Acest document are doar scop informativ și nu produce efecte juridice. Institu țiile Uniunii nu î și asumă răspunderea pentru 
conținutul său. Versiunile autentice ale actelor relevante, inclusiv preambulul acestora, sunt cele publicate în Jurnalul Oficial 
al Uniunii Europene și disponibile pe site-ul EUR-Lex. Aceste texte oficiale pot fi consultate accesând linkurile integrate în 
prezentul document.  
►B REGULAMENTUL DE PUNERE ÎN APLICARE (UE) 2016/799 AL COMISIEI  
din 18 martie 2016  
de punere în aplicare a Regulamentului (UE) nr. 165/2014 al Parlamentului European și al 
Consiliului de stabilire a cerin țelor pentru construirea, testarea, instalarea, operarea și 
repararea tahografelor și a componentelor acestora  
(Text cu relevan ță pentru SEE)  
(JO L 139, 26.5.2016, p. 1)  
Astfel cum a fost modificat prin:  
Jurnalul Oficial  
NR. Pagina  Data  
►M1 Regulamentul de punere în aplicare (UE) 2018/502 al Comisiei din 
28 februarie 2018  L 85  1  28.3.2018  
►M2 Regulamentul de punere în aplicare (UE) 2020/158 al Comisiei din 
5 februarie 2020  L 34  20  6.2.2020  
rectificat prin:  
►C1 Rectificare, JO L 146, 3.6.2016, p. 31 (2016/799)  
►C2 Rectificare, JO L 27, 1.2.2017, p. 169 (2016/799)  02016R0799 — RO — 26.02.2020 — 002.001 — 1
02016R0799 — RO — 26.02.2020 — 002.001 — 2  
REGULAMENTUL DE PUNERE ÎN APLICARE (UE) 2016/799 
AL COMISIEI  
din 18 martie 2016  
de punere în aplicare a Regulamentului (UE) nr. 165/2014 al 
Parlamentului European și al Consiliului de stabilire a cerin țelor 
pentru construirea, testarea, instalarea, operarea și repararea 
tahografelor și a componentelor acestora  
(Text cu relevan ță pentru SEE)  
Articolul 1  
Obiect și domeniu de aplicare  
(1) Prezentul regulament stabile ște dispozi țiile necesare pentru 
aplicarea uniform ă a următoarelor aspecte referitoare la tahografe:  
(a) înregistrarea pozi ției vehiculului în anumite puncte în timpul zilei de 
lucru a conduc ătorului auto;  
(b) detectarea timpurie la distan ță a posibilelor manipul ări sau utiliz ări 
abuzive ale tahografelor inteligente;  
(c) interfa ța cu sistemele de transport inteligente;  
(d) cerințele administrative și tehnice pentru procedurile de omologare 
de tip a tahografelor, inclusiv a mecanismelor de securitate.  
▼M1 
(2) Construirea, testarea, instalarea, inspectarea, operarea și repararea 
tahografelor inteligente și a componentelor acestora trebuie s ă respecte 
cerințele tehnice stabilite în anexa IC la prezentul regulament.  
(3) Celelalte tahografe, în afara tahografelor inteligente, trebuie s ă 
respecte în continuare, în ceea ce prive ște construirea, testarea, insta ­
larea, inspectarea, operarea și repararea, cerin țele din anexa I la Regu ­
lamentul (UE) nr. 165/2014 sau din anexa IB la Regulamentul (CEE) 
nr. 3821/85 al Consiliului (  1 ), după caz.  
▼B 
(4) În temeiul articolului 10d din Directiva 96/53/CE, echipamentul 
de detectare timpurie la distan ță trebuie s ă transmită, de asemenea, 
datele referitoare la greutate furnizate de un sistem intern de cânt ărire 
la bord, în scopul detect ării timpurii a fraudelor.  
▼M1 
(5) Prezentul regulament nu aduce atingere Directivei 2014/53/UE a 
Parlamentului European și a Consiliului (  2 ). 
▼B 
Articolul 2  
Definiții 
În scopul prezentului regulament, se aplic ă definițiile prevăzute la 
articolul 2 din Regulamentul (UE) nr. 165/2014.  ▼B 
( 1 ) Regulamentul (CEE) nr. 3821/85 al Consiliului din 20 decembrie 1985 
privind aparatura de înregistrare în transportul rutier (JO L 370, 31.12.1985, 
p. 8). 
( 2 ) Directiva 2014/53/UE a Parlamentului European și a Consiliului din 16 aprilie 
2014 privind armonizarea legisla ției statelor membre referitoare la punerea la 
dispoziție pe pia ță a echipamentelor radio și de abrogare a Directivei 
1999/5/CE (JO L 153, 22.5.2014, p. 62).
 02016R0799 — RO — 26.02.2020 — 002.001 — 3  
În plus, se aplic ă următoarele defini ții: 
1. „tahograf digital” sau „tahograf de prim ă generație” înseamn ă un 
tahograf digital care nu este un tahograf inteligent;  
2. „echipament GNSS extern” înseamn ă un echipament care con ține 
receptorul GNSS atunci când unitatea montat ă pe vehicul nu este o 
unitate compact ă, precum și alte componente necesare pentru 
protecția comunic ării datelor de pozi ționare către restul unit ății 
montate pe vehicul;  
▼M1 
3. „dosar informativ” înseamn ă dosarul complet, în format electronic 
sau pe hârtie, care con ține toate informa țiile furnizate de produc ător 
sau de agentul s ău autorității de omologare de tip în scopul 
omologării de tip a unui tahograf sau a unei componente a 
acestuia, inclusiv certificatele men ționate la articolul 12 alineatul 
(3) din Regulamentul (UE) nr. 165/2014, rezultatele testelor definite 
în anexa IC la prezentul regulament, precum și schițe, fotografii și 
alte documente relevante;  
▼B 
4. „dosar de omologare” înseamn ă dosarul informativ, în format elec ­
tronic sau pe hârtie, înso țit de orice alte documente ad ăugate de 
autoritatea de omologare de tip la dosarul informativ în cursul 
exercitării funcțiilor sale, inclusiv, la sfâr șitul procesului de 
omologare de tip, certificatul de omologare CE de tip a tahografului 
sau a unei componente a acestuia;  
5. „opisul dosarului de omologare” înseamn ă documentul care 
enumeră conținutul numerotat al dosarului de omologare, care iden ­
tifică toate părțile relevante din acest dosar. Formatul acestui 
document eviden țiază etapele succesive ale procesului de 
omologare CE de tip și include datele de revizuire și de actualizare 
a dosarului respectiv;  
6. „echipament de detectare timpurie la distan ță” înseamnă aparatura 
unității montate pe vehicul care este folosit ă pentru efectuarea de 
controale selective în trafic;  
▼M1 
7. „tahograf inteligent” sau „tahograf de a doua genera ție” înseamn ă 
un tahograf digital care este în conformitate cu articolele 8, 9 și 10 
din Regulamentul (UE) nr. 165/2014, precum și cu anexa IC la 
prezentul regulament;  
8. „component ă a tahografului” înseamn ă oricare dintre urm ătoarele 
elemente: unitatea montat ă pe vehicul, senzorul de mi șcare, foaia de 
înregistrare, echipamentul GNSS extern și echipamentul extern de 
detectare timpurie la distan ță; 
▼B 
9. „autoritate de omologare de tip” înseamn ă autoritatea unui stat 
membru care are competen ța de a efectua omologarea de tip a 
tahografului sau a componentelor sale și de a desf ășura procesul 
de autorizare, precum și de a elibera și, dacă este cazul, de a retrage 
certificatele de omologare de tip, care ac ționează ca punct de 
contact cu autorit ățile de omologare de tip ale altor state membre 
și care garanteaz ă că producătorii își îndeplinesc obliga țiile în ceea 
ce privește conformitatea cu cerin țele prezentului regulament;  
▼M1 
10. „unitate montat ă pe vehicul” înseamn ă tahograful, cu excep ția 
senzorului de mi șcare și a cablurilor cu care este conectat 
senzorul de mi șcare.  
Aceasta poate fi format ă dintr-o singur ă unitate sau din mai multe 
unități distribuite în vehicul și include o unitate de procesare, o 
memorie de date, o func ție de măsurare a timpului, dou ă dispo­
zitive-interfa ță pentru cardul inteligent de conduc ător auto și de ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 4  
copilot, o imprimant ă, un ecran, conectori și dispozitive pentru 
introducerea de date de c ătre utilizator, un receptor GNSS și un 
echipament de comunicare la distan ță. 
Unitatea montat ă pe vehicul poate fi alc ătuită din următoarele 
componente care fac obiectul omolog ării de tip:  
— unitatea montat ă pe vehicul, ca o component ă separată (inclusiv 
receptorul GNSS și echipamentul de comunicare la distan ță; 
— corpul principal al unit ății montate pe vehicul (inclusiv echipa ­
mentul de comunicare la distan ță) și echipamentul GNSS 
extern;  
— corpul principal al unit ății montate pe vehicul (inclusiv 
receptorul GNSS) și echipamentul extern de comunicare la 
distanță; 
— corpul principal al unit ății montate pe vehicul, echipamentul 
GNSS extern și echipamentul extern de comunicare la distan ță. 
Dacă unitatea montat ă pe vehicul este compus ă din mai multe 
unități distribuite în vehicul, corpul principal al unit ății montate 
pe vehicul este unitatea care con ține unitatea de procesare, 
memoria de date și funcția de măsurare a timpului.  
„unitatea montat ă pe vehicul (VU)” se utilizeaz ă pentru a desemna 
„unitatea montat ă pe vehicul” sau „corpul principal al unit ății 
montate pe vehicul”.  
▼B 
Articolul 3  
Servicii bazate pe localizare  
(1) Produc ătorii trebuie s ă se asigure c ă tahografele inteligente sunt 
compatibile cu serviciile de pozi ționare furnizate de sistemele Galileo și 
Serviciul european geosta ționar mixt de navigare (EGNOS).  
(2) Pe lâng ă sistemele men ționate la alineatul (1), produc ătorii pot 
alege, de asemenea, s ă asigure compatibilitatea cu alte sisteme de 
navigație prin satelit.  
Articolul 4  
Procedura de omologare de tip a unui tahograf și a componentelor 
tahografului  
(1) Un produc ător sau agentul s ău trebuie s ă depună o cerere pentru 
omologarea de tip a unui tahograf, a oric ăreia dintre componentele 
acestuia sau a oric ărui grup de componente, la autorit ățile de 
omologare de tip desemnate de fiecare stat membru. Cererea const ă 
într-un dosar informativ care con ține informa țiile referitoare la fiecare 
dintre componentele vizate, inclusiv, acolo unde este cazul, certificatele 
de omologare de tip ale celorlalte componente necesare pentru a 
completa tahograful, precum și orice alte documente relevante.  
(2) Un stat membru acord ă omologarea de tip pentru orice tahograf, 
component ă sau grup de componente care respect ă cerințele adminis ­
trative și tehnice men ționate la articolul 1 alineatul (2) sau (3), dup ă caz. 
În acest caz, autoritatea de omologare de tip elibereaz ă solicitantului un 
certificat de omologare de tip care respect ă modelul stabilit în anexa II 
la prezentul regulament.  
(3) Autoritatea de omologare de tip poate solicita produc ătorului sau 
agentului acestuia s ă furnizeze orice informa ții suplimentare.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 5  
(4) Produc ătorul sau agentul s ău pune la dispozi ția autorităților de 
omologare de tip, precum și a entităților responsabile cu eliberarea 
certificatelor men ționate la articolul 12 alineatul (3) din Regulamentul 
(UE) nr. 165/2014, num ărul de tahografe sau de componente de 
tahograf care este necesar pentru a permite ca procedura de 
omologare de tip s ă se desfășoare în mod satisf ăcător. 
(5) În cazul în care produc ătorul sau agentul s ău dorește să obțină o 
omologare de tip a anumitor componente sau grupuri de componente ale 
unui tahograf, acesta furnizeaz ă autorităților de omologare de tip 
celelalte componente deja omologate de tip, precum și alte piese 
necesare pentru construirea tahografului complet, pentru a permite auto ­
rităților respective s ă efectueze testele necesare.  
Articolul 5  
Modificarea omolog ărilor de tip  
(1) Produc ătorul sau agentul s ău informeaz ă fără întârziere autori ­
tățile de omologare de tip care au acordat omologarea de tip ini țială, 
în legătură cu orice modificare a software-ului sau a hardware-ului 
tahografului sau a naturii materialelor utilizate la fabricarea acestuia 
care sunt înregistrate în dosarul de omologare, și depune o cerere de 
modificare a omolog ării de tip.  
(2) Autorit ățile de omologare de tip pot revizui sau extinde o 
omologare de tip existent ă, sau pot acorda o nou ă omologare de tip 
în funcție de natura și de caracteristicile modific ărilor.  
În cazul în care autoritatea de omologare de tip consider ă că modifi­
cările software-ului, ale hardware-ului tahografului sau ale naturii mate ­
rialelor utilizate la fabricarea acestuia sunt minore, are loc o „revizuire”. 
În astfel de cazuri, autoritatea de omologare de tip elibereaz ă docu­
mentele revizuite din dosarul de omologare, indicând natura modifi ­
cărilor realizate și data aprob ării lor. O versiune actualizat ă a 
dosarului de omologare într-o form ă consolidat ă, însoțită de o 
descriere detaliat ă a modific ărilor aduse, este suficient ă pentru a 
îndeplini aceast ă cerință. 
În cazul în care autoritatea de omologare de tip consider ă că modifi­
cările software-ului, ale hardware-ului tahografului sau ale naturii mate ­
rialelor utilizate la fabricarea acestuia sunt substan țiale, are loc o „extin ­
dere”. În astfel de cazuri, autoritatea de omologare de tip poate solicita 
să se efectueze noi teste și informeaz ă în mod corespunz ător produ­
cătorul sau agentul acestuia. Dac ă aceste teste sunt satisf ăcătoare, auto ­
ritatea de omologare de tip elibereaz ă un certificat de omologare de tip 
ce conține un num ăr care se refer ă la extinderea acordat ă. Certificatul de 
omologare de tip precizeaz ă motivul extinderii și data eliber ării. 
(3) În opisul dosarului de omologare se indic ă data celei mai recente 
extinderi sau revizuiri a omolog ării de tip sau data celei mai recente 
consolidări a versiunii actualizate a omolog ării de tip.  
(4) Este necesar ă o nouă omologare de tip atunci când modific ările 
aduse tahografului omologat de tip sau componentelor sale omologate 
de tip ar conduce la eliberarea unui nou certificat de securitate sau a 
unui nou certificat de interoperabilitate.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 6  
Articolul 6  
Intrare în vigoare  
Prezentul regulament intr ă în vigoare în a dou ăzecea zi de la data 
publicării în  Jurnalul Oficial al Uniunii Europene . 
Se aplică de la 2 martie 2016.  
▼M1 
Cu toate acestea, anexa IC se aplic ă de la 15 iunie 2019, cu excep ția 
apendicelui 16, care se aplic ă de la 2 martie 2016.  
▼B 
Prezentul regulament este obligatoriu în toate elementele sale și se 
aplică direct în toate statele membre.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 7  
ANEXA I C  
Cerințe privind construc ția, testarea, instalarea și inspecția 
INTRODUCERE  
1. DEFINI ȚII 
2. CARACTERISTICI ȘI FUNC ȚII GENERALE ALE 
APARATURII DE ÎNREGISTRARE  
2.1 Caracteristici generale  
2.2 Func ții 
2.3 Moduri de func ționare  
2.4 Securitate  
3. CERIN ȚE DE CONSTRUC ȚIE ȘI DE FUNC ȚIONARE APLI ­ 
CABILE APARATURII DE ÎNREGISTRARE  
3.1 Monitorizarea introducerii și retragerii cardurilor  
3.2 M ăsurarea vitezei, a pozi ției și a distanței 
3.2.1 M ăsurarea distan ței parcurse  
3.2.2 M ăsurarea vitezei  
3.2.3 M ăsurarea pozi ției 
3.3 M ăsurarea timpului  
3.4 Monitorizarea activit ăților conduc ătorului auto  
3.5 Monitorizarea regimului de conducere  
3.6 Înregistr ări realizate de conduc ătorii auto  
3.6.1 Înregistrarea locurilor în care încep și/sau se încheie zilele de lucru  
3.6.2 Introducerea manual ă a activităților conduc ătorului auto și acordul 
conducătorului auto pentru interfa ța ITS  
3.6.3 Înregistrarea condi țiilor specifice  
3.7 Gestionarea bloc ărilor efectuate de societate  
3.8 Monitorizarea activit ăților de control  
3.9 Detectarea evenimentelor și/sau a anomaliilor  
3.9.1 Evenimentul „Introducerea unui card nevalabil”  
3.9.2 Evenimentul „Conflict de carduri”  
3.9.3 Evenimentul „Suprapunere a timpului”  
3.9.4 Evenimentul „Conducere f ără un card adecvat”  
3.9.5 Evenimentul „Introducerea cardului în timpul conducerii”  
3.9.6 Evenimentul „Încheierea incorect ă a ultimei sesiuni”  
3.9.7 Evenimentul „Dep ășirea limitei de vitez ă” 
3.9.8 Evenimentul „Întreruperea aliment ării cu energie electric ă” 
3.9.9 Evenimentul „Eroare de comunicare cu echipamentul de comu ­ 
nicare la distan ță” 
3.9.10 Evenimentul „Absen ța informațiilor de pozi ționare de la receptorul 
GNSS”  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 8  
3.9.11 Evenimentul „Eroare de comunicare cu echipamentul GNSS 
extern”  
3.9.12 Evenimentul „Eroare privind datele de la senzorul de mi șcare”  
3.9.13 Evenimentul „Conflict privind deplasarea vehiculului”  
3.9.14 Evenimentul „Tentativ ă de încălcare a securit ății” 
3.9.15 Evenimentul „Conflict or ă” 
3.9.16 Anomalia „Card”  
3.9.17 Anomalia „Aparatura de înregistrare”  
3.10 Teste integrate și autoteste  
3.11 Citirea din memoria de date  
3.12 Înregistrarea și stocarea în memoria de date  
3.12.1 Date de identificare a aparaturii  
3.12.1.1 Date de identificare a unit ății montate pe vehicul  
3.12.1.2 Date de identificare a senzorului de mi șcare 
3.12.1.3 Date de identificare a sistemului global de naviga ție prin satelit  
3.12.2 Chei și certificate  
3.12.3 Date privind introducerea și retragerea cardului de conduc ător auto 
sau ale cardului de atelier  
3.12.4 Date privind activitatea conduc ătorului auto  
▼M1 
3.12.5 Locuri și poziții în care încep și se încheie zilele de lucru și/sau în 
care se atinge timpul de conducere acumulat de trei ore  
▼B 
3.12.6 Date privind odometrul  
3.12.7 Date privind viteza detaliat ă 
3.12.8 Date privind evenimentele  
3.12.9 Date privind anomaliile  
3.12.10 Date privind etalonarea  
3.12.11 Date privind reglarea orei  
3.12.12 Date privind activit ățile de control  
3.12.13 Date privind bloc ările efectuate de societate  
3.12.14 Date privind activit ățile de desc ărcare  
3.12.15 Date privind condi țiile specifice  
3.12.16 Date privind cardul de tahograf  
3.13 Citirea de pe cardurile de tahograf  
3.14 Înregistrarea și stocarea pe cardurile de tahograf  
3.14.1 Înregistrarea și stocarea pe cardurile de tahograf de prim ă generație; 
3.14.2 Înregistrarea și stocarea pe cardurile de tahograf de a doua 
generație 
3.15 Afi șare 
3.15.1 Afi șaj implicit  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 9  
3.15.2 Afi șaj de avertizare  
3.15.3 Accesul la meniu  
3.15.4 Alte afi șaje 
3.16 Imprimare  
3.17 Avertismente  
3.18 Desc ărcarea datelor pe suporturi externe  
3.19 Comunicare la distan ță pentru controalele selective în trafic  
3.20 Date de ie șire transmise unor dispozitive externe suplimentare  
3.21 Etalonare  
3.22 Verificarea etalon ării în trafic  
3.23 Reglarea orei  
3.24 Caracteristici de performan ță 
3.25 Materiale  
3.26 Inscrip ții 
4. CERIN ȚE FUNCȚIONALE ȘI DE CONSTRUC ȚIE PENTRU 
CARDURILE DE TAHOGRAF  
4.1 Date vizibile  
4.2 Securitate  
4.3 Standarde  
4.4 Specifica ții de mediu și electrice  
4.5 Stocarea datelor  
4.5.1 Fi șierele elementare pentru identificare și pentru gestionarea 
cardului  
4.5.2 Identificarea cardurilor cu circuite integrate (IC)  
4.5.2.1 Identificarea cipului  
4.5.2.2 DIR (prezent numai pe cardurile de tahograf de a doua genera ție) 
4.5.2.3 Informa ții RLR (în anumite condi ții, prezente numai pe cardurile de 
tahograf de a doua genera ție) 
4.5.2.4 Informa ții privind lungimea extins ă (în anumite condi ții, prezente 
numai pe cardurile de tahograf de a doua genera ție) 
4.5.3 Cardul de conduc ător auto  
4.5.3.1 Aplica ție pentru tahograf (accesibil ă pentru unit ățile montate pe 
vehicul de prima și a doua genera ție) 
4.5.3.1.1 Identificarea aplica ției 
4.5.3.1.2 Chei și certificate  
4.5.3.1.3 Identificarea cardului  
4.5.3.1.4 Identificarea titularului cardului  
4.5.3.1.5 Desc ărcarea informa țiilor de pe card  
4.5.3.1.6 Informa ții privind permisul de conducere  
4.5.3.1.7 Date privind evenimentele  
4.5.3.1.8 Date privind anomaliile  
4.5.3.1.9 Date privind activitatea conduc ătorului auto  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 10  
4.5.3.1.10 Date privind vehiculele utilizate  
4.5.3.1.11 Locurile în care încep și/sau se încheie zilele de lucru  
4.5.3.1.12 Date privind sesiunile de utilizare a cardului  
4.5.3.1.13 Date privind activit ățile de control  
4.5.3.1.14 Date privind condi țiile specifice  
4.5.3.2 Aplica ție pentru tahograf de a 2-a genera ție (inaccesibil ă unităților 
montate pe vehicul de prim ă generație) 
4.5.3.2.1 Identificarea aplica ției 
4.5.3.2.2 Chei și certificate  
4.5.3.2.3 Identificarea cardului  
4.5.3.2.4 Identificarea titularului cardului  
4.5.3.2.5 Desc ărcarea informa țiilor de pe card  
4.5.3.2.6 Informa ții privind permisul de conducere  
4.5.3.2.7 Date privind evenimentele  
4.5.3.2.8 Date privind anomaliile  
4.5.3.2.9 Date privind activitatea conduc ătorului auto  
4.5.3.2.10 Date privind vehiculele folosite  
4.5.3.2.11 Locurile și pozițiile în care încep și/sau se încheie zilele de lucru  
4.5.3.2.12 Date privind sesiunile de utilizare a cardului  
4.5.3.2.13 Date privind activit ățile de control  
4.5.3.2.14 Date privind condi țiile specifice  
4.5.3.2.15 Date privind unit ățile montate pe vehicul utilizate  
▼M1 
4.5.3.2.16 Date privind locurile în care se încheie o perioad ă de conducere 
acumulată de trei ore  
▼B 
4.5.4 Cardul de atelier  
4.5.4.1 Aplica ție pentru tahograf (accesibil ă pentru unit ățile montate pe 
vehicul de prima și a doua genera ție) 
4.5.4.1.1 Identificarea aplica ției 
4.5.4.1.2 Chei și certificate  
4.5.4.1.3 Identificarea cardului  
4.5.4.1.4 Identificarea titularului cardului  
4.5.4.1.5 Desc ărcarea informa țiilor de pe card  
4.5.4.1.6 Date privind etalonarea și reglarea orei  
4.5.4.1.7 Date privind evenimentele și anomaliile  
4.5.4.1.8 Date privind activitatea conduc ătorului auto  
4.5.4.1.9 Date privind vehiculele utilizate  
4.5.4.1.10 Date privind începutul și/sau sfârșitul zilelor de lucru  
4.5.4.1.11 Date privind sesiunile de utilizare a cardului  
4.5.4.1.12 Date privind activit ățile de control  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 11  
4.5.4.1.13 Date privind condi țiile specifice  
4.5.4.2 Aplica ția pentru tahograf de a 2-a genera ție (inaccesibil ă unităților 
montate pe vehicul de prim ă generație) 
4.5.4.2.1 Identificarea aplica ției 
4.5.4.2.2 Chei și certificate  
4.5.4.2.3 Identificarea cardului  
4.5.4.2.4 Identificarea titularului cardului  
4.5.4.2.5 Desc ărcarea informa țiilor de pe card  
4.5.4.2.6 Date privind etalonarea și reglarea orei  
4.5.4.2.7 Date privind evenimentele și anomaliile  
4.5.4.2.8 Date privind activitatea conduc ătorului auto  
4.5.4.2.9 Date privind vehiculele utilizate  
4.5.4.2.10 Date privind începutul și/sau sfârșitul zilelor de lucru  
4.5.4.2.11 Date privind sesiunile de utilizare a cardului  
4.5.4.2.12 Date privind activit ățile de control  
4.5.4.2.13 Date privind unit ățile montate pe vehicul utilizate  
▼M1 
4.5.4.2.14 Date privind locurile în care se încheie o perioad ă de conducere 
acumulată de trei ore  
▼B 
4.5.4.2.15 Date privind condi țiile specifice  
4.5.5 Cardul de control  
4.5.5.1 Aplica ție pentru tahograf (accesibil ă pentru unit ățile montate pe 
vehicul de prima și a doua genera ție) 
4.5.5.1.1 Identificarea aplica ției 
4.5.5.1.2 Chei și certificate  
4.5.5.1.3 Identificarea cardului  
4.5.5.1.4 Identificarea titularului cardului  
4.5.5.1.5 Date privind activit ățile de control  
4.5.5.2 Aplica ția pentru tahograf G2 (inaccesibil ă unităților montate pe 
vehicul de prim ă generație) 
4.5.5.2.1 Identificarea aplica ției 
4.5.5.2.2 Chei și certificate  
4.5.5.2.3 Identificarea cardului  
4.5.5.2.4 Identificarea titularului cardului  
4.5.5.2.5 Date privind activit ățile de control  
4.5.6 Card de societate  
4.5.6.1 Aplica ție pentru tahograf (accesibil ă pentru unit ățile montate pe 
vehicul de prima și a doua genera ție) 
4.5.6.1.1 Identificarea aplica ției 
4.5.6.1.2 Chei și certificate  
4.5.6.1.3 Identificarea cardului  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 12  
4.5.6.1.4 Identificarea titularului cardului  
4.5.6.1.5 Date privind activitatea societ ății 
4.5.6.2 Aplica ția pentru tahograf G2 (inaccesibil ă unităților montate pe 
vehicul de prim ă generație) 
4.5.6.2.1 Identificarea aplica ției 
4.5.6.2.2 Chei și certificate  
4.5.6.2.3 Identificarea cardului  
4.5.6.2.4 Identificarea titularului cardului  
4.5.6.2.5 Date privind activitatea societ ății 
5. INSTALAREA APARATURII DE ÎNREGISTRARE  
5.1 Instalare  
5.2 Pl ăcuța de instalare  
5.3 Sigilarea  
6. CONTROALE, INSPEC ȚII ȘI REPARA ȚII 
6.1 Aprobarea montatorilor, a atelierelor și a producătorilor de vehicule  
▼M1 
6.2 Verificarea componentelor noi și a celor reparate  
▼B 
6.3 Inspec ția instalației 
6.4 Inspec ții periodice  
6.5 M ăsurarea erorilor  
6.6 Repara ții 
7. EMITEREA CARDURILOR  
8. OMOLOGAREA DE TIP A APARATURII DE ÎNREGISTRARE 
ȘI A CARDURILOR DE TAHOGRAF  
8.1 Generalit ăți 
8.2 Certificatul de securitate  
8.3 Certificatul de func ționare  
8.4 Certificatul de interoperabilitate  
8.5 Certificatul de omologare de tip  
8.6 Procedur ă extraordinar ă: primele certificate de interoperabilitate 
pentru aparatura de înregistrare și cardurile de tahograf de a 2-a 
generație 
INTRODUCERE  
Sistemul tahografic digital de prim ă generație este în vigoare de la 1 mai 2006. 
Acesta poate fi utilizat pân ă la finalul ciclului s ău de viață pentru transportul 
intern. În schimb, pentru transportul interna țional, după 15 ani de la intrarea în 
vigoare a prezentului regulament al Comisiei, toate vehiculele trebuie s ă fie 
echipate cu un tahograf inteligent conform de a doua genera ție, introdus prin 
prezentul regulament.  
Prezenta anex ă conține cerințe privind aparatura de înregistrare și cardurile de 
tahograf de a doua genera ție. Începând de la data introducerii, se instaleaz ă 
aparatura de înregistrare de a doua genera ție pe vehiculele înmatriculate pentru 
prima dată și se emit carduri de tahograf de a doua genera ție. 
Pentru a favoriza o introducere f ără probleme a sistemului tahografic de a doua 
generație, ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 13  
— cardurile de tahograf de a doua genera ție trebuie concepute astfel încât s ă 
poată fi utilizate și în unitățile montate pe vehicule de prim ă generație; 
— nu este obligatorie înlocuirea cardurilor de tahograf de prim ă generație 
valabile la data introducerii.  
Acest lucru le va permite conduc ătorilor auto s ă își păstreze cardul unic de 
conducător auto și să îl foloseasc ă pentru ambele sisteme.  
Cu toate acestea, aparatura de înregistrare de a doua genera ție se etaloneaz ă 
numai utilizând carduri de atelier de a doua genera ție. 
Prezenta anex ă conține toate cerin țele referitoare la interoperabilitatea dintre 
sistemele tahografice de prima și de a doua genera ție. 
Apendicele 15 con ține detalii suplimentare privind modul de gestionare a coexis ­
tenței celor dou ă sisteme.  
Lista apendicelor  
Apendicele 1: DIC ȚIONAR DE DATE  
Apendicele 2: SPECIFICA ȚIE PRIVIND CARDURILE DE TAHOGRAF  
Apendicele 3: PICTOGRAME  
Apendicele 4: DOCUMENTE IMPRIMATE  
Apendicele 5: AFI ȘAJUL  
Apendicele 6: CONECTOR FRONTAL PENTRU ETALONARE ȘI 
DESCĂRCARE  
Apendicele 7: PROTOCOALE DE DESC ĂRCARE A DATELOR  
Apendicele 8: PROTOCOL DE ETALONARE  
Apendicele 9: OMOLOGAREA DE TIP ȘI LISTA TESTELOR MINIME 
OBLIGATORII  
Apendicele 10: CERIN ȚE DE SECURITATE  
Apendicele 11: MECANISME DE SECURITATE COMUNE  
Apendicele 12: POZI ȚIONAREA BAZAT Ă PE SISTEMUL GLOBAL DE 
NAVIGAȚIE PRIN SATELIT (GNSS)  
Apendicele 13: INTERFA ȚA ITS  
Apendicele 14: FUNC ȚIA DE COMUNICARE LA DISTAN ȚĂ 
Apendicele 15: MIGRA ȚIE: GESTIONAREA COEXISTEN ȚEI MAI 
MULTOR GENERA ȚII DE ECHIPAMENTE  
Apendicele 16: ADAPTOR PENTRU VEHICULELE DIN CATEGORIILE 
M1 ȘI N1  
1. DEFINI ȚII 
În prezenta anex ă: 
(a) „activare” înseamn ă: 
etapa în care tahograful devine complet opera țional și asigură 
toate funcțiile, inclusiv func țiile de securitate, prin utilizarea 
unui card de atelier;  
(b) „autentificare” înseamn ă: 
o funcție destinat ă stabilirii și verificării unei identit ăți 
declarate;  
(c) „autenticitate” înseamn ă: 
faptul că informațiile provin de la o surs ă a cărei identitate 
poate fi verificat ă; 
(d) „test integrat (BIT)” înseamn ă: 
un test executat la comand ă, declanșat de operator sau de 
dispozitive externe;  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 14  
(e) „zi calendaristic ă” înseamnă: 
o zi cuprins ă între ora 00.00 și ora 24.00. Toate zilele calen ­
daristice se raporteaz ă la ora UTC (ora universal ă coordo­
nată); 
(f) „etalonarea” unui tahograf inteligent înseamn ă: 
actualizarea sau confirmarea parametrilor vehiculului care 
urmează să fie stocați în memoria de date. Parametrii vehi ­
culului includ identificarea vehiculului (VIN, VRN și statul 
membru de înmatriculare) și caracteristicile vehiculului [w, k, 
l, dimensiunea pneurilor, reglajele limitatorului de vitez ă 
(dacă este cazul), ora UTC din momentul respectiv, 
valoarea înregistrat ă de odometru în momentul respectiv]; în 
cursul etalon ării unei aparaturi de înregistrare, tipurile și iden­
tificatorii tuturor sigiliilor relevante de omologare de tip 
montate se stocheaz ă, de asemenea, în memoria de date;  
orice actualizare sau confirmare exclusiv a orei UTC este 
considerată o reglare a orei și nu o etalonare, cu condi ția ca 
aceasta să nu contravin ă cerinței 409;  
pentru etalonarea unei aparaturi de înregistrare trebuie 
folosit un card de atelier;  
(g) „num ărul cardului” înseamn ă: 
un cod format din 16 caractere alfanumerice, care reprezint ă 
numărul unic de identificare al unui card de tahograf într-un 
stat membru. Num ărul cardului con ține un indice secven țial al 
cardului (dac ă este cazul), un indice de înlocuire a cardului și 
un indice de reînnoire a cardului;  
prin urmare, un card poate fi identificat exclusiv pe baza 
codului statului membru emitent și a numărului cardului;  
(h) „indice secven țial al cardului” înseamn ă: 
al 14-lea caracter alfanumeric din num ărul unui card, folosit 
pentru a deosebi diferitele carduri emise unei societ ăți, unui 
atelier sau unei autorit ăți de control care au dreptul de a li se 
emite mai multe carduri de tahograf. Societatea, atelierul sau 
autoritatea de control sunt identificate în mod unic pe baza 
primelor 13 caractere ale num ărului cardului;  
(i) „indice de reînnoire a cardului” înseamn ă: 
al 16-lea caracter alfanumeric din num ărul unui card, care 
este incrementat la fiecare reînnoire a cardului de tahograf;  
(j) „indice de înlocuire a cardului” înseamn ă: 
al 15-lea caracter alfanumeric din num ărul unui card, care 
este incrementat la fiecare înlocuire a cardului de tahograf;  
(k) „coeficient caracteristic al vehiculului” înseamn ă: 
caracteristica numeric ă ce indică valoarea semnalului de ie șire 
emis de acel element al vehiculului care face leg ătura dintre 
acesta și aparatura de înregistrare (axul sau cilindrul de ie șire 
al cutiei de viteze), în timp ce vehiculul parcurge o distan ță 
de un kilometru m ăsurată în condiții normale de testare, astfel 
cum sunt definite la cerin ța 414. Coeficientul caracteristic este 
exprimat în impulsuri pe kilometru (w = … imp/km);  
(l) „card de societate” înseamn ă: 
un card de tahograf emis de autorit ățile unui stat membru 
unei întreprinderi de transport obligat ă să utilizeze vehicule 
echipate cu un tahograf, care identific ă întreprinderea de 
transport și permite afi șarea, desc ărcarea și imprimarea 
datelor, stocate în tahograf, care au fost blocate de respectiva 
întreprindere de transport;  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 15  
(m) „constanta aparaturii de înregistrare” înseamn ă: 
caracteristica numeric ă reprezentând valoarea semnalului de 
intrare necesar pentru a indica și a înregistra o distan ță de 
un kilometru parcurs ă; această constantă este exprimat ă în 
impulsuri pe kilometru (k = … imp/km);  
(n) „timpul de conducere continu ă” este calculat de aparatura de 
înregistrare astfel (  1 ): 
timpul de conducere continu ă se calculeaz ă ca fiind timpii de 
conducere acumula ți la un moment dat de un anumit 
conducător auto dup ă încheierea ultimei sale perioade de 
minimum 45 de minute de DISPONIBILITATE sau de 
PAUZĂ/ODIHNĂ sau NECUNOSCUT Ă ( 2 ) [este posibil ca 
această perioadă să fi fost împ ărțită în conformitate cu Regu ­
lamentul (CE) nr. 561/2006 al Parlamentului European și al 
Consiliului (  3 )]. Pentru calculele care trebuie efectuate se iau 
în considerare, dup ă cum este necesar, activit ățile anterioare 
stocate pe cardul de conduc ător auto. În cazul în care 
conducătorul auto nu și-a introdus cardul, calculele necesare 
se bazează pe înregistr ările din memoria de date pentru 
perioada în curs în care niciun card nu a fost introdus și 
legate de slotul relevant;  
(o) „card de control” înseamn ă: 
un card de tahograf emis de autorit ățile unui stat membru 
autorității naționale de control competente, care identific ă 
organismul de control și, opțional, agentul de control și 
care permite accesul la datele stocate în memoria de date 
sau pe cardul de conduc ător auto și, opțional, pe cardul de 
atelier în vederea citirii, a imprim ării și/sau a desc ărcării 
acestora;  
Acest card permite, de asemenea, accesul la func ția de veri­
ficare a etalon ării în trafic și la datele din cititorul pentru 
comunicarea în scopul detect ării timpurii la distan ță. 
(p) „durata cumulat ă a pauzelor” este calculat ă de aparatura de 
înregistrare astfel (  1 ): 
durata cumulat ă a pauzelor care întrerup timpul de conducere 
se calculeaz ă ca fiind perioadele de DISPONIBILITATE sau 
de PAUZĂ/ODIHNĂ sau NECUNOSCUTE (  2 ) de minimum 
15 minute pentru un anumit conduc ător auto, acumulate dup ă 
încheierea ultimei sale perioade de DISPONIBILITATE sau 
de PAUZĂ/ODIHNĂ sau NECUNOSCUTE (  2 ) de minimum 
45 de minute [este posibil ca aceast ă perioadă să fi fost 
împărțită în conformitate cu Regulamentul (CE) 
nr. 561/2006].  
Pentru calculele care trebuie efectuate se iau în considerare, 
după cum este necesar, activit ățile anterioare stocate pe cardul 
de conduc ător auto. Perioadele necunoscute cu durat ă 
negativă (începutul perioadei necunoscute > sfâr șitul 
perioadei necunoscute) cauzate de suprapunerile de timp 
dintre dou ă aparate de înregistrare diferite nu sunt luate în 
considerare la realizarea acestor calcule.  ▼B 
( 1 ) Această modalitate de calculare a timpului de conducere continu ă și a duratei cumulate a 
pauzelor este utilizat ă de aparatura de înregistrare pentru calcularea avertismentului legat 
de timpul de conducere continu ă. Ea nu aduce atingere interpret ării legale a acestor 
timpi. Modalit ățile alternative de calculare a timpului de conducere continu ă și a 
duratei cumulate a pauzelor pot fi utilizate pentru a înlocui aceste defini ții dacă 
acestea au devenit caduce în urma actualiz ării unor alte texte legislative în materie. 
( 2 ) Perioadele NECUNOSCUTE corespund perioadelor în care cardul de conduc ător auto nu 
a fost introdus în aparatul de înregistrare și în care nu au fost introduse manual date 
privind activit ățile conduc ătorului auto. 
( 3 ) Regulamentul (CE) nr. 561/2006 al Parlamentului European și al Consiliului din 
15 martie 2006 privind armonizarea anumitor dispozi ții ale legisla ției sociale în 
domeniul transporturilor rutiere, de modificare a Regulamentelor (CEE) nr. 3821/85 și 
(CE) nr. 2135/98 ale Consiliului și de abrogare a Regulamentului (CEE) nr. 3820/85 al 
Consiliului (JO L 102, 11.4.2006, p. 1).
 02016R0799 — RO — 26.02.2020 — 002.001 — 16  
În cazul în care conduc ătorul auto nu și-a introdus cardul, 
calculele necesare se bazeaz ă pe înregistr ările din memoria 
de date pentru perioada în curs în care niciun card nu a 
fost introdus și legate de slotul relevant;  
(q) „memorie de date” înseamn ă: 
un dispozitiv de stocare a datelor electronice încorporat în 
aparatura de înregistrare;  
(r) „semn ătură digitală” înseamnă: 
datele atașate unui bloc de date sau o transformare cripto ­
grafică a acestuia, care permite destinatarului blocului de 
date să dovedeasc ă autenticitatea și integritatea respectivului 
bloc de date;  
(s) „desc ărcare” înseamn ă: 
copierea, împreun ă cu semnătura digital ă, a unei părți sau a 
unui set complet de fi șiere de date înregistrate în memoria de 
date a unit ății montate pe vehicul sau în memoria cardului de 
tahograf, cu condi ția ca acest proces s ă nu modifice sau s ă 
șteargă eventuale date stocate;  
Producătorii de unit ăți montate pe vehicul pentru tahografele 
inteligente și producătorii de dispozitive proiectate și 
concepute pentru a desc ărca fișiere de date trebuie s ă ia 
toate măsurile rezonabile pentru a se asigura c ă descărcarea 
acestor date poate fi efectuat ă cu o întârziere minim ă de către 
întreprinderile de transport sau de c ătre conduc ătorii auto.  
Descărcarea fișierului care con ține viteza detaliat ă nu este 
necesară pentru stabilirea conformit ății cu Regulamentul 
(CE) nr. 561/2006, dar poate fi folosit ă, printre altele, în 
anchetarea unui accident.  
(t) „card de conduc ător auto” înseamn ă: 
un card de tahograf emis de autorit ățile unui stat membru 
unui anumit conduc ător auto, care identific ă conducătorul 
auto și permite stocarea datelor privind activitatea acestuia;  
(u) „circumferin ță efectivă a roților” înseamn ă: 
media distan țelor parcurse de fiecare dintre ro țile care 
acționează vehiculul (ro ți motoare) în cursul unei rota ții 
complete. M ăsurarea acestor distan țe trebuie efectuat ă în 
condiții normale de testare, astfel cum sunt definite la 
cerința 414 și se exprim ă în format „l = … mm”. Produc ătorii 
de vehicule pot înlocui m ăsurarea acestor distan țe cu un 
calcul teoretic care ia în considerare distribuirea masei pe 
axe atunci când vehiculul este neînc ărcat și în stare normal ă 
de funcționare (  1 ). Metodele pe care se bazeaz ă aceste calcule 
teoretice trebuie aprobate de o autoritate competent ă a statului 
membru și pot fi utilizate numai înainte de activarea tahogra ­
fului;  
(v) „eveniment” înseamn ă: 
o operațiune anormal ă detectată de tahograful inteligent care 
poate decurge dintr-o tentativ ă de fraudă; 
(w) „echipament GNSS extern” înseamn ă: 
un echipament care con ține receptorul GNSS atunci când 
unitatea montat ă pe vehicul nu este o unitate individual ă, 
precum și alte componente necesare pentru protec ția comu­
nicării datelor de pozi ționare către restul unit ății montate pe 
vehicul;  ▼B 
( 1 ) Regulamentul (UE) nr. 1230/2012 al Comisiei din 12 decembrie 2012 de punere în 
aplicare a Regulamentului (CE) nr. 661/2009 al Parlamentului European și al Consiliului 
privind cerin țele de omologare de tip pentru masele și dimensiunile autovehiculelor și ale 
remorcilor acestora și de modificare a Directivei 2007/46/CE a Parlamentului European 
și a Consiliului (JO L 353, 21.12.2012, p. 31), astfel cum a fost modificat ultima dat ă.
 02016R0799 — RO — 26.02.2020 — 002.001 — 17  
(x) „anomalie” înseamn ă: 
o operațiune anormal ă detectată de tahograful inteligent care 
poate decurge dintr-un deranjament sau o defec țiune a apara ­
turii;  
(y) „receptor GNSS” înseamn ă: 
un dispozitiv electronic care recep ționează și prelucreaz ă 
digital semnale de la unul sau mai multe sisteme globale de 
navigație prin satelit (GNSS), pentru a furniza informa ții 
privind pozi ția, viteza și timpul;  
(z) „instalare” înseamn ă: 
montarea unui tahograf într-un vehicul;  
(aa) „interoperabilitate” înseamn ă: 
capacitatea sistemelor și a proceselor de lucru care se afl ă la 
baza acestora de a face schimb de date și de informa ții; 
(bb) „interfa ță” înseamnă: 
un dispozitiv între sisteme care asigur ă mijlocul prin care 
acestea se pot conecta și pot interac ționa;  
(cc) „pozi ție” înseamn ă: 
coordonatele geografice ale vehiculului la un moment dat;  
(dd) „senzor de mi șcare” înseamn ă: 
o parte a tahografului care furnizeaz ă un semnal reprezentând 
viteza vehiculului și/sau distan ța parcursă; 
(ee) „card nevalabil” înseamn ă: 
un card pentru care s-a detectat o anomalie sau a c ărui auten­
tificare ini țială a eșuat sau a c ărui dată de început al valabi ­
lității nu a fost înc ă atinsă sau a cărui dată de expirare a fost 
depășită; 
(ff) „standard deschis” înseamn ă: 
un standard prev ăzut într-un document cu specifica țiile stan­
dardului, disponibil gratuit sau contra unei taxe nominale, 
care poate fi copiat, distribuit sau utilizat f ără taxă sau 
contra unei taxe nominale;  
(gg) „în afara zonei de aplicare a reglement ărilor” înseamn ă: 
cazurile în care utilizarea aparatului de înregistrare nu este 
necesară în conformitate cu dispozi țiile Regulamentului 
(CEE) nr. 561/2006;  
(hh) „dep ășirea limitei de vitez ă” înseamnă: 
depășirea vitezei autorizate a vehiculului, definit ă ca orice 
perioadă de peste 60 de secunde pe parcursul c ăreia viteza 
măsurată a vehiculului dep ășește limita stabilit ă pentru limi ­
tatorul de vitez ă prevăzută în Directiva 92/6/CEE a Consiliu ­
lui (  1 ), astfel cum a fost modificat ă ultima dat ă; 
(ii) „inspec ție periodic ă” înseamnă: 
un set de opera țiuni realizate pentru a verifica dac ă tahograful 
funcționează corespunz ător, dacă reglajele acestuia corespund 
parametrilor vehiculului și dacă nu sunt ata șate dispozitive de 
manipulare la tahograf;  ▼B 
( 1 ) Directiva 92/6/CEE a Consiliului din 10 februarie 1992 privind instalarea și utilizarea 
dispozitivelor limitatoare de vitez ă pentru anumite categorii de vehicule din cadrul 
Uniunii (JO L 57, 2.3.1992, p. 27).
 02016R0799 — RO — 26.02.2020 — 002.001 — 18  
(jj) „imprimant ă” înseamnă: 
o component ă a aparaturii de înregistrare cu ajutorul c ăreia se 
pot imprima datele stocate;  
(kk) „comunicare în scopul detect ării timpurii la distan ță” 
înseamnă: 
comunicarea între echipamentul de comunicare în scopul 
detectării timpurii la distan ță și cititorul pentru comunicarea 
în scopul detect ării timpurii la distan ță în timpul controalelor 
selective în trafic, cu scopul de a detecta la distan ță even­
tualele cazuri de manipulare sau de utilizare abuziv ă a 
aparaturii de înregistrare;  
▼M1 
(ll) „echipament de comunicare la distan ță” sau „echipament de 
detectare timpurie la distan ță” înseamnă: 
echipamentul din cadrul unit ății montate pe vehicul utilizat 
pentru efectuarea controalelor selective în trafic;  
▼B 
(mm) „cititor pentru comunicarea în scopul detect ării timpurii la 
distanță” înseamnă: 
sistemul utilizat de agen ții de control pentru controalele 
selective în trafic;  
(nn) „reînnoire” înseamn ă: 
emiterea unui nou card de tahograf la data expir ării cardului 
existent sau dac ă acesta nu func ționează corect și a fost 
returnat autorit ății emitente. Reînnoirea implic ă întotdeauna 
certitudinea c ă nu coexist ă două carduri valabile;  
(oo) „repara ție” înseamn ă: 
orice repara ție efectuat ă la un senzor de mi șcare sau la o 
unitate montat ă pe vehicul sau la un cablu, care impune 
deconectarea de la sursa de alimentare cu electricitate sau 
deconectarea de la alte componente ale tahografului sau 
deschiderea senzorului de mi șcare sau a unit ății montate pe 
vehicul;  
(pp) „înlocuire a cardului” înseamn ă: 
emiterea unui card de tahograf care s ă înlocuiasc ă un card 
existent care a fost declarat pierdut, furat sau care nu 
funcționează corespunz ător și care nu a fost returnat autorit ății 
emitente. Înlocuirea implic ă întotdeauna riscul ca dou ă carduri 
valabile să coexiste;  
(qq) „certificare a securit ății” înseamn ă: 
proces prin care un organism de certificare pe baza criteriilor 
comune certific ă faptul că aparatura de înregistrare (sau o 
component ă) sau cardul de tahograf investigat îndeplinesc 
cerințele de securitate definite în profilurile de protec ție 
aferente;  
(rr) „autotest” înseamn ă: 
teste efectuate în mod ciclic și automat de c ătre aparatura de 
înregistrare pentru a detecta anomalii;  
(ss) „măsurarea timpului” înseamn ă: 
o înregistrare digital ă permanent ă a datei și orei UTC (timpul 
universal coordonat);  
▼M1 
(tt) „reglarea orei” înseamn ă: 
reglarea orei curente; aceast ă reglare poate fi automat ă, la 
intervale regulate de timp, utilizând ca referin ță ora 
furnizată de receptorul GNSS, sau poate fi realizat ă în 
modul etalonare;  
▼B 
(uu) „dimensiunea pneurilor” înseamn ă: 
desemnarea dimensiunilor pneurilor (de la ro țile motoare 
externe) în conformitate cu Directiva 92/23/CEE a Consiliu ­
lui (  1 ), astfel cum a fost modificat ă ultima dat ă; ▼B 
( 1 ) Directiva 92/23/CEE a Consiliului din 31 martie 1992 privind pneurile autovehiculelor și 
ale remorcilor acestora, precum și montarea lor (JO L 129, 14.5.1992, p. 95).
 02016R0799 — RO — 26.02.2020 — 002.001 — 19  
(vv) „identificarea vehiculului” înseamn ă: 
numerele de identificare ale vehiculului: num ărul de înmatri ­
culare al vehiculului (VRN), care indic ă și statul membru de 
înmatriculare, și numărul de identificare al vehiculului 
(VIN) (  1 ); 
(ww) „săptămână” înseamn ă, în scopul calculelor efectuate de 
aparatura de înregistrare:  
perioada cuprins ă între ziua de luni, ora 00.00 UTC și 
duminica urm ătoare, ora 24.00 UTC;  
(xx) „card de atelier” înseamn ă: 
un card de tahograf emis de autorit ățile unui stat membru 
personalului desemnat al unui produc ător de tahografe, 
montator, produc ător de vehicule sau atelier aprobat de 
statul membru respectiv, care identific ă titularul cardului și 
permite testarea, etalonarea și activarea tahografelor și/sau 
descărcarea din acestea;  
(yy) „adaptor” înseamn ă: 
un dispozitiv care emite în permanen ță un semnal repre ­
zentativ pentru viteza vehiculului și/sau distan ța parcursă de 
acesta, altul decât cel utilizat pentru detectarea independent ă a 
deplasărilor, și care este:  
▼M1 
— instalat și utilizat numai pe vehiculele de tip M1 și N1 
(conform defini țiilor din anexa II la Directiva 2007/46/CE 
a Parlamentului European și a Consiliului (  2 ), astfel cum a 
fost modificat ă ultima dat ă); 
▼B 
— instalat acolo unde este imposibil din punct de vedere 
mecanic s ă se instaleze orice alt tip de senzor de 
mișcare existent care respect ă, în rest, dispozi țiile 
prezentei anexe și ale apendicelor 1-15 la aceasta;  
— instalat între unitatea montat ă pe vehicul și locul unde 
impulsurile de vitez ă/distanță sunt generate de senzori 
integrați sau de interfe țe alternative;  
— din perspectiva unit ății montate pe vehicul, comporta ­
mentul adaptorului este acela și ca în situa ția în care la 
unitatea montat ă pe vehicul ar fi conectat un senzor de 
mișcare care respect ă dispozițiile prezentei anexe și ale 
apendicelor 1-16 la aceasta;  
utilizarea unui astfel de adaptor în vehiculele men ționate mai 
sus permite instalarea și utilizarea corect ă a unei unit ăți 
montate pe vehicul care respect ă toate cerin țele prezentei 
anexe;  
în cazul vehiculelor respective, tahograful inteligent include 
cabluri, un adaptor și o unitate montat ă pe vehicul;  ▼B 
( 1 ) Directiva 76/114/CEE a Consiliului din 18 decembrie 1975 privind apropierea legi ­
slațiilor statelor membre referitoare la pl ăcuțele și inscripționările regulamentare ale 
autovehiculelor și ale remorcilor, precum și la amplasamentul și modul de aplicare a 
acestora (JO L 24, 30.1.1976, p. 1). 
( 2 ) Directiva 2007/46/CE a Parlamentului European și a Consiliului din 5 septembrie 2007 
de stabilire a unui cadru pentru omologarea autovehiculelor și remorcilor acestora, 
precum și a sistemelor, componentelor și unităților tehnice separate destinate vehiculelor 
respective (Directiv ă-cadru) (JO L 263, 9.10.2007, p. 1).
 02016R0799 — RO — 26.02.2020 — 002.001 — 20  
(zz) „integritatea datelor” înseamn ă: 
precizia și compatibilitatea datelor stocate, indicate prin 
absența oricărei modific ări a datelor între dou ă actualizări 
ale unei înregistr ări de date. Integritatea implic ă faptul că 
datele constituie o copie fidel ă a versiunii originale, de 
exemplu faptul c ă datele nu au fost deteriorate în cursul 
procesului de scriere pe sau de citire dintr-un card de 
tahograf sau dintr-un dispozitiv corespunz ător sau în cursul 
transmisiei prin intermediul oric ărui canal de comunicare;  
(aaa) „confiden țialitatea datelor” înseamn ă: 
măsurile tehnice generale luate cu scopul de a asigura punerea 
corespunzătoare în aplicare a principiilor prev ăzute în 
Directiva 95/46/CE a Parlamentului European și a Consiliu ­
lui (  1 ), precum și a principiilor prev ăzute în Directiva 
2002/58/CE a Parlamentului European și a Consiliului (  2 ); 
(bbb) „sistem tahografic inteligent” înseamn ă: 
aparatura de înregistrare, cardurile de tahograf și ansamblul 
tuturor echipamentelor cu interac țiune direct ă sau indirect ă în 
cursul etapelor de construc ție, instalare, utilizare, testare și 
control ale acestora, precum cardurile, cititorul pentru comu ­
nicarea la distan ță și orice alte echipamente pentru 
descărcarea datelor, analizarea datelor, etalonare, generarea, 
gestionarea sau introducerea elementelor de securitate etc.;  
(ccc) „data introducerii” înseamn ă: 
36 de luni de la intrarea în vigoare a dispozi țiilor detaliate 
menționate la articolul 11 din Regulamentul (UE) 
nr. 165/2014 al Parlamentului European și al Consiliului (  3 ). 
Este data începând de la care vehiculele înmatriculate pentru 
prima dat ă: 
— trebuie s ă fie echipate cu un tahograf conectat la un 
serviciu de pozi ționare bazat pe un sistem de naviga ție 
prin satelit;  
— trebuie s ă poată comunica autorit ăților de control 
competente date pentru controalele selective în trafic, în 
timp ce vehiculul se afl ă în mișcare;  
— și pot fi echipate cu interfe țe standardizate care s ă 
permită utilizarea în modul opera țional, de c ătre un 
dispozitiv extern, a datelor înregistrate sau produse de 
tahografe;  
(ddd) „profil de protec ție” înseamn ă: 
un document utilizat ca parte a procesului de certificare în 
conformitate cu criteriile comune, care define ște, independent 
de punerea în aplicare, cerin țele de securitate pentru 
garantarea protec ției informa țiilor; ▼B 
( 1 ) Directiva 95/46/CE a Parlamentului European și a Consiliului din 24 octombrie 1995 
privind protec ția persoanelor fizice în ceea ce prive ște prelucrarea datelor cu caracter 
personal și libera circula ție a acestor date (JO L 281, 23.11.1995, p. 31). 
( 2 ) Directiva 2002/58/CE a Parlamentului European și a Consiliului din 12 iulie 2002 
privind prelucrarea datelor personale și protejarea confiden țialității în sectorul comuni ­
cațiilor publice (Directiva asupra confiden țialității și comunica țiilor electronice) (JO L 201, 
31.7.2002, p. 37). 
( 3 ) Regulamentul (UE) nr. 165/2014 al Parlamentului European și al Consiliului din 
4 februarie 2014 privind tahografele în transportul rutier, de abrogare a Regulamentului 
(CEE) nr. 3821/85 al Consiliului privind aparatura de înregistrare în transportul rutier și 
de modificare a Regulamentului (CE) nr. 561/2006 al Parlamentului European și al 
Consiliului privind armonizarea anumitor dispozi ții ale legisla ției sociale în domeniul 
transporturilor rutiere (JO L 60, 28.2.2014, p. 1).
 02016R0799 — RO — 26.02.2020 — 002.001 — 21  
(eee) „precizia GNSS” înseamn ă: 
în contextul înregistr ării poziției de către un sistem global de 
navigație prin satelit (GNSS) cu ajutorul tahografelor, 
înseamnă valoarea sc ăderii preciziei în plan orizontal 
(HDOP –  Horizontal Dilution of Precision ), calculat ă ca 
cea mai mic ă dintre valorile HDOP colectate de la 
sistemele GNSS disponibile;  
▼M1 
(fff) „timp de conducere acumulat” înseamn ă: 
o valoare reprezentând num ărul total acumulat de minute de 
conducere a unui anumit vehicul.  
Valoarea timpului de conducere acumulat este o contorizare 
cumulativă a tuturor minutelor înregistrate drept 
CONDUCERE de func ția de monitorizare a activit ăților de 
conducere a aparaturii de înregistrare și este folosit ă doar 
pentru declan șarea înregistr ării poziției vehiculului de 
fiecare dat ă când este atins un multiplu de trei ore de 
conducere acumulat ă. Acumularea începe la activarea 
aparaturii de înregistrare. Aceasta nu este afectat ă de nicio 
altă condiție, cum ar fi „în afara zonei de aplicare a regle ­
mentărilor” sau „traseu parcurs pe feribot/în tren”.  
Valoarea timpului de conducere acumulat nu este destinat ă a 
fi afișată, imprimat ă sau descărcată. 
▼B 
2. CARACTERISTICI ȘI FUNCȚII GENERALE ALE APARATURII 
DE ÎNREGISTRARE  
2.1 Caracteristici generale  
Scopul aparaturii de înregistrare este de a înregistra, a stoca, a afi șa, 
a imprima și a genera date privind activitatea șoferului.  
Orice vehicul dotat cu aparatur ă de înregistrare conform ă cu 
dispozițiile prezentei anexe trebuie s ă fie echipat, de asemenea, cu 
un vitezometru și cu un odometru. Aceste func ții pot fi incluse în 
aparatura de înregistrare.  
(1) Aparatura de înregistrare include cabluri, un senzor de 
mișcare și o unitate montat ă pe vehicul.  
(2) Interfa ța dintre senzorii de mi șcare și unitățile montate pe 
vehicul respect ă cerințele specificate în apendicele 11.  
(3) Unitatea montat ă pe vehicul este conectat ă la sistemul (sis ­
temele) global(e) de naviga ție prin satelit, în conformitate cu 
apendicele 12.  
(4) Unitatea montat ă pe vehicul comunic ă cu cititoarele pentru 
comunicarea în scopul detect ării timpurii la distan ță, în 
conformitate cu apendicele 14.  
(5) Unitatea montat ă pe vehicul poate include o interfa ță ITS, 
specificată în apendicele 13.  
Aparatura de înregistrare poate fi conectat ă la alte echi ­
pamente prin intermediul unor interfe țe suplimentare și/sau 
prin interfa ța ITS opțională. 
(6) Includerea în sau conectarea la aparatura de înregistrare a 
oricărei funcții, dispozitiv sau dispozitive, omologate sau de 
alt tip, nu trebuie s ă interfereze sau s ă fie susceptibil ă de a 
interfera cu func ționarea corespunz ătoare și sigură a 
aparaturii de înregistrare, nici s ă încalce sau s ă fie suscep ­
tibilă de a încălca dispozi țiile prezentului regulament.  
Utilizatorii aparaturii de înregistrare se identific ă prin inter ­
mediul cardurilor de tahograf.  
(7) Aparatura de înregistrare ofer ă drepturi selective de acces la 
date și la funcții, pe baza tipului și/sau a identit ății utiliza­
torului.  
Aparatura de înregistrare înregistreaz ă și stochează date în memoria 
sa de date, în echipamentul de comunicare la distan ță și pe cardurile 
de tahograf.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 22  
Acest lucru se face în conformitate cu Directiva 95/46/CE din 
24 octombrie 1995 privind protec ția persoanelor fizice în ceea ce 
privește prelucrarea datelor cu caracter personal și libera circula ție a 
acestor date (  1 ), cu Directiva 2002/58/CE din 12 iulie 2002 privind 
prelucrarea datelor personale și protejarea confiden țialității în 
sectorul comunica țiilor publice (  2 ) și cu articolul 7 din Regulamentul 
(UE) nr. 165/2014.  
2.2 Func ții 
(8) Aparatura de înregistrare asigur ă următoarele func ții: 
— monitorizarea introducerilor și a retragerilor cardurilor;  
— măsurarea vitezei, a distan ței și a poziției; 
— măsurarea timpului;  
— monitorizarea activit ăților conduc ătorului auto;  
— monitorizarea regimului de conducere;  
— introducerea manual ă a datelor de c ătre conduc ătorul 
auto;  
— înregistrarea locurilor în care încep și/sau se încheie 
zilele de lucru;  
— introducerea manual ă a activităților conduc ătorului 
auto;  
— înregistrarea condi țiilor specifice;  
— gestionarea bloc ărilor efectuate de societate;  
— monitorizarea activit ăților de control;  
— detectarea evenimentelor și/sau a anomaliilor;  
— testele integrate și autotestele;  
— citirea din memoria de date;  
— înregistrarea și stocarea în memoria de date;  
— citirea de pe cardurile de tahograf;  
— înregistrarea și stocarea pe cardurile de tahograf;  
— afișarea;  
— imprimarea;  
— avertizarea;  
— descărcarea de date pe suporturi externe;  
— comunicarea la distan ță pentru controalele selective în 
trafic;  
— date de ie șire transmise unor echipamente suplimentare;  
— etalonarea;  
— verificarea etalon ării în trafic;  
— reglarea orei.  
2.3 Moduri de func ționare  
(9) Aparatura de înregistrare are patru moduri de operare:  
— modul opera țional;  
— modul control;  
— modul etalonare;  
— modul societate.  
(10) Aparatura de înregistrare este comutat ă la următoarele 
moduri de func ționare pe baza cardurilor de tahograf 
valabile introduse în dispozitivele de interfa ță pentru card. 
Generația cardului de tahograf nu este relevant ă pentru 
determinarea modului de func ționare, cu condi ția să fie 
introdus un card valabil. Un card de atelier de prim ă 
generație este întotdeauna considerat nevalabil atunci când 
este introdus într-o unitate montat ă pe vehicul (VU) de a 
doua genera ție. ▼B 
( 1 ) JO L 281, 23.11.1995, p.31. 
( 2 ) JO L 201, 31.7.2002, p.37.
 02016R0799 — RO — 26.02.2020 — 002.001 — 23  
Mod de func ționare  Slot pentru cardul de conduc ător auto  
Niciun card  Card de conduc ător 
auto Card de control  Card de atelier  Card de societate
 Slot pentru cardul copilotului 
Niciun card  Opera țional  Opera țional  Control  Etalonare  Societate  
Card de conduc ător 
auto Operațional  Opera țional  Control  Etalonare  Societate  
Card de control  Control  Control  Control (*)  Opera țional  Opera țional  
Card de atelier  Etalonare  Etalonare  Opera țional  Etalonare (*)  Operațional  
Card de societate  Societate  Societate  Opera țional  Opera țional  Societate (*)  
(*) În aceste situa ții, aparatura de înregistrare utilizeaz ă numai cardul de tahograf introdus în slotul pentru cardul de conduc ător auto.  
(11) Aparatura de înregistrare refuz ă cardurile nevalabile 
introduse, permi țând în astfel de cazuri numai afi șarea, 
imprimarea sau desc ărcarea datelor stocate pe cardurile 
expirate.  
(12) Toate func țiile enumerate la punctul 2.2 sunt disponibile în 
orice mod de func ționare, cu urm ătoarele excep ții: 
— funcția de etalonare este accesibil ă numai în modul 
etalonare;  
— funcția de verificare a etalon ării în trafic este accesibil ă 
numai în modul etalonare;  
— funcția de gestionare a bloc ărilor efectuate de societate 
este accesibil ă numai în modul societate;  
— funcția de monitorizare a activit ăților de control este 
accesibilă numai în modul control;  
— funcția de desc ărcare nu este accesibil ă în modul 
operațional (cu excep ția cazurilor prev ăzute la cerin ța 
193) și cu excep ția descărcării de pe un card de 
conducător auto atunci când în unitatea montat ă pe 
vehicul nu este introdus niciun alt tip de card.  
(13) Aparatura de înregistrare poate extrage orice date în vederea 
afișării, imprim ării sau desc ărcării pe suporturi externe, cu 
următoarele excep ții: 
— în modul opera țional, orice identificare personal ă (nume 
și prenume) care nu corespunde unui card de tahograf 
introdus este mascat ă și orice num ăr de card care nu 
corespunde unui card de tahograf introdus este mascat 
parțial (fiecare caracter de pe pozi țiile cu num ăr impar – 
de la stânga la dreapta – este mascat);  
— în modul societate, datele privind conduc ătorul auto 
(cerințele 102, 105 și 108) pot fi extrase numai pentru 
perioadele în care nu exist ă nicio blocare sau în care 
nicio o alt ă societate (astfel cum este identificat ă pe 
baza primelor 13 caractere din num ărul cardului de 
societate) nu a activat vreo blocare;  
— dacă în aparatura de înregistrare nu a fost introdus niciun 
card, nu pot fi extrase date privind conduc ătorul auto 
decât pentru ziua respectiv ă și pentru cele opt zile calen ­
daristice anterioare zilei respective;  
— datele cu caracter personal provenind din VU nu se 
extrag prin interfa ța ITS a VU, cu excep ția cazului în 
care a fost verificat acordul conduc ătorului auto la care 
se referă datele respective;  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 24  
— unitățile montate pe vehicul au, în mod normal, o 
perioadă de funcționare de 15 ani, începând de la data 
de începere a valabilit ății certificatelor aferente unit ăților 
montate pe vehicul, îns ă ele pot fi utilizate înc ă trei luni 
după această perioadă numai pentru desc ărcarea de date.  
▼B 
2.4 Securitate  
▼M1 
Scopul sistemului de securitate este de a proteja memoria de date 
astfel încât s ă împiedice accesul neautorizat la date și manipularea 
acestora, de a detecta orice astfel de tentative, de a proteja inte ­
gritatea și autenticitatea datelor transmise între senzorul de mi șcare 
și unitatea montat ă pe vehicul, de a proteja integritatea și autenti­
citatea datelor transmise între aparatura de înregistrare și cardurile de 
tahograf, de a proteja integritatea și autenticitatea datelor transmise 
între unitatea montat ă pe vehicul și echipamentul GNSS extern, dac ă 
există, de a proteja confiden țialitatea, integritatea și autenticitatea 
datelor transmise, în scopuri de control, prin comunicarea la 
distanță în scopul detect ării timpurii, precum și de a verifica inte ­
gritatea și autenticitatea datelor desc ărcate.  
▼B 
(14) Pentru a garanta securitatea sistemului, urm ătoarele 
componente trebuie s ă îndeplineasc ă cerințele de securitate 
specificate în profilurile de protec ție, în conformitate cu 
apendicele 10:  
— unitatea montat ă pe vehicul;  
— cardul de tahograf;  
— senzorul de mi șcare;  
— echipamentul GNSS extern (acest profil este necesar și 
aplicabil numai pentru varianta extern ă a GNSS).  
3. CERIN ȚE DE CONSTRUC ȚIE ȘI DE FUNC ȚIONARE APLI ­
CABILE APARATURII DE ÎNREGISTRARE  
3.1 Monitorizarea introducerii și retragerii cardurilor  
(15) Aparatura de înregistrare monitorizeaz ă dispozitivele de 
interfață pentru card pentru a detecta introducerile și retra­
gerile cardurilor.  
(16) La introducerea unui card, aparatura de înregistrare verific ă 
valabilitatea cardului de tahograf introdus și, dacă acesta este 
valabil, identific ă tipul și generația cardului.  
Dacă în aparatura de înregistrare a fost deja introdus un card 
cu același număr și cu un indice de reînnoire mai mare, 
cardul în cauz ă este declarat nevalabil.  
Dacă în aparatura de înregistrare a fost deja introdus un card 
cu același număr și cu același indice de reînnoire, dar cu un 
indice de înlocuire mai mare, cardul în cauz ă este declarat 
nevalabil.  
(17) Cardurile de tahograf de prim ă generație sunt considerate 
nevalabile de c ătre aparatura de înregistrare dup ă ce posibi­
litatea de a utiliza carduri de tahograf de prim ă generație a 
fost suprimat ă de un atelier, în conformitate cu apendicele 
15 (cerința MIG003).  
(18) Cardurile de atelier de prim ă generație care sunt introduse 
într-o aparatur ă de înregistrare de a doua genera ție sunt 
considerate nevalabile.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 25  
(19) Aparatura de înregistrare este proiectat ă astfel încât cardurile 
de tahograf s ă fie blocate în pozi ția corectă la introducerea 
lor în dispozitivul de interfa ță pentru card.  
(20) Retragerea cardurilor de tahograf este posibil ă numai dup ă 
oprirea vehiculului și după stocarea datelor relevante pe 
carduri. Retragerea cardului necesit ă o interven ție concretă 
a utilizatorului.  
3.2 M ăsurarea vitezei, a pozi ției și a distan ței 
(21) Senzorul de mi șcare (integrat eventual în adaptor) reprezint ă 
principala surs ă de măsurare a vitezei și a distanței. 
(22) Aceast ă funcție asigură măsurarea continu ă și poate indica 
valoarea înregistrat ă de odometru care corespunde distan ței 
totale parcurse de vehicul, pe baza impulsurilor emise de 
senzorul de mi șcare.  
(23) Aceast ă funcție asigură măsurarea continu ă și poate indica 
viteza vehiculului, pe baza impulsurilor emise de senzorul 
de mișcare.  
(24) Func ția de măsurare a vitezei indic ă, de asemenea, dac ă 
vehiculul se deplaseaz ă sau este oprit. Se consider ă că 
vehiculul se deplaseaz ă în momentul în care func ția 
detectează o valoare mai mare de 1 imp/sec de la senzorul 
de mișcare timp de cel pu țin cinci secunde, în caz contrar 
vehiculul fiind considerat oprit.  
(25) Dispozitivele pentru afi șarea vitezei (vitezometrul) și a 
distanței totale parcurse (odometrul) instalate în orice 
vehicul prev ăzut cu o aparatur ă de înregistrare care 
respectă dispozițiile prezentului regulament trebuie s ă 
respecte cerin țele privind toleran țele maxime (a se vedea 
punctele 3.2.1 și 3.2.2.) prev ăzute în prezenta anex ă. 
(26) Pentru detectarea manipul ării datelor de la senzorul de 
mișcare, informa țiile provenite de la senzorul de mi șcare 
sunt coroborate cu informa țiile privind deplasarea vehi ­
culului derivate din receptorul GNSS și, în mod op țional, 
din altă (alte) surs ă (surse) independent ă (independente) de 
senzorul de mi șcare.  
(27) Aceast ă funcție măsoară poziția vehiculului pentru a permite 
înregistrarea automat ă: 
— a pozițiilor în care conduc ătorul auto și/sau copilotul î și 
încep(e) ziua de lucru;  
▼M1 
— pozițiile în care timpul de conducere acumulat atinge un 
multiplu de trei ore;  
▼B 
— a pozițiilor în care conduc ătorul auto și/sau copilotul î și 
încheie ziua de lucru.  
3.2.1  M ăsurarea distan ței parcurse  
(28) Distan ța parcursă poate fi m ăsurată: 
— fie cumulând deplas ările înainte și înapoi;  
— fie cumulând numai deplas ările înainte.  
(29) Aparatura de înregistrare m ăsoară distanța parcursă între 0 și 
9 999 999,9 km.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 26  
(30) Distan ța măsurată respectă următoarele limite de toleran ță 
(distanțe de cel pu țin 1 000 m):  
— ± 1 % înainte de instalare;  
— ± 2 % în cursul instal ării și al inspec țiilor periodice;  
— ± 4 % în timpul func ționării. 
(31) Distan ța măsurată trebuie să aibă o rezoluție de 0,1 km sau 
mai bună. 
3.2.2  M ăsurarea vitezei  
(32) Aparatura de înregistrare m ăsoară viteza între 0 și 220 km/h.  
(33) Pentru a asigura o toleran ță maximă de ± 6 km/h pentru 
viteza afișată în timpul func ționării și luând în considerare:  
— o toleran ță de ± 2 km/h pentru varia țiile semnalului de 
intrare (varia ții provocate de pneuri, …);  
— o toleran ță de ± 1 km/h la m ăsurătorile efectuate în 
timpul instal ării sau al inspec țiilor periodice;  
aparatura de înregistrare trebuie s ă măsoare viteza cu o 
toleranță de ± 1 km/h (la vitez ă constantă) dacă vitezele se 
încadrează între 20 și 180 km/h, iar coeficien ții caracteristici 
ai vehiculului între 4 000 și 25 000 imp/km.  
Notă: Datorită rezoluției stocării de date, se adaug ă o 
toleranță suplimentar ă de ± 0,5 km/h la viteza stocat ă de 
aparatura de înregistrare.  
(34) Viteza trebuie m ăsurată corect, în limitele normale de tole ­
ranță, în primele dou ă secunde de dup ă finalizarea unei 
modificări a vitezei, dac ă viteza s-a modificat într-un ritm 
de până la 2 m/s  2 . 
(35) Măsurarea vitezei trebuie s ă aibă o rezoluție de 1 km/h sau 
mai bună. 
3.2.3  M ăsurarea pozi ției 
(36) Aparatura de înregistrare m ăsoară poziția absolută a vehi­
culului cu ajutorul receptorului GNSS.  
(37) Pozi ția absolută se măsoară în coordonate geografice de 
latitudine și longitudine, în grade și minute, cu o rezolu ție 
de 1/10 de minut.  
3.3 M ăsurarea timpului  
(38) Func ția de măsurare a timpului m ăsoară în permanen ță data 
și ora UTC și le furnizeaz ă în format digital.  
(39) Data și ora UTC se utilizeaz ă pentru datarea datelor din 
aparatura de înregistrare (înregistr ări, schimburi de date) și 
pentru toate materialele imprimate men ționate la apendicele 
4 „Materiale imprimate”.  
(40) Pentru afi șarea orei locale este posibil ă modificarea deca ­
lajului orar al orei afi șate, în intervale de o jum ătate de 
oră. Nu este admis niciun alt decalaj în afara celor care 
reprezintă multipli negativi sau pozitivi de jum ătate de oră; 
(41) Abaterea de timp nu trebuie s ă depășească ± 2 secunde pe zi 
în condiții de omologare de tip, în absen ța oricărei reglări a 
orei. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 27  
(42) Timpul se m ăsoară cu o rezolu ție de o secund ă sau mai 
bună. 
(43) Măsurarea timpului nu este afectat ă de întreruperile 
alimentării cu energie electric ă din exterior care dureaz ă 
mai puțin de 12 luni în condi ții de omologare de tip.  
3.4 Monitorizarea activit ăților conduc ătorului auto  
(44) Aceast ă funcție monitorizeaz ă, în mod permanent și separat, 
activitățile unui conduc ător auto și ale unui copilot.  
(45) Activit ățile conduc ătorului auto sunt CONDUCERE, 
MUNCĂ, DISPONIBILITATE sau PAUZ Ă/ODIHNĂ. 
(46) Pilotul și/sau copilotul pot selecta manual MUNC Ă, DISPO­
NIBILITATE sau PAUZ Ă/ODIHNĂ. 
(47) Când vehiculul este în mi șcare, se selecteaz ă automat acti ­
vitatea CONDUCERE pentru conduc ătorul auto și DISPO­
NIBILITATE pentru copilot.  
(48) Când vehiculul se opre ște, pentru conduc ătorul auto se 
selectează automat MUNC Ă. 
▼M1 
(49) Se consider ă că prima modificare a activit ății în PAUZ Ă/ 
ODIHNĂ sau DISPONIBILITATE care a avut loc în termen 
de 120 de secunde de la selectarea automat ă a activității 
MUNCĂ din cauza opririi vehiculului s-a produs în 
momentul în care vehiculul s-a oprit (fiind astfel posibil ă 
anularea modific ării în MUNC Ă). 
▼B 
(50) Aceast ă funcție transmite modific ările activit ăților către 
funcțiile de înregistrare cu o rezolu ție de un minut.  
(51) Dac ă o activitate de CONDUCERE este înregistrat ă ca acti­
vitate atât în minutul imediat anterior, cât și în minutul 
imediat ulterior unui minut calendaristic dat, minutul 
respectiv va fi considerat în întregime drept minut de 
CONDUCERE.  
(52) Dac ă un minut calendaristic dat nu este considerat minut de 
CONDUCERE conform cerin ței 051, întregul minut este 
considerat ca apar ținând aceluia și tip de activitate ca cea 
mai lungă activitate continu ă derulată în minutul respectiv 
(sau cea mai recent ă activitate în cazul unor activit ăți cu 
durată egală). 
(53) Aceast ă funcție permite, de asemenea, monitorizarea 
permanentă a timpului de conducere continu ă și a duratei 
cumulate a pauzelor conduc ătorului auto.  
3.5 Monitorizarea regimului de conducere  
(54) Aceast ă funcție monitorizeaz ă, în mod permanent și 
automat, regimul de conducere.  
(55) Când în aparat sunt introduse dou ă carduri de conduc ător 
auto valabile, se selecteaz ă regimul de conducere ECHIPAJ, 
iar în toate celelalte cazuri se selecteaz ă regimul SINGUR.  
3.6 Înregistr ări realizate de conduc ătorii auto  
3.6.1  Înregistrarea locurilor în care încep și/sau se încheie zilele de lucru  
(56) Aceast ă funcție permite înregistrarea locurilor în care, 
potrivit conduc ătorului auto și/sau copilotului, încep și/sau 
se încheie zilele sale (lor) de lucru.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 28  
(57) Un loc înseamn ă țara și, dacă este cazul, și regiunea care 
sunt înregistrate sau confirmate manual.  
(58) În momentul retragerii unui card de conduc ător auto, 
aparatura de înregistrare îi solicit ă conducătorului auto (copi ­
lotului) să introducă un „loc în care se încheie ziua de 
lucru”.  
▼M1 
(59) Conduc ătorul auto introduce atunci locul în care se afl ă 
vehiculul în momentul respectiv, acest lucru fiind considerat 
o înregistrare temporar ă. 
În următoarele condi ții, înregistrarea temporar ă efectuată la 
ultima retragere a cardului este validat ă (și anume, nu se mai 
suprascrie):  
— înregistrarea unui loc unde începe ziua de lucru curent ă 
în cursul înregistr ării manuale conform cerin ței (61);  
— următoarea înregistrare a unui loc unde începe ziua de 
lucru curent ă dacă titularul cardului nu înregistreaz ă 
niciun loc în care începe sau s-a încheiat ziua de lucru 
în cursul înregistr ării manuale conform cerin ței (61).  
În următoarele condi ții, înregistrarea temporar ă efectuată la 
ultima retragere a cardului este suprascris ă și noua valoare 
este validat ă: 
— următoarea înregistrare a unui loc unde se încheie ziua 
de lucru curent ă dacă titularul cardului nu înregistreaz ă 
niciun loc în care începe sau s-a încheiat ziua de lucru în 
cursul introducerii manuale conform cerin ței (61).  
▼B 
(60) Înregistrarea locurilor în care încep și/sau se încheie zilele 
de lucru este posibil ă prin intermediul comenzilor din 
meniuri. Dac ă într-un minut calendaristic se efectueaz ă mai 
multe astfel de înregistr ări, nu vor r ămâne înregistrate decât 
locul de începere cel mai recent introdus și locul de 
încheiere cel mai recent introdus.  
3.6.2  Introducerea manual ă a activităților conduc ătorului auto și acordul 
conducătorului auto pentru interfa ța ITS  
(61) Aparatura de înregistrare permite introducerea manual ă a 
activităților numai în momentul introducerii cardului de 
conducător auto (sau de atelier). Introducerea manual ă a 
activităților se efectueaz ă utilizând valorile datei și orei 
locale corespunz ătoare fusului orar (decalaj UTC) setat la 
momentul respectiv pentru unitatea montat ă pe vehicul.  
La introducerea cardului de conduc ător auto sau de atelier, 
titularului cardului i se vor reaminti urm ătoarele:  
— data și ora ultimei retrageri a cardului;  
— în mod op țional: decalajul orei locale setat la momentul 
respectiv pentru unitatea montat ă pe vehicul.  
La prima introducere a unui card de conduc ător auto sau de 
atelier care nu este recunoscut, la momentul respectiv, de 
unitatea montat ă pe vehicul, titularul cardului este invitat s ă 
își exprime acordul privind extragerea datelor cu caracter 
personal din tahograf prin intermediul interfe ței ITS 
opționale.  
Acordul conduc ătorului auto (respectiv al atelierului) poate 
fi activat sau dezactivat în orice moment prin comenzile din 
meniu, cu condi ția să fie introdus cardul de conduc ător auto 
(respectiv de atelier).  
Este posibil s ă se introduc ă activități, cu urm ătoarele 
restricții: ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 29  
— tipul de activitate trebuie s ă fie MUNC Ă, DISPONIBI ­
LITATE sau PAUZ Ă/ODIHNĂ; 
— ora de începere și de încheiere ale fiec ărei activități 
trebuie să se situeze numai între momentul ultimei 
retrageri a cardului și cel al introducerii sale curente;  
— activitățile nu trebuie s ă se suprapun ă în timp.  
Este posibil s ă se introduc ă manual date, dac ă este necesar, 
la prima introducere a unui card de conduc ător auto (sau de 
atelier) care nu a mai fost utilizat.  
Procedura de introducere manual ă a activităților include 
toate etapele consecutive necesare pentru stabilirea tipului, 
a orei de începere și a orei de încheiere a fiec ărei activități. 
Pentru oricare subdiviziune a perioadei de timp dintre ultima 
retragere a cardului și inserarea curent ă a acestuia, titularul 
cardului are op țiunea de a nu declara nicio activitate.  
În timpul introducerii manuale a datelor asociate introducerii 
cardului, titularul cardului are posibilitatea de a introduce, 
dacă este cazul:  
▼M1 
— locul unde s-a încheiat o zi de lucru anterioar ă, asociat 
orei relevante (suprascriind și validând astfel înregis ­
trarea efectuat ă cu ocazia ultimei retrageri a cardului);  
— locul unde începe ziua de lucru curent ă, asociat orei 
relevante (validând astfel o înregistrare temporar ă 
efectuată cu ocazia ultimei retrageri a cardului).  
▼B 
Dacă titularul cardului nu înregistreaz ă locul în care î și 
începe sau î și încheie ziua de lucru în cursul introducerii 
manuale a datelor asociate introducerii cardului, acest 
lucru se consider ă drept o declara ție a faptului c ă ziua sa 
de lucru nu s-a modificat de la ultima retragere a cardului. 
Următoarea înregistrare a unui loc în care se încheie o zi de 
lucru anterioar ă superscrie apoi înregistrarea temporar ă 
efectuată cu ocazia ultimei retrageri a cardului.  
Dacă se introduce un loc, acesta se înregistreaz ă pe cardul 
de tahograf relevant.  
Introducerea manual ă a datelor se întrerupe dac ă: 
— cardul este retras; sau  
— vehiculul este în mi șcare, iar cardul se afl ă în slotul 
pentru cardul de conduc ător auto.  
Sunt permise întreruperi suplimentare, de exemplu o pauz ă 
după o anumită perioadă de inactivitate a utilizatorului. Dac ă 
introducerea manual ă a datelor este întrerupt ă, aparatura de 
înregistrare valideaz ă orice date complete privind locul și 
activitatea (care indic ă, fără ambiguitate, fie locul și 
timpul, fie tipul de activitate, ora de începere și ora 
încheiere) care au fost deja înregistrate.  
Dacă, în cursul introducerii manuale a datelor pentru un card 
introdus anterior, se introduce un al doilea card de 
conducător auto sau de atelier, introducerea manual ă a 
datelor pentru primul card poate fi finalizat ă înainte de a 
începe introducerea manual ă a datelor pentru cel de al 
doilea card.  
Titularul cardului are op țiunea de a introduce manual date 
conform urm ătoarei proceduri minime:  
— Se introduc activit ățile manual, în ordine cronologic ă, 
pentru intervalul dintre ultima retragere a cardului și 
introducerea curent ă a acestuia.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 30  
— Ora începerii primei activit ăți se seteaz ă la ora retragerii 
cardului. Pentru fiecare înregistrare ulterioar ă, ora 
începerii este presetat ă să urmeze imediat orei de 
încheiere a înregistr ării anterioare. Pentru fiecare acti ­
vitate se selecteaz ă tipul activit ății și ora încheierii.  
Procedura se încheie în momentul în care ora de încheiere a 
unei activit ăți introduse manual este aceea și cu ora inser ării 
cardului. Aparatura de înregistrare poate apoi permite, 
opțional, titularului cardului s ă modifice orice activitate 
introdusă manual, pân ă în momentul valid ării prin selectarea 
unei comenzi specifice. Ulterior, orice astfel de modific ări 
sunt interzise.  
3.6.3  Înregistrarea condi țiilor specifice  
(62) Aparatura de înregistrare permite conduc ătorului auto s ă 
introducă, în timp real, urm ătoarele dou ă condiții specifice:  
— „ÎN AFARA ZONEI DE APLICARE A REGLEMEN ­
TĂRILOR” (început, sfâr șit) 
— „TRASEU PARCURS PE FERIBOT/ÎN TREN” 
(început, sfâr șit). 
O condiție de tip „TRASEU PARCURS PE FERIBOT/ÎN 
TREN” nu se poate produce dac ă este deschis ă o condiție de 
tip „ÎN AFARA ZONEI DE APLICARE A REGLEMEN ­
TĂRILOR”.  
O condiție deschis ă de tip „ÎN AFARA ZONEI DE 
APLICARE A REGLEMENT ĂRILOR” trebuie s ă fie 
închisă în mod automat de c ătre aparatura de înregistrare 
dacă este introdus sau retras un card de conduc ător auto.  
O condiție deschis ă de tip „ÎN AFARA ZONEI DE 
APLICARE A REGLEMENT ĂRILOR” împiedic ă apariția 
următoarelor evenimente și avertismente:  
— conducere f ără un card adecvat;  
— avertismente asociate timpului de conducere continu ă. 
Indicatorul de început al condi ției „TRASEU PARCURS PE 
FERIBOT/ÎN TREN” se seteaz ă înainte de oprirea motorului 
pe feribot/în tren.  
O condiție deschisă de tip „TRASEU PARCURS PE FERI ­
BOT/ÎN TREN” trebuie s ă se încheie atunci când se produce 
oricare dintre urm ătoarele evenimente:  
— conduc ătorul auto încheie manual condi ția „TRASEU 
PARCURS PE FERIBOT/ÎN TREN”;  
— conduc ătorul auto î și retrage cardul;  
O condiție deschisă de tip „TRASEU PARCURS PE FERI ­
BOT/ÎN TREN” se încheie atunci când nu mai este valabil ă 
în temeiul normelor prev ăzute în Regulamentul (CE) 
nr. 561/2006.  
3.7 Gestionarea bloc ărilor efectuate de societate  
(63) Aceast ă funcție permite gestionarea bloc ărilor efectuate de o 
societate pentru a- și asigura accesul exclusiv la date în 
modul societate.  
(64) Bloc ările efectuate de societate constau într-o dat ă și o oră 
de începere (blocare) și într-o dat ă și o oră de sfârșit 
(deblocare) asociate identific ării societ ății pe baza 
numărului cardului de societate (la blocare).  
(65) Bloc ările pot fi „activate” sau „dezactivate” numai în timp 
real. 
(66) Deblocarea poate fi efectuat ă numai de c ătre societatea a 
cărei blocare este „activ ă” (conform identific ării pe baza 
primelor 13 caractere din num ărul cardului de societate) sau  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 31  
(67) Deblocarea este automat ă dacă o altă societate efectueaz ă o 
blocare.  
(68) Dac ă o societate efectueaz ă o blocare și dacă blocarea ante ­
rioară a fost efectuat ă de aceeași societate, se consider ă că 
blocarea anterioar ă nu a fost „dezactivat ă” și este înc ă 
„activă”. 
3.8 Monitorizarea activit ăților de control  
(69) Aceast ă funcție monitorizeaz ă activitățile de AFI ȘARE, 
IMPRIMARE, DESC ĂRCARE din VU și de pe card și de 
verificare a ETALON ĂRII ÎN TRAFIC, realizate în modul 
control.  
(70) Aceast ă funcție monitorizeaz ă, de asemenea, activit ățile de 
CONTROL AL DEP ĂȘIRII LIMITEI DE VITEZ Ă în 
modul control. Se consider ă că a avut loc un control al 
depășirii limitei de vitez ă dacă, în modul control, mesajul 
„depășirea limitei de vitez ă” a fost trimis spre imprimant ă 
sau pe ecran sau dac ă din memoria de date a VU au fost 
descărcate date privind „evenimente sau anomalii”.  
3.9 Detectarea evenimentelor și/sau a anomaliilor  
(71) Aceast ă funcție detecteaz ă următoarele evenimente și/sau 
anomalii:  
3.9.1  Evenimentul „Introducerea unui card nevalabil”  
(72) Acest eveniment este declan șat de introducerea oric ărui card 
nevalabil, de introducerea unui card de conduc ător auto deja 
înlocuit și/sau la expirarea unui card valabil introdus.  
3.9.2  Evenimentul „Conflict de carduri”  
(73) Acest eveniment este declan șat la producerea oric ăreia dintre 
combinațiile de carduri valabile notate cu X din tabelul 
următor: 
Conflict de carduri  Slot pentru cardul de conduc ător auto  
Niciun card  Card de 
conducător auto  Card de control  Card de atelier  Card de societate
 Slot pentru cardul copilotului 
Niciun card  
Card de conduc ător 
auto X 
Card de control  X  X  X  
Card de atelier  X  X  X  X  
Card de societate  X  X  X  
3.9.3  Evenimentul „Suprapunere a timpului”  
(74) Acest eveniment este declan șat atunci când ora/data ultimei 
retrageri a unui card de conduc ător auto, a șa cum este citit ă 
de pe card, sunt ulterioare datei/orei curente înregistrate de 
aparatura de înregistrare în care este introdus cardul 
respectiv.  
3.9.4  Evenimentul „Conducere f ără un card adecvat”  
(75) Acest eveniment este declan șat de oricare dintre combina țiile 
de carduri de tahograf valabile notate cu X din tabelul 
următor, atunci când activitatea conduc ătorului auto se 
modifică devenind CONDUCERE sau când intervine o 
schimbare a modului de func ționare în timp ce activitatea 
conducătorului auto este CONDUCERE:  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 32  
Conducere f ără un card adecvat  Slot pentru cardul de conduc ător auto  
Niciun card (sau 
card nevalabil)  Card de 
conducător auto  Card de control  Card de atelier  Card de societate
 Slot pentru cardul copilotului Niciun card (sau card 
nevalabil)  X X  X  
Card de conduc ător 
auto X X  X  X  
Card de control  X  X  X  X  X  
Card de atelier  X  X  X  X  
Card de societate  X  X  X  X  X  
3.9.5  Evenimentul „Introducerea cardului în timpul conducerii”  
(76) Acest eveniment este declan șat la introducerea unui card de 
tahograf în orice slot în timp ce activitatea conduc ătorului 
auto este CONDUCERE.  
3.9.6  Evenimentul „Încheierea incorect ă a ultimei sesiuni”  
(77) Acest eveniment este declan șat atunci când, la introducerea 
unui card, aparatura de înregistrare detecteaz ă faptul că, în 
pofida dispozi țiilor de la punctul 3.1, sesiunea anterioar ă de 
utilizare a cardului nu a fost încheiat ă corect (cardul a fost 
retras înainte ca toate datele relevante s ă fi fost stocate pe 
el). Acest eveniment este declan șat numai de cardul de 
conducător auto și de cardul de atelier.  
3.9.7  Evenimentul „Dep ășirea limitei de vitez ă” 
(78) Acest eveniment este declan șat pentru fiecare dep ășire a 
limitei de vitez ă. 
3.9.8  Evenimentul „Întreruperea aliment ării cu energie electric ă” 
(79) Acest eveniment este declan șat, în celelalte moduri decât 
modul etalonare sau control, în cazul oric ărei întreruperi a 
alimentării cu energie electric ă a senzorului de mi șcare 
și/sau a unit ății montate pe vehicul, care dureaz ă mai mult 
de 200 de milisecunde. Pragul de întrerupere este stabilit de 
producător. Scăderea nivelului de alimentare cu energie 
datorată pornirii motorului nu declan șează acest eveniment.  
3.9.9  Evenimentul „Eroare de comunicare cu echipamentul de comu ­
nicare la distan ță” 
(80) Acest eveniment se declan șează, în celelalte moduri decât 
modul etalonare , dacă echipamentul de comunicare la 
distanță nu confirm ă recepționarea cu succes a datelor de 
comunicare la distan ță transmise de unitatea montat ă pe 
vehicul dup ă mai mult de trei încerc ări. 
3.9.10  Evenimentul „Absen ța informa țiilor de pozi ționare de la receptorul 
GNSS”  
(81) Acest eveniment se declan șează, în celelalte moduri decât 
modul etalonare , în cazul absen ței informa țiilor de 
poziționare provenind de la receptorul GNSS (intern sau 
extern) timp de peste trei ore de timp de conducere 
acumulat.  
3.9.11  Evenimentul „Eroare de comunicare cu echipamentul GNSS extern”  
(82) Acest eveniment se declan șează, în celelalte moduri decât 
modul etalonare , în cazul întreruperii comunic ării între 
echipamentul GNSS extern și unitatea montat ă pe vehicul, 
timp de peste 20 de minute în continuu, atunci când 
vehiculul este în mi șcare. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 33  
3.9.12  Evenimentul „Eroare privind datele de la senzorul de mi șcare”  
(83) Acest eveniment este declan șat, în celelalte moduri decât 
modul etalonare , în cazul întreruperii fluxului normal de 
date dintre senzorul de mi șcare și unitatea montat ă pe 
vehicul și/sau în cazul unor erori de integritate sau de auten ­
tificare a datelor survenite în timpul schimbului de date 
dintre senzorul de mi șcare și unitatea montat ă pe vehicul.  
3.9.13  Evenimentul „Conflict privind deplasarea vehiculului”  
(84) Acest eveniment se declan șează, în celelalte moduri decât 
modul etalonare , în cazul în care informa țiile privind 
deplasarea calculate de senzorul de mi șcare sunt contrazise 
de informa țiile privind deplasarea calculate de receptorul 
GNSS intern sau de echipamentul GNSS extern și, 
opțional, de alte surse independente, dup ă cum se specific ă 
în apendicele 12. Acest eveniment nu se declan șează în 
timpul unui traseu parcurs pe feribot/în tren, în timpul 
afișării condiției „ÎN AFARA ZONEI DE APLICARE A 
REGLEMENT ĂRILOR” sau atunci când informa țiile de 
poziționare transmise de receptorul GNSS nu sunt dispo ­
nibile.  
3.9.14  Evenimentul „Tentativ ă de încălcare a securit ății” 
(85) Acest eveniment este declan șat, în celelalte moduri decât 
modul etalonare, în cazul survenirii oric ărui alt eveniment 
care afecteaz ă securitatea senzorului de mi șcare și/sau a 
unității montate pe vehicul și/sau a echipamentului GNSS 
extern, în conformitate cu apendicele 10.  
▼M1 
3.9.15  Evenimentul „Conflict or ă” 
(86) Acest eveniment este declan șat, în celelalte moduri decât 
modul etalonare , atunci când VU detecteaz ă o diferență de 
peste 1 minut între ora calculat ă de funcția de măsurare a 
timpului a VU și ora transmis ă de receptorul GNSS. Acest 
eveniment este înregistrat împreun ă cu valoarea indicat ă de 
ceasul intern al unit ății montate pe vehicul și este înso țit de 
o reglare automat ă a orei. Dup ă declanșarea unui eveniment 
de tip „Conflict or ă”, VU nu va mai genera alte evenimente 
de tip „Conflict or ă” în următoarele 12 ore. Acest eveniment 
nu se declan șează în cazul în care receptorul GNSS nu a 
putut detecta niciun semnal GNSS valabil timp de 30 de zile 
sau mai mult.  
▼B 
3.9.16  Anomalia „Card”  
(87) Aceast ă anomalie este declan șată în cazul unei disfunc ții a 
unui card de tahograf în curs de func ționare.  
3.9.17  Anomalia „Aparatura de înregistrare”  
(88) Aceast ă anomalie este declan șată în cazul survenirii oric ăreia 
dintre urm ătoarele defec țiuni, în celelalte moduri decât 
modul etalonare:  
— Anomalie intern ă a VU  
— Anomalie a imprimantei  
— Anomalie a afi șajului  
— Anomalie la desc ărcare  
— Anomalie a senzorului  
— Anomalie a receptorului GNSS sau a echipamentului 
GNSS extern  
— Anomalie a echipamentului de comunicare la distan ță 
▼M1 
— Anomalie a interfe ței ITS (dac ă este cazul)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 34  
3.10 Teste integrate și autoteste  
(89) ►M1 Aparatura de înregistrare detecteaz ă anomaliile prin 
autoteste și teste integrate, în conformitate cu tabelul 
următor: ◄ 
Subansamblu de testat  Autotest  Test integrat  
Software  Integritate  
Memorie de date  Acces  Acces, integritatea datelor  
Dispozitive de interfa ță 
pentru card  Acces  Acces  
Tastatură Verificare manual ă 
Imprimantă (la latitudinea 
producătorului)  Imprimare  
Afișaj Verificare vizual ă 
Descărcare 
(se efectueaz ă numai în 
timpul desc ărcărilor)  Funcționare cores ­
punzătoare  
Senzor  Func ționare cores ­
punzătoare  Funcționare corespunz ă­
toare  
Echipament de comunicare la 
distanță Funcționare cores ­
punzătoare  Funcționare corespunz ă­
toare  
Echipament GNSS  Func ționare cores ­
punzătoare  Funcționare corespunz ă­
toare 
▼M1 
Interfața ITS (opțional)  Func ționare cores ­
punzătoare 
▼B 
3.11 Citirea din memoria de date  
(90) Aparatura de înregistrare trebuie s ă poată citi orice date 
stocate în memoria sa de date.  
3.12 Înregistrarea și stocarea în memoria de date  
În sensul prezentului alineat,  
— „365 de zile” înseamn ă 365 de zile calendaristice de activitate 
medie a conduc ătorilor auto într-un vehicul. Activitatea medie 
pe zi într-un vehicul implic ă cel puțin 6 conduc ători auto sau 
copiloți, 6 cicluri de introducere și retragere de carduri și 256 de 
schimbări de activitate. Prin urmare, „365 de zile” implic ă cel 
puțin 2 190 de conduc ători auto (copilo ți), 2 190 de cicluri de 
introducere și retragere de carduri și 93 440 de schimb ări de 
activitate;  
▼M1 
— numărul mediu de pozi ții pe zi înseamn ă cel puțin șase poziții în 
care începe ziua de lucru, șase poziții în care timpul de 
conducere acumulat atinge un multiplu de trei ore și șase 
poziții în care se încheie ziua de lucru, astfel încât „365 de 
zile” includ cel pu țin 6 570 de pozi ții; 
▼B 
— orele sunt înregistrate cu o rezolu ție de un minut, cu excep ția 
cazurilor în care se specific ă altfel;  
— valorile odometrului sunt înregistrate cu o rezolu ție de un kilo ­
metru;  
— vitezele sunt înregistrate cu o rezolu ție de 1 km/h;  
— pozițiile (latitudinile și longitudinile) sunt înregistrate în grade și 
minute, cu o rezolu ție de 1/10 de minut, cu precizia și cu timpul 
de achiziție ale GNSS aferente.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 35  
(91) Datele stocate în memoria de date nu trebuie s ă fie afectate de 
o întrerupere a aliment ării externe cu energie electric ă cu 
durata mai scurt ă de douăsprezece luni, în condi ții de 
omologare de tip. În plus, datele stocate în echipamentul 
extern de comunicare la distan ță, astfel cum este definit în 
apendicele 14, nu trebuie s ă fie afectate de întreruperi ale 
alimentării cu energie electric ă cu durata mai scurt ă de 28 
de zile.  
(92) Aparatura de înregistrare poate înregistra și stoca implicit sau 
explicit în memoria sa de date urm ătoarele detalii:  
3.12.1  Date de identificare a aparaturii  
3.12.1.1 D a t e d e i d e n t i f i c a r e a u n i t ă ț i i m o n t a t e p e 
v e h i c u l  
(93) Aparatura de înregistrare permite stocarea, în memoria sa de 
date, a urm ătoarelor date de identificare a unit ății montate pe 
vehicul:  
— denumirea produc ătorului;  
— adresa produc ătorului;  
— numărul de component ă; 
— numărul de serie;  
— generația VU;  
— capacitatea de a utiliza carduri de tahograf de prim ă gene­
rație; 
— numărul versiunii de software;  
— data de instalare a versiunii de software;  
— anul fabrica ției aparaturii;  
— numărul de omologare;  
(94) Datele de identificare a unit ății montate pe vehicul sunt înre ­
gistrate și stocate definitiv de produc ătorul unității montate pe 
vehicul, cu excep ția datelor legate de software și a numărului 
de omologare, care pot fi modificate în cazul moderniz ării 
software-ului, precum și al capacit ății de utilizare a cardurilor 
de tahograf de prim ă generație. 
3.12.1.2 D a t e d e i d e n t i f i c a r e a s e n z o r u l u i d e m i ș c a r e  
(95) Senzorul de mi șcare trebuie s ă poată stoca în memoria sa 
următoarele date de identificare:  
— denumirea produc ătorului;  
— numărul de serie;  
— numărul de omologare;  
— identificatorul componentei integrate de securitate (de 
exemplu, num ărul de component ă al cipului/procesorului 
intern);  
— identificatorul sistemului de operare (de exemplu, num ărul 
versiunii de software).  
(96) Datele de identificare a senzorului de mi șcare sunt înregistrate 
și stocate definitiv în senzorul de mi șcare de produc ătorul 
acestuia.  
(97) Unitatea montat ă pe vehicul trebuie s ă poată înregistra și 
stoca în memoria sa de date urm ătoarele date legate de cele 
mai recente 20 de asocieri ale senzorilor de mi șcare (dacă, în 
cursul unei zile calendaristice, au loc mai multe asocieri, se 
stochează numai prima și ultima asociere din ziua respectiv ă): ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 36  
Pentru fiecare dintre aceste asocieri se înregistreaz ă urmă­
toarele date:  
— datele de identificare a senzorului de mi șcare:  
— numărul de serie;  
— numărul de omologare;  
— datele privind asocierea senzorului de mi șcare:  
— data asocierii.  
3.12.1.3 D a t e d e i d e n t i f i c a r e a s i s t e m u l u i g l o b a l d e 
n a v i g a ț i e p r i n s a t e l i t  
(98) Echipamentul GNSS extern trebuie s ă poată stoca în memoria 
sa următoarele date de identificare:  
— denumirea produc ătorului;  
— numărul de serie;  
— numărul de omologare;  
— identificatorul componentei integrate de securitate (de 
exemplu num ărul de component ă al cipului/procesorului 
intern);  
— identificatorul sistemului de operare (de exemplu num ărul 
versiunii de software).  
(99) Datele de identificare a echipamentului GNSS extern sunt 
înregistrate și stocate definitiv în echipamentul GNSS extern 
de producătorul acestuia.  
(100) Unitatea montat ă pe vehicul trebuie s ă poată înregistra și 
stoca în memoria sa de date urm ătoarele date legate de cele 
mai recente 20 de cupl ări ale echipamentelor GNSS externe 
(dacă, în cursul unei zile calendaristice, au loc mai multe 
cuplări, se stocheaz ă numai prima și ultima cuplare din ziua 
respectivă): 
Pentru fiecare dintre aceste cupl ări se înregistreaz ă urmă­
toarele date:  
— datele de identificare a echipamentului GNSS extern:  
— numărul de serie;  
— numărul de omologare;  
— date privind cuplarea echipamentului GNSS extern:  
— data cupl ării. 
3.12.2  Chei și certificate  
(101) Aparatura de înregistrare poate stoca o serie de chei și certi­
ficate criptografice, în conformitate cu apendicele 11 p ărțile A 
și B. 
3.12.3  Date privind introducerea și retragerea cardului de conduc ător 
auto sau ale cardului de atelier  
(102) Pentru fiecare ciclu de introducere și retragere a unui card de 
conducător auto sau a unui card de atelier, aparatura de înre ­
gistrare înregistreaz ă și stocheaz ă în memoria sa de date 
următoarele detalii:  
— numele și prenumele titularului cardului, astfel cum sunt 
stocate pe card;  
— numărul cardului, statul membru emitent și data expir ării, 
astfel cum sunt stocate pe card;  
— generația cardului;  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 37  
— ora și data introducerii cardului;  
— valoarea indicat ă de odometrul vehiculului în momentul 
introducerii cardului;  
— slotul în care este introdus cardul;  
— data și ora retragerii cardului;  
— valoarea indicat ă de odometrul vehiculului în momentul 
retragerii cardului;  
— următoarele informa ții privind vehiculul utilizat anterior 
de conduc ătorul auto, astfel cum sunt stocate pe card:  
— VRN și statul membru de înmatriculare;  
— generația VU (atunci când aceast ă informație este 
disponibilă); 
— data și ora retragerii cardului;  
— un indicator de stare care arat ă dacă, la introducerea 
cardului, titularul acestuia a introdus manual activit ăți 
sau nu.  
(103) Memoria de date trebuie s ă poată stoca aceste date timp de 
cel puțin 365 de zile.  
(104) La epuizarea capacit ății de stocare, datele noi înlocuiesc 
datele cele mai vechi.  
3.12.4  Date privind activitatea conduc ătorului auto  
(105) Aparatura de înregistrare înregistreaz ă și stocheaz ă în 
memoria sa de date urm ătoarele informa ții de fiecare dat ă 
când survine o modificare a activit ății conducătorului auto 
și/sau a copilotului și/sau de fiecare dat ă când se modific ă 
regimul de conducere și/sau de fiecare dat ă când este introdus 
sau retras un card de conduc ător auto sau de atelier:  
— regimul de conducere (ECHIPAJ, SINGUR);  
— slotul (CONDUC ĂTOR AUTO, COPILOT);  
— starea cardului în slotul relevant (INTRODUS, NEIN ­
TRODUS);  
— activitatea (CONDUCERE, DISPONIBILITATE, 
MUNCĂ, PAUZĂ/ODIHNĂ); 
— data și ora modific ării. 
INTRODUS înseamn ă că în slot este introdus un card de 
conducător auto sau un card de atelier valabil. NEIN ­
TRODUS înseamn ă starea opus ă, și anume faptul c ă în slot 
nu este introdus un card de conduc ător auto sau de atelier 
valabil (de exemplu, este introdus un card de societate sau nu 
este introdus niciun card).  
Datele privind activitatea introduse manual de un conduc ător 
auto nu sunt înregistrate în memoria de date.  
(106) Memoria de date trebuie s ă poată stoca datele privind acti ­
vitatea conduc ătorului auto timp de cel pu țin 365 de zile.  
(107) La epuizarea capacit ății de stocare, datele noi înlocuiesc 
datele cele mai vechi.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 38  
3.12.5  Locuri și poziții în care încep și se încheie zilele de lucru și/sau în 
care se atinge timpul de conducere acumulat de trei ore  
(108) Aparatura de înregistrare înregistreaz ă și stocheaz ă în 
memoria sa de date:  
— locurile și pozițiile în care conduc ătorul auto și/sau 
copilotul î și încep(e) ziua de lucru;  
— pozițiile în care timpul de conducere acumulat atinge un 
multiplu de trei ore;  
— locurile și pozițiile în care conduc ătorul auto și/sau 
copilotul î și încheie ziua de lucru.  
▼B 
(109) Atunci când pozi ția vehiculului nu este disponibil ă din 
receptorul GNSS în momentele respective, aparatura de înre ­
gistrare utilizeaz ă ultima pozi ție disponibil ă, precum și data și 
ora aferente.  
(110) Aparatura de înregistrare înregistreaz ă și stocheaz ă în 
memoria sa de date, împreun ă cu fiecare loc sau pozi ție, 
următoarele elemente:  
— numărul cardului conduc ătorului auto (copilotului) și 
statul membru emitent al cardului;  
— generația cardului;  
— data și ora introducerii;  
▼M1 
— tipul de introducere (început, încheiere sau timp de 
conducere acumulat de trei ore);  
▼B 
— precizia GNSS, data și ora aferente, dac ă este cazul;  
— valoarea indicat ă de odometrul vehiculului.  
▼M1 
(111) Memoria de date trebuie s ă poată păstra, timp de cel pu țin 
365 de zile, locurile și pozițiile în care încep și se încheie 
zilele de lucru și/sau în care se atinge timpul de conducere 
acumulat de trei ore.  
▼B 
(112) La epuizarea capacit ății de stocare, datele noi înlocuiesc 
datele cele mai vechi.  
3.12.6  Date privind odometrul  
(113) Aparatura de înregistrare înregistreaz ă în memoria sa de date 
valoarea indicat ă de odometrul vehiculului și data respectiv ă 
la ora 00.00 a fiec ărei zile calendaristice.  
(114) Memoria de date trebuie s ă poată stoca valorile indicate de 
odometru la ora 00.00 timp de cel pu țin 365 de zile calenda ­
ristice.  
(115) La epuizarea capacit ății de stocare, datele noi înlocuiesc 
datele cele mai vechi.  
3.12.7  Date privind viteza detaliat ă 
▼M1 
(116) Aparatura de înregistrare înregistreaz ă și stocheaz ă în 
memoria sa de date, o dat ă pe secund ă, viteza detaliat ă a 
vehiculului, precum și data și ora corespunz ătoare acesteia, 
cel puțin pe parcursul ultimelor 24 de ore în care vehiculul a 
fost în mișcare. 
▼B 
3.12.8  Date privind evenimentele  
În sensul prezentului paragraf, timpul se înregistreaz ă cu o rezolu ție 
de 1 secund ă. 
(117) Aparatura de înregistrare înregistreaz ă și stocheaz ă în 
memoria sa de date urm ătoarele date pentru fiecare 
eveniment detectat, conform urm ătoarelor reguli de stocare:  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 39  
Eveniment  Reguli de stocare  Date de înregistrat pentru fiecare eveniment  
Introducerea unui card neva ­
labil — cele mai recente 10 evenimente.  — data și ora evenimentului; 
— tipul și numărul cardului (cardurilor), 
statul membru emitent și generația 
cardului care a creat evenimentul; 
— numărul de evenimente similare din 
ziua respectiv ă. 
Conflict de carduri  — cele mai recente 10 evenimente.  — data și ora începerii evenimentului; 
— data și ora încheierii evenimentului; 
— tipul și numărul cardului (cardurilor), 
statul membru emitent și generația 
celor dou ă carduri care au creat 
conflictul.  
Conducere f ără un card 
adecvat  — evenimentul cel mai de durat ă 
survenit în fiecare din ultimele 10 
zile de producere; 
— cele mai de durat ă 5 evenimente din 
ultimele 365 de zile;  — data și ora începerii evenimentului; 
— data și ora încheierii evenimentului; 
— tipul și numărul cardului (cardurilor), 
statul membru emitent și generația 
oricărui card introdus la începutul și/ 
sau la încheierea evenimentului; 
— numărul de evenimente similare din 
ziua respectiv ă. 
Introducerea cardului în timpul 
conducerii  — ultimul eveniment din fiecare dintre 
ultimele 10 zile de producere;  — data și ora evenimentului; 
— tipul, num ărul, statul membru emitent 
și generația cardului (cardurilor); 
— numărul de evenimente similare din 
ziua respectiv ă. 
Încheiere incorect ă a ultimei 
sesiuni  — cele mai recente 10 evenimente.  — data și ora introducerii cardului; 
— tipul, num ărul, statul membru emitent 
și generația cardului (cardurilor); 
— datele privind ultima sesiune a șa cum 
au fost citite de pe card: 
— data și ora introducerii cardului; 
— VRN, statul membru de înmatri ­
culare și generația VU.  
Depășirea limitei de vitez ă (1) — cel mai grav eveniment survenit în 
fiecare din ultimele 10 zile de 
producere ( și anume, cea mai mare 
viteză medie înregistrat ă); 
— cele mai grave 5 evenimente survenite 
în ultimele 365 de zile; 
— primul eveniment survenit dup ă 
ultima etalonare;  — data și ora începerii evenimentului; 
— data și ora încheierii evenimentului; 
— viteza maxim ă măsurată în cursul 
evenimentului; 
— media aritmetic ă a vitezei m ăsurate în 
cursul evenimentului; 
— tipul și numărul cardului (cardurilor), 
statul membru emitent și generația 
cardului de conduc ător auto (dac ă 
este cazul); 
— numărul de evenimente similare din 
ziua respectiv ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 40  
Eveniment  Reguli de stocare  Date de înregistrat pentru fiecare eveniment  
Întreruperea aliment ării cu 
energie electric ă (2) — evenimentul cel mai de durat ă din 
fiecare dintre ultimele 10 zile de 
producere; 
— cele mai de durat ă 5 evenimente din 
ultimele 365 de zile;  — data și ora începerii evenimentului; 
— data și ora încheierii evenimentului; 
— tipul și numărul cardului (cardurilor), 
statul membru emitent și generația 
oricărui card introdus la începutul și/ 
sau la încheierea evenimentului; 
— numărul de evenimente similare din 
ziua respectiv ă. 
Eroare de comunicare cu echi ­
pamentul de comunicare la 
distanță — evenimentul cel mai de durat ă din 
fiecare dintre ultimele 10 zile de 
producere; 
— cele mai de durat ă 5 evenimente din 
ultimele 365 de zile;  — data și ora începerii evenimentului; 
— data și ora încheierii evenimentului; 
— tipul și numărul cardului (cardurilor), 
statul membru emitent și generația 
oricărui card introdus la începutul și/ 
sau la încheierea evenimentului; 
— numărul de evenimente similare din 
ziua respectiv ă. 
Absența informa țiilor de 
poziționare de la receptorul 
GNSS  — evenimentul cel mai de durat ă din 
fiecare dintre ultimele 10 zile de 
producere; 
— cele mai de durat ă 5 evenimente din 
ultimele 365 de zile;  — data și ora începerii evenimentului; 
— data și ora încheierii evenimentului; 
— tipul și numărul cardului (cardurilor), 
statul membru emitent și generația 
oricărui card introdus la începutul și/ 
sau la încheierea evenimentului; 
— numărul de evenimente similare din 
ziua respectiv ă. 
▼M1 
Eroare de comunicare cu echi ­
pamentul GNSS extern  — evenimentul cel mai de durat ă din 
fiecare dintre ultimele 10 zile de 
producere, 
— cele mai de durat ă cinci evenimente 
din ultimele 365 de zile.  — data și ora începerii evenimentului, 
— data și ora încheierii evenimentului, 
— tipul și numărul cardului (cardurilor), 
statul membru emitent și generația 
oricărui card introdus la începutul și/ 
sau la încheierea evenimentului, 
— numărul de evenimente similare din 
ziua respectiv ă. 
▼B 
Eroare privind datele de la 
senzorul de mi șcare — evenimentul cel mai de durat ă din 
fiecare dintre ultimele 10 zile de 
producere; 
— cele mai de durat ă 5 evenimente din 
ultimele 365 de zile;  — data și ora începerii evenimentului; 
— data și ora încheierii evenimentului; 
— tipul și numărul cardului (cardurilor), 
statul membru emitent și generația 
oricărui card introdus la începutul și/ 
sau la încheierea evenimentului; 
— numărul de evenimente similare din 
ziua respectiv ă. 
Conflict privind deplasarea 
vehiculului  — evenimentul cel mai de durat ă din 
fiecare dintre ultimele 10 zile de 
producere; 
— cele mai de durat ă 5 evenimente din 
ultimele 365 de zile;  — data și ora începerii evenimentului; 
— data și ora încheierii evenimentului; 
— tipul și numărul cardului (cardurilor), 
statul membru emitent și generația 
oricărui card introdus la începutul și/ 
sau la încheierea evenimentului; 
— numărul de evenimente similare din 
ziua respectiv ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 41  
Eveniment  Reguli de stocare  Date de înregistrat pentru fiecare eveniment  
Tentativă de încălcare a secu ­
rității — cele mai recente 10 evenimente, per 
tip de eveniment.  — data și ora începerii evenimentului; 
— data și ora sfârșitului evenimentului 
(dacă sunt relevante); 
— tipul și numărul cardului (cardurilor), 
statul membru emitent și generația 
oricărui card introdus la începutul și/ 
sau la încheierea evenimentului; 
— tipul evenimentului.  
▼M1 
Conflict or ă — cel mai grav eveniment survenit în 
fiecare din ultimele 10 zile de 
producere ( și anume, cele cu cea mai 
mare diferen ță dintre data și ora 
indicate de aparatura de înregistrare 
și data și ora GNSS). 
— cele mai grave cinci evenimente 
survenite în ultimele 365 de zile.  — data și ora indicate de aparatura de 
înregistrare, 
— data și ora GNSS, 
— tipul și numărul cardului (cardurilor), 
statul membru emitent și generația 
oricărui card introdus la începutul și/ 
sau la încheierea evenimentului, 
— numărul de evenimente similare din 
ziua respectiv ă. 
▼B 
(1) Aparatura de înregistrare înregistreaz ă și stocheaz ă, de 
asemenea, în memoria sa de date:  
— data și ora ultimului CONTROL AL DEP ĂȘIRII 
LIMITEI DE VITEZ Ă; 
— data și ora primului eveniment de tip „Dep ășirea 
limitei de vitez ă”survenit dup ă efectuarea respec ­
tivului CONTROL AL DEP ĂȘIRII LIMITEI DE 
VITEZĂ. 
— numărul de evenimente de tip „Dep ășirea limitei de 
viteză” survenite de la ultimul CONTROL AL 
DEPĂȘIRII LIMITEI DE VITEZ Ă. 
(2) Aceste date pot fi înregistrate numai în momentul reco ­
nectării la sursa de energie electric ă, orele pot fi 
cunoscute cu o precizie de un minut.  
3.12.9  Date privind anomaliile  
În sensul prezentului paragraf, timpul se înregistreaz ă cu o rezolu ție 
de 1 secund ă. 
(118) Aparatura de înregistrare încearc ă să înregistreze și să 
stocheze în memoria sa de date urm ătoarele date pentru 
fiecare anomalie detectat ă conform urm ătoarelor reguli de 
stocare:  
Anomalie  Reguli de stocare  Date care trebuie înregistrate pentru fiecare 
anomalie  
Anomalie a cardului  — cele mai recente 10 anomalii ale 
cardului de conduc ător auto.  — data și ora începerii anomaliei; 
— data și ora încheierii anomaliei; 
— tipul, num ărul, statul membru emitent și 
generația cardului (cardurilor).  
Anomalii ale aparaturii de 
înregistrare  — cele mai recente 10 anomalii pentru 
fiecare tip de anomalie; 
— prima anomalie survenit ă după ultima 
etalonare.  — data și ora începerii anomaliei; 
— data și ora încheierii anomaliei; 
— tipul de anomalie; 
— tipul, num ărul și statul membru emitent 
al cardului (cardurilor), precum și 
generația oricărui card introdus la 
începutul și/sau la încheierea anomaliei;  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 42  
3.12.10  Date privind etalonarea  
(119) Aparatura de înregistrare înregistreaz ă și stocheaz ă în 
memoria sa de date urm ătoarele date relevante privind:  
— parametrii de etalonare cunoscu ți în momentul activ ării; 
— prima sa etalonare dup ă activare;  
— prima sa etalonare dup ă instalarea în vehiculul respectiv 
(identificat pe baza VIN);  
— cele mai recente 20 de etalon ări (dacă pe parcursul unei 
zile calendaristice se efectueaz ă mai multe etalon ări, nu 
este stocat ă decât ultima etalonare efectuat ă în ziua 
respectivă). 
(120) Pentru fiecare dintre aceste etalon ări se înregistreaz ă urmă­
toarele date:  
— scopul etalon ării (activare, prima instalare, instalare, 
inspecție periodic ă); 
— denumirea și adresa atelierului;  
— numărul cardului de atelier, statul membru emitent al 
cardului și data expir ării cardului;  
— identificarea vehiculului;  
— parametrii actualiza ți sau confirma ți: w, k, l, dimensiunea 
pneurilor, reglajul limitatorului de vitez ă, odometrul 
(valorile vechi și cele noi), data și ora (valorile vechi și 
cele noi);  
— tipurile și identificatorii tuturor sigiliilor montate.  
(121) În plus, aparatura de înregistrare înregistreaz ă și stochează în 
memoria sa de date capacitatea sa de a utiliza carduri de 
tahograf de prim ă generație (încă activate sau nu).  
(122) Senzorul de mi șcare înregistreaz ă și stochează în memoria sa 
următoarele date privind instalarea senzorului de mi șcare:  
— prima asociere la o VU (data, ora, num ărul de omologare 
al VU, num ărul de serie al VU);  
— ultima asociere la o VU (data, ora, num ărul de omologare 
al VU, num ărul de serie al VU).  
(123) Echipamentul GNSS extern înregistreaz ă și stocheaz ă în 
memoria sa urm ătoarele date privind instalarea echipa ­
mentului GNSS extern:  
— prima cuplare la o VU (data, ora, num ărul de omologare 
al VU, num ărul de serie al VU);  
— prima cuplare la o VU (data, ora, num ărul de omologare 
al VU, num ărul de serie al VU).  
3.12.11  Date privind reglarea orei  
(124) Aparatura de înregistrare înregistreaz ă și stocheaz ă în 
memoria sa de date urm ătoarele date legate de regl ările orei 
efectuate în modul etalonare, în afara cadrului unei etalon ări 
normale [a se vedea defini ția de la litera (f)]:  
— cea mai recent ă reglare a orei;  
— cele mai importante 5 regl ări ale orei.  
(125) Pentru fiecare dintre aceste regl ări ale orei se înregistreaz ă 
următoarele date:  
— data și ora, valoarea veche;  
— data și ora, valoarea nou ă; 
— denumirea și adresa atelierului;  
— numărul cardului de atelier, statul membru emitent al 
cardului și data expir ării cardului.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 43  
3.12.12  Date privind activit ățile de control  
(126) Aparatura de înregistrare înregistreaz ă și stocheaz ă în 
memoria sa de date urm ătoarele date privind cele mai 
recente 20 de activit ăți de control:  
— data și ora controlului;  
— numărul cardului de control, statul membru emitent al 
cardului și generația cardului;  
— tipul de control (afi șare și/sau imprimare și/sau descărcare 
din VU și/sau descărcare de pe card și/sau verificare a 
etalonării în trafic).  
(127) Pentru desc ărcări se înregistreaz ă și datele desc ărcate privind 
ziua cea mai îndep ărtată și ziua cea mai recent ă. 
3.12.13  Date privind bloc ările efectuate de societate  
(128) Aparatura de înregistrare înregistreaz ă și stocheaz ă în 
memoria sa de date urm ătoarele date privind cele mai 
recente 255 de bloc ări efectuate de societate:  
— data și ora blocării; 
— data și ora debloc ării; 
— numărul cardului de societate, statul membru emitent al 
cardului și generația cardului;  
— denumirea și adresa societ ății. 
Datele blocate anterior printr-un blocaj scos din memorie din 
cauza limitei de mai sus se consider ă a nu fi blocate.  
3.12.14  Date privind activit ățile de desc ărcare  
(129) Aparatura de înregistrare înregistreaz ă și stocheaz ă în 
memoria sa de date urm ătoarele date privind ultima 
descărcare de date din memorie de date pe un suport extern 
efectuată în modul societate sau etalonare:  
— data și ora descărcării; 
— numărul cardului de societate sau al cardului de atelier, 
statul membru emitent al cardului și generația cardului;  
— denumirea societ ății sau a atelierului.  
3.12.15  Date privind condi țiile specifice  
(130) Aparatura de înregistrare înregistreaz ă și stocheaz ă în 
memoria sa de date urm ătoarele date privind situa țiile 
speciale:  
— data și ora înregistr ării; 
— tipul condi ției speciale.  
(131) Memoria de date permite stocarea de date privind condi țiile 
specifice timp de cel pu țin 365 de zile (presupunând c ă pe zi 
se deschide și se închide în medie o condi ție specific ă). La 
epuizarea capacit ății de stocare, datele noi înlocuiesc datele 
cele mai vechi.  
3.12.16  Date privind cardul de tahograf  
(132) Aparatura de înregistrare permite stocarea urm ătoarelor date 
referitoare la diferitele carduri de tahograf care au fost 
utilizate în VU:  
— numărul și numărul de serie al cardului de tahograf;  
— produc ătorul cardului de tahograf;  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 44  
— tipul cardului de tahograf;  
— versiunea cardului de tahograf.  
(133) Aparatura de înregistrare permite stocarea a cel pu țin 88 de 
astfel de înregistr ări. 
3.13 Citirea de pe cardurile de tahograf  
(134) Aparatura de înregistrare permite citirea de pe cardurile de 
tahograf de prima și a doua genera ție, dacă este cazul, a 
datelor necesare:  
— pentru a identifica tipul de card, titularul cardului, 
vehiculul utilizat anterior, data și ora ultimei retrageri a 
cardului și activitatea selectat ă în momentul respectiv;  
— pentru a verifica dac ă ultima sesiune de utilizare a 
cardului a fost încheiat ă corect;  
— pentru a calcula timpul de conducere continu ă, durata 
cumulată a pauzelor și durata cumulat ă a orelor de 
conducere ale conduc ătorului auto pentru s ăptămâna 
respectivă și pentru cea anterioar ă; 
— pentru a imprima documentele necesare referitoare la 
datele înregistrate pe un card de conduc ător auto;  
— pentru a desc ărca datele de pe un card de conduc ător auto 
pe un suport extern.  
Această cerință se aplică numai cardurilor de tahograf de 
primă generație, dacă utilizarea acestora nu a fost invalidat ă 
de un atelier.  
(135) În cazul unei erori de citire, aparatura de înregistrare încearc ă 
din nou, de maximum trei ori, s ă efectueze aceea și comandă 
de citire, iar dac ă nu reușește declară cardul deficient și neva­
labil.  
3.14 Înregistrarea și stocarea pe cardurile de tahograf  
3.14.1  Înregistrarea și stocarea pe cardurile de tahograf de prim ă gene­
rație; 
(136) În cazul în care utilizarea cardurilor de tahograf de prim ă 
generație nu a fost suprimat ă de un atelier, aparatura de înre ­
gistrare înregistreaz ă și stochează date exact în acela și fel ca 
aparatura de înregistrare de prim ă generație. 
(137) Aparatura de înregistrare seteaz ă „datele privind sesiunea de 
utilizare a cardului” pe cardul de conduc ător auto sau de 
atelier imediat dup ă introducerea cardului.  
(138) Aparatura de înregistrare actualizeaz ă datele stocate pe 
cardurile de conduc ător auto, de atelier, de societate și/sau 
de control valabile cu toate datele necesare relevante pentru 
perioada în care este introdus cardul și pentru titularul 
cardului. Datele stocate pe aceste carduri sunt specificate în 
capitolul 4.  
(139) Aparatura de înregistrare actualizeaz ă datele privind acti ­
vitatea conduc ătorului auto și locurile (dup ă cum se 
specifică la punctele 4.5.3.1.9 și 4.5.3.1.11) stocate pe 
cardurile de conduc ător auto și/sau de atelier valabile cu 
datele privind activitatea și locurile care au fost introduse 
manual de titularul cardului.  
(140) Toate evenimentele care nu sunt definite în aparatura de înre ­
gistrare de prim ă generație nu se stocheaz ă pe cardurile de 
conducător auto și de atelier.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 45  
(141) Actualizarea datelor de pe cardurile de tahograf se face astfel 
încât, atunci când este necesar din punctul de vedere al capa ­
cității de stocare a cardului din momentul respectiv, datele 
cele mai recente s ă le înlocuiasc ă pe cele mai vechi.  
(142) În cazul unei erori de scriere, aparatura de înregistrare 
încearcă din nou, de maximum trei ori, s ă efectueze aceea și 
comandă de scriere, iar dac ă nu reușește declară cardul 
deficient și nevalabil.  
(143) Înainte de a elibera cardul de conduc ător auto și după ce toate 
datele relevante au fost stocate pe card, aparatura de înre ­
gistrare reseteaz ă „datele privind sesiunea de utilizare a 
cardului”.  
3.14.2  Înregistrarea și stocarea pe cardurile de tahograf de a doua 
generație 
(144) Cardurile de tahograf de a doua genera ție conțin 2 aplica ții de 
card diferite, dintre care prima este identic ă cu aplica ția 
TACHO pentru cardurile de tahograf de prim ă generație, iar 
a doua este aplica ția „TACHO_G2”, astfel cum este 
menționată la capitolul 4 și în apendicele 2.  
(145) Aparatura de înregistrare seteaz ă „datele privind sesiunea de 
utilizare a cardului” pe cardul de conduc ător auto sau de 
atelier imediat dup ă introducerea cardului.  
(146) Aparatura de înregistrare actualizeaz ă datele stocate în cele 2 
aplicații de card de pe cardurile de conduc ător auto, de atelier, 
de societate, și/sau de control valabile cu toate datele necesare 
relevante pentru perioada în care este introdus cardul și pentru 
titularul cardului. Datele stocate pe aceste carduri sunt speci ­
ficate la capitolul 4.  
(147) Aparatura de înregistrare actualizeaz ă datele privind acti ­
vitatea conduc ătorului auto și pozițiile (după cum se 
specifică la punctele 4.5.3.1.9, 4.5.3.1.11, 4.5.3.2.9 și 
4.5.3.2.11) stocate pe cardurile de conduc ător auto și/sau de 
atelier valabile cu datele privind activitatea și locurile care au 
fost introduse manual de titularul cardului.  
(148) Actualizarea datelor de pe cardurile de tahograf se face astfel 
încât, dacă este necesar din punctul de vedere al capacit ății de 
stocare a cardului din momentul respectiv, datele cele mai 
recente să le înlocuiasc ă pe cele mai vechi.  
(149) În cazul unei erori de scriere, aparatul de înregistrare încearc ă, 
de maximum trei ori, s ă efectueze aceea și comandă de scriere, 
iar dacă nu reușește declară cardul deficient și nevalabil.  
(150) Înainte de a elibera cardul de conduc ător auto și după ce toate 
datele relevante au fost stocate în cele dou ă aplicații de pe 
card, aparatura de înregistrare reseteaz ă „datele privind 
sesiunea de utilizare a cardului”.  
3.15 Afi șare 
(151) Afișajul include cel pu țin 20 de caractere.  
(152) Dimensiunile minime ale caracterelor sunt de 5 mm în ălțime 
și 3,5 mm l ățime. 
(153) Afișajul trebuie s ă fie compatibil cu caracterele specificate în 
apendicele 1 capitolul 4 „Seturi de caractere”. Afi șajul poate 
utiliza simboluri simplificate (de exemplu, caracterele cu 
accent pot fi afi șate fără accent sau minusculele pot fi 
afișate ca majuscule).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 46  
(154) Afișajul este prev ăzut cu iluminare corespunz ătoare, fără efect 
de orbire.  
(155) Indica țiile trebuie s ă fie vizibile din exteriorul aparaturii de 
înregistrare.  
(156) Aparatura de înregistrare trebuie s ă poată afișa: 
— date implicite;  
— date privind avertismentele;  
— date privind accesul la meniu;  
— alte date solicitate de utilizator.  
Aparatura de înregistrare poate afi șa și informații supli­
mentare, cu condi ția ca acestea s ă poată fi distinse în mod 
clar de informa țiile menționate anterior.  
(157) Afișajul aparaturii de înregistrare poate folosi pictogramele 
sau combina țiile de pictograme enumerate în apendicele 3. 
Aparatura de înregistrare poate afi șa și pictograme sau 
combinații de pictograme suplimentare, cu condi ția ca 
acestea să poată fi distinse în mod clar de pictogramele sau 
combinațiile de pictograme men ționate anterior.  
(158) Afișajul trebuie s ă fie întotdeauna PORNIT atunci când 
vehiculul este în mi șcare.  
(159) Aparatura de înregistrare poate include o func ție manuală sau 
automată care să treacă afișajul în pozi ția OPRIT atunci când 
vehiculul nu este în mi șcare.  
Formatul de afi șare este descris în apendicele 5.  
3.15.1  Afi șaj implicit  
(160) Atunci când nu este necesar s ă se afișeze nicio alt ă infor­
mație, aparatura de înregistrare afi șează, implicit, urm ătoarele:  
— ora local ă (ca rezultat al adun ării: ora UTC + decalajul 
setat de conduc ătorul auto);  
— modul de func ționare;  
— activitatea conduc ătorului auto în momentul respectiv și 
activitatea copilotului în momentul respectiv,  
— informa ții privind conduc ătorul auto:  
— dacă activitatea curent ă a acestuia este CONDUCERE, 
timpul de conducere continu ă și durata cumulat ă a 
pauzelor în momentul respectiv;  
— dacă activitatea curent ă a acestuia nu este CONDUCERE, 
durata activit ății curente în cauz ă (începând de la 
selectarea acesteia) și durata cumulat ă a pauzelor sale în 
momentul respectiv.  
(161) Afișarea datelor referitoare la fiecare conduc ător auto în parte 
trebuie să fie clară, simplă și lipsită de ambiguit ăți. Dacă 
informațiile privind conduc ătorul auto și copilotul nu pot fi 
afișate în acela și timp, aparatura de înregistrare afi șează 
implicit informa țiile privind conduc ătorul auto și îi permite 
utilizatorului s ă afișeze informa țiile privind copilotul.  
(162) Dac ă lățimea afișajului nu permite afi șarea implicit ă a 
modului de func ționare, aparatura de înregistrare afi șează, 
pentru scurt timp, noul mod de func ționare, în momentul 
oricărei modific ări a acestuia.  
(163) Aparatul de înregistrare afi șează pentru scurt timp, la intro ­
ducerea cardului, numele titularului acestuia.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 47  
(164) La deschiderea unei condi ții de tip „ÎN AFARA ZONEI DE 
APLICARE A REGLEMENT ĂRILOR” sau „TRASEU 
PARCURS PE FERIBOT/ÎN TREN”, afi șajul implicit 
trebuie să indice, prin intermediul pictogramei relevante, c ă 
respectiva condi ție este deschis ă (se accept ă posibilitatea ca 
activitatea curent ă a conducătorului auto s ă nu fie indicat ă în 
același timp).  
3.15.2  Afi șaj de avertizare  
(165) Aparatura de înregistrare afi șează informații de avertizare 
folosind în primul rând pictogramele din apendicele 3, 
completate dac ă este necesar cu informa ții suplimentare 
codate numeric. Se poate ad ăuga de asemenea o descriere 
textuală a avertismentului, în limba selectat ă de conduc ătorul 
auto.  
3.15.3  Accesul la meniu  
(166) Comenzile aparaturii de înregistrare sunt accesibile prin inter ­
mediul unui meniu cu structur ă adecvată. 
3.15.4  Alte afi șaje 
(167) Urm ătoarele informa ții trebuie s ă poată fi afișate selectiv, la 
cerere:  
— data și ora UTC, precum și decalajul orar local;  
— conținutul oricăruia dintre cele șase documente imprimate, 
în format identic cu al acestora;  
— timpul de conducere continu ă și durata cumulat ă a 
pauzelor conduc ătorului auto;  
— timpul de conducere continu ă și durata cumulat ă a 
pauzelor copilotului;  
— timpul de conducere continu ă al conduc ătorului auto 
pentru săptămâna în curs și pentru săptămâna anterioar ă; 
— timpul de conducere continu ă al copilotului pentru 
săptămâna în curs și pentru săptămâna anterioar ă, 
opțional:  
— durata activit ății copilotului în momentul respectiv 
(începând de la selectarea acesteia);  
— timpul de conducere continu ă al conduc ătorului auto 
pentru săptămâna în curs;  
— timpul de conducere continu ă al copilotului pentru 
programul zilnic de lucru în curs;  
— timpul de conducere continu ă al conduc ătorului auto 
pentru ziua de lucru în curs.  
(168) Afișarea con ținutului documentelor imprimate este 
secvențială, structurat ă pe rânduri. Dac ă lățimea afișajului 
este mai mic ă de 24 de caractere, utilizatorul trebuie s ă 
aibă acces la informa țiile complete printr-un mijloc adecvat 
(mai multe rânduri, derulare etc.).  
Nu este obligatorie afi șarea rândurilor rezervate pentru infor ­
mațiile scrise de mân ă din documentele imprimate.  
3.16 Imprimare  
(169) Aparatura de înregistrare permite imprimarea de informa ții 
din memoria sa de date și/sau de pe cardurile de tahograf, 
astfel încât s ă se obțină următoarele șapte tipuri de documente 
imprimate:  
— document imprimat zilnic privind activit ățile conduc ă­
torului auto stocate pe card;  
— document imprimat zilnic privind activit ățile zilnice ale 
conducătorului auto stocate în unitatea montat ă pe 
vehicul;  
— document imprimat privind evenimentele și anomaliile 
stocate pe card;  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 48  
— document imprimat privind evenimentele și anomaliile 
stocate în unitatea montat ă pe vehicul;  
— document imprimat privind datele tehnice;  
— document imprimat privind dep ășirea limitei de vitez ă; 
— istoricul datelor de pe cardul de tahograf pentru o anumit ă 
VU (a se vedea capitolul 3.12.16).  
Formatul detaliat și conținutul acestor documente imprimate 
sunt descrise în apendicele 4.  
La sfârșitul documentelor imprimate pot fi furnizate și date 
suplimentare.  
Aparatura de înregistrare poate furniza și alte documente 
imprimate, cu condi ția ca acestea s ă poată fi deosebite în 
mod clar de cele șapte tipuri men ționate anterior.  
(170) „Documentul imprimat zilnic privind activit ățile conduc ă­
torului auto stocate pe card” și „documentul imprimat 
privind evenimentele și anomaliile stocate pe card” trebuie 
să fie disponibile numai atunci când în aparatura de înre ­
gistrare este introdus un card de conduc ător auto sau de 
atelier. Aparatura de înregistrare actualizeaz ă datele stocate 
pe cardul relevant înainte de a ini ția imprimarea.  
(171) Pentru a genera „documentul imprimat zilnic privind activi ­
tățile conduc ătorului auto stocate pe card” și „documentul 
imprimat privind evenimentele și anomaliile stocate pe 
card”, aparatura de înregistrare:  
— fie selecteaz ă automat cardul de conduc ător auto sau 
cardul de atelier dac ă numai unul dintre acestea a fost 
introdus;  
— fie dispune de o comand ă care permite selectarea cardului 
sursă sau a cardului din slotul pentru cardul de conduc ător 
auto dacă în aparatura de înregistrare au fost introduse 
două astfel de carduri.  
(172) Imprimanta permite imprimarea a 24 de caractere pe fiecare 
rând.  
(173) Dimensiunile minime ale caracterelor sunt de 2,1 mm în ălțime 
și 1,5 mm l ățime. 
(174) Imprimanta permite utilizarea caracterelor specificate în apen ­
dicele 1 capitolul 4 „Seturi de caractere”.  
(175) Imprimantele trebuie proiectate astfel încât s ă producă aceste 
documente imprimate cu o rezolu ție care să elimine orice 
eventuală ambiguitate la citire.  
(176) Documentele imprimate trebuie s ă își păstreze dimensiunile și 
înregistrările în condi ții normale de umiditate (10-90 %) și de 
temperatur ă. 
(177) Hârtia omologat ă de tip folosit ă de aparatura de înregistrare 
trebuie să fie prevăzută cu marca de omologare de tip 
adecvată și să conțină o indicație privind tipul sau tipurile 
de aparatur ă de înregistrare pentru care poate fi folosit ă. 
(178) Documentele imprimate trebuie s ă își păstreze lizibilitatea și 
să poată fi identificate în condi ții normale de depozitare 
privind intensitatea luminii, umiditatea și temperatura, timp 
de cel puțin doi ani.  
(179) Documentele imprimate trebuie s ă respecte cel pu țin specifi­
cațiile de testare definite în apendicele 9.  
(180) De asemenea, pe aceste documente trebuie s ă se poată adăuga 
și note scrise de mân ă, cum ar fi semn ătura conduc ătorului 
auto ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 49  
(181) Aparatura de înregistrare gestioneaz ă întreruperile cauzate de 
terminarea hârtiei în timpul activit ății de imprimare, dup ă 
realimentarea cu hârtie, fie reluând imprimarea de la 
început, fie continuând imprimarea și făcând clar referire la 
partea imprimat ă anterior.  
3.17 Avertismente  
(182) Aparatura de înregistrare trebuie s ă avertizeze conduc ătorul 
auto atunci când detecteaz ă orice eveniment și/sau anomalie.  
(183) Este posibil ca avertismentul referitor la evenimentul „Între ­
ruperea aliment ării cu energie electric ă” să fie amânat pân ă la 
reconectarea la surs ă de electricitate.  
(184) În ceea ce prive ște depășirea timpului de conducere continu ă 
maxim autorizat, aparatura de înregistrare trebuie s ă aver­
tizeze conduc ătorul auto cu 15 minute înainte de expirarea 
timpului respectiv și în momentul dep ășirii. 
(185) Avertismentele trebuie s ă fie vizuale. avertismentele vizuale 
pot fi înso țite și de avertismente sonore.  
(186) Avertismentele vizuale trebuie s ă poată fi recunoscute în mod 
clar de către utilizator, trebuie s ă se afle în câmpul vizual al 
conducătorului auto și trebuie s ă fie perfect lizibile atât ziua 
cât și noaptea.  
(187) Avertismentele vizuale pot fi integrate în aparatura de înre ­
gistrare și/sau pot fi externe.  
(188) În cel de-al doilea caz, avertismentele trebuie s ă fie marcate 
cu simbolul „T”.  
(189) Avertismentele trebuie s ă dureze cel pu țin 30 de secunde, cu 
excepția cazurilor când șoferul confirm ă luarea lor la 
cunoștință prin ap ăsarea uneia sau mai multor taste 
specifice ale aparatului de înregistrare. Aceast ă primă 
confirmare nu anuleaz ă afișarea cauzei avertismentului 
descrisă la punctul urm ător. 
(190) Cauza avertismentului trebuie afi șată de aparatura de înre ­
gistrare și trebuie s ă rămână vizibilă până când utilizatorul 
confirmă luarea acesteia la cuno ștință cu ajutorul unei 
anumite taste sau comenzi a aparaturii de înregistrare.  
(191) Pot fi prev ăzute și avertismente suplimentare, cu condi ția ca 
acestea să nu poată fi confundate de conduc ătorii auto cu cele 
descrise anterior.  
3.18 Desc ărcarea datelor pe suporturi externe  
(192) Aparatura de înregistrare permite desc ărcarea la cerere a 
datelor din memoria sa de date sau de pe un card de 
conducător auto pe suporturi externe de stocare prin inter ­
mediul conectorului pentru etalonare/desc ărcare. Aparatura 
de înregistrare actualizeaz ă datele stocate pe cardul relevant 
înainte de a începe desc ărcarea.  
(193) În plus, ca o caracteristic ă opțională, aparatura de înregistrare 
poate, în orice mod de func ționare, să descarce date prin orice 
alt mijloc c ătre o societate autentificat ă prin intermediul 
acestui canal. În acest caz, pentru astfel de desc ărcări se 
aplică drepturile de acces la date în modul societate.  
(194) Desc ărcarea nu modific ă și nici nu șterge datele stocate.  
(195) Interfa ța electrică a conectorului pentru etalonare/desc ărcare 
este descris ă în apendicele 6.  
(196) Protocoalele de desc ărcare sunt descrise în apendicele 7.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 50  
3.19 Comunicare la distan ță pentru controalele selective în trafic  
(197) Atunci când motorul vehiculului este pornit, unitatea montat ă 
pe vehicul stocheaz ă, la fiecare 60 de secunde, în echipa ­
mentul de comunicare la distan ță, cele mai recente date 
necesare pentru controalele selective în trafic. Aceste date 
trebuie criptate și semnate în conformitate cu indica țiile din 
apendicele 11 și 14.  
(198) Datele de verificat de la distan ță trebuie să poată fi accesate 
de cititoarele pentru comunicarea la distan ță prin intermediul 
comunicării fără fir ( wireless ), în conformitate cu apen ­
dicele 14.  
(199) Datele necesare în scopul controalelor selective în trafic se 
referă la: 
— ultima tentativ ă de încălcare a securit ății; 
— cea mai lung ă întrerupere a aliment ării cu energie elec ­
trică; 
— anomalia senzorului;  
— eroare privind datele de la senzorul de mi șcare;  
— conflict privind deplasarea vehiculului;  
— conducere f ără un card valabil;  
— introducerea cardului în timpul conducerii;  
— date privind reglarea orei;  
— date de etalonare, inclusiv datele ultimelor dou ă înre­
gistrări de etalonare stocate;  
— numărul de înmatriculare al vehiculului;  
— viteza înregistrat ă de tahograf.  
3.20 Date de ie șire transmise unor dispozitive externe suplimentare  
▼M1 
(200) Aparatura de înregistrare poate fi dotat ă și cu interfe țe stan­
dardizate care permit utilizarea în modul opera țional sau în 
modul etalonare, de c ătre un dispozitiv extern, a datelor înre ­
gistrate sau produse de tahograf.  
În apendicele 13 este specificat ă și standardizat ă o interfață 
ITS opțională. Pot coexista și alte interfe țe ale unit ăților 
montate pe vehicule, cu condi ția să respecte pe deplin 
cerințele din apendicele 13 în ceea ce prive ște lista minim ă 
de date, securitatea și acordul conduc ătorului auto.  
Acordul conduc ătorului auto nu se aplic ă datelor transmise de 
aparatura de înregistrare la re țeaua vehiculului. În cazul în 
care datele cu caracter personal injectate în re țeaua vehi­
culului sunt prelucrate ulterior în afara re țelei vehiculului, 
este responsabilitatea produc ătorului vehiculului s ă se 
asigure că datele cu caracter personal se prelucreaz ă în 
conformitate cu Regulamentul (UE) 2016/679 („Regulamentul 
general privind protec ția datelor”).  
Acordul conduc ătorului auto nu se aplic ă nici datelor de pe 
tahograf desc ărcate către o societate la distan ță (cerința 193), 
deoarece acest scenariu este monitorizat de dreptul de acces al 
cardului de societate.  
Cerințele următoare se aplic ă datelor ITS puse la dispozi ție 
prin intermediul interfe ței respective:  
— aceste date reprezint ă un set de date existente selectate din 
dicționarul de date al tahografului (apendicele 1);  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 51  
— un subset al acestor date selectate constituie „date cu 
caracter personal”;  
— subsetul de „date cu caracter personal” este disponibil 
numai dac ă este activat acordul verificabil al conduc ă­
torului auto, care accept ă ca datele sale cu caracter 
personal să părăsească rețeaua vehiculului;  
— acordul conduc ătorului auto poate fi activat sau dezactivat 
în orice moment prin comenzile din meniu, cu condi ția să 
fie introdus cardul de conduc ător auto;  
— setul și subsetul de date vor fi transmise prin protocolul 
fără fir Bluetooth pe raza cabinei vehiculului, cu o rat ă de 
reîmprospătare de 1 minut;  
— asocierea dispozitivului extern la interfa ța ITS va fi 
protejată cu ajutorul unui PIN special și aleatoriu de cel 
puțin patru cifre, înregistrat în fiecare unitate montat ă pe 
vehicul și disponibil prin intermediul afi șajului acesteia;  
— prezența interfeței ITS nu poate, în nicio situa ție, să 
perturbe sau s ă influențeze funcționarea corect ă și secu­
ritatea unit ății montate pe vehicul.  
Pe lângă setul de date existente selectate, considerate drept 
lista minim ă, pot fi extrase și alte date, cu condi ția să nu 
poată fi considerate date cu caracter personal.  
Aparatura de înregistrare trebuie s ă aibă capacitatea de a 
comunica acordul conduc ătorului auto altor platforme din 
rețeaua vehiculului.  
Atunci când motorul vehiculului este PORNIT, aceste date 
sunt transmise în mod permanent.  
▼B 
(201) În scopul retrocompatibilit ății, tahografele pot r ămâne în 
continuare echipate cu interfa ța de legătură serială menționată 
în anexa 1B la Regulamentul (CEE) 3821/85, astfel cum a 
fost modificat ultima dat ă. Oricum, acordul conduc ătorului 
auto este în continuare necesar în cazul în care sunt 
transmise date cu caracter personal.  
3.21 Etalonare  
(202) Func ția de etalonare permite:  
— asocierea automat ă a senzorului de mi șcare la VU;  
— cuplarea automat ă a echipamentului GNSS extern la VU, 
dacă este cazul;  
— adaptarea digital ă a constantei aparaturii de înregistrare 
(k) la coeficientul caracteristic al vehiculului (w);  
— ajustarea orei curente în cadrul perioadei de valabilitate a 
cardului de atelier introdus;  
— ajustarea valorii curente a odometrului;  
— actualizarea datelor de identificare a senzorului de mi șcare 
stocate în memoria de date;  
— actualizarea, dac ă este cazul, a datelor de identificare a 
echipamentului GNSS extern stocate în memoria de date;  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 52  
— actualizarea tipurilor și a identificatorilor tuturor sigiliilor 
montate;  
— actualizarea sau confirmarea altor parametri cunoscu ți de 
aparatura de înregistrare: identificarea vehiculului, w, l, 
dimensiunea pneurilor și reglajele limitatorului de vitez ă, 
dacă este cazul.  
(203) În plus, func ția de etalonare permite anularea utiliz ării 
cardurilor de tahograf de prim ă generație în aparatura de 
înregistrare, dac ă sunt îndeplinite condi țiile specificate în 
apendicele 15.  
(204) Asocierea senzorului de mi șcare la VU implic ă cel puțin: 
— actualizarea datelor privind instalarea senzorului de 
mișcare reținute de senzorul de mi șcare (după caz);  
— copierea, din senzorul de mi șcare în memoria de date a 
VU, a datelor necesare pentru identificarea senzorului de 
mișcare.  
(205) Cuplarea echipamentului GNSS extern la VU implic ă cel 
puțin: 
— actualizarea datelor privind instalarea echipamentului 
GNSS extern re ținute de echipamentul GNSS extern 
(după caz);  
— copierea, din echipamentul GNSS extern în memoria de 
date a VU, a datelor necesare pentru identificarea echipa ­
mentului GNSS extern, inclusiv a num ărului de serie al 
echipamentului GNSS extern.  
Cuplarea este urmat ă de verificarea informa țiilor de 
poziționare de la GNSS.  
(206) Func ția de etalonare trebuie s ă permită înregistrarea datelor 
necesare prin intermediul conectorului pentru etalonare/des ­
cărcare, în conformitate cu protocolul de etalonare descris 
în apendicele 8. Func ția de etalonare permite înregistrarea 
datelor necesare și prin alte mijloace.  
3.22 Verificarea etalon ării în trafic  
(207) Func ția de verificare a etalon ării în trafic permite citirea 
numărului de serie al senzorului de mi șcare (eventual 
integrat în adaptor) și a numărului de serie al echipamentului 
GNSS extern (atunci când este cazul), care sunt conectate la 
unitatea montat ă pe vehicul, în momentul solicit ării. 
(208) Aceast ă citire trebuie s ă fie posibil ă cel puțin pe afișajul 
unității montate pe vehicul, prin intermediul unor comenzi 
aflate în meniuri.  
(209) Func ția de verificare a etalon ării în trafic permite, de 
asemenea, controlarea selec ției modulului de intrare/ie șire 
(I/O) al liniei de semnalizare I/O de etalonare, specificat în 
apendicele 6, prin interfa ța liniei K. Acest lucru se realizeaz ă 
prin intermediul sesiunii „ECUAdjustmentSession”, în confor ­
mitate cu apendicele 8 sec țiunea 7 Controlul impulsurilor de 
test – Unitatea func țională de control al intr ărilor/ieșirilor.  
3.23 Reglarea orei  
(210) Func ția de reglare a orei trebuie s ă permită reglarea automat ă 
a orei. În scopul regl ării orei, aparatura de înregistrare 
utilizează două surse de m ăsurare a timpului: 1) ceasul 
intern al VU; 2) receptorul GNSS.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 53  
(211) Ora ceasului intern al VU se reajusteaz ă automat din 12 în 12 
ore. Când aceast ă reajustare nu este posibil ă deoarece 
semnalul GNSS nu este disponibil, reglarea orei se realizeaz ă 
de îndată ce VU poate avea acces la o or ă valabilă furnizată 
de receptorul GNSS, în func ție de condi țiile de pornire a 
motorului vehiculului. Referin ța temporal ă pentru setarea 
automată a orei ceasului intern al VU se determin ă pe baza 
orei furnizate de receptorul GNSS.  
▼B 
(212) Func ția de reglare a orei trebuie s ă permită, de asemenea, 
reglarea declan șată a orei curente, în modul etalonare.  
3.24 Caracteristici de performan ță 
(213) Unitatea montat ă pe vehicul este complet opera țională în 
intervalul de temperatur ă cuprins între – 20 °C și 70 °C, echi ­
pamentul GNSS extern în intervalul de temperatur ă cuprins 
între – 20 °C și 70 C, iar senzorul de mi șcare în intervalul de 
temperatur ă cuprins între – 40 °C și 135 °C. Con ținutul 
memoriei de date se p ăstrează până la temperaturi de – 40 °C.  
(214) Tahograful trebuie s ă funcționeze corect într-un interval de 
umiditate de 10 % pân ă la 90 %.  
(215) Sigiliile utilizate în tahograful inteligent trebuie s ă îndepli­
nească aceleași condiții ca cele aplicabile componentelor 
tahografului de care sunt ata șate. 
(216) Aparatura de înregistrare trebuie protejat ă de supratensiune, 
de inversarea polarit ății sursei de alimentare și de scurt- 
circuite.  
(217) Senzorii de mi șcare trebuie:  
— fie să reacționeze la un câmp magnetic care perturb ă 
detectarea deplas ării vehiculului. În acest caz, unitatea 
montată pe vehicul va înregistra și stoca o eroare a 
senzorului (cerin ța 88), fie  
— să aibă un element detector protejat împotriva câmpurilor 
magnetice sau imun la acestea.  
(218) Aparatura de înregistrare și echipamentul GNSS extern 
trebuie să fie conforme cu regulamentul interna țional CEE- 
ONU R10 și protejate împotriva desc ărcărilor electrostatice și 
împotriva șocurilor de instalare.  
3.25 Materiale  
(219) Toate p ărțile componente ale aparaturii de înregistrare trebuie 
să fie confec ționate din materiale suficient de stabile și cu o 
rezistență mecanică suficientă și să aibă caracteristici electrice 
și magnetice stabile.  
(220) În condi ții normale de utilizare, toate componentele interne al 
aparaturii trebuie s ă fie protejate de umezeal ă și de praf.  
(221) Unitatea montat ă pe vehicul și echipamentul GNSS extern 
trebuie să respecte nivelul de protec ție IP 40, iar senzorul 
de mișcare trebuie s ă respecte nivelul de protec ție IP 64, 
conform standardului IEC 60529:1989, inclusiv A1:1999 și 
A2:2013.  
(222) Aparatura de înregistrare trebuie s ă respecte specifica țiile 
tehnice aplicabile în domeniul proiect ării ergonomice.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 54  
(223) Aparatura de înregistrare trebuie s ă fie protejat ă împotriva 
deteriorărilor accidentale.  
3.26 Inscrip ții 
(224) Dac ă aparatura de înregistrare afi șează valoarea odometrului 
și viteza vehiculului, pe afi șajul său apar urm ătoarele detalii:  
— lângă cifra care indic ă distanța, unitatea de m ăsură a 
distanței, indicată prin abrevierea „km”;  
— lângă cifra care indic ă viteza, indica ția „km/h”.  
Aparatura de înregistrare poate fi comutat ă astfel încât s ă 
afișeze viteza în mile pe or ă, în acest caz unitatea de 
măsură a vitezei fiind indicat ă prin abrevierea „mph”. 
Aparatura de înregistrare poate fi comutat ă astfel încât s ă 
afișeze distanța în mile, în acest caz unitatea de m ăsură a 
distanței fiind indicat ă prin abrevierea „mi”.  
▼M1 
(225) Pe fiecare component ă separată a aparaturii de înregistrare se 
atașează o plăcuță descriptiv ă care conține următoarele detalii:  
— numele și adresa produc ătorului;  
— numărul de component ă furnizat de produc ător și anul de 
fabricație; 
— numărul de serie;  
— marca de omologare de tip.  
(226) Dac ă spațiul fizic nu este suficient pentru afi șarea tuturor 
detaliilor men ționate anterior, pl ăcuța descriptiv ă trebuie să 
conțină cel puțin: numele și sigla produc ătorului și numărul 
de component ă. 
▼B 
4. CERIN ȚE FUNCȚIONALE ȘI DE CONSTRUC ȚIE PENTRU 
CARDURILE DE TAHOGRAF  
4.1 Date vizibile  
Pe recto figureaz ă: 
(227) cuvintele „Card de conduc ător auto” sau „Card de control” 
sau „Card de atelier” sau „Card de societate”, tip ărite cu 
majuscule în limba sau limbile oficiale ale statului membru 
emitent, în func ție de tipul cardului;  
(228) denumirea statului membru emitent al cardului (op țional);  
(229) indicativul statului membru emitent al cardului, tip ărit în 
negativ într-un dreptunghi albastru și înconjurat de 12 stele 
galbene. Indicativele sunt urm ătoarele: 
B 
BG 
CZ 
CY Belgia 
Bulgaria 
Republica Ceh ă 
Cipru  LV 
L 
LT 
M Letonia 
Luxemburg 
Lituania 
Malta  
DK Danemarca  NL  Țările de Jos  
D 
EST Germania 
Estonia  A 
PL Austria 
Polonia  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 55  
GR Grecia  P 
RO 
SK 
SLO  Portugalia 
România 
Slovacia 
Slovenia  
E Spania  FIN  Finlanda  
F 
HR 
H Franța 
Croația 
Ungaria  S Suedia  
IRL Irlanda  UK  Regatul Unit  
I Italia  
(230) informa ții specifice pentru cardul emis, numerotate dup ă cum 
urmează: 
Card de conduc ător auto  Card de control  Card de societate sau card de 
atelier  
1. numele conduc ătorului auto  denumirea organismului de 
control  denumirea societ ății sau a 
atelierului.  
2. prenumele conduc ătorului 
auto numele agentului de control 
(dacă este cazul)  numele titularului cardului 
(dacă este cazul)  
3. data na șterii conduc ătorului 
auto prenumele agentului de 
control 
(dacă este cazul)  prenumele titularului cardului 
(dacă este cazul)  
4.a data de la care este valabil cardul  
4.b data expir ării cardului  
4.c denumirea autorit ății emitente (poate fi imprimat ă pe verso)  
4.d un num ăr diferit de cel de la rubrica 5, în scop administrativ (op țional)  
5. a numărul permisului de 
conducere 
(la data emiterii cardului de 
conducător auto)  — —  
5. b numărul cardului  
6. fotografia conduc ătorului 
auto fotografia agentului de 
control (op țional)  fotografia montatorului 
(opțional)-  
7. Semn ătura titularului (op țional)  
8. Adresa oficial ă sau adresa 
poștală a titularului 
(opțional)  Adresa po ștală a orga ­
nismului de control  Adresa po ștală a societ ății 
sau a atelierului  
(231) datele se scriu în format „zz/ll/aaaa” sau „zz.ll.aaaa” (zi, lun ă, 
an). 
Pe verso figureaz ă: 
(232) explica ții pentru elementele numerotate de pe recto-ul 
cardului;  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 56  
(233) cu acordul special al titularului, exprimat în scris, pot fi 
adăugate informa ții care nu sunt legate de administrarea 
cardului, dar acestea nu trebuie s ă modifice în niciun fel 
utilizarea modelului drept card de tahograf.  
(234) Cardurile de tahograf se imprim ă pe fonduri având urm ă­
toarele culori predominante:  
— cardul de conduc ător auto: alb;  
— cardul de control: albastru;  
— cardul de atelier: ro șu; 
— cardul de societate: galben.  
(235) Cardurile de tahograf trebuie s ă aibă cel puțin următoarele 
caracteristici pentru protec ția corpului cardului împotriva 
falsificării și a manipul ării neadecvate:  
— un fond de securitate cu ghio șe și irizat;  
— în zona fotografiei, fondul de securitate și fotografia se 
suprapun;  
— cel puțin o linie bicolor ă microimprimat ă.
 
► (1) M1 
(236) Dup ă consultarea Comisiei, statele membre pot ad ăuga culori 
sau inscrip ții cum ar fi simboluri na ționale sau caracteristici 
de securitate, f ără a aduce atingere celorlalte dispozi ții din 
prezenta anex ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 57  
(237) Cardurile temporare men ționate la articolul 26 alineatul (4) 
din Regulamentul (UE) nr.165/2014 trebuie s ă respecte 
dispozițiile prezentei anexe.  
4.2 Securitate  
Scopul securit ății sistemului este de a proteja integritatea și auten­
ticitatea datelor schimbate între carduri și aparatura de înregistrare, 
de a proteja integritatea și autenticitatea datelor desc ărcate de pe 
carduri, de a permite aparaturii de înregistrare s ă efectueze numai 
anumite opera țiuni de scriere pe carduri, de a decripta anumite date, 
de a elimina orice posibilitate de falsificare a datelor stocate pe 
carduri, de a preveni manipul ările neadecvate și de a detecta orice 
tentativă de acest gen.  
(238) Pentru a asigura securitatea sistemului, cardurile de tahograf 
trebuie să îndeplineasc ă cerințele de securitate definite în 
apendicele 10 și 11.  
(239) Cardurile de tahograf trebuie s ă poată fi citite și de alte 
echipamente, cum ar fi computerele personale.  
4.3 Standarde  
(240) Cardurile de tahograf trebuie s ă respecte urm ătoarele stan ­
darde:  
— ISO/IEC 7810 Identification cards – Physical characte ­
ristics;  
— ISO/IEC 7816 Identification cards – Integrated circuit 
cards:  
— Part 1: Physical characteristics,  
— Part 2: Dimensions and position of the contacts 
(ISO/IEC 7816-2:2007),  
— Part 3: Electrical interface and transmission protocols 
(ISO/IEC 7816-3:2006),  
— Part 4: Organisation, security and commands for inter ­
change (ISO/IEC 7816-4:2013 + Cor 1:2014),  
— Part 6: Interindustry data elements for interchange 
(ISO/IEC 7816-6:2004 + Cor 1:2006),  
— Part 8: Commands for security operations (ISO/IEC 
7816-8:2004).  
— Cardurile de tahograf se testeaz ă în conformitate cu stan ­
dardul ISO/IEC 10373-3:2010 Identification cards – Test 
methods – Part 3: Integrated circuit cards with contacts 
and related interface devices.  
4.4 Specifica ții de mediu și electrice  
(241) Cardurile de tahograf pot func ționa corect în toate condi țiile 
climatice întâlnite în mod normal pe teritoriul Uniunii și cel 
puțin în intervalul de temperatur ă cuprins între – 25 °C și 
+ 70 °C, cu cre șteri ocazionale ale temperaturii de pân ă la 
+ 85 °C; „ocazional” înseamn ă timp de cel mult 4 ore o dat ă 
și de cel mult 100 de ori pe întreaga durat ă de viață a 
cardului.  
(242) Cardurile de tahograf pot func ționa corect în intervalul de 
umiditate cuprins între 10 % și 90 %.  
(243) Cardurile de tahograf pot func ționa corect timp de cinci ani 
dacă sunt folosite conform specifica țiilor de mediu și elec­
trice.  
(244) În cursul func ționării, cardurile de tahograf respect ă Regula­
mentul CEE-ONU R10, referitor la compatibilitatea electro ­
magnetică, și sunt protejate împotriva desc ărcărilor electros ­
tatice.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 58  
4.5 Stocarea datelor  
În sensul prezentului alineat,  
— orele sunt înregistrate cu o rezolu ție de un minut, cu excep ția 
cazurilor în care se specific ă altfel;  
— valorile odometrului sunt înregistrate cu o rezolu ție de un kilo ­
metru;  
— vitezele sunt înregistrate cu o rezolu ție de 1 km/h;  
— pozițiile (latitudinile și longitudinile) sunt înregistrate în grade și 
minute, cu o rezolu ție de 1/10 de minut.  
Funcțiile, comenzile și structurile logice ale cardurilor de tahograf 
care îndeplinesc cerin țele de stocare a datelor sunt men ționate în 
apendicele 2.  
În absența unor dispozi ții contrare, stocarea datelor pe cardurile de 
tahograf trebuie organizat ă astfel încât datele noi s ă înlocuiasc ă 
datele cele mai vechi în cazul epuiz ării capacit ății prevăzute a 
memoriei destinate anumitor înregistr ări. 
(245) Prezentul paragraf stabile ște capacitatea minim ă de stocare 
pentru diversele fi șiere de date pentru aplica ții. Cardurile de 
tahograf trebuie s ă poată transmite aparaturii de înregistrare 
capacitatea de stocare din momentul respectiv a respectivelor 
fișiere de date.  
(246) Orice date suplimentare care pot fi stocate pe cardurile de 
tahograf, referitoare la alte eventuale aplica ții existente pe 
card, se stocheaz ă în conformitate cu Directiva 95/46/CE, 
cu Directiva 2002/58/CE și cu articolul 7 din Regulamentul 
(UE) nr. 165/2014.  
(247) Fiecare fi șier principal (MF –  Master File ) al unui card de 
tahograf con ține până la cinci fi șiere de baz ă (EF –  
Elementary Files ) pentru gestionarea cardului și pentru iden ­
tificarea aplica țiilor și a cipurilor, precum și două fișiere 
speciale (DF –  Dedicated Files ): 
— DF Tachograph, care con ține aplicația accesibil ă pentru 
unitățile montate pe vehicul de prim ă generație, prezent ă 
și pe cardurile de tahograf de prim ă generație; 
— DF Tachograph_G2, care con ține aplica ția accesibil ă 
numai pentru unit ățile montate pe vehicul de a doua gene ­
rație, prezent ă numai pe cardurile de tahograf de a doua 
generație. 
Detaliile complete ale structurii cardurilor de tahograf sunt 
specificate în apendicele 2.  
4.5.1  Fi șierele elementare pentru identificare și pentru gestionarea 
cardului  
4.5.2  Identificarea cardurilor cu circuite integrate (IC)  
(248) Cardurile de tahograf permit stocarea urm ătoarelor date de 
identificare a cardurilor inteligente:  
— clock stop ; 
— numărul de serie al cardului (inclusiv referin țele de fabri ­
cație); 
— numărul de omologare de tip al cardului;  
— ID-ul de personalizare a cardului;  
— ID-ul integratorului;  
— identificatorul circuitului integrat (IC).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 59  
4.5.2.1 I d e n t i f i c a r e a c i p u l u i  
(249) Cardurile de tahograf permit stocarea urm ătoarelor date de 
identificare a circuitelor integrate (IC):  
— numărul de serie al IC;  
— referințele de fabrica ție ale IC.  
4.5.2.2 D I R ( p r e z e n t n u m a i p e c a r d u r i l e d e t a h o g r a f d e a 
d o u a g e n e r a ț i e ) 
(250) Cardurile de tahograf permit stocarea obiectelor de date 
pentru identificarea aplica ției, specificate în apendicele 2.  
4.5.2.3 I n f o r m a ț i i R L R ( î n a n u m i t e c o n d i ț i i , p r e z e n t e 
n u m a i p e c a r d u r i l e d e t a h o g r a f d e a d o u a g e n e ­
r a ț i e ) 
(251) Cardurile de tahograf permit stocarea urm ătorului obiect de 
date informativ cu lungime extins ă: 
— în cazul în care cardul de tahograf utilizeaz ă câmpuri cu 
lungime extins ă, obiectul de date informativ cu lungime 
extinsă specificat în apendicele 2.  
4.5.2.4 I n f o r m a ț i i p r i v i n d l u n g i m e a e x t i n s ă ( î n a n u m i t e 
c o n d i ț i i , p r e z e n t e n u m a i p e c a r d u r i l e d e 
t a h o g r a f d e a d o u a g e n e r a ț i e ) 
(252) Cardurile de tahograf permit stocarea urm ătoarelor obiecte de 
date informative cu lungime extins ă: 
— în cazul în care cardul de tahograf utilizeaz ă câmpuri cu 
lungime extins ă, obiectele de date informative cu lungime 
extinsă specificate în apendicele 2.  
4.5.3  Cardul de conduc ător auto  
4.5.3.1 A p l i c a ț i e p e n t r u t a h o g r a f ( a c c e s i b i l ă p e n t r u 
u n i t ă ț i l e m o n t a t e p e v e h i c u l d e p r i m a ș i a d o u a 
g e n e r a ț i e ) 
4.5.3.1.1 Identificarea aplica ției 
(253) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
de identificare a aplica ției: 
— identificarea aplica ției pentru tahograf;  
— identificarea tipului de card de tahograf.  
4.5.3.1.2 Chei și certificate  
(254) Cardul de conduc ător auto permite stocarea unei serii de chei 
și certificate criptografice, în conformitate cu apendicele 11 
partea A.  
4.5.3.1.3 Identificarea cardului  
(255) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
de identificare a cardului:  
— numărul cardului;  
— statul membru emitent, denumirea autorit ății emitente, 
data emiterii;  
— data de la care este valabil cardul, data expir ării cardului.  
4.5.3.1.4 Identificarea titularului cardului  
(256) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
de identificare a titularului cardului:  
— numele titularului;  
— prenumele titularului;  
— data na șterii;  
— limba preferat ă de titular.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 60  
4.5.3.1.5 Desc ărcarea informa țiilor de pe card  
(257) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
legate de desc ărcarea informa țiilor de pe card:  
— data și ora la care s-a efectuat ultima desc ărcare a infor ­
mațiilor de pe card (în alte scopuri decât în vederea unui 
control).  
(258) Cardul de conduc ător auto permite stocarea unei singure 
astfel de înregistr ări. 
4.5.3.1.6 Informa ții privind permisul de conducere  
(259) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
privind permisul de conducere:  
— statul membru emitent, denumirea autorit ății emitente;  
— numărul permisului de conducere (la data emiterii 
cardului).  
4.5.3.1.7 Date privind evenimentele  
În sensul prezentului paragraf, ora se înregistreaz ă cu o rezolu ție de 
1 secundă. 
(260) Cardul de conduc ător auto permite stocarea de date legate de 
următoarele evenimente detectate de aparatura de înregistrare 
în perioada în care cardul este introdus:  
— suprapunere a timpului (dac ă evenimentul este provocat 
de cardul respectiv);  
— introducerea cardului în timpul conducerii (dac ă eveni­
mentul afecteaz ă cardul respectiv);  
— încheierea incorect ă a ultimei sesiuni de utilizare a 
cardului (dac ă evenimentul afecteaz ă cardul respectiv);  
— întreruperea aliment ării cu energie electric ă; 
— eroare privind datele de la senzorul de mi șcare;  
— tentative de înc ălcare a securit ății. 
(261) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
privind aceste evenimente:  
— codul evenimentului;  
— data și ora începerii evenimentului (sau a introducerii 
cardului dac ă evenimentul era în curs la momentul 
respectiv);  
— data și ora încheierii evenimentului (sau a retragerii 
cardului dac ă evenimentul era în curs la momentul 
respectiv);  
— VRN și statul membru de înmatriculare a vehiculului 
afectat de eveniment.  
Notă: Pentru evenimentul „Suprapunere a timpului”:  
— data și ora începerii evenimentului trebuie s ă corespund ă 
datei și orei retragerii cardului din vehiculul precedent;  
— data și ora încheierii evenimentului trebuie s ă corespund ă 
datei și orei introducerii cardului în vehiculul folosit la 
momentul respectiv;  
— datele privind vehiculul trebuie s ă corespund ă vehiculului 
din momentul respectiv (cel care a declan șat eveni­
mentul).  
Notă: Pentru evenimentul: „Încheiere incorect ă a ultimei 
sesiuni de utilizare a cardului”:  
— data și ora începerii evenimentului trebuie s ă corespund ă 
datei și orei de introducere a cardului pentru sesiunea care 
nu a fost încheiat ă corect;  
— data și ora încheierii evenimentului trebuie s ă corespund ă 
datei și orei introducerii cardului pentru sesiunea în cursul 
căreia a fost detectat evenimentul (sesiunea din momentul 
respectiv);  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 61  
— datele privind vehiculul trebuie s ă corespund ă vehiculului 
în care s-a desf ășurat sesiunea care nu a fost încheiat ă 
corect.  
(262) Cardul de conduc ător auto permite stocarea de date privind 
cele mai recente șase evenimente din fiecare tip ( și anume, 36 
de evenimente).  
4.5.3.1.8 Date privind anomaliile  
În sensul prezentului paragraf, ora se înregistreaz ă cu o rezolu ție de 
1 secundă. 
(263) Cardul de conduc ător auto permite stocarea de date privind 
următoarele anomalii detectate de aparatura de înregistrare în 
timp ce cardul este introdus:  
▼M1 
— anomalie a cardului (dac ă anomalia afecteaz ă cardul);  
▼B 
— anomalie a aparaturii de înregistrare.  
(264) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
privind aceste anomalii:  
— codul anomaliei;  
— data și ora începerii anomaliei (sau a introducerii cardului 
dacă anomalia era în curs la momentul respectiv);  
— data și ora încheierii anomaliei (sau a retragerii cardului 
dacă anomalia era în curs la momentul respectiv);  
— VRN și statul membru de înmatriculare a vehiculului 
afectat de anomalie.  
(265) Cardul de conduc ător auto permite stocarea de date privind 
cele mai recente dou ăsprezece anomalii din fiecare tip ( și 
anume, 24 de anomalii).  
4.5.3.1.9 Date privind activitatea conduc ătorului auto  
(266) Cardul de conduc ător auto permite stocarea, pentru fiecare zi 
calendaristic ă în care a fost folosit cardul sau pentru care 
conducătorul auto a introdus manual activit ăți, următoarelor 
informații: 
— data;  
— un contor de prezen ță zilnică (a cărui valoare cre ște cu o 
unitate pentru fiecare dintre zilele calendaristice respec ­
tive);  
— distanța totală parcursă de conduc ătorul auto în decursul 
zilei respective;  
— regimul de conducere la ora 00.00;  
— în cazul oric ăror modific ări ale activit ății conducătorului 
auto și/sau ale regimului de conducere și/sau ale oric ărei 
introduceri sau retrageri a cardului de conduc ător auto:  
— regimul de conducere (ECHIPAJ, SINGUR);  
— slotul (CONDUC ĂTOR AUTO, COPILOT);  
— starea cardului (INTRODUS, NEINTRODUS);  
— activitatea (CONDUCERE, DISPONIBILITATE, 
MUNCĂ, PAUZĂ/ODIHNĂ); 
— ora modific ării. 
(267) Memoria cardului de conduc ător auto permite stocarea de 
date privind activit ățile conduc ătorului auto timp de cel 
puțin 28 de zile (activitatea medie a unui conduc ător auto 
este definit ă ca incluzând 93 de schimb ări de activitate pe zi).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 62  
(268) Datele enumerate la cerin țele 261, 264 și 266 se stocheaz ă 
astfel încât s ă permită extragerea activit ăților în ordinea 
desfășurării lor, chiar și în cazul unei suprapuneri a timpului.  
4.5.3.1.10 Date privind vehiculele utilizate  
(269) Cardul de conduc ător auto permite stocarea, pentru fiecare zi 
calendaristic ă în care a fost utilizat cardul și pentru fiecare 
perioadă de utilizare a unui anumit vehicul din ziua respectiv ă 
(o perioadă de utilizare include toate ciclurile consecutive de 
introducere/retragere a cardului desf ășurate în vehiculul 
respectiv, din punctul de vedere al cardului), a urm ătoarelor 
date:  
— data și ora primei utiliz ări a vehiculului ( și anume, prima 
introducere a cardului pentru respectiva perioad ă de 
utilizare, sau ora 00.00 dac ă perioada de utilizare este în 
curs la ora respectiv ă); 
— valoarea indicat ă de odometrul vehiculului în momentul 
respectiv;  
— data și ora ultimei utiliz ări a vehiculului ( și anume,ultima 
retragere a cardului pentru respectiva perioad ă de utilizare 
sau ora 23:59 dac ă perioada de utilizare este în curs la ora 
respectivă); 
— valoarea indicat ă de odometrul vehiculului în momentul 
respectiv;  
— VRN și statul membru de înmatriculare a vehiculului.  
(270) Cardul de conduc ător auto permite stocarea a cel pu țin 84 de 
astfel de înregistr ări. 
4.5.3.1.11 Locurile în care încep și/sau se încheie zilele de lucru  
(271) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
privind locurile în care încep și/sau se încheie zilele de lucru, 
introduse de conduc ătorul auto:  
— data și ora introducerii (sau data/ora legate de intro ­
ducerea datelor, dac ă aceasta se efectueaz ă pe parcursul 
procedurii de introducere manual ă); 
— tipul datelor introduse (început sau sfâr șit, condiția intro­
ducerii);  
— țara și regiunea introduse;  
— valoarea indicat ă de odometrul vehiculului.  
(272) Memoria cardului de conduc ător auto permite stocarea a cel 
puțin 42 de perechi de astfel de înregistr ări. 
4.5.3.1.12 Date privind sesiunile de utilizare a cardului  
(273) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
privind vehiculul în care a fost deschis ă sesiunea în curs:  
— data și ora deschiderii sesiunii ( și anume, ale introducerii 
cardului), cu o rezolu ție de o secund ă; 
— VRN și statul membru de înmatriculare.  
4.5.3.1.13 Date privind activit ățile de control  
(274) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
privind activit ățile de control:  
— data și ora controlului;  
— numărul cardului de control și statul membru emitent;  
— tipul controlului [afi șare și/sau imprimare și/sau 
descărcare din VU și/sau de pe card (a se vedea nota)];  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 63  
— perioada desc ărcată, dacă a avut loc o desc ărcare;  
— VRN și statul membru de înmatriculare a vehiculului 
controlat.  
Notă: descărcarea informa țiilor de pe card va fi înregistrat ă 
numai dac ă se realizeaz ă prin intermediul unei aparaturi de 
înregistrare.  
(275) Cardul de conduc ător auto permite stocarea unei singure 
astfel de înregistr ări. 
4.5.3.1.14 Date privind condi țiile specifice  
(276) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
legate de condi țiile specifice introduse în timp ce cardul este 
introdus (indiferent de slot):  
— data și ora introducerii;  
— tipul de condi ție specifică. 
(277) Cardul de conduc ător auto permite stocarea a cel pu țin 56 de 
astfel de înregistr ări. 
4.5.3.2 A p l i c a ț i e p e n t r u t a h o g r a f d e a 2 - a g e n e r a ț i e 
( i n a c c e s i b i l ă u n i t ă ț i l o r m o n t a t e p e v e h i c u l d e 
p r i m ă g e n e r a ț i e ) 
4.5.3.2.1 Identificarea aplica ției 
(278) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
de identificare a aplica ției: 
— identificarea aplica ției pentru tahograf;  
— identificarea tipului de card de tahograf.  
4.5.3.2.2 Chei și certificate  
(279) Cardul de conduc ător auto permite stocarea unei serii de chei 
și certificate criptografice, în conformitate cu apendicele 11 
partea B.  
4.5.3.2.3 Identificarea cardului  
(280) Cardul de conduc ător auto permit stocarea urm ătoarelor date 
de identificare a cardului:  
— numărul cardului;  
— statul membru emitent, denumirea autorit ății emitente, 
data emiterii;  
— data de la care este valabil cardul, data expir ării cardului.  
4.5.3.2.4 Identificarea titularului cardului  
(281) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
de identificare a titularului cardului:  
— numele titularului;  
— prenumele titularului;  
— data na șterii;  
— limba preferat ă de titular.  
4.5.3.2.5 Desc ărcarea informa țiilor de pe card  
(282) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
legate de desc ărcarea informa țiilor de pe card:  
— data și ora la care s-a efectuat ultima desc ărcare a infor ­
mațiilor de pe card (în alte scopuri decât în vederea unui 
control).  
(283) Cardul de conduc ător auto permite stocarea unei singure 
astfel de înregistr ări. 
4.5.3.2.6 Informa ții privind permisul de conducere  
(284) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
privind permisul de conducere:  
— statul membru emitent, denumirea autorit ății emitente;  
— numărul permisului de conducere (la data emiterii 
cardului).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 64  
4.5.3.2.7 Date privind evenimentele  
În sensul prezentului paragraf, ora se înregistreaz ă cu o rezolu ție de 
1 secundă. 
(285) Cardul de conduc ător auto permite stocarea de date legate de 
următoarele evenimente detectate de aparatura de înregistrare 
în timp ce cardul este introdus:  
— suprapunere a timpului (dac ă evenimentul este provocat 
de cardul respectiv);  
— introducerea cardului în timpul conducerii (dac ă eveni­
mentul afecteaz ă cardul respectiv);  
— încheierea incorect ă a ultimei sesiuni de utilizare a 
cardului (dac ă evenimentul afecteaz ă cardul respectiv);  
— întreruperea aliment ării cu energie electric ă; 
— eroare de comunicare cu echipamentul de comunicare la 
distanță; 
— evenimentul „Absen ța informațiilor de pozi ționare de la 
receptorul GNSS”;  
— eroare de comunicare cu echipamentul GNSS extern;  
— eroare privind datele de la senzorul de mi șcare;  
— conflict privind deplasarea vehiculului;  
— tentative de înc ălcare a securit ății; 
— conflict de or ă. 
(286) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
privind aceste evenimente:  
— codul evenimentului;  
— data și ora începerii evenimentului (sau a introducerii 
cardului dac ă evenimentul era în curs la momentul 
respectiv);  
— data și ora încheierii evenimentului (sau a retragerii 
cardului dac ă evenimentul era în curs la momentul 
respectiv);  
— VRN și statul membru de înmatriculare a vehiculului 
afectat de eveniment.  
Notă: Pentru evenimentul „Suprapunere a timpului”:  
— data și ora începerii evenimentului trebuie s ă corespund ă 
datei și orei retragerii cardului din vehiculul precedent;  
— data și ora încheierii evenimentului trebuie s ă corespund ă 
datei și orei introducerii cardului în vehiculul utilizat la 
momentul respectiv;  
— datele privind vehiculul trebuie s ă corespund ă vehiculului 
din momentul respectiv (cel care a declan șat eveni­
mentul).  
Notă: Pentru evenimentul: „Încheiere incorect ă a ultimei 
sesiuni de utilizare a cardului”:  
— data și ora începerii evenimentului trebuie s ă corespund ă 
datei și orei de introducere a cardului pentru sesiunea care 
nu a fost încheiat ă corect;  
— data și ora încheierii evenimentului trebuie s ă corespund ă 
datei și orei introducerii cardului pentru sesiunea pe 
parcursul c ăreia a fost detectat evenimentul (sesiunea 
din momentul respectiv);  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 65  
— datele privind vehiculul trebuie s ă corespund ă vehiculului 
în care s-a desf ășurat sesiunea care nu a fost încheiat ă 
corect.  
(287) Cardul de conduc ător auto permite stocarea de date privind 
cele mai recente șase evenimente din fiecare tip ( și anume, 66 
de evenimente).  
4.5.3.2.8 Date privind anomaliile  
În sensul prezentului paragraf, ora se înregistreaz ă cu o rezolu ție de 
1 secundă. 
(288) Cardul de conduc ător auto permite stocarea de date privind 
următoarele anomalii detectate de aparatura de înregistrare în 
timp ce cardul este introdus:  
▼M1 
— anomalie a cardului (dac ă anomalia afecteaz ă cardul);  
▼B 
— anomalie a aparaturii de înregistrare.  
(289) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
privind aceste anomalii:  
— codul anomaliei;  
— data și ora începerii anomaliei (sau a introducerii cardului 
dacă anomalia era în curs la momentul respectiv);  
— data și ora încheierii anomaliei (sau a retragerii cardului 
dacă anomalia era în curs la momentul respectiv);  
— VRN și statul membru de înmatriculare a vehiculului 
afectat de anomalie.  
(290) Cardul de conduc ător auto permite stocarea de date privind 
cele mai recente dou ăsprezece anomalii din fiecare tip ( și 
anume, 24 de anomalii).  
4.5.3.2.9 Date privind activitatea conduc ătorului auto  
(291) Cardul de conduc ător auto permite stocarea, pentru fiecare zi 
calendaristic ă în care a fost folosit cardul sau pentru care 
conducătorul auto a introdus manual activit ăți, următoarelor 
informații: 
— data;  
— un contor de prezen ță zilnică (a cărui valoare cre ște cu o 
unitate pentru fiecare dintre zilele calendaristice respec ­
tive);  
— distanța totală parcursă de conduc ătorul auto în cursul 
zilei respective;  
— regimul de conducere la ora 00.00;  
— în cazul oric ăror modific ări ale activit ății conducătorului 
auto și/sau ale regimului de conducere și/sau ale oric ărei 
introduceri sau retrageri a cardului de conduc ător auto:  
— regimul de conducere (ECHIPAJ, SINGUR);  
— slotul (CONDUC ĂTOR AUTO, COPILOT);  
— starea cardului (INTRODUS, NEINTRODUS);  
— activitatea (CONDUCERE, DISPONIBILITATE, 
MUNCĂ, PAUZĂ/ODIHNĂ); ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 66  
— ora modific ării. 
(292) Memoria cardului de conduc ător auto permite stocarea de 
date privind activit ățile conduc ătorului auto timp de cel 
puțin 28 de zile (activitatea medie a unui conduc ător auto 
este definit ă ca incluzând 93 de schimb ări de activitate pe zi).  
(293) Datele enumerate la cerin țele 286, 289 și 291 se stocheaz ă 
astfel să permită extragerea activit ăților în ordinea desf ășurării 
lor, chiar și în cazul unei suprapuneri a timpului.  
4.5.3.2.10 Date privind vehiculele folosite  
(294) Cardul de conduc ător auto permite stocarea, pentru fiecare zi 
calendaristic ă în care a fost utilizat cardul și pentru fiecare 
perioadă de utilizare a unui anumit vehicul din ziua respectiv ă 
(o perioadă de utilizare include toate ciclurile consecutive de 
introducere/retragere a cardului desf ășurate în vehiculul 
respectiv, din punctul de vedere al cardului), a urm ătoarelor 
date:  
— data și ora primei utiliz ări a vehiculului ( și anume, prima 
introducere a cardului pentru respectiva perioad ă de 
utilizare, sau ora 00.00 dac ă perioada de utilizare este în 
curs la ora respectiv ă); 
— valoarea indicat ă de odometrul vehiculului la ora 
respectivă a primei utiliz ări; 
— data și ora ultimei utiliz ări a vehiculului ( și anume, ultima 
retragere a cardului pentru respectiva perioad ă de utilizare 
sau ora 23:59 dac ă perioada de utilizare este în curs la ora 
respectivă); 
— valoarea indicat ă de odometrul vehiculului la ora 
respectivă a ultimei utiliz ări; 
— VRN și statul membru de înmatriculare a vehiculului;  
— VIN al vehiculului respectiv.  
(295) Cardul de conduc ător auto permite stocarea a cel pu țin 84 de 
astfel de înregistr ări. 
4.5.3.2.11 Locurile și pozițiile în care încep și/sau se încheie zilele de lucru  
(296) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
privind locurile în care încep și/sau se încheie zilele de lucru, 
introduse de conduc ătorul auto:  
— data și ora introducerii (sau data/ora legate de intro ­
ducerea datelor, dac ă aceasta se efectueaz ă pe parcursul 
procedurii de introducere manual ă); 
— tipul introducerii (început sau sfâr șit, condiția introdu­
cerii);  
— țara și regiunea introduse;  
— valoarea indicat ă de odometrul vehiculului;  
— poziția vehiculului;  
— precizia GNSS, data și ora determin ării poziției. 
(297) Memoria cardului de conduc ător auto permite stocarea a cel 
puțin 84 de perechi de astfel de înregistr ări. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 67  
4.5.3.2.12 Date privind sesiunile de utilizare a cardului  
(298) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
privind vehiculul în care a fost deschis ă sesiunea în curs:  
— data și ora deschiderii sesiunii ( și anume, a introducerii 
cardului), cu o rezolu ție de o secund ă; 
— VRN și statul membru de înmatriculare.  
4.5.3.2.13 Date privind activit ățile de control  
(299) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
privind activit ățile de control:  
— data și ora controlului;  
— numărul cardului de control și statul membru emitent;  
— tipul controlului [afi șare și/sau imprimare și/sau 
descărcare din VU și/sau de pe card (a se vedea nota)];  
— perioada desc ărcată, dacă a avut loc o desc ărcare;  
— VRN și statul membru de înmatriculare a vehiculului 
controlat.  
Notă: cerințele de securitate impun ca desc ărcarea de pe card 
să poată fi înregistrat ă numai dac ă se realizeaz ă prin inter ­
mediul unei aparaturi de înregistrare.  
(300) Cardul de conduc ător auto permite stocarea unei singure 
astfel de înregistr ări. 
4.5.3.2.14 Date privind condi țiile specifice  
(301) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
legate de condi țiile specifice introduse în timp ce cardul este 
introdus (indiferent de slot):  
— data și ora introducerii;  
— tipul de condi ție specifică. 
(302) Cardul de conduc ător auto permite stocarea a cel pu țin 56 de 
astfel de înregistr ări. 
4.5.3.2.15 Date privind unit ățile montate pe vehicul utilizate  
(303) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
referitoare la diferitele unit ăți montate pe vehicul în care a 
fost utilizat cardul:  
— data și ora începerii perioadei utilizare a unit ății montate 
pe vehicul ( și anume, prima introducere a cardului în 
unitatea montat ă pe vehicul pentru perioada respectiv ă); 
— numele produc ătorului unit ății montate pe vehicul;  
— tipul de unitate montat ă pe vehicul;  
— numărul versiunii software-ului unit ății montate pe 
vehicul.  
(304) Cardul de conduc ător auto permite stocarea a cel pu țin 84 de 
astfel de înregistr ări. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 68  
4.5.3.2.16 Date privind locurile în care se încheie o perioad ă de conducere 
acumulată de trei ore  
(305) Cardul de conduc ător auto permite stocarea urm ătoarelor date 
legate de pozi ția vehiculului atunci când timpul de conducere 
acumulat atinge un multiplu de trei ore:  
— data și ora la care timpul de conducere acumulat atinge un 
multiplu de trei ore;  
— poziția vehiculului;  
— precizia GNSS, data și ora determin ării poziției; 
— valoarea indicat ă de odometrul vehiculului.  
(306) Cardul de conduc ător auto permite stocarea a cel pu țin 252 de 
astfel de înregistr ări. 
▼B 
4.5.4  Cardul de atelier  
4.5.4.1 A p l i c a ț i e p e n t r u t a h o g r a f ( a c c e s i b i l ă p e n t r u 
u n i t ă ț i l e m o n t a t e p e v e h i c u l d e p r i m a ș i a d o u a 
g e n e r a ț i e ) 
4.5.4.1.1 Identificarea aplica ției 
(307) Cardul de atelier permite stocarea urm ătoarelor date de iden ­
tificare a aplica ției: 
— identificarea aplica ției pentru tahograf;  
— identificarea tipului de card de tahograf.  
4.5.4.1.2 Chei și certificate  
(308) Cardul de atelier permite stocarea unei serii de chei și certi­
ficate criptografice, în conformitate cu apendicele 11 
partea A.  
(309) Cardul de atelier permite stocarea unui num ăr de identificare 
personal (cod PIN).  
4.5.4.1.3 Identificarea cardului  
(310) Cardul de atelier permite stocarea urm ătoarelor date de iden ­
tificare a cardului:  
— numărul cardului;  
— statul membru emitent, denumirea autorit ății emitente, 
data emiterii;  
— data de la care este valabil cardul, data expir ării cardului.  
4.5.4.1.4 Identificarea titularului cardului  
(311) Cardul de atelier permite stocarea urm ătoarelor date de iden ­
tificare a titularului cardului:  
— denumirea atelierului;  
— adresa atelierului;  
— numele titularului;  
— prenumele titularului;  
— limba preferat ă de titular.  
4.5.4.1.5 Desc ărcarea informa țiilor de pe card  
(312) Cardul de atelier permite stocarea unei înregistr ări a datelor 
privind desc ărcarea informa țiilor de pe card, în acela și mod ca 
un card de conduc ător auto.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 69  
4.5.4.1.6 Date privind etalonarea și reglarea orei  
(313) Cardul de atelier permite stocarea de înregistr ări privind etalo ­
nările și/sau reglările orei realizate în timp ce cardul este 
introdus în aparatura de înregistrare.  
(314) Fiecare înregistrare de etalonare con ține următoarele date:  
— scopul etalon ării (activare, prima instalare, instalare, 
inspecție periodic ă); 
— identificarea vehiculului;  
— parametrii actualiza ți sau confirma ți [w, k, l, dimensiunea 
pneurilor, reglajul limitatorului de vitez ă, odometrul 
(valorile vechi și cele noi), data și ora (valorile vechi și 
cele noi)];  
— identificarea aparaturii de înregistrare (num ărul de 
component ă al VU, num ărul de serie al VU, num ărul de 
serie al senzorului de mi șcare).  
(315) Cardul de atelier permite stocarea a cel pu țin 88 de astfel de 
înregistrări. 
(316) Cardul de atelier este prev ăzut cu un contor care indic ă 
numărul total de etalon ări efectuate cu cardul respectiv.  
(317) Cardul de atelier este prev ăzut cu un contor care indic ă 
numărul total de etalon ări efectuate dup ă ultima desc ărcare 
de date.  
4.5.4.1.7 Date privind evenimentele și anomaliile  
(318) Cardul de atelier permite stocarea de înregistr ări de date 
privind evenimentele și anomaliile, în acela și mod ca un 
card de conduc ător auto.  
(319) Cardul de atelier permite stocarea de date privind cele mai 
recente trei evenimente de fiecare tip ( și anume, 18 eveni ­
mente) și cele mai recente șase erori de fiecare tip ( și anume, 
12 erori).  
4.5.4.1.8 Date privind activitatea conduc ătorului auto  
(320) Cardul de atelier permite stocarea de date privind activitatea 
conducătorului auto, în acela și mod ca un card de conduc ător 
auto.  
(321) Cardul de atelier permite stocarea de date privind activitatea 
conducătorului auto pentru cel pu țin o zi de activitate medie a 
conducătorului auto.  
4.5.4.1.9 Date privind vehiculele utilizate  
(322) Cardul de atelier permite stocarea de înregistr ări de date 
privind vehiculele utilizate, în acela și mod ca un card de 
conducător auto.  
(323) Cardul de atelier permite stocarea a cel pu țin patru astfel de 
înregistrări. 
4.5.4.1.10 Date privind începutul și/sau sfârșitul zilelor de lucru  
(324) Cardul de atelier permite stocarea de înregistr ări de date 
privind începutul și/sau sfârșitul zilelor de lucru, în acela și 
mod ca un card de conduc ător auto.  
(325) Cardul de atelier permite stocarea a cel pu țin trei perechi de 
astfel de înregistr ări. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 70  
4.5.4.1.11 Date privind sesiunile de utilizare a cardului  
(326) Cardul de atelier permite stocarea unei înregistr ări a datelor 
privind sesiunile de utilizare a cardului, în acela și mod ca un 
card de conduc ător auto.  
4.5.4.1.12 Date privind activit ățile de control  
(327) Cardul de atelier permite stocarea unei înregistr ări a datelor 
privind activit ățile de control, în acela și mod ca un card de 
conducător auto.  
4.5.4.1.13 Date privind condi țiile specifice  
(328) Cardul de atelier permite stocarea de date relevante privind 
condițiile specifice, în acela și mod ca un card de conduc ător 
auto.  
(329) Cardul de atelier permite stocarea a cel pu țin două astfel de 
înregistrări. 
4.5.4.2 A p l i c a ț i a p e n t r u t a h o g r a f d e a 2 - a g e n e r a ț i e 
( i n a c c e s i b i l ă u n i t ă ț i l o r m o n t a t e p e v e h i c u l d e 
p r i m ă g e n e r a ț i e ) 
4.5.4.2.1 Identificarea aplica ției 
(330) Cardul de atelier permite stocarea urm ătoarelor date de iden ­
tificare a aplica ției: 
— identificarea aplica ției pentru tahograf;  
— identificarea tipului de card de tahograf.  
4.5.4.2.2 Chei și certificate  
(331) Cardul de atelier permite stocarea unei serii de chei și certi­
ficate criptografice, în conformitate cu apendicele 11 
partea B.  
(332) Cardul de atelier permite stocarea unui num ăr de identificare 
personal (cod PIN).  
4.5.4.2.3 Identificarea cardului  
(333) Cardul de atelier permite stocarea urm ătoarelor date de iden ­
tificare a cardului:  
— numărul cardului;  
— statul membru emitent, denumirea autorit ății emitente, 
data emiterii;  
— data de la care este valabil cardul, data expir ării cardului.  
4.5.4.2.4 Identificarea titularului cardului  
(334) Cardul de atelier permite stocarea urm ătoarelor date de iden ­
tificare a titularului cardului:  
— denumirea atelierului;  
— adresa atelierului;  
— numele titularului;  
— prenumele titularului;  
— limba preferat ă de titular.  
4.5.4.2.5 Desc ărcarea informa țiilor de pe card  
(335) Cardul de atelier permite stocarea unei înregistr ări a datelor 
privind desc ărcarea informa țiilor de pe card, în acela și mod ca 
un card de conduc ător auto.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 71  
4.5.4.2.6 Date privind etalonarea și reglarea orei  
(336) Cardul de atelier permite stocarea de înregistr ări privind etalo ­
nările și/sau reglările orei realizate în timp ce cardul este 
introdus în aparatura de înregistrare.  
(337) Fiecare înregistrare de etalonare con ține următoarele date:  
— scopul etalon ării (activare, prima instalare, instalare, 
inspecție periodic ă); 
— identificarea vehiculului;  
— parametrii actualiza ți sau confirma ți [w, k, l, dimensiunea 
pneurilor, reglajul limitatorului de vitez ă, odometrul 
(valorile vechi și cele noi), data și ora (valorile vechi și 
cele noi)];  
— identificarea aparaturii de înregistrare (num ărul de 
component ă al VU, num ărul de serie al VU, num ărul de 
serie al senzorului de mi șcare, numărul de serie al echi ­
pamentului de comunicare la distan ță și numărul de serie 
al echipamentului GNSS extern, dac ă este cazul);  
— tipurile și identificatorii tuturor sigiliilor montate;  
— capacitatea VU de a utiliza carduri de tahograf de prim ă 
generație (activate sau neactivate).  
(338) Cardul de atelier permite stocarea a cel pu țin 88 astfel de 
înregistrări. 
(339) Cardul de atelier este prev ăzut cu un contor care indic ă 
numărul total de etalon ări efectuate cu cardul respectiv.  
(340) Cardul de atelier este prev ăzut cu un contor care indic ă 
numărul total de etalon ări efectuate dup ă ultima desc ărcare 
de date.  
4.5.4.2.7 Date privind evenimentele și anomaliile  
(341) Cardul de atelier permite stocarea de înregistr ări de date 
privind evenimentele și anomaliile, în acela și mod ca un 
card de conduc ător auto.  
(342) Cardul de atelier permite stocarea de date privind cele mai 
recente trei evenimente de fiecare tip ( și anume, 33 eveni ­
mente) și cele mai recente șase erori de fiecare tip ( și anume, 
12 erori).  
4.5.4.2.8 Date privind activitatea conduc ătorului auto  
(343) Cardul de atelier permit stocarea de date privind activitatea 
conducătorului auto, în acela și mod ca un card de conduc ător 
auto.  
(344) Cardul de atelier permite stocarea de date privind activitatea 
conducătorului auto pentru cel pu țin o zi de activitate medie a 
conducătorului auto.  
4.5.4.2.9 Date privind vehiculele utilizate  
(345) Cardul de atelier permite stocarea de înregistr ări de date 
privind vehiculele utilizate, în acela și mod ca un card de 
conducător auto.  
(346) Cardul de atelier permite stocarea a cel pu țin patru astfel de 
înregistrări. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 72  
4.5.4.2.10 Date privind începutul și/sau sfârșitul zilelor de lucru  
(347) Cardul de atelier permite stocarea de înregistr ări de date 
privind începutul și/sau sfârșitul zilelor de lucru, în acela și 
mod ca un card de conduc ător auto.  
(348) Cardul de atelier permite stocarea a cel pu țin trei perechi de 
astfel de înregistr ări. 
4.5.4.2.11 Date privind sesiunile de utilizare a cardului  
(349) Cardul de atelier permite stocarea unei înregistr ări a datelor 
privind sesiunile de utilizare a cardului, în acela și mod ca un 
card de conduc ător auto.  
4.5.4.2.12 Date privind activit ățile de control  
(350) Cardul de atelier permite stocarea unei înregistr ări a datelor 
privind activit ățile de control, în acela și mod ca un card de 
conducător auto.  
4.5.4.2.13 Date privind unit ățile montate pe vehicul utilizate  
(351) Cardul de atelier permite stocarea urm ătoarelor date refe ­
ritoare la diferitele unit ăți montate pe vehicul în care a fost 
utilizat cardul:  
— data și ora începerii perioadei de utilizare a unit ății 
montate pe vehicul ( și anume, prima introducere a 
cardului în unitatea montat ă pe vehicul pentru perioada 
respectivă); 
— numele produc ătorului unit ății montate pe vehicul;  
— tipul de unitate montat ă pe vehicul;  
— numărul versiunii software-ului unit ății montate pe 
vehicul.  
(352) Cardul de atelier permite stocarea a cel pu țin patru astfel de 
înregistrări. 
▼M1 
4.5.4.2.14 Date privind locurile în care se încheie o perioad ă de conducere 
acumulată de trei ore  
(353) Cardul de atelier permite stocarea urm ătoarelor date legate de 
poziția vehiculului atunci când timpul de conducere acumulat 
atinge un multiplu de trei ore:  
— data și ora la care timpul de conducere acumulat atinge un 
multiplu de trei ore;  
— poziția vehiculului;  
— precizia GNSS, data și ora determin ării poziției; 
— valoarea indicat ă de odometrul vehiculului.  
(354) Cardul de atelier permite stocarea a cel pu țin 18 astfel de 
înregistrări. 
▼B 
4.5.4.2.15 Date privind condi țiile specifice  
(355) Cardul de atelier permite stocarea de date relevante privind 
condițiile specifice, în acela și mod ca un card de conduc ător 
auto.  
(356) Cardul de atelier permite stocarea a cel pu țin două astfel de 
înregistrări. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 73  
4.5.5  Cardul de control  
4.5.5.1 A p l i c a ț i e p e n t r u t a h o g r a f ( a c c e s i b i l ă p e n t r u 
u n i t ă ț i l e m o n t a t e p e v e h i c u l d e p r i m a ș i a d o u a 
g e n e r a ț i e ) 
4.5.5.1.1 Identificarea aplica ției 
(357) Cardul de control permite stocarea urm ătoarelor date de iden ­
tificare a aplica ției: 
— identificarea aplica ției pentru tahograf;  
— identificarea tipului de card de tahograf.  
4.5.5.1.2 Chei și certificate  
(358) Cardul de control permite stocarea unei serii de chei și certi­
ficate criptografice, în conformitate cu apendicele 11 
partea A.  
4.5.5.1.3 Identificarea cardului  
(359) Cardul de control permite stocarea urm ătoarelor date de iden ­
tificare a cardului:  
— numărul cardului;  
— statul membru emitent, denumirea autorit ății emitente, 
data emiterii;  
— data de la care este valabil cardul, data expir ării cardului 
(dacă există). 
4.5.5.1.4 Identificarea titularului cardului  
(360) Cardul de control permite stocarea urm ătoarelor date de iden ­
tificare a titularului cardului:  
— denumirea organismului de control;  
— adresa organismului de control;  
— numele titularului;  
— prenumele titularului;  
— limba preferat ă de titular.  
4.5.5.1.5 Date privind activit ățile de control  
(361) Cardul de control permite stocarea urm ătoarelor date privind 
activitățile de control:  
— data și ora controlului;  
— tipul controlului (afi șare și/sau imprimare și/sau 
descărcare din VU și/sau descărcare de pe card și/sau 
verificare a etalon ării în trafic);  
— perioada desc ărcată (dacă este cazul);  
— VRN și autoritatea competent ă din statul membru de 
înmatriculare a vehiculului controlat;  
— numărul cardului și statul membru emitent al cardului de 
conducător auto controlat.  
(362) Cardul de control permite stocarea a cel pu țin 230 de astfel de 
înregistrări. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 74  
4.5.5.2 A p l i c a ț i a p e n t r u t a h o g r a f G 2 ( i n a c c e s i b i l ă 
u n i t ă ț i l o r m o n t a t e p e v e h i c u l d e p r i m ă g e n e ­
r a ț i e ) 
4.5.5.2.1 Identificarea aplica ției 
(363) Cardul de control permite stocarea urm ătoarelor date de iden ­
tificare a aplica ției: 
— identificarea aplica ției pentru tahograf;  
— identificarea tipului de card de tahograf.  
4.5.5.2.2 Chei și certificate  
(364) Cardul de control permite stocarea unei serii de chei și certi­
ficate criptografice, în conformitate cu apendicele 11 
partea B.  
4.5.5.2.3 Identificarea cardului  
(365) Cardul de control permite stocarea urm ătoarelor date de iden ­
tificare a cardului:  
— numărul cardului;  
— statul membru emitent, denumirea autorit ății emitente, 
data emiterii;  
— data de la care este valabil cardul, data expir ării cardului 
(dacă este cazul).  
4.5.5.2.4 Identificarea titularului cardului  
(366) Cardul de control permite stocarea urm ătoarelor date de iden ­
tificare a titularului cardului:  
— denumirea organismului de control;  
— adresa organismului de control;  
— numele titularului;  
— prenumele titularului;  
— limba preferat ă de titular.  
4.5.5.2.5 Date privind activit ățile de control  
(367) Cardul de control permite stocarea urm ătoarelor date privind 
activitățile de control:  
— data și ora controlului;  
— tipul controlului (afi șare și/sau imprimare și/sau 
descărcare din VU și/sau descărcare de pe card și/sau 
verificare a etalon ării în trafic);  
— perioada aferent ă datelor desc ărcate (dacă este cazul);  
— VRN și autoritatea competent ă din statul membru de 
înmatriculare a vehiculului controlat;  
— numărul cardului și statul membru emitent al cardului de 
conducător auto controlat.  
(368) Cardul de control permite stocarea a cel pu țin 230 de astfel de 
înregistrări. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 75  
4.5.6  Card de societate  
4.5.6.1 A p l i c a ț i e p e n t r u t a h o g r a f ( a c c e s i b i l ă p e n t r u 
u n i t ă ț i l e m o n t a t e p e v e h i c u l d e p r i m a ș i a d o u a 
g e n e r a ț i e ) 
4.5.6.1.1 Identificarea aplica ției 
(369) Cardul de societate permite stocarea urm ătoarelor date de 
identificare a aplica ției: 
— identificarea aplica ției pentru tahograf;  
— identificarea tipului de card de tahograf.  
4.5.6.1.2 Chei și certificate  
(370) Cardul de societate permite stocarea unei serii de chei și 
certificate criptografice, în conformitate cu apendicele 11 
partea A.  
4.5.6.1.3 Identificarea cardului  
(371) Cardul de societate permite stocarea urm ătoarelor date de 
identificare a cardului:  
— numărul cardului;  
— statul membru emitent, denumirea autorit ății emitente, 
data emiterii;  
— data de la care este valabil cardul, data expir ării cardului 
(dacă există). 
4.5.6.1.4 Identificarea titularului cardului  
(372) Cardul de societate permite stocarea urm ătoarelor date de 
identificare a titularului cardului:  
— denumirea societ ății; 
— adresa societ ății. 
4.5.6.1.5 Date privind activitatea societ ății 
(373) Cardul de societate permite stocarea urm ătoarelor date privind 
activitatea societ ății: 
— data și ora activit ății; 
— tipul activit ății (blocare și/sau deblocare a VU și/sau 
descărcare din VU și/sau de pe card);  
— perioada desc ărcată (dacă este cazul);  
— numărul de înmatriculare al vehiculului și autoritatea 
competentă din statul membru de înmatriculare a vehicu ­
lului;  
— numărul cardului și statul membru emitent (în cazul unei 
descărcări de pe card).  
(374) Cardul de societate permite stocarea a cel pu țin 230 de astfel 
de înregistr ări. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 76  
4.5.6.2 A p l i c a ț i a p e n t r u t a h o g r a f G 2 ( i n a c c e s i b i l ă 
u n i t ă ț i l o r m o n t a t e p e v e h i c u l d e p r i m ă g e n e ­
r a ț i e ) 
4.5.6.2.1 Identificarea aplica ției 
(375) Cardul de societate permite stocarea urm ătoarelor date de 
identificare a aplica ției: 
— identificarea aplica ției pentru tahograf;  
— identificarea tipului de card de tahograf.  
4.5.6.2.2 Chei și certificate  
(376) Cardul de societate permite stocarea unei serii de chei și 
certificate criptografice, în conformitate cu apendicele 11 
partea B.  
4.5.6.2.3 Identificarea cardului  
(377) Cardul de societate permite stocarea urm ătoarelor date de 
identificare a cardului:  
— numărul cardului;  
— statul membru emitent, denumirea autorit ății emitente, 
data emiterii;  
— data de la care este valabil cardul, data expir ării cardului 
(dacă există). 
4.5.6.2.4 Identificarea titularului cardului  
(378) Cardul de societate permite stocarea urm ătoarelor date de 
identificare a titularului cardului:  
— denumirea societ ății; 
— adresa societ ății. 
4.5.6.2.5 Date privind activitatea societ ății 
(379) Cardul de societate permite stocarea urm ătoarelor date 
privind activitatea societ ății: 
— data și ora activit ății; 
— tipul activit ății (blocare și/sau deblocare a VU și/sau 
descărcare din VU și/sau de pe card);  
— perioada aferent ă datelor desc ărcate (dacă este cazul);  
— numărul de înmatriculare al vehiculului și autoritatea 
competentă din statul membru de înmatriculare a vehi ­
culului;  
— numărul cardului și statul membru emitent al cardului (în 
cazul unei desc ărcări de pe card).  
(380) Cardul de societate permite stocarea a cel pu țin 230 de astfel 
de înregistr ări. 
5. INSTALAREA APARATURII DE ÎNREGISTRARE  
5.1 Instalare  
(381) Aparaturile de înregistrare noi sunt livrate neactivate monta ­
torilor sau produc ătorilor de vehicule, cu to ți parametrii de 
etalonare prev ăzuți în capitolul 3.21 seta ți la valori implicite 
adecvate și valabile. În cazurile în care nu se aplic ă nicio 
valoare special ă, parametrii alfabetici sunt înlocui ți cu șiruri 
de „?”, iar parametrii numerici cu „0”. Furnizarea compo ­
nentelor de securitate ale aparaturii de înregistrare poate fi 
restricționată, dacă este necesar, în timpul certific ării de 
securitate  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 77  
(382) Înainte de activare, aparatura de înregistrare trebuie s ă 
permită accesul la func ția de etalonare, chiar dac ă 
aparatura nu este în modul etalonare.  
(383) Înainte de activare, aparatura de înregistrare nu înregistreaz ă 
și nici nu stocheaz ă datele men ționate la punctele 3.12.3, 
3.12.9 și 3.12.12 – 3.12.15 inclusiv.  
(384) În timpul instal ării, produc ătorii de vehicule preseteaz ă toți 
parametrii cunoscu ți. 
(385) Produc ătorii de vehicule sau montatorii activeaz ă aparatura 
de înregistrare montat ă cel târziu înainte ca vehiculul s ă fie 
utilizat în conformitate cu Regulamentul (CE) nr. 561/2006.  
(386) Activarea aparaturii de înregistrare se declan șează automat la 
prima introducere a unui card de atelier valabil în oricare 
dintre dispozitivele de interfa ță pentru card.  
(387) Dac ă este cazul, opera țiunile speciale necesare pentru 
asocierea senzorului de mi șcare la unitatea montat ă pe 
vehicul se realizeaz ă automat, înainte sau în timpul activ ării. 
(388) În mod similar, dac ă este cazul, opera țiunile speciale de 
cuplare a echipamentului GNSS extern la unitatea montat ă 
pe vehicul se realizeaz ă automat, înainte sau în timpul acti ­
vării. 
(389) Dup ă activare, aparatura de înregistrare controleaz ă integral 
drepturile de acces la func ții și date.  
(390) Dup ă activare, aparatura de înregistrare comunic ă echipa­
mentului de comunicare la distan ță datele securizate 
necesare în scopul controalelor selective în trafic.  
(391) Func țiile de înregistrare și stocare ale aparaturii de înre ­
gistrare trebuie s ă funcționeze integral dup ă activarea 
acesteia.  
(392) Instalarea este urmat ă de o etalonare. Nu este necesar ca 
prima etalonare s ă includă introducerea num ărului de înma ­
triculare al vehiculului (VRN) în cazul în care acesta nu este 
cunoscut de atelierul aprobat care trebuie s ă efectueze etalo ­
narea. În aceste condi ții și numai în acest moment, este 
posibil ca proprietarul vehiculului s ă introducă VRN 
folosind cardul de societate înainte de utilizarea vehiculului 
în conformitate cu Regulamentul (CE) nr. 561/2006 (de 
exemplu, utilizând comenzile prin intermediul unei 
structuri corespunz ătoare a meniului interfe ței om-mașină a 
unității montate pe vehicul) (  1 ). Actualizarea sau confirmarea 
acestei introduceri este posibil ă numai atunci când se 
folosește un card de atelier.  
(393) Instalarea unui echipament GNSS extern necesit ă cuplarea la 
unitatea montat ă pe vehicul și verificarea ulterioar ă a infor­
mațiilor de pozi ționare de la GNSS.  
(394) Aparatura de înregistrare trebuie pozi ționată în vehicul astfel 
încât conduc ătorul auto s ă poată accesa toate func țiile 
necesare de pe scaunul s ău. ▼B 
( 1 ) JO L 102, 11.4.2006, p. 1.
 02016R0799 — RO — 26.02.2020 — 002.001 — 78  
5.2 Pl ăcuța de instalare  
(395) Dup ă instalarea și verificarea aparaturii de înregistrare, pe 
acesta se aplic ă o plăcuță de instalare gravat ă sau imprimat ă 
în mod permanent, care s ă fie clar vizibil ă și ușor accesibil ă. 
În cazurile în care acest lucru nu este posibil, pl ăcuța se 
montează pe stâlpul „B” al vehiculului pentru a fi clar 
vizibilă. La vehiculele care nu au un stâlp „B”, pl ăcuța de 
instalare trebuie montat ă pe cadrul u șii de pe latura unde se 
află volanul și trebuie s ă fie clar vizibil ă în toate situa țiile. 
După fiecare inspec ție efectuat ă de un montator sau de un 
atelier aprobat, în locul pl ăcuței existente se aplic ă una nouă. 
▼M1 
(396) Plăcuța trebuie s ă conțină cel puțin următoarele informa ții: 
— numele, adresa sau denumirea comercial ă a montatorului 
sau a atelierului aprobat;  
— coeficientul caracteristic al vehiculului, sub forma „w = 
… imp/km”;  
— constanta aparaturii de înregistrare, sub forma „k = … 
imp/km”;  
— circumferin ța efectivă a pneurilor ro ților, sub forma „l = 
… mm”;  
— dimensiunea pneurilor;  
— data la care au fost m ăsurate coeficientul caracteristic al 
vehiculului și circumferin ța efectivă a pneurilor ro ților; 
— numărul de identificare al vehiculului;  
— prezența (sau absen ța) unui echipament GNSS extern;  
— numărul de serie al echipamentului GNSS extern, dac ă 
este cazul;  
— numărul de serie al echipamentului de comunicare la 
distanță, dacă există; 
— numerele de serie ale tuturor sigiliilor montate;  
— partea vehiculului unde este instalat adaptorul, dac ă este 
cazul;  
— partea vehiculului unde este instalat senzorul de mi șcare, 
dacă acesta nu este conectat la cutia de viteze sau dac ă 
nu se folose ște un adaptor;  
— o descriere a culorii cablului dintre adaptor și partea 
vehiculului care îi furnizeaz ă impulsurile de intrare;  
— numărul de serie al senzorului de mi șcare integrat al 
adaptorului.  
▼B 
(397) Folosirea unei pl ăcuțe suplimentare este permis ă numai în 
cazul vehiculelor M1 și N1 prev ăzute cu un adaptor în 
conformitate cu Regulamentul (CE) nr. 68/2009 (  1 ), astfel 
cum a fost modificat ultima dat ă, și dacă nu este posibil ă 
includerea tuturor informa țiilor necesare prev ăzute la cerin ța 
396. În aceste cazuri, pl ăcuța suplimentar ă trebuie să conțină 
cel puțin ultimele patru liniu țe de la cerin ța 396.  ▼B 
( 1 ) Regulamentul (CE) nr. 68/2009 al Comisiei din 23 ianuarie 2009 de adaptare pentru a 
noua oară la progresul tehnic a Regulamentului (CEE) nr. 3821/85 al Consiliului privind 
aparatura de înregistrare în transportul rutier (JO L 21, 24.1.2009, p. 3).
 02016R0799 — RO — 26.02.2020 — 002.001 — 79  
Dacă se folose ște o plăcuță suplimentar ă, aceasta se 
montează lângă prima plăcuță, descrisă la cerința 396, și 
trebuie să aibă același nivel de protec ție. În plus, pe 
plăcuța suplimentar ă figureaz ă numele, adresa sau 
denumirea comercial ă a montatorului sau a atelierului 
mecanic aprobat care a efectuat instalarea, precum și data 
instalării. 
5.3 Sigilarea  
(398) Se sigileaz ă următoarele părți: 
— orice conexiune care, în cazul deconect ării, ar cauza 
producerea unor modific ări indetectabile sau pierderea 
indetectabil ă a unor date (acest lucru poate fi valabil, 
de exemplu, pentru senzorul de mi șcare montat pe 
cutia de viteze, pentru adaptorul destinat vehiculelor 
M1/N1, pentru conexiunea GNSS extern ă sau pentru 
unitatea montat ă pe vehicul);  
— plăcuța de instalare, în afar ă de cazul în care aceasta este 
aplicată astfel încât nu poate fi îndep ărtată fără a distruge 
inscripțiile. 
▼M1 
(398a) Sigiliile men ționate anterior trebuie s ă fie certificate conform 
standardului EN 16882:2016.  
▼B 
(399) Sigiliile men ționate anterior pot fi îndep ărtate:  
— în caz de urgen ță; 
— pentru instalarea, ajustarea sau repararea unui limitator 
de viteză sau a oric ărui alt dispozitiv care contribuie la 
siguranța rutieră, cu condiția ca aparatura de înregistrare 
să funcționeze în continuare în mod corect și fiabil și să 
fie resigilat de un montator sau de un atelier aprobat (în 
conformitate cu dispozi țiile capitolului 6) imediat dup ă 
montarea limitatorului de vitez ă sau a oric ărui alt 
dispozitiv care contribuie la siguran ța rutieră, sau în 
termen de șapte zile în celelalte cazuri.  
(400) De fiecare dat ă când aceste sigilii sunt rupte, se elaboreaz ă 
și se transmite autorit ății competente o declara ție scrisă cu 
privire la motivele ac țiunii respective.  
(401) Sigiliile trebuie s ă poarte un num ăr de identificare atribuit de 
producătorul de sigilii. Acest num ăr trebuie s ă fie unic și 
diferit de orice alt num ăr de sigiliu atribuit de orice alt 
producător de sigilii.  
▼M1 
Acest num ăr unic de identificare se înscrie astfel încât s ă nu 
poată fi șters si are urm ătoarea configura ție: 
MMNNNNNNNN, unde MM reprezint ă numărul unic de 
identificare a produc ătorului (înregistrarea în baza de date 
urmează să fie gestionat ă de CE), iar NNNNNNNN 
reprezintă numărul alfanumeric unic al sigiliului, atribuit 
de producător. 
▼B 
(402) Sigiliile trebuie s ă aibă un spațiu liber unde montatorii, 
atelierele sau produc ătorii de vehicule aproba ți să poată 
adăuga o marc ă specială în conformitate cu articolul 22 
alineatul (3) din Regulamentul (UE) nr. 165/2014.  
Această marcă nu acoper ă numărul de identificare al sigi ­
liului.  
▼M1 
(403) Produc ătorii de sigilii trebuie s ă se înregistreze într-o baz ă 
de date specific ă atunci când un model de sigiliu este 
certificat în conformitate cu EN 16882:2016 și să facă 
publice numerele de identificare atribuite sigiliilor fabricate 
de ei, printr-o procedur ă care urmeaz ă să fie stabilit ă de 
Comisia European ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 80  
(404) Atelierele și producătorii de vehicule aproba ți trebuie s ă 
utilizeze, în temeiul Regulamentului (UE) nr. 165/2014, 
numai sigilii certificate în conformitate cu EN 16882:2016, 
produse de produc ătorii de sigilii înregistra ți în baza de date 
menționată anterior.  
▼B 
(405) Produc ătorii de sigilii și distribuitorii acestora trebuie s ă 
păstreze eviden țe de trasabilitate complete ale sigiliilor 
vândute pentru a fi utilizate în cadrul Regulamentului 
(UE) nr. 165/2014 și trebuie s ă fie pregătiți să le prezinte 
autorităților naționale competente ori de câte ori este 
necesar.  
(406) Numerele de identificare unice ale sigiliilor trebuie s ă fie 
vizibile pe pl ăcuța de instalare.  
6. CONTROALE, INSPEC ȚII ȘI REPARA ȚII 
Cerințele privind situa țiile în care pot fi îndep ărtate sigiliile, astfel 
cum sunt prev ăzute la articolul 22 alineatul (5) din Regulamentul 
(UE) nr. 165/2014, sunt definite în capitolul 5.3 din prezenta anex ă. 
6.1 Aprobarea montatorilor, a atelierelor și a produc ătorilor de 
vehicule  
Statele membre aprob ă, controleaz ă în mod regulat și certifică orga­
nismele îns ărcinate cu efectuarea de:  
— instalări; 
— controale;  
— inspecții; 
— reparații. 
Cardurile de atelier sunt emise numai montatorilor și/sau atelierelor 
aprobate pentru activarea și/sau etalonarea aparaturii de înregistrare 
în conformitate cu prezenta anex ă și, cu excep ția cazurilor justificate 
în mod corespunz ător: 
— care nu sunt eligibile pentru acordarea unui card de societate și 
— ale căror activit ăți profesionale nu sunt susceptibile de a 
compromite securitatea global ă a sistemului, astfel cum se 
prevede în apendicele 10.  
▼M1 
6.2 Verificarea componentelor noi și a celor reparate  
(407) Fiecare dispozitiv în parte, indiferent dac ă este nou sau 
reparat, trebuie verificat pentru a se constata dac ă 
funcționează corespunz ător și dacă citirile și înregistrările 
pe care le efectueaz ă sunt precise și respectă limitele 
prevăzute în capitolul 3.2.1, 3.2.2, 3.2.3 și 3.3.  
▼B 
6.3 Inspec ția instala ției 
▼M1 
(408) La instalarea pe un vehicul, întreaga instala ție (inclusiv 
aparatura de înregistrare) trebuie s ă respecte dispozi țiile 
privind toleran țele maxime prev ăzute în capitolul 3.2.1, 
3.2.2, 3.2.3 și 3.3. Întreaga instala ție trebuie sigilat ă în 
conformitate cu capitolul 5.3 și trebuie să includă o etalonare.  
▼B 
6.4 Inspec ții periodice  
(409) Inspec țiile periodice ale aparaturii montate pe vehicule se 
efectuează după orice repara ție a aparaturii sau dup ă orice 
modificare a coeficientului caracteristic al vehiculului sau a 
circumferin ței efective ale pneurilor sau dup ă ce aparatura a 
indicat ora UTC cu o eroare de peste 20 de minute sau dac ă 
VRN a fost modificat și cel puțin o dată în termen de doi ani 
(24 de luni) de la ultima inspec ție. ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 81  
(410) În cadrul acestor inspec ții se verific ă, printre altele:  
— dacă aparatura de înregistrare func ționează corespunz ător, 
inclusiv în ceea ce prive ște funcția de stocare a datelor pe 
cardurile de tahograf și comunicarea cu cititoarele pentru 
comunicarea la distan ță; 
— dacă este asigurat ă conformitatea cu dispozi țiile capi­
tolului 3.2.1 și 3.2.2 privind toleran țele maxime la 
instalare;  
— dacă este asigurat ă conformitatea cu dispozi țiile capi­
tolului 3.2.3 și 3.3;  
— dacă aparatura de înregistrare poart ă marca de omologare 
de tip;  
— dacă plăcuța de instalare, astfel cum este definit ă la 
cerința 396, și plăcuța descriptiv ă, astfel cum este 
definită la cerința 225, sunt fixate;  
— dimensiunea pneurilor și circumferin ța efectivă a pneu­
rilor;  
— dacă la aparatur ă nu sunt ata șate dispozitive de mani ­
pulare;  
— dacă sigiliile sunt amplasate în mod corect, dac ă sunt în 
stare bună, dacă numerele lor de identificare sunt valabile 
(dacă producătorul de sigilii este înregistrat în baza de 
date a CE) și dacă numerele lor de identificare corespund 
inscripțiilor de pe pl ăcuța de instalare (a se vedea cerin ța 
401).  
(411) Dac ă se constat ă că unul din evenimentele enumerate în 
capitolul 3.9 (Detectarea evenimentelor și/sau a anomaliilor) 
a avut loc dup ă ultima inspec ție și, conform produc ătorilor de 
tahografe și/sau autorit ăților naționale, poate pune în pericol 
securitatea echipamentului, atelierul:  
a. face o compara ție între datele de identificare a senzorului 
de mișcare conectat la cutia de viteze și cele de identi ­
ficare a senzorului de mi șcare asociat la unitatea montat ă 
pe vehicul;  
b. verifică dacă informațiile înscrise pe pl ăcuța de instalare 
coincid cu informa țiile înregistrate în unitatea montat ă pe 
vehicul;  
c. verifică dacă numărul de serie și numărul de omologare 
ale senzorului de mi șcare, în cazul în care acestea sunt 
imprimate pe carcasa senzorului de mi șcare, coincid cu 
informațiile stocate în memoria de date a aparaturii de 
înregistrare;  
d. compar ă datele de identificare inscrip ționate pe pl ăcuța 
descriptivă a echipamentului GNSS extern, dac ă este 
cazul, cu cele stocate în memoria de date a unit ății 
montate pe vehicul.  
(412) În rapoartele lor de inspec ție, atelierele țin evidența oricăror 
constatări referitoare la existen ța unor sigilii rupte sau a unor 
dispozitive de manipulare. Atelierele p ăstrează aceste 
rapoarte cel pu țin 2 ani și le pun la dispozi ția autorității 
competente ori de câte ori li se cere s ă facă acest lucru.  
(413) Aceste inspec ții includ o etalonare și o înlocuire preventiv ă a 
sigiliilor a c ăror montare ține de responsabilitatea atelierelor.  
6.5 M ăsurarea erorilor  
(414) Măsurarea erorilor la instalare și în timpul utiliz ării se 
realizează în următoarele condi ții, considerate drept condi ții 
standard de testare:  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 82  
— vehicul f ără încărcătură, în stare normal ă de funcționare;  
— presiunea pneurilor în conformitate cu instruc țiunile 
producătorului;  
— uzura pneurilor în limitele permise de legisla ția națională; 
— deplasarea vehiculului:  
— vehiculul avanseaz ă, pe baza ac țiunii motorului propriu, 
în linie dreapt ă, pe teren plat, cu o vitez ă de 50 ± 5 km/h. 
Distanța de măsurare trebuie s ă fie de cel pu țin 1 000 m.  
— pentru testare pot fi folosite și metode alternative, de 
exemplu un banc dinamometric adecvat, cu condi ția ca 
acesta să aibă o precizie comparabil ă. 
6.6 Repara ții 
(415) Atelierele trebuie s ă poată descărca date din aparatura de 
înregistrare pentru a le transmite societ ății de transport în 
cauză. 
(416) Atelierele autorizate emit societ ăților de transport un certificat 
care atestă că datele nu pot fi desc ărcate, în cazul în care o 
defecțiune a aparaturii de înregistrare împiedic ă descărcarea 
datelor înregistrate anterior, chiar și după reparațiile efectuate 
de atelierul respectiv. Atelierul p ăstrează timp de cel pu țin 
doi ani un exemplar din fiecare certificat emis.  
7. EMITEREA CARDURILOR  
Procedurile de emitere a cardurilor stabilite de statele membre 
respectă următoarele dispozi ții: 
(417) Num ărul de card al primului card de tahograf emis unui 
solicitant con ține un indice secven țial (dacă este cazul), un 
indice de înlocuire și un indice de reînnoire setate la „0”.  
(418) Numerele de card ale tuturor cardurilor nenominale de 
tahograf emise unui singur organism de control, unui 
singur atelier sau unei singure societ ăți au primele 13 cifre 
identice și un indice secven țial diferit.  
(419) Un card de tahograf emis în scopul înlocuirii unui card de 
tahograf existent are acela și număr de card ca și cardul 
înlocuit, cu excep ția indicelui de înlocuire, a c ărui valoare 
se mărește cu „1” (în ordinea 0, …9, A, … Z).  
(420) Un card de tahograf emis în scopul înlocuirii unui card de 
tahograf existent are aceea și dată de expirare ca și cardul 
înlocuit.  
(421) Un card de tahograf emis în scopul reînnoirii unui card de 
tahograf existent are acela și număr de card ca și cardul 
înlocuit, cu excep ția indicelui de înlocuire, a c ărui valoare 
trebuie resetat ă la „0”, și cu excep ția indicelui de reînnoire a 
cărui valoare se m ărește cu „1” (în ordinea 0, …, 9, A, …, Z).  
(422) În vederea modific ării datelor administrative, schimbarea 
unui card de tahograf existent respect ă regulile de reînnoire 
dacă se produce în acela și stat membru sau regulile aplicabile 
primei emiteri în cazul în care se produce în alt stat membru.  
(423) În cazul cardurilor de atelier sau de control nenominale, 
rubrica „Numele titularului cardului” se completeaz ă cu 
denumirea atelierului sau a organismului de control ori cu 
numele montatorului sau al agentului de control, în cazul în 
care statele membre decid astfel.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 83  
(424) Statele membre fac schimb de date prin mijloace electronice 
pentru a asigura unicitatea cardurilor de conduc ător auto pe 
care le emit în conformitate cu articolul 31 din Regulamentul 
(UE) nr. 165/2014.  
8. OMOLOGAREA DE TIP A APARATURII DE ÎNREGISTRARE 
ȘI A CARDURILOR DE TAHOGRAF  
8.1 Generalit ăți 
▼M1 
În sensul prezentului capitol, termenul „aparatur ă de înregistrare” 
înseamnă „aparatura de înregistrare sau componentele acesteia”. 
Nu este necesar ă omologarea de tip pentru cablul sau cablurile 
care conecteaz ă senzorul de mi șcare, echipamentul GNSS extern 
sau echipamentul extern de comunicare la distan ță cu VU. Hârtia 
utilizată de aparatura de înregistrare este considerat ă drept o 
component ă a aparaturii de înregistrare.  
Orice produc ător poate solicita omologarea de tip a componentei sau 
componentelor aparaturii de înregistrare cu orice alt ă component ă 
sau alte componente ale aparaturii de înregistrare, cu condi ția ca 
fiecare component ă să respecte cerin țele din prezenta anex ă. Alter­
nativ, produc ătorii pot să solicite, de asemenea, omologarea de tip a 
aparaturii de înregistrare.  
După cum sunt descrise în defini ția 10 de la articolul 2 din prezentul 
regulament, unit ățile montate pe vehicul au variante în ansamblurile 
de componente. Oricare ar fi ansamblul de componente al unit ății 
montate pe vehicul, antena extern ă și (dacă este cazul) splitterul 
antenei conectat la receptorul GNSS sau la echipamentul extern 
de comunicare la distan ță nu fac parte din omologarea de tip a 
unității montate pe vehicul.  
Totuși, producătorii care au ob ținut omologarea de tip pentru 
aparatura de înregistrare trebuie s ă pună la dispozi ția publicului o 
listă a antenelor și a splitterelor compatibile cu orice unitate montat ă 
pe vehicul, echipament GNSS extern și echipament extern de comu ­
nicare la distan ță omologate de tip.  
▼B 
(425) Aparatura de înregistrare trebuie prezentat ă spre omologare în 
întregime, incluzând eventualele dispozitive suplimentare 
integrate.  
(426) Omologarea aparaturii de înregistrare și a cardurilor de 
tahograf trebuie s ă cuprindă teste de securitate, teste de 
funcționare și teste de interoperabilitate. Rezultatele pozitive 
obținute la fiecare dintre aceste teste sunt confirmate printr- 
un certificat corespunz ător. 
▼M1 
(427) Autorit ățile însărcinate cu omologarea de tip din statele 
membre nu acord ă certificate de omologare de tip pân ă 
când nu de țin: 
— un certificat de securitate (în cazul în care este solicitat de 
prezenta anex ă), 
— un certificat de func ționare,  
— un certificat de interoperabilitate (în cazul în care este 
solicitat de prezenta anex ă). 
pentru aparatura de înregistrare sau cardul de tahograf care 
face obiectul cererii de omologare de tip.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 84  
(428) Orice modificare a software-ului sau a hardware-ului 
aparaturii sau a naturii materialelor utilizate pentru 
producerea acesteia se notific ă, înainte de utilizare, autorit ății 
care a acordat omologarea de tip pentru aparatura în cauz ă. 
Autoritatea respectiv ă îi confirm ă producătorului extinderea 
omologării de tip sau poate solicita o actualizare sau o 
confirmare a certificatelor de func ționare, de securitate 
și/sau de interoperabilitate relevante.  
(429) Procedurile de actualizare in situ a software-ului aparaturii de 
înregistrare trebuie aprobate de autoritatea care a acordat 
omologarea de tip pentru aparatura de înregistrare în cauz ă. 
Actualizarea software-ului nu trebuie s ă modifice și nici să 
șteargă niciun fel de date privind activitatea conduc ătorului 
auto stocate în aparatura de înregistrare. Software-ul poate fi 
actualizat numai pe r ăspunderea produc ătorului aparaturii.  
(430) Omologarea de tip a modific ărilor aduse software-ului în 
scopul actualiz ării unei aparaturi de înregistrare deja 
omologate de tip nu poate fi refuzat ă dacă modificările 
respective vizeaz ă numai func ții nespecificate în prezenta 
anexă. Actualizarea software-ului unei aparaturi de înre ­
gistrare poate s ă nu implice introducerea de noi seturi de 
caractere, dac ă acest lucru nu este fezabil din punct de 
vedere tehnic.  
8.2 Certificatul de securitate  
(431) Certificatul de securitate se elibereaz ă în conformitate cu 
dispozițiile apendicelui 10 la prezenta anex ă. Componentele 
aparaturii de înregistrare care trebuie certificate sunt unitatea 
montată pe vehicul, senzorul de mi șcare, echipamentul GNSS 
extern și cardurile de tahograf.  
(432) În situa ția excepțională în care autorit ățile de certificare a 
securității refuză certificarea unei aparaturi noi din cauza 
mecanismelor de securitate învechite, omologarea de tip se 
va acorda în continuare numai în acest gen de situa ții parti­
culare și excepționale și numai dac ă nu există nicio altă 
soluție conform ă cu regulamentul.  
(433) În aceast ă situație, statul membru în cauz ă informeaz ă fără 
întârziere Comisia European ă care, în termen de dou ă­
sprezece luni calendaristice de la acordarea omolog ării de 
tip, lanseaz ă o procedur ă menită să garanteze c ă securitatea 
este readus ă la nivelul ini țial. 
8.3 Certificatul de func ționare  
(434) Fiecare candidat la omologarea de tip furnizeaz ă autorității de 
omologare de tip a statului membru toate materialele și 
întreaga documenta ție pe care aceasta le consider ă necesare.  
(435) În termen de o lun ă de la depunerea cererii, produc ătorii 
furnizează eșantioanele relevante din produsele pentru care 
se solicită omologarea de tip și documenta ția aferent ă 
cerute de laboratoarele desemnate s ă efectueze testele de 
funcționare. Toate costurile care deriv ă din aceast ă cerere 
sunt suportate de entitatea solicitant ă. Laboratoarele asigur ă 
confidențialitatea informa țiilor comerciale sensibile.  
(436) Produc ătorului i se elibereaz ă un certificat de func ționare 
numai dup ă obținerea de rezultate satisf ăcătoare cel pu țin la 
toate testele de func ționare prev ăzute în apendicele 9.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 85  
(437) Autoritatea de omologare de tip elibereaz ă certificatul de 
funcționare. Acest certificat indic ă, pe lângă numele benefi ­
ciarului și identificarea modelului, o list ă detaliată a testelor 
efectuate și a rezultatelor ob ținute.  
(438) Certificatul de func ționare al oric ărei componente a aparaturii 
de înregistrare indic ă, de asemenea, numerele de omologare 
de tip ale celorlalte componente compatibile și omologate de 
tip ale aparaturii de înregistrare, testate în vederea certific ării. 
(439) Certificatul de func ționare al oric ărei componente a aparaturii 
de înregistrare indic ă, de asemenea, standardul ISO sau CEN 
pe baza căruia a fost certificat ă interfața de funcționare.  
8.4 Certificatul de interoperabilitate  
(440) Testele de interoperabilitate sunt realizate de un singur labo ­
rator, aflat sub autoritatea și responsabilitatea Comisiei 
Europene.  
(441) Laboratorul înregistreaz ă cererile de teste de interoperabilitate 
depuse de produc ători în ordinea cronologic ă a primirii lor.  
(442) Cererile se înregistreaz ă oficial numai în momentul în care 
laboratorul de ține: 
— toate materialele și documentele necesare pentru 
realizarea acestor teste de interoperabilitate;  
— certificatul de securitate corespunz ător; 
— certificatul de func ționare corespunz ător. 
Data înregistr ării cererii se notific ă producătorului.  
(443) Laboratorul nu efectueaz ă niciun test de interoperabilitate 
pentru aparatura de înregistrare sau cardurile de tahograf 
care nu au primit un certificat de securitate și un certificat 
de funcționare, în afar ă de situațiile excepționale descrise la 
cerința 432.  
(444) Orice produc ător care solicit ă teste de interoperabilitate se 
angajează să cedeze laboratorului îns ărcinat cu efectuarea 
testelor respective toate materialele și documentele pe care 
le-a furnizat în vederea realiz ării testelor.  
(445) Testele de interoperabilitate se efectueaz ă în conformitate cu 
dispozițiile apendicelui 9 la prezenta anex ă, pentru toate 
tipurile de aparatur ă de înregistrare sau de carduri de 
tahograf:  
— a căror omologare de tip este înc ă valabilă; sau  
— care nu au primit înc ă omologarea de tip și care dețin un 
certificat de interoperabilitate valabil.  
(446) Testele de interoperabilitate vizeaz ă toate genera țiile 
aparaturii de înregistrare sau ale cardurilor de tahograf 
aflate încă în uz.  
(447) Certificatul de interoperabilitate este eliberat de c ătre 
laborator produc ătorului numai dup ă obținerea de rezultate 
satisfăcătoare la toate testele de interoperabilitate solicitate.  
(448) Dac ă rezultatele testelor de interoperabilitate nu sunt satisf ă­
cătoare pentru unul sau mai multe aparaturi de înregistrare 
sau carduri de tahograf, certificatul de interoperabilitate nu se 
eliberează decât dup ă ce produc ătorul a efectuat modific ările 
necesare și a obținut rezultate satisf ăcătoare la testele de 
interoperabilitate. Laboratorul identific ă sursa problemei  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 86  
împreună cu produc ătorii afecta ți de respectiva anomalie de 
interoperabilitate și încearcă să îi ajute să găsească o soluție 
tehnică. În cazul în care produc ătorul și-a modificat produsul, 
acesta este obligat s ă se informeze pe lâng ă autoritățile 
competente dac ă certificatul de securitate și certificatul de 
funcționare sunt înc ă valabile.  
(449) Certificatul de interoperabilitate este valabil șase luni. Acesta 
expiră la sfârșitul perioadei respective dac ă producătorul nu 
primește un certificat de omologare relevant. Certificatul este 
transmis de produc ător autorit ății de omologare de tip a 
statului membru care a emis certificatul de func ționare.  
(450) Niciun element care ar putea sta la originea unei anomalii de 
interoperabilitate nu trebuie folosit în scopul ob ținerii de 
profit sau pentru ob ținerea unei pozi ții dominante.  
8.5 Certificatul de omologare de tip  
(451) Autoritatea de omologare de tip a statului membru poate 
elibera certificatul de omologare de tip de îndat ă ce se află 
în posesia celor trei certificate solicitate.  
(452) Certificatul de omologare de tip al oric ărei componente a 
aparaturii de înregistrare trebuie s ă indice, de asemenea, 
numerele de omologare de tip ale celorlalte aparaturi de 
înregistrare interoperabile care de țin omologarea de tip.  
(453) Autoritatea de omologare de tip transmite laboratorului 
însărcinat cu efectuarea testelor de interoperabilitate un 
exemplar al certificatului de omologare de tip în momentul 
eliberării acestuia c ătre producător. 
(454) Laboratorul îns ărcinat cu efectuarea testelor de interoperabi ­
litate creeaz ă un site web public care con ține o listă actua­
lizată a modelelor de aparaturi de înregistrare sau de carduri 
de tahograf:  
— pentru care a fost înregistrat ă o cerere de efectuare a unor 
teste de interoperabilitate;  
— care au primit un certificat de interoperabilitate (chiar 
dacă acesta este provizoriu);  
— care au primit un certificat de omologare de tip.  
8.6 Procedur ă extraordinar ă: primele certificate de interoperabi ­
litate pentru aparatura de înregistrare și cardurile de tahograf 
de a 2-a genera ție 
(455) Pe parcursul unei perioade de patru luni de la certificarea 
interoperabilit ății unui prim ansamblu de aparatur ă de înre­
gistrare de a 2-a genera ție și carduri de tahograf de a 2-a 
generație (card de conduc ător auto, de atelier, de control și de 
societate), orice certificat de interoperabilitate eliberat 
(inclusiv primele) în urma cererilor înregistrate pe parcursul 
acestei perioade este considerat provizoriu.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 87  
(456) Dac ă, la sfâr șitul perioadei men ționate anterior, toate 
produsele în cauz ă sunt reciproc interoperabile, toate certifi ­
catele de interoperabilitate aferente devin definitive.  
(457) Dac ă, pe parcursul acestei perioade, apar anomalii de intero ­
perabilitate, laboratorul îns ărcinat cu efectuarea testelor de 
interoperabilitate trebuie s ă identifice cauzele problemelor 
cu ajutorul produc ătorilor implica ți și îi invită să facă modi­
ficările necesare.  
(458) Dac ă, la sfârșitul acestei perioade, problemele de interopera ­
bilitate persist ă, laboratorul îns ărcinat cu realizarea testelor de 
interoperabilitate, în colaborare cu produc ătorii în cauz ă și cu 
autoritățile de omologare de tip care au eliberat certificatul de 
funcționare aferent, trebuie s ă identifice cauzele anomaliilor 
de interoperabilitate și să stabileasc ă modificările care ar 
trebui efectuate de c ătre fiecare dintre produc ătorii în 
cauză. Căutarea de solu ții tehnice dureaz ă maximum dou ă 
luni, după care, dac ă nu se găsește nicio solu ție comună, 
Comisia, dup ă consultarea laboratorului îns ărcinat cu efec ­
tuarea testelor de interoperabilitate, decide care aparatur ă și 
care carduri primesc un certificat de interoperabilitate 
definitiv și precizeaz ă motivele pe baza c ărora a fost 
adoptată decizia respectiv ă. 
(459) Orice cerere de efectuare a unor teste de interoperabilitate 
înregistrată de laborator între sfâr șitul perioadei de patru 
luni de la eliberarea primului certificat provizoriu de intero ­
perabilitate și data deciziei adoptate de Comisie men ționată la 
cerința 455 trebuie amânat ă până la rezolvarea problemelor 
inițiale de interoperabilitate. Cererile respective se prelu ­
crează apoi în ordinea cronologic ă a înregistr ării. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 88  
Apendicele 1  
DICȚIONAR DE DATE  
CUPRINS  
1. INTRODUCERE  
1.1. Metoda de stabilire a defini țiilor tipurilor de date  
1.2. Referin țe 
2. DEFINI ȚIILE TIPURILOR DE DATE  
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  
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  
2.25. CardMACertificate  
2.26. CardNumber  
2.27. CardPlaceDailyWorkPeriod  
2.28. CardPrivateKey  
2.29. CardPublicKey  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 89  
2.30. CardRenewalIndex  
2.31. CardReplacementIndex  
2.32. CardSignCertificate  
2.33. CardSlotNumber  
2.34. CardSlotsStatus  
2.35. CardSlotsStatusRecordArray  
2.36. CardStructureVersion  
2.37. CardVehicleRecord  
2.38. CardVehiclesUsed  
2.39. CardVehicleUnitRecord  
2.40. CardVehicleUnitsUsed  
2.41. Certificat  
2.42. CertificateContent  
2.43. CertificateHolderAuthorisation  
2.44. CertificateRequestID  
2.45. CertificationAuthorityKID  
2.46. CompanyActivityData  
2.47. CompanyActivityType  
2.48. CompanyCardApplicationIdentification  
2.49. CompanyCardHolderIdentification  
2.50. ControlCardApplicationIdentification  
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  
2.61. DriverCardApplicationIdentification  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 90  
2.62. DriverCardHolderIdentification  
▼M1 
2.63. Rezervat pentru o utilizare viitoare  
▼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  
2.74. FullCardNumberAndGeneration  
2.75. Generation  
2.76. GeoCoordinates  
2.77. GNSSAccuracy  
▼M1 
2.78. GNSSAccumulatedDriving  
2.79. GNSSAccumulatedDrivingRecord  
▼B 
2.80. GNSSPlaceRecord  
2.81. HighResOdometer  
2.82. HighResTripDistance  
2.83. HolderName  
2.84. InternalGNSSReceiver  
2.85. K-ConstantOfRecordingEquipment  
2.86. KeyIdentifier  
2.87. KMWCKey  
2.88. Language  
2.89. LastCardDownload  
2.90. LinkCertificate  
2.91. L-TyreCircumference  
2.92. MAC  
2.93. ManualInputFlag  
2.94. ManufacturerCode  
2.95. ManufacturerSpecificEventFaultData  
2.96. MemberStateCertificate  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 91  
2.97. MemberStateCertificateRecordArray  
2.98. MemberStatePublicKey  
2.99. Name  
2.100. NationAlpha  
2.101. NationNumeric  
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  
▼B 
2.112. NoOfSpecificConditionRecords  
2.113. OdometerShort  
2.114. OdometerValueMidnight  
2.115. OdometerValueMidnightRecordArray  
2.116. OverspeedNumber  
2.117. PlaceRecord  
2.118. PreviousVehicleInfo  
2.119. PublicKey  
2.120. RecordType  
2.121. RegionAlpha  
2.122. RegionNumeric  
2.123. RemoteCommunicationModuleSerialNumber  
2.124. RSAKeyModulus  
2.125. RSAKeyPrivateExponent  
2.126. RSAKeyPublicExponent  
2.127. RtmData  
2.128. SealDataCard  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 92  
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  
2.152. SpecificConditionRecord  
2.153. SpecificConditions  
2.154. SpecificConditionType  
2.155. Speed  
2.156. SpeedAuthorised  
2.157. SpeedAverage  
2.158. SpeedMax  
2.159. TachographPayload  
▼M1 
2.160. Rezervat pentru o utilizare viitoare  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 93  
2.161. TDesSessionKey  
2.162. TimeReal  
2.163. TyreSize  
2.164. VehicleIdentificationNumber  
2.165. VehicleIdentificationNumberRecordArray  
2.166. VehicleRegistrationIdentification  
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  
2.179. VuCardRecord  
2.180. VuCardRecordArray  
2.181. VuCertificate  
2.182. VuCertificateRecordArray  
2.183. VuCompanyLocksData  
2.184. VuCompanyLocksRecord  
2.185. VuCompanyLocksRecordArray  
2.186. VuControlActivityData  
2.187. VuControlActivityRecord  
2.188. VuControlActivityRecordArray  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 94  
2.189. VuDataBlockCounter  
2.190. VuDetailedSpeedBlock  
2.191. VuDetailedSpeedBlockRecordArray  
2.192. VuDetailedSpeedData  
2.193. VuDownloadablePeriod  
2.194. VuDownloadablePeriodRecordArray  
2.195. VuDownloadActivityData  
2.196. VuDownloadActivityDataRecordArray  
2.197. VuEventData  
2.198. VuEventRecord  
2.199. VuEventRecordArray  
2.200. VuFaultData  
2.201. VuFaultRecord  
2.202. VuFaultRecordArray  
▼M1 
2.203. VuGNSSADRecord  
2.204. VuGNSSADRecordArray  
▼B 
2.205. VuIdentification  
2.206. VuIdentificationRecordArray  
2.207. VuITSConsentRecord  
2.208. VuITSConsentRecordArray  
2.209. VuManufacturerAddress  
2.210. VuManufacturerName  
2.211. VuManufacturingDate  
2.212. VuOverSpeedingControlData  
2.213. VuOverSpeedingControlDataRecordArray  
2.214. VuOverSpeedingEventData  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 95  
2.215. VuOverSpeedingEventRecord  
2.216. VuOverSpeedingEventRecordArray  
2.217. VuPartNumber  
2.218. VuPlaceDailyWorkPeriodData  
2.219. VuPlaceDailyWorkPeriodRecord  
2.220. VuPlaceDailyWorkPeriodRecordArray  
2.221. VuPrivateKey  
2.222. VuPublicKey  
2.223. VuSerialNumber  
2.224. VuSoftInstallationDate  
2.225. VuSoftwareIdentification  
2.226. VuSoftwareVersion  
2.227. VuSpecificConditionData  
2.228. VuSpecificConditionRecordArray  
2.229. VuTimeAdjustmentData  
▼M1 
2.230. Rezervat pentru o utilizare viitoare  
2.231. Rezervat pentru o utilizare viitoare  
▼B 
2.232. VuTimeAdjustmentRecord  
2.233. VuTimeAdjustmentRecordArray  
2.234. WorkshopCardApplicationIdentification  
2.235. WorkshopCardCalibrationData  
2.236. WorkshopCardCalibrationRecord  
2.237. WorkshopCardHolderIdentification  
2.238. WorkshopCardPIN  
2.239. W-VehicleCharacteristicConstant  
2.240. VuPowerSupplyInterruptionRecord  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 96  
2.241. VuPowerSupplyInterruptionRecordArray  
2.242. VuSensorExternalGNSSCoupledRecordArray  
2.243. VuSensorPairedRecordArray  
3. DEFINIREA INTERVALELOR DE VALORI ȘI DE DIMENSIUNI  
4. SETURI DE CARACTERE  
5. CODAREA  
6. IDENTIFICATORII DE OBIECT ȘI IDENTIFICATORII DE 
APLICAȚIE 
6.1. Identificatorii de obiect  
6.2. Identificatorii de aplica ție 
1. INTRODUCERE  
Prezentul apendice cuprinde preciz ări privind formatele de date, 
elementele de date și structurile de date care trebuie utilizate de 
aparatura de înregistrare și de cardurile de tahograf.  
1.1. Metoda de stabilire a defini țiilor tipurilor de date  
În prezentul apendice se recurge la  Abstract Syntax Notation One  
(ASN.1) pentru a defini tipurile de date. Acest lucru permite definirea 
unor date simple și structurate, f ără a fi necesar ă o sintaxă specifică de 
transfer (reguli de codare) care s ă depindă de aplicație și de mediu.  
Convențiile de denumire a tipurilor ASN.1 sunt realizate conform stan ­
dardului ISO/IEC 8824-1. Aceasta implic ă faptul că: 
— acolo unde este posibil, semnifica ția tipului de date este indicat ă prin 
intermediul denumirilor alese;  
— dacă un tip de date reprezint ă o combina ție de alte tipuri de date, 
denumirea tipului de date în cauz ă constituie totu și o singur ă 
secvență de caractere alfabetice care începe cu o majuscul ă, dar se 
mai utilizeaz ă și alte majuscule în cadrul denumirii pentru a atribui 
semnificația corespondent ă fiecărei părți; 
— în general, denumirile tipurilor de date sunt legate de denumirile 
tipurilor de date din care sunt alc ătuite, ale echipamentelor în care 
sunt stocate datele și ale funcției atribuite datelor în cauz ă. 
Dacă un tip ASN.1 este deja definit în cadrul unui alt standard și dacă 
trebuie utilizat de aparatura de înregistrare, atunci tipul ASN.1 în cauz ă 
este definit în prezentul apendice.  
Pentru a permite aplicarea mai multor tipuri de reguli de codare, anumite 
tipuri ASN.1 cuprinse în prezentul apendice sunt condi ționate de iden ­
tificatorii intervalelor de valori. Identificatorii intervalelor de valori sunt 
definiți la punctul 3 și în apendicele 2.  
1.2. Referin țe 
În prezentul apendice se utilizeaz ă următoarele referin țe: 
ISO 639 Code for the representation of names of languages. 
First Edition: 1988.  
ISO 3166 Codes for the representation of names of countries 
and their subdivisions – Part 1: Country codes, 2013  
ISO 3779 Road vehicles – Vehicle identification number (VIN) 
– Content and structure. 2009  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 97  
ISO/IEC 7816-5 Identification cards – Integrated circuit cards – Part 5: 
Registration of application providers.  
Second edition: 2004.  
ISO/IEC 7816-6 Identification cards – Integrated circuit cards – Part 6: 
Interindustry data elements for interchange, 2004 + 
Technical Corrigendum 1: 2006  
ISO/IEC 8824-1 Information technology – Abstract Syntax Notation 
One (ASN.1): Specification of basic notation. 2008 
+ Technical Corrigendum 1: 2012 and Technical 
Corrigendum 2: 2014.  
ISO/IEC 8825-2 Information technology – ASN.1 encoding rules: 
Specification of Packed Encoding Rules (PER). 2008.  
ISO/IEC 8859-1 Information technology – 8 bit single-byte coded 
graphic character sets – Part 1: Latin alphabet No.1. 
First edition: 1998.  
ISO/IEC 8859-7 Information technology – 8 bit single-byte coded 
graphic character sets – Part 7: Latin/Greek 
alphabet. 2003.  
ISO 16844-3 Road vehicles – Tachograph systems – Motion 
Sensor Interface. 2004 + Technical Corrigendum 1: 
2006..  
TR-03110-3 BSI / ANSSI Technical Guideline TR-03110-3, 
Advanced Security Mechanisms for Machine 
Readable Travel Documents and eIDAS Token – 
Part 3 Common Specifications, version 2.20, 3. 
February 2015  
2. DEFINI ȚIILE TIPURILOR DE DATE  
Pentru fiecare din urm ătoarele tipuri de date, valoarea implicit ă pentru 
un conținut „necunoscut” sau care „nu se aplic ă” va consta în 
completarea elementului de date cu octe ți ‘FF’.  
Toate tipurile de date sunt utilizate pentru aplica țiile de genera ția 1 și de 
generația 2, cu excep ția cazului în care se prevede altfel.  
▼M1 
Pentru tipurile de date referitoare la card pentru aplica țiile de genera ția 1 
și de genera ția 2, dimensiunea specificat ă în prezentul apendice este cea 
pentru aplica ția de genera ția 2. Se presupune c ă dimensiunea pentru 
aplicația de genera ția 1 trebuie s ă fie deja cunoscut ă de cititor. 
Numerele cerin țelor din anexa IC legate de aceste tipuri de date 
includ atât aplica țiile de genera ția 1, cât și aplicațiile de genera ția 2. 
▼B 
2.1. ActivityChangeInfo  
Acest tip de date permite codarea, într-un cuvânt de doi octe ți, a stării 
slotului la 00.00 și/sau a regimului de conducere la 00.00 și/sau a 
modificărilor de activitate și/sau a modific ărilor regimului de 
conducere și/sau a modific ărilor stării cardului pentru un conduc ător 
auto sau un copilot. Acest tip de date se raporteaz ă la cerințele 105, 
266, 291, 320, 321, 343 și 344 din anexa 1C.
  
Atribuirea valorii – Octet aliniat : ‘scpaattttttttttt’B (16 bi ți) 
Pentru înregistr ările în memoria de date (sau starea slotului):  
‘s’B Slot:  
‘0’B: CONDUC ĂTOR AUTO,  
‘1’B: COPILOT,  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 98  
‘c’B Regim de conducere:  
‘0’B: SINGUR,  
‘1’B: ECHIPAJ,  
‘p’B Starea cardului de conduc ător auto (sau de atelier) din 
slotul relevant:  
‘0’B: INTRODUS, este introdus un card,  
‘1’B: NEINTRODUS, nu este introdus niciun card 
(sau este retras un card),  
‘aa’B Activitate:  
‘00’B: PAUZ Ă/PERIOAD Ă DE ODIHN Ă, 
‘01’B: DISPONIBILITATE,  
‘10’B: LUCRU,  
‘11’B: CONDUCERE,  
‘ttttttttttt’B Ora modific ării: Numărul de minute de la 00h00 în 
ziua dată. 
Pentru înregistr ările de pe cardul de conduc ător auto (sau de atelier) ( și 
regimul de conducere):  
‘s’B Slot (nu este relevant când ‘p’=1 cu excep ția notei de 
mai jos):  
‘0’B: CONDUC ĂTOR AUTO,  
‘1’B: COPILOT,  
‘c’B Regim de conducere (caz ‘p’=0) sau  
Starea activit ății următoare (caz ‘p’=1):  
‘0’B: SINGUR,  
‘0’B: NECUNOSCUT Ă 
‘1’B: ECHIPAJ,  
‘1’B: CUNOSCUT Ă (= introdus ă manual)  
‘p’B Starea cardului:  
‘0’B: INTRODUS, cardul este introdus în aparatura 
de înregistrare,  
‘1’B: NEINTRODUS, cardul nu este introdus (sau 
cardul este retras),  
‘aa’B Activitate (nu este relevant ă când ‘p’=1 și ‘c’=0, cu 
excepția notei de mai jos):  
‘00’B: PAUZ Ă/PERIOAD Ă DE ODIHN Ă, 
‘01’B: DISPONIBILITATE,  
‘10’B: LUCRU,  
‘11’B: CONDUCERE,  
‘ttttttttttt’B Ora modific ării: Numărul de minute de la 00h00 în 
ziua dată. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 99  
Notă pentru cazul de „retragere a cardului”:  
Atunci când cardul este retras:  
— ‘s’ este relevant și indică slotul din care este retras cardul,  
— ‘c’ trebuie s ă fie setat la 0,  
— ‘p’ trebuie s ă fie setat la 1,  
— ‘aa’ trebuie s ă codeze activitatea curent ă selectată în momentul 
respectiv,  
Ca urmare a unei introduceri manuale de date, bi ții ‘c’ și ‘aa’ din cuvânt 
(stocați pe un card) pot fi suprascri și mai târziu pentru a reflecta intro ­
ducerea de date.  
2.2. Address  
O adresă.
 
codePage  indică un set de caractere definit în capitolul 4,  
address  este o adres ă codată cu ajutorul setului de caractere precizat.  
2.3. AESKey  
Generația 2:  
O cheie AES cu o lungime de 128, 192 sau 256 de bi ți.
 
Atribuirea valorii : nu se furnizeaz ă indicații suplimentare.  
2.4. AES128Key  
Generația 2:  
O cheie AES128.
  
length  denotă lungimea cheii AES128 în octe ți. 
aes128Key  este o cheie AES cu o lungime de 128 de bi ți. 
Atribuirea valorii:  
lungimea trebuie s ă aibă valoarea 16.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 100  
2.5. AES192Key  
Generația 2:  
O cheie AES192.
  
length  denotă lungimea cheii AES192 în octe ți. 
aes192Key  este o cheie AES cu o lungime de 192 de bi ți. 
Atribuirea valorii:  
lungimea trebuie s ă aibă valoarea 24.  
2.6. AES256Key  
Generația 2:  
O cheie AES256.
  
length  denotă lungimea cheii AES256 în octe ți. 
aes256Key  este o cheie AES cu o lungime de 256 de bi ți. 
Atribuirea valorii:  
lungimea trebuie s ă aibă valoarea 32.  
2.7. BCDString  
BCDString se aplic ă pentru o reprezentare a zecimalei în cod binar 
(Binary Code Decimal , BCD). Acest tip de date se utilizeaz ă pentru a 
reprezenta o unitate zecimal ă într-un semioctet (4 bi ți). BCDString se 
bazează pe ISO/IEC 8824-1 ‘CharacterStringType’.
  
BCDString folose ște o notație „hstring”. Cifra din extremitatea stâng ă a 
șirului hexadecimal este cel mai important semioctet din primul octet. 
Pentru a ob ține un multiplu de octe ți, se insereaz ă semiocteți nuli, în 
cantitatea necesar ă, din poziția semioctetului din extremitatea stâng ă a 
primului octet.  
Cifrele permise sunt: 0, 1, .. 9.  
2.8. CalibrationPurpose  
Cod care explic ă de ce s-a înregistrat un set de parametri de etalonare. 
Acest tip de date se raporteaz ă la cerințele 097 și 098 din anexa 1B și la 
cerința 119 din anexa 1C.
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 101  
Atribuirea valorii:  
Generația 1:  
‘00’H valoare rezervat ă, 
‘01’H activare: înregistrarea parametrilor de etalonare 
cunoscuți, în momentul activ ării VU,  
‘02’H prima instalare: prima etalonare a VU dup ă activarea 
ei, 
‘03’H instalare: prima etalonare a VU în vehiculul actual,  
‘04’H inspec ție periodic ă. 
Generația 2:  
În plus față de genera ția 1, se utilizeaz ă următoarele valori:  
‘05’H introducerea VRN de c ătre societate,  
‘06’H reglarea orei f ără etalonare,  
de la ‘07’H pân ă la ‘7F’H RFU,  
de la ‘80’H pân ă la ‘FF’H Specific produc ătorului.  
2.9. CardActivityDailyRecord  
Informații, stocate pe un card, privind activit ățile conduc ătorului auto 
într-o anumit ă zi calendaristic ă. Acest tip de date se raporteaz ă la 
cerințele 266, 291, 320 și 343 din anexa 1C.
  
activityPreviousRecordLength  este lungimea total ă în octeți a înregis ­
trării zilnice anterioare. Valoarea maxim ă este dat ă de lungimea 
ȘIRULUI DE OCTE ȚI care con ține aceste înregistr ări [a se vedea  
CardActivityLengthRange  din apendicele 2 punctul 4.]. Atunci când 
această înregistrare este cea mai veche înregistrare zilnic ă, valoarea 
pentru  activityPreviousRecordLength  trebuie setat ă la 0.  
activityRecordLength  este lungimea total ă în octeți a acestei înregis ­
trări. Valoarea maxim ă este dată de lungimea ȘIRULUI DE OCTE ȚI 
care conține aceste înregistr ări. 
activityRecordDate  este data înregistr ării. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 102  
activityDailyPresenceCounter  este contorul prezen ței zilnice pentru 
card în ziua respectiv ă. 
activityDayDistance  este distan ța totală parcursă în ziua respectiv ă. 
activityChangeInfo  este setul de date  ActivityChangeInfo  pentru 
conducătorul auto în ziua respectiv ă. Acesta poate con ține maximum 1 
440 de valori (o schimbare de activitate pe minut). Acest set de date 
cuprinde întotdeauna  activityChangeInfo  care codeaz ă regimul de 
conducere la 00.00.  
2.10.  CardActivityLengthRange  
Numărul de octe ți de pe un card de conduc ător auto sau de pe un card 
de atelier, disponibil pentru stocarea înregistr ărilor privind activitatea 
conducătorului auto.
  
Atribuirea valorii : a se vedea apendicele 2.  
2.11.  CardApprovalNumber  
Numărul de omologare de tip al cardului.
  
Atribuirea valorii:  
Numărul de omologare trebuie s ă fie furnizat a șa cum este publicat pe 
site-ul web corespunz ător al Comisiei Europene, de exemplu inclusiv cu 
liniuțe dacă este cazul. Num ărul de omologare trebuie s ă fie aliniat la 
stânga.  
2.12.  CardCertificate  
Generația 1:  
Certificatul cheii publice a unui card.
  
2.13.  CardChipIdentification  
Informații, stocate pe un card, privind identificarea circuitului integrat 
(Integrated Circuit , IC) al cardului (cerin ța 249 din anexa 1C).  icSerial­
Number , împreună cu icManufacturingReferences , identifică în mod unic 
cipul cardului. Doar  icSerialNumber  nu este suficient pentru a identifica 
în mod unic cipul cardului.
  
icSerialNumber  este numărul de serie al IC.  
icManufacturingReferences  reprezintă identificatorul specific al produ ­
cătorului IC.  
2.14.  CardConsecutiveIndex  
Un indice secven țial al cardului [defini ția h)].
  
Atribuirea valorii : (a se vedea anexa 1C capitolul 7)  
Ordinea de cre ștere: ‘0, …, 9, A, …, Z, a, …, z’  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 103  
2.15.  CardControlActivityDataRecord  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind ultimul control la care a fost supus conduc ătorul auto 
(cerințele 274, 299, 327 și 350 din anexa 1C).
  
controlType  este tipul de control.  
controlTime  este data și ora la care a avut loc controlul.  
controlCardNumber  este  FullCardNumber  al agentului de control care 
a efectuat controlul.  
controlVehicleRegistration  reprezintă VRN și statul membru de înma ­
triculare ale vehiculului în care a avut loc controlul.  
controlDownloadPeriodBegin  și controlDownloadPeriodEnd  
reprezintă perioada desc ărcată, în cazul unei desc ărcări. 
2.16.  CardCurrentUse  
Informații privind utilizarea efectiv ă a cardului (cerin țele 273, 298, 326 
și 349 din anexa 1C).
  
sessionOpenTime  este ora la care cardul a fost introdus pentru utilizarea 
curentă. Acest element se seteaz ă la 0 în momentul retragerii cardului.  
sessionOpenVehicle  este identificarea vehiculului utilizat în prezent, 
setată la introducerea cardului. Acest element se seteaz ă la 0 în 
momentul retragerii cardului.  
2.17.  CardDriverActivity  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind activit ățile conduc ătorului auto (cerin țele 267, 268, 292, 
293, 321 și 344 din anexa 1C).
  
activityPointerOldestDayRecord  este specificarea începutului locului 
de stocare în memorie (num ărul de octe ți de la începutul șirului) a 
celei mai vechi înregistr ări complete aferente unei zile din șirul activi­
tyDailyRecords . Valoarea maxim ă este dată de lungimea șirului.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 104  
activityPointerNewestRecord  este specificarea începutului locului de 
stocare în memorie (num ărul de octe ți de la începutul șirului) a celei 
mai recente înregistr ări complete aferente unei zile din șirul activityDai ­
lyRecords . Valoarea maxim ă este dată de lungimea șirului.  
activityDailyRecords  este spa țiul disponibil pentru stocarea datelor 
privind activitatea conduc ătorului auto (structura datelor:  CardActivity ­
DailyRecord ) pentru fiecare zi calendaristic ă în care s-a utilizat cardul.  
Atribuirea valorii : acest șir de octeți este completat în mod ciclic cu 
înregistrări din  CardActivityDailyRecord . La prima utilizare, stocarea 
începe la primul octet din șir. Toate înregistr ările noi se adaug ă la 
sfârșitul înregistr ării anterioare. Atunci când șirul devine complet, 
stocarea se reia de la primul octet din șir, indiferent dac ă există o 
întrerupere în interiorul unui element de date. Înainte de a plasa în șir 
noi date privind activitatea (prin extinderea  activityDailyRecord  curent 
sau prin introducerea unui nou  activityDailyRecord ) care să înlocuiasc ă 
datele mai vechi privind activitatea,  activityPointerOldestDayRecord  
trebuie actualizat pentru a indica noul loc al celei mai vechi înregistr ări 
complete aferente unei zile, iar  activityPreviousRecordLength  pentru 
această (nouă) cea mai veche înregistrare zilnic ă completă trebuie 
resetat la 0.  
2.18.  CardDrivingLicenceInformation  
Informații, stocate pe un card de conduc ător auto, privind datele 
permisului de conducere al titularului cardului (cerin țele 259 și 284 
din anexa 1C).
  
drivingLicenceIssuingAuthority  este autoritatea responsabil ă pentru 
eliberarea permisului de conducere.  
drivingLicenceIssuingNation  este na ționalitatea autorit ății care a 
eliberat permisul de conducere.  
drivingLicenceNumber  este numărul permisului de conducere.  
▼M1 
2.19.  CardEventData  
Generația 1:  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind evenimentele asociate cu titularul cardului (cerin țele 
260 și 318 din anexa IC).
  
CardEventData  este o secven ță, în ordine cresc ătoare a valorilor Event ­
FaultType, a cardEventRecords (cu excep ția înregistr ărilor privind tenta ­
tivele de înc ălcare a securit ății, care sunt cuprinse în ultimul set al 
secvenței). 
cardEventRecords  este un set de înregistr ări de evenimente pentru un 
anumit tip de evenimente (sau categorie pentru evenimentele care țin de 
tentativele de înc ălcare a securit ății). 
Generația 2: ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 105  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind evenimentele asociate cu titularul cardului (cerin țele 
285 și 341 din anexa IC).
  
CardEventData  este o secven ță, în ordine cresc ătoare a valorilor Event ­
FaultType, a cardEventRecords (cu excep ția înregistr ărilor privind tenta ­
tivele de înc ălcare a securit ății, care sunt cuprinse în ultimul set al 
secvenței). 
cardEventRecords  este un set de înregistr ări de evenimente pentru un 
anumit tip de evenimente (sau categorie pentru evenimentele care țin de 
tentativele de înc ălcare a securit ății). 
▼B 
2.20.  CardEventRecord  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind un eveniment asociat cu titularul cardului (cerin țele 
261, 286, 318 și 341 din anexa 1C).
  
eventType  este tipul de eveniment.  
eventBeginTime  este data și ora la care a început evenimentul.  
eventEndTime  este data și ora la care s-a încheiat evenimentul.  
eventVehicleRegistration  reprezintă VRN și statul membru de înmatri ­
culare ale vehiculului în care a avut loc evenimentul.  
2.21.  CardFaultData  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind anomaliile asociate cu titularul cardului (cerin țele 263, 
288, 318 și 341 din anexa 1C).
  
CardFaultData  este o secven ță care cuprinde un set de înregistr ări ale 
anomaliilor aparaturii de înregistrare, urmat de un set de înregistr ări 
privind anomaliile cardului.  
cardFaultRecords  este un set de înregistr ări de anomalii dintr-o anumit ă 
categorie de anomalii (aparatur ă de înregistrare sau card).  
2.22.  CardFaultRecord  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind o anomalie asociat ă cu titularul cardului (cerin țele 264, 
289, 318 și 341 din anexa 1C).
  
faultType  este tipul de anomalie.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 106  
faultBeginTime  este data și ora la care a început anomalia.  
faultEndTime  este data și ora la care s-a încheiat anomalia.  
faultVehicleRegistration  reprezintă VRN și statul membru de înmatri ­
culare ale vehiculului în care s-a produs anomalia.  
2.23.  CardIccIdentification  
Informații, stocate pe un card, privind identificarea cardului cu circuite 
integrate (IC) (cerin ța 248 din anexa 1C).
  
clockStop  este modul Clockstop definit în apendicele 2.  
cardExtendedSerialNumber  este numărul de serie unic al cardului cu 
IC, așa cum este specificat de tipul de date  ExtendedSerialNumber . 
cardApprovalNumber  este numărul omolog ării de tip a cardului.  
CardPersonaliserID  este ID-ul de personalizare a cardului codat ca  
ManufacturerCode . 
embedderIcAssemblerId  oferă informații despre integratorul/asamblorul 
IC. 
icIdentifier  este identificatorul circuitului integrat de pe card și al produ­
cătorului circuitului integrat a șa cum este definit în standardul ISO/IEC 
7816-6.  
2.24.  CardIdentification  
Informații, stocate pe un card, referitoare la identificarea cardului 
(cerințele 255, 280, 310, 333, 359, 365, 371 și 377 din anexa 1C).
  
cardIssuingMemberState  este codul statului membru care elibereaz ă 
cardul.  
cardNumber  este numărul de card al cardului.  
cardIssuingAuthorityName  este denumirea autorit ății care a eliberat 
cardul.  
cardIssueDate  este data eliber ării cardului pentru titularul actual.  
cardValidityBegin  este data ini țială de la care este valabil cardul.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 107  
cardExpiryDate  este data la care expir ă valabilitatea cardului.  
2.25.  CardMACertificate  
Generația 2:  
Certificatul cheii publice a cardului pentru autentificarea reciproc ă cu o 
VU. Structura acestui certificat este specificat ă în apendicele 11.
  
2.26.  CardNumber  
Un număr de card conform defini ției g).
  
driverIdentification  este identificarea unic ă a unui conduc ător auto într- 
un stat membru.  
ownerIdentification  este identificarea unic ă a unei societ ăți, a unui 
atelier sau a unui organism de control în cadrul unui stat membru.  
cardConsecutiveIndex  este indicele secven țial al cardului.  
cardReplacementIndex  este indicele de înlocuire a cardului.  
cardRenewalIndex  este indicele de reînnoire a cardului.  
Prima secven ță din selecție este adecvat ă pentru a coda un num ăr de card 
de conduc ător auto, a doua secven ță din selecție este adecvat ă pentru a 
coda numărul de card de atelier, num ărul de card de control și, respectiv, 
numărul de card de societate.  
2.27.  CardPlaceDailyWorkPeriod  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind locurile în care încep și/sau se încheie zilele de lucru 
(cerințele 272, 297, 325 și 348 din anexa 1C).
  
placePointerNewestRecord  este indicele ultimei înregistr ări actualizate 
a locului.  
Atribuirea valorii : număr care corespunde num ărătorului înregistr ării 
privind locul, începând de la ‘0’ pentru prima ocuren ță a înregistr ărilor 
privind locurile în structur ă. 
placeRecords  este setul de înregistr ări care con țin informa ții privind 
locurile introduse.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 108  
2.28.  CardPrivateKey  
Generația 1:  
Cheia privat ă a unui card.
  
2.29.  CardPublicKey  
Cheia public ă a unui card.
  
▼M1 
2.30.  CardRenewalIndex  
Un indice de reînnoire a cardului [defini ția i)].
  
Atribuirea valorii : (a se vedea capitolul 7 din prezenta anex ă). 
„0” Cardul original.  
Ordinea de cre ștere: „0, …, 9, A, …, Z”  
▼B 
2.31.  CardReplacementIndex  
Un indice de înlocuire a cardului [defini ția j)].
  
Atribuirea valorii : (a se vedea capitolul VII din prezenta anex ă). 
‘0’ Cardul original.  
Ordinea de cre ștere: ‘0, …, 9, A, …, Z’  
2.32.  CardSignCertificate  
Generația 2:  
Certificatul cheii publice a cardului pentru semn ătură. Structura acestui 
certificat este specificat ă în apendicele 11.
  
2.33.  CardSlotNumber  
Cod care face distinc ția între cele dou ă sloturi ale unei unit ăți montate pe 
vehicul.
  
Atribuirea valorii : nu se furnizeaz ă indicații suplimentare.  
2.34.  CardSlotsStatus  
Cod care indic ă tipurile de carduri introduse în cele dou ă sloturi ale 
unității montate pe vehicul.
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 109  
Atribuirea valorii – Octet aliniat : ‘ccccdddd’B  
‘cccc’B Identificarea tipului de card introdus în slotul pentru 
cardul de copilot,  
‘dddd’B Identificarea tipului de card introdus în slotul pentru 
cardul de conduc ător auto,  
cu următoarele coduri de identificare:  
‘0000’B niciun card introdus,  
‘0001’B un card de conduc ător auto introdus,  
‘0010’B un card de atelier introdus,  
‘0011’B un card de control introdus,  
‘0100’B un card de societate introdus.  
2.35.  CardSlotsStatusRecordArray  
Generația 2:  
CardSlotsStatus  și metadatele utilizate în protocolul de desc ărcare.
  
recordType  reprezintă tipul înregistr ării (CardSlotsStatus ). Atribuirea 
valorii : A se vedea  RecordType  
recordSize  este dimensiunea  CardSlotsStatus  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este setul de înregistr ări CardSlotsStatus . 
2.36.  CardStructureVersion  
Cod care indic ă versiunea structurii implementate într-un card de 
tahograf.
  
Atribuirea valorii : ‘aabb’H:  
‘aa’H Indice pentru modific ări ale structurii.  
‘00’H pentru aplica ții de genera ția 1 
‘01’H pentru aplica ții de genera ția 2 
‘bb’H Indice pentru schimb ările privind utilizarea elementelor 
de date definite pentru structura dat ă de octetul cel mai 
semnificativ.  
‘00’H pentru aceast ă versiune a aplica țiilor de 
generația 1 
‘00’H pentru aceast ă versiune a aplica țiilor de 
generația 2 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 110  
2.37.  CardVehicleRecord  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind o perioad ă de utilizare a unui vehicul pe durata unei zile 
calendaristice (cerin țele 269, 294, 322 și 345 din anexa 1C).  
Generația 1:
  
vehicleOdometerBegin  este valoarea indicat ă de contorul de parcurs al 
vehiculului la începutul perioadei de utilizare a vehiculului.  
vehicleOdometerEnd  este valoarea indicat ă de odometrul vehiculului la 
sfârșitul perioadei de utilizare a vehiculului.  
vehicleFirstUse  reprezintă data și ora la care începe perioada de utilizare 
a vehiculului.  
vehicleLastUse  este data și ora la care se încheie perioada de utilizare a 
vehiculului.  
vehicleRegistration  reprezintă VRN și statul membru de înmatriculare a 
vehiculului.  
vuDataBlockCounter  este valoarea  VuDataBlockCounter  la ultima 
extragere de date din perioada de utilizare a vehiculului.  
Generația 2:
  
În plus față de genera ția 1, se utilizeaz ă următorul element de date:  
VehicleIdentificationNumber  este numărul de identificare a vehiculului 
care se refer ă la vehicul în ansamblul s ău. 
2.38.  CardVehiclesUsed  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind vehiculele utilizate de titularul cardului (cerin țele 270, 
295, 323 și 346 din anexa 1C).
  
vehiclePointerNewestRecord  este indicele ultimei înregistr ări actua­
lizate a vehiculului.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 111  
Atribuirea valorii : număr care corespunde num ărătorului înregistr ării 
privind vehiculul, începând de la ‘0’ pentru prima ocuren ță a înregis­
trărilor privind vehiculele în structur ă. 
cardVehicleRecords  este setul de înregistr ări care con țin informa ții 
privind vehiculele utilizate.  
2.39.  CardVehicleUnitRecord  
Generația 2:  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind o unitate montat ă pe vehicul care a fost utilizat ă 
(cerințele 303 și 351 din anexa 1C).
  
timeStamp  este începutul perioadei de utilizare a unit ății montate pe 
vehicul (și anume, prima introducere a cardului în unitatea montat ă pe 
vehicul pentru perioada respectiv ă). 
manufacturerCode  identifică producătorul unității montate pe vehicul.  
deviceID  identifică tipul unității montate pe vehicul a unui produc ător. 
Valoarea este specific ă producătorului.  
vuSoftwareVersion  este num ărul versiunii software-ului instalat pe 
unitatea montat ă pe vehicul.  
2.40.  CardVehicleUnitsUsed  
Generația 2:  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind unit ățile montate pe vehicul utilizate de titularul cardului 
(cerințele 306 și 352 din anexa 1C).
  
vehicleUnitPointerNewestRecord  este indicele ultimei înregistr ări 
actualizate privind unitatea montat ă pe vehicul.  
Atribuirea valorii : număr care corespunde num ărătorului înregistr ării 
privind unitatea montat ă pe vehicul, începând de la ‘0’ pentru prima 
ocurență a înregistr ărilor privind unit ățile montate pe vehicul în 
structură. 
cardVehicleUnitRecords  este setul de înregistr ări care con țin informa ții 
privind unit ățile montate pe vehicul utilizate.  
2.41.  Certificat  
Certificatul unei chei publice emise de o autoritate de certificare.  
Generația 1:
 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 112  
Atribuirea valorii : semnătură digitală cu recuperarea par țială a Certifi­
cateContent  conform apendicelui 11 „Mecanisme de securitate comune”: 
Semnătura (128 de octe ți) || Restul cheii publice (58 de octe ți) || Iden­
tificatorul autorit ății de certificare (8 octe ți). 
Generația 2:
  
Atribuirea valorii: a se vedea apendicele 11.  
2.42.  CertificateContent  
Generația 1:  
Conținutul (în clar) al certificatului unei chei publice conform apen ­
dicelui 11 „Mecanisme de securitate comune”.
  
certificateProfileIdentifier  este versiunea certificatului corespunz ător. 
Atribuirea valorii : ‘01h’pentru aceast ă versiune.  
certificationAuthorityReference  identifică autoritatea de certificare care 
a emis certificatul. De asemenea, identific ă cheia public ă a autorității de 
certificare în cauz ă. 
certificateHolderAuthorisation  identifică drepturile de ținătorului certi ­
ficatului.  
certificateEndOfValidity  este data la care certificatul expir ă din punct 
de vedere administrativ.  
certificateHolderReference  identifică deținătorul certificatului. De 
asemenea, identific ă cheia public ă a acestuia.  
publicKey  este cheia public ă care este certificat ă prin intermediul certi ­
ficatului respectiv.  
2.43.  CertificateHolderAuthorisation  
Identificarea drepturilor unui de ținător de certificat.
  
Generația 1:  
tachographApplicationID  este identificatorul de aplica ție pentru 
aplicația tahografic ă. 
Atribuirea valorii : ‘FFh’ ‘54h’ ‘41h’ ‘43h’ ‘48h’ ‘4Fh’. Acest AID este 
un identificator exclusiv de aplica ție neînregistrat conform standardului 
ISO/IEC 7816-5.  
equipmentType  este identificarea tipului de echipament pentru care se 
emite certificatul.  
Atribuirea valorii : în conformitate cu tipul de date  EquipmentType . 0 
dacă certificatul este emis de unul din statele membre.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 113  
Generația 2:  
tachographApplicationID  reprezintă cei mai importan ți 6 octeți din 
identificatorul de aplica ție pentru cardurile de tahograf de genera ția 2 
(AID). AID pentru aplica ția de card de tahograf este specificat în 
capitolul 6.2.  
Atribuirea valorii:  ‘FF 53 4D 52 44 54’.  
equipmentType  este identificarea tipului de echipament specificat 
pentru genera ția 2, pentru care se emite certificatul.  
Atribuirea valorii : în conformitate cu tipul de date  EquipmentType . 
2.44.  CertificateRequestID  
Cod unic de identificare a unei cereri de certificat. Se poate utiliza și ca 
identificator al cheii publice a unit ății montate pe vehicul dac ă numărul 
de serie al unit ății montate pe vehicul c ăreia îi este destinat ă cheia nu 
este cunoscut în momentul gener ării certificatului.
  
requestSerialNumber  este un num ăr de serie aferent cererii de certi ­
ficat, fiind un num ăr unic pentru produc ător și pentru luna definit ă mai 
jos. 
requestMonthYear  este identificarea lunii și a anului în care s-a depus 
cererea de certificat.  
Atribuirea valorii : codarea BCD a lunii (dou ă cifre) și a anului 
(ultimele dou ă cifre).  
crIdentifier : este un identificator care are rolul de a face distinc ția între 
o cerere de certificat și un număr de serie lung.  
Atribuirea valorii : ‘FFh’.  
manufacturerCode : este codul numeric al produc ătorului care solicit ă 
certificatul.  
2.45.  CertificationAuthorityKID  
Identificatorul cheii publice a unei autorit ăți de certificare (un stat 
membru sau Autoritatea european ă de certificare).
  
nationNumeric  este codul numeric na țional al autorit ății de certificare.  
nationAlpha  este codul alfanumeric na țional al autorit ății de certificare.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 114  
keySerialNumber  este numărul de serie care face distinc ția între dife ­
ritele chei ale autorit ății de certificare dac ă aceste chei se modific ă. 
additionalInfo  este un câmp de doi octe ți pentru cod ări suplimentare 
(specifice autorit ății de certificare).  
caIdentifier  este un identificator care face distinc ția dintre un identi ­
ficator al cheii autorit ății de certificare și identificatorii altor chei.  
Atribuirea valorii : ‘01h’.  
2.46.  CompanyActivityData  
Informații, stocate pe un card de societate, privind activit ățile efectuate 
cu cardul (cerin țele 373 și 379 din anexa 1C).
  
companyPointerNewestRecord  este indicele ultimei  companyActivity ­
Record  actualizate.  
Atribuirea valorii : număr care corespunde num ărătorului înregistr ării 
privind activitatea societ ății, începând cu ‘0’ pentru prima ocuren ță a 
unei înregistr ări privind activitatea societ ății în structur ă. 
companyActivityRecords  este setul tuturor înregistr ărilor privind acti ­
vitățile societății. 
companyActivityRecord  este o secven ță de informa ții referitoare la o 
activitate a societ ății. 
companyActivityType  este tipul de activitate a societ ății. 
companyActivityTime  este data și ora activit ății societății. 
cardNumberInformation  este num ărul cardului și statul membru 
emitent al cardului desc ărcat, dacă este cazul.  
vehicleRegistrationInformation  reprezintă VRN și statul membru de 
înmatriculare a vehiculului care au fost desc ărcate, blocate sau deblocate.  
downloadPeriodBegin  și downloadPeriodEnd  reprezint ă perioada 
descărcată din VU, dac ă este cazul.  
2.47.  CompanyActivityType  
Cod care indic ă o activitate desf ășurată de o societate prin utilizarea 
propriului card de societate.
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 115  
2.48.  CompanyCardApplicationIdentification  
Informații, stocate pe un card de societate, privind identificarea aplica ției 
cardului (cerin țele 369 și 375 din anexa 1C).
  
typeOfTachographCardId  precizează tipul de card implementat.  
cardStructureVersion  precizeaz ă versiunea structurii implementate în 
card.  
noOfCompanyActivityRecords  este num ărul de înregistr ări privind 
activitățile societății care pot fi stocate pe card.  
2.49.  CompanyCardHolderIdentification  
Informații, stocate pe un card de societate, privind identificarea titu ­
larului cardului (cerin țele 372 și 378 din anexa 1C).
  
companyName  este denumirea societ ății deținătoare.  
companyAddress  este adresa societ ății deținătoare.  
cardHolderPreferredLanguage  este limba preferat ă de titularul 
cardului.  
2.50.  ControlCardApplicationIdentification  
Informații, stocate pe un card de control, privind identificarea aplica ției 
cardului (cerin țele 357 și 363 din anexa 1C).
  
typeOfTachographCardId  precizează tipul de card implementat.  
cardStructureVersion  precizeaz ă versiunea structurii implementate în 
card.  
noOfControlActivityRecords  este numărul înregistr ărilor privind activi ­
tățile de control care pot fi stocate pe card.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 116  
2.51.  ControlCardControlActivityData  
Informații, stocate pe un card de control, privind activit ățile de control 
efectuate cu cardul (cerin țele 361 și 367 din anexa 1C).
  
controlPointerNewestRecord  este indicele ultimei înregistr ări actua­
lizate privind activit ățile de control.  
Atribuirea valorii : număr care corespunde num ărătorului înregistr ării 
privind activitatea de control, începând cu ‘0’ pentru prima ocuren ță a 
unei înregistr ări privind activitatea de control în structur ă. 
controlActivityRecords  este setul tuturor înregistr ărilor privind activi ­
tățile de control.  
controlActivityRecord  este secven ța de informa ții privind o activitate 
de control.  
controlType  este tipul de control.  
controlTime  este data și ora la care a avut loc controlul.  
controlledCardNumber  reprezintă numărul cardului și statul membru 
emitent al cardului controlat.  
controlledVehicleRegistration  reprezintă VRN și statul membru de 
înmatriculare ale vehiculului în care a avut loc controlul.  
controlDownloadPeriodBegin  și controlDownloadPeriodEnd  
reprezintă perioada desc ărcată. 
2.52.  ControlCardHolderIdentification  
Informații, stocate pe un card de control, privind identificarea titularului 
cardului (cerin țele 360 și 366 din anexa 1C).
  
controlBodyName  este denumirea organismului de control al titularului 
cardului.  
controlBodyAddress  este adresa organismului de control al titularului 
cardului.  
cardHolderName  reprezintă numele și prenumele titularului cardului de 
control.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 117  
cardHolderPreferredLanguage  este limba preferat ă de titularul 
cardului.  
2.53.  ControlType  
Cod care indic ă activitățile desfășurate în timpul unui control. Acest tip 
de date se raporteaz ă la cerințele 126, 274, 299, 327 și 350 din anexa 
1C.
 
Generația 1:  
Atribuirea valorii – Octet aliniat : ‘cvpdxxxx’B (8 bi ți) 
‘c’B desc ărcare de pe card:  
‘0’B: informa țiile de pe card nu sunt desc ărcate în 
timpul acestei activit ăți de control,  
‘1’B: informa țiile de pe card sunt desc ărcate în timpul 
acestei activit ăți de control  
‘v’B desc ărcare din VU:  
‘0’B: informa țiile din VU nu sunt desc ărcate în timpul 
acestei activit ăți de control,  
‘1’B: informa țiile din VU sunt desc ărcate în timpul 
acestei activit ăți de control  
‘p’B imprimare:  
‘0’B: nu s-a imprimat nimic în timpul acestei activit ăți 
de control,  
‘1’B: s-au imprimat informa ții în timpul acestei activit ăți 
de control  
‘d’B afi șaj: 
‘0’B: nu s-a utilizat afi șajul în timpul acestei activit ăți 
de control,  
‘1’B: s-a utilizat afi șajul în timpul acestei activit ăți de 
control  
‘xxxx’B Neutilizat.  
Generația 2:  
Atribuirea valorii – Octet aliniat : ‘cvpdexxx’B (8 bi ți) 
‘c’B desc ărcare de pe card:  
‘0’B: informa țiile de pe card nu sunt desc ărcate în 
timpul acestei activit ăți de control,  
‘1’B: informa țiile de pe card sunt desc ărcate în timpul 
acestei activit ăți de control  
‘v’B desc ărcare din VU:  
‘0’B: informa țiile din VU nu sunt desc ărcate în timpul 
acestei activit ăți de control,  
‘1’B: informa țiile din VU sunt desc ărcate în timpul 
acestei activit ăți de control  
‘p’B imprimare:  
‘0’B: nu s-a imprimat nimic în timpul acestei activit ăți 
de control,  
‘1’B: s-au imprimat informa ții în timpul acestei activit ăți 
de control  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 118  
‘d’B afi șaj: 
‘0’B: nu s-a utilizat afi șajul în timpul acestei activit ăți 
de control,  
‘1’B: s-a utilizat afi șajul în timpul acestei activit ăți de 
control  
‘e’B verificarea etalon ării în trafic:  
‘0’B: parametrii de etalonare nu sunt verifica ți în timpul 
acestei activit ăți de control,  
‘1’B: parametrii de etalonare sunt verifica ți în timpul 
acestei activit ăți de control  
‘xxx’B RFU.  
2.54.  CurrentDateTime  
Data și ora curente, afi șate de aparatul de înregistrare.
  
Atribuirea valorii : nu se furnizeaz ă indicații suplimentare.  
2.55.  CurrentDateTimeRecordArray  
Generația 2:  
Data și ora curente, plus metadatele utilizate în protocolul de desc ărcare.
  
recordType  reprezintă tipul înregistr ării (CurrentDateTime ). Atribuirea 
valorii : A se vedea  RecordType  
recordSize  este dimensiunea  CurrentDateTime  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări ale datei și orei curente.  
2.56.  DailyPresenceCounter  
Contor, stocat pe un card de conduc ător auto sau pe un card de atelier, 
incrementat cu o unitate pentru fiecare zi calendaristic ă în care cardul a 
fost introdus într-o VU. Acest tip de date se raporteaz ă la cerințele 266, 
299, 320 și 343 din anexa 1C.
  
Atribuirea valorii : număr consecutiv cu valoare maxim ă = 9 999, 
începând apoi din nou de la 0. În momentul primei emiteri a cardului, 
numărul este setat la 0.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 119  
2.57.  Datef  
Data exprimat ă într-un format numeric care poate fi imprimat imediat.
  
Atribuirea valorii:  
yyyy Anul  
mm Luna  
dd Ziua  
‘00000000’H reprezint ă în mod explicit „nicio dat ă”. 
2.58.  DateOfDayDownloaded  
Generația 2:  
Data și ora descărcării.
 
Atribuirea valorii : nu se furnizeaz ă indicații suplimentare.  
2.59.  DateOfDayDownloadedRecordArray  
Generația 2:  
Data și ora desc ărcării plus metadate, astfel cum se utilizeaz ă în 
protocolul de desc ărcare.
  
recordType  reprezintă tipul înregistr ării (DateOfDayDownloaded ). Atri­
buirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  CurrentDateTime  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este setul de înregistr ări ale datei și orei de desc ărcare.  
2.60.  Distance  
O distanță parcursă (rezultatul calcul ării diferen ței dintre dou ă valori 
afișate de odometrul unui vehicul, în kilometri).
  
Atribuirea valorii : Binar fără semn. Valoarea în kilometri în intervalul 
operațional 0 – 9 999 km.  
2.61.  DriverCardApplicationIdentification  
Informații, stocate pe un card de conduc ător auto, privind identificarea 
aplicației cardului (cerin țele 253 și 278 din anexa 1C).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 120  
Generația 1:
  
typeOfTachographCardId  precizează tipul de card implementat.  
cardStructureVersion  precizeaz ă versiunea structurii implementate în 
card.  
noOfEventsPerType  reprezintă numărul de evenimente, per tip de 
eveniment, pe care cardul le poate înregistra.  
noOfFaultsPerType  reprezint ă numărul de anomalii, per tip de 
anomalie, pe care cardul le poate înregistra.  
activityStructureLength  indică numărul de octe ți disponibili pentru 
stocarea înregistr ărilor privind activit ățile. 
noOfCardVehicleRecords  este num ărul de înregistr ări privind vehi ­
culele pe care cardul le poate con ține. 
noOfCardPlaceRecords  este numărul de locuri pe care cardul le poate 
înregistra.  
Generația 2: 
▼M1
 
În plus față de genera ția 1, se utilizeaz ă următoarele elemente de date:  
noOfGNSSADRecords  este num ărul de înregistr ări GNSS privind 
timpul de conducere acumulat care pot fi stocate pe card.  
noOfSpecificConditionRecords  este num ărul de înregistr ări privind 
condițiile specifice care pot fi stocate pe card.  
noOfCardVehicleUnitRecords  este num ărul de înregistr ări privind 
unitățile montate pe vehicul utilizate care pot fi stocate pe card.  
▼B 
2.62.  DriverCardHolderIdentification  
Informații, stocate pe un card de conduc ător auto, privind identificarea 
titularului cardului (cerin țele 256 și 281 din anexa 1C).
  
cardHolderName  reprezintă numele și prenumele titularului cardului de 
conducător auto.  
cardHolderBirthDate  este data de na ștere a titularului cardului de 
conducător auto.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 121  
cardHolderPreferredLanguage  este limba preferat ă de titularul 
cardului.  
▼M1 
2.63.  Rezervat pentru o utilizare viitoare  
▼B 
2.64.  EGFCertificate  
Generația 2:  
Certificatul cheii publice a echipamentului GNSS extern pentru autenti ­
ficarea reciproc ă cu o VU. Structura acestui certificat este specificat ă în 
apendicele 11.
  
2.65.  EmbedderIcAssemblerId  
Oferă informații referitoare la integratorul IC.
  
countryCode  este codul de țară format din 2 litere al integratorului 
modulului conform ISO 3166 . 
moduleEmbedder  identifică integratorul modulului.  
manufacturerInformation  pentru uzul intern al produc ătorului.  
2.66.  EntryTypeDailyWorkPeriod  
Cod care face distinc ția între începutul și sfârșitul unei introduceri de 
date privind locul unde s-a desf ășurat o zi de lucru și condițiile în care s- 
a realizat introducerea de date respectiv ă. 
Generația 1
 
Atribuirea valorii : conform standardului ISO/IEC 8824-1.  
Generația 2
 
Atribuirea valorii : conform standardului ISO/IEC 8824-1.  
2.67.  EquipmentType  
Cod care face distinc ția între diferite tipuri de aparatur ă pentru aplica ția 
tahografică.
 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 122  
Generația 1:
  
Atribuirea valorii : conform standardului ISO/IEC 8824-1.  
Valoarea 0 este rezervat ă pentru a desemna un stat membru sau Europa 
în câmpul CHA al certificatelor.  
Generația 2: 
▼M1 
Sunt utilizate acelea și valori ca în genera ția 1, cu urm ătoarele comple ­
tări:
 
Nota 1:  valorile aferente genera ției 2 pentru pl ăcuță, pentru adaptor și 
pentru conexiunea GNSS extern ă, precum și valorile aferente genera ției 
1 pentru unitatea montat ă pe vehicul și pentru senzorul de mi șcare pot fi 
utilizate în SealRecord, dac ă este cazul.  
Nota 2:  În câmpul CardHolderAuthorisation (CHA) al unui certificat de 
generația 2, valorile (1), (2) și (6) trebuie interpretate ca indicând un 
certificat pentru autentificare reciproc ă pentru respectivul tip de echi ­
pament. Pentru indicarea certificatului respectiv în vederea cre ării unei 
semnături digitale, trebuie utilizate valorile (17), (18) sau (19).  
▼B 
2.68.  EuropeanPublicKey  
Generația 1:  
Cheia public ă europeană.
 
2.69.  EventFaultRecordPurpose  
Cod care explic ă de ce s-a înregistrat un anumit eveniment sau o 
anumită anomalie.
  
Atribuirea valorii:  ▼B
02016R0799 — RO — 26.02.2020 — 002.001 — 123 
unul/una dintre cele mai recente (sau ultimele) 10 evenimente sau anomalii 
evenimentul cel mai de durat ă pentru una din ultimele 10 zile de producere a unui 
eveniment 
unul dintre cele mai de durat ă 5 evenimente din ultimele 365 de zile 
ultimul eveniment pentru una din ultimele 10 zile de producere a unui eveniment 
cel mai grav eveniment pentru una din ultimele 10 zile de producere a unui 
eveniment 
unul dintre cele mai grave 5 evenimente din ultimele 365 de zile 
primul eveniment sau prima anomalie care a survenit dup ă ultima etalonare 
un eveniment activ/în curs sau o anomalie activ ă/în curs 
RFU 
specific produc ătorului  
2.70. EventFaultType 
Cod prin care se caracterizeaz ă un eveniment sau o anomalie.
  
Atribuirea valorii:  
Generația 1:
  
Evenimente generale, 
Nu sunt disponibile detalii suplimentare, 
Introducerea unui card nevalabil, 
Conflict de carduri, 
Suprapunerea timpului, 
Conducere f ără un card adecvat, 
Introducerea cardului în timpul conducerii, 
Ultima sesiune a cardului nu a fost încheiat ă corect, 
Depășire a limitei de vitez ă, 
Întrerupere a aliment ării cu energie electric ă, 
Eroare privind datele de la senzorul de mi șcare, 
Conflict privind deplasarea vehiculului, 
RFU,
  
Evenimente care țin de tentativele de înc ălcare a securit ății privind unitatea montat ă pe 
vehicul, 
Nu sunt disponibile detalii suplimentare, 
Eroare de autentificare a senzorului de mi șcare, 
Eroare de autentificare a cardului de tahograf, 
Înlocuirea neautorizat ă a senzorului de mi șcare, 
Eroare de integritate care afecteaz ă introducerea datelor pe card, 
Eroare de integritate a datelor stocate privind utilizatorul, 
Eroare de transfer intern de date, 
Deschidere neautorizat ă a carcasei, 
Sabotarea hardware-ului, 
RFU,
  
Evenimente care țin de tentativele de înc ălcare a securit ății privind senzorul, 
Nu sunt disponibile detalii suplimentare, 
Eroare de autentificare, 
Eroare de integritate a datelor stocate, 
Eroare de transfer intern de date, 
Deschidere neautorizat ă a carcasei, 
Sabotarea hardware-ului, 
RFU,
  
Anomalii ale aparaturii de înregistrare, 
Nu sunt disponibile detalii suplimentare, 
Anomalie intern ă a VU, 
Anomalie a imprimantei, 
Anomalie a afi șajului, 
Anomalie la desc ărcare, 
Anomalie a senzorului, 
RFU,  ▼B
02016R0799 — RO — 26.02.2020 — 002.001 — 124 
Anomalii ale cardului, 
Nu sunt disponibile detalii suplimentare, 
RFU,
  
RFU,
  
Specific produc ătorului.  
▼M1
Generația 2:
  
Evenimente generale, 
Nu sunt disponibile detalii suplimentare, 
Introducerea unui card nevalabil, 
Conflict de carduri, 
Suprapunerea timpului, 
Conducere f ără un card adecvat, 
Introducerea cardului în timpul conducerii, 
Ultima sesiune a cardului nu a fost încheiat ă corect, 
Depășire a limitei de vitez ă, 
Întrerupere a aliment ării cu energie electric ă, 
Eroare privind datele de mi șcare, 
Conflict privind deplasarea vehiculului, 
Conflict or ă (GNSS fa ță de ceasul intern al VU), 
Eroare de comunicare cu echipamentul de comunicare la distan ță, 
Absența informațiilor de pozi ționare de la receptorul GNSS, 
Eroare de comunicare cu echipamentul GNSS extern, 
RFU,
  
Evenimente care țin de tentativele de înc ălcare a securit ății privind unitatea montat ă pe 
vehicul, 
Nu sunt disponibile detalii suplimentare, 
Eroare de autentificare a senzorului de mi șcare, 
Eroare de autentificare a cardului de tahograf, 
Înlocuirea neautorizat ă a senzorului de mi șcare, 
Eroare de integritate care afecteaz ă introducerea datelor pe card, 
Eroare de integritate a datelor stocate privind utilizatorul, 
Eroare de transfer intern de date, 
Deschidere neautorizat ă a carcasei, 
Sabotarea hardware-ului, 
Detectare a manipul ării frauduloase a GNSS, 
Eroare de autentificare a echipamentului GNSS extern, 
Certificatul echipamentului GNSS extern a expirat, 
de la ‘1C’H pân ă la ‘1F’H RFU,
  
Evenimente care țin de tentativele de înc ălcare a securit ății privind senzorul, 
Nu sunt disponibile detalii suplimentare, 
Eroare de autentificare, 
Eroare de integritate a datelor stocate, 
Eroare de transfer intern de date, 
Deschidere neautorizat ă a carcasei, 
Sabotarea hardware-ului, 
de la ‘26’H pân ă la ‘2F’H RFU,  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 125
  
Anomalii ale aparaturii de înregistrare, 
Nu sunt disponibile detalii suplimentare, 
Anomalie intern ă a VU, 
Anomalie a imprimantei, 
Anomalie a afi șajului, 
Anomalie la desc ărcare, 
Anomalie a senzorului, 
Receptor GNSS intern, 
Echipament GNSS extern, 
Echipament de comunicare la distan ță, 
Interfață ITS, 
de la ‘3A’H pân ă la ‘3F’H RFU,
  
Anomalii ale cardului, 
Nu sunt disponibile detalii suplimentare, 
de la ‘41’H pân ă la ‘4F’H RFU,
  
RFU,
  
Specific produc ătorului.  
2.71.  ExtendedSealIdentifier  
Generația 2:  
Identificatorul lung al sigiliului identific ă în mod unic un sigiliu (cerin ța 
401 din anexa IC).
  
manufacturerCode  este codul produc ătorului sigiliului.  
sealIdentifier  este un identificator al sigiliului care este unic pentru 
producător. 
▼B 
2.72.  ExtendedSerialNumber  
Identificare unic ă a unui echipament. Poate fi utilizat și ca identificator 
al cheii publice a unui echipament.  
Generația 1:
  
serialNumber  este num ărul de serie al echipamentului, unic pentru 
producător, tipul echipamentului, luna și anul descrise în continuare.  
monthYear  este identificarea lunii și a anului de produc ție (sau de 
atribuire a num ărului de serie).  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 126  
Atribuirea valorii : codarea BCD a lunii (dou ă cifre) și a anului 
(ultimele dou ă cifre).  
type este un identificator al tipului de echipament.  
Atribuirea valorii : specifică producătorului, cu valoarea rezervat ă 
‘FFh’.  
manufacturerCode : este codul numeric care identific ă un produc ător de 
echipamente omologate de tip.  
Generația 2:
  
serialNumber  a se vedea genera ția 1.  
monthYear  a se vedea genera ția 1.  
type indică tipul de echipament.  
manufacturerCode : a se vedea genera ția 1.  
2.73.  FullCardNumber  
Cod prin care se identific ă complet un card de tahograf.
  
cardType  este tipul cardului de tahograf.  
cardIssuingMemberState  este codul statului membru care a emis 
cardul.  
cardNumber  este numărul cardului.  
2.74.  FullCardNumberAndGeneration  
Generația 2:  
Cod prin care se identific ă complet un card de tahograf și generația sa.
  
fullcardNumber  identifică cardul de tahograf.  
generation  indică generația cardului de tahograf utilizat.  
2.75.  Generation  
Generația 2:  
Indică generația tahografului utilizat.
  
Atribuirea valorii:  
‘00’H RFU  
‘01’H Genera ția 1 
‘02’H Genera ția 2 
‘03’H .. ‘FF’H RFU  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 127  
2.76.  GeoCoordinates  
Generația 2:  
Coordonatele geografice sunt codate sub form ă de numere întregi. 
Aceste numere întregi sunt multipli ai cod ării ±DDMM.M pentru lati ­
tudine și ±DDDMM.M pentru longitudine. Aici ±DD, respectiv ± DDD, 
denotă gradele, iar MM.M minutele.
  
latitude  este codat ă ca multiplu (factor 10) al reprezent ării ±DDMM.M.  
longitude  este codat ă ca multiplu (factor 10) al reprezent ării 
±DDDMM.M.  
2.77.  GNSSAccuracy  
Generația 2:  
Precizia datelor de pozi ționare GNSS [defini ția eee)]. Aceast ă precizie 
este codată ca număr întreg și este un multiplu (factor 10) al valorii X.Y 
furnizate de propozi ția GSA NMEA.
  
▼M1 
2.78.  GNSSAccumulatedDriving  
Generația 2:  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind pozi ția GNSS a vehiculului dac ă timpul de conducere 
acumulat ajunge la un multiplu de trei ore (cerin țele 306 și 354 din 
anexa IC).
  
ggnssADPointerNewestRecord  este indicele ultimei înregistr ări actua­
lizate GNSS a timpului de conducere acumulat.  
Atribuirea valorii  este numărul care corespunde num ărătorului înregis ­
trării GNSS privind conducerea acumulat ă, începând de la '0' pentru 
prima ocuren ță a înregistr ării GNSS privind conducerea acumulat ă în 
structură. 
gnssAccumulatedDrivingRecords  este setul de înregistr ări care con țin 
data și ora la care timpul de conducere acumulat atinge un multiplu de 
trei ore și informații privind pozi ția vehiculului.  
2.79.  GNSSAccumulatedDrivingRecord  
Generația 2: ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 128  
Informații, stocate pe un card de conduc ător auto sau pe un card de 
atelier, privind pozi ția GNSS a vehiculului dac ă timpul de conducere 
acumulat ajunge la un multiplu de trei ore (cerin țele 305 și 353 din 
anexa IC)
  
timeStamp  este data și ora la care timpul de conducere acumulat atinge 
un multiplu de trei ore.  
gnssPlaceRecord  conține informa ții referitoare la pozi ția vehiculului.  
vehicleOdometerValue  este valoarea indicat ă de odometru în momentul 
în care timpul de conducere acumulat atinge un multiplu de trei ore.  
▼B 
2.80.  GNSSPlaceRecord  
Generația 2:  
Informații referitoare la pozi ția GNSS a vehiculului (cerin țele 108, 109, 
110, 296, 305, 347 și 353 din anexa 1C).
  
timeStamp  este data și ora la care a fost stabilit ă poziția GNSS a 
vehiculului.  
gnssAccuracy  este precizia datelor de pozi ționare GNSS.  
geoCoordinates  este locul înregistrat folosind GNSS.  
2.81.  HighResOdometer  
Valoarea indicat ă de odometrul vehiculului: distan ța cumulată parcursă 
de vehicul în timpul exploat ării acestuia.
  
Atribuirea valorii : binar fără semn. Valoare în 1/200 km cuprins ă în 
intervalul opera țional 0 – 21 055 406 km.  
2.82.  HighResTripDistance  
O distanță parcursă pe întreaga durat ă sau într-o parte a cursei.
  
Atribuirea valorii : binar fără semn. Valoare în 1/200 km cuprins ă în 
intervalul opera țional 0 – 21 055 406 km.  
2.83.  HolderName  
Numele și prenumele titularului cardului.
  
holderSurname  este numele (numele de familie) al titularului. Acest 
nume de familie nu cuprinde titluri.  
Atribuirea valorii : dacă un card nu este personal,  holderSurname  
conține acelea și informații ca și companyName , workshopName  sau  
controlBodyName . ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 129  
holderFirstNames  reprezintă prenumele și inițialele titularului.  
2.84.  InternalGNSSReceiver  
Generația 2:  
Informații care specific ă dacă receptorul GNSS este intern sau extern 
unității montate pe vehicul.  True  înseamnă că receptorul GNSS este o 
parte intern ă a VU.  False  înseamnă că receptorul GNSS este extern.
  
2.85.  K-ConstantOfRecordingEquipment  
Constanta aparaturii de înregistrare [defini ția (m)].
  
Atribuirea valorii : impulsuri pe kilometru într-un interval opera țional 
de la 0 la 64 255 impulsuri/km.  
▼M1 
2.86.  KeyIdentifier  
Un identificator unic al unei chei publice utilizat pentru a identifica și a 
selecta cheia. Acesta identific ă și titularul cheii.
  
Prima opțiune este adecvat ă pentru a identifica cheia public ă a unei 
unități montate pe vehicul, a unui card de tahograf sau a unui echi ­
pament GNSS extern.  
A doua op țiune este adecvat ă pentru a identifica cheia public ă a unei 
unități montate pe vehicul (în cazurile în care num ărul de serie al unit ății 
montate pe vehicul nu poate fi cunoscut în momentul gener ării certifi­
catului).  
A treia opțiune este adecvat ă pentru a identifica cheia public ă a unui stat 
membru.  
▼B 
2.87.  KMWCKey  
Generația 2:  
Cheia AES și versiunea cheii care îi este asociat ă, utilizată pentru 
asocierea VU – senzor de mi șcare. Pentru detalii, a se vedea apen ­
dicele 11.
  
kMWCKey  este lungimea cheii AES concatenate cu cheia care este 
folosită pentru asocierea VU – senzor de mi șcare.  
keyVersion  reprezintă versiunea cheii AES.  
2.88.  Language  
Codul de identificare a unei limbi.
  
Atribuirea valorii : O codare de dou ă litere minuscule conform stan ­
dardului ISO 639.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 130  
2.89.  LastCardDownload  
Data și ora, stocate pe un card de conduc ător auto, la care s-a efectuat 
ultima desc ărcare a informa țiilor de pe card (în alte scopuri decât în 
vederea unui control)(cerin țele 257 și 282 din anexa 1C). Aceast ă dată 
poate fi actualizat ă de o VU sau de orice cititor de card.
  
Atribuirea valorii : nu se furnizeaz ă indicații suplimentare.  
2.90.  LinkCertificate  
Generația 2:  
Certificatul de leg ătură între perechi de chei  European Root CA .
 
2.91.  L-TyreCircumference  
Circumferin ța efectivă a roților [defini ția u)].
  
Atribuirea valorii : binar fără semn, valoare în 1/8 mm cuprins ă în 
intervalul opera țional 0 – 8 031 mm.  
▼M1 
2.92.  MAC  
Generația 2:  
O sumă de verificare criptografic ă cu lungimea de 8, 12 sau 16 octe ți, 
care corespunde suitelor cifru specificate în apendicele 11.
  
▼B 
2.93.  ManualInputFlag  
Cod care specific ă dacă un titular de card a introdus manual activit ățile 
conducătorului auto la introducerea cardului sau nu (cerin ța 081 din 
anexa 1B și cerința 102 din anexa 1C).
  
Atribuirea valorii : nu se furnizeaz ă indicații suplimentare.  
2.94.  ManufacturerCode  
Cod de identificare al unui produc ător de echipamente omologate de tip.
  
Laboratorul responsabil cu efectuarea testelor de interoperabilitate 
menține și publică lista codurilor de produc ător pe site-ul s ău web 
(cerința 454 din anexa 1C).  
ManufacturerCodes  se alocă provizoriu produc ătorilor de echipamente 
tahografice în urma depunerii unei cereri la laboratorul responsabil cu 
efectuarea testelor de interoperabilitate.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 131  
2.95.  ManufacturerSpecificEventFaultData  
Generația 2:  
Codurile de eroare specifice produc ătorului simplific ă analiza erorilor și 
întreținerea unit ăților montate pe vehicule.
  
manufacturerCode  identifică producătorul unității montate pe vehicul.  
manufacturerSpecificErrorCode  este un cod de eroare specific produ ­
cătorului.  
2.96.  MemberStateCertificate  
Certificatul unei chei publice a unui stat membru, eliberat de autoritatea 
europeană de certificare.
  
2.97.  MemberStateCertificateRecordArray  
Generația 2:  
Certificatul statului membru plus metadatele utilizate în protocolul de 
descărcare.
  
recordType  reprezintă tipul înregistr ării (MemberStateCertificate ). Atri­
buirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  MemberStateCertificate  în octeți. 
noOfRecords  este num ărul de înregistr ări cuprinse în setul  records . 
Valoarea se seteaz ă la 1 deoarece certificatele pot avea diferite lungimi.  
records  este setul de certificate ale statelor membre.  
2.98.  MemberStatePublicKey  
Generația 1:  
Cheia public ă a unui stat membru.
  
2.99.  Name  
Un nume.
  
codePage  indică un set de caractere definit în capitolul 4,  
name  este un nume codat cu ajutorul setului de caractere precizat.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 132  
2.100.  NationAlpha  
Trimiterea alfabetic ă la o țară se face în conformitate cu semnele 
distinctive utilizate pentru vehicule în traficul interna țional (Conven ția 
ONU de la Viena asupra circula ției rutiere, 1968).
  
Codurile  Nation Alpha  și Numeric  trebuie s ă figureze pe o list ă 
menținută pe site-ul web al laboratorului desemnat s ă efectueze testele 
de interoperabilitate, astfel cum se prevede la cerin ța 440 din anexa 1C.  
2.101.  NationNumeric  
Cod numeric care desemneaz ă o țară.
 
Atribuirea valorii:  a se vedea tipul de date 2.100 ( NationAlpha ). 
Orice modificare sau actualizare a specifica ției Nation Alpha  sau  
Numeric  descrise în paragraful anterior se efectueaz ă numai dup ă ce 
laboratorul desemnat s-a consultat cu produc ătorii unităților de 
tahograf digital și inteligent montate pe vehicule, care de țin omologare 
de tip.  
2.102.  NoOfCalibrationRecords  
Numărul de înregistr ări ale opera țiunilor de etalonare care pot fi stocate 
pe un card de atelier.  
Generația 1:
  
Atribuirea valorii : a se vedea apendicele 2.  
Generația 2:
  
Atribuirea valorii : a se vedea apendicele 2.  
2.103.  NoOfCalibrationsSinceDownload  
Contor care indic ă numărul de opera țiuni de etalonare efectuate cu un 
card de atelier de la ultima desc ărcare a datelor de pe cardul respectiv 
(cerințele 317 și 340 din anexa 1C).
  
Atribuirea valorii : nu se furnizeaz ă indicații suplimentare.  
2.104.  NoOfCardPlaceRecords  
Numărul de înregistr ări privind locurile care pot fi stocate pe un card de 
conducător auto sau de atelier.  
Generația 1:
  
Atribuirea valorii : a se vedea apendicele 2.  
Generația 2:
  
Atribuirea valorii : a se vedea apendicele 2.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 133  
2.105.  NoOfCardVehicleRecords  
Numărul de înregistr ări privind vehiculele utilizate care pot fi stocate pe 
un card de conduc ător auto sau de atelier.
  
Atribuirea valorii : a se vedea apendicele 2.  
2.106.  NoOfCardVehicleUnitRecords  
Generația 2:  
Numărul de înregistr ări privind unit ățile montate pe vehicul utilizate care 
pot fi stocate pe un card de conduc ător auto sau de atelier.
  
Atribuirea valorii : a se vedea apendicele 2.  
2.107.  NoOfCompanyActivityRecords  
Numărul de înregistr ări privind activit ățile societății care pot fi stocate 
pe un card de societate.
  
Atribuirea valorii : a se vedea apendicele 2.  
2.108.  NoOfControlActivityRecords  
Numărul de înregistr ări privind activit ățile de control care pot fi stocate 
pe un card de control.
  
Atribuirea valorii : a se vedea apendicele 2.  
2.109.  NoOfEventsPerType  
Numărul de evenimente, per tip de eveniment, care pot fi stocate pe un 
card.
  
Atribuirea valorii:  a se vedea apendicele 2.  
2.110.  NoOfFaultsPerType  
Numărul de anomalii, per tip de anomalie, care pot fi stocate pe un card.
  
Atribuirea valorii:  a se vedea apendicele 2.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 134  
2.111.  NoOfGNSSADRecords  
Generația 2:  
Numărul de înregistr ări GNSS privind timpul de conducere acumulat 
care pot fi înregistrate pe un card.
  
Atribuirea valorii:  a se vedea apendicele 2.  
▼B 
2.112.  NoOfSpecificConditionRecords  
Generația 2:  
Numărul de înregistr ări privind condi țiile specifice care pot fi înregistrate 
pe un card.
  
Atribuirea valorii:  a se vedea apendicele 2.  
2.113.  OdometerShort  
Valoarea indicat ă de odometrul vehiculului, în form ă prescurtat ă.
 
Atribuirea valorii : binar fără semn. Valoare exprimat ă în kilometri și 
cuprinsă în intervalul opera țional 0 – 9 999 999 km.  
2.114.  OdometerValueMidnight  
Valoarea indicat ă de odometrul vehiculului la miezul nop ții într-o zi dat ă 
(cerința 090 din anexa 1B și cerința 113 din anexa 1C).
  
Atribuirea valorii : nu se furnizeaz ă indicații suplimentare.  
2.115.  OdometerValueMidnightRecordArray  
Generația 2:  
OdometerValueMidnight  plus metadatele utilizate în protocolul de 
descărcare.
  
RecordType  reprezint ă tipul înregistr ării ( OdometerValueMidnight ). 
Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  OdometerValueMidnight  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este setul de înregistr ări OdometerValueMidnight . ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 135  
2.116.  OverspeedNumber  
Numărul evenimentelor de dep ășire a limitei de vitez ă de la ultimul 
control privind dep ășirea limitei de vitez ă.
 
Atribuirea valorii:  0 înseamn ă că nu s-a produs niciun eveniment de 
depășire a limitei de vitez ă de la ultimul control privind dep ășirea limitei 
de viteză, 1 înseamn ă că s-a produs un eveniment de dep ășire a limitei 
de viteză de la ultimul control privind dep ășirea limitei de vitez ă, iar 
…255 înseamn ă că s-au produs 255 sau mai multe evenimente de 
depășire a limitei de vitez ă de la ultimul control privind dep ășirea 
limitei de vitez ă. 
2.117.  PlaceRecord  
Informații privind un loc unde începe sau se încheie o zi de lucru 
(cerințele 108, 271, 296, 324 și 347 din anexa 1C).  
Generația 1:
  
entryTime  reprezintă data și ora aferente introducerii datelor.  
entryTypeDailyWorkPeriod  este tipul de introducere de date.  
dailyWorkPeriodCountry  este țara introdus ă. 
dailyWorkPeriodRegion  este regiunea introdus ă. 
vehicleOdometerValue  este valoarea indicat ă de odometru în momentul 
introducerii datelor privind locul.  
Generația 2:
  
În plus față de genera ția 1, se utilizeaz ă următoarea component ă: 
entryGNSSPlaceRecord  reprezintă locul și ora înregistrate.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 136  
2.118.  PreviousVehicleInfo  
Informații privind vehiculul utilizat anterior de un conduc ător auto atunci 
când acesta î și introduce cardul într-o unitate montat ă pe vehicul (cerin ța 
081 din anexa 1B și cerința 102 din anexa 1C).  
Generația 1:
  
vehicleRegistrationIdentification  reprezintă VRN și statul membru de 
înmatriculare a vehiculului.  
cardWithdrawalTime  reprezintă data și ora la care a fost retras cardul.  
Generația 2:
  
În plus față de genera ția 1, se utilizeaz ă următorul element de date:  
vuGeneration  identifică generația unității montate pe vehicul.  
2.119.  PublicKey  
Generația 1:  
O cheie public ă RSA.
  
rsaKeyModulus  este modulul perechii de chei.  
rsaKeyPublicExponent  este exponentul public al perechii de chei.  
2.120.  RecordType  
Generația 2:  
Trimitere la un tip de înregistrare. Acest tip de date se utilizeaz ă în 
RecordArrays .
 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 137  
Atribuirea valorii:
  
► (1) M1 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, 
RFU, 
Specific produc ătorului.  
2.121.  RegionAlpha  
Trimitere alfabetic ă la o regiune dintr-o anumit ă țară.
 
Generația 1:  
Atribuirea valorii:
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 138  
Generația 2:  
Codurile  RegionAlpha  trebuie să figureze pe o list ă menținută pe site-ul 
web al laboratorului desemnat s ă efectueze testele de interoperabilitate.  
2.122.  RegionNumeric  
Trimitere numeric ă la o regiune dintr-o anumit ă țară.
 
Generația 1:  
Atribuirea valorii:
  
Generația 2:  
Codurile  RegionNumeric  trebuie să figureze pe o list ă menținută pe site- 
ul web al laboratorului desemnat s ă efectueze testele de interoperabi ­
litate.  
2.123.  RemoteCommunicationModuleSerialNumber  
Generația 2:  
Numărul de serie al modulului de comunicare la distan ță.
 
2.124.  RSAKeyModulus  
Generația 1:  
Modulul unei perechi de chei RSA.
  
Atribuirea valorii : neprecizat ă. 
2.125.  RSAKeyPrivateExponent  
Generația 1:  
Exponentul privat al unei perechi de chei RSA.
  
Atribuirea valorii : neprecizat ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 139  
2.126.  RSAKeyPublicExponent  
Generația 1:  
Exponentul public al unei perechi de chei RSA.
  
Atribuirea valorii : neprecizat ă. 
2.127.  RtmData  
Generația 2:  
Pentru defini ția acestui tip de date, a se vedea apendicele 14.  
2.128.  SealDataCard  
Generația 2:  
Acest tip de date stocheaz ă informații despre sigiliile care sunt ata șate la 
diferitele componente ale unui vehicul și sunt destinate a fi stocate pe un 
card. Acest tip de date se raporteaz ă la cerința 337 din anexa 1C.
  
noOfSealRecords  este numărul de înregistr ări din  sealRecords . 
sealRecords  este un set de înregistr ări privind sigiliile.  
2.129.  SealDataVu  
Generația 2:  
Acest tip de date stocheaz ă informații despre sigiliile care sunt ata șate la 
diferitele componente ale unui vehicul și sunt destinate a fi stocate într-o 
unitate montat ă pe vehicul.
  
sealRecords  este un set de înregistr ări privind sigiliile. În cazul în care 
sunt disponibile mai pu țin de 5 sigilii, valoarea  EquipmentType  în toate  
sealRecords  neutilizate se seteaz ă la 16, și anume neutilizate.  
2.130.  SealRecord  
Generația 2:  
Acest tip de date stocheaz ă informații despre un sigiliu care este ata șat la 
o component ă. Acest tip de date se raporteaz ă la cerința 337 din anexa 
1C.
 
equipmentType  identifică tipul de echipament la care este ata șat sigiliul.  
extendedSealIdentifier  este identificatorul sigiliului ata șat la echi ­
pament.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 140  
2.131.  SensorApprovalNumber  
Numărul de omologare de tip al senzorului.  
Generația 1:
  
Atribuirea valorii : neprecizat ă. 
Generația 2:
  
Atribuirea valorii:  
Numărul de omologare trebuie s ă fie furnizat a șa cum este publicat pe 
site-ul web corespunz ător al Comisiei Europene, de exemplu inclusiv cu 
liniuțe dacă este cazul. Num ărul de omologare trebuie s ă fie aliniat la 
stânga.  
2.132.  SensorExternalGNSSApprovalNumber  
Generația 2:  
Numărul de omologare de tip al echipamentului GNSS extern.
  
Atribuirea valorii:  
Numărul de omologare trebuie s ă fie furnizat a șa cum este publicat pe 
site-ul web corespunz ător al Comisiei Europene, de exemplu inclusiv cu 
liniuțe dacă este cazul. Num ărul de omologare trebuie s ă fie aliniat la 
stânga.  
2.133.  SensorExternalGNSSCoupledRecord  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind identificarea 
echipamentului GNSS extern cuplat la unitatea montat ă pe vehicul 
(cerința 100 din anexa 1C).
  
sensorSerialNumber  este num ărul de serie al echipamentului GNSS 
extern cuplat la unitatea montat ă pe vehicul.  
sensorApprovalNumber  este num ărul de omologare al respectivului 
echipament GNSS extern.  
sensorCouplingDate  este data de cuplare a respectivului echipament 
GNSS extern la unitatea montat ă pe vehicul.  
2.134.  SensorExternalGNSSIdentification  
Generația 2:  
Informații privind identificarea echipamentului GNSS extern (cerin ța 98 
din anexa 1C).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 141
  
sensorSerialNumber  este num ărul de serie lung al echipamentului 
GNSS extern.  
sensorApprovalNumber  este numărul de omologare al echipamentului 
GNSS extern.  
sensorSCIdentifier  este identificatorul componentei de securitate a echi ­
pamentului GNSS extern.  
sensorOSIdentifier  este identificatorul sistemului de operare al echipa ­
mentului GNSS extern.  
2.135.  SensorExternalGNSSInstallation  
Generația 2:  
Informații, stocate într-un echipament GNSS extern, privind instalarea 
senzorului GNSS extern (cerin ța 123 din anexa 1C).
  
sensorCouplingDateFirst  este data la care s-a efectuat prima cuplare a 
echipamentului GNSS extern la o unitate montat ă pe vehicul.  
firstVuApprovalNumber  este num ărul de omologare al primei unit ăți 
montate pe vehicul cuplate la echipamentul GNSS extern.  
firstVuSerialNumber  este numărul de serie al primei unit ăți montate pe 
vehicul asociate cu echipamentul GNSS extern.  
sensorCouplingDateCurrent  este data la care s-a efectuat cuplarea 
actuală a echipamentului GNSS extern la o unitate montat ă pe vehicul.  
currentVuApprovalNumber  este num ărul de omologare al unit ății 
montate pe vehicul cuplate în prezent la echipamentul GNSS extern.  
currentVUSerialNumber  este num ărul de serie al unit ății montate pe 
vehicul cuplate în prezent la echipamentul GNSS extern.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 142  
2.136.  SensorExternalGNSSOSIdentifier  
Generația 2:  
Identificator al sistemului de operare al echipamentului GNSS extern.
  
Atribuirea valorii : specifică producătorului.  
2.137.  SensorExternalGNSSSCIdentifier  
Generația 2:  
Acest tip de date este folosit, de exemplu, pentru identificarea modulului 
criptografic al echipamentului GNSS extern.  
Identificator al componentei de securitate a echipamentului GNSS 
extern.
  
Atribuirea valorii : specifică producătorului componentei.  
2.138.  SensorGNSSCouplingDate  
Generația 2:  
Data cuplării echipamentului GNSS extern la o unitate montat ă pe 
vehicul.
  
Atribuirea valorii : neprecizat ă. 
2.139.  SensorGNSSSerialNumber  
Generația 2:  
Acest tip de date este utilizat pentru a stoca num ărul de serie al recep ­
torului GNSS atât când acesta se afl ă în interiorul VU, cât și când acesta 
se află în exteriorul VU.  
Numărul de serie al receptorului GNSS.
  
2.140.  SensorIdentification  
Informații, stocate într-un senzor de mi șcare, privind identificarea 
senzorului de mi șcare (cerin ța 077 din anexa 1B și cerința 95 din 
anexa 1C).
  
sensorSerialNumber  este num ărul de serie lung al senzorului de 
mișcare (include num ărul de component ă și codul produc ătorului).  
sensorApprovalNumber  este num ărul de omologare al senzorului de 
mișcare.  
sensorSCIdentifier  este identificatorul componentei de securitate a 
senzorului de mi șcare. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 143  
sensorOSIdentifier  este identificatorul sistemului de operare al 
senzorului de mi șcare.  
2.141.  SensorInstallation  
Informații, stocate într-un senzor de mi șcare, privind instalarea 
senzorului de mi șcare (cerin ța 099 din anexa 1B și cerința 122 din 
anexa 1C).
  
sensorPairingDateFirst  este data la care s-a efectuat prima asociere a 
senzorului de mi șcare cu o unitate montat ă pe vehicul.  
firstVuApprovalNumber  este num ărul de omologare al primei unit ăți 
montate pe vehicul asociate cu senzorul de mi șcare.  
firstVuSerialNumber  este numărul de serie al primei unit ăți montate pe 
vehicul asociate cu senzorul de mi șcare.  
sensorPairingDateCurrent  este data la care s-a efectuat asocierea 
actuală a senzorului de mi șcare cu unitatea montat ă pe vehicul.  
currentVuApprovalNumber  este num ărul de omologare al unit ății 
montate pe vehicul asociate în prezent cu senzorul de mi șcare.  
currentVUSerialNumber  este num ărul de serie al unit ății montate pe 
vehicul asociate în prezent cu senzorul de mi șcare.  
2.142.  SensorInstallationSecData  
Informații, stocate pe un card de atelier, privind datele de securitate 
necesare pentru asocierea senzorilor de mi șcare cu unit ățile montate pe 
vehicule (cerin țele 308 și 331 din anexa 1C).  
Generația 1:
  
Atribuirea valorii : în conformitate cu standardul ISO 16844-3.  
Generația 2:  
Conform descrierii din apendicele 11, un card de atelier stocheaz ă până 
la trei chei pentru asocierea unui senzor de mi șcare cu VU. Aceste chei 
au versiuni diferite.
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 144  
2.143.  SensorOSIdentifier  
Identificator al sistemului de operare al senzorului de mi șcare.
  
Atribuirea valorii : specifică producătorului.  
2.144.  SensorPaired  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind identificarea 
senzorului de mi șcare asociat cu unitatea montat ă pe vehicul (cerin ța 079 
din anexa 1B).
  
sensorSerialNumber  este num ărul de serie al senzorului de mi șcare 
asociat în prezent cu unitatea montat ă pe vehicul.  
sensorApprovalNumber  este num ărul de omologare al senzorului de 
mișcare asociat în prezent cu unitatea montat ă pe vehicul.  
sensorPairingDateFirst  este data primei asocieri cu o unitate montat ă 
pe vehicul a senzorului de mi șcare asociat în prezent cu unitatea montat ă 
pe vehicul.  
2.145.  SensorPairedRecord  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind identificarea 
unui senzor de mi șcare asociat cu unitatea montat ă pe vehicul (cerin ța 97 
din anexa 1C).
  
sensorSerialNumber  este num ărul de serie al unui senzor de mi șcare 
asociat cu unitatea montat ă pe vehicul.  
sensorApprovalNumber  este num ărul de omologare al senzorului de 
mișcare respectiv.  
sensorPairingDate  este data la care s-a efectuat asocierea senzorului de 
mișcare respectiv cu unitatea montat ă pe vehicul.  
2.146.  SensorPairingDate  
Data asocierii unui senzor de mi șcare cu o unitate montat ă pe vehicul.
  
Atribuirea valorii : neprecizat ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 145  
2.147.  SensorSCIdentifier  
Identificatorul componentei de securitate a senzorului de mi șcare.
  
Atribuirea valorii : specifică producătorului componentei.  
2.148.  SensorSerialNumber  
Numărul de serie al senzorului de mi șcare.
  
2.149.  Signature  
O semnătură digitală. 
Generația 1:
  
Atribuirea valorii : în conformitate cu apendicele 11, „Mecanisme de 
securitate comune”.  
Generația 2:
  
Atribuirea valorii : în conformitate cu apendicele 11, „Mecanisme de 
securitate comune”.  
2.150.  SignatureRecordArray  
Generația 2:  
Un set de semn ături plus metadatele utilizate în protocolul de desc ărcare.
  
recordType  reprezintă tipul înregistr ării (Signature ). Atribuirea valorii : 
A se vedea  RecordType  
recordSize  este dimensiunea  Signature  în octeți. 
noOfRecords  este num ărul de înregistr ări cuprinse în setul  records . 
Valoarea se seteaz ă la 1 deoarece semn ăturile pot avea diferite lungimi.  
records  este setul de semn ături. 
2.151.  SimilarEventsNumber  
Numărul de evenimente similare într-o zi dat ă (cerința 094 din anexa 1B 
și cerința 117 din anexa 1C).
  
Atribuirea valorii:  0 nu se utilizeaz ă, 1 înseamn ă că s-a produs și s-a 
stocat în acea zi un singur eveniment de tipul respectiv, 2 înseamn ă că s- 
au produs dou ă evenimente de tipul respectiv în ziua dat ă (a fost stocat 
numai unul), …255 înseamn ă că s-au produs 255 sau mai multe 
evenimente de tipul respectiv în ziua dat ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 146  
2.152.  SpecificConditionRecord  
Informații, stocate pe un card de conduc ător auto, pe un card de atelier 
sau într-o unitate montat ă pe vehicul, privind o condi ție specific ă 
(cerințele 130, 276, 301, 328 și 355 din anexa 1C).
  
entryTime  reprezintă data și ora introducerii datelor.  
specificConditionType  este codul prin care se identific ă condiția 
specifică. 
2.153.  SpecificConditions  
Informații, stocate pe un card de conduc ător auto, pe un card de atelier 
sau într-o unitate montat ă pe vehicul, privind o condi ție specific ă 
(cerințele 131, 277, 302, 329 și 356 din anexa 1C).  
Generația 2:
  
conditionPointerNewestRecord  este indicele ultimei înregistr ări actua­
lizate privind condi ția specifică. 
Atribuirea valorii : număr care corespunde num ărătorului înregistr ării 
privind condi ția specific ă, începând de la ‘0’ pentru prima ocuren ță a 
înregistrării privind condi ția specifică în structur ă. 
specificConditionRecords  este setul de înregistr ări care con țin 
informații privind condi țiile specifice înregistrate.  
2.154.  SpecificConditionType  
Cod care identific ă o condiție specific ă (cerințele 050b, 105a, 212a și 
230a din anexa 1B și cerința 62 din anexa 1C).
  
Generația 1:  
Atribuirea valorii:  
‘00’H RFU  
‘01’H În afara zonei de aplicare a reglement ărilor – Început  
‘02’H În afara zonei de aplicare a reglement ărilor – Sfâr șit 
‘03’H Traversare cu feribotul / trenul  
‘04’H .. ‘FF’H RFU  
Generația 2:  
Atribuirea valorii:  
‘00’H RFU  
‘01’H În afara zonei de aplicare a reglement ărilor – Început  
‘02’H În afara zonei de aplicare a reglement ărilor – Sfâr șit 
‘03’H Traversare cu feribotul / trenul – Început  
‘04’H Traversare cu feribotul / trenul – Sfâr șit 
‘05’H .. ‘FF’H RFU  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 147  
2.155.  Speed  
Viteza vehiculului (km/h).
  
Atribuirea valorii : kilometri pe or ă în intervalul opera țional 0 – 
220 km/h.  
2.156.  SpeedAuthorised  
Viteza maxim ă autorizată a vehiculului (defini ția hh)).
  
2.157.  SpeedAverage  
Viteza medie dintr-un interval definit în prealabil (km/h).
  
2.158.  SpeedMax  
Viteza maxim ă măsurată într-un interval definit în prealabil.
  
2.159.  TachographPayload  
Generația 2:  
Pentru defini ția acestui tip de date, a se vedea apendicele 14.  
▼M1 
2.160.  Rezervat pentru o utilizare viitoare  
▼B 
2.161.  TDesSessionKey  
Generația 1:  
O cheie de sesiune DES tripl ă.
 
Atribuirea valorii : nu se furnizeaz ă indicații suplimentare.  
▼M1 
2.162.  TimeReal  
Cod pentru un câmp combinat de dat ă și oră, unde data și ora sunt 
exprimate în secunde care dep ășesc 00h.00m.00s. la 1 ianuarie 1970 
UTC.
  
Atribuirea valorii  – Octet aliniat : Numărul de secunde începând de la 
miezul nop ții la 1 ianuarie 1970 UTC.  
Data/ora maxim ă posibilă este în anul 2106.  
▼B 
2.163.  TyreSize  
Desemnarea dimensiunilor pneurilor.
  
Atribuirea valorii : în conformitate cu Directiva 92/23 (CEE) 31.3.92 
JO L 129 p. 95.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 148  
2.164.  VehicleIdentificationNumber  
Numărul de identificare a vehiculului (VIN) care desemneaz ă vehiculul 
în ansamblu, fiind reprezentat în mod normal de num ărul de serie al 
șasiului sau de num ărul cadrului.
  
Atribuirea valorii : conform defini ției din standardul ISO 3779.  
2.165.  VehicleIdentificationNumberRecordArray  
Generația 2:  
Numărul de identificare a vehiculului, plus metadatele utilizate în 
protocolul de desc ărcare.
  
recordType  reprezintă tipul înregistr ării (VehicleIdentificationNumber ). 
Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VehicleIdentificationNumber  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este setul numerelor de identificare a vehiculului.  
2.166.  VehicleRegistrationIdentification  
Identificarea unui vehicul, unic ă în Europa (VRN și statul membru).
  
vehicleRegistrationNation  reprezintă statul în care este înmatriculat 
vehiculul.  
vehicleRegistrationNumber  este numărul de înmatriculare a vehiculului 
(VRN).  
2.167.  VehicleRegistrationNumber  
Numărul de înmatriculare a vehiculului (VRN). Num ărul de înmatri ­
culare este atribuit de autoritatea responsabil ă cu înmatricularea vehicu ­
lelor.
  
codePage  indică un set de caractere definit în capitolul 4,  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 149  
vehicleRegNumber  este un VRN codat cu ajutorul setului de caractere 
precizat.  
Atribuirea valorii : specifică fiecărei țări. 
2.168.  VehicleRegistrationNumberRecordArray  
Generația 2:  
Numărul de înmatriculare al vehiculului, plus metadatele utilizate în 
protocolul de desc ărcare.
  
recordType  reprezintă tipul înregistr ării (VehicleRegistrationNumber ). 
Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VehicleRegistrationNumber  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este setul numerelor de înmatriculare a vehiculului.  
2.169.  VuAbility  
Generația 2:  
Informații stocate într-o VU privind capacitatea VU de a utiliza sau nu 
carduri de tahograf de genera ția 1 (cerin ța 121 din anexa 1C).
  
Atribuirea valorii – Octet aliniat : ‘xxxxxxxa’B (8 bi ți) 
Pentru compatibilitatea cu genera ția 1:  
‘a’B Compatibilitate cu carduri de tahograf de genera ția 1:  
‘0’ B Compatibil cu genera ția 1,  
‘1’ B Incompatibil cu genera ția 1,  
‘xxxxxxx’B RFU  
2.170.  VuActivityDailyData  
Generația 1:  
Informații, stocate într-o VU, privind modific ările activității și/sau modi ­
ficările regimului de conducere și/sau modific ările stării cardului într-o 
anumită zi calendaristic ă (cerința 084 din anexa 1B și cerințele 105, 106, 
107 din anexa 1C) și privind starea sloturilor la 00.00 în acea zi.
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 150  
noOfActivityChanges  este num ărul de cuvinte  ActivityChangeInfo  din 
setul  activityChangeInfos . 
activityChangeInfos  este setul de cuvinte  ActivityChangeInfo  stocate în 
VU pentru ziua respectiv ă. Acest set cuprinde întotdeauna dou ă cuvinte  
ActivityChangeInfo  care indic ă starea celor dou ă sloturi la ora 00.00 în 
ziua respectiv ă. 
2.171.  VuActivityDailyRecordArray  
Generația 2:  
Informații, stocate într-o VU, privind modific ările activității și/sau modi ­
ficările regimului de conducere și/sau modific ările stării cardului într-o 
anumită zi calendaristic ă (cerințele 105, 106, 107 din anexa 1C) și 
privind starea sloturilor la 00.00 în acea zi.
  
recordType  reprezint ă tipul înregistr ării ( ActivityChangeInfo ). Atri­
buirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  ActivityChangeInfo  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este setul de cuvinte  ActivityChangeInfo  stocate în VU pentru 
ziua respectiv ă. Acest set cuprinde întotdeauna dou ă cuvinte  Activity­
ChangeInfo  care indic ă starea celor dou ă sloturi la ora 00.00 în ziua 
respectivă. 
2.172.  VuApprovalNumber  
Numărul de omologare de tip al unit ății montate pe vehicul.  
Generația 1:
  
Atribuirea valorii : neprecizat ă. 
Generația 2:
  
Atribuirea valorii:  
Numărul de omologare trebuie s ă fie furnizat a șa cum este publicat pe 
site-ul web corespunz ător al Comisiei Europene, de exemplu inclusiv cu 
liniuțe dacă este cazul. Num ărul de omologare trebuie s ă fie aliniat la 
stânga.  
2.173.  VuCalibrationData  
Generația 1: ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 151  
Informații, stocate într-o unitate montat ă pe vehicul, privind opera țiunile 
de etalonare a aparaturii de înregistrare (cerin ța 098 din anexa 1B).
  
noOfVuCalibrationRecords  este num ărul de înregistr ări cuprinse în 
setul  vuCalibrationRecords . 
vuCalibrationRecords  este setul de înregistr ări privind etalonarea.  
2.174.  VuCalibrationRecord  
Informații, stocate într-o unitate montat ă pe vehicul, privind o opera țiune 
de etalonare a aparaturii de înregistrare (cerin ța 098 din anexa 1B și 
cerințele 119 și 120 din anexa 1C).  
Generația 1:
  
calibrationPurpose  este scopul etalon ării. 
workshopName, workshopAddress  reprezint ă denumirea și adresa 
atelierului.  
workshopCardNumber  identifică cardul de atelier utilizat în timpul 
operațiunii de etalonare.  
workshopCardExpiryDate  este data de expirare a cardului.  
vehicleIdentificationNumber  este VIN.  
vehicleRegistrationIdentification  conține VRN și statul membru de 
înmatriculare.  
wVehicleCharacteristicConstant  este coeficientul caracteristic al vehi ­
culului.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 152  
kConstantOfRecordingEquipment  este constanta aparaturii de înregis ­
trare.  
lTyreCircumference  este circumferin ța efectivă a pneurilor ro ților. 
tyreSize  reprezint ă desemnarea dimensiunii pneurilor montate pe 
vehicul.  
authorisedSpeed  este viteza autorizat ă a vehiculului.  
oldOdometerValue, newOdometerValue  reprezint ă vechea și, 
respectiv, noua valoare indicate de odometru.  
oldTimeValue, newTimeValue  sunt valorile vechi și, respectiv, noi ale 
datei și orei.  
nextCalibrationDate  este data urm ătoarei etalon ări de tipul specificat în  
CalibrationPurpose  care va fi efectuat ă de autoritatea de inspec ție 
competentă. 
Generația 2:
  
În plus față de genera ția 1, se utilizeaz ă următorul element de date:  
sealDataVu  oferă informații cu privire la sigiliile care sunt ata șate la 
diferite componente ale vehiculului.  
2.175.  VuCalibrationRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind opera țiunile 
de etalonare a aparaturii de înregistrare (cerin țele 119 și 120 din anexa 
1C). ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 153
  
recordType  reprezintă tipul înregistr ării (VuCalibrationRecord ). Atri­
buirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuCalibrationRecord  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este setul de înregistr ări privind etalonarea.  
2.176.  VuCardIWData  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind ciclurile de 
introducere și de retragere a cardurilor de conduc ător auto sau a 
cardurilor de atelier din unitatea montat ă pe vehicul (cerin ța 081 din 
anexa 1B și cerința 103 din anexa 1C).
  
noOfIWRecords  este num ărul de înregistr ări cuprinse în setul  vuCar­
dIWRecords . 
vuCardIWRecords  este un set de înregistr ări privind ciclurile de intro ­
ducere și de retragere a cardurilor.  
2.177.  VuCardIWRecord  
Informații, stocate într-o unitate montat ă pe vehicul, privind un ciclu de 
introducere și de retragere a unui card de conduc ător auto sau a unui 
card de atelier din unitatea montat ă pe vehicul (cerin ța 081 din anexa 1B 
și cerința 102 din anexa 1C).  
Generația 1:
  
cardHolderName  reprezintă numele și prenumele titularului unui card 
de conduc ător auto sau al unui card de atelier, a șa cum sunt acestea 
stocate pe card.  
fullCardNumber  reprezintă tipul cardului, statul membru emitent al 
cardului și numărul cardului, a șa cum sunt stocate pe card.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 154  
cardExpiryDate  este data de expirare a cardului, a șa cum este stocat ă 
pe card.  
cardInsertionTime  reprezintă data și ora introducerii cardului.  
vehicleOdometerValueAtInsertion  este valoarea indicat ă de odometrul 
vehiculului în momentul introducerii cardului.  
cardSlotNumber  este slotul în care se introduce cardul.  
cardWithdrawalTime  reprezintă data și ora retragerii cardului.  
vehicleOdometerValueAtWithdrawal  este valoarea indicat ă de 
odometrul vehiculului în momentul retragerii cardului.  
previousVehicleInfo  conține informa ții privind vehiculul folosit anterior 
de conduc ătorul auto, a șa cum este acesta stocat pe card.  
manualInputFlag  este un indicator prin care se indic ă dacă titularul 
cardului a introdus manual activit ățile conduc ătorului auto la intro ­
ducerea cardului.  
Generația 2:
  
În loc de  fullCardNumber , în structura de date aferent ă generației 2 se 
utilizează următorul element de date.  
fullCardNumberAndGeneration  reprezint ă tipul cardului, statul 
membru emitent al cardului, num ărul cardului și generația sa, așa cum 
sunt stocate pe card.  
2.178.  VuCardIWRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind ciclurile de 
introducere și de retragere a cardurilor de conduc ător auto sau a 
cardurilor de atelier din unitatea montat ă pe vehicul (cerin ța 103 din 
anexa 1C).
  
recordType  reprezintă tipul înregistr ării (VuCardIWRecord ). Atribuirea 
valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuCardIWRecord  în octeți. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 155  
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări privind ciclurile de introducere și de 
retragere a cardurilor.  
▼M1 
2.179.  VuCardRecord  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind un card de 
tahograf utilizat (cerin ța 132 din anexa IC).
  
cardNumberAndGenerationInformation  este num ărul complet al 
cardului și generația cardului utilizat (tip de date 2.74).  
cardExtendedSerialNumber  așa cum este citit din fi șierul EF_ICC din 
MF al cardului.  
cardStructureVersion  așa cum este citit din fi șierul EF_Applica ­
tion_Identification din cadrul DF_Tachograph_G2.  
cardNumber  așa cum este citit din fi șierul EF_Identification din cadrul 
DF_Tachograph_G2.  
▼B 
2.180.  VuCardRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind cardurile de 
tahograf utilizate cu respectiva VU. Aceste informa ții sunt destinate 
analizei VU – probleme card (cerin ța 132 din anexa 1C).
  
recordType  reprezintă tipul înregistr ării (VuCardRecord ). Atribuirea 
valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuCardRecord  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări privind cardurile de tahograf utilizate 
cu VU.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 156  
2.181.  VuCertificate  
Certificatul cheii publice a unei unit ăți montate pe vehicul.
  
2.182.  VuCertificateRecordArray  
Generația 2:  
Certificatul VU, plus metadatele utilizate în protocolul de desc ărcare.
  
recordType  reprezint ă tipul înregistr ării ( VuCertificate ). Atribuirea 
valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuCertificate  în octeți. 
noOfRecords  este num ărul de înregistr ări cuprinse în setul  records . 
Valoarea se seteaz ă la 1 deoarece certificatele pot avea diferite lungimi.  
records  este un set de certificate ale VU.  
2.183.  VuCompanyLocksData  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind bloc ările 
efectuate de societate (cerin ța 104 din anexa 1B).
  
noOfLocks  este numărul de bloc ări enumerate în  vuCompanyLocksRe ­
cords . 
vuCompanyLocksRecords  este setul de înregistr ări privind bloc ările 
efectuate de societate.  
2.184.  VuCompanyLocksRecord  
Informații, stocate într-o unitate montat ă pe vehicul, privind o blocare 
efectuată de societate (cerin ța 104 din anexa 1B și cerința 128 din anexa 
1C). 
Generația 1:
 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 157  
lockInTime, lockOutTime  reprezintă data și ora blocării și, respectiv, a 
deblocării. 
companyName, companyAddress  reprezint ă denumirea și adresa 
societății asociate cu blocarea.  
companyCardNumber  reprezintă cardul utilizat la blocare.  
Generația 2:
  
În loc de  companyCardNumber , în structura de date aferent ă generației 2 
se utilizeaz ă următorul element de date.  
companyCardNumberAndGeneration  reprezint ă cardul utilizat la 
blocare, inclusiv genera ția acestuia.  
2.185.  VuCompanyLocksRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind bloc ările 
efectuate de societate (cerin ța 128 din anexa 1C).
  
recordType  reprezint ă tipul înregistr ării ( VuCompanyLocksRecord ). 
Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuCompanyLocksRecord  în octeți. 
noOfRecords  este num ărul de înregistr ări cuprinse în setul  records . 
Valoare 0..255.  
records  este setul de înregistr ări privind bloc ările efectuate de societate.  
2.186.  VuControlActivityData  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind controalele 
efectuate utilizând VU respectiv ă (cerința 102 din anexa 1B).
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 158  
noOfControls  este numărul de controale enumerate în  vuControlActivi ­
tyRecords . 
vuControlActivityRecords  este setul de înregistr ări privind activit ățile 
de control.  
2.187.  VuControlActivityRecord  
Informații, stocate într-o unitate montat ă pe vehicul, privind un control 
efectuat utilizând respectiva VU (cerin ța 102 din anexa 1B și cerința 126 
din anexa 1C).  
Generația 1:
  
controlType  este tipul de control.  
controlTime  este data și ora la care a avut loc controlul.  
controlCardNumber  reprezintă cardul de control utilizat la efectuarea 
controlului.  
downloadPeriodBeginTime  este ora de începere a perioadei desc ărcate, 
în caz de desc ărcare.  
downloadPeriodEndTime  este ora de încheiere a perioadei desc ărcate, 
în caz de desc ărcare.  
Generația 2:
  
În loc de  controlCardNumber , în structura de date aferent ă generației 2 
se utilizeaz ă următorul element de date.  
controlCardNumberAndGeneration  reprezint ă cardul de control 
utilizat la efectuarea controlului, inclusiv genera ția acestuia.  
2.188.  VuControlActivityRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind controalele 
efectuate utilizând VU respectiv ă (cerința 126 din anexa 1C).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 159
  
recordType  reprezint ă tipul înregistr ării ( VuControlActivityRecord ). 
Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuControlActivityRecord  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este setul de înregistr ări privind activit ățile de control al VU.  
2.189.  VuDataBlockCounter  
Contor, stocat pe un card, care indic ă secvențial ciclurile de introducere 
și de retragere a cardului din unit ățile montate pe vehicul.
  
Atribuirea valorii : număr consecutiv cu valoarea maxim ă de 9 999, 
după care numerotarea reîncepe de la 0.  
2.190.  VuDetailedSpeedBlock  
Informații, stocate într-o unitate montat ă pe vehicul, privind viteza 
detaliată a vehiculului timp de un minut în care vehiculul s-a aflat în 
mișcare (cerin ța 093 din anexa 1B și cerința 116 din anexa 1C).
  
speedBlockBeginDate  reprezintă data și ora primei valori a vitezei din 
bloc.  
speedsPerSecond  este secven ța cronologic ă de viteze m ăsurate în 
fiecare secund ă din minutul care a început cu  speedBlockBeginDate  
(inclusiv).  
2.191.  VuDetailedSpeedBlockRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind viteza 
detaliată a vehiculului.
  
recordType  reprezintă tipul înregistr ării (VuDetailedSpeedBlock ). Atri­
buirea valorii : A se vedea  RecordType  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 160  
recordSize  este dimensiunea  VuDetailedSpeedBlock  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este setul de blocuri de date privind viteza detaliat ă. 
2.192.  VuDetailedSpeedData  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind viteza 
detaliată a vehiculului.
  
noOfSpeedBlocks  este num ărul de blocuri de date privind viteza din 
setul  vuDetailedSpeedBlocks . 
vuDetailedSpeedBlocks  este setul de blocuri de date privind viteza 
detaliată. 
2.193.  VuDownloadablePeriod  
Cele mai vechi și cele mai recente date pentru care o unitate montat ă pe 
vehicul con ține informa ții privind activit ățile conduc ătorului auto 
(cerințele 081, 084 sau 087 din anexa 1B și cerințele 102,105, 108 
din anexa 1C).
  
minDownloadableTime  reprezintă cea mai veche dat ă și oră stocată în 
VU la care s-a realizat o introducere a cardului, o modificare a activit ății 
sau o introducere de date privind locul.  
maxDownloadableTime  reprezintă cea mai recent ă dată și oră stocată în 
VU la care s-a realizat o retragere a cardului, o modificare a activit ății 
sau o introducere de date privind locul.  
2.194.  VuDownloadablePeriodRecordArray  
Generația 2:  
VUDownloadablePeriod , plus metadatele utilizate în protocolul de 
descărcare.
  
recordType  reprezintă tipul înregistr ării (VuDownloadablePeriod ). Atri­
buirea valorii : A se vedea  RecordType  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 161  
recordSize  este dimensiunea  VuDownloadablePeriod  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este setul de înregistr ări VuDownloadablePeriod . 
2.195.  VuDownloadActivityData  
Informații, stocate într-o unitate montat ă pe vehicul, privind ultima 
descărcare de date din aceasta (cerin ța 105 din anexa 1B și cerința 
129 din anexa 1C).  
Generația 1:
  
downloadingTime  reprezintă data și ora la care s-a realizat desc ărcarea.  
fullCardNumber  reprezintă cardul utilizat pentru autorizarea desc ărcării. 
companyOrWorkshopName  reprezint ă denumirea societ ății sau a 
atelierului.  
Generația 2:
  
În loc de  fullCardNumber , în structura de date aferent ă generației 2 se 
utilizează următorul element de date.  
fullCardNumberAndGeneration  reprezintă cardul utilizat pentru auto ­
rizarea desc ărcării, inclusiv genera ția acestuia.  
2.196.  VuDownloadActivityDataRecordArray  
Generația 2:  
Informații privind ultima desc ărcare din VU (cerin ța 129 din anexa 1C).
  
recordType  reprezint ă tipul înregistr ării ( VuDownloadActivityData ). 
Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuDownloadActivityData  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 162  
records  este setul de înregistr ări de date privind activit ățile de 
descărcare.  
2.197.  VuEventData  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind eveni ­
mentele (cerin ța 094 din anexa 1B, cu excep ția evenimentului de 
depășire a limitei de vitez ă).
 
noOfVuEvents  este numărul de evenimente enumerate în setul  vuEven­
tRecords . 
vuEventRecords  este un set de înregistr ări privind evenimentele.  
2.198.  VuEventRecord  
Informații, stocate într-o unitate montat ă pe vehicul, privind un 
eveniment (cerin ța 094 din anexa 1B și cerința 117 din anexa 1C, cu 
excepția evenimentului de dep ășire a limitei de vitez ă). 
Generația 1:
  
eventType  este tipul de eveniment.  
eventRecordPurpose  este motivul pentru care s-a efectuat înregistrarea 
evenimentului respectiv.  
eventBeginTime  este data și ora la care a început evenimentul.  
eventEndTime  este data și ora la care s-a încheiat evenimentul.  
cardNumberDriverSlotBegin  identifică cardul introdus în slotul pentru 
cardul de conduc ător auto la începutul evenimentului.  
cardNumberCodriverSlotBegin  identifică cardul introdus în slotul 
pentru cardul de copilot la începutul evenimentului.  
cardNumberDriverSlotEnd  identifică cardul introdus în slotul pentru 
cardul de conduc ător auto la sfâr șitul evenimentului.  
cardNumberCodriverSlotEnd  identifică cardul introdus în slotul pentru 
cardul de copilot la sfâr șitul evenimentului.  
similarEventsNumber  este num ărul de evenimente similare din ziua 
respectivă. 
Această secvență poate fi utilizat ă pentru toate evenimentele, cu excep ția 
evenimentelor de dep ășire a limitei de vitez ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 163  
Generația 2:
  
În plus față de genera ția 1, se utilizeaz ă următoarele elemente de date:  
manufacturerSpecificEventFaultData  conține informa ții suplimentare 
cu privire la eveniment, specifice produc ătorului.  
În loc de  cardNumberDriverSlotBegin , cardNumberCodriverSlotBegin , 
cardNumberDriverSlotEnd  și cardNumberCodriverSlotEnd , în structura 
de date aferent ă generației 2 se utilizeaz ă următoarele elemente de date:  
cardNumberAndGenDriverSlotBegin  identifică cardul introdus în 
slotul pentru cardul de conduc ător auto la începutul evenimentului, 
inclusiv genera ția cardului respectiv.  
cardNumberAndGenCodriverSlotBegin  identifică cardul introdus în 
slotul pentru cardul de copilot la începutul evenimentului, inclusiv 
generația cardului respectiv.  
cardNumberAndGenDriverSlotEnd  identifică cardul introdus în slotul 
pentru cardul de conduc ător auto la sfâr șitul evenimentului, inclusiv 
generația cardului respectiv.  
cardNumberAndGenCodriverSlotEnd  identifică cardul introdus în 
slotul pentru cardul de copilot la sfâr șitul evenimentului, inclusiv 
generația cardului respectiv.  
În cazul în care evenimentul este un conflict or ă, eventBeginTime  și 
eventEndTime  se interpreteaz ă după cum urmeaz ă: 
eventBeginTime  este data și ora indicat ă de aparatura de înregistrare.  
eventEndTime  reprezintă data și ora GNSS.  
2.199.  VuEventRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind eveni ­
mentele (cerin ța 117 din anexa 1C, cu excep ția evenimentului privind 
depășirea limitei de vitez ă).
 
recordType  reprezintă tipul înregistr ării (VuEventRecord ). Atribuirea 
valorii : A se vedea  RecordType  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 164  
recordSize  este dimensiunea  VuEventRecord  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări privind evenimentele.  
2.200.  VuFaultData  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind anomaliile 
(cerința 096 din anexa 1B).
  
noOfVuFaults  este numărul anomaliilor enumerate în setul  vuFaultRe ­
cords . 
vuFaultRecords  este un set de înregistr ări privind anomaliile.  
2.201.  VuFaultRecord  
Informații, stocate într-o unitate montat ă pe vehicul, privind o anomalie 
(cerința 096 din anexa 1B și cerința 118 din anexa 1C).  
Generația 1:
  
faultType  este tipul de anomalie a aparaturii de înregistrare.  
faultRecordPurpose  este motivul pentru care s-a efectuat înregistrarea 
anomaliei respective.  
faultBeginTime  este data și ora la care a început anomalia.  
faultEndTime  este data și ora la care s-a încheiat anomalia.  
cardNumberDriverSlotBegin  identifică cardul introdus în slotul pentru 
cardul de conduc ător auto la începutul anomaliei.  
cardNumberCodriverSlotBegin  identifică cardul introdus în slotul 
pentru cardul de copilot la începutul anomaliei.  
cardNumberDriverSlotEnd  identifică cardul introdus în slotul pentru 
cardul de conduc ător auto la sfâr șitul anomaliei.  
cardNumberCodriverSlotEnd  identifică cardul introdus în slotul pentru 
cardul de copilot la sfâr șitul anomaliei.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 165  
Generația 2:
  
În plus față de genera ția 1, se utilizeaz ă următorul element de date:  
manufacturerSpecificEventFaultData  conține informa ții suplimentare 
specifice produc ătorului cu privire la anomalie.  
În loc de  cardNumberDriverSlotBegin , cardNumberCodriverSlotBegin , 
cardNumberDriverSlotEnd  și cardNumberCodriverSlotEnd , în structura 
de date aferent ă generației 2 se utilizeaz ă următoarele elemente de date:  
cardNumberAndGenDriverSlotBegin  identifică cardul introdus în 
slotul pentru cardul de conduc ător auto la începutul anomaliei, 
inclusiv genera ția cardului respectiv.  
cardNumberAndGenCodriverSlotBegin  identifică cardul introdus în 
slotul pentru cardul de copilot la începutul anomaliei, inclusiv 
generația cardului respectiv.  
cardNumberAndGenDriverSlotEnd  identifică cardul introdus în slotul 
pentru cardul de conduc ător auto la sfâr șitul anomaliei, inclusiv 
generația cardului respectiv.  
cardNumberAndGenCodriverSlotEnd  identifică cardul introdus în 
slotul pentru cardul de copilot la sfâr șitul anomaliei, inclusiv genera ția 
cardului respectiv.  
2.202.  VuFaultRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind anomaliile 
(cerința 118 din anexa 1C).
  
recordType  reprezintă tipul înregistr ării (VuFaultRecord ). Atribuirea 
valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuFaultRecord  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări privind anomaliile.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 166  
2.203.  VuGNSSADRecord  
Generația 2:  
Informații stocate într-o unitate montat ă pe vehicul privind pozi ția GNSS 
a vehiculului dac ă timpul de conducere acumulat ajunge la un multiplu 
de trei ore (cerin țele 108, 110 din anexa IC).
  
timeStamp  este data și ora la care timpul de conducere acumulat atinge 
un multiplu de trei ore.  
cardNumberAndGenDriverSlot  identifică cardul introdus în slotul 
pentru cardul de conduc ător auto, inclusiv genera ția cardului respectiv.  
cardNumberAndGenCodriverSlot  identifică cardul introdus în slotul 
pentru cardul de copilot, inclusiv genera ția cardului respectiv.  
gnssPlaceRecord  conține informa ții referitoare la pozi ția vehiculului.  
vehicleOdometerValue  este valoarea odometrului în momentul în care 
timpul de conducere acumulat atinge un multiplu de trei ore.  
2.204.  VuGNSSADRecordArray  
Generația 2:  
Informații stocate într-o unitate montat ă pe vehicul privind pozi ția GNSS 
a vehiculului dac ă timpul de conducere acumulat ajunge la un multiplu 
de trei ore (cerin țele 108 și 110 din anexa IC).
  
recordType  reprezintă tipul înregistr ării (VuGNSSADRecord).  
Atribuirea valorii : A se vedea RecordType.  
recordSize  este dimensiunea VuGNSSADRecord în octe ți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul records.  
records  este un set de înregistr ări GNSS privind timpul de conducere 
acumulat.  
▼B 
2.205.  VuIdentification  
Informații, stocate într-o unitate montat ă pe vehicul, privind identificarea 
unității montate pe vehicul (cerin ța 075 din anexa 1B și cerințele 93 și 
121 din anexa 1C).  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 167  
Generația 1:
  
vuManufacturerName  este numele produc ătorului unit ății montate pe 
vehicul.  
vuManufacturerAddress  este adresa produc ătorului unit ății montate pe 
vehicul.  
vuPartNumber  este num ărul de component ă al unității montate pe 
vehicul.  
vuSerialNumber  este num ărul de serie al unit ății montate pe vehicul.  
vuSoftwareIdentification  identifică software-ul implementat în unitatea 
montată pe vehicul.  
vuManufacturingDate  este data de fabrica ție a unității montate pe 
vehicul.  
vuApprovalNumber  este num ărul de omologare de tip al unit ății 
montate pe vehicul.  
Generația 2:
  
În plus față de genera ția 1, se utilizeaz ă următorul element de date:  
vuGeneration  identifică generația unității montate pe vehicul.  
vuAbility  oferă informații cu privire la faptul dac ă VU este compatibil ă 
sau nu cu carduri de tahograf de genera ția 1.  
2.206.  VuIdentificationRecordArray  
Generația 2:  
VuIdentification , plus metadatele utilizate în protocolul de desc ărcare.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 168
  
recordType  reprezintă tipul înregistr ării (VuIdentification ). Atribuirea 
valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuIdentification  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări VuIdentification . 
2.207.  VuITSConsentRecord  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind aprobarea 
unui conduc ător auto de a utiliza sisteme de transport inteligente.
  
cardNumberAndGen  identifică cardul, inclusiv genera ția sa. Acesta 
trebuie să fie un card de conduc ător auto sau un card de atelier.  
consent  este un indicator care indic ă dacă conducătorul auto și-a dat 
consimțământul privind utilizarea sistemelor de transport inteligente cu 
acest vehicul/cu aceast ă unitate montat ă pe vehicul.  
Atribuirea valorii:  
TRUE indic ă consimțământul conduc ătorului auto de a utiliza 
sisteme de transport inteligente  
FALSE indic ă refuzul conduc ătorului auto de a utiliza sisteme de 
transport inteligente  
2.208.  VuITSConsentRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind 
consimțământul conduc ătorilor auto de a utiliza sisteme de transport 
inteligente (cerin ța 200 din anexa 1C).
  
recordType  reprezintă tipul înregistr ării (VuITSConsentRecord ). Atri­
buirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuITSConsentRecord  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este setul de înregistr ări privind consim țământul ITS.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 169  
2.209.  VuManufacturerAddress  
Adresa produc ătorului unit ății montate pe vehicul.
  
Atribuirea valorii : neprecizat ă. 
2.210.  VuManufacturerName  
Numele produc ătorului unit ății montate pe vehicul.
  
Atribuirea valorii : neprecizat ă. 
2.211.  VuManufacturingDate  
Data de fabrica ție a unității montate pe vehicul.
  
Atribuirea valorii : neprecizat ă. 
2.212.  VuOverSpeedingControlData  
Informații, stocate într-o unitate montat ă pe vehicul, privind eveni ­
mentele de dep ășire a limitei de vitez ă care s-au produs de la ultimul 
control privind dep ășirea limitei de vitez ă (cerința 095 din anexa 1B și 
cerința 117 din anexa 1C).
  
lastOverspeedControlTime  reprezintă data și ora la care s-a efectuat 
ultimul control privind dep ășirea limitei de vitez ă. 
firstOverspeedSince  reprezintă data și ora primei dep ășiri a limitei de 
viteză după efectuarea respectivului control al dep ășirilor limitei de 
viteză. 
numberOfOverspeedSince  este num ărul de evenimente de dep ășire a 
limitei de vitez ă de la ultimul control al dep ășirilor limitei de vitez ă. 
2.213.  VuOverSpeedingControlDataRecordArray  
Generația 2:  
VuOverSpeedingControlData , plus metadatele utilizate în protocolul de 
descărcare.
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 170  
recordType  reprezintă tipul înregistr ării (VuOverSpeedingControlData ). 
Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuOverSpeedingControlData  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări de date referitoare la controalele 
privind dep ășirea limitei de vitez ă. 
2.214.  VuOverSpeedingEventData  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind eveni ­
mentele de dep ășire a limitei de vitez ă (cerința 094 din anexa 1B).
  
noOfVuOverSpeedingEvents  este numărul de evenimente enumerate în 
setul  vuOverSpeedingEventRecords . 
vuOverSpeedingEventRecords  este un set de înregistr ări privind eveni ­
mentele de dep ășire a limitei de vitez ă. 
2.215.  VuOverSpeedingEventRecord  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind eveni ­
mentele de dep ășire a limitei de vitez ă (cerința 094 din anexa 1B și 
cerința 117 din anexa 1C).
  
eventType  este tipul de eveniment.  
eventRecordPurpose  este motivul pentru care s-a efectuat înregistrarea 
evenimentului respectiv.  
eventBeginTime  este data și ora la care a început evenimentul.  
eventEndTime  este data și ora la care s-a încheiat evenimentul.  
maxSpeedValue  este viteza maxim ă măsurată în timpul evenimentului.  
averageSpeedValue  este media aritmetic ă a vitezei m ăsurate în timpul 
evenimentului.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 171  
cardNumberDriverSlotBegin  identifică cardul introdus în slotul pentru 
cardul de conduc ător auto la începutul evenimentului.  
similarEventsNumber  este num ărul de evenimente similare din ziua 
respectivă. 
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind eveni ­
mentele de dep ășire a limitei de vitez ă (cerința 094 din anexa 1B și 
cerința 117 din anexa 1C).
  
În loc de  cardNumberDriverSlotBegin , în structura de date aferent ă 
generației 2 se utilizeaz ă următorul element de date:  
cardNumberAndGenDriverSlotBegin  identifică cardul, introdus în 
slotul pentru cardul de conduc ător auto la începutul evenimentului, 
inclusiv genera ția cardului respectiv.  
2.216.  VuOverSpeedingEventRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind eveni ­
mentele de dep ășire a limitei de vitez ă (cerința 117 din anexa 1C).
  
recordType  reprezintă tipul înregistr ării (VuOverSpeedingEventRecord ). 
Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuOverSpeedingEventRecord  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări privind evenimentele de dep ășire a 
limitei de vitez ă. 
2.217.  VuPartNumber  
Numărul de component ă al unității montate pe vehicul.
  
Atribuirea valorii : specifică producătorului VU.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 172  
2.218.  VuPlaceDailyWorkPeriodData  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind locurile în 
care conduc ătorii auto încep sau încheie o zi de lucru (cerin ța 087 din 
anexa 1B sau cerin țele 108 și 110 din anexa 1C).
  
noOfPlaceRecords  este num ărul de înregistr ări enumerate în setul  
vuPlaceDailyWorkPeriodRecords . 
vuPlaceDailyWorkPeriodRecords  este un set de înregistr ări privind 
locurile.  
2.219.  VuPlaceDailyWorkPeriodRecord  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind un loc în 
care un conduc ător auto începe sau încheie o zi de lucru (cerin ța 087 din 
anexa 1B sau cerin țele 108 și 110 din anexa 1C).
  
fullCardNumber  reprezintă tipul de card al conduc ătorului auto, statul 
membru emitent al cardului și numărul cardului.  
placeRecord  conține informa țiile privind locul introdus.  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind un loc în 
care un conduc ător auto începe sau încheie o zi de lucru (cerin ța 087 din 
anexa 1B sau cerin țele 108 și 110 din anexa 1C).
  
În loc de  fullCardNumber , în structura de date aferent ă generației 2 se 
utilizează următorul element de date:  
fullCardNumberAndGeneration  reprezint ă tipul cardului, statul 
membru emitent al cardului, num ărul cardului și generația sa, așa cum 
sunt stocate pe card.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 173  
2.220.  VuPlaceDailyWorkPeriodRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind locurile în 
care conduc ătorii auto încep sau încheie o zi de lucru (cerin țele 108 și 
110 din anexa 1C).
  
recordType  reprezintă tipul înregistr ării (VuPlaceDailyWorkPeriodRe ­
cord). Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuPlaceDailyWorkPeriodRecord  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări privind locurile.  
2.221.  VuPrivateKey  
Generația 1:  
Cheia privat ă a unei unit ăți montate pe vehicul.
  
2.222.  VuPublicKey  
Generația 1:  
Cheia public ă a unei unit ăți montate pe vehicul.
  
2.223.  VuSerialNumber  
Numărul de serie al unit ății montate pe vehicul (cerin ța 075 din anexa 
1B și cerința 93 din anexa 1C).
  
2.224.  VuSoftInstallationDate  
Data instal ării versiunii de software a unit ății montate pe vehicul.
  
Atribuirea valorii : neprecizat ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 174  
2.225.  VuSoftwareIdentification  
Informații, stocate într-o unitate montat ă pe vehicul, privind software-ul 
instalat.
  
vuSoftwareVersion  este num ărul versiunii software-ului instalat pe 
unitatea montat ă pe vehicul.  
vuSoftInstallationDate  este data instal ării versiunii de software.  
2.226.  VuSoftwareVersion  
Numărul versiunii de software al unit ății montate pe vehicul.
  
Atribuirea valorii : neprecizat ă. 
2.227.  VuSpecificConditionData  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind condi țiile 
specifice.
  
noOfSpecificConditionRecords  este numărul de înregistr ări enumerate 
în setul  specificConditionRecords . 
specificConditionRecords  este un set de înregistr ări privind condi țiile 
specifice.  
2.228.  VuSpecificConditionRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind condi țiile 
specifice (cerin ța 130 din anexa 1C).
  
recordType  reprezint ă tipul înregistr ării ( SpecificConditionRecord ). 
Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  SpecificConditionRecord  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări privind condi țiile specifice.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 175  
2.229.  VuTimeAdjustmentData  
Generația 1:  
Informații, stocate într-o unitate montat ă pe vehicul, privind opera țiunile 
de reglare a orei efectuate în afara cadrului unei etalon ări normale 
(cerința 101 din anexa 1B).
  
noOfVuTimeAdjRecords  este numărul de înregistr ări din  vuTimeAdjus ­
tmentRecords . 
vuTimeAdjustmentRecords  este un set de înregistr ări privind 
operațiunile de reglare a orei.  
▼M1 
2.230.  Rezervat pentru o utilizare viitoare  
2.231.  Rezervat pentru o utilizare viitoare  
▼B 
2.232.  VuTimeAdjustmentRecord  
Informații, stocate într-o unitate montat ă pe vehicul, privind o opera țiune 
de reglare a orei efectuat ă în afara cadrului unei etalon ări normale 
(cerința 101 din anexa 1B și cerințele 124 și 125 din anexa 1C).  
Generația 1:
  
oldTimeValue, newTimeValue  sunt valorile vechi și, respectiv, noi ale 
datei și orei.  
workshopName, workshopAddress  reprezint ă denumirea și adresa 
atelierului.  
workshopCardNumber  reprezintă cardul de atelier utilizat pentru a 
efectua opera țiunea de reglare a orei.  
Generația 2:
  
În loc de  workshopCardNumber , în structura de date aferent ă generației 
2 se utilizeaz ă următorul element de date.  
workshopCardNumberAndGeneration  reprezint ă cardul de atelier 
utilizat pentru a efectua opera țiunea de reglare a orei, inclusiv 
generația acestuia.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 176  
2.233.  VuTimeAdjustmentRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind opera țiunile 
de reglare a orei efectuate în afara cadrului unei etalon ări normale 
(cerințele 124 și 125 din anexa 1C).
  
recordType  reprezint ă tipul înregistr ării ( VuTimeAdjustmentRecord ). 
Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuTimeAdjustmentRecord  în octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări privind opera țiunile de reglare a orei.  
2.234.  WorkshopCardApplicationIdentification  
Informații, stocate pe un card de atelier, privind identificarea aplica ției 
cardului (cerin țele 307 și 330 din anexa 1C).  
Generația 1:
  
typeOfTachographCardId  precizează tipul de card implementat.  
cardStructureVersion  precizeaz ă versiunea structurii implementate în 
card.  
noOfEventsPerType  reprezintă numărul de evenimente, per tip de 
eveniment, pe care cardul le poate înregistra.  
noOfFaultsPerType  reprezint ă numărul de anomalii, per tip de 
anomalie, pe care cardul le poate înregistra.  
activityStructureLength  indică numărul de octe ți disponibili pentru 
stocarea înregistr ărilor privind activit ățile. 
noOfCardVehicleRecords  este num ărul de înregistr ări privind vehi ­
culele pe care cardul le poate con ține. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 177  
noOfCardPlaceRecords  este numărul de locuri pe care cardul le poate 
înregistra.  
noOfCalibrationRecords  este num ărul de înregistr ări privind 
operațiunile de etalonare care pot fi stocate pe card.  
Generația 2: 
▼M1
 
În plus față de genera ția 1, se utilizeaz ă următoarele elemente de date:  
noOfGNSSADRecords  este num ărul de înregistr ări GNSS privind 
timpul de conducere acumulat care pot fi stocate pe card.  
noOfSpecificConditionRecords  este num ărul de înregistr ări privind 
condițiile specifice care pot fi stocate pe card.  
noOfCardVehicleUnitRecords  este num ărul de înregistr ări privind 
unitățile montate pe vehicul utilizate care pot fi stocate pe card.  
▼B 
2.235.  WorkshopCardCalibrationData  
Informații, stocate pe un card de atelier, privind activit ățile atelierului 
efectuate cu cardul (cerin țele 314, 316, 337 și 339 din anexa 1C).
  
calibrationTotalNumber  este numărul total de opera țiuni de etalonare 
efectuate cu cardul.  
calibrationPointerNewestRecord este indicele ultimei înregistr ări actua­
lizate privind etalonarea.  
Atribuirea valorii : număr corespunzând num ărătorului înregistr ării 
privind etalonarea, începând cu ‘0’ pentru prima ocuren ță a înregis ­
trărilor privind etalonarea în structur ă. 
calibrationRecords  este setul de înregistr ări care con țin informa ții 
privind etalonarea și/sau opera țiunile de reglare a orei.  
2.236.  WorkshopCardCalibrationRecord  
Informații, stocate pe un card de atelier, privind activit ățile de etalonare 
efectuate cu cardul (cerin țele 314 și 337 din anexa 1C).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 178  
Generația 1:
  
calibrationPurpose  este scopul etalon ării. 
vehicleIdentificationNumber  este VIN.  
vehicleRegistration  conține VRN și statul membru de înmatriculare.  
wVehicleCharacteristicConstant  este coeficientul caracteristic al vehi ­
culului.  
kConstantOfRecordingEquipment  este constanta aparaturii de înregis ­
trare.  
lTyreCircumference  este circumferin ța efectivă a pneurilor ro ților. 
tyreSize  reprezint ă desemnarea dimensiunilor pneurilor montate pe 
vehicul.  
authorisedSpeed  este viteza maxim ă autorizată a vehiculului.  
oldOdometerValue, newOdometerValue  reprezint ă vechea și, 
respectiv, noua valoare indicate de odometru.  
oldTimeValue, newTimeValue  sunt valorile vechi și, respectiv, noi ale 
datei și orei.  
nextCalibrationDate  este data urm ătoarei etalon ări de tipul specificat în  
CalibrationPurpose  care va fi efectuat ă de autoritatea de inspec ție 
competentă. 
vuPartNumber , vuSerialNumber  și sensorSerialNumber  sunt 
elementele de date pentru identificarea aparaturii de înregistrare.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 179  
Generația 2:
  
În plus față de genera ția 1, se utilizeaz ă următoarele elemente de date:  
sensorGNSSSerialNumber  care identific ă un echipament GNSS extern.  
rcmSerialNumber  care identific ă un modul de comunicare la distan ță. 
sealDataCard  oferă informații cu privire la sigiliile care sunt ata șate la 
diferite componente ale vehiculului.  
2.237.  WorkshopCardHolderIdentification  
Informații, stocate pe un card de atelier, privind identificarea titularului 
cardului (cerin țele 311 și 334 din anexa 1C).
  
workshopName  este numele atelierului de care apar ține titularul 
cardului.  
workshopAddress  este adresa atelierului de care apar ține titularul 
cardului.  
cardHolderName  este numele și prenumele titularului (de exemplu, 
numele mecanicului).  
cardHolderPreferredLanguage  este limba preferat ă de titularul 
cardului.  
2.238.  WorkshopCardPIN  
Numărul de identificare personal al cardului de atelier (cerin țele 309 și 
332 din anexa 1C).
  
Atribuirea valorii : PIN-ul cunoscut de titularul cardului, completat la 
dreapta cu o serie de octe ți ‘FF’ care poate con ține până la 8 octe ți. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 180  
2.239.  W-VehicleCharacteristicConstant  
Coeficientul caracteristic al vehiculului [defini ția k)].
  
Atribuirea valorii : impulsuri pe kilometru în intervalul opera țional de la 
0 la 64 255 impulsuri/km.  
2.240.  VuPowerSupplyInterruptionRecord  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind eveni ­
mentele de întrerupere a aliment ării cu energie electric ă (cerința 117 
din anexa 1C).
  
eventType  este tipul de eveniment.  
eventRecordPurpose  este motivul pentru care s-a efectuat înregistrarea 
evenimentului respectiv.  
eventBeginTime  este data și ora la care a început evenimentul.  
eventEndTime  este data și ora la care s-a încheiat evenimentul.  
cardNumberAndGenDriverSlotBegin  identifică cardul introdus în 
slotul pentru cardul de conduc ător auto la începutul evenimentului, 
inclusiv genera ția cardului respectiv.  
cardNumberAndGenDriverSlotEnd  identifică cardul introdus în slotul 
pentru cardul de conduc ător auto la sfâr șitul evenimentului, inclusiv 
generația cardului respectiv.  
cardNumberAndGenCodriverSlotBegin  identifică cardul introdus în 
slotul pentru cardul de copilot la începutul evenimentului, inclusiv 
generația cardului respectiv.  
cardNumberAndGenCodriverSlotEnd  identifică cardul introdus în 
slotul pentru cardul de copilot la sfâr șitul evenimentului, inclusiv 
generația cardului respectiv.  
similarEventsNumber  este num ărul de evenimente similare din ziua 
respectivă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 181  
2.241.  VuPowerSupplyInterruptionRecordArray  
Generația 2:  
Informații, stocate într-o unitate montat ă pe vehicul, privind eveni ­
mentele de întrerupere a aliment ării cu energie electric ă (cerința 117 
din anexa 1C).
  
recordType  reprezintă tipul înregistr ării (VuPowerSupplyInterruptionRe ­
cord). Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  VuPowerSupplyInterruptionRecord  în 
octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări privind evenimentele de întrerupere a 
alimentării cu energie electric ă. 
2.242.  VuSensorExternalGNSSCoupledRecordArray  
Generația 2:  
Un set de  SensorExternalGNSSCoupledRecord , plus metadatele utilizate 
în protocolul de desc ărcare.
  
recordType  reprezintă tipul înregistr ării (SensorExternalGNSSCouple ­
dRecord ). Atribuirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  SensorExternalGNSSCoupledRecord  în 
octeți. 
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări Sensor External GNSS Coupled . 
2.243.  VuSensorPairedRecordArray  
Generația 2:  
Un set de  SensorPairedRecord , plus metadatele utilizate în protocolul de 
descărcare.
  
recordType  reprezintă tipul înregistr ării (SensorPairedRecord ). Atri­
buirea valorii : A se vedea  RecordType  
recordSize  este dimensiunea  SensorPairedRecord  în octeți. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 182  
noOfRecords  este numărul de înregistr ări cuprinse în setul  records . 
records  este un set de înregistr ări privind senzorul asociat.  
3. DEFINIREA INTERVALELOR DE VALORI ȘI DE DIMENSIUNI  
Definiția valorilor variabilelor utilizate în defini țiile de la punctul 2.
  
4. SETURI DE CARACTERE  
IA5Strings  utilizează caracterele ASCII definite în standardul ISO/IEC 
8824-1. În scopul lizibilit ății și pentru a facilita trimiterile, atribuirea 
valorilor este indicat ă în continuare. În caz de discrepan țe, aplicarea 
ISO/IEC 8824-1 are prioritate fa ță de prezenta not ă informativ ă.
 
În alte șiruri de caractere ( Address, Name, VehicleRegistrationNumber ) 
se utilizeaz ă, în plus, caracterele din intervalul zecimal de caractere 161 
– 255 din urm ătoarele seturi standard de caractere de 8 bi ți, specificate 
prin numărul Code Page : 
Set caractere standard  Code Page 
(Zecimal)  
ISO/IEC 8859-1 Latin-1 Western European  1  
ISO/IEC 8859-2 Latin-2 Central European  2  
ISO/IEC 8859-3 Latin-3 South European  3  
ISO/IEC 8859-5 Latin / Cyrillic  5  
ISO/IEC 8859-7 Latin / Greek  7  
ISO/IEC 8859-9 Latin-5 Turkish  9  
ISO/IEC 8859-13 Latin-7 Baltic Rim  13  
ISO/IEC 8859-15 Latin-9  15  
ISO/IEC 8859-16 Latin-10 South Eastern European  16  
KOI8-R Latin / Cyrillic  80  
KOI8-U Latin / Cyrillic  85  
5. CODAREA  
Atunci când sunt codate conform normelor de codare ASN.1, toate 
tipurile de date definite se codeaz ă conform standardului ISO/IEC 
8825-2, varianta aliniat ă. 
6. IDENTIFICATORII DE OBIECT ȘI IDENTIFICATORII DE 
APLICAȚIE 
6.1. Identificatorii de obiect  
Identificatorii de obiect (OID) enumera ți în prezentul capitol sunt 
relevanți numai pentru genera ția 2. Ace ști OID sunt specifica ți în ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 183  
TR-03110-3 și reluați aici din motive de exhaustivitate. Ace ști OID sunt 
cuprinși în subarborele bsi-de:
  
Identificatori ai protocolului de autentificare a VU
  
Exemplu:  Să presupunem c ă autentificarea VU trebuie s ă se realizeze cu 
SHA- 384; atunci identificatorul de obiect care trebuie utilizat este (în nota ție 
ASN.1)
  . 
Valoarea respectivului identificator de obiect în nota ția cu puncte este
  
. 
Notația cu puncte  Nota ția cu octeți
 
‘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’  
Identificatori ai protocolului de autentificare a cipului
  
Exemplu:  Să presupunem c ă autentificarea cipului trebuie efectuat ă prin 
utilizarea algoritmului ECDH, ducând la o lungime a cheii de sesiune 
AES de 128 de bi ți. Această cheie de sesiune va fi folosit ă apoi în 
modul de operare CBC pentru a asigura confiden țialitatea datelor și cu 
algoritmul CMAC pentru a asigura autenticitatea datelor. Prin urmare, 
identificatorul de obiect care trebuie utilizat este (în nota ția ASN.1)
  
. Valoarea 
respectivului identificator de obiect în nota ția cu puncte este
  
. 
Notația cu puncte  Nota ția cu octeți
 
‘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 — RO — 26.02.2020 — 002.001 — 184  
6.2. Identificatorii de aplica ție 
Generația 2:  
Identificatorul de aplica ție (AID) pentru echipamentul GNSS extern 
(generația 2) este dat de ‘FF 44 54 45 47 4D’. Acesta este un AID 
exclusiv în conformitate cu ISO/IEC 7816-4.  
Notă: ultimii 5 octe ți codează DTEGM pentru echipamentul GNSS 
extern pentru tahografe inteligente.  
Identificatorul de aplica ție pentru aplica ția cardului de tahograf de 
generația 2 este dat de ‘FF 53 4D 52 44 54’. Acesta este un AID 
exclusiv în conformitate cu ISO/IEC 7816-4.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 185  
Apendicele 2  
SPECIFICA ȚIE PRIVIND CARDURILE DE TAHOGRAF  
CUPRINS  
1. INTRODUCERE  
1.1. Abrevieri  
1.2. Referin țe 
2. CARACTERISTICI ELECTRICE ȘI FIZICE  
2.1. Tensiunea de alimentare și consumul de curent  
2.2. Tensiunea de programare V  pp 
2.3. Generare și frecvență ceas  
2.4. Contact I/O (intrare/ie șire) 
2.5. St ări ale cardului  
3. HARDWARE ȘI COMUNICA ȚII 
3.1. Introducere  
3.2. Protocolul de transmisie  
3.2.1 Protocoale  
3.2.2 ATR  
3.2.3 PTS  
3.3. Norme de acces  
3.4. Prezentare general ă a comenzilor și a codurilor de eroare  
3.5. Descrierea comenzilor  
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 — RO — 26.02.2020 — 002.001 — 186  
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE  
3.5.15 PSO: VERIFY DIGITAL SIGNATURE  
3.5.16 PROCESS DSRC MESSAGE  
4. STRUCTURA CARDURILOR DE TAHOGRAF  
4.1. Fi șier master  MF 
4.2. Aplica ții de card de conduc ător auto  
4.2.1 Aplica ția de card de conduc ător auto de genera ția 1 
4.2.2 Aplica ția de card de conduc ător auto de genera ția 2 
4.3. Aplica ții de card de atelier  
4.3.1 Aplica ția de card de atelier de genera ția 1 
4.3.2 Aplica ția de card de atelier de genera ția 2 
4.4. Aplica ții de card de control  
4.4.1 Aplica ția de card de control de genera ția 1 
4.4.2 Aplica ția de card de control de genera ția 2 
4.5. Aplica ții de card de societate  
4.5.1 Aplica ția de card de societate de genera ția 1 
4.5.2 Aplica ția de card de societate de genera ția 2 
1. INTRODUCERE  
1.1. Abrevieri  
În sensul prezentului apendice, se aplic ă următoarele abrevieri:  
AC Condi ții de acces  
AES Standard de criptare avansat ă 
AID Identificator de aplica ție 
ALW Întotdeauna  
APDU Unitate de date pentru protocolul de aplica ție (structura 
unei comenzi)  
ATR R ăspuns la resetare  
AUT Autentificat.  
C6, C7 Contactele nr. 6 și 7 de pe card, conform descrierii din 
ISO/IEC 7816-2  
cc cicluri ceas  
▼M1 
CHA Autoriza ția deținătorului certificatului  
▼B 
CHV Informa ții de verificare a titularului cardului  
CLA Octet de clas ă al unei comenzi APDU  
▼M1 
DO Obiect de date  
▼B 
DSRC Comunica ții specializate cu raz ă scurtă de acțiune 
DF Fi șier dedicat. Un DF poate con ține alte fișiere (EF sau 
DF) 
ECC Criptografie bazat ă pe curbe eliptice  
EF Fi șier elementar  
etu unitate elementar ă de timp  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 187  
G1 Genera ția 1 
G2 Genera ția 2 
IC Circuit integrat  
ICC Card cu circuite integrate  
ID Identificator  
IFD Dispozitiv de interfa ță 
IFS Dimensiunea câmpului de informa ții 
IFSC Dimensiunea câmpului de informa ții pentru card  
IFSD Dimensiunea câmpului de informa ții pentru dispozitiv 
(pentru terminal)  
INS Octet de instruc țiuni al unei comenzi APDU  
Lc Lungimea datelor de intrare pentru o comand ă APDU  
Le Lungimea datelor a șteptate (date de ie șire pentru o 
comandă) 
MF Fi șier master  (DF rădăcină) 
NAD Adres ă nod utilizat ă în protocolul T=1  
NEV Niciodat ă 
P1-P2 Octe ți de parametru  
PIN Num ăr de identificare personal  
PRO SM Protejat cu mesagerie securizat ă 
PTS Selectarea protocolului de transmisie  
RFU Rezervat pentru o utilizare viitoare  
RST Resetare (a cardului)  
SFID Identificator de EF scurt  
SM Mesagerie securizat ă 
SW1-SW2 Octe ți de stare  
TS Caracter ini țial ATR  
VPP Tensiune de programare  
VU Unitate montat ă pe vehicul  
XXh Valoare XX în nota ție hexadecimal ă 
‘XXh’ Valoare XX în nota ție hexadecimal ă 
|| Simbol de concatenare 03||04=0304  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 188  
1.2. Referin țe 
În prezentul apendice se utilizeaz ă următoarele referin țe: 
ISO/IEC 7816-2  Identification cards  – Integrated circuit cards  – 
Part 2: Dimensions and location of the contacts . 
ISO/IEC 7816-2:2007.  
ISO/IEC 7816-3  Identification cards  – Integrated circuit cards  – 
Part 3: Electrical interface and transmission 
protocols . ISO/IEC 7816-3:2006.  
ISO/IEC 7816-4  Identification cards  – Integrated circuit cards  – 
Part 4: Organization, security and commands for 
interchange . ISO/IEC 7816-4:2013 + Cor 1: 2014.  
ISO/IEC 7816-6  Identification cards  – Integrated circuit cards  – 
Part 6: Interindustry data elements for inter ­
change.  ISO/IEC 7816-6:2004 + Cor 1: 2006.  
ISO/IEC 7816-8  Identification cards  – Integrated circuit cards  – 
Part 8: Commands for security operations.  
ISO/IEC 7816-8:2004.  
ISO/IEC 9797-2  Information technology  – Security techniques  – 
Message Authentication Codes (MACs)  – Part 2: 
Mechanisms using a dedicated hash-function.  
ISO/IEC 9797-2:2011  
2. CARACTERISTICI ELECTRICE ȘI FIZICE  
TCS_01 Toate semnalele electronice trebuie s ă fie conforme cu 
ISO/IEC 7816-3, cu excep ția cazului în care se specific ă 
altfel.  
TCS_02 Localizarea și dimensiunile contactelor cardului trebuie s ă 
fie conforme cu ISO/IEC 7816-2.  
2.1. Tensiunea de alimentare și consumul de curent  
TCS_03 Cardul trebuie s ă funcționeze conform specifica țiilor în 
limitele de consum prev ăzute în ISO/IEC 7816-3.  
TCS_04 Cardul trebuie s ă funcționeze cu Vcc = 3V (± 0,3V) sau cu 
Vcc = 5V (± 0,5V).  
Selectarea tensiunii trebuie s ă se facă în conformitate cu 
ISO/IEC 7816-3.  
2.2. Tensiunea de programare V  pp 
TCS_05 Cardul trebuie s ă nu necesite o tensiune de programare la 
contactul C6. Se prevede ca acest contact C6 s ă nu fie 
conectat într-un IFD. Contactul C6 poate fi conectat la 
V cc în card, dar trebuie s ă nu fie conectat la mas ă. 
Această tensiune nu ar trebui interpretat ă în niciun caz.  
2.3. Generare și frecven ță ceas  
TCS_06 Cardul trebuie s ă funcționeze într-un interval de frecven ță 
de la 1 la 5 MHz și poate suporta frecven țe mai mari. Într-o 
sesiune de lucru cu cardul, frecven ța ceasului poate varia cu 
±2 %. Frecven ța ceasului este generat ă de unitatea montat ă 
pe vehicul și nu de cardul în sine. Factorul de utilizare 
poate varia între 40 și 60 %.  
TCS_07 Ceasul extern poate fi oprit în condi țiile cuprinse în fi șierul 
de card EF ICC. Primul octet din corpul fi șierului EF ICC 
codează condițiile pentru modul „Clockstop”:  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 189  
Scăzut Ridicat  
Bit 3  Bit 2  Bit 1  
0 0  1  Clockstop  permis, fără nivel preferat  
0 1  1  Clockstop  permis, nivel ridicat preferat  
1 0  1  Clockstop  permis, nivel sc ăzut preferat  
0 0  0  Clockstop  nepermis  
0 1  0  Clockstop  permis doar la nivel ridicat  
1 0  0  Clockstop  permis doar la nivel sc ăzut 
Biții 4-8 nu sunt utiliza ți. 
2.4. Contact I/O (intrare/ie șire) 
TCS_08 Contactul I/O C7 este utilizat pentru recep ționarea datelor 
de la IFD și pentru transmiterea datelor c ătre IFD. În cursul 
funcționării, doar cardul sau doar IFD trebuie s ă fie în mod 
de transmisie. Dac ă ambele unit ăți sunt în mod de trans ­
misie, cardul trebuie s ă nu sufere nicio deteriorare. Cu 
excepția cazului în care transmite, cardul trebuie s ă intre 
automat în mod de recep ție. 
2.5. St ări ale cardului  
TCS_09 Cardul prezint ă două stări atunci când se afl ă sub tensiunea 
de alimentare:  
Starea de func ționare, atunci când execut ă comenzi sau 
interfațează cu unitatea digital ă, 
Starea de repaus, în toate celelalte momente; în aceast ă 
stare, toate datele sunt re ținute de card.  
3. HARDWARE ȘI COMUNICA ȚII 
3.1. Introducere  
Prezentul punct descrie func ționalitatea minim ă necesară pentru 
cardurile de tahograf și VU în vederea asigur ării unei func ționări 
corecte și a interoperabilit ății. 
Cardurile de tahograf sunt conforme, în cea mai mare m ăsură posibilă, 
cu standardele disponibile ISO/IEC aplicabile (în special ISO/IEC 
7816). Cu toate acestea, comenzile și protocoalele sunt descrise 
integral pentru a specifica anumite utiliz ări limitate sau anumite dife ­
rențe, dacă acestea exist ă. Comenzile specificate sunt conforme pe 
deplin cu normele la care se face trimitere, cu excep ția cazurilor 
indicate.  
3.2. Protocolul de transmisie  
TCS_10 Protocolul de transmisie trebuie s ă fie conform cu ISO/IEC 
7816-3 pentru T=0 și T=1. În special, VU trebuie s ă recu­
noască prelungirile duratei de a șteptare transmise de card.  
3.2.1  Protocoale  
TCS_11 Cardul trebuie s ă ofere atât protocolul  T=0 , cât și 
protocolul  T=1 . În plus, cardul poate fi compatibil și cu 
alte protocoale orientate pe contact.  
TCS_12  T=0  este protocolul implicit, prin urmare este necesar ă o 
comandă PTS  pentru schimbarea protocolului în  T=1 . ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 190  
TCS_13 Dispozitivele trebuie s ă fie compatibile cu  conven ția 
directă în ambele protocoale: prin urmare, conven ția 
directă este obligatorie pentru card.  
TCS_14 ATR trebuie s ă conțină, în caracterul TA3, octetul privind  
dimensiunea câmpului de informa ții pentru card . 
Această valoare trebuie s ă fie de cel pu țin ‘F0h’ (= 240 
de octeți). 
Protocoalele sunt supuse urm ătoarelor restric ții: 
TCS_15  T=0  
— dispozitivul de interfa ță trebuie să fie compatibil cu un 
răspuns la intrare/ie șire după partea ascendent ă a 
semnalului în RST plecând de la 400 cc;  
— dispozitivul de interfa ță trebuie să poată citi caractere 
separate de 12 etu;  
— dispozitivul de interfa ță trebuie să citească un caracter 
eronat și repetiția acestuia dac ă sunt separate de 13 etu. 
Dacă este detectat un caracter eronat, semnalul de 
eroare la intrare/ie șire poate ap ărea între 1 etu și 2 
etu. Dispozitivul trebuie s ă fie compatibil cu o 
întârziere de 1 etu;  
— dispozitivul de interfa ță trebuie să accepte un ATR de 
33 de octe ți (TS+32);  
— dacă ATR con ține TC1, trebuie s ă fie prezent „Extra 
Guard Time” (timpul suplimentar de gard ă) pentru 
caracterele transmise de c ătre dispozitivul de interfa ță, 
deși caracterele transmise de card pot fi totu și separate 
de 12 etu. Acest lucru este valabil și pentru caracterul 
ACK transmis de card dup ă un caracter P3 emis de 
dispozitivul de interfa ță; 
— dispozitivul de interfa ță trebuie s ă țină cont de un 
caracter NUL emis de card;  
— dispozitivul de interfa ță trebuie s ă accepte modul 
complementar pentru ACK;  
— comanda „get-response” (ob ține un răspuns) nu poate fi 
utilizată în modul de înl ănțuire pentru a ob ține date a 
căror lungime ar putea dep ăși 255 de octe ți. 
TCS_16  T=1  
— octet NAD: neutilizat (NAD se seteaz ă la ‘00’);  
— S-block ABORT : neutilizat;  
— S-block VPP state error : neutilizat;  
— lungimea total ă de înlănțuire pentru un câmp de date nu 
va depăși 255 de octe ți (cerință care trebuie asigurat ă de 
IFD);  
— dimensiunea câmpului de informa ții pentru dispozitiv 
(Information Field Size Device  – IFSD) trebuie 
indicată de IFD imediat dup ă ATR: IFD transmite soli ­
citarea  S-Block IFS  după ATR, iar cardul r ăspunde 
transmițând S-Block IFS . Valoarea recomandat ă pentru 
IFSD este de 254 de octe ți; 
— cardul nu va solicita o reajustare a IFS.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 191  
3.2.2  ATR  
TCS_17 Dispozitivul verific ă octeții ATR, în conformitate cu 
ISO/IEC 7816-3. Nu se face nicio verificare cu privire la 
caracterele istorice ale ATR.  
Exemplu de biprotocol de baz ă ATR conform ISO/IEC 
7816-3  
Caracter  Valoare  Observa ții 
TS ‘3Bh’  Indic ă convenție directă. 
T0 ‘85h’  TD1 prezent; 5 octe ți istorici sunt prezen ți. 
TD1 ‘80h’  TD2 prezent; trebuie folosit T=0  
TD2 ‘11h’  TA3 prezent; trebuie folosit T=1  
TA3 ‘XXh’ (cel pu țin 
‘F0h’)  Dimensiunea câmpului de informa ții pentru card 
(IFSC)  
TH1-TH5  ‘XXh’  Caractere istorice  
TCK  ‘XXh’  Verificare caracter (SAU exclusiv)  
TCS_18 Dup ă „Answer To Reset” (ATR), fi șierul master  (MF) este 
selectat implicit și devine directorul curent.  
3.2.3  PTS  
TCS_19 Protocolul implicit este T=0. Pentru a seta protocolul T=1, 
dispozitivul trebuie s ă transmită cardului o comand ă PTS 
(cunoscută și ca PPS).  
TCS_20 Întrucât protocoalele T=0 și T=1 sunt ambele obligatorii 
pentru card, PTS de baz ă pentru schimbarea protocolului 
este obligatorie pentru card.  
PTS poate fi utilizat ă, conform indica țiilor din ISO/IEC 
7816-3, pentru a trece la rate de modula ție mai mari 
decât cea implicit ă propusă de card în ATR, dac ă există 
o astfel de rat ă implicită [octetul TA(1)].  
Ratele de modula ție mai mari sunt op ționale pentru card.  
TCS_21 În cazul în care cardul nu este compatibil cu alte rate de 
modulație decât rata implicit ă (sau dacă nu este compatibil 
cu rata de modula ție selectată), cardul trebuie s ă răspundă 
la PTS în mod corect, în conformitate cu ISO/IEC 7816-3, 
omițând octetul PPS1.  
Următoarele sunt exemple de PTS de baz ă pentru selectarea 
protocolului:  
Caracter  Valoare  Observa ții 
PPSS  ‘FFh’  Caracterul de ini țializare („The Initiate Character”).  
PPS0  ‘00h’ sau ‘01h’  PPS1-PPS3 nu sunt prezente; ‘00h’ pentru a selecta T0, ‘01h’ 
pentru a selecta T1.  
PK ‘XXh’  Verificare caracter („Check character”): ‘XXh’ = ‘FFh’ dac ă 
PPS0 = ‘00h’, 
‘XXh’ = ‘FEh’ dac ă 
PPS0 = ‘01h’.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 192  
3.3. Norme de acces  
TCS_22 O norm ă de acces specific ă pentru un mod de acces, și 
anume o comand ă, condițiile de securitate corespunz ătoare. 
Dacă aceste condi ții de securitate sunt îndeplinite, comanda 
corespunzătoare este prelucrat ă. 
TCS_23 Urm ătoarele condi ții de securitate sunt utilizate pentru 
cardul de tahograf:  
Abreviere  Sens  
ALW  Ac țiunea este posibil ă întotdeauna și poate fi executat ă fără nicio restric ție. 
APDU de comand ă și de răspuns sunt transmise ca text în clar, adic ă fără 
mesagerie securizat ă. 
NEV  Ac țiunea nu este posibil ă niciodată. 
PLAIN-C  APDU de comand ă este transmis ă ca text în clar, adic ă fără mesagerie secu ­
rizată. 
PWD  Ac țiunea poate fi executat ă numai dac ă PIN-ul cardului de atelier a fost 
verificat cu succes, și anume dac ă este stabilit ă starea de securitate intern ă 
„PIN_Verified” a cardului. Comanda trebuie transmis ă fără mesagerie securi ­
zată. 
EXT-AUT-G1  Acțiunea poate fi executat ă numai în cazul în care comanda „External Authen ­
ticate” (autentificare extern ă) pentru autentificarea de genera ția 1 (a se vedea, 
de asemenea, apendicele 11 partea A) a fost executat ă cu succes.  
SM-MAC-G1  APDU (comand ă și răspuns) trebuie s ă fie aplicat ă cu mesagerie securizat ă de 
generația 1 în mod doar de autentificare (a se vedea apendicele 11 partea A).  
SM-C-MAC-G1  APDU de comand ă trebuie să fie aplicat ă cu mesagerie securizat ă de generația 
1 în mod doar de autentificare (a se vedea apendicele 11 partea A).  
SM-R-ENC-G1  APDU de r ăspuns trebuie s ă fie aplicat ă cu mesagerie securizat ă de genera ția 
1 în mod de criptare (a se vedea apendicele 11 partea A), și anume nu se 
returnează niciun cod de autentificare a mesajului.  
SM-R-ENC- 
MAC-G1  APDU de r ăspuns trebuie s ă fie aplicat ă cu mesagerie securizat ă de genera ția 
1 în mod de criptare apoi autentificare (a se vedea apendicele 11 partea A).  
SM-MAC-G2  APDU (comand ă și răspuns) trebuie s ă fie aplicat ă cu mesagerie securizat ă de 
generația 2 în mod doar de autentificare (a se vedea apendicele 11 partea B).  
SM-C-MAC-G2  APDU de comand ă trebuie să fie aplicat ă cu mesagerie securizat ă de generația 
2 în mod doar de autentificare (a se vedea apendicele 11 partea B).  
SM-R-ENC- 
MAC-G2  APDU de r ăspuns trebuie s ă fie aplicat ă cu mesagerie securizat ă de genera ția 
2 în mod de criptare apoi autentificare (a se vedea apendicele 11 partea B).  
▼M1 
TCS_24 Aceste condi ții de securitate pot fi conectate în urm ătoarele 
moduri:  
ȘI: Trebuie îndeplinite toate condi țiile de securitate  
SAU: Trebuie îndeplinit ă cel puțin o condi ție de securitate  
Normele de acces pentru sistemul de fi șiere, și anume 
comanda SELECT, READ BINARY și UPDATE 
BINARY, sunt specificate în capitolul 4. Normele de 
acces pentru restul comenzilor sunt specificate în tabelele 
de mai jos. Termenul „nu se aplic ă” este utilizat în cazul în 
care nu exist ă nicio cerin ță compatibil ă cu comanda. În 
acest caz, comanda poate sau nu s ă fie compatibil ă, dar 
condiția de acces este în afara sferei de aplicare.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 193  
TCS_25 În aplica ția DF Tachograph G1 se utilizeaz ă următoarele 
norme de acces:  
▼M1 
Comandă Card de 
conducător auto  Card de atelier  Card de control  Card de 
societate  
External Authenticate  
— Pentru autentificarea de 
generația 1 ALW  ALW  ALW  ALW  
— Pentru autentificarea de 
generația 2 ALW  PWD  ALW  ALW  
Internal Authenticate  ALW  PWD  ALW  ALW  
General Authenticate  ALW  ALW  ALW  ALW  
Get Challenge  ALW  ALW  ALW  ALW  
MSE:SET AT  ALW  ALW  ALW  ALW  
MSE:SET DST  ALW  ALW  ALW  ALW  
Process DSRC Message  Nu se aplic ă Nu se aplic ă Nu se aplic ă Nu se aplic ă 
PSO: Compute Digital Signature  ALW SAU 
SM-MAC- 
G2 ALW SAU 
SM-MAC- 
G2 Nu se aplic ă Nu se aplic ă 
PSO: Hash  Nu se aplic ă Nu se aplic ă ALW  Nu se aplic ă 
PERFORM HASH of FILE  ALW SAU 
SM-MAC- 
G2 ALW SAU 
SM-MAC- 
G2 Nu se aplic ă Nu se aplic ă 
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Nu se aplic ă Nu se aplic ă ALW  Nu se aplic ă 
Verify  Nu se aplic ă ALW  Nu se aplic ă Nu se aplic ă 
▼B 
TCS_26 În aplica ția DF Tachograph_G2 se utilizeaz ă următoarele 
norme de acces:  
▼M1 
Comandă Card de 
conducător auto  Card de atelier  Card de control  Card de 
societate  
External Authenticate  
— Pentru autentificarea de 
generația 1 Nu se aplic ă Nu se aplic ă Nu se aplic ă Nu se aplic ă 
— Pentru autentificarea de 
generația 2 ALW  PWD  ALW  ALW  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 194  
Comandă Card de 
conducător auto  Card de atelier  Card de control  Card de 
societate  
Internal Authenticate  Nu se aplic ă Nu se aplic ă Nu se aplic ă Nu se aplic ă 
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  Nu se aplic ă ALW  ALW  Nu se aplic ă 
PSO: Compute Digital Signature  ALW SAU 
SM-MAC- 
G2 ALW SAU 
SM-MAC- 
G2 Nu se aplic ă Nu se aplic ă 
PSO: Hash  Nu se aplic ă Nu se aplic ă ALW  Nu se aplic ă 
PERFORM HASH of FILE  ALW SAU 
SM-MAC- 
G2 ALW SAU 
SM-MAC- 
G2 Nu se aplic ă Nu se aplic ă 
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Nu se aplic ă Nu se aplic ă ALW  Nu se aplic ă 
Verify  Nu se aplic ă ALW  Nu se aplic ă Nu se aplic ă 
▼B 
TCS_27 În MF se utilizeaz ă următoarele norme de acces:  
▼M1 
Comandă Card de 
conducător auto  Card de atelier  Card de control  Card de 
societate  
External Authenticate  
— Pentru autentificarea de 
generația 1 Nu se aplic ă Nu se aplic ă Nu se aplic ă Nu se aplic ă 
— Pentru autentificarea de 
generația 2 ALW  PWD  ALW  ALW  
Internal Authenticate  Nu se aplic ă Nu se aplic ă Nu se aplic ă Nu se aplic ă 
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 — RO — 26.02.2020 — 002.001 — 195  
Comandă Card de 
conducător auto  Card de atelier  Card de control  Card de 
societate  
Process DSRC Message  Nu se aplic ă Nu se aplic ă Nu se aplic ă Nu se aplic ă 
PSO: Compute Digital Signature  Nu se aplic ă Nu se aplic ă Nu se aplic ă Nu se aplic ă 
PSO: Hash  Nu se aplic ă Nu se aplic ă Nu se aplic ă Nu se aplic ă 
PERFORM HASH of FILE  Nu se aplic ă Nu se aplic ă Nu se aplic ă Nu se aplic ă 
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Nu se aplic ă Nu se aplic ă Nu se aplic ă Nu se aplic ă 
Verify  Nu se aplic ă ALW  Nu se aplic ă Nu se aplic ă 
▼B 
TCS_28 Un card de tahograf poate sau nu s ă accepte o comand ă cu 
un nivel de securitate mai ridicat decât cel specificat în 
condițiile de securitate. Cu alte cuvinte, în cazul în care 
condiția de securitate este ALW (sau PLAIN-C) cardul 
poate accepta o comand ă cu mesagerie securizat ă (mod 
de criptare și/sau de autentificare). În cazul în care 
condiția de securitate impune utilizarea de mesagerie secu ­
rizată cu mod de autentificare, cardul de tahograf poate 
accepta o comand ă cu mesagerie securizat ă din aceea și 
generație în mod de autentificare și de criptare.  
Notă: descrierile comenzilor ofer ă mai multe informa ții cu 
privire la compatibilitatea comenzilor cu diferitele tipuri de 
card de tahograf și cu diferitele DF.  
3.4. Prezentare general ă a comenzilor și a codurilor de eroare  
Comenzile și organizarea fi șierelor sunt derivate din ISO/IEC 7816-4 
și sunt conforme cu acest standard.  
Prezenta sec țiune descrie perechile de comand ă-răspuns APDU 
menționate în cele ce urmeaz ă. Variantele de comand ă care sunt 
compatibile cu o aplica ție de genera ția 1 și 2 sunt specificate în 
descrierile corespunz ătoare ale comenzilor.  
Comandă INS  
SELECT  ‘A4h’  
READ BINARY  ‘B0h’, ‘B1h’  
UPDATE BINARY  ‘D6h’, ‘D7h’  
GET CHALLENGE  ‘84h’  
VERIFY  ‘20h’  
GET RESPONSE  ‘C0h’  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 196  
Comandă INS  
PERFORM SECURITY OPERATION  ‘2Ah’  
— VERIFY CERTIFICATE  
— COMPUTE DIGITAL SIGNATURE  
— VERIFY DIGITAL SIGNATURE  
— HASH  
— PERFORM HASH OF FILE  
— PROCESS DSRC MESSAGE  
INTERNAL AUTHENTICATE  ‘88h’  
EXTERNAL AUTHENTICATE  ‘82h’  
MANAGE SECURITY ENVIRONMENT  ‘22h’  
— SET DIGITAL SIGNATURE TEMPLATE  
— SET AUTHENTICATION TEMPLATE  
GENERAL AUTHENTICATE  ‘86h’  
▼M1 
TCS_29 Cuvintele de stare SW1 SW2 sunt returnate în orice mesaj 
de răspuns și indică starea de procesare a comenzii.  
SW1  SW2  Sens  
90 00  Procesare normal ă. 
61 XX  Procesare normal ă. XX = num ărul de octe ți de răspuns disponi ­
bili. 
62 81  Procesare de avertizare. Este posibil ca o parte dintre datele 
returnate s ă fie corupte  
63 00  Autentificare e șuată (avertizare)  
63 CX  CHV (PIN) eronat. Num ărul încercărilor rămase este dat de „X”.  
64 00  Eroare de execu ție – Starea memoriei nevolatile nu s-a modificat. 
Eroare de integritate.  
65 00  Eroare de execu ție – Starea memoriei nevolatile s-a modificat.  
65 81  Eroare de execu ție – Starea memoriei nevolatile s-a modificat – 
Eroare de memorie  
66 88  Eroare de securitate: sum ă de verificare criptografic ă eronată 
(în cursul mesageriei securizate) sau 
certificat eronat (în cursul verific ării certi­
ficatului) sau 
criptogram ă eronată (în cursul autenti ­
ficării externe) sau 
semnătură eronată (în cursul verific ării 
semnăturii) ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 197  
SW1  SW2  Sens  
67 00  Lungime eronat ă (Lc sau Le eronat ă) 
68 83  Se a șteaptă ultima comand ă din lanț 
69 00  Comand ă interzisă (niciun răspuns disponibil în T = 0)  
69 82  Starea de securitate nu este îndeplinit ă. 
69 83  Metoda de autentificare este blocat ă. 
69 85  Condi țiile de utilizare nu sunt satisf ăcute.  
69 86  Comand ă nepermisă (niciun EF curent)  
69 87  Obiectele de date a șteptate din mesageria securizat ă lipsesc  
69 88  Obiectele de date din mesageria securizat ă sunt incorecte  
6A 80  Parametri incorec ți în câmpul de date  
6A 82  Fișierul nu a fost g ăsit. 
6A 86  Parametrii P1-P2 erona ți. 
6A 88  Datele men ționate nu pot fi g ăsite. 
6B 00  Parametri erona ți (deplasare în afara EF).  
6C XX  Lungime eronat ă, SW2 indic ă lungimea exact ă. Nu este returnat 
niciun câmp de date.  
6D 00  Cod de instruc țiuni incompatibil sau invalid.  
6E 00  Clas ă incompatibil ă. 
6F 00  — Alte erori de verificare.  
Pot fi returnate cuvinte de stare suplimentare, astfel cum 
sunt definite în ISO/IEC 7816-4, în cazul în care compor ­
tamentul acestora nu este men ționat în mod explicit în 
prezentul apendice.  
De exemplu, urm ătoarele cuvinte de stare pot fi returnate 
opțional:  
6881: Incompatibilitate cu canalul logic  
6882: Incompatibilitate cu mesageria securizat ă 
▼B 
TCS_30 Dac ă într-o APDU de comand ă este îndeplinit ă mai mult de 
o condiție de eroare, cardul poate returna oricare dintre 
cuvintele de stare corespunz ătoare.  
3.5. Descrierea comenzilor  
Prezentul capitol descrie comenzile obligatorii pentru cardurile de 
tahograf.  
Detalii suplimentare pertinente cu privire la opera țiunile criptografice 
implicate se g ăsesc în apendicele 11 Mecanisme de securitate comune 
pentru genera ția 1 și generația 2 de tahografe.  
Toate comenzile sunt descrise independent de protocolul utilizat (T=0 
sau T=1). Octe ții APDU CLA, INS, P1, P2, Lc și Le sunt întotdeauna 
indicați. Dacă Lc sau Le nu sunt necesare pentru comanda descris ă, 
lungimea, valoarea și descrierea aferente sunt vide.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 198  
TCS_31 Dac ă sunt solicita ți ambii octe ți de lungime (Lc și Le), 
comanda descris ă trebuie să fie separat ă în două părți în 
cazul în care IFD utilizeaz ă protocolul T=0: IFD transmite 
comanda conform descrierii cu P3=Lc + date și apoi 
transmite o comand ă GET RESPONSE (a se vedea 
secțiunea 3.5.6) cu P3=Le.  
TCS_32 Dac ă sunt solicita ți ambii octe ți de lungime, iar Le=0 
(mesagerie securizat ă): 
— atunci când se utilizeaz ă protocolul T=1, cardul trebuie 
să răspundă la Le=0 prin transmiterea tuturor datelor de 
ieșire disponibile;  
— atunci când se utilizeaz ă protocolul T=0, IFD trebuie s ă 
transmită prima comand ă cu P3=Lc + date, iar cardul 
trebuie să răspundă (la aceast ă valoare implicit ă Le=0) 
cu octeții de stare ‘ 61La ’, unde La este num ărul de 
octeți de răspuns disponibili. IFD trebuie s ă genereze 
apoi o comand ă GET RESPONSE cu P3 = La, pentru a 
citi datele.  
TCS_33 Un card de tahograf poate fi compatibil cu câmpuri cu 
lungime extins ă în conformitate cu ISO/IEC 7816-4, ca o 
caracteristic ă opțională. Un card de tahograf care este 
compatibil cu câmpuri cu lungime extins ă trebuie:  
— să indice compatibilitatea cu câmpurile cu lungime 
extinsă în ATR;  
— să furnizeze dimensiunile zonei tampon compatibile 
prin intermediul informa ției privind lungimea extins ă 
în EF ATR/INFO, a se vedea TCS_146;  
— să indice dac ă este compatibil cu câmpuri cu lungime 
extinsă pentru T = 1 și/sau T = 0 în EF  Extended 
Length , a se vedea TCS_147;  
— să fie compatibil cu câmpuri cu lungime extins ă pentru 
generația 1 și 2 de aplica ții tahografice.  
Note:  
Toate comenzile sunt specificate pentru câmpuri cu o 
lungime redus ă. Utilizarea APDU-urilor cu lungime 
extinsă rezultă clar din ISO/IEC 7816-4.  
În general, comenzile sunt specificate pentru scrierea în 
clar, adică fără mesagerie securizat ă, nivelul de mesagerie 
securizată fiind specificat în apendicele 11. Din normele de 
acces pentru o comand ă rezultă în mod clar dac ă respectiva 
comandă trebuie să fie compatibil ă cu mesageria securizat ă 
sau nu și dacă respectiva comand ă trebuie să fie compa ­
tibilă cu genera ția 1 și/sau genera ția 2 de mesagerie secu ­
rizată. Unele variante de comand ă sunt descrise incluzând 
mesageria securizat ă, pentru a ilustra utilizarea mesageriei 
securizate.  
TCS_34 VU trebuie s ă execute întregul protocol de autentificare 
reciprocă VU – card de genera ția 2 pentru o sesiune 
incluzând verificarea certificatului (dac ă este necesar), fie 
în DF Tachograph, fie în DF Tachograph_G2, fie în MF.  
3.5.1  SELECT  
Această comandă respectă ISO/IEC 7816-4, dar are o utilizare 
restricționată comparativ cu comanda definit ă în standard.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 199  
Comanda SELECT se utilizeaz ă: 
— pentru a selecta un DF de aplica ție (trebuie utilizat ă selectarea 
după denumire);  
— pentru a selecta un fi șier elementar corespunz ător ID-ului fi șierului 
prezentat.  
3.5.1.1 S e l e c t a r e d u p ă d e n u m i r e ( A I D )  
Această comandă permite selectarea unui DF de aplica ție din card.  
TCS_35 Aceast ă comandă poate fi executat ă din orice parte din 
structura fi șierelor (dup ă ATR sau în orice moment).  
TCS_36 Selectarea unei aplica ții reseteaz ă mediul de securitate 
curent. Dup ă ce s-a efectuat selectarea aplica ției, nu mai 
este selectat ă nicio cheie public ă curentă. De asemenea, se 
pierde condi ția de acces EXT-AUT-G1. În cazul în care 
comanda a fost executat ă fără mesagerie securizat ă, cheile 
de sesiune anterioare ale mesageriei securizate nu mai sunt 
disponibile.  
TCS_37  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘A4h’  
P1 1  ‘04h’  Selectare dup ă denumire (AID)  
P2 1  ‘0Ch’  Nu se a șteaptă niciun răspuns  
Lc 1  ‘NNh’  Num ărul de octe ți transmiși către card (lungimea AID): 
‘06h’ pentru aplica ția tahografic ă 
#6-#(5+NN)  NN  ‘XX..XXh’  AID: ‘FF 54 41 43 48 4F’ pentru aplica ția tahografic ă de 
generația 1 
AID: ‘FF 53 4D 52 44 54’ pentru aplica ția tahografic ă 
de generația 2 
Nu este necesar niciun r ăspuns la comanda SELECT (Le 
absentă în T=1 sau nu se solicit ă niciun răspuns în T=0).  
TCS_38  Mesaj de r ăspuns (nu se solicit ă niciun r ăspuns)  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă aplicația corespunz ătoare AID nu este g ăsită, 
starea de procesare returnat ă este ‘ 6A82 ’. 
— În T=1, dac ă este prezent octetul Le, starea returnat ă 
este ‘ 6700 ’. 
— În T=0, dac ă se solicit ă un răspuns dup ă comanda 
SELECT, starea returnat ă este ‘ 6900 ’. 
▼M1 
— Dacă aplicația selectată este considerat ă coruptă (în atri­
butele fișierului este detectat ă o eroare de integritate), 
starea de procesare returnat ă este ‘ 6400 ’ sau ‘ 6500 ’. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 200  
3.5.1.2 S e l e c t a r e a u n u i f i ș i e r e l e m e n t a r f o l o s i n d i d e n t i ­
f i c a t o r u l d e f i ș i e r a l a c e s t u i a  
TCS_39  Mesaj de comand ă 
TCS_40 Un card de tahograf trebuie s ă fie compatibil cu mesageria 
securizată de genera ția 2 conform specifica țiilor din apen ­
dicele 11 partea B pentru aceast ă variantă de comand ă. 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘A4h’  
P1 1  ‘02h’  Selectarea unui EF din DF curent  
P2 1  ‘0Ch’  Nu se a șteaptă niciun răspuns  
Lc 1  ‘02h’  Num ărul de octe ți transmiși către card  
#6-#7  2  ‘XXXXh’  Identificatorul fi șierului  
Nu este necesar niciun r ăspuns la comanda SELECT (Le 
absentă în T=1 sau nu se solicit ă niciun răspuns în T=0).  
TCS_41  Mesaj de r ăspuns (nu se solicit ă niciun r ăspuns)  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă fișierul corespunz ător identificatorului de fi șier nu 
este găsit, starea de procesare returnat ă este ‘ 6A82 ’. 
— În T=1, dac ă este prezent octetul Le, starea returnat ă 
este ‘ 6700 ’. 
— În T=0, dac ă se solicit ă un răspuns dup ă comanda 
SELECT, starea returnat ă este ‘ 6900 ’. 
▼M1 
— Dacă fișierul selectat este considerat corupt (în atri ­
butele fișierului este detectat ă o eroare de integritate), 
starea de procesare returnat ă este ‘ 6400 ’ sau ‘ 6500 ’. 
▼B 
3.5.2  READ BINARY  
Această comandă respectă ISO/IEC 7816-4, dar are o utilizare 
restricționată comparativ cu comanda definit ă în standard.  
Comanda READ BINARY se utilizeaz ă pentru citirea datelor dintr-un 
fișier transparent.  
Răspunsul cardului const ă în returnarea datelor citite, încapsulate 
opțional într-o structur ă de mesagerie securizat ă. 
3.5.2.1 C o m a n d ă c u d e p l a s a r e î n P 1 - P 2  
Această comandă permite IFD s ă citească datele din EF-ul selectat în 
momentul respectiv, f ără mesagerie securizat ă. 
Notă: Această comandă fără mesagerie securizat ă poate fi utilizat ă 
numai pentru a citi un fi șier care este compatibil cu condi ția de 
securitate ALW pentru modul de acces de citire („read”).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 201  
TCS_42  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘B0h’  Citire date ( Read Binary ) 
P1 1  ‘XXh’  Deplasare octe ți de la începutul fi șierului: cel mai semni ­
ficativ octet  
P2 1  ‘XXh’  Deplasare octe ți de la începutul fi șierului: cel mai pu țin 
semnificativ octet  
Le 1  ‘XXh’  Lungimea datelor a șteptate. Num ărul de octe ți de citit.  
Notă: bitul 8 al P1 trebuie setat la 0.  
TCS_43  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
#1-#X  X  ‘XX..XXh’  Date citite  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă nu este selectat niciun EF, starea de procesare 
returnată este ‘ 6986 ’. 
— Dacă nu sunt îndeplinite condi țiile de securitate pentru 
fișierul selectat, comanda este întrerupt ă cu ‘ 6982 ’. 
— Dacă deplasarea nu este compatibil ă cu dimensiunea EF 
(Deplasare > dimensiune EF), starea de procesare 
returnată este ‘ 6B00 ’. 
— Dacă dimensiunea datelor de citit nu este compatibil ă 
cu dimensiunea EF (Deplasare + Le > dimensiune EF), 
starea de procesare returnat ă este ‘ 6700 ’ sau ‘ 6Cxx ’, 
unde ‘xx’ indic ă lungimea exact ă. 
▼M1 
— Dacă în atributele fi șierului este detectat ă o eroare de 
integritate, cardul trebuie s ă considere fi șierul ca fiind 
corupt și irecuperabil, iar starea de procesare returnat ă 
este ‘ 6400 ’ sau ‘ 6500 ’. 
▼B 
— Dacă în datele stocate este detectat ă o eroare de inte ­
gritate, cardul trebuie s ă returneze datele solicitate, iar 
starea de procesare returnat ă este ‘ 6281 ’. 
3.5.2.1.1 C o m a n d ă c u m e s a g e r i e s e c u r i z a t ă ( e x e m p l e )  
Această comandă permite IFD s ă citească date din EF-ul selectat în 
momentul respectiv, cu mesagerie securizat ă, pentru a verifica inte ­
gritatea datelor primite și pentru a proteja confiden țialitatea datelor în 
cazul în care este aplicat ă condiția de securitate SM-R-ENC-MAC-G1 
(generația 1) sau SM-R-ENC-MAC-G2 (genera ția 2).  
TCS_44  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘0Ch’  Mesagerie securizat ă solicitată 
INS 1  ‘B0h’  Citire date ( Read Binary ) ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 202  
Octet  Lungime  Valoare  Descriere  
P1 1  ‘XXh’  P1 (deplasare octe ți de la începutul fi șierului): cel mai 
semnificativ octet  
P2 1  ‘XXh’  P2 (deplasare octe ți de la începutul fi șierului): cel mai 
puțin semnificativ octet  
Lc 1  ‘XXh’  Lungimea datelor de intrare pentru mesageria securizat ă 
#6 1  ‘97h’  T  LE : etichetă pentru specifica ția lungimii a șteptate.  
#7 1  ‘01h’  L  LE : lungimea lungimii a șteptate  
#8 1  ‘NNh’  Specifica ția lungimii a șteptate (Le original ă): numărul de 
octeți de citit  
#9 1  ‘8Eh’  T  CC : etichetă pentru suma de verificare criptografic ă 
#10 1  ‘XXh’  L  CC : lungimea sumei de verificare criptografice 
următoare 
‘04h’ pentru mesageria securizat ă de genera ția 1 (a se 
vedea apendicele 11 partea A) 
‘08h’, ‘0Ch’ sau ‘10h’, în func ție de lungimea cheii AES 
pentru mesageria securizat ă de genera ția 2 (a se vedea 
apendicele 11 partea B)  
#11-#(10 + L)  L  ‘XX..XXh’  Sumă de verificare criptografic ă 
Le 1  ‘00h’  Conform specifica țiilor din ISO/IEC 7816-4  
TCS_45  Mesaj de r ăspuns dac ă SM-R-ENC-MAC-G1 (genera ția 
1) / SM-R-ENC-MAC-G2 (genera ția 2) nu este necesar ă 
și dacă formatul de intrare pentru mesageria securizat ă 
este corect:  
▼M1 
Octet  Lungi­
me Valoare  Descriere  
#1 1  ‘81h’  T  PV : Etichetă pentru valoarea datelor în clar  
#2 L  ‘NNh’ sau 
„81 NNh”  L PV : lungimea datelor returnate (= Le origi ­
nală). 
L este de 2 octe ți dacă L PV > 127 de octe ți. 
#(2+ L) - #(1+ L+ NN)  NN  ‘XX..XXh’  Valoarea datelor în clar  
#(2+ L+ NN)  1  ‘99h’  Etichet ă pentru starea de procesare (SW1- 
SW2) – op țională pentru mesageria secu ­
rizată de genera ția 1 
#(3+ L+ NN)  1  ‘02h’  Lungimea st ării de procesare – op țională 
pentru mesageria securizat ă de genera ția 1 
#(4+ L+ NN) - 
#(5+ L+ NN)  2 ‘XX XXh’  Starea de procesare a APDU de r ăspuns 
neprotejate – op țională pentru mesageria 
securizată de genera ția 1 
#(6+ L+ NN)  1  ‘8Eh’  TCC: Etichet ă pentru suma de verificare 
criptografic ă 
#(7+ L+ NN)  1  ‘XXh’  LCC: Lungimea urm ătoarei sume de veri ­
ficare criptografice 
„04h” pentru mesageria securizat ă de 
generația 1 (a se vedea apendicele 11 
partea A) 
„08h”, „0Ch” sau „10h”, în func ție de 
lungimea cheii AES pentru mesageria secu ­
rizată de genera ția 2 (a se vedea apendicele 
11 partea B)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 203  
Octet  Lungi­
me Valoare  Descriere  
#(8+ L+ NN)- 
#(7+ M+ L+ NN)  M ‘XX..XXh’  Sumă de verificare criptografic ă 
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
▼B 
TCS_46  Mesaj de r ăspuns dac ă SM-R-ENC-MAC-G1 (genera ția 
1) / SM-R-ENC-MAC-G2 (genera ția 2) este necesar ă și 
dacă formatul de intrare pentru mesageria securizat ă 
este corect:  
▼M1 
Octet  Lungi­
me Valoare  Descriere  
#1 1  ‘87h’  T  PI CG  : Etichetă pentru date criptate (cripto ­
gramă) 
#2 L  ‘MMh’ sau 
‘81 MMh’  L PI CG  : lungimea datelor criptate returnate 
(diferită de Le original ă a comenzii din 
cauza complet ării). 
L este de 2 octe ți dacă LPI CG > 127 de 
octeți. 
#(2+ L)-#(1+ L+ MM)  MM  ‘01XX..XXh’  Date criptate: indicator de completare și 
criptogram ă 
#(2+ L+ MM)  1  ‘99h’  Etichet ă pentru starea de procesare (SW1- 
SW2) – op țională pentru mesageria secu ­
rizată de genera ția 1 
#(3+ L+ MM)  1  ‘02h’  Lungimea st ării de procesare – op țională 
pentru mesageria securizat ă de genera ția 1 
#(4+ L+ MM) - 
#(5+ L+ MM)  2 ‘XX XXh’  Starea de procesare a APDU de r ăspuns 
neprotejate – op țională pentru mesageria 
securizată de genera ția 1 
#(6+ L+ MM)  1  ‘8Eh’  TCC: Etichet ă pentru suma de verificare 
criptografic ă 
#(7+ L+ MM)  1  ‘XXXXh’  LCC: Lungimea urm ătoarei sume de veri ­
ficare criptografice 
„04h” pentru mesageria securizat ă de 
generația 1 (a se vedea apendicele 11 
partea A) 
„08h”, „0Ch” sau „10h”, în func ție de 
lungimea cheii AES pentru mesageria secu ­
rizată de genera ția 2 (a se vedea apendicele 
11 partea B)  
#(8+ L+ MM)- 
#(7+ N+ L+ MM)  N ‘XX..XXh’  Sumă de verificare criptografic ă 
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
▼B 
Comanda READ BINARY poate returna st ările de 
procesare normale enumerate în TCS_43 cu eticheta 
‘99h’, conform descrierii din TCS_59, folosind structura 
de răspuns a mesageriei securizate.  
În plus, pot ap ărea unele erori legate în mod specific de 
mesageria securizat ă. În acest caz, starea de procesare este 
returnată pur și simplu, f ără a mai implica o structur ă de 
mesagerie securizat ă: ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 204  
TCS_47  Mesaj de r ăspuns dac ă formatul de intrare pentru 
mesageria securizat ă este incorect  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— Dacă nu este disponibil ă nicio cheie de sesiune curent ă, 
se returneaz ă starea de procesare ‘ 6A88 ’. Acest lucru se 
întâmplă fie în cazul în care cheia de sesiune nu a fost 
generată deja, fie în cazul în care valabilitatea cheii de 
sesiune a expirat (în acest caz, IFD trebuie s ă ruleze din 
nou un proces de autentificare reciproc ă pentru a seta o 
nouă cheie de sesiune).  
— Dacă unele dintre obiectele de date a șteptate (conform 
specificațiilor de mai sus) lipsesc din formatul de 
mesagerie securizat ă, se returneaz ă starea de procesare 
‘6987 ’: această eroare se produce dac ă lipsește o 
etichetă așteptată sau dacă corpul comenzii nu este 
construit în mod corect.  
— Dacă unele obiecte de date sunt incorecte, starea de 
procesare returnat ă este ‘ 6988 ’: această eroare se 
produce dac ă toate etichetele necesare sunt prezente, 
dar unele lungimi sunt diferite de cele a șteptate.  
— Dacă verificarea sumei de verificare criptografice 
eșuează, starea de procesare returnat ă este ‘ 6688 ’. 
3.5.2.2 C o m a n d ă c u i d e n t i f i c a t o r d e E F ( f i ș i e r e l e m e n t a r ) 
s c u r t  
Această variantă de comand ă permite IFD s ă selecteze un EF prin 
intermediul unui identificator de EF scurt și să citească date din EF-ul 
respectiv.  
TCS_48 Un card de tahograf trebuie s ă fie compatibil cu aceast ă 
variantă de comand ă pentru toate fi șierele elementare care 
au un identificator de EF scurt specificat. Ace ști identifi­
catori de EF scur ți sunt specifica ți în capitolul 4.  
TCS_49  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘B0h’  Citire date ( Read Binary ) 
P1 1  ‘XXh’  Bitul 8 este setat la 1 
Biții 7 și 6 sunt seta ți la 00 
Biții 5-1 codeaz ă identificatorul de EF scurt al EF-ului 
corespunzător 
P2 1  ‘XXh’  Codeaz ă o deplasare de la 0 la 255 de octe ți în EF-ul la 
care face trimitere P1  
Le 1  ‘XXh’  Lungimea datelor a șteptate. Num ărul de octe ți de citit.  
Notă: identificatorii de EF scur ți utilizați pentru aplica ția 
tahografică de genera ția 2 sunt specifica ți în capitolul 4.  
Dacă P1 codeaz ă un identificator de EF scurt și comanda 
este executat ă cu succes, EF-ul identificat devine EF-ul 
selectat în momentul respectiv (EF curent).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 205  
TCS_50  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
#1-#L  L  ‘XX..XXh’  Date citite  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă fișierul corespunz ător identificatorului de EF scurt 
nu este găsit, starea de procesare returnat ă este ‘ 6A82 ’. 
— Dacă nu sunt îndeplinite condi țiile de securitate pentru 
fișierul selectat, comanda este întrerupt ă cu ‘ 6982 ’. 
— Dacă deplasarea nu este compatibil ă cu dimensiunea EF 
(Deplasare > dimensiune EF), starea de procesare 
returnată este ‘ 6B00 ’. 
— Dacă dimensiunea datelor de citit nu este compatibil ă 
cu dimensiunea EF (Deplasare + Le > dimensiune EF), 
starea de procesare returnat ă este ‘ 6700 ’ sau ‘ 6Cxx ’, 
unde ‘xx’ indic ă lungimea exact ă. 
▼M1 
— Dacă în atributele fi șierului este detectat ă o eroare de 
integritate, cardul trebuie s ă considere fi șierul ca fiind 
corupt și irecuperabil, iar starea de procesare returnat ă 
este ‘ 6400 ’ sau ‘ 6500 ’. 
▼B 
— Dacă în datele stocate este detectat ă o eroare de inte ­
gritate, cardul trebuie s ă returneze datele solicitate, iar 
starea de procesare returnat ă este ‘ 6281 ’. 
3.5.2.3 C o m a n d ă c u o c t e t d e i n s t r u c ț i u n i i m p a r  
Această variantă de comand ă permite IFD s ă citească datele dintr-un 
EF cu 32 768 de octe ți sau mai mul ți. 
TCS_51 Un card de tahograf care este compatibil cu EF-uri cu 
32 768 de octe ți sau mai mul ți trebuie s ă fie compatibil 
cu această variantă de comand ă pentru EF-urile respective. 
Un card de tahograf poate s ă fie sau nu compatibil cu 
această variantă de comand ă pentru alte EF-uri, cu 
excepția EF  Sensor_Installation_Data . A se vedea 
TCS_156 și TCS_160.  
TCS_52  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘B1h’  Citire date ( Read Binary ) 
P1 1  ‘00h’  EF curent  
P2 1  ‘00h’  
Lc 1  ‘NNh’  Lc Lungimea obiectului de date deplasat.  
#6-#(5+NN)  NN  ‘XX..XXh’  Obiect de date deplasat: 
Etichetă ‘54h’ 
Lungime ‘01h’ sau ‘02h’ 
Valoare deplasare  
▼M1 
Le 1  ‘XXh’  Conform specifica țiilor din ISO/IEC 7816-4  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 206  
IFD trebuie s ă codeze lungimea obiectului de date deplasat 
cu un num ăr minim posibil de octe ți, și anume: utilizând 
octetul de lungime ‘01h’ IFD codeaz ă o deplasare de la 0 la 
255 și utilizând octetul de lungime ‘02h’ o deplasare de la 
‘256’ până la ‘65 535’ de octe ți. 
▼M1 
În cazul în care T = 0, cardul presupune valoarea Le = 
‘00h’ dacă nu este aplicat ă mesageria securizat ă. 
În cazul în care T = 1, starea de procesare returnat ă este 
‘6700’ dac ă Le = „01h”.  
▼B 
TCS_53  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
#1-#L  L  ‘XX..XXh’  Date citite încapsulate într-un obiect de date discre ționar 
cu eticheta ‘53h’.  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă nu este selectat niciun EF, starea de procesare 
returnată este ‘ 6986 ’. 
— Dacă nu sunt îndeplinite condi țiile de securitate pentru 
fișierul selectat, comanda este întrerupt ă cu ‘ 6982 ’. 
— Dacă deplasarea nu este compatibil ă cu dimensiunea EF 
(Deplasare > dimensiune EF), starea de procesare 
returnată este ‘ 6B00 ’. 
— Dacă dimensiunea datelor de citit nu este compatibil ă 
cu dimensiunea EF (Deplasare + Le > dimensiune EF), 
starea de procesare returnat ă este ‘ 6700 ’ sau ‘ 6Cxx ’, 
unde ‘xx’ indic ă lungimea exact ă. 
▼M1 
— Dacă în atributele fi șierului este detectat ă o eroare de 
integritate, cardul trebuie s ă considere fi șierul ca fiind 
corupt și irecuperabil, iar starea de procesare returnat ă 
este ‘ 6400 ’ sau ‘ 6500 ’. 
▼B 
— Dacă în datele stocate este detectat ă o eroare de inte ­
gritate, cardul trebuie s ă returneze datele solicitate, iar 
starea de procesare returnat ă este ‘ 6281 ’. 
3.5.2.3.1 C o m a n d ă c u m e s a g e r i e s e c u r i z a t ă ( e x e m p l u )  
Următorul exemplu ilustreaz ă utilizarea mesageriei securizate în cazul 
în care se aplic ă condiția de securitate SM-MAC-G2.  
TCS_54 Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘0Ch’  Mesagerie securizat ă solicitată 
INS 1  ‘B1h’  Citire date ( Read Binary ) 
P1 1  ‘00h’  EF curent  
P2 1  ‘00h’  
Lc 1  ‘XXh’  Lungimea câmpului de date securizate  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 207  
Octet  Lungime  Valoare  Descriere  
#6 1  ‘B3h’  Etichet ă pentru valoarea datelor în clar codate în BER- 
TLV  
#7 1  ‘NNh’  L  PV : lungimea datelor transmise  
#(8)-#(7+NN)  NN  ‘XX..XXh’  Date în clar codate în BER-TLV, și anume obiectul de 
date deplasat cu eticheta ‘54’  
#(8+NN)  1  ‘97h’  T  LE : etichetă pentru specifica ția lungimii a șteptate.  
#(9+NN)  1  ‘01h’  L  LE : lungimea lungimii a șteptate  
#(10+NN)  1  ‘XXh’  Specifica ția lungimii a șteptate (Le original ă): numărul de 
octeți de citit  
#(11+NN)  1  ‘8Eh’  T  CC : etichetă pentru suma de verificare criptografic ă 
#(12+NN)  1  ‘XXh’  L  CC : lungimea sumei de verificare criptografice 
următoare 
‘08h’, ‘0Ch’ sau ‘10h’, în func ție de lungimea cheii AES 
pentru mesageria securizat ă de genera ția 2 (a se vedea 
apendicele 11 partea B)  
#(13+NN)- 
#(12+M+NN)  M ‘XX..XXh’  Sumă de verificare criptografic ă 
Le 1  ‘00h’  Conform specifica țiilor din ISO/IEC 7816-4  
TCS_55 Mesaj de r ăspuns în cazul în care comanda este executat ă 
cu succes  
Octet  Lungime  Valoare  Descriere  
#1 1  ‘B3h’  Date în clar codate în BER-TLV  
#2 L  ‘NNh’ sau 
‘81 NNh’  L PV : lungimea datelor returnate (= Le original ă) 
L este de 2 octe ți dacă L PV > 127 de octe ți 
#(2+L)- 
#(1+L+NN)  NN ‘XX..XXh’  Valoarea datelor în clar codate în BER-TLV, adic ă 
datele citite încapsulate într-un obiect de date 
discreționar cu eticheta ‘53h’.  
#(2+L+NN)  1  ‘99h’  Starea de procesare a APDU de r ăspuns neprotejate  
#(3+L+NN)  1  ‘02h’  Lungimea st ării de procesare  
#(4+L+NN) – 
#(5+L+NN)  2 ‘XX XXh’  Starea de procesare a APDU de r ăspuns neprotejate  
#(6+L+NN)  1  ‘8Eh’  T  CC : etichetă pentru suma de verificare criptografic ă 
#(7+L+NN)  1  ‘XXh’  L  CC : lungimea sumei de verificare criptografice 
următoare 
‘08h’, ‘0Ch’ sau ‘10h’, în func ție de lungimea cheii AES 
pentru mesageria securizat ă de genera ția 2 (a se vedea 
apendicele 11 partea B)  
#(8+L+NN)- 
#(7+M+L+NN)  M ‘XX..XXh’  Sumă de verificare criptografic ă 
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
3.5.3  UPDATE BINARY  
Această comandă respectă ISO/IEC 7816-4, dar are o utilizare 
restricționată comparativ cu comanda definit ă în standard.  
Mesajul de comand ă UPDATE BINARY ini țializează actualizarea 
(ștergere + scriere) bi ților deja prezen ți într-un EF binar cu bi ții dați 
în APDU de comand ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 208  
3.5.3.1 C o m a n d ă c u d e p l a s a r e î n P 1 - P 2  
Această comandă permite IFD s ă scrie date în EF-ul selectat în 
momentul respectiv, f ără ca integritatea datelor primite s ă fie verificat ă 
de card.  
Notă: Această comandă fără mesagerie securizat ă poate fi utilizat ă 
numai pentru a actualiza un fi șier care este compatibil cu condi ția 
de securitate ALW pentru modul de acces de actualizare („update”).  
TCS_56  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘D6h’  Actualizare date ( Update Binary ) 
P1 1  ‘XXh’  Deplasare octe ți de la începutul fi șierului: cel mai semni ­
ficativ octet  
P2 1  ‘XXh’  Deplasare octe ți de la începutul fi șierului: cel mai pu țin 
semnificativ octet  
Lc 1  ‘NNh’  Lc Lungimea datelor de actualizat. Num ărul de octe ți de 
scris.  
#6-#(5+NN)  NN  ‘XX..XXh’  Date de scris  
Notă: bitul 8 al P1 trebuie setat la 0.  
TCS_57  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă nu este selectat niciun EF, starea de procesare 
returnată este ‘ 6986 ’. 
— Dacă nu sunt îndeplinite condi țiile de securitate pentru 
fișierul selectat, comanda este întrerupt ă cu ‘ 6982 ’. 
— Dacă deplasarea nu este compatibil ă cu dimensiunea EF 
(Deplasare > dimensiune EF), starea de procesare 
returnată este ‘ 6B00 ’. 
— Dacă dimensiunea datelor de scris nu este compatibil ă 
cu dimensiunea EF (Deplasare + Lc > dimensiunea EF), 
starea de procesare returnat ă este ‘ 6700 ’. 
— Dacă în atributele fi șierului este detectat ă o eroare de 
integritate, cardul trebuie s ă considere fi șierul ca fiind 
corupt și irecuperabil, iar starea de procesare returnat ă 
este ‘ 6400 ’ sau ‘ 6500 ’. 
— Dacă scrierea nu este executat ă cu succes, starea de 
procesare returnat ă este ‘ 6581 ’. 
3.5.3.1.1 C o m a n d ă c u m e s a g e r i e s e c u r i z a t ă ( e x e m p l e )  
Această comandă permite IFD s ă scrie date în EF-ul selectat în 
momentul respectiv, integritatea datelor primite fiind verificat ă de 
card. Întrucât nu este necesar ă păstrarea confiden țialității, datele nu 
sunt criptate.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 209  
TCS_58  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘0Ch’  Mesagerie securizat ă solicitată 
INS 1  ‘D6h’  Actualizare date ( Update Binary ) 
P1 1  ‘XXh’  Deplasare octe ți de la începutul fi șierului: 
cel mai semnificativ octet  
P2 1  ‘XXh’  Deplasare octe ți de la începutul fi șierului: 
cel mai pu țin semnificativ octet  
Lc 1  ‘XXh’  Lungimea câmpului de date securizate  
#6 1  ‘81h’  T  PV : etichetă pentru valoarea datelor în clar  
#7 L  ‘NNh’ sau 
‘81 NNh’  L PV : lungimea datelor transmise. 
L este de 2 octe ți dacă L PV > 127 de octe ți. 
#(7+L)- 
#(6+L+NN)  NN ‘XX..XXh’  Valoarea datelor în clar (date de scris)  
#(7+L+NN)  1  ‘8Eh’  T  CC : etichetă pentru suma de verificare criptografic ă 
#(8+L+NN)  1  ‘XXh’  L  CC : lungimea sumei de verificare criptografice 
următoare ‘04h’ pentru mesageria securizat ă de 
generația 1 (a se vedea apendicele 11 partea A) 
‘08h’, ‘0Ch’ sau ‘10h’, în func ție de lungimea cheii AES 
pentru mesageria securizat ă de genera ția 2 (a se vedea 
apendicele 11 partea B)  
#(9+L+NN)- 
#(8+M+L+NN)  M ‘XX..XXh’  Sumă de verificare criptografic ă 
Le 1  ‘00h’  Conform specifica țiilor din ISO/IEC 7816-4  
TCS_59  Mesaj de r ăspuns dac ă formatul de intrare pentru 
mesageria securizat ă este corect  
Octet  Lungime  Valoare  Descriere  
#1 1  ‘99h’  T  SW : etichetă pentru cuvinte de stare (de protejat de c ătre 
CC) 
#2 1  ‘02h’  L  SW : lungimea cuvintelor de stare returnate  
#3-#4  2  ‘XXXXh’  Starea de procesare a APDU de r ăspuns neprotejate  
#5 1  ‘8Eh’  T  CC : etichetă pentru suma de verificare criptografic ă 
#6 1  ‘XXh’  L  CC : lungimea sumei de verificare criptografice 
următoare 
‘04h’ pentru mesageria securizat ă de genera ția 1 (a se 
vedea apendicele 11 partea A) 
‘08h’, ‘0Ch’ sau ‘10h’, în func ție de lungimea cheii AES 
pentru mesageria securizat ă de genera ția 2 (a se vedea 
apendicele 11 partea B)  
#7-#(6+L)  L  ‘XX..XXh’  Sumă de verificare criptografic ă 
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
Stările de procesare „normale”, descrise pentru comanda 
UPDATE BINARY f ără mesagerie securizat ă (a se vedea 
secțiunea 3.5.3.1), pot fi returnate utilizând structura de 
mesaj de r ăspuns descris ă anterior.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 210  
În plus, pot ap ărea unele erori legate în mod specific de 
mesageria securizat ă. În acest caz, starea de procesare este 
returnată pur și simplu, f ără a mai implica o structur ă de 
mesagerie securizat ă: 
TCS_60  Mesaj de r ăspuns în caz de eroare în cadrul mesageriei 
securizate  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— Dacă nu este disponibil ă nicio cheie de sesiune curent ă, 
se returneaz ă starea de procesare ‘ 6A88 ’. 
— Dacă unele dintre obiectele de date a șteptate (conform 
specificațiilor de mai sus) lipsesc din formatul de 
mesagerie securizat ă, se returneaz ă starea de procesare 
‘6987 ’: această eroare se produce dac ă lipsește o 
etichetă așteptată sau dacă corpul comenzii nu este 
construit în mod corect.  
— Dacă unele obiecte de date sunt incorecte, starea de 
procesare returnat ă este ‘ 6988 ’: această eroare se 
produce dac ă toate etichetele necesare sunt prezente, 
dar unele lungimi sunt diferite de cele a șteptate.  
— Dacă verificarea sumei de verificare criptografice 
eșuează, starea de procesare returnat ă este ‘ 6688 ’. 
3.5.3.2 C o m a n d ă c u i d e n t i f i c a t o r d e E F s c u r t  
Această variantă de comand ă permite IFD s ă selecteze un EF prin 
intermediul unui identificator de EF scurt și să scrie date din EF-ul 
respectiv.  
TCS_61 Un card de tahograf trebuie s ă fie compatibil cu aceast ă 
variantă de comand ă pentru toate fi șierele elementare care 
au un identificator de EF scurt specificat. Ace ști identifi­
catori de EF scur ți sunt specifica ți în capitolul 4.  
TCS_62  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘D6h’  Actualizare date ( Update Binary ) 
P1 1  ‘XXh’  Bitul 8 este setat la 1 
Biții 7 și 6 sunt seta ți la 00 
Biții 5-1 codeaz ă identificatorul de EF scurt al EF-ului 
corespunzător 
P2 1  ‘XXh’  Codeaz ă o deplasare de la 0 la 255 de octe ți în EF-ul la 
care face trimitere P1  
Lc 1  ‘NNh’  Lc Lungimea datelor de actualizat. Num ărul de octe ți de 
scris.  
#6-#(5+NN)  NN  ‘XX..XXh’  Date de scris  
TCS_63  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
Notă: Identificatorii de EF scur ți utilizați pentru aplica ția 
tahografică de genera ția 2 sunt specifica ți în capitolul 4.  
Dacă P1 codeaz ă un identificator de EF scurt și comanda 
este executat ă cu succes, EF-ul identificat devine EF-ul 
selectat în momentul respectiv (EF curent).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 211  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă fișierul corespunz ător identificatorului de EF scurt 
nu este găsit, starea de procesare returnat ă este ‘ 6A82 ’. 
— Dacă nu sunt îndeplinite condi țiile de securitate pentru 
fișierul selectat, comanda este întrerupt ă cu ‘ 6982 ’. 
— Dacă deplasarea nu este compatibil ă cu dimensiunea EF 
(Deplasare > dimensiune EF), starea de procesare 
returnată este ‘ 6B00 ’. 
— Dacă dimensiunea datelor de scris nu este compatibil ă 
cu dimensiunea EF (Deplasare + Lc > dimensiunea EF), 
starea de procesare returnat ă este ‘ 6700 ’. 
▼M1 
— Dacă în atributele fi șierului este detectat ă o eroare de 
integritate, cardul trebuie s ă considere fi șierul ca fiind 
corupt și irecuperabil, iar starea de procesare returnat ă 
este ‘ 6400 ’ sau ‘ 6500 ’. 
▼B 
— Dacă scrierea nu este executat ă cu succes, starea de 
procesare returnat ă este ‘ 6581 ’. 
3.5.3.3 C o m a n d ă c u o c t e t d e i n s t r u c ț i u n i i m p a r  
Această variantă de comand ă permite IFD s ă scrie date într-un EF cu 
32 768 de octe ți sau mai mul ți. 
TCS_64 Un card de tahograf care este compatibil cu EF-uri cu 
32 768 de octe ți sau mai mul ți trebuie s ă fie compatibil 
cu această variantă de comand ă pentru EF-urile respective. 
Un card de tahograf poate sau nu s ă fie compatibil cu 
această variantă de comand ă pentru alte EF-uri.  
TCS_65  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘D7h’  Actualizare date ( Update Binary ) 
P1 1  ‘00h’  EF curent  
P2 1  ‘00h’  
Lc 1  ‘NNh’  Lc Lungimea datelor din câmpul de date al comenzii  
#6-#(5+NN)  NN  ‘XX..XXh’  Obiect de date deplasat cu eticheta ‘54h’ || Obiect de 
date discre ționar cu eticheta ‘53h’ care cuprinde datele 
de scris  
IFD trebuie s ă codeze lungimea obiectului de date deplasat 
și a obiectului de date discre ționar cu num ărul minim 
posibil de octe ți, și anume: utilizând octetul de lungime 
‘01h’, IFD trebuie s ă codeze o deplasare / lungime de la 
0 la 255 și utilizând octetul de lungime ‘02h’ o deplasare / 
lungime de la ‘256’ pân ă la ‘65 535’ de octe ți. 
TCS_66  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 212  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă nu este selectat niciun EF, starea de procesare 
returnată este ‘ 6986 ’. 
— Dacă nu sunt îndeplinite condi țiile de securitate pentru 
fișierul selectat, comanda este întrerupt ă cu ‘ 6982 ’. 
— Dacă deplasarea nu este compatibil ă cu dimensiunea EF 
(Deplasare > dimensiune EF), starea de procesare 
returnată este ‘ 6B00 ’. 
— Dacă dimensiunea datelor de scris nu este compatibil ă 
cu dimensiunea EF (Deplasare + Lc > dimensiunea EF), 
starea de procesare returnat ă este ‘ 6700 ’. 
— Dacă în atributele fi șierului este detectat ă o eroare de 
integritate, cardul trebuie s ă considere fi șierul ca fiind 
corupt și irecuperabil, iar starea de procesare returnat ă 
este ‘ 6400 ’ sau ‘ 6500 ’. 
— Dacă scrierea nu este executat ă cu succes, starea de 
procesare returnat ă este ‘ 6581 ’. 
3.5.3.3.1 C o m a n d ă c u m e s a g e r i e s e c u r i z a t ă ( e x e m p l u )  
Următorul exemplu ilustreaz ă utilizarea mesageriei securizate în cazul 
în care se aplic ă condiția de securitate SM-MAC-G2.  
TCS_67 Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘0Ch’  Mesagerie securizat ă solicitată 
INS 1  ‘D7h’  Actualizare date ( Update Binary ) 
P1 1  ‘00h’  EF curent  
P2 1  ‘00h’  
Lc 1  ‘XXh’  Lungimea câmpului de date securizate  
#6 1  ‘B3h’  Etichet ă pentru valoarea datelor în clar codate în BER- 
TLV  
#7 L  ‘NNh’ sau 
‘81 NNh’  L PV : lungimea datelor transmise. 
L este de 2 octe ți dacă L PV > 127 de octe ți. 
#(7+L)- 
#(6+L+NN)  NN ‘XX..XXh’  Date în clar codate în BER-TLV, și anume obiect de 
date deplasat cu eticheta ‘54h’ || obiect de date 
discreționar cu eticheta ‘53h’ care cuprinde datele de 
scris 
#(7+L+NN)  1  ‘8Eh’  T  CC : etichetă pentru suma de verificare criptografic ă 
#(8+L+NN)  1  ‘XXh’  L  CC : lungimea sumei de verificare criptografice 
următoare 
‘08h’, ‘0Ch’ sau ‘10h’, în func ție de lungimea cheii AES 
pentru mesageria securizat ă de genera ția 2 (a se vedea 
apendicele 11 partea B)  
#(9+L+NN)- 
#(8+M+L+NN)  M ‘XX..XXh’  Sumă de verificare criptografic ă 
Le 1  ‘00h’  Conform specifica țiilor din ISO/IEC 7816-4  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 213  
TCS_68 Mesaj de r ăspuns în cazul în care comanda este executat ă 
cu succes  
Octet  Lungime  Valoare  Descriere  
#1 1  ‘99h’  T  SW : etichetă pentru cuvinte de stare (de protejat de c ătre 
CC) 
#2 1  ‘02h’  L  SW : lungimea cuvintelor de stare returnate  
#3-#4  2  ‘XXXXh’  Starea de procesare a APDU de r ăspuns neprotejate  
#5 1  ‘8Eh’  T  CC : etichetă pentru suma de verificare criptografic ă 
#6 1  ‘XXh’  L  CC : lungimea sumei de verificare criptografice 
următoare 
‘08h’, ‘0Ch’ sau ‘10h’, în func ție de lungimea cheii AES 
pentru mesageria securizat ă de genera ția 2 (a se vedea 
apendicele 11 partea B)  
#7-#(6+L)  L  ‘XX..XXh’  Sumă de verificare criptografic ă 
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
3.5.4  GET CHALLENGE  
Această comandă respectă ISO/IEC 7816-4, dar are o utilizare 
restricționată comparativ cu comanda definit ă în standard.  
Comanda GET CHALLENGE solicit ă cardului s ă emită date de 
provocare pentru a fi utilizate într-o procedur ă legată de securitate 
în cadrul c ăreia se transmit cardului o criptogram ă sau date codificate.  
TCS_69 Datele de provocare emise de card sunt valabile doar pentru 
următoarea comand ă, care utilizeaz ă date de provocare, 
transmisă cardului.  
TCS_70  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘84h’  INS  
P1 1  ‘00h’  P1  
P2 1  ‘00h’  P2  
Le 1  ‘08h’  Le (Lungimea a șteptată a datelor de provocare).  
TCS_71  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
#1-#8  8  ‘XX..XXh’  Date de provocare  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă Le este diferit ă de ‘08h’, starea de procesare este 
‘6700 ’. 
— Dacă parametrii P1-P2 sunt incorec ți, starea de 
procesare este ‘ 6A86 ’. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 214  
3.5.5  VERIFY  
Această comandă respectă ISO/IEC 7816-4, dar are o utilizare 
restricționată comparativ cu comanda definit ă în standard.  
Numai cardul de atelier trebuie s ă fie compatibil cu aceast ă comandă. 
Alte tipuri de carduri de tahograf pot sau nu s ă implementeze aceast ă 
comandă, dar pentru cardurile respective nu este personalizat ă nicio 
CHV de referin ță. Prin urmare, cardurile respective nu pot executa cu 
succes aceast ă comandă. Pentru alte tipuri de carduri de tahograf decât 
cardurile de atelier, comportamentul, și anume codul de eroare 
returnat, se afl ă în afara domeniului de aplicare al prezentei specifi ­
cații, dacă această comandă este transmis ă. 
Comanda „Verify” ini țializează în card compara ția dintre datele CHV 
(PIN) transmise prin comand ă cu CHV de referin ță stocate în card.  
▼M1 
TCS_72 PIN-ul introdus de utilizator trebuie s ă fie codat ASCII și 
completat la dreapta de c ătre IFD cu octe ți „FFh” pân ă la 
lungimea de 8 octe ți; a se vedea, de asemenea, tipul de date 
WorkshopCardPIN din apendicele 1.  
▼B 
TCS_73 Genera ția 1 și 2 de aplica ții tahografice trebuie s ă utilizeze 
aceleași CHV de referin ță. 
TCS_74 Cardul de tahograf trebuie s ă verifice dac ă comanda este 
corect codat ă. În cazul în care comanda nu este corect 
codată, cardul trebuie s ă nu compare valorile CHV, s ă nu 
scadă numărul încercărilor CHV r ămase și să nu reseteze 
starea de securitate „PIN_Verified”, ci s ă anuleze comanda. 
O comand ă este codat ă corect dac ă octeții CLA, INS, P1, 
P2, Lc au valorile specificate, Le lipse ște, iar câmpul de 
date al comenzii are lungimea corect ă. 
TCS_75 În cazul în care comanda este executat ă cu succes, num ărul 
de încercări CHV r ămase se reini țializează. Valoarea 
inițială a numărului de încerc ări CHV rămase este de 5. 
În cazul în care comanda este executat ă cu succes, cardul 
trebuie să seteze starea de securitate intern ă „PIN_Veri ­
fied”. Cardul trebuie s ă reseteze aceast ă stare de securitate 
în cazul în care cardul este resetat sau în cazul în care 
codul CHV transmis în cadrul comenzii nu corespunde cu 
CHV de referin ță stocate.  
Notă: Utilizarea acelora și CHV de referin ță și a unei st ări 
de securitate globale face s ă nu mai fie necesar ca un 
angajat al atelierului s ă reintroduc ă PIN-ul dup ă selectarea 
altui DF de aplica ție tahografic ă. 
TCS_76 O compara ție nereușită este înregistrat ă în card, și anume 
numărul de încerc ări CHV rămase trebuie sc ăzut cu una, 
pentru a limita num ărul încercărilor ulterioare de utilizare a 
CHV de referin ță. 
TCS_77  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘20h’  INS  
P1 1  ‘00h’  P1  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 215  
Octet  Lungime  Valoare  Descriere  
P2 1  ‘00h’  P2 (CHV verificate sunt cunoscute implicit)  
Lc 1  ‘08h’  Lungimea codului CHV transmis  
#6-#13  8  ‘XX..XXh’  CHV  
TCS_78  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă CHV de referin ță nu sunt g ăsite, starea de 
procesare returnat ă este ‘ 6A88 ’. 
— Dacă CHV sunt blocate (num ărul de încerc ări rămase 
pentru CHV este zero), starea de procesare returnat ă 
este ‘ 6983 ’. Odată ce se afl ă în aceast ă stare, CHV 
nu mai pot fi niciodat ă prezentate cu succes.  
— În cazul în care compara ția nu reușește, numărul de 
încercări rămase scade și se returneaz ă starea ‘ 63CX ’ 
(X>0, X fiind egal cu num ărul de încerc ări CHV 
rămase.  
— Dacă CHV de referin ță sunt considerate a fi corupte, 
starea de procesare returnat ă este ‘ 6400 ’ sau ‘ 6581 ’. 
— Dacă Lc este diferit ă de ‘08h’, starea de procesare este 
‘6700 ’. 
3.5.6  GET RESPONSE  
Această comandă respectă ISO/IEC 7816-4.  
Această comandă (necesară și disponibil ă doar pentru protocolul T=0) 
este utilizat ă pentru a transmite datele preg ătite de la card c ătre dispo­
zitivul de interfa ță (cazul în care o comand ă avea inclus ă atât Lc, cât 
și Le).  
Comanda GET RESPONSE trebuie emis ă imediat dup ă comanda de 
pregătire a datelor, altfel datele sunt pierdute. Dup ă executarea 
comenzii GET RESPONSE (cu excep ția cazurilor în care se 
produce eroarea ‘ 61xx ’ sau ‘ 6Cxx ’, a se vedea mai jos), datele 
pregătite anterior nu mai sunt disponibile.  
TCS_79  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘C0h’  
P1 1  ‘00h’  
P2 1  ‘00h’  
Le 1  ‘XXh’  Num ărul de octe ți așteptați ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 216  
TCS_80  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
#1-#X  X  ‘XX..XXh’  Date  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă nu au fost preg ătite date de c ătre card, starea de 
procesare returnat ă este ‘ 6900 ’ sau ‘ 6F00 ’. 
— Dacă Le depășește numărul de octe ți disponibili sau 
dacă Le este egal ă cu zero, starea de procesare 
returnată este ‘ 6Cxx ’, unde ‘xx’ reprezint ă numărul 
exact de octe ți disponibili. În acest caz, datele 
pregătite sunt în continuare disponibile pentru o 
comandă GET RESPONSE ulterioar ă. 
— Dacă Le nu este egal ă cu zero, dar este mai mic ă decât 
numărul de octe ți disponibili, datele solicitate sunt 
transmise în mod normal de c ătre card, iar starea de 
procesare returnat ă este ‘ 61xx ’, unde ‘xx’ indic ă 
numărul de octe ți suplimentari care sunt înc ă disponibili 
pentru o comand ă GET RESPONSE ulterioar ă. 
— În cazul în care comanda nu este compatibil ă (protocol 
T=1), cardul returneaz ă starea ‘ 6D00 ’. 
3.5.7  PSO: VERIFY CERTIFICATE  
Această comandă respectă ISO/IEC 7816-8, dar are o utilizare 
restricționată comparativ cu comanda definit ă în standard.  
Cardul utilizeaz ă comanda VERIFY CERTIFICATE pentru a ob ține o 
cheie public ă din afară și pentru a verifica valabilitatea acesteia.  
3.5.7.1 P e r e c h e d e c o m a n d ă – r ă s p u n s p e n t r u g e n e r a ț i a 1  
TCS_81 Aceast ă variantă de comand ă este compatibil ă doar cu o 
aplicație tahografic ă de genera ția 1.  
TCS_82 În cazul în care o comand ă VERIFY CERTIFICATE este 
executată cu succes, cheia public ă este stocat ă pentru o 
utilizare ulterioar ă în mediul de securitate. Aceast ă cheie 
trebuie să fie setată în mod explicit pentru a fi utilizat ă 
de comanda MSE (a se vedea sec țiunea 3.5.11) în cadrul 
comenzilor legate de securitate (INTERNAL AUTHEN ­
TICATE, EXTERNAL AUTHENTICATE sau VERIFY 
CERTIFICATE), folosindu-se identificatorul s ău de cheie.  
TCS_83 În orice caz, comanda VERIFY CERTIFICATE utilizeaz ă 
cheia public ă selectată anterior de c ătre comanda MSE 
pentru a deschide certificatul. Aceast ă cheie public ă 
trebuie să aparțină unui stat membru sau Europei.  
TCS_84  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘2Ah’  Executarea unei opera țiuni de securitate  
P1 1  ‘00h’  P1  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 217  
Octet  Lungime  Valoare  Descriere  
P2 1  ‘AEh’  P2: date necodate BER-TLV (concatenarea elementelor 
de date)  
Lc 1  ‘C2h’  Lc: lungimea certificatului, 194 de octe ți 
#6-#199  194  ‘XX..XXh’  Certificat: concatenarea elementelor de date (conform 
descrierii din apendicele 11)  
TCS_85  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă verificarea certificatului e șuează, starea de 
procesare returnat ă este ‘ 6688 ’. Procesul de verificare 
și de deschidere a certificatului este descris în apen ­
dicele 11 pentru G1 și G2.  
— Dacă în mediul de securitate nu exist ă nicio cheie 
publică, se returneaz ă starea ‘ 6A88 ’. 
— Dacă cheia public ă selectat ă (utilizat ă pentru 
deschiderea certificatului) este considerat ă coruptă, 
starea de procesare returnat ă este ‘ 6400 ’ sau ‘ 6581 ’. 
— Doar genera ția 1: Dacă cheia public ă selectată (utilizată 
pentru deschiderea certificatului) are un CHA.LSB 
(
 ) 
diferit de ‘00’ (adic ă nu aparține unuia dintre statele 
membre sau Europei), starea de procesare returnat ă 
este ‘ 6985 ’. 
3.5.7.2 P e r e c h e d e c o m a n d ă – r ă s p u n s p e n t r u g e n e r a ț i a 2  
În funcție de dimensiunea curbei, certificatele ECC pot fi atât de lungi 
încât să nu poată fi transmise într-o singur ă APDU. În acest caz, 
trebuie aplicat ă înlănțuirea comenzilor conform ISO/IEC 7816-4 și 
certificatul trebuie transmis în dou ă APDU-uri  PSO: Verify Certificate  
consecutive.  
Structura certificatului și parametrii domeniului sunt defini ți în apen­
dicele 11.  
TCS_86 Comanda poate fi executat ă în MF, în DF Tachograph și în 
DF Tachograph_G2; a se vedea, de asemenea, TCS_ 33.  
TCS_87  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘X0h’  Octet CLA care indic ă înlănțuirea comenzilor: 
‘00h’ unica sau ultima comand ă din lanț 
‘10h’ alte comenzi decât ultima comand ă din lanț 
INS 1  ‘2Ah’  Executarea unei opera țiuni de securitate  
P1 1  ‘00h’  
P2 1  ‘BEh’  Verificarea certificatului autodescriptiv  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 218  
Octet  Lungime  Valoare  Descriere  
Lc 1  ‘XXh’  Lungimea câmpului de date al comenzii, a se vedea 
TCS_88 și TCS_89.  
#6-#5+L  L  ‘XX..XXh’  Date codate DER-TLV: obiectul de date  ECC Certificate 
Body  ca prim obiect de date, concatenat cu obiectul de 
date ECC Certificate Signature  ca al doilea obiect de 
date, sau o parte a acestei concaten ări. Eticheta ‘7F21’ 
și lungimea corespunz ătoare nu se transmit. 
Ordinea acestor obiecte de date este fix ă. 
TCS_88 Pentru APDU-urile cu lungime redus ă se aplică următoarele 
dispoziții: IFD trebuie s ă utilizeze num ărul minim de 
APDU-uri necesar pentru a transmite datele utile ale 
comenzii și să transmită numărul maxim de octe ți în 
prima APDU de comand ă, conform valorii din octetul 
privind dimensiunea câmpului de informa ții pentru card, a 
se vedea TCS_14. Dac ă IFD se comport ă diferit, compor ­
tamentul cardului iese în afara zonei de aplicare.  
TCS_89 Pentru APDU-urile cu lungime extins ă se aplică urmă­
toarele dispozi ții: dacă certificatul nu se încadreaz ă într-o 
singură APDU, cardul trebuie s ă fie compatibil cu 
înlănțuirea comenzilor. IFD trebuie s ă utilizeze num ărul 
minim de APDU-uri necesar pentru a transmite datele 
utile ale comenzii și să transmită numărul maxim de 
octeți în prima APDU de comand ă. Dacă IFD se 
comportă diferit, comportamentul cardului iese în afara 
zonei de aplicare.  
Notă: Conform apendicelui 11, cardul stocheaz ă certificatul 
sau conținutul relevant al certificatului și își actualizeaz ă 
currentAuthenticatedTime . 
Structura mesajului de r ăspuns și cuvintele de stare sunt 
cele definite în TCS_85.  
TCS_90 Pe lâng ă codurile de eroare enumerate în TCS_85, cardul 
poate returna urm ătoarele coduri de eroare:  
— Dacă cheia public ă selectat ă (utilizat ă pentru 
deschiderea certificatului) are un CHA.LSB ( Certifica­
teHolderAuthorisation.equipmentType ) care nu este 
potrivit pentru verificarea certificatului în conformitate 
cu apendicele 11, starea de procesare returnat ă este 
‘6985 ’. 
— Dacă currentAuthenticatedTime  al cardului este mai 
târziu decât data expir ării certificatului, starea de 
procesare returnat ă este ‘ 6985 ’. 
— Dacă este așteptată ultima comand ă din lanț, cardul 
returnează starea ‘ 6883 ’. 
— Dacă în câmpul de date al comenzii sunt transmi și 
parametri incorec ți, cardul returneaz ă starea ‘ 6A80 ’ (uti­
lizată, de asemenea, în cazul în care obiectele de date 
nu sunt trimise în ordinea specificat ă). ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 219  
3.5.8  INTERNAL AUTHENTICATE  
Această comandă respectă ISO/IEC 7816-4.  
TCS_91 Toate cardurile de tahograf trebuie s ă fie compatibile cu 
această comandă în DF Tachograph de genera ția 1. 
Comanda poate sau nu s ă fie accesibil ă în MF și/sau în 
DF Tachograph_G2. În acest caz, comanda se încheie cu 
un cod de eroare adecvat, deoarece cheia privat ă a cardului 
(Card.SK ) pentru protocolul de autentificare de genera ția 1 
este accesibil ă numai în DF_Tachograph de genera ția 1.  
Utilizând comanda INTERNAL AUTHENTICATE, IFD 
poate să autentifice cardul. Procesul de autentificare este 
descris în apendicele 11. Acesta include urm ătoarele 
mențiuni: 
TCS_92 Comanda INTERNAL AUTHENTICATE utilizeaz ă cheia 
privată a cardului (selectat ă implicit) pentru a semna datele 
de autentificare, inclusiv K1 (primul element pentru 
înțelegerea asupra cheii de sesiune) și RND1, și utilizează 
cheia public ă selectată în momentul respectiv (prin inter ­
mediul ultimei comenzi MSE) pentru a cripta semn ătura și 
a forma tokenul de autentificare (mai multe detalii în apen ­
dicele 11).  
TCS_93  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  CLA  
INS 1  ‘88h’  INS  
P1 1  ‘00h’  P1  
P2 1  ‘00h’  P2  
Lc 1  ‘10h’  Lungimea datelor transmise c ătre card  
#6 – #13  8  ‘XX..XXh’  Date de provocare utilizate pentru autentificarea cardului  
#14 -#21  8  ‘XX..XXh’  VU.CHR (a se vedea apendicele 11)  
Le 1  ‘80h’  Lungimea datelor a șteptate de la card  
TCS_94  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
#1-#128  128  ‘XX..XXh’  Token de autentificare a cardului (a se vedea apendicele 11)  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă în mediul de securitate nu exist ă nicio cheie 
publică, starea de procesare returnat ă este ‘ 6A88 ’. 
— Dacă în mediul de securitate nu exist ă nicio cheie 
privată, starea de procesare returnat ă este ‘ 6A88 ’. 
— Dacă VU.CHR nu corespunde identificatorului cheii 
publice curente, starea de procesare returnat ă este 
‘6A88 ’. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 220  
— Dacă cheia privat ă selectată este considerat ă coruptă, 
starea de procesare returnat ă este ‘ 6400 ’ sau ‘ 6581 ’. 
▼M1 
TCS_95 În cazul în care comanda INTERNAL AUTHENTICATE 
este executat ă cu succes, cheia de sesiune curent ă de 
generația 1, dacă există, este ștearsă și nu mai este dispo ­
nibilă. Pentru a face disponibil ă o nouă cheie de sesiune de 
generația 1, trebuie executat ă cu succes comanda 
EXTERNAL AUTHENTICATE pentru mecanismul de 
autentificare de genera ția 1.  
Notă: Pentru cheile de sesiune de genera ția 2 a se vedea 
apendice 11 CSM_193 și CSM_195. Dac ă sunt stabilite 
chei de sesiune de genera ția 2, iar tahograful prime ște 
comanda APDU în clar INTERNAL AUTHENTICATE, 
acesta abandoneaz ă sesiunea de mesagerie securizat ă de 
generația 2 și distruge cheile de sesiune de genera ția 2. 
▼B 
3.5.9  EXTERNAL AUTHENTICATE  
Această comandă respectă ISO/IEC 7816-4.  
Utilizând comanda EXTERNAL AUTHENTICATE, cardul poate 
autentifica IFD-ul. Procesul de autentificare este descris în apendicele 
11 pentru genera ția 1 și 2 de tahografe (autentificare VU).  
TCS_96 Varianta de comand ă pentru mecanismul de autentificare 
reciprocă de genera ția 1 este compatibil ă numai cu o 
aplicație tahografic ă de genera ția 1. 
▼M1 
TCS_97 Varianta de comand ă pentru autentificarea reciproc ă VU- 
card de a doua genera ție poate fi executat ă în MF, în DF 
Tachograph și în DF Tachograph_G2; a se vedea, de 
asemenea, TCS_34. În cazul în care aceast ă comandă 
INTERNAL AUTHENTICATE de genera ția 2 este 
executată cu succes, cheia de sesiune curent ă de genera ția 
1, dacă există, este ștearsă și nu mai este disponibil ă. 
Notă: Pentru cheile de sesiune de genera ția 2 a se vedea 
apendicele 11 CSM_193 și CSM_195. Dac ă sunt stabilite 
chei de sesiune de genera ția 2, iar tahograful prime ște 
comanda APDU în clar EXTERNAL AUTHENTICATE, 
acesta abandoneaz ă sesiunea de mesagerie securizat ă de 
generația 2 și distruge cheile de sesiune de genera ția 2. 
▼B 
TCS_98  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  CLA  
INS 1  ‘82h’  INS  
P1 1  ‘00h’  Cheile și algoritmii cunoscu ți implicit  
P2 1  ‘00h’  
Lc 1  ‘XXh’  Lc (Lungimea datelor transmise c ătre card)  
#6-#(5+L)  L  ‘XX..XXh’  Autentificarea de genera ția 1: criptogram ă (a se vedea 
apendicele 11 partea A) 
Autentificarea de genera ția 2: semn ătură generată de IFD 
(a se vedea apendicele 11 partea B)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 221  
TCS_99  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă CHA a cheii publice setate în momentul respectiv 
nu este reprezentat ă de concatenarea AID-ului aplica ției 
tahografice și a unui tip de echipament VU, starea de 
procesare returnat ă este ‘ 6F00 ’. 
— În cazul în care comanda nu urmeaz ă imediat unei 
comenzi GET CHALLENGE, starea de procesare 
returnată este ‘ 6985 ’. 
Aplicația tahografic ă de genera ția 1 poate returna urm ă­
toarele coduri de eroare suplimentare:  
— Dacă în mediul de securitate nu exist ă nicio cheie 
publică, se returneaz ă starea ‘ 6A88 ’. 
— Dacă în mediul de securitate nu exist ă nicio cheie 
privată, starea de procesare returnat ă este ‘ 6A88 ’. 
— Dacă verificarea criptogramei este eronat ă, starea de 
procesare returnat ă este ‘ 6688 ’. 
— Dacă cheia privat ă selectată este considerat ă coruptă, 
starea de procesare returnat ă este ‘ 6400 ’ sau ‘ 6581 ’. 
Varianta de comand ă pentru autentificarea de genera ția 2 
poate returna urm ătorul cod de eroare suplimentar:  
— Dacă verificarea semn ăturii a eșuat, cardul returneaz ă 
‘6300 ’. 
3.5.10  GENERAL AUTHENTICATE  
Această comandă este utilizat ă pentru protocolul de autentificare a 
cipului de genera ția 2 specificat în apendicele 11 partea B și este 
conformă cu ISO/IEC 7816-4.  
TCS_100 Comanda poate fi executat ă în MF, în DF Tachograph și în 
DF Tachograph_G2; a se vedea, de asemenea, TCS_34.  
TCS_101  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘86h’  
P1 1  ‘00h’  Protocolul și cheile cunoscute implicit  
P2 1  ‘00h’  
Lc 1  ‘NNh’  Lc: lungimea câmpului de date subsecvent  
#6-#(5+L)  L  ‘7Ch’ + L  7C + 
‘80h’ + L  80 + 
‘XX..XXh’  Valoarea cheii publice efemere codate DER-TLV (a 
se vedea apendicele 11) 
VU trebuie s ă trimită obiectele de date în aceast ă 
ordine.  
▼M1 
5 + L + 1  1  ‘00h’  Conform specifica țiilor din ISO/IEC 7816-4  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 222  
TCS_102  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
#1-#L  L  ‘7Ch’ + L  7C + ‘81h’ 
+ ‘08h’ + ‘XX..XXh’ 
+ ‘82h’ + L  82 + 
‘XX..XXh’  Date dinamice de autentificare codate DER- 
TLV:  nonce  și token de autentificare (a se 
vedea apendicele 11)  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Cardul returneaz ă starea ‘ 6A80 ’ pentru a indica 
existența unor parametri incorec ți în câmpul de date.  
— Cardul returneaz ă starea ‘ 6982 ’ în cazul în care 
comanda  External Authenticate  nu a fost executat ă cu 
succes.  
Obiectul de r ăspuns cu date dinamice de autentificare ‘7Ch’  
— trebuie s ă fie prezent dac ă operațiunea reușește, și 
anume cuvintele de stare sunt ‘ 9000 ’, 
— trebuie s ă fie absent în cazul unei erori de execu ție sau 
al unei erori de verificare, și anume în cazul în care 
cuvintele de stare se înscriu în intervalul ‘ 6400 ’ – 
‘6FFF ’ și 
— poate fi absent în cazul unei avertiz ări, și anume în 
cazul în care cuvintele de stare se înscriu în intervalul 
‘6200 ’ – ‘ 63FF ’. 
3.5.11  MANAGE SECURITY ENVIRONMENT  
Această comandă este utilizat ă pentru setarea unei chei publice pentru 
autentificare.  
3.5.11.1 P e r e c h e d e c o m a n d ă – r ă s p u n s p e n t r u g e n e r a ț i a 1  
Această comandă respectă ISO/IEC 7816-4. Utilizarea acestei comenzi 
este restric ționată față de standardul corespunz ător. 
TCS_103 Aceast ă comandă este compatibil ă doar cu o aplica ție taho­
grafică de genera ția 1.  
TCS_104 Cheia identificat ă în câmpul de date MSE r ămâne cheia 
publică curentă până la urm ătoarea comand ă MSE 
corectă, până la selectarea unui DF sau pân ă când cardul 
este resetat.  
TCS_105 Dac ă cheia identificat ă nu este (deja) prezent ă în card, 
mediul de securitate r ămâne neschimbat.  
TCS_106  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  CLA  
INS 1  ‘22h’  INS  
P1 1  ‘C1h’  P1: cheia identificat ă valabilă pentru toate opera țiunile 
criptografice  
P2 1  ‘B6h’  P2 (date identificate privind semn ătura digital ă) 
Lc 1  ‘0Ah’  Lc: lungimea câmpului de date subsecvent  
#6 1  ‘83h’  Etichet ă pentru identificarea unei chei publice în cazuri 
asimetrice  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 223  
Octet  Lungime  Valoare  Descriere  
#7 1  ‘08h’  Lungimea identificatorului de cheie (identificator cheie)  
#8-#15  8  ‘XX..XXh’  Identificator cheie conform specifica țiilor din apendicele 
11 
TCS_107  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă cheia identificat ă nu este prezent ă în card, starea 
de procesare returnat ă este ‘ 6A88 ’. 
— Dacă unele dintre obiectele de date a șteptate lipsesc din 
formatul de mesagerie securizat ă, se returneaz ă starea 
de procesare ‘ 6987 ’. Acest lucru se poate întâmpla dac ă 
lipsește eticheta ‘83h’.  
— Dacă unele obiecte de date sunt incorecte, starea de 
procesare returnat ă este ‘ 6988 ’. Acest lucru se poate 
întâmpla dac ă lungimea identificatorului cheii nu este 
‘08h’.  
— Dacă cheia selectat ă este considerat ă coruptă, starea de 
procesare returnat ă este ‘ 6400 ’ sau ‘ 6581 ’. 
3.5.11.2 P e r e c h i d e c o m a n d ă – r ă s p u n s p e n t r u g e n e r a ț i a 2  
Pentru autentificarea de genera ția 2, cardul de tahograf este compatibil 
cu următoarele versiuni de comand ă MSE: Set  care respect ă ISO/IEC 
7816-4. Aceste versiuni de comand ă nu sunt compatibile în ceea ce 
privește autentificarea de genera ția 1.  
3.5.11.2.1 M S E : S E T A T p e n t r u a u t e n t i f i c a r e a c i p u l u i  
Următoarea comand ă MSE:SET AT este utilizat ă pentru a selecta 
parametrii pentru autentificarea cipului care este efectuat ă de o 
comandă General Authenticate  ulterioară. 
TCS_108 Comanda poate fi executat ă în MF, în DF Tachograph și în 
DF Tachograph_G2; a se vedea, de asemenea, TCS_34.  
TCS_109  Mesaj de comand ă MSE:SET AT pentru autentificarea 
cipului  
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘41h’  Setat pentru autentificare intern ă 
P2 1  ‘A4h’  Autentificare  
Lc 1  ‘NNh’  Lc: lungimea câmpului de date subsecvent  
#6-#(5+L)  L  ‘80h’ + ‘0Ah’ 
+ ‘XX..XXh’  Identificatorul mecanismului criptografic codat DER- 
TLV: identificatorul de obiect al autentific ării cipului 
(doar valoarea, eticheta ‘06h’ este omis ă). 
A se vedea apendicele 1 pentru valorile identificatorilor 
de obiect; trebuie folosit ă notația cu octeți. A se vedea 
apendicele 11 pentru îndrum ări cu privire la modul de 
selectare a unuia dintre ace ști identificatori de obiect.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 224  
3.5.11.2.2 M S E : S E T A T p e n t r u a u t e n t i f i c a r e a V U  
Următoarea comand ă MSE:SET AT este utilizat ă pentru a selecta 
parametrii și cheile pentru autentificarea VU care este efectuat ă de 
o comandă External Authenticate  ulterioară. 
TCS_110 Comanda poate fi executat ă în MF, în DF Tachograph și în 
DF Tachograph_G2; a se vedea, de asemenea, TCS_34.  
TCS_111  Mesaj de comand ă MSE:SET AT pentru autentificarea 
VU 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘81h’  Setat pentru autentificare extern ă 
P2 1  ‘A4h’  Autentificare  
Lc 1  ‘NNh’  Lc: lungimea câmpului de date subsecvent  
#6-#(5+L)  L  ‘80h’ + ‘0Ah’ 
+ ‘XX..XXh’  Identificatorul mecanismului criptografic codat DER- 
TLV: identificatorul de obiect al autentific ării VU (doar 
valoarea, eticheta ‘06h’ este omis ă). 
A se vedea apendicele 1 pentru valorile identificatorilor 
de obiect; trebuie folosit ă notația cu octeți. A se vedea 
apendicele 11 pentru îndrum ări cu privire la modul de 
selectare a unuia dintre ace ști identificatori de obiect.  
‘83h’ + ‘08h’ 
+ ‘XX..XXh’  Identificator codat DER-TLV al cheii publice a VU de 
către identificatorul de ținătorului certificatului men ționat 
în certificatul aferent.  
‘91h’ + L  91 + 
‘XX..XXh’  Reprezentare comprimat ă, codată DER-TLV, a cheii 
publice efemere a VU care va fi folosit ă în cursul auten ­
tificării cipului (a se vedea apendicele 11)  
3.5.11.2.3 M S E : S E T D S T  
Următoarea comand ă MSE:SET DST este utilizat ă pentru a stabili o 
cheie public ă fie 
— pentru verificarea unei semn ături care este furnizat ă într-o 
comandă PSO: Verify Digital Signature  ulterioară, fie 
— pentru verificarea semn ăturii unui certificat care este furnizat într-o 
comandă PSO: Verify Certificate  ulterioară. 
TCS_112 Comanda poate fi executat ă în MF, în DF Tachograph și în 
DF Tachograph_G2; a se vedea, de asemenea, TCS_ 33.  
TCS_113  Mesaj de comand ă MSE:SET DST  
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘81h’  Setat pentru verificare  
P2 1  ‘B6h’  Semn ătură digitală ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 225  
Octet  Lungime  Valoare  Descriere  
Lc 1  ‘NNh’  Lc: lungimea câmpului de date subsecvent  
#6-#(5+L)  L  ‘83h’ + ‘08h’ 
+ ‘XX...XXh’  Identificator codat DER-TLV al unei chei publice, și 
anume identificatorul de ținătorului certificatului din certi ­
ficatul cheii publice (a se vedea apendicele 11)  
Pentru toate versiunile de comand ă, structura mesajului de r ăspuns și 
cuvintele de stare sunt date de:  
TCS_114  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. Protocolul a fost 
selectat și inițializat.  
— ‘6A80 ’ indică existența unor parametri incorec ți în 
câmpul de date al comenzii.  
— ‘6A88 ’ indică faptul că datele identificate ( și anume o 
cheie identificat ă) nu sunt disponibile.  
▼M1 
— Dacă currentAuthenticatedTime al cardului este ulterior 
față de data de expirare a cheii publice selectate, starea 
de procesare returnat ă este  ‘6A88’.  
Notă: În cazul unei comenzi MSE: SET AT pentru auten ­
tificarea VU, cheia identificat ă este o cheie public ă 
VU_MA. Cardul seteaz ă pentru utilizare cheia public ă 
VU_MA, dac ă este disponibil ă în memoria sa, care 
corespunde identificatorului de ținătorului certificatului 
(CHR) indicat în câmpul de date al comenzii (cardul 
poate identifica cheile publice VU_MA prin intermediul 
câmpului certificatului CHA). Cardul returneaz ă „6A88” 
la această comandă în cazul în care este disponibil ă 
numai cheia public ă VU_Sign sau nu este disponibil ă 
nicio cheie public ă a unității montate pe vehicul. A se 
vedea defini ția câmpului CHA în apendicele 11 și a 
tipului de date equipmentType în apendicele 1.  
În mod similar, în cazul în care se trimite o comand ă MSE: 
SET DST care identific ă EQT (și anume, o VU sau un 
card) la un card de control, potrivit CSM_234, cheia iden ­
tificată este întotdeauna o cheie EQT_Sign, care trebuie 
utilizată pentru verificarea semn ăturii digitale. În confor ­
mitate cu figura 13 din apendicele 11, cardul de control 
va avea întotdeauna stocat ă cheia public ă EQT_Sign rele ­
vantă. În anumite cazuri, cardul de control ar putea avea 
stocată cheia public ă EQT_MA corespunz ătoare. Cardul de 
control trebuie s ă seteze întotdeauna pentru utilizare cheia 
publică EQT_Sign atunci când prime ște o comand ă MSE: 
SET DST.  
▼B 
3.5.12  PSO: HASH  
Această comandă este utilizat ă pentru a transfera pe card rezultatul 
unui calcul  hash  aplicat anumitor date. Aceast ă comandă este utilizat ă 
pentru verificarea semn ăturilor digitale. Valoarea  hash  este stocat ă 
temporar pentru comanda ulterioar ă PSO: Verify Digital Signature  
Această comandă respectă ISO/IEC 7816-8. Utilizarea acestei comenzi 
este restric ționată față de standardul corespunz ător. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 226  
Numai cardul de control trebuie s ă fie compatibil cu aceast ă comandă 
în DF Tachograph și în DF Tachograph_G2.  
Alte tipuri de card de tahograf pot sau nu s ă implementeze aceast ă 
comandă. Comanda poate sau nu s ă fie accesibil ă în MF.  
Aplicația cardului de control de genera ția 1 este compatibil ă numai cu 
SHA-1.  
TCS_115 Valoarea  hash  stocată temporar trebuie ștearsă dacă o nouă 
valoare  hash  este calculat ă prin intermediul unei comenzi  
PSO: HASH , dacă este selectat un DF și dacă cardul de 
tahograf este resetat.  
TCS_116  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Executarea unei opera țiuni de securitate  
P1 1  ‘90h’  Returnare cod  hash  
P2 1  ‘A0h’  Etichet ă: câmpul de date con ține DO-urile relevante 
pentru  hashing  
Lc 1  ‘XXh’  Lungimea Lc a câmpului de date subsecvent  
#6 1  ‘90h’  Etichet ă pentru codul  hash  
#7 1  ‘XXh’  Lungimea L a codului  hash : 
‘14h’ în aplica ția de genera ția 1 (a se vedea apendicele 
11 partea A) 
‘20h’, ‘30h’ sau ‘40h’ în aplica ția de genera ția 2 (a se 
vedea apendicele 11 partea B)  
#8-#(7+L)  L  ‘XX..XXh’  Cod  hash  
TCS_117  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă unele dintre obiectele de date a șteptate (conform 
specificațiilor de mai sus) lipsesc, se returneaz ă starea 
de procesare ‘ 6987 ’. Acest lucru se poate întâmpla dac ă 
lipsește una dintre etichetele ‘90h’.  
— Dacă unele obiecte de date sunt incorecte, starea de 
procesare returnat ă este ‘ 6988 ’. Această eroare apare 
dacă eticheta necesar ă este prezent ă, dar cu o lungime 
diferită de ‘14h’ pentru SHA-1, ‘20h’ pentru SHA-256, 
‘30h’ pentru SHA-384, ‘40h’ pentru SHA-512 (aplica ția 
de generația 2).  
3.5.13  PERFORM HASH OF FILE  
Această comandă nu respect ă ISO/IEC 7816-8. Astfel, octetul CLA al 
acestei comenzi indic ă o utilizare exclusiv ă a comenzii PERFORM 
SECURITY OPERATION / HASH.  
Numai cardul de conduc ător auto și cardul de control trebuie s ă fie 
compatibile cu aceast ă comandă în DF Tachograph și în DF Tacho ­
graph_G2.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 227  
Alte tipuri de card de tahograf pot sau nu s ă implementeze aceast ă 
comandă. Dacă un card de societate sau de control implementeaz ă 
această comandă, comanda trebuie implementat ă conform specifi ­
cațiilor din prezentul capitol.  
Comanda poate sau nu s ă fie accesibil ă în MF. În acest caz, comanda 
trebuie să fie implementat ă conform specifica țiilor din prezentul 
capitol, și anume să nu permit ă calcularea unei valori  hash , ci să se 
încheie cu un cod de eroare adecvat.  
TCS_118 Comanda PERFORM HASH OF FILE este utilizat ă pentru 
a executa o opera țiune hash  în zona de date a EF trans ­
parent selectat în momentul respectiv.  
TCS_119 Un card de tahograf trebuie s ă fie compatibil cu aceast ă 
comandă numai pentru EF-urile care sunt men ționate în 
capitolul 4 din cadrul DF_Tachograph și DF_Tacho ­
graph_G2, cu urm ătoarea excep ție. Un card de tahograf 
nu trebuie s ă fie compatibil cu aceast ă comandă pentru 
EF Sensor_Installation_Data  din DF Tachograph_G2.  
TCS_120 Rezultatul opera țiunii hash  este stocat temporar în card. 
Ulterior, acesta poate fi utilizat pentru a ob ține semnătura 
digitală a fișierului, utilizând comanda  PSO: COMPUTE 
DIGITAL SIGNATURE . 
▼M1 
TCS_121 Valoarea hash de fi șier stocată temporar trebuie ștearsă 
dacă o nouă valoare hash de fi șier este calculat ă prin inter­
mediul comenzii PERFORM HASH of FILE, dac ă este 
selectat un DF și dacă cardul de tahograf este resetat.  
▼B 
TCS_122 Aplica ția tahografic ă de genera ția 1 trebuie s ă fie compa ­
tibilă cu SHA-1.  
▼M1 
TCS_123 Aplica ția tahografic ă de genera ția 2 trebuie s ă fie compa ­
tibilă cu algoritmul SHA-2 (SHA-256, SHA-384 sau SHA- 
512), definit de suita cifru din apendicele 11 partea B 
pentru cheia de semn ătură Card_Sign a cardului.  
▼B 
TCS_124  Mesaj de comand ă 
▼M1 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘80h’  CLA  
INS 1  ‘2Ah’  Executarea unei opera țiuni de securitate  
P1 1  ‘90h’  Etichet ă: Hash  
P2 1  ‘00h’  Algoritm implicit cunoscut 
Pentru aplica ția tahografic ă de genera ția 1: SHA-1 
Pentru aplica ția tahografic ă de genera ția 2: algoritmul 
SHA-2 (SHA-256, SHA-384 sau SHA-512) definit de 
suita cifru din apendicele 11 partea B pentru cheia de 
semnătură Card_Sign a cardului  
▼B 
TCS_125  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă EF-ul curent nu permite aceast ă comandă (EF  
Sensor_Installation_Data  din DF Tachograph_G2), se 
returnează starea de procesare ‘ 6985 ’. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 228  
— Dacă EF-ul selectat este considerat corupt (erori în atri ­
butele fișierului sau erori de integritate a datelor 
stocate), starea de procesare returnat ă este ‘ 6400 ’ sau 
‘6581 ’. 
— Dacă fișierul selectat nu este un fi șier transparent sau 
dacă nu exist ă un EF curent, starea de procesare 
returnată este ‘ 6986 ’. 
3.5.14  PSO: COMPUTE DIGITAL SIGNATURE  
▼M1 
Această comandă este utilizat ă pentru calcularea semn ăturii digitale a 
codului hash calculat anterior (a se vedea „PERFORM HASH of 
FILE”, sec țiunea 3.5.13).  
Numai cardul de conduc ător auto și cardul de control trebuie s ă fie 
compatibile cu aceast ă comandă în DF Tachograph și în DF Tacho ­
graph_G2.  
Alte tipuri de card de tahograf pot sau nu s ă implementeze aceast ă 
comandă. În cazul aplica ției tahografice de genera ția 2, numai cardul 
de conduc ător auto și cardul de atelier au o cheie de semn ătură de 
generația 2, alte carduri nu pot executa comanda cu succes și o 
încheie cu un cod de eroare adecvat.  
Comanda poate sau nu s ă fie accesibil ă în MF. Atunci când comanda 
nu este accesibil ă în MF, trebuie s ă se încheie cu un cod de eroare 
adecvat.  
Această comandă respectă ISO/IEC 7816-8. Utilizarea acestei comenzi 
este restric ționată față de standardul corespunz ător. 
▼B 
TCS_126 Aceast ă comandă nu trebuie s ă calculeze o semn ătură 
digitală a codului  hash  calculat anterior prin comanda  
PSO: HASH . 
TCS_127 Cheia privat ă a cardului este utilizat ă pentru a calcula 
semnătura digital ă și este cunoscut ă implicit de card.  
TCS_128 Aplica ția tahografic ă de genera ția 1 execut ă o semnătură 
digitală utilizând o metod ă de completare conform ă cu 
PKCS1 (a se vedea apendicele 11 pentru detalii).  
TCS_129 Aplica ția tahografic ă de genera ția 2 calculeaz ă o semnătură 
digitală bazată pe curbe eliptice (a se vedea apendicele 11 
pentru detalii).  
TCS_130  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Executarea unei opera țiuni de securitate  
P1 1  ‘9Eh’  Semn ătură digitală de returnat  
P2 1  ‘9Ah’  Etichet ă: câmpul de date con ține date de semnat. Întrucât 
nu este inclus niciun câmp de date, se presupune c ă 
datele sunt deja prezente în card ( hash  de fișier) 
Le 1  ‘NNh’  Lungimea semn ăturii așteptate  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 229  
TCS_131  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
#1-#L  L  ‘XX..XXh’  Semnătura codului  hash  calculat anterior  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă cheia privat ă selectată implicit este considerat ă 
coruptă, starea de procesare returnat ă este ‘ 6400 ’ sau 
‘6581 ’. 
— În cazul în care codul  hash  care a fost calculat într-o 
comandă Perform Hash of File  anterioară nu este 
disponibil, starea de procesare returnat ă este ‘ 6985 ’. 
3.5.15  PSO: VERIFY DIGITAL SIGNATURE  
Această comandă este utilizat ă pentru a verifica semn ătura digital ă, 
furnizată ca intrare, al c ărui cod  hash  este cunoscut de card. Algo ­
ritmul semn ăturii este cunoscut implicit de card.  
Această comandă respectă ISO/IEC 7816-8. Utilizarea acestei comenzi 
este restric ționată față de standardul corespunz ător. 
Numai cardul de control trebuie s ă fie compatibil cu aceast ă comandă 
în DF Tachograph și în DF Tachograph_G2.  
Alte tipuri de card de tahograf pot sau nu s ă implementeze aceast ă 
comandă. Comanda poate sau nu s ă fie accesibil ă în MF.  
TCS_132 Comanda VERIFY DIGITAL SIGNATURE utilizeaz ă 
întotdeauna cheia public ă selectată de comanda anterioar ă 
Manage Security Environment MSE: Set DST  și codul  hash  
anterior introdus de o comand ă PSO: HASH . 
TCS_133  Mesaj de comand ă 
▼M1 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Executarea unei opera țiuni de securitate  
P1 1  ‘00h’  
P2 1  ‘A8h’  Etichet ă: câmpul de date con ține DO-urile relevante 
pentru verificare  
Lc 1  ‘XXh’  Lungimea Lc a câmpului de date subsecvent  
#6 1  ‘9Eh’  Etichet ă pentru semn ătura digital ă 
#7 sau 
#7-#8  L ‘NNh’ sau 
‘81 NNh’  Lungimea semn ăturii digitale (L este de 2 octe ți dacă 
semnătura digital ă este mai mare de 127 de octe ți): 
128 de octe ți codați în conformitate cu apendicele 11 
partea A pentru aplica ția tahografic ă de genera ția 1. 
În funcție de curba aleas ă pentru aplica ția tahografic ă de 
generația 2 (a se vedea apendicele 11 partea B).  
#(7+ L)- 
#(6+ L+ NN)  NN ‘XX..XXh’  Conținutul semn ăturii digitale  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 230  
TCS_134  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— Dacă verificarea semn ăturii eșuează, starea de procesare 
returnată este ‘ 6688 ’. Procesul de verificare este descris 
în apendicele 11.  
— Dacă nu este selectat ă nicio cheie public ă, starea de 
procesare returnat ă este ‘ 6A88 ’. 
— Dacă unele dintre obiectele de date a șteptate (conform 
specificațiilor de mai sus) lipsesc, se returneaz ă starea 
de procesare ‘ 6987 ’. Acest lucru se poate întâmpla dac ă 
una dintre etichetele necesare lipse ște. 
— Dacă nu este disponibil niciun cod  hash  pentru 
procesarea comenzii (ca urmare a unei comenzi  PSO: 
Hash  anterioare), starea de procesare returnat ă este 
‘6985 ’. 
— Dacă unele obiecte de date sunt incorecte, starea de 
procesare returnat ă este ‘ 6988 ’. Acest lucru se poate 
întâmpla dac ă lungimea unuia dintre obiectele de date 
necesare este incorect ă. 
— Dacă cheia public ă selectată este considerat ă coruptă, 
starea de procesare returnat ă este ‘ 6400 ’ sau ‘ 6581 ’. 
▼M1 
— Dacă cheia public ă selectată (utilizată pentru verificarea 
semnăturii digitale) are un CHA.LSB (CertificateHolde ­
rAuthorisation.equipmentType) care nu este potrivit 
pentru verificarea semn ăturii digitale în conformitate 
cu apendicele 11, starea de procesare returnat ă este  
‘6985’ . 
▼B 
3.5.16  PROCESS DSRC MESSAGE  
Această comandă este utilizat ă pentru a verifica integritatea și auten­
ticitatea mesajului DSRC și pentru a descifra datele comunicate de o 
VU unei autorit ăți de control sau unui atelier prin leg ătura DSRC. 
Cardul ob ține cheia de criptare și cheia MAC folosite pentru a 
securiza mesajul DSRC conform descrierii din apendicele 11 partea 
B capitolul 13.  
Numai cardul de control și cardul de atelier trebuie s ă fie compatibile 
cu această comandă în DF Tachograph_G2.  
Alte tipuri de carduri de tahograf pot sau nu s ă implementeze aceast ă 
comandă, dar nu trebuie s ă aibă o cheie  master  DSRC. Prin urmare, 
aceste carduri nu pot executa comanda cu succes, ci o încheie cu un 
cod de eroare adecvat.  
Comanda poate sau nu s ă fie accesibil ă în MF și/sau în DF Tacho ­
graph. În acest caz, comanda trebuie s ă se încheie cu un cod de eroare 
adecvat.  
TCS_135 Cheia  master  DSRC este accesibil ă numai în DF Tacho ­
graph_G2, și anume cardul de control și cardul de atelier 
trebuie să permită executarea cu succes a comenzii doar în 
DF Tachograph_G2.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 231  
TCS_136 Comanda decripteaz ă doar datele DSRC și verifică suma de 
verificare criptografic ă, dar fără a interpreta datele de 
intrare.  
TCS_137 Ordinea obiectelor de date din câmpul de date al comenzii 
este fixată de prezenta specifica ție. 
TCS_138  Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘80h’  CLA exclusiv  
INS 1  ‘2Ah’  Executarea unei opera țiuni de securitate  
P1 1  ‘80h’  Date de r ăspuns: valoare a datelor în clar  
P2 1  ‘B0h’  Date de comand ă: valoare a datelor în clar codat ă BER- 
TLV și incluzând DO-uri SM  
Lc 1  ‘NNh’  Lungimea Lc a câmpului de date subsecvent  
#6-#(5+L)  L  ‘87h’ + L  87 + 
‘XX..XXh’  Octet indicator de con ținut de completare codat DER- 
TLV, urmat de datele utile de tahograf criptate. Pentru 
octetul indicator de con ținut de completare trebuie 
folosită valoarea ‘00h’ („nicio alt ă indicație” în confor ­
mitate cu tabelul 52 din ISO/IEC 7816-4:2013). Pentru 
mecanismul de criptare, a se vedea apendicele 11 partea 
B capitolul 13. 
Valorile permise pentru lungimea L  87 sunt multiplii 
lungimii de bloc AES plus 1 pentru octetul indicator 
de conținut de completare, adic ă de la 17 octe ți până 
la 193 de octe ți, inclusiv.  
Notă: a se vedea tabelul 49 din ISO/IEC 7816-4:2013 
pentru obiectul de date SM cu eticheta ‘87h’.  
‘81h’ + ‘10h’  Model de referin ță de control pentru confiden țialitate, 
codat DER-TLV, care g ăzduiește concatenarea urm ă­
toarelor elemente de date (a se vedea apendicele 1,  
DSRCSecurityData , și apendicele 11 partea B capitolul 
13): 
— marcă temporală – 4 octeți 
— contor – 3 octe ți 
— numărul de serie al VU – 8 octe ți 
— versiunea cheii  master  DSRC – 1 octet  
Notă: a se vedea tabelul 49 din ISO/IEC 7816-4:2013 
pentru obiectul de date SM cu eticheta ‘81h’.  
‘8Eh’ + L  8E + 
‘XX..XXh’  MAC codat DER-TLV prin mesajul DSRC. Pentru 
calcularea și algoritmul MAC, a se vedea apendicele 
11 partea B capitolul 13.  
Notă: a se vedea tabelul 49 din ISO/IEC 7816-4:2013 
pentru obiectul de date SM cu eticheta ‘8Eh’.  
▼M1 
5 + L + 1  1  ‘00h’  Conform specifica țiilor din ISO/IEC 7816-4  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 232  
TCS_139  Mesaj de r ăspuns  
Octet  Lungime  Valoare  Descriere  
#1-#L  L  ‘XX..XXh’  Lipsește (în cazul unei erori) sau date descifrate (com ­
pletare eliminat ă) 
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, 
cardul returneaz ă starea ‘ 9000 ’. 
— ‘6A80 ’ indică existența unor parametri incorec ți în 
câmpul de date al comenzii (utilizat, de asemenea, în 
cazul în care obiectele de date nu sunt trimise în 
ordinea specificat ă). 
— ‘6A88 ’ indică faptul că datele men ționate nu sunt 
disponibile, și anume cheia  master  DSRC identificat ă 
nu este disponibil ă. 
— ‘6900 ’ indică faptul că verificarea sumei de verificare 
criptografice sau decriptarea datelor a e șuat. 
▼M1 
— ‘6985 ’ indică faptul că marca temporal ă de 4 octe ți 
furnizată în câmpul de date al comenzii este anterioar ă 
cardValidityBegin sau posterioar ă cardExpiryDate.  
▼B 
4. STRUCTURA CARDURILOR DE TAHOGRAF  
Prezenta sec țiune specific ă structurile de fi șiere ale cardurilor de 
tahograf pentru stocarea datelor accesibile.  
Ea nu specific ă structurile interne care depind de produc ătorul 
cardului, precum anteturile fi șierelor, nici stocarea și procesarea 
elementelor de date necesare doar pentru uz intern, precum
  
,
 ,
  
sau
 .  
TCS_140 Un card de tahograf de genera ția 2 trebuie s ă cuprindă 
fișierul master  MF și o aplicație tahografic ă de genera ția 
1 și una de genera ția 2 de acela și tip (de exemplu, apli ­
cațiile cardului de conduc ător auto).  
TCS_141 Un card de tahograf trebuie s ă fie compatibil cel pu țin cu 
numărul minim de înregistr ări specificat pentru aplica țiile 
corespondente și trebuie s ă nu permit ă mai multe înre ­
gistrări decât num ărul maxim de înregistr ări specificat 
pentru aplica țiile corespondente.  
Numărul minim și numărul maxim de înregistr ări pentru 
diferitele aplica ții sunt specificate în prezentul capitol.  
Pentru condi țiile de securitate utilizate în cadrul normelor 
de acces pe parcursul prezentului capitol, a se consulta 
capitolul 3.3. În general, modul de acces „read” denot ă 
comanda READ BINARY cu octet INS par și, dacă este 
compatibil, impar, cu excep ția EF  Sensor_Installation_Data  
din cardul de atelier, a se vedea TCS_156 și TCS_160. 
Modul de acces „update” denot ă comanda UPDATE 
BINARY cu octet INS par și, dacă este compatibil, 
impar, iar modul de acces „select” denot ă comanda 
SELECT.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 233  
4.1. Fi șier master  MF  
TCS_142 Dup ă personalizarea sa, fi șierul master  MF trebuie s ă aibă 
următoarea structur ă permanent ă a fișierelor și următoarele 
norme de accesare a fi șierelor:  
Notă: identificatorul de EF scurt SFID este dat ca num ăr 
zecimal, de exemplu valoarea 30 corespunde lui 11110 în 
cod binar.
  
În acest tabel este folosit ă următoarea abreviere pentru 
condiția de securitate:  
SC1 ALW SAU SM-MAC-G2  
TCS_143 Structura tuturor EF trebuie s ă fie transparent ă. 
TCS_144 Fi șierul master  MF trebuie s ă aibă următoarea structur ă de 
date:
  
TCS_145 Fi șierul elementar EF DIR trebuie s ă conțină următoarele 
obiecte de date legate de aplica ții: ‘61 08 4F 06 FF 54 41 
43 48 4F 61 08 4F 06 FF 53 4D 52 44 54’  
TCS_146 Fi șierul elementar EF ATR/INFO trebuie s ă fie prezent în 
cazul în care cardul de tahograf indic ă, în ATR-ul s ău, că 
este compatibil cu câmpuri cu lungime extins ă. În acest 
caz, EF ATR/INFO con ține obiectul de date informativ 
cu lungime extins ă (DO‘7F66’), conform specifica țiilor 
din ISO/IEC 7816-4:2013, clauza 12.7.1.  
TCS_147 Fi șierul elementar EF  Extended_Length  trebuie s ă fie 
prezent în cazul în care cardul de tahograf indic ă, în 
ATR-ul său, că este compatibil cu câmpuri cu lungime 
extinsă. În acest caz, EF-ul trebuie s ă conțină următorul 
obiect de date: ‘02 01 xx’, unde valoarea ‘xx’ indic ă 
dacă câmpurile cu lungime extins ă sunt compatibile cu 
protocolul T = 1 și / sau T = 0.  
Valoarea ‘01’ arat ă compatibilitatea câmpului cu lungime 
extinsă cu protocolul T = 1.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 234  
Valoarea ‘10’ arat ă compatibilitatea câmpului cu lungime 
extinsă cu protocolul T = 0.  
Valoarea ‘11’ arat ă compatibilitatea câmpului cu lungime 
extinsă cu protocolul T = 1 și cu protocolul T = 0.  
4.2. Aplica ții de card de conduc ător auto  
4.2.1  Aplica ția de card de conduc ător auto de genera ția 1 
TCS_148 Dup ă personalizarea sa, aplica ția de card de conduc ător 
auto de genera ția 1 trebuie s ă aibă următoarea structur ă 
permanentă a fișierelor și următoarele norme de accesare 
a fișierelor:
  
În acest tabel sunt folosite urm ătoarele abrevieri pentru 
condițiile de securitate:  
SC1 ALW SAU SM-MAC-G2  
SC2 ALW SAU SM-MAC-G1 SAU SM-MAC-G2  
SC3 SM-MAC-G1 SAU SM-MAC-G2  
TCS_149 Structura tuturor EF trebuie s ă fie transparent ă. 
TCS_150 Aplica ția de card de conduc ător auto de genera ția 1 trebuie 
să aibă următoarea structur ă de date:  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 235
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 236
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 237  
TCS_151 Urm ătoarele valori, utilizate pentru a specifica dimensiuni 
în tabelul de mai sus, reprezint ă valorile pentru num ărul 
minim și maxim de înregistr ări pe care structura de date 
a cardului de conduc ător auto trebuie s ă le utilizeze pentru 
o aplicație de genera ția 1:
  
4.2.2  Aplica ția de card de conduc ător auto de genera ția 2 
TCS_152 Dup ă personalizarea sa, aplica ția de card de conduc ător 
auto de genera ția 2 trebuie s ă aibă următoarea structur ă 
permanentă a fișierelor și următoarele norme de accesare 
a fișierelor.  
Notă: identificatorul de EF scurt SFID este dat ca num ăr 
zecimal, de exemplu valoarea 30 corespunde lui 11110 în 
cod binar.
  
În acest tabel este folosit ă următoarea abreviere pentru 
condiția de securitate:  
SC1 ALW SAU SM-MAC-G2  
TCS_153 Structura tuturor EF trebuie s ă fie transparent ă. 
TCS_154 Aplica ția de card de conduc ător auto de genera ția 2 trebuie 
să aibă următoarea structur ă de date:  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 238
  
► (1) M1 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 239
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 240
  
► (1) M1 
TCS_155 Urm ătoarele valori, utilizate pentru a specifica dimensiuni 
în tabelul de mai sus, reprezint ă valorile pentru num ărul 
minim și maxim de înregistr ări pe care structura de date 
a cardului de conduc ător auto trebuie s ă le utilizeze pentru 
o aplicație de genera ția 2:
  
► (1) M1 
4.3. Aplica ții de card de atelier  
4.3.1  Aplica ția de card de atelier de genera ția 1 
TCS_156 Dup ă personalizarea sa, aplica ția de card de atelier de 
generația 1 trebuie s ă aibă următoarea structur ă permanent ă 
a fișierelor și următoarele norme de accesare a fi șierelor:  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 241
  
În acest tabel sunt folosite urm ătoarele abrevieri pentru 
condițiile de securitate:  
SC1 ALW SAU SM-MAC-G2  
SC2 ALW SAU SM-MAC-G1 SAU SM-MAC-G2  
SC3 SM-MAC-G1 SAU SM-MAC-G2  
▼M1 
SC4 Pentru comanda READ BINARY cu octet INS par:  
(SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR  
(SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)  
Pentru comanda READ BINARY cu octet INS 
impar (dac ă este compatibil): NEV  
▼B 
TCS_157 Structura tuturor EF trebuie s ă fie transparent ă. 
TCS_158 Aplica ția de card de atelier de genera ția 1 trebuie s ă aibă 
următoarea structur ă de date:  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 242
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 243
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 244
  
TCS_159 Urm ătoarele valori, utilizate pentru a specifica dimensiuni 
în tabelul de mai sus, reprezint ă valorile pentru num ărul 
minim și maxim de înregistr ări pe care structura de date 
a cardului de atelier trebuie s ă le utilizeze pentru o aplica ție 
de generația 1:
  
4.3.2  Aplica ția de card de atelier de genera ția 2 
TCS_160 Dup ă personalizarea sa, aplica ția de card de atelier de 
generația 2 trebuie s ă aibă următoarea structur ă permanent ă 
a fișierelor și următoarele norme de accesare a fi șierelor.  
Notă: identificatorul de EF scurt SFID este dat ca num ăr 
zecimal, de exemplu valoarea 30 corespunde lui 11110 în 
cod binar.
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 245  
În acest tabel sunt folosite urm ătoarele abrevieri pentru 
condițiile de securitate:  
SC1 ALW SAU SM-MAC-G2  
SC5 Pentru comanda READ BINARY cu octet INS par: 
SM-C-MAC-G2 ȘI SM-R-ENC-MAC-G2  
Pentru comanda READ BINARY cu octet INS 
impar (dac ă este compatibil): NEV  
TCS_161 Structura tuturor EF trebuie s ă fie transparent ă. 
TCS_162 Aplica ția de card de atelier de genera ția 2 trebuie s ă aibă 
următoarea structur ă de date:
  
► (1) (2) M1 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 246
  
► (1) M1 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 247
  
► (1) M1 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 248  
TCS_163 Urm ătoarele valori, utilizate pentru a specifica dimensiuni 
în tabelul de mai sus, reprezint ă valorile pentru num ărul 
minim și maxim de înregistr ări pe care structura de date 
a cardului de atelier trebuie s ă le utilizeze pentru o aplica ție 
de generația 2:
  
► (1) M1 
4.4. Aplica ții de card de control  
4.4.1  Aplica ția de card de control de genera ția 1 
TCS_164 Dup ă personalizarea sa, aplica ția de card de control de 
generația 1 trebuie s ă aibă următoarea structur ă permanent ă 
a fișierelor și următoarele norme de accesare a fi șierelor:
  
În acest tabel sunt folosite urm ătoarele abrevieri pentru 
condițiile de securitate:  
SC1 ALW SAU SM-MAC-G2  
SC2 ALW SAU SM-MAC-G1 SAU SM-MAC-G2  
SC3 SM-MAC-G1 SAU SM-MAC-G2  
SC6 EXT-AUT-G1 SAU SM-MAC-G1 SAU SM-MAC- 
G2 
TCS_165 Structura tuturor EF trebuie s ă fie transparent ă. 
TCS_166 Aplica ția de card de control de genera ția 1 trebuie s ă aibă 
următoarea structur ă de date:  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 249
  
TCS_167 Urm ătoarele valori, utilizate pentru a specifica dimensiuni 
în tabelul de mai sus, reprezint ă valorile pentru num ărul 
minim și maxim de înregistr ări pe care structura de date 
a cardului de control trebuie s ă le utilizeze pentru o 
aplicație de genera ția 1:
  
4.4.2  Aplica ția de card de control de genera ția 2 
TCS_168 Dup ă personalizarea sa, aplica ția de card de control de 
generația 2 trebuie s ă aibă următoarea structur ă permanent ă 
a fișierelor și următoarele norme de accesare a fi șierelor.  
Notă: identificatorul de EF scurt SFID este dat ca num ăr 
zecimal, de exemplu valoarea 30 corespunde lui 11110 în 
cod binar.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 250
  
În acest tabel este folosit ă următoarea abreviere pentru 
condiția de securitate:  
SC1 ALW SAU SM-MAC-G2  
TCS_169 Structura tuturor EF trebuie s ă fie transparent ă. 
TCS_170 Aplica ția de card de control de genera ția 2 trebuie s ă aibă 
următoarea structur ă de date:
  
TCS_171 Urm ătoarele valori, utilizate pentru a specifica dimensiuni 
în tabelul de mai sus, reprezint ă valorile pentru num ărul 
minim și maxim de înregistr ări pe care structura de date 
a cardului de control trebuie s ă le utilizeze pentru o 
aplicație de genera ția 2: ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 251
  
4.5. Aplica ții de card de societate  
4.5.1  Aplica ția de card de societate de genera ția 1 
TCS_172 Dup ă personalizarea sa, aplica ția de card de societate de 
generația 1 trebuie s ă aibă următoarea structur ă permanent ă 
a fișierelor și următoarele norme de accesare a fi șierelor:
  
În acest tabel sunt folosite urm ătoarele abrevieri pentru 
condițiile de securitate:  
SC1 ALW SAU SM-MAC-G2  
SC2 ALW SAU SM-MAC-G1 SAU SM-MAC-G2  
SC3 SM-MAC-G1 SAU SM-MAC-G2  
SC6 EXT-AUT-G1 SAU SM-MAC-G1 SAU SM-MAC- 
G2 
TCS_173 Structura tuturor EF trebuie s ă fie transparent ă. 
TCS_174 Aplica ția de card de societate de genera ția 1 trebuie s ă aibă 
următoarea structur ă de date:
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 252  
TCS_175 Urm ătoarele valori, utilizate pentru a specifica dimensiuni 
în tabelul de mai sus, reprezint ă valorile pentru num ărul 
minim și maxim de înregistr ări pe care structura de date 
a cardului de societate trebuie s ă le utilizeze pentru o 
aplicație de genera ția 1:
  
4.5.2  Aplica ția de card de societate de genera ția 2 
TCS_176 Dup ă personalizarea sa, aplica ția de card de societate de 
generația 2 trebuie s ă aibă următoarea structur ă permanent ă 
a fișierelor și următoarele norme de accesare a fi șierelor.  
Notă: identificatorul de EF scurt SFID este dat ca num ăr 
zecimal, de exemplu valoarea 30 corespunde lui 11110 în 
cod binar.
  
În acest tabel este folosit ă următoarea abreviere pentru 
condiția de securitate:  
SC1 ALW SAU SM-MAC-G2  
TCS_177 Structura tuturor EF trebuie s ă fie transparent ă. 
TCS_178 Aplica ția de card de societate de genera ția 2 trebuie s ă aibă 
următoarea structur ă de date:
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 253  
TCS_179 Urm ătoarele valori, utilizate pentru a specifica dimensiuni 
în tabelul de mai sus, reprezint ă valorile pentru num ărul 
minim și maxim de înregistr ări pe care structura de date 
a cardului de societate trebuie s ă le utilizeze pentru o 
aplicație de genera ția 2:
 ▼B
02016R0799 — RO — 26.02.2020 — 002.001 — 254 
Apendicele 3  
PICTOGRAME 
PIC_001 Tahograful poate folosi op țional următoarele pictograme și combina ții 
de pictograme (sau pictograme și combina ții suficient de asem ănătoare 
pentru a fi clar identificabile cu acestea):  
1. PICTOGRAME DE BAZ Ă
Persoane Acțiuni Moduri de funcționare
  
Societate Mod societate
  
Agent de control Control Mod de control
  
Conducător auto Conducere Mod operațional
  
Atelier/stație de testare Inspecție/etalonare Mod calibrare
  
Producător 
Activități Durată
 
Disponibil Perioada de disponibilitate curent ă
 
Conducere Timp de conducere continuă
 
Odihnă Perioada de odihnă curentă
 
Alte activit ăți Ziua de lucru curentă
 
Pauză Durata cumulată a pauzelor
  
Necunoscut ă 
Echipament Funcții
 
Slot pentru cardul de conduc ător 
auto
 
Slot pentru cardul copilotului
  
Card
  
Ceas
  
Afișaj Afișare
 
Stocare extern ă Descărcare
  
Sursă de alimentare (electric ă)
 
Imprimantă/document imprimat  Imprimare
  
Senzor
  
Dimensiunea pneurilor
  
Vehicul/unitate montată pe vehicul
  
Echipament GNSS
  
Echipament de detectare la distan ță
 
Interfață ITS ▼B
02016R0799 — RO — 26.02.2020 — 002.001 — 255 
Condiții specifice
  
În afara zonei de aplicare a reglement ărilor
 
Traversare cu feribotul sau cu trenul  
Diverse
  
Evenimente
 Anomalii
  
Începutul zilei de lucru
 Sfârșitul zilei de lucru
  
Loc
 
Introducere manual ă a activit ăților 
conducătorului auto
  
Securitate
  
Viteză
 
Oră
 
Total/rezumat  
Calificative  
24h Zilnic
  
Săptămânal
  
Două săptămâni
  
De la sau pân ă la 
2. COMBINA ȚII DE PICTOGRAME
Diverse
  
Locul controlului
  
Loc de începere a zilei de lucru
  Loc de încheiere a zilei de lucru  
▼M1
Poziția după un timp de conducere 
acumulat de trei ore  
▼B
De la ora
 Până la ora
  
De la vehicul
  
În afara zonei de aplicare a reglemen ­
tărilor, început
  În afara zonei de aplicare a 
reglementărilor, sfârșit 
Carduri
  
Card de conduc ător auto
  
Card de societate
  
Card de control
  
Card de atelier
  
Niciun card  ▼B
02016R0799 — RO — 26.02.2020 — 002.001 — 256 
Conducere
  
Conducere în echipaj
  
Timp de conducere pentru o s ăptămână
 
Timp de conducere pentru dou ă săptămâni  
Documente imprimate
  
Document imprimat zilnic privind activit ățile conduc ătorului auto extrase 
de pe card
  
Document imprimat zilnic privind activit ăților conduc ătorului auto extrase 
din VU
  
Document imprimat privind evenimentele și anomaliile de pe card
  
Document imprimat privind evenimentele și anomaliile din VU
  
Document imprimat privind datele tehnice
  
Document imprimat privind dep ășirea limitei de vitez ă 
Evenimente
  
Introducerea unui card nevalabil
  
Conflict de carduri
  
Suprapunere a timpului
  
Conducere f ără un card corespunz ător
 
Introducerea cardului în timpul conducerii
  
Încheiere incorect ă a ultimei sesiuni de utilizare a cardului
  
Depășire a limitei de vitez ă
 
Întrerupere a aliment ării cu energie electric ă
 
Eroare privind datele de la senzorul de mi șcare
 
Conflict privind deplasarea vehiculului
  
Încălcare a securit ății
 
Reglarea orei (de c ătre atelier)  
▼M1
Conflict or ă sau reglarea orei (de c ătre atelier)  
▼B
Control pentru dep ășirea limitei de vitez ă 
▼M1
Absența informațiilor de pozi ționare de la receptorul GNSS sau Eroare de 
comunicare cu echipamentul GNSS extern
  
Eroare de comunicare cu echipamentul de comunicare la distan ță 
▼B
Anomalii
  
Anomalie a cardului (slot pentru cardul de conduc ător auto)
  
Anomalie a cardului (slot pentru cardul copilotului)
  
Anomalie a afi șajului  ▼B
02016R0799 — RO — 26.02.2020 — 002.001 — 257 
Anomalie la desc ărcare
  
Anomalie a imprimantei
  
Anomalie a senzorului
  
Anomalie intern ă a VU
  
Anomalie a GNSS
  
Anomalie privind detectarea la distan ță 
Procedur ă privind introducerea manual ă a datelor
  
Aceeași zi de lucru în curs?
  
Sfârșitul zilei de lucru anterioare?
  
Confirmaț i sau introduce ți locul de încheiere a zilei de lucru
  
Introduceți ora de pornire
  
Introduceți locul de începere a zilei de lucru.  
Notă: În apendicele 4 sunt definite combina ții suplimentare de picto ­
grame, pentru formarea de blocuri de imprimare sau de identificatori 
de înregistrare.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 258  
Apendicele 4  
DOCUMENTE IMPRIMATE  
CUPRINS  
1. GENERALIT ĂȚI 
2. SPECIFICA ȚII PRIVIND BLOCURILE DE DATE  
3. SPECIFICA ȚII REFERITOARE LA DOCUMENTELE IMPRIMATE  
3.1. Document imprimat zilnic privind activit ățile conduc ătorului auto 
extrase de pe card  
3.2. Document imprimat zilnic privind activit ăților conduc ătorului auto 
extrase din VU  
3.3. Document imprimat privind evenimentele și anomaliile de pe card  
3.4. Document imprimat privind evenimentele și anomaliile din VU  
3.5. Document imprimat privind datele tehnice  
3.6. Document imprimat privind dep ășirea limitei de vitez ă 
3.7. Istoricul introducerii cardurilor  
1. GENERALIT ĂȚI 
Fiecare document imprimat este construit prin înl ănțuirea a diverse 
blocuri de date, identificate, dac ă este cazul, prin intermediul unui 
identificator de bloc.  
Un bloc de date con ține una sau mai multe înregistr ări, identificate, 
dacă este cazul, cu un identificator de înregistrare.  
PRT_001 Când un identificator de înregistrare urmeaz ă imediat dup ă un 
identificator de bloc, identificatorul de înregistrare nu este 
imprimat.  
PRT_002 În cazul în care un element de date este necunoscut sau nu 
trebuie imprimat din motive legate de drepturile de acces la 
date, în locul acestuia se imprim ă spații. 
PRT_003 Dac ă întregul con ținut al unui rând este necunoscut sau nu 
trebuie imprimat, se omite întregul rând.  
PRT_004 La imprimare, câmpurile de date numerice sunt aliniate la 
dreapta, cu un spa țiu de separare pentru mii și milioane și 
fără zerouri la început.  
PRT_005 La imprimare, câmpurile de date constituite din șiruri de 
caractere sunt aliniate la stânga și completate cu spa ții până 
la lungimea elementului de date sau trunchiate la lungimea 
elementului de date, atunci când este necesar (nume și 
adrese).  
PRT_006 În cazul trecerii la un nou rând din cauza lungimii textului, la 
începutul noului rând ar trebui imprimat un caracter special 
(un punct la jum ătatea înălțimii rândului, „•”).  
2. SPECIFICA ȚII PRIVIND BLOCURILE DE DATE  
În acest capitol sunt utilizate urm ătoarele nota ții convenționale pentru 
formatare:  
— caracterele  aldine  indică faptul că trebuie imprimat un text în clar 
(textul se imprim ă cu caractere normale);  ▼B
02016R0799 — RO — 26.02.2020 — 002.001 — 259  
— caracterele normale reprezint ă variabile (pictograme sau date) care 
trebuie înlocuite cu valorile lor în scopul imprim ării; 
— denumirile variabilelor au fost completate cu liniu țe de subliniere 
pentru a ilustra lungimea elementului de date disponibil pentru 
variabila în cauz ă; 
— datele sunt specificate în formatul „zz/ll/aaaa” (zi, lun ă, an). Se 
poate utiliza, de asemenea, formatul „zz.ll.aaaa”;  
— termenul „identificarea cardului” reprezint ă combina ția dintre: tipul 
de card, reprezentat printr-o combina ție de pictograme de card, codul 
statului membru care a emis cardul, o bar ă oblică orientat ă spre 
dreapta și numărul cardului cu indexul de înlocuire și indexul de 
reînnoire separate de un spa țiu: 
P
 x  x  x  / x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x
 Combinații de 
pictograme de card  
Codul statului 
membru emitent Primele 14 caractere din num ărul cardului 
(care includ, eventual, un indice secven țial)
 
Indice de înlocuire  
Indice de reînnoire ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 260  
PRT_007 Documentele imprimate utilizeaz ă următoarele blocuri de date și/sau 
înregistrări de date, în conformitate cu urm ătoarele semnifica ții și 
formate:
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 261
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 262
  
► (1) (2) M1 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 263
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 264
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 265
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 266
  
3. SPECIFICA ȚII REFERITOARE LA DOCUMENTELE IMPRIMATE  
În prezentul capitol s-au folosit urm ătoarele nota ții convenționale: 
N A se imprima blocul sau înregistrarea cu num ărul N.  
N A se imprima blocul sau înregistrarea cu num ărul N, opera țiune 
repetată ori de câte ori este necesar.  
X/Y A se imprima blocurile sau înregistr ările X și/sau Y, dup ă caz, cu 
repetarea opera țiunii ori de câte ori este necesar.  
3.1. Document imprimat zilnic privind activit ățile conduc ătorului auto 
extrase de pe card  
PRT_008 Documentul imprimat zilnic privind activit ățile conduc ă­
torului auto extrase de pe card respect ă următorul format: 
1 Data și ora imprim ării documentului  
2 Tipul de document imprimat  
3 Identificarea agentului de control (dac ă în VU este introdus un card de 
control)  
3 Identificarea conduc ătorului auto (de pe cardul care face obiectul 
imprimării + GEN)  
4 Identificarea vehiculului (vehiculul din care se imprim ă datele)  
5 Identificarea VU (VU din care se imprim ă datele + GEN)  
6 Ultima etalonare a respectivei VU  
7 Ultimul control la care a fost supus conduc ătorul auto inspectat  
8 Delimitator al activit ăților conduc ătorului auto  
8a Condiție „În afara zonei de aplicare a reglement ărilor” la începutul 
zilei respective  
8.1a / 8.1b / 8.1c / 8.2 / 
8.3 / 8.3a / 8.4  Activitățile conduc ătorului auto în ordine cronologic ă 
11 Delimitator al rezumatului zilnic  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 267  
11.4 Locurile introduse în ordine cronologic ă 
▼M1 
11.5 Poziții după un timp de conducere acumulat de trei ore în ordine 
cronologic ă 
▼B 
11.6 Totaluri activitate  
12.1 Evenimente sau anomalii din delimitatorul cardului  
12.4 Înregistrări de evenimente/anomalii (ultimele 5 evenimente sau 
anomalii înregistrate pe card)  
13.1 Evenimente sau anomalii extrase din delimitatorul VU  
13.4 Înregistrări de evenimente/anomalii (ultimele 5 evenimente sau 
anomalii înregistrate sau în curs de desf ășurare în VU)  
22.1 Locul controlului  
22.2 Semnătura agentului de control  
22.5 Semnătura conduc ătorului auto  
3.2. Document imprimat zilnic privind activit ăților conduc ătorului auto 
extrase din VU  
PRT_009 Documentul imprimat zilnic privind activit ăților conduc ă­
torului auto extrase din VU respect ă următorul format:  
▼M1 
1 Data și ora imprim ării documentului  
2 Tipul de document imprimat  
3 Identificarea titularului cardului (pentru toate cardurile 
introduse în VU + GEN)  
4 Identificarea vehiculului (vehiculul din care se imprim ă 
datele)  
5 Identificarea VU (VU din care se imprim ă datele + GEN)  
6 Ultima etalonare a respectivei VU  
7 Ultimul control al tahografului respectiv  
9 Delimitator al activit ăților conduc ătorului auto  
10 Delimitator al slotului pentru cardul de conduc ător auto 
(slotul 1)  
10a Condiție „În afara zonei de aplicare a reglement ărilor” la 
începutul zilei respective  
10.1 / 10.2 / 10.3 / 
10.3a / 10.4  Activități în ordine cronologic ă (slot pentru cardul de 
conducător auto)  
10 Delimitator al slotului pentru cardul copilotului (slotul 2)  
10a Condiție „În afara zonei de aplicare a reglement ărilor” la 
începutul zilei respective  
10.1 / 10.2 / 10.3 / 
10.3a / 10.4  Activități în ordine cronologic ă (slot pentru cardul copilo ­
tului)  
11 Delimitator al rezumatului zilnic  
11.1 Rezumatul perioadelor f ără card în slotul pentru cardul de 
conducător auto  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 268  
11.4 Locurile introduse în ordine cronologic ă 
11.5 Poziții după un timp de conducere acumulat de trei ore în 
ordine cronologic ă 
11.7 Totaluri activitate  
11.2 Rezumatul perioadelor f ără card în slotul pentru cardul copi ­
lotului  
11.4 Locurile introduse în ordine cronologic ă 
11.5 Poziții după un timp de conducere acumulat de trei ore în 
ordine cronologic ă 
11.8 Totaluri activitate  
11.3 Rezumatul activit ăților unui conduc ător auto, pentru ambele 
sloturi  
11.4 Locurile introduse de respectivul conduc ător auto în ordine 
cronologic ă 
11.5 Poziții după un timp de conducere acumulat de trei ore în 
ordine cronologic ă 
11.9 Totaluri activitate pentru respectivul conduc ător auto  
13.1 Delimitator evenimente/anomalii  
13.4 Înregistrări de evenimente/anomalii (ultimele cinci 
evenimente sau anomalii înregistrate sau în curs de 
desfășurare în VU)  
22.1 Locul controlului  
22.2 Semnătura agentului de control  
22.3 De la ora (spa țiu disponibil pentru ca un conduc ător auto 
fără card să indice  
22.4 până la ora perioadele care sunt relevante pentru el)  
22.5 Semnătura conduc ătorului auto  
▼B 
3.3. Document imprimat privind evenimentele și anomaliile de pe card  
PRT_010 Documentul imprimat privind evenimentele și anomaliile de 
pe card respect ă următorul format: 
1 Data și ora imprim ării documentului  
2 Tipul de document imprimat  
3 Identificarea agentului de control (dac ă în VU este introdus un card 
de control + GEN)  
3 Identificarea conduc ătorului auto (de pe cardul care face obiectul 
imprimării) 
4 Identificarea vehiculului (vehiculul din care se imprim ă datele)  
12.2 Delimitator al evenimentelor  
12.4 Înregistrări ale evenimentelor (toate evenimentele stocate pe card)  
12.3 Delimitator al anomaliilor  
12.4 Înregistrări ale anomaliilor (toate anomaliile stocate pe card)  
22.1 Locul controlului  
22.2 Semnătura agentului de control  
22.5 Semnătura conduc ătorului auto  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 269  
3.4. Document imprimat privind evenimentele și anomaliile din VU  
PRT_011 Documentul imprimat privind evenimentele și anomaliile din 
VU respect ă următorul format: 
1 Data și ora imprim ării documentului  
2 Tipul de document imprimat  
3 Identificarea titularului cardului (pentru toate cardurile introduse în 
VU + GEN)  
4 Identificarea vehiculului (vehiculul din care se imprim ă datele)  
13.2 Delimitator al evenimentelor  
13.4 Înregistrări ale evenimentelor (toate evenimentele stocate sau în curs 
de desfășurare în VU)  
13.3 Delimitator al anomaliilor  
13.4 Înregistrări ale anomaliilor (toate anomaliile stocate sau în curs de 
desfășurare în VU)  
22.1 Locul controlului  
22.2 Semnătura agentului de control  
22.5 Semnătura conduc ătorului auto  
3.5. Document imprimat privind datele tehnice  
PRT_012 Documentul imprimat privind datele tehnice respect ă 
următorul format: 
1 Data și ora imprim ării documentului  
2 Tipul de document imprimat  
3 Identificarea titularului cardului (pentru toate cardurile introduse în 
VU + GEN)  
4 Identificarea vehiculului (vehiculul din care se imprim ă datele)  
14 Identificarea VU  
15 Identificarea senzorului  
15.1 Date privind asocierea senzorului (toate datele disponibile în ordine 
cronologic ă) 
16 Identificarea GNSS  
16.1 Date privind cuplarea echipamentului GNSS extern (toate datele 
disponibile în ordine cronologic ă) 
17 Delimitator al datelor de etalonare  
17.1 Înregistrări ale etalon ărilor (toate înregistr ările disponibile în ordine 
cronologic ă) 
18 Delimitator al regl ării orei  
18.1 Înregistrări ale reglării orei (toate înregistr ările disponibile din înregis ­
trările reglării orei și ale datelor de etalonare)  
19 Cel mai recent eveniment și cea mai recent ă anomalie înregistrate în 
VU ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 270  
3.6. Document imprimat privind dep ășirea limitei de vitez ă 
PRT_013 Documentul imprimat privind dep ășirea limitei de vitez ă 
respectă următorul format: 
1 Data și ora imprim ării documentului  
2 Tipul de document imprimat  
3 Identificarea titularului cardului (pentru toate cardurile introduse în 
VU + GEN)  
4 Identificarea vehiculului (vehiculul din care se imprim ă datele)  
20 Informații privind controalele pentru dep ășirea limitei de vitez ă 
21.1 Identificatorul datelor privind dep ășirile limitei de vitez ă 
21.4 / 21.5  Prima depășire a limitei de vitez ă după ultima etalonare  
21.2 Identificatorul datelor privind dep ășirile limitei de vitez ă 
21.4 / 21.5  Cele mai grave 5 dep ășiri ale limitei de vitez ă din ultimele 365 de zile  
21.3 Identificatorul datelor privind dep ășirile limitei de vitez ă 
21.4 / 21.5  Cea mai grav ă depășire a limitei de vitez ă pentru fiecare dintre 
ultimele 10 zile de producere a evenimentului  
22.1 Locul controlului  
22.2 Semnătura agentului de control  
22.5 Semnătura conduc ătorului auto  
3.7. Istoricul introducerii cardurilor  
▼M1 
PRT_014 Documentul imprimat privind istoricul introducerii cardurilor 
respectă următorul format: 
1 Data și ora imprim ării documentului  
2 Tipul de document imprimat  
3 Identificarea titularului cardului (pentru toate cardurile introduse în 
VU) 
23 Cel mai recent card introdus în VU  
23.1 Carduri introduse (pân ă la 88 de înregistr ări) 
12.3 Delimitator al anomaliilor  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 271  
Apendicele 5  
AFIȘAJUL  
În prezentul apendice s-au folosit urm ătoarele nota ții convenționale de formatare:  
— caracterele  aldine  indică textul în clar care urmeaz ă să fie afișat (afișajul 
rămâne în caractere normale);  
— caracterele normale indic ă variabilele (pictograme sau date) care trebuie s ă fie 
înlocuite cu valorile lor în scopul afi șării: 
— zz ll aaaa: ziua, luna, anul,  
— hh: ore,  
— mm: minute,  
— D: pictograma pentru durat ă, 
— EF: combina ție de pictograme pentru evenimente sau 
anomalii,  
— O: pictograma modului de func ționare.  
DIS_001 Tahograful afi șează datele folosind urm ătoarele formate:  
Date  Format  
Afișaj implicit  
Ora locală
 
Mod de func ționare
  
Informații privind conduc ătorul auto
  
Informații privind copilotul
  
Condiția „În afara zonei de aplicare a reglement ărilor” 
deschisă
 
Afișaj de avertizare  
Depășirea timpului de conducere continu ă
 
Eveniment sau anomalie
  
Alte afișaje 
Data UTC
  
ora 
Timpul de conducere continu ă și durata cumulat ă a pauzelor 
conducătorului auto
  
Timpul de conducere continu ă și durata cumulat ă a pauzelor 
copilotului
  
Timpul de conducere cumulat al conduc ătorului auto pentru 
săptămâna anterioar ă și cea curent ă
 
Timpul de conducere cumulat al copilotului pentru 
săptămâna anterioar ă și cea curent ă
 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 272  
Apendicele 6  
CONECTOR FRONTAL PENTRU ETALONARE ȘI DESCĂRCARE  
CUPRINS  
1. HARDWARE  
1.1. Conector  
1.2. Alocarea contactelor  
1.3. Schema func țională 
2. INTERFA ȚĂ DE DESC ĂRCARE  
3. INTERFA ȚĂ DE ETALONARE  
1. HARDWARE  
1.1. Conector  
INT_001 Conectorul pentru desc ărcare/etalonare trebuie s ă fie un conector 
cu 6 contacte, care s ă poată fi accesat de la panoul frontal, f ără a 
fi necesară deconectarea unei p ărți a tahografului, și trebuie s ă 
respecte detaliile din urm ătoarea schi ță (toate dimensiunile sunt 
în milimetri):
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 273  
În următoarea diagram ă este prezentat ă o fișă obișnuită de 
conectare cu 6 contacte:
  
1.2. Alocarea contactelor  
INT_002 Contactele se aloc ă în conformitate cu tabelul urm ător: 
Contact  Descriere  Observa ție 
1 Pol negativ al bateriei  Conectat la polul negativ al bateriei vehiculului  
2 Comunicarea datelor  Linia K (ISO 14230-1)  
3 RxD – Desc ărcare  Date de intrare în tahograf  
4 Semnal de intrare/ie șire Etalonare  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 274  
Contact  Descriere  Observa ție 
5 Putere de ie șire permanent ă Intervalul de tensiune trebuie s ă fie identic cu cel pentru 
alimentarea electric ă a vehiculului minus 3 V pentru a lua 
în calcul c ăderea de tensiune din circuitele de protec ție. 
Ieșire de 40 mA  
6 TxD – Desc ărcare  Date de ie șire provenite de la tahograf  
1.3. Schema func țională 
INT_003 Schema func țională trebuie să respecte urm ătoarele indica ții:
 
2. INTERFA ȚĂ DE DESC ĂRCARE  
INT_004 Interfa ța de descărcare trebuie s ă respecte specifica țiile RS232.  
INT_005 Interfa ța de descărcare folose ște un bit de pornire, 8 bi ți de date 
cu un LSB (bitul cel mai pu țin semnificativ) la început, un bit de 
paritate par ă și 1 bit de oprire.
  
Organizarea octe ților de informa ții 
Bit de inițiere: un bit cu nivel logic 0;  
Biți de date: transmi și cu un LSB la început;  
Bit de paritate: paritate par ă 
Bit de oprire: un bit cu nivel logic 1  
La transmisia datelor numerice compuse din mai mult de un octet, octetul 
cel mai semnificativ este transmis la început și octetul cel mai pu țin 
semnificativ este transmis la sfâr șit. 
INT_006 Viteza de transmisie a datelor poate fi reglat ă într-un interval 
cuprins între 9 600 bps și 115 200 bps. Transmisia se realizeaz ă 
la viteza maxim ă posibilă, viteza de transmisie ini țială după 
începerea comunic ării fiind stabilit ă la 9 600 bps.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 275  
3. INTERFA ȚĂ DE ETALONARE  
INT_007 Comunic ările de date respect ă ISO 14230-1  Road vehicles  – 
Diagnostic systems  – Keyword protocol 2000  – Part 1: 
Physical layer , prima edi ție: 1999.  
INT_008 Semnalul de intrare/ie șire respect ă următoarele specifica ții elec­
trice:  
Parametru  Minim  Normal  Maxim  Observa ție 
U low (intrare)  1,0 V  I = 750 μA 
U high (intrare)  4 V  I = 200 μA 
Frecvență 4 kHz  
U low (ieșire) 1,0 V  I = 1 mA  
U high (ieșire) 4 V  I = 1 mA  
INT_009 Semnalul de intrare/ie șire trebuie s ă respecte urm ătoarele 
diagrame de timp:
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 276  
Apendicele 7  
PROTOCOALE DE DESC ĂRCARE A DATELOR  
CUPRINS  
1. INTRODUCERE  
1.1. Domeniul de aplicare  
1.2. Acronime și notații 
2. DESC ĂRCAREA DATELOR DE PE VU  
2.1. Procedura de desc ărcare  
2.2. Protocolul de desc ărcare a datelor  
2.2.1 Structura mesajului  
2.2.2 Tipuri de mesaje  
2.2.2.1 Solicitare de ini țiere a comunic ării (Start Communication 
Request )(SID 81)  
2.2.2.2 R ăspuns pozitiv la solicitarea de ini țiere a comunic ării 
(Positive Response Start Communication )(SID C1)  
2.2.2.3 Solicitare de începere a sesiunii de diagnosticare ( Start 
Diagnostic Session Request ) (SID 10)  
2.2.2.4 R ăspuns pozitiv la solicitarea de începere a sesiunii de 
diagnosticare ( Positive Response Start Diagnostic )(SID 50)  
2.2.2.5 Serviciul de control al leg ăturii ( Link Control Service ) (SID 
87) 
2.2.2.6 R ăspuns pozitiv la controlul leg ăturii ( Link Control Positive 
Response ) (SID C7)  
2.2.2.7 Solicitare de înc ărcare ( Request Upload )(SID 35)  
2.2.2.8 R ăspuns pozitiv la solicitarea de înc ărcare ( Positive 
Response Request Upload ) (SID 75)  
2.2.2.9 Solicitare de transfer de date ( Transfer Data Request ) (SID 
36) 
2.2.2.10 R ăspuns pozitiv la solicitarea de transfer de date ( Positive 
Response Transfer Data ) (SID 76)  
2.2.2.11 Solicitare de încheiere a transferului ( Request Transfer Exit ) 
(SID 37)  
2.2.2.12 R ăspuns pozitiv la solicitarea de încheiere a transferului 
(SID 77) ( Positive Response Request Transfer Exit ) 
2.2.2.13 Solicitare de încheiere a comunic ării (Stop Communication 
Request ) (SID 82)  
2.2.2.14 R ăspuns pozitiv la solicitarea de încheiere a comunic ării 
(Positive Response Stop Communication ) (SID C2)  
2.2.2.15 Confirmare de primire a sub-mesajului ( Acknowledge Sub 
Message ) (SID 83)  
2.2.2.16 R ăspuns negativ ( Negative Response ) (SID 7F)  
2.2.3 Fluxul mesajelor  
2.2.4 Sincronizare  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 277  
2.2.5 Gestionarea erorilor  
2.2.5.1 Etapa de ini țiere a comunic ării 
2.2.5.2 Etapa de comunicare  
2.2.6 Con ținutul mesajelor de r ăspuns  
2.2.6.1 R ăspuns pozitiv la solicitarea de transfer de date de 
prezentare general ă (Positive Response Transfer Data 
Overview ) 
2.2.6.2 R ăspuns pozitiv la solicitarea de transfer de date privind 
activitățile (Positive Response Transfer Data Activities ) 
2.2.6.3 R ăspuns pozitiv la solicitarea de transfer de date privind 
evenimentele și anomaliile ( Positive Response Transfer 
Data Events and Faults ) 
2.2.6.4 R ăspuns pozitiv la solicitarea de transfer de date privind 
viteza detaliat ă (Positive Response Transfer Data Detailed 
Speed ) 
2.2.6.5 R ăspuns pozitiv la solicitarea de transfer de date tehnice 
(Positive Response Transfer Data Technical Data ) 
2.3. Stocarea fi șierelor în ESM  
3. PROTOCOL DE DESC ĂRCARE DE PE CARDURILE 
DE TAHOGRAF  
3.1. Domeniu de aplicare  
3.2. Defini ții 
3.3. Desc ărcarea informa țiilor de pe card  
3.3.1 Secven ța de inițializare  
3.3.2 Secven ța de descărcare de fi șiere de date nesemnate  
3.3.3 Secven ța de descărcare de fi șiere de date semnate  
3.3.4 Secven ța de resetare a unui contor de etalonare.  
3.4. Formatul de stocare a datelor  
3.4.1 Introducere  
3.4.2 Formatul fi șierului  
4. DESC ĂRCAREA INFORMA ȚIILOR DE PE UN CARD 
DE TAHOGRAF PRIN INTERMEDIUL UNEI UNIT ĂȚI 
MONTATE PE VEHICUL  
1. INTRODUCERE  
Prezentul apendice cuprinde procedurile care trebuie urmate pentru a 
realiza diferite tipuri de desc ărcare de date pe un mediu de stocare 
extern, precum și protocoalele care trebuie puse în aplicare pentru a 
asigura transferul corect de date și compatibilitatea deplin ă a formatului 
datelor desc ărcate, pentru a permite oric ărui controlor s ă inspecteze 
aceste date și să poată verifica autenticitatea și integritatea acestora 
înainte de a le analiza.  
▼M1 
1.1. Domeniul de aplicare  
Datele pot fi desc ărcate pe un ESM:  
— de pe o unitate montat ă pe vehicul, cu ajutorul unui echipament 
inteligent dedicat (IDE) conectat la VU;  
— de pe un card de tahograf, cu ajutorul unui IDE conectat la un 
dispozitiv de interfa ță pentru card (IFD);  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 278  
— de pe un card de tahograf, prin intermediul unei unit ăți montate pe 
vehicul și cu ajutorul unui IDE conectat la VU.  
Pentru a permite verificarea autenticit ății și integrității datelor 
descărcate stocate pe un ESM, datele se descarc ă însoțite de o 
semnătură atașată în conformitate cu apendicele 11 „Mecanisme de 
securitate comune”. Se descarc ă, de asemenea, identificarea echipa ­
mentului surs ă (VU sau card) și certificatele sale de securitate (stat 
membru și echipament). Persoana care verific ă datele trebuie s ă 
dețină o cheie public ă europeană certificată. 
Datele desc ărcate de pe o VU sunt semnate utilizând apendicele 11 
„Mecanisme de securitate comune” partea B (sistemul tahografic de a 
doua genera ție), cu excep ția cazului în care controlul conduc ătorilor 
auto este efectuat de c ătre o autoritate de control din afara UE, 
utilizând un card de control de prim ă generație, caz în care datele 
sunt semnate cu apendicele 11 „Mecanisme de securitate comune” 
partea A (sistemul tahografic de prima genera ție), astfel cum se 
prevede în apendicele 15, „Migra ție”, cerința MIG_015.  
Prezentul apendice precizeaz ă, așadar, două tipuri de desc ărcări de date 
de pe VU:  
— tipul de genera ția 2 de desc ărcare a datelor de pe VU, furnizând 
structura de date de genera ția 2, semnat ă utilizând apendicele 11, 
„Mecanisme de securitate comune”, partea B;  
— tipul de genera ția 1 de desc ărcare a datelor de pe VU, furnizând 
structura de date de genera ția 1, semnat ă utilizând apendicele 11, 
„Mecanisme de securitate comune”, partea A.  
În mod similar, exist ă două tipuri de desc ărcări de date de pe cardurile 
de conducător auto de a doua genera ție introduse într-o VU, astfel cum 
este prevăzut la punctele 3 și 4 din prezentul apendice.  
▼B 
1.2. Acronime și notații 
În prezentul apendice sunt folosite urm ătoarele acronime:  
AID Identificator de aplica ție (Application Identifier ) 
ATR  Răspuns de resetare ( Answer To Reset ) 
CS Octet de sum ă de verificare ( Checksum byte ) 
FD Fișier dedicat ( Dedicated File ) 
DS_ Sesiune de diagnosticare ( Diagnostic Session ) 
EF Fișier elementar ( Elementary File ) 
ESM  Mediu de stocare extern ( External Storage Medium ) 
FID Identificatorul fi șierului [ File Identifier (File ID) ] 
FMT  Octet de format (primul octet al antetului mesajului) ( Format 
Byte) 
ICC Card cu circuite integrate ( Integrated Circuit Card ) 
IDE Echipament inteligent dedicat: echipamentul folosit la efec ­
tuarea desc ărcării datelor în ESM (de exemplu, un calculator 
personal)  
IFD Dispozitiv de interfa ță (Interface Device ) 
KWP  Keyword Protocol 2000  
LEN  Octet de lungime (ultimul octet al antetului mesajului) ( Length 
Byte) 
PPS Selecția parametrilor protocolului ( Protocol Parameter 
Selection ) 
PSO  Executarea unei opera țiuni de securitate ( Perform Security 
Operation ) 
SID Identificator de serviciu ( Service Identifier ) 
SRC  Octet surs ă (Source byte ) 
TGT  Octet țintă (Target Byte ) ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 279  
TLV  Valoarea lungimii etichetei ( Tag Length Value ) 
TREP  Parametru de r ăspuns la transfer ( Transfer Response Para ­
meter ) 
TRTP  Parametru de solicitare de transfer ( Transfer Request Para ­
meter ) 
VU Unitate montat ă pe vehicul ( Vehicle Unit ) 
2. DESC ĂRCAREA DATELOR DE PE VU  
2.1. Procedura de desc ărcare  
Pentru a efectua o desc ărcare de date de pe VU, operatorul trebuie s ă 
realizeze urm ătoarele opera țiuni: 
— să insereze cardul s ău de tahograf într-un slot pentru card al 
VU (*);  
— să conecteze IDE la conectorul de desc ărcare al VU;  
— să stabileasc ă conexiunea dintre IDE și VU;  
— să selecteze în IDE datele care trebuie desc ărcate și să trimită 
solicitarea la VU;  
— să încheie sesiunea de desc ărcare.  
2.2. Protocolul de desc ărcare a datelor  
Protocolul este structurat pe baza unei arhitecturi de tip  master/slave , 
unde IDE are rolul de  master  și VU are rolul de  slave . 
Structura, tipurile și fluxul mesajelor se bazeaz ă în principal pe 
protocolul  Keyword Protocol 2000  (KWP) ( ISO 14230-2 Road 
vehicles – Diagnostic systems – Keyword protocol 2000 – Part2: 
Data link layer ). 
Stratul de aplica ție se bazeaz ă în principal pe proiectul actual de 
standard ISO 14229-1 ( Road vehicles – Diagnostic systems – Part 1: 
Diagnostic services , versiunea 6 din 22 februarie 2001).  
2.2.1  Structura mesajului  
DDP_002 Toate mesajele schimbate între IDE și VU sunt formatate cu 
o structură care const ă în trei părți: 
— un antet compus dintr-un octet de format (FMT), un 
octet țintă (TGT), un octet surs ă (SRC) și, eventual, 
un octet de lungime (LEN);  
— un câmp de date compus dintr-un octet al identifica ­
torului de serviciu (SID) și un număr variabil de octe ți 
de date, care pot cuprinde un octet op țional de sesiune 
de diagnosticare (DS_) sau un octet op țional de 
parametru de transfer (TRTP sau TREP);  
— Sumă de verificare compus ă dintr-un octet de sum ă de 
verificare (CS).  
Antet  Câmp de date  Sum ă de verificare  
FMT  TGT  SRC  LEN  SID  DATE  …  …  …  CS  
4 octeți Maximum 255 de octe ți 1 octet  
Octetul TGT și octetul SRC reprezint ă adresa fizic ă a 
destinatarului și a inițiatorului mesajului. Valorile sunt F0 
Hex pentru IDE și EE Hex pentru VU.  
Octetul LEN reprezint ă lungimea câmpului de date.  ▼B 
(*) Cardul introdus va declan șa drepturile corespunz ătoare de acces la func ția de descărcare 
și la date. Datele pot fi totu și descărcate de pe un card de conduc ător auto introdus într- 
unul din sloturile VU atunci când în cel ălalt slot nu este introdus niciun alt tip de card.
 02016R0799 — RO — 26.02.2020 — 002.001 — 280  
Octetul de sum ă de verificare este seria de sume de 8 bi ți 
modulo 256 a tuturor octe ților din mesaj, cu excep ția CS.  
Octeții FMT, SID, DS_, TRTP și TREP sunt defini ți în 
continuare în prezentul document.  
DDP_003 În cazul în care datele pe care urmeaz ă să le transporte 
mesajul sunt mai lungi decât spa țiul disponibil în câmpul 
de date, mesajul este transmis practic sub forma mai multor 
sub-mesaje. Fiecare sub-mesaj are un antet, acela și SID, 
TREP și un contor de sub-mesaje de 2 octe ți care indic ă 
numărul de ordine al sub-mesajului în cadrul mesajului 
integral. Pentru a permite verificarea erorilor și un 
eventual abandon al schimbului de date, IDE confirm ă 
fiecare sub-mesaj. IDE poate accepta sub-mesajul, poate 
solicita retransmiterea acestuia și poate solicita VU s ă reia 
sau să abandoneze transmisia.  
DDP_004 Dac ă ultimul sub-mesaj con ține exact 255 de octe ți în 
câmpul de date, trebuie s ă se adauge un sub-mesaj final 
cu un câmp de date gol (cu excep ția SID, TREP și a 
contorului de sub-mesaje) pentru a indica sfâr șitul mesajului.  
Exemplu:  
Antet  SID  TREP  Mesaj  CS  
4 octeți Cu o lungime de peste 255 de octe ți 
Se transmite astfel:  
Antet  SID  TREP  00  01  Sub-mesaj 1  CS  
4 octeți 255 octe ți 
Antet  SID  TREP  00  02  Sub-mesaj 2  CS  
4 octeți 255 octe ți 
… 
Antet  SID  TREP  xx  yy  Sub-mesaj n  CS  
4 octeți Mai pu țin de 255 de octe ți 
sau astfel:  
Antet  SID  TREP  00  01  Sub-mesaj 1  CS  
4 octeți 255 octe ți 
Antet  SID  TREP  00  02  Sub-mesaj 2  CS  
4 octeți 255 octe ți 
… 
Antet  SID  TREP  xx  yy  Sub-mesaj n  CS  
4 octeți 255 octe ți 
Antet  SID  TREP  xx  yy + 1  CS  
4 octeți 4 octe ți ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 281  
2.2.2  Tipuri de mesaje  
Protocolul de comunicare pentru desc ărcarea de date între VU și IDE 
impune schimbul a opt tipuri diferite de mesaje.  
Aceste mesaje sunt prezentate în tabelul urm ător. 
▼M1 
Structura mesajului  Maximum 4 octe ți Antet  Maximum 255 octe ți Date  1 octet 
Sumă 
de veri­
ficare  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  CS  
Solicitare de ini țiere a comuni ­
cării 81 EE  F0  81  E0  
Răspuns pozitiv la solicitarea de 
inițiere 
a comunic ării 80 F0  EE  03  C1  EA, 8F  9 B  
Solicitare de începere a sesiunii 
de diagnosticare  80 EE  F0  02  10  81  F1  
Răspuns pozitiv la solicitarea de 
începere a sesiunii de diagnos ­
ticare  80 F0  EE  02  50  81  31  
Serviciul de control al leg ăturii 
Verificarea ratei de modula ție 
(etapa 1)  
9 600 Bd  80  EE  F0  04  87  01,01,01  EC  
19 200 Bd  80  EE  F0  04  87  01,01,02  ED  
38 400 Bd  80  EE  F0  04  87  01,01,03  EE  
57 600 Bd  80  EE  F0  04  87  01,01,04  EF  
115 200 Bd  80  EE  F0  04  87  01,01,05  F0  
Răspuns pozitiv la o solicitare 
de 
verificare a ratei de modula ție 80 F0  EE  02  C7  01  28  
Rata de modula ție de tranzi ție 
(etapa 2)  80 EE  F0  03  87  02.03  ED  
Solicitare de înc ărcare  80  EE  F0  0A  35  00,00,00,00, 
00,FF,FF, 
FF,FF  99 
Răspuns pozitiv la solicitarea de 
încărcare  80 F0  EE  03  75  00,FF  D5  
Solicitare de transfer de date  
Prezentare general ă 80  EE  F0  02  36  01 sau 21  97  
Activități 80  EE  F0  06  36  02 sau 22  Data  CS  
Evenimente și anomalii  80  EE  F0  02  36  03 sau 23  Data  99  
Viteză detaliată 80  EE  F0  02  36  04 sau 24  Data  9 A  
Date tehnice  80  EE  F0  02  36  05 sau 25  Data  9 B  
Descărcarea informa țiilor de 
pe card  80 EE  F0  02  36  06  Slot  CS  
Răspuns pozitiv la solicitarea de 
transfer de date  80 F0  EE  Len  76  TREP  Date  CS  
Solicitare de încheiere a 
transferului  80 EE  F0  01  37  96  
Răspuns pozitiv la solicitarea de 
încheiere a transferului  80 F0  EE  01  77  D6  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 282  
Structura mesajului  Maximum 4 octe ți Antet  Maximum 255 octe ți Date  1 octet 
Sumă 
de veri­
ficare  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  CS  
Solicitare de încheiere a 
comunicării 80 EE  F0  01  82  E1  
Răspuns pozitiv la solicitarea 
de încheiere a comunic ării 80 F0  EE  01  C2  21  
Confirmare de primire a 
sub-mesajului  80 EE  F0  Len  83  Date  CS  
Răspunsuri negative  
Respingere general ă 80  F0  EE  03  7F  Sid Req  10  CS  
Serviciu incompatibil  80  F0  EE  03  7F  Sid Req  11  CS  
Subfuncție incompatibil ă 80  F0  EE  03  7F  Sid Req  12  CS  
Lungime incorect ă a mesajului  80  F0  EE  03  7F  Sid Req  13  CS  
Condiții incorecte sau eroare a 
secvenței de interogare  80 F0  EE  03  7F  Sid Req  22  CS  
Solicitare în afara intervalului  80  F0  EE  03  7F  Sid Req  31  CS  
Încărcare refuzat ă 80  F0  EE  03  7F  Sid Req  50  CS  
Răspuns în a șteptare  80  F0  EE  03  7F  Sid Req  78  CS  
Datele nu sunt disponibile  80  F0  EE  03  7F  Sid Req  FA  CS  
▼B 
Note:  
▼M1 
— TRTP 21-25 sunt utilizate pentru tipul de genera ția 2 de solicit ări 
de descărcare a datelor de pe VU, TRTP 01-05 sunt utilizate pentru 
tipul de genera ția 1 de solicit ări de descărcare a datelor de pe VU, 
care pot fi acceptate numai de VU în cadrul controlului conduc ă­
torilor auto efectuat de o autoritate de control din afara UE, 
utilizând un card de control de prim ă generație. 
— TRTP 11-19 și 31-39 sunt rezervate pentru solicit ările de desc ărcare 
specifice produc ătorului.  
▼B 
— Sid Req = Sid-ul solicit ării corespunz ătoare.  
— TREP = TRTP-ul solicit ării corespunz ătoare.  
— Rubricile marcate cu negru indic ă absența unei transmisii.  
— Termenul „înc ărcare” ( upload ) (privit din perspectiva IDE) se 
folosește pentru a garanta compatibilitatea cu ISO 14229. Are 
aceeași semnifica ție ca și termenul „desc ărcare” ( download ) văzut 
din perspectiva VU.  
— În acest tabel nu se g ăsește niciun contor poten țial de sub-mesaje de 
2 octeți. 
— Slot este num ărul slotului, fie „1” (card în slotul conduc ătorului 
auto), fie „2” (card în slotul copilotului)  
— În cazul în care slotul nu este specificat, VU trebuie s ă selecteze 
slotul 1 dac ă se introduce un card în slotul respectiv și să selecteze 
slotul 2 numai în cazul în care este ales în mod specific de c ătre 
utilizator.  
2.2.2.1 S o l i c i t a r e d e i n i ț i e r e a c o m u n i c ă r i i (  S t a r t C o m m u ­
n i c a t i o n R e q u e s t  ) ( S I D 8 1 )  
DDP_005 Acest mesaj este emis de IDE în vederea ini țierii legăturii de 
comunicare cu VU. Comunic ările inițiale sunt efectuate 
întotdeauna la 9 600 de bauzi (pân ă la eventuala 
schimbare a ratei de modula ție cu ajutorul serviciilor 
adecvate de control al leg ăturii).  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 283  
2.2.2.2 R ă s p u n s p o z i t i v l a s o l i c i t a r e a d e i n i ț i e r e a c o m u ­
n i c ă r i i (  P o s i t i v e R e s p o n s e S t a r t C o m m u n i c a ­
t i o n  ) ( S I D C 1 )  
DDP_006 Acest mesaj este emis de VU ca r ăspuns pozitiv la un mesaj 
de solicitare de ini țiere a comunic ării. Este compus din cei 
doi octeți cheie „EA” „8F” care indic ă faptul că unitatea 
este compatibil ă cu protocolul în cauz ă și are un antet 
care include informa ții privind sursa, ținta și lungimea.  
2.2.2.3 S o l i c i t a r e d e î n c e p e r e a s e s i u n i i d e d i a g n o s t i c a r e 
( S t a r t D i a g n o s t i c S e s s i o n R e q u e s t  ) ( S I D 1 0 )  
DDP_007 IDE emite un mesaj de solicitare de începere a sesiunii de 
diagnosticare ( Start Diagnostic Session request ) pentru a 
solicita o nou ă sesiune de diagnosticare cu VU. Subfunc ția 
„sesiune implicit ă” (81 Hex) indic ă faptul că urmează să 
înceapă o sesiune de diagnosticare standard.  
2.2.2.4 R ă s p u n s p o z i t i v l a s o l i c i t a r e a d e î n c e p e r e a 
s e s i u n i i d e d i a g n o s t i c a r e (  P o s i t i v e R e s p o n s e 
S t a r t D i a g n o s t i c  ) ( S I D 5 0 )  
DDP_008 Mesajul de r ăspuns pozitiv la solicitarea de începere a 
sesiunii de diagnosticare ( Positive Response Start Diag ­
nostic ) este trimis de VU ca r ăspuns pozitiv la solicitarea 
de începere a sesiunii de diagnosticare ( Diagnostic Session 
Request ). 
2.2.2.5 S e r v i c i u l d e c o n t r o l a l l e g ă t u r i i (  L i n k C o n t r o l 
S e r v i c e  ) ( S I D 8 7 )  
DDP_052 Serviciul de control al leg ăturii este folosit de IDE pentru a 
iniția o schimbare a ratei de modula ție. Acest lucru se 
realizează în două etape. În prima etap ă, IDE propune 
schimbarea ratei de modula ție, indicând rata nou ă. La 
primirea mesajului cu r ăspuns pozitiv de la VU, IDE 
trimite confirmarea privind modificarea ratei de modula ție 
la VU (etapa a doua). EID trece apoi la noua rat ă de modu­
lație. După primirea confirm ării, VU trece la noua rat ă de 
modulație. 
2.2.2.6 R ă s p u n s p o z i t i v l a c o n t r o l u l l e g ă t u r i i (  L i n k 
C o n t r o l P o s i t i v e R e s p o n s e  ) ( S I D C 7 )  
DDP_053 R ăspunsul pozitiv la controlul leg ăturii este emis de VU ca 
răspuns pozitiv la solicitarea serviciului de control al leg ă­
turii. A se remarca faptul c ă solicitarea de confirmare nu 
primește niciun r ăspuns (etapa a doua).  
2.2.2.7 S o l i c i t a r e d e î n c ă r c a r e (  R e q u e s t U p l o a d  ) ( S I D 3 5 )  
DDP_009 Mesajul de solicitare de înc ărcare ( Request Upload ) este 
emis de IDE pentru a indica VU faptul c ă s-a solicitat o 
operațiune de desc ărcare. Pentru a respecta cerin țele stan­
dardului ISO 14229, sunt incluse date care se refer ă la 
adresă și la detalii privind dimensiunea și formatul datelor 
solicitate. Deoarece IDE nu cunoa ște aceste date înainte de 
descărcare, adresa memoriei este setat ă la 0, formatul este 
necriptat și necomprimat, iar dimensiunea memoriei este 
setată la valoarea maxim ă. 
2.2.2.8 R ă s p u n s p o z i t i v l a s o l i c i t a r e a d e î n c ă r c a r e 
( P o s i t i v e R e s p o n s e R e q u e s t U p l o a d  ) ( S I D 7 5 )  
DDP_010 Mesajul de r ăspuns pozitiv la solicitarea de înc ărcare este 
trimis de VU pentru a indica IDE faptul c ă VU este 
pregătită pentru desc ărcarea datelor. Pentru a respecta 
cerințele standardului ISO 14229, în acest mesaj privind 
răspunsul pozitiv sunt incluse date care indic ă IDE că urmă­
toarele mesaje de r ăspuns pozitiv la solicitarea de transfer de 
date ( Positive Response Transfer Data ) vor fi compuse din 
maximum 00FF hex octe ți. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 284  
2.2.2.9 S o l i c i t a r e d e t r a n s f e r d e d a t e (  T r a n s f e r D a t a 
R e q u e s t  ) ( S I D 3 6 )  
▼M1 
DDP_011 Solicitarea de transfer de date (Transfer Data Request) este 
trimisă de EID pentru a indica VU tipul de date care 
urmează să fie descărcate. Un parametru de solicitare de 
transfer (TRTP) de un octet indic ă tipul transferului.  
Există șase tipuri de transfer de date. Pentru desc ărcarea 
datelor de pe VU, pot fi utilizate dou ă valori TRTP 
diferite pentru fiecare tip de transfer:  
Tip de transfer de 
date Valoare TRTP 
pentru tipul de 
generația 1 de 
descărcare a datelor 
de pe VU  Valoare TRTP 
pentru tipul de 
generația 2 de 
descărcare a datelor 
de pe VU  
Prezentare 
generală 01 21  
Activitățile de la o 
anumită dată 02 22  
Evenimente și 
anomalii  03 23  
Viteză detaliată 04  24  
Date tehnice  05  25  
Tip de transfer 
de date  Valoare TRTP  
Descărcarea 
informațiilor de 
pe card  06 
DDP_054 Este obligatoriu ca IDE s ă solicite un transfer de date de 
prezentare general ă (TRTP 01 sau 21) în timpul unei sesiuni 
de descărcare, deoarece este singurul lucru care garanteaz ă 
înregistrarea certificatelor VU în fi șierul desc ărcat (și 
permite verificarea semn ăturii digitale).  
În al doilea caz (TRTP 02 sau 22) mesajul de solicitare de 
transfer de date ( Transfer Data Request ) include indica ția 
zilei calendaristice (format
  ) care urmeaz ă să 
fie descărcată. 
▼B 
2.2.2.10 R ă s p u n s p o z i t i v l a s o l i c i t a r e a d e t r a n s f e r d e d a t e 
( 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  ) ( S I D 7 6 )  
DDP_012 Mesajul de r ăspuns pozitiv la solicitarea de transfer de date 
(Positive Response Transfer Data ) este trimis de VU ca 
răspuns la solicitarea de transfer de date ( Transfer Data 
Request ). Mesajul con ține datele solicitate, cu un  Transfer 
Response Parameter  (TREP) corespunz ător TRTP-ului soli ­
citării. 
▼M1 
DDP_055 În primul caz (TREP 01 sau 21), VU trimite datele care s ă 
poată ajuta operatorul IDE în alegerea datelor pe care 
dorește să le descarce în continuare. Informa țiile incluse în 
acest mesaj sunt:  
— certificate de securitate,  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 285  
— identificarea vehiculului,  
— data și ora actuale pentru VU,  
— data de desc ărcare minim ă și maximă (date VU),  
— indicații privind prezen ța cardurilor în VU,  
— descărcarea precedent ă către o societate,  
— blocări executate de societ ăți, 
— controale anterioare.  
▼B 
2.2.2.11 S o l i c i t a r e d e î n c h e i e r e a t r a n s f e r u l u i (  R e q u e s t 
T r a n s f e r E x i t  ) ( S I D 3 7 )  
DDP_013 Mesajul de solicitare de încheiere a transferului este trimis 
de IDE pentru a informa VU c ă sesiunea de desc ărcare s-a 
încheiat.  
2.2.2.12 R ă s p u n s p o z i t i v l a s o l i c i t a r e a d e î n c h e i e r e a 
t r a n s f e r u l u i ( S I D 7 7 ) (  P o s i t i v e R e s p o n s e R e q u e s t 
T r a n s f e r E x i t  ) 
DDP_014 Mesajul de r ăspuns pozitiv la solicitarea de încheiere a 
transferului ( Positive Response Request Transfer Exit)  este 
trimis de VU pentru a confirma primirea mesajului de soli ­
citare de încheiere a transferului.  
2.2.2.13 S o l i c i t a r e d e î n c h e i e r e a c o m u n i c ă r i i (  S t o p 
C o m m u n i c a t i o n R e q u e s t  ) ( S I D 8 2 )  
DDP_015 Mesajul de solicitare de încheiere a comunic ării (Stop 
Communication Request)  este trimis de IDE cu scopul de 
a întrerupe leg ătura de comunicare cu VU.  
2.2.2.14 R ă s p u n s p o z i t i v l a s o l i c i t a r e a d e î n c h e i e r e a 
c o m u n i c ă r i i (  P o s i t i v e R e s p o n s e S t o p C o m m u n i ­
c a t i o n  ) ( S I D C 2 )  
DDP_016 Mesajul de r ăspuns pozitiv la solicitarea de încheiere a 
comunicării (Positive Response Stop Communication)  este 
trimis de VU pentru a confirma primirea mesajului  Stop 
Communication Request . 
2.2.2.15 C o n f i r m a r e d e p r i m i r e a s u b - m e s a j u l u i 
( A c k n o w l e d g e S u b M e s s a g e  ) ( S I D 8 3 )  
DDP_017 Confirmarea de primire a sub-mesajului  (Acknowledge Sub 
Message)  este trimis de IDE pentru a confirma primirea 
fiecărei părți a unui mesaj care este transmis prin inter ­
mediul mai multor sub-mesaje. Câmpul de date con ține 
SID primit de la VU și un cod de 2 octe ți după cum 
urmează: 
— MsgC + 1 Confirm ă primirea corect ă a sub-mesajului cu 
numărul MsgC.  
Solicitare din partea IDE c ătre VU pentru a transmite 
sub-mesajul urm ător 
— MsgC indic ă apariția unei probleme la primirea sub- 
mesajului cu num ărul MsgC.  
Solicitare din partea IDE c ătre VU de a transmite sub- 
mesajul din nou  
— FFFF solicit ă întreruperea mesajului aflat în curs de 
transmitere.  
IDE poate folosi acest cod pentru a întrerupe trans ­
miterea mesajului VU, indiferent de motiv.  
Primirea ultimului sub-mesaj al unui mesaj (octetul LEN < 
255) poate fi confirmat ă cu ajutorul unuia dintre aceste 
coduri sau poate s ă nu fie confirmat ă. 
Răspunsurile din partea VU compuse din câteva sub-mesaje 
sunt:  
— Răspuns pozitiv la solicitarea de transfer de date 
(Positive Response Transfer Data ) (SID 76)  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 286  
2.2.2.16 R ă s p u n s n e g a t i v (  N e g a t i v e R e s p o n s e  ) ( S I D 7 F )  
DDP_018 Mesajul de r ăspund negativ ( Negative Response)  este trimis 
de VU ca r ăspuns la mesajele de solicitare men ționate 
anterior în cazul în care VU nu poate da curs solicit ării. 
Câmpurile de date ale mesajului con țin SID-ul r ăspunsului 
(7F), SID-ul solicit ării și un cod care precizeaz ă motivul 
răspunsului negativ. Sunt disponibile urm ătoarele coduri:  
— 10 respingere general ă 
Acțiunea nu poate fi realizat ă dintr-un motiv care nu este 
menționat în continuare.  
— 11 serviciu incompatibil  
SID-ul solicit ării nu poate fi în țeles. 
— 12 subfunc ție incompatibil ă 
DS_ sau TRTP al solicit ării nu poate fi în țeles sau nu 
mai există alte sub-mesaje de transmis.  
— 13 lungime incorect ă a mesajului  
Lungimea mesajului primit este incorect ă. 
— 22 condi ții incorecte sau eroare a secven ței de interogare  
Serviciul solicitat nu este activ sau secven ța mesajelor 
de solicitare nu este corect ă. 
— 31 solicitare în afara intervalului  
Înregistrarea parametrului solicit ării (câmpul de date) nu 
este valabil ă. 
— 50 încărcare refuzat ă 
Solicitarea nu poate fi executat ă (VU nu se afl ă în 
modul de func ționare corespunz ător sau exist ă o 
anomalie intern ă a VU).  
— 78 răspuns în a șteptare  
Acțiunea solicitat ă nu poate fi finalizat ă în timp util și 
VU nu este preg ătită să accepte o nou ă solicitare.  
▼M1 
— FA datele nu sunt disponibile  
Obiectul de date al unei solicit ări de transfer de date nu 
este disponibil în VU (de exemplu, cardul nu este 
inserat, tipul de genera ția 1 de solicitare de desc ărcare 
a datelor de pe VU în afara cadrului de verificare a 
conducătorului auto de c ătre o autoritate de control din 
afara UE…).  
▼B 
2.2.3  Fluxul mesajelor  
Pe parcursul unei proceduri normale de desc ărcare de date, un flux de 
mesaje tipic se efectueaz ă de obicei astfel:  
IDE VU  
Solicitare de ini țiere a comunic ării ⇨ 
⇦  R ăspuns pozitiv  
Solicitare de ini țiere a serviciului de diagnos ­
ticare ⇨ 
⇦  R ăspuns pozitiv  
Solicitare de înc ărcare ⇨ 
⇦  R ăspuns pozitiv  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 287  
IDE VU  
Solicitare de transfer de date de prezentare 
generală ⇨ 
⇦  R ăspuns pozitiv  
Solicitare de transfer de date #2  ⇨ 
⇦  R ăspuns pozitiv #1  
Confirmare de primire a sub-mesajului #1  ⇨ 
⇦  R ăspuns pozitiv #2  
Confirmare de primire a sub-mesajului #2  ⇨ 
⇦  R ăspuns pozitiv #m  
Confirmare de primire a sub-mesajului #m  ⇨ 
⇦  Răspuns pozitiv (Câmp de date <255 de octe ți) 
Confirmare de primire a sub-mesajului 
(opțional) ⇨  
… 
Solicitare de transfer de date #n  ⇨ 
⇦  R ăspuns pozitiv  
Solicitare de încheiere a transferului  ⇨ 
⇦  R ăspuns pozitiv  
Solicitare de încheiere a comunic ării ⇨ 
⇦  R ăspuns pozitiv  
2.2.4  Sincronizare  
DDP_019 În condi ții de funcționare normale, se aplic ă parametrii de 
sincronizare indica ți în figura urm ătoare:  
Figura 1  
Fluxul mesajelor, sincronizare
  
Unde:  
P1 = Timp interoctet pentru r ăspunsul VU.  
P2 = Interval de timp între încheierea solicit ării IDE și 
începerea r ăspunsului VU sau între încheierea 
confirmării de primire a IDE și începerea urm ătorului 
răspuns al VU.  
P3 = Interval de timp între încheierea r ăspunsului VU și 
începerea noii solicit ări a IDE sau între încheierea 
răspunsului VU și începerea confirm ării de primire 
a IDE sau între încheierea solicit ării IDE și 
începerea noii solicit ări a IDE dac ă VU nu reu șește 
să răspundă. 
P4 = Interval de timp interoctet pentru solicitarea IDE.  
P5 = Valoarea extins ă a P3 pentru desc ărcarea informa țiilor 
de pe card.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 288  
Valorile permise pentru parametrii de sincronizare sunt 
indicate în tabelul urm ător (setul de parametri de sincro ­
nizare extin și KWP folosi ți în caz de adresare fizic ă 
pentru o comunicare mai rapid ă). 
Parametru sincronizare  Limita inferioar ă 
Valoare (ms)  Limita superioar ă 
Valoare (ms)  
P1 0  20  
P2 20  1 000 (*)  
P3 10  5 000  
P4 5  20  
P5 10  20 de minute  
(*) dacă VU răspunde cu un r ăspuns negativ ( Negative Response ) care conține un cod cu sensul de „solicitare 
primită corect, răspuns în așteptare”, aceast ă valoare este extins ă până la aceeași valoare a limitei superioare 
a P3.  
2.2.5  Gestionarea erorilor  
Dacă o eroare intervine în timpul schimbului de mesaje, schema 
fluxului de mesaje se modific ă în funcție de echipamentul care a 
detectat eroarea și de mesajul care a generat eroarea.  
În figura 2 și în figura 3 sunt prezentate procedurile de gestionare a 
erorilor folosite de VU și, respectiv, de IDE.  
2.2.5.1 E t a p a d e i n i ț i e r e a c o m u n i c ă r i i 
DDP_020 Dac ă IDE detecteaz ă o eroare în timpul etapei de ini țiere a 
comunicării, fie la nivelul sincroniz ării, fie la nivelul 
fluxului de bi ți, așteaptă o perioad ă de P3min înainte de a 
emite din nou solicitarea.  
DDP_021 Dac ă VU detecteaz ă o eroare în secven ța primită de la IDE, 
nu trimite niciun r ăspuns și așteaptă un alt mesaj de soli ­
citare de ini țiere a comunic ării ( Start Communication 
Request ) timp de P3 max.  
2.2.5.2 E t a p a d e c o m u n i c a r e  
Pot fi definite dou ă proceduri diferite de gestionare a erorilor:  
1. VU detecteaz ă o eroare de transmisie a IDE  
DDP_022 VU analizeaz ă fiecare mesaj primit pentru a detecta erori 
de sincronizare, erori de format al octe ților (de exemplu, 
încălcări ce afecteaz ă biții de pornire și oprire) și erori de 
cadru (primirea unui num ăr greșit de octeți, octet de sum ă 
de verificare eronat).  
DDP_023 Dac ă VU detecteaz ă una dintre erorile men ționate 
anterior, nu trimite niciun r ăspuns și ignoră mesajul 
primit.  
DDP_024 VU poate detecta alte erori ale formatului sau 
conținutului mesajului primit (de exemplu, mesaj incom ­
patibil) chiar dac ă mesajul respect ă cerințele de lungime 
și de sumă de verificare; în acest caz, VU r ăspunde IDE 
cu un mesaj de r ăspuns negativ ( Negative Response ), 
indicând tipul erorii.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 289  
Figura 2  
Gestionarea erorilor de c ătre VU
  
2. IDE detecteaz ă o eroare de transmisie a VU  
DDP_025 IDE analizeaz ă fiecare mesaj primit pentru a detecta erori 
de sincronizare, erori de format al octe ților (de exemplu, 
încălcări ce afecteaz ă biții de pornire și oprire) și erori de 
cadru (primirea unui num ăr greșit de octeți, octet de sum ă 
de verificare eronat).  
DDP_026 IDE detecteaz ă erorile de secven ță, de exemplu incre ­
mentări greșite ale contorului de sub-mesaje în mesajele 
succesive primite.  
DDP_027 Dac ă IDE detecteaz ă o eroare sau dac ă nu primește niciun 
răspuns de la VU într-o perioad ă P2max, mesajul de soli ­
citare este transmis din nou de cel mult trei ori. În scopul 
detectării acestei erori, o confirmare de primire a sub- 
mesajului este considerat ă a fi o solicitare adresat ă VU. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 290  
DDP_028 IDE a șteaptă o perioad ă de P3min înainte de începerea 
fiecărei transmisii; perioada de a șteptare se m ăsoară de la 
ultima apari ție calculat ă a unui bit de oprire dup ă 
detectarea erorii în cauz ă. 
Figura 3  
Gestionarea erorilor de c ătre IDE
  
2.2.6  Conținutul mesajelor de r ăspuns  
La acest punct este prezentat con ținutul câmpurilor de date ale dife ­
ritelor mesaje de r ăspuns pozitiv.  
Elementele de date sunt definite în dic ționarul de date din apendicele 1.  
Observație: Pentru desc ărcări de genera ția 2, fiecare element de date de 
nivel superior este reprezentat de o colec ție de înregistr ări, chiar și în 
cazul în care aceasta con ține numai o singur ă înregistrare. O colec ție de 
înregistrări începe cu un antet; acest antet con ține tipul de înregistr ări, 
dimensiunea înregistr ărilor și numărul de înregistr ări. Colecțiile de înre ­
gistrări sunt denumite „ ... RecordArray ” (cu antet) în urm ătoarele 
tabele.  
2.2.6.1 R ă s p u n s p o z i t i v l a s o l i c i t a r e a d e t r a n s f e r d e d a t e 
d e p r e z e n t a r e g e n e r a l ă (  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  ) 
DDP_029  ►M1 Câmpul de date al mesajului de r ăspuns pozitiv la 
solicitarea de transfer de date de prezentare general ă („Po­
sitive Response Transfer Data Overview”) furnizeaz ă urmă­
toarele date în ordinea prezentat ă mai jos în conformitate cu 
SID 76 Hex, TREP 01 sau 21 Hex și criteriile adecvate de 
separare și numărare a sub-mesajelor: ◄ ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 291  
Structura datelor genera ția 1 (TREP 01 Hex)  
▼B 
Element de date  Observa ții
 
Certificate de securitate VU
  
Identificarea vehiculului
  
Data și ora actuale pentru VU
  
Perioada care poate fi desc ărcată
 
Tipuri de carduri introduse în VU
  
Descărcare anterioar ă VU
 
Toate bloc ările executate de societ ăți și stocate. 
Dacă secțiunea nu con ține date, se trimite numai 
noOfLocks = 0.
  
Toate înregistr ările activităților de control stocate 
în VU. Dac ă secțiunea nu con ține date, se trimite 
numai noOfControls = 0.
  
Semnătura RSA a tuturor datelor (cu excep ția 
certificatelor), începând cu VehicleIdentification ­
Number pân ă la ultimul octet din ultima VuCon ­
trolActivityData.  
▼M1 
Structura datelor genera ția 2 (TREP 21 Hex)  
▼B 
Element de date  Observa ții
 
Certificatul statului membru
  
Certificatul VU
  
Identificarea vehiculului
  
Numărul de înmatriculare al vehiculului
  
Data și ora actuale pentru VU
  
Perioada care poate fi desc ărcată
 
Tipuri de carduri introduse în VU
  
Descărcare anterioar ă VU
 
Toate bloc ările executate de societ ăți și stocate. 
Dacă secțiunea nu con ține date, se trimite un 
antet cu noOfRecords = 0.
  
Toate înregistr ările activităților de control stocate 
în VU. Dac ă secțiunea nu con ține date, se trimite 
un antet cu noOfRecords = 0.
  
Semnătura ECC a tuturor datelor precedente, cu 
excepția certificatelor.  
2.2.6.2 R ă s p u n s p o z i t i v l a s o l i c i t a r e a d e t r a n s f e r d e d a t e 
p r i v i n d a c t i v i t ă ț i l e (  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  ) 
DDP_030  ►M1 Câmpul de date al mesajului de r ăspuns pozitiv la 
solicitarea de transfer de date privind activit ățile („Positive 
Response Transfer Data Activities”) furnizeaz ă următoarele 
date în ordinea prezentat ă mai jos în conformitate cu SID 76 
Hex, TREP 02 sau 22Hex și criteriile adecvate de separare 
și numărare a sub-mesajelor: ◄ ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 292  
Structura datelor genera ția 1 (TREP 02 Hex)  
▼B 
Element de date  Observa ții
 
Data zilei desc ărcate
  
Odometrul la sfâr șitul zilei desc ărcate
  
Date privind ciclurile de introducere și de retragere a 
cardurilor. 
— Dacă această secțiune nu con ține date disponibile, se 
trimite numai noOfVuCardIWRecords = 0. 
— Atunci când VuCardIWRecord con ține date înre ­
gistrate înainte de ora 00.00 (introducerea cardului 
în ziua anterioar ă) sau dup ă ora 24.00 (retragerea 
cardului în ziua urm ătoare), aceste înregistr ări apar 
integral în cele dou ă zile implicate.
  
Starea sloturilor la 00:00 și modificările de activitate 
înregistrate pentru ziua desc ărcată.
 
Date privind locurile, înregistrate pentru ziua desc ărcată. 
Dacă secțiunea nu con ține date, se trimite numai noOf ­
PlaceRecords = 0.
  
Date privind condi țiile specifice, înregistrate pentru ziua 
descărcată. Dacă secțiunea nu con ține date, se trimite 
numai noOfSpecificConditionRecords = 0.
  
Semnătura RSA a tuturor datelor, începând de la 
TimeReal pân ă la ultimul octet din ultima înregistrare 
privind condi țiile specifice.  
▼M1 
Structura datelor genera ția 2 (TREP 22 Hex)  
▼B 
Element de date  Observa ții
 
Data zilei desc ărcate
  
Odometrul la sfâr șitul zilei desc ărcate
  
Date privind ciclurile de introducere și de retragere a 
cardurilor. 
— Dacă această secțiune nu con ține date disponibile, se 
trimite un antet al colec ției cu noOfRecords = 0. 
— Atunci când VuCardIWRecord con ține date înre ­
gistrate înainte de ora 00.00 (introducerea cardului 
în ziua anterioar ă) sau dup ă ora 24.00 (retragerea 
cardului în ziua urm ătoare), aceste înregistr ări apar 
integral în cele dou ă zile implicate.
  
Starea sloturilor la 00:00 și modificările de activitate 
înregistrate pentru ziua desc ărcată.
 
Date privind locurile, înregistrate pentru ziua desc ărcată. 
Dacă secțiunea nu con ține date, se trimite un antet al 
colecției cu noOfRecords = 0.  
▼M1
 
Pozițiile GNSS ale vehiculului când timpul de conducere 
acumulat al vehiculului atinge un multiplu de trei ore. 
Dacă secțiunea nu con ține date, se trimite un antet al 
colecției cu noOfRecords = 0.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 293  
Element de date  Observa ții
 
Date privind condi țiile specifice, înregistrate pentru ziua 
descărcată. Dacă secțiunea nu con ține date, se trimite un 
antet al colec ției cu noOfRecords = 0.
  
Semnătura ECC a tuturor datelor precedente.  
2.2.6.3 R ă s p u n s p o z i t i v l a s o l i c i t a r e a d e t r a n s f e r d e d a t e 
p r i v i n d e v e n i m e n t e l e ș i a n o m a l i i l e (  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  ) 
DDP_031  ►M1 Câmpul de date al mesajului de r ăspuns pozitiv la 
solicitarea de transfer de date privind evenimentele și 
anomaliile („Positive Response Transfer Data Events and 
Faults”) furnizeaz ă următoarele date în ordinea prezentat ă 
mai jos în conformitate cu SID 76 Hex, TREP 03 sau 23 
Hex și criteriile adecvate de separare și numărare a sub- 
mesajelor: ◄ 
▼M1 
Structura datelor genera ția 1 (TREP 03 Hex)  
▼B 
Element de date  Observa ții
 
Toate anomaliile stocate sau curente în VU. 
Dacă secțiunea nu con ține date, se trimite numai 
noOfVuFaults = 0.
  
Toate evenimentele (cu excep ția depășirii limitei 
de viteză) stocate sau în curs în VU. 
Dacă secțiunea nu con ține date, se trimite numai 
noOfVuEvents = 0.
  
Date referitoare la ultimul control privind 
depășirea limitei de vitez ă (valoare implicit ă în 
lipsa datelor).
  
Toate evenimentele de dep ășire a limitei de 
viteză stocate în VU. 
Dacă secțiunea nu con ține date, se trimite numai 
noOfVuOverSpeedingEvents = 0.
  
Toate evenimentele de reglare a orei stocate în 
VU (în afara cadrului unei etalon ări complete). 
Dacă secțiunea nu con ține date, se trimite numai 
noOfVuTimeAdjRecords = 0.
  
Semnătura RSA a tuturor datelor, începând cu 
noOfVuFaults pân ă la ultimul octet din ultima 
înregistrare privind reglarea orei.  
▼M1 
Structura datelor genera ția 2 (TREP 23 Hex)  
▼B 
Element de date  Observa ții
 
Toate anomaliile stocate sau curente în VU. 
Dacă secțiunea nu con ține date, se trimite un 
antet al colec ției cu noOfRecords = 0.
  
Toate evenimentele (cu excep ția depășirii limitei 
de viteză) stocate sau în curs în VU. 
Dacă secțiunea nu con ține date, se trimite un 
antet al colec ției cu noOfRecords = 0.
  
Date referitoare la ultimul control privind 
depășirea limitei de vitez ă (valoare implicit ă în 
lipsa datelor).
  
Toate evenimentele de dep ășire a limitei de 
viteză stocate în VU. 
Dacă secțiunea nu con ține date, se trimite un 
antet al colec ției cu noOfRecords = 0.  ▼B
02016R0799 — RO — 26.02.2020 — 002.001 — 294 
Element de date Observații
 
Toate evenimentele de reglare a orei stocate în 
VU (în afara cadrului unei etalon ări complete). 
Dacă secțiunea nu con ține date, se trimite un 
antet al colecției cu noOfRecords = 0.  
▼M1__________ 
▼B
Semnătura ECC a tuturor datelor precedente..  
2.2.6.4 R ă s p u n s p o z i t i v l a s o l i c i t a r e a d e t r a n s f e r d e d a t e 
p r i v i n d v i t e z a d e t a l i a t ă (  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  ) 
DDP_032 ►M1 Câmpul de date al mesajului de r ăspuns pozitiv la 
solicitarea de transfer de date privind viteza detaliat ă („Po­
sitive Response Transfer Data Detailed Speed”) furnizeaz ă 
urmă toarele date în ordinea prezentat ă mai jos în confor ­
mitate cu SID 76 Hex, TREP 04 sau 24 Hex și criteriile 
adecvate de separare și numărare a sub-mesajelor: ◄ 
▼M1
Structura datelor genera ția 1 (TREP 04)  
▼B
Element de date Observații
 
Toate datele privind viteza detaliat ă stocate în 
VU (un bloc de viteze pentru fiecare minut în 
timpul căruia vehiculul a fost în mi șcare) 
60 valori ale vitezei pe minut (una pe secund ă).
 
Semnătura RSA a tuturor datelor, începând cu 
noOfSpeedBlocks pân ă la ultimul octet din 
ultimul bloc de viteze.  
▼M1
Structura datelor genera ția 2 (TREP 24)  
▼B
Element de date Observații
 
Toate datele privind viteza detaliat ă stocate în 
VU (un bloc de viteze pentru fiecare minut în 
timpul căruia vehiculul a fost în mi șcare) 
60 valori ale vitezei pe minut (una pe secund ă).
 
Semnătura ECC a tuturor datelor precedente.  
2.2.6.5 R ă s p u n s p o z i t i v l a s o l i c i t a r e a d e t r a n s f e r d e d a t e 
t e h n i c e (  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  ) 
DDP_033 ►M1 Câmpul de date al mesajului de r ăspuns pozitiv la 
solicitarea de transfer de date tehnice („Positive Response 
Transfer Data Technical Data”) furnizeaz ă urmă toarele date 
în ordinea prezentat ă mai jos în conformitate cu SID 76 
Hex, TREP 05 sau 25 Hex și criteriile adecvate de 
separare și numărare a sub-mesajelor: ◄ ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 295  
Structura datelor genera ția 1 (TREP 05)  
▼B 
Element de date  Observa ții
 
Toate înregistr ările activit ăților de etalonare 
stocate în VU.
  
Semnătura RSA a tuturor datelor, începând cu 
vuManufacturerName pân ă la ultimul octet din 
ultimul VuCalibrationRecord.  
▼M1 
Structura datelor genera ția 2 (TREP 25)  
▼B 
Element de date  Observa ții
 
Toate asocierile MS stocate în VU.
  
Toate cupl ările echipamentului GNSS extern 
stocate în VU.
  
Toate înregistr ările activit ăților de etalonare 
stocate în VU.
  
Toate datele referitoare la introducerea cardurilor 
stocate în VU.
  
Semnătura ECC a tuturor datelor precedente.  
2.3. Stocarea fi șierelor în ESM  
DDP_034 Dac ă o sesiune de desc ărcare a inclus un transfer de date de 
pe VU, IDE stocheaz ă într-un singur fi șier fizic toate datele 
primite de la VU în timpul sesiunii de desc ărcare în 
mesajele de r ăspuns pozitiv la solicitarea de transfer de 
date. Datele stocate nu includ anteturi de mesaje, contoare 
de sub-mesaje, sub-mesaje f ără date și sume de verificare, 
dar includ SID și TREP (din primul sub-mesaj, numai dac ă 
există mai multe sub-mesaje).  
3. PROTOCOL DE DESC ĂRCARE DE PE CARDURILE DE 
TAHOGRAF  
3.1. Domeniu de aplicare  
Acest punct cuprinde o descriere a desc ărcării datelor de pe un card de 
tahograf pe un IDE. IDE nu face parte din mediul securizat; prin 
urmare, nu se realizeaz ă nicio procedur ă de autentificare între card și 
IDE.  
3.2. Defini ții 
Sesiune de desc ărcare : De fiecare dat ă când se efectueaz ă o 
operațiune de desc ărcare de date de pe 
ICC. Sesiunea include întreaga procedur ă, 
de la resetarea ICC cu ajutorul unui IFD 
până la dezactivarea ICC (retragerea 
cardului sau urm ătoarea resetare).  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 296  
Fișier de date semnat : Un fișier din ICC. Fi șierul este transferat în 
IFD sub form ă de text în clar. Pe ICC 
fișierul este supus func ției hash și semnat, 
iar semnătura este transferat ă la IFD.  
3.3. Desc ărcarea informa țiilor de pe card  
▼M1 
DDP_035 Desc ărcarea de pe un card de tahograf include urm ătoarele 
etape:  
— Descărcarea informa țiilor comune stocate pe card în 
fișierele elementare (EF)
  și
 . Aceste 
informații sunt op ționale și nu sunt protejate de o 
semnătură digitală. 
— (pentru prima și a doua genera ție de carduri de tahograf) 
Descărcarea EF în
  :  
— Descărcarea EF
  și
 
. Aceste informa ții nu sunt 
protejate de o semn ătură digitală. 
Descărcarea acestor fi șiere este obligatorie în cadrul 
fiecărei sesiuni de desc ărcare.  
— Descărcarea celorlalte EF de date privind aplica ția 
(în
 ), cu excep ția EF 
elementar
  . Aceste informa ții 
sunt securizate cu o semn ătură digitală, utilizând 
apendicele 11 „Mecanisme de securitate comune”, 
partea A.  
— Este obligatoriu s ă se descarce cel pu țin EF
  
și
 
pentru fiecare sesiune de 
descărcare.  
— La desc ărcarea de pe cardul de conduc ător auto, 
descărcarea urm ătoarelor EF este obligatorie:
  
— (numai pentru cardurile de tahograf de a doua gene ­
rație) Cu excep ția cazului în care o desc ărcare a unui 
card de conduc ător auto introdus într-o VU este 
efectuată în timpul controlului conduc ătorilor auto 
de către o autoritate de control din afara UE, 
utilizând un card de control de prim ă generație, 
descărcarea EF în
  :  
— Descărcarea EF CardSignCertificate, CA_Certi ­
ficate și Link_Certificate (dac ă există). Aceste 
informații nu sunt protejate de o semn ătură 
digitală. 
Descărcarea acestor fi șiere este obligatorie în 
cadrul fiec ărei sesiuni de desc ărcare.  
— Descărcarea celorlalte EF de date privind 
aplicația (în
  ), cu 
excepția EF
  . Aceste 
informații sunt securizate cu o semn ătură 
digitală, utilizând apendicele 11 „Mecanisme de 
securitate comune”, partea B.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 297  
— Este obligatoriu s ă se descarce cel pu țin EF
  
și
 
pentru fiecare sesiune 
de descărcare.  
— La desc ărcarea de pe cardul de conduc ător auto, 
descărcarea urm ătoarelor EF este obligatorie:
  
— La desc ărcarea unui card al conduc ătorului auto, 
se actualizeaz ă data
  
în EF
  , în
  
și în DF
  
, dacă este cazul.  
— La desc ărcarea unui card de atelier, se 
resetează contorul de etalonare în EF
  
, în
 și 
în DF
  , dac ă este cazul.  
— La desc ărcarea unui card de atelier, nu se descarc ă 
EF
 în
  
și DF
  , 
dacă este cazul.  
▼B 
3.3.1  Secven ța de inițializare  
DDP_036 IDE ini țiază secvența după cum urmeaz ă: 
Card  Direc ție IDE/IFD  Semnifica ție/Observa ții 
⇦ Resetare hardware  
ATR ⇨ 
Opțional, se poate folosi PPS pentru a trece la o rat ă de 
modulație mai mare dac ă ICC este compatibil.  
3.3.2  Secven ța de desc ărcare de fi șiere de date nesemnate  
DDP_037  ►M1 Secvența de descărcare a EF ICC, IC, Card_Certi ­
ficate (sau CardSignCertificate pentru DF Tachograph_G2), 
CA_Certificate și Link_Certificate (numai pentru DF Tacho ­
graph_G2) este urm ătoarea: ◄ 
Card  Direc ție IDE/IFD  Semnifica ție/Observa ții 
⇦ Select file  Selecteaz ă în funcție de iden­
tificatorii fi șierelor  
OK ⇨ 
⇦ Read Binary  Dac ă fișierul con ține mai 
multe date decât dimensiunea 
zonei tampon a cititorului sau 
a cardului, comanda trebuie 
repetată până la citirea 
integrală a datelor din fi șier. 
Arhivare date ( File 
Data ) 
OK ⇨ Stocarea datelor în ESM  în conformitate cu  3.4  
Formatul de stocare a datelor  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 298  
Nota 1:  Înainte de a selecta  Card_Certificate ( ori CardSig­
nCertificate) EF , trebuie s ă selectați aplicația de tahograf 
(selecție cu AID).  
Nota 2:  Selectarea și citirea unui fi șier poate fi efectuat ă, de 
asemenea, într-o singur ă etapă cu ajutorul unei comenzi de 
citire a datelor ( Read Binary ) cu un identificator EF scurt.  
3.3.3  Secven ța de desc ărcare de fi șiere de date semnate  
DDP_038 Urm ătoarea secven ță se folose ște pentru fiecare dintre 
fișierele urm ătoare care trebuie desc ărcate împreun ă cu 
semnătura lor:  
▼M1 
Card  Dir  IDE / IFD  Semnifica ție/Observa ții
 
Select File  
OK
 
Perform Hash of File  Calculeaz ă valoarea hash în 
raport cu con ținutul de date 
al fișierului selectat cu 
ajutorul algoritmului de 
hashing indicat în confor ­
mitate cu apendicele 11, 
partea A sau B. Aceast ă 
comandă nu este o comand ă 
conform ISO.  
Se calculeaz ă Hash of 
File și se stocheaz ă 
temporar valoarea hash  
OK
 
Read Binary  Dac ă fișierul con ține mai 
multe date decât poate s ă 
stocheze zona tampon a citi ­
torului sau a cardului, 
comanda trebuie repetat ă 
până la citirea integral ă a 
datelor din fi șier. 
File Data 
OK
 Stochează datele primite în 
ESM  în conformitate cu  3.4 Data 
storage format
  
PSO: Compute Digital 
Signature  
Execută operațiunea de 
securitate „Calcularea 
semnăturii digitale” cu 
ajutorul valorii hash 
stocate temporar  
Semnătura 
OK
 Adaugă date la datele 
stocate anterior în ESM  în conformitate cu  3.4 Data 
storage format  
▼B 
Notă: Selectarea și citirea unui fi șier poate fi efectuat ă, de 
asemenea, într-o singur ă etapă cu ajutorul unei comenzi de 
citire a datelor ( Read Binary ) cu un identificator EF scurt. În 
acest caz, EF poate fi selectat și citit înainte de a fi aplicat ă 
comanda Efectueaz ă Hash of File . ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 299  
3.3.4  Secven ța de resetare a unui contor de etalonare.  
DDP_039 Secven ța de resetare a contorului
  
din EF
  
al unui card de atelier se prezint ă 
după cum urmeaz ă: 
Card  Dir  IDE/IFD  Semnifica ție/Observa ții 
⇦ Select File  EF Card_Dow ­
nload  Selectează în funcție de iden­
tificatorii fi șierelor  
OK ⇨ 
⇦ Update Binary  
NoOfCalibrationsSince ­
Download = ‘00 00’  
Resetează numărul de 
descărcări de pe card  
OK ⇨ 
Notă: Selectarea și actualizarea unui fi șier poate fi efectuat ă, 
de asemenea, într-o singur ă etapă cu ajutorul unei comenzi  
Update Binary  cu un identificator EF scurt.  
3.4. Formatul de stocare a datelor  
3.4.1  Introducere  
DDP_040 Datele desc ărcate trebuie stocate în conformitate cu urm ă­
toarele condi ții: 
— Stocarea datelor trebuie s ă fie transparent ă. Acest lucru 
înseamnă că, pe parcursul stoc ării, trebuie s ă se mențină 
ordinea octe ților, precum și ordinea bi ților din interiorul 
octeților care sunt transfera ți de pe card.  
— Toate fi șierele de pe card desc ărcate în cadrul unei 
sesiuni de desc ărcare sunt stocate într-un singur fi șier 
în ESM.  
3.4.2  Formatul fi șierului  
DDP_041 Formatul fi șierului este o concatenare a mai multor obiecte 
TLV.  
DDP_042 Eticheta pentru un EF este FID înso țit de apendicele „00”.  
DDP_043 Eticheta pentru o semn ătură a EF este FID al fi șierului 
însoțit de apendicele „01”.  
DDP_044 Lungimea este o valoare de 2 octe ți. Valoarea define ște 
numărul de octe ți din câmpul de valori. Valoarea „FF FF” 
din câmpul de lungime este rezervat ă pentru o utilizare 
viitoare.  
DDP_045 Dac ă un fișier nu este desc ărcat, nu se stocheaz ă nicio 
informație privind fi șierul (nicio etichet ă și nicio lungime 
zero).  
▼M1 
DDP_046 O semn ătură trebuie salvat ă drept urm ătorul obiect TLV 
imediat dup ă obiectul TLV care con ține datele fi șierului.  
Definiție Sens  Lungime  
FID (2 octe ți) || „00”  Etichet ă pentru EF (FID) în 
DF
 sau 
pentru informa țiile comune 
stocate pe card  3 octeți 
FID (2 octe ți) || „01”  Eticheta pentru semn ătura 
EF (FID) în DF
  3 octeți ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 300  
Definiție Sens  Lungime  
FID (2 octe ți) || „02”  Eticheta pentru EF (FID) în 
DF
 3 octeți 
FID (2 octe ți) || „03”  Eticheta pentru semn ătura 
EF (FID) în DF
  3 octeți 
xx xx  Lungimea câmpului de 
valori  2 octeți 
Exemplu de date dintr-un fi șier de desc ărcare de pe o ESM:  
Etichetă Lungime  Valoare
  
— Date din EF ICC
  
— Date din EF Card_Certificate  
— …
  
Date din EF
  (în
  
DF)
 
Semnătura din EF
  
(în
 DF)
  
Date din EF
  în
  
DF
 
Semnătura din EF
  
în
 DF  
▼B 
4. DESC ĂRCAREA INFORMA ȚIILOR DE PE UN CARD DE 
TAHOGRAF PRIN INTERMEDIUL UNEI UNIT ĂȚI MONTATE 
PE VEHICUL  
DDP_047 VU trebuie s ă permită descărcarea conținutului unui card de 
conducător auto introdus într-un IDE conectat.  
DDP_048 IDE trimite un mesaj de solicitare de transfer de date privind 
descărcarea informa țiilor de pe card („ Transfer Data 
Request Card Download ”) către VU pentru a ini ția acest 
mod (a se vedea 2.2.2.9).  
▼M1 
DDP_049 Carduri de conduc ător auto de prima genera ție: Datele se 
descarcă folosind protocolul de desc ărcare a datelor aferent 
primei genera ții, iar datele desc ărcate trebuie s ă aibă același 
format ca datele desc ărcate dintr-o unitate montat ă pe 
vehicul de prima genera ție. 
Carduri de conduc ător auto de a doua genera ție: VU 
descarcă apoi integral cardul, fi șier cu fișier, în conformitate 
cu protocolul de desc ărcare definit la punctul 3, și trimite 
toate datele primite de pe card c ătre IDE în formatul de 
fișier TLV adecvat (a se vedea 3.4.2) și încapsulate într- 
un mesaj de r ăspuns pozitiv la solicitarea de transfer de 
date („Positive Response Transfer Data”).  
▼B 
DDP_050 IDE preia datele de pe card din mesajul de r ăspuns pozitiv 
la solicitarea de transfer de date („ Positive Response 
Transfer Data ”) (eliminând toate anteturile, SID-urile, 
TREP-urile contoarele de sub-mesaje și sumele de veri ­
ficare) și le stocheaz ă într-un singur fi șier fizic conform 
descrierii de la punctul 2.3.  
DDP_051 În continuare, VU actualizeaz ă, dacă este cazul, fi șierul
 
sau
 de pe 
cardul conduc ătorului auto.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 301  
Apendicele 8  
PROTOCOL DE ETALONARE  
CUPRINS  
1. INTRODUCERE  
2. TERMENI, DEFINI ȚII ȘI REFERIN ȚE 
3. PREZENTARE GENERAL Ă A SERVICIILOR  
3.1. Servicii disponibile  
3.2. Coduri de r ăspuns  
4. SERVICII DE COMUNICARE  
4.1. Serviciul StartCommunication  
4.2. Serviciul StopCommunication  
4.2.1 Descrierea mesajului  
4.2.2 Formatul mesajului  
4.2.3 Definirea parametrilor  
4.3. Serviciul TesterPresent  
4.3.1 Descrierea mesajului  
4.3.2 Formatul mesajului  
5. SERVICII DE GESTIONARE  
5.1. Serviciul StartDiagnosticSession  
5.1.1 Descrierea mesajului  
5.1.2 Formatul mesajului  
5.1.3 Definirea parametrilor  
5.2. Serviciul SecurityAccess  
5.2.1 Descrierea mesajului  
5.2.2 Formatul mesajului – SecurityAccess – requestSeed  
5.2.3 Formatul mesajului – SecurityAccess – sendKey  
6. SERVICII DE TRANSMISIE A DATELOR  
6.1. Serviciul ReadDataByIdentifier  
6.1.1 Descrierea mesajului  
6.1.2 Formatul mesajului  
6.1.3 Definirea parametrilor  
6.2. Serviciul WriteDataByIdentifier  
6.2.1 Descrierea mesajului  
6.2.2 Formatul mesajului  
6.2.3 Definirea parametrilor  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 302  
7. CONTROLUL IMPULSURILOR DE TEST – UNITATEA 
FUNCȚIONALĂ DE CONTROL AL INTR ĂRILOR/IEȘIRILOR  
7.1. Serviciul InputOutputControlByIdentifier  
7.1.1 Descrierea mesajului  
7.1.2 Formatul mesajului  
7.1.3 Definirea parametrilor  
8. FORMATE DATARECORDS  
8.1. Intervalele parametrilor transmi și 
8.2. Formate dataRecords  
1. INTRODUCERE  
Prezentul apendice descrie modul în care are loc schimbul de date între 
o unitate montat ă pe vehicul și un aparat de testare prin intermediul 
liniei K care face parte din interfa ța de etalonare descris ă în apendicele 
6. De asemenea, în prezentul apendice este descris controlul liniei de 
semnalizare I/O efectuat asupra conectorului de etalonare.  
Modul de stabilire a comunic ărilor pe linia K este descris în sec țiunea 
4, „Communication Services”.  
În prezentul apendice se folose ște ideea de „sesiuni” de diagnosticare 
pentru a determina sfera controlului liniei K în diferite condi ții. 
Sesiunea implicit ă este „StandardDiagnosticSession”, în cadrul c ăreia 
pot fi citite toate datele de pe o unitate montat ă pe vehicul, dar nu pot 
fi înregistrate date pe o unitate montat ă pe vehicul.  
Selectarea sesiunii de diagnosticare este descris ă în secțiunea 5, „Mana ­
gement Services”.  
Prezentul apendice trebuie s ă fie considerat relevant pentru ambele 
generații de VU și de carduri de atelier, în conformitate cu cerin țele 
de interoperabilitate prev ăzute în prezentul regulament.  
CPR_001 Sesiunea „ECUProgrammingSession” permite introducerea 
datelor în unitatea montat ă pe vehicul. În cazul introducerii 
datelor de etalonare, unitatea montat ă pe vehicul trebuie s ă 
se afle în modul de func ționare ETALONARE.  
Transferul de date prin intermediul liniei K este descris în 
secțiunea 6, „Data Transmission Services”. Formatele pentru 
datele transferate sunt descrise în detaliu în sec țiunea 8, 
„dataRecords formats”.  
CPR_002 Sesiunea „ECUAdjustmentSession” permite selectarea 
modului I/O al liniei de semnalizare I/O de etalonare, prin 
interfața liniei K. Controlul liniei de semnalizare I/O de 
etalonare este descris în sec țiunea 7, „Control of Test 
Pulses – Input/Output Control functional unit”.  
CPR_003 În cadrul prezentului document, adresa aparatului de testare 
este notată cu ‘tt’. Cu toate c ă este posibil s ă existe adrese 
privilegiate pentru aparatele de testare, VU trebuie s ă 
răspundă corect la orice adres ă a aparatului de testare. 
Adresa fizic ă a VU este 0xEE.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 303  
2. TERMENI, DEFINI ȚII ȘI REFERIN ȚE 
Protocoalele, mesajele și codurile de eroare se bazeaz ă în principal pe 
un proiect al standardului ISO 14229-1( Road vehicles – Diagnostic 
systems – Part 1: Diagnostic services , versiunea 6 din 22 februarie 
2001).  
Codificările octeților și alte valori hexazecimale sunt folosite la 
definirea identificatorilor de servicii, la elaborarea solicit ărilor și a 
răspunsurilor de servicii și la configurarea parametrilor standard.  
Termenul „aparat de testare” se refer ă la echipamentul folosit la intro ­
ducerea datelor de programare/etalonare în VU.  
Termenii „client” și „server” se refer ă la aparatul de testare, respectiv la 
VU. 
Termenul ECU înseamn ă „Unitate electronic ă de control” și se referă la 
VU. 
Referințe: 
▼M1 
ISO 14230-2: Road Vehicles – Diagnostic Systems – Keyword 
Protocol 2000 – Part 2: Data Link Layer.  
Prima ediție: 1999.  
▼B 
3. PREZENTARE GENERAL Ă A SERVICIILOR  
3.1. Servicii disponibile  
Următorul tabel cuprinde o prezentare general ă a serviciilor care vor fi 
disponibile în tahograf și sunt definite în prezentul document.  
CPR_004 Tabelul prezint ă serviciile disponibile în cadrul unei sesiuni 
de diagnosticare active.  
— Prima coloan ă cuprinde serviciile disponibile.  
— A  doua coloan ă include num ărul secțiunii din prezentul 
apendice unde serviciul este definit mai detaliat.  
— A  treia coloan ă indică valorile atribuite identificatorului 
de serviciu pentru mesajele de solicitare.  
— A  patra coloan ă precizeaz ă serviciile sesiunii  „Stan­
dardDiagnosticSession” (SD)  care trebuie implementate 
în fiecare VU.  
— A  cincea coloan ă precizeaz ă serviciile sesiunii  
„ECUAdjustmentSession” (ECUAS)  care trebuie 
implementate pentru a permite controlul liniei de semna ­
lizare I/O în conectorul de etalonare din panoul frontal al 
VU. 
— A  șasea coloan ă precizeaz ă serviciile sesiunii  „ECU­
ProgrammingSession” (ECUPS)  care trebuie imple ­
mentate pentru a permite programarea parametrilor în 
VU. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 304  
Tabelul 1  
Tabel de prezentare a valorilor identificatorilor de serviciu  
Sesiuni de diagnosticare  
Denumirea serviciului de diagnos ­
ticare  Secțiunea 
Nr. SID Valoarea 
solicitată 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  ■ 
■ Acest simbol indic ă faptul că serviciul este obligatoriu în aceast ă sesiune de diagnosticare. 
Absența oricărui simbol indic ă faptul că acest serviciu nu este permis în aceast ă sesiune de 
diagnosticare.  
3.2. Coduri de r ăspuns  
Codurile de r ăspuns sunt definite pentru fiecare serviciu în parte.  
4. Servicii de comunicare  
Există anumite servicii care sunt necesare pentru ini țierea și menținerea 
comunicării. Acestea nu apar în stratul aplica țiilor. Serviciile dispo ­
nibile sunt prezentate în detaliu în tabelul urm ător: 
Tabelul 2  
Servicii de comunicare  
Denumirea serviciului  Descriere  
StartCommunication  Clientul solicit ă inițierea unei sesiuni 
de comunicare cu unul sau mai multe 
servere.  
StopCommunication  Clientul solicit ă încheierea sesiunii de 
comunicare în curs de desf ășurare.  
TesterPresent  Clientul semnaleaz ă serverului faptul 
că este încă prezent.  
CPR_005 Serviciul StartCommunication este folosit pentru ini țierea 
unei comunic ări. Pentru a efectua un serviciu, trebuie s ă 
se inițializeze comunicarea, iar parametrii de comunicare 
trebuie să fie adapta ți modului dorit.  
4.1. Serviciul StartCommunication  
CPR_006 La primirea unei primitive de indicare StartCommunication, 
VU verific ă dacă legătura de comunicare solicitat ă poate fi 
inițializată în condi țiile existente. Condi țiile necesare 
inițializării unei leg ături de comunicare sunt descrise în 
documentul ISO 14230-2.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 305  
CPR_007 În continuare, VU realizeaz ă toate acțiunile necesare pentru 
a inițializa o leg ătură de comunicare și trimite o primitiv ă de 
răspuns StartCommunication cu parametrii de r ăspuns 
pozitiv selecta ți. 
CPR_008 Dac ă o VU deja ini țializată (și care a început o sesiune de 
diagnosticare) prime ște o nouă solicitare StartCommuni ­
cation (de exemplu, datorit ă unei remedieri a erorii în 
aparatul de testare), solicitarea este acceptat ă și VU este 
reinițializată. 
CPR_009 Dac ă legătura de comunicare nu poate fi ini țializată, indi­
ferent de motiv, VU continu ă să funcționeze în acelea și 
condiții care existau imediat înainte de încercarea de 
inițializare a leg ăturii de comunicare.  
CPR_010 Mesajului de solicitare StartCommunication trebuie s ă i se 
aloce o adres ă fizică. 
CPR_011 Ini țializarea VU pentru servicii se realizeaz ă cu ajutorul unei 
metode de „ini țializare rapid ă”; 
— Anterior oric ărei activități există o perioad ă de inacti­
vitate a magistralei.  
— În continuare, aparatul de testare trimite o configurare de 
inițializare.  
— Toate informa țiile necesare ini țializării comunic ării sunt 
incluse în r ăspunsul VU.  
CPR_012 Dup ă finalizarea ini țializării, 
— Tuturor parametrilor de comunicare le sunt atribuite 
valorile definite în tabelul 4 în func ție de octeții cheie.  
— VU așteaptă prima solicitare din partea aparatului de 
testare.  
— VU se afl ă în modul de diagnosticare implicit, adic ă 
StandardDiagnosticSession.  
— Linia de semnalizare I/O de etalonare este în starea 
implicită, adică inactivă. 
CPR_014 Viteza de transmisie a datelor pe linia K este de 10 400 
bauzi.  
CPR_016 Ini țializarea rapid ă este lansat ă de aparatul de testare prin 
transmiterea unei secven țe de ieșire din starea inactiv ă 
(Wup) pe linia K. Secven ța începe dup ă perioada inactiv ă 
pe linia K, cu o perioad ă scurtă Tinil. Aparatul de testare 
transmite primul bit al serviciului StartCommunication dup ă 
un timp Twup, dup ă prima linie descendent ă.
 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 306  
CPR_017 Valorile de sincronizare pentru ini țializarea rapid ă și comu­
nicare în general sunt descrise în detaliu în tabelele 
prezentate în continuare. Pentru perioada de inactivitate 
există diferite posibilit ăți: 
— Prima transmisie dup ă conectarea la alimentare, Tidle = 
300 ms.  
— După finalizarea unui serviciu StopCommunication, 
Tidle = P3 min.  
— După încheierea comunic ării prin dep ășirea timpului 
alocat P3 max, Tidle = 0.  
Tabelul 3  
Valori de sincronizare pentru ini țializarea rapid ă 
Parametru  valoare minim ă valoare maxim ă 
Tinil  25 ± 1 ms  24 ms  26 ms  
Twup  50 ± 1 ms  49 ms  51 ms  
Tabelul 4  
Valorile de sincronizare pentru comunicare  
Parametru 
de sincro­
nizare  Descrierea parametrului  valori minime 
admise (ms)  valori maxime 
admise (ms)  
min. max.  
P1 Timpul între octe ți pentru 
răspunsul VU  0 20  
P2 Timpul dintre solicitarea 
aparatului de testare și 
răspunsul VU sau dintre dou ă 
răspunsuri VU  25 250  
P3 Timpul dintre sfâr șitul răspun­
surilor VU și începutul noii 
solicitări a aparatului de testare  55 5 000  
P4 Timpul între octe ți pentru soli ­
citarea aparatului de testare  5 20  
CPR_018 Formatul mesajului pentru ini țializarea rapid ă este prezentat 
în detaliu în tabelele urm ătoare. (NOT Ă: Hex înseamn ă 
hexazecimal)  
Tabelul 5  
Mesaj StartCommunication Request  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 81 FMT  
#2 Octet al adresei țintă EE  TGT  
#3 Octet al adresei surs ă tt  SRC  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 307  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#4 StartCommunication Request 
Service Id  81 SCR  
#5 Sum ă de verificare  00-FF  CS  
Tabelul 6  
Mesaj StartCommunication Positive Response  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  03  LEN  
#5 StartCommunication Positive 
Response Service Id  C1 SCRPR  
#6 Octet cheie 1  EA  KB1  
#7 Octet cheie 2  8F  KB2  
#8 Sum ă de verificare  00-FF  CS  
CPR_019 Nu exist ă niciun răspuns negativ la mesajul StartCommuni ­
cation Request; dac ă nu există un mesaj de r ăspuns pozitiv 
de transmis, VU nu este ini țializată, nu se transmite niciun 
mesaj și aceasta r ămâne în modul s ău normal de 
funcționare.  
4.2. Serviciul StopCommunication  
4.2.1  Descrierea mesajului  
Scopul acestui serviciu al stratului de comunicare este de a încheia o 
sesiune de comunicare.  
CPR_020 La primirea unei primitive de indicare StopCommunication, 
VU verific ă dacă condițiile din momentul respectiv permit 
încheierea comunic ării în cauză. În acest caz, VU realizeaz ă 
toate acțiunile necesare pentru a încheia comunicarea în 
cauză. 
CPR_021 Dac ă încheierea comunic ării este posibil ă, VU emite o 
primitivă de răspuns StopCommunication cu parametrii de 
răspuns pozitiv selecta ți, înainte de încheierea comunic ării. 
CPR_022 Dac ă încheierea comunic ării nu este posibil ă, indiferent de 
motiv, VU emite o primitiv ă de răspuns StopCommuni ­
cation împreun ă cu parametrul de r ăspuns negativ selectat.  
CPR_023 Dac ă VU detecteaz ă depășirea timpului alocat P3max, 
comunicarea este încheiat ă fără a se emite o primitiv ă de 
răspuns.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 308  
4.2.2  Formatul mesajului  
CPR_024 Formatele mesajelor pentru primitivele StopCommunication 
sunt prezentate în detaliu în tabelele urm ătoare:  
Tabelul 7  
Mesaj StopCommunication Request  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă EE  TGT  
#3 Octet al adresei surs ă tt  SRC  
#4 Octet de lungime suplimentar  01  LEN  
#5 StopCommunication Request 
Service Id  82 SPR  
#6 Sum ă de verificare  00-FF  CS  
Tabelul 8  
Mesaj StopCommunication Positive Response  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  01  LEN  
#5 StopCommunication Positive 
Response Service Id  C2 SPRPR  
#6 Sum ă de verificare  00-FF  CS  
Tabelul 9  
Mesaj StopCommunication Negative Response  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  03  LEN  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 309  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#5 negative Response Service Id  7F  NR  
#6 StopCommunication Request 
Service Identification  82 SPR  
#7 responseCode = generalReject  10  RC_GR  
#8 Sum ă de verificare  00-FF  CS  
4.2.3  Definirea parametrilor  
Acest serviciu nu necesit ă definirea niciunui parametru.  
4.3. Serviciul TesterPresent  
4.3.1  Descrierea mesajului  
Serviciul TesterPresent este folosit de aparatul de testare pentru a indica 
serverului c ă este încă prezent, în scopul de a preveni astfel revenirea 
automată a serverului la modul de func ționare normal și posibila între ­
rupere a comunic ării de către acesta. Acest serviciu, trimis periodic, 
menține sesiunea de diagnosticare/comunicarea activ ă prin resetarea 
contorului P3 de fiecare dat ă când se prime ște o solicitare pentru 
acest serviciu.  
4.3.2  Formatul mesajului  
CPR_079 Formatele mesajelor pentru primitivele TesterPresent sunt 
prezentate în detaliu în tabelele urm ătoare.  
Tabelul 10  
Mesaj TesterPresent Request  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă EE  TGT  
#3 Octet al adresei surs ă tt  SRC  
#4 Octet de lungime suplimentar  02  LEN  
#5 TesterPresent Request 
Service Id  3E TP  
#6 Subfunc ție = respon ­
seRequired =  [ da 01  RESPREQ_Y  
nu ] 02  RESPREQ_NO  
#7 Sum ă de verificare  00-FF  CS  
CPR_080 Dac ă parametrul responseRequired are valoarea „da”, 
serverul răspunde cu urm ătorul mesaj de r ăspuns pozitiv. 
Dacă valoarea este „nu”, serverul nu trimite niciun r ăspuns.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 310  
Tabelul 11  
Mesaj TesterPresent Positive Response  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  01  LEN  
#5 TesterPresent Positive 
Response Service Id  7E TPPR  
#6 Sum ă de verificare  00-FF  CS  
CPR_081 Serviciul este compatibil cu urm ătoarele coduri de r ăspuns 
negativ:  
Tabelul 12  
Mesaj TesterPresent Negative Response  
Octet #  Denumirea parametrului  Valoarea 
Hex Cod mnemonic  
#1 Octet de format – adresare fizic ă 80  FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  03  LEN  
#5 negative Response Service Id  7F  NR  
#6 TesterPresent Request Service Identifi ­
cation  3E TP  
#7 responseCode =  [ SubFunctionNotSup ­
ported-InvalidFormat  12 RC_SFNS_IF  
incorrectMessage ­
Length ]  13 RC_IML  
#8 Sumă de verificare  00-FF  CS  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 311  
5. SERVICII DE GESTIONARE  
Serviciile disponibile sunt prezentate în detaliu în tabelul urm ător: 
Tabelul 13  
Servicii de gestionare  
Denumirea serviciului  Descriere  
StartDiagnosticSession  Clientul solicit ă inițierea unei sesiuni 
de diagnosticare cu o VU.  
SecurityAccess  Clientul solicit ă accesul la func ții 
rezervate utilizatorilor autoriza ți. 
5.1. Serviciul StartDiagnosticSession  
5.1.1  Descrierea mesajului  
CPR_025 Serviciul StartDiagnosticSession este utilizat pentru 
activarea unor diferite sesiuni de diagnosticare în server. O 
sesiune de diagnosticare activeaz ă un set specific de servicii 
în conformitate cu tabelul 17. O sesiune poate activa servicii 
specifice ale produc ătorului vehiculului care nu fac parte din 
prezentul document. Normele de implementare respect ă 
următoarele cerin țe: 
— Întotdeauna exist ă doar o sesiune de diagnosticare activ ă 
în VU,  
— VU lanseaz ă întotdeauna StandardDiagnosticSession 
când este conectat ă la o surs ă de alimentare. Dac ă nu 
este lansat ă o altă sesiune de diagnosticare, Standar ­
dDiagnosticSession r ămâne deschis ă atâta timp cât VU 
este conectat ă la o sursă de alimentare,  
— Dacă o sesiune de diagnosticare în curs de desf ășurare a 
fost solicitat ă de un aparat de testare, VU trimite un 
mesaj de r ăspuns pozitiv,  
— De fiecare dat ă când un aparat de testare solicit ă o 
sesiune de diagnosticare nou ă, VU trimite mai întâi un 
mesaj de r ăspuns pozitiv la solicitarea StartDiagnostic ­
Session, înainte ca noua sesiune s ă devină activă în VU. 
Dacă VU nu poate lansa noua sesiune de diagnosticare 
solicitată, aceasta r ăspunde cu un mesaj de r ăspuns 
negativ la solicitarea StartDiagnosticSession, iar 
sesiunea aflat ă în desfășurare continu ă. 
CPR_026 O sesiune de diagnosticare poate fi lansat ă numai în cazul în 
care comunicarea a fost stabilit ă între client și VU.  
CPR_027 Parametrii de sincronizare defini ți în tabelul 4 devin activi 
după efectuarea cu succes a StartDiagnosticSession, para ­
metrul diagnosticSession fiind stabilit la valoarea „Standar ­
dDiagnosticSession” în mesajul de solicitare în cazul în care 
o altă sesiune de diagnosticare a fost activ ă anterior.  
5.1.2  Formatul mesajului  
CPR_028 Formatele mesajelor pentru primitivele StartDiagnostic ­
Session sunt prezentate în detaliu în tabelele urm ătoare.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 312  
Tabelul 14  
Mesaj StartDiagnosticSession Request  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă EE  TGT  
#3 Octet al adresei surs ă tt  SRC  
#4 Octet de lungime suplimentar  02  LEN  
#5 StartDiagnosticSession 
Request Service Id  10 STDS  
#6 diagnosticSession = [o valoare 
din tabelul 17]  xx DS_…  
#7 Sum ă de verificare  00-FF  CS  
Tabelul 15  
Mesaj StartDiagnosticSession Positive Response  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  02  LEN  
#5 StartDiagnosticSession 
Positive Response Service Id  50 STDSPR  
#6 diagnosticSession = [aceea și 
valoare ca la octetul #6 din 
tabelul 14]  xx DS_…  
#7 Sum ă de verificare  00-FF  CS  
Tabelul 16  
Mesaj StartDiagnosticSession Negative Response  
Octet #  Denumirea parametrului  Valoarea 
Hex Cod mnemonic  
#1 Octet de format – adresare fizic ă 80  FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 313  
Octet #  Denumirea parametrului  Valoarea 
Hex Cod mnemonic  
#4 Octet de lungime suplimentar  03  LEN  
#5 Negative Response Service Id  7F  NR  
#6 StartDiagnosticSession Request Service Id  10  STDS  
#7 ResponseCode =  [subFunctionNotSup ­
ported (  a ) 12 RC_SFNS  
incorrectMessage ­
Length (  b ) 13 RC_IML  
conditionsNotCor ­
rect (  c ) 22 RC_CNC  
#8 Sumă de verificare  00-FF  CS  
( a ) – valoarea introdus ă la octetul # 6 din mesajul de solicitare nu este compatibil ă, 
adică nu se află în tabelul 17, 
( b ) – lungimea mesajului nu este corect ă, 
( c ) – criteriile pentru solicitarea StartDiagnosticSession nu sunt îndeplinite.  
5.1.3  Definirea parametrilor  
CPR_029 Parametrul  diagnosticSession (DS_)  este folosit de serviciul 
StartDiagnosticSession pentru a selecta comportamentul 
specific al serverului (serverelor). În prezentul document 
sunt precizate urm ătoarele sesiuni de diagnosticare:  
Tabelul 17  
Definiția valorilor diagnosticSession  
Hex Descriere  Cod 
mnemonic  
81 StandardDiagnosticSession  
Această sesiune de diagnosticare activeaz ă toate 
serviciile specificate în  coloana 4 “SD”  din  
tabelul 1 . Aceste servicii permit citirea datelor de 
pe un server (VU). Aceast ă sesiune de diagnos- 
ticare este activ ă după finalizarea cu succes a 
inițializării între client (aparatul de testare) și 
server (VU). Aceast ă sesiune de diagnosticare 
poate fi suprascris ă de alte sesiuni de diagnos- 
ticare specificate în prezenta sec țiune.  SD 
85 ECUProgrammingSession  
Această sesiune de diagnosticare activeaz ă toate 
serviciile specificate în  coloana 6 “ECUPS”  din 
tabelul 1 . Serviciile respective sunt compatibile 
cu programarea memoriei unui server (VU). 
Această sesiune de diagnosticare poate fi supras- 
crisă de alte sesiuni de diagnosticare specificate 
în prezenta sec țiune.  ECUPS  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 314  
Hex Descriere  Cod 
mnemonic  
87 ECUAdjustmentSession  
Această sesiune de diagnosticare activeaz ă toate 
serviciile specificate în  coloana 5 “ECUAS”  din 
tabelul 1 . Aceste servicii sunt compatibile cu 
controlul intr ărilor/ieșirilor unui server (VU). 
Această sesiune de diagnosticare poate fi supras- 
crisă de alte sesiuni de diagnosticare specificate 
în prezenta sec țiune.  ECUAS  
5.2. Serviciul SecurityAccess  
Scrierea datelor de etalonare este posibil ă doar dacă VU se afl ă în mod 
ETALONARE. Pe lâng ă introducerea unui card de atelier în VU, este 
necesară și introducerea PIN-ului corespunz ător în VU înainte de 
acordarea accesului la modul ETALONARE.  
În cazul în care VU se afl ă în modul ETALONARE sau CONTROL, 
este posibil ă, de asemenea, accesarea liniei I/O de etalonare.  
Serviciul SecurityAccess ofer ă o modalitate de introducere a PIN-ului 
și de a semnala aparatului de testare dac ă VU se afl ă sau nu în mod 
ETALONARE.  
Se permite introducerea PIN-ului și prin intermediul altor metode.  
5.2.1  Descrierea mesajului  
Serviciul SecurityAccess const ă într-un mesaj SecurityAccess „reques ­
tSeed”, urmat eventual de un mesaj SecurityAccess „sendKey”. 
Serviciul SecurityAccess trebuie s ă fie executat dup ă serviciul Start ­
DiagnosticSession.  
CPR_033 Aparatul de testare folose ște mesajul SecurityAccess 
„requestSeed” pentru a verifica dac ă unitatea montat ă pe 
vehicul este preg ătită să accepte un PIN.  
CPR_034 Dac ă unitatea montat ă pe vehicul este deja în mod 
ETALONARE, aceasta r ăspunde solicit ării prin trimiterea 
unei „valori ini țiale ( seed)” de 0x0000 cu ajutorul servi ­
ciului SecurityAccess Positive Response.  
CPR_035 Dac ă unitatea montat ă pe vehicul este preg ătită să accepte 
un PIN pentru verificarea cu un card de atelier, aceasta 
răspunde solicit ării prin trimiterea unei „valori ini țiale” 
mai mari de 0x0000 cu ajutorul serviciului SecurityAccess 
Positive Response.  
CPR_036 Dac ă unitatea montat ă pe vehicul nu este preg ătită să 
accepte un PIN de la aparatul de testare, întrucât fie 
cardul de atelier introdus nu este valabil, fie nu a fost 
introdus niciun card de atelier, fie unitatea montat ă pe 
vehicul așteaptă transmiterea PIN-ului printr-o alt ă metodă, 
aceasta răspunde solicit ării cu un r ăspuns negativ având un 
cod de răspuns setat pe conditionsNotCorrectOrRequestSe ­
quenceError.  
CPR_037 Apoi, aparatul de testare folose ște în cele din urm ă mesajul 
SecurityAccess „sendKey” pentru a transmite un PIN unit ății 
montate pe vehicul. Pentru a aloca timpul necesar realiz ării 
procesului de autentificare a cardului, VU folose ște codul de 
răspuns negativ requestCorrectlyReceived-ResponsePending 
pentru a prelungi timpul de r ăspuns. Totu și, timpul maxim 
de răspuns nu trebuie s ă depășească 5 minute. Dup ă fina­
lizarea serviciului solicitat, VU trimite un mesaj de r ăspuns 
pozitiv sau un mesaj de r ăspuns negativ cu un cod de r ăspuns  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 315  
diferit de acesta. Codul de r ăspuns negativ requestCorrectly ­
Received-ResponsePending poate fi repetat de VU pân ă la 
finalizarea serviciului solicitat și trimiterea mesajului de 
răspuns final.  
CPR_038 Unitatea montat ă pe vehicul r ăspunde acestei solicit ări 
folosind serviciul SecurityAccess Positive Response numai 
când este în modul ETALONARE.  
CPR_039 În urm ătoarele cazuri, unitatea montat ă pe vehicul r ăspunde 
acestei solicit ări cu un răspuns negativ înso țit de un cod de 
răspuns cu valoarea:  
— subFunctionNot supported: format nevalabil pentru para ­
metrul subfunc ției (accessType);  
— conditionsNotCorrectOrRequestSequenceError: unitatea 
montată pe vehicul nu este preg ătită să accepte intro ­
ducerea unui PIN,  
— invalidKey: PIN nevalabil și numărul de încerc ări 
permise de verificare a PIN-ului nedep ășit, 
— exceededNumberOfAttempts: PIN nevalabil și numărul 
de încercări permise de verificare a PIN-ului dep ășit, 
— generalReject: PIN corect, dar tentativ ă nereușită de 
autentificare reciproc ă cu cardul de atelier.  
5.2.2  Formatul mesajului – SecurityAccess – requestSeed  
CPR_040 Formatele mesajelor pentru primitivele SecurityAccess 
„requestSeed” sunt prezentate în detaliu în tabelele urm ă­
toare.  
Tabelul 18  
Mesaj SecurityAccess Request- requestSeed  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă EE  TGT  
#3 Octet al adresei surs ă tt  SRC  
#4 Octet de lungime suplimentar  02  LEN  
#5 SecurityAccess Request 
Service Id  27 SA  
#6 accessType – requestSeed  7D  AT_RSD  
#7 Sum ă de verificare  00-FF  CS  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 316  
Tabelul 19  
Mesaj SecurityAccess – requestSeed Positive Response  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  04  LEN  
#5 SecurityAccess Positive 
Response Service Id  67 SAPR  
#6 accessType – requestSeed  7D  AT_RSD  
#7 Valoare ini țială superioară 00-FF  SEEDH  
#8 Valoare ini țială inferioară 00-FF  SEEDL  
#9 Sum ă de verificare  00-FF  CS  
Tabelul 20  
Mesaj SecurityAccess Negative Response  
Octet #  Denumirea parametrului  Valoarea 
Hex Cod mnemonic  
#1 Octet de format – adresare fizic ă 80  FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  03  LEN  
#5 negativeResponse Service Id  7F  NR  
#6 SecurityAccess Request Service Id  27  SA  
#7 responseCode =  [conditionsNotCorrect 
OrRequestSequence ­
Error  22 RC_CNC  
incorrectMessage ­
Length]  13 RC_IML  
#8 Sumă de verificare  00-FF  CS  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 317  
5.2.3  Formatul mesajului – SecurityAccess – sendKey  
CPR_041 Formatele mesajelor pentru primitivele SecurityAccess 
„sendKey” sunt prezentate în detaliu în tabelele urm ătoare.  
Tabelul 21  
Mesaj SecurityAccess Request – sendKey  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă EE  TGT  
#3 Octet al adresei surs ă tt  SRC  
#4 Octet de lungime suplimentar  m+2  LEN  
#5 SecurityAccess Request 
Service Id  27 SA  
#6 accessType – sendKey  7E  AT_SK  
de la 
#7 până la 
#m+6  Cheia #1 (superioar ă) xx  KEY  
… …  
Cheia #m (inferioar ă, m trebuie 
să fie minim 4 și maxim 8)  xx 
#m+7  Sumă de verificare  00-FF  CS  
Tabelul 22  
Mesaj SecurityAccess – sendKey Positive Response  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  02  LEN  
#5 SecurityAccess Positive 
Response Service Id  67 SAPR  
#6 accessType – sendKey  7E  AT_SK  
#7 Sum ă de verificare  00-FF  CS  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 318  
Tabelul 23  
Mesaj SecurityAccess Negative Response  
Octet #  Denumirea parametrului  Valoarea 
Hex Cod mnemonic  
#1 Octet de format – adresare fizic ă 80  FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  03  LEN  
#5 NegativeResponse Service Id  7F  NR  
#6 SecurityAccess Request Service Id  27  SA  
#7 ResponseCode =  [generalReject  10  RC_GR  
subFunctionNotSup ­
ported  12 RC_SFNS  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCorrect 
OrRequestSequence ­
Error  22 RC_CNC  
invalidKey  35  RC_IK  
exceededNumberOf 
Attempts  36 RC_ENA  
requestCorrectlyRe ­
ceived-ResponsePen ­
ding]  78 RC_RCR_RP  
#8 Sumă de verificare  00-FF  CS  
6. SERVICII DE TRANSMISIE A DATELOR  
Serviciile disponibile sunt prezentate în detaliu în tabelul urm ător: 
Tabelul 24  
Servicii de transmisie de date  
Denumirea serviciului  Descriere  
ReadDataByIdentifier  Clientul solicit ă transmisia valorii curente a 
unei înregistr ări care poate fi accesat ă prin 
recordDataIdentifier.  
WriteDataByIdentifier  Clientul solicit ă scrierea unei înregistr ări 
care poate fi accesat ă prin recordDataIdenti ­
fier. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 319  
6.1. Serviciul ReadDataByIdentifier  
6.1.1  Descrierea mesajului  
CPR_050 Serviciul ReadDataByIdentifier este folosit de client pentru 
a solicita valorile datelor înregistrate de la un server. Datele 
sunt identificate de un recordDataIdentifier. Produc ătorul 
VU trebuie s ă se asigure c ă, la efectuarea acestui serviciu, 
condițiile privind serverul sunt îndeplinite.  
6.1.2  Formatul mesajului  
CPR_051 Formatele mesajelor pentru primitivele ReadDataByIden ­
tifier sunt prezentate în detaliu în tabelele urm ătoare.  
Tabelul 25  
Mesaj ReadDataByIdentifier Request  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă EE  TGT  
#3 Octet al adresei surs ă tt  SRC  
#4 Octet de lungime suplimentar  03  LEN  
#5 ReadDataByIdentifier 
Request Service Id  22 RDBI  
de la #6 la 
#7 recordDataIdentifier = [o 
valoare din tabelul 28]  xxxx  RDI_…  
#8 Sum ă de verificare  00-FF  CS  
Tabelul 26  
Mesaj ReadDataByIdentifier Positive Response  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  m+3  LEN  
#5 ReadDataByIdentifier 
Positive Response Service Id  62 RDBIPR  
#6 și #7 recordDataIdentifier = [aceea și 
valoare ca octe ții #6 și #7 din 
tabelul 25]  xxxx  RDI_…  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 320  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
de la 
#8 până la 
#m+7  dataRecord[] =  [data#1  xx  DREC_DAT ­
A1 
: :  :  
data#m]  xx  DREC_DAT ­
Am 
#m+8  Sumă de verificare  00-FF  CS  
Tabelul 27  
Mesaj ReadDataByIdentifier Negative Response  
Octet #  Denumirea parametrului  Valoarea 
Hex Cod mnemonic  
#1 Octet de format – adresare fizic ă 80  FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  03  LEN  
#5 NegativeResponse Service Id  7F  NR  
#6 ReadDataByIdentifier Request Service 
Id 22 RDBI  
#7 ResponseCode =  [requestOutO ­
fRange  31 RC_ROOR  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCor ­
rect] 22 RC_CNC  
#8 Sumă de verificare  00-FF  CS  
6.1.3  Definirea parametrilor  
CPR_052 Parametrul  recordDataIdentifier (RDI_)  din mesajul de 
solicitare ReadDataByIdentifier identific ă o înregistrare de 
date.  
CPR_053 Valorile recordDataIdentifier definite în prezentul document 
sunt indicate în tabelul de mai jos.  
Tabelul recordDataIdentifier este format din patru coloane și 
mai multe rânduri.  
— Prima coloan ă (Hex)  cuprinde „valoarea Hex” atribuit ă 
recordDataIdentifier specificat în coloana a treia.  
— A  doua coloan ă (element de date)  precizează elementul 
de date din apendicele 1 pe care se bazeaz ă recordDa­
taIdentifier (uneori este necesar ă transcodarea).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 321  
— A  treia coloan ă (descriere)  specifică denumirea recor ­
dDataIdentifier corespunz ătoare.  
— A  patra coloan ă (cod mnemonic)  indică codul 
mnemonic al recordDataIdentifier în cauz ă. 
Tabelul 28  
Definiția valorilor recordDataIdentifier  
Hex Element de date  Denumirea recordDataIdentifier 
(a se vedea formatul în sec țiunea 
8.2) Cod mnemonic  
F90B
  TimeDate  RDI_TD  
F912
  HighResolutionTotalVehicle ­
Distance  RDI_HRTVD  
F918
  Kfactor  RDI_KF  
F91C
  LfactorTyreCircumference  RDI_LF  
F91D
  WvehicleCharacteristicFactor  RDI_WVCF  
F921
  TyreSize  RDI_TS  
F922
  NextCalibrationDate  RDI_NCD  
F92C
  SpeedAuthorised  RDI_SA  
F97D
  RegisteringMemberState  RDI_RMS  
F97E
  VehicleRegistrationNumber  RDI_ VRN  
F190
  VIN  RDI_ VIN  
CPR_054 Parametrul  dataRecord (DREC_)  este folosit de mesajul de 
răspuns pozitiv ReadDataByIdentifier pentru a furniza 
clientului (aparatul de testare) valoarea înregistr ării de date 
identificată de recordDataIdentifier. Formatele datelor sunt 
specificate în sec țiunea 8. Se pot implementa dataRecords 
suplimentare ca op țiune a utilizatorului, precum date de 
intrare, interne și de ieșire specifice pentru VU, dar 
acestea nu sunt definite în prezentul document.  
6.2. Serviciul WriteDataByIdentifier  
6.2.1  Descrierea mesajului  
CPR_056 Serviciul WriteDataByIdentifier este folosit de client pentru 
a scrie valorile înregistr ării de date pe un server. Datele sunt 
identificate de un recordDataIdentifier. Produc ătorul VU 
trebuie să se asigure c ă, la efectuarea acestui serviciu, 
condițiile privind serverul sunt îndeplinite. Pentru a 
actualiza parametrii enumera ți în tabelul 28, VU trebuie s ă 
se afle în modul ETALONARE.  
6.2.2  Formatul mesajului  
CPR_057 Formatele mesajelor pentru primitivele WriteDataByIden ­
tifier sunt prezentate în detaliu în tabelele urm ătoare.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 322  
Tabelul 29  
Mesaj WriteDataByIdentifier Request  
Octet #  Denumirea parametrului  Valoarea 
Hex Cod mnemonic  
#1 Octet de format – adresare fizic ă 80  FMT  
#2 Octet al adresei țintă EE  TGT  
#3 Octet al adresei surs ă tt  SRC  
#4 Octet de lungime suplimentar  m+3  LEN  
#5 WriteDataByIdentifier Request 
Service Id  2E WDBI  
de la 
#6 până la 
#7 recordDataIdentifier = [o valoare din 
tabelul 28]  xxxx  RDI_…  
de la 
#8 până la 
m+7 dataRecord[] =  [data#1  xx  DREC_DAT ­
A1 
: :  :  
data#m]  xx  DREC_DAT ­
Am 
#m+8  Sumă de verificare  00-FF  CS  
Tabelul 30  
Mesaj WriteDataByIdentifier Positive Response  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  03  LEN  
#5 WriteDataByIdentifier 
Positive Response Service Id  6E WDBIPR  
de la 
#6 până la 
#7 recordDataIdentifier = [aceea și 
valoare ca octe ții #6 și #7 din 
tabelul 29]  xxxx  RDI_…  
#8 Sum ă de verificare  00-FF  CS  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 323  
Tabelul 31  
Mesaj WriteDataByIdentifier Negative Response  
Octet #  Denumirea parametrului  Valoarea 
Hex Cod mnemonic  
#1 Octet de format – adresare fizic ă 80  FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  03  LEN  
#5 NegativeResponse Service Id  7F  NR  
#6 WriteDataByIdentifier Request 
Service Id  2E WDBI  
#7 ResponseCode 
= [requestOutO ­
fRange  31 RC_ROOR  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCor ­
rect] 22 RC_CNC  
#8 Sum ă de verificare  00-FF  CS  
6.2.3  Definirea parametrilor  
Parametrul  recordDataIdentifier (RDI_)  este definit în tabelul 28.  
Parametrul  dataRecord (DREC_)  este folosit de mesajul de solicitare 
WriteDataByIdentifier pentru a furniza serverului (VU) valorile înregis ­
trărilor de date identificate de recordDataIdentifier. Formatele datelor 
sunt specificate în sec țiunea 8.  
7. CONTROLUL IMPULSURILOR DE TEST – UNITATEA 
FUNCȚIONALĂ DE CONTROL AL INTR ĂRILOR/IEȘIRILOR  
Serviciile disponibile sunt prezentate în detaliu în tabelul urm ător: 
Tabelul 32  
Unitatea func țională de control al intr ărilor/ieșirilor  
Denumirea serviciului  Descriere  
InputOutputControl ­
ByIdentifier  Clientul solicit ă controlul unei intr ări/ieșiri 
specifice serverului.  
7.1. Serviciul InputOutputControlByIdentifier  
7.1.1  Descrierea mesajului  
Conexiunea realizat ă cu ajutorul conectorului frontal permite controlul 
sau monitorizarea impulsurilor de test folosind un aparat de testare 
corespunzător. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 324  
CPR_058 Linia de semnalizare I/O de etalonare poate fi configurat ă cu 
ajutorul comenzii lansate pe linia K folosind serviciul Inpu ­
tOutputControlByIdentifier pentru a selecta func ția de 
intrare sau ie șire solicitat ă pentru linie. St ările disponibile 
ale liniei sunt urm ătoarele:  
— dezactivat ă, 
— speedSignalInput, caz în care linia de semnalizare I/O de 
etalonare este utilizat ă pentru a introduce un semnal de 
viteză (semnal de test) care s ă înlocuiasc ă semnalul de 
viteză al senzorului de mi șcare; aceast ă funcție nu este 
disponibilă în modul CONTROL,  
— realTimeSpeedSignalOutputSensor, caz în care linia de 
semnalizare I/O de etalonare este utilizat ă pentru ieșirea 
unui semnal de vitez ă de la senzorul de mi șcare,  
— RTCOutput, caz în care linia de semnalizare I/O de 
etalonare este utilizat ă pentru ie șirea unui semnal de 
ceas UTC; aceast ă funcție nu este disponibil ă în modul 
CONTROL.  
CPR_059 Pentru a configura starea liniei, unitatea montat ă pe vehicul 
trebuie să fi intrat într-o sesiune de reglare și să se afle în 
modul ETALONARE sau CONTROL. Dac ă VU se afl ă în 
mod ETALONARE, cele patru st ări ale liniei pot fi selectate 
(dezactivat ă, speedSignalInput, realTimeSpeedSignalOutput ­
Sensor, RTCOutput). Dac ă VU se afl ă în modul 
CONTROL, numai dou ă stări ale liniilor pot fi selectate 
(dezactivat ă, realTimeSpeedOutputSensor). La ie șirea din 
sesiunea de reglare sau din modul ETALONARE sau 
CONTROL, unitatea montat ă pe vehicul trebuie s ă se 
asigure că linia de semnalizare I/O de etalonare a revenit 
la starea „dezactivat ă” (stare implicit ă). 
CPR_060 În cazul în care impulsurile de vitez ă sunt primite pe linia 
de intrare a semnalului de vitez ă în timp real a VU, iar linia 
de semnalizare I/O de etalonare este setat ă în modul intrare, 
linia de semnalizare I/O de etalonare este setat ă pe ieșire sau 
este readus ă la starea dezactivat ă. 
CPR_061 Ordinea opera țiunilor este urm ătoarea:  
— Stabilirea comunic ărilor cu ajutorul serviciului Star ­
tCommunication  
— Intrarea într-o sesiune de reglare cu ajutorul serviciului 
StartDiagnosticSession și trecerea în modul de 
funcționare ETALONARE sau CONTROL (ordinea de 
efectuare a acestor dou ă operațiuni nu este important ă). 
— Modificarea st ării ieșirii cu ajutorul serviciului InputOut ­
putControlByIdentifier.  
7.1.2  Formatul mesajului  
CPR_062 Formatele mesajelor pentru primitivele InputOutputControl ­
ByIdentifier sunt prezentate în detaliu în tabelele urm ătoare.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 325  
Tabelul 33  
Mesaj InputOutputControlByIdentifier Request  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă EE  TGT  
#3 Octet al adresei surs ă tt  SRC  
#4 Octet de lungime suplimentar  xx  LEN  
#5 InputOutputControlByIden ­
tifier Request Sid  2F IOCBI  
#6 și #7 InputOutputIdentifier = [Cali ­
brationInputOutput]  F960  IOI_CIO  
#8 sau 
de la 
#8 până la 
#9 ControlOptionRecord = [  COR_…  
InputOutputControlParameter – 
o valoare din tabelul 36  xx IOCP_…  
controlState – o valoare din 
tabelul 37 (a se vedea nota de 
mai jos)]  xx CS_…  
#9 sau #10  Sumă de verificare  00-FF  CS  
Notă: Parametrul controlState este prezent numai în anumite 
cazuri (a se vedea 7.1.3).  
Tabelul 34  
Mesaj InputOutputControlByIdentifier Positive Response  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  xx  LEN  
#5 inputOutputControlByIden ­
tifier Positive Response SId  6F IOCBIPR  
#6 și #7 inputOutputIdentifier = [Cali ­
brationInputOutput]  F960  IOI_CIO  
#8 sau 
de la 
#8 până la 
#9 controlStatusRecord =[  CSR_  
inputOutputControlParameter 
(aceeași valoare ca cea a 
octetului #8 din tabelul 33)  xx IOCP_…  
controlState (aceea și valoare ca 
cea a octetului #9 tabelul 33)] 
(dacă este cazul)  xx CS_…  
#9 sau #10  Sumă de verificare  00-FF  CS  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 326  
Tabelul 35  
Mesaj InputOutputControlByIdentifier Negative Response  
Octet #  Denumirea parametrului  Valoarea Hex  Cod mnemonic  
#1 Octet de format – adresare 
fizică 80 FMT  
#2 Octet al adresei țintă tt  TGT  
#3 Octet al adresei surs ă EE  SRC  
#4 Octet de lungime suplimentar  03  LEN  
#5 negativeResponse Service Id  7F  NR  
#6 inputOutputControlByIdentifier 
Request SId  2F IOCBI  
#7 responseCode=[  
incorrectMessageLength  13  RC_IML  
conditionsNotCorrect  22  RC_CNC  
requestOutOfRange  31  RC_ROOR  
deviceControlLimitsExceeded]  7A  RC_DCLE  
#8 Sum ă de verificare  00-FF  CS  
7.1.3  Definirea parametrilor  
CPR_064 Parametrul  inputOutputControlParameter (IOCP_)  este 
definit în tabelul urm ător. 
Tabelul 36  
Definiția valorilor inputOutputControlParameter  
Hex Descriere  Cod 
mnemonic  
00 ReturnControlToECU  
Această valoare indic ă serverului (VU) faptul c ă 
aparatul de testare nu mai are controlul asupra 
liniei de semnalizare I/O de etalonare.  RCTECU  
01 ResetToDefault  
Această valoare indic ă serverului (VU) faptul c ă 
s-a solicitat resetarea liniei de semnalizare I/O de 
etalonare la starea implicit ă. RTD ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 327  
Hex Descriere  Cod 
mnemonic  
03 ShortTermAdjustment  
Această valoare indic ă serverului (VU) faptul c ă 
s-a solicitat ajustarea liniei de semnalizare I/O de 
etalonare la valoarea inclus ă în parametrul 
controlState.  STA  
CPR_065 Parametrul  controlState  este prezent numai în cazul în care 
inputOutputControlParameter este setat la ShortTermAd ­
justment și este definit în tabelul urm ător: 
Tabelul 37  
Definiția valorilor controlState  
Mod  Valoarea Hex  Descriere  
Dezactivare  00  Linia I/O este dezactivat ă (stare implicit ă) 
Activare  01  Se activeaz ă linia I/O de etalonare ca speed ­
SignalInput  
Activare  02  Se activeaz ă linia I/O de etalonare ca realTi ­
meSpeedSignalOutputSensor  
Activare  03  Se activeaz ă linia I/O de etalonare ca 
RTCOutput  
8. FORMATE DATARECORDS  
Această secțiune prezint ă în detaliu:  
— normele generale care se aplic ă intervalelor de parametri transmi și 
de unitatea montat ă pe vehicul c ătre aparatul de testare,  
— formatele care se folosesc pentru datele transferate cu ajutorul servi ­
ciilor de transmisie de date descrise în sec țiunea 6.  
CPR_067 To ți parametrii identifica ți sunt compatibili cu VU.  
CPR_068 Datele transmise de VU c ătre aparatul de testare ca r ăspuns 
la un mesaj de solicitare sunt de tip cuantificabil ( și anume, 
valoarea activ ă a parametrului solicitat, astfel cum a fost 
măsurată sau observat ă de VU).  
8.1. Intervalele parametrilor transmi și 
CPR_069 Tabelul 38 define ște intervalele folosite la determinarea vala ­
bilității unui parametru transmis.  
CPR_070 Valorile din intervalul „indicator de eroare” ( error indicator ) 
permit unit ății montate pe vehicul s ă indice imediat faptul c ă 
nicio dată parametric ă valabilă nu este disponibil ă pentru 
moment din cauza unui anumit tip de eroare la nivelul taho ­
grafului.  
CPR_071 Valorile din intervalul „indisponibil” ( not available ) permit 
unității montate pe vehicul s ă transmită un mesaj care 
conține un parametru indisponibil sau incompatibil cu 
modulul în cauz ă. Valorile din intervalul „nesolicitat” ( not 
requested ) permit transmiterea de c ătre un dispozitiv a unui 
mesaj de comand ă și identifică acei parametri în cazul c ărora 
nu se așteaptă niciun răspuns de la dispozitivul de recep ție. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 328  
CPR_072 Dac ă defecțiunea unei componente împiedic ă transmisia de 
date valabile pentru un parametru, în locul datelor para ­
metrice respective ar trebui folosi ți indicatorii de eroare 
descriși în tabelul 38. Cu toate acestea, dac ă datele 
măsurate sau calculate au ca rezultat o valoare valabil ă 
care depășește totuși intervalul definit al parametrului 
respectiv, indicatorul de eroare nu ar trebui folosit. Datele 
trebuie să fie transmise folosind valoarea minim ă sau 
maximă adecvată a parametrului.  
Tabelul 38  
Intervalele dataRecords  
Denumirea intervalului  1 octet 
(valoarea Hex)  2 octeți 
(valoarea Hex)  4 octeți 
(valoarea Hex)  ASCII  
Semnal valabil  00-FA  0000-FAFF  00000000-FAFFFFFF  de la 1 la 
254 
Indicator specific parametrului  FB  FB00-FBFF  FB000000-FBFFFFFF  nu exist ă 
Interval rezervat pentru viitorii 
biți ai indicatorului  FC-FD  FC00-FDFF  FC000000-FDFFFFFF  nu exist ă 
Indicator de eroare  FE  FE00-FEFF  FE000000-FEFFFFFF  0  
Nu sunt disponibile sau nu sunt 
solicitate  FF FF00-FFFF  FF000000-FFFFFFFF  FF  
CPR_073 Pentru parametrii coda ți în ASCII, caracterul ASCII „*” este 
rezervat ca delimitator.  
8.2. Formate dataRecords  
În tabelele 39 – 42 de mai jos sunt prezentate în detaliu formatele care 
trebuie folosite prin intermediul serviciilor ReadDataByIdentifier și 
WriteDataByIdentifier.  
CPR_074 În tabelul 39 sunt indicate lungimea, rezolu ția și domeniul 
de valori ale fiec ărui parametru identificat de recordDataI ­
dentifier:  
Tabelul 39  
Formatul dataRecords  
Denumirea parametrului  Lungimea datelor 
(octeți) Rezoluția Domeniul de valori  
TimeDate  8  A se vedea detaliile din tabelul 40  
HighResolutionTotalVehicle ­
Distance  4 amplificare 5 m/bit, deplasare 0 m  de la 0 pân ă la + 
21 055 406 km  
Kfactor  2  amplificare 0,001 impulsuri/m/bit, 
deplasare 0  0-64,255 impulsuri/m  
LfactorTyreCircumference  2  amplificare 0,125 10  – 3 m/bit, 
deplasare 0  de la 0 la 8,031 m  
WvehicleCharacteristicFactor  2  amplificare 0,001 impulsuri/m/bit, 
deplasare 0  0-64,255 impulsuri/m  
TyreSize  15  ASCII  ASCII  
NextCalibrationDate  3  A se vedea detaliile din tabelul 41  
SpeedAuthorised  2  amplificare 1/256 km/h/bit, deplasare 
0 0-250,996 km/h  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 329  
Denumirea parametrului  Lungimea datelor 
(octeți) Rezoluția Domeniul de valori  
RegisteringMemberState  3  ASCII  ASCII  
VehicleRegistrationNumber  14  A se vedea detaliile din tabelul 42  
VIN 17  ASCII  ASCII  
CPR_075 În tabelul 40 sunt prezentate în detaliu formatele diferi ților 
octeți ai parametrului TimeDate:  
Tabelul 40  
Formatul detaliat al TimeDate (valoarea recordDataIdentifier # F90B)  
Octet  Definirea para ­
metrilor  Rezoluția Domeniul de 
valori  
1 Secunde  amplificare 0,25 s/bit, deplasare 
0 s de la 0 la 
59,75 s  
2 Minute  amplificare 1 min/bit, deplasare 
0 min  0-59 min  
3 Ore  amplificare 1 h/bit, deplasare 0 h  0-23 h  
4 Luna  amplificare 1 lun ă/bit, deplasare 
0 luni  1-12 luni  
5 Ziua  amplificare 0,25 zile/bit, 
deplasare 0 zile 
(a se vedea NOTA de sub 
tabelul 41)  0,25-31,75 
zile 
6 Anul  amplificare 1 lun ă/bit, deplasare 
an + 1985 
(a se vedea NOTA de sub 
tabelul 41)  anul 1985- 
anul 2235  
7 Deplasare 
locală minute  amplificare 1 min/bit, deplasare 
– 125 min  de la – 59 la + 
59 min  
8 Deplasare 
locală ore amplificare 1 h/bit, deplasare 
-125 h  de la – 23 la + 
23 h 
CPR_076 În tabelul 41 sunt prezentate în detaliu formatele diferi ților octeți ai parame ­
trului NextCalibrationDate.  
Tabelul 41  
Formatul detaliat al NextCalibrationDate (valoarea recordDataIdentifier # 
F922)  
Octet  Definirea para ­
metrilor  Rezoluția Domeniul de 
valori  
1 Luna  amplificare 1 lun ă/bit, deplasare 
0 luni  1-12 luni  
2 Ziua  amplificare 0,25 zile/bit, 
deplasare 0 zile 
(a se vedea NOTA de mai jos)  0,25-31,75 
zile 
3 Anul  amplificare 1 lun ă/bit, deplasare 
an + 1985 
(a se vedea NOTA de mai jos)  anul 1985- 
anul 2235  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 330  
NOTĂ privind folosirea parametrului „Zi”:  
1) O valoare 0 pentru dat ă este o valoare nul ă. Valorile 1, 2, 3 și 4 
sunt folosite pentru a identifica prima zi a lunii; valorile 5, 6, 7 și 8 
identifică a doua zi a lunii etc.  
2) Acest parametru nu influen țează și nici nu modific ă parametrul 
pentru oră menționat anterior.  
NOTĂ privind folosirea octetului parametrului „An”:  
Valoarea 0 pentru an corespunde anului 1985; valoarea 1 indic ă anul 
1986 etc.  
CPR_078 În tabelul 42 sunt prezentate în detaliu formatele diferi ților 
octeți ai parametrului VehicleRegistrationNumber:  
Tabelul 42  
Formatul detaliat al VehicleRegistrationNumber (valoarea 
recordDataIdentifier # F97E)  
Octet  Definirea parametrilor  Rezolu ția Domeniul de 
valori  
1 Pagin ă de cod (conform 
definiției din apendicele 1)  ASCII  de la 01 la 0A  
2-14 Numărul de înmatriculare al 
vehiculului (conform defini ției 
din apendicele 1)  ASCII  ASCII  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 331  
Apendicele 9.  
OMOLOGAREA DE TIP LISTA TESTELOR MINIME OBLIGATORII  
CUPRINS  
1. INTRODUCERE  
2. TESTE DE FUNC ȚIONARE A UNIT ĂȚII MONTATE PE VEHICUL  
3. TESTE DE FUNC ȚIONARE A SENZORULUI DE MI ȘCARE  
4. TESTE DE FUNC ȚIONARE A CARDURILOR DE TAHOGRAF  
5. TESTE PRIVIND ECHIPAMENTUL GNSS EXTERN  
▼M1 
6. TESTE PRIVIND ECHIPAMENTUL EXTERN DE COMUNICARE LA 
DISTANȚĂ 
▼B 
7. TESTE DE FUNC ȚIONARE PRIVIND HÂRTIA  
8. TESTE DE INTEROPERABILITATE  
1. INTRODUCERE  
1.1. Omologarea de tip  
Omologarea CE de tip pentru aparatura de înregistrare (sau o component ă a 
acesteia) sau pentru un card de tahograf se bazeaz ă pe: 
▼M1 
— o  certificare a securit ății, pe baza specifica țiilor prevăzute în criteriile 
comune, în raport cu un obiectiv de securitate care respect ă în totalitate 
apendicele 10 la prezenta anex ă; 
▼B 
— o  certificare a func ționării, efectuată de o autoritate a unui stat 
membru, care certific ă faptul c ă articolul testat respect ă cerințele 
prezentei anexe din punctul de vedere al func țiilor îndeplinite, al 
preciziei m ăsurătorilor și al caracteristicilor de mediu;  
— o  certificare a interoperabilit ății, efectuată de un organism competent, 
care certific ă faptul că aparatura de înregistrare (sau cardul de tahograf) 
este în întregime interoperabil ă(interoperabil) cu modelele necesare de 
card de tahograf (sau de aparatur ă de înregistrare) (a se vedea capitolul 8 
din prezenta anex ă). 
Prezentul apendice enumer ă testele minime care trebuie efectuate de c ătre o 
autoritate a unui stat membru în cadrul testelor de func ționare, precum și 
testele minime care trebuie efectuate de organismul competent în cadrul 
testelor de interoperabilitate. Procedurile care trebuie urmate în vederea 
efectuării testelor sau tipul de teste nu sunt specificate în cuprinsul 
prezentului document.  
Prezentul apendice nu se vizeaz ă aspecte legate de certificarea securit ății. 
Dacă unele teste necesare pentru omologarea de tip sunt efectuate în cadrul 
procesului de evaluare și de certificare a securit ății, ele nu mai trebuie 
repetate. Într-un asemenea caz, este suficient ă inspectarea rezultatelor 
acestor teste de securitate. În scop informativ, cerin țele care ar urma s ă 
fie testate (sau cele strâns legate de testele care ar urma s ă fie efectuate) 
în cadrul certific ării securit ății sunt marcate cu un „*” în cuprinsul 
prezentului apendice.  
Cerințele numerotate se refer ă la corpusul anexei, în timp ce celelalte cerin țe 
se referă la celelalte apendice (de exemplu, PIC_001 se refer ă la cerința 
PIC_001 din apendicele 3, „Pictograme”).  
Prezentul apendice trateaz ă separat omologarea de tip a senzorului de 
mișcare, a unit ății montate pe vehicul și a echipamentului GNSS extern în 
calitate de componente ale aparaturii de înregistrare. Fiecare component ă va ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 332  
primi propriul certificat de omologare de tip în care vor fi indicate celelalte 
componente compatibile. Testul de func ționare a senzorului de mi șcare (sau 
a echipamentului GNSS extern) se efectueaz ă împreună cu testul de 
funcționare a unit ății montate pe vehicul și viceversa.  
Interoperabilitatea dintre fiecare model de senzor de mi șcare (respectiv echi ­
pament GNSS extern) și fiecare model de unitate montat ă pe vehicul nu este 
necesară. În acest caz, omologarea de tip a unui senzor de mi șcare (res­
pectiv, echipament GNSS extern) poate fi acordat ă numai în combina ție cu 
omologarea de tip a unit ății montate pe vehicul corespunz ătoare și viceversa.  
1.2. Referințe 
În prezentul apendice se utilizeaz ă următoarele referin țe: 
IEC 60068-2-1: Environmental testing – Part 2-1: Tests – Test A: Rece  
IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests 
B: dry heat (sinusoidal).  
IEC 60068-2-6: Environmental testing – Part 2: Tests – Test Fc: Vibration  
IEC 60068-2-14: Environmental testing; Part 2-14: Tests; Test N: Change of 
temperature  
IEC 60068-2-27: Environmental testing. Part 2: Tests. Test Ea and guidance: 
Shock  
IEC 60068-2-30: Environmental testing – Part 2-30: Tests – Test Db: Damp 
heat, cyclic (12 h + 12 h cycle)  
IEC 60068-2-64: Environmental testing – Part 2-64: Tests – Test Fh: 
Vibration, broadband random and guidance  
IEC 60068-2-78 Environmental testing – Part 2-78: Tests – Test Cab: Damp 
heat, steady state  
ISO 16750-3 – Mechanical loads (2012-12)  
ISO 16750-4 – Climatic loads(2010-04).  
ISO 20653: Road vehicles – Degree of protection (IP code) – Protection of 
electrical equipment against foreign objects, water and access  
ISO 10605:2008 + Technical Corrigendum:2010 + AMD1:2014 Road 
vehicles – Test methods for electrical disturbances from electrostatic 
discharge  
ISO 7637-1:2002 + AMD1: 2008 Road vehicles – Electrical disturbances 
from conduction and coupling – Part 1: Definitions and general considera ­
tions.  
ISO 7637-2 Road vehicles – Electrical disturbances from conduction and 
coupling – Part 2: Electrical transient conduction along supply lines only.  
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.  
ISO/IEC 7816-1 Identification cards – Integrated circuit(s) cards with 
contacts – Part 1: Physical characteristics..  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 333  
ISO/IEC 7816-2 Information technology – Identification cards – Integrated 
circuit(s) cards with contacts – Part 2: Dimensions and location of the 
contacts.  
ISO/IEC 7816-3 Information technology – Identification cards – Integrated 
circuit(s) cards with contacts – Part 3: Semnale electronice și protocol de 
transmisie.  
ISO/IEC 10373-1:2006 + AMD1:2012 Identification cards – Test methods – 
Part 1: Caracteristici generale  
ISO/IEC 10373-3:2010 + Technical Corrigendum:2013 Identification cards 
– Test methods – Part 3: Integrated circuit cards with contacts and related 
interface devices  
ISO 16844-3:2004, Cor 1:2006 Road vehicles – Tachograph systems – Part 
3: Motion sensor interface (with vehicle units).  
ISO 16844-4 Road vehicles – Tachograph systems – Part 4: CAN interface  
ISO 16844-6 Road vehicles – Tachograph systems – Part 6: Diagnostics  
ISO 16844-7 Road vehicles – Tachograph systems – Part 7: Parameters  
ISO 534 Paper and board – Determination of thickness, density and specific 
volume  
UN ECE R10 Uniform provisions concerning the approval of vehicles with 
regard to electromagnetic compatibility (United Nation Economic 
Commission for Europe)  
2. TESTE DE FUNC ȚIONARE A UNIT ĂȚII MONTATE PE VEHICUL  
▼M1 
Nr. Test  Descriere  Cerin țe asociate  
1 Examinare administrativ ă 
1.1 Documenta ție Corectitudinea documenta ției 
1.2 Rezultatele testelor 
efectuate de produc ător Rezultatele testului efectuat de produc ător în 
cursul integr ării. 
Documente pentru demonstrarea testelor efec ­
tuate.  88, 89, 91  
2 Inspec ție vizuală 
2.1 Conformitatea cu documenta ția 
2.2 Identificare/inscrip ții 224-226  
2.3 Materiale  219-223  
2.4 Sigilare  398, 401-405  
2.5 Interfețe externe  
3 Teste de func ționare  
3.1 Funcții oferite  02, 03, 04, 05, 07, 382  
3.2 Moduri de func ționare  09-11*, 134, 135  
3.3 Funcții și drepturi de acces la date  12* 13*, 382, 383, 386-389  
3.4 Monitorizarea introducerii și retragerii cardurilor  15, 16, 17, 18, 19*, 20*, 134  
3.5 Măsurarea vitezei și a distanței 21-31  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 334  
Nr. Test  Descriere  Cerin țe asociate  
3.6 Măsurarea timpului (teste efectuate la 20 °C)  38-43  
3.7 Monitorizarea activit ăților conduc ătorului auto  44-53, 134  
3.8 Monitorizarea regimului de conducere  54, 55, 134  
3.9 Introducerea manual ă a datelor  56-62  
3.10 Gestionarea bloc ărilor efectuate de societate  63-68  
3.11 Monitorizarea activit ăților de control  69, 70  
3.12 Detectarea de evenimente și/sau anomalii  71-88, 134  
3.13 Date de identificare a echipamentelor  93*, 94*, 97, 100  
3.14 Date privind introducerea și retragerea cardului de conduc ător auto  102*-104*  
3.15 Date privind activitatea conduc ătorului auto  105*-107*  
3.16 Date privind locurile și pozițiile 108*-112*  
3.17 Date privind odometrul  113*-115*  
3.18 Date privind viteza detaliat ă 116*  
3.19 Date privind evenimentele  117*  
3.20 Date privind anomaliile  118*  
3.21 Date privind etalonarea  119*-121*  
3.22 Date privind reglarea orei  124*, 125*  
3.23 Date privind activit ățile de control  126*, 127*  
3.24 Date privind bloc ările efectuate de societate  128*  
3.25 Date privind activitatea de desc ărcare  129*  
3.26 Date privind condi țiile specifice  130*, 131*  
3.27 Înregistrarea și stocarea informa țiilor pe cardurile de tahograf  136, 137, 138*, 139*, 141*, 
142, 143 
144, 145, 146*, 147*, 148*, 
149, 150  
3.28 Afișare 90, 134, 
151-168, 
PIC_001, DIS_001  
3.29 Imprimare  90, 134, 
169-181, PIC_001, PRT_001 - 
PRT_014  
3.30 Avertizare  134, 182-191, 
PIC_001  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 335  
Nr. Test  Descriere  Cerin țe asociate  
3.31 Descărcarea datelor pe suporturi externe  90, 134, 192-196  
3.32 Comunicarea la distan ță pentru controalele selective în trafic  197-199  
3.33 Date de ie șire transmise unor dispozitive externe suplimentare  200, 201  
3.34 Etalonare  202-206*, 383, 384, 386-391  
3.35 Verificarea etalon ării în trafic  207-209  
3.36 Reglarea orei  210-212*  
3.37 Neinterferen ța cu funcțiile suplimentare  06, 425  
3.38 Interfața senzorului de mi șcare 02, 122  
3.39 Echipamentul GNSS extern  03, 123  
3.40 Se verific ă dacă VU detecteaz ă, înregistreaz ă și stochează evenimentul 
(evenimentele) și/sau anomalia (anomaliile) definite de produc ătorul VU 
atunci când un senzor de mi șcare asociat reac ționează la câmpurile 
magnetice care perturb ă detectarea deplas ării vehiculului.  217 
3.41 Suite cifru și parametri de domeniu standardiza ți CSM_48, CSM_50  
4 Teste de mediu  
4.1 Temperatur ă Verificarea func ționalității prin: 
Test în conformitate cu ISO 16750-4, Chapter 
5.1.1.2: Low temperature operation test (72 h 
@ – 20 °C) 
Acest test se refer ă la IEC 60068-2-1: Envi ­
ronmental testing – Part 2-1: Tests – Test A: 
Cold 
Test în conformitate cu ISO 16750-4: Chapter 
5.1.2.2: High temperature operation test (72 h 
at 70 °C) 
Acest test se refer ă la IEC 60068-2-2: Basic 
environmental testing procedures; part 2: 
tests; tests B: dry heat 
Test în conformitate cu ISO 16750-4: Chapter 
5.3.2: Rapid change of temperature with 
specified transition duration (– 20°C/70 °C, 
20 cycles, dwell time 2h at each temperature) 
Un număr redus de teste (dintre cele definite 
în secțiunea 3 din prezentul tabel) pot fi 
efectuate la temperatura cea mai sc ăzută, la 
temperatura cea mai ridicat ă și pe parcursul 
ciclurilor de temperatur ă 213 
4.2 Umiditate  Se verific ă, prin intermediul testului Db IEC 
60068-2-30, dac ă unitatea montat ă pe vehicul 
poate suporta un ciclu de c ăldură umedă (test 
de căldură), prin șase cicluri de câte 24 de ore 
fiecare, cu temperaturi variind între + 25 °C și 
+ 55 °C la o umiditate relativ ă de 97 % la 
+ 25 °C și de 93 % la + 55 °C  214 ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 336  
Nr. Test  Descriere  Cerin țe asociate  
4.3 Teste mecanice  1. Vibra ții sinusoidale. 
Se verific ă dacă unitatea montat ă pe 
vehicul poate suporta vibra ții sinusoidale 
cu următoarele caracteristici: 
deplasare constant ă la frecven țe între 5 și 
11 Hz: valoare maxim ă 10 mm 
accelerație constant ă între 11 și 300 Hz: 
5 g 
Această cerință este verificat ă prin inter ­
mediul testului Fc IEC 60068-2-6, cu o 
durată minimă a testului de 3 × 12 ore 
(12 ore per ax ă) 
ISO 16750-3 nu prevede un test de vibra ții 
sinusoidale pentru dispozitivele situate în 
cabina decuplat ă a vehiculului. 
2. Vibrații aleatorii: 
Test în conformitate cu ISO 16750-3: 
Chapter 4.1.2.8: Test VIII: Commercial 
vehicle, decoupled vehicle cab 
Test de vibra ții aleatorii, 10…2 000 Hz, 
RMS vertical 21,3 m/s  2 , RMS longitudinal 
11,8 m/s  2 , RMS lateral 13,1 m/s  2 , 3 axe, 
32 de ore per ax ă, inclusiv ciclul de 
temperatur ă – 20…70 °C. 
Acest test se refer ă la IEC 60068-2-64: 
Environmental testing – Part 2-64: Tests 
– Test Fh: Vibration, broadband random 
and guidance 
3. Șocuri: 
șoc mecanic semisinusoidal 3 g în confor ­
mitate cu ISO 16750. 
Testele descrise anterior se efectueaz ă pe 
mostre diferite ale tipului de echipament 
testat.  219 
4.4 Protecție împotriva 
apei și corpurilor 
străine Test în conformitate cu ISO 20653: Road 
vehicles – Degree of protection (IP code) – 
Protection of electrical equipment against 
foreign objects, water and access (No 
change in parameters); Valoare minim ă IP 40  220, 221  
4.5 Protecție împotriva 
supratensiunii  Se verifică dacă unitatea montat ă pe vehicul 
poate suporta o surs ă de alimentare de: 
versiuni de 24 V: 34 V la + 40 °C 1 or ă 
versiuni de 12 V: 17 V la + 40 °C 1 or ă( 
ISO 16750-2)  216 ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 337  
Nr. Test  Descriere  Cerin țe asociate  
4.6 Protecție împotriva 
polarității inverse  Se verifică dacă unitatea montat ă pe vehicul 
poate suporta o inversare a polarit ății la sursa 
de alimentare 
(ISO 16750-2)  216 
4.7 Protecție împotriva 
scurtcircuitelor  Se verifică dacă semnalele de intrare/ie șire 
sunt protejate împotriva scurtcircuitelor la 
sursa de alimentare și la masă 
(ISO 16750-2)  216 
5 Teste CEM  
5.1 Emisii de radia ții și 
susceptibilitate de 
radiații Conformitate cu Regulamentul R10 al CEE  218  
5.2 Descărcări electros ­
tatice  Conformitate cu ISO 10605:2008 + 
Rectificare tehnic ă: 2010 + 
AMD1:2014: + /– 4kV pentru contact și + /– 
8kV pentru evacuarea aerului  218 
5.3 Susceptibilitate de 
conducție tranzitorie la 
sursa de alimentare  Pentru versiunile de 24 V: conformitate cu 
ISO 7637-2 + Regulamentul nr. 10 al CEE 
Rev. 3: 
puls 1a: Vs=– 450 V Ri=50 ohmi 
puls 2 a: Vs=+ 37 V Ri=2 ohmi 
puls 2b: Vs=+ 20 V Ri=0,05 ohmi 
puls 3 a: Vs=– 150 V Ri=50 ohmi 
puls 3b: Vs=+ 150 V Ri=50 ohmi 
puls 4: Vs=– 16V Va=– 12V t6=100 ms 
puls 5: Vs=+ 120 V Ri=2,2 ohmi td=250 ms 
Pentru versiunile de 12 V: conformitate cu 
ISO 7637-1 + Regulamentul nr. 10 al CEE 
Rev. 3: 
puls 1: Vs=– 75 V Ri=10 ohmi 
puls 2 a: Vs=+ 37 V Ri=2 ohmi 
puls 2b: Vs=+ 10 V Ri=0,05 ohmi 
puls 3 a: Vs=– 112 V Ri=50 ohmi 
puls 3b: Vs=+ 75 V Ri=50 ohmi 
puls 4: Vs=– 6 V Va=– 5 V t6=15 ms 
puls 5: Vs=+ 65 V Ri=3 ohmi td=100ms 
Pulsul 5 se testeaz ă numai pentru unit ățile 
montate pe vehicule care sunt proiectate 
pentru a fi instalate în vehicule care nu 
dispun de o protec ție externă obișnuită 
împotriva întreruperii aliment ării 
Pentru propunerea privind întreruperea 
alimentării, a se vedea ISO 16750-2, a 4-a 
ediție, capitolul 4.6.4.  218 ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 338  
3. TESTE DE FUNC ȚIONARE A SENZORULUI DE MI ȘCARE  
Nr. Test  Descriere  Cerin țe asociate  
1. Examinare administrativ ă 
1.1 Documenta ție Corectitudinea documenta ției 
2. Inspec ție vizuală 
2.1. Conformitatea cu documenta ția 
2.2. Identificare/inscrip ții 225, 226,  
2.3 Materiale  219 – 223  
2.4. Sigilare  398, 401 – 405  
3. Teste de func ționare  
3.1 Date de identificare a senzorului  95 – 97*  
3.2 Asociere senzor de mi șcare – unitate montat ă pe vehicul  122*, 204  
3.3 Detectarea mi șcării 
Precizia m ăsurării mișcării 30 – 35  
3.4 Interfața unității montate pe vehicul  02  
3.5 Se verific ă dacă senzorul de mi șcare este imun la un câmp magnetic constant. 
Alternativ, se verific ă dacă senzorul de mi șcare reacționează la câmpurile 
magnetice constante care perturb ă detectarea deplas ării vehiculului astfel încât 
o VU conectat ă să poată detecta, înregistra și stoca anomaliile senzorului  217 
4. Teste de mediu  
4.1 Temperatura de func ționare  Se verific ă funcționalitatea (conform defini ției 
din testul nr. 3.3) pentru intervalul de tempe ­
ratură [– 40 °C; + 135 °C] prin: 
testul Ad, IEC 60068-2-1, cu o durat ă de 96 de 
ore a testului la temperatura minim ă To  min 
testul Bd, IEC 60068-2-2, cu o durat ă a testului 
de 96 de ore la temperatura maxim ă To  max 
Test în conformitate cu ISO 16750-4: Chapter 
5.1.1.2: Low temperature operation test (24 h @ 
– 40 °C) 
Acest test se refer ă la IEC 60068-2-1: Environ ­
mental testing – Part 2-1: Tests – Test A: Cold 
IEC 68-2-2 test Bd, with a test duration of 96 
hours at the lowest temperature of – 40 °C. 
Test în conformitate cu ISO 16750-4: Chapter 
5.1.2.2: Low temperature operation test (96 h @ 
135 °C) 
Acest test se refer ă la IEC 60068-2-2: Basic 
environmental testing procedures; part 2: tests; 
tests B: dry heat  213 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 339  
Nr. Test  Descriere  Cerin țe asociate  
4.2 Cicluri de temperatur ă Test în conformitate cu ISO 16750-4: Chapter 
5.3.2: Rapid change of temperature with 
specified transition duration (– 40 °C/135 °C, 
20 cycles, dwell time 30 min at each tempe ­
rature) 
IEC 60068-2-14: Environmental testing; Part 2- 
14: Tests; Test N: Change of temperature  213 
4.3 Cicluri de umiditate  Se verific ă funcționalitatea (conform defini ției 
din testul nr. 3.3) prin testul Db, IEC 60068- 
2-30, prin șase cicluri de câte 24 de ore fiecare, 
temperatura variind în cadrul fiec ărui ciclu între 
+ 25 °C și + 55 °C, la o umiditate relativ ă de 
97 % la + 25 °C și egală cu 93 % la + 55 °C  214 
4.4 Vibrații ISO 16750-3: Chapter 4.1.2.6: Test VI: 
Commercial vehicle, engine, gearbox 
Test de vibra ții în mod mixt, care include: 
a) Test de vibra ții sinusoidale, 20...520 Hz, 11,4 
... 120 m/s  2 , <= 0,5 oct/min 
b) Test de vibra ții aleatorii, 10...2 000 Hz, RMS 
177 m/s  2 
94 de ore pe ax ă, inclusiv ciclul de temperatur ă 
-20...70 °C) 
Acest test se refer ă la IEC 60068-2-80: Environ ­
mental testing – Part 2-80: Tests – Test Fi: 
Vibration – Mixed mode  219 
4.5 Șoc mecanic  ISO 16750-3: Chapter 4.2.3: Test VI: Test for 
devices in or on the gearbox 
șoc semisinusoidal, accelera ție de stabilit în 
intervalul 3 000...15 000 m/s  2 , durata pulsului 
de stabilit, dar < 1 ms, num ăr de șocuri: de 
stabilit 
Acest test se refer ă la IEC 60068-2-27: Environ ­
mental testing. Part 2: Tests. Test Ea and 
guidance: Shock  219 
4.6 Protecție împotriva apei și 
corpurilor str ăine Test în conformitate cu ISO 20653: Road 
vehicles – Degree of protection (IP code) – 
Protection of electrical equipment against 
foreign objects, water and access 
(Valoare țintă IP 64)  220, 221  
4.7 Protecție împotriva polarit ății 
inverse  Se verific ă dacă senzorul de mi șcare poate 
suporta o inversare a polarit ății la sursa de 
alimentare  216 
4.8 Protecție împotriva scurtcir ­
cuitelor  Se verifică dacă semnalele de intrare/ie șire sunt 
protejate împotriva scurtcircuitelor la sursa de 
alimentare și la masă 216 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 340  
Nr. Test  Descriere  Cerin țe asociate  
5. CEM  
5.1 Emisii de radia ții și suscepti­
bilitate de radia ții Se verifică conformitatea cu Regulamentul R10 
al CEE  218 
5.2 Descărcări electrostatice  Conformitate cu ISO 10605:2008 + Rectificare 
tehnică:2010 + AMD1:2014: +/- 4kV pentru 
contact și +/- 8kV pentru evacuarea aerului  218 
5.3 Susceptibilitate de conduc ție 
tranzitorie la sursa de alimen ­
tare) Pentru versiunile de 24 V: conformitate cu ISO 
7637-2 + Regulamentul nr. 10 al CEE Rev. 3: 
puls 1a: Vs=-450 V Ri=50 ohmi 
puls 2a: Vs=+37 V Ri=2 ohmi 
puls 2b: Vs=+20 V Ri=0,05 ohmi 
puls 3a: Vs=-150 V Ri=50 ohmi 
puls 3b: Vs=+150 V Ri=50 ohmi 
puls 4: Vs=-16 V Va=-12 V t6=100ms 
puls 5: Vs=+120 V Ri=2,2 ohmi td=250ms 
Pentru versiunile de 12 V: conformitate cu ISO 
7637-1 + Regulamentul nr. 10 al CEE Rev. 3: 
puls 1: Vs=-75 V Ri=10 ohmi 
puls 2a: Vs=+37 V Ri=2 ohmi 
puls 2b: Vs=+10 V Ri=0,05 ohmi 
puls 3a: Vs=-112 V Ri=50 ohmi 
puls 3b: Vs=+75 V Ri=50 ohmi 
puls 4: Vs=-6 V Va=-5 V t6=15ms 
puls 5: Vs=+65 V Ri=3 ohmi td=100ms 
Pulsul 5 se testeaz ă numai pentru unit ățile 
montate pe vehicule care sunt proiectate pentru 
a fi instalate în vehicule care nu dispun de o 
protecție externă obișnuită împotriva întreruperii 
alimentării 
Pentru propunerea privind întreruperea alimen ­
tării, a se vedea ISO 16750-2, a 4-a edi ție, 
capitolul 4.6.4.  218 
4. TESTE DE FUNC ȚIONARE A CARDURILOR DE TAHOGRAF  
Testele în conformitate cu prezenta sec țiune 4, numerele  
5 „Teste privind protocoalele”;  
6 „Structura cardului” și 
7 „Teste de func ționare”  
pot fi efectuate de evaluator sau de certificator în cursul procesului de 
certificare a securit ății modulul cipului în conformitate cu criteriile 
comune (CC).  
Testele cu numerele 2.3 și 4.2 sunt identice. Este vorba despre testele 
mecanice efectuate asupra ansamblului format din corpul cardului și 
modulul cipului. Aceste teste sunt necesare dac ă una dintre aceste 
componente (corpul cardului, modului cipului) este modificat ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 341  
Nr. Test  Descriere  Cerin țe asociate  
1. Examinare administrativ ă 
1.1 Documenta ție Corectitudinea documenta ției 
2 Corpul cardului  
2.1 Elementele imprimate  Se verifică dacă toate elementele de protec ție și toate 
datele vizibile sunt imprimate corect pe card și sunt 
conforme. 
[Identificator] 
Anexa 1C capitolul 4.1 „Date vizibile”, punctul 227) 
Pe recto figureaz ă: 
cuvintele „Card de conduc ător auto” sau „Card de 
control” sau „Card de atelier” sau „Card de socie ­
tate”, tipărite cu majuscule în limba sau limbile 
oficiale ale statului membru emitent, în func ție de 
tipul cardului. 
[Denumirea statului membru] 
Anexa 1C capitolul 4.1 „Date vizibile”, punctul 228) 
Pe recto figureaz ă: 
denumirea statului membru emitent al cardului 
(opțional). 
[Indicativ] 
Anexa 1C capitolul 4.1 „Date vizibile”, punctul 229) 
Pe recto figureaz ă: 
indicativul statului membru emitent al cardului, tip ărit 
în negativ într-un dreptunghi albastru și înconjurat de 
12 stele galbene. 
[Enumerare] 
Anexa 1C capitolul 4.1 „Date vizibile”, punctul 232) 
Pe verso figureaz ă: 
explicații pentru elementele numerotate de pe recto-ul 
cardului. 
[Culoare] 
Anexa 1C capitolul 4.1 „Date vizibile”, punctul 234) 
Cardurile de tahograf se imprim ă pe fonduri având 
următoarele culori predominante: 
— cardul de conduc ător auto: alb; 
— cardul de atelier: ro șu; 
— cardul de control: albastru; 
— cardul de societate: galben.  227 – 229, 232, 234 – 
236 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 342  
Nr. Test  Descriere  Cerin țe asociate  
[Securitate] 
Anexa 1C capitolul 4.1 „Date vizibile”, punctul 235) 
Cardurile de tahograf trebuie s ă aibă cel puțin 
următoarele caracteristici pentru protec ția corpului 
cardului împotriva falsific ării și a manipul ării fraudu- 
loase: 
— un fond de securitate cu ghio șe și irizat; 
— cel puțin o linie bicolor ă microimprimat ă. 
[Inscripții] 
Anexa 1C capitolul 4.1 „Date vizibile”, punctul 236) 
Statele membre pot ad ăuga culori sau inscrip ții cum ar 
fi simboluri na ționale sau caracteristici de securitate. 
[Marca de omologare] 
Cardurile de tahograf con țin o marcă de omologare. 
Marca de omologare const ă în următoarele: 
— un dreptunghi în interiorul c ăruia se plaseaz ă litera 
„e” urmat ă de un num ăr sau de o liter ă 
distinctiv(ă) pentru țara care a emis omologarea; 
— un num ăr de omologare corespunz ător numărului 
certificatului de omologare acordat unui card de 
tahograf, plasat oriunde în imediata apropiere a 
dreptunghiului susmen ționat.  
2.2 Teste mecanice  
[Mărimea cardului] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical 
characteristics, 
[5] Dimensiunea cardului; 
[5.1] Mărimea cardului; 
[5.1.1] Dimensiunile cardului și toleranțe; 
Card de tip ID-1 Card neutilizat 
[Marginile cardului] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[5] Dimensiunea cardului; 
[5.1] Mărimea cardului; 
[5.1.2] Marginile cardului  240, 243 
ISO/IEC 7810  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 343  
Nr. Test  Descriere  Cerin țe asociate  
[Construcția cardului] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[6] Construc ția cardului 
[Materiale utilizate pentru fabricarea cardului] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[7] Materiale utilizate pentru fabricarea cardului 
[Rigiditatea de îndoire] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[8] Caracteristicile cardului, 
[8.1] Rigiditate de îndoire 
[Toxicitate] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[8] Caracteristicile cardului, 
[8.3] Toxicitate 
[Rezistența la substan țe chimice] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[8] Caracteristicile cardului, 
[8.4] Rezisten ța la substan țe chimice 
[Stabilitatea cardului] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[8] Caracteristicile cardului, 
[8.5] Stabilitatea dimensional ă a cardului și capacita- 
tea de deformare sub efectul temperaturii și al 
umidității ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 344  
Nr. Test  Descriere  Cerin țe asociate  
[Lumină] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[8] Caracteristicile cardului, 
[8.6] Lumin ă 
[Durabilitate] 
Anexa 1C capitolul 4.4, „Specifica ții de mediu și 
electrice”, punctul 241) 
Cardurile de tahograf trebuie s ă poată funcționa corect 
timp de cinci ani dac ă sunt folosite conform 
specificațiilor de mediu și electrice. 
[Rezistența stratului exterior] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[8] Caracteristicile cardului, 
[8.8] Rezisten ța stratului exterior 
[Aderență sau blocare] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[8] Caracteristicile cardului, 
[8.9] Aderen ță sau blocare 
[Capacitate de deformare] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[8] Caracteristicile cardului, 
[8.11] Capacitatea de deformare global ă a cardului 
[Rezistența la căldură] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[8] Caracteristicile cardului, 
[8.12] Rezisten ța la căldură ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 345  
Nr. Test  Descriere  Cerin țe asociate  
[Distorsiuni ale suprafe ței] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[8] Caracteristicile cardului, 
[8.13] Distorsiuni ale suprafe ței 
[Contaminare] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810, Identification cards – Physical char- 
acteristics, 
[8] Caracteristicile cardului, 
[8.14] Contaminarea și interacțiunea componentelor 
cardului  
2.3 Teste mecanice cu 
modulul cipului 
integrat  [Îndoire] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810:2003/Amd. 1:2009, Identification 
cards – Physical characteristics, Amendment 1: 
Criteria for cards containing integrated circuits 
[9.2] Tensiune de îndoire dinamic ă 
Numărul total de cicluri de îndoire: 4 000. 
[Torsiune] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards 
– Physical characteristics, Amendment 1: Criteria for 
cards containing integrated circuits 
[9.3] Tensiune de torsiune dinamic ă 
Numărul total de cicluri de torsiune: 4 000.  ISO/IEC 7810  
3 Modul  
3.1 Modul  Modulul este alc ătuit din capsula ermetic ă și plotul 
cipului. 
[Profil de suprafa ță] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7816-1:2011, Identification cards – Inte ­
grated circuit cards – Part 1: Cards with contacts – 
Physical characteristics 
[4.2] Profilul de suprafa ță al contactelor  ISO/IEC 7816  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 346  
Nr. Test  Descriere  Cerin țe asociate  
[Rezistență mecanică] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7816-1:2011, Identification cards – Inte ­
grated circuit cards – Part 1: Cards with contacts – 
Physical characteristics 
[4.3] Rezisten ță mecanică (a unui card și a contac ­
telor) 
[Rezistență electrică] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7816-1:2011, Identification cards – Inte- 
grated circuit cards – Part 1: Cards with contacts – 
Physical characteristics 
[4.4] Rezisten ță electrică (a contactelor) 
[Dimensiune] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7816-2:2007, Identification cards – Inte- 
grated circuit cards – Part 2: Cards with contacts – 
Dimension and location of the contacts 
[3] Dimensiunea contactelor 
[Locație] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7816-2:2007, Identification cards – Inte- 
grated circuit cards – Part 2: Cards with contacts – 
Dimension and location of the contacts 
[4] Numărul și locația contactelor 
În cazul modulelor cu șase contacte, contactele „C4” 
și „C8” nu fac obiectul acestei cerin țe de testare.  
4 Cip  
4.1 Cip  
[Temperatura de func ționare] 
Cipul cardului de tahograf func ționează în intervalul 
de temperatur ă ambiental ă dintre – 25 °C și + 85 °C.  241 – 244 
R10 al CEE 
ISO/IEC 7810 
ISO/IEC 10373  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 347  
Nr. Test  Descriere  Cerin țe asociate  
[Temperatur ă și umiditate] 
Anexa 1C capitolul 4.4, „Specifica ții de mediu și 
electrice”, punctul 241) 
Cardurile de tahograf trebuie s ă poată funcționa 
corect în toate condi țiile climatice întâlnite în mod 
normal pe teritoriul Uniunii și cel puțin în intervalul 
de temperatur ă cuprins între – 25 °C și + 70 °C, cu 
creșteri ocazionale ale temperaturii de pân ă la 
+ 85 °C; „ocazional” înseamn ă timp de cel mult 4 
ore o dată și de cel mult 100 de ori pe întreaga 
durată de viață a cardului. 
Cardurile de tahograf sunt expuse, în etape 
consecutive, la urm ătoarele temperaturi și niveluri 
de umiditate, pe durata indicat ă. După fiecare 
etapă, se testeaz ă funcționalitatea electric ă a 
cardurilor de tahograf. 
1. Temperatur ă de – 20 °C timp de 2 h. 
2. Temperatur ă de +/– 0 °C timp de 2 h. 
3. Temperatur ă de + 20 °C, umiditate relativ ă de 
50 %, timp de 2 h. 
4. Temperatur ă de + 50 °C, umiditate relativ ă de 
50 %, timp de 2 h. 
5. Temperatur ă de + 70 °C, umiditate relativ ă de 
50 %, timp de 2 h. 
Temperatura este m ărită intermitent la + 85 °C, 
umiditate relativ ă de 50 %, timp de 60 min. 
6. Temperatur ă de + 70 °C, umiditate relativ ă de 
85 %, timp de 2 h. 
Temperatura este m ărită intermitent la + 85 °C, 
umiditate relativ ă de 85 %, timp de 30 min. 
[Umiditate] 
Anexa 1C capitolul 4.4, „Specifica ții de mediu și 
electrice”, punctul 242) 
Cardurile de tahograf trebuie s ă poată funcționa corect 
în intervalul de umiditate cuprins între 10 % și 90 %. 
[Compatibilitate electromagnetic ă – CEM] 
Anexa 1C capitolul 4.4, „Specifica ții de mediu și 
electrice”, punctul 244) 
În cursul func ționării, cardurile de tahograf respect ă 
R10 al CEE, referitor la compatibilitatea electromag- 
netică. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 348  
Nr. Test  Descriere  Cerin țe asociate  
[Electricitate static ă] 
Anexa 1C capitolul 4.4, „Specifica ții de mediu și 
electrice”, punctul 244) 
În timpul func ționării, cardurile de tahograf sunt 
protejate împotriva desc ărcărilor electrostatice. 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards 
– Physical characteristics, Amendment 1: Criteria for 
cards containing integrated circuits 
[9.4] Electricitate static ă 
[9.4.1] Carduri IC cu contacte 
Tensiune de testare: 4 000 V. 
[raze X] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards 
– Physical characteristics, Amendment 1: Criteria for 
cards containing integrated circuits 
[9.1] Raze X 
[Lumină ultraviolet ă] 
ISO/IEC 10373-1:2006, Identification cards – Test 
methods – Part 1: General characteristics 
[5.11] Lumin ă ultraviolet ă 
[cu 3 roți] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 10373-1:2006/Amd. 1:2012, Identification 
cards – Test methods – Part 1: General characteristics, 
Amendment 1 
[5.22] Carduri IC – Rezisten ță mecanică: test cu 3 ro ți 
pentru carduri IC cu contacte 
[Învelișul] 
Cardurile de tahograf trebuie s ă respecte standardul 
MasterCard CQM V2.03:2013 
[11.1.3] R-L3-14-8: Testarea rezisten ței învelișului 
[13.2.1.32] TM-422: Fiabilitate mecanic ă: Test pri- 
vind ambalajul  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 349  
Nr. Test  Descriere  Cerin țe asociate  
4.2 Teste mecanice cu 
modulul cipului 
integrat în corpul 
cardului-> identic cu 
2.3 [Îndoire] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810:2003/Amd. 1:2009, Identification 
cards – Physical characteristics, Amendment 1: 
Criteria for cards containing integrated circuits 
[9.2] Tensiune de îndoire dinamic ă 
Numărul total de cicluri de îndoire: 4 000. 
[Torsiune] 
Cardurile de tahograf trebuie s ă respecte standardul 
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards 
– Physical characteristics, Amendment 1: Criteria for 
cards containing integrated circuits 
[9.3] Tensiune de torsiune dinamic ă 
Numărul total de cicluri de torsiune: 4 000.  ISO/IEC 7810  
5 Teste privind protocoalele  
5.1 ATR  Se verific ă dacă ATR este conform  ISO/IEC 7816-3 
TCS_14, TCS_17, 
TCS_18  
5.2 T = 0  Se verific ă dacă protocolul T = 0 este conform  ISO/IEC 7816-3 
TCS_11, TCS_12, 
TCS_13, TCS_15  
5.3 PTS  Se verific ă conformitatea comenzii PTS prin 
schimbarea protocolului T = 0 în T = 1  ISO/IEC 7816-3 
TCS_12, TCS_19, 
TCS_20, TCS_21  
5.4 T = 1  Se verific ă dacă protocolul T = 1 este conform  ISO/IEC 7816-3 
TCS_11, TCS_13, 
TCS_16  
6 Structura cardului  
6.1 Se testeaz ă conformitatea structurii de fi șiere a 
cardului, verificându-se prezen ța pe card a fi șierelor 
obligatorii și condițiile de acces ale acestora  TCS_22 – TCS_28 
TCS_140 – TCS_179  
7 Teste de func ționare  
7.1 Procesare normal ă Se testeaz ă cel puțin o dată fiecare utilizare permis ă a 
fiecărei comenzi (de ex.: se testeaz ă comanda 
UPDATE BINARY cu CLA = ‘00’, CLA = ‘0C’ și 
cu parametri P1, P2 și Lc diferi ți) 
Se verifică dacă operațiunile au fost efectiv efectuate 
pe card (de ex.: prin citirea fi șierului pe care s-a 
executat comanda)  TCS_29 – TCS_139  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 350  
Nr. Test  Descriere  Cerin țe asociate  
7.2 Mesaje de eroare  Se testeaz ă cel puțin o dată fiecare mesaj de eroare 
(conform apendicelui 2) pentru fiecare comand ă. 
Se testează cel puțin o dată fiecare eroare generic ă (cu 
excepția erorilor de integritate ‘ 6400 ’ verificate în 
cadrul certific ării de securitate)  
7.3 Suite cifru și parametri de domeniu standardiza ți CSM_48, CSM_50  
8 Personalizare  
8.1 Personalizare optic ă Anexa 1C capitolul 4.1 „Date vizibile”, punctul 
230) 
Pe recto figureaz ă: 
informații specifice pentru cardul emis. 
Anexa 1C capitolul 4.1 „Date vizibile”, punctul 231) 
Pe recto figureaz ă: 
datele în format „zz/ll/aaaa” sau „zz.ll.aaaa” (zi, lun ă, 
an). 
Anexa 1C capitolul 4.1 „Date vizibile”, punctul 235) 
Cardurile de tahograf trebuie s ă aibă cel puțin 
următoarele caracteristici pentru protec ția corpului 
cardului împotriva falsific ării și a manipul ării fraudu- 
loase: 
— în zona fotografiei, fondul de securitate și fotografia 
se suprapun.  230, 231, 235  
5. TESTE PRIVIND ECHIPAMENTUL GNSS EXTERN  
Nr. Test  Descriere  Cerin țe asociate  
1. Examinare administrativ ă 
1.1 Documenta ție Corectitudinea documenta ției 
2. Inspec ție vizuală a echipamentului GNSS extern  
2.1. Conformitatea cu documenta ția 
2.2. Identificare/inscrip ții 224 – 226  
2.3 Materiale  219 – 223  
3. Teste de func ționare  
3.1 Date de identificare a senzorului  98,99  
3.2 Cuplare între echipamentul GNSS extern și unitatea montat ă pe vehicul  123, 205  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 351  
Nr. Test  Descriere  Cerin țe asociate  
3.3 Poziție GNSS  36, 37  
3.4 Interfața unității montate pe vehicul atunci când receptorul GNSS este exterior 
unității montate pe vehicul  03 
3.5 Suite cifru și parametri de domeniu standardiza ți CSM_48, CSM_50  
4. Teste de mediu  
4.1 Temperatur ă Verificarea func ționalității prin: 
Test în conformitate cu ISO 16750-4, Chapter 5.1.1.2: Low 
temperature operation test (72 h @ – 20 °C) 
Acest test se refer ă la IEC 60068-2-1: Environmental testing 
– Part 2-1: Tests – Test A: Cold 
Test în conformitate cu ISO 16750-4: Chapter 5.1.2.2: High 
temperature operation test (72 h @ 70 °C) 
Acest test se refer ă la IEC 60068-2-2: Basic environmental 
testing procedures; part 2: tests; tests B: dry heat 
Test în conformitate cu ISO 16750-4: Chapter 5.3.2: Rapid 
change of temperature with specified transition duration 
(-20°C/70 °C, 20 cycles, dwell time 1h at each temperature) 
Un număr redus de teste (dintre cele definite în sec țiunea 3 
din prezentul tabel) pot fi efectuate la temperatura cea mai 
scăzută, la temperatura cea mai ridicat ă și pe parcursul 
ciclurilor de temperatur ă 213 
4.2 Umiditate  Se verific ă, prin intermediul testului Db, IEC 60068-2-30, 
dacă unitatea montat ă pe vehicul poate suporta un ciclu de 
căldură umedă (testul de c ăldură), prin șase cicluri de câte 
24 de ore fiecare, cu temperaturi variind între + 25 °C și 
+ 55 °C la o umiditate relativ ă de 97 % la + 25 °C și egală 
cu 93 % la + 55 °C  214 
4.3 Teste mecanice  1. Vibra ții sinusoidale. 
Se verific ă dacă unitatea montat ă pe vehicul poate 
suporta vibra ții sinusoidale cu urm ătoarele caracteristici: 
deplasare constant ă la frecven țe între 5 și 11 Hz: valoare 
maximă 10 mm 
accelerație constant ă între 11 și 300 Hz: 5 g 
Această cerință este verificat ă prin intermediul testului 
Fc, IEC 60068-2-6, cu o durat ă minimă a testului de 
3 × 12 ore (12 ore per ax ă) 
ISO 16750-3 nu prevede un test de vibra ții sinusoidale 
pentru dispozitivele situate în cabina decuplat ă a vehicu­
lului.  219 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 352  
Nr. Test  Descriere  Cerin țe asociate  
2. Vibrații aleatorii: 
Test în conformitate cu ISO 16750-3: Chapter 4.1.2.8: 
Testul VIII: Commercial vehicle, decoupled vehicle cab 
Test de vibra ții aleatorii, 10…2 000 Hz, RMS vertical 
21,3 m/s  2 , RMS longitudinal 11,8 m/s  2 , RMS lateral 
13,1 m/s  2 , 3 axe, 32 de ore per ax ă, inclusiv ciclul de 
temperatur ă – 20…70 °C. 
Acest test se refer ă la IEC 60068-2-64: Environmental 
testing – Part 2-64: Tests – Test Fh: Vibration, broadband 
random and guidance 
3. Șocuri: 
șoc mecanic semisinusoidal 3 g în conformitate cu ISO 
16750. 
Testele descrise anterior se efectueaz ă pe mostre diferite ale 
tipului de echipament testat.  
4.4 Protecție 
împotriva apei și 
corpurilor str ăine Test în conformitate cu ISO 20653: Road vehicles – Degree 
of protection (IP code) – Protection of electrical equipment 
against foreign objects, water and access (No change in 
parameters)  220, 221  
4.5 Protecție 
împotriva supra ­
tensiunii  Se verifică dacă unitatea montat ă pe vehicul poate suporta o 
sursă de alimentare de:  216 
Pentru versiunile de 24 V:  34 V la + 40 °C 1 or ă 
Pentru versiunile de 12 V:  17 V la + 40 °C 1 or ă 
( ISO 16750-2, capitolul 4.3)  
4.6 Protecție 
împotriva pola ­
rității inverse  Se verifică dacă unitatea montat ă pe vehicul poate suporta o 
inversare a polarit ății la sursa de alimentare 
( ISO 16750-2, capitolul 4.7)  216 
4.7 Protecție 
împotriva scur ­
tcircuitelor  Se verifică dacă semnalele de intrare/ie șire sunt protejate 
împotriva scurtcircuitelor la sursa de alimentare și la masă 
( ISO 16750-2, capitolul 4.10)  216 
5 Teste CEM  
5.1 Emisii de radia ții 
și susceptibilitate 
de radiații Conformitate cu Regulamentul R10 al CEE  218  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 353  
Nr. Test  Descriere  Cerin țe asociate  
5.2 Descărcări elec­
trostatice  Conformitate cu ISO 10605:2008 + Rectificare tehnic ă:2010 
+ AMD1:2014: +/– 4kV pentru contact și +/– 8kV pentru 
evacuarea aerului  218 
5.3 Susceptibilitate 
de conduc ție 
tranzitorie la 
sursa de 
alimentare  Pentru versiunile de 24 V: conformitate cu ISO 7637-2 + 
Regulamentul nr. 10 al CEE Rev. 3: 
puls 1a: Vs = – 450 V Ri = 50 ohmi 
puls 2a: Vs = + 37 V Ri = 2 ohmi 
puls 2b: Vs = + 20 V Ri = 0,05 ohmi 
puls 3a: Vs = – 150 V Ri = 50 ohmi 
puls 3b: Vs = + 150 V Ri = 50 ohmi 
puls 4: Vs = –16 V Va = –12 V t6 = 100ms 
puls 5: Vs = + 120 V Ri = 2,2 ohmi td = 250ms 
Pentru versiunile de 12 V: conformitate cu ISO 7637-1 + 
Regulamentul nr. 10 al CEE Rev. 3: 
puls 1: Vs = – 75 V Ri = 10 ohmi 
puls 2a: Vs = + 37 V Ri = 2 ohmi 
puls 2b: Vs = + 10 V Ri = 0,05 ohmi 
puls 3a: Vs = – 112 V Ri = 50 ohmi 
puls 3b: Vs = + 75 V Ri = 50 ohmi 
puls 4: Vs = – 6 V Va = – 5 V t6 = 15ms 
puls 5: Vs = + 65 V Ri = 3 ohmi td = 100ms 
Pulsul 5 se testeaz ă numai pentru unit ățile montate pe 
vehicule care sunt proiectate pentru a fi instalate în 
vehicule care nu dispun de o protec ție externă obișnuită 
împotriva întreruperii aliment ării 
Pentru propunerea privind întreruperea aliment ării, a se 
vedea ISO 16750-2, a 4-a edi ție, capitolul 4.6.4.  218 
▼M1 
6. TEST PRIVIND ECHIPAMENTUL EXTERN DE COMUNICARE LA 
DISTANȚĂ 
Nr. Test  Descriere  Cerin țe asociate  
1. Examinare administrativ ă 
1.1 Documenta ție Corectitudinea docu ­
mentației 
2. Inspec ție vizuală 
2.1. Conformitatea cu documenta ția 
2.2. Identificare/inscrip ții 225, 226  
2.3 Materiale  219-223  
3. Teste de func ționare  
3.1 Comunicarea la distan ță pentru controalele selective în trafic  4, 197-199  
3.2 Înregistrarea și stocarea în memoria de date  91  
3.3 Comunicarea cu unitatea montat ă pe vehicul  Apendicele 14 
DSC_66 - DSC_70, 
DSC_71 - DSC_76  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 354  
Nr. Test  Descriere  Cerin țe asociate  
4. Teste de mediu  
4.1 Temperatur ă Verificarea func ționalității prin: 
Test în conformitate cu ISO 16750-4, Chapter 5.1.1.2: 
Low temperature operation test (72 h @ – 20 °C) 
Acest test se refer ă la IEC 60068-2-1: Environmental 
testing – Part 2-1: Tests - Test A: Cold 
Test în conformitate cu ISO 16750-4: Chapter 5.1.2.2: 
High temperature operation test (72 h @ 70 °C) 
Acest test se refer ă la IEC 60068-2-2: Basic environ ­
mental testing procedures; part 2: tests; tests B: dry heat 
Test în conformitate cu ISO 16750-4: Chapter 5.3.2: 
Rapid change of temperature with specified transition 
duration (– 20°C/70 °C, 20 cycles, dwell time 1 h at 
each temperature) 
Un număr redus de teste (dintre cele definite în sec țiunea 
3 din prezentul tabel) pot fi efectuate la temperatura cea 
mai scăzută, la temperatura cea mai ridicat ă și pe 
parcursul ciclurilor de temperatur ă 213 
4.2 Protecție împotriva 
apei și corpurilor 
străine Test în conformitate cu ISO 20653: Road vehicles – 
Degree of protection (IP code) – Protection of electrical 
equipment against foreign objects, water and access 
(targeted value IP40)  220, 221  
5. Teste CEM  
5.1 Emisii de radia ții și 
susceptibilitate de 
radiații Conformitate cu Regulamentul R10 al CEE  218  
5.2 Descărcări electros ­
tatice  Conformitate cu ISO 10605:2008 + Rectificare tehnic ă: 
2010 + AMD1:2014: + /– 4kV pentru contact și + /– 
8kV pentru evacuarea aerului  218 
5.3 Susceptibilitate de 
conducție tranzitorie 
la sursa de 
alimentare  Pentru versiunile de 24 V: conformitate cu ISO 7637-2 
+ Regulamentul nr. 10 al CEE Rev. 3: 
puls 1a: Vs=– 450 V Ri=50 ohmi 
puls 2 a: Vs=+ 37 V Ri=2 ohmi 
puls 2b: Vs=+ 20 V Ri=0,05 ohmi 
puls 3 a: Vs=– 150 V Ri=50 ohmi 
puls 3b: Vs=+ 150 V Ri=50 ohmi 
puls 4: Vs=– 16V Va=– 12V t6=100 ms 
puls 5: Vs=+ 120 V Ri=2,2 ohmi td=250 ms 
Pentru versiunile de 12 V: conformitate cu ISO 7637-1 
+ Regulamentul nr. 10 al CEE Rev. 3: 
puls 1: Vs=– 75 V Ri=10 ohmi 
puls 2 a: Vs=+ 37 V Ri=2 ohmi 
puls 2b: Vs=+ 10 V Ri=0,05 ohmi 
puls 3 a: Vs=– 112 V Ri=50 ohmi  218 ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 355  
Nr. Test  Descriere  Cerin țe asociate  
puls 3b: Vs=+ 75 V Ri=50 ohmi 
puls 4: Vs=– 6 V Va=– 5 V t6=15 ms 
puls 5: Vs=+ 65 V Ri=3 ohmi td=100 ms 
Pulsul 5 se testeaz ă numai pentru unit ățile montate pe 
vehicule care sunt proiectate pentru a fi instalate în 
vehicule care nu dispun de o protec ție externă 
obișnuită împotriva întreruperii aliment ării 
Pentru propunerea privind întreruperea aliment ării, a se 
vedea ISO 16750-2, a 4-a edi ție, capitolul 4.6.4.  
▼B 
7. TESTE DE FUNC ȚIONARE PRIVIND HÂRTIA  
Nr. Test  Descriere  Cerin țe asociate  
1. Examinare administrativ ă 
1.1 Documenta ție Corectitudinea documenta ției 
2 Teste generale  
2.1 Număr de caractere 
pe fiecare rând  Inspecție vizuală a documentelor imprimate.  172  
2.2 Dimensiunea minim ă 
a caracterelor  Inspecție vizuală a documentului imprimat și verificarea 
caracterelor.  173 
2.3 Seturi de caractere 
compatibile  Imprimanta trebuie s ă fie compatibil ă cu caracterele 
specificate în apendicele 1 capitolul 4, „Seturi de carac ­
tere”.  174 
2.4 Definiția docu ­
mentelor imprimate  Verificarea omolog ării de tip a tahografului și inspecția 
vizuală a documentelor imprimate  174 
2.5 Lizibilitatea și identi­
ficarea documentelor 
imprimate  Inspectarea documentelor imprimate 
Demonstrate prin rapoarte de testare și protocoale de 
testare de c ătre producător. 
Toate numerele de omologare ale tahografelor cu care 
poate fi utilizat ă imprimanta sunt imprimate pe hârtie.  175, 177, 178  
2.6 Adăugarea de 
mențiuni scrise de 
mână Inspecție vizuală: Este disponibil un câmp pentru 
semnătura conduc ătorului auto. 
Sunt disponibile câmpuri pentru alte men țiuni scrise de 
mână. 180 
2.7 Detalii suplimentare 
privind fețele hârtiei.  Pe ambele fe țe ale hârtiei pot figura detalii și informații 
suplimentare. 
Aceste detalii și informații suplimentare nu trebuie s ă 
afecteze lizibilitatea documentelor imprimate. 
Inspecție vizuală. 177, 178  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 356  
Nr. Test  Descriere  Cerin țe asociate  
3 Teste privind stocarea  
3.1 Căldură uscată Condi ții prealabile: 16 ore la + 23 °C ± 2 °C/umiditate 
relativă de 55 % ±3 % 
Mediul de testare: 72 ore la + 70 °C ± 2 °C 
Recuperare: 16 ore la + 23 °C ± 2 °C/umiditate relativ ă 
de 55 % ± 3 %  176, 178 
IEC 60068-2-2-Bb  
2.2 Căldură umedă Condi ții prealabile: 16 ore la + 23 °C ± 2 °C/umiditate 
relativă de 55 % ± 3 % 
Mediul de testare: 144 ore la + 55 °C ± 2 °C și 
umiditate relativ ă de 93 % ± 3 % 
Recuperare: 16 ore la + 23 °C ± 2 °C/umiditate relativ ă 
de 55 % ± 3 %  176, 178 
IEC 60068-2-78-Cab  
4 Teste privind utilizarea hârtiei  
4.1 Rezisten ța la 
umiditate a 
fundalului (hârtie 
neimprimat ă) Condiții prealabile: 16 ore la + 23 °C ± 2 °C/umiditate 
relativă de 55 % ± 3 % 
Mediul de testare: 144 ore la + 55 °C ± 2 °C și 
umiditate relativ ă de 93 % ± 3 % 
Recuperare: 16 ore la + 23 °C ± 2 °C/umiditate relativ ă 
de 55 % ± 3 %  176, 178 
IEC 60068-2-78-Cab  
4.2 Capacitatea de 
imprimare  Condiții prealabile: 24 ore la + 40 °C ± 2 °C/umiditate 
relativă de 93 % ±3 % 
Mediul de testare: document imprimat la + 23 °C ± 2 °C 
Recuperare: 16 ore la + 23 °C ± 2 °C/umiditate relativ ă 
de 55 % ± 3 %  176, 178  
4.3 Rezisten ța la căldură Condiții prealabile: 16 ore la + 23 °C ± 2 °C/umiditate 
relativă de 55 % ± 3 % 
Mediul de testare: 2 ore la + 70 °C ± 2 °C, c ăldură 
uscată 
Recuperare: 16 ore la + 23 °C ± 2 °C/umiditate relativ ă 
de 55 % ± 3 %  176, 178 
IEC 60068-2-2-Bb  
4.4 Rezisten ța la tempe ­
ratură scăzută Condiții prealabile: 16 ore la + 23 °C ± 2 °C/umiditate 
relativă de 55 % ±3 % 
Mediul de testare: 24 de ore la -20 °C ± 3 °C, c ăldură 
umedă 
Recuperare: 16 ore la +23 °C ± 2 °C/umiditate relativ ă 
de 55 % ± 3 %  176, 178 
ISO 60068-2-1-Ab  
4.5 Rezisten ța la lumin ă Condiții prealabile: 16 ore la + 23 °C ± 2 °C/umiditate 
relativă de 55 % ± 3 % 
Mediu de testare: 100 ore, la o iluminare de 5 000 de 
lucși, la + 23 °C ± 2 °C/umiditate relativ ă de 55 % ± 
3 % 
Recuperare: 16 ore la + 23 °C ± 2 °C/umiditate relativ ă 
de 55 % ± 3 %  176, 178  
Criterii de lizibilitate pentru testele 3.x și 4.x:  
Lizibilitatea documentelor imprimate este asigurat ă dacă densitățile optice 
respectă următoarele limite:  
Caractere imprimate: min. 1,0  
Fundal (hârtie neimprimat ă): max. 0,2  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 357  
Densitățile optice ale documentelor imprimate rezultate se m ăsoară conform 
standardului DIN EN ISO 534.  
Documentele imprimate trebuie s ă nu prezinte modific ări ale dimensiunilor 
și să rămână perfect lizibile.  
8. TESTE DE INTEROPERABILITATE  
▼M1 
Nr. Test  Descriere  
8.1 Teste de interoperabilitate între unit ăți montate pe vehicule și carduri de tahograf  
1 Autentificare reciproc ă Se verific ă dacă autentificarea reciproc ă dintre unitatea montat ă pe 
vehicul și cardul de tahograf se produce normal  
2 Teste de scriere/citire  Se execut ă un scenariu tipic de activitate asupra unit ății montate pe 
vehicul. Scenariul trebuie adaptat tipului de card supus test ării și 
implică scrierea pe card într-un num ăr cât mai mare de fi șiere 
elementare. 
Se verifică, prin desc ărcarea datelor din unitatea montat ă pe vehicul, 
dacă toate înregistr ările corespunz ătoare au fost efectuate corect. 
Se verifică, prin desc ărcarea datelor de pe card, dac ă toate înregis ­
trările corespunz ătoare au fost efectuate corect. 
Se verifică, prin documente imprimate zilnice, dac ă toate înregis ­
trările corespunz ătoare pot fi citite în mod adecvat.  
8.2 Teste de interoperabilitate între unit ăți montate pe vehicule și senzori de mi șcare 
1 Asociere  Se verific ă dacă asocierea dintre unit ățile montate pe vehicule și 
senzorii de mi șcare se desf ășoară normal  
2 Teste privind activit ățile Se execut ă un scenariu tipic de activitate asupra senzorului de 
mișcare. Scenariul implic ă o activitate normal ă și crearea cât mai 
multor evenimente sau anomalii. 
Se verifică, prin desc ărcarea datelor din unitatea montat ă pe vehicul, 
dacă toate înregistr ările corespunz ătoare au fost efectuate corect. 
Se verifică, prin desc ărcarea datelor de pe card, dac ă toate înregis ­
trările corespunz ătoare au fost efectuate corect. 
Se verifică, printr-un document imprimat zilnic, dac ă toate înregis ­
trările corespunz ătoare pot fi citite în mod adecvat.  
8.3 Teste de interoperabilitate între unit ăți montate pe vehicule și echipamente GNSS externe (acolo unde este 
cazul)  
1 Autentificare reciproc ă Se verific ă dacă autentificarea reciproc ă (cuplarea) dintre unitatea 
montată pe vehicul și echipamentul GNSS extern se desf ășoară 
normal.  
2 Teste privind activit ățile Se execut ă un scenariu tipic de activitate asupra echipamentului 
GNSS extern. Scenariul implic ă o activitate normal ă și crearea cât 
mai multor evenimente sau anomalii. 
Se verifică, prin desc ărcarea datelor din unitatea montat ă pe vehicul, 
dacă toate înregistr ările corespunz ătoare au fost efectuate corect. 
Se verifică, prin desc ărcarea datelor de pe card, dac ă toate înregis ­
trările corespunz ătoare au fost efectuate corect. 
Se verifică, printr-un document imprimat zilnic, dac ă toate înregis ­
trările corespunz ătoare pot fi citite în mod adecvat.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 358  
Apendicele 10  
CERINȚE DE SECURITATE  
Prezentul apendice specific ă cerințele de securitate informatic ă pentru compo ­
nentele sistemului tahografic inteligent (tahograf de a doua genera ție). 
SEC_001 Urm ătoarele componente ale sistemului tahografic inteligent trebuie s ă 
fie certificate din punctul de vedere al securit ății în conformitate cu 
criteriile comune:  
— unitatea montat ă pe vehicul;  
— cardul de tahograf;  
— senzorul de mi șcare;  
— echipamentul GNSS extern.  
SEC_002 Cerin țele minime de securitate informatic ă pe care trebuie s ă le 
respecte fiecare component ă care trebuie s ă fie certificat ă din 
punctul de vedere al securit ății sunt definite într-un profil de 
protecție al componentei, în conformitate cu criteriile comune.  
SEC_003 Comisia European ă se asigură că patru profile de protec ție conforme 
cu prezenta anex ă sunt sponsorizate, dezvoltate, aprobate de orga ­
nismele guvernamentale de certificare în domeniul securit ății infor­
matice, create în cadrul Grupului de lucru mixt privind interpretarea 
(JIWG –  Joint Interpretation Working Group ), care sprijin ă recu­
noașterea reciproc ă a certificatelor în cadrul MRA (Acordul de recu ­
noaștere reciproc ă a certificatelor de evaluare a securit ății informatice) 
al grupului european SOGIS, și înregistrate:  
— profilul de protec ție pentru unitatea montat ă pe vehicul;  
— profilul de protec ție pentru cardul de tahograf;  
— profilul de protec ție pentru senzorul de mi șcare;  
— profilul de protec ție pentru echipamentul GNSS extern.  
Profilul de protec ție pentru unitatea montat ă pe vehicul trebuie s ă abordeze 
cazurile în care VU este proiectat ă pentru a fi sau nu utilizat ă cu un echipament 
GNSS extern. În primul caz, cerin țele de securitate aplicabile echipamentului 
GNSS extern sunt specificate în profilul de protec ție aferent.  
SEC_004 Produc ătorii componentelor amelioreaz ă și completeaz ă, după nece­
sități, profilul de protec ție corespunz ător al componentei, f ără a 
modifica sau a șterge amenin țările, obiectivele, mijloacele procedurale 
și specificațiile funcțiilor de asigurare a securit ății existente, pentru a 
crea un obiectiv de securitate în raport cu care s ă solicite certificarea 
de securitate a componentei respective.  
SEC_005 În cursul procesului de evaluare, trebuie declarat ă conformitatea 
strictă a acestui obiectiv de securitate specific cu profilul de 
protecție corespunz ător. 
SEC_006 Nivelul de siguran ță al fiecărui profil de protec ție trebuie s ă fie EAL4, 
amplificat de componentele de siguran ță ATE_DPT.2 și 
AVA_VAN.5.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 359  
Apendicele 11  
MECANISME DE SECURITATE COMUNE  
CUPRINS  
PREAMBUL  
PARTEA A SISTEMUL TAHOGRAFIC DE PRIMA GENERA ȚIE 
1. INTRODUCERE  
1.1. Referin țe 
1.2. Nota ții și termeni abrevia ți 
2. SISTEME ȘI ALGORITMI CRIPTOGRAFICI  
2.1. Sisteme criptografice  
2.2. Algoritmi criptografici  
2.2.1 Algoritmul RSA  
2.2.2 Algoritmul de hash  
2.2.3 Algoritmul de criptare a datelor  
3. CHEI ȘI CERTIFICATE  
3.1. Generarea și distribuirea cheilor  
3.1.1 Generarea și distribuirea cheilor RSA  
3.1.2 Chei de testare RSA  
3.1.3 Cheile senzorului de mi șcare 
3.1.4 Generarea și distribuția cheilor de sesiune T-DES  
3.2. Chei  
3.3. Certificate  
3.3.1 Con ținutul certificatelor  
3.3.2 Certificate emise  
3.3.3 Verificarea și deschiderea certificatelor  
4. MECANISMUL DE AUTENTIFICARE RECIPROC Ă 
5. CONFIDEN ȚIALITATEA, INTEGRITATEA ȘI MECANISMUL 
DE AUTENTIFICARE ALE TRANSFERULUI DE DATE 
DINTRE VU ȘI CARDURI  
5.1. Mesagerie securizat ă 
5.2. Tratarea erorilor mesageriei securizate  
5.3. Algoritmul de calcul al sumelor de verificare criptografice  
5.4. Algoritmul de calcul al criptogramelor pentru obiecte de date (DO) 
confidențiale 
6. MECANISMELE DE SEMNARE DIGITAL Ă A DATELOR 
DESCĂRCATE  
6.1. Generarea semn ăturilor  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 360  
6.2. Verificarea semn ăturilor  
PARTEA B SISTEMUL TAHOGRAFIC DE A DOUA GENERA ȚIE 
7. INTRODUCERE  
7.1. Referin țe 
7.2. Nota ții și abrevieri  
7.3. Defini ții 
8. SISTEME ȘI ALGORITMI CRIPTOGRAFICI  
8.1. Sisteme criptografice  
8.2. Algoritmi criptografici  
8.2.1 Algoritmi simetrici  
8.2.2 Algoritmi asimetrici și parametri de domeniu standardiza ți 
8.2.3 Algoritmi de hashing  
8.2.4 Suite cifru  
9. CHEI ȘI CERTIFICATE  
9.1. Perechi de chei asimetrice și certificate de cheie public ă 
9.1.1 Considera ții generale  
9.1.2 Nivelul european  
9.1.3 Nivelul statului membru  
9.1.4 Nivelul echipamentului: Unit ăți montate pe vehicule  
9.1.5 Nivelul echipamentului: Carduri de tahograf  
9.1.6 Nivelul echipamentului: Echipamente GNSS externe  
9.1.7 Prezentare general ă: Înlocuirea certificatelor  
9.2. Chei simetrice  
9.2.1 Chei pentru siguran ța comunica țiilor dintre VU și senzorul de 
mișcare 
9.2.2 Chei pentru securizarea comunica țiilor specializate cu raz ă scurtă 
de acțiune (DSRC)  
9.3. Certificate  
9.3.1 Considera ții generale  
9.3.2 Con ținutul certificatelor  
9.3.3 Solicitarea de certificate  
10. AUTENTIFICAREA RECIPROC Ă ȘI MESAGERIA SECU ­ 
RIZATĂ ÎNTRE VU ȘI CARDURI  
10.1. Considera ții generale  
10.2. Verificarea reciproc ă a lanțului de certificate  
10.2.1 Verificarea lan țului de certificate de c ătre VU  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 361  
10.2.2 Verificarea lan țului de certificate ale VU de c ătre card  
10.3. Autentificarea VU  
10.4. Autentificarea cipului și înțelegerea asupra cheilor de sesiune  
10.5. Mesagerie securizat ă 
10.5.1 Considera ții generale  
10.5.2 Structura mesageriei securizate  
10.5.3 Abandonarea sesiunii de mesagerie securizat ă 
11. CUPLAREA, AUTENTIFICAREA RECIPROC Ă ȘI MESAGERIA 
SECURIZAT Ă ÎNTRE VU ȘI ECHIPAMENTUL GNSS EXTERN  
11.1. Considera ții generale  
11.2. Cuplarea dintre VU și echipamentul GNSS extern  
11.3. Verificarea reciproc ă a lanțului de certificate  
11.3.1 Considera ții generale  
11.3.2 În timpul cupl ării VU – EGF  
11.3.3 În timpul func ționării normale  
11.4. Autentificarea VU, autentificarea cipului și înțelegerea asupra 
cheilor de sesiune  
11.5. Mesageria securizat ă 
12. ASOCIEREA ȘI COMUNICAREA DINTRE O VU ȘI UN 
SENZOR DE MI ȘCARE  
12.1. Considera ții generale  
12.2. Asocierea VU – senzor de mi șcare folosind genera ții diferite de 
chei 
12.3. Comunicarea și asocierea dintre o VU și un senzor de mi șcare 
folosind AES  
12.4. Asocierea VU – senzor de mi șcare pentru echipamente de diferite 
generații 
13. SECURITATEA COMUNIC ĂRII LA DISTAN ȚĂ PRIN DSRC  
13.1. Considera ții generale  
13.2. Criptarea datelor utile ale tahografului și generarea MAC  
13.3. Verificarea și decriptarea datelor utile ale tahografului  
14. SEMNAREA DESC ĂRCĂRII DE DATE ȘI VERIFICAREA 
SEMNĂTURILOR  
14.1. Considera ții generale  
14.2. Generarea semn ăturilor  
14.3. Verificarea semn ăturilor  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 362  
PREAMBUL  
Prezentul apendice precizeaz ă mecanismele de securitate care asigur ă 
— autentificarea reciproc ă între diferitele componente ale sistemului tahografic,  
— confiden țialitatea, integritatea, autenticitatea și/sau evitarea respingerii datelor 
transferate între diferitele componente ale sistemului tahografic sau desc ărcate 
pe suporturi de stocare externe.  
Prezentul apendice cuprinde dou ă părți. Partea A define ște mecanismele de secu ­
ritate pentru sistemul tahografic de prima genera ție (tahograful digital). Partea B 
definește mecanismele de securitate pentru sistemul tahografic de a doua 
generație (tahograful inteligent).  
Mecanismele men ționate în partea A din prezentul apendice se aplic ă în cazul în 
care cel pu țin una dintre componentele sistemului tahografic implicate într-un 
proces de autentificare reciproc ă și/sau de transfer de date este de prima gene ­
rație. 
Mecanismele men ționate în partea B din prezentul apendice se aplic ă în cazul în 
care ambele componente ale sistemului tahografic implicate într-un proces de 
autentificare reciproc ă și/sau de transfer de date sunt de a doua genera ție. 
Apendicele 15 ofer ă mai multe informa ții privind utilizarea componentelor de 
prima genera ție în combina ție cu componente de a doua genera ție. 
PARTEA A  
SISTEMUL TAHOGRAFIC DE PRIMA GENERA ȚIE 
1. INTRODUCERE  
1.1. Referin țe 
În prezentul apendice se face trimitere la urm ătoarele standarde:  
SHA-1  National Institute of Standards and Technology  
(NIST).  Publication  FIPS 180-1:  Secure Hash 
Standard.  Aprilie 1995.  
PKCS1  RSA Laboratories . PKCS # 1:  RSA Encryption 
Standard  Versiunea 2.0. Octombrie 1998  
TDES  National Institute of Standards and Technology  
(NIST).  FIPS Publication 46-3: Data Encryption 
Standard  Proiect 1999.  
TDES-OP ANSI X9.52,  Triple Data Encryption Algorithm 
Modes of Operation  1998.  
ISO/IEC 7816-4  Information Technology – Identification cards – Inte ­
grated circuit(s) cards with contacts – Part 4: Inte ­
rindustry commands for interexchange.  Prima edi ție: 
1995 + Amendamentul 1: 1997.  
ISO/IEC 7816-6  Information Technology – Identification cards – Inte ­
grated circuit(s) cards with contacts – Part 6: Inte ­
rindustry data elements.  Prima edi ție: 1996 + Cor 1: 
1998.  
ISO/IEC 7816-8  Information Technology – Identification cards – Inte ­
grated circuit(s) cards with contacts – Part 8: Security 
related interindustry commands.  Prima edi ție 1999.  
ISO/IEC 9796-2  Information Technology – Security techniques – 
Digital signature schemes giving message recovery – 
Part 2: Mechanisms using a hash function.  Prima 
ediție: 1997.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 363  
ISO/IEC 9798-3  Information Technology – Security techniques – Entity 
authentication mechanisms – Part 3: Entity authenti ­
cation using a public key algorithm.  Ediția a doua 
1998.  
ISO 16844-3 Road vehicles – Tachograph systems – Part 3: Motion 
sensor interface.  
1.2. Nota ții și termeni abrevia ți 
În prezentul apendice sunt folosite urm ătoarele nota ții și termeni abre ­
viați: 
(K a , K  b , K  c ) un grup de chei utilizat de algoritmul de criptare tripl ă 
a datelor,  
CA autoritate de certificare,  
CAR identificator al autorit ății de certificare,  
CC sum ă de verificare criptografic ă, 
CG criptogram ă, 
CH antet de comand ă, 
CHA autoriza ția deținătorului certificatului,  
CHR identificator al de ținătorului certificatului,  
D() decriptare cu DES  (Data Encryption Standard),  
DE element de date,  
DO obiect de date,  
d cheie privat ă RSA, exponent privat,  
e cheie public ă RSA, exponent public,  
E() criptare cu DES,  
EQT echipament,  
Hash()  valoare  hash , un rezultat al func ției hash,  
Hash  func ție hash , 
KID identificator de cheie,  
Km cheie TDES. Cheie master definit ă în ISO 16844-3.  
Km  VU cheie TDES introdus ă în unitățile montate pe vehicule,  
Km  WC cheie TDES introdus ă în cardurile de atelier.  
m reprezentant de mesaj, num ăr întreg cuprins între 0 și 
n-1, 
n chei RSA, modul,  
PB octe ți de completare,  
PI Octet indicator de completare (utilizat în criptograme 
pentru confiden țialitatea DO),  
PV Valoare a datelor în clar,  
s reprezentant de semn ătură, număr întreg cuprins între 
0 și n-1, 
SSC Contor de secven țe trimise,  
SM Mesagerie securizat ă, 
TCBC Mod de func ționare prin înl ănțuirea blocurilor cifrate 
TDEA,  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 364  
TDEA Algoritm de criptare tripl ă a datelor,  
TLV Valoarea unei lungimi de etichet ă, 
VU Unitate montat ă pe vehicul,  
X.C Certificatul utilizatorului X emis de o autoritate de 
certificare,  
X.CA o autoritate de certificare a utilizatorului X,  
X.CA.PK  o X.C Opera ția de dezv ăluire a unui certificat pentru a 
extrage o cheie public ă. Este un operator infix, al 
cărui operand stâng este cheia public ă a unei autorit ăți 
de certificare, iar operandul drept este certificatul emis 
de acea autoritate de certificare. Rezultatul este cheia 
publică a utilizatorului X al c ărui certificat este 
operandul drept,  
X.PK Cheia privat ă RSA a utilizatorului X,  
X.PK[I] Cifrarea RSA a unor informa ții I, folosind cheia 
publică a utilizatorului X  
X.SK Cheia privat ă RSA a utilizatorului X,  
X.SK[I] Cifrarea RSA a unor informa ții I, folosind cheia 
privată a utilizatorului X,  
‘xx’ o valoare hexazecimal ă, 
|| Operatorul de concatenare.  
2. SISTEME ȘI ALGORITMI CRIPTOGRAFICI  
2.1. Sisteme criptografice  
CSM_001 Unit ățile montate pe vehicule și cardurile de tahograf 
utilizează un sistem criptografic cu cheie public ă RSA 
clasic pentru a oferi urm ătoarele mecanisme de securitate:  
— autentificarea între unit ățile montate pe vehicule și 
carduri,  
— transportul cheilor de sesiune de tip DES triplu între 
unitățile montate pe vehicule și cardurile de tahograf,  
— semnătura digital ă a datelor desc ărcate din unit ățile 
montate pe vehicule și din cardurile de tahograf pe 
suporturi externe.  
CSM_002 Unit ățile montate pe vehicule și cardurile de tahograf 
utilizează un sistem criptografic simetric DES triplu în 
scopul de a asigura un mecanism pentru integritatea datelor 
în timpul schimburilor de date privind utilizatorul dintre 
unitățile montate pe vehicule și cardurile de tahograf și 
pentru a garanta, unde este cazul, confiden țialitatea schim ­
burilor de date dintre unit ățile montate pe vehicule și 
cardurile de tahograf.  
2.2. Algoritmi criptografici  
2.2.1  Algoritmul RSA  
CSM_003 Algoritmul RSA este definit în întregime de urm ătoarele 
relații: ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 365  
X.SK[ m] = s = m d mod n 
X.PK[ s] = m = s e mod n 
O descriere mai complet ă a funcției RSA poate fi g ăsită în 
referința [PKCS1]. Exponentul public, e, pentru calculul 
funcției RSA este un num ăr întreg cuprins între 3 și n-1 
care satisface gcd[e, lcm(p-1, q-1)] = 1.  
2.2.2  Algoritmul de hash  
CSM_004 Mecanismele de semn ătură digitală utilizează algoritmul de  
hash  SHA-1 astfel cum este definit în referin ța [SHA-1].  
2.2.3  Algoritmul de criptare a datelor  
CSM_005 Algoritmii baza ți pe DES sunt utiliza ți în modul de 
funcționare prin înl ănțuirea blocurilor cifrate.  
3. CHEI ȘI CERTIFICATE  
3.1. Generarea și distribuirea cheilor  
3.1.1  Generarea și distribuirea cheilor RSA  
CSM_006 Cheile RSA sunt generate prin trei niveluri ierarhice 
funcționale:  
— nivelul european,  
— nivelul statului membru,  
— nivelul echipamentului.  
CSM_007 La nivelul european se genereaz ă o pereche unic ă de chei 
europene (EUR.SK și EUR.PK). Cheia privat ă europeană se 
utilizează pentru certificarea cheilor publice ale statelor 
membre. Se ține eviden ța tuturor cheilor certificate. Aceste 
sarcini sunt îndeplinite de o autoritate de certificare euro ­
peană, sub autoritatea și responsabilitatea Comisiei Europene.  
CSM_008 La nivelul statului membru se genereaz ă o pereche de chei 
ale statului membru (MS.SK și MS.PK). Cheile publice ale 
statelor membre sunt certificate de autoritatea de certificare 
europeană. Cheile private ale statelor membre se utilizeaz ă 
pentru certificarea cheilor publice care se introduc în echi ­
pament (unitatea montat ă pe vehicul sau cardul de tahograf). 
Se ține eviden ța tuturor cheilor publice certificate, împreun ă 
cu datele de identificare a echipamentului c ăruia îi sunt 
destinate. Aceste sarcini sunt îndeplinite de autoritatea de 
certificare a unui stat membru. Un stat membru î și poate 
schimba periodic perechea de chei.  
CSM_009 La nivelul echipamentului se genereaz ă o singură pereche de 
chei (EQT.SK și EQT.PK), care se introduce în fiecare echi ­
pament. Cheile publice ale echipamentelor sunt certificate de 
autoritatea de certificare a unui stat membru. Aceste sarcini 
pot fi îndeplinite de produc ătorii de echipamente, de 
serviciile de personalizare a echipamentelor sau de autori ­
tățile statelor membre. Aceast ă pereche de chei se folose ște 
pentru serviciile de autentificare, de semn ătură digitală și de 
cifrare.  
CSM_010 Confiden țialitatea cheilor private trebuie men ținută în timpul 
generării, transportului (dac ă este cazul) și stocării. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 366  
Ilustrația următoare sintetizeaz ă fluxul de date al acestui 
proces:
  
3.1.2  Chei de testare RSA  
CSM_011 Pentru testarea echipamentelor (inclusiv pentru testele de 
interoperabilitate), autoritatea de certificare european ă 
generează o pereche unic ă diferită de chei de testare 
europene și cel puțin două perechi de chei de testare ale 
statului membru, ale c ărui chei publice sunt certificate cu 
cheia de testare privat ă europeană. Producătorii introduc, în 
echipamentele supuse testelor pentru omologarea de tip, chei 
de testare certificate cu una dintre aceste chei de testare ale 
statului membru.  
3.1.3  Cheile senzorului de mi șcare 
Confidențialitatea celor trei chei TDES descrise mai jos trebuie asigurat ă 
în mod corespunz ător în timpul gener ării, transportului (dac ă este cazul) 
și stocării. 
În scopul de a asigura compatibilitatea componentelor tahografului cu 
ISO 16844, autoritatea de certificare european ă și autoritățile de certi ­
ficare din statele membre asigur ă, în plus, urm ătoarele:  
CSM_036 Autoritatea de certificare european ă generează KmVU și 
KmWC, dou ă chei DES triple independente și unice, 
și genereaz ă Km ca fiind:  Km = Km  VU XOR Km  WC . 
Autoritatea de certificare european ă transmite aceste chei, 
prin proceduri securizate corespunz ător, autorit ăților de certi ­
ficare ale statelor membre, la cererea acestora.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 367  
CSM_037 Autorit ățile de certificare ale statelor membre:  
— folosesc Km pentru a cripta datele de la senzorul de 
mișcare solicitate de produc ătorii de senzori de mi șcare 
(datele care trebuie criptate cu Km sunt definite în ISO 
16844-3),  
— transmit Km  VU producătorilor de unit ăți montate pe 
vehicule, prin proceduri securizate corespunz ător, pentru 
a fi introdus ă în unitățile montate pe vehicule,  
— se asigur ă că Km  WC va fi introdus ă în toate cardurile de 
atelier (
  din fi șierul 
elementar
  ) în timpul 
personalizării cardului.  
3.1.4  Generarea și distribu ția cheilor de sesiune T-DES  
CSM_012 Unit ățile montate pe vehicule și cardurile de tahograf 
generează și își transmit reciproc datele necesare pentru 
elaborarea unei chei de sesiune comune de tip DES triplu, 
ca parte a procesului de autentificare reciproc ă. 
Confidențialitatea acestui schimb de date trebuie s ă fie 
protejată printr-un mecanism de criptare RSA.  
CSM_013 Aceast ă cheie se utilizeaz ă pentru toate opera țiunile cripto ­
grafice ulterioare folosind mesageria securizat ă. Valabilitatea 
ei expiră la terminarea sesiunii (retragerea cardului sau 
reinițializarea cardului) și/sau după 240 de utiliz ări (o 
utilizare a cheii = o comand ă trimisă cardului folosind 
mesageria securizat ă și răspunsul asociat).  
3.2. Chei  
CSM_014 Cheile RSA au urm ătoarele lungimi (indiferent de nivel): 
modul  n 1 024 de bi ți, exponentul public  e maxim 64 de 
biți, exponentul privat  d 1 024 de bi ți. 
CSM_015 Cheile de tip DES triplu au forma (K  a , K  b , K  a ), unde K  a și 
K b sunt chei independente cu o lungime de 64 de bi ți. Nu se 
configureaz ă niciun bit pentru detectarea erorilor de paritate.  
3.3. Certificate  
CSM_016 Certificatele cheilor publice RSA sunt certificate de tip „non 
self-descriptive” (nu se pot autodescrie) și „Card Verifiable” 
(verificabile cu ajutorul cardului) (ref.: ISO/IEC 7816-8)  
3.3.1  Conținutul certificatelor  
CSM_017 Certificatele cheilor publice RSA sunt alc ătuite din urm ă­
toarele date, în ordinea indicat ă: 
Date  Format  Octe ți Observa ții 
CPI ÎNTREG  1  Identificator de profil al 
certificatului (‘01’ pentru 
prezenta versiune)  
CAR  ȘIR DE OCTE ȚI 8  Identificatorul autorit ății de 
certificare  
CHA  ȘIR DE OCTE ȚI 7  Autoriza ția deținătorului 
certificatului  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 368  
Date  Format  Octe ți Observa ții 
EOV  TimeReal  4  Data expir ării valabilit ății 
certificatului. Op țional, 
completat cu ‘FF’ dac ă nu 
este folosit  
CHR  ȘIR DE OCTE ȚI 8  Identificatorul de ținătorului 
certificatului  
n ȘIR DE OCTE ȚI 128  Cheie public ă (modul)  
e ȘIR DE OCTE ȚI 8  Cheie public ă (exponent 
public)  
164 
Note:  
1. „Identificatorul de profil al certificatului” (CPI) determin ă structura 
precisă a unui certificat de autentificare. El poate fi folosit ca identi ­
ficator intern al echipamentului pentru o list ă antet relevant ă care 
descrie concatenarea elementelor de date în cadrul certificatului.  
Lista antet asociat ă cu acest con ținut al certificatului este urm ătoarea: 
‘4D’  ‘16’  ‘5F 
29’ ‘01’ ‘42’  ‘08’  ‘5F 
4B’ ‘07’ ‘5F 
24’ ‘04’ ‘5F 
20’ ‘08’ ‘7F 
49’ ‘05’ ‘81’  ‘81 
80’ ‘82’ ‘08’
 Eticheta listei antet extinse  
Lungimea listei antet  
Eticheta CPI  
Lungimea CPI  
Eticheta CAR  
Lungimea CAR  
Eticheta CAR  
Lungimea CHA  
Eticheta CAR  
Lungimea EOV  
Eticheta CHR  
Lungimea CHR  
Etichetă cheie public ă (construită) 
Lungimea DO-urilor ulterioare  
Etichetă modul  
Lungime modul  
Etichetă exponent public  
Lungime exponent public 
2. „Identificatorul autorit ății de certificare” (CAR) are scopul de a iden ­
tifica autoritatea de certificare care a emis certificatul, astfel încât 
elementul de date s ă poată fi folosit în acela și timp și ca un identi ­
ficator al cheii de autoritate pentru a face trimitere la cheia public ă a 
autorității de certificare (pentru codificare, a se vedea mai jos identi ­
ficatorul de cheie).  
3. „Autoriza ția deținătorului certificatului” (CHA) este folosit ă pentru a 
identifica drepturile de ținătorului certificatului. Aceasta se compune 
din ID-ul aplica ției tahografice și din tipul de echipament c ăruia îi 
este destinat certificatul (în conformitate cu elementul de date
  
, ‘00’ pentru un stat membru).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 369  
4. „Identificatorul de ținătorului certificatului” (CHR) are scopul de a 
identifica în mod unic de ținătorul certificatului, astfel încât 
elementul de date s ă poată fi folosit în acela și timp ca identificator 
al cheii subiect pentru a face trimitere la cheia public ă a deținătorului 
certificatului.  
5. Identificatoarele cheii identific ă în mod unic de ținătorul certificatului 
sau autorit ățile de certificare. Acestea sunt codificate dup ă cum 
urmează: 
5.1. Echipament (VU sau card): 
Date  Num ărul 
de serie al 
echipa­
mentului  Data  Tip  Produc ător 
Lungime  4 octeți 2 octe ți 1 octet  1 octet  
Valoare  Întreg  ll aa codare BCD  Specific produ ­
cătorului  Codul produc ă­
torului  
În cazul unei unit ăți montate pe vehicul, atunci când produc ătorul 
solicită certificate, el poate sau nu s ă cunoască identificatorul 
echipamentului în care vor fi introduse cheile.  
În primul caz, produc ătorul trimite identificatorul echipamentului 
împreună cu cheia public ă la autoritatea statului membru 
respectiv pentru certificare. Certificatul va con ține în acest caz 
identificatorul echipamentului, iar produc ătorul trebuie s ă se 
asigure că cheile și certificatele sunt introduse în echipamentele 
prevăzute. Identificatorul cheii are forma indicat ă mai sus.  
În al doilea caz, produc ătorul trebuie s ă identifice în mod unic 
fiecare cerere de certificat și să trimită acest identificator 
împreună cu cheia public ă la autoritatea statului membru 
respectiv pentru certificare. Certificatul con ține identificatorul 
cererii. Produc ătorul trebuie s ă informeze autoritatea statului 
său membru cu privire la atribuirea cheii pentru echipament ( și 
anume, identificatorul cererii de certificat, identificatorul echipa ­
mentului) dup ă instalarea cheii în echipament. Identificatorul 
cheii are forma urm ătoare: 
Date  Num ărul 
de serie al 
cererii de 
certificat  Data  Tip  Produc ător 
Lungime  4 octeți 2 octe ți 1 octet  1 octet  
Valoare  Întreg  ll aa codare BCD  ‘FF’  Codul produc ă­
torului  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 370  
5.2. Autoritatea de certificare: 
Date  Identificatorul 
autorității Numărul de 
serie al cheii  Informații 
suplimentare  Identificator  
Lungime  4 octeți 1 octet  2 octe ți 1 octet  
Valoare  Codul numeric 
național 1 octet 
Codul alfanumeric 
național 3 octe ți Întreg  codificare 
suplimentar ă 
(specific CA) 
‘FF FF’ dac ă 
nu este folosit  ‘01’ 
Numărul de serie al cheii este folosit pentru a distinge cheile 
diferite ale unui stat membru, în cazul în care cheia este 
schimbată. 
6. Verificatorii certificatelor știu implicit c ă cheia public ă certificată este 
o cheie RSA relevant ă pentru autentificare, pentru verificarea 
semnăturii digitale și pentru cifrarea în scopul serviciilor de 
confidențialitate (certificatul nu con ține niciun identificator de obiect 
care să specifice acest lucru).  
3.3.2  Certificate emise  
CSM_018 Certificatul emis este o semn ătură digitală cu recuperarea 
parțială a conținutului certificatului în conformitate cu 
ISO/IEC 9796-2 (cu excep ția anexei A4 a acestuia), cu 
„identificatorul autorit ății de certificare” ad ăugat.  
X.C = X.CA.SK[‘6A’ || C  r || Hash (Cc) || ‘BC’] || C  n || X.CAR 
Cu conținutul certificatului = 
Cc =  C r || C  n 
106 octeți 58 de octe ți 
Note:  
1. Acest certificat are o lungime de 194 de octe ți. 
2. CAR, fiind ascuns de semn ătură, este în acela și timp ad ăugat la 
semnătură, astfel încât cheia public ă a autorității de certificare s ă 
poată fi selectat ă pentru verificarea certificatului.  
3. Verificatorul certificatului cunoa ște implicit algoritmul folosit de auto ­
ritatea de certificare pentru semnarea certificatului.  
4. Lista antet asociat ă cu acest certificat emis este urm ătoarea: 
‘7F 21’  ‘09’  ‘5F 37’  ‘81 80’  ‘5F 38’  ‘3A’  ‘42’  ‘08’
 Eticheta certificatului CV (construit ă) 
Lungimea DO-urilor ulterioare  
Eticheta semn ăturii 
Lungimea semn ăturii 
Eticheta restului  
Lungimea restului  
Eticheta CAR  
Lungimea CAR ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 371  
3.3.3  Verificarea și deschiderea certificatelor  
Verificarea și deschiderea certificatelor const ă în verificarea semn ăturii în 
conformitate cu ISO/IEC 9796-2, extr ăgând conținutul certificatului și 
cheia public ă conținută: X.PK = X.CA.PK  o X.C și în verificarea vala ­
bilității certificatului.  
CSM_019 Aceasta implic ă următoarele etape:  
Verificarea semn ăturii și extragerea con ținutului: 
— din X.C se extrage semn ătura, C  n ' și CAR':  X.C =  Semnare  ||  C  n ' ||  CAR'  
128 de octe ți 58 de octe ți 8 octeți 
— din CAR' se selecteaz ă cheia public ă a autorității de certi­
ficare corespunz ătoare (dac ă nu s-a selec ționat anterior 
prin alte metode)  
— se deschide semn ătura cu cheia public ă a CA: Sr'= 
X.CA.PK [Sign],  
— se verific ă dacă Sr' începe cu ‘6A’ și se termin ă cu ‘BC’ 
— se calculeaz ă C r ' și H' cu formula: Sr' =  ‘6 A’  || C  r ' ||  H'  ||  ‘BC’  
106 octeți 20 de octe ți 
— se recupereaz ă conținutul certificatului C' = C  r ' || C  n ', 
— se verific ă faptul că Hash (C') = H'  
Dacă verificările sunt în regul ă, certificatul este original, 
având con ținutul C'.  
Se verifică valabilitatea. Din C':  
— dacă este cazul, se verific ă data de expirare a valabilit ății 
Se extrage și se stocheaz ă cheia public ă, identificatorul cheii, 
autorizația deținătorului certificatului și data de expirare a 
valabilității din C':  
— X.PK =  n || e 
— X.KID = CHR  
— X.CHA = CHA  
— X.EOV = EOV  
4. MECANISMUL DE AUTENTIFICARE RECIPROC Ă 
Autentificarea reciproc ă între carduri și VU se bazeaz ă pe principiul 
următor: 
Fiecare parte îi demonstreaz ă celeilalte c ă deține o pereche valabil ă de 
chei, a cărei cheie public ă a fost certificat ă de autoritatea de certificare a 
unui stat membru, care la rândul ei a fost certificat ă de autoritatea de 
certificare european ă. 
Demonstra ția se face prin semnarea cu cheia privat ă a unui num ăr 
aleatoriu trimis de cealalt ă parte, care trebuie s ă recupereze num ărul 
aleatoriu trimis în momentul verific ării acestei semn ături. 
Mecanismul este declan șat de către VU la introducerea cardului. Acesta 
începe cu schimbul de certificate și deschiderea cheilor publice și se 
termină cu stabilirea unei chei de sesiune.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 372  
CSM_020 Trebuie utilizat urm ătorul protocol [s ăgețile indică comenzile 
și datele schimbate (a se vedea apendicele 2)]:
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 373
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 374  
5. CONFIDEN ȚIALITATEA, INTEGRITATEA ȘI MECANISMUL DE 
AUTENTIFICARE ALE TRANSFERULUI DE DATE DINTRE VU 
ȘI CARDURI  
5.1. Mesagerie securizat ă 
CSM_021 Integritatea transferurilor de date dintre VU și carduri trebuie 
protejată printr-o mesagerie securizat ă în conformitate cu 
referințele (ISO/IEC 7816-4) și (ISO/IEC 7816-8).  
CSM_022 Atunci când datele trebuie s ă fie protejate în timpul trans ­
ferului, se adaug ă un obiect de date de tip sum ă de verificare 
criptografic ă la obiectele de date trimise în cadrul comenzii 
sau al răspunsului. Suma de verificare criptografic ă este veri­
ficată de receptor.  
CSM_023 Suma de verificare criptografic ă a datelor trimise în cadrul 
unei comenzi integreaz ă antetul comenzii și toate obiectele de 
date trimise (=>CLA = ‘0C’, iar toate obiectele de date sunt 
încapsulate cu etichete în care b1 = 1).  
CSM_024 Octe ții de stare-informa ții transmiși ca răspuns sunt proteja ți 
printr-o sum ă de verificare criptografic ă atunci când 
răspunsul nu con ține niciun câmp de date.  
CSM_025 Sumele de verificare criptografice au o lungime de 4 octe ți. 
Structura comenzilor și răspunsurilor când se utilizeaz ă 
mesageria securizat ă este următoarea:  
Obiectele de date utilizate sunt un set par țial din obiectele de 
date de mesagerie securizat ă descrise în ISO/IEC 7816-4:  
Etichetă Cod 
mnemonic  Sens 
‘81’ T  PV Valoare a datelor în clar necodat ă prin BER-TLV (a 
se proteja prin CC)  
‘97’ T  LE Valoarea Le din comanda nesecurizat ă (a se proteja 
prin CC)  
‘99’ T  SW Informații de stare (a se proteja prin CC)  
‘8E’ T  CC Sumă de verificare criptografic ă 
‘87’ T  PI CG  Octet indicator de completare || Criptogram ă (valoare 
a datelor în clar necodat ă prin BER-TLV)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 375  
Fiind dată o pereche comand ă-răspuns nesecurizat ă: 
Antet de comand ă Corpul comenzii  
CLA  INS  P1  P2  [Câmp L  c ] [Câmp de date]  [Câmp L  e ] 
patru octeți L octe ți, indicați cu identificatori de la B  1 la B  L 
Corpul răspunsului  Coada r ăspunsului  
[Câmp de date]  SW1  SW2  
Octeți de date L  r doi octeți 
Perechea corespunz ătoare comand ă-răspuns securizat ă este:  
Comanda securizat ă: 
Antetul comenzii (CH)  Corpul comenzii  
CLA  INS  P1  P2  [Câmp nou L  c ] [Câmp de date nou]  [Câmp 
nou L  e ] 
‘OC’  Lungimea Câmp 
de date nou  T PV L PV PV T  LE L LE L e T CC L CC CC ‘00’  
‘81’ L  c Câmp de date  ‘97’  ‘01’  L  e ‘8E’ ‘04’  CC  
Datele care trebuie integrate în suma de verificare = CH || PB || 
T PV || L PV || PV || T  LE || L LE || L e || PB  
PB = Octe ți de completare (80 .. 00) în conformitate cu ISO- 
IEC 7816-4 și cu ISO 9797 metoda 2.  
Obiectele de date PV și LE sunt prezente numai dac ă există 
anumite date corespondente în comanda nesecurizat ă. 
Răspunsul securizat:  
1. Cazul în care câmpul de date r ăspuns nu este gol și nu 
este nevoie s ă fie protejat pentru confiden țialitate:  
Corpul răspunsului  Coada r ăspunsului  
[Câmp de date nou]  SW1 SW2 noi  
T PV L PV PV T  CC L CC CC 
‘81’ L  r Câmp de date  ‘8E’  ‘04’  CC  
Datele care trebuie integrate în suma de verificare = T  PV || 
L PV || PV || PB  
2. Cazul în care câmpul de date r ăspuns nu este gol și este 
nevoie să fie protejat pentru confiden țialitate:  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 376  
Corpul răspunsului  Coada r ăspunsului  
[Câmp de date nou]  SW1 SW2 noi  
T PI CG  L PI 
CG PI CG  T  CC L CC CC 
‘87’ PI || CG  ‘8E’  ‘04’  CC  
Datele care sunt transportate prin CG: date necodate prin 
BER-TLV și octeți de completare.  
Datele care trebuie integrate în suma de verificare = T  PI 
CG || L  PI CG  || PI CG || PB  
3. Cazul în care câmpul de date r ăspuns este gol:  
Corpul răspunsului  Coada r ăspunsului  
[Câmp de date nou]  SW1 SW2 noi  
T SW L SW SW T  CC L CC CC 
‘99’ ‘02’  SW1 SW2 noi  ‘8E’  ‘04’  CC  
Datele care trebuie integrate în suma de verificare = T  SW || 
L SW || SW || PB  
5.2. Tratarea erorilor mesageriei securizate  
CSM_026 Atunci când cardul de tahograf recunoa ște o eroare de SM 
(mesagerie securizat ă) în timpul interpret ării unei comenzi, 
octeții de stare trebuie s ă fie returna ți fără SM. În confor ­
mitate cu standardul ISO/IEC 7816-4, urm ătorii octeți de 
stare sunt defini ți pentru a indica erori de SM:  
‘66 88’: verificarea sumei de verificare criptografice a e șuat, 
‘69 87’: obiectele de date a șteptate ale SM lipsesc,  
‘69 88’: obiectele de date ale SM sunt incorecte.  
CSM_027 Atunci când cardul de tahograf returneaz ă octeții de stare f ără 
obiectele de date ale SM sau cu un obiect de date al SM 
eronat, sesiunea trebuie s ă fie terminat ă de VU.  
5.3. Algoritmul de calcul al sumelor de verificare criptografice  
CSM_028 Sumele de verificare criptografice sunt construite folosind un 
MAC (cod de autentificare a mesajelor) detaliat, conform 
standardului ANSI X9.19, cu criptarea DES:  
— Etapa ini țială: blocul de verificare ini țial y0 este E(Ka, 
SSC).  
— Etapa secven țială: blocurile de verificare y1,…, yn sunt 
calculate folosind Ka.  
— Etapa final ă: suma de verificare criptografic ă este 
calculată din ultimul bloc de control yn dup ă cum 
urmează: E[Ka, D(Kb, yn)].  
unde E() este criptarea cu DES, iar D() este decriptarea cu 
DES.  
Cei mai relevan ți patru octe ți ai sumei de verificare cripto ­
grafice sunt transfera ți. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 377  
CSM_029 Contorul de secven țe trimise (SSC) este ini țializat în timpul 
procedurii de în țelegere asupra cheii la:  
SSC inițial: Rnd3 (cei 4 octe ți cel mai pu țin semnificativi) || 
Rnd1 (cei 4 octe ți cel mai pu țin semnificativi) ||  
CSM_030 Contorul de secven țe trimise este incrementat cu 1 de fiecare 
dată înainte de calcularea unui MAC ( și anume, SSC pentru 
prima comand ă este SSC ini țial + 1, SSC pentru primul 
răspuns este SSC ini țial + 2).  
Figura urm ătoare ilustreaz ă calcularea MAC detaliat:
  
5.4. Algoritmul de calcul al criptogramelor pentru obiecte de date (DO) 
confidențiale 
CSM_031 Criptogramele sunt calculate folosind TDEA în modul de 
funcționare TCBC, în conformitate cu referin țele [TDES] și 
[TDES-OP], și utilizând vectorul nul ca bloc de valoare 
inițială. 
Figura urm ătoare ilustreaz ă aplicarea cheilor în TDES:
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 378  
6. MECANISMELE DE SEMNARE DIGITAL Ă A DATELOR 
DESCĂRCATE  
CSM_032 Echipamentul inteligent dedicat (IDE) stocheaz ă într-un 
singur fișier fizic de date datele recep ționate de la un echi ­
pament (VU sau card) în timpul unei sesiuni de desc ărcare. 
Acest fișier trebuie s ă conțină certificatele MS  i .C și EQT.C. 
Fișierul conține semnăturile digitale ale blocurilor de date a șa 
cum se specific ă în apendicele 7, „Protocoale de desc ărcare a 
datelor”.  
CSM_033 Semn ăturile digitale ale datelor desc ărcate utilizeaz ă o 
schemă de semn ătură digitală cu apendice astfel încât 
datele desc ărcate să poată fi citite fără nicio descifrare dac ă 
se dorește. 
6.1. Generarea semn ăturilor  
CSM_034 Generarea semn ăturilor de date de c ătre echipament trebuie 
să respecte schema de semn ătură cu apendice definit ă în 
referința [PKCS1] cu func ția hash  SHA-1:  
Semnătura = EQT.SK[‘00’ || ‘01’ ||  PS || ‘00’ || DER(SHA-1 
(Data))]  
PS = șir de octeți de completare cu valoarea ‘FF’, astfel încât 
lungimea s ă fie 128.  
DER(SHA-1( M)) este codificarea ID-ului algoritmului pentru 
funcția hash  și pentru valoarea  hash  într-o valoare ASN.1 de 
tip DigestInfo (reguli de codare distincte):  
‘30’||‘21’||‘30’||‘09’||‘06’||‘05’ ||‘2B’||‘0E’||‘03’||‘02’||‘1A’|| 
‘05’||‘00’||‘04’||‘14’||valoare  hash . 
6.2. Verificarea semn ăturilor  
CSM_035 Verificarea semn ăturilor datelor la datele desc ărcate este 
efectuată conform schemei de semn ătură cu apendice 
definită în referința [PKCS1] cu func ția hash  SHA-1.  
Cheia public ă europeană EUR.PK trebuie s ă fie cunoscut ă 
independent ( și aprobată) de verificator.  
Tabelul urm ător ilustreaz ă protocolul pe care îl poate urma 
un IDE dotat cu un card de control pentru a verifica inte ­
gritatea datelor desc ărcate și stocate pe ESM (suport de 
memorie extern). Cardul de control este folosit pentru a 
efectua descifrarea semn ăturilor digitale. În acest caz, 
această funcție nu trebuie neap ărat să fie implementat ă în 
IDE.  
Echipamentul care a desc ărcat și semnat datele de analizat 
este denumit EQT.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 379
  
PARTEA B  
SISTEMUL TAHOGRAFIC DE A DOUA GENERA ȚIE 
7. INTRODUCERE  
7.1. Referin țe 
În această parte a prezentului apendice se face trimitere la urm ătoarele 
standarde:  
AES  National Institute of Standards and Technology  (NIST), 
FIPS PUB 197:  Advanced Encryption Standard  (AES), 
26 noiembrie 2001  
DSS National Institute of Standards and Technology  (NIST), 
FIPS PUB 186-4:  Digital Signature Standard  (DSS), iulie 
2013  
ISO 7816-4 ISO/IEC 7816-4,  Identification cards  – Integrated circuit 
cards  – Part 4: Organization, security and commands for 
interchange.  Ediția a treia, 15.4.2013  
ISO 7816-8 ISO/IEC 7816-8,  Identification cards  – Integrated circuit 
cards  – Part 8: Commands for security operations.  Ediția 
a doua, 1.6.2004  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 380  
ISO 8825-1 ISO/IEC 8825-1  Information technology  – ASN.1 
encoding rules: Specification of Basic Encoding Rules 
(BER), Canonical Encoding Rules (CER) and Distin ­
guished Encoding Rules (DER).  Ediția a patra, 
15.12.2008  
ISO 9797-1 ISO/IEC 9797-1,  Information technology – Security 
techniques – Message Authentication Codes (MACs) – 
Part 1: Mechanisms using a block cipher.  Ediția a 
doua, 1.3.2011  
ISO 10116 ISO/IEC 10116,  Information technology – Security 
techniques – Modes of operation of an n-bit block 
cipher.  Ediția a treia, 1.2.2006  
ISO 16844-3 ISO16844-3  Road vehicles – Tachograph systems – Part 
3: Motion sensor interface.  Prima edi ție 2004, inclusiv 
rectificarea tehnic ă 1, 2006  
RFC 5480  Elliptic Curve Cryptography Subject Public Key Infor ­
mation , martie 2009  
RFC 5639  Elliptic Curve Cryptography (ECC)  – Brainpool Standard 
Curves and Curve Generation , 2010  
RFC 5869  HMAC-based Extract-and-Expand Key Derivation 
Function  (HKDF), mai 2010  
SHS National Institute of Standards and Technology  (NIST), 
FIPS PUB 180-4:  Secure Hash Standard , martie 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 
Authentication,  2005  
TR-03111  BSI Technical Guideline TR-03111, Elliptic Curve Cryp ­
tography , versiunea 2.00, 28.6.2012  
7.2. Nota ții și abrevieri  
În prezentul apendice sunt folosite urm ătoarele nota ții și abrevieri:  
AES Standard de criptare avansat ă 
CA Autoritate pentru certificate  
CAR Identificatorul autorit ății pentru certificate  
CBC Înl ănțuirea blocurilor cifrate (mod de func ționare)  
CH Antet de comand ă 
CHA Autoriza ția deținătorului certificatului  
CHR Identificatorul de ținătorului certificatului  
CV Vector constant  
DER Reguli de codificare distincte  
DO Obiect de date  
DSRC Comunica ții specializate cu raz ă scurtă de acțiune 
ECC Criptografie bazat ă pe curbe eliptice  
ECDSA Algoritm pentru semn ătura digital ă bazat pe curbe eliptice  
ECDH (Algoritm de în țelegere asupra cheii bazat pe) curba 
eliptică Diffie-Hellman  
EGF echipament GNSS extern  
EQT Echipament  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 381  
IDE Echipament inteligent dedicat  
K M Cheie master a senzorului de mi șcare, care permite o 
asociere a unei unit ăți montate pe vehicul cu un senzor 
de mișcare 
K M-VU  Cheie introdus ă în unitățile montate pe vehicule, permi țând 
unei VU s ă deriveze cheia master a senzorului de mi șcare 
în cazul în care un card de atelier este introdus în 
respectiva VU  
K M-WC  Cheie introdus ă în cardurile de atelier, permi țând unei VU 
să deriveze cheia master a senzorului de mi șcare în cazul 
în care un card de atelier este introdus în respectiva VU  
MAC Cod de autentificare a mesajelor  
MoS Senzor de mi șcare 
MSB Bitul cel mai semnificativ  
PKI Infrastructur ă pentru chei publice  
RCF Echipament de comunicare la distan ță 
SSC Contor de secven țe trimise  
SM Mesagerie securizat ă 
TDES Standard de criptare tripl ă a datelor  
TLV Valoarea lungimii etichetei  
VU Unitate montat ă pe vehicul  
X.C certificatul de cheie public ă al utilizatorului X  
X.CA autoritatea pentru certificate care a emis certificatul utili ­
zatorului X  
X.CAR identificatorul autorit ății pentru certificate men ționat în 
certificatul utilizatorului X  
X.CHR identificatorul de ținătorului certificatului men ționat în 
certificatul utilizatorului X  
X.PK cheia public ă a utilizatorului X  
X.SK cheia privat ă a utilizatorului X  
X.PK  eph cheia public ă efemeră a utilizatorului X  
X.SK  eph cheia privat ă efemeră a utilizatorului X  
‘xx’ o valoare hexazecimal ă 
|| operator de concatenare  
7.3. Defini ții 
Definițiile termenilor utiliza ți în prezentul apendice sunt incluse în 
secțiunea I a anexei 1C.  
8. SISTEME ȘI ALGORITMI CRIPTOGRAFICI  
8.1. Sisteme criptografice  
CSM_38 Unit ățile montate pe vehicule și cardurile de tahograf 
utilizează un sistem criptografic cu chei publice bazat pe 
curbe eliptice pentru a oferi urm ătoarele servicii de secu ­
ritate:  
— autentificarea reciproc ă între o unitate montat ă pe 
vehicul și un card,  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 382  
— înțelegerea asupra cheilor de sesiune AES între o 
unitate montat ă pe vehicul și un card,  
— asigurarea autenticit ății, integrit ății și nerepudierii 
datelor desc ărcate din unit ățile montate pe vehicule 
sau din cardurile de tahograf pe suporturi externe.  
CSM_39 Unit ățile montate pe vehicule și echipamentele GNSS 
externe utilizeaz ă un sistem criptografic cu chei publice 
bazat pe curbe eliptice pentru a oferi urm ătoarele servicii 
de securitate:  
— cuplarea unei unit ăți montate pe vehicul cu un echi ­
pament GNSS extern,  
— autentificarea reciproc ă între o unitate montat ă pe 
vehicul și un dispozitiv GNSS extern,  
— înțelegerea asupra unei chei de sesiune AES între o 
unitate montat ă pe vehicul și un echipament GNSS 
extern,  
CSM_40 Unit ățile montate pe vehicule și cardurile de tahograf 
utilizează un sistem criptografic simetric bazat pe AES 
pentru a oferi urm ătoarele servicii de securitate:  
— asigurarea autenticit ății și integrității datelor schimbate 
între o unitate montat ă pe vehicul și un card de 
tahograf,  
— după caz, asigurarea confiden țialității datelor schimbate 
între o unitate montat ă pe vehicul și un card de 
tahograf,  
CSM_41 Unit ățile montate pe vehicule și echipamentele GNSS 
externe utilizeaz ă un sistem criptografic simetric bazat pe 
AES pentru a oferi urm ătoarele servicii de securitate:  
— asigurarea autenticit ății și integrității datelor schimbate 
între o unitate montat ă pe vehicul și un echipament 
GNSS extern.  
CSM_42 Unit ățile montate pe vehicule și senzorii de mi șcare 
utilizează un sistem criptografic simetric bazat pe AES 
pentru a oferi urm ătoarele servicii de securitate:  
— asocierea dintre o unitate montat ă pe vehicul și un 
senzor de mi șcare,  
— autentificarea reciproc ă între o unitate montat ă pe 
vehicul și un senzor de mi șcare,  
— asigurarea confiden țialității datelor schimbate între o 
unitate montat ă pe vehicul și un senzor de mi șcare.  
CSM_43 Unit ățile montate pe vehicule și cardurile de tahograf 
utilizează un sistem criptografic simetric bazat pe AES 
pentru a oferi urm ătoarele servicii de securitate la nivelul 
interfeței de comunicare la distan ță: 
— asigurarea confiden țialității, autenticit ății și integrității 
datelor transmise de la o unitate montat ă pe vehicul la 
un card de control.  
Note:  
— În mod concret, datele sunt transmise de la o unitate 
montată pe vehicul la un echipament de interogare la 
distanță, sub controlul unui agent de control, folosind 
un echipament de comunicare la distan ță care poate fi 
intern sau extern în raport cu VU (a se vedea apen ­
dicele 14). Cu toate acestea, echipamentul de inte ­
rogare la distan ță trimite datele primite unui card de  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 383  
control pentru decriptare și validarea autenticit ății. Din 
punctul de vedere al securit ății, echipamentul de comu ­
nicare la distan ță și echipamentul de interogare la 
distanță sunt pe deplin transparente.  
— Un card de atelier ofer ă aceleași servicii de securitate 
pentru interfa ța DSRC ca un card de control. Aceasta 
permite unui atelier s ă valideze func ționarea corect ă a 
interfeței de comunicare la distan ță a unei VU, inclusiv 
a sistemului de asigurare a securit ății acesteia. A se 
vedea secțiunea 9.2.2 pentru informa ții suplimentare.  
8.2. Algoritmi criptografici  
8.2.1  Algoritmi simetrici  
CSM_44 Unit ățile montate pe vehicule, cardurile de tahograf, 
senzorii de mi șcare și echipamentele GNSS externe sunt 
compatibile cu algoritmul AES, astfel cum este definit în 
[AES], cu lungimi ale cheilor de 128, 192 și 256 de bi ți. 
8.2.2  Algoritmi asimetrici și parametri de domeniu standardiza ți 
CSM_45 Unit ățile montate pe vehicule, cardurile de tahograf și echi­
pamentele GNSS externe sunt compatibile cu criptografia 
bazată pe curbe eliptice, cu lungimi ale cheii de 256, 384 
și 512/521 bi ți. 
CSM_46 Unit ățile montate pe vehicule, cardurile de tahograf și echi­
pamentele GNSS externe sunt compatibile cu algoritmul de 
semnare ECDSA, astfel cum este precizat în [DSS].  
CSM_47 Unit ățile montate pe vehicule, cardurile de tahograf și echi­
pamentele GNSS externe sunt compatibile cu algoritmul de 
înțelegere asupra cheii ECKA-EG, astfel cum este precizat 
în [TR03111].  
CSM_48 Unit ățile montate pe vehicule, cardurile de tahograf și echi­
pamentele GNSS externe sunt compatibile cu to ți para­
metrii de domeniu standardiza ți precizați în tabelul 1 de 
mai jos pentru criptografia bazat ă pe curbe eliptice.  
Tabelul 1  
Parametri de domeniu standardiza ți 
Denumire  Dimensiune (bi ți) Referin ță Identificatorul de obiect  
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 — RO — 26.02.2020 — 002.001 — 384  
Notă: identificatorii de obiecte men ționați în ultima 
coloană a tabelul 1 sunt specifica ți în [RFC 5639] pentru 
curbele Brainpool, respectiv în [RFC 5480] pentru curbele 
NIST.
  
8.2.3  Algoritmi de hashing  
▼M1 
CSM_49 Unit ățile montate pe vehicule, cardurile de tahograf și echi­
pamentele GNSS externe sunt compatibile cu algoritmii 
SHA-256, SHA-384 și SHA-512 specifica ți în [SHS].  
▼B 
8.2.4  Suite cifru  
CSM_50 În cazul în care un algoritm simetric, un algoritm asimetric 
și/sau un algoritm de  hashing  sunt utiliza ți împreun ă 
pentru a forma un protocol de securitate, lungimile 
cheilor lor respective și dimensiunile lor  hash  respective 
trebuie să aibă (aproximativ) aceea și putere. În tabelul 2 
sunt indicate suitele cifru permise:  
Tabelul 2  
Suite cifru permise  
Identificatorul suitei 
cifru  Lungimea cheii ECC 
(biți) Lungimea cheii AES 
(biți) Algoritm de  
hashing  Lungimea MAC 
(octeți) 
CS#1  256  128  SHA-256  8  
CS#2  384  192  SHA-384  12  
CS#3  512/521  256  SHA-512  16  
Notă: Dimensiunile de 512 bi ți și de 521 de bi ți ale cheilor sunt considerate a avea puteri egale 
pentru toate scopurile în cadrul prezentului apendice.  
9. CHEI ȘI CERTIFICATE  
9.1. Perechi de chei asimetrice și certificate de cheie public ă 
9.1.1  Considera ții generale  
Notă: cheile descrise în aceast ă secțiune sunt utilizate pentru autenti ­
ficarea reciproc ă și mesageria securizat ă între unit ățile montate pe 
vehicule și cardurile de tahograf și între unit ățile montate pe vehicule 
și echipamentele GNSS externe. Aceste procese sunt descrise în detaliu 
în capitolele 10 și 11 din prezentul apendice.  
CSM_51 În cadrul sistemului tahografic inteligent european, 
perechile de chei ECC și certificatele aferente sunt 
generate și administrate prin trei niveluri ierarhice 
funcționale:  
— nivelul european,  
— nivelul statului membru,  
— nivelul echipamentului.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 385  
CSM_52 În cadrul întregului sistem tahografic digital european, 
cheile și certificatele publice și private sunt generate, admi ­
nistrate și comunicate folosind metode standardizate și 
sigure.  
9.1.2  Nivelul european  
CSM_53 La nivel european se genereaz ă o pereche unic ă de chei 
ECC denumit ă EUR. Ea este format ă dintr-o cheie privat ă 
(EUR.SK) și o cheie public ă (EUR.PK). Aceast ă pereche 
de chei reprezint ă perechea de chei r ădăcină a întregii PKI 
pentru tahograful digital european. Aceast ă sarcină este 
îndeplinită de o Autoritate european ă pentru certificatele 
rădăcină (ERCA), sub autoritatea și responsabilitatea 
Comisiei Europene.  
CSM_54 ERCA utilizeaz ă cheia privat ă europeană pentru a semna 
un certificat r ădăcină (autosemnat) al cheii publice 
europene și comunic ă acest certificat r ădăcină european 
tuturor statelor membre.  
CSM_55 ERCA utilizeaz ă cheia privat ă europeană pentru a semna 
certificatele cheilor publice ale statelor membre, la cerere. 
ERCA ține eviden țe ale tuturor certificatelor de cheie 
publică semnate ale statelor membre.  
CSM_56 Dup ă cum se arat ă în figura 1 din sec țiunea 9.1.7, ERCA 
generează o nouă pereche de chei r ădăcină europene o dat ă 
la 17 ani. Ori de câte ori ERCA genereaz ă o nouă pereche 
de chei r ădăcină europene, aceasta creeaz ă un nou 
certificat r ădăcină autosemnat pentru noua cheie public ă 
europeană. Perioada de valabilitate a unui certificat 
rădăcină european este de 34 de ani și 3 luni.  
Notă: Introducerea unei noi perechi de chei r ădăcină 
implică de asemenea faptul c ă ERCA va genera o nou ă 
cheie master pentru senzorul de mi șcare și o nouă cheie 
master pentru DSRC (a se vedea sec țiunile 9.2.1.2 și 
9.2.2.2.)  
CSM_57 Înainte de a genera o nou ă pereche de chei r ădăcină 
europene, ERCA va efectua o analiz ă a puterii cripto ­
grafice necesare pentru noua pereche de chei, ținând cont 
de faptul c ă aceasta din urm ă ar trebui s ă fie sigură pentru 
următorii 34 de ani. Dac ă se va considera necesar, ERCA 
va alege o suit ă cifru mai puternic ă decât actuala suit ă, 
astfel cum este precizat în CSM_50.  
▼M1 
CSM_58 Ori de câte ori genereaz ă o nouă pereche de chei r ădăcină, 
ERCA creeaz ă un certificat de leg ătură pentru noua cheie 
publică european ă și îl semneaz ă cu cheia privat ă 
europeană anterioar ă. Perioada de valabilitate a unui 
certificat de leg ătură este de 17 ani și 3 luni. Acest 
proces este prezentat și în figura 1 din sec țiunea 9.1.7.  
▼B 
Notă: Întrucât un certificat de leg ătură conține cheia 
publică din genera ția X generată de ERCA și este semnat 
cu cheia privat ă din genera ția X-1 generată de ERCA, un 
certificat de leg ătură oferă echipamentului produs în cadrul 
generației X-1  o metodă de a avea încredere în echipa ­
mentele produse în cadrul genera ției X. 
CSM_59 ERCA nu mai utilizeaz ă cheia privat ă a unei perechi de 
chei rădăcină în niciun scop dup ă momentul în care a fost 
validat un nou certificat de cheie r ădăcină. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 386  
CSM_60 În orice moment, ERCA dispune de una dintre urm ătoarele 
chei criptografice și certificate:  
— Perechea de chei EUR actual ă și certificatul aferent  
— Toate certificatele EUR anterioare care urmeaz ă să fie 
utilizate pentru verificarea certificatelor MSCA înc ă 
valabile  
— Certificate de leg ătură pentru toate genera țiile de certi ­
ficate EUR, cu excep ția primei genera ții. 
9.1.3  Nivelul statului membru  
CSM_61 La nivel de stat membru, toate statele membre c ărora li se 
solicită să semneze certificate de card de tahograf 
generează una sau mai multe perechi de chei ECC unice 
desemnate ca fiind MSCA_Card. Toate statele membre 
cărora li se solicit ă să semneze certificate pentru unit ăți 
montate pe vehicul sau pentru echipamente GNSS 
externe genereaz ă în plus una sau mai multe perechi de 
chei ECC desemnate ca fiind MSCA_VU-EGF.  
CSM_62 Sarcina de a genera perechi de chei pentru statul membru 
este îndeplinit ă de autoritatea pentru certificate a unui stat 
membru (MSCA). Ori de câte ori o MSCA genereaz ă o 
pereche de chei pentru statul membru, aceasta trimite cheia 
publică la ERCA în vederea ob ținerii unui certificat aferent 
al statului membru, semnat de ERCA.  
CSM_63 O MSCA alege puterea unei perechi de chei a unui stat 
membru astfel încât s ă fie egală cu puterea perechii de chei 
rădăcină europene utilizate pentru semnarea certificatului 
aferent al statului membru.  
CSM_64 O pereche de chei MSCA_VU-EGF, dac ă există, este 
formată din cheia privat ă MSCA_VU-EGF.SK și din 
cheia public ă MSCA_VU-EGF.SK. O MSCA utilizeaz ă 
cheia privat ă MSCA_VU-EGF.SK exclusiv pentru 
semnarea certificatelor de cheie public ă ale unităților 
montate pe vehicule și ale echipamentelor GNSS externe.  
CSM_65 O pereche de chei MSCA_Card este format ă din cheia 
privată MSCA_Card.SK și din cheia public ă 
MSCA_Card.PK. O MSCA utilizeaz ă cheia privat ă 
MSCA_Card.SK exclusiv pentru semnarea certificatelor 
de cheie public ă ale cardurilor de tahograf.  
CSM_66 O MSCA ține eviden țe privind toate certificatele semnate 
ale unităților montate pe vehicule, ale echipamentelor 
GNSS externe și ale certificatelor de card, cât și privind 
identificarea echipamentului c ăruia îi este destinat fiecare 
certificat în parte.  
CSM_67 Perioada de valabilitate a unui certificat MSCA_VU-EGF 
este de 17 ani și 3 luni. Perioada de valabilitate a unui 
certificat MSCA_Card este de 7 ani și 1 lună. 
CSM_68 Astfel cum este indicat în figura 1 din sec țiunea 9.1.7, 
cheia privat ă a unei perechi de chei MSCA_VU-EGF și 
cheia privat ă a unei perechi de chei MSCA_Card au o 
perioadă de utilizare de doi ani.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 387  
CSM_69 O MSCA nu mai utilizeaz ă cheia privat ă a unei perechi de 
chei MSCA_VU-EGF în niciun scop dup ă momentul în 
care perioada sa de utilizare a expirat. De asemenea, o 
MSCA nu mai utilizeaz ă cheia privat ă a unei perechi de 
chei MSCA_Card key în niciun scop dup ă momentul la 
care perioada sa de utilizare a expirat.  
CSM_70 În orice moment, o MSCA dispune de una dintre urm ă­
toarele chei criptografice și certificate:  
— Perechea de chei MSCA_Card actual ă și certificatul 
aferent  
— Toate certificatele MSCA_Card anterioare care 
urmează să fie utilizate pentru verificarea certificatelor 
cardurilor de tahograf înc ă valabile  
— Certificatul EUR actual necesar pentru verificarea certi ­
ficatului MSCA actual  
— Toate certificatele EUR anterioare necesare pentru veri ­
ficarea certificatelor MSCA înc ă valabile  
CSM_71 În cazul în care o MSCA este solicitat ă să semneze certi ­
ficate pentru unit ăți montate pe vehicule sau pentru echi ­
pamente GNSS externe, aceasta trebuie, în plus, s ă aibă la 
dispoziție următoarele chei și certificate:  
— Perechea de chei MSCA_VU-EGF actual ă și certi­
ficatul aferent  
— Toate cheile publice MSCA_VU-EGF anterioare care 
urmează să fie utilizate pentru verificarea certificatelor 
încă valabile ale VU-urilor sau ale echipamentelor 
GNSS externe  
9.1.4  Nivelul echipamentului: Unit ăți montate pe vehicule  
▼M1 
CSM_72 Pentru fiecare unitate montat ă pe vehicul sunt generate 
două perechi de chei ECC unice, desemnate ca fiind 
VU_MA și VU_Sign. Aceast ă sarcină este îndeplinit ă de 
producătorii de VU. Ori de câte ori este generat ă o pereche 
de chei pentru VU, partea care genereaz ă cheia transmite 
cheia public ă către MSCA de care apar ține, în scopul de a 
obține un certificat aferent al VU semnat de MSCA. Cheia 
privată este utilizat ă doar de c ătre unitatea montat ă pe 
vehicul.  
▼B 
CSM_73 Certificatele VU_MA și VU_Sign ale unui anumit vehicul 
au aceeași dată de începere a valabilit ății certificatului.  
CSM_74 Un produc ător de VU alege puterea unei perechi de chei 
pentru VU astfel încât s ă fie egală cu puterea perechii de 
chei MSCA utilizate pentru semnarea certificatului aferent 
al VU.  
CSM_75 O unitate montat ă pe vehicul utilizeaz ă perechea sa de chei 
VU_MA, format ă din cheia privat ă VU_MA.SK și din 
cheia public ă VU_MA.PK, exclusiv pentru procedura de 
autentificare a VU în raport cu cardurile de tahograf și cu 
echipamentele GNSS externe, astfel cum este specificat în 
secțiunile 10.3 și 11.4 din prezentul apendice.  
CSM_76 O unitate montat ă pe vehicul este capabil ă să genereze 
perechi de chei ECC efemere și utilizează o pereche de 
chei efemere exclusiv pentru a efectua în țelegerea asupra 
cheilor de sesiune cu un card de tahograf sau cu un echi ­
pament GNSS extern, astfel cum este specificat în 
secțiunile 10.4 și 11.4 din prezentul apendice.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 388  
CSM_77 O unitate montat ă pe vehicul utilizeaz ă cheia privat ă 
VU_Sign.SK a perechii sale de chei VU_Sign exclusiv 
pentru a semna fi șiere de date desc ărcate, astfel cum este 
specificat la capitolul 14 din prezentul apendice. Cheia 
publică aferentă VU_Sign.PK este utilizat ă exclusiv 
pentru a verifica semn ăturile create de unitatea montat ă 
pe vehicul.  
CSM_78 Astfel cum se arat ă în figura 1 din sec țiunea 9.1.7, 
perioada de valabilitate a unui certificat VU_MA este de 
15 ani și 3 luni. Perioada de valabilitate a unui certificat 
VU_Sign este de asemenea de 15 ani și 3 luni.  
Note:  
— Perioada prelungit ă de valabilitate a unui certificat 
VU_Sign permite unei unit ăți montate pe vehicul s ă 
creeze semn ături valabile pentru datele desc ărcate în 
primele trei luni de la data la care certificatul 
respectiv a expirat, astfel cum se prevede în Regula ­
mentul (UE) nr. 581/2010.  
— Perioada prelungit ă de valabilitate a unui certificat 
VU_MA este necesar ă pentru a permite VU s ă se 
autentifice în raport cu un card de control sau cu un 
card de societate în cursul primelor trei luni de la data 
la care certificatul respectiv a expirat, astfel încât s ă fie 
posibilă descărcarea de date.  
CSM_79 O unitate montat ă pe vehicul nu mai utilizeaz ă în niciun 
scop cheia privat ă a unei perechi de chei a VU dup ă 
expirarea valabilit ății certificatului aferent.  
CSM_80 Perechile de chei ale VU (cu excep ția perechilor de chei 
efemere) și certificatele aferente ale unui anumit vehicul nu 
sunt înlocuite sau reînnoite pe teren odat ă ce unitatea de 
vehicul a fost pus ă în funcțiune.  
Note:  
— Perechile de chei efemere nu fac obiectul dispozi ției de 
mai sus, întrucât o pereche nou ă de chei efemere este 
generată de o VU de fiecare dat ă când se efectueaz ă 
autentificarea cipului și înțelegerea asupra cheilor de 
sesiune (a se vedea sec țiunea 10.4). A se nota faptul 
că perechile de chei efemere nu au certificate aferente.  
— Această cerință nu exclude posibilitatea de a înlocui 
perechile de chei ale VU-urilor statice în timpul unei 
renovări sau repara ții efectuate într-un mediu sigur 
controlat de produc ător. 
CSM_81 Atunci când sunt puse în func țiune, unitățile montate pe 
vehicule trebuie s ă conțină următoarele chei criptografice 
și certificate:  
— Cheia privat ă VU_MA și certificatul aferent  
— Cheia privat ă VU_Sign și certificatul aferent  
— Certificatul MSCA_VU-EGF care con ține cheia 
publică MSCA_VU-EGF.PK destinat ă verificării certi­
ficatului VU_MA și certificatului VU_Sign  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 389  
— Certificatul EUR care con ține cheia public ă EUR.PK 
destinată verificării certificatului MSCA_VU-EGF  
— Certificatul EUR a c ărui perioad ă de valabilitate 
precede imediat perioada de valabilitate a certificatului 
EUR destinat verific ării certificatului MSCA_VU-EGF, 
dacă există 
— Certificatul de leg ătură care face conexiunea între 
aceste dou ă certificate de mai sus, dac ă există 
CSM_82 Pe lâng ă cheile criptografice și certificatele enumerate în 
CSM_81, unit ățile montate pe vehicule con țin, de 
asemenea, chei și certificate specificate în partea A din 
prezentul apendice, permi țând unei unit ăți montate pe 
vehicul să interacționeze cu cardurile de tahograf de 
prima genera ție. 
9.1.5  Nivelul echipamentului: Carduri de tahograf  
▼M1 
CSM_83 Pentru fiecare card de tahograf este generat ă o unică 
pereche de chei ECC, desemnat ă ca fiind Card_MA. O a 
doua pereche unic ă de chei ECC, desemnat ă ca fiind 
Card_Sign, este generat ă suplimentar pentru fiecare card 
de conduc ător auto și pentru fiecare card de atelier. 
Această sarcină poate fi îndeplinit ă de produc ătorii de 
carduri sau de serviciile de personalizare a cardurilor. Ori 
de câte ori este generat ă o pereche de chei pentru card, 
partea care genereaz ă cheia transmite cheia public ă către 
MSCA de care apar ține, în scopul de a ob ține un certificat 
aferent de card semnat de MSCA. Cheia privat ă este 
utilizată doar de c ătre cardul de tahograf.  
▼B 
CSM_84 Certificatele Card_MA și Card_Sign ale unui anumit card 
de conduc ător auto au aceea și dată de începere a valabi ­
lității certificatului.  
CSM_85 Un produc ător de carduri sau un serviciu de personalizare 
a cardurilor alege puterea unei perechi de chei pentru 
carduri astfel încât aceasta s ă fie egal ă cu puterea 
perechii de chei MSCA utilizate pentru semnarea certifi ­
catului aferent de card.  
CSM_86 Un card de tahograf utilizeaz ă perechea sa de chei 
Card_MA, format ă din cheia privat ă Card_MA.SK și din 
cheia public ă Card_MA.PK, exclusiv pentru procedurile de 
autentificare reciproc ă și de înțelegere asupra cheilor de 
sesiune în raport cu unit ățile montate pe vehicul, astfel 
cum este precizat în sec țiunile 10.3 și 10.4 din prezentul 
apendice.  
CSM_87 Un card de conduc ător auto sau un card de atelier 
utilizează cheia privat ă Card_Sign.SK a perechii sale de 
chei Card_Sign exclusiv pentru a semna fi șierele de date 
descărcate, astfel cum este specificat la capitolul 14 din 
prezentul apendice. Cheia public ă aferentă Card_Sign.PK 
este utilizat ă exclusiv pentru a verifica semn ăturile create 
de card.  
▼M1 
CSM_88 Perioada de valabilitate a unui certificat Card_MA este 
după cum urmeaz ă: 
— Pentru carduri de conduc ător auto: 5 ani  
— Pentru carduri de societate: 5 ani  
— Pentru carduri de control: 2 ani  
— Pentru carduri de atelier: 1 an  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 390  
CSM_89 Perioada de valabilitate a unui certificat Card_Sign este 
după cum urmeaz ă: 
— Pentru carduri de conduc ător 
auto:  5 ani si o lun ă 
— Pentru carduri de atelier:  1 an si o lun ă 
Notă: perioada prelungit ă de valabilitate a unui certificat 
Card_Sign permite unui card de conduc ător auto să creeze 
semnături valabile pentru datele desc ărcate în prima lun ă 
de la data la care certificatul respectiv a expirat. Acest 
lucru este necesar având în vedere Regulamentul (UE) 
nr. 581/2010, care prevede c ă o descărcare de date de pe 
un card de conduc ător auto trebuie s ă fie posibil ă într-un 
interval de cel mult 28 de zile de la data la care au fost 
înregistrate ultimele date.  
CSM_90 Odat ă ce cardul a fost emis, perechile de chei și certifi­
catele aferente ale unui anumit tahograf nu sunt înlocuite 
sau reînnoite.  
CSM_91 Atunci când sunt emise, cardurile de tahograf con țin urmă­
toarele chei criptografice și certificate:  
— cheia privat ă Card_MA și certificatul aferent  
— Pentru cardurile de conduc ător auto și cardurile de 
atelier, în plus: cheia privat ă Card_Sign și certificatul 
aferent  
— certificatul MSCA_Card care con ține cheia public ă 
MSCA_Card.PK destinat ă verificării certificatului 
Card_MA și certificatului Card_Sign  
— certificatul EUR care con ține cheia public ă EUR.PK 
destinată verificării certificatului MSCA_Card.  
— Certificatul EUR a c ărui perioad ă de valabilitate 
precede imediat perioada de valabilitate a certificatului 
EUR destinat verific ării certificatului MSCA_Card, 
dacă există. 
— Certificatul de leg ătură care face conexiunea între 
aceste dou ă certificate de mai sus, dac ă există. 
▼M1 
— În plus, numai pentru cardurile de control, cardurile de 
societate și cardurile de atelier, și numai dac ă astfel de 
carduri sunt emise în cursul primelor trei luni ale 
perioadei de valabilitate a unui nou certificat EUR: 
certificatul EUR care este mai vechi cu dou ă generații, 
dacă există. 
Notă la ultimul simbol marcator : De exemplu, în 
primele trei luni ale certificatului ERCA(3) (a se 
vedea figura 1), cardurile men ționate con țin certificatul 
ERCA(1). Acesta este necesar pentru a se asigura c ă 
respectivele carduri pot fi utilizate pentru a desc ărca 
date din VU ERCA(1) a c ăror durată normală de 
viață de 15 ani, plus perioada de trei luni de desc ărcare 
a datelor, expir ă în lunile respective; a se vedea ultimul 
simbol marcator de la cerin ța 13 din anexa IC.  
▼B 
CSM_92 Pe lâng ă cheile criptografice și certificatele enumerate în 
CSM_91, cardurile de tahograf con țin, de asemenea, chei 
și certificate specificate în partea A din prezentul apendice, 
permițând acestor carduri s ă interacționeze cu VU-urile de 
prima genera ție. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 391  
9.1.6  Nivelul echipamentului: Echipamente GNSS externe  
▼M1 
CSM_93 O pereche unic ă de chei ECC este generat ă pentru fiecare 
echipament GNSS extern, desemnat ă ca fiind EGF_MA. 
Această sarcină este îndeplinit ă de produc ătorii de echi ­
pamente GNSS externe. Ori de câte ori este generat ă o 
pereche de chei EGF_MA, partea care genereaz ă cheia 
transmite cheia public ă către MSCA de care apar ține, în 
scopul de a ob ține un certificat aferent EGF_MA semnat 
de MSCA. Cheia privat ă este utilizat ă doar de c ătre echi­
pamentul GNSS extern.  
▼B 
CSM_94 Un produc ător de EGF alege puterea unei perechi de chei 
EGF_MA astfel încât s ă fie egală cu puterea perechii de 
chei MSCA utilizate pentru semnarea certificatului aferent 
EGF_MA.  
▼M1 
CSM_95 Un echipament GNSS extern î și utilizează perechea de 
chei EGF_MA, format ă din cheia privat ă EGF_MA.SK 
și din cheia public ă EGF_MA.PK, exclusiv pentru proce ­
durile de autentificare reciproc ă și de stabilire a cheilor de 
sesiune în raport cu unit ățile montate pe vehicule, astfel 
cum este precizat în sec țiunea 11.4 din prezentul apendice.  
▼B 
CSM_96 Perioada de valabilitate a certificatului EGF_MA este de 
15 ani.  
CSM_97 Un echipament GNSS extern nu mai utilizeaz ă în niciun 
scop cheia privat ă a perechii sale de chei EGF_MA dup ă 
expirarea valabilit ății certificatului aferent.  
Notă: astfel cum s-a explicat în sec țiunea 11.3.3, un EGF 
ar putea folosi cheia sa privat ă pentru autentificarea 
reciprocă în raport cu VU-ul la care este deja cuplat, 
chiar și după expirarea certificatului aferent.  
CSM_98 Odat ă ce EGF a fost pus în func țiune, perechea de chei 
EGF_MA și certificatul aferent ale unui anumit echipament 
GNSS extern nu sunt înlocuite sau reînnoite pe teren.  
Notă: Această cerință nu exclude posibilitatea de a înlocui 
perechile de chei EGF în timpul unei renov ări sau repara ții 
efectuate într-un mediu sigur controlat de produc ătorul 
EGF-ului.  
CSM_99 Atunci când sunt puse în func țiune, echipamentele GNSS 
externe trebuie s ă conțină următoarele chei criptografice și 
certificate:  
— cheia privat ă EGF_MA și certificatul aferent  
— certificatul MSCA_VU-EGF care con ține cheia public ă 
MSCA_VU-EGF.PK destinat ă verificării certificatului 
EGF_MA  
— Certificatul EUR care con ține cheia public ă EUR.PK 
destinată verificării certificatului MSCA_VU-EGF  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 392  
— Certificatul EUR a c ărui perioad ă de valabilitate 
precede imediat perioada de valabilitate a certificatului 
EUR destinat verific ării certificatului MSCA_VU-EGF, 
dacă există 
— Certificatul de leg ătură care face conexiunea între 
aceste dou ă certificate de mai sus, dac ă există 
9.1.7  Prezentare general ă: Înlocuirea certificatelor  
În figura 1 de mai jos este prezentat modul în care sunt emise și utilizate 
de-a lungul timpului diferitele genera ții de certificate r ădăcină ERCA, de 
certificate de leg ătură ERCA, de certificate MSCA și de certificate de 
echipament (VU și card).  
▼M1 
Figura 1  
Eliberarea și utilizarea diferitelor genera ții de certificate r ădăcină ERCA, de certificate de leg ătură ERCA, de 
certificate MSCA și de certificate de echipament
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 393  
Note la figura 1:  
1. Diferitele genera ții ale certificatului r ădăcină sunt indicate de un 
număr între paranteze. De exemplu, ERCA (1) este prima genera ție 
a certificatului r ădăcină ERCA; ERCA (2) este a doua genera ție etc.  
2. Alte certificate sunt marcate cu dou ă cifre între paranteze, prima cifr ă 
indicând genera ția certificatului r ădăcină în cadrul c ăreia acestea sunt 
emise, iar a doua cifr ă indicând genera ția certificatului în sine. De 
exemplu, MSCA_Card (1-1) este primul certificat MSCA_Card emis 
în cadrul genera ției ERCA (1); MSCA_Card (2-1) este primul 
certificat MSCA_Card emis în cadrul genera ției ERCA (2); 
MSCA_Card (2-last) este ultimul certificat MSCA_Card emis în 
cadrul genera ției ERCA (2); Card_MA (2-1) este primul certificat 
de card pentru autentificare reciproc ă emis în cadrul genera ției 
ERCA (2) etc.  
3. Certificatele MSCA_Card (2-1) și MSCA_Card (1-last) sunt emise 
aproape la aceea și dată, dar nu exact la aceea și dată. MSCA_Card 
(2-1) este primul certificat MSCA_Card emis în cadrul genera ției 
ERCA (2) și va fi emis pu țin mai târziu decât MSCA_Card (1-last), 
acesta din urm ă fiind ultimul certificat MSCA_Card emis în cadrul 
generației ERCA (1).  
4. Astfel cum este indicat în figur ă, primele certificate VU și de card 
emise în cadrul ERCA (2) vor ap ărea cu aproape doi ani înaintea 
apariției ultimelor certificate VU și de card emise în cadrul genera ției 
ERCA (1). Aceast ă situație este o consecin ță a faptului c ă certificatele 
VU și de card nu sunt emise în mod direct în cadrul certificatului 
ERCA, ci în cadrul unui certificat MSCA. Certificatul MSCA (2-1) va 
fi emis direct dup ă începerea valabilit ății ERCA (2), dar certificatul 
MSCA (1-ultimul) va fi emis cu pu țin timp înaintea momentului 
respectiv, și anume în ultimul moment în care certificatul ERCA (1) 
este încă valabil. Prin urmare, aceste dou ă certificate MSCA vor avea 
aproape aceea și perioadă de valabilitate, cu toate c ă sunt din genera ții 
diferite.  
5. Perioada de valabilitate indicat ă pentru carduri este cea pentru 
cardurile de conduc ător auto (5 ani).  
▼M1 
6. Pentru a economisi spa țiu, diferen ța dintre perioadele de valabilitate 
ale certificatelor CARD_MA și Card_Sign este indicat ă numai pentru 
prima genera ție. 
▼B 
9.2. Chei simetrice  
9.2.1  Chei pentru siguran ța comunica țiilor dintre VU și senzorul de mi șcare 
9.2.1.1  Considera ții generale  
Notă: se consider ă că cititorii prezentei sec țiuni sunt familiariza ți cu 
conținutul standardului (ISO 16844-3), care descrie interfa ța dintre o 
unitate montat ă pe vehicul și un senzor de mi șcare. Procesul de 
asociere dintre o VU și un senzor de mi șcare este descris în mod 
detaliat la capitolul 12 din prezentul apendice.  
CSM_100 Sunt necesare mai multe chei simetrice pentru asocierea 
dintre unit ățile montate pe vehicule și senzorii de mi șcare, 
pentru autentificarea reciproc ă între unit ățile montate pe 
vehicule și senzorii de mi șcare și pentru criptarea comuni ­
cațiilor dintre unit ățile montate pe vehicule și senzorii de 
mișcare, astfel cum se arat ă în tabelul 3. Toate aceste chei 
sunt chei AES cu o lungime egal ă cu lungimea cheii master 
a senzorului de mi șcare, care este legat ă de lungimea (pre ­
conizată) a perechii de chei r ădăcină europene, astfel cum 
este precizat în CSM_50.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 394  
Tabelul 3  
Chei pentru securizarea comunica țiilor dintre unitatea montat ă pe vehicul și senzorul de mi șcare  
Cheie  Simbol  Generat ă de Metod ă de generare  Stocat ă de 
Cheie master a senzorului 
de mișcare – component ă 
a VU  K M-VU  ERCA  Aleatoriu  ERCA, MSCA-uri implicate în 
eliberarea certificatelor VU, 
producători de VU, unit ăți 
montate pe vehicul  
Cheie master a senzorului 
de mișcare – component ă 
a atelierului  K M-WC  ERCA  Aleatoriu  ERCA, MSCA-uri, produc ătorii 
de carduri, cardurile de atelier  
Cheie master a senzorului 
de mișcare K M Nu este generat ă 
în mod inde ­
pendent  Calculată astfel: K  M 
= K  M-VU  XOR K  M- 
WC ERCA, MSCA-uri implicate în 
emiterea de chei pentru senzorii 
de mișcare (opțional) (*)  
Cheie de identificare  K  ID Nu este generat ă 
în mod inde ­
pendent  Calculată astfel: K  ID = 
K M XOR CV, unde 
CV este precizat în 
CSM_106  ERCA, MSCA-uri implicate în 
emiterea de chei pentru senzorii 
de mișcare (opțional) (*)  
Cheie de asociere  K  P Producător de 
senzori de mi șcare Aleatoriu  Un senzor de mi șcare 
Cheie de sesiune  K  S VU (în timpul 
asocierii dintre 
VU și senzorul de 
mișcare)  Aleatoriu  O VU și un senzor de mi șcare  
(*) Stocarea cheilor K  M și K  ID este opțională, întrucât aceste chei pot fi derivate din K  M-VU  , K  M-WC  și CV.  
CSM_101 Autoritatea european ă pentru certificatele r ădăcină generează 
K M-VU  și K  M-WC  , două chei AES unice și aleatorii, pe baza 
cărora poate fi calculat ă cheia master a senzorului de 
mișcare, K  M , ca fiind K  M-VU  XOR K  M-WC  . ERCA 
comunică K M, K M-VU  și K  M-WC  autorităților pentru certi ­
ficate ale statelor membre, la cererea acestora.  
CSM_102 ERCA atribuie fiec ărei chei master K  M a senzorului de 
mișcare un num ăr unic de versiune, ceea ce este aplicabil 
și pentru constituirea cheilor K  M-VU  și K  M-WC  , precum și 
pentru cheia de identificare aferent ă K ID . ERCA informeaz ă 
MSCA-urile cu privire la num ărul versiunii în momentul în 
care le trimite acestora cheile K  M-VU  și K  M-WC  . 
Notă: Numărul versiunii este utilizat pentru a face distinc ția 
între diferitele genera ții ale acestor chei, astfel cum se 
explică în detaliu în sec țiunea 9.2.1.2.  
CSM_103 O autoritate pentru certificate a unui stat membru transmite 
cheia K  M-VU  , împreună cu numărul versiunii sale, produc ă­
torilor de unit ăți montate pe vehicule, la cererea acestora. 
Producătorii de VU introduc K  M-VU  și numărul versiunii 
acesteia în toate VU produse.  
CSM_104 O autoritate pentru certificate a unui stat membru se asigur ă 
că cheia K  M-WC  , împreună cu numărul versiunii sale, sunt 
introduse în toate cardurile de atelier emise sub responsabi ­
litatea acesteia.  
Note:  
— A se vedea descrierea tipului de date
  
din apendicele 2.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 395  
— astfel cum se explic ă în secțiunea 9.2.1.2, poate fi 
necesar ca mai multe genera ții de chei K  M-WC  să fie 
introduse în acela și card de atelier.  
CSM_105 Pe lâng ă cheia AES men ționată în CSM_104, o MSCA se 
asigură că cheia TDES Km  WC , specificat ă în cerin ța 
CSM_037 din partea A din prezentul apendice, este 
introdusă în fiecare card emis sub responsabilitatea acesteia.  
Note:  
— Aceasta permite utilizarea unui card de atelier de a doua 
generație pentru cuplarea cu o VU de prima genera ție. 
— Un card de atelier de a doua genera ție va conține două 
aplicații diferite, și anume una care îndepline ște cerințele 
din partea B din prezentul apendice și una care înde ­
plinește cerințele din partea A. Cea din urm ă aplicație va 
conține cheia TDES Km  WC . 
CSM_106 O MSCA implicat ă în emiterea de senzori de mi șcare derivă 
cheia de identificare pornind de la cheia master a senzorului 
de mișcare căreia i se aplic ă operația logică XOR (disjunc ție 
exclusivă) cu un vector constant CV. Valoarea CV este dup ă 
cum urmeaz ă: 
▼M1 
— Pentru cheile master de 128 de bi ți ale senzorilor de 
mișcare: CV = „B6 44 2C 45 0E F8 D3 62 0B 7A 
8A 97 91 E4 5D 83”  
▼B 
— Pentru cheile master de 192 de bi ți ale senzorilor de 
mișcare: 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’  
— Pentru cheile master de 256 de bi ți ale senzorilor de 
mișcare: 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’  
Notă: vectorii constan ți au fost genera ți după cum urmeaz ă: 
Pi_10 = primii 10 octe ți ai porțiunii zecimale a constantei 
matematice π = ‘24 3F 6A 88 85 A3 08 D3 13 19’  
CV_ 128-bits = primii 16 octe ți ai SHA-256(Pi_10)  
CV_ 192-bits = primii 24 de octe ți ai SHA-384(Pi_10)  
CV_ 256-bits = primii 32 de octe ți ai SHA-512(Pi_10)  
CSM_107  ►M1 Fiecare produc ător de senzori de mi șcare genereaz ă o 
cheie de asociere K  P aleatorie și unică pentru fiecare senzor 
de mișcare și trimite fiecare cheie de asociere autorit ății 
pentru certificate a statului s ău membru. MSCA cripteaz ă 
fiecare cheie de asociere în mod separat, cu cheia master 
K M a senzorului de mi șcare, și returneaz ă cheia criptat ă 
producătorului senzorului de mi șcare. Pentru fiecare cheie 
criptată, MSCA notific ă producătorului senzorului de 
mișcare numărul versiunii cheii K  M asociate. ◄ 
Notă: astfel cum s-a explicat în sec țiunea 9.2.1.2, poate fi 
necesar ca un produc ător de senzori de mi șcare să genereze 
mai multe chei de asociere unice pentru un singur senzor de 
mișcare. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 396  
CSM_108 Fiecare produc ător de senzori de mi șcare genereaz ă un 
număr de serie unic pentru fiecare senzor de mi șcare și 
trimite toate numerele de serie autorit ății pentru certificate 
a statului s ău membru. MSCA cripteaz ă fiecare num ăr de 
serie, în mod separat, cu cheia de identificare K  ID , și 
returnează numărul de serie criptat produc ătorului senzorului 
de mișcare. Pentru fiecare num ăr de serie criptat, MSCA 
notifică producătorul senzorului de mi șcare num ărul 
versiunii cheii K  ID asociate.  
▼B 
CSM_109 Pentru cerin țele CSM_107 și CSM_108, MSCA utilizeaz ă 
algoritmul AES în modul de operare cu înl ănțuirea 
blocurilor cifrate, astfel cum este definit în standardul (ISO 
10116), cu un parametru intermediar  m = 1 și un vector de 
inițializare SV = ‘00’ {16}, adic ă 16 octeți cu valoarea 
binară 0. După caz, MSCA utilizeaz ă metoda de completare 
2 definită în (ISO 9797-1).  
CSM_110 Produc ătorul senzorului de mi șcare stocheaz ă cheia de 
asociere criptat ă și numărul de serie criptat în senzorul de 
mișcare destinat, împreun ă cu valorile de text în clar și cu 
numerele versiunilor cheilor K  M și K  ID utilizate pentru 
criptare.  
Notă: astfel cum s-a explicat în sec țiunea 9.2.1.2, poate fi 
necesar ca un produc ător de senzori de mi șcare să introducă 
mai multe chei de asociere criptate și mai multe numere de 
serie criptate într-un singur senzor de mi șcare.  
CSM_111 Pe lâng ă materialul criptografic bazat pe AES specificat în 
CSM_110, un produc ător de senzori de mi șcare poate stoca, 
de asemenea, în fiecare senzor de mi șcare materialul cripto ­
grafic bazat pe TDES specificat în cerin ța CSM_037 din 
partea A din prezentul apendice.  
Notă: acest lucru va permite cuplarea unui senzor de 
mișcare de a doua genera ție la o VU de prima genera ție. 
CSM_112 Lungimea cheii de sesiune K  S generate de o VU în timpul 
asocierii cu un senzor de mi șcare depinde de lungimea cheii 
sale K  M-VU  , astfel cum este precizat în CSM_50.  
9.2.1.2  Înlocuirea cheii master a senzorului de mi șcare din echipamentul de a 
doua genera ție. 
CSM_113 Fiecare cheie master a senzorului de mi șcare și toate cheile 
aferente (a se vedea tabelul 3) sunt asociate cu o genera ție 
specifică a perechii de chei r ădăcină a ERCA. Prin urmare, 
aceste chei se înlocuiesc o dat ă la 17 ani. Perioada de vala ­
bilitate a fiec ărei generații a cheii master a senzorului de 
mișcare începe cu un an înaintea începerii valabilit ății 
perechii de chei r ădăcină asociate a ERCA și se termin ă 
atunci când perechea de chei r ădăcină asociată a ERCA 
expiră. Acest fapt este descris în figura 2.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 397  
Figura 2  
Emiterea și utilizarea diferitelor genera ții ale cheii master a senzorului de mi șcare din unit ățile montate pe 
vehicule, din senzorii de mi șcare și din cardurile de atelier
  
CSM_114 Cu cel pu țin un an înainte de generarea unei noi perechi de 
chei rădăcină europene, astfel cum este descris în CSM_56, 
ERCA genereaz ă o nouă cheie master K  M a senzorului de 
mișcare prin generarea unor noi chei K  M-VU  și K  M-WC  . 
Lungimea cheii master a senzorului de mi șcare este legat ă 
de puterea prev ăzută a noii perechi de chei r ădăcină 
europene, în conformitate cu CSM_50. ERCA comunic ă 
noile chei K  M , K  M-VU  și K  M-WC  MSCA-urilor, la cererea 
acestora, împreun ă cu numărul lor de versiune respectiv.  
CSM_115 O MSCA se asigur ă că toate genera țiile valabile de chei K  M- 
WC sunt stocate pe fiecare card de atelier emis sub auto ­
ritatea acesteia, împreun ă cu numerele lor de versiune, 
astfel cum este prezentat în figura 2.  
Notă: aceasta implic ă faptul că, în ultimul an al perioadei de 
valabilitate a unui certificat ERCA, cardurile de atelier vor fi 
emise cu trei genera ții diferite de K  M-WC  , astfel cum este 
indicat în figura 2.  
CSM_116 În ceea ce prive ște procesul descris în CSM_107 și 
CSM_108 de mai sus: O MSCA cripteaz ă fiecare pereche 
de chei de asociere K  P pe care o prime ște de la un 
producător de senzori de mi șcare în mod separat cu 
fiecare genera ție valabilă a cheii master K  M a senzorului 
de mișcare. O MSCA cripteaz ă de asemenea fiecare num ăr 
de serie pe care îl prime ște de la un produc ător de senzori de 
mișcare în mod separat cu fiecare genera ție valabilă a cheii 
de identificare K  ID . Un produc ător de senzori de mi șcare 
stochează toate cript ările cheii de asociere și toate cript ările 
numărului de serie în senzorul de mi șcare destinat, împreun ă 
cu valorile de text în clar aferente și cu numărul (numerele) 
de versiune ale cheilor K  M și K  ID utilizate pentru criptare.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 398  
Notă: aceasta implic ă faptul că, în ultimul an al perioadei de 
valabilitate a unui certificat ERCA, senzorii de mi șcare vor 
fi livrați cu date criptate bazate pe trei genera ții diferite de 
K M , astfel cum este indicat în figura 2.  
CSM_117 În ceea ce prive ște procesul descris în CSM_107 de mai sus: 
Întrucât lungimea cheii de asociere K  P este legată de 
lungimea cheii K  M (a se vedea CSM_100), poate fi 
necesar ca un produc ător de senzori de mi șcare să 
genereze pân ă la trei perechi diferite de chei de asociere 
(de lungimi diferite) pentru un senzor de mi șcare, în cazul 
în care genera țiile ulterioare de chei K  M au lungimi diferite. 
În acest caz, produc ătorul trimite fiecare pereche de chei de 
asociere către MSCA. MSCA se asigur ă că fiecare cheie de 
asociere este criptat ă cu genera ția corectă a cheii master a 
senzorului de mi șcare, adică cu cea care are aceea și lungime.  
Notă: În cazul în care produc ătorul senzorului de mi șcare 
decide să genereze o cheie de asociere bazat ă pe TDES 
pentru un senzor de mi șcare de a doua genera ție (a se 
vedea CSM_111), produc ătorul îi indic ă MSCA-ului faptul 
că pentru criptarea acestei chei de asociere trebuie s ă fie 
utilizată cheia master bazat ă pe TDES a senzorului de 
mișcare. Acest lucru se datoreaz ă faptului c ă lungimea 
unei chei TDES poate s ă nu fie egal ă cu cea a unei chei 
AES și, prin urmare, MSCA nu poate trage o concluzie 
exclusiv pe baza lungimii cheii.  
CSM_118 Produc ătorii de unit ăți montate pe vehicule introduc doar o 
generație de K  M-VU  în fiecare unitate montat ă pe vehicul, 
împreună cu numărul versiunii acesteia. Aceast ă generație de 
K M-VU  este legată de certificatul ERCA pe care sunt bazate 
certificatele unit ăților montate pe vehicule.  
Note:  
— O unitate montat ă pe vehicul bazat ă pe certificatul 
ERCA din genera ția X conține doar cheia K  M-VU  din 
generația X, chiar dac ă a fost produs ă după începutul 
perioadei de valabilitate a certificatului ERCA din 
generația X+1 . Această situație este ilustrat ă în figura 2.  
— O VU din genera ția X nu poate fi asociat ă cu un senzor 
de mișcare din genera ția X-1 
— Întrucât cardurile de atelier au o perioad ă de valabilitate 
de un an, rezultatul CSM_113 – CSM_118 este c ă toate 
cardurile de atelier vor con ține noua cheie K  M-WC  la 
momentul producerii primei VU care con ține noua 
cheie K  M-VU  . Prin urmare, o astfel de VU va fi întot ­
deauna în m ăsură să calculeze noua cheie K  M . În plus, 
până la momentul respectiv, majoritatea noilor senzori de 
mișcare vor con ține date criptate bazate inclusiv pe noua 
cheie K  M . 
9.2.2  Chei pentru securizarea comunica țiilor specializate cu raz ă scurtă de 
acțiune (DSRC)  
9.2.2.1  Considera ții generale  
CSM_119 Autenticitatea și confidențialitatea datelor comunicate de la o 
unitate montat ă pe vehicul la o autoritate de control printr-un 
canal de comunicare la distan ță DSRC este asigurat ă prin 
intermediul unui set de chei AES specifice ale VU derivate 
dintr-o singur ă cheie master DSRC, și anume din cheia 
KM  DSRC  . ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 399  
CSM_120 Cheia master DSRC, KM  DSRC  , este o cheie AES generat ă, 
stocată și distribuit ă de ERCA în mod securizat. Lungimea 
cheii poate fi de 128,192 sau 256 de bi ți și este legat ă de 
lungimea perechii de chei r ădăcină europene, astfel cum este 
descris în CSM_50.  
CSM_121 ERCA comunic ă în mod securizat cheia master DSRC auto ­
rităților pentru certificate ale statelor membre, la cererea 
acestora, pentru a le permite s ă deriveze cheile DSRC 
specifice ale VU și pentru a se asigura c ă cheia master 
DSRC este introdus ă în toate cardurile de control și în 
toate cardurile de atelier emise sub responsabilitatea lor.  
CSM_122 ERCA atribuie fiec ărei chei master DSRC un num ăr unic de 
versiune. ERCA informeaz ă MSCA-urile cu privire la 
numărul versiunii în momentul în care le trimite cheia 
master DSRC.  
Notă: Numărul versiunii este utilizat pentru a face distinc ția 
între diferitele genera ții ale cheii master DSRC, astfel cum 
se explică în detaliu în sec țiunea 9.2.2.2.  
▼M1 
CSM_123 Pentru fiecare unitate montat ă pe vehicul, produc ătorul 
unității montate pe vehicul creeaz ă un număr de serie unic 
al VU și trimite acest num ăr autorității pentru certificate a 
statului său membru într-o cerere de ob ținere a unui set de 
două chei DSRC specifice pentru VU. Num ărul de serie al 
VU are tipul de date
  .  
Notă: 
— Acest num ăr de serie al VU este identic cu elementul 
vuSerialNumber al VuIdentification (a se vedea apen ­
dicele 1) și cu identificatorul de ținătorului certificatului 
din certificatele VU.  
— Numărul de serie al VU poate s ă nu fie cunoscut în 
momentul în care un produc ător de unit ăți montate pe 
vehicule solicit ă cheile DSRC specifice pentru VU. În 
acest caz, produc ătorul VU trimite, în schimb, ID-ul unic 
al cererii de certificat pe care l-a utilizat atunci când a 
solicitat certificatele VU; A se vedea CSM_153. Acest 
ID al cererii de certificat este, prin urmare, egal cu iden ­
tificatorul de ținătorului certificatului din certificatele VU.  
▼B 
CSM_124 La primirea unei cereri de chei DSRC specifice pentru VU, 
MSCA deriveaz ă două chei AES pentru unitatea montat ă pe 
vehicul, denumite K_VU  DSRC  _ENC și K_VU  DSRC  _MAC. 
Aceste chei specifice pentru VU trebuie s ă aibă lungimea 
egală cu cea a cheii master DSRC. MSCA utilizeaz ă funcția 
de derivare a cheilor definit ă în [RFC 5869]. Func ția hash  
necesară pentru a instan ția funcția HMAC-hash este legat ă 
de lungimea cheii master DSRC, astfel cum este precizat în 
CSM_50. Func ția de derivare a cheilor din standardul [RFC 
5869] este dup ă cum urmeaz ă: 
Etapa 1 (extragere)  
— PRK  = HMAC-Hash ( salt, IKM ), unde  salt  este un șir 
vid ‘’, iar  IKM  este KM  DSRC  . ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 400  
Etapa 2 (extindere)  
— OKM  = T(1) , unde  
T(1) = HMAC-Hash ( PRK , T(0)  || info  || ‘01’), cu  
— T (0)  = un șir vid (‘ ’),  
— ►M1 info  = numărul de serie al VU sau ID-ul 
cererii de certificat, astfel cum este specificat în 
CSM_123 ◄ 
— K_VU  DSRC  _ENC = primii  L octeți ai OKM  și 
K_VU  DSRC  _MAC = ultimii  L octeți ai OKM,  
unde  L este lungimea necesar ă a K_VU  DSRC  _ENC și a 
K_VU  DSRC  _MAC în octe ți. 
CSM_125 MSCA distribuie K_VU  DSRC  _ENC și K_VU  DSRC  _MAC 
producătorilor de VU într-un mod securizat pentru a fi 
introduse în unitatea montat ă pe vehicul c ăreia îi sunt 
destinate.  
CSM_126 La momentul producerii, o unitate montat ă pe vehicul are 
stocate în memoria sa securizat ă cheile K_VU  DSRC  _ENC și 
K_VU  DSRC  _MAC, pentru a putea asigura integritatea, auten ­
ticitatea și confidențialitatea datelor trimise prin canalul de 
comunicare la distan ță. O unitate montat ă pe vehicul 
stochează de asemenea cheia master DSRC utilizat ă pentru 
a deriva aceste chei specifice pentru VU.  
CSM_127 La momentul emiterii, cardurile de control și cardurile de 
atelier au stocate în memoria lor securizat ă cheia KM  DSRC  , 
pentru a putea verifica astfel integritatea și autenticitatea 
datelor trimise de o VU printr-un canal de comunicare la 
distanță și pentru a putea decripta datele respective. 
Cardurile de control și cardurile de atelier stocheaz ă de 
asemenea num ărul versiunii cheii master DSRC.  
Notă: astfel cum se explic ă în secțiunea 9.2.2.2, poate fi 
necesar ca mai multe genera ții de chei KM  DSRC  să fie 
introduse în acela și card de atelier sau în acela și card de 
control.  
▼M1 
CSM_128 MSCA ține eviden ța tuturor cheilor DSRC specifice pentru 
VU pe care le-a generat, a num ărului versiunii acestora și a 
numărului de serie al VU sau a ID-ului cererii de certificat 
folosite la derivarea lor.  
▼B 
9.2.2.2  Înlocuirea cheii master DSRC  
CSM_129 Fiecare cheie master DSRC este asociat ă cu o genera ție 
specifică a perechii de chei r ădăcină a ERCA. Prin 
urmare, ERCA înlocuie ște cheia master DSRC o dat ă la 
17 ani. Perioada de valabilitate a fiec ărei generații a cheii 
master DSRC începe cu doi ani înaintea începerii valabi ­
lității perechii de chei r ădăcină asociate a ERCA și se 
termină atunci când perechea de chei r ădăcină asociată a 
ERCA expir ă. Acest fapt este descris în figura 3.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 401  
Figura 3  
Emiterea și utilizarea diferitelor genera ții ale cheii master DSRC în unit ățile montate pe vehicule, în cardurile de 
atelier și în cardurile de control
  
CSM_130 Cu cel pu țin doi ani înainte de generarea unei noi perechi de 
chei rădăcină europene, astfel cum este descris în CSM_56, 
ERCA genereaz ă o nouă cheie master DSRC. Lungimea 
cheii master DSRC este legat ă de puterea prev ăzută a noii 
perechi de chei r ădăcină europene, în conformitate cu 
CSM_50. ERCA comunic ă noua cheie master DSRC 
MSCA-urilor, la cererea acestora, împreun ă cu numărul 
versiunii sale.  
CSM_131 O MSCA se asigur ă că toate genera țiile valabile ale cheii 
KM  DSRC  sunt stocate pe fiecare card de control emis sub 
autoritatea acesteia, împreun ă cu numerele versiunilor 
acestora, astfel cum este ilustrat în figura 3.  
Notă: aceasta implic ă faptul că, în ultimii doi ani ai 
perioadei de valabilitate a unui certificat ERCA, cardurile 
de control vor fi emise cu trei genera ții diferite ale cheii 
KM  DSRC  , astfel cum este indicat în figura 3.  
CSM_132 O MSCA se asigur ă că toate genera țiile cheii KM  DSRC  care 
au fost valabile pentru cel pu țin un an și sunt în continuare 
valabile sunt stocate pe fiecare card de atelier emis sub 
autoritatea acesteia, împreun ă cu numerele versiunilor 
acestora, astfel cum este ilustrat în figura 3.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 402  
Notă: aceasta implic ă faptul că, în ultimul an al perioadei de 
valabilitate a unui certificat ERCA, cardurile de atelier vor fi 
emise cu trei genera ții diferite ale KM  DSRC  , astfel cum este 
indicat în figura 3.  
CSM_133 Produc ătorii de unit ăți montate pe vehicule introduc doar un 
set de chei DSRC specifice pentru VU în fiecare unitate 
montată pe vehicul, împreun ă cu num ărul versiunii 
acestora. Acest set de chei este derivat din genera ția 
KM  DSRC  legată de certificatul ERCA pe care se bazeaz ă 
certificatele unit ăților montate pe vehicule.  
Note:  
— Acest lucru implic ă faptul că o unitate montat ă pe 
vehicul bazat ă pe certificatul ERCA din genera ția X 
conține doar cheile K_VU  DSRC  _ENC și 
K_VU  DSRC  _MAC din genera ția X, chiar dac ă VU a 
fost produs ă după începutul perioadei de valabilitate a 
certificatului ERCA din genera ția X+1 . Această situație 
este ilustrat ă în figura 3.  
— Deoarece perioada de valabilitate a cardurilor de atelier 
este de un an, iar a cardurilor de control este de doi ani, 
rezultatul CSM_131 – CSM_133 este c ă toate cardurile 
de atelier și toate cardurile de control vor con ține noua 
cheie master DSRC la momentul în care va fi emis ă 
prima VU con ținând chei specifice pentru VU bazate 
pe cheia master respectiv ă. 
9.3. Certificate  
9.3.1  Considera ții generale  
CSM_134 Toate certificatele din sistemul european de tahografe inte ­
ligente se pot autodescrie și sunt verificabile cu ajutorul 
cardurilor (CV), în conformitate cu (ISO 7816-4) și (ISO 
7816-8).  
CSM_135  ►M1 Regulile de codificare distincte (DER), în confor ­
mitate cu [ISO 8825-1] sunt utilizate pentru codificarea 
obiectelor de date în cadrul certificatelor. Tabelul 4 
prezintă codarea complet ă a certificatului, inclusiv to ți 
octeții de etichetare și de lungime. ◄ 
Notă: această codificare are ca rezultat o structur ă de tip 
„valoarea lungimii etichetei” (TLV) dup ă cum urmeaz ă: 
Etichetă: Eticheta este codificat ă în unul sau doi octe ți și 
indică conținutul.  
Lungime: Lungimea este codificat ă ca un întreg nesemnat în 
unul, doi sau trei octe ți, ducând la o lungime 
maximă de 65 535 de octe ți. Se utilizeaz ă 
numărul minim de octe ți. 
Valoare: Valoarea este codificat ă în zero sau mai mul ți 
octeți. 
9.3.2  Conținutul certificatelor  
CSM_136 Toate certificatele au structura prezentat ă în profilul de 
certificat din tabelul 4.  
Tabelul 4  
Profil de certificat versiunea 1  
Câmp  ID-ul 
câmpului  Etichetă Lungime (octe ți) Tip de date ASN. 1 
(a se vedea apendicele 1)  
Certificat ECC  C  ‘7F 21‘  var  
Corpul certificatului 
ECC  B ‘7F 4E‘  var  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 403  
Câmp  ID-ul 
câmpului  Etichetă Lungime (octe ți) Tip de date ASN. 1 
(a se vedea apendicele 1)  
Identificator de profil 
al certificatului  CPI ‘5F 29‘  ‘01‘
  
Identificatorul auto ­
rității pentru certi ­
ficate  CAR  ‘42‘  ‘08‘
  
Autorizația 
deținătorului certifi ­
catului  CHA  ‘5F 4C‘  ‘07‘
  
Cheie public ă PK  ‘7F 49‘  var  
Parametrii de 
domeniu  DP ‘06‘  var
  
Punct public  PP  ‘86‘  var
  
Identificatorul 
deținătorului certifi ­
catului  CHR  ‘5F 20‘  ‘08‘
  
Data de începere a 
valabilității certifica ­
tului CEfD  ‘5F 25‘  ‘04‘
  
Data expir ării certifi­
catului  CExD  ‘5F 24‘  ‘04‘
  
Semnătura certifi ­
catului ECC  S ‘5F 37‘  var
  
Notă: ID-ul câmpului va fi utilizat în sec țiuni ulterioare ale 
prezentului apendice pentru a indica câmpurile individuale 
ale unui certificat; de exemplu, X.CAR este identificatorul 
autorității pentru certificate men ționat în certificatul utiliza ­
torului X.  
9.3.2.1 Identificator de profil al certificatului  
CSM_137 Certificatele utilizeaz ă un identificator de profil al certifi ­
catului pentru a indica profilul certificatului utilizat. 
Versiunea 1, astfel cum este specificat în tabelul 4, este 
identificată de o valoare ‘00’.  
9.3.2.2 Identificatorul autorit ății pentru certificate  
CSM_138 Identificatorul autorit ății pentru certificate se folose ște pentru 
identificarea cheii publice care trebuie utilizat ă pentru veri ­
ficarea semn ăturii unui certificat. Prin urmare, identificatorul 
autorității pentru certificate este egal cu identificatorul 
deținătorului certificatului în certificatul autorit ății aferente 
pentru certificate.  
CSM_139 Un certificat r ădăcină al ERCA este autosemnat, adic ă iden­
tificatorul autorit ății pentru certificate este egal cu identifi ­
catorul deținătorului certificatului în certificat.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 404  
CSM_140 În cazul unui certificat de leg ătură al ERCA, identificatorul 
deținătorului certificatului (CHR) este egal cu CHR al noului 
certificat rădăcină al ERCA. Identificatorul autorit ății pentru 
certificate în cazul unui certificat de leg ătură este egal cu 
CHR al certificatului r ădăcină anterior al ERCA.  
9.3.2.3 Autoriza ția deținătorului certificatului  
▼M1 
CSM_141 Autoriza ția deținătorului certificatului este folosit ă pentru a 
identifica tipul de certificat. Aceasta este format ă din cei mai 
semnificativi șase octeți ai ID-ului aplica ției tahografice, 
concatenați cu tipul de echipament, care indic ă tipul de 
echipament c ăruia îi este destinat certificatul. În cazul unui 
certificat VU, al unui certificat de card de conduc ător auto 
sau al unui certificat de card de atelier, tipul de echipament 
este, de asemenea, utilizat pentru a face diferen ța între un 
certificat pentru autentificare reciproc ă și un certificat pentru 
crearea semn ăturilor digitale (a se vedea sec țiunea 9.1 și 
apendicele 1, tipul de date EquipmentType).  
▼B 
9.3.2.4 Cheie public ă 
Cheia public ă imbrică două elemente de date: parametrii de domeniu 
standardiza ți care urmeaz ă să fie utiliza ți cu cheia public ă în certificat 
și valoarea punctului public.  
CSM_142 Elementul de date  Domain Parameters  conține unul dintre 
identificatorii de obiect specifica ți în tabelul 1 pentru a face 
trimitere la un set de parametri de domeniu standardiza ți. 
CSM_143 Elementul de date  Public Point  conține punctul public. 
Punctele publice pe baz ă de curbe eliptice sunt transformate 
în șiruri de octe ți, astfel cum este precizat în (TR-03111). Se 
utilizează formatul de codificare necomprimat. La recu ­
perarea unui punct bazat pe curbe eliptice din formatul s ău 
codificat, se efectueaz ă întotdeauna valid ările descrise în 
(TR-03111).  
9.3.2.5 Identificatorul de ținătorului certificatului  
CSM_144 Identificatorul de ținătorului certificatului este un identificator 
pentru cheia public ă furnizată în certificat. El este utilizat 
pentru a face trimitere la aceast ă cheie public ă în alte certi ­
ficate.  
CSM_145 În cazul certificatelor de card și al certificatelor de echi ­
pament GNSS extern, identificatorul de ținătorului certifi ­
catului are tipul de date
  
specificat în apendicele 1.  
CSM_146 În cazul unit ăților montate pe vehicul, în momentul în care 
producătorul solicit ă un certificat, acesta poate s ă știe sau 
poate să nu știe numărul de serie, specific produc ătorului, al 
VU căreia îi sunt destinate certificatul respectiv și cheia 
privată asociată. În primul caz, identificatorul de ținătorului 
certificatului are tipul de date
  
specificat în apendicele 1. În al doilea caz, identifica- 
torul deținătorului certificatului are tipul de date
  
specificat în apendicele 1.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 405  
Notă: Pentru un certificat de card, valoarea CHR este egal ă 
cu valoarea cardExtendedSerialNumber în EF_ICC; a se 
vedea apendicele 2. Pentru un certificat EGF, valoarea 
CHR este egal ă cu valoarea sensorGNSSSerialNumber în 
EF_ICC; a se vedea apendicele 14. Pentru un certificat 
VU, valoarea CHR este egal ă cu elementul vuSerialNumber 
din VuIdentification, a se vedea apendicele 1, cu excep ția 
cazului în care produc ătorul nu cunoa ște numărul de serie 
specific produc ătorului în momentul în care se solicit ă certi­
ficatul.  
▼B 
CSM_147 În cazul certificatelor ERCA și MSCA, identifica- 
torul deținătorului certificatului are tipul de date
  
specificat în apen ­
dicele 1.  
9.3.2.6 Data de începere a valabilit ății certificatului  
▼M1 
CSM_148 Data de începere a valabilit ății certificatului indic ă data și 
ora la care certificatul intr ă în perioada de valabilitate.  
▼B 
9.3.2.7 Data expir ării certificatului  
CSM_149 Data expir ării certificatului indic ă data și ora de la care 
certificatul nu mai este valabil.  
9.3.2.8 Semn ătura de pe certificat  
CSM_150 Semn ătura de pe certificat este creat ă prin intermediul 
corpului codificat al certificatului, inclusiv eticheta și 
lungimea corpului certificatului. Algoritmul semn ăturii este 
ECDSA, astfel cum este precizat în [DSS], folosindu-se 
algoritmul de  hashing  legat de m ărimea cheii autorit ății cu 
drept de semn ătură, astfel cum este specificat în CSM_50. 
Formatul semn ăturii este simplu, astfel cum este precizat în 
(TR-03111).  
9.3.3  Solicitarea de certificate  
CSM_151  ►M1 Atunci când solicit ă un certificat, o MSCA trebuie s ă 
transmită următoarele date c ătre ERCA: ◄ 
— Identificatorul de profil al certificatului solicitat  
— Referin ța autorității pentru certificate care se preco ­
nizează a fi utilizat ă pentru semnarea certificatului.  
— Cheia public ă care urmeaz ă să fie semnat ă 
CSM_152 Pe lâng ă datele din CSM_151, o MSCA trimite c ătre ERCA 
următoarele date în cadrul unei cereri de certificat, permi țând 
ERCA să creeze identificatorul de ținătorului certificatului 
pentru noul certificat MSCA:  
— Codul numeric na țional al autorit ății de certificare (tip de 
date
 definit în apendicele 1)  
— Codul alfanumeric na țional al autorit ății de certificare 
(tip de date
  definit în apendicele 1)  
— Numărul de serie de 1 octet pentru a face distinc ția între 
diferitele chei ale autorit ății de certificare în cazul în care 
aceste chei sunt modificate.  
— Câmpul de doi octe ți care con ține informa ții supli­
mentare specifice privind autoritatea de certificare.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 406  
CSM_153 Un produc ător de echipamente trimite c ătre MSCA urm ă­
toarele date în cadrul unei cereri de certificat, permi țând 
MSCA să creeze identificatorul de ținătorului certificatului 
pentru noul certificat de echipament:  
— Dacă este cunoscut (a se vedea CSM_154), un num ăr de 
serie al echipamentului, asociat în mod unic produc ăto­
rului, precum și tipul echipamentului și luna în care 
acesta a fost produs. În caz contrar, un identificator 
unic asociat cererii de certificat.  
— Luna și anul de produc ție a echipamentelor sau ale 
cererii de certificat.  
Producătorul trebuie s ă se asigure c ă aceste date sunt corecte și că 
certificatul transmis înapoi de c ătre MSCA este introdus în echipamentul 
căruia îi este destinat.  
▼B 
CSM_154 În cazul unei VU, în momentul în care produc ătorul solicit ă 
un certificat, acesta poate s ă știe sau poate s ă nu știe 
numărul de serie, specific produc ătorului, al VU c ăreia îi 
sunt destinate certificatul respectiv și cheia privat ă 
asociată. În primul caz, produc ătorul unității montate pe 
vehicul trimite acest num ăr de serie c ătre MSCA. În cel 
de al doilea caz, produc ătorul trebuie s ă identifice în mod 
unic fiecare cerere de certificat și să trimită către MSCA 
numărul de serie al acestei cererii de certificat. Certificatul 
astfel obținut va con ține prin urmare num ărul de serie al 
cererii de certificat. Dup ă introducerea certificatului într-o 
VU specific ă, producătorul îi comunic ă MSCA leg ătura 
dintre num ărul de serie al cererii de certificat și identificarea 
VU. 
10. AUTENTIFICAREA RECIPROC Ă ȘI MESAGERIA SECURIZAT Ă 
ÎNTRE VU ȘI CARDURI  
10.1.  Considera ții generale  
CSM_155 La un nivel înalt, comunicarea securizat ă între o unitate 
montată pe vehicul și un card de tahograf se bazeaz ă pe 
următoarele etape:  
— În prima etap ă, fiecare parte îi demonstreaz ă celeilalte 
părți că deține un certificat de cheie public ă, semnat de 
către autoritatea pentru certificate a unui stat membru. La 
rândul său, certificatul de cheie public ă al MSCA trebuie 
să fie semnat de Autoritatea european ă pentru certifi ­
catele rădăcină. Această etapă se nume ște verificarea 
lanțului de certificate și este descris ă în detaliu în 
secțiunea 10.2.  
— În a doua etap ă, unitatea montat ă pe vehicul îi demons ­
trează cardului c ă este în posesia cheii private aferente 
cheii publice din certificatul prezentat. Acest lucru se 
realizează prin semnarea unui num ăr aleatoriu trimis de 
card. Cardul verific ă semnătura prin intermediul 
numărului aleatoriu. În cazul în care aceast ă verificare 
are un rezultat pozitiv, VU este autentificat ă. Această 
etapă se numește autentificarea VU și este descris ă în 
detaliu în sec țiunea 10.3.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 407  
— În a treia etap ă, ambele p ărți, în mod independent, 
calculează două chei de sesiune AES utilizând un 
algoritm asimetric de în țelegere asupra cheii. Utilizând 
una dintre aceste chei de sesiune, cardul creeaz ă un cod 
de autentificare a mesajelor (MAC) prin intermediul 
unor date trimise de VU. VU verific ă MAC. În cazul 
în care aceast ă verificare are un rezultat pozitiv, cardul 
este autentificat. Aceast ă etapă se numește autentificarea 
cardului și este descris ă în detaliu în sec țiunea 10.4.  
— În a patra etap ă, VU și cardul utilizeaz ă cheile de 
sesiune convenite pentru a asigura confiden țialitatea, 
integritatea și autenticitatea tuturor mesajelor schimbate. 
Aceasta se nume ște mesageria securizat ă și este descris ă 
în detaliu în sec țiunea 10.5.  
CSM_156 Mecanismul descris în CSM_155 este declan șat de unitatea 
montată pe vehicul ori de câte ori se introduce un card într- 
unul dintre sloturile sale pentru carduri.  
10.2.  Verificarea reciproc ă a lanțului de certificate  
10.2.1  Verificarea lan țului de certificate de c ătre VU  
CSM_157  ►M1 Unitățile montatepe vehicul utilizeaz ă protocolul 
descris în figura 4 pentru a verifica lan țul de certificate al 
unui card de tahograf. Pentru fiecare certificat citit de pe 
card, VU verific ă dacă este corect câmpul privind autoriza ția 
deținătorului certificatului (CHA):  
— câmpul CHA al certificatului de card indic ă un certificat 
de card pentru autentificare reciproc ă (a se vedea apen ­
dicele 1, tipul de date EquipmentType).  
— CHA al certificatului Card.CA indic ă o MSCA.  
— CHA al certificatului Card.Link indic ă ERCA. ◄ 
Note la figura 4:  
— Certificatele de card și cheile publice men ționate în 
figură sunt cele utilizate pentru autentificarea reciproc ă. 
Acestea sunt indicate în sec țiunea 9.1.5 ca fiind 
Card_MA.  
— Certificatele și cheile publice Card.CA men ționate în 
figură sunt cele utilizate pentru semnarea certificatelor 
de card și sunt indicate în CAR al certificatului de 
card. Acestea sunt indicate în sec țiunea 9.1.3 ca fiind 
MSCA_Card.  
— Certificatul Card.CA.EUR men ționat în figur ă este certi­
ficatul rădăcină european precizat în CAR al certifi ­
catului Card.CA.  
— Certificatul Card.Link men ționat în figur ă este certi ­
ficatul de leg ătură al cardului, dac ă acesta exist ă. 
Astfel cum este specificat în sec țiunea 9.1.2, acesta 
este un certificat de leg ătură pentru o nou ă pereche de 
chei rădăcină europene create de ERCA și semnate de 
cheia privat ă europeană anterioară. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 408  
— Certificatul Card.Link.EUR este certificatul r ădăcină 
european precizat în CAR al certificatului Card.Link.  
CSM_158 A șa cum se arat ă în figura 4, verificarea lan țului de certi ­
ficate al cardului începe la introducerea cardului. Unitatea 
montată pe vehicul cite ște identificatorul titularului cardului 
(
 ) din EF ICC VU 
verifică dacă cunoaște cardul, și anume, dac ă verificarea 
lanțului de certificate efectuat ă anterior de c ătre VU 
respectivă a avut un rezultat pozitiv și dacă lanțul în cauză 
a fost stocat pentru consultare viitoare. Dac ă rezultatul veri ­
ficării a fost pozitiv și dacă certificatul de card este înc ă 
valabil, procesul continu ă cu verificarea lan țului de certi ­
ficate ale VU. În caz contrar, VU cite ște de pe card, în 
mod succesiv, certificatul MSCA_Card necesar pentru a 
verifica certificatul de card (certificatul Card_CA). Certi ­
ficatul EUR necesar pentru a verifica certificatul 
MSCA_Card, precum și, eventual, certificatul de leg ătură, 
până ce găsește un certificat pe care îl cunoa ște sau pe 
care îl poate verifica. În cazul în care este g ăsit un certificat, 
VU utilizeaz ă certificatul respectiv pentru a verifica certifi ­
catele de card subiacente pe care le-a citit de pe card. În 
cazul în care rezultatele sunt pozitive, procesul continu ă cu 
verificarea lan țului de certificate ale VU. În cazul în care 
rezultatele sunt negative, VU ignor ă cardul.  
Notă: Există trei moduri în care VU poate cunoa ște certi­
ficatul Card.CA.EUR:  
— certificatul Card.CA.EUR este acela și certificat ca certi ­
ficatul EUR al VU;  
— certificatul Card.CA.EUR precede certificatul EUR al 
VU, iar VU con ținea deja acest certificat la emitere (a 
se vedea CSM_81);  
— certificatul Card.CA.EUR este emis ulterior certificatului 
EUR al VU, iar VU a primit anterior un certificat de 
legătură de la un alt card de tahograf, l-a verificat și l-a 
stocat pentru consultare viitoare.  
CSM_159 Astfel cum este indicat în figura 4, dup ă ce VU a verificat 
autenticitatea și valabilitatea unui certificat care era necu ­
noscut anterior, aceasta poate stoca certificatul respectiv 
pentru consultare viitoare nemaifiind necesar, prin urmare, 
ca VU să verifice înc ă o dată autenticitatea certificatului 
respectiv dac ă acesta este prezentat din nou unit ății 
montate pe vehicul. În loc de a stoca întregul certificat, o 
VU poate alege s ă stocheze numai con ținuturile corpului 
certificatului, astfel cum se specific ă în secțiunea 9.3.2.  
►M1 Stocarea tuturor celorlalte tipuri de certificat este 
facultativă, însă este obligatoriu ca o VU s ă stocheze un 
nou certificat de leg ătură prezentat de un card. ◄ 
CSM_160 VU verific ă valabilitatea temporal ă a oricărui certificat, citit ă 
de pe card sau stocat ă în memoria sa, și respinge certifi ­
catele expirate. Pentru a verifica valabilitatea temporal ă a 
unui certificat prezentat de card, o VU î și utilizează ceasul 
intern.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 409  
Figura 4  
Protocol pentru verificarea lan țului de certificate de card de c ătre VU
  
10.2.2  Verificarea lan țului de certificate ale VU de c ătre card  
CSM_161  ►M1 Cardurile de tahograf utilizeaz ă protocolul descris în 
figura 5 pentru a verifica lan țul de certificate al unei VU. 
Pentru fiecare certificat prezentat de VU, cardul verific ă 
dacă este corect câmpul privind autoriza ția deținătorului 
certificatului (CHA):  
— CHA al certificatului VU.Link indic ă ERCA.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 410  
— CHA al certificatului VU.CA indic ă o MSCA.  
— Câmpul CHA al certificatului VU indic ă un certificat 
VU pentru autentificare reciproc ă (a se vedea apendicele 
1, tipul de date EquipmentType). ◄ 
Figura 5  
Protocol pentru verificarea lan țului de certificate ale VU de c ătre card
  
Note la figura 5:  
— Certificatele VU și cheile publice men ționate în figur ă sunt cele 
utilizate pentru autentificarea reciproc ă. Acestea sunt indicate în 
secțiunea 9.1.4 ca fiind VU_Card.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 411  
— Certificatele și cheile publice VU.CA men ționate în figur ă sunt cele 
utilizate pentru semnarea certificatelor VU și ale echipamentelor 
GNSS externe. Acestea sunt indicate în sec țiunea 9.1.3 ca fiind 
MSCA_VU-EGF.  
— Certificatul VU.CA.EUR men ționat în figur ă este certificatul r ădăcină 
european precizat în CAR al certificatului VU.CA.  
— Certificatul VU.Link men ționat în figur ă este certificatul de leg ătură 
al VU, dac ă acesta exist ă. Astfel cum este specificat în sec țiunea 
9.1.2, acesta este un certificat de leg ătură pentru o nou ă pereche de 
chei rădăcină europene create de ERCA și semnate de cheia 
europeană anterioară. 
— Certificatul VU.Link.EUR este certificatul r ădăcină european precizat 
în CAR al certificatului VU.Link.  
CSM_162 Astfel cum se indic ă în figura 5, verificarea lan țului de 
certificate ale unit ății montate pe vehicul începe cu 
încercarea unit ății montate pe vehicul de a- și stabili 
propria cheie public ă pentru a fi utilizat ă în cardul de 
tahograf. Dac ă această încercare se concretizeaz ă, 
înseamnă că lanțul de certificate ale VU a fost verificat cu 
succes de c ătre card, acesta din urm ă stocând certificatul 
VU pentru consultare ulterioar ă. În acest caz, certificatul 
VU este preg ătit pentru utilizare, iar procesul continu ă cu 
autentificarea VU. În cazul în care cardul nu cunoa ște certi­
ficatul VU, VU prezint ă în mod succesiv certificatul VU.CA 
care trebuie folosit pentru verificarea certificatului s ău VU, 
certificatul VU.CA.EUR care trebuie folosit pentru veri ­
ficarea certificatului VU.CA, precum și, eventual, certi ­
ficatul de leg ătură, în scopul de a g ăsi un certificat 
cunoscut sau verificabil de c ătre card. În cazul în care 
este găsit un astfel de certificat, cardul utilizeaz ă certificatul 
respectiv pentru a verifica certificatele VU subiacente care i- 
au fost prezentate. Dac ă verificarea are un rezultat pozitiv, 
VU își stabilește în final cheia public ă necesară pentru 
utilizarea în cardul de tahograf. În cazul în care rezultatele 
verificării sunt negative, VU ignor ă cardul.  
Notă: Există trei moduri prin care cardul poate cunoa ște 
certificatul VU.CA.EUR:  
— certificatul VU.CA.EUR este acela și certificat ca certi ­
ficatul EUR al cardului;  
— certificatul VU.CA.EUR precede certificatul EUR al 
cardului, iar cardul con ținea deja acest certificat la 
emitere (a se vedea CSM_91);  
— certificatul VU.CAR.EUR este emis ulterior emiterii 
certificatului EUR al cardului, iar cardul a primit 
anterior un certificat de leg ătură de la o alt ă unitate 
montată pe vehicul, l-a verificat și l-a stocat pentru 
consultare viitoare.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 412  
CSM_163 VU folose ște comanda MSE: Set AT pentru a- și stabili 
cheia public ă care urmeaz ă a fi utilizat ă în cardul de 
tahograf. Astfel cum se specific ă în apendicele 2, aceast ă 
comandă conține o indica ție a mecanismului criptografic 
care va fi utilizat cu cheia stabilit ă. Acest mecanism este 
denumit în continuare „Autentificarea VU utilizând algo ­
ritmul ECDSA, în combina ție cu algoritmul de  hashing  
legat de m ărimea cheilor din perechea de chei VU_MA a 
VU, astfel cum este specificat în CSM_50”.  
CSM_164 Comanda MSE: Set AT con ține de asemenea o indica ție 
privind perechea de chei efemere pe care le va utiliza VU 
în timpul în țelegerii asupra cheilor de sesiune (a se vedea 
secțiunea 10.4). Prin urmare, înainte de a lansa comanda 
MSE: Set AT, VU genereaz ă o pereche de chei ECC 
efemere. Pentru generarea perechii de chei efemere, VU 
utilizează parametrii de domeniu standardiza ți indicați în 
certificatul de card. Perechea de chei efemer ă se noteaz ă 
astfel: (VU.SK  eph , VU.PK  eph , Card.DP). VU utilizeaz ă coor­
donata x a punctului public efemer ECDH ca identificator al 
cheii; aceasta este denumit ă reprezentarea comprimat ă a 
cheii publice și este notat ă astfel: Comp(VU.PK  eph ). 
▼M1 
CSM_165 În cazul în care comanda MSE: Set AT func ționează corect, 
cardul stabile ște cheia VU.PK indicat ă pentru a o utiliza 
ulterior în timpul autentific ării vehiculului și stocheaz ă 
temporar Comp(VU.PKeph). În cazul în care dou ă sau 
mai mult comenzi MSE: Set AT sunt lansate înaintea 
stabilirii cheilor de sesiune, cardul stocheaz ă doar ultima 
Comp(VU.PKeph) primit ă. Cardul reseteaz ă 
Comp(VU.PKeph) dup ă o comand ă GENERAL AUTHEN ­
TICATE executat ă cu succes.  
▼B 
CSM_166 Cardul verific ă valabilitatea temporal ă a oricărui certificat 
prezentat de VU sau men ționat de VU la momentul 
stocării în memoria cardului și respinge certificatele 
expirate.  
CSM_167 Pentru a verifica valabilitatea temporal ă a unui certificat 
prezentat de VU, fiecare card de tahograf stocheaz ă intern 
anumite date care reprezint ă ora curent ă. Aceste date nu 
sunt actualizate direct de c ătre o VU. La momentul 
emiterii, ora curent ă a cardului este reglat ă pentru a fi 
egală cu momentul la care începe valabilitatea certificatului 
Card_MA al cardului. Un card î și actualizeaz ă ora curent ă 
dacă momentul la care începe valabilitatea unui certificat 
autentic de tip „surs ă valabilă de indicare a orei” prezentat 
de o VU este mai recent decât ora curent ă a cardului. În 
acest caz, cardul î și reglează ora curent ă pentru a fi identic ă 
cu momentul la care începe valabilitatea certificatului 
respectiv. Cardul accept ă doar urm ătoarele certificate ca 
sursă valabilă de indicare a orei:  
— Certificatele de leg ătură ERCA de a doua genera ție 
— Certificatele MSCA de a doua genera ție 
— Certificatele VU de a doua genera ție emise de aceea și 
țară care a emis certificatul (certificatele) de card al(e) 
cardului.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 413  
Notă: ultima cerin ță implică faptul că un card este în 
măsură să recunoasc ă CAR al certificatului VU, adic ă certi­
ficatul MSCA_VU-EGF. CAR recunoscut nu va fi acela și 
precum CAR al propriului certificat, care este certificatul 
MSCA_Card.  
CSM_168 Astfel cum este indicat în figura 5, dup ă ce cardul a 
verificat autenticitatea și valabilitatea unui certificat care 
era necunoscut anterior, acesta poate stoca certificatul 
respectiv pentru consultare viitoare, astfel încât cardul nu 
mai trebuie s ă verifice înc ă o dată autenticitatea certifi ­
catului respectiv dac ă acesta este prezentat din nou 
cardului. În loc de a stoca întregul certificat, un card 
poate alege s ă stocheze numai con ținuturile corpului certi ­
ficatului, astfel cum se specific ă în secțiunea 9.3.2.  
10.3.  Autentificarea VU  
CSM_169 Unit ățile montate pe vehicule și cardurile utilizeaz ă 
protocolul de autentificare descris în figura 6 pentru a auten ­
tifica VU în raport cu cardul. Autentificarea VU permite 
cardului de tahograf s ă verifice în mod explicit c ă VU 
este autentic ă. În acest sens, VU î și utilizeaz ă cheia 
privată pentru a semna date de provocare generate de card.  
CSM_170  ►M1 Alături de datele de provocare ale cardului, VU 
include în semn ătură identificatorul de ținătorului certifi ­
catului obținut din certificatul de card. ◄ 
Notă: Astfel este garantat faptul c ă acest card în raport cu 
care se autentific ă VU este acela și card al c ărui lanț de 
certificate a fost verificat anterior de c ătre VU.  
CSM_171 VU include, de asemenea, în semn ătură, identificatorul cheii 
publice efemere Comp(VU.PK  eph ), utilizate de VU pentru a 
stabili mesageria securizat ă în timpul procesului de autenti ­
ficare a cipului, specificat ă în secțiunea 10.4.  
Notă: Acest lucru asigur ă faptul că VU cu care comunic ă 
un card în timpul sesiunii de mesagerie securizat ă este 
aceeași VU care a fost autentificat ă de card.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 414  
Figura 6  
Protocolul de autentificare a VU
  
▼B 
CSM_172 În cazul în care mai multe comenzi GET CHALLENGE 
sunt trimise de VU în timpul autentific ării VU, cardul 
trimite de fiecare dat ă înapoi noi date de provocare 
aleatorii de 8 octe ți, dar stocheaz ă doar ultimele date de 
provocare.  
CSM_173 Algoritmul de semnare utilizat de VU pentru autentificarea 
VU este ECDSA, astfel cum este precizat în [DSS], folo ­
sindu-se algoritmul de  hashing  legat de m ărimea cheilor din 
perechea de chei VU_MA a VU, astfel cum este specificat 
în CSM_50. Formatul semn ăturii este simplu, astfel cum 
este precizat în (TR-03111). VU trimite cardului 
semnătura rezultat ă. 
▼M1 
CSM_174 La primirea semn ăturii VU într-o comand ă EXTERNAL 
AUTHENTICATE, cardul  
— calculeaz ă tokenul de autentificare prin concatenarea 
Card.CHR, a datelor de provocare rcard a cardului și 
a identificatorului cheii publice efemere a VU, 
Comp(VU.PKeph),  
— verifică semnătura VU utilizând algoritmul ECDSA, 
utilizând algoritmul de hashing legat de m ărimea 
cheilor din perechea de chei VU_MA a VU, astfel 
cum este specificat în CSM_50, în combina ție cu 
VU.PK și tokenul de autentificare calculat.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 415  
10.4.  Autentificarea cipului și înțelegerea asupra cheilor de sesiune  
CSM_175 Unit ățile montate pe vehicule și cardurile utilizeaz ă 
protocolul de autentificare a cipului descris în  figura 7  
pentru a autentifica cardul în raport cu VU. Autentificarea 
cipului permite unit ății montate pe vehicul s ă verifice în 
mod explicit autenticitatea cardului.  
Figura 7  
Autentificarea cipului și înțelegerea asupra cheilor de sesiune
  
CSM_176 VU și cardul parcurg urm ătoarele etape:  
1. Unitatea montat ă pe vehicul ini țiază procesul de autenti ­
ficare a cipului prin lansarea comenzii MSE: Set AT, 
care indică „Autentificare a cipului utilizând algoritmul 
ECDH rezultând într-o lungime a cheii de sesiune legat ă 
de mărimea cheilor din perechea de chei Card_MA a 
cardului, astfel cum este specificat în CSM_50”. VU 
determină mărimea cheilor din perechea de chei a 
cardului pe baza certificatului de card.  
▼M1 
2. VU trimite cardului punctul public VU.PK  eph al perechii 
sale de chei efemere. Punctul public este convertit într-un 
șir de octeți, astfel cum este precizat în [TR-03111]. Se 
utilizează formatul de codificare necomprimat. Astfel 
cum a fost explicat în CSM_164, VU a generat aceast ă 
pereche de chei efemere anterior verific ării lanțului de 
certificate ale VU. VU a trimis cardului identificatorul 
cheii publice efemere Comp(VU.PK  eph ), iar cardul l-a 
stocat.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 416  
3. Cardul calculeaz ă Comp(VU.PK  eph ) pe baza VU.PK  eph și 
îl compară cu valoarea stocat ă a Comp(VU.PK  eph ). 
4. Utilizând algoritmul ECDH în combina ție cu cheia 
privată statică a cardului și cu cheia public ă efemeră a 
VU, cardul calculeaz ă o cheie K secret ă. 
5. Cardul alege o cheie de unic ă folosință aleatorie de 8 
octeți, N  PICC , și o utilizeaz ă pentru a deriva dou ă chei de 
sesiune AES, K  MAC și K  ENC , pe baza cheii K. A se 
vedea CSM_179.  
▼M1 
6. Utilizând K  MAC , cardul calculeaz ă un token de autenti ­
ficare prin intermediul punctului public efemer al VU: 
T PICC = CMAC(K  MAC , VU.PK  eph ). Punctul public 
trebuie să fie în formatul utilizat de VU (a se vedea 
punctul 2 de mai sus). Cardul trimite N  PICC și T  PICC 
unității montate pe vehicul.  
▼B 
7. Utilizând algoritmul ECDH în combina ție cu cheia 
privată statică a cardului și cu cheia public ă efemeră a 
VU, VU calculeaz ă aceeași cheie secret ă K calculat ă de 
card în etapa 4.  
8. VU deriveaz ă cheile de sesiune K  MAC și K  ENC pe baza 
cheilor K și N  PICC ; A se vedea CSM_179.  
9. VU verific ă autenticitatea tokenului T  PICC . 
CSM_177 În etapa 3 de mai sus, cardul calculeaz ă Comp(VU.PKeph) 
drept coordonata x a punctului public în VU.PKeph.  
CSM_178 În etapele 4 și 7 de mai sus, cardul și unitatea montat ă pe 
vehicul utilizeaz ă algoritmul ECKA-EG astfel cum este 
definit în (TR-03111).  
CSM_179 În etapele 5 și 8 de mai sus, cardul și unitatea montat ă pe 
vehicul utilizeaz ă funcția de derivare a cheilor pentru cheile 
de sesiune AES definite în (TR-03111), cu urm ătoarele 
precizii și modificări: 
— Valoarea contorului este ‘00 00 00 01’ pentru K  ENC și 
‘00 00 00 02’ pentru K  MAC.  
— Cheia op țională de unică folosință r este utilizat ă și este 
egală cu N  PICC . 
— Pentru cheile AES derivate de 128 de bi ți, algoritmul de  
hashing  care trebuie utilizat este SHA-256.  
— Pentru cheile AES derivate de 192 de bi ți, algoritmul de  
hashing  care trebuie utilizat este SHA-384.  
— Pentru cheile AES derivate de 256 de bi ți, algoritmul de  
hashing  care trebuie utilizat este SHA-512.  
Lungimea cheilor de sesiune (adic ă lungimea la care 
valoarea  hash  este trunchiat ă) este legat ă de mărimea 
perechii de chei Card_MA, astfel cum este specificat în 
CSM_50.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 417  
CSM_180 În etapele 6 și 9 de mai sus, cardul și unitatea montat ă pe 
vehicul utilizeaz ă algoritmul AES în modul CMAC, astfel 
cum este definit în [SP 800-38B]. Lungimea T  PIC este legată 
de lungimea cheilor de sesiune AES, astfel cum este 
specificat în CSM_50.  
10.5.  Mesagerie securizat ă 
10.5.1  Considera ții generale  
CSM_181 Toate comenzile și toate răspunsurile schimbate între o 
unitate montat ă pe vehicul și un card de tahograf dup ă 
confirmarea autenticit ății cipului și până la sfârșitul 
sesiunii sunt protejate prin mesageria securizat ă. 
CSM_182 Cu excep ția situației în care se efectueaz ă citirea de pe un 
fișier cu condi ții de acces SM-R-ENC-MAC-G2 (a se vedea 
secțiunea 4 din apendicele 2), mesageria securizat ă este 
utilizată în modul exclusiv cu autentificare. În acest mod, 
o sumă de verificare criptografic ă (cunoscut ă și sub 
denumirea de MAC) se adaug ă la toate comenzile și răspun­
surile pentru a asigura autenticitatea și integritatea mesa ­
jului.  
CSM_183 În cazul în care se efectueaz ă citirea datelor dintr-un fi șier 
cu condiția de acces SM-R-ENC-MAC-G2, mesageria secu ­
rizată este utilizat ă în modul criptare urmat ă de autentificare, 
iar apoi, prin intermediul datelor criptate formatate se 
calculează o MAC pentru a asigura autenticitatea și integri­
tatea.  
CSM_184 Mesageria securizat ă utilizează AES, astfel cum este definit ă 
în [AES], cu cheile de sesiune K  MAC și K  ENC care au fost 
stabilite în timpul autentific ării cipului.  
CSM_185 Un întreg nesemnat se utilizeaz ă drept contor de secven țe 
trimise (SSC) pentru a preveni atacurile prin reluare. 
Mărimea SSC este egal ă cu mărimea blocului AES, și 
anume 128 de bi ți. SSC este în format  MSB-first  (cel mai 
semnificativ octet la început). Contorul de secven țe trimise 
începe cu zero ( și anume, ‘00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00’) atunci când este lansat ă mesageria 
securizată. SSC este m ărit de fiecare dat ă înaintea 
generării unei comenzi sau a unui r ăspuns APDU, ceea ce 
înseamnă că, întrucât valoarea de început a SSC într-o 
sesiune SM este 0, în prima comand ă valoarea SSC va fi 
1. Valoarea SSC pentru primul r ăspuns va fi 2.  
CSM_186 Pentru criptarea unui mesaj, cheia K  ENC este utilizat ă cu 
AES în modul de operare cu înl ănțuirea blocurilor cifrate 
(CBC), astfel cum este definit în (ISO 10116), cu un 
parametru intermediar  m = 1 și un vector de ini țializare 
SV = E(K  ENC , SSC), adic ă valoarea curent ă a contorului 
de secvențe trimise criptat ă cu cheia K  ENC . 
CSM_187 Pentru autentificarea mesajelor, cheia K  MAC este utilizat ă cu 
AES în modul CMAC, astfel cum este specificat în (SP 
800-38B). Lungimea MAC este legat ă de lungimea cheilor 
de sesiune AES, astfel cum este specificat în CSM_50. 
Contorul de secven țe trimise este inclus în MAC prin 
adăugarea acestuia la începutul datagramei care trebuie 
autentificat ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 418  
10.5.2  Structura mesageriei securizate  
CSM_188 Mesageria securizat ă utilizează numai obiectele de date din 
mesageria securizat ă [a se vedea (ISO 7816-4)] enumerate 
în tabelul 5. În orice mesaj, aceste obiecte de date sunt 
utilizate în ordinea precizat ă în tabelul men ționat mai sus.  
Tabelul 5  
Obiecte de date ale mesageriei securizate  
Denumirea obiectului de date  Etichet ă Prezență obligatorie (M), 
condițională (C) sau 
interzisă (F) în  
Comenzi  Răspunsuri  
Valoarea datelor în clar necodificat ă în 
BER-TLV  ‘81’ C  C  
Valoarea a datelor în clar codat ă în 
BER-TLV, dar care nu include obiecte 
de date (DO) ale SM  ‘B3’ C  C  
Indicator al con ținutului de completare 
urmat de criptogram ă, valoare a datelor 
în clar necodat ă în BER-TLV  ‘87’ C  C  
Le protejat ă ‘97’  C  F  
Starea de procesare  ‘99’  F  M  
Sumă de verificare criptografic ă ‘8E’  M  M  
Notă: Astfel cum este specificat în apendicele 2, cardurile 
de tahograf pot trata comenzile READ BINARY și 
UPDATE BINARY cu un octet INS impar (‘B1’, 
respectiv ‘D7’). Aceste variante de comenzi trebuie s ă 
citească și să actualizeze fi șiere cu mai mult de 32 768 de 
octeți. În cazul în care este utilizat ă o astfel de variant ă, un 
obiect de date cu eticheta ‘B3’ este utilizat în locul unui 
obiect cu eticheta ‘81’. A se vedea apendicele 2 pentru mai 
multe informa ții. 
CSM_189 Toate obiectele de date ale SM sunt codificate în DER 
TLV, astfel cum este specificat în (ISO 8825-1). Rezultatele 
codificării într-o structur ă de tip „valoarea lungimii 
etichetei” (TLV) sunt dup ă cum urmeaz ă: 
Etichetă: Eticheta este codificat ă în unul sau doi octe ți și 
indică conținutul.  
Lungime: Lungimea este codificat ă ca un întreg nesemnat în 
unul, doi sau trei octe ți, ducând la o lungime 
maximă de 65 535 de octe ți. Se utilizeaz ă 
numărul minim de octe ți. 
Valoare: Valoarea este codificat ă în zero sau mai mul ți 
octeți. 
CSM_190 APDU (unit ățile de date pentru protocolul de aplica ție) care 
sunt protejate prin mesageria securizat ă sunt create astfel:  
— Antetul comenzii este inclus în calcularea MAC; prin 
urmare, pentru octetul de clas ă CLA este utilizat ă 
valoarea ‘0C’.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 419  
— Astfel cum se specific ă în apendicele 2, to ți octeții INS 
trebuie să fie pari, cu posibila excep ție a octeților impari 
INS utiliza ți pentru comenzile READ BINARY și 
UPDATE BINARY.  
— Valoarea curent ă a Lc va fi modificat ă în Lc' dup ă 
aplicarea mesageriei securizate.  
— Câmpul de date const ă în obiectele de date ale SM.  
— În comanda protejat ă APDU, noul octet Le se seteaz ă la 
‘00’. Dacă este necesar, în câmpul de date este inclus un 
obiect de date ‘97’ pentru a indica valoarea ini țială a Le.  
▼M1 
CSM_191 Orice obiect de date care urmeaz ă să fie criptat este 
completat în conformitate cu [ISO 7816-4], utilizând indi ­
catorul „01” al con ținutului de completare. Pentru calcularea 
MAC, obiectele de date din APDU sunt completate în 
conformitate cu [ISO 7816-4].  
Notă: Completarea pentru mesageria securizat ă este 
efectuată întotdeauna de stratul de mesagerie securizat ă, 
nu de algoritmii CMAC sau CBC.  
Rezumat și exemple  
O comand ă APDU cu mesageria securizat ă aplicată va avea urm ătoarea 
structură, în funcție de cazul comenzii nesecurizate respective (DO 
înseamnă obiect de date):  
Cazul 1: CLA INS P1 P2 || Lc' || DO „8E” || Le  
Cazul 2: CLA INS P1 P2 || Lc' || DO „97” || DO 
„8E” || Le  
Cazul 3 (octet INS par): CLA INS P1 P2 || Lc' || DO „81” || DO 
„8E” || Le  
Cazul 3 (octet INS impar): CLA INS P1 P2 || Lc' || DO «B3« || DO 
„8E” || Le  
Cazul 4 (octet INS par): CLA INS P1 P2 || Lc' || DO „81” || DO 
„97” || DO „8E” || Le  
Cazul 4 (octet INS impar): CLA INS P1 P2 || Lc' || DO „B3” || DO 
„97” || DO „8E” || Le  
unde Le = „00” sau „00 00”, aceasta depinzând de lungimea câmpurilor 
utilizate, și anume câmpuri de lungime scurt ă sau câmpuri de lungime 
extinsă; a se vedea [ISO 7816-4].  
Un răspuns APDU cu mesageria securizat ă aplicată va avea urm ătoarea 
structură, în funcție de cazul r ăspunsului nesecurizat respectiv:  
Cazul 1 sau 3: DO „99” || DO „8E” || 
SW1SW2  
Cazul 2 sau 4 (octet INS par) f ără criptare: DO „81” || DO „99” || DO 
„8E” || SW1SW2  
Cazul 2 sau 4 (octet INS par) cu criptare: DO „87” || DO „99” || DO 
„8E” || SW1SW2  
Cazul 2 sau 4 (octet INS impar) f ără criptare: DO „B3” || DO „99” || DO „8E” || SW1SW2  
Notă: Cazul 2 sau 4 (octet INS impar) cu criptare nu este niciodat ă 
utilizat în comunicarea dintre o VU și un card.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 420  
Mai jos sunt prezentate trei exemple de transform ări APDU pentru 
comenzi cu cod INS par. În figura 8 este prezentat ă o comand ă APDU 
autentificat ă din cazul 4, în figura 9 este prezentat un r ăspuns APDU 
autentificat din cazul 1/cazul 3, iar în figura 10 este prezentat un r ăspuns 
APDU criptat și autentificat din cazul 2/cazul 4.  
Figura 8  
Transformarea unei comenzi APDU autentificate din cazul 4
  
Figura 9  
Transformarea unui r ăspuns APDU autentificat din cazul 1/cazul 3
  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 421  
Figura 10  
Transformarea unui r ăspuns APDU criptat și autentificat din cazul 2/cazul 4
  
▼B 
10.5.3  Abandonarea sesiunii de mesagerie securizat ă 
CSM_192 O unitate montat ă pe vehicul abandoneaz ă o sesiune de 
mesagerie securizat ă în curs de desf ășurare dacă și numai 
dacă are loc unul dintre urm ătoarele evenimente:  
— unitatea prime ște un răspuns simplu APDU,  
— unitatea detecteaz ă o eroare a mesageriei securizate într- 
un răspuns APDU:  
— un obiect de date preconizat lipse ște din mesageria 
securizată, ordinea obiectelor de date este incorect ă 
sau este inclus un obiect de date necunoscut.  
— Un obiect de date din mesageria securizat ă este 
incorect, de exemplu valoarea MAC este incorect ă, 
structura TLV este incorect ă sau indicatorul de 
completare din eticheta ‘87’ nu este egal cu ‘01’.  
— cardul trimite un octet de stare care indic ă faptul că 
acesta a detectat o eroare SM (a se vedea CSM_194),  
— a fost atins ă limita num ărului de comenzi și de 
răspunsuri aferente din sesiunea curent ă. Pentru o 
anumită VU, aceast ă limită este definit ă de produc ătorul 
său, luând în considerare cerin țele de securitate ale 
hardware-ului utilizat, cu o valoare maxim ă de 240 de 
comenzi și de răspunsuri aferente SM pe sesiune.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 422  
CSM_193 Un card de tahograf abandoneaz ă o sesiune de mesagerie 
securizată în curs de desf ășurare dacă și numai dac ă are 
loc unul dintre urm ătoarele evenimente:  
— cardul prime ște un răspuns simplu APDU,  
— cardul detecteaz ă o eroare a mesageriei securizate într-o 
comandă APDU:  
— un obiect de date preconizat lipse ște din mesageria 
securizată, ordinea obiectelor de date este incorect ă 
sau este inclus un obiect de date necunoscut.  
— Un obiect de date din mesageria securizat ă este 
incorect, de exemplu valoarea MAC este incorect ă 
sau structura TLV este incorect ă. 
— cardul este deconectat de la alimentarea cu energie 
electrică sau este resetat,  
— VU începe procesul de autentificare al VU,  
— a fost atins ă limita num ărului de comenzi și de 
răspunsuri aferente din sesiunea curent ă. Pentru un 
anumit card, aceast ă limită este definit ă de produc ătorul 
său, luând în considerare cerin țele de securitate ale 
hardware-ului utilizat, cu o valoare maxim ă de 240 de 
comenzi și de răspunsuri aferente SM pe sesiune.  
▼B 
CSM_194 În ceea ce prive ște gestionarea erorilor SM de c ătre cardul de 
tahograf:  
— În cazul în care într-o comand ă APDU lipsesc anumite 
obiecte de date preconizate ale mesageriei securizate, 
ordinea obiectelor de date este incorect ă sau sunt 
incluse obiecte de date necunoscute, cardul de tahograf 
răspunde cu octe ții de stare ‘69 87’.  
— În cazul în care un obiect de date din mesageria secu ­
rizată într-o comand ă APDU este incorect, un card de 
tahograf răspunde cu octe ții de stare ‘69 88’.  
Într-un astfel de caz, octe ții de stare sunt returna ți fără 
utilizarea SM.  
CSM_195 Dac ă o sesiune de mesagerie securizat ă între o VU și un card 
de tahograf este abandonat ă, VU și cardul de tahograf  
— distrug în mod securizat cheile de sesiune stocate  
— stabilesc imediat o nou ă sesiune de mesagerie securizat ă, 
astfel cum este descris în sec țiunile 10.2 – 10.5.  
CSM_196 În cazul în care, din orice motiv, VU decide s ă reînceapă 
procedura de autentificare reciproc ă în raport cu un card 
introdus, procesul se reia cu verificarea lan țului de certificate 
de card, astfel cum este descris în sec țiunea 10.2, și continuă 
astfel cum este descris în sec țiunile 10.2 – 10.5.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 423  
11. CUPLAREA, AUTENTIFICAREA RECIPROC Ă ȘI MESAGERIA 
SECURIZAT Ă ÎNTRE VU ȘI ECHIPAMENTUL GNSS EXTERN  
11.1.  Considera ții generale  
CSM_197 Echipamentul GNSS utilizat de o VU pentru a- și determina 
poziția poate fi intern (adic ă poate fi montat în interiorul 
carcasei VU, f ără a fi deta șabil) sau poate fi un modul 
extern. În primul caz, nu este necesar s ă se standardizeze 
comunicarea intern ă dintre echipamentul GNSS și VU, iar 
cerințele din prezentul capitol nu se aplic ă. În al doilea caz, 
comunicarea dintre VU și echipamentul GNSS extern este 
standardizat ă și protejată astfel cum este descris în prezentul 
capitol.  
CSM_198 Comunicarea securizat ă între o unitate montat ă pe vehicul și 
un echipament GNSS extern are loc în acela și mod ca o 
comunicare securizat ă între o unitate montat ă pe vehicul și 
un card de tahograf, echipamentul GNSS extern (EGF) 
având rolul cardului. Un EGF îndepline ște toate cerin țele 
menționate în capitolul 10 referitoare la cardurile de 
tahograf, ținând seama de devia țiile, clarific ările și adăugirile 
menționate în prezentul capitol. În special, verificarea 
reciprocă a lanțurilor de certificate, autentificarea VU și 
autentificarea cipurilor sunt efectuate astfel cum este 
descris în sec țiunile 11.3 și 11.4.  
CSM_199 Comunicarea dintre o unitate montat ă pe vehicul și un EGF 
este diferit ă față de comunicarea dintre o unitate montat ă pe 
vehicul și un card prin faptul c ă o unitate montat ă pe vehicul 
și un EGF trebuie s ă fie cuplate mai întâi într-un atelier 
pentru a putea schimba ulterior date bazate pe GNSS în 
timpul func ționării normale. Procesul de cuplare este 
descris în sec țiunea 11.2.  
CSM_200 Pentru comunicarea dintre o unitate montat ă pe vehicul și un 
EGF se utilizeaz ă comenzile și răspunsurile bazate pe (ISO 
7816-4) și (ISO 7816-8). Structura precis ă a acestor APDU 
este definit ă în apendicele 2 la prezenta anex ă. 
11.2.  Cuplarea dintre VU și echipamentul GNSS extern  
CSM_201 O unitate montat ă pe vehicul și un EGF sunt cuplate de un 
atelier. În timpul func ționării normale, numai o unitate 
montată pe vehicul și un EGF cuplate vor putea comunica 
între ele.  
CSM_202 Cuplarea unei unit ăți montate pe vehicul cu un EGF este 
posibilă numai dac ă unitatea montat ă pe vehicul este în 
modul etalonare. Cuplarea este ini țiată de unitatea montat ă 
pe vehicul.  
CSM_203 Un atelier poate recupla o unitate montat ă pe vehicul la un 
alt EGF sau la acela și EGF în orice moment. În timpul 
recuplării, VU distruge în mod securizat certificatul 
EGF_MA existent din memoria sa și stochează certificatul 
EGF_MA al EGF la care este în curs de a fi cuplat ă. 
CSM_204 Un atelier poate recupla un echipament GNSS extern la o 
altă VU sau la aceea și VU în orice moment. În timpul recu ­
plării, EGF distruge în mod securizat certificatul VU_MA 
existent din memoria sa și stocheaz ă certificatul VU_MA 
al VU la care este în curs de a fi cuplat.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 424  
11.3.  Verificarea reciproc ă a lanțului de certificate  
11.3.1  Considera ții generale  
CSM_205 Verificarea reciproc ă a lanțului de certificate dintre o VU și 
un EGF are loc în timpul cupl ării VU și a EGF de c ătre un 
atelier. În timpul func ționării normale a unei VU și a unui 
EGF cuplate între ele, nu este verificat niciun certificat. În 
locul acestei verific ări, VU și EGF au încredere în certifi ­
catele pe care le-au stocat în timpul cupl ării, după ce au 
verificat valabilitatea temporal ă a acestor certificate. VU și 
EGF nu au încredere în niciun alt certificat pentru protejarea 
comunicării VU – EGF în timpul func ționării normale.  
11.3.2  În timpul cupl ării VU – EGF  
CSM_206 În timpul cupl ării la un EGF, o unitate montat ă pe vehicul 
utilizează protocolul descris în figura 4 (sec țiunea 10.2.1) 
pentru verificarea lan țului de certificate ale echipamentului 
GNSS extern.  
Note la figura 4 în acest context:  
— Controlul comunic ărilor este în afara domeniului de 
aplicare al prezentului apendice. Cu toate acestea, un 
EGF nu este un card inteligent și, prin urmare, VU nu 
va trimite, probabil, o comand ă de resetare pentru a ini ția 
comunicarea și nici nu va primi un ATR.  
— Certificatele și cheile publice ale cardurilor men ționate în 
figură sunt interpretate ca fiind certificatele și cheile 
publice EGF pentru identificarea reciproc ă. Acestea 
sunt indicate în sec țiunea 9.1.6 ca fiind EGF_MA.  
— Certificatele Card.CA și cheile publice men ționate în 
figură sunt interpretate ca fiind certificatele și cheile 
publice MSCA pentru semnarea certificatelor EGF. 
Acestea sunt indicate în sec țiunea 9.1.3 ca fiind 
MSCA_VU-EGF.  
— Certificatul Card.CA.EUR men ționat în figur ă este inter­
pretat ca fiind certificatul r ădăcină european precizat în 
CAR al certificatului MSCA_VU-EGF.  
— Certificatul Card.Link men ționat în figur ă este interpretat 
ca fiind certificatul de leg ătură al EGF, dac ă acesta 
există. Astfel cum este specificat în sec țiunea 9.1.2, 
acesta este un certificat de leg ătură pentru o nou ă 
pereche de chei r ădăcină europene create de ERCA și 
semnate de cheia privat ă europeană anterioară. 
— Certificatul Card.Link.EUR este certificatul r ădăcină 
european precizat în CAR al certificatului Card.Link.  
— În loc de a citi
  , VU 
citește
 din EF ICC.  
— În loc de a selecta AID al tahografului, VU selecteaz ă 
AID al EGF.  
— „Ignore Card” se interpreteaz ă ca „Ignore EGF”.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 425  
CSM_207 Dup ă ce a verificat certificatul EGF_MA, unitatea montat ă 
pe vehicul stocheaz ă acest certificat pentru utilizarea sa în 
timpul func ționării normale; a se vedea sec țiunea 11.3.3.  
CSM_208  ►M1 În timpul cupl ării la o VU, un echipament GNSS 
extern utilizeaz ă protocolul descris în figura 5 (sec țiunea 
10.2.2) pentru verificarea lan țului de certificate ale VU. ◄ 
Note la figura 5 în acest context:  
— VU genereaz ă o nouă pereche de chei efemere utilizând 
parametrii de domeniu din certificatul EGF.  
— Certificatele și cheile publice ale VU men ționate în 
figură sunt cele utilizate pentru autentificarea reciproc ă. 
Acestea sunt indicate în sec țiunea 9.1.4 ca fiind 
VU_MA.  
— Certificatele și cheile publice VU.CA men ționate în 
figură sunt cele utilizate pentru semnarea certificatelor 
VU și ale echipamentului GNSS extern. Acestea sunt 
indicate în sec țiunea 9.1.3 ca fiind MSCA_VU-EGF.  
— Certificatul VU.CA.EUR men ționat în figur ă este certi ­
ficatul rădăcină european precizat în CAR al certifi ­
catului VU.CA.  
— Certificatul VU.Link men ționat în figur ă este certificatul 
de legătură al VU, dac ă acesta exist ă. Astfel cum este 
specificat în sec țiunea 9.1.2, acesta este un certificat de 
legătură pentru o nou ă pereche de chei r ădăcină europene 
create de ERCA și semnate de cheia privat ă europeană 
anterioară. 
— Certificatul VU.Link.EUR este certificatul r ădăcină 
european precizat în CAR al certificatului VU.Link.  
CSM_209 Ca o excep ție de la cerin ța CSM_167, un EGF utilizeaz ă ora 
indicată de GNSS pentru a verifica valabilitatea temporal ă a 
oricărui certificat prezentat.  
▼M1 
CSM_210 Dup ă ce a verificat certificatul VU_MA, echipamentul GNSS 
extern stocheaz ă acest certificat pentru a-l utiliza în timpul 
funcționării normale; a se vedea sec țiunea 11.3.3.  
▼B 
11.3.3  În timpul func ționării normale  
CSM_211  ►M1 În timpul func ționării normale, o unitate montat ă pe 
vehicul și un EGF utilizeaz ă protocolul descris în figura 11 
pentru a verifica valabilitatea temporal ă a certificatului stocat 
EGF_MA și pentru a configura cheia public ă VU_MA în 
scopul autentific ării ulterioare a VU. Nicio alt ă verificare 
reciprocă a lanțurilor de certificate nu este efectuat ă în 
timpul func ționării normale. ◄ 
A se remarca faptul c ă figura 11 este compus ă în esență din 
primele etape prezentate în figura 4 și în figura 5. A se 
remarca înc ă o dată faptul că, întrucât EGF nu este un 
card inteligent, VU nu va trimite, probabil, o comand ă de 
resetare pentru a ini ția comunicarea și nici nu va primi un 
ATR. În orice caz, acest aspect este în afara domeniului de 
aplicare al prezentului apendice.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 426  
Figura 11  
Verificarea reciproc ă a valabilit ății temporale a certificatului în timpul func ționării normale VU – EGF
  
CSM_212 Astfel cum reiese din figura 11, unitatea montat ă pe vehicul 
înregistreaz ă o eroare în cazul în care certificatul EGF_MA 
nu mai este valabil. Cu toate acestea, autentificarea reci ­
procă, înțelegerea asupra cheilor și comunicarea ulterioar ă 
prin mesageria securizat ă continuă în mod normal.  
11.4.  Autentificarea VU, autentificarea cipului și înțelegerea asupra cheilor 
de sesiune  
CSM_213 Autentificarea VU, autentificarea cipului și înțelegerea 
asupra cheilor de sesiune între o VU și un EGF sunt 
efectuate în timpul cupl ării și ori de câte ori este restabilit ă 
o sesiune de mesagerie securizat ă în timpul func ționării 
normale. VU și EGF efectueaz ă procesele descrise în 
secțiunile 10.3 și 10.4. Se aplic ă toate cerin țele din aceste 
secțiuni. 
11.5.  Mesageria securizat ă 
CSM_214 Toate comenzile și toate răspunsurile schimbate între o 
unitate montat ă pe vehicul și un echipament GNSS extern 
după confirmarea autenticit ății cipului și până la sfârșitul 
sesiunii sunt protejate prin mesageria securizat ă în modul 
exclusiv cu autentificare. Se aplic ă toate cerin țele din 
secțiunea 10.5.  
CSM_215 Dac ă o sesiune de mesagerie securizat ă dintre o VU și un 
EGF este abandonat ă, VU trebuie s ă stabileasc ă imediat o 
nouă sesiune de mesagerie securizat ă, astfel cum este descris 
în secțiunile 11.3.3 și 11.4.  
12. ASOCIEREA ȘI COMUNICAREA DINTRE O VU ȘI UN SENZOR 
DE MIȘCARE  
12.1.  Considera ții generale  
CSM_216 O unitate montat ă pe vehicul comunic ă cu un senzor de 
mișcare utilizând protocolul de interfa ță specificat în (ISO 
16844-3) în timpul asocierii și al funcționării normale, cu 
schimbările descrise în prezentul capitol și în secțiunea 9.2.1.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 427  
Notă: se presupune c ă cititorii prezentului capitol sunt fami ­
liarizați cu conținutul standardului (ISO 16844-3).  
12.2.  Asocierea VU – senzor de mi șcare folosind genera ții diferite de chei  
Astfel cum s-a explicat în sec țiunea 9.2.1, cheia master a senzorului de 
mișcare și toate cheile asociate sunt înlocuite în mod periodic. Acest fapt 
duce la prezen ța în cardurile de atelier a pân ă la trei chei K  M-WC  AES 
legate de senzorul de mi șcare (din genera ții consecutive de chei). În mod 
similar, în senzorii de mi șcare pot fi prezente pân ă la trei cript ări diferite 
de date bazate pe AES (care au la baz ă generații consecutive ale cheii 
master K  M a senzorului de mi șcare). O unitate montat ă pe vehicul 
conține o singur ă cheie K  M-VU  legată de senzorul de mi șcare.  
CSM_217 O VU din a doua genera ție și un senzor de mi șcare din a 
doua genera ție sunt asociate dup ă cum urmeaz ă [a se 
compara cu tabelul 6 din (ISO 16844-3)]:  
1. Un card de atelier din a doua genera ție este introdus în 
VU, iar VU este conectat la senzorul de mi șcare.  
2. VU cite ște toate cheile K  M-WC  disponibile din cardul de 
atelier, inspecteaz ă numerele de versiune ale acestora și 
alege cheia al c ărei număr de versiune corespunde 
numărului de versiune al cheii K  M-VU  a VU. În cazul în 
care cheia K  M-WC  corespunzătoare nu este prezent ă pe 
cardul de atelier, VU abandoneaz ă procesul de asociere 
și afișează un mesaj adecvat de eroare pentru titularul 
cardului de atelier.  
3. VU calculeaz ă cheia master K  M a senzorului de mi șcare 
pe baza cheilor K  M-VU  și K  M-WC  , precum și cheia de 
identificare K  ID pe baza cheii K  M , astfel cum este 
specificat în sec țiunea 9.2.1.  
4. VU trimite instruc țiunea pentru a ini ția procesul de 
asociere în raport cu senzorul de mi șcare, astfel cum 
este descris în (ISO 16844-3), și criptează numărul de 
serie pe care îl prime ște de la senzorul de mi șcare cu 
cheia de identificare K  ID . VU trimite înapoi senzorului 
de mișcare numărul de serie criptat.  
5. Senzorul de mi șcare compar ă consecutiv num ărul de serie 
criptat cu fiecare dintre cript ările numărului de serie pe 
care îl con ține intern. În cazul în care g ăsește o cores ­
pondență, VU este autentificat ă. Senzorul de mi șcare 
notează generația cheii K  ID utilizate de VU și returneaz ă 
versiunea criptat ă corespondent ă a cheii sale de asociere, 
și anume criptarea care a fost creat ă folosind aceea și 
generație a K  M . 
6. VU decripteaz ă cheia de asociere utilizând K  M , generează 
o cheie de sesiune K  S , o cripteaz ă cu cheia de asociere și 
trimite rezultatul senzorului de mi șcare. Senzorul de 
mișcare decripteaz ă K S . 
7. VU reune ște informa țiile de asociere astfel cum sunt 
definite în (ISO 16844-3), cripteaz ă informațiile cu 
cheia de asociere și trimite rezultatul senzorului de 
mișcare. Senzorul de mi șcare decripteaz ă informațiile de 
asociere.  
8. Senzorul de mi șcare cripteaz ă informațiile de asociere 
primite, cu ajutorul cheii K  S , și le transmite înapoi c ătre 
VU. VU verific ă dacă informațiile de asociere sunt 
identice cu informa țiile pe care VU le-a trimis senzorului 
de mișcare în etapa anterioar ă. Dacă acest lucru se  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 428  
confirmă, înseamn ă că senzorul de mi șcare a utilizat 
aceeași cheie K  S ca VU și, prin urmare, în etapa 5, 
acesta și-a trimis cheia de asociere criptat ă cu genera ția 
corectă a cheii K  M . În consecin ță, senzorul de mi șcare 
este autentificat.  
A se nota faptul c ă etapele 2 și 5 sunt diferite fa ță de 
procesul standard din (ISO 16844-3); celelalte etape sunt 
standard.  
Exemplu: S ă presupunem c ă are loc o asociere în primul an 
de valabilitate a certificatului ERCA (3); a se vedea figura 2 
din secțiunea 9.2.1.2. În plus,  
— să presupunem c ă senzorul de mi șcare a fost produs în 
ultimul an de valabilitate a certificatului ERCA (1). Prin 
urmare, aceasta va con ține următoarele chei și date:  
— N  s [1]: numărul de serie criptat cu genera ția 1 a K  ID , 
— N  s [2]: numărul său de serie criptat cu genera ția 2 a 
K ID , 
— N  s [3]: numărul său de serie criptat cu genera ția 3 a 
K ID , 
— K  P [1]: genera ția 1 a cheii sale de asociere (  1 ), criptată 
cu generația 1 a cheii K  M , 
— K  P [2]: genera ția 2 a cheii sale de asociere, criptat ă cu 
generația 2 a cheii K  M , 
— K  P [3]: genera ția 3 a cheii sale de asociere, criptat ă cu 
generația 3 a cheii K  M , 
— Să presupunem c ă livrarea cardului de atelier a fost 
efectuată în ultimul an de valabilitate a certificatului 
ERCA (3). Acesta va con ține, prin urmare, genera ția 2 
și generația 3 ale cheii K  M-WC  . 
— Să presupunem c ă VU este din genera ția 2 de VU, 
conținând genera ția 2 a cheii K  M-VU  . 
În acest caz, în etapele 2-5 vor avea loc urm ătoarele eveni ­
mente:  
— Etapa 2: VU cite ște generația 2 și generația 3 ale cheii 
K M-WC  din cardul de atelier și inspecteaz ă numerele de 
versiune ale acestora.  
— Etapa 3: VU combin ă generația 2 a cheii K  M-WC  cu cheia 
sa K  M-VU  pentru a calcula K  M și K  ID . 
— Etapa 4: VU cripteaz ă numărul de serie pe care îl 
primește de la senzorul de mi șcare cu cheia K  ID . 
— Etapa 5: Senzorul de mi șcare compar ă datele primite cu 
N s [1] și nu găsește nicio coresponden ță. Apoi, acesta 
compară datele cu N  s [2] și găsește o coresponden ță. 
Senzorul de mi șcare trage concluzia c ă VU este din 
generația 2 de VU și, prin urmare, trimite înapoi K  P [2]. ▼B 
( 1 ) A se nota faptul c ă generația 1, genera ția 2 și generația 3 de chei de asociere pot 
reprezenta de fapt aceea și cheie sau pot fi trei chei diferite cu lungimi diferite, astfel 
cum este explicat în CSM_117.
 02016R0799 — RO — 26.02.2020 — 002.001 — 429  
12.3.  Comunicarea și asocierea dintre o VU și un senzor de mi șcare 
folosind AES  
CSM_218 Astfel cum este precizat în tabelul 3 din sec țiunea 9.2.1, 
toate cheile implicate în asocierea unei unit ăți (de a doua 
generație) montate pe vehicul și a unui senzor de mi șcare, 
precum și în comunicarea lor ulterioar ă, sunt mai curând chei 
AES decât chei de lungime dubl ă TDES, astfel cum este 
specificat în (ISO 16844-3). Aceste chei AES pot avea o 
lungime de 128, 192 sau 256 de bi ți. Întrucât m ărimea 
blocurilor AES este de 16 octe ți, lungimea unui mesaj 
criptat trebuie s ă fie un multiplu de 16 octe ți, în compara ție 
cu lungimea de 8 octe ți din cazul TDES. În plus, unele 
dintre aceste mesaje vor fi utilizate pentru a transporta chei 
AES, a căror lungime poate fi de 128, 192 sau 256 de bi ți. 
Prin urmare, num ărul de octe ți de date per instruc țiune în 
tabelul 5 din (ISO 16844-3) se modific ă după cum este 
indicat în tabelul 6:  
▼M1 
Tabelul 6  
Numărul de octe ți de date cu text simplu și criptate per instruc țiune definit în [ISO 16844-3]  
Instrucțiune Solicitare/ 
răspuns  Descrierea datelor  Nr. de octe ți de date 
cu text simplu în 
conformitate cu 
[ISO 16844-3]  Nr. de octe ți de date 
cu text simplu 
folosind chei AES  Nr. de octe ți de date criptate 
folosind chei AES cu lungimea 
de (în biți): 
128 192  256  
10 solicitare  Datele de autenti ­
ficare + num ărul 
fișierului  8 8  16  16  16  
11 răspuns  Datele de autenti ­
ficare + con ținuturile 
fișierelor  16 sau 32, depinde 
de fișier 16 sau 32, depinde 
de fișier 32 / 48  32 / 48  32 / 48  
41 solicitare  Numărul de serie al 
MoS (senzorul de 
mișcare)  8 8  16  16  16  
41 răspuns  Cheie de asociere  16  16 / 24 / 32  16  32  32  
42 solicitare  Cheie de sesiune  16  16 / 24 / 32  16  32  32  
43 solicitare  Informa ții de asociere  24  24  32  32  32  
50 răspuns  Informa ții de asociere  24  24  32  32  32  
70 solicitare  Date de autentificare  8  8  16  16  16  
80 răspuns  Valoarea contorului 
MoS + date de auten ­
tificare  8 8  16  16  16  
▼B 
CSM_219 Informa țiile de asociere trimise în instruc țiunile 43 (soli ­
citarea VU) și 50 (răspunsul MoS) sunt reunite astfel cum 
este precizat în sec țiunea 7.6.10 din (ISO 16844-3), cu 
excepția faptului c ă se utilizeaz ă algoritmul AES în locul 
algoritmului TDES în schema de criptare a datelor de 
asociere, ceea ce duce, prin urmare, la folosirea a dou ă 
criptări AES și la adoptarea complet ării specificate în 
CSM_220 pentru a corespunde m ărimii blocului AES. 
Cheia K'  p utilizată pentru aceast ă criptare este generat ă în 
modul urm ător: 
— În cazul în care cheia de asociere K  P are o lungime de 16 
octeți: K'  p = K  P XOR (N  s ||N s ) ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 430  
— În cazul în care cheia de asociere K  P are o lungime de 24 
de octeți: K'  p = K  P XOR (N  s ||N s ||N s ) 
— În cazul în care cheia de asociere K  P are o lungime de 32 
de octeți: K'  p = K  P XOR (N  s ||N s ||N s ||N s ) 
unde N  s este numărul de serie de 8 octe ți al senzorului de 
mișcare.  
CSM_220 În cazul în care lungimea datelor de text simplu (utilizând 
chei AES) nu este un multiplu de 16 octe ți, se folose ște 
metoda 2 de completare definit ă în (ISO 9797-1).  
Notă: în (ISO 16844-3), num ărul de octe ți de date cu text 
simplu este întotdeauna un multiplu de 8, astfel încât 
completarea nu este necesar ă atunci când se folose ște 
TDES. Defini ția datelor și mesajelor în ISO (16844-3) nu 
este modificat ă prin prezenta parte din prezentul apendice, 
fiind necesar ă, prin urmare, aplicarea complet ării. 
CSM_221 Pentru instruc țiunea 11 și în cazul în care trebuie încriptate 
cel puțin două blocuri de date, se utilizeaz ă modul de 
funcționare cu înl ănțuirea blocurilor cifrate, astfel cum se 
precizează în (ISO 10116), cu un parametru intermediar  m 
= 1. Vectorul de ini țializare (IV) care trebuie utilizat este:  
— Pentru instruc țiunea 11: blocul de autentificare de 8 
octeți specificat în sec țiunea 7.6.3.3. din (ISO 16844- 
3), completat utilizând metoda de completare 2 definit ă 
în (ISO 9797-1); a se vedea, de asemenea, sec țiunile 
7.6.5 și 7.6.6 din ISO (16844-3).  
— Pentru toate celelalte sec țiuni în care sunt transfera ți mai 
mult de 16 octe ți, astfel cum este precizat în tabelul 6: 
‘00’ {16}, adic ă șaisprezece octe ți cu valoarea binar ă 0. 
Notă: Așa cum se arat ă în secțiunile 7.6.5 și 7.6.6 din (ISO 
16844-3), atunci când MoS cripteaz ă fișierele de date pentru 
a fi incluse în instruc țiunea 11, blocul de autentificare este  
— atât utilizat ca vector de ini țializare pentru modul CBC 
de criptare a fi șierelor de date,  
— cât și criptat și inclus ca prim bloc în datele trimise c ătre 
VU. 
12.4.  Asocierea VU – senzor de mi șcare pentru echipamente de diferite 
generații 
CSM_222 Astfel cum s-a explicat în sec țiunea 9.2.1, un senzor de 
mișcare din a doua genera ție poate con ține criptarea bazat ă 
pe TDES a datelor de asociere (astfel cum este definit în 
partea A a prezentului apendice), ceea ce permite asocierea 
senzorului de mi șcare cu o VU de prima genera ție. În acest 
caz, o VU de prima genera ție și un senzor de mi șcare de a 
doua genera ție sunt asocia ți conform descrierii din partea A 
a prezentului apendice și din (ISO 16844-3). Pentru procesul 
de asociere poate fi folosit un card de atelier de prima 
generație sau de a doua genera ție. 
Note:  
— Nu este posibil ă asocierea unei VU de a doua genera ție 
cu un senzor de mi șcare de prima genera ție. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 431  
— Nu este posibil ă utilizarea unui card de atelier de prima 
generație pentru a cupla o VU de a doua genera ție la un 
senzor de mi șcare.  
13. SECURITATEA COMUNIC ĂRII LA DISTAN ȚĂ PRIN DSRC  
13.1.  Considera ții generale  
Astfel cum se specific ă în apendicele 14, o VU genereaz ă periodic date 
de monitorizare de la distan ță a tahografelor (RTM) și trimite aceste date 
echipamentului (intern sau extern) de comunicare la distan ță (RCF). 
Echipamentul de monitorizare la distan ță este responsabil pentru 
trimiterea datelor, prin interfa ța DSRC descris ă în apendicele 14, c ătre 
echipamentul de interogare la distan ță. În apendicele 1 se precizeaz ă că 
datele RTM sunt concatenarea urm ătoarelor elemente:  
Datele utile criptate ale tahografului  criptarea datelor utile cu text 
simplu ale tahografului  
Datele de securitate DSRC  descrise mai jos  
Formatul datelor utile cu text simplu ale tahografului este precizat în 
apendicele 1 și descris în detaliu în apendicele 14. În aceast ă secțiune 
este descris ă structura datelor de securitate DSRC; specifica ția formală 
este descris ă în apendicele 1.  
CSM_223 Datele cu text în clar
  comunicate 
de o VU unui echipament de comunicare la distan ță (dacă 
RCF este instalat în afara VU) sau de la VU c ătre un echi ­
pament de interogare la distan ță prin intermediul interfe ței 
DSRC (dac ă RCF este instalat în interiorul VU) sunt 
protejate în modul criptare urmat ă de autentificare, ceea ce 
înseamnă că mai întâi se cripteaz ă datele utile ale taho ­
grafului pentru a asigura confiden țialitatea mesajului, iar 
apoi se calculeaz ă un MAC pentru a asigura autenticitatea 
și integritatea datelor.  
CSM_224 Datele de securitate DSRC constau în concatenarea 
elementelor de date de mai jos, în urm ătoarea ordine; a se 
vedea, de asemenea figura 12:  
Data și ora curente  data și ora curente ale VU (tip de date
  
) 
Contor  un contor de 3 octe ți, a se vedea CSM_225  
▼M1 
Numărul de serie al VU  num ărul de serie al VU sau ID-ul cererii de 
certificat (tipul de date VuSerialNumber sau 
CertificateRequestID) – a se vedea CSM_123  
▼B 
Numărul de versiune al cheii master DSRC  num ărul de versiune de 1 octet al cheii 
master DSRC din care au fost derivate 
cheile DSRC specifice pentru VU (a se 
vedea secțiunea 9.2.2).  
MAC  MAC calculat prin intermediul tuturor 
octeților anteriori din datele RTM.  
CSM_225 Contorul de 3 octe ți din datele de securitate DSRC sunt în 
formatul MSB (cel mai semnificativ octet) la început. Prima 
dată când o VU calculeaz ă un set de date RTM dup ă ce este 
pusă în produc ție, aceasta regleaz ă valoarea contorului la 0. 
De fiecare dat ă înainte de a calcula urm ătorul set de date 
RTM, VU m ărește cu 1 valoarea datelor contorului.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 432  
13.2.  Criptarea datelor utile ale tahografului și generarea MAC  
CSM_226 Fiind dat un element de date cu text simplu având tipul de 
date
 astfel cum este descris în 
apendicele 14, o VU cripteaz ă aceste date dup ă cum este 
indicat în figura 12: Cheia DSRC a VU folosit ă pentru 
criptare, K_VU  DSRC  _ENC (a se vedea sec țiunea 9.2.2), 
este utilizat ă cu AES în modul de func ționare cu înl ănțuirea 
blocurilor cifrate, astfel cum este definit în (ISO 10116), cu 
un parametru intermediar  m = 1. Vectorul de ini țializare este: 
IV =  data și ora curent ă || ‘00 00 00 00 00 00 00 00 00 ’ || 
contor , unde  data și ora curent ă și contorul  sunt specificate 
în CSM_224. Datele care trebuie criptate sunt completate 
folosind metoda 2 definit ă în (ISO 9797-1)  
CSM_227 O VU calculeaz ă MAC din datele de securitate DSRC astfel 
cum este indicat în figura 12: MAC este calculat pe baza 
tuturor octe ților preceden ți din datele RTM, pân ă la numărul 
de versiune al cheii master DSRC (inclusiv acest num ăr) și 
incluzând etichetele și lungimile obiectelor de date. VU î și 
utilizează cheia DSRC pentru a verifica autenticitatea 
K_VU  DSRC  _MAC (a se vedea sec țiunea 9.2.2) cu algoritmul 
AES în modul CMAC, astfel cum este specificat în (SP 800- 
38B). Lungimea MAC este legat ă de lungimea cheilor 
DSRC specifice pentru VU, astfel cum este specificat în 
CSM_50.  
Figura 12  
Criptarea datelor utile ale tahografului și generarea MAC
  
13.3.  Verificarea și decriptarea datelor utile ale tahografului  
CSM_228 Atunci când un echipament de interogare la distan ță primește 
date RTM de la o VU, acesta trimite toate datele RTM la un 
card de control în câmpul de date al unei comenzi 
PROCESS DSRC MESSAGE, astfel cum este descris în 
apendicele 2. În acest caz:  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 433  
1. Cardul de control inspecteaz ă numărul de versiune al 
cheii master DSRC din datele de securitate DSRC. În 
cazul în care cardul de control nu cunoa ște cheia master 
DSRC indicat ă, acesta trimite înapoi un mesaj de eroare 
specificat în anexa 2 și abandoneaz ă procesul.  
▼M1 
2. Cardul de control utilizeaz ă cheia master DSRC indicat ă 
în combina ție cu num ărul de serie al VU sau cu ID-ul 
cererii de certificat din datele de securitate DSRC pentru 
a deriva cheile DSRC specifice pentru VU, și anume 
K_VU  DSRC  _ENC și K_VU  DSRC  _MAC, astfel cum este 
specificat în CSM_124.  
▼B 
3. Cardul de control utilizeaz ă K_VU  DSRC  _MAC pentru a 
verifica MAC în datele de securitate DSRC, astfel cum 
este specificat în CSM_227. Dac ă MAC este incorect, 
cardul de control trimite înapoi un mesaj de eroare 
specificat în apendicele 2 și abandoneaz ă procesul.  
4. Cardul de control utilizeaz ă K_VU  DSRC  _ENC pentru a 
decripta datele utile criptate ale tahografului, astfel cum 
este specificat în CSM_226. Cardul de control elimin ă 
completarea și trimite datele utile decriptate ale taho ­
grafului către echipamentul de interogare la distan ță. 
CSM_229 Pentru a preveni atacurile prin reluare, echipamentul de inte ­
rogare la distan ță verifică dacă datele RTM sunt reînnoite 
verificând faptul c ă data și ora curente  din datele de secu ­
ritate DSRC nu se abat prea mult de la ora curent ă a echi­
pamentului de interogare la distan ță. 
Note:  
— Pentru aceast ă verificare este necesar ca echipamentul de 
interogare la distan ță să dispună de o sursă de indicare a 
orei exactă și fiabilă. 
— Întrucât conform cerin țelor din apendicele 14, VU trebuie 
să calculeze un nou set de date RTM la fiecare 60 de 
secunde, iar ceasul VU poate avea o abatere de 1 minut 
de la ora real ă, o limită mai acceptabil ă pentru reînnoirea 
datelor RTM este de 2 minute. Reînnoirea real ă a datelor 
care trebuie prev ăzută depinde, de asemenea, de exac ­
titatea ceasului echipamentului de interogare la distan ță. 
CSM_230 Atunci când un atelier verific ă funcționarea corect ă a 
funcționalității DSRC a unei VU, acesta trimite totalitatea 
datelor RTM primite de la VU unui card de atelier în 
câmpul de date al unei comenzi PROCESS DSRC 
MESSAGE, astfel cum este descris în apendicele 2. Cardul 
de atelier efectueaz ă toate verific ările și acțiunile specificate 
în CSM_228.  
14. SEMNAREA DESC ĂRCĂRII DE DATE ȘI VERIFICAREA SEMN Ă­
TURILOR  
14.1.  Considera ții generale  
CSM_231 Echipamentul inteligent dedicat (IDE) stocheaz ă într-un 
singur fișier fizic de date datele primite de la o VU sau de 
la un card în timpul unei sesiuni de desc ărcare. Datele pot fi 
stocate pe un suport de memorie extern (ESM). Acest fi șier 
conține semnături digitale de blocuri de date, astfel cum este 
specificat în apendicele 7. Fi șierul men ționat mai sus 
conține, de asemenea, urm ătoarele certificate (a se vedea 
secțiunea 9.1):  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 434  
— În cazul unei desc ărcări de pe o VU:  
— Certificatul VU_Sign  
— Certificatul MSCA_VU-EGF care con ține cheia 
publică destinată utilizării pentru verificarea certifi ­
catului VU_Sign  
— În cazul unei desc ărcări de pe un card:  
— Certificatul Card_Sign  
— Certificatul MSCA_Card care con ține cheia public ă 
destinată verificării certificatului Card_Sign  
CSM_232 IDE dispune, de asemenea, de:  
— În cazul în care acesta utilizeaz ă un card de control 
pentru verificarea semn ăturii, astfel cum este indicat în 
figura 13: Certificatul de leg ătură care leag ă cel mai 
recent certificat EUR de certificatul EUR a c ărui 
perioadă de valabilitate este imediat anterioar ă acestui 
celui mai recent certificat EUR, dac ă acesta exist ă. 
— În cazul în care verific ă chiar el semn ătura: toate certifi ­
catele rădăcină europene valabile.  
Notă: metoda folosit ă de IDE pentru a ob ține aceste certi ­
ficate nu este specificat ă în prezentul apendice.  
14.2.  Generarea semn ăturilor  
CSM_233 Algoritmul de semnare utilizat pentru a crea semn ături prin 
intermediul datelor desc ărcate este ECDSA, astfel cum este 
precizat în [DSS], folosindu-se algoritmul de  hashing  legat 
de mărimea cheilor VU sau ale cardului, astfel cum este 
specificat în CSM_50. Formatul semn ăturii este simplu, 
astfel cum este precizat în (TR-03111).  
14.3.  Verificarea semn ăturilor  
CSM_234  ►M1 Un IDE poate efectua verificarea unei semn ături pe 
baza datelor desc ărcate în mod nemijlocit sau poate utiliza 
un card de control în acest scop. În cazul în care utilizeaz ă 
un card de control, verificarea semn ăturii se efectueaz ă astfel 
cum este indicat în figura 13. Pentru a verifica valabilitatea 
temporală a unui certificat prezentat de IDE, cardul de 
control își utilizeaz ă ora curent ă internă, astfel cum se 
precizează în CSM_167. Un card de control î și actualizeaz ă 
ora curentă dacă momentul la care începe valabilitatea unui 
certificat autentic de tip „surs ă valabilă de indicare a orei” 
este mai recent decât ora curent ă a cardului. Cardul accept ă 
doar următoarele certificate ca surs ă valabilă de indicare a 
orei: 
— Certificatele de leg ătură ERCA de a doua genera ție 
— Certificatele MSCA de a doua genera ție 
— Certificatele VU_Sign sau Card_Sign de a doua genera ție 
emise de aceea și țară care a emis certificatul de card al 
cardului de control.  
În cazul în care IDE efectueaz ă nemijlocit verificarea semn ă­
turii, acesta verific ă autenticitatea și valabilitatea tuturor 
certificatelor din lan țul de certificate din fi șierul de date și 
verifică semnătura prin intermediul datelor, urmând schema 
de semnătură definită în [DSS]. În ambele cazuri, pentru 
fiecare certificat citit din fi șierul de date, este necesar s ă se 
verifice dac ă este corect câmpul privind autoriza ția 
deținătorului certificatului (CHA):  
— Câmpul CHA al certificatului EQT indic ă un certificat 
VU sau un certificat de card (dup ă caz) pentru semnare 
(a se vedea apendicele 1, tipul de date EquipmentType).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 435  
— CHA al certificatului EQT.CA indic ă o MSCA.  
— CHA al certificatului EQT.Link indic ă ERCA. ◄ 
Note la figura 13:  
— Echipamentul care a semnat datele de analizat este 
denumit EQT.  
— Certificatele EQT și cheile publice men ționate în figur ă 
sunt cele utilizate pentru semnare, și anume VU_Sign 
sau Card_Sign.  
— Certificatele și cheile publice EQT.CA men ționate în 
figură sunt cele utilizate pentru semnarea certificatelor 
VU sau a celor de card, dup ă caz.  
— Certificatul EQT.CA.EUR men ționat în figur ă este certi­
ficatul rădăcină european precizat în CAR al certifi ­
catului EQT.CA.  
— Certificatul EQT.Link men ționat în figur ă este certificatul 
de legătură al EQT, dac ă acesta exist ă. Astfel cum este 
specificat în sec țiunea 9.1.2, acesta este un certificat de 
legătură pentru o nou ă pereche de chei r ădăcină europene 
create de ERCA și semnate cu cheia privat ă europeană 
anterioară. 
— Certificatul EQT.Link.EUR este certificatul r ădăcină 
european precizat în CAR al certificatului EQT.Link.  
CSM_235 Pentru a calcula func ția hash  a mesajului M trimis c ătre 
cardul de control în comanda PSO:Hash, IDE utilizeaz ă 
algoritmul de  hashing  legat de m ărimea cheii VU sau a 
cardului de pe care se descarc ă datele, astfel cum este 
specificat în CSM_50.  
CSM_236 Pentru a verifica semn ătura EQT, cardul de control trebuie s ă 
respecte schema de semn ătură definită în [DSS].  
Notă: Prezentul document nu precizeaz ă nicio acțiune care 
să fie întreprins ă în cazul în care o semn ătură prin inter ­
mediul unui fi șier de date desc ărcat nu poate fi verificat ă 
sau dacă verificarea are un rezultat negativ.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 436  
Figura 13  
Protocol pentru verificarea semn ăturii prin intermediul unui fi șier de date desc ărcate
  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 437  
Apendicele 12  
POZIȚIONAREA BAZAT Ă PE SISTEMUL GLOBAL DE NAVIGA ȚIE 
PRIN SATELIT (GNSS)  
CUPRINS  
1. INTRODUCERE  
1.1. Domeniu de aplicare  
1.2. Acronime și notații 
2. SPECIFICA ȚIA RECEPTORULUI GNSS  
3. PROPOZI ȚIILE NMEA  
4. UNITATE MONTAT Ă PE VEHICUL CU UN ECHIPAMENT 
GNSS EXTERN  
4.1. Configura ție 
4.1.1 Componente principale și interfețe 
4.1.2 Starea echipamentului GNSS extern la finalul procesului de 
producție 
4.2. Comunicarea între echipamentul GNSS extern și unitatea montat ă 
pe vehicul  
4.2.1 Protocolul de comunicare  
4.2.2 Transferul securizat de date GNSS  
4.2.3 Structura comenzii de citire a înregistr ării (Read Record)  
4.3. Cuplarea, autentificarea reciproc ă și înțelegerea asupra cheii de 
sesiune a echipamentului GNSS extern cu unitatea montat ă pe 
vehicul  
4.4. Gestionarea erorilor  
4.4.1 Eroare de comunicare cu echipamentul GNSS extern  
4.4.2 Înc ălcarea integrit ății fizice a echipamentului GNSS extern  
4.4.3 Absen ța informațiilor de pozi ționare de la receptorul GNSS  
4.4.4 Certificatul echipamentului GNSS extern a expirat  
5. UNITATE MONTAT Ă PE VEHICUL F ĂRĂ UN ECHIPAMENT 
GNSS EXTERN  
5.1. Configura ție 
5.2. Gestionarea erorilor  
5.2.1 Absen ța informațiilor de pozi ționare de la receptorul GNSS  
6. CONFLICT OR Ă GNSS  
7. CONFLICT PRIVIND DEPLASAREA VEHICULULUI  
1. INTRODUCERE  
Prezentul apendice prevede cerin țele tehnice pentru datele GNSS utilizate 
de unitatea montat ă pe vehicul, inclusiv protocoalele care trebuie imple ­
mentate pentru a asigura transferul de date corect și în siguran ță al 
informațiilor de pozi ționare.  
Principalele articole din Regulamentul (UE) nr. 165/2014 care impun 
aceste cerin țe sunt: „Articolul 8 Înregistrarea pozi ției vehiculului în 
anumite puncte în timpul zilei de lucru”, „Articolul 10 Interfa ța cu 
sistemele de transport inteligente” și „Articolul 11 Dispozi ții detaliate 
pentru tahograful inteligent”.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 438  
1.1. Domeniu de aplicare  
GNS_1 Unitatea montat ă pe vehicul colecteaz ă date de localizare cel 
puțin de la un GNSS pentru a sprijini punerea în aplicare a 
articolului 8.  
Unitatea montat ă pe vehicul poate fi dotat ă sau nu cu un echipament 
GNSS extern, astfel cum este descris în Figura 1:  
Figura 1  
Diferite configura ții pentru receptorul GNSS.
  
1.2. Acronime și notații 
În prezentul apendice sunt folosite urm ătoarele acronime:  
DOP  Dilution of Precision  (Scădere a preciziei)  
EGF Fi șier elementar Dispozitiv GNSS ( Elementary file GNSS 
Facility ) 
EGNOS Serviciul european geosta ționar mixt de navigare ( European 
Geostationary Navigation Overlay Service ) 
GNSS Sistem global de naviga ție prin satelit ( Global Navigation 
Satellite System ) 
GSA GPS DOP și sateliți activi  
HDOP  Horizontal Dilution of Precision  (Scădere a preciziei în plan 
orizontal)  
ICD Document de control al interfe ței 
NMEA National Marine Electronics Association  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 439  
PDOP  Position Dilution of Precision  (Diminuare a preciziei ca 
urmare a pozi ționării sateliților) 
RMC Recommended Minimum Specific  
SIS Semnal în spa țiu (Signal in Space ) 
VDOP  Vertical Dilution of Precision  (Scădere a preciziei în plan 
vertical)  
VU Unitate montat ă pe vehicul ( Vehicle Unit ) 
2. SPECIFICA ȚIA RECEPTORULUI GNSS  
Indiferent de configura ția tahografului inteligent, cu sau f ără un echi­
pament GNSS extern, furnizarea de informa ții de poziționare exacte și 
fiabile reprezint ă un element esen țial pentru func ționarea eficient ă a taho­
grafului inteligent. Prin urmare, este oportun s ă se solicite compatibi ­
litatea acestuia cu serviciile furnizate de programele Galileo și 
Serviciul european geosta ționar mixt de navigare (EGNOS), astfel cum 
sunt prevăzute în Regulamentul (UE) nr. 1285/2013 al Parlamentului 
European și al Consiliului (  1 ). Sistemul constituit în cadrul programului 
Galileo este un sistem global de naviga ție prin satelit independent, iar cel 
constituit în cadrul programului EGNOS este un sistem regional de 
navigație prin satelit, care îmbun ătățește calitatea semnalului sistemului 
de poziționare global ă. 
GNS_2 Produc ătorii garanteaz ă că receptoarele GNSS din tahografele 
inteligente sunt compatibile cu serviciile de pozi ționare 
furnizate de sistemele Galileo și EGNOS. De asemenea, 
producătorii pot alege, în plus, compatibilitatea cu alte 
sisteme de naviga ție prin satelit.  
GNS_3 Receptorul GNSS trebuie s ă fie compatibil cu autentificarea pe 
serviciul deschis al Galileo atunci când acest serviciu va fi 
furnizat de sistemul Galileo și integrat de produc ătorii de 
receptoare GNSS. Totu și, pentru tahografele inteligente 
introduse pe pia ță înainte de a fi îndeplinite condi țiile 
susmenționate și care nu sunt compatibile cu autentificarea 
pe serviciul deschis al Galileo, reabilitarea nu va fi obligatorie.  
3. PROPOZI ȚIILE NMEA  
Această secțiune descrie propozi țiile NMEA utilizate în func ționarea 
tahografului inteligent. Aceast ă secțiune este valabil ă atât pentru 
configurația tahografului inteligent cu echipament GNSS extern, cât și 
a celui fără echipament GNSS extern.  
GNS_4 Datele de localizare se bazeaz ă pe propozi ția NMEA  Recom­
mended Minimum Specific (RMC) GNSS Data , care con ține 
informații de pozi ționare (latitudine, longitudine), ora în 
format UTC (hhmmss.ss), viteza fa ță de sol în noduri plus 
valori suplimentare.  
Formatul propozi ției RMC este urm ătorul (conform standardului 
NMEA V4.1):  ▼B 
( 1 ) Regulamentul (UE) nr. 1285/2013 al Parlamentului European și al Consiliului din 
11 decembrie 2013 privind punerea în aplicare și exploatarea sistemelor europene de 
radionaviga ție prin satelit și de abrogare a Regulamentului (CE) nr. 876/2002 al 
Consiliului și a Regulamentului (CE) nr. 683/2008 al Parlamentului European și al 
Consiliului (JO L 347, 20.12.2013, p. 1).
 02016R0799 — RO — 26.02.2020 — 002.001 — 440  
Figura 2  
Structura propozi ției RMC
  
Statutul ( Status ) indică dacă semnalul GNSS este disponibil. Pân ă când 
valoarea statutului nu este setat ă la A, datele primite (de exemplu, refe ­
ritoare la or ă sau latitudine/longitudine) nu pot fi utilizate pentru înregis ­
trarea pozi ției vehiculului în VU.  
▼M1 
Rezoluția poziției se bazeaz ă pe formatul propozi ției RMC descris mai 
sus. Prima parte din câmpurile (3) și (5) se utilizeaz ă pentru a reprezenta 
gradele. Restul se utilizeaz ă pentru a reprezenta minutele cu trei 
zecimale. Astfel, rezolu ția este 1/1000 de minut sau 1/60000 de grad 
(deoarece un minut este 1/60 dintr-un grad).  
GNS_5 Unitatea montat ă pe vehicul stocheaz ă în baza de date a VU 
informațiile de pozi ționare pentru latitudine și longitudine cu o 
rezoluție de 1/10 de minut sau 1/600 de grad, astfel cum este 
descris în apendicele 1 pentru tipul GeoCoordinates.  
Comanda GPS DOP și sateliți activi (GSA) poate fi utilizat ă 
de VU pentru a determina și a înregistra disponibilitatea și 
precizia semnalului. În special HDOP este utilizat ă pentru a 
furniza o indica ție cu privire la gradul de precizie a datelor de 
localizare înregistrate (a se vedea 4.2.2). VU va înregistra 
valoarea Horizontal Dilution of Precision (HDOP), calculat ă 
ca cea mai mic ă dintre valorile HDOP colectate de la sistemele 
GNSS disponibile.  
GNSS Id. indic ă NMEA Id. corespunz ător pentru fiecare 
constelație GNSS și sistem de augmentare cu ajutorul 
sateliților (SBAS).  
Figura 3  
Structura propozi ției GSA
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 441  
GNS_6 Propozi ția GSA este stocat ă cu număr de înregistrare „02”- 
„06”.  
▼B 
GNS_7 Dimensiunea maxim ă a propozi țiilor NMEA (de exemplu, 
RMC, GSA sau altele), care poate fi utilizat ă pentru dimen ­
sionarea comenzii de citire a înregistr ării (Read Record ) este 
de 85 de octe ți (a se vedea Tabelul 1).  
4. UNITATE MONTAT Ă PE VEHICUL CU UN ECHIPAMENT GNSS 
EXTERN  
4.1. Configura ție 
4.1.1  Componente principale și interfețe 
În această configura ție, receptorul GNSS face parte din echipamentul 
GNSS extern.  
GNS_8 Echipamentul GNSS extern trebuie s ă fie alimentat cu o 
interfață specifică a vehiculului.  
GNS_9 Echipamentul GNSS extern const ă în următoarele componente 
(a se vedea Figura 4):  
a) Un receptor GNSS comercial care s ă furnizeze datele de 
poziționare prin interfa ța de date GNSS. De exemplu, 
interfața de date GNSS poate fi standardul NMEA V4.10, 
unde receptorul GNSS ac ționează ca un emi țător și 
transmite propozi ții NMEA c ătre transceiverul securizat 
GNSS cu o frecven ță de 1 Hz pentru setul predefinit de 
propoziții NMEA, care trebuie s ă cuprindă cel puțin 
propozițiile RMC și GSA. Implementarea interfe ței de 
date GNSS este la alegerea produc ătorilor de echipament 
GNSS extern.  
b) O unitate de emisie-recep ție (transceiver securizat GNSS), 
compatibil ă cu standardul ISO/IEC 7816-4:2013 (a se 
vedea 4.2.1) pentru a comunica cu unitatea montat ă pe 
vehicul și compatibil ă cu interfa ța de date GNSS pentru 
receptorul GNSS. Unitatea este prev ăzută cu o memorie 
pentru stocarea datelor de identificare ale receptorului 
GNSS și ale echipamentului GNSS extern.  
c) Un sistem de încapsulare cu func ție de detectare a mani ­
pulărilor frauduloase, care încapsuleaz ă atât receptorul 
GNSS, cât și transceiverul securizat GNSS. Func ția de 
detectare a manipul ărilor frauduloase implementeaz ă 
măsurile de protec ție a securit ății conform cerin țelor din 
profilul de protec ție al tahografului inteligent.  
d) O anten ă GNSS instalat ă pe vehicul și conectat ă la 
receptorul GNSS prin sistemul de încapsulare.  
GNS_10 Echipamentul GNSS extern are cel pu țin următoarele interfe țe 
externe:  
a) interfața cu antena GNSS instalat ă pe remorca vehiculului, 
dacă se utilizeaz ă o antenă externă; 
b) interfața cu unitatea montat ă pe vehicul.  
GNS_11 În VU, transceiverul securizat VU este cel ălalt capăt al comu­
nicării securizate cu transceiverul securizat GNSS și trebuie să 
fie compatibil cu ISO/IEC 7816-4:2013 pentru conectarea la 
echipamentul GNSS extern.  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 442  
GNS_12 Pentru nivelul fizic al comunic ării cu echipamentul GNSS 
extern, unitatea montat ă pe vehicul trebuie s ă fie compatibil ă 
cu ISO/IEC 7816-12: 2005 sau cu un alt standard compatibil 
cu ISO/IEC 7816-4: 2013. (a se vedea 4.2.1).  
4.1.2  Starea echipamentului GNSS extern la finalul procesului de produc ție 
GNS_13 Echipamentul GNSS extern stocheaz ă următoarele valori în 
memoria nevolatil ă a transceiverului securizat GNSS atunci 
când părăsește fabrica:  
— perechea de chei EGF_MA și certificatul corespunz ător, 
— certificatul MSCA_VU-EGF care con ține cheia public ă 
MSCA_VU-EGF.PK care trebuie utilizat ă pentru veri ­
ficarea certificatului EGF_MA,  
— certificatul EUR care con ține cheia public ă EUR.PK care 
trebuie utilizat ă pentru verificarea certificatului 
MSCA_VU-EGF,  
— certificatul EUR a c ărui perioad ă de valabilitate precede 
direct perioada de valabilitate a certificatului EUR care 
trebuie utilizat pentru verificarea certificatului 
MSCA_VU-EGF, dac ă există, 
— certificatul leg ătură care leagă aceste dou ă certificate EUR, 
dacă există, 
— numărul de serie lung al echipamentului GNSS extern,  
— identificatorul sistemului de operare al echipamentului 
GNSS,  
— numărul de omologare de tip al echipamentului GNSS 
extern,  
— identificatorul componentei de securitate a modulului 
GNSS extern.  
4.2. Comunicarea între echipamentul GNSS extern și unitatea montat ă pe 
vehicul  
4.2.1  Protocolul de comunicare  
GNS_14 Protocolul de comunicare între echipamentul GNSS extern și 
unitatea montat ă pe vehicul asigur ă trei funcții: 
1. Colectarea și distribuirea datelor GNSS (de exemplu, 
poziția, ora, viteza),  
2. Colectarea datelor de configura ție ale echipamentului 
GNSS extern,  
3. Protocolul de gestionare pentru a asigura cuplarea, autenti ­
ficarea reciproc ă și înțelegerea asupra cheii de sesiune între 
echipamentul GNSS extern și VU.  
GNS_15 Protocolul de comunicare se bazeaz ă pe standardul ISO/IEC 
7816-4: 2013 unde transceiverul securizat VU de ține rolul de  
master , iar transceiverul securizat GNSS de ține rolul de  slave . 
Conexiunea fizic ă între echipamentul GNSS extern și unitatea 
montată pe vehicul se bazeaz ă pe ISO/IEC 7816-12:2005 sau 
pe un alt standard compatibil cu ISO/IEC 7816-4:2013.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 443  
GNS_16 În protocolul de comunicare, nu sunt suportate câmpuri cu 
lungime extins ă. 
▼B 
GNS_17 Protocolul de comunicare din ISO 7816 (atât *-4:2013, cât și 
*-12:2005) dintre echipamentul GNSS extern și VU se seteaz ă 
la T=1.  
▼M1 
GNS_18 În ceea ce prive ște funcțiile 1. colectarea și distribuirea datelor 
GNSS, 2. colectarea datelor de configura ție ale echipamentului 
GNSS extern și 3. protocolul de gestionare, transceiverul 
securizat GNSS simuleaz ă un card inteligent cu o arhitectur ă 
a sistemului de fi șiere compus ă dintr-un fi șier master (MF), un 
fișier dedicat (DF) cu identificatorul aplica ției specificat în 
apendicele 1 capitolul 6.2 („FF 44 54 45 47 4D”) și cu 3 
EF care con țin certificate și un singur fi șier elementar 
(EF.EGF) cu identificatorul fi șierului egal cu „2F2F” 
conform descrierii din tabelul 1.  
▼B 
GNS_19 Transceiverul securizat GNSS stocheaz ă datele care provin de 
la receptorul GNSS și configura ția în EF.EGF. Acesta este un 
fișier de înregistrare liniar de lungime variabil ă cu un identi ­
ficator egal cu ‘2F2F’ în format hexadecimal.  
▼M1 
GNS_20 Transceiverul securizat GNSS utilizeaz ă o memorie pentru 
stocarea datelor și are o capacitate de cel pu țin 20 de 
milioane de cicluri de scriere/citire. În afar ă de acest aspect, 
proiectarea intern ă și implementarea transceiverului securizat 
GNSS rămân la latitudinea produc ătorilor.  
Maparea numerelor înregistr ărilor și a datelor este furnizat ă în 
tabelul 1. Se men ționează faptul că există cinci propozi ții GSA 
pentru constela țiile GNSS și sistemul de augmentare cu 
ajutorul sateli ților (SBAS).  
▼B 
GNS_21 Structura fi șierelor este furnizat ă în Tabelul 1. Pentru condi țiile 
de acces (ALW, NEV, SM-MAC) a se vedea apendicele 2 
capitolul 3.5.  
Tabelul 1  
Structura fi șierelor  
Condiții de acces  
Fișier ID fi șier Citire  Actualizare  Criptat  
MF 3F00  
EF.ICC  0002  ALW  NEV 
(de VU)  Nu 
DF Echipament GNSS  0501  ALW  NEV  Nu  
EF EGF_MACertificate  C100  ALW  NEV  Nu  
EF CA_Certificate  C108  ALW  NEV  Nu  
EF Link_Certificate  C109  ALW  NEV  Nu  
EF.EGF  2F2F  SM-MAC  NEV 
(de VU)  Nu ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 444  
Fișier / element de date  Num ărul înregistr ării Dimensiune (octe ți) Valori implicite  
Min Max  
MF 552  1 031  
EF.ICC  
sensorGNSSSerialNumber  8  8  
DF Echipament GNSS  612  1 023  
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  
Propoziție RMC NMEA  ‘01’  85  85  
Prima propozi ție GSA NMEA  ‘02’  85  85  
A 2-a propozi ție GSA NMEA  ‘03’  85  85  
A 3-a propozi ție GSA NMEA  ‘04’  85  85  
A 4-a propozi ție GSA NMEA  ‘05’  85  85  
A 5-a propozi ție GSA NMEA  ‘06’  85  85  
Numărul de serie lung al echipa ­
mentului GNSS extern definit în apen ­
dicele 1 ca SensorGNSSSerialNumber.  ‘07’ 8  8  
Identificatorul sistemului de operare al 
transceiverului securizat GNSS definit 
în apendicele 1 ca SensorOSIdentifier.  ‘08’ 2  2  
Numărul de omologare de tip al echipa ­
mentului GNSS extern definit în apen ­
dicele 1 ca SensorExternalGNSSAppro ­
valNumber.  ‘09’ 16  16  
Identificatorul componentei de securitate 
a echipamentului GNSS extern definit 
în apendicele 1 ca SensorExternal ­
GNSSSCIdentifier.  ‘10’ 8  8  
RFU – Rezervat pentru o utilizare viitoare  De la ‘11’ la ‘FD’  
4.2.2  Transferul securizat de date GNSS  
GNS_22 Transferul securizat de date de pozi ționare GNSS este permis 
numai în urm ătoarele condi ții: 
1. Procesul de cuplare a fost încheiat, astfel cum este descris 
în apendicele 11. „Mecanisme de securitate comune”.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 445  
2. Autentificarea reciproc ă periodică și înțelegerea asupra 
cheii de sesiune dintre VU și echipamentul GNSS extern 
descrisă, de asemenea, în apendicele 11. „Mecanisme de 
securitate comune” a fost executat ă cu frecven ța indicată. 
GNS_23 La fiecare T secunde, unde T reprezint ă o valoare mai mic ă 
sau egală cu 10, cu excep ția cazului în care are loc cuplarea 
sau autentificarea reciproc ă și înțelegerea asupra cheii de 
sesiune, VU solicit ă de la echipamentul GNSS extern infor ­
mațiile de pozi ționare pe baza urm ătorului flux:  
1. VU solicit ă date de localizare de la echipamentul GNSS 
extern, împreun ă cu date  Dilution of Precision  (de la 
propoziția GSA NMEA). Transceiverul securizat VU 
utilizează comenzile SELECT și READ RECORD(S) în 
conformitate cu standardul ISO/IEC 7816-4:2013 în 
modul doar de autentificare al mesageriei securizate, 
conform descrierii din apendicele 11 sec țiunea 11.5 cu 
identificatorul fi șierului „2F2F” și numărul RECORD egal 
cu „01” pentru propozi ția RMC NMEA și 
‘02’,‘03’,‘04’,‘05’,‘06’ pentru propozi ția GSA NMEA.  
2. Ultimele date de localizare primite sunt stocate în EF cu 
identificatorul ‘2F2F’ și înregistrările descrise în Tabelul 1 
în transceiverul securizat GNSS deoarece transceiverul 
securizat GNSS recep ționează date NMEA cu o frecven ță 
de cel puțin 1 Hz de la receptorul GNSS prin interfa ța de 
date GNSS.  
3. Transceiverul securizat GNSS trimite r ăspunsul la trans ­
ceiverul securizat VU folosind mesajul de r ăspuns APDU 
în modul doar de autentificare al mesageriei securizate, 
conform descrierii din apendicele 11 sec țiunea 11.5.  
4. Transceiverul securizat VU verific ă autenticitatea și inte­
gritatea răspunsului primit. În cazul unui rezultat pozitiv, 
datele de localizare sunt transferate c ătre procesorul VU 
prin interfa ța de date GNSS.  
▼M1 
5. Procesorul VU verific ă datele primite și extrage informa țiile 
(de exemplu, latitudinea, longitudinea, ora) din propozi ția 
RMC NMEA. Propozi ția RMC NMEA include informa ții 
privind valabilitatea pozi ției. În cazul în care pozi ția nu este 
valabilă, datele de localizare nu sunt înc ă disponibile și nu 
pot fi utilizate pentru înregistrarea pozi ției vehiculului. 
Dacă poziția este valabil ă, procesorul VU extrage, de 
asemenea,valorile HDOP din propozi țiile GSA NMEA și 
calculează valoarea minim ă pe baza sistemelor prin satelit 
disponibile (de exemplu, când  fix este disponibil).  
▼B 
6. Procesorul VU stocheaz ă informațiile primite și prelucrate, 
cum ar fi latitudinea, longitudinea, ora și viteza, în formatul 
definit în apendicele 1 „Dic ționar de date” ca GeoCoordi ­
nates, împreun ă cu valoarea HDOP calculat ă ca valoarea 
minimă a valorilor HDOP colectate pe baza sistemelor 
GNSS disponibile.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 446  
4.2.3  Structura comenzii de citire a înregistr ării (Read Record)  
Această secțiune descrie în detaliu structura comenzii de citire a înregis ­
trării (Read Record ). Mesageria securizat ă (modul doar de autentificare) 
este adăugată conform descrierii din apendicele 11 „Mecanisme de secu ­
ritate comune”.  
GNS_24 Comanda trebuie s ă fie compatibil ă cu modul doar autenti ­
ficare al mesageriei securizate, cf. apendicele 11.  
GNS_25 Mesaj de comand ă 
Octet  Lungime  Valoare  Descriere  
CLA  1  ‘0Ch’  Mesagerie securizat ă solicitată. 
INS 1  ‘B2h’  Citește înregistrarea  
P1 1  ‘XXh’  Numărul înregistr ării (‘00’ indic ă înregis­
trarea curent ă) 
P2 1  ‘04h’  Citește înregistrarea cu num ărul înregistr ării 
indicat în P1  
Le 1  ‘XXh’  Lungimea datelor a șteptate. Num ărul de 
octeți de citit.  
GNS_26 Înregistrarea indicat ă în P1 devine înregistrarea curent ă. 
Octet  Lungime  Valoare  Descriere  
#1-#X  X  ‘XX..XXh’  Date citite  
SW 2  ‘XXXXh’  Cuvinte de stare (SW1, SW2)  
— În cazul în care comanda este executat ă cu succes, trans ­
ceiverul securizat GNSS returneaz ă ‘9000 ’. 
— În cazul în care fi șierul curent nu este orientat pe înregis ­
trare, transceiverul securizat GNSS returneaz ă ‘6981 ’. 
— În cazul în care comanda este utilizat ă cu P1 = ‘00’, dar nu 
există niciun EF curent, transceiverul securizat GNSS 
returnează ‘6986 ’ (comandă nepermisă). 
— În cazul în care înregistrarea nu este g ăsită, transceiverul 
securizat GNSS returneaz ă ‘6A 83 ’. 
— În cazul în care echipamentul GNSS extern a detectat 
manipulare frauduloas ă, returneaz ă cuvintele de stare ‘ 66 
90’. 
GNS_27 Transceiverul securizat GNSS trebuie s ă fie compatibil cu 
următoarele comenzi de tahograf de genera ția 2 specificate 
în apendicele 2:  
Comandă Referin ță 
Select  Apendicele 2 capitolul 3.5.1  
Read Binary  Apendicele 2 capitolul 3.5.2  
Get Challenge  Apendicele 2 capitolul 3.5.4  
PSO: Verify Certificate  Apendicele 2 capitolul 3.5.7  
External Authenticate  Apendicele 2 capitolul 3.5.9  
General Authenticate  Apendicele 2 capitolul 3.5.10  
MSE:SET  Apendicele 2 capitolul 3.5.11  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 447  
4.3. Cuplarea, autentificarea reciproc ă și înțelegerea asupra cheii de 
sesiune a echipamentului GNSS extern cu unitatea montat ă pe 
vehicul  
Cuplarea, autentificarea reciproc ă și înțelegerea asupra cheii de sesiune a 
echipamentului GNSS extern cu unitatea montat ă pe vehicul este descris ă 
în apendicele 11 – „Mecanisme de securitate comune”, capitolul 11.  
4.4. Gestionarea erorilor  
Prezenta sec țiune descrie modul în care condi țiile de eroare poten țiale ale 
echipamentului GNSS extern sunt tratate și înregistrate în VU.  
4.4.1  Eroare de comunicare cu echipamentul GNSS extern  
▼M1 
GNS_28 În cazul în care VU nu reu șește să comunice cu echipamentul 
GNSS extern cuplat timp de mai mult de 20 de minute 
consecutive, VU genereaz ă și înregistreaz ă în VU un 
eveniment de tipul EventFaultType cu valoarea de enumerare 
‘0E’H Eroare de comunicare cu echipamentul GNSS extern și 
cu marca temporal ă setată la ora curent ă. Acest eveniment va 
fi generat numai dac ă sunt îndeplinite urm ătoarele dou ă 
condiții: (a) tahograful inteligent nu este în modul etalonare; 
și (b) vehiculul este în mi șcare. În acest context, este 
declanșată o eroare de comunicare atunci când transceiverul 
securizat VU nu prime ște un mesaj de r ăspuns după un mesaj 
de solicitare, conform descrierii din 4.2.  
▼B 
4.4.2  Încălcarea integrit ății fizice a echipamentului GNSS extern  
▼M1 
GNS_29 În cazul în care echipamentul GNSS extern a fost manipulat 
fraudulos, transceiverul securizat GNSS șterge integral 
memoria acestuia, inclusiv materialul criptografic. Astfel cum 
este descris în GNS_25 și GNS_26, VU detecteaz ă mani­
pularea frauduloas ă dacă răspunsul are starea „6690”. VU 
generează apoi un eveniment de tipul EventFaultType cu 
valoarea de enumerare ‘19’H Detectare a manipul ării frau­
duloase a GNSS. În mod alternativ, echipamentul GNSS 
extern poate s ă nu mai răspundă niciunei cereri externe.  
▼B 
4.4.3  Absența informa țiilor de pozi ționare de la receptorul GNSS  
▼M1 
GNS_30 În cazul în care transceiverul securizat GNSS nu prime ște date 
de la receptorul GNSS timp de mai mult de 3 ore consecutive, 
transceiverul securizat GNSS va genera un mesaj de r ăspuns 
pentru comanda READ RECORD cu num ărul RECORD egal 
cu „01”, cu un câmp de date de 12 octe ți setați toți la 0xFF. 
La primirea mesajului de r ăspuns cu aceast ă valoare a 
câmpului de date, VU genereaz ă și înregistreaz ă un 
eveniment de tipul EventFaultType cu valoarea de enumerare 
‘0D’H Absen ța informațiilor de pozi ționare de la receptorul 
GNSS, cu o marc ă temporală egală cu valoarea curent ă a 
orei numai dac ă sunt îndeplinite urm ătoarele dou ă condiții: 
(a) tahograful inteligent nu este în modul etalonare; și (b) 
vehiculul este în mi șcare. 
▼B 
4.4.4  Certificatul echipamentului GNSS extern a expirat  
GNS_31  ►M1 Dacă VU detecteaz ă că certificatul EGF utilizat pentru 
autentificarea reciproc ă nu mai este valabil, VU genereaz ă și 
înregistreaz ă un eveniment al aparaturii de înregistrare de tipul 
EventFaultType cu valoarea de enumerare  ‘1B’H Certificatul 
echipamentului GNSS extern expirat  cu o marc ă temporală 
egală cu valoarea curent ă a orei. VU utilizeaz ă în continuare 
datele de pozi ționare GNSS primite. ◄ ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 448  
Figura 4  
Schema echipamentului GNSS extern
  
5. UNITATE MONTAT Ă PE VEHICUL F ĂRĂ UN ECHIPAMENT 
GNSS EXTERN  
5.1. Configura ție 
În această configura ție, receptorul GNSS se afl ă în interiorul unit ății 
montate pe vehicul, conform descrierii din Figura 1.  
GNS_32 Receptorul GNSS ac ționează ca emi țător și transmite 
propoziții NMEA procesorului VU, care ac ționează ca 
receptor cu o frecven ță de 1/10 Hz sau mai rapid pentru 
setul prestabilit de propozi ții NMEA, care include cel pu țin 
propozițiile RMC și GSA.  
GNS_33 O anten ă GNSS extern ă instalată pe vehicul sau o anten ă 
GNSS intern ă trebuie să fie conectat ă la VU.  
5.2. Gestionarea erorilor  
5.2.1  Absența informa țiilor de pozi ționare de la receptorul GNSS  
▼M1 
GNS_34 În cazul în care VU nu prime ște date de la receptorul GNSS 
timp de mai mult de 3 ore consecutive, VU genereaz ă și 
înregistreaz ă un eveniment de tipul EventFaultType cu 
valoarea de enumerare ‘0D’H Absen ța informa țiilor de 
poziționare de la receptorul GNSS, cu o marc ă temporală 
egală cu valoarea curent ă a orei numai dac ă sunt îndeplinite 
următoarele dou ă condiții: (a) tahograful inteligent nu este în 
modul etalonare; și (b) vehiculul este în mi șcare.  
6. CONFLICT OR Ă GNSS  
Dacă VU detecteaz ă o discrepan ță de peste 1 minut între ora indicat ă de 
funcția de măsurare a timpului a unit ății montate pe vehicul și ora 
indicată de receptorul GNSS, VU va înregistra un eveniment de tipul 
EventFaultType cu valoarea de enumerare  ‘0B’H Conflict or ă (GNSS 
versus ceasul intern al VU) . După declanșarea unui eveniment de tip 
„Conflict or ă”, VU nu va mai verifica discrepan ța temporal ă în urmă­
toarele 12 ore. Acest eveniment nu se declan șează în cazul în care 
receptorul GNSS nu a putut detecta niciun semnal GNSS valabil în 
cursul ultimelor 30 de zile.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 449  
7. CONFLICT PRIVIND DEPLASAREA VEHICULULUI  
GNS_35 VU declan șează și înregistreaz ă un eveniment „Conflict 
privind deplasarea vehiculului” (a se vedea cerin ța 84 din 
prezenta anex ă) cu o marc ă temporală egală cu valoarea 
curentă a orei, în cazul în care informa țiile privind deplasarea 
calculate de senzorul de mi șcare sunt contrazise de informa țiile 
privind deplasarea calculate de receptorul GNSS intern sau de 
echipamentul GNSS extern. În scopul detect ării unor astfel de 
contradicții, se utilizeaz ă valoarea median ă a diferen țelor de 
viteză între aceste surse, dup ă cum se precizeaz ă în continuare:  
— la fiecare maximum 10 secunde, se calculeaz ă valoarea 
absolută a diferenței dintre viteza vehiculului estimat ă de 
GNSS și cea estimat ă de senzorul de mi șcare.  
— toate valorile calculate într-o fereastr ă orară care conține 
ultimele cinci minute de deplasare se utilizeaz ă pentru a 
calcula valoarea median ă. 
— valoarea median ă se calculeaz ă ca media a 80 % din 
valorile rămase, dup ă ce s-au eliminat valorile cele mai 
mari în valori absolute.  
Evenimentul „Conflict privind deplasarea vehiculului” se 
declanșează dacă valoarea median ă depășește 10 km/h timp 
de cinci minute neîntrerupte de deplasare a vehiculului. 
Opțional, pot fi utilizate alte surse independente de detectare 
a deplasării vehiculului, pentru a se pune la dispozi ție o 
detectare mai fiabil ă a manipul ărilor tahografului. (Not ă: 
Utilizarea medianei ultimelor 5 minute se aplic ă pentru a 
atenua riscul de m ăsurători aberante și valori tranzitorii). 
Acest eveniment nu se declan șează în următoarele condi ții: 
a) în timpul unei travers ări cu feribotul sau cu trenul, b) 
atunci când informa țiile de pozi ționare de la receptorul 
GNSS nu sunt disponibile și c) în modul etalonare.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 450  
Apendicele 13  
INTERFA ȚA ITS  
CUPRINS  
1. INTRODUCERE  
2. OBIECT  
2.1. Acronime, defini ții și notații 
3. REGULAMENTE ȘI STANDARDE MEN ȚIONATE  
4. PRINCIPIILE DE FUNC ȚIONARE A INTERFE ȚEI 
4.1. Condi ții prealabile pentru transferul de date prin interfa ța ITS  
4.1.1 Datele furnizate prin interfa ța ITS  
4.1.2 Con ținutul datelor  
4.1.3 Aplica ții ITS  
4.2. Tehnologia comunica țiilor 
4.3. Autorizare prin PIN  
4.4. Formatul mesajelor  
4.5. Acordul conduc ătorului auto  
4.6. Extragerea de date standard  
4.7. Extragerea de date cu caracter personal  
4.8. Extragerea de date privind evenimentele și anomaliile  
1. INTRODUCERE  
Prezentul apendice prezint ă detaliile privind concep ția și procedurile care 
trebuie urmate pentru a implementa interfa ța cu sisteme de transport inte ­
ligente (ITS), astfel cum este prev ăzut la articolul 10 din Regulamentul 
(UE) nr. 165/2014 (denumit în continuare  regulamentul ). 
Regulamentul  prevede c ă tahografele vehiculelor pot fi echipate cu 
interfețe standardizate care permit utilizarea în modul opera țional, de 
către un dispozitiv extern, a datelor înregistrate sau produse de tahograf, 
dacă sunt îndeplinite urm ătoarele condi ții: 
(a) interfa ța nu trebuie s ă afecteze autenticitatea și integritatea datelor 
tahografului;  
(b) interfa ța trebuie s ă respecte dispozi țiile detaliate de la articolul 11 din  
regulament ; 
(c) dispozitivul extern conectat la interfa ță poate accesa datele cu 
caracter personal, inclusiv datele de geopozi ționare, numai dup ă 
acordul verificabil al conduc ătorului auto la care se refer ă datele.  
2. OBIECT  
Scopul prezentului apendice este s ă precizeze modul în care aplica țiile 
instalate pe dispozitive externe pot s ă extragă date (denumite în continuare  
datele ) dintr-un tahograf prin intermediul unei conexiuni Bluetooth®.  
Datele  disponibile prin intermediul acestei interfe țe sunt descrise în anexa 
1 la prezentul document. Aceast ă interfață nu exclude implementarea altor 
interfețe (de exemplu, prin intermediul magistralei CAN) în vederea trans ­
miterii datelor din unitatea montat ă pe vehicul (VU) c ătre alte unit ăți de 
procesare montate pe vehicul.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 451  
Prezentul apendice specific ă: 
— datele  disponibile prin interfa ța ITS;  
— profilul Bluetooth® care este utilizat pentru transferul de date;  
— procedurile de interogare și de descărcare și secvența de opera țiuni; 
— mecanismul de asociere dintre tahograf și dispozitivul extern;  
— mecanismul de confirmare aflat la dispozi ția conducătorului auto.  
▼M1 
Pentru clarificare, prezentul apendice  nu precizeaz ă: 
— Operarea și gestionarea colect ării datelor  în cadrul VU (care sunt 
specificate în alt ă secțiune a  regulamentului  sau depind de concep ția 
produsului).  
— Forma de prezentare a datelor colectate c ătre aplicația instalată pe 
dispozitivul extern.  
— Dispozi țiile de securitate a datelor care dep ășesc securitatea oferit ă de 
Bluetooth® (cum ar fi criptarea) în ceea ce prive ște conținutul  datelor  
[care trebuie s ă fie specificate în alt ă secțiune a  regulamentului  (apen­
dicele 11 – Mecanisme de securitate comune)].  
— Protocoalele Bluetooth® utilizate de interfa ța ITS.  
▼B 
2.1. Acronime, defini ții și notații 
În prezentul apendice sunt utilizate urm ătoarele acronime și definiții 
specifice prezentului apendice:  
comunicarea  schimbul de informa ții/date între o unitate  master  (și 
anume, tahografele) și o unitate extern ă, prin intermediul 
interfeței ITS și folosind sistemul Bluetooth®.  
datele  seturile de date precizate în anexa 1.  
regulamentul  Regulamentul (UE) nr. 165/2014 al Parlamentului 
European și al Consiliului din 4 februarie 2014 privind 
tahografele în transportul rutier, de abrogare a Regula ­
mentului (CEE) nr. 3821/85 al Consiliului privind 
aparatura de înregistrare în transportul rutier și de modi­
ficare a Regulamentului (CE) nr. 561/2006 al Parla ­
mentului European și al Consiliului privind armonizarea 
anumitor dispozi ții ale legisla ției sociale în domeniul 
transporturilor rutiere.  
BR rata de baz ă (basic rate ) 
EDR  rata îmbun ătățită de transfer al datelor ( enhanced data 
rate) 
GNSS  sistem global de naviga ție prin satelit ( Global navigation 
satellite system ) 
IRK  cheie de rezolvare a identit ății (identity resolution key ) 
ITS sistem de transport inteligent ( intelligent transport system ) 
LE nivel redus de energie ( low energy ) 
PIN num ăr de identificare personal ( personal identification 
number ) 
PUC  cod de deblocare personal ( personal unblocking code ) 
SID identificator de serviciu ( service identifier ) 
SPP profilul portului serial ( serial port profile ) ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 452  
SSP asociere simpl ă securizată (secure simple pairing ) 
TRTP  parametru de solicitare de transfer ( transfer request para ­
meter ) 
PRT  parametru de r ăspuns la transfer ( transfer response para ­
meter ) 
VU unitate montat ă pe vehicul ( vehicle unit ) 
3. REGULAMENTE ȘI STANDARDE MEN ȚIONATE  
Specificația definită în prezentul apendice se refer ă la toate sau la o parte 
din următoarele regulamente și standarde și depinde de acestea. În cadrul 
clauzelor din prezentul apendice sunt specificate standardele relevante sau 
clauzele relevante ale standardelor. În cazul oric ărei situații contradictorii, 
clauzele din prezentul apendice prevaleaz ă. 
Regulamentele și standardele la care se face trimitere în prezentul apendice 
sunt următoarele:  
— Regulamentul (UE) nr. 165/2014 al Parlamentului European și al 
Consiliului din 4 februarie 2014 privind tahografele în transportul 
rutier, de abrogare a Regulamentului (CEE) nr. 3821/85 al Consiliului 
privind aparatura de înregistrare în transportul rutier și de modificare a 
Regulamentului (CE) nr. 561/2006 al Parlamentului European și al 
Consiliului privind armonizarea anumitor dispozi ții ale legisla ției 
sociale în domeniul transporturilor rutiere.  
— Regulamentul (CE) nr. 561/2006 al Parlamentului European și al 
Consiliului din 15 martie 2006 privind armonizarea anumitor dispozi ții 
ale legislației sociale în domeniul transporturilor rutiere, de modificare 
a Regulamentelor (CEE) nr. 3821/85 și (CE) nr. 2135/98 ale 
Consiliului și de abrogare a Regulamentului (CEE) nr. 3820/85 al 
Consiliului.  
— ISO 16844 – 4:  Road vehicles – Tachograph systems – Part 4: Can 
interface  
— ISO 16844 – 7:  Road vehicles – Tachograph systems – Part 7: Para ­
meters  
— Bluetooth® –  Serial Port Profile  – V1.2  
— Bluetooth® – Versiunea principal ă 4.2 
— Protocolul NMEA 0183 V4.1  
4. PRINCIPIILE DE FUNC ȚIONARE A INTERFE ȚEI 
4.1. Condi ții prealabile pentru transferul de date prin interfa ța ITS  
Unitatea montat ă pe vehicul are rolul de a actualiza și de a păstra datele 
care urmeaz ă să fie stocate în VU, f ără implicarea interfe ței ITS. Acest rol 
este îndeplinit de unitatea montat ă pe vehicul printr-o modalitate intern ă, 
care este specificat ă în altă secțiune a regulamentului și nu este specificat ă 
în prezentul apendice.  
4.1.1  Datele furnizate prin interfa ța ITS  
Unitatea montat ă pe vehicul este responsabil ă cu actualizarea datelor care 
vor fi disponibile prin interfa ța ITS, cu o frecven ță stabilită în cadrul 
procedurilor VU, f ără implicarea interfe ței ITS. Datele furnizate de 
unitatea montat ă pe vehicul sunt utilizate ca baz ă pentru a completa și a 
actualiza  datele ; modalitatea prin care se realizeaz ă acest lucru este speci ­
ficată în altă secțiune din  regulament  sau, în cazul în care nu exist ă o 
astfel de specifica ție, această modalitate depinde de concep ția produsului 
și nu este specificat ă în prezentul apendice.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 453  
4.1.2  Conținutul datelor  
Conținutul  datelor  este specificat în anexa 1 la prezentul apendice.  
4.1.3  Aplicații ITS  
Aplicațiile ITS vor folosi datele puse la dispozi ție prin interfa ța ITS, de 
exemplu pentru a optimiza gestionarea activit ăților conduc ătorului auto, 
respectând în acela și timp dispozi țiile regulamentului, pentru a detecta 
posibilele anomalii ale tahografului sau pentru utilizarea datelor GNSS. 
Specificarea aplica țiilor nu face obiectul prezentului apendice.  
4.2. Tehnologia comunica țiilor 
Schimbul de  date  prin interfa ța ITS se efectueaz ă printr-o interfa ță Blue­
tooth® compatibil ă folosind versiunea 4.2 sau o versiune mai recent ă. Blue­
tooth® func ționează în banda de unde industrial ă, științifică și medicală 
(ISM) cu frecven țe cuprinse între 2,4 și 2,485 GHz; aceast ă bandă nu face 
obiectul unei licen țe. Bluetooth® 4.2 ofer ă mecanisme îmbun ătățite de 
confidențialitate și de securitate și este caracterizat de o vitez ă și o fiabilitate 
sporite ale transferurilor de date. În scopul prezentei specifica ții este utilizat 
sistemul radio Bluetooth® de clasa 2 cu o raz ă de acțiune de cel mult 10 m. 
Informații suplimentare cu privire la Bluetooth® 4.2 sunt disponibile la 
adresa: www.bluetooth.com (https://www.bluetooth.org/en-us/specification/ 
adopted-specifications?_ga=1.215147412.2083380574.1435305 676).  
Comunicarea  se stabile ște cu echipamentele de comunicare dup ă fina­
lizarea unui proces de asociere de c ătre un dispozitiv autorizat. Întrucât 
Bluetooth® folose ște o arhitectur ă de tip  master/slave  pentru a controla 
atât momentul în care dispozitivele pot transmite date, cât și destinația 
acestor date, tahograful va îndeplini func ția de  master , iar dispozitivul 
extern va avea rolul de  slave . 
▼M1 
Atunci când un dispozitiv extern intr ă pentru prima dat ă în raza de ac țiune 
a VU, procesul de asociere Bluetooth® poate fi ini țiat (a se vedea, de 
asemenea, anexa 2). Dispozitivele î și transmit reciproc adresele, numele și 
profilurile, precum și cheia secret ă comună, ceea ce le permite s ă se lege 
unul la altul ori de câte ori intr ă în contact ulterior. Dup ă finalizarea 
acestui pas, dispozitivul extern este „certificat” și este în m ăsură să 
lanseze solicit ări de descărcare a datelor din tahograf. Nu se preconizeaz ă 
folosirea unor mecanisme de criptare suplimentare pe lâng ă cele deja 
existente în sistemul Bluetooth®. Cu toate acestea, în cazul în care sunt 
necesare mecanisme suplimentare de securitate, acestea vor fi imple ­
mentate în conformitate cu apendicele 11 – Mecanisme de securitate 
comune.  
▼B 
Figura de mai jos prezint ă principiul general de comunicare.
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 454  
SPP (profilul portului serial) al sistemului Bluetooth® este utilizat pentru a 
transfera date de la VU la dispozitivul extern.  
4.3. Autorizare prin PIN  
▼M1 
Din motive de securitate, VU va avea nevoie de un sistem de autorizare 
bazat pe un cod PIN, separat de sistemul de asociere Bluetooth. În scopuri 
de autentificare, fiecare VU trebuie s ă poată genera coduri PIN formate 
din cel pu țin patru cifre. De fiecare dat ă când un dispozitiv extern se 
asociază cu o VU, dispozitivul respectiv trebuie s ă furnizeze codul PIN 
corect înainte de a primi eventualele date.  
▼B 
Introducerea corect ă a PIN-ului implic ă plasarea dispozitivului pe lista 
dispozitivelor validate. Lista dispozitivelor validate trebuie s ă cuprindă 
cel puțin 64 de dispozitive asociate cu o anume VU.  
Furnizarea unui cod PIN incorect de trei ori la rând duce la plasarea 
provizorie a dispozitivului pe lista neagr ă. Câtă vreme dispozitivul se 
află pe lista neagr ă, orice nou ă încercare de accesare din partea dispozi ­
tivului este respins ă. Furnizarea în continuare a unui cod PIN incorect, de 
trei ori la rând, duce la plasarea pentru o perioad ă din ce în ce mai lung ă a 
dispozitivului pe lista neagr ă (a se vedea tabelul 1). Furnizarea corect ă a 
codului PIN permite resetarea duratei de interdic ție și a numărului de 
încercări. În figura 1 din anexa 2 este prezentat ă schema etapelor unei 
încercări de validare folosind codul PIN.  
Tabelul 1  
Durata interdic ției în func ție de num ărul de introduceri consecutive 
ale unui cod PIN incorect  
Numărul de încerc ări eronate 
consecutive  Durata interdic ției 
3 30 de secunde  
6 5 minute  
9 1 or ă 
12 24 de ore  
15 Permanent  
Furnizarea unui cod PIN incorect de cincisprezece ori la rând (5 × 3) duce 
la plasarea permanent ă a dispozitivului pe lista neagr ă a unității ITS. 
Această interdicție permanent ă se anuleaz ă numai prin furnizarea codului 
PUC corect.  
Codul PUC este compus din 8 cifre și este furnizat de produc ător 
împreună cu VU. Furnizarea unui cod PUC incorect de zece ori la rând 
va duce la plasarea definitiv ă a unității ITS pe lista neagr ă. 
▼M1 
Cu toate c ă producătorul poate oferi op țiunea schimb ării directe a codului 
PIN prin intermediul VU, codul PUC trebuie s ă nu poată fi modificat. 
Dacă există posibilitatea schimb ării codului PIN, aceasta se efectueaz ă prin 
introducerea actualului cod PIN direct în VU.  
▼B 
De asemenea, orice dispozitive stocate în lista dispozitivelor validate 
rămân incluse în list ă până la înlăturarea manual ă (a acestora) de c ătre 
utilizator (de exemplu, prin intermediul interfe ței dispozitiv-utilizator a VU 
sau prin alte mijloace). Prin aceast ă procedură pot fi eliminate de pe lista 
dispozitivelor validate unit ățile ITS care au fost pierdute sau furate. În 
plus, orice unitate ITS care nu se mai afl ă în raza de ac țiune a conexiunii 
Bluetooth timp de peste 24 de ore este eliminat ă automat din lista dispo ­
zitivelor validate a VU și trebuie să furnizeze din nou codul PIN corect la 
restabilirea conexiunii.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 455  
Formatul mesajelor dintre interfa ța VU și VU nu este furnizat, alegerea 
acestuia fiind l ăsată la latitudinea produc ătorului. Cu toate acestea, produ ­
cătorul în cauz ă trebuie să se asigure c ă formatul mesajului transmis între 
unitatea ITS și interfața VU este respectat (a se vedea specifica țiile 
ASN.1).  
Prin urmare, toate solicit ările de date trebuie s ă facă obiectul verific ării 
corespunzătoare a acredit ărilor expeditorului, înainte de a ini ția orice 
formă de tratare a datelor respective. În figura 2 din anexa 2 este 
prezentată schema etapelor pentru aceast ă procedură. Orice dispozitiv 
aflat pe lista neagr ă este respins automat, iar orice dispozitiv care nu se 
află nici pe lista neagr ă, nici pe lista dispozitivelor validate prime ște o 
cerere de furnizare a PIN-ului pe care trebuie s ă o îndeplineasc ă înainte de 
a trimite din nou solicitarea sa de date.  
4.4. Formatul mesajelor  
Toate mesajele transmise între unitatea ITS și VU trebuie s ă fie formatate 
într-o structur ă alcătuită din trei părți: un antet compus dintr-un octet țintă 
(TGT), un octet surs ă (SRC) și un octet de lungime (LEN);  
câmpul de date compus dintr-un octet de identificare a serviciului (SID) și 
dintr-un num ăr variabil de octe ți de date (cel mult 255);  
octetul de sum ă de verificare ( checksum byte ) corespunde unei serii de 
sume de câte 1 bit modul 256 care reprezint ă toți octeții din mesaj cu 
excepția octetului de sum ă de verificare (CS).  
Mesajul este în sistemul  Big Endian . 
Tabelul 2  
Formatul general al mesajelor  
Antet  Câmp de date  Sumă de veri­
ficare  
TGT  SRC  LEN  SID  TRTP  CC  CM  DATE  CS  
3 octeți maximum 255 de octe ți 1 octet  
Antet  
TGT și SRC: ID-ul dispozitivului țintă (TGT) și ID-ul dispozitivului surs ă 
(SRC) ale mesajului. Interfa ța VU trebuie s ă aibă codul de identificare 
implicit „EE”. Acest cod de identificare nu poate fi schimbat. Unitatea ITS 
trebuie să utilizeze codul de identificare implicit „A0” pentru primul s ău 
mesaj din sesiunea de comunicare. Interfa ța VU atribuie apoi un cod de 
identificare unic unit ății ITS și îl transmite spre informare unit ății ITS 
pentru viitoarele mesaje din timpul sesiunii.  
Octetul LEN trebuie s ă țină seama numai de rubrica „DATE” din câmpul 
de date (a se vedea tabelul 2); primii 4 octe ți sunt implici ți. 
Interfața VU trebuie s ă confirme autenticitatea expeditorului mesajului prin 
verificări încrucișate ale propriei liste de ID-uri ( IDList ) cu datele ob ținute 
prin sistemul Bluetooth, verificând faptul c ă unitatea ITS corespunz ătoare 
codului de identificare furnizat se afl ă în acel moment în raza de ac țiune a 
conexiunii Bluetooh.  
Câmpul de date  
Pe lângă SID, câmpul de date trebuie s ă conțină și alți parametri: un 
parametru de solicitare de transfer (TRTP) și octeți de numărare. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 456  
În cazul în care datele care trebuie prelucrate sunt mai voluminoase decât 
spațiul disponibil într-un singur mesaj, ele vor fi separate în mai multe 
submesaje. Fiecare submesaj trebuie s ă aibă același antet și același SID, 
dar va con ține un contor cu doi octe ți, contorul curent (CC) și contorul 
maxim (CM), pentru a indica num ărul de ordine al submesajului. Pentru a 
permite verificarea erorilor și o eventual ă încetare a schimbului de date, 
dispozitivul receptor confirm ă primirea fiec ărui submesaj. Dispozitivul 
receptor poate accepta submesajul, poate solicita retransmiterea acestuia 
și poate solicita dispozitivului emi țător să reia sau s ă abandoneze trans ­
misia.  
▼B 
Dacă nu sunt utilizate, CC și CM primesc valoarea 0xFF.  
De exemplu, urm ătorul mesaj  
ANTET  SID  TRTP  CC  CM  DATE  CS  
3 octeți mai lung de 255 de octe ți 1 octet  
Se transmite astfel:  
ANTET  SID  TRTP  01  n  DATE  CS  
3 octeți 255 de octe ți 1 octet  
ANTET  SID  TRTP  02  n  DATE  CS  
3 octeți 255 de octe ți 1 octet  
... 
ANTET  SID  TRTP  N  N  DATE  CS  
3 octeți maximum 255 de octe ți 1 octet  
Tabelul 3 con ține mesajele care pot fi schimbate între VU și unitatea ITS. 
Conținutul fiecărui parametru este dat în valori hexazecimale. Din motive 
de claritate, în tabel nu sunt indica ți CC și CM; a se vedea mai sus 
formatul complet.  
Tabelul 3  
Conținutul detaliat al mesajelor  
Mesaj  Antet  DATE  Sumă de 
control  
TGT  SRC  LEN  SID  TRTP  DATE  
RequestPIN  ITSID  EE  00  01  FF  
SendITSID  ITSID  EE  01  02  FF  ITSID  
SendPIN  EE  ITSID  04  03  FF  4*NUM ĂR ÎNTREG 
(0..9)  
Pairingresult  ITSID  EE  01  04  FF  BOOLEAN (T/F)  
SendPUC  EE  ITSID  08  05  FF  8*INTEGER (0..9)  ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 457  
Mesaj  Antet  DATE  Sumă de 
control  
TGT  SRC  LEN  SID  TRTP  DATE  
BanLiftingResult  ITSID  EE  01  06  FF  BOOLEAN (T/F)  
RequestRejected  ITSID  EE  08  07  FF  Timp  
RequestData  
standardTachData  EE  ITSID  01  08  01  
personalTachData  EE  ITSID  01  08  02  
gnssData  EE  ITSID  01  08  03  
standardEventData  EE  ITSID  01  08  04  
personalEventData  EE  ITSID  01  08  05  
standardFaultData  EE  ITSID  01  08  06  
manufacturerData  EE  ITSID  01  08  07  
ResquestAccepted  ITSID  EE  Len  09  PRT  Date  
DataUnavailable  
Nu sunt dispo ­
nibile date  ITSID  EE  02  0A  PRT  10  
Datele cu caracter 
personal nu sunt 
făcute publice  ITSID  EE  02  0A  PRT  11  
NegativeAnswer  
Respingere 
generală ITSID  EE  02  0B  SID Req  10  
Serviciu incompa ­
tibil ITSID  EE  02  0 B  SID Req  11  
Subfuncție incom­
patibilă ITSID  EE  02  0 B  SID Req  12  
Lungime incorect ă 
a mesajului  ITSID  EE  02  0 B  SID Req  13  
Condiții incorecte 
sau eroare a 
secvenței de soli­
citare  ITSID  EE  02  0 B  SID Req  22  
Solicitare în afara 
intervalului  ITSID  EE  02  0 B  SID Req  31  
Răspuns în 
așteptare  ITSID  EE  02  0 B  SID Req  78  
Neconcordan ță 
ITSID  ITSID  EE  02  0 B  SID Req  FC  
ITSID nu poate fi 
găsit ITSID  EE  02  0 B  SID Req  FB  
RequestPIN (SID 01)  
Acest mesaj este emis de interfa ța VU în cazul în care o unitate ITS care 
nu este pe lista neagr ă, dar nici pe lista dispozitivelor validate trimite o 
solicitare de date.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 458  
SendITSID (SID 02)  
Acest mesaj este emis de interfa ța VU ori de câte ori un nou dispozitiv 
emite o solicitare. Acest dispozitiv utilizeaz ă codul de identificare implicit 
„A0” înainte de a îi fi atribuit un cod de identificare unic pentru sesiunea 
de comunicare.  
SendPIN (SID 03)  
Acest mesaj este emis de unitatea ITS care urmeaz ă să fie înscris ă pe lista 
de dispozitive validate de c ătre interfața VU. Con ținutul acestui mesaj este 
un număr întreg 4 („4 INTEGER”) cuprins între 0 și 9. 
PairingResult (SID 04)  
Acest mesaj este emis de interfa ța VU pentru a informa unitatea ITS c ă 
aceasta din urm ă a trimis un cod PIN corect. Con ținutul acestui mesaj este 
un element BOOLEAN cu valoarea „True” în cazul în care codul PIN este 
corect, respectiv „False” în caz contrar.  
SendPUC (SID 05)  
Acest mesaj este emis de unitatea ITS pentru o scoatere de pe lista neagr ă 
de către interfața VU. Con ținutul acestui mesaj este un num ăr întreg 8 („8 
INTEGER”) cuprins între 0 și 9. 
BanLiftingResult (SID 06)  
Acest mesaj este emis de interfa ța VU pentru a informa unitatea ITS c ă 
aceasta din urm ă a trimis un cod PUC corect. Con ținutul acestui mesaj 
este un element BOOLEAN cu valoarea „True” în cazul în care codul 
PUC este corect, respectiv „False” în caz contrar.  
RequestRejected (SID 07)  
Acest mesaj este emis de interfa ța VU ca răspuns la orice mesaj trimis de 
o unitate ITS aflat ă pe lista neagr ă, cu excep ția mesajului „SendPUC”. 
Mesajul precizeaz ă timpul rămas până la scoaterea unit ății ITS de pe lista 
neagră, conform formatului secven ței „Timp” astfel cum este definit în 
anexa 3.  
RequestData (SID 08)  
Acest mesaj pentru accesarea datelor este emis de unitatea ITS. Un 
parametru de solicitare de transfer de un octet (TRTP) indic ă tipul 
datelor solicitate. Exist ă mai multe tipuri de date:  
— standardTachData (TRTP 01): date puse la dispozi ție de tahograf și 
clasificate ca fiind publice.  
— personalTachData (TRTP 02): date puse la dispozi ție de tahograf și 
clasificate ca având caracter personal.  
— gnssData (TRTP 03): datele referitoare la GNSS, care au întotdeauna 
un caracter personal.  
— standardEventData (TRTP 04): date privind evenimentele înregistrate, 
clasificate ca fiind publice.  
— personalEventData (TRTP 05): date privind evenimentele înregistrate, 
clasificate ca având caracter personal.  
— standardFaultData (TRTP 06): anomalii înregistrate, clasificate ca fiind 
publice.  
— manufacturerData (TRTP 07): date puse la dispozi ție de către produ­
cător. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 459  
A se vedea anexa 3 din prezentul apendice pentru mai multe informa ții 
referitoare la con ținutul fiecărui tip de date.  
A se vedea apendicele 12 pentru mai multe informa ții cu privire la 
formatul și conținutul datelor GNSS.  
A se vedea anexele IB și IC pentru mai multe informa ții referitoare la 
datele privind evenimentele și la anomalii.  
ResquestAccepted (SID 09)  
Acest mesaj este emis de interfa ța VU dac ă un mesaj „RequestData” 
transmis de o unitate ITS a fost acceptat. Acest mesaj con ține un PRT 
de un 1 octet, care reprezint ă octetul TRTP al mesajului  RequestData  
asociat și al tuturor datelor de tipul solicitat.  
DataUnavailable (SID 0A)  
Acest mesaj este emis de interfa ța VU dac ă, dintr-un motiv oarecare, 
informațiile solicitate nu sunt disponibile pentru a fi transmise unei 
unități ITS aflate pe o list ă de dispozitive validate. Mesajul con ține un 
PRT de 1 octet, care reprezint ă TRTP-ul datelor solicitate, și un cod de 
eroare de 1 octet, specificat în tabelul 3. Se aplic ă următoarele coduri:  
— Nu sunt disponibile informa ții (10): Interfa ța VU nu poate avea acces 
la datele VU dac ă motivele cererii de accesare nu sunt precizate.  
— Datele cu caracter personal nu sunt public accesibile (11): Unitatea ITS 
încearcă să extragă date cu caracter personal în situa ții în care acestea 
nu sunt public accesibile.  
NegativeAnswer (SID 0B)  
Aceste mesaje sunt emise de interfa ța VU dacă o solicitare nu poate fi 
finalizată din orice alte motive decât indisponibilitatea datelor. Mesajele 
respective sunt în general rezultatul utiliz ării unui format eronat al soli ­
citării (lungime, SID, ITSID...), dar pot avea și alte cauze. TRTP-ul din 
câmpul de date con ține SID-ul solicit ării. Câmpul de date con ține un cod 
prin care este identificat motivul r ăspunsului negativ. Se aplic ă urmă­
toarele coduri:  
— Respingere general ă (cod: 10)  
— Acțiunea nu poate fi realizat ă dintr-un motiv care nu este men ționat 
nici mai jos, nici în sec țiunea (a se introduce num ărul secțiunii DataU­
navailable ). 
— Serviciu incompatibil (cod: 11)  
— SID-ul solicit ării nu este comprehensibil.  
— Subfunc ție incompatibil ă (cod: 12)  
— TRTP-ul solicit ării nu este comprehensibil. Acesta poate fi, de 
exemplu, absent sau se poate situa în afara intervalului de valori 
acceptate.  
— Lungime incorect ă a mesajului (cod: 13)  
— Lungimea mesajului primit este incorect ă (neconcordan ță între octetul 
LEN și lungimea efectiv ă a mesajului).  
— Condiții incorecte sau eroare a secven ței de solicitare (cod: 22)  
— Serviciul solicitat nu este disponibil sau secven ța mesajelor de soli ­
citare nu este corect ă 
— Solicitare în afara intervalului (cod: 33)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 460  
— Înregistrarea parametrului solicit ării (câmp de date) nu este valabil ă 
— Răspuns în a șteptare (cod: 78)  
— Acțiunea solicitat ă nu poate fi finalizat ă în timp util și VU nu este 
pregătită să accepte o nou ă solicitare.  
— Neconcordan ță ITSID  (cod: FB)  
— În urma compar ării cu informa țiile Bluetooh, rezult ă că ITSID-ul SRC- 
ului nu corespunde dispozitivului asociat.  
— ITSID  absent (cod: FC)  
— ITSID -ul SRC-ului nu este asociat cu niciun dispozitiv.  
Rândurile 1-72 ( FormatMessageModule ) din codul ASN.1 din anexa 3 
precizează formatul mesajelor, astfel cum este descris în tabelul 3. Mai jos 
sunt oferite detalii suplimentare cu privire la con ținutul mesajelor.  
4.5. Acordul conduc ătorului auto  
Toate datele disponibile sunt clasificate fie ca date standard, fie ca date cu 
caracter personal. Datele cu caracter personal sunt accesibile numai în 
cazul în care conduc ătorul auto și-a dat acordul în acest sens, acceptând 
ca datele sale cu caracter personal referitoare la tahograf s ă fie transmise în 
afara rețelei vehiculului pentru a fi utilizate în aplica ții ale unor p ărți terțe. 
Acordul conduc ătorului auto este dat atunci când, la prima introducere a 
unui anumit card de conduc ător auto sau a unui card de atelier necunoscut 
de unitatea montat ă pe vehicul pân ă la momentul respectiv, titularul 
cardului este invitat s ă își exprime acordul pentru transmiterea în 
exterior, prin intermediul interfe ței opționale ITS, a datelor cu caracter 
personal care se refer ă la tahograf (a se vedea, de asemenea, anexa I C 
punctul 3.6.2).  
Starea acordului (activat/dezactivat) se înregistreaz ă în memoria tahogra ­
fului.  
În cazul în care exist ă mai mul ți conducători auto, numai datele cu 
caracter personal referitoare la conduc ătorii auto care și-au dat acordul 
în acest sens sunt transmise interfe ței ITS. De exemplu, în cazul în care 
există doi conduc ători auto la bordul vehiculului, dar numai unul dintre 
aceștia a acceptat s ă permită accesul la datele sale cu caracter personal, 
datele referitoare la cel ălalt conduc ător auto nu pot fi transmise unei ter țe 
părți. 
4.6. Extragerea de date standard  
În figura 3 din anexa 2 este prezentat ă diagrama secven țelor unei cereri 
valabile trimise de unitatea ITS pentru a solicita accesul la date standard. 
Unitatea ITS este inclus ă în mod corespunz ător pe lista dispozitivelor 
validate și nu solicit ă accesul la date cu caracter personal; prin urmare, 
nu este necesar ă nicio verificare suplimentar ă. În diagramele men ționate se 
consideră că a fost deja urmat ă procedura corespunz ătoare ilustrat ă în 
figura 2 din anexa 2. Acestea pot fi considerate echivalente cu drep ­
tunghiul gri purtând men țiunea  REQUEST TREATMENT  din figura 2.  
Dintre datele disponibile, urm ătoarele sunt considerate a fi date standard:  
— standardTachData (TRTP 01)  
— standardEventData (TRTP 04)  
— standardFaultData (TRTP 06)  
4.7. Extragerea de date cu caracter personal  
În figura 4 din anexa 2 este prezentat ă diagrama secven țelor pentru prelu ­
crarea solicit ărilor de date cu caracter personal. Dup ă cum s-a men ționat 
anterior, interfa ța VU transmite date cu caracter personal numai în cazul în 
care conduc ătorul auto și-a dat acordul explicit în acest sens (a se vedea, 
de asemenea, punctul 4.5). În caz contrar, solicitarea trebuie respins ă în 
mod automat.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 461  
Dintre datele disponibile, urm ătoarele sunt considerate a fi date cu caracter 
personal:  
— personalTachData (TRTP 02)  
— gnssData (TRTP 03)  
— personalEventData (TRTP 05)  
— manufacturerData (TRTP 07)  
4.8. Extragerea de date privind evenimentele și anomaliile  
Unitățile ITS trebuie s ă aibă capacitatea de a solicita date privind eveni ­
mentele, care con țin lista tuturor evenimentelor neprev ăzute. Aceste date 
sunt considerate fie standard, fie date cu caracter personal (a se vedea 
anexa 3). Con ținutul fiec ărui eveniment este în conformitate cu docu ­
mentația furnizată în anexa 1 la prezentul apendice.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 462  
ANEXA 1  
▼M1 
1) LISTA DATELOR DISPONIBILE PRIN INTERFA ȚA ITS  
▼B 
Date  Sursa  ►C2 Clasificarea 
datelor (cu caracter 
personal/publice) ◄ 
VehicleIdentificationNumber  Unitatea montat ă pe vehicul  publice  
CalibrationDate  Unitatea montat ă pe vehicul  publice  
TachographVehicleSpeed speed instant t  Unitatea montat ă pe vehicul  cu caracter personal  
Driver1WorkingState Selector driver  Unitatea montat ă pe vehicul  cu caracter personal  
Driver2WorkingState  Unitatea montat ă pe vehicul  cu caracter personal  
DriveRecognize Speed Threshold detected  Unitatea montat ă pe vehicul  publice  
Driver1TimeRelatedStates Weekly day time  Cardul conduc ătorului auto  cu caracter personal  
Driver2TimeRelatedStates  Cardul conduc ătorului auto  cu caracter personal  
DriverCardDriver1  Unitatea montat ă pe vehicul  publice  
DriverCardDriver2  Unitatea montat ă pe vehicul  publice  
OverSpeed  Unitatea montat ă pe vehicul  cu caracter personal  
TimeDate  Unitatea montat ă pe vehicul  publice  
HighResolutionTotalVehicleDistance  Unitatea montat ă pe vehicul  publice  
ServiceComponentIdentification  Unitatea montat ă pe vehicul  publice  
ServiceDelayCalendarTimeBased  Unitatea montat ă pe vehicul  publice  
Driver1Identification  Cardul conduc ătorului auto  cu caracter personal  
Driver2Identification  Cardul conduc ătorului auto  cu caracter personal  
NextCalibrationDate  Unitatea montat ă pe vehicul  publice  
Driver1ContinuousDrivingTime  Cardul conduc ătorului auto  cu caracter personal  
Driver2ContinuousDrivingTime  Cardul conduc ătorului auto  cu caracter personal  
Driver1CumulativeBreakTime  Cardul conduc ătorului auto  cu caracter personal  
Driver2CumulativeBreakTime  Cardul conduc ătorului auto  cu caracter personal  
Driver1CurrentDurationOfSelectedActivity  Cardul conduc ătorului auto  cu caracter personal  
Driver2CurrentDurationOfSelectedActivity  Cardul conduc ătorului auto  cu caracter personal  
SpeedAuthorised  Unitatea montat ă pe vehicul  publice  
TachographCardSlot1  Cardul conduc ătorului auto  publice  
TachographCardSlot2  Cardul conduc ătorului auto  publice  
Driver1Name  Cardul conduc ătorului auto  cu caracter personal  
Driver2Name  Cardul conduc ătorului auto  cu caracter personal  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 463  
Date  Sursa  ►C2 Clasificarea 
datelor (cu caracter 
personal/publice) ◄ 
OutOfScopeCondition  Unitatea montat ă pe vehicul  publice  
ModeOfOperation  Unitatea montat ă pe vehicul  publice  
Driver1CumulatedDrivingTimePreviousAn ­
dCurrentWeek  Cardul conduc ătorului auto  cu caracter personal  
Driver2CumulatedDrivingTimePreviousAn ­
dCurrentWeek  Cardul conduc ătorului auto  cu caracter personal  
EngineSpeed  Unitatea montat ă pe vehicul  cu caracter personal  
RegisteringMemberState  Unitatea montat ă pe vehicul  publice  
VehicleRegistrationNumber  Unitatea montat ă pe vehicul  publice  
Driver1EndOfLastDailyRestPeriod  Cardul conduc ătorului auto  cu caracter personal  
Driver2EndOfLastDailyRestPeriod  Cardul conduc ătorului auto  cu caracter personal  
Driver1EndOfLastWeeklyRestPeriod  Cardul conduc ătorului auto  cu caracter personal  
Driver2EndOfLastWeeklyRestPeriod  Cardul conduc ătorului auto  cu caracter personal  
Driver1EndOfSecondLastWeeklyRestPeriod  Cardul conduc ătorului auto  cu caracter personal  
Driver2EndOfSecondLastWeeklyRestPeriod  Cardul conduc ătorului auto  cu caracter personal  
Driver1CurrentDailyDrivingTime  Cardul conduc ătorului auto  cu caracter personal  
Driver2CurrentDailyDrivingTime  Cardul conduc ătorului auto  cu caracter personal  
Driver1CurrentWeeklyDrivingTime  Cardul conduc ătorului auto  cu caracter personal  
Driver2CurrentWeeklyDrivingTime  Cardul conduc ătorului auto  cu caracter personal  
Driver1TimeLeftUntilNewDailyRestPeriod  Cardul conduc ătorului auto  cu caracter personal  
Driver2TimeLeftUntilNewDailyRestPeriod  Cardul conduc ătorului auto  cu caracter personal  
Driver1CardExpiryDate  Cardul conduc ătorului auto  cu caracter personal  
Driver2CardExpiryDate  Cardul conduc ătorului auto  cu caracter personal  
Driver1CardNextMandatoryDownloadDate  Cardul conduc ătorului auto  cu caracter personal  
Driver2CardNextMandatoryDownloadDate  Cardul conduc ătorului auto  cu caracter personal  
TachographNextMandatoryDownloadDate  Unitatea montat ă pe vehicul  publice  
Driver1TimeLeftUntilNewWeeklyRestPeriod  Cardul conduc ătorului auto  cu caracter personal  
Driver2TimeLeftUntilNewWeeklyRestPeriod  Cardul conduc ătorului auto  cu caracter personal  
Driver1NumberOfTimes9hDailyDrivingTi ­
mesExceeded  Cardul conduc ătorului auto  cu caracter personal  
Driver2NumberOfTimes9hDailyDrivingTi ­
mesExceeced  Cardul conduc ătorului auto  cu caracter personal  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 464  
Date  Sursa  ►C2 Clasificarea 
datelor (cu caracter 
personal/publice) ◄ 
Driver1CumulativeUninterruptedRestTime  Cardul conduc ătorului auto  cu caracter personal  
Driver2CumulativeUninterruptedRestTime  Cardul conduc ătorului auto  cu caracter personal  
Driver1MinimumDailyRest  Cardul conduc ătorului auto  cu caracter personal  
Driver2MinimumDailyRest  Cardul conduc ătorului auto  cu caracter personal  
Driver1MinimumWeeklyRest  Cardul conduc ătorului auto  cu caracter personal  
Driver2MinimumWeeklyRest  Cardul conduc ătorului auto  cu caracter personal  
Driver1MaximumDailyPeriod  Cardul conduc ătorului auto  cu caracter personal  
Driver2MaximumDailyPeriod  Cardul conduc ătorului auto  cu caracter personal  
Driver1MaximumDailyDrivingTime  Cardul conduc ătorului auto  cu caracter personal  
Driver2MaximumDailyDrivingTime  Cardul conduc ătorului auto  cu caracter personal  
Driver1NumberOfUsedReducedDailyRestPe ­
riods  Cardul conduc ătorului auto  cu caracter personal  
Driver2NumberOfUsedReducedDailyRestPe ­
riods  Cardul conduc ătorului auto  cu caracter personal  
Driver1RemainingCurrentDrivingTime  Cardul conduc ătorului auto  cu caracter personal  
Driver2RemainingCurrentDrivingTime  Cardul conduc ătorului auto  cu caracter personal  
GNSS position  Unitatea montat ă pe vehicul  cu caracter personal  
2) DATE GNSS FURNIZATE ÎN FLUX CONTINUU DISPONIBILE CU 
ACORDUL CONDUC ĂTORULUI AUTO  
A se vedea apendicele 12 – GNSS.  
3) CODURI ALE EVENIMENTELOR DISPONIBILE F ĂRĂ ACORDUL 
PREALABIL AL CONDUC ĂTORULUI AUTO  
Eveniment  Reguli de stocare  Date care trebuie înregistrate pentru fiecare eveniment  
Introducerea unui card neva ­
labil — cele mai recente 10 evenimente.  — data și ora evenimentului, 
— tipul și numărul cardului (cardurilor), statul 
membru emitent și generația cardului care a 
creat evenimentul, 
— numărul de evenimente similare care au 
survenit în ziua respectiv ă. 
Conflict de carduri  — cele mai recente 10 evenimente.  — data și ora începerii evenimentului, 
— data și ora încheierii evenimentului, 
— tipul și numărul cardului (cardurilor), statul 
membru emitent și generația celor dou ă 
carduri care au creat conflictul.  
Încheierea incorect ă a ultimei 
sesiuni  — cele mai recente 10 evenimente.  — data și ora introducerii cardului, 
— tipul, num ărul, statul membru emitent și 
generația cardului (cardurilor), 
— datele din ultima sesiune, a șa cum au fost 
citite de pe card: 
— data și ora introducerii cardului, 
— VRN, statul membru de înmatriculare și 
generația VU.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 465  
Eveniment  Reguli de stocare  Date care trebuie înregistrate pentru fiecare eveniment  
Întreruperea aliment ării cu 
energie electric ă (2) — evenimentul care a durat cel mai 
mult în fiecare din ultimele 10 
zile de producere a unui 
eveniment, 
— cele mai de durat ă 5 evenimente 
din ultimele 365 de zile.  — data și ora începerii evenimentului, 
— data și ora încheierii evenimentului, 
— tipul și numărul cardului (cardurilor), statul 
membru emitent și generația oricărui card 
introdus la începutul și/sau la încheierea 
evenimentului, 
— numărul de evenimente similare care au 
survenit în ziua respectiv ă. 
Eroare de comunicare cu 
dispozitivul de comunicare la 
distanță — evenimentul care a durat cel mai 
mult în fiecare din ultimele 10 
zile de producere a unui 
eveniment, 
— cele mai de durat ă 5 evenimente 
din ultimele 365 de zile.  — data și ora începerii evenimentului, 
— data și ora încheierii evenimentului, 
— tipul și numărul cardului (cardurilor), statul 
membru emitent și generația oricărui card 
introdus la începutul și/sau la încheierea 
evenimentului, 
— numărul de evenimente similare care au 
survenit în ziua respectiv ă. 
Absența informațiilor privind 
poziția din receptorul GNSS  — evenimentul care a durat cel mai 
mult în fiecare din ultimele 10 
zile în care s-a produs, 
— cele mai de durat ă 5 evenimente 
din ultimele 365 de zile.  — data și ora începerii evenimentului, 
— data și ora încheierii evenimentului, 
— tipul și numărul cardului (cardurilor), statul 
membru emitent și generația oricărui card 
introdus la începutul și/sau la încheierea 
evenimentului, 
— numărul de evenimente similare care au 
survenit în ziua respectiv ă. 
▼M1 
Eroare de comunicare cu 
echipamentul GNSS extern  — evenimentul cel mai de durat ă din 
fiecare dintre ultimele 10 zile de 
producere, 
— cele mai de durat ă cinci 
evenimente din ultimele 365 de 
zile. — data și ora începerii evenimentului, 
— data și ora încheierii evenimentului, 
— tipul și numărul cardului (cardurilor), statul 
membru emitent și generația oricărui card 
introdus la începutul și/sau la încheierea 
evenimentului, 
— numărul de evenimente similare din ziua 
respectivă. 
▼B 
Eroare privind datele de 
deplasare  — evenimentul care a durat cel mai 
mult în fiecare din ultimele 10 
zile în care s-a produs, 
— cele mai de durat ă 5 evenimente 
din ultimele 365 de zile.  — data și ora începerii evenimentului, 
— data și ora încheierii evenimentului, 
— tipul și numărul cardului (cardurilor), statul 
membru emitent și generația oricărui card 
introdus la începutul și/sau la încheierea 
evenimentului, 
— numărul de evenimente similare care au 
survenit în ziua respectiv ă. 
Conflict privind deplasarea 
vehiculului  — evenimentul care a durat cel mai 
mult în fiecare din ultimele 10 
zile în care s-a produs, 
— cele mai de durat ă 5 evenimente 
din ultimele 365 de zile.  — data și ora începerii evenimentului, 
— data și ora încheierii evenimentului, 
— tipul și numărul cardului (cardurilor), statul 
membru emitent și generația oricărui card 
introdus la începutul și/sau la încheierea 
evenimentului, 
— numărul de evenimente similare care au 
survenit în ziua respectiv ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 466  
Eveniment  Reguli de stocare  Date care trebuie înregistrate pentru fiecare eveniment  
Tentativă de încălcare a 
securității cele mai recente 10 evenimente, pe 
tipuri de evenimente.  — data și ora începerii evenimentului, 
— data și ora încheierii evenimentului (dac ă 
sunt relevante), 
— tipul și numărul cardului (cardurilor), statul 
membru emitent și generația oricărui card 
introdus la începutul și/sau la încheierea 
evenimentului, 
— tipul evenimentului.  
Conflict temporal  — evenimentul care a durat cel mai 
mult în fiecare din ultimele 10 
zile în care s-a produs, 
— cele mai de durat ă 5 evenimente 
din ultimele 365 de zile.  — data și ora indicate de aparatura de înre ­
gistrare 
— data și ora GNSS, 
— tipul și numărul cardului (cardurilor), statul 
membru emitent și generația oricărui card 
introdus la începutul și/sau la încheierea 
evenimentului, 
— numărul de evenimente similare care au 
survenit în ziua respectiv ă. 
4) CODURI ALE EVENIMENTELOR DISPONIBILE F ĂRĂ ACORDUL 
PREALABIL AL CONDUC ĂTORULUI AUTO  
Eveniment  Reguli de stocare  Date care trebuie înregistrate pentru fiecare eveniment  
Conducere f ără un card 
adecvat  — evenimentul care a durat cel mai 
mult în fiecare din ultimele 10 
zile în care s-a produs, 
— cele mai de durat ă 5 evenimente 
din ultimele 365 de zile.  — data și ora începerii evenimentului, 
— data și ora încheierii evenimentului, 
— tipul și numărul cardului (cardurilor), statul 
membru emitent și generația oricărui card 
introdus la începutul și/sau la încheierea 
evenimentului, 
— numărul de evenimente similare care au 
survenit în ziua respectiv ă. 
Introducerea cardului în 
timpul conducerii  — ultimul eveniment survenit în 
fiecare dintre ultimele 10 zile 
de producere a unui eveniment,  — data și ora evenimentului, 
— tipul, num ărul, statul membru emitent și 
generația cardului (cardurilor), 
— numărul de evenimente similare care au 
survenit în ziua respectiv ă 
Depășirea limitei de vitez ă 
(1) — cel mai grav eveniment survenit 
în fiecare dintre ultimele 10 zile 
în care acesta s-a produs (adic ă 
cel în care s-a înregistrat cea mai 
mare vitez ă medie), 
— cele mai grave cinci evenimente 
survenite în ultimele 365 de zile. 
— primul eveniment survenit dup ă 
ultima etalonare,  — data și ora începerii evenimentului, 
— data și ora încheierii evenimentului, 
— viteza maxim ă măsurată pe parcursul 
evenimentului, 
— media aritmetic ă a vitezei m ăsurate în 
timpul evenimentului, 
— tipul și numărul cardului (cardurilor), statul 
membru emitent și generația cardului de 
conducător auto (dac ă este cazul), 
— numărul de evenimente similare care au 
survenit în ziua respectiv ă. 
5) CODURI ALE DATELOR PRIVIND ANOMALIILE DISPONIBILE F ĂRĂ 
ACORDUL PREALABIL AL CONDUC ĂTORULUI AUTO  
Anomalie  Reguli de stocare  Date care trebuie înregistrate pentru fiecare anomalie  
Anomalie a cardului  — cele mai recente 10 anomalii ale 
cardului de conduc ător auto.  — data și ora începerii anomaliei, 
— data și ora încheierii anomaliei, 
— tipul, num ărul, statul membru emitent și 
generația cardului (cardurilor).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 467  
Anomalie  Reguli de stocare  Date care trebuie înregistrate pentru fiecare anomalie  
Anomalii ale aparaturii de 
înregistrare  — cele mai recente 10 anomalii 
pentru fiecare tip de anomalie, 
— prima anomalie survenit ă după 
ultima etalonare.  — data și ora începerii anomaliei, 
— data și ora încheierii anomaliei, 
— tipul de anomalie, 
— tipul, num ărul și statul membru emitent al 
cardului (cardurilor), precum și generația 
oricărui card introdus la începutul și/sau 
la încheierea anomaliei.  
Această anomalie este declan șată în cazul survenirii oric ăreia dintre urm ătoarele 
anomalii în celelalte moduri decât modul de etalonare:  
— Anomalie intern ă a VU  
— Anomalie a imprimantei  
— Anomalie a afi șajului  
— Anomalie la desc ărcare  
— Anomalie a senzorului  
— Anomalie a receptorului GNSS sau a echipamentului GNSS extern  
— Anomalie a dispozitivului de comunicare la distan ță 
▼M1 
— Anomalie a interfe ței ITS (dac ă este cazul)  
▼B 
6) EVENIMENTE ȘI ANOMALII SPECIFICE PRODUC ĂTORULUI, DISPO ­
NIBILE FĂRĂ ACORDUL PREALABIL AL CONDUC ĂTORULUI AUTO  
Eveniment sau anomalie  Reguli de stocare  Date care trebuie înregistrate pentru fiecare eveniment  
Se specific ă de către produ­
cător Se specific ă de către produc ător Se specific ă de către produc ător ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 468  
ANEXA 2  
DIAGRAMELE SECVEN ȚELOR PENTRU SCHIMBURILE DE MESAJE CU UNITATEA ITS.  
Figura 1  
Diagrama secven țelor pentru încercarea de validare a PIN-ului
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 469  
Figura 2  
Diagrama secven țelor pentru verificarea autoriz ării unității ITS
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 470  
Figura 3  
Diagrama secven țelor pentru prelucrarea unei solicit ări de date clasificate ca fiind publice (dup ă introducerea 
corectă a PIN-ului)
  
Figura 4  
Diagrama secven țelor pentru prelucrarea unei solicit ări de date clasificate ca având caracter personal (dup ă 
introducerea corect ă a PIN-ului)
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 471  
Figura 5  
Diagrama secven țelor pentru încercarea de validare a PUC-ului
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 472  
ANEXA 3  
SPECIFICA ȚII ASN. 1
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 473
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 474
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 475
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 476
  
► (1) M1 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 477
  
► (1) (2) (3)  M1 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 478
  
► (1) M1 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 479
  
► (1) (2) M1 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 480
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 481
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 482
  
► (1) M1 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 483
  
▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 484  
Apendicele 14.  
FUNCȚIA DE COMUNICARE LA DISTAN ȚĂ 
CUPRINS  
1 INTRODUCERE  
2 DOMENIU DE APLICARE  
3 ACRONIME, DEFINI ȚII ȘI NOTAȚII 
4 SCENARII OPERA ȚIONALE  
4.1 Prezentare general ă 
4.1.1 Condi ții prealabile pentru transferul de date prin interfa ța DSRC de 
5,8 GHz  
4.1.2 Profilul 1a: prin intermediul unui cititor pentru comunicarea în scopul 
detectării timpurii la distan ță orientat manual sau montat temporar în 
afara părții carosabile și orientat  
4.1.3 Profilul 1b: prin intermediul unui cititor pentru comunicarea în scopul 
detectării timpurii la distan ță (REDCR) montat pe vehicul și direcționat  
4.2 Securitate/integritate  
5 CONCEP ȚIA ȘI PROTOCOALELE COMUNIC ĂRII LA DISTAN ȚĂ 
5.1 Concep ție 
5.2 Fluxul de lucru  
5.2.1 Opera țiuni 
5.2.2 Interpretarea datelor primite prin comunicarea DSRC  
5.3 Parametri ai interfe ței fizice DSRC pentru comunicarea la distan ță 
5.3.1 Constrângeri legate de amplasament  
5.3.2 Parametri ai leg ăturii descendente și ai legăturii ascendente  
5.3.3 Concep ția antenei  
5.4 Cerin țe de protocol DSRC pentru RTM  
5.4.1 Prezentare general ă 
5.4.2 Comenzi  
5.4.3 Secven ța comenzilor de interogare  
5.4.4 Structuri de date  
5.4.5 Elementele  RtmData , acțiunile realizate și definiții 
5.4.6 Mecanismul de transfer al datelor  
5.4.7 Descriere detaliat ă a tranzacției DSRC  
5.4.8 Descrierea tranzac ției de testare DRSC  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 485  
5.6 Transferul de date între DSRC-VU și VU  
5.6.1 Conexiunea fizic ă și interfețele 
5.6.2 Protocolul de aplica ție 
5.7 Gestionarea erorilor  
5.7.1 Înregistrarea și comunicarea datelor în DSRC-VU  
5.7.2 Erori de comunicare f ără fir 
6 TESTELE DE OPERA ȚIONALITATE ȘI DE VERIFICARE 
PERIODIC Ă PENTRU FUNC ȚIA DE COMUNICARE LA 
DISTANȚĂ 
6.1 Generalit ăți 
6.2 ECHO  
6.3 Testele de validare a con ținutului de date securizate  
1 INTRODUCERE  
Prezentul apendice specific ă detaliile privind proiectarea și procedurile 
care trebuie urmate pentru a utiliza func ția de comunicare la distan ță 
(„comunicarea”), astfel cum se prevede la articolul 9 din Regulamentul 
(UE) nr. 165/2014 („regulamentul”).  
DSC_1 Regulamentul (UE) nr. 165/2014 stabile ște faptul că tahograful 
trebuie să fie dotat cu o func ție de comunicare la distan ță care 
să permită agenților autorit ăților de control competente s ă 
citească informații din tahografele vehiculelor care trec pe 
lângă ei, prin utilizarea unui echipament de interogare la 
distanță [cititorul pentru comunicarea în scopul detect ării 
timpurii la distan ță (Remote early detection communication 
reader  – REDCR)], mai precis un echipament de interogare 
care se conecteaz ă fără fir folosind interfe țe DSRC ( Dedicated 
Short Range Communication ) de 5,8 GHz conforme cu CEN.  
Este important s ă se înțeleagă faptul că această funcție are ca 
unic scop s ă servească drept prefiltru pentru selectarea vehi ­
culelor în vederea unei inspec ții mai amănunțite și că nu înlo­
cuiește procesul de inspec ție formal stabilit în dispozi țiile 
Regulamentului (UE) nr. 165/2014. A se vedea considerentul 
9 din preambulul prezentului regulament, conform c ăruia 
comunicarea dintre tahograf și autoritățile de control în 
scopul controlului în trafic faciliteaz ă controalele selective în 
trafic.  
DSC_2  Datele  trebuie comunicate prin intermediul  comunic ării, care 
trebuie să constea într-o interac țiune fără fir folosind comu ­
nicații fără fir DSRC de 5,8 GHz în conformitate cu prezentul 
apendice, și testate pe baza parametrilor corespunz ători din EN 
300 674-1 [ Electromagnetic compatibility and Radio spectrum  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 486  
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 Industrial, Scientific and Medical (ISM) band; 
Part 1 : General characteristics and test methods for Road 
Side Units (RSU) and On -Board Units (OBU) ]. 
DSC_3  Comunicarea  cu echipamentul de comunicare trebuie stabilit ă 
doar atunci când este solicitat ă de echipamentul autorit ății de 
control competente care utilizeaz ă mijloace de radiocomu ­
nicație conforme [ cititorul pentru comunicarea în scopul 
detectării timpurii la distan ță (REDCR) ]. 
DSC_4  Datele  trebuie securizate, pentru a se asigura integritatea.  
DSC_5 Accesul la  datele  comunicate trebuie limitat la autorit ățile de 
control competente care sunt autorizate s ă verifice înc ălcările 
Regulamentului (CE) nr. 561/2006 și ale Regulamentului (UE) 
nr. 165/2014 și la ateliere, în m ăsura în care acest acces este 
necesar pentru a se verifica func ționarea corect ă a tahografului.  
DSC_6  Datele  transmise în timpul  comunic ării trebuie limitate la 
datele necesare pentru efectuarea de controale selective în 
trafic ale vehiculelor al c ăror tahograf este posibil s ă fi fost 
manipulat sau utilizat abuziv.  
DSC_7 Integritatea și securitatea datelor trebuie ob ținute prin secu ­
rizarea  datelor  din cadrul unit ății montate pe vehicul (VU) și 
transmiterea doar a datelor utile securizate și a datelor legate 
de securitate (a se vedea 5.4.4) prin mediul de comunicare f ără 
fir DSRC de 5,8 GHz, ceea ce înseamn ă că doar persoanele 
autorizate din cadrul autorit ăților de control competente dispun 
de mijloacele necesare pentru în țelegerea datelor transmise prin  
comunicare  și pentru verificarea autenticit ății acestora. A se 
vedea apendicele 11 – Mecanisme de securitate comune.  
DSC_8  Datele  trebuie să conțină o marcă temporală care să indice 
când au fost actualizate ultima dat ă. 
DSC_9 Con ținutul datelor de securitate trebuie s ă fie cunoscut și 
controlat doar de autorit ățile de control competente și de 
părțile cărora acestea le împ ărtășesc informa țiile respective și 
nu intră sub inciden ța prevederilor  comunic ării care face 
obiectul prezentului apendice, cu excep ția cazului în care  
comunicarea  prevede transferarea unui pachet de date de secu ­
ritate împreun ă cu fiecare pachet de date utile.  
DSC_10 Aceea și arhitectur ă și același echipament trebuie s ă poată fi 
folosite pentru a ob ține alte concepte de date (precum „cânt ă­
rire–la-bord”) utilizând arhitectura specificat ă. 
DSC_11 Pentru clarificare, în conformitate cu dispozi țiile Regula ­
mentului (UE) nr. 165/2014 (articolul 7), datele referitoare la 
identitatea conduc ătorului auto nu sunt comunicate prin inter ­
mediul  comunic ării. 
2 DOMENIU DE APLICARE  
Scopul prezentului apendice este s ă precizeze modul în care agen ții 
autorităților de control competente utilizeaz ă o comunicare DSRC f ără 
fir de 5,8 GHz specificat ă pentru a ob ține de la distan ță date ( datele ) de ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 487  
la un vehicul vizat, care identific ă faptul că este posibil ca vehiculul 
vizat să încalce Regulamentul (UE) nr. 165/2014 și că ar trebui s ă fie 
avut în vedere pentru oprirea în scopul unei investiga ții mai amănunțite. 
Regulamentul (UE) nr. 165/2014 impune ca datele colectate s ă se 
limiteze la sau s ă țină de date care identific ă o potențială încălcare, 
conform defini ției de la articolul 9 din Regulamentul (UE) nr. 165/2014.  
▼M1 
În acest scenariu, timpul disponibil pentru comunicare este limitat, 
deoarece  comunicarea  este selectiv ă și conceput ă să fie cu raz ă scurtă 
de acțiune. În plus, acelea și mijloace de comunicare ca cele folosite la 
monitorizarea de la distan ță a tahografelor (RTM) pot fi de asemenea 
utilizate de autorit ățile de control competente pentru alte aplica ții 
[precum greut ățile și dimensiunile maxime ale vehiculelor grele de 
marfă definite în Directiva (UE) 2015/719], iar aceste opera țiuni pot fi 
separate sau secven țiale, la discre ția autorităților de control competente.  
▼B 
Prezentul apendice precizeaz ă: 
— Echipamentele, procedurile și protocoalele de comunicare care 
trebuie folosite pentru realizarea  comunic ării. 
— Standardele și regulamentele cu care trebuie s ă fie conform echipa ­
mentul radio.  
— Prezentarea  datelor  către echipamentul de  comunicare.  
— Procedurile de interogare și de descărcare și secvența de opera țiuni. 
— Datele  de transferat.  
— Potențiala interpretare a  datelor  transferate prin intermediul  comuni­
cării. 
— Prevederile referitoare la datele de securitate legate de  comunicare.  
— Disponibilitatea  datelor  pentru autorit ățile de control competente.  
— Modul în care  cititorul pentru comunicarea în scopul detect ării 
timpurii la distan ță poate solicita concepte diferite de date privind 
mărfurile și parcul auto („freight and fleet”).  
Pentru clarificare, prezentul apendice  nu precizeaz ă: 
— Colectarea  datelor  și gestionarea acestora în cadrul VU [care trebuie 
să depindă de concep ția produsului, în afara cazului în care sunt 
specificate în alt ă parte a Regulamentului (UE) nr. 165/2014].  
— Forma de prezentare a datelor colectate c ătre agentul autorit ăților de 
control competente, și nici criteriile care trebuie folosite de autori ­
tățile de control competente pentru a decide ce vehicule s ă fie oprite 
[care trebuie s ă depindă de concep ția produsului, în afara cazului în 
care sunt specificate în alt ă parte a Regulamentului (UE) nr. 165/2014 
sau într-o decizie de politic ă a autorităților de control competente]. 
Pentru clarificare:  comunicarea  doar pune  datele  la dispozi ția auto­
rităților de control competente pentru ca  acestea să poată lua decizii 
în cunoștință de cauză. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 488  
— Prevederi referitoare la securitatea datelor (precum criptarea) pentru 
conținutul  datelor  (care sunt specificate în apendicele 11 – 
Mecanisme de securitate comune).  
— Detalii privind orice alte concepte de date în afara RTM care ar 
putea fi ob ținute utilizând aceea și arhitectur ă și același echipament.  
— Detalii privind comportamentul și gestionarea dintre VU-uri și 
DSRC-VU, și nici privind comportamentul în cadrul DSRC-VU (în 
afara furniz ării datelor  atunci când sunt solicitate de un REDCR).  
3 ACRONIME, DEFINI ȚII ȘI NOTAȚII 
În prezentul apendice sunt utilizate urm ătoarele acronime și definiții 
specifice prezentului apendice:  
Antena  dispozitiv electric care transform ă 
puterea electric ă în unde radio și 
invers, utilizat în combina ție cu un 
transmițător radio sau cu un receptor 
radio. Atunci când se afl ă în 
funcțiune, un transmi țător radio 
furnizează un curent electric care 
oscilează la frecven ța radio a termi ­
nalelor antenei, iar antena radiaz ă 
energia din curent sub form ă de 
unde electromagnetice (unde radio). 
La recepție, o anten ă intercepteaz ă o 
parte din puterea unei unde electro ­
magnetice pentru a produce o foarte 
mică tensiune la terminalele sale, 
care este aplicat ă receptorului 
pentru a fi amplificat ă. 
Comunicarea  schimb de informa ții/date între un 
DSRC-REDCR și o DSRC-VU în 
conformitate cu sec țiunea 5, într-o 
relație master-slave , pentru a ob ține 
datele.  
Datele  date securizate într-un format definit 
(a se vedea 5.4.4 ) solicitate de  
DSRC-REDCR  și furnizate  DSRC- 
REDCR  de către DSRC-VU  printr-o 
legătură DSRC de 5,8 GHz, definit ă 
la punctul 5 de mai jos.  
Regulamentul (UE) nr. 165/2014  Regulamentul (UE) nr. 165/2014 al 
Parlamentului European și al 
Consiliului din 4 februarie 2014 
privind tahografele în transportul 
rutier, de abrogare a Regulamentului  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 489  
(CEE) nr. 3821/85 al Consiliului 
privind aparatura de înregistrare în 
transportul rutier și de modificare a 
Regulamentului (CE) nr. 561/2006 
al Parlamentului European și al 
Consiliului privind armonizarea 
anumitor dispozi ții ale legisla ției 
sociale în domeniul transporturilor 
rutiere.  
AID Identificator de aplica ție 
BLE  Bluetooth de energie redus ă 
(Bluetooth Low Energy ) 
BST  Tabel de serviciu al radiobalizei  
CIWD  Introducerea cardului în timpul 
conducerii  
CRC  Verificare redundant ă ciclică 
DSC (n)  Identificator al unei cerin țe privind 
un apendice DSRC specific  
DSRC  Comunica ții specializate cu raz ă 
scurtă de acțiune 
DSRC-REDCR  DSRC – cititor pentru comunicarea 
în scopul detect ării timpurii la 
distanță. 
DSRC-VU  DSRC – unitate montat ă pe vehicul. 
Acesta este „echipamentul de comu ­
nicare la distan ță” definit în anexa 
1C. 
DWVC  Conducere f ără un card valabil  
EID Identificator de element  
LLC  Controlul leg ăturii logice  
LPDU  Unitate de date a protocolului LLC  
OWS  Sistem de cânt ărire la bord  
PDU  Unitate de date pentru protocol  
REDCR  Cititor pentru comunicarea în scopul 
detectării timpurii la distan ță. Acesta 
este „cititorul pentru comunicarea în 
scopul detect ării timpurii la distan ță” 
definit în anexa 1C.  
RTM  Monitorizarea de la distan ță a taho­
grafelor  
SM-REDCR  Modul de securitate-Cititor pentru 
comunicarea în scopul detect ării 
timpurii la distan ță 
TARV  Aplica ții telematice pentru vehicule 
reglementate (seria de standarde 
ISO 15638)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 490  
VU Unitate montat ă pe vehicul  
VUPM  Memoria util ă a unității montate pe 
vehicul  
VUSM  Modulul de securitate al unit ății 
montate pe vehicul  
VST  Tabel de serviciu al vehiculului  
WIM  Cânt ărire în mers  
WOB  Cânt ărire la bord  
Specificația definită în prezentul apendice se refer ă la toate sau la o parte 
din următoarele regulamente și standarde și depinde de acestea. În cadrul 
clauzelor din prezentul apendice sunt specificate standardele relevante 
sau clauzele relevante ale standardelor. În cazul oric ărei contradic ții, 
clauzele din prezentul apendice prevaleaz ă. În cazul oric ărei contradic ții 
privind un aspect pentru care nu este stabilit ă nicio specifica ție clară în 
prezentul apendice, prevaleaz ă operarea conform ERC 70-03 (cu testare 
pe baza parametrilor corespunz ători din EN 300 674-1), urmat ă în ordine 
descrescătoare a preferin ței de EN 12795, EN 12253, EN 12834 și EN 
13372, 6.2, 6.3, 6.4 și 7.1.  
Regulamentele și standardele la care se face trimitere în prezentul 
apendice sunt urm ătoarele:  
[1] Regulamentul (UE) nr. 165/2014 al Parlamentului European și al 
Consiliului din 4 februarie 2014 privind tahografele în transportul 
rutier, de abrogare a Regulamentului (CEE) nr. 3821/85 al 
Consiliului privind aparatura de înregistrare în transportul rutier 
și de modificare a Regulamentului (CE) nr. 561/2006 al Parla ­
mentului European și al Consiliului privind armonizarea anumitor 
dispoziții ale legisla ției sociale în domeniul transporturilor rutiere.  
[2] Regulamentul (CE) nr. 561/2006 al Parlamentului European și al 
Consiliului din 15 martie 2006 privind armonizarea anumitor 
dispoziții ale legisla ției sociale în domeniul transporturilor rutiere, 
de modificare a Regulamentelor (CEE) nr. 3821/85 și (CE) 
nr. 2135/98 ale Consiliului și de abrogare a Regulamentului 
(CEE) nr. 3820/85 al Consiliului (Text cu relevan ță pentru SEE).  
[3] ERC 70-03 CEPT: Recomandarea ECC 70-03:  Relating to the Use 
of Short Range Devices (SRD)  
[4] ISO 15638  Intelligent transport systems — Framework for coope ­
rative 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 Indus ­
trial, 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 — RO — 26.02.2020 — 002.001 — 491  
[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 SCENARII OPERA ȚIONALE  
4.1 Prezentare general ă 
Regulamentul (UE) nr. 165/2014 prevede scenarii specifice și controlate 
în cadrul c ărora trebuie utilizat ă comunicarea . 
Scenariile compatibile sunt:  
„Profilul de comunicare 1: Inspec ție în afara p ărții carosabile folosind 
un cititor pentru comunicarea în scopul detect ării timpurii la distan ță, 
care comunic ă fără fir pe o raz ă scurtă de acțiune și care instig ă o 
inspecție fizică în afara p ărții carosabile (master-:-slave).  
Profil cititor 1a: prin intermediul unui cititor pentru comunicarea în 
scopul detect ării timpurii la distan ță orientat manual sau montat 
temporar în afara p ărții carosabile și orientat  
Profil cititor 1b: prin intermediul unui cititor pentru comunicarea în 
scopul detect ării timpurii la distan ță montat pe vehicul și direcționat”.  
4.1.1  Condi ții prealabile pentru transferul de date prin interfa ța DSRC de 
5,8 GHz  
NOTĂ: pentru a în țelege contextul condi țiilor prealabile, cititorul este 
rugat să consulte figura 14.3 de mai jos.  
4.1.1.1 Datele stocate în VU  
DSC_12 VU are responsabilitatea de a actualiza la fiecare 60 de 
secunde și de a men ține datele care urmeaz ă să fie stocate în 
VU, fără nicio implicare a func ției de comunicare DSRC. 
Mijloacele prin care se realizeaz ă acest lucru sunt integrate 
în VU, specificate în Regulamentul (UE) nr. 165/2014, în 
anexa 1C sec țiunea 3.19 „ Comunicare la distan ță pentru 
controalele selective în trafic ” și nu sunt specificate în 
prezentul apendice.  
4.1.1.2 Datele furnizate echipamentului DSRC-VU  
DSC_13 VU are responsabilitatea de a actualiza datele tahografice 
DSRC ( datele ) ori de câte ori datele stocate în VU sunt actua ­
lizate, la intervalul stabilit în sec țiunea 4.1.1.1 (DSC_12), f ără 
nicio implicare a func ției de comunicare DSRC.  
DSC_14 Datele furnizate de VU sunt utilizate ca baz ă pentru a 
completa și a actualiza  datele ; mijloacele prin care se 
realizează acest lucru sunt specificate în anexa 1C sec țiunea 
3.19 „ Comunicare la distan ță pentru controalele selective în 
trafic ” sau, dac ă nu există o astfel de specifica ție, depind de 
concepția produsului și nu sunt specificate în prezentul 
apendice. Pentru concep ția conexiunii dintre echipamentul 
DSRC-VU și VU, vă rugăm să consultați secțiunea 5.6.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 492  
4.1.1.3 Con ținutul datelor  
DSC_15 Con ținutul și formatul  datelor  trebuie s ă fie de așa natură 
încât, odat ă decriptate, s ă fie structurate și puse la dispozi ție 
sub forma și în formatul specificate în sec țiunea 5.4.4 din 
prezentul apendice (Structuri de date).  
4.1.1.4 Prezentarea datelor  
DSC_16  Datele , actualizate frecvent în conformitate cu procedurile 
stabilite în sec țiunea 4.1.1.1, trebuie s ă fie securizate înainte 
de a fi prezentate c ătre DSRC-VU  și trebuie prezentate ca o 
valoare a conceptului de date securizate, pentru a fi stocate 
temporar în  DSRC-VU  ca versiunea curent ă a datelor.  Aceste 
date sunt transferate de la  VUSM  la funcția VUPM  pentru 
DSRC.  VUSM  și VUPM  sunt func ții, nu neap ărat entități 
fizice. Forma instan țierii fizice pentru realizarea acestor 
funcții ține de concep ția produsului, în afara cazului în care 
este specificat ă în altă parte a Regulamentului (UE) 
nr. 165/2014 . 
4.1.1.5 Datele de securitate  
DSC_17 Datele de securitate ( securityData ), care cuprind datele 
necesare  REDCR  pentru a-și îndeplini func ția de decriptare a  
datelor,  trebuie furnizate conform defini ției din apendicele 11 
(Mecanisme de securitate comune) și prezentate ca o valoare a 
conceptului de date, pentru stocarea temporar ă în DSRC-VU  ca 
versiunea curent ă a securityData,  sub forma definit ă în 
secțiunea 5.4.4 din prezentul apendice.  
4.1.1.6 Date VUPM disponibile pentru transfer prin interfa ța DSRC  
DSC_18 Conceptul de date care trebuie s ă fie mereu disponibil în 
funcția VUPM pentru DSRC în vederea transferului imediat 
în urma solicit ării REDCR  este definit în sec țiunea 5.4.4 pentru 
specificațiile complete privind modulul ASN.1.  
Prezentare general ă a profilului de comunicare 1  
Acest profil se refer ă la cazul de utilizare în care un agent al autorit ăților 
de control competente folose ște un cititor pentru comunicarea în scopul 
detectării timpurii la distan ță ce comunic ă pe o rază scurtă de acțiune 
(interfețe DSRC de 5,8 GHz care func ționează conform ERC 70-03 și 
sunt testate pe baza parametrilor corespunz ători din EN 300 674-1, 
conform descrierii din sec țiunea 5) ( REDCR ) pentru a identifica de la 
distanță un vehicul care este posibil s ă încalce Regulamentul (UE) 
nr. 165/2014 . Odată identificat, agentul autorit ăților de control 
competente care controleaz ă interogarea decide dac ă vehiculul ar 
trebui să fie oprit.  
4.1.2  Profilul 1a: prin intermediul unui cititor pentru comunicarea în scopul 
detectării timpurii la distan ță orientat manual sau montat temporar în 
afara părții carosabile și orientat  
În acest caz de utilizare, agentul autorit ăților de control competente se 
află în afara p ărții carosabile și orienteaz ă un REDCR  portabil ținut în 
mână ori montat pe un tripod sau un  REDCR  portabil similar dinspre 
marginea drumului c ătre centrul parbrizului vehiculului vizat. Interogarea 
se realizeaz ă folosind interfe țe DSRC de 5,8 GHz care func ționează 
conform ERC 70-03 și sunt testate pe baza parametrilor corespunz ători 
din EN 300 674-1, conform descrierii din sec țiunea 5. A se vedea figura 
14.1 (cazul de utilizare 1).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 493  
Figura 14.1  
Interogare cu REDCR sta ționar folosind DSRC de 5,8 GHz
  
4.1.3  Profilul 1b: prin intermediul unui cititor pentru comunicarea în scopul 
detectării timpurii la distan ță (REDCR) montat pe vehicul și direcționat  
În acest caz de utilizare, agentul autorit ăților de control competente se 
află într-un vehicul în mi șcare și fie orienteaz ă un REDCR  portabil ținut 
în mână dinspre vehicul c ătre centrul parbrizului vehiculului vizat, fie  
REDCR-ul  este montat în sau pe vehicul astfel încât s ă țintească centrul 
parbrizului vehiculului vizat atunci când vehiculul pe sau în care este 
situat cititorul pentru comunicarea în scopul detect ării timpurii la distan ță 
se află într-o anumit ă poziție relevant ă față de vehiculul vizat (de 
exemplu direct în fa ța acestuia în cadrul unui flux de trafic). Interogarea 
se realizeaz ă folosind interfe țe DSRC de 5,8 GHz care func ționează 
conform ERC 70-03 și sunt testate pe baza parametrilor corespunz ători 
din EN 300 674-1, conform descrierii din sec țiunea 5. A se vedea figura 
14.2. (Cazul de utilizare 2).  
Figura 14.2  
Interogare cu REDCR mobil folosind DSRC de 5,8 GHz
  
4.2 Securitate/integritate  
Pentru a da posibilitatea de verificare a autenticit ății și integrității datelor 
descărcate prin comunicarea la distan ță, datele  securizate sunt verificate 
și decriptate în conformitate cu apendicele 11 – Mecanisme de securitate 
comune.  
5 CONCEP ȚIA ȘI PROTOCOALELE COMUNIC ĂRII LA DISTAN ȚĂ 
5.1 Concep ție 
Concepția funcției de comunicare la distan ță în cadrul tahografului inte ­
ligent este prezentat ă în figura 14.3.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 494  
Figura 14.3  
Concepția funcției de comunicare la distan ță
 
DSC_19 Urm ătoarele func ții se află în VU:  
— Modulul de securitate ( VUSM ). Această funcție prezentă în 
VU este responsabil ă pentru securizarea  datelor  care 
urmează să fie transmise de la  DSRC-VU  către agentul 
autorităților de control competente prin comunicarea la 
distanță. 
— Datele securizate sunt stocate în memoria VUSM. La inter ­
valele de timp stabilite în sec țiunea 4.1.1.1 (DSC_12), VU 
criptează și completeaz ă conceptul  RTMdata  (care cuprinde 
valorile conceptelor de date de securitate și de date utile 
stabilite mai jos în prezentul apendice) aflat în memoria 
DSRC-VU. Func ționarea modulului de securitate este 
definită în apendicele 11 (Mecanisme de securitate 
comune) și nu intră sub inciden ța prezentului apendice, 
cu excepția faptului c ă va trebui s ă furnizeze actualiz ări 
echipamentului de comunicare al VU de fiecare dat ă 
când se modific ă datele din VUSM.  
— Comunicarea dintre VU și DSRC-VU poate fi o comu ­
nicare prin cablu sau o comunicare prin Bluetooth de 
energie redus ă (BLE), iar amplasarea fizic ă a DSRC-VU 
poate fi împreun ă cu antena de pe parbrizul vehiculului, în 
cadrul VU sau undeva între acestea.  
— DSRC-VU trebuie s ă dispună de o surs ă de energie 
electrică fiabilă, disponibil ă în orice moment. Mijloacele 
prin care este alimentat ă cu energie electric ă țin de 
deciziile de concep ție. 
— Memoria DSRC-VU trebuie s ă fie nevolatil ă, pentru a 
menține datele în DSRC-VU chiar și atunci când 
contactul vehiculului este în pozi ția „oprit”.  
— În cazul în care comunicarea dintre VU și DSRC-VU se 
face prin BLE și sursa de energie electric ă este o baterie 
nereîncărcabilă, sursa de energie electric ă a DSRC-VU 
trebuie înlocuit ă cu ocazia fiec ărei inspecții periodice, iar  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 495  
producătorul DSRC-VU trebuie s ă fie responsabil pentru 
asigurarea faptului c ă sursa de energie electric ă este 
adecvată pentru a rezista de la o inspec ție periodic ă până 
la următoarea men ținând accesul normal la date printr-un 
REDCR de-a lungul întregii perioade, f ără defectări sau 
întreruperi.  
— Echipamentul de „memorie util ă” al RTM VU ( VUPM ). 
Această funcție prezentă în VU este responsabil ă pentru 
furnizarea și actualizarea  datelor . Conținutul  datelor  („Ta­
chographPayload”) este definit în sec țiunea 5.4.4/5.4.5 de 
mai jos și este actualizat la intervalul stabilit în sec țiunea 
4.1.1.1 (DSC_12).  
— DSRC-VU. Aceast ă funcție, aflată în cadrul antenei sau 
conectată la anten ă și în comunicare cu VU printr-o 
conexiune prin cablu sau f ără fir (BLE), este cea care 
deține datele curente ( datele VUPM ) și gestioneaz ă 
răspunsul la o interogare transmis ă prin mediul DSRC de 
5,8 GHz. Deconectarea echipamentului DSRC sau apari ția 
unor interferen țe, în timpul utiliz ării normale a vehiculului, 
cu funcționarea echipamentului DSRC este considerat ă o 
încălcare a Regulamentului (UE) nr. 165/2014.  
— Modulul de securitate (REDCR) ( SM-REDCR ) este func ția 
utilizată pentru a decripta datele care provin de la VU și a 
verifica integritatea acestora. Mijloacele prin care se 
realizează acest lucru sunt stabilite în apendicele 11 
(Mecanisme de securitate comune) și nu sunt definite în 
prezentul apendice.  
— Funcția echipamentului DSRC (REDCR) ( DSRC-REDCR ) 
cuprinde un transceiver de 5,8 GHz și programele asociate 
de firmware și de software, care gestioneaz ă comunicarea  
cu DSRC-VU  în conformitate cu prezentul apendice.  
— DSRC-REDCR  interogheaz ă DSRC-VU  a vehiculului vizat 
și obține datele  (datele VUPM  curente ale vehiculului 
vizat) prin leg ătura DSRC și proceseaz ă și stocheaz ă 
datele primite în  SM-REDCR-ul  său. 
▼M1 
— Antena DSRC-VU trebuie amplasat ă într-un loc în care 
optimizeaz ă comunicarea DSRC dintre vehicul și antena 
de citire aflat ă în afara p ărții carosabile, atunci când 
cititorul este instalat la 15 metri distan ță în fața vehiculului 
și la 2 metri în ălțime, vizând centrul orizontal și vertical al 
parbrizului. Pentru vehiculele u șoare, este adecvat ă o 
instalare care corespunde p ărții superioare a parbrizului. 
Pentru toate celelalte vehicule antena DSRC trebuie s ă 
fie instalat ă fie în partea de jos, fie în partea de sus a 
parbrizului.  
▼B 
DSC_20 Antena și comunicarea trebuie s ă funcționeze conform ERC 
70-03 și să fie testate pe baza parametrilor corespunz ători din 
EN 300 674-1, conform descrierii din sec țiunea 5. Antena și 
comunicarea pot utiliza tehnici de atenuare a riscului de inter ­
ferențe radio, conform descrierii din raportul 228 al ECC, 
folosind de exemplu filtre în cadrul comunic ării DSRC de 
5,8 GHz conforme cu CEN.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 496  
DSC_21 Antena DSRC trebuie s ă fie conectat ă la echipamentul DSRC- 
VU fie direct în cadrul modulului montat pe sau aproape de 
parbriz, fie printr-un cablu special construit în a șa fel încât s ă 
facă dificilă deconectarea ilegal ă. Deconectarea sau interferen ța 
cu funcționarea antenei reprezint ă o încălcare a Regula ­
mentului (UE) nr. 165/2014. Mascarea sau modificarea preju ­
diciabilă în alt fel, în mod inten ționat, a performan ței 
operaționale a antenei este considerat ă o încălcare a Regula ­
mentului (UE) nr. 165/2014.  
DSC_22  ►M1 Formatul antenei nu este definit și reprezintă o decizie 
comercială, atât timp cât DSRC-VU montat ă îndepline ște 
cerințele de conformitate definite în sec țiunea 5 de mai jos. 
Antena trebuie pozi ționată conform celor stabilite la punctul 
DSC_19 și trebuie s ă fie compatibil ă în mod eficient cu 
cazurile de utilizare descrise la punctele 4.1.2 și 4.1.3. ◄ 
Figura 14.4  
Exemplu de pozi ționare a antenei DSRC de 5,8 GHz pe parbrizul 
vehiculelor reglementate
  
Formatul  REDCR  și al antenei sale poate varia în func ție de circum ­
stanțele cititorului (montat pe tripod, ținut în mân ă, montat pe vehicul 
etc.) și de modul de utilizare folosit de agentul autorit ăților de control 
competente.  
O funcție de afișare și/sau de notificare este utilizat ă pentru a prezenta 
agentului autorit ăților de control competente rezultatele func ției de 
comunicare la distan ță. Afișarea poate ap ărea pe un ecran, sub forma 
unui document imprimat, sub forma unui semnal audio sau ca o 
combinație a acestor tipuri de notific ări. Forma acestei afi șări și/sau 
notificări ține de cerin țele agenților autorit ăților de control competente 
și de concep ția echipamentului și nu este specificat ă în prezentul 
apendice.  
DSC_23 Formatul și concepția REDCR  depind de concep ția comercial ă, 
conform ERC 70-03, și de specifica țiile privind concep ția și 
performanța definite în prezentul apendice (sec țiunea 5.3.2), 
oferind astfel pie ței flexbilitatea maxim ă pentru a proiecta  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 497  
și a furniza echipamente care s ă servească scenariilor specifice 
de interogare ale oric ărei autorități de control competente date.  
DSC_24 Formatul și concepția DSRC-VU  și poziționarea acesteia 
înăuntrul sau în afara VU depind de concep ția comercial ă, 
conform ERC 70-03, și de specifica țiile privind concep ția și 
performanța definite în prezentul apendice (sec țiunea 5.3.2) și 
în prezenta sec țiune (5.1).  
DSC_25 Cu toate acestea,  DSRC-VU  trebuie să fie în mod rezonabil 
capabilă să accepte valori ale conceptelor de date de la alte 
echipamente inteligente de vehicule prin intermediul unei 
conexiuni și al unor protocoale conforme cu standarde 
deschise din domeniu (de exemplu de la echipamente de 
cântărire la bord), atât timp cât aceste concepte de date sunt 
identificate prin denumiri de fi șier/identificatori de aplica ție 
unici și cunoscuți; instrucțiunile de utilizare a unor astfel de 
protocoale trebuie puse la dispozi ția Comisiei Europene, 
precum și, în mod gratuit, la dispozi ția producătorilor de echi ­
pamente relevante.  
5.2 Fluxul de lucru  
5.2.1  Opera țiuni 
Fluxul de opera țiuni este reprezentat în figura 14.5.  
Figura 14.5  
Fluxul de lucru pentru func ția de comunicare la distan ță
 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 498  
Etapele sunt descrise mai jos:  
a. Ori de câte ori un vehicul se afl ă în funcțiune (contactul este în 
poziția „PORNIT”), tahograful furnizeaz ă date func ției VU. Func ția 
VU pregătește datele  pentru func ția de comunicare la distan ță 
(criptare) și actualizeaz ă VUPM de ținute în memoria  DSRC-VU  
(conform defini ției din sec țiunile 4.1.1.1-4.1.1.2).  Datele  colectate 
trebuie formatate conform celor stabilite în sec țiunile 5.4.4-5.4.5 de 
mai jos.  
b. Cu fiecare ocazie în care  datele  sunt actualizate, marca temporal ă 
definită în conceptul de date de securitate trebuie actualizat ă. 
c. Funcția VUSM  securizeaz ă datele în conformitate cu procedurile 
stabilite în apendicele 11.  
d. Cu fiecare ocazie în care  datele  sunt actualizate (a se vedea 4.1.1.1- 
4.1.1.2),  datele  trebuie transferate c ătre DSRC-VU , unde înlocuiesc 
orice date anterioare, pentru ca datele curente actualizate ( datele)  să 
fie întotdeauna disponibile pentru a fi furnizate în cazul interog ării de 
către un  REDCR . Atunci când sunt transmise de VU c ătre DSRC-VU,  
datele  trebuie să poată fi identificate prin numele de fi șier RTMData  
sau prin identificatori „ApplicationID” și „Attribute”.  
e. Dacă un agent al autorit ăților de control competente dore ște să vizeze 
un vehicul și să colecteze  datele  de la vehiculul vizat, agentul auto ­
rităților de control competente trebuie întâi s ă își introducă propriul 
card inteligent ( smartcard ) în REDCR,  pentru a face posibil ă comu­
nicarea  și pentru a permite  SM-REDCR  să verifice autenticitatea 
acestuia și să decripteze datele.  
f. Apoi, agentul autorit ății de control competente vizeaz ă un vehicul și 
solicită datele prin comunicare la distan ță. REDCR-ul  deschide o 
sesiune prin interfa ța DSRC de 5,8 GHz cu  DSRC-VU  a vehiculului 
vizat și solicită datele . Datele  sunt transferate c ătre REDCR  prin 
sistemul de comunicare f ără fir, ca atribut DSRC, folosind serviciul 
de aplicație GET definit în sec țiunea 5.4. Atributul con ține valorile 
datelor utile criptate și datele de securitate DSRC.  
g. Datele sunt analizate de echipamentul  REDCR  și prezentate agentului 
autorității de control competente.  
h. Agentul autorit ății de control competente utilizeaz ă datele pentru a 
lua decizia dac ă să oprească sau nu vehiculul pentru o inspec ție 
detaliată sau dacă să ceară altui agent al autorit ății de control 
competente s ă oprească vehiculul.  
5.2.2  Interpretarea datelor primite prin comunicarea DSRC  
DSC_26 Datele primite prin interfa ța de 5,8 GHz trebuie s ă prezinte 
sensul și formatul definite în sec țiunile 5.4.4 și 5.4.5 de mai 
jos, și numai sensul și formatul respective, și trebuie în țelese 
în contextul obiectivelor definite în acestea. În conformitate 
cu dispozi țiile Regulamentului (UE) nr. 165/2014,  datele  
trebuie utilizate numai pentru a furniza informa ții relevante  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 499  
unei autorit ăți de control competente, pentru ca aceasta s ă 
poată stabili ce vehicul ar trebui oprit în vederea efectu ării 
unei inspec ții fizice, și trebuie distruse ulterior în conformitate 
cu articolul 9 din Regulamentul (UE) nr. 165/2014.  
5.3 Parametri ai interfe ței fizice DSRC pentru comunicarea la distan ță 
5.3.1  Constrângeri legate de amplasament  
DSC_27 Interogarea la distan ță a vehiculelor printr-o interfa ță DSRC 
de 5,8GHz nu ar trebui utilizat ă la o distan ță mai mică de 200 
de metri de un suport DSRC de 5,8 GHz aflat în func țiune.  
5.3.2  Parametri ai leg ăturii descendente și ai legăturii ascendente  
DSC_28 Echipamentul utilizat pentru monitorizarea de la distan ță a 
tahografelor trebuie s ă fie conform și să funcționeze în 
conformitate cu ERC70-03 și cu parametrii defini ți în 
tabelele 14.1 și 14.2 de mai jos.  
DSC_29 În plus, pentru a asigura compatibilitatea cu parametrii 
operaționali ai altor sisteme DSRC de 5,8 GHz standardizate, 
echipamentul folosit pentru monitorizarea de la distan ță a 
tahografelor trebuie s ă fie conform cu parametrii din EN 
12253 și din EN 13372.  
Și anume:  
Tabelul 14.1  
Parametrii leg ăturii descendente  
Nr. crt.  Parametru  Valoare (valori)  Observa ție 
D1 Frecven țe purtătoare pentru 
legătura descendent ă Există patru alternative care 
pot fi folosite de un 
REDCR: 
5,7975 GHz 
5,8025 GHz 
5,8075 GHz 
5,8125 GHz  Conform ERC 70-03. 
Frecvențele purtătoare pot fi 
selectate de cel care implementeaz ă 
sistemul sta ționar de monitorizare 
în trafic și nu este necesar s ă fie 
cunoscute în cadrul DSRC-VU 
(În conformitate cu EN 12253, EN 
13372)  
D1a (*) Toleran ța frecven țelor 
purtătoare  în limita a ± 5 ppm  (În conformitate cu EN 12253)  
D2 (*) Masca spectral ă a 
emițătorului RSU (REDCR)  Conform ERC 70-03. 
REDCR trebuie s ă fie 
conform cu clasele B,C 
definite în EN 12253. 
În prezenta anex ă nu există 
nicio altă cerință specifică Parametru utilizat pentru 
controlarea interferen țelor dintre 
echipamentele de interogare din 
apropiere (conform defini ției din 
EN 12253 și EN 13372).  
D3 Interval de frecven ță minim 
pentru OBU (DSRC-VU)  5,795-5,815 GHz  (În conformitate cu EN 12253)  
D4 (*) E.I.R.P. maxim ă Conform ERC 70-03 (f ără 
licență) și reglement ărilor 
naționale 
maximum + 33 dBm  (În conformitate cu EN 12253)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 500  
Nr. crt.  Parametru  Valoare (valori)  Observa ție 
D4a Masca E.I.R.P. unghiular ă În conformitate cu specifi ­
cațiile declarate și publicate 
ale proiectantului echipa ­
mentului de interogare  (În conformitate cu EN 12253)  
D5 Polarizare  Circular ă levogiră (În conformitate cu EN 12253)  
D5a Polarizare ortogonal ă XPD: 
În linia de vizare direct ă: 
(REDCR) RSU t ≥ 15 dB 
(DSRC-VU) OBU r ≥ 
10 dB 
În zona de – 3 dB: 
(REDCR) RSU t ≥ 10 dB 
(DSRC-VU) OBU r ≥ 6 dB  (În conformitate cu EN 12253)  
D6 (*) Modula ție Modula ție de amplitudine în 
două trepte.  (În conformitate cu EN 12253)  
D6a (*) Indice de modula ție 0,5 … 0,9  (În conformitate cu EN 12253)  
D6b Diagram ă ochi  ≥ 90 % (timp) / ≥ 85 % 
(amplitudine)  
D7 (*) Codarea datelor  FM0 
Bitul ‘1’ are tranzi ții doar la 
începutul și la sfâr șitul 
intervalului de bi ți. Bitul 
‘0’ are o tranzi ție supli­
mentară în mijlocul inter ­
valului de bi ți față de bitul 
‘1’. (În conformitate cu EN 12253)  
D8 (*) Viteza bi ților 500 kBit/s  (În conformitate cu EN 12253)  
D8a Toleran ța tactului de bit  mai bun ă decât ± 100 ppm  (În conformitate cu EN 12253)  
D9 (*) Rata de eroare a bi ților 
(B.E.R.) pentru comunicare  ≤ 10  – 6 când puterea de 
intrare la OBU (DSRC-VU) 
se situează în intervalul dat 
de [D11a – D11b].  (În conformitate cu EN 12253)  
D10 Declan șator pentru ie șirea 
din starea inactiv ă pentru 
OBU (DSRC-VU)  OBU (DSRC-VU) se reac ­
tivează la primirea oric ărui 
cadru cu 11 sau mai mul ți 
octeți (inclusiv preambul)  Nu este necesar ă nicio schem ă 
specială de reactivare. 
DSRC-VU se poate reactiva la 
primirea unui cadru cu mai pu țin 
de 11 octe ți 
(În conformitate cu EN 12253)  
D10a  Timp de pornire maxim  ≤ 5 ms  (În conformitate cu EN 12253)  
D11 Zon ă de comunicare  Ansamblu spa țial în cadrul 
căruia se atinge o B.E.R. 
conform D9a  (În conformitate cu EN 12253)  
D11a  (*) Limita de putere pentru 
comunicare (superioar ă). – 24dBm  (În conformitate cu EN 12253)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 501  
Nr. crt.  Parametru  Valoare (valori)  Observa ție 
D11b  (*) Limita de putere pentru 
comunicare (inferioar ă). Puterea de intrare: 
– 43 dBm (linia de vizare 
directă) 
– 41 dBm [în intervalul de 
– 45 ° – + 45°Cores ­
punzând planului paralel cu 
suprafața carosabilului 
atunci când DSRC-VU este 
instalată ulterior în vehicul 
(azimut)]  (În conformitate cu EN 12253) 
Cerință extinsă pentru unghiurile 
orizontale pân ă la ± 45°, datorit ă 
cazurilor de utilizare definite în 
prezenta anex ă. 
D12 (*) Nivelul puterii de între ­
rupere al (DSRC-VU)  -60 dBm  (În conformitate cu EN 12253)  
D13 Preambul  Preambulul este obligatoriu.  (În conformitate cu EN 12253)  
D13a  Preambul – lungime și tipar  16 biți ± 1 bit de bi ți ‘1’ 
codați FM0  (În conformitate cu EN 12253)  
D13b  Forma de und ă a preambu ­
lului O secven ță alternant ă de 
nivel scăzut și nivel ridicat 
cu o durat ă a impulsului de 
2 μs. 
Toleranța este dată de D8a  (În conformitate cu EN 12253)  
D13c  Bi ți de final  RSU (REDCR) poate 
transmite maximum 8 bi ți 
după indicatorul de final. 
O OBU (DSRC-VU) nu 
este obligat ă să țină seama 
de acești biți suplimentari.  (În conformitate cu EN 12253)  
(*) – Parametri ai leg ăturii descendente care fac obiectul test ării conformit ății pe baza testului de parametru relevant din EN 300 674-1  
Tabelul 14.2  
Parametrii leg ăturii ascendente  
Nr. crt.  Parametru  Valoare (valori)  Observa ție 
U1 (*) Frecven țe subpurtătoare  O OBU (DSRC-VU) 
trebuie să fie compatibil ă 
cu 1,5 MHz și cu 2,0 MHz 
O RSU (REDCR) trebuie s ă 
fie compatibil ă cu 1,5 MHz 
sau cu 2,0 MHz sau cu 
ambele. U1-0: 1,5 MHz 
U1-1: 2,0 MHz  Selectarea frecven ței subpurtătoare 
(1,5 MHz sau 2,0 MHz) depinde de 
profilul EN 13372 selectat.  
U1a (*) Toleran ța frecven țelor 
subpurtătoare  în limita a ± 0,1 %  (În conformitate cu EN 12253)  
U1b Utilizarea de benzi laterale  Aceleași date de ambele 
părți (În conformitate cu EN 12253)  
U2 (*) Masca spectral ă a 
emițătorului OBU (DSRC- 
VU) În conformitate cu 
EN12253 
1) Putere în afara benzii: 
a se vedea ETSI EN 
300674-1  (În conformitate cu EN 12253)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 502  
Nr. crt.  Parametru  Valoare (valori)  Observa ție 
2) Putere în band ă: 
[U4a] dBm în 500 kHz 
3) Emisie în orice alt canal 
de legătură ascendent ă: 
U2(3)-1 = – 35 dBm în 
500 kHz  
U4a (*) E.I.R.P. maxim ă în bandă 
laterală unică (linia de 
vizare direct ă) Două opțiuni: 
U4a-0: – 14 dBm 
U4a-1: – 21 dBm  În conformitate cu specifica țiile 
declarate și publicate ale proiec ­
tantului echipamentului  
U4b (*) E.I.R.P. maxim ă în bandă 
laterală unică (35°)  Două opțiuni: 
— Nu se aplic ă 
— – 17dBm  În conformitate cu specifica țiile 
declarate și publicate ale proiec ­
tantului echipamentului  
U5 Polarizare  Circular ă levogiră (În conformitate cu EN 12253)  
U5a Polarizare ortogonal ă XPD: 
În linia de vizare direct ă: 
(REDCR) RSU r ≥ 15 dB 
(DSRC-VU) OBU t ≥ 
10 dB 
La – 3 dB: (REDCR) RSU 
r ≥ 10 dB 
(DSRC-VU) OBU t ≥ 6 dB  (În conformitate cu EN 12253)  
U6 Modula ția subpurtătoarei  2-PSK 
Date codate sincronizate cu 
subpurtătoarea: tranzi țiile 
datelor codate coincid cu 
tranzițiile subpurt ătoarei.  (În conformitate cu EN 12253)  
U6b Ciclu de func ționare  Ciclu de func ționare: 
50 % ± α, α ≤ 5 %  (În conformitate cu EN 12253)  
U6c Modula ție pe purtătoare  Multiplicarea subpurt ătoarei 
modulate cu purt ătoarea.  (În conformitate cu EN 12253)  
U7 (*) Codarea datelor  NRZI (Nicio tranzi ție la 
începutul bitului ‘1’, 
tranziție la începutul bitului 
‘0’, nicio tranzi ție în cadrul 
biților) (În conformitate cu EN 12253)  
U8 (*) Viteza bi ților 250 kbit/s  (În conformitate cu EN 12253)  
U8a Toleran ța tactului de bit  în limita a ± 1 000 ppm  (În conformitate cu EN 12253)  
U9 Rata de eroare a bi ților 
(B.E.R.) pentru comunicare  ≤10 – 6 (În conformitate cu EN 12253)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 503  
Nr. crt.  Parametru  Valoare (valori)  Observa ție 
U11 Zon ă de comunicare  Ansamblul spa țial în cadrul 
căruia este situat ă DSRC- 
VU astfel încât transmisiile 
sale să fie primite de 
REDCR cu o B.E.R. mai 
mică decât cea dat ă de U9a.  (În conformitate cu EN 12253)  
U12a  (*) Amplificare a etajului de 
amestec (limita inferioar ă) 1 dB pentru fiecare band ă 
laterală Intervalul unghiului: 
Simetric circular între linia 
de vizare direct ă și ± 35° 
și 
în intervalul de – 45 ° – + 
45 °Corespunzând planului 
paralel cu suprafa ța carosa­
bilului atunci când DSRC- 
VU este instalat ă ulterior 
în vehicul (azimut)  Mai mare decât intervalul de valori 
specificat pentru unghiurile 
orizontale pân ă la ± 45 °, datorit ă 
cazurilor de utilizare definite în 
prezenta anex ă. 
U12b  (*) Amplificare a etajului de 
amestec (limita superioar ă) 10 dB pentru fiecare band ă 
laterală Mai mică decât intervalul de valori 
specificat pentru fiecare band ă 
laterală într-un con circular în 
jurul liniei de vizare direct ă cu 
unghi de deschidere de ± 45 °  
U13 Preambul  Preambulul este obligatoriu.  (În conformitate cu EN 12253)  
U13a  Preambul 
Lungime și tipar  32-36 μs, modulate doar cu 
subpurtătoare, apoi 8 bi ți de 
biți ‘0’ codați NRZI.  (În conformitate cu EN 12253)  
U13b  Bi ți de final  DSRC-VU poate transmite 
maximum 8 bi ți după indi­
catorul de final. O RSU 
(REDCR) nu este obligat ă 
să țină seama de ace ști biți 
suplimentari.  (În conformitate cu EN 12253)  
(*) — Parametri ai leg ăturii ascendente care fac obiectul test ării conformit ății pe baza testului de parametru relevant din EN 300 674-1  
5.3.3  Concep ția antenei  
5.3.3.1 Antena REDCR  
DSC_30 Concep ția antenei  REDCR  depinde de concep ția comercial ă, 
în conformitate cu limitele definite în sec țiunea 5.3.2, care 
este adaptat ă pentru a optimiza performan ța de citire a  
DSRC-REDCR  în scopul specific și în circumstan țele de 
citire în care  REDCR  a fost proiectat s ă funcționeze.  
5.3.3.2 Antena VU  
DSC_31 Concep ția antenei  DSRC-VU  depinde de concep ția comer­
cială, în conformitate cu limitele definite în sec țiunea 5.3.2, 
care este adaptat ă pentru a optimiza performan ța de citire a  
DSRC-REDCR  în scopul specific și în circumstan țele de citire 
în care  REDCR  a fost proiectat s ă funcționeze.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 504  
DSC_32 Antena VU trebuie s ă fie fixată pe sau aproape de parbrizul 
vehiculului, conform specifica țiilor din sec țiunea 5.1 de mai 
sus. 
DSC_33 În mediul de testare dintr-un atelier (a se vedea sec țiunea 6.3), 
o antenă DSRC-VU, fixat ă conform sec țiunii 5.1 de mai sus, 
trebuie să se conecteze cu succes la o comunicare de testare 
standard și trebuie s ă realizeze cu succes o tranzac ție RTM 
conform defini ției din prezentul apendice, la o distan ță 
cuprinsă între 2 și 10 metri, mai mult de 99 % din timp, 
potrivit unei medii calculate pe baza a 1 000 de interog ări 
de citire.  
5.4 Cerin țe de protocol DSRC pentru RTM  
5.4.1  Prezentare general ă 
DSC_34 Protocolul de tranzac ție pentru desc ărcarea  datelor  prin 
legătura de interfa ță DSRC de 5,8 GHz trebuie s ă corespund ă 
etapelor descrise în cele ce urmeaz ă. Prezenta sec țiune descrie 
un flux de tranzac ție în condi ții ideale fără retransmiteri sau 
întreruperi ale comunic ării. 
NOTĂ Scopul fazei de ini țializare (etapa 1) este de a stabili 
comunicarea între  REDCR  și DSRC-VU-urile care au intrat în 
zona de tranzac ție DSRC de 5,8 GHz ( master-slave ), dar care 
nu au stabilit înc ă o comunicare cu  REDCR , și să notifice 
procesele de aplica ție. 
— Etapa 1  Inițializare.  REDCR  transmite un cadru 
conținând un „tabel de serviciu al radiobalizei” (BST) 
care include identificatorii de aplica ție (AID) din lista 
de serviciu cu care este compatibil. În aplica ția RTM, 
acesta va fi pur și simplu serviciul cu valoarea AID = 2 
(Freight&Fleet ). DSRC-VU  evalueaz ă BST primit și 
răspunde (a se vedea mai jos) cu o list ă a aplicațiilor 
cu care este compatibil ă din domeniul  Freight&Fleet  
sau nu răspunde dac ă nu este compatibil ă cu niciuna. 
Dacă REDCR  nu oferă AID=2, DSRC-VU nu r ăspunde 
REDCR.  
— Etapa 2  DSRC-VU  transmite un cadru con ținând o cerere 
de alocare a unei ferestre private.  
— Etapa 3  REDCR  transmite un cadru con ținând o alocare a 
unei ferestre private.  
— Etapa 4  DSRC-VU  utilizează fereastra privat ă alocată 
pentru a transmite un cadru con ținând tabelul s ău de 
serviciu al vehiculului (VST). Acest VST include o list ă 
a tuturor instan țierilor diferite de aplica ții cu care  DSRC- 
VU respectivă este compatibil ă în cadrul AID=2. Dife ­
ritele instan țieri trebuie identificate prin intermediul unor 
EID-uri unic generate, fiecare asociat cu o valoare de 
parametru pentru marca contextual ă de aplica ție (Appli­
cation Context Mark ), care indic ă aplicația și standardul 
compatibil.  
— Etapa 5  Apoi,  REDCR  analizează VST prezentat și fie 
întrerupe conexiunea (RELEASE) dac ă nu este interesat 
de nimic din ceea ce VST are de oferit (adic ă primește de 
la o DSRC-VU  un VST care nu este compatibil cu tran ­
zacția RTM), fie, dac ă primește un VST corespunz ător, 
pornește o instan țiere de aplica ție. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 505  
— Etapa 6  Pentru a realiza acest lucru, REDCR transmite 
un cadru con ținând o comand ă de obținere a datelor 
RTM, identificând instan țierea de aplica ție RTM prin 
precizarea identificatorului care corespunde instan țierii 
de aplicație RTM (conform celor specificate de DSRC- 
VU în VST), și alocă o fereastr ă privată. 
— Etapa 7  DSRC-VU  utilizează fereastra privat ă nou-alocat ă 
pentru a transmite un cadru con ținând identificatorul 
adresat care corespunde instan țierii de aplica ție RTM 
furnizate în VST, urmat de atributul  RtmData  (element 
util + element de securitate).  
— Etapa 8  Dacă sunt solicitate mai multe servicii, valoarea 
„n” se modific ă în numărul de referin ță al serviciului 
următor și procesul este repetat.  
— Etapa 9  REDCR  confirmă primirea datelor prin trans ­
miterea unui cadru care con ține o comand ă RELEASE 
către DSRC-VU  pentru a încheia sesiunea SAU, dac ă nu 
a reușit să valideze primirea cu succes a LDPU, revine la 
etapa 6.  
A se vedea figura 14.6 pentru o descriere în imagini a proto ­
colului de tranzac ție. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 506  
Figura 14.6  
Flux de proces RTM prin DSRC de 5,8 GHz
  
5.4.2  Comenzi  
DSC_35 Urm ătoarele comenzi sunt singurele func ții utilizate într-o 
etapă de tranzac ție RTM  
— INITIALISATION.request : o comand ă, emisă de 
REDCR sub forma unei transmisii cu definirea aplica țiilor 
cu care este compatibil REDCR.  
— INITIALISATION.response : un răspuns din partea 
DSRC-VU care confirm ă conexiunea și conține o listă a 
instanțelor de aplica ție compatibile, precum și caracteris ­
ticile și informațiile privind modul de adresare a acestora 
(EID).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 507  
— GET.request : o comand ă, emisă de REDCR  către DSRC- 
VU, care precizeaz ă instanțierea de aplica ție ce trebuie 
adresată prin intermediul unui EID definit, conform 
VST primit, indicându-i  DSRC-VU  să transmită atributul 
(atributele) ales(e) împreun ă cu  datele . Obiectivul 
comenzii GET este ca  REDCR  să obțină datele  de la  
DSRC-VU . 
— GET.response : un răspuns din partea DSRC-VU, care 
conține datele  solicitate.  
— ACTION.request ECHO : o comand ă care îi indic ă 
DSRC-VU  să răspundă transmițând date de la  DSRC-VU  
la REDCR . Obiectivul comenzii ECHO este de a permite 
atelierelor sau unit ăților de testare pentru omologarea de 
tip să verifice dac ă legătura DSRC func ționează fără a 
avea nevoie de acces la elementele de securitate.  
— ACTION .response ECHO: Un r ăspuns din partea DSRC 
VU la comanda ECHO.  
— EVENT_REPORT.request  RELEASE: o comand ă care 
îi indică DSRC-VU  faptul că tranzacția s-a încheiat. 
Obiectivul comenzii RELEASE este de a încheia 
sesiunea cu  DSRC-VU . La primirea comenzii 
RELEASE,  DSRC-VU  trebuie s ă nu răspundă la nicio 
altă interogare în cadrul conexiunii curente. Trebuie luat 
act de faptul c ă, potrivit EN 12834, o DSRC-VU nu se va 
conecta de dou ă ori la acela și interogator, cu excep ția 
cazului în care s-a aflat în afara zonei de comunicare 
timp de 255 de secunde sau dac ă ID-ul  Beacon  (radio­
baliză) al interogatorului s-a modificat.  
5.4.3  Secven ța comenzilor de interogare  
DSC_36 Din perspectiva secven ței de comenzi și de răspunsuri, tran ­
zacția este descris ă după cum urmeaz ă: 
Secvență Expeditor  Destinatar  Descriere  Ac țiune 
1 REDCR  >  DSRC-VU  Inițializarea leg ăturii de 
comunicare Solicitare  REDCR transmite BST  
2 DSRC-VU  >  REDCR  Inițializarea leg ăturii de 
comunicare R ăspuns  Dacă BST este compatibil cu 
AID = 2, atunci DSRC-VU 
solicită o fereastr ă privată 
3 REDCR  >  DSRC-VU  Acordă o fereastră privată Transmite cadrul care con ține 
alocarea ferestrei private  
4 DSRC-VU  >  REDCR  Transmite VST  Transmite cadrul care con ține 
VST 
5 REDCR  >  DSRC-VU  Transmite  GET.request  
privind datele din 
atributul pentru un EID 
specific  
6 DSRC-VU  >  REDCR  Transmite GET.response 
cu atributul solicitat 
pentru EID-ul specific  Transmite atributul (RTMData, 
OWSData etc.) cu datele 
pentru EID-ul specific  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 508  
Secvență Expeditor  Destinatar  Descriere  Ac țiune 
▼M1 
7 REDCR  >  DSRC-VU  Transmite GET.request 
pentru date din alt 
atribut (dac ă este cazul)  
▼B 
8 DSRC-VU  >  REDCR  Transmite GET.response 
cu atributul solicitat  Transmite atributul cu datele 
pentru EID-ul specific  
9 REDCR  >  DSRC-VU  Confirm ă primirea cu 
succes a datelor  Transmite comanda RELEASE 
care încheie tranzac ția 
10 DSRC-VU  Încheie tranzac ția 
Un exemplu al secven ței de tranzac ție și al conținutului 
cadrelor comunicate este prezentat în sec țiunile 5.4.7 și 5.4.8.  
5.4.4  Structuri de date  
DSC_37 Structura semantic ă a datelor  atunci când sunt transmise prin 
interfața DSRC de 5,8 GHz DSRC trebuie s ă fie în 
concordanță cu cele descrise în prezentul apendice. Modul 
în care sunt structurate aceste date este specificat în cadrul 
prezentei sec țiuni. 
DSC_38 Datele utile (datele RTM) constau în concatenarea  
1. datelor  EncryptedTachographPayload , care reprezint ă 
varianta criptat ă a TachographPayload  definită la punctul 
ASN.1 din sec țiunea 5.4.5. Metoda de criptare este 
descrisă în apendicele 11;  
2. datelor  DSRCSecurityData , specificate în apendicele 11.  
DSC_39 Datele RTM sunt adresate ca atribut RTM =1 și transferate în 
containerul RTM =10.  
DSC_40 Marca contextual ă RTM ( RTM Context Mark ) trebuie să iden­
tifice partea de standard compatibil ă din seria de standarde 
TARV (RTM corespunde p ărții 9).  
Definiția din modulul ASN.1 pentru datele DSRC din cadrul 
aplicației RTM este dup ă cum urmeaz ă: ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 509
  
► (1) (2) (3) (4)  M1 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 510
  
5.4.5  Elementele RtmData, ac țiunile realizate și definiții 
DSC_41 Valorile de date care trebuie calculate de VU și utilizate 
pentru actualizarea datelor securizate din DSRC-VU se 
calculează în conformitate cu regulile definite în tabelul 14.3:  
Tabelul 14.3  
Elementele  RtmData , acțiunile realizate și definiții 
(1) Element 
RTM Data  (2) Acțiune realizat ă de VU  (3)  Definiția datelor din ASN.1  
RTM1 
Numărul de 
înmatriculare 
al vehiculului  VU seteaz ă valoarea elementului de date 
RTM1  tp15638VehicleRegistrationPlate  pe 
baza valorii înregistrate a tipului de date Vehi ­
cleRegistrationIdentification definit în apen ­
dicele 1  VehicleRegistrationIdentification  Numărul de 
înmatriculare al 
vehiculului 
exprimat ca șir de 
caractere
  
RTM2 
Eveniment de 
depășire a 
limitei de 
viteză VU genereaz ă o valoare boolean ă pentru 
elementul de date RTM2  tp15638Speedin ­
gEvent . 
Valoarea  tp15638SpeedingEvent  se calculeaz ă 
de VU pe baza num ărului evenimentelor de 
depășire a limitei de vitez ă (Over Speeding 
Events ) înregistrate în VU în ultimele 10 zile 
de producere a unui eveniment, conform 
definiției din anexa 1C.  1 (TRUE) – 
Indică nereguli 
de viteză în 
ultimele 10 zile 
de producere a 
unui eveniment
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 511  
(1) Element 
RTM Data  (2) Acțiune realizat ă de VU  (3)  Definiția datelor din ASN.1  
Dacă în ultimele 10 zile de producere a unui 
eveniment a survenit cel pu țin un  tp15638Spee ­
dingEvent , valoarea  tp15638SpeedingEvent  se 
setează la TRUE. 
Altfel (ELSE), dac ă în ultimele 10 zile de 
producere a unui eveniment nu s-a produs 
niciun eveniment,  tp15638SpeedingEvent  se 
setează la FALSE.  
RTM3 
Conducere 
fără un card 
valabil  VU genereaz ă o valoare boolean ă pentru 
elementul de date RTM3  tp15638DrivingWit ­
houtValidCard . 
VU atribuie o valoare de „True” variabilei  
tp15638DrivingWithoutValidCard  dacă datele 
VU au înregistrat, în ultimele 10 zile de 
producere a unui eveniment, cel pu țin un 
eveniment de tipul „Conducere f ără un card 
adecvat”, conform defini ției din anexa 1C. 
Altfel (ELSE), dac ă nu există evenimente în 
ultimele 10 zile de producere a unui 
eveniment, variabila  tp15638DrivingWithout ­
ValidCard  se setează la FALSE.  1 (TRUE) = 
Indică utilizarea 
unui card care nu 
este valabil
  
RTM4 
Card de 
conducător 
auto valabil  VU genereaz ă o valoare boolean ă pentru 
elementul de date RTM4  
tp15638DriverCard , pe baza datelor stocate în 
VU și definite în apendicele 1. 
Dacă nu este prezent niciun card de conduc ător 
auto valabil, VU seteaz ă variabila la TRUE 
Altfel (ELSE), dac ă este prezent un card de 
conducător auto valabil, VU seteaz ă variabila 
la FALSE  0 (FALSE) = 
Indică un card de 
conducător auto 
valabil
  
RTM5 
Introducerea 
cardului în 
timpul 
conducerii  VU genereaz ă o valoare boolean ă pentru 
elementul de date RTM5. 
VU atribuie o valoare de TRUE variabilei  
tp15638CardInsertion  dacă datele VU au înre ­
gistrat, în ultimele 10 zile de producere a unui 
eveniment, cel pu țin un eveniment de tipul 
„Introducerea cardului în timpul conducerii”, 
conform defini ției din anexa 1C. 
Altfel (ELSE), dac ă nu exist ă astfel de 
evenimente în ultimele 10 zile de producere a 
unui eveniment, variabila  tp15638CardIn ­
sertion  se setează la FALSE.  1 (TRUE) = 
indică intro­
ducerea cardului 
în timpul 
conducerii în 
ultimele 10 zile 
de producere a 
unui eveniment
  
RTM6 
Eroare 
privind datele 
de la senzorul 
de mișcare VU genereaz ă o valoare boolean ă pentru 
elementul de date RTM6 
VU atribuie o valoare de TRUE variabilei  
tp15638MotionDataError  dacă datele VU au 
înregistrat, în ultimele 10 zile de producere a 
unui eveniment, cel pu țin un eveniment de 
tipul „Eroare privind datele de la senzorul de 
mișcare”, conform defini ției din anexa 1C. 
Altfel (ELSE), dac ă nu exist ă astfel de 
evenimente în ultimele 10 zile de producere a 
unui eveniment, variabila  tp15638MotionDa ­
taError  se setează la FALSE.  1 (TRUE) = 
Indică o eroare 
privind datele de 
la senzorul de 
mișcare în 
ultimele 10 zile 
de producere a 
unui eveniment
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 512  
(1) Element 
RTM Data  (2) Acțiune realizat ă de VU  (3)  Definiția datelor din ASN.1  
RTM7 
Conflict 
privind 
deplasarea 
vehiculului  VU genereaz ă o valoare boolean ă pentru 
elementul de date RTM7 
VU atribuie o valoare de TRUE variabilei  
tp15638vehicleMotionConflict  dacă datele VU 
au înregistrat în ultimele 10 zile cel pu țin un 
eveniment de tipul „Conflict privind deplasarea 
vehiculului” (valoare ‘0A’H). 
Altfel (ELSE), dac ă nu există evenimente în 
ultimele 10 zile de producere a unui 
eveniment, variabila  tp15638vehicleMotion ­
Conflict  se setează la FALSE.  1 (TRUE) = 
Indică un conflict 
privind 
deplasarea în 
ultimele 10 zile 
de producere a 
unui eveniment
  
RTM8 
Al doilea 
card de 
conducător 
auto  VU genereaz ă o valoare boolean ă pentru 
elementul de date RTM8 pe baza anexei 1C 
(„activitatea conduc ătorului auto” CREW și 
CO-DRIVER). 
Dacă este prezent un al doilea card de 
conducător auto valabil, VU seteaz ă variabila 
la TRUE 
Altfel (ELSE), dac ă nu este prezent un al 
doilea card de conduc ător auto valabil, VU 
setează variabila la FALSE  1 (TRUE) = 
Indică existența 
unui al doilea 
card de 
conducător auto 
introdus
  
RTM9 
Activitate 
curentă VU genereaz ă o valoare boolean ă pentru 
elementul de date RTM9 
Dacă activitatea curent ă este înregistrat ă în VU 
ca orice alt ă activitate în afar ă de „CON ­
DUCERE”, conform defini ției din anexa 1C, 
VU seteaz ă variabila la TRUE 
Altfel (ELSE), dac ă activitatea curent ă este 
înregistrată în VU drept „CONDUCERE”, 
VU seteaz ă variabila la FALSE  1 (TRUE) = alt ă 
activitate 
selectată; 
0 (FALSE) = 
„conducere” 
selectată
 
RTM10 
Ultima 
sesiune 
încheiată VU genereaz ă o valoare boolean ă pentru 
elementul de date RTM10. 
Dacă ultima sesiune de utilizare a cardului nu a 
fost încheiat ă corect, conform defini ției din 
anexa 1C, VU seteaz ă variabila la TRUE. 
Altfel (ELSE), dac ă ultima sesiune de utilizare 
a cardului a fost încheiat ă corect, VU seteaz ă 
variabila la FALSE.  1 (TRUE) = 
încheiată incorect 
0 (FALSE) = 
încheiată corect
  
RTM11 
Întreruperea 
alimentării cu 
energie elec ­
trică VU genereaz ă o valoare de num ăr întreg pentru 
elementul de date RTM11. 
VU atribuie pentru variabila  tp15638Power ­
SupplyInterruption  o valoare egal ă cu cea mai 
lungă întrerupere a aliment ării cu energie elec ­
trică, conform articolului 9 din Regulamentul 
(UE) nr. 165/2014, de tip „Întreruperea 
alimentării cu energie electric ă”, conform 
definiției din anexa 1C.  — Numărul 
întreruperilor 
de alimentare 
cu energie 
electrică în 
ultimele 10 
zile de 
producere a 
unui 
eveniment
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 513  
(1) Element 
RTM Data  (2) Acțiune realizat ă de VU  (3)  Definiția datelor din ASN.1  
Altfel (ELSE), dac ă în ultimele 10 zile de 
producere a unui eveniment nu au survenit 
evenimente de întrerupere a aliment ării cu 
energie electric ă, valoarea num ărului întreg se 
setează la 0.  
▼M1 
RTM12 
Anomalie a 
senzorului  VU genereaz ă o valoare de num ăr întreg pentru 
elementul de date RTM12. 
VU atribuie variabilei sensorFault o valoare de: 
— 1 dacă un eveniment de tipul „anomalie a 
senzorului ‘35H’” a fost înregistrat în 
ultimele 10 zile, 
— 2 dacă un eveniment de tipul „anomalie a 
receptorului GNSS” (fie intern, fie extern, 
cu valorile de enumerare ‘36’H sau ‘37’ H) 
a fost înregistrat în ultimele 10 zile. 
— 3 dacă un eveniment de tipul ‘0E’H Eroare 
de comunicare cu echipamentul GNSS 
extern a fost înregistrat în ultimele 10 zile 
— 4 dacă atât o anomalie a senzorului, cât și 
o anomalie a receptorului GNSS au fost 
înregistrate în ultimele 10 zile 
— 5 dacă atât o anomalie a senzorului, cât și 
un eveniment de tip eroare de comunicare 
cu echipamentul GNSS extern au fost înre ­
gistrate în ultimele 10 zile 
— 6 dac ă atât o anomalie a receptorului 
GNSS, cât și un eveniment de tip eroare 
de comunicare cu echipamentul GNSS 
extern au fost înregistrate în ultimele 10 
zile 
— 7 dacă toate cele trei anomalii de senzor au 
fost înregistrate în ultimele 10 zile 
ALTFEL atribuie o valoare de 0 dac ă nu 
s-a înregistrat niciun eveniment în ultimele 
10 zile  - anomalie senzor 
un octet 
conform 
dicționarului de 
date
 
▼B 
RTM13 
Reglarea orei  VU genereaz ă o valoare de num ăr întreg 
(timeReal  din apendicele 1) pentru elementul 
de date RTM13 pe baza prezen ței datelor 
privind reglarea orei, conform defini ției din 
anexa 1C. 
VU atribuie valoarea orei la care s-a produs 
ultimul eveniment de date privind reglarea orei. 
Altfel (ELSE), dac ă în datele VU nu este 
prezent niciun eveniment de tip „reglarea 
orei”, conform defini ției din anexa 1C, VU 
setează o valoare de 0  Ora ultimei 
reglări a orei
  
RTM14 
Tentativă de 
încălcare a 
securității VU genereaz ă o valoare de num ăr întreg 
(timeReal  din apendicele 1) pentru elementul 
de date RTM14 pe baza prezen ței unei 
tentative de înc ălcare a securit ății, conform 
definiției din anexa 1C.  Ora ultimei 
tentative de 
încălcare 
— Valoare 
implicită 
=0x00FF
  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 514  
(1) Element 
RTM Data  (2) Acțiune realizat ă de VU  (3)  Definiția datelor din ASN.1  
VU seteaz ă valoarea orei la care a fost înre ­
gistrată de către VU ultima tentativ ă de 
încălcare a securit ății. 
Altfel (ELSE), dac ă în datele VU nu este 
prezent niciun eveniment de tip „tentativ ă de 
încălcare a securit ății”, conform defini ției din 
anexa 1C, VU seteaz ă o valoare de 0x00FF.  
RTM15 
Ultima 
etalonare  VU genereaz ă o valoare de num ăr întreg 
(timeReal  din apendicele 1) pentru elementul 
de date RTM15 pe baza prezen ței datelor 
privind ultima etalonare, conform defini ției 
din anexa 1C. 
VU seteaz ă valoarea orei la care au avut loc 
ultimele dou ă etalonări (RTM15 și RTM16), 
care sunt stabilite în  VuCalibrationData  
definite în apendicele 1. 
VU seteaz ă valoarea pentru RTM 15 la ora 
reală (timeReal ) a ultimei înregistr ări de etalo ­
nare.  Ora ultimelor 
date de etalonare
  
RTM16 
Etalonare 
anterioar ă VU genereaz ă o valoare de num ăr întreg 
(timeReal  din apendicele 1) pentru elementul 
de date RTM16 al înregistr ării de etalonare 
care o preced ă pe cea a ultimei etalon ări 
Altfel (ELSE), dac ă nu a existat nicio etalonare 
anterioară, VU seteaz ă valoarea RTM16 la 0.  Ora datelor 
privind 
etalonarea ante ­
rioară
 
RTM17 
Data 
conectării 
tahografului  Pentru elementul de date RTM17, VU 
generează o valoare de num ăr întreg 
(timeReal  din apendicele 1). 
VU setează valoarea orei la care a fost instalat ă 
inițial VU. 
VU extrage aceste date din  VuCalibrationData  
(apendicele1) din  vuCalibrationRecords , Cali­
brationPurpose  fiind egal cu: ‘03’H  Data conect ării 
tahografului
  
RTM18 
Viteza 
curentă VU genereaz ă o valoare de num ăr întreg pentru 
elementul de date RTM18. 
VU seteaz ă valoarea pentru RTM16 la ultima 
viteză curentă înregistrat ă în momentul celei 
mai recente actualiz ări a RtmData . Ultima vitez ă 
curentă înregis­
trată
 
RTM19 
Marcă 
temporal ă 
(Timestamp ) Pentru elementul de date RTM19, VU 
generează o valoare de num ăr întreg 
(timeReal  din apendicele 1). 
VU seteaz ă valoarea pentru RTM19 la ora 
ultimei actualiz ări a RtmData . Marca temporal ă 
a înregistrării 
Tachograp ­
hPayload  curente
  
5.4.6  Mecanismul de transfer al datelor  
DSC_42 Datele utile definite anterior sunt solicitate de REDCR dup ă 
etapa de ini țializare și transmise în consecin ță de către DSRC- 
VU în fereastra alocat ă. Comanda GET este utilizat ă de 
REDCR pentru a ob ține date.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 515  
DSC_43 Pentru toate schimburile DSRC, datele trebuie s ă fie codate 
folosind PER (Packed Encoding Rules) UNALIGNED, cu 
excepția
 și
 , care 
trebuie să fie codate folosind OER (Octet Encoding Rules) 
definite în ISO/IEC 8825-7, Rec. ITU-T X.696.  
▼B 
5.4.7  Descriere detaliat ă a tranzac ției DSRC  
DSC_44 Ini țializarea se realizeaz ă în conformitate cu DSC_44 – 
DSC_48 și cu tabelele 14.4 – 14.9. În etapa de ini țializare, 
REDCR începe s ă transmită un cadru care con ține un BST 
(tabel de serviciu al radiobalizei) în conformitate cu EN 
12834 și cu EN 13372, 6.2, 6.3, 6.4 și 7.1, cu set ările speci­
ficate în urm ătorul tabel 14.4.  
Tabelul 14.4  
Inițializare – set ări cadru BST  
Câmp  Set ări 
Link Identifier  Adresa de transmisie  
BeaconId  Conform EN 12834  
Time  Conform EN 12834  
Profile  Nicio extensie, a se folosi 0 
sau 1  
MandApplications  Nicio extensie, EID nu este 
prezent, parametrul nu este 
prezent, AID= 2 
Freight&Fleet  
NonMandApplications  Nu este prezent  
ProfileList  Nicio extensie, num ărul de 
profiluri din list ă = 0  
Fragmentation header  Nicio fragmentare  
Layer 2 settings  PDU de comand ă, comandă 
UI 
Un exemplu practic al set ărilor specificate în tabelul 14.4, cu 
indicarea cod ării biților, este dat în urm ătorul tabel 14.5.  
Tabelul 14.5  
Inițializare – exemplu de con ținut cadru BST
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
1 FLAG
  Indicator de început  
2 Broadcast ID
  Adresa de transmisie  
3 MAC Control Field
  PDU de comand ă 
4 LLC Control field
  Comand ă UI ▼M1
 02016R0799 — RO — 26.02.2020 — 002.001 — 516
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
5 Fragmentation header
  Nicio fragmentare  
6 BST
  Solicitare de ini țializare  
SEQUENCE {  
OPTION indicator 
BeaconID SEQUENCE { 
ManufacturerId INTEGER (0..65535)
  Aplicațiile neobligatorii 
(NonMand ) nu sunt 
prezente
  
Identificator produc ător 
7
 
8
 
IndividualID INTEGER (0..134217727) 
}
 ID de 27 de bi ți disponibil 
pentru produc ător 
9
 
10
 
11
 
12 Time INTEGER (0..4294967295)
  Timp real UNIX de 32 de 
biți 
13
 
14
 
15
 
16 Profile INTEGER (0..127,…)
  Nicio extensie. Profil de 
exemplu 0  
17 MandApplications SEQUENCE 
(SIZE(0..12 ­
7,…)) OF {
  Nicio extensie, num ărul 
aplicațiilor obligatorii 
(mandApplications ) = 1  
18 SEQUENCE {  
OPTION indicator
  EID nu este prezent  
OPTION indicator
  Parametrul nu este prezent  
AID DSRCApplicationEntityID } }
  Nicio extensie. AID= 2 
Freight&Fleet  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 517
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
19 ProfileList SEQUENCE (0..127,…) OF 
Profile }
  Nicio extensie, num ărul de 
profiluri din list ă = 0 
20 FCS
  Secven ță de verificare a 
cadrului  
21
 
22 Flag
  Indicator de final  
DSC_45 Atunci când prime ște un BST, o  DSRC-VU  solicită alocarea 
unei ferestre private, conform specifica țiilor din EN 12795 și 
EN 13372, 7.1.1, f ără nicio setare RTM specific ă. Tabelul 
14.6 oferă un exemplu de codare a bi ților. 
Tabelul 14.6  
Inițializare – Con ținutul cadrului de solicitare de alocare a unei ferestre private
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
1 FLAG
  Indicator de început  
2 Private LID
  Adresa de leg ătură a 
DSRC-VU specifice  
3
 
4
 
5
 
6 MAC Control field
  Solicitare de fereastr ă 
privată 
7 FCS
  Secven ță de verificare a 
cadrului  
8
 
9 Flag
  Indicator de final  
DSC_45 REDCR r ăspunde apoi prin alocarea unei ferestre private, 
conform specifica țiilor din EN 12795 și EN 13372, 7.1.1, 
fără nicio setare RTM specific ă. 
Tabelul 14.7 ofer ă un exemplu de codare a bi ților. 
Tabelul 14.7  
Inițializare – Con ținutul cadrului de alocare a unei ferestre private
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
1 FLAG
  Indicator de început  
2 Private LID
  Adresa de leg ătură a 
DSRC-VU specifice  
3
 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 518
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
4
 
5
 
6 MAC Control field
  Alocarea ferestrei private  
7 FCS
  Secven ță de verificare a 
cadrului  
8
 
9 Flag
  Indicator de final  
DSC_47 Atunci când prime ște alocarea ferestrei private,  DSRC-VU  
transmite VST-ul s ău (tabelul de serviciu al vehiculului), 
conform defini ției din EN 12834 și din EN 13372, 6.2, 6.3, 
6.4 și 7.1, cu set ările specificate în tabelul 14.8, folosind 
fereastra de transmisie alocat ă. 
Tabelul 14.8  
Inițializare – set ări cadru VST  
Câmp  Set ări 
Private LID  Conform EN 12834  
VST parameters  Fill = 0, apoi pentru fiecare aplica ție 
compatibil ă: EID prezent, parametru 
prezent, AID = 2, EID generat de 
OBU  
Parameter  Nicio extensie, con ține marca 
contextuală RTM  
ObeConfiguration  Câmpul op țional  ObeStatus  poate fi 
prezent, dar nu trebuie folosit de 
REDCR  
Fragmentation header  Nicio fragmentare  
Layer 2 settings  PDU de comand ă, comandă UI 
DSC_48  DSRC-VU  trebuie să fie compatibil ă cu aplicația „Freight and 
Fleet”, identificat ă prin identificatorul de aplica ție „2”. Și alți 
identificatori de aplica ție pot fi compatibili, dar nu trebuie s ă 
fie prezen ți în acest VST, deoarece BST necesit ă numai 
AID=2. Câmpul „Applications” con ține o listă a instanțelor 
de aplica ții compatibile din  DSRC-VU . Pentru fiecare 
instanțiere de aplica ție compatibil ă este dată o trimitere la 
standardul corespunz ător, format ă dintr-o marc ă contextual ă 
Rtm, care este compus ă dintr-un OBJECT IDENTIFIER 
reprezentând standardul aferent, partea acestuia (9 pentru 
RTM) și posibil versiunea sa, plus un EID care este generat 
de DSRC-VU și asociat instan țierii de aplica ție respective.  
Un exemplu practic al set ărilor specificate în tabelul 14.8, cu 
indicarea cod ării biților, este dat în tabelul 14.9.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 519  
Tabelul 14.9  
Inițializare – exemplu de con ținut cadru VST
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
1 FLAG
  Indicator de început  
2 Private LID
  Adresa de leg ătură a 
DSRC-VU specifice  
3
 
4
 
5
 
6 MAC Control field
  PDU de comand ă 
7 LLC Control field
  Comand ă UI 
8 Fragmentation header
  Nicio fragmentare  
9 VST 
SEQUENCE {
  Răspuns la ini țializare  
Fill BIT STRING (SIZE(4))
  Neutilizat și setat la 0  
10 Profile INTEGER (0..127,...) 
Applications SEQUENCE OF {
  Nicio extensie. Profil de 
exemplu 0  
11
 Nicio extensie, 1 aplica ție 
12 SEQUENCE {  
OPTION indicator
  EID prezent  
OPTION indicator
  Parametru prezent  
AID DSRCApplicationEntityID
  Nicio extensie. AID = 2 
Freight&Fleet  
13 EID Dsrc-EID
  Definit în cadrul OBU și 
identificând instan ța de 
aplicație 
14 Parameter Container {
  Nicio extensie, op țiune 
container = 02, șir de 
octeți 
15
 Nicio extensie, lungimea 
mărcii contextuale Rtm = 8  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 520
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
16 Rtm-ContextMark::= SEQUENCE 
{ 
StandardIdentifier 
standardIdentifier
  ►M1 Identificator de 
obiect al standardului 
compatibil, cu partea si 
versiunea sa. Exemplu: 
ISO (1) Standard (0) 
TARV (15638) part9 (9) 
Version1 (1). 
Primul octet este 06H, 
care reprezint ă identifi­
catorul de obiect. Al 
doilea octet este 06H, 
care reprezint ă lungimea 
acestuia. Urm ătorii 6 
octeți codează identifi­
catorul de obiect dat ca 
exemplu. ◄ 17
 
18
 
19
 
20
 
21
 
22
 
23
 
24 ObeConfiguration Sequence {  
OPTION indicator
  ObeStatus nu este prezent  
EquipmentClass INTEGER (0..32767)
  
25
 
26 ManufacturerId INTEGER (0..65535)
  Identificator al produc ă­
torului pentru DSRC-VU, 
conform descrierii din 
registrul ISO 14816  27
 
28 FCS
  Secven ță de verificare a 
cadrului  
29
 
30 Flag
  Indicator de final  
DCS_49 REDCR cite ște apoi datele prin emiterea unei comenzi GET, 
conformă cu comanda GET definit ă în EN 13372, 6.2, 6.3, 
6.4 și în EN 12834, cu set ările specificate în tabelul 14.10.  
Tabelul 14.10  
Prezentare – set ări cadru  GET.request  
Câmp  Set ări 
Invoker Identifier (IID)  Nu este prezent  
Link Identifier (LID)  Adresa de leg ătură a DSRC-VU 
specifice  
Chaining  Nu  
Element Identifier (EID)  Astfel cum este specificat în VST. 
Nicio extensie  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 521  
Câmp  Set ări 
Access Credentials  Nu  
AttributeIdList  Nicio extensie, 1 atribut, AttributeID 
= 1 (RtmData)  
Fragmentation  Nu  
Layer2 settings  PDU de comand ă, comandă ACn cu 
interogare prealabil ă 
Tabelul 14.11 prezint ă un exemplu de citire a datelor RTM  
Tabelul 14.11  
Prezentare – exemplu de cadru GET.request
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
1 FLAG
  Indicator de început  
2 Private LID
  Adresa de leg ătură a 
DSRC-VU specifice  
3
 
4
 
5
 
6 MAC Control field
  PDU de comand ă 
7 LLC Control field
  Comand ă ACn cu inte ­
rogare prealabil ă, bit n  
8 Fragmentation header
  Nicio fragmentare  
9 Get.request 
SEQUENCE {
  Solicitare de ob ținere a 
datelor  
OPTION indicator
  Acreditările de acces 
(Access Credentials) nu 
sunt prezente  
OPTION indicator
  IID nu este prezent  
OPTION indicator
  AttributeIdList prezent ă 
Fill BIT STRING(SIZE(1))
  Setată la 0.  
10 EID INTEGER(0..127,…)
  EID al instan ței de 
aplicație RTM, astfel 
cum este specificat în 
VST. Nicio extensie  
11 AttributeIdList SEQUENCE OF { 
AttributeId }}
  Nicio extensie, num ărul 
de atribute = 1  
12
 AttributeId =1, RtmData . 
Nicio extensie  
13 FCS
  Secven ță de verificare a 
cadrului  
14
 
15 Flag
  Indicator de final  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 522  
DCS_50 Când prime ște solicitarea GET ( GET.request ), DSRC-VU  
transmite un r ăspuns GET ( GET.response ) cu datele solicitate, 
conform cu r ăspunsul GET definit în EN 13372, 6.2, 6.3, 6.4 
și în EN 12834, cu set ările specificate în tabelul 14.12.  
Tabelul 14.12  
Prezentare – set ări cadru GET.response  
Câmp  Set ări 
Invoker Identifier (IID)  Nu este prezent  
Link Identifier (LID)  Conform EN 12834  
Chaining  Nu  
Element Identifier (EID)  Astfel cum este specificat în 
VST.  
Access Credentials  Nu  
Fragmentation  Nu  
Layer2 settings  PDU de r ăspuns, răspuns 
disponibil și comand ă 
acceptată, comandă ACn  
Tabelul 14.13 prezint ă un exemplu de citire a datelor RTM  
Tabelul 14.13  
Prezentare – exemplu de con ținut cadru r ăspuns
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
1 FLAG
  Indicator de început  
2 Private LID
  Adresa de leg ătură a 
DSRC-VU specifice  
3
 
4
 
5
 
6 MAC Control field
  PDU de r ăspuns  
7 LLC Control field
  R ăspuns disponibil, 
comandă ACn bit n  
8 LLC Status field
  R ăspuns disponibil și 
comandă acceptată 
9 Fragmentation header
  Nicio fragmentare  
10 Get.response 
SEQUENCE {
  Obținere răspuns  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 523
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
OPTION indicator
  IID nu este prezent  
OPTION indicator
  Lista atributelor (Attribute 
List) prezent ă 
OPTION indicator
  Starea de retur nu este 
prezentă 
Fill BIT STRING(SIZE(1))
  Neutilizat  
11 EID INTEGER(0..127,…)
  R ăspuns din partea 
instanței de aplica ție 
RTM. Nicio extensie,  
12 AttributeList SEQUENCE OF {
  Nicio extensie, num ărul 
de atribute = 1  
13 Attributes SEQUENCE { 
AttributeId
  Nicio extensie, Attri ­
buteID = 1 (RtmData)  
14 AttributeValue CONTAINER {
  Nicio extensie, op țiune 
container = 10  10 . 
15
 RtmData  
16
 
17
 
… …  
n }}}}
  
n+1 FCS
  Secven ță de verificare a 
cadrului  
n+2
 
n+3 Flag
  Indicator de final  
DSC_51 Apoi REDCR închide conexiunea prin emiterea unei comenzi 
EVENT_REPORT, RELEASE conforme cu EN 13372, 6.2, 
6.3, 6.4 și cu EN 12834, 7.3.8, f ără nicio setare RTM 
specifică. Tabelul 14.14 arat ă un exemplu de codare a 
biților pentru comanda RELEASE.  
Tabelul 14.14  
Încheiere. Con ținut cadru EVENT_REPORT RELEASE
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
1 FLAG
  Indicator de început  
2 Private LID
  Adresa de leg ătură a 
DSRC-VU specifice  
3
 
4
 ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 524
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
5
 
6 MAC Control field
  Cadrul con ține o LPDU 
de comand ă 
7 LLC Control field
  Comand ă UI 
8 Fragmentation header
  Nicio fragmentare  
9 EVENT_REPORT.request 
SEQUENCE {
  EVENT_REPORT 
(Release)  
OPTION indicator
  Acreditările de acces 
(Access Credentials) nu 
sunt prezente  
OPTION indicator
  Parametrul de eveniment 
nu este prezent  
OPTION indicator
  IID nu este prezent  
Mode BOOLEAN
  Nu se a șteaptă niciun 
răspuns  
10 EID INTEGER (0..127,…)
  Nicio extensie, EID = 0 
(sistem)  
11 EventType INTEGER (0..127,…) }
  Tip de eveniment 0 = 
Release  
12 FCS
  Secven ță de verificare a 
cadrului  
13
 
14 Flag
  Indicator de final  
DSC_52 Nu se a șteaptă ca DSRC-VU  să răspundă la comanda  Release . 
Comunicarea este apoi închis ă. 
5.4.8  Descrierea tranzac ției de testare DRSC  
DSC_53 Testele complete, care includ securizarea datelor, trebuie 
realizate conform defini ției din apendicele 11 (Mecanisme 
de securitate comune), de c ătre persoane autorizate care au 
acces la procedurile de securitate, folosind comanda GET 
normală definită mai sus.  
DSC_54 Testele de opera ționalitate și de inspec ție (verificare) 
periodică ce necesit ă decriptarea și înțelegerea con ținutului 
de date decriptat trebuie realizate conform specifica țiilor din 
apendicele 11 (Mecanisme de securitate comune) și din apen­
dicele 9 (Omologarea de tip – lista testelor minime obliga ­
torii).  
Cu toate acestea, comunicarea DSRC de baz ă poată fi testată 
prin comanda ECHO. Aceste teste pot fi necesare la veri ­
ficarea opera ționalității, cu ocazia inspec ției periodice sau la 
cererea autorit ății de control competente sau dac ă sunt impuse 
de Regulamentul (UE) nr. 165/2014 (a se vedea sec țiunea 6 
de mai jos)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 525  
DSC_55 Pentru a realiza aceast ă testare a comunic ării de baz ă, 
comanda ECHO este emis ă de REDCR în cursul unei 
sesiuni, și anume dup ă finalizarea cu succes a unei etape de 
inițializare. Astfel, secven ța de interac țiuni este similar ă celei 
a unei interog ări: 
— Etapa 1  REDCR  transmite un „tabel de serviciu al radio ­
balizei” (BST) care include identificatorii de aplica ție 
(AID) din lista de serviciu cu care este compatibil. În 
aplicațiile RTM, acesta va fi pur și simplu serviciul cu 
valoarea AID = 2.  
DSRC-VU  evaluează BST-ul primit și, în cazul în care 
identifică faptul că BST solicit ă Freight&Fleet  (AID = 2),  
DSRC-VU  răspunde. Dac ă REDCR  nu oferă AID=2,  
DSRC-VU  închide tranzac ția sa cu  REDCR . 
— Etapa 2  DSRC-VU  transmite o cerere de alocare a unei 
ferestre private.  
— Etapa 3 REDCR transmite o alocare de fereastr ă privată. 
— Etapa 4  DSRC-VU  utilizează fereastra privat ă alocată 
pentru a transmite tabelul s ău de serviciu al vehiculului 
(VST). Acest VST include o list ă a tuturor instan țierilor 
diferite de aplica ții cu care  DSRC-VU  respectiv ă este 
compatibil ă în cadrul AID=2. Diferitele instan țieri 
trebuie identificate prin intermediul unor EID-uri unice, 
fiecare asociat cu o valoare de parametru indicând 
instanțierea de aplica ție compatibil ă. 
— Etapa 5 Apoi,  REDCR  analizează VST prezentat și fie 
întrerupe conexiunea (RELEASE) dac ă nu este interesat 
de nimic din ceea ce VST are de oferit (adic ă primește un 
VST de la o  DSRC-VU  care nu este o RTM VU), fie, 
dacă primește un VST corespunz ător, porne ște o 
instanțiere de aplica ție. 
— Etapa 6  REDCR  emite o comand ă (ECHO) c ătre DSRC- 
VU specifică și alocă o fereastr ă privată. 
— Etapa 7  DSRC-VU  utilizează fereastra privat ă nou alocat ă 
pentru a transmite un cadru de r ăspuns ECHO.  
Tabelele de mai jos ofer ă un exemplu practic de sesiune de comunicare 
ECHO.  
DSC_56 Ini țializarea se realizeaz ă în conformitate cu sec țiunea 5.4.7 
(DSC_44-DSC_48) și cu tabelele 14.4-14.9.  
DSC_57 REDCR emite apoi o comand ă ACTION, ECHO conform ă cu 
ISO 14906, care con ține 100 de octe ți de date și nicio setare 
specifică pentru RTM. Tabelul 14.15 prezint ă conținutul 
cadrului transmis de REDCR.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 526  
Tabelul 14.15  
Exemplu de cadru de solicitare ACTION, ECHO
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
1 FLAG
  Indicator de început  
2 Private LID
  Adresa de leg ătură a 
DSRC-VU specifice  
3
 
4
 
5
 
6 MAC Control field
  PDU de comand ă 
7 LLC Control field
  Comand ă ACn cu inte ­
rogare prealabil ă, bit n  
8 Fragmentation header
  Nicio fragmentare  
9 ACTION.request 
SEQUENCE {
  Solicitare de ac țiune 
(ECHO)  
OPTION indicator
  Acredit ările de acces 
(Access Credentials) nu 
sunt prezente  
OPTION indicator
  Parametru de ac țiune 
prezent  
OPTION indicator
  IID nu este prezent  
Mode BOOLEAN
  Răspuns așteptat  
10 EID INTEGER (0..127,…)
  Nicio extensie, EID = 0 
(sistem)  
11 ActionType INTEGER (0..127,…)
  Nicio extensie, solicitare 
ECHO de tip ac țiune 
12 ActionParameter CONTAINER {
  Nicio extensie, op țiune 
container = 2.  
13
 Nicio extensie. Lungimea 
șirului = 100 de octe ți 
14
 Datele care trebuie 
transmise (echoed)  
… …  
113 }}
  
114 FCS
  Secven ță de verificare a 
cadrului  
115
 
116 Flag
  Indicator de final  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 527  
DSC_58 Când prime ște solicitarea ECHO,  DSRC-VU  transmite un 
răspuns ECHO cu 100 de octe ți de date, prin reflectarea 
comenzii primite, conform ISO 14906, f ără nicio setare 
specifică pentru RTM. Tabelul 14.16 prezint ă un exemplu 
de codare la nivelul bi ților. 
Tabelul 14.16  
Exemplu de cadru de r ăspuns ACTION, ECHO
 Nr. octet 
Atribut/Câmp  Bi ți în octet  Descriere  
1 FLAG
  Indicator de început  
2 Private LID
  Adresa de leg ătură a VU 
specifice  
3
 
4
 
5
 
6 MAC Control field
  PDU de r ăspuns  
7 LLC Control field
  Comand ă ACn, bit n  
8 LLC status field
  R ăspuns disponibil  
9 Fragmentation header
  Nicio fragmentare  
10 ACTION.response 
SEQUENCE {
  răspuns ACTION (ECHO)  
OPTION indicator
  IID nu este prezent  
OPTION indicator
  Parametru de r ăspuns 
prezent  
OPTION indicator
  Starea de retur nu este 
prezentă 
Fill BIT STRING (SIZE (1))
  Neutilizat  
11 EID INTEGER (0..127,…)
  Nicio extensie, EID = 0 
(sistem)  
12 ResponseParameter CONTAINER {
  Nicio extensie, op țiune 
container = 2.  
13
 Nicio extensie. Lungimea 
șirului = 100 de octe ți 
14
 Date transmise (echoed)  
… …  
113 }}
  
114 FCS
  Secven ță de verificare a 
cadrului  
115
 
116 Flag
  Indicator de final  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 528  
__________  
▼B 
5.6 Transferul de date între DSRC-VU și VU  
5.6.1  Conexiunea fizic ă și interfețele 
DSC_66 Conexiunea dintre  VU și DSRC-VU  se poate realiza fie prin 
cablu fizic, fie prin comunicare f ără fir cu raz ă scurtă de 
acțiune bazat ă pe BLE Bluetooth v4.0.  
DSC_67 Indiferent de interfa ța și de conexiunea fizic ă selectate, trebuie 
satisfăcute următoarele cerin țe: 
DSC_68  ►M1 (a) Pentru ca diferi ți furnizori s ă poată fi contacta ți în 
scopul de a furniza VU și DSRC-VU, inclusiv 
loturi diferite de DSRC-VU, conexiunea dintre 
VU și DSRC-VU care nu este intern ă VU trebuie 
să fie o conexiune conform ă unui standard 
disponibil în mod public. VU trebuie s ă se 
conecteze la DSRC-VU fie ◄ 
i) folosind un cablu fix de cel pu țin 2 metri, cu 
un conector DIN 41612 H11 drept – un 
conector cu fi șă cu 11 pini aprobat de la 
DSRC-VU, care se potrive ște cu un conector 
de recepție DIN/ISO similar aprobat de la 
dispozitivul VU, fie  
ii) folosind Bluetooth de energie redus ă (BLE), 
fie 
iii) folosind o conexiune standard ISO 11898 sau 
SAE J1939  
DSC_69 (b) defini ția interfețelor și a conexiunii dintre VU și DSRC- 
VU trebuie s ă fie compatibil ă cu comenzile de protocol 
de aplicație definite în sec țiunea 5.6.2. și 
DSC_70 (c) VU și DSRC-VU trebuie s ă fie compatibile cu realizarea 
transferului de date prin conexiune în ceea ce prive ște 
performanța și alimentarea cu energie electric ă. 
5.6.2  Protocolul de aplica ție 
DSC_71 Protocolul de aplica ție dintre echipamentul de comunicare la 
distanță al VU și DSRC-VU este responsabil cu transferul 
periodic al datelor pentru comunicarea la distan ță de la VU 
către DSRC.  
DSC_72 Sunt identificate urm ătoarele comenzi principale:  
1. Inițializarea leg ăturii de comunicare – solicitare  
2. Inițializarea leg ăturii de comunicare – r ăspuns  
3. Transmiterea datelor cu identificatorul aplica ției RTM și 
datele utile definite de  RTM Data  
4. Confirmarea primirii datelor  
5. Încheierea leg ăturii de comunicare – solicitare  
6. Încheierea leg ăturii de comunicare – r ăspuns  
DSC_73 În ASN1.0, comenzile anterioare pot fi definite ca:  ▼M2
 02016R0799 — RO — 26.02.2020 — 002.001 — 529
  
DSC_74 Descrierea comenzilor și a parametrilor este urm ătoarea:  
—
 
este folosit ă pentru a ini țializa legătura de comunicare. 
Comanda este transmis ă de către VU la DSRC-VU.  LinkI­
dentifier  este setat de VU și comunicat DSRC-VU pentru 
a urmări o anumit ă legătură de comunicare.  
(Notă: aceasta are ca scop compatibilitatea cu leg ături 
viitoare și cu alte aplica ții/module, precum cânt ărirea la 
bord).  
—
 
este utilizat ă de DSRC-VU pentru a furniza r ăspunsul la 
solicitarea de ini țializare a leg ăturii de comunicare. 
Comanda este transmis ă de DSRC-VU c ătre VU. 
Comanda d ă rezultatul ini țializării ca răspuns = 1 
(reușită) sau =0 (e șec). 
DSC_75 Ini țializarea leg ăturii de comunicare trebuie f ăcută doar după 
instalarea, etalonarea și pornirea motorului/VU este pornit ă. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 530  
—
 este utilizat ă de VU pentru a transmite 
datele  RCDTData  (și anume  the remote communication 
Data , datele pentru comunicarea la distan ță) semnate 
către DSRC-VU. Datele vor fi transmise la fiecare 60 
de secunde. Parametrul  DataTransactionId  identific ă 
transmisiunea specific ă de date.  LinkIdentifier  este de 
asemenea folosit pentru a se asigura c ă legătura corespun ­
zătoare este corect ă. 
—
 este transmis ă de DSRC- 
VU ca  feedback  pentru VU în ceea ce prive ște primirea 
datelor dintr-o comand ă
 identificat ă de 
parametrul  DataTransactionId . Parametrul de r ăspuns este 
1 (reușită) sau =0 (e șec). Dacă o VU prime ște mai mult de 
trei răspunsuri egale cu 0 sau dac ă VU nu prime ște o 
RCDT Data Acknowledgment  pentru o anumit ă RCDT- 
Send Data  transmisă anterior cu un  DataTransactionId  
specific, VU va genera și înregistra un eveniment.  
—
 este 
transmisă de VU c ătre DSRC-VU pentru a încheia o 
legătură aferentă unui anumit  LinkIdentifier . 
DSC_76 La repornirea DSRC-VU sau a unei VU, toate leg ăturile de 
comunicare existente ar trebui eliminate, deoarece ar putea 
exista legături „rupte” r ămase în urma închiderii bru ște a 
unei VU.  
—
 este 
transmis de DSRC-VU c ătre VU pentru a confirma soli ­
citarea de încheiere a leg ăturii de către VU pentru  LinkI­
dentifier -ul specific.  
5.7 Gestionarea erorilor  
5.7.1  Înregistrarea și comunicarea datelor în DSRC-VU  
▼M1 
DSC_77  Datele  trebuie furnizate  DSRC-VU , deja securizate, de c ătre 
funcția VUSM. VUSM  trebuie să verifice că datele înregistrate 
în DSRC-VU  au fost înregistrate corect. Înregistrarea și 
raportarea oric ăror erori în transferul datelor de la  VU către 
memoria  DSRC-VU  trebuie înregistrate cu tipul Event ­
FaultType și valoarea de enumerare stabilit ă la ‘0C’H eveni ­
mentul „Eroare de comunicare cu echipamentul de comu ­
nicare la distan ță”, împreun ă cu marca temporal ă. 
▼B 
DSC_78  VU  păstrează un fișier identificat printr-un nume unic, care 
este ușor identificabil de c ătre inspectori, în scopul înregis ­
trării „eșecurilor de comunicare intern ă ale VU”.  
DSC_79 Dac ă VUPM încearc ă să obțină date VU de la modulul de 
securitate (pentru a le transmite c ătre VU-DSRC), dar 
nu reușește, ea trebuie s ă înregistreze e șecul respectiv cu 
tipul EventFaultType  și valoarea de enumerare stabilit ă la 
‘62’H  (anomalie a echipamentului de comunicare la distan ță), ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 531  
împreună cu marca temporal ă. Eșecul comunic ării este 
detectat atunci când, timp de trei ori consecutiv, nu se 
primește un mesaj
  Pentru
  
aferentă (și anume cu acela și DataTransac ­
tionId  în mesajele
  ).  
5.7.2  Erori de comunicare f ără fir 
DSC_80 Gestionarea erorilor de comunicare trebuie s ă fie în 
concordanță cu standardele DSRC aferente, și anume EN 
300 674-1, EN 12253, EN 12795, EN 12834 și parametrii 
corespunzători din EN 13372.  
5.7.2.1  Erori de criptare și de semn ătură 
DSC_81 Erorile de criptare și de semnătură trebuie gestionate conform 
definiției din apendicele 11 (Mecanisme de securitate 
comune) și nu sunt prezente în niciun mesaj de eroare 
asociat cu transferul DSRC de date.  
5.7.2.2  Înregistrarea erorilor  
Mediul DSRC este o comunicare f ără fir dinamic ă într-un mediu de 
condiții de interferen ță și atmosferice nesigure, în special în combina țiile 
„REDCR portabil” și „vehicul în mi șcare” implicate de aceast ă aplicație. 
Prin urmare, este necesar s ă se stabileasc ă diferența dintre o „eroare de 
citire” și o condi ție de „eroare”. În cadrul unei tranzac ții printr-o 
interfață fără fir, eșecul de citire este ceva obi șnuit și consecin ța este 
de obicei c ă trebuie reîncercat, și anume BST trebuie retransmis și 
secvența trebuie încercat ă din nou, ceea ce, în majoritatea circum ­
stanțelor, va duce la o conexiune de comunicare reu șită și la transferul 
cu succes al datelor, cu excep ția cazului în care vehiculul vizat iese din 
raza de acțiune în decursul perioadei necesare pentru retransmitere. (Este 
posibil ca o instan ță „reușită” a unei opera țiuni de „citire” s ă fi presupus 
mai multe încerc ări și reîncercări). 
Eșecul de citire se poate produce din cauz ă că antenele nu au fost 
asociate în mod corespunz ător (eșec de „țintire”); din cauz ă că una 
dintre antene este ecranat ă – în mod deliberat sau din cauza prezen ței 
fizice a altui vehicul, a interferen țelor radio, în special de la WIFI de 
circa 5,8 GHz sau de la alte comunica ții fără fir cu acces public, sau din 
cauza interferen țelor radar sau a condi țiilor atmosferice dificile (de 
exemplu în timpul unei furtuni) ori pur și simplu din cauza ie șirii din 
raza de acțiune a comunic ării DSRC. Instan țele individuale de e șecuri de 
citire, prin natura lor, nu pot fi înregistrate, pur și simplu deoarece 
comunicarea nu a avut loc.  
Cu toate acestea, dac ă agentul autorit ății de control competente vizeaz ă 
un vehicul și încearcă să interogheze  DSRC-VU  a acestuia, dar nu are 
loc niciun transfer de date reu șit, este posibil ca acest e șec să se fi 
produs din cauza unei manipul ări deliberate și, prin urmare, agentul 
autorității de control competente are nevoie de o modalitate de a înre ­
gistra eșecul și de a alerta colegii din aval c ă este posibil s ă existe o 
încălcare a normelor. Ace știa din urm ă pot apoi opri vehiculul și realiza 
o inspecție fizică. Însă dat fiind faptul c ă nu a avut loc nicio comunicare 
reușită, DSRC-VU nu poate furniza date privind e șecul. Prin urmare, 
astfel de raport ări depind de concep ția echipamentului REDCR.  
„Eșecul de citire” este diferit din punct de vedere tehnic de o „eroare”. 
În acest context, o „eroare” reprezint ă obținerea unei valori eronate.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 532  
Datele transferate c ătre DSRC-VU  sunt furnizate deja securizate, prin 
urmare trebuie verificate de c ătre furnizorul datelor (a se vedea 5.4).  
Datele transferate ulterior prin interfa ța aeriană sunt verificate prin veri ­
ficări redundante ciclice la nivelul comunica țiilor. Dacă CRC le vali ­
dează, atunci datele sunt corecte. Dac ă CRC nu le valideaz ă, datele sunt 
transmise din nou. Probabilitatea ca date incorecte s ă poată trece cu 
succes printr-o CRC este atât de sc ăzută din punct de vedere statistic 
încât poate s ă nu fie luat ă în considerare.  
Dacă CRC nu valideaz ă datele și nu este timp pentru retransmiterea și 
primirea datelor corecte, atunci rezultatul nu va fi o eroare, ci o 
instanțiere a unui tip specific de e șec de citire.  
Singurele date de „e șec” semnificative care pot fi înregistrate sunt cele 
privind num ărul inițierilor reușite de tranzac ții care au loc, dar care nu 
duc la un transfer reu șit al datelor c ătre REDCR.  
DSC_82 Prin urmare,  REDCR  înregistreaz ă, cu marc ă temporal ă, 
numărul ocaziilor în care etapa de „ini țializare” a unei inte ­
rogări DSRC a reu șit, însă tranzacția s-a încheiat înainte ca  
datele  să fie obținute cu succes de REDCR . Aceste date 
trebuie să fie disponibile pentru agentul autorit ății de 
control competente și trebuie stocate în memoria echipa ­
mentului REDCR. Mijloacele prin care se realizeaz ă acest 
lucru depind de concep ția produsului sau de specifica țiile 
unei autorit ăți de control competente.  
Singurele date de „eroare” semnificative care pot fi înre ­
gistrate sunt cele privind num ărul ocaziilor în care REDCR 
nu reușește să decripteze  datele  primite. Îns ă trebuie luat not ă 
de faptul c ă aceasta se va referi numai la eficien ța software- 
ului REDCR. Datele pot fi decriptate tehnic, dar nu au sens 
din punct de vedere semantic.  
DSC_83 Prin urmare,  REDCR  trebuie s ă înregistreze, cu marc ă 
temporală, numărul ocaziilor în care a încercat, f ără succes, 
să descifreze datele primite prin interfa ța DSRC.  
6 TESTELE DE OPERA ȚIONALITATE ȘI DE VERIFICARE 
PERIODIC Ă PENTRU FUNC ȚIA DE COMUNICARE LA 
DISTANȚĂ 
6.1 Generalit ăți 
DSC_84 Pentru func ția de comunicare la distan ță sunt prevăzute două 
tipuri de teste:  
1. Un test ECHO pentru a valida canalul de comunicare f ără 
fir DSRC-REDCR  >>-:-< DSRC-VU . 
2. Un test de securitate „end-to-end” (de la un cap ăt la altul) 
pentru a se asigura faptul c ă un card de atelier este capabil 
să acceseze con ținutul de date criptate și semnate creat de 
VU și transmis prin canalul de comunicare f ără fir. 
6.2 ECHO  
Prezenta clauz ă conține dispozi țiile specifice pentru a testa numai dac ă 
DSRC-REDCR  >>-:-< DSRC-VU  este activ din punct de vedere 
funcțional.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 533  
Obiectivul comenzii ECHO este de a permite atelierelor sau unit ăților de 
testare pentru omologarea de tip s ă verifice dac ă legătura DSRC 
funcționează fără a avea nevoie de acces la elementele de securitate. 
Prin urmare, echipamentele de testare trebuie doar s ă poată inițializa o 
comunicare DSRC (transmi țând un BST cu AID=2) și să poată apoi 
trimite comanda ECHO și, presupunând c ă DSRC func ționează, vor 
primi răspunsul ECHO. A se vedea sec țiunea 5.4.8 pentru detalii. Presu ­
punând că primește acest răspuns în mod corect, leg ătura DSRC ( DSRC- 
REDCR  >>-:-< DSRC-VU ) poate fi validat ă ca funcționând corect.  
6.3 Testele de validare a con ținutului de date securizate  
DSC_85 Acest test este realizat pentru a valida fluxul de securitate 
„end-to-end” al datelor. Pentru un astfel de test este necesar 
un cititor de testare DSRC. Cititorul de testare DSRC înde ­
plinește aceeași funcție și este implementat cu acelea și speci­
ficații ca cititorul folosit de for țele de ordine, cu diferen ța că 
pentru autentificarea utilizatorului cititorului de testare DSRC 
trebuie folosit un card de atelier și nu un card de control. 
Testul poate fi executat dup ă activarea ini țială a unui 
tahograf inteligent sau la sfâr șitul procedurii de etalonare. 
După activare, unitatea montat ă pe vehicul trebuie s ă 
genereze și să comunice c ătre DSRC-VU datele securizate 
pentru detectarea timpurie.  
DSC_86 Personalul atelierului trebuie s ă poziționeze cititorul de testare 
DSRC la o distan ță de 2-10 metri în fa ța vehiculului.  
DSC_87 Apoi, personalul atelierului introduce un card de atelier în 
cititorul de testare DSRC pentru a solicita interogarea 
datelor pentru detectarea timpurie de la unitatea montat ă pe 
vehicul. Dup ă o interogare reu șită, personalul atelierului va 
accesa datele primite pentru a se asigura ca au fost validate cu 
succes în ceea ce prive ște integritatea și decriptate.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 534  
Apendicele 15  
MIGRAȚIE: GESTIONAREA COEXISTEN ȚEI MAI MULTOR 
GENERA ȚII DE ECHIPAMENTE  
CUPRINS  
1. DEFINI ȚII 
2. DISPOZI ȚII GENERALE  
2.1. Prezentare general ă a tranziției 
2.2. Interoperabilitatea dintre VU și carduri  
2.3. Interoperabilitatea dintre VU și MS  
2.4. Interoperabilitatea dintre unit ățile montate pe vehicule, 
cardurile de tahograf și echipamentele pentru desc ărcarea 
datelor  
2.4.1 Desc ărcare direct ă de pe card de c ătre IDE  
2.4.2 Desc ărcare de pe card prin intermediul unei unit ăți montate 
pe vehicul  
2.4.3 Desc ărcarea din unitatea montat ă pe vehicul  
2.5. Interoperabilitatea dintre VU și echipamentele de etalonare  
3. PRINCIPALELE ETAPE ÎN PERIOADA ANTERIOAR Ă 
DATEI INTRODUCERII  
4. DISPOZI ȚII PENTRU PERIOADA POSTERIOAR Ă 
DATEI INTRODUCERII  
1. DEFINI ȚII 
În sensul prezentului apendice, se folosesc urm ătoarele defini ții: 
sistem tahografic inteligent : conform defini ției din prezenta anex ă 
[capitolul 1: defini ția (bbb)];  
sistem tahografic de prima genera ție: conform defini ției din prezentul 
regulament (articolul 2: defini ția 1);  
sistem tahografic de a doua genera ție: conform defini ției din prezentul 
regulament (articolul 2: defini ția 7);  
data introducerii : conform defini ției din prezenta anex ă [capitolul 1: 
definiția (ccc)];  
echipament inteligent dedicat (IDE) : echipament utilizat la desc ărcarea 
de date, conform defini ției din apendicele 7 la prezenta anex ă. 
2. DISPOZI ȚII GENERALE  
2.1. Prezentare general ă a tranzi ției 
Preambulul la prezenta anex ă oferă o prezentare general ă a tranziției de 
la prima la a doua genera ție de sisteme tahografice.  
În plus față de cele prev ăzute în prezentul preambul:  
— prima genera ție de senzori de mi șcare nu va fi interoperabil ă cu a 
doua genera ție de unități montate pe vehicule;  
— a doua genera ție de senzori de mi șcare va începe s ă fie instalat ă în 
vehicule în acela și timp cu a doua genera ție de unități montate pe 
vehicule;  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 535  
— echipamentele de etalonare și de descărcare a datelor vor trebui s ă 
evolueze pentru a fi compatibile cu utilizarea ambelor genera ții de 
aparatură de înregistrare și de carduri de tahograf.  
2.2. Interoperabilitatea dintre VU și carduri  
▼M1 
Este de la sine în țeles că prima genera ție de carduri de tahograf este 
interoperabil ă cu prima genera ție de unit ăți montate pe vehicule în 
conformitate cu anexa IB la Regulamentul (CEE) nr. 3821/85, în timp 
ce a doua genera ție de carduri de tahograf este interoperabil ă cu a doua 
generație de unități montate pe vehicule în conformitate cu anexa IC la 
prezentul regulament. În plus, se aplic ă cerințele de mai jos.  
▼B 
MIG_001 Cu excep ția cazurilor prev ăzute în cerin ța MIG_004 și în 
MIG_005, cardurile de tahograf de prima genera ție pot fi 
utilizate în continuare cu a doua genera ție de unit ăți 
montate pe vehicule, pân ă la data de expirare a valabilit ății 
lor. Deținătorii acestora pot îns ă solicita înlocuirea lor cu 
carduri de tahograf de a doua genera ție, de îndat ă ce 
acestea din urm ă sunt disponibile.  
MIG_002 A doua genera ție de unități montate pe vehicule trebuie s ă 
poată utiliza orice card valabil de conduc ător auto, de control 
și de societate de prima genera ție introdus.  
MIG_003 Aceast ă capacitate poate fi suprimat ă definitiv în aceste 
unități montate pe vehicule, în cadrul atelierelor, astfel 
încât să nu mai poat ă fi acceptate cardurile de tahograf de 
prima genera ție. Aceasta se poate face numai dup ă ce 
Comisia European ă a lansat o procedur ă pentru a solicita 
atelierelor s ă acționeze în acest sens, de exemplu cu ocazia 
fiecărei inspecții periodice a tahografului.  
MIG_004 A doua genera ție de unități montate pe vehicule trebuie s ă 
poată utiliza numai carduri de atelier de a doua genera ție. 
MIG_005 Pentru stabilirea modului de func ționare, a doua genera ție de 
unități montate pe vehicule trebuie s ă ia în considerare numai 
tipurile cardurilor valabile introduse, indiferent de genera ția 
acestora.  
MIG_006 Orice card de tahograf de a doua genera ție valabil trebuie s ă 
poată fi utilizat cu prima genera ție de unit ăți montate pe 
vehicule exact în acela și mod ca un card de tahograf de 
prima genera ție de acela și tip.  
2.3. Interoperabilitatea dintre VU și MS  
Este de la sine în țeles că prima genera ție de senzori de mi șcare este 
interoperabil ă cu prima genera ție de unități montate pe vehicule, iar a 
doua genera ție de senzori de mi șcare este interoperabil ă cu a doua 
generație de unități montate pe vehicule. În plus, se aplic ă cerințele de 
mai jos.  
MIG_007 A doua genera ție de unități montate pe vehicule nu va putea 
fi asociată și utilizată cu senzori de mi șcare de prima gene ­
rație. 
MIG_008 Senzorii de mi șcare de a doua genera ție pot fi asocia ți și 
utilizați numai cu a doua genera ție de unit ăți montate pe 
vehicule sau cu ambele genera ții de unit ăți montate pe 
vehicule.  
2.4. Interoperabilitatea dintre unit ățile montate pe vehicule, cardurile de 
tahograf și echipamentele pentru desc ărcarea datelor  
MIG_009 Echipamentele pentru desc ărcarea datelor pot fi utilizate cu o 
singură generație de unități montate pe vehicule și de carduri 
de tahograf sau cu ambele.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 536  
2.4.1  Descărcare direct ă de pe card de c ătre IDE  
MIG_010 Datele sunt desc ărcate de c ătre IDE de pe cardurile de 
tahograf de o anumit ă generație introduse în cititoarele lor 
de carduri, cu utilizarea mecanismelor de securitate și a 
protocolului de desc ărcare a datelor aferente genera ției 
respective, iar datele desc ărcate trebuie s ă aibă formatul 
definit pentru genera ția respectiv ă. 
MIG_011 Pentru a permite controlarea conduc ătorilor auto de c ătre 
autorități de control care nu apar țin de UE, trebuie s ă fie 
de asemenea posibil ă descărcarea cardurilor de conduc ător 
auto (și de atelier) de a doua genera ție exact în acela și 
mod ca și cardurile de conduc ător autor ( și de atelier) de 
prima genera ție. Această descărcare trebuie s ă includă: 
▼M1 
— EF IC și ICC nesemnate (op țional),  
▼B 
— EF nesemnate (prima genera ție)
 
și
 ,  
▼M1 
— celelalte EF cu date de aplica ție (din cadrul DF Tacho ­
graph) impuse de protocolul de desc ărcare pentru 
cardurile de prima genera ție. Aceste informa ții trebuie 
să fie protejate de o semn ătură digitală, în conformitate 
cu mecanismele de securitate aferente primei genera ții. 
Această descărcare nu trebuie s ă includă EF cu date de 
aplicație care sunt prezente doar în cardurile de conduc ător 
auto (și de atelier) de a doua genera ție (EF cu date de 
aplicație din cadrul DF Tachograph_G2).  
▼B 
2.4.2  Descărcare de pe card prin intermediul unei unit ăți montate pe vehicul  
MIG_012 Datele de pe un card de a doua genera ție introdus într-o 
unitate montat ă pe vehicul de prima genera ție se descarc ă 
folosind protocolul de desc ărcare a datelor aferent primei 
generații. Cardul trebuie s ă răspundă comenzilor date de 
unitatea montat ă pe vehicul exact în acela și mod ca un 
card de prima genera ție, iar datele desc ărcate trebuie s ă 
aibă același format ca datele desc ărcate de pe un card de 
prima genera ție. 
MIG_013 Datele de pe un card de prima genera ție introdus într-o 
unitate montat ă pe vehicul de a doua genera ție se descarc ă 
folosind protocolul de desc ărcare a datelor definit în apen ­
dicele 7 la prezenta anex ă. Unitatea montat ă pe vehicul 
trebuie să transmită comenzi cardului exact în acela și mod 
ca o unitate montat ă pe vehicul de prima genera ție, iar datele 
descărcate trebuie s ă respecte formatul definit pentru 
cardurile de prima genera ție. 
2.4.3  Descărcarea din unitatea montat ă pe vehicul  
▼M1 
MIG_014 În afara cadrului controlului conduc ătorilor auto de c ătre 
autorități de control din afara UE, datele din a doua 
generație de unit ăți montate pe vehicule se descarc ă 
folosind mecanismele de securitate aferente celei de-a doua 
generații și protocolul de desc ărcare a datelor specificat în 
apendicele 7 la prezenta anex ă. 
MIG_015 Pentru a permite controlarea conduc ătorilor auto de c ătre 
autorități de control din afara UE, poate exista op țiunea 
descărcării datelor din a doua genera ție de unități montate 
pe vehicule cu utilizarea mecanismelor de securitate aferente 
primei genera ții. Datele desc ărcate au în acest caz acela și 
format ca datele desc ărcate dintr-o unitate montat ă pe 
vehicul de prima genera ție. Aceast ă opțiune poate fi 
selectată cu ajutorul comenzilor din meniu.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 537  
2.5. Interoperabilitatea dintre VU și echipamentele de etalonare  
MIG_016 Echipamentele de etalonare trebuie s ă poată efectua 
etalonarea fiec ărei generații de tahografe, utilizând protocolul 
de etalonare aferent genera ției respective. Echipamentele de 
etalonare pot fi utilizate cu o singur ă generație de tahografe 
sau cu ambele.  
3. PRINCIPALELE ETAPE ÎN PERIOADA ANTERIOAR Ă DATEI 
INTRODUCERII  
MIG_017 Certificatele și cheile de testare trebuie s ă se afle la dispozi ția 
producătorilor cel târziu cu  30 de luni  înainte de data intro ­
ducerii.  
MIG_018 Testele de interoperabilitate trebuie s ă fie gata de demarare, 
dacă sunt solicitate de produc ători, cel târziu cu  15 luni  
înainte de data introducerii.  
MIG_017 Certificatele și cheile oficiale trebuie s ă se afle la dispozi ția 
producătorilor cel târziu cu  12 luni  înainte de data introdu ­
cerii.  
MIG_020 Statele membre trebuie s ă fie în măsură să emită carduri de 
atelier de a doua genera ție cel târziu cu  3 luni  înainte de data 
introducerii.  
MIG_021 Statele membre trebuie s ă fie în m ăsură să emită toate 
tipurile de carduri de tahograf de a doua genera ție cel 
târziu cu  1 lună înainte de data introducerii . 
4. DISPOZI ȚII PENTRU PERIOADA POSTERIOAR Ă DATEI INTRO ­
DUCERII  
MIG_022 Dup ă data introducerii, statele membre trebuie s ă emită 
numai carduri de tahograf de a doua genera ție. 
MIG_023 Produc ătorilor de unit ăți montate pe vehicule / senzori de 
mișcare li se permite s ă producă unități montate pe 
vehicule / senzori de mi șcare de prima genera ție atât timp 
cât acestea / ace știa sunt utilizate / utiliza ți în practic ă, astfel 
încât componentele defecte s ă poată fi înlocuite.  
MIG_024 Produc ătorilor de unit ăți montate pe vehicule / senzori de 
mișcare li se permite s ă solicite și să obțină menținerea 
omologării de tip pentru tipurile deja omologate de unit ăți 
montate pe vehicule / senzori de mi șcare de prima genera ție. ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 538  
Apendicele 16.  
ADAPTOR PENTRU VEHICULELE DIN CATEGORIILE M1 ȘI N1  
CUPRINS  
1. ABREVIERI ȘI DOCUMENTE DE REFERIN ȚĂ 
1.1. Abrevieri  
1.2. Standarde de referin ță 
2. CARACTERISTICILE GENERALE ȘI FUNCȚIILE ADAPTORULUI  
2.1. Descriere general ă a adaptorului  
2.2. Func ții 
2.3. Securitate  
3. CERIN ȚE PENTRU APARATURA DE ÎNREGISTRARE ÎN CAZUL 
INSTALĂRII UNUI ADAPTOR  
4. CERIN ȚE FUNC ȚIONALE ȘI DE CONSTRUC ȚIE PENTRU 
ADAPTOR  
4.1. Interfa țare și adaptarea impulsurilor de vitez ă de intrare  
4.2. Orientarea impulsurilor de intrare c ătre senzorul de mi șcare integrat  
4.3. Senzorul de mi șcare integrat  
4.4. Cerin țe de securitate  
4.5. Caracteristici de performan ță 
4.6. Materiale  
4.7. Marcaje  
5. INSTALAREA APARATURII DE ÎNREGISTRARE ÎN CAZUL 
UTILIZĂRII UNUI ADAPTOR  
5.1. Instalarea  
5.2. Sigilarea  
6. CONTROALE, INSPEC ȚII ȘI REPARA ȚII 
6.1. Inspec ții periodice  
7. OMOLOGAREA DE TIP A APARATURII DE ÎNREGISTRARE ÎN 
CAZUL UTILIZ ĂRII UNUI ADAPTOR  
7.1. Considera ții generale  
7.2. Certificat de func ționare  
1. ABREVIERI ȘI DOCUMENTE DE REFERIN ȚĂ 
1.1. Abrevieri  
TBD de precizat  
VU Unitate montat ă pe vehicul  
1.2. Standarde de referin ță 
ISO16844-3  Road vehicles – Tachograph systems – Part 3 : Motion sensor 
interface  
2. CARACTERISTICILE GENERALE ȘI FUNCȚIILE ADAPTORULUI  
2.1. Descriere general ă a adaptorului  
ADA_001 Adaptorul furnizeaz ă unei unități montate pe vehicul conectate 
date de mi șcare securizate, care sunt în mod permanent repre ­
zentative pentru viteza vehiculului și pentru distan ța parcursă 
de acesta.  
Adaptorul este destinat numai vehiculelor care, conform 
prezentului regulament, trebuie s ă fie echipate cu aparatur ă 
de înregistrare.  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 539  
Acesta se instaleaz ă și se utilizeaz ă numai la tipurile de 
vehicule definite la defini ția (yy), „adaptor”, acolo unde este 
imposibil din punct de vedere mecanic s ă se instaleze orice alt 
tip de senzor de mi șcare existent care respect ă dispozițiile 
prezentei anexe și ale apendicelor 1-16 la prezenta anex ă. 
Adaptorul nu se conecteaz ă mecanic la un element mobil al 
vehiculului, ci se conecteaz ă la impulsurile de vitez ă/distanță 
generate de senzori integra ți sau de interfe țe alternative.  
ADA_002 Un senzor de mi șcare omologat de tip (conform dispozi țiilor 
din secțiunea 8 a prezentei anexe IC, Omologarea de tip a 
aparaturii de înregistrare și a cardurilor de tahograf) este 
montat în carcasa adaptorului, care con ține de asemenea un 
dispozitiv de convertire a impulsurilor al c ărui rol este s ă 
orienteze impulsurile de intrare c ătre senzorul de mi șcare 
integrat. Senzorul de mi șcare integrat este conectat la VU, 
astfel încât interfa ța dintre VU și adaptor s ă respecte 
cerințele stabilite în standardul ISO16844-3.  
2.2. Funcții 
ADA_003 Adaptorul are urm ătoarele func ții: 
— interfațare și adaptarea impulsurilor de vitez ă de intrare,  
— orientarea impulsurilor de intrare c ătre senzorul de mi șcare 
integrat,  
— toate func țiile senzorului de mi șcare integrat, care 
furnizează VU date de mi șcare securizate.  
2.3. Securitate  
ADA_004 Securitatea adaptorului nu se certific ă conform obiectivului 
general de securitate pentru senzorii de mi șcare definit în apen ­
dicele 10 la prezenta anex ă. În locul acestuia, se aplic ă 
cerințele de securitate specificate în sec țiunea 4.4 din 
prezentul apendice.  
3. CERIN ȚE PENTRU APARATURA DE ÎNREGISTRARE ÎN CAZUL 
INSTALĂRII UNUI ADAPTOR  
Cerințele din urm ătoarele capitole indic ă modul în care trebuie în țelese 
cerințele din prezenta anex ă în cazul utiliz ării unui adaptor. Numerele 
aferente cerin țelor din anexa IC sunt men ționate între paranteze.  
ADA_005 Aparatura de înregistrare a oric ărui vehicul prev ăzut cu un 
adaptor trebuie s ă respecte toate dispozi țiile prezentei anexe, 
cu excepția cazului în care se prevede altfel în prezentul 
apendice.  
ADA_006 Atunci când este instalat un adaptor, aparatura de înregistrare 
include cabluri, adaptorul în sine (inclusiv un senzor de 
mișcare) și o VU (01).  
ADA_007 Func ția de detectare a evenimentelor și/sau a anomaliilor 
aparaturii de înregistrare se modific ă după cum urmeaz ă: 
— evenimentul „întreruperea aliment ării cu energie electric ă” 
este declan șat de VU, atunci când aceasta nu se afl ă în 
modul de etalonare, în cazul oric ărei întreruperi de peste 
200 de milisecunde a aliment ării cu energie electric ă a 
senzorului de mi șcare integrat (79)  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 540  
— evenimentul „eroare a datelor de mi șcare” este declan șat de 
VU în cazul întreruperii fluxului normal de date dintre 
senzorul de mi șcare integrat și VU și/sau în cazul unor 
erori de integritate sau de autentificare a datelor survenite 
în timpul schimbului de date dintre senzorul de mi șcare 
integrat și VU (83)  
— evenimentul „tentativ ă de încălcare a securit ății” este 
declanșat de VU, atunci când aceasta nu se afl ă în modul 
de etalonare, în cazul oric ărui eveniment care afecteaz ă 
securitatea senzorului de mi șcare integrat (85)  
— anomalia „aparatura de înregistrare” este declan șată de VU, 
atunci când aceasta nu se afl ă în modul de etalonare, în 
cazul oricărei defecțiuni a senzorului de mi șcare integrat 
(88) 
ADA_008 Anomaliile adaptorului care pot fi detectate de aparatura de 
înregistrare sunt cele legate de senzorul de mi șcare integrat 
(88).  
ADA_009 Func ția de etalonare a VU permite asocierea automat ă a 
senzorului de mi șcare integrat cu VU (202, 204).  
4. CERIN ȚE FUNC ȚIONALE ȘI DE CONSTRUC ȚIE PENTRU 
ADAPTOR  
4.1. Interfa țare și adaptarea impulsurilor de vitez ă de intrare  
ADA_011 Interfa ța de intrare a adaptorului trebuie s ă accepte impulsuri 
de frecven ță care sunt reprezentative pentru viteza vehiculului 
și pentru distan ța parcursă de acesta. Caracteristicile electrice 
ale impulsurilor de intrare sunt:  a se defini de c ătre produ ­
cător. Trebuie s ă existe reglaje, accesibile numai produc ă­
torului adaptorului și numai atelierului autorizat care efectueaz ă 
instalarea adaptorului, care s ă permită interfațarea corect ă a 
intrării adaptorului cu vehiculul, dac ă este cazul.  
ADA_012 Interfa ța de intrare a adaptorului trebuie s ă fie capabil ă, dacă 
este cazul, s ă înmulțească sau să împartă impulsurile de 
frecvență ale impulsurilor de vitez ă de intrare la un factor 
fix, pentru adaptarea semnalului la intervalul de factori k 
definit în prezenta anex ă (4 000-25 000 de impulsuri/km). 
Acest factor fix poate fi programat numai de produc ătorul 
adaptorului și de atelierul autorizat care efectueaz ă instalarea 
adaptorului.  
4.2. Orientarea impulsurilor de intrare c ătre senzorul de mi șcare integrat  
ADA_013 Impulsurile de intrare, posibil adaptate dup ă cum se specific ă 
mai sus, sunt direc ționate către senzorul de mi șcare integrat, 
astfel încât fiecare impuls de intrare s ă fie detectat de senzorul 
de mișcare.  
4.3. Senzorul de mi șcare integrat  
ADA_014 Senzorul de mi șcare integrat este stimulat de impulsurile 
induse, permi țându-i astfel s ă genereze date de mi șcare care 
redau cu precizie deplasarea vehiculului, ca și cum ar fi 
interfațat mecanic cu o parte mobil ă a vehiculului.  
ADA_015 Datele de identificare ale senzorului de mi șcare integrat sunt 
folosite de VU pentru identificarea adaptorului (95).  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 541  
ADA_016 Se consider ă că datele de instalare stocate în senzorul de 
mișcare integrat reprezint ă datele de instalare ale adaptorului 
(122).  
4.4. Cerințe de securitate  
ADA_017 Carcasa adaptorului se proiecteaz ă în așa fel încât s ă nu poată 
fi deschisă. Carcasa se sigileaz ă, astfel încât tentativele de 
manipulare fizic ă frauduloas ă să fie ușor de detectat (de 
exemplu, prin inspec ție vizuală, a se vedea ADA_035). 
Sigiliile respect ă aceleași cerințe ca cele folosite pentru 
sigiliile senzorilor de mi șcare (398-406)  
ADA_018 Nu trebuie s ă fie posibil ă scoaterea senzorului de mi șcare 
integrat din adaptor f ără ruperea sigiliului sau a sigiliilor 
carcasei adaptorului sau f ără ruperea sigiliului dintre senzor 
și carcasa adaptorului (a se vedea ADA_034).  
ADA_019 Adaptorul trebuie s ă asigure faptul c ă datele de mi șcare nu pot 
fi prelucrate și extrase decât din intrarea adaptorului.  
4.5. Caracteristici de performan ță 
ADA_020 Adaptorul trebuie s ă fie perfect func țional în intervalul de 
temperatur ă definit de produc ător. 
ADA_021 Adaptorul este perfect func țional în intervalul de umiditate 
10 %-90 % (214).  
ADA_022 Adaptorul este protejat împotriva supratensiunilor, a invers ării 
polarității sursei de alimentare și a scurtcircuitelor (216).  
ADA_023 Adaptorul trebuie fie:  
— să reacționeze la un câmp magnetic care perturb ă detectarea 
deplasării vehiculului; în acest caz, unitatea montat ă pe 
vehicul va înregistra și va stoca o anomalie a senzorului 
(88), fie  
— să fie prevăzut cu un element detector care s ă fie protejat 
împotriva câmpurilor magnetice sau imun la acestea (217).  
ADA_024 Adaptorul trebuie s ă respecte dispozi țiile Regulamentului inter ­
național CEE-ONU nr. 10, referitor la compatibilitatea electro ­
magnetică, și trebuie s ă fie protejat împotriva desc ărcărilor 
electrostatice și a curenților tranzitorii (218).  
4.6. Materiale  
ADA_025 Adaptorul trebuie s ă corespund ă indicelui de protec ție (a se 
defini de c ătre produc ător, în func ție de pozi ția de instalare)  
(220, 221).  
ADA_026 Carcasa adaptorului este de culoare galben ă. 
4.7. Marcaje  
ADA_027 Pe adaptor trebuie fixat ă o plăcuță descriptiv ă care con ține 
următoarele detalii:  
— denumirea și adresa produc ătorului adaptorului,  
— numărul de component ă al produc ătorului și anul de 
fabricație al adaptorului,  
— marca de omologare a tipului de adaptor sau a aparaturii de 
înregistrare care con ține adaptorul,  
— data instal ării adaptorului,  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 542  
— numărul de identificare al vehiculului pe care acesta a fost 
instalat.  
ADA_028 Pl ăcuța descriptiv ă trebuie să includă de asemenea urm ătoarele 
detalii (dac ă acestea nu pot fi citite direct din afar ă pe senzorul 
de mișcare integrat):  
— denumirea produc ătorului senzorului de mi șcare integrat,  
— numărul de component ă al produc ătorului și anul de 
fabricație al senzorului de mi șcare integrat,  
— marca de omologare a senzorului de mi șcare integrat.  
5. INSTALAREA APARATURII DE ÎNREGISTRARE ÎN CAZUL 
UTILIZĂRII UNUI ADAPTOR  
5.1. Instalarea  
ADA_029 Adaptoarele care urmeaz ă a fi instalate pe vehicule trebuie 
instalate numai de produc ătorii vehiculelor sau de ateliere 
aprobate, autorizate s ă instaleze, s ă activeze și să etaloneze 
tahografe digitale și tahografe inteligente.  
ADA_030 Un astfel de atelier aprobat care instaleaz ă adaptorul regleaz ă 
interfața de intrare și selecteaz ă raportul de divizare al 
semnalului de intrare (dac ă este cazul).  
ADA_031 Un astfel de atelier aprobat care instaleaz ă adaptorul sigileaz ă 
apoi carcasa adaptorului.  
ADA_032 Adaptorul este instalat cât mai aproape de acea parte a vehi ­
culului care furnizeaz ă impulsurile de intrare.  
ADA_033 Cablurile de alimentare ale adaptorului sunt de culoare ro șie 
(polul pozitiv), respectiv neagr ă (masa).  
5.2. Sigilarea  
ADA_034 Se aplic ă următoarele cerin țe privind sigilarea:  
— carcasa adaptorului se sigileaz ă (a se vedea ADA_017),  
— carcasa senzorului integrat se sigileaz ă de carcasa adapto ­
rului, cu excep ția situației în care nu este posibil ă scoaterea 
senzorului din carcasa adaptorului f ără ruperea sigiliului 
(sigiliilor) carcasei adaptorului (a se vedea ADA_18),  
— carcasa adaptorului se sigileaz ă de vehicul,  
— conexiunea dintre adaptor și echipamentul care furnizeaz ă 
impulsurile de intrare ale acestuia se sigileaz ă la ambele 
capete (în m ăsura în care este posibil în mod rezonabil).  
6. CONTROALE, INSPEC ȚII ȘI REPARA ȚII 
6.1. Inspec ții periodice  
ADA_035 Atunci când este folosit un adaptor, fiecare inspec ție periodic ă 
[inspecție periodic ă înseamnă o inspecție în conformitate cu 
cerințele (409)-(413) din anexa 1C] asupra aparaturii de înre ­
gistrare trebuie s ă includă următoarele controale:  
— verificarea faptului c ă adaptorul poart ă marcajele de 
omologare de tip corespunz ătoare,  
— verificarea faptului c ă sigiliul de pe adaptor și cel de pe 
conexiunile sale sunt intacte,  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 543  
— verificarea faptului c ă adaptorul este instalat astfel cum este 
indicat pe pl ăcuța de instalare,  
— verificarea faptului c ă adaptorul este instalat astfel cum este 
specificat de produc ătorului adaptorului și/sau al vehicu ­
lului,  
— verificarea faptului c ă este autorizat ă montarea unui adaptor 
pe vehiculul care face obiectul inspec ției. 
ADA_036 Aceste inspec ții includ o etalonare și o înlocuire a tuturor 
sigiliilor, indiferent de starea lor.  
7. OMOLOGAREA DE TIP A APARATURII DE ÎNREGISTRARE ÎN 
CAZUL UTILIZ ĂRII UNUI ADAPTOR  
7.1. Considera ții generale  
ADA_037 Aparatura de înregistrare este prezentat ă completă în vederea 
omologării, împreun ă cu adaptorul (425).  
ADA_038 Orice adaptor poate fi prezentat pentru propria omologare de 
tip sau pentru omologarea de tip în calitate de component ă a 
unei aparaturi de înregistrare.  
ADA_039 O asemenea omologare de tip include teste de func ționare care 
implică folosirea adaptorului. Rezultatele pozitive ob ținute în 
cadrul acestor teste sunt men ționate într-un certificat cores ­
punzător (426).  
7.2. Certificat de func ționare  
ADA_040 Produc ătorului adaptorului i se elibereaz ă un certificat de 
funcționare pentru un adaptor sau pentru o aparatur ă de înre­
gistrare care include un adaptor numai în cazul în care au fost 
înregistrate rezultate pozitive în cadrul tuturor testelor de 
funcționare minime men ționate mai jos.  
Nr. Test  Descriere  Cerin țe conexe  
1. Examinare administrativ ă 
1.1 Documenta ție Corectitudinea 
documenta ției adap­
torului  
2. Inspec ție vizuală 
2.1. Respectarea documenta ției de către adaptor  
2.2. Identificare/marcaje a(le) adaptorului  ADA_027, 
ADA_028  
2.3 Materiale ale adaptorului  (219)-(223) 
ADA_026  
2.4. Sigilarea  ADA_017, 
ADA_018, 
ADA_034  
3. Teste de func ționare  
3.1 Orientarea impulsurilor de vitez ă către senzorul 
de mișcare integrat  ADA_013  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 544  
Nr. Test  Descriere  Cerin țe conexe  
3.2 Interfa țare și adaptarea impulsurilor de vitez ă de 
intrare  ADA_011, 
ADA_012  
3.3 Precizia m ăsurării deplasării (30) – (35), (217)  
4. Teste de mediu  
4.1 Rezultatele testelor 
efectuate de produc ător Rezultatele testelor 
de mediu efectuate 
de producător ADA_020, 
ADA_021, 
ADA_022, 
ADA_024  
5. EMC  
5.1 emisii radiate și suscepti­
bilitate  Verificarea confor ­
mității cu Directiva 
2006/28/CE  ADA_024  
5.2 Rezultatele testelor 
efectuate de produc ător Rezultatele testelor 
de mediu efectuate 
de producător ADA_024  ▼B
 02016R0799 — RO — 26.02.2020 — 002.001 — 545  
ANEXA II  
MARCA ȘI CERTIFICATUL DE OMOLOGARE  
I. MARCA DE OMOLOGARE  
1. Marca de omologare const ă în următoarele:  
(a) un dreptunghi în interiorul c ăruia se plaseaz ă litera „e” urmat ă de un 
număr sau de o liter ă distinctiv( ă) pentru țara care a emis omologarea, 
conform urm ătoarelor semne conven ționale: 
Belgia  6,  
Bulgaria  34,  
Republica Ceh ă 8,  
Danemarca  18,  
Germania  1,  
Estonia  29,  
Irlanda  24,  
Grecia  23,  
Spania  9,  
Franța 2,  
Croația 25,  
Italia  3,  
Cipru  CY,  
Letonia  32,  
Lituania  36,  
Luxemburg  13,  
Ungaria  7,  
Malta  MT,  
Țările de Jos  4,  
Austria  12,  
Polonia  20,  
Portugalia  21,  
România  19,  
Slovenia  26,  
Slovacia  27,  
Finlanda  17,  
Suedia  5,  
Regatul Unit  11,  
și 
▼M1 
(b) un num ăr de omologare care corespunde num ărului certificatului de 
omologare acordat prototipului de aparatur ă de înregistrare, de foaie de 
înregistrare sau de card de tahograf, plasat în imediata apropiere a drep ­
tunghiului respectiv.  ▼C1
 02016R0799 — RO — 26.02.2020 — 002.001 — 546  
2. Marca de omologare se aplic ă pe plăcuța descriptiv ă a fiecărui set de 
aparatură, precum și pe fiecare foaie de înregistrare și pe fiecare card de 
tahograf. Marca trebuie s ă fie indelebil ă și să rămână întotdeauna clar lizibil ă. 
3. Dimensiunile m ărcii de omologare prezentate mai jos (  1 ) sunt exprimate în 
milimetri, acestea reprezentând dimensiunile minime. Raportul dintre 
dimensiuni trebuie p ăstrat.
 ▼C1 
( 1 ) Aceste cifre sunt prezentate doar cu titlu orientativ.
 02016R0799 — RO — 26.02.2020 — 002.001 — 547  
II. CERTIFICAT DE OMOLOGARE PENTRU TAHOGRAFE ANALOGICE  
Un stat membru care a acordat o omologare emite solicitantului un certificat de 
omologare, al c ărui model este prezentat în continuare. Atunci când informeaz ă 
celelalte state membre cu privire la omolog ările emise sau, dac ă este cazul, 
retrase, statul membru în cauz ă folosește copii ale certificatului de omologare 
respectiv.  
CERTIFICAT DE OMOLOGARE  
Denumirea administra ției competente  
Notificare privind (  1 ): 
— omologarea unui tip de aparatur ă de înregistrare  
— retragerea omolog ării unui tip de aparatur ă de înregistrare  
— omologarea unui model de foaie de înregistrare  
— retragerea omolog ării unui model de foaie de înregistrare  
Omologarea nr.:  
...................................  
1. Denumirea sau marca comercial ă 
2. Denumirea tipului sau a modelului  
3. Denumirea produc ătorului  
4. Adresa produc ătorului  
5. Prezentat pentru omologare la  
6. Testat la  
7. Data și numărul testului (testelor)  
8. Data omolog ării 
9. Data retragerii omolog ării 
10. Tipul sau tipurile de aparatur ă de înregistrare pentru care este destinat ă foaia 
de înregistrare  
11. Locul  
12. Data  
13. Documente descriptive anexate  
14. Observa ții (inclusiv pozi ția sigiliilor, dac ă este cazul)  
(Semnătura) ▼C1 
( 1 ) A se șterge mențiunile care nu sunt aplicabile.
 02016R0799 — RO — 26.02.2020 — 002.001 — 548  
III. CERTIFICAT DE OMOLOGARE PENTRU TAHOGRAFE DIGITALE  
Un stat membru care a acordat o omologare emite solicitantului un certificat de 
omologare, al c ărui model este prezentat în continuare. Atunci când informeaz ă 
celelalte state membre cu privire la omolog ările emise sau, dac ă este cazul, 
retrase, statul membru în cauz ă folosește copii ale certificatului de omologare 
respectiv.  
CERTIFICAT DE OMOLOGARE PENTRU TAHOGRAFE DIGITALE  
Denumirea administra ției competente  
Notificare privind (  1 ): 
□ omologarea:  □ retragerea omolog ării: 
□ unui model de aparatur ă de înregistrare  
□ unei componente de aparatur ă de înregistrare (  2 ) 
□ unui card de conduc ător auto  
□ unui card de atelier  
□ unui card de societate  
□ unui card de controlor  
Omologarea nr.:  
1. Firma produc ătoare sau marca comercial ă 
2. Denumirea modelului  
3. Denumirea produc ătorului  
4. Adresa produc ătorului  
▼M1 
5. Prezentat spre omologare la  
▼C1 
6. Laborator (laboratoare)  
7. Data și numărul raportului de testare  
8. Data omolog ării 
9. Data retragerii omolog ării 
10. Modelul aparaturii (aparaturilor) de înregistrare cu care este destinat ă a fi 
folosită componenta  
11. Locul  
12. Data  
13. Documente descriptive anexate  
14. Observa ții (inclusiv pozi ția sigiliilor, dac ă este cazul)  
(Semnătura) ▼C1 
( 1 ) A se bifa casetele relevante. 
( 2 ) A se preciza componenta care face obiectul notific ării.
 02016R0799 — RO — 26.02.2020 — 002.001 — 549  
IV. CERTIFICAT DE OMOLOGARE PENTRU TAHOGRAFE 
INTELIGENTE  
Un stat membru care a acordat o omologare emite solicitantului un certificat de 
omologare, al c ărui model este prezentat în continuare. Atunci când informeaz ă 
celelalte state membre cu privire la omolog ările emise sau, dac ă este cazul, 
retrase, statul membru în cauz ă folosește copii ale certificatului de omologare 
respectiv.  
CERTIFICAT DE OMOLOGARE PENTRU TAHOGRAFE INTELIGENTE  
Denumirea administra ției competente  
Notificare privind (  1 ): 
□ omologarea:  □ retragerea omolog ării: 
□ unui model de aparatur ă de înregistrare  
□ unei componente de aparatur ă de înregistrare (  2 ) 
□ unui card de conduc ător auto  
□ unui card de atelier  
□ unui card de societate  
□ unui card de controlor  
Omologarea nr.:  
1. Firma produc ătoare sau marca comercial ă 
2. Denumirea modelului  
3. Denumirea produc ătorului  
4. Adresa produc ătorului  
▼M1 
5. Prezentat spre omologare la  
▼C1 
6. (a) Laborator de testare pentru certificarea func ționării 
(b) Laborator de testare pentru certificarea securit ății 
(c) Laborator de testare pentru certificarea interoperabilit ății 
7. (a) Data și numărul certificatului de func ționare  
(b) Data și numărul certificatului de securitate  
(c) Data și numărul certificatului de interoperabilitate  
8. Data omolog ării 
9. Data retragerii omolog ării 
10. Modelul aparaturii (aparaturilor) de înregistrare cu care este destinat ă a fi 
folosită componenta  
11. Locul  
12. Data  
13. Documente descriptive anexate  
14. Observa ții (inclusiv pozi ția sigiliilor, dac ă este cazul)  
(Semnătura) ▼C1 
( 1 ) A se bifa casetele relevante. 
( 2 ) A se preciza componenta care face obiectul notific ării.