EUR-Lex Document 02016R0799-20230821

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
►M3 Règlement d’exécution (UE) 2021/1228 de la Commission du 16 juillet
2021
L 273 1 30.7.2021
►M4 Règlement d’exécution (UE) 2023/980 de la Commission du 16 mai
2023
L 134 28 22.5.2023
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 — 21.08.2023 — 003.002 — 1
02016R0799 — FR — 21.08.2023 — 003.002 — 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 — 21.08.2023 — 003.002 — 3
En outre, on entend par:
1) «tachygraphe numérique» ou «tachygraphe de première génération»,
un tachygraphe numérique autre qu'un tachygraphe intelligent;
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 — 21.08.2023 — 003.002 — 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 — 21.08.2023 — 003.002 — 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'extension 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'interopérabilité.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 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’excep­
tion 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 — 21.08.2023 — 003.002 — 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
▼M3
3.6.4 Saisie des opérations de chargement/déchargement
▼B
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 — 21.08.2023 — 003.002 — 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»
▼M3
3.9.18 Événement «Anomalie GNSS»
▼B
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
▼M3
3.12.17 Passages aux frontières
3.12.18 Opérations de chargement/déchargement
3.12.19 Carte numérique
▼B
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 9
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
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
▼M3
3.20 Échanges de données avec des dispositifs externes supplémentaires
▼B
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
▼M3
3.27 Surveillance des passages aux frontières
3.28 Mise à jour logicielle
▼B
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 10
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
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
▼M3
4.5.3.2.1.1 Identification des applications supplémentaires (non accessible par
la version 1 des unités embarquées sur véhicule de deuxième géné­
ration)
▼B
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
▼M3
4.5.3.2.17 Statut d’authentification pour les positions correspondant aux lieux
de début et/ou de fin des périodes de travail journalières (non
accessible par la version 1 des unités embarquées sur véhicule de
deuxième génération)
4.5.3.2.18 Statut d’authentification pour les positions correspondant aux lieux
où les trois heures de temps de conduite accumulé sont atteintes
(non accessible par la version 1 des unités embarquées sur véhicule
de deuxième génération)
4.5.3.2.19 Passages aux frontières (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 11
4.5.3.2.20 Opérations de chargement/déchargement (non accessible par la
version 1 des unités embarquées sur véhicule de deuxième géné­
ration)
4.5.3.2.21 Saisies du type de charge (non accessible par la version 1 des
unités embarquées sur véhicule de deuxième génération)
4.5.3.2.22 Configurations de la VU (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
▼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
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
▼M3
4.5.4.2.1.1 Identification des applications supplémentaires (non accessible par
la version 1 des unités embarquées sur véhicule de deuxième géné­
ration)
▼B
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
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 12
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
▼M3
4.5.4.2.16 Statut d’authentification pour les positions correspondant aux lieux
de début et/ou de fin des périodes de travail journalières (non
accessible par la version 1 des unités embarquées sur véhicule de
deuxième génération)
4.5.4.2.17 Statut d’authentification pour les positions correspondant aux lieux
où les trois heures de temps de conduite accumulé sont atteintes
(non accessible par la version 1 des unités embarquées sur véhicule
de deuxième génération)
4.5.4.2.18 Passages aux frontières (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
4.5.4.2.19 Opérations de chargement/déchargement (non accessible par la
version 1 des unités embarquées sur véhicule de deuxième géné­
ration)
4.5.4.2.20 Saisies du type de charge (non accessible par la version 1 des
unités embarquées sur véhicule de deuxième génération)
4.5.4.2.21 Données d’étalonnage supplémentaires (non accessible par la
version 1 des unités embarquées sur véhicule de deuxième géné­
ration)
4.5.4.2.22 Configurations de la VU (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
▼B
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
▼M3
4.5.5.2.1.1 Identification des applications supplémentaires (non accessible par
la version 1 des unités embarquées sur véhicule de deuxième géné­
ration)
▼B
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
▼M3
4.5.5.2.6 Configurations de la VU (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
▼B
4.5.6 Carte d'entreprise
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 13
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
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
▼M3
4.5.6.2.1.1 Identification des applications supplémentaires (non accessible par
la version 1 des unités embarquées sur véhicule de deuxième géné­
ration)
▼B
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
▼M3
4.5.6.2.6 Configurations de la VU (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
▼B
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 14
INTRODUCTION
La présente annexe contient les exigences relatives aux appareils de contrôle et
cartes tachygraphiques de deuxième génération.
Depuis le 15 juin 2019, des appareils de contrôle de deuxième génération sont
installés dans les véhicules immatriculés dans l’Union pour la première fois et
des cartes tachygraphiques de deuxième génération sont délivrées.
Afin de mettre en œuvre sans encombre le tachygraphe de deuxième génération,
les cartes tachygraphiques de deuxième génération ont été conçues pour être
également utilisées dans les unités embarquées sur véhicule de première généra­
tion construites conformément à l’annexe I B du règlement (CEE) n o 3821/85.
Réciproquement, les cartes tachygraphiques de première génération peuvent être
utilisées dans les unités embarquées sur véhicule de deuxième génération. Cepen­
dant, les unités embarquées sur véhicule de deuxième génération ne peuvent être
étalonnées qu’à l’aide de cartes d’atelier de deuxième génération.
Les exigences relatives à l’interopérabilité entre les tachygraphes de première et
de deuxième génération sont spécifiées dans la présente annexe. À cet égard,
l’appendice 15 contient des détails supplémentaires sur la gestion de la coexis­
tence des deux générations.
En outre, en raison de la mise en œuvre de nouvelles fonctions telles que
l’utilisation du service d’authentification des messages de navigation en libre
service de Galileo (OSNMA), la détection des passages aux frontières, la saisie
des opérations de chargement et de déchargement, et en raison de la nécessité de
porter la capacité de la carte de conducteur à 56 jours d’activités du conducteur,
le présent règlement introduit les exigences techniques applicables à la deuxième
version des appareils de contrôle et des cartes tachygraphiques de deuxième
génération.
▼B
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
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 15
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éra­
teur ou d'un dispositif externe;
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);
▼M3
f) «étalonnage d’un tachygraphe intelligent»:
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’immatriculation] 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, type de charge par défaut];
pendant l’étalonnage d’un appareil de contrôle, les types et les
identifiants des scellements 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 énoncée au point 6.4.
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 un numéro
d’identification unique d’une carte tachygraphique dans un
État membre. Le numéro de carte comprend une identification,
qui consiste en une identification du conducteur, ou en une
identification du propriétaire de la carte, accompagnée d’un
indice séquentiel de la carte, d’un indice de remplacement
de la carte et d’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;
▼B
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;
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 16
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 tachygraphique
correspondant à une identification donnée, c’est-à-dire à une
identification du conducteur ou du propriétaire accompagnée
d’un indice séquentiel;
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
correspondant à une identification donnée, c’est-à-dire à une
identification du conducteur ou du propriétaire accompagnée
d’un indice séquentiel;
▼B
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'appa­
reil 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 kilo­
mè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;
m) «constante de l'appareil de contrôle»:
la caractéristique numérique donnant la valeur du signal
d'entré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 DISPONIBILITÉ
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;
▼M3
( 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 — 21.08.2023 — 003.002 — 17
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'étalonnage 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 accumulées
par un conducteur donné, depuis la fin de sa dernière période de
DISPONIBILITÉ ou 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.]
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.
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 transfor­
mation cryptographique de celui-ci, qui permettent à son desti­
nataire 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;
▼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.
02016R0799 — FR — 21.08.2023 — 003.002 — 18
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;
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 navi­
gation par satellite (GNSS en anglais) afin de déterminer la
position, la vitesse et l'heure;
▼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 — 21.08.2023 — 003.002 — 19
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;
▼M3
ee) «carte non valable»:
une carte détectée comme présentant un défaut, ou dont
l’authentification 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;
une carte est également considérée comme non valable par
l’unité embarquée sur véhicule:
— si une carte portant le même État membre de délivrance, la
même identification, c’est-à-dire la même identification du
conducteur ou du propriétaire accompagnée d’un indice
séquentiel, et un indice de renouvellement plus élevé a
déjà été insérée dans l’unité embarquée sur véhicule, ou
— si une carte portant le même État membre de délivrance, la
même identification, c’est-à-dire la même identification du
conducteur ou du propriétaire accompagnée d’un indice
séquentiel et d’un indice de renouvellement, mais avec
un indice de remplacement plus élevé, a déjà été insérée
dans l’unité embarquée sur véhicule;
▼B
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;
▼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 — 21.08.2023 — 003.002 — 20
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;
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;
▼M3
ll) «dispositif de communication à distance», «module de commu­
nication à 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;
▼M3
nn) «renouvellement de la carte»:
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;
▼B
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;
▼M3
pp) «remplacement de la carte»:
la délivrance d’une nouvelle carte tachygraphique en rempla­
cement 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’autorité qui l’a délivrée;
▼B
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);
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 21
tt) «remise à l’heure»:
un réglage de l’heure actuelle; ce réglage peut être exécuté de
manière automatique, 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;
vv) «identification du véhicule»:
les numéros permettant d'identifier le véhicule: numéro
d'immatriculation (VRN) avec indication de l'État membre
d'immatriculation, et numéro d'identification du véhicule
(VIN) ( 2 );
ww) «semaine», aux fins du calcul dans l'appareil de contrôle:
une période 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épen­
dante, et qui est:
▼M3
— installé et utilisé uniquement sur les types de véhicules M1
et N1, tels que définis à l’article 4 du règlement (UE)
2018/858 du Parlement européen et du Conseil ( 3 ),
▼B
— installé lorsqu'il n'est pas mécaniquement possible
d'installer un autre type de capteur de mouvement par
ailleurs conforme aux dispositions de la présente annexe
et de ses appendices 1 à 15,
▼M3
( 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).
( 2 ) 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).
( 3 ) Règlement (UE) 2018/858 du Parlement européen et du Conseil du 30 mai 2018 relatif à
la réception et à la surveillance du marché des véhicules à moteur et de leurs remorques,
ainsi que des systèmes, composants et entités techniques distinctes destinés à ces véhi­
cules, modifiant les règlements (CE) n o 715/2007 et (CE) n o 595/2009 et abrogeant la
directive 2007/46/CE (JO L 151 du 14.6.2018, p. 1).
02016R0799 — FR — 21.08.2023 — 003.002 — 22
— 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
remplacement;
— 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;
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;
▼M3
aaa) réservé pour une utilisation future;
▼B
bbb) «tachygraphe intelligent»:
l'appareil de contrôle, les cartes tachygraphiques et l'ensemble
des équipements qui interagissent directement ou indirectement
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.;
▼M3
ccc) «date de mise en œuvre»:
la date fixée dans le règlement (UE) n o 165/2014 à partir de
laquelle les véhicules immatriculés pour la première fois
doivent être équipés d’un tachygraphe conformément au
présent règlement;
▼B
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
02016R0799 — FR — 21.08.2023 — 003.002 — 23
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'APPAREIL 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'appendice 11.
3) L'unité embarquée sur le véhicule doit être
connectée à un ou plusieurs systèmes mondiaux
de navigation par satellite, comme indiqué à
l'appendice 12.
4) L'unité embarquée sur le véhicule doit communi­
quer avec des lecteurs de communication et de
détection précoces à distance conformément à
l'appendice 14.
▼M3
5) L’unité embarquée sur le véhicule doit comporter
une interface ITS, qui est spécifiée à l’appen­
dice 13.
L’appareil de contrôle peut être relié à d’autres
équipements par le biais d’interfaces supplémen­
taires et/ou de l’interface ITS.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 24
6) Toute insertion ou connexion de toute fonction
ou dispositif(s), homologué(s) ou non, dans ou à
l'appareil de contrôle, ne doit pas interférer ou
être susceptible d'interférer avec le fonctionne­
ment 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'identi­
fient 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'utilisateur.
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.
▼M3
Ces fonctions sont assurées conformément à la législation de
l’Union applicable en matière de protection des données et à
l’article 7 du règlement (UE) n o 165/2014.
▼B
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,
▼M3
— 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 conduc­
teur et consentement du conducteur pour
l’interface ITS,
— saisie des conditions particulières,
— saisie des opérations de chargement/
déchargement,
▼B
— 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,
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 25
— communication à distance pour les contrôles
routiers ciblés,
— sortie de données vers des équipements addi­
tionnels,
— étalonnage,
— contrôle routier d'étalonnage,
— remise à l'heure,
▼M3
— surveillance des passages aux frontières,
— mise à jour logicielle.
▼B
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 tachygra­
phique valable insérée dans l'interface de carte. La
génération à laquelle appartient la carte du tachy­
graphe n'est pas pertinente en vue de déterminer le
mode de fonctionnement à condition que la carte
insérée soit valable. Une carte d'atelier de première
génération doit toujours être considérée comme non
valable lorsqu'elle est insérée dans une unité embar­
quée de deuxième génération.
Mode de fonctionnement
Lecteur «conducteur»
Pas de carte Carte du conducteur Carte de contrôleur Carte d'atelier Carte d'entreprise
L
ec
te
ur
«
co
nv
oy
eu
r»

Pas de carte Opérationnel Opérationnel Contrôle Étalonnage Entreprise
Carte du cond­
ucteur
Opérationnel Opérationnel Contrôle Étalonnage Entreprise
Carte de con­
trô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'exception de:
— la fonction d'étalonnage, accessible unique­
ment en mode étalonnage,
— la fonction de contrôle routier d'étalonnage,
accessible uniquement en mode contrôle,
— la fonction de gestion des verrouillages d'entre­
prise, accessible uniquement en mode entreprise,
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 26
— le suivi des activités de contrôle, accessible
uniquement en mode contrôle,
▼M3
— la fonction de téléchargement n’est pas acces­
sible en mode opérationnel, sauf:
a) dans les cas prévus à l’exigence 193,
b) pour le téléchargement d’une carte de
conducteur lorsqu’aucun autre type de
carte n’est inséré dans la VU.
▼B
13) L'appareil de contrôle peut extraire toute donnée
pour affichage, impression ou téléchargement
vers des interfaces externes, sauf:
— en mode opérationnel, toute identification
personnelle [nom et prénom(s)] ne correspon­
dant 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 carac­
tère sur deux, de gauche à droite),
▼M3
— en mode entreprise, les données relatives au
conducteur (exigences 102, 105, 108, 133 bis
et 133 sexies) peuvent être extraites seule­
ment pour les périodes où aucun verrouillage
n’existe ou où aucune autre entreprise (telle
qu’identifiée par les 13 premiers chiffres du
numéro de la carte d’entreprise) ne détient de
verrouillage,
▼B
— lorsqu'aucune carte n'est insérée dans l'appa­
reil de contrôle, seules peuvent être extraites
les données relatives au conducteur pour le
jour même et les 8 jours civils précédents,
▼M3
— les données à caractère personnel enregistrées
et produites par le tachygraphe ou les cartes
tachygraphiques ne doivent pas être extraites
grâce à l’interface ITS de la VU à moins que
le consentement du conducteur à qui se
rapportent ces données soit vérifié.
▼M1
— 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’authenticité des données échangées entre l’unité embarquée sur
véhicule 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
02016R0799 — FR — 21.08.2023 — 003.002 — 27
14) Afin d'assurer la sécurité du système, les compo­
sants 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,
▼M3
— dispositif GNSS externe (ce profil n’est
nécessaire et applicable que pour la variante
du dispositif GNSS externe).
▼B
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.
▼M3
16) Lors de l’insertion d’une carte (ou de son authen­
tification à distance), l’appareil de contrôle
vérifie si la carte est une carte tachygraphique
valide au sens de la définition figurant à la
section 1, point ee), et identifie son type et la
génération à laquelle elle appartient.
Pour vérifier si une carte a déjà été insérée, l’appa­
reil de contrôle doit utiliser les données de la carte
tachygraphique stockées dans sa mémoire, comme
indiqué à l’exigence 133.
▼B
17) Les cartes tachygraphiques de première généra­
tion doivent être considérées comme non valables
par l'appareil de contrôle après que la possibilité
d'utiliser des cartes tachygraphiques 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.
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.
▼M3
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
action positive de l’utilisateur.
▼B
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 corres­
pondant à la distance totale parcourue par le
véhicule en utilisant les impulsions envoyées
par le capteur de mouvement.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 28
23) Cette fonction assure une mesure en continu et
permet d'indiquer la vitesse du véhicule en utili­
sant les impulsions envoyées par le capteur de
mouvement.
24) La fonction de mesure de la vitesse doit égale­
ment indiquer 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
provenance 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 appa­
reil 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.
▼M3
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 d’une ou
plusieurs autres sources indépendantes du
capteur de mouvement. Au moins une autre
source indépendante de mouvement du véhicule
doit se trouver à l’intérieur de la VU sans qu’une
interface externe soit nécessaire.
27) Cette fonction doit mesurer la position du véhi­
cule afin de permettre l’enregistrement:
— des positions correspondant aux lieux où le
conducteur et/ou le convoyeur commencent
leur période de travail journalière;
— des positions correspondant aux lieux où le
temps de conduite accumulé atteint un
multiple de trois heures;
— des positions correspondant aux lieux où le
véhicule a franchi la frontière d’un pays;
— des positions correspondant aux lieux où les
opérations de chargement/déchargement ont
été effectuées;
— des positions correspondant aux lieux où le
conducteur et/ou le convoyeur terminent leur
période de travail journalière.
▼B
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 — 21.08.2023 — 003.002 — 29
30) La distance mesurée doit être dans les tolérances
suivantes (distances d'au moins 1 000 m):
— ± 1 % avant installation,
— ± 2 % lors de l'installation et des inspections
périodiques,
— ± 4 % en service.
▼M3
Les tolérances ne doivent pas être utilisées pour
modifier intentionnellement la distance mesurée.
▼B
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.
▼M3
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 varia­
tions 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éristiques du véhicule compris
entre 2 400 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.
▼B
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.
▼M3
37) La position absolue doit être mesurée sous forme
de coordonnées géographiques en degrés et
minutes de latitude et de longitude, avec une
résolution d’un dixième de minute.
▼B
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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 30
39) La date et l'heure UTC sont utilisées pour dater
les données à l'intérieur de l'appareil de contrôle
(enregistrements, é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é.
▼M3
41) La dérive temporelle ne doit pas excéder
± 1 seconde par jour, dans des conditions de
température conformes à l’exigence 213, en
l’absence de toute remise à l’heure.
41 bis) Lorsque le réglage de l’heure est effectué en
atelier conformément à l’exigence 212, les
heures doivent être connues avec une précision
de 3 secondes ou mieux.
41 ter) L’unité embarquée sur véhicule doit comprendre
un compteur de dérive qui calcule la dérive
temporelle maximale depuis le dernier réglage
de l’heure effectué conformément au point 3.23.
La dérive temporelle maximale doit être définie
par le fabricant de l’unité embarquée sur véhicule
et ne doit pas excéder 1 seconde par jour, comme
indiqué à l’exigence 41.
41 quater) Le compteur de dérive doit être remis à
1 seconde après chaque réglage de l’heure de
l’appareil de contrôle conformément au
point 3.23, y compris après:
— les réglages automatiques de l’heure,
— les réglages de l’heure effectués en mode
étalonnage.
▼B
42) Le temps mesuré doit avoir une résolution meil­
leure 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 condi­
tions 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, DISPONIBILITÉ ou PAUSE/
REPOS.
47) Lorsque le véhicule est en mouvement, l'activité
CONDUITE doit être automatiquement sélec­
tionnée pour le conducteur, et l'activité DISPO­
NIBILITÉ doit être automatiquement sélec­
tionnée pour le convoyeur.
48) Lorsque le véhicule s'arrête, l'activité TRAVAIL
doit être automatiquement sélectionnée pour le
conducteur.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 31
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éhi­
cule 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 consi­
dérée comme activité de CONDUITE en applica­
tion 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
automatiquement 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élec­
tionné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.
▼M3
57) On entend par lieu le pays et, le cas échéant, la
région.
58) Lors du retrait de la carte de conducteur (ou
d’atelier), l’appareil de contrôle doit afficher le
lieu actuel du véhicule sur la base des informations
GNSS et de la carte numérique stockée conformé­
ment au point 3.12.19, et il doit demander au titu­
laire de la carte de confirmer ou de rectifier
manuellement le lieu.
59) Le lieu saisi conformément à l’exigence 58 doit
être considéré comme le lieu où se termine la
période de travail journalière. Il doit être enre­
gistré sur la carte de conducteur (ou d’atelier)
correspondante en tant qu’enregistrement tempo­
raire et peut donc être écrasé ultérieurement.
Dans les conditions suivantes, la saisie temporaire
effectué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 journalière actuelle lors de la saisie
manuelle en application de l’exigence 61;
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 32
— 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 tempo­
raire effectué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 empla­
cement de début ou de fin de la période de
travail lors de la saisie manuelle en applica­
tion 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.
▼M3
L’appareil de contrôle doit afficher le lieu actuel
du véhicule sur la base des informations GNSS et
de la ou des cartes numériques stockées confor­
mément au point 3.12.19, et il doit demander au
conducteur de confirmer ou de rectifier manuel­
lement le lieu.
▼B
3.6.2 Saisie manuelle des activités du conducteur et consentement du
conducteur pour l'interface ITS
▼M3
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 rappe­
lé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électionné 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 tachygraphe
puissent être extraites grâce à l’interface ITS.
Pour vérifier si une carte a déjà été insérée,
l’appareil de contrôle doit utiliser les données
de la carte tachygraphique stockées dans sa
mémoire, comme indiqué à l’exigence 133.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 33
L’accord du conducteur (ou de l’atelier) peut être
activé ou désactivé à tout moment par des
commandes se trouvant dans le menu, à condi­
tion que la carte du conducteur (ou de l’atelier)
soit insérée.
Il doit être possible de saisir des activités,
moyennant les restrictions suivantes:
— le type d’activité doit être le TRAVAIL, la
DISPONIBILITÉ ou la PAUSE/REPOS,
— les heures de début et de fin pour chaque
activité doivent se situer exclusivement dans
la période séparant 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électionner un type, une heure
de début et une heure de fin pour chaque activité.
Pour toute partie de la période séparant le dernier
retrait de la carte de son insertion actuelle, le
détenteur a le choix de ne déclarer aucune acti­
vité.
Au cours des saisies manuelles associées à
l’insertion de la carte, le détenteur de celle-ci a,
le cas échéant, la possibilité de saisir:
— un lieu où s’est achevée une période de
travail journaliè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 jour­
nalière actuelle, associé à l’heure correspon­
dante (qui valide une saisie temporaire effec­
tuée lors du dernier retrait de la carte).
Pour le lieu où débute la période de travail jour­
nalière actuelle saisi lors de l’insertion de la carte
actuelle, l’appareil de contrôle doit afficher le
lieu actuel du véhicule sur la base des informa­
tions GNSS et de la ou des cartes numériques
stockées conformément au point 3.12.19, et il
doit demander au conducteur de confirmer ou
de rectifier manuellement le lieu.
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.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 34
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 ambi­
guï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’effec­
tuer une saisie manuelle selon la procédure mini­
male suivante:
— saisie manuelle des activités, par ordre chro­
nologique, pour la période allant du dernier
retrait de la carte à son insertion actuelle,
— l’heure de début de la première activité est
fixée à l’heure du retrait de la carte. Pour
chaque saisie ultérieure, l’heure de début
présélectionnée suit immédiatement l’heure
de fin de la saisie précédente. Le type d’acti­
vité 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 activité saisie manuellement correspond à
l’heure d’insertion de la carte.
L’appareil de contrôle doit permettre aux conduc­
teurs et aux ateliers d’effectuer successivement
des saisies manuelles qui doivent être introduites
au cours de la procédure grâce à l’interface ITS
spécifiée à l’appendice 13 et, éventuellement,
grâce à d’autres interfaces.
L’appareil de contrôle doit permettre au détenteur
de la carte de modifier toute activité saisie
manuellement, jusqu’à la validation par la sélec­
tion d’une commande particulière. Par la suite,
toute modification de ce type est interdite.
▼B
3.6.3 Saisie de conditions particulières
▼M3
62) L’appareil de contrôle doit permettre au conduc­
teur de saisir en temps réel les deux conditions
particulières suivantes:
— «HORS CHAMP» (début, fin),
— «TRAJET EN FERRY/TRAIN» (début, fin).
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 35
Un «TRAJET EN FERRY/TRAIN» ne doit pas
survenir lorsque la condition «HORS CHAMP»
est ouverte. Si une condition «HORS CHAMP»
est ouverte, l’appareil de contrôle ne doit pas
permettre aux utilisateurs de saisir un drapeau
de début «TRAJET EN FERRY/TRAIN».
Une condition «HORS CHAMP» ouverte doit
impérativement ê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 conducteur doit entrer le drapeau de début
TRAJET EN FERRY/TRAIN immédiatement
après avoir sélectionné PAUSE/REPOS sur le
ferry ou le train.
Un TRAJET EN FERRY/TRAIN ouvert doit être
clôturé par l’appareil de contrôle lorsque l’une
des possibilités suivantes se produit:
— le conducteur met fin manuellement au
TRAJET EN FERRY/TRAIN à l’arrivée à
destination du ferry/train, avant de quitter le
ferry/train,
— une condition «HORS CHAMP» est ouverte,
— le conducteur éjecte sa carte,
— l’activité du conducteur est comptabilisée
comme de la CONDUITE pendant une
minute calendrier conformément au point 3.4.
Si plusieurs saisies d’un même type correspon­
dant à une de ces conditions particulières sont
effectuées au cours d’une minute calendrier,
seule la dernière doit être gardée enregistrée.
3.6.4 Saisie des opérations de chargement/déchargement
62 bis) L’appareil de contrôle doit permettre au conduc­
teur de saisir et de confirmer, en temps réel, des
informations indiquant que le véhicule est en
train d’être chargé ou déchargé, ou qu’une opéra­
tion de chargement/déchargement simultanés est
en cours.
Si plusieurs saisies d’un même type indiquant
une opération de chargement/déchargement sont
effectuées au cours d’une minute calendrier, seule
la dernière doit être gardée enregistrée.
62 ter) Les opérations de chargement, de déchargement
ou de chargement/déchargement simultanés
doivent être enregistrées en tant qu’événements
distincts.
62 quater) Les informations relatives au chargement/déchar­
gement doivent être saisies avant que le véhicule
ne quitte le lieu où l’opération de chargement/
déchargement est effectuée.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 36
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) asso­
ciées à l'identification de l'entreprise par le
numéro de carte d'entreprise (lors du verrouil­
lage).
65) Le verrouillage et le déverrouillage ne sont possi­
bles 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
67) le déverrouillage est automatique lorsqu'une autre
entreprise verrouille.
68) Dans le cas où une entreprise verrouille et où le
verrouillage précédent a été effectué pour la
même entreprise, on supposera que le verrouil­
lage précédent n'a pas été déverrouillé 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 acti­
vité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 vali­
dité 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
combinaisons de cartes marquées d'une croix
dans le tableau suivant:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 37
Conflit de carte
Lecteur «conducteur»
Pas de carte
Carte du conduc­
teur
Carte de contrôleur Carte d'atelier Carte d'entreprise
L
ec
te
ur
«
co
nv
oy
eu
r»
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 conduc­
teur, tel qu'elle apparaî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 combi­
naison 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:
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
L
ec
te
ur
«
co
nv
oy
eu
r»

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
tachygraphique est insérée dans un lecteur quel­
conque 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 dispositions du paragraphe 3.1., la
session précédente n'a pas été correctement
clôturée (la carte a été retirée avant que 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 38
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'alimenta­
tion électrique du capteur de mouvement et/ou de
l'unité embarquée sur le véhicule. Le seuil d'inter­
ruption 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'«étalonnage» et que le dispositif de commu­
nication à distance ne confirme pas la bonne
réception de données de communication à
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 informa­
tion 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'«étalonnage», que la communication entre
le dispositif GNSS externe et l'unité embarquée
sur le véhicule est interrompue pendant plus de
20 minutes consécutives et que le véhicule est en
mouvement.
3.9.12 Événement «Erreur sur les données de mouvement»
▼M3
83) Cet événement est déclenché, en mode autre
qu’«étalonnage», en cas d’interruption du flux
normal de données entre le capteur de mouve­
ment 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 mouve­
ment et la VU. Cet événement est également
déclenché, en mode autre qu’«étalonnage», si
la vitesse calculée à partir des impulsions du
capteur de mouvement passe de 0 à plus de
40 km/h en 1 seconde, puis reste supérieure à
40 km/h pendant au moins 3 secondes.
▼B
3.9.13 Événement «Conflit concernant le mouvement du véhicule»
▼M3
84) Comme spécifié à l’appendice 12, cet événement
est déclenché, en mode autre qu’«étalonnage»,
lorsque des informations relatives au mouvement
calculées par le capteur de mouvement entrent en
conflit avec les informations de mouvement four­
nies par le récepteur GNSS interne ou par le
dispositif GNSS externe, ou par une ou plusieurs
autres sources indépendantes, conformément à
l’exigence 26. Cet événement n’est pas déclenché
lors d’un trajet en ferry/train.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 39
3.9.14 Événement «Tentative d'atteinte à la sécurité»
85) Cet événement est déclenché en cas de tout autre
événement 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»
▼M3
86) Cet événement est déclenché, en mode autre
qu’«étalonnage», lorsque la VU détecte un
écart entre l’heure fournie par sa fonction de
mesure du temps et l’heure provenant des posi­
tions authentifiées transmises par le récepteur
GNSS ou le dispositif GNSS externe. Un «écart
temporel» est détecté si la différence de temps
dépasse ± 3 secondes, ce qui correspond à la
précision temporelle définie à l’exigence 41 bis,
cette dernière étant augmentée de la dérive
temporelle maximale par jour. Cet événement
est enregistré avec la valeur d’horloge interne
de l’appareil de contrôle. La VU vérifie le
déclenchement de l’événement «Conflit
temporel» juste avant de réajuster automatique­
ment son horloge interne, conformément à
l’exigence 211.
▼B
3.9.16 Anomalie «Carte»
87) Cette anomalie est déclenchée en cas d'anomalie
d'une carte tachygraphique en cours de fonction­
nement.
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.
▼M3
— anomalie sur l’interface ITS.
3.9.18 Événement «Anomalie GNSS»
88 bis) Cet événement est déclenché, en mode autre
qu’«étalonnage», lorsque le récepteur GNSS
détecte une attaque, ou lorsque l’authentification
des messages de navigation a échoué, comme
spécifié à l’appendice 12. Après le déclenche­
ment d’un événement «Anomalie GNSS», la
VU ne générera plus d’autres événements
«Anomalie GNSS» pendant les 10 minutes
suivantes.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 40
3.10 Autotests intégrés
89) ►M1 L’appareil de contrôle détecte les anoma­
lies 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
fabricant)
Impression
Écran Contrôle visuel
Téléchargement
(effectué uniquement
lors du téléchargement)
Fonctionnement
correct
Capteur Fonctionnement
correct
Fonctionnement
correct
Dispositif de commu­
nication à distance
Fonctionnement
correct
Fonctionnement
correct
Dispositif GNSS Fonctionnement
correct
Fonctionnement
correct
▼M3
Interface ITS 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
▼M3
Aux fins du présent point,
— 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 ou convoyeurs, 2190 cycles d’insertion/retrait
de cartes et 93 440 changements d’activité,
— le nombre moyen de saisies de lieux par jour est défini comme
au moins 6 saisies correspondant aux lieux où commence la
période de travail journalière et 6 saisies correspondant aux
lieux où se termine la période de travail journalière, de sorte
qu’au moins 4 380 saisies de lieux sont comprises dans ces
«365 jours»,
— le nombre moyen de positions par jour lorsque le temps de
conduite accumulé atteint un multiple de trois heures est défini
comme au moins à 6 positions, de sorte qu’au moins 2 190 posi­
tions sont comprises dans ces «365 jours»,
— le nombre moyen de passages aux frontières par jour est défini
comme au moins 20 passages, de sorte qu’au moins 7 300 passages
aux frontières sont compris dans ces «365 jours»,
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 41
— le nombre moyen d’opérations de chargement/déchargement par
jour est défini comme au moins 25 opérations (tous types
confondus), de sorte qu’au moins 9 125 opérations de charge­
ment/déchargement sont comprises dans ces «365 jours»,
— 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, en association avec la
précision et le temps d’acquisition du GNSS, et avec un drapeau
indiquant si la position a été authentifiée.
▼B
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'homo­
logation. 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'identifi­
cation 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 tachygra­
phiques 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.
▼M3
— identificateur de la version de la carte numé­
rique (exigence 133 terdecies).
94) Les données d’identification de l’unité embar­
qué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, à l’exception des
données qui peuvent être modifiées en cas de
mise à jour du logiciel conformément au
présent règlement, et des données concernant la
possibilité d’utiliser des cartes tachygraphiques
de première génération.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 42
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 micropro­
cesseur 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.
▼M3
97) L’unité embarquée sur le véhicule enregistre et
mémorise dans sa mémoire de données les
données suivantes associées aux 20 appariements
de capteurs de mouvement ayant abouti 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
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 micropro­
cesseur 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.
▼M3
100) L’unité embarquée sur le véhicule enregistre et
mémorise dans sa mémoire de données les
données suivantes associées aux 20 appariements
de dispositifs GNSS externes ayant abouti 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 — 21.08.2023 — 003.002 — 43
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'appen­
dice 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
conducteur 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,
— 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'immatricu­
lation,
— 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 44
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 conduc­
teur 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 manuel­
lement 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.
▼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
108) L’appareil de contrôle doit enregistrer et stocker
dans sa mémoire:
— les lieux et positions des lieux où le conduc­
teur et/ou le convoyeur commencent leur
période de travail journalière;
— les positions des lieux où le temps de
conduite accumulé atteint un multiple de
trois heures;
— les lieux et positions des lieux où le conduc­
teur et/ou le convoyeur terminent leur période
de travail journalière.
▼B
109) Lorsque le récepteur GNSS ne peut communi­
quer la position du véhicule à ces instants
précis, l'appareil de contrôle doit utiliser la
dernière position disponible, ainsi que la date et
l'heure correspondantes.
110) Pour chaque lieu ou pour chaque position, l'appa­
reil de contrôle doit enregistrer et stocker dans sa
mémoire:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 45
— le numéro de carte de conducteur et/ou de
convoyeur et l’État membre qui a délivré la
carte
▼B
— 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 corres­
pondantes, le cas é chéant,
— kilométrage du véhicule,
▼M3
— un drapeau indiquant si la position a été
authentifiée.
110 bis) Pour les lieux de début ou de fin de la période de
travail journalière saisis au cours de la procédure
de saisie manuelle à l’insertion de la carte confor­
mément à l’exigence 61, le kilométrage et la
position du véhicule doivent être enregistrés.
▼M1
111) La mémoire doit être en mesure de conserver
pendant au moins 365 jours les lieux et les posi­
tions des lieux où les périodes de travail journa­
lières commencent et se terminent, 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 kilométrage du véhicule et la date correspon­
dante, 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:
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 46
É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.
▼M3
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.
▼B
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 — 21.08.2023 — 003.002 — 47
É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 — 21.08.2023 — 003.002 — 48
É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.
▼M3
Anomalie 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 enre­
gistré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 la fin de l’événe­
ment,
— 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.
▼B
(1) L'appareil de contrôle doit également enregis­
trer 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:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 49
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.
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ério­
dique),
— 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 scelle­
ments en place,
▼M3
— les numéros de série du capteur de mouve­
ment, du dispositif GNSS externe (le cas
échéant) et du dispositif externe de commu­
nication à distance (le cas échéant),
— le type de charge par défaut associé au véhi­
cule (chargement de biens ou de passagers),
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 50
— le pays dans lequel l’étalonnage a été effectué
et la date et l’heure auxquelles la position
utilisée pour déterminer ce pays a été
fournie par le récepteur GNSS.
▼B
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 concer­
nant 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 concer­
nant son installation:
— premier couplage à une VU (date, heure,
numéro d'homologation de la VU, numéro
de série de la VU),
— dernier couplage à une VU (date, heure,
numéro d'homologation 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 «étalon­
nage» 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.
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).
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 51
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
verrouillage 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 particuliè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 épuisé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 — 21.08.2023 — 003.002 — 52
— 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.
▼M3
3.12.17 Passages aux frontières
133 bis) L’appareil de contrôle doit enregistrer et stocker
dans sa mémoire les informations suivantes sur
les passages aux frontières:
— le pays que le véhicule quitte,
— le pays dans lequel le véhicule pénètre,
— la position correspondant au lieu où le véhi­
cule a franchi la frontière.
133 ter) Avec les pays et la position, l’appareil de
contrôle doit enregistrer et stocker dans sa
mémoire:
— le numéro de carte de conducteur et/ou de
convoyeur et l’État membre qui a délivré la
carte,
— la génération de la carte,
— la précision GNSS, la date et l’heure
correspondantes,
— un drapeau indiquant si la position a été
authentifiée,
— le kilométrage du véhicule au moment du
passage aux frontières.
133 quater) La mémoire doit pouvoir conserver ces données
relatives aux passages aux frontières pendant au
moins 365 jours.
133 quinquies) Lorsque la capacité de stockage est épuisée, les
données nouvelles remplacent les données les
plus anciennes.
3.12.18 Opérations de chargement/déchargement
133 sexies) L’appareil de contrôle doit enregistrer et stocker
dans sa mémoire les informations suivantes
concernant les opérations de chargement et de
déchargement du véhicule:
— le type d’opération (chargement, décharge­
ment ou chargement/déchargement simul­
tanés),
— la position correspondant au lieu où l’opéra­
tion de chargement/déchargement s’est
déroulée.
133 septies) Lorsque le récepteur GNSS ne peut communi­
quer la position du véhicule au moment de
l’opération de chargement/déchargement, l’appa­
reil de contrôle doit utiliser la dernière position
disponible, ainsi que la date et l’heure
correspondantes.
133 octies) Avec le type d’opération et la position, l’appareil
de contrôle doit enregistrer et stocker dans sa
mémoire:
— le numéro de carte de conducteur et/ou de
convoyeur et l’État membre qui a délivré la
carte,
— la génération de la carte,
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 53
— la date et l’heure de l’opération de charge­
ment/déchargement,
— la précision GNSS, la date et l’heure corres­
pondantes, le cas échéant,
— un drapeau indiquant si la position a été
authentifiée,
— le kilométrage du véhicule.
133 nonies) La mémoire doit pouvoir stocker les opérations
de chargement/déchargement pendant au moins
365 jours civils.
133 decies) Lorsque la capacité de stockage est épuisée, les
données nouvelles remplacent les données les
plus anciennes.
3.12.19 Carte numérique
133 undecies) Afin d’enregistrer la position du véhicule lors du
franchissement de la frontière d’un pays, l’appa­
reil de contrôle stocke dans sa mémoire une carte
numérique.
133 duodecies) Les cartes numériques autorisées pour soutenir la
fonction de surveillance des passages aux fron­
tières de l’appareil de contrôle sont mises à
disposition par la Commission européenne pour
téléchargement à partir d’un site web sécurisé
prévu à cet effet, sous différents formats.
133 terdecies) Pour chacune de ces cartes, un identificateur de
version et une valeur de hachage sont disponibles
sur le site web.
133 quaterdecies) Les cartes doivent comporter:
— un niveau de définition correspondant au
niveau 0 de la nomenclature des unités terri­
toriales statistiques (NUTS),
— une échelle de 1:1 million.
133 quindecies) Les fabricants de tachygraphes doivent sélec­
tionner une carte sur le site web sécurisé et la
télécharger.
133 sexdecies) Les fabricants de tachygraphes ne doivent utiliser
une carte téléchargée à partir du site web
qu’après avoir vérifié son intégrité en utilisant
la valeur de hachage de la carte.
133 septdecies) La carte sélectionnée est importée dans l’appareil
de contrôle par son fabricant, dans un format
approprié, mais la sémantique de la carte
importée doit rester inchangée.
133 octodecies) Le fabricant doit aussi stocker l’identificateur de
version de la carte utilisée dans l’appareil de
contrôle.
133 novodecies) Il doit être possible de mettre à jour la carte
numérique stockée ou de la remplacer par une
nouvelle carte mise à disposition par la Commis­
sion européenne.
133 vicies) Les mises à jour des cartes numériques doivent
être effectuées conformément aux mécanismes de
mise à jour du logiciel mis en place par le fabri­
cant, en application des exigences 226 quinquies
et 226 sexies, de sorte que l’appareil de contrôle
puisse vérifier l’authenticité et l’intégrité de la
nouvelle carte importée, avant de la stocker et
de remplacer la précédente.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 54
133 unvicies) Les fabricants de tachygraphes peuvent ajouter
des informations supplémentaires à la carte de
base visée à l’exigence 133 quaterdecies) à des
fins autres que l’enregistrement des passages aux
frontières, telles que les frontières des régions de
l’UE, à condition que la sémantique de la carte
reste inchangée.
▼B
3.13 Lecture des cartes tachygraphiques
134) L'appareil de contrôle doit pouvoir lire sur les
cartes tachygraphiques 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é correc­
tement clôturée,
▼M3
— calculer le temps de conduite continue du
conducteur, le temps de pause cumulé et les
temps de conduite accumulés pour la semaine
précédente et la semaine en cours,
▼B
— imprimer les demandes d'impression de données
enregistré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 tachy­
graphiques de première génération si leur utilisa­
tion 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é.
▼M3
135 bis) La structure dans l’application «TACHO_G2»
dépend de la version. Les cartes de la version 2
contiennent des fichiers élémentaires supplémen­
taires par rapport à celles de la version 1,
notamment:
— dans les cartes de conducteur et d’atelier:
— EF Places_Authentication doit contenir le
statut d’authentification des positions du
véhicule stockées dans EF Places. Un
horodatage doit être stocké avec chaque
statut d’authentification, qui doit corres­
pondre exactement à la date et à l’heure
de la saisie stockées avec la position
correspondante dans EF Places.
— EF GNSS_Places_Authentication doit
contenir le statut d’authentification des
positions du véhicule stockées dans EF
GNSS_Places. Un horodatage doit être
stocké avec chaque statut d’authentifica­
tion, qui doit correspondre exactement à
la date et à l’heure de la saisie stockées
avec la position correspondante dans EF
Places.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 55
— EF Border_Crossings, EF Load_Unload_
Operations et EF Load_Type_Entries
doivent contenir des données relatives aux
passages aux frontières, aux opérations de
chargement/déchargement et aux types de
charge.
— dans les cartes d’atelier:
— EF Calibration_Add_Data doit contenir
des données d’étalonnage supplémentaires
par rapport à celles stockées dans EF
Calibration. Les anciennes valeurs de
date et d’heure et le numéro d’identifica­
tion du véhicule doivent être stockés avec
chaque enregistrement de données
d’étalonnage supplémentaire, et doivent
correspondre exactement aux anciennes
valeurs de date et d’heure et au numéro
d’identification du véhicule stockés avec
les données d’étalonnage correspondantes
dans l’étalonnage dans EF Calibration.
— dans toutes les cartes tachygraphiques:
— EF VU_Configuration doit contenir les
paramètres spécifiques du tachygraphe
du détenteur de la carte.
L’unité embarquée sur le véhicule doit ignorer tout
statut d’authentification trouvé dans EF Places_
Authentication ou EF GNSS_Places_Authentication,
lorsqu’aucune position du véhicule présentant le
même horodatage n’est trouvée dans EF Places ou
EF GNSS_Places.
L’unité embarquée sur véhicule doit ignorer le
fichier élémentaire EF VU_Configuration dans
toutes les cartes, dans la mesure où aucune règle
spécifique n’a été fournie en ce qui concerne l’utili­
sation de ce fichier élémentaire. Ces règles sont à
établir par une modification de l’annexe IC modi­
fiant ou supprimant le présent paragraphe.
▼B
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 tachygra­
phiques 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'insertion 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
manuellement par le détenteur de la carte.
▼M3
140) Tous les événements ou anomalies non définis
pour l’appareil de contrôle de première généra­
tion ne sont pas stockés sur les cartes de conduc­
teur et d’atelier de première génération.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 56
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 remplacent 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 valable.
▼M3
143) Avant la libération d’une carte de conducteur ou
d’atelier, 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».
▼B
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'application 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.
▼M3
La structure dans l’application «TACHO_G2»
dépend de la version. Les cartes de la version 2
contiennent des fichiers élémentaires supplémen­
taires par rapport à celles de la version 1.
▼B
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'insertion 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'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.
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 manuel­
lement par le détenteur de la carte.
▼M3
147 bis) Lors de l’insertion d’une carte de conducteur ou
d’atelier, l’appareil de contrôle doit stocker sur la
carte le type de charge par défaut du véhicule.
147 ter) Lors de l’insertion d’une carte de conducteur ou
d’atelier, et après la procédure de saisie manuelle,
l’appareil de contrôle doit vérifier le dernier lieu
de début ou de fin de la période de travail jour­
nalière stocké sur la carte. Ce lieu peut être
temporaire, comme spécifié à l’exigence 59. Si
ce lieu se trouve dans un pays différent de celui
où se trouve actuellement le véhicule, l’appareil
de contrôle doit stocker sur la carte un enregis­
trement du passage à la frontière, avec:
— le pays quitté par le conducteur: non disponible,
— le pays dans lequel le conducteur pénètre: le
pays où se trouve le véhicule actuellement,
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 57
— la date et l’heure auxquelles le conducteur a
franchi la frontière: l’heure d’insertion de la
carte,
— la position du conducteur lors du franchis­
sement de la frontière: non disponible,
— le kilométrage du véhicule: non disponible.
▼B
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 remplacent 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 valable.
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'appa­
reil de contrôle remet à zéro les «données de
session».
▼M3
150 bis) L’unité embarquée sur véhicule doit ignorer le
fichier élémentaire EF VU_Configuration dans
toutes les cartes, dans la mesure où aucune
règle spécifique n’a été fournie en ce qui
concerne l’utilisation de ce fichier élémentaire.
Ces règles sont à établir par une modification
de l’annexe IC modifiant ou supprimant le
présent paragraphe.
▼B
3.15 Affichage
151) L'affichage doit comporter au moins 20 carac­
tè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 caractères spécifiés au chapitre 4 «Jeux de
caractères» de l'appendice 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 majuscules).
154) L'affichage doit être muni d'un éclairage non
éblouissant.
155) Les indications doivent être visibles à l'extérieur
de l'appareil de contrôle.
156) L'appareil de contrôle doit pouvoir afficher:
— des données 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 affi­
chées par l'appareil de contrôle, à condition d'être
clairement distinctes des informations précitées.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 58
157) L'affichage de l'appareil de contrôle doit utiliser
les pictogrammes ou les combinaisons de picto­
grammes énumérées à l'appendice 3. Des picto­
grammes ou des combinaisons de pictogrammes
additionnels peuvent également être utilisé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 fonc­
tion manuelle ou automatique qui coupe le dispo­
sitif d'affichage 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'afficher les informations sur le convoyeur.
162) Lorsque la largeur d'affichage n'est pas suffisante
pour afficher par défaut le mode de fonctionne­
ment, l'appareil de contrôle doit afficher briève­
ment 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.
164) Lorsqu'une condition «HORS CHAMP» ou
«FERRY/TRAIN» est ouverte, le pictogramme
approprié doit apparaî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).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 59
3.15.2 Affichage d'avertissements
165) L'appareil de contrôle utilise principalement, pour
les avertissements, les pictogrammes figurant à
l'appendice 3, complétés au besoin par des infor­
mations 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,
▼M3
— le contenu de tout tirage papier visé à
l’exigence 169, dans le même format que le
tirage papier lui-même,
▼B
— 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,
▼M3
— le temps de conduite accumulé du conducteur
pour la semaine précédente et la semaine en
cours,
— le temps de conduite accumulé du convoyeur
pour la semaine précédente et pour la
semaine en cours,
▼B
à titre facultatif:
— la durée actuelle de l'activité du convoyeur
(depuis sa sélection),
▼M3
— le temps de conduite accumulé du conducteur
pour la semaine en cours,
— le temps de conduite accumulé du convoyeur
pour la période de travail journalière en
cours,
— le temps de conduite accumulé du conducteur
pour la période de travail journalière en
cours.
▼B
168) L'affichage du contenu du tirage papier est
séquentiel, ligne par ligne. Si la largeur d'affi­
chage 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 infor­
mations manuscrites peuvent être omises.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 60
3.16 Impression
169) L'appareil de contrôle doit pouvoir imprimer des
informations stockées dans sa mémoire et/ou sur
des cartes tachygraphiques, 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,
— é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 tachygra­
phique 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'appen­
dice 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 figu­
rant 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'appareil
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
conducteur ou la carte d'atelier si une seule
de ces cartes est insérée,
— soit comporter une commande permettant de
sélectionner la carte source ou de sélectionner
la carte insérée dans le lecteur «conducteur»
si deux de ces cartes sont insérées dans
l'appareil de contrôle.
172) L'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 carac­
tères spécifié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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 61
176) Les tirages papier doivent conserver leurs dimen­
sions 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 indication du ou des types
d'appareil de contrôle avec lesquels il peut être
utilisé.
178) Les tirages papier doivent rester facilement lisi­
bles et identifiables 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.
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 recom­
mencer l'impression au début, soit la reprendre
là où elle s'était interrompue, en faisant claire­
ment 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'alimentation é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 aver­
tissements sonores peuvent être produits en plus
des avertissements visuels.
186) Les avertissements visuels doivent être clairement
identifiables 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'appareil 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éci­
fiques de l'appareil de contrôle. Ce premier
accusé de réception ne doit pas effacer l'affichage
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'appa­
reil de contrôle.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 62
191) Des avertissements additionnels peuvent être
prévus, pour autant qu'ils ne prêtent pas à confu­
sion 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échar­
gement à la demande de données stockées sur sa
mémoire ou sur une carte de conducteur vers des
médias externes, par l'intermé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.
▼M3
193) En outre, et en option, l’appareil de contrôle
peut, dans tout mode de fonctionnement, télé­
charger des données grâce à n’importe quelle
autre interface 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».
▼B
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'étalon­
nage et le téléchargement est spécifiée à l'appen­
dice 6.
196) Les protocoles de téléchargement sont spécifiés à
l'appendice 7.
▼M3
196 bis) Une entreprise de transport utilisant des véhicules
équipés d’un appareil de contrôle conforme à la
présente annexe et relevant du champ d’applica­
tion du règlement (CE) n o 561/2006 doit veiller à
ce que toutes les données soient téléchargées à
partir de l’unité embarquée sur véhicule et des
cartes de conducteur.
La fréquence maximale à laquelle télécharger les
données pertinentes ne dépasse pas:
— 90 jours pour les données téléchargées à
partir de l’unité embarquée sur véhicule;
— 28 jours pour les données téléchargées à
partir de la carte de conducteur.
196 ter) Les entreprises doivent conserver les données
téléchargées à partir de l’unité embarquée sur
véhicule et des cartes de conducteur pendant au
moins douze mois après leur enregistrement.
▼B
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 communi­
cation à 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 63
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 ,
▼M3
— position du véhicule,
— une indication s’il se peut que le conducteur
soit en train d’enfreindre les temps de
conduite.
3.20 Échanges de données avec des dispositifs externes supplémentaires
200) L’appareil de contrôle doit également être équipé
d’une interface ITS conformément à l’appen­
dice 13, permettant l’utilisation, par un dispositif
externe, des données enregistrées ou produites
par le tachygraphe ou les cartes tachygraphiques.
En mode opérationnel, le consentement du
conducteur est nécessaire pour la transmission
de données à caractère personnel grâce à l’inter­
face ITS. Cependant, l’exigence relative au
consentement du conducteur ne s’applique pas
aux données du tachygraphe ou de la carte
consultées en mode «contrôle», «entreprise» ou
«étalonnage». Les données et les droits d’accès
fonctionnels pour ces modes sont spécifiés dans
les exigences 12 et 13.
Les exigences suivantes sont applicables aux
données ITS mises à disposition par l’inter­
médiaire de cette interface:
— les données à caractère personnel ne doivent
être disponibles que sous réserve du consen­
tement vérifiable du conducteur, qui accepte
que ses données à caractère personnel puis­
sent quitter le réseau du véhicule.
Un ensemble de données existantes sélection­
nées qui peuvent être disponibles par l’inter­
médiaire de l’interface ITS et la classification
des données en tant que données à caractère
personnel ou que données sans caractère
personnel sont précisées à l’appendice 13.
Des données supplémentaires peuvent aussi
être produites en plus de l’ensemble de
données prévu à l’appendice 13. Le fabricant
de la VU doit classer ces données dans la
catégorie «à caractère personnel» ou «sans
caractère personnel», l’exigence relative au
consentement du conducteur s’appliquant
aux données classées comme étant à caractère
personnel,
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 64
— le consentement 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,
— en aucun cas la présence de l’interface ITS ne
doit perturber ou affecter le fonctionnement
correct et la sécurité de la VU.
Des interfaces supplémentaires d’unité embar­
quée sur véhicule peuvent coexister, à condition
qu’elles respectent pleinement les exigences de
l’appendice 13 en ce qui concerne le consente­
ment du conducteur. L’appareil de contrôle
permet de communiquer le statut du consente­
ment du conducteur aux autres plateformes du
réseau du véhicule et aux dispositifs externes.
Pour le traitement ultérieur, hors du réseau du
véhicule, des données à caractère personnel intro­
duites dans le réseau du véhicule, il ne relève pas
de la responsabilité du fabricant du tachygraphe
de s’assurer que ce traitement de données à
caractère personnel est conforme à la législation
de l’Union applicable en matière de protection
des données.
L’interface ITS doit aussi permettre la saisie des
données pendant la procédure de saisie manuelle
conformément à l’exigence 61, tant pour le
conducteur que pour le convoyeur.
L’interface ITS peut aussi être utilisée pour intro­
duire des informations supplémentaires, en temps
réel, telles que:
— la sélection de l’activité du conducteur,
conformément à l’exigence 46,
— des lieux, conformément à l’exigence 56,
— des conditions particulières, conformément à
l’exigence 62,
— des opérations de chargement/déchargement,
conformément à l’exigence 62 bis.
Ces informations peuvent également être saisies
par l’intermédiaire d’autres interfaces.
201) L’interface de liaison série spécifiée dans
l’annexe I B du règlement (CEE) n o 3821/85,
tel que modifié en dernier lieu, peut continuer à
équiper les tachygraphes afin d’assurer leur
compatibilité avec les équipements de première
génération. La liaison série est classée comme
faisant partie du réseau de véhicules, conformé­
ment à l’exigence 200.
▼B
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 carac­
téristique du véhicule (w),
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 65
— 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'identification du dispositif GNSS externe
stockées dans la mémoire,
— la mise à jour des types et des identifiants de
tous les scellements en place,
▼M3
— 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, réglage du limiteur de vitesse
le cas échéant, et type de charge par défaut,
— le stockage automatique du pays dans lequel
l’étalonnage a été effectué et de la date et de
l’heure auxquelles la position utilisée pour
déterminer ce pays a été fournie par le récep­
teur GNSS.
▼B
203) En outre, la fonction d'étalonnage permet de
rendre impossible l'utilisation de cartes tachygra­
phiques 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.
▼M3
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 dispositif GNSS externe, des données
d’identification nécessaires du dispositif
GNSS externe, y compris le numéro de
série du dispositif GNSS externe.
▼B
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'étalonnage peut
également permettre la saisie des données néces­
saires par d'autres moyens.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 66
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é embarqué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 impul­
sions d'essai — Unité fonctionnelle de contrôle
des entrées/sorties».
▼M3
Lorsque le mode d’entrée/sortie de la ligne de
signalisation d’entrée/sortie d’étalonnage est
actif conformément à la présente exigence,
l’avertissement «Conduite sans carte appropriée»
(exigence 75) ne doit pas être déclenché par
l’unité embarquée sur véhicule.
▼B
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.
▼M3
211) Le réglage de l’heure de l’horloge interne de la
VU est automatiquement réajusté à des inter­
valles de temps variables. Le réajustement auto­
matique de l’heure suivant est déclenché entre
72 h et 168 h après le précédent et après que
la VU a pu accéder à l’heure GNSS au moyen
d’un message de position authentifié valide
conformément à l’appendice 12. Néanmoins, le
réglage de l’heure ne doit jamais entraîner un
réajustement supérieur à la dérive temporelle
maximale accumulée par jour, telle que calculée
par le fabricant de la VU conformément à
l’exigence 41 ter. Si la différence entre l’heure
de l’horloge interne de la VU et l’heure du récep­
teur GNSS est supérieure à la dérive temporelle
maximale accumulée par jour, le réglage de
l’heure doit amener l’horloge interne de la VU
aussi près que possible de l’heure du récepteur
GNSS. Le réglage de l’heure ne peut être
effectué que si le temps fourni par le récepteur
GNSS est obtenu à l’aide de messages de posi­
tion authentifiés comme indiqué à l’appendice 12.
La base temps pour le réglage automatique de
l’heure de l’horloge interne de la VU doit être
l’heure indiquée dans le message de position
authentifié.
212) La fonction de remise à l’heure doit également
permettre de déclencher le réglage de l’heure
courante en mode étalonnage.
Les ateliers peuvent régler l’heure:
— soit en écrivant une valeur temps dans la VU,
en utilisant le service WriteDataByIdentifier
conformément à la section 6.2 de l’appen­
dice 8,
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 67
— soit en demandant un alignement de l’horloge
de la VU sur l’heure fournie par le récepteur
GNSS. Le réglage de l’heure ne peut être
effectué que si le temps fourni par le récep­
teur GNSS est obtenu à l’aide de messages de
position authentifiés. Dans ce dernier cas, le
service RoutineControl doit être utilisé
conformément à la section 8 de l’appen­
dice 8.
▼B
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éra­
tures de – 40 °C.
214) Le tachygraphe doit pouvoir fonctionner correc­
tement dans une gamme d'humidité comprise
entre 10 % et 90 %.
215) Les scellements utilisés dans le tachygraphe intel­
ligent doivent résister aux mêmes conditions que
celles applicables aux composants du tachy­
graphe sur lesquels ils sont apposés.
216) L'appareil de contrôle doit être protégé contre les
surtensions, l'inversion de polarités de son
alimentation électrique 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 immu­
nisé contre ceux-ci.
218) L'appareil de contrôle et le dispositif GNSS
externe doivent être conformes à la réglementa­
tion 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écanique suffisantes, et
présenter des caractéristiques électriques 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écifications techniques applicables en matière
de conception ergonomique.
223) L'appareil de contrôle doit être protégé contre les
détériorations accidentelles.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 68
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'indi­
cation «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
composant 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.
▼M3
3.27 Surveillance des passages aux frontières
226 bis) Cette fonction permet de détecter, lorsque le
véhicule a franchi la frontière d’un pays, le
pays de provenance et le pays de destination.
226 ter) La détection du passage à la frontière se fonde
sur la position mesurée par l’appareil de contrôle
et sur la carte numérique stockée conformément
au point 3.12.19.
226 quater) Les passages aux frontières conduisant à la
présence du véhicule dans un pays pendant une
période inférieure à 120 s ne doivent pas être
enregistrés.
3.28 Mise à jour logicielle
226 quinquies) L’unité embarquée sur véhicule doit prévoir une
fonction pour la mise en œuvre des mises à jour
logicielles lorsque ces mises à jour ne nécessitent
pas la disponibilité de matériel informatique
supplémentaire au-delà des ressources prévues à
l’exigence 226 septies, et que les autorités
d’homologation autorisent les mises à jour logi­
cielles sur la base de l’unité embarquée sur véhi­
cule existante homologuée, conformément à
l’article 12, paragraphe 5, du règlement (UE)
n o 165/2014.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 69
226 sexies) La fonction de mise à jour logicielle est conçue
pour prendre en charge les fonctionnalités
suivantes, lorsqu’elles sont juridiquement
requises:
— la modification des fonctions visées au
point 2.2, à l’exception de la fonction de
mise à jour logicielle elle-même,
— l’ajout de nouvelles fonctions directement
liées à l’application de la législation de
l’Union sur le transport par route,
— la modification des modes d’opération visés
au point 2.3,
— la modification de la structure du fichier,
notamment l’ajout de nouvelles données ou
l’augmentation de la taille du fichier,
— le déploiement de correctifs logiciels pour
traiter les failles de sécurité et les failles logi­
cielles ou les attaques signalées contre les
fonctions de l’appareil de contrôle.
226 septies) L’unité embarquée sur véhicule doit fournir des
ressources matérielles informatiques gratuites
d’au moins 35 % pour les logiciels et les
données nécessaires à la mise en œuvre de
l’exigence 226 sexies et des ressources maté­
rielles informatiques gratuites d’au moins 65 %
pour la mise à jour de la carte numérique sur la
base des ressources matérielles informatiques
requises pour la version 2021 de la carte
NUTS 0.
▼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'entre­
prise» 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
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 70
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'atelier
1. nom du conducteur nom de l'organisme de
contrôle
nom de l'entreprise ou
de l'atelier
2. prénom(s) du conduc­
teur
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 conduc­
teur)
— —
5. b numéro de la carte
6. photographie du con­
ducteur
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étenteur (facultatif)
adresse postale de l'or­
ganisme 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 — 21.08.2023 — 003.002 — 71
233) avec l'accord écrit exprès du détenteur, des infor­
mations 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 impri­
mé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 contre­
façon et la manipulation:
— 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
► (2) M3
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 — 21.08.2023 — 003.002 — 72
237) Les cartes temporaires visées à l'article 26, para­
graphe 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 tachygra­
phiques doivent satisfaire aux exigences de sécu­
rité 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éristiques 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 transmission (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 intersecto­
riels pour les échanges (ISO/IEC 7816-
6:2004 + Cor 1:2006),
— Partie 8: commandes pour des opérations
de sécurité (ISO/IEC 7816-8:2004).
— Les cartes tachygraphiques doivent être testées
conformé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 fonc­
tionner correctement dans toutes les conditions
climatiques normalement observées sur le terri­
toire 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 fonc­
tionner correctement dans une gamme d'humidité
comprise entre 10 % et 90 %.
243) Les cartes tachygraphiques doivent pouvoir fonc­
tionner correctement pendant une période de cinq
ans si elles sont utilisées conformément aux
spécifications environnementales et électriques.
244) En fonctionnement, les cartes tachygraphiques
doivent satisfaire à la réglementation R10 de
l'ECE-ONU, relative à la compatibilité électroma­
gnétique, et doivent être protégées contre les
décharges électrostatiques.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 73
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é mini­
male de stockage des données des divers fichiers
d'application. Les cartes tachygraphiques doivent
pouvoir indiquer à l'appareil de contrôle la capa­
cité réelle de stockage de ces fichiers.
▼M3
246) Toute donnée supplémentaire peut être stockée
sur des cartes tachygraphiques, à condition que
le stockage de ces données soit conforme à la
législation applicable en matière de protection
des données.
▼B
247) Chaque fichier maître (MF) d'une carte tachygra­
phique 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
accessible à la deuxième génération de VU et
qui est seulement présent sur les cartes tachy­
graphiques de deuxième génération.
▼M3
Remarque: la version 2 des cartes de deuxième
génération contient des fichiers élémentaires
supplémentaires dans DF Tachograph_G2.
▼B
L'intégralité des détails relatifs à la structure des
cartes tachygraphiques est spécifiée dans l'appen­
dice 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 intelligentes:
— arrêt d'horloge,
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 74
— 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é.
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'appen­
dice 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 relatifs aux informations sur la
période étendue spécifiés dans l'appendice 2.
4.5.3 Carte de conducteur
4.5.3.1 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 75
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éli­
vrance,
— date de début de validité de la carte, et date
d'expiration.
4.5.3.1.4 Identification du détenteur de la carte
256) La carte de conducteur doit pouvoir stocker les
données suivantes pour l'identification du déten­
teur de la carte:
— nom du détenteur,
— prénom(s) du détenteur,
— date de naissance,
— langue habituelle.
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écharge­
ment 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'appareil 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),
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 76
— 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éne­
ments:
— 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éne­
ment é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 «chevauche­
ment 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éne­
ment 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ôturé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),
— 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éne­
ments de chaque type (soit 36 événements).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 77
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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 78
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).
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 chevauche­
ment 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'insertion/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éhi­
cule, 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:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 79
— date et heure d'ouverture de la session (c.-à-d.
de l'insertion 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)],
— 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.
▼M3
4.5.3.2 L ’ 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 u n i t é s e m b a r q u é e s s u r
v é h i c u l e d e p r e m i è r e g é n é r a t i o n , a c c e s s i b l e p a r
l e s v e r s i o n s 1 e t 2 d e s u n i t é s e m b a r q u é e s s u r
v é h i c u l e d e d e u x i è m e g é n é r a t i o n )
▼B
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 tachygra­
phique.
▼M3
4.5.3.2.1.1 Identification des applications supplémentaires (non accessible par la
version 1 des unités embarquées sur véhicule de deuxième génération)
278 bis) La carte de conducteur doit pouvoir stocker des
données pour l’identification des applications
supplémentaires applicables seulement pour la
version 2.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 80
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éli­
vrance,
— date de début de validité de la carte, et date
d'expiration.
4.5.3.2.4 Identification du détenteur de la carte
281) La carte de conducteur doit pouvoir stocker les
données suivantes pour l'identification du déten­
teur 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écharge­
ment 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élivrance de la carte).
4.5.3.2.7 Données relatives aux événements
Aux fins du présent point, l'heure est enregistrée à la seconde près.
285) La carte de conducteur doit permettre le stockage
des données liées aux événements suivants
détectés par l'appareil de contrôle alors que la
carte est insérée:
— chevauchement temporel (lorsque la carte est
la cause de l'événement),
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 81
— 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
communication à distance,
— absence d'informations de positionnement en
provenance 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éne­
ments:
— 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éne­
ment é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 «chevauche­
ment 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éne­
ment 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ôturé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 — 21.08.2023 — 003.002 — 82
— les données relatives au véhicule doivent
correspondre au véhicule dans lequel la
session a été incorrectement clôturée.
▼M3
287) La carte de conducteur doit permettre le stockage
des données concernant les 12 derniers événe­
ments de chaque type (soit 132 événements).
▼B
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.
▼M3
290) La carte de conducteur doit permettre le stockage
des données relatives aux 24 dernières anomalies
de chaque type (soit 48 anomalies).
▼B
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),
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 83
— situation de la carte (INSÉRÉE, NON
INSÉRÉE),
— activité (CONDUITE, DISPONIBILITÉ,
TRAVAIL, PAUSE/REPOS),
— heure du changement.
▼M3
292) La mémoire de la carte de conducteur doit
permettre le stockage des données relatives à
l’activité du conducteur pendant 56 jours (aux
fins de la présente exigence, l’activité moyenne
d’un conducteur est définie comme 117 change­
ments d’activité par jour).
▼B
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 chevauche­
ment 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'insertion/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éhi­
cule, 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.
▼M3
295) La carte de conducteur doit pouvoir stocker
200 enregistrements de ce type.
▼B
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),
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 84
— 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éter­
mination de la position.
▼M3
297) La mémoire de la carte de conducteur doit
pouvoir stocker 112 enregistrements de ce type.
▼B
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'insertion 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 enre­
gistré 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 85
302) La carte de conducteur doit pouvoir stocker
112 enregistrements de ce type.
▼B
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 embarquées sur véhicule dans lesquelles
la carte a été utilisée:
— la date et l'heure du début de la période
d'utilisation de l'unité embarquée sur le véhi­
cule (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.
▼M3
304) La carte de conducteur doit pouvoir stocker
200 enregistrements de ce type.
▼M1
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.
▼M3
306) La carte de conducteur doit pouvoir stocker
336 enregistrements de ce type.
4.5.3.2.17 Statut d’authentification pour les positions correspondant aux lieux
de début et/ou de fin des périodes de travail journalières (non acces­
sible par la version 1 des unités embarquées sur véhicule de
deuxième génération)
306 bis) La carte de conducteur doit permettre le stockage
de données supplémentaires se rapportant aux
lieux de début et/ou de fin des périodes journa­
lières de travail, saisies par le conducteur confor­
mément au point 4.5.3.2.11:
— la date et l’heure de la saisie, qui doit être
exactement la même que celle stockée dans
EF Places sous DF Tachograph_G2,
— un drapeau indiquant si la position a été
authentifiée.
306 ter) La mémoire de la carte de conducteur doit
pouvoir stocker 112 enregistrements de ce type.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 86
4.5.3.2.18 Statut d’authentification pour les positions correspondant aux lieux
où les trois heures de temps de conduite accumulé sont atteintes
(non accessible par la version 1 des unités embarquées sur véhicule
de deuxième génération)
306 quater) La carte de conducteur doit permettre le stockage
de données supplémentaires se rapportant à la
position du véhicule correspondant au lieu où le
temps de conduite accumulé atteint un multiple
de trois heures conformément au point 4.5.3.2.16:
— la date et l’heure auxquelles le temps de
conduite accumulé atteint un multiple de
trois heures, qui doivent être exactement les
mêmes que celles stockées dans EF
GNSS_Places sous DF Tachograph_G2,
— un drapeau indiquant si la position a été
authentifiée.
306 quinquies) La carte de conducteur doit pouvoir stocker
336 enregistrements de ce type.
4.5.3.2.19 Passages aux frontières (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
306 sexies) La carte de conducteur doit pouvoir stocker les
données suivantes relatives aux passages aux
frontières soit lors de l’insertion de la carte
conformément à l’exigence 147 ter, soit avec la
carte déjà insérée:
— le pays que le véhicule quitte,
— le pays dans lequel le véhicule pénètre,
— la date et l’heure auxquelles le véhicule a
franchi la frontière,
— la position du véhicule au moment du fran­
chissement de la frontière,
— la précision GNSS,
— un drapeau indiquant si la position a été
authentifiée,
— le kilométrage du véhicule.
306 septies) La mémoire de la carte de conducteur doit
permettre le stockage de 1120 enregistrements
de ce type.
4.5.3.2.20 Opérations de chargement/déchargement (non accessible par la
version 1 des unités embarquées sur véhicule de deuxième généra­
tion)
306 octies) La carte de conducteur doit permettre le stockage
des données suivantes concernant les opérations
de chargement/déchargement:
— le type d’opération (chargement, décharge­
ment ou chargement/déchargement simul­
tanés),
— la date et l’heure de l’opération de charge­
ment/déchargement,
— la position du véhicule,
— la précision GNSS, la date et l’heure de
détermination de la position,
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 87
— un drapeau indiquant si la position a été
authentifiée,
— le kilométrage du véhicule.
306 nonies) La carte de conducteur doit pouvoir stocker
1624 opérations de chargement/déchargement.
4.5.3.2.21 Saisies du type de charge (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
306 decies) La carte de conducteur doit permettre le stockage
des données suivantes concernant le type de
charge automatiquement introduites par la VU à
chaque insertion de carte:
— le type de charge introduit (biens ou passa­
gers),
— la date et l’heure de la saisie.
306 undecies) La carte de conducteur doit pouvoir stocker
336 enregistrements de ce type.
4.5.3.2.22 Configurations de la VU (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
306 duodecies) La carte de conducteur doit pouvoir stocker les
paramètres spécifiques du tachygraphe du déten­
teur de la carte.
306 terdecies) La capacité de stockage de la carte de conducteur
pour les paramètres spécifiques du tachygraphe
du détenteur de la carte doit être de 3072 octets.
▼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 cryp­
tographiques, 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éli­
vrance,
— date de début de validité de la carte, et date
d'expiration.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 88
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éten­
teur 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
enregistrements de données relatives au téléchar­
gement d'une carte de la même manière qu'une
carte de conducteur.
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
enregistrements de données relatives aux étalon­
nages 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échargement.
4.5.4.1.7 Données relatives aux événements et aux anomalies
318) La carte d'atelier doit permettre le stockage des
enregistrements de données relatives aux événe­
ments 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).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 89
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
enregistrements de données relatives aux véhi­
cules 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
enregistrements 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.
4.5.4.1.11 Données concernant les sessions pour chaque carte
326) La carte d'atelier doit permettre le stockage des
enregistrements 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
enregistrements 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.
▼M3
4.5.4.2 L ’ 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 u n i t é s e m b a r ­
q u é e s s u r v é h i c u l e d e p r e m i è r e g é n é r a t i o n ,
a c c e s s i b l e p a r l e s v e r s i o n s 1 e t 2 d e s u n i t é s
e m b a r q u é e s s u r v é h i c u l e d e d e u x i è m e g é n é r a ­
t i o n )
▼B
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.
▼M3
4.5.4.2.1.1 Identification des applications supplémentaires (non accessible par la
version 1 des unités embarquées sur véhicule de deuxième génération)
330 bis) La carte d’atelier doit pouvoir stocker des données
pour l’identification des applications supplémen­
taires applicables seulement pour la version 2.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 90
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 cryp­
tographiques, 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éli­
vrance,
— date de début de validité de la carte, et date
d'expiration.
4.5.4.2.4 Identification du détenteur de la carte
334) La carte d'atelier doit permettre le stockage des
données suivantes pour l'identification du déten­
teur 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
enregistrements de données relatives au téléchar­
gement d'une carte de la même manière qu'une
carte de conducteur.
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
enregistrements de données relatives aux étalon­
nages 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),
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 91
— type et identifiant de tous les scellements en
place,
— possibilité pour la VU d'utiliser les cartes
tachygraphiques de première génération (acti­
vées ou non).
▼M3
338) La carte d’atelier doit pouvoir stocker 255 enre­
gistrements de ce type.
▼B
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échargement.
4.5.4.2.7 Données relatives aux événements et aux anomalies
341) La carte d'atelier doit permettre le stockage des
enregistrements de données relatives aux événe­
ments 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.
▼M3
344) La carte d’atelier doit pouvoir stocker des
données concernant l’activité du conducteur
pendant 1 jour comprenant 240 changements
d’activité.
▼B
4.5.4.2.9 Données concernant les véhicules utilisés
345) La carte d'atelier doit permettre le stockage des
enregistrements de données relatives aux véhi­
cules utilisés de la même manière que la carte
de conducteur.
▼M3
346) La carte d’atelier doit pouvoir stocker 8 enregis­
trements de ce type.
4.5.4.2.10 Données se rapportant aux lieux et positions de début/fin des
périodes journalières de travail
347) La carte d’atelier doit permettre le stockage des
enregistrements de données se rapportant aux
lieux et positions de début/fin des périodes jour­
nalières de travail de la même manière qu’une
carte de conducteur.
348) La carte d’atelier doit pouvoir stocker 4 paires
d’enregistrements de ce type.
▼B
4.5.4.2.11 Données concernant les sessions pour chaque carte
349) La carte d'atelier doit permettre le stockage des
enregistrements de données relatives à une
session de carte de la même manière qu'une
carte de conducteur.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 92
4.5.4.2.12 Données relatives aux activités de contrôle
350) La carte d'atelier doit permettre le stockage des
enregistrements 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.
▼M3
352) La carte d’atelier doit pouvoir stocker 8 enregis­
trements 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éhi­
cule 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.
▼M3
354) La carte d’atelier doit pouvoir stocker 24 enregis­
trements 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.
▼M3
356) La carte d’atelier doit pouvoir stocker 4 enregis­
trements de ce type.
4.5.4.2.16 Statut d’authentification pour les positions correspondant aux lieux
de début et/ou de fin des périodes de travail journalières (non acces­
sible par la version 1 des unités embarquées sur véhicule de
deuxième génération)
356 bis) La carte d’atelier doit pouvoir stocker des
données supplémentaires se rapportant aux lieux
de début et/ou de fin des périodes de travail
journalières de la même manière qu’une carte
de conducteur.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 93
356 ter) La mémoire de la carte d’atelier doit pouvoir
stocker 4 paires d’enregistrements de ce type.»;
4.5.4.2.17 Statut d’authentification pour les positions correspondant aux lieux
où les trois heures de temps de conduite accumulé sont atteintes
(non accessible par la version 1 des unités embarquées sur véhicule
de deuxième génération)
356 quater) La carte d’atelier doit permettre le stockage de
données supplémentaires se rapportant à la posi­
tion du véhicule correspondant au lieu où temps
de conduite accumulé atteint un multiple de trois
heures de la même manière qu’une carte de
conducteur.
356 quinquies) La carte d’atelier doit pouvoir stocker 24 enregis­
trements de ce type.
4.5.4.2.18 Passages aux frontières (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
356 sexies) La carte d’atelier doit permettre le stockage de
données relatives aux passages aux frontières de
la même manière que la carte de conducteur.
356 septies) La mémoire de la carte d’atelier doit permettre le
stockage de 4 enregistrements de ce type.
4.5.4.2.19 Opérations de chargement/déchargement (non accessible par la
version 1 des unités embarquées sur véhicule de deuxième génération)
356 octies) La carte d’atelier doit permettre le stockage de
données relatives aux opérations de chargement/
déchargement de la même manière que la carte
de conducteur.
356 nonies) La carte d’atelier doit pouvoir stocker 8 opéra­
tions de chargement, de déchargement ou de
chargement/déchargement simultanés.
4.5.4.2.20 Saisies du type de charge (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
356 decies) La carte d’atelier doit permettre le stockage de
données relatives aux saisies du type de charge
de la même manière que la carte de conducteur.
356 undecies) La carte d’atelier doit pouvoir stocker 4 enregis­
trements de ce type.
4.5.4.2.21 Données d’étalonnage supplémentaires (non accessible par la version 1
des unités embarquées sur véhicule de deuxième génération)
356 duodecies) La carte d’atelier doit pouvoir stocker des
données d’étalonnage supplémentaires applica­
bles seulement pour la version 2:
— les anciennes valeurs de date et d’heure ainsi
que le numéro d’identification du véhicule,
qui doivent être exactement les mêmes que
ceux enregistrés dans EF Calibration sous
DF Tachograph_G2,
— le type de charge par défaut saisi lors de cet
étalonnage,
— le pays dans lequel l’étalonnage a été effectué
et la date et l’heure auxquelles la position
utilisée pour déterminer ce pays a été
fournie par le récepteur GNSS.
356 terdecies) La carte d’atelier doit pouvoir stocker 255 enre­
gistrements de ce type.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 94
4.5.4.2.22 Configurations de la VU (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
356 quaterdecies) La carte d’atelier doit pouvoir stocker les para­
mètres spécifiques du tachygraphe du détenteur
de la carte.
356 quindecies) La capacité de stockage de la carte d’atelier pour
les paramètres spécifiques du tachygraphe du
détenteur de la carte doit être de 3072 octets.
▼B
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éli­
vrance,
— 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,
▼M3
— type du contrôle (affichage et/ou impression
et/ou téléchargement à partir de la VU et/ou à
partir de la carte),
▼B
— période téléchargée (le cas échéant),
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 95
— numéro et autorité nationale d'immatriculation
du véhicule 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.
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.
▼M3
4.5.5.2.1.1 Identification des applications supplémentaires (non accessible par la
version 1 des unités embarquées sur véhicule de deuxième génération)
363 bis) La carte de contrôle doit pouvoir stocker des
données pour l’identification des applications
supplémentaires applicables seulement pour la
version 2.
▼B
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éli­
vrance,
— 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,
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 96
— 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'étalon­
nage sur route),
— période téléchargée (le cas échéant),
— numéro et autorité nationale d'immatriculation
du véhicule 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.
▼M3
4.5.5.2.6 Configurations de la VU (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
368 bis) La carte de contrôle doit pouvoir stocker les
paramètres spécifiques du tachygraphe du déten­
teur de la carte.
368 ter) La capacité de stockage de la carte de contrôle
pour les paramètres spécifiques du tachygraphe
du détenteur de la carte doit être de 3072 octets.
▼B
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éli­
vrance,
— 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 97
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éver­
rouillage 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éhicule,
— 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.
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.
▼M3
4.5.6.2.1.1 Identification des applications supplémentaires (non accessible par la
version 1 des unités embarquées sur véhicule de deuxième généra­
tion)
375 bis) La carte d’entreprise doit pouvoir stocker des
données pour l’identification des applications
supplémentaires applicables seulement pour la
version 2.
▼B
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éli­
vrance,
— 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 98
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éver­
rouillage 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éhicule,
— 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.
▼M3
4.5.6.2.6 Configurations de la VU (non accessible par la version 1 des unités
embarquées sur véhicule de deuxième génération)
380 bis) La carte d’entreprise doit pouvoir stocker les
paramètres spécifiques du tachygraphe du déten­
teur de la carte.
380 ter) La capacité de stockage de la carte d’entreprise
pour les paramètres spécifiques du tachygraphe
du détenteur de la carte doit être de 3072 octets.
▼B
5. INSTALLATION DE L'APPAREIL DE CONTRÔLE
5.1 Installation
381) L'appareil de contrôle neuf est livré non activé
aux installateurs ou aux constructeurs de véhi­
cules, avec tous les paramètres d'étalonnage figu­
rant 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é.
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.
▼M3
383) Avant son activation, l’appareil de contrôle ne doit
ni enregistrer ni stocker les données visées aux
exigences 102 à 133 incluse. Cependant, avant
son activation, l’appareil de contrôle peut enregis­
trer et stocker les événements de tentative d’atteinte
à la sécurité conformément à l’exigence 117, ainsi
que les anomalies affectant l’appareil de contrôle
conformément à l’exigence 118.
▼B
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é confor­
mément au règlement (CE) n o 561/2006.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 99
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éces­
saires entre le capteur de mouvement et l'unité
embarquée sur le véhicule, le cas échéant, inter­
viennent automatiquement avant ou pendant
l'activation.
388) De même, les opérations particulières de
couplage nécessaires entre le dispositif GNSS
externe et l'unité embarquée sur le véhicule, le
cas échéant, interviennent automatiquement avant
ou pendant l'activation.
389) Après l'activation, l'appareil de contrôle applique
pleinement le contrôle d'accès aux fonctions et
aux données.
390) Après son activation, l'appareil de contrôle
communique au dispositif de communication à
distance les données sé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.
▼M3
392) L’installation doit être suivie d’un étalonnage. Le
premier étalonnage ne comporte pas nécessairement
la saisie de l’identification du véhicule (VRN et
État membre) si elle n’est pas connue de l’atelier
agréé qui doit procéder à cet étalonnage. Dans ces
circonstances, il doit être possible pour le proprié­
taire du véhicule, uniquement à ce moment, de
saisir le VRN et l’État membre à l’aide de sa
carte d’entreprise avant l’utilisation du véhicule
conformément au règlement (CE) n o 561/2006
(par exemple à l’aide de commandes via une struc­
ture de menu appropriée de l’interface homme-
machine de l’unité embarquée). Seule l’utilisation
d’une carte d’atelier doit permettre la mise à jour
ou la confirmation de cette saisie.
▼B
393) L'installation d'un dispositif GNSS externe néces­
site son couplage avec la VU et la vérification
ultérieure des informations de position GNSS.
394) L'appareil de contrôle doit être positionné dans le
véhicule de telle manière que le conducteur ait
accès aux fonctions nécessaires depuis son siège.
5.2 Plaquette d'installation
395) ►M3 Après la vérification de l’appareil de
contrôle une fois installé, une plaquette d’instal­
lation, 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’installation doit être
apposée à proximité de la portière du véhicule,
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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 100
396) La plaquette doit comporter au moins les indica­
tions 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 pneuma­
tiques, sous la forme «l = … mm»,
— la taille des pneumatiques,
— la date à laquelle le coefficient caractéristique
du véhicule 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,
▼M3
— le numéro de série du dispositif de commu­
nication à distance, le cas échéant,
▼M1
— 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 mouve­
ment 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’adaptateur 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.
▼M3
— le type de charge par défaut associé au véhi­
cule.
▼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.
▼M1
( 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 — 21.08.2023 — 003.002 — 101
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'installation, 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înerait des modifications indécelables ou
des pertes de données indécelables (cela peut
par exemple s'appliquer 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 dispo­
sitif 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 transmise à l'autorité compétente.
401) Les scellements doivent porter un numéro d'iden­
tification, 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’identi­
fiant unique du fabricant (enregistrement 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, para­
graphe 3 du règlement (UE) n o 165/2014.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 102
Cette marque ne doit pas couvrir le numéro
d'identification du scellement.
▼M1
403) Les fabricants de scellements doivent être enre­
gistrés dans une base de données dédiée
lorsqu’ils obtiennent la certification d’un
modèle de scellement selon la norme EN
16882:2016 et rendre publics leurs numéros
d’identification de scellements par une procédure
établie par la Commission européenne.
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 certi­
fié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 distribu­
teurs doivent conserver des dossiers de traçabilité
complète des scellements vendus pour une utili­
sation dans le cadre du règlement (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 scelle­
ments 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
02016R0799 — FR — 21.08.2023 — 003.002 — 103
6.3 Inspection de l'installation
▼M1
408) Lors de son montage sur un véhicule, l’ensemble
de l’installation (y compris l’appareil de contrôle)
doit respecter les dispositions en matière de tolé­
rances maximales fixées au chapitre 3, points 2.1,
2.2, 2.3 et 3. L’ensemble de l’installation doit
être scellé conformément au chapitre 5.3 et
comprendre un étalonnage.
▼B
6.4 Inspections périodiques
▼M3
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 carac­
téristique du véhicule ou de la circonférence
effective des pneumatiques, ou lorsque l’horloge
UTC est fausse de plus de 5 minutes, ou lorsque
le numéro d’immatriculation a changé, et au
moins une fois tous les deux ans (24 mois).
▼B
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'exigence 396 et de la plaque signalé­
tique définie par l'exigence 225
— taille des pneumatiques et circonférence
effective des pneumatiques,
— absence de dispositifs de manipulation atta­
chés à l'appareil,
— placement correct et bon état des scellements,
validité de leurs numéros d'identification (le
fabricant de scellements est référencé dans la
base de données de la CE) et correspondance
entre leurs numéros d'identification et les
marquages des plaquettes d'installation (voir
exigence 401).
▼M3
— identificateur de version de la carte numé­
rique stockée le plus récent.
410 bis) En cas de détection d’une manipulation par les
autorités nationales compétentes, le véhicule peut
être envoyé à un atelier agréé à des fins de rééta­
lonnage de l’appareil de contrôle.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 104
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 fabricants 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'identification 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'homologation du capteur de mouvement,
s'ils sont imprimés sur le corps du capteur
de mouvement, correspondent aux informa­
tions enregistrées dans la mémoire de l'appa­
reil 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 manipula­
tion. 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
remplacement préventif des scellements dont
l'installation s'effectue 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 condi­
tions d'essai standard:
— véhicule à vide en ordre de marche,
— pression des pneumatiques conforme aux
instructions du fabricant,
— usure des pneumatiques dans les limites auto­
risé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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 105
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'entreprise de transport appro­
prié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 dysfonc­
tionnement 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 conser­
vent une copie de chaque certificat délivré,
pendant au moins deux ans.
7. DÉLIVRANCE DES CARTES
Les processus mis en place par les États membres pour la délivrance
des cartes sont 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 renouvellement
fixé à «0».
418) Les numéros de carte de toutes les cartes tachy­
graphiques 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équen­
tiel.
419) Une carte tachygraphique délivrée en remplace­
ment 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 remplace­
ment 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 renouvelle­
ment 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 adminis­
tratives, 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 applicables à
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'installa­
teur ou de l'agent de contrôle selon ce que déci­
dent les États membres.
424) Les États membres échangent des données par
voie électronique 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 106
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 additionnel é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'accorderont 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 tachygra­
phique faisant l’objet de la demande d’homolo­
gation.
▼B
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'appareil. Cette autorité doit
confirmer au fabricant l'extension de l'homologa­
tion, ou bien elle peut demander une mise à jour
ou une confirmation des certificats de fonction­
nement, de sécurité et/ou d'interopérabilité.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 107
429) Les procédures pour la mise à jour in situ du
logiciel de l’appareil de contrôle doivent être
approuvées par l’autorité qui a accordé l’homo­
logation pour l’appareil de contrôle concerné. La
mise à jour logicielle ne doit ni modifier ni
supprimer aucune donnée relative à l’activité du
conducteur stockée dans l’appareil de contrôle.
Le logiciel ne peut être mis à jour que sous la
responsabilité du fabricant de l’appareil de
contrôle.
430) L’homologation des modifications de logiciels
visant à mettre à jour un appareil de contrôle
préalablement homologué ne peut être refusée si
ces modifications ne s’appliquent qu’à des fonc­
tions 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.
▼B
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 certifié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é refu­
sent de certifier un nouvel appareil en invoquant
l'obsolescence des mécanismes de sécurité,
l'homologation continue à être accordée unique­
ment lorsqu'il n'existe aucune autre solution
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 perti­
nents de produits en attente d'une homologation
et la documentation associée requis par les labo­
ratoires désignés pour effectuer les essais fonc­
tionnels, 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 informations 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'appendice 9.
437) L'autorité d'homologation délivre le certificat de
fonctionnement. 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ésul­
tats obtenus.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 108
438) Le certificat de fonctionnement de tout compo­
sant d'appareil de contrôle mentionne aussi les
numéros d'homologation des autres composants
d'appareil de contrôle compatibles homologués
qui sont testés en vue d'obtenir cette certification.
439) Le certificat de fonctionnement d'un composant
de l'appareil de contrôle doit également indiquer
la norme ISO ou CEN en vertu de laquelle
l'interface fonctionnelle a été certifiée.
8.4 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 chronologique 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 correspon­
dant.
La date de l'enregistrement de la demande est
notifiée au fabricant.
▼M3
443) Aucun essai d’interopérabilité ne doit être réalisé
par le laboratoire sur un appareil de contrôle ou
une carte tachygraphique qui n’a pas réussi une
analyse de vulnérabilité dans le cadre d’une
évaluation de la sécurité ainsi qu’une évaluation
fonctionnelle, sauf dans les circonstances excep­
tionnelles décrites dans l’exigence 432.
▼B
444) Tout fabricant demandant des essais d'interopéra­
bilité s'engage à laisser au laboratoire chargé des
essais l'ensemble du matériel et de la documen­
tation 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 validité.
446) Les tests d'interopérabilité doivent couvrir toutes
les générations d'appareils de contrôle ou de
cartes tachygraphiques encore en usage.
▼M3
447) Le certificat d’interopérabilité ne doit être délivré
par le laboratoire au fabricant qu’après la réussite
de tous les essais d’interopérabilité requis et
après que le fabricant a démontré qu’un certificat
fonctionnel et un certificat de sécurité valables
ont été délivrés pour le produit, sauf dans les
circonstances exceptionnelles décrites dans
l’exigence 432.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 109
448) En cas de résultat négatif des essais d'interopéra­
bilité sur un ou plusieurs appareils de contrôle ou
cartes tachygraphiques, le certificat d'interopéra­
bilité n'est pas délivré tant que le fabricant
concerné n'a pas apporté les modifications néces­
saires et que l'appareil ou la carte n'a pas satisfait
à 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 fabri­
cant 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'homologa­
tion 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 labora­
toire chargé des essais d'interopérabilité lors de la
délivrance de ce certificat au fabricant.
454) Le laboratoire compétent pour les essais d'inter­
opé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 tachygraphiques:
— pour lesquels une demande d'essais d'inter­
opé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éli­
vré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 — 21.08.2023 — 003.002 — 110
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érabilité 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érabilité 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 corres­
pondants, les causes des anomalies d'interopéra­
bilité, 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'interopérabilité, décide du ou des appa­
reils et des cartes auxquels est délivré un certi­
ficat d'interopérabilité définitif, en précisant les
raisons de son choix.
459) Toute demande d'essais d'interopérabilité enregis­
trée par le laboratoire entre la fin de la période de
quatre mois suivant la délivrance du premier
certificat d'interopérabilité provisoire 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 — 21.08.2023 — 003.002 — 111
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
▼M3
2.11 bis CardBorderCrossing
2.11 ter CardBorderCrossingRecord
▼B
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 112
2.24 bis CardLoadTypeEntries
2.24 ter CardLoadTypeEntryRecord
2.24 quater CardLoadUnloadOperations
2.24 quinquies CardLoadUnloadRecord
▼B
2.25. CardMACertificate
2.26. CardNumber
▼M3
2.26 bis CardPlaceAuthDailyWorkPeriod
▼B
2.27. CardPlaceDailyWorkPeriod
2.28. CardPublicKey
2.29. CardPublicKey
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 certificat.
2.44. CertificateRequestID
2.45. CertificationAuthorityKID
2.46. CompanyActivityData
2.47. CompanyActivityType
2.48. CompanyCardApplicationIdentification
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 113
2.48 bis CompanyCardApplicationIdentificationV2
▼B
2.49. CompanyCardHolderIdentification
2.50. ControlCardApplicationIdentification
▼M3
2.50 bis ControlCardApplicationIdentificationV2
▼B
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
▼M3
2.60 bis DownloadInterfaceVersion
▼B
2.61. DriverCardApplicationIdentification
▼M3
2.61 bis DriverCardApplicationIdentificationV2
▼B
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
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 114
2.74. FullCardNumberAndGeneration
2.75. Generation
2.76. GeoCoordinates
2.77. GNSSAccuracy
▼M1
2.78. GNSSAccumulatedDriving
2.79. GNSSAccumulatedDrivingRecord
▼M3
2.79 bis GNSSAuthAccumulatedDriving
2.79 ter GNSSAuthStatusADRecord
2.79 quater GNSSPlaceAuthRecord
▼B
2.80. GNSSPlaceRecord
2.81. HighResOdometer
2.82. HighResTripDistance
2.83. HolderName
▼M3
2.84. Réservé pour une utilisation future
▼B
2.85. K-ConstantOfRecordingEquipment
2.86. KeyIdentifier
2.87. KMWCKey
2.88. Language
2.89. LastCardDownload
▼M3
2.89 bis LengthOfFollowingData
▼B
2.90. LinkCertificate
▼M3
2.90 bis LoadType
▼B
2.91. L-TyreCircumference
2.92. MAC
2.93. ManualInputFlag
2.94. ManufacturerCode
2.95. ManufacturerSpecificEventFaultData
2.96. MemberStatePublicKey
2.97. MemberStateCertificateRecordArray
2.98. MemberStatePublicKey
2.99. Name
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 115
2.100. NationAlpha
2.101. Code numérique national
▼M3
2.101 bis NoOfBorderCrossingRecords
▼B
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
▼M3
2.111 bis NoOfLoadUnloadRecords
▼B
2.112. NoOfSpecificConditionRecords
▼M3
2.112 bis NoOfLoadTypeEntryRecords
▼B
2.113. OdometerShort
2.114. OdometerValueMidnight
▼M3
2.114 bis OperationType
▼B
2.115. OdometerValueMidnightRecordArray
2.116. OverspeedNumber
▼M3
2.116 bis PlaceAuthRecord
2.116 ter PlaceAuthStatusRecord
▼B
2.117. PlaceRecord
▼M3
2.117 bis PositionAuthenticationStatus
▼B
2.118. PreviousVehicleInfo
2.119. PublicKey
2.120. RecordType
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 116
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
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 117
2.152. SpecificConditionRecord
2.153. SpecificConditions
2.154. SpecificConditionType
2.155. Speed
2.156. SpeedAuthorised
2.157. SpeedAverage
2.158. SpeedMax
▼M3
2.158 bis TachographCardsGen1Suppression
▼B
2.159. TachographPayload
▼M1
2.160. Réservé pour une utilisation future
▼B
2.161. TDesSessionKey
2.162. TimeReal
2.163. TyreSize
2.164. VehicleIdentificationNumber
2.165. VehicleIdentificationNumberRecordArray
2.166. VehicleRegistrationIdentification
▼M3
2.166 bis VehicleRegistrationIdentificationRecordArray
▼B
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 118
2.179. VuCardRecord
2.180. VuCardRecordArray
2.181. VuCertificate
2.182. VuCertificateRecordArray
2.183. VuCompanyLocksData
2.184. VuCompanyLocksRecord
2.185. VuCompanyLocksRecordArray
▼M3
2.185 bis VuConfigurationLengthRange
▼B
2.186. VuControlActivityData
2.187. VuControlActivityRecord
2.188. VuControlActivityRecordArray
2.189. VuDataBlockCounter
2.190. VuDetailedSpeedBlock
2.191. VuDetailedSpeedBlockRecordArray
2.192. VuDetailedSpeedData
▼M3
2.192 bis VuDigitalMapVersion
▼B
2.193. VuDownloadablePeriod
2.194. VuDownloadablePeriodRecordArray
2.195. VuDownloadActivityData
2.196. VuDownloadActivityDataRecordArray
2.197. VuEventData
2.198. VuEventRecord
2.199. VuEventRecordArray
2.200. VuFaultData
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 119
2.201. VuFaultRecord
2.202. VuFaultRecordArray
▼M1
2.203. VuGNSSADRecord
▼M3
2.203 bis VuBorderCrossingRecord
2.203 ter VuBorderCrossingRecordArray
▼M1
2.204. VuGNSSADRecordArray
▼M3
2.204 bis VuGnssMaximalTimeDifference
▼B
2.205. VuIdentification
2.206. VuIdentificationRecordArray
2.207. VuITSConsentRecord
2.208. VuITSConsentRecordArray
▼M3
2.208 bis VuLoadUnloadRecord
2.208 ter VuLoadUnloadRecordArray
▼B
2.209. VuManufacturerAddress
2.210. VuManufacturerName
2.211. VuManufacturingDate
2.212. VuOverSpeedingControlData
2.213. VuOverSpeedingControlDataRecordArray
2.214. VuOverSpeedingEventData
2.215. VuOverSpeedingEventRecord
2.216. VuOverSpeedingEventRecordArray
2.217. VuPartNumber
2.218. VuPlaceDailyWorkPeriodData
2.219. VuPlaceDailyWorkPeriodRecord
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 120
2.220. VuPlaceDailyWorkPeriodRecordArray
2.221. VuPublicKey
2.222. VuPublicKey
▼M3
2.222 bis VuRtcTime
▼B
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
▼M3
2.234 bis WorkshopCardApplicationIdentificationV2
2.234 ter WorkshopCardCalibrationAddData
2.234 quater WorkshopCardCalibrationAddDataRecord
▼B
2.235. WorkshopCardCalibrationData
2.236. WorkshopCardCalibrationRecord
2.237. WorkshopCardHolderIdentification
2.238. WorkshopCardPIN
2.239. W-VehicleCharacteristicConstant
2.240. VuPowerSupplyInterruptionRecord
2.241. VuPowerSupplyInterruptionRecordArray
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 121
2.242. VuSensorExternalGNSSCoupledRecordArray
2.243. VuSensorPairedRecordArray
3. DÉFINITIONS DES PLAGES DE VALEURS ET DE DIMEN­
SIONS
4. JEUX DE CARACTÈRES
5. ENCODAGE
6. IDENTIFICATEURS D'OBJETS ET IDENTIFICATEURS
D'APPLICATIONS
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
conformité 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émorisé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 — 21.08.2023 — 003.002 — 122
ISO/IEC 7816-5 Cartes d'identification — Cartes à circuit
intégré — Partie 5: Enregistrement des four­
nisseurs d'application.
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éci­
fication de la notation de base. 2008 + Recti­
ficatif technique 1: 2012 et Rectificatif tech­
nique 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
+ Rectificatif technique 1: 2006.
TR-03110-3 BSI/ANSSI Rapport technique TR-03110-3,
Mécanismes 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
▼M3
Quel que soit le type de données considéré parmi ceux qui
suivent, un contenu «inconnu» ou «sans objet» entraînera l’attri­
bution d’une valeur par défaut résultant du remplissage de
l’élément de données concerné au moyen d’hex octets «FF»,
sauf disposition contraire.
Tous les types de données servent aux applications de généra­
tion 1 ou 2, sauf disposition contraire. Les types de données
utilisés uniquement pour les applications de génération 2,
version 2 sont indiqués.
Pour les types de données de carte utilisés pour les applications
de génération 1 ou 2, la taille indiquée dans le présent appen­
dice 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 applica­
tions de génération 1 et de génération 2.
Les types de données de carte non définis pour les cartes de
génération 1 ne sont pas stockés dans l’application de généra­
tion 1 des cartes de génération 2. En particulier:
— les numéros d’homologation stockés dans l’application de
génération 1 des cartes de génération 2 sont tronqués aux
8 premiers caractères si nécessaire,
— seule la condition «TRAJET EN FERRY/TRAIN début»
d’une condition spécifique «TRAJET EN FERRY/TRAIN»
doit être stockée dans l’application de génération 1 des cartes
de génération 2.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 123
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
«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 écou­
lé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)
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 124
«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 écou­
lées depuis 00h00 le jour considéré.
Remarque
En cas de «retrait de la carte»:
— «s» s'applique et indique le lecteur dont la carte a été
extraite,
— «c» doit être mis à 0,
— «p» doit être mis à 1,
— «aa» doit coder l'activité en cours sélectionnée au même
moment.
Rien ne s'oppose à ce que les bits «c» et «aa» du mot (enregistré
sur une carte) soient écrasés à la suite d'une saisie manuelle pour
refléter l'entrée de données 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 carac­
tères spécifié.
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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 125
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.
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 «Charac­
terStringType» (type de chaîne de caractères).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 126
BCDString a recours à une notation «hstring». Le chiffre hexa­
dé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 approprié 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.
Attribution de valeur:
Génération 1:
«00»H valeur réservée
«01»H enregistrement de paramètres d'étalon­
nage connus, au moment de l'activation
de la VU,
«02»H premier étalonnage de la VU après son
activation,
«03»H premier étalonnage de l'unité embarquée
sur le véhicule considéré,
«04»H inspection périodique,
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 acti­
vité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 maxi­
male correspond à la longueur de la CHAÎNE D'OCTETS conte­
nant ces relevés (cf. CardActivityLengthRange, appendice 2,
paragraphe 4) Lorsque ces données correspondent au relevé
quotidien le plus ancien, la valeur de l'activityPreviousRecord­
Length doit être mise à 0.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 127
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é.
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
considéré.
activityChangeInfo indique le jeu de données ActivityChan­
geInfo se rapportant au conducteur et au jour considérés. Cette
chaîne d'octets ne peut contenir plus de 1440 valeurs (un chan­
gement d'activité par minute). Ce jeu comprend toujours l'Acti­
vityChangeInfo 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.
▼M3
2.11 bis CardBorderCrossings
Génération 2, version 2:
Informations stockées sur une carte de conducteur ou d’atelier et
se rapportant aux passages aux frontières du véhicule lorsque
celui-ci a franchi la frontière d’un pays (exigences 306 septies
et 356 septies de l’annexe IC).
borderCrossingPointerNewestRecord désigne l’indice du plus
récent relevé de passage à la frontière sur la carte.
Attribution de valeur: nombre correspondant au numérateur du
relevé de passage à la frontière, commençant par une série de
«0» pour la première occurrence d’un relevé de passage à la
frontière dans la structure considérée.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 128
cardBorderCrossingRecords désigne l’ensemble des relevés de
passage à la frontière.
2.11 ter CardBorderCrossingRecord
Génération 2, version 2:
Informations stockées sur une carte de conducteur ou d’atelier et
se rapportant aux passages aux frontières du véhicule lorsque
celui-ci a franchi la frontière d’un pays (exigences 147 ter,
306 sexies et 356 sexies de l’annexe IC).
countryLeft est le pays quitté par le véhicule, ou «aucune
information disponible» conformément à l’exigence 147 ter de
l’annexe IC. «Reste du monde» (code numérique national
«FF»H) doit être utilisé lorsque l’unité embarquée sur véhicule
n’est pas en mesure de déterminer le pays où se trouve le
véhicule (par exemple lorsque le pays actuel ne figure pas sur
les cartes numériques stockées).
countryEntered est le pays dans lequel le véhicule est entré ou
le pays dans lequel le véhicule est situé au moment de l’inser­
tion de la carte. «Reste du monde» (code numérique national
«FF»H) doit être utilisé lorsque l’unité embarquée sur véhicule
n’est pas en mesure de déterminer le pays où se trouve le
véhicule (par exemple lorsque le pays actuel ne figure pas sur
les cartes numériques stockées).
gnssPlaceAuthRecord contient les informations relatives à la posi­
tion du véhicule, lorsque l’unité embarquée sur véhicule a constaté
que le véhicule avait franchi la frontière d’un pays, ou «aucune
information disponible» conformément à l’exigence 147 ter de
l’annexe IC, et son statut d’authentification.
vehicleOdometerValue est la valeur affichée par le compteur kilo­
métrique lorsque l’unité embarquée sur véhicule a détecté que le
véhicule avait franchi la frontière d’un pays, ou «aucune informa­
tion disponible» conformément à l’exigence 147 ter de
l’annexe IC.
▼B
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'iden­
tification du circuit intégré (CI) de cette carte (exigence 249 de
l'annexe 1C). Le icSerialNumber associé au icManufacturingRe­
ferences 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.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 129
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»
2.15. CardControlActivityDataRecord
Informations enregistrées sur une carte de conducteur ou d'atelier
et se rapportant au dernier contrôle auquel le conducteur consi­
dé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 consi­
déré.
controlDownloadPeriodBegin et controlDownloadPeriodEnd
indiquent 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 130
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.
activityPointerNewestRecord 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 le plus récent
que comporte la chaîne activityDailyRecords. La valeur maxi­
male correspond à la longueur de la chaîne.
activityDailyRecords indique l'espace disponible affecté à
l'enregistrement de données relatives aux activités du conducteur
(structure de données: 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 utilisation, le début de l'enregistrement du premier
relevé coïncide avec le premier octet de la chaîne. Les relevés
suivants sont enregistrés à la fin du précédent. Lorsque la chaîne
est saturée, l'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 activityDailyRecord), 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'activityPreviousRecordLength 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 131
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’exception 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 corres­
pond à celui des EventFaultType rangés par ordre croissant.
cardEventRecords consiste en un jeu de relevés d’événements
correspondant à un type d’événement donné (ou à cette catégorie
d’événements dans laquelle se rangent les tentatives d’atteinte à
la sécurité).
Génération 2:
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’exception 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 corres­
pond à celui des EventFaultType rangés par ordre croissant.
cardEventRecords consiste en un jeu de relevés d’événements
correspondant à un type d’événement donné (ou à cette catégorie
d’événements 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éne­
ment.
eventEndTime indique la date et l'heure de la fin de l'événe­
ment.
eventVehicleRegistration indique le VRN ainsi que l'État
membre d'immatriculation du véhicule dans lequel l'événement
considéré s'est produit.
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 132
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.
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'immatriculation 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'iden­
tification 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
ExtendedSerialNumber.
cardApprovalNumber indique le numéro d'homologation de la
carte.
cardPersonaliserID indique l'ID individuelle de la carte cryptée
par le ManufacturerCode.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 133
embedderIcAssemblerId fournit des informations à propos de
l'intégrateur/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'iden­
tification 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.
cardExpiryDate indique la date d'expiration de la carte.
▼M3
2.24 bis CardLoadTypeEntries
Génération 2, version 2:
Informations stockées sur une carte de conducteur ou d’atelier et
se rapportant aux saisies du type de charge lorsque la carte est
insérée dans une unité embarquée sur véhicule (exigences
306 undecies et 356 undecies de l’annexe IC).
loadTypeEntryPointerNewestRecord désigne l’indice du plus
récent relevé de type de charge sur la carte.
Attribution de valeur: nombre correspondant au numérateur du
relevé de type de charge, commençant par une série de «0» pour
la première occurrence d’un relevé de type de charge dans la
structure considérée.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 134
cardLoadTypeEntryRecords indique le jeu de relevés conte­
nant la date et l’heure de la saisie et le type de charge introduit.
2.24 ter CardLoadTypeEntryRecord
Génération 2, version 2:
Informations stockées sur une carte de conducteur ou d’atelier et
se rapportant aux changements de type de charge saisis à l’inser­
tion de la carte dans l’unité embarquée sur véhicule (exigences
306 decies et 356 decies de l’annexe IC).
timeStamp est la date et l’heure auxquelles le type de charge a
été saisi.
loadTypeEntered est le type de charge saisi.
2.24 quater CardLoadUnloadOperations
Génération 2, version 2:
Informations enregistrées sur une carte de conducteur ou
d’atelier et se rapportant aux opérations de chargement/déchar­
gement du véhicule (exigences 306 nonies et 356 nonies de
l’annexe IC).
loadUnloadPointerNewestRecord est l’indice du plus récent
relevé de chargement/déchargement sur la carte.
Attribution de valeur: nombre correspondant au numérateur du
relevé de chargement/déchargement, commençant par une série
de «0» pour la première occurrence d’un relevé de chargement/
déchargement dans la structure considérée.
cardLoadUnloadRecords désigne le jeu de relevés contenant
l’indication du type d’opération effectuée (chargement, déchar­
gement ou chargement et déchargement simultanés), la date et
l’heure de saisie de l’opération de chargement/déchargement, les
informations relatives à la position du véhicule et le kilométrage
du véhicule.
2.24 quinquies CardLoadUnloadRecord
Génération 2, version 2:
Informations enregistrées sur une carte de conducteur ou
d’atelier et se rapportant aux opérations de chargement/déchar­
gement du véhicule (exigences 306 octies et 356 octies de
l’annexe IC).
timeStamp est la date et l’heure du début de l’opération de
chargement/déchargement.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 135
operationType est le type d’opération saisi (chargement,
déchargement ou chargement/déchargement simultanés).
gnssPlaceAuthRecord contient les informations relatives à la
position du véhicule.
vehicleOdometerValue est la valeur affichée par le compteur
kilométrique au début de l’opération de chargement/décharge­
ment.
▼B
2.25. CardMACertificate
Génération 2:
Certificat associé à la clé publique d'une carte destinée à son
authentification 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.
▼M3
2.26 bis CardPlaceAuthDailyWorkPeriod
Génération 2, version 2:
Informations enregistrées sur une carte de conducteur ou
d’atelier, indiquant le statut d’authentification des lieux de
début et/ou de fin de la période de travail journalière (exigences
306 ter et 356 ter de l’annexe IC).
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 136
placeAuthPointerNewestRecord désigne l’indice du plus récent
relevé de statut d’authentification de lieu.
Attribution de valeur: nombre correspondant au numérateur du
relevé de statut d’authentification de lieu, commençant par une
série de «0» pour la première occurrence d’un relevé de statut
d’authentification de lieu dans la structure considérée.
placeAuthStatusRecords indique le jeu de relevés contenant le
statut d’authentification des lieux saisis.
▼B
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 journaliè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 consi­
dérée.
placeRecords indique le jeu de relevés contenant les données
relatives aux lieux entrés.
2.28. CardPublicKey
Génération 1:
Clé privée d'une carte.
2.29. CardPublicKey
Clé publique d'une carte.
▼M1
2.30. CardRenewalIndex
Indice de renouvellement d’une carte [définition i)].
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 137
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'appen­
dice 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.
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.
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 138
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). Attri­
bution 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
▼M3
bb’HIndex 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 les applications de génération 1
«00»H pour la version 1 des applications de
génération 2
«01»H pour la version 2 des applications de
génération 2
▼B
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:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 139
vehicleOdometerBegin indique la valeur affichée par le
compteur kilométrique d'un véhicule donné au début de la
période d'utilisation considérée.
vehicleOdometerEnd indique la valeur affichée par le compteur
kilométrique d'un véhicule donné à la fin de la période d'utili­
sation considérée.
vehicleFirstUse indique la date et l'heure du début de la période
d'utilisation du véhicule.
vehicleLastUse indique la date et l'heure de la fin de la période
d'utilisation du véhicule.
vehicleRegistration indique le VRN ainsi que l'État membre où
le véhicule 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'identifica­
tion 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éhicule actualisé par le système.
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 occurrence d'un relevé de véhicule dans la structure
considérée.
cardVehicleRecords indique le jeu de relevés contenant des
informations relatives aux véhicules utilisés.
2.39. CardVehicleUnitRecord
Génération 2:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 140
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éhi­
cule (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éhicule.
deviceID identifie le type d'unité embarquée sur le véhicule d'un
fabricant. 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
▼M3
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éhicule
associées au détenteur de la carte (exigences 304 et 352 de
l’annexe IC).
▼B
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 informations 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:
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).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 141
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
correspondant.
Attribution de valeur: «01h» pour cette version.
certificationAuthorityReference identifie l'organisme de certi­
fication 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 certificat.
certificateEndOfValidity indique la date d'expiration adminis­
trative 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'applica­
tion tachygraphique.
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
EquipmentType. 0 si le certificat émane de l'un des États
membres.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 142
Génération 2:
tachographApplicationID indique les 6 octets les plus signifi­
catifs de l'identificateur d'application (AID) pour carte tachygra­
phique 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 certi­
ficat et spécifié pour la génération 2.
Attribution de valeur: en conformité avec le type de données
EquipmentType.
2.44. CertificateRequestID
Identification individuelle d'une demande de certificat. Elle peut
également 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 certificat.
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 distinc­
tion 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'orga­
nisme de certification.
nationAlpha indique le code alphanumérique national de l'orga­
nisme de certification.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 143
keySerialNumber est un numéro de série permettant de faire la
distinction entre les différentes clés de l'organisme de certifica­
tion si certaines clés font l'objet de modifications.
additionalInfo est un champ de deux octets autorisant l'intro­
duction de codes supplémentaires (propres à l'organisme de
certification).
caIdentifier est un identificateur permettant de faire la distinc­
tion entre l'identificateur d'une clé associée à un organisme de
certification et d'autres identificateurs de clé.
Attribution de valeur: «01h».
2.46. CompanyActivityData
Informations enregistrées sur une carte d'entreprise et se rappor­
tant aux activités menées avec cette carte (exigence 373 et 379
de l'annexe 1C).
companyPointerNewestRecord indique l'indice du dernier
relevé d'activité 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'entre­
prise 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'entreprise.
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éverrouillés.
downloadPeriodBegin et downloadPeriodEnd indiquent, le
cas échéant, la période téléchargée à partir de la VU.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 144
2.47. CompanyActivityType
Code indiquant une activité menée par une entreprise recourant à
l'utilisation de sa carte d'entreprise.
2.48. CompanyCardApplicationIdentification
Informations enregistrées sur une carte d'entreprise et se rappor­
tant à 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
application.
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.
▼M3
2.48 bis CompanyCardApplicationIdentificationV2
Génération 2, version 2:
Informations enregistrées sur une carte d’entreprise et se rappor­
tant à l’identification de l’application de la carte (exigence 375 bis
de l’annexe IC).
lengthOfFollowingData est le nombre d’octets suivant dans le
relevé.
vuConfigurationLengthRange est le nombre d’octets contenus
dans une carte tachygraphique, disponibles pour stocker les
configurations de la VU.
▼B
2.49. CompanyCardHolderIdentification
Informations enregistrées sur une carte d'entreprise et se rappor­
tant à l'identification du détenteur de la carte (exigence 372 et
378 de l'annexe 1C).
companyName indique le nom de l'entreprise du titulaire.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 145
companyAddress indique l'adresse de l'entreprise du titulaire.
cardHolderPreferredLanguageindique la langue de travail
préférentielle du titulaire.
2.50. ControlCardApplicationIdentification
Informations enregistrées sur une carte de contrôle et se rappor­
tant à 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
application.
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.
▼M3
2.50 bis ControlCardApplicationIdentificationV2
Génération 2, version 2:
Informations enregistrées sur une carte de contrôle et se rappor­
tant à l’identification de l’application de la carte (exigence 363 bis
de l’annexe IC).
lengthOfFollowingData est le nombre d’octets suivant dans le
relevé.
vuConfigurationLengthRange est le nombre d’octets contenus
dans une carte tachygraphique, disponibles pour stocker les
configurations de la VU.
▼B
2.51. ControlCardControlActivityData
Informations enregistrées sur une carte de contrôle et se rappor­
tant 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 146
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 asso­
cié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
indiquent, 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.
cardHolderPreferredLanguageindique la langue de travail
préférentielle 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 147
«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 acti­
vité 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 acti­
vité 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 acti­
vité 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 activité de contrôle.
«xxx»B RFU.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 148
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). 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 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
maximale est égale à 9 999, la numérotation recommençant par
le numéro 0. Lors de la première entrée en vigueur d'une carte,
le compteur correspondant est à zéro.
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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 149
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'utilisées dans le protocole de téléchargement.
recordType indique le type de relevé (DateOfDayDownloaded).
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 le jeu de date et d'heure sur les relevés de
téléchargements.
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.
▼M3
2.60 bis DownloadInterfaceVersion
Génération 2, version 2:
Code indiquant la version de l’interface de téléchargement d’une
unité embarquée sur véhicule.
Attribution de valeur: «aabb»H:
«aa»H «00»H: inutilisé,
«01»H: Unité embarquée sur véhicule de génération 2,
«bb»H «00»H: inutilisé,
«01»H: version 2 de l’unité embarquée sur véhicule de généra­
tion 2.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 150
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).
Génération 1:
typeOfTachographCardId spécifie le type de la carte mise en
application.
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 conditions particulières que la carte est susceptible de mémo­
riser.
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
02016R0799 — FR — 21.08.2023 — 003.002 — 151
2.61 bis DriverCardApplicationIdentificationV2
Génération 2, version 2:
Informations enregistrées sur une carte de conducteur et se
rapportant à l’identification de l’application de la carte
(exigence 278 bis de l’annexe IC).
lengthOfFollowingData est le nombre d’octets suivant dans le
relevé.
noOfBorderCrossingRecords indique le nombre de relevés de
passages aux frontières que la carte de conducteur est suscep­
tible de mémoriser.
noOfLoadUnloadRecords indique le nombre de relevés de
chargement/déchargement que la carte de conducteur est suscep­
tible de mémoriser.
noOfLoadTypeEntryRecords indique le nombre de saisies de
type de charge que la carte de conducteur est susceptible de
mémoriser.
vuConfigurationLengthRange est le nombre d’octets contenus
dans une carte tachygraphique, disponibles pour stocker les
configurations de la VU.
▼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'annexe 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.
cardHolderPreferredLanguageindique la langue de travail
préférentielle du titulaire.
▼M3
2.63. DSRCSecurityData
Génération 2:
Pour la définition de ce type de données, cf. appendice 11.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 152
2.64. EGFCertificate
Génération 2:
Certificat associé à la clé publique d'un dispositif GNSS destiné
à l'authentification 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.
▼M3
Génération 2
Attribution de valeur: conforme à la norme ISO/IEC8824-1.
▼B
2.67. EquipmentType
Code permettant de faire la distinction entre différents types
d'équipement pour l'application tachygraphique.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 153
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éra­
tion 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’équipement concerné. Pour indiquer le certi­
ficat à 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 — 21.08.2023 — 003.002 — 154
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'occurrence
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 — 21.08.2023 — 003.002 — 155
anomalies affectant une carte
absence d'informations complémentaires
RFU
RFU
propre au fabricant
▼M3
Génération 2, version 1:
▼M1 é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 — 21.08.2023 — 003.002 — 156
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.
▼M3
Génération 2, version 2:
«0x»H événements généraux,
«00»H absence d’informations complémentaires,
«01»H insertion d’une carte non valable,
«02»H conflit de carte,
«03»H chevauchement temporel,
«04»H conduite sans carte appropriée,
«05»H insertion de carte en cours de conduite,
«06»H dernière session incorrectement clôturée,
«07»H excès de vitesse,
«08»H coupure d’alimentation électrique,
«09»H erreur sur les données de mouvement,
«0A»H conflit concernant le mouvement du véhi­
cule,
«0B»H conflit temporel (GNSS contre l’horloge
interne de la VU),
«0C»H erreur de communication avec le dispositif
de communication à distance,
«0D»H absence d’informations de positionnement
en provenance du récepteur GNSS,
«0E»H erreur de communication avec le dispositif
GNSS externe,
«0F»H anomalie GNSS,
«1x»H tentatives d’atteinte à la sécurité en rapport
avec l’unité embarquée sur véhicule,
«10»H absence d’informations complémentaires,
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 157
«11»H défaut d’authentification du capteur de
mouvement,
«12»H défaut d’authentification d’une carte
tachygraphique,
«13»H remplacement sans autorisation du capteur
de mouvement,
«14»H défaut d’intégrité affectant la saisie de
données sur la carte,
«15»H défaut d’intégrité affectant les données utili­
sateur mémorisées,
«16»H erreur de transfert de données internes,
«17»H ouverture illicite d’un boîtier,
«18»H sabotage du matériel,
«19»H détection de violation du dispositif GNSS,
«1A»H défaut d’authentification du dispositif GNSS
externe,
«1B»H expiration du certificat du dispositif GNSS
externe,
«1C»H Divergence entre les données de mouve­
ment et les données enregistrées relatives à
l’activité du conducteur,
«1D»H à «1F»H RFU,
«2x»H tentatives d’atteinte à la sécurité en rapport
avec le capteur de mouvement,
«20»H absence d’informations complémentaires,
«21»H échec d’une authentification,
«22»H défaut d’intégrité affectant les données
mémorisées,
«23»H erreur de transfert de données internes,
«24»H ouverture illicite d’un boîtier,
«25»H sabotage du matériel,
«26»H à «2F»H RFU,
«3x»H anomalies affectant l’appareil de contrôle,
«30»H absence d’informations complémentaires,
«31»H anomalie interne affectant la VU,
«32»H anomalie affectant l’imprimante,
«33»H anomalie affectant l’affichage,
«34»H anomalie affectant le téléchargement,
«35»H anomalie affectant le capteur de mouvement,
«36»H récepteur du dispositif GNSS interne,
«37»H dispositif GNSS externe,
«38»H dispositif de communication à distance,
«39»H interface ITS,
«3A»H anomalie du capteur interne,
«3B»H à «3F»H RFU,
«4x»H anomalies affectant une carte,
«40»H absence d’informations complémentaires,
«41»H à «4F»H RFU,
«50»H à «7F»H RFU,
«80»H à «FF»H propre au fabricant.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 158
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 scelle­
ment. Attribution de valeur: voir l’enregistrement dans la base
de données qui sera géré par la Commission européenne (voir
https://dtc.jrc.ec.europa.eu).
sealIdentifier désigne l’identifiant du scellement, unique pour le
fabricant. Attribution de valeur: numéro alphanumérique,
unique dans le domaine du fabricant conformément à la norme
[ISO8859-1].
▼B
2.72. ExtendedSerialNumber
Identification individuelle d'un équipement. Ce numéro peut
également faire office d'identificateur de clé publique d'équipe­
ment.
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).
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éservé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
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 159
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 tachygra­
phique 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
2.76. GeoCoordinates
▼M3
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 longitude. Les codages ± DD et
± DDD indiquent respectivement les degrés et MM.M, les
minutes. La longitude et la latitude d’une position inconnue
sont représentées par Hex «7FFFFF» (Decimal 8388607).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 160
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éfini­
tion 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, relatives à 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éra­
teur 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 consi­
dérée.
gnssContinuousDrivingRecords désigne le jeu de relevés
contenant la date et l’heure lorsque le temps de conduite accu­
mulé atteint un multiple de trois heures, ainsi que les informa­
tions relatives à la position du véhicule.
2.79. GNSSAccumulatedDrivingRecord
Génération 2:
Informations enregistrées sur une carte de conducteur ou
d’atelier, relatives à 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 161
gnssPlaceRecord contient les informations relatives à la posi­
tion 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.
▼M3
2.79 bis GNSSAuthAccumulatedDriving
Génération 2, version 2:
Informations enregistrées sur une carte de conducteur ou
d’atelier et indiquant le statut d’authentification des positions
GNSS du véhicule lorsque le temps de conduite accumulé
atteint un multiple de trois heures (exigences 306 quinquies
et 356 quinquies de l’annexe IC).
gnssAuthADPointerNewestRecord est l’indice du plus récent
relevé de statut d’authentification des positions GNSS.
Attribution de valeur: nombre correspondant au numérateur du
relevé de statut d’authentification des positions GNSS, commen­
çant par une série de «0» pour la première occurrence d’un
relevé de statut d’authentification des positions GNSS dans la
structure considérée.
gnssAuthStatusADRecords 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 le statut d’authentification
de la position GNSS.
2.79 ter GNSSAuthStatusADRecord
Génération 2, version 2:
Informations enregistrées sur une carte de conducteur ou
d’atelier, indiquant le statut d’authentification d’une position
GNSS du véhicule lorsque le temps de conduite accumulé
atteint un multiple de trois heures (exigences 306 quater
et 356 quater de l’annexe IC). D’autres informations relatives
à la position GNSS elle-même sont stockées dans un autre relevé
(voir 2.79 GNSSAccumulatedDrivingRecord).
timeStamp désigne la date et l’heure auxquelles le temps de
conduite accumulé atteint un multiple de trois heures (et qui
sont la même date et la même heure que dans le GNSSAccu­
mulatedDrivingRecord correspondant).
authenticationStatus désigne le statut d’authentification de la
position GNSS lorsque le temps de conduite accumulé atteint un
multiple de trois heures.
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 162
2.79 quater GNSSPlaceAuthRecord
Génération 2, version 2:
Informations relatives à la position GNSS du véhicule
(exigences 108, 109, 110, 296, 306 bis, 306 quater, 306 sexies,
306 octies, 356 bis, 356 quater, 356 sexies et 356 octies de
l’annexe IC).
timeStamp indique la date et l’heure auxquelles la position
GNSS du véhicule a été déterminée.
gnssAccuracy précise le degré d’exactitude des données de
positionnement GNSS.
geoCoordinates indique l’emplacement enregistré à l’aide du
dispositif GNSS.
authenticationStatus désigne le statut d’authentification de la
position GNSS au moment où celle-ci est déterminée.
▼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 posi­
tion 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.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 163
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 indivi­
duelle, holderSurname contient les mêmes données que compa­
nyName, workshopName ou controlBodyName.
holderFirstNames indique le(s) prénom(s) et initiale(s) du
titulaire.
▼M3
2.84. Réservé pour une utilisation future
▼B
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'exploitation comprise entre 0 et 64 255 imp/km.
▼M1
2.86. KeyIdentifier
Identificateur unique d’une clé publique permettant de la dési­
gner 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é embarquée sur véhicule (en cas de méconnaissance du
numéro de série de l’unité embarquée, lors de l’élaboration du
certificat).
La troisième option permet de désigner la clé publique d’un État
membre.
▼B
2.87. KMWCKey
Génération 2:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 164
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.
appendice 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 minus­
cules, en conformité avec la norme ISO 639.
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.
▼M3
2.89 bis LengthOfFollowingData
Génération 2, version 2:
Indicateur de longueur pour les relevés extensibles.
Attribution de valeur: cf. appendice 2.
▼B
2.90. LinkCertificate
Génération 2:
Certificat du lien entre les clés couplées conformément à l'auto­
rité de certification racine européenne.
▼M3
2.90 bis LoadType
Génération 2, version 2:
Code identifiant un type de charge introduit.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 165
Attribution de valeur:
«00»H type de charge non défini,
«01»H biens,
«02»H passagers,
«03»H .. «FF»H RFU.
▼B
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 labo­
ratoire chargé des essais d'interopérabilité.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 166
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éhi­
cules.
manufacturerCode identifie le fabricant de l'unité embarquée
sur véhicule.
manufacturerSpecificErrorCode est un code d'erreur propre au
fabricant.
2.96. MemberStatePublicKey
Certificat de la clé publique d'un État membre délivré par l'orga­
nisme 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).
Attribution 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 167
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é.
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 (Natio­
nAlpha).
Toute modification ou mise à jour des spécifications Natio­
nAlpha ou NationNumeric ne peut intervenir qu'après consulta­
tion, par le laboratoire désigné, des fabricants d'unités embar­
quées de tachygraphe numérique et intelligent homologuées.
▼M3
2.101 bis NoOfBorderCrossingRecords
Génération 2, version 2:
Nombre de relevés de passage aux frontières qu’une carte de
conducteur ou d’atelier est susceptible de mémoriser.
Attribution de valeur: cf. appendice 2.
▼B
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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 168
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.
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'entre­
prise est susceptible de mémoriser.
Attribution de valeur: cf. appendice 2.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 169
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
▼M1
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.
▼M3
2.111 bis NoOfLoadUnloadRecords
Génération 2, version 2:
Nombre de relevés de chargement/déchargement qu’une carte est
susceptible de mémoriser.
Attribution 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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 170
2.112 bis NoOfLoadTypeEntryRecords
Génération 2, version 2:
Nombre de relevés de saisie de type de charge qu’une carte de
conducteur ou d’atelier est susceptible de mémoriser.
Attribution de valeur: cf. appendice 2. ▼B
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.
▼M3
2.114 bis OperationType
Génération 2, version 2:
Code identifiant un type d’opération saisi.
Attribution de valeur:
«00»H RFU,
«01»H opération de chargement,
«02»H opération de déchargement,
«03»H opération de chargement/déchargement simul­
tanés,
«04»H .. «FF»H RFU.
▼B
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é (OdometerValueMid­
night). Attribution de valeur: Cf. RecordType
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 171
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.
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.
▼M3
2.116 bis PlaceAuthRecord
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 de
l’annexe IC).
Génération 2, version 2:
entryTime indique la date et l’heure de la saisie des données.
entryTypeDailyWorkPeriod indique le type de saisie.
dailyWorkPeriodCountry indique le pays saisi.
dailyWorkPeriodRegion indique la région saisie.
vehicleOdometerValue indique la valeur affichée par le
compteur kilométrique à l’heure de la saisie du lieu entré.
entryGNSSPlaceAuthRecord indique le lieu enregistré, le
statut d’authentification GNSS et l’heure.
2.116 ter PlaceAuthStatusRecord
Génération 2, version 2:
Informations enregistrées sur une carte de conducteur ou
d’atelier, indiquant le statut d’authentification d’un lieu de
début ou de fin d’une période de travail journalière (exigences
306 bis et 356 bis de l’annexe IC). D’autres informations rela­
tives au lieu lui-même sont stockées dans un autre relevé
(voir 2.117 PlaceRecord).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 172
entryTime indique une date et une heure liées à la saisie (qui
sont la même date et la même heure que dans le PlaceRecord
correspondant).
authenticationStatus désigne le statut d’authentification de la
position GNSS enregistrée.
▼B
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 kilomé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.
▼M3
2.117 bis PositionAuthenticationStatus
Génération 2, version 2:
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 173
Attribution de valeur (cf. appendice 12):
«00»H non authentifié (voir appendice 12, exigence
GNS_39),
«01»H authentifié (voir appendice 12, exigence
GNS_39),
«02»H .. «FF»H RFU.
▼B
2.118. PreviousVehicleInfo
Informations relatives au véhicule précédemment utilisé par un
conducteur 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.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 174
Attribution de valeur:
► (1) M1
► (2) M3
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,
►M3 VuBorderCrossingRecord,
VuLoadUnloadRecord,
Identification et immatriculation du véhicule
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 — 21.08.2023 — 003.002 — 175
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érabilité.
2.122. ►C4 RegionNumeric ◄
Référence alphabétique aux différentes régions d'un pays déter­
miné.
Génération 1:
Attribution de valeur:
Génération 2:
Les codes RegionNumeric sont consignés sur une liste main­
tenue à jour sur le site web du laboratoire désigné pour effectuer
les essais d'interopé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 — 21.08.2023 — 003.002 — 176
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 sealRe­
cords.
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 associé.
extendedSealIdentifier désigne l'identificateur du scellé associé
à l'équipement concerné.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 177
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é embar­
qué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 dispositif 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 — 21.08.2023 — 003.002 — 178
sensorSerialNumber désigne le numéro de série étendu du
dispositif GNSS externe.
sensorApprovalNumber désigne le numéro d'homologation du
dispositif GNSS externe.
sensorSCIdentifier indique l'identificateur du composant de
sécurité du dispositif GNSS externe.
sensorOSIdentifier indique l'identificateur du système d'exploi­
tation 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 dispo­
sitif 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é
embarquée sur le véhicule actuellement couplée avec le dispo­
sitif GNSS externe.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 179
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
dispositif 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 — 21.08.2023 — 003.002 — 180
sensorOSIdentifier indique l'identificateur du système d'exploi­
tation 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éhicule 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 — 21.08.2023 — 003.002 — 181
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é embar­
qué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
mouvement 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é embar­
quée sur véhicule.
sensorPairingDateFirst indique la date du premier couplage
entre une unité sur véhicule et le capteur de mouvement actuel­
lement 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é embar­
qué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
mouvement 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 — 21.08.2023 — 003.002 — 182
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échargement.
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énement 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 considé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 — 21.08.2023 — 003.002 — 183
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
particuliè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 parti­
culières dans la structure considérée.
specificConditionRecords indique le jeu de relevés contenant
des informations 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 — 21.08.2023 — 003.002 — 184
2.155. Speed
Vitesse du véhicule (km/h).
Attribution de valeur: kilomètres à l'heure dans une plage
d'exploitation 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.
▼M3
2.158 bis TachographCardsGen1Suppression
Génération 2, version 2:
Capacité d’une VU de deuxième génération à utiliser la première
génération de cartes de conducteur, de contrôle et d’entreprise
(cf. appendice 15, MIG_002).
Attribution de valeur:
«0000»H La VU peut utiliser la génération 1
de cartes tachygraphiques (valeur
par défaut),
«A5E3»H La VU ne peut pas utiliser les cartes
tachygraphiques de génération 1,
Toutes les autres valeurs Inutilisé.
▼B
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:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 185
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).
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é (VehicleIdentification­
Number). Attribution de valeur: Cf. RecordType
recordSize indique la taille des VehicleIdentificationNumber
exprimée en octets.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 186
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éhi­
cules.
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éhicule.
vehicleRegistrationNumber indique le numéro d'immatricula­
tion du véhicule (VRN).
▼M3
2.166 bis VehicleRegistrationIdentificationRecordArray
Génération 2, version 2:
Identification du véhicule plus les métadonnées telles qu’utili­
sées dans le protocole de téléchargement.
recordType indique le type de relevé (VehicleRegistrationIden­
tification). Attribution de valeur: cf. RecordType.
recordSize indique la taille des VehicleRegistrationIdentification
exprimée en octets.
noOfRecords désigne le nombre de relevés dans les relevés
définis.
records désigne le jeu des identifications des véhicules.
▼B
2.167. Numéro d'immatriculation du véhicule
Numéro d'immatriculation du véhicule (VRN). Le numéro
d'immatriculation 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 — 21.08.2023 — 003.002 — 187
vehicleRegNumber indique un VRN encodé à l'aide du jeu de
caractères spécifié.
Attribution de valeur: propre à chaque pays.
2.168. VehicleRegistrationNumberRecordArray
▼M3
Génération 2, version 1:
▼B
Immatriculation du véhicule plus les métadonnées tels qu'utili­
sées dans le protocole de téléchargement.
recordType indique le type de relevé (VehicleRegistration­
Number). 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:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 188
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux changements d'activité
ainsi qu'aux changements 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.
noOfActivityChanges indique le nombre de mots que comporte
le jeu ActivityChangeInfos.
activityChangeInfos indique le jeu de mots ActivityChangeInfo
enregistré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é embar­
quée sur véhicule et se rapportant aux changements d'activité
ainsi qu'aux changements 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 ActivityChangeInfo 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:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 189
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:
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux étalonnages successifs
de l'appareil d'enregistrement (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é embar­
quée sur véhicule et se rapportant aux étalonnages successifs
de l'appareil d'enregistrement (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'étalonnage.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 190
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.
kConstantOfRecordingEquipment indique la constante de
l'appareil de contrôle.
lTyreCircumference indique la circonférence effective des
pneumatiques.
tyreSize indique la désignation de la dimension des pneuma­
tiques 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
correspondant au type spécifié dans le champ CalibrationPurpose
et auquel l'organisme d'inspection agréé doit procéder.
▼M3
Génération 2, version 1:
▼B
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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 191
Génération 2, version 2:
Outre la génération 1, l’élément de données suivant est utilisé:
sensorSerialNumber indique le numéro de série du capteur de
mouvement couplé avec l’unité embarquée sur véhicule à la fin
de l’étalonnage,
sensorGNSSSerialNumber désigne le numéro de série du
dispositif GNSS externe couplé avec l’unité embarquée sur véhi­
cule à la fin de l’étalonnage (le cas échéant),
rcmSerialNumber désigne le numéro de série du dispositif de
communication à distance couplé avec l’unité embarquée sur
véhicule à la fin de l’étalonnage (le cas échéant),
sealDataVu fournit des informations relatives aux scellements
liés aux différents composants du véhicule.
byDefaultLoadType désigne le type de charge par défaut du
véhicule (présent uniquement dans la version 2).
calibrationCountry indique le pays dans lequel l’étalonnage a
été effectué.
calibrationCountryTimestamp indique la date et l’heure
auxquelles la position utilisée pour déterminer le pays d’étalon­
nage a été fournie par le récepteur GNSS.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 192
2.175. VuCalibrationRecordArray
Génération 2:
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux étalonnages successifs
de l'appareil d'enregistrement (exigence 119 et 120, annexe 1C).
recordType indique le type de relevé (VuCalibrationRecord).
Attribution 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é embar­
quée sur véhicule et se rapportant aux cycles d'insertion et de
retrait des cartes de conducteur ou d'atelier dans le lecteur appro­
prié de cette unité embarquée (exigence 081, annexe 1B et
exigence 103, annexe 1C).
noOfIWRecords désigne le nombre de relevés dans le jeu
vuCardIWRecords
vuCardIWRecords désigne un jeu de relevés portant sur les
cycles d'insertion et de retrait des cartes.
2.177. VuCardIWRecord
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux cycles d'insertion et de
retrait des cartes de conducteur ou d'atelier dans le lecteur appro­
prié de cette unité embarquée (exigence 081, annexe 1B et
exigence 102, annexe 1C).
Génération 1:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 193
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 enregis­
trés sur la carte.
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 affi­
ché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'identi­
fier 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 fullCard­
Number, 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:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 194
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux cycles d'insertion et de
retrait des cartes de conducteur ou d'atelier dans le lecteur appro­
prié de cette unité embarqué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.
noOfRecords désigne le nombre de relevés dans les relevés
définis.
records désigne un jeu de relevés portant sur les cycles d'inser­
tion et de retrait des cartes.
▼M1
2.179. VuCardRecord
Génération 2:
Informations enregistrées dans la mémoire d’une unité embar­
qué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_Application_Identification sous le fichier spécialisé
DF_Tachograph_G2.
cardNumber tel qu’extrait du fichier élémentaire FE_Identifica­
tion 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é embar­
qué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).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 195
recordType indique le type de relevé (VuCardRecord). Attri­
bution 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 tachy­
graphiques utilisées par la VU.
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
protocole de téléchargement.
recordType indique le type de relevé (VuCertificate). Attribu­
tion 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é embar­
qué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
verrouillages d'entreprise.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 196
2.184. VuCompanyLocksRecord
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant à un verrouillage d'entreprise
déterminé (exigence 104, annexe 1B; exigence 128, annexe 1C).
Génération 1:
lockInTime, lockOutTime indiquent les dates et heures de
verrouillage et de déverrouillage.
companyName, companyAddress indiquent les nom et adresse
de l'entreprise 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 company­
CardNumber, 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é embar­
quée sur véhicule et se rapportant aux verrouillages d'entreprise
(exigence 128, annexe 1C).
recordType indique le type de relevé (VuCompanyLocksRe­
cord). Attribution 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'entre­
prise.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 197
2.185 bis. VuConfigurationLengthRange
Génération 2, version 2:
Nombre d’octets dans une carte tachygraphique, disponibles
pour stocker les configurations de la VU.
Attribution de valeur: cf. appendice 2.
▼B
2.186. VuControlActivityData
Génération 1:
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux contrôles exécutés à
l'aide de cette VU (exigence 102, annexe 1B).
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é embar­
qué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.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 198
downloadPeriodEndTime indique l'heure de fin de la période
téléchargée, en cas de téléchargement.
Génération 2:
La structure de données de génération 2 n'utilise pas control­
CardNumber, 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é embar­
quée sur véhicule et se rapportant aux contrôles exécutés à
l'aide de cette VU (exigence 126, annexe 1C).
recordType indique le type de relevé (VuControlActivityRe­
cord). Attribution 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'acti­
vité 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
maximale 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é embar­
qué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).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 199
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 mesurées toutes les secondes pendant la minute qui a
commencé à la speedBlockBeginDate (incluse).
2.191. VuDetailedSpeedBlockRecordArray
Génération 2:
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant à l'évolution de la vitesse
du véhicule.
recordType indique le type de relevé (VuDetailedSpeedBlock).
Attribution de valeur: Cf. RecordType
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 instan­
tanée.
2.192. VuDetailedSpeedData
Génération 1:
Informations enregistrées dans la mémoire d'une unité embar­
qué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.
▼M3
2.192 bis VuDigitalMapVersion
Génération 2, version 2:
Version de la carte numérique stockée dans l’unité embarquée
sur véhicule (exigence 133 undecies de l’annexe IC).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 200
Attribution de valeur: comme indiqué sur le site web sécurisé
prévu à cet effet et mis à disposition par la Commission euro­
péenne (exigence 133 duodecies de l’annexe IC).
▼B
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 acti­
vité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).
Attribution de valeur: Cf. RecordType
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é embar­
qué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.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 201
fullCardNumber identifie la carte utilisée pour autoriser le télé­
chargement.
companyOrWorkshopName indique le nom de l'entreprise ou
de l'atelier.
Génération 2:
La structure de données de génération 2 n'utilise pas fullCard­
Number, mais plutôt les éléments suivants.
fullCardNumberAndGeneration identifie la carte utilisée pour
autoriser 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é (VuDownloadActivity­
Data). 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.
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é embar­
qué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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 202
2.198. VuEventRecord
Informations enregistrées dans la mémoire d'une unité embar­
qué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énement considéré.
eventBeginTime indique la date et l'heure du début de l'événe­
ment.
eventEndTime indique la date et l'heure de la fin de l'événe­
ment.
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 simi­
laires survenus le même jour.
Cette séquence s'utilise pour tous les événements, sauf ceux du
type excès de vitesse.
Génération 2:
Outre la génération 1, les éléments de données suivants sont
utilisés:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 203
manufacturerSpecificEventFaultData contient des informa­
tions complémentaires propres au fabricant et se rapportant à
l'événement.
La structure de données de génération 2 n'utilise pas cardNum­
berDriverSlotBegin, cardNumberCodriverSlotBegin, cardNum­
berDriverSlotEnd 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
eventBeginTime 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é embar­
qué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). Attri­
bution de valeur: Cf. RecordType
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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 204
2.200. VuFaultData
Génération 1:
Informations enregistrées dans la mémoire d'une unité embar­
qué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é embar­
qué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 — 21.08.2023 — 003.002 — 205
Génération 2:
Outre la génération 1, l'élément de données suivant est utilisé:
manufacturerSpecificEventFaultData contient des informa­
tions complémentaires propres au fabricant et se rapportant à
l'événement.
La structure de données de génération 2 n'utilise pas cardNum­
berDriverSlotBegin, cardNumberCodriverSlotBegin, cardNum­
berDriverSlotEnd 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'anomalie.
cardNumberAndGenCodriverSlotEnd identifie la carte insérée
dans le lecteur réservé au convoyeur ainsi que sa génération, à la
fin de l'anomalie.
2.202. VuFaultRecordArray
Génération 2:
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant à diverses anomalies
(exigence 118, annexe 1C).
recordType indique le type de relevé (VuFaultRecord). Attri­
bution 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 — 21.08.2023 — 003.002 — 206
2.203. VuGNSSADRecord
▼M3
Génération 2, version 1:
▼M1
Informations enregistrées dans la mémoire d’une unité embar­
qué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 posi­
tion 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.
▼M3
Génération 2, version 2:
Informations enregistrées dans la mémoire d’une unité embar­
qué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 de l’annexe IC).
Dans la version 2 de la génération 2, au lieu de gnssPlaceRe­
cord, gnssPlaceAuthRecord est utilisé, ce dernier contenant
également le statut d’authentification GNSS.
2.203 bis VuBorderCrossingRecord
Génération 2, version 2:
Informations enregistrées dans la mémoire d’une unité embar­
quée sur véhicule et se rapportant aux passages aux frontières du
véhicule lorsque celui-ci a franchi la frontière d’un pays
(exigences 133 bis et 133 ter de l’annexe IC).
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 207
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.
countryLeft indique le pays quitté par le véhicule, sur la base
de la dernière position disponible avant la détection du franchis­
sement de la frontière. «Reste du monde» (code numérique
national «FF»H) doit être utilisé lorsque l’unité embarquée sur
véhicule n’est pas en mesure de déterminer le pays où se trouve
le véhicule (par exemple lorsque le pays actuel ne figure pas sur
les cartes numériques stockées).
countryEntered indique le pays dans lequel le véhicule est
entré. «Reste du monde» (code numérique national «FF»H)
doit être utilisé lorsque l’unité embarquée sur véhicule n’est
pas en mesure de déterminer le pays où se trouve le véhicule
(par exemple lorsque le pays actuel ne figure pas sur les cartes
numériques stockées).
gnssPlaceAuthRecord contient des informations relatives à la
position du véhicule lors de la détection du franchissement de la
frontière, et son statut d’authentification.
vehicleOdometerValue est la valeur affichée par le compteur
kilométrique lorsque l’unité embarquée sur véhicule a détecté
que le véhicule avait franchi la frontière d’un pays.
2.203 ter VuBorderCrossingRecordArray
Génération 2, version 2:
Informations enregistrées dans la mémoire d’une unité embar­
quée sur véhicule et se rapportant aux passages aux frontières du
véhicule (exigence 133 quater de l’annexe IC).
recordType indique le type de relevé (VuBorderCrossingRe­
cord). Attribution de valeur: cf. RecordType.
recordSize indique la taille des VuBorderCrossingRecord
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 passage aux frontières.
▼M1
2.204. VuGNSSADRecordArray
Génération 2:
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 208
Informations enregistrées dans la mémoire d’une unité embar­
qué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 accu­
mulé GNSS.
▼M3
2.204 bis VuGnssMaximalTimeDifference
Génération 2, version 2:
La différence maximale entre l’heure réelle et l’heure de
l’horloge RTC de la VU, sur la base de la dérive temporelle
maximale spécifiée à l’annexe IC, exigence 041, transmise par
l’unité embarquée sur véhicule à un dispositif GNSS externe, cf.
exigence GNS_3 octies de l’appendice 12.
▼B
2.205. VuIdentification
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant à l'identification de l'unité
embarquée (exigence 075, annexe 1B; exigences 93 et 121,
annexe 1C).
Génération 1:
vuManufacturerName indique le nom du fabricant de l'unité
embarqué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é embar­
quée sur véhicule.
vuSerialNumber indique le numéro de série de l'unité embar­
quée sur véhicule.
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 209
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é
embarquée sur véhicule.
vuApprovalNumber indique le numéro d'homologation de
l'unité embarquée sur véhicule.
▼M3
Génération 2:
Outre la génération 1, les éléments de données suivants sont
utilisés:
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.
VuDigitalMapVersion indique la version de la carte numérique
stockée dans l’unité embarquée sur véhicule (présente unique­
ment dans la version 2).
▼B
2.206. VuIdentificationRecordArray
Génération 2:
VuIdentification plus les métadonnées tels qu'utilisés dans le
protocole de téléchargement.
recordType indique le type de relevé (VuIdentification). Attri­
bution de valeur: Cf. RecordType
recordSize indique la taille des VuIdentification exprimée en
octets.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 210
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 Intelli­
gent 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 Intelli­
gent Transport Systems (exigence 200, annexe 1C).
recordType indique le type de relevé (VuITSConsentRecord).
Attribution 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.
▼M3
2.208 bis VuLoadUnloadRecord
Génération 2, version 2:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 211
Informations enregistrées dans la mémoire de l’unité embarquée
sur véhicule et se rapportant à une opération de chargement/
déchargement saisie (exigences 133 sexies, 133 septies
et 133 octies de l’annexe IC).
timeStamp est la date et l’heure auxquelles l’opération de char­
gement/déchargement a été saisie.
operationType est le type d’opération saisi (chargement,
déchargement ou chargement/déchargement simultanés).
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.
gnssPlaceAuthRecord contient les informations relatives à la
position du véhicule et son statut d’authentification.
vehicleOdometerValue désigne le kilométrage lié à l’opération
de chargement/déchargement.
2.208 ter VuLoadUnloadRecordArray
Génération 2, version 2:
Informations enregistrées dans la mémoire d’une unité embar­
quée sur véhicule et se rapportant à une opération de charge­
ment/déchargement saisie (exigence 133 nonies de l’annexe IC).
recordType indique le type de relevé (VuLoadUnloadRecord).
Attribution de valeur: cf. Type de relevé.
recordSize indique la taille des VuLoadUnloadRecord 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 d’opérations de chargement/
déchargement.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 212
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é embar­
qué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 — 21.08.2023 — 003.002 — 213
recordType indique le type de relevé (VuOverSpeedingControl­
Data). 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é embar­
quée sur véhicule et se rapportant aux événements du type
excès de vitesse (exigence 094, annexe 1B).
noOfVuOverSpeedingEvents indique le nombre d'événements
répertorié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é embar­
quée sur véhicule et se rapportant aux événements du type
excès de vitesse (exigence 094, annexe 1B; exigence 117,
annexe 1C).
eventType indique le type d'événement.
eventRecordPurpose indique la raison de l'enregistrement de
l'événement considéré.
eventBeginTime indique la date et l'heure du début de l'événe­
ment.
eventEndTime indique la date et l'heure de la fin de l'événe­
ment.
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 — 21.08.2023 — 003.002 — 214
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 simi­
laires survenus le même jour.
Génération 2:
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux événements du type
excès de vitesse (exigence 094, annexe 1B; exigence 117,
annexe 1C).
La structure de données de génération 2 n'utilise pas cardNum­
berDriverSlotBegin, 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é embar­
quée sur véhicule et se rapportant aux événements du type
excès de vitesse (exigence 117, annexe 1C).
recordType indique le type de relevé (VuOverSpeedingEven­
tRecord). 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 — 21.08.2023 — 003.002 — 215
2.218. VuPlaceDailyWorkPeriodData
Génération 1:
Informations enregistrées dans la mémoire d'une unité embar­
qué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é embar­
qué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é.
▼M3
Génération 2, version 1:
▼B
Informations enregistrées dans la mémoire d'une unité embar­
qué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 fullCard­
Number, 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.
▼M3
Génération 2, version 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 de
l’annexe 1B; exigences 108 et 110 de l’annexe 1C).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 216
La structure de données de la version 2 de la génération 2
n’utilise pas placeRecord, mais plutôt l’élément suivant:
placeAuthRecord contient les informations relatives au lieu
saisi, à la position enregistrée, au statut d’authentification
GNSS et à l’heure à laquelle la position a été déterminée.
▼B
2.220. VuPlaceDailyWorkPeriodRecordArray
Génération 2:
Informations enregistrées dans la mémoire d'une unité embar­
qué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é (VuPlaceDailyWorkPerio­
dRecord). 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.
▼M3
2.222 bis VuRtcTime
Génération 2, version 2:
L’heure de la RTC de la VU, transmise par la VU à un dispo­
sitif GNSS externe, voir exigence GNS_3 septies de l’appen­
dice 12.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 217
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é.
2.225. VuSoftwareIdentification
Informations enregistrées dans la mémoire d'une unité embar­
qué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éhi­
cule.
Attribution de valeur: Non-spécifié.
2.227. VuSpecificConditionData
Génération 1:
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux conditions particulières.
noOfSpecificConditionRecords indique le nombre des relevés
répertoriés dans le jeu specificConditionRecords.
specificConditionRecords indique un jeu de relevés relatifs à
des conditions particulières.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 218
2.228. VuSpecificConditionRecordArray
Génération 2:
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux conditions particulières
(exigence 130, annexe 1C).
recordType indique le type de relevé (SpecificConditionRe­
cord). Attribution 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 parti­
culières.
2.229. VuTimeAdjustmentData
Génération 1:
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux remises à l'heure exécu­
tées hors du cadre d'un étalonnage complet (exigence 101,
annexe 1B).
noOfVuTimeAdjRecords indique le nombre des relevés réper­
torié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é embar­
quée sur véhicule et se rapportant aux remises à l'heure exécu­
tées hors du cadre d'un étalonnage complet (exigence 101,
annexe 1B; exigences 124 et 125, annexe 1C).
Génération 1:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 219
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 workshop­
CardNumber, 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.
2.233. VuTimeAdjustmentRecordArray
Génération 2:
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux remises à l'heure exécu­
tées hors du cadre d'un étalonnage complet (exigences 124 et 125,
annexe 1C).
recordType indique le type de relevé (VuTimeAdjustmentRe­
cord). 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'identification de l'application de la carte (exigences 307 et 330
de l'annexe 1C).
Génération 1:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 220
typeOfTachographCardId spécifie le type de la carte mise en
application.
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.
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 conditions particulières que la carte est susceptible de mémo­
riser.
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.
▼M3
2.234 bis WorkshopCardApplicationIdentificationV2
Génération 2, version 2:
Informations enregistrées sur une carte d’atelier et se rapportant
à l’identification de l’application de la carte (exigence 330 bis de
l’annexe IC).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 221
lengthOfFollowingData est le nombre d’octets suivant dans le
relevé.
noOfBorderCrossingRecords indique le nombre de relevés de
passages aux frontières que la carte d’atelier est susceptible de
mémoriser.
noOfLoadUnloadRecords indique le nombre de relevés de
chargement/déchargement que la carte d’atelier est susceptible
de mémoriser.
noOfLoadTypeEntryRecords indique le nombre de saisies de
type de charge que la carte d’atelier est susceptible de mémo­
riser.
vuConfigurationLengthRange est le nombre d’octets contenus
dans une carte tachygraphique, disponibles pour stocker les
configurations de la VU.
2.234 ter WorkshopCardCalibrationAddData
Génération 2, version 2:
Informations enregistrées sur une carte d’atelier et se rapportant
aux données supplémentaires (c’est-à-dire le type de charge par
défaut) saisies au cours d’un étalonnage (exigence 356 terdecies
de l’annexe IC).
calibrationPointerNewestRecord indique l’indice du plus
récent relevé de données supplémentaires d’étalonnage.
Attribution de valeur: nombre correspondant au numérateur du
relevé de données supplémentaires d’étalonnage, commençant
par une série de «0» pour la première occurrence d’un relevé
de données supplémentaires d’étalonnage dans la structure consi­
dérée.
workshopCardCalibrationAddDataRecords désigne le jeu de
relevés contenant les anciennes valeurs de date et d’heure, la
valeur d’identification du véhicule et le type de charge par
défaut du véhicule.
2.234 quater WorkshopCardCalibrationAddDataRecord
Génération 2, version 2:
Informations enregistrées sur une carte d’atelier et se rapportant
au type de charge par défaut saisi au cours d’un étalonnage
(exigence 356 duodecies de l’annexe IC).
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 222
oldTimeValue désigne les anciennes valeurs de date et d’heure
contenues dans le WorkshopCardCalibrationRecord correspon­
dant,
vehicleIdentificationNumber indique le numéro d’identification
du véhicule, également contenu dans le WorkshopCardCalibra­
tionRecord correspondant,
byDefaultLoadType désigne le type de charge par défaut du
véhicule (présent uniquement dans la version 2).
calibrationCountry indique le pays dans lequel l’étalonnage a
été effectué.
calibrationCountryTimestamp indique la date et l’heure
auxquelles la position utilisée pour déterminer le pays d’étalon­
nage a été fournie par le récepteur GNSS.
▼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 occurrence 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).
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 223
Génération 1:
calibrationPurpose indique la raison de l'étalonnage.
vehicleIdentificationNumber indique le VIN.
vehicleRegistration contient le VRN et l'État membre d'imma­
triculation.
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
pneumatiques.
tyreSize indique la désignation de la dimension des pneuma­
tiques montés sur le véhicule.
authorisedSpeed indique la vitesse maximale autorisée du véhi­
cule.
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
correspondant au type spécifié dans le champ CalibrationPurpose
et auquel l'organisme d'inspection agréé doit procéder.
vuPartNumber, vuSerialNumber et sensorSerialNumber
constituent les éléments d'information nécessaires à l'identifica­
tion de l'appareil d'enregistrement.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 224
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'identification 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érentielle du titulaire.
2.238. WorkshopCardPIN
Numéro d'identification individuel de la carte d'atelier
(exigences 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» susceptible de compter 8 octets.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 225
2.239. W-VehicleCharacteristicConstant
Coefficient caractéristique du véhicule (définition k).
Attribution de valeur: Impulsions par kilomètre dans la plage
d'exploitation 0 à 64 255 imp/km.
2.240. VuPowerSupplyInterruptionRecord
Génération 2:
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux événements du type inter­
ruption de l'alimentation électrique (exigence 117, annexe 1C).
eventType indique le type d'événement.
eventRecordPurpose indique la raison de l'enregistrement de
l'événement considéré.
eventBeginTime indique la date et l'heure du début de l'événe­
ment.
eventEndTime indique la date et l'heure de la fin de l'événe­
ment.
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 simi­
laires survenus le même jour.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 226
2.241. VuPowerSupplyInterruptionRecordArray
Génération 2:
Informations enregistrées dans la mémoire d'une unité embar­
quée sur véhicule et se rapportant aux événements du type
excès de vitesse (exigence 117, annexe 1C).
recordType indique le type de relevé (VuPowerSupplyInterrup­
tionRecord). Attribution de valeur: Cf. RecordType
recordSize indique la taille des VuPowerSupplyInterruptionRe­
cord 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 inter­
ruptions de l'alimentation électrique.
2.242. VuSensorExternalGNSSCoupledRecordArray
Génération 2:
Jeu de SensorExternalGNSSCoupledRecord plus les métadon­
nées servant au protocole de téléchargement.
recordType indique le type de relevé (SensorExternalGNSSCou­
pledRecord). Attribution de valeur: Cf. RecordType
recordSize indique la taille des SensorExternalGNSSCouple­
dRecord 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).
Attribution de valeur: Cf. RecordType
recordSize indique la taille des SensorPairedRecord exprimée
en octets.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 227
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 DIMEN­
SIONS
Définition des variables employées dans les définitions du para­
graphe 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 assi­
gnation de valeur est indiquée ci-après. En cas de divergence, la
norme ISO/IEC 8824-1 l'emporte sur cette note d'information.
D'autres chaînes de caractères (Address, Name, VehicleRegis­
trationNumber) utilisent en outre les caractères de la plage de
caractères décimaux 161 à 255 des jeux de caractères standard
à 8 bits suivants, spécifiés par leur numéro de page de code:
Jeu de caractères standard
Code Page
(Décimal)
ISO/IEC 8859-1 Latin-1 Européen occidental 1
ISO/IEC 8859-2 Latin-2 Européen central 2
ISO/IEC 8859-3 Latin-3 Européen du sud 3
ISO/IEC 8859-5 Latin/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'APPLICATIONS
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 228
sont spécifiés dans le rapport technique TR-03110-3 et rappelés
aux présentes à titre d'exhaustivité. 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'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 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 — 21.08.2023 — 003.002 — 229
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
tachygraphiques (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 — 21.08.2023 — 003.002 — 230
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 — 21.08.2023 — 003.002 — 231
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 — 21.08.2023 — 003.002 — 232
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 — 21.08.2023 — 003.002 — 233
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 — 21.08.2023 — 003.002 — 234
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:
▼M3
État d’exploitation lors de l’exécution de commandes ou en
interfaçage avec une unité embarquée sur véhicule,
▼B
É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 — 21.08.2023 — 003.002 — 235
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é.
▼M3
__________
▼B
— 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 — 21.08.2023 — 003.002 — 236
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 — 21.08.2023 — 003.002 — 237
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 — 21.08.2023 — 003.002 — 238
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 — 21.08.2023 — 003.002 — 239
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 — 21.08.2023 — 003.002 — 240
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 — 21.08.2023 — 003.002 — 241
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
disponibles.
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 — 21.08.2023 — 003.002 — 242
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 — 21.08.2023 — 003.002 — 243
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 indi­
quent clairement si la commande prend ou non en charge la
messagerie 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 — 21.08.2023 — 003.002 — 244
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 — 21.08.2023 — 003.002 — 245
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 — 21.08.2023 — 003.002 — 246
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 — 21.08.2023 — 003.002 — 247
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 cryptographique
#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.
appendice 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
Longu­
eur
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 — 21.08.2023 — 003.002 — 248
Octet
Longu­
eur
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
Longu­
eur
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 — 21.08.2023 — 003.002 — 249
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 — 21.08.2023 — 003.002 — 250
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 — 21.08.2023 — 003.002 — 251
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éplace­
ment 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 — 21.08.2023 — 003.002 — 252
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 cryptographique
#(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.
appendice 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 cryptographique
#(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.
appendice 11 partie B)
#(8+L+NN)-
#(7+M+L+N­
N)
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 — 21.08.2023 — 003.002 — 253
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 — 21.08.2023 — 003.002 — 254
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 cryptographique
#(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.
appendice 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 cryptographique
#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.
appendice 11 partie B)
#7-#(6+L) L «XX..XXh» Total de contrôle cryptographique
SW 2 «XXXXh» Mots d'état (SW1, SW2)
La structure des messages de réponse dé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 — 21.08.2023 — 003.002 — 255
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 — 21.08.2023 — 003.002 — 256
— 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'octets. 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épla­
cement/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 — 21.08.2023 — 003.002 — 257
— 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 cryptographique
#(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.
appendice 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 — 21.08.2023 — 003.002 — 258
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 cryptographique
#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.
appendice 11 partie B)
#7-#(6+L) L «XX..XXh» Total de contrôle cryptographique
SW 2 «XXXXh» Mots d'état (SW1, SW2)
3.5.4 GET CHALLENGE
Cette commande est 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 — 21.08.2023 — 003.002 — 259
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 — 21.08.2023 — 003.002 — 260
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 — 21.08.2023 — 003.002 — 261
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 — 21.08.2023 — 003.002 — 262
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électionné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.
▼M3
TCS_86 La commande est exécutable dans le MF, DF Tachograph
et DF Tachograph_G2, voir également TCS_34.
▼B
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 — 21.08.2023 — 003.002 — 263
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.
▼M3
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.
Toutefois, toute valeur de «Lc» inférieure ou égale à
255 octets doit être prise en charge par la carte.
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 un chaînage est nécessaire, toute valeur de «Lc» infé­
rieure ou égale à la longueur maximale étendue indiquée
doit être prise en charge par la carte.
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 de statut
figurent en TCS_85.
▼B
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 — 21.08.2023 — 003.002 — 264
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 — 21.08.2023 — 003.002 — 265
— 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 — 21.08.2023 — 003.002 — 266
TCS_99 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 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 Longueur 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.
▼M3
Le 1 «00h» Conformément à la norme ISO/IEC 7816-4
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 267
TCS_102 Message de réponse
Octet Longueur 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'authen­
tification.
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 Longueur 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 — 21.08.2023 — 003.002 — 268
Octet Longueur 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 Longueur 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 Longueur 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'objets; utiliser la notation en octets. Cf. appendice 11
pour les instructions relatives à la sélection de l'un des
identificateurs d'objet.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 269
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 Longueur 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'objets; utiliser la notation en octets. Cf. appendice 11
pour les instructions relatives à la sélection de l'un des
identificateurs 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 Longueur 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 — 21.08.2023 — 003.002 — 270
Octet Longueur 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 Longueur 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 certi­
ficat). 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éhicule n’est disponible. Voir la définition du champ
CHA à l’appendice 11 et la définition du type de
données EquipmentType à 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 — 21.08.2023 — 003.002 — 271
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 Longueur 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 Longueur 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 — 21.08.2023 — 003.002 — 272
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’appendice
11, partie B, pour la clé de signature de carte Card_Sign.
▼B
TCS_124 Message de commande
▼M1
Octet Longueur 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’algorithme SHA-2 (SHA-256, SHA-384 ou
SHA-512), défini par la méthode de cryptage à l’appen­
dice 11, partie B, pour la clé de signature de carte
Card_Sign
▼B
TCS_125 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 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 — 21.08.2023 — 003.002 — 273
— 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 Longueur 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 — 21.08.2023 — 003.002 — 274
TCS_131 Message de réponse
Octet Longueur 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 Longueur 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 — 21.08.2023 — 003.002 — 275
TCS_134 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 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 — 21.08.2023 — 003.002 — 276
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 Longueur 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'algorithme 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».
▼M3
Le 1 «00h» Conformément à la norme ISO/IEC 7816-4
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 277
TCS_139 Message de réponse
Octet Longueur 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
disponibles.
— «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'enregistrements que le nombre maximum d'enregistre­
ments spécifiés pour les applications correspondantes.
▼M3
Les nombres minimum et maximum d’enregistrements sont
définis au présent chapitre pour les différentes applications.
Dans la version 2 des cartes de conducteur et d’atelier de
génération 2, l’application de génération 1 doit prendre en
charge le nombre maximum d’enregistrements spécifié
en TCS_150 et TCS_158.
▼B
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 — 21.08.2023 — 003.002 — 278
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 — 21.08.2023 — 003.002 — 279
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 — 21.08.2023 — 003.002 — 280
► (1) (2) M3
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 281
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 282
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
▼M3
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:
Remarques:
— l’identificateur d’EF court SFID est communiqué sous
la forme d’un nombre décimal, par exemple la valeur 30
correspond au nombre binaire 11110.
— EF Application_Identification_V2, EF Places_Authenti­
cation, EF GNSS_Places_Authentication, EF
Border_Crossings, EF Load_Unload_Operations, EF
VU_Configuration et EF Load_Type_Entries ne sont
présents que dans la version 2 de la carte de conducteur
de génération 2.
— cardStructureVersion dans EF Application_Identifica­
tion est égal à {01 01} pour la version 2 de la carte
de conducteur de génération 2, alors qu’il était égal à
{01 00} pour la version 1 de la carte de conducteur de
génération 2.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 283
Dans le tableau ci-dessus, les abréviations suivantes sont
utilisées en ce qui concerne 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
▼B
TCS_153 La structure de tous les EF doit être transparente.
▼M3
TCS_154 L’application de la carte de conducteur de génération 2 doit
avoir la structure de données suivante:
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 284
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 285
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 286
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:
▼M3
Min Max
n 1 NoOfEventsPerType 12 12
n 2 NoOfFaultsPerType 24 24
n 3 NoOfCardVehicleRecords 200 200
n 4 NoOfCardPlaceRecords 112 112
n 6 CardActivityLengthRange 13776 octets
(56 jours * 117 modifi­
cations d’activité)
13776 octets
(56 jours * 117 modifi­
cations d’activité)
n 7 NoOfCardVehicleUnitRecords 200 200
n 8 NoOfGNSSADRecords 336 336
n 9 NoOfSpecificConditionRecords 112 112
n 10 NoOfBorderCrossingRecords 1120 1120
n 11 NoOfLoadUnloadRecords 1624 1624
n 12 NoOfLoadTypeEntryRecords 336 336
n 13 VuConfigurationLengthRange 3072 octets 3072 octets
▼B
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 — 21.08.2023 — 003.002 — 287
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 — 21.08.2023 — 003.002 — 288
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 289
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 290
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
▼M3
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.
Remarques:
— l’identificateur d’EF court SFID est communiqué sous
la forme d’un nombre décimal, par exemple la valeur 30
correspond au nombre binaire 11110.
— EF Application_Identification_V2, EF Places_Authenti­
cation, EF GNSS_Places_Authentication, EF
Border_Crossings, EF Load_Unload_Operations, EF
Load_Type_Entries, EF VU_Configuration et Calibra­
tion_Add_Data ne sont présents que dans la version 2
de la carte d’atelier de génération 2.
— cardStructureVersion dans EF Application_Identifica­
tion est égal à {01 01} pour la version 2 de la carte
d’atelier de génération 2, alors qu’il était égal à {01 00}
pour la version 1 de la carte d’atelier de génération 2.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 291
Dans le tableau ci-dessus, les abréviations suivantes sont
utilisées en ce qui concerne 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
▼B
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:
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 292
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 293
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 294
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 295
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 296
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:
▼M3
Min Max
n 1 NoOfEventsPerType 3 3
n 2 NoOfFaultsPerType 6 6
n 3 NoOfCardVehicleRecords 8 8
n 4 NoOfCardPlaceRecords 8 8
n 5 NoOfCalibrationsSinceDownload 255 255
n 6 CardActivityLengthRange 492 octets (1 jour *
240 changements
d’activité)
492 octets (1 jour *
240 changements
d’activité)
n 7 NoOfCardVehicleUnitRecords 8 8
n 8 NoOfGNSSADRecords 24 24
n 9 NoOfSpecificConditionRecords 4 4
n 10 NoOfBorderCrossingRecords 4 4
n 11 NoOfLoadUnloadRecords 8 8
n 12 NoOfLoadTypeEntryRecords 4 4
n 13 VuConfigurationLengthRange 3072 octets 3072 octets
▼B
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 — 21.08.2023 — 003.002 — 297
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
▼M3
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:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 298
Remarques:
— l’identificateur d’EF court SFID est communiqué sous
la forme d’un nombre décimal, par exemple la valeur 30
correspond au nombre binaire 11110.
— EF Application_Identification_V2, et EF VU_Configu­
ration ne sont présents que dans la version 2 de la carte
de contrôle de génération 2,
— cardStructureVersion dans EF Application_Identifica­
tion est égal à {01 01} pour la version 2 de la carte
de contrôle de génération 2, alors qu’il était égal à {01
00} pour la version 1 de la carte de contrôle de géné­
ration 2.
Dans le tableau ci-dessus, les abréviations suivantes sont
utilisées en ce qui concerne 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
▼B
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:
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 299
▼B
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:
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 300
Min Max
n 7 NoOfControlActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 octets 3072 octets
▼B
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:
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 301
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
▼M3
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:
Remarques:
— l’identificateur d’EF court SFID est communiqué sous
la forme d’un nombre décimal, par exemple la valeur 30
correspond au nombre binaire 11110.
— EF Application_Identification_V2, et EF VU_Configu­
ration ne sont présents que dans la version 2 de la carte
d’entreprise de génération 2,
— cardStructureVersion dans EF Application_Identifica­
tion est égal à {01 01} pour la version 2 de la carte
d’entreprise de génération 2, alors qu’il était égal à {01
00} pour la version 1 de la carte d’entreprise de géné­
ration 2.
Dans le tableau ci-dessus, les abréviations suivantes sont
utilisées en ce qui concerne 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
▼B
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 — 21.08.2023 — 003.002 — 302
▼B
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:
▼M3
Min Max
n 8 NoOfCompanyActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 octets 3072 octets
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 303
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 — 21.08.2023 — 003.002 — 304
Conditions particulières, saisies manuelles
Hors limites
Trajet en ferry/train
Opération de chargement
Opération de déchargement
Opération de chargement/déchargement simultanés
Type de charge: passagers
Type de charge: biens
Type de charge: type de charge non défini
▼B
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
▼M3
Sécurité/données authentifiées/scelle­
ments
▼B
Vitesse
Temps
Total/Synthèse
▼M3
Carte numérique/passage à la fron­
tière
▼B
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
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 305
Position où le véhicule a franchi la
frontière entre deux pays
Position où une opération de charge­
ment a eu lieu
Position où une opération de déchar­
gement a eu lieu
Position où une opération de charge­
ment/déchargement simultanés a eu
lieu
▼B
Cartes
Carte du conducteur
Carte d'entreprise
Carte de contrôleur
Carte d'atelier
Pas de carte
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
▼M3
Tirage papier de l’historique des cartes insérées
▼B
É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é
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 306
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
▼M3
Anomalie GNSS
▼B
Défauts
Carte défectueuse (logement de carte du conducteur)
Carte défectueuse (logement de carte du convoyeur)
Anomalie de l'affichage
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'impression sont défi­
nies à l'appendice 4.
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 307
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.
▼M3
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. Les noms et adresses peuvent être
imprimés en deux lignes.
▼B
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 — 21.08.2023 — 003.002 — 308
— les caractères normaux indiquent à l'affichage des variables (picto­
grammes ou données) remplacées au tirage par leurs valeurs
respectives,
— 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
envisageable,
— 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
C
om
bi
na
is
on

de
p
ic
to
gr
am
m
es

C
od
e
de
l
'É
ta
t
m
em
br
e
d'
ém
is
si
on
14 premiers caractères du numéro de la carte
(comprenant, le cas échéant, un indice séquentiel)
In
di
ce
d
e
re
m
pl
ac
em
en
t
In
di
ce
d
e
re
no
uv
el
le
m
en
t
▼M3
— dans un bloc de données, le texte après «pi =» fait référence au
pictogramme ou à la combinaison de pictogrammes correspondants
définis à l’appendice 3,
— lorsqu’il est imprimé après la longitude et la latitude d’une position
enregistrée ou après l’horodatage du moment où la position a été
déterminée, le pictogramme indique que cette position a été
calculée à partir de messages de navigation authentifiés,
— * données disponibles uniquement sur les tachygraphes de généra­
tion 2 (toutes versions confondues),
— ** données disponibles uniquement dans la version 2 de la généra­
tion 2.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 309
PRT_007 Les tirages se composent des blocs et/ou enregistrements de données
qui suivent. Leur signification et leur format sont les suivants:
► (1) (2) (3) (4) (5) M3
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 310
► (1) (2) (3) M3
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 311
► (1) (2) M3
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 312
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 313
► (1) (2) (3) (4) M3
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 314
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 315
► (1) M3
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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 316
3.1. Tirage quotidien des activités du conducteur extraites d'une carte
▼M3
PRT_008 Le tirage quotidien des activités du conducteur extraites
d’une carte doit respecter le format suivant:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 317
3.2. Tirage quotidien des activités du conducteur extraites de la VU
▼M3
PRT_009 Le tirage quotidien des activités du conducteur extraites de la
VU doit respecter le format suivant:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 318
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
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 319
3.5. Tirage des données techniques
▼M3
PRT_012 Le tirage des données techniques doit respecter le format
suivant:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 320
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
▼M3
PRT_014 Le tirage de l’historique des cartes insérées doit respecter le
format suivant:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 321
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'anomalie,
— 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 — 21.08.2023 — 003.002 — 322
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 — 21.08.2023 — 003.002 — 323
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 — 21.08.2023 — 003.002 — 324
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 — 21.08.2023 — 003.002 — 325
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 — 21.08.2023 — 003.002 — 326
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 — 21.08.2023 — 003.002 — 327
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
▼M3
2.2.6.1 Réponse positive à une demande de transfert de données relatives au
téléchargement de la version d’interface
2.2.6.2 Réponse positive à un récapitulatif de transfert de données
2.2.6.3 Réponse positive à une demande de transfert de données relatives aux
activités
2.2.6.4 Réponse positive à une demande de transfert de données relatives aux
événements et anomalies
2.2.6.5 Réponse positive à une demande de transfert de données relatives à la
vitesse du véhicule
2.2.6.6 Réponse positive à une demande de transfert de données techniques
▼B
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 — 21.08.2023 — 003.002 — 328
— à 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’appendice 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 — 21.08.2023 — 003.002 — 329
TLV Longueur des balises (Tag Length Value)
TREP Paramètre de réponse du transfert (Transfer Response Para­
meter)
TRTP Paramètre de demande du transfert (Transfer Request Para­
meter)
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'infor­
mation 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 — 21.08.2023 — 003.002 — 330
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
document.
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 — 21.08.2023 — 003.002 — 331
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.
▼M3
Structure du message 4 octets max. 255 octets max. 1 octet
En-tête Données
Total de
contrôle
IDE ->
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
Téléchargement de la version
d’interface
80 EE F0 02 36 00 96
Vue d’ensemble 80 EE F0 02 36 01, 21 ou 31 CS
Activités 80 EE F0 06 36 02, 22 ou 32 Date CS
Événements et anomalies 80 EE F0 02 36 03, 23 ou 33 Date CS
Vitesse instantanée 80 EE F0 02 36 04 ou 24 Date CS
Données techniques 80 EE F0 02 36 05, 25 ou 35 Date CS
Téléchargement d’une carte 80 EE F0 02 ou 03 36 06 Lecteur CS
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 332
Structure du message 4 octets max. 255 octets max. 1 octet
En-tête Données
Total de
contrôle
IDE ->
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
Demande d’arrêt de la communication 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 Version FA CS
Remarques:
— SID Req = SID de la demande correspondante
— TREP = le TRTP de la demande correspondante.
— La présence de cellules noires indique une absence de transmission.
— L’utilisation du terme «upload» (considéré à partir de l’IDE)
s’impose pour garantir la compatibilité du système avec la norme
ISO 14229. Ce terme possède la même signification que «down­
load» (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.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 333
— Le TRTP 24 est utilisé pour les demandes de téléchargement de
données d’une VU de génération 2, versions 1 et 2.
— Les TRTP 00, 31, 32, 33 et 35 sont utilisés pour les demandes de
téléchargement de données d’une VU de génération 2, version 2.
— Les TRTP 21, 22, 23 et 25 sont utilisés pour les demandes de
téléchargement de données d’une VU de génération 2, version 1.
— Les TRTP 01 à 05 sont utilisés pour les demandes de télécharge­
ment de données d’une VU de génération 1. Ils peuvent, à titre
facultatif, être acceptés par le type de VU de génération 2, mais
uniquement dans le cadre du contrôle des conducteurs effectué par
une autorité de contrôle d’un pays tiers, à l’aide d’une carte de
contrôle de première génération.
— Les TRTP 11 à 1F sont réservés aux demandes de téléchargement
propres au fabricant.
▼B
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).
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.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 334
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.
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.
▼M3
Il existe sept types de transfert de données. Pour les télé­
chargements 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é­
chargements de données
de la VU de génération 1
Valeur de TRTP pour les télé­
chargements de données
de la VU de génération 2,
version 1
Valeur de TRTP pour les télé­
chargements de données
de la VU de génération 2,
version 2
Téléchargement de la version
d’interface
Non utilisé Non utilisé 00
Vue d’ensemble 01 21 31
Activités associées à une date
précise
02 22 32
Événements et anomalies 03 23 33
Vitesse instantanée 04 24 24
Données techniques 05 25 35
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 335
Type de transfert
de données
Valeur de TRTP
Téléchargement
de carte
06
▼M3
DDP_054 Il est obligatoire pour l’IDE de demander un transfert de
données du type «récapitulatif» (TRTP 01, 21 ou 31) 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 troisième cas de figure (TRTP 02, 22 ou 32), le message de
demande de transfert de données comporte l’indication du jour civil
(format TimeReal) 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.
▼M3
DDP_055 Dans le premier cas (TREP 01, 21 ou 31), la VU enverra
des données destinées à aider l’opérateur de l’IDE dans le
choix des données qu’il souhaite télécharger. Les informa­
tions contenues dans ce message sont les suivantes:
▼M1
— Certificats de sécurité,
— 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
terminé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.
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 336
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
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)
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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 337
— 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 — 21.08.2023 — 003.002 — 338
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
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 — 21.08.2023 — 003.002 — 339
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'établis­
sement de la communication, tant au niveau de la synchro­
nisation 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 incompa­
tible), 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 — 21.08.2023 — 003.002 — 340
Figure 2
Traitement d’erreur au niveau de la VU
▼B
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.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 341
DDP_028 L'IDE attend au moins une période de P3min avant
d'entamer 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.
▼M3
2.2.6.1 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 t é l é c h a r g e m e n t d e l a v e r s i o n
d ’ i n t e r f a c e
DDP_028a Le champ de données du message “Réponse positive à une
demande de transfert de données relatives au télécharge­
ment de la version d’interface” doit fournir les données
ci-après dans l’ordre qui suit en vertu des SID 76 Hex,
TREP 00 Hex:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 342
Structure de données de génération 2, version 2 (TREP 00 Hex)
Élément de données Commentaire
DownloadInterfaceVersion Génération et version de la VU: 02,02 Hex pour
la génération 2, version 2.
Non pris en charge par une VU de génération 1
ou de génération 2, version 1, qui doit envoyer
un message de réponse négative (sous-fonction
non prise en charge, voir DDP_018 )
2.2.6.2 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 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, 21 ou 31 Hex et critères appro­
priés de séparation et de comptage des sous-messages:
Structure de données de génération 1 (TREP 01 Hex)
Élément de données Commentaire
MemberStateCertificate Certificats de sécurité de la VU
VUCertificate
VehicleIdentificationNumber Identification du véhicule
VehicleRegistrationIdentification
CurrentDateTime Date et heure actuelles sur la VU
VuDownloadablePeriod Période téléchargeable
CardStructureVersion Catégorie de cartes insérées dans la VU
VuDownloadActivityData Téléchargement précédent de la VU
VuCompanyLocksData Tous les verrouillages d’entreprise mémorisés. Si
cette section est vide, seule l’expression
noOfLocks = 0 est envoyée.
VuControlActivityData 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 Signature RSA de toutes les données (hormis les
certificats) à partir de VehicleIdentification­
Number jusqu’au dernier octet du dernier VuCon­
trolActivityData.
Structure de données de génération 2, version 1 (TREP 21 Hex)
Élément de données Commentaire
MemberStateCertificateRecordArray Certificat de l’État membre
VUCertificateRecordArray Certificate de la VU
VehicleIdentificationNumberRecordArray Identification du véhicule
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 343
Élément de données Commentaire
VehicleRegistrationIdentificationRecordArray Numéro d’immatriculation du véhicule
CurrentDateTimeRecordArray Date et heure actuelles sur la VU
VuDownloadablePeriodRecordArray Période téléchargeable
CardSlotsStatusRecordArray Catégorie de cartes insérées dans la VU
VuDownloadActivityDataRecordArray Téléchargement précédent de la VU
VuCompanyLocksRecordArray 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é
VuControlActivityRecordArray 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é
SignatureRecordArray Signature ECC de toutes les données antérieures
hormis les certificats.
Structure de données de génération 2, version 2 (TREP 31 Hex)
Élément de données Commentaire
MemberStateCertificateRecordArray Certificat de l’État membre
VUCertificateRecordArray Certificate de la VU
VehicleIdentificationNumberRecordArray Identification du véhicule
VehicleRegistrationNumberRecordArray Numéro d’immatriculation du véhicule
CurrentDateTimeRecordArray Date et heure actuelles sur la VU
VuDownloadablePeriodRecordArray Période téléchargeable
CardSlotsStatusRecordArray Catégorie de cartes insérées dans la VU
VuDownloadActivityDataRecordArray Téléchargement précédent de la VU
VuCompanyLocksRecordArray 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é
VuControlActivityRecordArray 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é
SignatureRecordArray Signature ECC de toutes les données antérieures
hormis les certificats.
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 a c t i v i t é s
DDP_030 Le champ de données du message “Réponse positive à une
demande de transfert de données relatives aux activités”
doit fournir les données ci-après dans l’ordre qui suit en
vertu des SID 76 Hex, TREP 02, 22 ou 32 Hex et critères
appropriés de séparation et de comptage des sous-
messages:
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 344
Structure de données de génération 1 (TREP 02 Hex)
Élément de données Commentaire
TimeReal Date du jour de téléchargement
OdometerValueMidnight Kilométrage à la fin de la journée téléchargée
VuCardIWData Données relatives aux cycles d’insertion et de retrait des
cartes.
— Si cette section ne contient aucune donnée dispo­
nible, seule l’expression noOfVuCardIWRecords = 0
est envoyée.
— Lorsque VuCardIWRecord figure à 00 h 00 (inser­
tion de carte de la veille) ou à 24 h 00 (retrait de
carte du lendemain), elle apparaît entièrement sur
les deux jours concernés.
VuActivityDailyData État des lecteurs à 00 h 00 et modifications d’activité
mémorisés pour la journée téléchargée.
VuPlaceDailyWorkPeriodData Données relatives aux emplacements mémorisés pour la
journée téléchargée. Si cette section est vide, seule
l’expression noOfPlaceRecords = 0 est envoyée.
VuSpecificConditionData 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 noOfSpecificConditionRe­
cords = 0 est envoyée.
Signature Signature RSA de toutes les données à partir de Time­
Real jusqu’au dernier octet du dernier relevé de condi­
tions particulières.
Structure de données de génération 2, version 1 (TREP 22 Hex)
Élément de données Commentaire
DateOfDayDownloadedRecordArray Date du jour de téléchargement
OdometerValueMidnightRecordArray Kilométrage à la fin de la journée téléchargée
VuCardIWRecordArray Données relatives aux cycles d’insertion et de retrait des
cartes.
— Si cette section ne contient aucune donnée dispo­
nible, un en-tête de tableau avec l’expression
noOfRecords = 0 est envoyé.
— Lorsque VuCardIWRecord figure à 00 h 00 (inser­
tion de carte de la veille) ou à 24 h 00 (retrait de
carte du lendemain), elle apparaît entièrement sur
les deux jours concernés.
VuActivityDailyRecordArray État des lecteurs à 00 h 00 et modifications d’activité
mémorisés pour la journée téléchargée.
VuPlaceDailyWorkPeriodRecordArray 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é.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 345
Élément de données Commentaire
VuGNSSADRecordArray 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é.
VuSpecificConditionRecordArray 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é
SignatureRecordArray Signature ECC de toutes les données antérieures.
Structure de données de génération 2, version 2 (TREP 32 Hex)
Élément de données Commentaire
DateOfDayDownloadedRecordArray Date du jour de téléchargement
OdometerValueMidnightRecordArray Kilométrage à la fin de la journée téléchargée
VuCardIWRecordArray Données relatives aux cycles d’insertion et de retrait des
cartes.
— Si cette section ne contient aucune donnée dispo­
nible, un en-tête de tableau avec l’expression
noOfRecords = 0 est envoyé.
— Lorsque VuCardIWRecord figure à 00 h 00 (inser­
tion de carte de la veille) ou à 24 h 00 (retrait de
carte du lendemain), elle apparaît entièrement sur
les deux jours concernés.
VuActivityDailyRecordArray État des lecteurs à 00 h 00 et modifications d’activité
mémorisés pour la journée téléchargée.
VuPlaceDailyWorkPeriodRecordArray 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é.
VuGNSSADRecordArray 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é.
VuSpecificConditionRecordArray 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é
VuBorderCrossingRecordArray Passages aux frontières 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é.
VuLoadUnloadRecordArray Opérations de chargement/déchargement 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é.
SignatureRecordArray Signature ECC de toutes les données antérieures.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 346
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 a u x é v é n e m e n t s e t a n o m a l i e s
DDP_031 Le champ de données du message “Réponse positive à une
demande de transfert de données relatives aux événements
et anomalies” doit fournir les données ci-après dans l’ordre
qui suit en vertu des SID 76 Hex, TREP 03, 23 ou 33 Hex
et critères appropriés de séparation et de comptage des
sous-messages:
Structure de données de génération 1 (TREP 03 Hex)
Élément de données Commentaire
VuFaultData Toutes les anomalies enregistrées ou en cours au sein de
la VU.
Si cette section est vide, seule l’expression noOfVu­
Faults = 0 est envoyée.
VuEventData 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 noOfVuE­
vents = 0 est envoyée.
VuOverSpeedingControlData Données relatives au dernier contrôle de dépassement de
vitesse (valeur par défaut en l’absence de données).
VuOverSpeedingEventData 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 noOfVuO­
verSpeedingEvents = 0 est envoyée.
VuTimeAdjustmentData Tous les événements de réglage horaire mémorisés dans
la VU (hormis le cadre d’étalonnage complet).
Si cette section est vide, seule l’expression noOfVuTi­
meAdjRecords = 0 est envoyée.
Signature Signature RSA de toutes les données à partir de noOf­
VuFaults jusqu’au dernier octet du dernier relevé de
réglage horaire.
Structure de données de génération 2, version 1 (TREP 23 Hex)
Élément de données Commentaire
VuFaultRecordArray 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é.
VuEventRecordArray 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é.
VuOverSpeedingControlDataRecordArray Données relatives au dernier contrôle de dépassement de
vitesse (valeur par défaut en l’absence de données).
VuOverSpeedingEventRecordArray 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é.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 347
Élément de données Commentaire
VuTimeAdjustmentRecordArray Tous les événements de réglage horaire mémorisé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é.
SignatureRecordArray Signature ECC de toutes les données antérieures.
Structure de données de génération 2, version 2 (TREP 33 Hex)
Élément de données Commentaire
VuFaultRecordArray 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é.
VuEventRecordArray 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é.
VuOverSpeedingControlDataRecordArray Données relatives au dernier contrôle de dépassement de
vitesse (valeur par défaut en l’absence de données).
VuOverSpeedingEventRecordArray 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é.
VuTimeAdjustmentRecordArray Tous les événements de réglage horaire mémorisé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é.
SignatureRecordArray 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 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 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:
Structure de données de génération 1 (TREP 04 Hex)
Élément de données Commentaire
VuDetailedSpeedData 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 Signature RSA de toutes les données à partir de noOfS­
peedBlocks jusqu’au dernier octet du dernier bloc de
vitesse.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 348
Structure de données de génération 2 (TREP 24 Hex)
Élément de données Commentaire
VuDetailedSpeedBlockRecordArray 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).
SignatureRecordArray Signature ECC de toutes les données antérieures.
2.2.6.6 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 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, 25 ou 35 Hex et critères appropriés
de séparation et de comptage des sous-messages:
Structure de données de génération 1 (TREP 05 Hex)
Élément de données Commentaire
VuIdentification
SensorPaired
VuCalibrationData Tous les relevés d’étalonnage mémorisés dans la VU.
Signature Signature RSA de toutes les données à partir de vuMa­
nufacturerName jusqu’au dernier octet du dernier VuCa­
librationRecord.
Structure de données de génération 2, version 1 (TREP 25 Hex)
Élément de données Commentaire
VuIdentificationRecordArray
VuSensorPairedRecordArray Tous les couplages MS mémorisés dans la VU.
VuSensorExternalGNSSCoupledRecor­
dArray
Tous les couplages du dispositif GNSS externe mémo­
risés dans la VU
VuCalibrationRecordArray Tous les relevés d’étalonnage mémorisés dans la VU.
VuCardRecordArray Toutes les données relatives à l’insertion de carte
mémorisées dans la VU.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray Signature ECC de toutes les données antérieures.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 349
Structure de données de génération 2, version 2 (TREP 35 Hex)
Élément de données Commentaire
VuIdentificationRecordArray
VuSensorPairedRecordArray Tous les couplages MS mémorisés dans la VU.
VuSensorExternalGNSSCoupledRecor­
dArray
Tous les couplages du dispositif GNSS externe mémo­
risés dans la VU
VuCalibrationRecordArray Tous les relevés d’étalonnage mémorisés dans la VU.
VuCardRecordArray Toutes les données relatives à l’insertion de carte
mémorisées dans la VU.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray Signature ECC de toutes les données antérieures.
▼B
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
concernant 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).
Fichier de données signé: fichier enregistré sur l'ICC. Ce fichier
est transféré en clair vers l'IFD. Sur
l'ICC, le fichier est haché et signé; la
signature est transférée vers l'IFD.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 350
3.3. Téléchargement d'une carte
▼M3
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)
ICC et IC. 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é
Tachograph DF:
— Téléchargement des FE Card_Certificate et
CA_Certificate. 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’application (dans le Tachograph DF) sauf
l’EF Card_Download. Ces informations sont
protégées par une signature numérique, confor­
mé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 EF Appli­
cation_Identification et Identification 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:
Events_Data,
Faults_Data,
Driver_Activity_Data,
Vehicles_Used,
Places,
Control_Activity_Data,
Specific_Conditions.
— Pour les cartes tachygraphiques de deuxième génération
uniquement:
— Excepté lorsque le téléchargement 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 Tachograph_G2
DF:
— Télécharger les EF CardSignCertificate,
CA_Certificate et Link_Certificate. Ces informa­
tions 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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 351
— Téléchargement des autres EF de données
d’application (dans le Tachograph_G2 DF) sauf
l’EF Card_Download. Ces informations sont
protégées par une signature numérique, confor­
mément aux dispositions de l’appendice 11,
Mécanismes de sécurité communs, partie B.
— Il y a lieu de télécharger au moins les EF Appli­
cation_Identification, Application_Identifica­
tion_V2 (le cas échéant) et Identification 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:
Events_Data,
Faults_Data,
Driver_Activity_Data,
Vehicles_Used,
Places,
Control_Activity_Data,
Specific_Conditions,
VehicleUnits_Used,
GNSS_Places,
Places_Authentication, le cas échéant,
GNSS_Places_Authentication, le cas échéant,
Border_Crossings, le cas échéant,
Load_Unload_Operations, le cas échéant,
Load_Type_Entries, le cas échéant.
— Lors du téléchargement d’une carte de conduc­
teur, il convient de mettre à jour la date Last­
CardDownload dans l’EF Card_Download, dans
les DF Tachograph et, le cas échéant, Tacho­
graph_G2.
— Lors du téléchargement d’une carte d’atelier, il
convient de réinitialiser le compteur d’étalonnage
enregistré dans l’EF Card_Download dans les
DF Tachograph et, le cas échéant, Tacho­
graph_G2.
— Lors du téléchargement d’une carte d’atelier,
l’EF Sensor_Installation_Data dans les DF
Tachograph et, le cas échéant, Tachograph_G2
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.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 352
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
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
retenue
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 353
Carte Dir IDE/IFD Signification/Remarques
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 temporaire­
ment 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.
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.
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 354
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
FDI (2 octets) || «02» Balise pour EF (FDI) dans 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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 355
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 — 21.08.2023 — 003.002 — 356
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 — 21.08.2023 — 003.002 — 357
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
▼M3
8. SERVICE ROUTINECONTROL (RÉGLAGE DE L’HEURE)
8.1. Description des messages
8.2. Structure des messages
9. STRUCTURES DES DATARECORDS
9.1. Gammes des paramètres transmis
9.2. Structures des dataRecords
▼B
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 — 21.08.2023 — 003.002 — 358
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'appa­
reil 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 — 21.08.2023 — 003.002 — 359
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 ■
▼M3
RoutineControl 8 31
▼B
■ 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 auto­
risé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'établissement d'une communication et la sélection de para­
mè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'intercommunication font l'objet d'une description détaillée
dans le document ISO 14230-2.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 360
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 diag­
nostic) 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éinitialisé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'intercommunication.
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'initialisation.
— Toutes les informations nécessaires à l'établissement
d'une communication sont contenues dans la réponse
de la VU.
CPR_012 Après initialisation,
— 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ésac­
tivé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 — 21.08.2023 — 003.002 — 361
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 — 21.08.2023 — 003.002 — 362
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 — 21.08.2023 — 003.002 — 363
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 — 21.08.2023 — 003.002 — 364
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émen­
taire
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 — 21.08.2023 — 003.002 — 365
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 — 21.08.2023 — 003.002 — 366
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 fonc­
tions 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 — 21.08.2023 — 003.002 — 367
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 — 21.08.2023 — 003.002 — 368
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 ( α )
12 RC_SFNS
incorrectMessage­
Length ( β )
13 RC_IML
conditionsNotCor­
rect ( γ )
22 RC_CNC
#8 Total de contrôle 00-FF CS
( α ) La valeur introduite dans l'octet 6 du message de demande n'est pas prise en charge,
c.-à-d. pas dans le Tableau 17,
( β ) la longueur du message est incorrecte,
( γ ) 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 — 21.08.2023 — 003.002 — 369
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éhicule
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 370
requestCorrectlyReceived-ResponsePending (demande bien
reçue — réponse suit) afin de prolonger le temps de
réponse. Le temps de réponse ne devra cependant pas
dépasser 5 minutes. Dès que le service demandé est exécuté,
la VU envoie un 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 — 21.08.2023 — 003.002 — 371
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 response­
Code =
[conditionsNotCorrec­
tOrRequestSequen­
ceError
22 RC_CNC
incorrectMessage­
Length]
13 RC_IML
#8 Total de contrôle 00-FF CS
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 372
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 — 21.08.2023 — 003.002 — 373
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 Response­
Code =
[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 — 21.08.2023 — 003.002 — 374
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 — 21.08.2023 — 003.002 — 375
Octet # Nom de paramètre
Valeur
hex.
Mnémonique
#8 à #m+7 dataRecord[] = [data#1 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DAT­
Am
#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 Response­
Code=
[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.
▼M3
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 cinq colonnes
et d’un certain nombre de lignes.
— La 1 re colonne (Hex.) indique la “Valeur hex.” affectée
au 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 — 21.08.2023 — 003.002 — 376
— La 3 e colonne (Description) spécifie le nom recordDa­
taIdentifier correspondant.
— La 4 e colonne (Droits d’accès) spécifie les droits
d’accès à ce recordDataIdentifier.
— La 5 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)
Droits
d’accès
(Lecture/
Écriture)
Mnémonique
F90B CurrentDateTime TimeDate L/E RDI_TD
F912 HighResOdometer HighResolutionTotalVehicleDis­
tance
L/E RDI_HRTVD
F918 K-ConstantOfRecordingEquipment Kfactor L/E RDI_KF
F91C L-TyreCircumference LfactorTyreCircumference L/E RDI_LF
F91D W-VehicleCharacteristicConstant WvehicleCharacteristicFactor L/E IR_CWCV
F921 TyreSize TyreSize L/E IR_DP
F922 nextCalibrationDate NextCalibrationDate L/E RDI_NCD
F92C SpeedAuthorised SpeedAuthorised L/E RDI_SA
F97D vehicleRegistrationNation RegisteringMemberState L/E RDI_RMS
F97E VehicleRegistrationNumber VehicleRegistrationNumber L/E RDI_ VRN
F190 VehicleIdentificationNumber VIN L/E RDI_ VIN
F9D0 SensorSerialNumber MotionSensorSerialNumber L RDI_SSN
F9D1 RemoteCommunicationModuleSerial­
Number
RemoteCommunicationFacility­
SerialNumber
L RDI_RCSN
F9D2 SensorGNSSSerialNumber ExternalGNSSFacilitySerial­
Number
L RDI_GSSN
F9D3 SealDataVu SmartTachographSealsSerial­
Number
L/E RDI_SDV
F9D4 VuSerialNumber VuSerialNumber L RDI_VSN
F9D5 ByDefaultLoadType ByDefaultLoadType L/E RDI_BDLT
F9D6 TachographCardsGen1Suppression TachographCardsGen1Suppres­
sion
L/E RDI_TCG1S
F9D7 VehiclePosition VehiclePosition L RDI_VP
F9D8 LastCalibrationCountry CalibrationCountry L RDI_CC
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 377
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.
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_DAT­
Am
#m+8 Total de contrôle 00-FF CS
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 378
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
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 Response­
Code=
[requestOutOf
Range
31 RC_ROOR
incorrectMessage­
Length
13 RC_IML
conditionsNotCor­
rect]
22 RC_CNC
#8 Total de contrôle 00-FF CS
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 379
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é.
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'horloge UTC; cette fonction n'est pas disponible en
mode CONTRÔLE.
CPR_059 Pour être en mesure de configurer l'état de la ligne, il faut
que l'unité embarquée sur véhicule soit entrée en session de
réglage et qu'elle soit exploitée en mode É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).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 380
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.
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).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 381
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
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 382
Octet # Nom de paramètre Valeur hex. Mnémonique
#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
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)
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 383
Mode Valeur hex. Description
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
▼M3
8. SERVICE ROUTINECONTROL (RÉGLAGE DE L’HEURE)
8.1. Description des messages
CPR_065a Le service RoutineControl (TimeAdjustment) permet de
déclencher un alignement de l’horloge de la VU sur
l’heure fournie par le récepteur GNSS.
Pour l’exécution du service RoutineControl (TimeAdjust­
ment), la VU doit être en mode ÉTALONNAGE.
Condition préalable: il est garanti que la VU est en
mesure de recevoir des messages de position authentifiés
de la part du récepteur GNSS.
Tant que la remise à l’heure est en cours, la VA répondra à
la demande RoutineControl, sous-fonction requestRoutine­
Results, par routineInfo = 0x78.
Remarque: la remise à l’heure peut prendre un certain
temps. L’appareil de diagnostic demande le statut de
remise à l’heure en utilisant la sous-fonction requestRouti­
neResults.
8.2. Structure des messages
CPR_065b La structure des messages associés au service RoutineCon­
trol (TimeAdjustment) et à ses primitives fait l’objet d’une
description détaillée dans les tableaux ci-après.
Tableau 37a
RoutineControl, message de demande routine (TimeAdjustment) sous-fonction startRoutine
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 xx LEN
#5 ID du service Demande RoutineControl 31 RC
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 et #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 Total de contrôle 00-FF CS
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 384
Tableau 37b
RoutineControl, routine (TimeAdjustment), sous-fonction startRoutine, message de réponse positive
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 xx LEN
#5 ID du service réponse positive RoutineControl 71 RCPR
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 et #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 Total de contrôle 00-FF CS
Tableau 37c
RoutineControl, message de demande routine (TimeAdjustment), sous-fonction requestRoutineResults
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 xx LEN
#5 ID du service Demande RoutineControl 31 RC
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 et #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 Total de contrôle 00-FF CS
Tableau 37d
RoutineControl, routine (TimeAdjustment), sous-fonction requestRoutineResults, message de réponse positive
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 xx LEN
#5 ID du service réponse positive RoutineControl 71 RCPR
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 et #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 routineInfo (voir tableau 37f) XX RINF_TA
#10 routineStatusRecord[] = routineStatus#1 (voir Tableau 37g) XX RS_TA
#11 Total de contrôle 00-FF CS
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 385
Tableau 37e
RoutineControl, routine (TimeAdjustment), message de réponse négative
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 ID du service Réponse négative 7F NR
#6 ID du service Demande inputOutputControlByIdentifier 31 RC
#7 responseCode=[
sub-functionNotSupported
incorrectMessageLengthOrInvalidFormat
conditionsNotCorrect
requestOutOfRange
]
12
13
22
31
SFNS
IMLOIF
CNC
ROOR
#8 Total de contrôle 00-FF CS
Tableau 37f
RoutineControl, routine (TimeAdjustment), routineInfo
routineInfo Valeur hex. Description
NormalExitWithResultAvailable 61 La routine a été entièrement exécutée; résultats supplé­
mentaires de la routine disponibles.
RoutineExecutionOngoing 78 La routine demandée est toujours en cours d’exécution.
Tableau 37 g
RoutineControl, routine (TimeAdjustment), routineStatus
Valeur hex. Résultat de l’essai Description
01 positif La remise à l’heure a été effectuée avec succès.
02..0F RFU
10 négatif Pas de réception du signal GNSS.
11..7F RFU
80..FF Propre au fabricant
9. 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.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 386
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’est-à-dire
la valeur actuelle du paramètre demandé telle que mesurée
ou observée par la VU).
9.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 mettent en lumière les paramètres
pour lesquels le récepteur n’attend pas de réponse.
CPR_072 Lorsque la défaillance d’un composant empêche la trans­
mission 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
Gammes de dataRecords
Nom de la gamme
1 octet
(valeur hex.)
2 octets
(valeur hex.)
4 octets
(valeur hex.)
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.
9.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 WriteDataByI­
dentifier.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 387
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
HighResolutionTotalVehicleDis­
tance
4 gain 5 m/bit, décalage 0 m 0 à +21 055 406 km
Kfactor 2 gain 0,001 impulsion/m/bit,
décalage 0
0 à 64,255 impulsion/m
LfactorTyreCircumference 2 gain 0,125 10 -3 m/bit,
décalage 0
0 et 8,031 m
WvehicleCharacteristicFactor 2 gain 0,001 impulsion/m/bit,
décalage 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
RegisteringMemberState 3 ASCII ASCII
VehicleRegistrationNumber 14 Cf. détails au tableau 42
VIN 17 ASCII ASCII
SealDataVu 55 Cf. détails au tableau 43
ByDefaultLoadType 1 Cf. détails au tableau 44
VuSerialNumber 8 Cf. détails au tableau 45
SensorSerialNumber 8 Cf. détails au tableau 45
SensorGNSSSerialNumber 8 Cf. détails au tableau 45
RemoteCommunicationModuleSe­
rialNumber
8 Cf. détails au tableau 45
TachographCardsGen1Suppression 2 Cf. détails au tableau 46
VehiclePosition 14 Cf. détails au tableau 47
CalibrationCountry 3 ASCII NationAlpha tel que défini à
l’appendice 1
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 388
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érationnelle
1 Secondes gain 0,25 s/bit, décalage 0 s 0 à 59,75 s
2 Procès-verbal gain 1 min/bit, décalage 0 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
ci-après la remarque du tableau 41)
0,25 à 31,75 jours
6 Année gain 1 année/bit, décalage année + 1985
(voir remarque 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 les structures 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érationnelle
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
remarque ci-après)
0,25 à 31,75 jours
3 Année gain 1 année/bit, décalage année + 1985
(voir la remarque ci-dessous)
années 1985 à 2235
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; les
valeurs 5, 6, 7 et 8 indiquent le deuxième jour du mois;
etc.
2) Ce paramètre n’influence pas ni ne modifie le paramètre
des heures précité.Remarque concernant l’utilisation du
paramètre «Année»:
Une valeur ‘0’ pour l’année identifie l’année 1985; une
valeur ‘1’ identifie 1986; etc.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 389
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 de VehicleRegistrationNumber (valeur recordDataIdentifier # F97E)
Octet Définition du paramètre Résolution Gamme opérationnelle
1 Page de code (telle que définie à l’appen­
dice 1)
sans objet VehicleRegistrationNumber
2 – 14 Numéro d’immatriculation du véhicule (tel
que défini à l’appendice 1)
sans objet VehicleRegistrationNumber
CPR_090 Le tableau 43 expose en détail les structures des différents
octets du paramètre SealDataVu:
Tableau 43
Structure détaillée de SealDataVu (valeur recordDataIdentifier # F9D3)
Octet Définition du paramètre Résolution Gamme opérationnelle
1 – 11 sealRecord1. Structure SealRecord (telle que
définie à l’appendice 1)
sans objet SealRecord
12 - 22 sealRecord2. Structure SealRecord (telle que
définie à l’appendice 1)
sans objet SealRecord
23 – 33 sealRecord3. Structure SealRecord (telle que
définie à l’appendice 1)
sans objet SealRecord
34 – 44 sealRecord4. Structure SealRecord (telle que
définie à l’appendice 1)
sans objet SealRecord
45 – 55 sealRecord5. Structure SealRecord (telle que
définie à l’appendice 1)
sans objet SealRecord
REMARQUE: S’il existe moins de 5 scellements disponi­
bles, la valeur du type d’équipement dans tous les relevés
de scellements inutilisés doit être définie sur 15, c’est-à-dire
inutilisé.
CPR_091 Le tableau 44 expose en détail les structures des différents
octets du paramètre ByDefaultLoadType:
Tableau 44
Structure détaillée de ByDefaultLoadType (valeur recordDataIdentifier # F9D5)
Octet Définition du paramètre Résolution Gamme opérationnelle
1 loadType
‘00’H: Type de charge non défini
‘01’H: Biens
‘02’H: Passagers
sans objet ‘00’H à ‘02’H
CPR_092 Le tableau 45 expose en détail les structures des différents
octets des paramètres VuSerialNumber, SensorSerial­
Number, SensorGNSSSerialNumber et RemoteCommunica­
tionModuleSerialNumber:
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 390
Tableau 45
Structure détaillée de VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber et
RemoteCommunicationModuleSerialNumber (valeurs recordDataIdentifier # F9D4, F9D0, F9D2, F9D1)
Octet Définition du paramètre Résolution Gamme opérationnelle
1 VuSerialNumber, SensorSerialNumber,
SensorGNSSSerialNumber et RemoteCom­
municationModuleSerialNumber:
structure ExtendedSerialNumber telle que
définie à l’appendice 1.
sans objet ExtendedSerialNumber
CPR_093 Le tableau 46 expose en détail les structures des différents
octets du paramètre TachographCardsGen1Suppression:
Tableau 46
Structure détaillée de TachographCardsGen1Suppression (valeur recordDataIdentifier # F9D6)
Octet Définition du paramètre Résolution Gamme opérationnelle
1-2 TachographCardsGen1Suppression. Structure
TachographCardsGen1Suppression telle que
définie à l’appendice 1.
sans objet ‘0000’H, ‘A5E3’H
CPR_094 Le tableau 47 expose en détail les structures des différents
octets du paramètre VehiclePosition.
Tableau 47
Structure détaillée de VehiclePosition (valeur recordDataIdentifier # F9D7)
Octet Définition du paramètre Résolution Gamme opérationnelle
1 - 4 L’horodatage du moment où la position du
véhicule a été déterminée.
Sans objet TimeReal
5 Précision GNSS Sans objet GNSSAccuracy
6 - 11 Position du véhicule Sans objet GeoCoordinates
12 Statut d’authentification Sans objet PositionAuthenticationStatus
13 Pays actuel Sans objet NationNumeric
14 Région actuelle Sans objet RegionNumeric
Remarque: après l’actualisation de la position du véhicule,
la mise à jour du pays et de la région actuels peut être
retardée.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 391
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É
▼M3
9. ESSAIS OSNMA
▼B
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’appendice 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 certification 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
fonctionnement 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).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 392
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
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
dispositifs 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.
▼M3
L’autorité des États membres chargée des essais fonctionnels d’une unité
embarquée sur véhicule ou d’un dispositif GNSS externe doit s’assurer
que le récepteur GNSS intégré a passé avec succès les essais OSNMA
spécifiés dans le présent appendice. Ces essais sont considérés comme
faisant partie des essais fonctionnels de l’unité embarquée sur véhicule
ou du dispositif GNSS externe.
▼B
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
électriques 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
conduction 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'alimentation.
ISO/IEC 7816-1 Cartes d'identification — Cartes à circuit intégré — Partie
1: Cartes à contacts — Caractéristiques physiques.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 393
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'identifica­
tion — 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
volumique et du volume spécifique
▼M3
RGODP JRC Technical Report – Receiver guidelines for OSNMA data
processing
▼B
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 394
N o Essai Description Exigences connexes
▼M3
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, de la position et de la distance parcourue 21 à 37
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 et 134
3.9 Saisie par le conducteur 56 à 62 quater
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 bis, 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 ou de l’atelier 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 Données relatives aux cartes tachygraphiques 132*, 133*
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 395
N o Essai Description Exigences connexes
3.28 Passages aux frontières 133 bis* à 133 quinquies*
3.29 Opération de chargement/déchargement 133 sexies* à 133 decies*
3.30 Carte numérique 133 undecies* à 133 unvicies*
3.31 Enregistrement et mémorisation sur les cartes tachygraphiques 136, 137, 138*, 139*, 141*,
142, 143
144, 145, 146*, 147*,
147 bis*, 147 ter*, 148*,
149, 150, 150 bis
3.32 Affichage 90, 134,
151 à 168,
PIC_001, DIS_001
3.33 Impression 90, 134,
169 à 181, PIC_001, PRT_001
à PRT_014
3.34 Avertissement 134, 182 à 191,
PIC_001
3.35 Téléchargement de données à destination de supports externes 90, 134, 192 à 196
3.36 Communication à distance pour les contrôles routiers ciblés 197 à 199
3.37 Échanges de données avec des dispositifs externes supplémentaires 200, 201
3.38 Étalonnage 202 à 206*, 383, 384, 386 à
391
3.39 Contrôles routiers d’étalonnage 207 à 209
3.40 Réglage de l’heure 210 à 212*
3.41 Surveillance des passages aux frontières 226 bis à 226 quater
3.42 Mise à jour logicielle 226 quinquies à 226 septies
3.43 Absence d’interférence des fonctions supplémentaires 06, 425
3.44 Interface des capteurs de mouvement 02, 122
3.45 Dispositif GNSS externe 03, 123
3.46 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.47 Suite de chiffrement et paramètres de domaines normalisés CSM_48, CSM_50
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 396
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é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
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é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écou­
plée.
219
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 397
N o Essai Description Exigences connexes
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
(codes IP) - Protection des équipements élec­
triques 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
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
électrique
(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’alimentation é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 é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
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 398
N o Essai Description Exigences connexes
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
▼B
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*
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 399
N o Essai Description Exigences connexes
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 appli­
quant 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
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éra­
ture variant de + 25 °C à + 55 °C et le taux
d'humidité relative atteignant 97 % à + 25 °C
et 93 % à + 55 °C
214
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 400
N o Essai Description Exigences connexes
4.4 vibrations ISO 16750-3: Chapitre 4.1.2.6: Essai VI: Véhi­
cule 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 ,
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

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éhi­
cules 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
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 +
Rectificatif technique:2010 + AMD1:2014: +/–
4 kV pour le contact et +/– 8 kV pour la
décharge d'air
218
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 401
N o Essai Description Exigences connexes
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 dispo­
sitif 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 TACHYGRA­
PHIQUES
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éca­
niques 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 — 21.08.2023 — 003.002 — 402
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 — 21.08.2023 — 003.002 — 403
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é­
ristiques physiques,
[5] Dimension de la carte,
[5.1] Taille de la carte,
[5.1.1] Dimensions et tolérances de la carte,
type de carte ID-1 Carte inutilisée
[Bords de la carte]
Les cartes 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 — 21.08.2023 — 003.002 — 404
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 — 21.08.2023 — 003.002 — 405
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 — 21.08.2023 — 003.002 — 406
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 — 21.08.2023 — 003.002 — 407
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 — 21.08.2023 — 003.002 — 408
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 fonc­
tionner correctement dans toutes les conditions
climatiques normalement 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, «occa­
sionnelles» 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 — 21.08.2023 — 003.002 — 409
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 — 21.08.2023 — 003.002 — 410
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 — 21.08.2023 — 003.002 — 411
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
optique 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 — 21.08.2023 — 003.002 — 412
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'envi­
ronnement — 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 atteignant
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 — 21.08.2023 — 003.002 — 413
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
d e t e m p é r a t u r e – 2 0 . . . 7 0 ° 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 étran­
gers
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
(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 alimen­
tation é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 — 21.08.2023 — 003.002 — 414
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'alimentation
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 — 21.08.2023 — 003.002 — 415
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’alimentation
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 — 21.08.2023 — 003.002 — 416
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 — 21.08.2023 — 003.002 — 417
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 — 21.08.2023 — 003.002 — 418
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 tachy­
graphique
2 Essais de lecture/écriture Mettre à exécution un scénario d’activité classique sur l’unité
embarqué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é
embarqué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 — 21.08.2023 — 003.002 — 419
9. ESSAIS OSNMA
9.1. Introduction
Le présent chapitre décrit les essais visant à prouver la bonne mise en
œuvre du service OSNMA dans le récepteur GNSS. Étant donné que
l’authentification du signal satellite est effectuée uniquement par le récep­
teur GNSS en toute indépendance par rapport aux autres composants du
tachygraphe, les essais décrits dans le présent chapitre peuvent être effec­
tués sur le récepteur GNSS examiné en tant qu’élément autonome. Dans
ce cas, le fabricant du tachygraphe présente aux autorités compétentes en
matière d’homologation un rapport détaillant la mise en œuvre et les
résultats des essais effectués sous la responsabilité du fabricant du récep­
teur GNSS.
9.2 Conditions applicables
— Les critères de réussite/échec définis dans les essais OSNMA ne sont
considérés comme valables que pour les conditions d’essai indiquées.
— Les critères pourraient être révisés au moment de la déclaration de
service OSNMA de Galileo et compte tenu des engagements en
matière de performance des services qui y sont associés.
9.3. Définitions et acronymes
9.3.1 Définitions
Démarrage GNSS
froid/chaud/très chaud:
désigne l’état de démarrage d’un récepteur
GNSS sur la base de la disponibilité du
temps (T), de l’almanach (A) et de l’éphémé­
ride (E) actuels, et de la position (P):
— Démarrage GNSS froid: aucun
— Démarrage GNSS chaud: T, A, P
— Démarrage GNSS très chaud: T, A, E, P
Démarrage OSNMA
froid/chaud/très chaud:
désigne l’état de démarrage de la fonction
OSNMA sur la base de la disponibilité des
informations de la clé publique (P) et
DSM-KROOT (K) (telles que définies dans
les lignes directrices concernant les récepteurs
OSNMA visées à l’appendice 12 ):
— Démarrage OSNMA froid: aucun
— Démarrage OSNMA chaud: P
— Démarrage OSNMA très chaud: P, K
9.3.2 Acronymes
ADKD “Authentication Data & Key Delay” (données d’authen­
tification et délai de la clé)
DSM-KROOT “Digital Signature Message KROOT” (message de signa­
ture numérique KROOT)
GNSS “Global Navigation Satellite System” (système mondial
de radionavigation par satellite)
KROOT Clé racine de la chaîne de clés TESLA
MAC “Message Authentication Code” (code d’authentification
de message)
NMACK “Number of MAC & key blocks” (nombre de MAC et de
blocs de clés par 30 secondes)
OSNMA “Galileo Open Service Navigation Message Authentica­
tion” (service d’authentification des messages de naviga­
tion en libre service de Galileo)
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 420
SLMAC “Slow MAC” (MAC lent)
TESLA “Timed Efficient Stream Loss-tolerant Authentication”
(Protocole utilisé dans OSNMA)
9.4. Équipements pour la génération des signaux GNSS
La génération des signaux GNSS peut être réalisée à l’aide d’un simula­
teur GNSS multiconstellation prenant en charge la transmission de
messages OSNMA. Il est également possible d’utiliser un lecteur de
signaux radioélectriques capable de récupérer des échantillons de
signaux GNSS à partir de fichiers. La profondeur et la vitesse d’échan­
tillonnage des bits typiques sont respectivement de 4 bits I/Q et 10 MHz.
On suppose que le récepteur GNSS dispose d’interfaces pour ordonner
l’effacement de la mémoire du récepteur (pour effacer de manière indé­
pendante la clé publique, la KROOT, les informations d’horloge, les
informations de position, l’éphéméride et l’almanach), pour régler la réali­
sation en heure locale du récepteur pour l’exigence de vérification de la
synchronisation OSNMA et pour charger les informations cryptogra­
phiques. Ces commandes peuvent être limitées à des fins d’essai et ne
peuvent donc pas être disponibles pour le fonctionnement nominal du
récepteur.
9.5 Conditions d’essai
9.5.1 Conditions GNSS
Les signaux GNSS simulés ou répétés doivent présenter les caractéris­
tiques suivantes:
— Scénario de récepteur utilisateur statique;
— Au moins les constellations GPS et Galileo;
— Fréquence E1/L1;
— Au moins 4 satellites Galileo ayant un angle d’altitude supérieur à 5°;
— Durée requise pour chaque essai;
— Les éphémérides de navigation constante des satellites au cours de
l’essai.
9.5.2 Conditions OSNMA
Le message OSNMA transmis dans le signal RF doit présenter les carac­
téristiques suivantes:
— Un message HKROOT avec le statut OSNMA réglé sur “opérationnel”
ou “à l’essai” et un DSM-KROOT fixe de 8 blocs pour la chaîne en
vigueur;
— Au moins 4 satellites Galileo transmettant OSNMA;
— Un message MACK avec un bloc MACK (soit NMACK = 1), et au
moins un ADKD = 0 et un ADKD = 12 par satellite et bloc MACK;
— Une taille de balise de 40 bits;
— La longueur minimale équivalente de la balise requise dans les lignes
directrices concernant les récepteurs OSNMA (actuellement 80 bits).
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 421
Sauf indication contraire, la réalisation temporelle du récepteur interne doit
être connue avec une précision suffisante et correctement alignée sur
l’heure simulée. Cela garantit que l’exigence de synchronisation tempo­
relle initiale OSNMA est satisfaite pour chaque condition d’essai, c’est-à-
dire la synchronisation nominale pour tous les essais à l’exception de
l’essai SLMAC. Voir les lignes directrices concernant les récepteurs
OSNMA pour plus de détails sur l’initialisation temporelle.
Il convient de noter que les critères de réussite et d’échec identifiés sont
prudents et ne représentent pas les performances attendues du service
OSNMA de Galileo.
9.6. Spécifications d’essai
N° Essai Description Exigences connexes
1. Examen administratif
1.1 Documentation Exactitude de la documentation
2 Essais généraux
2.1 Démarrage OSNMA
très chaud
Objectif: vérifier que le récepteur GNSS calcule une
position avec OSNMA après un démarrage très chaud.
Procédure:
Le récepteur GNSS démarre dans des conditions de
démarrage GNSS et OSNMA très chaudes et acquiert
les signaux des satellites Galileo visibles.
Le récepteur authentifie les données de navigation
Galileo avec OSNMA (ADKD = 0) et fournit une
position avec des données authentifiées.
Critères de réussite et d’échec: le récepteur calcule un
point de repère authentifié dans un délai de
160 secondes.
Appendice 12,
GNS_3 ter
2.2 Démarrage OSNMA
chaud:
Objectif: vérifier que le récepteur GNSS calcule une
position avec OSNMA après un démarrage très chaud.
Procédure:
Avant de commencer l’essai, les éphémérides et la
KROOT doivent être effacées de la mémoire du récep­
teur GNSS afin de forcer le démarrage GNSS et
OSNMA chaud.
Le récepteur GNSS démarre et acquiert les signaux des
satellites Galileo visibles.
Le DSM-KROOT est réceptionné et vérifié.
Le récepteur authentifie les données de navigation
Galileo avec OSNMA (ADKD = 0) et fournit une
position avec des données authentifiées.
Critères de réussite et d’échec: le récepteur calcule un
point de repère authentifié valide dans un délai de
430 secondes.
Appendice 12,
GNS_3 ter
2.3 Démarrage OSNMA
chaud avec SLMAC
Objectif: vérifier que le récepteur GNSS calcule une
position avec OSNMA après un démarrage chaud
avec une initialisation temporelle nécessitant le mode
SLMAC, tel que défini dans les lignes directrices
concernant les récepteurs OSNMA.
Procédure:
La réalisation temporelle du récepteur interne doit être
configurée de manière à avoir une incertitude tempo­
relle initiale comprise entre 2 et 2,5 minutes, de telle
sorte que, conformément aux lignes directrices de
l’OSNMA Receiver, le mode “Slow MAC” soit activé.
Appendice 12,
GNS_3 ter
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 422
N° Essai Description Exigences connexes
Avant de commencer les essais, les éphémérides et la
KROOT doivent être effacées de la mémoire du récep­
teur GNSS afin de forcer le démarrage GNSS et
OSNMA chaud.
Le récepteur GNSS démarre et acquiert les signaux des
satellites Galileo visibles.
Le DSM-KROOT est réceptionné et vérifié.
Le récepteur authentifie les données de navigation
Galileo avec OSNMA limité au mode “Slow MAC”
(ADKD = 12) et fournit une position avec des
données authentifiées.
Critères de réussite et d’échec: le récepteur calcule un
point de repère authentifié valide dans un délai de
730 secondes.
2.4 Démarrage OSNMA
très chaud avec un
signal répété
Objectif: vérifier que le récepteur GNSS détecte un
signal répété.
Procédure:
Le récepteur GNSS démarre dans des conditions de
démarrage GNSS et OSNMA très chaudes et acquiert
les signaux des satellites Galileo visibles.
Le récepteur authentifie les données de navigation
Galileo avec OSNMA (ADKD = 0) et fournit une
position avec des données authentifiées.
Une fois que le récepteur fournit une solution PVT avec
des données authentifiées, il est éteint.
Un signal répété avec un retard de 40 secondes par
rapport au signal précédent est simulé, et le récepteur
est allumé.
Le récepteur détecte que le temps du système Galileo à
partir du temps du signal dans l’espace et la réalisation
de la synchronisation locale ne satisfont pas à
l’exigence de synchronisation et qu’il cesse de traiter
les données OSNMA telles que définies dans les lignes
directrices concernant les récepteurs OSNMA.
Critères de réussite et d’échec: le récepteur détecte le
signal répété et ne calcule pas une position valide
authentifiée depuis le début de la répétition jusqu’à la
fin de l’essai.
Appendice 12,
GNS_3 ter
2.5 Démarrage OSNMA
très chaud avec des
données erronées
Objectif: vérifier que OSNMA détecte les données erro­
nées.
Procédure:
Le récepteur GNSS est allumé dans des conditions de
démarrage GNSS et OSNMA très chaudes.
Le récepteur GNSS doit être en mesure d’acquérir le
signal de tous les satellites Galileo visibles et de vérifier
l’authenticité de leurs messages de navigation au moyen
d'OSNMA.
Au moins un bit des données des éphémérides fournies
par chaque satellite Galileo ne correspond pas aux
données originales et authentifiées, mais le message
Galileo I/NAV doit être cohérent, y compris CRC.
Critères de réussite et d’échec: le récepteur détecte les
fausses données dans un délai de 160 secondes et ne
calcule pas de position valide authentifiée jusqu’à la fin
de l’essai.
Appendice 12,
GNS_3 ter
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 423
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'inter­
pré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 protec­
tion correspondant doit être déclarée au cours du processus d'évalua­
tion.
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 — 21.08.2023 — 003.002 — 424
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 — 21.08.2023 — 003.002 — 425
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 — 21.08.2023 — 003.002 — 426
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 — 21.08.2023 — 003.002 — 427
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 — 21.08.2023 — 003.002 — 428
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 — 21.08.2023 — 003.002 — 429
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 — 21.08.2023 — 003.002 — 430
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 europé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 organisme 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 certification
européen. La clé privée de l'État membre permettra d'homo­
loguer les clés publiques à introduire dans l'équipement (unité
embarquée sur le véhicule ou carte tachygraphique). Des
registres de l'ensemble des clés publiques certifié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'équi­
pement ou autorités compétentes à l'échelon national. Cette
paire de clés sera utilisée par les services d'authentification, 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
archivage.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 431
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 introduiront, dans
les équipements en cours de certification de type, des clés de
test certifiées par l'une des clés de test nationales.
3.1.3 Clés du capteur de 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 orga­
nismes de certification des États membres qui en font la
demande.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 432
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écurisée.
Sa validité expirera à la fin de la session (retrait ou réinitia­
lisation de la carte) et/ou après 240 usages (définition d'un
usage de la clé: l'envoi d'une commande recourant à la messa­
gerie 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 — 21.08.2023 — 003.002 — 433
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’
B
al
is
e
de
l
is
te
e
n-
tê
te
é
te
nd
ue

L
on
gu
eu
r
de
l
a
li
st
e
en
-t
êt
e
B
al
is
e
C
P
I
L
on
gu
eu
r
C
P
I
B
al
is
e
C
A
R

L
on
gu
eu
r
C
A
R

B
al
is
e
C
H
A

L
on
gu
eu
r
C
H
A

B
al
is
e
E
O
V

L
on
gu
eu
r
E
O
V

B
al
is
e
C
H
R

L
on
gu
eu
r
C
H
R

B
al
is
e
de
c
lé
p
ub
li
qu
e
(c
on
st
ru
it
e)

L
on
gu
eu
r
de
s
ob
je
ts
d
e
do
nn
ée
s
ul
té
ri
eu
rs

B
al
is
e
m
od
ul
e
L
on
gu
eu
r
m
od
ul
e
B
al
is
e
ex
po
sa
nt
p
ub
li
c
L
on
gu
eu
r
ex
po
sa
nt
p
ub
li
c
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 — 21.08.2023 — 003.002 — 434
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
introduites.
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'affectation des clés à l'équipement concerné (c.-à-d., les
données d'identification de la demande de certificat et d'identifi­
cation de l'équipement visé) après leur installation sur cet équi­
pement. 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 certi­
ficat
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 — 21.08.2023 — 003.002 — 435
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-utilisation
‘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 certifica­
tion» 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’
B
al
is
e
ce
rt
if
ic
at
C
V
(
co
ns
tr
ui
te
)
L
on
gu
eu
r
de
s
ob
je
ts
d
e
do
nn
ée
s
ul
té
ri
eu
rs

B
al
is
e
si
gn
at
ur
e
L
on
gu
eu
r
si
gn
at
ur
e
B
al
is
e
so
ld
e
L
on
gu
eu
r
so
ld
e
B
al
is
e
C
A
R

L
on
gu
eu
r
C
A
R

▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 436
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 — 21.08.2023 — 003.002 — 437
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 — 21.08.2023 — 003.002 — 438
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 439
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
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émo­
nique
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 — 21.08.2023 — 003.002 — 440
É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] [nouveau
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
correspondantes.
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 confidentialité:
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 — 21.08.2023 — 003.002 — 441
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 mani­
festation d'erreurs de SM:
‘66 88’: Échec de la vérification du total de contrôle
cryptographique,
‘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)).
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 442
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.
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 — 21.08.2023 — 003.002 — 443
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 enregistré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 — 21.08.2023 — 003.002 — 444
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 — 21.08.2023 — 003.002 — 445
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 — 21.08.2023 — 003.002 — 446
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 — 21.08.2023 — 003.002 — 447
— 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 — 21.08.2023 — 003.002 — 448
ou externe à la VU; cf. appendice 14. Cependant,
l'interrogateur distant adresse les données reçues à
une carte de contrôle qui les déchiffre et valide leur
authenticité. Du point de vue de la sécurité, le dispo­
sitif 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 — 21.08.2023 — 003.002 — 449
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
(quasiment) égale. Le Tableau 2 montre les méthodes de
cryptage 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
fonctionnels:
— niveau européen,
— niveau État membre,
— niveau équipement.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 450
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 — 21.08.2023 — 003.002 — 451
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
correspondant,
— 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 certificats 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 — 21.08.2023 — 003.002 — 452
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 — 21.08.2023 — 003.002 — 453
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 — 21.08.2023 — 003.002 — 454
— 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 — 21.08.2023 — 003.002 — 455
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 — 21.08.2023 — 003.002 — 456
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 correspondant, 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 — 21.08.2023 — 003.002 — 457
— 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 — 21.08.2023 — 003.002 — 458
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 — 21.08.2023 — 003.002 — 459
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'appendice 2.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 460
— 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ération.
— 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
mouvement.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 461
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
mouvement.
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'expi­
ration de la paire de clés racine ERCA associée. La Figure 2
illustre ce principe.
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 462
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 — 21.08.2023 — 003.002 — 463
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 — 21.08.2023 — 003.002 — 464
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'atelier é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écessaire pour instan­
cier la fonction de hachage HMAC est liée à la longueur de
la clé maîtresse DSRC, conformément au CSM_50. La fonc­
tion 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 — 21.08.2023 — 003.002 — 465
É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 — 21.08.2023 — 003.002 — 466
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 — 21.08.2023 — 003.002 — 467
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 — 21.08.2023 — 003.002 — 468
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
domaines
DP ‘06’ var
Point public PP ‘86’ var
Référence du titulaire
de certificat
CHR ‘5F 20’ ‘08’
Date d'entrée en
vigueur du certificat
CEfD ‘5F 25’ ‘04’
Date d'expiration du
certificat
CExD ‘5F 24’ ‘04’
Signature du certificat
ECC
S ‘5F 37’ var
Note: l'ID de champ sert dans les sections ultérieures du
présent appendice à indiquer les zones individuelles d'un
certificat, p. ex. X.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 — 21.08.2023 — 003.002 — 469
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
certificat, connaît ou non le numéro de série propre au
fabricant de la VU à laquelle s'adresse ce certificat et la
clé privée associée. Dans le premier cas, la référence
du titulaire de certificat relève du type de données
comme précisé en appen­
dice 1. Dans le dernier cas, la référence du titulaire
de certificat relève du type de données
comme précisé en appen­
dice 1.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 470
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’appen­
dice 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'appendice 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
modifications,
— le champ de deux octets contenant les informations
complémentaires spécifiques à l'organisme de
certification.
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 471
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 — 21.08.2023 — 003.002 — 472
— 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
certificat» (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 — 21.08.2023 — 003.002 — 473
— 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 certi­
ficat, conformément à la section 9.3.2. ►M1 Si l’enregis­
trement 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 — 21.08.2023 — 003.002 — 474
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 — 21.08.2023 — 003.002 — 475
— 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 — 21.08.2023 — 003.002 — 476
— 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 — 21.08.2023 — 003.002 — 477
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'abscisse du point public éphémère ECDH comme identifi­
cation 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’authentification 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
expiré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 — 21.08.2023 — 003.002 — 478
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 — 21.08.2023 — 003.002 — 479
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 — 21.08.2023 — 003.002 — 480
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 — 21.08.2023 — 003.002 — 481
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é
embarqué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 — 21.08.2023 — 003.002 — 482
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'émission (SSC) pour empêcher les attaques par relecture.
La taille du SSC est égale à la taille du bloc AES, soit
128 bits. Le SSC respecte la structure MSB-First. Le
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 — 21.08.2023 — 003.002 — 483
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 — 21.08.2023 — 003.002 — 484
— 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 — 21.08.2023 — 003.002 — 485
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 — 21.08.2023 — 003.002 — 486
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 asso­
ciées de SM par session.
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 487
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 asso­
ciées de SM par session.
▼B
CSM_194 Concernant la gestion des erreurs de SM par une carte
tachygraphique:
— 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 tachygraphique 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
tachygraphique:
— détruisent de façon sécurisée les clés de sessions mémo­
risées;
— établissent immédiatement une nouvelle session de messa­
gerie 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 — 21.08.2023 — 003.002 — 488
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 communi­
cation 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 communication sécu­
risé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 mention­
nées au chapitre 10 pour les cartes tachygraphiques sont satis­
faites par l'EGF et tiennent compte des écarts, clarifications et
ajouts mentionnés au présent chapitre. En particulier, la véri­
fication de la chaîne de certification mutuelle, l'authentifica­
tion 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 puis­
sent échanger des données basées GNSS en fonctionnement
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 description
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 certificat
VU_MA de la VU à laquelle il vient d'être couplé.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 489
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 fonctionne­
ment 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 vali­
dité dans le temps. La VU et l'EGF ne font confiance à aucun
autre certificat pour protéger la communication 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 vraisembla­
blement pas une Réinitialisation pour lancer la communi­
cation 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 — 21.08.2023 — 003.002 — 490
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'authentification
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 vrai­
semblablement pas une réinitialisation pour lancer la commu­
nication et ne recevra pas d'ATR. Dans tous les cas, cela sort
du champ d'application du présent appendice.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 491
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'appli­
quent.
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 — 21.08.2023 — 003.002 — 492
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ération
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 corres­
pondance, la VU est authentifiée. Le capteur de mouve­
ment 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 relatives
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 493
mouvement à l'étape précédente. Dans l'affirmative, cela
prouve que le capteur de mouvement utilise 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ération de K M . Le
capteur de mouvement est ainsi authentifié.
Note: les étapes 2 et 5 divergent de la procédure normalisée
[ISO 16844-3]; les autres étapes restent standard.
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 — 21.08.2023 — 003.002 — 494
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 communica­
tion 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’authen.
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 — 21.08.2023 — 003.002 — 495
— 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'entrelace­
ment 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'authen­
tification 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 — 21.08.2023 — 003.002 — 496
— 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 respon­
sable 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 confi­
dentialité 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 VuSe­
rialNumber 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 — 21.08.2023 — 003.002 — 497
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 — 21.08.2023 — 003.002 — 498
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écurité
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 indiqué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'appendice 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 auto­
risé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 fonc­
tionnalité 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 — 21.08.2023 — 003.002 — 499
— 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 signature
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é temporelle 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 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 VU_Sign ou Card_Sign de deuxième génération
é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 — 21.08.2023 — 003.002 — 500
— 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, conformé­
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 asso­
ciée à un fichier de données téléchargé ou si cette vérification
échoue.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 501
Figure 13
Protocole de vérification de la signature associée à un fichier de données téléchargé
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 502
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
▼M3
1.1.1 Références
▼B
1.2. Abréviations et notations
▼M3
2. CARACTÉRISTIQUES DE BASE DU RÉCEPTEUR GNSS
3. PHRASES FOURNIES PAR LE RÉCEPTEUR GNSS
▼B
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
▼M3
4.2.4 Structure de la commande WriteRecord
4.2.5 Autres commandes
▼B
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
▼M3
5.2. Transfert d’informations du récepteur GNSS vers la VU
__________
5.3. Transfert d’informations de la VU vers le récepteur GNSS
5.4. Traitement des erreurs
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 503
5.4.1. Absence d’informations de positionnement en provenance du récepteur
GNSS
6. TRAITEMENT ET ENREGISTREMENT DES DONNÉES DE POSI­
TIONNEMENT PAR LA VU
7. CONFLIT TEMPOREL GNSS
8. CONFLIT CONCERNANT LE MOUVEMENT DU VÉHICULE
1. INTRODUCTION
Le présent appendice présente les exigences techniques applicables au
récepteur GNSS et 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.
1.1. Champ d’application
GNS_1 L’unité embarquée sur véhicule recueille des données de loca­
lisation à partir d’au moins un réseau satellite GNSS.
L’unité embarquée sur le véhicule peut disposer ou non d’un
dispositif GNSS externe, comme illustré à la figure 1:
1.1.1 Références
Le présent appendice emploie les références suivantes:
NMEA Norme d’interface NMEA (“National Marine Electronics Asso­
ciation”) 0183, V4.11
▼B
Figure 1
Différentes configurations du récepteur GNSS
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 504
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
▼M3
OSNMA “Galileo Open Service Navigation Message Authentication”
(service d’authentification des messages de navigation en
service ouvert de Galileo)
▼B
PDOP Affaiblissement de la précision de position
RMC Minimum spécifique recommandé
▼M3
RTC “Real Time Clock” (horloge en temps réel)
▼B
SIS Signal dans l'espace
VDOP Affaiblissement de la précision verticale
VU Unité embarquée sur le véhicule
▼M3
2. CARACTÉRISTIQUES DE BASE DU RÉCEPTEUR GNSS
▼B
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 compati­
bles avec les services de positionnement fournis par
les systèmes Galileo et EGNOS. Les fabricants ont
également la possibilité de choisir, en plus, d'assurer
la compatibilité avec d'autres systèmes de navigation
par satellite.
▼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 — 21.08.2023 — 003.002 — 505
GNS_3 Le récepteur GNSS doit être capable de prendre en
charge l’authentification des messages de navigation
sur le service ouvert de Galileo (OSNMA).
GNS_3 bis GNS_Le récepteur GNSS doit effectuer un certain
nombre de contrôles de cohérence afin de vérifier
que les mesures calculées par le récepteur GNSS sur
la base des données OSNMA ont permis d’obtenir des
informations correctes sur la position, la vitesse et les
données du véhicule et n’ont donc pas été influencées
par une attaque externe telle que des opérations de
transplexion. Ces contrôles de cohérence doivent
consister, par exemple, en:
— la détection des émissions de puissance anormales
au moyen de la surveillance combinée du système
de contrôle automatique du gain (AGC) et du
rapport de densité porteuse-bruit (C/N0),
— la vérification de la cohérence des mesures de la
pseudodistance et des mesures Doppler dans le
temps, y compris la détection de variations
brusques des mesures,
— techniques de surveillance de l’intégrité de l’auto­
nomie du récepteur (“receiver autonomous inte­
grity monitoring” – RAIM), y compris la détection
de mesures divergentes par rapport à la position
estimée,
— contrôles de position et de vitesse, y compris les
solutions de position et de vitesse anormales, les
variations brusques et les comportements qui ne
cadrent pas avec la dynamique du véhicule,
— la cohérence entre les valeurs de temps et de
fréquence, y compris les variations brusques de
temps et les dérivations qui ne cadrent pas avec
les caractéristiques de l’horloge du récepteur.
GNS_3 ter La Commission européenne élabore et approuve les
documents suivants:
— Un document de contrôle des signaux dans les
interfaces spatiales (“Signal in Space Interface
Control Document” – SIS ICD) décrivant en
détail les informations OSNMA transmises dans
le signal Galileo.
— Lignes directrices concernant les récepteurs
OSNMA, qui définissent les exigences et les
procédures des récepteurs afin de garantir une
mise en œuvre sûre du service OSNMA, ainsi
que des recommandations visant à améliorer les
performances du service OSNMA.
Les récepteurs GNSS installés dans les tachygraphes,
internes ou externes, sont construits conformément au
code SIS ICD et aux lignes directrices concernant les
récepteurs OSNMA.
GNS_3 quater Le récepteur GNSS fournit des messages de position,
appelés messages de position authentifiés dans la
présente annexe et ses appendices, qui sont élaborés
exclusivement à l’aide de messages de navigation
satellites dont l’authenticité a été vérifiée avec succès.
GNS_3 quinquies Le récepteur GNSS fournit également des messages
de positionnement standard, élaborés à l’aide des
satellites en vue, qu’ils soient authentifiés ou non.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 506
GNS_3 sexies Le récepteur GNSS utilise l’horloge en temps
réel (RTC) de la VU comme référence temporelle
pour la synchronisation du temps nécessaire à
OSNMA.
GNS_3 septies L’heure de la RTC de la VU est fournie au récepteur
GNSS par la VU.
GNS_3 octies La dérive temporelle maximale spécifiée à
l’exigence 41 de l’annexe IC est fournie au récepteur
GNSS par la VU, avec l’heure de la RTC de la VU.
3. PHRASES FOURNIES PAR LE RÉCEPTEUR GNSS
La présente section décrit les phrases utilisées pendant le fonctionnement
du tachygraphe intelligent pour transmettre des messages de position
standard et authentifiés. Cette section est applicable à la configuration
du tachygraphe intelligent avec et sans dispositif GNSS externe.
GNS_4 Les données de positionnement standard reposent sur les
données GNSS du minimum spécifique recommandé
(RMC) de la phrase NMEA, qui contiennent les informa­
tions 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.11):
Figure 2
Structure de la phrase RMC
$–RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x .x,xxxx,x.x,a,a,a*hh
1) Heure (TUC)
2) Statut, A= Position valide, V= Avertissement
3) Latitude
4) N ou S
5) Longitude
6) E ou O
7) Vitesse sur le fond en nœuds
8) Route suivie, degrés vrais
9) Date, jjmmaa
10) Variation magnétique, degrés
11) E ou O
12) Indicateur de mode FAA
13) État de navigation
14) Total de contrôle
L'état de navigation est facultatif et peut être absent de la
phrase RMC.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 507
L’état indique la disponibilité du signal GNSS. Tant que la
valeur de l’état n’est pas fixée à “A”, les données reçues
(c’est-à-dire l’heure ou la latitude ou la longitude) ne
peuvent pas servir à enregistrer la position du véhicule
dans la VU.
La résolution de la position repose sur la structure de la
phrase RMC décrite ci-dessus. La première partie des
champs 3) et 5) correspond 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_4 bis Les données de positionnement authentifiées reposent sur
une phrase de type NMEA, les données spécifiques mini­
males authentifiées (AMC), qui contiennent les informa­
tions 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 AMC est la suivante (d’après la
norme NMEA V4.11,sauf pour la valeur n o 2):
Figure 3
Structure de la phrase AMC
$–AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
1) Heure (TUC)
2) Statut, A=position authentifiée (établie à l’aide de messages de navigation
provenant d’au moins 4 satellites dont l’authenticité a été vérifiée avec
succès), J=brouillage ou O=autre attaque GNSS en l’absence d’échec de
l’authentification des messages de navigation (par des contrôles de cohérence
mis en œuvre conformément à l’exigence GNS_3 bis), F=échec de l’authen­
tification des messages de navigation (tel que détecté par les vérifications
OSNMA spécifiées dans les documents visés à l’exigence GNS_3 ter), V
=néant (la position authentifiée n’est pas disponible pour un autre motif)
3) Latitude
4) N ou S
5) Longitude
6) E ou O
7) Vitesse sur le fond en nœuds
8) Route suivie, degrés vrais
9) Date, jjmmaa
10) Variation magnétique, degrés
11) E ou O
12) Indicateur de mode FAA
13) État de navigation
14) Total de contrôle
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 508
L'état de navigation est facultatif et peut être absent de la
phrase AMC.
Le statut indique si une position GNSS authentifiée est
disponible, si une attaque contre les signaux GNSS a été
détectée, si l’authentification des messages de navigation a
échoué ou si la position GNSS est indisponible. Tant que la
valeur du statut n’est pas fixée à “A”, les données reçues
(par exemple l’heure ou la latitude ou la longitude) sont
considérées comme non valides et ne peuvent pas servir à
enregistrer la position du véhicule dans la VU. Lorsque la
valeur du statut est fixée à “J” (brouillage), “O” (autre
attaque GNSS) ou “F” (échec de l’authentification des
messages de navigation), un événement d’anomalie GNSS
est enregistré dans la VU, comme défini à l’annexe IC et à
l’appendice 1 (EventFaultCode).
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 position­
nement 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 types.
La VU peut utiliser la commande GPS DOP et satellites
actifs (GSA), conformément à la norme NMEA V4.11,
pour déterminer et enregistrer la disponibilité du signal et
l’exactitude des positionnements standard. En particulier,
HDOP sert à fournir une indication sur le degré d’exacti­
tude des données de localisation enregistrées (cf. 4.2.2). La
VU enregistre la valeur du coefficient d’affaiblissement de
la précision de positionnement horizontal (HDOP) calculée
comme étant la minimale des valeurs HDOP recueillies sur
les systèmes GNSS disponibles.
L’identificateur du système GNSS indique l’identifiant
NMEA correspondant pour chaque constellation GNSS et
pour le SBAS (Satellite-Based Augmentation System).
Figure 4
Structure de la phrase GSA (positionnements standard)
$–GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h
1) Mode de sélection
2) Mode
3) ID du 1 er satellite utilisé comme point de repère
4) ID du 2 e satellite utilisé comme point de repère
…
14) ID du 12 e satellite utilisé comme point de repère
15) PDOP
16) HDOP
17) VDOP
18) ID de système
19) Total de contrôle
L'ID de système est facultatif et peut être absent de la
phrase GSA.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 509
De même, la VU peut utiliser la phrase satellites actifs
authentifiés (ASA) de type NMEA pour déterminer et enre­
gistrer la disponibilité du signal et l’exactitude des position­
nements authentifiés. Les valeurs 1 à 18 sont définies dans
la norme NMEA V4.11.
Figure 5
Structure de la phrase ASA (positionnements authentifiés)
$–ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h
1) Mode de sélection
2) Mode
3) ID du 1 er satellite utilisé comme point de repère
4) ID du 2 e satellite utilisé comme point de repère
…
14) ID du 12 e satellite utilisé comme point de repère
15) PDOP
16) HDOP
17) VDOP
18) ID de système
19) Total de contrôle
L'ID de système est facultatif et peut être absent de la
phrase ASA.
GNS_6 Lorsqu’un dispositif GNSS externe est utilisé, la phrase
GSA doit être stockée dans l’émetteur-récepteur sécurisé
GNSS avec les numéros d’enregistrement ‘02’ à ‘06’, et
la phrase ASA avec les numéros d’enregistrement ‘12’ à
‘16’.
GNS_7 La taille maximale des phrases (par exemple RMC, AMC,
GSA, ASA ou d’autres), qui peut servir à étalonner la
commande Read Record, est de 85 octets (cf. tableau 1).
▼B
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 inter­
face de véhicule spécifique.
▼M3
GNS_9 Le dispositif GNSS externe se compose des éléments
suivants (cf. figure 6):
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 510
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.11 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 et de type NMEA, lequel doit
comprendre au moins les phrases RMC, AMC, GSA
et ASA. Le choix de la mise en œuvre de l’interface
de données GNSS revient aux fabricants du dispositif
GNSS externe.
▼B
b) Une unité d'émetteur-récepteur (émetteur-récepteur sécu­
risé GNSS) compatible avec la norme ISO/IEC 7816-
4:2013 (cf. 4.2.1) pour communiquer avec l'unité embar­
qué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 rela­
tives à l'identification du récepteur GNSS et du dispo­
sitif GNSS externe.
▼M3
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écepteur sécurisé GNSS. La fonction de détection des
fraudes met en pratique les mesures de protection de la
sécurité comme les définit le profil de protection du
tachygraphe intelligent.
▼B
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'émetteur-récepteur sécurisé GNSS. Il respecte la
norme ISO/IEC 7816-4:2013 relative à la connexion au
dispositif GNSS externe.
GNS_12 Pour la couche de communication avec le dispositif GNSS
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écu­
risé 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,
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 511
— 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
▼M3
GNS_14 Le protocole de communication entre le dispositif
GNSS externe et l’unité embarquée sur véhicule
remplit les fonctions suivantes:
1. la collecte et la distribution des données GNSS
(par exemple la position, l’heure et la vitesse),
2. la collecte des données de configuration du dispo­
sitif GNSS externe,
3. le protocole de gestion à l’appui de l’appariement,
de l’authentification mutuelle et de la concordance
de clés de session entre le dispositif GNSS externe
et la VU.
4. la transmission au dispositif GNSS externe de
l’heure de la RTC de la VU et de la différence
maximale entre l’heure réelle et l’heure de la RTC
de la VU.
▼B
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
▼M1
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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 512
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 intelligente 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.
▼M3
GNS_18 bis En ce qui concerne la fonction 4), la transmission au
dispositif GNSS externe de l’heure de la RTC de la
VU et de la différence maximale entre l’heure réelle
et l’heure de la RTC de la VU, l’émetteur-récepteur
sécurisé GNSS utilisera un EF (“EF VU”) dans le
même DF avec un identifiant de fichier égal à ‘2F30’
comme décrit dans 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 configu­
ration 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.
▼M3
GNS_19 bis L’émetteur-récepteur sécurisé GNSS mémorise les
données provenant de la VU dans le fichier “EF
VU”. Il s’agit d’un fichier d’enregistrement d’une
longueur fixe et linéaire dont l’identificateur corres­
pond à ‘2F30’ au format hexadécimal
GNS_20 L’émetteur-récepteur sécurisé GNSS utilise une
mémoire pour stocker les données et être capable
d’effectuer autant de cycles de lecture/écriture que
nécessaire pendant une durée de vie d’au moins
15 ans. Hormis cet aspect, la conception interne et
la mise en œuvre de l’émetteur-récepteur sécurisé
GNSS incombent aux fabricants.
▼M1
Le tableau 1 fournit la modélisation des numéros
d’enregistrement 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. Concer­
nant les règles d'accès (ALW, NEV, SM-MAC), cf.
appendice 2, chapitre 3.5.
▼M3
Tableau 1
Structure de fichier
Conditions d’accès
Fichier ID fichier Lecture Mise à jour Crypté
MF 3F00
EF.ICC 0002 ALW NEV
(par la VU)
Non
▼M1
02016R0799 — FR — 21.08.2023 — 003.002 — 513
Conditions d’accès
Fichier ID fichier Lecture Mise à jour Crypté
Dispositif DF GNSS 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
EF VU 2F30 SM-MAC SM-MAC Non
Fichier/Élément d’information
Numéro de
l’enregistre­
ment
Taille (octets)
Valeurs par
défaut
Min Max
MF 552 1031
EF.ICC
sensorGNSSSerialNumber 8 8
Dispositif DF GNSS 612 1023
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 re 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
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 514
Fichier/Élément d’information
Numéro de
l’enregistre­
ment
Taille (octets)
Valeurs par
défaut
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
Phrase AMC ‘11’ 85 85
1 re phrase ASA ‘12’ 85 85
2 e phrase ASA ‘13’ 85 85
3 e phrase ASA ‘14’ 85 85
4 e phrase ASA ‘15’ 85 85
5 e phrase ASA ‘16’ 85 85
RFU – Réservé pour une utilisation future De ‘17’ à
‘FD’
EF VU
VuRtcTime (cf. appendice 1) ‘01’ 4 4 {00..00}
VuGnssMaximalTimeDifference (cf.
appendice 1)
‘02’ 2 2 {00..00}
▼B
4.2.2 Transfert sécurisé de données GNSS
▼M3
GNS_22 Le transfert sécurisé des données de positionnement
GNSS, du temps de la RTC de la VU et de la diffé­
rence de temps maximale entre l’heure réelle et
l’heure de la RTC de la VU n’est autorisé que dans
les conditions suivantes:
▼B
1. La procédure d'appariement a abouti conformé­
ment aux dispositions de l'appendice 11. Méca­
nismes de sécurité communs.
2. L'authentification mutuelle régulière et la concor­
dance de clés de session entre la VU et le dispo­
sitif GNSS externe également décrites à l'appen­
dice 11. Les mécanismes de sécurité communs
sont appliqués à la fréquence indiquée.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 515
GNS_23 Toutes les T secondes, où T est une valeur inférieure
ou égale à 20, sauf pendant le déroulement de l’appa­
riement, de l’authentification mutuelle et de la
concordance de clés de session, la VU demande au
dispositif GNSS externe les informations de position­
nement selon la séquence suivante:
1. La VU demande les données de positionnement et
les données relatives à l’affaiblissement de la
précision (provenant des phrases GSA et ASA)
au dispositif GNSS externe. L’émetteur-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’identi­
ficateur de fichier ‘2F2F’ et le nombre de
RECORD égal à ‘01’ pour la phrase NMEA
RMC, les nombres ‘02’,‘03 ’,‘04 ’,‘05 ’,‘06 ’
pour la phrase GSA NMEA, le nombre ‘11’
pour la phrase AMC, et les nombres ‘12’,‘13
’,‘14 ’,‘15 ’,‘16 ’ pour la phrase ASA.
2. Les dernières données de positionnement reçues
sont mémorisées dans l’EF avec l’identificateur
‘2F2F’ et les enregistrements 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écu­
risée, comme le décrit l’appendice 11,
section 11.5.
4. L’émetteur-récepteur sécurisé de la VU contrôle
l’authenticité et l’intégrité de la réponse reçue.
En cas de résultat positif, les données de position­
nement sont transférées au processeur de la VU
par l’interface de données GNSS.
5. Le processeur de la VU vérifie les données reçues
en extrayant les informations (par exemple la lati­
tude, la longitude ou l’heure) de la phrase RMC
NMEA. Cette dernière inclut les informations si le
positionnement non authentifié est valide. Si le
positionnement non authentifié 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 (par exemple, lorsque les points de
repère sont disponibles).
6. Le processeur de la VU extrait également les
informations (par exemple la latitude, la longitude
ou l’heure) de la phrase AMC. La phrase AMC
inclut les informations si le positionnement authen­
tifié n’est pas valide ou si le signal GNSS a été
attaqué. Si le positionnement est valide, le proces­
seur de la VU extrait également les valeurs HDOP
des phrases ASA et calcule la valeur minimale
d’après les systèmes de satellites disponibles
(par exemple, lorsque les points de repère sont
disponibles).
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 516
GNS_23 bis La VU écrit également l’heure de la RTC de la VU et
la différence de temps maximale entre celle-ci et
l’heure réelle, le cas échéant, en utilisant les
commandes ISO/IEC 7816-4:2013 SELECT et
WRITE RECORD(S) en mode authentification
uniquement de la messagerie sécurisée, comme
indiqué à l’appendice 11, section 11.5, avec l’identi­
ficateur de fichier ‘2F30’ et le numéro RECORD égal
à ‘01’ pour VuRtcTime et à ‘02’ pour MaximalTime­
Difference.
▼B
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 disposi­
tions de l'appendice 11 Mécanismes de sécurité communs.
GNS_24 La commande est compatible avec le mode authenti­
fication uniquement de la messagerie sécurisée;
cf. appendice 11.
GNS_25 Message de commande
Octet Longueur 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'enregistrement en cours).
P2 1 ‘04h’ Lire l'enregistrement avec le nombre
d'enregistrements indiqué en P1.
Le 1 ‘XXh’ Longueur de données prévisible.
Nombre d'octets à extraire.
GNS_26 L'enregistrement référencé en P1 devient l'enregistre­
ment en cours.
Octet Longueur 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écu­
risé GNSS renvoie ‘9000’.
— Si le fichier en cours n'est pas orienté enregistre­
ment, 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écu­
risé GNSS renvoie ‘6986’ (commande interdite).
▼M3
— Si l’enregistrement est introuvable, l’émetteur-
récepteur sécurisé GNSS renvoie ‘6A83’.
— Si le dispositif GNSS externe détecte une fraude,
il renvoie les mots de statut ‘6690’.
__________
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 517
4.2.4 Structure de la commande WriteRecord
La présente section décrit en détail la structure de la commande “Write
Record” (lecture des enregistrements). La messagerie sécurisée (mode
authentification uniquement) est ajoutée conformément aux disposi­
tions de l’appendice 11 Mécanismes de sécurité communs.
GNS_26 bis La commande est compatible avec le mode authenti­
fication uniquement de la messagerie sécurisée; cf.
appendice 11.
GNS_26 ter Message de commande
Octet Longueur Valeur Description
CLA 1 ‘0Ch’ Messagerie sécurisée demandée.
INS 1 ‘D2h’ Write Record
P1 1 ‘XXh’ Nombre d’enregistrements (‘00’
indique l’enregistrement en cours)
P2 1 ‘04h’ Écrire l’enregistrement avec le
nombre d’enregistrements indiqué
en P1.
Données X ‘XXh’ Données
GNS_26 quater L’enregistrement référencé en P1 devient l’enregistre­
ment en cours.
Octet Longueur Valeur Description
SW 2 ‘XXXXh’ Mots de statut (SW1, SW2)
— Si la commande aboutit, l’émetteur-récepteur
sécurisé GNSS renvoie ‘9000’.
— Si le fichier en cours n’est pas orienté enregis­
trement, 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 inter­
dite).
— Si l’enregistrement est introuvable, l’émetteur-
récepteur sécurisé GNSS renvoie ‘6A83’.
— Si le dispositif GNSS externe détecte une fraude,
il renvoie les mots de statut ‘6690’.
4.2.5 Autres commandes
GNS_27 L’émetteur-récepteur sécurisé GNSS est compatible
avec les commandes suivantes de la deuxième géné­
ration de tachygraphes, définies à l’appendice 2:
Commande Référence
Sélectionner 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
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 518
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
▼M3
GNS_28 Les événements correspondant à des erreurs de
communication avec le dispositif GNSS externe
sont enregistrés dans la VU, conformément à
l’exigence 82 de l’annexe IC et à l’appendice 1
(EventFaultType). Dans ce contexte, une erreur de
communication 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
▼M3
GNS_29 En cas d’atteinte au dispositif GNSS externe, l’émet­
teur-récepteur sécurisé GNSS veille à ce que le maté­
riel cryptographique soit indisponible. Comme le
prévoient les paragraphes GNS_25 et GNS_26, la
VU détecte les infractions si la réponse possède le
statut ‘6690’. La VU génère et enregistre ensuite un
événement de tentative d’atteinte à la sécurité tel que
défini à l’exigence 85 de l’annexe IC et à l’appen­
dice 1 (EventFaultType pour la détection de violation
du dispositif GNSS). Le dispositif GNSS externe peut
également répondre aux demandes de la VU sans
messagerie sécurisée et avec le statut ‘6A88’.
▼B
4.4.3 Absence d'informations de positionnement en provenance du récepteur
GNSS
▼M3
GNS_30 Si l’émetteur-récepteur sécurisé GNSS ne reçoit
aucune donnée du récepteur GNSS, 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. À la réception du message de
réponse avec cette valeur du champ de données, la
VU génère et enregistre un événement “Absence
d’informations de positionnement en provenance du
récepteur GNSS”, conformément à l’exigence 81 de
l’annexe IC et à l’appendice 1 (EventFaultType).
▼B
4.4.4 Expiration du certificat du dispositif GNSS externe
▼M3
GNS_31 Si la VU détecte que le certificat EGF utilisé pour
l’authentification mutuelle n’est plus valable, la VU
génère et enregistre un événement “Tentative
d’atteinte à la sécurité” conformément à l’exigence 85
de l’annexe IC et à l’appendice 1 (EventFaultType
pour certificat de dispositif GNSS externe expiré). La
VU utilise encore les données de positionnement
GNSS reçues.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 519
Figure 6
Schéma du dispositif GNSS externe
▼B
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.
▼M3
GNS_32 Pour la transmission de données de position, de
données DOP et de données satellites, le récepteur
GNSS tient le rôle de l’émetteur qui transmet les
phrases NMEA ou de type 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, lequel doit comprendre au moins les
phrases RMC, GSA, AMC et ASA. Le processeur de
la VU et le récepteur GNSS interne peuvent égale­
ment utiliser d’autres structures de données pour
échanger les données contenues dans les phrases
NMEA ou de type NMEA spécifiées aux exigences
GNS_4, GNS_4 bis et GNS_5.
▼B
GNS_33 Une antenne GNSS externe installée sur le véhicule ou
une antenne GNSS interne doit être connectée à la VU.
▼M3
5.2. Transfert d’informations du récepteur GNSS vers la VU
GNS_34 Le processeur de la VU vérifie les données reçues en
extrayant les informations (par exemple la latitude, la
longitude ou l’heure) de la phrase RMC NMEA et de
la phrase AMC.
GNS_35 Cette dernière inclut les informations si le positionne­
ment non authentifié est valide. Si tel n’est pas le cas,
les données de positionnement ne sont pas mises à
disposition et ne peuvent pas servir à enregistrer la
position du véhicule. Si le positionnement non authen­
tifié est valide, le processeur de la VU extrait également
les valeurs HDOP de GSA NMEA.
GNS_36 Le processeur de la VU extrait également les infor­
mations (par exemple la latitude, la longitude ou
l’heure) de la phrase AMC. La phrase AMC
indique si le positionnement non authentifié est
valide conformément à l’exigence GNS_4 bis. Si le
positionnement non authentifié est valide, le proces­
seur de la VU extrait également les valeurs HDOP
des phrases ASA.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 520
5.3. Transfert d’informations de la VU vers le récepteur GNSS
GNS_37 Le processeur de la VU fournit au récepteur GNSS
l’heure de la RTC de la VU et la différence maximale
entre celle-ci et le temps réel, conformément aux
exigences GNS_3 septies et GNS_3 octies.
5.4. Traitement des erreurs
5.4.1 Absence d’informations de position en provenance du récepteur GNSS
GNS_38 La VU génère et enregistre un événement «Absence
d’informations de positionnement en provenance du
récepteur GNSS», conformément à l’exigence 81 de
l’annexe IC et à l’appendice 1 (EventFaultType).
6. TRAITEMENT ET ENREGISTREMENT DES DONNÉES DE POSI­
TIONNEMENT PAR LA VU
Cette section est applicable à la configuration du tachygraphe intelli­
gent avec et sans dispositif GNSS externe.
GNS_39 Les données de positionnement sont stockées dans la
VU, accompagnées d’un drapeau indiquant si le posi­
tionnement a été authentifié. Lorsque les données de
positionnement doivent être enregistrées dans la VU,
les règles suivantes s’appliquent:
a) Si les positionnements authentifiés et standard
sont valides et cohérents, le positionnement stan­
dard et son exactitude sont enregistrés dans la
VU, et le drapeau doit être “authentifié”.
b) Si les positionnements authentifiés et standard
sont valides mais divergents, la VU stocke le
positionnement authentifié et son exactitude, et
le drapeau doit être “authentifié”.
c) Si le positionnement authentifié est valide et que
le positionnement standard n’est pas valide, la VU
enregistre le positionnement authentifié et son
exactitude, et le drapeau doit être “authentifié”.
d) Si le positionnement standard est valide et que le
positionnement authentifié n’est pas valide, la VU
enregistre le positionnement standard et son exac­
titude, et le drapeau doit être “authentifié”.
Les positionnements authentifiés et standard sont
considérés comme cohérents, comme le montre la
figure 7, lorsque le positionnement horizontal authen­
tifié se trouve dans un cercle centré sur le position­
nement horizontal standard, le rayon correspondant à
l’arrondi au nombre entier supérieur le plus proche de
la valeur R_H calculée selon la formule suivante:
R_H = 1,74 • σ UERE • HDOP
dans laquelle:
— R_H est le rayon relatif d’un cercle autour de la
position horizontale estimée, en mètres. Il s’agit
d’un indicateur utilisé pour vérifier la cohérence
entre les positionnements standard et les position­
nements authentifiés.
— pour l’erreur de gamme équivalente utilisateur
(UERE), qui modélise toutes les erreurs de
mesure pour l’application cible, y compris les
environnements urbains. Une valeur constante
de σ- UERE = 10 mètres doit être utilisée.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 521
— HDOP est l’affaiblissement de la précision hori­
zontale calculée par le récepteur GNSS.
— σ UERE . HDOP est l’estimation de l’erreur quadra­
tique moyenne dans le domaine horizontal.
Figure 7
Positionnements authentifiés et positionnements standard (non
authentifiés) cohérents
GNS_40 Lorsque la valeur du statut dans une phrase AMC reçue est
fixée à ‘J’, ‘O’ ou ‘F’ conformément à
l’exigence GNS_4 bis, la VU génère et enregistre un
événement “Anomalie GNSS”, conformément à
l’exigence 88 bis de l’annexe IC et à l’appendice 1 (Event­
FaultType). L’unité embarquée sur véhicule peut effectuer
des vérifications supplémentaires avant de stocker un
événement “Anomalie GNSS” après réception d’un statut
fixé à ‘J’ ou ‘O’.
7. CONFLIT TEMPOREL GNSS
GNS_41 Si la VU détecte un écart entre l’heure de la fonction de
mesure du temps de l’unité embarquée sur véhicule et
l’heure provenant des signaux GNSS, elle génère et enre­
gistre un événement “Conflit temporel GNSS”, conformé­
ment à l’exigence 86 de l’annexe IC et à l’appendice 1
(EventFaultType).
8. CONFLIT CONCERNANT LE MOUVEMENT DU VÉHICULE
GNS_42 La VU déclenche et enregistre un événement “Conflit
concernant le mouvement du véhicule” conformément à
l’exigence 84 de l’annexe IC dans le cas où les informa­
tions relatives au mouvement calculées à partir du capteur
de mouvement ne cadrent pas avec les informations rela­
tives au mouvement calculées à partir du récepteur GNSS
interne, du dispositif GNSS externe ou par une ou plusieurs
autres sources d’informations relatives au mouvement indé­
pendantes, conformément à l’exigence 26 de l’annexe IC.
L’événement “Conflit concernant le mouvement du véhi­
cule” est déclenché lorsque l’une des conditions de déclen­
chement suivantes se produit:
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 522
Condition de déclenchement 1:
La valeur moyenne tronquée des différences de vitesse
entre ces sources doit être utilisée, lorsque les informations
de positionnement du récepteur GNSS sont disponibles et
que le contact du véhicule est allumé, comme indiqué
ci-dessous:
— toutes les dix secondes maximum, la valeur absolue de
l’écart entre la vitesse du véhicule estimée par le dispo­
sitif GNSS et celle estimée par le capteur de mouve­
ment est calculée.
— toutes les données calculées dans une fenêtre horaire
comportant les cinq dernières minutes de mouvement
du véhicule servent à calculer la valeur moyenne tron­
quée.
— la valeur moyenne tronquée est calculée comme la
moyenne des 80 % de valeurs restantes après élimina­
tion des plus élevées en valeur absolue.
L’événement de conflit de mouvement du véhicule est
déclenché si la valeur moyenne tronquée dépasse
10 km/h pendant cinq minutes de circulation du véhicule
ininterrompues. (remarque: l’utilisation de la moyenne
tronquée au cours des cinq dernières minutes est appliquée
pour atténuer le risque de mesure des valeurs aberrantes et
transitoires).
Pour le calcul de la moyenne tronquée, le véhicule est
considéré comme en mouvement si au moins une valeur
de vitesse du véhicule estimée soit à partir du capteur de
mouvement soit à partir du récepteur GNSS n’est pas égale
à zéro.
Condition de déclenchement 2:
L’événement “Conflit concernant le mouvement du véhi­
cule” est également déclenché si la condition suivante est
vraie:
GnssDistance > [OdometerDifference × OdometerToleran­
ceFactor + Minimum (SlipDistanceUpperlimit; (Odometer­
Difference × SlipFactor)) + GnssTolerance + FerryTrain­
Distance]
lorsque:
— GnssDistance est la distance entre la position actuelle
du véhicule et la position précédente, toutes deux obte­
nues à partir de messages de positionnement authenti­
fiés valides, sans tenir compte de la hauteur,
— OdometerDifference est la différence entre le kilomé­
trage actuel et le kilométrage correspondant au précé­
dent message de positionnement authentifié valide,
— OdometerToleranceFactor est égal à 1,1 (facteur de
tolérance le plus défavorable pour toutes les tolérances
de mesure du compteur kilométrique du véhicule),
— GnssTolerance est égale à 1 km (tolérance GNSS la
plus défavorable),
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 523
— Minimum [SlipDistanceUpperLimit; (OdometerDiffe­
rence * SlipFactor)] est la valeur la plus faible entre:
— SlipDistanceUpperLimit, soit 10 km (limite supé­
rieure de la distance glissante due aux effets de
glissement pendant le freinage),
— et OdometerDifference * SlipFactor, où SlipFactor
est égal à 0,2 (influence maximale des effets de
glissement pendant le freinage),
— FerryTrainDistance est calculé comme suit: FerryTrain­
Distance = 200 km/h * tFerryTrain, où tFerryTrain est
la somme des durées en heures de trajet du ferry/train
dans l’intervalle de temps considéré. La durée d’un
trajet en ferry/train est définie comme la différence de
temps entre le drapeau de fin et le drapeau de début.
Les vérifications précédentes doivent être effectuées toutes
les 15 minutes si les données de positionnement néces­
saires sont disponibles, ou dès que les données de position­
nement sont disponibles.
Pour cette condition de déclenchement:
— la date et l’heure du début de l’événement sont égales à
la date et à l’heure de réception du message de posi­
tionnement précédent,
— la date et l’heure de la fin de l’événement sont égales à
la date et à l’heure auxquelles la condition contrôlée
redevient fausse.
Condition de déclenchement 3:
L’unité embarquée sur véhicule constate un écart entre le
capteur de mouvement qui ne détecte aucun mouvement et
la source indépendante qui détecte des mouvements
pendant une période déterminée. Les conditions d’enregis­
trement de l’écart ainsi que la période de détection de
l’écart sont fixées par le fabricant de l’unité embarquée
sur véhicule, mais l’écart doit être détecté dans un délai
maximal de trois heures.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 524
Appendice 13
INTERFACE ITS
TABLE DES MATIÈRES
1. INTRODUCTION
1.1. Champ d’application
1.2. Abréviations et définitions
2. NORMES DE RÉFÉRENCE
3. PRINCIPES DE FONCTIONNEMENT DE L’INTERFACE ITS
3.1. Technologie de communication
3.2. Services disponibles
3.3. Accès par l’intermédiaire de l’interface ITS
3.4. Données disponibles et nécessité du consentement du conducteur
4. LISTE DES DONNÉES DISPONIBLES PAR L’INTERMÉDIAIRE DE
L’INTERFACE ITS ET CLASSIFICATION À CARACTÈRE
PERSONNEL/SANS CARACTÈRE PERSONNEL
1. INTRODUCTION
1.1. Champ d’application
ITS_01 Le présent appendice spécifie les bases de la communication par
l’intermédiaire de l’interface tachygraphique avec les systèmes de
transport intelligents (ITS), conformément aux articles 10 et 11 du
règlement (UE) n o 165/2014.
ITS_02 L’interface ITS doit permettre aux dispositifs externes d’obtenir
des données du tachygraphe, d’utiliser des services de tachygraphe
et de fournir des données au tachygraphe.
D’autres interfaces tachygraphiques (par exemple, bus CAN)
peuvent également être utilisées à cette fin.
Le présent appendice ne précise pas:
— les modalités de collecte et de gestion des données fournies par
l’intermédiaire de l’interface ITS se rapportant au tachygraphe,
— la forme de la présentation des données collectées pour les
applications hébergées sur le dispositif externe,
— la spécification de sécurité ITS en plus de ce qui fournit Blue­
tooth®,
— les protocoles Bluetooth® qu’utilise l’interface ITS.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 525
1.2. Abréviations et définitions
Les abréviations et définitions suivantes sont utilisées spécifiquement dans
le présent appendice:
GNSS “Global Navigation Satellite System” (système mondial de
radionavigation par satellite)
ITS “Intelligent Transport System” (système de transport intel­
ligent)
OSI “Open Systems Interconnection” (interconnexion de
systèmes ouverts)
VU “Vehicle Unit” (unité embarquée sur véhicule)
Unité ITS Un dispositif ou une application externe utilisant l’interface
ITS de la VU.
2. NORMES DE RÉFÉRENCE
ITS_03 Le 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 sont visées dans le présent appendice. En cas de
conflit, les dispositions du présent appendice prévalent.
Les normes mentionnées dans le présent appendice sont les
suivantes:
— Bluetooth® – Version standard 5.0
— ISO 16844-7: Véhicules routiers - Systèmes tachygraphes -
Partie 7: Paramètres
— ISO/IEC 7498-1: 1994, Technologies de l’information – Inter­
connexion de systèmes ouverts – Modèle de référence de base:
Le modèle de base.
3. PRINCIPES DE FONCTIONNEMENT DE L’INTERFACE ITS
ITS_04 La VU est responsable de l’actualisation et de la mémorisation des
données tachygraphiques transmises par l’intermédiaire de l’inter­
face ITS, sans impliquer l’interface ITS.
3.1. Technologie de communication
ITS_05 La communication par l’intermédiaire de l’interface ITS doit être
effectuée par l’intermédiaire de l’interface Bluetooth® et être
compatible avec Bluetooth® Low Energy conformément à Blue­
tooth version 5.0 ou une version plus récente.
ITS_06 La communication entre la VU et l’unité ITS est établie après
l’achèvement d’un processus de couplage Bluetooth®.
ITS_07 Une communication sécurisée et cryptée est établie entre la VU et
l’unité ITS, conformément aux mécanismes de spécification Blue­
tooth®. Le présent appendice ne précise pas de mécanismes de
cryptage ou d’autres mécanismes de sécurité en plus de ce que
prévoit Bluetooth®.
ITS_08 Bluetooth® utilise un modèle serveur/client pour contrôler la trans­
mission de données entre appareils, dans lequel la VU fera office
de serveur et l’unité ITS de client.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 526
3.2. Services disponibles
ITS_09 Les données à transmettre par l’intermédiaire de l’interface ITS
conformément au point 4 sont mises à disposition par l’inter­
médiaire des services spécifiés aux appendices 7 et 8. En outre,
la VU met à la disposition de l’unité ITS les services nécessaires à
la saisie manuelle de données conformément à l’exigence 61 de
l’annexe IC, et, éventuellement, à la saisie d’autres données en
temps réel.
Figure 1
Cloisonnement de la communication par l’interface ITS selon les couches du modèle OSI
(interconnexion de systèmes ouverts)
ITS_10 Lorsque l’interface de téléchargement est utilisée par l’inter­
médiaire du connecteur frontal, la VU ne fournit pas les services
de téléchargement spécifiés à l’appendice 7 par l’intermédiaire de
la connexion ITS Bluetooth®.
ITS_11 Lorsque l’interface d’étalonnage est utilisée par l’intermédiaire du
connecteur frontal, la VU ne fournit pas les services d’étalonnage
spécifiés à l’appendice 8 par l’intermédiaire de la connexion ITS
Bluetooth®.
3.3. Accès par l’intermédiaire de l’interface ITS
ITS_12 L’interface ITS fournit un accès sans fil à tous les services spéci­
fiés aux appendices 7 et 8, en remplacement de la connexion par
câble au connecteur frontal à des fins d’étalonnage et de téléchar­
gement spécifiée à l’appendice 6.
ITS_13 La VU met l’interface ITS à la disposition de l’utilisateur en fonc­
tion de la combinaison de cartes tachygraphiques valides insérées
dans la VU, comme indiqué dans le tableau 1.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 527
Tableau 1
Disponibilité de l’interface ITS en fonction du type de carte insérée dans le tachygraphe
Disponibilité de l’interface
ITS
Lecteur «conducteur»
Pas de carte
Carte du conduc­
teur
Carte de contrôleur Carte d’atelier Carte d’entreprise
L
ec
te
ur
c
on
vo
ye
ur

Pas de carte Non disponible Disponible Disponible Disponible Disponible
Carte du
conducteur
Disponible Disponible Disponible Disponible Disponible
Carte de contrô­
leur
Disponible Disponible Disponible Non disponible Non disponible
Carte d’atelier Disponible Disponible Non disponible Disponible Non disponible
Carte d’entre­
prise
Disponible Disponible Non disponible Non disponible Disponible
ITS_14 Après un couplage ITS Bluetooth® réussi, la VU attribue la
connexion ITS Bluetooth ® à la carte tachygraphique spécifique
insérée conformément au tableau 2:
Tableau 2
Attribution de la connexion ITS en fonction du type de carte insérée dans le tachygraphe
Attribution de la connexion
ITS Bluetooth®
Lecteur «conducteur»
Pas de carte
Carte du conduc­
teur
Carte de contrôleur Carte d’atelier Carte d’entreprise
L
ec
te
ur
c
on
vo
ye
ur

Pas de carte Non disponible Carte du
conducteur
Carte de
contrôleur
Carte d’atelier Carte d’entre­
prise
Carte du
conducteur
Carte du
conducteur
Carte du
conducteur (**)
Carte de
contrôleur
Carte d’atelier Carte d’entre­
prise
Carte de contrô­
leur
Carte de
contrôleur
Carte de
contrôleur
Carte de
contrôleur (*)
Non disponible Non disponible
Carte d’atelier Carte d’atelier Carte d’atelier Non disponible Carte
d’atelier (*)
Non disponible
Carte d’entre­
prise
Carte d’entre­
prise
Carte d’entre­
prise
Non disponible Non disponible Carte d’entre­
prise (*)
(*) La connexion ITS Bluetooth® est attribuée à la carte tachygraphique dans le lecteur «conducteur» de la VU.
(**) L’utilisateur sélectionne la carte à laquelle la connexion ITS Bluetooth® doit être attribuée (insérée dans le lecteur «conducteur» ou
«convoyeur»).
ITS_15 Si une carte tachygraphique est retirée, la VU met fin à la
connexion ITS Bluetooth® attribuée à cette carte.
ITS_16 La VU prend en charge la connexion ITS avec au moins une unité
ITS et peut prendre en charge les connexions avec plusieurs unités
ITS en même temps.
ITS_17 Les droits d’accès aux données et services disponibles par l’inter­
médiaire de l’interface ITS doivent être conformes aux exigences 12
et 13 de l’annexe IC, ainsi qu’à l’exigence relative au consente­
ment du conducteur spécifiée au point 3.4 du présent appendice.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 528
3.4. Données disponibles et nécessité du consentement du conducteur
ITS_18 Toutes les données tachygraphiques disponibles par l’intermédiaire
des services visés au point 3.3 sont classées comme étant soit à
caractère personnel soit sans caractère personnel pour le conduc­
teur, le convoyeur ou les deux.
ITS_19 Au minimum, la liste des données classées comme étant obliga­
toires à la section 4 doit être mise à disposition par l’intermédiaire
de l’interface ITS.
ITS_20 Les données de la section 4 qui sont classées comme étant à
caractère personnel ne sont accessibles que sous réserve du consen­
tement du conducteur, lequel accepte donc que les données à
caractère personnel puissent quitter le réseau du véhicule, sauf
dans le cas prévu par l’exigence ITS_25, en vertu de laquelle le
consentement du conducteur n’est pas nécessaire.
ITS_21 Les données autres que celles recueillies au point 4 et considérées
comme étant obligatoires peuvent être mises à disposition par l’inter­
médiaire de l’interface ITS. Les données supplémentaires qui ne sont
pas mentionnées au point 4 sont classées comme étant soit à caractère
personnel soit sans caractère personnel par le fabricant de la VU, le
consentement du conducteur étant requis pour les données qui ont été
classées comme étant à caractère personnel, sauf dans le cas prévu par
l’exigence ITS_25, en vertu de laquelle le consentement du conduc­
teur n’est pas nécessaire.
ITS_22 En cas d’insertion d’une carte de conducteur inconnue de l’unité
embarquée sur véhicule, le titulaire de la carte doit être invité par
le tachygraphe à confirmer son consentement pour la transmission de
données à caractère personnel par l’intermédiaire de l’interface ITS,
conformément à l’exigence 61 de l’annexe IC.
ITS_23 Le statut de consentement (activé/désactivé) est stocké dans la
mémoire du tachygraphe de la VU.
ITS_24 Dans le cas de conducteurs multiples, seules les données à carac­
tère personnel concernant les conducteurs qui ont donné leur
accord sont accessibles par l’intermédiaire de l’interface ITS. Par
exemple, dans le cas d’un équipage, si seul le conducteur a donné
son consentement, les données à caractère personnel relatives au
convoyeur ne sont pas accessibles.
ITS_25 Lorsque la VU est en mode de contrôle, d’entreprise ou d’étalon­
nage, les droits d’accès par l’intermédiaire de l’interface ITS sont
gérés conformément aux exigences 12 et 13 de l’annexe IC, de
sorte que le consentement du conducteur n’est pas nécessaire.
4. LISTE DES DONNÉES DISPONIBLES PAR L’INTERMÉDIAIRE DE
L’INTERFACE ITS ET CLASSIFICATION À CARACTÈRE
PERSONNEL/SANS CARACTÈRE PERSONNEL
Nom des données
Format des
données
Source
Classification des données (à caractère
personnel/sans caractère personnel) Consentement à la
mise à disposition des
données
Mise à dispo­
sition
conducteur convoyeur
VehicleIdentification­
Number
Appendice 8 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
CalibrationDate ISO 16844-7 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
TachographVehicleS­
peed
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
obligatoire
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 529
Nom des données
Format des
données
Source
Classification des données (à caractère
personnel/sans caractère personnel) Consentement à la
mise à disposition des
données
Mise à dispo­
sition
conducteur convoyeur
Driver1WorkingState ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
obligatoire
Driver2WorkingState ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
obligatoire
DriveRecognize ISO 16844-7 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
Driver1TimeRelatedS­
tates
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
obligatoire
Driver2TimeRelatedS­
tates
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
obligatoire
DriverCardDriver1 ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
obligatoire
DriverCardDriver2 ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
obligatoire
OverSpeed ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
obligatoire
TimeDate Appendice 8 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
HighResolutionTotal­
VehicleDistance
ISO 16844-7 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
HighResolutionTrip­
Distance
ISO 16844-7 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
ServiceComponentI­
dentification
ISO 16844-7 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
ServiceDelayCalendar­
TimeBased
ISO 16844-7 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
Driver1Identification ISO 16844-7 Carte
du
con­
duct­
eur
à caractère
personnel
s.o. consentement du
conducteur
obligatoire
Driver2Identification ISO 16844-7 Carte
du
con­
duct­
eur
s.o. à caractère
personnel
consentement du
convoyeur
obligatoire
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 530
Nom des données
Format des
données
Source
Classification des données (à caractère
personnel/sans caractère personnel) Consentement à la
mise à disposition des
données
Mise à dispo­
sition
conducteur convoyeur
NextCalibrationDate Appendice 8 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
Driver1ContinuousDri­
vingTime
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
obligatoire
Driver2ContinuousDri­
vingTime
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
obligatoire
Driver1Cumulative­
BreakTime
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
obligatoire
Driver2Cumulative­
BreakTime
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
obligatoire
Driver1CurrentDuratio­
nOfSelectedActivity
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
obligatoire
Driver2CurrentDuratio­
nOfSelectedActivity
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
obligatoire
SpeedAuthorised Appendice 8 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
TachographCardSlot1 ISO 16844-7 VU sans caractère
personnel
s.o. consentement non
requis
obligatoire
TachographCardSlot2 ISO 16844-7 VU s.o. sans caractère
personnel
consentement non
requis
obligatoire
Driver1Name ISO 16844-7 Carte
du
con­
duct­
eur
à caractère
personnel
s.o. consentement du
conducteur
obligatoire
Driver2Name ISO 16844-7 Carte
du
con­
duct­
eur
s.o. à caractère
personnel
consentement du
convoyeur
obligatoire
OutOfScopeCondition ISO 16844-7 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
ModeOfOperation ISO 16844-7 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
Driver1CumulatedDri­
vingTimePreviousAnd­
CurrentWeek
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
obligatoire
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 531
Nom des données
Format des
données
Source
Classification des données (à caractère
personnel/sans caractère personnel) Consentement à la
mise à disposition des
données
Mise à dispo­
sition
conducteur convoyeur
Driver2CumulatedDri­
vingTimePreviousAnd­
CurrentWeek
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
obligatoire
EngineSpeed ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
RegisteringMemberS­
tate
Appendice 8 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
VehicleRegistration­
Number
Appendice 8 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
obligatoire
Driver1EndOfLastDai­
lyRestPeriod
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2EndOfLastDai­
lyRestPeriod
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1EndOfLast­
WeeklyRestPeriod
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2EndOfLast­
WeeklyRestPeriod
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1EndOfSecond­
LastWeeklyRestPeriod
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2EndOfSecond­
LastWeeklyRestPeriod
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1CurrentDaily­
DrivingTime
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2CurrentDaily­
DrivingTime
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1CurrentWeekly­
DrivingTime
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2CurrentWeekly­
DrivingTime
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 532
Nom des données
Format des
données
Source
Classification des données (à caractère
personnel/sans caractère personnel) Consentement à la
mise à disposition des
données
Mise à dispo­
sition
conducteur convoyeur
Driver1TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1CardExpiry­
Date
ISO 16844-7 Carte
du
con­
duct­
eur
à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2CardExpiry­
Date
ISO 16844-7 Carte
du
con­
duct­
eur
s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1CardNextMan­
datoryDownloadDate
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2CardNextMan­
datoryDownloadDate
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
TachographNextMan­
datoryDownloadDate
ISO 16844-7 VU sans caractère
personnel
sans caractère
personnel
consentement non
requis
facultative
Driver1TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1NumberOf­
Times9hDailyDriving­
TimesExceeded
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2NumberOf­
Times9hDailyDriving­
TimesExceeded
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1CumulativeU­
ninterruptedRestTime
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2CumulativeU­
ninterruptedRestTime
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1MinimumDai­
lyRest
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2MinimumDai­
lyRest
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 533
Nom des données
Format des
données
Source
Classification des données (à caractère
personnel/sans caractère personnel) Consentement à la
mise à disposition des
données
Mise à dispo­
sition
conducteur convoyeur
Driver1MinimumWee­
klyRest
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2MinimumWee­
klyRest
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1MaximumDai­
lyPeriod
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2MaximumDai­
lyPeriod
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1MaximumDai­
lyDrivingTime
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2MaximumDai­
lyDrivingTime
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1NumberOfUse­
dReducedDailyRestPe­
riods
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2NumberOfUse­
dReducedDailyRestPe­
riods
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
Driver1RemainingCur­
rentDrivingTime
ISO 16844-7 VU à caractère
personnel
s.o. consentement du
conducteur
facultative
Driver2RemainingCur­
rentDrivingTime
ISO 16844-7 VU s.o. à caractère
personnel
consentement du
convoyeur
facultative
VehiclePosition Appendice 8 VU à caractère
personnel
à caractère
personnel
consentement du
conducteur et du
convoyeur
obligatoire
ByDefaultLoadType Appendice 8 VU à caractère
personnel
à caractère
personnel
consentement du
conducteur et du
convoyeur
obligatoire
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 534
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 — 21.08.2023 — 003.002 — 535
5.5 Réservé pour une utilisation future
▼B
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
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 536
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 concernant
l'identité du conducteur ne sont pas transmises par la commu­
nication.
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 537
données (les données) provenant d'un véhicule ciblé, ces données devant
servir à déterminer si ce véhicule est éventuellement en infraction avec
le règlement (UE) 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
tachygraphes (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 — 21.08.2023 — 003.002 — 538
— 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 émetteur
ou un récepteur radio. En fonctionne­
ment, un émetteur radio fournit un
courant électrique oscillant à 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 struc­
ture définie (cf. 5.4.4) demandées par le
DSRC-REDCR et fournies 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 Parle­
ment Européen et du Conseil du
4 février 2014 relatif aux tachygraphes
dans les transports routiers, abrogeant le
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 539
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.
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 validité
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 collaboratives
pour véhicules de fret commercial régle­
menté (série de normes ISO 15638)
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 540
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 — 21.08.2023 — 003.002 — 541
[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 — 21.08.2023 — 003.002 — 542
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é
▼M3
DSC_17 Les données de sécurité (DSRCSecurityData), 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é” en vue de leur stockage tempo­
raire dans la DSRC-VU comme étant la version actuelle des
DSRCSecurityData, selon la structure définie par la
section 5.4.4 du présent appendice.
▼B
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 iden­
tifié, 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
pertinents 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 — 21.08.2023 — 003.002 — 543
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 — 21.08.2023 — 003.002 — 544
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
rechargeable, l'alimentation de la DSRC-VU doit être
remplacée lors de chaque inspection périodique. En
outre, il incombe au fabricant de la DSRC-VU de vérifier
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 545
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 interruption.
— 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
(«TachographPayload») 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'interférence
sans fil comme décrit au rapport ECC 228, en utilisant notam­
ment des filtres dans la communication CEN DSRC 5,8 GHz.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 546
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 547
fait d'une souplesse optimale pour concevoir et fournir les
équipements nécessaires dans le but de répondre à l'ensemble
des cas de figure d'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 — 21.08.2023 — 003.002 — 548
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'identifi­
cateur 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éhi­
cule et procède à la demande de données par l'intermédiaire de la
communication à 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 relatives à 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 à
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 549
une autorité de contrôle compétente pour l'aider à déterminer
quel véhicule intercepter pour un contrôle physique et sont
détruites par la suite conformément à l'article 9 du règle­
ment (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 — 21.08.2023 — 003.002 — 550
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
maximal
≤ 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 — 21.08.2023 — 003.002 — 551
Point Paramètre Valeur(s) Remarque
D11b (*) Limite de puissance (infé­
rieure) pour la commu-
nication.
Puissance incidente:
– 43 dBm (axe de visée)
– 41 dBm (dans la plage –
45° — + 45° Correspon­
dant 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 norme 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é­
rales
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 — 21.08.2023 — 003.002 — 552
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 — 21.08.2023 — 003.002 — 553
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
fonctionner.
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
fonctionner.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 554
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'établir 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 — 21.08.2023 — 003.002 — 555
— É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'appli­
cation RTM tel que fourni dans la VST, suivi de l'attribut
RtmData (élément de données utiles + élément de sécu­
rité).
— É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 transaction.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 556
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 — 21.08.2023 — 003.002 — 557
— 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'attribut ou les attributs sélectionnés avec les données.
L'objectif de la commande GET est que le REDCR
obtienne les données de la DSRC-VU.
— GET.response: réponse de la DSRC-VU contenant les
données demandées.
— ACTION.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-VUque la transaction est terminée.
L'objectif de la commande RELEASE est de mettre fin
à la session avec la DSRC-VU. Dès ré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 inter­
rogateur sauf si elle a quitté la zone de communication
pendant 255 secondes ou si l'ID de balise de l'interroga­
teur 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 communication —
Demande
Le REDCR diffuse la BST
2 DSRC-VU > REDCR Initialisation de la liaison
de communication —
Réponse
Si la BST prend en charge
AID=2 alors la DSRC-VU
demande l'allocation d'une
fenêtre privée
3 REDCR > DSRC-VU Alloue une fenêtre privée Envoie une trame contenant
une allocation de fenêtre
privée
4 DSRC-VU > REDCR Envoie une VST Envoie une trame contenant
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éci­
fique
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 558
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éci­
fique
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'appli­
cation RTM est défini comme suit:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 559
► (2) (3) M1
► (1) M3
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 560
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:
▼M3
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
Immatriculation du
véhicule
Plaque
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’appen­
dice 1 VehicleRegistrationI­
dentification
Plaque d’immatriculation
du véhicule exprimée par
une chaîne de caractères
tp15638VehicleRegistration­
Plate LPN,
–Immatriculation du véhicule
Plaque utilisant la structure de
données de la
norme ISO 14906, mais avec
la limite suivante pour l’appli­
cation RTM;
SEQUENCE commence par le
code pays, suivi d’un indica­
teur alphabétique suivi du
numéro d’immatriculation
lui-même,
qui est toujours de 14 octets
(complétés par des zéros de
remplissage), de sorte que la
longueur du type LPN est
toujours de 17 octets (pas de
détermination de longueur
nécessaire), dont 14 corres­
pondent au numéro d’imma­
triculation “réel”.
RTM2
Événement “Excès de
vitesse”
La VU génère une valeur
booléenne
pour l’élément de
données RTM2
tp15638SpeedingEvent.
La valeur tp15638Speedin­
gEvent est calculée par la VU
d’après le nombre d’événe­
ments “Excès de vitesse” (tel
que défini à l’annexe IC)
enregistrés dans la VU au
cours des 10 derniers jours
d’occurrence.
1 (TRUE): si l’événe­
ment “Excès de vitesse”
le plus récent s’est
terminé au cours des
10 derniers jours ou est
toujours en cours;
0 (FALSE): dans tout
autre cas.
tp15638SpeedingEvent
BOOLEAN,
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 561
1)
Élément de données RTM
2)
Action effectuée par la VU
3)
Définition des données ASN.1
RTM3
Conduite sans
carte valide
La VU génère une valeur
booléenne
pour l’élément de
données RTM3
tp15638DrivingWithoutVa­
lidCard.
La VU attribue une valeur
TRUE à la variable
tp15638DrivingWithoutVa­
lidCard si au moins un
événement “Conduite sans
carte appropriée” (tel que
défini à l’annexe IC) a été
enregistré dans la VU au
cours des 10 derniers jours.
1 (TRUE): si l’événe­
ment “Conduite sans
carte appropriée” le plus
récent s’est terminé au
cours des 10 derniers
jours ou est toujours en
cours;
0 (FALSE): dans tout
autre cas.
tp15638DrivingWithoutValid­
Card
BOOLEAN,
RTM4
Carte de conducteur
valide
La VU génère une valeur
booléenne pour l’élément de
données RTM4
tp15638DriverCard sur la
base de la carte de conduc­
teur en cours de validité
insérée dans le lecteur
“conducteur”.
1 (TRUE): si aucune
carte de conducteur en
cours de validité n’est
présente dans le lecteur
“conducteur” de la VU;
0 (FALSE): si une carte
de conducteur valide est
présente dans le lecteur
“conducteur” de la VU.
tp15638DriverCard
BOOLEAN,
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
tp15638CardInsertion.
La VU attribue une valeur
TRUE à la variable
tp15638CardInsertion si au
moins un événement “Inser­
tion d’une carte pendant la
conduite” (tel que défini à
l’annexe IC) a été enregistré
dans la VU au cours des
10 derniers jours.
1 (TRUE): si l’événe­
ment “Insertion d’une
carte pendant la
conduite” le plus récent
s’est produit au cours
des 10 derniers jours;
0 (FALSE): dans tout
autre cas.
tp15638CardInsertion
BOOLEAN,
RTM6
Erreur sur les données
de mouvement
La VU génère une valeur
booléenne
pour l’élément de
données RTM6.
La VU attribue une valeur
TRUE à la variable
tp15638MotionDataError si
au moins un événement
“Erreur sur les données de
mouvement” (tel que défini à
l’annexe IC) a été enregistré
dans la VU au cours des
10 derniers jours.
1 (TRUE): si l’événe­
ment “Erreur sur les
données de mouvement”
le plus récent s’est
terminé au cours des
10 derniers jours ou est
toujours en cours;
0 (FALSE): dans tout
autre cas.
tp15638MotionDataError
BOOLEAN,
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 562
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 attribue une valeur
TRUE à la variable
tp15638VehicleMotionCon­
flict si au moins un événe­
ment “Conflit concernant le
mouvement du véhicule” (tel
que défini à l’annexe IC) a
été enregistré dans la VU au
cours des 10 derniers jours.
1 (TRUE): si l’événe­
ment “Conflit concernant
le mouvement du véhi­
cule” le plus récent s’est
terminé au cours des
10 derniers jours ou est
toujours en cours;
0 (FALSE): dans tout
autre cas.
tp15638VehicleMotionConflict
BOOLEAN,
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’annexe IC («Données
relatives à l’activité du
conducteur» ÉQUIPAGE et
CONVOYEUR).
Si aucune carte de convoyeur
valide n’est présente, la VU
attribue la valeur TRUE à
l’élément RTM8.
1 (TRUE): si une carte
de convoyeur en cours
de validité est présente
dans la VU;
2 (FALSE): si aucune
carte de convoyeur en
cours de validité n’est
présente dans la VU.
tp156382ndDriverCard
BOOLEAN,
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 IC), la VU
attribue la valeur TRUE à
l’élément RTM9.
1 (TRUE): autre activité
sélectionnée
0 (FALSE): conduite
sélectionnée
tp15638CurrentActivityDri­
ving
BOOLEAN
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’annexe IC, la VU
attribue la valeur TRUE à
l’élément RTM10.
1 (TRUE): au moins une
des cartes insérées a
déclenché une dernière
session qui n’a pas été
correctement clôturée;
0 (FALSE): aucune des
cartes insérées n’a
déclenché de dernière
session mal clôturée.
tp15638LastSessionClosed
BOOLEAN
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 563
1)
Élément de données RTM
2)
Action effectuée par la VU
3)
Définition des données ASN.1
RTM11
Coupure d’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 attribue pour la
variable tp15638PowerSup­
plyInterruption une valeur
égale au nombre d’événe­
ments “Coupure d’alimenta­
tion électrique” (tels que
définis à l’annexe IC) enre­
gistrés dans la VU au cours
des 10 derniers jours.
Si aucun événement
“Coupure d’alimentation
électrique” n’a été enregistré
dans la VU au cours des
10 derniers jours, elle fixe la
valeur de RTM11 à 0.
Nombre d’événements
“Coupure d’alimentation
électrique” enregistrés au
cours des 10 derniers
jours.
tp15638PowerSupplyInterrup­
tion
INTEGER (0..127),
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 ‘35 ’H “Anomalie
du capteur”
a été enregistré au cours
des 10 derniers jours ou
est toujours en cours.
— 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 ou est toujours en
cours.
— 3 si un événement de
type ‘0E ’H “Erreur de
communication avec le
dispositif GNSS externe”
a été enregistré au cours
des 10 derniers jours ou
est toujours en cours.
— 4 si à la fois des anoma­
lies du capteur et du
récepteur GNSS ont été
enregistrées au cours des
10 derniers jours ou sont
toujours en cours.
— 5 si à la fois des anoma­
lies du capteur et des
erreurs de communica­
tion avec le dispositif
GNSS externe ont été
enregistrées au cours des
10 derniers jours ou sont
toujours en cours.
– erreur de capteur un
octet conformément au
dictionnaire des données
tp15638SensorFault INTEGER
(0..255),
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 564
1)
Élément de données RTM
2)
Action effectuée par la VU
3)
Définition des données ASN.1
— 6 si à la fois des anoma­
lies du récepteur GNSS
et des erreurs de
communication avec le
dispositif GNSS externe
ont été enregistrées au
cours des 10 derniers
jours ou sont toujours en
cours.
— 7 si les trois types
d’anomalies du capteur
ont été enregistrés au
cours des 10 derniers
jours ou sont toujours en
cours.
Si aucun événement n’a été
enregistré au cours des
10 derniers jours ou n’est
toujours en cours, la VU fixe
la valeur de RTM12 à 0.
RTM13
Remise à l’heure
La VU génère une valeur
indiquée par un nombre
entier (timeReal de l’appen­
dice 1) pour l’élément de
données RTM13, en fonction
de la présence de données
concernant la remise à
l’heure (telle que définie à
l’annexe IC).
La VU doit attribuer
à RTM13 la valeur horaire
correspondant au dernier
événement de remise à
l’heure.
Si aucun événement “Remise
à l’heure” (tel que défini à
l’annexe IC) n’est présent
dans les données de la VU, la
valeur attribuée à RTM13
est 0.
oldTimeValue de la plus
récente remise à l’heure.
tp15638TimeAdjustment
INTEGER(0..4294967295),
RTM14
Tentative d’atteinte à
la sécurité
La VU génère une valeur
indiquée par un nombre
entier (timeReal de l’appen­
dice 1) pour l’élément de
données RTM14, en fonction
de la présence d’une tentative
d’atteinte à la sécurité (telle
que définie à l’annexe IC).
La VU doit attribuer la valeur
horaire correspondant au
dernier événement de tenta­
tive d’infraction à la sécurité
enregistrée par la VU.
Si aucun événement “Tenta­
tive d’atteinte à la sécurité”
(tel que défini à l’annexe IC)
n’est présent dans les
données de la VU, a valeur
attribuée à RTM14 est 0.
Heure de début du
dernier événement de
tentative d’atteinte à la
sécurité stocké.
tp15638LatestBreachAttempt
INTEGER(0..4294967295),
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 565
1)
Élément de données RTM
2)
Action effectuée par la VU
3)
Définition des données ASN.1
RTM15
Dernier étalonnage
La VU génère une valeur
indiquée par un nombre
entier (timeReal de l’appen­
dice 1) pour l’élément de
données RTM15, en fonction
de la présence de données de
dernier étalonnage (tel que
défini à l’annexe IC et à
l’appendice 1).
La VU doit attribuer
à RTM15 la valeur
oldTimeValue du dernier
enregistrement d’étalonnage.
Si aucun étalonnage n’a été
effectué, la VU attribue la
valeur 0 à RTM15.
oldTimeValue du dernier
enregistrement d’étalon­
nage.
tp15638LastCalibrationData
INTEGER(0..4294967295),
RTM16
Étalonnage précédent
La VU génère une valeur
indiquée par un nombre
entier (timeReal de l’appen­
dice 1) pour l’élément de
données RTM16, en fonction
de l’enregistrement d’étalon­
nage précédant celui du
dernier étalonnage.
La VU doit attribuer
à RTM15 la valeur
oldTimeValue de l’enregis­
trement d’étalonnage précé­
dant celui du dernier étalon­
nage.
Si aucun étalonnage n’a été
effectué précédemment, la
VU attribue la valeur 0
à RTM16.
oldTimeValue de l’enre­
gistrement d’étalonnage
précédant celui du
dernier étalonnage.
tp15638PrevCalibrationData
INTEGER(0..4294967295),
RTM17
Date de connexion
du tachygraphe
La VU génère une valeur
exprimée par un nombre
entier (timeReal de l’appen­
dice 1) pour l’élément de
données RTM17.
La VU doit attribuer
à RTM17 la valeur de la date
du premier étalonnage de la
VU dans le véhicule consi­
déré.
La VU extrait ces données
des VuCalibrationData
(appendice 1) des vuCalibra­
tionRecords, où Calibration­
Purpose est égal à: ‘03’H
Si aucun étalonnage n’a été
effectué précédemment, la
VU attribue la valeur 0
à RTM17.
Date du premier étalon­
nage de l’unité embar­
quée sur le véhicule
considéré.
tp15638DateTachoConnected
INTEGER(0..4294967295),
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 566
1)
Élément de données RTM
2)
Action effectuée par la VU
3)
Définition des données ASN.1
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
enregistrée
tp15638CurrentSpeed
INTEGER (0..255),
RTM19
Horodatage
La VU génère une valeur
exprimée par un nombre
entier pour l’élément de
données RTM19 (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’enregis­
trement
TachographPayload
actuel
tp15638Timestamp
INTEGER(0..4294967295),
RTM20
Heure à laquelle la
dernière position
authentifiée du véhicule
était disponible
La VU génère une valeur
exprimée par un nombre
entier (timeReal de l’appen­
dice 1) pour l’élément de
données RTM20.
La VU attribue comme valeur
pour l’élément RTM20
l’heure à laquelle la dernière
position authentifiée du véhi­
cule était disponible auprès
du récepteur GNSS.
Si aucune position authenti­
fiée du véhicule n’était
disponible auprès du récep­
teur GNSS, la VU attribue la
valeur 0 à RTM20.
Horodatage de la
dernière position authen­
tifiée du véhicule
tp15638LatestAuthenticatedPo­
sition
INTEGER(0..4294967295),
RTM21
Temps de conduite
continue
La VU génère une valeur
exprimée par un nombre
entier pour l’élément de
données RTM21.
La VU attribue comme valeur
pour l’élément RTM21 le
temps de conduite continue
du conducteur en cours.
Temps de conduite
continue du conducteur,
exprimé par un nombre
entier.
Longueur: 1 octet
Résolution: 2 minutes/bit
Décalage 0
Étendue des données: 0
à 250
Une valeur de 250
indique que le temps de
conduite continue du
conducteur est égal ou
supérieur à 500 minutes.
Les valeurs 251 à 254 ne
sont pas utilisées.
La valeur 255 indique
que les informations ne
sont pas disponibles.
tp15638ContinuousDriving­
Time INTEGER(0..255),
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 567
1)
Élément de données RTM
2)
Action effectuée par la VU
3)
Définition des données ASN.1
RTM22
Temps de conduite
journalier le plus long
pour la période de
travail RTM en cours et
la précédente, calculé
conformément à
l’addendum à l’appen­
dice 14
La VU génère une valeur
exprimée par un nombre
entier pour l’élément de
données RTM22.
La VU attribue comme valeur
pour l’élément RTM22 la
plus longue des deux
périodes de conduite journa­
lières du conducteur, soit
celle de la période de travail
RTM en cours, soit celle de
la précédente.
Temps de conduite jour­
nalier du conducteur,
exprimé par un nombre
entier.
Longueur: 1 octet
Résolution: 4 minutes/bit
Décalage 0
Étendue des données: 0
à 250
Une valeur de 250
indique que le temps de
conduite journalier du
conducteur est égal ou
supérieur à
1 000 minutes.
Les valeurs 251 à 254 ne
sont pas utilisées.
La valeur 255 indique
que les informations ne
sont pas disponibles.
tp15638DailyDrivingTimeShift
INTEGER(0..255),
RTM23
Temps de conduite
journalier le plus long
pour la semaine en
cours, calculé conformé­
ment à l’addendum à
l’appendice 14
La VU génère une valeur
exprimée par un nombre
entier pour l’élément de
données RTM23.
La VU attribue comme valeur
pour l’élément RTM23 la
période de conduite journa­
lière la plus longue du
conducteur, qu’il s’agisse de
la période de travail RTM en
cours ou d’une période de
travail RTM achevée ou
commencée pendant la
semaine en cours.
Temps de conduite jour­
nalier du conducteur,
exprimé par un nombre
entier.
Longueur: 1 octet
Résolution: 4 minutes/bit
Décalage 0
Étendue des données: 0
à 250
Une valeur de 250
indique que le temps de
conduite journalier du
conducteur est égal ou
supérieur à
1 000 minutes.
Les valeurs 251 à 254 ne
sont pas utilisées.
La valeur 255 indique
que les informations ne
sont pas disponibles.
tp15638DailyDrivingTime­
Week INTEGER(0..255),
RTM24
Temps de conduite
hebdomadaire, calculé
conformément à
l’addendum à l’appen­
dice 14
La VU génère une valeur
exprimée par un nombre
entier pour l’élément de
données RTM24.
La VU attribue comme valeur
pour l’élément RTM24 le
temps de conduite hebdoma­
daire du conducteur.
Temps de conduite
hebdomadaire du
conducteur, exprimé par
un nombre entier.
Longueur: 1 octet
Résolution: 20 minutes/
bit
Décalage 0
Étendue des données: 0
à 250
Une valeur de 250
indique que le temps de
conduite hebdomadaire
du conducteur est égal
ou supérieur à
5 000 minutes.
Les valeurs 251 à 254 ne
sont pas utilisées.
La valeur 255 indique
que les informations ne
sont pas disponibles.
tp15638WeeklyDrivingTime
INTEGER(0..255),
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 568
1)
Élément de données RTM
2)
Action effectuée par la VU
3)
Définition des données ASN.1
RTM25
Temps de conduite
bihebdomadaire, calculé
conformément à
l’addendum à l’appen­
dice 14
La VU génère une valeur
exprimée par un nombre
entier pour l’élément de
données RTM25.
La VU attribue comme valeur
pour l’élément RTM25 le
temps de conduite bihebdo­
madaire du conducteur.
Temps de conduite
bihebdomadaire du
conducteur, exprimé par
un nombre entier.
Longueur: 1 octet
Résolution: 30 minutes/
bit
Décalage 0
Étendue des données: 0
à 250
Une valeur de 250
indique que le temps de
conduite bihebdomadaire
du conducteur est égal
ou supérieur à
7 500 minutes.
Les valeurs 251 à 254 ne
sont pas utilisées.
La valeur 255 indique
que les informations ne
sont pas disponibles.
tp15638FortnightlyDriving­
Time INTEGER(0..255),
Remarque: les éléments RTM22, RTM23, RTM24 et RTM25 sont calculés
conformément à l’addendum au présent appendice.
▼B
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.
▼M1
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'initia­
lisation, le REDCR commence à envoyer une trame contenant
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
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 569
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, Com­
mande 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
O
ct
et
#

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
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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 570
O
ct
et
#

Attribut/Champ Bits dans l'octet Description
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
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
O
ct
et
#

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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 571
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
O
ct
et
#

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 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
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 572
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.
▼M3
Tableau 14.9
Initialisation – Exemple de contenu de la trame VST
O
ct
et

Attribut/Champ Bits dans l’octet Description
1 DRAPEAU 0111 1110 Drapeau de début
2 LID privé xxxx xxxx Adresse de liaison de la
DSRC-VU spécifique
3 xxxx xxxx
4 xxxx xxxx
5 xxxx xxxx
6 Champ de contrôle MAC 1100 0000 PDU de commande
7 Champ de contrôle LLC 0000 0011 Commande UI
8 En-tête fragmentation 1xxx x001 Pas de fragmentation
9 VST
SEQUENCE {
Fill BIT STRING (SIZE(4))
1001 Réponse d’initialisation
0000 Inutilisé, prend la valeur 0
10 Profile INTEGER (0..127,...)
Applications SEQUENCE OF {
0000 0000 Pas d’extension. Profil
d’exemple 0
Pas d’extension, 1 appli­
cation
11 0000 0001
12 SEQUENCE {
OPTION indicator
OPTION indicator
AID DSRCApplicationEntityID
1 EID présent
1 Paramètre présent
00 0010 Pas d’extension. AID= 2
Freight&Fleet
13 EID Dsrc-EID xxxx xxxx Défini dans le cadre de
l’OBU et identifie
l’instance d’application.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 573
O
ct
et

Attribut/Champ Bits dans l’octet Description
14 Parameter Container { 0000 0010 Pas d’extension, choix de
conteneur = 02,
chaîne d’octets
15 0000 0110 Pas d’extension, longueur
de marque de contexte
RTM = 6
16 Rtm-ContextMark ::= SEQUENCE {
StandardIdentifier
0000 0101 Le premier octet est 05H,
qui est sa longueur.
Les 5 octets suivants
encodent l’identificateur
d’objet de la norme,
partie et version prise en
charge.
{ISO (1) Standard (0)
TARV (15638) part9(9)
Version2 (2)}
17 standardIdentifier 0010 1000
18 1111 1010
19 0001 0110
20 0000 1001
21 0000 0010
22 ObeConfiguration Sequence {
OPTION indicator
0 ObeStatus non présent
EquipmentClass INTEGER (0..32767) xxx xxxx Ce champ doit être utilisé
pour les
23 xxxx xxxx indications du fabricant
concernant la version
logicielle/matérielle de
l’interface DSRC
24 ManufacturerId INTEGER (0..65535) xxxx xxxx Identificateur du fabricant
pour la DSRC-VU tel
qu’il figure au
registre ISO 14816
25 xxxx xxxx
26 FCS xxxx xxxx Séquence de contrôle de
trame
27 xxxx xxxx
28 Drapeau 0111 1110 Drapeau de fin
▼B
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
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 574
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
O
ct
et
#

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 solli­
cité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'application 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 — 21.08.2023 — 003.002 — 575
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
O
ct
et
#

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 — 21.08.2023 — 003.002 — 576
O
ct
et
#

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
O
ct
et
#

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 — 21.08.2023 — 003.002 — 577
O
ct
et
#

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 — 21.08.2023 — 003.002 — 578
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'appli­
cation 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 — 21.08.2023 — 003.002 — 579
Tableau 14.15
Exemple de trame de demande ACTION, ECHO
O
ct
et
#

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'action 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 — 21.08.2023 — 003.002 — 580
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
O
ct
et
#

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 — 21.08.2023 — 003.002 — 581
5.5 Réservé pour une utilisation future
▼M2
__________
▼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
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 582
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:
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 LinkIdenti­
fier 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éussite) 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 — 21.08.2023 — 003.002 — 583
— 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 LinkIdentifier spéci­
fique.
5.7 Traitement des erreurs
5.7.1 Enregistrement et communication des données dans la DSRC-VU
▼M3
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 ont bien été transmises à la
DSRC-VU. 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 “Erreur de communication avec le
dispositif de communication à distance”, ainsi que l’horoda­
tage. Le VUSM vérifie que les données ont bien été trans­
mises à la DSRC-VU.
DSC_78 Réservé pour une utilisation future.
▼B
DSC_79 Si la VUPM tente d'obtenir les données VU du module de
sécurité (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 — 21.08.2023 — 003.002 — 584
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.
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 585
L'«anomalie de lecture» est techniquement différente d'une «erreur».
Dans ce contexte, une «erreur» désigne l'acquisition d'une valeur fausse.
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:
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 586
1) Un essai ECHO pour valider le canal de communication
sans fil DSRC-REDCR >>-:-
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
>>-:-
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'envoyer 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 >>-:-
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'utili­
sateur 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'étalonnage. Après son activation, l'unité embarquée sur le
véhicule génère et communique à la DSRC-VU les données
sécurisé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 — 21.08.2023 — 003.002 — 587
Addendum
Règles pour le calcul des temps de conduite journaliers, hebdomadaires et biheb­
domadaires
1. Règles de calcul de base
La VU calcule les temps de conduite journaliers, hebdomadaires et bihebdo­
madaires sur la base des données pertinentes stockées dans une carte de
conducteur (ou d’atelier) insérée dans le lecteur conducteur (lecteur 1,
lecteur de carte #1) de l’unité embarquée sur véhicule, ainsi que des activités
du conducteur sélectionnées pendant que cette carte est insérée dans la VU.
Les temps de conduite ne sont pas calculés tant qu’aucune carte de conducteur
(ou d’atelier) n’est insérée.
La ou les périodes “INCONNUE(S)” constatées au cours de la période néces­
saire aux calculs sont assimilées à des périodes “PAUSE/REPOS”.
Les périodes et activités “INCONNUE(S)” dont la durée est négative (c’est-à-
dire que le début de l’activité intervient après la fin de l’activité) en raison de
chevauchements de temps entre deux VU différentes ou en raison d’une
remise à l’heure ne sont pas prises en compte.
Les activités enregistrées sur la carte de conducteur correspondant aux
périodes “HORS CHAMP” conformément à la définition gg) de l’annexe IC
sont interprétées comme suit:
— “PAUSE/REPOS” est calculé comme “PAUSE” ou “REPOS”
— “TRAVAIL” et “CONDUITE” sont considérés comme “TRAVAIL”
— “DISPONIBILITÉ” est considérée comme “DISPONIBILITÉ”
Dans le cadre du présent addendum, la VU présume un temps de repos
journalier au début des relevés d’activité.
2. Définitions
Les concepts suivants s’appliquent exclusivement au présent appendice et
visent à préciser le calcul des temps de conduite par la VU et leur trans­
mission ultérieure par le dispositif de communication à distance.
a) “période de travail RTM”: la période comprise entre les fins respectives de
deux temps de repos journaliers consécutifs.
La VU entame une nouvelle période de travail RTM après la fin de chaque
temps de repos journalier.
La période de travail RTM en cours est la période écoulée depuis la fin du
dernier temps de repos journalier;
b) “temps de conduite accumulé”: la somme de la durée de toutes les activités
“CONDUITE” du conducteur au cours d’une période qui ne sont pas
“HORS CHAMP”;
c) “temps de conduite journalier”: le temps de conduite accumulé au cours
d’une période de travail RTM;
d) “temps de conduite hebdomadaire”: le temps de conduite accumulé pour la
semaine en cours;
e) “temps de repos continu”: toute période ininterrompue de “PAUSE/
REPOS”;
f) “temps de conduite bihebdomadaire”: le temps de conduite accumulé pour
la semaine en cours et la semaine précédente;
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 588
g) “repos journalier”: une période de “PAUSE/REPOS”, qui peut être:
— un temps de repos journalier normal,
— un temps de repos journalier fractionné, ou
— un temps de repos journalier réduit.
Dans le contexte de l’appendice 14, lorsqu’une VU calcule les temps de
repos hebdomadaires, ces temps de repos hebdomadaires sont considérés
comme des temps de repos journaliers;
h) “temps de repos journalier normal”: toute période de repos ininterrompue
d’au moins onze heures.
À titre exceptionnel, lorsqu’une condition “TRAJET EN FERRY/TRAIN”
est active, le temps de repos journalier normal peut être interrompu au
maximum deux fois par des activités autres que le repos, avec une durée
maximale cumulée d’une heure, de telle sorte que le temps de repos
journalier normal comportant une ou plusieurs périodes de trajets en ferry/
train peut être scindé en deux ou trois parties. La VU calcule ensuite un
temps de repos journalier normal lorsque le temps de repos accumulé
calculé conformément au point 3 est d’au moins 11 heures.
Lorsqu’un temps de repos journalier normal a été interrompu, la VU:
— n’inclut pas l’activité de conduite détectée pendant ces interruptions
dans le calcul du temps de conduite journalier, et
— commence une nouvelle période de travail RTM à la fin du temps de
repos journalier normal qui a été interrompu.
Figure 1.
Exemple de temps de repos journalier interrompu en raison d’un trajet en ferry/train
i) “temps de repos journalier réduit”: un temps de repos ininterrompu d’au
moins 9 heures et de moins de 11 heures;
j) “temps de repos journalier fractionné”: un temps de repos journalier pris en
deux parties:
— la première partie est un temps de repos ininterrompu d’au moins
3 heures et de moins de 9 heures,
— la seconde partie est un temps de repos ininterrompu d’au moins
9 heures.
À titre exceptionnel, lorsqu’une condition “TRAJET EN FERRY/TRAIN”
est active pendant l’une ou les deux parties d’un temps de repos journalier
fractionné, le temps de repos journalier fractionné peut être interrompu au
maximum deux fois par d’autres activités d’une durée cumulée d’une heure
au maximum, à savoir:
— la première partie du temps de repos journalier fractionné peut être
interrompue une ou deux fois, ou
— la seconde partie du temps de repos journalier fractionné peut être
interrompue une ou deux fois, ou
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 589
— la première partie du temps de repos journalier fractionné peut être
interrompue une fois et la seconde partie du temps de repos journalier
fractionné peut être interrompue une fois.
La VU calcule ensuite un temps de repos journalier fractionné lorsque le
temps de repos accumulé calculé conformément au point 3 est:
— d’au moins 3 heures et de moins de 11 heures pour la première période
de repos et d’au moins 9 heures pour la deuxième période de repos,
lorsque la première période de repos a été interrompue par un
“TRAJET EN FERRY/TRAIN”.
— d’au moins 3 heures et de moins de 9 heures pour la première période
de repos et d’au moins 9 heures pour la deuxième période de repos,
lorsque la première période de repos n’a pas été interrompue par un
“TRAJET EN FERRY/TRAIN”.
Figure 2.
Exemple de temps de repos journalier fractionné interrompu en raison d’un trajet en ferry/train
Lorsqu’un temps de repos journalier fractionné est interrompu, la VU:
— n’inclut pas l’activité de conduite détectée pendant ces interruptions
dans le calcul du temps de conduite journalier, et
— commence une nouvelle période de travail RTM à la fin du temps de
repos journalier fractionné qui a été interrompu;
k) “semaine”: la période comprise entre 00 h 00 le lundi et 24 h 00 le
dimanche (heure UTC);
3. Calcul de la période de repos lorsqu’elle a été interrompue en raison d’un
trajet en ferry/train
Pour le calcul de la période de repos lorsqu’elle a été interrompue en raison
d’un trajet en ferry/train, la VU calcule le temps de repos cumulé selon les
étapes suivantes:
a) Étape 1
La VU détecte les interruptions du temps de repos intervenues avant
l’activation du drapeau “TRAJET EN FERRY/TRAIN (DÉBUT)”, confor­
mément à la figure 3 et, dans son cas, à la figure 4, et évalue, pour chaque
interruption détectée, si les conditions suivantes sont remplies:
— l’interruption fait que la durée totale des interruptions détectées, y
compris, dans son cas, des interruptions survenant au cours de la
première partie d’un temps de repos journalier fractionné en raison
d’un trajet en ferry/train, dépasse au total plus d’une heure,
— l’interruption fait que le nombre total d’interruptions détectées, y
compris, dans son cas, d’interruptions survenant au cours de la
première partie d’un temps de repos journalier fractionné en raison
d’un trajet en ferry/train, est supérieur à deux,
— il existe une “Saisie du lieu de fin de la période de travail journalière”
stockée après la fin de l’interruption.
Si aucune des conditions ci-dessus n’est remplie, la période de repos
ininterrompue précédant immédiatement l’interruption est ajoutée au
temps de repos accumulé.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 590
Si au moins l’une des conditions ci-dessus est remplie, la VU doit soit
interrompre le calcul du temps de repos cumulé conformément à l’étape 2,
soit détecter les interruptions du temps de repos survenant après l’activa­
tion du drapeau “TRAJET EN FERRY/TRAIN (DÉBUT)” conformément
à l’étape 3.
b) Étape 2
Pour chaque interruption détectée conformément à l’étape 1, la VU évalue
si le calcul du temps de repos accumulé doit s’arrêter. La VU arrête le
processus de calcul lorsque deux temps de repos ininterrompus se produi­
sant avant l’activation du drapeau “TRAJET EN FERRY/TRAIN
(DÉBUT)” ont été ajoutés au temps de repos accumulé, y compris, dans
son cas, des temps de repos ajoutés dans la première partie d’un temps de
repos journalier fractionné également interrompu par un trajet en ferry/
train. Dans le cas contraire, la VU procédera à l’étape 3.
c) Étape 3
Si, après la réalisation de l’étape 2, la VU poursuit le calcul du temps de
repos accumulé, la VU détecte les interruptions qui se produisent après la
désactivation de la condition “TRAJET EN FERRY/TRAIN” conformé­
ment à la figure 3 et, dans son cas, à la figure 4.
Pour chaque interruption constatée, la VU évalue si l’interruption fait que
le temps accumulé de toutes les interruptions détectées dépasse au total
plus d’une heure, auquel cas le calcul du temps de repos accumulé se
termine à la fin du temps de repos ininterrompu précédant l’interruption.
Dans le cas contraire, les temps de repos ininterrompus postérieurs aux
interruptions respectives sont ajoutés au calcul du temps de repos journa­
lier jusqu’à ce que la condition de l’étape 4 soit remplie.
d) Étape 4
Le calcul du temps de repos accumulé s’arrête lorsque la VU a ajouté, à la
suite des étapes 1 et 3, un maximum de deux temps de repos ininterrompus
à la période de repos pour laquelle la condition “TRAJET EN FERRY/
TRAIN” est activée, y compris, dans son cas, les interruptions survenant
au cours de la première partie d’un temps de repos journalier fractionné en
raison d’un trajet en ferry/train.
Figure 3.
Traitement des temps de repos par la VU afin de déterminer si un temps de repos interrompu doit être
calculé comme un temps de repos journalier normal ou comme la première partie d’un temps de repos
journalier fractionné.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 591
Figure 4.
Traitement des temps de repos par la VU afin de déterminer si une période de repos interrompue doit être
considérée comme la deuxième partie d’un temps de repos journalier fractionné.
Figure 5.
Exemple de temps de repos journalier interrompu plus de deux fois, entraînant la non-prise en compte du
temps de repos H dans le calcul.
Figure 6.
Exemple de temps de repos journalier où la période de calcul des trajets en ferry/train commence à la fin
de la période de travail.
Figure 7.
Exemple de temps de repos journalier interrompu plus de deux fois, entraînant la non-prise en compte du
temps de repos B dans le calcul.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 592
Figure 8.
Exemple de temps de repos journalier fractionné interrompu une fois pendant le premier temps de repos et
une fois pendant le deuxième temps de repos.
4. Calcul des temps de conduite journaliers, hebdomadaires et bihebdomadaires
La VU calcule le ou les temps de conduite journaliers pour les périodes de
travail RTM en cours et antérieures. Le temps de conduite survenant pendant
les interruptions des temps de repos journaliers n’est pas ajouté au calcul du
temps de conduite journalier, lorsque ces interruptions sont dues à des trajets
en ferry/train et que les exigences énoncées aux points 2 h) et 2 j) et au
point 3 ont été respectées. Néanmoins, dans la mesure où un temps de repos
journalier normal ou fractionné n’a pas été calculé par la VU conformément
au point 3, les temps de conduite survenant pendant les interruptions sont
ajoutés au temps de conduite journalier pour la période de travail RTM en
cours.
La VU calcule également les temps de conduite hebdomadaires et bihebdo­
madaires. Le temps de conduite survenant pendant les interruptions des temps
de repos journaliers en raison de trajets en ferry/train est ajouté au calcul des
temps de conduite hebdomadaires et bihebdomadaires.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 593
Appendice 15
MIGRATION: GÉRER LA COEXISTENCE DE PLUSIEURS GÉNÉRATIONS
ET VERSIONS D’ÉQUIPEMENTS
▼B
TABLE DES MATIÈRES
1. DÉFINITIONS
2. DISPOSITIONS GÉNÉRALES
2.1. Présentation de la transition
▼M3
2.2. Interopérabilité entre les unités embarquées sur véhicule et les cartes
▼B
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
▼M3
5. ENREGISTREMENT DES PASSAGES AUX FRONTIÈRES RÉALISÉS
PAR DES TACHYGRAPHES DE PREMIÈRE GÉNÉRATION ET DES
TACHYGRAPHES DE DEUXIÈME GÉNÉRATION, PREMIÈRE
VERSION
▼B
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ègle­
ment (article 2: définition 1);
tachygraphe de deuxième génération: tel que défini par le présent règle­
ment (article 2: définition 7);
date d'introduction: telle que définie dans la présente annexe (chapitre 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.
▼M3
2. DISPOSITIONS GÉNÉRALES
2.1. Présentation de la transition
L’introduction de la présente annexe donne un aperçu de la transition entre
les systèmes tachygraphiques de première et de deuxième génération et de
l’introduction de la deuxième version d’appareils de contrôle et de cartes
tachygraphiques de deuxième génération.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 594
Outre les dispositions de cette introduction, les informations suivantes
peuvent être rappelées:
— la première génération de capteurs de mouvement n’est pas interopé­
rable avec la deuxième génération d’unités embarquées sur véhicule,
indépendamment de leur version,
— seuls des capteurs de mouvement de deuxième génération peuvent être
installés dans des véhicules équipés d’unités embarquées sur véhicule
de deuxième génération, indépendamment de leur version,
— le téléchargement de données et l’équipement d’étalonnage doivent
être compatibles avec les deux générations ou versions d’appareils
de contrôle et de cartes tachygraphiques.
2.2. Interopérabilité entre les unités embarquées sur les véhicules et les
cartes
Il est entendu que la première génération de cartes 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]
et que la deuxième génération de cartes tachygraphiques est interopérable
avec la deuxième génération d’unités embarquées sur les véhicules, indé­
pendamment de leur version (conformément à l’annexe IC du présent
règlement). De plus, les exigences ci-dessous s’appliquent.
MIG_001 Sous réserve des dispositions prévues aux exigences MIG_004
et MIG_005, les cartes tachygraphiques de première généra­
tion peuvent continuer à être utilisées dans les unités embar­
quées sur les véhicules de deuxième génération, indépendam­
ment de leur version, 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, indépendamment de leur version, pourront utiliser toute
carte de conducteur, de contrôleur et d’entreprise valide de
première génération qui est insérée.
MIG_003 Les ateliers pourraient supprimer définitivement cette possibi­
lité 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 aura 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, indépen­
damment de leur version, il suffira de consulter les types de
cartes valides insérées, indépendamment de leur génération et
de leur version.
MIG_006 Toute carte tachygraphique de deuxième génération valide
pourra, indépendamment de sa version, ê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, indépendamment de leur version. De plus, les exigences
ci-dessous s’appliquent.
MIG_007 Indépendamment de leur version, les unités embarquées sur
les véhicules de deuxième génération ne pourront pas être
couplées et utilisées avec les capteurs de mouvement de
première génération.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 595
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 embar­
quées sur les véhicules de deuxième génération, indépendam­
ment de leur version, soit avec les deux générations d’unités
embarquées sur les véhicules.
2.4. Interopérabilité entre les unités embarquées sur les véhicules, les
cartes 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 toutes les générations et versions d’unités embarquées
sur des véhicules et de cartes tachygraphiques.
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 tachy­
graphiques 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ération,
et les données téléchargées sont au format défini pour ladite
génération et version.
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’ateliers) de deuxième génération, indépendamment de leur
version, 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:
— EF ICC, IC non signés (facultatif),
— des EF non signés (de première génération) Card_Certifi­
cate et CA_Certificate,
— 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
conducteur (et d’atelier) de deuxième génération,
versions 1 et 2 (EF de données d’application au sein du
DF Tachograph_G2).
2.4.2 Téléchargement de carte grâce à l’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, indépendamment de la version, 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é embar­
qué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, indépendamment de la version, selon
le protocole de téléchargement de données défini à l’appen­
dice 7 de la présente annexe. L’unité embarquée sur le véhi­
cule 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.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 596
2.4.3 Téléchargement d’unité embarquée sur un véhicule
MIG_014 En dehors du cadre du contrôle d’un conducteur par des
autorités de contrôle autres 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 pour
la version correspondante.
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, indépen­
damment de la version, 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électionnée grâce aux commandes
du menu.
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, indépendamment de la
version, selon le protocole d’étalonnage de cette génération
ou version. L’équipement d’étalonnage peut être compatible
avec toutes les générations et versions d’unités embarquées
sur véhicule.
3. PRINCIPALES ÉTAPES PRÉCÉDANT LE LANCEMENT
MIG_017 Les clés et les certificats d’essai seront à la disposition des
fabricants à la date de publication de la présente annexe.
MIG_018 Les essais d’interopérabilité seront prêts à commencer avec les
unités embarquées sur véhicule de version 2 et avec les cartes
tachygraphiques de version 2 sur demande des fabricants au
plus tard 15 mois avant la date d’introduction.
MIG_019 Pour la version 2 de la génération 2 de tachygraphes, de
cartes tachygraphiques et de capteurs de mouvement, les
mêmes clés et certificats sont utilisés que pour la version 1
de la génération 2 d’équipements.
MIG_020 Les États membres pourront émettre des cartes d’atelier de
deuxième génération, version 2, au plus tard 1 mois avant
la date d’introduction.
MIG_021 Les États membres pourront émettre tous les autres types de
cartes tachygraphiques de deuxième génération, version 2, au
plus tard 1 mois avant la date d’introduction.
4. DISPOSITIONS RELATIVES À LA PÉRIODE QUI SUIT LE LANCE­
MENT
MIG_022 À compter de la date d’introduction, les États membres
n’émettront que des cartes tachygraphiques de deuxième géné­
ration, version 2.
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 mouve­
ment de première génération tant qu’ils resteront utilisés sur le
terrain, de façon à pouvoir remplacer les composants qui
dysfonctionneraient.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 597
MIG_023a À compter de la date d’introduction, les unités embarquées sur
véhicule et les dispositifs GNSS externes de deuxième géné­
ration, version 1, qui ne fonctionnent pas correctement seront
remplacés par la version 2 des unités embarquées sur véhicule
et des dispositifs GNSS externes de deuxième génération.
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, ou de la version 1 de la deuxième géné­
ration, dont le type est déjà homologué.
5. ENREGISTREMENT DES PASSAGES AUX FRONTIÈRES RÉALISÉS
PAR DES TACHYGRAPHES DE PREMIÈRE GÉNÉRATION ET DES
TACHYGRAPHES DE DEUXIÈME GÉNÉRATION, PREMIÈRE
VERSION
MIG_025 Le symbole du pays et, le cas échéant, de la région que le
conducteur rejoint après avoir franchi la frontière d’un État
membre en application de l’article 34, paragraphe 7, du règle­
ment (UE) n o 165/2014, doit être saisi en tant que lieu où
débute la période de travail journalière conformément à la
saisie manuelle des lieux prévue à l’exigence 60 de
l’annexe IC du règlement (UE) n o 165/2014 et à l’exigence 50
de l’annexe IB du règlement (CEE) n o 3821/85.
▼M3
02016R0799 — FR — 21.08.2023 — 003.002 — 598
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'ADAPTA­
TEUR
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 — 21.08.2023 — 003.002 — 599
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
interfaces.
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'interruption de l'alimentation électrique du capteur de
mouvement intégré (79) dépassant 200 millisecondes (ms);
▼B
02016R0799 — FR — 21.08.2023 — 003.002 — 600
— 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'atelier agréé qui procède à l'installation de l'adaptateur permet­
tent le bon interfaçage de l'adaptateur au véhicule, le cas
échéant.
▼M3
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 (2 400 à 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.
▼B
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 — 21.08.2023 — 003.002 — 601
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 — 21.08.2023 — 003.002 — 602
— 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
possible).
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 — 21.08.2023 — 003.002 — 603
— 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 — 21.08.2023 — 003.002 — 604
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 — 21.08.2023 — 003.002 — 605
Appendice 17
DISPOSITIONS TRANSITOIRES LIÉES À L’UTILISATION DU
SERVICE OSNMA PAR LES TACHYGRAPHES
1. DÉFINITIONS ET ACRONYMES
1.1. Définitions
Déclaration de service du service d’authentification des messages de
navigation en libre service (OSNMA) de Galileo: déclaration de la
Commission européenne indiquant que le service OSNMA de Galileo
entre en phase opérationnelle.
Unité embarquée transitoire sur le véhicule: unité embarquée sur le
véhicule conforme aux dispositions du présent appendice.
Les unités embarquées transitoires sur véhicule sont construites conformé­
ment au document de contrôle des signaux dans les interfaces spatiales
(Signal in Space Interface Control Document — SIS ICD) et aux lignes
directrices concernant les récepteurs OSNMA applicables à la phase
d’essai public OSNMA. Elles sont équipées d’un récepteur GNSS
capable d’utiliser le service OSNMA disponible pendant sa phase
d’essai public.
Les unités embarquées transitoires sur véhicule ne sont toutefois pas à
même d’authentifier les messages de navigation disponibles après la décla­
ration de service OSNMA, car cette opération nécessite une mise à jour du
matériel cryptographique intégré à l’unité embarquée sur le véhicule. Une
mise à jour logicielle appropriée doit être effectuée afin que les unités
embarquées transitoires sur véhicule puissent commencer à utiliser
OSNMA et qu’elles soient conformes aux exigences fixées à l’annexe I
C et à ses appendices 1 à 16. Avant la mise à jour, les unités embarquées
transitoires sur véhicule mettent en œuvre les fonctionnalités liées à
OSNMA comme précisé dans le présent appendice. Les fonctionnalités
indépendantes du service OSNMA restent inchangées.
Une fois effectuée la mise à jour logicielle appropriée, les unités embar­
quées transitoires sur véhicule sont alors conformes au SIS ICD et aux
lignes directrices concernant les récepteurs OSNMA applicables à la phase
opérationnelle OSNMA, ainsi qu’à toutes les exigences fixées à l’annexe I
C et à ses appendices 1 à 16, et elles utilisent le service OSNMA dispo­
nible pendant la phase opérationnelle.
Tachygraphe transitoire: tachygraphe intégrant une unité embarquée
transitoire sur le véhicule.
1.2. Acronymes
ICD document de contrôle des interfaces (Interface
Control Document)
OSNMA service d’authentification des messages de naviga­
tion en libre service de Galileo (Galileo Open
Service Navigation Message Authentication)
SIS signal dans l’espace (Signal in Space)
VU unité embarquée sur le véhicule (Vehicle Unit)
▼M4
02016R0799 — FR — 21.08.2023 — 003.002 — 606
2. CONSIDÉRATIONS GÉNÉRALES RELATIVES À OSNMA
Afin que les véhicules immatriculés pour la première fois puissent être
équipés de tachygraphes de deuxième génération, deuxième version, à
partir de la date de mise en œuvre demandée telle que définie à l’annexe I
C, section 1, point ccc), du règlement d’exécution (UE) 2016/799, il est
nécessaire de procéder à l’homologation, la production et la commerciali­
sation d’unités embarquées sur véhicule avant la déclaration de service
OSNMA. Pour que ces unités, désignées sous le nom d’unités embarquées
transitoires sur véhicule, puissent être homologuées et utilisées sur le
terrain, il convient d’adapter les exigences relatives à OSNMA fixées à
l’annexe I C et à ses appendices 1 à 16.
Les dispositions du présent appendice définissent les exigences spécifiques
applicables aux unités embarquées transitoires sur véhicule. Elles ne
s’appliquent qu’aux unités embarquées sur véhicule équipées d’un récep­
teur GNSS interne.
3. EXIGENCES APPLICABLES AU RÉCEPTEUR GNSS DES TACHY­
GRAPHES TRANSITOIRES
TRA_001 Les unités embarquées transitoires sur véhicule doivent être
équipées d’un récepteur GNSS capable d’utiliser le service OSNMA
disponible pendant sa phase d’essai public.
TRA_002 Les exigences de l’appendice 12 s’appliquent au récepteur
GNSS intégré aux unités embarquées transitoires sur véhicule, avec les
interprétations suivantes:
— le SIS ICD et les lignes directrices concernant les récepteurs OSNMA
auquel il est fait référence désignent les documents disponibles pour la
phase d’essai public, à savoir:
— “Galileo Open Service Navigation Message Authentication
(OSNMA) User ICD for the Test Phase”, version 1.0, novembre
2021,
— “Galileo Open Service Navigation Message Authentication
(OSNMA) Receiver Guidelines for the Test Phase”, version 1.0,
novembre 2021,
— OSNMA désigne le service disponible pendant la phase d’essai public,
— SIS désigne le signal dans l’espace disponible pendant la phase d’essai
public.
TRA_003 Le récepteur GNSS intégré aux unités embarquées transitoires
sur véhicule doit être conçu de telle sorte que, après mise à jour de son
logiciel effectuée au moyen de la mise à jour logicielle de l’unité embar­
quée sur le véhicule, il soit pleinement conforme aux exigences de
l’annexe 12, et qu’il utilise le service OSNMA disponible pendant sa
phase opérationnelle.
4. EXIGENCES APPLICABLES AUX UNITÉS EMBARQUÉES TRANSI­
TOIRES SUR VÉHICULE
Les unités embarquées transitoires sur véhicule peuvent traiter le signal
OSNMA disponible pendant sa phase d’essai public, mais elles ne peuvent
pas indiquer le statut d’authentification des messages de navigation issus
du SIS pendant la phase opérationnelle OSNMA, et ce jusqu’à ce qu’une
mise à jour logicielle appropriée soit effectuée. Par conséquent, elles indi­
quent systématiquement que les positionnements standard transmis par le
récepteur GNSS sont authentifiés.
Les exigences fixées à l’annexe I C et à ses appendices 1 à 16 s’appli­
quent, avec les interprétations suivantes.
▼M4
02016R0799 — FR — 21.08.2023 — 003.002 — 607
TRA_004 À l’annexe I C, 3.9.15 Événement “Conflit temporel”,
l’exigence 86 doit être comprise comme suit:
Cet événement est déclenché, en mode autre qu’“étalonnage”, lorsque la
VU détecte un écart entre l’heure fournie par sa fonction de mesure du
temps et l’heure provenant des positions standard transmises par le récep­
teur GNSS ou le dispositif GNSS externe. Un “écart temporel” est détecté
si la différence de temps dépasse ± 3 secondes, ce qui correspond à la
précision temporelle définie à l’exigence 41 bis, cette dernière étant
augmentée de la dérive temporelle maximale par jour. Cet événement
est enregistré avec la valeur d’horloge interne de l’appareil de contrôle.
La VU vérifie le déclenchement de l’événement “Conflit temporel” juste
avant de réajuster automatiquement son horloge interne, conformément à
l’exigence 211.
TRA_005 À l’annexe I C, point 3.9.18 Événement “Anomalie GNSS”,
l’exigence 88 bis doit être comprise comme suit:
Cet événement est déclenché, en mode autre qu’“étalonnage”, lorsque le
récepteur GNSS détecte une attaque , comme spécifié à l’appendice 12.
Après le déclenchement d’un événement “Anomalie GNSS”, la VU ne
générera plus d’autres événements “Anomalie GNSS” pendant les 10
minutes suivantes.
TRA_006 À l’annexe I C, 3.12.5 Enregistrement et stockage dans la
mémoire, Lieux et positions des lieux où les périodes de travail journa­
lières commencent et se terminent et/ou où les 3 heures de temps de
conduite accumulé sont atteintes, l’exigence 110 doit être comprise
comme suit:
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 et/ou de 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,
— le type de saisie (début, fin ou 3 heures de temps de conduite accu­
mulé),
— la précision GNSS, la date et l’heure correspondantes, le cas échéant,
— le kilométrage du véhicule,
— un drapeau indiquant que la position a été considérée comme authen­
tifiée.
TRA_007 À l’annexe I C, 3.12.17 Enregistrement et stockage dans la
mémoire, Passages aux frontières, l’exigence 133 ter doit être comprise
comme suit:
Avec les pays et la position, l’appareil de contrôle doit enregistrer et
stocker dans sa mémoire:
— le numéro de carte de conducteur et/ou de convoyeur et l’État membre
qui a délivré la carte,
— la génération de la carte,
— la précision GNSS, la date et l’heure correspondantes,
— un drapeau indiquant que la position a été considérée comme authen­
tifiée,
— le kilométrage du véhicule au moment du passage aux frontières.
▼M4
02016R0799 — FR — 21.08.2023 — 003.002 — 608
TRA_008 À l’annexe I C, 3.12.18 Enregistrement et stockage dans la
mémoire, Opérations de chargement/déchargement, l’exigence 133 octies
doit être comprise comme suit:
Avec le type d’opération et la position, l’appareil de contrôle doit enregis­
trer et stocker dans sa mémoire:
— le numéro de carte de conducteur et/ou de convoyeur et l’État membre
qui a délivré la carte,
— la génération de la carte,
— la date et l’heure de l’opération de chargement/déchargement,
— la précision GNSS, la date et l’heure correspondantes, le cas échéant,
— un drapeau indiquant que la position a été considérée comme authen­
tifiée,
— le kilométrage du véhicule.
TRA_009 À l’annexe I C, 3.23 Remise à l’heure, l’exigence 211 doit être
comprise comme suit:
Le réglage de l’heure de l’horloge interne de la VU est automatiquement
réajusté à des intervalles de temps variables. Le réajustement automatique
de l’heure suivant est déclenché entre 72 h et 168 h après le précédent et
après que la VU a pu accéder à l’heure GNSS au moyen d’un message de
position standard valide conformément à l’appendice 12. Néanmoins, le
réglage de l’heure ne doit jamais entraîner un réajustement supérieur à la
dérive temporelle maximale accumulée par jour, telle que calculée par le
fabricant de la VU conformément à l’exigence 41 ter. Si la différence
entre l’heure d’horloge interne de la VU et l’heure du récepteur GNSS
est supérieure à la dérive temporelle maximale accumulée par jour, le
réglage de l’heure doit amener l’horloge interne de la VU aussi près que
possible de l’heure du récepteur GNSS. Le réglage de l’heure ne peut être
effectué que si le temps fourni par le récepteur GNSS est obtenu à l’aide
de messages de position standard comme indiqué à l’appendice 12. La
base temps pour le réglage automatique de l’heure de l’horloge interne de
la VU doit être l’heure indiquée dans le message de position standard.
TRA_010 À l’annexe I C, 3.23 Remise à l’heure, l’exigence 212 doit être
comprise comme suit:
La fonction de remise à l’heure doit également permettre de déclencher le
réglage de l’heure courante en mode étalonnage.
Les ateliers peuvent régler l’heure:
— soit en écrivant une valeur temps dans la VU, en utilisant le service
WriteDataByIdentifier conformément à la section 6.2 de l’appendice 8,
— soit en demandant un alignement de l’horloge de la VU sur l’heure
fournie par le récepteur GNSS. Le réglage de l’heure ne peut être
effectué que si le temps fourni par le récepteur GNSS est obtenu à
l’aide de messages de position standard. Dans ce dernier cas, le
service RoutineControl doit être utilisé conformément à la section 8
de l’appendice 8.
▼M4
02016R0799 — FR — 21.08.2023 — 003.002 — 609
TRA_011 À l’appendice 4, point 2 Caractéristiques des blocs de données,
le premier alinéa, septième tiret, doit être compris comme suit:
Lorsqu’il est imprimé après la longitude et la latitude d’une position
enregistrée ou après l’horodatage du moment où la position a été déter­
minée, le pictogramme indique que cette position a été considérée
comme authentifiée.
TRA_012 À l’appendice 8, Service RoutineControl (réglage de l’heure),
le point 8.1 Description des messages, CPR_065a, doit être compris
comme suit:
Le service RoutineControl (TimeAdjustment) permet de déclencher un
alignement de l’horloge de la VU sur l’heure fournie par le récepteur
GNSS.
Pour l’exécution du service RoutineControl (TimeAdjustment), la VU doit
être en mode ÉTALONNAGE.
Condition préalable: il est garanti que la VU est en mesure de recevoir
des messages de position standard de la part du récepteur GNSS.
Tant que la remise à l’heure est en cours, la VA répondra à la demande
RoutineControl, sous-fonction requestRoutineResults, par routineInfo =
0x78.
Remarque: la remise à l’heure peut prendre un certain temps. L’appareil
de diagnostic demande le statut de remise à l’heure en utilisant la
sous-fonction requestRoutineResults.
TRA_013 À l’appendice 12, point 3 Phrases fournies par le récepteur
GNSS, l’exigence GNS_4 bis doit être comprise comme suit:
Les données contenues dans les phrases AMC fournies par le récepteur
GNSS, le cas échéant, ne sont pas utilisées par l’unité embarquée sur le
véhicule, à l’exception des valeurs suivantes du statut:
J = brouillage ou O = autre attaque GNSS (par des contrôles de cohé­
rence mis en œuvre conformément à l’exigence GNS_3 bis),
V = néant (la position authentifiée n’est pas disponible pour un autre
motif).
TRA_014 À l’appendice 12, point 3 Phrases fournies par le récepteur
GNSS, l’exigence GNS_5 doit être comprise comme suit:
Les données contenues dans les phrases ASA fournies par le récepteur
GNSS, le cas échéant, ne sont pas utilisées par l’unité embarquée sur le
véhicule.
TRA_015 À l’appendice 12, point 5.2 Unité embarquée sur le véhicule
sans dispositif GNSS externe, Transfert d’informations du récepteur GNSS
vers la VU, les exigences GNS_34 et 36 doivent être comprises comme
suit:
Le processeur de la VU n’utilise pas les informations extraites de la
phrase AMC, à l’exception des valeurs suivantes du statut:
J = brouillage ou O = autre attaque GNSS (par des contrôles de cohé­
rence mis en œuvre conformément à l’exigence GNS_3 bis),
V = néant (la position authentifiée n’est pas disponible pour un autre
motif).
Le processeur de la VU n’utilise pas les informations extraites de la
phrase ASA.
▼M4
02016R0799 — FR — 21.08.2023 — 003.002 — 610
TRA_016 À l’appendice 12, point 6 Traitement et enregistrement des
données de positionnement par la VU, l’exigence GNS_39 doit être
comprise comme suit:
Les données de positionnement sont stockées dans la VU, accompagnées
d’un drapeau indiquant si le positionnement a été considéré comme
authentifié. Lorsque les données de positionnement doivent être enregis­
trées dans la VU, la règle suivante s’applique:
a) Si le positionnement standard est valide, le positionnement standard et
son exactitude sont enregistrés dans la VU, et le drapeau doit être
“authentifié”.
TRA_017 À l’appendice 12, point 6 Traitement et enregistrement des
données de positionnement par la VU, l’exigence GNS_40 doit être
comprise comme suit:
Lorsque la valeur du statut dans une phrase AMC reçue est fixée à “J” ou
“O” conformément à l’exigence GNS_4 bis, la VU génère et enregistre un
événement “Anomalie GNSS”, conformément à l’exigence 88 bis de
l’annexe IC et à l’appendice 1 (EventFaultType), L’unité embarquée sur
véhicule peut effectuer des vérifications supplémentaires avant de stocker
un événement “Anomalie GNSS” après réception d’un statut fixé à ‘J’ ou
‘O’.
TRA_018 À l’appendice 12, point 8 Conflit concernant le mouvement du
véhicule, exigence GNS_42, condition de déclenchement 2, les premier et
deuxième tirets après la formule doivent être compris comme suit:
— GnssDistance est la distance entre la position actuelle du véhicule et
la position précédente, toutes deux obtenues à partir de messages de
positionnement standard valides, sans tenir compte de la hauteur,
— OdometerDifference est la différence entre le kilométrage actuel et le
kilométrage correspondant au précédent message de positionnement
standard valide,
TRA_019 À l’appendice 14, point 5.4.5 Algorithme de calcul des crypto­
grammes destinés aux instructions DO de confidentialité, Éléments de
RtmData, actions effectuées et définitions, exigence DSC_41, tableau 14.3,
la deuxième cellule de la ligne RTM20 doit être comprise comme suit:
La VU génère une valeur exprimée par un nombre entier (timeReal de
l’appendice 1) pour l’élément de données RTM20.
La VU attribue comme valeur pour l’élément RTM20 l’heure à laquelle la
dernière position standard du véhicule était disponible auprès du récep­
teur GNSS.
Si aucune position standard du véhicule n’était disponible auprès du
récepteur GNSS, la VU attribue la valeur 0 à RTM20.
TRA_020 Le constructeur d’une unité embarquée transitoire sur véhicule
homologuée informe la Commission de ses versions logicielles. La
Commission publie ces versions logicielles sur un site web accessible
au public.
▼M4
02016R0799 — FR — 21.08.2023 — 003.002 — 611
5. DISPOSITIONS PARTICULIÈRES RELATIVES À L’HOMOLOGA­
TION ET À L’UTILISATION DES TACHYGRAPHES TRANSITOIRES
TRA_021 Les unités embarquées transitoires doivent être homologuées
conformément aux prescriptions de l’annexe I C et de ses appendices 1
à 16, complétées par les dispositions du présent appendice.
TRA_022 Les certificats d’homologation des unités embarquées et tachy­
graphes transitoires ne peuvent être demandés que jusqu’au 31 décembre
2023 ou jusqu’à la date de déclaration de service OSNMA, la date la plus
tardive étant retenue.
TRA_023 Les unités embarquées transitoires ne peuvent être montées sur
des véhicules immatriculés pour la première fois que jusqu’au 31 mai
2024 ou jusqu’à 5 mois après la date de déclaration de service
OSNMA, la date la plus tardive étant retenue.
▼M4
02016R0799 — FR — 21.08.2023 — 003.002 — 612
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’homologation é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 — 21.08.2023 — 003.002 — 613
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 — 21.08.2023 — 003.002 — 614
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 — 21.08.2023 — 003.002 — 615
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 — 21.08.2023 — 003.002 — 616
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.


Full & Egal Universal Law Academy