30.7.2021   

FR

Journal officiel de l’Union européenne

L 273/1


RÈGLEMENT D’EXÉCUTION (UE) 2021/1228 DE LA COMMISSION

du 16 juillet 2021

modifiant le règlement d’exécution (UE) 2016/799 en ce qui concerne les exigences applicables à la construction, aux essais, à l’installation, à l’utilisation et à la réparation des tachygraphes intelligents et de leurs composants

(Texte présentant de l’intérêt pour l’EEE)

LA COMMISSION EUROPÉENNE,

vu le traité sur le fonctionnement de l’Union européenne,

vu le règlement (UE) no 165/2014 du Parlement européen et du Conseil du 4 février 2014 relatif aux tachygraphes dans les transports routiers (1), et notamment son article 11,

considérant ce qui suit:

(1)

Le règlement (UE) no 165/2014 a instauré le tachygraphe intelligent, connecté au système mondial de navigation par satellite (ci-après «GNSS») et comprenant un dispositif de communication à distance à des fins de détection précoce et une interface avec les systèmes de transport intelligents.

(2)

Les exigences techniques applicables à la construction, aux essais, à l’installation, à l’utilisation et à la réparation des tachygraphes et de leurs composants sont définies dans le règlement d’exécution (UE) 2016/799 de la Commission (2).

(3)

Le règlement (UE) no 165/2014 et le règlement (CE) no 561/2006 du Parlement européen et du Conseil (3) ont été modifiés par le règlement (UE) 2020/1054 du Parlement européen et du Conseil (4). Conformément au règlement (UE) 2020/1054, le tachygraphe intelligent doit intégrer des fonctionnalités supplémentaires. Il convient dès lors de définir une nouvelle version du tachygraphe intelligent en modifiant le règlement d’exécution (UE) 2016/799.

(4)

Conformément à l’article 8, paragraphe 1, du règlement (UE) no 165/2014, la position du véhicule devrait être enregistrée automatiquement chaque fois que le véhicule franchit la frontière d’un État membre et chaque fois que le véhicule effectue des opérations de chargement ou de déchargement.

(5)

L’interface avec les systèmes de transport intelligents, qui est facultative dans la version du tachygraphe intelligent mise en œuvre depuis le 15 juin 2019, devrait être obligatoire pour la nouvelle version du tachygraphe intelligent.

(6)

La nouvelle version du tachygraphe intelligent devrait être conçue pour authentifier le signal satellitaire Galileo dès que le système Galileo sera opérationnel.

(7)

Afin d’éviter le remplacement physique de l’appareil de contrôle lorsqu’une modification des spécifications techniques du tachygraphe est adoptée, il est nécessaire de veiller à ce que les futures fonctionnalités du tachygraphe puissent être mises en œuvre et améliorées grâce à des mises à jour logicielles.

(8)

Le règlement d’exécution (UE) 2016/799 permet l’installation d’un adaptateur entre le capteur de mouvement et le tachygraphe pour les véhicules qui, bien qu’ayant un poids inférieur à 3,5 tonnes, peuvent parfois dépasser ce seuil, par exemple lorsqu’ils tractent une remorque. À la suite de la modification du règlement (CE) no 561/2006, l’obligation d’installer un tachygraphe a été étendue aux véhicules de plus de 2,5 tonnes. L’installation obligatoire du tachygraphe intelligent dans les véhicules utilitaires légers rend nécessaire le renforcement du niveau de sécurité offert par l’adaptateur en installant un capteur interne à l’intérieur du tachygraphe, indépendant du signal du capteur de mouvement.

(9)

Les mesures prévues par le présent règlement sont conformes à l’avis du comité institué par l’article 42, paragraphe 1, du règlement (UE) no 165/2014,

A ADOPTÉ LE PRÉSENT RÈGLEMENT:

Article premier

L’annexe IC du règlement d’exécution (UE) 2016/799 est modifiée conformément à l’annexe du présent règlement.

Article 2

Entrée en vigueur

Le présent règlement entre en vigueur le vingtième jour suivant celui de sa publication au Journal officiel de l’Union européenne.

Il est applicable à partir du 21 août 2023.

Le présent règlement est obligatoire dans tous ses éléments et directement applicable dans tout État membre.

Fait à Bruxelles, le 16 juillet 2021.

Par la Commission

La présidente

Ursula VON DER LEYEN


(1)  JO L 60 du 28.2.2014, p. 1.

(2)  Règlement d'exécution (UE) 2016/799 de la Commission du 18 mars 2016 mettant en œuvre le règlement (UE) no 165/2014 du Parlement européen et du Conseil en ce qui concerne les exigences applicables à la construction, aux essais, à l'installation, à l'utilisation et à la réparation des tachygraphes et de leurs composants (JO L 139 du 26.5.2016, p. 1).

(3)  Règlement (CE) no 561/2006 du Parlement européen et du Conseil du 15 mars 2006 relatif à l’harmonisation de certaines dispositions de la législation sociale dans le domaine des transports par route, modifiant les règlements (CEE) no 3821/85 et (CE) no 2135/98 du Conseil et abrogeant le règlement (CEE) no 3820/85 du Conseil (JO L 102 du 11.4.2006, p. 1).

(4)  Règlement (UE) 2020/1054 du Parlement européen et du Conseil du 15 juillet 2020 modifiant le règlement (CE) no 561/2006 en ce qui concerne les exigences minimales relatives aux durées maximales de conduite journalière et hebdomadaire et à la durée minimale des pauses et des temps de repos journalier et hebdomadaire, et le règlement (UE) no 165/2014 en ce qui concerne la localisation au moyen de tachygraphes (JO L 249 du 31.7.2020, p. 1).


ANNEXE

L’annexe IC du règlement d’exécution (UE) 2016/799 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) no 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 (1),»;

(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) no 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) no 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 2 400 et 25 000 imp/km, mesurer la vitesse avec une tolérance de ± 1 km/h (à vitesse constante).

Remarque: la résolution du stockage des données entraîne une tolérance additionnelle de ± 0,5 km/h sur la vitesse stockée par l’appareil de contrôle.»;

(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 2 190 conducteurs ou convoyeurs, 2190 cycles d’insertion/retrait de cartes et 93 440 changements d’activité,

le nombre moyen de saisies de lieux par jour est défini comme au moins 6 saisies correspondant aux lieux où commence la période de travail journalière et 6 saisies correspondant aux lieux où se termine la période de travail journalière, de sorte qu’au moins 4 380 saisies de lieux sont comprises dans ces “365 jours”,

le nombre moyen de positions par jour lorsque le temps de conduite accumulé atteint un multiple de trois heures est défini comme au moins à 6 positions, de sorte qu’au moins 2 190 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) no 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) no 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) no 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:

«

Image 1

»;

(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) no 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).

Image 2

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).

Image 3

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).

Image 4

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).

Image 5

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).

Image 6

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).

Image 7

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).

Image 8

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’HIndex des modifications concernant l’utilisation des éléments d’information définis pour la structure donnée par l’octet de poids fort.

 

‘00’H pour les applications de génération 1

 

‘00’H pour la version 1 des applications de génération 2

 

‘01’H pour la version 2 des applications de génération 2»;

(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).

Image 9

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).

Image 10

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.

Image 11

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).

Image 12

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

Image 13

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’H

absence d’informations complémentaires,

‘01’H

insertion d’une carte non valable,

‘02’H

conflit de carte,

‘03’H

chevauchement temporel,

‘04’H

conduite sans carte appropriée,

‘05’H

insertion de carte en cours de conduite,

‘06’H

dernière session incorrectement clôturée,

‘07’H

excès de vitesse,

‘08’H

coupure d’alimentation électrique,

‘09’H

erreur sur les données de mouvement,

‘0A’H

conflit concernant le mouvement du véhicule,

‘0B’H

conflit temporel (GNSS contre l’horloge interne de la VU),

‘0C’H

erreur de communication avec le dispositif de communication à distance,

‘0D’H

absence d’informations de positionnement en provenance du récepteur GNSS,

‘0E’H

erreur de communication avec le dispositif GNSS externe,

‘0F’H

anomalie GNSS,

‘1x’H

tentatives d’atteinte à la sécurité en rapport avec l’unité embarquée sur véhicule,

‘10’H

absence d’informations complémentaires,

‘11’H

défaut d’authentification du capteur de mouvement,

‘12’H

défaut d’authentification d’une carte tachygraphique,

‘13’H

remplacement sans autorisation du capteur de mouvement,

‘14’H

défaut d’intégrité affectant la saisie de données sur la carte,

‘15’H

défaut d’intégrité affectant les données utilisateur mémorisées,

‘16’H

erreur de transfert de données internes,

‘17’H

ouverture illicite d’un boîtier,

‘18’H

sabotage du matériel,

‘19’H

détection de violation du dispositif GNSS,

‘1A’H

défaut d’authentification du dispositif GNSS externe,

‘1B’H

expiration du certificat du dispositif GNSS externe,

‘1C’H

Divergence entre les données de mouvement et les données enregistrées relatives à l’activité du conducteur,

‘1D’H à ‘1F’H

RFU,

‘2x’H

tentatives d’atteinte à la sécurité en rapport avec le capteur de mouvement,

‘20’H

absence d’informations complémentaires,

‘21’H

échec d’une authentification,

‘22’H

défaut d’intégrité affectant les données mémorisées,

‘23’H

erreur de transfert de données internes,

‘24’H

ouverture illicite d’un boîtier,

‘25’H

sabotage du matériel,

‘26’H à ‘2F’H

RFU,

‘3x’H

anomalies affectant l’appareil de contrôle,

‘30’H

absence d’informations complémentaires,

‘31’H

anomalie interne affectant la VU,

‘32’H

anomalie affectant l’imprimante,

‘33’H

anomalie affectant l’affichage,

‘34’H

anomalie affectant le téléchargement,

‘35’H

anomalie affectant le capteur de mouvement,

‘36’H

récepteur du dispositif GNSS interne,

‘37’H

dispositif GNSS externe,

‘38’H

dispositif de communication à distance,

‘39’H

interface ITS,

‘3A’H

anomalie du capteur interne,

‘3B’H à ‘3F’H

RFU,

‘4x’H

anomalies affectant une carte,

‘40’H

absence d’informations complémentaires,

‘41’H à ‘4F’H

RFU,

‘50’H à ‘7F’H

RFU,

‘80’H à ‘FF’H

propre au fabricant.»;

(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).

Image 14

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).

Image 15

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).

Image 16

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).

Image 17

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.

Image 18

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.

Image 19

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.

Image 20

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.

Image 21

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.

Image 22

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.

Image 23

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:

Image 24

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).

Image 25

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:

Image 26

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).

Image 27 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.

Image 28

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:

Image 29

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.

Image 30

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).

Image 31

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).

Image 32

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).

Image 33

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).

Image 34

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.

Image 35

»;

(kk)

au point 2.205, le texte se rapportant à la génération 2 est remplacé par le texte suivant:

«Génération 2:

Image 36

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).

Image 37

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).

Image 38

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).

Image 39

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.

Image 40

»;

(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).

Image 41

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).

Image 42

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).

Image 43

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:

«

Image 44

»;

2)

la ligne correspondant à LastCardDownload est remplacée par le texte suivant:

«

Image 45

»;

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.

Image 46

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:

Image 47

Image 48

Image 49

»;

3)

au paragraphe TCS_155, le tableau est remplacé par le tableau suivant:

«

 

 

 

 

 

 

Min

Max

n1

NoOfEventsPerType

12

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.

Image 50

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:

«

Image 51

Image 52

Image 53

Image 54

»;

3)

au paragraphe TCS_163, le tableau est remplacé par le tableau suivant:

«

 

 

 

 

 

 

Min

Max

n1

NoOfEventsPerType

3

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.

Image 55

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:

«

Image 56

Image 57

»;

3)

au paragraphe TCS_171, le tableau est remplacé par le tableau suivant:

«

 

 

 

 

 

 

Min

Max

n7

NoOfControlActivityRecords

230

520

n13

VuConfigurationLengthRange

3072 octets

3072 octets

»;

vi)

le point 4.5.2 est modifié comme suit:

1)

le paragraphe TCS_176 est remplacé par le texte suivant:

«TCS_176

Après personnalisation, l’application de la carte d’entreprise de génération 2 doit avoir la structure de fichier et les conditions d’accès au fichier permanentes suivantes:

Remarques:

l’identificateur d’EF court SFID est communiqué sous la forme d’un nombre décimal, par exemple la valeur 30 correspond au nombre binaire 11110.

EF Application_Identification_V2, et EF VU_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.

Image 58

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:

«

Image 59

»;

3)

au paragraphe TCS_179, le tableau est remplacé par le tableau suivant:

«

 

 

 

 

 

 

Min

Max

n8

NoOfCompanyActivityRecords

230

520

n13

VuConfigurationLengthRange

3072 octets

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

Image 60

Hors limites

Image 61

Trajet en ferry/train

Image 62

Opération de chargement

Image 63

Opération de déchargement

Image 64

Opération de chargement/déchargement simultanés

Image 65

Type de charge: passagers

Image 66

Type de charge: biens

Image 67

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:

« Image 68

Sécurité/données authentifiées/scellements»;

2)

le pictogramme suivant est ajouté:

« Image 69

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»:

 

«

Image 70

Position où le véhicule a franchi la frontière entre deux pays

Image 71

Position où une opération de chargement a eu lieu

Image 72

Position où une opération de déchargement a eu lieu

Image 73

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:

« Image 74

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:

« Image 75

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 Image 76 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:

«

Image 77

Image 78

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:

«

Image 79

»;

v)

le bloc 5 est remplacé par le bloc suivant:

«

Image 80

»;

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:

«

Image 81

»;

viii)

le bloc 8.2 est remplacé par le bloc suivant:

«

Image 82

»;

ix)

le bloc 10.2 est remplacé par le bloc suivant:

«

Image 83

»;

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:

«

Image 84

Image 85

Image 86

Image 87

»;

xii)

le bloc 14 est remplacé par le bloc suivant:

«

Image 88

»;

xiii)

le bloc 15.1 est remplacé par le bloc suivant:

«

Image 89

»;

xiv)

les blocs 16 et 16.1 sont remplacés par le texte suivant:

«

16

Identification du GNSS*

Image 90

Image 91

Image 92

Image 93

»;

xv)

le bloc 17.1 est remplacé par le bloc suivant:

«

Image 94

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:

«

Image 95 »;

(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:

Image 96 »;

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:

Image 97 »;

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:

Image 98 »;

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:

Image 99 »;

(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:

Image 100 »;

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)

Élément de données

 

Commentaire

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)

Élément de données

 

Commentaire

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

 

Image 101

Image 102

»;

(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

Secondes

gain 0,25 s/bit, décalage 0 s

0 à 59,75 s

2

Procès-verbal

gain 1 min/bit, décalage 0 min

0 à 59 min

3

Heures

gain 1 h/bit, décalage 0 h

0 à 23 h

4

Mois

gain 1 mois/bit, décalage 0 mois

1 à 12 mois

5

Jour

gain 0,25 jour/bit, décalage 0 jour (voir ci-après la remarque du tableau 41)

0,25 à 31,75 jours

6

Année

gain 1 année/bit, décalage année + 1985

(voir remarque ci-dessous au tableau 41)

années 1985 à 2235

7

Correction locale des minutes

gain 1 min/bit, décalage – 125 min

– 59 à + 59 min

8

Correction locale des heures

gain 1 h/bit, décalage –125 h

– 23 à + 23 h

CPR_076

Le tableau 41 expose en détail les structures des différents octets du paramètre NextCalibrationDate:

Tableau 41

Structure détaillée de NextCalibrationDate (valeur de recordDataIdentifier # F922)

Octet

Définition du paramètre

Résolution

Gamme opérationnelle

1

Mois

gain 1 mois/bit, décalage 0 mois

1 à 12 mois

2

Jour

gain 0,25 jour/bit, décalage 0 jour (voir la remarque ci-après)

0,25 à 31,75 jours

3

Année

gain 1 année/bit, décalage année + 1985

(voir la remarque ci-dessous)

années 1985 à 2235

Note concernant l’utilisation du paramètre «Jour»:

1)

Une valeur de 0 pour la date est nulle. Les valeurs 1, 2, 3 et 4 servent à identifier le premier jour du mois; les valeurs 5, 6, 7 et 8 indiquent le deuxième jour du mois; etc.

2)

Ce paramètre n’influence pas ni ne modifie le paramètre des heures précité.

Remarque concernant l’utilisation du paramètre «Année»:

Une valeur ‘0’ pour l’année identifie l’année 1985; une valeur ‘1’ identifie 1986; etc.

CPR_078

Le tableau 42 expose en détail la structure des différents octets du paramètre VehicleRegistrationNumber:

Tableau 42

Structure détaillée de VehicleRegistrationNumber (valeur recordDataIdentifier # F97E)

Octet

Définition du paramètre

Résolution

Gamme opérationnelle

1

Page de code (telle que définie à l’appendice 1)

sans objet

VehicleRegistrationNumber

2 – 14

Numéro d’immatriculation du véhicule (tel que défini à l’appendice 1)

sans objet

VehicleRegistrationNumber

CPR_090

Le tableau 43 expose en détail les structures des différents octets du paramètre SealDataVu:

Tableau 43

Structure détaillée de SealDataVu (valeur recordDataIdentifier # F9D3)

Octet

Définition du paramètre

Résolution

Gamme opérationnelle

1 – 11

sealRecord1. Structure SealRecord (telle que définie à l’appendice 1)

sans objet

SealRecord

12 - 22

sealRecord2. Structure SealRecord (telle que définie à l’appendice 1)

sans objet

SealRecord

23 – 33

sealRecord3. Structure SealRecord (telle que définie à l’appendice 1)

sans objet

SealRecord

34 – 44

sealRecord4. Structure SealRecord (telle que définie à l’appendice 1)

sans objet

SealRecord

45 – 55

sealRecord5. Structure SealRecord (telle que définie à l’appendice 1)

sans objet

SealRecord

REMARQUE: S’il existe moins de 5 scellements 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

loadType

‘00’H: Type de charge non défini

‘01’H: Biens

‘02’H: Passagers

sans objet

‘00’H à ‘02’H

CPR_092

Le tableau 45 expose en détail les structures des différents octets des paramètres VuSerialNumber, 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

VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber et RemoteCommunicationModuleSerialNumber:

 

structure ExtendedSerialNumber telle que définie à l’appendice 1.

sans objet

ExtendedSerialNumber

CPR_093

Le tableau 46 expose en détail les structures des différents octets du paramètre TachographCardsGen1Suppression:

Tableau 46

Structure détaillée de TachographCardsGen1Suppression (valeur recordDataIdentifier # F9D6)

Octet

Définition du paramètre

Résolution

Gamme opérationnelle

1-2

TachographCardsGen1Suppression. Structure TachographCardsGen1Suppression telle que définie à l’appendice 1.

sans objet

‘0000’H, ‘A5E3’H

CPR_094

Le tableau 47 expose en détail les structures des différents octets du paramètre VehiclePosition.

Tableau 47

Structure détaillée de VehiclePosition (valeur recordDataIdentifier # F9D7)

Octet

Définition du paramètre

Résolution

Gamme opérationnelle

1 - 4

L’horodatage du moment où la position du véhicule a été déterminée.

Sans objet

TimeReal

5

Précision GNSS

Sans objet

GNSSAccuracy

6 - 11

Position du véhicule

Sans objet

GeoCoordinates

12

Statut d’authentification

Sans objet

PositionAuthenticationStatus

13

Pays actuel

Sans objet

NationNumeric

14

Région actuelle

Sans objet

RegionNumeric

Remarque: après l’actualisation de la position du véhicule, la mise à jour du pays et de la région actuels peut être retardée.»;

(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

Essai

Description

Exigences connexes

1.

Examen administratif

1.1

Documentation

Exactitude de la documentation

 

2

Essais généraux

2.1

Démarrage OSNMA très chaud

Objectif: vérifier que le récepteur GNSS calcule une position avec OSNMA après un démarrage très chaud.

Procédure:

 

Le récepteur GNSS démarre dans des conditions de démarrage GNSS et OSNMA très chaudes et acquiert les signaux des satellites Galileo visibles.

 

Le récepteur authentifie les données de navigation Galileo avec OSNMA (ADKD = 0) et fournit une position avec des données authentifiées.

 

Critères de réussite et d’échec: le récepteur calcule un point de repère authentifié dans un délai de 160 secondes.

Appendice 12,

GNS_3 ter

2.2

Démarrage OSNMA chaud:

Objectif: vérifier que le récepteur GNSS calcule une position avec OSNMA après un démarrage très chaud.

Procédure:

 

Avant de commencer l’essai, les éphémérides et la KROOT doivent être effacées de la mémoire du ré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

2.3

Démarrage OSNMA chaud avec SLMAC

Objectif: vérifier que le récepteur GNSS calcule une position avec OSNMA après un démarrage chaud avec une initialisation temporelle nécessitant le mode SLMAC, tel que défini dans les lignes directrices concernant les récepteurs OSNMA.

Procédure:

 

La réalisation temporelle du récepteur interne doit être configurée de manière à avoir une incertitude 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

2.4

Démarrage OSNMA très chaud avec un signal répété

Objectif: vérifier que le récepteur GNSS détecte un signal répété.

Procédure:

 

Le récepteur GNSS démarre dans des conditions de démarrage GNSS et OSNMA très chaudes et acquiert les signaux des satellites Galileo visibles.

 

Le récepteur authentifie les données de navigation Galileo avec OSNMA (ADKD = 0) et fournit une position avec des données authentifiées.

 

Une fois que le récepteur fournit une solution PVT avec des données authentifiées, il est éteint.

 

Un signal répété avec un retard de 40 secondes par rapport au signal précédent est simulé, et le récepteur est allumé.

 

Le récepteur détecte que le temps du système Galileo à partir du temps du signal dans l’espace et la réalisation de la synchronisation locale ne satisfont pas à l’exigence de synchronisation et qu’il cesse de traiter les données OSNMA telles que définies dans les lignes directrices concernant les récepteurs OSNMA.

 

Critères de réussite et d’échec: le récepteur détecte le signal répété et ne calcule pas une position valide authentifiée depuis le début de la répétition jusqu’à la fin de l’essai.

Appendice 12,

GNS_3 ter

2.5

Démarrage OSNMA très chaud avec des données erronées

Objectif: vérifier que OSNMA détecte les données 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):

Image 103

$--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 no 2):

Image 104

$--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).

Image 105

$--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.

Image 106

$--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.

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.

Image 107

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:

GnssDistance > [OdometerDifference × OdometerToleranceFactor + Minimum(SlipDistanceUpperlimit; (OdometerDifference × SlipFactor)) + GnssTolerance + FerryTrainDistance]

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) no 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.

Image 108

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  (*2)

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  (*1)

Non disponible

Non disponible

Carte d’atelier

Carte d’atelier

Carte d’atelier

Non disponible

Carte d’atelier  (*1)

Non disponible

Carte d’entreprise

Carte d’entreprise

Carte d’entreprise

Non disponible

Non disponible

Carte d’entreprise  (*1)

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:

«

Image 109

»;

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 à 1 000  minutes.

Les valeurs 251 à 254 ne sont pas utilisées.

La valeur 255 indique que les informations ne sont pas disponibles.

tp15638DailyDrivingTimeShift INTEGER(0..255),

RTM23

Temps de conduite journalier le plus long pour la semaine en cours, calculé conformément à l’addendum à l’appendice 14

La VU génère une valeur exprimée par un nombre entier pour l’élément de données RTM23.

La VU attribue comme valeur pour l’élément RTM23 la période de conduite 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 à 1 000  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 à 5 000  minutes.

Les valeurs 251 à 254 ne sont pas utilisées.

La valeur 255 indique que les informations ne sont pas disponibles.

tp15638WeeklyDrivingTime INTEGER(0..255),

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 à 7 500  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.

Image 110

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”.

Image 111

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.

Image 112

Image 113

Image 114

Image 115

Image 116

Image 117

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) no 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) no 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) no 165/2014 et à l’exigence 50 de l’annexe IB du règlement (CEE) no 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 (2 400 à 25 000 impulsions/km). Ce facteur fixe ne peut être programmé que par le fabricant de l’adaptateur et l’atelier agréé qui effectue l’installation de l’adaptateur.».


(1)  Règlement (UE) 2018/858 du Parlement européen et du Conseil du 30 mai 2018 relatif à la réception et à la surveillance du marché des véhicules à moteur et de leurs remorques, ainsi que des systèmes, composants et entités techniques distinctes destinés à ces véhicules, modifiant les règlements (CE) no 715/2007 et (CE) no 595/2009 et abrogeant la directive 2007/46/CE (JO L 151 du 14.6.2018, p. 1).

(*1)  La connexion ITS Bluetooth® est attribuée à la carte tachygraphique dans le lecteur «conducteur» de la VU.

(*2)  L’utilisateur sélectionne la carte à laquelle la connexion ITS Bluetooth® doit être attribuée (insérée dans le lecteur «conducteur» ou «convoyeur»).