ANNEXE
L’annexe IC est modifiée comme suit:
(1)la table des matières est modifiée comme suit:
(a)le point 3.6.4 suivant est inséré:
«3.6.4
Saisie des opérations de chargement/déchargement»;
(b)le point 3.9.18 suivant est inséré:
«3.9.18
Événement “Anomalie GNSS”»;
(c)les points 3.12.17, 3.12.18 et 3.12.19 suivants sont insérés:
«3.12.17
Passages aux frontières
3.12.18
Opérations de chargement/déchargement
3.12.19
Carte numérique»;
(d)le point 3.20 est remplacé par le texte suivant:
«3.20
Échanges de données avec des dispositifs externes supplémentaires»;
(e)les points 3.27 et 3.28 suivants sont insérés:
«3.27
Surveillance des passages aux frontières
3.28
Mise à jour logicielle»;
(f)le point 4.5.3.2.1.1 suivant est inséré:
«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)»;
(g)les points 4.5.3.2.17 à 4.5.3.2.22 suivants sont insérés:
«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)
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)»;
(h)le point 4.5.4.2.1.1 suivant est inséré:
«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)»;
(i)les points 4.5.4.2.16 à 4.5.4.2.22 suivants sont insérés:
«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)»;
(j)le point 4.5.5.2.1.1 suivant est inséré après le point 4.5.5.2.1:
«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)»;
(k)le point 4.5.5.2.6 suivant est inséré:
«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)»;
(l)le point 4.5.6.2.1.1 suivant est inséré après le point 4.5.6.2.1:
«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)»;
(m)le point 4.5.6.2.6 suivant est inséré:
«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)»;
(2)le texte introductif précédant la liste des appendices est remplacé par le texte suivant:
«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ération construites conformément à l’annexe I B du règlement (CEE) nº 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. Cependant, 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 coexistence 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.»;
(3)la section 1 est modifiée comme suit:
(a)le point f) est remplacé par le texte suivant:
«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 comprennent 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;»;
(b)le point g) est remplacé par le texte suivant:
«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;»;
(c)les points i) et j) sont remplacés par le texte suivant:
«(i)
“indice de renouvellement de la carte”:
le 16e 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 15e 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;»;
(d)le point ee) est remplacé par le texte suivant:
«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;»;
(e)le point ll) est remplacé par le texte suivant:
«ll)
“dispositif de communication à distance”, “module de communication à distance” ou “dispositif de détection précoce à distance”:
l’équipement de l’unité embarquée sur le véhicule utilisé pour les contrôles routiers ciblés;»;
(f)le point nn) est remplacé par le texte suivant:
«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;»;
(g)le point pp) est remplacé par le texte suivant:
«pp)
“remplacement de la carte”:
la délivrance d’une nouvelle carte tachygraphique en remplacement d’une carte existante qui a été déclarée perdue, volée ou ne fonctionnant pas correctement, et n’a pas été retournée à l’autorité qui l’a délivrée;»;
(h)le point tt) est remplacé par le texte suivant:
«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”;»;
(i)le premier tiret du point yy) est remplacé par le texte suivant:
«–
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,»;
(j)le point aaa) est remplacé par le texte suivant:
«aaa)
réservé pour une utilisation future;»;
(k)le point ccc) est remplacé par le texte suivant:
«ccc)
“date de mise en œuvre”:
la date fixée dans le règlement (UE) nº 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.»;
(4)le point 2.1 est modifié comme suit:
(a)le paragraphe 5) est remplacé par le texte suivant:
«5)
L’unité embarquée sur le véhicule doit comporter une interface ITS, qui est spécifiée à l’appendice 13.
L’appareil de contrôle peut être relié à d’autres équipements par le biais d’interfaces supplémentaires et/ou de l’interface ITS.»;
(b)au paragraphe 7), le dernier alinéa est remplacé par le texte suivant:
«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º 165/2014.»;
(5)le point 2.2 est modifié comme suit:
(a)le sixième tiret est remplacé par le texte suivant:
«–
saisie manuelle de données par le conducteur:
–
lieu de début et/ou de fin des périodes journalières de travail,
–
saisie manuelle des activités du conducteur et consentement du conducteur pour l’interface ITS,
–
saisie des conditions particulières,
–
saisie des opérations de chargement/déchargement,»;
(b)les tirets suivants sont ajoutés:
«–
surveillance des passages aux frontières,
–
mise à jour logicielle.»;
(6)le point 2.3 est modifié comme suit:
(a)au paragraphe 12), le cinquième tiret est remplacé par le texte suivant:
«–
la fonction de téléchargement n’est pas accessible 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)le paragraphe 13) est modifié comme suit:
i)
le deuxième tiret est remplacé par le texte suivant:
«–
en mode entreprise, les données relatives au conducteur (exigences 102, 105, 108, 133 bis et 133 sexies) peuvent être extraites seulement 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,»;
ii)
le quatrième tiret est remplacé par le texte suivant:
«–
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é.»;
(7)au point 2.4.14), le quatrième tiret est remplacé par le tiret suivant:
«–
dispositif GNSS externe (ce profil n’est nécessaire et applicable que pour la variante du dispositif GNSS externe).»;
(8)le point 3.1 est modifié comme suit:
(a)le paragraphe 16) est remplacé par le texte suivant:
«16)
Lors de l’insertion d’une carte (ou de son authentification à 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’appareil de contrôle doit utiliser les données de la carte tachygraphique stockées dans sa mémoire, comme indiqué à l’exigence 133.»;
(b)le paragraphe 20) est remplacé par le texte suivant:
«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.»;
(9)le point 3.2 est modifié comme suit:
(a)les paragraphes 26) et 27) sont remplacés par le texte suivant:
«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éhicule 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)au point 3.2.1, la phrase suivante est ajoutée au paragraphe 30):
«Les tolérances ne doivent pas être utilisées pour modifier intentionnellement la distance mesurée.»;
(c)au point 3.2.2, le paragraphe 33) est remplacé par le texte suivant:
«33)
Afin de garantir une tolérance maximale sur la vitesse indiquée de ± 6 km/h en service, et en tenant compte:
–
d’une tolérance de ± 2 km/h pour les variations du signal d’entrée (variations dues aux pneumatiques, etc.),
–
d’une tolérance de ± 1 km/h sur les mesures effectuées au cours de l’installation et des inspections périodiques,
l’appareil de contrôle doit, pour les vitesses comprises entre 20 et 180 km/h, et pour des coefficients caractéristiques du véhicule compris entre 2400 et 25000 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.»;
(d)au point 3.2.3, le paragraphe 37), est remplacé par le texte suivant:
«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.»;
(10)le point 3.3 est modifié comme suit:
(a)le paragraphe 41) est remplacé par le texte suivant:
«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.»;
(b)les paragraphes 41 bis), 41 ter) et 41 quater) suivants sont insérés:
«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.»;
(11)le point 3.6 est modifié comme suit:
(a)le point 3.6.1 est modifié comme suit:
i)les paragraphes 57) à 59) sont remplacés par le texte suivant:
«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 titulaire 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 enregistré sur la carte de conducteur (ou d’atelier) correspondante en tant qu’enregistrement temporaire 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;
–
saisie suivante d’un lieu où débute la période de travail journalière actuelle si le détenteur de la carte n’indique aucun emplacement de début ou de fin de la période de travail lors de la saisie manuelle en application de l’exigence 61.
Dans les conditions suivantes, la saisie temporaire 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 emplacement de début ou de fin de la période de travail lors de la saisie manuelle en application de l’exigence 61.»;
ii)au paragraphe 60), l’alinéa suivant est ajouté:
«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 conformément au point 3.12.19, et il doit demander au conducteur de confirmer ou de rectifier manuellement le lieu.»;
(b)au point 3.6.2, le paragraphe 61) est remplacé par le texte suivant:
«61)
Lors de l’insertion d’une carte de conducteur (ou d’atelier), et seulement à ce moment, l’appareil de contrôle doit permettre la saisie manuelle d’activités. La saisie manuelle d’activités est effectuée en indiquant la date et l’heure locale du fuseau horaire (décalage UTC) sélectionné pour l’unité embarquée.
Lors de l’insertion de la carte de conducteur ou d’atelier, les informations suivantes sont rappelées au détenteur de la carte:
–
la date et l’heure du dernier retrait de la carte,
–
facultativement: le décalage de l’heure locale sé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.
L’accord du conducteur (ou de l’atelier) peut être activé ou désactivé à tout moment par des commandes se trouvant dans le menu, à condition que la carte du conducteur (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 activité.
Au cours des saisies manuelles associées à l’insertion de la carte, le détenteur de celle-ci a, le cas échéant, la 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 journalière actuelle, associé à l’heure correspondante (qui valide une saisie temporaire effectuée lors du dernier retrait de la carte).
Pour le lieu où débute la période de travail journaliè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 informations 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.
En cas de saisie d’un lieu, celui-ci est enregistré sur la carte tachygraphique appropriée.
La saisie manuelle est interrompue si:
–
la carte est retirée ou
–
le véhicule est mis en mouvement alors que la carte se trouve dans le lecteur réservé au conducteur.
Des interruptions supplémentaires sont autorisées, par exemple une temporisation après une certaine période d’inactivité de l’utilisateur. En cas d’interruption de la saisie manuelle, l’appareil de contrôle valide toute saisie complète de lieu et d’activité déjà effectuée (indiquant sans ambiguïté un lieu et une heure, ou un type d’activité, une heure de début et une heure de fin).
Si une seconde carte de conducteur ou d’atelier est insérée alors que la saisie manuelle d’activités est en cours pour une carte insérée auparavant, la saisie concernant cette première carte doit pouvoir être achevée avant le début de la saisie manuelle pour la seconde carte.
Le détenteur de la carte a la possibilité d’effectuer une saisie manuelle selon la procédure minimale suivante:
–
saisie manuelle des activités, par ordre chronologique, pour la période allant du dernier retrait de la carte à son insertion actuelle,
–
l’heure de début de la première activité est fixée à l’heure du retrait de la carte. Pour chaque saisie ultérieure, l’heure de début présélectionnée suit immédiatement l’heure de fin de la saisie précédente. Le type d’activité et l’heure de fin doivent être sélectionnés pour chaque activité.
La procédure se 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 conducteurs 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élection d’une commande particulière. Par la suite, toute modification de ce type est interdite.»;
(c)au point 3.6.3, le paragraphe 62) est remplacé par le texte suivant:
«62)
L’appareil de contrôle doit permettre au conducteur de saisir en temps réel les deux conditions particulières suivantes:
–
“HORS CHAMP” (début, fin),
–
“TRAJET EN FERRY/TRAIN” (début, fin).
Un “TRAJET EN FERRY/TRAIN” ne 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 correspondant à 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.»;
(d)le point 3.6.4 suivant est ajouté:
«3.6.4
Saisie des opérations de chargement/déchargement
62 bis)
L’appareil de contrôle doit permettre au conducteur 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ération 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échargement doivent être saisies avant que le véhicule ne quitte le lieu où l’opération de chargement/déchargement est effectuée.»;
(12)le point 3.9 est modifié comme suit:
(a)au point 3.9.12, le paragraphe 83) est remplacé par le texte suivant:
«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 mouvement et l’unité embarquée sur le véhicule et/ou en cas d’erreur sur l’intégrité des données ou l’authentification des données au cours de l’échange de données entre le capteur de mouvement et la VU. 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)au point 3.9.13, le paragraphe 84) est remplacé par le texte suivant:
«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 fournies 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.»;
(c)au point 3.9.15, le paragraphe 86) est remplacé par le texte suivant:
«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 positions 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 automatiquement son horloge interne, conformément à l’exigence 211.»;
(d)au point 3.9.17, le huitième tiret est remplacé par le texte suivant:
«–
anomalie sur l’interface ITS.»;
(e)le point suivant est ajouté:
«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é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.»;
(13)au point 3.10, la dernière ligne du tableau est remplacée par la suivante:
«
|
Interface ITS
|
Fonctionnement correct
|
|
»;
(14)le point 3.12 est modifié comme suit:
(a)le premier paragraphe est remplacé par le texte suivant:
«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 changements d’activités. “365 jours” incluent donc au moins 2190 conducteurs ou convoyeurs, 2190 cycles d’insertion/retrait de cartes et 93440 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 positions 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”,
–
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 chargement/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)le point 3.12.1.1 est modifié comme suit:
i)au paragraphe 93), le tiret suivant est ajouté:
«–
identificateur de la version de la carte numérique (exigence 133 terdecies).»;
ii)le paragraphe 94) est remplacé par le texte suivant:
«94)
Les données d’identification de l’unité embarquée sur le véhicule sont enregistrées et stockées une fois pour toutes par le fabricant de l’unité embarquée sur le véhicule, à 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.»;
(c)au point 3.12.1.2, paragraphe 97), le premier alinéa est remplacé par le texte suivant:
«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):»;
(d)au point 3.12.1.3, paragraphe 100), le premier alinéa est remplacé par le texte suivant:
«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).»;
(e)le point 3.12.5. est modifié comme suit:
i)le paragraphe 110) est modifié comme suit:
1)
le premier tiret est remplacé par le texte suivant:
«–
le numéro de carte de conducteur et/ou de convoyeur et l’État membre qui a délivré la carte»;
2)
le tiret suivant est ajouté:
«–
un drapeau indiquant si la position a été authentifiée.»;
ii)le paragraphe 110 bis) suivant est inséré:
«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 conformément à l’exigence 61, le kilométrage et la position du véhicule doivent être enregistrés.»;
(f)au point 3.12.8, le tableau du paragraphe 117) est modifié comme suit:
i)la cinquième ligne est remplacée par le texte suivant:
«
|
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.
|
»;
ii)la ligne suivante est ajoutée:
«
|
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 enregistrés au cours des 365 derniers jours.
|
–
la date et l’heure du début de l’événement,
–
la date et l’heure de la fin de l’événement,
–
le type et le numéro de la ou des cartes, l’État membre de délivrance et la génération de toute carte insérée au début et/ou à la fin de l’événement,
–
le nombre d’événements semblables survenus le même jour.
|
»;
(g)au point 3.12.10, les tirets suivants sont ajoutés au paragraphe 120):
«–
les numéros de série du capteur de mouvement, du dispositif GNSS externe (le cas échéant) et du dispositif externe de communication à distance (le cas échéant),
–
le type de charge par défaut associé au véhicule (chargement de biens ou de passagers),
–
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.»;
(h)les points suivants sont ajoutés:
«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éhicule 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échargement ou chargement/déchargement simultanés),
–
la position correspondant au lieu où l’opération de chargement/déchargement s’est déroulée.
133 septies)
Lorsque le récepteur GNSS ne peut communiquer la position du véhicule au moment de l’opération de chargement/déchargement, l’appareil 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,
–
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 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’appareil 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 frontiè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 territoriales statistiques (NUTS),
–
une échelle de 1:1 million.
133 quindecies)
Les fabricants de tachygraphes doivent sélectionner 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 Commission 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 fabricant, 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.
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.»;
(15)le point 3.13 est modifié comme suit:
(a)au paragraphe 134), le troisième tiret est remplacé par le texte suivant:
«–
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)le paragraphe 135 bis) suivant est ajouté:
«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émentaires 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 correspondre 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’authentification, qui doit correspondre exactement à la date et à l’heure de la saisie stockées avec la position correspondante dans EF Places.
–
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’identification 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’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.»;
(16)le point 3.14 est modifié comme suit:
(a)le point 3.14.1 est modifié comme suit:
i)le paragraphe 140) est remplacé par le texte suivant:
«140)Tous les événements ou anomalies non définis pour l’appareil de contrôle de première génération ne sont pas stockés sur les cartes de conducteur et d’atelier de première génération.»;
ii)le paragraphe 143) est remplacé par le texte suivant:
«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)le point 3.14.2 est modifié comme suit:
i)au paragraphe 144), l’alinéa suivant est ajouté:
«La structure dans l’application “TACHO_G2” dépend de la version. Les cartes de la version 2 contiennent des fichiers élémentaires supplémentaires par rapport à celles de la version 1.»;
ii)les paragraphes 147 bis) et 147 ter) suivants sont insérés:
«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 journaliè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 enregistrement 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,
–
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 franchissement de la frontière: non disponible,
–
le kilométrage du véhicule: non disponible.»;
iii)Le paragraphe 150 bis) suivant est ajouté:
«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.»;
(17)au point 3.15.4, le paragraphe 167) est modifié comme suit:
(a)le deuxième tiret est remplacé par le texte suivant:
«–
le contenu de tout tirage papier visé à l’exigence 169, dans le même format que le tirage papier lui-même,»;
(b)les cinquième et sixième tirets sont remplacés par le texte suivant:
«–
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,»;
(c)les huitième, neuvième et dixième tirets sont remplacés par le texte suivant:
«–
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.»;
(18)le point 3.18 est modifié comme suit:
(a)le paragraphe 193) est remplacé par le texte suivant:
«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)les paragraphes 196 bis) et 196 ter) suivants sont insérés:
«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’application du règlement (CE) nº 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.»;
(19)au point 3.19, les tirets suivants sont ajoutés au paragraphe 199):
«–
position du véhicule,
–
une indication s’il se peut que le conducteur soit en train d’enfreindre les temps de conduite.»;
(20)le point 3.20 est modifié comme suit:
(a)le titre est remplacé par le titre suivant:
«3.20
Échanges de données avec des dispositifs externes supplémentaires»;
(b)le paragraphe 200) est remplacé par le texte suivant:
«200)
L’appareil de contrôle doit également être équipé d’une interface ITS conformément à l’appendice 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’interface 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’intermédiaire de cette interface:
–
les données à caractère personnel ne doivent être disponibles que sous réserve du consentement vérifiable du conducteur, qui accepte que ses données à caractère personnel puissent quitter le réseau du véhicule.
Un ensemble de données existantes sélectionnées qui peuvent être disponibles par l’intermé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,
–
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é embarquée sur véhicule peuvent coexister, à condition qu’elles respectent pleinement les exigences de l’appendice 13 en ce qui concerne le consentement du conducteur. L’appareil de contrôle permet de communiquer le statut du consentement 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 introduites 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 introduire 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.»;
(c)le paragraphe 201) est remplacé par le texte suivant:
«201)
L’interface de liaison série spécifiée dans l’annexe I B du règlement (CEE) nº 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.»;
(21)le point 3.21 est modifié comme suit:
(a)le paragraphe 202) est modifié comme suit:
i)le neuvième tiret est remplacé par le texte suivant:
«–
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,»;
ii)
le tiret suivant est ajouté:
«–
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écepteur GNSS.»;
(b)le paragraphe 205) est remplacé par le texte suivant:
«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.»;
(22)au point 3.22, l’alinéa suivant est ajouté au paragraphe 209):
«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.»;
(23)le point 3.23 est modifié comme suit:
(a)le paragraphe 211) est remplacé par le texte suivant:
«211) 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 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é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 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é.»;
(b)le paragraphe 212) est remplacé par le texte suivant:
«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’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 authentifiés. Dans ce dernier cas, le service RoutineControl doit être utilisé conformément à la section 8 de l’appendice 8.»;
(24)les points 3.27 et 3.28 suivants sont insérés:
«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 logicielles sur la base de l’unité embarquée sur véhicule existante homologuée, conformément à l’article 12, paragraphe 5, du règlement (UE) nº 165/2014.
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 logicielles 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.»;
(25)au point 4.1, après le paragraphe 235), sur l’image «Cartes tachygraphiques de modèle communautaire», le verso de la carte de contrôle est remplacé par le texte suivant:
«
»;
(26)le point 4.5 est modifié comme suit:
(a)le paragraphe 246) est remplacé par le texte suivant:
«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)au paragraphe 247), la remarque suivante est insérée après le deuxième tiret:
«Remarque: la version 2 des cartes de deuxième génération contient des fichiers élémentaires supplémentaires dans DF Tachograph_G2.»;
(c)le point 4.5.3.2 est modifié comme suit:
i)le titre est remplacé par le titre suivant:
«4.5.3.2
L’application tachygraphique de deuxième génération (non accessible aux unités embarquées sur véhicule de première génération, accessible par les versions 1 et 2 des unités embarquées sur véhicule de deuxième génération)»;
ii)le point 4.5.3.2.1.1 suivant est inséré après le point 4.5.3.2.1:
«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.»;
iii)au point 4.5.3.2.7, le paragraphe 287) est remplacé par le texte suivant:
«287)
La carte de conducteur doit permettre le stockage des données concernant les 12 derniers événements de chaque type (soit 132 événements).»;
iv)au point 4.5.3.2.8, le paragraphe 290) est remplacé par le texte suivant:
«290)
La carte de conducteur doit permettre le stockage des données relatives aux 24 dernières anomalies de chaque type (soit 48 anomalies).»;
v)au point 4.5.3.2.9, le paragraphe 292) est remplacé par le texte suivant:
«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 changements d’activité par jour).»;
vi)au point 4.5.3.2.10, le paragraphe 295) est remplacé par le texte suivant:
«295)
La carte de conducteur doit pouvoir stocker 200 enregistrements de ce type.»;
vii)au point 4.5.3.2.11, le paragraphe 297) est remplacé par le texte suivant:
«297)
La mémoire de la carte de conducteur doit pouvoir stocker 112 enregistrements de ce type.»;
viii)au point 4.5.3.2.14, le paragraphe 302) est remplacé par le texte suivant:
«302)
La carte de conducteur doit pouvoir stocker 112 enregistrements de ce type.»;
ix)au point 4.5.3.2.15, le paragraphe 304) est remplacé par le texte suivant:
«304)
La carte de conducteur doit pouvoir stocker 200 enregistrements de ce type.»;
x)au point 4.5.3.2.16, le paragraphe 306) est remplacé par le texte suivant:
«306)
La carte de conducteur doit pouvoir stocker 336 enregistrements de ce type.»;
xi)les points 4.5.3.2.17 à 4.5.3.2.22 suivants sont ajoutés:
«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)
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 journalières de travail, saisies par le conducteur conformé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.
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 franchissement 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ération)
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échargement ou chargement/déchargement simultanés),
–
la date et l’heure de l’opération de chargement/déchargement,
–
la position du véhicule,
–
la précision GNSS, la date et l’heure de détermination de la position,
–
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 passagers),
–
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étenteur 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.»;
(d)le point 4.5.4.2 est modifié comme suit:
i)le titre est remplacé par le titre suivant:
«4.5.4.2
L’application tachygraphique de deuxième génération (non accessible aux unités embarquées sur véhicule de première génération, accessible par les versions 1 et 2 des unités embarquées sur véhicule de deuxième génération)»;
ii)le point 4.5.4.2.1.1 suivant est inséré après le point 4.5.4.2.1:
«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émentaires applicables seulement pour la version 2.»;
iii)au point 4.5.4.2.6, le paragraphe 338) est remplacé par le texte suivant:
«338)
La carte d’atelier doit pouvoir stocker 255 enregistrements de ce type.»;
iv)au point 4.5.4.2.8, le paragraphe 344) est remplacé par le texte suivant:
«344)
La carte d’atelier doit pouvoir stocker des données concernant l’activité du conducteur pendant 1 jour comprenant 240 changements d’activité.»;
v)au point 4.5.4.2.9, le paragraphe 346) est remplacé par le texte suivant:
«346)
La carte d’atelier doit pouvoir stocker 8 enregistrements de ce type.»;
vi)le point 4.5.4.2.10 est remplacé par le texte suivant:
«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 journaliè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.»;
vii)au point 4.5.4.2.13, le paragraphe 352) est remplacé par le texte suivant:
«352)
La carte d’atelier doit pouvoir stocker 8 enregistrements de ce type.»;
viii)au point 4.5.4.2.14, le paragraphe 354) est remplacé par le texte suivant:
«354)
La carte d’atelier doit pouvoir stocker 24 enregistrements de ce type.»;
ix)au point 4.5.4.2.15, le paragraphe 356) est remplacé par le texte suivant:
«356)
La carte d’atelier doit pouvoir stocker 4 enregistrements de ce type.»;
x)les points 4.5.4.2.16 à 4.5.4.2.22 suivants sont ajoutés:
«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)
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.
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 position 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 enregistrements 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érations 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 enregistrements 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 applicables 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 enregistrements de ce type.
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 paramè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.»;
(e)le point 4.5.5 est modifié comme suit:
i)au point 4.5.5.1.5, le deuxième tiret est remplacé par le texte suivant:
«–
type du contrôle (affichage et/ou impression et/ou téléchargement à partir de la VU et/ou à partir de la carte),»;
ii)le point 4.5.5.2.1.1 suivant est inséré après le point 4.5.5.2.1:
«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.»;
iii)le point suivant est inséré après le point 4.5.5.2.5:
«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étenteur 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.»;
(f)le point 4.5.6.2 est modifié comme suit:
i)le point suivant est inséré après le point 4.5.6.2.1:
«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)
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.»;
ii)le point 4.5.6.2.6 suivant est ajouté:
«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étenteur 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.»;
(27)le point 5 est modifié comme suit:
(a)le point 5.1 est modifié comme suit:
i)le paragraphe 383) est remplacé par le texte suivant:
«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 enregistrer 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.»;
ii)le paragraphe 392) est remplacé par le texte suivant:
«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º 561/2006 (par exemple à l’aide de commandes via une structure de menu appropriée de l’interface homme-machine de l’unité embarquée). Seule l’utilisation d’une carte d’atelier doit permettre la mise à jour ou la confirmation de cette saisie.»;
(b)le point 5.2 est modifié comme suit:
i)au paragraphe 395), le premier alinéa est remplacé par le texte suivant:
«Après la vérification de l’appareil de contrôle une fois installé, une plaquette d’installation, gravée ou imprimée de façon permanente, bien visible et facilement accessible, doit être fixée sur l’appareil de contrôle. Dans les cas où cela n’est pas possible, la plaquette est apposée sur le pied milieu du véhicule, de manière à être clairement visible. Si le véhicule n’a pas de pied milieu, la plaquette d’installation doit être apposée à proximité de la portière du véhicule, et être bien visible dans tous les cas.»;
ii)le paragraphe 396) est modifié comme suit:
1)
le dixième tiret est remplacé par le texte suivant:
«–
le numéro de série du dispositif de communication à distance, le cas échéant,»;
2)
le seizième tiret suivant est ajouté:
«–
le type de charge par défaut associé au véhicule.»;
(28)le point 6.4 est modifié comme suit:
(a)le paragraphe 409) est remplacé par le texte suivant:
«409)
Des inspections périodiques des appareils montés sur les véhicules ont lieu après toute réparation, ou après toute modification du coefficient caractéristique du véhicule ou de la circonférence effective des pneumatiques, ou lorsque l’horloge UTC est fausse de plus de 5 minutes, ou lorsque le numéro d’immatriculation a changé, et au moins une fois tous les deux ans (24 mois).»;
(b)au paragraphe 410), le neuvième tiret suivant est ajouté:
«–
identificateur de version de la carte numérique stockée le plus récent.»;
(c)le paragraphe 410 bis) suivant est inséré:
«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éétalonnage de l’appareil de contrôle.»;
(29)le point 8 est modifié comme suit:
(a)au point 8.1, les paragraphes 429) et 430) sont remplacés par le texte suivant:
«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’homologation 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 fonctions non spécifiées dans la présente annexe. La mise à jour logicielle d’un appareil de contrôle peut exclure l’introduction de nouveaux jeux de caractères si ce n’est pas techniquement faisable.»;
(b)le point 8.4 est modifié comme suit:
i)le paragraphe 443) est remplacé par le texte suivant:
«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 exceptionnelles décrites dans l’exigence 432.»;
ii)le paragraphe 447) est remplacé par le texte suivant:
«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.»;
(30)l’appendice 1 est modifié comme suit:
(a)la table des matières est modifiée comme suit:
i)les points 2.11 bis et 2.11 ter suivants sont insérés:
«2.11 bis
CardBorderCrossing
2.11 ter
CardBorderCrossingRecord»;
ii)les points 2.24 bis, 2.24 ter, 2.24 quater et 2.24 quinquies suivants sont insérés:
«2.24 bis
CardLoadTypeEntries
2.24 ter
CardLoadTypeEntryRecord
2.24 quater
CardLoadUnloadOperations
2.24 quinquies
CardLoadUnloadRecord»;
iii)le point 2.26 bis suivant est inséré:
«2.26 bis
CardPlaceAuthDailyWorkPeriod»;
iv)le point 2.48 bis suivant est inséré:
«2.48 bis
CompanyCardApplicationIdentificationV2»;
v)le point 2.50 bis suivant est inséré:
«2.50 bis
ControlCardApplicationIdentificationV2»;
vi)le point 2.60 bis suivant est inséré:
«2.60 bis
DownloadInterfaceVersion»;
vii)le point 2.61 bis suivant est inséré:
«2.61 bis
DriverCardApplicationIdentificationV2»;
viii)les points 2.79 bis, 2.79 ter et 2.79 quater suivants sont insérés:
«2.79 bis
GNSSAuthAccumulatedDriving
2.79 ter
GNSSAuthStatusADRecord
2.79 quater
GNSSPlaceAuthRecord»;
ix)le point 2.84 est remplacé par le texte suivant:
«2.84.
Réservé pour une utilisation future»;
x)le point 2.89 bis suivant est inséré:
«2.89 bis
LengthOfFollowingData»;
xi)le point 2.90 bis suivant est inséré:
«2.90 bis
LoadType»;
xii)le point 2.101 bis suivant est inséré:
«2.101 bis
NoOfBorderCrossingRecords»;
xiii)le point 2.111 bis suivant est inséré:
«2.111 bis
NoOfLoadUnloadRecords»;
xiv)le point 2.112 bis suivant est inséré:
«2.112 bis
NoOfLoadTypeEntryRecords»;
xv)le point 2.114 bis suivant est inséré:
«2.114 bis
OperationType»;
xvi)les points 2.116 bis et 2.116 ter suivants sont insérés:
«2.116 bis
PlaceAuthRecord
2.116 ter
PlaceAuthStatusRecord»;
xvii)le point 2.117 bis suivant est inséré:
«2.117 bis
PositionAuthenticationStatus»;
xviii)le point 2.158 bis suivant est inséré:
«2.158 bis
TachographCardsGen1Suppression»;
xix)le point 2.166 bis suivant est inséré:
«2.166 bis
VehicleRegistrationIdentificationRecordArray»;
xx)le point 2.185 bis suivant est inséré:
«2.185 bis
VuConfigurationLengthRange»;
xxi)le point 2.192 bis suivant est inséré:
«2.192 bis
VuDigitalMapVersion»;
xxii)les points 2.203 bis et 2.203 ter suivants sont insérés:
«2.203 bis
VuBorderCrossingRecord
2.203 ter
VuBorderCrossingRecordArray»;
xxiii)le point 2.204 bis suivant est inséré:
«2.204 bis
VuGnssMaximalTimeDifference»;
xxiv)les points 2.208 bis et 2.208 ter suivants sont insérés:
«2.208 bis
VuLoadUnloadRecord
2.208 ter
VuLoadUnloadRecordArray»;
xxv)le point 2.222 bis suivant est inséré:
«2.222 bis
VuRtcTime»;
xxvi)les points 2.234 bis, 2.234 ter et 2.234 quater suivants sont insérés:
«2.234 bis
WorkshopCardApplicationIdentificationV2
2.234 ter
WorkshopCardCalibrationAddData
2.234 quater
WorkshopCardCalibrationAddDataRecord»;
(b)au point 2, le texte précédant le point 2.1 est remplacé par le texte suivant:
«Quel que soit le type de données considéré parmi ceux qui suivent, un contenu “inconnu” ou “sans objet” entraînera l’attribution d’une valeur par défaut résultant du remplissage de l’élément de données concerné au moyen d’hex octets ‘FF’, sauf disposition contraire.
Tous les types de données servent aux applications de génération 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 appendice est celle relative à l’application de génération 2. La taille relative à l’application de génération 1 est censée être déjà connue du lecteur. Les numéros des exigences de l’annexe IC relatives à ces types de données couvrent à la fois les applications de génération 1 et de génération 2.
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ération 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.»;
(c)les points 2.11 bis et 2.11 ter suivants sont insérés:
«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).
|
CardBorderCrossings ::= SEQUENCE {
borderCrossingPointerNewestRecord
INTEGER (0..NoOfBorderCrossingRecords -1),
cardBorderCrossingRecords
SET SIZE (NoOfBorderCrossingRecords)
OF CardBorderCrossingRecord
}
|
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.
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).
|
CardBorderCrossingRecord ::= SEQUENCE {
countryLeft
NationNumeric,
countryEntered
NationNumeric,
gnssPlaceAuthRecord
GNSSPlaceAuthRecord,
vehicleOdometerValue
OdometerShort
}
|
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’insertion 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 position 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 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, ou “aucune information disponible” conformément à l’exigence 147 ter de l’annexe IC.»;
(d)les points 2.24 bis, 2.24 ter, 2.24 quater et 2.24 quinquies suivants sont insérés:
«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).
|
CardLoadTypeEntries ::= SEQUENCE {
loadTypeEntryPointerNewestRecord
INTEGER(0..NoOfLoadTypeEntryRecords -1),
cardLoadTypeEntryRecords
SET SIZE(NoOfLoadTypeEntryRecords) OF
CardLoadTypeEntryRecord
}
|
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.
cardLoadTypeEntryRecords indique le jeu de relevés contenant 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’insertion de la carte dans l’unité embarquée sur véhicule (exigences 306 decies et 356 decies de l’annexe IC).
|
CardLoadTypeEntryRecord ::= SEQUENCE {
timeStampTimeReal,
loadTypeEnteredLoadType
}
|
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échargement du véhicule (exigences 306 nonies et 356 nonies de l’annexe IC).
|
CardLoadUnloadOperations ::= SEQUENCE {
loadUnloadPointerNewestRecordINTEGER(0..NoOfLoadUnloadRecords -1),
cardLoadUnloadRecords
SET SIZE(NoOfLoadUnloadRecords) OF
CardLoadUnloadRecord
}
|
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échargement 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échargement du véhicule (exigences 306 octies et 356 octies de l’annexe IC).
|
CardLoadUnloadRecord ::= SEQUENCE {
timeStampTimeReal,
operationTypeOperationType,
gnssPlaceAuthRecordGNSSPlaceAuthRecord,
vehicleOdometerValueOdometerShort
}
|
timeStamp est la date et l’heure du début de l’opération de chargement/déchargement.
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échargement.»;
(e)le point 2.26 bis suivant est inséré:
«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).
|
CardPlaceAuthDailyWorkPeriod ::= SEQUENCE {
placeAuthPointerNewestRecordINTEGER(0 .. NoOfCardPlaceRecords-1),
placeAuthStatusRecordsSET SIZE(NoOfCardPlaceRecords) OF PlaceAuthStatusRecord
}
|
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.»;
(f)au point 2.36, le texte correspondant à l’attribution de valeur ‘bbH’ est remplacé par le texte suivant:
«bb’H
Index des modifications concernant l’utilisation des éléments d’information définis pour la structure donnée par l’octet de poids fort.
‘00’H pour 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»;
(g)au point 2.40, le paragraphe entre l’en-tête et le code est remplacé par le texte suivant:
«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).»;
(h)le point 2.48 bis suivant est inséré:
«2.48 bis
CompanyCardApplicationIdentificationV2
Génération 2, version 2:
Informations enregistrées sur une carte d’entreprise et se rapportant à l’identification de l’application de la carte (exigence 375 bis de l’annexe IC).
|
CompanyCardApplicationIdentificationV2 ::= SEQUENCE {
lengthOfFollowingData
LengthOfFollowingData,
vuConfigurationLengthRange
VuConfigurationLengthRange
}
|
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.»;
(i)le point 2.50 bis suivant est inséré:
«2.50 bis
ControlCardApplicationIdentificationV2
Génération 2, version 2:
Informations enregistrées sur une carte de contrôle et se rapportant à l’identification de l’application de la carte (exigence 363 bis de l’annexe IC).
|
ControlCardApplicationIdentificationV2 ::= SEQUENCE {
lengthOfFollowingData
LengthOfFollowingData,
vuConfigurationLengthRange
VuConfigurationLengthRange
}
|
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.»;
(j)le point 2.60 bis suivant est inséré:
«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.
|
DownloadInterfaceVersion ::= OCTET STRING (SIZE(2))
|
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ération 2.»;
(k)le point 2.61 bis suivant est inséré:
«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).
|
DriverCardApplicationIdentificationV2 ::= SEQUENCE {
lengthOfFollowingDataLengthOfFollowingData,
noOfBorderCrossingRecordsNoOfBorderCrossingRecords,
noOfLoadUnloadRecordsNoOfLoadUnloadRecords,
noOfLoadTypeEntryRecordsNoOfLoadTypeEntryRecords,
vuConfigurationLengthRangeVuConfigurationLengthRange
}
|
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 susceptible de mémoriser.
noOfLoadUnloadRecords indique le nombre de relevés de chargement/déchargement que la carte de conducteur est susceptible 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.»;
(l)le point 2.63 est remplacé par le texte suivant:
«2.63.
DSRCSecurityData
Génération 2:
Pour la définition de ce type de données, cf. appendice 11.»;
(m)au point 2.66, le texte se rapportant à la génération 2 est remplacé par le texte suivant:
«Génération 2
|
EntryTypeDailyWorkPeriod ::= INTEGER {
Begin,
related time = card insertion time or time of entry(0),
End,
related time = card withdrawal time or time of entry
(1),
Begin,
related time manually entered (start time)
(2),
End,
related time manually entered (end of work period)
(3)
}
|
Attribution de valeur: conforme à la norme ISO/IEC8824-1.»;
(n)le point 2.70 est modifié comme suit:
i)l’en-tête se rapportant à la génération 2 est remplacé par le texte suivant:
«Génération 2, version 1:»;
ii)le texte suivant est inséré:
«Génération 2, version 2:
‘0x’H événements généraux,
‘00’Habsence d’informations complémentaires,
‘01’Hinsertion d’une carte non valable,
‘02’Hconflit de carte,
‘03’Hchevauchement temporel,
‘04’Hconduite sans carte appropriée,
‘05’Hinsertion de carte en cours de conduite,
‘06’Hdernière session incorrectement clôturée,
‘07’Hexcès de vitesse,
‘08’Hcoupure d’alimentation électrique,
‘09’Herreur sur les données de mouvement,
‘0A’Hconflit concernant le mouvement du véhicule,
‘0B’Hconflit temporel (GNSS contre l’horloge interne de la VU),
‘0C’Herreur de communication avec le dispositif de communication à distance,
‘0D’Habsence d’informations de positionnement en provenance du récepteur GNSS,
‘0E’Herreur de communication avec le dispositif GNSS externe,
‘0F’Hanomalie GNSS,
‘1x’Htentatives d’atteinte à la sécurité en rapport avec l’unité embarquée sur véhicule,
‘10’Habsence d’informations complémentaires,
‘11’Hdéfaut d’authentification du capteur de mouvement,
‘12’Hdéfaut d’authentification d’une carte tachygraphique,
‘13’Hremplacement sans autorisation du capteur de mouvement,
‘14’Hdéfaut d’intégrité affectant la saisie de données sur la carte,
‘15’Hdéfaut d’intégrité affectant les données utilisateur mémorisées,
‘16’Herreur de transfert de données internes,
‘17’Houverture illicite d’un boîtier,
‘18’Hsabotage du matériel,
‘19’Hdétection de violation du dispositif GNSS,
‘1A’Hdéfaut d’authentification du dispositif GNSS externe,
‘1B’H expiration du certificat du dispositif GNSS externe,
‘1C’HDivergence entre les données de mouvement et les données enregistrées relatives à l’activité du conducteur,
‘1D’H à ‘1F’HRFU,
‘2x’Htentatives d’atteinte à la sécurité en rapport avec le capteur de mouvement,
‘20’Habsence d’informations complémentaires,
‘21’Héchec d’une authentification,
‘22’Hdéfaut d’intégrité affectant les données mémorisées,
‘23’Herreur de transfert de données internes,
‘24’Houverture illicite d’un boîtier,
‘25’Hsabotage du matériel,
‘26’H à ‘2F’HRFU,
‘3x’H anomalies affectant l’appareil de contrôle,
‘30’Habsence d’informations complémentaires,
‘31’Hanomalie interne affectant la VU,
‘32’Hanomalie affectant l’imprimante,
‘33’Hanomalie affectant l’affichage,
‘34’Hanomalie affectant le téléchargement,
‘35’Hanomalie affectant le capteur de mouvement,
‘36’Hrécepteur du dispositif GNSS interne,
‘37’Hdispositif GNSS externe,
‘38’Hdispositif de communication à distance,
‘39’Hinterface ITS,
‘3A’Hanomalie du capteur interne,
‘3B’H à ‘3F’HRFU,
‘4x’Hanomalies affectant une carte,
‘40’Habsence d’informations complémentaires,
‘41’H à ‘4F’HRFU,
‘50’H à ‘7F’HRFU,
‘80’H à ‘FF’Hpropre au fabricant.»;
(o)le point 2.71 est remplacé par le texte suivant:
«2.71.
ExtendedSealIdentifier
Génération 2:
L’identifiant de scellement étendu identifie un scellement de manière unique (exigence 401, annexe IC).
|
ExtendedSealIdentifier ::= SEQUENCE{
manufacturerCode
IA5String (SIZE(2)),
sealIdentifier
IA5String (SIZE(8))
}
|
manufacturerCode correspond au code du fabricant du scellement. 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].»;
(p)au point 2.76, le paragraphe entre l’en-tête et le code est remplacé par le texte suivant:
«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).»;
(q)les points 2.79 bis, 2.79 ter et 2.79 quater suivants sont insérés:
«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).
|
GNSSAuthAccumulatedDriving ::= SEQUENCE {
gnssAuthADPointerNewestRecord
INTEGER(0..NoOfGNSSADRecords -1),
gnssAuthStatusADRecords
SET SIZE (NoOfGNSSADRecords) OF GNSSAuthStatusADRecord
}
|
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).
|
GNSSAuthStatusADRecord ::= SEQUENCE {
timeStamp
TimeReal,
authenticationStatus
PositionAuthenticationStatus
}
|
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 GNSSAccumulatedDrivingRecord correspondant).
authenticationStatus désigne le statut d’authentification de la position GNSS lorsque le temps de conduite accumulé atteint un multiple de trois heures.
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).
|
GNSSPlaceAuthRecord ::= SEQUENCE {
timeStamp
TimeReal,
gnssAccuracy
GNSSAccuracy,
geoCoordinates
GeoCoordinates,
authenticationStatus
PositionAuthenticationStatus
}
|
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.»;
(r)le point 2.84 est remplacé par le texte suivant:
«2.84.
Réservé pour une utilisation future»;
(s)le point 2.89 bis suivant est inséré:
«2.89 bis
LengthOfFollowingData
Génération 2, version 2:
Indicateur de longueur pour les relevés extensibles.
|
LengthOfFollowingData ::= INTEGER(0.. 216-1)
|
Attribution de valeur: cf. appendice 2.»;
(t)le point 2.90 bis suivant est inséré:
«2.90 bis
LoadType
Génération 2, version 2:
Code identifiant un type de charge introduit.
|
LoadType ::= INTEGER(0..255)
|
Attribution de valeur:
‘00’H
type de charge non défini,
‘01’H
biens,
‘02’H
passagers,
‘03’H .. ‘FF’H
RFU.»;
(u)le point 2.101 bis suivant est inséré:
«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.
|
NoOfBorderCrossingRecords ::= INTEGER(0.. 216-1)
|
Attribution de valeur: cf. appendice 2.»;
(v)le point 2.111 bis suivant est inséré:
«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.
|
NoOfLoadUnloadRecords ::= INTEGER(0..216-1)
|
Attribution de valeur: cf. appendice 2.»;
(w)le point 2.112 bis suivant est inséré:
«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.
|
NoOfLoadTypeEntryRecords ::= INTEGER(0..216-1)
|
Attribution de valeur: cf. appendice 2.»;
(x)le point 2.114 bis suivant est inséré:
«2.114 bis
OperationType
Génération 2, version 2:
Code identifiant un type d’opération saisi.
|
OperationType ::= INTEGER(0..255)
|
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 simultanés,
‘04’H .. ‘FF’H
RFU.»;
(y)les points 2.116 bis et 2.116 ter suivants sont insérés:
«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:
|
PlaceAuthRecord ::= SEQUENCE {
entryTime
TimeReal,
entryTypeDailyWorkPeriod
EntryTypeDailyWorkPeriod,
dailyWorkPeriodCountry
NationNumeric,
dailyWorkPeriodRegion
RegionNumeric,
vehicleOdometerValue
OdometerShort,
entryGNSSPlaceAuthRecord
GNSSPlaceAuthRecord
}
|
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 relatives au lieu lui-même sont stockées dans un autre relevé (voir 2.117 PlaceRecord).
|
PlaceAuthStatusRecord ::= SEQUENCE {
entryTimeTimeReal,
authenticationStatusPositionAuthenticationStatus
}
|
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.»;
(z)le point 2.117 bis suivant est inséré:
«2.117 bis
PositionAuthenticationStatus
Génération 2, version 2:
|
PositionAuthenticationStatus ::= INTEGER(0..255)
|
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.»;
(aa)au point 2.120, l’attribution des valeurs ‘22’H à ‘7F’H est remplacée par le texte suivant:
«‘22’H
VuBorderCrossingRecord,
‘23’H
VuLoadUnloadRecord,
‘24’H
Identification et immatriculation du véhicule
‘25’H à ‘7F’H
RFU.»;
(bb)le point 2.158 bis suivant est inséré:
«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).
|
TachographCardsGen1Suppression ::= INTEGER (0..216-1)
|
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é.»;
(cc)le point 2.166 bis suivant est inséré:
«2.166 bis
VehicleRegistrationIdentificationRecordArray
Génération 2, version 2:
Identification du véhicule plus les métadonnées telles qu’utilisées dans le protocole de téléchargement.
|
VehicleRegistrationIdentificationRecordArray ::= SEQUENCE {
recordTypeRecordType,
recordSizeINTEGER(1..65535),
noOfRecordsINTEGER(0..65535),
recordsSET SIZE(noOfRecords) OF VehicleRegistrationIdentification
}
|
recordType indique le type de relevé (VehicleRegistrationIdentification). 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.»;
(dd)au point 2.168, la première ligne qui suit l’en-tête est remplacée par le texte suivant:
«Génération 2, version 1:»;
(ee)le point 2.174 est modifié comme suit:
i)l’en-tête de la génération 2 est remplacé par le texte suivant:
«Génération 2, version 1:»;
ii)le texte suivant est inséré:
«Génération 2, version 2:
|
VuCalibrationRecord ::= SEQUENCE {
calibrationPurposeCalibrationPurpose,
workshopNameName,
workshopAddressAddress,
workshopCardNumberFullCardNumber,
workshopCardExpiryDateTimeReal,
vehicleIdentificationNumberVehicleIdentificationNumber,
vehicleRegistrationIdentificationVehicleRegistrationIdentification,
wVehicleCharacteristicConstantW-VehicleCharacteristicConstant,
kConstantOfRecordingEquipmentK-ConstantOfRecordingEquipment,
lTyreCircumferenceL-TyreCircumference,
tyreSizeTyreSize,
authorisedSpeedSpeedAuthorised,
oldOdometerValueCompteur kilométrique
newOdometerValueCompteur kilométrique
oldTimeValueTimeReal,
newTimeValueTimeReal,
nextCalibrationDateTimeReal,
sensorSerialNumberSensorSerialNumber,
sensorGNSSSerialNumberSensorGNSSSerialNumber,
rcmSerialNumberRemoteCommunicationModuleSerialNumber,
sealDataVuSealDataVu,
byDefaultLoadTypeLoadType,
calibrationCountryNationNumeric,
calibrationCountryTimestampTimeReal
}
|
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éhicule à 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’étalonnage a été fournie par le récepteur GNSS.»;
(ff)le point 2.185 bis suivant est inséré:
«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.
|
VuConfigurationLengthRange ::= INTEGER(0..216-1)
|
Attribution de valeur: cf. appendice 2.»;
(gg)le point 2.192 bis suivant est inséré:
«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).
|
VuDigitalMapVersion ::= IA5String(SIZE(12))
|
Attribution de valeur: comme indiqué sur le site web sécurisé prévu à cet effet et mis à disposition par la Commission européenne (exigence 133 duodecies de l’annexe IC).»;
(hh)le point 2.203 est modifié comme suit:
i)l’en-tête se rapportant à la génération 2 est remplacé par le texte suivant:
«Génération 2, version 1:»;
ii)le texte suivant est inséré:
«Génération 2, version 2:
Informations enregistrées dans la mémoire d’une unité embarquée sur véhicule relatives à la position GNSS du véhicule lorsque le temps de conduite accumulé atteint un multiple de trois heures (exigences 108 et 110 de l’annexe IC).
|
VuGNSSADRecord ::= SEQUENCE {
timestamp
TimeReal,
cardNumberAndGenDriverSlot
FullCardNumberAndGeneration,
cardNumberAndGenCodriverSlot
FullCardNumberAndGeneration,
gnssPlaceAuthRecord
GNSSPlaceAuthRecord,
vehicleOdometerValue
OdometerShort
}
|
Dans la version 2 de la génération 2, au lieu de gnssPlaceRecord, gnssPlaceAuthRecord est utilisé, ce dernier contenant également le statut d’authentification GNSS.»;
(ii)les points 2.203 bis et 2.203 ter suivants sont insérés:
«2.203 bis
VuBorderCrossingRecord
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 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).
|
VuBorderCrossingRecord ::= SEQUENCE {
cardNumberAndGenDriverSlotFullCardNumberAndGeneration,
cardNumberAndGenCodriverSlotFullCardNumberAndGeneration,
countryLeftNationNumeric,
countryEnteredNationNumeric,
gnssPlaceAuthRecordGNSSPlaceAuthRecord,
vehicleOdometerValueOdometerShort
}
|
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 franchissement 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é embarquée sur véhicule et se rapportant aux passages aux frontières du véhicule (exigence 133 quater de l’annexe IC).
|
VuBorderCrossingRecordArray ::= SEQUENCE {
recordTypeRecordType,
recordSizeINTEGER(1..65535),
noOfRecordsINTEGER(0..65535),
recordsSET SIZE(noOfRecords) OF VuBorderCrossingRecord
}
|
recordType indique le type de relevé (VuBorderCrossingRecord). 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.»;
(jj)le point 2.204 bis suivant est inséré:
«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.
|
VuGnssMaximalTimeDifference ::= INTEGER(0..65535)
|
»;
(kk)au point 2.205, le texte se rapportant à la génération 2 est remplacé par le texte suivant:
«Génération 2:
|
VuIdentification ::= SEQUENCE {
vuManufacturerName Nom du fabricant de la VUVuManufacturerName,
vuManufacturerAddressVuManufacturerAddress,
vuPartNumberVuPartNumber,
vuSerialNumberVuSerialNumber,
vuSoftwareIdentificationVuSoftwareIdentification,
vuManufacturingDateVuManufacturingDate,
vuApprovalNumberVuApprovalNumber,
vuGenerationGeneration,
vuAbilityVuAbility,
vuDigitalMapVersionVuDigitalMapVersion
}
|
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 uniquement dans la version 2).»;
(ll)les points 2.208 bis et 2.208 ter suivants sont insérés:
«2.208 bis
VuLoadUnloadRecord
Génération 2, version 2:
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).
|
VuLoadUnloadRecord ::= SEQUENCE {
timeStampTimeReal,
operationTypeOperationType
cardNumberAndGenDriverSlotFullCardNumberAndGeneration,
cardNumberAndGenCodriverSlotFullCardNumberAndGeneration,
gnssPlaceAuthRecordGNSSPlaceAuthRecord,
vehicleOdometerValueOdometerShort
}
|
timeStamp est la date et l’heure auxquelles l’opération de chargement/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é embarquée sur véhicule et se rapportant à une opération de chargement/déchargement saisie (exigence 133 nonies de l’annexe IC).
|
VuLoadUnloadRecordArray ::= SEQUENCE {
recordTypeRecordType,
recordSizeINTEGER(1..65535),
noOfRecordsINTEGER(0..65535),
recordsSET SIZE(noOfRecords) OF VuLoadUnloadRecord
}
|
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.»;
(mm)le point 2.219 est modifié comme suit:
i)l’en-tête de la génération 2 est remplacé par le texte suivant:
«Génération 2, version 1:»;
ii)le texte suivant est inséré:
«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).
|
VuPlaceDailyWorkPeriodRecord ::= SEQUENCE {
fullCardNumberAndGeneration
FullCardNumberAndGeneration,
placeAuthRecord
PlaceAuthRecord
}
|
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.»;
(nn)le point suivant est inséré après le point 2.222:
«2.222 bis
VuRtcTime
Génération 2, version 2:
L’heure de la RTC de la VU, transmise par la VU à un dispositif GNSS externe, voir exigence GNS_3 septies de l’appendice 12.
»;
(oo)les points 2.234 bis, 2.234 ter et 2.234 quater suivants sont insérés:
«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).
|
WorkshopCardApplicationIdentificationV2 ::= SEQUENCE {
lengthOfFollowingDataLengthOfFollowingData,
noOfBorderCrossingRecordsNoOfBorderCrossingRecords,
noOfLoadUnloadRecordsNoOfLoadUnloadRecords,
noOfLoadTypeEntryRecordsNoOfLoadTypeEntryRecords,
vuConfigurationLengthRangeVuConfigurationLengthRange
}
|
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émoriser.
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).
|
WorkshopCardCalibrationAddData ::= SEQUENCE {
calibrationPointerNewestRecordINTEGER(0..NoOfCalibrationRecords -1),
workshopCardCalibrationAddDataRecordsSET SIZE(NoOfCalibrationRecords) OF WorkshopCardCalibrationAddDataRecord
}
|
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 considé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).
|
WorkshopCardCalibrationAddDataRecord ::= SEQUENCE {
oldTimeValueTimeReal,
vehicleIdentificationNumberVehicleIdentificationNumber,
byDefaultLoadTypeLoadType,
calibrationCountryNationNumeric,
calibrationCountryTimestampTimeReal
}
|
oldTimeValue désigne les anciennes valeurs de date et d’heure contenues dans le WorkshopCardCalibrationRecord correspondant,
vehicleIdentificationNumber indique le numéro d’identification du véhicule, également contenu dans le WorkshopCardCalibrationRecord 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’étalonnage a été fournie par le récepteur GNSS.»;
(31)l’appendice 2 est modifié comme suit:
(a)au point 2.5, le deuxième alinéa du paragraphe TCS_09 est remplacé par le texte suivant:
«État d’exploitation lors de l’exécution de commandes ou en interfaçage avec une unité embarquée sur véhicule,»;
(b)le point 3 est modifié comme suit:
i)au point 3.2.1, le quatrième tiret du paragraphe TCS_16 est supprimé.
ii)le point 3.5.7.2 est modifié comme suit:
1)
le paragraphe TCS_86 est remplacé par le texte suivant:
«TCS_86
La commande est exécutable dans le MF, DF Tachograph et DF Tachograph_G2, voir également TCS_34.»;
2)
les paragraphes TCS_88 et TCS_89 sont remplacés par le texte suivant:
«TCS_88
Pour les APDU courtes, les dispositions suivantes s’appliquent: 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’appliquent: si le certificat ne s’insère pas dans une seule APDU, la carte doit prendre en charge une chaîne de commandes. L’IFD doit utiliser le moins d’APDU possible pour transmettre la charge de la commande et transmettre le maximum d’octets dans la première APDU de commande. Si 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.»;
iii)au point 3.5.10, la dernière ligne du tableau du paragraphe TCS_101 est remplacée par le texte suivant:
«
|
Le
|
1
|
‘00h’
|
Conformément à la norme ISO/IEC 7816-4
|
»;
iv)au point 3.5.16, la dernière ligne du tableau du paragraphe TCS_138 est remplacée par le texte suivant:
«
|
Le
|
1
|
‘00h’
|
Conformément à la norme ISO/IEC 7816-4
|
»;
(c)le point 4 est modifié comme suit:
i)au paragraphe TCS_141, le deuxième alinéa est remplacé par le texte suivant:
«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.»;
ii)au point 4.2.1, le tableau du paragraphe TCS_150 est modifié comme suit:
1)la ligne correspondant à cardIssuingAuthorityName est remplacée par le texte suivant:
«
|
|
|
|
|
|
|
|
cardIssuingAuthorityName
|
|
36
|
36
|
{00,20..20}
|
»;
2)la ligne correspondant à LastCardDownload est remplacée par le texte suivant:
«
|
|
|
|
|
|
|
LastCardDownload
|
|
4
|
4
|
{00..00}
|
»;
iii)le point 4.2.2 est modifié comme suit:
1)le paragraphe TCS_152 est remplacé par le texte suivant:
«TCS_152
Après personnalisation, l’application de la carte de conducteur 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_Authentication, 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_Identification 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.
|
|
|
Règles d’accès
|
|
Fichier
|
ID fichier
|
SFID
|
Lire/Sélect.
|
Mettre à jour
|
|
|
|
DF
|
Tachograph_G2
|
|
|
SC1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Application_Identification
|
‘0501h’
|
1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
CardMA_Certificate
|
‘C100h’
|
2
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
CardSignCertificate
|
‘C101h’
|
3
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
CA_Certificate
|
‘C108h’
|
4
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Link_Certificate
|
‘C109h’
|
5
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Identification
|
‘0520h’
|
6
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Card_Download
|
‘050Eh’
|
7
|
SC1
|
SC1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Driving_Licence_Info
|
‘0521h’
|
10
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Events_Data
|
‘0502h’
|
12
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Faults_Data
|
‘0503h’
|
13
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Driver_Activity_Data
|
‘0504h’
|
14
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Vehicles_Used
|
‘0505h’
|
15
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Places
|
‘0506h’
|
16
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Current_Usage
|
‘0507h’
|
17
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Control_Activity_Data
|
‘0508h’
|
18
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Specific_Conditions
|
‘0522h’
|
19
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
VehicleUnits_Used
|
‘0523h’
|
20
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
GNSS_Places
|
‘0524h’
|
21
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Application_Identification_V2
|
‘0525h’
|
22
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Places_Authentication
|
‘0526h’
|
23
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF GNSS_Places_Authentication
|
‘0527h’
|
24
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Border_Crossings
|
‘0528h’
|
25
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Load_Unload_Operations
|
‘0529h’
|
26
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Load_Type_Entries
|
‘0530h’
|
27
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Vu_Configuration
|
‘0540h’
|
30
|
SC5/SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
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»;
2)le paragraphe TCS_154 est remplacé par le texte suivant:
«TCS_154
L’application de la carte de conducteur de génération 2 doit avoir la structure de données suivante:
|
Fichier/Élément de données
|
|
|
|
|
Nombre de relevés
|
Taille (octets)
Min Max
|
Valeurs par défaut
|
|
DF Tachograph_G2
|
|
|
|
|
|
98300
|
98848
|
|
|
|
EF Application_Identification
|
|
|
17
|
17
|
|
|
|
|
DriverCardApplicationIdentification
|
|
17
|
17
|
|
|
|
|
|
typeOfTachographCardId
|
|
|
1
|
1
|
{00}
|
|
|
|
|
cardStructureVersion
|
|
|
2
|
2
|
{01 01}
|
|
|
|
|
noOfEventsPerType
|
|
|
1
|
1
|
{00}
|
|
|
|
|
noOfFaultsPerType
|
|
|
1
|
1
|
{00}
|
|
|
|
|
activityStructureLength
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCardVehicleRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCardPlaceRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfGNSSADRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfSpecificConditionRecords
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCardVehicleUnitRecords
|
|
2
|
2
|
{00 00}
|
|
|
EF CardMA_Certificate
|
|
|
|
204
|
341
|
|
|
|
|
CardMA_Certificate
|
|
|
|
204
|
341
|
{00..00}
|
|
|
EF CardSignCertificate
|
|
|
|
204
|
341
|
|
|
|
|
CardSignCertificate
|
|
|
|
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 Identification
|
|
|
|
|
143
|
143
|
|
|
|
|
CardIdentification
|
|
|
|
65
|
65
|
|
|
|
|
|
cardIssuingMemberState
|
|
|
1
|
1
|
{00}
|
|
|
|
|
cardNumber
|
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
cardIssuingAuthorityName
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardIssueDate
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardValidityBegin
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardExpiryDate
|
|
|
4
|
4
|
{00..00}
|
|
|
|
DriverCardHolderIdentification
|
|
|
78
|
78
|
|
|
|
|
|
cardHolderName
|
|
|
72
|
72
|
|
|
|
|
|
|
holderSurname
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
|
holderFirstNames
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardHolderBirthDate
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardHolderPreferredLanguage
|
|
2
|
2
|
{20 20}
|
|
|
EF Card_Download
|
|
|
|
|
4
|
4
|
|
|
|
|
|
LastCardDownload
|
|
|
4
|
4
|
{00..00}
|
|
|
EF Driving_Licence_Info
|
|
|
|
53
|
53
|
|
|
|
|
|
CardDrivingLicenceInformation
|
|
53
|
53
|
|
|
|
|
|
|
drivingLicenceIssuingAuthority
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
|
drivingLicenceIssuingNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
drivingLicenceNumber
|
|
|
16
|
16
|
{20..20}
|
|
|
EF Events_Data
|
|
|
|
|
3168
|
3168
|
|
|
|
|
CardEventData
|
|
|
|
|
3168
|
3168
|
|
|
|
|
|
cardEventRecords
|
|
11
|
288
|
288
|
|
|
|
|
|
|
CardEventRecord
|
|
n1
|
24
|
24
|
|
|
|
|
|
|
|
eventType
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
eventBeginTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
eventEndTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
eventVehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
EF Faults_Data
|
|
|
|
|
1152
|
1152
|
|
|
|
|
CardFaultData
|
|
|
|
|
1152
|
1152
|
|
|
|
|
|
cardFaultRecords
|
|
2
|
576
|
576
|
|
|
|
|
|
|
CardFaultRecord
|
|
n2
|
24
|
24
|
|
|
|
|
|
|
|
faultType
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
faultBeginTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
faultEndTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
faultVehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
EF Driver_Activity_Data
|
|
|
|
13780
|
13780
|
|
|
|
|
CardDriverActivity
|
|
|
|
13780
|
13780
|
|
|
|
|
|
activityPointerOldestDayRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
activityPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
activityDailyRecords
|
|
n6
|
13776
|
13776
|
{00..00}
|
|
|
EF Vehicles_Used
|
|
|
|
|
9602
|
9602
|
|
|
|
|
CardVehiclesUsed
|
|
|
|
9602
|
9602
|
|
|
|
|
|
vehiclePointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardVehicleRecords
|
|
|
9600
|
9600
|
|
|
|
|
|
|
cardVehicleRecord
|
|
n3
|
48
|
48
|
|
|
|
|
|
|
|
vehicleOdometerBegin
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
vehicleOdometerEnd
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
vehicleFirstUse
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
vehicleLastUse
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
vehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
|
|
vuDataBlockCounter
|
|
2
|
2
|
{00 00}
|
|
|
|
|
|
|
vehicleIdentificationNumber
|
|
17
|
17
|
{20..20}
|
|
|
EF Places
|
|
|
|
|
|
2354
|
2354
|
|
|
|
|
CardPlaceDailyWorkPeriod
|
|
|
2354
|
2354
|
|
|
|
|
|
placePointerNewestRecord
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
placeRecords
|
|
|
|
2352
|
2352
|
|
|
|
|
|
|
PlaceRecord
|
|
n4
|
21
|
21
|
|
|
|
|
|
|
|
entryTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
entryTypeDailyWorkPeriod
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
dailyWorkPeriodCountry
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
dailyWorkPeriodRegion
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
entryGNSSPlaceRecord
|
|
11
|
11
|
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
EF Current_Usage
|
|
|
|
|
19
|
19
|
|
|
|
|
CardCurrentUse
|
|
|
|
|
19
|
19
|
|
|
|
|
|
sessionOpenTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
sessionOpenVehicle
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
EF Control_Activity_Data
|
|
|
|
46
|
46
|
|
|
|
|
CardControlActivityDataRecord
|
|
|
46
|
46
|
|
|
|
|
|
controlType
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
controlTime
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
controlCardNumber
|
|
|
|
|
|
|
|
|
|
|
cardType
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
cardIssuingMemberState
|
|
1
|
1
|
{00}
|
|
|
|
|
|
cardNumber
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
controlVehicleRegistration
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
controlDownloadPeriodBegin
|
|
4
|
4
|
{00..00}
|
|
|
|
|
controlDownloadPeriodEnd
|
|
|
4
|
4
|
{00..00}
|
|
|
EF Specific_Conditions
|
|
|
|
562
|
562
|
|
|
|
|
SpecificConditions
|
|
|
|
562
|
562
|
|
|
|
|
|
conditionPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
specificConditionRecords
|
|
|
560
|
560
|
|
|
|
|
|
|
SpecificConditionRecord
|
n9
|
5
|
5
|
|
|
|
|
|
|
|
entryTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
specificConditionType
|
|
1
|
1
|
{00}
|
|
|
EF VehicleUnits_Used
|
|
|
|
2002
|
2002
|
|
|
|
|
CardVehicleUnitsUsed
|
|
|
2002
|
2002
|
|
|
|
|
|
vehicleUnitPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardVehicleUnitRecords
|
|
|
2000
|
2000
|
|
|
|
|
|
|
CardVehicleUnitRecord
|
n7
|
10
|
10
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
manufacturerCode
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
deviceID
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vuSoftwareVersion
|
|
4
|
4
|
{00..00}
|
|
|
EF GNSS_Places
|
|
|
|
|
6050
|
6050
|
|
|
|
|
GNSSAccumulatedDriving
|
|
|
6050
|
6050
|
|
|
|
|
|
gnssADPointerNewestRecord
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
gnssAccumulatedDrivingRecords
|
|
6048
|
6048
|
|
|
|
|
|
|
GNSSAccumulatedDrivingRecord
|
n8
|
18
|
18
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
gnssPlaceRecord
|
|
|
14
|
14
|
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
EF Application_Identification_V2
|
|
|
10
|
10
|
|
|
|
|
DriverCardApplicationIdentificationV2
|
|
10
|
10
|
|
|
|
|
|
lengthOfFollowingData
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfBorderCrossingRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfLoadUnloadRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfLoadTypeEntryRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
VuConfigurationLengthRange
|
|
|
2
|
2
|
{00 00}
|
|
|
EF Places_Authentication
|
|
|
562
|
562
|
|
|
|
|
CardPlaceAuthDailyWorkPeriod
|
|
562
|
562
|
|
|
|
|
|
placeAuthPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
placeAuthStatusRecords
|
|
|
560
|
560
|
|
|
|
|
|
|
PlaceAuthStatusRecord
|
n4
|
5
|
5
|
|
|
|
|
|
|
|
entryTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
EF GNSS_Places_Authentication
|
|
|
1682
|
1682
|
|
|
|
|
GNSSAuthAccumulatedDriving
|
|
|
1682
|
1682
|
|
|
|
|
|
gnssAuthADPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
gnssAuthStatusADRecords
|
|
1680
|
1680
|
|
|
|
|
|
|
GNSSAuthStatusADRecord
|
n8
|
5
|
5
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
EF Border_Crossings
|
|
|
|
19042
|
19042
|
|
|
|
|
CardBorderCrossings
|
|
|
|
19042
|
19042
|
|
|
|
|
|
borderCrossingPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardBorderCrossingRecords
|
|
|
19040
|
19040
|
|
|
|
|
|
|
CardBorderCrossingRecord
|
n10
|
17
|
17
|
|
|
|
|
|
|
|
countryLeft
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
countryEntered
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
gnssPlaceAuthRecord
|
|
12
|
12
|
|
|
|
|
|
|
|
|
timeStamp
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
EF Load_Unload_Operations
|
|
|
32482
|
32482
|
|
|
|
|
CardLoadUnloadOperations
|
|
|
32482
|
32482
|
|
|
|
|
|
loadUnloadPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardloadUnloadRecords
|
|
|
32480
|
32480
|
|
|
|
|
|
|
CardLoadUnloadRecord
|
|
n11
|
20
|
20
|
|
|
|
|
|
|
|
timestamp
|
|
|
4
|
4
|
{00}
|
|
|
|
|
|
|
operationType
|
|
|
1
|
1
|
{00..00}
|
|
|
|
|
|
|
gnssPlaceAuthRecord
|
|
12
|
12
|
|
|
|
|
|
|
|
|
timeStamp
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
EF Load_Type_Entries
|
|
|
1682
|
1682
|
|
|
|
|
CardLoadTypeEntries
|
|
|
1682
|
1682
|
|
|
|
|
|
loadtypeEntryPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardLoadTypeEntryRecords
|
|
1680
|
1680
|
|
|
|
|
|
|
CardLoadTypeEntryRecord
|
n12
|
5
|
5
|
|
|
|
|
|
|
|
timestamp
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
loadTypeEntered
|
|
|
1
|
1
|
{00}
|
|
|
EF VU_Configuration
|
|
|
3072
|
3072
|
|
|
|
|
VuConfigurations
|
|
n13
|
3072
|
3072
|
|
»;
3)au paragraphe TCS_155, le tableau est remplacé par le tableau suivant:
«
|
|
|
Min
|
Max
|
|
n1
|
|
|
12
|
|
n2
|
NoOfFaultsPerType
|
24
|
24
|
|
n3
|
NoOfCardVehicleRecords
|
200
|
200
|
|
n4
|
NoOfCardPlaceRecords
|
112
|
112
|
|
n6
|
CardActivityLengthRange
|
13776 octets
(56 jours * 117 modifications d’activité)
|
13776 octets
(56 jours * 117 modifications d’activité)
|
|
n7
|
NoOfCardVehicleUnitRecords
|
200
|
200
|
|
n8
|
NoOfGNSSADRecords
|
336
|
336
|
|
n9
|
NoOfSpecificConditionRecords
|
112
|
112
|
|
n10
|
NoOfBorderCrossingRecords
|
1120
|
1120
|
|
n11
|
NoOfLoadUnloadRecords
|
1624
|
1624
|
|
n12
|
NoOfLoadTypeEntryRecords
|
336
|
336
|
|
n13
|
VuConfigurationLengthRange
|
3072 octets
|
3072 octets
|
»;
iv)le point 4.3.2 est modifié comme suit:
1)le paragraphe TCS_160 est remplacé par le texte suivant:
«TCS_160
Après personnalisation, l’application de la carte d’atelier de génération 2 doit avoir la structure de fichier et les conditions d’accès au fichier permanentes suivantes.
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_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF Load_Type_Entries, EF VU_Configuration et Calibration_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_Identification 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.
|
|
|
|
Règles d’accès
|
|
Fichier
|
ID fichier
|
SFID
|
Lire
|
Sélectionner
|
Mettre à jour
|
|
|
|
DF Tachograph_G2
|
|
|
SC1
|
SC1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Application_Identification
|
‘0501h’
|
1
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CardMA_Certificate
|
‘C100h’
|
2
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CardSignCertificate
|
‘C101h’
|
3
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CA_Certificate
|
‘C108h’
|
4
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Link_Certificate
|
‘C109h’
|
5
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Identification
|
‘0520h’
|
6
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Card_Download
|
‘0509h’
|
7
|
SC1
|
SC1
|
SC1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Calibration
|
‘050Ah’
|
10
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Sensor_Installation_Data
|
‘050Bh’
|
11
|
SC5
|
SM-MAC-G2
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Events_Data
|
‘0502h’
|
12
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Faults_Data
|
‘0503h’
|
13
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Driver_Activity_Data
|
‘0504h’
|
14
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Vehicles_Used
|
‘0505h’
|
15
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Places
|
‘0506h’
|
16
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Current_Usage
|
‘0507h’
|
17
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Control_Activity_Data
|
‘0508h’
|
18
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Specific_Conditions
|
‘0522h’
|
19
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF VehicleUnits_Used
|
‘0523h’
|
20
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF GNSS_Places
|
‘0524h’
|
21
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Application_Identification_V2
|
‘0525h’
|
22
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Places_Authentication
|
‘0526h’
|
23
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF GNSS_Places_Authentication
|
‘0527h’
|
24
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Border_Crossings
|
‘0528h’
|
25
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Load_Unload_Operations
|
‘0529h’
|
26
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Load_Type_Entries
|
‘0530h’
|
27
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Calibration_Add_Data
|
‘0531h’
|
28
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF VU_Configuration
|
‘0540h’
|
30
|
SC5
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
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»;
2)au paragraphe TCS_162, le tableau est remplacé par le tableau suivant:
«
|
Fichier/Élément de données
|
|
|
|
|
|
Nombre de relevés
|
Taille (octets)
Min Max
|
Valeurs par défaut
|
|
DF Tachograph_G2
|
|
|
|
|
|
|
59582
|
60214
|
|
|
|
EF Application_Identification
|
|
|
|
19
|
19
|
|
|
|
|
WorkshopCardApplicationIdentification
|
|
19
|
19
|
|
|
|
|
|
typeOfTachographCardId
|
|
|
1
|
1
|
{00}
|
|
|
|
|
cardStructureVersion
|
|
|
|
2
|
2
|
{01 01}
|
|
|
|
|
noOfEventsPerType
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
noOfFaultsPerType
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
activityStructureLength
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCardVehicleRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCardPlaceRecords
|
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCalibrationRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfGNSSADRecords
|
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfSpecificConditionRecords
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCardVehicleUnitRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
EF CardMA_Certificate
|
|
|
|
|
204
|
341
|
|
|
|
|
CardMA_Certificate
|
|
|
|
|
204
|
341
|
{00..00}
|
|
|
EF CardSignCertificate
|
|
|
|
|
204
|
341
|
|
|
|
|
CardSignCertificate
|
|
|
|
|
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 Identification
|
|
|
|
|
|
211
|
211
|
|
|
|
|
CardIdentification
|
|
|
|
|
65
|
65
|
|
|
|
|
|
cardIssuingMemberState
|
|
|
1
|
1
|
{00}
|
|
|
|
|
cardNumber
|
|
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
cardIssuingAuthorityName
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardIssueDate
|
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardValidityBegin
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardExpiryDate
|
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
WorkshopCardHolderIdentification
|
|
146
|
146
|
|
|
|
|
|
workshopName
|
|
|
|
|
36
|
36
|
|
|
|
|
|
workshopAddress
|
|
|
|
36
|
36
|
|
|
|
|
|
cardHolderName
|
|
|
|
|
72
|
72
|
|
|
|
|
|
|
holderSurname
|
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
|
holderFirstNames
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardHolderPreferredLanguage
|
|
2
|
2
|
{20 20}
|
|
|
EF Card_Download
|
|
|
|
|
|
2
|
2
|
|
|
|
|
NoOfCardPlaceRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
EF Calibration
|
|
|
|
|
|
45394
|
45394
|
|
|
|
|
WorkshopCardCalibrationData
|
|
|
45394
|
45394
|
|
|
|
|
|
calibrationTotalNumber
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
calibrationPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
calibrationRecords
|
|
|
|
45390
|
45390
|
|
|
|
|
|
|
WorkshopCardCalibrationRecord
|
n5
|
178
|
178
|
|
|
|
|
|
|
|
calibrationPurpose
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleIdentificationNumber
|
|
17
|
17
|
{20..20}
|
|
|
|
|
|
|
vehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
|
|
wVehicleCharacteristicConstant
|
|
2
|
2
|
{00 00}
|
|
|
|
|
|
|
kConstantOfRecordingEquipment
|
|
2
|
2
|
{00 00}
|
|
|
|
|
|
|
lTyreCircumference
|
|
2
|
2
|
{00 00}
|
|
|
|
|
|
|
tyreSize
|
|
|
|
15
|
15
|
{20..20}
|
|
|
|
|
|
|
authorisedSpeed
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
oldOdometerValue
|
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
newOdometerValue
|
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
oldTimeValue
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
newTimeValue
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
nextCalibrationDate
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
vuPartNumber
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
|
|
vuSerialNumber
|
|
|
8
|
8
|
{00..00}
|
|
|
|
|
|
|
sensorSerialNumber
|
|
8
|
8
|
{00..00}
|
|
|
|
|
|
|
sensorGNSSSerialNumber
|
|
8
|
8
|
{00..00}
|
|
|
|
|
|
|
rcmSerialNumber
|
|
|
8
|
8
|
{00..00}
|
|
|
|
|
|
|
vuAbility
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
sealDataCard
|
|
|
56
|
56
|
|
|
|
|
|
|
|
|
noOfSealRecords
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
SealRecords
|
|
55
|
55
|
|
|
|
|
|
|
|
|
|
SealRecord
|
5
|
11
|
11
|
|
|
|
|
|
|
|
|
|
|
equipmentType
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
|
|
extendedSealIdentifier
|
10
|
10
|
{00..00}
|
|
|
EF Sensor_Installation_Data
|
|
|
|
18
|
102
|
|
|
|
|
SensorInstallationSecData
|
|
|
|
18
|
102
|
{00..00}
|
|
|
EF Events_Data
|
|
|
|
|
|
792
|
792
|
|
|
|
|
CardEventData
|
|
|
|
|
|
792
|
792
|
|
|
|
|
|
cardEventRecords
|
|
|
11
|
72
|
72
|
|
|
|
|
|
|
CardEventRecord
|
|
|
n1
|
24
|
24
|
|
|
|
|
|
|
|
eventType
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
eventBeginTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
eventEndTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
eventVehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
EF Faults_Data
|
|
|
|
|
|
288
|
288
|
|
|
|
|
CardFaultData
|
|
|
|
|
|
288
|
288
|
|
|
|
|
|
cardFaultRecords
|
|
|
2
|
144
|
144
|
|
|
|
|
|
|
CardFaultRecord
|
|
|
n2
|
24
|
24
|
|
|
|
|
|
|
|
faultType
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
faultBeginTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
faultEndTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
faultVehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
EF Driver_Activity_Data
|
|
|
|
|
496
|
496
|
|
|
|
|
CardDriverActivity
|
|
|
|
|
496
|
496
|
|
|
|
|
|
activityPointerOldestDayRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
activityPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
activityDailyRecords
|
|
|
n6
|
492
|
492
|
{00..00}
|
|
|
EF Vehicles_Used
|
|
|
|
|
|
386
|
386
|
|
|
|
|
CardVehiclesUsed
|
|
|
|
|
386
|
386
|
|
|
|
|
|
vehiclePointerNewestRecord
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardVehicleRecords
|
|
|
|
384
|
384
|
|
|
|
|
|
|
cardVehicleRecord
|
|
n3
|
48
|
48
|
|
|
|
|
|
|
|
vehicleOdometerBegin
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
vehicleOdometerEnd
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
vehicleFirstUse
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
vehicleLastUse
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
vehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
|
|
vuDataBlockCounter
|
|
2
|
2
|
{00 00}
|
|
|
|
|
|
|
vehicleIdentificationNumber
|
|
17
|
17
|
{20..20}
|
|
|
EF Places
|
|
|
|
|
|
|
170
|
170
|
|
|
|
|
CardPlaceDailyWorkPeriod
|
|
|
|
170
|
170
|
|
|
|
|
|
placePointerNewestRecord
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
placeRecords
|
|
|
|
|
168
|
168
|
|
|
|
|
|
|
PlaceRecord
|
|
|
n4
|
21
|
21
|
|
|
|
|
|
|
|
entryTime
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
entryTypeDailyWorkPeriod
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
dailyWorkPeriodCountry
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
dailyWorkPeriodRegion
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
entryGNSSPlaceRecord
|
|
11
|
11
|
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
EF Current_Usage
|
|
|
|
|
|
19
|
19
|
|
|
|
|
CardCurrentUse
|
|
|
|
|
|
19
|
19
|
|
|
|
|
|
sessionOpenTime
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
sessionOpenVehicle
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
EF Control_Activity_Data
|
|
|
|
|
46
|
46
|
|
|
|
|
CardControlActivityDataRecord
|
|
|
46
|
46
|
|
|
|
|
|
controlType
|
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
controlTime
|
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
controlCardNumber
|
|
|
|
|
|
|
|
|
|
|
|
cardType
|
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
cardIssuingMemberState
|
|
1
|
1
|
{00}
|
|
|
|
|
|
cardNumber
|
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
controlVehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
controlDownloadPeriodBegin
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
controlDownloadPeriodEnd
|
|
|
4
|
4
|
{00..00}
|
|
|
EF VehicleUnits_Used
|
|
|
|
|
82
|
82
|
|
|
|
|
CardVehicleUnitsUsed
|
|
|
|
82
|
82
|
|
|
|
|
|
vehicleUnitPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardVehicleUnitRecords
|
|
|
80
|
80
|
|
|
|
|
|
|
CardVehicleUnitRecord
|
n7
|
10
|
10
|
|
|
|
|
|
|
|
timeStamp
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
manufacturerCode
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
deviceID
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vuSoftwareVersion
|
|
4
|
4
|
{00..00}
|
|
|
EF GNSS_Places
|
|
|
|
|
|
434
|
434
|
|
|
|
|
GNSSAccumulatedDriving
|
|
|
|
434
|
434
|
|
|
|
|
|
gnssADPointerNewestRecord
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
gnssAccumulatedDrivingRecords
|
|
432
|
432
|
|
|
|
|
|
|
GNSSAccumulatedDrivingRecord
|
n8
|
18
|
18
|
|
|
|
|
|
|
|
timeStamp
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
gnssPlaceRecord
|
|
|
14
|
14
|
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
EF Specific_Conditions
|
|
|
|
|
22
|
22
|
|
|
|
|
SpecificConditions
|
|
|
|
|
22
|
22
|
|
|
|
|
|
conditionPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
specificConditionRecords
|
|
|
20
|
20
|
|
|
|
|
|
|
SpecificConditionRecord
|
n9
|
5
|
5
|
|
|
|
|
|
|
|
entryTime
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
specificConditionType
|
|
1
|
1
|
{00}
|
|
|
EF Application_Identification_V2
|
|
|
10
|
10
|
|
|
|
|
WorkshopCardApplicationIdentificationV2
|
|
10
|
10
|
|
|
|
|
|
LengthOfFollowingData
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfBorderCrossingRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfLoadUnloadRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfLoadTypeEntryRecords
|
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
VuConfigurationLengthRange
|
|
|
|
2
|
2
|
{00 00}
|
|
|
EF Places_Authentication
|
|
|
|
42
|
42
|
|
|
|
|
CardPlaceAuthDailyWorkPeriod
|
|
|
42
|
42
|
|
|
|
|
|
placeAuthPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
placeAuthStatusRecords
|
|
|
|
40
|
40
|
|
|
|
|
|
|
|
PlaceAuthStatusRecord
|
n4
|
5
|
5
|
|
|
|
|
|
|
|
entryTime
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
EF GNSS_Places_Authentication
|
|
|
122
|
122
|
|
|
|
|
GNSSAuthAccumulatedDriving
|
|
|
122
|
122
|
|
|
|
|
|
gnssAuthADPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
gnssAuthStatusADRecords
|
|
120
|
120
|
|
|
|
|
|
|
GNSSAuthStatusADRecord
|
n8
|
5
|
5
|
|
|
|
|
|
|
|
timeStamp
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
EF Border_Crossings
|
|
|
|
|
70
|
70
|
|
|
|
|
CardBorderCrossings
|
|
|
|
|
70
|
70
|
|
|
|
|
|
borderCrossingPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardBorderCrossingRecords
|
|
|
68
|
68
|
|
|
|
|
|
|
CardBorderCrossingRecord
|
n10
|
17
|
17
|
|
|
|
|
|
|
|
countryLeft
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
countryEntered
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
gnssPlaceAuthRecord
|
|
12
|
12
|
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
EF Load_Unload_Operations
|
|
|
|
162
|
162
|
|
|
|
|
CardLoadUnloadOperations
|
|
|
|
162
|
162
|
|
|
|
|
|
loadUnloadPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardloadUnloadRecords
|
|
|
|
160
|
160
|
|
|
|
|
|
|
CardLoadUnloadRecord
|
|
n11
|
20
|
20
|
|
|
|
|
|
|
|
timestamp
|
|
|
4
|
4
|
{00}
|
|
|
|
|
|
|
operationType
|
|
|
1
|
1
|
{00..00}
|
|
|
|
|
|
|
gnssPlaceAuthRecord
|
|
12
|
12
|
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
EF Load_Type_Entries
|
|
|
|
22
|
22
|
|
|
|
|
CardLoadTypeEntries
|
|
|
|
22
|
22
|
|
|
|
|
|
loadtypeEntryPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardLoadTypeEntryRecords
|
|
20
|
20
|
|
|
|
|
|
|
CardLoadTypeEntryRecord
|
n12
|
5
|
5
|
|
|
|
|
|
|
|
timestamp
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
loadTypeEntered
|
|
1
|
1
|
{00}
|
|
|
EF Calibration_Add_Data
|
|
|
|
6887
|
6887
|
|
|
|
|
WorkshopCardCalibrationAddData
|
|
|
6887
|
6887
|
|
|
|
|
|
calibrationPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
workshopCardCalibrationAddDataRecords
|
|
|
6885
|
6885
|
|
|
|
|
|
|
WorkshopCardCalibrationAddDataRecord
|
n5
|
27
|
27
|
|
|
|
|
|
|
|
oldTimeValue
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
vehicleIdentificationNumber
|
|
17
|
17
|
{20..20}
|
|
|
|
|
|
|
byDefaultLoadType
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
calibrationCountry
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
calibrationCountryTimestamp
|
|
4
|
4
|
{00..00}
|
|
|
EF VU_Configuration
|
|
|
3072
|
3072
|
|
|
|
|
VuConfigurations
|
|
n13
|
3072
|
3072
|
|
»;
3)au paragraphe TCS_163, le tableau est remplacé par le tableau suivant:
«
|
|
|
Min
|
Max
|
|
n1
|
|
|
3
|
|
n2
|
NoOfFaultsPerType
|
6
|
6
|
|
n3
|
NoOfCardVehicleRecords
|
8
|
8
|
|
n4
|
NoOfCardPlaceRecords
|
8
|
8
|
|
n5
|
NoOfCalibrationsSinceDownload
|
255
|
255
|
|
n6
|
CardActivityLengthRange
|
492 octets (1 jour * 240 changements d’activité)
|
492 octets (1 jour *
240 changements d’activité)
|
|
n7
|
NoOfCardVehicleUnitRecords
|
8
|
8
|
|
n8
|
NoOfGNSSADRecords
|
24
|
24
|
|
n9
|
NoOfSpecificConditionRecords
|
4
|
4
|
|
n10
|
NoOfBorderCrossingRecords
|
4
|
4
|
|
n11
|
NoOfLoadUnloadRecords
|
8
|
8
|
|
n12
|
NoOfLoadTypeEntryRecords
|
4
|
4
|
|
n13
|
VuConfigurationLengthRange
|
3072 octets
|
3072 octets
|
»;
v)le point 4.4.2 est modifié comme suit:
1)le paragraphe TCS_168 est remplacé par le texte suivant:
«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:
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_Configuration ne sont présents que dans la version 2 de la carte de contrôle de génération 2,
–
cardStructureVersion dans EF Application_Identification 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.
|
|
Règles d’accès
|
|
Fichier
|
ID fichier
|
SFID
|
Lire/Sélect.
|
Mettre à jour
|
|
|
|
DF Tachograph_G2
|
|
|
SC1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Application_Identification
|
‘0501h’
|
1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CardMA_Certificate
|
‘C100h’
|
2
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CA_Certificate
|
‘C108h’
|
4
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Link_Certificate
|
‘C109h’
|
5
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Identification
|
‘0520h’
|
6
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Controller_Activity_Data
|
‘050Ch’
|
14
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Application_Identification_V2
|
‘0525h’
|
22
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF VU_Configuration
|
‘0540h’
|
30
|
SC5/SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
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»;
2)au paragraphe TCS_170, le tableau est remplacé par le tableau suivant:
«
|
Fichier/Élément de données
|
|
|
|
|
Nombre de relevés
|
Min
|
Max
|
Valeurs par défaut
|
|
DF Tachograph_G2
|
|
|
|
|
|
14486
|
28237
|
|
|
|
EF Application_Identification
|
|
5
|
5
|
|
|
|
|
ControlCardApplicationIdentification
|
|
5
|
5
|
|
|
|
|
|
typeOfTachographCardId
|
|
1
|
1
|
{00}
|
|
|
|
|
cardStructureVersion
|
|
2
|
2
|
{01 01} V2
|
|
|
|
|
noOfControlActivityRecords
|
|
2
|
2
|
{00 00}
|
|
|
EF CardMA_Certificate
|
|
|
|
204
|
341
|
|
|
|
|
CardMA_Certificate
|
|
|
|
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 Identification
|
|
|
|
|
211
|
211
|
|
|
|
|
CardIdentification
|
|
|
|
65
|
65
|
|
|
|
|
|
cardIssuingMemberState
|
|
1
|
1
|
{00}
|
|
|
|
|
cardNumber
|
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
cardIssuingAuthorityName
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardIssueDate
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardValidityBegin
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardExpiryDate
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
ControlCardHolderIdentification
|
|
146
|
146
|
|
|
|
|
|
controlBodyName
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
controlBodyAddress
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardHolderName
|
|
|
|
|
|
|
|
|
|
|
|
holderSurname
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
|
holderFirstNames
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardHolderPreferredLanguage
|
|
2
|
2
|
{20 20}
|
|
|
EF Controller_Activity_Data
|
|
|
10582
|
23922
|
|
|
|
|
ControlCardControlActivityData
|
|
10582
|
23922
|
|
|
|
|
|
controlPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
controlActivityRecords
|
|
10580
|
23920
|
|
|
|
|
|
|
controlActivityRecord
|
n7
|
46
|
46
|
|
|
|
|
|
|
|
controlType
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
controlTime
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
controlledCardNumber
|
|
|
|
|
|
|
|
|
|
|
|
cardType
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
cardIssuingMemberState
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
cardNumber
|
|
16
|
16
|
{20..20}
|
|
|
|
|
|
|
controlledVehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
|
|
controlDownloadPeriodBegin
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
controlDownloadPeriodEnd
|
4
|
4
|
{00..00}
|
|
|
EF Application_Identification_V2
|
|
4
|
4
|
|
|
|
|
ControlCardApplicationIdentificationV2
|
|
4
|
4
|
|
|
|
|
|
lengthOfFollowingData
|
|
2
|
2
|
{00 00}
|
|
|
|
|
VuConfigurationLengthRange
|
|
2
|
2
|
{00 00}
|
|
|
EF VuConfiguration
|
|
|
|
3072
|
3072
|
|
|
|
|
VuConfigurations
|
|
|
n13
|
3072
|
3072
|
|
»;
3)au paragraphe TCS_171, le tableau est remplacé par le tableau suivant:
«
|
|
|
Min
|
Max
|
|
n7
|
|
|
520
|
|
n13
|
|
|
3072 octets
|
»;
vi)le point 4.5.2 est modifié comme suit:
1)le paragraphe TCS_176 est remplacé par le texte suivant:
«TCS_176Aprè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_Configuration ne sont présents que dans la version 2 de la carte d’entreprise de génération 2,
–cardStructureVersion dans EF Application_Identification 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.
|
|
|
Règles d’accès
|
|
Fichier
|
ID fichier
|
SFID
|
Lire/Sélect.
|
Mettre à jour
|
|
|
|
DF Tachograph_G2
|
|
|
SC1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Application_Identification
|
‘0501h’
|
1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CardMA_Certificate
|
‘C100h’
|
2
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CA_Certificate
|
‘C108h’
|
4
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Link_Certificate
|
‘C109h’
|
5
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Identification
|
‘0520h’
|
6
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Company_Activity_Data
|
‘050Dh’
|
14
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Application_Identification_V2
|
‘0525h’
|
22
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF VU_Configuration
|
‘0540h’
|
30
|
SC5/SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
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»;
2)au paragraphe TCS_178, le tableau est remplacé par le tableau suivant:
«
|
Fichier/Élément de données
|
|
|
|
|
Nombre de relevés
|
Min
|
Max
|
Valeurs par défaut
|
|
DF Tachograph_G2
|
|
|
|
|
|
14414
|
28165
|
|
|
|
EF Application_Identification
|
|
5
|
5
|
|
|
|
|
CompanyCardApplicationIdentification
|
|
5
|
5
|
|
|
|
|
|
typeOfTachographCardId
|
|
1
|
1
|
{00}
|
|
|
|
|
cardStructureVersion
|
|
2
|
2
|
{01 01} V2
|
|
|
|
|
noOfCompanyActivityRecords
|
|
2
|
2
|
{00 00}
|
|
|
EF CardMA_Certificate
|
|
|
|
204
|
341
|
|
|
|
|
CardMA_Certificate
|
|
|
|
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 Identification
|
|
|
|
|
139
|
139
|
|
|
|
|
CardIdentification
|
|
|
|
65
|
65
|
|
|
|
|
|
cardIssuingMemberState
|
|
1
|
1
|
{00}
|
|
|
|
|
cardNumber
|
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
cardIssuingAuthorityName
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardIssueDate
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardValidityBegin
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardExpiryDate
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
CompanyCardHolderIdentification
|
|
74
|
74
|
|
|
|
|
|
companyName
|
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
companyAddress
|
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardHolderPreferredLanguage
|
|
2
|
2
|
{20 20}
|
|
|
EF Company_Activity_Data
|
|
|
|
10582
|
23922
|
|
|
|
|
CompanyActivityData
|
|
|
|
10582
|
23922
|
|
|
|
|
|
companyPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
companyActivityRecords
|
|
10580
|
23920
|
|
|
|
|
|
|
companyActivityRecord
|
n8
|
46
|
46
|
|
|
|
|
|
|
|
companyActivityType
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
companyActivityTime
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
cardNumberInformation
|
|
|
|
|
|
|
|
|
|
|
|
cardType
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
cardIssuingMemberState
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
cardNumber
|
|
16
|
16
|
{20..20}
|
|
|
|
|
|
|
vehicleRegistrationInformation
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
|
|
downloadPeriodBegin
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
downloadPeriodEnd
|
|
4
|
4
|
{00..00}
|
|
|
EF Application_Identification_V2
|
|
4
|
4
|
|
|
|
|
CompanyCardApplicationIdentificationV2
|
|
4
|
4
|
|
|
|
|
|
lengthOfFollowingData
|
|
2
|
2
|
{00 00}
|
|
|
|
|
VuConfigurationLengthRange
|
|
2
|
2
|
{00 00}
|
|
|
EF VuConfiguration
|
|
|
|
3072
|
3072
|
|
|
|
|
VuConfigurations
|
|
|
n13
|
3072
|
3072
|
|
»;
3)au paragraphe TCS_179, le tableau est remplacé par le tableau suivant:
«
|
|
|
Min
|
Max
|
|
n8
|
|
|
520
|
|
n13
|
|
|
3072 octets
|
»;
(32)l’appendice 3 est modifié comme suit:
(a)le point 1 est modifié comme suit:
i)le paragraphe relatif aux conditions particulières est remplacé par le texte suivant:
«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»;
ii)les pictogrammes “divers” sont modifiés comme suit:
1)le pictogramme de sécurité est remplacé par le pictogramme suivant:
«
Sécurité/données authentifiées/scellements»;
2)le pictogramme suivant est ajouté:
«
Carte numérique/passage à la frontière»;
(b)le point 2 est modifié comme suit:
i)les combinaisons de pictogrammes suivantes sont ajoutées aux pictogrammes «divers»:
«
|
|
Position où le véhicule a franchi la frontière entre deux pays
|
|
|
Position où une opération de chargement a eu lieu
|
|
|
Position où une opération de déchargement a eu lieu
|
|
|
Position où une opération de chargement/déchargement simultanés a eu lieu»;
|
ii)les combinaisons de pictogrammes suivantes sont ajoutées aux pictogrammes pour les tirages papier:
«
Tirage papier de l’historique des cartes insérées»;
iii)la combinaison de pictogrammes suivante est ajoutée aux pictogrammes pour les événements:
«
Anomalie GNSS»;
(33)l’appendice 4 est modifié comme suit:
(a)au point 1, le paragraphe PRT_005 est remplacé par le texte suivant:
«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)le point 2 est modifié comme suit:
i)les tirets suivants sont ajoutés après le tableau et avant le paragraphe PRT_007:
«–
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ération 2 (toutes versions confondues),
–
** données disponibles uniquement dans la version 2 de la génération 2.»;
ii)les blocs 2 et 3 sont remplacés par les blocs suivants:
«
|
2
|
Type de tirage papier
|
|
|
Identificateur de bloc
Génération et version de la VU**
|
-----------
------------
GEN2 v2
|
|
|
Combinaison de pictogrammes d’impression (cf. appendice 3); réglage du dispositif limiteur de vitesse (impression uniquement en cas de dépassement de la vitesse autorisée)
|
Picto xxx km/h
|
|
|
|
|
|
|
|
|
3
|
Identification du titulaire de la carte
|
|
|
Identificateur de bloc. P = pictogramme individuel
|
-----------P------------
|
|
|
Nom du titulaire de la carte
|
P Last_Name_____________
|
|
|
Prénom(s) du titulaire de la carte (le cas échéant)
|
First_Name____________
|
|
|
Identification de carte
|
Card_Identification_____
|
|
|
Date d’expiration de la carte (le cas échéant) et numéro de génération de la carte (GEN1 ou GEN2)* et version**
|
dd/mm/yyyy - GEN2 v2
|
Si la carte considérée n’est pas individuelle et ne contient aucun nom de titulaire, le nom de l’entreprise, de l’atelier ou de l’organisme de contrôle concerné sera imprimé en lieu et place de celui-ci.»;
iii)avant le bloc 4, la phrase précédée d’un astérisque est supprimée;
iv)le bloc suivant est inséré après le bloc 4:
«
|
4a
|
Type de charge par défaut du véhicule**
|
|
|
pi = pictogramme du type de charge par défaut du véhicule**
|
pi
|
»;
v)le bloc 5 est remplacé par le bloc suivant:
«
|
5
|
Identification de la VU
|
|
|
Identificateur de bloc
|
-----------
------------
|
|
|
Nom du fabricant de la VU
|
VU_Manufacturer_______
|
|
|
Numéro de référence de la VU
Génération de la VU*
|
VU_Part_Number__
GEN2
|
»;
vi)avant le bloc 6, la phrase précédée d’un astérisque est supprimée;
vii)le bloc suivant est inséré après le bloc 8a:
«
|
8b
|
Type de charge au début de la journée** (si la carte est insérée dans une VU; ne pas remplir si tel n’est pas le cas), pi=pictogramme du type de charge**
|
-----------pi-----------
|
»;
viii)le bloc 8.2 est remplacé par le bloc suivant:
«
|
8.2
|
Insertion de la carte dans le lecteur S
|
|
|
Identificateur d’enregistrement; S = pictogramme de lecteur
|
---------S---------
|
|
|
État membre dans lequel le véhicule est immatriculé et numéro d’immatriculation du véhicule (VRN)
|
Nat/VRN__________
|
|
|
Kilométrage indiqué au compteur du véhicule lors de l’insertion de la carte
pi = type de charge du véhicule à l’insertion de la carte**
|
x xxx xxx km
pi
|
»;
ix)le bloc 10.2 est remplacé par le bloc suivant:
«
|
10.2
|
Insertion de carte
|
|
|
Identificateur d’enregistrement d’insertion de carte
|
--------------------
|
|
|
|
Last_Name_____________
|
|
|
Prénom du conducteur
|
First_Name____________
|
|
|
Identification de la carte du conducteur
|
Card_Identification_____
|
|
|
Date d’expiration de la carte (le cas échéant) et numéro de génération de la carte (GEN1 ou GEN2)* et version**
|
dd/mm/yyyy - GEN2 v2
|
|
|
État membre dans lequel le véhicule précédent utilisé est immatriculé et numéro d’immatriculation de ce véhicule
|
Nat/VRN__________
|
|
|
Date et heure de retrait de la carte introduite sur le précédent véhicule
|
dd/mm/yyyy hh:mm
|
|
|
Ligne vierge
|
|
|
|
Kilométrage indiqué au compteur lors de l’insertion de la carte, drapeau de saisie manuelle d’activités du conducteur (M si oui, espace vide si non).
S’il n’y a pas eu d’insertion de carte de conducteur le jour pour lequel le tirage papier est effectué, le kilométrage donné pour le bloc 10.2 est celui correspondant à la dernière insertion de carte disponible avant le jour concerné.
|
x xxx xxx km M
|
|
|
|
|
»;
x)avant le bloc 11, la phrase précédée d’un astérisque est supprimée;
xi)les blocs 11.4 et 11.5 sont remplacés par le texte suivant:
«
|
11.4
|
Saisie du lieu de début et/ou de fin d’une période de travail journalière
|
|
|
pi=pictogramme du lieu de départ/d’arrivée, heure, pays, région
latitude de la position enregistrée*, statut d’authentification**
longitude de la position enregistrée*, statut d’authentification**
horodatage de la détermination de la position*, statut d’authentification**
|
pihh:mm Cou Reg
lat ± DD°MM.M’
lon ±DDD°MM.M’
dd/mm/yyyy hh:mm
|
|
|
Kilométrage
|
x xxx xxx km
|
|
11.5
|
Position après trois heures de temps de conduite accumulé*
|
|
|
pi=position après trois heures de temps de conduite accumulé*, heure du relevé*
latitude de la position enregistrée*, statut d’authentification**
longitude de la position enregistrée*, statut d’authentification**
horodatage de la détermination de la position*, statut d’authentification**
|
pihh:mm
lat ± DD°MM.M’
lon ±DDD°MM.M’
dd/mm/yyyy hh:mm
|
|
|
Kilométrage*
|
x xxx xxx km
|
|
11.5 a
|
Passage aux frontières**
pi=position où le véhicule a franchi la frontière
|
|
|
d’un pays**
Pays de provenance/destination du véhicule**
latitude de la position enregistrée**, statut d’authentification**
longitude de la position enregistrée**, statut d’authentification**
horodatage de la détermination de la position**, statut d’authentification**
|
pi
Cou
Cou
lat ± DD°MM.M’
lon ±DDD°MM.M’
dd/mm/yyyy hh:mm
|
|
|
Kilométrage**
|
x xxx xxx km
|
|
11.5b
|
Opération de chargement/déchargement**
|
|
|
pi=position où une opération de chargement/déchargement a eu lieu, heure du relevé**
latitude de la position enregistrée**, statut d’authentification**
longitude de la position enregistrée**, statut d’authentification**
horodatage de la détermination de la position**
|
pihh:mm
lat ± DD°MM.M’
lon ±DDD°MM.M’
dd/mm/yyyy hh:mm
|
|
|
Kilométrage**
|
x xxx xxx km
|
»;
xii)le bloc 14 est remplacé par le bloc suivant:
«
|
14
|
Identification de la VU
|
|
|
Identificateur de bloc
|
-----------
------------
|
|
|
Nom du fabricant de la VU
|
Name__________________
|
|
|
Adresse du fabricant de la VU
|
Address_______________
|
|
|
Numéro de référence de la VU
|
PartNumber______
|
|
|
Numéro d’homologation de la VU
|
Apprv___________
|
|
|
|
S/N_____
|
|
|
Année de fabrication de la VU
Génération et version de la VU**
|
yyyy
GEN2 v2
|
|
|
|
V xxxx dd/mm/yyyy
xxxxxxxxxxxx
|
»;
xiii)le bloc 15.1 est remplacé par le bloc suivant:
«
|
15.1
|
Enregistrement de couplage
|
|
|
|
Numéro de série du capteur (S/N = serialNumber au format décimal, MY = monthYear au format décimal, T = type au format décimal, MC = manufacturerCode au format hexadécimal, voir appendice 1, ExtendedSerialNumber)
|
S/N_______ MY__ T__ MC_
|
|
|
Numéro d’homologation du capteur
|
Apprv___________
|
|
|
Date de couplage du capteur
|
dd/mm/yyyy hh:mm
|
»;
xiv)les blocs 16 et 16.1 sont remplacés par le texte suivant:
«
16
Identification du GNSS*
|
|
Identificateur de bloc*
|
-----------
-----------
|
16.1
Enregistrement de couplage*
|
|
Numéro de série du dispositif GNSS externe (S/N = serialNumber au format décimal, MY = monthYear au format décimal, T = type au format décimal, MC = manufacturerCode au format hexadécimal, voir appendice 1, ExtendedSerialNumber)
|
S/N_______ MY__ T__ MC_
|
|
|
Numéro d’homologation du dispositif GNSS externe*
|
Apprv___________
|
|
|
Date de couplage du dispositif GNSS externe*
|
dd/mm/yyyy hh:mm
|
|
16a
|
Identification du dispositif de communication à distance**
|
|
|
Identificateur de bloc**
|
-----------
-----------
|
16a.1
Numéro de série du dispositif de communication à distance**
|
Numéro de série du dispositif de communication à distance** (S/N = serialNumber au format décimal, MY = monthYear au format décimal, T = type au format décimal, MC = manufacturerCode au format hexadécimal, voir appendice 1, ExtendedSerialNumber)
|
S/N_______ MY__ T__ MC_
|
»;
xv)le bloc 17.1 est remplacé par le bloc suivant:
«
|
17.1
|
Enregistrement d’étalonnage
|
|
|
Identificateur d’enregistrement
|
--------------------
|
|
|
Atelier responsable de l’étalonnage
|
Workshop_name_________
|
|
|
Adresse de l’atelier
|
Workshop_address______
|
|
|
Identification de carte d’atelier
|
Card_Identification_____
|
|
|
Date d’expiration de la carte d’atelier
|
dd/mm/yyyy
|
|
|
Ligne vierge
|
|
|
|
Horodatage de l’étalonnage (oldTimeValue dans le relevé d’étalonnage) + motif d’étalonnage au format hexadécimal
|
dd/mm/yyyy hh:mm (p)
|
|
|
VIN
|
VIN______________
|
|
|
État membre dans lequel le véhicule est immatriculé et numéro d’immatriculation du véhicule (VRN)
|
Nat/VRN__________
|
|
|
Coefficient caractéristique du véhicule
|
w xx xxx Imp/km
|
|
|
Constante de l’équipement d’enregistrement
|
k xx xxx Imp/km
|
|
|
Circonférence effective des pneumatiques
|
l xx xxx mm
|
|
|
Dimensions des pneumatiques montés
|
TyreSize_______
|
|
|
Réglage du dispositif limiteur de vitesse
|
xxx km/h
|
|
|
Ancien et nouveau kilométrages indiqués au compteur
pi=type de charge par défaut du véhicule**
Pays dans lequel l’étalonnage a été effectué et horodatage
Données des scellements (jusqu’à 5 relevés de scellements, 1 ligne pour chaque scellement utilisé), ET = equipmentType au format décimal**, MC = manufacturerCode en deux caractères** , SI = sealIdentifier en 8 caractères**, voir appendice 1, SealRecord)
|
x xxx xxx – x xxx xxx km
pi
Cou dd/mm/yyyy hh:mm
ET_ MC SI______
|
Le motif d’étalonnage (p) prend la forme d’un code numérique indiquant la raison pour laquelle ces paramètres d’étalonnage ont été enregistrés et codés en conformité avec l’élément d’information CalibrationPurpose.»;
xvi)le bloc 23 est remplacé par le bloc suivant:
«
|
23
|
Cartes les plus récentes insérées dans la VU*
|
|
|
Identificateur de bloc*
|
--------
--------
|
|
23.1
|
Carte insérée*
|
|
|
|
Identificateur d’enregistrement*
|
----
|
|
|
|
<gen> <version> <MC>
|
|
|
Identification de carte*
Numéro de série de la carte*
Date et heure de la dernière insertion de carte*
|
Card Identification
Card Serial Number
dd/mm/yyyy hh:mm
|
|
|
|
|
1 (le tout sur une seule ligne)
avec
type de carte: pictogramme, un caractère + espace
gen: GEN1 ou GEN2, 4 caractères + espace
version: jusqu’à 10 caractères
MC: code du fabricant, 3 caractères»;
(c)le point 3 est modifié comme suit:
i)au point 3.1, le paragraphe PRT_008 est remplacé par le texte suivant:
«PRT_008
Le tirage quotidien des activités du conducteur extraites d’une carte doit respecter le format suivant:
|
1
|
Date et heure d’impression du document
|
|
2
|
Type de tirage papier
|
|
3
|
Identification du contrôleur (en cas d’insertion d’une carte de contrôle dans la VU)
|
|
3
|
Identification du conducteur (extraite de la carte faisant l’objet de l’impression + GEN)
|
|
4
|
Identification du véhicule (à partir duquel le tirage est exécuté)
|
|
5
|
Identification de la VU (à partir de laquelle le tirage est exécuté + GEN)
|
|
6
|
Dernier étalonnage de cette VU
|
|
7
|
Dernier contrôle auquel le conducteur inspecté a été soumis
|
|
8
|
Délimiteur des activités du conducteur
|
|
8a
|
Condition hors champ au début de cette journée
|
|
8b
|
Type de charge au début de la journée (si la carte est insérée dans une VU)
|
|
8.1a / 8.1b / 8.1c / 8.2 / 8.3 / 8.3a / 8.4
|
Activités du conducteur par ordre chronologique
|
|
11
|
Délimiteur de synthèse quotidienne
|
|
11.4
|
Lieux saisis, par ordre chronologique
|
|
11.5
|
Positions après trois heures de temps de conduite accumulé, par ordre chronologique
|
|
11.5a
|
Passages aux frontières, par ordre chronologique
|
|
11.5b
|
Opérations de chargement/déchargement, par ordre chronologique
|
|
11.6
|
Totaux par activité
|
|
12.1
|
Délimiteur des événements et anomalies extraits d’une carte
|
|
12.4
|
Enregistrements d’événements/anomalies (5 derniers événements ou anomalies enregistrés sur la carte)
|
|
13.1
|
Délimiteur des événements ou anomalies extraits de la VU
|
|
13.4
|
Enregistrements d’événements/anomalies (5 derniers événements ou anomalies enregistrés ou en cours dans la VU)
|
|
22.1
|
Lieu du contrôle
|
|
22.2
|
Signature du contrôleur
|
|
22.5
|
Signature du conducteur
|
»;
ii)au point 3.2, le paragraphe PRT_009 est remplacé par le texte suivant:
«PRT_009
Le tirage quotidien des activités du conducteur extraites de la VU doit respecter le format suivant:
|
1
|
Date et heure d’impression du document
|
|
2
|
Type de tirage papier
|
|
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é)
|
|
4a
|
Type de charge par défaut du véhicule
|
|
5
|
Identification de la VU (à partir de laquelle le tirage est exécuté + GEN)
|
|
6
|
Dernier étalonnage de cette VU
|
|
7
|
Dernier contrôle auquel ce tachygraphe a été soumis
|
|
9
|
Délimiteur des activités du conducteur
|
|
10
|
Délimiteur de lecteur de carte du conducteur (lecteur 1)
|
|
10a
|
Condition hors champ au début de cette journée
|
|
10.1 / 10.2 / 10.3 /10.3a / 10.4
|
Activités par ordre chronologique (lecteur conducteur)
|
|
10
|
Délimiteur de lecteur de carte du convoyeur (lecteur 2)
|
|
10a
|
Condition hors champ au début de cette journée
|
|
10.1 / 10.2 / 10.3 /10.3a / 10.4
|
Activités par ordre chronologique (lecteur convoyeur)
|
|
11
|
Délimiteur de synthèse quotidienne
|
|
11.1
|
Synthèse des périodes sans carte dans le lecteur du conducteur
|
|
11.4
|
Lieux saisis, par ordre chronologique
|
|
11.5
|
Positions après trois heures de temps de conduite accumulé, par ordre chronologique
|
|
11.5a
|
Passages aux frontières, par ordre chronologique
|
|
11.5b
|
Opérations de chargement/déchargement, par ordre chronologique
|
|
11.7
|
Totaux par activité
|
|
11.2
|
Synthèse des périodes sans carte dans le lecteur du convoyeur
|
|
11.4
|
Lieux saisis, par ordre chronologique
|
|
11.5
|
Positions après trois heures de temps de conduite accumulé, par ordre chronologique
|
|
11.5a
|
Passages aux frontières, par ordre chronologique
|
|
11.5b
|
Position où une opération de chargement/déchargement a eu lieu, par ordre chronologique
|
|
11.8
|
Totaux par activité
|
|
11.3
|
Synthèse des activités par conducteur, les deux lecteurs étant inclus
|
|
|
11.4
|
|
Lieux saisis par ce conducteur, par ordre chronologique
|
|
|
11.5
|
|
Positions après trois heures de temps de conduite accumulé par ordre chronologique
|
|
|
11.5a
|
|
Passages aux frontières, par ordre chronologique
|
|
|
11.5b
|
|
Opérations de chargement/déchargement, par ordre chronologique
|
|
11.9
|
Totaux par activité pour ce conducteur
|
|
13.1
|
Délimiteur d’événements et d’anomalies
|
|
13.4
|
Enregistrements d’événements/anomalies (5 derniers événements ou anomalies enregistrés ou en cours dans la VU)
|
|
22.1
|
Lieu du contrôle
|
|
22.2
|
Signature du contrôleur
|
|
22.3
|
|
|
22.4
|
à (heure)
les périodes qui correspondent à ses prestations)
|
|
22.5
|
Signature du conducteur
|
»;
iii)au point 3.5, le paragraphe PRT_012 est remplacé par le texte suivant:
«PRT_012
Le tirage des données techniques doit respecter le format suivant:
|
1
|
Date et heure d’impression du document
|
|
2
|
Type de tirage papier
|
|
3
|
Identification du titulaire de la carte (pour toutes les cartes insérées dans la VU + GEN)
|
|
4
|
Identification du véhicule (à partir duquel le tirage est exécuté)
|
|
14
|
Identification de la VU
|
|
15
|
Identification des capteurs
|
|
15.1
|
Données relatives au couplage des capteurs (toutes les données disponibles, par ordre chronologique)
|
|
16
|
Identification du GNSS
|
|
16.1
|
Données relatives au couplage du dispositif GNSS externe (toutes les données disponibles, par ordre chronologique)
|
|
16a
|
Identification du dispositif de communication à distance
|
|
16a.1
|
Numéro de série du dispositif de communication à distance
|
|
17
|
Délimiteur des données d’étalonnage
|
|
17.1
|
Enregistrement d’étalonnage (ensemble des enregistrements disponibles par ordre chronologique)
|
|
18
|
Délimiteur du réglage de l’heure
|
|
18.1
|
Enregistrement du réglage de l’heure (ensemble des enregistrements disponibles, extraits des enregistrements du réglage de l’heure et des données d’étalonnage)
|
|
19
|
Événement et anomalie les plus récents enregistrés dans la VU
|
|
2
|
Type de tirage papier (indique la fin de l’impression)
|
»;
iv)au point 3.7, le paragraphe PRT_014 est remplacé par le texte suivant:
«PRT_014
Le tirage de l’historique des cartes insérées doit respecter le format suivant:
|
1
|
Date et heure d’impression du document
|
|
2
|
Type de tirage papier
|
|
3
|
Identifications du titulaire de la carte (pour toutes les cartes insérées dans la VU)
|
|
23
|
Cartes les plus récentes insérées dans la VU
|
|
23.1
|
Cartes insérées (jusqu’à 88 enregistrements)
|
|
2
|
Type de tirage papier (indique la fin de l’impression)
|
»;
(34)l’appendice 7 est modifié comme suit:
(a)la table des matières est modifiée comme suit:
i)les points 2.2.6.1 à 2.2.6.5 sont remplacés par le texte suivant:
«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»;
ii)le point suivant est ajouté:
«2.2.6.6
Réponse positive à une demande de transfert de données techniques»;
(b)le point 2 est modifié comme suit:
i)au point 2.2.2, le tableau de structure du message et les remarques qui suivent le tableau sont remplacés par le texte suivant:
«
|
Structure du message
|
4 octets max.
|
255 octets max.
|
1 octet
|
|
|
|
En-tête
|
Données
|
Total de contrôle
|
|
IDE ->
|
<- VU
|
FMT
|
TGT
|
SRC
|
LEN
|
SID
|
DS_ / TRTP
|
DATA
|
CS
|
|
Demande d’établissement de la communication
|
81
|
EE
|
F0
|
|
81
|
|
|
E0
|
|
Réponse positive à une demande d’établissement de la communication
|
80
|
F0
|
EE
|
03
|
C1
|
|
EA, 8F
|
9B
|
|
Demande d’ouverture d’une session de diagnostic
|
80
|
EE
|
F0
|
02
|
10
|
81
|
|
F1
|
|
Réponse positive à une demande d’ouverture de session de diagnostic
|
80
|
F0
|
EE
|
02
|
50
|
81
|
|
31
|
|
Service de contrôle de liaison
|
|
|
|
|
|
|
|
|
|
Vérification du débit en bauds (étape 1)
|
|
|
|
|
|
|
|
|
|
9 600 Bd
|
80
|
EE
|
F0
|
04
|
87
|
01
|
01,01
|
EC
|
|
19 200 Bd
|
80
|
EE
|
F0
|
04
|
87
|
01
|
01,02
|
ED
|
|
38 400 Bd
|
80
|
EE
|
F0
|
04
|
87
|
01
|
01,03
|
EE
|
|
57 600 Bd
|
80
|
EE
|
F0
|
04
|
87
|
01
|
01,04
|
EF
|
|
115 200 Bd
|
80
|
EE
|
F0
|
04
|
87
|
01
|
01,05
|
F0
|
|
Réponse positive à une demande de vérification du débit en bauds
|
80
|
F0
|
EE
|
02
|
C7
|
01
|
|
28
|
|
Débit de transition en bauds (étape 2)
|
80
|
EE
|
F0
|
03
|
87
|
02
|
03
|
ED
|
|
Demande de téléchargement (upload)
|
80
|
EE
|
F0
|
0A
|
35
|
|
00,00,00,00,00,FF,FF,
FF,FF
|
99
|
|
Réponse positive à une demande de téléchargement
|
80
|
F0
|
EE
|
03
|
75
|
|
00,FF
|
D5
|
|
Demande de transfert de données
|
|
|
|
|
|
|
|
|
|
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
|
|
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 “download” (considéré à partir de la VU).
–
Cette table ne présente pas de compteur potentiel de sous-messages de 2 octets.
–
Le lecteur désigne le numéro de lecteur, soit “1” (carte sur le lecteur du conducteur) soit “2” (carte sur le lecteur du convoyeur).
–
Si le lecteur n’est pas précisé, la VU sélectionne le lecteur 1 s’il contient une carte et le lecteur 2 uniquement si l’utilisateur le sélectionne.
–
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échargement 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.»;
ii)le point 2.2.2.9 est modifié comme suit:
1)
au paragraphe DDP_011, le deuxième alinéa et le premier tableau sont remplacés par le texte suivant:
«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
|
»;
2)
le paragraphe DDP_054 est remplacé par le texte suivant:
«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é.»;
iii)au point 2.2.2.10, le texte précédant les tirets du paragraphe DDP_055 est remplacé par le texte suivant:
«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 informations contenues dans ce message sont les suivantes:»;
iv)au point 2.2.5.2, la figure 2 est remplacée par le texte suivant:
«
Figure 2
Traitement d’erreur au niveau de la VU
»;
v)les points 2.2.6.1 à 2.2.6.5 sont remplacés par le texte suivant:
«2.2.6.1
Réponse positive à une demande de transfert de données relatives au téléchargement de la version d’interface
DDP_028a
Le champ de données du message «Réponse positive à une demande de transfert de données relatives au téléchargement 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:
«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éponse positive à un récapitulatif de transfert de données
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 approprié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 VehicleIdentificationNumber jusqu’au dernier octet du dernier VuControlActivityData.
|
|
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
|
|
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éponse positive à une demande de transfert de données relatives aux activité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:
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 disponible, seule l’expression noOfVuCardIWRecords = 0 est envoyée.
-Lorsque VuCardIWRecord figure à 00 h 00 (insertion 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émorisées pour la journée téléchargée. Si cette section est vide, seule l’expression noOfSpecificConditionRecords = 0 est envoyée.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signature
|
|
Signature RSA de toutes les données à partir de TimeReal jusqu’au dernier octet du dernier relevé de conditions 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 disponible, un en-tête de tableau avec l’expression noOfRecords = 0 est envoyé.
-Lorsque VuCardIWRecord figure à 00 h 00 (insertion 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émorisées 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.
|
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 disponible, un en-tête de tableau avec l’expression noOfRecords = 0 est envoyé.
-Lorsque VuCardIWRecord figure à 00 h 00 (insertion 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émorisées 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é
|
|
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.
|
2.2.6.4
Réponse positive à une demande de transfert de données relatives aux événements et anomalies
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 noOfVuFaults = 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 noOfVuEvents = 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 noOfVuOverSpeedingEvents = 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 noOfVuTimeAdjRecords = 0 est envoyée.
|
|
|
|
|
|
|
|
|
|
Signature
|
|
Signature RSA de toutes les données à partir de noOfVuFaults 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é.
|
|
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éponse positive à une demande de transfert de données relatives à la vitesse du véhicule
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 noOfSpeedBlocks jusqu’au dernier octet du dernier bloc de vitesse.
|
|
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.
|
»;
vi)le point suivant est ajouté:
«2.2.6.6
Réponse positive à une demande de transfert de données techniques
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 vuManufacturerName jusqu’au dernier octet du dernier VuCalibrationRecord.
|
Structure de données de génération 2, version 1 (TREP 25 Hex)
|
Commentaire
|
|
Élément de données
|
|
|
|
VuIdentificationRecordArray
|
|
|
|
VuSensorPairedRecordArray
|
|
Tous les couplages MS mémorisés dans la VU.
|
|
VuSensorExternalGNSSCoupledRecordArray
|
|
Tous les couplages du dispositif GNSS externe mémorisé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.
|
Structure de données de génération 2, version 2 (TREP 35 Hex)
|
Commentaire
|
|
Élément de données
|
|
|
|
VuIdentificationRecordArray
|
|
|
|
VuSensorPairedRecordArray
|
|
Tous les couplages MS mémorisés dans la VU.
|
|
VuSensorExternalGNSSCoupledRecordArray
|
|
Tous les couplages du dispositif GNSS externe mémorisé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.
|
»;
(c)au point 3.3, le paragraphe DDP_035 est remplacé par le texte suivant:
«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, conformément aux dispositions de l’appendice 11, Mécanismes de sécurité communs, partie A.
–
Il y a lieu de télécharger au moins les EF Application_Identification et Identification lors de toute session de téléchargement.
–
Lors du téléchargement d’une carte de conducteur, il faut également procéder obligatoirement au télé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 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_G2 DF) sauf l’EF Card_Download. Ces informations sont protégées par une signature numérique, conformément aux dispositions de l’appendice 11, Mécanismes de sécurité communs, partie B.
–
Il y a lieu de télécharger au moins les EF Application_Identification, Application_Identification_V2 (le cas échéant) et Identification lors de toute session de téléchargement.
–
Lors du téléchargement d’une carte de conducteur, il faut également procéder obligatoirement au télé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 conducteur, il convient de mettre à jour la date LastCardDownload dans l’EF Card_Download, dans les DF Tachograph et, le cas échéant, Tachograph_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, Tachograph_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é.»;
(35)l’appendice 8 est modifié comme suit:
(a)la table des matières est modifiée comme suit:
i)les points 8, 8.1 et 8.2 sont remplacés par le texte suivant:
«8.
SERVICE ROUTINECONTROL (RÉGLAGE DE L’HEURE)
8.1.
Description des messages
8.2.
Structure des messages»;
ii)les points 9, 9.1 et 9.2 suivants sont ajoutés:
«9.
STRUCTURES DES DATARECORDS
9.1.
Gammes des paramètres transmis
9.2.
Structures des dataRecords»;
(b)au point 3.1, la ligne suivante est ajoutée au tableau 1:
«
|
|
Sessions de diagnostic
|
|
RoutineControl
|
8
|
31
|
|
■
|
■
|
»;
(c)au point 6.1.3, le paragraphe CPR_053 est remplacé par le texte suivant:
«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 1re colonne (Hex.) indique la “Valeur hex.” affectée au recordDataIdentifier spécifié dans la 3e colonne.
–
La 2e colonne (Élément de donnée) indique l’élément de donnée de l’Appendice 1 sur lequel est basé recordDataIdentifier (un transcodage est parfois nécessaire).
–
La 3e colonne (Description) spécifie le nom recordDataIdentifier correspondant.
–
La 4e colonne (Droits d’accès) spécifie les droits d’accès à ce recordDataIdentifier.
–
La 5e 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
|
HighResolutionTotalVehicleDistance
|
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
|
RemoteCommunicationModuleSerialNumber
|
RemoteCommunicationFacilitySerialNumber
|
L
|
RDI_RCSN
|
|
F9D2
|
SensorGNSSSerialNumber
|
ExternalGNSSFacilitySerialNumber
|
L
|
RDI_GSSN
|
|
F9D3
|
SealDataVu
|
SmartTachographSealsSerialNumber
|
L/E
|
RDI_SDV
|
|
F9D4
|
VuSerialNumber
|
VuSerialNumber
|
L
|
RDI_VSN
|
|
F9D5
|
ByDefaultLoadType
|
ByDefaultLoadType
|
L/E
|
RDI_BDLT
|
|
F9D6
|
TachographCardsGen1Suppression
|
TachographCardsGen1Suppression
|
L/E
|
RDI_TCG1S
|
|
F9D7
|
VehiclePosition
|
VehiclePosition
|
L
|
RDI_VP
|
|
F9D8
|
LastCalibrationCountry
|
CalibrationCountry
|
L
|
RDI_CC
|
»;
(d)le point 8 est remplacé par le texte suivant:
«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 (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 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 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.
8.2.
Structure des messages
CPR_065b
La structure des messages associés au service RoutineControl (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
|
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
|
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
|
»;
(e)le point 9 suivant est ajouté:
«9.
STRUCTURES DES DATARECORDS
Le présent chapitre expose en détail:
–
les règles générales applicables aux gammes de paramètres transmises par l’unité embarquée sur le véhicule à l’appareil d’essai,
–
les structures qui sont utilisées pour les données transférées par l’intermédiaire des services de transmission de données à la section 6.
CPR_067
Tous les paramètres indiqués sont pris en charge par la VU.
CPR_068
Les données transmises par la VU à l’appareil d’essai en réponse à une demande sont du type mesurées (c’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 transmission 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 WriteDataByIdentifier.
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
|
|
HighResolutionTotalVehicleDistance
|
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
|
|
RemoteCommunicationModuleSerialNumber
|
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
|
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
|
|
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)
|
|
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.
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
|
|
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
|
|
sans objet
|
SealRecord
|
|
12 - 22
|
|
sans objet
|
SealRecord
|
|
23 – 33
|
|
sans objet
|
SealRecord
|
|
34 – 44
|
|
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 disponibles, 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
|
|
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, SensorSerialNumber, SensorGNSSSerialNumber et RemoteCommunicationModuleSerialNumber:
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
|
|
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
|
|
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.»;
(36)l’appendice 9 est modifié comme suit:
(a)dans la table des matières, le point 9 suivant est ajouté:
«9.
ESSAIS OSNMA»;
(b)le point 1 est modifié comme suit:
i)au point 1.1, l’alinéa suivant est ajouté:
«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.»;
ii)au point 1.2, la référence suivante est ajoutée:
«RGODP
JRC Technical Report – Receiver guidelines for OSNMA data processing»;
(c)au point 2, les lignes 3.1 à 3.41 sont remplacées par le texte suivant:
«
|
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*
|
|
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
|
»;
(d)le point 9 suivant est ajouté:
«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écepteur GNSS en toute indépendance par rapport aux autres composants du tachygraphe, les essais décrits dans le présent chapitre peuvent être effectué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écepteur 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’authentification et délai de la clé)
DSM-KROOT
“Digital Signature Message KROOT” (message de signature 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 Authentication” (service d’authentification des messages de navigation en libre service de Galileo)
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 simulateur 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’échantillonnage 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éalisation en heure locale du récepteur pour l’exigence de vérification de la synchronisation OSNMA et pour charger les informations cryptographiques. 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éristiques 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 caracté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).
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 temporelle 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
|
|
|
|
Essais généraux
|
|
|
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
|
|
|
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écepteur 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
|
|
|
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 temporelle 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é.
Avant de commencer les essais, les éphémérides et la KROOT doivent être effacées de la mémoire du récepteur 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.
|
Appendice 12,
GNS_3 ter
|
|
|
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
|
|
|
Démarrage OSNMA très chaud avec des données erronées
|
Objectif: vérifier que OSNMA détecte les données erroné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
|
»;
(37)l’appendice 12 est modifié comme suit:
(a)la table des matières est modifiée comme suit:
i)le point 1.1.1 suivant est inséré après le point 1.1:
«1.1.1
Références»;
ii)le point 2 est remplacé par le texte suivant:
«2.
CARACTÉRISTIQUES DE BASE DU RÉCEPTEUR GNSS»;
iii)le point 3 est remplacé par le texte suivant:
«3.
PHRASES FOURNIES PAR LE RÉCEPTEUR GNSS»;
iv)les points 4.2.4 et 4.2.5 suivants sont insérés:
«4.2.4
Structure de la commande WriteRecord
4.2.5
Autres commandes»;
v)le point 5.2 est remplacé par le texte suivant:
«5.2.
Transfert d’informations du récepteur GNSS vers la VU»;
vi)
la section 5.2.1 est supprimée;
vii)les points 5.3, 5.4 et 5.4.1 suivants sont insérés:
«5.3.
Transfert d’informations de la VU vers le récepteur GNSS
5.4.
Traitement des erreurs
5.4.1
Absence d’informations de positionnement en provenance du récepteur GNSS;
viii)les points 6 et 7 sont remplacés par le texte suivant:
«6.
TRAITEMENT ET ENREGISTREMENT DES DONNÉES DE POSITIONNEMENT PAR LA VU
7.
CONFLIT TEMPOREL GNSS»;
ix)le point 8 suivant est ajouté:
«8.
CONFLIT CONCERNANT LE MOUVEMENT DU VÉHICULE»;
(b)le point 1 est modifié comme suit:
i)le texte précédant la figure 1 est remplacé par le texte suivant:
«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 localisation à 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:»;
ii)le point 1.1.1 suivant est inséré après le point 1.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 Association”) 0183, V4.11»;
iii)au point 1.2, les abréviations suivantes sont ajoutées:
«OSNMA
“Galileo Open Service Navigation Message Authentication” (service d’authentification des messages de navigation en service ouvert de Galileo)
RTC
“Real Time Clock” (horloge en temps réel)
»;
(c)le point 2 est modifié comme suit:
i)le titre est remplacé par le titre suivant:
«2.
CARACTÉRISTIQUES DE BASE DU RÉCEPTEUR GNSS»;
ii)le paragraphe GNS_3 est remplacé par le texte suivant:
«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).»;
iii)les paragraphes GNS_3 bis à GNS_3 octies suivants sont ajoutés:
«GNS_3 bis
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’autonomie du récepteur (“receiver autonomous integrity 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.
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.»;
(d)le point 3 est remplacé par le texte suivant:
«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 informations de positionnement (latitude et longitude), l’heure au format UTC (hhmmss.ss) et la vitesse sur le fond en nœuds plus d’autres valeurs complémentaires.
La structure de la phrase RMC est la suivante (d’après la norme NMEA V4.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.
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 minimales authentifiées (AMC), qui contiennent les informations de positionnement (latitude et longitude), l’heure au format UTC (hhmmss.ss) et la vitesse sur le fond en nœuds plus d’autres valeurs complémentaires.
La structure de la phrase AMC est la suivante (d’après la norme NMEA V4.11,sauf pour la valeur nº 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’authentification 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
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 positionnement en termes de latitude et de longitude selon une résolution d’1/10 minute ou 1/600 degré, comme le décrit l’appendice 1 pour les coordonnées géographiques 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’exactitude 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*hh
1)
Mode de sélection
2)
Mode
3)
ID du 1er satellite utilisé comme point de repère
4)
ID du 2e satellite utilisé comme point de repère
…
14)
ID du 12e 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.
De même, la VU peut utiliser la phrase satellites actifs authentifiés (ASA) de type NMEA pour déterminer et enregistrer la disponibilité du signal et l’exactitude des positionnements 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*hh
1)
Mode de sélection
2)
Mode
3)
ID du 1er satellite utilisé comme point de repère
4)
ID du 2e satellite utilisé comme point de repère
…
14)
ID du 12e 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).»;
(e)le point 4 est modifié comme suit:
i)au point 4.1.1, le paragraphe GNS_9, est modifié comme suit:
1)
le texte précédant le point b) est remplacé par le texte suivant:
«GNS_9
Le dispositif GNSS externe se compose des éléments suivants (cf. figure 6):
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.»;
2)
le point c) est remplacé par le texte suivant:
«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.»;
ii)le point 4.2.1 est modifié comme suit:
1)
le paragraphe GNS_14 est remplacé par le texte suivant:
«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 dispositif 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.»;
2)
le paragraphe suivant est inséré après le paragraphe GNS_18:
«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.»;
3)
le paragraphe suivant est inséré après le paragraphe GNS_19:
«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 correspond à ‘2F30’ au format hexadécimal.
4)
au paragraphe GNS_20, le premier alinéa est remplacé par le texte suivant:
«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.»;
5)
au paragraphe GNS_21, le tableau 1 est remplacé par le tableau suivant:
«
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
|
|
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’enregistrement
|
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
|
|
|
1re phrase GSA NMEA
|
‘02’
|
85
|
85
|
|
|
2e phrase GSA NMEA
|
‘03’
|
85
|
85
|
|
|
3e phrase GSA NMEA
|
‘04’
|
85
|
85
|
|
|
4e phrase GSA NMEA
|
‘05’
|
85
|
85
|
|
|
5e phrase GSA NMEA
|
‘06’
|
85
|
85
|
|
|
Numéro de série étendu du dispositif GNSS externe défini à l’appendice 1 comme SensorGNSSSerialNumber.
|
‘07’
|
8
|
8
|
|
|
Identificateur du système d’exploitation 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 SensorExternalGNSSApprovalNumber.
|
‘09’
|
16
|
16
|
|
|
Identificateur du composant de sécurité du dispositif GNSS externe défini à l’appendice 1 comme SensorExternalGNSSSCIdentifier
|
‘10’
|
8
|
8
|
|
|
Phrase AMC
|
‘11’
|
85
|
85
|
|
|
1re phrase ASA
|
‘12’
|
85
|
85
|
|
|
2e phrase ASA
|
‘13’
|
85
|
85
|
|
|
3e phrase ASA
|
‘14’
|
85
|
85
|
|
|
4e phrase ASA
|
‘15’
|
85
|
85
|
|
|
5e 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}
|
»;
iii)le point 4.2.2 est modifié comme suit:
1)
au paragraphe GNS_22, le premier alinéa est remplacé par le texte suivant:
«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:»;
2)
le paragraphe GNS_23 est remplacé par le texte suivant:
«GNS_23
Toutes les T secondes, où T est une valeur inférieure ou égale à 20, sauf pendant le déroulement de l’appariement, de l’authentification mutuelle et de la concordance de clés de session, la VU demande au dispositif GNSS externe les informations de positionnement selon la séquence suivante:
1.
La VU demande les données de 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’identificateur 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écurisée, comme le décrit l’appendice 11, section 11.5.
4.
L’émetteur-récepteur sécurisé de la VU contrôle l’authenticité et l’intégrité de la réponse reçue. En cas de résultat positif, les données de positionnement 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 latitude, 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 authentifié n’est pas valide ou si le signal GNSS a été attaqué. Si le positionnement est valide, le processeur 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).
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’identificateur de fichier ‘2F30’ et le numéro RECORD égal à ‘01’ pour VuRtcTime et à ‘02’ pour MaximalTimeDifference.»;
iv)le point 4.2.3 est modifié comme suit:
1)
au paragraphe GNS_26, les quatrième et cinquième tirets sont remplacés par le texte suivant:
«–
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’.»;
2)
le paragraphe GNS_27 est supprimé;
v)les points 4.2.4 et 4.2.5 suivants sont insérés:
«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 dispositions de l’appendice 11 Mécanismes de sécurité communs.
GNS_26 bis
La commande est compatible avec le mode authentification 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’enregistrement 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é enregistrement, l’émetteur-récepteur sécurisé GNSS renvoie ‘6981’.
–
Si la commande est utilisée avec P1 = ‘00’, mais sans aucun EF en cours, l’émetteur-récepteur sécurisé GNSS renvoie ‘6986’ (commande interdite).
–
Si l’enregistrement est introuvable, l’émetteur-récepteur sécurisé GNSS renvoie ‘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
|
»;
vi)au point 4.4.1, le paragraphe GNS_28 est remplacé par le texte suivant:
«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.»;
vii)au point 4.4.2, le paragraphe GNS_29 est remplacé par le texte suivant:
«GNS_29
En cas d’atteinte au dispositif GNSS externe, l’émetteur-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’appendice 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’.»;
viii)au point 4.4.3, le paragraphe GNS_30 est remplacé par le texte suivant:
«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).»;
ix)le point 4.4.4 est modifié comme suit:
1)
le paragraphe GNS_31 est remplacé par le texte suivant:
«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.»;
2)
l’en-tête de la figure 4 est remplacé par le texte suivant:
«Figure 6
Schéma du dispositif GNSS externe»;
(f)le point 5 est modifié comme suit:
i)au point 5.1, le paragraphe GNS_32 est remplacé par le texte suivant:
«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 également 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.»;
ii)le point 5.2 est remplacé par le texte suivant:
«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 positionnement 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 authentifié 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 informations (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 processeur de la VU extrait également les valeurs HDOP des phrases ASA.
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).»;
(g)les points 6 et 7 sont remplacés par le texte suivant:
«6.
Traitement et enregistrement des données de positionnement par la VU
Cette section est applicable à la configuration du tachygraphe intelligent 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 positionnement 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 standard 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 exactitude, 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 authentifié se trouve dans un cercle centré sur le positionnement 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 positionnements authentifiés.
-
UERE est l’écart type
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.
–
HDOP est l’affaiblissement de la précision horizontale
calculée par le récepteur GNSS.
–
UERE HDOP est l’estimation de l’erreur
quadratique 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 (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’.
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 enregistre un événement “Conflit temporel GNSS”, conformément à l’exigence 86 de l’annexe IC et à l’appendice 1 (EventFaultType).»;
(h)le point 8 suivant est ajouté:
«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 informations relatives au mouvement calculées à partir du capteur de mouvement ne cadrent pas avec les informations relatives 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éhicule” est déclenché lorsque l’une des conditions de déclenchement suivantes se produit:
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 dispositif GNSS et celle estimée par le capteur de mouvement est calculée.
–
toutes les données calculées dans une fenêtre horaire comportant les cinq dernières minutes de mouvement du véhicule servent à calculer la valeur moyenne tronquée.
–
la valeur moyenne tronquée est calculée comme la moyenne des 80 % de valeurs restantes après élimination des plus élevées en valeur absolue.
L’événement de conflit de mouvement du véhicule est déclenché si la valeur 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éhicule” est également déclenché si la condition suivante est vraie:
lorsque:
–
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 authentifié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),
–
Minimum [SlipDistanceUpperLimit; (OdometerDifference * 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: FerryTrainDistance = 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écessaires sont disponibles, ou dès que les données de positionnement 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 positionnement 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’enregistrement 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.»;
(38)l’appendice 13 est remplacé par le texte suivant:
«
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º 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 Bluetooth®,
–
les protocoles Bluetooth® qu’utilise l’interface ITS.
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 intelligent)
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 – Interconnexion 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’interface 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 à Bluetooth 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 Bluetooth®. 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 transmission de données entre appareils, dans lequel la VU fera office de serveur et l’unité ITS de client.
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’intermé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’intermé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écifié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échargement spécifiée à l’appendice 6.
ITS_13
La VU met l’interface ITS à la disposition de l’utilisateur en fonction de la combinaison de cartes tachygraphiques valides insérées dans la VU, comme indiqué dans le tableau 1.
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 conducteur
|
Carte de contrôleur
|
Carte d’atelier
|
Carte d’entreprise
|
|
Lecteur «convoyeur»
|
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’entreprise
|
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 conducteur
|
Carte de contrôleur
|
Carte d’atelier
|
Carte d’entreprise
|
|
Lecteur «convoyeur»
|
Pas de carte
|
Non disponible
|
Carte du conducteur
|
Carte de contrôleur
|
Carte d’atelier
|
Carte d’entreprise
|
|
|
Carte du conducteur
|
Carte du conducteur
|
Carte du conducteur (**)
|
Carte de contrôleur
|
Carte d’atelier
|
Carte d’entreprise
|
|
|
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’entreprise
|
Carte d’entreprise
|
Carte d’entreprise
|
Non disponible
|
Non disponible
|
Carte d’entreprise (*)
|
(*) 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’intermédiaire de l’interface ITS doivent être conformes aux exigences 12 et 13 de l’annexe IC, ainsi qu’à l’exigence relative au consentement du conducteur spécifiée au point 3.4 du présent appendice.
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 conducteur, le convoyeur ou les deux.
ITS_19
Au minimum, la liste des données classées comme étant obligatoires à 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 consentement 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’intermé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 conducteur 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 à caractè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’étalonnage, 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 à disposition
|
|
|
|
|
conducteur
|
convoyeur
|
|
|
|
VehicleIdentificationNumber
|
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
|
|
TachographVehicleSpeed
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
obligatoire
|
|
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
|
|
Driver1TimeRelatedStates
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
obligatoire
|
|
Driver2TimeRelatedStates
|
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
|
|
HighResolutionTotalVehicleDistance
|
ISO 16844-7
|
VU
|
sans caractère personnel
|
sans caractère personnel
|
consentement non requis
|
obligatoire
|
|
HighResolutionTripDistance
|
ISO 16844-7
|
VU
|
sans caractère personnel
|
sans caractère personnel
|
consentement non requis
|
obligatoire
|
|
ServiceComponentIdentification
|
ISO 16844-7
|
VU
|
sans caractère personnel
|
sans caractère personnel
|
consentement non requis
|
obligatoire
|
|
ServiceDelayCalendarTimeBased
|
ISO 16844-7
|
VU
|
sans caractère personnel
|
sans caractère personnel
|
consentement non requis
|
obligatoire
|
|
Driver1Identification
|
ISO 16844-7
|
Carte du conducteur
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
obligatoire
|
|
Driver2Identification
|
ISO 16844-7
|
Carte du conducteur
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
obligatoire
|
|
NextCalibrationDate
|
Appendice 8
|
VU
|
sans caractère personnel
|
sans caractère personnel
|
consentement non requis
|
obligatoire
|
|
Driver1ContinuousDrivingTime
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
obligatoire
|
|
Driver2ContinuousDrivingTime
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
obligatoire
|
|
Driver1CumulativeBreakTime
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
obligatoire
|
|
Driver2CumulativeBreakTime
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
obligatoire
|
|
Driver1CurrentDurationOfSelectedActivity
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
obligatoire
|
|
Driver2CurrentDurationOfSelectedActivity
|
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 conducteur
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
obligatoire
|
|
Driver2Name
|
ISO 16844-7
|
Carte du conducteur
|
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
|
|
Driver1CumulatedDrivingTimePreviousAndCurrentWeek
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
obligatoire
|
|
Driver2CumulatedDrivingTimePreviousAndCurrentWeek
|
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
|
|
RegisteringMemberState
|
Appendice 8
|
VU
|
sans caractère personnel
|
sans caractère personnel
|
consentement non requis
|
obligatoire
|
|
VehicleRegistrationNumber
|
Appendice 8
|
VU
|
sans caractère personnel
|
sans caractère personnel
|
consentement non requis
|
obligatoire
|
|
Driver1EndOfLastDailyRestPeriod
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2EndOfLastDailyRestPeriod
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1EndOfLastWeeklyRestPeriod
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2EndOfLastWeeklyRestPeriod
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1EndOfSecondLastWeeklyRestPeriod
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2EndOfSecondLastWeeklyRestPeriod
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1TimeLastLoadUnloadOperation
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2TimeLastLoadUnloadOperation
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1CurrentDailyDrivingTime
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2CurrentDailyDrivingTime
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1CurrentWeeklyDrivingTime
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2CurrentWeeklyDrivingTime
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1TimeLeftUntilNewDailyRestPeriod
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2TimeLeftUntilNewDailyRestPeriod
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1CardExpiryDate
|
ISO 16844-7
|
Carte du conducteur
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2CardExpiryDate
|
ISO 16844-7
|
Carte du conducteur
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1CardNextMandatoryDownloadDate
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2CardNextMandatoryDownloadDate
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
TachographNextMandatoryDownloadDate
|
ISO 16844-7
|
VU
|
sans caractère personnel
|
sans caractère personnel
|
consentement non requis
|
facultative
|
|
Driver1TimeLeftUntilNewWeeklyRestPeriod
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2TimeLeftUntilNewWeeklyRestPeriod
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1NumberOfTimes9hDailyDrivingTimesExceeded
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2NumberOfTimes9hDailyDrivingTimesExceeded
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1CumulativeUninterruptedRestTime
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2CumulativeUninterruptedRestTime
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1MinimumDailyRest
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2MinimumDailyRest
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1MinimumWeeklyRest
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2MinimumWeeklyRest
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1MaximumDailyPeriod
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2MaximumDailyPeriod
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1MaximumDailyDrivingTime
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2MaximumDailyDrivingTime
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1NumberOfUsedReducedDailyRestPeriods
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2NumberOfUsedReducedDailyRestPeriods
|
ISO 16844-7
|
VU
|
s.o.
|
à caractère personnel
|
consentement du convoyeur
|
facultative
|
|
Driver1RemainingCurrentDrivingTime
|
ISO 16844-7
|
VU
|
à caractère personnel
|
s.o.
|
consentement du conducteur
|
facultative
|
|
Driver2RemainingCurrentDrivingTime
|
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
|
»;
(39)l’appendice 14 est modifié comme suit:
(a)dans la table des matières, le point suivant est inséré après le point 5.4.8:
«5.5
Réservé pour une utilisation future»;
(b)au point 4.1.1.5, le paragraphe DCS_17 est remplacé par le texte suivant:
«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écanismes communs de sécurité” en vue de leur stockage temporaire 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.»;
(c)le point 5 est modifié comme suit:
i)au point 5.4.4, la séquence TachographPayload dans la définition du module ASN.1 pour les données DSRC dans l’application RTM est remplacée par le texte suivant:
|
‘TachographPayload ∷= SEQUENCE {
|
|
|
tp15638VehicleRegistrationPlate
|
LPN -- Plaque d’immatriculation des véhicules utilisant la structure de données de la norme ISO 14906, mais pour l’application RTM la LPN est fixée à 17 octets (pas de facteur de longueur)
|
|
tp15638SpeedingEvent
|
BOOLEAN, -- 1= Irrégularités de vitesse (cf. annexe IC)
|
|
tp15638DrivingWithoutValidCard
|
BOOLEAN,-- 1= Utilisation d’une carte invalide (cf. annexe IC)
|
|
tp15638DriverCard
|
BOOLEAN,-- 0= Désigne une carte de conducteur valide (cf. annexe IC)
|
|
tp15638CardInsertion
|
BOOLEAN, -- 1= Insertion de la carte pendant la conduite (cf. annexe IC)
|
|
tp15638MotionDataError
|
BOOLEAN, -- 1= Erreur sur les données de mouvement (cf. annexe IC)
|
|
tp15638VehicleMotionConflict
|
BOOLEAN, -- 1= Conflit concernant le mouvement du véhicule(cf. annexe IC)
|
|
tp156382ndDriverCard
|
BOOLEAN, -- 1= Deuxième carte de conducteur insérée (cf. annexe IC)
|
|
tp15638CurrentActivityDriving
|
BOOLEAN, -- 1= autre activité sélectionnée;
-- 0= conduite sélectionnée
|
|
tp15638LastSessionClosed
|
BOOLEAN, -- 1= session incorrectement clôturée, 0= session correctement clôturée
|
|
tp15638PowerSupplyInterruption
|
INTEGER (0..127), -- Coupures de l’alimentation électrique au cours des 10 derniers jours
|
|
tp15638SensorFault
|
INTEGER (0..255),-- eventFaultType conformément au dictionnaire des données
|
|
-- Tous les types liés à l’heure ultérieure tels que définis à l’annexe IC.
|
|
tp15638TimeAdjustment
|
INTEGER(0..4294967295), -- Heure de la dernière remise à l’heure
|
|
tp15638LatestBreachAttempt
|
INTEGER(0..4294967295), -- Heure de la dernière tentative d’infraction
|
|
tp15638LastCalibrationData
|
INTEGER(0..4294967295), -- Heure des données de dernier étalonnage
|
|
tp15638PrevCalibrationData
|
INTEGER(0..4294967295), -- Heure des données de l’étalonnage précédent
|
|
tp15638DateTachoConnected
|
INTEGER(0..4294967295), -- Date de connexion du tachygraphe
|
|
tp15638CurrentSpeed
|
INTEGER (0..255), -- Dernière vitesse actuelle enregistrée
|
|
tp15638Timestamp
|
INTEGER(0..4294967295) -- Horodatage de l’enregistrement actuel
|
|
tp15638LatestAuthenticatedPosition
|
INTEGER(0..4294967295), – Heure de la dernière position authentifiée
|
|
tp15638ContinuousDrivingTime
|
INTEGER (0..255), -- Temps de conduite continue du conducteur
|
|
tp15638DailyDrivingTimeShift
|
INTEGER (0..255), -- Temps de conduite journalier le plus long du conducteur pour la période de travail RTM en cours et la précédente
|
|
tp15638DailyDrivingTimeWeek
|
INTEGER (0..255), -- Temps de conduite journalier le plus long du conducteur pour la semaine en cours
|
|
tp15638WeeklyDrivingTime
|
INTEGER (0..255), -- Temps de conduite hebdomadaire du conducteur
|
|
tp15638FortnightlyDrivingTime
}
|
INTEGER (0..255) -- Temps de conduite bihebdomadaire du conducteur
|
»;
ii)au point 5.4.5, le tableau 14.3 est remplacé par le tableau suivant:
«
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 tp15638VehicleRegistrationPlate provenant de la valeur enregistrée du type de données
VehicleRegistrationIdentification tel que
défini à l’appendice 1 VehicleRegistrationIdentification
|
Plaque d’immatriculation du véhicule
exprimée par une chaîne de caractères
|
tp15638VehicleRegistrationPlate LPN,
--Immatriculation du véhicule
Plaque utilisant la structure de données de la norme ISO 14906, mais avec la limite suivante pour l’application RTM;
SEQUENCE commence par le code pays, suivi d’un indicateur 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 correspondent au numéro d’immatriculation “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 tp15638SpeedingEvent est calculée par la VU d’après le nombre d’événements “Excès de vitesse” (tel que défini à l’annexe IC) enregistrés dans la VU au cours des 10 derniers jours d’occurrence.
|
1 (TRUE): si l’événement “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,
|
|
RTM3
Conduite sans
carte valide
|
La VU génère une valeur booléenne
pour l’élément de données RTM3
tp15638DrivingWithoutValidCard.
La VU attribue une valeur TRUE à la variable tp15638DrivingWithoutValidCard 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énement “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.
|
tp15638DrivingWithoutValidCard
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 conducteur 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 “Insertion 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énement “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énement “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,
|
|
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 tp15638VehicleMotionConflict si au moins un événement “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énement “Conflit concernant le mouvement du véhicule” 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
|
tp15638CurrentActivityDriving
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
|
|
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 tp15638PowerSupplyInterruption une valeur égale au nombre d’événements “Coupure d’alimentation électrique” (tels que définis à l’annexe IC) enregistré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.
|
tp15638PowerSupplyInterruption
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 anomalies 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 anomalies du capteur 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.
– 6 si à la fois des anomalies 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.
|
-- erreur de capteur un octet conformément au dictionnaire des données
|
tp15638SensorFault INTEGER (0..255),
|
|
RTM13
Remise à l’heure
|
La VU génère une valeur indiquée par un nombre entier (timeReal de l’appendice 1) pour l’élément de données RTM13, en fonction de la présence de 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’appendice 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 tentative d’infraction à la sécurité enregistrée par la VU.
Si aucun événement “Tentative 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),
|
|
RTM15
Dernier étalonnage
|
La VU génère une valeur indiquée par un nombre entier (timeReal de l’appendice 1) pour l’élément de données RTM15, en fonction de la présence de données de dernier é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’étalonnage.
|
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’appendice 1) pour l’élément de données RTM16, en fonction de l’enregistrement d’étalonnage précédant celui du dernier étalonnage.
La VU doit attribuer à RTM15 la valeur
oldTimeValue de l’enregistrement d’étalonnage précédant celui du dernier étalonnage.
Si aucun étalonnage n’a été effectué précédemment, la VU attribue la valeur 0 à RTM16.
|
oldTimeValue de l’enregistrement 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’appendice 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 considéré.
La VU extrait ces données des VuCalibrationData (appendice 1) des vuCalibrationRecords, où CalibrationPurpose est égal à: ’03’H
Si aucun étalonnage n’a été effectué précédemment, la VU attribue la valeur 0 à RTM17.
|
Date du premier étalonnage de l’unité embarquée sur le véhicule considéré.
|
tp15638DateTachoConnected
INTEGER(0..4294967295),
|
|
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’enregistrement
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’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 authentifiée du véhicule était disponible auprès du récepteur GNSS.
Si aucune position authentifiée du véhicule n’était disponible auprès du récepteur GNSS, la VU attribue la valeur 0 à RTM20.
|
Horodatage de la dernière position authentifiée du véhicule
|
tp15638LatestAuthenticatedPosition
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.
|
tp15638ContinuousDrivingTime INTEGER(0..255),
|
|
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’appendice 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 journalières du conducteur, soit celle de la période de travail RTM en cours, soit celle de la précédente.
|
Temps de conduite journalier 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 à 1000 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 journaliè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 journalier 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 à 1000 minutes.
Les valeurs 251 à 254 ne sont pas utilisées.
La valeur 255 indique que les informations ne sont pas disponibles.
|
tp15638DailyDrivingTimeWeek INTEGER(0..255),
|
|
RTM24
Temps de conduite hebdomadaire, 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 RTM24.
La VU attribue comme valeur pour l’élément RTM24 le temps de conduite hebdomadaire 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 à 5000 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),
|
|
RTM25
Temps de conduite bihebdomadaire, 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 RTM25.
La VU attribue comme valeur pour l’élément RTM25 le temps de conduite bihebdomadaire 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 à 7500 minutes.
Les valeurs 251 à 254 ne sont pas utilisées.
La valeur 255 indique que les informations ne sont pas disponibles.
|
tp15638FortnightlyDrivingTime INTEGER(0..255),
|
Remarque: les éléments RTM22, RTM23, RTM24 et RTM25 sont calculés conformément à l’addendum au présent appendice.»;
iii)au point 5.4.7, le tableau 14.9 est remplacé par le tableau suivant:
«
Tableau 14.9
Initialisation – Exemple de contenu de la trame VST
|
Octet #
|
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 application
|
|
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.
|
|
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
|
»;
iv)le point 5.5 suivant est inséré:
«5.5
Réservé pour une utilisation future»;
v)au point 5.7, les paragraphes DSC_77 et DSC_78 sont remplacés par le texte suivant:
«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’horodatage. Le VUSM vérifie que les données ont bien été transmises à la DSRC-VU.
DSC_78
Réservé pour une utilisation future.»;
(d)l’addendum suivant est ajouté:
«
ADDENDUM
Règles pour le calcul des temps de conduite journaliers, hebdomadaires et bihebdomadaires
1.
Règles de calcul de base
La VU calcule les temps de conduite journaliers, hebdomadaires et bihebdomadaires 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écessaire 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 transmission 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;
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
–
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)”, conformé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é.
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’activation 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 produisant 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 journalier 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é.
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.
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 bihebdomadaires. 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.»;
(40)l’appendice 15 est modifié comme suit:
(a)le titre est remplacé par le titre suivant:
«
Appendice 15
MIGRATION: GÉRER LA COEXISTENCE DE PLUSIEURS GÉNÉRATIONS ET VERSIONS D’ÉQUIPEMENTS»;
(b)la table des matières est modifiée comme suit:
i)le point 2.2 est remplacé par le texte suivant:
«2.2.
Interopérabilité entre les unités embarquées sur véhicule et les cartes»;
ii)le point 5 suivant est ajouté:
«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»;
(c)les points 2 à 4 sont remplacés par le texte suivant:
«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.
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º 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ération peuvent continuer à être utilisées dans les unités embarquées sur les véhicules de deuxième génération, indépendamment 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 possibilité 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éhicules 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épendamment 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.
MIG_008
Les capteurs de mouvement de deuxième génération pourront être couplés et utilisés soit uniquement avec des unités embarquées sur les véhicules de deuxième génération, indépendamment 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 tachygraphiques d’une génération qui ont été insérées dans les lecteurs de cartes, selon les mécanismes de sécurité et les protocoles de téléchargement des données de cette géné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_Certificate 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é embarquée sur le véhicule exactement de la même manière qu’une carte de première génération. Les données téléchargées auront le même format que les données téléchargées depuis une carte de première génération.
MIG_013
Les données sont téléchargées depuis une carte de première génération insérée dans une unité embarquée sur un véhicule de deuxième génération, indépendamment de la version, selon le protocole de téléchargement de données défini à l’appendice 7 de la présente annexe. L’unité embarquée sur le véhicule adressera des commandes à la carte exactement de la même manière qu’une unité embarquée sur un véhicule de première génération. Les données téléchargées auront le format défini pour les cartes de première génération.
2.4.3
Téléchargement d’unité embarquée sur un véhicule
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épendamment 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’équipement 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 LANCEMENT
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 mouvement de première génération tant qu’ils resteront utilisés sur le terrain, de façon à pouvoir remplacer les composants qui dysfonctionneraient.
MIG_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 embarqué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é.»;
(d)le point 5 suivant est ajouté:
«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èglement (UE) nº 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º 165/2014 et à l’exigence 50 de l’annexe IB du règlement (CEE) nº 3821/85.»;
(41)à l’appendice 16, le paragraphe ADA_012 est remplacé par le texte suivant:
«ADA_012
L’interface d’entrée de l’adaptateur peut, le cas échéant, multiplier 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 (2400 à 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.».
