EUR-Lex Document 02016R0799-20230821

Il presente testo è un semplice strumento di documentazione e non produce alcun effetto giuridico. Le istituzioni dell’Unione
non assumono alcuna responsabilità per i suoi contenuti. Le versioni facenti fede degli atti pertinenti, compresi i loro
preamboli, sono quelle pubblicate nella Gazzetta ufficiale dell’Unione europea e disponibili in EUR-Lex. Tali testi ufficiali
sono direttamente accessibili attraverso i link inseriti nel presente documento
►B REGOLAMENTO DI ESECUZIONE (UE) 2016/799 DELLA COMMISSIONE
del 18 marzo 2016
che applica il regolamento (UE) n. 165/2014 del Parlamento europeo e del Consiglio recante le
prescrizioni per la costruzione, il collaudo, il montaggio, il funzionamento e la riparazione dei
tachigrafi e dei loro componenti
(Testo rilevante ai fini del SEE)
(GU L 139 del 26.5.2016, pag. 1)
Modificato da:
Gazzetta ufficiale
n. pag. data
►M1 Regolamento di esecuzione (UE) 2018/502 della Commissione del
28 febbraio 2018
L 85 1 28.3.2018
►M2 Regolamento di esecuzione (UE) 2020/158 della Commissione del
5 febbraio 2020
L 34 20 6.2.2020
►M3 Regolamento di esecuzione (UE) 2021/1228 della Commissione del
16 luglio 2021
L 273 1 30.7.2021
►M4 Regolamento di esecuzione (UE) 2023/980 della Commissione del
16 maggio 2023
L 134 28 22.5.2023
Rettificato da:
►C1 Rettifica, GU L 146 del 3.6.2016, pag. 31 (2016/799)
►C2 Rettifica, GU L 27 dell’1.2.2017, pag. 169 (2016/799)
02016R0799 — IT — 21.08.2023 — 003.002 — 1
02016R0799 — IT — 21.08.2023 — 003.002 — 2
REGOLAMENTO DI ESECUZIONE (UE) 2016/799 DELLA
COMMISSIONE
del 18 marzo 2016
che applica il regolamento (UE) n. 165/2014 del Parlamento europeo
e del Consiglio recante le prescrizioni per la costruzione, il collaudo,
il montaggio, il funzionamento e la riparazione dei tachigrafi e dei
loro componenti
(Testo rilevante ai fini del SEE)
Articolo 1
Oggetto e campo di applicazione
1. Il presente regolamento reca le disposizioni necessarie all'applica­
zione uniforme dei seguenti aspetti riguardanti i tachigrafi:
a) registrazione della posizione del veicolo in determinati punti nel
corso del periodo di lavoro giornaliero del conducente;
b) diagnosi precoce remota di eventuali manomissioni o uso improprio
dei tachigrafi intelligenti;
c) interfaccia con i sistemi di trasporto intelligenti;
d) le prescrizioni amministrative e tecniche per le procedure di omolo­
gazione dei tachigrafi, compresi i meccanismi di sicurezza.
▼M1
2. La costruzione, il collaudo, il montaggio, l’ispezione, il funziona­
mento e la riparazione dei tachigrafi intelligenti e dei loro componenti
devono avere luogo in conformità alle prescrizioni tecniche di cui
all’allegato IC del presente regolamento.
3. Per quanto riguarda la costruzione, il collaudo, il montaggio,
l’ispezione, il funzionamento e la riparazione, i tachigrafi diversi dai
tachigrafi intelligenti devono continuare a soddisfare, a seconda dei casi,
le prescrizioni dell’allegato I del regolamento (UE) n. 165/2014 o
dell’allegato IB del regolamento (CEE) n. 3821/85 del Consiglio ( 1 ).
▼B
4. A norma dell'articolo 10 quinquies della direttiva 96/53/CE, il
dispositivo di diagnosi precoce remota trasmette anche i dati sul peso
forniti da un sistema di pesatura interno di bordo, ai fini della rapida
individuazione delle frodi.
▼M1
5. Il presente regolamento non pregiudica le disposizioni della diret­
tiva 2014/53/UE del Parlamento europeo e del Consiglio ( 2 ).
▼B
Articolo 2
Definizioni
Ai fini del presente regolamento si applicano le definizioni di cui al­
l'articolo 2 del regolamento (UE) n. 165/2014.
▼B
( 1 ) Regolamento (CEE) n. 3821/85 del Consiglio, del 20 dicembre 1985, relativo
all'apparecchio di controllo nel settore dei trasporti su strada (GU L 370 del
31.12.1985, pag. 8).
( 2 ) Direttiva 2014/53/UE del Parlamento europeo e del Consiglio, del 16 aprile
2014, concernente l'armonizzazione delle legislazioni degli Stati membri re­
lative alla messa a disposizione sul mercato di apparecchiature radio e che
abroga la direttiva 1999/5/CE (GU L 153 del 22.5.2014, pag. 62).
02016R0799 — IT — 21.08.2023 — 003.002 — 3
Si applicano inoltre le seguenti definizioni:
1) «tachigrafo digitale» o «tachigrafo di prima generazione», un tachi­
grafo digitale diverso da un tachigrafo intelligente;
2) «dispositivo esterno del GNSS», un dispositivo comprendente il
ricevitore GNSS, quando l'unità elettronica di bordo non è un'unità
singola, nonché gli altri componenti necessari per proteggere la
comunicazione dei dati sulla posizione al resto dell'unità elettronica
di bordo;
▼M1
3) «fascicolo informativo», il fascicolo completo, in forma elettronica
o cartacea, contenente tutte le informazioni fornite dal fabbricante o
dal suo mandatario all’autorità di omologazione ai fini dell’omolo­
gazione di un tachigrafo o di un suo componente, compresi i cer­
tificati di cui all’articolo 12, paragrafo 3, del regolamento (UE)
n. 165/2014, i risultati delle prove di cui all’allegato IC del presente
regolamento, nonché disegni, fotografie e altri documenti pertinenti;
▼B
4) «fascicolo di omologazione», il fascicolo informativo, in formato
elettronico o cartaceo, più i documenti aggiunti dall'autorità di
omologazione al fascicolo informativo nello svolgimento delle pro­
prie funzioni, compresa la scheda di omologazione CE del tachi­
grafo o di un suo componente aggiunta alla fine della procedura di
omologazione;
5) «indice del fascicolo di omologazione», il documento in cui è
elencato il contenuto numerato del fascicolo di omologazione, che
ne identifica tutte le parti pertinenti. Il formato di tale documento
distingue le fasi successive della procedura di omologazione CE,
incluse le date delle revisioni e degli aggiornamenti del fascicolo;
6) «dispositivo di diagnosi precoce remota», le dotazioni dell'unità
elettronica di bordo utilizzate per svolgere controlli su strada mirati;
▼M1
7) «tachigrafo intelligente» o «tachigrafo di seconda generazione», un
tachigrafo digitale conforme agli articoli 8, 9 e 10 del
regolamento (UE) n. 165/2014, nonché all’allegato IC del presente
regolamento;
8) «componente del tachigrafo», uno dei seguenti elementi: l’unità
elettronica di bordo, il sensore di movimento, il foglio di registra­
zione, il dispositivo esterno del GNSS e il dispositivo esterno di
diagnosi precoce remota;
▼B
9) «autorità di omologazione», l'autorità di uno Stato membro preposta
all'omologazione del tachigrafo o dei suoi componenti, alla proce­
dura di autorizzazione, al rilascio e, se del caso, alla revoca delle
schede di omologazione, che agisce in qualità di punto di contatto
per le autorità di omologazione degli altri Stati membri e che ga­
rantisce che i fabbricanti adempiano i loro obblighi relativamente
alla conformità alle prescrizioni del presente regolamento ;
▼M1
10) «unità elettronica di bordo», il tachigrafo escluso il sensore di
movimento e i cavi che collegano il sensore di movimento.
Può trattarsi di un’unità singola o di più unità dislocate nel veicolo
e comprende un’unità di elaborazione, una memoria di dati, una
funzione di misurazione del tempo, due dispositivi di interfaccia per
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 4
carte intelligenti (smart card) per il conducente e il secondo con­
ducente, una stampante, un dispositivo di visualizzazione, connet­
tori e dispositivi per l’immissione dei dati da parte dell’utilizzatore,
un ricevitore GNSS e un dispositivo di comunicazione remota.
L’unità elettronica di bordo può essere costituita dai seguenti com­
ponenti soggetti a omologazione:
— unità elettronica di bordo come componente singolo (compren­
dente il ricevitore GNSS e il dispositivo di comunicazione re­
mota);
— corpo centrale dell’unità elettronica di bordo (comprendente il
dispositivo di comunicazione remota) e dispositivo GNSS
esterno;
— corpo centrale dell’unità elettronica di bordo (comprendente il
ricevitore GNSS) e dispositivo esterno di comunicazione
remota;
— corpo centrale dell’unità elettronica di bordo, ricevitore GNSS
esterno e dispositivo esterno di comunicazione remota.
Se l’unità elettronica di bordo è costituita da più unità dislocate nel
veicolo, il suo corpo centrale è costituito dall’unità che contiene
l’unità di elaborazione, la memoria di dati e la funzione di misu­
razione del tempo.
Per «unità elettronica di bordo (VU)» si può intendere sia «unità
elettronica di bordo», sia «corpo centrale dell’unità elettronica di
bordo».
▼B
Articolo 3
Servizi basati sulla localizzazione
1. I fabbricanti garantiscono la compatibilità dei tachigrafi intelligenti
con i servizi di posizionamento offerti dai sistemi Galileo e EGNOS (il
servizio europeo di copertura per la navigazione geostazionaria).
2. Oltre ai sistemi di cui al paragrafo 1, i fabbricanti possono anche
scegliere di assicurare la compatibilità con altri sistemi di navigazione
satellitare.
Articolo 4
Procedura di omologazione di un tachigrafo e dei componenti di un
tachigrafo
1. Il fabbricante o il suo mandatario presenta una domanda di omo­
logazione di un tachigrafo o di uno dei suoi componenti o di un gruppo
di componenti alle autorità di omologazione designate da ciascuno Stato
membro. Tale domanda consiste in un fascicolo informativo contenente
le informazioni relative a ciascuno dei componenti interessati, comprese,
se del caso, le schede di omologazione di altri componenti necessari per
completare il tachigrafo, nonché ogni altro documento pertinente.
2. Uno Stato membro rilascia l'omologazione per i tachigrafi, i com­
ponenti o i gruppi di componenti conformi alle prescrizioni ammini­
strative e tecniche di cui all'articolo 1, paragrafo 2 o 3, secondo i casi.
In tal caso l'autorità di omologazione rilascia al richiedente una scheda
di omologazione conforme al modello di cui all'allegato II del presente
regolamento.
3. L'autorità di omologazione può chiedere al fabbricante o al suo
mandatario di fornire ulteriori informazioni.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 5
4. Il fabbricante o il suo mandatario mette a disposizione delle auto­
rità di omologazione, nonché degli organismi responsabili del rilascio
dei certificati di cui all'articolo 12, paragrafo 3, del regolamento (UE)
n. 165/2014, tutti i tachigrafi o i relativi componenti necessari a garan­
tire lo svolgimento soddisfacente della procedura di omologazione.
5. Qualora il fabbricante o il suo mandatario chieda l'omologazione
di determinati componenti o gruppi di componenti di un tachigrafo, egli
fornisce alle autorità di omologazione gli altri componenti, già omolo­
gati, nonché le altre parti necessarie per la costruzione del tachigrafo
completo, al fine di consentire loro di effettuare le prove necessarie.
Articolo 5
Modifiche delle omologazioni
1. Il fabbricante o il suo mandatario informa senza indugio le autorità
di omologazione che hanno rilasciato l'omologazione iniziale, in merito
alle eventuali modifiche del software o dell'hardware del tachigrafo o
della natura dei materiali usati per la sua fabbricazione che sono regi­
strati nel fascicolo informativo e presenta una domanda di modifica
dell'omologazione.
2. Le autorità di omologazione possono rivedere o estendere un'omo­
logazione esistente oppure rilasciare una nuova omologazione, secondo
la natura e le caratteristiche delle modifiche.
Si procede a una «revisione» quando l'autorità di omologazione ritiene
che le modifiche del software o dell'hardware del tachigrafo o della
natura dei materiali usati per la sua fabbricazione siano di lieve entità.
In tali casi, l'autorità di omologazione rilascia i documenti rivisti del
fascicolo informativo, precisando la natura delle modifiche apportate e
la data della loro approvazione. Una versione aggiornata del fascicolo
informativo in una forma consolidata, accompagnata da una descrizione
dettagliata delle modifiche apportate, è sufficiente a soddisfare questa
prescrizione.
Si procede a un'«estensione» quando l'autorità di omologazione ritiene
che le modifiche del software o dell'hardware del tachigrafo o della
natura dei materiali usati per la sua fabbricazione siano sostanziali. In
tali casi, l'autorità di omologazione può ritenere necessario che siano
effettuate nuove prove e ne informa il fabbricante o il suo mandatario.
Se i risultati di tali prove sono soddisfacenti, l'autorità di omologazione
rilascia una scheda di omologazione rivista recante un numero che
identifica l'estensione rilasciata. La scheda di omologazione riporta il
motivo dell'estensione e la data del rilascio.
3. L'indice del fascicolo informativo indica la data dell'ultima esten­
sione o dell'ultima revisione dell'omologazione o la data dell'ultimo
consolidamento della versione aggiornata dell'omologazione.
4. Una nuova omologazione è necessaria quando le modifiche richie­
ste del tachigrafo omologato o dei suoi componenti comporterebbero il
rilascio di un nuovo certificato di sicurezza o di interoperabilità.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 6
Articolo 6
Entrata in vigore
Il presente regolamento entra in vigore il ventesimo giorno successivo
alla pubblicazione nella Gazzetta ufficiale dell'Unione europea.
Esso si applica a decorrere dal 2 marzo 2016.
▼M1
Tuttavia, l’allegato IC si applica a decorrere dal 15 giugno 2019, ad
eccezione dell’appendice 16, la quale si applica a decorrere dal 2 marzo
2016.
▼B
Il presente regolamento è obbligatorio in tutti i suoi elementi e diretta­
mente applicabile in ciascuno degli Stati membri.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 7
ALLEGATO IC
Requisiti per la costruzione, il collaudo, il montaggio e il controllo
INTRODUZIONE
1 DEFINIZIONI
2 CARATTERISTICHE GENERALI E FUNZIONI DELL'APPA­
RECCHIO DI CONTROLLO
2.1 Caratteristiche generali
2.2 Funzioni
2.3 Modalità di funzionamento
2.4 Sicurezza
3 REQUISITI DI COSTRUZIONE E FUNZIONAMENTO DEL­
L'APPARECCHIO DI CONTROLLO
3.1 Controllo dell'inserimento e dell'estrazione delle carte
3.2 Misurazione della velocità, della posizione e della distanza
3.2.1 Misurazione della distanza percorsa
3.2.2 Misurazione della velocità
3.2.3 Misurazione della posizione
3.3 Misurazione del tempo
3.4 Controllo delle attività del conducente
3.5 Controllo delle condizioni di guida
3.6 Immissioni da parte del conducente
3.6.1 Immissione del luogo in cui inizia e/o termina il periodo di lavoro
giornaliero
3.6.2 Immissione manuale delle attività del conducente e consenso del
conducente per l'interfaccia ITS
3.6.3 Immissione di condizioni particolari
▼M3
3.6.4 Immissione di un’operazione di carico/scarico
▼B
3.7 Gestione dei blocchi di un'impresa
3.8 Verifica delle attività di controllo
3.9 Rilevamento di anomalie e/o guasti
3.9.1 Anomalia «Inserimento di una carta non valida»
3.9.2 Anomalia «Conflitto di carte»
3.9.3 Anomalia «Sovrapposizione di orari»
3.9.4 Anomalia «Guida in assenza di una carta adeguata»
3.9.5 Anomalia «Inserimento carta durante la guida»
3.9.6 Anomalia «Chiusura errata ultima sessione carta»
3.9.7 Anomalia «Superamento della velocità»
3.9.8 Anomalia «Interruzione dell'alimentazione di energia»
3.9.9 Anomalia «Errore di comunicazione con il dispositivo di comuni­
cazione remota»
3.9.10 Anomalia «Assenza di informazioni sulla posizione provenienti dal
ricevitore GNSS»
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 8
3.9.11 Anomalia «Errore di comunicazione con il dispositivo GNSS
esterno»
3.9.12 Anomalia «Errore dati di marcia»
3.9.13 Anomalia «Dati contrastanti sul movimento del veicolo»
3.9.14 Anomalia «Tentata violazione della sicurezza»
3.9.15 Anomalia «Conflitto di orari»
3.9.16 Guasto «Carta»
3.9.17 Guasto «Apparecchio di controllo»
▼M3
3.9.18 Anomalia «Anomalia GNSS»
▼B
3.10 Prove incorporate e prove automatiche
3.11 Lettura della memoria di dati
3.12 Registrazione e memorizzazione nella memoria di dati
3.12.1 Dati di identificazione dell'apparecchio
3.12.1.1 Dati di identificazione dell'unità elettronica di bordo
3.12.1.2 Dati di identificazione del sensore di movimento
3.12.1.3 Dati di identificazione dei sistemi globali di navigazione satellitare
3.12.2 Chiavi e certificati
3.12.3 Dati relativi all'inserimento e all'estrazione della carta del condu­
cente o dell'officina
3.12.4 Dati relativi all'attività del conducente
▼M1
3.12.5 Luoghi e posizioni dove iniziano e terminano i periodi di lavoro
giornalieri e/o dove il periodo di guida cumulativo raggiunge le 3
ore
▼B
3.12.6 Dati relativi all'odometro
3.12.7 Dati dettagliati relativi alla velocità
3.12.8 Dati relativi alle anomalie
3.12.9 Dati relativi ai guasti
3.12.10 Dati relativi alla taratura
3.12.11 Dati relativi alla regolazione dell'ora
3.12.12 Dati relativi alle attività di controllo
3.12.13 Dati relativi ai blocchi di un'impresa
3.12.14 Dati relativi al trasferimento
3.12.15 Dati relativi a condizioni particolari
3.12.16 Dati della carta tachigrafica
▼M3
3.12.17 Attraversamenti di frontiera
3.12.18 Operazioni di carico/scarico
3.12.19 Mappa digitale
▼B
3.13 Lettura delle carte tachigrafiche
3.14 Registrazione e memorizzazione nelle carte tachigrafiche
3.14.1 Registrazione e memorizzazione nelle carte tachigrafiche di prima
generazione
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 9
3.14.2 Registrazione e memorizzazione nelle carte tachigrafiche di se­
conda generazione
3.15 Visualizzazione
3.15.1 Visualizzazione predefinita
3.15.2 Visualizzazione degli avvisi
3.15.3 Accesso guidato da menù
3.15.4 Visualizzazione di altre informazioni
3.16 Stampa
3.17 Avvisi
3.18 Trasferimento di dati a un dispositivo esterno
3.19 Comunicazione remota per controlli su strada mirati
▼M3
3.20 Scambi di dati con dispositivi esterni aggiuntivi
▼B
3.21 Taratura
3.22 Verifica della taratura su strada
3.23 Regolazione dell'ora
3.24 Caratteristiche prestazionali
3.25 Materiali
3.26 Iscrizioni
▼M3
3.27 Monitoraggio degli attraversamenti di frontiera
3.28 Aggiornamento software
▼B
4 REQUISITI DI COSTRUZIONE E FUNZIONAMENTO DELLE
CARTE TACHIGRAFICHE
4.1 Dati visibili
4.2 Sicurezza
4.3 Norme
4.4 Specifiche ambientali ed elettriche
4.5 Memorizzazione dei dati
4.5.1 File elementari per l'identificazione e la gestione della carta
4.5.2 Identificazione della carta a circuito integrato
4.5.2.1 Identificazione del chip
4.5.2.2 DIR (presente solo nelle carte tachigrafiche di seconda genera­
zione)
4.5.2.3 Informazioni ATR (opzionali, presenti solo nelle carte tachigrafiche
di seconda generazione)
4.5.2.4 Informazioni di lunghezza estesa (opzionali, presenti solo nelle
carte tachigrafiche di seconda generazione)
4.5.3 Carta del conducente
4.5.3.1 Applicazione del tachigrafo (accessibile alle unità elettroniche di
bordo di prima e seconda generazione)
4.5.3.1.1 Identificazione dell'applicazione
4.5.3.1.2 Chiavi e certificati
4.5.3.1.3 Identificazione della carta
4.5.3.1.4 Identificazione del titolare della carta
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 10
4.5.3.1.5 Trasferimento dei dati della carta
4.5.3.1.6 Informazioni sulla patente di guida
4.5.3.1.7 Dati relativi alle anomalie
4.5.3.1.8 Dati relativi ai guasti
4.5.3.1.9 Dati relativi all'attività del conducente
4.5.3.1.10 Dati relativi ai veicoli impiegati
4.5.3.1.11 Luogo in cui inizia e/o termina il periodo di lavoro giornaliero
4.5.3.1.12 Dati relativi alla sessione della carta
4.5.3.1.13 Dati relativi alle attività di controllo
4.5.3.1.14 Dati relativi a condizioni particolari
4.5.3.2 Applicazione del tachigrafo di seconda generazione (non accessi­
bile alle unità elettroniche di bordo di prima generazione)
4.5.3.2.1 Identificazione dell'applicazione
▼M3
4.5.3.2.1.1 Identificazione delle applicazioni aggiuntive (non accessibile me­
diante la versione 1 delle unità elettroniche di bordo di seconda
generazione)
▼B
4.5.3.2.2 Chiavi e certificati
4.5.3.2.3 Identificazione della carta
4.5.3.2.4 Identificazione del titolare della carta
4.5.3.2.5 Trasferimento dei dati della carta
4.5.3.2.6 Informazioni sulla patente di guida
4.5.3.2.7 Dati relativi alle anomalie
4.5.3.2.8 Dati relativi ai guasti
4.5.3.2.9 Dati relativi all'attività del conducente
4.5.3.2.10 Dati relativi ai veicoli impiegati
4.5.3.2.11 Luogo e posizione in cui inizia e/o termina il periodo di lavoro
giornaliero
4.5.3.2.12 Dati relativi alla sessione della carta
4.5.3.2.13 Dati relativi alle attività di controllo
4.5.3.2.14 Dati relativi a condizioni particolari
4.5.3.2.15 Dati relativi alle unità elettroniche di bordo usate
▼M1
4.5.3.2.16 Dati relativi al luogo in cui si raggiungono le tre ore cumulative di
guida
▼M3
4.5.3.2.17 Stato di autenticazione per le posizioni relative a luoghi dove ini­
ziano e/o terminano i periodi di lavoro giornalieri (non accessibile
mediante la versione 1 delle unità elettroniche di bordo di seconda
generazione)
4.5.3.2.18 Stato di autenticazione per le posizioni in cui il periodo di guida
cumulativo raggiunge le tre ore (non accessibile mediante la ver­
sione 1 delle unità elettroniche di bordo di seconda generazione)
4.5.3.2.19 Attraversamenti di frontiera (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 11
4.5.3.2.20 Operazioni di carico/scarico (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
4.5.3.2.21 Immissioni relative al tipo di carico (non accessibili mediante la
versione 1 delle unità elettroniche di bordo di seconda generazione)
4.5.3.2.22 Configurazioni della VU (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
▼B
4.5.4 Carta dell'officina
4.5.4.1 Applicazione del tachigrafo (accessibile alle unità elettroniche di
bordo di prima e seconda generazione)
4.5.4.1.1 Identificazione dell'applicazione
4.5.4.1.2 Chiavi e certificati
4.5.4.1.3 Identificazione della carta
4.5.4.1.4 Identificazione del titolare della carta
4.5.4.1.5 Trasferimento dei dati della carta
4.5.4.1.6 Dati relativi a taratura e regolazione dell'ora
4.5.4.1.7 Dati relativi ad anomalie e guasti
4.5.4.1.8 Dati relativi all'attività del conducente
4.5.4.1.9 Dati relativi ai veicoli impiegati
4.5.4.1.10 Dati relativi all'inizio e/o al termine del periodo di lavoro giorna­
liero
4.5.4.1.11 Dati relativi alla sessione della carta
4.5.4.1.12 Dati relativi alle attività di controllo
4.5.4.1.13 Dati relativi a condizioni particolari
4.5.4.2 Applicazione del tachigrafo di seconda generazione (non accessi­
bile alle unità elettroniche di bordo di prima generazione)
4.5.4.2.1 Identificazione dell'applicazione
▼M3
4.5.4.2.1.1 Identificazione delle applicazioni aggiuntive (non accessibile me­
diante la versione 1 delle unità elettroniche di bordo di seconda
generazione)
▼B
4.5.4.2.2 Chiavi e certificati
4.5.4.2.3 Identificazione della carta
4.5.4.2.4 Identificazione del titolare della carta
4.5.4.2.5 Trasferimento dei dati della carta
4.5.4.2.6 Dati relativi a taratura e regolazione dell'ora
4.5.4.2.7 Dati relativi ad anomalie e guasti
4.5.4.2.8 Dati relativi all'attività del conducente
4.5.4.2.9 Dati relativi ai veicoli impiegati
4.5.4.2.10 Dati relativi all'inizio e/o al termine del periodo di lavoro giorna­
liero
4.5.4.2.11 Dati relativi alla sessione della carta
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 12
4.5.4.2.12 Dati relativi alle attività di controllo
4.5.4.2.13 Dati relativi alle unità elettroniche di bordo usate
▼M1
4.5.4.2.14 Dati relativi al luogo in cui si raggiungono le tre ore cumulative di
guida
▼B
4.5.4.2.15 Dati relativi a condizioni particolari
▼M3
4.5.4.2.16 Stato di autenticazione per le posizioni relative a luoghi dove ini­
ziano e/o terminano i periodi di lavoro giornalieri (non accessibile
mediante la versione 1 delle unità elettroniche di bordo di seconda
generazione)
4.5.4.2.17 Stato di autenticazione per le posizioni dove il periodo di guida
cumulativo raggiunge le tre ore (non accessibile mediante la ver­
sione 1 delle unità elettroniche di bordo di seconda generazione)
4.5.4.2.18 Attraversamenti di frontiera (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
4.5.4.2.19 Operazioni di carico/scarico (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
4.5.4.2.20 Immissioni relative al tipo di carico (non accessibili mediante la
versione 1 delle unità elettroniche di bordo di seconda generazione)
4.5.4.2.21 Dati aggiuntivi relativi alla taratura (non accessibili mediante la
versione 1 delle unità elettroniche di bordo di seconda generazione)
4.5.4.2.22 Configurazioni della VU (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
▼B
4.5.5 Carta di controllo
4.5.5.1 Applicazione del tachigrafo (accessibile alle unità elettroniche di
bordo di prima e seconda generazione)
4.5.5.1.1 Identificazione dell'applicazione
4.5.5.1.2 Chiavi e certificati
4.5.5.1.3 Identificazione della carta
4.5.5.1.4 Identificazione del titolare della carta
4.5.5.1.5 Dati relativi alle attività di controllo
4.5.5.2 Applicazione del tachigrafo di seconda generazione (non accessi­
bile alle unità elettroniche di bordo di prima generazione)
4.5.5.2.1 Identificazione dell'applicazione
▼M3
4.5.5.2.1.1 Identificazione delle applicazioni aggiuntive (non accessibile me­
diante la versione 1 delle unità elettroniche di bordo di seconda
generazione)
▼B
4.5.5.2.2 Chiavi e certificati
4.5.5.2.3 Identificazione della carta
4.5.5.2.4 Identificazione del titolare della carta
4.5.5.2.5 Dati relativi alle attività di controllo
▼M3
4.5.5.2.6 Configurazioni della VU (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
▼B
4.5.6 Carta dell'azienda
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 13
4.5.6.1 Applicazione del tachigrafo (accessibile alle unità elettroniche di
bordo di prima e seconda generazione)
4.5.6.1.1 Identificazione dell'applicazione
4.5.6.1.2 Chiavi e certificati
4.5.6.1.3 Identificazione della carta
4.5.6.1.4 Identificazione del titolare della carta
4.5.6.1.5 Dati relativi alle attività dell'impresa
4.5.6.2 Applicazione del tachigrafo di seconda generazione (non accessi­
bile alle unità elettroniche di bordo di prima generazione)
4.5.6.2.1 Identificazione dell'applicazione
▼M3
4.5.6.2.1.1 Identificazione delle applicazioni aggiuntive (non accessibile me­
diante la versione 1 delle unità elettroniche di bordo di seconda
generazione)
▼B
4.5.6.2.2 Chiavi e certificati
4.5.6.2.3 Identificazione della carta
4.5.6.2.4 Identificazione del titolare della carta
4.5.6.2.5 Dati relativi alle attività dell'impresa
▼M3
4.5.6.2.6 Configurazioni della VU (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
▼B
5 MONTAGGIO DELL'APPARECCHIO DI CONTROLLO
5.1 Montaggio
5.2 Targhetta di montaggio
5.3 Sigilli
6 VERIFICHE, CONTROLLI E RIPARAZIONI
6.1 Autorizzazione di installatori, officine e costruttori di veicoli
▼M1
6.2 Verifica dei componenti nuovi o riparati
▼B
6.3 Controllo in sede di montaggio
6.4 Controlli periodici
6.5 Determinazione degli errori
6.6 Riparazioni
7 RILASCIO DELLA CARTA
8 OMOLOGAZIONE DELL'APPARECCHIO DI CONTROLLO E
DELLE CARTE TACHIGRAFICHE
8.1 Prescrizioni generali
8.2 Certificato di sicurezza
8.3 Certificato funzionale
8.4 Certificato di interoperabilità
8.5 Scheda di omologazione
8.6 Procedura eccezionale: primi certificati di interoperabilità per gli
apparecchi di controllo e le carte tachigrafiche di 2 a generazione
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 14
INTRODUZIONE
Il presente allegato reca i requisiti degli apparecchi di controllo e delle carte
tachigrafiche di seconda generazione.
A decorrere dal 15 giugno 2019 sui veicoli immatricolati per la prima volta
nell’Unione si montano gli apparecchi di controllo di seconda generazione e
sono rilasciate le carte tachigrafiche di seconda generazione.
Affinché il sistema tachigrafico di seconda generazione possa essere implemen­
tato senza intoppi, le carte tachigrafiche di seconda generazione sono state pro­
gettate per essere utilizzate anche nelle unità elettroniche di bordo di prima
generazione costruite conformemente all’allegato IB del regolamento (CEE)
n. 3821/85.
Analogamente, le carte tachigrafiche di prima generazione possono essere utiliz­
zate nelle unità elettroniche di bordo di seconda generazione. Le unità elettroni­
che di bordo di seconda generazione possono tuttavia essere tarate utilizzando
solo le carte dell’officina di seconda generazione.
I requisiti relativi all’interoperabilità tra i sistemi tachigrafici di prima e seconda
generazione sono specificati nel presente allegato. A tal proposito l’appendice 15
contiene ulteriori dettagli sulla gestione della coesistenza di entrambe le
generazioni.
Inoltre, poiché sono state implementate nuove funzioni, quali l’uso del servizio
aperto di autenticazione dei messaggi di navigazione di Galileo (Galileo Open
Service Navigation Message Authentication), il rilevamento degli attraversamenti
di frontiera e l’immissione delle operazioni di carico e scarico, e vi è l’esigenza
di aumentare la capacità della carta del conducente a 56 giorni di attività del
conducente, il presente regolamento introduce i requisiti tecnici per la seconda
versione dell’apparecchio di controllo e delle carte tachigrafiche di seconda
generazione.
▼B
Elenco delle appendici
App 1: DIZIONARIO DEI DATI
App 2: SPECIFICHE RIGUARDANTI LE CARTE TACHIGRAFICHE
App 3: PITTOGRAMMI
App 4: STAMPE
App 5: DISPOSITIVO DI VISUALIZZAZIONE
App 6: CONNETTORE ANTERIORE PER LA TARATURA E IL
TRASFERIMENTO DEI DATI
App 7: PROTOCOLLI DI TRASFERIMENTO DEI DATI
App 8: PROTOCOLLO DI TARATURA
App 9: OMOLOGAZIONE ED ELENCO DELLE PROVE MINIME
PRESCRITTE
App 10: REQUISITI DI SICUREZZA
App 11: MECCANISMI COMUNI DI SICUREZZA
App 12: POSIZIONAMENTO BASATO SUL SISTEMA GLOBALE DI
NAVIGAZIONE SATELLITARE (GNSS)
App 13: INTERFACCIA ITS
App 14: FUNZIONE DI COMUNICAZIONE REMOTA
App 15: MIGRAZIONE: GESTIONE DELLA COESISTENZA DI DI­
VERSE GENERAZIONI DI APPARECCHIATURE
App 16: ADATTATORE PER VEICOLI DELLE CATEGORIE M1 E N1
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 15
1 DEFINIZIONI
Ai sensi del presente allegato, s'intende per:
a) «attivazione»,
la fase in cui il tachigrafo diventa pienamente operativo e in
grado di assolvere tutte le sue funzioni, comprese quelle di
sicurezza, tramite l'uso di una carta dell'officina;
b) «autenticazione»,
la funzione di identificazione e verifica dell'identità indicata;
c) «autenticità»,
la caratteristica di un'informazione di provenire da una fonte di
cui si può verificare l'identità;
d) «prova incorporata»,
le prove effettuate su richiesta, azionate dall'operatore o da un
apparecchio esterno;
e) «giorno di calendario»,
una giornata che va dalle ore 00:00 alle ore 24:00. Tutti i
giorni di calendario si riferiscono all'ora UTC (tempo univer­
sale coordinato);
▼M3
f) «taratura del tachigrafo intelligente»,
l’aggiornamento o la conferma dei parametri del veicolo da
conservare nella memoria di dati. Tali parametri comprendono
l’identificazione del veicolo (VIN, VRN e Stato membro di
immatricolazione) e le caratteristiche del veicolo (w, k, l, di­
mensioni degli pneumatici, impostazioni del limitatore di ve­
locità (se applicabile), ora corrente (UTC), valore corrente
dell’odometro, tipo di carico predefinito). Durante la taratura
di un apparecchio di controllo, anche i tipi e gli identificativi
di tutti i sigilli di omologazione pertinenti devono essere me­
morizzati nella memoria di dati.
Qualsiasi aggiornamento o conferma esclusivamente dell’ora
UTC sono considerati una regolazione dell’ora e non una ta­
ratura, purché non siano in contrasto con il requisito 409 di cui
al punto 6.4.
La taratura di un apparecchio di controllo richiede l’impiego di
una carta dell’officina;
g) «numero della carta»,
un numero costituito da 16 caratteri alfanumerici che identifica
in modo univoco una carta tachigrafica all’interno di uno Stato
membro. Il numero della carta comprende un’identificazione,
costituita dall’identificazione del conducente o dall’identifica­
zione del titolare della carta, insieme a un codice di serie della
carta, un codice di sostituzione della carta e un codice di
rinnovo della carta.
Una carta è quindi identificata in modo univoco dal codice
dello Stato membro di rilascio e dal numero della carta;
▼B
h) «codice di serie della carta»,
il 14 o carattere alfanumerico del numero della carta inteso a
differenziare le diverse carte rilasciate ad un'impresa, un'offi­
cina o un'autorità di controllo autorizzate ad ottenere più carte
tachigrafiche. L'impresa, l'officina o l'autorità di controllo sono
identificate in modo inequivocabile dai primi 13 caratteri del
numero della carta;
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 16
i) «codice di rinnovo della carta»,
il 16 o carattere alfanumerico del numero della carta che viene
incrementato ogni volta che viene rinnovata una carta tachi­
grafica corrispondente a una determinata identificazione, vale a
dire l’identificazione del conducente o del titolare insieme al
codice di serie;
j) «codice di sostituzione della carta»,
il 15 o carattere alfanumerico del numero della carta che viene
incrementato ogni volta che viene sostituita una carta tachigra­
fica corrispondente a una determinata identificazione, vale a
dire l’identificazione del conducente o del titolare insieme al
codice di serie;
▼B
k) «coefficiente caratteristico del veicolo»,
la caratteristica numerica che esprime il valore del segnale di
uscita emesso dalla parte del veicolo collegata all'apparecchio
di controllo (asse o albero di uscita del cambio) quando il
veicolo percorre la distanza di un chilometro in condizioni
normali di prova, come definite nel requisito 414. Il coeffi­
ciente caratteristico è espresso in impulsi per chilometro (w =
… imp/km);
l) «carta dell'azienda»,
una carta tachigrafica rilasciata dalle autorità di uno Stato
membro a un'impresa di trasporto stradale che deve usare vei­
coli muniti di tachigrafo, che identifica l'impresa di trasporto e
consente la visualizzazione, il trasferimento e la stampa dei
dati archiviati nel tachigrafo che sono stati bloccati da tale
impresa di trasporto;
m) «costante dell'apparecchio di controllo»,
la caratteristica numerica che esprime il valore del segnale di
entrata necessario per ottenere l'indicazione e la registrazione
della distanza percorsa di 1 chilometro. La costante è espressa
in impulsi per chilometro (k = … imp/km);
n) «periodo di guida continuo», calcolato all'interno dell'apparec­
chio di controllo come ( 1 ):
il periodo di guida continuo è calcolato come la somma cor­
rente dei periodi di guida accumulati da un determinato con­
ducente, a partire dal termine del suo ultimo periodo di DI­
SPONIBILITÀ o di INTERRUZIONE/RIPOSO o NON
NOTO ( 2 ) di 45 minuti o più [questo periodo può essere ri­
partito come prescritto dal regolamento (CE) n. 561/2006 del
Parlamento europeo e del Consiglio ( 3 )]. I calcoli tengono
conto, a seconda della necessità, delle attività precedenti me­
morizzate sulla carta del conducente. Qualora il conducente
non abbia inserito la sua carta, i calcoli si basano sulle regi­
strazioni nella memoria di dati riferite al periodo corrente du­
rante il quale la carta non era inserita e relative alla sede (slot)
pertinente;
▼M3
( 1 ) Questo metodo di calcolo del periodo di guida continuo e del periodo cumulato di
interruzione consente all'apparecchio di controllo di calcolare gli avvisi relativi al periodo
di guida continuo. Esso non pregiudica l'interpretazione giuridica di tali periodi. Ai fini
del calcolo del periodo di guida continuo e del periodo cumulato di interruzione si
possono utilizzare metodi alternativi per sostituire le presenti definizioni qualora risultino
superate a seguito di modifiche di altri atti legislativi pertinenti.
( 2 ) I periodi NON NOTI corrispondono ai periodi durante i quali la carta del conducente non
era inserita in un apparecchio di controllo e per i quali non è stata effettuata l'immissione
manuale delle attività del conducente.
( 3 ) Regolamento (CE) n. 561/2006 del Parlamento europeo e del Consiglio, del 15 marzo
2006, relativo all'armonizzazione di alcune disposizioni in materia sociale nel settore dei
trasporti su strada e che modifica i regolamenti del Consiglio (CEE) n. 3821/85 e (CE)
n. 2135/98 e abroga il regolamento (CEE) n. 3820/85 del Consiglio (GU L 102
dell'11.4.2006, pag. 1).
02016R0799 — IT — 21.08.2023 — 003.002 — 17
o) «carta di controllo»,
una carta tachigrafica rilasciata dalle autorità di uno Stato
membro a un'autorità di controllo nazionale competente, che
identifica l'organismo di controllo e, facoltativamente, l'agente
di controllo, e consente l'accesso ai dati archiviati nella me­
moria di dati, nelle carte del conducente e, facoltativamente,
nelle carte dell'officina, per la lettura, la stampa e/o il
trasferimento.
Essa dà accesso anche alla funzione di verifica della taratura
su strada e ai dati del lettore della comunicazione remota a fini
di diagnosi precoce;
p) «periodo cumulato di interruzione», calcolato all'interno del­
l'apparecchio di controllo come ( 1 ):
il periodo cumulato di interruzione della guida è calcolato
come la somma corrente dei periodi di DISPONIBILITÀ o
di INTERRUZIONE/RIPOSO o NON NOTI ( 2 ) di 15 minuti
o più accumulati da un determinato conducente, a partire dal
termine del suo ultimo periodo di DISPONIBILITÀ o di IN­
TERRUZIONE/RIPOSO o NON NOTO ( 3 ) di 45 minuti o più
[questo periodo può essere ripartito come prescritto dal
regolamento (CE) n. 561/2006].
I calcoli tengono conto, a seconda della necessità, delle attività
precedenti memorizzate sulla carta del conducente. I periodi
non noti di durata negativa (inizio del periodo non noto >
termine del periodo non noto), dovuti a sovrapposizioni di
orari tra due diversi apparecchi di controllo, non sono presi
in considerazione.
Qualora il conducente non abbia inserito la sua carta, i calcoli
si basano sulle registrazioni nella memoria di dati riferite al
periodo corrente durante il quale la carta non era inserita e
relative alla sede (slot) pertinente;
q) «memoria di dati»,
un dispositivo elettronico di memorizzazione di dati, incorpo­
rato nell'apparecchio di controllo;
r) «firma digitale»,
i dati aggiunti a un blocco di dati o una trasformazione critto­
grafica dello stesso, che consentono al destinatario del blocco
di dati di verificarne l'autenticità e l'integrità;
s) «trasferimento»,
la copia, unitamente alla firma digitale, di una parte o di una
serie completa di file di dati, registrati nella memoria di dati
dell'unità elettronica di bordo (VU) o nella memoria di una
carta tachigrafica, a condizione che tale procedura non modifi­
chi o cancelli i dati memorizzati.
▼B
( 1 ) Questo metodo di calcolo del periodo di guida continuo e del periodo cumulato di
interruzione consente all'apparecchio di controllo di calcolare gli avvisi relativi al periodo
di guida continuo. Esso non pregiudica l'interpretazione giuridica di tali periodi. Ai fini
del calcolo del periodo di guida continuo e del periodo cumulato di interruzione si
possono utilizzare metodi alternativi per sostituire le presenti definizioni qualora risultino
superate a seguito di modifiche di altri atti legislativi pertinenti.
( 2 ) I periodi NON NOTI corrispondono ai periodi durante i quali la carta del conducente non
era inserita in un apparecchio di controllo e per i quali non è stata effettuata l'immissione
manuale delle attività del conducente.
( 3 ) I periodi NON NOTI corrispondono ai periodi durante i quali la carta del conducente non
era inserita in un apparecchio di controllo e per i quali non è stata effettuata l'immissione
manuale delle attività del conducente.
02016R0799 — IT — 21.08.2023 — 003.002 — 18
I fabbricanti delle unità elettroniche di bordo (tachigrafo intel­
ligente) e i fabbricanti delle apparecchiature destinate al tra­
sferimento di file di dati devono adottare tutti i provvedimenti
ragionevoli per garantire che il trasferimento dei dati in que­
stione avvenga in modo da causare ritardi minimi all'attività
delle imprese di trasporto o dei conducenti.
Il trasferimento del file relativo alla velocità può non essere
necessario per stabilire la conformità al regolamento (CE)
n. 561/2006, ma può essere usato per altri scopi, ad esempio
per accertare le cause di un incidente;
t) «carta del conducente»,
una carta tachigrafica rilasciata dalle autorità di uno Stato
membro a un determinato conducente, che lo identifica e con­
sente l'archiviazione dei dati sulla sua attività;
u) «circonferenza effettiva delle ruote»,
la media delle distanze percorse da ciascuna delle ruote che
imprimono il movimento al veicolo (ruote motrici) durante una
rotazione completa. La misurazione di queste distanze deve
essere effettuata in condizioni normali di prova, come definite
nel requisito 414, ed è espressa come: «l = … mm». I co­
struttori di veicoli possono sostituire la misurazione di queste
distanze con un calcolo teorico che tenga conto della riparti­
zione del peso sugli assi, con veicolo a vuoto in normali
condizioni di marcia ( 1 ). I metodi di tale calcolo teorico de­
vono essere approvati da un'autorità competente degli Stati
membri e tale approvazione può avvenire solo prima dell'atti­
vazione del tachigrafo;
v) «anomalia»,
un'operazione anomala rilevata dal tachigrafo intelligente, po­
tenzialmente risultante da un tentativo di frode;
w) «dispositivo GNSS esterno»,
un dispositivo comprendente il ricevitore GNSS, quando
l'unità elettronica di bordo non è un'unità singola, nonché gli
altri componenti necessari per proteggere la comunicazione dei
dati sulla posizione al resto delle unità elettroniche di bordo;
x) «guasto»,
un'operazione anomala rilevata dal tachigrafo intelligente, che
può essere dovuta al cattivo funzionamento o al guasto di un
apparecchio;
y) «ricevitore GNSS»,
un dispositivo elettronico che riceve ed elabora digitalmente i
segnali di uno o più sistemi globali di navigazione satellitare
(in inglese GNSS) per fornire informazioni sulla posizione, la
velocità e l'ora;
▼B
( 1 ) Regolamento (UE) n. 1230/2012 della Commissione, del 12 dicembre 2012, che attua il
regolamento (CE) n. 661/2009 del Parlamento europeo e del Consiglio per quanto
riguarda i requisiti di omologazione per le masse e le dimensioni dei veicoli a motore
e dei loro rimorchi e che modifica la direttiva 2007/46/CE del Parlamento europeo e del
Consiglio (GU L 353 del 21.12.2012, pag. 31), come modificata da ultimo.
02016R0799 — IT — 21.08.2023 — 003.002 — 19
z) «montaggio»,
il montaggio di un tachigrafo su un veicolo;
aa) «interoperabilità»,
la capacità dei sistemi e dei processi industriali e commerciali
sottostanti di scambiare dati e di condividere informazioni;
bb) «interfaccia»,
strumento posto tra sistemi, che fornisce i mezzi attraverso i
quali detti sistemi possono collegarsi e interagire;
cc) «posizione»,
coordinate geografiche del veicolo in un dato momento;
dd) «sensore di movimento»,
una parte del tachigrafo che fornisce un segnale rappresenta­
tivo della velocità del veicolo e/o della distanza percorsa;
▼M3
ee) «carta non valida»,
una carta individuata come difettosa oppure la cui autentica­
zione non è andata a buon fine o la cui data di inizio di
validità non è ancora stata raggiunta o la cui data di scadenza
è stata superata;
una carta è inoltre considerata non valida dall’unità elettronica
di bordo se:
— una carta con lo stesso Stato membro di rilascio, la stessa
identificazione, vale a dire l’identificazione del conducente
o del titolare insieme a un codice di serie, e un codice di
rinnovo più elevato è già stata inserita nell’unità elettronica
di bordo, oppure
— una carta con lo stesso Stato membro di rilascio, la stessa
identificazione, vale a dire l’identificazione del conducente
o del titolare insieme a un codice di serie, lo stesso codice
di rinnovo, ma un codice di sostituzione più elevato è già
stata inserita nell’unità elettronica di bordo;
▼B
ff) «standard aperto»,
uno standard definito in un documento contenente le relative
specifiche disponibile gratuitamente o a un prezzo simbolico,
che può essere copiato, divulgato o usato a titolo gratuito o
previo pagamento di un importo simbolico;
gg) «escluso dal campo di applicazione»,
la circostanza in cui non è prescritto l'uso dell'apparecchio di
controllo, secondo le disposizioni del regolamento (CE)
n. 561/2006;
hh) «superamento della velocità»,
il superamento della velocità autorizzata del veicolo, definito
come ogni periodo di durata superiore a 60 secondi durante il
quale la velocità misurata del veicolo supera il limite del va­
lore di regolazione del limitatore di velocità stabilito dalla
direttiva 92/6/CEE del Consiglio ( 1 ), come modificata da
ultimo;
▼B
( 1 ) Direttiva 92/6/CEE del Consiglio, del 10 febbraio 1992, concernente il montaggio e
l'impiego di limitatori di velocità per talune categorie di autoveicoli nella Comunità
(GU L 57 del 2.3.1992, pag. 27).
02016R0799 — IT — 21.08.2023 — 003.002 — 20
ii) «controllo periodico»,
un insieme di operazioni effettuate per verificare il corretto
funzionamento del tachigrafo, la corrispondenza tra le impo­
stazioni e i parametri del veicolo e l'assenza di un eventuale
collegamento del tachigrafo a dispositivi di manipolazione;
jj) «stampante»,
un componente dell'apparecchio di controllo che stampa i dati
memorizzati;
kk) «comunicazione remota a fini di diagnosi precoce»,
la comunicazione tra il dispositivo di comunicazione remota a
fini di diagnosi precoce e il lettore della comunicazione remota
a fini di diagnosi precoce durante i controlli su strada mirati al
fine di individuare a distanza eventuali manomissioni o usi
impropri dell'apparecchio di controllo;
▼M3
ll) «dispositivo di comunicazione remota», «modulo di comuni­
cazione remota» o «dispositivo di diagnosi precoce remota»,
le apparecchiature dell’unità elettronica di bordo utilizzate per
svolgere controlli su strada mirati;
▼B
mm) «lettore della comunicazione remota a fini di diagnosi pre­
coce»,
il sistema utilizzato per i controlli su strada mirati dagli agenti
preposti;
▼M3
nn) «rinnovo della carta»,
il rilascio di una nuova carta tachigrafica quando una carta
esistente raggiunge la sua data di scadenza o non funziona
correttamente e viene restituita alle autorità di rilascio;
▼B
oo) «riparazione»,
qualunque riparazione di un sensore di movimento, di un'unità
elettronica di bordo o di un cavo che comporti l'interruzione
dell'alimentazione di energia o del suo collegamento ad altri
componenti del tachigrafo o l'apertura del sensore di movi­
mento o dell'unità elettronica di bordo;
▼M3
pp) «sostituzione della carta»,
il rilascio di una nuova carta tachigrafica in sostituzione di una
carta esistente, dichiarata smarrita, rubata o non funzionante,
che non è stata restituita alle autorità di rilascio;
▼B
qq) «certificazione della sicurezza»,
la procedura, condotta da un organismo di certificazione di
criteri comuni, volta a certificare che l'apparecchio di controllo
(o un suo componente) o la carta tachigrafica in esame soddi­
sfano i requisiti di sicurezza definiti nei rispettivi profili di
protezione;
rr) «prova automatica»,
le prove cicliche ed automatiche effettuate dall'apparecchio di
controllo per rilevare eventuali guasti;
ss) «misurazione del tempo»,
una registrazione digitale permanente del tempo (data e ora)
universale coordinato (UTC);
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 21
tt) «regolazione dell’ora»,
una regolazione dell’ora corrente; tale regolazione può essere
automatica, usando come riferimento l’ora indicata dal ricevi­
tore GNSS, oppure può essere effettuata nel modo taratura;
▼B
uu) «dimensioni degli pneumatici»,
l'indicazione delle dimensioni degli pneumatici (ruote motrici
esterne), in conformità alla direttiva 92/23/CEE, del Consi­
glio ( 1 ), come modificata da ultimo;
vv) «identificazione del veicolo»,
i numeri che identificano il veicolo: il numero di immatrico­
lazione del veicolo (VRN), con indicazione dello Stato mem­
bro di immatricolazione, e il numero di identificazione del
veicolo (VIN) ( 2 );
ww) «settimana», ai fini dei calcoli interni dell'apparecchio di
controllo,
il periodo compreso tra le ore 00:00 UTC del lunedì e le ore
24:00 UTC della domenica;
xx) «carta dell'officina»,
una carta tachigrafica rilasciata dalle autorità di uno Stato
membro al personale designato di un produttore di tachigrafi,
un installatore, un costruttore di veicoli o un'officina approvati
da tale Stato membro, che identifica il titolare della carta e
consente il collaudo, la taratura e l'attivazione dei tachigrafi e/o
il trasferimento di dati dai medesimi;
yy) «adattatore»,
un dispositivo, che fornisce un segnale costantemente rappre­
sentativo della velocità del veicolo e/o della distanza percorsa,
diverso da quello utilizzato per il rilevamento del movimento
indipendente, e che:
▼M3
— è montato e utilizzato solo sui veicoli delle categorie M1 e
N1, di cui all’articolo 4 del regolamento (UE) 2018/858
del Parlamento europeo e del Consiglio ( 3 ),
▼B
— è montato nei casi in cui non è meccanicamente possibile
montare alcun altro tipo di sensore di movimento esistente
altrimenti conforme alle disposizioni del presente allegato e
delle appendici da 1 a 15 dello stesso,
▼M3
( 1 ) Direttiva 92/23/CEE del Consiglio, del 31 marzo 1992, relativa ai pneumatici dei veicoli
a motore e dei loro rimorchi nonché al loro montaggio (GU L 129 del 14.5.1992,
pag. 95).
( 2 ) Direttiva 76/114/CEE del Consiglio, del 18 dicembre 1975, per il ravvicinamento delle
legislazioni degli Stati membri relative alle targhette ed alle iscrizioni regolamentari
nonché alla loro posizione e modo di fissaggio per i veicoli a motore e i loro rimorchi
(GU L 24 del 30.1.1976, pag. 1).
( 3 ) Regolamento (UE) 2018/858 del Parlamento europeo e del Consiglio, del 30 maggio
2018, relativo all'omologazione e alla vigilanza del mercato dei veicoli a motore e dei
loro rimorchi, nonché dei sistemi, dei componenti e delle entità tecniche indipendenti
destinati a tali veicoli, che modifica i regolamenti (CE) n. 715/2007 e (CE) n. 595/2009 e
abroga la direttiva 2007/46/CE (GU L 151 del 14.6.2018, pag. 1).
02016R0799 — IT — 21.08.2023 — 003.002 — 22
— è montato tra l'unità elettronica di bordo e il punto in cui
gli impulsi relativi alla velocità/distanza sono generati da
sensori integrati o interfacce alternative,
— visto dall'unità elettronica di bordo, l'adattatore funziona
come se un sensore di movimento, conforme alle disposi­
zioni del presente allegato e delle appendici da 1 a 16 dello
stesso, fosse collegato all'unità elettronica di bordo.
L'uso dell'adattatore nei veicoli sopra descritti deve consentire
il montaggio e il corretto utilizzo di un'unità elettronica di
bordo conforme a tutti i requisiti del presente allegato.
Per tali veicoli il tachigrafo intelligente comprende i cavi,
l'adattatore e l'unità elettronica di bordo;
zz) «integrità dei dati»,
l'accuratezza e la coerenza dei dati memorizzati, indicata dal­
l'assenza di qualsiasi cambiamento dei dati tra due aggiorna­
menti di un registro di dati. L'integrità implica che i dati siano
una copia conforme della versione originale, ad esempio che
non siano stati danneggiati durante la scrittura su una carta
tachigrafica o un dispositivo apposito e la lettura da essi o
durante la trasmissione tramite qualsiasi canale di
comunicazione;
▼M3
aaa) riservato per uso futuro;
▼B
bbb) «sistema tachigrafico intelligente»,
l'apparecchio di controllo, le carte tachigrafiche e l'insieme di
tutte le apparecchiature che interagiscono direttamente o indi­
rettamente durante la loro costruzione, installazione, uso, col­
laudo e controllo, come le carte, il lettore della comunicazione
remota e qualsiasi altro dispositivo per il trasferimento dei dati,
l'analisi dei dati, la taratura, la creazione, la gestione o l'in­
troduzione di elementi di sicurezza, ecc.;
▼M3
ccc) «data di introduzione»,
la data stabilita nel regolamento (UE) n. 165/2014 a decorrere
dalla quale i veicoli immatricolati per la prima volta sono
muniti di un tachigrafo in conformità a tale regolamento;
▼B
ddd) «profilo di protezione»,
un documento, utilizzato come parte del processo di certifica­
zione secondo criteri comuni, che fornisce le specifiche indi­
pendenti dall'attuazione dei requisiti di sicurezza per la garan­
zia di sicurezza delle informazioni;
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 23
eee) «accuratezza del GNSS»,
nel contesto della registrazione della posizione dal sistema
globale di navigazione satellitare (GNSS) con i tachigrafi, il
valore dell'HDOP (Horizontal Dilution of Precision), calcolato
come il valore HDOP minimo tra quelli raccolti sui sistemi
GNSS disponibili ;
▼M1
fff) «periodo di guida cumulativo»,
un valore che rappresenta il totale cumulativo dei minuti di
guida di un certo veicolo.
Il valore del periodo di guida cumulativo è un conteggio cu­
mulativo di tutti i minuti considerati DI GUIDA dalla funzione
di verifica delle attività di guida dell’apparecchio di controllo
ed è utilizzato solo per attivare la memorizzazione della posi­
zione del veicolo ogni volta che viene raggiunto un multiplo di
tre ore cumulative di guida. Il conteggio cumulativo è avviato
all’attivazione dell’apparecchio di controllo e non è influenzato
da altre condizioni, come le condizioni«escluso dal campo di
applicazione» o «attraversamento mediante traghetto/treno».
Il periodo di guida cumulativo non è destinato ad essere vi­
sualizzato, stampato o scaricato.
▼B
2 CARATTERISTICHE GENERALI E FUNZIONI DELL'APPA­
RECCHIO DI CONTROLLO
2.1 Caratteristiche generali
L'apparecchio di controllo ha la finalità di registrare, memorizzare,
visualizzare, stampare e trasmettere dati relativi alle attività del
conducente.
I veicoli su cui è montato un apparecchio di controllo conforme alle
disposizioni del presente allegato devono essere muniti di un indi­
catore di velocità e di un odometro. Tali funzioni possono essere
incorporate nell'apparecchio di controllo.
1) L'apparecchio di controllo comprende i cavi, un
sensore di movimento e un'unità elettronica di
bordo.
2) L'interfaccia tra i sensori di movimento e le unità
elettroniche di bordo deve soddisfare le prescri­
zioni specificate nell'appendice 11.
3) L'unità elettronica di bordo deve essere collegata a
uno o più sistemi globali di navigazione satellitare,
come specificato nell'appendice 12.
4) L'unità elettronica di bordo deve comunicare con i
lettori della comunicazione remota a fini di dia­
gnosi precoce, come specificato nell'appendice 14.
▼M3
5) L’unità elettronica di bordo deve comprendere
un’interfaccia ITS, specificata nell’appendice 13.
L’apparecchio di controllo può essere collegato ad
altri dispositivi attraverso interfacce supplementari
e/o l’interfaccia ITS.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 24
6) L'eventuale presenza nell'apparecchio di controllo
di altre funzioni o altri dispositivi, omologati o
meno, o il loro collegamento ad esso non deve
interferire direttamente o indirettamente con il fun­
zionamento corretto e sicuro dell'apparecchio di
controllo e con le disposizioni del presente
regolamento.
Gli utilizzatori dell'apparecchio di controllo sono
identificati dall'apparecchio per mezzo di carte
tachigrafiche.
7) L'apparecchio di controllo fornisce diritti di ac­
cesso selettivi ai dati e alle funzioni, a seconda
del tipo e/o dell'identità dell'utilizzatore.
L'apparecchio di controllo registra e memorizza dati nella sua me­
moria di dati, nel dispositivo di comunicazione remota e sulle carte
tachigrafiche.
▼M3
Queste operazioni sono effettuate in conformità alla legislazione
dell’Unione applicabile in materia di protezione dei dati e in con­
formità all’articolo 7 del regolamento (UE) n. 165/2014.
▼B
2.2 Funzioni
8) L'apparecchio di controllo deve garantire le se­
guenti funzioni:
— controllo dell'inserimento e dell'estrazione
delle carte,
— misurazione della velocità, della distanza e
della posizione,
— misurazione del tempo,
— controllo delle attività del conducente,
— controllo delle condizioni di guida,
▼M3
— immissioni manuali da parte del conducente:
— luogo in cui inizia e/o termina il periodo di
lavoro giornaliero,
— immissione manuale delle attività del con­
ducente e consenso del conducente per
l’interfaccia ITS,
— immissione di condizioni particolari,
— immissione di operazioni di carico/scarico,
▼B
— gestione dei blocchi di un'impresa,
— verifica delle attività di controllo,
— rilevamento di anomalie e/o guasti,
— prove incorporate e prove automatiche,
— lettura della memoria di dati,
— registrazione e memorizzazione nella memoria
di dati,
— lettura delle carte tachigrafiche,
— registrazione e memorizzazione nelle carte
tachigrafiche,
— visualizzazione,
— stampa,
— avvisi,
— trasferimento di dati su dispositivi esterni,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 25
— comunicazione remota per controlli su strada
mirati,
— trasmissione di dati a dispositivi aggiuntivi,
— taratura,
— verifica su strada della taratura,
— regolazione dell'ora,
▼M3
— monitoraggio degli attraversamenti di frontiera,
— aggiornamento software.
▼B
2.3 Modalità di funzionamento
9) L'apparecchio di controllo deve prevedere quattro
modalità di funzionamento:
— modo funzionamento,
— modo controllo,
— modo taratura,
— modo azienda.
10) L'apparecchio di controllo deve passare alla mo­
dalità di funzionamento sotto riportata, a seconda
delle carte tachigrafiche in corso di validità inse­
rite nelle interfacce. Al fine di determinare la mo­
dalità di funzionamento, la generazione della carta
tachigrafica è irrilevante, purché la carta inserita
sia valida. Una carta dell'officina di prima genera­
zione deve essere sempre considerata non valida
quando è inserita in un'unità elettronica di bordo
di seconda generazione.
Modalità di
funzionamento
Sede (slot) del conducente
Carta assente Carta del conducente Carta di controllo Carta dell'officina Carta dell'azienda
S
ed
e
(s
lo
t)
d
el
s
ec
on
do
c
on
du
ce
nt
e Carta assente Funzionamento Funzionamento Controllo Taratura Azienda
Carta del con­
ducente
Funzionamento Funzionamento Controllo Taratura Azienda
Carta di con­
trollo
Controllo Controllo Controllo (*) Funzionamento Funzionamento
Carta dell'offi­
cina
Taratura Taratura Funzionamento Taratura (*) Funzionamento
Carta del­
l'azienda
Azienda Azienda Funzionamento Funzionamento Azienda (*)
(*) In questi casi l'apparecchio di controllo deve usare solo la carta tachigrafica inserita nella sede (slot) del conducente.
11) L'apparecchio di controllo deve ignorare le carte
non valide inserite, fatta salva la possibilità di
visualizzare, stampare o trasferire i dati memoriz­
zati su una carta scaduta.
12) Tutte le funzioni elencate al punto 2.2 devono
essere disponibili in ogni modalità di funziona­
mento, con le seguenti eccezioni:
— la funzione di taratura è accessibile solo nel
modo taratura,
— la funzione di verifica della taratura su strada è
accessibile solo nel modo controllo,
— la funzione di gestione dei blocchi di un'im­
presa è disponibile solo nel modo azienda,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 26
— la verifica delle attività di controllo è disponi­
bile solo nel modo controllo,
▼M3
— la funzione di trasferimento dati non è acces­
sibile nel modo funzionamento, fatta ecce­
zione:
a) per quanto disposto nel requisito 193,
b) per il trasferimento dati dalla carta del con­
ducente quando nella VU non è inserito
nessun altro tipo di carta.
▼B
13) L'apparecchio di controllo può trasmettere qual­
siasi dato al dispositivo di visualizzazione, alla
stampante o a interfacce esterne, con le seguenti
eccezioni:
— nel modo funzionamento, deve essere omessa
ogni identificazione personale (cognome e
nome/i) non corrispondente a una carta tachi­
grafica inserita e va parzialmente omesso (un
carattere sì e uno no, da sinistra a destra) ogni
numero di carta non corrispondente a una carta
tachigrafica inserita,
▼M3
— nel modo azienda, i dati relativi al conducente
(requisiti 102, 105, 108, 133 bis e 133 sexies)
possono essere trasmessi soltanto per i periodi
per cui non esista un blocco o nessun’altra
azienda (identificata dai primi 13 caratteri del
numero della carta dell’azienda) ne abbia atti­
vato uno,
▼B
— se nell'apparecchio di controllo non è inserita
una carta, si possono trasmettere solo i dati
relativi al conducente riferiti al giorno corrente
e agli 8 giorni di calendario precedenti,
▼M3
— i dati personali registrati e prodotti dal tachi­
grafo o dalle carte tachigrafiche non devono
essere trasmessi tramite l’interfaccia ITS della
VU, salvo previa verifica del consenso del
conducente cui i dati si riferiscono,
▼M1
— in condizioni di funzionamento normali le
unità elettroniche di bordo hanno un periodo
di validità di 15 anni dalla data di efficacia dei
relativi certificati, ma possono essere utilizzate
per ulteriori 3 mesi per il solo trasferimento
dei dati.
▼B
2.4 Sicurezza
▼M1
La sicurezza del sistema è intesa a proteggere la memoria di dati in
modo da impedire l’accesso non autorizzato, la manipolazione dei
dati e rilevarne eventuali tentativi, nonché da proteggere l’integrità e
l’autenticità dei dati scambiati tra sensore di movimento e unità
elettronica di bordo, l’integrità e l’autenticità dei dati scambiati tra
l’apparecchio di controllo e le carte tachigrafiche, l’integrità e l’au­
tenticità dei dati scambiati tra l’unità elettronico di bordo e il di­
spositivo GNSS esterno, se presente, la riservatezza, l’integrità e
l’autenticità dei dati scambiati per finalità di controllo tramite la
comunicazione remota a fini di diagnosi precoce e da verificare
l’integrità e l’autenticità dei dati trasferiti.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 27
14) Al fine di garantire la sicurezza del sistema, i
seguenti componenti devono soddisfare i requisiti
di sicurezza specificati nei rispettivi profili di pro­
tezione, come richiesto nell'appendice 10:
— unità elettronica di bordo,
— carta tachigrafica,
— sensore di movimento,
▼M3
— dispositivo GNSS esterno (questo profilo è ne­
cessario e applicabile solo per la variante
esterna del dispositivo GNSS).
▼B
3 REQUISITI DI COSTRUZIONE E FUNZIONAMENTO DEL­
L'APPARECCHIO DI CONTROLLO
3.1 Controllo dell'inserimento e dell'estrazione delle carte
15) L'apparecchio di controllo deve rilevare ogni inse­
rimento ed estrazione di carte nelle relative
interfacce.
▼M3
16) All’atto dell’inserimento della carta (o dell’auten­
ticazione della carta da remoto), l’apparecchio di
controllo deve verificare se la carta è una carta
tachigrafica valida in conformità alla definizione
ee) di cui alla sezione 1 e in tal caso identificarne
il tipo e la generazione.
Per verificare se una carta è già stata inserita,
l’apparecchio di controllo deve utilizzare i dati
della carta tachigrafica memorizzati nella sua me­
moria di dati, come stabilito al requisito 133.
▼B
17) Le carte tachigrafiche di prima generazione de­
vono essere considerate non valide dall'apparec­
chio di controllo dopo che la possibilità di utiliz­
zare carte tachigrafiche di prima generazione è
stata preclusa da un'officina, in conformità all'ap­
pendice 15 (req. MIG003).
18) Le carte dell'officina di prima generazione inserite
nell'apparecchio di controllo di seconda genera­
zione devono essere considerate non valide.
19) L'apparecchio di controllo deve essere realizzato
in modo tale che le carte tachigrafiche vengano
bloccate in posizione quando sono inserite corret­
tamente nelle relative interfacce.
▼M3
20) Le carte tachigrafiche devono poter essere estratte
solo a veicolo fermo e dopo la memorizzazione
dei dati pertinenti nelle carte stesse. L’estrazione
della carta deve richiedere l’intervento fisico
dell’utilizzatore.
▼B
3.2 Misurazione della velocità, della posizione e della distanza
21) Il sensore di movimento (eventualmente incorpo­
rato nell'adattatore) è la principale fonte di misu­
razione della velocità e della distanza.
22) Questa funzione deve misurare costantemente ed
essere in grado di fornire il valore dell'odometro
corrispondente alla distanza totale percorsa dal
veicolo utilizzando gli impulsi provenienti dal sen­
sore di movimento.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 28
23) Questa funzione deve misurare costantemente ed
essere in grado di fornire la velocità del veicolo
utilizzando gli impulsi provenienti dal sensore di
movimento.
24) La funzione di misurazione della velocità deve
inoltre segnalare se il veicolo è in marcia o fermo.
Il veicolo va considerato in marcia non appena la
funzione rileva più di 1 imp/sec per almeno 5 se­
condi sul sensore di movimento, in caso contrario
il veicolo si considera fermo.
25) I dispositivi che visualizzano la velocità (tachime­
tro) e la distanza totale percorsa (odometro), mon­
tati su ogni veicolo munito di un apparecchio di
controllo conforme alle prescrizioni del presente
regolamento, devono soddisfare i requisiti relativi
alle tolleranze massime fissati nel presente allegato
(cfr. punti 3.2.1 e 3.2.2).
▼M3
26) Al fine di individuare una manipolazione dei dati
di movimento, le informazioni provenienti dal sen­
sore di movimento devono essere confermate dalle
informazioni sul movimento del veicolo prove­
nienti dal ricevitore GNSS e da altre fonti indipen­
denti dal sensore di movimento. Almeno un’altra
fonte indipendente di dati di movimento del vei­
colo deve trovarsi all’interno della VU senza che
sia necessaria un’interfaccia esterna.
27) Questa funzione deve misurare la posizione del
veicolo al fine di consentire la registrazione:
— delle posizioni in cui il conducente e/o il se­
condo conducente iniziano il loro periodo di
lavoro giornaliero;
— delle posizioni in cui il periodo di guida cu­
mulativo raggiunge un multiplo di tre ore;
— delle posizioni in cui il veicolo ha attraversato
la frontiera di un paese;
— delle posizioni in cui sono state effettuate le
operazioni di carico/scarico;
— delle posizioni in cui il conducente e/o il se­
condo conducente terminano il loro periodo di
lavoro giornaliero.
▼B
3.2.1 Misurazione della distanza percorsa
28) La distanza percorsa può essere misurata:
— a marcia avanti e a marcia indietro oppure
— unicamente a marcia avanti.
29) L'apparecchio di controllo deve misurare la di­
stanza da 0 a 9 999 999,9 km.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 29
30) La distanza misurata deve rispettare le tolleranze
seguenti (distanze di almeno 1 000 m):
— ± 1 % prima del montaggio,
— ± 2 % all'atto del montaggio e del controllo
periodico,
— ± 4 % durante l'impiego.
▼M3
Le tolleranze non devono essere utilizzate per mo­
dificare intenzionalmente la distanza misurata.
▼B
31) La distanza misurata deve avere una risoluzione
maggiore o uguale a 0,1 km.
3.2.2 Misurazione della velocità
32) L'apparecchio di controllo deve misurare la velo­
cità tra 0 e 220 km/h.
▼M3
33) Per garantire una tolleranza massima sulla velocità
visualizzata di ± 6 km/h durante l’impiego, tenuto
conto di:
— una tolleranza di ± 2 km/h per le variazioni in
ingresso (variazioni degli pneumatici, …),
— una tolleranza di ± 1 km/h per le misurazioni
effettuate durante il montaggio o i controlli
periodici,
l’apparecchio di controllo deve misurare la velo­
cità, per velocità comprese tra 20 e 180 km/h e per
coefficienti caratteristici del veicolo compresi tra
2 400 e 25 000 imp/km, con una tolleranza di
± 1 km/h (a velocità costante).
Nota: la risoluzione della memorizzazione dei dati
apporta una tolleranza supplementare di
± 0,5 km/h alla velocità memorizzata dall’apparec­
chio di controllo.
▼B
34) La velocità deve essere misurata correttamente,
rispettando le tolleranze normali, entro 2 secondi
dalla fine di una variazione di velocità, quando il
tasso di variazione di velocità è inferiore o uguale
a 2m/s 2 .
35) La misurazione della velocità deve avere una riso­
luzione pari a 1 km/h o migliore.
3.2.3 Misurazione della posizione
36) L'apparecchio di controllo deve misurare la posi­
zione assoluta del veicolo utilizzando il ricevitore
GNSS.
▼M3
37) La posizione assoluta deve essere misurata in co­
ordinate geografiche di latitudine e longitudine in
gradi e minuti con una risoluzione di 1/10 di
minuto.
▼B
3.3 Misurazione del tempo
38) La funzione di misurazione del tempo deve misu­
rare costantemente ed indicare data e ora UTC in
formato digitale.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 30
39) La data e l'ora UTC vanno usate per datare tutti i
dati dell'apparecchio di controllo (registrazioni,
scambio di dati) e per tutti i documenti stampati
di cui all'appendice 4 «Documenti stampati».
40) Al fine di visualizzare l'ora locale, deve poter es­
sere possibile regolare l'ora visualizzata in inter­
valli di mezz'ora. Non devono essere possibili re­
golazioni diverse dai multipli positivi o negativi
della mezz'ora.
▼M3
41) In assenza di regolazioni dell’ora, lo sfasamento
dell’ora deve essere al massimo di ± 1 secondo al
giorno, in condizioni di temperatura conformi al
requisito 213.
41 bis) L’accuratezza dell’orario quando l’orario è rego­
lato dalle officine conformemente al requisito 212
deve essere di 3 secondi o migliore.
41 ter) L’unità elettronica di bordo deve comprendere un
contatore dello sfasamento, che calcola lo sfasa­
mento massimo dell’ora dall’ultima regolazione in
conformità al punto 3.23. Lo sfasamento massimo
dell’ora deve essere definito dal fabbricante
dell’unità elettronica di bordo e non deve superare
1 secondo al giorno, come stabilito al requisito 41.
41 quater) Il contatore dello sfasamento deve essere riportato
a 1 secondo dopo ogni regolazione dell’ora
dell’apparecchio di controllo conformemente al
punto 3.23. Tali regolazioni includono:
— regolazioni automatiche dell’ora,
— regolazioni dell’ora effettuate in modo taratura.
▼B
42) L'ora misurata deve avere una risoluzione pari a
1 secondo o migliore.
43) La misurazione dell'ora non deve essere compro­
messa da un'interruzione dell'alimentazione esterna
inferiore a 12 mesi in condizioni di omologazione.
3.4 Controllo delle attività del conducente
44) Questa funzione deve controllare costantemente e
separatamente le attività di un conducente e di
un secondo conducente.
45) Le attività del conducente sono GUIDA, LA­
VORO, DISPONIBILITÀ e INTERRUZIONE/RI­
POSO.
46) Il conducente e/o il secondo conducente devono
poter selezionare manualmente LAVORO, DI­
SPONIBILITÀ o INTERRUZIONE/RIPOSO.
47) Quando il veicolo è in marcia, devono essere au­
tomaticamente selezionati GUIDA per il condu­
cente e DISPONIBILITÀ per il secondo
conducente.
48) Quando il veicolo si arresta, deve essere automa­
ticamente selezionato LAVORO per il conducente.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 31
49) Il primo passaggio di attività a INTERRUZIONE/
RIPOSO o DISPONIBILITÀ che si verifica entro
120 secondi dalla selezione automatica di LA­
VORO dovuta all’arresto del veicolo va conside­
rato avvenuto al momento dell’arresto del veicolo
(annullando eventualmente il passaggio a LA­
VORO).
▼B
50) Questa funzione deve trasmettere i cambi di atti­
vità alle funzioni di registrazione con una risolu­
zione di un minuto.
51) Dato un intervallo di un minuto, se GUIDA è
registrata come attività del minuto immediata­
mente precedente e del minuto immediatamente
successivo, l'intero minuto va considerato come
GUIDA.
52) Dato un intervallo di un minuto non considerato
come GUIDA in base al requisito 051, l'intero
minuto va considerato come attività dello stesso
tipo di quella continua di maggiore durata verifi­
catasi entro tale minuto (o, nel caso di più attività
di pari durata, dell'ultima di esse).
53) Questa funzione deve controllare inoltre costante­
mente il periodo di guida continuo e il periodo
cumulato di interruzione del conducente.
3.5 Controllo delle condizioni di guida
54) Questa funzione deve controllare costantemente ed
automaticamente le condizioni di guida.
55) La condizione di guida EQUIPAGGIO deve essere
selezionata quando nell'apparecchio sono inserite
due carte del conducente in corso di validità; in
ogni altro caso deve essere selezionata la condi­
zione di guida SINGOLA.
3.6 Immissioni da parte del conducente
3.6.1 Immissione del luogo in cui inizia e/o termina il periodo di lavoro
giornaliero
56) Questa funzione deve consentire l'immissione del
luogo in cui, secondo il conducente e/o il secondo
conducente, il suo periodo di lavoro giornaliero
inizia e/o termina.
▼M3
57) Per luogo si intende il paese e, se del caso, anche
la regione.
58) All’atto dell’estrazione della carta del conducente
(o dell’officina), l’apparecchio di controllo deve
visualizzare il luogo in cui il veicolo si trova in
quel momento sulla base delle informazioni GNSS
e della mappa digitale memorizzata conforme­
mente al punto 3.12.19 e deve chiedere al titolare
della carta di confermare o rettificare manualmente
il luogo.
59) Il luogo inserito conformemente al requisito 58
deve essere considerato il luogo in cui termina il
periodo di lavoro giornaliero. Esso deve essere
registrato nella pertinente carta del conducente (o
dell’officina) come registrazione temporanea, e
può quindi essere successivamente sovrascritto.
Alle condizioni riportate di seguito sono convali­
dati (cioè non saranno più sovrascritti) i dati tem­
poranei immessi al momento dell’ultima estrazione
della carta:
— immissione di un luogo in cui inizia il periodo
di lavoro giornaliero in corso durante l’immis­
sione manuale conformemente al requisito 61;
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 32
— immissione successiva di un luogo in cui inizia
il periodo di lavoro giornaliero in corso se il
titolare della carta non immette alcun luogo di
inizio o fine del periodo di lavoro durante
l’immissione manuale conformemente al requi­
sito 61.
Alle condizioni riportate di seguito i dati tempo­
ranei immessi al momento dell’ultima estrazione
della carta sono sovrascritti e viene convalidato
il nuovo valore:
— immissione successiva di un luogo in cui ter­
mina il periodo di lavoro giornaliero in corso
se il titolare della carta non immette alcun
luogo di inizio o fine del periodo di lavoro
durante l’immissione manuale conformemente
al requisito 61.
▼B
60) I luoghi in cui iniziano e/o terminano i periodi di
lavoro giornalieri devono poter essere immessi
mediante comandi dei menù. Se durante un inter­
vallo di un minuto viene immesso più di uno di
tali dati, va conservata esclusivamente la registra­
zione dell'ultima immissione di inizio e dell'ultima
immissione di fine effettuata in tale intervallo.
▼M3
L’apparecchio di controllo deve visualizzare il
luogo in cui il veicolo si trova in quel momento
sulla base delle informazioni GNSS e delle mappe
digitali memorizzate conformemente al
punto 3.12.19 e deve chiedere al conducente di
confermare o rettificare manualmente il luogo.
▼B
3.6.2 Immissione manuale delle attività del conducente e consenso del
conducente per l'interfaccia ITS
▼M3
61) All’atto dell’inserimento della carta del condu­
cente (o dell’officina), ed esclusivamente in tale
momento, l’apparecchio di controllo deve consen­
tire l’immissione manuale di attività. L’immissione
manuale di attività deve essere effettuata utiliz­
zando i valori dell’ora locale e della data del
fuso orario (regolazione UTC) impostato in quel
momento per l’unità elettronica di bordo.
All’atto dell’inserimento della carta del condu­
cente o dell’officina, al titolare della carta devono
essere comunicate:
— la data e l’ora dell’ultima estrazione della
carta;
— facoltativamente, la regolazione dell’ora locale
impostata in quel momento per l’unità elettro­
nica di bordo.
All’atto del primo inserimento di una carta del
conducente o dell’officina sconosciuta all’unità
elettronica di bordo, il titolare della carta deve
essere invitato a dare il proprio consenso alla tra­
smissione di dati personali connessi al tachigrafo
tramite l’interfaccia ITS. Per verificare se una
carta è già stata inserita, l’apparecchio di controllo
deve utilizzare i dati della carta tachigrafica me­
morizzati nella sua memoria di dati, come stabilito
al requisito 133.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 33
In qualsiasi momento il consenso del conducente
(o dell’officina) può essere abilitato o disabilitato
mediante comandi del menù, purché la carta del
conducente (o dell’officina) sia inserita.
L’immissione di attività deve essere possibile, ma
con le seguenti restrizioni:
— i tipi di attività devono essere: LAVORO, DI­
SPONIBILITÀ e INTERRUZIONE/RIPOSO;
— le ore di inizio e di fine per ciascuna attività
devono rientrare esclusivamente nel periodo
compreso tra l’ultima estrazione della carta e
l’inserimento della carta in corso;
— non deve essere consentita la sovrapposizione
reciproca nel tempo delle attività.
L’immissione manuale deve essere possibile, se
richiesta, all’atto del primo inserimento di una
carta del conducente (o dell’officina) precedente­
mente inutilizzata.
La procedura di immissione manuale dei dati sulle
attività deve comprendere tutte le fasi consecutive
necessarie per inserire, per ciascuna attività, il
tipo, l’ora di inizio e l’ora di fine. Per ogni parte
del periodo compreso tra l’ultima estrazione della
carta e l’inserimento della carta in corso, il titolare
della carta deve avere la possibilità di non dichia­
rare alcuna attività.
Nel corso dell’immissione manuale di attività as­
sociate all’inserimento della carta, il titolare della
carta, se del caso, deve avere la possibilità di
indicare:
— il luogo in cui si è concluso il precedente pe­
riodo di lavoro giornaliero associato all’ora
pertinente (sovrascrivendo e convalidando
così il dato inserito al momento dell’ultima
estrazione della carta);
— il luogo in cui ha inizio il periodo di lavoro
giornaliero in corso associato all’ora pertinente
(convalidando così il dato temporaneo inserito
al momento dell’ultima estrazione della carta).
Per il luogo in cui ha inizio il periodo di lavoro
giornaliero in corso immesso al momento dell’in­
serimento della carta, l’apparecchio di controllo
deve visualizzare il luogo in cui il veicolo si trova
in quel momento sulla base delle informazioni
GNSS e delle mappe digitali memorizzate confor­
memente al punto 3.12.19 e deve chiedere al con­
ducente di confermare o rettificare manualmente il
luogo.
La mancata immissione da parte del titolare della
carta di un luogo di inizio o fine del periodo di
lavoro durante le immissioni manuali associate
all’inserimento della carta è da considerarsi equi­
valente a una dichiarazione del fatto che il suo
periodo di lavoro non è cambiato dall’ultima estra­
zione della carta. La successiva immissione di un
luogo in cui termina un periodo di lavoro giorna­
liero precedente deve allora sovrascrivere il dato
temporaneo immesso al momento dell’ultima
estrazione della carta.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 34
Se viene inserito un luogo, l’informazione relativa
deve essere registrata nella carta tachigrafica
pertinente.
Le immissioni manuali devono interrompersi:
— in caso di estrazione della carta, oppure
— se il veicolo è in movimento e la carta è inse­
rita nella sede (slot) del conducente.
Sono consentite ulteriori interruzioni, ad esempio
dopo un periodo di inattività dell’utente. In caso di
interruzione delle immissioni manuali, l’apparec­
chio di controllo deve convalidare tutte le indica­
zioni complete di luogo e attività già inserite (che
indichino senza ambiguità un luogo e un’ora o un
tipo di attività e un’ora di inizio e di fine).
Qualora venga inserita una seconda carta del con­
ducente o dell’officina mentre è in corso l’immis­
sione manuale di dati di attività relative alla carta
precedentemente inserita, tale immissione manuale
deve poter essere completata prima che abbia ini­
zio l’immissione manuale dei dati relativi alla se­
conda carta.
Il titolare della carta deve avere la possibilità di
effettuare l’immissione manuale di dati secondo la
seguente procedura minima:
— immissione manuale di attività in ordine cro­
nologico per il periodo compreso tra l’ultima
estrazione della carta e l’inserimento in corso.
— l’ora di inizio della prima attività deve essere
fissata al momento dell’estrazione della carta.
Per ciascuna immissione di dati successiva,
l’ora di inizio deve essere fissata in modo da
seguire immediatamente l’ora di fine dell’im­
missione di dati precedente. Per ciascuna atti­
vità devono essere selezionati il tipo e l’ora di
fine.
La procedura è completata quando l’ora in cui
termina un’attività inserita manualmente corri­
sponde all’ora di inserimento della carta.
L’apparecchio di controllo deve consentire ai con­
ducenti e alle officine di caricare alternativamente
le immissioni manuali che devono essere inserite
durante la procedura attraverso l’interfaccia ITS di
cui all’appendice 13 e, facoltativamente, attraverso
altre interfacce.
L’apparecchio di controllo deve consentire al tito­
lare della carta di modificare ogni attività inserita
manualmente, fino alla convalida mediante un co­
mando specifico. Successivamente tali modifiche
non devono più essere consentite.
▼B
3.6.3 Immissione di condizioni particolari
▼M3
62) L’apparecchio di controllo deve consentire al con­
ducente di inserire, in tempo reale, le due condi­
zioni particolari seguenti:
— «ESCLUSO DAL CAMPO DI APPLICA­
ZIONE» (inizio, fine),
— «ATTRAVERSAMENTO MEDIANTE TRA­
GHETTO/TRENO» (inizio, fine).
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 35
Un «ATTRAVERSAMENTO MEDIANTE TRA­
GHETTO/TRENO» non deve potersi verificare se
è attiva la condizione «ESCLUSO DAL CAMPO
DI APPLICAZIONE». Se è attiva la condizione
«ESCLUSO DAL CAMPO DI APPLICA­
ZIONE», l’apparecchio di controllo non deve con­
sentire agli utenti di inserire l’indicatore (flag) di
inizio dell’«ATTRAVERSAMENTO MEDIANTE
TRAGHETTO/TRENO».
La condizione «ESCLUSO DAL CAMPO DI AP­
PLICAZIONE» deve essere automaticamente di­
sattivata, dall’apparecchio di controllo, quando
viene inserita o estratta una carta del conducente.
La condizione «ESCLUSO DAL CAMPO DI AP­
PLICAZIONE» attiva deve inibire i seguenti av­
visi e le seguenti anomalie:
— guida in assenza di una carta adeguata;
— avvisi relativi al periodo di guida continuo.
Il conducente deve inserire l’indicatore (flag) di
inizio dell’ATTRAVERSAMENTO MEDIANTE
TRAGHETTO/TRENO immediatamente dopo
aver selezionato INTERRUZIONE/RIPOSO sul
traghetto o sul treno.
La condizione ATTRAVERSAMENTO ME­
DIANTE TRAGHETTO/TRENO deve essere di­
sattivata dall’apparecchio di controllo quando si
verifica uno dei seguenti casi:
— il conducente disattiva manualmente la condi­
zione ATTRAVERSAMENTO MEDIANTE
TRAGHETTO/TRENO, operazione che deve
essere effettuata all’arrivo a destinazione del
traghetto/treno, prima di scendere dallo stesso,
— è attiva la condizione «ESCLUSO DAL
CAMPO DI APPLICAZIONE»,
— il conducente espelle la sua carta,
— l’attività del conducente è calcolata come
GUIDA per un minuto conformemente al
punto 3.4.
Se nell’intervallo di un minuto viene immessa più
di una condizione specifica dello stesso tipo, solo
l’ultima deve essere registrata.
3.6.4 Immissione di un’operazione di carico/scarico
62 bis) L’apparecchio di controllo deve consentire al con­
ducente di inserire e confermare, in tempo reale,
informazioni indicanti che è in corso il carico o lo
scarico di un veicolo, o che è in corso un’opera­
zione di carico/scarico simultanei.
Se nell’intervallo di un minuto viene immessa più
di un’operazione di carico/scarico dello stesso
tipo, solo l’ultima deve essere registrata.
62 ter) Le operazioni di carico, scarico o carico/scarico
simultanei devono essere registrate come eventi
distinti.
62 quater) Le informazioni sul carico/scarico devono essere
inserite prima che il veicolo lasci il luogo in cui si
effettua l’operazione di carico/scarico.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 36
3.7 Gestione dei blocchi di un'impresa
63) Questa funzione deve consentire di gestire i bloc­
chi previsti da un'impresa per limitare a se stessa
l'accesso ai dati nel modo azienda.
64) I blocchi di un'impresa consistono in una data/ora
di inizio (attivazione blocco) e in una data/ora di
termine (disattivazione blocco), associate all'iden­
tificazione dell'impresa risultante dal numero della
carta dell'azienda (all'attivazione del blocco).
65) I blocchi possono essere attivati o disattivati solo
in tempo reale.
66) Il blocco deve poter essere disattivato solo dall'im­
presa il cui blocco è attivo (identificata dai primi
13 caratteri del numero della carta dell'azienda)
oppure
67) la disattivazione del blocco deve avvenire automa­
ticamente quando un'altra impresa attiva un
blocco.
68) Nel caso in cui un'impresa attivi un blocco e che il
blocco precedente fosse della stessa impresa, al­
lora si riterrà che il blocco precedente non sia
stato disattivato e che sia tuttora attivato.
3.8 Verifica delle attività di controllo
69) Questa funzione deve verificare le attività di con­
trollo «VISUALIZZAZIONE, STAMPA, TRA­
SFERIMENTO dati della VU e della carta» e
«TARATURA SU STRADA» nel modo controllo.
70) Essa deve inoltre verificare le attività di «CON­
TROLLO SUPERAMENTO DELLA VELO­
CITÀ» nel modo controllo. Un controllo del su­
peramento della velocità si considera avvenuto
quando, nel modo controllo, l'informazione «supe­
ramento della velocità» viene inviata alla stam­
pante o al dispositivo di visualizzazione oppure
quando i dati relativi ad «anomalie e guasti» ven­
gono trasferiti dalla memoria di dati della VU.
3.9 Rilevamento di anomalie e/o guasti
71) Questa funzione deve rilevare le anomalie e/o i
guasti seguenti:
3.9.1 Anomalia «Inserimento di una carta non valida»
72) Questa anomalia deve attivarsi all'inserimento di
una carta non valida, all'inserimento di una carta
del conducente già sostituita e/o quando una carta
inserita in corso di validità scade.
3.9.2 Anomalia «Conflitto di carte»
73) Questa anomalia deve attivarsi quando si verifica
una combinazione di carte in corso di validità in­
dicata con X nella tabella seguente:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 37
Conflitto di carte
Sede (slot) del conducente
Carta assente
Carta del condu­
cente
Carta di controllo Carta dell'officina Carta dell'azienda
S
ed
e
(s
lo
t)
d
el
s
ec
on
do

co
nd
uc
en
te

Carta assente
Carta del conducente X
Carta di controllo X X X
Carta dell'officina X X X X
Carta dell'azienda X X X
3.9.3 Anomalia «Sovrapposizione di orari»
74) Questa anomalia deve attivarsi quando la data/ora
dell'ultima estrazione di una carta del conducente,
letta sulla carta, è successiva alla data/ora corrente
dell'apparecchio di controllo in cui è inserita la
carta.
3.9.4 Anomalia «Guida in assenza di una carta adeguata»
75) Questa anomalia deve attivarsi per ogni combina­
zione valida di carte tachigrafiche indicata con X
nella tabella seguente, quando l'attività del condu­
cente passa a GUIDA o quando si verifica un cam­
bio di modalità di funzionamento mentre l'attività
del conducente è GUIDA:
Guida in assenza di una carta
adeguata
Sede (slot) del conducente
Carta assente (o
carta non valida)
Carta del condu­
cente
Carta di controllo Carta dell'officina Carta dell'azienda
S
ed
e
(s
lo
t)
d
el
s
ec
on
do

co
nd
uc
en
te

Carta assente (o carta
non valida)
X X X
Carta del conducente X X X X
Carta di controllo X X X X X
Carta dell'officina X X X X
Carta dell'azienda X X X X X
3.9.5 Anomalia «Inserimento carta durante la guida»
76) Questa anomalia deve attivarsi quando una carta
tachigrafica viene inserita in qualsiasi sede, mentre
l'attività del conducente è GUIDA.
3.9.6 Anomalia «Chiusura errata ultima sessione carta»
77) Questa anomalia deve attivarsi quando all'inseri­
mento della carta l'apparecchio di controllo rileva
che, nonostante le prescrizioni di cui al punto 3.1,
la sessione precedente della carta non è stata chiusa
in modo corretto (la carta è stata estratta prima che
tutti i dati pertinenti fossero memorizzati sulla carta
stessa). Questa anomalia deve attivarsi solo per le
carte del conducente e dell'officina.
3.9.7 Anomalia «Superamento della velocità»
78) Questa anomalia deve attivarsi ad ogni supera­
mento della velocità autorizzata.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 38
3.9.8 Anomalia «Interruzione dell'alimentazione di energia»
79) Quando l'apparecchio non si trova nel modo tara­
tura o nel modo controllo, questa anomalia deve
attivarsi nel caso di un'interruzione dell'alimenta­
zione del sensore di movimento e/o dell'unità elet­
tronica di bordo di durata superiore a 200 millise­
condi. La soglia di interruzione deve essere defi­
nita dal fabbricante. La caduta di alimentazione
dovuta all'avviamento del motore del veicolo non
deve attivare questa anomalia.
3.9.9 Anomalia «Errore di comunicazione con il dispositivo di comunica­
zione remota»
80) Questa anomalia deve attivarsi, quando non è
attivo il modo taratura, quando il dispositivo di
comunicazione remota non riconosce l'avvenuta
ricezione dei dati della comunicazione remota in­
viati dall'unità elettronica di bordo per più di tre
tentativi.
3.9.10 Anomalia «Assenza di informazioni sulla posizione provenienti dal
ricevitore GNSS»
81) Questa anomalia deve attivarsi, quando non è
attivo il modo taratura, in caso di assenza di
informazioni sulla posizione provenienti dal rice­
vitore GNSS (sia interno che esterno) per più di
tre ore di periodo di guida cumulato.
3.9.11 Anomalia «Errore di comunicazione con il dispositivo GNSS
esterno»
82) Questa anomalia deve attivarsi, quando non è
attivo il modo taratura, in caso di interruzione
della comunicazione tra il dispositivo GNSS
esterno e l'unità elettronica di bordo per più di
20 minuti consecutivi, quando il veicolo è in
movimento.
3.9.12 Anomalia «Errore dati di marcia»
▼M3
83) Questa anomalia deve attivarsi, quando non è
attivo il modo taratura, in caso di interruzione
del normale flusso di dati tra il sensore di movi­
mento e l’unità elettronica di bordo e/o in caso di
errore di integrità dei dati o di autenticazione dei
dati durante lo scambio di dati tra il sensore di
movimento e l’unità elettronica di bordo. Questa
anomalia deve inoltre attivarsi, quando non è at­
tivo il modo taratura, se la velocità calcolata a
partire dagli impulsi del sensore di movimento
aumenta da 0 a più di 40 km/h in 1 secondo e
rimane quindi superiore a 40 km/h per almeno 3
secondi.
▼B
3.9.13 Anomalia «Dati contrastanti sul movimento del veicolo»
▼M3
84) Come specificato nell’appendice 12, questa ano­
malia deve attivarsi, quando non è attivo il
modo taratura, nel caso in cui le informazioni
sul movimento calcolate dal sensore di movimento
siano contraddette dalle informazioni sul movi­
mento calcolate dal ricevitore GNSS interno o
dal dispositivo GNSS esterno o da altre fonti in­
dipendenti conformemente al requisito 26. Questa
anomalia non deve attivarsi durante un attraversa­
mento mediante traghetto/treno.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 39
3.9.14 Anomalia «Tentata violazione della sicurezza»
85) Questa anomalia deve attivarsi, quando non è at­
tivo il modo taratura, in caso di ogni altra anoma­
lia che influisca sulla sicurezza del sensore di mo­
vimento e/o dell'unità elettronica di bordo e/o del
dispositivo GNSS esterno, come richiesto nell'ap­
pendice 10.
▼M1
3.9.15 Anomalia «Conflitto di orari»
▼M3
86) Questa anomalia deve attivarsi, quando non è
attivo il modo taratura, qualora la VU rilevi
una discrepanza tra l’orario della funzione di mi­
surazione del tempo dell’unità elettronica di bordo
e l’orario proveniente dalle posizioni autenticate
trasmesse dal ricevitore GNSS o dal dispositivo
GNSS esterno. Si rileva una «discrepanza di ora­
rio» se la differenza tra gli orari è superiore a
± 3 secondi, corrispondente all’accuratezza di cui
al requisito 41 bis; quest’ultima è aumentata dello
sfasamento massimo dell’ora giornaliero. Questa
anomalia deve essere registrata insieme al valore
dell’orologio interno dell’apparecchio di controllo.
La VU deve effettuare il controllo per attivare
l’anomalia «Conflitto di orari» subito prima di
regolare automaticamente il suo orologio interno,
in conformità al requisito 211.
▼B
3.9.16 Guasto «Carta»
87) Questo guasto deve attivarsi in caso di funziona­
mento difettoso della carta tachigrafica.
3.9.17 Guasto «Apparecchio di controllo»
88) Questo guasto deve attivarsi, quando non è attivo
il modo taratura, in ciascuno dei casi seguenti:
— guasto interno della VU
— guasto della stampante
— guasto del dispositivo di visualizzazione
— guasto nel trasferimento di dati
— guasto del sensore
— guasto del ricevitore GNSS o del dispositivo
GNSS esterno
— guasto del dispositivo di comunicazione re­
mota
▼M3
— guasto dell’interfaccia ITS.
3.9.18 Anomalia «Anomalia GNSS»
88 bis) «Questa anomalia deve attivarsi, quando non è
attivo il modo taratura, qualora il ricevitore
GNSS rilevi un attacco o l’autenticazione dei mes­
saggi di navigazione non vada a buon fine, come
specificato nell’appendice 12. Dopo che si è atti­
vata un’anomalia di tipo “Anomalia GNSS”, la
VU non deve generare anomalie GNSS per i suc­
cessivi 10 minuti.»;
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 40
3.10 Prove incorporate e prove automatiche
89) ►M1 L’apparecchio di controllo deve rilevare i gua­
sti mediante prove automatiche e prove incorporate,
secondo la tabella seguente: ◄
Sottoinsieme da sottoporre a
prova
Prova automatica Prova incorporata
Software Integrità
Memoria di dati Accesso Accesso, integrità dei
dati
Dispositivi di interfaccia
della carta
Accesso Accesso
Tastiera Controllo manuale
Stampante (a discrezione del
fabbricante)
Stampa
Schermo Controllo visivo
Trasferimento dati
(effettuato solo durante il
trasferimento dati)
Funzionamento cor­
retto
Sensore Funzionamento cor­
retto
Funzionamento corretto
Dispositivo di comunica­
zione remota
Funzionamento cor­
retto
Funzionamento corretto
Dispositivo GNSS Funzionamento cor­
retto
Funzionamento corretto
▼M3
Interfaccia ITS Funzionamento cor­
retto
▼B
3.11 Lettura della memoria di dati
90) L'apparecchio di controllo deve essere in grado di
leggere ogni dato memorizzato nella sua memoria
di dati.
3.12 Registrazione e memorizzazione nella memoria di dati
▼M3
Ai fini del presente punto,
— per «365 giorni» si intende 365 giorni di calendario di attività
media del conducente su un veicolo. Per attività media giorna­
liera su un veicolo si intende almeno 6 conducenti o secondi
conducenti, 6 cicli di inserimento ed estrazione della carta e 256
cambi di attività. «365 giorni» comprendono quindi almeno
2 190 conducenti o secondi conducenti, 2 190 cicli di inseri­
mento ed estrazione della carta e 93 440 cambi di attività,
— per numero medio giornaliero di luoghi immessi si intende almeno 6
immissioni in cui inizia il periodo di lavoro giornaliero e 6 immis­
sioni in cui termina il periodo di lavoro giornaliero, in modo che i
«365 giorni» comprendano almeno 4 380 luoghi immessi,
— per numero medio giornaliero di posizioni in cui il periodo di
guida cumulativo raggiunge un multiplo di tre ore si intende
almeno 6 posizioni, in modo che i «365 giorni» comprendano
almeno 2 190 di tali posizioni,
— per numero medio giornaliero di attraversamenti di frontiera si
intende almeno 20 attraversamenti, in modo che i «365 giorni»
comprendano almeno 7 300 attraversamenti di frontiera;
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 41
— per numero medio giornaliero di operazioni di carico/scarico si
intende almeno 25 operazioni (indipendentemente dal tipo), in
modo che i «365 giorni» comprendano almeno 9 125 operazioni
di carico/scarico;
— se non diversamente specificato, i tempi sono registrati con una
risoluzione di un minuto,
— i valori dell’odometro sono registrati con una risoluzione di un
chilometro,
— le velocità sono registrate con una risoluzione di 1 km/h,
— le posizioni (latitudini e longitudini) sono registrate in gradi e
minuti, con una risoluzione di 1/10 di minuto, con il tempo di
acquisizione e l’accuratezza del GNSS ad esse associati e con un
indicatore che segnala se la posizione è stata autenticata.
▼B
91) I dati memorizzati nella memoria di dati non de­
vono essere compromessi da un'interruzione del­
l'alimentazione esterna di durata inferiore a dodici
mesi in condizioni di omologazione. Inoltre, i dati
archiviati nel dispositivo esterno di comunicazione
remota, come definito nell'appendice 14, non de­
vono essere compromessi da un'interruzione del­
l'alimentazione di durata inferiore a 28 giorni.
92) L'apparecchio di controllo deve essere in grado di
registrare e memorizzare implicitamente o esplici­
tamente nella sua memoria di dati le informazioni
sotto elencate.
3.12.1 Dati di identificazione dell'apparecchio
3.12.1.1 D a t i d i i d e n t i f i c a z i o n e d e l l ' u n i t à e l e t t r o n i c a d i
b o r d o
93) L'apparecchio di controllo deve essere in grado di
memorizzare nella sua memoria di dati i seguenti
dati di identificazione dell'unità elettronica di
bordo:
— nome del fabbricante,
— indirizzo del fabbricante,
— codice componente,
— numero di serie,
— generazione della VU,
— capacità di utilizzare carte tachigrafiche di
prima generazione,
— numero di versione del software,
— data di installazione della versione del
software,
— anno di fabbricazione dell'apparecchio,
— numero di omologazione ,
▼M3
— identificativo della versione della mappa digi­
tale (requisito 133 terdecies).
94) I dati di identificazione dell’unità elettronica di
bordo sono registrati e memorizzati una sola volta
dal fabbricante dell’unità, ad eccezione dei dati
che possono essere modificati in caso di aggiorna­
mento software in conformità al presente regola­
mento, e della capacità di utilizzare carte tachigra­
fiche di prima generazione.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 42
3.12.1.2 D a t i d i i d e n t i f i c a z i o n e d e l s e n s o r e d i m o v i ­
m e n t o
95) Il sensore di movimento deve essere in grado di
memorizzare nella sua memoria i seguenti dati di
identificazione:
— nome del fabbricante,
— numero di serie,
— numero di omologazione,
— identificativo del componente di sicurezza in­
corporato (per es., codice componente del
chip/processore interno),
— identificativo del sistema operativo (per es.,
numero di versione del software).
96) I dati di identificazione del sensore di movimento
sono registrati e memorizzati una sola volta dal
fabbricante del sensore.
▼M3
97) L’unità elettronica di bordo deve essere in grado
di registrare e memorizzare nella sua memoria di
dati i seguenti dati relativi agli ultimi 20 abbina­
menti con esito positivo dei sensori di movimento
(se in un giorno di calendario avvengono più ab­
binamenti, si registrano solo il primo e l’ultimo):
▼B
Per ciascuno di tali abbinamenti si devono regi­
strare i dati seguenti:
— dati di identificazione del sensore di
movimento:
— numero di serie
— numero di omologazione
— dati di abbinamento al sensore di movimento:
— data dell'abbinamento.
3.12.1.3 D a t i d i i d e n t i f i c a z i o n e d e i s i s t e m i g l o b a l i d i
n a v i g a z i o n e s a t e l l i t a r e
98) Il dispositivo GNSS esterno deve essere in grado
di memorizzare nella sua memoria i seguenti dati
di identificazione:
— nome del fabbricante,
— numero di serie,
— numero di omologazione,
— identificativo del componente di sicurezza in­
corporato (per es., codice componente del
chip/processore interno),
— identificativo del sistema operativo (per es.,
numero di versione del software).
99) I dati di identificazione sono registrati e memoriz­
zati una sola volta nel dispositivo GNSS esterno
dal fabbricante dello stesso.
▼M3
100) L’unità elettronica di bordo deve essere in grado
di registrare e memorizzare nella sua memoria di
dati i seguenti dati relativi agli ultimi 20 accop­
piamenti con esito positivo dei dispositivi GNSS
esterni (se in un giorno di calendario avvengono
più accoppiamenti, si registrano solo il primo e
l’ultimo).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 43
Per ciascuno di tali accoppiamenti devono essere
registrati i dati seguenti:
— dati di identificazione del dispositivo GNSS
esterno:
— numero di serie,
— numero di omologazione,
— dati di accoppiamento al dispositivo GNSS
esterno:
— data dell'accoppiamento
3.12.2 Chiavi e certificati
101) L'apparecchio di controllo deve essere in grado di
memorizzare una serie di chiavi crittografiche e di
certificati, come specificato nell'appendice 11,
parti A e B.
3.12.3 Dati relativi all'inserimento e all'estrazione della carta del condu­
cente o dell'officina
102) Per ogni ciclo di inserimento ed estrazione dall'ap­
parecchio di una carta del conducente o dell'offi­
cina, l'apparecchio di controllo deve registrare e
memorizzare nella sua memoria di dati:
— cognome e nome/i del titolare della carta, me­
morizzati nella carta stessa,
— numero della carta, Stato membro che l'ha rila­
sciata e data di scadenza, memorizzati nella
carta stessa,
— generazione della carta,
— data e ora di inserimento,
— valore dell'odometro del veicolo all'atto dell'in­
serimento,
— sede (slot) in cui è inserita la carta,
— data e ora di estrazione,
— valore dell'odometro del veicolo all'atto del­
l'estrazione,
— le seguenti informazioni relative al veicolo
usato in precedenza dal conducente, memoriz­
zate nella carta:
— VRN e Stato membro di immatricolazione,
— generazione della VU (se disponibile),
— data e ora di estrazione della carta,
— un indicatore (flag) che segnali se, all'atto del­
l'inserimento della carta, il titolare della carta
abbia o meno inserito manualmente le attività.
103) La memoria di dati deve essere in grado di con­
servare tali informazioni per almeno 365 giorni.
104) Qualora si esaurisca la capacità di memorizza­
zione, i dati nuovi devono sostituire quelli meno
recenti.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 44
3.12.4 Dati relativi all'attività del conducente
105) L'apparecchio di controllo deve registrare e memo­
rizzare nella sua memoria di dati, ogniqualvolta si
verifichi un cambio di attività del conducente e/o
del secondo conducente e/o ogniqualvolta si veri­
fichi una variazione della condizione di guida e/o
ogniqualvolta venga inserita o estratta una carta
del conducente o dell'officina:
— la condizione di guida (EQUIPAGGIO, SIN­
GOLA),
— la sede (slot) (CONDUCENTE, SECONDO
CONDUCENTE),
— la condizione della carta nella relativa sede
(slot) (INSERITA, NON INSERITA),
— l'attività (GUIDA, DISPONIBILITÀ, LA­
VORO, INTERRUZIONE/RIPOSO),
— la data e l'ora del cambio.
INSERITA significa che una carta del conducente
o dell'officina in corso di validità è inserita nella
sede (slot). NON INSERITA significa il contrario,
cioè che nella sede non è inserita una carta del
conducente o dell'officina in corso di validità (per
es., è inserita una carta dell'azienda oppure non è
inserita alcuna carta).
I dati relativi all'attività inseriti manualmente dal
conducente non vengono registrati nella memoria
di dati.
106) La memoria di dati deve essere in grado di con­
servare i dati relativi all'attività del conducente per
almeno 365 giorni.
107) Qualora si esaurisca la capacità di memorizza­
zione, i dati nuovi devono sostituire quelli meno
recenti.
▼M1
3.12.5 Luoghi e posizioni dove iniziano e terminano i periodi di lavoro
giornalieri e/o dove il periodo di guida cumulativo raggiunge le 3
ore
108) L’apparecchio di controllo deve registrare e me­
morizzare nella sua memoria di dati:
— i luoghi e le posizioni in cui il conducente e/o
il secondo conducente iniziano il loro periodo
di lavoro giornaliero;
— le posizioni in cui il periodo di guida cumula­
tivo raggiunge un multiplo di tre ore;
— i luoghi e le posizioni in cui il conducente e/o
il secondo conducente terminano il loro pe­
riodo di lavoro giornaliero.
▼B
109) Quando la posizione del veicolo non è rilevabile
dal ricevitore GNSS in quei momenti, l'apparec­
chio di controllo deve utilizzare la posizione di­
sponibile più recente e la relativa data e ora.
110) Insieme a ciascun luogo o posizione, l'apparecchio
di controllo deve registrare e memorizzare nella
sua memoria di dati:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 45
— il numero della carta del conducente e/o del
secondo conducente e lo Stato membro che
l’ha rilasciata,
▼B
— la generazione della carta,
— la data e l'ora d'immissione dei dati,
▼M1
— il tipo di immissione (inizio, fine o 3 ore di
periodo di guida cumulativo),
▼B
— l'accuratezza del GNSS, la data e l'ora perti­
nenti, se applicabili,
— il valore dell'odometro del veicolo,
▼M3
— un indicatore che segnali se la posizione è
stata autenticata.
110 bis) Per i luoghi in cui inizia o termina il periodo di
lavoro giornaliero immessi durante la procedura di
immissione manuale all’atto dell’inserimento della
carta conformemente al requisito 61, devono es­
sere memorizzati il valore corrente dell’odometro
e la posizione corrente del veicolo.
▼M1
111) La memoria di dati deve essere in grado di con­
servare per almeno 365 giorni i luoghi e le posi­
zioni in cui iniziano e terminano i periodi di la­
voro giornalieri e/o in cui il periodo di guida cu­
mulativo raggiunge le 3 ore.
▼B
112) Qualora si esaurisca la capacità di memorizza­
zione, i dati nuovi devono sostituire quelli meno
recenti.
3.12.6 Dati relativi all'odometro
113) L'apparecchio di controllo deve registrare nella sua
memoria di dati il valore dell'odometro del veicolo
e la data di registrazione alla mezzanotte di ogni
giorno di calendario.
114) La memoria di dati deve essere in grado di me­
morizzare i valori dell'odometro registrati a mez­
zanotte per almeno 365 giorni di calendario.
115) Qualora si esaurisca la capacità di memorizza­
zione, i dati nuovi devono sostituire quelli meno
recenti.
3.12.7 Dati dettagliati relativi alla velocità
▼M1
116) L’apparecchio di controllo deve registrare e me­
morizzare nella sua memoria di dati la velocità
istantanea del veicolo e la data e l’ora di registra­
zione ogni secondo per almeno le ultime 24 ore di
marcia del veicolo.
▼B
3.12.8 Dati relativi alle anomalie
Agli effetti del presente punto, l'ora deve essere registrata con una
risoluzione di 1 secondo.
117) L'apparecchio di controllo deve registrare e memo­
rizzare nella sua memoria di dati i dati sottoelen­
cati per ogni anomalia rilevata, in base alle se­
guenti regole di memorizzazione:
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 46
Anomalia Regole di memorizzazione Dati da registrare per ogni anomalia
Inserimento di una carta
non valida
— le 10 anomalie più recenti. — data e ora dell'anomalia,
— tipo, numero, Stato membro di rilascio e
generazione della carta o delle carte che
hanno dato origine all'anomalia.
— numero di anomalie simili nel giorno in
questione.
Conflitto di carte — le 10 anomalie più recenti. — data e ora di inizio dell'anomalia,
— data e ora di fine dell'anomalia,
— tipo, numero, Stato membro di rilascio e
generazione delle due carte che hanno
dato origine al conflitto.
Guida in assenza di una
carta adeguata
— l'anomalia di maggiore durata per cia­
scuno degli ultimi 10 giorni in cui si è
verificata,
— le 5 anomalie di maggiore durata nel
corso degli ultimi 365 giorni.
— data e ora di inizio dell'anomalia,
— data e ora di fine dell'anomalia,
— tipo, numero, Stato membro di rilascio e
generazione delle carte inserite all'inizio
e/o alla fine dell'anomalia,
— numero di anomalie simili nel giorno in
questione.
Inserimento della carta
durante la guida
— l'ultima anomalia per ciascuno degli ul­
timi 10 giorni in cui si è verificata,
— data e ora dell'anomalia,
— tipo, numero, Stato membro di rilascio e
generazione della carta o delle carte,
— numero di anomalie simili nel giorno in
questione.
▼M3
Chiusura errata ultima
sessione carta
— le 10 anomalie più recenti. — data e ora dell’inserimento della carta,
— tipo, numero, Stato membro di rilascio e
generazione della carta o delle carte,
— dati relativi all’ultima sessione letti sulla
carta:
— data e ora dell’inserimento della carta.
▼B
Superamento della velo­
cità (1)
— l'anomalia più grave per ciascuno degli
ultimi 10 giorni in cui si è verificata
(cioè quella con la più alta velocità me­
dia),
— le 5 anomalie più gravi nel corso degli
ultimi 365 giorni,
— la prima anomalia verificatasi dopo l'ul­
tima taratura.
— data e ora di inizio dell'anomalia,
— data e ora di fine dell'anomalia,
— velocità massima misurata durante l'ano­
malia,
— media aritmetica della velocità misurata
durante l'anomalia,
— tipo, numero, Stato membro di rilascio e
generazione della carta del conducente
(se applicabili),
— numero di anomalie simili nel giorno in
questione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 47
Anomalia Regole di memorizzazione Dati da registrare per ogni anomalia
Interruzione dell'alimenta­
zione di energia (2)
— l'anomalia di maggiore durata per cia­
scuno degli ultimi 10 giorni in cui si è
verificata,
— le 5 anomalie di maggiore durata nel
corso degli ultimi 365 giorni.
— data e ora di inizio dell'anomalia,
— data e ora di fine dell'anomalia,
— tipo, numero, Stato membro di rilascio e
generazione delle carte inserite all'inizio
e/o alla fine dell'anomalia,
— numero di anomalie simili nel giorno in
questione.
Errore di comunicazione
con il dispositivo di co­
municazione remota
— l'anomalia di maggiore durata per cia­
scuno degli ultimi 10 giorni in cui si è
verificata,
— le 5 anomalie di maggiore durata nel
corso degli ultimi 365 giorni.
— data e ora di inizio dell'anomalia,
— data e ora di fine dell'anomalia,
— tipo, numero, Stato membro di rilascio e
generazione delle carte inserite all'inizio
e/o alla fine dell'anomalia,
— numero di anomalie simili nel giorno in
questione.
Assenza di informazioni
sulla posizione prove­
nienti dal ricevitore GNSS
— l'anomalia di maggiore durata per cia­
scuno degli ultimi 10 giorni in cui si è
verificata,
— le 5 anomalie di maggiore durata nel
corso degli ultimi 365 giorni.
— data e ora di inizio dell'anomalia,
— data e ora di fine dell'anomalia,
— tipo, numero, Stato membro di rilascio e
generazione delle carte inserite all'inizio
e/o alla fine dell'anomalia,
— numero di anomalie simili nel giorno in
questione.
▼M1
Errore di comunicazione
con il dispositivo GNSS
esterno
— l’anomalia di maggiore durata per cia­
scuno degli ultimi 10 giorni in cui si è
verificata,
— le 5 anomalie di maggiore durata nel
corso degli ultimi 365 giorni.
— data e ora di inizio dell’anomalia,
— data e ora di fine dell’anomalia,
— tipo, numero, Stato membro di rilascio e
generazione delle carte inserite all’inizio
e/o alla fine dell’anomalia,
— numero di anomalie simili nel giorno in
questione.
▼B
Errore dei dati di movi­
mento
— l'anomalia di maggiore durata per cia­
scuno degli ultimi 10 giorni in cui si è
verificata,
— le 5 anomalie di maggiore durata nel
corso degli ultimi 365 giorni.
— data e ora di inizio dell'anomalia,
— data e ora di fine dell'anomalia,
— tipo, numero, Stato membro di rilascio e
generazione delle carte inserite all'inizio
e/o alla fine dell'anomalia,
— numero di anomalie simili nel giorno in
questione.
Dati contrastanti sul movi­
mento del veicolo
— l'anomalia di maggiore durata per cia­
scuno degli ultimi 10 giorni in cui si è
verificata,
— le 5 anomalie di maggiore durata nel
corso degli ultimi 365 giorni.
— data e ora di inizio dell'anomalia,
— data e ora di fine dell'anomalia,
— tipo, numero, Stato membro di rilascio e
generazione delle carte inserite all'inizio
e/o alla fine dell'anomalia,
— numero di anomalie simili nel giorno in
questione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 48
Anomalia Regole di memorizzazione Dati da registrare per ogni anomalia
Tentativi di violazione
della sicurezza
— le ultime 10 anomalie per ogni tipo di
anomalia.
— data e ora di inizio dell'anomalia,
— data e ora di fine dell'anomalia (se per­
tinenti),
— tipo, numero, Stato membro di rilascio e
generazione delle carte inserite all'inizio
e/o alla fine dell'anomalia,
— tipo di anomalia.
▼M1
Dati contrastanti sull’ora — l’anomalia più grave per ciascuno degli
ultimi 10 giorni in cui si è verificata
(ovvero l’anomalia con la differenza
maggiore tra data e ora dell’apparecchio
di controllo e data e ora del GNSS).
— le 5 anomalie più gravi nel corso degli
ultimi 365 giorni.
— data e ora dell’apparecchio di controllo,
— data e ora del GNSS,
— tipo, numero, Stato membro di rilascio e
generazione delle carte inserite all’inizio
e/o alla fine dell’anomalia,
— numero di anomalie simili nel giorno in
questione.
▼M3
Anomalia GNSS — le anomalie di maggiore durata per cia­
scuno degli ultimi 10 giorni in cui si è
verificata,
— le 5 anomalie di maggiore durata nel
corso degli ultimi 365 giorni.
— data e ora di inizio dell’anomalia,
— data e ora di fine dell’anomalia,
— tipo, numero, Stato membro di rilascio e
generazione delle carte inserite all’inizio
e/o alla fine dell’anomalia,
— numero di anomalie simili nel giorno in
questione.
▼B
(1) L'apparecchio di controllo deve registrare e
memorizzare nella sua memoria di dati anche:
— la data e l'ora dell'ultimo CONTROLLO
DEL SUPERAMENTO DELLA VELO­
CITÀ,
— la data e l'ora del primo superamento della
velocità successivo a tale CONTROLLO
DEL SUPERAMENTO DELLA VELO­
CITÀ,
— il numero di anomalie per superamento
della velocità verificatesi dall'ultimo CON­
TROLLO DEL SUPERAMENTO DELLA
VELOCITÀ.
(2) Questi dati si possono registrare solo al ripri­
stino dell'alimentazione di energia, l'ora può
essere nota con un'accuratezza al minuto.
3.12.9 Dati relativi ai guasti
Agli effetti del presente punto, l'ora deve essere registrata con una
risoluzione di 1 secondo.
118) L'apparecchio di controllo deve cercare di regi­
strare e memorizzare nella sua memoria di dati i
dati sottoelencati per ciascun guasto rilevato, in
base alle seguenti regole di memorizzazione:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 49
Guasto Regole di memorizzazione Dati da registrare per ciascun guasto
Guasto della carta — gli ultimi 10 guasti della carta del con­
ducente.
— data e ora di inizio del guasto,
— data e ora di fine del guasto,
— tipo, numero, Stato membro di rilascio e
generazione della carta o delle carte.
Guasti dell'apparecchio di
controllo
— gli ultimi 10 guasti per ogni tipo di
guasto,
— il primo guasto dopo l'ultima taratura.
— data e ora di inizio del guasto,
— data e ora di fine del guasto,
— tipo di guasto,
— tipo, numero, Stato membro di rilascio e
generazione delle carte inserite all'inizio
e/o alla fine del guasto.
3.12.10 Dati relativi alla taratura
119) L'apparecchio di controllo deve registrare e memo­
rizzare nella sua memoria di dati le informazioni
relative a:
— i parametri di taratura noti al momento dell'at­
tivazione,
— la prima taratura successiva all'attivazione,
— la prima taratura sul veicolo in cui è montato
(identificato dal VIN),
— le ultime 20 tarature (se si effettuano diverse
tarature nello stesso giorno di calendario, si
devono memorizzare soltanto la prima e l'ul­
tima del giorno).
120) Per ciascuna di tali tarature si devono registrare i
dati seguenti:
— scopo della taratura (attivazione, primo mon­
taggio, montaggio, controllo periodico),
— denominazione e indirizzo dell'officina,
— numero di carta dell'officina, Stato membro di
rilascio della carta e data di scadenza della
carta,
— identificazione del veicolo,
— parametri aggiornati o confermati: w, k, l, di­
mensioni degli pneumatici, regolazione del li­
mitatore di velocità, odometro (vecchio e
nuovo valore), data e ora (vecchio e nuovo
valore),
— i tipi e gli identificativi di tutti i sigilli apposti,
▼M3
— i numeri di serie del sensore di movimento,
dell’eventuale dispositivo GNSS esterno e
dell’eventuale dispositivo esterno di comunica­
zione remota,
— il tipo di carico predefinito associato al veicolo
(carico delle merci o dei passeggeri),
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 50
— il paese in cui è stata effettuata la taratura e la
data e l’ora in cui è stata fornita dal ricevitore
GNSS la posizione utilizzata per determinare
tale paese.
▼B
121) Inoltre, l'apparecchio di controllo deve registrare e
memorizzare nella sua memoria di dati la sua
eventuale capacità di utilizzare le carte tachigrafi­
che di prima generazione (ancora attivate o meno).
122) Il sensore di movimento deve registrare e memo­
rizzare nella sua memoria i seguenti dati di mon­
taggio del sensore stesso:
— primo abbinamento con una VU (data, ora,
numero di omologazione della VU, numero
di serie della VU),
— ultimo abbinamento con una VU (data, ora,
numero di omologazione della VU, numero
di serie della VU).
123) Il dispositivo GNSS esterno deve registrare e me­
morizzare nella sua memoria i seguenti dati di
montaggio del dispositivo stesso:
— primo accoppiamento con una VU (data, ora,
numero di omologazione della VU, numero di
serie della VU),
— ultimo accoppiamento con una VU (data, ora,
numero di omologazione della VU, numero di
serie della VU).
3.12.11 Dati relativi alla regolazione dell'ora
124) L'apparecchio di controllo deve registrare e memo­
rizzare nella sua memoria di dati i dati relativi alle
regolazioni dell'ora effettuate in modo taratura al
di fuori di un ciclo ordinario di taratura (def. f):
— l'ultima regolazione dell'ora,
— le 5 regolazioni dell'ora di maggiore portata.
125) Per ciascuna di tali regolazioni dell'ora devono
essere registrati i dati seguenti:
— data e ora, vecchio valore,
— data e ora, nuovo valore,
— denominazione e indirizzo dell'officina,
— numero di carta dell'officina, Stato membro di
rilascio, generazione e data di scadenza della
carta.
3.12.12 Dati relativi alle attività di controllo
126) L'apparecchio di controllo deve registrare e memo­
rizzare nella sua memoria di dati i dati seguenti
relativi alle ultime 20 attività di controllo:
— data e ora del controllo,
— numero della carta di controllo, Stato membro
di rilascio e generazione della carta,
— tipo di controllo (visualizzazione e/o stampa
e/o trasferimento dati VU e/o trasferimento
dati carta e/o verifica della taratura su strada).
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 51
127) Nel caso del trasferimento, si devono registrare
anche le date del giorno meno recente e del giorno
più recente cui si riferiscono i dati trasferiti.
3.12.13 Dati relativi ai blocchi di un'impresa
128) L'apparecchio di controllo deve registrare e memo­
rizzare nella sua memoria di dati i dati seguenti
relativi agli ultimi 255 blocchi di un'impresa:
— data e ora di attivazione del blocco,
— data e ora di disattivazione del blocco,
— numero della carta dell'azienda, Stato membro
di rilascio e generazione della carta,
— denominazione e indirizzo dell'impresa.
I dati precedentemente bloccati mediante un
blocco rimosso dalla memoria a seguito del rag­
giungimento dei limiti di cui sopra devono essere
considerati non bloccati.
3.12.14 Dati relativi al trasferimento
129) L'apparecchio di controllo deve registrare e memo­
rizzare nella sua memoria di dati i dati seguenti,
relativi all'ultimo trasferimento della memoria di
dati su un dispositivo esterno in modo azienda o
taratura:
— data e ora del trasferimento,
— numero della carta dell'azienda o dell'officina,
Stato membro di rilascio e generazione della
carta,
— denominazione dell'impresa o dell'officina.
3.12.15 Dati relativi a condizioni particolari
130) L'apparecchio di controllo deve registrare e memo­
rizzare nella sua memoria di dati i dati seguenti,
relativi a condizioni particolari:
— data e ora di immissione,
— tipo di condizione particolare.
131) La memoria di dati deve essere in grado di con­
servare i dati relativi alle condizioni particolari per
almeno 365 giorni (nell'ipotesi che in media si
apra e si chiuda 1 condizione al giorno). Qualora
si esaurisca la capacità di memorizzazione, i dati
nuovi devono sostituire quelli meno recenti.
3.12.16 Dati della carta tachigrafica
132) L'apparecchio di controllo deve essere in grado di
memorizzare i dati seguenti, relativi alle diverse
carte tachigrafiche che sono state utilizzate nella
VU:
— il numero della carta tachigrafica e il suo nu­
mero di serie,
— il fabbricante della carta tachigrafica,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 52
— il tipo di carta tachigrafica,
— la versione della carta tachigrafica.
133) L'apparecchio di controllo deve essere in grado di
memorizzare almeno 88 di tali registrazioni.
▼M3
3.12.17 Attraversamenti di frontiera
133 bis) L’apparecchio di controllo deve registrare e memo­
rizzare nella sua memoria di dati le seguenti infor­
mazioni relative agli attraversamenti di frontiera:
— il paese che il veicolo sta lasciando,
— il paese in cui il veicolo sta entrando,
— la posizione in cui il veicolo ha attraversato la
frontiera.
133 ter) Insieme ai paesi e alla posizione, l’apparecchio di
controllo deve registrare e memorizzare nella sua
memoria di dati:
— il numero della carta del conducente e/o del se­
condo conducente e lo Stato membro che l’ha
rilasciata,
— la generazione della carta,
— l’accuratezza del GNSS, la data e l’ora
pertinenti,
— un indicatore che segnali se la posizione è stata
autenticata,
— il valore dell’odometro del veicolo al momento
del rilevamento dell’attraversamento della
frontiera.
133 quater) La memoria di dati deve essere in grado di conser­
vare le informazioni sugli attraversamenti di fron­
tiera per almeno 365 giorni.
133 quinquies) Qualora si esaurisca la capacità di memorizzazione,
i dati nuovi devono sostituire quelli meno recenti.
3.12.18 Operazioni di carico/scarico
133 sexies) L’apparecchio di controllo deve registrare e memo­
rizzare nella sua memoria di dati le seguenti infor­
mazioni relative alle operazioni di carico e scarico
del veicolo:
— il tipo di operazione (carico, scarico o carico/
scarico simultanei),
— la posizione in cui ha avuto luogo l’operazione
di carico/scarico.
133 septies) Quando la posizione del veicolo non è rilevabile dal
ricevitore GNSS al momento dell’operazione di ca­
rico/scarico, l’apparecchio di controllo deve utiliz­
zare la posizione disponibile più recente e la relativa
data e ora.
133 octies) Insieme al tipo di operazione e alla posizione, l’ap­
parecchio di controllo deve registrare e memorizzare
nella sua memoria di dati:
— il numero della carta del conducente e/o del se­
condo conducente e lo Stato membro che l’ha
rilasciata,
— la generazione della carta,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 53
— la data e l’ora dell’operazione di carico/scarico,
— l’accuratezza del GNSS, la data e l’ora perti­
nenti, se applicabili,
— un indicatore che segnali se la posizione è stata
autenticata,
— il valore dell’odometro del veicolo.
133 nonies) La memoria di dati deve essere in grado di memo­
rizzare le operazioni di carico/scarico per al­
meno 365 giorni di calendario.
133 decies) Qualora si esaurisca la capacità di memorizzazione,
i dati nuovi devono sostituire quelli meno recenti.
3.12.19 Mappa digitale
133 undecies) Ai fini della registrazione della posizione del vei­
colo al momento dell’attraversamento della fron­
tiera di un paese, l’apparecchio di controllo deve
conservare nella sua memoria di dati una mappa
digitale.
133 duodecies) La Commissione europea deve mettere a dispo­
sizione mappe digitali consentite, da scaricare da
un apposito sito web protetto, in vari formati, a
sostegno della funzione dell’apparecchio di con­
trollo che monitora gli attraversamenti di
frontiera.
133 terdecies) Per ciascuna di queste mappe devono essere di­
sponibili sul sito web un identificativo di ver­
sione e un valore di hash.
133 quaterdecies) La mappa deve avere le seguenti caratteristiche:
— un livello di definizione corrispondente al li­
vello NUTS 0, secondo la nomenclatura delle
unità territoriali per la statistica,
— una scala di 1:1 milione.
133 quindecies) I fabbricanti di tachigrafi devono selezionare una
mappa dal sito e scaricarla in modo sicuro.
133 sexdecies) I fabbricanti di tachigrafi devono utilizzare una
mappa scaricata dal sito web solo dopo averne
verificato l’integrità utilizzando il valore di hash
della mappa.
133 septdecies) La mappa selezionata deve essere importata
nell’apparecchio di controllo dal suo fabbricante
in un formato appropriato, ma la semantica della
mappa importata deve rimanere invariata.
133 octodecies) Il fabbricante deve inoltre conservare nell’appa­
recchio di controllo l’identificativo della versione
della mappa utilizzata.
133 novodecies) Deve essere possibile aggiornare o sostituire la
mappa digitale memorizzata con una nuova
mappa messa a disposizione dalla Commissione
europea.
133 vicies) Gli aggiornamenti della mappa digitale devono
essere effettuati utilizzando i meccanismi di ag­
giornamento software predisposti dal fabbricante,
in applicazione dei requisiti 226 quinquies e 226
sexies, in modo che l’apparecchio di controllo
possa verificare l’autenticità e l’integrità di una
nuova mappa importata prima di memorizzarla e
sostituire la precedente.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 54
133 unvicies) I fabbricanti di tachigrafi possono aggiungere in­
formazioni supplementari alla mappa di base di
cui al requisito 133 quaterdecies, a fini diversi
dalla registrazione degli attraversamenti di fron­
tiera, come le frontiere delle regioni dell’UE, a
condizione che la semantica della mappa di base
non sia modificata.
▼B
3.13 Lettura delle carte tachigrafiche
134) L'apparecchio di controllo deve essere in grado di
leggere dalle carte tachigrafiche di prima e se­
conda generazione, se del caso, i dati necessari a:
— identificare il tipo di carta, il titolare della
carta, il veicolo usato in precedenza, la data
e l'ora dell'ultima estrazione della carta e l'at­
tività selezionata in quel momento,
— verificare che l'ultima sessione della carta sia
stata chiusa in modo corretto,
▼M3
— calcolare il periodo di guida continuo del
conducente, il periodo cumulato di interru­
zione e i periodi di guida cumulativi per la
settimana corrente e per quella precedente,
▼B
— stampare i documenti relativi ai dati registrati
su una carta del conducente,
— trasferire i dati di una carta del conducente su
un dispositivo esterno.
Questo requisito si applica unicamente alle carte
tachigrafiche di prima generazione, se il loro uti­
lizzo non è stato precluso da un'officina.
135) In caso di errore di lettura, l'apparecchio di con­
trollo deve riprovare, un massimo di tre volte, ad
inviare il medesimo comando di lettura; quindi,
se l'errore persiste, deve dichiarare la carta guasta
e non valida.
▼M3
135 bis) La struttura dell’applicazione «TACHO_G2» di­
pende dalla versione. Le carte della versione 2
contengono file elementari aggiuntivi rispetto a
quelli delle carte della versione 1, in particolare:
— nelle carte del conducente e dell’officina:
— EF Places_Authentication deve contenere
lo stato di autenticazione delle posizioni
del veicolo memorizzate in EF Places.
Con ciascuno stato di autenticazione
deve essere memorizzata una marcatura
oraria (timestamp), che deve coincidere
esattamente con la data e l’ora dell’im­
missione memorizzate con la posizione
corrispondente in EF Places;
— EF GNSS_Places_Authentication deve
contenere lo stato di autenticazione delle
posizioni del veicolo memorizzate in EF
GNSS_Places. Con ciascuno stato di au­
tenticazione deve essere memorizzata una
marcatura oraria (timestamp), che deve
coincidere esattamente con la data e l’ora
dell’immissione memorizzate con la posi­
zione corrispondente in EF Places;
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 55
— EF Border_Crossings, EF Load_Un­
load_Operations ed EF Load_Type_En­
tries devono contenere dati relativi agli
attraversamenti di frontiera, alle opera­
zioni di carico/scarico e ai tipi di carico;
— nelle carte dell’officina:
— EF Calibration_Add_Data deve contenere
dati di taratura supplementari rispetto a
quelli memorizzati in EF Calibration. Il
vecchio valore di data e ora e il numero
di identificazione del veicolo devono es­
sere memorizzati con ciascuna registra­
zione supplementare dei dati di taratura,
e devono coincidere esattamente con il
vecchio valore di data e ora e il numero
di identificazione del veicolo memoriz­
zato con i corrispondenti dati di taratura
in EF Calibration;
— in tutte le carte tachigrafiche:
— EF VU_Configuration deve contenere le
impostazioni specifiche del titolare della
carta.
L’unità elettronica di bordo deve ignorare qual­
siasi stato di autenticazione trovato in EF Pla­
ces_Authentication o EF GNSS_Places_Authenti­
cation, quando in EF Places o EF GNSS_Places
non è presente alcuna posizione del veicolo con
la stessa marcatura oraria (timestamp).
L’unità elettronica di bordo deve ignorare il file
elementare EF VU_Configuration in tutte le
carte, a meno che non siano state fornite regole
specifiche in merito all’uso di tale file elemen­
tare. Tali regole devono essere stabilite mediante
una modifica dell’allegato IC, che comprenda la
modifica o la soppressione del presente
paragrafo.
▼B
3.14 Registrazione e memorizzazione nelle carte tachigrafiche
3.14.1 Registrazione e memorizzazione nelle carte tachigrafiche di prima
generazione
136) Purché l'uso delle carte tachigrafiche di prima
generazione non sia stato precluso da un'officina,
l'apparecchio di controllo deve registrare e me­
morizzare i dati esattamente come farebbe un
apparecchio di controllo di prima generazione.
137) L'apparecchio di controllo deve impostare i «dati
relativi alla sessione della carta» nella carta del
conducente o dell'officina immediatamente dopo
l'inserimento della carta.
138) L'apparecchio di controllo deve aggiornare i dati
memorizzati in una carta valida del conducente,
dell'officina, dell'azienda e/o di controllo con tutti
i dati necessari relativi al periodo durante il quale
la carta è inserita e al titolare della carta. I dati
memorizzati in tali carte sono specificati nella
sezione 4.
139) L'apparecchio di controllo deve aggiornare i dati
relativi all'attività del conducente e ai luoghi
(come specificato ai punti 4.5.3.1.9 e 4.5.3.1.11)
memorizzati su una carta valida del conducente
e/o dell'officina con i dati relativi all'attività e ai
luoghi inseriti manualmente dal titolare della
carta.
▼M3
140) Tutte le anomalie e i guasti che non sono definiti
per le apparecchiature di controllo di prima ge­
nerazione non devono essere memorizzati sulle
carte del conducente e dell’officina di prima
generazione.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 56
141) L'aggiornamento dei dati delle carte tachigrafiche deve
avvenire in modo tale che, all'occorrenza e tenuto
conto della capacità di memorizzazione effettiva della
carta, i nuovi dati sostituiscano quelli meno recenti.
142) In caso di errore di scrittura, l'apparecchio di
controllo deve riprovare, un massimo di tre volte,
ad inviare il medesimo comando di scrittura;
quindi, se l'errore persiste, deve dichiarare la
carta guasta e non valida.
▼M3
143) Prima di consentire l’estrazione di una carta del
conducente o dell’officina e dopo avere memo­
rizzato nella carta tutti i dati pertinenti, l’apparec­
chio di controllo deve azzerare i «dati relativi alla
sessione della carta».
▼B
3.14.2 Registrazione e memorizzazione nelle carte tachigrafiche di seconda
generazione
144) Le carte tachigrafiche di seconda generazione de­
vono contenere 2 diverse applicazioni della carta,
la prima esattamente uguale all'applicazione TA­
CHO delle carte tachigrafiche di prima genera­
zione, mentre la seconda deve essere l'applica­
zione «TACHO_G2», come specificato nella
sezione 4 e nell'appendice 2.
▼M3
La struttura dell’applicazione «TACHO_G2» di­
pende dalla versione. Le carte della versione 2
contengono file elementari aggiuntivi rispetto a
quelli delle carte della versione 1.
▼B
145) L'apparecchio di controllo deve impostare i «dati
relativi alla sessione della carta» nella carta del
conducente o dell'officina immediatamente dopo
l'inserimento della carta.
146) L'apparecchio di controllo deve aggiornare i dati
memorizzati nelle 2 applicazioni di una carta va­
lida del conducente, dell'officina, dell'azienda e/o
di controllo con tutti i dati necessari relativi al
periodo durante il quale la carta è inserita e al
titolare della carta. I dati memorizzati in tali carte
sono specificati nella sezione 4.
147) L'apparecchio di controllo deve aggiornare i dati
relativi ai luoghi e alle posizioni dell'attività del
conducente (come specificato ai punti 4.5.3.1.9,
4.5.3.1.11, 4.5.3.2.9 e 4.5.3.2.11), memorizzati su
una carta valida del conducente e/o dell'officina,
con i dati relativi all'attività e ai luoghi inseriti
manualmente dal titolare della carta.
▼M3
147 bis) Al momento dell’inserimento di una carta del
conducente o dell’officina, l’apparecchio di con­
trollo deve memorizzare sulla carta il tipo di ca­
rico predefinito del veicolo.
147 ter) Al momento dell’inserimento di una carta del con­
ducente o dell’officina e dopo la procedura di im­
missione manuale, l’apparecchio di controllo deve
controllare l’ultimo luogo in cui inizia o termina il
periodo di lavoro giornaliero memorizzato sulla
carta. Tale luogo può essere temporaneo, come
specificato al requisito 59. Se questo luogo si trova
in un paese diverso da quello in cui il veicolo si
trova in quel momento, l’apparecchio di controllo
memorizza sulla carta una registrazione dell’attra­
versamento di frontiera con:
— il paese lasciato dal conducente: non
disponibile,
— il paese in cui il conducente sta entrando: il
paese in cui si trova il veicolo in quel
momento,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 57
— la data e l’ora in cui il conducente ha attra­
versato la frontiera: l’orario di inserimento
della carta,
— la posizione del conducente al momento
dell’attraversamento della frontiera: non
disponibile,
— il valore dell’odometro del veicolo: non
disponibile.
▼B
148) L'aggiornamento dei dati delle carte tachigrafiche
deve avvenire in modo tale che, all'occorrenza e
tenuto conto della capacità di memorizzazione
effettiva della carta, i nuovi dati sostituiscano
quelli meno recenti.
149) In caso di errore di scrittura, l'apparecchio di
controllo deve riprovare, un massimo di tre volte,
ad inviare il medesimo comando di scrittura;
quindi, se l'errore persiste, deve dichiarare la
carta guasta e non valida.
150) Prima di consentire l'estrazione di una carta del
conducente e dopo avere memorizzato nelle 2
applicazioni della carta tutti i dati pertinenti, l'ap­
parecchio di controllo deve azzerare i «dati rela­
tivi alla sessione della carta».
▼M3
150 bis) L’unità elettronica di bordo deve ignorare il file
elementare EF VU_Configuration in tutte le
carte, a meno che non siano state fornite regole
specifiche in merito all’uso di tale file elemen­
tare. Tali regole devono essere stabilite mediante
una modifica dell’allegato IC, che comprenda la
modifica o la soppressione del presente
paragrafo.
▼B
3.15 Visualizzazione
151) Il dispositivo di visualizzazione deve compren­
dere almeno 20 caratteri.
152) La dimensione minima prescritta per i caratteri è
di 5 mm in altezza e 3,5 mm in larghezza.
153) Il dispositivo di visualizzazione deve gestire i
caratteri specificati nell'appendice 1, sezione 4,
«Insiemi di caratteri». Il dispositivo di visualiz­
zazione può usare caratteri semplificati (per es. le
lettere accentate possono apparire senza l'accento
o le lettere minuscole possono apparire come
maiuscole).
154) Il dispositivo di visualizzazione deve essere mu­
nito di un'illuminazione adeguata non
abbagliante.
155) Le indicazioni devono essere visibili dall'esterno
dell'apparecchio di controllo.
156) L'apparecchio di controllo deve essere in grado di
visualizzare:
— i dati predefiniti,
— i dati relativi agli avvisi,
— i dati relativi all'accesso guidato da menù,
— altri dati richiesti dall'utilizzatore.
L'apparecchio di controllo può visualizzare altre
informazioni, a condizione che siano chiaramente
distinte da quelle di cui sopra.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 58
157) Il dispositivo di visualizzazione dell'apparecchio
di controllo deve usare i pittogrammi o le com­
binazioni di pittogrammi elencati nell'appendice
3. Il dispositivo di visualizzazione può prevedere
altri pittogrammi o combinazioni di pittogrammi,
purché siano chiaramente distinti da quelli
summenzionati.
158) Il dispositivo di visualizzazione deve essere sem­
pre acceso durante la marcia del veicolo.
159) L'apparecchio di controllo può prevedere un co­
mando manuale o automatico per spegnere il di­
spositivo di visualizzazione quando il veicolo
non è in marcia.
Il formato di visualizzazione è specificato nell'ap­
pendice 5.
3.15.1 Visualizzazione predefinita
160) In assenza di altre informazioni da visualizzare,
l'apparecchio di controllo deve visualizzare, nel­
l'impostazione predefinita, le seguenti
informazioni:
— l'ora locale (risultante dall'ora UTC, con re­
golazione effettuata dal conducente),
— la modalità di funzionamento,
— l'attività in corso del conducente e del se­
condo conducente,
— informazioni relative al conducente:
— se l'attività in corso è GUIDA, il periodo di
guida continuo in corso e il periodo cumulato
di interruzione in corso,
— se l'attività in corso non è GUIDA, la durata
di tale attività (a partire dal momento in cui è
stata selezionata) e il periodo cumulato di
interruzione in corso.
161) La visualizzazione dei dati relativi a ciascun con­
ducente deve essere chiara, semplice ed inequi­
vocabile. Qualora non sia possibile visualizzare
contemporaneamente le informazioni relative al
conducente e al secondo conducente, l'apparec­
chio di controllo deve visualizzare per defini­
zione le informazioni relative al conducente e
consentire all'utente di visualizzare le informa­
zioni relative al secondo conducente.
162) Qualora la larghezza del dispositivo non consenta
di visualizzare per definizione la modalità di fun­
zionamento, ad ogni variazione l'apparecchio di
controllo deve visualizzare brevemente la nuova
modalità di funzionamento.
163) L'apparecchio di controllo deve visualizzare bre­
vemente il nome del titolare all'atto dell'inseri­
mento della carta.
164) Qualora si attivi una condizione «ESCLUSO
DAL CAMPO DI APPLICAZIONE» o «TRA­
GHETTO/TRENO», la visualizzazione predefi­
nita deve indicare, mediante l'apposito pitto­
gramma, che tale condizione è attiva (è ammesso
che l'attività in corso del conducente non sia in­
dicata nel contempo).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 59
3.15.2 Visualizzazione degli avvisi
165) L'apparecchio di controllo deve visualizzare gli
avvisi utilizzando principalmente i pittogrammi
di cui all'appendice 3, integrati, se necessario,
da un codice numerico supplementare. Si può
anche aggiungere una descrizione dell'avviso
nella lingua abituale del conducente.
3.15.3 Accesso guidato da menù
166) L'apparecchio di controllo deve fornire i comandi
necessari attraverso un'apposita struttura a menù.
3.15.4 Visualizzazione di altre informazioni
167) Deve essere possibile visualizzare selettivamente,
su richiesta:
— la data e l'ora UTC e la regolazione dell'ora
locale;
▼M3
— il contenuto di ciascuno dei documenti stam­
pati elencati al requisito 169, nello stesso for­
mato dei documenti stessi;
▼B
— il periodo di guida continuo e il periodo cu­
mulato di interruzione del conducente;
— il periodo di guida continuo e il periodo cu­
mulato di interruzione del secondo
conducente;
▼M3
— il periodo di guida cumulativo del conducente
relativo alla settimana in corso e a quella
precedente;
— il periodo di guida cumulativo del secondo
conducente relativo alla settimana in corso e
a quella precedente;
▼B
informazioni facoltative:
— la durata attuale dell'attività del secondo con­
ducente (a partire dal momento in cui è stata
selezionata);
▼M3
— il periodo di guida cumulativo del conducente
relativo alla settimana in corso;
— il periodo di guida cumulativo del secondo
conducente relativo al periodo di lavoro gior­
naliero in corso;
— il periodo di guida cumulativo del conducente
relativo al periodo di lavoro giornaliero in
corso.
▼B
168) La visualizzazione del contenuto dei documenti
stampati deve essere sequenziale, riga per riga.
Qualora la larghezza del dispositivo di visualiz­
zazione sia inferiore a 24 caratteri, l'utilizzatore
deve poter ottenere le informazioni complete me­
diante un sistema adeguato (più righe, scorri­
mento del testo, ecc.).
Ai fini della visualizzazione si possono omettere
le righe dei documenti stampati riservate alle in­
formazioni da riportare a mano.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 60
3.16 Stampa
169) L'apparecchio di controllo deve essere in grado di
stampare le seguenti informazioni contenute nella
sua memoria di dati e/o nelle carte tachigrafiche,
in modo da ottenere i sette documenti stampati
seguenti:
— stampa giornaliera delle attività del condu­
cente contenute nella carta,
— stampa giornaliera delle attività del condu­
cente contenute nell'unità elettronica di bordo,
— stampa di anomalie e guasti contenuti nella
carta,
— stampa di anomalie e guasti contenuti nel­
l'unità elettronica di bordo,
— stampa dei dati tecnici,
— stampa dei superamenti della velocità,
— cronologia dei dati della carta tachigrafica per
una determinata VU (cfr. punto 3.12.16).
Il formato e il contenuto precisi di tali documenti
stampati sono specificati nell'appendice 4.
In fondo ai documenti stampati si possono ripor­
tare anche altre informazioni.
L'apparecchio di controllo può inoltre fornire altri
documenti stampati, purché siano chiaramente di­
stinguibili dai sette documenti summenzionati.
170) I documenti «stampa giornaliera delle attività del
conducente contenute nella carta» e «stampa di
anomalie e guasti contenuti nella carta» devono
essere disponibili solo quando nell'apparecchio di
controllo è inserita una carta del conducente o
una carta dell'officina. L'apparecchio di controllo
deve aggiornare i dati contenuti nella carta prima
di iniziare la stampa.
171) Per produrre il documento «stampa giornaliera
delle attività del conducente contenute nella
carta» o il documento «stampa di anomalie e
guasti contenuti nella carta», l'apparecchio di
controllo deve:
— selezionare automaticamente la carta del con­
ducente o la carta dell'officina, se solo una
delle due è inserita, oppure
— prevedere un comando per selezionare la
carta da cui attingere i dati o selezionare la
carta inserita nella sede (slot) «conducente»,
se due di tali carte sono inserite nell'apparec­
chio di controllo.
172) La stampante deve essere in grado di stampare 24
caratteri per riga.
173) La dimensione minima prescritta per i caratteri è
di 2,1 mm in altezza e 1,5 mm in larghezza.
174) La stampante deve poter stampare i caratteri spe­
cificati nell'appendice 1, sezione 4, «Insiemi di
caratteri».
175) Le stampanti devono essere progettate in modo
da fornire i suddetti documenti stampati con un
grado di definizione atto ad evitare qualsiasi am­
biguità nella lettura.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 61
176) I documenti stampati devono conservare le loro
dimensioni e le loro registrazioni in condizioni
normali di umidità (10-90 %) e di temperatura.
177) La carta omologata usata per la stampa deve re­
care il marchio di omologazione pertinente e l'in­
dicazione del tipo o dei tipi di apparecchio di
controllo con cui può essere utilizzata.
178) I documenti stampati devono rimanere chiara­
mente leggibili e identificabili in condizioni nor­
mali di conservazione, per quanto riguarda l'in­
tensità luminosa, l'umidità e la temperatura, per
almeno due anni.
179) I documenti stampati devono essere quantomeno
conformi alle specifiche di prova di cui all'appen­
dice 9.
180) Deve inoltre essere possibile aggiungere su questi
documenti note manoscritte supplementari, come
la firma del conducente.
181) L'apparecchio di controllo deve gestire anomalie
del tipo «mancanza carta» durante la stampa,
riavviando la stampa dall'inizio del documento
in seguito al caricamento della carta o conti­
nuando la stampa e fornendo un riferimento ine­
quivocabile alla parte già stampata.
3.17 Avvisi
182) L'apparecchio di controllo deve inviare un se­
gnale di avviso al conducente quando rileva
un'anomalia e/o un guasto.
183) L'avviso di un'anomalia dovuta ad interruzione
dell'alimentazione può attivarsi anche solo dopo
il ripristino dell'alimentazione stessa.
184) L'apparecchio di controllo deve inviare un se­
gnale di avviso al conducente 15 minuti prima
del superamento del periodo massimo di guida
continuo consentito e nel momento in cui tale
limite viene superato.
185) I segnali di avviso devono essere visivi. Si pos­
sono anche prevedere avvisi acustici in aggiunta
a quelli visivi.
186) Gli avvisi visivi devono essere chiaramente rico­
noscibili dall'utente, devono rientrare nel campo
visivo del conducente ed essere chiaramente leg­
gibili sia di giorno che di notte.
187) Gli avvisi visivi possono essere incorporati nel­
l'apparecchio di controllo e/o collocati in posi­
zione remota rispetto all'apparecchio di controllo.
188) In quest'ultimo caso devono recare il simbolo
«T».
189) Gli avvisi devono avere una durata di almeno
30 secondi, salvo che l'utente con la pressione
di uno o più tasti specifici dell'apparecchio di
controllo non confermi di averne preso atto. Que­
sta prima conferma non deve annullare la visua­
lizzazione della causa dell'avviso menzionata nel
paragrafo successivo.
190) La causa dell'avviso deve essere visualizzata sul­
l'apparecchio di controllo e rimanere visibile fino
alla conferma da parte dell'utente mediante l'uso
di un apposito tasto o comando dell'apparecchio
di controllo.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 62
191) Si possono prevedere altri avvisi, purché non
confondano i conducenti in relazione a quelli so­
pra definiti.
3.18 Trasferimento di dati a un dispositivo esterno
192) L'apparecchio di controllo deve essere in grado di
trasferire su richiesta i dati contenuti nella sua
memoria o in una carta del conducente ad un
dispositivo di memorizzazione esterno attraverso
il connettore di taratura/trasferimento. L'apparec­
chio di controllo deve aggiornare i dati contenuti
nella carta prima di iniziare il trasferimento.
▼M3
193) In qualsiasi modalità di funzionamento l’apparec­
chio di controllo può inoltre, e a titolo facolta­
tivo, trasferire i dati tramite qualsiasi altra inter­
faccia a un’impresa autenticata attraverso questo
canale. In tal caso, a tale trasferimento dati si
applicano i diritti di accesso ai dati del modo
azienda.
▼B
194) Il trasferimento di dati non deve modificare o
cancellare i dati memorizzati.
195) L'interfaccia elettrica del connettore di taratura/
trasferimento è specificata nell'appendice 6.
196) I protocolli di trasferimento sono specificati nel­
l'appendice 7.
▼M3
196 bis) Un’impresa di trasporto che utilizza veicoli mu­
niti di un apparecchio di controllo conforme alle
disposizioni del presente allegato e che rientrano
nell’ambito di applicazione del regolamento (CE)
n. 561/2006 deve provvedere affinché tutti i dati
siano trasferiti dall’unità elettronica di bordo e
dalle carte del conducente.
Il periodo massimo entro cui devono essere tra­
sferiti i dati pertinenti non deve superare:
— 90 giorni per i dati trasferiti dall’unità elet­
tronica di bordo;
— 28 giorni per i dati trasferiti dalla carta del
conducente.
196 ter) Le imprese di trasporto devono conservare i dati
trasferiti dall’unità elettronica di bordo e dalle
carte del conducente per almeno dodici mesi
dalla registrazione.
▼B
3.19 Comunicazione remota per controlli su strada mirati
197) Quando l'accensione è inserita, l'unità elettronica
di bordo deve memorizzare ogni 60 secondi nel
dispositivo di comunicazione remota i dati più
recenti necessari ai fini dei controlli su strada
mirati. Tali dati devono essere criptati e firmati
come specificato nelle appendici 11 e 14.
198) I dati da controllare a distanza devono essere resi
disponibili a lettori di comunicazione remota at­
traverso una comunicazione senza fili, come spe­
cificato nell'appendice 14.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 63
199) I dati necessari ai fini dei controlli su strada mi­
rati devono riguardare:
— l'ultimo tentativo di violazione della
sicurezza,
— l'interruzione più lunga dell'alimentazione di
energia,
— guasto del sensore,
— errore dei dati di movimento,
— dati contrastanti sul movimento del veicolo,
— guida in assenza di una carta valida,
— inserimento della carta durante la guida,
— dati relativi alla regolazione dell'ora,
— dati relativi alla taratura, comprese le date
delle ultime due registrazioni di tarature
memorizzate,
— numero d'immatricolazione del veicolo,
— velocità registrata dal tachigrafo,
▼M3
— posizione del veicolo,
— un’indicazione del fatto che il conducente
possa in quel momento violare o no i tempi
di guida.
3.20 Scambi di dati con dispositivi esterni aggiuntivi
200) L’apparecchio di controllo deve essere anche mu­
nito di un’interfaccia ITS conforme alle disposi­
zioni dell’appendice 13, che consenta l’utilizzo
da parte di un dispositivo esterno dei dati regi­
strati o prodotti dal tachigrafo o dalle carte
tachigrafiche.
Nel modo funzionamento deve essere necessario
il consenso del conducente per la trasmissione di
dati personali attraverso l’interfaccia ITS. Il con­
senso del conducente non si applica tuttavia ai
dati del tachigrafo o della carta tachigrafica con­
sultati in modo controllo, azienda o taratura. I
dati e i diritti di accesso funzionali per tali
modi sono specificati nei requisiti 12 e 13.
I seguenti requisiti si applicano ai dati ITS resi
disponibili mediante tale interfaccia:
— i dati personali devono essere disponibili solo
previo consenso verificabile del conducente,
che accetta che i dati personali possano la­
sciare la rete del veicolo.
Una serie di dati esistenti selezionati che pos­
sono essere disponibili mediante l’interfaccia
ITS e la classificazione dei dati come perso­
nali o non personali sono specificati nell’ap­
pendice 13. Oltre alla serie di dati di cui
all’appendice 13, possono essere trasmessi
anche dati aggiuntivi. Il fabbricante della
VU deve classificare tali dati come «perso­
nali» o «non personali», poiché il consenso
del conducente è applicabile ai dati classifi­
cati come «personali»,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 64
— in qualsiasi momento il consenso del condu­
cente può essere abilitato o disabilitato con i
comandi del menù, purché la carta del con­
ducente sia inserita,
— in qualsiasi circostanza, la presenza dell’inter­
faccia ITS non deve perturbare o pregiudicare
il corretto funzionamento e la sicurezza
dell’unità elettronica di bordo.
Possono coesistere interfacce supplementari
dell’unità elettronica di bordo, purché siano pie­
namente conformi ai requisiti dell’appendice 13
in termini di consenso del conducente. L’appa­
recchio di controllo deve essere in grado di co­
municare lo stato del consenso del conducente ad
altre piattaforme presenti nella rete del veicolo e
a dispositivi esterni.
Per quanto riguarda i dati personali introdotti
nella rete del veicolo, che sono ulteriormente trat­
tati al di fuori della rete del veicolo, non spetta al
fabbricante del tachigrafo far sì che tale tratta­
mento dei dati personali sia conforme alla legi­
slazione applicabile dell’Unione in materia di
protezione dei dati.
L’interfaccia ITS deve inoltre consentire l’immis­
sione dei dati da parte sia del conducente sia
del secondo conducente durante la procedura di
immissione manuale conformemente al requi­
sito 61.
L’interfaccia ITS può essere utilizzata anche per
inserire, in tempo reale, informazioni supplemen­
tari quali:
— selezione dell’attività del conducente, confor­
memente al requisito 46,
— luoghi, conformemente al requisito 56,
— condizioni specifiche, conformemente al re­
quisito 62,
— operazioni di carico/scarico, conformemente
al requisito 62 bis.
Tali informazioni possono essere inserite anche
attraverso altre interfacce.
201) Il tachigrafo può continuare ad essere munito
dell’interfaccia del collegamento seriale, come spe­
cificato nell’allegato IB del regolamento (CEE)
n. 3821/85, come modificato da ultimo, per garan­
tire la compatibilità con le versioni precedenti. Il
collegamento seriale è classificato come parte della
rete del veicolo, in conformità al requisito 200.
▼B
3.21 Taratura
202) La funzione di taratura deve consentire:
— l'accoppiamento automatico del sensore di
movimento alla VU,
— l'accoppiamento automatico del dispositivo
GNSS esterno alla VU, se del caso,
— l'adattamento digitale della costante dell'appa­
recchio di controllo (k) al coefficiente carat­
teristico del veicolo (w),
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 65
— la regolazione dell'ora corrente entro il pe­
riodo di validità della carta dell'officina
inserita,
— la regolazione del valore corrente dell'odome­
tro,
— l'aggiornamento dei dati di identificazione del
sensore di movimento memorizzati nella me­
moria di dati,
— l'aggiornamento, se del caso, dei dati di iden­
tificazione del dispositivo GNSS esterno me­
morizzati nella memoria di dati,
— l'aggiornamento dei tipi e degli identificativi
di tutti i sigilli apposti,
▼M3
— l’aggiornamento o la conferma di altri para­
metri noti all’apparecchio di controllo: iden­
tificazione del veicolo, w, l, dimensioni degli
pneumatici, impostazioni del limitatore di ve­
locità se applicabile, e tipo di carico
predefinito,
— la memorizzazione automatica del paese in
cui è stata effettuata la taratura e la data e
l’ora in cui è stata fornita dal ricevitore
GNSS la posizione utilizzata per determinare
tale paese.
▼B
203) Inoltre, la funzione di taratura deve consentire di
eliminare l'utilizzo delle carte tachigrafiche di
prima generazione nell'apparecchio di controllo,
purché siano soddisfatte le condizioni di cui al­
l'appendice 15.
204) L'abbinamento del sensore di movimento alla VU
deve prevedere almeno:
— l'aggiornamento dei dati di montaggio del
sensore di movimento in esso contenuti (al­
l'occorrenza),
— la copia, nella memoria di dati della VU, dei
dati di identificazione del sensore necessari.
▼M3
205) L’accoppiamento del dispositivo GNSS esterno
alla VU deve prevedere almeno:
— l’aggiornamento dei dati di montaggio del
dispositivo GNSS esterno in esso contenuti
(all’occorrenza),
— la copia, dal dispositivo GNSS esterno alla
memoria di dati della VU, dei dati di identi­
ficazione necessari del dispositivo GNSS
esterno, compreso il numero di serie del di­
spositivo GNSS esterno.
▼B
206) La funzione di taratura deve essere in grado di
immettere i dati necessari, attraverso il connettore
di taratura/trasferimento, in base al protocollo di
taratura definito nell'appendice 8. La funzione di
taratura può anche immettere i dati necessari at­
traverso altri mezzi.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 66
3.22 Verifica della taratura su strada
207) La funzione di verifica della taratura su strada
deve consentire di leggere il numero di serie
del sensore di movimento (eventualmente incor­
porato nell'adattatore) e il numero di serie del
dispositivo GNSS esterno (se del caso), collegati
all'unità elettronica di bordo, al momento della
richiesta.
208) Tale lettura deve essere possibile almeno sul di­
spositivo di visualizzazione dell'unità elettronica
di bordo con i comandi dei menù.
209) La funzione di verifica della taratura su strada
deve anche consentire di controllare la selezione
della modalità I/O della linea dei segnali I/O di
taratura specificata nell'appendice 6, tramite l'in­
terfaccia della linea K. A ciò si deve provvedere
tramite la sessione di regolazione ECU, come
specificato nell'appendice 8, Sezione 7 «Con­
trollo degli impulsi di prova — Unità funzionale
di controllo dei segnali di entrata/uscita».
▼M3
Quando la modalità I/O della linea dei segnali
I/O di taratura è attiva conformemente al presente
requisito, l’avviso «Guida in assenza di una carta
adeguata» (requisito 75) non deve essere attivato
dall’unità elettronica di bordo.
▼B
3.23 Regolazione dell'ora
210) La funzione di regolazione dell'ora deve consen­
tire di regolare automaticamente l'ora corrente.
Nell'apparecchio di controllo si devono usare
due fonti di misurazione del tempo per regolare
l'ora: 1) l'orologio interno della VU); 2) il rice­
vitore GNSS.
▼M3
211) Le impostazioni dell’ora dell’orologio interno
della VU devono essere regolate automatica­
mente a intervalli di tempo variabili. La succes­
siva regolazione automatica dell’ora deve atti­
varsi tra 72 e 168 ore dopo la precedente e
dopo che la VU ha potuto accedere all’ora del
GNSS mediante un messaggio di posizione au­
tenticata valido in conformità all’appendice 12.
La regolazione dell’ora non deve tuttavia mai
essere superiore allo sfasamento massimo cumu­
lativo giornaliero dell’ora, come calcolato dal
fabbricante della VU conformemente al requisito
41 ter. Se la differenza tra l’ora dell’orologio
interno della VU e l’ora del ricevitore GNSS è
superiore allo sfasamento massimo cumulativo
giornaliero dell’ora, la regolazione dell’ora deve
avvicinare il più possibile l’ora dell’orologio in­
terno della VU all’ora del ricevitore GNSS.
L’impostazione dell’ora può essere effettuata
solo se l’ora indicata dal ricevitore GNSS è otte­
nuta utilizzando messaggi di posizione autenti­
cata come indicato nell’appendice 12. Il riferi­
mento temporale per l’impostazione automatica
dell’ora dell’orologio interno della VU deve es­
sere costituito dall’ora fornita dal messaggio di
posizione autenticata.
212) La funzione di regolazione dell’ora deve anche
consentire la regolazione dell’ora corrente in
modo mirato, nel modo taratura.
Le officine possono regolare l’ora:
— scrivendo un valore temporale nella VU uti­
lizzando il servizio WriteDataByIdentifier
conformemente alla sezione 6.2 dell’appen­
dice 8,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 67
— oppure richiedendo un allineamento dell’oro­
logio della VU all’ora fornita dal ricevitore
GNSS. Ciò è possibile solo se l’ora indicata
dal ricevitore GNSS è ottenuta utilizzando
messaggi di posizione autenticata. In
quest’ultimo caso deve essere utilizzato il ser­
vizio RoutineControl conformemente alla
sezione 8 dell’appendice 8.
▼B
3.24 Caratteristiche prestazionali
213) L'unità elettronica di bordo deve essere in grado
di funzionare correttamente nell'intervallo di tem­
peratura compreso tra – 20 °C e 70 °C, il dispo­
sitivo GNSS esterno nell'intervallo di temperatura
compreso tra – 20 °C e 70 °C e il sensore di
movimento nell'intervallo di temperatura com­
preso tra – 40 °C e 135 °C. Il contenuto della
memoria di dati deve conservarsi fino alla tem­
peratura minima di – 40 °C.
214) Il tachigrafo deve essere in grado di funzionare
correttamente nell'intervallo di umidità compreso
tra 10 % e 90 %.
215) I sigilli utilizzati nel tachigrafo intelligente de­
vono resistere alle stesse condizioni applicabili
ai componenti del tachigrafo cui sono apposti.
216) L'apparecchio di controllo deve essere protetto
contro la sovratensione, l'inversione di polarità
dell'alimentazione e i corto circuiti.
217) I sensori di movimento:
— devono reagire a un campo magnetico che
disturbi il rilevamento dei dati di movimento
del veicolo. In queste circostanze, l'unità elet­
tronica di bordo del veicolo deve registrare e
memorizzare un guasto del sensore (requisito
88); oppure
— devono disporre di un elemento di rilevazione
protetto dai campi magnetici o immune agli
stessi.
218) L'apparecchio di controllo e il dispositivo GNSS
esterno devono essere conformi al regolamento
internazionale UNECE n. 10 e devono essere
protetti contro le scariche elettrostatiche ed i
transitori.
3.25 Materiali
219) Tutti gli elementi costitutivi dell'apparecchio di
controllo devono essere realizzati con materiali
dotati di stabilità e di resistenza meccanica suffi­
cienti e con caratteristiche elettriche e magnetiche
stabili.
220) Per le normali condizioni di impiego, tutti gli
elementi interni dell'apparecchio devono essere
protetti contro l'umidità e la polvere.
221) L'unità elettronica di bordo e il dispositivo GNSS
esterno devono soddisfare il grado di protezione
IP 40 e il sensore di movimento deve soddisfare
il grado di protezione IP 64, secondo la norma
IEC 60529:1989 comprese A1:1999 e A2:2013.
222) L'apparecchio di controllo deve essere conforme
alle specifiche tecniche applicabili in materia di
ergonomia.
223) L'apparecchio di controllo deve essere protetto
contro i danni accidentali.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 68
3.26 Iscrizioni
224) Se l'apparecchio di controllo visualizza il valore
dell'odometro e la velocità, sul dispositivo di vi­
sualizzazione devono figurare le seguenti
iscrizioni:
— in prossimità della cifra che indica la di­
stanza, l'unità di misura della distanza
espressa dal simbolo «km»,
— in prossimità della cifra che indica la velocità,
l'indicazione «km/h».
L'apparecchio di controllo deve inoltre consentire
la visualizzazione della velocità in miglia all'ora,
nel qual caso l'unità di misura della velocità sarà
espressa dall'indicazione «mph». L'apparecchio di
controllo deve inoltre consentire la visualizza­
zione della distanza in miglia, nel qual caso
l'unità di misura della distanza sarà espressa dal­
l'indicazione «mi».
▼M1
225) Una targhetta segnaletica deve essere affissa su
ogni componente distinto dell’apparecchio di
controllo e deve riportare le indicazioni seguenti:
— nome ed indirizzo del fabbricante,
— codice componente del fabbricante e anno di
fabbricazione,
— numero di serie,
— marchio di omologazione.
226) Qualora lo spazio fisico non sia sufficiente per
riportare tutte le indicazioni summenzionate, sulla
targhetta segnaletica devono figurare almeno: il
nome o il logo del fabbricante e il codice
componente.
▼M3
3.27 Monitoraggio degli attraversamenti di frontiera
226 bis) Questa funzione deve rilevare quando il veicolo
ha attraversato la frontiera di un paese, quale
paese ha lasciato e in quale paese è entrato.
226 ter) Il rilevamento degli attraversamenti di frontiera
deve basarsi sulla posizione misurata dall’appa­
recchio di controllo e sulla mappa digitale me­
morizzata conformemente al punto 3.12.19.
226 quater) Gli attraversamenti di frontiera correlati alla pre­
senza del veicolo in un paese per un periodo
inferiore a 120 secondi non devono essere
registrati.
3.28 Aggiornamento software
226 quinquies) L’unità elettronica di bordo deve incorporare una
funzione per l’implementazione degli aggiorna­
menti software ogniqualvolta tali aggiornamenti
non richiedono la disponibilità di risorse har­
dware supplementari rispetto alle risorse di cui
al requisito 226 septies e le autorità di omologa­
zione autorizzano gli aggiornamenti software ba­
sati sull’unità elettronica di bordo omologata esi­
stente, in conformità all’articolo 12, paragrafo 5,
del regolamento (UE) n. 165/2014.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 69
226 sexies) La funzione di aggiornamento software deve es­
sere progettata per supportare le seguenti caratte­
ristiche funzionali, ogniqualvolta esse siano pre­
scritte dalla legge:
— modifica delle funzioni di cui al punto 2.2, ad
eccezione della funzione di aggiornamento
software stessa,
— aggiunta di nuove funzioni direttamente cor­
relate all’applicazione della legislazione
dell’Unione in materia di trasporti su strada,
— modifica delle modalità di funzionamento di
cui al punto 2.3,
— modifica della struttura dei file, come l’ag­
giunta di nuovi dati o l’aumento delle dimen­
sioni dei file,
— installazione di patch software per risolvere
problemi collegati a difetti software e di si­
curezza o ad attacchi segnalati alle funzioni
dell’apparecchio di controllo.
226 septies) L’unità elettronica di bordo deve provvedere af­
finché siano libere almeno il 35 % delle risorse
hardware per software e dati necessarie per l’at­
tuazione del requisito 226 sexies e almeno il
65 % delle risorse hardware per l’aggiornamento
della mappa digitale in base alle risorse hardware
necessarie per la versione 2021 della mappa
NUTS 0.
▼B
4 REQUISITI DI COSTRUZIONE E FUNZIONAMENTO DELLE
CARTE TACHIGRAFICHE
4.1 Dati visibili
Il lato anteriore della carta deve recare:
227) le diciture «Carta del conducente» o «Carta di
controllo» o «Carta dell'officina» o «Carta del­
l'azienda» stampati in carattere maiuscolo nella
lingua o nelle lingue ufficiali dello Stato membro
che rilascia la carta, a seconda del tipo di carta;
228) il nome dello Stato membro che rilascia la carta
(facoltativo);
229) il segno distintivo dello Stato membro che rila­
scia la carta, stampato in negativo in un rettan­
golo azzurro e circondato da dodici stelle gialle. I
segni distintivi sono i seguenti:
B
BG
CZ
CY
Belgio
Bulgaria
Repubblica ceca
Cipro
LV
L
LT
M
Lettonia
Lussemburgo
Lituania
Malta
DK Danimarca NL Paesi Bassi
D
EST
Germania
Estonia
A
PL
Austria
Polonia
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 70
GR Grecia P
RO
SK
SLO
Portogallo
Romania
Slovacchia
Slovenia
E Spagna FIN Finlandia
F
HR
H
Francia
Croazia
Ungheria
S Svezia
IRL Irlanda UK Regno Unito
I Italia
230) le informazioni specifiche della carta, nell'ordine
seguente:
Carta del conducente Carta di controllo
Carta dell'azienda o carta
dell'officina
1. cognome del conducente denominazione del­
l'organismo di con­
trollo
denominazione dell'im­
presa o dell'officina
2. nome/i del conducente cognome del control­
lore
(se pertinente)
cognome del titolare della
carta
(se pertinente)
3. data di nascita del con­
ducente
nome/i del controllore
(se pertinente)
nome/i del titolare della
carta
(se pertinente)
4.a data di inizio validità della carta
4.b data di fine validità della carta
4.c denominazione dell'autorità che rilascia la carta (può essere stampata sul
retro);
4.d un numero diverso da quello di cui alla voce 5, a fini amministrativi (facol­
tativo);
5.a numero della patente di
guida
(alla data di rilascio della
carta del conducente)
— —
5.b numero della carta
6. fotografia del condu­
cente
fotografia del control­
lore (facoltativa)
fotografia dell'installatore
(facoltativa)
7. firma del titolare (facoltativa)
8. luogo di residenza abi­
tuale o indirizzo postale
del titolare (facoltativo)
indirizzo postale del­
l'organismo di con­
trollo
indirizzo postale del­
l'azienda o dell'officina
231) le date devono essere indicate nel formato «gg/
mm/aaaa» o «gg.mm.aaaa» (giorno, mese, anno).
Il retro della carta deve recare:
232) la spiegazione delle voci numerate che appaiono
sul lato anteriore della carta;
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 71
233) se del caso e con l'assenso specifico scritto del
titolare, anche altre informazioni che non si rife­
riscono alla gestione della carta, purché tale ag­
giunta non modifichi in alcun modo l'impiego del
modello come carta tachigrafica.
234) Le carte tachigrafiche devono essere stampate
con i seguenti colori di fondo predominanti:
— carta del conducente: bianco,
— carta di controllo: blu,
— carta dell'officina: rosso,
— carta dell'azienda: giallo.
235) Le carte tachigrafiche devono avere almeno le
caratteristiche seguenti ai fini della protezione
contro la falsificazione e la manomissione:
— stampa policroma del fondo di sicurezza fine­
mente arabescato,
— nell'area della foto, sovrapposizione del fondo
di sicurezza e della fotografia,
— almeno una linea bicromatica microstampata.
► (1) M1
► (2) M3
236) Previa consultazione della Commissione, gli Stati
membri possono aggiungere colori o iscrizioni,
quali simboli nazionali e caratteristiche di sicu­
rezza, fatte salve le altre disposizioni del presente
allegato.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 72
237) Le carte temporanee di cui all'articolo 26, paragrafo 4,
del regolamento (UE) n. 165/2014 devono essere con­
formi alle disposizioni del presente allegato.
4.2 Sicurezza
La sicurezza del sistema è intesa a proteggere l'integrità e l'autenti­
cità dei dati scambiati tra le carte e l'apparecchio di controllo e
l'integrità e l'autenticità dei dati trasferiti dalle carte, a consentire
determinate operazioni di scrittura sulle carte solo all'apparecchio di
controllo, a decriptare alcuni dati, ad escludere ogni possibilità di
falsificazione dei dati memorizzati sulle carte, ad impedire la mano­
missione e a rilevarne eventuali tentativi.
238) Al fine di garantire la sicurezza del sistema, le
carte tachigrafiche devono soddisfare i requisiti
di sicurezza specificati nelle appendici 10 e 11.
239) Le carte tachigrafiche devono poter essere lette
da altri apparecchi, come i personal computer.
4.3 Norme
240) Le carte tachigrafiche devono essere conformi
alle norme seguenti:
— ISO/IEC 7810 Carte di identificazione — Ca­
ratteristiche fisiche,
— ISO/IEC 7816 Carte di identificazione —
Carte a circuiti integrati:
— Parte 1: Caratteristiche fisiche,
— Parte 2: Dimensioni e posizione dei con­
tatti (ISO/IEC 7816-2:2007),
— Parte 3: Interfaccia elettrica e protocolli di
trasmissione (ISO/IEC 7816-3:2006),
— Parte 4: Organizzazione, sicurezza e co­
mandi per gli scambi (ISO/IEC 7816-
4:2013 + Cor 1:2014),
— Parte 6: Elementi di dati interindustriali per gli
scambi (ISO/IEC 7816-6:2004 + Cor
1:2006),
— Parte 8: Comandi per le operazioni di si­
curezza (ISO/IEC 7816-8:2004).
— Le carte tachigrafiche devono essere sottopo­
ste a prova in conformità alla norma ISO/IEC
10373-3:2010 Carte di identificazione — Me­
todi di prova — Parte 3: Carte a circuiti inte­
grati con contatti e relative interfacce.
4.4 Specifiche ambientali ed elettriche
241) Le carte tachigrafiche devono essere in grado di
funzionare correttamente in tutte le condizioni
climatiche abituali nel territorio della Comunità
e almeno nell'intervallo di temperatura compreso
tra – 25 °C e + 70 °C, con picchi occasionali
fino a + 85 °C, dove per «occasionale» s'intende
non superiore a 4 ore per volta e non superiore a
100 volte nell'intero periodo di durata della carta.
242) Le carte devono poter funzionare correttamente
con un'umidità compresa tra 10 e 90 %.
243) Le carte tachigrafiche devono essere in grado di
funzionare correttamente per un periodo di cin­
que anni, se impiegate nel rispetto delle specifi­
che ambientali ed elettriche.
244) Durante il funzionamento, le carte tachigrafiche
devono essere conformi al regolamento UNECE
n. 10, relativo alla compatibilità elettromagnetica,
e devono essere protette contro le scariche
elettrostatiche.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 73
4.5 Memorizzazione dei dati
Agli effetti del presente punto:
— se non diversamente specificato, i tempi sono registrati con una
risoluzione di un minuto,
— i valori dell'odometro sono registrati con una risoluzione di un
chilometro,
— le velocità sono registrate con una risoluzione di 1 km/h,
— le posizioni (latitudini e longitudini) sono registrate in gradi e
minuti, con una risoluzione di 1/10 di minuto.
Le funzioni, i comandi e le strutture logiche delle carte tachigrafi­
che, che soddisfano i requisiti di memorizzazione dei dati, sono
specificati nell'appendice 2.
Se non diversamente specificato, la memorizzazione dei dati nelle
carte tachigrafiche deve essere organizzata in modo che i nuovi dati
sostituiscano quelli più datati, nel caso in cui lo spazio della me­
moria previsto per quelle registrazioni specifiche sia esaurito.
245) Il presente punto specifica la capacità minima di
memorizzazione per i file di dati destinati alle
diverse applicazioni. Le carte tachigrafiche devono
essere in grado di indicare all'apparecchio di con­
trollo la capacità effettiva di memorizzazione di
tali file di dati.
▼M3
246) Eventuali dati aggiuntivi possono essere memoriz­
zati nelle carte tachigrafiche, a condizione che la
conservazione di tali dati sia conforme alla legi­
slazione applicabile in materia di protezione dei
dati.
▼B
247) Ogni file principale (MF) di ciascuna carta tachi­
grafica deve contenere fino a cinque file
elementari (EF), ai fini della gestione della carta
e dell'identificazione dell'applicazione e del chip, e
due file dedicati (DF):
— DF Tachograph, che contiene l'applicazione
accessibile alle unità elettroniche di bordo di
prima generazione, che è presente anche nelle
carte tachigrafiche di prima generazione,
— DF Tachograph_G2, che contiene l'applica­
zione accessibile solo alle unità elettroniche
di bordo di seconda generazione, che è pre­
sente solo nelle carte tachigrafiche di seconda
generazione.
▼M3
Nota: la versione 2 delle carte di seconda genera­
zione contiene file elementari aggiuntivi in DF
Tachograph_G2.
▼B
Informazioni dettagliate sulla struttura delle carte
tachigrafiche sono riportate nell'appendice 2.
4.5.1 File elementari per l'identificazione e la gestione della carta
4.5.2 Identificazione della carta a circuito integrato
248) Le carte tachigrafiche devono essere in grado di
memorizzare i seguenti dati di identificazione delle
carte intelligenti:
— arresto dell'orologio,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 74
— numero di serie della carta (compresi i riferi­
menti di fabbricazione),
— numero di omologazione della carta,
— identificazione personalizzata della carta (ID),
— identificazione dell'assemblatore della carta,
— identificativo del circuito integrato.
4.5.2.1 I d e n t i f i c a z i o n e d e l c h i p
249) Le carte tachigrafiche devono essere in grado di
memorizzare i seguenti dati di identificazione del
circuito integrato:
— numero di serie del circuito integrato,
— riferimenti di fabbricazione del circuito
integrato.
4.5.2.2 D I R ( p r e s e n t e s o l o n e l l e c a r t e t a c h i g r a f i c h e d i
s e c o n d a g e n e r a z i o n e )
250) Le carte tachigrafiche devono essere in grado di
memorizzare gli oggetti dei dati di identificazione
dell'applicazione specificati nell'appendice 2.
4.5.2.3 I n f o r m a z i o n i A T R ( o p z i o n a l i , p r e s e n t i s o l o
n e l l e c a r t e t a c h i g r a f i c h e d i s e c o n d a g e n e r a ­
z i o n e )
251) Le carte tachigrafiche devono essere in grado di
memorizzare il seguente oggetto di dati informa­
tivi di lunghezza estesa:
— nel caso in cui la carta tachigrafica supporti i
campi di lunghezza estesa, l'oggetto di dati
informativi di lunghezza estesa specificato nel­
l'appendice 2.
4.5.2.4 I n f o r m a z i o n i d i l u n g h e z z a e s t e s a ( o p z i o n a l i ,
p r e s e n t i s o l o n e l l e c a r t e t a c h i g r a f i c h e d i s e ­
c o n d a g e n e r a z i o n e )
252) Le carte tachigrafiche devono essere in grado di
memorizzare i seguenti oggetti di dati informativi
di lunghezza estesa:
— nel caso in cui la carta tachigrafica supporti i
campi di lunghezza estesa, gli oggetti di dati
informativi di lunghezza estesa specificati nel­
l'appendice 2.
4.5.3 Carta del conducente
4.5.3.1 A p p l i c a z i o n e d e l t a c h i g r a f o ( a c c e s s i b i l e a l l e
u n i t à e l e t t r o n i c h e d i b o r d o d i p r i m a e s e c o n d a
g e n e r a z i o n e )
4.5.3.1.1 Identificazione dell'applicazione
253) La carta del conducente deve essere in grado di
memorizzare i seguenti dati di identificazione del­
l'applicazione:
— identificazione dell'applicazione del tachigrafo,
— identificazione del tipo di carta tachigrafica.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 75
4.5.3.1.2 Chiavi e certificati
254) La carta del conducente deve essere in grado di
memorizzare una serie di chiavi crittografiche e di
certificati, come specificato nell'appendice 11,
parte A.
4.5.3.1.3 Identificazione della carta
255) La carta del conducente deve essere in grado di
memorizzare i seguenti dati di identificazione della
carta:
— numero della carta,
— Stato membro di rilascio, denominazione del­
l'autorità di rilascio, data di rilascio,
— data di inizio validità della carta, data di sca­
denza della carta.
4.5.3.1.4 Identificazione del titolare della carta
256) La carta del conducente deve essere in grado di
memorizzare i seguenti dati di identificazione del
titolare:
— cognome del titolare,
— nome/i del titolare,
— data di nascita,
— lingua abituale.
4.5.3.1.5 Trasferimento dei dati della carta
257) La carta del conducente deve essere in grado di
memorizzare i dati seguenti relativi al trasferi­
mento dei dati della carta:
— data e ora dell'ultimo trasferimento di dati
della carta (a fini diversi da quelli di con­
trollo).
258) La carta del conducente deve essere in grado di
conservare una di tali registrazioni.
4.5.3.1.6 Informazioni sulla patente di guida
259) La carta del conducente deve essere in grado di
memorizzare i seguenti dati relativi alla patente di
guida:
— Stato membro di rilascio, denominazione del­
l'autorità di rilascio,
— numero della patente di guida (alla data di
rilascio della carta).
4.5.3.1.7 Dati relativi alle anomalie
Agli effetti del presente punto, l'ora deve essere memorizzata con
una risoluzione di 1 secondo.
260) La carta del conducente deve essere in grado di
memorizzare i dati relativi alle anomalie seguenti,
rilevate dall'apparecchio di controllo a carta
inserita:
— sovrapposizione di orari (se questa carta è la
causa dell'anomalia),
— inserimento della carta durante la guida (se
questa carta è l'oggetto dell'anomalia),
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 76
— chiusura errata ultima sessione carta (se questa
carta è l'oggetto dell'anomalia),
— interruzione dell'alimentazione di energia,
— errore dei dati di movimento,
— tentativi di violazione della sicurezza.
261) Per tali anomalie, la carta del conducente deve
essere in grado di memorizzare i dati seguenti:
— codice dell'anomalia,
— data e ora di inizio dell'anomalia (o di inseri­
mento della carta se l'anomalia era in atto in
tale momento),
— data e ora di termine dell'anomalia (o di estra­
zione della carta se l'anomalia era in atto in
tale momento),
— VRN e Stato membro di immatricolazione del
veicolo in cui si è verificata l'anomalia.
Nota: per l'anomalia «Sovrapposizione di orari»:
— la data e l'ora di inizio dell'anomalia devono
corrispondere alla data e all'ora di estrazione
della carta dal veicolo precedente,
— la data e l'ora di termine dell'anomalia devono
corrispondere alla data e all'ora di inserimento
della carta nel veicolo in uso,
— i dati relativi al veicolo devono corrispondere
al veicolo in uso su cui si verifica l'anomalia.
Nota: per l'anomalia «Chiusura errata ultima ses­
sione carta»:
— la data e l'ora di inizio dell'anomalia devono
corrispondere alla data e all'ora di inserimento
della carta per la sessione chiusa in modo
errato,
— la data e l'ora di termine dell'anomalia devono
corrispondere alla data e all'ora di inserimento
della carta della sessione durante la quale è
stata rilevata l'anomalia (sessione in corso),
— i dati relativi al veicolo devono corrispondere
al veicolo in cui la sessione è stata chiusa in
modo errato.
262) La carta del conducente deve essere in grado di
memorizzare i dati relativi alle sei anomalie più
recenti di ciascun tipo (vale a dire 36 anomalie).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 77
4.5.3.1.8 Dati relativi ai guasti
Agli effetti del presente punto, l'ora deve essere registrata con una
risoluzione di 1 secondo.
263) La carta del conducente deve essere in grado di
memorizzare i dati relativi ai guasti seguenti, rile­
vati dall'apparecchio di controllo a carta inserita:
▼M1
— guasto della carta (se questa carta è l’oggetto
del guasto),
▼B
— guasto dell'apparecchio di controllo.
264) Per tali guasti, la carta del conducente deve essere
in grado di memorizzare i dati seguenti:
— codice di guasto,
— data e ora di inizio del guasto (o di inseri­
mento della carta se il guasto era in atto in
tale momento),
— data e ora di termine del guasto (o di estra­
zione della carta se il guasto era in atto in tale
momento),
— VRN e Stato membro di immatricolazione del
veicolo in cui si è verificato il guasto.
265) La carta del conducente deve essere in grado di
memorizzare i dati relativi ai dodici guasti più
recenti di ciascun tipo (vale a dire 24 guasti).
4.5.3.1.9 Dati relativi all'attività del conducente
266) La carta del conducente deve essere in grado di
memorizzare, per ciascun giorno di calendario in
cui viene usata o ogniqualvolta il conducente in­
serisca manualmente un'attività, i dati seguenti:
— la data,
— un contatore di presenza giornaliera (aumen­
tato di un'unità per ogni giorno di calendario
in cui la carta viene usata),
— la distanza totale percorsa dal conducente du­
rante tale giorno,
— la condizione del conducente alle 00h00,
— ad ogni cambio di attività del conducente e/o
cambio di condizione di guida e/o inserimento
o estrazione della carta:
— la condizione di guida (EQUIPAGGIO,
SINGOLA),
— la sede (slot) (CONDUCENTE, SE­
CONDO CONDUCENTE),
— la condizione della carta (INSERITA,
NON INSERITA),
— l'attività (GUIDA, DISPONIBILITÀ, LA­
VORO, INTERRUZIONE/RIPOSO),
— l'ora del cambio.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 78
267) La memoria della carta del conducente deve essere
in grado di conservare i dati relativi all'attività del
conducente per almeno 28 giorni (l'attività media
di un conducente è intesa come 93 cambi di atti­
vità al giorno).
268) I dati elencati ai requisiti 261, 264 e 266 devono
essere memorizzati in modo da consentire il repe­
rimento delle attività nell'ordine in cui hanno
avuto luogo, anche in caso di sovrapposizione di
orari.
4.5.3.1.10 Dati relativi ai veicoli impiegati
269) La carta del conducente deve essere in grado di
memorizzare, per ogni giorno di calendario in cui
viene usata e per ogni periodo di impiego di un
determinato veicolo in tale giorno (un periodo di
impiego comprende tutti i cicli consecutivi di in­
serimento/estrazione della carta nel veicolo, dal
punto di vista della singola carta), i dati seguenti:
— data e ora del primo impiego del veicolo (cioè
il primo inserimento della carta per questo pe­
riodo di impiego del veicolo o 00h00 se il
periodo di impiego è in corso in tale mo­
mento),
— valore dell'odometro del veicolo in tale
momento,
— data e ora dell'ultimo impiego del veicolo (cioè
l'ultima estrazione della carta per questo pe­
riodo di impiego del veicolo o 23h59 se il
periodo di impiego è in corso in tale mo­
mento),
— valore dell'odometro del veicolo in tale
momento,
— VRN e Stato membro di immatricolazione del
veicolo.
270) La carta del conducente deve essere in grado di
memorizzare almeno 84 di tali registrazioni.
4.5.3.1.11 Luogo in cui inizia e/o termina il periodo di lavoro giornaliero
271) La carta del conducente deve essere in grado di
memorizzare i dati seguenti relativi al luogo in cui
inizia e/o termina il periodo di lavoro giornaliero,
inseriti dal conducente:
— la data e l'ora dell'immissione (o la data/ora
relativa all'immissione, se questa viene effet­
tuata durante la procedura di immissione ma­
nuale),
— il tipo di immissione (inizio o termine, condi­
zione di immissione),
— il paese e la regione inseriti,
— il valore dell'odometro del veicolo.
272) La memoria della carta del conducente deve essere
in grado di conservare almeno 42 coppie di tali
registrazioni.
4.5.3.1.12 Dati relativi alla sessione della carta
273) La carta del conducente deve essere in grado di
memorizzare i dati relativi al veicolo che ha aperto
la sessione in corso:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 79
— data e ora di apertura della sessione (cioè d'in­
serimento della carta) con una risoluzione di
un secondo,
— VRN e Stato membro di immatricolazione.
4.5.3.1.13 Dati relativi alle attività di controllo
274) La carta del conducente deve essere in grado di
memorizzare i dati seguenti, relativi alle attività di
controllo:
— data e ora del controllo,
— numero della carta di controllo e Stato mem­
bro di rilascio,
— tipo di controllo [visualizzazione e/o stampa
e/o trasferimento dati VU e/o trasferimento
dati carta (cfr. nota)],
— periodo trasferito, in caso di trasferimento,
— VRN e Stato membro di immatricolazione del
veicolo in cui è stato effettuato il controllo.
Nota: il trasferimento dei dati della carta è regi­
strato soltanto se viene effettuato attraverso un
apparecchio di controllo.
275) La carta del conducente deve essere in grado di
conservare una di tali registrazioni.
4.5.3.1.14 Dati relativi a condizioni particolari
276) La carta del conducente deve essere in grado di
memorizzare i dati seguenti, relativi a condizioni
particolari immesse a carta inserita [in qualsiasi
sede (slot)]:
— data e ora di immissione,
— tipo di condizione particolare.
277) La carta del conducente deve essere in grado di
memorizzare almeno 56 di tali registrazioni.
▼M3
4.5.3.2 A p p l i c a z i o n e d e l t a c h i g r a f o d i s e c o n d a g e n e r a ­
z i o n e ( n o n a c c e s s i b i l e a l l e u n i t à e l e t t r o n i c h e
d i b o r d o d i p r i m a g e n e r a z i o n e , a c c e s s i b i l e a l l e
v e r s i o n i 1 e 2 d e l l e u n i t à e l e t t r o n i c h e d i b o r d o
d i s e c o n d a g e n e r a z i o n e )
▼B
4.5.3.2.1 Identificazione dell'applicazione
278) La carta del conducente deve essere in grado di
memorizzare i seguenti dati di identificazione del­
l'applicazione:
— identificazione dell'applicazione del tachigrafo,
— identificazione del tipo di carta tachigrafica.
▼M3
4.5.3.2.1.1 Identificazione delle applicazioni aggiuntive (non accessibile me­
diante la versione 1 delle unità elettroniche di bordo di seconda
generazione)
278 bis) La carta del conducente deve essere in grado di
memorizzare i dati di identificazione delle appli­
cazioni aggiuntive applicabili solo alla versione 2.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 80
4.5.3.2.2 Chiavi e certificati
279) La carta del conducente deve essere in grado di
memorizzare una serie di chiavi crittografiche e di
certificati, come specificato nell'appendice 11,
parte B.
4.5.3.2.3 Identificazione della carta
280) La carta del conducente deve essere in grado di
memorizzare i seguenti dati di identificazione della
carta:
— numero della carta,
— Stato membro di rilascio, denominazione del­
l'autorità di rilascio, data di rilascio,
— data di inizio validità della carta, data di sca­
denza della carta.
4.5.3.2.4 Identificazione del titolare della carta
281) La carta del conducente deve essere in grado di
memorizzare i seguenti dati di identificazione del
titolare:
— cognome del titolare,
— nome/i del titolare,
— data di nascita,
— lingua abituale.
4.5.3.2.5 Trasferimento dei dati della carta
282) La carta del conducente deve essere in grado di
memorizzare i dati seguenti relativi al trasferi­
mento dei dati della carta:
— data e ora dell'ultimo trasferimento di dati
della carta (a fini diversi da quelli di con­
trollo).
283) La carta del conducente deve essere in grado di
conservare una di tali registrazioni.
4.5.3.2.6 Informazioni sulla patente di guida
284) La carta del conducente deve essere in grado di
memorizzare i seguenti dati relativi alla patente di
guida:
— Stato membro di rilascio, denominazione del­
l'autorità di rilascio,
— numero della patente di guida (alla data di
rilascio della carta).
4.5.3.2.7 Dati relativi alle anomalie
Agli effetti del presente punto, l'ora deve essere memorizzata con
una risoluzione di 1 secondo.
285) La carta del conducente deve essere in grado di
memorizzare i dati relativi alle anomalie seguenti,
rilevate dall'apparecchio di controllo a carta
inserita:
— sovrapposizione di orari (se questa carta è la
causa dell'anomalia),
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 81
— inserimento della carta durante la guida (se
questa carta è l'oggetto dell'anomalia),
— chiusura errata ultima sessione carta (se questa
carta è l'oggetto dell'anomalia),
— interruzione dell'alimentazione di energia,
— errore di comunicazione con il dispositivo di
comunicazione remota,
— assenza di informazioni sulla posizione prove­
nienti dal ricevitore GNSS,
— errore di comunicazione con il dispositivo
GNSS esterno,
— errore dei dati di movimento,
— dati contrastanti sul movimento del veicolo,
— tentativi di violazione della sicurezza,
— dati contrastanti sull'ora.
286) Per tali anomalie, la carta del conducente deve
essere in grado di memorizzare i dati seguenti:
— codice dell'anomalia,
— data e ora di inizio dell'anomalia (o di inseri­
mento della carta se l'anomalia era in atto in
tale momento),
— data e ora di termine dell'anomalia (o di estra­
zione della carta se l'anomalia era in atto in
tale momento),
— VRN e Stato membro di immatricolazione del
veicolo in cui si è verificata l'anomalia.
Nota: per l'anomalia «Sovrapposizione di orari»:
— la data e l'ora di inizio dell'anomalia devono
corrispondere alla data e all'ora di estrazione
della carta dal veicolo precedente,
— la data e l'ora di termine dell'anomalia devono
corrispondere alla data e all'ora di inserimento
della carta nel veicolo in uso,
— i dati relativi al veicolo devono corrispondere
al veicolo in uso su cui si verifica l'anomalia.
Nota: per l'anomalia «Chiusura errata ultima ses­
sione carta»:
— la data e l'ora di inizio dell'anomalia devono
corrispondere alla data e all'ora di inserimento
della carta per la sessione chiusa in modo
errato,
— la data e l'ora di termine dell'anomalia devono
corrispondere alla data e all'ora di inserimento
della carta della sessione durante la quale è
stata rilevata l'anomalia (sessione in corso),
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 82
— i dati relativi al veicolo devono corrispondere
al veicolo in cui la sessione è stata chiusa in
modo errato.
▼M3
287) La carta del conducente deve essere in grado di
memorizzare i dati relativi alle 12 anomalie più
recenti di ciascun tipo (vale a dire 132 anomalie).
▼B
4.5.3.2.8 Dati relativi ai guasti
Agli effetti del presente punto, l'ora deve essere registrata con una
risoluzione di 1 secondo.
288) La carta del conducente deve essere in grado di
memorizzare i dati relativi ai guasti seguenti, rile­
vati dall'apparecchio di controllo a carta inserita:
▼M1
— guasto della carta (se questa carta è l’oggetto
del guasto),
▼B
— guasto dell'apparecchio di controllo.
289) Per tali guasti, la carta del conducente deve essere
in grado di memorizzare i dati seguenti:
— codice di guasto,
— data e ora di inizio del guasto (o di inseri­
mento della carta se il guasto era in atto in
tale momento),
— data e ora di termine del guasto (o di estra­
zione della carta se il guasto era in atto in tale
momento),
— VRN e Stato membro di immatricolazione del
veicolo in cui si è verificato il guasto.
▼M3
290) La carta del conducente deve essere in grado di
memorizzare i dati relativi ai 24 guasti più recenti
di ciascun tipo (vale a dire 48 guasti).
▼B
4.5.3.2.9 Dati relativi all'attività del conducente
291) La carta del conducente deve essere in grado di
memorizzare, per ciascun giorno di calendario in
cui viene usata o ogniqualvolta il conducente in­
serisca manualmente un'attività, i dati seguenti:
— la data,
— un contatore di presenza giornaliera (aumen­
tato di un'unità per ogni giorno di calendario
in cui la carta viene usata),
— la distanza totale percorsa dal conducente du­
rante tale giorno,
— la condizione del conducente alle 00h00,
— ad ogni cambio di attività del conducente e/o
cambio di condizione di guida e/o inserimento
o estrazione della carta:
— la condizione di guida (EQUIPAGGIO,
SINGOLA),
— la sede (slot) (CONDUCENTE, SE­
CONDO CONDUCENTE),
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 83
— la condizione della carta (INSERITA,
NON INSERITA),
— l'attività (GUIDA, DISPONIBILITÀ, LA­
VORO, INTERRUZIONE/RIPOSO),
— l'ora del cambio.
▼M3
292) La memoria della carta del conducente deve essere
in grado di conservare i dati relativi all’attività del
conducente per 56 giorni (ai fini del presente re­
quisito per attività media del conducente si intende
117 cambi di attività al giorno).
▼B
293) I dati elencati ai requisiti 286, 289 e 291 devono
essere memorizzati in modo da consentire il repe­
rimento delle attività nell'ordine in cui hanno
avuto luogo, anche in caso di sovrapposizione di
orari.
4.5.3.2.10 Dati relativi ai veicoli impiegati
294) La carta del conducente deve essere in grado di
memorizzare, per ogni giorno di calendario in cui
viene usata e per ogni periodo di impiego di un
determinato veicolo in tale giorno (un periodo di
impiego comprende tutti i cicli consecutivi di in­
serimento/estrazione della carta nel veicolo, dal
punto di vista della singola carta), i dati seguenti:
— data e ora del primo impiego del veicolo (cioè
il primo inserimento della carta per questo pe­
riodo di impiego del veicolo o 00h00 se il
periodo di impiego è in corso in tale mo­
mento),
— valore dell'odometro del veicolo all'ora di tale
primo impiego,
— data e ora dell'ultimo impiego del veicolo (cioè
l'ultima estrazione della carta per questo pe­
riodo di impiego del veicolo o 23h59 se il
periodo di impiego è in corso in tale mo­
mento),
— valore dell'odometro del veicolo all'ora di tale
ultimo impiego,
— VRN e Stato membro di immatricolazione del
veicolo,
— VIN del veicolo.
▼M3
295) La carta del conducente deve essere in grado di
memorizzare 200 di tali registrazioni.
▼B
4.5.3.2.11 Luogo e posizione in cui inizia e/o termina il periodo di lavoro
giornaliero
296) La carta del conducente deve essere in grado di
memorizzare i dati seguenti relativi al luogo in cui
inizia e/o termina il periodo di lavoro giornaliero,
inseriti dal conducente:
— la data e l'ora dell'immissione (o la data/ora
relativa all'immissione, se questa viene effet­
tuata durante la procedura di immissione ma­
nuale),
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 84
— il tipo di immissione (inizio o termine, condi­
zione di immissione),
— il paese e la regione inseriti,
— il valore dell'odometro del veicolo,
— la posizione del veicolo,
— l'accuratezza del GNSS, la data e l'ora in cui la
posizione è stata determinata.
▼M3
297) La memoria della carta del conducente deve essere
in grado di conservare 112 di tali registrazioni.
▼B
4.5.3.2.12 Dati relativi alla sessione della carta
298) La carta del conducente deve essere in grado di
memorizzare i dati relativi al veicolo che ha aperto
la sessione in corso:
— data e ora di apertura della sessione (cioè d'in­
serimento della carta) con una risoluzione di
un secondo,
— VRN e Stato membro di immatricolazione.
4.5.3.2.13 Dati relativi alle attività di controllo
299) La carta del conducente deve essere in grado di
memorizzare i dati seguenti, relativi alle attività di
controllo:
— data e ora del controllo,
— numero della carta di controllo e Stato mem­
bro di rilascio,
— tipo di controllo [visualizzazione e/o stampa
e/o trasferimento dati VU e/o trasferimento
dati carta (cfr. nota)],
— periodo trasferito, in caso di trasferimento,
— VRN e Stato membro di immatricolazione del
veicolo in cui è stato effettuato il controllo.
Nota: i requisiti di sicurezza prevedono che il tra­
sferimento dei dati della carta sia registrato sol­
tanto se viene effettuato attraverso un apparecchio
di controllo.
300) La carta del conducente deve essere in grado di
conservare una di tali registrazioni.
4.5.3.2.14 Dati relativi a condizioni particolari
301) La carta del conducente deve essere in grado di
memorizzare i dati seguenti, relativi a condizioni
particolari immesse a carta inserita [in qualsiasi
sede (slot)]:
— data e ora di immissione,
— tipo di condizione particolare.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 85
302) La carta del conducente deve essere in grado di
memorizzare 112 di tali registrazioni.
▼B
4.5.3.2.15 Dati relativi alle unità elettroniche di bordo usate
303) La carta del conducente deve essere in grado di
memorizzare i dati seguenti, relativi alle diverse
unità elettroniche di bordo in cui è stata usata la
carta:
— la data e l'ora d'inizio del periodo d'impiego
dell'unità elettronica di bordo (cioè il primo
inserimento della carta nell'unità elettronica di
bordo per il periodo),
— il fabbricante dell'unità elettronica di bordo,
— il tipo di unità elettronica di bordo,
— il numero di versione del software dell'unità
elettronica di bordo.
▼M3
304) La carta del conducente deve essere in grado di
memorizzare 200 di tali registrazioni.
▼M1
4.5.3.2.16 Dati relativi al luogo in cui si raggiungono le tre ore cumulative di
guida
305) La carta del conducente deve essere in grado di
memorizzare i seguenti dati relativi alla posizione
del veicolo quando il periodo di guida cumulativo
del conducente raggiunge un multiplo di tre ore:
— la data e l’ora in cui il periodo di guida cu­
mulativo raggiunge un multiplo di tre ore,
— la posizione del veicolo,
— l’accuratezza del GNSS, la data e l’ora in cui
la posizione è stata determinata,
— il valore dell’odometro del veicolo.
▼M3
306) La carta del conducente deve essere in grado di
memorizzare 336 di tali registrazioni.
4.5.3.2.17 Stato di autenticazione per le posizioni relative a luoghi dove ini­
ziano e/o terminano i periodi di lavoro giornalieri (non accessibile
mediante la versione 1 delle unità elettroniche di bordo di seconda
generazione)
306 bis) La carta del conducente deve essere in grado di
memorizzare dati aggiuntivi relativi al luogo in cui
inizia e/o termina il periodo di lavoro giornaliero,
immessi dal conducente in conformità al
punto 4.5.3.2.11:
— la data e l’ora dell’immissione, che devono
corrispondere esattamente alla data e all’ora
memorizzate in EF Places sotto il DF Tacho­
graph_G2,
— un indicatore che segnali se la posizione è
stata autenticata.
306 ter) La memoria della carta del conducente deve essere
in grado di conservare 112 di tali registrazioni.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 86
4.5.3.2.18 Stato di autenticazione per le posizioni in cui il periodo di guida
cumulativo raggiunge le tre ore (non accessibile mediante la ver­
sione 1 delle unità elettroniche di bordo di seconda generazione)
306 quater) La carta del conducente deve essere in grado di
memorizzare dati aggiuntivi relativi alla posi­
zione del veicolo quando il periodo di guida cu­
mulativo del conducente raggiunge un multiplo
di tre ore in conformità al punto 4.5.3.2.16:
— la data e l’ora in cui il periodo di guida cu­
mulativo raggiunge un multiplo di tre ore,
che devono corrispondere esattamente alla
data e all’ora memorizzate in EF GNSS_Pla­
ces sotto il DF Tachograph_G2,
— un indicatore che segnali se la posizione è
stata autenticata.
306 quinquies) La carta del conducente deve essere in grado di
memorizzare 336 di tali registrazioni.
4.5.3.2.19 Attraversamenti di frontiera (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
306 sexies) La carta del conducente deve essere in grado di
memorizzare i seguenti dati relativi agli attraver­
samenti di frontiera al momento dell’inserimento
della carta conformemente al requisito 147 ter o
con la carta già inserita:
— il paese che il veicolo sta lasciando,
— il paese in cui il veicolo sta entrando,
— la data e l’ora in cui il veicolo ha attraversato
la frontiera,
— la posizione del veicolo al momento dell’at­
traversamento della frontiera;
— l’accuratezza del GNSS,
— un indicatore che segnali se la posizione è
stata autenticata,
— il valore dell’odometro del veicolo.
306 septies) La memoria della carta del conducente deve es­
sere in grado di memorizzare 1 120 di tali
registrazioni.
4.5.3.2.20 Operazioni di carico/scarico (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
306 octies) La carta del conducente deve essere in grado di
memorizzare i dati seguenti, relativi alle opera­
zioni di carico/scarico:
— il tipo di operazione (carico, scarico o carico/
scarico simultanei),
— la data e l’ora dell’operazione di carico/sca­
rico,
— la posizione del veicolo,
— l’accuratezza del GNSS, la data e l’ora in cui
la posizione è stata determinata,
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 87
— un indicatore che segnali se la posizione è
stata autenticata,
— il valore dell’odometro del veicolo.
306 nonies) La carta del conducente deve essere in grado di
memorizzare 1 624 di tali operazioni di carico/
scarico.
4.5.3.2.21 Immissioni relative al tipo di carico (non accessibili mediante la
versione 1 delle unità elettroniche di bordo di seconda generazione)
306 decies) La carta del conducente deve essere in grado di
memorizzare i dati seguenti, relativi al tipo di
carico, immessi automaticamente dalla VU a
ogni inserimento della carta:
— il tipo di carico immesso (merci o passeg­
geri),
— la data e l’ora dell’immissione.
306 undecies) La carta del conducente deve essere in grado di
memorizzare 336 di tali registrazioni.
4.5.3.2.22 Configurazioni della VU (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
306 duodecies) La carta del conducente deve essere in grado di
memorizzare le impostazioni specifiche del tachi­
grafo del titolare della carta.
306 terdecies) La capacità di memorizzazione della carta del
conducente per le impostazioni specifiche del ta­
chigrafo del titolare della carta deve essere di
3072 byte.
▼B
4.5.4 Carta dell'officina
4.5.4.1 A p p l i c a z i o n e d e l t a c h i g r a f o ( a c c e s s i b i l e a l l e
u n i t à e l e t t r o n i c h e d i b o r d o d i p r i m a e s e c o n d a
g e n e r a z i o n e )
4.5.4.1.1 Identificazione dell'applicazione
307) La carta dell'officina deve essere in grado di me­
morizzare i seguenti dati di identificazione del­
l'applicazione:
— identificazione dell'applicazione del
tachigrafo,
— identificazione del tipo di carta tachigrafica.
4.5.4.1.2 Chiavi e certificati
308) La carta dell'officina deve essere in grado di me­
morizzare una serie di chiavi crittografiche e di
certificati, come specificato nell'appendice 11,
parte A.
309) La carta dell'officina deve essere in grado di me­
morizzare un numero di identificazione personale
(codice PIN).
4.5.4.1.3 Identificazione della carta
310) La carta dell'officina deve essere in grado di me­
morizzare i seguenti dati di identificazione della
carta:
— numero della carta,
— Stato membro di rilascio, denominazione del­
l'autorità di rilascio, data di rilascio,
— data di inizio validità della carta, data di sca­
denza della carta.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 88
4.5.4.1.4 Identificazione del titolare della carta
311) La carta dell'officina deve essere in grado di me­
morizzare i seguenti dati di identificazione del
titolare della carta:
— denominazione dell'officina,
— indirizzo dell'officina,
— cognome del titolare,
— nome/i del titolare,
— lingua abituale.
4.5.4.1.5 Trasferimento dei dati della carta
312) La carta dell'officina deve essere in grado di me­
morizzare un registro di dati del trasferimento dei
dati della carta allo stesso modo della carta del
conducente.
4.5.4.1.6 Dati relativi a taratura e regolazione dell'ora
313) La carta dell'officina deve essere in grado di con­
servare i dati relativi alle tarature e/o alle regola­
zioni dell'ora effettuate a carta inserita nell'appa­
recchio di controllo.
314) Ogni registrazione relativa alla taratura deve es­
sere in grado di contenere i dati seguenti:
— scopo della taratura (attivazione, primo mon­
taggio, montaggio, controllo periodico),
— identificazione del veicolo,
— parametri aggiornati o confermati (w, k, l,
dimensioni degli pneumatici, regolazione del
limitatore di velocità, odometro (vecchio e
nuovo valore), data e ora (vecchio e nuovo
valore),
— identificazione dell'apparecchio di controllo
(codice componente della VU, numero di se­
rie della VU, numero di serie del sensore di
movimento).
315) La carta dell'officina deve essere in grado di me­
morizzare almeno 88 di tali registrazioni.
316) La carta dell'officina deve contenere un contatore
che indichi il numero totale di tarature effettuate
con la carta stessa.
317) La carta dell'officina deve contenere un contatore
che indichi il numero di tarature effettuate a par­
tire dall'ultimo trasferimento di dati della carta
stessa.
4.5.4.1.7 Dati relativi ad anomalie e guasti
318) La carta dell'officina deve essere in grado di me­
morizzare i registri dei dati delle anomalie e dei
guasti allo stesso modo della carta del
conducente.
319) La carta dell'officina deve essere in grado di me­
morizzare i dati relativi alle ultime tre anomalie
di ciascun tipo (cioè 18 anomalie) e agli ultimi
sei guasti di ciascun tipo (cioè 12 guasti).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 89
4.5.4.1.8 Dati relativi all'attività del conducente
320) La carta dell'officina deve essere in grado di me­
morizzare i dati relativi all'attività del conducente
allo stesso modo della carta del conducente.
321) La carta dell'officina deve essere in grado di con­
servare tali dati per almeno 1 giorno di attività
media del conducente.
4.5.4.1.9 Dati relativi ai veicoli impiegati
322) La carta dell'officina deve essere in grado di me­
morizzare i dati relativi ai veicoli impiegati allo
stesso modo della carta del conducente.
323) La carta dell'officina deve essere in grado di me­
morizzare almeno 4 di tali registrazioni.
4.5.4.1.10 Dati relativi all'inizio e/o al termine del periodo di lavoro giornaliero
324) La carta dell'officina deve essere in grado di me­
morizzare i dati relativi all'inizio e/o al termine
del periodo di lavoro giornaliero allo stesso modo
della carta del conducente.
325) La carta dell'officina deve essere in grado di con­
servare almeno 3 coppie di tali registrazioni.
4.5.4.1.11 Dati relativi alla sessione della carta
326) La carta dell'officina deve essere in grado di me­
morizzare un registro di dati della sessione della
carta allo stesso modo della carta del conducente.
4.5.4.1.12 Dati relativi alle attività di controllo
327) La carta dell'officina deve essere in grado di me­
morizzare i dati relativi alle attività di controllo
allo stesso modo della carta del conducente.
4.5.4.1.13 Dati relativi a condizioni particolari
328) La carta dell'officina deve essere in grado di me­
morizzare i dati relativi a condizioni particolari
allo stesso modo della carta del conducente.
329) La carta dell'officina deve essere in grado di me­
morizzare almeno 2 di tali registrazioni.
▼M3
4.5.4.2 A p p l i c a z i o n e d e l t a c h i g r a f o d i s e c o n d a g e n e r a ­
z i o n e ( n o n a c c e s s i b i l e a l l e u n i t à e l e t t r o n i c h e
d i b o r d o d i p r i m a g e n e r a z i o n e , a c c e s s i b i l e a l l e
v e r s i o n i 1 e 2 d e l l e u n i t à e l e t t r o n i c h e d i b o r d o
d i s e c o n d a g e n e r a z i o n e )
▼B
4.5.4.2.1 Identificazione dell'applicazione
330) La carta dell'officina deve essere in grado di me­
morizzare i seguenti dati di identificazione del­
l'applicazione:
— identificazione dell'applicazione del tachi­
grafo,
— identificazione del tipo di carta tachigrafica.
▼M3
4.5.4.2.1.1 Identificazione delle applicazioni aggiuntive (non accessibile me­
diante la versione 1 delle unità elettroniche di bordo di seconda
generazione)
330a) La carta dell’officina deve essere in grado di
memorizzare i dati di identificazione delle appli­
cazioni aggiuntive applicabili solo alla versione 2.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 90
4.5.4.2.2 Chiavi e certificati
331) La carta dell'officina deve essere in grado di me­
morizzare una serie di chiavi crittografiche e di
certificati, come specificato nell'appendice 11,
parte B.
332) La carta dell'officina deve essere in grado di me­
morizzare un numero di identificazione personale
(codice PIN).
4.5.4.2.3 Identificazione della carta
333) La carta dell'officina deve essere in grado di me­
morizzare i seguenti dati di identificazione della
carta:
— numero della carta,
— Stato membro di rilascio, denominazione del­
l'autorità di rilascio, data di rilascio,
— data di inizio validità della carta, data di sca­
denza della carta.
4.5.4.2.4 Identificazione del titolare della carta
334) La carta dell'officina deve essere in grado di me­
morizzare i seguenti dati di identificazione del
titolare della carta:
— denominazione dell'officina,
— indirizzo dell'officina,
— cognome del titolare,
— nome/i del titolare,
— lingua abituale.
4.5.4.2.5 Trasferimento dei dati della carta
335) La carta dell'officina deve essere in grado di me­
morizzare un registro di dati del trasferimento dei
dati della carta allo stesso modo della carta del
conducente.
4.5.4.2.6 Dati relativi a taratura e regolazione dell'ora
336) La carta dell'officina deve essere in grado di con­
servare i dati relativi alle tarature e/o alle regola­
zioni dell'ora effettuate a carta inserita nell'appa­
recchio di controllo.
337) Ogni registrazione relativa alla taratura deve es­
sere in grado di contenere i dati seguenti:
— scopo della taratura (attivazione, primo mon­
taggio, montaggio, controllo periodico),
— identificazione del veicolo,
— parametri aggiornati o confermati (w, k, l,
dimensioni degli pneumatici, regolazione del
limitatore di velocità, odometro (vecchio e
nuovo valore), data e ora (vecchio e nuovo
valore),
— identificazione dell'apparecchio di controllo
(codice componente della VU, numero di se­
rie della VU, numero di serie del sensore di
movimento, numero di serie del dispositivo di
comunicazione remota e numero di serie del
dispositivo GNSS esterno, se applicabile),
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 91
— tipo e identificativo di tutti i sigilli apposti,
— capacità della VU di utilizzare carte tachigra­
fiche di prima generazione (attivata o meno).
▼M3
338) La carta dell’officina deve essere in grado di
memorizzare 255 di tali registrazioni.
▼B
339) La carta dell'officina deve contenere un contatore
che indichi il numero totale di tarature effettuate
con la carta stessa.
340) La carta dell'officina deve contenere un contatore
che indichi il numero di tarature effettuate a par­
tire dall'ultimo trasferimento di dati della carta
stessa.
4.5.4.2.7 Dati relativi ad anomalie e guasti
341) La carta dell'officina deve essere in grado di me­
morizzare i registri dei dati delle anomalie e dei
guasti allo stesso modo della carta del
conducente.
342) La carta dell'officina deve essere in grado di me­
morizzare i dati relativi alle ultime tre anomalie
di ciascun tipo (cioè 33 anomalie) e agli ultimi
sei guasti di ciascun tipo (cioè 12 guasti).
4.5.4.2.8 Dati relativi all'attività del conducente
343) La carta dell'officina deve essere in grado di me­
morizzare i dati relativi all'attività del conducente
allo stesso modo della carta del conducente.
▼M3
344) La carta dell’officina deve essere in grado di
conservare l’attività del conducente per 1 giorno
comprendente 240 cambi di attività.
▼B
4.5.4.2.9 Dati relativi ai veicoli impiegati
345) La carta dell'officina deve essere in grado di me­
morizzare i dati relativi ai veicoli impiegati allo
stesso modo della carta del conducente.
▼M3
346) La carta dell’officina deve essere in grado di
memorizzare 8 di tali registrazioni.
4.5.4.2.10 Dati relativi a luoghi e posizioni in cui iniziano e/o terminano i
periodi di lavoro giornaliero
347) La carta dell’officina deve essere in grado di
memorizzare le registrazioni dei dati relativi a
luoghi e posizioni in cui iniziano e/o terminano
i periodi di lavoro giornaliero allo stesso modo
della carta del conducente.
348) La carta dell’officina deve essere in grado di
memorizzare 4 coppie di tali registrazioni.
▼B
4.5.4.2.11 Dati relativi alla sessione della carta
349) La carta dell'officina deve essere in grado di me­
morizzare un registro di dati della sessione della
carta allo stesso modo della carta del conducente.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 92
4.5.4.2.12 Dati relativi alle attività di controllo
350) La carta dell'officina deve essere in grado di me­
morizzare i dati relativi alle attività di controllo
allo stesso modo della carta del conducente.
4.5.4.2.13 Dati relativi alle unità elettroniche di bordo usate
351) La carta dell'officina deve essere in grado di me­
morizzare i dati seguenti, relativi alle diverse
unità elettroniche di bordo in cui è stata usata
la carta:
— la data e l'ora d'inizio del periodo d'impiego
dell'unità elettronica di bordo (cioè il primo
inserimento della carta nell'unità elettronica di
bordo per il periodo),
— il fabbricante dell'unità elettronica di bordo,
— il tipo di unità elettronica di bordo,
— il numero di versione del software dell'unità
elettronica di bordo.
▼M3
352) La carta dell’officina deve essere in grado di
memorizzare 8 di tali registrazioni.
▼M1
4.5.4.2.14 Dati relativi al luogo in cui si raggiungono le tre ore cumulative di
guida
353) La carta dell’officina deve essere in grado di
memorizzare i seguenti dati relativi alla posizione
del veicolo quando il periodo di guida cumula­
tivo del conducente raggiunge un multiplo di tre
ore:
— la data e l’ora in cui il periodo di guida cu­
mulativo raggiunge un multiplo di tre ore,
— la posizione del veicolo,
— l’accuratezza del GNSS, la data e l’ora in cui
la posizione è stata determinata,
— il valore dell’odometro del veicolo.
▼M3
354) La carta dell’officina deve essere in grado di
memorizzare 24 di tali registrazioni.
▼B
4.5.4.2.15 Dati relativi a condizioni particolari
355) La carta dell'officina deve essere in grado di me­
morizzare i dati relativi a condizioni particolari
allo stesso modo della carta del conducente.
▼M3
356) La carta dell’officina deve essere in grado di
memorizzare 4 di tali registrazioni.
4.5.4.2.16 Stato di autenticazione per le posizioni relative a luoghi dove ini­
ziano e/o terminano i periodi di lavoro giornalieri (non accessibile
mediante la versione 1 delle unità elettroniche di bordo di seconda
generazione)
356 bis) La carta dell’officina deve essere in grado di
memorizzare dati aggiuntivi relativi ai luoghi in
cui iniziano e/o terminano i periodi di lavoro
giornaliero allo stesso modo della carta del
conducente.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 93
356 ter) La memoria della carta dell’officina deve essere
in grado di memorizzare 4 coppie di tali
registrazioni.
4.5.4.2.17 Stato di autenticazione per le posizioni dove il periodo di guida
cumulativo raggiunge le tre ore (non accessibile mediante la ver­
sione 1 delle unità elettroniche di bordo di seconda generazione)
356 quater) La carta dell’officina deve essere in grado di
memorizzare dati aggiuntivi relativi alla posi­
zione del veicolo in cui il periodo di guida cu­
mulativo del conducente raggiunge un multiplo
di tre ore allo stesso modo della carta del
conducente.
356 quinquies) La carta dell’officina deve essere in grado di
memorizzare 24 di tali registrazioni.
4.5.4.2.18 Attraversamenti di frontiera (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
356 sexies) La carta dell’officina deve essere in grado di
memorizzare gli attraversamenti di frontiera allo
stesso modo della carta del conducente.
356 septies) La memoria della carta dell’officina deve essere
in grado di memorizzare 4 di tali registrazioni.
4.5.4.2.19 Operazioni di carico/scarico (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
356 octies) La carta dell’officina deve essere in grado di
memorizzare le operazioni di carico/scarico allo
stesso modo della carta del conducente.
356 nonies) La carta dell’officina deve essere in grado di
memorizzare 8 operazioni di carico, di scarico
o di carico/scarico simultanei.
4.5.4.2.20 Immissioni relative al tipo di carico (non accessibili mediante la
versione 1 delle unità elettroniche di bordo di seconda generazione)
356 decies) La carta dell’officina deve essere in grado di
memorizzare le immissioni dei tipi di carico
allo stesso modo della carta del conducente.
356 undecies) La carta dell’officina deve essere in grado di
memorizzare 4 di tali registrazioni.
4.5.4.2.21 Dati aggiuntivi relativi alla taratura (non accessibili mediante la
versione 1 delle unità elettroniche di bordo di seconda generazione)
356 duodecies) La carta dell’officina deve essere in grado di
memorizzare i dati di taratura aggiuntivi applica­
bili solo alla versione 2:
— il vecchio valore di data e ora e il numero di
identificazione del veicolo, che devono corri­
spondere esattamente agli stessi valori memo­
rizzati in EF Calibration sotto il DF Tacho­
graph_G2,
— il tipo di carico predefinito immesso durante
la taratura,
— il paese in cui è stata effettuata la taratura e la
data e l’ora in cui è stata fornita dal ricevitore
GNSS la posizione utilizzata per determinare
tale paese.
356 terdecies) La carta dell’officina deve essere in grado di
memorizzare 255 di tali registrazioni.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 94
4.5.4.2.22 Configurazioni della VU (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
356 quaterdecies) La carta dell’officina deve essere in grado di
memorizzare le impostazioni specifiche del tachi­
grafo del titolare della carta.
356 quindecies) La capacità di memorizzazione della carta
dell’officina per le impostazioni specifiche del
tachigrafo del titolare della carta deve essere di
3072 byte.
▼B
4.5.5 Carta di controllo
4.5.5.1 A p p l i c a z i o n e d e l t a c h i g r a f o ( a c c e s s i b i l e a l l e
u n i t à e l e t t r o n i c h e d i b o r d o d i p r i m a e s e c o n d a
g e n e r a z i o n e )
4.5.5.1.1 Identificazione dell'applicazione
357) La carta di controllo deve essere in grado di
memorizzare i seguenti dati di identificazione
dell'applicazione:
— identificazione dell'applicazione del
tachigrafo,
— identificazione del tipo di carta tachigrafica.
4.5.5.1.2 Chiavi e certificati
358) La carta di controllo deve essere in grado di
memorizzare una serie di chiavi crittografiche e
di certificati, come specificato nell'appendice 11,
parte A.
4.5.5.1.3 Identificazione della carta
359) La carta di controllo deve essere in grado di
memorizzare i seguenti dati di identificazione
della carta:
— numero della carta,
— Stato membro di rilascio, denominazione del­
l'autorità di rilascio, data di rilascio,
— data di inizio validità della carta, data di sca­
denza della carta (se presente).
4.5.5.1.4 Identificazione del titolare della carta
360) La carta di controllo deve essere in grado di
memorizzare i seguenti dati di identificazione
del titolare:
— denominazione dell'organismo di controllo,
— indirizzo dell'organismo di controllo,
— cognome del titolare,
— nome/i del titolare,
— lingua abituale.
4.5.5.1.5 Dati relativi alle attività di controllo
361) La carta di controllo deve essere in grado di
memorizzare i dati seguenti, relativi alle attività
di controllo:
— data e ora del controllo,
▼M3
— tipo di controllo (visualizzazione e/o stampa
e/o trasferimento dati VU e/o trasferimento
dati carta),
▼B
— periodo cui si riferiscono i dati (se del caso),
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 95
— VRN e autorità di immatricolazione del vei­
colo controllato dello Stato membro,
— numero della carta e Stato membro di rilascio
della carta del conducente controllata.
362) La carta di controllo deve essere in grado di
conservare almeno 230 di tali registrazioni.
4.5.5.2 A p p l i c a z i o n e d e l t a c h i g r a f o d i s e c o n d a g e n e r a ­
z i o n e ( n o n a c c e s s i b i l e a l l e u n i t à e l e t t r o n i c h e
d i b o r d o d i p r i m a g e n e r a z i o n e )
4.5.5.2.1 Identificazione dell'applicazione
363) La carta di controllo deve essere in grado di
memorizzare i seguenti dati di identificazione
dell'applicazione:
— identificazione dell'applicazione del
tachigrafo,
— identificazione del tipo di carta tachigrafica.
▼M3
4.5.5.2.1.1 Identificazione delle applicazioni aggiuntive (non accessibile me­
diante la versione 1 delle unità elettroniche di bordo di seconda
generazione)
363 bis) La carta di controllo deve essere in grado di
memorizzare i dati di identificazione delle appli­
cazioni aggiuntive applicabili solo alla ver­
sione 2.
▼B
4.5.5.2.2 Chiavi e certificati
364) La carta di controllo deve essere in grado di
memorizzare una serie di chiavi crittografiche e
di certificati, come specificato nell'appendice 11,
parte B.
4.5.5.2.3 Identificazione della carta
365) La carta di controllo deve essere in grado di
memorizzare i seguenti dati di identificazione
della carta:
— numero della carta,
— Stato membro di rilascio, denominazione del­
l'autorità di rilascio, data di rilascio,
— data di inizio validità della carta, data di sca­
denza della carta (se presente).
4.5.5.2.4 Identificazione del titolare della carta
366) La carta di controllo deve essere in grado di
memorizzare i seguenti dati di identificazione
del titolare:
— denominazione dell'organismo di controllo,
— indirizzo dell'organismo di controllo,
— cognome del titolare,
— nome/i del titolare,
— lingua abituale.
4.5.5.2.5 Dati relativi alle attività di controllo
367) La carta di controllo deve essere in grado di
memorizzare i dati seguenti, relativi alle attività
di controllo:
— data e ora del controllo,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 96
— tipo di controllo (visualizzazione e/o stampa
e/o trasferimento dati VU e/o trasferimento
dati carta e/o verifica della taratura su strada),
— periodo cui si riferiscono i dati (se del caso),
— VRN e autorità di immatricolazione del vei­
colo controllato dello Stato membro,
— numero della carta e Stato membro di rilascio
della carta del conducente controllata.
368) La carta di controllo deve essere in grado di
conservare almeno 230 di tali registrazioni.
▼M3
4.5.5.2.6 Configurazioni della VU (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
368 bis) La carta di controllo deve essere in grado di
memorizzare le impostazioni specifiche del tachi­
grafo del titolare della carta.
368 ter) La capacità di memorizzazione della carta di con­
trollo per le impostazioni specifiche del tachi­
grafo del titolare della carta deve essere di
3072 byte.
▼B
4.5.6 Carta dell'azienda
4.5.6.1 A p p l i c a z i o n e d e l t a c h i g r a f o ( a c c e s s i b i l e a l l e
u n i t à e l e t t r o n i c h e d i b o r d o d i p r i m a e s e c o n d a
g e n e r a z i o n e )
4.5.6.1.1 Identificazione dell'applicazione
369) La carta dell'azienda deve essere in grado di me­
morizzare i seguenti dati di identificazione del­
l'applicazione:
— identificazione dell'applicazione del
tachigrafo,
— identificazione del tipo di carta tachigrafica.
4.5.6.1.2 Chiavi e certificati
370) La carta dell'azienda deve essere in grado di me­
morizzare una serie di chiavi crittografiche e di
certificati, come specificato nell'appendice 11,
parte A.
4.5.6.1.3 Identificazione della carta
371) La carta dell'azienda deve essere in grado di me­
morizzare i seguenti dati di identificazione della
carta:
— numero della carta,
— Stato membro di rilascio, denominazione del­
l'autorità di rilascio, data di rilascio,
— data di inizio validità della carta, data di sca­
denza della carta (se presente).
4.5.6.1.4 Identificazione del titolare della carta
372) La carta dell'azienda deve essere in grado di me­
morizzare i seguenti dati di identificazione del
titolare:
— denominazione dell'azienda,
— indirizzo dell'azienda.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 97
4.5.6.1.5 Dati relativi alle attività dell'impresa
373) La carta dell'azienda deve essere in grado di me­
morizzare i dati seguenti, relativi alle attività del­
l'impresa:
— data e ora dell'attività,
— tipo di attività (attivazione e/o disattivazione
blocco VU e/o trasferimento dati VU e/o tra­
sferimento dati carta),
— periodo cui si riferiscono i dati (se del caso),
— VRN e autorità di immatricolazione del vei­
colo dello Stato membro,
— numero della carta e Stato membro di rilascio
(in caso di trasferimento dei dati della carta).
374) La carta dell'azienda deve essere in grado di con­
servare almeno 230 di tali registrazioni.
4.5.6.2 A p p l i c a z i o n e d e l t a c h i g r a f o d i s e c o n d a g e n e r a ­
z i o n e ( n o n a c c e s s i b i l e a l l e u n i t à e l e t t r o n i c h e
d i b o r d o d i p r i m a g e n e r a z i o n e )
4.5.6.2.1 Identificazione dell'applicazione
375) La carta dell'azienda deve essere in grado di me­
morizzare i seguenti dati di identificazione del­
l'applicazione:
— identificazione dell'applicazione del
tachigrafo,
— identificazione del tipo di carta tachigrafica.
▼M3
4.5.6.2.1.1 Identificazione delle applicazioni aggiuntive (non accessibile me­
diante la versione 1 delle unità elettroniche di bordo di seconda
generazione)
375 bis) La carta dell’azienda deve essere in grado di
memorizzare i dati di identificazione delle appli­
cazioni aggiuntive applicabili solo alla ver­
sione 2.
▼B
4.5.6.2.2 Chiavi e certificati
376) La carta dell'azienda deve essere in grado di me­
morizzare una serie di chiavi crittografiche e di
certificati, come specificato nell'appendice 11,
parte B.
4.5.6.2.3 Identificazione della carta
377) La carta dell'azienda deve essere in grado di me­
morizzare i seguenti dati di identificazione della
carta:
— numero della carta,
— Stato membro di rilascio, denominazione del­
l'autorità di rilascio, data di rilascio,
— data di inizio validità della carta, data di sca­
denza della carta (se presente).
4.5.6.2.4 Identificazione del titolare della carta
378) La carta dell'azienda deve essere in grado di me­
morizzare i seguenti dati di identificazione del
titolare:
— denominazione dell'azienda,
— indirizzo dell'azienda.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 98
4.5.6.2.5 Dati relativi alle attività dell'impresa
379) La carta dell'azienda deve essere in grado di me­
morizzare i dati seguenti, relativi alle attività del­
l'impresa:
— data e ora dell'attività,
— tipo di attività (attivazione e/o disattivazione
blocco VU e/o trasferimento dati VU e/o tra­
sferimento dati carta),
— periodo cui si riferiscono i dati (se del caso),
— VRN e autorità di immatricolazione del vei­
colo dello Stato membro,
— numero della carta e Stato membro di rilascio
(in caso di trasferimento dei dati della carta).
380) La carta dell'azienda deve essere in grado di con­
servare almeno 230 di tali registrazioni.
▼M3
4.5.6.2.6 Configurazioni della VU (non accessibili mediante la versione 1
delle unità elettroniche di bordo di seconda generazione)
380 bis) La carta dell’azienda deve essere in grado di
memorizzare le impostazioni specifiche del tachi­
grafo del titolare della carta.
380 ter) La capacità di memorizzazione della carta
dell’azienda per le impostazioni specifiche del
tachigrafo del titolare della carta deve essere di
3072 byte.
▼B
5 MONTAGGIO DELL'APPARECCHIO DI CONTROLLO
5.1 Montaggio
381) Gli apparecchi di controllo nuovi devono essere
consegnati agli installatori o ai costruttori di vei­
coli prima dell'attivazione con tutti i parametri di
taratura elencati al punto 3.21 impostati su valori
predefiniti corretti e validi. In assenza di un va­
lore corretto, i parametri alfabetici devono essere
impostati come stringhe di «?» e i parametri nu­
merici devono essere impostati su «0». La conse­
gna di parti dell'apparecchio di controllo aventi
attinenza con la sicurezza può essere limitata se
necessario durante la certificazione della
sicurezza.
382) Prima dell'attivazione, l'apparecchio di controllo
deve consentire l'accesso alla funzione di taratura
anche in modalità di funzionamento diverse dal
modo taratura.
▼M3
383) Prima dell’attivazione, l’apparecchio di controllo
non deve registrare né memorizzare i dati men­
zionati nei requisiti da 102 a 133 incluso. Tutta­
via, prima della sua attivazione, l’apparecchio di
controllo può registrare e memorizzare le anoma­
lie relative a tentativi di violazione della sicu­
rezza conformemente al requisito 117 e i guasti
dell’apparecchio di controllo conformemente al
requisito 118.
▼B
384) Durante il montaggio, i costruttori di veicoli de­
vono preimpostare tutti i parametri noti.
385) I costruttori di veicoli o gli installatori devono
procedere all'attivazione dell'apparecchio di con­
trollo montato sul veicolo al più tardi prima che
esso sia adibito agli usi previsti nel
regolamento (CE) n. 561/2006.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 99
386) L'attivazione dell'apparecchio di controllo deve
avvenire automaticamente al primo inserimento
di una carta dell'officina valida in una qualsiasi
delle interfacce della carta.
387) Le operazioni specifiche di abbinamento tra il
sensore di movimento e l'unità elettronica di
bordo, se del caso, devono avvenire automatica­
mente prima o durante l'attivazione.
388) Analogamente, le operazioni specifiche di accop­
piamento tra il dispositivo GNSS esterno e l'unità
elettronica di bordo, se del caso, devono avvenire
automaticamente prima o durante l'attivazione.
389) Dopo l'attivazione, l'apparecchio di controllo
deve essere in grado di funzionare correttamente
e riconoscere tutti i diritti di accesso ai dati.
390) Dopo l'attivazione, l'apparecchio di controllo
deve comunicare al dispositivo di comunicazione
remota i dati protetti necessari ai fini dei controlli
su strada mirati.
391) Dopo l'attivazione si devono poter usare tutte le
funzioni di registrazione e memorizzazione del­
l'apparecchio di controllo.
▼M3
392) Dopo il montaggio occorre procedere alla tara­
tura. La prima taratura non deve necessariamente
includere l’immissione dell’identificazione di im­
matricolazione del veicolo (VRN e Stato mem­
bro), qualora essa non sia nota all’officina auto­
rizzata che deve effettuare tale taratura. In queste
circostanze, ed esclusivamente per tale prima
volta, deve poter essere possibile per il proprie­
tario del veicolo immettere VRN e Stato membro
utilizzando la sua carta dell’azienda prima di adi­
bire il veicolo agli usi previsti nel
regolamento (CE) n. 561/2006 (ad esempio uti­
lizzando i comandi mediante una struttura di
menù appropriata dell’interfaccia
uomo-macchina dell’unità elettronica di bordo).
L’aggiornamento o la conferma di tale immis­
sione devono essere possibili esclusivamente uti­
lizzando una carta dell’officina.
▼B
393) Il montaggio di un dispositivo GNSS esterno ri­
chiede l'accoppiamento con l'unità elettronica di
bordo e la successiva verifica delle informazioni
sulla posizione del GNSS.
394) L'apparecchio di controllo deve essere posizio­
nato a bordo del veicolo in modo tale da consen­
tire al conducente di accedere a tutte le funzioni
dal posto di guida.
5.2 Targhetta di montaggio
395) ►M3 Dopo la verifica dell’apparecchio di con­
trollo in sede di montaggio, deve essere affissa
sull’apparecchio di controllo, in un
punto chiaramente visibile e facilmente accessi­
bile, una targhetta di montaggio, incisa o stam­
pata in modo permanente. Nei casi in cui ciò non
sia possibile, la targhetta va affissa in posizione
facilmente visibile sul montante «B» del veicolo.
Nel caso dei veicoli sprovvisti di montante «B»,
la targhetta di montaggio dovrebbe essere appo­
sta in un’area della portiera del veicolo ed essere
chiaramente visibile in tutti i casi. ◄
Dopo ogni intervento da parte di un installatore o
di un'officina autorizzati deve essere apposta una
nuova targhetta in sostituzione della precedente.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 100
396) Sulla targhetta devono essere riportate almeno le
indicazioni seguenti:
— nome, indirizzo o denominazione commer­
ciale dell’installatore o dell’officina
autorizzati,
— coefficiente caratteristico del veicolo, in
forma di «w = … imp/km»,
— costante dell’apparecchio di controllo, in
forma di «k = … imp/km»,
— circonferenza effettiva degli pneumatici delle
ruote, in forma di «l = … mm»,
— dimensioni degli pneumatici,
— data in cui sono stati misurati il coefficiente
caratteristico del veicolo e la circonferenza
effettiva degli pneumatici delle ruote,
— numero di identificazione del veicolo,
— presenza (o meno) di un dispositivo GNSS
esterno,
— numero di serie del dispositivo GNSS esterno
(se del caso),
▼M3
— numero di serie dell’eventuale dispositivo di
comunicazione remota,
▼M1
— numero di serie di tutti i sigilli apposti,
— parte del veicolo su cui è montato l’adatta­
tore, se presente,
— parte del veicolo su cui è montato il sensore
di movimento, se non è collegato alla scatola
del cambio o se non viene utilizzato un
adattatore,
— descrizione del colore del cavo che collega
l’adattatore e la parte del veicolo che fornisce
gli impulsi in entrata,
— numero di serie del sensore di movimento
incorporato nell’adattatore.
▼M3
— tipo di carico predefinito associato al veicolo.
▼B
397) Solo per i veicoli M1 e N1 che sono provvisti di
adattatore conformemente al regolamento (CE)
n. 68/2009 della Commissione ( 1 ), come modifi­
cato da ultimo, e qualora non sia possibile indi­
care tutte le informazioni necessarie, come indi­
cato nel requisito 396, può essere utilizzata una
seconda targhetta aggiuntiva. In questi casi la
targhetta aggiuntiva deve recare le informazioni
di cui ai quattro ultimi trattini del requisito 396.
▼M1
( 1 ) Regolamento (CE) n. 68/2009 della Commissione, del 23 gennaio 2009, che adegua per
la nona volta al progresso tecnico il regolamento (CEE) n. 3821/85 del Consiglio relativo
all'apparecchio di controllo nel settore dei trasporti su strada (GU L 21 del 24.1.2009,
pag. 3).
02016R0799 — IT — 21.08.2023 — 003.002 — 101
La targhetta aggiuntiva, se utilizzata, deve essere
apposta a fianco o vicino alla targhetta principale,
di cui al requisito 396, e deve avere lo stesso
livello di protezione. La seconda targhetta, inol­
tre, deve recare il nome, l'indirizzo o la denomi­
nazione commerciale dell'installatore o dell'offi­
cina autorizzati che hanno effettuato il montag­
gio, nonché la data di quest'ultimo.
5.3 Sigilli
398) Le seguenti parti devono essere sigillate:
— qualsiasi connessione che, se scollegata, cau­
serebbe modifiche o perdite di dati non rile­
vabili (ciò può ad esempio valere per il sen­
sore di movimento montato sul cambio, per
l'adattatore per i veicoli delle categorie
M1/N1, per il dispositivo GNSS esterno o
per l'unità elettronica di bordo),
— la targhetta di montaggio, a meno che non sia
affissa in modo da non poter essere rimossa
senza distruggere le iscrizioni poste sulla
stessa.
▼M1
398a) I sigilli summenzionati devono essere certificati
conformemente alla norma EN 16882:2016.
▼B
399) I sigilli summenzionati possono essere tolti:
— in caso d'emergenza,
— per installare, regolare o riparare un limitatore
di velocità o qualsiasi altro dispositivo inteso
a migliorare la sicurezza stradale, a condi­
zione che l'apparecchio di controllo continui
a funzionare in modo affidabile e corretto e
sia risigillato da un installatore o da un'offi­
cina autorizzati (conformemente alla
sezione 6) immediatamente dopo l'installa­
zione del limitatore di velocità o di un altro
dispositivo inteso a migliorare la sicurezza
stradale, oppure entro sette giorni negli altri
casi.
400) L'eventuale rimozione di questi sigilli deve essere
l'oggetto di una giustificazione scritta, tenuta a
disposizione dell'autorità competente.
401) I sigilli devono avere un numero di identifica­
zione assegnato dal fabbricante. Tale numero
deve essere unico e diverso da qualsiasi altro
numero di sigillo assegnato da altri fabbricanti
di sigilli.
▼M1
Questo numero di identificazione unico è così
composto: MMNNNNNNNN, con iscrizione
non rimovibile, dove MM è l’identificazione
unica del fabbricante (registrazione nella banca
dati gestita dalla CE) e NNNNNNNN il valore
alfanumerico del sigillo, unico nel settore del
fabbricante.
▼B
402) I sigilli devono avere uno spazio libero in cui gli
installatori, le officine o i costruttori di veicoli
autorizzati possono aggiungere un marchio spe­
ciale in conformità all'articolo 22, paragrafo 3,
del regolamento (UE) n. 165/2014.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 102
Tale marchio non deve coprire il numero di iden­
tificazione del sigillo.
▼M1
403) I fabbricanti di sigilli, i cui modelli di sigillo
sono certificati secondo la norma EN
16882:2016, devono essere registrati in una
banca dati dedicata e devono rendere pubblici i
loro numeri di identificazione dei sigilli attra­
verso una procedura che sarà stabilita dalla Com­
missione europea.
404) Nel quadro del regolamento (UE) n. 165/2014, le
officine e i costruttori di veicoli autorizzati de­
vono usare esclusivamente sigilli certificati se­
condo la norma EN 16882:2016 provenienti dai
fabbricanti di sigilli elencati nella suddetta banca
dati.
▼B
405) I fabbricanti di sigilli e i loro distributori devono
conservare i documenti attestanti la completa
tracciabilità dei sigilli venduti, da utilizzare nel
quadro del regolamento (UE) n. 165/2014, e pre­
sentarli alle autorità nazionali competenti ogni­
qualvolta necessario.
406) I numeri di identificazione unici dei sigilli de­
vono essere visibili sulla targhetta di montaggio.
6 VERIFICHE, CONTROLLI E RIPARAZIONI
I requisiti relativi alle circostanze in cui si possono togliere i sigilli,
secondo quanto indicato all'articolo 22, paragrafo 5, del regola­
mento (UE) n. 165/2014, sono definiti al punto 5.3 del presente
allegato.
6.1 Autorizzazione di installatori, officine e costruttori di veicoli
Gli Stati membri autorizzano, sottopongono a verifiche regolari e
certificano gli organismi incaricati di effettuare:
— il montaggio,
— le verifiche,
— i controlli,
— le riparazioni.
Le carte dell'officina devono essere rilasciate esclusivamente agli
installatori e/o alle officine autorizzati ad effettuare l'attivazione
e/o la taratura dell'apparecchio di controllo in conformità al presente
allegato e che, tranne in casi debitamente motivati:
— non possiedono i requisiti necessari per ottenere una carta del­
l'azienda,
— e le cui altre attività professionali non costituiscono un rischio
potenziale per la sicurezza generale del sistema, secondo quanto
previsto all'appendice 10.
▼M1
6.2 Verifica dei componenti nuovi o riparati
407) Di ogni singolo dispositivo, nuovo o riparato,
vanno verificati il corretto funzionamento e l’esat­
tezza delle letture e delle registrazioni, nei limiti
fissati ai punti 3.2.1, 3.2.2, 3.2.3 e 3.3.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 103
6.3 Controllo in sede di montaggio
▼M1
408) All’atto del montaggio sul veicolo, l’installazione
nel suo complesso (compreso l’apparecchio di
controllo) deve essere conforme alle disposizioni
relative alle tolleranze massime di cui ai punti
3.2.1, 3.2.2, 3.2.3 e 3.3. L’installazione nel suo
complesso deve essere sigillata conformemente al
capitolo 5.3 e tarata.
▼B
6.4 Controlli periodici
▼M3
409) I controlli periodici degli apparecchi montati nei
veicoli devono avere luogo dopo ogni riparazione
degli apparecchi stessi, oppure dopo ogni modifica
del coefficiente caratteristico del veicolo o della
circonferenza effettiva degli pneumatici, oppure
dopo che l’ora UTC degli apparecchi è errata per
oltre 5 minuti, oppure dopo la modifica del VRN,
e almeno una volta entro due anni (24 mesi) a
partire dall’ultimo controllo.
▼B
410) Si devono controllare:
— lo stato di buon funzionamento dell'apparec­
chio di controllo, compresa la funzione di me­
morizzazione di dati nelle carte tachigrafiche e
la comunicazione con i lettori di comunica­
zione remota,
— la conformità alle disposizioni dei punti 3.2.1 e
3.2.2 relative alle tolleranze massime in sede
di montaggio,
— la conformità alle disposizioni dei punti 3.2.3 e
3.3,
— la presenza del marchio di omologazione sul­
l'apparecchio di controllo,
— che siano apposte la targhetta di montaggio,
quale definita al requisito 396, e la targhetta
segnaletica, quale definita al requisito 225,
— le dimensioni degli pneumatici e la circonfe­
renza effettiva degli pneumatici,
— che l'apparecchio non sia collegato ad alcun
dispositivo di manipolazione,
— che i sigilli siano correttamente collocati, in
buone condizioni, e che i loro numeri di iden­
tificazione siano validi (fabbricante dei sigilli
presente nella banca dati della CE) e corri­
spondano alle iscrizioni sulla targhetta di mon­
taggio (cfr. requisito 401).
▼M3
— che l’identificativo della versione della mappa
digitale memorizzata sia quello più recente.
410 bis) Nel caso le autorità nazionali competenti rilevino
una manipolazione, il veicolo può essere inviato a
un’officina autorizzata affinché l’apparecchio di
controllo possa essere nuovamente tarato.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 104
411) Se dopo l'ultimo controllo viene constatata una
delle anomalie elencate al punto 3.9 (Rilevamento
di anomalie e/o guasti) e qualora i fabbricanti del
tachigrafo e/o le autorità nazionali ritengano che
essa possa comportare rischi per la sicurezza del­
l'apparecchio, l'officina:
a. raffronta i dati di identificazione del sensore di
movimento collegato alla scatola del cambio
con quelli del sensore di movimento registrati
nell'unità elettronica di bordo ad esso
accoppiata;
b. verifica se le informazioni riportate sulla tar­
ghetta di montaggio corrispondono a quelle
contenute nell'unità elettronica di bordo;
c. verifica se il numero di serie e il numero di
omologazione del sensore di movimento, se
stampati sul corpo del sensore stesso, corri­
spondono alle informazioni memorizzate nella
memoria di dati dell'apparecchio di controllo;
d. confronta gli eventuali dati di identificazione
apposti sulla targhetta segnaletica del disposi­
tivo GNSS esterno con quelli memorizzati nella
memoria di dati dell'unità elettronica di bordo.
412) Nelle relazioni di controllo, le officine devono
indicare gli eventuali casi di rimozione dei sigilli
o di intervento di dispositivi di manipolazione. Le
officine devono conservare tali relazioni per al­
meno 2 anni e metterle a disposizione delle auto­
rità competenti ogniqualvolta queste ultime ne fac­
ciano richiesta.
413) Tali controlli devono prevedere una taratura e una
sostituzione preventiva dei sigilli la cui apposi­
zione è responsabilità delle officine..
6.5 Determinazione degli errori
414) La determinazione degli errori all'atto del montag­
gio e durante l'uso va effettuata nelle seguenti
condizioni, che devono essere considerate normali
condizioni di prova:
— veicolo a vuoto, in normali condizioni di
marcia,
— pressione degli pneumatici conforme alle indi­
cazioni fornite dal produttore,
— usura degli pneumatici nei limiti ammessi dalla
normativa nazionale in vigore,
— movimento del veicolo:
— il veicolo deve spostarsi, mosso dal proprio
motore, in linea retta, su terreno piano, ad
una velocità di 50 ± 5 km/h. La misurazione
deve essere effettuata su una distanza di al­
meno 1 000 m.
— A condizione che sia garantita una precisione
analoga, la prova può essere effettuata con altri
metodi, per esempio su un banco di prova.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 105
6.6 Riparazioni
415) Le officine devono essere in grado di trasferire i
dati dall'apparecchio di controllo al fine di fornirli
alle imprese di trasporti interessate.
416) Qualora il cattivo funzionamento dell'apparecchio
di controllo impedisca il trasferimento dei dati re­
gistrati in precedenza, anche dopo la riparazione
da parte di tali officine autorizzate, queste ultime
devono rilasciare alle imprese di trasporti un cer­
tificato che attesti l'impossibilità di trasferire i dati.
Le officine devono conservare una copia di ogni
certificato rilasciato per almeno due anni.
7 RILASCIO DELLA CARTA
Le procedure di rilascio della carta definite dagli Stati membri de­
vono conformarsi ai requisiti seguenti.
417) Al primo rilascio di una carta tachigrafica ad un
richiedente, il numero della carta deve contenere
un codice di serie (se applicabile), un codice di
sostituzione e un codice di rinnovo impostati sullo
«0».
418) Il numero della carta di tutte le carte tachigrafiche
non personali rilasciate ad un medesimo organi­
smo di controllo, una medesima officina o una
medesima impresa di trasporti, deve avere gli
stessi primi 13 caratteri ed un diverso codice di
serie.
419) Una carta tachigrafica rilasciata in sostituzione di una
carta tachigrafica esistente deve avere lo stesso nu­
mero della carta sostituita, eccetto per il codice di
sostituzione che deve essere aumentato di un'unità
(nell'ordine 0, …, 9, A, …, Z).
420) Una carta tachigrafica rilasciata in sostituzione di
una carta tachigrafica esistente deve avere la stessa
data di scadenza della carta sostituita.
421) Una carta tachigrafica rilasciata in rinnovo di una
carta tachigrafica esistente deve avere lo stesso nu­
mero della carta rinnovata, eccetto per il codice di
sostituzione che deve essere riportato a «0» e il co­
dice di rinnovo che deve essere aumentato di un'unità
(nell'ordine 0, …, 9, A, …, Z).
422) In caso di cambio di una carta tachigrafica esi­
stente al fine di modificarne i dati amministrativi,
si devono applicare le regole relative al rinnovo,
se il cambio è effettuato all'interno dello stesso
Stato membro, oppure le regole relative al primo
rilascio, se il cambio è effettuato da un altro Stato
membro.
423) Per le carte dell'officina o le carte di controllo non
personali, nel campo «Cognome del titolare della
carta» si deve inserire la denominazione dell'offi­
cina o dell'organismo di controllo o il nome del­
l'installatore o dell'agente di controllo, a discre­
zione degli Stati membri.
424) Gli Stati membri devono scambiarsi i dati in forma
elettronica per assicurare l'univocità delle carte del
conducente da essi emesse conformemente all'arti­
colo 31 del regolamento (UE) n. 165/2014.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 106
8 OMOLOGAZIONE DELL'APPARECCHIO DI CONTROLLO E
DELLE CARTE TACHIGRAFICHE
8.1 Prescrizioni generali
▼M1
Agli effetti della presente sezione, con «apparecchio di controllo» si
intendono l’«apparecchio di controllo o i suoi componenti». Non è
richiesta l’omologazione del cavo o dei cavi di collegamento tra il
sensore di movimento e la VU, il dispositivo GNSS esterno e la VU
o il dispositivo esterno di comunicazione remota e la VU. I fogli di
carta impiegati dall’apparecchio di controllo devono considerarsi
come un componente dell’apparecchio stesso.
Ciascun fabbricante può chiedere l’omologazione di uno o più com­
ponenti dell’apparecchio di controllo con qualsiasi altro componente
(o componenti) dell’apparecchio di controllo, purché ciascun com­
ponente sia conforme ai requisiti del presente allegato. In alterna­
tiva, i fabbricanti possono anche chiedere l’omologazione dell’ap­
parecchio di controllo.
Come indicato nella definizione 10), all’articolo 2 del presente re­
golamento, le unità elettroniche di bordo possono essere costituite
da componenti assemblati in varianti diverse. A prescindere dalla
variante di assemblaggio dei componenti, l’antenna esterna e (se del
caso) il divisore dell’antenna connesso al ricevitore GNSS o al
dispositivo di comunicazione remota non fanno parte dell’omologa­
zione dell’unità elettronica di bordo.
Ciononostante, i fabbricanti che hanno ottenuto l’omologazione di
un apparecchio di controllo devono tenere un elenco pubblicamente
accessibile delle antenne e dei divisori compatibili con ciascun tipo
di unità elettronica di bordo, di dispositivo GNSS esterno e di
dispositivo esterno di comunicazione remota omologato.
▼B
425) L'apparecchio di controllo deve essere presentato
per l'omologazione munito di tutti i dispositivi
integrati supplementari.
426) L'omologazione dell'apparecchio di controllo e
delle carte tachigrafiche deve comprendere prove
riguardanti la sicurezza, prove funzionali e prove
di interoperabilità. I risultati positivi di ciascuna di
queste prove sono riportati su un apposito
certificato.
▼M1
427) Le autorità di omologazione degli Stati membri
non rilasciano la scheda di omologazione finché
non siano stati loro presentati:
— un certificato di sicurezza (se richiesto a norma
del presente allegato),
— un certificato funzionale,
— un certificato di interoperabilità (se richiesto a
norma del presente allegato),
per l’apparecchio di controllo o la carta tachigra­
fica oggetto della domanda di omologazione.
▼B
428) Eventuali modifiche del software o dell'hardware
dell'apparecchio o della natura dei materiali usati
per la fabbricazione devono essere notificate prima
dell'impiego all'autorità che ha omologato l'appa­
recchio. Tale autorità conferma al fabbricante
l'estensione dell'omologazione oppure richiede un
aggiornamento o una conferma del certificato fun­
zionale, del certificato di sicurezza e/o del certifi­
cato di interoperabilità pertinenti.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 107
429) Le procedure volte ad aggiornare in situ il soft­
ware dell’apparecchio di controllo devono essere
approvate dall’autorità che ha rilasciato l’omolo­
gazione dell’apparecchio di controllo. L’aggiorna­
mento software non deve modificare né cancellare
i dati relativi all’attività del conducente memoriz­
zati nell’apparecchio di controllo. Il software può
essere aggiornato solo sotto la responsabilità del
fabbricante dell’apparecchio.
430) L’omologazione delle modifiche software finaliz­
zate ad aggiornare un apparecchio di controllo
precedentemente omologato non può essere negata
qualora tali modifiche si applichino solo a funzioni
non specificate nel presente allegato. L’aggiorna­
mento software di un apparecchio di controllo può
escludere l’introduzione di nuovi insiemi di carat­
teri, qualora essa non sia tecnicamente fattibile.
▼B
8.2 Certificato di sicurezza
431) Il certificato di sicurezza è rilasciato in conformità
alle disposizioni dell'appendice 10 del presente al­
legato. I componenti dell'apparecchio di controllo
da certificare sono: unità elettronica di bordo, sen­
sore di movimento, dispositivo GNSS esterno e
carte tachigrafiche.
432) Nei casi eccezionali in cui le autorità nazionali di
certificazione della sicurezza rifiutino di certificare
apparecchiature nuove a causa del carattere supe­
rato dei meccanismi di sicurezza, l'omologazione
continua a essere rilasciata solo in queste circo­
stanze specifiche ed eccezionali e qualora non esi­
stano soluzioni alternative in conformità al pre­
sente regolamento.
433) In questi casi gli Stati membri interessati devono
informare sollecitamente la Commissione europea
che, entro 12 mesi civili dal rilascio dell'omologa­
zione, avvia una procedura per accertare che la
sicurezza sia stata ripristinata ai livelli originali.
8.3 Certificato funzionale
434) Ogni richiedente un'omologazione deve presentare
all'autorità di omologazione dello Stato membro
tutto il materiale e la documentazione ritenuti ne­
cessari da tale autorità.
435) I fabbricanti devono fornire i campioni pertinenti
dei prodotti da omologare e la relativa documen­
tazione ai laboratori incaricati di eseguire le prove
funzionali entro un mese dalla presentazione di
una richiesta in tal senso. Gli eventuali costi
sono a carico dei soggetti che hanno presentato
la richiesta. I laboratori sono tenuti a trattare con
riservatezza le informazioni sensibili sotto il pro­
filo commerciale.
436) Il certificato funzionale deve essere rilasciato al
fabbricante solo se almeno tutte le prove funzio­
nali specificate nell'appendice 9 hanno dato risul­
tati positivi.
437) L'autorità di omologazione rilascia un certificato
funzionale. Tale certificato deve recare, oltre al
nome del beneficiario e all'identificazione del mo­
dello, un elenco dettagliato delle prove effettuate e
dei risultati ottenuti.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 108
438) Il certificato funzionale dei componenti dell'appa­
recchio di controllo deve indicare inoltre i numeri
di omologazione degli altri componenti dell'appa­
recchio di controllo compatibili omologati sottopo­
sti a prova per ottenere la certificazione dell'appa­
recchio di controllo.
439) Il certificato funzionale dei componenti dell'appa­
recchio di controllo deve anche indicare la norma
ISO o CEN in conformità alla quale è stata certi­
ficata l'interfaccia funzionale.
8.4 Certificato di interoperabilità
440) Le prove di interoperabilità sono effettuate da un
unico laboratorio sotto l'autorità e la responsabilità
della Commissione europea.
441) Il laboratorio registra le richieste di prove di inte­
roperabilità presentate dai fabbricanti nell'ordine
cronologico di presentazione.
442) Le richieste sono registrate ufficialmente solo
quando il laboratorio dispone:
— dell'intera serie di materiali e documenti neces­
sari per le prove di interoperabilità,
— del corrispondente certificato di sicurezza,
— del corrispondente certificato funzionale.
La data di registrazione della richiesta viene noti­
ficata al fabbricante.
▼M3
443) Fatte salve le circostanze eccezionali di cui al re­
quisito 432, i laboratori non devono effettuare
prove di interoperabilità sugli apparecchi di con­
trollo o sulle carte tachigrafiche che non hanno
superato l’analisi di vulnerabilità della loro valu­
tazione della sicurezza e una valutazione
funzionale.
▼B
444) I fabbricanti che richiedono le prove di interope­
rabilità si impegnano a lasciare a disposizione del
laboratorio incaricato di tali prove l'intera serie di
materiali e documenti forniti per l'esecuzione delle
prove stesse.
445) Le prove di interoperabilità sono effettuate, in con­
formità alle disposizioni dell'appendice 9 del pre­
sente allegato, con tutti i tipi di apparecchi di con­
trollo e di carte tachigrafiche:
— la cui omologazione è in corso di validità o
— che sono in attesa di omologazione e hanno
ottenuto un certificato di interoperabilità
valido.
446) Le prove di interoperabilità devono riguardare
tutte le generazioni di apparecchi di controllo o
di carte tachigrafiche ancora in uso.
▼M3
447) Il certificato di interoperabilità deve essere rila­
sciato dal laboratorio al fabbricante solo dopo
che tutte le prove di interoperabilità prescritte
sono state superate con esito positivo e dopo che
il fabbricante ha dimostrato che sono stati rilasciati
sia un certificato funzionale valido sia un certifi­
cato di sicurezza valido per il prodotto, fatte salve
le circostanze eccezionali di cui al requisito 432.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 109
448) Se le prove di interoperabilità non danno risultati
positivi con uno o più apparecchi di controllo o
carte tachigrafiche, il certificato di interoperabilità
non viene rilasciato al fabbricante finché non sono
state apportate le modifiche necessarie a superare
tutte le prove di interoperabilità. Il laboratorio
identifica la causa del problema con l'aiuto dei
fabbricanti interessati da tale mancanza di intero­
perabilità ed aiuta il richiedente a trovare una so­
luzione tecnica. Nel caso in cui il fabbricante mo­
difichi il prodotto, spetterà al fabbricante stesso
accertare presso le autorità competenti che il cer­
tificato di sicurezza e il certificato funzionale siano
ancora validi.
449) Il certificato di interoperabilità ha una validità di
sei mesi e viene revocato se, al termine di tale
periodo, il fabbricante non ha ottenuto la corri­
spondente scheda di omologazione. Il certificato
di interoperabilità viene trasmesso dal fabbricante
all'autorità di omologazione dello Stato membro
che ha rilasciato il certificato funzionale.
450) Qualsiasi elemento cui si possa ricondurre la man­
canza di interoperabilità non deve essere usato a
fini di lucro o per accedere ad una posizione
dominante.
8.5 Scheda di omologazione
451) L'autorità di omologazione di uno Stato membro
può rilasciare la scheda di omologazione non ap­
pena è in possesso dei tre certificati richiesti.
452) La scheda di omologazione dei componenti del­
l'apparecchio di controllo deve anche indicare i
numeri di omologazione degli altri componenti in­
teroperabili omologati dell'apparecchio di
controllo.
453) L'autorità di omologazione deve trasmettere una
copia della scheda di omologazione al laboratorio
incaricato delle prove di interoperabilità all'atto del
rilascio della stessa al fabbricante.
454) Il laboratorio competente per le prove di interope­
rabilità deve gestire un sito web pubblico nel
quale mantiene aggiornato l'elenco dei modelli di
apparecchio di controllo o carta tachigrafica:
— per i quali è stata registrata una richiesta di
prove di interoperabilità,
— che abbiano ottenuto un certificato di interope­
rabilità (anche provvisorio),
— che abbiano ottenuto una scheda di
omologazione.
8.6 Procedura eccezionale: primi certificati di interoperabilità per
gli apparecchi di controllo e le carte tachigrafiche di 2 a genera­
zione
455) Per un periodo di quattro mesi successivi al rila­
scio del certificato di interoperabilità della prima
coppia apparecchio di controllo di 2 a generazione/
carte tachigrafiche di 2 a generazione (carte del
conducente, dell'officina, di controllo e del­
l'azienda), ogni certificato di interoperabilità rila­
sciato (compresi i primi in assoluto), concernente
le richieste presentate durante tale periodo, deve
essere considerato provvisorio.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 110
456) Se al termine di tale periodo tutti i prodotti inte­
ressati sono reciprocamente interoperabili, i rispet­
tivi certificati di interoperabilità diventano
definitivi.
457) Se durante tale periodo si riscontrano mancanze di
interoperabilità, il laboratorio incaricato delle
prove di interoperabilità identifica le cause dei
problemi con l'aiuto di tutti i fabbricanti interessati
e li invita ad apportare le modifiche necessarie.
458) Se al termine di tale periodo sussistono ancora
problemi di interoperabilità, il laboratorio incari­
cato delle prove di interoperabilità, con la collabo­
razione dei fabbricanti interessati e delle autorità
di omologazione che hanno rilasciato i corrispon­
denti certificati funzionali, ricerca le cause della
mancanza di interoperabilità e stabilisce le modifi­
che che ogni fabbricante deve apportare. La ri­
cerca di soluzioni tecniche deve avvenire entro
un periodo massimo di due mesi, in seguito al
quale, qualora non si trovi una soluzione comune,
la Commissione, dopo aver consultato il laborato­
rio incaricato delle prove di interoperabilità, de­
cide quali apparecchi e quali carte ottengono un
certificato definitivo di interoperabilità e ne indica
i motivi.
459) Tutte le richieste di prove di interoperabilità, regi­
strate dal laboratorio tra il termine del periodo di
quattro mesi successivi al rilascio del primo certi­
ficato provvisorio di interoperabilità e la data della
decisione della Commissione di cui al requisito
455, sono rinviate fino alla soluzione dei problemi
iniziali di interoperabilità. Tali richieste sono
quindi evase in ordine cronologico in base alla
data di registrazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 111
Appendice 1
DIZIONARIO DEI DATI
INDICE
1. INTRODUZIONE
1.1. Metodo di definizione dei tipi di dati
1.2. Riferimenti
2. DEFINIZIONI DEI TIPI DI DATI
2.1. ActivityChangeInfo
2.2. Address
2.3. AESKey
2.4. AES128Key
2.5. AES192Key
2.6. AES256Key
2.7. BCDString
2.8. CalibrationPurpose
2.9. CardActivityDailyRecord
2.10. CardActivityLengthRange
2.11. CardApprovalNumber
▼M3
2.11a. CardBorderCrossing
2.11b. CardBorderCrossingRecord
▼B
2.12. CardCertificate
2.13. CardChipIdentification
2.14. CardConsecutiveIndex
2.15. CardControlActivityDataRecord
2.16. CardCurrentUse
2.17. CardDriverActivity
2.18. CardDrivingLicenceInformation
2.19. CardEventData
2.20. CardEventRecord
2.21. CardFaultData
2.22. CardFaultRecord
2.23. CardIccIdentification
2.24. CardIdentification
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 112
2.24a. CardLoadTypeEntries
2.24b. CardLoadTypeEntryRecord
2.24c. CardLoadUnloadOperations
2.24d. CardLoadUnloadRecord
▼B
2.25. CardMACertificate
2.26. CardNumber
▼M3
2.26a. CardPlaceAuthDailyWorkPeriod
▼B
2.27. CardPlaceDailyWorkPeriod
2.28. CardPrivateKey
2.29. CardPublicKey
2.30. CardRenewalIndex
2.31. CardReplacementIndex
2.32. CardSignCertificate
2.33. CardSlotNumber
2.34. CardSlotsStatus
2.35. CardSlotsStatusRecordArray
2.36. CardStructureVersion
2.37. CardVehicleRecord
2.38. CardVehiclesUsed
2.39. CardVehicleUnitRecord
2.40. CardVehicleUnitsUsed
2.41. Certificate
2.42. CertificateContent
2.43. CertificateHolderAuthorisation
2.44. CertificateRequestID
2.45. CertificationAuthorityKID
2.46. CompanyActivityData
2.47. CompanyActivityType
2.48. CompanyCardApplicationIdentification
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 113
2.48a. CompanyCardApplicationIdentificationV2
▼B
2.49. CompanyCardHolderIdentification
2.50. ControlCardApplicationIdentification
▼M3
2.50a. ControlCardApplicationIdentificationV2
▼B
2.51. ControlCardControlActivityData
2.52. ControlCardHolderIdentification
2.53. ControlType
2.54. CurrentDateTime
2.55. CurrentDateTimeRecordArray
2.56. DailyPresenceCounter
2.57. Datef
2.58. DateOfDayDownloaded
2.59. DateOfDayDownloadedRecordArray
2.60. Distance
▼M3
2.60a. DownloadInterfaceVersion
▼B
2.61. DriverCardApplicationIdentification
▼M3
2.61a. DriverCardApplicationIdentificationV2
▼B
2.62. DriverCardHolderIdentification
▼M1
2.63. Riservato per uso futuro
▼B
2.64. EGFCertificate
2.65. EmbedderIcAssemblerId
2.66. EntryTypeDailyWorkPeriod
2.67. EquipmentType
2.68. EuropeanPublicKey
2.69. EventFaultRecordPurpose
2.70. EventFaultType
2.71. ExtendedSealIdentifier
2.72. ExtendedSerialNumber
2.73. FullCardNumber
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 114
2.74. FullCardNumberAndGeneration
2.75. Generation
2.76. GeoCoordinates
2.77. GNSSAccuracy
▼M1
2.78. GNSSAccumulatedDriving
2.79. GNSSAccumulatedDrivingRecord
▼M3
2.79a. GNSSAuthAccumulatedDriving
2.79b. GNSSAuthStatusADRecord
2.79c. GNSSPlaceAuthRecord
▼B
2.80. GNSSPlaceRecord
2.81. HighResOdometer
2.82. HighResTripDistance
2.83. HolderName
▼M3
2.84. Riservato per uso futuro
▼B
2.85. K-ConstantOfRecordingEquipment
2.86. KeyIdentifier
2.87. KMWCKey
2.88. Language
2.89. LastCardDownload
▼M3
2.89a. LengthOfFollowingData
▼B
2.90. LinkCertificate
▼M3
2.90a. LoadType
▼B
2.91. L-TyreCircumference
2.92. MAC
2.93. ManualInputFlag
2.94. ManufacturerCode
2.95. ManufacturerSpecificEventFaultData
2.96. MemberStateCertificate
2.97. MemberStateCertificateRecordArray
2.98. MemberStatePublicKey
2.99. Name
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 115
2.100. NationAlpha
2.101. NationNumeric
▼M3
2.101a. NoOfBorderCrossingRecords
▼B
2.102. NoOfCalibrationRecords
2.103. NoOfCalibrationsSinceDownload
2.104. NoOfCardPlaceRecords
2.105. NoOfCardVehicleRecords
2.106. NoOfCardVehicleUnitRecords
2.107. NoOfCompanyActivityRecords
2.108. NoOfControlActivityRecords
2.109. NoOfEventsPerType
2.110. NoOfFaultsPerType
▼M1
2.111. NoOfGNSSADRecords
▼M3
2.111a. NoOfLoadUnloadRecords
▼B
2.112. NoOfSpecificConditionRecords
▼M3
2.112a. NoOfLoadTypeEntryRecords
▼B
2.113. OdometerShort
2.114. OdometerValueMidnight
▼M3
2.114a. OperationType
▼B
2.115. OdometerValueMidnightRecordArray
2.116. OverspeedNumber
▼M3
2.116a. PlaceAuthRecord
2.116b. PlaceAuthStatusRecord
▼B
2.117. PlaceRecord
▼M3
2.117a. PositionAuthenticationStatus
▼B
2.118. PreviousVehicleInfo
2.119. PublicKey
2.120. RecordType
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 116
2.121. RegionAlpha
2.122. RegionNumeric
2.123. RemoteCommunicationModuleSerialNumber
2.124. RSAKeyModulus
2.125. RSAKeyPrivateExponent
2.126. RSAKeyPublicExponent
2.127. RtmData
2.128. SealDataCard
2.129. SealDataVu
2.130. SealRecord
2.131. SensorApprovalNumber
2.132. SensorExternalGNSSApprovalNumber
2.133. SensorExternalGNSSCoupledRecord
2.134. SensorExternalGNSSIdentification
2.135. SensorExternalGNSSInstallation
2.136. SensorExternalGNSSOSIdentifier
2.137. SensorExternalGNSSSCIdentifier
2.138. SensorGNSSCouplingDate
2.139. SensorGNSSSerialNumber
2.140. SensorIdentification
2.141. SensorInstallation
2.142. SensorInstallationSecData
2.143. SensorOSIdentifier
2.144. SensorPaired
2.145. SensorPairedRecord
2.146. SensorPairingDate
2.147. SensorSCIdentifier
2.148. SensorSerialNumber
2.149. Signature
2.150. SignatureRecordArray
2.151. SimilarEventsNumber
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 117
2.152. SpecificConditionRecord
2.153. SpecificConditions
2.154. SpecificConditionType
2.155. Velocità
2.156. SpeedAuthorised
2.157. SpeedAverage
2.158. SpeedMax
▼M3
2.158a. TachographCardsGen1Suppression
▼B
2.159. TachographPayload
▼M1
2.160. Riservato per uso futuro
▼B
2.161. TDesSessionKey
2.162. TimeReal
2.163. TyreSize
2.164. VehicleIdentificationNumber
2.165. VehicleIdentificationNumberRecordArray
2.166. VehicleRegistrationIdentification
▼M3
2.166a. VehicleRegistrationIdentificationRecordArray
▼B
2.167. VehicleRegistrationNumber
2.168. VehicleRegistrationNumberRecordArray
2.169. VuAbility
2.170. VuActivityDailyData
2.171. VuActivityDailyRecordArray
2.172. VuApprovalNumber
2.173. VuCalibrationData
2.174. VuCalibrationRecord
2.175. VuCalibrationRecordArray
2.176. VuCardIWData
2.177. VuCardIWRecord
2.178. VuCardIWRecordArray
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 118
2.179. VuCardRecord
2.180. VuCardRecordArray
2.181. VuCertificate
2.182. VuCertificateRecordArray
2.183. VuCompanyLocksData
2.184. VuCompanyLocksRecord
2.185. VuCompanyLocksRecordArray
▼M3
2.185a. VuConfigurationLengthRange
▼B
2.186. VuControlActivityData
2.187. VuControlActivityRecord
2.188. VuControlActivityRecordArray
2.189. VuDataBlockCounter
2.190. VuDetailedSpeedBlock
2.191. VuDetailedSpeedBlockRecordArray
2.192. VuDetailedSpeedData
▼M3
2.192a. VuDigitalMapVersion
▼B
2.193. VuDownloadablePeriod
2.194. VuDownloadablePeriodRecordArray
2.195. VuDownloadActivityData
2.196. VuDownloadActivityDataRecordArray
2.197. VuEventData
2.198. VuEventRecord
2.199. VuEventRecordArray
2.200. VuFaultData
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 119
2.201. VuFaultRecord
2.202. VuFaultRecordArray
▼M1
2.203. VuGNSSADRecord
▼M3
2.203a. VuBorderCrossingRecord
2.203b. VuBorderCrossingRecordArray
▼M1
2.204. VuGNSSADRecordArray
▼M3
2.204a. VuGnssMaximalTimeDifference
▼B
2.205. VuIdentification
2.206. VuIdentificationRecordArray
2.207. VuITSConsentRecord
2.208. VuITSConsentRecordArray
▼M3
2.208a. VuLoadUnloadRecord
2.208b. VuLoadUnloadRecordArray
▼B
2.209. VuManufacturerAddress
2.210. VuManufacturerName
2.211. VuManufacturingDate
2.212. VuOverSpeedingControlData
2.213. VuOverSpeedingControlDataRecordArray
2.214. VuOverSpeedingEventData
2.215. VuOverSpeedingEventRecord
2.216. VuOverSpeedingEventRecordArray
2.217. VuPartNumber
2.218. VuPlaceDailyWorkPeriodData
2.219. VuPlaceDailyWorkPeriodRecord
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 120
2.220. VuPlaceDailyWorkPeriodRecordArray
2.221. VuPrivateKey
2.222. VuPublicKey
▼M3
2.222a. VuRtcTime
▼B
2.223. VuSerialNumber
2.224. VuSoftInstallationDate
2.225. VuSoftwareIdentification
2.226. VuSoftwareVersion
2.227. VuSpecificConditionData
2.228. VuSpecificConditionRecordArray
2.229. VuTimeAdjustmentData
▼M1
2.230. Riservato per uso futuro
2.231. Riservato per uso futuro
▼B
2.232. VuTimeAdjustmentRecord
2.233. VuTimeAdjustmentRecordArray
2.234. WorkshopCardApplicationIdentification
▼M3
2.234a. WorkshopCardApplicationIdentificationV2
2.234b. WorkshopCardCalibrationAddData
2.234c. WorkshopCardCalibrationAddDataRecord
▼B
2.235. WorkshopCardCalibrationData
2.236. WorkshopCardCalibrationRecord
2.237. WorkshopCardHolderIdentification
2.238. WorkshopCardPIN
2.239. W-VehicleCharacteristicConstant
2.240. VuPowerSupplyInterruptionRecord
2.241. VuPowerSupplyInterruptionRecordArray
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 121
2.242. VuSensorExternalGNSSCoupledRecordArray
2.243. VuSensorPairedRecordArray
3. DEFINIZIONI DEI CAMPI DI VALORI E DIMENSIONI
4. SET DI CARATTERI
5. CODIFICA
6. IDENTIFICATIVI DI OGGETTO E IDENTIFICATIVI DI APPLICA­
ZIONE
6.1. Identificativi di oggetto
6.2. Identificativi di applicazione
1. INTRODUZIONE
La presente appendice specifica i formati dei dati, gli elementi di dati e
le strutture dei dati da usare nell'apparecchio di controllo e nelle carte
tachigrafiche.
1.1. Metodo di definizione dei tipi di dati
Nella presente appendice i tipi di dati sono definiti in base al linguaggio
Abstract Syntax Notation One (ASN.1). La notazione ASN.1 permette di
definire dati semplici e strutturati, senza richiedere una specifica sintassi
di trasmissione (regole di codifica), la quale dipende dall'applicazione e
dal contesto.
La notazione convenzionale ASN.1 per l'attribuzione di nomi si basa
sulla norma ISO/IEC 8824-1. Ciò significa che:
— ove possibile, il significato del tipo di dati è implicitamente noto in
funzione del nome attribuito,
— per i tipi di dati composti, costituiti da una combinazione di più tipi
di dati, il nome è comunque un'unica sequenza di caratteri alfabetici
con la lettera iniziale maiuscola, ma vengono usate lettere maiuscole
anche all'interno del nome, che consentono di individuare il signifi­
cato corrispondente,
— in generale, i nomi dei tipi di dati si riferiscono al nome dei tipi di
dati con cui vengono costruiti, all'apparecchio in cui sono memoriz­
zati i dati e alla funzione connessa ai dati.
Se un tipo ASN.1 è già definito nell'ambito di un'altra norma e viene
usato nell'apparecchio di controllo, tale tipo ASN.1 è definito nella
presente appendice.
Per tenere conto di vari tipi di regole di codifica, alcuni tipi ASN.1
compresi nella presente appendice sono limitati da identificativi del
campo di valori. Gli identificativi del campo di valori sono definiti al
paragrafo 3 e nell'appendice 2.
1.2. Riferimenti
Nella presente appendice si rimanda alle seguenti norme:
ISO 639 Codice per la rappresentazione dei nomi delle lingue.
Prima edizione: 1988.
ISO 3166 Codici per la rappresentazione dei nomi dei paesi e
delle loro suddivisioni — Parte 1: Codici paese, 2013
ISO 3779 Veicoli stradali — Numero di identificazione del
veicolo (VIN) — Contenuto e struttura. 2009
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 122
ISO/CEI 7816-5 Carte di identificazione — Carte a circuiti integrati —
Parte 5: Registrazione dei fornitori di applicazioni.
Seconda edizione: 2004.
ISO/CEI 7816-6 Carte di identificazione — Carte a circuiti integrati —
Parte 6: Elementi di dati interindustriali per gli
scambi, 2004 + rettifica tecnica 1: 2006
ISO/CEI 8824-1 Tecnologia dell'informazione — Abstract Syntax No­
tation 1 (ASN.1): Descrizione della notazione di base.
2008 + rettifica tecnica 1: 2012 e rettifica tecnica 2:
2014.
ISO/CEI 8825-2 Tecnologia dell'informazione — Regole di codifica
ASN.1: Descrizione delle regole di codifica a
pacchetto (PER). 2008.
ISO/CEI 8859-1 Tecnologia dell'informazione — Codifica a gruppo
singolo di 8 bit di insiemi di caratteri grafici — Parte
1: Alfabeto latino n. 1. Prima edizione: 1998.
ISO/CEI 8859-7 Tecnologia dell'informazione — Codifica a gruppo
singolo di 8 bit di insiemi di caratteri grafici — Parte
7: Alfabeto latino/greco. 2003.
ISO 16844-3 Veicoli stradali — Sistemi tachigrafici — Interfaccia
del sensore di movimento. 2004 + rettifica tecnica 1:
2006.
TR-03110-3 Orientamenti tecnici TR-03110-3 di BSI/ANSSI,
Meccanismi di sicurezza avanzati per i documenti di
viaggio a lettura ottica e il token eIDAS- Parte 3:
Specifiche comuni, versione 2.20, 3. Febbraio 2015
2. DEFINIZIONI DEI TIPI DI DATI
▼M3
Per ciascuno dei seguenti tipi di dati, il valore predefinito di un conte­
nuto «non noto» o «non applicabile» è dato dal riempimento dell’ele­
mento di dati con il valore esadecimale «FF» byte, salvo indicazione
contraria.
Tutti i tipi di dati sono utilizzati per le applicazioni di prima e seconda
generazione, salvo indicazione contraria. Sono indicati i tipi di dati
utilizzati solo per le applicazioni di seconda generazione, versione 2.
Per i tipi di dati delle carte utilizzati nelle applicazioni di prima e se­
conda generazione, le dimensioni specificate nella presente
appendice sono quelle valide per le applicazioni di seconda generazione.
Si suppone che le dimensioni valide per le applicazioni di prima gene­
razione siano già note al lettore. I riferimenti numerici dei requisiti
dell’allegato IC relativi a tali tipi di dati si riferiscono sia alle applica­
zioni di prima generazione, sia a quelle di seconda generazione.
I tipi di dati delle carte non definiti per le carte di prima generazione non
sono memorizzati nell’applicazione di prima generazione delle carte di
seconda generazione. In particolare:
— i numeri di omologazione memorizzati nell’applicazione di prima
generazione delle carte di seconda generazione sono troncati dopo
i primi 8 caratteri, ove necessario;
— solo l’indicatore di inizio della condizione specifica di «ATTRA­
VERSAMENTO MEDIANTE TRAGHETTO/TRENO» è memoriz­
zato nell’applicazione di prima generazione delle carte di seconda
generazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 123
2.1. ActivityChangeInfo
Questo tipo di dati consente di codificare, in una parola (word) a due
byte, la condizione della sede (slot) alle 00h00 e/o la condizione del
conducente alle 00h00 e/o i cambi di attività e/o le variazioni della
condizione di guida e/o le variazioni della condizione della carta riguar­
danti un conducente o un secondo conducente. Questo tipo di dati si
riferisce ai requisiti 105, 266, 291, 320, 321, 343 e 344 dell'allegato 1C.
Assegnazione valore — Allineato all'ottetto: «scpaattttttttttt»B (16 bit)
Per le registrazioni nella memoria di dati (o condizione della sede):
«s»B Sede (slot):
«0»B: CONDUCENTE,
«1»B: SECONDO CONDUCENTE,
«c»B Condizione di guida:
«0»B: SINGOLA,
«1»B: EQUIPAGGIO,
«p»B Condizione della carta del conducente (o dell'officina)
nella relativa sede (slot):
«0»B: INSERITA, la carta è inserita,
«1»B: NON INSERITA, la carta è assente (o una
carta viene estratta),
«aa»B Attività:
«00»B: INTERRUZIONE/RIPOSO,
«01»B: DISPONIBILITÀ,
«10»B: LAVORO,
«11»B: GUIDA,
«ttttttttttt»B Ora della variazione: numero di minuti a partire dalle
00h00 del giorno in questione.
Per le registrazioni nella carta del conducente (o dell'officina) (e per la
condizione del conducente):
«s»B Sede (slot) (non pertinente se «p» = 1, fatta salva la
nota sotto):
«0»B: CONDUCENTE,
«1»B: SECONDO CONDUCENTE,
«c»B Condizione di guida (quando «p» = 0) o
Condizione attività successiva (quando «p» = 1):
«0»B: SINGOLA,
«0»B: NON NOTA
«1»B: EQUIPAGGIO,
«1»B: NOTA (= immissione manuale)
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 124
«p»B Condizione carta:
«0»B: INSERITA, la carta è inserita in un apparec­
chio di controllo,
«1»B: NON INSERITA, la carta è assente (o la carta
viene estratta),
«aa»B Attività (non pertinente se «p» = 1 e «c» = 0, fatta
salva la nota sotto):
«00»B: INTERRUZIONE/RIPOSO,
«01»B: DISPONIBILITÀ,
«10»B: LAVORO,
«11»B: GUIDA,
«ttttttttttt»B Ora della variazione: numero di minuti a partire dalle
00h00 del giorno in questione.
Nota per il caso di «estrazione carta»:
Quando la carta viene estratta:
— «s» è pertinente ed indica la sede (slot) da cui viene estratta la carta,
— «c» deve essere impostato su 0,
— «p» deve essere impostato su 1,
— «aa» deve codificare l'attività selezionata in corso al momento del­
l'estrazione.
In seguito a un'immissione manuale, i bit «c» e «aa» della parola (word)
(memorizzata in una carta) possono essere sovrascritti in un secondo
tempo per tenere conto dell'immissione.
2.2. Address
Un indirizzo.
codePage specifica una serie di caratteri quali definiti nel capitolo 4,
address è un indirizzo codificato usando la serie specifica di caratteri.
2.3. AESKey
Seconda generazione:
Una chiave AES con una lunghezza di 128, 192 o 256 bit.
Assegnazione valore: nessun'altra specificazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 125
2.4. AES128Key
Seconda generazione:
Una chiave AES128.
length indica la lunghezza della chiave AES128 in ottetti.
aes128key è una chiave AES con una lunghezza di 128 bit.
Assegnazione valore:
la lunghezza deve avere il valore 16.
2.5. AES192Key
Seconda generazione:
Una chiave AES192.
length indica la lunghezza della chiave AES192 in ottetti.
aes192key è una chiave AES con una lunghezza di 192 bit.
Assegnazione valore:
la lunghezza deve avere il valore 24.
2.6. AES256Key
Seconda generazione:
Una chiave AES256.
length indica la lunghezza della chiave AES256 in ottetti.
aes256key è una chiave AES con una lunghezza di 256 bit.
Assegnazione valore:
la lunghezza deve avere il valore 32.
2.7. BCDString
BCDString si usa per la rappresentazione in codice binario
decimale (BCD). Questo tipo di dati è usato per rappresentare una cifra
decimale in un semi-ottetto (4 bit). BCDString si basa su ISO/IEC 8824-
1 «CharacterStringType».
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 126
BCDString utilizza la notazione «hstring». La prima cifra esadecimale a
partire da sinistra è il semi-ottetto più significativo del primo ottetto. Per
ottenere un multiplo di ottetti, si devono inserire semi-ottetti a coda
zero, secondo la necessità, a partire dalla prima posizione a sinistra del
semi-ottetto nel primo ottetto.
Le cifre ammesse sono: 0, 1, .. 9.
2.8. CalibrationPurpose
Codice che spiega il motivo per cui è stata registrata una serie di para­
metri di taratura. Questo tipo di dati si riferisce ai requisiti 097 e 098
dell'allegato 1B e al requisito 119 dell'allegato 1C.
Assegnazione valore:
Prima generazione:
«00»H valore riservato,
«01»H attivazione: registrazione dei parametri di taratura
noti al momento dell'attivazione della VU,
«02»H prima installazione: prima taratura della VU in
seguito all'attivazione,
«03»H installazione: prima taratura della VU nel veicolo
in cui è montata,
«04»H controllo periodico.
Seconda generazione:
Oltre alla prima generazione, sono utilizzati i valori seguenti:
«05»H inserimento del VRN da parte dell'azienda,
«06»H regolazione dell'ora senza taratura,
da «07»H a «7F»H RFU,
da «80»H a «FF»H Specifico del fabbricante.
2.9. CardActivityDailyRecord
Informazioni, memorizzate in una carta, relative all'attività del condu­
cente per un determinato giorno di calendario. Questo tipo di dati si
riferisce ai requisiti 266, 291, 320 e 343 dell'allegato 1C.
activityPreviousRecordLength è la lunghezza totale in byte della regi­
strazione giornaliera precedente. Il valore massimo è dato dalla lun­
ghezza della STRINGA DI OTTETTI contenente tali registrazioni (cfr.
CardActivityLengthRange, appendice 2, paragrafo 4). Se questa registra­
zione è la registrazione giornaliera meno recente, il valore di activity­
PreviousRecordLength dev'essere impostato su 0.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 127
activityRecordLength è la lunghezza totale in byte di questa registra­
zione. Il valore massimo è dato dalla lunghezza della STRINGA DI
OTTETTI contenente tali registrazioni.
activityRecordDate è la data della registrazione.
activityDailyPresenceCounter è il contatore di presenza giornaliera per
la carta nel giorno in questione.
activityDayDistance è la distanza totale percorsa nel giorno in
questione.
activityChangeInfo è la serie di dati ActivityChangeInfo per il condu­
cente nel giorno in questione. Può contenere un massimo di 1440 valori
(un cambio di attività al minuto). La serie comprende sempre il valore
activityChangeInfo relativo alla condizione del conducente alle 00h00.
2.10. CardActivityLengthRange
Numero di byte in una carta del conducente o dell'officina, disponibile
per memorizzare le registrazioni relative all'attività del conducente.
Assegnazione valore: cfr. appendice 2.
2.11. CardApprovalNumber
Numero di omologazione della carta.
Assegnazione valore:
Il numero di omologazione deve corrispondere a quanto pubblicato sul
sito Internet della Commissione europea, vale a dire ad esempio com­
presi gli eventuali trattini. Il numero di omologazione deve essere alli­
neato a sinistra.
▼M3
2.11a. CardBorderCrossings
Seconda generazione, versione 2:
informazioni, memorizzate in una carta del conducente o dell’officina,
relative agli attraversamenti di frontiera del veicolo quando quest’ultimo
ha attraversato la frontiera di un paese (requisiti 306 septies e 356 septies
dell’allegato IC).
borderCrossingPointerNewestRecord è l’indice della registrazione più
aggiornata nella carta dell’attraversamento di frontiera.
Assegnazione valore è il numero corrispondente al numeratore della
registrazione nella carta dell’attraversamento di frontiera, a partire da
«0» per la prima volta in cui tale registrazione compare nella struttura.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 128
cardBorderCrossingRecords è l’insieme delle registrazioni nella carta
degli attraversamenti di frontiera.
2.11b. CardBorderCrossingRecord
Seconda generazione, versione 2:
informazioni, memorizzate in una carta del conducente o dell’officina,
relative agli attraversamenti di frontiera del veicolo quando quest’ultimo
ha attraversato la frontiera di un paese (requisiti 147 ter, 306 sexies
e 356 sexies dell’allegato IC).
countryLeft è il paese lasciato dal veicolo oppure contiene l’indicazione
«nessuna informazione disponibile» conformemente al requisito 147 ter
dell’allegato IC. «Resto del mondo» (codice NationNumeric «FF»H)
deve essere utilizzato quando l’unità elettronica di bordo non è in grado
di determinare il paese in cui si trova il veicolo (ad esempio, il paese in
cui si trova il veicolo in quel momento non è compreso nelle mappe
digitali memorizzate).
countryEntered è il paese in cui il veicolo è entrato o il paese in cui il
veicolo si trova al momento dell’inserimento della carta. «Resto del
mondo» (codice NationNumeric «FF»H) deve essere utilizzato quando
l’unità elettronica di bordo non è in grado di determinare il paese in cui
si trova il veicolo (ad esempio, il paese in cui si trova il veicolo in quel
momento non è compreso nelle mappe digitali memorizzate).
gnssPlaceAuthRecord contiene informazioni relative alla posizione del veicolo,
quando l’unità elettronica di bordo ha rilevato che il veicolo ha attraversato la
frontiera di un paese, o «nessuna informazione disponibile» conformemente al
requisito 147 ter dell’allegato IC, e il suo stato di autenticazione.
vehicleOdometerValue è il valore dell’odometro quando l’unità elettro­
nica di bordo ha rilevato che il veicolo ha attraversato la frontiera di un
paese, oppure contiene l’indicazione «nessuna informazione disponibile»
conformemente al requisito 147 ter dell’allegato IC.
▼B
2.12. CardCertificate
Prima generazione:
Certificato della chiave pubblica di una carta.
2.13. CardChipIdentification
Informazioni, memorizzate in una carta, relative all'identificazione del
circuito integrato (IC) della carta (requisito 249 dell'allegato 1C). L'ic­
SerialNumber unitamente all'icManufacturingReferences identifica il chip
della carta in modo univoco. L'icSerialNumber di per sé non è suffi­
ciente per identificare univocamente il chip della carta.
icSerialNumber è il numero di serie dell'IC.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 129
icManufacturingReferences è l'identificativo specifico del fabbricante
dell'IC.
2.14. CardConsecutiveIndex
Il codice di serie di una carta [definizione h)].
Assegnazione valore: (cfr. allegato 1C, capitolo 7)
Ordine di incremento: «0, …, 9, A, …, Z, a, …, z»
2.15. CardControlActivityDataRecord
Informazioni, memorizzate in una carta del conducente o dell'officina,
relative all'ultimo controllo cui è stato sottoposto il conducente (requisiti
274, 299, 327 e 350 dell'allegato 1C).
controlType è il tipo di controllo.
controlTime è la data e l'ora del controllo.
controlCardNumber è il FullCardNumber dell'agente che ha effettuato
il controllo.
controlVehicleRegistration contiene il VRN e lo Stato membro di im­
matricolazione del veicolo in cui è stato effettuato il controllo.
controlDownloadPeriodBegin e controlDownloadPeriodEnd specifi­
cano il periodo trasferito, in caso di trasferimento.
2.16. CardCurrentUse
Informazioni sull'uso effettivo della carta (requisiti 273, 298, 326 e 349
dell'allegato 1C).
sessionOpenTime è l'ora in cui viene inserita la carta per l'uso corrente.
Questo elemento viene azzerato all'atto dell'estrazione della carta.
sessionOpenVehicle è l'identificazione del veicolo in uso, impostata
all'atto dell'inserimento della carta. Questo elemento viene azzerato al­
l'atto dell'estrazione della carta.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 130
2.17. CardDriverActivity
Informazioni, memorizzate in una carta del conducente o dell'officina,
relative alle attività del conducente (requisiti 267, 268, 292, 293, 321 e
344 dell'allegato 1C).
activityPointerOldestDayRecord specifica il punto d'inizio della memo­
rizzazione (numero di byte a partire dall'inizio della stringa) della regi­
strazione completa meno recente del giorno nella stringa activityDaily­
Records. Il valore massimo è dato dalla lunghezza della stringa.
activityPointerNewestRecord specifica il punto d'inizio della memoriz­
zazione (numero di byte a partire dall'inizio della stringa) della regi­
strazione più recente del giorno nella stringa activityDailyRecords. Il
valore massimo è dato dalla lunghezza della stringa.
activityDailyRecords è lo spazio disponibile per memorizzare i dati
relativi all'attività del conducente (struttura dei dati: CardActivityDaily­
Record) per ogni giorno di calendario in cui è stata usata la carta.
Assegnazione valore: questa stringa di ottetti viene riempita ciclica­
mente con le registrazioni di CardActivityDailyRecord. Al primo im­
piego, la memorizzazione inizia a partire dal primo byte della stringa.
Tutte le nuove registrazioni vengono aggiunte in coda alla precedente.
Quando la stringa è piena, la memorizzazione prosegue a partire dal
primo byte della stringa, indipendentemente dalla presenza di un'interru­
zione all'interno di un elemento di dati. Prima di inserire nella stringa
nuovi dati relativi all'attività (ingrandendo l'activityDailyRecord corrente
o inserendo un nuovo activityDailyRecord) per sostituire dati meno re­
centi, l'activityPointerOldestDayRecord deve essere aggiornato per tenere
conto della nuova posizione della registrazione giornaliera completa
meno recente, e l'activityPreviousRecordLength di questa (nuova) regi­
strazione giornaliera completa meno recente deve essere riazzerato.
2.18. CardDrivingLicenceInformation
Informazioni, memorizzate in una carta del conducente, relative ai dati
della patente di guida del titolare della carta (requisiti 259 e 284 dell'al­
legato 1C).
drivingLicenceIssuingAuthority è l'autorità responsabile del rilascio
della patente di guida.
drivingLicenceIssuingNation è la nazionalità dell'autorità che ha rila­
sciato la patente di guida.
drivingLicenceNumber è il numero della patente di guida.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 131
2.19. CardEventData
Prima generazione:
informazioni, memorizzate in una carta del conducente o dell’officina,
relative alle anomalie associate al titolare della carta (requisiti 260 e 318
dell’allegato IC).
CardEventData è una sequenza di cardEventRecords ordinata in base al
valore ascendente di EventFaultType (eccetto per le registrazioni relative
ai tentativi di violazione della sicurezza, che sono raggruppate nell’ul­
tima serie della sequenza).
cardEventRecords è una serie di registrazioni di anomalie di un deter­
minato tipo (o categoria di anomalie relative ai tentativi di violazione
della sicurezza).
Seconda generazione:
informazioni, memorizzate in una carta del conducente o dell’officina,
relative alle anomalie associate al titolare della carta (requisiti 285 e 341
dell’allegato IC).
CardEventData è una sequenza di cardEventRecords ordinata in base al
valore ascendente di EventFaultType (eccetto per le registrazioni relative
ai tentativi di violazione della sicurezza, che sono raggruppate nell’ul­
tima serie della sequenza).
cardEventRecords è una serie di registrazioni di anomalie di un deter­
minato tipo (o categoria di anomalie relative ai tentativi di violazione
della sicurezza).
▼B
2.20. CardEventRecord
Informazioni, memorizzate in una carta del conducente o dell'officina,
relative ad un'anomalia associata al titolare della carta (requisiti 261,
286, 318 e 341 dell'allegato 1C).
eventType è il tipo di anomalia.
eventBeginTime specifica la data e l'ora di inizio dell'anomalia.
eventEndTime specifica la data e l'ora di fine dell'anomalia.
eventVehicleRegistration contiene il VRN e lo Stato membro di imma­
tricolazione del veicolo in cui si è verificata l'anomalia.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 132
2.21. CardFaultData
Informazioni, memorizzate in una carta del conducente o dell'officina,
relative ai guasti associati al titolare della carta (requisiti 263, 288, 318 e
341 dell'allegato 1C).
CardFaultData è una sequenza di una serie di registrazioni di guasti
dell'apparecchio di controllo seguita dalla serie di registrazioni dei guasti
della carta.
cardFaultRecords è una serie di registrazioni di guasti di una determi­
nata categoria (apparecchio di controllo o carta).
2.22. CardFaultRecord
Informazioni, memorizzate in una carta del conducente o dell'officina,
relative ad un guasto associato al titolare della carta (requisiti 264, 289,
318 e 341 dell'allegato 1C).
faultType è il tipo di guasto.
faultBeginTime specifica la data e l'ora di inizio del guasto.
faultEndTime specifica la data e l'ora di fine del guasto.
faultVehicleRegistration contiene il VRN e lo Stato membro di imma­
tricolazione del veicolo in cui si è verificato il guasto.
2.23. CardIccIdentification
Informazioni, memorizzate in una carta, relative all'identificazione della
carta a circuito integrato (IC) (requisito 248 dell'allegato 1C).
clockStop è la modalità «Clockstop», come definita nell'appendice 2.
cardExtendedSerialNumber contiene il numero di serie unico della
carta IC, come ulteriormente specificato dal tipo di dati ExtendedSerial­
Number.
cardApprovalNumber è il numero di omologazione della carta.
cardPersonaliserID è l'identificazione personalizzata della carta (ID)
codificata come ManufacturerCode.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 133
embedderIcAssemblerId fornisce informazioni circa l'assemblatore
della carta IC.
icIdentifier è l'identificativo dell'IC sulla carta e del fabbricante dell'IC,
come definita nella norma ISO/IEC 7816-6.
2.24. CardIdentification
Informazioni, memorizzate in una carta, relative all'identificazione della
carta (requisiti 255, 280, 310, 333, 359, 365, 371 e 377 dell'allegato 1C).
cardIssuingMemberState è il codice dello Stato membro che ha rila­
sciato la carta.
cardNumber è il numero della carta.
cardIssuingAuthorityName è il nome dell'autorità che ha rilasciato la
carta.
cardIssueDate è la data di rilascio della carta all'attuale titolare.
cardValidityBegin è la data di inizio validità della carta.
cardExpiryDate è la data in cui termina la validità della carta.
▼M3
2.24a. CardLoadTypeEntries
Seconda generazione, versione 2:
informazioni, memorizzate in una carta del conducente o dell’officina,
relative alle immissioni del tipo di carico quando la carta è inserita in
un’unità elettronica di bordo (requisiti 306 undecies e 356 undecies
dell’allegato IC).
loadTypeEntryPointerNewestRecord è l’indice della registrazione più
aggiornata nella carta dell’immissione del tipo di carico.
Assegnazione valore: numero corrispondente al numeratore della regi­
strazione nella carta dell’immissione del tipo di carico, a partire da «0»
per la prima volta in cui tale registrazione compare nella struttura.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 134
cardLoadTypeEntryRecords è la serie di registrazioni contenenti la
data e l’ora dell’immissione e il tipo di carico immesso.
2.24b. CardLoadTypeEntryRecord
Seconda generazione, versione 2:
informazioni, memorizzate in una carta del conducente o dell’officina, rela­
tive alle modifiche del tipo di carico quando la carta è inserita in un’unità
elettronica di bordo (requisiti 306 decies e 356 decies dell’allegato IC).
timeStamp è la data e l’ora in cui è stato immesso il tipo di carico.
loadTypeEntered è il tipo di carico immesso.
2.24c. CardLoadUnloadOperations
Seconda generazione, versione 2:
informazioni, memorizzate in una carta del conducente o dell’officina,
relative alle operazioni di carico/scarico del veicolo (requisiti 306 nonies
e 356 nonies dell’allegato IC).
loadUnloadPointerNewestRecord è l’indice della registrazione più ag­
giornata nella carta dell’operazione di carico/scarico.
Assegnazione valore: è il numero corrispondente al numeratore della
registrazione nella carta dell’operazione di carico/scarico, a partire da
«0» per la prima volta in cui tale registrazione compare nella struttura.
cardLoadUnloadRecords è la serie di registrazioni contenenti l’indicazione del
tipo di operazione effettuata (carico, scarico o carico e scarico simultanei), la data
e l’ora in cui è stata immessa l’operazione di carico/scarico, informazioni sulla
posizione del veicolo e il valore dell’odometro del veicolo.
2.24d. CardLoadUnloadRecord
Seconda generazione, versione 2:
informazioni, memorizzate in una carta del conducente o dell’officina,
relative alle operazioni di carico/scarico del veicolo (requisiti 306 octies
e 356 octies dell’allegato IC).
timeStamp è la data e l’ora dell’inizio dell’operazione di carico/scarico.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 135
operationType è il tipo di operazione immessa (carico, scarico o carico/
scarico simultanei),
gnssPlaceRecord contiene informazioni relative alla posizione del
veicolo.
vehicleOdometerValue è il valore dell’odometro relativo all’inizio
dell’operazione di carico/scarico.
▼B
2.25. CardMACertificate
Seconda generazione:
Certificato della chiave pubblica della carta per l'autenticazione reciproca
con una VU. La struttura di tale certificato è specificata nell'appen­
dice 11.
2.26. CardNumber
Numero della carta, secondo la definizione g).
driverIdentification è l'identificazione univoca di un conducente in uno
Stato membro.
ownerIdentification è l'identificazione univoca di un'impresa o di un'of­
ficina o di un organismo di controllo all'interno di uno Stato membro.
cardConsecutiveIndex è il codice di serie della carta.
cardReplacementIndex è il codice di sostituzione della carta.
cardRenewalIndex è il codice di rinnovo della carta.
La prima sequenza della scelta (CHOICE) è adatta a codificare il numero
della carta del conducente, la seconda sequenza a codificare i numeri
delle carte dell'officina, di controllo e dell'azienda.
▼M3
2.26a. CardPlaceAuthDailyWorkPeriod
Seconda generazione, versione 2:
informazioni, memorizzate in una carta del conducente o dell’officina,
che forniscono lo stato di autenticazione dei luoghi in cui i periodi di
lavoro giornalieri iniziano e/o terminano (requisiti 306 ter e 356 ter
dell’allegato IC).
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 136
placeAuthPointerNewestRecord è l’indice della registrazione più ag­
giornata dello stato di autenticazione del luogo.
Assegnazione valore: numero corrispondente al numeratore della regi­
strazione dello stato di autenticazione del luogo, a partire da «0» per la
prima volta in cui tale registrazione compare nella struttura.
placeAuthStatusRecords è la serie di registrazioni contenenti lo stato di
autenticazione del luogo relativo ai luoghi immessi.
▼B
2.27. CardPlaceDailyWorkPeriod
Informazioni, memorizzate in una carta del conducente o dell'officina,
relative al luogo in cui inizia e/o termina il periodo di lavoro giornaliero
(requisiti 272, 297, 325 e 348 dell'allegato 1C).
placePointerNewestRecord è l'indice della registrazione più aggiornata
del luogo.
Assegnazione valore: numero corrispondente al numeratore della regi­
strazione del luogo, a partire da ′0′ per la prima volta in cui tale regi­
strazione compare nella struttura.
placeRecords è la serie di registrazioni contenenti le informazioni rela­
tive ai luoghi inseriti.
2.28. CardPrivateKey
Prima generazione:
La chiave privata di una carta.
2.29. CardPublicKey
La chiave pubblica di una carta.
▼M1
2.30. CardRenewalIndex
Il codice di rinnovo di una carta [definizione i)].
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 137
Value assignment: (cfr. capitolo 7 del presente allegato).
«0» Primo rilascio.
Ordine di incremento: «0, …, 9, A, …, Z»
▼B
2.31. CardReplacementIndex
Il codice di sostituzione di una carta [definizione j)].
Assegnazione valore: (cfr. capitolo VII del presente allegato).
«0» Carta originale.
Ordine di incremento: «0, …, 9, A, …, Z»
2.32. CardSignCertificate
Seconda generazione:
Certificato della chiave pubblica della carta per la firma. La struttura di
tale certificato è specificata nell'appendice 11.
2.33. CardSlotNumber
Codice usato per distinguere le due sedi (slot) di un'unità elettronica di bordo.
Assegnazione valore: nessun'altra specificazione.
2.34. CardSlotsStatus
Codice che indica il tipo di carta inserita nelle due sedi (slot) dell'unità
elettronica di bordo.
Assegnazione valore — Allineato all'ottetto: «ccccdddd»B
«cccc»B Identificazione del tipo di carta inserita nella sede (slot)
«secondo conducente»,
«dddd»B Identificazione del tipo di carta inserita nella sede (slot)
«conducente»,
con i seguenti codici di identificazione:
«0000»B carta non inserita,
«0001»B carta del conducente inserita,
«0010»B carta dell'officina inserita,
«0011»B carta di controllo inserita,
«0100»B carta dell'azienda inserita.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 138
2.35. CardSlotsStatusRecordArray
Seconda generazione:
Il CardSlotsStatus più i metadati usati nel protocollo di trasferimento.
recordType rappresenta il tipo di registrazione (CardSlotsStatus). Asse­
gnazione valore: Cfr. RecordType
recordSize sono le dimensioni di CardSlotsStatus in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è la serie di registrazioni del CardSlotsStatus.
2.36. CardStructureVersion
Codice che indica la versione della struttura utilizzata in una carta
tachigrafica.
Assegnazione valore: «aabb»H:
«aa»H Indice per le modifiche della struttura.
«00»H per le applicazioni di prima generazione
«01»H per le applicazioni di seconda generazione
▼M3
«bb»H Indice per le modifiche riguardanti l’impiego degli ele­
menti di dati definiti per la struttura data dal byte più
significativo.
«00»H per le applicazioni di prima generazione
«00»H per la versione 1 delle applicazioni di seconda
generazione
«01»H per la versione 2 delle applicazioni di seconda
generazione
▼B
2.37. CardVehicleRecord
Informazioni, memorizzate in una carta del conducente o dell'officina,
relative al periodo d'impiego di un veicolo durante un giorno di calen­
dario (requisiti 269, 294, 322 e 345 dell'allegato 1C).
Prima generazione:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 139
vehicleOdometerBegin è il valore dell'odometro del veicolo all'inizio
del periodo d'impiego del veicolo.
vehicleOdometerEnd è il valore dell'odometro del veicolo al termine
del periodo d'impiego del veicolo.
vehicleFirstUse specifica la data e l'ora d'inizio del periodo d'impiego
del veicolo.
vehicleLastUse specifica la data e l'ora di termine del periodo d'impiego
del veicolo.
vehicleRegistration contiene il VRN e lo Stato membro di immatrico­
lazione del veicolo.
vuDataBlockCounter è il valore del VuDataBlockCounter all'atto del­
l'ultima estrazione nel periodo d'impiego del veicolo.
Seconda generazione:
Oltre alla prima generazione, è utilizzato il seguente elemento di dati:
VehicleIdentificationNumber è il numero di identificazione del veicolo
che si riferisce al veicolo nel suo complesso.
2.38. CardVehiclesUsed
Informazioni, memorizzate in una carta del conducente o dell'officina,
relative ai veicoli usati dal titolare della carta (requisiti 270, 295, 323 e
346 dell'allegato 1C).
vehiclePointerNewestRecord è l'indice della registrazione più aggior­
nata del veicolo.
Assegnazione valore: numero corrispondente al numeratore della regi­
strazione del veicolo, a partire da ′0′ per la prima volta in cui tale
registrazione compare nella struttura.
cardVehicleRecords è la serie di registrazioni contenenti le informa­
zioni relative ai veicoli utilizzati.
2.39. CardVehicleUnitRecord
Seconda generazione:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 140
Informazioni, memorizzate in una carta del conducente o dell'officina,
relative ad un'unità elettronica di bordo utilizzata (requisiti 303 e 351
dell'allegato 1C).
timeStampindica l'inizio del periodo d'impiego dell'unità elettronica di
bordo (cioè il primo inserimento della carta nell'unità elettronica di
bordo per il periodo).
manufacturerCode identifica il fabbricante dell'unità elettronica di
bordo.
deviceID identifica il tipo di unità elettronica di bordo di un fabbricante.
Il valore è specifico del fabbricante.
vuSoftwareVersion è il numero della versione del software dell'unità
elettronica di bordo.
2.40. CardVehicleUnitsUsed
▼M3
Seconda generazione:
informazioni, memorizzate in una carta del conducente o dell’officina,
relative alle unità elettroniche di bordo usate dal titolare della carta
(requisiti 304 e 352 dell’allegato IC).
▼B
vehicleUnitPointerNewestRecord è l'indice della registrazione più ag­
giornata dell'unità elettronica di bordo.
Assegnazione valore: numero corrispondente al numeratore della regi­
strazione dell'unità elettronica di bordo, a partire da «0» per la prima
volta in cui tale registrazione compare nella struttura.
cardVehicleUnitRecords è la serie di registrazioni contenenti le infor­
mazioni relative alle unità elettroniche di bordo utilizzate.
2.41. Certificate
Il certificato di una chiave pubblica rilasciato da un'autorità di
certificazione.
Prima generazione:
Assegnazione valore: firma digitale con recupero parziale di un Certi­
ficateContent, secondo i meccanismi comuni di sicurezza di cui all'ap­
pendice 11: firma (128 byte) resto chiave pubblica (58 byte) riferimento
dell'autorità di certificazione (8 byte).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 141
Seconda generazione:
Assegnazione valore: v. appendice 11
2.42. CertificateContent
Prima generazione:
Il contenuto (in chiaro) del certificato di una chiave pubblica, secondo i
meccanismi comuni di sicurezza di cui all'appendice 11.
certificateProfileIdentifier è la versione del certificato corrispondente.
Assegnazione valore: «01h» per questa versione.
certificationAuthorityReference identifica l'autorità di certificazione
che ha rilasciato il certificato. Fornisce inoltre il riferimento della chiave
pubblica di tale autorità.
certificateHolderAuthorisation identifica i diritti del titolare del
certificato.
certificateEndOfValidity è la data di scadenza amministrativa del
certificato.
certificateHolderReference identifica il titolare del certificato. Fornisce
inoltre il riferimento della chiave pubblica del titolare.
publicKey è la chiave pubblica per la quale è stato rilasciato il certifi­
cato in questione.
2.43. CertificateHolderAuthorisation
Identificazione dei diritti del titolare di un certificato.
Prima generazione:
tachographApplicationID è l'identificativo di applicazione dell'applica­
zione del tachigrafo.
Assegnazione valore: «FFh» «54h» «41h» «43h» «48h» «4Fh». Si
tratta di un identificativo di applicazione di proprietà riservata, non regi­
strata, secondo ISO/IEC 7816-5.
equipmentType è l'identificazione del tipo di apparecchio cui è desti­
nato il certificato.
Assegnazione valore: in conformità al tipo di dati EquipmentType. 0 se
si tratta del certificato di uno Stato membro.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 142
Seconda generazione:
tachographApplicationID rappresenta i 6 byte più significativi del­
l'identificativo di applicazione (AID) della carta tachigrafica di seconda
generazione. L'AID dell'applicazione della carta tachigrafica è specificato
al capitolo 6.2.
Assegnazione valore: «FF 53 4D 52 44 54».
equipmentType è l'identificazione del tipo di apparecchio, specificato
per la seconda generazione, cui è destinato il certificato.
Assegnazione valore: in conformità al tipo di dati EquipmentType.
2.44. CertificateRequestID
Identificazione univoca di una richiesta di certificato. Si può anche usare
come identificativo della chiave pubblica di un'unità elettronica di bordo,
nel caso in cui il numero di serie dell'unità elettronica di bordo cui è
destinata la chiave non sia noto al momento della generazione del
certificato.
requestSerialNumber è un numero di serie per la richiesta di certifi­
cato, associato univocamente al fabbricante e al mese di cui sotto.
requestMonthYear è l'identificazione del mese e dell'anno di richiesta
del certificato.
Assegnazione valore: codifica BCD del mese (due cifre) e dell'anno
(ultime due cifre).
crIdentifier: è un identificativo usato per distinguere una richiesta di
certificato da un numero di serie completo.
Assegnazione valore: «FFh».
manufacturerCode: è il codice numerico del fabbricante che ha richie­
sto il certificato.
2.45. CertificationAuthorityKID
Identificativo della chiave pubblica di un'autorità di certificazione (di
uno Stato membro o dell'autorità europea di certificazione).
nationNumeric è il codice numerico del paese dell'autorità di
certificazione.
nationAlpha è il codice alfanumerico del paese dell'autorità di
certificazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 143
keySerialNumber è un numero di serie usato per distinguere le diverse
chiavi dell'autorità di certificazione in caso di cambio di chiavi.
additionalInfo è un campo a due byte per codifiche supplementari (a
cura dell'autorità di certificazione).
caIdentifier è un identificativo usato per distinguere l'identificativo della
chiave di un'autorità di certificazione dagli identificativi di altre chiavi.
Assegnazione valore: «01h».
2.46. CompanyActivityData
Informazioni, memorizzate in una carta dell'azienda, relative alle attività
eseguite con la carta (requisiti 373 e 379 dell'allegato 1C).
companyPointerNewestRecord è l'indice del companyActivityRecord
più aggiornato.
Assegnazione valore: numero corrispondente al numeratore della regi­
strazione delle attività dell'impresa, a partire da «0» per la prima volta in
cui tale registrazione compare nella struttura.
companyActivityRecords è la serie di tutte le registrazioni delle attività
dell'impresa.
companyActivityRecord è la sequenza di informazioni relative ad un'at­
tività dell'impresa.
companyActivityType è il tipo di attività dell'impresa.
companyActivityTime specifica la data e l'ora dell'attività dell'impresa.
cardNumberInformation contiene il numero della carta e lo Stato
membro che ha rilasciato la carta da cui sono stati trasferiti i dati, se
pertinente.
vehicleRegistrationInformation contiene il VRN e lo Stato membro di
immatricolazione del veicolo da cui sono stati trasferiti i dati o in cui è
stato attivato o disattivato un blocco.
downloadPeriodBegin e downloadPeriodEnd specificano il periodo
cui si riferisce il trasferimento dei dati della VU, se pertinente.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 144
2.47. CompanyActivityType
Codice che indica un'attività eseguita da un'impresa utilizzando la pro­
pria carta dell'azienda.
2.48. CompanyCardApplicationIdentification
Informazioni, memorizzate in una carta dell'azienda, relative all'identifica­
zione dell'applicazione della carta (requisiti 369 e 375 dell'allegato 1C).
typeOfTachographCardId specifica il tipo di carta.
cardStructureVersion specifica la versione della struttura utilizzata
nella carta.
noOfCompanyActivityRecords è il numero di registrazioni delle atti­
vità dell'impresa che la carta è in grado di memorizzare.
▼M3
2.48a. CompanyCardApplicationIdentificationV2
Seconda generazione, versione 2:
informazioni, memorizzate in una carta dell’azienda, relative all’identi­
ficazione dell’applicazione della carta (requisito 375 bis dell’allega­
to IC).
lengthOfFollowingData è il numero di byte che seguono nella
registrazione.
vuConfigurationLengthRange è il numero di byte in una carta tachi­
grafica, disponibile per memorizzare le configurazioni della VU.
▼B
2.49. CompanyCardHolderIdentification
Informazioni, memorizzate in una carta dell'azienda, relative all'identifi­
cazione del titolare della carta (requisiti 372 e 378 dell'allegato 1C).
companyName è il nome dell'impresa titolare.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 145
companyAddress è l'indirizzo dell'impresa titolare.
cardHolderPreferredLanguage è la lingua abituale del titolare della
carta.
2.50. ControlCardApplicationIdentification
Informazioni, memorizzate in una carta di controllo, relative all'identifica­
zione dell'applicazione della carta (requisiti 357 e 363 dell'allegato 1C).
typeOfTachographCardId specifica il tipo di carta.
cardStructureVersion specifica la versione della struttura utilizzata
nella carta.
noOfControlActivityRecords è il numero di registrazioni di attività di
controllo che la carta è in grado di memorizzare.
▼M3
2.50a. ControlCardApplicationIdentificationV2
Seconda generazione, versione 2:
informazioni, memorizzate in una carta di controllo, relative all’identifi­
cazione dell’applicazione della carta (requisito 363 bis dell’allegato IC).
lengthOfFollowingData è il numero di byte che seguono nella
registrazione.
vuConfigurationLengthRange è il numero di byte in una carta tachi­
grafica, disponibile per memorizzare le configurazioni della VU.
▼B
2.51. ControlCardControlActivityData
Informazioni, memorizzate in una carta di controllo, relative all'attività
di controllo eseguita con la carta (requisiti 361 e 367 dell'allegato 1C).
controlPointerNewestRecord è l'indice della registrazione più aggior­
nata dell'attività di controllo.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 146
Assegnazione valore: numero corrispondente al numeratore della regi­
strazione dell'attività di controllo, a partire da «0» per la prima volta in
cui tale registrazione compare nella struttura.
controlActivityRecords è la serie di tutte le registrazioni delle attività di
controllo.
controlActivityRecord è la sequenza di informazioni relative ad un
controllo.
controlType è il tipo di controllo.
controlTime è la data e l'ora del controllo.
controlledCardNumber contiene il numero della carta e lo Stato mem­
bro che ha rilasciato la carta sottoposta al controllo.
controlledVehicleRegistration contiene il VRN e lo Stato membro di
immatricolazione del veicolo in cui è stato effettuato il controllo.
controlDownloadPeriodBegin e controlDownloadPeriodEnd specifi­
cano il periodo trasferito, in caso di trasferimento.
2.52. ControlCardHolderIdentification
Informazioni, memorizzate in una carta di controllo, relative all'identifi­
cazione del titolare della carta (requisiti 360 e 366 dell'allegato 1C).
controlBodyName è il nome dell'organismo di controllo del titolare
della carta.
controlBodyAddress è l'indirizzo dell'organismo di controllo del titolare
della carta.
cardHolderName contiene cognome e nome/i del titolare della carta di
controllo.
cardHolderPreferredLanguage è la lingua abituale del titolare della
carta.
2.53. ControlType
Codice che indica le attività eseguite durante un controllo. Questo tipo di
dati si riferisce ai requisiti 126, 274, 299, 327 e 350 dell'allegato 1C.
Prima generazione:
Assegnazione valore — Allineato all'ottetto: «cvpdxxxx»B (8 bit)
«c»B trasferimento dati carta:
«0»B: dati carta non trasferiti durante l'attività di
controllo,
«1»B: «1»B: dati carta trasferiti durante l'attività di con­
trollo
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 147
«v»B trasferimento dati VU:
«0»B: dati VU non trasferiti durante l'attività di
controllo,
«1»B: dati VU trasferiti durante l'attività di controllo
«p»B stampa:
«0»B: stampa non eseguita durante l'attività di controllo,
«1»B: stampa eseguita durante l'attività di controllo
«d»B visualizzazione:
«0»B: visualizzazione non utilizzata durante l'attività di
controllo,
«1»B: visualizzazione utilizzata durante l'attività di con­
trollo
«xxxx»B Non usato.
Seconda generazione:
Assegnazione valore — Allineato all'ottetto: «cvpdexxx»B (8 bit)
«c»B trasferimento dati carta:
«0»B: dati carta non trasferiti durante l'attività di
controllo,
«1»B: «1»B: dati carta trasferiti durante l'attività di con­
trollo
«v»B trasferimento dati VU:
«0»B: dati VU non trasferiti durante l'attività di
controllo,
«1»B: dati VU trasferiti durante l'attività di controllo
«p»B stampa:
«0»B: stampa non eseguita durante l'attività di controllo,
«1»B: stampa eseguita durante l'attività di controllo
«d»B visualizzazione:
«0»B: visualizzazione non utilizzata durante l'attività di
controllo,
«1»B: visualizzazione utilizzata durante l'attività di con­
trollo
«e»B verifica della taratura su strada,
«0»B: parametri di taratura non controllati durante l'at­
tività di controllo,
«1»B: parametri di taratura controllati durante l'attività
di controllo
«xxx»B RFU.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 148
2.54. CurrentDateTime
La data e l'ora correnti dell'apparecchio di controllo.
Assegnazione valore: nessun'altra specificazione.
2.55. CurrentDateTimeRecordArray
Seconda generazione:
La data e l'ora correnti più i metadati usati nel protocollo di
trasferimento.
recordType rappresenta il tipo di registrazione (CurrentDateTime). As­
segnazione valore: Cfr. RecordType
recordSize sono le dimensioni di CurrentDateTime in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni di data e ora correnti.
2.56. DailyPresenceCounter
Un contatore, memorizzato in una carta del conducente o dell'officina,
incrementato di un'unità per ogni giorno di calendario in cui la carta
viene inserita in una VU. Questo tipo di dati si riferisce ai requisiti 266,
299, 320 e 343 dell'allegato 1C.
Assegnazione valore: numero consecutivo con valore massimo = 9 999,
anche in questo caso a partire da 0. All'atto del primo rilascio della carta
il numero è impostato su 0.
2.57. Datef
Data espressa in un formato numerico idoneo alla stampa.
Assegnazione valore:
yyyy Anno
mm Mese
dd Giorno
«00000000»H denota esplicitamente l'assenza di data.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 149
2.58. DateOfDayDownloaded
Seconda generazione:
la data e l'ora del trasferimento.
Assegnazione valore: nessun'altra specificazione.
2.59. DateOfDayDownloadedRecordArray
Seconda generazione:
La data e l'ora del trasferimento più i metadati usati nel protocollo di
trasferimento.
recordType rappresenta il tipo di registrazione (DateOfDayDownloa­
ded). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di CurrentDateTime in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è la serie di data e ora delle registrazioni dei trasferimenti.
2.60. Distance
Una distanza percorsa (risultante dal calcolo della differenza tra due
valori dell'odometro del veicolo espressi in chilometri).
Assegnazione valore: binario senza segno. Valore in km nell'intervallo
operativo 0-9 999 km.
▼M3
2.60a. DownloadInterfaceVersion
Seconda generazione, versione 2:
codice che indica la versione dell’interfaccia di trasferimento dati di
un’unità elettronica di bordo.
Assegnazione valore: «aabb»H:
«aa»H «00»H: non usato,
«01»H: unità elettronica di bordo di seconda generazione,
«bb»H «00»H: non usato,
«01»H: versione 2 dell’unità elettronica di bordo di seconda
generazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 150
2.61. DriverCardApplicationIdentification
Informazioni, memorizzate in una carta del conducente, relative all'identi­
ficazione dell'applicazione della carta (requisiti 253 e 278 dell'allegato 1C).
Prima generazione:
typeOfTachographCardId specifica il tipo di carta.
cardStructureVersion specifica la versione della struttura utilizzata
nella carta.
noOfEventsPerType è il numero di anomalie per tipo di anomalia che
la carta è in grado di registrare.
noOfFaultsPerType è il numero di guasti per tipo di guasto che la carta
è in grado di registrare.
activityStructureLength indica il numero di byte disponibili per me­
morizzare le registrazioni delle attività.
noOfCardVehicleRecords è il numero di registrazioni del veicolo che
la carta è in grado di contenere.
noOfCardPlaceRecords è il numero di luoghi che la carta è in grado di
registrare.
Seconda generazione:
▼M1
Oltre alla prima generazione, sono utilizzati gli elementi di dati seguenti:
noOfGNSSADRecords è il numero di registrazioni del periodo guida
cumulativo del GNSS che la carta è in grado di memorizzare.
noOfSpecificConditionRecords è il numero di registrazioni di condi­
zioni particolari che la carta è in grado di memorizzare.
noOfCardVehicleUnitRecords è il numero di registrazioni utilizzate
delle unità elettroniche di bordo che la carta è in grado di memorizzare.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 151
2.61a. DriverCardApplicationIdentificationV2
Seconda generazione, versione 2:
informazioni, memorizzate in una carta del conducente, relative all’iden­
tificazione dell’applicazione della carta (requisito 278 bis dell’allega­
to IC).
lengthOfFollowingData è il numero di byte che seguono nella
registrazione.
noOfBorderCrossingRecords è il numero di registrazioni degli attra­
versamenti di frontiera che la carta del conducente può memorizzare.
noOfLoadUnloadRecords è il numero di registrazioni delle operazioni
di carico/scarico che la carta del conducente può memorizzare.
noOfLoadTypeEntryRecords è il numero di registrazioni delle immis­
sioni dei tipi di carico che la carta del conducente può memorizzare.
vuConfigurationLengthRange è il numero di byte in una carta tachi­
grafica, disponibile per memorizzare le configurazioni della VU.
▼B
2.62. DriverCardHolderIdentification
Informazioni, memorizzate in una carta del conducente, relative all'iden­
tificazione del titolare della carta (requisiti 256 e 281 dell'allegato 1C).
cardHolderName contiene cognome e nome/i del titolare della carta del
conducente.
cardHolderBirthDate è la data di nascita del titolare della carta del
conducente.
cardHolderPreferredLanguage è la lingua abituale del titolare della
carta.
▼M3
2.63. DSRCSecurityData
Seconda generazione:
Per la definizione di questo tipo di dati, cfr. l’appendice 11.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 152
2.64. EGFCertificate
Seconda generazione:
Certificato della chiave pubblica del dispositivo GNSS esterno per l'au­
tenticazione reciproca con una VU. La struttura di tale certificato è
specificata nell'appendice 11.
2.65. EmbedderIcAssemblerId
Fornisce informazioni sull'assemblatore della carta IC.
countryCode è il codice paese di 2 lettere dell'assemblatore del modulo
in conformità alla norma ISO 3166.
moduleEmbedder identifica l'assemblatore del modulo.
manufacturerInformation ad uso interno del fabbricante.
2.66. EntryTypeDailyWorkPeriod
Codice usato per distinguere inizio e termine dell'immissione del luogo
di un periodo di lavoro giornaliero e la condizione dell'immissione.
Prima generazione
Assegnazione valore: secondo ISO/IEC8824-1.
▼M3
Seconda generazione
Assegnazione valore: secondo ISO/IEC8824-1.
▼B
2.67. EquipmentType
Codice usato per distinguere i diversi tipi di apparecchio per l'applica­
zione tachigrafica.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 153
Prima generazione:
Assegnazione valore: secondo ISO/IEC8824-1.
Il valore 0 è riservato; serve ad indicare uno Stato membro o l'Europa
nel campo CHA dei certificati.
Seconda generazione:
▼M1
Si usano gli stessi valori della prima generazione con le aggiunte
seguenti:
Nota 1: i valori della seconda generazione per la targa, l’adattatore e la
connessione del dispositivo GNSS esterno e i valori della prima gene­
razione per l’unità elettronica di bordo e il sensore di movimento pos­
sono essere utilizzati in SealRecord, se del caso.
Nota 2: nel campo CardHolderAuthorisation (CHA) dei certificati di se­
conda generazione i valori 1, 2 e 6 vanno interpretati come indicanti un
certificato di autenticazione reciproca per il rispettivo tipo di apparec­
chio. Per indicare il rispettivo certificato allo scopo di creare una firma
digitale, vanno usati i valori 17, 18 o 19.
▼B
2.68. EuropeanPublicKey
Prima generazione:
La chiave pubblica europea.
2.69. EventFaultRecordPurpose
Codice che spiega il motivo per cui sono stati registrati un'anomalia o un
guasto.
Assegnazione valore:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 154
una delle 10 anomalie o dei 10 guasti più recenti (o ultimi)
l'anomalia più lunga per uno degli ultimi 10 giorni in cui si è verificata
una delle 5 anomalie più lunghe nel corso degli ultimi 365 giorni
l'ultima anomalia per uno degli ultimi 10 giorni in cui si è verificata
l'anomalia più grave per uno degli ultimi 10 giorni in cui si è verificata
una delle 5 anomalie più gravi nel corso degli ultimi 365 giorni
la prima anomalia o il primo guasto che si è verificato dopo l'ultima taratura
un'anomalia o un guasto attivo/in atto
RFU
specifico del fabbricante
2.70. EventFaultType
Codice che identifica un'anomalia o un guasto.
Assegnazione valore:
Prima generazione:
Anomalie generali,
Nessun'altra informazione,
Inserimento di una carta non valida,
Conflitto di carte,
Sovrapposizione di orari,
Guida in assenza di una carta adeguata;
Inserimento carta durante la guida,
Chiusura errata ultima sessione carta,
Superamento di velocità,
Interruzione dell'alimentazione di energia,
Errore dei dati di movimento,
Dati contrastanti sul movimento del veicolo,
RFU,
Anomalie relative a tentativi di violazione della sicurezza riguardanti l'unità elettronica
di bordo,
Nessun'altra informazione,
Mancata autenticazione del sensore di movimento,
Mancata autenticazione della carta tachigrafica,
Cambiamento non autorizzato di sensore di movimento,
Errore di integrità nell'immissione dei dati della carta,
Errore di integrità dei dati dell'utente memorizzati,
Errore nel trasferimento interno di dati,
Apertura non autorizzata dell'involucro,
Sabotaggio di elementi hardware,
RFU,
Anomalie relative a tentativi di violazione della sicurezza riguardanti il sensore,
Nessun'altra informazione,
Autenticazione fallita,
Errore di integrità dei dati memorizzati,
Errore nel trasferimento interno di dati,
Apertura non autorizzata dell'involucro,
Sabotaggio di elementi hardware,
RFU,
Guasti dell'apparecchio di controllo,
Nessun'altra informazione,
Guasto all'interno della VU,
Guasto della stampante,
Guasto del dispositivo di visualizzazione,
Guasto nel trasferimento di dati,
Guasto del sensore,
RFU,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 155
Guasti della carta,
Nessun'altra informazione,
RFU,
RFU,
Specifico del fabbricante.
▼M3
Seconda generazione, versione 1:
▼M1
Anomalie generali,
Nessun’altra informazione,
Inserimento di una carta non valida,
Conflitto di carte,
Sovrapposizione di orari,
Guida in assenza di una carta adeguata,
Inserimento carta durante la guida,
Chiusura errata ultima sessione carta,
Superamento di velocità,
Interruzione dell’alimentazione di energia,
Errore dei dati di movimento,
Conflitto di dati sul movimento del veicolo,
Conflitto di orari (fra orologio del GNSS e orologio interno della VU),
Errore di comunicazione con il dispositivo di comunicazione remota,
Assenza di informazioni sulla posizione provenienti dal ricevitore GNSS,
Errore di comunicazione con il dispositivo GNSS esterno,
RFU,
Anomalie relative a tentativi di violazione della sicurezza riguardanti l’unità elettronica
di bordo,
Nessun’altra informazione,
Mancata autenticazione del sensore di movimento,
Mancata autenticazione della carta tachigrafica,
Cambiamento non autorizzato di sensore di movimento,
Errore di integrità nell’immissione dei dati della carta,
Errore di integrità dei dati dell’utente memorizzati,
Errore nel trasferimento interno di dati,
Apertura non autorizzata dell’involucro,
Sabotaggio di elementi hardware,
Individuazione di manomissione del GNSS,
Mancata autenticazione del dispositivo GNSS esterno,
Certificato del dispositivo GNSS esterno scaduto,
RFU,
Anomalie relative a tentativi di violazione della sicurezza riguardanti il sensore,
Nessun’altra informazione,
Autenticazione fallita,
Errore di integrità dei dati memorizzati,
Errore nel trasferimento interno di dati,
Apertura non autorizzata dell’involucro,
Sabotaggio di elementi hardware,
RFU,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 156
Guasti dell’apparecchio di controllo,
Nessun’altra informazione,
Guasto all’interno della VU,
Guasto della stampante,
Guasto del dispositivo di visualizzazione,
Guasto nel trasferimento di dati,
Guasto del sensore,
Ricevitore del GNSS interno,
Dispositivo GNSS esterno,
Dispositivo di comunicazione remota,
Interfaccia ITS,
RFU,
Guasti della carta,
Nessun’altra informazione,
RFU,
RFU,
Specifico del fabbricante.
▼M3
Seconda generazione, versione 2:
«0x»H Anomalie generali,
«00»H Nessun’altra informazione,
«01»H Inserimento di una carta non valida,
«02»H Conflitto di carte,
«03»H Sovrapposizione di orari,
«04»H guida in assenza di una carta adeguata;
«05»H Inserimento carta durante la guida,
«06»H Chiusura errata ultima sessione carta,
«07»H Superamento di velocità,
«08»H Interruzione dell’alimentazione di energia,
«09»H Errore dei dati di movimento,
«0A»H Dati contrastanti sul movimento del veicolo,
«0B»H Conflitto di orari (orologio interno del GNSS e
orologio interno della VU),
«0C»H Errore di comunicazione con il dispositivo di co­
municazione remota,
«0D»H Assenza di informazioni sulla posizione prove­
nienti dal ricevitore GNSS,
«0E»H Errore di comunicazione con il dispositivo GNSS
esterno,
«0F»H Anomalia GNSS,
«1x»H Anomalie relative a tentativi di violazione della
sicurezza riguardanti l’unità elettronica di bordo,
«10»H Nessun’altra informazione,
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 157
«11»H Mancata autenticazione del sensore di movimento,
«12»H Mancata autenticazione della carta tachigrafica,
«13»H Cambiamento non autorizzato di sensore di
movimento,
«14»H Errore di integrità nell’immissione dei dati della
carta,
«15»H Errore di integrità dei dati dell’utente
memorizzati,
«16»H Errore nel trasferimento interno di dati,
«17»H Apertura non autorizzata dell’involucro,
«18»H Sabotaggio di elementi hardware,
«19»H Rilevamento delle manomissioni del GNSS,
«1 A»H Mancata autenticazione del dispositivo GNSS
esterno,
«1 B»H Certificato del dispositivo GNSS esterno scaduto,
«1C»H Incoerenza tra i dati di movimento e i dati memo­
rizzati relativi all’attività del conducente,
da «1D»H a «1F»H RFU,
«2x»H Anomalie relative a tentativi di violazione della
sicurezza riguardanti il sensore,
«20»H Nessun’altra informazione,
«21»H Autenticazione fallita,
«22»H Errore di integrità dei dati memorizzati,
«23»H Errore nel trasferimento interno di dati,
«24»H Apertura non autorizzata dell’involucro,
«25»H Sabotaggio di elementi hardware,
da «26»H a «2F»H RFU,
«3x»H Guasti dell’apparecchio di controllo,
«30»H Nessun’altra informazione,
«31»H Guasto interno della VU,
«32»H Guasto della stampante,
«33»H Guasto del dispositivo di visualizzazione,
«34»H Guasto nel trasferimento dati,
«35»H Guasto del sensore,
«36»H Ricevitore GNSS interno,
«37»H Dispositivo GNSS esterno,
«38»H Dispositivo di comunicazione remota,
«39»H Interfaccia ITS,
«3 A»H Guasto del sensore interno,
da «3B»H a «3F»H RFU,
«4x»H Guasti della carta,
«40»H Nessun’altra informazione,
da «41»H a «4F»H RFU,
da «50»H a «7F»H RFU,
da «80»H a «FF»H Specifico del fabbricante.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 158
2.71. ExtendedSealIdentifier
Seconda generazione:
l’identificativo completo del sigillo identifica in modo univoco un sigillo
(requisito 401 dell’allegato IC).
manufacturerCode è un codice del fabbricante del sigillo. Assegna­
zione valore: cfr. registrazione nella banca dati gestita dalla Commis­
sione europea (cfr. https://dtc.jrc.ec.europa.eu).
sealIdentifier è un identificativo del sigillo che è unico per il fabbri­
cante. Assegnazione valore: numero alfanumerico unico nel settore del
fabbricante in base a [ISO8859-1].
▼B
2.72. ExtendedSerialNumber
Identificazione univoca di un apparecchio. Si può anche usare come
identificativo della chiave pubblica di un apparecchio.
Prima generazione:
serialNumber è un numero di serie dell'apparecchio, univocamente as­
sociato al fabbricante, al tipo di apparecchio e al mese e all'anno di cui
sotto.
monthYear è l'identificazione del mese e dell'anno di fabbricazione (o di
assegnazione del numero di serie).
Assegnazione valore: codifica BCD del mese (due cifre) e dell'anno
(ultime due cifre).
type è un identificativo del tipo di apparecchio.
Assegnazione valore: specifico del fabbricante, con valore riservato
«FFh».
manufacturerCode: è il codice numerico che identifica un fabbricante di
un apparecchio omologato.
Seconda generazione:
serialNumber cfr. prima generazione
monthYear cfr. prima generazione
type indica il tipo di apparecchio
manufacturerCode: cfr. prima generazione.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 159
2.73. FullCardNumber
Codice per l'identificazione completa di una carta tachigrafica.
cardType è il tipo di carta tachigrafica.
cardIssuingMemberState è il codice dello Stato membro che ha rila­
sciato la carta.
cardNumber è il numero della carta.
2.74. FullCardNumberAndGeneration
Seconda generazione:
Codice per l'identificazione completa di una carta tachigrafica e della sua
generazione.
fullcardNumber identifica la carta tachigrafica.
generation indica la generazione della carta tachigrafica utilizzata.
2.75. Generation
Seconda generazione:
Indica la generazione del tachigrafo utilizzato.
Assegnazione valore:
«00»H RFU
«01»H Prima generazione
«02»H Seconda generazione
«03»H .. «FF»H RFU
2.76. GeoCoordinates
▼M3
Seconda generazione:
le coordinate geografiche sono codificate come numeri interi. Tali numeri
interi sono multipli della codifica ±DDMM.M per la latitudine e
±DDDMM.M per la longitudine. Qui ±DD e ±DDD rispettivamente
indicano i gradi e MM.M indica i minuti. La longitudine e la latitudine
di una posizione sconosciuta sono rappresentate con il valore esadeci­
male «7FFFFF» (decimale 8388607).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 160
latitude è codificato come multiplo (fattore 10) della rappresentazione di
±DDMM.M.
longitude è codificato come multiplo (fattore 10) della rappresentazione
di ±DDDMM.M.
2.77. GNSSAccuracy
Seconda generazione:
L'accuratezza dei dati del GNSS sulla posizione [definizione eee)]. Tale
accuratezza è codificata come numero intero ed è un multiplo (fattore 10)
del valore X.Y fornito dalla frase GSA NMEA.
▼M1
2.78. GNSSAccumulatedDriving
Seconda generazione:
Informazioni, memorizzate in una carta del conducente o dell’officina,
relative alla posizione del veicolo rilevata dal GNSS, se il periodo di
guida cumulativo raggiunge un multiplo di tre ore (requisiti 306 e 354
dell’allegato IC).
gnssADPointerNewestRecord è l’indice della registrazione più aggior­
nata di guida cumulativa effettuata dal GNSS.
Value assignment è il numero corrispondente al numeratore della regi­
strazione del periodo guida cumulativo effettuata dal GNSS, a partire da
’0’ per la prima volta in cui tale registrazione compare nella struttura.
gnssAccumulatedDrivingRecords è la serie di registrazioni contenenti
la data e l’ora in cui il periodo guida cumulativo raggiunge un multiplo
di tre ore e informazioni sulla posizione del veicolo.
2.79. GNSSAccumulatedDrivingRecord
Seconda generazione:
Informazioni, memorizzate in una carta del conducente o dell’officina,
relative alla posizione del veicolo rilevata dal GNSS, se il periodo di
guida cumulativo raggiunge un multiplo di tre ore (requisiti 305 e 353
dell’allegato IC).
timeStamp indica la data e l’ora in cui il periodo di guida cumulativo
raggiunge un multiplo di tre ore.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 161
gnssPlaceRecord contiene informazioni relative alla posizione del
veicolo.
vehicleOdometerValue è il valore odometrico del momento in cui il
periodo di guida cumulativo raggiunge un multiplo di tre ore.
▼M3
2.79a. GNSSAuthAccumulatedDriving
Seconda generazione, versione 2:
informazioni, memorizzate in una carta del conducente o dell’officina,
che forniscono lo stato di autenticazione delle posizioni GNSS del vei­
colo, se il periodo di guida cumulativo raggiunge un multiplo di tre ore
(requisiti 306 quinquies e 356 quinquies dell’allegato IC).
gnssAuthADPointerNewestRecord è l’indice della registrazione più ag­
giornata dello stato di autenticazione della posizione GNSS.
Assegnazione valore è il numero corrispondente al numeratore della
registrazione dello stato di autenticazione della posizione GNSS, a partire
da «0» per la prima volta in cui tale registrazione compare nella struttura.
gnssAuthStatusADRecords è la serie di registrazioni contenenti la data
e l’ora in cui il periodo di guida cumulativo raggiunge un multiplo di tre
ore e lo stato di autenticazione della posizione GNSS del veicolo.
2.79b. GNSSAuthStatusADRecord
Seconda generazione, versione 2:
informazioni, memorizzate in una carta del conducente o dell’officina,
che forniscono lo stato di autenticazione della posizione GNSS del vei­
colo, se il periodo di guida cumulativo raggiunge un multiplo di tre ore
(requisiti 306 quater e 356 quater dell’allegato IC). Altre informazioni
relative alla posizione GNSS stessa sono memorizzate in un’altra regi­
strazione (cfr. 2.79 GNSSAccumulatedDrivingRecord).
timeStamp è la data e l’ora in cui il periodo di guida cumulativo rag­
giunge un multiplo di tre ore (stessa data e ora indicate nel corrispon­
dente GNSSAccumulatedDrivingRecord).
authenticationStatus è lo stato di autenticazione della posizione GNSS
quando il periodo di guida cumulativo raggiunge un multiplo di tre ore.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 162
2.79c. GNSSPlaceAuthRecord
Seconda generazione, versione 2:
informazioni relative alla posizione GNSS del veicolo (requisiti 108,
109, 110, 296, 306 bis, 306 quater, 306 sexies, 306 octies, 356 bis,
356 quater, 356 sexies e 356 octies dell’allegato IC).
timeStamp è la data e l’ora in cui è stata determinata la posizione GNSS
del veicolo.
gnssAccuracy è l’accuratezza dei dati sulla posizione GNSS.
geoCoordinates è la posizione registrata tramite GNSS.
authenticationStatus è lo stato di autenticazione della posizione GNSS
al momento della sua determinazione.
▼B
2.80. GNSSPlaceRecord
Seconda generazione:
Informazioni relative alla posizione del veicolo rilevata dal GNSS (re­
quisiti 108, 109, 110, 296, 305, 347 e 353 dell'allegato 1C).
timeStamp indica la data e l'ora di determinazione della posizione del
veicolo da parte del GNSS.
gnssAccuracy è l'accuratezza dei dati sulla posizione del GNSS.
geoCoordinates è la posizione registrata tramite GNSS.
2.81. HighResOdometer
Valore dell'odometro del veicolo: distanza cumulata percorsa dal veicolo
durante il funzionamento.
Assegnazione valore: binario senza segno. Valore espresso in 1/200 km
nell'intervallo operativo 0-21 055 406 km.
2.82. HighResTripDistance
Una distanza percorsa durante un intero viaggio o parte di esso.
Assegnazione valore: binario senza segno. Valore espresso in 1/200 km
nell'intervallo operativo 0-21 055 406 km.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 163
2.83. HolderName
Cognome e nome/i del titolare di una carta.
holderSurname è il cognome del titolare. Il cognome non comprende
titoli.
Assegnazione valore: nel caso di una carta non personale, holderSur­
name contiene le stesse informazioni di companyName o workshopName
o controlBodyName.
holderFirstNames contiene il nome (o i nomi) e le iniziali del titolare.
▼M3
2.84. Riservato per uso futuro
▼B
Seconda generazione:
Indicazione se il ricevitore GNSS è interno o esterno all'unità elettronica
di bordo. «Vero» significa che il ricevitore GNSS è interno alla VU.
«Falso» significa che il ricevitore GNSS è esterno.
2.85. K-ConstantOfRecordingEquipment
Costante dell'apparecchio di controllo [definizione m)].
Assegnazione valore: impulsi per chilometro nell'intervallo operativo 0-
64 255 impulsi/km.
▼M1
2.86. KeyIdentifier
Identificativo univoco di una chiave pubblica utilizzato per codificare e
selezionare la chiave. Identifica anche il titolare della chiave.
La prima scelta (CHOICE) è adatta a codificare la chiave pubblica di
un’unità elettronica di bordo, di una carta tachigrafica o di un dispositivo
GNSS esterno.
La seconda scelta è adatta a codificare la chiave pubblica di un’unità
elettronica di bordo (nei casi in cui il numero di serie dell’unità elet­
tronica di bordo non sia noto al momento della generazione del certifi­
cato).
La terza scelta è adatta a codificare la chiave pubblica di uno Stato
membro.
▼B
2.87. KMWCKey
Seconda generazione:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 164
Chiave AES e versione della chiave ivi associata usata per l'abbinamento
del sensore di movimento alla VU. Per i dettagli cfr. l'appendice 11.
kMWCKey è la lunghezza della chiave AES concatenata con la chiave
usata per l'abbinamento del sensore di movimento alla VU.
keyVersion rappresenta la versione della chiave AES.
2.88. Language
Codice che identifica una lingua.
Assegnazione valore: codifica a due lettere minuscole, secondo ISO
639.
2.89. LastCardDownload
Data e ora, registrati sulla carta del conducente, dell'ultimo trasferimento
di dati dalla carta (a fini diversi da quelli di controllo), requisiti 257 e
282 dell'allegato 1C. La data può essere aggiornata dalla VU o da
qualsiasi lettore di carte.
Assegnazione valore: nessun'altra specificazione.
▼M3
2.89a. LengthOfFollowingData
Seconda generazione, versione 2:
indicatore di lunghezza per registrazioni estendibili.
Assegnazione valore: cfr. appendice 2.
▼B
2.90. LinkCertificate
Seconda generazione:
Il certificato di collegamento tra coppie di chiavi dell'autorità europea di
certificazione primaria.
▼M3
2.90a. LoadType
Seconda generazione, versione 2:
codice che identifica un tipo di carico immesso.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 165
Assegnazione valore:
«00»H Tipo di carico non definito,
«01»H Merci,
«02»H Passeggeri,
«03»H .. «FF»H RFU.
▼B
2.91. L-TyreCircumference
Circonferenza effettiva degli pneumatici delle ruote [definizione u)].
Assegnazione valore: binario senza segno, valore espresso in 1/8 mm
nell'intervallo operativo 0-8 031 mm.
▼M1
2.92. MAC
Seconda generazione:
Un totale di controllo crittografico di 8, 12 o 16 byte di lunghezza
corrispondente alle cipher suites (sequenze crittografiche) di cui all’ap­
pendice 11.
▼B
2.93. ManualInputFlag
Codice che indica se, all'atto dell'inserimento della carta, il titolare di una
carta abbia o meno inserito manualmente le attività del conducente (re­
quisito 081 dell'allegato 1B e requisito 102 dell'allegato 1C).
Assegnazione valore: nessun'altra specificazione.
2.94. ManufacturerCode
Codice che identifica il fabbricante di un apparecchio omologato.
Il laboratorio competente per le prove di interoperabilità aggiorna e pub­
blica sul proprio sito Internet l'elenco dei codici dei fabbricanti (requisito
454 dell'allegato 1C).
I ManufacturerCodes sono assegnati in via provvisoria ai progettisti di
tachigrafi su richiesta del laboratorio responsabile delle prove di intero­
perabilità.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 166
2.95. ManufacturerSpecificEventFaultData
Seconda generazione:
I codici di errore specifici del fabbricante semplificano l'analisi degli
errori e la manutenzione delle unità elettroniche di bordo.
manufacturerCode identifica il fabbricante dell'unità elettronica di bordo.
manufacturerSpecificErrorCode è un codice di errore specifico del
fabbricante.
2.96. MemberStateCertificate
Il certificato della chiave pubblica di uno Stato membro rilasciato dal­
l'autorità europea di certificazione.
2.97. MemberStateCertificateRecordArray
Seconda generazione:
Il certificato dello Stato membro più i metadati usati nel protocollo di
trasferimento.
recordType rappresenta il tipo di registrazione (MemberStateCertificate).
Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di MemberStateCertificate in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni. Il
valore deve essere fissato a 1 perché i certificati possono avere lunghezze
diverse.
records è la serie di certificati dello Stato membro.
2.98. MemberStatePublicKey
Prima generazione:
La chiave pubblica di uno Stato membro.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 167
2.99. Name
Un nome.
codePage specifica una serie di caratteri quali definiti nel capitolo 4,
name è un nome codificato usando la serie specifica di caratteri.
2.100. NationAlpha
Codice alfabetico del paese conforme ai segni distintivi usati sui veicoli
nel traffico internazionale (Convenzione delle Nazioni Unite sulla circo­
lazione stradale — Vienna 1968).
I codici NationAlpha e i codici numerici devono figurare in un elenco
pubblicato nel sito Internet del laboratorio incaricato di effettuare le
prove di interoperabilità, come previsto dal requisito 440 dell'allegato
1C.
2.101. NationNumeric
Codice numerico di un paese.
Assegnazione valore: cfr. tipo di dati 2.100 (NationAlpha).
Qualsiasi modifica delle specifiche NationAlpha o numeriche descritte
nel precedente paragrafo può essere apportata soltanto dopo che il labo­
ratorio incaricato abbia ottenuto il parere dei fabbricanti dell'unità elet­
tronica di bordo del tachigrafo intelligente e digitale omologato.
▼M3
2.101a. NoOfBorderCrossingRecords
Seconda generazione, versione 2:
numero di registrazioni di attraversamenti di frontiera che una carta del
conducente o dell’officina è in grado di memorizzare.
Assegnazione valore: cfr. appendice 2.
▼B
2.102. NoOfCalibrationRecords
Numero di registrazioni di tarature che una carta dell'officina è in grado
di memorizzare.
Prima generazione:
Assegnazione valore: cfr. appendice 2.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 168
Seconda generazione:
Assegnazione valore: cfr. appendice 2.
2.103. NoOfCalibrationsSinceDownload
Contatore che indica il numero di tarature effettuate con una carta del­
l'officina dall'ultimo trasferimento dei suoi dati (requisiti 317 e 340 del­
l'allegato 1C).
Assegnazione valore: nessun'altra specificazione.
2.104. NoOfCardPlaceRecords
Numero di registrazioni di luoghi che una carta del conducente o del­
l'officina è in grado di memorizzare.
Prima generazione:
Assegnazione valore: cfr. appendice 2.
Seconda generazione:
Assegnazione valore: cfr. appendice 2.
2.105. NoOfCardVehicleRecords
Numero di registrazioni relative ai veicoli utilizzati che una carta del
conducente o dell'officina è in grado di memorizzare.
Assegnazione valore: cfr. appendice 2.
2.106. NoOfCardVehicleUnitRecords
Seconda generazione:
Numero di registrazioni relative alle unità elettroniche di bordo utilizzate
che una carta del conducente o dell'officina è in grado di memorizzare.
Assegnazione valore: cfr. appendice 2.
2.107. NoOfCompanyActivityRecords
Numero di registrazioni delle attività dell'impresa che una carta del­
l'azienda è in grado di memorizzare.
Assegnazione valore: cfr. appendice 2.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 169
2.108. NoOfControlActivityRecords
Numero di registrazioni delle attività di controllo che una carta di con­
trollo è in grado di memorizzare.
Assegnazione valore: cfr. appendice 2.
2.109. NoOfEventsPerType
Numero di anomalie per tipo di anomalia che una carta è in grado di
memorizzare.
Assegnazione valore: cfr. appendice 2.
2.110. NoOfFaultsPerType
Numero di guasti per tipo di guasto che una carta è in grado di
memorizzare.
Assegnazione valore: cfr. appendice 2.
▼M1
2.111. NoOfGNSSADRecords
Seconda generazione:
Numero di registrazioni del periodo guida cumulativo del GNSS che una
carta è in grado di memorizzare.
Assegnazione valore: cfr. appendice 2.
▼M3
2.111a. NoOfLoadUnloadRecords
Seconda generazione, versione 2:
numero di registrazioni di operazioni di carico/scarico che una carta è in
grado di memorizzare.
Assegnazione valore: cfr. appendice 2.
▼B
2.112. NoOfSpecificConditionRecords
Seconda generazione:
Numero di registrazioni di condizioni particolari che una carta è in grado
di memorizzare.
Assegnazione valore: cfr. appendice 2.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 170
2.112a. NoOfLoadTypeEntryRecords
Seconda generazione, versione 2:
numero di registrazioni di immissioni di tipi di carico che una carta del
conducente o dell’officina è in grado di memorizzare.
Assegnazione valore: cfr. appendice 2.
▼B
2.113. OdometerShort
Valore dell'odometro del veicolo in forma abbreviata.
Assegnazione valore: binario senza segno. Valore espresso in km nel­
l'intervallo operativo 0-9 999 999 km.
2.114. OdometerValueMidnight
Il valore dell'odometro del veicolo alla mezzanotte di un determinato
giorno (requisito 090 dell'allegato 1B e requisito 113 dell'allegato 1C).
Assegnazione valore: nessun'altra specificazione.
▼M3
2.114a. OperationType
Seconda generazione, versione 2:
codice che identifica un tipo di operazione immessa.
Assegnazione valore:
«00»H RFU,
«01»H Operazione di carico,
«02»H Operazione di scarico,
«03»H Operazione di carico/scarico simultanei,
«04»H .. «FF»H RFU.
▼B
2.115. OdometerValueMidnightRecordArray
Seconda generazione:
L'OdometerValueMidnight più i metadati usati nel protocollo di
trasferimento.
recordType rappresenta il tipo di registrazione (OdometerValueMid­
night). Assegnazione valore: Cfr. RecordType
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 171
recordSize sono le dimensioni di OdometerValueMidnight in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è la serie di registrazioni dell'OdometerValueMidnight.
2.116. OverspeedNumber
Numero di anomalie per superamento di velocità dopo l'ultimo controllo
di superamento di velocità.
Assegnazione valore: 0 significa che non si è verificata alcuna anomalia
per superamento di velocità dopo l'ultimo controllo di superamento di
velocità, 1 significa che si è verificata un'anomalia per superamento
velocità dopo l'ultimo controllo … 255 significa che si sono verificate
255 o più anomalie per superamento di velocità dopo l'ultimo controllo
di superamento di velocità.
▼M3
2.116a. PlaceAuthRecord
Informazioni relative al luogo in cui inizia o termina un periodo di
lavoro giornaliero (requisiti 108, 271, 296, 324 e 347 dell’allegato IC).
Seconda generazione, versione 2:
entryTime è la data e l’ora di immissione.
entryTypeDailyWorkPeriod è il tipo di immissione.
dailyWorkPeriodCountry è il paese immesso.
dailyWorkPeriodRegion è la regione immessa.
vehicleOdometerValue è il valore dell’odometro al momento dell’im­
missione del luogo.
entryGNSSPlaceAuthRecord è la posizione registrata, lo stato di au­
tenticazione GNSS e l’ora.
2.116b. PlaceAuthStatusRecord
Seconda generazione, versione 2:
informazioni, memorizzate in una carta del conducente o dell’officina,
che forniscono lo stato di autenticazione del luogo in cui il periodo di
lavoro giornaliero inizia e/o termina (requisiti 306 bis e 356 bis dell’al­
legato IC). Altre informazioni relative al luogo stesso sono memorizzate
in un’altra registrazione (cfr. 2.117 PlaceRecord).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 172
entryTime è la data e l’ora di immissione (stessa data e ora indicate nel
corrispondente PlaceRecord).
authenticationStatus è lo stato di autenticazione della posizione GNSS
registrata.
▼B
2.117. PlaceRecord
Informazioni relative al luogo in cui inizia o termina un periodo di
lavoro giornaliero (requisiti 108, 271, 296, 324 e 347 dell'allegato 1C).
Prima generazione:
entryTime specifica la data e l'ora relative all'immissione.
entryTypeDailyWorkPeriod è il tipo di immissione.
dailyWorkPeriodCountry è il paese inserito.
dailyWorkPeriodRegion è la regione inserita.
vehicleOdometerValue è il valore dell'odometro all'atto dell'immissione
del luogo.
Seconda generazione:
Oltre alla prima generazione, si usa il seguente componente:
entryGNSSPlaceRecord indica il luogo e l'ora registrati.
▼M3
2.117a. PositionAuthenticationStatus
Seconda generazione, versione 2:
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 173
Assegnazione valore (cfr. appendice 12):
«00»H Non autenticata (cfr. requisito GNS_39 dell’appendice
12),
«01»H Autenticata (cfr. requisito GNS_39 dell’appendice
12),
«02»H .. «FF»H RFU.
▼B
2.118. PreviousVehicleInfo
Informazioni relative al veicolo precedentemente usato da un conducente
all'atto dell'inserimento della carta in un'unità elettronica di bordo (requi­
sito 081 dell'allegato 1B e requisito 102 dell'allegato 1C).
Prima generazione:
vehicleRegistrationIdentification contiene il VRN e lo Stato membro di
immatricolazione del veicolo.
cardWithdrawalTime specifica la data e l'ora di estrazione della carta.
Seconda generazione:
Oltre alla prima generazione, è utilizzato il seguente elemento di dati:
vuGeneration identifica la generazione dell'unità elettronica di bordo.
2.119. PublicKey
Prima generazione:
Una chiave pubblica RSA.
rsaKeyModulus è il modulo della coppia di chiavi.
rsaKeyPublicExponent è l'esponente pubblico della coppia di chiavi.
2.120. RecordType
Seconda generazione:
Riferimento ad un tipo di registrazione. Questo tipo di dati è usato in
RecordArrays.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 174
Assegnazione valore:
► (1) M1
► (2) M3
ActivityChangeInfo,
CardSlotsStatus,
CurrentDateTime,
MemberStateCertificate,
OdometerValueMidnight,
DateOfDayDownloaded,
SensorPaired,
Signature,
SpecificConditionRecord,
VehicleIdentificationNumber,
VehicleRegistrationNumber,
VuCalibrationRecord,
VuCardIWRecord,
VuCardRecord,
VuCertificate,
VuCompanyLocksRecord,
VuControlActivityRecord,
VuDetailedSpeedBlock,
VuDownloadablePeriod,
VuDownloadActivityData,
VuEventRecord,
►M1 VuGNSSADRecord, ◄
VuITSConsentRecord,
VuFaultRecord,
VuIdentification,
VuOverSpeedingControlData,
VuOverSpeedingEventRecord,
VuPlaceDailyWorkPeriodRecord,
VuTimeAdjustmentGNSSRecord,
VuTimeAdjustmentRecord,
VuPowerSupplyInterruptionRecord,
SensorPairedRecord,
SensorExternalGNSSCoupledRecord,
►M3 VuBorderCrossingRecord,
VuLoadUnloadRecord,
VehicleRegistrationIdentification,
RFU, ◄
Specifico del fabbricante.
2.121. RegionAlpha
Codice numerico delle diverse regioni di un determinato paese.
Prima generazione:
Assegnazione valore:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 175
Seconda generazione:
I codici RegionAlpha devono figurare in un elenco pubblicato nel sito
Internet del laboratorio incaricato di effettuare le prove di interoperabi­
lità.
2.122. RegionNumeric
Codice numerico delle diverse regioni di un determinato paese.
Prima generazione:
Assegnazione valore:
Seconda generazione:
I codici RegionNumeric devono figurare in un elenco pubblicato nel sito
Internet del laboratorio incaricato di effettuare le prove di interoperabi­
lità.
2.123. RemoteCommunicationModuleSerialNumber
Seconda generazione:
Numero di serie del modulo di comunicazione remota.
2.124. RSAKeyModulus
Prima generazione:
Il modulo di una coppia di chiavi RSA.
Assegnazione valore: non specificato.
2.125. RSAKeyPrivateExponent
Prima generazione:
L'esponente privato di una coppia di chiavi RSA.
Assegnazione valore: non specificato.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 176
2.126. RSAKeyPublicExponent
Prima generazione:
L'esponente pubblico di una coppia di chiavi RSA.
Assegnazione valore: non specificato.
2.127. RtmData
Seconda generazione:
Per la definizione di questo tipo di dati, cfr. l'appendice 14.
2.128. SealDataCard
Seconda generazione:
Questo tipo di dati memorizza informazioni sui sigilli apposti ai diversi
componenti di un veicolo ed è destinato alla memorizzazione su una
carta. Questo tipo di dati si riferisce al requisito 337 dell'allegato 1C.
noOfSealRecords è il numero di registrazioni contenute in sealRecords.
sealRecords è una serie di registrazioni di sigilli.
2.129. SealDataVu
Seconda generazione:
Questo tipo di dati memorizza informazioni sui sigilli apposti ai diversi
componenti di un veicolo ed è destinato alla memorizzazione in una VU.
sealRecords è una serie di registrazioni di sigilli. Se sono presenti meno
di 5 sigilli, il valore di EquipmentType in tutti i sealRecords inutilizzati
deve essere impostato su 16, ossia «inutilizzato».
2.130. SealRecord
Seconda generazione:
Questo tipo di dati memorizza informazioni su un sigillo apposto ad un
componente. Questo tipo di dati si riferisce al requisito 337 dell'allegato 1C.
equipmentType identifica il tipo di apparecchio su cui è apposto il
sigillo.
extendedSealIdentifier è l'identificativo del sigillo apposto sull'apparec­
chio.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 177
2.131. SensorApprovalNumber
Numero di omologazione del sensore.
Prima generazione:
Assegnazione valore: non specificato.
Seconda generazione:
Assegnazione valore:
Il numero di omologazione deve corrispondere a quanto pubblicato sul
sito Internet della Commissione europea, vale a dire ad esempio com­
presi gli eventuali trattini. Il numero di omologazione deve essere alli­
neato a sinistra.
2.132. SensorExternalGNSSApprovalNumber
Seconda generazione:
Numero di omologazione del dispositivo GNSS esterno.
Assegnazione valore:
Il numero di omologazione deve corrispondere a quanto pubblicato sul
sito Internet della Commissione europea, vale a dire ad esempio com­
presi gli eventuali trattini. Il numero di omologazione deve essere alli­
neato a sinistra.
2.133. SensorExternalGNSSCoupledRecord
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative al­
l'identificazione del dispositivo GNSS esterno accoppiato all'unità elet­
tronica di bordo (requisito 100 dell'allegato 1C).
sensorSerialNumber è il numero di serie del dispositivo GNSS esterno
accoppiato all'unità elettronica di bordo.
sensorApprovalNumber è il numero di omologazione di questo dispo­
sitivo GNSS esterno.
sensorCouplingDate è una data di accoppiamento di questo dispositivo
GNSS esterno con l'unità elettronica di bordo.
2.134. SensorExternalGNSSIdentification
Seconda generazione:
Informazioni relative all'identificazione del dispositivo GNSS esterno
(requisito 98 dell'allegato 1C).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 178
sensorSerialNumber è il numero di serie completo del dispositivo
GNSS esterno.
sensorApprovalNumber è il numero di omologazione del dispositivo
GNSS esterno.
sensorSCIdentifier è l'identificativo del componente di sicurezza del
dispositivo GNSS esterno.
sensorOSIdentifier è l'identificativo del sistema operativo del disposi­
tivo GNSS esterno.
2.135. SensorExternalGNSSInstallation
Seconda generazione:
Informazioni, memorizzate in un dispositivo GNSS esterno, relative al­
l'installazione del sensore del dispositivo GNSS esterno (requisito 123
dell'allegato 1C).
sensorCouplingDateFirst è la data del primo accoppiamento del dispo­
sitivo GNSS esterno con un'unità elettronica di bordo.
firstVuApprovalNumber è il numero di omologazione della prima unità
elettronica di bordo accoppiata al dispositivo GNSS esterno.
firstVuSerialNumber è il numero di serie della prima unità elettronica
di bordo abbinata al dispositivo GNSS esterno.
sensorCouplingDateCurrent è la data dell'accoppiamento corrente del
dispositivo GNSS esterno con un'unità elettronica di bordo.
currentVuApprovalNumber è il numero di omologazione dell'unità
elettronica di bordo attualmente accoppiata al dispositivo GNSS esterno.
currentVuSerialNumber è il numero di serie dell'unità elettronica di
bordo attualmente accoppiata al dispositivo GNSS esterno.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 179
2.136. SensorExternalGNSSOSIdentifier
Seconda generazione:
L'identificativo del sistema operativo del dispositivo GNSS esterno.
Assegnazione valore: a cura del fabbricante.
2.137. SensorExternalGNSSSCIdentifier
Seconda generazione:
Questo tipo è utilizzato, ad esempio, per individuare il modulo critto­
grafico del dispositivo GNSS esterno.
Identificativo del componente di sicurezza del dispositivo GNSS esterno.
Assegnazione valore: a cura del fabbricante del componente.
2.138. SensorGNSSCouplingDate
Seconda generazione:
Data di accoppiamento del dispositivo GNSS esterno con un'unità elet­
tronica di bordo.
Assegnazione valore: non specificato.
2.139. SensorGNSSSerialNumber
Seconda generazione:
Questo tipo è utilizzato per memorizzare il numero di serie del ricevitore
GNSS sia quando è all'interno della VU che quando è esterno alla VU.
Numero di serie del ricevitore GNSS.
2.140. SensorIdentification
Informazioni, memorizzate in un sensore di movimento, relative all'iden­
tificazione del sensore stesso (requisito 077 dell'allegato 1B e requisito
95 dell'allegato 1C).
sensorSerialNumber è il numero di serie completo del sensore di mo­
vimento (comprende il codice componente e il codice del fabbricante).
sensorApprovalNumber è il numero di omologazione del sensore di
movimento.
sensorSCIdentifier è l'identificativo del componente di sicurezza del
sensore di movimento.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 180
sensorOSIdentifier è l'identificativo del sistema operativo del sensore di
movimento.
2.141. SensorInstallation
Informazioni, memorizzate in un sensore di movimento, relative all'in­
stallazione del sensore stesso (requisito 099 dell'allegato 1B e requisito
122 dell'allegato 1C).
sensorPairingDateFirst è la data del primo abbinamento del sensore di
movimento con un'unità elettronica di bordo.
firstVuApprovalNumber è il numero di omologazione della prima unità
elettronica di bordo abbinata al sensore di movimento.
firstVuSerialNumber è il numero di serie della prima unità elettronica
di bordo abbinata al sensore di movimento.
sensorPairingDateCurrent è la data dell'attuale abbinamento del sen­
sore di movimento con l'unità elettronica di bordo.
currentVuApprovalNumber è il numero di omologazione dell'unità
elettronica di bordo attualmente abbinata al sensore di movimento.
currentVUSerialNumber è il numero di serie dell'unità elettronica di
bordo attualmente abbinata al sensore di movimento.
2.142. SensorInstallationSecData
Informazioni, memorizzate in una carta dell'officina, relative ai dati di
sicurezza necessari per l'abbinamento dei sensori di movimento con le
unità elettroniche di bordo (requisiti 308 e 331 dell'allegato 1C).
Prima generazione:
Assegnazione valore: secondo ISO 16844-3.
Seconda generazione:
Come descritto nell'appendice 11, una carta dell'officina memorizza fino
a tre chiavi per l'abbinamento del sensore di movimento alla VU. Tali
chiavi hanno versioni diverse della chiave.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 181
2.143. SensorOSIdentifier
Identificativo del sistema operativo del sensore di movimento.
Assegnazione valore: a cura del fabbricante.
2.144. SensorPaired
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative al­
l'identificazione del sensore di movimento abbinato all'unità elettronica di
bordo (requisito 079 dell'allegato 1B).
sensorSerialNumber è il numero di serie del sensore di movimento
attualmente abbinato all'unità elettronica di bordo.
sensorApprovalNumber è il numero di omologazione del sensore di
movimento attualmente abbinato all'unità elettronica di bordo.
sensorPairingDateFirst è la data del primo abbinamento con un'unità
elettronica di bordo del sensore di movimento attualmente abbinato al­
l'unità elettronica di bordo.
2.145. SensorPairedRecord
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative al­
l'identificazione di un sensore di movimento abbinato all'unità elettronica
di bordo (requisito 97 dell'allegato 1C).
sensorSerialNumber è il numero di serie di un sensore di movimento
abbinato all'unità elettronica di bordo.
sensorApprovalNumber è il numero di omologazione di questo sensore
di movimento.
sensorPairingDate è una data di abbinamento di questo sensore di
movimento con l'unità elettronica di bordo.
2.146. SensorPairingDate
Data di abbinamento del sensore di movimento con un'unità elettronica
di bordo.
Assegnazione valore: non specificato.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 182
2.147. SensorSCIdentifier
Identificativo del componente di sicurezza del sensore di movimento.
Assegnazione valore: a cura del fabbricante del componente.
2.148. SensorSerialNumber
Numero di serie del sensore di movimento.
2.149. Signature
Una firma digitale.
Prima generazione:
Assegnazione valore: secondo l'appendice 11 (Meccanismi comuni di
sicurezza).
Seconda generazione:
Assegnazione valore: secondo l'appendice 11 (Meccanismi comuni di
sicurezza).
2.150. SignatureRecordArray
Seconda generazione:
una serie di firme più i metadati usati nel protocollo di trasferimento.
recordType rappresenta il tipo di registrazione (Signature). Assegna­
zione valore: Cfr. RecordType
recordSize sono le dimensioni di Signature in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni. Il
valore deve essere fissato a 1 perché le firme possono avere lunghezze
diverse.
records è la serie di firme.
2.151. SimilarEventsNumber
Il numero di anomalie simili in un determinato giorno (requisito 094
dell'allegato 1B e requisito 117 dell'allegato 1C).
Assegnazione valore: 0 non è utilizzato, 1 significa che, nel giorno in
questione, si è verificata ed è stata memorizzata una sola anomalia di un
dato tipo, 2 significa che si sono verificate 2 anomalie dello stesso tipo
(solo una è stata memorizzata), … 255 significa che si sono verificate
255 o più anomalie dello stesso tipo.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 183
2.152. SpecificConditionRecord
Informazioni, memorizzate in una carta del conducente, una carta del­
l'officina o un'unità elettronica di bordo, relative ad una condizione par­
ticolare (requisiti 130, 276, 301, 328 e 355 dell'allegato 1C).
entryTime specifica la data e l'ora di immissione.
specificConditionType è il codice che identifica la condizione
particolare.
2.153. SpecificConditions
Informazioni, memorizzate in una carta del conducente, una carta del­
l'officina o un'unità elettronica di bordo, relative ad una condizione par­
ticolare (requisiti 131, 277, 302, 329, e 356 dell'allegato 1C).
Seconda generazione:
conditionPointerNewestRecord è l'indice della registrazione più aggior­
nata della condizione particolare.
Assegnazione valore: numero corrispondente al numeratore della regi­
strazione della condizione particolare, a partire da ′0′ per la prima volta
in cui tale registrazione compare nella struttura.
specificConditionRecords è la serie di registrazioni contenenti le infor­
mazioni relative alle condizioni particolari registrate.
2.154. SpecificConditionType
Codice che identifica una condizione particolare (requisiti 050b, 105a,
212a e 230a dell'allegato 1B e requisito 62 dell'Allegato 1C).
Prima generazione:
Assegnazione valore:
«00»H RFU
«01»H Escluso dal campo di applicazione — Inizio
«02»H Escluso dal campo di applicazione — Fine
«03»H Attraversamento mediante traghetto/treno
«04»H .. «FFH» RFU
Seconda generazione:
Assegnazione valore:
«00»H RFU
«01»H Escluso dal campo di applicazione — Inizio
«02»H Escluso dal campo di applicazione — Fine
«03»H Attraversamento mediante traghetto/treno — Inizio
«04»H Attraversamento mediante traghetto/treno — Fine
«05»H .. «FF»H RFU
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 184
2.155. Velocità
Velocità del veicolo (km/h).
Assegnazione valore: chilometri all'ora nell'intervallo operativo 0-220
km/h.
2.156. SpeedAuthorised
Velocità massima autorizzata del veicolo [definizione hh)].
2.157. SpeedAverage
Velocità media in un periodo precedentemente definito (km/h).
2.158. SpeedMax
Velocità massima misurata in un periodo precedentemente definito.
▼M3
2.158a. TachographCardsGen1Suppression
Seconda generazione, versione 2:
capacità di una VU di seconda generazione di utilizzare carte del con­
ducente, di controllo e dell’azienda di prima generazione (cfr. requisito
MIG_002 dell’appendice 15).
Assegnazione valore:
«0000»H La VU è in grado di utilizzare carte tachigrafiche
di prima generazione (valore predefinito),
«A5E3»H La VU non è in grado di utilizzare carte tachi­
grafiche di prima generazione,
Tutti gli altri valori non utilizzato.
▼B
2.159. TachographPayload
Seconda generazione:
Per la definizione di questo tipo di dati, cfr. l'appendice 14.
▼M1
2.160. Riservato per uso futuro
▼B
2.161. TDesSessionKey
Prima generazione:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 185
Una chiave tripla di sessione DES.
Assegnazione valore: nessun'altra specificazione.
▼M1
2.162. TimeReal
Codice per un campo combinato di data e ora, in cui la data e l’ora sono
espresse in termini di secondi trascorsi a partire dalle 00h00min00s. del
1 o gennaio 1970 UTC.
Assegnazione valore - Allineato all’ottetto: numero di secondi trascorsi
a partire dalla mezzanotte del 1 o gennaio 1970 UTC.
La data/ora massima possibile è nell’anno 2106.
▼B
2.163. TyreSize
Indicazione delle dimensioni degli pneumatici.
Assegnazione valore: in conformità alla direttiva (CEE) 92/23 del
31.3.1992 (GU L 129, pag. 95).
2.164. VehicleIdentificationNumber
Numero di identificazione del veicolo (VIN) riferito al veicolo nel suo
insieme, di norma corrispondente al numero di serie o al numero del
telaio.
Assegnazione valore: secondo ISO 3779.
2.165. VehicleIdentificationNumberRecordArray
Seconda generazione:
Il numero di identificazione del veicolo più i metadati usati nel proto­
collo di trasferimento.
recordType rappresenta il tipo di registrazione (VehicleIdentification­
Number). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VehicleIdentificationNumber in byte.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 186
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è la serie di numeri di identificazione del veicolo.
2.166. VehicleRegistrationIdentification
Identificazione di un veicolo, univoca per l'Europa (VRN e Stato mem­
bro).
vehicleRegistrationNation è il paese in cui è stato immatricolato il
veicolo.
vehicleRegistrationNumber è il numero di immatricolazione del
veicolo (VRN).
▼M3
2.166a. VehicleRegistrationIdentificationRecordArray
Seconda generazione, versione 2:
il numero di immatricolazione del veicolo più i metadati usati nel pro­
tocollo di trasferimento dati.
recordType indica il tipo di registrazione (VehicleRegistrationIdentifi­
cation). Assegnazione valore: cfr. RecordType.
recordSize contiene le dimensioni di VehicleRegistrationIdentification
in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records contiene la serie di identificazioni di immatricolazione del
veicolo.
▼B
2.167. VehicleRegistrationNumber
Numero di immatricolazione del veicolo (VRN). Il numero di immatri­
colazione è assegnato dall'autorità competente.
codePage specifica una serie di caratteri quali definiti nel capitolo 4,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 187
vehicleRegNumber è un VRN codificato usando la serie specifica di
caratteri.
Assegnazione valore: a cura del paese.
2.168. VehicleRegistrationNumberRecordArray
▼M3
Seconda generazione, versione 1:
▼B
Il numero di immatricolazione del veicolo più i metadati usati nel pro­
tocollo di trasferimento.
recordType rappresenta il tipo di registrazione (VehicleRegistration­
Number). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VehicleRegistrationNumber in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è la serie di numeri di immatricolazione del veicolo.
2.169. VuAbility
Seconda generazione:
Informazioni memorizzate in una VU sulla capacità della VU di utiliz­
zare o meno carte tachigrafiche di prima generazione (requisito 121
dell'allegato 1C).
Assegnazione valore — Allineato all'ottetto: «xxxxxxxa»B (8 bit)
Per la capacità di supportare la prima generazione:
«a»B Capacità di supportare le carte tachigrafiche di prima
generazione:
«0» B la prima generazione è supportata,
«1» B la prima generazione non è supportata,
«xxxxxxx»B RFU
2.170. VuActivityDailyData
Prima generazione:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 188
Informazioni, memorizzate in una VU, relative ai cambi di attività e/o
alle variazioni della condizione di guida e/o alle variazioni della condi­
zione della carta in un determinato giorno di calendario (requisito 084
dell'allegato 1B e requisiti 105, 106 e 107 dell'allegato 1C) e della
condizione della sede (slot) alle 00h00 del giorno stesso.
noOfActivityChanges è il numero di parole (word) ActivityChangeInfo
nella serie activityChangeInfos.
activityChangeInfos è la serie di parole (word) ActivityChangeInfo
memorizzate nella VU il giorno in questione. Comprende sempre due
parole ActivityChangeInfo che indicano la condizione delle due sedi
(slot) alle 00h00 del giorno stesso.
2.171. VuActivityDailyRecordArray
Seconda generazione:
Informazioni, memorizzate in una VU, relative ai cambi di attività e/o
alle variazioni della condizione di guida e/o alle variazioni della condi­
zione della carta in un determinato giorno di calendario (requisiti 105,
106 e 107 dell'allegato 1C) e della condizione della sede (slot) alle
00h00 del giorno stesso.
recordType rappresenta il tipo di registrazione (ActivityChangeInfo).
Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di ActivityChangeInfo in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è la serie di parole (word) ActivityChangeInfo memorizzate
nella VU il giorno in questione. Comprende sempre due parole Activi­
tyChangeInfo che indicano la condizione delle due sedi (slot) alle 00h00
del giorno stesso.
2.172. VuApprovalNumber
Numero di omologazione dell'unità elettronica di bordo.
Prima generazione:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 189
Assegnazione valore: non specificato.
Seconda generazione:
Assegnazione valore:
Il numero di omologazione deve corrispondere a quanto pubblicato sul
sito Internet della Commissione europea, vale a dire ad esempio com­
presi gli eventuali trattini. Il numero di omologazione deve essere alli­
neato a sinistra.
2.173. VuCalibrationData
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alle
tarature dell'apparecchio di controllo (requisito 098 dell'allegato 1B).
noOfVuCalibrationRecords è il numero di registrazioni contenute nella
serie vuCalibrationRecords.
vuCalibrationRecords è la serie di registrazioni di tarature.
2.174. VuCalibrationRecord
Informazioni, memorizzate in un'unità elettronica di bordo, relative ad
una taratura dell'apparecchio di controllo (requisito 098 dell'allegato 1B
e requisiti 119 e 120 dell'allegato 1C).
Prima generazione:
calibrationPurpose è lo scopo della taratura.
workshopName, workshopAddress sono il nome e l'indirizzo dell'of­
ficina.
workshopCardNumber identifica la carta dell'officina usata durante la
taratura.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 190
workshopCardExpiryDate è la data di termine validità della carta.
vehicleIdentificationNumber è il VIN.
vehicleRegistrationIdentification contiene il VRN e lo Stato membro
di immatricolazione.
wVehicleCharacteristicConstant è il coefficiente caratteristico del
veicolo.
kConstantOfRecordingEquipment è la costante dell'apparecchio di
controllo.
lTyreCircumference è la circonferenza effettiva degli pneumatici delle
ruote.
tyreSize è l'indicazione delle dimensioni degli pneumatici montati sul
veicolo.
authorisedSpeed è la velocità autorizzata del veicolo.
oldOdometerValue, newOdometerValue sono i valori vecchio e nuovo
dell'odometro.
oldTimeValue, newTimeValue sono i valori vecchio e nuovo di data e
ora.
nextCalibrationDate è la data della prossima taratura del tipo specifi­
cato in CalibrationPurpose che dovrà essere effettuata dall'organismo
incaricato dei controlli.
▼M3
Seconda generazione, versione 1:
▼B
Oltre alla prima generazione, è utilizzato il seguente elemento di dati:
sealDataVu dà informazioni sui sigilli apposti a diversi componenti del
veicolo.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 191
Seconda generazione, versione 2:
Oltre alla prima generazione, è utilizzato il seguente elemento di dati:
sensorSerialNumber è il numero di serie del sensore di movimento
abbinato all’unità elettronica di bordo alla fine della taratura,
sensorGNSSSerialNumber è il numero di serie del dispositivo GNSS
esterno accoppiato all’unità elettronica di bordo alla fine dell’eventuale
taratura,
rcmSerialNumber è il numero di serie del dispositivo di comunicazione
remota accoppiato all’unità elettronica di bordo alla fine dell’eventuale
taratura,
sealDataVu dà informazioni sui sigilli apposti a diversi componenti del
veicolo,
byDefaultLoadType è il tipo di carico predefinito del veicolo (presente
solo nella versione 2),
calibrationCountry è il paese in cui è stata effettuata la taratura,
calibrationCountryTimestamp è la data e l’ora in cui il ricevitore
GNSS ha fornito la posizione utilizzata per determinare il paese in cui
è stata effettuata la taratura.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 192
2.175. VuCalibrationRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alle
tarature dell'apparecchio di controllo (requisiti 119 e 120 dell'allegato 1C).
recordType rappresenta il tipo di registrazione (VuCalibrationRecord).
Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuCalibrationRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è la serie di registrazioni di taratura.
2.176. VuCardIWData
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative ai
cicli di inserimento ed estrazione delle carte del conducente o delle carte
dell'officina nell'unità elettronica di bordo (requisito 081 dell'allegato 1B
e requisito 103 dell'allegato 1C).
noOfIWRecords è il numero di registrazioni nella serie vuCardIWRe­
cords.
vuCardIWRecords è una serie di registrazioni relative ai cicli di inse­
rimento ed estrazione della carta.
2.177. VuCardIWRecord
Informazioni, memorizzate in un'unità elettronica di bordo, relative ad
un ciclo di inserimento ed estrazione di una carta del conducente o di
una carta dell'officina nell'unità elettronica di bordo (requisito 081 del­
l'allegato 1B e requisito 102 dell'allegato 1C).
Prima generazione:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 193
cardHolderName contiene il cognome e il nome o i nomi del titolare
della carta del conducente o dell'officina memorizzati nella carta.
fullCardNumber specifica il tipo di carta, lo Stato membro di rilascio e
il numero della carta memorizzati nella carta stessa.
cardExpiryDate è la data di termine validità della carta memorizzata
nella carta stessa.
cardInsertionTime specifica la data e l'ora di inserimento.
vehicleOdometerValueAtInsertion è il valore dell'odometro del veicolo
all'atto dell'inserimento della carta.
cardSlotNumber è la sede (slot) in cui è inserita la carta.
cardWithdrawalTime specifica la data e l'ora di estrazione.
vehicleOdometerValueAtWithdrawal è il valore dell'odometro del vei­
colo all'atto dell'estrazione della carta.
previousVehicleInfo contiene informazioni, memorizzate nella carta,
relative al veicolo precedentemente utilizzato dal conducente.
manualInputFlag è un indicatore (flag) che indica se, all'atto dell'inse­
rimento della carta, il titolare della carta abbia o meno inserito manual­
mente le attività del conducente.
Seconda generazione:
Anziché fullCardNumber la struttura dei dati della seconda generazione
usa il seguente elemento di dati.
fullCardNumberAndGeneration specifica il tipo di carta, lo Stato
membro di rilascio e il numero e la generazione della carta memorizzati
nella carta stessa.
2.178. VuCardIWRecordArray
Seconda generazione:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 194
Informazioni, memorizzate in un'unità elettronica di bordo, relative ai cicli
di inserimento ed estrazione delle carte del conducente o delle carte del­
l'officina nell'unità elettronica di bordo (requisito 103 dell'allegato 1C).
recordType rappresenta il tipo di registrazione (VuCardIWRecord). As­
segnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuCardIWRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni relative ai cicli di inserimento ed
estrazione della carta.
▼M1
2.179. VuCardRecord
Seconda generazione:
Informazioni, memorizzate in un’unità elettronica di bordo, relative ad
una carta tachigrafica utilizzata (requisito 132 dell’allegato IC).
cardNumberAndGenerationInformation indica il numero completo e
la generazione della carta utilizzata (tipo di dati 2.74).
cardExtendedSerialNumber quale letto nel file EF_ICC contenuto nel
MF della carta.
cardStructureVersion quale letta nel file EF_Application_Identification
contenuto nel DF_Tachograph_G2.
cardNumber quale letto nel file EF_Identification contenuto nel DF_Ta­
chograph_G2.
▼B
2.180. VuCardRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alle
carte tachigrafiche utilizzate con tale unità elettronica di bordo. Questa
informazione è destinata all'analisi dei problemi tra la VU e la carta
(requisito 132 dell'allegato 1C).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 195
recordType rappresenta il tipo di registrazione (VuCardRecord). Asse­
gnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuCardRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni relative alle carte tachigrafiche usate
con la VU.
2.181. VuCertificate
Certificato della chiave pubblica di un'unità elettronica di bordo.
2.182. VuCertificateRecordArray
Seconda generazione:
Il certificato della VU più i metadati usati nel protocollo di
trasferimento.
recordType rappresenta il tipo di registrazione (VuCertificate). Asse­
gnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuCertificate in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni. Il
valore deve essere fissato a 1 perché i certificati possono avere lun­
ghezze diverse.
records è una serie di certificati della VU.
2.183. VuCompanyLocksData
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative ai
blocchi di un'impresa (requisito 104 dell'allegato 1B).
noOfLocks è il numero di blocchi elencati in vuCompanyLocksRecords.
vuCompanyLocksRecords è la serie di registrazioni dei blocchi di
un'impresa.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 196
2.184. VuCompanyLocksRecord
Informazioni, memorizzate in un'unità elettronica di bordo, relative ad
un blocco di un'impresa (requisito 104 dell'allegato 1B e requisito 128
dell'allegato 1C).
Prima generazione:
lockInTime, lockOutTime specificano la data e l'ora di attivazione e di
disattivazione del blocco.
companyName, companyAddress specificano il nome e l'indirizzo del­
l'impresa connessa all'attivazione del blocco.
companyCardNumber identifica la carta usata all'atto dell'attivazione
del blocco.
Seconda generazione:
Anziché companyCardNumber la struttura dei dati della seconda gene­
razione usa il seguente elemento di dati.
companyCardNumberAndGeneration identifica la carta, compresa la
generazione, usata all'atto dell'attivazione del blocco.
2.185. VuCompanyLocksRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative ai
blocchi di un'impresa (requisito 128 dell'allegato 1C).
recordType rappresenta il tipo di registrazione (VuCompanyLocksRe­
cord). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuCompanyLocksRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
Valore 0..255.
records è la serie di registrazioni dei blocchi di un'impresa.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 197
2.185a. VuConfigurationLengthRange
Seconda generazione, versione 2:
numero di byte in una carta tachigrafica, disponibile per memorizzare le
configurazioni della VU.
Assegnazione valore: cfr. appendice 2.
▼B
2.186. VuControlActivityData
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative ai
controlli eseguiti utilizzando tale VU (requisito 102 dell'allegato 1B).
noOfControls è il numero di controlli elencati in vuControlActivityRe­
cords.
vuControlActivityRecords è la serie di registrazioni di attività di
controllo.
2.187. VuControlActivityRecord
Informazioni, memorizzate in un'unità elettronica di bordo, relative ad
un controllo eseguito utilizzando tale VU (requisito 102 dell'allegato 1B
e requisito 126 dell'allegato 1C).
Prima generazione:
controlType è il tipo di controllo.
controlTime sono la data e l'ora del controllo.
controlCardNumber identifica la carta di controllo usata per il
controllo.
downloadPeriodBeginTime è l'ora di inizio del periodo cui si riferi­
scono i dati trasferiti, in caso di trasferimento.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 198
downloadPeriodEndTime è l'ora di fine del periodo cui si riferiscono i
dati trasferiti, in caso di trasferimento.
Seconda generazione:
Anziché controlCardNumber la struttura dei dati della seconda genera­
zione usa il seguente elemento di dati.
controlCardNumberAnd Generation identifica la carta di controllo,
compresa la generazione, usata per il controllo.
2.188. VuControlActivityRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative ai
controlli eseguiti utilizzando tale VU (requisito 126 dell'allegato 1C).
recordType rappresenta il tipo di registrazione (VuControlActivityRe­
cord). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuControlActivityRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è la serie di registrazioni delle attività di controllo della VU.
2.189. VuDataBlockCounter
Contatore, memorizzato in una carta, che indica in ordine di sequenza i
cicli di inserimento ed estrazione della carta nelle unità elettroniche di
bordo.
Assegnazione valore: numero consecutivo con valore massimo 9 999,
dopodiché la numerazione ricomincia da 0.
2.190. VuDetailedSpeedBlock
Informazioni, memorizzate in un'unità elettronica di bordo, relative alla
velocità dettagliata del veicolo per un minuto di marcia del veicolo
(requisito 093 dell'allegato 1B e requisito 116 dell'allegato 1C).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 199
speedBlockBeginDate specifica la data e l'ora del primo valore di ve­
locità all'interno del blocco.
speedsPerSecond è la sequenza cronologica della velocità misurata ogni
secondo durante il minuto che comincia da speedBlockBeginDate (in­
clusa).
2.191. VuDetailedSpeedBlockRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alla
velocità dettagliata del veicolo.
recordType rappresenta il tipo di registrazione (VuDetailedSpeed­
Block). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuDetailedSpeedBlock in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è la serie di blocchi di velocità dettagliata.
2.192. VuDetailedSpeedData
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alla
velocità dettagliata del veicolo.
noOfSpeedBlocks è il numero di blocchi di velocità nella serie vuDe­
tailedSpeedBlocks.
vuDetailedSpeedBlocks è la serie di blocchi di velocità dettagliata.
▼M3
2.192a. VuDigitalMapVersion
Seconda generazione, versione 2:
versione della mappa digitale memorizzata nell’unità elettronica di bordo
(requisito 133 undecies dell’allegato IC).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 200
Assegnazione valore: come specificato nell’apposito sito web protetto
messo a disposizione dalla Commissione europea (requisito 133 duode­
cies dell’allegato IC).
▼B
2.193. VuDownloadablePeriod
Le date meno recente e più recente per le quali un'unità elettronica di
bordo conserva i dati relativi alle attività dei conducenti (requisiti 081,
084 o 087 dell'allegato 1B e requisiti 102, 105, 108 dell'allegato 1C).
minDownloadableTime specifica la data e l'ora meno recenti di inseri­
mento della carta o di cambio di attività o di immissione del luogo
memorizzate nella VU.
maxDownloadableTime specifica la data e l'ora più recenti di estra­
zione della carta o di cambio di attività o di immissione del luogo
memorizzate nella VU.
2.194. VuDownloadablePeriodRecordArray
Seconda generazione:
Il VUDownloadablePeriod più i metadati usati nel protocollo di
trasferimento.
recordType rappresenta il tipo di registrazione (VuDownloadablePe­
riod). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuDownloadablePeriod in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è la serie di registrazioni del VuDownloadablePeriod.
2.195. VuDownloadActivityData
Informazioni, memorizzate in un'unità elettronica di bordo, relative al­
l'ultimo trasferimento dei suoi dati (requisito 105 dell'allegato 1B e
requisito 129 dell'allegato 1C).
Prima generazione:
downloadingTime specifica la data e l'ora del trasferimento di dati.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 201
fullCardNumber identifica la carta usata per autorizzare il trasferimento
di dati.
companyOrWorkshopName è il nome dell'impresa o dell'officina.
Seconda generazione:
Anziché fullCardNumber la struttura dei dati della seconda generazione
usa il seguente elemento di dati.
fullCardNumberAnd Generation identifica la carta, compresa la gene­
razione, usata per autorizzare il trasferimento di dati.
2.196. VuDownloadActivityDataRecordArray
Seconda generazione:
Informazioni relative all'ultimo trasferimento di dati della VU (requisito
129 dell'allegato 1C).
recordType rappresenta il tipo di registrazione (VuDownloadActivity­
Data). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuDownloadActivityData in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è la serie di registrazioni dei dati relativi al trasferimento.
2.197. VuEventData
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alle
anomalie (requisito 094 dell'allegato 1B eccetto per il superamento di
velocità).
noOfVuEvents è il numero di anomalie elencate nella serie vuEven­
tRecords.
vuEventRecords è una serie di registrazioni di anomalie.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 202
2.198. VuEventRecord
Informazioni, memorizzate in un'unità elettronica di bordo, relative ad
un'anomalia (requisito 094 dell'allegato 1B e requisito 117 dell'allegato
1C, eccetto per il superamento di velocità).
Prima generazione:
eventType è il tipo di anomalia.
eventRecordPurpose è lo scopo per cui è stata registrata l'anomalia.
eventBeginTime specifica la data e l'ora di inizio dell'anomalia.
eventEndTime specifica la data e l'ora di fine dell'anomalia.
cardNumberDriverSlotBegin identifica la carta inserita nella sede (slot)
del conducente all'inizio dell'anomalia.
cardNumberCodriverSlotBegin identifica la carta inserita nella sede
(slot) del secondo conducente all'inizio dell'anomalia.
cardNumberDriverSlotEnd identifica la carta inserita nella sede (slot)
del conducente al termine dell'anomalia.
cardNumberCodriverSlotEnd identifica la carta inserita nella sede
(slot) del secondo conducente al termine dell'anomalia.
similarEventsNumber è il numero di anomalie analoghe verificatesi nel
giorno in questione.
Questa sequenza si può usare per tutte le anomalie, eccetto quelle rela­
tive al superamento di velocità.
Seconda generazione:
Oltre alla prima generazione, sono utilizzati i seguenti elementi di dati:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 203
manufacturerSpecificEventFaultData contiene ulteriori informazioni
specifiche del fabbricante relative all'anomalia.
Anziché cardNumberDriverSlotBegin, cardNumberCodriverSlotBegin,
cardNumberDriverSlotEnd e cardNumberCodriverSlotEnd, la struttura
dei dati della seconda generazione usa i seguenti elementi di dati:
cardNumberAndGenDriverSlotBegin identifica la carta, compresa la
generazione, inserita nella sede (slot) del conducente all'inizio dell'ano­
malia.
cardNumberAndGenCodriverSlotBegin identifica la carta, compresa
la generazione, inserita nella sede (slot) del secondo conducente all'ini­
zio dell'anomalia.
cardNumberAndGenDriverSlotEnd identifica la carta, compresa la
generazione, inserita nella sede (slot) del conducente al termine dell'ano­
malia.
cardNumberAndGenCodriverSlotEnd identifica la carta, compresa la
generazione, inserita nella sede (slot) del secondo conducente al termine
dell'anomalia.
Se l'anomalia è un conflitto di orari, l'eventBeginTime e l'eventEndTime
devono essere interpretati come segue:
eventBeginTime specifica la data e l'ora dell'apparecchio di controllo.
eventEndTime specifica la data e l'ora del GNSS.
2.199. VuEventRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alle
anomalie (requisito 117 dell'allegato 1C eccetto per il superamento di
velocità).
recordType rappresenta il tipo di registrazione (VuEventRecord). Asse­
gnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuEventRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni di anomalie.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 204
2.200. VuFaultData
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative ai
guasti (requisito 096 dell'allegato 1B).
noOfVuFaults è il numero di guasti elencati nella serie vuFaultRecords.
vuFaultRecords è una serie di registrazioni di guasti.
2.201. VuFaultRecord
Informazioni, memorizzate in un'unità elettronica di bordo, relative ad un
guasto (requisito 096 dell'allegato 1B e requisito 118 dell'allegato 1C).
Prima generazione:
faultType è il tipo di guasto dell'apparecchio di controllo.
faultRecordPurpose è lo scopo per cui è stato registrato il guasto.
faultBeginTime specifica la data e l'ora di inizio del guasto.
faultEndTime specifica la data e l'ora di fine del guasto.
cardNumberDriverSlotBegin identifica la carta inserita nella sede (slot)
del conducente all'inizio del guasto.
cardNumberCodriverSlotBegin identifica la carta inserita nella sede
(slot) del secondo conducente all'inizio del guasto.
cardNumberDriverSlotEnd identifica la carta inserita nella sede (slot)
del conducente al termine del guasto.
cardNumberCodriverSlotEnd identifica la carta inserita nella sede
(slot) del secondo conducente al termine del guasto.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 205
Seconda generazione:
Oltre alla prima generazione, è utilizzato il seguente elemento di dati:
manufacturerSpecificEventFaultData contiene ulteriori informazioni
specifiche del fabbricante relative al guasto.
Anziché cardNumberDriverSlotBegin, cardNumberCodriverSlotBegin,
cardNumberDriverSlotEnd e cardNumberCodriverSlotEnd, la struttura
dei dati della seconda generazione usa i seguenti elementi di dati:
cardNumberAndGenDriverSlotBegin identifica la carta, compresa la
generazione, inserita nella sede (slot) del conducente all'inizio del
guasto.
cardNumberAndGenCodriverSlotBegin identifica la carta, compresa
la generazione, inserita nella sede (slot) del secondo conducente all'ini­
zio del guasto.
cardNumberAndGenDriverSlotEnd identifica la carta, compresa la
generazione, inserita nella sede (slot) del conducente al termine del
guasto.
cardNumberAndGenCodriverSlotEnd identifica la carta, compresa la
generazione, inserita nella sede (slot) del secondo conducente al termine
del guasto.
2.202. VuFaultRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative ai
guasti (requisito 118 dell'allegato 1C).
recordType rappresenta il tipo di registrazione (VuFaultRecord). Asse­
gnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuFaultRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni di guasti.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 206
2.203. VuGNSSADRecord
▼M3
Seconda generazione, versione 1:
▼M1
Informazioni, memorizzate in un’unità elettronica di bordo, relative alla
posizione del veicolo rilevata dal GNSS, se il periodo di guida cumu­
lativo raggiunge un multiplo di tre ore (requisiti 108 e 110
dell’allegato IC).
timeStamp indica la data e l’ora in cui il periodo di guida cumulativo
raggiunge un multiplo di tre ore.
cardNumberAndGenDriverSlot identifica la carta, compresa la gene­
razione, inserita nella sede (slot) del conducente.
cardNumberAndGenCodriverSlot identifica la carta, compresa la ge­
nerazione, inserita nella sede (slot) del secondo conducente.
gnssPlaceRecord contiene informazioni relative alla posizione del
veicolo.
vehicleOdometerValue è il valore odometrico del momento in cui il
periodo di guida cumulativo raggiunge un multiplo di tre ore.
▼M3
Seconda generazione, versione 2:
informazioni, memorizzate in un’unità elettronica di bordo, relative alla
posizione GNSS del veicolo, se il periodo di guida cumulativo rag­
giunge un multiplo di tre ore (requisiti 108 e 110 dell’allegato IC).
Nella seconda generazione, versione 2, invece di gnssPlaceRecord, si
usa gnssPlaceAuthRecord, che contiene anche lo status di autenticazione
GNSS.
2.203a. VuBorderCrossingRecord
Seconda generazione, versione 2:
informazioni, memorizzate in una unità elettronica di bordo, relative agli
attraversamenti di frontiera del veicolo quando quest’ultimo ha attraver­
sato la frontiera di un paese (requisiti 133 bis e 133 ter dell’allegato IC).
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 207
cardNumberAndGenDriverSlot identifica la carta, compresa la gene­
razione, inserita nella sede (slot) del conducente.
cardNumberAndGenCodriverSlot identifica la carta, compresa la ge­
nerazione, inserita nella sede (slot) del secondo conducente.
countryLeft è il paese lasciato dal veicolo, sulla base dell’ultima posi­
zione disponibile prima del rilevamento dell’attraversamento di frontiera.
«Resto del mondo» (codice NationNumeric «FF»H) deve essere utiliz­
zato quando l’unità elettronica di bordo non è in grado di determinare il
paese in cui si trova il veicolo (ad esempio, il paese in cui si trova il
veicolo in quel momento non è compreso nelle mappe digitali memo­
rizzate).
countryEntered è il paese in cui il veicolo è entrato. «Resto del
mondo» (codice NationNumeric «FF»H) deve essere utilizzato quando
l’unità elettronica di bordo non è in grado di determinare il paese in cui
si trova il veicolo (ad esempio, il paese in cui si trova il veicolo in quel
momento non è compreso nelle mappe digitali memorizzate).
gnssPlaceAuthRecord contiene informazioni relative alla posizione del
veicolo al momento del rilevamento dell’attraversamento di frontiera, e
al suo stato di autenticazione.
vehicleOdometerValue è il valore dell’odometro quando l’unità elettro­
nica di bordo ha rilevato che il veicolo ha attraversato la frontiera di un
paese.
2.203b. VuBorderCrossingRecordArray
Seconda generazione, versione 2:
informazioni, memorizzate in un’unità elettronica di bordo, relative agli
attraversamenti di frontiera del veicolo (requisito 133 quater
dell’allegato IC).
recordType indica il tipo di registrazione (VuBorderCrossingRecord).
Assegnazione valore: cfr. RecordType.
recordSize contiene le dimensioni di VuBorderCrossingRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records contiene una serie di registrazioni di attraversamenti di frontiera.
▼M1
2.204. VuGNSSADRecordArray
Seconda generazione:
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 208
Informazioni, memorizzate in un’unità elettronica di bordo, relative alla
posizione del veicolo rilevata dal GNSS, se il periodo di guida cumu­
lativo raggiunge un multiplo di tre ore (requisiti 108 e 110
dell’allegato IC).
recordType rappresenta il tipo di registrazione (VuGNSSADRecord).
Assegnazione valore: cfr. RecordType.
recordSize sono le dimensioni di VuGNSSADRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni di guida cumulativa rilevata dal
GNSS.
▼M3
2.204a. VuGnssMaximalTimeDifference
Seconda generazione, versione 2:
la differenza massima tra l’ora effettiva e quella dell’orologio in tempo
reale della VU, sulla base dello sfasamento massimo dell’ora di cui al
requisito 041 dell’allegato IC, trasmessa dall’unità elettronica di bordo a
un dispositivo GNSS esterno, cfr. il requisito GNS_3g dell’appen­
dice 12.
▼B
2.205. VuIdentification
Informazioni, memorizzate in un'unità elettronica di bordo, relative al­
l'identificazione dell'unità stessa (requisito 075 dell'allegato 1B e requi­
siti 93 e 121 dell'allegato 1C).
Prima generazione:
vuManufacturerName è il nome del fabbricante dell'unità elettronica di
bordo.
vuManufacturerAddress è l'indirizzo del fabbricante dell'unità elettro­
nica di bordo.
vuPartNumber è il codice componente dell'unità elettronica di bordo.
vuSerialNumber è il numero di serie dell'unità elettronica di bordo.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 209
vuSoftwareIdentification identifica il software installato nell'unità elet­
tronica di bordo.
vuManufacturingDate è la data di fabbricazione dell'unità elettronica di
bordo.
vuApprovalNumber è il numero di omologazione dell'unità elettronica
di bordo.
▼M3
Seconda generazione:
Oltre alla prima generazione, sono utilizzati i seguenti elementi di dati:
vuGeneration identifica la generazione dell’unità elettronica di bordo.
vuAbility fornisce informazioni in merito al fatto che la VU supporti o
no le carte tachigrafiche di prima generazione.
vuDigitalMapVersion è la versione della mappa digitale memorizzata
nell’unità elettronica di bordo (presente solo nella versione 2).
▼B
2.206. VuIdentificationRecordArray
Seconda generazione:
La VuIdentification più i metadati usati nel protocollo di trasferimento.
recordType rappresenta il tipo di registrazione (VuIdentification). Asse­
gnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuIdentification in byte.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 210
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni di VuIdentification.
2.207. VuITSConsentRecord
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative al
consenso di un conducente ad utilizzare sistemi di trasporto intelligenti.
cardNumberAndGen identifica la carta, compresa la generazione. Deve
essere una carta del conducente o una carta dell'officina.
consent è un indicatore (flag) che indica se il conducente ha dato il suo
consenso all'uso di sistemi di trasporto intelligenti con questo veicolo o
con questa unità elettronica di bordo.
Assegnazione valore:
VERO indica il consenso del conducente ad utilizzare sistemi di
trasporto intelligenti
FALSO indica il rifiuto del conducente ad utilizzare sistemi di tra­
sporto intelligenti
2.208. VuITSConsentRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative al
consenso del conducente ad utilizzare sistemi di trasporto intelligenti
(requisito 200 dell'allegato 1C).
recordType rappresenta il tipo di registrazione (VuITSConsentRecord).
Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuITSConsentRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è la serie di registrazioni dei consensi ad utilizzare ITS.
▼M3
2.208a. VuLoadUnloadRecord
Seconda generazione, versione 2:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 211
informazioni, memorizzate nell’unità elettronica di bordo, relative a
un’operazione di carico/scarico immessa (requisiti 133 sexies, 133 sep­
ties e 133 octies dell’allegato IC).
timeStamp è la data e l’ora in cui è stata immessa l’operazione di
carico/scarico.
operationType è il tipo di operazione immessa (carico, scarico o carico/
scarico simultanei),
cardNumberAndGenDriverSlot identifica la carta, compresa la gene­
razione, inserita nella sede (slot) del conducente.
cardNumberAndGenCodriverSlot identifica la carta, compresa la ge­
nerazione, inserita nella sede (slot) del secondo conducente.
gnssPlaceAuthRecord contiene informazioni relative alla posizione del
veicolo e al suo stato di autenticazione.
vehicleOdometerValue è il valore dell’odometro relativo all’operazione
di carico/scarico.
2.208b. VuLoadUnloadRecordArray
Seconda generazione, versione 2:
informazioni, memorizzate nell’unità elettronica di bordo, relative a
un’operazione di carico/scarico (requisito 133 nonies dell’allegato IC).
recordType indica il tipo di registrazione (VuLoadUnloadRecord). As­
segnazione valore: cfr. RecordType.
recordSize contiene le dimensioni di VuLoadUnloadRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records contiene una serie di registrazioni di operazioni di carico/sca­
rico.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 212
2.209. VuManufacturerAddress
Indirizzo del fabbricante dell'unità elettronica di bordo.
Assegnazione valore: non specificato.
2.210. VuManufacturerName
Nome del fabbricante dell'unità elettronica di bordo.
Assegnazione valore: non specificato.
2.211. VuManufacturingDate
Data di fabbricazione dell'unità elettronica di bordo.
Assegnazione valore: non specificato.
2.212. VuOverSpeedingControlData
Informazioni, memorizzate in un'unità elettronica di bordo, relative alle
anomalie per superamento di velocità verificatesi dopo l'ultimo controllo
del superamento di velocità (requisito 095 dell'allegato 1B e requisito
117 dell'allegato 1C).
lastOverspeedControlTime specifica la data e l'ora dell'ultimo controllo
del superamento di velocità.
firstOverspeedSince specifica la data e l'ora del primo superamento di
velocità dopo tale controllo del superamento di velocità.
numberOfOverspeedSince è il numero di anomalie per superamento di
velocità verificatesi dopo l'ultimo controllo del superamento di velocità.
2.213. VuOverSpeedingControlDataRecordArray
Seconda generazione:
I VuOverSpeedingControlData più i metadati usati nel protocollo di
trasferimento.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 213
recordType rappresenta il tipo di registrazione (VuOverSpeedingCon­
trolData). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuOverSpeedingControlData in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni dei dati di controllo del superamento
di velocità.
2.214. VuOverSpeedingEventData
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alle
anomalie per superamento di velocità (requisito 094 dell'allegato 1B).
noOfVuOverSpeedingEvents è il numero di anomalie elencate nella
serie vuOverSpeedingEventRecords.
vuOverSpeedingEventRecords è una serie di registrazioni di anomalie
per superamento di velocità.
2.215. VuOverSpeedingEventRecord
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative ad
anomalie per superamento di velocità (requisito 094 dell'allegato 1B e
requisito 117 dell'allegato 1C).
eventType è il tipo di anomalia.
eventRecordPurpose è lo scopo per cui è stata registrata l'anomalia.
eventBeginTime specifica la data e l'ora di inizio dell'anomalia.
eventEndTime specifica la data e l'ora di fine dell'anomalia.
maxSpeedValue è la velocità massima misurata durante l'anomalia.
averageSpeedValue è la media aritmetica della velocità misurata du­
rante l'anomalia.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 214
cardNumberDriverSlotBegin identifica la carta inserita nella sede (slot)
del conducente all'inizio dell'anomalia.
similarEventsNumber è il numero di anomalie analoghe verificatesi nel
giorno in questione.
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative ad
anomalie per superamento di velocità (requisito 094 dell'allegato 1B e
requisito 117 dell'allegato 1C).
Anziché cardNumberDriverSlotBegin la struttura dei dati della seconda
generazione usa il seguente elemento di dati.
cardNumberAndGenDriverSlotBegin identifica la carta, compresa la
generazione, inserita nella sede (slot) «conducente» all'inizio dell'anoma­
lia.
2.216. VuOverSpeedingEventRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alle
anomalie per superamento di velocità (requisito 117 dell'allegato 1C).
recordType rappresenta il tipo di registrazione (VuOverSpeedingEven­
tRecord). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuOverSpeedingEventRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni di anomalie per superamento di
velocità.
2.217. VuPartNumber
Codice componente dell'unità elettronica di bordo.
Assegnazione valore: a cura del fabbricante della VU.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 215
2.218. VuPlaceDailyWorkPeriodData
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative ai
luoghi in cui i conducenti iniziano o terminano un periodo di lavoro
giornaliero (requisito 087 dell'allegato 1B e requisiti 108 e 110 dell'al­
legato 1C).
noOfPlaceRecords è il numero di registrazioni elencate nella serie vu­
PlaceDailyWorkPeriodRecords.
vuPlaceDailyWorkPeriodRecords è una serie di registrazioni relative ai
luoghi.
2.219. VuPlaceDailyWorkPeriodRecord
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative al
luogo in cui il conducente inizia o termina un periodo di lavoro gior­
naliero (requisito 087 dell'allegato 1B e requisiti 108 e 110 dell'allegato
1C).
fullCardNumber specifica il tipo di carta del conducente, lo Stato
membro di rilascio e il numero della carta.
placeRecord contiene le informazioni relative al luogo inserito.
▼M3
Seconda generazione, versione 1:
▼B
Informazioni, memorizzate in un'unità elettronica di bordo, relative al
luogo in cui il conducente inizia o termina un periodo di lavoro giornaliero
(requisito 087 dell'allegato 1B e requisiti 108 e 110 dell'allegato 1C).
Anziché fullCardNumber la struttura dei dati della seconda generazione
usa il seguente elemento di dati:
fullCardNumberAndGeneration specifica il tipo di carta, lo Stato
membro di rilascio e il numero e la generazione della carta memorizzati
nella carta stessa.
▼M3
Seconda generazione, versione 2:
informazioni, memorizzate in un’unità elettronica di bordo, relative al
luogo in cui il conducente inizia o termina un periodo di lavoro gior­
naliero (requisito 087 dell’allegato 1B e requisiti 108 e 110 dell’alle­
gato 1C).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 216
Anziché placeRecord, la struttura dei dati della seconda generazione,
versione 2, usa il seguente elemento di dati:
placeAuthRecord contiene le informazioni relative al luogo inserito,
alla posizione registrata, allo stato di autenticazione GNSS e al tempo
di determinazione della posizione.
▼B
2.220. VuPlaceDailyWorkPeriodRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative ai
luoghi in cui i conducenti iniziano o terminano un periodo di lavoro
giornaliero (requisiti 108 e 110 dell'allegato 1C).
recordType rappresenta il tipo di registrazione (VuPlaceDailyWorkPe­
riodRecord). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuPlaceDailyWorkPeriodRecord in
byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni relative ai luoghi.
2.221. VuPrivateKey
Prima generazione:
La chiave privata di un'unità elettronica di bordo.
2.222. VuPublicKey
Prima generazione:
La chiave pubblica di un'unità elettronica di bordo.
▼M3
2.222a. VuRtcTime
Seconda generazione, versione 2:
l’ora dell’orologio RTC della VU, trasmesso dalla VU a un dispositivo
GNSS esterno, cfr. il requisito GNS_3f dell’appendice 12.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 217
2.223. VuSerialNumber
Numero di serie dell'unità elettronica di bordo (requisito 075 dell'alle­
gato 1B e requisito 93 dell'allegato 1C).
2.224. VuSoftInstallationDate
Data di installazione del software dell'unità elettronica di bordo.
Assegnazione valore: non specificato.
2.225. VuSoftwareIdentification
Informazioni, memorizzate in un'unità elettronica di bordo, relative al
software installato.
vuSoftwareVersion è il numero della versione del software dell'unità
elettronica di bordo.
vuSoftInstallationDate è la data di installazione del software.
2.226. VuSoftwareVersion
Numero della versione del software dell'unità elettronica di bordo.
Assegnazione valore: non specificato.
2.227. VuSpecificConditionData
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative a
condizioni particolari.
noOfSpecificConditionRecords è il numero di registrazioni elencate
nella serie specificConditionRecords.
specificConditionRecords è una serie di registrazioni relative a condi­
zioni particolari.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 218
2.228. VuSpecificConditionRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative a
condizioni particolari (requisito 130 dell'allegato 1C).
recordType rappresenta il tipo di registrazione (SpecificConditionRe­
cord). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di SpecificConditionRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni relative a condizioni particolari.
2.229. VuTimeAdjustmentData
Prima generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alle
regolazioni dell'ora effettuate al di fuori di un ciclo ordinario di taratura
(requisito 101 dell'allegato 1B).
noOfVuTimeAdjRecords è il numero di registrazioni contenute in vu­
TimeAdjustmentRecords.
vuTimeAdjustmentRecords è una serie di registrazioni di regolazioni
dell'ora.
▼M1
2.230. Riservato per uso futuro
2.231. Riservato per uso futuro
▼B
2.232. VuTimeAdjustmentRecord
Informazioni, memorizzate in un'unità elettronica di bordo, relative ad
una regolazione dell'ora effettuata al di fuori di un ciclo ordinario di
taratura (requisito 101 dell'allegato 1B e requisiti 124 e 125 dell'allegato
1C).
Prima generazione:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 219
oldTimeValue, newTimeValue sono i valori vecchio e nuovo di data e
ora.
workshopName, workshopAddress sono il nome e l'indirizzo dell'of­
ficina.
workshopCardNumber identifica la carta dell'officina utilizzata per
effettuare la regolazione dell'ora.
Seconda generazione:
Anziché workshopCardNumber, la struttura dei dati della seconda gene­
razione usa il seguente elemento di dati.
workshopCardNumberAnd Generation identifica la carta dell'officina,
compresa la generazione, utilizzata per effettuare la regolazione dell'ora.
2.233. VuTimeAdjustmentRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alle
regolazioni dell'ora effettuate al di fuori di un ciclo ordinario di taratura
(requisiti 124 e 125 dell'allegato 1C).
recordType rappresenta il tipo di registrazione (VuTimeAdjustmentRe­
cord). Assegnazione valore: Cfr. RecordType
recordSize è la dimensione di VuTimeAdjustmentRecord in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni di regolazioni dell'ora.
2.234. WorkshopCardApplicationIdentification
Informazioni, memorizzate in una carta dell'officina, relative all'identifi­
cazione dell'applicazione della carta (requisiti 307 e 330 dell'allegato
1C).
Prima generazione:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 220
typeOfTachographCardId specifica il tipo di carta.
cardStructureVersion specifica la versione della struttura utilizzata
nella carta.
noOfEventsPerType è il numero di anomalie per tipo di anomalia che
la carta è in grado di registrare.
noOfFaultsPerType è il numero di guasti per tipo di guasto che la carta
è in grado di registrare.
activityStructureLength indica il numero di byte disponibili per me­
morizzare le registrazioni delle attività.
noOfCardVehicleRecords è il numero di registrazioni del veicolo che
la carta è in grado di contenere.
noOfCardPlaceRecords è il numero di luoghi che la carta è in grado di
registrare.
noOfCalibrationRecords è il numero di registrazioni di tarature che la
carta è in grado di memorizzare.
Seconda generazione:
▼M1
Oltre alla prima generazione, sono utilizzati gli elementi di dati seguenti:
noOfGNSSADRecords è il numero di registrazioni del periodo guida
cumulativo del GNSS che la carta è in grado di memorizzare.
noOfSpecificConditionRecords è il numero di registrazioni di condi­
zioni particolari che la carta è in grado di memorizzare.
noOfCardVehicleRecords è il numero di registrazioni relative alle unità
elettroniche di bordo che la carta è in grado di memorizzare.
▼M3
2.234a. WorkshopCardApplicationIdentificationV2
Seconda generazione, versione 2:
informazioni, memorizzate in una carta dell’officina, relative all’identi­
ficazione dell’applicazione della carta (requisito 330 bis dell’allegato IC).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 221
lengthOfFollowingData è il numero di byte che seguono nella
registrazione.
noOfBorderCrossingRecords è il numero di registrazioni degli attra­
versamenti di frontiera che la carta dell’officina può memorizzare.
noOfLoadUnloadRecords è il numero di registrazioni delle operazioni
di carico/scarico che la carta dell’officina può memorizzare.
noOfLoadTypeEntryRecords è il numero di registrazioni delle immis­
sioni dei tipi di carico che la carta dell’officina può memorizzare.
vuConfigurationLengthRange è il numero di byte in una carta tachi­
grafica, disponibile per memorizzare le configurazioni della VU.
2.234b. WorkshopCardCalibrationAddData
Seconda generazione, versione 2:
informazioni, memorizzate in una carta dell’officina, relative ai dati
aggiuntivi (cioè il tipo di carico predefinito) immessi durante una tara­
tura (requisito 356 terdecies dell’allegato IC).
calibrationPointerNewestRecord è l’indice della registrazione più ag­
giornata dei dati aggiuntivi relativi alla taratura.
Assegnazione valore è il numero corrispondente al numeratore della
registrazione dei dati aggiuntivi relativi alla taratura, a partire da «0»
per la prima volta in cui tale registrazione compare nella struttura.
workshopCardCalibrationAddDataRecords è la serie di registrazioni
contenenti il vecchio valore di data e ora, il valore di identificazione del
veicolo e il tipo di carico predefinito del veicolo.
2.234c. WorkshopCardCalibrationAddDataRecord
Seconda generazione, versione 2:
informazioni, memorizzate in una carta dell’officina, relative al tipo di
carico predefinito immesso durante una taratura (requisito 356 duodecies
dell’allegato IC).
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 222
oldTimeValue è il vecchio valore di data e ora contenuto nel corrispon­
dente WorkshopCardCalibrationRecord.
vehicleIdentificationNumber è il numero di identificazione del veicolo,
anch’esso contenuto nel corrispondente WorkshopCardCalibrationRe­
cord.
byDefaultLoadType è il tipo di carico predefinito del veicolo (presente
solo nella versione 2).
calibrationCountry è il paese in cui è stata effettuata la taratura.
calibrationCountryTimestamp è la data e l’ora in cui il ricevitore
GNSS ha fornito la posizione utilizzata per determinare tale paese.
▼B
2.235. WorkshopCardCalibrationData
Informazioni, memorizzate in una carta dell'officina, relative alle attività
dell'officina eseguite con la carta (requisiti 314, 316, 337 e 339 dell'al­
legato 1C).
calibrationTotalNumber è il numero totale di tarature effettuate con la
carta.
calibrationPointerNewestRecord è l'indice della registrazione di tara­
tura più aggiornata.
Assegnazione valore: numero corrispondente al numeratore della regi­
strazione di taratura, a partire da ′0′ per la prima volta in cui tale regi­
strazione compare nella struttura.
calibrationRecords è la serie di registrazioni contenenti le informazioni
relative alle tarature e/o regolazioni dell'ora.
2.236. WorkshopCardCalibrationRecord
Informazioni, memorizzate in una carta dell'officina, relative ad una
taratura eseguita con la carta (requisiti 314 e 337 dell'allegato 1C).
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 223
Prima generazione:
calibrationPurpose è lo scopo della taratura.
vehicleIdentificationNumber è il VIN.
vehicleRegistration contiene il VRN e lo Stato membro di
immatricolazione.
wVehicleCharacteristicConstant è il coefficiente caratteristico del
veicolo.
kConstantOfRecordingEquipment è la costante dell'apparecchio di
controllo.
lTyreCircumference è la circonferenza effettiva degli pneumatici delle
ruote.
tyreSize è l'indicazione delle dimensioni degli pneumatici montati sul
veicolo.
authorisedSpeed è la velocità massima autorizzata del veicolo.
oldOdometerValue, newOdometerValue sono i valori vecchio e nuovo
dell'odometro.
oldTimeValue, newTimeValue sono i valori vecchio e nuovo di data e
ora.
nextCalibrationDate è la data della prossima taratura del tipo specifi­
cato in CalibrationPurpose che dovrà essere effettuata dall'organismo
incaricato dei controlli.
vuPartNumber, vuSerialNumber e sensorSerialNumber contengono
gli elementi di dati per l'identificazione dell'apparecchio di controllo.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 224
Seconda generazione:
Oltre alla prima generazione, sono utilizzati i seguenti elementi di dati:
sensorGNSSSerialNumber identifica un dispositivo GNSS esterno.
rcmSerialNumber identifica un modulo di comunicazione remota.
sealDataCard dà informazioni sui sigilli apposti a diversi componenti
del veicolo.
2.237. WorkshopCardHolderIdentification
Informazioni, memorizzate in una carta dell'officina, relative all'identifi­
cazione del titolare della carta (requisiti 311 e 334 dell'allegato 1C).
workshopName è il nome dell'officina del titolare della carta.
workshopAddress è l'indirizzo dell'officina del titolare della carta.
cardHolderName specifica il cognome e il/i nome/i del titolare (per
esempio il nome del meccanico).
cardHolderPreferredLanguage è la lingua abituale del titolare della
carta.
2.238. WorkshopCardPIN
Numero di identificazione personale (PIN) della carta dell'officina (re­
quisiti 309 e 332 dell'allegato 1C).
Assegnazione valore: il PIN noto al titolare della carta, riempito a destra
con byte ′FF′ fino a raggiungere 8 byte.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 225
2.239. W-VehicleCharacteristicConstant
Coefficiente caratteristico del veicolo [definizione k)].
Assegnazione valore: impulsi per chilometro nell'intervallo operativo 0-
64 255 impulsi/km.
2.240. VuPowerSupplyInterruptionRecord
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alle
interruzioni dell'alimentazione di energia (requisito 117 dell'allegato 1C).
eventType è il tipo di anomalia.
eventRecordPurpose è lo scopo per cui è stata registrata l'anomalia.
eventBeginTime specifica la data e l'ora di inizio dell'anomalia.
eventEndTime specifica la data e l'ora di fine dell'anomalia.
cardNumberAndGenDriverSlotBegin identifica la carta, compresa la
generazione, inserita nella sede (slot) del conducente all'inizio dell'ano­
malia.
cardNumberAndGenDriverSlotEnd identifica la carta, compresa la
generazione, inserita nella sede (slot) del conducente al termine dell'ano­
malia.
cardNumberAndGenCodriverSlotBegin identifica la carta, compresa
la generazione, inserita nella sede (slot) del secondo conducente all'inizio
dell'anomalia.
cardNumberAndGenCodriverSlotEnd identifica la carta, compresa la
generazione, inserita nella sede (slot) del secondo conducente al termine
dell'anomalia.
similarEventsNumber è il numero di anomalie analoghe verificatesi nel
giorno in questione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 226
2.241. VuPowerSupplyInterruptionRecordArray
Seconda generazione:
Informazioni, memorizzate in un'unità elettronica di bordo, relative alle
interruzioni dell'alimentazione di energia (requisito 117 dell'allegato 1C).
recordType rappresenta il tipo di registrazione (VuPowerSupplyInter­
ruptionRecord). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di VuPowerSupplyInterruptionRecord in
byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni di interruzioni dell'alimentazione di
energia.
2.242. VuSensorExternalGNSSCoupledRecordArray
Seconda generazione:
Una serie di SensorExternalGNSSCoupledRecord più i metadati usati
nel protocollo di trasferimento.
recordType rappresenta il tipo di registrazione (SensorExternal­
GNSSCoupledRecord). Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di SensorExternalGNSSCoupledRecord
in byte.
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni degli accoppiamenti del sensore del
dispositivo GNSS esterno.
2.243. VuSensorPairedRecordArray
Seconda generazione:
Una serie di SensorPairedRecord più i metadati usati nel protocollo di
trasferimento.
recordType rappresenta il tipo di registrazione (SensorPairedRecord).
Assegnazione valore: Cfr. RecordType
recordSize sono le dimensioni di SensorPairedRecord in byte.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 227
noOfRecords è il numero di registrazioni nella serie di registrazioni.
records è una serie di registrazioni di abbinamenti del sensore.
3. DEFINIZIONI DEI CAMPI DI VALORI E DIMENSIONI
Definizione dei valori delle variabili usati per le definizioni nel para­
grafo 2.
4. SET DI CARATTERI
Le stringhe IA5 utilizzano i caratteri ASCII definiti nella norma ISO/IEC
8824-1. A fini di migliore leggibilità e di semplice riferimento, si riporta
di seguito l'assegnazione dei valori. In caso di discordanza, la norma
ISO/IEC 8824-1 prevale sulla presente nota informativa.
Altre stringhe di caratteri (Address, Name, VehicleRegistrationNumber)
utilizzano anche i caratteri definiti dai codici dei caratteri decimali 161
— 255 del seguente insieme standard di caratteri a 8 bit, specificati dal
loro numero di pagina di codice:
Insieme standard di caratteri
Pagina di codice
(decimale)
ISO/IEC 8859-1 Latino-1 Europa occidentale 1
ISO/IEC 8859-2 Latino-2 Europa centrale 2
ISO/IEC 8859-3 Latino-3 Europa meridionale 3
ISO/IEC 8859-5 Latino/Cirillico 5
ISO/IEC 8859-7 Latino/Greco 7
ISO/IEC 8859-9 Latino-5 Turco 9
ISO/IEC 8859-13 Latino-7 Baltico 13
ISO/IEC 8859-15 Latino-9 15
ISO/IEC 8859-16 Latino-10 Europa sudorientale 16
KOI8-R Latino/Cirillico 80
KOI8-U Latino / Cirillico 85
5. CODIFICA
Se la codifica viene effettuata in base alle regole ASN.1, tutti i tipi di
dati definiti devono essere codificati in conformità alla norma ISO/IEC
8825-2, variante allineata.
6. IDENTIFICATIVI DI OGGETTO E IDENTIFICATIVI DI APPLICA­
ZIONE
6.1. Identificativi di oggetto
Gli identificativi di oggetto (OID) elencati nel presente capitolo sono
pertinenti solo per la seconda generazione. Questi OID sono specificati
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 228
nelle linee guida tecniche TR-03110-3 e ripetuti qui per ragioni di
completezza. Questi OID sono contenuti nel sottoalbero di bsi-de:
Identificativi del protocollo di autenticazione della VU
Esempio: Supponiamo che l'autenticazione della VU debba essere fatta con
SHA-384; allora l'identificativo di oggetto da usare è (nella notazione ASN.
1) . Il
valore di tale identificativo di oggetto nella dot notation (notazione col
punto) è .
Dot notation Byte notation
«04 00 7F 00 07 02 02 02 02 03»
«04 00 7F 00 07 02 02 02 02 04»
«04 00 7F 00 07 02 02 02 02 05»
Identificativi del protocollo di autenticazione del chip
Esempio: Supponiamo che l'autenticazione del chip debba essere ef­
fettuata utilizzando l'algoritmo ECDH, che dà come risultato una
lunghezza della chiave di sessione AES di 128 bit. Tale chiave
di sessione sarà successivamente utilizzata nel modo operativo
CBC per garantire la riservatezza dei dati e con l'algoritmo
CMAC per assicurare l'autenticità dei dati. Di conseguenza, l'identi­
ficativo di oggetto da usare è (nella notazione ASN. 1)
. Il valore di
tale identificativo di oggetto nella dot notation (notazione col punto)
è .
Dot notation Byte notation
«04 00 7F 00 07 02 02 03 02 02»
«04 00 7F 00 07 02 02 03 02 03»
«04 00 7F 00 07 02 02 03 02 04»
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 229
6.2. Identificativi di applicazione
Seconda generazione:
L'identificativo di applicazione (AID) per il dispositivo GNSS esterno
(di seconda generazione) è dato da «FF 44 54 45 47 4D». Si tratta di un
AID proprietario secondo la norma ISO/IEC 7816-4.
Nota: gli ultimi 5 byte codificano DTEGM per il dispositivo GNSS
esterno del tachigrafo intelligente.
L'identificativo di applicazione per l'applicazione della carta tachigrafica
di seconda generazione è dato da «FF 53 4D 52 44 54». Si tratta di un
AID proprietario secondo la norma ISO/IEC 7816-4.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 230
Appendice 2
SPECIFICHE RIGUARDANTI LE CARTE TACHIGRAFICHE
INDICE
1. INTRODUZIONE
1.1. Abbreviazioni
1.2. Riferimenti
2. CARATTERISTICHE ELETTRICHE E FISICHE
2.1. Tensione di alimentazione e assorbimento di corrente
2.2. Tensione di programmazione V pp
2.3. Generazione e frequenza dell'orologio
2.4. Contatto I/O (ingresso/uscita)
2.5. Condizioni di funzionamento della carta
3. HARDWARE E COMUNICAZIONE
3.1. Introduzione
3.2. Protocollo di trasmissione
3.2.1 Protocolli
3.2.2 ATR
3.2.3 PTS
3.3. Regole di accesso
3.4. Panoramica dei comandi e dei codici di errore
3.5. Descrizione dei comandi
3.5.1 SELECT
3.5.2 READ BINARY
3.5.3 UPDATE BINARY
3.5.4 GET CHALLENGE
3.5.5 VERIFY
3.5.6 GET RESPONSE
3.5.7 PSO: VERIFY CERTIFICATE
3.5.8 INTERNAL AUTHENTICATE
3.5.9 EXTERNAL AUTHENTICATE
3.5.10 GENERAL AUTHENTICATE
3.5.11 MANAGE SECURITY ENVIRONMENT
3.5.12 PSO: HASH
3.5.13 PERFORM HASH of FILE
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 231
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE
3.5.15 PSO: VERIFY DIGITAL SIGNATURE
3.5.16 PROCESS DSRC MESSAGE
4. STRUTTURA DELLE CARTE TACHIGRAFICHE
4.1. Master file MF
4.2. Applicazioni della carta del conducente
4.2.1 Applicazione della carta del conducente di prima genera­
zione
4.2.2 Applicazione della carta del conducente di seconda genera­
zione
4.3. Applicazioni della carta dell'officina
4.3.1 Applicazione della carta dell'officina di prima generazione
4.3.2 Applicazione della carta dell'officina di seconda genera­
zione
4.4. Applicazioni della carta di controllo
4.4.1 Applicazione della carta di controllo di prima generazione
4.4.2 Applicazione della carta di controllo di seconda genera­
zione
4.5. Applicazioni della carta dell'azienda
4.5.1 Applicazione della carta dell'azienda di prima generazione
4.5.2 Applicazione della carta dell'azienda di seconda genera­
zione
1. INTRODUZIONE
1.1. Abbreviazioni
Ai fini della presente appendice, si applicano le seguenti
abbreviazioni.
AC Criteri di accesso
AES Norma di cifratura avanzata (Advanced Encryption Stan­
dard)
AID Identificativo dell'applicazione (Application Identifier)
ALW Sempre
APDU Unità dati del protocollo di applicazione (struttura di un
comando)
ATR Risposta al reset
AUT Autenticato
C6, C7 Contatti nn. 6 e 7 della carta, secondo la definizione ISO/
IEC 7816-2
cc Cicli dell'orologio
▼M1
CHA Autorizzazione del titolare del certificato
▼B
CHV Informazioni di verifica del titolare della carta
CLA Byte di classe di un comando APDU
▼M1
DO Oggetto di dati
▼B
DSRC Comunicazione dedicata a corto raggio
DF File dedicato. Un DF può contenere altri file (EF o DF)
ECC Crittografia a curve ellittiche
EF File elementare
etu Unità di tempo elementare
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 232
G1 Prima generazione
G2 Seconda generazione
IC Circuito integrato
ICC Carta a circuito integrato (Integrated Circuit Card)
ID Identificativo
IFD Dispositivo di interfaccia (Interface Device)
IFS Dimensioni del campo informazioni
IFSC Dimensioni del campo informazioni per la carta
IFSD Dimensioni del campo informazioni per il dispositivo (per
il terminale)
INS Byte di istruzioni di un comando APDU
Lc Lunghezza dei dati in ingresso per un comando APDU
Le Lunghezza dei dati attesi (dati in uscita per un comando)
MF File principale (root DF)
NAD Indirizzo di nodo usato nel protocollo T=1
NEV Mai
P1-P2 Byte dei parametri
PIN Numero di identificazione personale
PRO SM Protezione con messaggistica sicura
PTS Selezione della trasmissione del protocollo
RFU Riservato per uso futuro
RST Reset (della carta)
SFID Identificativo breve dell'EF
SM Messaggistica sicura (Secure Messaging)
SW1-SW2 Byte di stato
TS Carattere ATR iniziale
VPP Tensione di programmazione
VU Unità elettronica di bordo
XXh Valore XX in notazione esadecimale
«XXh» Valore XX in notazione esadecimale
|| Simbolo di concatenamento 03||04=0304
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 233
1.2. Riferimenti
Nella presente appendice si rimanda alle seguenti norme:
ISO/IEC 7816-2 Carte di identificazione — Carte a circuiti integrati
— Parte 2: Dimensioni e posizione dei contatti.
ISO/IEC 7816-2:2007.
ISO/IEC 7816-3 Carte di identificazione — Carte a circuiti integrati
— Parte 3: Interfaccia elettrica e protocolli di tra­
smissione. ISO/IEC 7816-3:2006.
ISO/IEC 7816-4 Carte di identificazione — Carte a circuiti integrati
— Parte 4: Organizzazione, sicurezza e comandi di
interscambio. ISO/IEC 7816-4:2013 + Cor 1: 2014.
ISO/IEC 7816-6 Carte di identificazione — Carte a circuiti integrati
— Parte 6: Elementi di dati per lo scambio intra­
settoriale. ISO/IEC 7816-6:2004 + Cor 1: 2006.
ISO/IEC 7816-8 Carte di identificazione — Carte a circuiti integrati
— Parte 8: Comandi per le operazioni di sicurezza.
ISO/IEC 7816-8:2004.
ISO/IEC 9797-2 Tecnologia dell'informazione — Tecniche di sicu­
rezza — Codici di autenticazione del
messaggio (MAC) — Parte 2: Meccanismi che
usano una funzione di hash dedicata. ISO/IEC
9797-2:2011
2. CARATTERISTICHE ELETTRICHE E FISICHE
TCS_01 Se non diversamente specificato, tutti i segnali elettronici
devono essere conformi alla norma ISO/IEC 7816-3.
TCS_02 La posizione e le dimensioni dei contatti della carta devono
essere conformi alla norma ISO/IEC 7816-2.
2.1. Tensione di alimentazione e assorbimento di corrente
TCS_03 La carta deve funzionare in conformità alle specifiche, en­
tro i limiti di assorbimento previsti nella norma ISO/IEC
7816-3.
TCS_04 La carta deve funzionare a Vcc = 3V (± 0,3V) o a Vcc =
5V (± 0,5V).
La tensione deve essere selezionata in conformità alla
norma ISO/IEC 7816-3.
2.2. Tensione di programmazione V pp
TCS_05 La carta non deve richiedere una tensione di programma­
zione sul pin C6. Si prevede che il pin C6 non sia collegato
in un IFD. Il contatto C6 può essere collegato alla V cc nella
carta, ma non va collegato a massa. Non sono ammesse
altre interpretazioni della tensione di programmazione.
2.3. Generazione e frequenza dell'orologio
TCS_06 La carta deve funzionare entro un campo di frequenze tra 1
e 5 MHz e può operare anche a frequenze più elevate. In
una sessione della carta, la frequenza dell'orologio può va­
riare di ± 2 %. La frequenza dell'orologio è generata dal­
l'unità elettronica di bordo e non dalla carta. Il fattore di
utilizzo può variare tra il 40 e il 60 %.
TCS_07 Nelle condizioni specificate nel file EF ICC della carta,
l'orologio esterno può essere arrestato. Il primo byte del
file EF ICC codifica le condizioni della modalità «Clock­
stop»:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 234
Basso Alto
Bit 3 Bit 2 Bit 1
0 0 1 Clockstop ammesso, nessun livello preferito
0 1 1 Clockstop ammesso, livello alto preferito
1 0 1 Clockstop ammesso, livello basso preferito
0 0 0 Clockstop non ammesso
0 1 0 Clockstop ammesso solo al livello alto
1 0 0 Clockstop ammesso solo al livello basso
I bit da 4 a 8 non sono utilizzati.
2.4. Contatto I/O (ingresso/uscita)
TCS_08 Il contatto I/O C7 è utilizzato per ricevere e trasmettere dati
da e verso l'IFD. Durante il funzionamento, la modalità di
trasmissione deve essere attiva solo nella carta o solo nel­
l'IFD. Se la modalità di trasmissione è attiva in entrambi i
dispositivi, la carta non deve essere danneggiata. A condi­
zione che non sia in fase di trasmissione, la carta deve
passare alla modalità di ricezione.
2.5. Condizioni di funzionamento della carta
TCS_09 Con la tensione di alimentazione inserita, la carta prevede
due condizioni di funzionamento:
▼M3
condizione di funzionamento durante l’esecuzione di co­
mandi o l’interfacciamento con l’unità elettronica di bordo,
▼B
condizione di riposo in tutti gli altri casi; in questa condi­
zione, la carta deve conservare tutti i dati.
3. HARDWARE E COMUNICAZIONE
3.1. Introduzione
Il presente paragrafo descrive la funzionalità minima richiesta per le
carte tachigrafiche e le VU al fine di garantirne il corretto funziona­
mento e l'interoperabilità.
Le carte tachigrafiche devono essere il più possibile conformi alle
norme ISO/IEC applicabili in vigore (in particolare ISO/IEC 7816).
Si fornisce comunque una descrizione completa dei comandi e dei
protocolli al fine di specificare alcune limitazioni d'uso o le differenze
eventualmente esistenti. Se non diversamente indicato, i comandi spe­
cificati sono pienamente conformi alle norme citate.
3.2. Protocollo di trasmissione
TCS_10 Il protocollo di trasmissione deve essere conforme alla
norma ISO/IEC 7816-3 per T = 0 e T = 1. In particolare,
la VU deve riconoscere le proroghe del tempo di attesa
inviate dalla carta.
3.2.1 Protocolli
TCS_11 La carta deve prevedere sia il protocollo T=0 sia il proto­
collo T=1. La carta può inoltre supportare ulteriori proto­
colli orientati al contatto.
TCS_12 T=0 è il protocollo predefinito ed è quindi necessario un
comando PTS per passare al protocollo T=1.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 235
TCS_13 I dispositivi devono prevedere l'impiego della convenzione
diretta in entrambi i protocolli: la convenzione diretta è
quindi obbligatoria per la carta.
TCS_14 Il byte di dimensione del campo di informazioni per la
carta deve essere presentato all'ATR nel carattere TA3.
Questo valore deve essere almeno pari a «F0h» (= 240
byte).
Ai protocolli si applicano le restrizioni seguenti.
TCS_15 T=0
— L'interfaccia deve prevedere una risposta all'I/O dopo il
fronte di salita del segnale all'RST da 400 cc.
— L'interfaccia deve essere in grado di leggere caratteri
separati da 12 etu.
— L'interfaccia deve leggere un carattere errato e la sua
ripetizione se separati da 13 etu. Se viene rilevato un
carattere errato, il segnale di errore all'I/O può verifi­
carsi tra 1 e 2 etu. Il dispositivo deve prevedere un
ritardo di 1 etu.
— L'interfaccia deve accettare un'ATR da 33 byte
(TS+32).
— In presenza di TC1 nell'ATR, deve essere previsto un
Extra Guard Time (tempo di protezione supplementare)
per i caratteri inviati dall'interfaccia, anche se i caratteri
inviati dalla carta possono comunque essere separati da
12 etu. Questo vale anche per il carattere ACK inviato
dalla carta dopo un carattere P3 emesso dall'interfaccia.
— L'interfaccia deve tener conto di un carattere NUL
(nullo) emesso dalla carta.
— L'interfaccia deve accettare la modalità complementare
per ACK.
— Il comando GET RESPONSE non può essere usato
nella modalità di concatenamento per ottenere dati la
cui lunghezza può superare 255 byte.
TCS_16 T=1
— Byte NAD: non utilizzato (il byte NAD deve essere
impostato a «00»).
— S-block ABORT: non utilizzato.
— S-block VPP state error: non utilizzato.
▼M3
__________
▼B
— La dimensione del campo di informazioni per il
dispositivo (IFSD) deve essere indicata dall'IFD imme­
diatamente dopo l'ATR: l'IFD deve trasmettere la ri­
chiesta dell'S-Block IFS dopo l'ATR e la carta deve
rispondere con l'S-Block IFS. Il valore consigliato per
l'IFSD è 254 byte.
— La carta non chiede un riadeguamento dell'IFS.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 236
3.2.2 ATR
TCS_17 Il dispositivo controlla i byte ATR, secondo la norma ISO/
IEC 7816-3. Non si devono effettuare verifiche dei caratteri
storici dell'ATR.
Esempio di biprotocollo ATR di base secondo la norma
ISO/IEC 7816-3
Carattere Valore Osservazioni
TS «3Bh» Indica la convenzione diretta
T0 «85h» TD1 presente; sono presenti 5 byte storici
TD1 «80h» TD2 presente; si deve usare T = 0
TD2 «11h» TA3 presente; si deve usare T = 1
TA3 «XXh» (almeno
«F0h»)
Dimensione del campo di informazioni per la
carta (IFSC)
da TH1 a TH5 «XXh» Caratteri storici
TCK «XXh» Carattere di controllo (OR esclusivo)
TCS_18 In seguito alla risposta al reset (ATR), il file
principale (MF) è implicitamente selezionato e diventa la
directory attiva.
3.2.3 PTS
TCS_19 Il protocollo predefinito è T=0. Per impostare il protocollo
T=1, il dispositivo deve inviare un PTS (anche noto come
PPS) alla carta.
TCS_20 Poiché entrambi i protocolli T=0 e T=1 sono obbligatori
per la carta, anche il PTS di base per il cambio di proto­
collo è obbligatorio per la carta.
Come indicato nella norma ISO/IEC 7816-3, il PTS si può
utilizzare per passare a velocità di dati più elevate rispetto a
quella predefinita, proposta dalla carta nell'ATR, se pre­
sente (TA(1) byte).
Velocità di dati più elevate per la carta sono facoltative.
TCS_21 Se non sono previste velocità di dati diverse da quella
predefinita (o se non è prevista la velocità di dati selezio­
nata), la carta deve rispondere correttamente al PTS, se­
condo la norma ISO/IEC 7816-3, omettendo il byte PPS1.
Si riportano di seguito alcuni esempi di PTS di base per la
selezione del protocollo.
Carattere Valore Osservazioni
PPSS «FFh» Il carattere iniziale
PPS0 «00h» o «01h» I caratteri da PPS1 a PPS3 non sono presenti; «00h» per
selezionare T0, «01h» per selezionare T1.
PK «XXh» Carattere di controllo: «XXh» = «FFh» se PPS0 =
«00h»,
«XXh» = «FEh» se PPS0 =
«01h».
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 237
3.3. Regole di accesso
TCS_22 Una regola di accesso specifica per una modalità di ac­
cesso, vale a dire un comando, le condizioni di sicurezza
corrispondenti. Se queste condizioni di sicurezza sono sod­
disfatte, il comando corrispondente è elaborato.
TCS_23 Le seguenti condizioni di sicurezza sono usate per la carta
tachigrafica:
Abbreviazione Significato
ALW L'azione è sempre possibile e può essere eseguita senza limitazioni. Il co­
mando e la risposta APDU sono inviati in testo semplice, vale a dire senza
messaggistica sicura.
NEV L'azione non è mai possibile.
PLAIN-C Il comando APDU è inviato in testo semplice, vale a dire senza messaggistica
sicura.
PWD L'azione può essere eseguita solo se il PIN della carta dell'officina è stato
correttamente verificato, vale a dire se la condizione di sicurezza interna della
carta «PIN_Verified» è impostata. Il comando deve essere inviato senza mes­
saggistica sicura.
EXT-AUT-G1 L'azione può essere eseguita solo se il comando External Authenticate per
l'autenticazione di prima generazione (cfr. anche appendice 11, parte A) è
stato eseguito correttamente.
SM-MAC-G1 L'APDU (comando e risposta) deve essere applicata con messaggistica sicura
di prima generazione in modalità di sola autenticazione (cfr. appendice 11,
parte A).
SM-C-MAC-G1 Il comando APDU deve essere applicato con messaggistica sicura di prima
generazione in modalità di sola autenticazione (cfr. appendice 11, parte A).
SM-R-ENC-G1 La risposta APDU deve essere applicata con messaggistica sicura di prima
generazione in modalità cifratura (cfr. appendice 11, parte A), vale a dire
senza che sia inviato in risposta un codice di autenticazione del messaggio.
SM-R-ENC-
MAC-G1
La risposta APDU deve essere applicata con messaggistica sicura di prima
generazione in modalità cifratura seguita da autenticazione (cfr. appendice 11,
parte A).
SM-MAC-G2 L'APDU (comando e risposta) deve essere applicata con messaggistica sicura
di seconda generazione in modalità di sola autenticazione (cfr. appendice 11,
parte B).
SM-C-MAC-G2 Il comando APDU deve essere applicato con messaggistica sicura di seconda
generazione in modalità di sola autenticazione (cfr. appendice 11, parte B).
SM-R-ENC-
MAC-G2
La risposta APDU deve essere applicata con messaggistica sicura di seconda
generazione in modalità cifratura seguita da autenticazione (cfr. appendice 11,
parte B).
▼M1
TCS_24 Queste condizioni di sicurezza possono essere collegate nei
modi seguenti:
AND: devono essere soddisfatte tutte le condizioni di sicu­
rezza
OR: deve essere soddisfatta almeno una condizione di si­
curezza
Le norme di accesso per il file system, vale a dire per i
comandi SELECT, UPDATE BINARY e READ BINARY,
sono specificate nel capitolo 4. Le norme di accesso per gli
altri comandi sono specificate nelle tabelle riportate di se­
guito. L’espressione «Non applicabile» si usa quando non
vi sono requisiti a supporto del comando. In questo caso il
comando può essere o può non essere supportato, ma la
condizione di accesso è esclusa dal campo di applicazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 238
TCS_25 Nell'applicazione DF Tachograph G1 sono utilizzate le se­
guenti norme di accesso:
▼M1
Comando
Carta del con­
ducente
Carta dell’offi­
cina
Carta di con­
trollo
Carta
dell’azienda
External Authenticate
— Per l’autenticazione di
prima generazione
ALW ALW ALW ALW
— Per l’autenticazione di se­
conda generazione
ALW PWD ALW ALW
Internal Authenticate ALW PWD ALW ALW
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message Non applica­
bile
Non applica­
bile
Non applica­
bile
Non applica­
bile
PSO: Compute Digital Signature ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
Non applica­
bile
Non applica­
bile
PSO: Hash Non applica­
bile
Non applica­
bile
ALW Non applica­
bile
PERFORM HASH OF FILE ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
Non applica­
bile
Non applica­
bile
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature Non applica­
bile
Non applica­
bile
ALW Non applica­
bile
Verify Non applica­
bile
ALW Non applica­
bile
Non applica­
bile
▼B
TCS_26 Nell'applicazione DF Tachograph_G2 sono utilizzate le se­
guenti norme di accesso:
▼M1
Comando
Carta del con­
ducente
Carta dell’offi­
cina
Carta di con­
trollo
Carta
dell’azienda
External Authenticate
— Per l’autenticazione di
prima generazione
Non applica­
bile
Non applica­
bile
Non applica­
bile
Non applica­
bile
— Per l’autenticazione di se­
conda generazione
ALW PWD ALW ALW
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 239
Comando
Carta del con­
ducente
Carta dell’offi­
cina
Carta di con­
trollo
Carta
dell’azienda
Internal Authenticate Non applica­
bile
Non applica­
bile
Non applica­
bile
Non applica­
bile
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message Non applica­
bile
ALW ALW Non applica­
bile
PSO: Compute Digital Signature ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
Non applica­
bile
Non applica­
bile
PSO: Hash Non applica­
bile
Non applica­
bile
ALW Non applica­
bile
PERFORM HASH OF FILE ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
Non applica­
bile
Non applica­
bile
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature Non applica­
bile
Non applica­
bile
ALW Non applica­
bile
Verify Non applica­
bile
ALW Non applica­
bile
Non applica­
bile
▼B
TCS_27 Nell'MF sono utilizzate le seguenti norme di accesso:
▼M1
Comando
Carta del con­
ducente
Carta dell’offi­
cina
Carta di con­
trollo
Carta
dell’azienda
External Authenticate
— Per l’autenticazione di
prima generazione
Non applica­
bile
Non applica­
bile
Non applica­
bile
Non applica­
bile
— Per l’autenticazione di se­
conda generazione
ALW PWD ALW ALW
Internal Authenticate Non applica­
bile
Non applica­
bile
Non applica­
bile
Non applica­
bile
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 240
Comando
Carta del con­
ducente
Carta dell’offi­
cina
Carta di con­
trollo
Carta
dell’azienda
Process DSRC Message Non applica­
bile
Non applica­
bile
Non applica­
bile
Non applica­
bile
PSO: Compute Digital Signature Non applica­
bile
Non applica­
bile
Non applica­
bile
Non applica­
bile
PSO: Hash Non applica­
bile
Non applica­
bile
Non applica­
bile
Non applica­
bile
PERFORM HASH OF FILE Non applica­
bile
Non applica­
bile
Non applica­
bile
Non applica­
bile
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature Non applica­
bile
Non applica­
bile
Non applica­
bile
Non applica­
bile
Verify Non applica­
bile
ALW Non applica­
bile
Non applica­
bile
▼B
TCS_28 Una carta tachigrafica può accettare o meno un comando
con un livello di sicurezza più elevato rispetto a quello
specificato nelle condizioni di sicurezza. Ciò significa che
se la condizione di sicurezza è ALW (o PLAIN-C) la carta
può accettare un comando con messaggistica sicura (moda­
lità cifratura e/o autenticazione). Se la condizione di sicu­
rezza richiede la messaggistica sicura con modalità di au­
tenticazione, la carta tachigrafica può accettare un comando
con messaggistica sicura della stessa generazione in moda­
lità autenticazione e cifratura.
Nota: le descrizioni del comando forniscono maggiori in­
formazioni sul supporto dei comandi per i diversi tipi di
carte tachigrafiche e i diversi DF.
3.4. Panoramica dei comandi e dei codici di errore
I comandi e l'organizzazione dei file si desumono dalla norma ISO/
IEC 7816-4, cui sono conformi.
La presente sezione descrive le seguenti coppie comando-risposta
APDU. Le varianti di comandi che sono supportate da un'applicazione
di prima e di seconda generazione sono specificate nelle descrizioni
dei comandi corrispondenti.
Comando INS
SELECT «A4h»
READ BINARY «B0h», «B1h»
UPDATE BINARY «D6h», «D7h»
GET CHALLENGE «84h»
VERIFY «20h»
GET RESPONSE «C0h»
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 241
Comando INS
PERFORM SECURITY OPERA­
TION
«2Ah»
— VERIFY CERTIFICATE
— COMPUTE DIGITAL SIGNA­
TURE
— VERIFY DIGITAL SIGNA­
TURE
— HASH
— PERFORM HASH OF FILE
— PROCESS DSRC MESSAGE
INTERNAL AUTHENTICATE «88h»
EXTERNAL AUTHENTICATE «82h»
MANAGE SECURITY ENVIRON­
MENT
«22h»
— SET DIGITAL SIGNATURE
TEMPLATE
— SET AUTHENTICATION TEM­
PLATE
GENERAL AUTHENTICATE «86h»
▼M1
TCS_29 Le parole di stato SW1 SW2 sono inviate in ogni messag­
gio di risposta ed indicano lo stato di elaborazione del
comando.
SW1 SW2 Significato
90 00 Elaborazione normale.
61 XX Elaborazione normale. XX= numero di byte di risposta disponibili
62 81 Elaborazione con avvertimento. Parte dei dati inviati in risposta
potrebbe essere danneggiata.
63 00 Autenticazione fallita (avvertimento).
63 CX CHV (PIN) errato. Contatore tentativi rimasti fornito da ′X′.
64 00 Errore di esecuzione - Stato della memoria non volatile immutato.
Errore di integrità.
65 00 Errore di esecuzione - Stato della memoria non volatile mutato.
65 81 Errore di esecuzione - Stato della memoria non volatile mutato -
Errore di memoria.
66 88 Errore di sicurezza: totale di controllo crittografico errato (du­
rante messaggistica sicura), o
certificato errato (durante verifica certifi­
cato), o
crittogramma errato (durante autenticazione
esterna), o
firma errata (durante verifica firma).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 242
SW1 SW2 Significato
67 00 Lunghezza errata (Lc o Le errata).
68 83 Ultimo comando della catena atteso.
69 00 Comando vietato (risposta non disponibile in T= 0).
69 82 Condizione di sicurezza non soddisfatta.
69 83 Metodo di autenticazione bloccato.
69 85 Condizioni di impiego non soddisfatte.
69 86 Comando non consentito (nessun EF in corso).
69 87 Oggetti di dati previsti in messaggistica sicura mancanti.
69 88 Oggetti di dati in messaggistica sicura non corretti.
6A 80 Parametri errati nel campo di dati.
6A 82 File non trovato.
6A 86 Parametri P1-P2 errati.
6A 88 Dati indicati non trovati.
6B 00 Parametri errati (scostamento al di fuori dell’EF).
6C XX Lunghezza errata, SW2 indica la lunghezza esatta. Non viene
inviato alcun campo di dati in risposta.
6D 00 Codice di istruzione non previsto o non valido.
6E 00 Classe non supportata.
6F 00 — Altri errori di controllo.
Possono essere inviate in risposta altre parole di stato de­
finite dalla norma ISO/IEC 7816-4 se il loro comporta­
mento non è esplicitamente menzionato nella presente
appendice.
Per esempio possono essere inviate in risposta le parole di
stato seguenti:
6881: Canale logico non supportato
6882: Messaggistica sicura non supportata
▼B
TCS_30 Se in un comando APDU è soddisfatta più di una condi­
zione di errore, la carta può inviare in risposta una qualsiasi
delle parole di stato appropriate.
3.5. Descrizione dei comandi
Nel presente capitolo sono descritti i comandi obbligatori per le carte
tachigrafiche.
Altri particolari di rilievo, riguardanti le operazioni crittografiche,
sono forniti nell'appendice 11 (Meccanismi comuni di sicurezza per
i tachigrafi di prima e seconda generazione).
Tutti i comandi sono descritti a prescindere dal protocollo utilizzato
(T=0 o T=1). I byte APDU CLA, INS, P1, P2, Lc e Le sono sempre
indicati. Se i byte Lc o Le non sono necessari per il comando de­
scritto, la lunghezza, il valore e la descrizione ad essi associati sono
vuoti.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 243
TCS_31 Se entrambi i byte di lunghezza (Lc e Le) sono necessari, e
se l'IFD utilizza il protocollo T=0, il comando descritto
dev'essere suddiviso in due parti: l'IFD invia il comando
secondo quanto descritto con P3=Lc + dati e quindi invia
un comando GET RESPONSE (cfr. paragrafo 3.5.6) con
P3=Le.
TCS_32 Se sono necessari entrambi i byte di lunghezza e Le=0
(messaggistica sicura):
— se si usa il protocollo T=1, la carta deve rispondere a
Le=0 inviando tutti i dati in uscita disponibili;
— se si usa il protocollo T=0, l'IFD deve inviare il primo
comando con P3=Lc + dati e la carta deve rispondere
(a questo implicito Le=0) con i byte di stato «61La»,
dove La è il numero di byte di risposta disponibili.
L'IFD deve generare quindi un comando GET RE­
SPONSE con P3=La per leggere i dati.
TCS_33 Una carta tachigrafica può supportare campi di lunghezza
estesa conformemente alla norma ISO/IEC 7816-4 quale
caratteristica opzionale. Una carta tachigrafica che supporta
campi di lunghezza estesa:
— deve indicare che supporta i campi di lunghezza estesa
nell'ATR;
— deve fornire la dimensione del buffer supportato tramite
le informazioni di lunghezza estesa nell'ATR/INFO del­
l'EF, cfr. TCS_146;
— deve indicare se supporta campi di lunghezza estesa per
T = 1 e/o T = 0 nella lunghezza estesa dell'EF, cfr.
TCS_147;
— deve supportare campi di lunghezza estesa per l'appli­
cazione tachigrafica di prima e seconda generazione.
Note:
tutti i comandi sono specificati per campi di lunghezza
breve. L'uso di APDU di lunghezza estesa è specificato
nella norma ISO/IEC 7816-4.
In generale i comandi sono specificati per la modalità in
chiaro, vale a dire senza messaggistica sicura, poiché il
livello della messaggistica sicura è specificato nell'appen­
dice 11. È chiaro dalle norme di accesso di un comando se
questo supporta la messaggistica sicura oppure no e se
supporta la messaggistica sicura di prima e/o di seconda
generazione. Alcune varianti di comandi sono descritte
con messaggistica sicura per illustrarne l'uso.
TCS_34 La VU deve eseguire il protocollo completo di autentica­
zione reciproca tra la VU di seconda generazione e la carta
per una sessione, compresa la verifica del certificato (se
richiesta), in DF Tachograph, DF Tachograph_G2 o nel­
l'MF.
3.5.1 SELECT
Questo comando è conforme alla norma ISO/IEC 7816-4, ma ha un
impiego limitato rispetto al comando definito nella norma.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 244
Il comando SELECT si usa per:
— selezionare un DF di applicazione (si deve usare la selezione per
nome)
— selezionare un file elementare corrispondente all'ID del file indi­
cato
3.5.1.1 S e l e z i o n e i n b a s e a l n o m e ( A I D )
Questo comando consente di selezionare un DF di applicazione nella
carta.
TCS_35 Il comando può essere eseguito da qualsiasi punto della
struttura del file (dopo l'ATR o in qualsiasi momento).
TCS_36 La selezione di un'applicazione azzera l'ambiente di sicu­
rezza attivo. Dopo la selezione dell'applicazione non è più
selezionata nessuna chiave pubblica corrente. Si perde an­
che la condizione di accesso EXT-AUT-G1. Se il comando
è stato eseguito senza messaggistica sicura, le chiavi della
precedente sessione di messaggistica sicura non sono più
disponibili.
TCS_37 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «A4h»
P1 1 «04h» Selezione in base al nome (AID)
P2 1 «0Ch» Nessuna risposta attesa
Lc 1 «NNh» Numero di byte inviati alla carta (lunghezza dell'AID):
«06h» per l'applicazione tachigrafica
#6-#(5 + NN) NN «XX..XXh» AID: «FF 54 41 43 48 4F» per l'applicazione tachigra­
fica di prima generazione
AID: «FF 53 4D 52 44 54» per l'applicazione tachigra­
fica di seconda generazione
Non è necessaria una risposta al comando SELECT (Le
assente in T=1 o nessuna risposta richiesta in T=0).
TCS_38 Messaggio di risposta (nessuna risposta richiesta)
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se l'applicazione corrispondente all'AID non viene tro­
vata, lo stato di elaborazione inviato in risposta è
«6A82».
— In T=1, se il byte Le è presente, lo stato inviato in
risposta è «6700».
— In T=0, se è richiesta una risposta dopo il comando
SELECT, lo stato inviato in risposta è «6900».
▼M1
— Se l’applicazione selezionata è considerata danneggiata
(negli attributi del file è rilevato un errore di integrità),
lo stato di elaborazione inviato in risposta è «6400» o
«6500».
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 245
3.5.1.2 S e l e z i o n e d i u n f i l e e l e m e n t a r e u t i l i z z a n d o i l s u o
i d e n t i f i c a t i v o
TCS_39 Messaggio di comando
TCS_40 Una carta tachigrafica deve supportare la messaggistica si­
cura di seconda generazione, come specificato nell'appen­
dice 11, parte B, per questa variante di comando.
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «A4h»
P1 1 «02h» Selezione di un EF sotto il DF corrente
P2 1 «0Ch» Nessuna risposta attesa
Lc 1 «02h» Numero di byte inviati alla carta
#6-#7 2 «XXXXh» Identificativo del file
Non è necessaria una risposta al comando SELECT (Le
assente in T=1 o nessuna risposta richiesta in T=0).
TCS_41 Messaggio di risposta (nessuna risposta richiesta)
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se il file corrispondente all'identificativo del file non
viene trovato, lo stato di elaborazione inviato in risposta
è «6A82».
— In T=1, se il byte Le è presente, lo stato inviato in
risposta è «6700».
— In T=0, se è richiesta una risposta dopo il comando
SELECT, lo stato inviato in risposta è «6900».
▼M1
— Se il file selezionato è considerato danneggiato (negli
attributi del file è rilevato un errore di integrità), lo stato
di elaborazione inviato in risposta è «6400» o «6500».
▼B
3.5.2 READ BINARY
Questo comando è conforme alla norma ISO/IEC 7816-4, ma ha un
impiego limitato rispetto al comando definito nella norma.
Il comando READ BINARY è usato per leggere i dati di un file
trasparente.
La risposta della carta consiste nell'invio dei dati letti, eventualmente
incapsulati in una struttura di messaggistica sicura.
3.5.2.1 C o m a n d o c o n s c o s t a m e n t o i n P 1 - P 2
Questo comando consente all'IFD di leggere i dati dell'EF selezionato,
senza messaggistica sicura.
Nota: questo comando senza messaggistica sicura si può usare solo
per leggere un file che supporta la condizione di sicurezza ALW per
la modalità Read Access.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 246
TCS_42 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «B0h» Read Binary
P1 1 «XXh» Scostamento in byte dall'inizio del file: byte più signifi­
cativo
P2 1 «XXh» Scostamento in byte dall'inizio del file: byte meno signi­
ficativo
Le 1 «XXh» Lunghezza dei dati attesi. Numero di byte da leggere
Nota: il bit 8 di P1 dev'essere impostato a 0.
TCS_43 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
#1-#X X «XX..XXh» Dati letti
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se non è selezionato un EF, lo stato di elaborazione
inviato in risposta è «6986».
— Se le condizioni di sicurezza del file selezionato non sono
soddisfatte, il comando viene interrotto con «6982».
— Se lo scostamento non è compatibile con la dimensione
dell'EF (scostamento > dimensione EF), lo stato di ela­
borazione inviato in risposta è «6B00».
— Se la dimensione dei dati da leggere non è compatibile con
la dimensione dell'EF (scostamento + Le > dimensione
EF), lo stato di elaborazione inviato in risposta è «6700»
o «6Cxx», dove «xx» indica la lunghezza esatta.
▼M1
— Se negli attributi del file è rilevato un errore di integrità,
la carta deve considerare tale file danneggiato e irrecu­
perabile; lo stato di elaborazione inviato in risposta è
’6400’ o ’6500’.
▼B
— Se nei dati memorizzati è rilevato un errore di integrità,
la carta deve fornire i dati richiesti e inviare in risposta
lo stato di elaborazione «6281».
3.5.2.1.1 C o m a n d o c o n m e s s a g g i s t i c a s i c u r a ( e s e m p i )
Questo comando consente all'IFD di leggere i dati dall'EF selezionato
con messaggistica sicura, al fine di verificare l'integrità dei dati rice­
vuti e di proteggere la riservatezza dei dati se si applica la condizione
di sicurezza SM-R-ENC-MAC-G1 (prima generazione) o SM-R-ENC-
MAC-G2 (seconda generazione).
TCS_44 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «0Ch» Richiesta messaggistica sicura
INS 1 «B0h» Read Binary
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 247
Byte
Lun­
ghezza
Valore Descrizione
P1 1 «XXh» P1 (scostamento in byte dall'inizio del file): byte più
significativo
P2 1 «XXh» P2 (scostamento in byte dall'inizio del file): byte meno
significativo
Lc 1 «XXh» Lunghezza dei dati in ingresso per messaggistica sicura
#6 1 «97h» T LE : tag per la specificazione della lunghezza attesa
#7 1 «01h» L LE : lunghezza della lunghezza attesa
#8 1 «NNh» Specificazione della lunghezza attesa (Le originale): nu­
mero di byte da leggere
#9 1 «8Eh» T CC : tag per il totale di controllo crittografico
#10 1 «XXh» L CC : lunghezza del totale di controllo crittografico succes­
sivo
«04h» per la messaggistica sicura di prima generazione (cfr.
appendice 11, parte A)
«08h», «0Ch» o «10h» secondo la lunghezza della chiave
AES per la messaggistica sicura di seconda generazione
(cfr. appendice 11, parte B)
#11-#(10 + L) L «XX..XXh» Totale di controllo crittografico
Le 1 «00h» Secondo la norma ISO/IEC 7816-4
TCS_45 Messaggio di risposta se SM-R-ENC-MAC-G1 (prima
generazione) / SM-R-ENC-MAC-G2 (seconda genera­
zione) non è necessario e se il formato di messaggistica
sicura in ingresso è corretto:
▼M1
Byte
Lun­
ghezza
Valore Descrizione
#1 1 «81h» T PV : tag per i dati in chiaro
#2 L «NNh» o
«81 NNh»
L PV : lunghezza dei dati inviati in risposta
(= Le originale).
L è 2 byte se L PV >127 byte
#(2+L) - #(1+L+NN) NN «XX..XXh» Dati in chiaro
#(2+L+NN) 1 «99h» Tag per lo stato di elaborazione (SW1-SW2)
- facoltativo per la messaggistica sicura di
prima generazione
#(3+L+NN) 1 «02h» Lunghezza dello stato di elaborazione - fa­
coltativo per la messaggistica sicura di prima
generazione
#(4+L+NN) - #(5+L+NN) 2 «XX XXh» Stato di elaborazione della risposta APDU
non protetta - facoltativo per la messaggi­
stica sicura di prima generazione
#(6+L+NN) 1 «8Eh» TCC: tag per il totale di controllo crittogra­
fico
#(7+L+NN) 1 «XXh» LCC: lunghezza del totale di controllo crit­
tografico successivo
«04h» per la messaggistica sicura di prima
generazione (cfr. appendice 11, parte A)
«08h», «0Ch» o «10h» secondo la lun­
ghezza della chiave AES per la messaggi­
stica sicura di seconda generazione (cfr.
appendice 11, parte B)
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 248
Byte
Lun­
ghezza
Valore Descrizione
#(8+L+NN)-#(7+M+L+NN) M «XX..XXh» Totale di controllo crittografico
SW 2 «XXXXh» Parole di stato (SW1, SW2)
▼B
TCS_46 Messaggio di risposta se SM-R-ENC-MAC-G1 (prima
generazione) / SM-R-ENC-MAC-G2 (seconda genera­
zione) è necessario e se il formato di messaggistica si­
cura in ingresso è corretto:
▼M1
Byte
Lun­
ghezza
Valore Descrizione
#1 1 «87h» T PI CG : tag per i dati criptati (crittogramma)
#2 L «MMh» o
’81 MMh’
L PI CG : lunghezza dei dati criptati inviati in
risposta (diversa da Le originale del co­
mando a causa del riempimento)
L è 2 byte se LPI CG>127 byte.
#(2+L)-#(1+L+MM) MM «01XX..XXh» Dati criptati: indicatore di riempimento e
crittogramma
#(2+L+MM) 1 «99h» Tag per lo stato di elaborazione (SW1-SW2)
- facoltativo per la messaggistica sicura di
prima generazione
#(3+L+MM) 1 «02h» Lunghezza dello stato di elaborazione - fa­
coltativo per la messaggistica sicura di prima
generazione
#(4+L+MM) - #(5+L+MM) 2 «XX XXh» Stato di elaborazione della risposta APDU
non protetta - facoltativo per la messaggi­
stica sicura di prima generazione
#(6+L+MM) 1 «8Eh» TCC: tag per il totale di controllo crittogra­
fico
#(7+L+MM) 1 «XXXXh» LCC: lunghezza del totale di controllo crit­
tografico successivo
«04h» per la messaggistica sicura di prima
generazione (cfr. appendice 11, parte A)
«08h», «0Ch» o «10h» secondo la lun­
ghezza della chiave AES per la messaggi­
stica sicura di seconda generazione (cfr.
appendice 11, parte B)
#(8+L+MM)-
#(7+N+L+MM)
N «XX..XXh» Totale di controllo crittografico
SW 2 «XXXXh» Parole di stato (SW1, SW2)
▼B
Il comando READ BINARY può inviare in risposta gli
stati di elaborazione regolare elencati in TCS_43 con il
tag «99h», come descritto in TCS_59, usando la struttura
di risposta della messaggistica sicura.
Si possono inoltre verificare alcuni errori riguardanti in
modo specifico la messaggistica sicura. In tal caso, viene
inviato in risposta solo lo stato di elaborazione, senza strut­
ture di messaggistica sicura.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 249
TCS_47 Messaggio di risposta se il formato di messaggistica si­
cura in ingresso è errato
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se non è disponibile una chiave di sessione corrente,
viene inviato in risposta lo stato di elaborazione
«6A88». Questo si verifica se la chiave di sessione
non è ancora stata generata o se è terminato il corso
di validità della chiave di sessione (in questo caso l'IFD
deve rieseguire un processo di autenticazione reciproca
per impostare una nuova chiave di sessione).
— Se nel formato di messaggistica sicura mancano alcuni
oggetti di dati attesi (secondo quanto sopra specificato),
viene inviato in risposta lo stato di elaborazione
«6987»: questo errore si verifica se manca un tag atteso
o se il comando non è costruito in modo corretto.
— Se alcuni oggetti di dati non sono corretti, lo stato di
elaborazione inviato in risposta è «6988»: questo errore
si verifica se tutti i tag richiesti sono presenti, ma al­
cune lunghezze sono diverse da quelle attese.
— Se la verifica del totale di controllo crittografico ha
esito negativo, lo stato di elaborazione inviato in rispo­
sta è «6688».
3.5.2.2 C o m a n d o c o n i d e n t i f i c a t i v o b r e v e d e l l ' E F ( f i l e
e l e m e n t a r e )
Questa variante di comando consente all'IFD di selezionare un EF
mediante un identificativo breve dell'EF e di leggere i dati da questo
EF.
TCS_48 Una carta tachigrafica deve supportare questa variante di
comando per tutti i file elementari con un identificativo
breve dell'EF determinato. Questi identificativi brevi del­
l'EF sono specificati nel capitolo 4.
TCS_49 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «B0h» Read Binary
P1 1 «XXh» Il bit 8 è pari a 1
I bit 7 e 6 sono pari a 00
I bit 5 — 1 codificano l'identificativo breve dell'EF cor­
rispondente
P2 1 «XXh» Codifica uno scostamento da 0 a 255 byte nell'EF al
quale si riferisce P1
Le 1 «XXh» Lunghezza dei dati attesi. Numero di byte da leggere
Nota: gli identificativi brevi dell'EF utilizzati per l'applica­
zione tachigrafica di seconda generazione sono specificati
nel capitolo 4.
Se P1 codifica un identificativo breve dell'EF e il comando
ha esito positivo, l'EF identificato diventa l'EF selezionato
in quel momento (EF corrente).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 250
TCS_50 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
#1-#L L «XX..XXh» Dati letti
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se il file corrispondente all'identificativo breve dell'EF
non viene trovato, lo stato di elaborazione inviato in
risposta è «6A82».
— Se le condizioni di sicurezza del file selezionato non sono
soddisfatte, il comando viene interrotto con «6982».
— Se lo scostamento non è compatibile con la dimensione
dell'EF (scostamento > dimensione EF), lo stato di ela­
borazione inviato in risposta è «6B00».
— Se la dimensione dei dati da leggere non è compatibile
con la dimensione dell'EF (scostamento + Le > dimen­
sione EF), lo stato di elaborazione inviato in risposta è
«6700» o «6Cxx», dove «xx» indica la lunghezza
esatta.
▼M1
— Se negli attributi del file è rilevato un errore di integrità,
la carta deve considerare tale file danneggiato e irrecu­
perabile; lo stato di elaborazione inviato in risposta è
«6400» o «6500».
▼B
— Se nei dati memorizzati è rilevato un errore di integrità,
la carta deve fornire i dati richiesti e inviare in risposta
lo stato di elaborazione \«6281».
3.5.2.3 C o m a n d o c o n b y t e d i i s t r u z i o n i d i s p a r i
Questa variante di comando consente all'IFD di leggere i dati da un
EF con 32 768 byte o più.
TCS_51 Una carta tachigrafica che supporta EF con 32 768 byte o
più deve supportare questa variante di comando per questi
EF. Una carta tachigrafica può supportare o meno questa
variante di comando per altri EF ad eccezione dell'EF Sen­
sor_Installation_Data, cfr. TCS_156 e TCS_160.
TCS_52 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «B1h» Read Binary
P1 1 «00h» EF corrente
P2 1 «00h»
Lc 1 «NNh» Lc Lunghezza dell'oggetto di dati di scostamento
#6-#(5+NN) NN «XX..XXh» Oggetto di dati di scostamento:
Tag «54h»
Lunghezza «01h» o «02h»
Valore scostamento
▼M1
Le 1 ’XXh’ Secondo la norma ISO/IEC 7816-4
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 251
L'IFD deve codificare la lunghezza dell'oggetto di dati di
scostamento con il numero minimo possibile di ottetti, ov­
vero utilizzando il byte di lunghezza «01h», l'IFD deve
codificare uno scostamento da 0 a 255 e, utilizzando il
byte di lunghezza «02h», uno scostamento da «256» fino
a «65 535» byte.
▼M1
Nei casi in cui T=0, la carta assume il valore Le=«00h» se
non è applicata la messaggistica sicura.
Nei casi in cui T=1, lo stato di elaborazione inviato in
risposta è «6700» se Le=«01h».
▼B
TCS_53 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
#1-#L L «XX..XXh» Dati letti incapsulati in un oggetto di dati discrezionale
con tag «53h».
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se non è selezionato un EF, lo stato di elaborazione
inviato in risposta è «6986».
— Se le condizioni di sicurezza del file selezionato non
sono soddisfatte, il comando viene interrotto con
«6982».
— Se lo scostamento non è compatibile con la dimensione
dell'EF (scostamento > dimensione EF), lo stato di ela­
borazione inviato in risposta è «6B00».
— Se la dimensione dei dati da leggere non è compatibile
con la dimensione dell'EF (scostamento + Le > dimen­
sione EF), lo stato di elaborazione inviato in risposta è
«6700» o «6Cxx», dove «xx» indica la lunghezza
esatta.
▼M1
— Se negli attributi del file è rilevato un errore di integrità,
la carta deve considerare tale file danneggiato e irrecu­
perabile; lo stato di elaborazione inviato in risposta è
«6400» o «6500».
▼B
— Se nei dati memorizzati è rilevato un errore di integrità,
la carta deve fornire i dati richiesti e inviare in risposta
lo stato di elaborazione «6281».
3.5.2.3.1 C o m a n d o c o n m e s s a g g i s t i c a s i c u r a ( e s e m p i o )
Il seguente esempio illustra l'uso della messaggistica sicura se si ap­
plica la condizione di sicurezza SM-MAC-G2.
TCS_54 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «0Ch» Richiesta messaggistica sicura
INS 1 «B1h» Read Binary
P1 1 «00h» EF corrente
P2 1 «00h»
Lc 1 «XXh» Lunghezza del campo di dati sicuri
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 252
Byte
Lun­
ghezza
Valore Descrizione
#6 1 «B3h» Tag per i dati in chiaro codificati in BER-TLV
#7 1 «NNh» L PV : lunghezza dei dati trasmessi
#(8)-#(7+NN) NN «XX..XXh» Dati in chiaro codificati in BER-TLV, vale a dire l'og­
getto di dati di scostamento con tag «54»
#(8+NN) 1 «97h» T LE : tag per la specificazione della lunghezza attesa
#(9+NN) 1 «01h» L LE : lunghezza della lunghezza attesa
#(10+NN) 1 «XXh» Specificazione della lunghezza attesa (Le originale): nu­
mero di byte da leggere
#(11+NN) 1 «8Eh» T CC : tag per il totale di controllo crittografico
#(12+NN) 1 «XXh» L CC : lunghezza del totale di controllo crittografico suc­
cessivo
«08h», «0Ch» o «10h» secondo la lunghezza della
chiave AES per la messaggistica sicura di seconda gene­
razione (cfr. appendice 11, parte B)
#(13+NN)-
#(12+M+NN)
M «XX..XXh» Totale di controllo crittografico
Le 1 «00h» Secondo la norma ISO/IEC 7816-4
TCS_55 Messaggio di risposta se il comando ha esito positivo
Byte
Lun­
ghezza
Valore Descrizione
#1 1 «B3h» Dati in chiaro codificati in BER-TLV
#2 L «NNh» o
«81 NNh»
L PV : lunghezza dei dati inviati in risposta (=Le origi­
nale).
L è 2 byte se L PV >127 byte
#(2+L)-
#(1+L+NN)
NN «XX..XXh» Dati in chiaro codificati in BER-TLV, vale a dire dati
letti incapsulati in un oggetto di dati discrezionale con
tag «53h»
#(2+L+NN) 1 «99h» Stato di elaborazione della risposta APDU non protetta
#(3+L+NN) 1 «02h» Lunghezza dello stato di elaborazione
#(4+L+NN) —
#(5+L+NN)
2 «XX XXh» Stato di elaborazione della risposta APDU non protetta
#(6+L+NN) 1 «8Eh» T CC : tag per il totale di controllo crittografico
#(7+L+NN) 1 «XXh» L CC : lunghezza del totale di controllo crittografico suc­
cessivo
«08h», «0Ch» o «10h» secondo la lunghezza della
chiave AES per la messaggistica sicura di seconda gene­
razione (cfr. appendice 11, parte B)
#(8+L+NN)-
#(7+M+L+
NN)
M «XX..XXh» Totale di controllo crittografico
SW 2 «XXXXh» Parole di stato (SW1, SW2)
3.5.3 UPDATE BINARY
Questo comando è conforme alla norma ISO/IEC 7816-4, ma ha un
impiego limitato rispetto al comando definito nella norma.
Il messaggio di comando UPDATE BINARY avvia l'aggiornamento
(cancellazione + scrittura) dei bit già presenti in un EF binario con i
bit indicati nel comando APDU.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 253
3.5.3.1 C o m a n d o c o n s c o s t a m e n t o i n P 1 - P 2
Questo comando consente all'IFD di scrivere dati nell'EF selezionato,
senza che la carta verifichi l'integrità dei dati ricevuti.
Nota: questo comando senza messaggistica sicura si può usare solo
per aggiornare un file che supporta la condizione di sicurezza ALW
per la modalità Update Access.
TCS_56 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «D6h» Update Binary
P1 1 «XXh» Scostamento in byte dall'inizio del file: byte più signifi­
cativo
P2 1 «XXh» Scostamento in byte dall'inizio del file: byte meno signi­
ficativo
Lc 1 «NNh» Lc Lunghezza dei dati da aggiornare. Numero di byte da
scrivere
#6-#(5+NN) NN «XX..XXh» Dati da scrivere
Nota: il bit 8 di P1 dev'essere impostato a 0.
TCS_57 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se non è selezionato un EF, lo stato di elaborazione
inviato in risposta è «6986».
— Se le condizioni di sicurezza del file selezionato non
sono soddisfatte, il comando viene interrotto con
«6982».
— Se lo scostamento non è compatibile con la dimensione
dell'EF (scostamento > dimensione EF), lo stato di ela­
borazione inviato in risposta è «6B00».
— Se la dimensione dei dati da scrivere non è compatibile
con la dimensione dell'EF (scostamento + Lc > dimen­
sione EF), lo stato di elaborazione inviato in risposta è
«6700».
— Se negli attributi del file è rilevato un errore di integrità,
la carta deve considerare tale file danneggiato e irrecu­
perabile; lo stato di elaborazione inviato in risposta è
«6400» o «6500».
— Se l'operazione di scrittura fallisce, lo stato di elabora­
zione inviato in risposta è «6581».
3.5.3.1.1 C o m a n d o c o n m e s s a g g i s t i c a s i c u r a ( e s e m p i )
Questo comando consente all'IFD di scrivere dati nell'EF selezionato,
con verifica da parte della carta dell'integrità dei dati ricevuti. Poiché
non è richiesta la riservatezza, i dati non sono criptati.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 254
TCS_58 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «0Ch» Richiesta messaggistica sicura
INS 1 «D6h» Update Binary
P1 1 «XXh» Scostamento in byte dall'inizio del file:
byte più significativo
P2 1 «XXh» Scostamento in byte dall'inizio del file:
byte meno significativo
Lc 1 «XXh» Lunghezza del campo di dati sicuri
#6 1 «81h» T PV : tag per i dati in chiaro
#7 L «NNh» o
«81 NNh»
L PV : lunghezza dei dati trasmessi
L è 2 byte se L PV >127 byte
#(7+L)-
#(6+L+NN)
NN «XX..XXh» Valore dei dati in chiaro (dati da scrivere)
#(7+L+NN) 1 «8Eh» T CC : tag per il totale di controllo crittografico
#(8+L+NN) 1 «XXh» L CC : lunghezza del totale di controllo crittografico se­
guente «04h» per la messaggistica sicura di prima gene­
razione (cfr. appendice 11, parte A)
«08h», «0Ch» o «10h» secondo la lunghezza della
chiave AES per la messaggistica sicura di seconda gene­
razione (cfr. appendice 11, parte B)
#(9+L+NN)-
#(8+M+L+
NN)
M «XX..XXh» Totale di controllo crittografico
Le 1 «00h» Secondo la norma ISO/IEC 7816-4
TCS_59 Messaggio di risposta se il formato di messaggistica si­
cura in ingresso è corretto
Byte
Lun­
ghezza
Valore Descrizione
#1 1 «99h» T SW : tag per le parole di stato (deve essere protetto da
CC)
#2 1 «02h» L SW : lunghezza delle parole di stato inviate in risposta
#3-#4 2 «XXXXh» Stato di elaborazione della risposta APDU non protetta
#5 1 «8Eh» T CC : tag per il totale di controllo crittografico
#6 1 «XXh» L CC : lunghezza del totale di controllo crittografico suc­
cessivo
«04h» per la messaggistica sicura di prima generazione
(cfr. appendice 11, parte A)
«08h», «0Ch» o «10h» secondo la lunghezza della
chiave AES per la messaggistica sicura di seconda gene­
razione (cfr. appendice 11, parte B)
#7-#(6+L) L «XX..XXh» Totale di controllo crittografico
SW 2 «XXXXh» Parole di stato (SW1, SW2)
Gli stati di elaborazione «regolari», descritti per il comando
UPDATE BINARY senza messaggistica sicura (cfr.
§3.5.3.1), possono essere inviati in risposta utilizzando la
struttura del messaggio di risposta sopra descritta.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 255
Si possono inoltre verificare alcuni errori riguardanti in
modo specifico la messaggistica sicura. In tal caso, viene
inviato in risposta solo lo stato di elaborazione, senza strut­
ture di messaggistica sicura.
TCS_60 Messaggio di risposta in caso di errore di messaggistica
sicura
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se non è disponibile una chiave di sessione corrente, viene
inviato in risposta lo stato di elaborazione «6A88».
— Se nel formato di messaggistica sicura mancano alcuni
oggetti di dati attesi (secondo quanto sopra specificato),
viene inviato in risposta lo stato di elaborazione
«6987»: questo errore si verifica se manca un tag atteso
o se il comando non è costruito in modo corretto.
— Se alcuni oggetti di dati non sono corretti, lo stato di
elaborazione inviato in risposta è «6988»: questo errore
si verifica se tutti i tag richiesti sono presenti, ma al­
cune lunghezze sono diverse da quelle attese.
— Se la verifica del totale di controllo crittografico ha esito
negativo, lo stato di elaborazione inviato in risposta è «6688».
3.5.3.2 C o m a n d o c o n i d e n t i f i c a t i v o b r e v e d e l l ' E F
Questa variante di comando consente all'IFD di selezionare un EF me­
diante un identificativo breve dell'EF e di scrivere dati da questo EF.
TCS_61 Una carta tachigrafica deve supportare questa variante di
comando per tutti i file elementari con un identificativo
breve dell'EF determinato. Questi identificativi brevi del­
l'EF sono specificati nel capitolo 4.
TCS_62 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «D6h» Update Binary
P1 1 «XXh» Il bit 8 è pari a 1
I bit 7 e 6 sono pari a 00
I bit 5 — 1 codificano l'identificativo breve dell'EF cor­
rispondente
P2 1 «XXh» Codifica uno scostamento da 0 a 255 byte nell'EF al
quale si riferisce P1
Lc 1 «NNh» Lc Lunghezza dei dati da aggiornare. Numero di byte da
scrivere
#6-#(5+NN) NN «XX..XXh» Dati da scrivere
TCS_63 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
Nota: gli identificativi brevi dell'EF utilizzati per l'applica­
zione tachigrafica di seconda generazione sono specificati
nel capitolo 4.
Se P1 codifica un identificativo breve dell'EF e il comando
ha esito positivo, l'EF identificato diventa l'EF selezionato
in quel momento (EF corrente).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 256
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se il file corrispondente all'identificativo breve dell'EF
non viene trovato, lo stato di elaborazione inviato in
risposta è «6A82».
— Se le condizioni di sicurezza del file selezionato non
sono soddisfatte, il comando viene interrotto con
«6982».
— Se lo scostamento non è compatibile con la dimensione
dell'EF (scostamento > dimensione EF), lo stato di ela­
borazione inviato in risposta è «6B00».
— Se la dimensione dei dati da scrivere non è compatibile
con la dimensione dell'EF (scostamento + Lc > dimen­
sione EF), lo stato di elaborazione inviato in risposta è
«6700».
▼M1
— Se negli attributi del file è rilevato un errore di integrità,
la carta deve considerare tale file danneggiato e irrecu­
perabile; lo stato di elaborazione inviato in risposta è
«6400» o «6500».
▼B
— Se l'operazione di scrittura fallisce, lo stato di elabora­
zione inviato in risposta è «6581».
3.5.3.3 C o m a n d o c o n b y t e d i i s t r u z i o n i d i s p a r i
Questa variante di comando consente all'IFD di scrivere i dati in un
EF con 32 768 byte o più.
TCS_64 Una carta tachigrafica che supporta EF con 32 768 byte o
più deve supportare questa variante di comando per questi
EF. Una carta tachigrafica può supportare o meno questa
variante di comando per altri EF.
TCS_65 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «D7h» Update Binary
P1 1 «00h» EF corrente
P2 1 «00h»
Lc 1 «NNh» Lc Lunghezza dei dati nel campo di dati del comando
#6-#(5+NN) NN «XX..XXh» Oggetto di dati di scostamento con tag «54h» || Oggetto
di dati discrezionale con tag «53h» che incapsula i dati
da scrivere
L'IFD deve codificare la lunghezza dell'oggetto di dati di
scostamento e la lunghezza dell'oggetto di dati discrezio­
nale con il numero minimo possibile di ottetti, ovvero uti­
lizzando il byte di lunghezza «01h», l'IFD deve codificare
uno scostamento / una lunghezza da 0 a 255 e, utilizzando
il byte di lunghezza «02h», uno scostamento / una lun­
ghezza da «256» fino a «65 535» byte.
TCS_66 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 257
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se non è selezionato un EF, lo stato di elaborazione
inviato in risposta è «6986».
— Se le condizioni di sicurezza del file selezionato non
sono soddisfatte, il comando viene interrotto con
«6982».
— Se lo scostamento non è compatibile con la dimensione
dell'EF (scostamento > dimensione EF), lo stato di ela­
borazione inviato in risposta è «6B00».
— Se la dimensione dei dati da scrivere non è compatibile
con la dimensione dell'EF (scostamento + Lc > dimen­
sione EF), lo stato di elaborazione inviato in risposta è
«6700».
— Se negli attributi del file è rilevato un errore di integrità,
la carta deve considerare tale file danneggiato e irrecu­
perabile; lo stato di elaborazione inviato in risposta è
«6400» o «6500».
— Se l'operazione di scrittura fallisce, lo stato di elabora­
zione inviato in risposta è «6581».
3.5.3.3.1 C o m a n d o c o n m e s s a g g i s t i c a s i c u r a ( e s e m p i o )
Il seguente esempio illustra l'uso della messaggistica sicura se si ap­
plica la condizione di sicurezza SM-MAC-G2.
TCS_67 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «0Ch» Richiesta messaggistica sicura
INS 1 «D7h» Update Binary
P1 1 «00h» EF corrente
P2 1 «00h»
Lc 1 «XXh» Lunghezza del campo di dati sicuri
#6 1 «B3h» Tag per i dati in chiaro codificati in BER-TLV
#7 L «NNh» o
«81 NNh»
L PV : lunghezza dei dati trasmessi
L è 2 byte se L PV >127 byte
#(7+L)-
#(6+L+NN)
NN «XX..XXh» Dati in chiaro codificati in BER-TLV, vale a dire l'og­
getto di dati di scostamento con tag «54h» || Oggetto di
dati discrezionale con tag «53h» che incapsula i dati da
scrivere
#(7+L+NN) 1 «8Eh» T CC : tag per il totale di controllo crittografico
#(8+L+NN) 1 «XXh» L CC : lunghezza del totale di controllo crittografico suc­
cessivo
«08h», «0Ch» o «10h» secondo la lunghezza della
chiave AES per la messaggistica sicura di seconda gene­
razione (cfr. appendice 11, parte B)
#(9+L+NN)-
#(8+M+L+N­
N)
M «XX..XXh» Totale di controllo crittografico
Le 1 «00h» Secondo la norma ISO/IEC 7816-4
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 258
TCS_68 Messaggio di risposta se il comando ha esito positivo
Byte
Lun­
ghezza
Valore Descrizione
#1 1 «99h» T SW : tag per le parole di stato (deve essere protetto da
CC)
#2 1 «02h» L SW : lunghezza delle parole di stato inviate in risposta
#3-#4 2 «XXXXh» Stato di elaborazione della risposta APDU non protetta
#5 1 «8Eh» T CC : tag per il totale di controllo crittografico
#6 1 «XXh» L CC : lunghezza del totale di controllo crittografico suc­
cessivo
«08h», «0Ch» o «10h» secondo la lunghezza della
chiave AES per la messaggistica sicura di seconda gene­
razione (cfr. appendice 11, parte B)
#7-#(6+L) L «XX..XXh» Totale di controllo crittografico
SW 2 «XXXXh» Parole di stato (SW1, SW2)
3.5.4 GET CHALLENGE
Questo comando è conforme alla norma ISO/IEC 7816-4, ma ha un
impiego limitato rispetto al comando definito nella norma.
Il comando GET CHALLENGE chiede alla carta di generare una
Challenge da utilizzare in una procedura di sicurezza, in cui un critto­
gramma o alcuni dati cifrati vengono inviati alla carta.
TCS_69 La Challenge generata dalla carta è valida solo per il co­
mando successivo, che utilizza una Challenge, inviato alla
carta.
TCS_70 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «84h» INS
P1 1 «00h» P1
P2 1 «00h» P2
Le 1 «08h» Le (lunghezza della Challenge attesa).
TCS_71 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
#1-#8 8 «XX..XXh» Challenge
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se Le è diversa da «08h», lo stato di elaborazione è
«6700».
— Se i parametri P1-P2 sono errati, lo stato di elabora­
zione è «6A86».
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 259
3.5.5 VERIFY
Questo comando è conforme alla norma ISO/IEC 7816-4, ma ha un
impiego limitato rispetto al comando definito nella norma.
Solo la carta dell'officina deve supportare questo comando.
Altri tipi di carte tachigrafiche possono eseguire o meno questo co­
mando, ma per tali carte nessun CHV di riferimento è personalizzato.
Tali carte non possono dunque eseguire questo comando con esito
positivo. Per altri tipi di carte tachigrafiche diverse dalle carte dell'of­
ficina, il comportamento, cioè il codice di errore inviato in risposta,
esula dal campo di applicazione delle presenti specifiche, se tale
comando è inviato.
Il comando VERIFY avvia il confronto nella carta dei dati
CHV (PIN) inviati dal comando con il CHV di riferimento memoriz­
zato nella carta.
▼M1
TCS_72 Il PIN inserito dall’utente deve essere codificato in ASCII e
riempito a destra dall’IFD con byte «FFh», fino a raggiun­
gere la lunghezza di 8 byte; cfr. anche il tipo di dati Wor­
kshopCardPIN nell’appendice 1.
▼B
TCS_73 Le applicazioni tachigrafiche di prima e seconda genera­
zione devono usare lo stesso CHV di riferimento.
TCS_74 La carta tachigrafica deve verificare se il comando è codi­
ficato correttamente. Se il comando non è codificato cor­
rettamente, la carta non deve confrontare i valori CHV, non
deve decrementare il contatore dei tentativi rimasti per il
CHV e non deve azzerare lo stato di sicurezza «PIN_Ve­
rified», ma deve interrompere la trasmissione del comando.
Un comando è codificato correttamente se i byte CLA,
INS, P1, P2 e Lc hanno i valori specificati, Le è assente
e il campo di dati del comando ha la lunghezza corretta.
TCS_75 Se il comando è eseguito correttamente, il contatore dei
tentativi rimasti per il CHV è reinizializzato. Il valore ini­
ziale del contatore dei tentativi rimasti per il CHV è 5. Se il
comando è eseguito correttamente, la carta deve impostare
lo stato di sicurezza interna «PIN_Verified». La carta deve
azzerare tale stato di sicurezza se è reimpostata o se il
codice CHV trasmesso nel comando non corrisponde al
CHV di riferimento memorizzato.
Nota: l'uso dello stesso CHV di riferimento e di uno stato
di sicurezza globale evita che un dipendente dell'officina
debba reinserire il PIN dopo aver selezionato un altro DF
dell'applicazione tachigrafica.
TCS_76 Se il confronto ha esito negativo, l'informazione viene regi­
strata nella carta, vale a dire che il contatore dei tentativi
rimasti per il CHV è decrementato di uno, al fine di limi­
tare il numero di ulteriori tentativi d'uso del CHV di
riferimento.
TCS_77 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «20h» INS
P1 1 «00h» P1
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 260
Byte
Lun­
ghezza
Valore Descrizione
P2 1 «00h» P2 (il CHV di riferimento verificato è implicitamente
noto)
Lc 1 «08h» Lunghezza del codice CHV trasmesso
#6-#13 8 «XX..XXh» CHV
TCS_78 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se il CHV di riferimento non viene trovato, lo stato di
elaborazione inviato in risposta è «6A88».
— Se il CHV è bloccato (il contatore dei tentativi rimasti
per il CHV è nullo), lo stato di elaborazione inviato in
risposta è «6983». In presenza di tale stato, il CHV non
può più essere presentato con esito positivo.
— Se il confronto ha esito negativo, il contatore dei ten­
tativi rimasti è decrementato e viene inviato in risposta
lo stato «63CX» (X > 0 e X è uguale al contatore dei
tentativi rimasti per il CHV).
— Se il CHV di riferimento è considerato danneggiato, lo
stato di elaborazione inviato in risposta è «6400» o
«6581».
— Se Lc è diversa da «08h», lo stato di elaborazione è
«6700».
3.5.6 GET RESPONSE
Questo comando è conforme alla norma ISO/IEC 7816-4.
Il comando (necessario e disponibile solo per il protocollo T=0) è
utilizzato per trasmettere all'interfaccia i dati preparati dalla carta (caso
in cui un comando include sia Lc che Le).
Il comando GET RESPONSE dev'essere inviato immediatamente
dopo il comando di preparazione dei dati, altrimenti i dati in questione
sono persi. Dopo l'esecuzione del comando GET RESPONSE (eccetto
per il caso in cui si verifichi l'errore «61xx» o «6Cxx», cfr. sotto), i
dati precedentemente preparati non sono più disponibili.
TCS_79 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «C0h»
P1 1 «00h»
P2 1 «00h»
Le 1 «XXh» Numero di byte attesi
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 261
TCS_80 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
#1-#X X «XX..XXh» Dati
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se i dati non sono stati preparati dalla carta, lo stato di
elaborazione inviato in risposta è «6900» o «6F00».
— Se Le supera il numero di byte disponibili o è nullo, lo
stato di elaborazione inviato in risposta è «6Cxx», dove
«xx» indica il numero esatto di byte disponibili. In tal
caso, i dati preparati restano disponibili per un succes­
sivo comando GET RESPONSE.
— Se Le non è nullo ed è inferiore al numero di byte
disponibili, i dati richiesti vengono inviati normalmente
dalla carta e lo stato di elaborazione inviato in risposta
è «61xx», dove «xx» indica il numero di byte ancora
disponibili per un ulteriore comando GET RESPONSE.
— Se il comando non è previsto (protocollo T = 1), la
carta risponde «6D00».
3.5.7 PSO: VERIFY CERTIFICATE
Questo comando è conforme alla norma ISO/IEC 7816-8, ma ha un
impiego limitato rispetto al comando definito nella norma.
Il comando VERIFY CERTIFICATE è utilizzato dalla carta per otte­
nere una chiave pubblica dall'esterno e per verificarne la validità.
3.5.7.1 C o p p i a c o m a n d o - r i s p o s t a d i p r i m a g e n e r a z i o n e
TCS_81 Questa variante di comando è supportata solo da un'appli­
cazione tachigrafica di prima generazione.
TCS_82 Se il comando VERIFY CERTIFICATE ha esito positivo,
la chiave pubblica viene memorizzata per uso futuro nel­
l'ambiente di sicurezza. Questa chiave è esplicitamente im­
postata dal comando MSE (cfr. § 3.5.11), utilizzando il suo
identificativo della chiave, per l'impiego in comandi relativi
alla sicurezza (INTERNAL AUTHENTICATE, EXTER­
NAL AUTHENTICATE o VERIFY CERTIFICATE).
TCS_83 In ogni caso, il comando VERIFY CERTIFICATE utilizza
la chiave pubblica precedentemente selezionata dal co­
mando MSE per aprire il certificato. Tale chiave pubblica
deve essere quella di uno degli Stati membri o quella del­
l'Europa.
TCS_84 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «2Ah» Esecuzione operazione di sicurezza
P1 1 «00h» P1
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 262
Byte
Lun­
ghezza
Valore Descrizione
P2 1 «AEh» P2: dati non codificati BER-TLV (concatenamento di
elementi di dati)
Lc 1 «C2h» Lc: lunghezza del certificato, 194 byte
#6-#199 194 «XX..XXh» Certificato: concatenamento di elementi di dati (secondo
la descrizione di cui all'appendice 11)
TCS_85 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se la verifica del certificato fallisce, lo stato di elabo­
razione inviato in risposta è «6688». Il processo di
verifica e di apertura del certificato è descritto nell'ap­
pendice 11 per G1 e G2.
— Se nell'ambiente di sicurezza non è presente una chiave
pubblica, viene inviato in risposta «6A88».
— Se la chiave pubblica selezionata (usata per aprire il
certificato) è considerata danneggiata, lo stato di elabo­
razione inviato in risposta è «6400» o «6581».
— Solo prima generazione: se la chiave pubblica selezio­
nata
(usata per aprire il certificato) ha una CHA.LSB (­
)
diversa da «00» (ovvero non è quella di uno degli Stati
membri o quella dell'Europa), lo stato di elaborazione
inviato in risposta è «6985».
3.5.7.2 C o p p i a c o m a n d o - r i s p o s t a d i s e c o n d a g e n e r a z i o n e
Secondo le dimensioni della curva, i certificati ECC possono essere
così lunghi da non poter essere trasmessi in un unico APDU. In
questo caso è necessario applicare il concatenamento dei comandi
conformemente alla norma ISO/IEC 7816-4 e il certificato deve essere
trasmesso in due PSO consecutivi: Verify Certificate APDUs.
La struttura del certificato e i parametri del dominio sono definiti
nell'appendice 11.
▼M3
TCS_86 Il comando può essere eseguito in MF, DF Tachograph e
DF Tachograph_G2, cfr. anche TCS_34.
▼B
TCS_87 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «X0h» Byte CLA indicante il concatenamento dei comandi:
«00h» l'unico o l'ultimo comando della catena
«10h» non l'ultimo comando di una catena
INS 1 «2Ah» Esecuzione operazione di sicurezza
P1 1 «00h»
P2 1 «BEh» Verifica del certificato autodescrittivo
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 263
Byte
Lun­
ghezza
Valore Descrizione
Lc 1 «XXh» Lunghezza del campo di dati del comando, cfr. TCS_88
e TCS_89
#6-#5+L L «XX..XXh» Dati codificati DER-TLV: oggetto di dati del corpo del
certificato ECC quale primo oggetto di dati concatenato
all'oggetto di dati della firma del certificato ECC quale
secondo oggetto di dati o parte di questa concatenazione.
Il tag «7F21» e la lunghezza corrispondente non devono
essere trasmessi.
L'ordine di questi oggetti di dati è fisso.
▼M3
TCS_88 Agli APDU di lunghezza breve si applicano le seguenti
disposizioni: l’IFD deve utilizzare il numero minimo di
APDU richiesti per trasmettere il payload del comando e
deve trasmettere il numero massimo di byte nel primo co­
mando APDU. Tuttavia qualsiasi valore di «Lc» fino a 255
byte deve essere supportato dalla carta.
TCS_89 Agli APDU di lunghezza estesa si applicano le seguenti
disposizioni: se il certificato non entra in un unico APDU,
la carta deve supportare il concatenamento dei comandi.
L’IFD deve utilizzare il numero minimo di APDU richiesti
per trasmettere il payload del comando e deve trasmettere il
numero massimo di byte nel primo comando APDU. Se è
necessario il concatenamento, qualsiasi valore di «Lc» fino
alla dimensione massima della lunghezza estesa indicata
deve essere supportato dalla carta.
Nota: secondo l’appendice 11, la carta memorizza il certi­
ficato o i contenuti pertinenti del certificato e ne aggiorna il
currentAuthenticatedTime.
La struttura del messaggio di risposta e le parole di stato
sono definite in TCS_85.
▼B
TCS_90 Oltre ai codici di errore elencati in TCS_85, la carta può
inviare in risposta i seguenti codici di errore:
— Se la chiave pubblica selezionata (usata per aprire il
certificato) ha una CHA.LSB (CertificateHolderAutho­
risation.equipmentType) non idonea alla verifica del
certificato secondo l'appendice 11, lo stato di elabora­
zione inviato in risposta è «6985».
— Se il currentAuthenticatedTime della carta è successivo
alla data di scadenza del certificato, lo stato di elabo­
razione inviato in risposta è «6985».
— Se si aspetta l'ultimo comando della catena, la carta
invia in risposta «6883».
— Se nel campo di dati del comando sono trasmessi pa­
rametri non corretti, la carta invia in risposta «6A80»
(usato anche nel caso in cui gli oggetti di dati non siano
inviati nell'ordine specificato).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 264
3.5.8 INTERNAL AUTHENTICATE
Questo comando è conforme alla norma ISO/IEC 7816-4.
TCS_91 Tutte le carte tachigrafiche devono supportare questo co­
mando in DF Tachograph_G1. Il comando può essere ac­
cessibile o meno nell'MF e/o in DF Tachograph_G2. In
caso sia accessibile, il comando deve finire con un codice
di errore idoneo, poiché la chiave privata della carta
(Card.SK) per il protocollo di autenticazione di prima ge­
nerazione è accessibile unicamente in DF_Tachograph_G1.
Utilizzando il comando INTERNAL AUTHENTICATE,
l'IFD può autenticare la carta. Il processo di autenticazione
è descritto nell'appendice 11. Esso include i seguenti
enunciati.
TCS_92 Il comando INTERNAL AUTHENTICATE utilizza la
chiave privata della carta (selezionata implicitamente) per
firmare dati di autenticazione, compresi K1 (primo ele­
mento per l'accordo sulla chiave di sessione) e RND1, ed
utilizza la chiave pubblica selezionata (mediante l'ultimo
comando MSE) per criptare la firma e formare il token di
autenticazione (cfr. appendice 11 per maggiori particolari).
TCS_93 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h» CLA
INS 1 «88h» INS
P1 1 «00h» P1
P2 1 «00h» P2
Lc 1 «10h» Lunghezza dei dati inviati alla carta
#6 — #13 8 «XX..XXh» Challenge usata per autenticare la carta
#14 -#21 8 «XX..XXh» VU.CHR (cfr. appendice 11)
Le 1 «80h» Lunghezza dei dati attesi dalla carta
TCS_94 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
#1-#128 128 «XX..XXh» Token di autenticazione della carta (cfr. appendice 11)
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se nell'ambiente di sicurezza non è presente una chiave
pubblica, lo stato di elaborazione inviato in risposta è
«6A88».
— Se nell'ambiente di sicurezza non è presente una chiave
privata, lo stato di elaborazione inviato in risposta è
«6A88».
— Se VU.CHR non corrisponde all'identificativo della
chiave pubblica corrente, lo stato di elaborazione in­
viato in risposta è «6A88».
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 265
— Se la chiave privata selezionata è considerata danneg­
giata, lo stato di elaborazione inviato in risposta è
«6400» o «6581».
▼M1
TCS_95 Se il comando INTERNAL AUTHENTICATE ha esito
positivo, la chiave di sessione corrente di prima genera­
zione, se presente, viene cancellata e non è più disponibile.
Per avere a disposizione una nuova chiave di sessione di
prima generazione, il comando EXTERNAL AUTHENTI­
CATE per il meccanismo di autenticazione di prima gene­
razione dev’essere eseguito con esito positivo.
Nota: per le chiavi di sessione di seconda generazione
cfr. appendice 11, CSM_193 e CSM_195. Se sono stabilite
chiavi di sessione di seconda generazione e la carta tachi­
grafica riceve il comando in chiaro INTERNAL AUTHEN­
TICATE APDU, la carta interrompe la sessione di messag­
gistica sicura di seconda generazione e distrugge le chiavi
di sessione di seconda generazione.
▼B
3.5.9 EXTERNAL AUTHENTICATE
Questo comando è conforme alla norma ISO/IEC 7816-4.
Utilizzando il comando EXTERNAL AUTHENTICATE, la carta può
autenticare l'IFD. Il processo di autenticazione è descritto nell'appen­
dice 11 per i tachigrafi di prima e di seconda generazione (autentica­
zione della VU).
TCS_96 La variante di comando per il meccanismo di autentica­
zione reciproca di prima generazione è supportata solo da
un'applicazione tachigrafica di prima generazione.
▼M1
TCS_97 La variante di comando per l’autenticazione reciproca
VU-carta di seconda generazione può essere eseguita
nell’MF, nel DF Tachograph e nel DF Tachograph_G2,
cfr. anche TCS_34. Se questo comando EXTERNAL AU­
THENTICATE di seconda generazione ha esito positivo, la
chiave di sessione corrente di prima generazione, se pre­
sente, viene cancellata e non è più disponibile.
Nota: per le chiavi di sessione di seconda generazione
cfr. appendice 11, CSM_193 e CSM_195. Se sono stabilite
chiavi di sessione di seconda generazione e la carta tachi­
grafica riceve il comando in chiaro EXTERNAL AU­
THENTICATE APDU, la carta interrompe la sessione di
messaggistica sicura di seconda generazione e distrugge le
chiavi di sessione di seconda generazione.
▼B
TCS_98 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h» CLA
INS 1 «82h» INS
P1 1 «00h» Chiavi e algoritmi implicitamente noti
P2 1 «00h»
Lc 1 «XXh» Lc (lunghezza dei dati inviati alla carta)
#6-#(5+L) L «XX..XXh» Autenticazione di prima generazione: crittogramma (cfr.
appendice 11, parte A)
Autenticazione di seconda generazione: firma generata
dall'IFD (cfr. appendice 11, parte B)
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 266
TCS_99 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se il CHA della chiave pubblica impostata non è il
concatenamento dell'AID dell'applicazione tachigrafica
e di un tipo di apparecchio VU, lo stato di elaborazione
inviato in risposta è «6F00».
— Se il comando non è immediatamente preceduto da un
comando GET CHALLENGE, lo stato di elaborazione
inviato in risposta è «6985».
L'applicazione tachigrafica di prima generazione può in­
viare in risposta gli ulteriori codici di errore a seguire:
— Se nell'ambiente di sicurezza non è presente una chiave
pubblica, viene inviato in risposta «6A88».
— Se nell'ambiente di sicurezza non è presente una chiave
privata, lo stato di elaborazione inviato in risposta è
«6A88».
— Se la verifica del crittogramma è errata, lo stato di
elaborazione inviato in risposta è «6688».
— Se la chiave privata selezionata è considerata danneg­
giata, lo stato di elaborazione inviato in risposta è
«6400» o «6581».
La variante di comando per l'autenticazione di seconda ge­
nerazione può inviare in risposta il seguente codice di er­
rore supplementare:
— Se la verifica della firma non è andata a buon fine, la
carta invia in risposta «6300».
3.5.10 GENERAL AUTHENTICATE
Questo comando è usato per il protocollo di autenticazione del chip
di seconda generazione specificato nell'appendice 11, parte B, ed è
conforme alla norma ISO/IEC 7816-4.
TCS_100 Il comando può essere eseguito nell'MF, in DF Tachograph
e in DF Tachograph_G2, cfr. anche TCS_34.
TCS_101 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «86h»
P1 1 «00h» Chiavi e protocollo implicitamente noti
P2 1 «00h»
Lc 1 «NNh» Lc: lunghezza del campo di dati successivo
#6-#(5+L) L «7Ch» + L 7C +
«80h» + L 80 +
«XX..XXh»
Valore della chiave pubblica temporanea codificato
DER-TLV (cfr. appendice 11)
La VU deve inviare gli oggetti di dati in quest'ordine
▼M3
Le 1 «00h» Secondo la norma ISO/IEC 7816-4
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 267
TCS_102 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
#1-#L L «7Ch» + L 7C +
«81h» + «08h» +
«XX..XXh» + «82h»
+ L 82 + «XX..XXh»
Dati di autenticazione dinamica codificati
DER-TLV: nonce e token di autenticazione
(cfr. appendice 11)
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— La carta invia in risposta «6A80» per indicare parametri
errati nel campo di dati.
— La carta invia in risposta «6982» se il comando Exter­
nal Authenticate non è stato eseguito correttamente.
L'oggetto di dati di autenticazione dinamica della risposta
«7Ch»:
— deve essere presente se l'operazione è riuscita, vale a
dire se le parole di stato sono «9000»,
— deve essere assente in caso di errore di esecuzione o di
controllo, vale a dire se le parole di stato rientrano
nell'intervallo «6400» — «6FFF» e
— può essere assente in caso di avvertimento, vale a dire
se le parole di stato rientrano nell'intervallo «6200» —
«63FFF».
3.5.11 MANAGE SECURITY ENVIRONMENT
Questo comando è usato per impostare una chiave pubblica a scopo di
autenticazione.
3.5.11.1 C o p p i a c o m a n d o - r i s p o s t a d i p r i m a g e n e r a z i o n e
Questo comando è conforme alla norma ISO/IEC 7816-4. L'uso del
comando è limitato rispetto a quello previsto dalla norma.
TCS_103 Questo comando è supportato solo da un'applicazione ta­
chigrafica di prima generazione.
TCS_104 La chiave indicata nel campo di dati MSE rimane la chiave
pubblica corrente fino al successivo comando MSE cor­
retto, finché non si seleziona un DF o non si azzera la
carta.
TCS_105 Se la chiave indicata non è (già) presente nella carta, l'am­
biente di sicurezza resta invariato.
TCS_106 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h» CLA
INS 1 «22h» INS
P1 1 «C1h» P1: chiave indicata valida per tutte le operazioni critto­
grafiche
P2 1 «B6h» P2: dati indicati riguardanti la firma digitale
Lc 1 «0Ah» Lc: lunghezza del campo di dati successivo
#6 1 «83h» Tag per indicare una chiave pubblica in casi asimmetrici
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 268
Byte
Lun­
ghezza
Valore Descrizione
#7 1 «08h» Lunghezza del riferimento della chiave (identificativo
della chiave)
#8-#15 8 «XX..XXh» Identificativo della chiave, secondo quanto specificato
nell'appendice 11
TCS_107 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se la chiave indicata non è presente nella carta, lo stato
di elaborazione inviato in risposta è «6A88».
— Se mancano alcuni oggetti di dati attesi nel formato di
messaggistica sicura, viene inviato in risposta lo stato di
elaborazione «6987». Ciò si può verificare se manca il
tag «83h».
— Se alcuni oggetti di dati non sono corretti, lo stato di
elaborazione inviato in risposta è «6988». Ciò si può
verificare se la lunghezza dell'identificativo della chiave
è diversa da «08h».
— Se la chiave selezionata è considerata danneggiata, lo
stato di elaborazione inviato in risposta è «6400» o
«6581».
3.5.11.2 C o p p i e c o m a n d o - r i s p o s t a d i s e c o n d a g e n e r a z i o n e
Per l'autenticazione di seconda generazione, la carta tachigrafica sup­
porta le seguenti versioni del comando MSE: SET, che sono conformi
alla norma ISO/IEC 7816-4. Queste versioni di comando non sono
supportate per l'autenticazione di prima generazione.
3.5.11.2.1 M S E : S E T A T p e r l ' a u t e n t i c a z i o n e d e l c h i p
Il seguente comando MSE:SET AT è usato per selezionare i parametri
per l'autenticazione del chip, che è eseguita da un comando successivo
General Authenticate.
TCS_108 Il comando può essere eseguito nell'MF, in DF Tachograph
e in DF Tachograph_G2, cfr. anche TCS_34.
TCS_109 Messaggio di comando MSE:SET AT per l'autentica­
zione del chip
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «22h»
P1 1 «41h» Impostato per l'autenticazione interna
P2 1 «A4h» Autenticazione
Lc 1 «NNh» Lc: lunghezza del campo di dati successivo
#6-#(5+L) L «80h» +
«0Ah» +
«XX..XXh»
Riferimento del meccanismo crittografico codificato
DER-TLV: identificativo dell'oggetto dell'autenticazione
del chip (solo valore, il tag «06h» è omesso).
Cfr. appendice 1 per i valori degli identificativi degli
oggetti; si deve usare la notazione in byte. Cfr.
appendice 11 per informazioni su come scegliere uno
di questi identificativi degli oggetti.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 269
3.5.11.2.2 M S E : S E T A T p e r l ' a u t e n t i c a z i o n e d e l l a V U
Il seguente comando MSE:SET AT è usato per selezionare i parametri
e le chiavi per l'autenticazione della VU, che è eseguita da un co­
mando successivo General Authenticate.
TCS_110 Il comando può essere eseguito nell'MF, in DF Tachograph
e in DF Tachograph_G2, cfr. anche TCS_34.
TCS_111 Messaggio di comando MSE:SET AT per l'autentica­
zione della VU
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «22h»
P1 1 «81h» Impostato per l'autenticazione esterna
P2 1 «A4h» Autenticazione
Lc 1 «NNh» Lc: lunghezza del campo di dati successivo
#6-#(5+L) L «80h» +
«0Ah» +
«XX..XXh»
Riferimento del meccanismo crittografico codificato
DER-TLV: identificativo dell'oggetto dell'autenticazione
della VU (solo valore, il tag «06h» è omesso).
Cfr. appendice 1 per i valori degli identificativi degli
oggetti; si deve usare la notazione in byte. Cfr.
appendice 11 per informazioni su come scegliere uno
di questi identificativi degli oggetti.
«83h» +
«08h» +
«XX..XXh»
Riferimento codificato DER-TLV della chiave pubblica
della VU da parte del Certificate Holder Reference indi­
cato nel rispettivo certificato
«91h» +
L 91 +
«XX..XXh»
Rappresentazione compressa codificata DER-TLV della
chiave pubblica temporanea della VU che sarà usata du­
rante l'autenticazione del chip (cfr. appendice 11)
3.5.11.2.3 M S E : S E T D S T
Il seguente comando MSE:SET DST è usato per impostare una chiave
pubblica:
— per la verifica di una firma che figura in un PSO successivo:
comando Verify Digital Signature o
— per la verifica della firma di un certificato che figura in un PSO
successivo: comando Verify Certificate
TCS_112 Il comando può essere eseguito in MF, DF Tachograph e
DF Tachograph_G2, cfr. anche TCS_33.
TCS_113 Messaggio di comando MSE:SET DST
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h»
INS 1 «22h»
P1 1 «81h» Impostato per la verifica
P2 1 «B6h» Firma digitale
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 270
Byte
Lun­
ghezza
Valore Descrizione
Lc 1 «NNh» Lc: lunghezza del campo di dati successivo
#6-#(5+L) L «83h» + «08h»
+ «XX...XXh»
Riferimento codificato DER-TLV di una chiave pub­
blica, vale a dire il Certificate Holder Reference nel
certificato della chiave pubblica (cfr. appendice 11)
Per tutte le versioni di comando, la struttura del messaggio di risposta
e le parole di stato sono date da:
TCS_114 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000». Il protocollo è stato selezionato e inizializzato.
— «6A80» indica parametri non corretti nel campo di dati
del comando.
— «6A88» indica che i dati indicati (ossia una chiave
indicata) non sono disponibili.
▼M1
— Se il currentAuthenticatedTime della carta è successivo
alla data di scadenza della chiave pubblica selezionata,
lo stato di elaborazione inviato in risposta è «6A88».
Nota: in caso di comando MSE: SET AT per l’autentica­
zione della VU, la chiave indicata è una chiave pubblica
VU_MA. La carta deve impostare la chiave pubblica
VU_MA per l’uso, se disponibile nella sua memoria, che
coincide con il riferimento del titolare del certificato (CHR)
indicato nel campo di dati del comando (la carta può iden­
tificare le chiavi pubbliche VU_MA tramite il campo CHA
del comando). Se è disponibile solo la chiave pubblica
VU_Sign o se non è disponibile alcuna chiave pubblica
dell’unità elettronica di bordo, in risposta a questo comando
la carta deve inviare lo stato «6A88». Cfr. la definizione
del campo CHA nell’appendice 11 e la definizione del tipo
di dati equipmentType nell’appendice 1.
Allo stesso modo, qualora venga inviata a una carta di
controllo un comando MSE: SET DST con un riferimento
a un EQT (cioè una VU o una carta), conformemente a
CSM_234, la chiave indicata è sempre una chiave
EQT_Sign che va utilizzata per la verifica di una firma
digitale. Come illustrato nella figura 13 dell’appendice
11, la carta di controllo avrà sempre memorizzato la chiave
pubblica EQT_Sign pertinente. In alcuni casi la carta di
controllo potrebbe aver memorizzato la chiave pubblica
EQT_MA corrispondente. La carta di controllo deve sem­
pre impostare l’uso della chiave pubblica EQT_Sign
quando riceve il comando MSE: SET DST.
▼B
3.5.12 PSO: HASH
Questo comando si usa per trasferire alla carta il risultato del calcolo
di una funzione di hash di alcuni dati. Questo comando è usato per
verificare le firme digitali. Il valore di hash è memorizzato tempora­
neamente per il successivo comando PSO: Verify Digital Signature
Questo comando è conforme alla norma ISO/IEC 7816-8. L'uso del
comando è limitato rispetto a quello previsto dalla norma.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 271
Solo la carta di controllo deve supportare questo comando in DF
Tachograph e DF Tachograph_G2.
Altri tipi di carte tachigrafiche possono eseguire o meno questo co­
mando. Il comando può essere accessibile o meno nell'MF.
L'applicazione della carta di controllo di prima generazione supporta
solo SHA-1.
TCS_115 Il valore di hash temporaneamente memorizzato deve es­
sere cancellato se è calcolato un nuovo valore di hash
tramite il comando PSO: HASH, se un DF è selezionato
e se la carta tachigrafica è azzerata.
TCS_116 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h» CLA
INS 1 «2Ah» Esecuzione operazione di sicurezza
P1 1 «90h» Codice Hash di risposta
P2 1 «A0h» Tag: il campo dati contiene DO interessati alla funzione
di hash
Lc 1 «XXh» Lunghezza Lc del campo di dati successivo
#6 1 «90h» Tag per il codice hash
#7 1 «XXh» Lunghezza L del codice hash:
«14h» nell'applicazione di prima generazione (cfr.
appendice 11, parte A)
«20h», «30h» o «40h» nell'applicazione di seconda ge­
nerazione (cfr. appendice 11, parte B)
#8-#(7+L) L «XX..XXh» Codice hash
TCS_117 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se mancano alcuni oggetti di dati attesi (secondo
quanto sopra specificato), viene inviato in risposta lo
stato di elaborazione «6987». Ciò si può verificare se
manca uno dei tag «90h».
— Se alcuni oggetti di dati non sono corretti, lo stato di
elaborazione inviato in risposta è «6988». Questo errore
si verifica se il tag richiesto è presente, ma con una
lunghezza diversa da «14h» per SHA-1, «20h» per
SHA-256, «30h» per SHA-384 e «40h» per SHA-512
(applicazione di seconda generazione).
3.5.13 PERFORM HASH of FILE
Questo comando non è conforme alla norma ISO/IEC 7816-8. Per­
tanto il byte CLA di questo comando indica che il comando PER­
FORM SECURITY OPERATION/HASH viene utilizzato in modo
esclusivo e riservato.
Solo la carta del conducente e la carta dell'officina devono supportare
questo comando in DF Tachograph e DF Tachograph_G2.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 272
Altri tipi di carte tachigrafiche possono eseguire o meno questo co­
mando. Se una carta dell'azienda o una carta di controllo esegue
questo comando, il comando deve essere eseguito come specificato
nel presente capitolo.
Il comando può essere accessibile o meno nell'MF. Se lo è, il co­
mando deve essere eseguito come specificato nel presente capitolo,
vale a dire non deve consentire il calcolo di un valore di hash, ma
deve finire con un codice di errore opportuno.
TCS_118 Il comando PERFORM HASH of FILE è usato per eseguire la
funzione di hash dell'area di dati dell'EF trasparente selezionato.
TCS_119 Una carta tachigrafica deve supportare questo comando solo
per gli EF che sono elencati nel capitolo 4 sotto DF_Tacho­
graph e DF_Tachograph_G2 con la seguente eccezione. Una
carta tachigrafica non deve supportare il comando per Sen­
sor_Installation_Data dell'EF di DF Tachograph_G2.
TCS_120 Il risultato dell'operazione di hash è memorizzato tempora­
neamente nella carta. Può poi essere usato per ottenere una
firma digitale del file, utilizzando il comando PSO: COM­
PUTE DIGITAL SIGNATURE.
▼M1
TCS_121 Il valore Hash of File temporaneamente memorizzato deve
essere cancellato se è calcolato un nuovo valore Hash of
File tramite il comando PERFORM HASH of FILE, se è
selezionato un DF o se la carta tachigrafica è azzerata.
▼B
TCS_122 L'applicazione del tachigrafo di prima generazione deve
supportare SHA-1.
▼M1
TCS_123 L’applicazione del tachigrafo di seconda generazione deve sup­
portare l’algoritmo SHA-2 (SHA-256, SHA-384 o SHA-512),
specificato dalla sequenza crittografica di cui all’appendice 11,
parte B, per la chiave di firma della carta Card_Sign.
▼B
TCS_124 Messaggio di comando
▼M1
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «80h» CLA
INS 1 «2Ah» Esecuzione operazione di sicurezza
P1 1 «90h» Tag: Hash
P2 1 «00h» Algoritmo implicitamente noto
Per l’applicazione tachigrafica di prima generazione: SHA-1
Per l’applicazione tachigrafica di seconda generazione: l’al­
goritmo SHA-2, (SHA-256, SHA-384 o SHA-512), speci­
ficato dalla sequenza crittografica di cui all’appendice 11,
parte B, per la chiave di firma della carta Card_Sign.
▼B
TCS_125 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se l'EF corrente non consente questo comando (EF
Sensor_Installation_Data in DF Tachograph_G2), lo
stato di elaborazione inviato in risposta è «6985».
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 273
— Se l'EF selezionato è considerato danneggiato (errori
d'integrità negli attributi del file o nei dati registrati),
lo stato di elaborazione inviato in risposta è «6400» o
«6581».
— Se il file selezionato non è un file trasparente o se non
c'è nessun EF corrente, lo stato di elaborazione inviato
in risposta è «6986».
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE
▼M1
Questo comando è usato per calcolare la firma digitale del codice hash
precedentemente calcolato (cfr. PERFORM HASH OF FILE, al
punto 3.5.13).
Solo la carta del conducente e la carta dell’officina devono supportare
questo comando nel DF Tachograph e nel DF Tachograph_G2.
Altri tipi di carte tachigrafiche possono eseguire o meno questo co­
mando. Nel caso dell’applicazione dei tachigrafi di seconda genera­
zione, solo la carta del conducente e la carta dell’officina dispongono
di una chiave di firma di seconda generazione; altre carte non sono in
grado di eseguire il comando e di terminare con un codice di errore
idoneo.
Il comando può essere accessibile o meno nell’MF. Se il comando
non è accessibile nell’MF, deve terminare con un codice di errore
idoneo.
Questo comando è conforme alla norma ISO/IEC 7816-8. Il suo uso è
limitato rispetto a quello previsto dalla norma.
▼B
TCS_126 Questo comando non deve calcolare una firma digitale di
un codice hash precedentemente calcolato con il comando
PSO: HASH.
TCS_127 La chiave privata della carta è usata per calcolare la firma
digitale ed è implicitamente nota alla carta.
TCS_128 L'applicazione tachigrafica di prima generazione esegue
una firma digitale utilizzando un metodo di riempimento
conforme a PKCS1 (cfr. appendice 11 per ulteriori partico­
lari).
TCS_129 L'applicazione tachigrafica di seconda generazione calcola
una firma digitale basata su una curva ellittica (cfr.
appendice 11 per ulteriori particolari).
TCS_130 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h» CLA
INS 1 «2Ah» Esecuzione operazione di sicurezza
P1 1 «9Eh» Firma digitale da inviare in risposta
P2 1 «9Ah» Tag: il campo di dati contiene dati da firmare. Poiché
non è incluso un campo di dati, i dati sono considerati
già presenti nella carta (hash del file)
Le 1 «NNh» Lunghezza della firma attesa
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 274
TCS_131 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
#1-#L L «XX..XXh» Firma dell'hash precedentemente calcolato
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se la chiave privata implicitamente selezionata è consi­
derata danneggiata, lo stato di elaborazione inviato in
risposta è «6400» o «6581».
— Se l'hash calcolato in un precedente comando Perform
Hash of File non è disponibile, lo stato di elaborazione
inviato in risposta è «6985».
3.5.15 PSO: VERIFY DIGITAL SIGNATURE
Questo comando si usa per verificare la firma digitale, fornita come
un input, il cui hash è noto alla carta. L'algoritmo della firma è
implicitamente noto alla carta.
Questo comando è conforme alla norma ISO/IEC 7816-8. L'uso del
comando è limitato rispetto a quello previsto dalla norma.
Solo la carta di controllo deve supportare questo comando in DF
Tachograph e DF Tachograph_G2.
Altri tipi di carte tachigrafiche possono eseguire o meno questo co­
mando. Il comando può essere accessibile o meno nell'MF.
TCS_132 Il comando VERIFY DIGITAL SIGNATURE usa sempre
la chiave pubblica selezionata dal precedente comando
MSE: Set DST e il codice hash precedente inserito da un
comando PSO: HASH.
TCS_133 Messaggio di comando
▼M1
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «00h» CLA
INS 1 «2Ah» Esecuzione operazione di sicurezza
P1 1 «00h»
P2 1 «A8h» Tag: il campo di dati contiene DO pertinenti per la ve­
rifica
Lc 1 «XXh» Lunghezza Lc del campo di dati successivo
#6 1 «9Eh» Tag per la firma digitale
#7 o
#7-#8
L «NNh» o
«81 NNh»
Lunghezza della firma digitale (L è 2 byte se la firma
digitale è più lunga di 127 byte):
128 byte codificati conformemente all’appendice 11,
parte A, per l’applicazione tachigrafica di prima
generazione.
Secondo la curva selezionata per l’applicazione tachigra­
fica di seconda generazione (cfr. appendice 11, parte B)
#(7+L)-
#(6+L+NN)
NN «XX..XXh» Contenuto della firma digitale
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 275
TCS_134 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— Se la verifica della firma fallisce, lo stato di elabora­
zione inviato in risposta è «6688». Il processo di veri­
fica è descritto nell'appendice 11.
— Se non è selezionata nessuna chiave pubblica, lo stato
di elaborazione inviato in risposta è «6A88».
— Se mancano alcuni oggetti di dati attesi (secondo
quanto sopra specificato), viene inviato in risposta lo
stato di elaborazione «6987». Ciò si può verificare se
manca uno dei tag richiesti.
— Se non è disponibile un codice hash per elaborare il
comando (in conseguenza di un comando PSO: HASH
precedente), lo stato di elaborazione inviato in risposta
è «6985».
— Se alcuni oggetti di dati non sono corretti, lo stato di
elaborazione inviato in risposta è «6988». Ciò si può
verificare se la lunghezza di uno degli oggetti di dati
richiesti non è corretta.
— Se la chiave pubblica selezionata è considerata danneg­
giata, lo stato di elaborazione inviato in risposta è
«6400» o «6581».
▼M1
— Se la chiave pubblica selezionata (usata per verificare la
firma digitale) ha una CHA.LSB (CertificateHolderAu­
thorisation.equipmentType) non idonea alla verifica
della firma digitale secondo l’appendice 11, lo stato di
elaborazione inviato in risposta è «6985».
▼B
3.5.16 PROCESS DSRC MESSAGE
Questo comando è usato per verificare l'integrità e l'autenticità del
messaggio DSRC e per decifrare i dati comunicati da una VU a
un'autorità di controllo o a un'officina tramite il link DSRC. La carta
calcola la chiave di cifratura e la chiave del MAC utilizzate per
rendere sicuro il messaggio DSRC, come descritto nell'appendice
11, parte B, capitolo 13.
Solo la carta di controllo e la carta dell'officina devono supportare
questo comando in DF Tachograph_G2.
Altri tipi di carte tachigrafiche possono eseguire o meno questo co­
mando, ma non devono avere una chiave master DSRC. Tali carte
quindi non possono eseguire il comando correttamente, ma finiscono
con un codice di errore idoneo.
Il comando può essere accessibile o meno nell'MF e/o in DF Tacho­
graph. Se lo è, il comando deve finire con un codice di errore idoneo.
TCS_135 La chiave master DSRC è accessibile solo in DF Tacho­
graph_G2, vale a dire che la carta di controllo e la carta
dell'officina devono supportare un'esecuzione corretta del
comando solo in DF Tachograph_G2.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 276
TCS_136 Il comando deve solo decriptare i dati DSRC e verificare il
totale di controllo crittografico, ma non deve interpretare i
dati in ingresso.
TCS_137 L'ordine degli oggetti di dati nel campo di dati del co­
mando è fissato nelle presenti specifiche.
TCS_138 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «80h» CLA proprietaria
INS 1 «2Ah» Esecuzione operazione di sicurezza
P1 1 «80h» Dati della risposta: valore in chiaro
P2 1 «B0h» Dati del comando: valore in chiaro codificato in
BER-TLV e comprendente DO SM
Lc 1 «NNh» Lunghezza Lc del campo di dati successivo
#6-#(5+L) L «87h» + L 87 +
«XX..XXh»
Byte indicatore di contenuto di riempimento codificato
DER-TLV seguito dal payload criptato del tachigrafo.
Per il byte indicatore di contenuto di riempimento si
deve usare il valore «00h» («nessuna ulteriore indica­
zione» secondo la norma ISO/IEC 7816-4: 2013, tabella
52). Per il meccanismo di cifratura, cfr. appendice 11,
parte B, capitolo 13.
I valori consentiti per la lunghezza L 87 sono i multipli
della lunghezza dei blocchi AES più 1 per il byte indi­
catore di contenuto di riempimento, vale a dire da 17
byte fino a 193 byte compresi.
Nota: cfr. ISO/IEC 7816-4: 2013, tabella 49, per l'og­
getto di dati SM con tag «87h».
«81h» +
«10h»
Modello di controllo di riferimento per la riservatezza
codificato DER-TLV che annida la concatenazione dei
seguenti elementi di dati (cfr. appendice 1 DSRCSecuri­
tyData e appendice 11, parte B, capitolo 13):
— time stamp: 4 byte
— contatore: 3 byte
— numero di serie della VU: 8 byte
— versione della chiave master DSRC: 1 byte
Nota: cfr. ISO/IEC 7816-4: 2013, tabella 49, per l'og­
getto di dati SM con tag «81h».
«8Eh» + L 8E +
«XX..XXh»
MAC codificato DER-TLV sul messaggio DSRC. Per
l'algoritmo e il calcolo del MAC, cfr. appendice 11, parte
B, capitolo 13.
Nota: cfr. ISO/IEC 7816-4: 2013, tabella 49, per l'og­
getto di dati SM con tag «8Eh».
▼M3
Le 1 «00h» Secondo la norma ISO/IEC 7816-4
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 277
TCS_139 Messaggio di risposta
Byte
Lun­
ghezza
Valore Descrizione
#1-#L L «XX..XXh» Assente (in caso di errore) o dati decodificati (riempi­
mento eliminato)
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, la carta risponde
«9000».
— «6A80» indica parametri non corretti nel campo di dati
del comando (usato anche nel caso in cui gli oggetti di
dati non siano inviati nell'ordine specificato).
— «6A88» indica che i dati indicati non sono disponibili,
vale a dire che la chiave master DSRC indicata non è
disponibile.
— «6900» indica che la verifica del totale di controllo
crittografico o la decifrazione dei dati non è andata a
buon fine.
▼M1
— «6985» indica che il time stamp di 4 byte riportato nel
campo di dati del comando è anteriore a cardValidity­
Begin o posteriore a cardExpiryDate.
▼B
4. STRUTTURA DELLE CARTE TACHIGRAFICHE
Il presente paragrafo specifica le strutture dei file delle carte tachi­
grafiche per la memorizzazione di dati accessibili.
Non specifica le strutture interne, che dipendono dal fabbricante
della carta, come per esempio le intestazioni dei file, né la memorizzazione
e la gestione degli elementi di dati necessari solo per uso interno, quali
o .
TCS_140 Una carta tachigrafica di seconda generazione deve ospitare
il master file MF e un'applicazione tachigrafica di prima e
di seconda generazione dello stesso tipo (ad esempio le
applicazioni della carta del conducente).
TCS_141 Una carta tachigrafica deve supportare almeno il numero
minimo di registrazioni specificate per le applicazioni corri­
spondenti e non deve supportare più registrazioni rispetto al
numero massimo di registrazioni specificato per le applica­
zioni corrispondenti.
▼M3
Il numero massimo e il numero minimo di registrazioni
sono specificati nel presente capitolo per le diverse appli­
cazioni. Nelle carte del conducente e dell’officina di se­
conda generazione, versione 2, l’applicazione di prima ge­
nerazione deve supportare il numero massimo di registra­
zioni specificato in TCS_150 e TCS_158.
▼B
Per le condizioni di sicurezza usate nelle norme di accesso
nel presente capitolo si rimanda al capitolo 3.3. In generale,
la modalità di accesso «leggi» indica il comando READ
BINARY con il byte INS pari e, se supportato, dispari, ad
eccezione di EF Sensor_Installation_Data sulla carta dell'of­
ficina, cfr. TCS_156 e TCS_160. La modalità di accesso
«aggiorna» indica il comando UPDATE BINARY con il
byte INS pari e, se supportato, dispari, e la modalità di
accesso «seleziona» in dica il comando SELECT.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 278
4.1. Master file MF
TCS_142 Dopo la personalizzazione, il master file MF deve avere la struttura
dei file e le regole di accesso ai file permanenti a seguire:
Nota: l'identificativo breve dell'EF SFID è indicato come
numero decimale: ad esempio, il valore 30 corrisponde a
11110 in formato binario.
Nella tabella a seguire si usa la seguente abbreviazione per
le condizioni di sicurezza:
SC1 ALW OR SM-MAC-G2
TCS_143 Le strutture di tutti gli EF devono essere trasparenti.
TCS_144 Il file principale MF deve avere la struttura dei dati seguente:
TCS_145 Il file elementare EF DIR deve contenere i seguenti oggetti
di dati relativi all'applicazione: «61 08 4F 06 FF 54 41 43
48 4F 61 08 4F 06 FF 53 4D 52 44 54»
TCS_146 Il file elementare EF ATR/INFO deve essere presente se la
carta tachigrafica indica nella sua ATR che supporta campi
di lunghezza estesa. In questo caso, EF ATR/INFO deve
contenere l'oggetto di dati di informazioni di lunghezza
estesa (DO«7F66»), come specificato nella norma ISO/IEC
7816-4:2013, clausola 12.7.1.
TCS_147 Il file elementare EF Extended_Length deve essere presente
se la carta tachigrafica indica nella sua ATR che supporta
campi di lunghezza estesa. In questo caso l'EF deve conte­
nere il seguente oggetto di dati: «02 01 xx» dove il valore
«xx» indica se i campi di lunghezza estesa sono supportati
per il protocollo T = 1 e / o T = 0.
Il valore «01» indica che i campi di lunghezza estesa sono
supportati per il protocollo T = 1.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 279
Il valore «10» indica che i campi di lunghezza estesa sono
supportati per il protocollo T = 0.
Il valore «11» indica che i campi di lunghezza estesa sono
supportati per il protocollo T = 1 e T = 0.
4.2. Applicazioni della carta del conducente
4.2.1 Applicazione della carta del conducente di prima generazione
TCS_148 Dopo la personalizzazione, l'applicazione della carta del
conducente di prima generazione deve avere la struttura
dei file e le regole di accesso permanenti a seguire.
Nella tabella a seguire si usano le seguenti abbreviazioni
per le condizioni di sicurezza:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
TCS_149 Le strutture di tutti gli EF devono essere trasparenti.
TCS_150 L'applicazione della carta del conducente di prima genera­
zione deve avere la seguente struttura dei dati:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 280
► (1) (2) M3
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 281
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 282
TCS_151 I valori sotto indicati, usati per fornire le dimensioni nella
tabella precedente, sono i valori minimo e massimo del
numero di registrazioni che la struttura dei dati della carta
del conducente deve utilizzare per un'applicazione di prima
generazione:
4.2.2 Applicazione della carta del conducente di seconda generazione
▼M3
TCS_152 Dopo la personalizzazione, l’applicazione della carta del
conducente di seconda generazione deve avere la struttura
dei file e le regole di accesso permanenti indicate di
seguito.
Note:
— l’identificativo breve dell’EF SFID è indicato come nu­
mero decimale: ad esempio, il valore 30 corrisponde
a 11110 in formato binario.
— EF Application_Identification_V2, EF Places_Authenti­
cation, EF GNSS_Places_Authentication, EF Bor­
der_Crossings, EF Load_Unload_Operations, EF
VU_Configuration ed EF Load_Type_Entries sono pre­
senti solo nella versione 2 della carta del conducente
di seconda generazione.
— cardStructureVersion in EF Application_Identification è
uguale a {01 01} per la versione 2 della carta del
conducente di seconda generazione, mentre era uguale
a {01 00} per la versione 1 della carta del conducente
di seconda generazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 283
Nella tabella sono usate le seguenti abbreviazioni per le
condizioni di sicurezza:
SC1 ALW OR SM-MAC-G2
SC5 Per il comando Read Binary con byte INS pari:
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
Per il comando Read Binary con byte INS dispari
(se supportato): NEV
▼B
TCS_153 Le strutture di tutti gli EF devono essere trasparenti.
▼M3
TCS_154 L’applicazione della carta del conducente di seconda gene­
razione deve avere la seguente struttura dei dati:
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 284
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 285
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 286
TCS_155 I valori sotto indicati, usati per fornire le dimensioni nella
tabella precedente, sono i valori minimo e massimo del
numero di registrazioni che la struttura dei dati della carta
del conducente deve utilizzare per un'applicazione di se­
conda generazione:
▼M3
Min Max
n 1 NoOfEventsPerType 12 12
n 2 NoOfFaultsPerType 24 24
n 3 NoOfCardVehicleRecords 200 200
n 4 NoOfCardPlaceRecords 112 112
n 6 CardActivityLengthRange 13776 byte
(56 giorni * 117 cambi
di attività)
13776 byte
(56 giorni * 117 cambi
di attività)
n 7 NoOfCardVehicleUnitRecords 200 200
n 8 NoOfGNSSADRecords 336 336
n 9 NoOfSpecificConditionRecords 112 112
n 10 NoOfBorderCrossingRecords 1120 1120
n 11 NoOfLoadUnloadRecords 1624 1624
n 12 NoOfLoadTypeEntryRecords 336 336
n 13 VuConfigurationLengthRange 3072 byte 3072 byte
▼B
4.3. Applicazioni della carta dell'officina
4.3.1 Applicazione della carta dell'officina di prima generazione
TCS_156 Dopo la personalizzazione, l'applicazione della carta dell'of­
ficina di prima generazione deve avere la struttura dei file e
le regole di accesso permanenti a seguire.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 287
Nella tabella a seguire si usano le seguenti abbreviazioni
per le condizioni di sicurezza:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
▼M1
SC4 Per il comando READ BINARY con byte INS pari:
(SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR
(SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)
Per il comando READ BINARY con byte INS di­
spari (se supportato): NEV
▼B
TCS_157 Le strutture di tutti gli EF devono essere trasparenti.
TCS_158 L'applicazione della carta dell'officina di prima generazione
deve avere la seguente struttura dei dati:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 288
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 289
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 290
TCS_159 I valori sottoindicati, usati per fornire le dimensioni nella
tabella precedente, sono i valori minimo e massimo del
numero di registrazioni che la struttura dei dati della carta
dell'officina deve utilizzare per un'applicazione di prima
generazione:
4.3.2 Applicazione della carta dell'officina di seconda generazione
▼M3
TCS_160 Dopo la personalizzazione, l’applicazione della carta
dell’officina di seconda generazione deve avere la struttura
dei file e le regole di accesso permanenti indicate di
seguito.
Note:
— l’identificativo breve dell’EF SFID è indicato come nu­
mero decimale: ad esempio, il valore 30 corrisponde
a 11110 in formato binario.
— EF Application_Identification_V2, EF Places_Authenti­
cation, EF GNSS_Places_Authentication, EF Bor­
der_Crossings, EF Load_Unload_Operations, EF
Load_Type_Entries, EF VU_Configuration ed EF Cali­
bration_Add_Data sono presenti solo nella versione 2
della carta dell’officina di seconda generazione.
— cardStructureVersion in EF Application_Identification è
uguale a {01 01} per la versione 2 della carta dell’of­
ficina di seconda generazione, mentre era uguale a {01
00} per la versione 1 della carta dell’officina di seconda
generazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 291
Nella tabella sono usate le seguenti abbreviazioni per le
condizioni di sicurezza:
SC1 ALW OR SM-MAC-G2
SC5 Per il comando Read Binary con byte INS pari:
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
Per il comando Read Binary con byte INS dispari
(se supportato): NEV
▼B
TCS_161 Le strutture di tutti gli EF devono essere trasparenti.
TCS_162 L'applicazione della carta dell'officina di seconda genera­
zione deve avere la seguente struttura dei dati:
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 292
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 293
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 294
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 295
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 296
TCS_163 I valori sotto indicati, usati per fornire le dimensioni nella
tabella precedente, sono i valori minimo e massimo del numero
di registrazioni che la struttura dei dati della carta dell'officina
deve utilizzare per un'applicazione di seconda generazione:
▼M3
Min Max
n 1 NoOfEventsPerType 3 3
n 2 NoOfFaultsPerType 6 6
n 3 NoOfCardVehicleRecords 8 8
n 4 NoOfCardPlaceRecords 8 8
n 5 NoOfCalibrationRecords 255 255
n 6 CardActivityLengthRange 492 byte (1 giorno *
240 cambi di attività)
492 byte (1 giorno *
240 cambi di attività)
n 7 NoOfCardVehicleUnitRecords 8 8
n 8 NoOfGNSSADRecords 24 24
n 9 NoOfSpecificConditionRecords 4 4
n 10 NoOfBorderCrossingRecords 4 4
n 11 NoOfLoadUnloadRecords 8 8
n 12 NoOfLoadTypeEntryRecords 4 4
n 13 VuConfigurationLengthRange 3072 byte 3072 byte
▼B
4.4. Applicazioni della carta di controllo
4.4.1 Applicazione della carta di controllo di prima generazione
TCS_164 Dopo la personalizzazione, l'applicazione della carta di con­
trollo di prima generazione deve avere la struttura dei file e
le regole di accesso permanenti a seguire.
Nella tabella a seguire si usano le seguenti abbreviazioni
per le condizioni di sicurezza:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
SC6 EXT-AUT-G1 OR SM-MAC-G1 OR SM-MAC-G2
TCS_165 Le strutture di tutti gli EF devono essere trasparenti.
TCS_166 L'applicazione della carta di controllo di prima generazione
deve avere la seguente struttura dei dati:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 297
TCS_167 I valori sotto indicati, usati per fornire le dimensioni nella
tabella precedente, sono i valori minimo e massimo del
numero di registrazioni che la struttura dei dati della carta
di controllo deve utilizzare per un'applicazione di prima
generazione:
4.4.2 Applicazione della carta di controllo di seconda generazione
▼M3
TCS_168 Dopo la personalizzazione, l’applicazione della carta di
controllo di seconda generazione deve avere la struttura
dei file e le regole di accesso permanenti indicate di
seguito.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 298
Note:
— l’identificativo breve dell’EF SFID è indicato come nu­
mero decimale: ad esempio, il valore 30 corrisponde
a 11110 in formato binario.
— EF Application_Identification_V2 e EF VU_Configura­
tion sono presenti solo nella versione 2 della carta di
controllo di seconda generazione.
— cardStructureVersion in EF Application_Identification è
uguale a {01 01} per la versione 2 della carta di con­
trollo di seconda generazione, mentre era uguale a {01
00} per la versione 1 della carta di controllo di seconda
generazione.
Nella tabella sono usate le seguenti abbreviazioni per le
condizioni di sicurezza:
SC1 ALW OR SM-MAC-G2
SC5 Per il comando Read Binary con byte INS pari:
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
Per il comando Read Binary con byte INS
dispari (se supportato): NEV
▼B
TCS_169 Le strutture di tutti gli EF devono essere trasparenti.
TCS_170 L'applicazione della carta di controllo di seconda genera­
zione deve avere la seguente struttura dei dati:
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 299
▼B TCS_171 I valori sotto indicati, usati per fornire le dimensioni nella tabella
precedente, sono i valori minimo e massimo del numero di
registrazioni che la struttura dei dati della carta di controllo
deve utilizzare per un'applicazione di seconda generazione:
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 300
Min Max
n 7 NoOfControlActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 byte 3072 byte
▼B
4.5. Applicazioni della carta dell'azienda
4.5.1 Applicazione della carta dell'azienda di prima generazione
TCS_172 Dopo la personalizzazione, l'applicazione della carta del­
l'azienda di prima generazione deve avere la struttura dei
file e le regole di accesso permanenti a seguire.
Nella tabella a seguire si usano le seguenti abbreviazioni
per le condizioni di sicurezza:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
SC6 EXT-AUT-G1 OR SM-MAC-G1 OR SM-MAC-
G2
TCS_173 Le strutture di tutti gli EF devono essere trasparenti.
TCS_174 L'applicazione della carta dell'azienda di prima genera­
zione deve avere la seguente struttura dei dati:
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 301
TCS_175 I valori sotto indicati, usati per fornire le dimensioni nella
tabella precedente, sono i valori minimo e massimo del
numero di registrazioni che la struttura dei dati della carta
dell'azienda deve utilizzare per un'applicazione di prima
generazione:
4.5.2 Applicazione della carta dell'azienda di seconda generazione
▼M3
TCS_176 Dopo la personalizzazione, l’applicazione della carta
dell’azienda di seconda generazione deve avere la strut­
tura dei file e le regole di accesso permanenti indicate di
seguito.
Note:
— l’identificativo breve dell’EF SFID è indicato come
numero decimale: ad esempio, il valore 30 corri­
sponde a 11110 in formato binario.
— EF Application_Identification_V2 e EF VU_Configu­
ration sono presenti solo nella versione 2 della carta
dell’azienda di seconda generazione.
— cardStructureVersion in EF Application_Identification
è uguale a {01 01} per la versione 2 della carta
dell’azienda di seconda generazione, mentre era
uguale a {01 00} per la versione 1 della carta
dell’azienda di seconda generazione.
Nella tabella sono usate le seguenti abbreviazioni per le
condizioni di sicurezza:
SC1 ALW OR SM-MAC-G2
SC5 Per il comando Read Binary con byte INS
pari: SM-C-MAC-G2 AND SM-R-ENC-
MAC-G2
Per il comando Read Binary con byte INS
dispari (se supportato): NEV
▼B
TCS_177 Le strutture di tutti gli EF devono essere trasparenti.
TCS_178 L'applicazione della carta dell'azienda di seconda genera­
zione deve avere la seguente struttura dei dati:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 302
▼B
TCS_179 I valori sotto indicati, usati per fornire le dimensioni nella
tabella precedente, sono i valori minimo e massimo del
numero di registrazioni che la struttura dei dati della carta
dell'azienda deve utilizzare per un'applicazione di seconda
generazione:
▼M3
Min Max
n 8 NoOfCompanyActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 byte 3072 byte
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 303
Appendice 3
PITTOGRAMMI
PIC_001 Il tachigrafo può usare facoltativamente i pittogrammi e le combina­
zioni di pittogrammi seguenti (o pittogrammi e combinazioni di pitto­
grammi sufficientemente simili da essere identificati senza ambiguità
con essi):
1. PITTOGRAMMI DI BASE
Persone Azioni Modalità di funziona­mento
Azienda Modalità azienda
Controllore Controllo Modalità controllo
Conducente Guida Modalità funzionamento
Officina/centro di prova Controllo/taratura Modalità taratura
Fabbricante
Attività Durata
Disponibile Periodo di disponibilità in corso
Guida Periodo di guida continuo
Riposo Periodo di riposo in corso
Altra attività Periodo di lavoro in corso
Interruzione Periodo cumulato di interruzione
Sconosciuto
Apparecchio Funzioni
Sede (slot) del conducente
Sede (slot) del secondo condu­
cente
Carta
Orologio
Dispositivo di visualizzazione Visualizzazione
Memoria esterna Trasferimento dati
Alimentazione
Stampante/stampa Stampa
Sensore
Dimensioni pneumatici
Veicolo/unità elettronica di
bordo
Dispositivo GNSS
Dispositivo di diagnosi remota
Interfaccia ITS
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 304
Condizioni particolari, immissioni manuali
Escluso dal campo di applicazione
Attraversamento mediante traghetto/treno
Operazione di carico
Operazione di scarico
Operazione di carico/scarico simultanei
Tipo di carico: passeggeri
Tipo di carico: merci
Tipo di carico: tipo di carico non definito
▼B
Varie
Anomalie Guasti
Inizio del periodo di lavoro giorna­
liero
Termine del periodo di lavoro
giornaliero
Posizione
Immissione manuale delle attività del
conducente
▼M3
Sicurezza/dati autenticati/sigilli
▼B
Velocità
Ora
Totale/riepilogo
▼M3
Mappa digitale/attraversamento di
frontiera
▼B
Indicatori
24h Giornaliero
Settimanale
Quindicinale
Da/a
2. COMBINAZIONI DI PITTOGRAMMI
Varie
Luogo di controllo
Luogo in cui inizia il periodo di la­
voro giornaliero
Luogo in cui termina il periodo
di lavoro giornaliero
▼M1
Posizione dopo 3 ore di periodo di
guida cumulativo
▼B
Dalle ore Alle ore
Dal veicolo
Escluso dal campo di applicazione —
Inizio
Escluso dal campo di applica­
zione — Fine
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 305
Posizione in cui il veicolo ha attraver­
sato la frontiera tra due paesi
Posizione in cui ha avuto luogo
un’operazione di carico
Posizione in cui ha avuto luogo
un’operazione di scarico
Posizione in cui ha avuto luogo
un’operazione di carico/scarico simul­
tanei
▼B
Carte
Carta del conducente
Carta dell'azienda
Carta di controllo
Carta dell'officina
Carta assente
Guida
Guida con equipaggio
Periodo di guida di una settimana
Periodo di guida di due settimane
Stampe
Stampa giornaliera delle attività del conducente contenute nella carta
Stampa giornaliera delle attività del conducente contenute nella VU
Stampa di anomalie e guasti contenuti nella carta
Stampa di anomalie e guasti contenuti nella VU
Stampa dei dati tecnici
Stampa dei superamenti di velocità
▼M3
Cronologia delle stampe relative alle carte inserite
▼B
Anomalie
Inserimento di una carta non valida
Conflitto di carte
Sovrapposizione di orari
Guida in assenza di una carta adeguata
Inserimento carta durante la guida
Chiusura errata ultima sessione carta
Superamento di velocità
Interruzione dell'alimentazione di energia
Errore dei dati di movimento
Dati contrastanti sul movimento del veicolo
Violazione della sicurezza
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 306
Dati contrastanti sull’ora o regolazione dell’ora (in officina)
▼B
Controllo superamento di velocità
▼M1
Assenza di informazioni sulla posizione provenienti dal ricevitore GNSS
o errore di comunicazione con il dispositivo GNSS esterno
Errore di comunicazione con il dispositivo di comunicazione remota
▼M3
Anomalia GNSS
▼B
Guasti
Guasto della carta (slot del conducente)
Guasto della carta (slot del secondo conducente)
Guasto del dispositivo di visualizzazione
Guasto nel trasferimento di dati
Guasto della stampante
Guasto del sensore
Guasto interno della VU
Guasto del GNSS
Guasto del dispositivo di diagnosi remota
Procedura di immissione manuale
Stesso periodo di lavoro giornaliero?
Termine del periodo di lavoro precedente?
Conferma o immissione del luogo in cui termina il periodo di lavoro
Immissione ora di inizio
Immissione del luogo in cui inizia il periodo di lavoro
Nota: nell'appendice 4 sono definite alcune combinazioni di pittogrammi
supplementari per creare blocchi di stampa o identificazioni delle
registrazioni.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 307
Appendice 4
STAMPE
INDICE
1. DATI GENERALI
2. SPECIFICHE DEI BLOCCHI DI DATI
3. SPECIFICHE DELLE STAMPE
3.1. Stampa giornaliera delle attività del conducente contenute nella carta
3.2. Stampa giornaliera delle attività del conducente contenute nella VU
3.3. Stampa di anomalie e guasti contenuti nella carta
3.4. Stampa di anomalie e guasti contenuti nella VU
3.5. Stampa dei dati tecnici
3.6. Stampa dei superamenti di velocità
3.7. Cronologia delle carte inserite
1. DATI GENERALI
Ogni stampa è realizzata mediante il concatenamento di diversi blocchi
di dati, possibilmente identificati da un identificativo di blocco.
Un blocco di dati contiene una o più registrazioni, possibilmente iden­
tificate da un identificativo di registrazione.
PRT_001 Se un identificativo di blocco precede direttamente un iden­
tificativo di registrazione, quest'ultima non viene stampata.
PRT_002 Nel caso in cui un elemento di dati non sia noto, o non debba
essere stampato per motivi riguardanti i diritti di accesso ai
dati, al suo posto vengono stampati degli spazi.
PRT_003 Se il contenuto di un'intera riga non è noto, o non deve essere
stampato, la riga viene omessa.
PRT_004 I campi contenenti dati numerici sono stampati con l'allinea­
mento a destra, con le migliaia e i milioni separati da uno
spazio e senza zeri iniziali.
▼M3
PRT_005 I campi contenenti stringhe di dati sono stampati con l’alli­
neamento a sinistra e riempiti da spazi fino a coprire l’intera
lunghezza dell’elemento di dati o, se necessario, troncati in
corrispondenza di tale lunghezza. I nomi e gli indirizzi pos­
sono essere stampati su due righe.
▼B
PRT_006 Nel caso in cui sia necessaria una interruzione di riga poiché
il testo è troppo lungo, è necessario stampare un carattere
speciale (punto mediano, «•») come primo carattere della
nuova riga.
2. SPECIFICHE DEI BLOCCHI DI DATI
Nel presente capitolo sono state usate le seguenti convenzioni
tipografiche:
— i caratteri in grassetto indicano il testo normale da stampare (nella
stampa non saranno in grassetto),
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 308
— i caratteri normali indicano le variabili (pittogrammi o dati), che
nella stampa saranno sostituiti con i rispettivi valori,
— i nomi delle variabili sono integrati da una sequenza di trattini bassi
che indicano la lunghezza dell'elemento di dati disponibile per la
variabile,
— le date sono indicate nel formato «dd/mm/yyyy» (giorno, mese,
anno); si può anche usare il formato «dd.mm.yyyy»,
— l'espressione «identificazione della carta» («card identification») in­
dica un elemento composto da: una combinazione di pittogrammi
della carta che indicano il tipo di carta, il codice dello Stato membro
che ha rilasciato la carta, una barra e il numero della carta con i
codici di sostituzione e di rinnovo separati da uno spazio:
P x x x / x x x x x x x x x x x x x x x x
C
om
bi
na
zi
on
e
di
p
it
to
gr
am
m
i
de
ll
a
ca
rt
a
C
od
ic
e
de
ll
o
S
ta
to

m
em
br
o
di
r
il
as
ci
o Primi 14 caratteri del numero della carta
(possibilmente comprendente un codice di serie)
C
od
ic
e
di
s
os
ti
tu
zi
on
e
C
od
ic
e
di
r
in
no
vo

▼M3
— in un blocco di dati, il testo che segue «pi=» si riferisce al pitto­
gramma o alla combinazione di pittogrammi corrispondente la cui
definizione è disponibile nell’appendice 3;
— se stampato dopo la longitudine e la latitudine di una posizione
registrata o dopo la marcatura oraria (timestamp) relativa al mo­
mento della determinazione della posizione, il pittogramma in­
dica che tale posizione è stata calcolata a partire da messaggi di
navigazione autenticati;
— * dati disponibili solo nei tachigrafi GEN2 (tutte le versioni),
— ** dati disponibili solo nei tachigrafi GEN2, versione 2.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 309
PRT_007 Le stampe usano i blocchi e/o le registrazioni di dati sotto riportati, in
base ai significati e formati seguenti:
► (1) (2) (3) (4) (5) M3
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 310
► (1) (2) (3) M3
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 311
► (1) (2) M3
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 312
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 313
► (1) (2) (3) (4) M3
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 314
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 315
► (1) M3
3. SPECIFICHE DELLE STAMPE
Nel presente capitolo sono state usate le seguenti convenzioni
tipografiche:
N Blocco di stampa o numero di registrazione N
N
Blocco di stampa o numero di registrazione N ripetuto tante volte
quante necessario
X/Y
Blocchi di stampa o registrazioni X e/o Y, a seconda della necessità,
ripetuti tante volte quante necessario
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 316
3.1. Stampa giornaliera delle attività del conducente contenute nella
carta
▼M3
PRT_008 La stampa giornaliera delle attività del conducente contenute
nella carta deve rispettare il formato seguente:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 317
3.2. Stampa giornaliera delle attività del conducente contenute nella VU
▼M3
PRT_009 La stampa giornaliera delle attività del conducente contenute
nella VU deve rispettare il formato seguente:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 318
3.3. Stampa di anomalie e guasti contenuti nella carta
PRT_010 La stampa di anomalie e guasti contenuti nella carta deve
rispettare il formato seguente:
1 Data e ora di stampa del documento
2 Tipo di stampa
3 Identificazione dell'agente incaricato del controllo (se una carta di
controllo è inserita nella VU + GEN)
3 Identificazione del conducente (dalla carta cui si riferisce la stampa)
4 Identificazione del veicolo (veicolo da cui si ottiene la stampa)
12.2 Delimitatore delle anomalie
12.4
Registrazioni delle anomalie (tutte le anomalie memorizzate nella
carta)
12.3 Delimitatore dei guasti
12.4
Registrazioni dei guasti (tutti i guasti memorizzati nella carta)
22.1 Luogo del controllo
22.2 Firma dell'agente incaricato del controllo
22.5 Firma del conducente
3.4. Stampa di anomalie e guasti contenuti nella VU
PRT_011 La stampa di anomalie e guasti contenuti nella VU deve
rispettare il formato seguente:
1 Data e ora di stampa del documento
2 Tipo di stampa
3
Identificazione del titolare della carta (per tutte le carte inserite nella
VU + GEN)
4 Identificazione del veicolo (veicolo da cui si ottiene la stampa)
13.2 Delimitatore delle anomalie
13.4
Registrazioni delle anomalie (tutte le anomalie memorizzate o in corso
nella VU)
13.3 Delimitatore dei guasti
13.4
Registrazioni dei guasti (tutti i guasti memorizzati o in corso nella
VU)
22.1 Luogo del controllo
22.2 Firma dell'agente incaricato del controllo
22.5 Firma del conducente
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 319
3.5. Stampa dei dati tecnici
▼M3
PRT_012 La stampa dei dati tecnici deve rispettare il formato seguente:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 320
3.6. Stampa dei superamenti di velocità
PRT_013 La stampa dei superamenti di velocità deve rispettare il for­
mato seguente:
1 Data e ora di stampa del documento
2 Tipo di stampa
3
Identificazione del titolare della carta (per tutte le carte inserite nella
VU + GEN)
4 Identificazione del veicolo (veicolo da cui si ottiene la stampa)
20 Informazioni relative al controllo dei superamenti di velocità
21.1 Identificativo dei dati relativi ai superamenti di velocità
21.4 / 21.5 Primo superamento di velocità successivo all'ultima taratura
21.2 Identificativo dei dati relativi ai superamenti di velocità
21.4 / 21.5
I 5 superamenti di velocità più gravi nel corso degli ultimi 365 giorni
21.3 Identificativo dei dati relativi ai superamenti di velocità
21.4 / 21.5 Il superamento di velocità più grave per ciascuno degli ultimi 10
giorni in cui si è verificato
22.1 Luogo del controllo
22.2 Firma dell'agente incaricato del controllo
22.5 Firma del conducente
3.7. Cronologia delle carte inserite
▼M3
PRT_014 La stampa della cronologia delle carte inserite deve rispettare
il formato seguente:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 321
Appendice 5
DISPOSITIVO DI VISUALIZZAZIONE
Nella presente appendice sono state usate le seguenti convenzioni tipografiche:
— i caratteri in grassetto indicano il testo normale da visualizzare (nella visua­
lizzazione non saranno in grassetto),
— i caratteri normali indicano le variabili (pittogrammi o dati) che nella visua­
lizzazione saranno sostituiti con i rispettivi valori:
— dd mm yyyy: giorno, mese, anno,
— hh: ore,
— mm: minuti,
— D: pittogramma della durata,
— EF: combinazione di pittogrammi relativi ad anomalie o
guasti,
— O: pittogramma della modalità di funzionamento.
DIS_001 Il tachigrafo deve visualizzare i dati nei formati seguenti:
Dati Formato
Visualizzazione predefinita
Ora locale
Modalità di funzionamento
Informazioni relative al conducente
Informazioni relative al secondo conducente
Condizione «Escluso dal campo di applicazione» attiva
Visualizzazione degli avvisi
Superamento del periodo di guida continuo
Anomalia o guasto
Visualizzazione di altre informazioni
Data UTC
Ora
Periodo di guida continuo e periodo cumulato di interru­
zione del conducente
Periodo di guida continuo e periodo cumulato di interru­
zione del secondo conducente
Periodo cumulato di guida del conducente per la settimana
in corso e quella precedente
Periodo cumulato di guida del secondo conducente per la
settimana in corso e quella precedente
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 322
Appendice 6
CONNETTORE ANTERIORE PER LA TARATURA E IL TRASFERI­
MENTO DEI DATI
INDICE
1. HARDWARE
1.1. Connettore
1.2. Distribuzione dei contatti
1.3. Schema elettrico
2. INTERFACCIA DI TRASFERIMENTO DATI
3. INTERFACCIA DI TARATURA
1. HARDWARE
1.1. Connettore
INT_001 Il connettore per la taratura e il trasferimento dei dati deve essere
un connettore a 6 pin, accessibile sul pannello anteriore senza
necessità di smontare alcun elemento del tachigrafo e deve essere
conforme al disegno seguente (tutte le dimensioni sono indicate
in millimetri):
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 323
Il disegno seguente illustra un tipico connettore volante a 6 pin:
1.2. Distribuzione dei contatti
INT_002 I contatti devono essere distribuiti secondo la tabella seguente:
Pin Descrizione Osservazioni
1 Polo negativo batteria Collegato al polo negativo della batteria del veicolo
2 Comunicazione di dati Linea K (ISO 14230-1)
3 RxD — Trasferimento di dati Ingresso dati del tachigrafo
4 Segnale di ingresso/uscita Taratura
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 324
Pin Descrizione Osservazioni
5 Uscita di alimentazione per­
manente
Il campo di tensione deve essere quello dell'alimentazione
elettrica del veicolo meno 3V per tenere conto della caduta
di tensione nel circuito di protezione
Uscita 40 mA
6 TxD — Trasferimento di dati Uscita dati del tachigrafo
1.3. Schema elettrico
INT_003 Lo schema elettrico deve essere conforme a quello sotto
riportato:
2. INTERFACCIA DI TRASFERIMENTO DATI
INT_004 L'interfaccia di trasferimento dati deve essere conforme alle spe­
cifiche RS232.
INT_005 L'interfaccia di trasferimento dati deve utilizzare un bit di avvio,
8 bit di dati con il bit meno significativo (LSB) per primo, un bit
di parità pari e 1 bit di arresto.
Organizzazione dei byte di dati
Bit di avvio (start bit): un bit con livello logico 0;
Bit di dati (data bits): trasmessi con LSB per primo;
Bit di parità (parity bit): parità pari;
Bit di arresto (stop bit): un bit con livello logico 1.
In caso di trasmissione di dati numerici costituiti da più di un byte, il byte
più significativo viene trasmesso per primo ed il byte meno significativo
viene trasmesso per ultimo.
INT_006 La velocità di trasmissione deve avere un campo di regolazione
compreso tra 9 600 bps e 115 200 bps. La trasmissione deve
avvenire alla velocità di trasmissione più elevata possibile, con
la velocità iniziale impostata su 9 600 bps dopo l'avvio della
comunicazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 325
3. INTERFACCIA DI TARATURA
INT_007 La comunicazione di dati deve essere conforme alla norma ISO
14230-1, Road vehicles — Diagnostic systems — Keyword pro­
tocol 2000 — Part 1: Physical layer, First edition: 1999.
INT_008 Il segnale in ingresso (in)/uscita (out) deve essere conforme alle
seguenti specifiche elettriche:
Parametro Minimo Tipico Massimo Osservazioni
U low (in) 1,0 V I = 750 μA
U high (in) 4 V I = 200 μA
Frequenza 4 kHz
U low (out) 1,0 V I = 1 mA
U high (out) 4 V I = 1 mA
INT_009 Il segnale in ingresso (in)/uscita (out) deve essere conforme alle
seguenti temporizzazioni:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 326
Appendice 7
PROTOCOLLI DI TRASFERIMENTO DEI DATI
INDICE
1. INTRODUZIONE
1.1. Campo di applicazione
1.2. Acronimi e simboli
2. TRASFERIMENTO DEI DATI DA UNA VU
2.1. Procedura di trasferimento dei dati
2.2. Protocolli di trasferimento dei dati
2.2.1 Struttura dei messaggi
2.2.2 Tipi di messaggio
2.2.2.1 Richiesta di inizio comunicazione (SID 81)
2.2.2.2 Risposta positiva di inizio comunicazione (SID C1)
2.2.2.3 Richiesta di inizio sessione diagnostica (SID 10)
2.2.2.4 Risposta positiva di inizio sessione diagnostica (SID 50)
2.2.2.5 Servizio di controllo del collegamento (SID 87)
2.2.2.6 Risposta positiva di controllo del collegamento (SID C7)
2.2.2.7 Richiesta di invio dati (upload) (SID 35)
2.2.2.8 Risposta positiva di invio dati (upload) (SID 75)
2.2.2.9 Richiesta di trasferimento dati (SID 36)
2.2.2.10 Risposta positiva di trasferimento dati (SID 76)
2.2.2.11 Richiesta di chiusura trasferimento (SID 37)
2.2.2.12 Risposta positiva di richiesta chiusura trasferimento (SID 77)
2.2.2.13 Richiesta di termine comunicazione (SID 82)
2.2.2.14 Richiesta di risposta positiva di termine comunicazione (SID C2)
2.2.2.15 Riconoscimento sottomessaggio (SID 83)
2.2.2.16 Risposta negativa (SID 7F)
2.2.3 Flusso di messaggi
2.2.4 Temporizzazione
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 327
2.2.5 Gestione degli errori
2.2.5.1 Fase di inizio della comunicazione
2.2.5.2 Fase di comunicazione
2.2.6 Contenuto del messaggio di risposta
▼M3
2.2.6.1 Positive Response Transfer Data Download Interface Version (Risposta
positiva di trasferimento dati relativi alla versione dell’interfaccia di
trasferimento)
2.2.6.2 Positive Response Transfer Data Overview (Risposta positiva di trasfe­
rimento dati ispezione)
2.2.6.3 Positive Response Transfer Data Activities (Risposta positiva di trasfe­
rimento dati relativi alle attività)
2.2.6.4 Positive Response Transfer Data Events and Faults (Risposta positiva di
trasferimento dati relativi ad anomalie e guasti)
2.2.6.5 Positive Response Transfer Data Detailed Speed (Risposta positiva di
trasferimento dati dettagliati relativi alla velocità)
2.2.6.6 Positive Response Transfer Data Technical Data (Risposta positiva di
trasferimento dati tecnici)
▼B
2.3. Memorizzazione dei file ESM
3. PROTOCOLLO DI TRASFERIMENTO DEI DATI DELLE CARTE
TACHIGRAFICHE
3.1. Campo di applicazione
3.2. Definizioni
3.3. Trasferimento dati carta
3.3.1 Sequenza di inizializzazione
3.3.2 Sequenza dei file di dati non firmati
3.3.3 Sequenza dei file di dati firmati
3.3.4 Sequenza di azzeramento del contatore di taratura
3.4. Formato di memorizzazione dei dati
3.4.1 Introduzione
3.4.2 Formato dei file
4. TRASFERIMENTO DEI DATI DI UNA CARTA TACHIGRAFICA
MEDIANTE UN'UNITÀ ELETTRONICA DI BORDO
1. INTRODUZIONE
La presente appendice stabilisce le procedure per l'esecuzione delle
differenti modalità di trasferimento dei dati ad un dispositivo di me­
morizzazione esterno (ESM), insieme ai protocolli da attuare per ga­
rantire il corretto trasferimento dei dati e la piena compatibilità del
formato dei dati trasferiti, in modo da consentire a qualsiasi agente
di controllo di ispezionare i dati in questione e verificarne l'autenticità
e integrità prima di procedere alla loro analisi.
▼M1
1.1. Campo di applicazione
Il trasferimento di dati a un ESM può avvenire:
— da un’unità elettronica di bordo mediante un apparecchio intelli­
gente dedicato (Intelligent dedicated equipment - IDE) collegato
alla VU,
— da una carta tachigrafica mediante un IDE dotato di interfaccia
della carta (IFD),
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 328
— da una carta tachigrafica e attraverso l’unità elettronica di bordo
mediante un IDE collegato alla VU.
Per consentire la verifica dell’autenticità e dell’integrità dei dati tra­
sferiti e memorizzati in un ESM, i dati vengono trasferiti allegando una
firma digitale conformemente all’appendice 11 (Meccanismi comuni di
sicurezza). Vengono inoltre trasferiti i dati relativi all’identificazione
dell’apparecchio di provenienza (VU o carta tachigrafica) e i relativi
certificati di sicurezza (Stato membro e apparecchio). Chi è preposto
alla verifica dei dati deve essere in possesso di una chiave pubblica
europea fidata.
I dati trasferiti da una VU sono firmati utilizzando i meccanismi co­
muni di sicurezza di cui all’appendice 11, parte B (Sistema tachigrafico
di seconda generazione), tranne quando il controllo dei conducenti è
effettuato da un’autorità di controllo non UE che utilizza una carta di
controllo di prima generazione, nel qual caso i dati sono firmati utiliz­
zando i meccanismi comuni di sicurezza di cui all’appendice 11, parte
A (Sistema tachigrafico di prima generazione), come previsto dall’ap­
pendice 15, Migrazione: requisito MIG_015.
La presente appendice specifica pertanto due tipi di trasferimento di
dati dalla VU:
— trasferimento di dati da una VU di seconda generazione, che forni­
sce la struttura dei dati di seconda generazione, firmati utilizzando i
meccanismi comuni di sicurezza di cui all’appendice 11, parte B,
— trasferimento di dati da una VU di prima generazione, che fornisce
la struttura dei dati di prima generazione, firmati utilizzando i mec­
canismi comuni di sicurezza di cui all’appendice 11, parte A.
Analogamente esistono due tipi di trasferimento di dati da carte del
conducente di seconda generazione inserite in una VU, come specifi­
cato ai paragrafi 3 e 4 della presente appendice.
▼B
1.2. Acronimi e simboli
Nella presente appendice sono utilizzati i seguenti acronimi:
AID Identificativo dell'applicazione (Application Identifier)
ATR Risposta al reset (Answer To Reset)
CS Byte di totale di controllo (Checksum byte)
DF File dedicato
DS_ Sessione di diagnostica
EF File elementare
ESM Dispositivo di memorizzazione esterno (External Storage Me­
dium)
FID Identificatore file (file ID) (File identifier)
FMT Format byte (primo byte dell'intestazione del messaggio)
ICC Carta a circuito integrato (Integrated Circuit Card)
IDE Apparecchio intelligente dedicato (Intelligent dedicated equip­
ment): apparecchio utilizzato per effettuare il trasferimento di
dati all'ESM (ad esempio: un personal computer)
IFD Dispositivo interfaccia (Interface device)
KWP Keyword Protocol 2000
LEN Byte di lunghezza (Length Byte) (ultimo byte nell'intestazione
del messaggio)
PPS Selezione del parametro di protocollo (Protocol Parameter Se­
lection)
PSO Esecuzione operazione di sicurezza (Perform Security Opera­
tion)
SID Identificativo del servizio
SRC Source byte
TGT Target byte
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 329
TLV Valore lunghezza tag (Tag Length Value)
TREP Parametro di risposta di trasferimento (Transfer Response Pa­
rameter)
TRTP Parametro di richiesta di trasferimento (Transfer Request Para­
meter)
VU Unità elettronica di bordo (Vehicle Unit)
2. TRASFERIMENTO DEI DATI DA UNA VU
2.1. Procedura di trasferimento dei dati
Per effettuare un trasferimento di dati da una VU l'operatore deve
eseguire le seguenti operazioni:
— inserire la propria carta tachigrafica in una sede (slot) della VU (*);
— collegare l'IDE al connettore di trasferimento dati della VU;
— stabilire il collegamento tra l'IDE e la VU;
— selezionare sull'IDE i dati da trasferire e inviare la richiesta alla
VU;
— terminare la sessione di trasferimento dati.
2.2. Protocollo di trasferimento dei dati
Il protocollo è strutturato sulla base di una configurazione di tipo
«master-slave», in cui all'IDE è assegnato il ruolo master e alla VU
quello slave.
La struttura, i tipi e il flusso dei messaggi si basano principalmente sul
Keyword Protocol 2000 (KWP) (ISO 14230-2 Road vehicles — Dia­
gnostic systems — Keyword protocol 2000 — Part 2: Data link layer).
Il livello dell'applicazione è basato in gran parte sull'attuale versione
della norma ISO 14229-1 (Road vehicles — Diagnostic systems —
Part 1: Diagnostic services, versione 6 del 22 febbraio 2001).
2.2.1 Struttura dei messaggi
DDP_002 Tutti i messaggi scambiati tra l'IDE e la VU sono formattati
secondo una struttura composta da tre parti:
— intestazione, costituita da un format byte di
formato (FMT), un target byte (TGT), un source
byte (SRC) ed, eventualmente, un byte di
lunghezza (LEN);
— campo dati, costituito da un byte identificatore del
servizio (SID), che può comprendere un byte facoltativo
relativo alla sessione di diagnostica (DS_) o un byte
facoltativo relativo al parametro di trasferimento (TRIP
o TREP);
— totale di controllo, costituito da un byte di totale di
controllo (CS).
Intestazione Campo dati Totale di controllo
FMT TGT SRC LEN SID DATI … … … CS
4 byte Max 255 byte 1 byte
I byte TGT e SRC rappresentano l'indirizzo fisico del de­
stinatario e del mittente del messaggio. I valori esadecimali
sono rispettivamente F0 per l'IDE ed EE per la VU.
Il byte LEN è la lunghezza della parte riservata al campo
dati.
▼B
(*) L'inserimento della carta determina l'abilitazione degli opportuni diritti di accesso alla
funzione di trasferimento e ai dati in questione. Deve essere possibile tuttavia trasferire
dati da una carta del conducente inserita in uno degli slot della VU se nessun'altra carta
è inserita nell'altro slot.
02016R0799 — IT — 21.08.2023 — 003.002 — 330
Il byte del totale di controllo è dato dalla somma su 8 bit, modulo
256, di tutti i byte del messaggio escluso lo stesso CS.
I byte relativi a FMT, SID, DS_, TRTP e TREP sono de­
finiti più avanti nel presente documento.
DDP_003 Nel caso in cui i dati da inviare nel messaggio eccedano lo
spazio disponibile nella sezione riservata al campo di dati, il
messaggio viene suddiviso in diversi sottomessaggi. Ciascun
sottomessaggio ha un'intestazione, gli stessi SID, TREP e un
contatore a 2 byte che indica il numero del sottomessaggio
all'interno del messaggio totale. Per abilitare la verifica degli
errori e interrompere la trasmissione di dati, l'IDE conferma
tutti i sottomessaggi. L'IDE può accettare un sottomessag­
gio, chiedere che sia ritrasmesso, richiedere alla VU di ri­
cominciare o interrompere la trasmissione.
DDP_004 Se l'ultimo sottomessaggio contiene esattamente 255 byte nel
campo dati, è necessario allegare un sottomessaggio finale con
un campo dati vuoto (salvo SID, TREP e il contatore sottomes­
saggi) per indicare la fine del messaggio.
Esempio:
Intestazione SID TREP Messaggio CS
4 byte Lunghezza superiore a 255 byte
è trasmesso nella seguente forma:
Intestazione SID TREP 00 01
Sottomessaggio
1
CS
4 byte 255 byte
Intestazione SID TREP 00 02
Sottomessaggio
2
CS
4 byte 255 byte
…
Intestazione SID TREP xx yy
Sottomessaggio
n
CS
4 byte Lunghezza inferiore a 255 byte
o nella forma:
Intestazione SID TREP 00 01
Sottomessaggio
1
CS
4 byte 255 byte
Intestazione SID TREP 00 02
Sottomessaggio
2
CS
4 byte 255 byte
…
Intestazione SID TREP xx yy
Sottomessaggio
n
CS
4 byte 255 byte
Intestazione SID TREP xx yy + 1 CS
4 byte 4 byte
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 331
2.2.2 Tipi di messaggio
Il protocollo di comunicazione per il trasferimento di dati tra la VU e
l'IDE richiede lo scambio di 8 tipi diversi di messaggi.
La tabella che segue riepiloga questi messaggi.
▼M3
Struttura del messaggio Max 4 Byte Max 255 Byte 1 Byte
Intestazione Dati
Totale di
controllo
IDE ->
Richiesta di inizio comunicazione 81 EE F0 81 E0
Risposta positiva di inizio comunica­
zione
80 F0 EE 03 C1 EA, 8F 9B
Richiesta di inizio sessione diagnostica 80 EE F0 02 10 81 F1
Risposta positiva di inizio sessione
diagnostica
80 F0 EE 02 50 81 31
Servizi di controllo del collegamento
Verifica della frequenza di baud
(fase 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
Risposta positiva verifica della fre­
quenza di baud
80 F0 EE 02 C7 01 28
Frequenza di baud di transizione
(fase 2)
80 EE F0 03 87 02 03 ED
Richiesta di invio dati (upload) 80 EE F0 0A 35 00,00,00,00,­
00,FF,FF,F­
F,FF
99
Risposta positiva di invio dati (upload) 80 F0 EE 03 75 00,FF D5
Richiesta di trasferimento dati
Versione dell’interfaccia di trasfe­
rimento
80 EE F0 02 36 00 96
Ispezione 80 EE F0 02 36 01, 21 o 31 CS
Attività 80 EE F0 06 36 02, 22 o 32 Data CS
Anomalie e guasti 80 EE F0 02 36 03, 23 o 33 Data CS
Dati dettagliati relativi alla velocità 80 EE F0 02 36 04 o 24 Data CS
Dati tecnici 80 EE F0 02 36 05, 25 o 35 Data CS
Trasferimento dei dati della carta 80 EE F0 02 o 03 36 06 Slot CS
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 332
Struttura del messaggio Max 4 Byte Max 255 Byte 1 Byte
Intestazione Dati
Totale di
controllo
IDE ->
Risposta positiva di trasferimento dati 80 F0 EE Len 76 TREP Dati CS
Richiesta di chiusura trasferimento 80 EE F0 01 37 96
Risposta positiva richiesta di chiusura
trasferimento
80 F0 EE 01 77 D6
Richiesta di termine comunicazione 80 EE F0 01 82 E1
Risposta positiva di termine comuni­
cazione
80 F0 EE 01 C2 21
Riconoscimento sottomessaggio 80 EE F0 Len 83 Dati CS
Risposte negative
Rifiuto generico 80 F0 EE 03 7F Sid Req 10 CS
Servizio non supportato 80 F0 EE 03 7F Sid Req 11 CS
Sottofunzione non supportata 80 F0 EE 03 7F Sid Req 12 CS
Lunghezza del messaggio non corretta 80 F0 EE 03 7F Sid Req 13 CS
Condizioni non soddisfatte o errore
nella sequenza di richiesta
80 F0 EE 03 7F Sid Req 22 CS
Richiesta fuori valori limite 80 F0 EE 03 7F Sid Req 31 CS
Invio dati (upload) rifiutato 80 F0 EE 03 7F Sid Req 50 CS
Risposta pendente 80 F0 EE 03 7F Sid Req 78 CS
Dati non disponibili 80 F0 EE 03 7F Sid Req FA CS
Note:
— Sid Req = il Sid della richiesta corrispondente.
— TREP = il TRTP della richiesta corrispondente.
— Le celle scure indicano l’assenza di trasmissione.
— Il termine invio (upload) (riferito all’IDE) è utilizzato per compa­
tibilità con la norma ISO 14229. Esso ha lo stesso significato di
trasferimento (download) (riferito alla VU).
— La tabella non riporta i potenziali contatori a 2 byte di
sottomessaggi.
— «Slot» è il numero dello slot, «1» (carta nello slot conducente) o
«2» (carta nello slot «secondo conducente»).
— Qualora non sia specificato lo slot, la VU deve selezionare lo slot 1
se la carta è inserita in questo slot e lo slot 2 solo qualora sia scelto
espressamente dall’utente.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 333
— Il TRTP 24 è utilizzato per richieste di trasferimento dati da VU
di seconda generazione, versione 1 e versione 2.
— I TRTP 00, 31, 32, 33 e 35 sono utilizzati per le richieste di
trasferimento dati da VU di seconda generazione, versione 2.
— I TRTP 21, 22, 23 e 25 sono utilizzati per le richieste di trasferi­
mento dati da VU di seconda generazione, versione 1.
— I TRTP da 01 a 05 sono utilizzati per le richieste di trasferimento
dati da VU di prima generazione. Tali richieste possono essere
facoltativamente accettate da VU di seconda generazione, ma solo
nel quadro di controlli dei conducenti effettuati da un’autorità di
controllo non UE che utilizza una carta di controllo di prima
generazione.
— I TRTP da 11 a 1F sono riservati per richieste di trasferimento dati
specifiche del fabbricante.
▼B
2.2.2.1 R i c h i e s t a d i i n i z i o c o m u n i c a z i o n e ( S I D 8 1 )
DDP_005 Tale messaggio è inviato dall'IDE per stabilire il collega­
mento nelle comunicazioni con la VU. Le comunicazioni
iniziali sono sempre eseguite a 9 600 baud (finché la velo­
cità non è cambiata usando gli opportuni servizi di controllo
del collegamento).
2.2.2.2 R i s p o s t a p o s i t i v a d i i n i z i o c o m u n i c a z i o n e ( S I D C 1 )
DDP_006 Questo messaggio è inviato dalla VU per rispondere positi­
vamente alla richiesta di inizio comunicazione e comprende
i 2 byte chiave «EA» e «8F» che indicano che l'unità sup­
porta il protocollo con intestazione, comprendente le infor­
mazioni su target, source e lunghezza.
2.2.2.3 R i c h i e s t a d i i n i z i o s e s s i o n e d i a g n o s t i c a ( S I D 1 0 )
DDP_007 Il messaggio «Richiesta di inizio sessione diagnostica» è
inviato dall'IDE allo scopo di chiedere una nuova sessione
di diagnostica della VU. La sottofunzione «sessione prede­
finita» (81 esadecimale) indica che deve essere avviata una
sessione di diagnostica standard.
2.2.2.4 R i s p o s t a p o s i t i v a d i i n i z i o s e s s i o n e d i a g n o s t i c a
( S I D 5 0 )
DDP_008 Il messaggio «Risposta positiva di inizio sessione diagno­
stica» è inviato dalla VU per rispondere positivamente a
Richiesta di inizio sessione diagnostica.
2.2.2.5 S e r v i z i o d i c o n t r o l l o d e l c o l l e g a m e n t o ( S I D 8 7 )
DDP_052 Il «Servizio di controllo del collegamento» è utilizzato dal­
l'IDE per iniziare il cambiamento della velocità in baud. Il
cambiamento avviene in due fasi. Nella prima fase l'IDE
propone il cambiamento, indicando la nuova velocità. Rice­
vuta la risposta positiva della VU, l'IDE conferma il cam­
biamento di velocità in baud alla VU (seconda fase). L'IDE
passa quindi alla nuova velocità in baud. Ricevuta la con­
ferma, anche la VU passa alla nuova velocità.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 334
2.2.2.6 R i s p o s t a p o s i t i v a d i c o n t r o l l o d e l c o l l e g a m e n t o
( S I D C 7 )
DDP_053 La «Risposta positiva di controllo del collegamento» è in­
viata dalla VU per rispondere positivamente alla richiesta di
Link Control Service (prima fase). Nessuna risposta è invece
inviata alla richiesta di conferma (seconda fase).
2.2.2.7 R i c h i e s t a d i i n v i o d a t i ( u p l o a d ) ( S I D 3 5 )
DDP_009 Il messaggio «Richiesta di invio dati (upload)» è inviato
dall'IDE per specificare alla VU che si richiede un'opera­
zione di trasferimento dati. Per soddisfare i requisiti della
norma ISO 14229 vengono anche inviati dati relativi all'in­
dirizzo, alla dimensione ed al formato dei dati richiesti.
Poiché tali informazioni non sono note all'IDE prima del
trasferimento, l'indirizzo di memoria è impostato su 0, il
formato non è né criptato né compresso e la dimensione
della memoria è impostata sul valore massimo.
2.2.2.8 R i s p o s t a p o s i t i v a d i i n v i o d a t i ( u p l o a d ) ( S I D 7 5 )
DDP_010 Il messaggio «Risposta positiva di invio dati (upload)» è
inviato dalla VU per segnalare all'IDE che la VU è pronta
ad eseguire il trasferimento dei dati. Per soddisfare i requi­
siti della norma ISO 14229 nel messaggio di risposta posi­
tiva sono contenuti anche dati che indicano all'IDE che i
successivi messaggi di Risposta positiva alla richiesta di
trasferimento dati comprenderanno al massimo 00FF bytes
esadecimali.
2.2.2.9 R i c h i e s t a d i t r a s f e r i m e n t o d a t i ( S I D 3 6 )
▼M1
DDP_011 La richiesta di trasferimento dati è inviata dall’IDE per spe­
cificare alla VU il tipo di dati da trasferire. Un parametro di
richiesta di trasferimento (TRTP) di un byte indica il tipo di
trasferimento.
▼M3
I tipi di trasferimento dati sono sette. Per il trasferimento
dati da VU possono essere utilizzati due diversi TRTP per
ciascun tipo di trasferimento:
Tipo di trasferimento dati
Valore TRTP per trasferimento
dati da VU di
prima generazione
Valore TRTP per trasferimento
dati da VU di
seconda generazione, versione 1
Valore TRTP per trasferimento
dati da VU di
seconda generazione, versione 2
Versione dell’interfaccia di
trasferimento
Non utilizzato Non utilizzato 00
Ispezione 01 21 31
Attività relative a una data
specifica
02 22 32
Anomalie e guasti 03 23 33
Dati dettagliati relativi alla
velocità
04 24 24
Dati tecnici 05 25 35
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 335
Tipo di trasferi­
mento dati
Valore TRTP
Trasferimento
dei dati della
carta
06
▼M3
DDP_054 L’IDE deve obbligatoriamente richiedere il trasferimento
dati in modalità ispezione (TRTP 01, 21 o 31) durante
una sessione di trasferimento (download), poiché solo in
tal modo i certificati della VU sono registrati nei file tra­
sferiti (e permettono così la verifica della firma digitale).
Nel terzo caso (TRTP 02, 22 o 32) il messaggio di richiesta di tra­
sferimento dati comprende l’indicazione del giorno di calendario (for­
mato TimeReal) da trasferire.
▼B
2.2.2.10 R i s p o s t a p o s i t i v a d i t r a s f e r i m e n t o d a t i ( S I D 7 6 )
DDP_012 Il messaggio «Risposta positiva di trasferimento dati» è in­
viato dalla VU in risposta alla Richiesta di trasferimento dati
e contiene i dati richiesti con il Parametro di risposta di
trasferimento (TREP) corrispondente al TRTP della
richiesta.
▼M3
DDP_055 Nel primo caso (TREP 01, 21 o 31) la VU invia i dati utili
all’operatore dell’IDE per individuare i dati che intende tra­
sferire. Il messaggio contiene le seguenti informazioni:
▼M1
— certificati di sicurezza,
— identificazione del veicolo,
— data e ora correnti della VU,
— estremi temporali minimo e massimo dei dati disponibili
per il trasferimento (dati VU),
— indicazione della presenza di carte nella VU,
— precedente trasferimento dati a un’impresa,
— blocchi di un’impresa,
— controlli precedenti.
▼B
2.2.2.11 R i c h i e s t a d i c h i u s u r a t r a s f e r i m e n t o ( S I D 3 7 )
DDP_013 Il messaggio «Richiesta di chiusura trasferimento» è inviato
dall'IDE per informare la VU che la sessione di trasferi­
mento è terminata.
2.2.2.12 R i s p o s t a p o s i t i v a d i r i c h i e s t a c h i u s u r a t r a s f e r i ­
m e n t o ( S I D 7 7 )
DDP_014 Il messaggio «Risposta positiva di richiesta chiusura trasfe­
rimento» è inviato dalla VU per confermare la ricezione
della Richiesta di chiusura trasferimento.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 336
2.2.2.13 R i c h i e s t a d i t e r m i n e c o m u n i c a z i o n e ( S I D 8 2 )
DDP_015 Il messaggio «Richiesta di termine comunicazione» è inviato
dall'IDE per disattivare il collegamento di comunicazione
con la VU.
2.2.2.14 R i c h i e s t a d i r i s p o s t a p o s i t i v a d i t e r m i n e c o m u n i ­
c a z i o n e ( S I D C 2 )
DDP_016 Il messaggio «Richiesta di risposta positiva di termine co­
municazione» è inviato dalla VU per confermare la rice­
zione della Richiesta di termine comunicazione.
2.2.2.15 R i c o n o s c i m e n t o s o t t o m e s s a g g i o ( S I D 8 3 )
DDP_017 Il messaggio «Riconoscimento sottomessaggio» è inviato
dall'IDE per confermare l'avvenuta ricezione di ciascuna
parte di un messaggio trasmesso sotto forma di più sotto­
messaggi. Il campo dati contiene il SID ricevuto dalla VU e
un codice a 2 byte, come descritto qui di seguito:
— MsgC + 1 conferma la corretta ricezione del sottomes­
saggio MsgC.
Richiesta da parte dell'IDE alla VU di inviare il sotto­
messaggio successivo.
— MsgC indica un problema nella ricezione del sottomes­
saggio MsgC.
Richiesta da parte dell'IDE alla VU di inviare di nuovo
il sottomessaggio.
— FFFF richiede la conclusione del messaggio.
Può essere utilizzato dall'IDE per terminare la trasmis­
sione del messaggio della VU per qualsiasi ragione.
L'ultimo sottomessaggio di un messaggio (byte LEN
può essere confermato utilizzando uno qualsiasi di questi
codici oppure non essere confermato.
Le risposte della VU, composte da diversi sottomessaggi,
sono:
— Risposta positiva di trasferimento dati (SID 76)
2.2.2.16 R i s p o s t a n e g a t i v a ( S I D 7 F )
DDP_018 La «Risposta negativa» è inviata dalla VU in risposta alle
richieste sopra menzionate nel caso in cui la VU non sia in
grado di soddisfare la richiesta in questione. I campi dati del
messaggio comprendono il SID della risposta (7F), il SID
della richiesta e un codice che specifica la ragione della
risposta negativa. Sono disponibili i seguenti codici:
— 10 rifiuto generico
L'azione non può essere eseguita per una ragione diversa
da quelle sotto esposte.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 337
— 11 servizio non supportato
Mancata comprensione del SID relativo alla richiesta.
— 12 sottofunzione non supportata
Mancata comprensione del DS_ o TRTP relativo alla
richiesta, o assenza di ulteriori sottomessaggi da
trasmettere.
— 13 lunghezza del messaggio non corretta
Il messaggio ricevuto non ha la giusta lunghezza.
— 22 condizioni non soddisfatte o errore nella sequenza di
richiesta
Il servizio richiesto non è attivo o la sequenza dei mes­
saggi di richiesta non è corretta.
— 31 richiesta fuori valori limite
Il parametro indicato (campo dei dati) non è valido.
— 50 invio dati (upload) rifiutato
La richiesta non può essere eseguita (errata modalità di
funzionamento della VU o guasto interno della VU).
— 78 risposta pendente
L'azione richiesta non può essere completata nel tempo
previsto e la VU non è pronta per accettare un'altra
richiesta.
▼M1
— dati FA non disponibili
I dati oggetto di una richiesta di trasferimento non sono di
disponibili nella VU (ad esempio non vi è alcuna carta
inserita, richiesta di trasferimento dati da VU di prima
generazione fuori dall’ambito di un controllo dei condu­
centi da parte di un’autorità di controllo non UE …).
▼B
2.2.3 Flusso di messaggi
Qui di seguito è illustrato un tipico flusso di messaggi nel corso di una
normale procedura di trasferimento dati:
IDE VU
Richiesta di inizio comunicazione ⇨
⇦ Risposta positiva
Richiesta di inizio sessione diagnostica ⇨
⇦ Risposta positiva
Richiesta di invio dati ⇨
⇦ Risposta positiva
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 338
IDE VU
Riepilogo della richiesta di trasferimento dati ⇨
⇦ Risposta positiva
Richiesta di trasferimento dati #2 ⇨
⇦ Risposta positiva #1
Riconoscimento sottomessaggio #1 ⇨
⇦ Risposta positiva #2
Riconoscimento sottomessaggio #2 ⇨
⇦ Risposta positiva #m
Riconoscimento sottomessaggio #m ⇨
⇦ Risposta positiva (campo dati
Riconoscimento sottomessaggio (facoltativo) ⇨
…
Richiesta di trasferimento dati #n ⇨
⇦ Risposta positiva
Richiesta di chiusura trasferimento ⇨
⇦ Risposta positiva
Richiesta di termine comunicazione ⇨
⇦ Risposta positiva
2.2.4 Temporizzazione
DDP_019 La figura di seguito riportata illustra i parametri di tempo­
rizzazione importanti durante il normale funzionamento:
Figura 1
Flusso messaggi, temporizzazione
dove:
P1 = Intervallo di tempo tra byte per la risposta della VU.
P2 = Intervallo di tempo tra la fine della richiesta dell'IDE
e l'inizio della risposta della VU o tra la fine della
conferma di ricezione da parte dell'IDE e l'inizio della
successiva risposta della VU.
P3 = Intervallo di tempo tra la fine della risposta della VU
e l'inizio della nuova richiesta dell'IDE, o tra la fine
della risposta della VU e l'inizio della conferma di
ricezione da parte dell'IDE, o tra la fine della richiesta
dell'IDE e l'inizio della nuova richiesta dell'IDE in
caso di mancata risposta da parte della VU.
P4 = Intervallo di tempo tra byte per la richiesta da parte
dell'IDE.
P5 = Valore ampliato di P3 per il trasferimento dei dati
dalla carta.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 339
I valori consentiti per i parametri di temporizzazione sono
illustrati nella tabella successiva (impostazione dei parametri
di temporizzazione supplementari relativi al KWP, utilizzata
in caso di indirizzamento fisico per una comunicazione più
veloce).
Parametro di temporizzazione
Valore minimo
(ms)
Valore massimo
(ms)
P1 0 20
P2 20 1 000 (*)
P3 10 5 000
P4 5 20
P5 10 20 minuti
(*) Se la VU risponde con una Risposta negativa contenente un codice che significa «richiesta correttamente
ricevuta, risposta pendente», questo valore è esteso allo stesso valore limite superiore di P3.
2.2.5 Gestione degli errori
In caso di errore durante lo scambio di messaggi, lo schema del flusso
dei messaggi è modificato a seconda di quale apparecchio abbia rile­
vato l'errore e del messaggio che l'ha generato.
Le figure 2 e 3 indicano le procedure di gestione degli errori rispetti­
vamente per la VU e per l'IDE.
2.2.5.1 F a s e d i i n i z i o d e l l a c o m u n i c a z i o n e
DDP_020 Se durante la fase di avvio delle comunicazioni l'IDE rileva
un errore, nella temporizzazione o nel flusso di bit, esso
attende per un intervallo di tempo pari a P3min prima di
riproporre la richiesta.
DDP_021 Se la VU rileva un errore nella sequenza inviata dall'IDE,
essa non invia risposta e attende una nuova Richiesta di
inizio comunicazione, che deve pervenire entro un limite
di tempo pari a P3 max.
2.2.5.2 F a s e d i c o m u n i c a z i o n e
Si possono individuare due distinti ambiti di gestione degli errori:
1. Rilevamento da parte della VU di un errore di trasmissione
dell'IDE
DDP_022 Per ogni messaggio ricevuto la VU deve rilevare l'even­
tuale presenza di errori di temporizzazione, di formato dei
byte (ad esempio: violazione dei bit di avvio e di arresto)
e di struttura (numero errato dei byte ricevuti, byte errato
relativo al totale di controllo).
DDP_023 In caso di rilevamento di uno degli errori sopra menzio­
nati da parte della VU, quest'ultima non invia alcuna
risposta e ignora il messaggio ricevuto.
DDP_024 È possibile che la VU rilevi altri errori relativi al formato
o al contenuto del messaggio ricevuto (ad esempio, mes­
saggio non supportato) anche se questo soddisfa i requi­
siti previsti di lunghezza e totale di controllo; in tal caso,
la VU risponde all'IDE con un messaggio di Risposta
negativa che specifica la natura dell'errore in questione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 340
Figura 2
Gestione degli errori da parte della VU
▼B
2. Rilevamento da parte dell'IDE di un errore di trasmissione della VU
DDP_025 Per ogni messaggio ricevuto l'IDE rileva l'eventuale pre­
senza di errori di temporizzazione, di formato dei byte
(ad esempio: violazione dei bit di avvio e di arresto) e di
struttura (numero errato dei byte ricevuti, byte errato re­
lativo al totale di controllo).
DDP_026 L'IDE rileva errori di sequenza, ad esempio messaggi
successivi con incrementi non corretti del contatore di
sottomessaggi.
DDP_027 In caso di rilevamento di un errore da parte dell'IDE o in
assenza di risposta da parte della VU entro un periodo di
tempo pari a P2max, il messaggio di richiesta sarà nuo­
vamente inviato per un numero massimo complessivo di
tre trasmissioni. Ai fini di tale rilevamento di errori, la
conferma di ricezione di un sottomessaggio sarà conside­
rata come una richiesta inviata alla VU.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 341
DDP_028 L'IDE deve attendere un intervallo di tempo pari a P3min
prima dell'inizio di ciascuna trasmissione; il periodo di
attesa viene misurato a partire dall'ultimo intervento cal­
colato di un bit di arresto dopo il rilevamento dell'errore.
Figura 3
Gestione degli errori da parte dell'IDE
2.2.6 Contenuto del messaggio di risposta
Il presente punto definisce il contenuto dei campi di dati dei vari
messaggi di risposta positiva.
Gli elementi di dati sono definiti nel dizionario di dati di cui all'ap­
pendice 1.
Osservazioni: per i trasferimenti di generazione 2 ogni elemento di dati
di alto livello è rappresentato da un record array, anche se esso con­
tiene un solo record. Un record array inizia con un'intestazione, che
contiene i tipi, le dimensioni e il numero di record. I record array sono
sempre denominati «…RecordArray» (con intestazione) nelle seguenti
tabelle.
▼M3
2.2.6.1 P o s i t i v e R e s p o n s e T r a n s f e r D a t a D o w n l o a d I n t e r ­
f a c e V e r s i o n ( R i s p o s t a p o s i t i v a d i t r a s f e r i m e n t o
d a t i r e l a t i v i a l l a v e r s i o n e d e l l ’ i n t e r f a c c i a d i t r a ­
s f e r i m e n t o )
DDP_028a Il campo di dati del messaggio «Positive Response Tran­
sfer Data Download Interface Version» deve fornire
nell’ordine sotto indicato i seguenti dati corrispondenti ai
valori esadecimali SID 76 Hex e TREP 00 Hex:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 342
Struttura dei dati di seconda generazione, versione 2 (TREP 00 Hex)
Elemento di dati Osservazioni
DownloadInterfaceVersion Generazione e versione della VU: 02,02 esadeci­
mali per la seconda generazione, versione 2.
Non supportato dalle VU di prima generazione e
di seconda generazione, versione 1, che devono
fornire risposta negativa (sottofunzione non sup­
portata, cfr. DDP_018).
2.2.6.2 P o s i t i v e R e s p o n s e T r a n s f e r D a t a O v e r v i e w
( R i s p o s t a p o s i t i v a d i t r a s f e r i m e n t o d a t i i s p e z i o n e )
DDP_029 Il campo di dati del messaggio «Positive Response Tran­
sfer Data Overview» deve fornire nell’ordine sotto indicato
i seguenti dati corrispondenti ai valori esadecimali SID 76
Hex e TREP 01, 21 o 31 Hex, nonché alla suddivisione e
al conteggio appropriati dei sottomessaggi:
Struttura dei dati di prima generazione (TREP 01 Hex)
Elemento di dati Osservazioni
MemberStateCertificate Certificati di sicurezza della VU.
VUCertificate
VehicleIdentificationNumber Identificazione del veicolo.
VehicleRegistrationIdentification
CurrentDateTime Data e ora correnti della VU.
VuDownloadablePeriod Periodo disponibile per il trasferimento.
CardSlotsStatus Tipi di carte inserite nella VU.
VuDownloadActivityData Precedente trasferimento dalla VU.
VuCompanyLocksData Tutti i blocchi di un’impresa memorizzati. Se la
sezione è vuota, viene inviato solo noOfLocks =
0.
VuControlActivityData Tutti le registrazioni di controllo memorizzate
nella VU. Se la sezione è vuota, viene inviato
solo noOfControls = 0.
Signature Firma RSA di tutti i dati (tranne i certificati) a
partire dal VehicleIdentificationNumber fino
all’ultimo byte dell’ultimo VuControlActivity­
Data.
Struttura dei dati di seconda generazione, versione 1 (TREP 21 Hex)
Elemento di dati Osservazioni
MemberStateCertificateRecordArray Certificato dello Stato membro.
VUCertificateRecordArray Certificato della VU.
VehicleIdentificationNumberRecordArray Identificazione del veicolo.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 343
Elemento di dati Osservazioni
VehicleRegistrationIdentificationRecordArray Numero d’immatricolazione del veicolo.
CurrentDateTimeRecordArray Data e ora correnti della VU.
VuDownloadablePeriodRecordArray Periodo disponibile per il trasferimento.
CardSlotsStatusRecordArray Tipi di carte inserite nella VU.
VuDownloadActivityDataRecordArray Precedente trasferimento dalla VU.
VuCompanyLocksRecordArray Tutti i blocchi di un’impresa memorizzati. Se la
sezione è vuota, viene inviata un’intestazione di
array con noOfRecords = 0.
VuControlActivityRecordArray Tutti le registrazioni di controllo memorizzate
nella VU. Se la sezione è vuota, viene inviata
un’intestazione di array con noOfRecords = 0.
SignatureRecordArray Firma ECC di tutti i dati precedenti esclusi i
certificati.
Struttura dei dati di seconda generazione, versione 2 (TREP 31 Hex)
Elemento di dati Osservazioni
MemberStateCertificateRecordArray Certificato dello Stato membro.
VUCertificateRecordArray Certificato della VU.
VehicleIdentificationNumberRecordArray Identificazione del veicolo.
VehicleRegistrationNumberRecordArray Numero d’immatricolazione del veicolo.
CurrentDateTimeRecordArray Data e ora correnti della VU.
VuDownloadablePeriodRecordArray Periodo disponibile per il trasferimento.
CardSlotsStatusRecordArray Tipi di carte inserite nella VU.
VuDownloadActivityDataRecordArray Precedente trasferimento dalla VU.
VuCompanyLocksRecordArray Tutti i blocchi di un’impresa memorizzati. Se la
sezione è vuota, viene inviata un’intestazione di
array con noOfRecords = 0.
VuControlActivityRecordArray Tutti le registrazioni di controllo memorizzate
nella VU. Se la sezione è vuota, viene inviata
un’intestazione di array con noOfRecords = 0.
SignatureRecordArray Firma ECC di tutti i dati precedenti esclusi i
certificati.
2.2.6.3 P o s i t i v e R e s p o n s e T r a n s f e r D a t a A c t i v i t i e s ( R i ­
s p o s t a p o s i t i v a d i t r a s f e r i m e n t o d a t i r e l a t i v i a l l e
a t t i v i t à )
DDP_030 Il campo di dati del messaggio «Positive Response Tran­
sfer Data Activities» deve fornire nell’ordine sotto indicato
i seguenti dati corrispondenti ai valori esadecimali SID 76
Hex e TREP 02, 22 o 32 Hex, nonché alla suddivisione e
al conteggio appropriati dei sottomessaggi:
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 344
Struttura dei dati di prima generazione (TREP 02 Hex)
Elemento di dati Osservazioni
TimeReal Data della giornata oggetto del trasferimento dati.
OdometerValueMidnight Odometro alla fine della giornata oggetto del trasferi­
mento dati.
VuCardIWData Dati dei cicli di inserimento ed estrazione delle carte.
— Se questa sezione non contiene dati disponibili,
viene inviato solo noOfVuCardIWRecords = 0.
— Quando oltrepassa le 00:00 (inserimento della carta
il giorno precedente) o le 24:00 (estrazione della
carta il giorno seguente), un VuCardIWRecord
deve figurare interamente nei due giorni in que­
stione.
VuActivityDailyData Stato dello slot alle 00:00 e cambi di attività registrati
per la giornata oggetto del trasferimento dati.
VuPlaceDailyWorkPeriodData Dati relativi ai luoghi registrati nella giornata oggetto
del trasferimento dati. Se la sezione è vuota, viene in­
viato solo noOfPlaceRecords = 0.
VuSpecificConditionData Dati relativi a condizioni particolari registrati nella gior­
nata oggetto del trasferimento dati. Se la sezione è
vuota, viene inviato solo noOfSpecificConditionRe­
cords=0.
Signature Firma RSA di tutti i dati a partire da TimeReal fino all’ultimo
byte dell’ultima registrazione di condizioni particolari.
Struttura dei dati di seconda generazione, versione 1 (TREP 22 Hex)
Elemento di dati Osservazioni
DateOfDayDownloadedRecordArray Data della giornata oggetto del trasferimento dati.
OdometerValueMidnightRecordArray Odometro alla fine della giornata oggetto del trasferi­
mento dati.
VuCardIWRecordArray Dati dei cicli di inserimento ed estrazione delle carte.
— Se la sezione è vuota, viene inviata un’intestazione
di array con noOfRecords = 0.
— Quando oltrepassa le 00:00 (inserimento della carta il
giorno precedente) o le 24:00 (estrazione della carta il
giorno seguente), un VuCardIWRecord deve figurare
interamente nei due giorni in questione.
VuActivityDailyRecordArray Stato dello slot alle 00:00 e cambi di attività registrati
per la giornata oggetto del trasferimento dati.
VuPlaceDailyWorkPeriodRecordArray Dati relativi ai luoghi registrati nella giornata oggetto
del trasferimento dati. Se la sezione è vuota, viene in­
viata un’intestazione di array con noOfRecords = 0.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 345
Elemento di dati Osservazioni
VuGNSSADRecordArray Posizioni GNSS del veicolo se il periodo di guida cu­
mulativo raggiunge un multiplo di tre ore. Se la
sezione è vuota, viene inviata un’intestazione di array
con noOfRecords = 0.
VuSpecificConditionRecordArray Dati relativi a condizioni particolari registrati nella gior­
nata oggetto del trasferimento dati. Se la sezione è
vuota, viene inviata un’intestazione di array con noO­
fRecords = 0.
SignatureRecordArray Firma ECC di tutti i dati precedenti.
Struttura dei dati di seconda generazione, versione 2 (TREP 32 Hex)
Elemento di dati Osservazioni
DateOfDayDownloadedRecordArray Data della giornata oggetto del trasferimento dati.
OdometerValueMidnightRecordArray Odometro alla fine della giornata oggetto del trasferi­
mento dati.
VuCardIWRecordArray Dati dei cicli di inserimento ed estrazione delle carte.
— Se la sezione è vuota, viene inviata un’intestazione
di array con noOfRecords = 0.
— Quando oltrepassa le 00:00 (inserimento della carta
il giorno precedente) o le 24:00 (estrazione della
carta il giorno seguente), un VuCardIWRecord
deve figurare interamente nei due giorni in que­
stione.
VuActivityDailyRecordArray Stato dello slot alle 00:00 e cambi di attività registrati
per la giornata oggetto del trasferimento dati.
VuPlaceDailyWorkPeriodRecordArray Dati relativi ai luoghi registrati nella giornata oggetto
del trasferimento dati. Se la sezione è vuota, viene in­
viata un’intestazione di array con noOfRecords = 0.
VuGNSSADRecordArray Posizioni GNSS del veicolo se il periodo di guida cu­
mulativo raggiunge un multiplo di tre ore. Se la
sezione è vuota, viene inviata un’intestazione di array
con noOfRecords = 0.
VuSpecificConditionRecordArray Dati relativi a condizioni particolari registrati nella gior­
nata oggetto del trasferimento dati. Se la sezione è
vuota, viene inviata un’intestazione di array con noO­
fRecords = 0.
VuBorderCrossingRecordArray Attraversamenti di frontiera per la giornata oggetto del
trasferimento dati. Se la sezione è vuota, viene inviata
un’intestazione di array con noOfRecords = 0.
VuLoadUnloadRecordArray Operazioni di carico/scarico per la giornata oggetto del
trasferimento dati. Se la sezione è vuota, viene inviata
un’intestazione di array con noOfRecords = 0.
SignatureRecordArray Firma ECC di tutti i dati precedenti.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 346
2.2.6.4 P o s i t i v e R e s p o n s e T r a n s f e r D a t a E v e n t s a n d F a u l t s
( R i s p o s t a p o s i t i v a d i t r a s f e r i m e n t o d a t i r e l a t i v i a d
a n o m a l i e e g u a s t i )
DDP_031 Il campo di dati del messaggio «Positive Response Tran­
sfer Data Events and Faults» deve fornire nell’ordine sotto
indicato i seguenti dati corrispondenti ai valori esadecimali
SID 76 Hex e TREP 03, 23 o 33 Hex, nonché alla suddi­
visione e al conteggio appropriati dei sottomessaggi:
Struttura dei dati di prima generazione (TREP 03 Hex)
Elemento di dati Osservazioni
VuFaultData Tutti i guasti memorizzati o in corso nella VU.
Se la sezione è vuota, viene inviato solo noOfVuFaults
= 0.
VuEventData Tutti le anomalie (ad eccezione dei superamenti di ve­
locità) memorizzate o in corso nella VU.
Se la sezione è vuota, viene inviato solo noOfVuEvents
= 0.
VuOverSpeedingControlData Dati relativi all’ultimo controllo del superamento di ve­
locità (valore predefinito se non sono disponibili dati).
VuOverSpeedingEventData Tutti le anomalie di tipo «Superamento della velocità»
memorizzate nella VU.
Se la sezione è vuota, viene inviato solo noOfVuOver­
SpeedingEvents = 0.
VuTimeAdjustmentData Tutte le anomalie di tipo «Regolazione dell’ora» memo­
rizzate nella VU (al di fuori di una taratura completa).
Se la sezione è vuota, viene inviato solo noOfVuTime­
AdjRecords = 0.
Signature Firma RSA di tutti i dati a partire da noOfVuFaults fino
all’ultimo byte dell’ultimo record di regolazione
dell’ora.
Struttura dei dati di seconda generazione, versione 1 (TREP 23 Hex)
Elemento di dati Osservazioni
VuFaultRecordArray Tutti i guasti memorizzati o in corso nella VU.
Se la sezione è vuota, viene inviata un’intestazione di
array con noOfRecords = 0.
VuEventRecordArray Tutti le anomalie (ad eccezione dei superamenti di ve­
locità) memorizzate o in corso nella VU.
Se la sezione è vuota, viene inviata un’intestazione di
array con noOfRecords = 0.
VuOverSpeedingControlDataRecordArray Dati relativi all’ultimo controllo del superamento di ve­
locità (valore predefinito se non sono disponibili dati).
VuOverSpeedingEventRecordArray Tutti le anomalie di tipo «Superamento della velocità»
memorizzate nella VU.
Se la sezione è vuota, viene inviata un’intestazione di
array con noOfRecords = 0.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 347
Elemento di dati Osservazioni
VuTimeAdjustmentRecordArray Tutte le anomalie di tipo «Regolazione dell’ora» memo­
rizzate nella VU (al di fuori di una taratura completa).
Se la sezione è vuota, viene inviata un’intestazione di
array con noOfRecords = 0.
SignatureRecordArray Firma ECC di tutti i dati precedenti.
Struttura dei dati di seconda generazione, versione 2 (TREP 33 Hex)
Elemento di dati Osservazioni
VuFaultRecordArray Tutti i guasti memorizzati o in corso nella VU.
Se la sezione è vuota, viene inviata un’intestazione di
array con noOfRecords = 0.
VuEventRecordArray Tutti le anomalie (ad eccezione dei superamenti di ve­
locità) memorizzate o in corso nella VU.
Se la sezione è vuota, viene inviata un’intestazione di
array con noOfRecords = 0.
VuOverSpeedingControlDataRecordArray Dati relativi all’ultimo controllo del superamento di ve­
locità (valore predefinito se non sono disponibili dati).
VuOverSpeedingEventRecordArray Tutti le anomalie di tipo «Superamento della velocità»
memorizzate nella VU.
Se la sezione è vuota, viene inviata un’intestazione di
array con noOfRecords = 0.
VuTimeAdjustmentRecordArray Tutte le anomalie di tipo «Regolazione dell’ora» memo­
rizzate nella VU (al di fuori di una taratura completa).
Se la sezione è vuota, viene inviata un’intestazione di
array con noOfRecords = 0.
SignatureRecordArray Firma ECC di tutti i dati precedenti.
2.2.6.5 P o s i t i v e R e s p o n s e T r a n s f e r D a t a D e t a i l e d S p e e d
( r i s p o s t a p o s i t i v a d i t r a s f e r i m e n t o d a t i d e t t a g l i a t i
r e l a t i v i a l l a v e l o c i t à )
DDP_032 Il campo di dati del messaggio «Positive Response Tran­
sfer Data Detailed Speed» deve fornire nell’ordine sotto
indicato i seguenti dati corrispondenti ai valori esadecimali
SID 76 Hex e TREP 04 o 24 Hex, nonché alla suddivi­
sione e al conteggio appropriati dei sottomessaggi:
Struttura dei dati di prima generazione (TREP 04 Hex)
Elemento di dati Osservazioni
VuDetailedSpeedData Tutti i dati dettagliati relativi alla velocità memorizzati
nella VU (un blocco di velocità per ogni minuto di
marcia del veicolo)
60 valori della velocità al minuto (uno al secondo).
Signature Firma RSA di tutti i dati a partire da noOfSpeedBlocks
fino all’ultimo byte dell’ultimo blocco di velocità.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 348
Struttura dei dati di seconda generazione (TREP 24 Hex)
Elemento di dati Osservazioni
VuDetailedSpeedBlockRecordArray Tutti i dati dettagliati relativi alla velocità memorizzati
nella VU (un blocco di velocità per ogni minuto di
marcia del veicolo)
60 valori della velocità al minuto (uno al secondo).
SignatureRecordArray Firma ECC di tutti i dati precedenti.
2.2.6.6 P o s i t i v e R e s p o n s e T r a n s f e r D a t a T e c h n i c a l D a t a
( r i s p o s t a p o s i t i v a d i t r a s f e r i m e n t o d a t i t e c n i c i )
DDP_033 Il campo dati del messaggio «Positive Response Transfer
Data Technical Data» deve fornire nell’ordine sotto indicato
i seguenti dati corrispondenti ai valori esadecimali SID 76
Hex e TREP 05, 25 o 35 Hex, nonché alla suddivisione e al
conteggio appropriati dei sottomessaggi:
Struttura dei dati di prima generazione (TREP 05 Hex)
Elemento di dati Osservazioni
VuIdentification
SensorPaired
VuCalibrationData Tutti le registrazioni di taratura memorizzate nella VU.
Signature Firma RSA di tutti i dati a partire da vuManufacturer­
Name fino all’ultimo byte dell’ultimo VuCalibrationRe­
cord.
Struttura dei dati di seconda generazione, versione 1 (TREP 25 Hex)
Elemento di dati Osservazioni
VuIdentificationRecordArray
VuSensorPairedRecordArray Tutti gli abbinamenti di MS memorizzati nella VU
VuSensorExternalGNSSCoupledRecordAr­
ray
Tutti gli accoppiamenti del dispositivo GNSS esterno
memorizzati nella VU
VuCalibrationRecordArray Tutti le registrazioni di taratura memorizzate nella VU.
VuCardRecordArray Tutti i dati relativi all’inserimento della carta memoriz­
zati nella VU.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray Firma ECC di tutti i dati precedenti.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 349
Struttura dei dati di seconda generazione, versione 2 (TREP 35 Hex)
Elemento di dati Osservazioni
VuIdentificationRecordArray
VuSensorPairedRecordArray Tutti gli abbinamenti di MS memorizzati nella VU
VuSensorExternalGNSSCoupledRecordAr­
ray
Tutti gli accoppiamenti del dispositivo GNSS esterno
memorizzati nella VU
VuCalibrationRecordArray Tutti le registrazioni di taratura memorizzate nella VU.
VuCardRecordArray Tutti i dati relativi all’inserimento della carta memoriz­
zati nella VU.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray Firma ECC di tutti i dati precedenti.
▼B
2.3. Memorizzazione dei file ESM
DDP_034 Se una sessione di trasferimento comprende dati relativi alla
VU, l'IDE deve memorizzare in un unico file fisico tutti i
dati ricevuti dalla VU nel corso della sessione nell'ambito
dei messaggi di Risposta positiva di trasferimento dati. I
dati memorizzati non comprendono le intestazioni dei mes­
saggi, i contatori dei sottomessaggi, i sottomessaggi vuoti e
i totali di controllo, ma comprendono SID e TREP (relativi
soltanto al primo sottomessaggio nel caso di più sottomes­
saggi).
3. PROTOCOLLO DI TRASFERIMENTO DEI DATI DELLE CARTE
TACHIGRAFICHE
3.1. Campo di applicazione
Il presente punto descrive il trasferimento diretto dei dati di una carta
tachigrafica ad un IDE. Quest'ultimo non fa parte dell'ambiente sicuro;
quindi non viene eseguita alcuna autenticazione tra la carta e l'IDE.
3.2. Definizioni
Sessione di trasferimento: ogni trasferimento di dati del­
l'ICC. La sessione comprende
la procedura completa, dalla rei­
nizializzazione dell'ICC da parte
di un IFD fino alla disattiva­
zione dell'ICC (estrazione della
carta o reinizializzazione suc­
cessiva).
File di dati con firma: un file proveniente dall'ICC. Il
file è trasferito all'IFD con testo
in chiaro. Nell'ICC il file viene
«frammentato» (con la funzione
di hash) e firmato, quindi la
firma è trasferita all'IFD.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 350
3.3. Trasferimento dati carta
▼M3
DDP_035 Il trasferimento dei dati di una carta tachigrafica comprende
le seguenti fasi:
— Trasferimento negli EF ICC e IC dell’informazione co­
mune relativa alla carta. Questa informazione è facolta­
tiva e non è resa sicura mediante firma digitale.
— Per le carte tachigrafiche di prima e seconda generazione
— Trasferimento degli EF all’interno del DF Tacho­
graph:
— trasferimento degli EF Card_Certificate e
CA_Certificate. Questa informazione non è resa
sicura mediante firma digitale;
il trasferimento dei file in questione è obbligato­
rio per ogni sessione di trasferimento;
— trasferimento degli altri EF di dati relativi alle
diverse applicazioni (all’interno del DF Tacho­
graph) ad eccezione dell’EF Card_Download.
Questa informazione è resa sicura mediante firma
digitale utilizzando i meccanismi comuni di sicu­
rezza di cui all’appendice 11, parte A;
— per ogni sessione di trasferimento è obbligatorio
trasferire, quanto meno, gli EF Application_Iden­
tification e Identification;
— quando si trasferiscono i dati relativi alla carta
del conducente è obbligatorio trasferire anche i
seguenti EF:
Events_Data,
Faults_Data,
Driver_Activity_Data,
Vehicles_Used,
Places,
Control_Activity_Data,
Specific_Conditions.
— Solo per le carte tachigrafiche di seconda generazione
— Tranne nel caso in cui il trasferimento dei dati rela­
tivi alla carta del conducente inserita in una VU sia
effettuato da un’autorità di controllo non UE che
utilizza una carta di controllo di prima generazione,
trasferimento degli EF all’interno del Tacho­
graph_G2 DF:
— trasferimento degli EF CardSignCertificate,
CA_Certificate e Link_Certificate. Questa infor­
mazione non è resa sicura mediante firma
digitale;
— il trasferimento dei file in questione è obbligato­
rio per ogni sessione di trasferimento;
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 351
— trasferimento degli altri EF di dati relativi alle di­
verse applicazioni (all’interno del DF Tacho­
graph_G2), ad eccezione dell’EF Card_Download.
Questa informazione è resa sicura mediante firma
digitale utilizzando i meccanismi comuni di sicu­
rezza di cui all’appendice 11, parte B;
— per ogni sessione di trasferimento è obbligatorio
trasferire, quanto meno, gli EF Application_Identi­
fication, Application_Identification_V2 (se pre­
sente) e Identification;
— quando si trasferiscono i dati relativi alla carta
del conducente è obbligatorio trasferire anche i
seguenti EF:
Events_Data,
Faults_Data,
Driver_Activity_Data,
Vehicles_Used,
Places,
Control_Activity_Data,
Specific_Conditions,
VehicleUnits_Used,
GNSS_Places,
Places_Authentication, se presente,
GNSS_Places_Authentication, se presente,
Border_Crossings, se presente,
Load_Unload_Operations, se presente,
Load_Type_Entries, se presente;
— quando si trasferiscono i dati relativi alla carta
del conducente, aggiornare la data del LastCar­
dDownload nell’EF Card_Download, nel tachi­
grafo e, se del caso, nei DF Tachograph_G2;
— quando si trasferiscono i dati relativi alla carta
dell’officina, reinizializzare il contatore di tara­
tura nell’EF Card_Download nel tachigrafo e,
se del caso, nei DF Tachograph_G2;
— quando si trasferiscono i dati relativi alla carta
dell’officina, l’EF Sensor_Installation_Data nel
tachigrafo e, se del caso, i DF Tachograph_G2
non devono essere trasferiti.
▼B
3.3.1 Sequenza di inizializzazione
DDP_036 L'IDE avvia la sequenza nel modo seguente:
Carta Direzione IDE/IFD Significato/Osservazioni
⇦ Reinizializzazione Hardware
ATR ⇨
È facoltativo utilizzare la PPS per passare ad una velocità di
baud maggiore fintanto che l'ICC sia in grado di supportarla.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 352
3.3.2 Sequenza dei file di dati non firmati
DDP_037 ►M1 La sequenza per il trasferimento degli EF ICC, IC,
Card_Certificate (o CardSignCertificate per il DF Tacho­
graph_G2), CA_Certificate e Link_Certificate (solo per il
DF Tachograph_G2) è la seguente: ◄
Carta Direzione IDE/IFD Significato/Osservazioni
⇦ Seleziona file Seleziona mediante identifi­
catori di file
OK ⇨
⇦ Read binary Se il file contiene più dati
della dimensione buffer del
lettore o della carta, è neces­
sario ripetere il comando fino
all'avvenuta lettura del file
completo
File dati
OK
⇨ Invia dati in memoria a ESM secondo 3.4 Formato di me­
morizzazione dei dati
Nota 1: prima di selezionare l'EF Card_Certificate (o Car­
dSignCertificate) è necessario selezionare l'applicazione del
tachigrafo (selezione mediante AID).
Nota 2: La selezione e la lettura di un file può anche essere
effettuata in una sola volta utilizzando il comando Read
binary con un breve identificatore EF.
3.3.3 Sequenza dei file di dati firmati
DDP_038 Per ciascuno dei seguenti file che devono essere trasferiti
insieme alla rispettiva firma è necessario utilizzare la suc­
cessiva sequenza:
▼M1
Carta Dir IDE/IFD Significato/Osservazioni
Seleziona file
OK
Esegui Hash of file — Calcola il valore di hash
sul contenuto dei dati del
file selezionato, mediante
l’algoritmo di hash con­
formemente all’appen­
dice 11, parte A o B. Il
comando in questione
non è del tipo ISO
Calcola il valore di hash
del file e memorizza
temporaneamente tale
valore
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 353
Carta Dir IDE/IFD Significato/Osservazioni
OK
Read Binary Se il file contiene più dati
della dimensione buffer del
lettore o della carta, è neces­
sario ripetere il comando fino
all’avvenuta lettura del file
completo
File dati
OK
Invio dati ricevuti in me­
moria a ESM
secondo 3.4 Controllo inseri­
mento ed estrazione carte
PSO: Compute Digital Si­
gnature
Esegue l’operazione di
sicurezza Compute
Digital Signature me­
diante il valore di hash
temporaneamente me­
morizzato
Signature
OK
Aggiungi dati a quelli pre­
cedentemente memorizzati
nell’ESM
secondo 3.4 Controllo inseri­
mento ed estrazione carte
▼B
Nota: la selezione e la lettura di un file può anche essere
effettuata in una sola volta utilizzando il comando Read
binary con un breve identificatore EF. In questo caso l'EF
può essere selezionato e letto prima di applicare il comando
Perform Hash of File.
3.3.4 Sequenza di azzeramento del contatore di taratura
DDP_039 La sequenza di azzeramento del contatore­
nell'EF
in una carta dell'officina è la seguente:
Carta Dir IDE/IFD Significato/Osservazioni
⇦ Seleziona file EF Card_Dow­
nload
Seleziona mediante identifi­
catori di file
OK ⇨
⇦ Update Binary
NoOfCalibrationsSinceDow­
nload = «00 00»
Reinizializza il numero
di trasferimento della
carta
OK ⇨
Nota: la selezione e la lettura di un file può anche essere
effettuata in una sola volta utilizzando il comando Update
binary con un breve identificatore EF.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 354
3.4. Formato di memorizzazione dei dati
3.4.1 Introduzione
DDP_040 La memorizzazione dei dati trasferiti deve avvenire nel ri­
spetto delle seguenti condizioni:
— I dati devono essere memorizzati in modo trasparente.
Ciò significa che durante la memorizzazione è necessa­
rio rispettare l'ordine dei byte, così come quello dei bit
all'interno dei byte trasferiti dalla carta.
— Tutti i file della carta trasferiti nell'ambito di una stessa
sessione sono memorizzati nell'ESM in un unico file.
3.4.2 Formato dei file
DDP_041 Il formato dei file è costituito da una concatenazione di
diversi oggetti TLV.
DDP_042 Il tag di un EF deve essere costituito dal FID seguito dal­
l'appendice «00».
DDP_043 Il tag di una firma relativa ad un EF deve essere costituito
dal FID del file stesso seguito dall'appendice «01».
DDP_044 La lunghezza è un valore di due byte. Tale valore definisce
il numero di byte che costituiscono il campo valori. Il valore
«FF FF» nel campo relativo alla lunghezza è riservato per
un uso futuro.
DDP_045 In caso di mancato trasferimento di un file, non deve essere
memorizzato alcun dato ad esso relativo (nessun tag né
valore zero relativo alla lunghezza).
▼M1
DDP_046 Una firma deve essere memorizzata come l’oggetto TLV
immediatamente successivo all’oggetto TLV contenente i
dati del file.
Definizione Significato Lunghezza
FID (2 byte) || «00» Tag per EF (FID) all’in­
terno del DF
o per l’in­
formazione comune relativa
alla carta.
3 byte
FID (2 byte) || «01» Tag per firma di EF (FID)
all’interno del DF
3 byte
FID (2 byte) || «02» Tag per firma di EF (FID)
all’interno del DF
3 byte
FID (2 byte) || «03» Tag per firma di EF (FID)
all’interno del DF
3 byte
xx xx Lunghezza campo valori 2 byte
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 355
Esempio di dati contenuti in un file trasferito nell’ESM:
Tag Lunghezza Valore
— Dati dell’EF ICC
— Dati dell’EF Card_Certificate
— …
Dati dell’EF
(all’interno del DF )
Firma dell’EF
(all’interno del DF )
Dati dell’EF (all’in­
terno del DF )
Firma dell’EF
(all’interno del DF )
▼B
4. TRASFERIMENTO DEI DATI DI UNA CARTA TACHIGRAFICA
MEDIANTE UN'UNITÀ ELETTRONICA DI BORDO.
DDP_047 La VU deve consentire di trasferire il contenuto della carta
del conducente inserita ad un IDE ad essa collegata.
DDP_048 L'IDE invia un messaggio di «Richiesta di trasferimento dati
della carta tachigrafica» alla VU per iniziare questo modo
(cfr. 2.2.2.9).
▼M1
DDP_049 Carte del conducente di prima generazione: i dati vanno
trasferiti utilizzando il protocollo di trasferimento dati di
prima generazione; i dati trasferiti devono avere lo stesso
formato dei dati trasferiti da un’unità elettronica di bordo di
prima generazione.
Carte del conducente di seconda generazione: la VU trasfe­
risce quindi l’intero contenuto della carta, file dopo file, in
conformità del protocollo di trasferimento dati della carta
illustrato al punto 3, e invia tutti i dati ricevuti dalla carta
all’IDE nel formato file TLV appropriato (cfr. 3.4.2) e in­
capsulati all’interno di un messaggio "Risposta positiva di
trasferimento dati.
▼B
DDP_050 L'IDE recupera i dati della carta dal messaggio «Risposta
positiva di trasferimento dati» (eliminando tutte le intesta­
zioni, i SID, i TREP, i contatori di sottomessaggi, e i totali
di controllo) e li memorizza all'interno di un unico file
fisico secondo quanto descritto al punto 2.3.
DDP_051 In seguito la VU, se del caso, aggiorna il file­
o il file della carta
del conducente.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 356
Appendice 8
PROTOCOLLO DI TARATURA
INDICE
1. INTRODUZIONE
2. TERMINI, DEFINIZIONI E RIFERIMENTI
3. PROSPETTO DEI SERVIZI
3.1. Servizi disponibili
3.2. Codici di risposta
4. SERVIZI DI COMUNICAZIONE
4.1. Servizio StartCommunication
4.2. Servizio StopCommunication
4.2.1 Descrizione del messaggio
4.2.2 Formato del messaggio
4.2.3 Definizione dei parametri
4.3. Servizio TesterPresent
4.3.1 Descrizione del messaggio
4.3.2 Formato del messaggio
5. SERVIZI DI GESTIONE
5.1. Servizio StartDiagnosticSession
5.1.1 Descrizione del messaggio
5.1.2 Formato del messaggio
5.1.3 Definizione dei parametri
5.2. Servizio SecurityAccess
5.2.1 Descrizione del messaggio
5.2.2 Formato del messaggio — SecurityAccess — requestSeed
5.2.3 Formato del messaggio — SecurityAccess — sendKey
6. SERVIZI DI TRASMISSIONE DATI
6.1. ReadDataByIdentifier service
6.1.1 Descrizione del messaggio
6.1.2 Formato del messaggio
6.1.3 Definizione dei parametri
6.2. Servizio WriteDataByIdentifier
6.2.1 Descrizione del messaggio
6.2.2 Formato del messaggio
6.2.3 Definizione dei parametri
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 357
7. CONTROLLO DEGLI IMPULSI DI PROVA — UNITÀ FUNZIO­
NALE DI CONTROLLO DEI SEGNALI DI ENTRATA/USCITA
7.1. Servizio di InputOutputControlByIdentifier
7.1.1 Descrizione del messaggio
7.1.2 Formato del messaggio
7.1.3 Definizione dei parametri
▼M3
8. SERVIZIO ROUTINECONTROL (REGOLAZIONE DELL’ORA)
8.1. Descrizione del messaggio
8.2. Formato del messaggio
9. FORMATI DEL PARAMETRO DATARECORDS
9.1. Valori limite dei parametri trasmessi
9.2. Formati del parametro dataRecords
▼B
1. INTRODUZIONE
La presente appendice descrive come avviene lo scambio di dati tra
l'unità elettronica di bordo e un tester (apparecchio di prova) attraverso
la linea K, che costituisce parte dell'interfaccia di taratura illustrata
nell'appendice 6. Essa descrive inoltre il controllo della linea dei se­
gnali di entrata/uscita sul connettore di taratura.
La procedura per stabilire le comunicazioni sulla linea K è descritta
nella sezione 4 «Communication Services».
La presente appendice si avvale del concetto di «sessioni» diagnostiche
per stabilire la finalità del controllo sulla linea K in diverse condizioni.
L'impostazione predefinita è la «StandardDiagnosticSession» (sessione
diagnostica standard), che consente la lettura di tutti i dati dell'unità
elettronica di bordo ma non la scrittura di dati nell'unità stessa.
Il prospetto delle sessioni diagnostiche è riportato nella sezione 5 «Ma­
nagement Services».
La presente appendice riguarda entrambe le generazioni di VU e di
carte dell'officina conformemente alle prescrizioni di interoperabilità di
cui al presente regolamento.
CPR_001 La «ECUProgrammingSession» (sessione di programma­
zione ECU) consente l'inserimento dei dati nell'unità elet­
tronica di bordo. In caso di inserimento dei dati di taratura,
l'unità elettronica di bordo deve inoltre essere in modalità
TARATURA (CALIBRATION).
La procedura di trasferimento dati sulla linea K è descritta
nella sezione 6 «Data Transmission Services». Il formato dei
dati trasferiti è descritto in dettaglio nella sezione 8 «data­
Records formats».
CPR_002 La «ECUAdjustmentSession» (sessione di regolazione ECU)
consente di selezionare la modalità I/O della linea dei se­
gnali di taratura attraverso l'interfaccia della linea K. Il con­
trollo della linea dei segnali di entrata/uscita è descritto nella
sezione 7 «Control of Test Pulses — Input/Output Control
functional unit».
CPR_003 Nel presente documento l'indirizzo del tester è indicato
come «tt». Nonostante vi possano essere indirizzi preferen­
ziali, la VU deve rispondere correttamente a qualsiasi indi­
rizzo di tester. L'indirizzo fisico della VU è 0xEE.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 358
2. TERMINI, DEFINIZIONI E RIFERIMENTI
I protocolli, i messaggi ed i codici di errore si basano in gran parte sul
progetto di norma ISO 14299-1 (Road vehicles — Diagnostic systems
— Part 1: Diagnostic services, versione 6 del 22 febbraio 2001).
Per gli identificativi di servizio, le richieste di servizio e le relative
risposte e per i parametri standard si utilizzano la codifica a byte e i
valori esadecimali.
Il termine «tester» si riferisce all'apparecchio utilizzato per l'inserimento
dei dati di programmazione/taratura nella VU.
I termini «client» e «server» si riferiscono rispettivamente al tester e
alla VU.
Il termine ECU (Electronic Control Unit — Unità elettronica di con­
trollo) si riferisce alla VU.
Riferimenti:
▼M1
ISO 14230-2: Road Vehicles -Diagnostic Systems — Keyword Proto­
col 2000- Part 2: Data Link Layer.
First edition: 1999.
▼B
3. PROSPETTO DEI SERVIZI
3.1. Servizi disponibili
La seguente tabella fornisce il prospetto dei servizi disponibili nel
tachigrafo e definiti nell'ambito del presente documento.
CPR_004 La tabella indica i servizi disponibili in una sessione diagno­
stica abilitata.
— La 1 a colonna elenca i servizi disponibili.
— La 2 a colonna indica il numero della sezione all'interno
della presente appendice in cui il servizio è ulterior­
mente definito.
— La 3 a colonna assegna i valori degli identificativi di
servizio per i messaggi di richiesta.
— La 4 a colonna specifica i servizi di «StandardDiagno­
sticSession» (SD) che devono essere implementati in
ogni VU.
— La 5 a colonna specifica i servizi di «ECUAdjustmen­
tSession» (ECUAS) che devono essere implementati per
consentire il controllo della linea dei segnali I/O nel
connettore di taratura situato sul pannello frontale della
VU.
— La 6 a colonna specifica i servizi di «ECUProgrammin­
gSession» (ECUPS) che devono essere implementati per
consentire la programmazione dei parametri all'interno
della VU.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 359
Tabella 1
Tabella riassuntiva dei valori degli identificativi di servizio
Sessioni diagnostiche
Nome del servizio diagnostico
Sezione
n.
Val. rich. SID SD ECUAS ECUPS
StartCommunication 4.1 81 ■ ■ ■
StopCommunication 4.2 82 ■
Testerpresent 4.3 3E ■ ■ ■
StartDiagnosticSession 5.1 10 ■ ■ ■
SecurityAccess 5.2 27 ■ ■ ■
ReadDataByIdentifier 6.1 22 ■ ■ ■
WriteDataByIdentifier 6.2 2E ■
InputOutputControlByIdentifier 7.1 2F ■
▼M3
RoutineControl 8 31
▼B
■ Questo simbolo indica che il servizio è obbligatorio nella corrispondente sessione
diagnostica.
L'assenza di simboli indica che il servizio in questione non è consentito nella corrispondente
sessione diagnostica.
3.2. Codici di risposta
Per ogni servizio sono definiti appositi codici di risposta.
4. SERVIZI DI COMUNICAZIONE
Determinati servizi sono necessari per stabilire e mantenere le comu­
nicazioni e non compaiono al livello di applicazione. I servizi dispo­
nibili sono descritti nella seguente tabella:
Tabella 2
Servizi di comunicazione
Nome del servizio Descrizione
StartCommunication Il client richiede l'inizio di una ses­
sione di comunicazione con il/i server.
StopCommunication Il client richiede il termine della ses­
sione di comunicazione attiva.
Testerpresent Il client segnala al server di essere an­
cora in contatto.
CPR_005 Il servizio StartCommunication è utilizzato per iniziare una co­
municazione. Per poter eseguire qualsiasi servizio è necessario
inizializzare la comunicazione in oggetto ed i parametri di comu­
nicazione devono essere quelli adatti alla modalità richiesta.
4.1. Servizio StartCommunication
CPR_006 Alla ricezione di una primitiva di indicazione di StartCom­
munication, la VU deve verificare se nelle condizioni vi­
genti sia possibile inizializzare il collegamento della comu­
nicazione richiesta. Le condizioni valide per l'inizializza­
zione del collegamento sono descritte nel documento della
norma ISO 14230-2.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 360
CPR_007 Quindi la VU deve compiere tutte le azioni necessarie a
inizializzare il collegamento ed inviare una primitiva di ri­
sposta di StartCommunication con i parametri di Risposta
Positiva selezionati.
CPR_008 Se una VU già inizializzata (con qualsiasi sessione diagno­
stica in corso) riceve un nuovo messaggio StartCommuni­
cation Request (ad esempio a causa del recupero dell'errore
nel tester) la richiesta deve essere accettata e la VU nuova­
mente inizializzata.
CPR_009 Se per qualsiasi motivo non è possibile procedere all'inizia­
lizzazione del collegamento, la VU deve continuare a fun­
zionare nelle condizioni immediatamente precedenti al ten­
tativo di inizializzazione.
CPR_010 Il messaggio StartCommunication Request deve essere indi­
rizzato fisicamente.
CPR_011 L'inizializzazione della VU per i servizi è effettuata con un
metodo di «inizializzazione veloce», che prevede:
— un tempo di inattività del bus prima di qualsiasi attività,
— il susseguente invio da parte del tester di una configu­
razione di inizializzazione,
— la presenza nella risposta della VU di tutte le informa­
zioni necessarie a stabilire la comunicazione.
CPR_012 Una volta completata l'inizializzazione:
— tutti i parametri di comunicazione sono impostati sui
valori predefiniti nella Tabella 4, conformemente ai
byte chiave,
— la VU resta in attesa della prima richiesta da parte del
tester,
— la VU risulta in modalità di diagnosi predefinita, ovvero
impostata su StandardDiagnosticSession,
— la linea dei segnali I/O di taratura è nell'impostazione
predefinita, ovvero disabilitata.
CPR_014 La velocità di trasmissione dei dati (data rate) sulla linea K
deve essere di 10 400 baud.
CPR_016 L'inizializzazione veloce è avviata dal tester con la trasmis­
sione della sequenza di riattivazione (Wup) sulla linea K. La
sequenza inizia con un tempo breve di Tinil dopo il tempo
di inattività sulla linea K. Il tester trasmette quindi il primo
bit del servizio StartCommunication dopo un tempo di
Twup successivo al primo fronte di discesa.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 361
CPR_017 I valori di temporizzazione per l'inizializzazione veloce e le
comunicazioni in generale sono illustrati nelle seguenti ta­
belle. Vi sono differenti possibilità per ciò che riguarda il
tempo di inattività:
— prima trasmissione seguente l'accensione, Tidle =
300ms,
— dopo il completamento di un servizio StopCommunica­
tion, Tidle = P3min,
— dopo il termine della comunicazione a causa di un time-out
(superamento del tempo limite) P3max, Tidle = 0.
Tabella 3
Valori di temporizzazione per l'inizializzazione veloce
Parametro Valore minimo Valore massimo
Tinil 25 ± 1 ms 24 ms 26 ms
Twup 50 ± 1 ms 49 ms 51 ms
Tabella 4
Valori di temporizzazione della comunicazione
Temporizza­
zione Para­
metro
Descrizione parametro
Valore minimo
[ms]
Valore massimo
[ms]
min max
P1 Intervallo di tempo tra byte per
la risposta della VU
0 20
P2 Tempo intercorrente tra la ri­
chiesta del tester e la risposta
della VU o tra due risposte
della VU
25 250
P3 Tempo intercorrente tra la con­
clusione delle risposte della
VU e l'inizio di una nuova ri­
chiesta del tester
55 5 000
P4 Intervallo di tempo tra byte per
la richiesta del tester
5 20
CPR_018 Il formato del messaggio per l'inizializzazione veloce è de­
scritto nelle tabelle seguenti. (NOTE: Hex means hexadeci­
mal)
Tabella 5
Messaggio di StartCommunication Request
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
81 FMT
# 2 Byte dell'indirizzo di destina­
zione
EE TGT
# 3 Byte dell'indirizzo di prove­
nienza
tt SRC
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 362
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 4 StartCommunication Request
Service Id
81 SCR
# 5 Totale di controllo 00-FF CS
Tabella 6
Messaggio di StartCommunication Positive Response
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
tt TGT
# 3 Byte dell'indirizzo di prove­
nienza
EE SRC
# 4 Byte di lunghezza aggiuntivo 03 LEN
# 5 StartCommunication Positive
Response Service Id
C1 SCRPR
# 6 Byte-chiave 1 EA KB1
# 7 Byte-chiave 2 8F KB2
# 8 Totale di controllo 00-FF CS
CPR_019 Non vi è alcuna risposta negativa al messaggio StartCom­
munication Request; in assenza di messaggi di risposta po­
sitiva da trasmettere, la VU non viene inizializzata, rimane
in modalità di funzionamento normale e non vi è
trasmissione.
4.2. Servizio StopCommunication
4.2.1 Descrizione del messaggio
Questo servizio conclude una sessione di comunicazione.
CPR_020 Al ricevimento di una primitiva di indicazione di StopCom­
munication, la VU deve verificare se nelle condizioni vi­
genti sia possibile concludere la comunicazione in atto. In
tal caso la VU compie tutte le azioni necessarie per con­
cludere questa comunicazione.
CPR_021 Se la conclusione della comunicazione risulta attuabile,
prima di procedere la VU invia una primitiva di risposta
di StopCommunication con i parametri di Positive Response
(risposta positiva) selezionati.
CPR_022 Se invece per qualsiasi motivo non è possibile concludere la
comunicazione, la VU invia una primitiva di risposta di
StopCommunication con il parametro di Negative Response
(risposta negativa) selezionato.
CPR_023 In caso di riscontro da parte della VU di un superamento del
tempo limite P3max, la comunicazione viene conclusa senza
l'invio di una primitiva di risposta.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 363
4.2.2 Formato del messaggio
CPR_024 I formati dei messaggi per le primitive di StopCommunica­
tion sono descritti nelle seguenti tabelle.
Tabella 7
Messaggio di StopCommunication Request
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
EE TGT
# 3 Byte dell'indirizzo di prove­
nienza
tt SRC
# 4 Byte di lunghezza aggiuntivo 01 LEN
# 5 StopCommunication Request
Service Id
82 SPR
# 6 Totale di controllo 00-FF CS
Tabella 8
Messaggio di StopCommunication Positive Response
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
tt TGT
# 3 Byte dell'indirizzo di prove­
nienza
EE SRC
# 4 Byte di lunghezza aggiuntivo 01 LEN
# 5 StopCommunication Positive
Response Service Id
C2 SPRPR
# 6 Totale di controllo 00-FF CS
Tabella 9
Messaggio di StopCommunication Negative Response
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
tt TGT
# 3 Byte dell'indirizzo di prove­
nienza
EE SRC
# 4 Byte di lunghezza aggiuntivo 03 LEN
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 364
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 5 negative Response Service Id 7F NR
# 6 StopCommunication Request
Service Identification
82 SPR
# 7 responseCode = generalReject 10 RC_GR
# 8 Totale di controllo 00-FF CS
4.2.3 Definizione dei parametri
Questo servizio non richiede la definizione di parametri.
4.3. Servizio TesterPresent
4.3.1 Descrizione del messaggio
Il servizio TesterPresent è impiegato dal tester per indicare al server di
essere ancora in collegamento, in modo che il server non torni auto­
maticamente alla modalità di funzionamento normale, interrompendo
eventualmente la comunicazione. Tale servizio, attivato periodicamente,
mantiene attiva la sessione diagnostica/di comunicazione reimpostando
il timer P3 ogni volta che il servizio stesso viene richiesto.
4.3.2 Formato del messaggio
CPR_079 I formati dei messaggi per le primitive di TesterPresent sono
descritti nelle seguenti tabelle.
Tabella 10
Messaggio di TesterPresent Request
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
EE TGT
# 3 Byte dell'indirizzo di prove­
nienza
tt SRC
# 4 Byte di lunghezza aggiuntivo 02 LEN
# 5 TesterPresent Request Ser­
vice Id
3E TP
# 6 Sub Function = re­
sponseRequired =
[ sì 01 RESPREQ_Y
no ] 02 RESPREQ_NO
# 7 Totale di controllo 00-FF CS
CPR_080 Se il parametro responseRequired è impostato su «sì» il
server deve rispondere con il seguente messaggio di risposta
positiva. Se è impostato su «no» il server non invia alcuna
risposta.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 365
Tabella 11
Messaggio di TesterPresent Positive Response
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
tt TGT
# 3 Byte dell'indirizzo di prove­
nienza
EE SRC
# 4 Byte di lunghezza aggiuntivo 01 LEN
# 5 TesterPresent Positive Re­
sponse Service Id
7E TPPR
# 6 Totale di controllo 00-FF CS
CPR_081 Il presente servizio utilizza i seguenti codici di risposta
negativa:
Tabella 12
Messaggio di TesterPresent Negative Response
Byte # Denominazione del parametro
Valore
esadeci­
male
Mnemonico
# 1 Byte di formato — indirizzamento
fisico
80 FMT
# 2 Byte dell'indirizzo di destinazione tt TGT
# 3 Byte dell'indirizzo di provenienza EE SRC
# 4 Byte di lunghezza aggiuntivo 03 LEN
# 5 negative Response Service Id 7F NR
# 6 TesterPresent Request Service Identi­
fication
3E TP
# 7 response­
Code =
[SubFunctionNotSup­
ported-InvalidFormat
12 RC_SFNS_IF
incorrectMessage­
Length]
13 RC_IML
# 8 Totale di controllo 00-FF CS
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 366
5. SERVIZI DI GESTIONE
I servizi disponibili sono descritti nella seguente tabella:
Tabella 13
Servizi di gestione
Nome del servizio Descrizione
StartDiagnosticSession Il client richiede l'avvio della sessione dia­
gnostica con una VU.
SecurityAccess Il client richiede l'accesso a funzioni riser­
vate ad utenti autorizzati.
5.1. Servizio StartDiagnosticSession
5.1.1 Descrizione del messaggio
CPR_025 Il servizio StartDiagnosticSession serve ad abilitare nel ser­
ver sessioni diagnostiche differenti. Una sessione diagno­
stica abilita una serie specifica di servizi secondo la Tabella
17. Nel corso di una sessione possono essere attivati servizi
specificamente legati alle necessità del costruttore del vei­
colo non previsti nel presente documento. Le regole di at­
tuazione devono soddisfare i seguenti requisiti:
— nella VU deve essere sempre attiva una ed una sola
sessione diagnostica,
— all'accensione, la Vu deve sempre attivare la Standar­
dDiagnosticSession. Se non viene attivata nessun'altra
sessione diagnostica, la StandardDiagnosticSession
deve continuare a funzionare fintantoché la VU è accesa,
— se il tester richiede una sessione diagnostica già attiva, la
VU deve inviare un messaggio di risposta positiva,
— quando il tester richiede una nuova sessione diagnostica,
la VU deve innanzitutto inviare un messaggio di risposta
positiva di StartDiagnosticSession prima di attivare la
nuova sessione. Se non è in grado di avviare la nuova
sessione diagnostica richiesta, la VU deve inviare un
messaggio di risposta negativa di StartDiagnosticSession
e mantenere attiva la sessione corrente.
CPR_026 L'avvio di una sessione diagnostica deve avere luogo sol­
tanto in presenza di comunicazioni già stabilite tra il client e
la VU.
CPR_027 I parametri di temporizzazione definiti nella Tabella 4 de­
vono attivarsi in seguito all'invio completato con successo
del messaggio StartDiagnosticSession, con parametro dia­
gnosticSession impostato su «StandardDiagnosticSession»
nel messaggio di richiesta nel caso in cui in precedenza
sia già stata attivata un'altra sessione diagnostica.
5.1.2 Formato del messaggio
CPR_028 I formati dei messaggi per le primitive di StartDiagnostic­
Session sono descritti nelle seguenti tabelle.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 367
Tabella 14
Messaggio di StartDiagnosticSession Request
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
EE TGT
# 3 Byte dell'indirizzo di prove­
nienza
tt SRC
# 4 Byte di lunghezza aggiuntivo 02 LEN
# 5 StartDiagnosticSession Re­
quest Service Id
10 STDS
# 6 diagnosticSession = [un valore
da Tabella 17]
xx DS_…
# 7 Totale di controllo 00-FF CS
Tabella 15
Messaggio di StartDiagnosticSession Positive Response
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
tt TGT
# 3 Byte dell'indirizzo di prove­
nienza
EE SRC
# 4 Byte di lunghezza aggiuntivo 02 LEN
# 5 StartDiagnosticSession Posi­
tive Response Service Id
50 STDSPR
# 6 diagnosticSession = [ stesso
valore del byte # 6 Tabella 14]
xx DS_…
# 7 Totale di controllo 00-FF CS
Tabella 16
Messaggio di StartDiagnosticSession Negative Response
Byte # Denominazione del parametro
Valore
esadeci­
male
Mnemonico
# 1 Byte di formato — indirizzamento
fisico
80 FMT
# 2 Byte dell'indirizzo di destinazione tt TGT
# 3 Byte dell'indirizzo di provenienza EE SRC
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 368
Byte # Denominazione del parametro
Valore
esadeci­
male
Mnemonico
# 4 Byte di lunghezza aggiuntivo 03 LEN
# 5 Negative Response Service Id 7F NR
# 6 StartDiagnosticSession Request Ser­
vice Id
10 STDS
# 7 Response­
Code =
[subFunctionNotSup­
ported ( α )
12 RC_SFNS
incorrectMessage­
Length ( β )
13 RC_IML
conditionsNotCor­
rect ( γ )
22 RC_CNC
# 8 Totale di controllo 00-FF CS
( α ) il valore inserito nel byte # 6 del messaggio di richiesta non è supportato, ossia non
è contenuto nella Tabella 17,
( β ) la lunghezza del messaggio non è corretta,
( γ ) i criteri per la richiesta StartDiagnosticSession non sono soddisfatti.
5.1.3 Definizione dei parametri
CPR_029 Il parametro diagnosticSession (DS_) è utilizzato nell'am­
bito del servizio StartDiagnosticSession per selezionare il
ruolo specifico del/i server. Nel presente documento sono
descritte le seguenti sessioni diagnostiche:
Tabella 17
Definizione dei valori DiagnosticSession
Valore esa­
decimale
Descrizione Mnemonico
81 StandardDiagnosticSession
Questa sessione diagnostica abilita tutti i servizi
riportati nella Tabella 1 colonna 4 «SD». Tali
servizi consentono la lettura dei dati inviati dal
server (VU). Questa sessione diagnostica si attiva
in seguito all'inizializzazione completata con
successo tra client (tester) e server (VU) e può
essere sovrascritta dalle altre sessioni diagnos-
tiche descritte nella presente sezione.
SD
85 ECUProgrammingSession
Questa sessione diagnostica abilita tutti i servizi
riportati nella Tabella 1 colonna 6«ECUPS».
Tali servizi supportano la programmazione della
memoria del server (VU). La sessione diagnos-
tica può essere sovrascritta dalle altre sessioni
diagnostiche descritte nella presente sezione.
ECUPS
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 369
Valore esa­
decimale
Descrizione Mnemonico
87 ECUAdjustmentSession
Questa sessione diagnostica abilita tutti i servizi
riportati nella Tabella 1 colonna 5 «ECUAS».
Tali servizi supportano il controllo messaggi in
entrata/uscita del server (VU) e può essere
sovrascritta dalle altre sessioni diagnostiche
descritte nella presente sezione.
ECUAS
5.2. Servizio SecurityAccess
La scrittura dei dati di taratura è consentita solo se la VU si trova nella
modalità CALIBRATION (TARATURA). Oltre all'inserimento di una
carta dell'officina valida all'interno della VU, è necessario inserire nella
VU il codice PIN appropriato prima che sia consentito l'accesso alla
modalità CALIBRATION.
Quando la VU è in modalità CALIBRATION o CONTROL, è possi­
bile anche l'accesso alla linea dei segnali di entrata/uscita di taratura.
Il servizio SecurityAccess fornisce un mezzo per l'inserimento del co­
dice PIN e per segnalare al tester se la VU si trova in modalità CALI­
BRATION o meno.
È possibile inserire il codice PIN anche con procedure alternative.
5.2.1 Descrizione del messaggio
Il servizio SecurityAccess consiste nell'invio del messaggio SecurityAc­
cess «requestSeed», seguito dal messaggio SecurityAccess «sendKey».
È necessario eseguire il servizio in questione successivamente al ser­
vizio StartDiagnosticSession.
CPR_033 Il tester deve utilizzare il messaggio SecurityAccess «reque­
stSeed» per verificare se l'unità elettronica di bordo sia
pronta a ricevere il codice PIN.
CPR_034 Nel caso in cui l'unità elettronica di bordo si trovi già in
modalità CALIBRATION, deve rispondere alla richiesta in­
viando un «seed» del valore di 0x0000 utilizzando il servi­
zio SecurityAccess Positive Response.
CPR_035 Se l'unità elettronica di bordo è predisposta alla ricezione
del codice PIN proveniente da una carta dell'officina per
effettuarne la verifica, deve rispondere alla richiesta in­
viando un «seed» superiore a 0x0000 mediante il servizio
SecurityAccess Positive Response.
CPR_036 In caso invece di unità elettronica di bordo non predisposta
alla ricezione del codice PIN da parte del tester, a causa
dell'inserimento di una carta dell'officina non valida, del
mancato inserimento di una carta dell'officina o della predi­
sposizione dell'unità elettronica di bordo alla ricezione del
codice PIN attraverso altre procedure, la stessa VU deve
rispondere alla richiesta con un messaggio di Negative Re­
sponse (risposta negativa) contenente un codice di risposta
impostato su conditionsNotCorrectOrRequestSequenceError.
CPR_037 Il tester deve utilizzare infine il messaggio SecurityAccess
«sendKey» per inviare il codice PIN all'unità elettronica di
bordo. Al fine di garantire il tempo necessario per l'esecu­
zione della procedura di autenticazione della carta, la VU
deve impiegare il codice di risposta negativa
requestCorrectlyReceived-ResponsePending per prolungare
il tempo di risposta. Il tempo massimo di risposta non
deve comunque superare i 5 minuti. Quando il servizio
richiesto è stato completato, la VU deve inviare
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 370
un messaggio di risposta positiva o negativa, con un codice
di risposta diverso dal precedente. Il codice negativo di
risposta requestCorrectlyReceived-ResponsePending può es­
sere ripetuto dalla VU fintantoché il servizio richiesto non è
stato completato ed il messaggio di risposta conclusivo non
è stato inviato.
CPR_038 L'unità elettronica di bordo deve rispondere a tale richiesta
attraverso il servizio SecurityAccess Positive Response sol­
tanto quando si trova in modalità CALIBRATION.
CPR_039 Nei casi seguenti, l'unità elettronica di bordo deve rispon­
dere alla richiesta in questione con un messaggio di Nega­
tive Response (risposta negativa) contenente un codice di
risposta impostato su:
— subFunctionNot supported: formato non valido del para­
metro della sottofunzione (accessType),
— conditionsNotCorrectOrRequestSequenceError: VU non
predisposta a ricevere l'inserimento del codice PIN,
— invalidKey: codice PIN non valido e numero massimo di
tentativi di verifica del codice PIN non superato,
— exceededNumberOfAttempts: codice PIN non valido e
numero massimo di tentativi di verifica del codice PIN
superato,
— generalReject: codice PIN corretto ma reciproca autenti­
cazione con la carta dell'officina fallita.
5.2.2 Formato del messaggio — SecurityAccess — requestSeed
CPR_040 I formati dei messaggi per le primitive di SecurityAccess
«requestSeed» sono descritti nelle seguenti tabelle.
Tabella 18
Messaggio SecurityAccess Request- requestSeed
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
EE TGT
# 3 Byte dell'indirizzo di prove­
nienza
tt SRC
# 4 Byte di lunghezza aggiuntivo 02 LEN
# 5 SecurityAccess Request Ser­
vice Id
27 SA
# 6 accessType — requestSeed 7D AT_RSD
# 7 Totale di controllo 00-FF CS
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 371
Tabella 19
Messaggio di SecurityAccess — requestSeed Positive Response
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
tt TGT
# 3 Byte dell'indirizzo di prove­
nienza
EE SRC
# 4 Byte di lunghezza aggiuntivo 04 LEN
# 5 SecurityAccess Positive Re­
sponse Service Id
67 SAPR
# 6 accessType — requestSeed 7D AT_RSD
# 7 Seed byte alto 00-FF SEEDH
# 8 Seed byte basso 00-FF SEEDL
# 9 Totale di controllo 00-FF CS
Tabella 20
Messaggio di SecurityAccess Negative Response
Byte # Denominazione del parametro
Valore
esadeci­
male
Mnemonico
# 1 Byte di formato — indirizzamento
fisico
80 FMT
# 2 Byte dell'indirizzo di destinazione tt TGT
# 3 Byte dell'indirizzo di provenienza EE SRC
# 4 Byte di lunghezza aggiuntivo 03 LEN
# 5 negativeResponse Service Id 7F NR
# 6 SecurityAccess Request Service Id 27 SA
# 7 response­
Code =
[conditionsNotCorrec­
tOrRequestSequence­
Error
22 RC_CNC
incorrectMessage­
Length]
13 RC_IML
# 8 Totale di controllo 00-FF CS
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 372
5.2.3 Formato del messaggio — SecurityAccess — sendKey
CPR_041 I formati dei messaggi per le primitive di SecurityAccess
«sendKey» sono descritti nelle seguenti tabelle.
Tabella 21
Messaggio di SecurityAccess Request — sendKey Message
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
EE TGT
# 3 Byte dell'indirizzo di prove­
nienza
tt SRC
# 4 Byte di lunghezza aggiuntivo m+2 LEN
# 5 SecurityAccess Request Ser­
vice Id
27 SA
# 6 accessType — sendKey 7E AT_SK
Dal # 7 al #
m+6
Chiave # 1 (alto) xx KEY
… …
Chiave # m (basso, m deve es­
sere compreso tra 4 e 8)
xx
# m+7 Totale di controllo 00-FF CS
Tabella 22
Messaggio di SecurityAccess — sendKey Positive Response
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
tt TGT
# 3 Byte dell'indirizzo di prove­
nienza
EE SRC
# 4 Byte di lunghezza aggiuntivo 02 LEN
# 5 SecurityAccess Positive Re­
sponse Service Id
67 SAPR
# 6 accessType — sendKey 7E AT_SK
# 7 Totale di controllo 00-FF CS
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 373
Tabella 23
Messaggio di SecurityAccess Negative Response
Byte # Denominazione del parametro
Valore
esadeci­
male
Mnemonico
# 1 Byte di formato — indirizzamento
fisico
80 FMT
# 2 Byte dell'indirizzo di destinazione tt TGT
# 3 Byte dell'indirizzo di provenienza EE SRC
# 4 Byte di lunghezza aggiuntivo 03 LEN
# 5 NegativeResponse Service Id 7F NR
# 6 SecurityAccess Request Service Id 27 SA
# 7 Response­
Code =
[generalReject 10 RC_GR
subFunctionNotSup­
ported
12 RC_SFNS
incorrectMessage­
Length
13 RC_IML
conditionsNotCorrec­
tOrRequestSequence­
Error
22 RC_CNC
invalidKey 35 RC_IK
exceededNumberO­
fAttempts
36 RC_ENA
requestCorrectlyRe­
ceived-ResponsePen­
ding]
78 RC_RCR_RP
# 8 Totale di controllo 00-FF CS
6. SERVIZI DI TRASMISSIONE DATI
I servizi disponibili sono descritti nella seguente tabella:
Tabella 24
Servizi di trasmissione dati
Nome del servizio Descrizione
ReadDataByIdentifier Il client richiede la trasmissione del valore
corrente di un record con accesso mediante
recordDataIdentifier.
WriteDataByIdentifier Il client richiede la scrittura di un record con
accesso mediante recordDataIdentifier.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 374
6.1. ReadDataByIdentifier service
6.1.1 Descrizione del messaggio
CPR_050 Il servizio ReadDataByIdentifier è utilizzato dal client per
richiedere valori dei dati registrati dal server. I dati sono
identificati mediante parametro recordDataIdentifier. È re­
sponsabilità del fabbricante della VU assicurare che quando
si utilizza questo servizio lo stato del server sia quello
prescritto.
6.1.2 Formato del messaggio
CPR_051 I formati dei messaggi per le primitive di ReadDataByIden­
tifier sono descritti nelle seguenti tabelle.
Tabella 25
Messaggio di ReadDataByIdentifier Request
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
EE TGT
# 3 Byte dell'indirizzo di prove­
nienza
tt SRC
# 4 Byte di lunghezza aggiuntivo 03 LEN
# 5 ReadDataByIdentifier Re­
quest Service Id
22 RDBI
dal # 6 al
# 7
recordDataIdentifier = [valore
contenuto nella Tabella 28]
xxxx RDI_…
# 8 Totale di controllo 00-FF CS
Tabella 26
Messaggio di ReadDataByIdentifier Positive Response
Byte # Denominazione del parametro
Valore
esadeci­
male
Mnemonico
# 1 Byte di formato — indirizzamento
fisico
80 FMT
# 2 Byte dell'indirizzo di destinazione tt TGT
# 3 Byte dell'indirizzo di provenienza EE SRC
# 4 Byte di lunghezza aggiuntivo m+3 LEN
# 5 ReadDataByIdentifier Positive Re­
sponse Service Id
62 RDBIPR
# 6 e # 7 recordDataIdentifier = [stesso valore
dei byte # 6 e # 7, Tabella 25]
xxxx RDI_…
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 375
Byte # Denominazione del parametro
Valore
esadeci­
male
Mnemonico
Dal # 8
al # m+7
dataRecord[] = [data#1 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DA­
TAm
# m+8 Totale di controllo 00-FF CS
Tabella 27
Messaggio di ReadDataByIdentifier Negative Response
Byte # Denominazione del parametro
Valore
esadeci­
male
Mnemonico
# 1 Byte di formato — indirizzamento
fisico
80 FMT
# 2 Byte dell'indirizzo di destinazione tt TGT
# 3 Byte dell'indirizzo di provenienza EE SRC
# 4 Byte di lunghezza aggiuntivo 03 LEN
# 5 NegativeResponse Service Id 7F NR
# 6 ReadDataByIdentifier Request Ser­
vice Id
22 RDBI
# 7 Response­
Code=
[requestOutO­
fRange
31 RC_ROOR
incorrectMessage­
Length
13 RC_IML
conditionsNotCor­
rect]
22 RC_CNC
# 8 Totale di controllo 00-FF CS
6.1.3 Definizione dei parametri
CPR_052 Il parametro recordDataIdentifier (RDI_) nel messaggio
ReadDataByIdentifier Request identifica un record di dati.
▼M3
CPR_053 I valori di recordDataIdentifier definiti dal presente docu­
mento sono illustrati nella tabella seguente.
La tabella relativa a recordDataIdentifier è costituita da cin­
que colonne e da più righe.
— La 1 a colonna (Valore esadecimale) riporta il valore
esadecimale assegnato al recordDataIdentifier specificato
nella 3 a colonna.
— La 2 a colonna (Elemento di dati) specifica l’elemento
di dati dell’appendice 1 sul quale è basato il recordDa­
taIdentifier (in alcuni casi è necessario transcodificare).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 376
— La 3 a colonna (Descrizione) indica il nome del recor­
dDataIdentifier corrispondente.
— La 4 a colonna (Diritti di accesso) specifica i diritti di
accesso al recordDataIdentifier in questione.
— La 5 a colonna (Mnemonico) specifica l’identificativo
mnemonico del recordDataIdentifier in questione.
Tabella 28
Definizione dei valori recordDataIdentifier
Valore esa­
decimale
Elemento di dati
Nome del recordDataIdentifier
(cfr. formato nella sezione 8.2)
Diritti di
accesso
(Read/
Write)
Mnemonico
F90B CurrentDateTime TimeDate R/W RDI_TD
F912 HighResOdometer HighResolutionTotalVehicleDi­
stance
R/W RDI_HRTVD
F918 K-ConstantOfRecordingEquipment Kfactor R/W RDI_KF
F91C L-TyreCircumference LfactorTyreCircumference R/W RDI_LF
F91D W-VehicleCharacteristicConstant WvehicleCharacteristicFactor R/W RDI_WVCF
F921 TyreSize TyreSize R/W RDI_TS
F922 nextCalibrationDate NextCalibrationDate R/W RDI_NCD
F92C SpeedAuthorised SpeedAuthorised R/W RDI_SA
F97D vehicleRegistrationNation RegisteringMemberState R/W RDI_RMS
F97E VehicleRegistrationNumber VehicleRegistrationNumber R/W RDI_ VRN
F190 VehicleIdentificationNumber VIN R/W RDI_ VIN
F9D0 SensorSerialNumber MotionSensorSerialNumber R RDI_SSN
F9D1 RemoteCommunicationModuleSerial­
Number
RemoteCommunicationFacility­
SerialNumber
R RDI_RCSN
F9D2 SensorGNSSSerialNumber ExternalGNSSFacilitySerialNum­
ber
R RDI_GSSN
F9D3 SealDataVu SmartTachographSealsSerial­
Number
R/W RDI_SDV
F9D4 VuSerialNumber VuSerialNumber R RDI_VSN
F9D5 ByDefaultLoadType ByDefaultLoadType R/W RDI_BDLT
F9D6 TachographCardsGen1Suppression TachographCardsGen1Suppres­
sion
R/W RDI_TCG1S
F9D7 VehiclePosition VehiclePosition R RDI_VP
F9D8 LastCalibrationCountry CalibrationCountry R RDI_CC
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 377
CPR_054 Il parametro dataRecord (DREC_) è utilizzato nell'ambito
del messaggio ReadDataByIdentifier Positive Response per
fornire al client (tester) il record dei dati identificato dal
parametro recordDataIdentifier. Il formato dei dati è indicato
nella sezione 8. Ulteriori dataRecords facoltativi, tra cui i
dati specifici in entrata, quelli interni e quelli in uscita della
VU sono permessi, ma non sono definiti nel presente
documento.
6.2. Servizio WriteDataByIdentifier
6.2.1 Descrizione del messaggio
CPR_056 Il servizio WriteDataByIdentifier è utilizzato dal client per
registrare valori dei dati nel server. I dati sono identificati
mediante parametro recordDataIdentifier. È responsabilità
del fabbricante della VU assicurare che quando si utilizza
questo servizio lo stato del server sia quello prescritto. Per
aggiornare i parametri elencati nella Tabella 28 la VU deve
trovarsi in modalità CALIBRATION.
6.2.2 Formato del messaggio
CPR_057 I formati dei messaggi per le primitive di WriteDataByIden­
tifier sono descritti nelle seguenti tabelle.
Tabella 29
Messaggio di WriteDataByIdentifier Request
Byte # Denominazione del parametro
Valore
esadeci­
male
Mnemonico
# 1 Byte di formato — indirizzamento
fisico
80 FMT
# 2 Byte dell'indirizzo di destinazione EE TGT
# 3 Byte dell'indirizzo di provenienza tt SRC
# 4 Byte di lunghezza aggiuntivo m+3 LEN
# 5 WriteDataByIdentifier Request
Service Id
2E WDBI
dal # 6 al
# 7
recordDataIdentifier = [valore conte­
nuto nella Tabella 28]
xxxx RDI_…
#8 to m+7 dataRecord[] = [data#1 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DA­
TAm
# m+8 Totale di controllo 00-FF CS
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 378
Tabella 30
Messaggio di WriteDataByIdentifier Positive Response
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
tt TGT
# 3 Byte dell'indirizzo di prove­
nienza
EE SRC
# 4 Byte di lunghezza aggiuntivo 03 LEN
# 5 WriteDataByIdentifier Posi­
tive Response Service Id
6E WDBIPR
dal # 6 al
# 7
recordDataIdentifier = [stesso
valore dei byte # 6 e # 7, Ta­
bella 29]
xxxx RDI_…
# 8 Totale di controllo 00-FF CS
Tabella 31
Messaggio di WriteDataByIdentifier Negative Response
Byte # Denominazione del parametro
Valore
esadeci­
male
Mnemonico
# 1 Byte di formato — indirizzamento
fisico
80 FMT
# 2 Byte dell'indirizzo di destinazione tt TGT
# 3 Byte dell'indirizzo di provenienza EE SRC
# 4 Byte di lunghezza aggiuntivo 03 LEN
# 5 NegativeResponse Service Id 7F NR
# 6 WriteDataByIdentifier Request Ser­
vice Id
2E WDBI
# 7 Response­
Code=
[requestOutO­
fRange
31 RC_ROOR
incorrectMessage­
Length
13 RC_IML
conditionsNotCor­
rect]
22 RC_CNC
# 8 Totale di controllo 00-FF CS
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 379
6.2.3 Definizione dei parametri
Il parametro recordDataIdentifier (RDI_) è definito nella Tabella 28.
Il parametro dataRecord (DREC_) è utilizzato nell'ambito del messag­
gio WriteDataByIdentifier Request per fornire al server (VU) il record
dei dati identificato dal parametro recordDataIdentifier. Il formato dei
dati è indicato nella sezione 8.
7. CONTROLLO DEGLI IMPULSI DI PROVA — UNITÀ FUNZIO­
NALE DI CONTROLLO DEI SEGNALI DI ENTRATA/USCITA
I servizi disponibili sono descritti nella seguente tabella:
Tabella 32
Unità funzionale di controllo dei segnali di entrata/uscita
Nome del servizio Descrizione
InputOutputControl­
ByIdentifier
Il client richiede il controllo di uno specifico
segnale di entrata/uscita al/dal server.
7.1. Servizio di InputOutputControlByIdentifier
7.1.1 Descrizione del messaggio
Attraverso il connettore anteriore deve essere possibile effettuare un
collegamento che consenta il controllo degli impulsi di prova o la
loro verifica costante mediante tester adatto.
CPR_058 È possibile configurare tale linea dei segnali I/O di taratura
mediante comando della linea K, utilizzando il servizio In­
putOutputControlByIdentifier per selezionare la funzione di
entrata o di uscita richiesta per la linea in questione. La
linea può assumere i diversi stati indicati di seguito:
— disabled (disabilitata),
— speedSignalInput, in cui la linea dei segnali I/O di tara­
tura è utilizzata per inviare un segnale di velocità (se­
gnale di prova — test signal) al posto del segnale di
velocità inviato dal sensore di movimento; questa fun­
zione non è disponibile in modalità CONTROL,
— realTimeSpeedSignalOutputSensor, in cui la linea dei
segnali I/O di taratura è utilizzata per inviare il segnale
di velocità del sensore di movimento,
— RTCOutput, in cui la linea dei segnali I/O di taratura è
utilizzata per inviare il segnale dell'orologio UTC; que­
sta funzione non è disponibile in modalità CONTROL.
CPR_059 L'operazione di configurazione dello stato della linea ri­
chiede che l'unità elettronica di bordo abbia iniziato una
sessione di regolazione e che sia in modalità CALIBRA­
TION o CONTROL. Se la VU è in modalità CALIBRA­
TION, si possono selezionare i quattro stati della linea (di­
sabled, speedSignalInput, realTimeSpeedSignalOutputSen­
sor, RTCOutput). Se la VU è in modalità CONTROL, si
possono selezionare solo due stati della linea (disabled, re­
alTimeSpeedSignalOutputSensor). Al termine della sessione
di regolazione o della modalità CALIBRATION o CON­
TROL, l'unità elettronica di bordo deve verificare che lo
stato della linea dei segnali I/O di taratura sia nuovamente
«disabled» (disabilitata) (impostazione predefinita).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 380
CPR_060 Se sulla linea del segnale della velocità in tempo reale in
entrata alla VU vengono ricevuti degli impulsi di velocità
mentre la linea dei segnali I/O di taratura è impostata come
entrata, è necessario impostare la linea dei segnali I/O di
taratura come uscita o riportarla alla condizione di «disa­
bled» (disabilitata).
CPR_061 La sequenza deve essere la seguente:
— stabilire la comunicazione mediante il servizio Star­
tCommunication,
— iniziare una sessione di regolazione mediante il servizio
StartDiagnosticSession e adottare la modalità di funzio­
namento CALIBRATION o CONTROL (l'ordine di que­
ste due operazioni non è rilevante),
— modificare lo stato del segnale di uscita mediante l'ope­
razione InputOutputControlByIdentifier Service.
7.1.2 Formato del messaggio
CPR_062 I formati dei messaggi per le primitive di InputOutputCon­
trolByIdentifier sono descritti nelle seguenti tabelle.
Tabella 33
Messaggio di InputOutputControlByIdentifier Request
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
EE TGT
# 3 Byte dell'indirizzo di prove­
nienza
tt SRC
# 4 Byte di lunghezza aggiuntivo xx LEN
# 5 InputOutputControlByIden­
tifier Request Sid
2F IOCBI
# 6 e # 7 InputOutputIdentifier = [Cali­
brationInputOutput]
F960 IOI_CIO
# 8 o
dal # 8 al
# 9
ControlOptionRecord = [ COR_…
inputOutputControlParameter
— uno dei valori da Tabella 36
xx IOCP_…
controlState — uno dei valori
da Tabella 37 (cfr. nota)]
xx CS_…
# 9 oppure
# 10
Totale di controllo 00-FF CS
Nota: Il parametro controlState è presente soltanto in alcuni
casi (cfr. punto 7.1.3).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 381
Tabella 34
Messaggio di InputOutputControlByIdentifier Positive Response
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
tt TGT
# 3 Byte dell'indirizzo di prove­
nienza
EE SRC
# 4 Byte di lunghezza aggiuntivo xx LEN
# 5 inputOutputControlByIdenti­
fier Positive Response SId
6F IOCBIPR
# 6 e # 7 inputOutputIdentifier = [Cali­
brationInputOutput]
F960 IOI_CIO
# 8 o
dal # 8 al
# 9
controlStatusRecord = [ CSR_
inputOutputControlParameter
(stesso valore del byte # 8 Ta­
bella 33)
xx IOCP_…
controlState (stesso valore del
byte # 9 Tabella 33)] (se del
caso)
xx CS_…
# 9 oppure
# 10
Totale di controllo 00-FF CS
Tabella 35
Messaggio di InputOutputControlByIdentifier Negative Response
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 1 Byte di formato — indirizza­
mento fisico
80 FMT
# 2 Byte dell'indirizzo di destina­
zione
tt TGT
# 3 Byte dell'indirizzo di prove­
nienza
EE SRC
# 4 Byte di lunghezza aggiuntivo 03 LEN
# 5 negativeResponse Service Id 7F NR
# 6 inputOutputControlByIdentifier
Request SId
2F IOCBI
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 382
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
# 7 responseCode=[
incorrectMessageLength 13 RC_IML
conditionsNotCorrect 22 RC_CNC
requestOutOfRange 31 RC_ROOR
deviceControlLimitsExceeded] 7A RC_DCLE
# 8 Totale di controllo 00-FF CS
7.1.3 Definizione dei parametri
CPR_064 Il parametro inputOutputControlParameter (IOCP_) è de­
finito nella seguente tabella.
Tabella 36
Definizione dei valori inputOutputControlParameter
Valore esa­
decimale
Descrizione Mnemonico
00 ReturnControlToECU
Questo valore indica al server (VU) che il tester
non ha più il controllo della linea dei segnali I/O
di taratura.
RCTECU
01 ResetToDefault
Questo valore indica al server (VU) che si
richiede di riportare alla propria impostazione
predefinita («reset») la linea dei segnali I/O di
taratura.
RTD
03 ShortTermAdjustment
Questo valore indica al server (VU) che si
richiede di adeguare la linea dei segnali I/O di
taratura al valore indicato nel parametro con-
trolState.
STA
CPR_065 Il parametro controlState è presente soltanto quando il pa­
rametro inputOutputControlParameter è impostato su Shor­
tTermAdjustment ed è definito nella seguente tabella:
Tabella 37
Definizione dei valori controlState
Modalità
Valore esadeci­
male
Descrizione
Disable 00 La linea I/O è disabilitata (impostazione pre­
definita)
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 383
Modalità
Valore esadeci­
male
Descrizione
Enable 01 La linea I/O di taratura è abilitata come spe­
edSignalInput
Enable 02 La linea I/O di taratura è abilitata come re­
alTimeSpeedSignalOutputSensor
Enable 03 La linea I/O di taratura è abilitata come
RTCOutput
▼M3
8. SERVIZIO ROUTINECONTROL (REGOLAZIONE DELL’ORA)
8.1. Descrizione del messaggio
CPR_065a Il servizio RoutineControl (TimeAdjustment) garantisce la
capacità di attivare un allineamento dell’orologio della VU
all’ora fornita dal ricevitore GNSS.
Ai fini dell’esecuzione del servizio RoutineControl (Time­
Adjustment) la VU deve essere in modo TARATURA.
Precondizione: è garantito che la VU sia in grado di ri­
cevere messaggi di posizione autenticata provenienti dal
ricevitore GNSS.
Finché è in corso la regolazione dell’ora, la VU deve
rispondere alla richiesta RoutineControl, sottofunzione re­
questRoutineResults, con routineInfo = 0x78.
Nota: la regolazione dell’ora può richiedere tempo. Il tester
diagnostico deve richiedere lo stato della regolazione
dell’ora utilizzando la sottofunzione requestRoutineResults.
8.2. Formato del messaggio
CPR_065b I formati dei messaggi per il servizio RoutineControl (Ti­
meAdjustment) e le relative primitive sono descritti in det­
taglio nelle tabelle seguenti.
Tabella 37a
RoutineControl, messaggio di richiesta routine (TimeAdjustment), sottofunzione startRoutine
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
#1 Byte di formato - indirizzamento fisico 80 FMT
#2 Byte dell’indirizzo di destinazione EE TGT
#3 Byte dell’indirizzo di provenienza tt SRC
#4 Byte di lunghezza aggiuntivo xx LEN
#5 RoutineControl Request Sid (SID della richiesta RoutineControl) 31 RC
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 e #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 Totale di controllo 00-FF CS
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 384
Tabella 37b
RoutineControl, routine (TimeAdjustment), sottofunzione startRoutine, messaggio di risposta positiva
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
#1 Byte di formato – indirizzamento fisico 80 FMT
#2 Byte dell’indirizzo di destinazione tt TGT
#3 Byte dell’indirizzo di provenienza EE SRC
#4 Byte di lunghezza aggiuntivo xx LEN
#5 RoutineControl Positive Response Sid (Sid della risposta positiva
RoutineControl)
71 RCPR
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 e #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 Totale di controllo 00-FF CS
Tabella 37c
RoutineControl, messaggio di richiesta routine (TimeAdjustment), sottofunzione requestRoutineResults
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
#1 Byte di formato - indirizzamento fisico 80 FMT
#2 Byte dell’indirizzo di destinazione EE TGT
#3 Byte dell’indirizzo di provenienza tt SRC
#4 Byte di lunghezza aggiuntivo xx LEN
#5 RoutineControl Request Sid (SID della richiesta RoutineControl) 31 RC
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 e #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 Totale di controllo 00-FF CS
Tabella 37d
RoutineControl, routine (TimeAdjustment), sottofunzione requestRoutineResults, messaggio di risposta positiva
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
#1 Byte di formato – indirizzamento fisico 80 FMT
#2 Byte dell’indirizzo di destinazione tt TGT
#3 Byte dell’indirizzo di provenienza EE SRC
#4 Byte di lunghezza aggiuntivo xx LEN
#5 RoutineControl Positive Response Sid (Sid della risposta positiva
RoutineControl)
71 RCPR
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 e #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 routineInfo (cfr. tabella 37f) XX RINF_TA
#10 routineStatusRecord[] = routineStatus#1 (cfr. tabella 37g) XX RS_TA
#11 Totale di controllo 00-FF CS
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 385
Tabella 37e
RoutineControl, messaggio di risposta negativa routine (TimeAdjustment)
Byte # Denominazione del parametro
Valore esadeci­
male
Mnemonico
#1 Byte di formato – indirizzamento fisico 80 FMT
#2 Byte dell’indirizzo di destinazione tt TGT
#3 Byte dell’indirizzo di provenienza EE SRC
#4 Byte di lunghezza aggiuntivo 03 LEN
#5 negativeResponse Service Id (identificativo servizio negativeRe­
sponse)
7F NR
#6 inputOutputControlByIdentifier Request SId 31 RC
#7 responseCode=[
sub-functionNotSupported
incorrectMessageLengthOrInvalidFormat
conditionsNotCorrect
requestOutOfRange
]
12
13
22
31
SFNS
IMLOIF
CNC
ROOR
#8 Totale di controllo 00-FF CS
Tabella 37f
RoutineControl, routine (TimeAdjustment), routineInfo
routineInfo
Valore esadeci­
male
Descrizione
NormalExitWithResultAvailable 61 La routine è stata eseguita integralmente; sono disponi­
bili risultati di routine aggiuntivi.
RoutineExecutionOngoing 78 La routine richiesta è ancora in esecuzione.
Tabella 37g
RoutineControl, routine (TimeAdjustment), routineStatus
Valore esadecimale Risultato della prova Descrizione
01 positivo La regolazione dell’ora è stata completata con esito positivo.
02..0F RFU
10 negativo Nessuna ricezione del segnale GNSS.
11..7F RFU
80..FF Specifico per ciascun fabbricante
9. FORMATI DEL PARAMETRO DATARECORDS
La presente sezione contiene informazioni dettagliate in merito:
— alle regole generali da applicare alle serie di parametri trasmessi
dalla VU al tester,
— ai formati da impiegare per i dati trasferiti tramite i servizi di
trasmissione dati di cui alla sezione 6.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 386
CPR_067 Tutti i parametri individuati devono essere supportati dalla VU.
CPR_068 I dati trasmessi dalla VU al tester in risposta ad un mes­
saggio di richiesta devono essere di tipo misurato (ossia il
valore corrente del parametro richiesto, come misurato o
osservato dalla VU).
9.1. Valori limite dei parametri trasmessi
CPR_069 La tabella 38 definisce i valori limite impiegati per deter­
minare la validità dei parametri trasmessi.
CPR_070 I valori della serie «indicatore di errore» permettono alla VU di
indicare immediatamente che non sono al momento disponibili
dati parametrici validi a causa di errori intervenuti nel tachigrafo.
CPR_071 I valori della serie «non disponibile» permettono alla VU di
trasmettere un messaggio che contiene un parametro non
disponibile o non supportato dal modulo in questione. I
valori della serie «non richiesto» permettono di trasmettere
un messaggio di comando e di identificare i parametri per i
quali non ci si attende alcuna risposta dal dispositivo che lo
riceve.
CPR_072 Se il malfunzionamento di un componente non permette la
trasmissione di dati validi per un parametro, al loro posto
dovrebbe essere trasmesso l’indicatore di errore di cui nella
tabella 38. Se tuttavia il dato misurato o calcolato risulta
valido, ma supera i valori limite stabiliti per tale parametro,
non dovrebbe essere impiegato alcun indicatore di errore. I
dati dovrebbero essere trasmessi utilizzando il valore para­
metrico massimo o minimo opportuno.
Tabella 38
Serie di dataRecords
Nome della serie
1 byte
(Valore esade­
cimale)
2 byte
(Valore esadecimale)
4 byte
(Valore esadecimale)
ASCII
Segnale valido Da 00 a FA Da 0000 a FAFF Da 00000000 a FAFFFFFF Da 1 a 254
Indicatore specifico del parametro FB Da FB00 a FBFF Da FB000000 a FBFFFFFF Nessuno
Serie riservata per futuri bit indicatori Da FC a FD Da FC00 a FDFF Da FC000000 a FDFFFFFF Nessuno
Indicatore di errore FE Da FE00 a FEFF Da FE000000 a FEFFFFFF 0
Non disponibile o non richiesto FF Da FF00 a FFFF Da FF000000 a FFFFFFFF FF
CPR_073 Se i parametri sono codificati in ASCII, il carattere ASCII
«*» è riservato quale delimitatore.
9.2. Formati del parametro dataRecords
Le seguenti tabelle, dalla 39 alla 42, indicano in dettaglio i formati da
impiegare utilizzando i servizi ReadDataByIdentifier e WriteDataByI­
dentifier.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 387
CPR_074 La tabella 39 indica lunghezza, risoluzione e limiti operativi per
ogni parametro identificato dal relativo recordDataIdentifier:
Tabella 39
Formati dei dataRecords
Denominazione del parametro
Lunghezza
dati (in
byte)
Risoluzione Limiti operativi
TimeDate 8 Cfr. informazioni dettagliate nella tabella 40
HighResolutionTotalVehicleDi­
stance
4 gain 5 m/bit, offset 0 m Da 0 a +21 055 406 km
Kfactor 2 gain 0,001 impulsi/m/bit,
offset 0
Da 0 a 64,255 impulsi/m
LfactorTyreCircumference 2 gain 0,125 10 -3 m/bit, offset 0 Da 0 a 8,031 m
WvehicleCharacteristicFactor 2 gain 0,001 impulsi/m/bit,
offset 0
Da 0 a 64,255 impulsi/m
TyreSize 15 ASCII ASCII
NextCalibrationDate 3 Cfr. informazioni dettagliate nella tabella 41
SpeedAuthorised 2 gain 1/256 km/h/bit, offset 0 Da 0 a 250,996 km/h
RegisteringMemberState 3 ASCII ASCII
VehicleRegistrationNumber 14 Cfr. informazioni dettagliate nella tabella 42
VIN 17 ASCII ASCII
SealDataVu 55 Cfr. informazioni dettagliate nella tabella 43
ByDefaultLoadType 1 Cfr. informazioni dettagliate nella tabella 44
VuSerialNumber 8 Cfr. informazioni dettagliate nella tabella 45
SensorSerialNumber 8 Cfr. informazioni dettagliate nella tabella 45
SensorGNSSSerialNumber 8 Cfr. informazioni dettagliate nella tabella 45
RemoteCommunicationModuleSe­
rialNumber
8 Cfr. informazioni dettagliate nella tabella 45
TachographCardsGen1Suppression 2 Cfr. informazioni dettagliate nella tabella 46
VehiclePosition 14 Cfr. informazioni dettagliate nella tabella 47
CalibrationCountry 3 ASCII NationAlpha come definito
nell’appendice 1
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 388
CPR_075 La tabella 40 indica in dettaglio i formati dei diversi byte
impiegati dal parametro TimeDate:
Tabella 40
Formato dettagliato del parametro TimeDate (valore recordDataIdentifier # F90B)
Byte Definizione dei parametri Risoluzione Limiti operativi
1 Secondi gain 0,25 s/bit, offset 0 s Da 0 a 59,75s
2 Minuti gain 1 min/bit, offset 0 min Da 0 a 59 min
3 Ore gain 1 h/bit, offset 0 h Da 0 a 23 ore
4 Mese gain 1 mese/bit, offset 0 mesi Da 1 a 12 mesi
5 Giorno gain 0,25 giorni/bit, offset 0 giorni (cfr.
la nota alla Tabella 41)
Da 0,25 a 31,75 giorni
6 Anno gain 1 anno/bit, offset +1985 anni
(cfr. la nota seguente Tabella 41)
Dall’anno 1985 al 2235
7 Offset minuto locale gain 1 min/bit, offset -125 min Da -59 a +59 min
8 Offset ora locale gain 1 h/bit, offset -125 h Da -23 a +23 ore
CPR_076 La tabella 41 indica in dettaglio i formati dei diversi tipi di
byte impiegati dal parametro NextCalibrationDate:
Tabella 41
Formato dettagliato del parametro NextCalibrationDate (valore recordDataIdentifier # F922)
Byte Definizione dei parametri Risoluzione Limiti operativi
1 Mese gain 1 mese/bit, offset 0 mesi Da 1 a 12 mesi
2 Giorno gain 0,25 giorni/bit, offset 0 giorni (cfr.
la nota seguente)
Da 0,25 a 31,75 giorni
3 Anno gain 1 anno/bit, offset +1985 anni
(cfr. la nota seguente)
Dall’anno 1985 al 2235
Nota relativa all’impiego del parametro «Giorno»:
1) nella data, il valore 0 è nullo. I valori 1, 2, 3 e 4 sono
utilizzati per identificare il primo giorno del mese, 5, 6,
7 e 8 per identificare il secondo ecc.;
2) tale parametro non influenza né modifica il parametro
relativo all’ora.
Nota relativa all’impiego del parametro «Anno»:
il valore 0 corrisponde all’anno 1985, il valore 1 corri­
sponde al 1986 ecc.;
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 389
CPR_078 La tabella 42 indica in dettaglio i formati dei diversi byte
impiegati dal parametro VehicleRegistrationNumber:
Tabella 42
Formato dettagliato del parametro VehicleRegistrationNumber (valore recordDataIdentifier # F97E)
Byte Definizione dei parametri Risoluzione Limiti operativi
1 Pagina di codice (definito nell’appendice 1) Non applicabile VehicleRegistrationNumber
2 – 14 Numero di immatricolazione del veicolo (de­
finito nell’appendice 1)
Non applicabile VehicleRegistrationNumber
CPR_090 La tabella 43 indica in dettaglio i formati dei diversi byte
impiegati dal parametro SealDataVu:
Tabella 43
Formato dettagliato del parametro SealDataVu (valore recordDataIdentifier # F9D3)
Byte Definizione dei parametri Risoluzione Limiti operativi
1 – 11 sealRecord1. Formato SealRecord definito
nell’appendice 1.
Non applicabile SealRecord
12 - 22 sealRecord2. Formato SealRecord definito
nell’appendice 1.
Non applicabile SealRecord
23 – 33 sealRecord3. Formato SealRecord definito
nell’appendice 1.
Non applicabile SealRecord
34 – 44 sealRecord4. Formato SealRecord definito
nell’appendice 1.
Non applicabile SealRecord
45 – 55 sealRecord5. Formato SealRecord definito
nell’appendice 1.
Non applicabile SealRecord
NOTA: se sono disponibili meno di 5 sigilli, il valore
EquipmentType in tutti i sealRecords inutilizzati deve es­
sere impostato su 15, ossia «inutilizzato».
CPR_091 La tabella 44 indica in dettaglio i formati dei diversi byte
impiegati dal parametro ByDefaultLoadType:
Tabella 44
Formato dettagliato del parametro ByDefaultLoadType (valore recordDataIdentifier # F9D5)
Byte Definizione dei parametri Risoluzione Limiti operativi
1 loadType
«00»H: tipo di carico non definito
«01»H: merci
«02»H: passeggeri
Non applicabile Da «00»H a «02»H
CPR_092 La tabella 45 indica in dettaglio i formati dei diversi byte
impiegati dai parametri VuSerialNumber, SensorSerialNum­
ber, SensorGNSSSerialNumber e RemoteCommunication­
ModuleSerialNumber:
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 390
Tabella 45
Formato dettagliato dei parametri VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber e
RemoteCommunicationModuleSerialNumber (valori recordDataIdentifier # F9D4, F9D0, F9D2, F9D1)
Byte Definizione dei parametri Risoluzione Limiti operativi
1 VuSerialNumber, SensorSerialNumber, Sen­
sorGNSSSerialNumber e RemoteCommuni­
cationModuleSerialNumber:
formato ExtendedSerialNumber definito
nell’appendice 1.
Non applicabile ExtendedSerialNumber
CPR_093 La tabella 46 indica in dettaglio i formati dei diversi byte
impiegati dal parametro TachographCardsGen1Suppression:
Tabella 46
Formato dettagliato del parametro TachographCardsGen1Suppression (valore recordDataIdentifier # F9D6)
Byte Definizione dei parametri Risoluzione Limiti operativi
1-2 TachographCardsGen1Suppression. Formato
TachographCardsGen1Suppression definito
nell’appendice 1.
Non applicabile «0000»H, «A5E3»H
CPR_094 La tabella 47 indica in dettaglio i formati dei diversi byte
impiegati dal parametro VehiclePosition:
Tabella 47
Formato dettagliato del parametro VehiclePosition (valore recordDataIdentifier # F9D7)
Byte Definizione dei parametri Risoluzione Limiti operativi
1 - 4 Marcatura oraria della posizione del veicolo
determinata
Non applicabile TimeReal
5 Accuratezza del GNSS Non applicabile GNSSAccuracy
6 - 11 Posizione del veicolo Non applicabile GeoCoordinates
12 Stato di autenticazione Non applicabile PositionAuthenticationStatus
13 Paese in cui si trova il veicolo Non applicabile NationNumeric
14 Regione in cui si trova il veicolo Non applicabile RegionNumeric
Nota: dopo l’aggiornamento della posizione del veicolo, è
possibile ritardare l’aggiornamento del paese e della regione
in cui si trova il veicolo.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 391
Appendice 9.
OMOLOGAZIONE ELENCO DELLE PROVE MINIME PRESCRITTE
INDICE
1. INTRODUZIONE
2. PROVE FUNZIONALI PER L'UNITÀ ELETTRONICA DI BORDO
3. PROVE FUNZIONALI PER IL SENSORE DI MOVIMENTO
4. PROVE FUNZIONALI PER LE CARTE TACHIGRAFICHE
5. PROVE DEL DISPOSITIVO GNSS ESTERNO
▼M1
6. PROVE DEL DISPOSITIVO ESTERNO DI COMUNICAZIONE RE­
MOTA
▼B
7. PROVE FUNZIONALI SU CARTA
8. PROVE DI INTEROPERABILITÀ
▼M3
9. PROVE OSNMA
▼B
1. INTRODUZIONE
1.1. Omologazione
L'omologazione CE di un apparecchio di controllo (o suo componente) o
di una carta tachigrafica si basa su:
▼M1
— una certificazione di sicurezza, basata sulle specifiche dei criteri co­
muni rispetto ad un obiettivo di sicurezza pienamente conforme all’ap­
pendice 10 del presente allegato,
▼B
— una certificazione funzionale, effettuata dalle autorità competenti de­
gli Stati membri, che attesta la conformità dell'elemento sottoposto alle
prove ai requisiti del presente allegato in termini di funzioni eseguite,
precisione delle misurazioni e caratteristiche ambientali,
— una certificazione di interoperabilità, effettuata dall'organismo com­
petente, che attesta la piena interoperabilità dell'apparecchio di con­
trollo (o carta tachigrafica) con i modelli di carta tachigrafica (o ap­
parecchio di controllo) necessari (cfr. capitolo 8 del presente allegato).
La presente appendice specifica le prove minime che le autorità compe­
tenti degli Stati membri devono eseguire nell'ambito delle prove funzio­
nali, nonché le prove minime che l'organismo competente deve eseguire
nell'ambito delle prove di interoperabilità. Le procedure da seguire per
l'esecuzione delle prove e il tipo di prove non sono ulteriormente
specificati.
Gli aspetti concernenti la certificazione della sicurezza non sono contem­
plati dalla presente appendice. Se alcune prove richieste per l'omologa­
zione vengono effettuate nell'ambito delle procedure di valutazione e cer­
tificazione della sicurezza, non è necessario che tali prove vengano ripe­
tute. In quest'ultimo caso, solo i risultati delle prove della sicurezza pos­
sono essere oggetto di controlli. A titolo d'informazione, nella presente
appendice i requisiti che devono essere sottoposti a prova (o che sono
strettamente collegati alle prove previste) nell'ambito della certificazione
della sicurezza sono segnalati con un asterisco «*».
I requisiti numerati si riferiscono all'allegato, mentre quelli non numerati si
riferiscono alle altre appendici (ad es. PIC_001 si riferisce al requisito
PIC_001 dell'appendice 3 Pittogrammi).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 392
La presente appendice esamina separatamente l'omologazione del sensore
di movimento, dell'unità elettronica di bordo e del dispositivo GNSS
esterno come componenti dell'apparecchio di controllo. Ogni componente
riceve il proprio certificato di omologazione in cui vengono indicati gli
altri componenti compatibili. La prova funzionale del sensore di movi­
mento (o del dispositivo GNSS esterno) è eseguita insieme all'unità elet­
tronica di bordo e viceversa.
Non è prescritta l'interoperabilità tra ogni modello di sensore di movi­
mento (o dispositivo GNSS esterno) e ogni modello di unità elettronica
di bordo. Quindi l'omologazione di un sensore di movimento (o disposi­
tivo GNSS esterno) può essere accordata solo se abbinata all'omologazione
di una unità elettronica di bordo e viceversa.
▼M3
L’autorità degli Stati membri incaricata delle prove funzionali di un’unità
elettronica di bordo o di un dispositivo GNSS esterno deve accertarsi che
il ricevitore GNSS incorporato abbia superato con esito positivo le prove
OSNMA specificate nella presente appendice. Tali prove sono considerate
parte integrante delle prove funzionali dell’unità elettronica di bordo o del
dispositivo GNSS esterno.
▼B
1.2. Riferimenti
Nella presente appendice si rimanda alle norme seguenti.
IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A: Cold
(Prove ambientali — Parte 2-1: Prove — Prova A: Freddo)
IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests
B: dry heat (sinusoidal) [Procedure di prove ambientali di base; Prove;
Prove B: Calore secco (sinusoidale)].
IEC 60068-2-6: Environmental testing — Part 2: Tests — Test Fc: Vi­
bration (Prove ambientali — Parte 2: Prove — Prova Fc: Vibrazioni)
IEC 60068-2-14: Environmental testing; Part 2-14: Tests; Test N: Change
of temperature (Prove ambientali; Parti 2-14: Prove; Prova N: Cambia­
mento di temperatura)
IEC 60068-2-27: Environmental testing. Part 2: Tests. Test Ea and gui­
dance: Shock (Prove ambientali. Parte 2: Prove. Prova Ea e guida: Urti)
IEC 60068-2-30: Environmental testing — Part 2-30: Tests — Test Db:
Damp heat, cyclic (12 h + 12 h cycle) [Prove ambientali — Parti 2-30:
Prove — Prova Db: Calore umido, ciclico (ciclo di 12 h + 12 h)]
IEC 60068-2-64: Environmental testing — Part 2-64: Tests — Test Fh:
Vibration, broadband random and guidance (Prove ambientali — Parti 2-
64: Prove — Prova Fh: Vibrazioni, a banda larga casuali, e guida)
IEC 60068-2-78 Environmental testing — Part 2-78: Tests — Test Cab:
Damp heat, steady state (Prove ambientali — Parti 2-78: Prove — Prova
Cab: Calore umido, statico)
ISO 16750-3 — Mechanical loads (2012-12) (Carichi meccanici)
ISO 16750-4 — Climatic loads (2010-04) (Carichi climatici)
ISO 20653: Road vehicles — Degree of protection (IP code) — Protection
of electrical equipment against foreign objects, water and access [Veicoli
stradali — Grado di protezione (codice IP) — Protezione delle apparec­
chiature da oggetti estranei, dall'acqua e dall'accesso]
ISO 10605:2008 + Technical Corrigendum (rettifica tecnica): 2010 +
AMD1:2014 Road vehicles — Test methods for electrical disturbances
from electrostatic discharge (Veicoli stradali — Metodi di prova dei di­
sturbi elettrici da scariche elettrostatiche)
ISO 7637-1:2002 + AMD1: 2008 Road vehicles — Electrical disturbances
from conduction and coupling — Part 1: Definitions and general consi­
derations (Veicoli stradali — Disturbi elettrici da conduzione e accoppia­
mento — Parte 1: Definizioni e considerazioni generali).
ISO 7637-2 Road vehicles — Electrical disturbances from conduction and
coupling — Part 2: Definitions and general considerations (Veicoli stradali
— Disturbi elettrici da conduzione e accoppiamento — Parte 2: Defini­
zioni e considerazioni generali).
ISO 7637-3 Road vehicles — Electrical disturbances from conduction and
coupling — Part 3: Electrical transient transmission by capacitive and
inductive coupling via lines other than supply lines (Veicoli stradali —
Disturbi elettrici da conduzione e accoppiamento — Parte 3: Trasmissione
di transitori elettrici mediante accoppiamento capacitivo e induttivo attra­
verso linee diverse da quelle di alimentazione).
ISO/IEC 7816-1 Identification cards — Integrated circuit(s) cards with
contacts — Part 1: Physical characteristics. (Carte di identificazione —
Carte a circuito integrato con contatti — Parte 1: Caratteristiche fisiche).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 393
ISO/IEC 7816-2 Information technology — Identification cards — Inte­
grated circuit(s) cards with contacts — Part 2: Dimensions and location of
the contacts (Tecnologia dell'informazione — Carte di identificazione —
Carte a circuito integrato con contatti — Parte 2: Dimensioni e posizione
dei contatti).
ISO/IEC 7816-3 Information technology — Identification cards — Inte­
grated circuit(s) cards with contacts — Part 3: Electronic signals and
transmission protocol (Tecnologia dell'informazione — Carte di identifi­
cazione — Carte a circuito integrato con contatti — Parte 3: Segnali
elettronici e protocollo di trasmissione).
ISO/IEC 10373-1:2006 + AMD1:2012 Identification cards — Test me­
thods — Part 1: General characteristics (Carte di identificazione — Metodi
di prova — Parte 1: Caratteristiche generali)
ISO/IEC 10373-3:2010 + Technical Corrigendum (rettifica tecnica):2013
Identification cards — Test methods — Part 3: Integrated circuit cards
with contacts and related interface devices (Carte di identificazione —
Metodi di prova — Parte 3: Carte a circuito integrato con contatti e
relative interfacce)
ISO 16844-3:2004, Cor 1:2006 Road vehicles — Tachograph systems —
Part 3: Motion sensor interface (with vehicle units) [Veicoli stradali —
Sistemi tachigrafici — Parte 3: Interfaccia del sensore di movimento (con
le unità elettroniche di bordo)].
ISO 16844-4 Road vehicles — Tachograph systems — Part 4: CAN
interface (Veicoli stradali — Sistemi tachigrafici — Parte 4: Interfaccia
CAN)
ISO 16844-6 Road vehicles — Tachograph systems — Part 6: Diagnostics
(Veicoli stradali — Sistemi tachigrafici — Parte 6: Diagnostica)
ISO 16844-7 Road vehicles — Tachograph systems — Part 7: Parameters
(Veicoli stradali — Sistemi tachigrafici — Parte 7: Parametri)
ISO 534 Paper and board – Determination of thickness, density and spe­
cific volume (Carta e cartone – Determinazione dello spessore, della den­
sità e del volume specifico)
▼M3
RGODP Relazione tecnica del JRC - Receiver guidelines for OSNMA
data processing (Orientamenti per i ricevitori relativi all’elaborazione dei
dati OSNMA)
▼B
UN ECE R10 Uniform provisions concerning the approval of vehicles
with regard to electromagnetic compatibility (United Nation Economic
Commission for Europe) [Disposizioni uniformi relative all'omologazione
di veicoli relativamente alla loro compatibilità elettromagnetica (commis­
sione economica per l'Europa delle Nazioni Unite)]
2. PROVE FUNZIONALI PER L'UNITÀ ELETTRONICA DI BORDO
▼M1
N. Prova Descrizione Requisiti applicabili
1 Esame amministrativo
1.1 Documentazione Correttezza della documentazione
1.2 Risultati delle prove
del fabbricante
Risultati delle prove effettuate dal fabbricante
durante l’integrazione
Attestati cartacei
88, 89.91
2 Esame visivo
2.1 Conformità alla documentazione
2.2 Identificazione/marcature da 224 a 226
2.3 Materiali da 219 a 223
2.4 Sigillatura 398, da 401 a 405
2.5 Interfacce esterne
3 Prove funzionali
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 394
N. Prova Descrizione Requisiti applicabili
▼M3
3.1 Funzioni 02, 03, 04, 05, 07, 382,
3.2 Modi di funzionamento da 09 a 11*, 134, 135
3.3 Funzioni e diritti di accesso ai dati 12* 13*, 382, 383, da 386
a 389
3.4 Controllo inserimento ed estrazione carte 15, 16, 17, 18, 19*, 20*, 134
3.5 Misurazione della velocità, della posizione e della distanza Da 21 a 37
3.6 Misurazione del tempo (prova effettuata a 20 °C) Da 38 a 43
3.7 Controllo delle attività del conducente Da 44 a 53, 134
3.8 Controllo delle condizioni di guida 54, 55, 134
3.9 Immissioni da parte del conducente Da 56 a 62 quater
3.10 Gestione dei blocchi di un’impresa Da 63 a 68
3.11 Verifica delle attività di controllo 69, 70
3.12 Rilevamento di anomalie e/o guasti Da 71 a 88 bis, 134
3.13 Dati di identificazione dell’apparecchio 93*, 94*, 97, 100
3.14 Dati relativi all’inserimento e all’estrazione della carta del conducente o
dell’officina
Da 102* a 104*
3.15 Dati relativi all’attività del conducente Da 105* a 107*
3.16 Dati sui luoghi e sulle posizioni Da 108* a 112*
3.17 Dati relativi all’odometro Da 113* a 115*
3.18 Dati dettagliati relativi alla velocità 116*
3.19 Dati relativi alle anomalie 117*
3.20 Dati relativi ai guasti 118*
3.21 Dati relativi alla taratura Da 119* a 121*
3.22 Dati relativi alla regolazione dell’ora 124*, 125*
3.23 Dati relativi alle attività di controllo 126*, 127*
3.24 Dati relativi ai blocchi di un’impresa 128*
3.25 Dati relativi al trasferimento 129*
3.26 Dati relativi a condizioni particolari 130*, 131*
3.27 Dati della carta tachigrafica 132*, 133*
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 395
N. Prova Descrizione Requisiti applicabili
3.28 Attraversamenti di frontiera Da 133 bis* a 133 quinquies*
3.29 Operazione di carico/scarico** Da 133 sexies a 133 decies
3.30 Mappa digitale Da 133 undecies* a 133 unvi­
cies*
3.31 Registrazione e memorizzazione nelle carte tachigrafiche 136, 137, 138*, 139*, 141*,
142, 143
144, 145, 146*, 147*, 147
bis*, 147 ter*, 148*, 149,
150, 150 bis
3.32 Visualizzazione 90, 134,
Da 151 a 168,
PIC_001, DIS_001
3.33 Stampa 90, 134,
da 169 a 181, PIC_001, da
PRT_001 a PRT_014
3.34 Avviso 134, da 182 a 191,
PIC_001
3.35 Trasferimento di dati verso un dispositivo esterno 90, 134, da 192 a 196
3.36 Comunicazione remota per controlli su strada mirati Da 197 a 199
3.37 Scambi di dati con dispositivi esterni aggiuntivi 200, 201
3.38 Taratura Da 202 a 206*, 383, 384, da
386 a 391
3.39 Verifica su strada della taratura Da 207 a 209
3.40 Regolazione dell’ora Da 210 a 212*
3.41 Monitoraggio degli attraversamenti di frontiera Da 226a* a 226c*
3.42 Aggiornamento software Da 226 quinquies a 226 sep­
ties
3.43 Non interferenza di funzioni supplementari 06, 425
3.44 Interfaccia del sensore di movimento 02, 122
3.45 Dispositivo GNSS esterno 03, 123
3.46 Verifica del rilevamento, della registrazione e della memorizzazione da
parte della VU di anomalie e/o guasti definiti dal fabbricante della VU
nei casi in cui un sensore di movimento abbinato reagisce ai campi
magnetici che disturbano il rilevamento dei dati di movimento del
veicolo.
217
3.47 Cypher suite e parametri Domain standardizzati CSM_48, CSM_50
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 396
N. Prova Descrizione Requisiti applicabili
4 Prove ambientali
4.1 Temperatura: Verificare la funzionalità mediante:
prova conformemente alla norma ISO 16750-4,
capitolo 5.1.1.2: Prova di funzionamento a
bassa temperatura (72 h a -20 °C)
Questa prova si riferisce alla norma IEC 60068-
2-1: Prove ambientali - Parti 2-1: Prove - Prova
A: freddo
Prova conformemente a ISO 16750-4: Capitolo
5.1.2.2: Prova di funzionamento ad alta tempe­
ratura (72 h a 70 °C)
Questa prova si riferisce alla norma IEC 60068-
2-2: Procedure di prove ambientali di base;
Parte 2: Prove; Prove B: calore secco
Prova conformemente a ISO 16750-4: Capitolo
5.3.2: Cambiamento rapido di temperatura con
durata specifica della transizione (-20 °C/70
°C, 20 cicli, tempo di permanenza di 2h a
ogni temperatura)
Si può effettuare una serie ridotta di prove (fra
quelle definite alla sezione 3 della presente ta­
bella) alla temperatura più bassa, alla tempera­
tura più alta e durante i cicli di temperature
213
4.2 Umidità Verificare che l’unità elettronica di bordo
possa sopportare un’umidità ciclica (prova
termica) secondo la norma IEC 60068-2-30,
prova Db, sei cicli di 24 ore, ciascuno con
temperature che variano da +25 °C a +55 °C
e un’umidità relativa del 97 % a +25 °C e del
93 % a +55 °C
214
4.3 Prove meccaniche 1. Vibrazioni sinusoidali.
Verificare che l’unità elettronica di bordo
possa sopportare vibrazioni sinusoidali
aventi le seguenti caratteristiche:
spostamento costante tra 5 e 11 Hz: picco
di 10 mm
accelerazione costante tra 11 e 300 Hz: 5g
Questo requisito si verifica in base alla
norma IEC 60068-2-6, prova Fc, con una
durata minima della prova di 3×12 ore (12
ore per asse)
La norma ISO 16750-3 non prescrive una
prova di vibrazione sinusoidale per i di­
spositivi posizionati nella cabina del vei­
colo staccata.
2. Vibrazioni casuali:
Prova conformemente a ISO 16750-3: Ca­
pitolo 4.1.2.8: Prova VIII: Veicolo com­
merciale, cabina del veicolo staccata
219
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 397
N. Prova Descrizione Requisiti applicabili
Prova delle vibrazioni casuali, 10…2000 Hz,
RMS verticale 21,3 m/s 2 , RMS longitudinale
11,8 m/s 2 , RMS laterale 13,1 m/s 2 , 3 assi,
32 h per asse, incluso il ciclo di temperatura
-20…70 °C.
Questa prova si riferisce alla norma IEC
60068-2-64: Prove ambientali - Parti 2-64:
Prove - Prova Fh: vibrazioni, a banda larga
casuali e guida
3. Urti:
urto meccanico con mezzo seno 3g confor­
memente a ISO 16750.
Le prove sopra descritte sono effettuate su
campioni diversi del modello di apparecchio
sottoposto alle prove
4.4 Protezione contro l’ac­
qua e i corpi estranei
Prova conformemente a ISO 20653: Veicoli
stradali – Grado di protezione (codice IP) –
Protezione delle apparecchiature da oggetti
estranei, dall’acqua e dall’accesso (senza mo­
difica dei parametri); Valore minimo IP 40
220, 221
4.5 Protezione contro so­
vratensione
Verificare che l’unità elettronica di bordo
possa sopportare un’alimentazione di:
versioni da 24 V: 34V a + 40 °C 1 ora
versioni da 12 V: 17V a + 40 °C 1 ora
(ISO 16750-2)
216
4.6 Protezione contro pola­
rità inversa
Verificare che l’unità elettronica di bordo
possa sopportare un’inversione dell’alimenta­
zione
(ISO 16750-2)
216
4.7 Protezione contro cor­
tocircuiti
Verificare che i segnali in ingresso e in uscita
siano protetti contro i cortocircuiti rispetto ad
alimentazione e massa
(ISO 16750-2)
216
5 Prove della compatibilità elettromagnetica
5.1 Emissioni irradiate e
sensibilità ai disturbi
Conformità al regolamento ECE R10 218
5.2 Scariche elettrostatiche Conformità alla norma ISO 10605 :2008 +
Rettifica tecnica :2010 +
AMD1 :2014: +/- 4kV per il contatto e +/-
8kV per lo scarico di aria
218
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 398
N. Prova Descrizione Requisiti applicabili
5.3 Sensibilità ai transitori
condotti nell’alimenta­
zione
Per le versioni da 24 V: conformità alla
norma ISO 7637-2 + regolamento ECE n.
10 Rev. 3:
impulso 1a: Vs = -450V Ri = 50 ohm
impulso 2a: Vs = +37V Ri = 2 ohm
impulso 2b: Vs = +20V Ri = 0,05 ohm
impulso 3a: Vs = -150V Ri = 50 ohm
impulso 3b: Vs = +150V Ri = 50 ohm
impulso 4: Vs = -16V Va = -12V t6 = 100ms
impulso 5: Vs = +120V Ri = 2,2 ohm td =
250ms
Per le versioni da 12 V: conformità alla
norma ISO 7637-1 + regolamento ECE n.
10 Rev. 3:
impulso 1: Vs = -75V Ri = 10 ohm
impulso 2a: Vs = +37V Ri = 2 ohm
impulso 2b: Vs = +10V Ri = 0,05 ohm
impulso 3a: Vs = -112V Ri = 50 ohm
impulso 3b: Vs = +75V Ri = 50 ohm
impulso 4: Vs = -6V Va = -5V t6 = 15ms
impulso 5: Vs = +65V Ri = 3ohm td = 100ms
L’impulso 5 va controllato solo per le unità
elettroniche di bordo destinate al montaggio
in veicoli per i quali non è prevista una pro­
tezione comune esterna contro le cadute della
potenza di carico
Per la proposta relativa alle cadute della po­
tenza di carico fare riferimento alla norma
ISO 16750-2, 4a edizione, capitolo 4.6.4.
218
▼B
3. PROVE FUNZIONALI PER IL SENSORE DI MOVIMENTO
N. Prova Descrizione Requisiti applicabili
1. Esame amministrativo
1.1 Documentazione Correttezza della documentazione
2. Esame visivo
2.1. Conformità alla documentazione
2.2. Identificazione/marcature 225, 226,
2.3 Materiali da 219 a 223
2.4. Sigillatura 398, da 401 a 405
3. Prove funzionali
3.1 Dati di identificazione del sensore da 95 a 97*
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 399
N. Prova Descrizione Requisiti applicabili
3.2 Abbinamento sensore di movimento — unità elettronica di bordo 122*, 204
3.3 Rilevamento del movimento
Precisione della misurazione del movimento
da 30 a 35
3.4 Interfaccia dell'unità elettronica di bordo 02
3.5 Verificare che il sensore di movimento sia insensibile ai campi magnetici co­
stanti. In alternativa, verificare che il sensore di movimento reagisca ai campi
magnetici costanti che ostacolano il rilevamento dei dati di movimento del
veicolo in modo che la VU collegata possa individuare, registrare e memoriz­
zare i guasti del sensore
217
4. Prove ambientali
4.1 Temperatura di esercizio Verificare la funzionalità (secondo quanto defi­
nito alla prova n. 3.3) nel campo di temperatura
[- 40 °C; + 135 °C], mediante:
prova Ad, IEC 60068-2-1, per una durata di 96
ore alla temperatura più bassa To min ,
prova Bd, IEC 60068-2-2, per una durata di 96
ore alla temperatura più alta To max
Prova conformemente a ISO 16750-4: Capitolo
5.1.1.2: Prova di funzionamento a bassa tempe­
ratura (24 h @ – 40 °C)
Questa prova si riferisce alla norma IEC 60068-
2-1: Prove ambientali — Parti 2-1: Prove —
Prova A: Freddo, prova Bd, IEC 68-2-2, per
una durata di 96 ore alla temperatura più bassa
di – 40 °C.
Prova conformemente a ISO 16750-4: Capitolo
5.1.2.2: Prova di funzionamento ad alta tempe­
ratura (96 h @135 °C)
Questa prova si riferisce alla norma IEC 60068-
2-2: Procedure di prove ambientali di base;
parte 2: prove; prove B: calore secco
213
4.2 Cicli di temperature Prova conformemente a ISO 16750-4: Capitolo
5.3.2 Cambiamento rapido di temperatura con
durata specifica della transizione (– 40 °C/135
°C, 20 cicli, tempo di permanenza di 30 min a
ogni temperatura)
IEC 60068-2-14: Prove ambientali; Parti 2-14:
Prove; Prova N: Variazione di temperatura
213
4.3 Cicli di umidità Verificare la funzionalità (secondo quanto defi­
nito alla prova n. 3.3), mediante prova Db, IEC
60068-2-30, sei cicli di 24 ore, ciascuno con
temperature che variano da + 25 °C a + 55 °C
e un'umidità relativa del 97 % a + 25 °C e del
93 % a + 55 °C
214
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 400
N. Prova Descrizione Requisiti applicabili
4.4 Vibrazioni ISO 16750-3: Capitolo 4.1.2.6: Prova VI: Vei­
colo commerciale, motore, cambio
Prova delle vibrazioni in modalità mista, tra cui
a) Prova delle vibrazioni sinusoidali, 20...520
Hz, 11,4 …120 m/s 2 ,
b) Prova delle vibrazioni casuali, 10...2 000 Hz,
RMS 177 m/s 2
94 h per asse, incluso il ciclo di temperatura
-20…70 °C
Questa prova si riferisce alla norma IEC 60068-
2-80: Prove ambientali — Parti 2-80: Prove —
Prova Fi: Vibrazioni — Modalità mista
219
4.5 Urti meccanici ISO 16750-3: Capitolo 4.2.3 Prova VI: Prove
per i dispositivi nel o sul cambio
urto mezzo-sinusoidale, accelerazione da defi­
nire nell'intervallo 3 000…15 000 m/s 2 , durata
dell'impulso da definire, tuttavia
mero di urti: da definire
Questa prova si riferisce alla norma IEC 60068-
2-27: Prove ambientali. Parte 2: Prove. Prova
Ea e guida: Urti.
219
4.6 Protezione contro l'acqua e i
corpi estranei
Prova conformemente a ISO 20653: Veicoli
stradali — Grado di protezione (codice IP) —
Protezione delle apparecchiature da oggetti
estranei, dall'acqua e dall'accesso
(Valore target IP 64)
220, 221
4.7 Protezione contro polarità in­
versa
Verificare che il sensore di movimento possa
sopportare un'inversione dell'alimentazione
216
4.8 Protezione contro cortocir­
cuiti
Verificare che i segnali in ingresso e in uscita
siano protetti contro i cortocircuiti rispetto ad
alimentazione e massa
216
5. Compatibilità elettromagnetica
5.1 Emissioni irradiate e sensibi­
lità ai disturbi
Verifica della conformità al regolamento ECE
R10
218
5.2 Scariche elettrostatiche Conformità alla norma ISO 10605:2008 + Ret­
tifica tecnica:2010 + AMD1:2014: +/– 4kV per
il contatto e +/– 8kV per lo scarico di aria
218
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 401
N. Prova Descrizione Requisiti applicabili
5.3 Sensibilità ai transitori con­
dotti nelle linee dati
Per le versioni da 24 V: conformità a ISO 7637-
2 + regolamento ECE n. 10 Rev. 3:
impulso 1a: Vs = – 450V Ri = 50 ohm
impulso 2a: Vs = + 37V Ri = 2 ohm
impulso 2b: Vs = + 20V Ri = 0,05 ohm
impulso 3a: Vs = – 150V Ri = 50 ohm
impulso 3b: Vs = + 150V Ri = 50 ohm
impulso 4: Vs = – 16V Va = – 12V t6 = 100ms
impulso 5: Vs = + 120V Ri = 2,2 ohm td =
250ms
Per le versioni da 12 V: conformità a ISO 7637-
1 + regolamento ECE n. 10 Rev. 3:
impulso 1: Vs = – 75V Ri = 10 ohm
impulso 2a: Vs = + 37V Ri = 2 ohm
impulso 2b: Vs = + 10V Ri = 0,05 ohm
impulso 3a: Vs = – 112V Ri = 50 ohm
impulso 3b: Vs = + 75V Ri = 50 ohm
impulso 4: Vs = – 6V Va = – 5V t6=15ms
impulso 5: Vs = + 65V Ri = 3ohm td = 100ms
L'impulso 5 va controllato solo per le unità elet­
troniche di bordo destinate al montaggio in vei­
coli per i quali non è prevista una protezione
comune esterna contro le cadute della potenza
di carico
Per la proposta relativa alle cadute della potenza
di carico fare riferimento alla norma ISO
16750-2, 4a edizione, capitolo 4.6.4.
218
4. PROVE FUNZIONALI PER LE CARTE TACHIGRAFICHE
Le prove conformemente alla presente sezione 4,
n. 5, «Prove dei protocolli»,
n. 6, «Struttura della carta» e
n. 7, «Prove funzionali»
possono essere eseguite dall'addetto alla valutazione o alla certificazione
durante la procedura di certificazione della sicurezza del modulo chip
basata sui criteri comuni (CC).
Le prove numero 2.3 e 4.2 sono identiche. Esse sono le prove meccaniche
della combinazione carta e modulo chip. Se uno di questi componenti
(carta, modulo chip) viene modificato, tali prove diventano necessarie.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 402
N. Prova Descrizione Requisiti applicabili
1. Esame amministrativo
1.1 Documentazione Correttezza della documentazione
2 Carta
2.1 Stampa Accertarsi che tutte le caratteristiche di protezione e i
dati visibili siano stampati correttamente sulla carta e
siano conformi.
[Designatore]
Allegato 1C, capitolo 4.1 «Dati visibili», 227)
Il lato anteriore deve contenere:
i termini «Carta del conducente» o «Carta di con­
trollo» o «Carta dell'officina» o «Carta dell'azienda»
stampati in maiuscolo nella lingua o nelle lingue
ufficiali dello Stato membro che rilascia la carta, a
seconda del tipo di carta;
[Nome dello Stato membro]
Allegato 1C, capitolo 4.1 «Dati visibili», 228)
Il lato anteriore deve contenere:
il nome dello Stato membro che rilascia la carta
(facoltativo).
[Sigla]
Allegato 1C, capitolo 4.1 «Dati visibili», 229)
Il lato anteriore deve contenere:
la sigla distintiva dello Stato membro che rilascia la
carta, stampata in negativo in un rettangolo azzurro e
circondata da dodici stelle gialle.
[Numerazione]
Allegato 1C, capitolo 4.1 «Dati visibili», 232)
Il retro della carta deve contenere:
la spiegazione delle voci numerate che appaiono sul
lato anteriore della carta;
[Colore]
Allegato 1C, capitolo 4.1 «Dati visibili», 234)
Le carte tachigrafiche devono essere stampate con i
seguenti colori di fondo predominanti:
— carta del conducente: bianco,
— carta dell'officina: rosso,
— carta di controllo: azzurro,
— carta dell'azienda: giallo.
da 227 a 229, 232,
da 234 a 236
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 403
N. Prova Descrizione Requisiti applicabili
[Sicurezza]
Allegato 1C, capitolo 4.1 «Dati visibili», 235)
Le carte tachigrafiche devono presentare almeno le
caratteristiche seguenti per essere protette contro la
falsificazione e la manomissione:
— un fondo di sicurezza finemente arabescato e
stampa a iride,
— almeno una linea bicromatica microstampata.
[Marcature]
Allegato 1C, capitolo 4.1 «Dati visibili», 236)
Gli Stati membri possono aggiungere altri colori o
iscrizioni, come simboli nazionali ed altre caratter-
istiche di sicurezza.
[Marchio di omologazione]
Le carte tachigrafiche devono essere contrassegnate
con un marchio di omologazione.
Il marchio di omologazione deve essere composto:
— di un rettangolo, all'interno del quale si trova la
lettera «e» seguita da un numero distintivo o da
una lettera distintiva del paese che ha rilasciato
l'omologazione,
— di un numero di omologazione corrispondente al
numero della scheda di omologazione della carta
tachigrafica, posto in una posizione qualsiasi in
prossimità del rettangolo.
2.2 Prove meccaniche
[Dimensioni della carta]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Carat­
teristiche fisiche,
[5] Dimensioni della carta,
[5.1] Dimensioni della carta
[5.1.1] Dimensioni della carta e tolleranze,
carta tipo ID-1 Carta non usata
[Bordi della carta]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[5] Dimensioni della carta,
[5.1] Dimensioni della carta
[5.1.2] Bordi della carta
240, 243
ISO/IEC 7810
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 404
N. Prova Descrizione Requisiti applicabili
[Costruzione della carta]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[6] Costruzione della carta
[Materiali costruttivi della carta]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[7] Materiali costruttivi della carta
[Resistenza alla flessione]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[8] Caratteristiche della carta
[8.1] Resistenza alla flessione
[Tossicità]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[8] Caratteristiche della carta
[8.3] Tossicità
[Resistenza agli agenti chimici]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[8] Caratteristiche della carta
[8.4] Resistenza agli agenti chimici
[Stabilità della carta]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[8] Caratteristiche della carta
[8.5] Stabilità dimensionale della carta e deformazione
dovuta alla temperatura e all'umidità
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 405
N. Prova Descrizione Requisiti applicabili
[Luce]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[8] Caratteristiche della carta
[8.6] Luce
[Durabilità]
Allegato 1C, capitolo 4.4 «Specifiche ambientali ed
elettriche», 241)
Le carte tachigrafiche devono essere in grado di
funzionare correttamente per un periodo di cinque
anni, se impiegate nel rispetto delle specifiche
ambientali ed elettriche.
[Resistenza dello strato esterno]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[8] Caratteristiche della carta
[8.8] Resistenza dello strato esterno
[Aderenza o blocco]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[8] Caratteristiche della carta
[8.9] Aderenza o blocco
[Deformazione]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[8] Caratteristiche della carta
[8.11] Deformazione globale della carta
[Resistenza al calore]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[8] Caratteristiche della carta
[8.12] Resistenza al calore
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 406
N. Prova Descrizione Requisiti applicabili
[Distorsioni superficiali]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[8] Caratteristiche della carta
[8.13] Distorsioni superficiali
[Contaminazione]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810, Carte di identificazione — Caratter-
istiche fisiche,
[8] Caratteristiche della carta
[8.14] Contaminazione e interazione dei componenti
della carta
2.3 Prove meccaniche con
modulo chip integrato [Flessione]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810:2003/Amd. 1:2009, Carte di identifi­
cazione — Caratteristiche fisiche, Modifica 1: Cri­
teri per carte con circuiti integrati
[9.2] Sollecitazione dinamica alla flessione
Numero totale di cicli di flessione: 4 000.
[Torsione]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810:2003/Amd. 1:2009, Carte di identifica-
zione — Caratteristiche fisiche, Modifica 1: Criteri per
carte con circuiti integrati
[9.3] Sollecitazione dinamica alla torsione
Numero totale di cicli di torsione: 4 000.
ISO/IEC 7810
3 Modulo
3.1 Modulo Il modulo è costituito dall'involucro totale e dalla
piastra a contatto.
[Profilo superficiale]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7816-1:2011, Carte di identificazione —
Carte a circuito integrato — Parte 1: Carte con con­
tatti — Caratteristiche fisiche
[4.2] Profilo superficiale dei contatti
ISO/IEC 7816
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 407
N. Prova Descrizione Requisiti applicabili
[Resistenza meccanica]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7816-1:2011, Carte di identificazione —
Carte a circuito integrato — Parte 1: Carte con con­
tatti — Caratteristiche fisiche
[4.3] Resistenza meccanica (della carta e dei contatti)
[Resistenza elettrica]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7816-1:2011, Carte di identificazione —
Carte a circuito integrato — Parte 1: Carte con contatti
— Caratteristiche fisiche
[4.4] Resistenza elettrica (dei contatti)
[Dimensione:]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7816-2:2007, Carte di identificazione —
Carte a circuito integrato — Parte 2: Carte con contatti
— Dimensione e posizione dei contatti
[3] Dimensione dei contatti
[Posizione]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7816-2:2007, Carte di identificazione —
Carte a circuito integrato — Parte 2: Carte con contatti
— Dimensione e posizione dei contatti
[4] Numero e posizione dei contatti
Nel caso di moduli con sei contatti, i contatti «C4» e
«C8» non sono inclusi nella prova prescritta.
4 Chip
4.1 Chip
[Temperatura di esercizio]
Il chip della carta tachigrafica deve funzionare in un
campo di temperatura ambientale compreso tra -25
°C e +85 °C.
da 241 a 244
ECE R10
ISO/IEC 7810
ISO/IEC 10373
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 408
N. Prova Descrizione Requisiti applicabili
[Temperatura e umidità]
Allegato 1C, capitolo 4.4 «Specifiche ambientali ed
elettriche», 241)
Le carte tachigrafiche devono essere in grado di fun­
zionare correttamente in tutte le condizioni climati­
che abituali nel territorio della Comunità e almeno
nel campo di temperatura compreso tra – 25 °C e +
70 °C, con picchi occasionali fino a + 85 °C, dove
per «occasionale» s'intende non superiore a 4 ore per
volta e non superiore a 100 volte nell'intero periodo
di durata della carta.
Le carte tachigrafiche devono essere esposte, in fasi
successive, alle seguenti temperature e tassi di umi­
dità per i periodi indicati. Dopo ogni fase viene pro­
vata la funzionalità elettrica delle carte tachigrafiche.
1. Temperatura di – 20 °C per 2 h.
2. Temperatura di +/– 0 °C per 2 h.
3. Temperatura di + 20 °C, 50 % RH, per 2 h.
4. Temperatura di + 50 °C, 50 % RH, per 2 h.
5. Temperatura di + 70 °C, 50 % RH, per 2 h.
La temperatura viene aumentata in modo intermit­
tente a + 85 °C, 50 % RH, per 60 min.
6. Temperatura di + 70 °C, 85 % RH, per 2 h.
La temperatura viene aumentata in modo intermit­
tente a + 85 °C, 85 % RH, per 30 min.
[Umidità]
Allegato 1C, capitolo 4.4 «Specifiche ambientali ed
elettriche», 242)
Le carte tachigrafiche devono essere in grado di
funzionare correttamente nel campo di umidità
compreso tra 10 % e 90 %.
[Compatibilità elettromagnetica — EMC]
Allegato 1C, capitolo 4.4 «Specifiche ambientali ed
elettriche», 244)
Durante il funzionamento le carte tachigrafiche
devono essere conformi alla norma ECE R10 relativa
alla compatibilità elettromagnetica.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 409
N. Prova Descrizione Requisiti applicabili
[Elettricità statica]
Allegato 1C, capitolo 4.4 «Specifiche ambientali ed
elettriche», 244)
Durante il funzionamento le carte tachigrafiche
devono essere protette contro le scariche elettrosta-
tiche.
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810:2003/Amd. 1:2009, Carte di identifi-
cazione — Caratteristiche fisiche, Modifica 1: Criteri
per carte con circuiti integrati
[9.4] Elettricità statica
[9.4.1] Carte IC a contatto
Tensione di prova: 4 000 V.
[Raggi X]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810:2003/Amd. 1:2009, Carte di identifi-
cazione — Caratteristiche fisiche, Modifica 1: Criteri
per carte con circuiti integrati
[9.1] Raggi X
[Luce ultravioletta]
ISO/IEC 10373-1:2006, Carte di identificazione —
Metodi di prova — Parte 1: Caratteristiche generali
[5.11] Luce ultravioletta
[a 3 ruote]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 10373-1:2006/Amd. 1:2012, Carte di identi-
ficazione — Metodi di prova — Parte 1: Caratter-
istiche generali, Modifica 1
[5.22] ICC — Resistenza meccanica: prova a 3 ruote
per gli ICC con contatti
[Avvolgimento]
Le carte tachigrafiche devono essere conformi alla
norma
MasterCard CQM V2.03:2013
[11.1.3] R-L3-14-8: Prova della robustezza dell'av-
volgimento
[13.2.1.32] TM-422: Affidabilità meccanica: Prova di
avvolgimento
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 410
N. Prova Descrizione Requisiti applicabili
4.2 Modulo del chip per le
prove meccaniche inte­
grato nella carta
stessa-> uguale a 2.3
[Flessione]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810:2003/Amd. 1:2009, Carte di identifi­
cazione — Caratteristiche fisiche, Modifica 1: Cri­
teri per carte con circuiti integrati
[9.2] Sollecitazione dinamica alla flessione
Numero totale di cicli di flessione: 4 000.
[Torsione]
Le carte tachigrafiche devono essere conformi alla
norma
ISO/IEC 7810:2003/Amd. 1:2009, Carte di identifi-
cazione — Caratteristiche fisiche, Modifica 1: Criteri
per carte con circuiti integrati
[9.3] Sollecitazione dinamica alla torsione
Numero totale di cicli di torsione: 4 000.
ISO/IEC 7810
5 Prove dei protocolli
5.1 ATR Verificare la conformità dell'ATR ISO/IEC 7816-3
TCS_14, TCS_17,
TCS_18
5.2 T=0 Verificare la conformità del protocollo T = 0 ISO/IEC 7816-3
TCS_11, TCS_12,
TCS_13, TCS_15
5.3 PTS Verificare la conformità del comando PTS passando
all'impostazione T = 1 da T = 0
ISO/IEC 7816-3
TCS_12, TCS_19,
TCS_20, TCS_21
5.4 T=1 Verificare la conformità del protocollo T = 1 ISO/IEC 7816-3
TCS_11, TCS_13,
TCS_16
6 Struttura della carta
6.1 Controllare la conformità della struttura dei file della
carta, verificando la presenza dei file obbligatori nella
carta e le relative condizioni di accesso
da TCS_22 a
TCS_28
da TCS_140 a
TCS_179
7 Prove funzionali
7.1 Elaborazione normale Verificare almeno una volta ogni uso ammesso di cia­
scun comando (per es.: verificare il comando UP­
DATE BINARY con CLA = «00», CLA = «0C» e
con parametri P1, P2 e Lc diversi).
Verificare che le operazioni siano state effettivamente
eseguite nella carta (per es.: leggendo il file su cui è
stato eseguito il comando)
da TCS_29 a
TCS_139
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 411
N. Prova Descrizione Requisiti applicabili
7.2 Messaggi di errore Verificare almeno una volta ogni messaggio di errore
(secondo quanto specificato all'appendice 2) per cia­
scun comando.
Verificare almeno una volta ogni errore generico (ec­
cetto per gli errori di integrità «6400» verificati nel­
l'ambito della certificazione della sicurezza)
7.3 Cypher suite e parametri Domain standardizzati CSM_48, CSM_50
8 Personalizzazione
8.1 Personalizzazione ot­
tica Allegato 1C, capitolo 4.1 «Dati visibili», 230)
Il lato anteriore deve contenere:
le informazioni specifiche della carta.
Allegato 1C, capitolo 4.1 «Dati visibili», 231)
Il lato anteriore deve contenere:
le date, indicate nel formato «gg/mm/aaaa» o
«gg.mm.aaaa» (giorno, mese, anno).
Allegato 1C, capitolo 4.1 «Dati visibili», 235)
Le carte tachigrafiche devono presentare almeno le
caratteristiche seguenti per essere protette contro la
falsificazione e la manomissione:
— sovrapposizione del fondo di sicurezza e della
fotografia.-
230, 231, 235
5. PROVE DEL DISPOSITIVO GNSS ESTERNO
N. Prova Descrizione Requisiti applicabili
1. Esame amministrativo
1.1 Documenta­
zione
Correttezza della documentazione
2. Ispezione visiva del dispositivo GNSS esterno
2.1. Conformità alla documentazione
2.2. Identificazione/marcature da 224 a 226
2.3 Materiali da 219 a 223
3. Prove funzionali
3.1 Dati di identificazione del sensore 98.99
3.2 Modulo GNSS esterno — accoppiamento dell'unità elettronica di bordo 123, 205
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 412
N. Prova Descrizione Requisiti applicabili
3.3 Posizione GNSS 36, 37
3.4 Interfaccia dell'unità elettronica di bordo quando il ricevitore GNSS è esterno
all'unità elettronica di bordo
03
3.5 Cypher suite e parametri Domain standardizzati CSM_48, CSM_50
4. Prove ambientali
4.1 Temperatura Verificare la funzionalità mediante:
prova conformemente alla norma ISO 16750-4, capitolo
5.1.1.2: Prova di funzionamento a bassa temperatura (72 h
@ – 20 °C)
Questa prova si riferisce alla norma IEC 60068-2-1: Prove
ambientali — Parti 2-1: Prove — Prova A: Freddo
Prova conformemente a ISO 16750-4: Capitolo 5.1.2.2:
Prova di funzionamento ad alta temperatura (72 h @ 70 °C)
Questa prova si riferisce alla norma IEC 60068-2-2: Proce­
dure di prove ambientali di base; parte 2: prove; prove B:
calore secco
Prova conformemente a ISO 16750-4: Capitolo 5.3.2 Cam­
biamento rapido di temperatura con durata specifica della
transizione (– 20 °C/70 °C, 20 cicli, tempo di permanenza
di 1 h a ogni temperatura)
Si può effettuare una serie ridotta di prove (fra quelle definite
alla sezione 3 della presente tabella) alla temperatura più
bassa, alla temperatura più alta e durante i cicli di tempera­
ture
213
4.2 Umidità Verificare che l'unità elettronica di bordo possa sopportare
un'umidità ciclica (prova termica), mediante prova Db, IEC
60068-2-30, sei cicli di 24 ore, ciascuno con temperature che
variano da + 25 °C a + 55 °C ed un'umidità relativa del
97 % a + 25 °C e del 93 % a + 55 °C
214
4.3 Prove meccani­
che
1. Vibrazioni sinusoidali.
Verificare che l'unità elettronica di bordo possa sopportare
vibrazioni sinusoidali aventi le seguenti caratteristiche:
spostamento costante tra 5 e 11 Hz: picco di 10 mm
accelerazione costante tra 11 e 300 Hz: 5 g
Questo requisito si verifica in base alla norma IEC 60068-
2-6, prova Fc, con una durata minima della prova di 3 ×
12 ore (12 ore per asse)
La norma ISO 16750-3 non prescrive una prova di vibra­
zione sinusoidale per i dispositivi posizionati nella cabina
del veicolo staccata.
219
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 413
N. Prova Descrizione Requisiti applicabili
2. Vibrazioni casuali:
Prova conformemente a ISO 16750-3: Capitolo 4.1.2.8:
Prova VIII: Veicolo commerciale, cabina del veicolo
staccata
Prova delle vibrazioni casuali, 10…2 000 Hz, RMS
verticale 21,3 m/s 2 , RMS longitudinale 11,8 m/s 2 , RMS
laterale 13,1 m/s 2 , 3 assi, 32 h per asse, incluso il ciclo di
temperatura – 20…70 °C.
Questa prova si riferisce alla norma IEC 60068-2-64: Prove
ambientali — Parti 2-64: Prove — Prova Fh: Vibrazioni, a
banda larga casuali e guida
3. Urti:
urto meccanico con mezzo seno 3g conformemente a ISO
16750.
Le prove sopra descritte sono effettuate su campioni diversi del
modello di apparecchio sottoposto alle prove
4.4 Protezione con­
tro l'acqua e i
corpi estranei
Prova conformemente a ISO 20653: Veicoli stradali —
Grado di protezione (codice IP) — Protezione delle apparec­
chiature da oggetti estranei, dall'acqua e dall'accesso (senza
modifica dei parametri)
220, 221
4.5 Protezione con­
tro sovraten­
sione
Verificare che l'unità elettronica di bordo possa sopportare
un'alimentazione di:
216
Versioni da 24 V: 34V a + 40 °C 1 ora
Versioni da 12 V: 17V a + 40 °C 1 ora
(ISO 16750-2, capitolo 4.3)
4.6 Protezione con­
tro polarità in­
versa
Verificare che l'unità elettronica di bordo possa sopportare
un'inversione dell'alimentazione
(ISO 16750-2, capitolo 4.7)
216
4.7 Protezione con­
tro cortocircuiti
Verificare che i segnali in ingresso e in uscita siano protetti
contro i cortocircuiti rispetto ad alimentazione e massa
(ISO 16750-2, capitolo 4.10)
216
5 Prove della compatibilità elettromagnetica
5.1 Emissioni irra­
diate e sensibi­
lità ai disturbi
Conformità al regolamento ECE R10 218
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 414
N. Prova Descrizione Requisiti applicabili
5.2 Scariche elet­
trostatiche
Conformità alla norma ISO 10605:2008 + Rettifica tec­
nica:2010 + AMD1:2014: +/– 4kV per il contatto e +/–
8kV per lo scarico di aria
218
5.3 Sensibilità ai
transitori con­
dotti nell'ali­
mentazione
Per le versioni da 24 V: conformità a ISO 7637-2 + regola­
mento ECE n. 10 Rev. 3:
impulso 1a: Vs = – 450V Ri = 50 ohm
impulso 2a: Vs = + 37V Ri = 2 ohm
impulso 2b: Vs = + 20V Ri = 0,05 ohm
impulso 3a: V s= – 150V Ri = 50 ohm
impulso 3b: Vs=+150V Ri=50 ohm
impulso 4: Vs = – 16V Va = – 12V t6 = 100ms
impulso 5: Vs = + 120V Ri = 2,2 ohm td = 250ms
Per le versioni da 12 V: conformità a ISO 7637-1 + regola­
mento ECE n. 10 Rev. 3:
impulso 1: Vs = – 75V Ri = 10 ohm
impulso 2a: Vs = + 37V Ri = 2 ohm
impulso 2b: Vs = + 10V Ri = 0,05 ohm
impulso 3a: Vs = – 112V Ri = 50 ohm
impulso 3b: Vs = + 75V Ri = 50 ohm
impulso 4: Vs = – 6V Va = – 5V t6 = 15ms
impulso 5: Vs = + 65V Ri = 3ohm td = 100ms
L'impulso 5 va controllato solo per le unità elettroniche di
bordo destinate al montaggio in veicoli per i quali non è
prevista una protezione comune esterna contro le cadute della
potenza di carico
Per la proposta relativa alle cadute della potenza di carico
fare riferimento alla norma ISO 16750-2, 4a edizione, capi­
tolo 4.6.4.
218
▼M1
6. PROVE DEL DISPOSITIVO ESTERNO DI COMUNICAZIONE RE­
MOTA
N. Prova Descrizione Requisiti applicabili
1. Esame amministrativo
1.1 Documentazione Correttezza della do­
cumentazione
2. Esame visivo
2.1. Conformità alla documentazione
2.2. Identificazione/marcature 225, 226
2.3 Materiali da 219 a 223
3. Prove funzionali
3.1 Comunicazione remota per controlli su strada mirati 4, da 197 a 199
3.2 Registrazione e memorizzazione nella memoria di dati 91
3.3 Comunicazione con l’unità elettronica di bordo Appendice 14, da
DSC_66 a DSC_70,
da DSC_71 a
DSC_76
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 415
N. Prova Descrizione Requisiti applicabili
4. Prove ambientali
4.1 Temperatura: Verificare la funzionalità mediante:
prova conformemente alla norma ISO 16750-4, capitolo
5.1.1.2: Prova di funzionamento a bassa temperatura (72
h a -20 °C)
Questa prova si riferisce alla norma IEC 60068-2-1:
Prove ambientali - Parti 2-1: Prove - Prova A: freddo
Prova conformemente a ISO 16750-4: Capitolo 5.1.2.2:
Prova di funzionamento ad alta temperatura (72 h a 70 °C)
Questa prova si riferisce alla norma IEC 60068-2-2: Pro­
cedure di prove ambientali di base; Parte 2: Prove; Prove
B: calore secco
Prova conformemente a ISO 16750-4: Capitolo 5.3.2:
Cambiamento rapido di temperatura con durata specifica
della transizione (-20 °C/70 °C, 20 cicli, tempo di perma­
nenza di 1 h a ogni temperatura)
Si può effettuare una serie ridotta di prove (fra quelle de­
finite alla sezione 3 della presente tabella) alla temperatura
più bassa, alla temperatura più alta e durante i cicli di
temperature
213
4.2 Protezione contro
l’acqua e i corpi
estranei
Prova conformemente a ISO 20653: Veicoli stradali –
Grado di protezione (codice IP) – Protezione delle appa­
recchiature da oggetti estranei, dall’acqua e dall’accesso
(valore target IP40)
220, 221
5 Prove della compatibilità elettromagnetica
5.1 Emissioni irradiate
e sensibilità ai di­
sturbi
Conformità al regolamento ECE R10 218
5.2 Scariche elettrostati­
che
Conformità alla norma ISO 10605 :2008 + Rettifica tec­
nica :2010 + AMD1 :2014: +/- 4kV per il contatto e +/-
8kV per lo scarico di aria
218
5.3 Sensibilità ai transi­
tori condotti
nell’alimentazione
Per le versioni da 24 V: conformità alla norma ISO
7637-2 + regolamento ECE n. 10 Rev. 3:
impulso 1a: Vs = -450V Ri = 50 ohm
impulso 2a: Vs = +37V Ri = 2 ohm
impulso 2b: Vs = +20V Ri = 0,05 ohm
impulso 3a: Vs = -150V Ri = 50 ohm
impulso 3b: Vs = +150V Ri = 50 ohm
impulso 4: Vs = -16V Va = -12V t6 = 100ms
impulso 5: Vs = +120V Ri = 2,2 ohm td = 250ms
Per le versioni da 12 V: conformità alla norma ISO
7637-1 + regolamento ECE n. 10 Rev. 3:
impulso 1: Vs = -75V Ri = 10 ohm
impulso 2a: Vs = +37V Ri = 2 ohm
impulso 2b: Vs = +10V Ri = 0,05 ohm
impulso 3a: Vs = -112V Ri = 50 ohm
218
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 416
N. Prova Descrizione Requisiti applicabili
impulso 3b: Vs = +75V Ri = 50 ohm
impulso 4: Vs = -6V Va = -5V t6 = 15ms
impulso 5: Vs = +65V Ri = 3ohm td = 100ms
L’impulso 5 va controllato solo per le unità elettroniche
di bordo destinate al montaggio in veicoli per i quali non
è prevista una protezione comune esterna contro le ca­
dute della potenza di carico
Per la proposta relativa alle cadute della potenza di ca­
rico fare riferimento alla norma ISO 16750-2, 4a edi­
zione, capitolo 4.6.4.
▼B
7. PROVE FUNZIONALI SU CARTA
N. Prova Descrizione Requisiti applicabili
1. Esame amministrativo
1.1 Documentazione Correttezza della documentazione
2 Prove generali
2.1 Numero di caratteri
per riga
Ispezione ottica delle stampe. 172
2.2 Dimensione minima
dei caratteri
Esame visivo delle stampe e ispezione dei caratteri. 173
2.3 Insieme standard di
caratteri supportati
La stampante deve poter stampare i caratteri specificati
nell'appendice 1, capitolo 4, «Insiemi di caratteri».
174
2.4 Definizione delle
stampe
Controllo dell'omologazione del tachigrafo e esame vi­
sivo delle stampe
174
2.5 Leggibilità e identifi­
cazione delle stampe
Ispezione delle stampe
Dimostrata dal fabbricante mediante verbali e protocolli
di prova.
Tutti i numeri di omologazione dei tachigrafi con cui è
possibile usare la carta per stampante sono iscritti sulla
carta.
175, 177, 178
2.6 Aggiunta di note
scritte a mano
Esame visivo: È disponibile il campo per la firma del
conducente.
Sono disponibili campi per altre voci scritte a mano.
180
2.7 Ulteriori dettagli
sulla carta.
Sul lato frontale e sul retro della carta possono essere
riportati ulteriori dettagli e informazioni,
che non devono tuttavia interferire con la leggibilità
delle stampe.
Esame visivo.
177, 178
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 417
N. Prova Descrizione Requisiti applicabili
3 Prove di archiviazione
3.1 Calore secco Precondizionamento: 16 ore a + 23 °C ± 2 °C/55 %
± 3 % di umidità relativa
Ambiente di prova: 72 ore a + 70 °C ± 2 °C
Recupero: 16 ore a + 23 °C ± 2 °C/55 % ± 3 % di
umidità relativa
176, 178
IEC 60068-2-2-Bb
2.2 Calore umido Precondizionamento: 16 ore a + 23 °C ± 2 °C/55 %
± 3 % di umidità relativa
Ambiente di prova: 144 ore a + 55 °C ± 2 °C/93 %
± 3 % di umidità relativa
Recupero: 16 ore a + 23 °C ± 2 °C/55 % ± 3 % di
umidità relativa
176, 178
IEC 60068-2-78-Cab
4 Prove di servizio della carta
4.1 Resistenza dello
sfondo all'umidità
(carta non stampata)
Precondizionamento: 16 ore a + 23 °C ± 2 °C/55 %
± 3 % di umidità relativa
Ambiente di prova: 144 ore a + 55 °C ± 2 °C/93 %
± 3 % di umidità relativa
Recupero: 16 ore a + 23 °C ± 2 °C/55 % ± 3 % di
umidità relativa
176, 178
IEC 60068-2-78-Cab
4.2 Stampabilità Precondizionamento: 24 ore a + 40 °C ± 2 °C/93 %
± 3 % di umidità relativa
Ambiente di prova: stampa prodotta a + 23 °C ± 2 °C
Recupero: 16 ore a + 23 °C ± 2 °C/55 % ± 3 % di
umidità relativa
176, 178
4.3 Resistenza al calore Precondizionamento: 16 ore a + 23 °C ± 2 °C/55 %
± 3 % di umidità relativa
Ambiente di prova: 2 ore a + 70 °C ± 2 °C, calore
secco
Recupero: 16 ore a + 23 °C ± 2 °C/55 % ± 3 % di
umidità relativa
176, 178
IEC 60068-2-2-Bb
4.4 Resistenza alle tem­
perature basse
Precondizionamento: 16 ore a + 23 °C ± 2 °C/55 %
± 3 % di umidità relativa
Ambiente di prova: 24 ore – 20°C ± 3 °C, freddo secco
Recupero: 16 ore a + 23 °C ± 2 °C/55 % ± 3 % di
umidità relativa
176, 178
ISO 60068-2-1-Ab
4.5 Resistenza alla luce Precondizionamento: 16 ore a + 23 °C ± 2 °C/55 %
± 3 % di umidità relativa
Ambiente di prova: 100 ore con un'illuminazione di
5 000 Lux a + 23 °C ± 2 °C/55 % ± 3 % di umidità
relativa
Recupero: 16 ore a + 23 °C ± 2 °C/55 % ± 3 % di
umidità relativa
176, 178
Criteri di leggibilità per le prove 3.x e 4.x:
La leggibilità delle stampe è garantita se i valori di densità ottica sono
conformi ai limiti seguenti:
caratteri stampati: min. 1,0
sfondo (carta non stampata): max. 0,2
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 418
I valori di densità ottica delle stampe devono essere misurati conforme­
mente alla norma DIN EN ISO 534.
Le stampe non devono evidenziare cambiamenti di dimensioni e devono
rimanere chiaramente leggibili.
8. PROVE DI INTEROPERABILITÀ
▼M1
N. Prova Descrizione
8.1 Prove di interoperabilità tra unità elettroniche di bordo e carte tachigrafiche
1 Autenticazione reciproca Verificare che l’autenticazione reciproca tra l’unità elettronica di
bordo e la carta tachigrafica funzioni normalmente
2 Prove di scrittura/lettura Predisporre uno scenario di attività tipico sull’unità elettronica di
bordo. Lo scenario deve essere adattato al tipo di carta sottoposta
alla prova e prevedere la scrittura nel maggior numero possibile di
EF nella carta
Verificare mediante un trasferimento dei dati dell’unità elettronica
di bordo che tutte le registrazioni corrispondenti siano state effet­
tuate correttamente
Verificare mediante un trasferimento dei dati della carta che tutte le
registrazioni corrispondenti siano state effettuate correttamente
Verificare mediante stampe giornaliere che tutte le registrazioni
corrispondenti si possano leggere correttamente
8.2 Prove di interoperabilità tra unità elettroniche di bordo e sensori di movimento
1 Abbinamento Verificare che l’abbinamento delle unità elettroniche di bordo e dei
sensori di movimento funzioni normalmente
2 Prove delle attività Predisporre uno scenario di attività tipico sul sensore di movi­
mento. Lo scenario deve includere un’attività normale e creare il
maggior numero possibile di anomalie o guasti.
Verificare mediante un trasferimento dei dati dell’unità elettronica
di bordo che tutte le registrazioni corrispondenti siano state effet­
tuate correttamente
Verificare mediante un trasferimento dei dati della carta che tutte le
registrazioni corrispondenti siano state effettuate correttamente
Verificare mediante una stampa giornaliera che tutte le registrazioni
corrispondenti si possano leggere correttamente
8.3 Prove di interoperabilità tra unità elettroniche di bordo e dispositivi GNSS esterni (se applicabile)
1 Autenticazione reciproca Verificare che l’autenticazione reciproca (accoppiamento) tra
l’unità elettronica di bordo e il modulo GNSS esterno funzioni
normalmente
2 Prove delle attività Predisporre uno scenario di attività tipico sul GNSS esterno. Lo
scenario deve includere un’attività normale e creare il maggior
numero possibile di anomalie o guasti.
Verificare mediante un trasferimento dei dati dell’unità elettronica
di bordo che tutte le registrazioni corrispondenti siano state effet­
tuate correttamente
Verificare mediante un trasferimento dei dati della carta che tutte le
registrazioni corrispondenti siano state effettuate correttamente
Verificare mediante una stampa giornaliera che tutte le registrazioni
corrispondenti si possano leggere correttamente
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 419
9. PROVE OSNMA
9.1. Introduzione
Il presente capitolo descrive le prove volte a dimostrare la corretta imple­
mentazione dell’OSNMA nel ricevitore GNSS. Poiché l’autenticazione del
segnale satellitare è effettuata esclusivamente dal ricevitore GNSS in modo
indipendente da qualsiasi altro componente del tachigrafo, le prove di cui
al presente capitolo possono essere eseguite sul ricevitore GNSS come
elemento a sé stante. Il fabbricante del tachigrafo deve in tal caso presen­
tare alle autorità di omologazione una relazione contenente informazioni
dettagliate sull’elaborazione e sui risultati delle prove eseguite sotto la
responsabilità del fabbricante del ricevitore GNSS.
9.2 Condizioni applicabili
— I criteri di superamento/fallimento definiti nelle prove OSNMA de­
vono essere considerati validi solo per le condizioni di prova
identificate.
— I criteri potrebbero essere rivisti al momento della dichiarazione del
servizio OSNMA di Galileo e tenendo conto dei relativi impegni in
materia di prestazioni del servizio.
9.3. Definizioni e acronimi
9.3.1 Definizioni
avviamento del GNSS a
freddo/"a tiepido/a caldo:
fa riferimento alla condizione di avviamento
di un ricevitore GNSS sulla base della dispo­
nibilità di ora (T), almanacco (A) ed
effemeridi (E) correnti, posizione (P):
— avviamento GNSS a freddo: Nessuno
— avviamento GNSS «a tiepido»: T, A, P
— avviamento GNSS a caldo: T, A, E, P
avviamento OSNMA a
freddo/«a tiepido»/a caldo:
fa riferimento alla condizione di avviamento
della funzione OSNMA sulla base della di­
sponibilità delle informazioni su chiave
pubblica (P) e DSM-KROOT (K) (come de­
finite negli orientamenti per i ricevitori
OSNMA di cui nell’appendice 12):
— avviamento OSNMA a freddo: Nessuno
— avviamento OSNMA «a tiepido»: P
— avviamento OSNMA a caldo: P, K
9.3.2 Acronimi
ADKD Authentication Data & Key Delay (Dati di autenticazione
e Ritardo chiave)
DSM-KROOT Digital Signature Message KROOT (KROOT del messag­
gio di firma digitale)
GNSS Global Navigation Satellite System (sistema globale di
navigazione satellitare)
KROOT Root Key of the TESLA key chain (chiave radice della
catena di chiavi TESLA)
MAC Message Authentication Code (codice di autenticazione
del messaggio)
NMACK Number of MAC & key blocks (per 30 seconds) (numero
di MAC e blocchi di chiavi (per 30 secondi))
OSNMA Galileo Open Service Navigation Message Authentication
(servizio aperto di autenticazione dei messaggi di naviga­
zione di Galileo)
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 420
SLMAC Slow MAC (MAC lento)
TESLA Timed Efficient Stream Loss-tolerant Authentication (pro­
tocollo di autenticazione TESLA utilizzato nell’OSNMA)
9.4. Apparecchiatura per la generazione dei segnali GNSS
La generazione dei segnali GNSS può essere ottenuta utilizzando un ge­
neratore di segnale GNSS multicostellazione che supporta la trasmissione
di messaggi OSNMA. In alternativa, è possibile utilizzare un lettore del
segnale a radiofrequenza in grado di riprodurre campioni di segnali GNSS
da file. La profondità e la frequenza di campionamento dei bit sono, di
norma, rispettivamente di 4 bit I/Q e 10 MHz.
Si presume che il ricevitore GNSS disponga di interfacce atte a comandare
la pulizia della memoria del ricevitore (per cancellare in modo indipen­
dente chiave pubblica, KROOT, informazioni relative all’orologio e alla
posizione, effemeridi e almanacco), a impostare la realizzazione dell’ora
locale del ricevitore per il requisito di verifica oraria dell’OSNMA e a
caricare le informazioni crittografiche. Tali comandi possono essere limi­
tati a finalità di prova e possono pertanto non essere disponibili per il
normale funzionamento del ricevitore.
9.5 Condizioni di prova
9.5.1 Condizioni del GNSS
I segnali GNSS simulati o riprodotti avranno le caratteristiche seguenti:
— scenario con ricevitore-utente statico;
— almeno costellazioni GPS e Galileo;
— frequenza E1/L1;
— almeno 4 satelliti Galileo con angolo di elevazione superiore a 5 o ;
— durata conforme a quanto richiesto per ciascuna prova;
— trasmissione costante delle effemeridi di navigazione dei satelliti du­
rante la prova.
9.5.2 Condizioni dell’OSNMA
Il messaggio OSNMA trasmesso con segnale RF avrà le caratteristiche
seguenti:
— un messaggio HKROOT con OSNMA impostato sullo stato operativo
o di prova e una DSM-KROOT di 8 blocchi per la catena impiegata;
— almeno 4 satelliti Galileo che trasmettono OSNMA;
— un messaggio MACK con un blocco MACK (ossia NMACK=1) e
almeno un ADKD=0 e un ADKD=12 per satellite e blocco MACK;
— tag a 40 bit;
— la lunghezza minima equivalente del tag conforme a quanto richiesto
negli orientamenti per i ricevitori OSNMA (attualmente 80 bit).
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 421
Salvo quando indicato, la realizzazione del tempo del ricevitore interno
deve essere nota con sufficiente accuratezza e adeguatamente allineata al
tempo simulato. Ciò garantisce che il requisito di sincronizzazione tem­
porale iniziale OSNMA sia soddisfatto per ogni condizione di prova, vale
a dire la sincronizzazione nominale per tutte le prove tranne la prova
SLMAC. Per maggiori dettagli sull’inizializzazione del tempo, consultare
gli orientamenti per i ricevitori OSNMA.
Si noti che i criteri di superamento/fallimento individuati sono conservativi
e non rappresentano le prestazioni previste dell’OSNMA di Galileo.
9.6. Specifiche di prova
N. Prova Descrizione Requisiti applicabili
1. Esame amministrativo
1.1 Documentazione Correttezza della documentazione
2 Prove generali
2.1 Avviamento OSNMA a
caldo
Obiettivo: verificare che il ricevitore GNSS calcoli una
posizione con OSNMA dopo un avviamento a caldo.
Procedura:
il ricevitore GNSS è avviato in condizioni di avvia­
mento GNSS e OSNMA a caldo e acquisisce i segnali
dei satelliti Galileo visibili.
Il ricevitore autentica i dati di navigazione Galileo con
OSNMA (ADKD = 0) e fornisce una posizione con dati
autenticati.
Criteri di superamento/fallimento: il ricevitore calcola
una posizione geografica autenticata entro 160 secondi.
Appendice 12,
GNS_3b
2.2 Avviamento OSNMA
«a tiepido»
Obiettivo: verificare che il ricevitore GNSS calcoli una
posizione con OSNMA dopo un avviamento «a tie­
pido».
Procedura:
prima di iniziare la prova, le informazioni relative a
effemeridi e KROOT devono essere cancellate dalla
memoria del ricevitore GNSS al fine di forzare un av­
viamento GNSS e OSNMA «a tiepido».
Il ricevitore GNSS è avviato e acquisisce i segnali dei
satelliti Galileo visibili.
Il DSM-KROOT è ricevuto e verificato.
Il ricevitore autentica i dati di navigazione Galileo con
OSNMA (ADKD=0) e fornisce una posizione con dati
autenticati.
Criteri di superamento/fallimento: il ricevitore calcola
una posizione geografica valida autenticata entro 430
secondi.
Appendice 12,
GNS_3b
2.3 Avviamento OSNMA
«a tiepido» con
SLMAC
Obiettivo: verificare che il ricevitore GNSS calcoli una
posizione con OSNMA dopo un avviamento «a tie­
pido» con un’inizializzazione del tempo che richiede
la modalità SLMAC, quale definita negli orientamenti
per il ricevitore OSNMA.
Procedura:
la realizzazione del tempo del ricevitore interno deve
essere configurata in modo che il valore dell’incertezza
temporale iniziale sia compreso tra 2 e 2,5 minuti, af­
finché, in conformità agli orientamenti per il ricevitore
OSNMA, la modalità Slow MAC sia attivata.
Appendice 12,
GNS_3b
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 422
N. Prova Descrizione Requisiti applicabili
Prima di iniziare le prove, le informazioni relative a
effemeridi e KROOT devono essere cancellate dalla
memoria del ricevitore GNSS al fine di forzare un av­
viamento GNSS e OSNMA «a tiepido».
Il ricevitore GNSS è avviato e acquisisce i segnali dei
satelliti Galileo visibili.
Il DSM-KROOT è ricevuto e verificato.
Il ricevitore autentica i dati di navigazione Galileo solo
con OSNMA Slow MAC (ADKD=12) e fornisce una
posizione con dati autenticati.
Criteri di superamento/fallimento: il ricevitore calcola
una posizione geografica valida autenticata entro 730
secondi.
2.4 Avviamento OSNMA a
caldo con segnale ri­
prodotto
Obiettivo: verificare che il ricevitore GNSS rilevi un
segnale riprodotto.
Procedura:
il ricevitore GNSS è avviato in condizioni di avvia­
mento GNSS e OSNMA a caldo e acquisisce i segnali
dei satelliti Galileo visibili.
Il ricevitore autentica i dati di navigazione Galileo con
OSNMA (ADKD=0) e fornisce una posizione con dati
autenticati.
Una volta fornita la soluzione PVT con dati autenticati,
il ricevitore viene disattivato.
Si simula un segnale riprodotto con un ritardo di 40
secondi rispetto al segnale precedente e si accende il
ricevitore.
Il ricevitore rileva che l’ora del sistema Galileo tra­
smessa dal segnale spaziale e la realizzazione dell’ora
locale non soddisfano il requisito di sincronizzazione e
interrompe il trattamento dei dati OSNMA, come defi­
nito negli orientamenti per il ricevitore OSNMA.
Criteri di superamento/fallimento: il ricevitore rileva la
riproduzione e non calcola una posizione valida auten­
ticata dall’inizio della riproduzione fino alla fine della
prova.
Appendice 12,
GNS_3b
2.5 Avviamento OSNMA a
caldo con dati falsi
Obiettivo: verificare che l’OSNMA rilevi dati falsi.
Procedura:
il ricevitore GNSS è avviato in condizioni di avvia­
mento GNSS e OSNMA a caldo.
Il ricevitore GNSS deve essere in grado di acquisire il
segnale di tutti i satelliti Galileo visibili e di verificare
l’autenticità dei loro messaggi di navigazione mediante
OSNMA.
Almeno un bit dei dati sulle effemeridi forniti da cia­
scun satellite Galileo non corrisponde ai dati originali e
autenticati, ma il messaggio Galileo I/NAV deve essere
coerente e includere il CRC.
Criteri di superamento/fallimento: il ricevitore rileva i
dati falsi entro 160 secondi e non calcola una posizione
valida autenticata fino al termine della prova.
Appendice 12,
GNS_3b
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 423
Appendice 10
REQUISITI DI SICUREZZA
La presente appendice specifica i requisiti di sicurezza informatici per i compo­
nenti del sistema tachigrafico intelligente (tachigrafo di seconda generazione).
SEC_001 La certificazione di sicurezza dei seguenti componenti del sistema
tachigrafico intelligente deve essere conforme allo standard Common
Criteria (criteri comuni):
— unità elettronica di bordo (VU),
— carta tachigrafica,
— sensore di movimento,
— dispositivo GNSS esterno.
SEC_002 I requisiti minimi di sicurezza informatica che devono essere soddi­
sfatti da ogni componente che necessita della certificazione di sicu­
rezza sono definiti in un profilo di protezione del componente, con­
forme allo standard Common Criteria.
SEC_003 La Commissione europea dovrà assicurarsi che quattro profili di pro­
tezione conformi al presente allegato siano patrocinati, elaborati, ap­
provati dagli organismi pubblici di certificazione della sicurezza infor­
matica organizzati nell'ambito del Joint Interpretation Working
Group (JIWG), il gruppo di lavoro che sostiene il reciproco ricono­
scimento dei certificati sotto l'egida dell'accordo europeo SOGIS-MRA
(Agreement on Mutual Recognition of Information Technology Secu­
rity Evaluation Certificates) e registrati:
— profilo di protezione dell'unità elettronica di bordo (VU),
— profilo di protezione della carta tachigrafica,
— profilo di protezione del sensore di movimento,
— profilo di protezione del dispositivo GNSS esterno.
Il profilo di protezione dell'unità elettronica di bordo (VU) deve affrontare i casi
in cui la VU è destinata ad essere utilizzata sia con un dispositivo GNSS esterno
che senza. Nel primo caso i requisiti di sicurezza del dispositivo GNSS esterno
sono previsti nel profilo di protezione ad esso dedicato.
SEC_004 I fabbricanti dei componenti devono perfezionare e completare l'appo­
sito profilo di protezione del componente a seconda della necessità,
senza modificare né cancellare le specifiche relative alle minacce, agli
obiettivi, alle procedure e alle funzioni di sicurezza, al fine di formu­
lare un obiettivo di sicurezza rispetto al quale richiedere la certifica­
zione di sicurezza del componente.
SEC_005 Nel corso del processo di valutazione deve essere indicata la stretta
conformità di tale obiettivo di sicurezza specifico al profilo di prote­
zione corrispondente.
SEC_006 Il livello di garanzia per ciascun profilo di protezione deve essere
EAL4, aumentato dai componenti di garanzia ATE_DPT.2 e
AVA_VAN.5.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 424
Appendice 11
MECCANISMI COMUNI DI SICUREZZA
INDICE
PREAMBOLO
PARTE A SISTEMA TACHIGRAFICO DI PRIMA GENERAZIONE
1. INTRODUZIONE
1.1. Riferimenti
1.2. Simboli e abbreviazioni
2. SISTEMI E ALGORITMI CRITTOGRAFICI
2.1. Sistemi crittografici
2.2. Algoritmi crittografici
2.2.1 Algoritmo RSA
2.2.2 Algoritmo di hash
2.2.3 Algoritmo di cifratura dei dati
3. CHIAVI E CERTIFICATI
3.1. Generazione e distribuzione di chiavi
3.1.1 Generazione e distribuzione di chiavi RSA
3.1.2 Chiavi di prova RSA
3.1.3 Chiavi per i sensori di movimento
3.1.4 Generazione e distribuzione di chiavi T-DES
3.2. Chiavi
3.3. Certificati
3.3.1 Contenuto dei certificati
3.3.2 Rilascio dei certificati
3.3.3 Verifica e apertura dei certificati
4. MECCANISMO DI AUTENTICAZIONE RECIPROCA
5. MECCANISMI DI RISERVATEZZA, INTEGRITÀ E AUTENTI­
CAZIONE DEI TRASFERIMENTI DI DATI TRA VU E CARTE
5.1. Messaggistica sicura (Secure Messaging)
5.2. Trattamento degli errori della messaggistica sicura
5.3. Algoritmo per il calcolo di totali di controllo crittografico
5.4. Algoritmo per il calcolo di crittogrammi dei DO di riservatezza
6. MECCANISMI DI FIRMA DIGITALE PER IL TRASFERI­
MENTO DEI DATI
6.1. Generazione della firma
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 425
6.2. Verifica della firma
PARTE B SISTEMA TACHIGRAFICO DI SECONDA GENERAZIONE
7. INTRODUZIONE
7.1. Riferimenti
7.2. Simboli e abbreviazioni
7.3. Definizioni
8. SISTEMI E ALGORITMI CRITTOGRAFICI
8.1. Sistemi crittografici
8.2. Algoritmi crittografici
8.2.1 Algoritmi simmetrici
8.2.2 Algoritmi asimmetrici e parametri di dominio standardizzati (stan­
dardized domain parameters)
8.2.3 Algoritmi di hash
8.2.4 Suite crittografiche (cipher suites)
9. CHIAVI E CERTIFICATI
9.1. Coppie di chiavi asimmetriche e certificati delle chiavi pubbliche
9.1.1 Principi generali
9.1.2 Livello europeo
9.1.3 Livello di Stato membro
9.1.4 Livello di apparecchio: unità elettroniche di bordo (VU)
9.1.5 Livello di apparecchio: carte tachigrafiche
9.1.6 Livello di apparecchio: dispositivi GNSS esterni
9.1.7 Riepilogo: sostituzione dei certificati
9.2. Chiavi simmetriche
9.2.1 Chiavi per la sicurezza della comunicazione tra VU e sensore di
movimento
9.2.2 Chiavi per la sicurezza della comunicazione DSRC
9.3. Certificati
9.3.1 Principi generali
9.3.2 Contenuto del certificato
9.3.3 Richiesta di certificati
10. AUTENTICAZIONE RECIPROCA E MESSAGGISTICA SI­
CURA TRA VU E CARTA
10.1. Principi generali
10.2. Verifica reciproca della catena di certificati
10.2.1 Verifica della catena di certificati della carta da parte della VU
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 426
10.2.2 Verifica della catena di certificati della VU da parte della carta
10.3. Autenticazione della VU
10.4. Autenticazione del chip e accordo sulla chiave di sessione
10.5. Messaggistica sicura (Secure Messaging)
10.5.1 Principi generali
10.5.2 Struttura dei messaggi sicuri
10.5.3 Interruzione di una sessione di messaggistica sicura
11. ACCOPPIAMENTO, AUTENTICAZIONE RECIPROCA E MES­
SAGGISTICA SICURA TRA VU E DISPOSITIVO GNSS
ESTERNO
11.1. Principi generali
11.2. Accoppiamento tra VU e dispositivo GNSS esterno
11.3. Verifica reciproca della catena di certificati
11.3.1 Principi generali
11.3.2 Durante l'accoppiamento tra VU e EFG
11.3.3 Durante il funzionamento normale
11.4. Autenticazione della VU, autenticazione del chip e accordo sulla
chiave di sessione
11.5. Messaggistica sicura
12. ABBINAMENTO E COMUNICAZIONE TRA VU E SENSORE
DI MOVIMENTO
12.1. Principi generali
12.2. Abbinamento tra VU e sensore di movimento usando diverse ge­
nerazioni di chiavi
12.3. Abbinamento e comunicazione tra VU e sensore di movimento
usando AES
12.4. Abbinamento tra VU e sensore di movimento per diverse genera­
zioni di apparecchi
13. SICUREZZA PER LA COMUNICAZIONE REMOTA ATTRA­
VERSO DSRC
13.1. Principi generali
13.2. Cifratura del payload del tachigrafo e generazione del MAC
13.3. Verifica e decifratura del payload del tachigrafo
14. FIRMA DEL TRASFERIMENTO DEI DATI E VERIFICA
DELLE FIRME
14.1. Principi generali
14.2. Generazione della firma
14.3. Verifica della firma
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 427
PREAMBOLO
La presente appendice specifica i meccanismi di sicurezza atti a garantire:
— l'autenticazione reciproca tra i diversi componenti del sistema tachigrafico;
— la riservatezza, l'integrità, l'autenticità e/o la non disconoscibilità dei dati
trasferiti tra diversi componenti del sistema tachigrafico o a dispositivi di
memorizzazione esterni.
La presente appendice si articola in due parti. La parte A definisce i meccanismi
di sicurezza per il sistema tachigrafico di prima generazione (tachigrafo digitale).
La parte B definisce i meccanismi di sicurezza per il sistema tachigrafico di
seconda generazione (tachigrafo intelligente).
I meccanismi di cui alla parte A della presente appendice si applicano se almeno
uno dei componenti del sistema tachigrafico coinvolti nell'autenticazione reci­
proca e/o nella procedura di trasferimento dei dati è di prima generazione.
I meccanismi di cui alla parte B della presente appendice si applicano se en­
trambi i componenti del sistema tachigrafico coinvolti nell'autenticazione reci­
proca e/o nella procedura di trasferimento dei dati sono di seconda generazione.
L'appendice 15 fornisce maggiori informazioni in merito all'uso di componenti di
prima generazione in combinazione con componenti di seconda generazione.
PARTE A
SISTEMA TACHIGRAFICO DI PRIMA GENERAZIONE
1. INTRODUZIONE
1.1. Riferimenti
Nella presente appendice si rimanda alle seguenti norme:
SHA-1 National Institute of Standards and Technology (NIST).
FIPS Publication 180-1: Secure Hash Standard. April
1995.
PKCS1 RSA Laboratories. PKCS # 1: RSA Encryption Stan­
dard. Version 2.0. October 1998.
TDES National Institute of Standards and
Technology (NIST). FIPS Publication 46-3: Data En­
cryption Standard. Draft 1999.
TDES-OP ANSI X9.52, Triple Data Encryption Algorithm Mo­
des of Operation. 1998.
ISO/IEC 7816-4 Information Technology — Identification cards — In­
tegrated circuit(s) cards with contacts — Part 4: Inte­
rindustry commands for interexchange. First edition:
1995 + Amendment 1: 1997 (Tecnologie dell'informa­
zione — Carte di identificazione — Carte a circuito/i
integrato/i con contatti — Parte 4: Comandi interindu­
striali per l'interscambio. Prima edizione 1995 + Mo­
difica 1: 1997).
ISO/IEC 7816-6 Information Technology — Identification cards — In­
tegrated circuit(s) cards with contacts — Part 6: Inte­
rindustry data elements. First edition: 1996 + Cor 1:
1998 (Tecnologie dell'informazione — Carte di iden­
tificazione — Carte a circuito/i integrato/i con contatti
— Parte 6: Elementi di dati interindustriali. Prima
edizione 1996 + Cor 1: 1998).
ISO/IEC 7816-8 Information Technology — Identification cards — In­
tegrated circuit(s) cards with contacts — Part 8: Secu­
rity related interindustry commands. First edition 1999
(Tecnologie dell'informazione — Carte di identifica­
zione — Carte a circuito/i integrato/i con contatti —
Parte 8: Comandi interindustriali concernenti la sicu­
rezza. Prima edizione 1999).
ISO/IEC 9796-2 Information Technology — Security techniques —
Digital signature schemes giving message recovery
— Part 2: Mechanisms using a hash function. First
edition: 1997. (Tecnologie dell'informazione — Tecni­
che di sicurezza — Schemi per firme digitali con
recupero dei messaggi — Parte 2: Meccanismi che
usano una funzione di hash. Prima edizione 1997).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 428
ISO/IEC 9798-3 Information Technology — Security techniques —
Entity authentication mechanisms — Part 3: Entity
authentication using a public key algorithm. Second
edition 1998 (Tecnologie dell'informazione — Tecni­
che di sicurezza — Meccanismi di autenticazione di
entità — Parte 3: Autenticazione di entità con un
algoritmo a chiave pubblica. Seconda edizione 1998)
ISO 16844-3 Road vehicles — Tachograph systems — Part 3: Mo­
tion sensor interface (Veicoli stradali — Sistemi tachi­
grafici — Parte 3: Interfaccia del sensore di movi­
mento).
1.2. Simboli e abbreviazioni
Nella presente appendice sono stati usati i seguenti simboli e
abbreviazioni:
(K a , K b , K c ) insieme di chiavi usate dall'algoritmo di cifratura Tri­
ple Data Encryption Algorithm,
CA autorità di certificazione,
CAR riferimento dell'autorità di certificazione,
CC totale di controllo crittografico,
CG crittogramma,
CH intestazione del comando (Command Header),
CHA autorizzazione del titolare del certificato,
CHR riferimento del titolare del certificato,
D() decifrazione con DES,
DE elemento di dati (Data Element),
DO oggetto di dati (Data Object),
d chiave privata RSA, esponente privato,
e chiave pubblica RSA, esponente pubblico,
E() cifratura con DES,
EQT apparecchio,
Hash() valore di hash, un prodotto di Hash,
Hash funzione di hash,
KID identificativo della chiave,
Km chiave in TDES, chiave master (master key) definita
nella norma ISO 16844-3,
Km VU chiave in TDES inserita nell'unità elettronica di bordo
dei veicoli,
Km WC chiave in TDES inserita nella carta dell'officina,
m messaggio, un numero intero compreso tra 0 e n-1,
n chiavi RSA, modulo,
PB byte di riempimento,
PI byte indicatore di riempimento (da usare nel critto­
gramma per i DO di riservatezza),
PV valore in chiaro,
s firma, un numero intero compreso tra 0 e n-1,
SSC contatore sequenza di invio,
SM messaggistica sicura,
TCBC modalità di funzionamento a blocchi incatenati (Chi­
pher Block Chaining) del TDEA,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 429
TDEA algoritmo di cifratura Triple Data Encryption Algo­
rithm,
TLV valore lunghezza tag (Tag Length Value),
VU unità elettronica di bordo,
X.C certificato dell'utente X rilasciato da un'autorità di
certificazione,
X.CA autorità di certificazione dell'utente X,
X.CA.PK o X.C operazione di apertura di un certificato per estrarre
una chiave pubblica; si tratta di un operatore infisso,
il cui operando di sinistra è la chiave pubblica di
un'autorità di certificazione e il cui operando di destra
è il certificato rilasciato da tale autorità di certifica­
zione; il risultato è la chiave pubblica dell'utente X il
cui certificato è l'operando di destra,
X.PK chiave privata RSA di un utente X,
X.PK[I] cifratura RSA di un'informazione I, utilizzando la
chiave pubblica dell'utente X,
X.SK chiave privata RSA di un utente X,
X.SK[I] cifratura RSA di un'informazione I, utilizzando la
chiave privata dell'utente X,
«xx» valore esadecimale,
|| operatore di concatenamento.
2. SISTEMI E ALGORITMI CRITTOGRAFICI
2.1. Sistemi crittografici
CSM_001 Le unità elettroniche di bordo e le carte tachigrafiche devono
utilizzare un sistema crittografico RSA tradizionale a chiave
pubblica per fornire i seguenti meccanismi di sicurezza:
— autenticazione tra unità elettroniche di bordo e carte,
— trasporto di chiavi di sessione Triple-DES (TDES) tra
unità elettroniche di bordo e carte tachigrafiche,
— firma digitale dei dati trasferiti dalle unità elettroniche di
bordo o dalle carte tachigrafiche a dispositivi esterni.
CSM_002 Le unità elettroniche di bordo e le carte tachigrafiche devono
utilizzare un sistema di crittografia simmetrica Triple DES per
prevedere un meccanismo atto a garantire l'integrità dei dati
durante lo scambio di dati dell'utente tra unità elettroniche di
bordo e carte tachigrafiche e per garantire, se del caso, la
riservatezza dello scambio di dati tra unità elettroniche di
bordo e carte tachigrafiche.
2.2. Algoritmi crittografici
2.2.1 Algoritmo RSA
CSM_003 L'algoritmo RSA è interamente definito dalle seguenti
relazioni:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 430
X.SK[m] = s = m d mod n
X.PK[s] = m = s e mod n
Una descrizione più esauriente della funzione RSA è riportata
nel riferimento [PKCS1]. L'esponente pubblico e nei calcoli
dell'RSA è un numero intero compreso tra 3 e n-1 che soddi­
sfa la seguente equazione: gcd(e, lcm(p-1, q-1))=1.
2.2.2 Algoritmo di hash
CSM_004 I meccanismi di firma digitale devono utilizzare l'algoritmo di
hash SHA-1 definito nel riferimento [SHA-1].
2.2.3 Algoritmo di cifratura dei dati
CSM_005 Nella modalità di funzionamento a blocchi incatenati (Chipher
Block Chaining) occorre usare algoritmi basati su DES.
3. CHIAVI E CERTIFICATI
3.1. Generazione e distribuzione di chiavi
3.1.1 Generazione e distribuzione di chiavi RSA
CSM_006 Le chiavi RSA devono essere generate in base a tre livelli
gerarchici funzionali:
— livello europeo,
— livello di Stato membro,
— livello di apparecchio.
CSM_007 A livello europeo, deve essere generata un'unica coppia di
chiavi europee (EUR.SK e EUR.PK). La chiave privata euro­
pea deve essere usata per certificare le chiavi pubbliche degli
Stati membri. Devono essere conservate registrazioni di tutte
le chiavi certificate. Queste funzioni devono essere espletate
da un'autorità europea di certificazione, sotto l'autorità e la
responsabilità della Commissione europea.
CSM_008 A livello di Stato membro, deve essere generata una coppia di
chiavi dello Stato membro (MS.SK e MS.PK). Le chiavi
pubbliche degli Stati membri devono essere certificate dall'au­
torità europea di certificazione. La chiave privata degli Stati
membri deve essere usata per certificare le chiavi pubbliche
da inserire nell'apparecchio (unità elettronica di bordo o carta
tachigrafica). Devono essere conservate registrazioni di tutte
le chiavi pubbliche certificate insieme all'identificazione del­
l'apparecchio cui sono destinate. Queste funzioni devono es­
sere espletate da un'autorità di certificazione nazionale dello
Stato membro. Gli Stati membri possono cambiare periodica­
mente la propria coppia di chiavi.
CSM_009 A livello di apparecchio, deve essere generata e inserita in
ciascun apparecchio un'unica coppia di chiavi (EQT.SK e
EQT.PK). Le chiavi pubbliche degli apparecchi devono essere
certificate da un'autorità di certificazione nazionale dello Stato
membro. Queste funzioni possono essere espletate dai fabbri­
canti di apparecchi, dai centri che personalizzano gli apparec­
chi o dalle autorità degli Stati membri. Questa coppia di
chiavi è usata per l'autenticazione, la firma digitale e i servizi
di cifratura.
CSM_010 Durante la generazione, il trasporto (se del caso) e l'imma­
gazzinamento deve essere preservata la riservatezza delle
chiavi private.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 431
L'illustrazione seguente riepiloga il flusso di dati della sud­
detta procedura:
3.1.2 Chiavi di prova RSA
CSM_011 Ai fini delle prove dell'apparecchio (comprese le prove di
interoperabilità), l'autorità europea di certificazione deve ge­
nerare un'apposita diversa coppia di chiavi di prova europee e
almeno due coppie di chiavi di prova per ogni Stato membro,
le cui chiavi pubbliche devono essere certificate con la chiave
di prova privata europea. I fabbricanti devono inserire nell'ap­
parecchio sottoposto alle prove di omologazione chiavi di
prova certificate da una di tali chiavi di prova degli Stati
membri.
3.1.3 Chiavi per i sensori di movimento
La riservatezza delle tre chiavi Triple DES descritte di seguito deve
essere opportunamente garantita quando vengono generate, trasferite (se
del caso) e memorizzate.
Per assicurare la compatibilità con componenti di tachigrafi conformi alla
norma ISO 16844, l'autorità di certificazione europea e le autorità di
certificazione degli Stati membri devono inoltre garantire quanto segue:
CSM_036 l'autorità di certificazione europea deve generare KmVU e
KmWC, due chiavi Triple DES uniche e indipendenti, e la
chiave Km, come: Km = Km VU XOR Km WC . L'autorità di
certificazione europea deve inviare tali chiavi, applicando le op­
portune procedure di sicurezza, alle autorità di certificazione de­
gli Stati membri che ne fanno richiesta.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 432
CSM_037 Le autorità di certificazione degli Stati membri devono:
— utilizzare Km per crittare i dati relativi ai sensori di mo­
vimento richiesti dai produttori di tali sensori (i dati da
crittare con Km sono indicati nella norma ISO 16844-3),
— inviare Km VU ai fabbricanti delle unità elettroniche di
bordo, applicando le opportune procedure di sicurezza,
in modo che essi possano inserirla in tali unità,
— assicurare che Km WC sia inserita in tutte le carte di officina
( nel file elementare
) nel corso della perso­
nalizzazione della carta.
3.1.4 Generazione e distribuzione di chiavi T-DES
CSM_012 Nell'ambito della procedura di autenticazione reciproca, le
unità elettroniche di bordo e le carte tachigrafiche devono
generare e scambiare i dati necessari a elaborare una chiave
comune di sessione Triple DES. Per garantire la riservatezza,
tale scambio di dati deve essere protetto mediante un mecca­
nismo di cifratura RSA.
CSM_013 Questa chiave deve essere usata per tutte le successive ope­
razioni crittografiche che utilizzano la messaggistica sicura.
La sua validità deve scadere al termine della sessione (estra­
zione o reinizializzazione della carta) e/o dopo 240 impieghi
(un impiego della chiave = un comando che utilizza la mes­
saggistica sicura inviato alla carta e relativa risposta).
3.2. Chiavi
CSM_014 La lunghezza delle chiavi RSA deve essere la seguente (in­
dipendentemente dal livello): modulo n 1 024 bit, esponente
pubblico e 64 bit al massimo, esponente privato d 1 024 bit.
CSM_015 Le chiavi Triple DES devono avere il formato (K a , K b , K a ),
dove K a e K b sono chiavi indipendenti lunghe 64 bit. Non
deve essere impostato alcun bit di rilevamento dell'errore di
parità.
3.3. Certificati
CSM_016 I certificati delle chiavi pubbliche RSA devono essere verifi­
cabili mediante carta (card verifiable) e non autodescrittivi
(non self-descriptive) (rif.: ISO/CEI 7816-8)
3.3.1 Contenuto dei certificati
CSM_017 I certificati delle chiavi pubbliche RSA sono costruiti con i
dati sotto riportati nell'ordine seguente:
Dati Formato Byte Osservazioni
CPI INTEGER 1 Identificativo del profilo
del certificato («01» per
questa versione).
CAR OCTET
STRING
8 Riferimento dell'autorità di
certificazione.
CHA OCTET
STRING
7 Autorizzazione del titolare
del certificato.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 433
Dati Formato Byte Osservazioni
EOV TimeReal 4 Termine di validità del cer­
tificato. Facoltativo, riem­
pito con «FF» se non
utilizzato.
CHR OCTET
STRING
8 Riferimento del titolare del
certificato.
n OCTET
STRING
128 Chiave pubblica (modulo).
e OCTET
STRING
8 Chiave pubblica (espo­
nente pubblico).
164
Note:
1. L'«identificativo del profilo del certificato» (CPI) definisce la struttura
precisa di un certificato di autenticazione. Si può usare come un
identificativo interno all'apparecchio di un elenco di intestazioni (hea­
derlist) pertinente che descrive il concatenamento di elementi di dati
nel certificato.
L'elenco di intestazioni (headerlist) associato al contenuto di questo
certificato è il seguente:
«4D» «16» «5F
29»
«01» «42» «08» «5F
4B»
«07» «5F
24»
«04» «5F
20»
«08» «7F
49»
«05» «81» «81
80»
«82» «08»
Ta
g
el
en
co
d
i
in
te
st
az
io
ni
e
st
es
o
(E
xt
en
de
d
H
ea
de
rl
is
t
Ta
g)

L
un
gh
ez
za
e
le
nc
o
di
i
nt
es
ta
zi
on
i
Ta
g
C
P
I
L
un
gh
ez
za
C
P
I
Ta
g
C
A
R

L
un
gh
ez
za
C
A
R

Ta
g
C
H
A

L
un
gh
ez
za
C
H
A

Ta
g
E
O
V

L
un
gh
ez
za
E
O
V

Ta
g
C
H
R

L
un
gh
ez
za
C
H
R

Ta
g
ch
ia
ve
p
ub
bl
ic
a
(c
os
tr
ui
to
)
L
un
gh
ez
za
D
O
s
uc
ce
ss
iv
i
Ta
g
m
od
ul
o
L
un
gh
ez
za
m
od
ul
o
Ta
g
es
po
ne
nt
e
pu
bb
li
co

L
un
gh
ez
za
e
sp
on
en
te
p
ub
bl
ic
o
2. Il «riferimento dell'autorità di certificazione» (CAR) ha lo scopo di
identificare l'autorità di certificazione che rilascia il certificato, in
modo che l'elemento di dati si possa contemporaneamente usare
come un identificativo della chiave dell'autorità in riferimento alla
chiave pubblica dell'autorità di certificazione (per la codifica, cfr.
identificativo della chiave).
3. L'«autorizzazione del titolare del certificato» (CHA) è usata per iden­
tificare i diritti del titolare del certificato. È costituita dall'ID dell'ap­
plicazione tachigrafica e del tipo di apparecchio cui è destinato il
certificato (secondo l'elemento di dati , «00» per
uno Stato membro).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 434
4. Il «riferimento del titolare del certificato» (CHR) ha lo scopo di
identificare inequivocabilmente il titolare del certificato, in modo
che l'elemento di dati si possa contemporaneamente usare come un
identificativo della chiave di un soggetto in riferimento alla chiave
pubblica del titolare del certificato.
5. Gli identificativi delle chiavi identificano inequivocabilmente il tito­
lare del certificato o le autorità di certificazione. Sono codificati come
segue:
5.1. Apparecchio (VU o carta):
Dati Numero di
serie del­
l'apparec­
chio
Data Tipo Fabbricante
Lun­
ghezza
4 byte 2 byte 1 byte 1 byte
Valore Numero
intero
mm aa codifica
BCD
Specifico per
ciascun fabbri­
cante
Codice fabbri­
cante
Nel caso di una VU, il fabbricante, quando richiede i certificati,
può conoscere o meno l'identificazione dell'apparecchio in cui
saranno inserite le chiavi.
Nel primo caso, il fabbricante invia l'identificazione dell'apparec­
chio con la chiave pubblica all'autorità di certificazione del suo
Stato membro. Il certificato conterrà l'identificazione dell'appa­
recchio e il fabbricante deve garantire che le chiavi e il certificato
siano inseriti nell'apparecchio cui sono destinati. Il formato del­
l'identificativo della chiave è quello sopra riportato.
Nel secondo caso, il fabbricante deve identificare inequivocabil­
mente ciascuna richiesta di certificato e inviare tale identifica­
zione con la chiave pubblica all'autorità di certificazione del suo
Stato membro. Il certificato conterrà l'identificazione della richie­
sta. Il fabbricante deve comunicare all'autorità del suo Stato
membro l'assegnazione della chiave all'apparecchio (cioè identi­
ficazione della richiesta di certificato, identificazione dell'appa­
recchio) dopo l'installazione della chiave nell'apparecchio. L'iden­
tificativo della chiave ha il formato seguente:
Dati Numero di
serie ri­
chiesta
certificato
Data Tipo Fabbricante
Lun­
ghezza
4 byte 2 byte 1 byte 1 byte
Valore Numero
intero
mm aa codifica
BCD
«FF» Codice fabbri­
cante
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 435
5.2. Autorità di certificazione:
Dati Identificazione au­
torità
Numero di
serie chiave
Informazioni
supplementari
Identificativo
Lun­
ghezza
4 byte 1 byte 2 byte 1 byte
Valore 1 byte codice nu­
merico paese
3 byte codice al­
fanumerico paese
Numero in­
tero
Codifica ag­
giuntiva
(specifica per
CA)
«FF FF» se
non utilizzata
«01»
Il numero di serie della chiave è usato per distinguere le diverse
chiavi di uno Stato membro, nel caso in cui la chiave venga
cambiata.
6. I verificatori dei certificati devono sapere implicitamente che la chiave
pubblica certificata è una chiave RSA concernente l'autenticazione, la
verifica delle firme digitali e la cifratura per i servizi di riservatezza [il
certificato non contiene un identificativo di oggetto (object identifier)
che lo specifichi].
3.3.2 Rilascio dei certificati
CSM_018 Il certificato rilasciato è una firma digitale con recupero par­
ziale del contenuto del certificato conformemente alla norma
ISO/IEC 9796-2 (tranne l'allegato A4), con il CAR aggiunto
in coda.
X.C = X.CA.SK[«6A» || C r || Hash (Cc) || «BC»] || C n || X.CAR
Dove il contenuto del certificato
= Cc =
C r || C n
106 byte 58 byte
Note:
1. Questo certificato ha una lunghezza di 194 byte.
2. Il CAR, essendo nascosto dalla firma, è anche aggiunto in coda alla
firma, in modo da consentire di selezionare la chiave pubblica del­
l'autorità di certificazione per la verifica del certificato.
3. Il verificatore del certificato deve conoscere implicitamente l'algoritmo
usato dall'autorità di certificazione per firmare il certificato.
4. L'elenco di intestazioni associato al certificato rilasciato è il seguente:
«7F 21» «09» «5F 37» «81 80» «5F 38» «3A» «42» «08»
Ta
g
ce
rt
if
ic
at
o
C
V
(
co
st
ru
it
o)

L
un
gh
ez
za
D
O
s
uc
ce
ss
iv
i
Ta
g
fi
rm
a
L
un
gh
ez
za
f
ir
m
a
Ta
g
re
st
o
L
un
gh
ez
za
r
es
to

Ta
g
C
A
R

L
un
gh
ez
za
C
A
R

▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 436
3.3.3 Verifica e apertura dei certificati
La verifica e l'apertura dei certificati consistono nel verificare la firma in
base alla norma ISO/IEC 9796-2, recuperare il contenuto del certificato e
la chiave pubblica in esso contenuta: X.PK = X.CA.PK o X.C, e nel
verificare la validità del certificato.
CSM_019 La procedura prevede le fasi seguenti:
Verifica firma e recupero contenuto:
— da X.C recuperare Sign, C n ' e
CAR':
X.C = Sign || C n ' || CAR'
128 byte 58 byte 8 byte
— da CAR' selezionare la corretta chiave pubblica dell'auto­
rità di certificazione (se non ancora effettuato con altri
mezzi)
— aprire Sign con la chiave pubblica di CA: Sr'= X.CA.PK
[Sign],
— controllare che Sr' inizi con «6A» e termini con «BC»
— calcolare C r ' e H' da: Sr' = «6A» || C r ' || H' || «BC»
106 byte 20 byte
— recuperare il contenuto del certificato C' = C r «|| C n »
— controllare che Hash (C') = H'
Se i controlli danno esito positivo il certificato è autentico, il
suo contenuto è C'.
Verificare la validità. Da C':
— se applicabile, controllare data termine validità.
Recuperare e memorizzare la chiave pubblica, l'identificativo
della chiave, l'autorizzazione del titolare del certificato e il
termine di validità del certificato da C':
— X.PK = n || e
— X.KID = CHR
— X.CHA = CHA
— X.EOV = EOV
4. MECCANISMO DI AUTENTICAZIONE RECIPROCA
L'autenticazione reciproca tra le carte e le VU si basa sul principio
seguente:
ogni parte deve dimostrare all'altra di possedere una coppia di chiavi
valida, di cui la chiave pubblica è stata certificata da un'autorità di
certificazione di uno Stato membro, la quale è stata a sua volta certificata
dall'autorità di certificazione europea.
Tale dimostrazione è effettuata firmando con la chiave privata un numero
casuale inviato dall'altra parte, che deve recuperare il numero casuale
inviato quando verifica tale firma.
Il meccanismo è attivato dalla VU all'atto dell'inserimento della carta.
Inizia con lo scambio di certificati e l'apertura delle chiavi pubbliche e
termina con l'impostazione di una chiave di sessione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 437
CSM_020 Si deve utilizzare il seguente protocollo [le frecce indicano i
comandi e i dati scambiati (cfr. appendice 2)]:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 438
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 439
5. MECCANISMI DI RISERVATEZZA, INTEGRITÀ E AUTENTICA­
ZIONE DEI TRASFERIMENTI DI DATI TRA VU E CARTE
5.1. Messaggistica sicura (Secure Messaging)
CSM_021 L'integrità dei trasferimenti di dati tra VU e carte deve essere
protetta mediante messaggistica sicura (SM), in conformità
alle norme [ISO/IEC 7816-4] e [ISO/IEC 7816-8].
CSM_022 Quando è necessario proteggere i dati durante il trasferimento,
un oggetto di dati del totale di controllo crittografico (Cryp­
tographic Checksum Data Object) deve essere aggiunto in
coda agli oggetti di dati inviati all'interno del comando o della
risposta. Il totale di controllo crittografico deve essere verifi­
cato dal destinatario.
CSM_023 Il totale di controllo crittografico dei dati inviati all'interno di
un comando deve integrare l'intestazione del comando e tutti
gli oggetti di dati inviati (= > CLA = «0C», e tutti gli oggetti
di dati devono essere incapsulati con tag in cui b1 = 1).
CSM_024 I byte di informazione-stato della risposta devono essere pro­
tetti da un totale di controllo crittografico quando la risposta
non contiene campi di dati.
CSM_025 I totali di controllo crittografico devono avere una lunghezza
di 4 byte.
Quando si usa la messaggistica sicura, la struttura dei co­
mandi e delle risposte è quindi la seguente:
i DO utilizzati sono una serie parziale dei DO della messaggi­
stica sicura descritti nella norma ISO/IEC 7816-4:
Tag Mnemonico Significato
«81» T PV Valore in chiaro, dati non codificati BER-TLV (da
proteggere con CC)
«97» T LE Valore di Le nel comando non sicuro (da proteggere
con CC)
«99» T SW Informazione-stato (da proteggere con CC)
«8E» T CC Totale di controllo crittografico
«87» T PI CG Byte indicatore di riempimento || Crittogramma (va­
lore in chiaro, non codificato in BER-TLV)
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 440
Data una coppia comando-risposta non sicuri:
Intestazione comando Contenuto comando
CLA INS P1 P2 [Campo L c ] [Campo dati] [Campo L e ]
quattro byte L byte, indicati come B 1 — B L
Corpo della risposta Coda della risposta
[Campo dati] SW1 SW2
Byte dati L r due byte
La corrispondente coppia comando-risposta sicuri è:
Comando sicuro:
Intestazione comando (CH) Contenuto comando
CLA INS P1 P2 [Nuovo campo
L c ]
[Nuovo campo dati] [Nuovo
campo
L e ]
«OC» Lunghezza
Nuovo campo
dati
T PV L PV PV T LE L LE L e T CC L CC CC «00»
«81» L c Campo dati «97» «01» L e «8E» «04» CC
Dati da integrare nel totale di controllo = CH || PB || T PV ||
L PV || PV || T LE || L LE || L e || PB
PB = Byte di riempimento (80 .. 00), in base alle norme
ISO-IEC 7816-4 e ISO 9797, metodo 2.
DO PV e LE sono presenti solo se sono presenti dati corri­
spondenti nel comando non sicuro.
Risposta sicura:
1. Caso in cui il campo dati della risposta non è vuoto e non
deve essere protetto a fini di riservatezza:
Corpo della risposta Coda della risposta
[Nuovo campo dati] Nuovi SW1 SW2
T PV L PV PV T CC L CC CC
«81» L r Campo dati «8E» «04» CC
Dati da integrare nel totale di controllo = T PV || L PV || PV || PB
2. Caso in cui il campo dati della risposta non è vuoto e deve
essere protetto a fini di riservatezza:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 441
Corpo della risposta Coda della risposta
[Nuovo campo dati] Nuovi SW1 SW2
T PI CG L PI
CG
PI CG T CC L CC CC
«87» PI || CG «8E» «04» CC
Dati da trasportare da CG: dati non codificati BER-TLV e
byte di riempimento.
Dati da integrare nel totale di controllo = T PI CG || L PI CG ||
PI CG || PB
3. Caso in cui il campo dati della risposta è vuoto:
Corpo della risposta Coda della risposta
[Nuovo campo dati] Nuovi SW1 SW2
T SW L SW SW T CC L CC CC
«99» «02» Nuovi SW1 SW2 «8E» «04» CC
Dati da integrare nel totale di controllo = T SW || L SW || SW
|| PB
5.2. Trattamento degli errori della messaggistica sicura
CSM_026 Quando la carta tachigrafica riconosce un errore di SM du­
rante l'interpretazione di un comando, i byte di stato devono
essere restituiti senza SM. Secondo la norma ISO/IEC 7816-4,
i seguenti byte di stato sono definiti come indicazioni di
errore di SM:
«66 88»: verifica di un totale di controllo crittografico fallita,
«69 87»: oggetti di dati SM previsti mancanti,
«69 88»: oggetti di dati SM non corretti.
CSM_027 Quando la carta tachigrafica restituisce i byte di stato senza
DO SM o con un DO SM errato, la sessione deve essere
annullata dalla VU.
5.3. Algoritmo per il calcolo di totali di controllo crittografico
CSM_028 I totali di controllo crittografico sono costruiti utilizzando un
retail MAC, secondo ANSI X9.19, con DES:
— fase iniziale: il blocco di controllo iniziale y0 è E(Ka,
SSC);
— fase sequenziale: i blocchi di controllo y1, .., yn sono
calcolati usando Ka;
— fase finale: il totale di controllo crittografico è calcolato in
base all'ultimo blocco di controllo yn come segue: E(Ka,
D(Kb, yn)).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 442
dove E() significa cifratura con DES e D() significa decifra­
zione con DES.
Vengono trasferiti i quattro byte più significativi del totale di
controllo crittografico.
CSM_029 Il contatore sequenza di invio (SSC) deve essere inizializzato
durante la procedura di accordo sulla chiave (key agreement
procedure):
SSC iniziale: Rnd3 (4 byte meno significativi) || Rnd1 (4 byte
meno significativi).
CSM_030 Il contatore sequenza di invio va aumentato di un'unità prima di
ogni calcolo del MAC (cioè, l'SSC per il primo comando è SSC
iniziale + 1, l'SSC per la prima risposta è SSC iniziale + 2).
La figura seguente illustra il calcolo del retail MAC:
5.4. Algoritmo per il calcolo di crittogrammi dei DO di riservatezza
CSM_031 I crittogrammi sono calcolati utilizzando il TDEA nella mo­
dalità di funzionamento TCBC, secondo i riferimenti [TDES]
e [TDES-OP] e con il vettore nullo come blocco valore
iniziale.
La figura seguente illustra l'applicazione di chiavi in TDES:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 443
6. MECCANISMI DI FIRMA DIGITALE PER IL TRASFERIMENTO
DEI DATI
CSM_032 L'apparecchio intelligente dedicato (Intelligent dedicated
equipment — IDE) memorizza in un file di dati fisico i
dati ricevuti da un apparecchio (VU o carta) durante una
sessione di trasferimento. Tale file deve contenere i certificati
MS i .C e EQT.C. Il file contiene firme digitali dei blocchi di
dati secondo quanto specificato nell'appendice 7 «Protocolli
di trasferimento dei dati».
CSM_033 Per le firme digitali dei dati trasferiti occorre adoperare uno
schema di firma digitale con appendice tale che i dati trasferiti
possano, se del caso, essere letti senza necessità di
decifrazione.
6.1. Generazione della firma
CSM_034 La generazione di firme dei dati da parte dell'apparecchio
deve seguire lo schema di firma con appendice definito nel
riferimento [PKCS1] con la funzione di hash SHA-1:
Firma = EQT.SK[«00» || «01» || PS || «00» || DER(SHA-
1(Data))]
PS = stringa di riempimento di ottetti con valore «FF» in
modo che la lunghezza sia 128.
DER(SHA-1(M)) è la codifica dell'algoritmo ID per la fun­
zione di hash e il valore di hash in un valore ASN.1 di tipo
DigestInfo (regole di codifica distinte):
«30»||«21»||«30»||«09»||«06»||«05»||«2B»||«0E»|| «03»||«02»||«­
1A»||
«05»||«00» «04»||«14»||valore di hash.
6.2. Verifica della firma
CSM_035 La verifica della firma dei dati sui dati trasferiti deve seguire
lo schema di firma con appendice definito nel riferimento
[PKCS1] con la funzione di hash SHA-1.
La chiave pubblica europea EUR.PK deve essere nota al
verificatore in modo indipendente (e attendibile).
La tabella seguente illustra il protocollo che può seguire un
IDE in cui sia stata inserita una carta di controllo per verifi­
care l'integrità dei dati trasferiti e memorizzati nell'ESM (ex­
ternal storage media — dispositivo di memorizzazione
esterno). La carta di controllo è usata per la decifrazione delle
firme digitali. In questo caso, tale funzione può non essere
implementata nell'IDE.
L'apparecchio che ha trasferito e firmato i dati da analizzare è
indicato con EQT.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 444
PARTE B
SISTEMA TACHIGRAFICO DI SECONDA GENERAZIONE
7. INTRODUZIONE
7.1. Riferimenti
In questa parte della presente appendice si rimanda alle seguenti norme.
AES National Institute of Standards and Technology (NIST), FIPS
PUB 197: Advanced Encryption Standard (AES), November
26, 2001
DSS National Institute of Standards and Technology (NIST), FIPS
PUB 186-4: Digital Signature Standard (DSS), July 2013
ISO 7816-4 ISO/IEC 7816-4, Identification cards — Integrated circuit
cards — Part 4: Organization, security and commands for
interchange. Third edition 2013-04-15 (ISO/IEC 7816-4,
Carte di identificazione — Carte a circuito/i integrato/i —
Parte 4: Organizzazione, sicurezza e comandi per l'inter­
scambio. Terza edizione 2013-04-15).
ISO 7816-8 ISO/IEC 7816-8, Identification cards — Integrated circuit
cards — Part 8: Commands for security operations. Se­
cond edition 2004-06-01 (ISO/IEC 7816-8, Carte di iden­
tificazione — Carte a circuito/i integrato/i — Parte 8:
Comandi per le operazioni di sicurezza. Seconda edizione
2004-06-01).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 445
ISO 8825-1 ISO/IEC 8825-1, Information technology — ASN.1 en­
coding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Di­
stinguished Encoding Rules (DER). Fourth edition, 2008-
12-15 [ISO/IEC 8825-1, Tecnologie dell'informazione —
Regole di codifica ASN.1: specifiche delle regole di co­
difica di base (BER), regole di codifica canonica (CER) e
regole di codifica distinta (DER). Quarta edizione 2008-
12-15].
ISO 9797-1 ISO/IEC 9797-1, Information technology — Security te­
chniques — Message Authentication Codes (MACs) —
Part 1: Mechanisms using a block cipher. Second edition,
2011-03-01 [ISO/IEC 9797-1, Tecnologie dell'informa­
zione — Tecniche di sicurezza — Codici di autentica­
zione del messaggio (MAC) — Parte 1: Meccanismi
che usano una cifratura a blocchi. Seconda edizione
2011-03-01].
ISO 10116 ISO/IEC 10116, Information technology — Security te­
chniques — Modes of operation of an n-bit block cipher.
Third edition, 2006-02-01 (ISO/IEC 10116, Tecnologie
dell'informazione — Tecniche di sicurezza — Modalità
di funzionamento di una cifratura a blocchi a n-bit. Terza
edizione 2006-02-01)
ISO 16844-3 ISO/IEC 16844-3, Road vehicles — Tachograph systems
— Part 3: Motion sensor interface. First edition 2004,
including Technical Corrigendum 1 2006 ((ISO/IEC
16844-3, Veicoli stradali — Sistemi tachigrafici — Parte
3: Interfaccia del sensore di movimento. Prima edizione
2004, compresa rettifica tecnica 1 2006).
RFC 5480 Elliptic Curve Cryptography Subject Public Key Informa­
tion, March 2009
RFC 5639 Elliptic Curve Cryptography (ECC) — Brainpool Stan­
dard Curves and Curve Generation, 2010
RFC 5869 HMAC-based Extract-and-Expand Key Derivation
Function (HKDF), May 2010
SHS National Institute of Standards and Technology (NIST),
FIPS PUB 180-4: Secure Hash Standard, March 2012
SP 800-38B National Institute of Standards and Technology (NIST),
Special Publication 800-38B: Recommendation for Block
Cipher Modes of Operation: The CMAC Mode for Au­
thentication, 2005
TR-03111 BSI Technical Guideline TR-03111, Elliptic Curve Cryp­
tography, version 2.00, 2012-06-28
7.2. Simboli e abbreviazioni
Nella presente appendice sono stati usati i seguenti simboli e
abbreviazioni:
AES algoritmo di cifratura Advanced Encryption Standard
CA autorità di certificazione
CAR riferimento dell'autorità di certificazione
CBC modalità di funzionamento a blocchi incatenati (Chipher
Block Chaining)
CH intestazione comando
CHA autorizzazione del titolare del certificato
CHR riferimento del titolare del certificato
CV vettore costante
DER regole di codifica distinte (Distinguished Encoding Rules)
DO oggetto di dati (Data Object)
DSRC comunicazione dedicata a corto raggio
ECC crittografia a curve ellittiche
ECDSA algoritmo di firma digitale su curva ellittica
ECDH curva ellittica Diffie-Hellman [algoritmo di accordo sulla
chiave (key agreement algorithm)]
EGF dispositivo GNSS esterno
EQT apparecchio
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 446
IDE apparecchio intelligente dedicato (Intelligent Dedicated
Equipment):
K M chiave master del sensore di movimento che consente l'ab­
binamento (pairing) di un'unità elettronica di bordo (VU) a
un sensore di movimento
K M-VU chiave inserita nelle VU che consente a una VU di ricavare
la chiave master del sensore di movimento se una carta
dell'officina è inserita nella VU
K M-WC chiave inserita nelle carte dell'officina che consente a una
VU di ricavare la chiave master del sensore di movimento
se una carta dell'officina è inserita nella VU
MAC codice di autenticazione del messaggio
MoS sensore di movimento
MSB bit più significativo
PKI infrastruttura a chiave pubblica
RCF dispositivo di comunicazione remota
SSC contatore sequenza di invio
SM messaggistica sicura
TDES standard di cifratura Triple Date (Triple Data Encryption
Standard)
TLV valore lunghezza tag (Tag Length Value)
VU unità elettronica di bordo
X.C certificato di chiave pubblica dell'utente X
X.CA autorità di certificazione che ha rilasciato il certificato del­
l'utente X
X.CAR riferimento dell'autorità di certificazione citata nel certifi­
cato dell'utente X
X.CHR riferimento del titolare del certificato citato nel certificato
dell'utente X
X.PK chiave pubblica dell'utente X
X.SK chiave privata dell'utente X
X.PK eph chiave pubblica temporanea (ephemeral public key) del­
l'utente X
X.SK eph chiave privata temporanea (ephemeral private key) del­
l'utente X
«xx» valore esadecimale
|| operatore di concatenamento
7.3. Definizioni
Le definizioni dei termini usati nella presente appendice sono riportate
nella sezione I dell'allegato 1C.
8. SISTEMI E ALGORITMI CRITTOGRAFICI
8.1. Sistemi crittografici
CSM_38 Le unità elettroniche di bordo e le carte tachigrafiche de­
vono utilizzare un sistema crittografico a chiave pubblica
basato su curve ellittiche per fornire i seguenti servizi di
sicurezza:
— autenticazione reciproca tra un'unità elettronica di
bordo e una carta,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 447
— accordo di chiavi di sessione AES tra un'unità elettro­
nica di bordo e una carta,
— garantire l'autenticità, l'integrità e la non disconoscibi­
lità dei dati trasferiti dalle unità elettroniche di bordo o
dalle carte tachigrafiche a dispositivi esterni.
CSM_39 Le unità elettroniche di bordo e i dispositivi GNSS esterni
devono utilizzare un sistema crittografico a chiave pub­
blica basato su curve ellittiche per fornire i seguenti servizi
di sicurezza:
— accoppiamento di un'unità elettronica di bordo a un
dispositivo GNSS esterno,
— autenticazione reciproca tra un'unità elettronica di
bordo a un dispositivo GNSS esterno,
— accordo di una chiave di sessione AES tra un'unità
elettronica di bordo e un dispositivo GNSS esterno,
CSM_40 Le unità elettroniche di bordo e le carte tachigrafiche de­
vono utilizzare un sistema crittografico simmetrico basato
su AES per fornire i seguenti servizi di sicurezza:
— garantire l'autenticità e l'integrità dei dati scambiati tra
un'unità elettronica di bordo e una carta tachigrafica,
— se del caso, garantire la riservatezza dei dati scambiati
tra un'unità elettronica di bordo e una carta
tachigrafica.
CSM_41 Le unità elettroniche di bordo e i dispositivi GNSS esterni
devono utilizzare un sistema crittografico simmetrico ba­
sato su AES per fornire i seguenti servizi di sicurezza:
— garantire l'autenticità e l'integrità dei dati scambiati tra
un'unità elettronica di bordo e una dispositivo GNSS
esterno.
CSM_42 Le unità elettroniche di bordo e i sensori di movimento
devono utilizzare un sistema crittografico simmetrico ba­
sato su AES per fornire i seguenti servizi di sicurezza:
— abbinamento di un'unità elettronica di bordo a un sen­
sore di movimento,
— autenticazione reciproca tra un'unità elettronica di
bordo e un sensore di movimento,
— garantire la riservatezza dei dati scambiati tra un'unità
elettronica di bordo e un sensore di movimento.
CSM_43 Le unità elettroniche di bordo e le carte di controllo de­
vono utilizzare un sistema crittografico simmetrico basato
su AES per fornire i seguenti servizi di sicurezza sull'in­
terfaccia di comunicazione remota:
— garantire la riservatezza, l'autenticità e l'integrità dei
dati trasmessi da un'unità elettronica di bordo a una
carta di controllo.
Note:
— in realtà i dati sono trasmessi da una unità elettronica di
bordo (VU) a un interrogatore remoto, sotto il controllo di
un agente incaricato, che utilizza un dispositivo di comu­
nicazione remota che può essere interno o esterno alla VU,
cfr. appendice 14. L'interrogatore remoto tuttavia
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 448
invia i dati ricevuti a una carta di controllo per la decifra­
zione e la convalida dell'autenticità. Dal punto di vista
della sicurezza, il dispositivo di comunicazione remota e
l'interrogatore remoto sono completamente trasparenti.
— Per l'interfaccia DSRC una carta dell'officina offre gli
stessi servizi di sicurezza di una carta di controllo. Ciò
consente all'officina di convalidare il corretto funziona­
mento dell'interfaccia di comunicazione remota della
VU, sicurezza inclusa. Per maggiori informazioni si
veda la sezione 9.2.2.
8.2. Algoritmi crittografici
8.2.1 Algoritmi simmetrici
CSM_44 Le unità elettroniche di bordo, le carte tachigrafiche, i
sensori di movimento e i dispositivi GNSS esterni devono
essere compatibili con l'algoritmo AES, come definito nel
riferimento [AES], con chiavi lunghe 128, 192 e 256 bit.
8.2.2 Algoritmi asimmetrici e parametri di dominio standardizzati (standardi­
zed domain parameters)
CSM_45 Le unità elettroniche di bordo, le carte tachigrafiche e i
dispositivi GNSS esterni devono essere compatibili con la
crittografia a curve ellittiche con chiavi lunghe 256, 384 e
512/521 bit.
CSM_46 Le unità elettroniche di bordo, le carte tachigrafiche e i
dispositivi GNSS esterni devono essere compatibili con
l'algoritmo di firma ECDSA, come specificato in [DSS].
CSM_47 Le unità elettroniche di bordo, le carte tachigrafiche e i
dispositivi GNSS esterni devono essere compatibili con
l'algoritmo di accordo sulla chiave (key agreement algo­
rithm) ECKA-EG, come specificato in [TR 03111].
CSM_48 Le unità elettroniche di bordo, le carte tachigrafiche e i
dispositivi GNSS esterni devono essere compatibili con
tutti i parametri di dominio standardizzati specificati nella
Tabella 1 seguente per la crittografia a curve ellittiche.
Tabella 1
Parametri di dominio standardizzati
Nome Dimensioni (bit) Riferimento Identificativo di oggetto
NIST P-256 256 [DSS], [RFC 5480]
BrainpoolP256r1 256 [RFC 5639]
NIST P-384 384 [DSS], [RFC 5480]
BrainpoolP384r1 384 [RFC 5639]
BrainpoolP512r1 512 [RFC 5639]
NIST P-521 521 [DSS], [RFC 5480]
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 449
Nota: gli identificativi di oggetto (object identifiers) nel­
l'ultima colonna della Tabella 1 sono specificati in [RFC
5639] per le curve Brainpool e in [RFC 5480] per le curve
NIST.
8.2.3 Algoritmi di hash
▼M1
CSM_49 Le unità elettroniche di bordo, le carte tachigrafiche e i
dispositivi GNSS esterni devono essere compatibili con gli
algoritmi SHA-256, SHA-384 e SHA-512, come specifi­
cato in [SHS].
▼B
8.2.4 Suite crittografiche (cipher suites)
CSM_50 Nel caso un algoritmo simmetrico, un algoritmo asimme­
trico e/o un algoritmo di hash siano usati insieme per
costituire un protocollo di sicurezza, le lunghezze delle
rispettive chiavi e le dimensioni degli hash devono avere
(approssimativamente) la stessa forza. Tabella 2 indica le
suite crittografiche consentite:
Tabella 2
Suite crittografiche consentite
Id della suite critto­
grafica
Dimensioni della
chiave ECC (in bit)
Lunghezza della chiave
AES (in bit)
Algoritmo di hash
Lunghezza MAC
(in byte)
CS#1 256 128 SHA-256 8
CS#2 384 192 SHA-384 12
CS#3 512/521 256 SHA-512 16
Nota: le chiavi ECC delle dimensioni di 512 bit e 521 bit
sono considerate di pari forza per tutti gli scopi previsti
nella presente appendice.
9. CHIAVI E CERTIFICATI
9.1. Coppie di chiavi asimmetriche e certificati delle chiavi pubbliche
9.1.1 Principi generali
Nota: le chiavi descritte nella presente sezione sono usate per l'autenti­
cazione reciproca e la messaggistica sicura tra unità elettroniche di bordo
e carte tachigrafiche e tra unità elettroniche di bordo e dispositivi GNSS
esterni. Queste procedure sono descritte in dettaglio nei capitoli 10 e 11
della presente appendice.
CSM_51 Nell'ambito del sistema tachigrafico intelligente europeo, le
coppie di chiavi ECC e i certificati corrispondenti devono
essere creati e gestiti in base a tre livelli gerarchici
funzionali:
— livello europeo,
— livello di Stato membro,
— livello di apparecchio.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 450
CSM_52 Nell'ambito del sistema tachigrafico intelligente europeo, le
chiavi pubbliche e private e i certificati devono essere
generati, gestiti e comunicati usando metodi standardizzati
e sicuri.
9.1.2 Livello europeo
CSM_53 A livello europeo, deve essere generata una sola coppia di
chiavi uniche ECC designata come EUR che si compone
di una chiave privata (EUR.SK) e di una
chiave pubblica EUR.PK. Questa coppia di chiavi deve
costituire la coppia di chiavi radice (root) dell'intero del
tachigrafo intelligente europeo PKI. Queste funzioni de­
vono essere espletate dall'Autorità europea di certificazione
primaria (European Root Certificate Authority — ERCA),
sotto l'autorità e la responsabilità della Commissione
europea.
CSM_54 La ERCA deve usare la chiave privata europea per firmare
un certificato radice (autofirmato) della chiave pubblica
europea e deve comunicare tale certificato radice a tutti
gli Stati membri.
CSM_55 La ERCA deve usare la chiave privata europea per firmare,
su richiesta, i certificati delle chiavi pubbliche degli Stati
membri. La ERCA deve registrare tutti i certificati firmati
delle chiavi pubbliche di uno Stato membro.
CSM_56 Come indicato nella Figura 1, sezione 9.1.7, la ERCA
deve generare una nuova coppia di chiavi radice europee
ogni 17 anni. Ogni volta che ciò accade, la ERCA deve
creare un nuovo certificato radice autofirmato per la nuova
chiave pubblica europea. Il periodo di validità di un certi­
ficato radice europeo deve essere di 34 anni più 3 mesi.
Nota: l'introduzione di una nuova coppia di chiavi radice
implica inoltre che la ERCA genererà una nuova chiave
master del sensore di movimento e una nuova chiave ma­
ster DSRC, cfr. le sezioni 9.2.1.2 e 9.2.2.2.
CSM_57 Prima di generare una nuova coppia di chiavi radice euro­
pee, la ERCA deve effettuare un'analisi della forza critto­
grafica necessaria per la nuova coppia di chiavi, dato che
essa dovrebbe restare sicura per i successivi 34 anni. Se
ritenuto necessario, la ERCA deve passare a una suite
crittografica più forte di quella attuale, come specificato
in CSM_50.
▼M1
CSM_58 Ogni volta che si crea una nuova coppia di chiavi radice
europee, la ERCA deve creare un certificato di collega­
mento (link certificate) per la nuova chiave pubblica euro­
pea e deve firmarlo con la precedente chiave privata eu­
ropea. Il periodo di validità di un certificato di collega­
mento deve essere di 17 anni più 3 mesi. Anch’esso è
indicato nella figura 1, sezione 9.1.7.
▼B
Nota: poiché un certificato di collegamento contiene la
chiave pubblica ERCA della generazione X ed è firmato
con la chiave privata ERCA della generazione X-1, un
certificato di collegamento consente agli apparecchi della
generazione X-1 di considerare sicuri gli apparecchi della
generazione X.
CSM_59 Non appena un nuovo certificato di chiavi radice diventa
valido, la ERCA non deve usare la chiave privata di una
coppia di chiavi radice per nessuno scopo.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 451
CSM_60 In qualsiasi momento, la ERCA deve disporre dei seguenti
certificati e chiavi crittografiche:
— la coppia di chiavi EUR attuale e il certificato
corrispondente;
— tutti i precedenti certificati EUR da usare per la verifica
dei certificati MSCA che sono ancora validi;
— i certificati di collegamento per tutte le generazioni
di certificati EUR, eccetto la prima.
9.1.3 Livello di Stato membro
CSM_61 A livello di Stato membro, tutti gli Stati membri tenuti a
firmare i certificati della carta tachigrafica devono generare
una o più coppie di chiavi uniche ECC designate come
MSCA_card. Tutti gli Stati membri tenuti a firmare i cer­
tificati per le unità elettroniche di bordo o i dispositivi
GNSS esterni devono inoltre generare una o più coppie
di chiavi uniche ECC designate come MSCA_VU-EGF.
CSM_62 Il compito di generare le coppie di chiavi dello Stato
membro spetta all'autorità di certificazione dello Stato
membro (Member State Certificate Authority — MSCA).
Ogni volta che genera una coppia di chiavi dello Stato
membro, la MSCA è tenuta a inviare la chiave pubblica
alla ERCA in modo che quest'ultima possa firmare un
corrispondente certificato dello Stato membro.
CSM_63 La forza di una coppia di chiavi dello Stato membro è
scelta dalla MSCA e deve essere uguale alla forza della
coppia di chiavi radice europee usate per firmare il corri­
spondente certificato dello Stato membro.
CSM_64 Una coppia di chiavi MSCA_VU-EGF, se presente, deve
comporsi di una chiave privata MSCA_VU-EGF.SK e di
una chiave pubblica MSCA_VU-EGF.PK. La MSCA deve
usare la chiave privata MSCA_VU-EGF.SK solo per fir­
mare i certificati della chiave pubblica delle unità elettro­
niche di bordo e dei dispositivi GNSS esterni.
CSM_65 Una coppia di chiavi MSCA_Card deve comporsi di una
chiave privata MSCA_Card.SK e di una chiave pubblica
MSCA_Card.PK. La MSCA deve usare la chiave privata
MSCA_Card.SK esclusivamente per firmare i certificati
della chiave pubblica delle carte tachigrafiche.
CSM_66 La MSCA deve registrare tutti i certificati firmati della
VU, del dispositivo GNSS esterno e della carta tachigra­
fica, insieme all'identificazione dell'apparecchio cui è de­
stinato ciascun certificato.
CSM_67 Il periodo di validità di un certificato MSCA_VU-EGF
deve essere di 17 anni più 3 mesi. Il periodo di validità
di un certificato MSCA_Card deve essere di 7 anni più 1
mese.
CSM_68 Come indicato nella Figura 1, sezione 9.1.7, la chiave
privata di una coppia di chiavi MSCA_VU-EGF e la
chiave privata di una coppia di chiavi MSCA_Card de­
vono avere un periodo di utilizzo di due anni.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 452
CSM_69 Dopo la fine del periodo di utilizzo, la MSCA non deve
usare la chiave privata di una coppia di chiavi MSCA_VU-
EGF per nessuno scopo. Allo stesso modo, dopo la fine
del periodo di utilizzo, la MSCA non deve usare la chiave
privata di una coppia di chiavi MSCA_Card per nessuno
scopo.
CSM_70 In qualsiasi momento, la MSCA deve disporre dei seguenti
certificati e chiavi crittografiche:
— la coppia di chiavi MSCA_Card attuale e il certificato
corrispondente;
— tutti i precedenti certificati MSCA_Card da usare per la
verifica dei certificati delle carte tachigrafiche che sono
ancora validi;
— il certificato EUR attuale necessario alla verifica del
certificato MSCA attuale;
— tutti i precedenti certificati EUR necessari alla verifica
dei certificati MSCA che sono ancora validi;
CSM_71 Se una MSCA deve firmare certificati per VU o per di­
spositivi GNSS esterni, essa deve inoltre disporre dei se­
guenti certificati e chiavi:
— la coppia di chiavi MSCA_VU-EGF attuali e il certi­
ficato corrispondente;
— tutte le precedenti chiavi pubbliche MSCA_VU-EGF
da usare per la verifica dei certificati delle VU o dei
dispositivi GNSS esterni che sono ancora validi.
9.1.4 Livello di apparecchio: unità elettroniche di bordo (VU)
▼M1
CSM_72 Per ciascuna unità elettronica di bordo devono essere ge­
nerate due coppie di chiavi uniche ECC, denominate
VU_MA e VU_Sign. Questo compito spetta ai fabbricanti
di VU. Ogniqualvolta si genera una coppia di chiavi della
VU, la parte che genera la chiave deve inviare la chiave
pubblica alla MSCA di competenza, in modo da ottenere il
certificato VU corrispondente firmato dalla MSCA. La
chiave privata deve essere usata solo dall’unità elettronica
di bordo.
▼B
CSM_73 I certificati VU_MA e VU_Sign di una determinata unità
elettronica di bordo devono avere la stessa data di efficacia
(Certificate Effective Date).
CSM_74 La forza di una coppia di chiavi della VU è scelta dal
fabbricante della VU e deve essere uguale alla forza della
coppia di chiavi MSCA usate per firmare il corrispondente
certificato della VU.
CSM_75 Una unità elettronica di bordo deve usare la propria coppia
di chiavi VU_MA, composta da una chiave privata
VU_MA.SK e da una chiave pubblica VU_MA.PK, esclu­
sivamente per l'autenticazione della VU rispetto alle carte
tachigrafiche e ai dispositivi GNSS esterni, come specifi­
cato nelle sezioni 10.3 e 11.4 della presente appendice.
CSM_76 Una unità elettronica di bordo deve essere in grado di
generare coppie di chiavi ECC temporanee e deve utiliz­
zare una coppia di chiavi temporanee esclusivamente per
eseguire l'accordo sulla chiave di sessione con una carta
tachigrafica o con un dispositivo GNSS esterno, come
specificato nelle sezioni 10.4 e 11.4 della presente
appendice.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 453
CSM_77 Una unità elettronica di bordo deve usare la chiave privata
VU_Sign.SK della coppia di chiavi VU_Sign esclusiva­
mente per firmare i file di dati trasferiti, come specificato
nel capitolo 14 della presente appendice. La corrispondente
chiave pubblica VU_Sign.PK deve essere usata esclusiva­
mente per verificare le firme create dall'unità elettronica di
bordo.
CSM_78 Come mostrato in Figura 1, sezione 9.1.7, il periodo di
validità di un certificato VU_MA deve essere di 15 anni
più 3 mesi. Anche il periodo di validità di un certificato
VU_Sign deve essere di 15 anni e 3 mesi.
Note:
— l'estensione del periodo di validità di un certificato
VU_sign consente a una VU di creare firme valide
per i dati trasferiti nel corso dei primi tre mesi dopo
la sua scadenza, come previsto nel regolamento (UE)
n. 581/2010.
— L'estensione del periodo di validità di un certificato
VU_MA è necessaria per consentire alla VU di auten­
ticare una carta di controllo o una carta dell'azienda
durante i primi tre mesi dopo la sua scadenza, in
modo che sia possibile effettuare un trasferimento di
dati.
CSM_79 Dopo la scadenza del certificato corrispondente, l'unità
elettronica di bordo non deve usare la chiave privata di
una coppia di chiavi della VU per nessuno scopo.
CSM_80 Le coppie di chiavi della VU (eccetto le coppie di chiavi
temporanee) e i certificati corrispondenti di una determi­
nata unità elettronica di bordo non devono essere sostituiti
o rinnovati sul campo una volta che l'unità elettronica di
bordo è stata messa in funzione.
Note:
— Le coppie di chiavi temporanee non sono interessate da
questo requisito, poiché a ogni esecuzione della auten­
ticazione del chip (Chip Authentication) e dell'accordo
sulla chiave di sessione (session key agreement) la VU
genera una nuova coppia di chiavi temporanee, cfr.
sezione 10.4. Si segnala che le coppie di chiavi tem­
poranee non hanno certificati corrispondenti.
— Tale requisito non impedisce la sostituzione delle cop­
pie di chiavi statiche della VU nel corso di un ricon­
dizionamento o di una riparazione in un ambiente si­
curo, controllato dal fabbricante della VU.
CSM_81 Al momento della messa in funzione, le unità elettroniche
di bordo devono contenere i seguenti certificati e chiavi
crittografiche:
— la chiave privata VU_MA e il certificato
corrispondente;
— la chiave privata VU_Sign e il certificato
corrispondente;
— il certificato MSCA_VU-EGF contenente la chiave
pubblica MSCA_VU-EGF.PK da usare per la verifica
del certificato VU_MA e del certificato VU_Sign;
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 454
— il certificato EUR contenente la chiave pubblica
EUR.PK da usare per la verifica del certificato
MSCA_VU-EGF;
— il certificato EUR il cui periodo di validità precede
direttamente il periodo di validità del certificato EUR
da usare per la verifica del certificato MSCA_VU-
EGF, se presente;
— il certificato di collegamento che collega questi
due certificati EUR, se presente.
CSM_82 In aggiunta alle chiavi crittografiche e ai certificati elencati
in CSM_81, le unità elettroniche di bordo devono inoltre
contenere le chiavi e i certificati specificati nella parte A
della presente appendice, che consentono a una unità elet­
tronica di bordo di interagire con le carte tachigrafiche di
prima generazione.
9.1.5 Livello di apparecchio: carte tachigrafiche
▼M1
CSM_83 Per ciascuna carta tachigrafica deve essere generata una
coppia unica di chiavi ECC, denominata Card_MA. Inol­
tre, per ciascuna carta del conducente e per ciascuna carta
dell’officina deve essere generata una seconda coppia
unica di chiavi ECC, denominata Card_Sign. Questa ope­
razione può essere svolta dai fabbricanti della carta o da
chi personalizza la carta. Ogniqualvolta si genera una cop­
pia di chiavi della carta, la parte che genera la chiave deve
inviare la chiave pubblica alla MSCA di competenza, in
modo da ottenere il certificato della carta corrispondente
firmato dalla MSCA. La chiave privata deve essere usata
solo dalla carta tachigrafica.
▼B
CSM_84 I certificati Card_MA e Card_Sign di una determinata
carta del conducente o carta dell'officina devono avere la
stessa data di efficacia (Certificate Effective Date).
CSM_85 La forza di una coppia di chiavi della carta deve essere
scelta dal fabbricante della carta o da chi personalizza la
carta e deve essere uguale alla forza della coppia di chiavi
MSCA usate per firmare il corrispondente certificato della
carta.
CSM_86 Una carta tachigrafica deve usare la propria coppia di
chiavi Card_MA, composta da una chiave privata
Card_MA.SK e da una chiave pubblica Card_MA.PK,
esclusivamente per eseguire l'autenticazione reciproca e
l'accordo sulle chiavi di sessione nei confronti delle unità
elettroniche di bordo, come specificato nelle sezioni 10.3 e
10.4 della presente appendice.
CSM_87 Una carta del conducente o una carta dell'officina deve
usare la chiave privata Card_Sign.SK della coppia di
chiavi Card_Sign esclusivamente per firmare i file di dati
trasferiti, come specificato nel capitolo 14 della presente
appendice. La corrispondente chiave pubblica
Card_Sign.PK deve essere usata esclusivamente per verifi­
care le firme create dalla carta.
▼M1
CSM_88 Il periodo di validità di un certificato Card_MA deve es­
sere il seguente:
— per le carte del conducente: 5 anni;
— per le carte dell’azienda: 5 anni;
— per le carte di controllo: 2 anni;
— per le carte dell’officina: 1 anno.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 455
CSM_89 Il periodo di validità di un certificato Card_Sign deve
essere il seguente:
— per le carte del conducente: 5 anni e 1 mese;
— per le carte dell'officina: 1 anno e 1 mese.
Nota: l'estensione del periodo di validità di un certificato
Card_Sign consente alla carta del conducente di creare
firme valide per i dati trasferiti nel corso del primo mese
dopo la sua scadenza. Ciò è necessario in ragione del
Regolamento (UE) n. 581/2010 che impone che un trasfe­
rimento di dati da una carta del conducente deve essere
possibile fino a 28 giorni dopo la registrazione dell'ultimo
dato.
CSM_90 Le coppie di chiavi e i certificati corrispondenti di una
determinata carta tachigrafica non devono essere sostituiti
o rinnovati una volta che la carta è stata emessa.
CSM_91 Al momento del rilascio, le carte tachigrafiche devono
contenere i seguenti certificati e chiavi crittografiche:
— la chiave privata Card_MA e il certificato
corrispondente;
— per le carte del conducente e le carte dell'officina inol­
tre: la chiave privata Card_Sign e il certificato
corrispondente;
— il certificato MSCA_Card contenente la chiave pub­
blica MSCA_Card.PK da usare per la verifica del cer­
tificato Card_MA e del certificato Card_Sign;
— il certificato EUR contenente la chiave pubblica
EUR.PK da usare per la verifica del certificato
MSCA_Card;
— il certificato EUR il cui periodo di validità precede
direttamente il periodo di validità del certificato EUR
da usare per la verifica del certificato MSCA_Card, se
presente;
— il certificato di collegamento che collega questi
due certificati EUR, se presente;
▼M1
— inoltre, solo per le carte di controllo, le carte
dell’azienda e le carte dell’officina, e solo se tali carte
sono rilasciate durante i primi tre mesi del periodo di
validità di un nuovo certificato EUR: il certificato EUR
di due generazioni precedenti, se esistente.
Nota all’ultimo trattino: per esempio, nei primi tre mesi
dall’emissione del certificato ERCA(3) (cfr. figura 1),
dette carte devono contenere il certificato ERCA(1).
Ciò è necessario per garantire che queste carte possano
essere utilizzate per effettuare il trasferimento di dati
dalle VU ERCA (1) il cui normale periodo di trasferi­
mento dati di 15 anni più tre mesi scade durante questi
mesi; cfr. l’allegato IC, ultimo trattino del requisito 13.
▼B
CSM_92 In aggiunta alle chiavi crittografiche e ai certificati elencati
in CSM_91, le carte tachigrafiche devono inoltre contenere
le chiavi e i certificati specificati nella parte A della pre­
sente appendice, che consentono a tali carte di interagire
con le VU di prima generazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 456
9.1.6 Livello di apparecchio: dispositivi GNSS esterni
▼M1
CSM_93 Per ogni dispositivo GNSS esterno deve essere generata
una coppia unica di chiavi ECC, denominata EGF_MA.
Questo compito spetta ai fabbricanti di dispositivi GNSS
esterni. Ogniqualvolta si genera una coppia di chiavi
EGF_MA, la parte che genera la chiave deve inviare la
chiave pubblica alla MSCA di competenza, in modo da
ottenere il certificato EGF_MA corrispondente firmato
dalla MSCA. La chiave privata deve essere usata solo
dal dispositivo GNSS esterno.
▼B
CSM_94 La forza di una coppia di chiavi EGF_MA deve essere
scelta dal fabbricante dell'EGF e deve essere uguale alla
forza della coppia di chiavi MSCA usate per firmare il
corrispondente certificato EGF_MA.
▼M1
CSM_95 Un dispositivo GNSS esterno deve usare la propria coppia
di chiavi EGF_MA, composta da una chiave privata
EGF_MA.SK e da una chiave pubblica EGF_MA.PK,
esclusivamente per eseguire l’autenticazione reciproca e
l’accordo sulle chiavi di sessione nei confronti delle unità
elettroniche di bordo, come specificato al punto 11.4 della
presente appendice.
▼B
CSM_96 Il periodo di validità di un certificato EGF_MA deve es­
sere di 15 anni.
CSM_97 Dopo la scadenza del certificato corrispondente, il dispo­
sitivo GNSS esterno non deve usare la chiave privata della
sua coppia di chiavi EGF_MA per l'accoppiamento con
un'unità elettronica di bordo.
Nota: come spiegato nella sezione 11.3.3, un EGF può
potenzialmente usare la sua chiave privata per l'autentica­
zione reciproca con la VU cui è già accoppiato, anche
dopo la scadenza del certificato corrispondente.
CSM_98 La coppia di chiavi EGF_MA e il certificato corrispon­
dente di un determinato dispositivo GNSS esterno non
devono essere sostituiti o rinnovati sul campo una volta
che l'EGF è stato messo in funzione.
Nota: tale requisito non impedisce la sostituzione delle
coppie di chiavi EGF nel corso di un ricondizionamento
o di una riparazione in un ambiente sicuro, controllato dal
fabbricante dell'EGF.
CSM_99 Al momento della messa in funzione, i dispositivi GNSS
esterni devono contenere i seguenti certificati e chiavi
crittografiche:
— la chiave privata EGF_MA e il certificato
corrispondente;
— il certificato MSCA_VU-EGF contenente la chiave
pubblica MSCA_VU-EGF.PK da usare per la verifica
del certificato EGF_MA;
— il certificato EUR contenente la
chiave pubblica EUR.PK da usare per la verifica del
certificato MSCA_VU-EGF;
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 457
— il certificato EUR il cui periodo di validità precede
direttamente il periodo di validità del certificato EUR
da usare per la verifica del certificato MSCA_VU-
EGF, se presente;
— il certificato di collegamento che collega questi
due certificati EUR, se presente.
9.1.7 Riepilogo: sostituzione dei certificati
La Figura 1 di seguito mostra come diverse generazioni di certificati
radice ERCA, di certificati di collegamento ERCA, di certificati
MSCA e di certificati di dispositivo (VU o carta) siano rilasciati e usati
nel tempo:
▼M1
Figura 1
Rilascio e uso di diverse generazioni di certificati radice ERCA, certificati di collegamento ERCA, certificati
MSCA e certificati di dispositivo
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 458
Note alla Figura 1:
1. Le diverse generazioni del certificato radice sono indicate con un
numero tra parentesi. Ad esempio ERCA (1) è la prima generazione
del certificato radice ERCA; ERCA (2) è la seconda generazione, ecc.
2. Altri certificati sono indicati da due numeri tra parentesi, di cui il
primo indica la generazione del certificato radice in base al quale
sono stati rilasciati e il secondo indica la generazione del certificato
stesso. Ad esempio MSCA_Card (1-1) è il primo certificato
MSCA_Card rilasciato in base a ERCA (1); MSCA_Card (2-1) è il
primo certificato MSCA_Card rilasciato in base a ERCA (2);
MSCA_Card (2-last) è l'ultimo certificato MSCA_Card rilasciato in
base a ERCA (2); Card_MA (2-1) è il primo certificato della carta per
l'autenticazione reciproca rilasciato in base a ERCA (2), ecc.
3. I certificati MSCA_Card (2-1) e MSCA_Card (1-last) sono rilasciati
quasi, ma non esattamente, nella stessa data. MSCA_Card (2-1) è il
primo certificato MSCA_Card rilasciato in base a ERCA (2) poco
dopo MSCA_Card (1-last) che è l'ultimo certificato MSCA_Card rila­
sciato in base a ERCA (1).
4. Come indicato nella figura, i primi certificati della VU e della carta
rilasciati in base a ERCA (2) compariranno quasi due anni prima degli
ultimi certificati della VU e della carta rilasciati in base a ERCA (1).
Ciò è dovuto al fatto che i certificati della VU e della carta sono
rilasciati in base a un certificato MSCA e non direttamente in base al
certificato ERCA. Il certificato MSCA (2-1) sarà rilasciato subito
dopo l'inizio della validità di ERCA (2), ma il certificato MSCA (1-
last) sarà rilasciato solo poco prima, nell'ultimo momento in cui il
certificato ERCA (1) è ancora valido. Questi due certificati MSCA
avranno quindi quasi lo stesso periodo di validità, nonostante appar­
tengano a due diverse generazioni.
5. Il periodo di validità indicato per le carte è lo stesso di quello delle
carte del conducente (5 anni).
▼M1
6. Per motivi di spazio, la differenza del periodo di validità tra i certi­
ficati Card_MA e Card_Sign è indicata solo per la prima generazione.
▼B
9.2. Chiavi simmetriche
9.2.1 Chiavi per la sicurezza della comunicazione tra VU e sensore di movi­
mento
9.2.1.1 Principi generali
Nota: si presume che i lettori della presente sezione conoscano il conte­
nuto della norma [ISO 16844-3] che descrive l'interfaccia tra una VU e
un sensore di movimento. La procedura di abbinamento tra una VU e un
sensore di movimento è descritta in dettaglio nel capitolo 12 della pre­
sente appendice.
CSM_100 L'abbinamento delle VU ai sensori di movimento, l'autenti­
cazione reciproca tra le VU e i sensori di movimento e la
cifratura della comunicazione tra le VU e i sensori di mo­
vimento necessitano di un certo numero di chiavi simmetri­
che, come indicato in Tabella 3. Tutte queste chiavi devono
essere chiavi AES, di lunghezza uguale alla lunghezza della
chiave master del sensore di movimento, che deve essere
legata alla lunghezza della coppia di chiavi radice europee
(prevista) come descritto in CSM_50.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 459
Tabella 3
Chiavi per la sicurezza della comunicazione VU — sensore di movimento
Chiave Simbolo Generata da Metodo di generazione Memorizzata da
Chiave master del sen­
sore di movimento —
parte della VU
K M-VU ERCA Casuale ERCA, MSCA coinvolte nel ri­
lascio dei certificati delle VU,
fabbricanti di VU, unità elettro­
niche di bordo (VU)
Chiave master del sen­
sore di movimento —
parte dell'officina
K M-WC ERCA Casuale ERCA, MSCA, fabbricanti di
carte, carte dell'officina
Chiave master del sen­
sore di movimento
K M Non generata in
modo indipen­
dente
Calcolata come K M =
K M-VU XOR K M-WC
ERCA, MSCA coinvolte nel ri­
lascio delle chiavi dei sensori
di movimento (facoltativa­
mente) (*)
Chiave di identificazione K ID Non generata in
modo indipen­
dente
Calcolata come K ID =
K M XOR CV, dove CV
è specificato in
CSM_106
ERCA, MSCA coinvolte nel ri­
lascio delle chiavi dei sensori
di movimento (facoltativa­
mente) (*)
Chiave di abbinamento K P Fabbricante del
sensore di movi­
mento
Casuale Un sensore di movimento
Chiave di sessione K S VU (durante l'ab­
binamento tra VU
e sensore di movi­
mento)
Casuale Una VU e un sensore di movi­
mento
(*) La memorizzazione di K M e K ID è facoltativa, poiché queste chiavi possono essere calcolate da K M-VU , K M-WC e CV.
CSM_101 L'Autorità europea di certificazione primaria (ERCA) deve
generare K M-VU e K M-WC , che sono due chiavi AES uniche
e casuali con cui è possibile calcolare la chiave master del
sensore di movimento K M come K M-VU XOR K M-WC . La
ERCA deve comunicare, su richiesta, K M, K M-VU e K M-WC
alle autorità di certificazione degli Stati membri.
CSM_102 La ERCA deve assegnare a ciascuna chiave master del sen­
sore di movimento K M un numero di versione unico, appli­
cabile anche alle chiavi K M-VU e K M-WC di cui si compone e
alla relativa chiave di identificazione K ID . Quando la ERCA
trasmette alle MSCA le chiavi K M-VU e K M-WC deve anche
comunicare il numero di versione.
Nota: il numero di versione è usato per distinguere le di­
verse generazioni di tali chiavi, come spiegato in dettaglio
nella sezione 9.2.1.2.
CSM_103 Un'autorità di certificazione dello Stato membro (MSCA)
deve trasmettere la K M-VU, insieme al numero di versione,
ai fabbricanti di VU che ne facciano richiesta. I fabbricanti
di VU devono inserire la chiave K M-VU e il relativo numero
di versione in tutte le VU fabbricate.
CSM_104 Un'autorità di certificazione dello Stato membro (MSCA)
deve garantire che la chiave K M-WC e il rispettivo numero
di versione siano inseriti in ogni carta dell'officina rilasciata
sotto la sua responsabilità.
Note:
— cfr. la descrizione del tipo di dati
nell'appendice 2.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 460
— Come spiegato nella sezione 9.2.1.2, più generazioni di
K M-WC possono in realtà essere inserite in un'unica carta
dell'officina.
CSM_105 Oltre alle chiavi AES specificate in CSM_104, una MSCA
deve garantire che la chiave in TDES Km WC , specificata nel
requisito CSM_ 037 nella parte A della presente appendice,
sia inserita in ogni carta dell'officina rilasciata sotto la pro­
pria responsabilità.
Note:
— ciò consente di usare una carta dell'officina di seconda
generazione per l'accoppiamento con una VU di prima
generazione.
— Una carta dell'officina di seconda generazione conterrà
due distinte applicazioni, una conforme alla parte B
della presente appendice e l'altra conforme alla parte
A. Quest'ultima conterrà la chiave in TDES Km WC .
CSM_106 Una MSCA che partecipa al rilascio dei sensori di movi­
mento deve calcolare la chiave di identificazione mediante
una operazione XOR tra la chiave master del sensore di
movimento e un vettore costante CV. Il valore di CV
deve essere il seguente:
▼M1
— Per le chiavi master dei sensori di movimento a 128 bit:
CV = ’B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4
5D 83’
▼B
— Per le chiavi master dei sensori di movimento a 192 bit:
CV = «72 AD EA FA 00 BB F4 EE F4 99 15 70 5B 7E
EE BB 1C 54 ED 46 8B 0E F8 25»
— Per le chiavi master dei sensori di movimento a 256 bit:
CV = «1D 74 DB F0 34 C7 37 2F 65 55 DE D5 DC D1
9A C3 23 D6 A6 25 64 CD BE 2D 42 0D 85 D2 32 63
AD 60»
Nota: i vettori costanti sono stati generati come segue:
Pi_10 = primi 10 byte della parte decimale della costante
matematica π = «24 3F 6A 88 85 A3 08 D3 13 19»
CV_128-bits = primi 16 byte di SHA-256(Pi_10)
CV_192-bits = primi 24 byte di SHA-384(Pi_10)
CV_256-bits = primi 32 byte di SHA-512(Pi_10)
CSM_107 ►M1 Ciascun fabbricante di sensori di movimento deve
generare una chiave di abbinamento K P unica e casuale
per ciascun sensore di movimento e deve inviare ciascuna
chiave di accoppiamento all’autorità di certificazione dello
Stato membro (MSCA) di competenza. La MSCA deve crip­
tare separatamente ciascuna chiave di abbinamento con la
chiave master del sensore di movimento K M e deve fornire
la chiave criptata al fabbricante del sensore di movimento.
Per ciascuna chiave criptata, la MSCA deve comunicare al
fabbricante del sensore di movimento il numero di versione
della K M associata. ◄
Nota: come spiegato nella sezione 9.2.1.2, un fabbricante di
sensori di movimento può in realtà dover generare molteplici
chiavi di abbinamento uniche per un singolo sensore di
movimento.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 461
CSM_108 Ciascun fabbricante di sensori di movimento deve generare
un numero di serie unico per ciascun sensore di movimento
e deve inviare tutti i numeri di serie all’autorità di certifica­
zione dello Stato membro (MSCA) di competenza. La
MSCA deve criptare separatamente ciascun numero di serie
con la chiave di identificazione del sensore di movimento
K ID e deve fornire il numero di serie criptato al fabbricante
del sensore di movimento. Per ciascun numero di serie crip­
tato, la MSCA deve comunicare al fabbricante del sensore di
movimento il numero di versione della K ID associata.
▼B
CSM_109 Per i requisiti CSM_107 e CSM_108, la MSCA deve usare
l'algoritmo AES nella modalità di funzionamento a blocchi
incatenati (Chipher Block Chaining), come definito nella
norma [ISO 10116], con un parametro di interleave (inter­
leave parameter) m = 1 e un vettore di inizializzazione SV =
«00» {16}, cioè sedici byte con valore binario 0. Quando
necessario, la MSCA deve usare il metodo di riempimento 2
definito nella norma [ISO 9797-1].
CSM_110 Il fabbricante del sensore di movimento deve memorizzare
nel sensore di movimento la chiave di abbinamento criptata
e il numero di serie criptato, insieme ai corrispondenti valori
in formato di testo in chiaro (plain text) e al numero di
versione di K M e K ID usati per la cifratura.
Nota: come spiegato nella sezione 9.2.1.2, un fabbricante di
sensori di movimento può in realtà dover inserire molteplici
chiavi di abbinamento criptate e molteplici numeri di serie
criptati in un singolo sensore di movimento.
CSM_111 Oltre al materiale crittografico basato su AES specificato in
CSM_110, un fabbricante di sensori di movimento può inol­
tre memorizzare in ciascun sensore di movimento il mate­
riale crittografico basato su TDES specificato nel requisito
CSM_037 nella parte A della presente appendice.
Nota: ciò consentirà l'accoppiamento di un sensore di mo­
vimento di seconda generazione con una VU di prima
generazione.
CSM_112 La lunghezza della chiave di sessione K S generata da una
VU durante l'abbinamento a un sensore di movimento deve
essere collegata alla lunghezza della sua chiave K M-VU ,
come descritto in CSM_50.
9.2.1.2 Sostituzione della chiave master del sensore di movimento in apparecchi
di seconda generazione
CSM_113 Ciascuna chiave master del sensore di movimento e tutte le
relative chiavi (cfr. Tabella 3) sono associate a una partico­
lare generazione della coppia di chiavi radice ERCA. Tali
chiavi devono pertanto essere sostituite ogni 17 anni. Il
periodo di validità di ciascuna generazione di chiavi master
del sensore di movimento deve iniziare un anno prima che
la coppia di chiavi radice ERCA associata diventi valida e
terminare alla scadenza della coppia di chiavi radice ERCA
associata, come illustrato nella Figura 2.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 462
Figura 2
Rilascio e uso di diverse generazioni della chiave master del sensore di movimento nelle VU, nei sensori di
movimento e nelle carte dell'officina
CSM_114 Almeno un anno prima della generazione di una nuova cop­
pia di chiavi radice europee, come descritto in CSM_56, la
ERCA deve generare una nuova chiave master del sensore
di movimento, generando una nuova chiave K M-VU e una
nuova chiave K M-WC . La lunghezza della chiave master del
sensore di movimento deve essere collegata alla forza previ­
sta della nuova coppia di chiavi radice europee, conforme­
mente a CSM_50. La ERCA deve comunicare le nuove
chiavi K M , K M-VU e K M-WC alle MSCA che ne facciano
richiesta, insieme al rispettivo numero di versione.
CSM_115 Una MSCA deve garantire che tutte le generazioni valide di
K M-WC siano memorizzate in ogni carta dell'officina rila­
sciata sotto la sua autorità, insieme ai rispettivi numeri di
versione, come illustrato in Figura 2.
Nota: ciò implica che nell'ultimo anno del periodo di validità
di un certificato ERCA le carte dell'officina saranno rilasciate
con tre diverse generazioni di K M-WC , come illustrato in Fi­
gura 2.
CSM_116 Relativamente alla procedura descritta in CSM_107 e
CSM_108: la MSCA deve criptare separatamente ciascuna
chiave di abbinamento K P che riceve dal fabbricante del
sensore di movimento con ogni generazione valida della
chiave master del sensore di movimento K M . la MSCA
deve inoltre criptare separatamente ciascun numero di serie
che riceve dal fabbricante del sensore di movimento con
ogni generazione valida della chiave di identificazione
K ID . Il fabbricante del sensore di movimento deve memo­
rizzare nel sensore di movimento tutte le cifrature della
chiave di abbinamento e del numero di serie, insieme ai
corrispondenti valori in formato di testo semplice e ai nu­
meri di versione di K M e K ID usati per la cifratura.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 463
Nota: ciò implica che nell'ultimo anno del periodo di vali­
dità di un certificato ERCA i sensori di movimento saranno
rilasciati con dati criptati in base a tre diverse generazioni di
K M , come illustrato in Figura 2.
CSM_117 Relativamente alla procedura descritta in CSM_107: poiché
la lunghezza della chiave di abbinamento K P deve essere
collegata alla lunghezza di K M (cfr. CSM_100), un fabbri­
cante di sensori di movimento può dover generare fino a tre
diverse chiavi di abbinamento (di lunghezze diverse) per un
sensore di movimento, nel caso le successive generazioni
K M abbiano lunghezze diverse. In tal caso, il fabbricante
deve inviare ciascuna chiave di abbinamento alla MSCA.
Le MSCA deve garantire che ciascuna chiave di abbina­
mento sia criptata con la generazione corretta della chiave
master del sensore di movimento, ossia quella avente la
stessa lunghezza.
Nota: nel caso in cui scelga di generare una chiave di ab­
binamento basata su TDES per un sensore di movimento
di seconda generazione (cfr. CSM_111), il fabbricante di
sensori di movimento deve indicare alla MSCA che la
chiave master del sensore di movimento basata su TDES
deve essere usata per criptare questa chiave di accoppia­
mento. Ciò è dovuto al fatto che la lunghezza della chiave
in TDES può essere pari a quella di una chiave AES, per cui
la MSCA non può giudicare a partire dalla sola lunghezza
della chiave.
CSM_118 I fabbricanti di VU devono inserire solo una generazione di
K M-VU in ciascuna VU, insieme al suo numero di versione.
La generazione della K M-VU deve essere correlata al certifi­
cato ERCA su cui si basano i certificati della VU.
Note:
— una VU basata sulla generazione X del certificato ERCA
deve contenere solo la generazione X della chiave K M-
VU , anche se è stata rilasciata dopo l'inizio del periodo di
validità della generazione X+1 del certificato ERCA. Ciò
è illustrato nella Figura 2.
— Una generazione di VU X non può essere abbinata a un
sensore di movimento di generazione X-1.
— Poiché le carte dell'officina hanno un periodo di validità
di un anno, il risultato di CSM_113 — CSM_118 sarà
che tutte le carte di officina conterranno la nuova chiave
K M-WC al momento del rilascio della prima VU conte­
nente la nuova chiave K M-VU . Tale VU sarà quindi sem­
pre in grado di calcolare la nuova chiave K M . In quel
momento inoltre la maggior parte dei nuovi sensori di
movimento conterrà dati criptati basati anche sulla nuova
chiave K M .
9.2.2 Chiavi per la sicurezza della comunicazione DSRC
9.2.2.1 Principi generali
CSM_119 L'autenticità e la riservatezza dei dati comunicati da una VU
a un'autorità di controllo su un canale di comunicazione
remota DSRC devono essere garantite mediante un insieme
di chiavi AES specifiche della VU derivate da una singola
chiave master DSRC, KM DSRC .
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 464
CSM_120 La chiave master DSRC KM DSRC deve essere una chiave
AES generata, memorizzata e distribuita in modo sicuro
dalla ERCA. La lunghezza della chiave può essere di 128,
192 o 256 bit e deve essere legata alla lunghezza della
coppia di chiavi radice europee, come descritto in CSM_50.
CSM_121 La ERCA deve comunicare in modo sicuro la chiave master
DSRC alle autorità di certificazione degli Stati
membri (MSCA) che ne facciano richiesta, per consentire
loro di calcolare le chiavi DSRC specifiche della VU e di
garantire che la chiave master DSRC sia inserita in tutte le
carte di controllo e le carte dell'officina rilasciate sotto la
loro responsabilità.
CSM_122 La ERCA deve assegnare a ciascuna chiave master DSRC
un numero di versione unico. Quando la ERCA trasmette
alle MSCA le chiavi master DSRC deve anche comunicare
loro il numero di versione.
Nota: il numero di versione è usato per distinguere le di­
verse generazioni di chiavi master DSRC, come spiegato in
dettaglio nella sezione 9.2.2.2.
▼M1
CSM_123 Per ciascuna VU, il fabbricante di VU deve generare un
numero di serie unico della VU e inviare tale numero alla
rispettiva MSCA in una richiesta volta ad ottenere un in­
sieme di due chiavi DSRC specifiche della VU. Il tipo di
dati del numero di serie della VU deve essere
.
Nota:
— Il numero di serie della VU deve essere identico all’ele­
mento VuSerialNumber contenuto in VuIdentification
(cfr. appendice 1) e al riferimento del titolare del certi­
ficato indicato nei certificati della VU.
— Il numero di serie della VU può non essere noto nel
momento in cui il produttore della VU richiede le chiavi
DSRC specifiche della VU. In tal caso, il fabbricante
della VU deve inviare al suo posto l’identificativo unico
della richiesta di certificato usato nella domanda di cer­
tificati della VU; cfr. CSM_153. Tale identificativo della
richiesta di certificato deve quindi coincidere con il ri­
ferimento del titolare del certificato indicato nei certifi­
cati della VU.
▼B
CSM_124 Dopo aver ricevuto una richiesta di chiavi DSRC specifiche
della VU, la MSCA deve calcolare due chiavi AES per la
VU, denominate K_VU DSRC _ENC e K_VU DSRC _MAC. Tali
chiavi specifiche della VU devono avere la stessa lunghezza
della chiave master DSRC. La MSCA deve usare la fun­
zione di derivazione della chiave definita in [RFC 5869]. La
funzione di hash necessaria per istanziare la funzione
HMAC-Hash deve essere collegata alla lunghezza della
chiave master DSRC, come descritto in CSM_50. La fun­
zione di derivazione della chiave in [RFC 5869] deve essere
usata come segue:
Fase 1 (estrazione):
— PRK = HMAC-Hash (salt, IKM) dove salt è una stringa
vuota «» e IKM è KM DSRC .
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 465
Fase 2 (espansione):
— OKM = T(1), dove
T(1) = HMAC-Hash (PRK, T(0) || info || «01») con
— T(0) = una stringa vuota («»)
— ►M1 info = numero di serie o identificativo della
richiesta di certificato della VU come specificato in
CSM_123 ◄
— K_VU DSRC _ENC = primi L ottetti di OKM e
K_VU DSRC _MAC = ultimi L ottetti di OKM
dove L è la lunghezza richiesta di K_VU DSRC _ENC e
K_VU DSRC _MAC in ottetti.
CSM_125 La MSCA deve distribuire K_VU DSRC _ENC e
K_VU DSRC _MAC in modo sicuro al fabbricante della VU
perché le inserisca nella VU cui sono destinate.
CSM_126 Al momento del rilascio una VU deve contenere nella me­
moria sicura le chiavi K_VU DSRC _ENC e
K_VU DSRC _MAC, in modo da poter garantire l'integrità,
l'autenticità e la riservatezza dei dati trasmessi attraverso il
canale di comunicazione remota. Una VU deve inoltre avere
in memoria il numero della versione della chiave master
DSRC usata per calcolare tali chiavi specifiche della VU.
CSM_127 Al momento del rilascio, le carte di controllo e le carte
dell'officina devono contenere KM DSRC nella loro memoria
sicura, in modo da essere in grado di verificare l'integrità e
l'autenticità dei dati trasmessi da una VU sul canale di co­
municazione remota e di decriptare tali dati. Le carte di
controllo e le carte dell'officina deve inoltre avere in memo­
ria il numero di versione della chiave master DSRC.
Nota: come spiegato nella sezione 9.2.2.2, più generazioni
di K DSRC possono in realtà essere inserite in un'unica carta
dell'officina o carta di controllo.
▼M1
CSM_128 La MSCA deve registrare tutte le chiavi DSRC specifiche
della VU che ha generato, il loro numero di versione e il
numero di serie o l’identificativo della richiesta di certificato
della VU usato per ricavarle.
▼B
9.2.2.2 Sostituzione della chiave master DSRC
CSM_129 Ciascuna chiave master DSRC è associata a una particolare
generazione della coppia di chiavi radice ERCA. La ERCA
deve quindi sostituire la chiave master DSRC ogni 17 anni.
Il periodo di validità di ciascuna generazione di chiavi ma­
ster DSRC deve iniziare due anni prima che la coppia di
chiavi radice ERCA associata diventi valida e terminare alla
scadenza della coppia di chiavi radice ERCA associata,
come illustrato nella Figura 3.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 466
Figura 3
Rilascio e uso di diverse generazioni della chiave master DSRC nelle VU, nelle carte dell'officina e nelle carte di
controllo
CSM_130 Almeno due anni prima della generazione di una nuova
coppia di chiavi radice europee, come descritto in CSM_56,
la ERCA deve generare una nuova chiave master DSRC. La
lunghezza della chiave master DSRC deve essere collegata
alla forza prevista della nuova coppia di chiavi radice euro­
pee, conformemente a CSM_50. La ERCA deve comunicare
la nuova chiave master DSRC alle MSCA che ne facciano
richiesta, insieme al rispettivo numero di versione.
CSM_131 La MSCA deve garantire che tutte le generazioni valide di
KM DSRC siano memorizzate in ogni carta di controllo rila­
sciata sotto la sua autorità, insieme ai rispettivi numeri di
versione, come illustrato in Figura 3.
Nota: ciò implica che degli ultimi due anni del periodo di
validità di un certificato ERCA le carte di controllo saranno
rilasciate con tre diverse generazioni di KM DSRC , come illu­
strato in Figura 3.
CSM_132 La MSCA deve garantire che tutte le generazioni di
KM DSRC che sono state valide per almeno un anno e sono
ancora valide, siano memorizzate in ogni carta di controllo
rilasciata sotto la sua autorità, insieme ai rispettivi numeri di
versione, come illustrato in Figura 3.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 467
Nota: ciò implica che nell'ultimo anno del periodo di vali­
dità di un certificato ERCA le carte dell'officina saranno
rilasciate con tre diverse generazioni di K DSRC , come illu­
strato in Figura 3.
CSM_133 I fabbricanti di VU devono inserire solo una serie di chiavi
DSRC specifiche della VU in ciascuna VU, insieme al suo
numero di versione. Questa serie di chiavi deve essere cal­
colata dalla generazione di KM DSRC collegata al certificato
ERCA su cui si basano i certificati della VU.
Note:
— ciò implica che una VU basata sulla generazione X del
certificato ERCA deve contenere solo la generazione X
K_VU DSRC _ENC e K_VU DSRC _MAC , anche se la VU è
stata rilasciata dopo l'inizio del periodo di validità della
generazione X + 1 del certificato ERCA. Ciò è illustrato
in Figura 3.
— Poiché le carte dell'officina hanno una validità di un
anno e le carte di controllo di due anni, il risultato di
CSM_131 — CSM_133 sarà che tutte le carte dell'offi­
cina e le carte di controllo conterranno la nuova chiave
master DSRC al momento del rilascio della prima VU
contenente le chiavi specifiche della VU basata su tale
chiave master.
9.3. Certificati
9.3.1 Principi generali
CSM_134 Tutti i certificati nell'ambito del sistema tachigrafico intelli­
gente europeo devono essere verificabili mediante carta
(card verifiable — CV) e autodescrittivi (self-descriptive),
conformemente alle norme [ISO 7816-4] e [ISO 7816-8].
CSM_135 ►M1 Per la codifica degli oggetti di dati all’interno dei
certificati vanno usate le regole di codifica distinte (DER),
conformemente alla norma [ISO 8825-1]. La tabella 4 mo­
stra l’intera codifica dei certificati, compresi tutti i tag e i
byte di lunghezza. ◄
Nota: questa codifica genera una struttura Tag-Lunghezza-
Valore (TLV) come segue:
Tag: il tag è codificato in uno o due ottetti e indica
il contenuto.
Lunghezza: la lunghezza è codificata come un numero in­
tero senza segno in uno, due o tre ottetti, fino a
una lunghezza massima di 65 535 ottetti. Deve
essere usato il numero minimo di ottetti.
Valore: il valore è codificato come zero o più ottetti.
9.3.2 Contenuto del certificato
CSM_136 Tutti i certificati devono avere la struttura indicata nel pro­
filo del certificato nella Tabella 4.
Tabella 4
Profilo del certificato versione 1
Campo ID campo Tag Lunghezza (byte)
Tipo di dati ASN. 1
(cfr. appendice 1)
Certificato ECC C «7F 21» var
Corpo del certificato
ECC
B «7F 4E» var
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 468
Campo ID campo Tag Lunghezza (byte)
Tipo di dati ASN. 1
(cfr. appendice 1)
Identificativo del pro­
filo del certificato
(Certificate Profile
Identifier)
CPI «5F 29» «01»
Riferimento dell'auto­
rità di certificazione
CAR «42» «08»
Autorizzazione del ti­
tolare del certificato
CHA «5F 4C» «07»
Chiave pubblica PK «7F 49» var
Parametri di dominio DP «06» var
Punto pubblico (pu­
blic point)
PP «86» var
Riferimento del tito­
lare del certificato
CHR «5F 20» «08»
Data di efficacia del
certificato
CEfD «5F 25» «04»
Data di scadenza del
certificato
CExD «5F 24» «04»
Firma del certificato
ECC
S «5F 37» var
Nota: ID campo sarà usato in sezioni successive della pre­
sente appendice per indicare i singoli campi di un certificato,
ad esempio X.CAR è il riferimento all'autorità di certifica­
zione (Certificate Authority Reference — CAR) citata nel
certificato dell'utente X.
9.3.2.1 Identificativo del profilo del certificato (Certificate Profile Identifier)
CSM_137 I certificati devono usare un identificativo del profilo del
certificato (Certificate Profile Identifier) per indicare il pro­
filo del certificato usato. Come specificato nella Tabella 4, la
versione 1 deve essere indicata col valore «00».
9.3.2.2 Riferimento dell'autorità di certificazione
CSM_138 Il riferimento dell'autorità di certificazione deve essere usato
per identificare la chiave pubblica da usare per la verifica
della firma del certificato. Il riferimento dell'autorità di cer­
tificazione deve quindi essere uguale al riferimento del tito­
lare del certificato (Certificate Holder Reference — CHR)
nel certificato della corrispondente autorità di certificazione.
CSM_139 Un certificato radice ERCA deve essere autofirmato, vale a
dire che nel certificato il riferimento dell'autorità di certifi­
cazione e il riferimento del titolare del certificato devono
essere uguali.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 469
CSM_140 Per un certificato di collegamento ERCA, il riferimento del
titolare del certificato deve essere uguale al CHR del nuovo
certificato radice ERCA. Il riferimento dell'autorità di certi­
ficazione per un certificato di collegamento deve essere
uguale al CHR del precedente certificato radice ERCA.
9.3.2.3 Autorizzazione del titolare del certificato.
▼M1
CSM_141 L’autorizzazione del titolare del certificato deve essere usata
per identificare il tipo di certificato. Si compone dei sei byte
più significativi dell’ID dell’applicazione tachigrafica, con­
catenati con il tipo di apparecchio cui si riferisce il certifi­
cato. Nel caso di un certificato della VU, della carta del
conducente o della carta dell’officina, il tipo di apparecchio
si usa anche per distinguere tra un certificato di autentica­
zione reciproca e un certificato per la creazione di firme
digitali (cfr. appendice 1, punto 9.1, tipo di dati Equipmen­
tType).
▼B
9.3.2.4 Chiave pubblica
La chiave pubblica contiene due elementi di dati: i parametri di dominio
standardizzati da usare con la chiave pubblica nel certificato e il valore
del punto pubblico.
CSM_142 L'elemento di dati «parametri di dominio» (Domain Parame­
ters) deve contenere uno degli identificativi di oggetto spe­
cificati nella Tabella 1 in riferimento a un insieme di para­
metri di dominio standardizzati.
CSM_143 L'elemento di dati «punto pubblico» (Public Point) deve
contenere il punto pubblico. I punti pubblici della curva
ellittica devono essere convertiti in stringhe di ottetti,
come specificato in [TR-03111]. Deve essere usato il for­
mato di codifica non compresso. Al momento del ripristino
di un punto di una curva ellittica dal formato codificato,
devono essere sempre eseguite le convalide descritte in
[TR-03111].
9.3.2.5 Riferimento del titolare del certificato
CSM_144 Il riferimento del titolare del certificato (Certificate Holder
Reference) è un identificativo della chiave pubblica conte­
nuta nel certificato. Deve essere usato per fare riferimento a
tale chiave pubblica in altri certificati.
CSM_145 Per i certificati della carta e dei dispositivi GNSS esterni, il
riferimento del titolare del certificato deve avere il tipo
di dati specificato nell'appen­
dice 1.
CSM_146 Per le VU, il fabbricante, quando richiede un certificato, può cono­
scere o può non conoscere il numero di serie specifico del fab­
bricante della VU cui tale certificato e la chiave privata associata
sono destinati. Nel primo caso, il riferimento del titolare del certi­
ficato deve avere il tipo di dati
specificato nell'appendice 1. Nel secondo caso, il riferimento del
titolare del certificato deve avere il tipo di dati
specificato nell'appendice 1.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 470
Nota: per un certificato della carta, il valore del CHR deve
coincidere con il valore cardExtendedSerialNumber
nell’EF_ICC; cfr. appendice 2. Per un certificato EGF, il
valore del CHR deve coincidere con il valore sensor­
GNSSSerialNumber nell’EF_ICC; cfr. appendice 14. Per
un certificato della VU, il valore del CHR deve coincidere
con il l’elemento vuSerialNumber contenuto in VuIdentifi­
cation, cfr. appendice 1, a meno che al momento della ri­
chiesta del certificato il fabbricante non conoscesse il nu­
mero di serie specifico del fabbricante.
▼B
CSM_147 Per i certificati ERCA e MSCA, il riferimento del titolare
del certificato deve avere il tipo di dati
specificato nell'appen­
dice 1.
9.3.2.6 Data di efficacia del certificato
▼M1
CSM_148 La data di efficacia del certificato deve indicare la data e
l’ora di inizio del periodo di validità del certificato.
▼B
9.3.2.7 Data di scadenza del certificato
CSM_149 La data di scadenza del certificato deve indicare la data e
l'ora di fine del periodo di validità del certificato.
9.3.2.8 Firma del certificato
CSM_150 La firma sul certificato deve essere creata sul corpo del
certificato codificato, compresi il tag e la lunghezza del
corpo del certificato. L'algoritmo di firma deve essere
ECDSA, come specificato in [DSS], usando l'algoritmo di
hash collegato alle dimensioni della chiave dell'autorità che
firma, come specificato in CSM_50. Il formato della firma
deve essere in chiaro, come specificato in [TR-03111].
9.3.3 Richiesta di certificati
CSM_151 ►M1 Per la richiesta di un certificato, la MSCA deve
inviare i seguenti dati alla ERCA: ◄
— l'identificativo del profilo del certificato richiesto;
— il riferimento dell'autorità di certificazione che si prevede
di usare per la firma del certificato;
— la chiave pubblica da firmare.
CSM_152 Oltre ai dati in CSM_151, una MSCA deve inviare i seguenti
dati in una richiesta di certificato alla ERCA, consentendo a
quest'ultima di creare il riferimento del titolare del certificato
del nuovo certificato MSCA:
— il codice numerico del paese dell'autorità di certificazione
(tipo di dati definito nell'appendice 1);
— il codice alfanumerico del paese dell'autorità di certifica­
zione (tipo di dati definito nell'appen­
dice 1);
— il numero di serie a 1 byte usato per distinguere le
diverse chiavi dell'autorità di certificazione in caso di
cambio di chiavi;
— il campo a due byte contenente specifiche informazioni
supplementari dell'autorità di certificazione.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 471
CSM_153 Il fabbricante dell’apparecchiatura deve inviare i seguenti
dati in una richiesta di certificato alla MSCA, consentendole
di creare il riferimento del titolare del certificato relativo al
nuovo certificato dell’apparecchiatura:
— se noto (cfr. CSM_154), un numero di serie per l’appa­
recchio, univocamente associato al fabbricante, al tipo di
apparecchio e al mese di fabbricazione. Altrimenti, un
identificativo unico della richiesta di certificato;
— il mese e l’anno di fabbricazione dell’apparecchio o della
richiesta di certificato.
Il fabbricante deve garantire che tali dati siano corretti e che il certificato
rilasciato dalla MSCA sia inserito nell’apparecchio cui è destinato.
▼B
CSM_154 Nel caso di una VU, il fabbricante, quando richiede un
certificato, può conoscere o può non conoscere il numero
di serie specifico del fabbricante della VU cui tale certificato
e la chiave privata associata sono destinati. Nel primo caso,
il fabbricante della VU deve inviare il numero di serie alla
MSCA. Nel secondo caso, il fabbricante deve identificare
univocamente ciascuna richiesta di certificato e inviare tale
numero di serie della richiesta di certificato alla MSCA. Il
certificato che ne risulta conterrà quindi il numero di serie
della richiesta di certificato. Dopo aver inserito il certificato
in una specifica VU, il fabbricante deve comunicare alla
MSCA il collegamento tra il numero di serie della richiesta
di certificato e l'identificazione della VU.
10. AUTENTICAZIONE RECIPROCA E MESSAGGISTICA SICURA
TRA VU E CARTA
10.1. Principi generali
CSM_155 Ad alto livello, la comunicazione sicura tra una VU e una
carta tachigrafica deve avvenire secondo le seguenti fasi:
— prima fase: ciascuna parte deve dimostrare all'altra di
essere in possesso di un certificato a chiave pubblica
valido, firmato da un'autorità di certificazione di uno
Stato membro (MSCA). Il certificato MSCA a chiave
pubblica deve essere firmato dalla ERCA. Questa fase
è denominata verifica della catena di certificati (certifi­
cate chain verification) ed è specificata in dettaglio nella
sezione 10.2;
— seconda fase: la VU deve dimostrare alla carta di essere
in possesso della chiave privata corrispondente alla
chiave pubblica nel certificato presentato, firmando un
numero casuale inviato dalla carta. La carta verifica la
firma per questo numero casuale e, se la verifica ha esito
positivo, la VU è autenticata. Questa fase è denominata
autenticazione della VU (VU Authentication) ed è spe­
cificata in dettaglio nella sezione 10.3;
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 472
— terza fase: entrambe le parti calcolano in modo indipen­
dente due chiavi di sessione AES usando un algoritmo di
accordo sulla chiave asimmetrica. Usando una di queste
chiavi di sessione, la carta crea un codice di autentica­
zione del messaggio (MAC) per alcuni dati trasmessi
dalla VU. La VU verifica il MAC. Se la verifica ha esito
positivo, la carta è autenticata. Questa fase è denominata
autenticazione della carta (Card Authentication) ed è
specificata in dettaglio nella sezione 10.4;
— quarta fase: la VU e la carta devono usare le chiavi di
sessione su cui si sono accordate per garantire la riser­
vatezza, l'integrità e l'autenticità di tutti i messaggi scam­
biati. Questa fase è denominata messaggistica sicura (Se­
cure Messaging) ed è specificata in dettaglio nella
sezione 10.5.
CSM_156 Il meccanismo descritto in CSM_155 deve essere attivato
dalla VU ogni volta che una carta è inserita in una delle
sue sedi (slot).
10.2. Verifica reciproca della catena di certificati
10.2.1 Verifica della catena di certificati della carta da parte della VU
CSM_157 ►M1 Le VU devono usare il protocollo illustrato nella
figura 4 per la verifica della catena di certificati di una carta
tachigrafica. Per ogni certificato che legge dalla carta, la VU
deve verificare che l’informazione contenuta nel campo «au­
torizzazione del titolare del certificato» (CHA) sia corretta:
— Il campo CHA del certificato Card deve indicare un
certificato di autenticazione reciproca della carta (cfr.
appendice 1, tipo di dati EquipmentType).
— Il campo CHA del certificato Card.CA deve indicare una
MSCA.
— Il campo CHA del certificato Card.Link deve indicare la
ERCA. ◄
Note alla Figura 4:
— i certificati e le chiavi pubbliche della carta citati nella
figura sono quelli usati per l'autenticazione reciproca.
Nella sezione 9.1.5 sono indicati come Card_MA.
— I certificati e le chiavi pubbliche Card.CA citati nella
figura sono quelli usati per firmare i certificati della carta
e sono indicati nel CAR del certificato della carta. Nella
sezione 9.1.3 sono indicati come MSCA_Card.
— Il certificato Card.CA.EUR citato nella figura è il certi­
ficato radice europeo indicato nel CAR del certificato
Card.CA.
— Il certificato Card.Link indicato nella figura è il certifi­
cato di collegamento della carta, se presente. Come spe­
cificato nella sezione 9.1.2, si tratta di un certificato di
collegamento per una nuova coppia di chiavi radice eu­
ropee creata dalla ERCA e firmata con la precedente
chiave privata europea.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 473
— Il certificato Card.Link.EUR è il certificato radice euro­
peo indicato nel CAR del certificato Card.Link.
CSM_158 Come illustrato nella Figura 4, la verifica della catena di
certificati della carta deve iniziare al momento dell'inseri­
mento della carta. La VU deve leggere il riferimento del
titolare della carta ( )
dall'EF ICC. La VU deve verificare se conosce la carta,
vale a dire, se ha già verificato in passato la catena di
certificati della carta con esito positivo e ha memorizzato
questi dati per riferimento futuro. In caso affermativo, e se
il certificato della carta è ancora valido, la procedura conti­
nua con la verifica della catena di certificati della VU. In
caso contrario la VU deve leggere dalla carta, in succes­
sione, il certificato MSCA_Card da usare per la verifica
del certificato della carta, il certificato Card.CA.EUR da
usare per la verifica del certificato MSCA_Card e eventual­
mente il certificato di collegamento, fino a che non trova un
certificato che conosce o che può verificare. Se tale certifi­
cato viene trovato, la VU lo usa per verificare i certificati
della carta sottostanti che ha letto dalla carta. In caso di esito
positivo, la procedura continua con la verifica della catena di
certificati della VU. In caso di esito negativo, la VU deve
ignorare la carta.
Nota: la VU può conoscere il certificato Card.CA.EUR in
tre modi:
— il certificato Card.CA.EUR è uguale al certificato EUR
della VU stessa;
— il certificato Card.CA.EUR è precedente
al certificato EUR della VU stessa e la VU lo conteneva
già al momento del rilascio (cfr. CSM_81);
— il certificato Card.CA.EUR è successivo
al certificato EUR della VU stessa e la VU ha ricevuto
un certificato di collegamento in passato da un'altra carta
tachigrafica, lo ha verificato e lo ha memorizzato per
riferimento futuro.
CSM_159 Come illustrato in Figura 4, una volta verificata l'autenticità
e la validità di un certificato precedentemente sconosciuto, la
VU può conservarlo per riferimento futuro, in modo da non
doverne nuovamente verificare l'autenticità se viene nuova­
mente presentato alla VU. Invece di memorizzare l'intero
certificato, una VU può scegliere di memorizzare solo il
contenuto del corpo del certificato, come specificato nella
sezione 9.3.2. ►M1 Sebbene la memorizzazione di tutti gli
altri tipi di certificato sia facoltativa, la VU deve obbligato­
riamente memorizzare i certificati nuovi presentati da una
carta. ◄
CSM_160 La VU deve verificare la validità temporale di qualsiasi
certificato letto dalla carta o memorizzato nella sua memo­
ria e respingere i certificati scaduti. Per verificare la validità
temporale del certificato presentato dalla carta la VU deve
usare il suo orologio interno.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 474
Figura 4
Protocollo per la verifica della catena di certificati della carta da parte della VU
10.2.2 Verifica della catena di certificati della VU da parte della carta
CSM_161 ►M1 Le carte tachigrafiche devono usare il protocollo illu­
strato nella figura 5 per la verifica della catena di certificati
di una VU. Per ogni certificato presentato dalla VU, la carta
deve verificare che l’informazione contenuta nel campo «au­
torizzazione del titolare del certificato» (CHA) sia corretta:
— Il campo CHA del certificato VU.Link deve indicare la
ERCA.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 475
— Il campo CHA del certificato VU.CA deve indicare una
MSCA.
— Il campo CHA del certificato VU deve indicare un cer­
tificato VU di autenticazione reciproca (cfr. appendice 1,
tipo di dati EquipmentType). ◄
Figura 5
Protocollo per la verifica della catena di certificati della VU da parte della carta
Note alla Figura 5:
— i certificati e le chiavi pubbliche della VU citati nella figura sono
quelli usati per l'autenticazione reciproca. Nella sezione 9.1.4 sono
indicati come VU_MA.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 476
— I certificati e le chiavi pubbliche VU.CA citati nella figura sono
quelli usati per firmare i certificati della VU e del dispositivo
GNSS esterno. Nella sezione 9.1.3 sono indicati come MSCA_VU-
EGF.
— Il certificato VU.CA.EUR citato nella figura è il certificato radice
europeo indicato nel CAR del certificato VU.CA.
— Il certificato VU.Link indicato nella figura è il certificato di collega­
mento della VU, se presente. Come specificato nella sezione 9.1.2, si
tratta di un certificato di collegamento per una nuova coppia di chiavi
radice europee creata dalla ERCA e firmata con la precedente chiave
privata europea.
— Il certificato VU.Link.EUR è il certificato radice europeo indicato nel
CAR del certificato VU.Link.
CSM_162 Come illustrato in Figura 5, la verifica della catena di cer­
tificati della VU deve iniziare con il tentativo della VU di
usare la propria chiave pubblica nella carta tachigrafica. Se
questo tentativo ha esito positivo significa che in passato la
carta aveva già verificato la catena di certificati della VU
con esito positivo e aveva memorizzato il certificato della
VU per riferimento futuro. In tal caso il certificato della VU
è impostato per l'uso e la procedura continua con l'autenti­
cazione della VU. Se il certificato della VU non è noto alla
carta, la VU deve presentare, in successione, il certificato
VU.CA da usare per verificare il suo certificato di VU, il
certificato VU.CA.EUR da usare per verificare il certificato
VU.CA e eventualmente il certificato di collegamento, in
modo da trovare un certificato noto o verificabile dalla
carta. Se tale certificato viene trovato, la carta deve farne
uso per verificare i certificati della VU sottostanti che le
sono stati presentati. In caso di esito positivo la VU deve
impostare infine la sua chiave pubblica per l'uso nella carta
tachigrafica. In caso di esito negativo, la VU deve ignorare
la carta.
Nota: la carta può conoscere il certificato VU.CA.EUR in
tre modi:
— il certificato VU.CA.EUR è uguale al certificato EUR
della carta stessa;
— il certificato VU.CA.EUR è precedente al certificato
EUR della carta stessa e la carta lo conteneva già al
momento del rilascio (cfr. CSM_91);
— il certificato VU.CA.EUR è successivo al certificato
EUR della carta stessa e la carta ha ricevuto un certifi­
cato di collegamento in passato da un'altra VU, lo ha
verificato e lo ha memorizzato per riferimento futuro.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 477
CSM_163 La VU deve usare il comando MSE: Set AT per impostare
la sua chiave pubblica per l'uso nella carta tachigrafica.
Come specificato nell'appendice 2, tale comando contiene
un'indicazione del meccanismo di crittografia che sarà usato
con la chiave impostata. Il meccanismo è «autenticazione
della VU utilizzando l'algoritmo ECDSA, in combinazione
con l'algoritmo di hash collegato alle dimensioni della cop­
pia di chiavi VU_MA della VU, come specificato in
CSM_50».
CSM_164 Il comando MSE: Set AT contiene inoltre un'indicazione
della coppia di chiavi temporanee che la VU userà durante
l'accordo sulla chiave di sessione (cfr. sezione 10.4). Per­
tanto prima di inviare il comando MSE: Set AT la VU deve
generare una coppia di chiavi ECC temporanee. Per gene­
rare la coppia di chiavi temporanee, la VU deve usare i
parametri di dominio standardizzati indicati nel certificato
della carta. La coppia di chiavi temporanee è indicata come
(VU.SK eph , VU.PK eph , Card.DP). La VU deve prendere la
coordinata x del punto pubblico temporaneo ECDH come
chiave di identificazione; ciò è denominato rappresentazione
compressa della chiave pubblica ed indicato come
Comp(VU.PK eph ).
▼M1
CSM_165 Se il comando MSE: Set AT ha esito positivo, la carta deve
impostare il VU.PK indicato per l’uso successivo durante
l’autenticazione del veicolo e memorizzare temporanea­
mente il Comp(VU.PKeph). Nel caso in cui due o più co­
mandi MSE: Set AT siano inviati con esito positivo prima
dell’accordo sulla chiave di sessione, la carta deve memo­
rizzare solo l’ultimo Comp(VU.PKeph) ricevuto. La carta
deve azzerare Comp(VU.PKeph) una volta che il comando
GENERAL AUTHENTICATE ha avuto esito positivo.
▼B
CSM_166 La carta deve verificare la validità temporale di qualsiasi
certificato presentato dalla VU o cui la VU si riferisce
mentre è conservato nella memoria della carta e deve rifiu­
tare i certificati scaduti.
CSM_167 Per verificare la validità temporale del certificato presentato
dalla VU, ogni carta tachigrafica deve conservare in memo­
ria dei dati che rappresentano l'ora corrente. Tali dati non
devono essere direttamente aggiornabili da una VU. Al mo­
mento del rilascio, l'ora corrente di una carta deve essere
impostata come uguale alla data di efficacia del certificato
Card_MA della carta. Una carta deve aggiornare la sua ora
corrente se la data di efficacia di un certificato «sorgente di
tempo valida» autentico presentato da una VU è più recente
dell'ora corrente della carta. In tal caso, la carta deve impo­
stare la sua ora corrente come uguale alla data di efficacia di
tale certificato. La carta deve accettare solo i seguenti cer­
tificati come sorgente di tempo valida:
— certificati di collegamento ERCA di seconda
generazione;
— certificati MSCA di seconda generazione;
— certificati della VU di seconda generazione rilasciati
dallo stesso paese del certificato o dei certificati della
carta stessa.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 478
Nota: quest'ultimo requisito implica che una carta sia in
grado di riconoscere il CAR del certificato della VU, vale
a dire il certificato MSCA_VU-EGF, che sarà diverso dal
CAR del suo stesso certificato, che è il certificato
MSCA_Card.
CSM_168 Come illustrato nella Figura 5, una volta verificata l'auten­
ticità e la validità di un certificato precedentemente scono­
sciuto, la carta può conservarlo per riferimento futuro, in
modo da non doverne nuovamente verificare l'autenticità se
viene nuovamente presentato alla carta. Invece di memoriz­
zare l'intero certificato, una carta può scegliere di memoriz­
zare solo il contenuto del corpo del certificato, come speci­
ficato nella sezione 9.3.2.
10.3. Autenticazione della VU
CSM_169 Le VU e le carte devono usare il protocollo di autentica­
zione della VU illustrato nella Figura 6 per autenticare la
VU nei confonti della carta. L'autenticazione della VU con­
sente alla carta tachigrafica di verificare esplicitamente che
la VU sia autentica; quest'ultima deve usare la sua chiave
privata per firmare una sfida (challenge) generata dalla
carta.
CSM_170 ►M1 Accanto alla sfida (challenge) della carta, la VU
deve includere nella firma il riferimento al titolare del cer­
tificato preso dal certificato della carta. ◄
Nota: ciò garantisce che la carta nei confonti della quale la
VU si sta autenticando sia la stessa carta di cui la VU ha
precedentemente verificato la catena di certificati.
CSM_171 La VU deve inoltre includere nella firma l'identificativo
della chiave pubblica temporanea Comp(VU.PK eph ) che la
VU stessa userà per la messaggistica sicura durante la pro­
cedura di autenticazione del chip specificata nella
sezione 10.4.
Nota: ciò garantisce che la VU con cui una carta comunica
durante una sessione di messaggistica sicura sia la stessa
VU che è stata autenticata dalla carta.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 479
Figura 6
Protocollo di autenticazione della VU
▼B
CSM_172 Se la VU invia molteplici comandi GET CHALLENGE
durante l'autenticazione, la carta deve restituire ogni volta
una nuova sfida (challenge) casuale a 8 byte, ma deve
memorizzare solo l'ultima sfida.
CSM_173 L'algoritmo di firma usato dalla VU per l'autenticazione
della VU deve essere ECDSA, come specificato in [DSS],
usando l'algoritmo di hash collegato alle dimensioni della
coppia di chiavi VU_MA della VU, come specificato in
CSM_50. Il formato della firma deve essere in chiaro,
come specificato in [TR-03111]. La VU deve inviare alla
carta la firma che ne risulta.
▼M1
CSM_174 Al ricevimento della firma della VU in un comando EX­
TERNAL AUTHENTICATE, la carta deve:
— calcolare il token di autenticazione concatenando
Card.CHR, la sfida (challenge) della carta rcard e l’iden­
tificativo della chiave pubblica temporanea della VU
Comp(VU.PKeph),
— verificare la firma della VU utilizzando l’algoritmo
ECDSA, in combinazione con l’algoritmo di hash col­
legato alle dimensioni della coppia di chiavi VU_MA
della VU, come specificato in CSM_50, in combina­
zione con VU.PK e il token di autenticazione calcolato.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 480
10.4. Autenticazione del chip e accordo sulla chiave di sessione
CSM_175 Le VU e le carte devono usare il protocollo di autentica­
zione del chip illustrato nella Figura 7 per autenticare la
carta verso la VU. L'autenticazione del chip consente alla
VU di verificare esplicitamente che la carta sia autentica.
Figura 7
Autenticazione del chip e accordo sulla chiave di sessione
CSM_176 La VU e la carta devono eseguire la seguente procedura:
1. la VU avvia la procedura di autenticazione del chip in­
viando il comando MSE: Set AT con l'indicazione «Au­
tenticazione del chip usando l'algoritmo ECDH che dà
come risultato una lunghezza della chiave di sessione
AES collegata alle dimensioni della coppia di chiavi
Card_MA della carta, come specificato in CSM_50».
La VU deve determinare le dimensioni della chiave della
coppia di chiavi della carta dal certificato della stessa.
▼M1
2. La VU invia alla carta il punto pubblico VU.PK eph della
sua coppia di chiavi temporanee. Il punto pubblico deve
essere convertito in stringhe di ottetti, come specificato
in [TR-03111]. Deve essere usato il formato di codifica
non compresso. Come spiegato in CSM_164, la VU ha
generato questa coppia di chiavi temporanee prima della
verifica della catena di certificati della VU. La VU ha
inviato alla carta l’identificativo della chiave pubblica
temporanea Comp(VU.PK eph ) e la carta lo ha
memorizzato.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 481
3. La carta calcola Comp(VU.PK eph ) da VU.PK eph e lo
confronta con il valore memorizzato di
Comp(VU.PK eph ).
4. Usando l'algoritmo ECDH in combinazione con la chiave
privata statica della carta e la chiave pubblica temporanea
della VU, la carta calcola una chiave segreta K.
5. La carta sceglie un nonce casuale a 8 byte N PICC e lo usa
per calcolare due chiavi di sessione AES K MAC e K ENC
da K. Cfr. CSM_179.
▼M1
6. Usando K MAC , la carta calcola un token di autentica­
zione sul punto pubblico temporaneo della VU: T PICC =
CMAC(K MAC , VU.PK eph ). Il punto pubblico deve avere
il formato utilizzato dalla VU (cfr. punto 2 in alto). La
carta invia N PICC e T PICC all’unità elettronica di bordo.
▼B
7. Usando l'algoritmo ECDH in combinazione con la
chiave pubblica statica della carta e la chiave privata
temporanea della VU, la VU calcola la stessa chiave
segreta K calcolata dalla carta nella fase 4.
8. La VU calcola le chiavi di sessione K MAC e K ENC da K
e N PICC ; cfr. CSM_179.
9. La VU verifica il token di autenticazione T PICC .
CSM_177 Nella precedente fase 3, la carta deve calcolare
Comp(VU.PKeph) come la coordinata x del
punto pubblico in VU.PKeph.
CSM_178 Nelle precedenti fasi 4 e 7, la carta e la VU devono usare
l'algoritmo ECKA-EG come definito in [TR- 03111].
CSM_179 Nelle precedenti fasi 5 e 8, la carta e la VU devono usare la
funzione di derivazione della chiave per le chiavi di ses­
sione AES definita in [TR- 03111], tenendo conto delle
seguenti precisazioni e modifiche:
— il valore del contatore deve essere «00 00 00 01» per
K ENC e «00 00 00 02» per K MAC ;
— il nonce facoltativo r deve essere usato e deve essere
uguale a N PICC ;
— per il calcolo delle chiavi AES a 128 bit, l'algoritmo di
hash da usare è SHA-256;
— per il calcolo delle chiavi AES a 192 bit, l'algoritmo di
hash da usare è SHA-384;
— per il calcolo delle chiavi AES a 256 bit, l'algoritmo di
hash da usare è SHA-512.
La lunghezza delle chiavi di sessione (vale a dire la lun­
ghezza in corrispondenza della quale viene troncato l'hash)
deve essere collegata alle dimensioni della coppia di chiavi
Card_MA, come specificato in CSM_50.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 482
CSM_180 Nelle precedenti fasi 6 e 9, la carta e la VU devono usare
l'algoritmo AES in modalità CMAC, come definito in [SP
800-38B]. La lunghezza di T PICC deve essere collegata alla
lunghezza delle chiavi di sessione AES, come specificato in
CSM_50.
10.5. Messaggistica sicura (Secure Messaging)
10.5.1 Principi generali
CSM_181 Tutti i comandi e le risposte scambiate tra una VU e una
carta tachigrafica, dopo un'autenticazione del chip con esito
positivo e fino alla fine della sessione, devono essere pro­
tette mediante messaggistica sicura.
CSM_182 La messaggistica sicura deve essere usata in modalità di
sola autenticazione, ad eccezione della lettura da un file
con condizioni di accesso SM-R-ENC-MAC-G2 (cfr.
appendice 2, sezione 4). Nella modalità di sola autentica­
zione, un totale di controllo crittografico (alias MAC) è
aggiunto a tutti i comandi e a tutte le risposte per garantire
l'autenticità e l'integrità del messaggio.
CSM_183 Per la lettura di dati da un file con condizioni di accesso
SM-R-ENC-MAC-G2, la messaggistica sicura deve essere
usata in modalità cifratura seguita da autenticazione (en­
crypt-then-authenticate), vale a dire i dati della risposta
sono in primo luogo criptati per garantire la riservatezza
del messaggio e successivamente viene calcolato un MAC
sui dati criptati formattati per garantirne l'autenticità e l'inte­
grità.
CSM_184 La messaggistica sicura deve utilizzare AES come definito
in [AES] con le chiavi di sessione K MAC e K ENC concordate
durante l'autenticazione del chip.
CSM_185 Un numero intero senza segno deve essere usato come con­
tatore sequenza di invio (SSC) per prevenire gli attacchi di
tipo replay attack. Le dimensioni dell'SSC devono essere
uguali alle dimensioni dei blocchi AES, vale a dire 128 bit.
L'SSC deve essere in formato MSB-first. Il contatore se­
quenza di invio deve essere inizializzato a zero (vale a
dire «00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00») all'inizio della messaggistica sicura. L'SSC deve essere
aumentato ogni volta prima che sia generato un comando o
una risposta APDU, vale a dire: poiché il valore di partenza
dell'SSC in una sessione SM è 0, nel primo comando il
valore dell'SSC sarà 1. Il valore dell'SSC per la prima ri­
sposta sarà 2.
CSM_186 Per criptare i messaggi, deve essere usata la chiave K ENC
con AES nella modalità di funzionamento a blocchi
incatenati (CBC), come definito in [ISO 10116], con un
parametro di interleave (interleave parameter) m = 1 e un
vettore di inizializzazione SV = E(K ENC , SSC), vale a dire il
valore corrente dell'SSC criptato con K ENC .
CSM_187 Per l'autenticazione del messaggio, K MAC deve essere usato
con AES in modalità CMAC come specificato in [SP 800-
38B]. La lunghezza del MAC deve essere collegata alla
lunghezza delle chiavi di sessione AES, come specificato
in CSM_50. Il contatore sequenza di invio deve essere in­
cluso nel MAC, aggiungendolo prima del datagramma da
autenticare.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 483
10.5.2 Struttura dei messaggi sicuri
CSM_188 La messaggistica sicura deve avvalersi solo di oggetti di
dati in messaggistica sicura (cfr. [ISO 7816-4]) elencati in
Tabella 5. In tutti i messaggi tali oggetti di dati devono
essere usati nell'ordine indicato nella seguente tabella.
Tabella 5
Oggetti di dati in messaggistica sicura
Nome dell'oggetto di dati (Data Object
Name)
Tag
Presenza(O)bbligatoria,(C­
)ondizionata o (V)ietata in
Comandi Risposte
Valore in chiaro, non codificato in
BER-TLV
«81» C C
Valore in chiaro, non codificato in
BER-TLV, ma che non include DO SM
«B3» C C
Indicatore di contenuto di riempimento
seguito da crittogramma, valore in
chiaro, non codificato in BER-TLV
«87» C C
Le protetto «97» C V
Stato di elaborazione «99» V O
Totale di controllo crittografico «8E» O O
Nota: come specificato nell'appendice 2, le carte tachigrafi­
che possono essere compatibili con i comandi READ BI­
NARY e UPDATE BINARY con un byte INS dispari
(«B1» risp. «D7»). Tali varianti di comandi sono necessarie
per leggere e aggiornare i file con più di 32 768 byte. Nel
caso in cui si usi tale variante, deve essere usato un oggetto
di dati con tag «B3» invece di uno con tag «81». Cfr.
appendice 2 per ulteriori informazioni.
CSM_189 Tutti gli oggetti di dati SM devono essere codificati in DER
TLV come specificato nella norma [ISO 8825-1]. Questa
codifica genera una struttura Tag-Lunghezza-Valore (TLV)
come segue:
Tag: il tag è codificato in uno o due ottetti e indica il
contenuto.
Lunghezza: la lunghezza è codificata come un numero in­
tero senza segno in uno, due o tre ottetti, fino a
una lunghezza massima di 65 535 ottetti. Deve
essere usato il numero minimo di ottetti.
Valore: il valore è codificato come zero o più ottetti.
CSM_190 Gli APDU protetti con messaggistica sicura devono essere
creati come segue:
— l'intestazione del comando (command header) deve es­
sere inclusa nel calcolo del MAC, pertanto per il byte
classe CLA deve essere usato il valore «0C».
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 484
— Come specificato nell'appendice 2, tutti i byte INS de­
vono essere pari, con l'eventuale eccezione di byte INS
dispari per i comandi READ BINARY e UPDATE BI­
NARY.
— Il valore effettivo di Lc sarà modificato in Lc' dopo
l'applicazione della messaggistica sicura.
— Il campo dati deve essere costituito da oggetti di dati
SM.
— Nel comando protetto APDU il nuovo byte Le deve
essere impostato a «00». Se necessario, nel campo di
dati deve essere incluso un oggetto di dati «97» per
trasmettere il valore iniziale di Le.
▼M1
CSM_191 Qualsiasi oggetto di dati da criptare deve essere riempito
conformemente alla norma [ISO 7816-4] usando l’indicatore
di contenuto di riempimento ’01’. Per il calcolo del MAC,
gli oggetti di dati nell’APDU devono essere riempiti se­
condo la norma [ISO 7816-4].
Nota: il riempimento per la messaggistica sicura è sempre
eseguito a livello di messaggistica sicura e non dagli algo­
ritmi CMAC o CBC.
Riepilogo ed esempi
Un comando APDU con messaggistica sicura applicata avrà la seguente
struttura, a seconda del caso del rispettivo comando non sicuro (DO
corrisponde a oggetto di dati):
Caso 1: CLA INS P1 P2 || Lc’ || DO ’8E’ || Le
Caso 2: CLA INS P1 P2 || Lc’ || DO ’97’ || DO ’8E’
|| Le
Caso 3 (byte INS pari): CLA INS P1 P2 || Lc’ || DO ’81’ || DO ’8E’
|| Le
Caso 3 (byte INS dispari): CLA INS P1 P2 || Lc’ || DO ’B3’ || DO ’8E’
|| Le
Caso 4 (byte INS pari):: CLA INS P1 P2 || Lc’ || DO ’81’ || DO ’97’
|| DO ’8E’ || Le
Caso 4 (byte INS dispari): CLA INS P1 P2 || Lc’ || DO ’B3’ || DO ’97’
|| DO ’8E’ || Le
dove Le = ’00’ o ’00 00’ a seconda che siano usati campi brevi o lunghi;
cfr. [ISO 7816-4].
Una risposta APDU con messaggistica sicura applicata avrà la seguente
struttura, a seconda del caso della rispettiva risposta non sicura:
Caso 1 o 3: DO ’99’ || DO ’8E’ ||
SW1SW2
Caso 2 o 4 (byte INS pari) non criptato: DO ’81’ || DO ’99’ || DO
’8E’ || SW1SW2
Caso 2 o 4 (byte INS pari) criptato: DO ’87’ || DO ’99’ || DO
’8E’ || SW1SW2
Caso 2 o 4 (byte INS dispari) non
criptato:
DO ’B3’ || DO ’99’ || DO
’8E’ || SW1SW2
Nota: il caso 2 o 4 (byte INS dispari) criptato non è mai usato nella
comunicazione tra una VU e una carta.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 485
Di seguito tre esempi di trasformazioni APDU per comandi con codice
INS pari. La figura 8 mostra un comando APDU caso 4 autenticato, la
figura 9 una risposta APDU caso 1/caso 3 autenticata e la figura 10 una
risposta APDU, caso 2/caso 4 autenticata e criptata.
Figura 8
Trasformazione di un comando APDU caso 4 autenticato
Figura 9
Trasformazione di una risposta APDU caso 1 / caso 3 autenticata
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 486
Figura 10
Trasformazione di una risposta APDU caso 2 / caso 4 criptata e autenticata
▼B
10.5.3 Interruzione di una sessione di messaggistica sicura
CSM_192 Una VU deve interrompere una sessione di messaggistica
sicura (SM) in corso se e solo se si verifica una delle seguenti
condizioni:
— la VU riceve una risposta APDU in chiaro;
— la VU individua un errore di messaggistica sicura in una
risposta APDU:
— manca un oggetto di dati atteso in messaggistica si­
cura, l'ordine degli oggetti di dati è errato o è incluso
un oggetto di dati sconosciuto,
— un oggetto di dati in messaggistica sicura non è cor­
retto, ad esempio il valore MAC non è corretto, la
struttura TLV non è corretta, o l'indicatore di riempi­
mento nel tag «87» non è uguale a «01»;
— la carta invia un byte di status che indica che ha riscon­
trato un errore di SM (cfr. CSM_194);
— si è raggiunto il limite per il numero di comandi e di
risposte associate all'interno della sessione corrente. Per
una data VU, tale limite deve essere definito dal suo
fabbricante, tenendo conto dei requisiti di sicurezza dell'­
hardware usato, con un valore massimo di 240 comandi di
SM e risposte associate per sessione.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 487
CSM_193 Una carta tachigrafica deve interrompere una sessione di mes­
saggistica sicura in corso se e solo se si verifica una delle
seguenti condizioni:
— la carta tachigrafica riceve un comando APDU in chiaro;
— la carta tachigrafica individua un errore di messaggistica
sicura in un comando APDU:
— manca un oggetto di dati atteso in messaggistica si­
cura, l’ordine degli oggetti di dati è errato o è incluso
un oggetto di dati sconosciuto,
— un oggetto di dati in messaggistica sicura non è cor­
retto, ad esempio il valore MAC non è corretto o la
struttura TLV non è corretta;
— la carta non è più alimentata o viene reinizializzata;
— la VU inizia la procedura di autenticazione della VU;
— è stato raggiunto il limite per il numero di comandi e di
risposte associate nell’ambito della sessione corrente. Per
una data carta, tale limite deve essere definito dal suo
fabbricante, tenendo conto dei requisiti di sicurezza
dell’hardware usato, con un valore massimo di 240 co­
mandi di SM e risposte associate per sessione.
▼B
CSM_194 Per quanto riguarda l'errore di SM gestito da una carta
tachigrafica:
— se in un comando APDU mancano alcuni oggetti di dati
in messaggistica sicura attesi, l'ordine degli oggetti di dati
non è corretto o sono inclusi oggetti di dati sconosciuti,
una carta tachigrafica deve rispondere con i byte di stato
«69 87»;
— se un oggetto di dati in messaggistica sicura in un co­
mando APDU non è corretto, una carta tachigrafica deve
rispondere con i byte di stato «69 88».
In tal caso i byte di stato devono essere restituiti senza usare
SM.
CSM_195 Se una sessione di messaggistica sicura tra una VU e una
carta tachigrafica viene interrotta, la VU e le carte tachigrafi­
che devono:
— distruggere in modo sicuro le chiavi di sessione
memorizzate;
— stabilire immediatamente una nuova sessione di messaggi­
stica sicura, come descritto nelle sezioni 10.2 — 10.5.
CSM_196 Se per qualsiasi motivo la VU decide di riavviare l'autentica­
zione reciproca nei confronti di una carta inserita, la proce­
dura deve riprendere con la verifica della catena di certificati
della carta, come descritto nella sezione 10.2, e poi continuare
come descritto nelle sezioni 10.2 — 10.5.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 488
11. ACCOPPIAMENTO, AUTENTICAZIONE RECIPROCA E MESSAG­
GISTICA SICURA TRA VU E DISPOSITIVO GNSS ESTERNO
11.1. Principi generali
CSM_197 Il dispositivo GNSS usato da una VU per determinare la sua
posizione può essere interno (ossia costruito all'interno del­
l'involucro della VU e non amovibile) o può essere un mo­
dulo esterno. Nel primo caso non vi è alcuna necessità di
standardizzare la comunicazione interna tra il dispositivo
GNSS e la VU, pertanto i requisiti di cui al presente capitolo
non si applicano. Nel secondo caso, la comunicazione tra la
VU e il dispositivo GNSS esterno deve essere standardizzata
e protetta come indicato al presente capitolo.
CSM_198 La comunicazione sicura tra l'unità elettronica di bordo e un
dispositivo GNSS esterno deve avvenire nello stesso modo
della comunicazione sicura tra una VU e una carta tachigra­
fica, con il dispositivo GNSS esterno (EGF) nel ruolo della
carta. Tutti i requisiti di cui al capitolo 10 per le carte tachi­
grafiche devono essere soddisfatti da un EGF, tenuto conto
delle variazioni, dei chiarimenti e delle integrazioni di cui al
presente capitolo. In particolare la verifica reciproca della
catena di certificati, dell'autenticazione della VU e dell'auten­
ticazione del chip deve essere effettuata come descritto nelle
sezioni 11.3 e 11.4.
CSM_199 La comunicazione tra la VU e un EGF differisce dalla comu­
nicazione tra una VU e una carta nel fatto che è necessario
che una VU e un EGF siano stati accoppiati una volta in
officina prima di potersi scambiarsi dati basati su GNSS du­
rante il funzionamento normale. La procedura di accoppia­
mento è descritta nella sezione 11.2.
CSM_200 Per la comunicazione tra una VU e un EGF devono essere
usati i comandi e le risposte APDU basati sulle norme [ISO
7816-4] e [ISO 7816-8]. La struttura esatta di tali APDU è
definita nell'appendice 2 del presente allegato.
11.2. Accoppiamento tra VU e dispositivo GNSS esterno
CSM_201 L'accoppiamento tra una VU e un EGF di un veicolo deve
essere eseguito in officina. Solo una VU e un EGF che sono
stati accoppiati sono in grado di comunicare durante il fun­
zionamento normale.
CSM_202 L'accoppiamento tra una VU e un EGF è possibile solo se la
VU è in modalità taratura. L'accoppiamento deve essere av­
viato dalla VU.
CSM_203 Un'officina può riaccoppiare una VU con un altro o con lo
stesso EGF in qualsiasi momento. Durante il riaccoppiamento
la VU deve cancellare dalla sua memoria in modo sicuro il
certificato EGF_MA esistente e memorizzare il certificato
EGF_MA dell'EGF a cui viene accoppiata.
CSM_204 Un'officina può riaccoppiare un dispositivo GNSS esterno con
un'altra o con la stessa VU in qualsiasi momento. Durante il
riaccoppiamento l'EGF deve cancellare dalla sua memoria in
modo sicuro il certificato VU_MA esistente e memorizzare il
certificato VU_MA della VU a cui viene accoppiato.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 489
11.3. Verifica reciproca della catena di certificati
11.3.1 Principi generali
CSM_205 La verifica reciproca della catena di certificati tra una VU e
un EGF deve avvenire solo durante l'accoppiamento della VU
con l'EGF in officina. Durante il funzionamento normale di
una VU e un EGF accoppiati, nessun certificato deve essere
verificato, poiché la VU e l'EGF devono fidarsi dei certificati
che hanno memorizzato durante l'accoppiamento, dopo averne
verificato la validità temporale. Per proteggere la comunica­
zione tra la VU e l'EFG, questi ultimi non devono fidarsi di
nessun altro certificato.
11.3.2 Durante l'accoppiamento tra VU e EFG
CSM_206 Durante l'accoppiamento con un EFG, una VU deve usare il
protocollo illustrato nella Figura 4 (sezione 10.2.1) per veri­
ficare la catena di certificati del dispositivo GNSS esterno.
Note alla Figura 4 in questo contesto:
— il controllo della comunicazione non rientra nel campo di
applicazione della presente appendice. L'EGF non è tutta­
via una carta intelligente (smart card), per cui la VU
probabilmente non invierà un comando di reinizializza­
zione (Reset) per avviare la comunicazione e non riceverà
un ATR.
— I certificati e le chiavi pubbliche della carta citati nella
figura devono essere interpretati come i certificati e le
chiavi pubbliche dell'EGF per l'autenticazione reciproca.
Nella sezione 9.1.6 sono indicati come EGF_MA.
— I certificati Card.CA e le chiavi pubbliche citati nella
figura devono essere interpretati come i certificati e le
chiavi pubbliche dell'MSCA per la firma dei certificati
EGF. Nella sezione 9.1.3 sono indicati come
MSCA_VU-EGF.
— Il certificato Card.CA.EUR citato nella figura deve essere
interpretato come il certificato radice europeo indicato nel
CAR del certificato MSCA_VU-EGF.
— Il certificato Card.Link citato nella figura deve essere in­
terpretato come il certificato di collegamento dell'EGF, se
presente. Come specificato nella sezione 9.1.2, si tratta di
un certificato di collegamento per una nuova coppia di
chiavi radice europee creata dalla ERCA e firmata con
la precedente chiave privata europea.
— Il certificato Card.Link.EUR è il certificato radice europeo
indicato nel CAR del certificato Card.Link.
— Invece del , la VU deve
leggere il dall'EF ICC.
— Invece di selezionare Tachograph AID, la VU deve sele­
zionare EGF AID.
— «Ignore Card» (Ignora Carta) deve essere interpretato
come «Ignore EGF» (Ignora EGF).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 490
CSM_207 Dopo la verifica del certificato EGF_MA, la VU deve memo­
rizzare tale certificato da usare durante il funzionamento nor­
male; cfr. sezione 11.3.3.
CSM_208 ►M1 Durante l’accoppiamento alla VU, il dispositivo GNSS
esterno deve usare il protocollo illustrato nella figura 5 (punto
10.2.2) per verificare la catena di certificati della VU. ◄
Note alla Figura 5 in questo contesto:
— la VU deve generare una nuova coppia di chiavi tempo­
ranee usando i parametri di dominio nel certificato EGF.
— I certificati e le chiavi pubbliche della VU citati nella
figura sono quelli usati per l'autenticazione reciproca.
Nella sezione 9.1.4 sono indicati come VU_MA.
— I certificati e le chiavi pubbliche VU.CA citati nella figura
sono quelli usati per firmare i certificati della VU e del
dispositivo GNSS esterno. Nella sezione 9.1.3 sono indi­
cati come MSCA_VU-EGF.
— Il certificato VU.CA.EUR citato nella figura è il certifi­
cato radice europeo indicato nel CAR del certificato
VU.CA.
— Il certificato VU.Link indicato nella figura è il certificato
di collegamento della VU, se presente. Come specificato
nella sezione 9.1.2, si tratta di un certificato di collega­
mento per una nuova coppia di chiavi radice europee
creata dalla ERCA e firmata con la precedente chiave
privata europea.
— Il certificato VU.Link.EUR è il certificato radice europeo
indicato nel CAR del certificato VU.Link.
CSM_209 A differenza di quanto previsto nel requisito CSM_167, un
EGF deve usare l'ora del GNSS per verificare la validità
temporale di qualsiasi certificato presentato.
▼M1
CSM_210 Dopo la verifica del certificato VU_MA, il dispositivo GNSS
esterno deve memorizzare tale certificato da usare durante il
funzionamento normale; cfr. sezione 11.3.3.
▼B
11.3.3 Durante il funzionamento normale
CSM_211 ►M1 Durante il funzionamento normale, la VU e l’EGF
devono usare il protocollo della figura 11 per verificare la
validità temporale del certificato EGF_MA memorizzato e
per impostare la chiave pubblica VU_MA per la successiva
autenticazione della VU. Durante il normale funzionamento
non deve aver luogo nessun’altra verifica reciproca delle ca­
tene di certificati. ◄
Da notare che la Figura 11 è costituita sostanzialmente dalle
prime fasi illustrate nella Figura 4 e nella Figura 5. Si noti
inoltre che un EGF non è una carta intelligente (smart card),
per cui la VU probabilmente non invierà un comando di
reinizializzazione (Reset) per avviare la comunicazione e
non riceverà un ATR. In ogni caso ciò non rientra nel campo
di applicazione della presente appendice.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 491
Figura 11
Verifica reciproca della validità temporale dei certificati durante un funzionamento normale VU — EGF
CSM_212 Come illustrato nella Figura 11, la VU deve registrare un
errore se il certificato EGF_MA non è più valido. L'autenti­
cazione reciproca, l'accordo sulla chiave e la successiva co­
municazione mediante messaggistica sicura devono tuttavia
proseguire normalmente.
11.4. Autenticazione della VU, autenticazione del chip e accordo sulla
chiave di sessione
CSM_213 L'autenticazione della VU, l'autenticazione del chip e l'ac­
cordo sulla chiave di sessione tra una VU e un EGF devono
avere luogo nel corso delle operazioni di accoppiamento e
ogniqualvolta si ripristini una sessione di messaggistica sicura
durante il funzionamento normale. La VU e l'EFG devono
eseguire le procedure descritte nelle sezioni 10.3 e 10.4. Si
applicano tutti i requisiti di tali sezioni.
11.5. Messaggistica sicura
CSM_214 Tutti i comandi e le risposte scambiate tra una VU e un
dispositivo GNSS esterno, dopo un'autenticazione del chip
con esito positivo e fino alla fine della sessione, devono
essere protette mediante messaggistica sicura in modalità di
sola autenticazione. Si applicano tutti i requisiti della
sezione 10.5.
CSM_215 Se si interrompe una sessione di messaggistica sicura tra una
VU e un EFG, la VU deve stabilire immediatamente una
nuova sessione di messaggistica sicura, come descritto nelle
sezioni 11.3.3 e 11.4.
12. ABBINAMENTO E COMUNICAZIONE TRA VU E SENSORE DI
MOVIMENTO
12.1. Principi generali
CSM_216 La VU e il sensore di movimento devono comunicare usando
il protocollo di interfaccia specificato nella norma [ISO
16844-3] durante l'abbinamento e in condizioni di funziona­
mento normale, con le modifiche descritte nel presente capi­
tolo e nella sezione 9.2.1.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 492
Nota: si presume che i lettori del presente capitolo conoscano
il contenuto della norma [ISO 16844-3].
12.2. Abbinamento tra VU e sensore di movimento usando diverse gene­
razioni di chiavi
Come spiegato nella sezione 9.2.1, la chiave master del sensore di mo­
vimento e tutte le chiavi associate vengono periodicamente sostituite. Ciò
fa sì che le carte dell'officina possano contenere fino a tre chiavi AES
relative al sensore di movimento K M-WC (di generazioni consecutive).
Analogamente i sensori di movimento possono contenere fino a tre di­
verse cifrature di dati basate su AES (basate su generazioni consecutive
della chiave master del sensore di movimento K M ). Una VU contiene una
sola chiave relativa al sensore di movimento K M-VU .
CSM_217 Una VU di seconda generazione e un sensore di movimento
di seconda generazione devono essere abbinati come segue
(cfr. tabella 6 nella norma [ISO 16844-3]):
1. si inserisce una carta dell'officina di seconda generazione
nella VU e si collega quest'ultima al sensore di
movimento.
2. La VU legge tutte le chiavi K M-WC disponibili dalla carta
dell'officina, controlla i rispettivi numeri di versione e sce­
glie quella il cui numero di versione corrisponde alla
chiave K M-VU della VU. Se nella carta dell'officina non
è presente la corrispondente chiave K M-WC , la VU inter­
rompe la procedura di abbinamento e mostra un messaggio
di errore apposito al titolare della carta dell'officina.
3. La VU calcola la chiave master del sensore di movimento
K M da K M-VU e K M-WC e la chiave di identificazione K ID
da K M , come specificato nella sezione 9.2.1.
4. La VU invia l'istruzione di avviare la procedura di abbi­
namento con il sensore di movimento, come descritto nella
norma [ISO 16844-3], e cripta il numero di serie che
riceve dal sensore di movimento con la chiave di identifi­
cazione K ID . La VU restituisce il numero di serie criptato
al sensore di movimento.
5. Il sensore di movimento confronta il numero di serie crip­
tato con ciascuna delle cifrature del numero di serie che
contiene, in successione. Se ne trova una che corrisponde,
la VU viene autenticata. Il sensore di movimento nota la
generazione della K ID usata dalla VU e restituisce la corri­
spondente versione criptata della sua chiave di abbina­
mento; vale a dire la cifratura creata usando la stessa
generazione di K M .
6. La VU decripta la chiave di accoppiamento usando K M ,
genera una chiave di sessione K S , la cripta con la chiave di
abbinamento e invia il risultato al sensore di movimento. Il
sensore di movimento decripta K S .
7. La VU assembla le informazioni di accoppiamento come
definito nella norma [ISO 16844-3], cripta le informazioni
con la chiave di abbinamento e invia il risultato al sensore
di movimento. Il sensore di movimento decripta le infor­
mazioni di abbinamento.
8. Il sensore di movimento cripta le informazioni di abbina­
mento con la chiave K S che ha ricevuto e le restituisce alla
VU. La VU verifica che le informazioni di abbinamento
siano le stesse informazioni inviate dalla VU al sensore di
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 493
movimento nella fase precedente. Se sì, il sensore di mo­
vimento ha usato la stessa K S della VU e pertanto nella
fase 5 ha inviato la chiave di abbinamento cifrata con la
generazione corretta di K M . Il sensore di movimento viene
quindi autenticato.
Da notare che le fasi 2 e 5 sono diverse dalla procedura
standard della norma [ISO 16844-3]; le altre fasi sono
standard.
Esempio: supponiamo che un abbinamento abbia luogo nel
corso del primo anno di validità del certificato ERCA (3); cfr.
la Figura 2 nella sezione 9.2.1.2. Inoltre
— supponiamo che il sensore di movimento sia stato rila­
sciato nell'ultimo anno di validità del certificato ERCA
(1). Esso conterrà quindi i seguenti dati e chiavi:
— N s [1]: numero di serie criptato con la generazione 1
della chiave K ID ,
— N s [2]: numero di serie criptato con la generazione 2
della chiave K ID ,
— N s [3]: numero di serie criptato con la generazione 3
della chiave K ID ,
— K P [1]: chiave di abbinamento della generazione 1 ( 1 ),
criptata con la generazione 1 della chiave K M ,
— K P [2]: chiave di abbinamento di seconda generazione,
criptata con la generazione 2 della chiave K M ,
— K P [3]: chiave di abbinamento di terza generazione,
criptata con la generazione 3 della chiave K M ,
— supponiamo che la carta dell'officina sia stata rilasciata nel
primo anno di validità del certificato ERCA (3). Essa
conterrà pertanto la seconda e la terza generazione della
chiave K M-WC .
— Supponiamo che la VU sia di seconda generazione e che
contenga la chiave K M-VU di seconda generazione.
In tal caso nelle fasi da 2 a 5 si verificherà quanto segue:
— Fase 2: la VU legge la generazione 2 e la generazione 3
della chiave K M-WC dalla carta dell'officina e controlla il
loro numero di versione.
— Fase 3: la VU combina la chiave K M-WC di seconda ge­
nerazione con la sua chiave K M-VU per calcolare K M e
K ID.
— Fase 4: la VU cripta il numero di serie che riceve dal
sensore di movimento con la chiave K ID .
— Fase 5: il sensore di movimento confronta i dati ricevuti
con N s [1] e non trova corrispondenze. Successivamente
confronta i dati con N s [2] e trova una corrispondenza. Il
sensore di movimento conclude che la VU è di seconda
generazione e quindi restituisce K P [2].
▼B
( 1 ) Da notare che le chiavi di abbinamento di prima, seconda e terza generazione possono in
realtà essere la stessa chiave o possono essere tre chiavi diverse con diverse lunghezze,
come spiegato in CSM_117.
02016R0799 — IT — 21.08.2023 — 003.002 — 494
12.3. Abbinamento e comunicazione tra VU e sensore di movimento
usando AES
CSM_218 Come specificato nella Tabella 3 della sezione 9.2.1, tutte le
chiavi coinvolte nell'abbinamento di una VU (di seconda ge­
nerazione) con un sensore di movimento (MoS) e nelle suc­
cessive comunicazioni devono essere chiavi AES, invece di
chiavi in TDES a doppia lunghezza come specificato nella
norma [ISO 16844-3]. Tali chiavi AES possono avere una
lunghezza di 128, 192 o 256 bit. Poiché le dimensioni dei
blocchi AES sono di 16 byte, la lunghezza di un messaggio
criptato deve essere un multiplo di 16 byte, rispetto agli 8
byte per il TDES. Alcuni di questi messaggi saranno inoltre
usati per trasportare le chiavi AES, la cui lunghezza può
essere di 128, 192 o 256 bit. Il numero di byte di dati per
ciascuna istruzione nella tabella 5 della norma [ISO 16844-3]
deve pertanto essere modificato come indicato nella Ta­
bella 6:
▼M1
Tabella 6
Numero di byte di dati di testo in chiaro (plaintext) e criptati per istruzione definiti in [ISO 16844-3]
Istruzione
Richiesta / ri­
sposta
Descrizione dei dati
# di byte di dati di
testo in chiaro
(plaintext) secondo
[ISO 16844-3]
# di byte di dati di
testo in chiaro
(plaintext) usando
chiavi AES
# di byte di dati criptati usando
chiavi AES di lunghezza (in
bit)
128 192 256
10 richiesta Dati di autenticazione
+ numero del file
8 8 16 16 16
11 risposta Dati di autenticazione
+ contenuto del file
16 o 32 a seconda
del file
16 o 32 a seconda
del file
32 / 48 32 / 48 32 / 48
41 richiesta Numero di serie MoS 8 8 16 16 16
41 risposta Chiave di abbina­
mento
16 16 / 24 / 32 16 32 32
42 richiesta Chiave di sessione 16 16 / 24 / 32 16 32 32
43 richiesta Informazioni di abbi­
namento
24 24 32 32 32
50 risposta Informazioni di abbi­
namento
24 24 32 32 32
70 richiesta Dati di autenticazione 8 8 16 16 16
80 risposta Valore del contatore
del MoS + dati di au­
tenticazione
8 8 16 16 16
▼B
CSM_219 Le informazioni di abbinamento inviate nell'istruzione 43 (ri­
chiesta della VU) e 50 (risposta del MoS) devono essere
assemblate come specificato nella sezione 7.6.10 della norma
[ISO 16844-3], con la differenza che deve essere usato l'al­
goritmo AES invece dell'algoritmo TDES nello schema di
cifratura dei dati di abbinamento, generando quindi due cifra­
ture AES e adottando il riempimento specificato in CSM_220
per rispettare le dimensioni del blocco AES. La chiave K' p
usata per tale cifratura deve essere generata come segue:
— nel caso in cui la chiave di abbinamento K P sia lunga 16
byte: K' p = K P XOR (N s ||N s );
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 495
— nel caso in cui la chiave di abbinamento K P sia lunga 24
byte: K' p = K P XOR (N s ||N s ||N s );
— nel caso in cui la chiave di abbinamento K P sia lunga 32
byte: K' p = K P XOR (N s ||N s ||N s ||N s );
dove N S è il numero di serie a 8 byte del sensore di
movimento.
CSM_220 Nel caso in cui la lunghezza dei dati di testo in chiaro
(usando le chiavi AES) non sia un multiplo di 16 byte,
deve essere usato il metodo di riempimento 2 definito nella
norma [ISO 9797-1].
Nota: nella norma [ISO 16844-3], il numero di byte di dati di
testo in chiaro è sempre un multiplo di 8, in modo che non
sia necessario alcun riempimento quando si usa TDES. La
definizione dei dati e dei messaggi della norma [ISO
16844-3] non è modificata da questa parte della presente
appendice, che quindi richiede l'uso del riempimento.
CSM_221 Per l'istruzione 11 e nel caso sia necessario criptare più di un
blocco di dati, deve essere usata la modalità di funzionamento
a blocchi incatenati (CBC) come definito nella norma [ISO
10116], con un parametro di interleave m = 1. L'IV da usare è
— per l'istruzione 11: il blocco di autenticazione a 8 byte
indicato alla sezione 7.6.3.3 della norma [ISO 16844-3],
riempito usando il metodo di riempimento 2 definito nella
norma [ISO 9797-1]; cfr. anche le sezioni 7.6.5 e 7.6.6
della norma [ISO 16844-3].
— Per tutte le altre istruzioni in cui sono trasferiti più di 16
byte come specificato nella Tabella 6: «00» {16}, vale a
dire sedici byte con valore binario 0.
Nota: come indicato nelle sezioni 7.6.5 e 7.6.6 della norma
[ISO 16844-3], quando il MoS cripta i file di dati per l'in­
clusione nell'istruzione 11, il blocco di autenticazione è sia:
— usato come vettore di inizializzazione per la cifratura dei
file di dati in modalità CBC, che
— criptato e incluso come primo blocco nei dati inviati alla
VU.
12.4. Abbinamento tra VU e sensore di movimento per diverse generazioni
di apparecchi
CSM_222 Come spiegato nella sezione 9.2.1, un sensore di movimento
di seconda generazione può contenere la cifratura basata su
TDES dei dati di abbinamento (come definito nella parte A
della presente appendice), che gli permette di essere abbinato
a una VU di prima generazione. In tal caso, una VU di prima
generazione e un sensore di movimento di seconda genera­
zione devono essere abbinati come descritto nella parte A
della presente appendice e nella norma [ISO 16844-3]. Per
l'abbinamento è possibile usare sia una carta dell'officina di
prima generazione che una di seconda generazione.
Note:
— Non è possibile accoppiare una VU di seconda genera­
zione a un sensore di movimento di prima generazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 496
— Non è possibile usare una carta dell'officina di prima
generazione per l'accoppiamento di una VU di seconda
generazione a un sensore di movimento.
13. SICUREZZA PER LA COMUNICAZIONE REMOTA ATTRAVERSO
DSRC
13.1. Principi generali
Come specificato nell'appendice 14, la VU genera periodicamente dati di
monitoraggio del tachigrafo a distanza (Remote Tachograph Monitoring
— RTM) e li trasmette al dispositivo (interno o esterno) di comunica­
zione remota (Remote Communication Facility — RCF). Il dispositivo di
comunicazione remota è responsabile dell'invio di tali dati all'interroga­
tore remoto attraverso l'interfaccia DSRC descritta nell'appendice 14.
L'appendice 1 specifica che i dati RTM sono la concatenazione di:
payload (dati utili trasmessi) criptato del tachigrafo cifratura del pay­
load del tachigrafo;
dati di sicurezza DSRC come da descrizione che segue
Il formato in chiaro dei dati payload del tachigrafo è specificato nell'ap­
pendice 1 ed ulteriormente descritto nell'appendice 14. La presente
sezione descrive la struttura dei dati di sicurezza DSRC; la specifica
formale è descritto nell'appendice 1.
CSM_223 I dati di testo in chiaro trasmessi da
una VU a un dispositivo di comunicazione remota (se l'RCF è
esterno alla VU) o dalla VU all'interrogatore remoto tramite
l'interfaccia DSRC (se l'RCF è interno alla VU) devono essere
protetti in modalità cifratura seguita da autenticazione (en­
crypt-then-authenticate), cioè in primo luogo si criptano i
dati payload del tachigrafo per garantire la riservatezza del
messaggio e successivamente si calcola un MAC per garantire
l'autenticità e l'integrità dei dati.
CSM_224 I dati di sicurezza DSRC devono essere costituiti dalla con­
catenazione dei seguenti elementi di dati nell'ordine seguente;
cfr. anche Figura 12:
data e ora correnti la data e l'ora correnti della VU (tipo di dati
);
contatore un contatore da 3 byte, cfr. CSM_225;
▼M1
numero di serie della VU Il numero di serie della VU o l’identificativo
della richiesta di certificato (tipo di dati Vu­
SerialNumber o CertificateRequestID) – cfr.
CSM_123;
▼B
numero di versione della chiave master DSRC il numero di versione da un byte della chiave
master DSRC da cui sono calcolate le chiavi
DSRC specifiche della VU, cfr. sezione 9.2.2;
MAC il MAC calcolato su tutti i byte precedenti dei
dati RTM.
CSM_225 Il contatore da 3 byte nei dati di sicurezza DSRC deve essere
in formato MSB-first. La prima volta che una VU calcola una
serie di dati RTM dopo essere stata messa in produzione, il
valore del contatore deve essere impostato a 0. La VU deve
aumentare di 1 il valore del contatore di dati ogni volta che si
appresta a calcolare una nuova serie di dati RTM.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 497
13.2. Cifratura del payload del tachigrafo e generazione del MAC
CSM_226 Dato un elemento di dati in chiaro con tipo di dati
come descritto nell'appendice 14,
la VU deve criptare tali dati come illustrato nella Figura
12: deve essere usata la chiave DSRC per la cifratura
K_VU DSRC _ENC (cfr. sezione 9.2.2) con AES modalità di
funzionamento a blocchi incatenati (CBC), come definito
nella norma [ISO 10116], con un parametro di interleave m
= 1. Il vettore di inizializzazione deve essere uguale a IV =
data e ora correnti || «00 00 00 00 00 00 00 00 00» ||
contatore, dove data e ora correnti e contatore sono speci­
ficati in CSM_224. I dati da criptare devono essere riempiti
usando il metodo 2 definito nella norma [ISO 9797-1].
CSM_227 La VU deve calcolare il MAC nei dati di sicurezza DSRC
come indicato nella Figura 12: il MAC deve essere calcolato
su tutti i byte precedenti nei dati RTM, fino al numero di
versione della chiave master DSRC incluso, includendo i tag
e le lunghezze degli oggetti di dati. La VU deve usare la sua
chiave DSRC per autenticità K_VU DSRC _MAC (cfr.
sezione 9.2.2) con l'algoritmo AES in modalità CMAC
come specificato in [SP 800-38B]. La lunghezza del MAC
deve essere collegata alla lunghezza delle chiavi DSRC spe­
cifiche della VU, come specificato in CSM_50.
Figura 12
Cifratura del payload del tachigrafo e generazione del MAC
13.3. Verifica e decifratura del payload del tachigrafo
CSM_228 Quando un interrogatore remoto riceve dati RTM da una VU,
esso deve inviare l'intero pacchetto di dati RTM a una carta di
controllo nel campo dati di un comando PROCESS DSRC
MESSAGE, come descritto nell'appendice 2. Successiva­
mente:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 498
1. la carta di controllo deve verificare il numero di versione
della chiave master DSRC nei dati di sicurezza DSRC. Se
non conosce la chiave master DSRC indicata, la carta di
controllo deve restituire un errore specificato nell'appen­
dice 2 e interrompere la procedura.
▼M1
2. La carta di controllo deve usare la chiave master DSRC
indicata in combinazione con il numero di serie della VU
o l’identificativo della richiesta di certificato nei dati di
sicurezza DSRC per calcolare le chiavi DSRC specifiche
della VU K_VU DSRC _ENC e K_VU DSRC _MAC, come
specificato in CSM_124.
▼B
3. La carta di controllo deve usare K_VU DSRC _MAC per
verificare il MAC nei dati di sicurezza DSRC, come spe­
cificato in CSM_227. Se il MAC non è corretto, la carta di
controllo deve restituire un errore specificato nell'appen­
dice 2 e interrompere la procedura.
4. La carta di controllo deve usare K_VU DSRC _ENC per de­
criptare il payload criptato del tachigrafo, come specificato
in CSM_226. La carta di controllo deve eliminare il riem­
pimento e restituire i dati payload decriptati del tachigrafo
all'interrogatore remoto.
CSM_229 Al fine di impedire attacchi di tipo replay attack, l'interroga­
tore remoto deve verificare l'attualità dei dati RTM verifi­
cando che data e ora correnti nei dati di sicurezza DSRC
non si discostino eccessivamente dall'ora corrente dell'interro­
gatore remoto.
Note:
— ciò implica che l'interrogatore remoto usi una sorgente
oraria precisa e affidabile.
— Poiché secondo l'appendice 14 la VU calcola una nuova
serie di dati RTM ogni 60 secondi e l'orologio della VU
può discostarsi di 1 minuto dall'ora effettiva, il limite in­
feriore per l'attualità dei dati RTM è di 2 minuti. L'attualità
effettiva necessaria dipende anche dalla precisione dell'oro­
logio dell'interrogatore remoto.
CSM_230 Quando verifica il corretto funzionamento della funzionalità
DSRC di una VU, l'officina deve inviare l'intero pacchetto di
dati RTM ricevuti dalla VU a una carta dell'officina nel
campo dati di un comando PROCESS DSRC MESSAGE,
come descritto nell'appendice 2. La carta dell'officina deve
effettuare tutti i controlli e le azioni specificati in CSM_228.
14. FIRMA DEL TRASFERIMENTO DEI DATI E VERIFICA DELLE
FIRME
14.1. Principi generali
CSM_231 L'apparecchio intelligente dedicato (Intelligent Dedicated
Equipment — IDE) deve memorizzare in un file di dati fisico
i dati ricevuti da una VU o da una carta durante una sessione
di trasferimento. I dati possono essere memorizzati in un
dispositivo di memorizzazione esterno (ESM). Tale file con­
tiene firme digitali su blocchi di dati, come specificato nel­
l'appendice 7, e deve contenere inoltre i seguenti certificati
(cfr. sezione 9.1):
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 499
— in caso di trasferimento dei dati su VU:
— il certificato VU_Sign,
— il certificato MSCA_VU-EGF contenente la chiave
pubblica da usare per la verifica del certificato
VU_Sign;
— in caso di trasferimento dei dati su carta:
— il certificato Card_Sign,
— il certificato MSCA_Card contenente la chiave pub­
blica da usare per la verifica del certificato Card_Sign.
CSM_232 L'IDE deve anche disporre di:
— nel caso usi una carta di controllo per verificare la firma,
come illustrato nella Figura 13: il certificato di collega­
mento che collega l'ultimo certificato EUR
al certificato EUR il cui periodo di validità è immediata­
mente precedente, se esistenti;
— nel caso verifichi esso stesso la firma: tutti i certificati
radice europei validi.
Nota: il metodo usato dall'IDE per recuperare tali certificati
non è specificato nella presente appendice.
14.2. Generazione della firma
CSM_233 L'algoritmo di firma usato per creare le firme digitali sui dati
trasferiti deve essere ECDSA, come specificato in [DSS],
usando l'algoritmo di hash collegato alle dimensioni della
chiave della VU o della carta, come specificato in CSM_50.
Il formato della firma deve essere in chiaro, come specificato
in [TR-03111].
14.3. Verifica della firma
CSM_234 ►M1 Un IDE può verificare la firma sui dati trasferiti op­
pure può usare una carta di controllo per questo scopo. Nel
caso usi una carta di controllo, la verifica della firma può
avvenire come illustrato in figura 13. Per verificare la validità
temporale del certificato presentato dall’IDE, la carta di con­
trollo deve usare l’ora corrente memorizzata internamente,
come specificato in CSM_167. La carta di controllo deve
aggiornare la propria ora corrente se la data di efficacia di
un certificato «sorgente di tempo valida» è più recente
dell’ora corrente della carta. La carta deve accettare come
sorgente di tempo valida solo i certificati seguenti:
— certificati di collegamento ERCA di seconda generazione;
— certificati MSCA di seconda generazione;
— certificati VU_Sign o Card_Sign di seconda generazione
rilasciati dallo stesso paese del certificato della carta di
controllo.
Nel caso verifichi esso stesso la firma, l’IDE deve verificare
l’autenticità e la validità di tutti i certificati della catena di
certificati nel file di dati e la firma sui dati che seguono lo
schema di firma definito in [DSS]. In entrambi i casi, per
ciascun certificato letto dal file di dati è necessario verificare
che l’informazione contenuta nel campo «autorizzazione del
titolare del certificato» (CHA) sia corretta:
— Il campo CHA del certificato EQT deve indicare un cer­
tificato VU o Card (a seconda dei casi) usato per la firma
(cfr. appendice 1, tipo di dati EquipmentType).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 500
— Il campo CHA del certificato EQT.CA deve indicare una
MSCA.
— Il campo CHA del certificato EQT.Link deve indicare la
ERCA. ◄
Note alla Figura 13:
— l'apparecchio che ha firmato i dati da analizzare è indicato
con EQT.
— I certificati e le chiavi pubbliche EQT citati nella figura
sono quelli usati per la firma, cioè VU_Sign o Card_Sign.
— I certificati e le chiavi pubbliche EQT.CA citati nella
figura sono quelli usati per firmare i certificati della VU
o della carta, a seconda del caso.
— Il certificato EQT.CA.EUR citato nella figura è il certifi­
cato radice europeo indicato nel CAR del certificato
EQT.CA.
— Il certificato EQT.Link indicato nella figura è il certificato
di collegamento dell'EQT, se presente. Come specificato
nella sezione 9.1.2, si tratta di un certificato di collega­
mento per una nuova coppia di chiavi radice europee
creata dalla ERCA e firmate con la precedente chiave
privata europea.
— Il certificato EQT.Link.EUR è il certificato radice europeo
indicato nel CAR del certificato ETQ.Link.
CSM_235 Per calcolare l'hash M inviato alla carta di controllo nel co­
mando PSO:Hash, l'IDE deve usare l'algoritmo di hash colle­
gato alle dimensioni della chiave della VU o della carta da cui
sono trasferiti i dati, come specificato in CSM_50.
CSM_236 Per verificare la firma dell'EQT, la carta di controllo deve
seguire lo schema di firma definito in [DSS].
Nota: il presente documento non specifica alcuna azione da
intraprendere se la firma su un file di dati trasferito non può
essere verificata o se la verifica non va a buon fine.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 501
Figura 13
Protocollo di verifica della firma su un file di dati trasferiti
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 502
Appendice 12
POSIZIONAMENTO BASATO SUL SISTEMA GLOBALE DI
NAVIGAZIONE SATELLITARE (GNSS)
INDICE
1. INTRODUZIONE
1.1. Campo di applicazione
▼M3
1.1.1 Riferimenti
▼B
1.2. Acronimi e simboli
▼M3
2. CARATTERISTICHE DI BASE DEL RICEVITORE GNSS
3. FRASI FORNITE DAL RICEVITORE GNSS
▼B
4. UNITÀ ELETTRONICA DI BORDO CON DISPOSITIVO GNSS
ESTERNO
4.1. Configurazione
4.1.1 Componenti principali e interfacce
4.1.2 Stato del dispositivo GNSS esterno alla fine della produzione
4.2. Comunicazione tra il dispositivo GNSS esterno e l'unità elettronica di
bordo
4.2.1 Protocollo di comunicazione
4.2.2 Trasferimento sicuro di dati GNSS
4.2.3 Struttura del comando Read Record
▼M3
4.2.4 Struttura del comando WriteRecord
4.2.5 Altri comandi
▼B
4.3. Accoppiamento, autenticazione reciproca e accordo sulla chiave di ses­
sione del dispositivo GNSS esterno con l'unità elettronica di bordo
4.4. Gestione degli errori
4.4.1 Errore di comunicazione con il dispositivo GNSS esterno
4.4.2 Violazione dell'integrità fisica del dispositivo GNSS esterno
4.4.3 Assenza di informazioni sulla posizione provenienti dal ricevitore GNSS
4.4.4 Certificato del dispositivo GNSS esterno scaduto
5. UNITÀ ELETTRONICA DI BORDO SENZA DISPOSITIVO GNSS
ESTERNO
5.1. Configurazione
▼M3
5.2. Trasferimento di informazioni dal ricevitore GNSS alla VU
__________
5.3. Trasferimento di informazioni dalla VU al ricevitore GNSS
5.4. Gestione degli errori
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 503
5.4.1. Assenza di informazioni sulla posizione provenienti dal ricevitore GNSS
6. ELABORAZIONE E REGISTRAZIONE DEI DATI SULLA POSI­
ZIONE DA PARTE DELLA VU
7. CONFLITTO DI ORARI DEL GNSS
8. DATI CONTRASTANTI SUL MOVIMENTO DEL VEICOLO
1. INTRODUZIONE
La presente appendice stabilisce i requisiti tecnici per il ricevitore GNSS
e i dati GNSS usati dalle unità elettroniche di bordo, compresi i proto­
colli che devono essere implementati per garantire il trasferimento sicuro
e corretto dei dati relativi alle informazioni sul posizionamento.
1.1. Campo di applicazione
GNS_1 L’unità elettronica di bordo deve raccogliere i dati di localizza­
zione da almeno una rete satellitare GNSS.
L’unità elettronica di bordo può comprendere o non compren­
dere un dispositivo GNSS esterno come illustrato nella figura 1:
1.1.1 Riferimenti
In questa parte della presente appendice si rimanda ai seguenti
riferimenti.
NMEA Norma NMEA (National Marine Electronics Association) 0183
relativa all’interfaccia, V4.11
▼B
Figura 1
Configurazioni diverse per il ricevitore GNSS.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 504
1.2. Acronimi e simboli
Nella presente appendice sono utilizzati i seguenti acronimi:
DOP Diluizione della precisione
EGF File elementare dispositivo GNSS
EGNOS Servizio europeo di copertura per la navigazione geostaziona­
ria
GNSS Sistema globale di navigazione satellitare
GSA GPS DOP e satelliti attivi
HDOP Diluizione della precisione in orizzontale
ICD Documento di controllo dell'interfaccia
NMEA National Marine Electronics Association
▼M3
OSNMA Galileo Open Service Navigation Message Authentication
(servizio aperto di autenticazione dei messaggi di navigazione
di Galileo)
▼B
PDOP Diluizione della precisione della posizione
RMC Recommended Minimum Specific (minimo specifico racco­
mandato)
▼M3
RTC Real Time Clock (orologio in tempo reale)
▼B
SIS Segnale nello spazio
VDOP Diluizione della precisione in verticale
VU Unità elettronica di bordo
▼M3
2. CARATTERISTICHE DI BASE DEL RICEVITORE GNSS
▼B
Indipendentemente dalla configurazione del tachigrafo intelligente con o
senza un dispositivo GNSS esterno, la trasmissione di informazioni pre­
cise e affidabili sul posizionamento è un elemento essenziale dell'effica­
cia di funzionamento del tachigrafo intelligente. È quindi opportuno pre­
scriverne la compatibilità con i servizi forniti dai programmi Galileo e
EGNOS (servizio europeo di copertura per la navigazione geostaziona­
ria), come da regolamento (UE) n. 1285/2013 del Parlamento europeo e
del Consiglio ( 1 ). Il sistema realizzato nel quadro del programma Galileo
è un sistema globale indipendente di navigazione satellitare, mentre
quello realizzato nel quadro del programma EGNOS è un sistema regio­
nale di navigazione satellitare volto a migliorare la qualità del segnale del
sistema di posizionamento globale (Global Positioning System — GPS).
GNS_2 I fabbricanti devono garantire che i ricevitori GNSS dei tachi­
grafi intelligenti siano compatibili con i servizi di posiziona­
mento forniti dai sistemi Galileo e EGNOS. I fabbricanti pos­
sono inoltre optare per la compatibilità anche con ulteriori
sistemi di navigazione satellitare.
▼B
( 1 ) Regolamento (UE) n. 1285/2013 del Parlamento europeo e del Consiglio, dell'11 dicem­
bre 2013, relativo all'attuazione e all'esercizio dei sistemi europei di radionavigazione via
satellite e che abroga il regolamento (CE) n. 876/2002 del Consiglio e il
regolamento (CE) n. 683/2008 del Parlamento europeo e del Consiglio (GU L 347 del
20.12.2013, pag. 1).
02016R0799 — IT — 21.08.2023 — 003.002 — 505
GNS_3 Il ricevitore GNSS deve avere la capacità di supportare l’au­
tenticazione dei messaggi di navigazione sul servizio aperto di
Galileo (OSNMA).
GNS_3a Il ricevitore GNSS deve eseguire una serie di controlli di coe­
renza al fine di verificare che le misurazioni calcolate dal rice­
vitore GNSS sulla base dei dati OSNMA abbiano generato
informazioni corrette in merito alla posizione, alla velocità e
ai dati del veicolo e non siano state pertanto influenzate da
attacchi esterni come il meaconing. Di seguito alcuni esempi
di tali controlli di coerenza:
— rilevamento di emissioni di potenza anomale mediante il
monitoraggio combinato del controllo automatico del
guadagno (AGC) e del rapporto portante su densità di ru­
more (C/N0);
— coerenza nel tempo della misurazione della pseudodistanza
e della misurazione dell’effetto Doppler, compresa la rile­
vazione di salti improvvisi nella misurazione;
— tecniche di monitoraggio autonomo dell’integrità del
ricevitore (RAIM), compreso il rilevamento di misurazioni
non coerenti con la posizione stimata;
— controlli della posizione e della velocità, comprese solu­
zioni di posizione e velocità anormali, salti improvvisi e
comportamenti non coerenti con le dinamiche del veicolo;
— coerenza in termini di tempo e frequenza, compresi salti e
sfasamenti dell’orologio che risultino incoerenti con le ca­
ratteristiche dell’orologio del ricevitore.
GNS_3b La Commissione europea deve elaborare e approvare i docu­
menti seguenti:
— un documento di controllo dell’interfaccia per i segnali
nello spazio (SIS ICD), che specifichi in maniera dettagliata
le informazioni OSNMA trasmesse nel segnale Galileo;
— gli orientamenti per i ricevitori OSNMA, che stabiliscano i
requisiti e i processi relativi ai ricevitori per garantire
un’implementazione sicura dell’OSNMA, oltre alle racco­
mandazioni volte a migliorare le prestazioni dell’OSNMA.
I ricevitori GNSS montati nei tachigrafi, interni o esterni, de­
vono essere costruiti conformemente al SIS ICD e agli orien­
tamenti per i ricevitori OSNMA.
GNS_3c Il ricevitore GNSS deve fornire messaggi di posizione, deno­
minati messaggi di posizione autenticata nel presente allegato e
nelle sue appendici, elaborati utilizzando esclusivamente satel­
liti per i quali la verifica dell’autenticità dei messaggi di navi­
gazione ha dato esito positivo.
GNS_3d Il ricevitore GNSS deve altresì fornire messaggi di posizione
standard, elaborati utilizzando i satelliti visibili, a prescindere
dal fatto che siano autenticati o no.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 506
GNS_3e Il ricevitore GNSS deve utilizzare l’orologio in tempo
reale (RTC) della VU come riferimento temporale per la sin­
cronizzazione temporale necessaria per l’OSNMA.
GNS_3f L’ora RTC della VU deve essere fornita al ricevitore GNSS
dalla VU.
GNS_3g Lo sfasamento massimo dell’ora indicato al requisito 41
dell’allegato IC deve essere fornito al ricevitore GNSS dalla
VU assieme all’ora RTC della VU.
3. FRASI FORNITE DAL RICEVITORE GNSS
Nella presente sezione sono descritte le frasi utilizzate nel funzionamento
del tachigrafo intelligente per trasmettere messaggi di posizione standard
e autenticata. La presente sezione è valida per la configurazione del
tachigrafo intelligente con o senza dispositivo GNSS esterno.
GNS_4 I dati sulla posizione standard si basano sulla frase NMEA
Recommended Minimum Specific (RMC) GNSS Data, che
contiene le informazioni sulla posizione (latitudine, longitu­
dine), l’ora in formato UTC (oommss.ss) e la velocità al suolo
in nodi, più altri valori.
Il formato della frase RMC è il seguente (come da norma
NMEA V4.11):
Figura 2
Struttura della frase RMC
$–RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x .x,xxxx,x.x,a,a,a*hh
1) Ora (UTC)
2) Stato, A= Posizione valida, V= Avviso
3) Latitudine
4) N o S
5) Longitudine
6) E o W
7) Velocità al suolo in nodi
8) Direzione seguita, in gradi
9) Data, ggmmaa
10) Variazione magnetica, in gradi
11) E o W
12) Indicatore di modo FAA
13) Stato di navigazione
14) Totale di controllo
Lo stato di navigazione è facoltativo e può non essere presente
nella frase RMC.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 507
Lo stato indica se il segnale GNSS è disponibile. Fino a che il
valore dello stato non è impostato su «A», i dati ricevuti (ad
esempio sull’ora o sulla latitudine/longitudine) non possono
essere usati per registrare la posizione del veicolo nella VU.
La risoluzione della posizione è basata sul formato della frase
RMC di cui sopra. La prima parte dei campi 3) e 5) è usata
per rappresentare i gradi. La parte restante è usata per rappre­
sentare i minuti con tre decimali. La risoluzione è quindi
1/1 000 di minuto o 1/60 000 di grado (poiché un minuto è
1/60 di un grado).
GNS_4a I dati sulla posizione autenticata si basano su una frase Au­
thenticated Minimum Specific (AMC) Data, simile a una frase
NMEA, che contiene le informazioni sulla posizione (latitu­
dine, longitudine), l’ora in formato UTC (oommss.ss) e la
velocità al suolo in nodi, più altri valori.
Il formato della frase AMC è il seguente (come da norma
NMEA V4.11, fatta eccezione per il valore numero 2):
Figura 3
Struttura della frase AMC
$–AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
1) Ora (UTC)
2) Stato, A=posizione autenticata (stabilita utilizzando almeno 4 satelliti per i
quali la verifica dell’autenticità dei messaggi di navigazione ha dato esito
positivo), J=Jamming o O=altro attacco al GNSS in assenza di un’autenti­
cazione dei messaggi di navigazione fallita (mediante controlli di coerenza
attuati in conformità al GNS_3a), F=autenticazione dei messaggi di naviga­
zione fallita (come rilevato dalle verifiche OSNMA specificate nei docu­
menti di cui al GNS_3b), V=Void (nullo; la posizione autenticata non è
disponibile per altri motivi)
3) Latitudine
4) N o S
5) Longitudine
6) E o W
7) Velocità al suolo in nodi
8) Direzione seguita, in gradi
9) Data, ggmmaa
10) Variazione magnetica, in gradi
11) E o W
12) Indicatore di modo FAA
13) Stato di navigazione
14) Totale di controllo
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 508
Lo stato di navigazione è facoltativo e può non essere presente
nella frase AMC.
Lo stato indica se è disponibile una posizione GNSS autenti­
cata, se è stato rilevato un attacco ai segnali GNSS, se l’au­
tenticazione dei messaggi di navigazione è fallita o se la po­
sizione GNSS è nulla. Quando il valore dello stato non è
impostato su «A», i dati ricevuti (ad esempio sull’ora o sulla
latitudine/longitudine) non sono ritenuti validi e non possono
essere usati per registrare la posizione del veicolo nella VU.
Quando il valore dello stato è impostato su «J» (jamming),
«O» (altro attacco al GNSS) o «F» (autenticazione dei mes­
saggi di navigazione fallita), nella VU deve essere registrata
un’anomalia GNSS, come definita nell’allegato IC e nell’ap­
pendice 1 (EventFaultCode).
GNS_5 L’unità elettronica di bordo deve conservare nella propria
banca dati le informazioni sulla posizione per latitudine e
longitudine con una risoluzione di 1/10 di min o 1/600 di
grado, come descritto nell’appendice 1 per il tipo GeoCoordi­
nates.
Il comando GPS DOP e satelliti attivi (GSA), in conformità
alla norma NMEA V4.11, può essere usato dalla VU per
determinare e registrare la disponibilità e l’accuratezza del
segnale per le posizioni standard. In particolare HDOP è usato
per fornire un’indicazione circa il livello di precisione dei dati
di localizzazione registrati (cfr. 4.2.2). La VU memorizzerà il
valore di diluizione della precisione in orizzontale (Horizontal
Dilution of Precision – HDOP), calcolato come il valore
HDOP minimo tra quelli raccolti dai sistemi GNSS
disponibili.
L’identificativo GNSS indica l’identificativo NMEA corri­
spondente per ogni costellazione GNSS e sistema di potenzia­
mento basato su satelliti (Satellite-Based Augmentation Sy­
stem – SBAS).
Figura 4
Struttura della frase GSA (posizioni standard)
$–GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h
1) Modalità di selezione
2) Modo
3) ID del 1° satellite usato per il fix (rilevamento della posizione)
4) ID del 2° satellite usato per il fix (rilevamento della posizione)
…
14) ID del 12° satellite usato per il fix (rilevamento della posizione)
15) PDOP
16) HDOP
17) VDOP
18) Identificativo del sistema
19) Totale di controllo
L’identificativo del sistema è facoltativo e può non essere
presente nella frase GSA.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 509
Analogamente il comando satelliti attivi autenticati (ASA),
simile a una frase NMEA, può essere usato dalla VU per
determinare e registrare la disponibilità e la precisione del
segnale per le posizioni autenticate. I valori da 1 a 18 sono
definiti nella norma NMEA V4.11.
Figura 5
Struttura della frase ASA (posizioni autenticate)
$–ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h
1) Modalità di selezione
2) Modo
3) ID del 1° satellite usato per il fix (rilevamento della posizione)
4) ID del 2° satellite usato per il fix (rilevamento della posizione)
…
14) ID del 12° satellite usato per il fix (rilevamento della posizione)
15) PDOP
16) HDOP
17) VDOP
18) Identificativo del sistema
19) Totale di controllo
L’identificativo del sistema è facoltativo e può non essere
presente nella frase ASA.
GNS_6 Quando è usato un dispositivo GNSS esterno, la frase GSA
deve essere memorizzata nel ricetrasmettitore sicuro GNSS
con i numeri di registrazione da «02» to «06» e la frase
ASA deve essere memorizzata con i numeri di registrazione
da «12» a «16».
GNS_7 La dimensione massima delle frasi (ad esempio RMC, AMC,
GSA, ASA o altre) che può essere usata per la definizione
delle dimensioni del comando «Read Record» (leggi registra­
zione) deve essere di 85 byte (cfr. tabella 1).
▼B
4. UNITÀ ELETTRONICA DI BORDO CON DISPOSITIVO GNSS
ESTERNO
4.1. Configurazione
4.1.1 Componenti principali e interfacce
In tale configurazione, il ricevitore GNSS è parte del dispositivo
GNSS esterno.
GNS_8 Il dispositivo GNSS esterno deve essere alimentato con una
specifica interfaccia del veicolo.
▼M3
GNS_9 Il dispositivo GNSS esterno deve essere costituito dai se­
guenti elementi (cfr. figura 6):
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 510
a) un ricevitore GNSS commerciale per fornire i dati sulla
posizione attraverso l’interfaccia dati GNSS. Ad esem­
pio l’interfaccia dati GNSS può essere conforme alla
norma NMEA V4.11, con il ricevitore GNSS che funge
da sorgente e trasmette frasi NMEA al ricetrasmettitore
sicuro GNSS con una frequenza di 1 Hz per l’insieme
prestabilito di frasi NMEA e simili, che deve compren­
dere almeno le frasi RMC, AMC, GSA e ASA. L’im­
plementazione dell’interfaccia dati GNSS è una scelta
dei fabbricanti dei dispositivi GNSS esterni.
▼B
b) una unità ricetrasmittente (ricetrasmettitore sicuro
GNSS) compatibile con la norma ISO/IEC 7816-4:2013
(cfr. 4.2.1) per comunicare con l'unità elettronica di
bordo e essere compatibile con l'interfaccia dati GNSS
per il ricevitore GNSS. Tale unità è dotata di memoria
per conservare i dati di identificazione del ricevitore
GNSS e del dispositivo GNSS esterno;
▼M3
c) un contenitore, con funzione di rilevamento delle mano­
missioni, che incorpori sia il ricevitore GNSS sia il rice­
trasmettitore sicuro GNSS. La funzione di rilevamento
delle manomissioni deve attuare le misure di protezione
della sicurezza come richiesto nel profilo di protezione
del tachigrafo intelligente.
▼B
d) un'antenna GNSS installata sul veicolo e collegata al
ricevitore GNSS tramite il contenitore.
GNS_10 Il dispositivo GNSS esterno è dotato almeno delle seguenti
interfacce esterne:
a) l'interfaccia per l'antenna GNSS installata sull'autocarro,
se si utilizza un'antenna esterna;
b) l'interfaccia per l'unità elettronica di bordo.
GNS_11 Il ricetrasmettitore sicuro della VU è all'altro capo della
comunicazione sicura con il ricetrasmettitore sicuro GNSS
e deve essere compatibile con la norma ISO/IEC 7816-
4:2013 per il collegamento al dispositivo GNSS esterno.
GNS_12 Per il livello fisico della comunicazione con il dispositivo
GNSS esterno, l'unità elettronica di bordo deve essere com­
patibile con la norma ISO/IEC 7816-12:2005 o un'altra
norma compatibile con ISO/IEC 7816-4:2013 (cfr. 4.2.1).
4.1.2 Stato del dispositivo GNSS esterno alla fine della produzione
GNS_13 All'uscita dalla fabbrica il dispositivo GNSS esterno deve
conservare nella memoria non volatile del ricetrasmettitore
sicuro GNSS i seguenti valori:
— la coppia di chiavi EGF_MA e il certificato
corrispondente,
— il certificato MSCA_VU-EGF contenente la chiave pub­
blica MSCA_VU-EGF.PK da usare per la verifica del
certificato EGF_MA,
— il certificato EUR contenente la
chiave pubblica EUR.PK da usare per la verifica del
certificato MSCA_VU-EGF,
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 511
— il certificato EUR il cui periodo di validità precede
direttamente il periodo di validità del certificato EUR
da usare per la verifica del certificato MSCA_VU-EGF,
se presente,
— il certificato di collegamento che collega questi
due certificati EUR, se presente,
— il numero di serie completo del dispositivo GNSS
esterno,
— l'identificativo del sistema operativo del dispositivo
GNSS,
— il numero di omologazione del dispositivo GNSS
esterno,
— l'identificativo del componente di sicurezza del disposi­
tivo GNSS esterno.
4.2. Comunicazione tra il dispositivo GNSS esterno e l'unità elettronica
di bordo
4.2.1 Protocollo di comunicazione
▼M3
GNS_14 Il protocollo di comunicazione tra il dispositivo GNSS
esterno e l’unità elettronica di bordo deve essere compati­
bile con le funzioni seguenti:
1. la raccolta e la distribuzione di dati GNSS (ad esempio
posizione, ora, velocità);
2. la raccolta dei dati di configurazione del dispositivo
GNSS esterno;
3. il protocollo di gestione a supporto di accoppiamento,
autenticazione reciproca e accordo sulla chiave di ses­
sione tra il dispositivo GNSS esterno e la VU;
4. la trasmissione al dispositivo GNSS esterno dell’ora
RTC della VU e della differenza massima tra l’ora ef­
fettiva e l’ora RTC della VU.
▼B
GNS_15 Il protocollo di comunicazione deve essere basato sulla
norma ISO/IEC 7816-4:2013 con il ricetrasmettitore sicuro
della VU che svolge il ruolo di master e il ricetrasmettitore
sicuro del GNSS che svolge il ruolo di slave. Il collega­
mento fisico tra il dispositivo GNSS esterno e l'unità elet­
tronica di bordo si basa sulla norma ISO/IEC 7816-12:2005
o su un'altra norma compatibile con ISO/IEC 7816-4:2013.
▼M1
GNS_16 I campi lunghi non devono essere supportati nel protocollo
di comunicazione.
▼B
GNS_17 Il protocollo di comunicazione di ISO 7816 (sia *-4:2013
che *-12:2005) tra il dispositivo GNSS esterno e la VU
deve essere impostato su T=1.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 512
GNS_18 Per quanto riguarda le funzioni di 1) raccolta e distribuzione
dei dati GNSS, 2) raccolta dei dati di configurazione del
dispositivo GNSS esterno e 3) protocollo di gestione, il
ricetrasmettitore sicuro GNSS deve simulare una smart
card, l’architettura del cui file system è composta da un
file master (MF) e da un file dedicato (DF), con l’identifi­
cativo dell’applicazione specificato nell’appendice 1, capi­
tolo 6.2 («FF 44 54 45 47 4D») e con tre EF contenenti i
certificati e un solo file elementare (EF.EGF) con l’identi­
ficativo uguale a «2F2F» come illustrato nella tabella 1.
▼M3
GNS_18a Per quanto riguarda la funzione 4) relativa alla trasmissione
al dispositivo GNSS esterno dell’ora RTC della VU e della
differenza massima tra l’ora effettiva e l’ora RTC della VU,
il ricetrasmettitore sicuro GNSS deve utilizzare un EF (EF
VU) nello stesso DF con un identificativo di file uguale a
«2F30» come descritto nella tabella 1.
▼B
GNS_19 Il ricetrasmettitore sicuro GNSS deve memorizzare i dati
provenienti dal ricevitore GNSS e la configurazione nel
file EF.EFG. Quest'ultimo è un file di registrazione lineare
a lunghezza variabile con un identificativo uguale a «2F2F»
in formato esadecimale.
▼M3
GNS_19a Il ricetrasmettitore sicuro GNSS deve memorizzare i dati
provenienti dalla VU nell’EF VU. Quest’ultimo è un file
di registrazione lineare a lunghezza fissa con un identifica­
tivo uguale a «2F30» in formato esadecimale.
GNS_20 Il ricetrasmettitore sicuro GNSS deve utilizzare una memo­
ria per memorizzare i dati e deve essere in grado di eseguire
tutti i cicli di lettura/scrittura necessari per un periodo di
almeno 15 anni. A eccezione di questo aspetto, la proget­
tazione interna e l’implementazione del ricetrasmettitore si­
curo GNSS è a discrezione dei fabbricanti.
▼M1
La mappatura dei numeri di registrazione e dei dati è illu­
strata nella tabella 1. Da notare che vi sono cinque frasi
GSA per le costellazioni GNSS e il sistema satellitare di
potenziamento basato su satelliti (SBAS).
▼B
GNS_21 La struttura dei file è illustrata nella Table 1. Per le condi­
zioni di accesso (ALW, NEV, SM-MAC) cfr. appendice 2,
capitolo 3.5.
▼M3
Tabella 1
Struttura dei file
Condizioni di accesso
File ID del file Lettura Aggiornamento Criptato
MF 3F00
EF.ICC 0002 ALW NEV
(dalla VU)
N.
▼M1
02016R0799 — IT — 21.08.2023 — 003.002 — 513
Condizioni di accesso
File ID del file Lettura Aggiornamento Criptato
DF GNSS Facility 0501 ALW NEV N.
EF EGF_MACertificate C100 ALW NEV N.
EF CA_Certificate C108 ALW NEV N.
EF Link_Certificate C109 ALW NEV N.
EF EGF 2F2F SM-MAC NEV
(dalla VU)
N.
EF VU 2F30 SM-MAC SM-MAC N.
File / Elemento di dati Registrazione n. Dimensioni (in byte)
Valori stan­
dard
Min Max
MF 552 1031
EF.ICC
sensorGNSSSerialNumber 8 8
DF GNSS Facility 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
Frase NMEA RMC «01» 85 85
1 a frase NMEA GSA «02» 85 85
2 a frase NMEA GSA «03» 85 85
3 a frase NMEA GSA «04» 85 85
4 a frase NMEA GSA «05» 85 85
5 a frase NMEA GSA «06» 85 85
Numero di serie completo del dispo­
sitivo GNSS esterno definito Sensor­
GNSSSerialNumber nell’appendice 1.
«07» 8 8
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 514
File / Elemento di dati Registrazione n. Dimensioni (in byte)
Valori stan­
dard
Identificativo del sistema operativo
del ricetrasmettitore sicuro GNSS de­
finito SensorOSIdentifier nell’appen­
dice 1.
«08» 2 2
Numero di omologazione del disposi­
tivo GNSS esterno definito SensorEx­
ternalGNSSApprovalNumber nell’ap­
pendice 1.
«09» 16 16
Identificativo del componente di sicu­
rezza del dispositivo GNSS esterno
definito SensorExternalGNSSSCIden­
tifier nell’appendice 1.
«10» 8 8
Frase AMC «11» 85 85
1 a frase ASA «12» 85 85
2 a frase ASA «13» 85 85
3 a frase ASA «14» 85 85
4 a frase ASA «15» 85 85
5 a frase ASA «16» 85 85
RFU — Riservato per uso futuro Da «17» a
«FD»
EF VU
VuRtcTime (cfr. appendice 1) «01» 4 4 {00..00}
VuGnssMaximalTimeDifference (cfr.
appendice 1)
«02» 2 2 {00..00}
▼B
4.2.2 Trasferimento sicuro di dati GNSS
▼M3
GNS_22 Il trasferimento sicuro di dati sulla posizione GNSS, ora
RTC della VU e differenza massima tra l’ora effettiva e
l’ora RTC della VU deve essere consentito solo alle se­
guenti condizioni:
▼B
1. il processo di accoppiamento è stato completato come
descritto nell'appendice 11. Meccanismi comuni di
sicurezza;
2. l'accordo sulla chiave di sessione e l'autenticazione reci­
proca tra la VU e il dispositivo GNSS esterno, anch'essi
descritti nell'appendice 11. Meccanismi comuni di sicu­
rezza, sono stati eseguiti periodicamente con la fre­
quenza indicata.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 515
GNS_23 Ogni T secondi, dove T è un valore inferiore o uguale a 20,
a meno che non si verifichi l’accoppiamento o l’autentica­
zione reciproca e l’accordo sulla chiave di sessione, la VU
richiede al dispositivo GNSS esterno le informazioni sulla
posizione in base alle seguenti fasi:
1. la VU richiede i dati sulla posizione al dispositivo GNSS
esterno insieme ai dati sulla diluizione della precisione
(dalle frasi ASA e GSA); il ricetrasmettitore sicuro della
VU deve usare i comandi SELECT e READ RE­
CORD(S) (seleziona e leggi registrazione/i), conformi
alla norma ISO/IEC 7816-4:2013, in modalità di sola
autenticazione e con messaggistica sicura, come descritto
nell’appendice 11, punto 11.5, con l’identificativo di file
«2F2F» e numero di registrazione uguale a «01» per la
frase NMEA RMC, «02»,«03»,«04»,«05»,«06» per la
frase NMEA GSA, «11» per la frase AMC e
«12»,«13»,«14»,«15»,«16» per la frase ASA;
2. gli ultimi dati sulla posizione ricevuti sono memorizzati
nell’EF con identificativo «2F2F» e nei registri descritti
nella tabella 1 del ricetrasmettitore sicuro GNSS man
mano che quest’ultimo riceve i dati NMEA con una
frequenza di almeno 1 Hz dal ricevitore GNSS attra­
verso l’interfaccia dati GNSS;
3. il ricetrasmettitore sicuro GNSS invia la risposta al rice­
trasmettitore sicuro della VU usando il messaggio di
risposta APDU in modalità di sola autenticazione e
con messaggistica sicura come descritto nell’appendice
11.5, punto 11;
4. il ricetrasmettitore sicuro della VU verifica l’autenticità e
l’integrità della risposta ricevuta; se la verifica ha esito
positivo, i dati sulla posizione sono trasferiti al proces­
sore della VU attraverso l’interfaccia dati GNSS;
5. il processore della VU verifica i dati ricevuti ed estrae le
informazioni (ad esempio latitudine, longitudine, ora)
dalla frase NMEA RMC; la frase NMEA RMC com­
prende le informazioni sulla validità della posizione
non autenticata; se la posizione non autenticata è valida,
il processore della VU estrae anche i valori di HDOP
dalle frasi NMEA GSA e calcola il valore minimo sui
sistemi satellitari disponibili (vale a dire quando il fix è
disponibile);
6. il processore della VU estrae inoltre le informazioni (ad
esempio latitudine, longitudine, ora) dalla frase AMC; la
frase AMC comprende le informazioni sulla non validità
della posizione autenticata o su eventuali attacchi al se­
gnale GNSS; se la posizione è valida, il processore della
VU estrae anche i valori di HDOP dalle frasi ASA e
calcola il valore minimo sui sistemi satellitari disponibili
(vale a dire quando il fix è disponibile).
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 516
GNS_23a La VU deve anche scrivere l’ora RTC della VU e la diffe­
renza massima tra l’ora effettiva e l’ora RTC della VU, se­
condo necessità, utilizzando i comandi SELECT e WRITE
RECORD(S) (seleziona e scrivi registrazione/i), conformi
alla norma ISO/IEC 7816-4: 2013, in modalità di sola au­
tenticazione e con messaggistica sicura, come descritto
nell’appendice 11, punto 11.5, con identificativo di file
«2F30» e numero RECORD uguale a «01» per VuRtcTime
e «02» MaximalTimeDifference
▼B
4.2.3 Struttura del comando Read Record
La presente sezione descrive in dettaglio la struttura del comando Read
Record (leggi registrazione). La messaggistica sicura (in modalità di
sola autenticazione) è aggiunta come descritto nell'appendice 11. Mec­
canismi comuni di sicurezza.
GNS_24 Il comando deve essere compatibile con la messaggistica
sicura in modalità di sola autenticazione, cfr. appendice 11.
GNS_25 Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «0Ch» Richiesta messaggistica sicura
INS 1 «B2h» Leggi registrazione
P1 1 «XXh» Numero di registrazione («00» si riferisce
alla registrazione corrente)
P2 1 «04h» Leggi la registrazione con il numero di
registrazione indicato in P1
Le 1 «XXh» Lunghezza dei dati attesa. Numero di
byte da leggere
GNS_26 La registrazione cui si riferisce P1 diventa la registrazione
corrente.
Byte
Lun­
ghezza
Valore Descrizione
#1-#X X «XX..XXh» Dati letti
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, il ricetrasmettitore si­
curo GNSS risponde «9000».
— Se il file corrente non è orientato alla registrazione (re­
cord oriented), il ricetrasmettitore sicuro GNSS risponde
«6981».
— Se il comando è usato con P1 = «00», ma non vi è
alcun EF corrente, il ricetrasmettitore sicuro GNSS ri­
sponde «6986» (comando non consentito).
▼M3
— Se la registrazione non è stata trovata, il ricetrasmetti­
tore sicuro GNSS risponde «6A83».
— Se ha rilevato una manomissione, il dispositivo GNSS
esterno deve inviare in risposta le parole di stato
«6690».
__________
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 517
4.2.4 Struttura del comando WriteRecord
La presente sezione descrive in dettaglio la struttura del comando
Write Record (scrivi registrazione). La messaggistica sicura (in moda­
lità di sola autenticazione) è aggiunta come descritto nell’appendice 11
– Meccanismi comuni di sicurezza.
GNS_26a Il comando deve essere compatibile con la messaggistica
sicura in modalità di sola autenticazione, cfr. appendice 11.
GNS_26b Messaggio di comando
Byte
Lun­
ghezza
Valore Descrizione
CLA 1 «0Ch» Richiesta messaggistica sicura
INS 1 «D2h» Scrivi registrazione
P1 1 «XXh» Numero di registrazione («00» si riferi­
sce alla registrazione corrente)
P2 1 «04h» Scrivi la registrazione con il numero di
registrazione indicato in P1
Dati X «XXh» Dati
GNS_26c La registrazione cui si riferisce P1 diventa la registrazione
corrente.
Byte
Lun­
ghezza
Valore Descrizione
SW 2 «XXXXh» Parole di stato (SW1, SW2)
— Se il comando ha esito positivo, il ricetrasmettitore
sicuro GNSS risponde «9000».
— Se il file corrente non è orientato alla registrazione (record
oriented), il ricetrasmettitore sicuro GNSS risponde «6981».
— Se il comando è usato con P1 = «00», ma non vi è
alcun EF corrente, il ricetrasmettitore sicuro GNSS ri­
sponde «6986» (comando non consentito).
— Se la registrazione non è stata trovata, il ricetrasmetti­
tore sicuro GNSS risponde «6A83».
— Se il dispositivo GNSS esterno ha rilevato una mano­
missione, devono essere inviate in risposta le parole di
stato «6690».
4.2.5 Altri comandi
GNS_27 Il ricetrasmettitore sicuro GNSS deve essere compatibile coi se­
guenti comandi del tachigrafo di seconda generazione specificati
nell’appendice 2:
Comando Riferimento
Select (Seleziona) Appendice 2, capitolo 3.5.1
Read Binary (Leggi formato binario) Appendice 2, capitolo 3.5.2
Get Challenge (Genera Challenge) Appendice 2, capitolo 3.5.4
PSO: Verify Certificate (PSO: verifica
certificato)
Appendice 2, capitolo 3.5.7
External Authenticate (Autentica­
zione esterna)
Appendice 2, capitolo 3.5.9
General Authenticate (Autenticazione
generale)
Appendice 2, capitolo 3.5.10
MSE:SET Appendice 2, capitolo 3.5.11
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 518
4.3. Accoppiamento, autenticazione reciproca e accordo sulla chiave di
sessione del dispositivo GNSS esterno con l'unità elettronica di
bordo
L'accoppiamento, l'autenticazione reciproca e l'accordo sulla chiave di
sessione del dispositivo GNSS esterno con l'unità elettronica di bordo
sono descritti nell'appendice 11. Meccanismi comuni di sicurezza,
capitolo 11.
4.4. Gestione degli errori
La presente sezione descrive in che modo sono gestite e registrate
nella VU le potenziali condizioni di errore del dispositivo GNSS
esterno.
4.4.1 Errore di comunicazione con il dispositivo GNSS esterno
▼M3
GNS_28 Un’anomalia di tipo «Errore di comunicazione con il dispo­
sitivo GNSS esterno», come definita al requisito 82
dell’allegato IC e nell’appendice 1 (EventFaultType), deve
essere registrata nella VU. In tale contesto, si attiva un
errore di comunicazione quando il ricetrasmettitore sicuro
VU non riceve un messaggio di risposta dopo un messaggio
di richiesta come descritto al punto 4.2.
▼B
4.4.2 Violazione dell'integrità fisica del dispositivo GNSS esterno
▼M3
GNS_29 Se il dispositivo GNSS esterno è stato violato, il ricetra­
smettitore sicuro GNSS deve assicurare che il materiale
crittografico non sia disponibile. Come descritto ai paragrafi
GNS_25 e GNS_26, la VU deve rilevare le manomissioni
se lo stato della risposta è «6690». La VU deve quindi
generare e registrare un’anomalia di tipo «Tentata viola­
zione della sicurezza», come definita al requisito 85
dell’allegato IC e all’appendice 1 (EventFaultType per rile­
vamento delle manomissioni del GNSS). In alternativa, il
dispositivo GNSS esterno può rispondere alle richieste della
VU senza messaggistica sicura e con lo stato «6A88».
▼B
4.4.3 Assenza di informazioni sulla posizione provenienti dal ricevitore
GNSS
▼M3
GNS_30 Se non riceve dati dal ricevitore GNSS, il ricetrasmettitore
sicuro GNSS deve generare un messaggio di risposta al
comando READ RECORD (leggi registrazione) con il nu­
mero di registrazione uguale a «01» e un campo di dati di
12 byte impostati tutti su 0xFF. Alla ricezione del messag­
gio di risposta con tale valore del campo di dati, la VU deve
generare e registrare un’anomalia di tipo «Assenza di infor­
mazioni sulla posizione provenienti dal ricevitore GNSS»,
come definita al requisito 81 dell’allegato IC e all’appendice
1 (EventFaultType).
▼B
4.4.4 Certificato del dispositivo GNSS esterno scaduto
▼M3
GNS_31 Se rileva che il certificato EGF usato per l’autenticazione
reciproca non è più valido, la VU deve generare e registrare
un’anomalia di tipo «Tentata violazione della sicurezza»,
come definita al requisito 85 dell’allegato IC e all’appendice
1 (EventFaultType per certificato del dispositivo GNSS
esterno scaduto). La VU deve comunque usare i dati sulla
posizione GNSS ricevuti.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 519
Figura 6
Schema del dispositivo GNSS esterno
▼B
5. UNITÀ ELETTRONICA DI BORDO SENZA DISPOSITIVO GNSS
ESTERNO
5.1. Configurazione
Nella presente configurazione, il ricevitore GNSS è all'interno dell'unità
elettronica di bordo, come descritto nella Figure 1.
▼M3
GNS_32 Ai fini della trasmissione di posizione, DOP e dati satelli­
tari, il ricevitore GNSS deve fungere da sorgente e trasmet­
tere le frasi NMEA o simili al processore della VU, che
deve fungere da ricevitore con una frequenza pari o supe­
riore a 1/10 Hz per l’insieme prestabilito di frasi, che deve
includere almeno le frasi RMC, GSA, AMC e ASA. In
alternativa, il processore della VU e il ricevitore GNSS
interno possono utilizzare altri formati di dati per scambiare
i dati contenuti nelle frasi NMEA o simili specificate ai
paragrafi GNS_4, GNS_4a e GNS_5.
▼B
GNS_33 Alla VU deve essere collegata un'antenna GNSS esterna
installata sul veicolo o un'antenna GNSS interna.
▼M3
5.2. Trasferimento di informazioni dal ricevitore GNSS alla VU
GNS_34 Il processore della VU verifica i dati ricevuti ed estrae le
informazioni (ad esempio latitudine, longitudine, ora) dalla
frase RMC NMEA e dalla frase AMC.
GNS_35 La frase NMEA RMC comprende le informazioni sulla
validità della posizione non autenticata. Se la posizione
non autenticata non è valida, i dati sulla posizione non
sono disponibili e non possono essere usati per registrare
la posizione del veicolo. Se la posizione non autenticata è
valida, il processore della VU estrae anche i valori di
HDOP dalla frase GSA NMEA.
GNS_36 Il processore della VU estrae inoltre le informazioni (ad
esempio latitudine, longitudine, ora) dalla frase AMC. La
frase AMC comprende le informazioni sulla validità della
posizione non autenticata in conformità al
paragrafo GNS_4a. Se la posizione non autenticata è va­
lida, il processore della VU estrae anche i valori di HDOP
dalle frasi ASA.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 520
5.3. Trasferimento di informazioni dalla VU al ricevitore GNSS
GNS_37 Il processore della VU fornisce al ricevitore GNSS l’ora
RTC della VU e la differenza massima tra l’ora effettiva e
l’ora RTC della VU, in conformità ai paragrafi GNS_3f e
GNS_3g.
5.4. Gestione degli errori
5.4.1 Assenza di informazioni sulla posizione provenienti dal ricevitore
GNSS
GNS_38 La VU deve generare e registrare un’anomalia di tipo
«Assenza di informazioni sulla posizione provenienti dal
ricevitore GNSS», come definita al requisito 81
dell’allegato IC e all’appendice 1 (EventFaultType).
6. ELABORAZIONE E REGISTRAZIONE DEI DATI SULLA POSI­
ZIONE DA PARTE DELLA VU
La presente sezione è valida per la configurazione del tachigrafo
intelligente con o senza dispositivo GNSS esterno.
GNS_39 I dati sulla posizione devono essere memorizzati nella VU,
insieme a un indicatore che segnali se la posizione è stata
autenticata. Quando è necessario registrare i dati sulla po­
sizione nella VU devono applicarsi le regole seguenti:
a) se la posizione autenticata e la posizione standard sono
entrambe valide e coerenti, la posizione standard e la
sua accuratezza devono essere registrate nella VU e
l’indicatore deve essere impostato su «autenticata»;
b) se la posizione autenticata e la posizione standard sono
entrambe valide ma non coerenti, la VU deve memo­
rizzare la posizione autenticata e la sua accuratezza e
l’indicatore deve essere impostato su «autenticata»;
c) se la posizione autenticata è valida e la posizione stan­
dard non lo è, la VU deve registrare la posizione au­
tenticata e la sua accuratezza e l’indicatore deve essere
impostato su «autenticata»;
d) se la posizione standard è valida e la posizione standard
non lo è, la VU deve registrare la posizione autenticata
e la sua accuratezza e l’indicatore deve essere impo­
stato su «non autenticata».
La posizione autenticata e la posizione standard sono rite­
nute coerenti, come illustrato nella figura 7, quando la
posizione autenticata orizzontale si trova in un cerchio
che ha al centro la posizione standard orizzontale e il cui
raggio si ottiene arrotondando al numero intero superiore
più vicino il valore di R_H calcolato secondo la formula
seguente:
R_H = 1.74 • σ UERE • HDOP
in cui:
— R_H è il raggio relativo di un cerchio costruito attorno
alla posizione orizzontale stimata, espresso in metri. Si
tratta di un indicatore utilizzato per verificare la coe­
renza tra la posizione standard e quella autenticata;
— UERE è la deviazione standard per lo User Equivalent
Range Error (UERE, errore equivalente di distanza
dell’utente), che modellizza tutti gli errori di misura­
zione per l’applicazione destinataria, compresi gli am­
bienti urbani. Deve essere utilizzato un valore costante
di σ UERE = 10 metri;
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 521
— HDOP è la diluizione della precisione in orizzontale
calcolata dal ricevitore GNSS;
— σ UERE . HDOP è la stima della radice quadrata della
deviazione media sul piano orizzontale.
Figura 7
Posizione autenticata e posizione standard (non autenticata) coe­
renti
GNS_40 Quando il valore dello stato in una frase AMC ricevuta è
impostato su «J», «O» o «F» in conformità al requisito
GNS_4a, la VU deve generare e registrare un’anomalia di
tipo «Anomalia GNSS», come definita al requisito 88 bis
dell’allegato IC e all’appendice 1 (EventFaultType).
L’unità elettronica di bordo può effettuare verifiche sup­
plementari prima di memorizzare un’anomalia di tipo
«Anomalia GNSS» dopo la ricezione di un valore impo­
stato su «J» o «O».
7. CONFLITTO DI ORARI DEL GNSS
GNS_41 Se rileva una discrepanza tra l’ora della sua funzione di
misurazione del tempo e l’ora proveniente dai segnali
GNSS, la VU deve generare e registrare un’anomalia di
tipo «Conflitto di orari», come definita al requisito 86
dell’allegato IC e all’appendice 1 (EventFaultType).
8. DATI CONTRASTANTI SUL MOVIMENTO DEL VEICOLO
GNS_42 La VU deve attivare e registrare un’anomalia di tipo «Dati
contrastanti sul movimento del veicolo» in conformità al
requisito 84 dell’allegato IC, nel caso in cui le informa­
zioni sul movimento calcolate dal sensore di movimento
siano contraddette dalle informazioni sul movimento cal­
colate dal ricevitore GNSS interno, dal dispositivo GNSS
esterno o da altre fonti indipendenti di dati di movimento,
come indicato al requisito 26 dell’allegato IC.
L’anomalia di tipo «Dati contrastanti sul movimento del
veicolo» deve attivarsi quando si verifica una delle condi­
zioni di attivazione elencate di seguito.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 522
Condizione di attivazione 1
Il valore medio troncato delle differenze di velocità tra tali
sorgenti deve essere utilizzato, quando sono disponibili le
informazioni sulla posizione provenienti dal ricevitore
GNSS e quando viene inserito il contatto di accensione
del veicolo, come specificato di seguito:
— al massimo ogni 10 secondi deve essere calcolato il
valore assoluto della differenza tra la velocità del vei­
colo stimata dal GNSS e quella stimata dal sensore di
movimento;
— tutti i valori calcolati in una finestra temporale che
contempla gli ultimi 5 minuti di movimento del vei­
colo devono essere usati per calcolare il valore medio
troncato;
— il valore medio troncato deve essere calcolato come la
media dell’80 % dei valori rimanenti dopo l’elimina­
zione dei più elevati in valore assoluto.
L’anomalia di tipo «Dati contrastanti sul movimento del
veicolo» deve essere attivata se il valore medio troncato
supera i 10 Km/h per cinque minuti consecutivi di movi­
mento del veicolo. (Nota: si applica l’uso del valore medio
troncato sugli ultimi 5 minuti per attenuare il rischio di
misurare valori erratici e transitori).
Per il calcolo della media troncata, il veicolo deve essere
considerato in movimento se almeno un valore di velocità
stimato dal sensore di movimento o dal ricevitore GNSS è
diverso da zero.
Condizione di attivazione 2
L’anomalia di tipo «Dati contrastanti sul movimento del
veicolo» deve attivarsi anche se si verifica la seguente
condizione,
GnssDistance>[OdometerDifference×OdometerTolerance­
Factor+Minimum (SlipDistanceUpperlimit;(OdometerDif­
ference×SlipFactor))+GnssTolerance+FerryTrainDi­
stance]
in cui:
— GnssDistance è la distanza tra la posizione corrente
del veicolo e quella precedente, entrambe ottenute da
messaggi di posizione autenticata validi, senza consi­
derare l’altezza,
— OdometerDifference è la differenza tra il valore cor­
rente dell’odometro e il valore dell’odometro corri­
spondente al precedente messaggio di posizione auten­
ticata valido,
— OdometerToleranceFactor è pari a 1.1 (fattore di tol­
leranza più sfavorevole per tutte le tolleranze per la
misurazione dell’odometro del veicolo),
— GnssTolerance è pari a 1 km (tolleranza GNSS più
sfavorevole),
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 523
— Minimum (SlipDistanceUpperLimit; (OdometerDiffe­
rence * SlipFactor) è il valore minimo tra:
— SlipDistanceUpperLimit, che è pari a 10 km (li­
mite superiore della distanza di slittamento causata
dagli effetti di slittamento durante la frenatura),
— e OdometerDifference * SlipFactor, in cui lo Slip­
Factor è pari a 0,2 (influenza massima degli effetti
di slittamento durante la frenatura),
— FerryTrainDistance, così calcolata: FerryTrainDistance
= 200 km/h * tFerryTrain, dove tFerryTrain è la
somma delle durate in ore degli attraversamenti me­
diante traghetto/treno nell’intervallo di tempo conside­
rato. La durata di un attraversamento mediante tra­
ghetto/treno è definita come la differenza di tempo
tra l’indicatore di fine e l’indicatore di inizio.
Le verifiche precedenti devono essere effettuate ogni 15
minuti se sono disponibili i necessari dati sulla posizione,
altrimenti non appena i dati sulla posizione sono
disponibili.
Ai fini della presente condizione di attivazione:
— la data e l’ora di inizio dell’anomalia devono essere
uguali alla data e all’ora in cui è stato ricevuto il
messaggio di posizione precedente,
— la data e l’ora di fine dell’anomalia devono essere
uguali alla data e all’ora in cui la condizione verificata
risulta nuovamente falsa.
Condizione di attivazione 3
L’unità elettronica di bordo rileva una discrepanza consi­
stente nel fatto che il sensore di movimento non rileva
alcun movimento e che la fonte di dati di movimento
indipendente rileva un movimento per un periodo speci­
fico. Le condizioni per registrare una discrepanza e il
periodo di rilevamento della discrepanza devono essere
stabiliti dal fabbricante dell’unità elettronica di bordo,
ma la discrepanza deve essere rilevata in non più di tre
ore.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 524
Appendice 13
INTERFACCIA ITS
INDICE
1. INTRODUZIONE
1.1. Campo di applicazione
1.2. Acronimi e definizioni
2. NORME DI RIFERIMENTO
3. PRINCIPI DI FUNZIONAMENTO DELL’INTERFACCIA ITS
3.1. Tecnologia della comunicazione
3.2. Servizi disponibili
3.3. Accesso attraverso l’interfaccia ITS
3.4. Dati disponibili e necessità del consenso del conducente
4. ELENCO DEI DATI DISPONIBILI ATTRAVERSO L’INTERFACCIA
ITS E CLASSIFICAZIONE PERSONALI/NON PERSONALI
1. INTRODUZIONE
1.1. Campo di applicazione
ITS_01 La presente appendice specifica i principi di base della comunica­
zione attraverso l’interfaccia del tachigrafo con i sistemi di tra­
sporto intelligenti (ITS), di cui agli articoli 10 e 11 del regola­
mento (UE) n. 165/2014.
ITS_02 L’interfaccia ITS deve consentire ai dispositivi esterni di ottenere
dati dal tachigrafo, di utilizzare i servizi del tachigrafo nonché di
fornire dati al tachigrafo.
Possono essere a tal fine utilizzate altre interfacce del tachigrafo
(ad esempio bus CAN).
La presente appendice non precisa:
— in che modo i dati forniti attraverso l’interfaccia ITS sono
raccolti e gestiti all’interno del tachigrafo;
— la forma in cui i dati raccolti sono presentati alle applicazioni
installate nel dispositivo esterno;
— la specifica di sicurezza ITS in aggiunta a quanto previsto da
Bluetooth®;
— i protocolli Bluetooth® utilizzati dall’interfaccia ITS.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 525
1.2. Acronimi e definizioni
Nella presente appendice sono utilizzati i seguenti acronimi e le seguenti
definizioni specifici:
GNSS Global Navigation Satellite System (sistema globale di na­
vigazione satellitare)
ITS Intelligent Transport System (sistema di trasporto intelli­
gente)
OSI Open Systems Interconnection (interconnessione di sistemi
aperti)
VU Vehicle Unit (unità elettronica di bordo)
Unità ITS un dispositivo o un’applicazione esterni che utilizzano l’in­
terfaccia ITS della VU.
2. NORME DI RIFERIMENTO
ITS_03 La presente appendice fa riferimento ai regolamenti e alle norme
seguenti e dipende da essi nella loro interezza o in parte. Le
clausole della presente appendice fanno riferimento alle norme
pertinenti o alle clausole pertinenti delle norme. In caso di con­
traddizioni prevalgono le clausole della presente appendice.
Le norme cui si fa riferimento nella presente appendice sono:
— Bluetooth® – Core Version 5.0 (versione di base 5.0);
— ISO 16844-7: Veicoli stradali — Sistemi tachigrafici — Parte
7: Parametri;
— ISO/IEC7498-1:1994, Tecnologia dell’informazione - Intercon­
nessione dei sistemi aperti (OSI) - Modello di riferimento di
base, il modello di base.
3. PRINCIPI DI FUNZIONAMENTO DELL’INTERFACCIA ITS
ITS_04 La VU è responsabile della manutenzione e dell’aggiornamento dei
dati trasmessi attraverso l’interfaccia ITS, senza alcun coinvolgi­
mento da parte di quest’ultima.
3.1. Tecnologia della comunicazione
ITS_05 La comunicazione attraverso l’interfaccia ITS deve essere effettuata
tramite l’interfaccia Bluetooth® ed essere compatibile con Blueto­
oth® Low Energy (Bluetooth® a bassa energia) in conformità alla
versione Bluetooth 5.0 o successiva.
ITS_06 La comunicazione tra la VU e l’unità ITS deve essere stabilita
dopo il completamento di un processo di abbinamento Bluetooth®.
ITS_07 Una comunicazione sicura e criptata tra la VU e l’unità ITS deve
essere stabilita conformemente ai meccanismi delle specifiche
Bluetooth®. La presente appendice non specifica meccanismi di
cifratura o altri meccanismi di sicurezza oltre a quanto previsto
da Bluetooth®.
ITS_08 Bluetooth® utilizza un modello server/client per controllare la tra­
smissione di dati tra dispositivi, nel quale la VU deve essere il
server e l’unità ITS il client.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 526
3.2. Servizi disponibili
ITS_09 I dati da trasmettere attraverso l’interfaccia ITS in conformità al
punto 4 devono essere resi disponibili attraverso i servizi specifi­
cati nell’appendice 7 e nell’appendice 8. La VU deve inoltre met­
tere a disposizione dell’unità ITS i servizi necessari per l’immis­
sione manuale dei dati in conformità al requisito 61
dell’allegato IC e, in via facoltativa, per altre immissioni di dati
in tempo reale.
Figura 1
Ripartizione della comunicazione attraverso l’interfaccia ITS secondo i livelli del modello OSI
ITS_10 Se l’interfaccia di trasferimento dati è utilizzata attraverso il con­
nettore anteriore, la VU non deve fornire i servizi di trasferimento
specificati nell’appendice 7 tramite la connessione ITS Bluetooth®.
ITS_11 Se l’interfaccia per la taratura è utilizzata attraverso il connettore
anteriore, la VU non deve fornire i servizi di taratura specificati
nell’appendice 8 tramite la connessione ITS Bluetooth®.
3.3. Accesso attraverso l’interfaccia ITS
ITS_12 L’interfaccia ITS deve fornire un accesso senza fili a tutti i servizi
specificati nell’appendice 7 e nell’appendice 8, in sostituzione di
una connessione via cavo al connettore anteriore per la taratura e il
trasferimento dei dati di cui all’appendice 6.
ITS_13 La VU deve mettere a disposizione dell’utente l’interfaccia ITS in
base alla combinazione di carte tachigrafiche valide inserite nella
VU, come specificato nella tabella 1.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 527
Tabella 1
Disponibilità dell’interfaccia ITS in funzione del tipo di carta inserita nel tachigrafo
Disponibilità dell’interfaccia
ITS
Sede (slot) del conducente
Carta assente
Carta del condu­
cente
Carta di controllo Carta dell’officina Carta dell’azienda
S
ed
e
(s
lo
t)
d
el
s
ec
on
do
c
on
du
ce
nt
e Carta assente Non disponibile Disponibile Disponibile Disponibile Disponibile
Carta del condu­
cente
Disponibile Disponibile Disponibile Disponibile Disponibile
Carta di con­
trollo
Disponibile Disponibile Disponibile Non disponibile Non disponibile
Carta dell’offi­
cina
Disponibile Disponibile Non disponibile Disponibile Non disponibile
Carta
dell’azienda
Disponibile Disponibile Non disponibile Non disponibile Disponibile
ITS_14 Dopo un abbinamento ITS Bluetooth® andato a buon fine, la VU
deve assegnare la connessione ITS Bluetooth® alla specifica carta
tachigrafica inserita conformemente alla tabella 2:
Tabella 2
Assegnazione della connessione ITS in funzione del tipo di carta inserita nel tachigrafo
Assegnazione della connes­
sione ITS Bluetooth®
Sede (slot) del conducente
Carta assente
Carta del condu­
cente
Carta di controllo Carta dell’officina Carta dell’azienda
S
ed
e
(s
lo
t)
d
el
s
ec
on
do
c
on
du
ce
nt
e
Carta assente Non disponibile Carta del con­
ducente
Carta di con­
trollo
Carta dell’offi­
cina
Carta
dell’azienda
Carta del condu­
cente
Carta del con­
ducente
Carta del con­
ducente (**)
Carta di con­
trollo
Carta dell’offi­
cina
Carta
dell’azienda
Carta di con­
trollo
Carta di con­
trollo
Carta di con­
trollo
Carta di con­
trollo (*)
Non disponibile Non disponibile
Carta dell’offi­
cina
Carta dell’offi­
cina
Carta dell’offi­
cina
Non disponibile Carta dell’offi­
cina (*)
Non disponibile
Carta
dell’azienda
Carta
dell’azienda
Carta
dell’azienda
Non disponibile Non disponibile Carta
dell’azienda (*)
(*) La connessione ITS Bluetooth® deve essere assegnata alla carta tachigrafica nella sede (slot) del conducente della VU.
(**) L’utente deve selezionare la carta alla quale deve essere assegnata la connessione ITS Bluetooth® (inserita nella sede (slot) del
conducente o del secondo conducente).
ITS_15 In caso di estrazione della carta tachigrafica, la VU deve interrom­
pere la connessione ITS Bluetooth® assegnata a tale carta.
ITS_16 La VU deve supportare la connessione ITS ad almeno un’unità ITS
e può supportare connessioni a più unità ITS contemporaneamente.
ITS_17 I diritti di accesso ai dati e ai servizi disponibili attraverso l’inter­
faccia ITS devono soddisfare i requisiti 12 e 13 dell’allegato IC,
oltre a garantire il consenso del conducente specificato nella
sezione 3.4 della presente appendice.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 528
3.4. Dati disponibili e necessità del consenso del conducente
ITS_18 Tutti i dati del tachigrafo disponibili attraverso i servizi di cui al
punto 3.3 devono essere classificati come personali o non personali
per il conducente, per il secondo conducente o per entrambi.
ITS_19 L’interfaccia ITS deve rendere disponibile quanto meno l’elenco
dei dati classificati come obbligatori nella sezione 4.
ITS_20 I dati di cui alla sezione 4 classificati come «personali» devono
essere accessibili solo previo consenso del conducente, che accetta
pertanto che i dati personali possano uscire dalla rete del veicolo,
fatta eccezione per il caso previsto dal requisito ITS_25, per il
quale non è necessario il consenso del conducente.
ITS_21 I dati supplementari rispetto a quelli raccolti al punto 4 e conside­
rati obbligatori possono essere resi disponibili attraverso l’interfac­
cia ITS. I dati supplementari non contemplati al punto 4 devono
essere classificati come «personali» o «non personali» dal fabbri­
cante della VU, dato che il consenso del conducente è richiesto per
i dati classificati come personali, fatta eccezione per il caso di cui
al requisito ITS_25, per il quale non è necessario il consenso del
conducente.
ITS_22 All’atto dell’inserimento di una carta del conducente sconosciuta
all’unità elettronica di bordo, il titolare della carta deve essere
invitato dal tachigrafo a inserire il consenso alla trasmissione di
dati personali tramite l’interfaccia ITS, conformemente al requisito
61 dell’allegato IC.
ITS_23 Lo stato del consenso (abilitato/disabilitato) deve essere registrato
nella memoria di dati dell’unità elettronica di bordo.
ITS_24 Nel caso si alternino più conducenti, solo i dati personali relativi ai
conducenti che hanno dato il loro consenso devono essere acces­
sibili tramite l’interfaccia ITS. In presenza della condizione EQUI­
PAGGIO, ad esempio, se solo il conducente ha dato il proprio
consenso, i dati personali del secondo conducente non devono es­
sere accessibili.
ITS_25 Quando la VU è in modo controllo, azienda o taratura, i diritti di
accesso attraverso l’interfaccia ITS devono essere gestiti conforme­
mente ai requisiti 12 e 13 dell’allegato IC; il consenso del condu­
cente non è pertanto necessario.
4. ELENCO DEI DATI DISPONIBILI ATTRAVERSO L’INTERFACCIA
ITS E CLASSIFICAZIONE PERSONALI/NON PERSONALI
Denominazione dei dati Formato dei dati Fonte
Classificazione dei dati (personale/non
personale)
Consenso alla dispo­
nibilità dei dati
Disponibilità
Conducente
Secondo condu­
cente
VehicleIdentification­
Number
Appendice 8 VU non personale non personale consenso non ne­
cessario
obbligatoria
CalibrationDate ISO 16844-7 VU non personale non personale consenso non ne­
cessario
obbligatoria
TachographVehicle­
Speed
ISO 16844-7 VU personale N/D consenso del con­
ducente
obbligatoria
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 529
Denominazione dei dati Formato dei dati Fonte
Classificazione dei dati (personale/non
personale)
Consenso alla dispo­
nibilità dei dati
Disponibilità
Conducente
Secondo condu­
cente
Driver1WorkingState ISO 16844-7 VU personale N/D consenso del con­
ducente
obbligatoria
Driver2WorkingState ISO 16844-7 VU N/D personale consenso del se­
condo conducente
obbligatoria
DriveRecognize ISO 16844-7 VU non personale non personale consenso non ne­
cessario
obbligatoria
Driver1TimeRelated­
States
ISO 16844-7 VU personale N/D consenso del con­
ducente
obbligatoria
Driver2TimeRelated­
States
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
obbligatoria
DriverCardDriver1 ISO 16844-7 VU personale N/D consenso del con­
ducente
obbligatoria
DriverCardDriver2 ISO 16844-7 VU N/D personale consenso del se­
condo conducente
obbligatoria
OverSpeed ISO 16844-7 VU personale N/D consenso del con­
ducente
obbligatoria
TimeDate Appendice 8 VU non personale non personale consenso non ne­
cessario
obbligatoria
HighResolutionTotal­
VehicleDistance
ISO 16844-7 VU non personale non personale consenso non ne­
cessario
obbligatoria
HighResolutionTripDi­
stance
ISO 16844-7 VU non personale non personale consenso non ne­
cessario
obbligatoria
ServiceComponentI­
dentification
ISO 16844-7 VU non personale non personale consenso non ne­
cessario
obbligatoria
ServiceDelayCalendar­
TimeBased
ISO 16844-7 VU non personale non personale consenso non ne­
cessario
obbligatoria
Driver1Identification ISO 16844-7 Carta
del
con­
du­
cente
personale N/D consenso del con­
ducente
obbligatoria
Driver2Identification ISO 16844-7 Carta
del
con­
du­
cente
N/D personale consenso del se­
condo conducente
obbligatoria
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 530
Denominazione dei dati Formato dei dati Fonte
Classificazione dei dati (personale/non
personale)
Consenso alla dispo­
nibilità dei dati
Disponibilità
Conducente
Secondo condu­
cente
NextCalibrationDate Appendice 8 VU non personale non personale consenso non ne­
cessario
obbligatoria
Driver1ContinuousDri­
vingTime
ISO 16844-7 VU personale N/D consenso del con­
ducente
obbligatoria
Driver2ContinuousDri­
vingTime
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
obbligatoria
Driver1CumulativeBre­
akTime
ISO 16844-7 VU personale N/D consenso del con­
ducente
obbligatoria
Driver2CumulativeBre­
akTime
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
obbligatoria
Driver1CurrentDuratio­
nOfSelectedActivity
ISO 16844-7 VU personale N/D consenso del con­
ducente
obbligatoria
Driver2CurrentDuratio­
nOfSelectedActivity
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
obbligatoria
SpeedAuthorised Appendice 8 VU non personale non personale consenso non ne­
cessario
obbligatoria
TachographCardSlot1 ISO 16844-7 VU non personale N/D consenso non ne­
cessario
obbligatoria
TachographCardSlot2 ISO 16844-7 VU N/D non personale consenso non ne­
cessario
obbligatoria
Driver1Name ISO 16844-7 Carta
del
con­
du­
cente
personale N/D consenso del con­
ducente
obbligatoria
Driver2Name ISO 16844-7 Carta
del
con­
du­
cente
N/D personale consenso del se­
condo conducente
obbligatoria
OutOfScopeCondition ISO 16844-7 VU non personale non personale consenso non ne­
cessario
obbligatoria
ModeOfOperation ISO 16844-7 VU non personale non personale consenso non ne­
cessario
obbligatoria
Driver1CumulatedDri­
vingTimePreviousAn­
dCurrentWeek
ISO 16844-7 VU personale N/D consenso del con­
ducente
obbligatoria
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 531
Denominazione dei dati Formato dei dati Fonte
Classificazione dei dati (personale/non
personale)
Consenso alla dispo­
nibilità dei dati
Disponibilità
Conducente
Secondo condu­
cente
Driver2CumulatedDri­
vingTimePreviousAn­
dCurrentWeek
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
obbligatoria
EngineSpeed ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
RegisteringMember­
State
Appendice 8 VU non personale non personale consenso non ne­
cessario
obbligatoria
VehicleRegistration­
Number
Appendice 8 VU non personale non personale consenso non ne­
cessario
obbligatoria
Driver1EndOfLastDai­
lyRestPeriod
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2EndOfLastDai­
lyRestPeriod
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1EndOfLa­
stWeeklyRestPeriod
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2EndOfLa­
stWeeklyRestPeriod
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1EndOfSecon­
dLastWeeklyRestPe­
riod
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2EndOfSecon­
dLastWeeklyRestPe­
riod
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1CurrentDaily­
DrivingTime
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2CurrentDaily­
DrivingTime
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1CurrentWeekly­
DrivingTime
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2CurrentWeekly­
DrivingTime
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 532
Denominazione dei dati Formato dei dati Fonte
Classificazione dei dati (personale/non
personale)
Consenso alla dispo­
nibilità dei dati
Disponibilità
Conducente
Secondo condu­
cente
Driver1TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1CardExpiry­
Date
ISO 16844-7 Carta
del
con­
du­
cente
personale N/D consenso del con­
ducente
facoltativo
Driver2CardExpiry­
Date
ISO 16844-7 Carta
del
con­
du­
cente
N/D personale consenso del se­
condo conducente
facoltativo
Driver1CardNextMan­
datoryDownloadDate
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2CardNextMan­
datoryDownloadDate
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
TachographNextMan­
datoryDownloadDate
ISO 16844-7 VU non personale non personale consenso non ne­
cessario
facoltativo
Driver1TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1NumberOfTi­
mes9hDailyDrivingTi­
mesExceeded
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2NumberOfTi­
mes9hDailyDrivingTi­
mesExceeded
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1CumulativeU­
ninterruptedRestTime
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2CumulativeU­
ninterruptedRestTime
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1MinimumDai­
lyRest
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2MinimumDai­
lyRest
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 533
Denominazione dei dati Formato dei dati Fonte
Classificazione dei dati (personale/non
personale)
Consenso alla dispo­
nibilità dei dati
Disponibilità
Conducente
Secondo condu­
cente
Driver1MinimumWee­
klyRest
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2MinimumWee­
klyRest
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1MaximumDai­
lyPeriod
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2MaximumDai­
lyPeriod
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1MaximumDai­
lyDrivingTime
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2MaximumDai­
lyDrivingTime
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1NumberOfUse­
dReducedDailyRestPe­
riods
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2NumberOfUse­
dReducedDailyRestPe­
riods
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
Driver1RemainingCur­
rentDrivingTime
ISO 16844-7 VU personale N/D consenso del con­
ducente
facoltativo
Driver2RemainingCur­
rentDrivingTime
ISO 16844-7 VU N/D personale consenso del se­
condo conducente
facoltativo
VehiclePosition Appendice 8 VU personale personale consenso del con­
ducente e del se­
condo conducente
obbligatoria
ByDefaultLoadType Appendice 8 VU personale personale consenso del con­
ducente e del se­
condo conducente
obbligatoria
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 534
Appendice 14
FUNZIONE DI COMUNICAZIONE REMOTA
INDICE
1 INTRODUZIONE
2 CAMPO DI APPLICAZIONE
3 ACRONIMI, DEFINIZIONI E SIMBOLI
4 SCENARI OPERATIVI
4.1 Panoramica
4.1.1 Precondizioni per il trasferimento di dati tramite l'interfaccia DSRC 5,8
GHz
4.1.2 Profilo 1a: con un lettore della comunicazione remota a fini di diagnosi
precoce sorretto e puntato manualmente o posizionato su un cavalletto a
lato della strada e puntato
4.1.3 Profilo 1b: con un lettore della comunicazione remota a fini di diagnosi
precoce (REDCR) montato sul veicolo e puntato
4.2 Sicurezza/integrità
5 STRUTTURA E PROTOCOLLI DI COMUNICAZIONE REMOTA
5.1 Struttura
5.2 Sequenza
5.2.1 Operazioni
5.2.2 Interpretazione dei dati ricevuti tramite la comunicazione DSRC
5.3 Parametri dell'interfaccia fisica DSRC per la comunicazione remota
5.3.1 Vincoli relativi alla posizione
5.3.2 Parametri di downlink e uplink
5.3.3 Progettazione dell'antenna
5.4 Requisiti del protocollo DSRC per l'RTM
5.4.1 Panoramica
5.4.2 Comandi
5.4.3 Sequenza di comandi di interrogazione
5.4.4 Strutture dei dati
5.4.5 Elementi di RtmData, azioni eseguite e definizioni
5.4.6 Meccanismo di trasferimento dei dati
5.4.7 Descrizione dettagliata della transazione DSRC
5.4.8 Descrizione della transazione di prova DSRC
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 535
5.5 Riservato per uso futuro
▼B
5.6 Trasferimento di dati tra la DSRC-VU e la VU
5.6.1 Collegamento fisico e interfacce
5.6.2 Protocollo dell'applicazione
5.7 Trattamento degli errori
5.7.1 Registrazione e comunicazione dei dati nella DSRC-VU
5.7.2 Errori di comunicazione senza fili
6 PROVE DI ATTIVAZIONE E DI ISPEZIONE PERIODICA PER LA
FUNZIONE DI COMUNICAZIONE REMOTA
6.1 Aspetti generali
6.2 ECHO
6.3 Prove per convalidare il contenuto dei dati sicuri
1 INTRODUZIONE
La presente appendice stabilisce le specifiche di progettazione e le pro­
cedure da seguire per realizzare la funzione di comunicazione remota (la
comunicazione) conformemente all'articolo 9 del regolamento (UE)
n. 165/2014 (il regolamento).
DSC_1 Il regolamento (UE) n. 165/2014 stabilisce che il tachigrafo
deve essere munito di una funzionalità di comunicazione re­
mota che consenta agli agenti delle autorità di controllo com­
petenti di leggere le informazioni del tachigrafo dai veicoli in
transito tramite un dispositivo che interroga il tachigrafo a
distanza [il lettore della comunicazione remota a fini di dia­
gnosi precoce (REDCR)]. Tale dispositivo di interrogazione si
collega senza fili grazie alle interfacce CEN 5,8 GHz di co­
municazione dedicata a corto raggio (DSRC).
È importante capire che questa funzionalità è intesa a fungere
esclusivamente da prefiltro per scegliere i veicoli da sottoporre
a ispezione e non sostituisce la procedura di ispezione formale
prevista dal regolamento (UE) n. 165/2014. Si veda il consi­
derando 9 del preambolo del presente regolamento, che stabi­
lisce che la comunicazione remota fra il tachigrafo e le autorità
preposte ai controlli ai fini dei controlli su strada agevola i
controlli su strada mirati.
DSC_2 I dati devono essere scambiati usando la comunicazione, che deve
consistere in uno scambio senza fili tramite DSRC 5,8 GHz con­
forme alla presente appendice. Essi devono essere testati per ve­
rificarne la compatibilità ai parametri pertinenti della norma EN
300 674-1, [Electromagnetic compatibility and Radio spectrum
Matters (ERM); Road Transport and Traffic Telematics (RTTT);
Dedicated Short Range Communication (DSRC) transmission
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 536
equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz Indu­
strial, Scientific and Medical (ISM) band; Part 1: General charac­
teristics and test methods for Road Side Units (RSU) and On
-Board Units (OBU)].
DSC_3 La comunicazione con i relativi dispositivi deve essere stabilita
solo quando richiesto dal dispositivo dell'autorità di controllo
competente tramite mezzi di comunicazione radio conformi [il
lettore della comunicazione remota a fini di diagnosi
precoce (REDCR)].
DSC_4 I dati devono essere protetti per garantirne l'integrità.
DSC_5 L'accesso ai dati comunicati deve essere limitato alle autorità
di controllo competenti autorizzate ad accertare le violazioni
del regolamento (CE) n. 561/2006 e del regolamento (UE)
n. 165/2014 e alle officine, nella misura necessaria alla verifica
del corretto funzionamento del tachigrafo.
DSC_6 I dati scambiati durante la comunicazione devono limitarsi ai
dati necessari ai fini dei controlli su strada mirati dei veicoli
muniti di un tachigrafo potenzialmente manomesso o usato
impropriamente.
DSC_7 L'integrità e la sicurezza dei dati devono essere ottenute con­
servando i dati nell'unità elettronica di bordo (VU) in modalità
sicura e comunicando solo il payload in modalità sicura e i
dati relativi alla sicurezza (cfr. paragrafo 5.4.4) tramite il
mezzo di comunicazione remota senza fili DSRC 5,8 GHz.
In questo modo solo le persone autorizzate delle autorità di
controllo competenti hanno modo di capire i dati trasmessi con
la comunicazione e di verificarne l'autenticità. Cfr. l'appendice
11 (Meccanismi comuni di sicurezza).
DSC_8 I dati devono contenere un timeStamp indicante l'ora dell'ul­
timo aggiornamento.
DSC_9 Il contenuto dei dati di sicurezza deve essere noto e sotto il
controllo esclusivo delle autorità di controllo competenti e
delle parti con cui condividono queste informazioni ed esula
dalle disposizioni della comunicazione oggetto della presente
appendice, tranne per il fatto che la comunicazione prevede il
trasferimento di un pacchetto di dati di sicurezza con ciascun
pacchetto di payload.
DSC_10 La stessa architettura e gli stessi dispositivi devono poter es­
sere usati per acquisire altri concetti di dati (come il peso a
bordo) usando l'architettura qui specificata.
DSC_11 A scanso di equivoci, in conformità alle disposizioni del
regolamento (UE) n. 165/2014, articolo 7, i dati riguardanti
l'identità del conducente non devono essere comunicati tramite
la comunicazione.
2 CAMPO DI APPLICAZIONE
La presente appendice specifica come gli agenti delle autorità di controllo
competenti usano una comunicazione senza fili DSRC 5,8 GHz specificata
per ottenere dati a distanza (i dati) da un veicolo bersaglio,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 537
che rivelano che tale veicolo potrebbe violare il regolamento (UE)
n. 165/2014 e sarebbe opportuno valutare di fermarlo per ulteriori controlli.
Secondo il regolamento (UE) n. 165/2014, i dati raccolti devono limi­
tarsi o appartenere a dati che identificano una potenziale violazione,
come definita all'articolo 9 del medesimo.
▼M1
In questo scenario, il tempo a disposizione per la comunicazione è
limitato, perché la comunicazione è mirata e a corto raggio. Il mezzo
di comunicazione usato per il monitoraggio a distanza del
tachigrafo (RTM) può essere inoltre usato dalle autorità di controllo
competenti anche per altre applicazioni [ad esempio per i pesi massimi
e le dimensioni massime dei veicoli commerciali pesanti definiti nella
direttiva (UE) 2015/719] e tali operazioni possono essere separate o in
sequenza a discrezione delle autorità di controllo competenti.
▼B
La presente appendice specifica:
— Le apparecchiature, le procedure e i protocolli di comunicazione da
usare per la comunicazione
— Le norme e i regolamenti ai quali le apparecchiature radio devono
essere conformi
— La presentazione dei dati alle apparecchiature di comunicazione
— Le procedure di richiesta e di trasferimento e la sequenza delle
operazioni
— I dati da trasferire
— La potenziale interpretazione dei dati trasferiti durante la comunica­
zione
— Le disposizioni sui dati di sicurezza relativi alla comunicazione
— La messa a disposizione dei dati alle autorità di controllo competenti
— In che modo il lettore della comunicazione remota a fini di diagnosi
precoce può richiedere diversi concetti di dati sul carico e sul parco
veicoli
A fini di chiarezza, la presente appendice non specifica:
— la raccolta del funzionamento e della gestione dei dati all'interno
della VU (che deve essere una funzione della progettazione del
prodotto salvo altra indicazione nel regolamento (UE) n. 165/2014);
— la forma in cui i dati raccolti sono presentati all'agente delle autorità di
controllo competenti né i criteri che le autorità di controllo competenti
devono usare per decidere quali veicoli fermare (che deve essere una
funzione della progettazione del prodotto salvo altra indicazione nel
regolamento (UE) n. 165/2014 o una decisione delle autorità di controllo
competenti). A scanso di equivoci: la comunicazione si limita a mettere i
dati a disposizione delle autorità di controllo competenti per consentire
loro di prendere decisioni informate;
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 538
— le disposizioni sulla sicurezza dei dati (come la cifratura) per quanto
riguarda il contenuto dei dati (che devono essere specificate nell'ap­
pendice 11: Meccanismi comuni di sicurezza);
— i particolari in merito a concetti di dati diversi dall'RTM che possono
essere ottenuti usando la stessa architettura e le stesse
apparecchiature;
— i particolari in merito al comportamento e alla gestione tra VU e
DSRC-VU e il comportamento nella DSRC-VU (diversi dai dati
forniti su richiesta di un REDCR).
3 ACRONIMI, DEFINIZIONI E SIMBOLI
Nella presente appendice sono utilizzati i seguenti acronimi e le seguenti
definizioni specifici:
l'antenna dispositivo elettrico che trasforma
l'energia elettrica in onde radio e vi­
ceversa, usato in combinazione con
un trasmettitore o un ricevitore ra­
dio. Quando è in funzione, un tra­
smettitore radio fornisce ai terminali
dell'antenna una corrente elettrica
che oscilla a radiofrequenza e l'an­
tenna irradia l'energia dalla corrente
sotto forma di onde elettromagneti­
che (onde radio). In modalità rice­
zione, un'antenna intercetta parte
dell'energia di un'onda elettromagne­
tica per produrre un basso voltaggio
ai terminali, che è applicato ad un
ricevitore per essere amplificato.
la comunicazione scambio di informazioni/dati tra un
DSRC-REDCR e una DSRC-VU in
conformità al paragrafo 5 in una re­
lazione tra master e slave per otte­
nere i dati.
i dati dati sicuri di formato definito (cfr.
paragrafo 5.4.4) richiesti dal
DSRC-REDCR e forniti al DSRC-
REDCR dalla DSRC-VU tramite un
collegamento DSRC 5,8 GHz come
definito nel paragrafo 5 a seguire.
Regolamento (UE) n. 165/2014 Regolamento (UE) n. 165/2014 del
Parlamento europeo e del Consiglio,
del 4 febbraio 2014, relativo ai ta­
chigrafi nel settore dei trasporti su
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 539
strada, che abroga il regolamento
(CEE) n. 3821/85 del Consiglio re­
lativo all'apparecchio di controllo
nel settore dei trasporti su strada e
modifica il regolamento (CE)
n. 561/2006 del Parlamento europeo
e del Consiglio relativo all'armoniz­
zazione di alcune disposizioni in
materia sociale nel settore dei tra­
sporti su strada.
AID Identificativo dell'applicazione
BLE Bluetooth a bassa energia
BST Beacon Service Table (tabella di ser­
vizio del segnale)
CIWD Inserimento carta durante la guida
CRC Controllo di ridondanza ciclica
DSC (n) Identificativo di un requisito per
un'appendice DSRC specifica
DSRC Comunicazione dedicata a corto rag­
gio
DSRC-REDCR DSRC — lettore della comunica­
zione remota a fini di diagnosi pre­
coce
DSRC-VU DSRC — unità elettronica di bordo.
Si tratta del «meccanismo di dia­
gnosi precoce remota» definito nel­
l'allegato 1C.
DWVC Guida in assenza di una carta valida
EID Identificativo dell'elemento
LLC Controllo del collegamento logico
LPDU Unità dati del protocollo LLC
OWS Sistema di pesatura di bordo
PDU Unità dati del protocollo
REDCR Lettore della comunicazione remota
a fini di diagnosi precoce. Si tratta
del «dispositivo di lettura della co­
municazione remota a fini di dia­
gnosi precoce» definito nell'allegato
1C.
RTM Monitoraggio a distanza del tachi­
grafo
SM-REDCR Modulo di sicurezza-Lettore della
comunicazione remota a fini di dia­
gnosi precoce
TARV Telematics Applications for Regula­
ted Vehicles (serie di norme ISO
15638)
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 540
VU Unità elettronica di bordo
VUPM Memoria del payload dell'unità elet­
tronica di bordo
VUSM Modulo di sicurezza dell'unità elet­
tronica di bordo
VST Vehicle Service Table (tabella di
servizio del veicolo)
WIM Rilevamento del peso con veicolo in
movimento
WOB Pesatura a bordo
La specifica definita nella presente appendice fa riferimento ai regola­
menti e alle norme seguenti e dipende da essi nella loro interezza o in
parte. Le clausole della presente appendice indicano le norme pertinenti
o le clausole pertinenti delle norme. In caso di contraddizioni prevalgono
le clausole della presente appendice. In caso di contraddizioni, laddove
nella presente appendice non è determinata chiaramente nessuna speci­
fica, prevale il rispetto di ERC 70-03 (e le prove per verificare la
conformità ai parametri pertinenti di EN 300 674-1), seguito in ordine
di preferenza discendente da EN 12795, EN 12253, EN 12834 e EN
13372, 6.2, 6.3, 6.4 e 7.1.
Di seguito sono elencati i regolamenti e le norme cui si fa riferimento
nella presente appendice:
[1] Regolamento (UE) n. 165/2014 del Parlamento europeo e del Con­
siglio, del 4 febbraio 2014, relativo ai tachigrafi nel settore dei
trasporti su strada, che abroga il regolamento (CEE) n. 3821/85
del Consiglio relativo all'apparecchio di controllo nel settore dei
trasporti su strada e modifica il regolamento (CE) n. 561/2006 del
Parlamento europeo e del Consiglio relativo all'armonizzazione di
alcune disposizioni in materia sociale nel settore dei trasporti su
strada.
[2] Regolamento (CE) n. 561/2006 del Parlamento europeo e del Con­
siglio, del 15 marzo 2006, relativo all'armonizzazione di alcune
disposizioni in materia sociale nel settore dei trasporti su strada e
che modifica i regolamenti del Consiglio (CEE) n. 3821/85 e (CE)
n. 2135/98 e abroga il regolamento (CEE) n. 3820/85 del Consiglio
(Testo rilevante ai fini del SEE).
[3] ERC 70-03 CEPT: ECC Recommendation 70-03: Relating to the
Use of Short Range Devices (SRD).
[4] ISO 15638 Intelligent transport systems — Framework for coo­
perative telematics applications for regulated commercial freight
vehicles (TARV).
[5] EN 300 674-1 Electromagnetic compatibility and Radio spectrum
Matters (ERM); Road Transport and Traffic Telematics (RTTT);
Dedicated Short Range Communication (DSRC) transmission
equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz Indu­
strial, Scientific and Medical (ISM) band; Part 1: General charac­
teristics and test methods for Road Side Units (RSU) and On-Board
Units (OBU).
[6] EN 12253 Road transport and traffic telematics — Dedicated
short-range communication — Physical layer using microwave at
5.8 GHz.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 541
[7] EN 12795 Road transport and traffic telematics — Dedicated
short-range communication — Data link layer: medium access
and logical link control.
[8] EN 12834 Road transport and traffic telematics — Dedicated
short-range communication — Application layer.
[9] EN 13372 Road transport and traffic telematics — Dedicated
short-range communication — Profiles for RTTT applications
[10] ISO 14906 Electronic fee collection — Application interface defi­
nition for dedicated short- range communication
4 SCENARI OPERATIVI
4.1 Panoramica
Il regolamento (UE) n. 165/2014 definisce gli scenari specifici e con­
trollati entro cui si deve usare la comunicazione.
Gli scenari supportati sono:
«Profilo di comunicazione 1: ispezione dal lato della strada utilizzando
un lettore della comunicazione remota a fini di diagnosi precoce a corto
raggio senza fili che avvia un'ispezione fisica dal lato della strada
(master-slave).
Profilo del lettore 1a: tramite un lettore della comunicazione remota a
fini di diagnosi precoce sorretto e puntato manualmente o posizionato
temporaneamente su un cavalletto a lato della strada e puntato.
Profilo del lettore 1b: tramite un lettore della comunicazione remota a
fini di diagnosi precoce montato sul veicolo e puntato».
4.1.1 Precondizioni per il trasferimento di dati tramite l'interfaccia DSRC
5,8 GHz
NOTA: per capire il contesto delle precondizioni si prega di far riferi­
mento alla figura 14.3 a seguire.
4.1.1.1 Dati memorizzati nella VU
DSC_12 È compito della VU aggiornare ogni 60 secondi e conservare i
dati da archiviare al suo interno, senza interventi della fun­
zione di comunicazione DSRC. I mezzi per conseguire questo
obiettivo sono interni alla VU e sono specificati nel
regolamento (UE) n. 165/2014, allegato 1C, paragrafo 3.19
«Comunicazione remota per controlli su strada mirati» e
non sono specificati nella presente appendice.
4.1.1.2 Dati forniti al dispositivo DSRC-VU
DSC_13 È compito della VU aggiornare i dati DSRC del tachigrafo (i
dati) ogniqualvolta i dati memorizzati nella VU sono aggior­
nati agli intervalli determinati al paragrafo 4.1.1.1 (DSC_12),
senza interventi della funzione di comunicazione DSRC.
DSC_14 I dati della VU vanno utilizzati come base per popolare e
aggiornare i dati; i mezzi per raggiungere tale obiettivo sono
specificati nell'allegato 1C, paragrafo 3.19 «Comunicazione
remota per controlli su strada mirati» o in assenza di tale
specifica, sono una funzione della progettazione del prodotto
e non sono specificati nella presente appendice. Per la struttura
del collegamento tra il dispositivo DSRC-VU e la VU si prega
di far riferimento al paragrafo 5.6.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 542
4.1.1.3 Contenuto dei dati
DSC_15 Il contenuto e il formato dei dati devono essere tali da con­
sentire che, una volta decriptati, i dati siano strutturati e resi
disponibili nella forma e nel formato specificati al
paragrafo 5.4.4 della presente appendice (Strutture dei dati).
4.1.1.4 Presentazione dei dati
DSC_16 I dati, che sono stati tenuti frequentemente aggiornati secondo
le procedure di cui al paragrafo 4.1.1.1, devono essere resi
sicuri prima di essere presentati alla DSRC-VU e devono es­
sere presentati come un valore sicuro del concetto di dati per
essere temporaneamente memorizzati nella DSRC-VU quale
versione corrente dei dati. Questi dati sono trasferiti dal
VUSM alla funzione DSRC VUMP. VUSM e VUPM sono
funzioni e non necessariamente entità fisiche. La forma di
istanziazione fisica per eseguire queste funzioni deve essere
una questione di progettazione del prodotto salvo altra indica­
zione nel regolamento (UE) n. 165/2014.
4.1.1.5 Dati di sicurezza
▼M3
DSC_17 I dati di sicurezza (DSRCSecurityData), compresi i dati richie­
sti dal REDCR per completare la sua capacità di decriptare i
dati, devono essere forniti come definito nell’appendice 11
(Meccanismi comuni di sicurezza) per essere temporaneamente
memorizzati nella DSRC-VU quale versione corrente dei
DSRCSecurityData, nella forma definita al punto 5.4.4 della
presente appendice.
▼B
4.1.1.6 Dati VUMP disponibili per essere trasferiti tramite l'interfaccia DSRC
DSC_18 Il concetto di dati che deve sempre essere disponibile nella
funzione DSRC VUMP per il trasferimento immediato su ri­
chiesta del REDCR è definito al paragrafo 5.4.4 per le specifi­
che complete del modulo ASN.1.
Panoramica generale del profilo di comunicazione 1
Questo profilo riguarda il caso di impiego in cui un agente delle autorità
di controllo competenti usa un lettore della comunicazione remota a fini
di diagnosi precoce (il REDCR) per una comunicazione remota a corto
raggio (interfacce DSRC 5,8 GHz che funzionano in conformità alla
norma ERC 70-03 e sono testate per verificarne la conformità ai para­
metri pertinenti di EN 300 674-1, come descritto al paragrafo 5) fina­
lizzata ad identificare a distanza un veicolo che potrebbe violare il
regolamento (UE) n. 165/2014. Una volta identificato, l'agente delle
autorità di controllo competenti, che sta controllando il dispositivo di
interrogazione, decide se il veicolo debba essere fermato.
4.1.2 Profilo 1a: con un lettore della comunicazione remota a fini di diagnosi
precoce sorretto e puntato manualmente o posizionato su un cavalletto a
lato della strada e puntato
In questo caso d'impiego, l'agente delle autorità di controllo competenti è
posizionato a lato della strada e punta un REDCR, che regge in mano o
che è montato su un cavalletto o su un sostegno simile, dal ciglio della
strada al centro del parabrezza del veicolo bersaglio. L'interrogazione
avviene tramite interfacce DSRC 5,8 GHz che funzionano in conformità
alla norma ERC 70-03 e sono testate per verificarne la conformità ai
parametri pertinenti di EN 300 674-1, come descritto al paragrafo 5. Cfr.
la figura 14.1 (Caso d'impiego 1).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 543
Figura 14.1
Interrogazione dal lato della strada tramite interfacce DSRC 5,8 GHz
4.1.3 Profilo 1b: con un lettore della comunicazione remota a fini di diagnosi
precoce (REDCR) montato sul veicolo e puntato
In questo caso d'impiego, l'agente delle autorità di controllo competenti
si trova su un veicolo in movimento e punta un REDCR portatile, che
regge in mano, dal veicolo al centro del parabrezza del veicolo bersaglio
oppure il REDCR è montato nel o sul veicolo in modo da puntare verso
il centro del parabrezza del veicolo bersaglio quando il veicolo in cui si
trova il lettore della comunicazione remota a fini di diagnosi precoce è
in una particolare posizione rispetto al veicolo bersaglio, ad esempio
direttamente davanti ad esso in un flusso di traffico. L'interrogazione
avviene tramite interfacce DSRC 5,8 GHz che funzionano in conformità
alla norma ERC 70-03 e sono testate per verificarne la conformità ai
parametri pertinenti di EN 300 674-1, come descritto al paragrafo 5. Cfr.
la figura 14.2. (Caso d'impiego 2).
Figura 14.2
Interrogazione da un veicolo tramite interfacce DSRC 5,8 GHz
4.2 Sicurezza/integrità
Per consentire la verifica dell'autenticità e dell'integrità dei dati trasferiti
tramite comunicazione remota, i dati sicuri sono verificati e decriptati
conformemente all'appendice 11 (Meccanismi comuni di sicurezza).
5 STRUTTURA E PROTOCOLLI DI COMUNICAZIONE REMOTA
5.1 Struttura
La struttura della funzione di comunicazione remota nel tachigrafo in­
telligente è illustrata nella figura 14.3.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 544
Figura 14.3
Struttura della funzione di comunicazione remota
DSC_19 Le seguenti funzioni si trovano nella VU:
— modulo di sicurezza (VUSM). Questa funzione presente
nella VU è responsabile della sicurezza dei dati che de­
vono essere trasmessi dalla DSRC-VU all'agente delle au­
torità di controllo competenti tramite comunicazione
remota.
— I dati sicuri sono memorizzati nella memoria VUSM. Agli
intervalli determinati al paragrafo 4.1.1.1 (DSC_12), la VU
cripta e ricostituisce il concetto di dati RTM conservato
nella memoria della DSRC-VU. Tale concetto di dati RTM
comprende i valori del concetto di dati del payload e di
sicurezza determinati più avanti nella presente appendice.
Il funzionamento del modulo di sicurezza è definito nel­
l'appendice 11 (Meccanismi comuni di sicurezza) ed esula
dal campo di applicazione della presente appendice, salvo
l'obbligo di fornire aggiornamenti al dispositivo di comu­
nicazione della VU ogni volta che cambiano i dati della
VUSM.
— La comunicazione tra la VU e la DSRC-VU può essere
cablata o Bluetooth a bassa energia (BLE) e la DSRC-VU
può essere integrata nell'antenna sul parabrezza del veicolo,
nella VU o posizionata tra le due.
— La DSRC-VU deve avere una fonte affidabile di energia
sempre disponibile. La modalità di fornitura dell'energia
alla DSRC-VU è una decisione progettuale.
— La memoria della DSRC-VU deve essere non volatile per
conservare i dati anche quando il veicolo viene spento.
— Se la comunicazione tra la VU e la DSRC-VU avviene
tramite BLE e la fonte di energia è una batteria non rica­
ricabile, tale fonte di energia deve essere sostituita ad ogni
ispezione periodica e il fabbricante delle apparecchiature
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 545
della DSRC-VU è responsabile di garantire che la fornitura
di energia copra il periodo tra due ispezioni periodiche,
assicurando l'accesso usuale ai dati da parte di un REDCR
per tutto il periodo senza malfunzionamenti o interruzioni.
— Dispositivo di memoria dei dati utili trasmessi dalla VU
durante l'RTM (VUPM). Questa funzione presente nella
VU è responsabile della fornitura e dell'aggiornamento
dei dati. Il contenuto dei dati («TachographPayload») è
definito ai paragrafi 5.4.4/5.4.5 a seguire ed è aggiornato
agli intervalli determinati al paragrafo 4.1.1.1 (DSC_12).
— DSRC-VU. Questa funzione, integrata o collegata all'an­
tenna e in comunicazione con la VU tramite una connes­
sione cablata o senza fili (BLE), contiene i dati correnti
(dati della VUMP) e gestisce la risposta ad un'interroga­
zione attraverso l'interfaccia DSRC 5,8 GHz. Lo scollega­
mento del dispositivo DSRC o l'interferenza con il suo
funzionamento durante il normale funzionamento del vei­
colo saranno interpretati come una violazione del
regolamento (UE) n. 165/2014.
— Il modulo di sicurezza (REDCR) (SM-REDCR) è la fun­
zione usata per decriptare e controllare l'integrità dei dati
provenienti dalla VU. Le modalità di esecuzione di tali
operazioni sono definite nell'appendice 11 (Meccanismi
comuni di sicurezza) e non nella presente appendice.
— La funzione (REDCR) del dispositivo DSRC (DSRC-
REDCR) comprende un ricetrasmettitore 5,8 GHz e il fir­
mware e il software associati che gestiscono la comunica­
zione con la DSRC-VU secondo la presente appendice.
— Il DSRC-REDCR interroga la DSRC-VU del veicolo bersa­
glio, ottiene i dati (i dati della VUPM correnti del veicolo
bersaglio) tramite il collegamento DSRC e elabora e me­
morizza i dati ricevuti nel suo SM-REDCR.
▼M1
— L’antenna DSRC-VU deve essere posizionata in modo da
ottimizzare la comunicazione DSRC tra il veicolo e l’an­
tenna del lettore a lato della strada, se il lettore è installato
a 15 metri di distanza di fronte al veicolo e a due metri di
altezza dal suolo ed è orientato al centro del parabrezza del
veicolo sugli assi orizzontale e verticale. Sui veicoli leggeri
è appropriato installarla nella parte superiore del para­
brezza. Su tutti gli altri veicoli l’antenna DSRC dovrebbe
essere installata in prossimità della parte inferiore o della
parte superiore del parabrezza.
▼B
DSC_20 L'antenna e la comunicazione devono funzionare in conformità
alla norma ERC 70-03 e devono essere testate per verificarne
la conformità ai parametri pertinenti di EN 300 674-1, come
descritto nel paragrafo 5. L'antenna e la comunicazione pos­
sono applicare tecniche di mitigazione del rischio di interfe­
renze senza fili, come descritto nella relazione 228 dell'ECC,
utilizzando, ad esempio, filtri nella comunicazione CEN DSRC
5,8 GHz.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 546
DSC_21 L'antenna DSRC deve essere collegata al dispositivo DSRC-VU
direttamente nel modulo montato sul o in prossimità del para­
brezza o tramite un cavo dedicato costruito in modo da renderne
difficile lo scollegamento non autorizzato. Lo scollegamento o
l'interferenza col funzionamento dell'antenna saranno considerati
una violazione del regolamento (UE) n. 165/2014. La scherma­
tura deliberata o qualsiasi stratagemma per impedire all'antenna
di funzionare correttamente saranno interpretati come una viola­
zione del regolamento (UE) n. 165/2014.
DSC_22 ►M1 Il fattore di forma dell’antenna non è definito ed è una
decisione commerciale, purché la DSRC-VU montata soddisfi
i requisiti di conformità definiti nel paragrafo 5 che segue.
L’antenna deve essere posizionata come determinato in
DSC_19 e deve supportare efficacemente i casi d’impiego de­
scritti ai paragrafi 4.1.2 e 4.1.3. ◄
Figura 14.4
Esempio di posizionamento dell'antenna DSRC 5,8 GHz sul
parabrezza dei veicoli oggetto del regolamento
Il fattore di forma del REDCR e della sua antenna può variare a seconda
che il lettore sia montato su un cavalletto, tenuto in mano, montato sul
veicolo, ecc. e secondo il modus operandi dell'agente delle autorità di
controllo competenti.
Si usa una funzione di visualizzazione e/o di notifica per presentare i
risultati della funzione di comunicazione remota all'agente delle autorità
di controllo competenti. Tali risultati possono essere visualizzati sullo
schermo, stampati, segnalati acusticamente o si può usare una combina­
zione di questi sistemi. La forma di tale visualizzazione e/o notifica
dipende dalle esigenze degli agenti delle autorità di controllo competenti
e dalla progettazione delle apparecchiature e non è specificata nella
presente appendice.
DSC_23 Il progetto e il fattore di forma del REDCR sono una questione
di design commerciale, nel rispetto della norma ERC 70-03 e
delle specifiche concernenti il progetto e le prestazioni di cui
alla presente appendice (paragrafo 5.3.2). In questo modo è
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 547
garantita massima flessibilità di mercato per progettare e for­
nire apparecchiature adatte agli scenari di interrogazione spe­
cifici delle diverse autorità di controllo competenti.
DSC_24 Il progetto e il fattore di forma della DSRC-VU e il suo posi­
zionamento all'interno o all'esterno della VU sono una que­
stione di design commerciale, nel rispetto della norma ERC
70-03 e delle specifiche concernenti il progetto e le prestazioni
di cui alla presente appendice (paragrafo 5.3.2) e alla presente
clausola (5.1).
DSC_25 La DSRC-VU deve tuttavia essere ragionevolmente in grado di
accettare valori dei concetti di dati di altre apparecchiature
intelligenti del veicolo, ad esempio da dispositivi di pesatura
a bordo, grazie a un collegamento e a protocolli comuni stan­
dard aperti, purché tali concetti di dati siano identificati da
identificativi dell'applicazione/nomi di file noti. Le istruzioni
per il funzionamento di tali protocolli devono essere messe a
disposizione della Commissione europea e dei fabbricanti delle
apparecchiature pertinenti gratuitamente.
5.2 Sequenza
5.2.1 Operazioni
La sequenza delle operazioni è rappresentata nella figura 14.5.
Figura 14.5
Sequenza della funzione di comunicazione remota
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 548
Le fasi sono descritte di seguito:
a. quando il veicolo è in funzione (accensione ON), il tachigrafo invia
dati alla funzione VU. La funzione VU prepara i dati (criptati) per
la funzione di comunicazione remota e aggiorna la VUPM conser­
vata nella memoria della DSRC-VU (come definita ai paragrafi
4.1.1.1 e 4.1.1.2). I dati raccolti devono essere formattati come
prescritto ai paragrafi 5.4.4 e 5.4.5 a seguire.
b. Ogni volta che i dati sono aggiornati, deve essere aggiornato il
timeStamp definito nel concetto di dati di sicurezza.
c. La funzione VUSM rende i dati sicuri secondo le procedure definite
nell'appendice 11.
d. Ogni volta che i dati sono aggiornati (cfr. i paragrafi 4.1.1.1 e
4.1.1.2), essi sono trasferiti alla DSRC-VU, dove sostituiscono gli
eventuali dati precedenti, in modo che i dati correnti aggiornati (i
dati) siano sempre disponibili e possano sempre essere forniti ad un
REDCR in caso di interrogazione. Quando i dati sono forniti dalla
VU alla DSRC-VU, essi devono essere identificabili dal nome del
file RTMData o tramite identificativi dell'applicazione e dell'attri­
buto.
e. Se un agente delle autorità di controllo competenti vuole raccogliere
i dati di un veicolo, egli deve innanzitutto inserire la propria smar­
tcard nel REDCR per consentire la comunicazione e per consentire
all'SM-REDCR di verificare l'autenticità dei dati e di decriptarli.
f. Poi l'agente dell'autorità di controllo competente punta un veicolo e
ne richiede i dati tramite comunicazione remota. Il REDCR, tramite
l'interfaccia DSRC 5,8 GHz, apre una sessione con la DSRC-VU del
veicolo bersaglio e richiede i dati. I dati sono trasferiti al REDCR
tramite il sistema di comunicazione senza fili come un attributo
DSRC usando l'applicazione GET definita al paragrafo 5.4. L'attri­
buto contiene i valori criptati del payload e i dati di sicurezza
DSRC.
g. I dati sono analizzati dalle apparecchiature REDCR e forniti al­
l'agente dell'autorità di controllo competente.
h. L'agente dell'autorità di controllo competente usa i dati per decidere
se fermare o meno il veicolo per ispezionarlo nel dettaglio o se
chiedere ad un altro agente dell'autorità di controllo competente di
fermare il veicolo.
5.2.2 Interpretazione dei dati ricevuti tramite la comunicazione DSRC
DSC_26 I dati ricevuti tramite l'interfaccia 5,8 GHz devono conservare
esclusivamente il significato e il valore definiti ai successivi
paragrafi 5.4.4 e 5.4.5 e devono essere intesi nel quadro degli
obiettivi ivi definiti. In conformità alle disposizioni del
regolamento (UE) n. 165/2014, i dati devono essere usati
esclusivamente per fornire informazioni pertinenti ad un'auto­
rità di controllo competente per aiutare gli agenti a decidere
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 549
quali veicoli fermare per ispezionarli fisicamente e devono
essere successivamente distrutti in conformità all'articolo 9
del regolamento (UE) n. 165/2014.
5.3 Parametri dell'interfaccia fisica DSRC per la comunicazione remota
5.3.1 Vincoli relativi alla posizione
DSC_27 L'interrogazione remota dei veicoli tramite un'interfaccia
DSRC 5,8 GHz non va usata nel raggio di 200 metri da un
carroponte DSRC 5,8 GHz operativo.
5.3.2 Parametri di downlink e uplink
DSC_28 Le apparecchiature usate per il monitoraggio remoto dei ta­
chigrafi devono essere conformi alla norma ERC 70-03 e
funzionare secondo i parametri definiti nelle tabelle 14.1 e
14.2 a seguire.
DSC_29 Inoltre, per garantire la compatibilità ai parametri operativi di
altri sistemi DSRC 5,8 GHz standardizzati, le apparecchiature
usate per il monitoraggio remoto dei tachigrafi devono rispet­
tare i parametri delle norme EN 12253 e EN 13372.
Nello specifico:
Tabella 14.1
Parametri di downlink
Voce n. Parametro Valori Osservazioni
D1 Frequenze di downlink del
vettore
Ci sono quattro alternative
che possono essere usate
da un REDCR:
5,7975 GHz
5,8025 GHz
5,8075 GHz
5,8125 GHz
In conformità alla norma ERC 70-
03.
Le frequenze del vettore possono
essere scelte da chi usa il sistema
a lato della strada e non devono
essere note alla DSRC-VU
(In conformità alle norme EN
12253 e EN 13372)
D1a (*) Tolleranza del vettore Fre­
quenze
entro ± 5 ppm (In conformità alla norma EN
12253)
D2 (*) Maschera di spettro del tra­
smettitore RSU (REDCR)
In conformità alla norma
ERC 70-03.
Il REDCR deve essere con­
forme alla classe B,C come
definita in EN 12253
Nessun'altra prescrizione
specifica nel quadro del
presente allegato
Parametro usato per controllare l'in­
terferenza tra interrogatori in pros­
simità (come definiti in EN 12253
e EN 13372)
D3 Intervallo minimo della fre­
quenza dell'OBU (DSRC-
VU)
5,795 — 5,815 GHz (In conformità alla norma EN
12253)
D4 (*) E.I.R.P. massimo In conformità alla norma
ERC 70-03 (senza licenza)
e alle norme nazionali
Massimo + 33 dBm
(In conformità alla norma EN
12253)
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 550
Voce n. Parametro Valori Osservazioni
D4a Maschera angolare del­
l'E.I.R.P.
Secondo le specifiche di­
chiarate e pubblicate del
progettista dell'interrogatore
(In conformità alla norma EN
12253)
D5 Polarizzazione Circolare antioraria (In conformità alla norma EN
12253)
D5a Polarizzazione incrociata XPD:
Sull'asse di puntamento:
(REDCR) RSU t ≥ 15 dB
(DSRC-VU) OBU r ≥ 10
dB
Nella zona
-3 dB: (REDCR) RSU t ≥
10 dB
(DSRC-VU) OBU r ≥ 6 dB
(In conformità alla norma EN
12253)
D6 (*) Modulazione Modulazione a due livelli
dell'ampiezza.
(In conformità alla norma EN
12253)
D6a (*) Indice di modulazione 0,5 … 0,9 (In conformità alla norma EN
12253)
D6b Diagramma ad occhio ≥ 90 % (tempo) / ≥ 85 %
(ampiezza)
D7 (*) Codifica dei dati FM0
Il bit «1» ha transizioni solo
all'inizio e alla fine dell'in­
tervallo di bit. Il bit «0» ha
un'ulteriore transizione al
centro dell'intervallo di bit
rispetto al bit «1»
(In conformità alla norma EN
12253)
D8 (*) Velocità di trasmissione 500 kBit/s (In conformità alla norma EN
12253)
D8a Tolleranza del Bit Clock Meglio di ± 100 ppm (In conformità alla norma EN
12253)
D9 (*) Tasso d'errore di bit
(B.E.R.) per la comunica­
zione
≤ 10 – 6 quando la potenza
incidente all'OBU (DSRC-
VU) rientra nell'intervallo
[da D11a a D11b].
(In conformità alla norma EN
12253)
D10 Wake-up trigger (segnale di
riattivazione) per l'OBU
(DSRC-VU)
L'OBU (DSRC-VU) si deve
svegliare al ricevimento di
un frame con 11 o più ot­
tetti (incluso il preambolo)
Non è necessaria nessuna sequenza
di riattivazione speciale
La DSRC-VU può svegliarsi al ri­
cevimento di un frame con meno di
11 ottetti
(In conformità alla norma EN
12253)
D10a Tempo di inizio massimo ≤ 5 ms (In conformità alla norma EN
12253)
D11 Zona di comunicazione Regione spaziale entro la
quale si ottiene un B.E.R.
secondo D9a
(In conformità alla norma EN
12253)
D11a (*) Limite di potenza per la co­
municazione (superiore)
-24dBm (In conformità alla norma EN
12253)
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 551
Voce n. Parametro Valori Osservazioni
D11b (*) Limite di potenza per la co­
municazione (inferiore)
Potenza incidente:
–43 dBm (asse di punta­
mento)
– 41 dBm [tra – 45° e +
45°, corrispondente al piano
parallelo alla superficie stra­
dale quando la DSRC-VU è
successivamente installata
sul veicolo (azimut)]
(In conformità alla norma EN
12253)
Prescrizione estesa per gli angoli
orizzontali fino a ± 45°, in virtù
dei casi d'impiego definiti nel pre­
sente allegato
D12 (*) Livello della potenza di in­
terruzione della (DSRC-
VU)
– 60 dBm (In conformità alla norma EN
12253)
D13 Preambolo Il preambolo è obbligatorio (In conformità alla norma EN
12253)
D13a Lunghezza e configurazione
del preambolo
16 bit ± 1 bit di FM0 codi­
ficato «1» bit
(In conformità alla norma EN
12253)
D13b Forma dell'onda del pream­
bolo
Una sequenza alternata di
livello basso e livello alto
con una durata dell'impulso
di 2 μs
La tolleranza è data da D8a
(In conformità alla norma EN
12253)
D13c Trailing bits (bit più a de­
stra)
L'RSU (REDCR) può tra­
smettere un massimo di 8
bit dopo l'indicatore di fine.
Un OBU (DSRC-VU) non
deve tenere in considera­
zione questi bit aggiuntivi
(In conformità alla norma EN
12253)
(*) I parametri di downlink devono superare le prove di conformità per i parametri specificate nella norma EN 300 674-1
Tabella 14.2
Parametri di uplink
Voce n. Parametro Valori Osservazioni
U1 (*) Frequenze del sottoportante Un OBU (DSRC-VU) deve
supportare 1,5 MHz e 2,0
MHz
Un RSU (REDCR) deve
supportare 1,5 MHz o 2,0
MHz o entrambi. U1-0: 1,5
MHz U1-1: 2,0 MHz
Scelta della frequenza del sottopor­
tante
(1,5 MHz o 2,0 MHz) secondo il
profilo EN 13372 scelto
U1a (*) Tolleranza delle frequenze
del sottoportante
Entro ± 0,1 % (In conformità alla norma EN
12253)
U1b Uso di bande laterali Stessi dati su entrambi i lati (In conformità alla norma EN
12253)
U2 (*) Maschera di spettro del tra­
smettitore OBU (DSRC-
VU)
Secondo la norma EN
12253
1) Potenza fuori banda:
cfr. ETSI EN 300674-1
(In conformità alla norma EN
12253)
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 552
Voce n. Parametro Valori Osservazioni
2) Potenza in banda:
[U4a] dBm in 500 kHz
3) Emissione in qualsiasi
altro canale uplink:
U2(3)-1 = – 35 dBm in
500 kHz
U4a (*) E.I.R.P massimo con banda
laterale unica (asse di pun­
tamento)
Due opzioni:
U4a-0: -14 dBm
U4a-1: -21 dBm
Secondo le specifiche dichiarate e
pubblicate del progettista delle ap­
parecchiature
U4b (*) E.I.R.P massimo con banda
laterale unica (35°)
Due opzioni:
— Non applicabile
— – 17dBm
Secondo le specifiche dichiarate e
pubblicate del progettista delle ap­
parecchiature
U5 Polarizzazione Circolare antioraria (In conformità alla norma EN
12253)
U5a Polarizzazione incrociata XPD:
Sull'asse di puntamento:
(REDCR) RSU r ≥ 15 dB
(DSRC-VU) OBU t ≥ 15
dB
In – 3 dB: (REDCR) RSU r
≥ 10 dB
(DSRC-VU) OBU t ≥ 6 dB
(In conformità alla norma EN
12253)
U6 Modulazione del sottopor­
tante
2-PSK
Dati codificati sincronizzati
con il sottoportante: le tran­
sizioni dei dati codificati
coincidono con le transi­
zioni del sottoportante.
(In conformità alla norma EN
12253)
U6b Ciclo di lavoro Ciclo di lavoro:
50 % ± α, α ≤ 5 %
(In conformità alla norma EN
12253)
U6c Modulazione sul vettore Moltiplicazione del sotto­
portante modulato per il
vettore
(In conformità alla norma EN
12253)
U7 (*) Codifica dei dati NRZI (nessuna transizione
all'inizio del bit «1», transi­
zione all'inizio del bit «0»,
nessuna transizione all'in­
terno del bit)
(In conformità alla norma EN
12253)
U8 (*) Velocità di trasmissione 250 kbit/s (In conformità alla norma EN
12253)
U8a Tolleranza del Bit Clock Entro ± 1 000 ppm (In conformità alla norma EN
12253)
U9 Tasso d'errore di bit
(B.E.R.) per la comunica­
zione
≤10 – 6 (In conformità alla norma EN
12253)
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 553
Voce n. Parametro Valori Osservazioni
U11 Zona di comunicazione La regione spaziale in cui è
situata la DSRC-VU in
modo tale che le sue tra­
smissioni siano ricevute dal
REDCR con un B.E.R. in­
feriore a quello dato in U9a
(In conformità alla norma EN
12253)
U12a (*) Guadagno di conversione
(limite inferiore)
1 dB per ciascuna banda la­
terale Ampiezza dell'angolo:
circolarmente simmetrica tra
l'asse di puntamento e ± 35°
e
tra – 45° e + 45°, corri­
spondente al piano parallelo
alla superficie stradale
quando la DSRC-VU è suc­
cessivamente installata sul
veicolo (azimut)
Ampiezza maggiore del valore spe­
cificato per gli angoli orizzontali
fino a ± 45°, in virtù dei casi d'im­
piego definiti nel presente allegato
U12b (*) Guadagno di conversione
(limite superiore)
10 dB per ciascuna banda
laterale
Ampiezza minore del valore speci­
ficato per ciascuna banda laterale
entro un cono circolare attorno ad
un asse di puntamento con un di
angolo di apertura di ± 45°
U13 Preambolo Il preambolo è obbligatorio (In conformità alla norma EN
12253)
U13a Preambolo
Lunghezza e configurazione
Da 32 a 36 μs modulati
solo con il sottoportante,
poi 8 bit di bit «0» codifi­
cati NRZI
(In conformità alla norma EN
12253)
U13b Trailing bits (bit più a de­
stra)
La DSRC-VU può trasmet­
tere un massimo di 8 bit
dopo l'indicatore di fine
Un RSU (REDCR) non
deve tenere in considera­
zione questi bit aggiuntivi
(In conformità alla norma EN
12253)
(*) I parametri di uplink devono superare le prove di conformità per i parametri specificate nella norma EN 300 674-1
5.3.3 Progettazione dell'antenna
5.3.3.1 Antenna del REDCR
DSC_30 La progettazione dell'antenna del REDCR è una questione di
design commerciale. L'antenna deve funzionare entro i limiti
di cui al paragrafo 5.3.2, che sono adattati per ottimizzare le
prestazioni di lettura del DSRC-REDCR per la finalità speci­
fica e alle situazioni di lettura per cui il REDCR è stato
progettato per funzionare.
5.3.3.2 Antenna della VU
DSC_31 La progettazione dell'antenna della DSRC-VU è una questione
di design commerciale. L'antenna deve funzionare entro i
limiti di cui al paragrafo 5.3.2, che sono adattati per ottimiz­
zare le prestazioni di lettura del DSRC-REDCR per la finalità
specifica e alle situazioni di lettura per cui il REDCR è stato
progettato per funzionare.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 554
DSC_32 L'antenna della VU deve essere fissata sul o in prossimità del
parabrezza del veicolo, come specificato al precedente
paragrafo 5.1.
DSC_33 In un ambiente di prova in un'officina (cfr. il paragrafo 6.3),
un'antenna della DSRC-VU, fissata in conformità al prece­
dente paragrafo 5.1, deve collegarsi correttamente con una
comunicazione standard di prova e deve fornire correttamente
una transazione RTM, come definita nella presente appendice,
a una distanza tra 2 e 10 metri, per oltre il 99 % del tempo,
facendo la media su oltre 1 000 interrogazioni di lettura.
5.4 Requisiti del protocollo DSRC per l'RTM
5.4.1 Panoramica
DSC_34 Il protocollo di transazione per scaricare i dati tramite il col­
legamento all'interfaccia DSRC 5,8 GHz deve essere con­
forme alle fasi descritte di seguito. La presente
sezione descrive un flusso di transazioni in condizioni ideali,
senza ritrasmissioni o interruzioni della comunicazione.
NOTA La finalità della fase di inizializzazione (Fase 1) con­
siste nello stabilire una comunicazione tra il REDCR e le
DSRC-VU che sono entrate nella zona di transazione (ma­
ster-slave) DSRC 5,8 GHz, ma che non hanno ancora stabilito
una comunicazione con il REDCR, e nell'informarne i pro­
cessi applicativi.
— Fase 1 Inizializzazione. Il REDCR invia un frame conte­
nente una «tabella di servizio del segnale» (BST), che
include gli identificativi dell'applicazione (AID) nel­
l'elenco dei servizi che supporta. Nell'applicazione
RTM, si tratterà semplicemente del servizio con il valore
AID = 2 (Freight&Fleet = carico e parco veicoli). La
DSRC-VU valuta la BST ricevuta e deve rispondere (vedi
oltre) con l'elenco delle applicazioni supportate nel domi­
nio Freight&Fleet o, se non è supportata nessuna appli­
cazione, non deve rispondere. Se il REDCR non offre
AID = 2, la DSRC-VU non deve rispondergli.
— Fase 2 La DSRC-VU invia un frame contenente una ri­
chiesta di allocazione di finestra privata.
— Fase 3 Il REDCR invia un frame contenente un'alloca­
zione di finestra privata.
— Fase 4 La DSRC-VU usa la finestra privata allocata per
inviare un frame contenente la sua tabella di servizio del
veicolo (VST). Questa VST comprende un elenco di tutte
le diverse istanziazioni delle applicazioni che questa
DSRC-VU supporta nel quadro di AID = 2. Le diverse
istanziazioni devono essere identificate per mezzo di EID
generati univocamente, ciascuno associato ad un valore
del parametro «segnale contestuale dell'applicazione» in­
dicante l'applicazione e la norma supportate.
— Fase 5 A questo punto il REDCR analizza la VST offerta
e termina la connessione (RELEASE), perché non è inte­
ressato a nulla di ciò che la VST ha da offrire (vale a dire
che sta ricevendo una VST da una DSRC-VU che non
supporta la transazione RTM) oppure, se riceve una VST
appropriata, avvia un'istanziazione dell'applicazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 555
— Fase 6 Per fare ciò, il REDCR deve inviare un frame
contenente un comando per recuperare i dati RTM, iden­
tificando l'istanziazione dell'applicazione RTM specifi­
cando l'identificativo corrispondente (come specificato
dalla DSRC-VU nella VST), e deve allocare una finestra
privata.
— Fase 7 La DSRC-VU usa la finestra privata appena allo­
cata per inviare un frame contenente l'identificativo cui si
rivolge, corrispondente all'istanziazione dell'applicazione
RTM come fornita nella VST, seguito dall'attributo
RtmData (elemento del payload + elemento di sicurezza).
— Fase 8 Se sono richiesti più servizi, il valore «n» è so­
stituito dal numero di riferimento del servizio successivo
e il processo è ripetuto.
— Fase 9 Il REDCR conferma la ricezione dei dati inviando
un frame contenente un comando RELEASE alla DSRC-
VU per concludere la sessione OPPURE, se non è riuscito
a convalidare una ricezione corretta dell'LDPU, torna alla
fase 6.
Cfr. la figura 14.6 per una raffigurazione del protocollo di
transazione.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 556
Figura 14.6
Fasi del processo RTM tramite DSRC 5,8 GHz
5.4.2 Comandi
DSC_35 I seguenti comandi sono le uniche funzioni usate in una fase
di transazione RTM
— INITIALISATION.request: comando inviato dal
REDCR sotto forma di una trasmissione con definizione
delle applicazioni supportate dal REDCR.
— INITIALISATION.response: risposta da parte della
DSRC-VU che conferma la connessione e che contiene
un elenco di istanze applicative supportate con caratteri­
stiche e informazioni su come gestirle (EID).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 557
— GET.request: comando, inviato dal REDCR alla DSRC-
VU, che specifica l'istanziazione dell'applicazione da con­
siderare per mezzo di un EID definito, come ricevuto
nella VST, e dà istruzioni alla DSRC-VU di inviare gli
attributi scelti con i dati. L'obiettivo del comando GET è
che il REDCR ottenga i dati dalla DSRC-VU.
— GET.response: risposta dalla DSRC-VU che contiene i
dati richiesti.
— ACTION.request ECHO: comando che dà istruzioni alla
DSRC-VU di rimandare dati al REDCR. L'obiettivo del
comando ECHO è di permettere alle officine o ai labora­
tori di prova per il rilascio delle omologazioni di verifi­
care che il collegamento DSRC funzioni senza bisogno di
accedere alle credenziali di sicurezza.
— ACTION.response ECHO: una risposta da parte della
DSRC-VU al comando ECHO.
— EVENT_REPORT.request RELEASE: un comando che
informa la DSRC-VU che la transazione è conclusa.
L'obiettivo del comando RELEASE è concludere la ses­
sione con la DSRC-VU. Al ricevimento del RELEASE, la
DSRC-VU non deve rispondere a nessun'altra interroga­
zione nel corso della connessione corrente. Si noti che
secondo la norma EN 12834, una DSRC-VU non si col­
legherà due volte allo stesso interrogatore, a meno che
non si sia trovata al di fuori della zona di comunicazione
per 255 secondi o che l'ID del segnale dell'interrogatore
non sia cambiato.
5.4.3 Sequenza di comandi di interrogazione
DSC_36 Dal punto di vista della sequenza di comandi e risposte, la
transazione è descritta come segue:
Sequenza Mittente Destinatario Descrizione Azione
1 REDCR > DSRC-VU Inizializzazione della co­
municazione collegamento
— richiesta
Il REDCR trasmette la BST
2 DSRC-VU > REDCR Inizializzazione della comu­
nicazione collegamento —
risposta
Se la BST supporta AID = 2
allora la DSRC-VU richiede
una finestra privata
3 REDCR > DSRC-VU Alloca una finestra privata Invia un frame contenente
l'allocazione della finestra pri­
vata
4 DSRC-VU > REDCR Invia la VST Invia un frame comprendente
la VST
5 REDCR > DSRC-VU Invia GET.request per i
dati nell'attributo per l'EID
specifico
6 DSRC-VU > REDCR Invia GET.response con
l'attributo richiesto per
l'EID specifico
Invia l'attributo (dati RTM,
dati OWS...) con i dati per
l'EID specifico
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 558
Sequenza Mittente Destinatario Descrizione Azione
▼M1
7 REDCR > DSRC-VU Invia GET.request per i
dati di attributo diverso
(se del caso)
▼B
8 DSRC-VU > REDCR Invia GET.response con
l'attributo richiesto
Invia l'attributo con i dati per
l'EID specifico
9 REDCR > DSRC-VU Conferma la ricezione cor­
retta dei dati
Invia il comando RELEASE
che chiude la transazione
10 DSRC-VU Chiude la transazione
Un esempio della sequenza e del contenuto della transazione
dei frame scambiati è riportato ai paragrafi 5.4.7 e 5.4.8.
5.4.4 Strutture dei dati
DSC_37 La struttura semantica dei dati trasmessi tramite l'interfaccia
DSRC 5,8 GHz deve essere coerente con quanto descritto
nella presente appendice. Il modo in cui questi dati sono
strutturati è specificato nella presente clausola.
DSC_38 Il payload (dati RTM) consiste nella concatenazione dei
1. dati EncryptedTachographPayload, che sono la cifratura
del TachographPayload definito in ASN. 1 nel
paragrafo 5.4.5. Il metodo di cifratura è descritto nell'ap­
pendice 11.
2. DSRCSecurityData, specificati nell'appendice 11.
DSC_39 I dati RTM sono considerati come RTM attributo = 1 e sono
trasferiti nel contenitore RTM = 10.
DSC_40 Il segnale contestuale RTM deve identificare la parte suppor­
tata della norma nella serie di norme TARV (RTM corri­
sponde alla parte 9)
La definizione del modulo ASN.1 per i dati DSRC all'interno
dell'applicazione RTM è la seguente:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 559
► (1) (2) M1
► (3) M3
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 560
5.4.5 Elementi di RtmData, azioni eseguite e definizioni
DSC_41 I valori dei dati che la VU deve calcolare e usare per aggior­
nare i dati sicuri nella DSRC-VU devono essere calcolati se­
condo le regole definite nella tabella 14.3.
▼M3
Tabella 14.3
Elementi di RtmData, azioni eseguite e definizioni
1)
Elemento di dati RTM
2)
Azione eseguita dalla VU
3)
Definizione di ASN.1 dei dati
RTM1
Targa del
veicolo
La VU deve impostare il va­
lore dell’elemento di dati
RTM1 tp15638VehicleRegi­
strationPlate dal valore regi­
strato del tipo di dati
VehicleRegistrationIdentifica­
tion come definito nell’ap­
pendice 1 VehicleRegistratio­
nIdentification
Targa del veicolo
espressa come stringa di
caratteri
tp15638VehicleRegistration­
Plate LPN,
–Targa del veicolo con strut­
tura dei dati basata sulla
norma ISO 14906, ma con la
seguente limitazione per l’ap­
plicazione RTM:
la SEQUENZA inizia con il
codice paese, seguito da un
indicatore alfabetico, seguito
dal numero di targa stesso,
che è sempre costituito da 14
ottetti (riempiti con zeri) af­
finché la lunghezza del tipo
LPN sia sempre di 17 ottetti
(nessuna determinante di lun­
ghezza necessaria), 14 dei
quali costituiscono il numero
di targa «effettivo».
RTM2
Superamento della velo­
cità
La VU deve generare un va­
lore booleano
per l’elemento di dati RTM2
tp15638SpeedingEvent.
Il valore tp15638SpeedingE­
vent
deve essere calcolato dalla
VU in base alle anomalie di
tipo «Superamento della ve­
locità» registrate nella VU
negli ultimi 10 giorni, come
definito nell’allegato IC.
1 (VERO): se la più re­
cente anomalia di tipo
«Superamento della ve­
locità» si è conclusa en­
tro gli ultimi 10 giorni o
è ancora in corso;
0 (FALSO): in tutti gli
altri casi.
tp15638SpeedingEvent BOO­
LEAN,
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 561
1)
Elemento di dati RTM
2)
Azione eseguita dalla VU
3)
Definizione di ASN.1 dei dati
RTM3
Guida in assenza
di una carta valida
La VU deve generare un va­
lore booleano
per l’elemento di dati RTM3
tp15638DrivingWithoutVa­
lidCard.
La VU deve assegnare un
valore VERO alla variabile
tp15638DrivingWithoutVa­
lidCard se negli ultimi 10
giorni è stata registrata nella
VU almeno un’anomalia di
tipo «Guida in assenza di una
carta adeguata», come defi­
nita nell’allegato IC.
1 (VERO): se la più re­
cente anomalia di tipo
«Guida in assenza di una
carta adeguata» si è
conclusa entro gli ultimi
10 giorni o è ancora in
corso;
0 (FALSO): in tutti gli
altri casi.
tp15638DrivingWithoutValid­
Card
BOOLEAN,
RTM4
Carta del conducente
valida
La VU deve generare un va­
lore booleano per l’elemento
di dati RTM4
tp15638DriverCard sulla base
della carta del conducente
valida inserita nella sede
(slot) del conducente.
1 (VERO): se nella sede
(slot) del conducente
della VU non è presente
una carta del conducente
valida;
0 (FALSO): se nella
sede (slot) del condu­
cente della VU è pre­
sente una carta del con­
ducente valida.
tp15638DriverCard BOO­
LEAN,
RTM5
Inserimento della
carta durante la guida
La VU deve generare un va­
lore booleano per l’elemento
di dati RTM5 tp15638Car­
dInsertion.
La VU deve assegnare un
valore VERO alla variabile
tp15638CardInsertion se ne­
gli ultimi 10 giorni è stata
registrata nella VU almeno
un’anomalia di tipo «Inseri­
mento carta durante la
guida», come definita
nell’allegato IC.
1 (VERO): se l’ultima
anomalia di tipo «Inseri­
mento carta durante la
guida» si è verificata
negli ultimi 10 giorni;
0 (FALSO): in tutti gli
altri casi.
tp15638CardInsertion BOO­
LEAN,
RTM6
Errore dati di marcia
La VU deve generare un va­
lore booleano
per l’elemento di dati RTM6.
La VU deve assegnare un
valore VERO alla variabile
tp15638MotionDataError se
negli ultimi 10 giorni è stata
registrata nella VU almeno
un’anomalia di tipo «Errore
dati di marcia», come definita
nell’allegato IC.
1 (VERO): se la più re­
cente anomalia di tipo
«Errore dati di marcia»
si è conclusa entro gli
ultimi 10 giorni o è an­
cora in corso;
0 (FALSO): in tutti gli
altri casi.
tp15638MotionDataError
BOOLEAN,
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 562
1)
Elemento di dati RTM
2)
Azione eseguita dalla VU
3)
Definizione di ASN.1 dei dati
RTM7
Dati contrastanti sul
movimento del
veicolo
La VU deve generare un va­
lore booleano
per l’elemento di dati RTM7.
La VU deve assegnare un
valore VERO alla variabile
tp15638VehicleMotionCon­
flict se negli ultimi 10 giorni
è stata registrata nella VU
almeno un’anomalia di tipo
«Dati contrastanti sul movi­
mento del veicolo».
1 (VERO): se la più re­
cente anomalia di tipo
«Dati contrastanti sul
movimento del veicolo»
si è conclusa entro gli
ultimi 10 giorni o è an­
cora in corso;
0 (FALSO): in tutti gli
altri casi.
tp15638VehicleMotionConflict
BOOLEAN,
RTM8
Carta del secondo con­
ducente
La VU deve generare un va­
lore booleano
per l’elemento di dati RTM8
sulla base dell’allegato IC
(«Dati relativi all’attività del
conducente», EQUIPAGGIO
e SECONDO CONDU­
CENTE).
Se è presente una carta del
secondo conducente valida, la
VU deve impostare il valore
di RTM8 su VERO.
1 (VERO): se nella VU
è presente una carta del
secondo conducente va­
lida.
2 (FALSO): se nella VU
non è presente una carta
del secondo conducente
valida.
tp156382ndDriverCard BOO­
LEAN,
RTM9
Attività in corso
La VU deve generare un va­
lore booleano
per l’elemento di dati RTM9.
Se l’attività in corso è regi­
strata nella VU come attività
diversa da GUIDA, come
definita nell’allegato IC, la
VU deve impostare il valore
di RTM9 su VERO
1 (VERO): altra attività
selezionata;
0 (FALSO): attività
«guida» selezionata.
tp15638CurrentActivityDri­
ving
BOOLEAN
RTM10
Chiusura ultima sessione
La VU deve generare un va­
lore booleano per l’elemento
di dati RTM10.
Se l’ultima sessione della
carta non si è chiusa corret­
tamente, come definito
nell’allegato IC, la VU deve
impostare il valore di RTM10
su VERO.
1 (VERO): almeno una
delle carte inserite ha
attivato un’anomalia di
tipo «Chiusura errata ul­
tima sessione della
carta»;
0 (FALSO): nessuna
delle carte inserite ha
attivato un’anomalia di
tipo «Chiusura errata ul­
tima sessione della
carta».
tp15638LastSessionClosed
BOOLEAN
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 563
1)
Elemento di dati RTM
2)
Azione eseguita dalla VU
3)
Definizione di ASN.1 dei dati
RTM11
Interruzione dell’alimen­
tazione
di energia
La VU deve generare un va­
lore intero
per l’elemento di dati
RTM11.
La VU deve attribuire un
valore alla variabile
tp15638PowerSupplyInter­
ruption pari al numero di
anomalie di tipo «Interru­
zione dell’alimentazione di
energia», come definita
nell’allegato IC, memorizzate
nella VU negli ultimi 10
giorni.
Se negli ultimi 10 giorni non
è stata registrata nella VU
nessuna anomalia di tipo
«Interruzione dell’alimenta­
zione di energia», la VU
deve impostare il valore di
RTM11 su 0.
Numero di anomalie di
tipo «Interruzione
dell’alimentazione di
energia» registrate negli
ultimi 10 giorni.
tp15638PowerSupplyInterrup­
tion
INTEGER (0..127),
RTM12
Guasto del sensore
La VU deve generare un va­
lore intero per l’elemento di
dati RTM12.
La VU deve assegnare alla
variabile sensorFault un va­
lore di:
— 1 se è stata registrata ne­
gli ultimi 10 giorni o è
ancora in corso un’ano­
malia di tipo «35»H
«Guasto del sensore»;
— 2 se si è conclusa negli
ultimi 10 giorni o è an­
cora in corso un’anoma­
lia di tipo
«Guasto del ricevitore
GNSS» (interno o
esterno con i valori enum
«36»H o «37»H);
— 3 se si è conclusa negli
ultimi 10 giorni o è an­
cora in corso un’anoma­
lia di tipo «0E»H «Er­
rore di comunicazione
con il dispositivo GNSS
esterno»;
— 4 se si sono conclusi ne­
gli ultimi 10 giorni o
sono ancora in corso sia
un «Guasto del sensore»
sia un «Guasto del rice­
vitore GNSS»;
— 5 se si sono conclusi ne­
gli ultimi 10 giorni o
sono ancora in corso sia
un «Guasto del sensore»
sia anomalie di tipo
«Errore di comunica­
zione con il dispositivo
GNSS esterno»;
– Guasto del sensore, un
ottetto secondo il dizio­
nario di dati
tp15638SensorFault INTEGER
(0..255),
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 564
1)
Elemento di dati RTM
2)
Azione eseguita dalla VU
3)
Definizione di ASN.1 dei dati
— 6 se si sono concluse ne­
gli ultimi 10 giorni o
sono ancora in corso sia
un «Guasto del ricevitore
GNSS» sia anomalie di
tipo «Errore di comuni­
cazione con il dispositivo
GNSS esterno»;
— 7 se si sono conclusi ne­
gli ultimi 10 giorni o
sono ancora in corso tutti
e tre i guasti del sensore.
Se nessuna anomalia si è
conclusa negli ultimi 10
giorni o è ancora in corso, la
VU deve impostare il valore
di RTM12 su 0.
RTM13
Regolazione dell’ora
La VU deve generare un va­
lore intero (timeReal dall’ap­
pendice 1) per l’elemento di
dati RTM13 sulla base della
presenza di dati relativi alla
regolazione dell’ora, come
definita nell’allegato IC.
La VU deve impostare il va­
lore dell’RTM13 sull’ora in
cui si è verificata l’ultima
anomalia di tipo «Regola­
zione dell’ora».
Se nella VU non è presente
nessuna anomalia di tipo
«Regolazione dell’ora», come
definita nell’allegato IC, la
VU deve impostare il valore
di RTM13 su 0.
oldTimeValue della più
recente regolazione
dell’ora
tp15638TimeAdjustment
INTEGER(0..4294967295),
RTM14
Tentata violazione della
sicurezza
La VU deve generare un va­
lore intero (timeReal dall’ap­
pendice 1) per l’elemento di
dati RTM14 sulla base della
presenza di un’anomalia di
tipo «Tentata violazione della
sicurezza», come definita
nell’allegato IC.
La VU deve impostare il va­
lore temporale dell’ultima
anomalia del tipo «Tentata
violazione della sicurezza»
registrata dalla VU.
Se nella VU non è presente
nessuna anomalia di tipo
«Tentata violazione della si­
curezza», come definita
nell’allegato IC, la VU deve
impostare il valore di RTM14
su 0.
Ora di inizio della più
recente tentata violazione
della sicurezza
memorizzata.
tp15638LatestBreachAttempt
INTEGER(0..4294967295),
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 565
1)
Elemento di dati RTM
2)
Azione eseguita dalla VU
3)
Definizione di ASN.1 dei dati
RTM15
Ultima taratura
La VU deve generare un va­
lore intero (timeReal dall’ap­
pendice 1) per l’elemento di
dati RTM15 sulla base della
presenza di dati relativi
all’ultima taratura, come de­
finita nell’allegato IC e
nell’appendice 1.
La VU deve impostare il va­
lore
di RTM15 sull’oldTimeValue
della registrazione della più
recente taratura.
Se non è stata effettuata nes­
suna taratura, la VU deve
impostare il valore di RTM15
su 0.
oldTimeValue della re­
gistrazione della più re­
cente taratura
tp15638LastCalibrationData
INTEGER(0..4294967295),
RTM16
Taratura precedente
La VU deve generare un va­
lore intero (timeReal dall’ap­
pendice 1) per l’elemento di
dati RTM16 sulla base della
registrazione della penultima
taratura.
La VU deve impostare il va­
lore
di RTM16 sull’oldTimeValue
della registrazione della pe­
nultima taratura.
Se non è stata in precedenza
effettuata nessuna taratura, la
VU deve impostare il valore
di RTM16 su 0.
oldTimeValue della re­
gistrazione della penul­
tima taratura
tp15638PrevCalibrationData
INTEGER(0..4294967295),
RTM17
Data del collegamento
del
tachigrafo
La VU deve generare un va­
lore intero (timeReal dall’ap­
pendice 1) per l’elemento di
dati RTM17.
La VU deve impostare il va­
lore di RTM17 sulla data
della prima taratura della VU
nel veicolo in cui è montata.
La VU deve estrarre questo
dato da VuCalibrationData
(appendice 1) da vuCalibra­
tionRecords con Calibration­
Purpose pari a «03»H.
Se non è stata in precedenza
effettuata nessuna taratura, la
VU deve impostare il valore
di RTM17 su 0.
Data della prima taratura
della VU nel veicolo in
cui è montata.
tp15638DateTachoConnected
INTEGER(0..4294967295),
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 566
1)
Elemento di dati RTM
2)
Azione eseguita dalla VU
3)
Definizione di ASN.1 dei dati
RTM18
Velocità corrente
La VU deve generare un va­
lore intero
per l’elemento di dati
RTM18.
La VU deve impostare il va­
lore di RTM18 sull’ultima
velocità corrente registrata al
momento del più recente ag­
giornamento di RtmData.
Ultima velocità corrente
registrata
tp15638CurrentSpeed INTE­
GER (0..255),
RTM19
Marcatura oraria
La VU deve generare un va­
lore intero per l’elemento di
dati RTM19 (timeReal
dall’appendice 1).
La VU deve impostare il va­
lore di RTM19 sull’ora del
più recente aggiornamento di
RtmData.
Marcatura oraria della
registrazione
TachographPayload cor­
rente
tp15638Timestamp
INTEGER(0..4294967295),
RTM20
Ora in cui si è resa di­
sponibile la più recente
posizione autenticata del
veicolo
La VU deve generare un va­
lore intero (timeReal dall’ap­
pendice 1) per l’elemento di
dati RTM20.
La VU deve impostare il va­
lore di RTM20 sull’ora in cui
il ricevitore GNSS ha reso
disponibile la più recente
posizione autenticata del vei­
colo.
Se il ricevitore GNSS non ha
reso disponibile nessuna po­
sizione autenticata del vei­
colo, la VU deve impostare il
valore di RTM20 su 0.
Marcatura oraria della
più recente posizione
autenticata del veicolo
tp15638LatestAuthenticatedPo­
sition
INTEGER(0..4294967295),
RTM21
Periodo di guida conti­
nuo
La VU deve generare un va­
lore intero per l’elemento di
dati RTM21.
La VU deve impostare il va­
lore di RTM21 sul periodo di
guida continuo in corso del
conducente.
Periodo di guida conti­
nuo del conducente, co­
dificato come valore in­
tero.
Lunghezza: 1 byte
Risoluzione: 2 minuti/bit
No offset
Intervallo di dati: da 0
e 250
Un valore di 250 indica
che il periodo di guida
continuo del conducente
è pari o superiore a 500
minuti.
I valori da 251 a 254
non sono utilizzati.
Il valore 255 indica che
l’informazione non è
disponibile.
tp15638ContinuousDrivin­
gTime INTEGER(0..255),
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 567
1)
Elemento di dati RTM
2)
Azione eseguita dalla VU
3)
Definizione di ASN.1 dei dati
RTM22
Periodo di guida giorna­
liero più lungo per il
turno RTM in corso e
per quello precedente,
calcolato in conformità
all’addendum all’appen­
dice 14
La VU deve generare un va­
lore intero per l’elemento di
dati RTM22.
La VU deve impostare il va­
lore di RTM22 sul più lungo
dei due periodi di guida
giornalieri del conducente, sia
esso il turno RTM in corso o
quello precedente.
Periodo di guida giorna­
liero del conducente,
codificato come valore
intero.
Lunghezza: 1 byte
Risoluzione: 4 minuti/bit
No offset
Intervallo di dati: da 0
e 250
Un valore di 250 indica
che il periodo di guida
giornaliero del condu­
cente è pari o superiore a
1 000 minuti.
I valori da 251 a 254
non sono utilizzati.
Il valore 255 indica che
l’informazione non è
disponibile.
tp15638DailyDrivingTimeShift
INTEGER(0..255),
RTM23
Periodo di guida giorna­
liero più lungo durante
la settimana in corso,
calcolato in conformità
all’addendum all’appen­
dice 14
La VU deve generare un va­
lore intero per l’elemento di
dati RTM23.
La VU deve impostare il va­
lore di RTM23 sul periodo di
guida giornaliero più lungo
del conducente, sia esso il
turno RTM in corso o qual­
siasi turno RTM completo
che è iniziato o finito nella
settimana in corso.
Periodo di guida giorna­
liero del conducente,
codificato come valore
intero.
Lunghezza: 1 byte
Risoluzione: 4 minuti/bit
No offset
Intervallo di dati: da 0
e 250
Un valore di 250 indica
che il periodo di guida
giornaliero del condu­
cente è pari o superiore a
1 000 minuti.
I valori da 251 a 254
non sono utilizzati.
Il valore 255 indica che
l’informazione non è
disponibile.
tp15638DailyDrivingTime­
Week INTEGER(0..255),
RTM24
Periodo di guida setti­
manale, calcolato con­
formemente all’adden­
dum all’appendice 14
La VU deve generare un va­
lore intero per l’elemento di
dati RTM24.
La VU deve impostare il va­
lore di RTM24 sul periodo di
guida settimanale del
conducente.
Periodo di guida setti­
manale del conducente,
codificato come valore
intero.
Lunghezza: 1 byte
Risoluzione: 20 minuti/
bit
No offset
Intervallo di dati: da 0
e 250
Un valore di 250 indica
che il periodo di guida
settimanale del condu­
cente è pari o superiore a
5 000 minuti.
I valori da 251 a 254
non sono utilizzati.
Il valore 255 indica che
l’informazione non è
disponibile.
tp15638WeeklyDrivingTime
INTEGER(0..255),
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 568
1)
Elemento di dati RTM
2)
Azione eseguita dalla VU
3)
Definizione di ASN.1 dei dati
RTM25
Periodo di guida quindi­
cinale, calcolato confor­
memente all’addendum
all’appendice 14
La VU deve generare un va­
lore intero per l’elemento di
dati RTM25.
La VU deve impostare il va­
lore di RTM25 sul periodo di
guida quindicinale del
conducente.
Periodo di guida quindi­
cinale del conducente,
codificato come valore
intero.
Lunghezza: 1 byte
Risoluzione: 30 minuti/
bit
No offset
Intervallo di dati: da 0
e 250
Un valore di 250 indica
che il periodo di guida
quindicinale del condu­
cente è pari o superiore a
7 500 minuti.
I valori da 251 a 254
non sono utilizzati.
Il valore 255 indica che
l’informazione non è
disponibile.
tp15638FortnightlyDrivin­
gTime INTEGER(0..255),
Nota: RTM22, RTM23, RTM24 e RTM25 devono essere calcolati in conformità
all’Addendum alla presente appendice
▼B
5.4.6 Meccanismo di trasferimento dei dati
DSC_42 Il payload precedentemente definito è richiesto dal REDCR
dopo la fase di inizializzazione ed è successivamente tra­
smesso dalla DSRC-VU nella finestra allocata. Il comando
GET è usato dal REDCR per recuperare i dati.
▼M1
DSC_43 Per tutti gli altri scambi DSRC, i dati devono essere codificati
usando le PER (regole di codifica del pacchetto) SENZA
ALLINEAMENTO, tranne nel caso di
e , che devono
essere codificati usando le OER (regole di codifica all’ottetto)
definite dalla norma ISO/IEC 8825-7, Rec. ITU-T X.696.
▼B
5.4.7 Descrizione dettagliata della transazione DSRC
DSC_44 L'inizializzazione avviene in conformità alle clausole da
DSC_44 a DSC_48 e alle tabelle da 14.4 a 14.9. Nella fase
di inizializzazione, il REDCR inizia ad inviare un frame con­
tenente una BST (tabella di servizio del segnale) secondo le
norme EN 12834 e EN 13372, paragrafi 6.2, 6.3, 6.4 e 7.1
con le impostazioni come specificato nella seguente tabella
14.4.
Tabella 14.4
Inizializzazione — Impostazioni del frame contenente una
BST
Campo Impostazioni
Link Identifier Indirizzo di trasmissione
BeaconId In conformità a EN 12834
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 569
Campo Impostazioni
Ora In conformità a EN 12834
Profilo Nessuna estensione, usare 0
o 1
MandApplications Nessuna estensione, EID as­
sente, parametro assente,
AID = 2 Freight&Fleet
NonMandApplications Assente
ProfileList Nessuna estensione, numero
di profili nell'elenco = 0
Fragmentation header Nessuna frammentazione
Layer 2 settings PDU del comando, comando
UI
La tabella 14.5 a seguire riporta un esempio pratico delle
impostazioni specificate nella tabella 14.4, con un'indicazione
delle codifiche dei bit.
Tabella 14.5
Inizializzazione — Esempio dei contenuti del frame contenente una BST
O
tt
et
to
#

Attributo/Campo Bit nell'ottetto Descrizione
1 FLAG Indicatore di inizio
2 Broadcast ID Indirizzo di trasmissione
3 MAC Control Field PDU del comando
4 LLC Control field Comando UI
5 Intestazione della frammentazione Nessuna frammentazione
6 BST Richiesta di inizializza­
zione
SEQUENCE {
OPTION indicator
BeaconID SEQUENCE {
ManufacturerId INTEGER (0..65535)
Applicazioni NonMand
assenti
Identificativo del fabbri­
cante
7
8
IndividualID INTEGER (0..134217727)
}
ID di 27 bit disponibile
per il fabbricante
9
10
11
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 570
O
tt
et
to
#

Attributo/Campo Bit nell'ottetto Descrizione
12 Time INTEGER (0..4294967295) Tempo reale UNIX 32 bit
13
14
15
16 Profile INTEGER (0..127,...) Nessuna estensione. Pro­
filo esemplificativo 0
17 MandApplications SEQUENCE
(SIZE(0..127,…))
OF {
Nessuna estensione, numero
di mandApplications = 1
18 SEQUENCE {
OPTION indicator EID assente
OPTION indicator Parametro assente
AID DSRCApplicationEntityID } } Nessuna estensione. AID=
2 Freight&Fleet
19 ProfileList SEQUENCE (0..127,…) OF
Profile }
Nessuna estensione, nu­
mero di profili nell'elenco
= 0
20 FCS Sequenza di controllo del
frame
21
22 Flag Indicatore di fine
DSC_45 Quando una DSRC-VU riceve una BST, richiede l'allocazione
di una finestra privata, come specificato nelle norme EN
12795 e EN 13372, paragrafo 7.1.1, senza impostazioni
RTM specifiche. La tabella 14.6 riporta un esempio di codi­
fica dei bit.
Tabella 14.6
Inizializzazione — Contenuto del frame di richiesta di allocazione di finestra privata
O
tt
et
to
#

Attributo/Campo Bit nell'ottetto Descrizione
1 FLAG Indicatore di inizio
2 LID privato Indirizzo del collegamento
della DSRC-VU specifica
3
4
5
6 MAC Control field Richiesta di finestra pri­
vata
7 FCS Sequenza di controllo del
frame
8
9 Flag Indicatore di fine
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 571
DSC_46 Il REDCR allora risponde allocando una finestra privata,
come specificato nelle norme EN 12795 e EN 13372,
paragrafo 7.1.1, senza impostazioni RTM specifiche.
La tabella 14.7 riporta un esempio di codifica dei bit.
Tabella 14.7
Inizializzazione — Contenuto del frame di allocazione di finestra privata
O
tt
et
to
#

Attributo/Campo Bit nell'ottetto Descrizione
1 FLAG Indicatore di inizio
2 LID privato Indirizzo del collegamento
della DSRC-VU specifica
3
4
5
6 MAC Control field Allocazione della finestra
privata
7 FCS Sequenza di controllo del
frame
8
9 Flag Indicatore di fine
DSC_47 Quando riceve l'allocazione della finestra privata, la DSRC-
VU invia la sua VST (tabella di servizio del veicolo) come
definita nelle norme EN 12834 e EN 13372, paragrafi 6.2,
6.3, 6.4 e 7.1, con le impostazioni specificate nella tabella
14.8, usando la finestra di trasmissione allocata.
Tabella 14.8
Inizializzazione — Impostazioni del frame della VST
Campo Impostazioni
LID privato In conformità a EN 12834
Parametri della VST Riempimento=0, allora per ciascuna
applicazione supportata: EID presente,
parametro presente, AID=2, EID
come generato dall'OBU
Parametro Nessuna estensione, contiene il se­
gnale contestuale RTM
ObeConfiguration Il campo opzionale ObeStatus può es­
sere presente, ma non deve essere
usato dal REDCR
Intestazione della frammentazione Nessuna frammentazione
Impostazioni del livello 2 PDU del comando, comando UI
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 572
DSC_48 La DSRC-VU deve supportare l'applicazione «carico e parco
veicoli» identificata dall'identificativo dell'applicazione «2».
Possono essere supportati anche altri identificativi dell'appli­
cazione, che però non devono essere presenti in questa VST,
poiché la BST richiede solo AID=2. Il campo «applicazioni»
contiene un elenco di istanze applicative supportate nella
DSRC-VU. Per ciascuna istanziazione delle applicazioni sup­
portate è dato un riferimento alla norma appropriata, costituito
da un segnale contestuale RTM, che è composto da un IDEN­
TIFICATIVO DELL'OGGETTO, che rappresenta la relativa
norma, la parte (9 per RTM) e eventualmente la versione, più
un EID generato dalla DSRC-VU e associato a tale istanza
applicativa.
La tabella 14.9 riporta un esempio pratico delle impostazioni
specificate nella tabella 14.8, con un'indicazione delle codifi­
che dei bit.
▼M3
Tabella 14.9
Inizializzazione — Esempio di contenuti del frame della VST
O
tt
et
to
#

Attributo/Campo Bit nell’ottetto Descrizione
1 FLAG 0111 1110 Indicatore di inizio
2 LID privato xxxx xxxx Indirizzo del collegamento
della DSRC-VU specifica
3 xxxx xxxx
4 xxxx xxxx
5 xxxx xxxx
6 MAC Control field 1100 0000 PDU del comando
7 LLC Control field 0000 0011 Comando UI
8 Fragmentation header 1xxx x001 Nessuna frammentazione
9 VST
SEQUENCE {
Fill BIT STRING (SIZE(4))
1001 Risposta di inizializza­
zione
0000 Non usato e impostato su
0
10 Profile INTEGER (0..127,...)
Applications SEQUENCE OF {
0000 0000 Nessuna estensione. Pro­
filo esemplificativo 0
Nessuna estensione, 1 ap­
plicazione
11 0000 0001
12 SEQUENCE {
OPTION indicator
OPTION indicator
AID DSRCApplicationEntityID
1 EID presente
1 Parametro presente
00 0010 Nessuna estensione. AID=
2 Freight&Fleet
13 EID Dsrc-EID xxxx xxxx Definito nell’ambito
dell’OBU e che identifica
l’istanza applicativa
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 573
O
tt
et
to
#

Attributo/Campo Bit nell’ottetto Descrizione
14 Parameter Container { 0000 0010 Nessuna estensione, scelta
del contenitore = 02,
stringa di ottetti
15 0000 0110 Nessuna estensione, lun­
ghezza del segnale conte­
stuale Rtm = 6
16 Rtm-ContextMark ::= SEQUENCE {
standardIdentifier
0000 0101 Il primo ottetto è 05H,
che è la sua lunghezza.
I 5 ottetti successivi codi­
ficano l’identificativo
dell’oggetto della norma,
della parte e della ver­
sione supportate.
{ISO (1) Norma (0)
TARV (15638) Parte
9(9) Versione 2 (2)}
17 standardIdentifier 0010 1000
18 1111 1010
19 0001 0110
20 0000 1001
21 0000 0010
22 ObeConfiguration Sequence {
OPTION indicator
0 ObeStatus assente
EquipmentClass INTEGER (0..32767) xxx xxxx Questo campo deve essere
utilizzato per riportare
23 xxxx xxxx le indicazioni del fabbri­
cante sulla versione soft­
ware/hardware dell’inter­
faccia DSRC
24 ManufacturerId INTEGER (0..65535) xxxx xxxx Identificativo del fabbri­
cante per la DSRC-VU,
come descritto nel registro
di cui alla norma ISO
14816
25 xxxx xxxx
26 FCS xxxx xxxx Sequenza di controllo del
frame
27 xxxx xxxx
28 Flag 0111 1110 Indicatore di fine
▼B
DCS_49 Il REDCR legge poi i dati inviando un comando GET con­
forme al comando GET definito nella norma EN 13372, pa­
ragrafi 6.2, 6.3, 6.4, e nella norma EN 12834 con le impo­
stazioni specificate nella tabella 14.10.
Tabella 14.10
Presentazione — Impostazioni del frame di richiesta GET
Campo Impostazioni
Invoker Identifier (IID) Assente
Link Identifier (LID) Indirizzo del collegamento della
DSRC-VU specifica
Chaining N.
Element Identifier (EID) Come specificato nella VST. Nessuna
estensione
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 574
Campo Impostazioni
Access Credentials N.
AttributeIdList Nessuna estensione, 1 attributo, Attri­
buteID = 1 (RtmData)
Frammentazione N.
Layer2 settings PDU del comando, comando ACn in­
terrogato
La tabella 14.11 riporta un esempio di lettura dei dati RTM.
Tabella 14.11
Presentazione — Esempio di frame di richiesta GET
O
tt
et
to
#

Attributo/Campo Bit nell'ottetto Descrizione
1 FLAG Indicatore di inizio
2 LID privato Indirizzo del collegamento
della DSRC-VU specifica
3
4
5
6 MAC Control field PDU del comando
7 LLC Control field Comando ACn interro­
gato, n bit
8 Intestazione della frammentazione Nessuna frammentazione
9 Get.request
SEQUENCE {
Get request
OPTION indicator Credenziali di accesso as­
senti
OPTION indicator IID assente
OPTION indicator AttributeIdList presente
Fill BIT STRING(SIZE(1)) Impostato a 0
10 EID INTEGER(0..127,…) L'EID dell'istanza applica­
tiva RTM, come specifi­
cato nella VST. Nessuna
estensione
11 AttributeIdList SEQUENCE OF {
AttributeId }}
Nessuna estensione, nu­
mero di attributi = 1
12 AttributeId=1, RtmData.
Nessuna estensione
13 FCS Sequenza di controllo del
frame
14
15 Flag Indicatore di fine
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 575
DSC_50 La DSRC-VU, quando riceve la richiesta GET, invia una
riposta GET con i dati richiesti conforme alla risposta GET
definita nella norma EN 13372, paragrafi 6.2, 6.3, 6.4, e nella
norma EN 12834 con le impostazioni come specificato nella
tabella 14.12.
Tabella 14.12
Presentazione — Impostazioni del frame di risposta GET
Campo Impostazioni
Invoker Identifier (IID) Assente
Link Identifier (LID) In conformità a EN 12834
Chaining N.
Element Identifier (EID) Come specificato nella VST
Access Credentials N.
Frammentazione N.
Layer2 settings Risposta PDU, risposta di­
sponibile e comando accet­
tato, comando ACn
La tabella 14.13 riporta un esempio di lettura dei dati RTM.
Tabella 14.13
Presentazione — Esempio di contenuti del frame di risposta
O
tt
et
to
#

Attributo/Campo Bit nell'ottetto Descrizione
1 FLAG Indicatore di inizio
2 LID privato Indirizzo del collegamento
della DSRC-VU specifica
3
4
5
6 MAC Control field Risposta PDU
7 LLC Control field Risposta disponibile, n bit
del comando ACn
8 LLC Status field Risposta disponibile e co­
mando accettato
9 Intestazione della frammentazione Nessuna frammentazione
10 Get.response
SEQUENCE {
Ottieni la risposta
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 576
O
tt
et
to
#

Attributo/Campo Bit nell'ottetto Descrizione
OPTION indicator IID assente
OPTION indicator Elenco degli attributi pre­
sente
OPTION indicator Stato risposta inviata as­
sente
Fill BIT STRING(SIZE(1)) Non utilizzato
11 EID INTEGER(0..127,…) Risposta dall'istanza ap­
plicativa
RTM. Nessuna
estensione,
12 AttributeList SEQUENCE OF { Nessuna estensione, nu­
mero di attributi = 1
13 Attributes SEQUENCE {
AttributeId
Nessuna estensione, Attri­
buteId = 1 (RtmData)
14 AttributeValue CONTAINER { Nessuna estensione, scelta
del contenitore = 10, 10 .
15 RtmData
16
17
… …
n }}}}
n+1 FCS Sequenza di controllo del
frame
n+2
n+3 Flag Indicatore di fine
DSC_51 Il REDCR chiude allora il collegamento inviando un co­
mando EVENT_REPORT, RELEASE conforme alla norma
EN 13372, paragrafi 6.2, 6.3, 6.4, e alla norma EN 12834,
paragrafo 7.3.8, senza impostazioni RTM specifiche. La ta­
bella 14.14 illustra un esempio di codifica dei bit del co­
mando RELEASE.
Tabella 14.14
Chiusura. Contenuto del frame EVENT_REPORT Release
O
tt
et
to
#

Attributo/Campo Bit nell'ottetto Descrizione
1 FLAG Indicatore di inizio
2 LID privato Indirizzo del collegamento
della DSRC-VU specifica
3
4
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 577
O
tt
et
to
#

Attributo/Campo Bit nell'ottetto Descrizione
5
6 MAC Control field Il frame contiene un co­
mando LPDU
7 LLC Control field Comando UI
8 Intestazione della frammentazione Nessuna frammentazione
9 EVENT_REPORT.request
SEQUENCE {
EVENT_REPORT (Re­
lease)
OPTION indicator Credenziali di accesso as­
senti
OPTION indicator Parametro dell'anomalia
assente
OPTION indicator IID assente
Mode BOOLEAN Nessuna risposta attesa
10 EID INTEGER (0..127,…) Nessuna estensione, EID
= 0 (Sistema)
11 EventType INTEGER (0..127,…) } Tipo di anomalia 0 = Re­
lease
12 FCS Sequenza di controllo del
frame
13
14 Flag Indicatore di fine
DSC_52 Non è attesa alcuna risposta da parte della DSRC-VU al co­
mando Release. La comunicazione a questo punto si chiude.
5.4.8 Descrizione della transazione di prova DSRC
DSC_53 Prove complete, comprese verifiche delle procedure per ga­
rantire dati sicuri, devono essere condotte, come definito nel­
l'appendice 11 (Meccanismi comuni di sicurezza), da persone
autorizzate aventi accesso alle procedure di sicurezza, usando
il comando normale GET, come definito sopra.
DSC_54 Le prove di attivazione e le prove di ispezione periodica che
richiedono la decifrazione e la comprensione del contenuto
dei dati decifrati devono essere condotte come specificato
nell'appendice 11 (Meccanismi comuni di sicurezza) e nell'ap­
pendice 9 (Elenco di omologazione delle prove minime ri­
chieste).
La comunicazione DSRC di base può tuttavia essere testata
tramite il comando ECHO. Tali prove possono essere richieste
all'atto dell'attivazione, durante le ispezioni periodiche, dal­
l'autorità di controllo competente o in conformità al
regolamento (UE) n. 165/2014 (cfr. paragrafo 6 a seguire).
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 578
DSC_55 Per effettuare questa prova di comunicazione di base, il
REDCR invia il comando ECHO durante una sessione, vale
a dire dopo che una fase di inizializzazione è stata completata
correttamente. La sequenza di interazione è dunque simile a
quella di un'interrogazione:
— Fase 1 Il REDCR invia una «tabella di servizio del
segnale» (BST), che include gli identificativi
dell'applicazione (AID) nell'elenco dei servizi che sup­
porta. Nelle applicazioni RTM, si tratterà semplicemente
del servizio con il valore AID = 2.
La DSRC-VU valuta la BST ricevuta e laddove identifica
che la BST sta chiedendo Freight&Fleet (AID = 2), la
DSRC-VU deve rispondere. Se il REDCR non offre AID
= 2, la DSRC-VU deve chiudere la transazione con il
REDCR.
— Fase 2 La DSRC-VU invia una richiesta di allocazione di
finestra privata.
— Fase 3 Il REDCR invia un'allocazione di finestra privata.
— Fase 4 La DSRC-VU usa la finestra privata allocata per
inviare la sua tabella di servizio del veicolo (VST). Que­
sta VST comprende un elenco di tutte le diverse istanzia­
zioni delle applicazioni che questa DSRC-VU supporta nel
quadro di AID = 2. Le diverse istanziazioni devono es­
sere identificate per mezzo di EID generati univocamente,
ciascuno associato ad un valore di parametro indicante
l'istanza applicativa supportata.
— Fase 5 A questo punto il REDCR analizza la VST offerta
e termina la connessione (RELEASE), perché non è inte­
ressato a nulla di ciò che la VST ha da offrire (vale a dire
che sta ricevendo una VST da una DSRC-VU che non è
una RTM VU) oppure, se riceve una VST appropriata,
avvia un'istanziazione dell'applicazione.
— Fase 6 Il REDCR invia un comando (ECHO) alla DSRC-
VU specifica e alloca una finestra privata.
— Fase 7 La DSRC-VU usa la finestra privata appena allo­
cata per inviare un frame di risposta ECHO.
Le tabelle a seguire illustrano un esempio pratico di una sessione di
scambio ECHO.
DSC_56 L'inizializzazione avviene in conformità al paragrafo 5.4.7 (da
DSC_44 a DSC_48) e alle tabelle da 14.4 a 14.9.
DSC_57 Il REDCR a questo punto invia un comando ACTION,
ECHO conforme alla norma ISO 14906 contenente 100 ottetti
di dati e senza impostazioni specifiche per l'RTM. La tabella
14.15 illustra il contenuto del frame inviato dal REDCR.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 579
Tabella 14.15
Esempio di frame di richiesta ACTION, ECHO
O
tt
et
to
#

Attributo/Campo Bit nell'ottetto Descrizione
1 FLAG Indicatore di inizio
2 LID privato Indirizzo del collegamento
della DSRC-VU specifica
3
4
5
6 MAC Control field PDU del comando
7 LLC Control field Comando ACn interrogato,
n bit
8 Intestazione della frammentazione Nessuna frammentazione
9 ACTION.request
SEQUENCE {
Richiesta di azione (ECHO)
OPTION indicator Credenziali di accesso as­
senti
OPTION indicator Parametro dell'azione pre­
sente
OPTION indicator IID assente
Mode BOOLEAN Risposta attesa
10 EID INTEGER (0..127,…) Nessuna estensione, EID =
0 (Sistema)
11 ActionType INTEGER (0..127,…) Nessuna estensione, richie­
sta di azione di tipo
ECHO
12 ActionParameter CONTAINER { Nessuna estensione, scelta
del contenitore = 2
13 Nessuna estensione. Lun­
ghezza della stringa =
100 ottetti
14 Dati da ripetere
… …
113 }}
114614 FCS Sequenza di controllo del
frame
115715
116816 Flag Indicatore di fine
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 580
DSC_58 Quando la DSRC-VU riceve la richiesta di ECHO, invia una
risposta ECHO di 100 ottetti di dati riflettendo il comando
ricevuto, in conformità alla norma ISO 14906, senza impo­
stazioni specifiche per l'RTM. La tabella 14.16 illustra un
esempio di codifica del livello di bit.
Tabella 14.16
Esempio di frame di risposta ACTION, ECHO
O
tt
et
to
#

Attributo/Campo Bit nell'ottetto Descrizione
1 FLAG Indicatore di inizio
2 LID privato Indirizzo del collegamento
della VU specifica
3
4
5
6 MAC Control field Risposta PDU
7 LLC Control field n bit del comando ACn
8 LLC status field Risposta disponibile
9 Intestazione della frammentazione Nessuna frammentazione
10 ACTION.response
SEQUENCE {
ACTION.response
(ECHO)
OPTION indicator IID assente
OPTION indicator Parametro di risposta pre­
sente
OPTION indicator Stato risposta inviata as­
sente
Fill BIT STRING (SIZE (1)) Non utilizzato
11 EID INTEGER (0..127,…) Nessuna estensione, EID
= 0 (Sistema)
12 ResponseParameter CONTAINER { Nessuna estensione, scelta
del contenitore = 2
13 Nessuna estensione. Lun­
ghezza della stringa =
100 ottetti
14 Dati ripetuti
… …
113 }}
114 FCS Sequenza di controllo del
frame
115
116 Flag Indicatore di fine
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 581
5.5 Riservato per uso futuro
▼M2
__________
▼B
5.6 Trasferimento di dati tra la DSRC-VU e la VU
5.6.1 Collegamento fisico e interfacce
DSC_66 Il collegamento tra la VU e la DSRC-VU può essere un cavo
fisico o una comunicazione senza fili a corto raggio basata su
Bluetooth v4.0 BLE.
DSC_67 Indipendentemente dalla scelta del collegamento fisico e del­
l'interfaccia, i seguenti requisiti devono essere soddisfatti:
DSC_68 ►M1 a) al fine di consentire l’acquisto di VU, DSCR-VU e
di diversi lotti di DSRC-VU da fornitori diversi, il
collegamento tra la VU e la DSRC-VU non interno
alla VU deve essere un collegamento standard
aperto. La VU deve collegarsi alla DSRC-VU: ◄
i) tramite un cavo fisso di almeno 2 metri, utiliz­
zando un connettore Straight DIN 41612 H11;
un connettore maschio approvato a 11 pin
dalla DSRC-VU e un connettore femmina cor­
rispondente simile, conforme alla norma DIN/
ISO, dalla VU,
ii) tramite Bluetooth a bassa energia (BLE),
iii) tramite un collegamento conforme alla norma
ISO 11898 o SAE J1939;
DSC_69 b) la definizione delle interfacce e del collegamento tra la VU
e la DSRC-VU deve supportare i comandi del protocollo
dell'applicazione definiti al paragrafo 5.6.2 e
DSC_70 c) la VU e la DSRC-VU devono supportare l'operazione di
trasferimento di dati tramite il collegamento in termini di
prestazioni e di alimentazione di energia.
5.6.2 Protocollo dell'applicazione
DSC_71 Il protocollo dell'applicazione tra il dispositivo di comunica­
zione remota della VU e la DSRC-VU è responsabile del
trasferimento periodico dei dati della comunicazione remota
dalla VU alla DSRC.
DSC_72 Si identificano i seguenti comandi principali:
1. Inizializzazione del collegamento di comunicazione -richie­
sta
2. Inizializzazione del collegamento di comunicazione -rispo­
sta
3. Invio dei dati con identificativo dell'applicazione RTM e
payload definiti dai dati RTM
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 582
4. Riconoscimento dei dati
5. Fine del collegamento di comunicazione -richiesta
6. Fine del collegamento di comunicazione -risposta
DSC_73 In ASN1.0, i comandi precedenti possono essere definiti
come:
DSC_74 La descrizione dei comandi e dei parametri è la seguente:
— si
usa per inizializzare il collegamento di comunicazione. Il
comando è inviato dalla VU alla DSRC-VU. Il LinkIden­
tifier è impostato dalla VU e comunicato alla DSRC-VU
per tracciare un collegamento di comunicazione specifico.
(Nota: serve a supportare collegamenti futuri e altre ap­
plicazioni/altri moduli come la pesatura a bordo).
— è
usato dalla DSRC-VU per rispondere alla richiesta di ini­
zializzazione del collegamento di comunicazione. Il co­
mando è inviato dalla DSRC-VU alla VU. Il comando
dà il risultato dell'inizializzazione come risposta = 1 (av­
venuta) o = 0 (fallita).
DSC_75 L'inizializzazione del collegamento di comunicazione deve
essere fatta solo dopo l'installazione, la taratura e l'avvio del
motore/l'accensione della VU.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 583
— è usato dalla VU per inviare i dati
firmati RCDTData (= i dati della comunicazione remota)
alla DSRC-VU. I dati saranno inviati ogni 60 secondi. Il
parametro DataTransactionId identifica la trasmissione di
dati specifica. Il LinkIdentifier si usa anche per garantire
che il collegamento appropriato sia corretto.
— è inviato dalla
DSRC-VU per informare la VU della ricezione dei dati
da un comando identificato dal para­
metro DataTransactionId. Il parametro di risposta è 1 (av­
venuta) o = 0 (fallita). Se la VU riceve più di tre risposte
uguali a 0 o se la VU non riceve un RCDT-Data Ackno­
wledgment per un RCDT- Send Data specifico preceden­
temente inviato con un DataTransactionId specifico, la Vu
genererà e registrerà un'anomalia.
— è inviato
dalla VU alla DSRC-VU per chiudere un collegamento
per un LinkIdentifier specifico.
DSC_76 Al riavvio della DSRC-VU o di una VU, tutti i collegamenti
di comunicazione esistenti dovrebbero essere rimossi, poiché
potrebbero esserci collegamenti «pendenti» dovuti all'arresto
improvviso di una VU.
— è inviato
dalla DSRC-VU alla VU per confermare la richiesta della
VU di chiusura del collegamento per il LinkIdentifier
specifico.
5.7 Trattamento degli errori
5.7.1 Registrazione e comunicazione dei dati nella DSRC-VU
▼M3
DSC_77 I dati, una volta resi sicuri, devono essere forniti dalla fun­
zione VUSM alla DSRC-VU. La VUSM deve verificare che la
trasmissione alla DSRC-VU dei dati registrati nella DSRC-VU
abbia avuto esito positivo. La registrazione e la comunica­
zione degli eventuali errori nel trasferimento dei dati dalla
VU alla memoria della DSRC-VU devono essere registrate
insieme alla marcatura oraria come EventFaultType e con il
valore enum impostato su «0C»H (corrispondente all’anoma­
lia di tipo «Errore di comunicazione con il dispositivo di
comunicazione remota»). La VUSM deve verificare che la
trasmissione dei dati alla DSRC-VU abbia avuto esito
positivo.
DSC_78 Riservato per uso futuro.
▼B
DSC_79 Se la VUPM cerca di ottenere dati della VU dal modulo di
sicurezza (da passare alla DSRC-VU), ma senza successo, deve
registrare tale tentativo fallito insieme al timestamp come Even­
tFaultType e con il valore ENUM impostato a «62»H Errore di
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 584
comunicazione del dispositivo di comunicazione remota. La man­
cata comunicazione è rilevata quando un messaggio­
non è ricevuto per i relativi
(vale a dire con lo stesso DataTransactionId
nei messaggi ) per
oltre tre volte consecutive.
5.7.2 Errori di comunicazione senza fili
DSC_80 La gestione degli errori di comunicazione deve essere con­
forme alle relative norme DSRC, nello specifico EN 300
674-1, EN 12253, EN 12795, EN 12834, e ai parametri ap­
propriati di EN 13372.
5.7.2.1 Errori di cifratura e di firma
DSC_81 Gli errori di cifratura e di firma devono essere gestiti come
definito nell'appendice 11 (Meccanismi comuni di sicurezza) e
non sono presenti in nessun messaggio di errore associato al
trasferimento DSRC di dati.
5.7.2.2 Registrazione degli errori
Il mezzo DSRC è una comunicazione senza fili dinamica in un ambiente
con condizioni atmosferiche e di interferenza incerte, in particolare nelle
combinazioni «REDCR portatile» e «veicolo in movimento» usate in
questa applicazione. Di conseguenza è necessario accertare la differenza
tra un «mancata lettura» e una condizione di «errore». In una transazione
tramite un'interfaccia senza fili, le mancate letture sono comuni e la
conseguenza consiste generalmente nel riprovare, vale a dire nel ritra­
smettere la BST e nel riprovare la sequenza, il che nella maggior parte
dei casi porta a un collegamento di comunicazione con esito positivo e
al trasferimento dei dati, a meno che il veicolo bersaglio non esca dal
raggio del dispositivo nel periodo necessario per la ritrasmissione. (Una
«lettura» con «esito positivo» può aver comportato diversi tentativi ri­
petuti).
Una mancata lettura può essere causata dall'abbinamento non corretto
delle antenne (errore di «puntamento»); dal fatto che una delle antenne è
schermata, deliberatamente o a causa della presenza fisica di un altro
veicolo; da interferenze radio, causate in particolare da WIFI a circa
5,8 GHz o da altre comunicazioni senza fili di accesso pubblico, da
interferenze radar o da condizioni atmosferiche difficili (ad esempio
durante un temporale); o semplicemente dal fatto di uscire dal raggio
di comunicazione della DSRC. I singoli casi di mancata lettura non
possono essere registrati, per la loro stessa natura, semplicemente perché
la comunicazione non è avvenuta.
Se tuttavia l'agente dell'autorità di controllo competente punta un veicolo
e cerca di interrogare la sua DSRC-VU, ma non avviene nessun trasfe­
rimento di dati, questo tentativo fallito potrebbe essere causato da una
manomissione deliberata e dunque l'agente dell'autorità di controllo com­
petente deve poterlo registrare ed avvisare i colleghi a valle della pos­
sibile violazione. I colleghi possono quindi fermare il veicolo e ispezio­
narlo fisicamente. Tuttavia, siccome non è avvenuta nessuna comunica­
zione con esito positivo, la DSRC-VU non può fornire dati riguardanti il
tentativo fallito. Questa comunicazione deve dunque essere una funzione
di progettazione dell'apparecchiatura REDCR.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 585
«Mancata lettura» è diverso da «errore» da un punto di vista tecnico. In
questo contesto un «errore» è l'acquisizione di un valore errato.
I dati trasferiti alla DSRC-VU sono forniti già sicuri e devono quindi
essere verificati dal fornitore degli stessi (cfr. paragrafo 5.4).
I dati successivamente trasferiti tramite l'interfaccia aerea sono controllati
tramite controlli di ridondanza ciclica al livello delle comunicazioni. Se
il CRC convalida, allora i dati sono corretti. Se il CRC non convalida, i
dati sono ritrasmessi. La probabilità che dati potrebbero superare erro­
neamente un CRC è talmente remota statisticamente da poter essere
scartata.
Se il CRC non convalida e non c'è tempo di ritrasmettere e ricevere i
dati corretti, il risultato non sarà un errore, ma un'istanziazione di un tipo
specifico di mancata lettura.
L'unico dato significativo riguardante i tentativi falliti che può essere
registrato è il numero di inizializzazioni corrette di transazioni che non
portano ad un trasferimento corretto di dati al REDCR.
DSC_82 Il REDCR deve dunque registrare con timestamp il numero di
casi in cui la fase di «inizializzazione» di un'interrogazione
DSRC va a buon fine, ma la transazione termina prima che i
dati siano recuperati con successo dal REDCR. Questo dato
deve essere messo a disposizione dell'agente dell'autorità di
controllo competente e deve essere salvato nella memoria
dell'attrezzatura REDCR. Il mezzo per raggiungere tale obiet­
tivo è una questione di progettazione del prodotto o deve
essere oggetto di specifiche di un'autorità di controllo
competente.
L'unico dato significativo riguardante gli «errori» che può
essere registrato è il numero di casi in cui il REDCR non
riesce a decriptare i dati ricevuti. Va tuttavia sottolineato che
ciò sarà riferito esclusivamente all'efficienza del software del
REDCR. I dati possono essere decriptati dal punto di vista
tecnico, ma dal punto di vista semantico non hanno senso.
DSC_83 Il REDCR deve dunque registrare con timestamp il numero di
casi in cui ha cercato, senza successo, di decriptare dati rice­
vuti tramite l'interfaccia DSRC.
6 PROVE DI ATTIVAZIONE E DI ISPEZIONE PERIODICA PER LA
FUNZIONE DI COMUNICAZIONE REMOTA
6.1 Aspetti generali
DSC_84 Per la funzione di comunicazione remota sono previsti due
tipi di prove:
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 586
1) Una prova ECHO per convalidare il canale di comunica­
zione senza fili DSRC-REDCR>>-:-
2) Una prova di sicurezza end-to-end per garantire che una
carta dell'officina sia in grado di avere accesso al conte­
nuto dei dati criptati e firmati creato dalla VU e trasmesso
tramite il canale di comunicazione senza fili.
6.2 ECHO
Questa clausola contiene disposizioni elaborate specificamente per te­
stare solo il fatto che il collegamento DSRC-REDCR >>-:-
sia funzionalmente attivo.
L'obiettivo del comando ECHO è di permettere alle officine o ai labo­
ratori di prova per il rilascio delle omologazioni di verificare che il
collegamento DSRC funzioni senza bisogno di accedere alle credenziali
di sicurezza. Le attrezzature di chi esegue le prove dunque devono
essere in grado solamente di inizializzare una comunicazione DSRC
(inviando una BST con AID=2) e poi di inviare il comando ECHO e,
supponendo che il DSRC funzioni, riceveranno una risposta ECHO. Per
informazioni dettagliate si rimanda al paragrafo 5.4.8. Supponendo che
riceva correttamente questa risposta, il collegamento DSRC (DSRC-
REDCR >>-:-
correttamente.
6.3 Prove per convalidare il contenuto dei dati sicuri
DSC_85 Questa prova è eseguita per convalidare la sicurezza del
flusso di dati da un estremo all'altro (end-to-end). Per eseguire
la prova è necessario un lettore di prova DSRC. Il lettore di
prova DSRC ha la stessa funzionalità ed è usato secondo le
stesse specifiche del lettore utilizzato dalle forze dell'ordine,
con la differenza che per autenticare l'utente del lettore di
prova DSRC si deve usare una carta dell'officina anziché
una carta di controllo. La prova può essere eseguita dopo
l'attivazione iniziale di un tachigrafo intelligente o al termine
della procedura di taratura. Dopo l'attivazione, l'unità elettro­
nica di bordo deve generare e comunicare alla DSRC-VU i
dati sicuri di diagnosi precoce.
DSC_86 Il personale dell'officina deve posizionare il lettore di prova
DSRC a una distanza tra i 2 e i 10 metri davanti al veicolo.
DSC_87 Poi il personale dell'officina deve inserire una carta dell'offi­
cina nel lettore di prova DSRC per chiedere l'interrogazione
dei dati di diagnosi precoce all'unità elettronica di bordo.
Dopo un'interrogazione con esito positivo, il personale dell'of­
ficina deve avere accesso ai dati ricevuti per garantire che la
loro integrità sia stata correttamente convalidata e che siano
stati correttamente decriptati.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 587
ADDENDUM
Regole per il calcolo del periodo di guida giornaliero, settimanale e quindicinale
1. Regole di calcolo di base
La VU deve calcolare il periodo di guida giornaliero, il periodo di guida
settimanale e il periodo di guida quindicinale utilizzando i dati pertinenti
memorizzati in una carta del conducente (o dell’officina) inserita nella sede
(slot 1, lettore della carta #1) dell’unità elettronica di bordo, e determinate
attività del conducente mentre tale carta è inserita nella VU.
I tempi di guida non devono essere calcolati quando non è inserita nessuna
carta del conducente (o dell’officina).
I periodi NON NOTI individuati durante il periodo necessario per i calcoli
devono essere assimilati a INTERRUZIONE/RIPOSO.
Non sono tenuti in considerazione i periodi NON NOTI e le attività di durata
negativa (ossia quando l’inizio dell’attività si verifica più tardi della fine
dell’attività) dovuti a sovrapposizioni di orari tra due diverse VU o a regola­
zioni dell’ora.
Le attività registrate nella carta del conducente corrispondenti a periodi di tipo
«ESCLUSO DAL CAMPO DI APPLICAZIONE» in conformità alla defini­
zione gg) dell’allegato IC devono essere interpretate come segue:
— INTERRUZIONE/RIPOSO devono essere calcolati come «INTERRU­
ZIONE» o «RIPOSO»;
— LAVORO e GUIDA devono essere considerati come «LAVORO»;
— DISPONIBILITÀ deve essere considerata «DISPONIBILITÀ».
Nel contesto del presente addendum, la VU deve presupporre un periodo di
riposo giornaliero all’inizio delle registrazioni delle attività della carta.
2. Concetti
I concetti seguenti si applicano esclusivamente alla presente appendice e sono
intesi a specificare il calcolo da parte della VU dei periodi di guida e la loro
successiva trasmissione da parte del dispositivo di comunicazione remota.
a) «Turno RTM»: il periodo compreso tra la fine di un periodo di riposo
giornaliero e la fine del periodo di riposo giornaliero immediatamente
successivo;
la VU deve avviare un nuovo turno RTM una volta finito un periodo di
riposo giornaliero;
il turno RTM in corso è il periodo trascorso dalla fine dell’ultimo periodo
di riposo giornaliero;
b) «periodo di guida cumulativo»: la somma della durata di tutte le attività di
GUIDA del conducente entro un periodo non ESCLUSO DAL CAMPO
DI APPLICAZIONE;
c) «periodo di guida giornaliero»: il periodo di guida cumulativo nell’ambito
di un turno RTM;
d) «periodo di guida settimanale»: il periodo di guida cumulativo per la
settimana in corso;
e) «periodo di riposo continuo»: qualsiasi periodo ininterrotto di INTERRU­
ZIONE/RIPOSO;
f) «periodo di guida quindicinale»: il periodo di guida cumulativo per la
settimana in corso e quella precedente;
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 588
g) «periodo di riposo giornaliero»: un periodo di INTERRUZIONE/RIPOSO,
che può essere
— un periodo di riposo giornaliero regolare,
— un periodo di riposo giornaliero suddiviso o
— un periodo di riposo giornaliero ridotto;
nel contesto dell’appendice 14, quando una VU calcola i periodi di riposo
settimanale, questi ultimi devono essere considerati periodi di riposo
giornalieri;
h) «periodo di riposo giornaliero regolare»: un periodo di riposo continuo di
almeno 11 ore.
In via eccezionale, quando è attiva una condizione ATTRAVERSA­
MENTO MEDIANTE TRAGHETTO/TRENO, il periodo di riposo gior­
naliero regolare può essere interrotto al massimo due volte da attività
diverse dal riposo, con una durata cumulativa massima di un’ora; vale a
dire che il periodo di riposo giornaliero regolare contenente uno o più
periodi di attraversamento mediante traghetto/treno può essere suddiviso
in due o tre parti. La VU deve quindi calcolare un periodo di riposo
giornaliero regolare quando il periodo di riposo accumulato calcolato con­
formemente al punto 3 è di almeno 11 ore.
In caso di interruzione di un periodo di riposo giornaliero regolare, la VU:
— non deve integrare l’attività di guida rilevata durante tali interruzioni
nel calcolo del periodo di guida giornaliero, e
— deve avviare un nuovo turno RTM alla fine del periodo di riposo
giornaliero regolare che è stato interrotto;
Figura 1
esempio di periodo di riposo giornaliero interrotto a causa di un attraversamento mediante traghetto/treno
i) «periodo di riposo giornaliero ridotto»: un periodo di riposo continuo di
almeno 9 ore e di meno di 11 ore;
j) «periodo di riposo giornaliero suddiviso»: un periodo di riposo giornaliero
effettuato in due parti:
— la prima parte deve essere un periodo di riposo continuo di almeno 3
ore e di meno di 9 ore,
— la seconda parte deve essere un periodo di riposo continuo di almeno 9
ore.
In via eccezionale, quando una condizione ATTRAVERSAMENTO ME­
DIANTE TRAGHETTO/TRENO è attiva durante una o entrambe le parti
di un periodo di riposo giornaliero suddiviso, il periodo di riposo giorna­
liero suddiviso può essere interrotto al massimo due volte da altre attività
la cui durata cumulativa massima è pari a un’ora, ossia:
— la prima parte del periodo di riposo giornaliero suddiviso può essere
interrotta una o due volte, oppure
— la seconda parte del periodo di riposo giornaliero suddiviso può essere
interrotta una o due volte, oppure
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 589
— la prima parte del periodo di riposo giornaliero suddiviso può essere
interrotta una volta e la seconda parte del periodo di riposo giornaliero
suddiviso può essere interrotta una volta.
La VU deve quindi calcolare un periodo di riposo giornaliero suddiviso quando
il periodo di riposo accumulato calcolato conformemente al punto 3 è:
— di almeno tre ore e di meno di 11 ore per il primo periodo di riposo e
di almeno 9 ore per il secondo periodo di riposo, se il primo periodo di
riposo è stato interrotto da un ATTRAVERSAMENTO MEDIANTE
TRAGHETTO/TRENO;
— di almeno tre ore e di meno di 9 ore per il primo periodo di riposo e di
almeno 9 ore per il secondo periodo di riposo, se il primo periodo di
riposo non è stato interrotto da un ATTRAVERSAMENTO ME­
DIANTE TRAGHETTO/TRENO.
Figura 2
esempio di periodo di riposo giornaliero suddiviso interrotto a causa di un attraversamento mediante
traghetto/treno
In caso di interruzione di un periodo di riposo giornaliero suddiviso, la VU:
— non deve integrare l’attività di guida rilevata durante tali interruzioni
nel calcolo del periodo di guida giornaliero, e
— deve avviare un nuovo turno RTM alla fine del periodo di riposo
giornaliero suddiviso che è stato interrotto;
k) «settimana»: il periodo compreso tra le 00:00 del lunedì e le 24:00 della
domenica (ora UTC).
3. Calcolo del periodo di riposo interrotto a causa di un attraversamento me­
diante traghetto/treno
Ai fini del calcolo del periodo di riposo nei casi in cui è stato interrotto da un
attraversamento mediante traghetto/treno, la VU deve calcolare il periodo di
riposo cumulativo rispettando la seguente procedura:
a) Fase 1
La VU deve rilevare le interruzioni del periodo di riposo che si verificano
prima dell’attivazione dell’indicatore ATTRAVERSAMENTO ME­
DIANTE TRAGHETTO/TRENO (INIZIO) conformemente alla figura 3
e, se del caso, alla figura 4 e deve valutare, per ciascuna interruzione
rilevata, se sono soddisfatte le seguenti condizioni:
— l’interruzione fa sì che la durata totale delle interruzioni rilevate, com­
prese se del caso le interruzioni che si verificano durante la prima parte
di un periodo di riposo giornaliero suddiviso a causa di un attraversa­
mento mediante traghetto/treno, sia superiore a un’ora;
— l’interruzione fa sì che il numero totale di interruzioni rilevate, com­
prese se del caso le interruzioni che si verificano durante la prima parte
di un periodo di riposo giornaliero suddiviso a causa di un attraversa­
mento mediante traghetto/treno, sia superiore a due;
— dopo la fine dell’interruzione è stata memorizzata un’«Immissione del
luogo in cui termina il periodo di lavoro giornaliero».
Se nessuna delle condizioni di cui sopra è soddisfatta, il periodo di riposo
continuo immediatamente precedente l’interruzione deve essere aggiunto al
periodo di riposo cumulativo.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 590
Se almeno una delle condizioni di cui sopra è soddisfatta, la VU deve
interrompere il calcolo del periodo di riposo cumulativo conformemente
alla fase 2 o rilevare le interruzioni del periodo di riposo che si verificano
dopo la disattivazione dell’indicatore ATTRAVERSAMENTO ME­
DIANTE TRAGHETTO/TRENO (INIZIO) conformemente alla fase 3.
b) Fase 2
Per ciascuna interruzione rilevata conformemente alla fase 1, la VU deve
valutare se interrompere il calcolo del periodo di riposo cumulativo. La
VU deve interrompere il processo di calcolo quando al periodo di riposo
cumulativo sono stati aggiunti due periodi di riposo continui verificatisi
prima dell’attivazione dell’indicatore ATTRAVERSAMENTO ME­
DIANTE TRAGHETTO/TRENO (INIZIO), compresi se del caso i periodi
di riposo aggiunti nella prima parte di un periodo di riposo giornaliero
suddiviso interrotto anche da un attraversamento mediante traghetto/treno.
La VU deve altrimenti operare conformemente alla procedura di cui nella
fase 3.
c) Fase 3
Se continua il calcolo del periodo di riposo cumulativo dopo l’esecuzione
della fase 2, la VU deve rilevare le interruzioni che si verificano dopo la
disattivazione della condizione ATTRAVERSAMENTO MEDIANTE
TRAGHETTO/TRENO conformemente alla figura 3 e, se del caso, alla
figura 4.
Per ciascuna interruzione rilevata, la VU deve valutare se l’interruzione fa
sì che il periodo cumulativo di tutte le interruzioni rilevate sia complessi­
vamente superiore a un’ora, nel qual caso il calcolo del periodo di riposo
cumulativo deve terminare alla fine del periodo di riposo continuo prece­
dente all’interruzione. In caso contrario, i periodi di riposo continui che si
verificano dopo le rispettive interruzioni devono essere aggiunti al calcolo
del periodo di riposo giornaliero fino a quando non sia soddisfatta la
condizione di cui alla fase 4.
d) Fase 4
Il calcolo del periodo di riposo cumulativo deve terminare quando la VU
ha aggiunto, a seguito delle fasi 1 e 3, un massimo di due periodi di riposo
continui al periodo di riposo per il quale è attivata la condizione ATTRA­
VERSAMENTO MEDIANTE TRAGHETTO/TRENO, anche nel caso in
cui si verifichino interruzioni dovute a un attraversamento traghetto/treno
durante la prima parte di un periodo di riposo giornaliero suddiviso.
Figura 3
elaborazione dei periodi di riposo da parte della VU al fine di stabilire se un periodo di riposo interrotto
debba essere calcolato come periodo di riposo giornaliero regolare o come prima parte di un periodo di
riposo giornaliero suddiviso
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 591
Figura 4
elaborazione dei periodi di riposo da parte della VU al fine di stabilire se un periodo di riposo
interrotto debba essere calcolato come seconda parte di un periodo di riposo giornaliero suddiviso
Figura 5
esempio di un periodo di riposo giornaliero interrotto più di due volte, che impedisce di includere nel
calcolo il periodo di riposo H
Figura 6
esempio di periodo di riposo giornaliero in cui il periodo di calcolo traghetto/treno è iniziato alla fine
del periodo di lavoro
Figura 7
esempio di un periodo di riposo giornaliero interrotto più di due volte, che impedisce di includere nel
calcolo il periodo di riposo B
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 592
Figura 8
esempio di un periodo di riposo giornaliero suddiviso interrotto una volta durante il primo periodo di
riposo e una volta durante il secondo periodo di riposo
4. Calcolo dei periodi di guida giornaliero, settimanale e quindicinale
La VU deve calcolare i periodi di guida giornalieri per i turni RTM in
corso e per quelli precedenti. Il periodo di guida effettuato durante le
interruzioni dei periodi di riposo giornalieri non deve essere aggiunto al
calcolo del periodo di guida giornaliero, qualora tali interruzioni siano
dovute a un attraversamento traghetto/treno e siano state rispettati i requi­
siti di cui al punto 2, lettere h) e j), e al punto 3. Tuttavia, nella misura in
cui un periodo di riposo giornaliero completo regolare o suddiviso non sia
stato calcolato dalla VU conformemente al punto 3, i periodi di guida
effettuati durante le interruzioni devono essere aggiunti al periodo di guida
giornaliero per il turno RTM in corso.
La VU deve altresì calcolare i periodi di guida settimanali e quindicinali. Il
periodo di guida effettuato durante le interruzioni dei periodi di riposo
giornalieri dovuti a un attraversamento traghetto/treno deve essere aggiunto
al calcolo dei periodi di guida settimanale e quindicinale.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 593
Appendice 15
MIGRAZIONE: GESTIONE DELLA COESISTENZA DI DIVERSE
GENERAZIONI E VERSIONI DI APPARECCHIATURE
▼B
INDICE
1. DEFINIZIONI
2. DISPOSIZIONI GENERALI
2.1. Transizione
▼M3
2.2. Interoperabilità tra la VU e le carte
▼B
2.3. Interoperabilità tra VU e MS
2.4. Interoperabilità tra unità elettroniche di bordo, carte tachigrafiche e appa­
recchi per il trasferimento di dati
2.4.1 Trasferimento diretto dalla carta mediante IDE
2.4.2 Trasferimento di dati dalla carta mediante un'unità elettronica di bordo
2.4.3 Trasferimento dall'unità elettronica di bordo
2.5. Interoperabilità tra VU e apparecchiatura di taratura
3. FASI PRINCIPALI PRIMA DELL'INTRODUZIONE
4. DISPOSIZIONI PER IL PERIODO SUCCESSIVO ALL'INTRODU­
ZIONE
▼M3
5. REGISTRAZIONE DEGLI ATTRAVERSAMENTI DI FRONTIERA
NEI TACHIGRAFI DI PRIMA GENERAZIONE E NELLA PRIMA
VERSIONE DEI TACHIGRAFI DI SECONDA GENERAZIONE
▼B
1. DEFINIZIONI
Ai fini della presente appendice si applicano le seguenti definizioni:
sistema tachigrafico intelligente: come definito dal presente allegato (ca­
pitolo 1: definizione bbb);
tachigrafo di prima generazione: come definito dal presente regolamento
(articolo 2: definizione 1);
tachigrafo di seconda generazione: come definito dal presente regola­
mento (articolo 2: definizione 7);
data di introduzione: come definito dal presente allegato (capitolo 1:
definizione ccc);
Apparecchio intelligente dedicato [IDE (Intelligent dedicated equip­
ment)]: apparecchio utilizzato per il trasferimento di dati, conformemente
alla definizione di cui all'appendice 7 del presente allegato.
▼M3
2. DISPOSIZIONI GENERALI
2.1. Panoramica della transizione
L’introduzione del presente allegato fornisce una panoramica della transi­
zione tra i sistemi tachigrafici di prima e seconda generazione e dell’in­
troduzione della seconda versione dell’apparecchio di controllo e delle
carte tachigrafiche di seconda generazione.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 594
Oltre alle disposizioni della presente introduzione, si possono ricordare le
seguenti informazioni:
— i sensori di movimento di prima generazione non sono interoperabili
con nessuna versione delle unità elettroniche di bordo di seconda
generazione;
— solo i sensori di movimento di seconda generazione possono essere
montati su veicoli muniti di qualsiasi versione delle unità elettroniche
di bordo di seconda generazione;
— l’apparecchiatura per il trasferimento e la taratura dei dati deve essere
compatibile con entrambe le generazioni o versioni dell’apparecchio di
controllo e delle carte tachigrafiche.
2.2. Interoperabilità tra la VU e le carte
Resta inteso che le carte tachigrafiche di prima generazione sono intero­
perabili con le unità elettroniche di bordo di prima generazione (confor­
memente all’allegato IB del regolamento (CEE) n. 3821/85), mentre qual­
siasi versione delle carte tachigrafiche di seconda generazione è interope­
rabile con qualsiasi versione delle unità elettroniche di bordo di seconda
generazione (conformemente all’allegato IC del presente regolamento). Si
applicano inoltre i seguenti requisiti.
MIG_001 Fatta eccezione per quanto previsto dai requisiti MIG_004 e
MIG_005, le carte tachigrafiche di prima generazione possono
continuare a essere utilizzate in qualsiasi versione delle unità
elettroniche di bordo di seconda generazione fino alla scadenza
della loro validità. I titolari possono tuttavia chiedere la sostitu­
zione di tali carte con carte tachigrafiche di seconda generazione
non appena queste ultime sono disponibili.
MIG_002 Qualsiasi versione delle unità elettroniche di bordo di seconda
generazione deve essere in grado di utilizzare qualsiasi carta
del conducente, di controllo o dell’azienda di prima genera­
zione inserita che sia valida.
MIG_003 Questa capacità può essere soppressa definitivamente in tali
unità elettroniche di bordo dalle officine in modo che le carte
tachigrafiche di prima generazione non siano più accettate.
Tuttavia ciò sarà possibile solo dopo che la Commissione
europea avrà avviato una procedura per richiedere alle officine
di compiere tale azione, ad esempio durante l’ispezione perio­
dica del tachigrafo.
MIG_004 Le unità elettroniche di bordo di seconda generazione devono
poter utilizzare esclusivamente le carte dell’officina di se­
conda generazione.
MIG_005 Per determinare il modo di funzionamento, qualsiasi versione
delle unità elettroniche di bordo di seconda generazione deve
tenere in considerazione solo i tipi di carte valide inserite,
indipendentemente dalla generazione o versione di queste
ultime.
MIG_006 Qualsiasi versione di carta tachigrafica di seconda generazione va­
lida deve poter essere utilizzata nelle unità elettroniche di bordo di
prima generazione esattamente nello stesso modo di una carta tachi­
grafica di prima generazione dello stesso tipo.
2.3. Interoperabilità tra VU e MS
Resta inteso che i sensori di movimento (MS) di prima generazione sono
interoperabili con le unità elettroniche di bordo di prima generazione,
mentre i sensori di movimento di seconda generazione sono interoperabili
con qualsiasi versione delle unità elettroniche di bordo di seconda gene­
razione. Si applicano inoltre i seguenti requisiti.
MIG_007 Nessuna versione delle unità elettroniche di bordo di seconda
generazione dovrà essere abbinata a sensori di movimento di
prima generazione.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 595
MIG_008 I sensori di movimento di seconda generazione potranno es­
sere abbinati e utilizzati unicamente con unità elettroniche di
bordo di seconda generazione, qualsiasi versione, oppure con
entrambe le generazioni di unità elettroniche di bordo.
2.4. Interoperabilità tra unità elettroniche di bordo, carte tachigrafiche e
apparecchi per il trasferimento di dati
MIG_009 Gli apparecchi per il trasferimento di dati possono essere
compatibili con tutte le generazioni e versioni di unità elet­
troniche di bordo e carte tachigrafiche.
2.4.1 Trasferimento diretto dalla carta mediante IDE
MIG_010 I dati devono essere trasferiti mediante IDE dalle carte tachi­
grafiche di prima generazione inserite nei lettori di carte, uti­
lizzando i meccanismi di sicurezza e il protocollo di trasferi­
mento dati di tale generazione e i dati trasferiti devono corri­
spondere al formato definito per tale generazione e versione.
MIG_011 Per consentire il controllo dei conducenti da parte di autorità
non UE deve essere inoltre possibile trasferire dati dalle carte
del conducente (e dell’officina) di seconda generazione, a pre­
scindere dalla versione, esattamente nello stesso modo in cui
sono trasferiti dalle carte del conducente (e dell’officina) di
prima generazione. Tali trasferimenti devono includere:
— EF IC e ICC non firmati (facoltativo);
— EF (prima generazione) Card_Certificate e CA_Certificate
non firmati;
— gli altri EF dei dati applicativi (all’interno del DF Tacho­
graph) richiesti dal protocollo di trasferimento della carta
di prima generazione. Tali informazioni devono essere
rese sicure mediante una firma digitale conformemente
ai meccanismi di sicurezza di prima generazione.
Tale trasferimento dati non deve includere gli EF dei dati
applicativi presenti solo nelle carte del conducente (e
dell’officina) di seconda generazione, versione 1 o ver­
sione 2 (EF dei dati applicativi all’interno del DF Tacho­
graph_G2).
2.4.2 Trasferimento dati dalla carta mediante un’unità elettronica di bordo
MIG_012 I dati devono essere trasferiti da qualsiasi versione di una
carta di seconda generazione inserita in un’unità elettronica
di bordo di prima generazione utilizzando il protocollo di
trasferimento dati di prima generazione. La carta deve rispon­
dere ai comandi dell’unità elettronica di bordo esattamente
nello stesso modo in cui risponde una carta di prima genera­
zione. I dati trasferiti devono avere lo stesso formato dei dati
trasferiti da una carta di prima generazione.
MIG_013 I dati devono essere trasferiti da una carta di prima genera­
zione inserita in qualsiasi versione di un’unità elettronica di
bordo di seconda generazione utilizzando il protocollo di tra­
sferimento dati di cui all’appendice 7 del presente allegato.
L’unità elettronica di bordo deve inviare i comandi alla carta
esattamente nello stesso modo in cui li invia un’unità elettro­
nica di bordo di prima generazione. I dati trasferiti devono
rispettare il formato definito per le carte di prima generazione.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 596
2.4.3 Trasferimento dall’unità elettronica di bordo
MIG_014 Tranne che nel caso dei controlli dei conducenti da parte di
un’autorità di controllo non UE, i dati devono essere trasferiti
da un’unità elettronica di bordo di seconda generazione utiliz­
zando i meccanismi di sicurezza di seconda generazione e il
protocollo di trasferimento dati di cui all’appendice 7 del
presente allegato per la pertinente versione.
MIG_015 Per consentire il controllo dei conducenti da parte di autorità
non UE, può essere facoltativamente reso possibile il trasfe­
rimento dei dati da qualsiasi versione delle unità elettronica di
bordo di seconda generazione utilizzando meccanismi di sicu­
rezza di prima generazione. I dati trasferiti devono quindi
avere lo stesso formato dei dati trasferiti da un’unità elettro­
nica di bordo di prima generazione. Questa capacità può es­
sere selezionata mediante i comandi del menù.
2.5. Interoperabilità tra VU e apparecchiatura di taratura
MIG_016 L’apparecchiatura di taratura deve essere in grado di tarare
qualsiasi generazione o versione di tachigrafo, utilizzando il
protocollo di taratura della generazione o versione in que­
stione. L’apparecchiatura di taratura può essere compatibile
con tutte le generazioni e versioni delle unità elettroniche di
bordo.
3. FASI PRINCIPALI NEL PERIODO PRECEDENTE LA DATA
DELL’INTRODUZIONE
MIG_017 Chiavi e certificati di prova devono essere messi a disposi­
zione dei fabbricanti alla data di pubblicazione del presente
allegato.
MIG_018 Le prove di interoperabilità devono essere pronte ad iniziare
con la versione 2 delle unità elettroniche di bordo e la ver­
sione 2 delle carte tachigrafiche se richiesto dai fabbricanti al
più tardi 15 mesi prima della data di introduzione.
MIG_019 Per i tachigrafi, le carte tachigrafiche e i sensori di movimento
di seconda generazione, versione 2, si utilizzano le stesse
chiavi e i medesimi certificati utilizzati per gli apparecchi di
generazione 2, versione 1.
MIG_020 Gli Stati membri devono essere in grado di rilasciare carte
dell’officina di seconda generazione, versione 2, almeno 1
mese prima della data di introduzione.
MIG_021 Gli Stati membri devono essere in grado di rilasciare tutti i
tipi di carte tachigrafiche di seconda generazione, versione 2,
almeno 1 mese prima della data di introduzione.
4. DISPOSIZIONI PER IL PERIODO SUCCESSIVO ALLA DATA DI IN­
TRODUZIONE
MIG_022 A decorrere dalla data di introduzione, gli Stati membri do­
vranno rilasciare soltanto carte tachigrafiche di seconda gene­
razione, versione 2.
MIG_023 I fabbricanti di unità elettroniche di bordo/sensori di movi­
mento devono essere autorizzati a produrre unità elettroniche
di bordo/sensori di movimento di prima generazione finché
essi sono utilizzati nel settore, in modo che sia possibile so­
stituire componenti che non funzionano correttamente.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 597
MIG_023a A decorrere dalla data di introduzione, le unità elettroniche di
bordo o i dispositivi GNSS esterni di seconda generazione,
versione 1, che non funzionano correttamente devono essere
sostituiti da unità elettroniche di bordo o dispositivi GNSS
esterni di seconda generazione, versione 2.
MIG_024 I fabbricanti di unità elettroniche di bordo/sensori di movi­
mento devono essere autorizzati a richiedere e a ottenere
l’omologazione della manutenzione di unità elettroniche di
bordo/sensori di movimento di prima generazione o di se­
conda generazione, versione 1, che sono stati già omologati.
5. REGISTRAZIONE DEGLI ATTRAVERSAMENTI DI FRONTIERA NEI
TACHIGRAFI DI PRIMA GENERAZIONE E NELLA PRIMA VER­
SIONE DEI TACHIGRAFI DI SECONDA GENERAZIONE
MIG_025 Il simbolo del paese e, se del caso, della regione in cui il
conducente entra dopo aver attraversato una frontiera di uno
Stato membro in applicazione dell’articolo 34, paragrafo 7,
del regolamento (UE) n. 165/2014 deve essere inserito come
luogo in cui inizia il periodo di lavoro giornaliero conforme­
mente all’immissione manuale dei luoghi di cui al requisito 60
dell’allegato IC del regolamento (UE) n. 165/2014 e al requi­
sito 50 dell’allegato IB del regolamento (CEE) n. 3821/85.
▼M3
02016R0799 — IT — 21.08.2023 — 003.002 — 598
Appendice 16
ADATTATORE PER VEICOLI DELLE CATEGORIE M1 E N1
INDICE
1. ABBREVIAZIONI E DOCUMENTI DI RIFERIMENTO
1.1. Abbreviazioni
1.2. Norme di riferimento
2. CARATTERISTICHE E FUNZIONI GENERALI DELL'ADATTATORE
2.1. Descrizione generale dell'adattatore
2.2. Funzioni
2.3. Sicurezza
3. REQUISITI DELL'APPARECCHIO DI CONTROLLO QUANDO È
MONTATO UN ADATTATORE
4. REQUISITI DI COSTRUZIONE E FUNZIONAMENTO DELL'ADAT­
TATORE
4.1. Interfaccia e adattamento degli impulsi di velocità in entrata
4.2. Trasferimento degli impulsi in entrata al sensore di movimento incorporato
4.3. Sensore di movimento incorporato
4.4. Requisiti di sicurezza
4.5. Caratteristiche prestazionali
4.6. Materiali
4.7. Contrassegni
5. MONTAGGIO DELL'APPARECCHIO DI CONTROLLO QUANDO È
UTILIZZATO UN ADATTATORE
5.1. Montaggio
5.2. Sigilli
6. VERIFICHE, CONTROLLI E RIPARAZIONI
6.1. Controlli periodici
7. OMOLOGAZIONE DELL'APPARECCHIO DI CONTROLLO QUANDO
È UTILIZZATO UN ADATTATORE
7.1. Prescrizioni generali
7.2. Certificato funzionale
1. ABBREVIAZIONI E DOCUMENTI DI RIFERIMENTO
1.1. Abbreviazioni
TBD To Be Defined (da definire)
VU Vehicle Unit (Unità elettronica di bordo)
1.2. Norme di riferimento
ISO16844-3 Road vehicles — Tachograph systems — Part 3: Motion
sensor interface (Veicoli stradali — Sistemi tachigrafici — Parte 3: Inter­
faccia del sensore di movimento).
2. CARATTERISTICHE E FUNZIONI GENERALI DELL'ADATTATORE
2.1. Descrizione generale dell'adattatore
ADA_001 L'adattatore fornisce a una VU collegata dati di movimento
securizzati che sono costantemente rappresentativi della velo­
cità del veicolo e della distanza percorsa.
L'adattatore è destinato esclusivamente ai veicoli per i quali è
obbligatorio il montaggio dell'apparecchio di controllo in con­
formità del presente regolamento.
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 599
Esso è montato e utilizzato esclusivamente sui tipi di veicoli
definiti alla lettera yy) «adattatore» dell'allegato IC, nei casi in
cui non è meccanicamente possibile montare un altro tipo di
sensore di movimento che sia altrimenti conforme alle dispo­
sizioni del presente allegato e delle appendici da 1 a 16 dello
stesso.
L'adattatore non deve essere collegato meccanicamente a una
parte mobile del veicolo, bensì agli impulsi relativi alla velo­
cità/distanza generati da sensori integrati o interfacce
alternative.
ADA_002 Un sensore di movimento omologato (conformemente alle di­
sposizioni del presente allegato IC, sezione 8 — omologazione
dell'apparecchio di controllo e delle carte tachigrafiche) è mon­
tato nell'alloggiamento dell'adattatore, che comprende inoltre
un dispositivo di conversione che trasferisce gli impulsi in
entrata al sensore di movimento incorporato. Il sensore di mo­
vimento incorporato deve a sua volta essere collegato alla VU
in modo che l'interfaccia tra la VU e l'adattatore sia conforme
ai requisiti della norma ISO16844-3.
2.2. Funzioni
ADA_003 L'adattatore svolge le seguenti funzioni:
— interfaccia e adattamento degli impulsi di velocità in
entrata;
— trasferimento degli impulsi in entrata al sensore di movi­
mento incorporato;
— tutte le funzioni del sensore di movimento incorporato per
fornire alla VU dati di movimento securizzati.
2.3. Sicurezza
ADA_004 La certificazione di sicurezza dell'adattatore non si basa sugli
obiettivi generali di sicurezza per i sensori di movimento di cui
all'appendice 10 del presente allegato. A esso si applicano
invece i requisiti specificati al punto 4.4 della presente
appendice.
3. REQUISITI DELL'APPARECCHIO DI CONTROLLO QUANDO È
MONTATO UN ADATTATORE
I requisiti di cui ai successivi punti indicano come interpretare i requisiti
del presente allegato quando viene utilizzato un adattatore. I pertinenti
riferimenti numerici dei requisiti dell'allegato IC sono indicati tra parentesi.
ADA_005 L'apparecchio di controllo dei veicoli provvisti di adattatore
deve essere conforme a tutte le disposizioni del presente alle­
gato, salvo quando diversamente specificato nella presente
appendice.
ADA_006 Quando è montato un adattatore, l'apparecchio di controllo
comprende i cavi, l'adattatore (incluso il sensore di movimento)
e una VU [01].
ADA_007 La funzione di rilevamento di anomalie e/o guasti dell'apparec­
chio di controllo è modificata come segue:
— l'anomalia «interruzione dell'alimentazione di energia» (po­
wer supply interruption) è attivata dalla VU, quando non è
attiva la modalità di taratura, per qualsiasi interruzione di
durata superiore a 200 millisecondi dell'alimentazione del
sensore di movimento incorporato (79);
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 600
— l'anomalia «errore dei dati di movimento» (motion data
error) è attivata dalla VU in caso di interruzione del nor­
male flusso di dati tra il sensore di movimento incorporato
e l'unità elettronica di bordo e/o nel caso di un errore di
integrità o di autenticazione dei dati durante lo scambio di
dati tra il sensore di movimento incorporato e la VU (83);
— l'anomalia «tentativi di violazione della sicurezza» (security
breach attempt) è attivata dalla VU per ogni altra anomalia
relativa alla sicurezza del sensore di movimento incorpo­
rato, quando non è attiva la modalità di taratura (85);
— l'indicazione guasto dell'«apparecchio di controllo» (recor­
ding equipment) è attivata dalla VU, quando non è attiva la
modalità di taratura, per ogni guasto del sensore di movi­
mento incorporato (88).
ADA_008 I guasti dell'adattatore individuabili dall'apparecchio di con­
trollo sono quelli relativi al sensore di movimento incorporato
[88].
ADA_009 La funzione di taratura della VU consente l'abbinamento auto­
matico del sensore di movimento incorporato alla VU [202,
204].
4. REQUISITI DI COSTRUZIONE E FUNZIONAMENTO DELL'ADAT­
TATORE
4.1. Interfaccia e adattamento degli impulsi di velocità in entrata
ADA_011 L'interfaccia di entrata dell'adattatore accetta impulsi di fre­
quenza corrispondenti alla velocità del veicolo e alla distanza
da esso percorsa. Le caratteristiche elettriche degli impulsi in
ingresso sono: TBD dal fabbricante. Gli adeguamenti che pos­
sono essere apportati solo dal fabbricante dell'adattatore e dal­
l'officina autorizzata che effettua il montaggio dell'adattatore
devono consentire, se del caso, il corretto collegamento dell'in­
put dell'adattatore al veicolo.
▼M3
ADA_012 L’interfaccia di ingresso dell’adattatore deve essere in grado, se
del caso, di moltiplicare o dividere gli impulsi di frequenza
degli impulsi di velocità in entrata per un fattore fisso in
modo da adeguare il segnale all’intervallo del fattore k definito
dal presente allegato (da 2 400 a 25 000 impulsi/km). Il fattore
fisso può essere programmato soltanto dal fabbricante
dell’adattatore e dall’officina autorizzata che monta l’adattatore.
▼B
4.2. Trasferimento degli impulsi in entrata al sensore di movimento incor­
porato
ADA_013 Gli impulsi in entrata, eventualmente adattati come sopra spe­
cificato, sono trasferiti al sensore di movimento incorporato in
modo tale che ogni impulso in entrata sia captato dal sensore di
movimento.
4.3. Sensore di movimento incorporato
ADA_014 Il sensore di movimento incorporato è stimolato dagli impulsi
trasferiti che gli permettono di generare dati di movimento che
rappresentano con accuratezza il movimento del veicolo come
se fosse meccanicamente collegato a una parte mobile dello
stesso.
ADA_015 I dati di identificazione del sensore di movimento incorporato
sono utilizzati dalla VU per identificare l'adattatore [95].
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 601
ADA_016 Si considera che i dati di montaggio contenuti nel sensore di
movimento incorporato rappresentino i dati di montaggio del­
l'adattatore [122].
4.4. Requisiti di sicurezza
ADA_017 L'alloggiamento dell'adattatore deve essere progettato in modo
che non sia possibile aprirlo. Esso deve essere sigillato in
modo da consentire di individuare agevolmente i tentativi di
manomissione fisica (ad esempio mediante ispezione visiva,
cfr. ADA_035). I sigilli devono soddisfare gli stessi requisiti
dei sigilli dei sensori di movimento [da 398 a 406].
ADA_018 Non deve essere possibile asportare dall'adattatore il sensore di
movimento incorporato senza manomettere il o i sigilli dell'al­
loggiamento dell'adattatore o il sigillo apposto tra l'alloggia­
mento del sensore e quello dell'adattatore (cfr. ADA_034).
ADA_019 L'adattatore garantisce che i dati di movimento possano essere
elaborati e ricavati soltanto in base all'input dell'adattatore.
4.5. Caratteristiche prestazionali
ADA_020 L'adattatore deve essere completamente funzionale nell'inter­
vallo di temperatura definito dal fabbricante.
ADA_021 L'adattatore deve essere in grado di funzionare correttamente
nel campo di umidità compreso tra 10 % e 90 % [214].
ADA_021 L'adattatore deve essere protetto contro sovratensione, inver­
sione di polarità dell'alimentazione e corto circuiti [216].
ADA_023 L'adattatore:
— deve reagire a un campo magnetico che disturba il rileva­
mento dei dati di movimento del veicolo. In queste circo­
stanze, l'unità elettronica di bordo del veicolo registra e
memorizza un guasto del sensore [88]; oppure
— deve disporre di un elemento di rilevazione protetto dai
campi magnetici o immune agli stessi [217].
ADA_024 L'adattatore deve essere conforme al regolamento internazio­
nale UNECE n. 10 concernente la compatibilità elettromagne­
tica e deve essere protetto contro le scariche elettrostatiche e i
transitori [218].
4.6. Materiali
ADA_025 L'adattatore deve essere conforme al grado di protezione (TBD
dal fabbricante in funzione della posizione di montaggio) [220,
221].
ADA_026 L'alloggiamento dell'adattatore deve essere di colore giallo.
4.7. Contrassegni
ADA_027 Sull'adattatore deve essere affissa una targhetta segnaletica
indicante:
— nome e indirizzo del fabbricante dell'adattatore;
— il codice componente del fabbricante e l'anno di fabbrica­
zione dell'adattatore;
— il marchio di omologazione del tipo di adattatore o del tipo
di apparecchio di controllo che comprende l'adattatore;
— la data in cui è stato montato l'adattatore;
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 602
— il numero di identificazione del veicolo su cui è stato
montato.
ADA_028 La targhetta segnaletica deve riportare inoltre le seguenti infor­
mazioni (se non sono direttamente leggibili all'esterno del sen­
sore di movimento incorporato):
— nome del fabbricante del sensore di movimento
incorporato;
— il codice componente del fabbricante e l'anno di fabbrica­
zione del sensore di movimento incorporato;
— il marchio di omologazione del sensore di movimento
incorporato.
5. MONTAGGIO DELL'APPARECCHIO DI CONTROLLO QUANDO È
UTILIZZATO UN ADATTATORE
5.1. Montaggio
ADA_029 Gli adattatori destinati al montaggio sui veicoli devono essere
installati esclusivamente dai costruttori dei veicoli o dalle offi­
cine autorizzate, abilitati a montare, attivare e tarare i tachigrafi
digitali e intelligenti.
ADA_030 Le officine abilitate che effettuano il montaggio dell'adattatore
regolano l'interfaccia di ingresso e selezionano il rapporto di
divisione del segnale di ingresso (se applicabile).
ADA_031 Le officine abilitate che effettuano il montaggio dell'adattatore
appongono i sigilli sull'alloggiamento dello stesso.
ADA_032 L'adattatore è montato quanto più vicino possibile alla parte del
veicolo che gli fornisce gli impulsi in entrata.
ADA_033 I cavi per l'alimentazione dell'adattatore devono essere di co­
lore rosso (polo positivo) e nero (terra).
5.2. Sigilli
ADA_034 Per quanto riguarda i sigilli, si applicano i seguenti requisiti:
— l'alloggiamento dell'adattatore deve essere sigillato (cfr.
ADA_017);
— l'alloggiamento del sensore incorporato deve essere sigillato
all'alloggiamento dell'adattatore, salvo nei casi in cui non
sia possibile rimuovere il sensore incorporato senza rom­
pere il o i sigilli dell'alloggiamento dell'adattatore (cfr.
ADA_018);
— l'alloggiamento dell'adattatore deve essere sigillato al
veicolo;
— il collegamento tra l'adattatore e l'apparecchiatura che gli
fornisce gli impulsi in entrata deve essere sigillato alle due
estremità (nella misura in cui ciò sia ragionevolmente pos­
sibile).
6. VERIFICHE, CONTROLLI E RIPARAZIONI
6.1. Controlli periodici
ADA_035 Quando viene utilizzato un adattatore, ogni ispezione periodica
dell'apparecchio di controllo (ispezione periodica conforme ai
requisiti da [409] a [413] dell'allegato 1C) deve verificare che:
— l'adattatore rechi i pertinenti marchi di omologazione;
— i sigilli sull'adattatore e sui suoi collegamenti siano integri;
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 603
— l'adattatore sia montato come indicato sulla targhetta di
montaggio;
— l'adattatore sia montato come specificato dal fabbricante
dell'adattatore e/o dal costruttore del veicolo;
— il montaggio dell'adattatore sia autorizzato per il veicolo
oggetto di ispezione.
ADA_036 Tali controlli devono prevedere una taratura e una sostituzione
dei sigilli indipendentemente dal loro stato.
7. OMOLOGAZIONE DELL'APPARECCHIO DI CONTROLLO QUANDO
È UTILIZZATO UN ADATTATORE
7.1. Prescrizioni generali
ADA_037 L'apparecchio di controllo deve essere presentato all'omologa­
zione completo e munito dell'adattatore [425].
ADA_038 Qualsiasi adattatore può essere presentato all'omologazione in
quanto tale o come componente dell'apparecchio di controllo.
ADA_039 Tale omologazione deve includere prove funzionali dell'adatta­
tore. I risultati positivi di ciascuna di queste prove vanno ri­
portati su un apposito certificato [426].
7.2. Certificato funzionale
ADA_040 Al fabbricante dell'adattatore viene rilasciato un certificato fun­
zionale relativo all'adattatore o all'apparecchio di controllo
comprendente un adattatore solo se tutte le seguenti prove
funzionali minime hanno dato esito positivo.
N. Prova Descrizione Requisiti applicabili
1. Esame amministrativo
1.1 Documentazione Validità della docu­
mentazione del­
l'adattatore
2. Controllo visivo
2.1. Conformità dell'adattatore con la documentazione
2.2. Identificazione/marcatura dell'adattatore ADA_027,
ADA_028
2.3 Materiali dell'adattatore dal [219] al [223]
ADA_026
2.4. Sigilli ADA_017,
ADA_018,
ADA_034
3. Prove funzionali
3.1 Trasferimento degli impulsi di velocità al sensore
di movimento incorporato
ADA_013
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 604
N. Prova Descrizione Requisiti applicabili
3.2 Interfaccia e adattamento degli impulsi di velo­
cità in entrata
ADA_011,
ADA_012
3.3 Precisione della misurazione del movimento da [30] a [35], [217]
4. Prove ambientali
4.1 Risultati delle prove fab­
bricante
Risultati delle prove
ambientali del fab­
bricante
ADA_020,
ADA_021,
ADA_022,
ADA_024
5. EMC
5.1 Emissioni irradiate e sen­
sibilità ai disturbi
Verifica della con­
formità con la diret­
tiva 2006/28/CE
ADA_024
5.2 Risultati delle prove fab­
bricante
Risultati delle prove
ambientali del fab­
bricante
ADA_024
▼B
02016R0799 — IT — 21.08.2023 — 003.002 — 605
Appendice 17
DISPOSIZIONI TRANSITORIE RELATIVE ALL’USO DELL’OSNMA
DA PARTE DEI TACHIGRAFI
1. DEFINIZIONI E ACRONIMI
1.1. Definizioni
Dichiarazione di servizio del servizio aperto di autenticazione dei mes­
saggi di navigazione (OSNMA) di Galileo: la dichiarazione della Com­
missione europea che stabilisce l’entrata dell’OSNMA di Galileo nella sua
fase operativa.
Unità elettronica di bordo di transizione: un’unità elettronica di bordo
conforme alle disposizioni della presente appendice.
Le unità elettroniche di bordo di transizione sono costruite conformemente
al SIS ICD e agli orientamenti sui ricevitori OSNMA applicabili alla fase
di prova pubblica dell’OSNMA. Contengono un ricevitore GNSS in grado
di utilizzare l’OSNMA disponibile durante la fase di prova pubblica.
Le unità elettroniche di bordo di transizione non sono tuttavia in grado di
autenticare i messaggi di navigazione disponibili dopo la dichiarazione di
servizio OSNMA, a causa del necessario aggiornamento del materiale
crittografico nell’unità elettronica di bordo. È necessario applicare un
adeguato aggiornamento software, in modo che tali unità elettroniche
possano iniziare a utilizzare l’OSNMA e soddisfare tutti i requisiti
dell’allegato IC e delle relative appendici da 1 a 16. Prima dell’aggiorna­
mento, le unità elettroniche di bordo di transizione implementano le fun­
zionalità relative all’OSNMA come specificato nella presente appendice.
Le funzionalità non relative all’OSNMA rimangono invariate.
Se viene applicato l’adeguato aggiornamento software, le unità elettroni­
che di bordo di transizione implementano il SIS ICD e gli orientamenti sui
ricevitori OSNMA applicabili alla fase operativa dell’OSNMA e soddi­
sfano tutti i requisiti dell’allegato IC e delle relative appendici da 1 a 16,
utilizzando l’OSNMA disponibile durante la fase operativa.
Tachigrafo di transizione: un tachigrafo comprendente un’unità elettro­
nica di bordo di transizione.
1.2. Acronimi
ICD Documento di controllo dell’interfaccia (Interface
Control Document)
OSNMA Servizio aperto di autenticazione dei messaggi di
navigazione (Open Service Navigation Message
Authentication) di Galileo
SIS Segnale nello spazio (Signal in Space)
VU Unità elettronica di bordo (Vehicle Unit)
▼M4
02016R0799 — IT — 21.08.2023 — 003.002 — 606
2. CONSIDERAZIONI GENERALI RELATIVE ALL’OSNMA
Al fine di consentire ai veicoli immatricolati per la prima volta di essere
muniti della versione 2 dei tachigrafi di seconda generazione, a partire
dalla data di introduzione richiesta di cui all’allegato IC, sezione 1,
lettera ccc), del regolamento di esecuzione (UE) 2016/799, è necessario
omologare, produrre e commercializzare le unità elettroniche di bordo
prima della dichiarazione di servizio OSNMA. Per tali unità elettroniche
di bordo, denominate unità elettroniche di bordo di transizione, i requisiti
relativi all’OSNMA dell’allegato IC e delle relative appendici da 1 a 16
devono essere adattati in modo che tali unità possano essere omologate e
utilizzate sul campo.
Le disposizioni di cui alla presente appendice definiscono i requisiti spe­
cifici applicabili alle unità elettroniche di bordo di transizione. Esse si
applicano solo alle unità elettroniche di bordo dotate di ricevitore GNSS
interno.
3. REQUISITI APPLICABILI AL RICEVITORE GNSS DEI TACHIGRAFI
DI TRANSIZIONE
TRA_001 Le unità elettroniche di bordo di transizione devono compren­
dere un ricevitore GNSS in grado di utilizzare l’OSNMA disponibile
durante la sua fase di prova pubblica.
TRA_002 I requisiti dell’appendice 12 si applicano al ricevitore GNSS
incluso nelle unità elettroniche di bordo di transizione con le seguenti
interpretazioni:
— il SIS ICD e gli orientamenti per ricevitori OSNMA cui si fa riferi­
mento sono i documenti disponibili per la fase di prova pubblica:
— Galileo Open Service Navigation Message Authentication
(OSNMA) User ICD for the Test Phase (IDC dell’utente
dell’OSNMA di Galileo per la fase di prova), numero 1.0, novem­
bre 2021,
— Galileo Open Service Navigation Message Authentication
(OSNMA) Receiver Guidelines for the Test Phase (orientamenti
per ricevitori OSNMA di Galileo per la fase di prova), numero
1.0, novembre 2021;
— OSNMA è il servizio disponibile durante la fase di prova pubblica;
— SIS è il segnale nello spazio disponibile durante la fase di prova
pubblica.
TRA_003 Il ricevitore GNSS incluso nelle unità elettroniche di bordo di
transizione deve essere progettato in modo che, in seguito a un aggiorna­
mento del suo software, applicato mediante un aggiornamento del software
dell’unità elettronica di bordo, sia pienamente conforme ai requisiti
dell’allegato 12, utilizzando l’OSNMA disponibile durante la sua fase
operativa.
4. REQUISITI APPLICABILI ALLE UNITÀ ELETTRONICHE DI
BORDO DI TRANSIZIONE
Le unità elettroniche di bordo di transizione possono elaborare il segnale
OSNMA disponibile durante la sua fase di prova pubblica, ma non sono in
grado di segnalare lo stato di autenticazione dei messaggi di navigazione
del SIS disponibile durante la fase operativa dell’OSNMA fino a che non
viene applicato un adeguato aggiornamento software. Esse pertanto riten­
gono che le posizioni standard fornite dal ricevitore GNSS siano sempre
autenticate.
I requisiti dell’allegato IC e delle relative appendici da 1 a 16 si applicano
con le seguenti interpretazioni.
▼M4
02016R0799 — IT — 21.08.2023 — 003.002 — 607
TRA_004 Nell’allegato IC, punto 3.9.15 Anomalia «Conflitto di orari», il
requisito 86 è da intendersi nel modo seguente:
Questa anomalia deve attivarsi, quando non è attivo il modo taratura,
qualora la VU rilevi una discrepanza tra l’orario della funzione di misu­
razione del tempo dell’unità elettronica di bordo e l’orario proveniente
dalle posizioni standard trasmesse dal ricevitore GNSS o dal dispositivo
GNSS esterno. Si rileva una «discrepanza di orario» se la differenza tra
gli orari è superiore a ± 3 secondi, corrispondente all’accuratezza di cui
al requisito 41 bis; quest’ultima è aumentata dello sfasamento massimo
dell’ora giornaliero. Questa anomalia deve essere registrata insieme al
valore dell’orologio interno dell’apparecchio di controllo. La VU deve
effettuare il controllo per attivare l’anomalia «Conflitto di orari» subito
prima di regolare automaticamente il suo orologio interno, in conformità
al requisito 211.
TRA_005 Nell’allegato IC, punto 3.9.18 Anomalia «Anomalia GNSS», il
requisito 88 bis è da intendersi nel modo seguente:
Questa anomalia deve attivarsi, quando non è attivo il modo taratura,
qualora il ricevitore GNSS rilevi un attacco , come specificato nell’appen­
dice 12. Dopo che si è attivata un’anomalia di tipo «Anomalia GNSS» , la
VU non deve generare anomalie GNSS per i successivi 10 minuti.
TRA_006 Nell’allegato IC, Registrazione e memorizzazione nella memo­
ria di dati, punto 3.12.5 Luoghi e posizioni dove iniziano e terminano i
periodi di lavoro giornalieri e/o dove il periodo di guida cumulativo
raggiunge le 3 ore, il requisito 110 è da intendersi nel modo seguente:
Insieme a ciascun luogo o posizione, l’apparecchio di controllo deve
registrare e memorizzare nella sua memoria di dati:
— il numero della carta del conducente e/o del secondo conducente e lo
Stato membro che l’ha rilasciata,
— la generazione della carta,
— la data e l’ora d’immissione dei dati,
— il tipo di immissione (inizio, fine o 3 ore di periodo di guida cumu­
lativo),
— l’accuratezza del GNSS, la data e l’ora pertinenti, se applicabili,
— il valore dell’odometro del veicolo,
— un indicatore che segnali che la posizione è stata ritenuta autenticata.
TRA_007 Nell’allegato IC, Registrazione e memorizzazione nella memo­
ria di dati, punto 3.12.17 Attraversamenti di frontiera, il requisito 133 ter è
da intendersi nel modo seguente:
Insieme ai paesi e alla posizione, l’apparecchio di controllo deve regi­
strare e memorizzare nella sua memoria di dati:
— il numero della carta del conducente e/o del secondo conducente e lo
Stato membro che l’ha rilasciata,
— la generazione della carta,
— l’accuratezza del GNSS, la data e l’ora pertinenti,
— un indicatore che segnali che la posizione è stata ritenuta autenticata,
— il valore dell’odometro del veicolo al momento del rilevamento dell’at­
traversamento della frontiera.
▼M4
02016R0799 — IT — 21.08.2023 — 003.002 — 608
TRA_008 Nell’allegato IC, Registrazione e memorizzazione nella memo­
ria di dati, punto 3.12.18 Operazioni di carico/scarico, il requisito 133 oc­
ties è da intendersi nel modo seguente:
Insieme al tipo di operazione e alla posizione, l’apparecchio di controllo
deve registrare e memorizzare nella sua memoria di dati:
— il numero della carta del conducente e/o del secondo conducente e lo
Stato membro che l’ha rilasciata,
— la generazione della carta,
— la data e l’ora dell’operazione di carico/scarico,
— l’accuratezza del GNSS, la data e l’ora pertinenti, se applicabili,
— un indicatore che segnali che la posizione è stata ritenuta autenticata,
— il valore dell’odometro del veicolo.
TRA_009 Nell’allegato IC, punto 3.23 Regolazione dell’ora, il requisito
211 è da intendersi nel modo seguente:
Le impostazioni dell’ora dell’orologio interno della VU devono essere
regolate automaticamente a intervalli di tempo variabili. La successiva
regolazione automatica dell’ora deve attivarsi tra 72 e 168 ore dopo la
precedente e dopo che la VU ha potuto accedere all’ora del GNSS me­
diante un messaggio di posizione standard valido in conformità all’appen­
dice 12. La regolazione dell’ora non deve tuttavia mai essere superiore
allo sfasamento massimo cumulativo giornaliero dell’ora, come calcolato
dal fabbricante della VU conformemente al requisito 41 ter. Se la diffe­
renza tra l’ora dell’orologio interno della VU e l’ora del ricevitore GNSS
è superiore allo sfasamento massimo cumulativo giornaliero dell’ora, la
regolazione dell’ora deve avvicinare il più possibile l’ora dell’orologio
interno della VU all’ora del ricevitore GNSS. L’impostazione dell’ora può
essere effettuata solo se l’ora indicata dal ricevitore GNSS è ottenuta
utilizzando messaggi di posizione standard come indicato nell’appendice
12. Il riferimento temporale per l’impostazione automatica dell’ora
dell’orologio interno della VU deve essere costituito dall’ora fornita dal
messaggio di posizione standard.
TRA_010 Nell’allegato IC, punto 3.23 Regolazione dell’ora, il requisito
212 è da intendersi nel modo seguente:
La funzione di regolazione dell’ora deve anche consentire la regolazione
dell’ora corrente in modo mirato, nel modo taratura.
Le officine possono regolare l’ora:
— scrivendo un valore temporale nella VU utilizzando il servizio Write­
DataByIdentifier conformemente alla sezione 6.2 dell’appendice 8,
— oppure richiedendo un allineamento dell’orologio della VU all’ora
fornita dal ricevitore GNSS. Ciò è possibile solo se l’ora indicata
dal ricevitore GNSS è ottenuta utilizzando messaggi di posizione stan­
dard. In quest’ultimo caso deve essere utilizzato il servizio Routine­
Control conformemente alla sezione 8 dell’appendice 8.
▼M4
02016R0799 — IT — 21.08.2023 — 003.002 — 609
TRA_011 Nell’appendice 4, punto 2 Specifiche dei blocchi di dati, primo
comma, il settimo trattino è da intendersi nel modo seguente:
se stampato dopo la longitudine e la latitudine di una posizione registrata
o dopo la marcatura oraria (timestamp) relativa al momento della deter­
minazione della posizione, il pittogramma indica che tale posizione è
stata ritenuta autentica.
TRA_012 Nell’appendice 8, Servizio RoutineControl (regolazione
dell’ora), punto 8.1 Descrizione del messaggio, il requisito CPR_065a è
da intendersi nel modo seguente:
Il servizio RoutineControl (TimeAdjustment) garantisce la capacità di
attivare un allineamento dell’orologio della VU all’ora fornita dal rice­
vitore GNSS.
Ai fini dell’esecuzione del servizio RoutineControl (TimeAdjustment) la
VU deve essere in modo TARATURA.
Precondizione: è garantito che la VU sia in grado di ricevere messaggi di
posizione standard provenienti dal ricevitore GNSS.
Finché è in corso la regolazione dell’ora, la VU deve rispondere alla
richiesta RoutineControl, sottofunzione requestRoutineResults, con routi­
neInfo = 0x78.
Nota: la regolazione dell’ora può richiedere tempo. Il tester diagnostico
deve richiedere lo stato della regolazione dell’ora utilizzando la sottofun­
zione requestRoutineResults.
TRA_013 Nell’appendice 12, punto 3 Frasi fornite dal ricevitore GNSS,
il requisito GNS_4a è da intendersi nel modo seguente:
I dati contenuti nelle frasi AMC fornite dal ricevitore GNSS non devono
essere utilizzati dall’unità elettronica di bordo, ad eccezione dei seguenti
valori dello stato:
J = Jamming o O = altro attacco al GNSS (mediante controlli di coerenza
attuati conformemente al GNS_3a),
V = Void (nullo; la posizione autenticata non è disponibile per altri
motivi).
TRA_014 Nell’appendice 12, punto 3 Frasi fornite dal ricevitore GNSS,
il requisito GNS_5 è da intendersi nel modo seguente:
I dati contenuti nelle frasi ASA fornite dal ricevitore GNSS non devono
essere utilizzati dall’unità elettronica di bordo.
TRA_015 Nell’appendice 12, Unità elettronica di bordo senza dispositivo
GNSS esterno, punto 5.2 Trasferimento di informazioni dal ricevitore
GNSS alla VU, i requisiti GNS_34 e 36 sono da intendersi nel modo
seguente:
Il processore della VU non deve utilizzare informazioni estratte dalla
frase AMC, ad eccezione dei seguenti valori dello stato:
J = Jamming o O = altro attacco al GNSS (mediante controlli di coerenza
attuati conformemente al GNS_3a),
V = Void (nullo; la posizione autenticata non è disponibile per altri
motivi).
Il processore della VU non deve utilizzare informazioni estratte dalla
frase ASA.
▼M4
02016R0799 — IT — 21.08.2023 — 003.002 — 610
TRA_016 Nell’appendice 12, punto 6 Elaborazione e registrazione dei
dati sulla posizione da parte della VU, il requisito GNS_39 è da intendersi
nel modo seguente:
I dati sulla posizione devono essere memorizzati nella VU, insieme a un
indicatore che segnali se la posizione è ritenuta autenticata. Quando è
necessario registrare i dati sulla posizione nella VU deve applicarsi la
regola seguente:
a) se la posizione standard è valida, la posizione standard e la sua
accuratezza devono essere registrate nella VU e l’indicatore deve es­
sere impostato su «autenticata».
TRA_017 Nell’appendice 12, punto 6 Elaborazione e registrazione dei
dati sulla posizione da parte della VU, il requisito GNS_40 è da intendersi
nel modo seguente:
Quando il valore dello stato in una frase AMC ricevuta è impostato su
«J» o «O» in conformità al requisito GNS_4a, la VU deve generare e
registrare un’anomalia di tipo «Anomalia GNSS» , come definita al re­
quisito 88 bis dell’allegato IC e all’appendice 1 (EventFaultType). L’unità
elettronica di bordo può effettuare verifiche supplementari prima di me­
morizzare un’anomalia di tipo «Anomalia GNSS» dopo la ricezione di un
valore impostato su «J» o «O».
TRA_018 Nell’appendice 12, punto 8 Dati contrastanti sul movimento del
veicolo, requisito GNS_42, condizione di attivazione 2, il primo e il se­
condo trattino dopo la formula sono da intendersi nel modo seguente:
— GnssDistance è la distanza tra la posizione corrente del veicolo e
quella precedente, entrambe ottenute da messaggi di posizione stan­
dard validi, senza considerare l’altezza,
— OdometerDifference è la differenza tra il valore corrente dell’odome­
tro e il valore dell’odometro corrispondente al precedente messaggio
di posizione standard valido.
TRA_019 Nell’appendice 14, Requisiti del protocollo DSRC per l’RTM,
punto 5.4.5 Elementi di RtmData, azioni eseguite e definizioni, requisito
DSC_41, tabella 14.3, la seconda cella nella riga RTM20, è da intendersi
nel modo seguente:
La VU deve generare un valore intero (timeReal dall’appendice 1) per
l’elemento di dati RTM20.
La VU deve impostare il valore di RTM20 sull’ora in cui il ricevitore
GNSS ha reso disponibile la più recente posizione standard del veicolo.
Se il ricevitore GNSS non ha reso disponibile nessuna posizione standard
del veicolo, la VU deve impostare il valore di RTM20 su 0.
TRA_020 Il fabbricante di un’unità elettronica di bordo di transizione
omologata deve comunicare alla Commissione le sue versioni del soft­
ware. La Commissione deve pubblicare tali versioni del software su un
sito web accessibile al pubblico.
▼M4
02016R0799 — IT — 21.08.2023 — 003.002 — 611
5. DISPOSIZIONI SPECIFICHE PER L’OMOLOGAZIONE E L’USO DI
TACHIGRAFI DI TRANSIZIONE
TRA_021 Le unità elettroniche di bordo di transizione devono essere
omologate conformemente ai requisiti dell’allegato IC e delle relative
appendici da 1 a 16, integrate dalle disposizioni della presente appendice.
TRA_022 I certificati di omologazione delle unità elettroniche di bordo di
transizione e dei tachigrafi di transizione possono essere richiesti solo fino
al 31 dicembre 2023 o fino alla data della dichiarazione di servizio
OSNMA, se successiva.
TRA_023 Le unità elettroniche di bordo di transizione possono essere
montate su veicoli immatricolati per la prima volta solo fino al 31 maggio
2024 o fino a 5 mesi dopo la data della dichiarazione di servizio OSNMA,
se successiva.
▼M4
02016R0799 — IT — 21.08.2023 — 003.002 — 612
ALLEGATO II
MARCHIO E SCHEDA DI OMOLOGAZIONE
I. MARCHIO DI OMOLOGAZIONE
1. Il marchio di omologazione è composto:
a) da un rettangolo, all'interno del quale si trova la lettera «e» seguita da un
numero distintivo o da una lettera distintiva del paese che ha rilasciato
l'omologazione, come segue:
Belgio 6,
Bulgaria 34,
Repubblica ceca 8,
Danimarca 18,
Germania 1,
Estonia 29,
Irlanda 24,
Grecia 23,
Spagna 9,
Francia 2,
Croazia 25,
Italia 3,
Cipro CY,
Lettonia 32,
Lituania 36,
Lussemburgo 13,
Ungheria 7,
Malta MT,
Paesi Bassi 4,
Austria 12,
Polonia 20,
Portogallo 21,
Romania 19,
Slovenia 26,
Slovacchia 27,
Finlandia 17,
Svezia 5,
Regno Unito 11,
e
▼M1
b) da un numero di omologazione corrispondente al numero della scheda di
omologazione stabilita per il prototipo dell’apparecchio di controllo o del
foglio di registrazione o della carta tachigrafica, posto in una posizione
qualsiasi in prossimità di tale rettangolo.
▼C1
02016R0799 — IT — 21.08.2023 — 003.002 — 613
2. Il marchio di omologazione è apposto sulla targhetta segnaletica di ciascun
apparecchio, su ciascun foglio di registrazione e su ogni carta tachigrafica.
Esso deve essere indelebile e rimanere sempre ben leggibile.
3. Le dimensioni del marchio di omologazione disegnate di seguito ( 1 ) sono
espresse in millimetri e rappresentano dei minimi. Si devono rispettare i
rapporti fra queste dimensioni.
▼C1
( 1 ) Queste cifre sono riportate unicamente a titolo indicativo.
02016R0799 — IT — 21.08.2023 — 003.002 — 614
II. SCHEDA DI OMOLOGAZIONE DEI TACHIGRAFI ANALOGICI
Lo Stato membro che ha rilasciato l'omologazione, rilascia al richiedente una
scheda di omologazione, il cui modello è riprodotto di seguito. Per la notifica
agli altri Stati membri delle omologazioni rilasciate o eventualmente revocate,
ciascuno Stato membro deve utilizzare copie di tale scheda.
SCHEDA DI OMOLOGAZIONE
Nome dell'amministrazione competente
Notifica concernente ( 1 ):
— l'omologazione di un tipo di apparecchio di controllo
— la revoca dell'omologazione di un tipo di apparecchio di controllo
— l'omologazione di un modello di foglio di registrazione
— la revoca dell'omologazione di un modello di foglio di registrazione
Omologazione n.:
...................................
1. Marchio o denominazione commerciale
2. Denominazione del tipo o del modello
3. Denominazione del costruttore
4. Indirizzo del costruttore
5. Data di presentazione per l'omologazione
6. Laboratorio di prova
7. Data e numero della/e prova/e
8. Data dell'omologazione
9. Data della revoca dell'omologazione
10. Tipo/i di apparecchi di controllo nel/i quale/i il foglio è destinato ad essere
utilizzato
11. Luogo
12. Data
13. Documenti illustrativi allegati
14. Osservazioni (compresa la posizione dei sigilli, ove applicabile)
(Firma)
▼C1
( 1 ) Cancellare le diciture non pertinenti.
02016R0799 — IT — 21.08.2023 — 003.002 — 615
III. SCHEDA DI OMOLOGAZIONE DEI TACHIGRAFI DIGITALI
Lo Stato membro che ha rilasciato l'omologazione, rilascia al richiedente una
scheda di omologazione, il cui modello è riprodotto di seguito. Per la notifica
agli altri Stati membri delle omologazioni rilasciate o eventualmente revocate,
ciascuno Stato membro deve utilizzare copie di tale scheda.
SCHEDA DI OMOLOGAZIONE DEI TACHIGRAFI DIGITALI
Nome dell'amministrazione competente
Notifica concernente ( 1 ):
□ omologazione di: □ revoca dell'omologazione di:
□ modello di apparecchio di controllo
□ componente dell'apparecchio di controllo ( 2 )
□ una carta del conducente
□ una carta dell'officina
□ una carta dell'azienda
□ una carta dell'agente di controllo
Omologazione n.:
1. Marchio di fabbrica o denominazione commerciale
2. Nome del modello
3. Denominazione del costruttore
4. Indirizzo del costruttore
▼M1
5. Presentato all’omologazione il
▼C1
6. Laboratorio/i
7. Data e numero del verbale di prova
8. Data dell'omologazione
9. Data della revoca dell'omologazione
10. Modello di apparecchio/i di controllo con cui il componente è destinato ad
essere utilizzato
11. Luogo
12. Data
13. Documenti illustrativi allegati
14. Osservazioni (compresa la posizione dei sigilli, ove applicabile)
(Firma)
▼C1
( 1 ) Barrare le caselle appropriate.
( 2 ) Specificare il componente oggetto della notifica.
02016R0799 — IT — 21.08.2023 — 003.002 — 616
IV. SCHEDA DI OMOLOGAZIONE DEI TACHIGRAFI INTELLIGENTI
Lo Stato membro che ha rilasciato l'omologazione, rilascia al richiedente una
scheda di omologazione, il cui modello è riprodotto di seguito. Per la notifica
agli altri Stati membri delle omologazioni rilasciate o eventualmente revocate,
ciascuno Stato membro deve utilizzare copie di tale scheda.
SCHEDA DI OMOLOGAZIONE DEI TACHIGRAFI INTELLIGENTI
Nome dell'amministrazione competente
Notifica concernente ( 1 ):
□ omologazione di: □ revoca dell'omologazione di:
□ modello di apparecchio di controllo
□ componente dell'apparecchio di controllo ( 2 )
□ una carta del conducente
□ una carta dell'officina
□ una carta dell'azienda
□ una carta dell'agente di controllo
Omologazione n.:
1. Marchio di fabbrica o denominazione commerciale
2. Nome del modello
3. Denominazione del costruttore
4. Indirizzo del costruttore
▼M1
5. Presentato all’omologazione il
▼C1
6. a) Laboratorio di prova per la certificazione funzionale
b) Laboratorio di prova per la certificazione della sicurezza
c) Laboratorio di prova per la certificazione dell'interoperabilità
7. a) Data e numero del certificato funzionale
b) Data e numero del certificato di sicurezza
c) Data e numero del certificato di interoperabilità
8. Data dell'omologazione
9. Data della revoca dell'omologazione
10. Modello di apparecchio/i di controllo con cui il componente è destinato ad
essere utilizzato
11. Luogo
12. Data
13. Documenti illustrativi allegati
14. Osservazioni (compresa la posizione dei sigilli, ove applicabile)
(Firma)
▼C1
( 1 ) Barrare le caselle appropriate.
( 2 ) Specificare il componente oggetto della notifica.


Full & Egal Universal Law Academy