(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:
|
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
|
|
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):
$--RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
2)
|
Statut, A= Position valide, V= Avertissement
|
7)
|
Vitesse sur le fond en nœuds
|
8)
|
Route suivie, degrés vrais
|
10)
|
Variation magnétique, degrés
|
12)
|
Indicateur de mode FAA
|
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):
$--AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
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)
|
7)
|
Vitesse sur le fond en nœuds
|
8)
|
Route suivie, degrés vrais
|
10)
|
Variation magnétique, degrés
|
12)
|
Indicateur de mode FAA
|
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).
$--GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh
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
|
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.
$--ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh
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
|
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.
|
|
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.»;
|
|
|
|
|