Dokument ten s łuży wyłącznie do celów informacyjnych i nie ma mocy prawnej. Unijne instytucje nie ponosz ą żadnej 
odpowiedzialno ści za jego tre ść. Autentyczne wersje odpowiednich aktów prawnych, w łącznie z ich preambu łami, zosta ły 
opublikowane w Dzienniku Urz ędowym Unii Europejskiej i s ą dostępne na stronie EUR-Lex. Bezpo średni dost ęp do tekstów 
urzędowych mo żna uzyska ć za pośrednictwem linków zawartych w dokumencie  
►B ROZPORZ ĄDZENIE WYKONAWCZE KOMISJI (UE) 2016/799  
z dnia 18 marca 2016 r.  
w sprawie wykonania rozporz ądzenia Parlamentu Europejskiego i Rady (UE) nr 165/2014 
ustanawiaj ącego wymogi dotycz ące budowy, sprawdzania, instalacji, u żytkowania i naprawy 
tachografów oraz ich elementów sk ładowych  
(Tekst maj ący znaczenie dla EOG)  
(Dz.U. L 139 z 26.5.2016, s. 1)  
zmienione przez:  
Dziennik Urzędowy  
nr strona  data  
►M1 Rozporządzenie wykonawcze Komisji (UE) 2018/502 z dnia 28 lute go 
2018 r.  L 85  1  28.3.2018  
►M2 Rozporządzenie wykonawcze Komisji (UE) 2020/158 z dnia 5 luteg o 
2020 r.  L 34  2 0  6.2.2020  
►M3 Rozporządzenie wykonawcze Komisji (UE) 2021/1228 z dnia 16 lip ca 
2021 r.  L 273  1  30.7.2021  
sprostowane przez:  
►C1 Sprostowanie, Dz.U. L 146 z 3.6.2016, s. 31 (2016/799)  
►C2 Sprostowanie, Dz.U. L 27 z 1.2.2017, s. 169 (2016/799)  02016R0799 — PL — 21.08.2023 — 003.001 — 1
02016R0799 — PL — 21.08.2023 — 003.001 — 2  
ROZPORZ ĄDZENIE WYKONAWCZE KOMISJI (UE) 2016/799  
z dnia 18 marca 2016 r.  
w sprawie wykonania rozporz ądzenia Parlamentu Europejskiego 
i Rady (UE) nr 165/2014 ustanawiaj ącego wymogi dotycz ące 
budowy, sprawdzania, instalacji, u żytkowania i naprawy 
tachografów oraz ich elementów sk ładowych  
(Tekst maj ący znaczenie dla EOG)  
Artykuł 1 
Przedmiot i zakres stosowania  
1. Niniejsze rozporządzenie ustanawia przepisy niezbędne do jed no­
litego stosowania następujących aspektów dotyczących tachografó w: 
a) zapisywanie położenia pojazdu w pewnych punktach podczas dzi en­
nego okresu pracy kierowcy;  
b) wczesne wykrywanie na odległość możliwych przypadków manipu­
lowania tachografami inteligentnymi lub ich niewłaściwego użytk o­
wania;  
c) interfejs do inteligentnych systemów transportowych;  
d) wymogi administracyjne i techniczne dotyczące procedur homol o­
gacji typu dla tachografów, w tym mechanizmy zabezpieczające.  
▼M1 
2. Budowa, sprawdzanie, instalacja, kontrola, użytkowanie i nap rawa 
tachografów inteligentnych i ich elementów składowych muszą być  
zgodne z wymogami technicznymi określonymi w załączniku IC do 
niniejszego rozporządzenia.  
3. Tachografy inne niż tachografy inteligentne muszą nadal speł niać, 
jeśli chodzi o ich budowę, sprawdzanie, instalację, kontrolę, u żytko­
wanie i naprawę, wymogi zawarte w załączniku I do rozporzą­
dzenia (UE) nr 165/2014 albo w załączniku IB do rozporządzenia 
Rady (EWG) nr 3821/85 (  1 ), stosownie do przypadku.  
▼B 
4. Zgodnie z art. 10d dyrektywy 96/53/WE, urządzenie wczesnego 
wykrywania na odległość musi również przekazywać dane dotyczące  
mas dostarczone przez wewnętrzny pokładowy system ważenia na 
potrzeby wczesnego wykrywania nadużyć.  
▼M1 
5. Niniejsze rozporządzenie nie narusza przepisów dyrektywy Par la­
mentu Europejskiego i Rady 2014/53/UE (  2 ). 
▼B 
Artykuł 2 
Definicje  
Do celów niniejszego rozporządzenia zastosowanie mają definicje  
zawarte w art. 2 rozporządzenia (UE) nr 165/2014.  ▼B 
( 1 ) Rozporządzenie Rady (EWG) nr 3821/85 z dnia 20 grudnia 1985 r . w sprawie 
urządzeń rejestrujących stosowanych w transporcie drogowym (Dz. U. L 370 
z 31.12.1985, s. 8). 
( 2 ) Dyrektywa Parlamentu Europejskiego i Rady 2014/53/UE z dnia 1 6 kwietnia 
2014 r. w sprawie harmonizacji ustawodawstw państw członkowskic h doty­
czących udostępniania na rynku urządzeń radiowych i uchylająca dyrektywę 
1999/5/WE (Dz.U. L 153 z 22.5.2014, s. 62).
 02016R0799 — PL — 21.08.2023 — 003.001 — 3  
Zastosowanie mają ponadto następujące definicje:  
1) „tachograf cyfrowy” lub „tachograf pierwszej generacji” ozna cza 
tachograf cyfrowy inny niż tachograf inteligentny;  
2) „urządzenie zewnętrzne GNSS” oznacza urządzenie, które zawie ra 
odbiornik GNSS, jeżeli przyrząd rejestrujący nie jest pojedyncz ym 
urządzeniem, a także inne elementy składowe niezbędne do 
ochrony przekazywania danych o położeniu reszcie przyrządu reje s­
trującego;  
▼M1 
3) „folder informacyjny” oznacza pełny folder, w formie elektro ­
nicznej lub papierowej, zawierający wszystkie informacje dostar ­
czone przez producenta lub jego przedstawiciela organowi udziel a­
jącemu homologacji typu na potrzeby homologacji typu tachografu  
lub jego elementu składowego, w tym certyfikaty, o których mowa  
w art. 12 ust. 3 rozporządzenia (UE) nr 165/2014, wyniki testów  
przewidzianych w załączniku IC do niniejszego rozporządzenia, 
a także rysunki, fotografie i inne istotne dokumenty;  
▼B 
4) „pakiet informacyjny” oznacza folder informacyjny, w formie elek­
tronicznej lub papierowej, któremu towarzyszą wszelkie inne dok u­
menty dodane przez organ udzielający homologacji typu do folder u 
informacyjnego w ramach wykonywania jego funkcji, w tym – na 
zakończenie procesu homologacji typu – świadectwo homologacji 
typu WE tachografu lub jego elementu składowego;  
5) „indeks do pakietu informacyjnego” oznacza dokument zawieraj ący 
numerowany spis treści pakietu informacyjnego, wskazujący 
wszystkie istotne części tego pakietu. Format tego dokumentu 
umożliwia rozróżnienie kolejnych etapów w procesie homologacji 
typu WE, w tym dat wszelkich rewizji i aktualizacji tego pakiet u; 
6) „urządzenie wczesnego wykrywania na odległość” oznacza urzą­
dzenie przyrządu rejestrującego, które jest używane do przeprow a­
dzania ukierunkowanych kontroli drogowych;  
▼M1 
7) „tachograf inteligentny” lub „tachograf drugiej generacji” o znacza 
tachograf cyfrowy spełniający wymogi art. 8, 9 i 10 rozporzą­
dzenia (UE) nr 165/2014 oraz załącznika IC do niniejszego rozpo ­
rządzenia;  
8) „element składowy tachografu” oznacza dowolny z następującyc h 
elementów: przyrząd rejestrujący, czujnik ruchu, wykresówka, ur zą­
dzenie zewnętrzne GNSS oraz zewnętrzne urządzenie wczesnego 
wykrywania na odległość;  
▼B 
9) „organ udzielający homologacji typu” oznacza organ państwa 
członkowskiego właściwy w sprawach przeprowadzania homolo­
gacji typu tachografu lub jego elementów składowych, procesu 
zatwierdzania, wydawania oraz – w stosownych przypadkach – 
cofania świadectw homologacji typu, który działa jako punkt 
kontaktowy dla organów udzielających homologacji typu innych 
państw członkowskich oraz dopilnowuje, aby producenci wypeł­
niali swoje obowiązki dotyczące zapewnienia zgodności z wymo­
gami niniejszego rozporządzenia ;  
▼M1 
10) „przyrząd rejestrujący” oznacza tachograf bez czujnika ruch u i prze­
wodów do przyłączenia czujnika ruchu.  
Może to być pojedyncza jednostka lub kilka jednostek rozmieszcz onych 
w pojeździe, składających się z jednostki przetwarzającej, pami ęci 
danych, funkcji pomiaru czasu, dwóch czytników kart inteligentn ych 
(dla kierowcy i współkierowcy), drukarki, wyświetlacza, złącz i  urządzeń  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 4  
do wprowadzania danych przez użytkownika, odbiornika GNSS i urz ą­
dzenia do łączności na odległość.  
Przyrząd rejestrujący może się składać z następujących elementó w 
składowych podlegających homologacji typu:  
— urządzenie rejestrujące jako jeden element składowy (obejmu­
jący odbiornik GNSS i urządzenie do łączności na odległość),  
— jednostka główna przyrządu rejestrującego (obejmująca urzą­
dzenie do łączności na odległość) i urządzenie zewnętrzne 
GNSS,  
— jednostka główna przyrządu rejestrującego (obejmująca 
odbiornik GNSS) i zewnętrzne urządzenie do łączności na odle­
głość,  
— jednostka główna przyrządu rejestrującego, urządzenie 
zewnętrzne GNSS i zewnętrzne urządzenie do łączności na 
odległość.  
Jeżeli przyrząd rejestrujący składa się z kilku jednostek rozmi esz­
czonych w pojeździe, jednostką główną przyrządu rejestrującego 
jest jednostka zawierająca jednostkę przetwarzającą, pamięć dan ych 
i funkcję pomiaru czasu.  
Określenie „przyrząd rejestrujący” stosuje się w odniesieniu do  
„przyrządu rejestrującego” lub „jednostki głównej przyrządu rej es­
trującego”.  
▼B 
Artykuł 3 
Usługi w zakresie lokalizacji  
1. Producenci muszą zapewnić kompatybilność tachografów inteli­
gentnych z usługami określania pozycji świadczonymi przez syste m 
Galileo i europejski system wspomagania satelitarnego („EGNOS”) . 
2. Oprócz systemów, o których mowa w ust. 1, producenci mogą 
również postanowić o zapewnieniu kompatybilności z innymi syste ­
mami nawigacji satelitarnej.  
Artykuł 4 
Procedura homologacji typu tachografu i elementów sk ładowych 
tachografu  
1. Producent lub jego przedstawiciel składa wniosek o udzieleni e 
homologacji typu dla tachografu lub jego dowolnego elementu skł ado­
wego, bądź grupy elementów składowych, do organu udzielającego 
homologacji typu wyznaczonego przez dane państwo członkowskie. 
Obejmuje on folder informacyjny zawierający informacje na temat  
każdego z odpowiednich elementów składowych, w tym – w stosow­
nych przypadkach – świadectwa homologacji typu innych elementów  
składowych niezbędnych dla kompletności tachografu, jak również  
wszelkie inne istotne dokumenty.  
2. Państwo członkowskie udziela homologacji typu dla każdego 
tachografu, elementu składowego lub grupy elementów składowych,  
który(-a) spełnia wymogi administracyjne i techniczne określone  
w art. 1 ust. 2 lub 3, stosownie do przypadku. W takim przypadk u 
organ udzielający homologacji typu wydaje wnioskodawcy świadect wo 
homologacji typu zgodne ze wzorem określonym w załączniku II do  
niniejszego rozporządzenia.  
3. Organ udzielający homologacji typu może zażądać od producent a 
lub jego przedstawiciela dostarczenia wszelkich dodatkowych 
informacji.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 5  
4. Producent lub jego przedstawiciel udostępnia organom udziela ­
jącym homologacji typu, jak również podmiotom odpowiedzialnym z a 
wydawanie certyfikatów, o których mowa w art. 12 ust. 3 rozporz ą­
dzenia (UE) nr 165/2014, taką liczbę tachografów lub elementów skła­
dowych tachografu, jaka jest niezbędna, aby umożliwić przeprowa ­
dzenie procedury homologacji typu w satysfakcjonujący sposób.  
5. Jeżeli producent lub jego przedstawiciel ubiega się o homolo gację 
typu niektórych elementów składowych lub grup elementów składo­
wych tachografu, musi dostarczyć organom udzielającym homologac ji 
typu inne elementy składowe, które uzyskały już homologację typ u, 
a także inne części niezbędne do zbudowania kompletnego tachogr afu, 
aby umożliwić tym organom przeprowadzenie niezbędnych badań.  
Artykuł 5 
Modyfikacje homologacji typu  
1. Producent lub jego przedstawiciel informuje niezwłocznie org any 
udzielające homologacji typu, które udzieliły pierwotnej homolo gacji 
typu, o wszelkich modyfikacjach oprogramowania lub sprzętu tach o­
grafu bądź charakteru materiałów użytych do jego produkcji, któ re 
zostały odnotowane w pakiecie informacyjnym, i składa wniosek 
o modyfikację homologacji typu.  
2. Organy udzielające homologacji typu mogą dokonać rewizji lub  
rozszerzenia dotychczasowej homologacji typu albo wydać nową ho mo­
logację typu w zależności od rodzaju i właściwości tych modyfik acji. 
„Rewizja” ma miejsce, jeżeli organ udzielający homologacji typu  uzna, 
że modyfikacje oprogramowania lub sprzętu tachografu, bądź rodz aju 
materiałów użytych do jego produkcji, są niewielkie. W takich p rzypad­
kach organ udzielający homologacji typu wydaje zrewidowane doku ­
menty pakietu informacyjnego, wskazując rodzaj dokonanych modyf i­
kacji i datę ich zatwierdzenia. Zaktualizowana wersja pakietu i nforma­
cyjnego w formie skonsolidowanej, której towarzyszy szczegółowy  opis 
dokonanych modyfikacji, jest wystarczająca do spełnienia tego 
wymogu.  
„Rozszerzenie” ma miejsce, jeżeli organ udzielający homologacji  typu 
uzna, że modyfikacje oprogramowania lub sprzętu tachografu, bąd ź 
rodzaju materiałów użytych do jego produkcji, są istotne. W tak ich 
przypadkach Komisja może zwrócić się o przeprowadzenie nowych 
badań i poinformować o tym odpowiednio producenta lub jego upow aż­
nionego przedstawiciela. Jeśli wyniki tych badań okażą się zado wala­
jące, organ udzielający homologacji typu wydaje zrewidowane świ a­
dectwo homologacji typu, które zawiera numer odnoszący się do u dzie­
lonego rozszerzenia. Świadectwo homologacji typu wskazuje powód  
rozszerzenia oraz datę jego wydania.  
3. Indeks do pakietu informacyjnego wskazuje datę ostatniego 
rozszerzenia lub rewizji homologacji typu, bądź datę ostatniej konsoli­
dacji zaktualizowanej wersji homologacji typu.  
4. Nowa homologacja typu jest konieczna, jeżeli wnioskowane 
modyfikacje tachografu lub jego elementów składowych posiadając ych 
homologację typu prowadziłyby do wydania nowego świadectwa 
bezpieczeństwa lub interoperacyjności.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 6  
Artykuł 6 
Wejście w życie 
Niniejsze rozporządzenie wchodzi w życie dwudziestego dnia po j ego 
opublikowaniu w  Dzienniku Urz ędowym Unii Europejskiej . 
Niniejsze rozporządzenie stosuje się od dnia 2 marca 2016 r.  
▼M1 
Załącznik IC stosuje się jednak od dnia 15 czerwca 2019 r., z w yjątkiem 
dodatku 16, który stosuje się od dnia 2 marca 2016 r.  
▼B 
Niniejsze rozporządzenie wiąże w całości i jest bezpośrednio st osowane 
we wszystkich państwach członkowskich.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 7  
ZAŁĄCZNIK I C  
Wymagania w zakresie budowy, bada ń, instalacji i kontroli  
WPROWADZENIE  
1 DEFINICJE  
2 CHARAKTERYSTYKA OGÓLNA I FUNKCJE URZĄDZEŃ 
REJESTRUJĄCYCH  
2.1 Charakterystyka ogólna  
2.2 Funkcje  
2.3 Tryby pracy  
2.4 Zabezpieczenia  
3 WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE URZĄ­ 
DZEŃ REJESTRUJĄCYCH  
3.1 Monitorowanie wkładania i wyjmowania kart  
3.2 Pomiar prędkości, pozycji i odległości  
3.2.1 Pomiar przebytej drogi  
3.2.2 Pomiar prędkości  
3.2.3 Pomiar pozycji  
3.3 Pomiar czasu  
3.4 Monitorowanie czynności kierowcy  
3.5 Monitorowanie stanu prowadzenia pojazdu  
3.6 Dane wprowadzane przez kierowców  
3.6.1 Wprowadzanie miejsca rozpoczęcia lub zakończenia okresu p racy 
3.6.2 Ręczne wprowadzanie czynności kierowcy i zgoda kierowcy n a 
interfejs ITS  
3.6.3 Wprowadzanie warunków szczególnych  
▼M3 
3.6.4 Wprowadzanie operacji załadunku/rozładunku  
▼B 
3.7 Zarządzanie blokadami firmowymi  
3.8 Monitorowanie czynności kontrolnych  
3.9 Wykrywanie zdarzeń lub usterek  
3.9.1 Zdarzenie „włożenie nieważnej karty”  
3.9.2 Zdarzenie „konflikt kart”  
3.9.3 Zdarzenie „nakładające się czasy”  
3.9.4 Zdarzenie „prowadzenie pojazdu bez prawidłowej karty”  
3.9.5 Zdarzenie „włożenie karty podczas prowadzenia pojazdu”  
3.9.6 Zdarzenie „Sesja ostatniej karty niezamknięta prawidłowo”  
3.9.7 Zdarzenie „przekroczenie prędkości”  
3.9.8 Zdarzenie „przerwa w zasilaniu”  
3.9.9 Zdarzenie „błąd połączenia z urządzeniem do łączności na odległość”  
3.9.10 Zdarzenie „brak informacji o pozycji z odbiornika GNSS”  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 8  
3.9.11 Zdarzenie „błąd połączenia z urządzeniem zewnętrznym GNS S” 
3.9.12 Zdarzenie „błąd danych dotyczących ruchu”  
3.9.13 Zdarzenie „konflikt ruchu pojazdu”  
3.9.14 Zdarzenie „próba naruszenia zabezpieczenia”  
3.9.15 Zdarzenie „konflikt czasu”  
3.9.16 Usterka „karta”  
3.9.17 Usterka „urządzenie rejestrujące”  
▼M3 
3.9.18 Zdarzenie „anomalia GNSS”  
▼B 
3.10 Testy wbudowane i autotesty  
3.11 Odczyt z pamięci danych  
3.12 Rejestracja i przechowywanie w pamięci danych  
3.12.1 Dane identyfikujące sprzęt  
3.12.1.1 Dane identyfikujące przyrząd rejestrujący  
3.12.1.2 Dane identyfikujące czujnik ruchu  
3.12.1.3 Dane identyfikujące globalnego systemu nawigacji satel itarnej  
3.12.2 Klucze i certyfikaty  
3.12.3 Dane rejestrowane przy wkładaniu i wyjmowaniu karty kier owcy 
lub warsztatowej  
3.12.4 Dane dotyczące czynności kierowcy  
▼M1 
3.12.5 Miejsca i pozycje, w których zaczynają się i kończą dzie nne okresy 
pracy lub w których osiągnięto 3 godziny skumulowanego czasu 
prowadzenia pojazdu  
▼B 
3.12.6 Dane dotyczące licznika kilometrów  
3.12.7 Dane szczegółowe dotyczące prędkości  
3.12.8 Dane dotyczące zdarzeń  
3.12.9 Dane dotyczące usterek  
3.12.10 Dane kalibracyjne  
3.12.11 Dane dotyczące korekty czasu  
3.12.12 Dane dotyczące czynności kontrolnych  
3.12.13 Dane dotyczące blokad firmowych  
3.12.14 Dane dotyczące pobierania danych  
3.12.15 Dane dotyczące warunków szczególnych  
3.12.16 Dane karty do tachografu  
▼M3 
3.12.17 Przekroczenia granicy  
3.12.18 Operacje załadunku/rozładunku  
3.12.19 Mapa cyfrowa  
▼B 
3.13 Odczyt kart do tachografów  
3.14 Rejestrowanie i przechowywanie danych na kartach do tacho­  
grafów  
3.14.1 Rejestrowanie i przechowywanie danych na kartach do tach o­ 
grafów pierwszej generacji  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 9  
3.14.2 Rejestrowanie i przechowywanie danych na kartach do tach o­ 
grafów drugiej generacji  
3.15 Wyświetlanie  
3.15.1 Domyślne informacje na wyświetlaczu  
3.15.2 Wyświetlanie ostrzeżeń  
3.15.3 Dostęp do menu  
3.15.4 Inne wyświetlane informacje  
3.16 Drukowanie  
3.17 Ostrzeżenia  
3.18 Pobieranie danych na nośnik zewnętrzny  
3.19 Łączność na odległość na potrzeby ukierunkowanych kontroli  
drogowych  
▼M3 
3.20 Wymiana danych z dodatkowymi urządzeniami zewnętrznymi  
▼B 
3.21 Kalibracja  
3.22 Kontrola drogowa kalibracji  
3.23 Korekta czasu  
3.24 Parametry pracy  
3.25 Materiały  
3.26 Oznakowania  
▼M3 
3.27 Monitorowanie przekroczeń granicy  
3.28 Aktualizacja oprogramowania  
▼B 
4 WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE KART 
DO TACHOGRAFÓW  
4.1 Dane widzialne  
4.2 Zabezpieczenia  
4.3 Normy  
4.4 Wymagania środowiskowe i elektryczne  
4.5 Przechowywanie danych  
4.5.1 Pliki elementarne do identyfikacji i zarządzania kartą  
4.5.2 Identyfikacja kart mikroprocesorowych  
4.5.2.1 Identyfikacja mikroprocesora  
4.5.2.2 DIR (tylko w kartach do tachografów drugiej generacji)  
4.5.2.3 Informacje ATR (warunkowe, dostępne tylko w kartach do tacho­ 
grafów drugiej generacji)  
4.5.2.4 Informacje o rozszerzonej długości (warunkowe, dostępne  tylko 
w kartach do tachografów drugiej generacji)  
4.5.3 Karta kierowcy  
4.5.3.1 Aplikacja tachograficzna (dostępna dla przyrządów rejes trujących 
pierwszej i drugiej generacji)  
4.5.3.1.1 Identyfikacja aplikacji  
4.5.3.1.2 Klucz i certyfikaty  
4.5.3.1.3 Identyfikacja karty  
4.5.3.1.4 Identyfikacja posiadacza karty  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 10  
4.5.3.1.5 Pobieranie danych z karty  
4.5.3.1.6 Dane dotyczące prawa jazdy  
4.5.3.1.7 Dane dotyczące zdarzeń  
4.5.3.1.8 Dane dotyczące usterek  
4.5.3.1.9 Dane dotyczące czynności kierowcy  
4.5.3.1.10 Dane dotyczące używanych pojazdów  
4.5.3.1.11 Miejsca rozpoczęcia lub zakończenia dziennych okresó w pracy  
4.5.3.1.12 Dane sesji karty  
4.5.3.1.13 Dane dotyczące czynności kontrolnych  
4.5.3.1.14 Dane dotyczące warunków szczególnych  
4.5.3.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów 
rejestrujących pierwszej generacji)  
4.5.3.2.1 Identyfikacja aplikacji  
▼M3 
4.5.3.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w p rzypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
▼B 
4.5.3.2.2 Klucze i certyfikaty  
4.5.3.2.3 Identyfikacja karty  
4.5.3.2.4 Identyfikacja posiadacza karty  
4.5.3.2.5 Pobieranie danych z karty  
4.5.3.2.6 Dane dotyczące prawa jazdy  
4.5.3.2.7 Dane dotyczące zdarzeń  
4.5.3.2.8 Dane dotyczące usterek  
4.5.3.2.9 Dane dotyczące czynności kierowcy  
4.5.3.2.10 Dane dotyczące używanych pojazdów  
4.5.3.2.11 Miejsca i pozycje rozpoczęcia lub zakończenia dzienn ych okresów 
pracy  
4.5.3.2.12 Dane sesji karty  
4.5.3.2.13 Dane dotyczące czynności kontrolnych  
4.5.3.2.14 Dane dotyczące warunków szczególnych  
4.5.3.2.15 Dane dotyczące używanych przyrządów rejestrujących  
▼M1 
4.5.3.2.16 Dane miejsc, w których minęły trzy godziny skumulowa nego czasu 
prowadzenia pojazdu  
▼M3 
4.5.3.2.17 Status uwierzytelniania dla pozycji związanych z mie jscami rozpo­ 
częcia lub zakończenia dziennych okresów pracy (brak dostępu 
w przypadku wersji 1 drugiej generacji przyrządów rejestrującyc h) 
4.5.3.2.18 Status uwierzytelniania dla pozycji, w których osiąg nięto trzy 
godziny skumulowanego czasu prowadzenia pojazdu (brak dostępu 
w przypadku wersji 1 drugiej generacji przyrządów rejestrującyc h) 
4.5.3.2.19 Przekroczenia granicy (brak dostępu w przypadku wers ji 1 drugiej 
generacji przyrządów rejestrujących)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 11  
4.5.3.2.20 Operacje załadunku/rozładunku (brak dostępu w przypa dku wersji 
1 drugiej generacji przyrządów rejestrujących)  
4.5.3.2.21 Wprowadzanie typu załadunku (brak dostępu w przypadk u wersji 1 
drugiej generacji przyrządów rejestrujących)  
4.5.3.2.22 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
▼B 
4.5.4 Karta warsztatowa  
4.5.4.1 Aplikacja tachograficzna (dostępna dla przyrządów rejes trujących 
pierwszej i drugiej generacji)  
4.5.4.1.1 Identyfikacja aplikacji  
4.5.4.1.2 Klucze i certyfikaty  
4.5.4.1.3 Identyfikacja karty  
4.5.4.1.4 Identyfikacja posiadacza karty  
4.5.4.1.5 Pobieranie danych z karty  
4.5.4.1.6 Dane dotyczące kalibracji i korekty czasu  
4.5.4.1.7 Dane dotyczące zdarzeń i usterek  
4.5.4.1.8 Dane dotyczące czynności kierowcy  
4.5.4.1.9 Dane dotyczące używanych pojazdów  
4.5.4.1.10 Dane dotyczące rozpoczęcia lub zakończenia dziennych  okresów 
pracy  
4.5.4.1.11 Dane sesji karty  
4.5.4.1.12 Dane dotyczące czynności kontrolnych  
4.5.4.1.13 Dane dotyczące warunków szczególnych  
4.5.4.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów 
rejestrujących pierwszej generacji)  
4.5.4.2.1 Identyfikacja aplikacji  
▼M3 
4.5.4.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w p rzypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
▼B 
4.5.4.2.2 Klucze i certyfikaty  
4.5.4.2.3 Identyfikacja karty  
4.5.4.2.4 Identyfikacja posiadacza karty  
4.5.4.2.5 Pobieranie danych z karty  
4.5.4.2.6 Dane dotyczące kalibracji i korekty czasu  
4.5.4.2.7 Dane dotyczące zdarzeń i usterek  
4.5.4.2.8 Dane dotyczące czynności kierowcy  
4.5.4.2.9 Dane dotyczące używanych pojazdów  
4.5.4.2.10 Dane dotyczące rozpoczęcia lub zakończenia dziennych  okresów 
pracy  
4.5.4.2.11 Dane sesji karty  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 12  
4.5.4.2.12 Dane dotyczące czynności kontrolnych  
4.5.4.2.13 Dane dotyczące używanych przyrządów rejestrujących  
▼M1 
4.5.4.2.14 Dane miejsc, w których minęły trzy godziny skumulowa nego czasu 
prowadzenia pojazdu  
▼B 
4.5.4.2.15 Dane dotyczące warunków szczególnych  
▼M3 
4.5.4.2.16 Status uwierzytelniania dla pozycji związanych z mie jscami rozpo­ 
częcia lub zakończenia dziennych okresów pracy (brak dostępu 
w przypadku wersji 1 drugiej generacji przyrządów rejestrującyc h) 
4.5.4.2.17 Status uwierzytelniania dla pozycji, w których osiąg nięto trzy 
godziny skumulowanego prowadzenia pojazdu (brak dostępu 
w przypadku wersji 1 drugiej generacji przyrządów rejestrującyc h) 
4.5.4.2.18 Przekroczenia granicy (brak dostępu w przypadku wers ji 1 drugiej 
generacji przyrządów rejestrujących)  
4.5.4.2.19 Operacje załadunku/rozładunku (brak dostępu w przypa dku wersji 
1 drugiej generacji przyrządów rejestrujących)  
4.5.4.2.20 Wprowadzanie typu załadunku (brak dostępu w przypadk u wersji 1 
drugiej generacji przyrządów rejestrujących)  
4.5.4.2.21 Dodatkowe dane dotyczące kalibracji (brak dostępu w przypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
4.5.4.2.22 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
▼B 
4.5.5 Karta kontrolna  
4.5.5.1 Aplikacja tachograficzna (dostępna dla przyrządów rejes trujących 
pierwszej i drugiej generacji)  
4.5.5.1.1 Identyfikacja aplikacji  
4.5.5.1.2 Klucze i certyfikaty  
4.5.5.1.3 Identyfikacja karty  
4.5.5.1.4 Identyfikacja posiadacza karty  
4.5.5.1.5 Dane dotyczące czynności kontrolnych  
4.5.5.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów 
rejestrujących pierwszej generacji).  
4.5.5.2.1 Identyfikacja aplikacji  
▼M3 
4.5.5.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w p rzypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
▼B 
4.5.5.2.2 Klucze i certyfikaty  
4.5.5.2.3 Identyfikacja karty  
4.5.5.2.4 Identyfikacja posiadacza karty  
4.5.5.2.5 Dane dotyczące czynności kontrolnych  
▼M3 
4.5.5.2.6 Konfiguracje przyrządu rejestrującego (brak dostępu w  przypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
▼B 
4.5.6 Karta firmowa  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 13  
4.5.6.1 Aplikacja tachograficzna (dostępna dla przyrządów rejes trujących 
pierwszej i drugiej generacji)  
4.5.6.1.1 Identyfikacja aplikacji  
4.5.6.1.2 Klucze i certyfikaty  
4.5.6.1.3 Identyfikacja karty  
4.5.6.1.4 Identyfikacja posiadacza karty  
4.5.6.1.5 Dane dotyczące czynności wykonywanych przez firmę  
4.5.6.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów 
rejestrujących pierwszej generacji)  
4.5.6.2.1 Identyfikacja aplikacji  
▼M3 
4.5.6.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w p rzypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
▼B 
4.5.6.2.2 Klucze i certyfikaty  
4.5.6.2.3 Identyfikacja karty  
4.5.6.2.4 Identyfikacja posiadacza karty  
4.5.6.2.5 Dane dotyczące czynności wykonywanych przez firmę  
▼M3 
4.5.6.2.6 Konfiguracje przyrządu rejestrującego (brak dostępu w  przypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
▼B 
5 INSTALACJA URZĄDZENIA REJESTRUJĄCEGO  
5.1 Instalacja  
5.2 Tabliczka instalacyjna  
5.3 Plombowanie  
6 KONTROLE, PRZEGLĄDY I NAPRAWY  
6.1 Zatwierdzanie instalatorów, warsztatów i producentów pojazd ów 
▼M1 
6.2 Kontrola techniczna elementów składowych nowych i po napraw ie 
▼B 
6.3 Przegląd instalacyjny  
6.4 Przeglądy okresowe  
6.5 Wyznaczanie błędów  
6.6 Naprawy  
7 WYDAWANIE KART  
8 HOMOLOGACJA TYPU URZĄDZEŃ REJESTRUJĄCYCH 
I KART DO TACHOGRAFÓW  
8.1 Uwagi ogólne  
8.2 Świadectwo bezpieczeństwa  
8.3 Świadectwo funkcjonalności  
8.4 Świadectwo interoperacyjności  
8.5 Świadectwo homologacji typu  
8.6 Procedura szczególna: pierwsze świadectwa interoperacyjnośc i dla 
urządzeń rejestrujących i kart do tachografów 2. generacji  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 14  
WPROWADZENIE  
Niniejszy załącznik zawiera wymogi dotyczące drugiej generacji urządzeń rejes­
trujących i kart do tachografów.  
Począwszy od dnia 15 czerwca 2019 r., w pojazdach rejestrowanyc h po raz 
pierwszy w Unii instaluje się urządzenia rejestrujące drugiej g eneracji i wydaje 
się karty do tachografów drugiej generacji.  
W celu sprawnego wdrożenia systemu tachografu drugiej generacji , karty do 
tachografu drugiej generacji zaprojektowano w taki sposób, aby możliwe było 
ich używanie również w przyrządach rejestrujących pierwszej gen eracji skon­
struowanych zgodnie z załącznikiem IB do rozporządzenia (EWG) n r 3821/85.  
Analogicznie karty do tachografu pierwszej generacji mogą być u żywane w przy­
rządach rejestrujących drugiej generacji. Przyrządy rejestrując e drugiej generacji 
mogą być kalibrowane tylko z użyciem kart warsztatowych drugiej  generacji.  
Wymogi dotyczące interoperacyjności między systemami tachografu  pierwszej 
i drugiej generacji określono w niniejszym załączniku. W tym wz ględzie dodatek 
15 zawiera dodatkowe szczegółowe informacje na temat zarządzani a kwestią 
współistnienia obu tych generacji.  
Ponadto, w związku z wdrożeniem nowych funkcji, takich jak stos owanie uwie­
rzytelniania komunikatów nawigacyjnych w ramach sygnałów otwart ych Galileo, 
wykrywanie przekroczeń granicy, wpisywanie operacji załadunku i  rozładunku, 
a także ze względu na konieczność zwiększenia pojemności karty kierowcy 
do 56 dni czynności kierowcy, niniejsze rozporządzenie wprowadz a wymogi 
techniczne dotyczące drugiej wersji drugiej generacji urządzeń rejestrujących 
i kart do tachografów.  
▼B 
Wykaz dodatków  
Dodatek 1: SPIS DANYCH  
Dodatek 2: SPECYFIKACJA KART DO TACHOGRAFÓW  
Dodatek 3: PIKTOGRAMY  
Dodatek 4: WYDRUKI  
Dodatek 5: WYŚWIETLACZ  
Dodatek 6: PRZEDNIE ZŁĄCZE KALIBRACJI I POBIERANIA 
DANYCH  
Dodatek 7: PROTOKOŁY POBIERANIA DANYCH  
Dodatek 8: PROTOKÓŁ KALIBRACJI  
Dodatek 9: HOMOLOGACJA TYPU I WYKAZ MINIMUM WYMA­ 
GANYCH BADAŃ  
Dodatek 10: WYMOGI BEZPIECZEŃSTWA  
Dodatek 11: WSPÓLNE MECHANIZMY ZABEZPIECZENIA  
Dodatek 12: OKREŚLANIE POŁOŻENIA Z WYKORZYSTANIEM 
GLOBALNEGO SYSTEMU NAWIGACJI SATELI­ 
TARNEJ (GNSS)  
Dodatek 13: INTERFEJS ITS  
Dodatek 14: FUNKCJA ŁĄCZNOŚCI NA ODLEGŁOŚĆ  
Dodatek 15: MIGRACJA: ZARZĄDZANIE WSPÓŁISTNIENIEM 
GENERACJI URZĄDZEŃ  
Dodatek 16: ADAPTER DO POJAZDÓW KATEGORII M1 I N1  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 15  
1 DEFINICJE  
W niniejszym załączniku:  
a) „aktywacja” oznacza:  
fazę, gdy tachograf uzyskuje pełną funkcjonalność i uruchamia 
wszystkie funkcje, łącznie z funkcjami zabezpieczającymi, 
z wykorzystaniem karty warsztatowej;  
b) „uwierzytelnienie”oznacza:  
funkcję służącą ustanowieniu i kontroli tożsamości;  
c) „autentyczność”oznacza:  
właściwość polegającą na tym, że informacje przychodzą od 
strony, której tożsamość można zweryfikować;  
d) „test wbudowany (BIT)”oznacza:  
testy wykonywane na żądanie, uruchamiane przez operatora 
lub urządzenia zewnętrzne;  
e) „dzień kalendarzowy” oznacza:  
dzień zaczynający się o godzinie 00:00 i kończący o godzinie 
24:00. Wszystkie dni kalendarzowe odnoszą się do czasu UTC 
(uniwersalny czas koordynowany);  
▼M3 
f) „kalibracja tachografu inteligentnego” oznacza:  
aktualizację lub potwierdzenie parametrów pojazdu przecho­
wywanych w pamięci danych. Parametry pojazdu obejmują 
identyfikację pojazdu (numery VIN, VRN i kod rejestrującego 
państwa członkowskiego) i charakterystyki pojazdu (w, k, l, 
wielkość opon, ustawienia urządzenia ograniczenia prędkości 
(w stosownych przypadkach), bieżący czas UTC, bieżący stan 
licznika kilometrów, domyślny typ załadunku); podczas kalib­
racji urządzenia rejestrującego w pamięci danych zachowy­
wane są również rodzaje i identyfikatory odpowiednich 
plomb homologacyjnych;  
aktualizację lub potwierdzenie jedynie czasu UTC uważa się 
za korektę czasu, a nie za kalibrację, pod warunkiem że nie 
jest to sprzeczne z wymogiem 409 określonym w pkt 6.4;  
do kalibracji urządzenia rejestrującego potrzebna jest karta 
warsztatowa;  
g) „numer karty” oznacza:  
numer składający się z 16 znaków alfanumerycznych, który 
jednoznacznie identyfikuje kartę do tachografów w państwie 
członkowskim. Numer karty zawiera identyfikację, która 
polega na identyfikacji kierowcy lub identyfikacji właściciela 
karty wraz z kolejnym numerem karty, numerem wymiany 
karty i numerem odnowienia karty;  
tym samym karta jest jednoznacznie zidentyfikowana przez 
kod państwa członkowskiego wydającego i numer karty;  
▼B 
h) „numer kolejny karty”oznacza:  
14. znak alfanumeryczny w numerze karty, który umożliwia 
rozróżnianie różnych kart firmie, warsztatowi lub organowi 
kontrolnemu uprawnionym do otrzymania kilku kart do tacho­
grafów. Firmę, warsztat lub organ kontrolny jednoznacznie 
identyfikuje pierwszych 13 znaków numeru karty;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 16  
i) „numer odnowienia karty” oznacza:  
16. znak alfanumeryczny w numerze karty, który jest zmie­
niany przyrostowo za każdym razem, gdy odnawiana jest karta 
do tachografu odpowiadająca danej identyfikacji, tj. identyfi­
kacji kierowcy lub identyfikacji właściciela wraz z kolejnym 
numerem karty;  
j) „numer wymiany karty” oznacza:  
15. znak alfanumeryczny w numerze karty, który jest zmieniany 
przyrostowo za każdym razem, gdy wymieniana jest karta do 
tachografu odpowiadająca danej identyfikacji, tj. identyfikacji  
kierowcy lub identyfikacji właściciela wraz z kolejnym numerem 
karty;  
▼B 
k) „współczynnik charakterystyczny pojazdu”oznacza:  
wielkość liczbową określającą wartość sygnału dostarczanego 
przez część pojazdu podłączoną do urządzenia rejestrującego 
(wał główny skrzyni biegów lub oś) w czasie, gdy pojazd 
przebywa drogę o długości jednego kilometra mierzoną 
w normalnych warunkach testowych, zgodnie z definicją 
w wymaganiu 414. Współczynnik charakterystyczny pojazdu 
podaje się w impulsach na kilometr (w =… imp/km);  
l) „karta firmowa” oznacza:  
kartę do tachografu wydaną przez organy państwa członkow­
skiego przedsiębiorstwu transportowemu używającemu 
pojazdów wyposażonych w tachografy, która identyfikuje to 
przedsiębiorstwo transportowe i pozwala na wyświetlanie, 
pobieranie i drukowanie danych zapisanych w tachografie, 
który został zabezpieczony blokadą przez to przedsiębiorstwo 
transportowe;  
m) „stała urządzenia rejestrującego” oznacza:  
wielkość liczbową określającą wartość sygnału wejściowego 
wymaganą do wskazania i rejestracji przebytej odległości 
jednego kilometra; stała ta jest wyrażona w impulsach na 
kilometr (k =…imp/km);  
n) „nieprzerwany czas prowadzenia pojazdu” obliczany jest przez  
urządzenie rejestrujące w następujący sposób (  1 ): 
nieprzerwany czas prowadzenia pojazdu obliczany jest jako 
bieżące, skumulowane czasy prowadzenia pojazdu przez 
danego kierowcę od końca jego ostatniego 45-minutowego 
lub dłuższego okresu GOTOWOŚCI lub PRZERWY/ODPO­
CZYNKU lub NIEOKREŚLONEGO (  2 ) (okres ten może być 
rozbity zgodnie z rozporządzeniem (WE) nr 561/2006 Parla­
mentu Europejskiego i Rady (  3 )). W obliczeniach uwzględnia 
się, stosownie do okoliczności, wcześniejsze czynności zapi­
sane na karcie kierowcy. Jeżeli kierowca nie włoży swojej 
karty, obliczenia wykonuje się na podstawie znajdujących się 
w pamięci danych zapisów dla bieżącego okresu, w którym 
nie było włożonej karty, i dla stosownego czytnika;  ▼M3 
( 1 ) Ten sposób obliczania nieprzerwanego czasu prowadzenia pojazd u oraz skumulowanego 
czasu przerwy służy urządzeniu rejestrującemu do obliczenia ost rzeżenia o nieprze­
rwanym czasie prowadzenia. Nie przesądza on o prawnej interpret acji tych czasów. 
Można stosować alternatywne sposoby obliczania nieprzerwanego c zasu prowadzenia 
pojazdu i skumulowanego czasu przerw w celu zastąpienia niniejs zych definicji, jeżeli 
definicje te stały się nieaktualne w wyniku nowelizacji innych stosownych przepisów. 
( 2 ) Okresy NIEOKREŚLONE odpowiadają okresom, gdy karta kierowcy n ie jest włożona 
do urządzenia rejestrującego, oraz w których nie dokonano ręczn ej rejestracji czynności 
kierowcy. 
( 3 ) Rozporządzenie (WE) nr 561/2006 Parlamentu Europejskiego i Ra dy z dnia 15 marca 
2006 r. w sprawie harmonizacji niektórych przepisów socjalnych odnoszących się do 
transportu drogowego oraz zmieniające rozporządzenia Rady (EWG)  nr 3821/85 i (WE) 
2135/98, jak również uchylające rozporządzenie Rady (EWG) nr 38 20/85 (Dz.U. L 102 
z 11.4.2006, s. 1).
 02016R0799 — PL — 21.08.2023 — 003.001 — 17  
o) „karta kontrolna” oznacza:  
kartę do tachografu wydaną krajowemu właściwemu organowi 
kontrolnemu przez organy państwa członkowskiego, która 
identyfikuje organ kontrolny i fakultatywnie funkcjonariusza 
służb kontrolnych oraz umożliwia dostęp do danych zapisa­
nych w pamięci danych lub na kartach kierowcy i fakulta­
tywnie na kartach warsztatowych w celu odczytu, wydruku 
lub pobrania danych;  
Daje ona również dostęp do funkcji kontroli drogowej kalib­
racji oraz do danych na czytniku wczesnego wykrywania na 
odległość.  
p) „skumulowany czas przerwy” obliczany jest przez urządzenie 
rejestrujące w następujący sposób (  1 ): 
skumulowany czas przerwy w prowadzeniu pojazdu obliczany 
jest jako bieżące, zakumulowane, 15-minutowe lub dłuższe 
okresy GOTOWOŚCI lub PRZERWY/ODPOCZYNKU lub 
NIEOKREŚLONE (  2 ) dla danego kierowcy, od końca jego 
ostatniego 45-minutowego lub dłuższego okresu GOTO­
WOŚCI lub PRZERWY/ODPOCZYNKU lub NIEOKREŚLO­
NEGO (  2 ) (okres ten może być rozbity zgodnie z rozporządze­
niem (WE) nr 561/2006).  
W obliczeniach uwzględnia się, stosownie do okoliczności, 
wcześniejsze czynności zapisane na karcie kierowcy. Do obli­
czeń nie bierze się nieokreślonych okresów o ujemnym czasie 
trwania (początek nieokreślonego okresu > koniec nieokreślo­
nego okresu) wynikłych z nakładania się czasów z dwóch 
różnych urządzeń rejestrujących.  
Jeżeli kierowca nie włoży swojej karty, obliczenia wykonuje 
się na podstawie znajdujących się w pamięci danych zapisów 
dla bieżącego okresu, w którym nie było włożonej karty, i dla 
stosownego czytnika.  
q) „pamięć danych” oznacza:  
elektroniczne urządzenie przechowywania danych wbudowane 
w urządzenie rejestrujące;  
r) „podpis cyfrowy” oznacza:  
dane dołączone do bloku danych lub kryptograficzne prze­
kształcenie bloku danych, które umożliwiają odbiorcy bloku 
danych potwierdzenie autentyczności oraz integralności 
danego bloku danych;  
s) „pobieranie” oznacza:  
kopiowanie, wraz z podpisem cyfrowym, części lub komplet­
nego zestawu pliku danych zapisanych w pamięci danych 
przyrządu rejestrującego lub w pamięci karty do tachografu, 
pod warunkiem że proces ten nie zmienia ani nie usuwa 
żadnych zapisanych danych;  ▼B 
( 1 ) Ten sposób obliczania nieprzerwanego czasu prowadzenia pojazd u oraz skumulowanego 
czasu przerwy służy urządzeniu rejestrującemu do obliczenia ost rzeżenia o nieprze­
rwanym czasie prowadzenia. Nie przesądza on o prawnej interpret acji tych czasów. 
Można stosować alternatywne sposoby obliczania nieprzerwanego c zasu prowadzenia 
pojazdu i skumulowanego czasu przerw w celu zastąpienia niniejs zych definicji, jeżeli 
definicje te stały się nieaktualne w wyniku nowelizacji innych stosownych przepisów. 
( 2 ) Okresy NIEOKREŚLONE odpowiadają okresom, gdy karta kierowcy n ie jest włożona 
do urządzenia rejestrującego, oraz w których nie dokonano ręczn ej rejestracji czynności 
kierowcy.
 02016R0799 — PL — 21.08.2023 — 003.001 — 18  
Producenci przyrządów rejestrujących tachografów inteligent­
nych oraz producenci urządzeń skonstruowanych i przeznaczo­
nych do pobierania zbiorów danych podejmują wszelkie racjo­
nalne działania zapewniające pobieranie takich danych przez 
przedsiębiorstwa transportowe lub kierowców z minimalnym 
opóźnieniem.  
Pobieranie danych z pliku zawierającego dane szczegółowe 
dotyczące prędkości nie jest konieczne do celów zgodności 
z rozporządzeniem (WE) nr 561/2006, ale może być wyko­
rzystane do innych celów, takich jak dochodzenie w sprawie 
wypadku;  
t) „karta kierowcy” oznacza:  
kartę do tachografu, która identyfikuje kierowcę i umożliwia 
przechowywanie danych dotyczących czynności kierowcy, 
wydaną konkretnemu kierowcy przez organy państwa człon­
kowskiego;  
u) „obwód toczny kół” oznacza:  
wartość średnią długości drogi przebytej przez każde z kół 
(napędowych) poruszającego się pojazdu podczas jednego 
pełnego obrotu. Pomiar tych długości drogi jest wykonywany 
w normalnych warunkach testowych zgodnie z definicją 
w wymaganiu 414 i wyrażony jest w postaci „l = … mm”. 
Producenci pojazdów mogą zastąpić pomiar odległości obli­
czeniem teoretycznym, w którym uwzględnia się rozkład 
ciężaru na osie dla pojazdu bez obciążenia w stanie gotowym 
do jazdy (  1 ). Metody takiego obliczenia teoretycznego podle­
gają zatwierdzeniu przez właściwy organ państwa członkow­
skiego i mogą mieć miejsce tylko przed aktywacją tachografu;  
v) „zdarzenie” oznacza:  
odbiegające od normy działanie wykryte przez tachograf inte­
ligentny, które może być spowodowane próbą oszustwa;  
w) „urządzenie zewnętrzne GNSS” oznacza:  
urządzenie, które zawiera odbiornik GNSS, jeżeli przyrząd 
rejestrujący nie jest pojedynczą jednostką oraz inne elementy 
niezbędne do ochrony przekazywania danych dotyczących 
pozycji do pozostałej części przyrządu rejestrującego;  
x) „usterka” oznacza:  
odbiegające od normy działanie wykryte przez tachograf inte­
ligentny, które może być spowodowane wadliwą pracą lub 
awarią urządzeń;  
y) „odbiornik GNSS” oznacza:  
urządzenie elektroniczne, które odbiera i cyfrowo przetwarza 
sygnały z co najmniej jednego globalnego systemu nawigacji 
satelitarnej (ang.  GNSS ) w celu uzyskania informacji o pozycji, 
prędkości i czasie.  ▼B 
( 1 ) Rozporządzenie Komisji (UE) nr 1230/2012 z dnia 12 grudnia 20 12 r. w sprawie wyko­
nania rozporządzenia (WE) nr 661/2009 Parlamentu Europejskiego i Rady w odniesieniu 
do wymagań w zakresie homologacji typu dotyczących mas i wymiar ów pojazdów 
silnikowych oraz zmieniające dyrektywę 2007/46/WE Parlamentu Eu ropejskiego 
i Rady (Dz.U. L 353 z 21.12.2012, s. 31), z późniejszymi zmiana mi.
 02016R0799 — PL — 21.08.2023 — 003.001 — 19  
z) „instalacja” oznacza:  
montaż tachografu w pojeździe;  
aa) „interoperacyjność” oznacza:  
zdolność systemów oraz będących ich podstawą procesów 
gospodarczych do wymiany danych oraz do wymiany 
informacji;  
bb) „interfejs” oznacza:  
połączenie między systemami, które zapewnia mechanizmy, za 
których pośrednictwem systemy te mogą się łączyć i wchodzić 
w interakcję;  
cc) „pozycja” oznacza:  
współrzędne geograficzne pojazdu w danym momencie;  
dd) „czujnik ruchu” oznacza:  
część tachografu dostarczającą sygnał odzwierciedlający pręd­
kość pojazdu lub przebytą drogę;  
▼M3 
ee) „karta nieważna” oznacza:  
kartę wykrytą jako wadliwa lub kartę, której uwierzytelnienie 
nie jest możliwe lub której okres ważności jeszcze się nie 
rozpoczął lub już upłynął;  
przyrząd rejestrujący uznaje również kartę za nieważną:  
— jeżeli karta z tym samym państwem członkowskim wyda­
jącym kartę, taką samą identyfikacją, tj. identyfikacją 
kierowcy lub identyfikacją właściciela wraz z kolejnym 
numerem karty, oraz z wyższym numerem odnowienia 
została już wprowadzona do przyrządu rejestrującego, lub  
— jeżeli karta z tym samym państwem członkowskim wyda­
jącym kartę, taką samą identyfikacją, tj. identyfikacją 
kierowcy lub identyfikacją właściciela wraz z kolejnym 
numerem karty i numerem odnowienia, ale z wyższym 
numerem wymiany, została już wprowadzona do przyrządu 
rejestrującego;  
▼B 
ff) „otwarty standard” oznacza:  
standard określony w dokumencie specyfikacji standardów 
dostępnym bezpłatnie lub za symboliczną opłatą, który może 
być kopiowany, rozpowszechniany lub wykorzystywany 
bezpłatnie lub za symboliczną opłatą;  
gg) „poza zakresem” oznacza:  
że zgodnie z przepisami rozporządzenia (WE) nr 561/2006 
użycie urządzenia rejestrującego nie jest wymagane;  
hh) „przekroczenie prędkości” oznacza:  
przekroczenie dozwolonej prędkości pojazdu definiowane jako 
dowolny przynajmniej 60-sekundowy okres, w którym zmie­
rzona prędkość pojazdu przekracza wartość ograniczenia dla 
urządzenia ograniczenia prędkości ustanowioną w dyrektywie 
Rady 92/6/EWG z dnia 10 lutego 1992 r. w sprawie monto­
wania i zastosowania urządzeń ograniczenia prędkości 
w niektórych kategoriach pojazdów silnikowych we Wspól­
nocie (  1 ), z późniejszymi zmianami;  ▼B 
( 1 ) Dyrektywa Rady 92/6/EWG z dnia 10 lutego 1992 r. w sprawie mo ntowania i zastoso­
wania urządzeń ograniczenia prędkości w niektórych kategoriach pojazdów silnikowych 
we Wspólnocie (Dz.U. L 57 z 2.3.1992, s. 27).
 02016R0799 — PL — 21.08.2023 — 003.001 — 20  
ii) „przegląd okresowy”oznacza:  
zespół czynności wykonywanych w celu sprawdzenia, czy 
tachograf pracuje prawidłowo, czy jego ustawienia odpowia­
dają parametrom pojazdu i czy do tachografu nie podłączono 
urządzeń manipulacyjnych;  
jj) „drukarka” oznacza:  
element składowy urządzenia rejestrującego wykonujący 
wydruki danych zapisanych w pamięci;  
kk) „wczesne wykrywanie na odległość” oznacza:  
łączność między urządzeniem wczesnego wykrywania na odle­
głość a czytnikiem wczesnego wykrywania na odległość 
podczas ukierunkowanych kontroli drogowych, mającą na 
celu zdalne wykrycie ewentualnych manipulacji lub niewłaści­
wego użycia urządzenia rejestrującego;  
▼M3 
ll) „urządzenie do łączności na odległość”, „moduł komunikacji 
na odległość” lub „urządzenie wczesnego wykrywania na odle­
głość” oznacza:  
wyposażenie przyrządu rejestrującego, które jest używane do 
przeprowadzania ukierunkowanych kontroli drogowych;  
▼B 
mm) „czytnik wczesnego wykrywania na odległość” oznacza:  
system stosowany przez funkcjonariuszy służb kontrolnych do 
ukierunkowanych kontroli drogowych;  
▼M3 
nn) „odnowienie karty” oznacza:  
wydanie nowej karty do tachografu po upływie terminu 
ważności dotychczasowej karty lub w przypadku nieprawidło­
wego działania karty i zwrócenia jej organowi wydającemu 
kartę;  
▼B 
oo) „naprawa” oznacza:  
każdą naprawę czujnika ruchu lub przyrządu rejestrującego lub 
przewodu, wymagającą odłączenia zasilania lub odłączenia od 
innych elementów składowych tachografu lub otwarcia czuj­
nika ruchu lub przyrządu rejestrującego;  
▼M3 
pp) „wymiana karty” oznacza:  
wydanie nowej karty do tachografu w celu zastąpienia dotych­
czasowej karty, której utratę, kradzież lub wadliwe działanie 
zgłoszono i której nie zwrócono organowi, który wydał kartę;  
▼B 
qq) „certyfikacja bezpieczeństwa” oznacza:  
procedurę polegającą na potwierdzeniu przez jednostkę certy­
fikującą wspólnych kryteriów, że badane urządzenie rejestru­
jące (lub jego element składowy) lub karta do tachografu speł­
niają wymogi bezpieczeństwa określone w odpowiednich 
profilach zabezpieczenia;  
rr) „autotest” oznacza:  
testy wykonywane okresowo i automatycznie przez urządzenie 
rejestrujące w celu wykrycia usterek;  
ss) „pomiar czasu” oznacza:  
trwały cyfrowy zapis uniwersalnej daty koordynowanej 
i uniwersalnego czasu koordynowanego (UTC);  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 21  
tt) „korekta czasu” oznacza:  
korektę bieżącego czasu; może ona być automatyczna z wyko­
rzystaniem czasu podawanego przez odbiornik GNSS jako 
odniesienia lub wykonywana w trybie kalibracyjnym;  
▼B 
uu) „rozmiar opon” oznacza:  
oznaczenie wymiarów opon (na zewnętrznych kołach napędo­
wych) zgodne z dyrektywą Rady 92/23/EWG z dnia 31 marca 
1992 r. (  1 ) z późniejszymi zmianami;  
vv) „identyfikacja pojazdu” oznacza:  
numery identyfikujące pojazd: numer rejestracyjny pojazdu 
(VRN) z oznaczeniem państwa członkowskiego rejestracji 
i numer identyfikacyjny pojazdu (VIN) (  2 ); 
ww) na potrzeby obliczeniowe w urządzeniu rejestrującym 
„tydzień”oznacza:  
okres między godziną 00.00 UTC w poniedziałek a 24.00 
UTC w niedzielę;  
xx) „karta warsztatowa” oznacza:  
kartę do tachografu wydaną przez organy państwa członkow­
skiego wyznaczonemu personelowi producenta tachografu, 
instalatorowi, producentowi pojazdu lub warsztatowi zatwier­
dzonemu przez to państwo członkowskie, która identyfikuje 
posiadacza karty i umożliwia testowanie, kalibrację i aktywację  
tachografów lub pobieranie z nich danych;  
yy) „adapter” oznacza:  
urządzenie dostarczające sygnał w sposób ciągły odwzorowu­
jący prędkość pojazdu lub przebytą drogę, inne niż urządzenie 
stosowane do niezależnego wykrywania ruchu, oraz:  
▼M3 
— które jest zainstalowane i stosowane wyłącznie w pojazdach 
kategorii M1 i N1, określonych w art. 4 rozporządzenia 
Parlamentu Europejskiego i Rady (UE) 2018/858 (  3 ), 
▼B 
— które jest zainstalowane w miejscu, w którym z mechanicz­
nego punktu widzenia niemożliwy jest montaż stosowa­
nych czujników ruchu innego rodzaju, pod innym 
względem zgodnych z wymaganiami przedstawionymi 
w niniejszym załączniku i w dodatkach 1–15 do niniej­
szego załącznika,  ▼M3 
( 1 ) Dyrektywa Rady 92/23/EWG z dnia 31 marca 1992 r. odnosząca si ę do opon pojazdów 
silnikowych i ich przyczep oraz ich instalowania (Dz.U. L 129 z  14.5.1992, s. 95). 
( 2 ) Dyrektywa Rady z dnia 18 grudnia 1975 r. w sprawie zbliżania ustawodawstw Państw 
Członkowskich odnoszących się do tabliczek znamionowych i oznak owania identyfika­
cyjnego pojazdów silnikowych i ich przyczep oraz sposobu i miej sca ich umieszczania 
(Dz.U. L 24 z 30.1.1976, s. 1). 
( 3 ) Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2018/858 z dnia 30 maja 2018 r. 
w sprawie homologacji i nadzoru rynku pojazdów silnikowych i ic h przyczep oraz 
układów, komponentów i oddzielnych zespołów technicznych przezn aczonych do tych 
pojazdów, zmieniające rozporządzenie (WE) nr 715/2007 i (WE) nr  595/2009 oraz 
uchylające dyrektywę 2007/46/WE (Dz.U. L 151 z 14.6.2018, s. 1) .
 02016R0799 — PL — 21.08.2023 — 003.001 — 22  
— które jest zainstalowane między przyrządem rejestrującym 
a miejscem, gdzie generowane są impulsy prędkości/drogi 
przez zintegrowane czujniki lub alternatywne interfejsy,  
— z punktu widzenia przyrządu rejestrującego zachowanie 
adaptera jest takie samo jak czujnika ruchu zgodnego 
z wymaganiami w niniejszym załączniku i w dodatkach 
1–16 do niniejszego załącznika, w przypadku podłączenia 
go do przyrządu rejestrującego;  
zastosowanie takiego adaptera w wymienionych wyżej pojaz­
dach musi umożliwiać montaż i poprawne zastosowanie przy­
rządu rejestrującego, zgodnego ze wszystkimi wymaganiami 
niniejszego załącznika,  
w przypadku tych pojazdów tachograf inteligentny obejmuje 
przewody, adapter i przyrząd rejestrujący;  
zz) „integralność danych” oznacza:  
dokładność i spójność przechowywanych danych, których 
potwierdzeniem jest brak jakichkolwiek zmian w danych między 
dwoma aktualizacjami rekordu danych. Integralność oznacza, że 
dane są dokładną kopią wersji oryginalnej, np. że nie zostały z nie­
kształcone w trakcie zapisu na karcie do tachografu lub urzą­
dzeniu dedykowanym lub w trakcie odczytu z nich lub w trakcie 
transmisji za pośrednictwem dowolnego kanału komunikacji;  
▼M3 
aaa) zarezerwowane dla przyszłego użytku;  
▼B 
bbb) „system tachografu inteligentnego” oznacza:  
urządzenia rejestrujące, karty do tachografów oraz zestaw 
wszelkich urządzeń współdziałających bezpośrednio lub 
pośrednio podczas ich budowy, instalacji, użytkowania, testo­
wania i kontroli, takich jak karty, czytniki na odległość 
i wszelkie inne urządzenia do pobierania danych, analizy 
danych, kalibracji, generowania i wprowadzania elementów 
zabezpieczeń lub zarządzania tymi elementami itp.;  
▼M3 
ccc) „data wprowadzenia” oznacza:  
datę określoną w rozporządzeniu (UE) nr 165/2014, od której 
pojazdy zarejestrowane po raz pierwszy są wyposażone 
w tachograf zgodnie z niniejszym rozporządzeniem.  
▼B 
ddd) „profil zabezpieczenia” oznacza:  
dokument używany w ramach procesu certyfikacyjnego zgodnie 
ze wspólnymi kryteriami, który określa niezależne od wdrożenia 
specyfikacje wymogów bezpieczeństwa w zakresie zabezpie­
czania informacji;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 23  
eee) dokładność GNSS:  
w zapisywaniu pozycji z globalnego systemu nawigacji sateli­
tarnej (GNSS) z użyciem tachografów, oznacza wartość Hori­
zontal Dilution of Precision (HDOP) obliczaną jako najniższa 
z wartości HDOP pobranych z dostępnych systemów GNSS ;  
▼M1 
(fff) „skumulowany czas prowadzenia pojazdu” oznacza:  
wartość odpowiadającą łącznej skumulowanej liczbie minut 
prowadzenia danego pojazdu.  
Wartość skumulowanego czasu prowadzenia pojazdu to 
nieprzerwana liczba wszystkich minut uznanych przez funkcję 
monitorowania czynności prowadzenia pojazdu urządzenia 
rejestrującego za PROWADZENIE POJAZDU i jest wykorzy­
stywana wyłącznie do uruchomienia rejestracji pozycji pojazdu 
za każdym razem, gdy upłynie wielokrotność trzech godzin 
skumulowanego czasu prowadzenia pojazdu. Skumulowany 
czas zaczyna biec w momencie uruchomienia urządzenia rejes­
trującego. Nie mają na niego wpływu jakiekolwiek inne 
warunki, np. poza zakresem lub przeprawa promowa/przejazd 
kolejowy.  
Nie przewiduje się wyświetlania, drukowania lub pobierania 
skumulowanego czasu prowadzenia pojazdu.  
▼B 
2 CHARAKTERYSTYKA OGÓLNA I FUNKCJE URZĄDZEŃ 
REJESTRUJĄCYCH  
2.1 Charakterystyka ogólna  
Celem urządzenia rejestrującego jest rejestrowanie, przechowy­
wanie, wyświetlanie, drukowanie i wyprowadzanie danych związa­
nych z czynnościami kierowcy.  
Pojazd wyposażony w urządzenie rejestrujące spełniające wyma­
gania niniejszego załącznika musi mieć prędkościomierz i liczni k 
kilometrów. Funkcje te może spełniać urządzenie rejestrujące.  
01) Urządzenie rejestrujące składa się z przewodów, czujnika 
ruchu i przyrządu rejestrującego.  
02) Interfejs między czujnikami ruchu i przyrządami rejestrują­
cymi musi być zgodny z wymogami określonymi 
w dodatku 11.  
03) Przyrząd rejestrujący musi być podłączony do globalnego(- 
ych) systemu(-ów) nawigacji satelitarnej, jak określono 
w dodatku 12.  
04) Przyrząd rejestrujący musi łączyć się z czytnikami wczes­
nego wykrywania na odległość, jak określono w dodatku 14.  
▼M3 
05) Przyrząd rejestrujący musi obejmować interfejs ITS, który 
został określony w dodatku 13.  
Urządzenie rejestrujące może być podłączone do innych 
urządzeń poprzez dodatkowe interfejsy lub poprzez interfejs 
ITS. ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 24  
06) Zawarcie w urządzeniu rejestrującym lub przyłączenie do 
niego jakiejkolwiek funkcji, urządzenia lub urządzeń, 
zatwierdzonych lub nie, nie może zakłócać, ani potencjalnie 
zakłócać, prawidłowego i bezpiecznego działania urzą­
dzenia rejestrującego ani uchybiać przepisom niniejszego 
rozporządzenia.  
Użytkowników urządzenia rejestrującego identyfikują 
w sprzęcie ich karty do tachografów.  
07) Urządzenie rejestrujące zapewnia selektywne prawa dostępu 
do danych i funkcji zależnie od rodzaju lub tożsamości 
użytkownika.  
Urządzenie rejestrujące rejestruje i przechowuje dane w pamięci  
danych, w urządzeniu do łączności na odległość i na kartach do 
tachografów.  
▼M3 
Odbywa się to zgodnie z mającymi zastosowanie przepisami Unii 
dotyczącymi ochrony danych oraz zgodnie z art. 7 rozporzą­
dzenia (UE) nr 165/2014.  
▼B 
2.2 Funkcje  
08) Urządzenie rejestrujące realizuje następujące funkcje:  
— monitorowanie wkładania i wyjmowania kart,  
— pomiar prędkości, odległości i pozycji,  
— pomiar czasu,  
— monitorowanie czynności kierowcy,  
— monitorowanie stanu prowadzenia pojazdu,  
▼M3 
— dane wprowadzane ręcznie przez kierowcę:  
— wprowadzanie miejsc rozpoczęcia lub zakończenia 
dziennych okresów pracy,  
— ręczne wprowadzanie czynności kierowcy i zgody 
kierowcy na interfejs ITS,  
— wprowadzanie stanów szczególnych,  
— wprowadzanie operacji załadunku/rozładunku,  
▼B 
— zarządzanie blokadami firmowymi,  
— monitorowanie czynności kontrolnych,  
— wykrywanie zdarzeń lub usterek,  
— testy wbudowane i autotesty,  
— odczyt z pamięci danych,  
— rejestrowanie i przechowywanie w pamięci danych,  
— odczyt z kart do tachografów,  
— rejestrowanie i przechowywanie na kartach do tacho­
grafów,  
— wyświetlanie,  
— drukowanie,  
— ostrzeganie,  
— pobieranie danych na nośniki zewnętrzne,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 25  
— łączność na odległość na potrzeby ukierunkowanych 
kontroli drogowych,  
— wyprowadzanie danych do dodatkowych urządzeń,  
— kalibracja,  
— kontrola drogowa kalibracji,  
— korekta czasu,  
▼M3 
— monitorowanie przekroczeń granicy,  
— aktualizacja oprogramowania.  
▼B 
2.3 Tryby pracy  
09) Urządzenie rejestrujące może pracować w czterech trybach 
pracy:  
— tryb eksploatacyjny,  
— tryb kontrolny,  
— tryb kalibracyjny,  
— tryb firmowy.  
10) Urządzenie rejestrujące przełącza się do następujących 
trybów pracy zależnie od rodzaju ważnej karty do tacho­
grafów włożonej do czytników kart. Do określenia trybu 
pracy nie jest istotna generacja karty do tachografu, pod 
warunkiem że włożona karta jest ważna. Karta warsztatowa 
pierwszej generacji będzie zawsze uznawana za nieważną, 
jeżeli zostanie włożona do przyrządu rejestracyjnego 
drugiej generacji.  
Tryb pracy  Czytnik karty kierowcy  
Brak karty  Karta kierowcy  Karta kontrolna  Karta warsztatowa  Karta firmowa
 Czytnik karty współkierowcy 
Brak karty  eksploatacyjny  eksploatacyjny  kontrolny  kalibracyjny  firmowy  
Karta kierowcy  eksploatacyjny  eksploatacyjny  kontrolny  kalibracyjny  firmowy  
Karta kontrolna  kontrolny  kontrolny  kontrolny (*)  eksploatacyjny  eksploatacyjny  
Karta warsz­
tatowa  kalibracyjny  kalibracyjny  eksploatacyjny  kalibracyjny (*)  eksploatacyjny  
Karta firmowa  firmowy  firmowy  eksploatacyjny  eksploatacyjny  firmowy (*)  
(*) W tych sytuacjach urządzenie rejestrujące korzysta tylko z karty do tachografów w czytniku kierowcy.  
11) Urządzenie rejestrujące ignoruje włożone karty nieważne, 
z wyjątkiem tego, że możliwe jest wyświetlanie, druko­
wanie lub pobieranie danych zgromadzonych na kartach, 
których termin ważności minął.  
12) Wszystkie funkcje wymienione w 2.2. działają w każdym 
trybie pracy z następującymi wyjątkami:  
— funkcja kalibracji dostępna jest tylko w trybie 
kalibracyjnym,  
— funkcja kontroli drogowej kalibracji dostępna jest tylko 
w trybie kontrolnym,  
— funkcja zarządzania blokadami firmowymi dostępna jest 
tylko w trybie firmowym,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 26  
— funkcja monitorowania czynności kontrolnych dostępna 
jest tylko w trybie kontrolnym,  
▼M3 
— funkcja pobierania danych nie jest dostępna w trybie 
eksploatacyjnym, z wyjątkiem:  
a) funkcji przewidzianej w wymogu 193;  
b) pobierania danych z karty kierowcy, gdy żadna inna 
karta nie jest włożona do przyrządu rejestrującego.  
▼B 
13) Urządzenie rejestrujące może wyprowadzać dane na 
wyświetlacz, do drukarki lub interfejsów zewnętrznych 
z następującymi wyjątkami:  
— w trybie eksploatacyjnym wszystkie dane identyfikujące 
osoby (nazwisko i imię/imiona) nieodpowiadające 
włożonej karcie do tachografu są wygaszone, a numer 
karty nieodpowiadający włożonej karcie do tachografu 
jest częściowo wygaszony (wszystkie nieparzyste znaki 
od lewej do prawej są wygaszone),  
▼M3 
— w trybie firmowym, dane dotyczące kierowcy (wymogi 
102, 105, 108, 133a i 133e) mogą być wyprowadzane 
tylko dla okresów, w których nie ma żadnej blokady ani 
żadna inna firma nie założyła blokady (określona pierw­
szymi 13 cyframi numeru karty firmowej),  
▼B 
— przy braku karty w czytniku urządzenia rejestrującego 
dane dotyczące kierowcy mogą być wyprowadzane 
tylko dla bieżącego dnia kalendarzowego i 8 poprzed­
nich dni kalendarzowych,  
▼M3 
— dane osobowe zarejestrowane i wytworzone przez 
tachograf lub karty do tachografu nie są generowane 
przez interfejs ITS przyrządu rejestrującego, chyba że 
zweryfikowano zgodę kierowcy, którego dane dotyczą.  
▼M1 
— normalny okres ważności operacji przyrządów rejestru­
jących wynosi 15 lat, począwszy od daty wejścia 
w życie świadectwa przyrządu rejestrującego, ale przy­
rządy rejestrujące mogą być wykorzystywane przez 
kolejne 3 miesiące wyłącznie do pobierania danych.  
▼B 
2.4 Zabezpieczenia  
▼M1 
Celem zabezpieczenia systemu jest taka ochrona pamięci danych, by 
uniemożliwić nieautoryzowany dostęp i manipulowanie danymi oraz  
wykrycie wszelkich takich prób, ochrona integralności i autenty cz­
ności danych wymienianych między czujnikiem ruchu a przyrządem 
rejestrującym, ochrona integralności i autentyczności danych 
wymienianych między urządzeniem rejestrującym a kartami do 
tachografów, ochrona integralności i autentyczności danych wymi e­
nianych między przyrządem rejestrującym a ewentualnym urządze­
niem zewnętrznym GNSS, ochrona poufności, integralności i auten ­
tyczności danych wymienianych w ramach wczesnego wykrywania 
na odległość na potrzeby kontroli oraz sprawdzenie integralnośc i 
i autentyczności pobieranych danych.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 27  
14) W celu osiągnięcia bezpieczeństwa systemu, następujące 
elementy składowe muszą spełniać wymogi bezpieczeństwa 
określone w ich profilach zabezpieczenia, zgodnie z wyma­
ganiami w dodatku 10:  
— przyrząd rejestrujący,  
— karta do tachografu,  
— czujnik ruchu,  
▼M3 
— urządzenie zewnętrzne GNSS (profil ten jest tylko 
konieczny i stosowany do wariantu urządzenia 
zewnętrznego GNSS).  
▼B 
3 WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE URZĄ­
DZEŃ REJESTRUJĄCYCH  
3.1 Monitorowanie wk ładania i wyjmowania kart  
15) Urządzenie rejestrujące monitoruje czytniki kart w celu 
wykrycia wkładania i wyjmowania kart.  
▼M3 
16) Po włożeniu karty (lub zdalnym uwierzytelnieniu karty) 
urządzenie rejestrujące wykrywa, czy karta jest ważną 
kartą do tachografu zgodnie z definicją w lit. ee) w sekcji 
1, i w takim przypadku identyfikuje typ karty i generację 
karty.  
W celu sprawdzenia, czy karta została już włożona, urzą­
dzenie rejestrujące wykorzystuje dane karty do tachografu 
zapisane w jego pamięci danych, jak określono w wymogu 
133. 
▼B 
17) Karty do tachografu pierwszej generacji są uznawane przez 
urządzenie rejestrujące za nieważne, po tym jak możliwość 
korzystania z kart do tachografu pierwszej generacji została 
wyłączona przez warsztat, zgodnie z dodatkiem 15 (wym. 
MIG003).  
18) Karty warsztatowe pierwszej generacji wkładane do urzą­
dzeń rejestrujących drugiej generacji są uznawane za 
nieważne.  
19) Urządzenie rejestrujące musi być skonstruowane tak, aby 
po prawidłowym włożeniu do czytnika kart do tachografów 
były one blokowane we właściwej pozycji.  
▼M3 
20) wyjmowanie kart do tachografów jest możliwe tylko przy 
zatrzymanym pojeździe i po zapisaniu odpowiednich 
danych na kartach. Wyjęcie karty wymaga wykonania 
przez użytkownika odpowiedniej czynności.  
▼B 
3.2 Pomiar pr ędkości, pozycji i odleg łości 
21) Czujnik ruchu (ewentualnie wbudowany w adapter) jest 
głównym źródłem pomiaru prędkości i odległości.  
22) Funkcja ta nieprzerwanie mierzy i dostarcza wartość stanu 
licznika kilometrów odpowiadającą całkowitej drodze prze­
bytej przez pojazd za pomocą impulsów przekazywanych 
przez czujnik ruchu.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 28  
23) Funkcja ta nieprzerwanie mierzy i dostarcza wartość pręd­
kości pojazdu za pomocą impulsów przekazywanych przez 
czujnik ruchu.  
24) Funkcja pomiaru prędkości podaje także informacje o tym, 
czy pojazd porusza się, czy stoi. Uznaje się, że pojazd 
porusza się, gdy funkcja ta wykrywa więcej niż 1 impuls 
na sekundę z czujnika ruchu przez co najmniej 5 sekund, 
w przeciwnym razie uważa się, że pojazd stoi.  
25) Urządzenia do pokazywania prędkości (prędkościomierz) 
i łącznej drogi przebytej (licznik kilometrów) zainstalowane 
w pojeździe wyposażonym w urządzenie rejestrujące, speł­
niające wymagania niniejszego rozporządzenia, spełniają 
wymagania odnośnie do maksymalnych tolerancji (zob. 
3.2.1 i 3.2.2) określone w niniejszym załączniku.  
▼M3 
26) W celu wykrycia manipulowania danymi dotyczącymi 
ruchu informacje z czujnika ruchu są potwierdzane przez 
informacje dotyczące ruchu pojazdu pochodzące z odbior­
nika GNSS i z innych źródeł niezależnych od czujnika 
ruchu. Co najmniej jeszcze jedno niezależne źródło ruchu 
pojazdu musi znajdować się wewnątrz przyrządu rejestrują­
cego bez konieczności korzystania z interfejsu zewnętrz­
nego.  
27) Funkcja ta mierzy pozycję pojazdu w celu umożliwienia 
rejestracji:  
— pozycji, w których kierowca lub współkierowca rozpo­
czynają dzienny okres pracy;  
— pozycji, w których skumulowany czas prowadzenia 
pojazdu osiągnie wielokrotność trzech godzin;  
— pozycji, w których pojazd przekroczył granicę krajową;  
— pozycji, w których przeprowadzono operacje załadunku/ 
rozładunku;  
— pozycji, w których kierowca lub współkierowca kończą 
dzienny okres pracy.  
▼B 
3.2.1  Pomiar przebytej drogi  
28) Długość przebytej drogi może być mierzona, gdy pojazd 
porusza się:  
— do przodu i do tyłu, albo  
— tylko do przodu.  
29) Urządzenie rejestrujące mierzy odległość w zakresie 
0–9 999 999,9 km.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 29  
30) Pomiar odległości jest wykonywany z następującą dokład­
nością (odległości co najmniej 1 000 m):  
— ± 1 % przed instalacją,  
— ± 2 % po instalacji i przeglądzie okresowym,  
— ± 4 % podczas eksploatacji.  
▼M3 
Tolerancji nie można wykorzystywać do celowej zmiany 
zmierzonej odległości.  
▼B 
31) Pomiar odległości jest wykonywany z rozdzielczością co 
najmniej 0,1 km lub większą.  
3.2.2  Pomiar pr ędkości 
32) Urządzenie rejestrujące mierzy prędkość w zakresie od 0 do 
220 km/h.  
▼M3 
33) W celu zapewnienia maksymalnej tolerancji wskazywanej 
prędkości ± 6 km/h podczas eksploatacji i uwzględniając:  
— tolerancję ± 2 km/h na zmiany sygnału wejściowego 
(zmiany opon, …),  
— tolerancję ± 1 km/h dla pomiarów wykonywanych 
w czasie instalacji lub przeglądów okresowych,  
urządzenie rejestrujące, dla zakresu prędkości między 20 
a 180 km/h i dla współczynników charakterystycznych 
pojazdu między 2 400 a 25 000 impulsów na km, mierzy 
prędkość z dokładnością ± 1 km/h (przy stałej prędkości).  
Uwaga: Rozdzielczość przechowywania danych wprowadza 
dodatkową tolerancję ± 0,5 km/h do prędkości zapisanej 
przez urządzenie rejestrujące.  
▼B 
34) Prędkość jest mierzona prawidłowo w zakresie normalnych 
tolerancji w czasie nie dłuższym niż 2 sekundy od zakoń­
czenia zmiany prędkości, jeżeli prędkość zmieniła się 
w tempie 2 m/s  2 . 
35) Pomiar prędkości jest wykonywany z dokładnością co 
najmniej 1 km/h lub wyższą.  
3.2.3  Pomiar pozycji  
36) Urządzenie rejestrujące mierzy bezwzględną pozycję 
pojazdu za pomocą odbiornika GNSS.  
▼M3 
37) Bezwzględną pozycję mierzy się we współrzędnych szero­
kości i długości geograficznej, w stopniach i minutach, 
z dokładnością do 1/10 minuty.  
▼B 
3.3 Pomiar czasu  
38) Funkcja pomiaru czasu mierzy czas nieprzerwanie i cyfrowo 
podaje czas UTC.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 30  
39) Do datowania w urządzeniu rejestrującym (rejestracja, 
wymiana danych) i do wszystkich wydruków wymienio­
nych w dodatku 4 „Wydruki” używany jest czas UTC.  
40) W celu wizualizacji czasu lokalnego możliwa jest zmiana 
przesunięcia wyświetlanego czasu skokowo co pół godziny. 
Nie dopuszcza się innych przesunięć poza przesunięciami 
wstecz lub do przodu o wielokrotność połowy godziny;  
▼M3 
41) Dryft czasu musi wynosić ± 1 sekundę dziennie lub mniej, 
w warunkach temperaturowych zgodnie z wymogiem 213, 
przy braku korekty czasu.  
41a) Dokładność czasu, gdy czas jest korygowany przez warsz­
taty zgodnie z wymogiem 212, jest na poziomie 3 sekund 
lub lepszym.  
41b) Przyrząd rejestrujący musi zawierać dryftomierz, który 
wylicza maksymalny dryft czasu od ostatniej korekty 
czasu zgodnie z pkt 3.23. Maksymalny dryft czasu jest 
określany przez producenta przyrządu rejestrującego i nie 
może przekraczać 1 sekundy dziennie, jak określono 
w wymogu 41.  
41c) Dryftomierz ustawia się ponownie na 1 sekundę po każdej 
korekcie czasu urządzenia rejestrującego zgodnie z pkt 3.23. 
Obejmuje to:  
— automatyczne korekty czasu,  
— korekty czasu wykonywane w trybie kalibracyjnym.  
▼B 
42) Pomiar czasu jest wykonywany z dokładnością co najmniej 
1 sekundy lub większą.  
43) Odcięcie zewnętrznego źródła zasilania na czas nie krótszy 
niż 12 miesięcy w warunkach homologacyjnych nie może 
wpływać na pomiar czasu.  
3.4 Monitorowanie czynno ści kierowcy  
44) Funkcja ta nieprzerwanie i odrębnie monitoruje czynności 
jednego kierowcy i jednego współkierowcy.  
45) Czynnościami kierowcy są PROWADZENIE, PRACA, 
GOTOWOŚĆ lub PRZERWA/ODPOCZYNEK.  
46) Kierowca lub współkierowca mogą ręcznie wybierać 
PRACĘ, GOTOWOŚĆ lub PRZERWĘ/ODPOCZYNEK.  
47) Gdy pojazd porusza się następuje automatyczne wybór 
czynności PROWADZENIE dla kierowcy i GOTOWOŚĆ 
dla współkierowcy.  
48) Gdy pojazd zatrzymuje się, następuje automatyczne 
wybranie czynności PRACA dla kierowcy.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 31  
49) Jeżeli w czasie 120 sekund od automatycznej zmiany na 
PRACĘ, wskutek zatrzymania pojazdu, nastąpi zmiana 
czynności na PRZERWA/ODPOCZYNEK lub GOTO­
WOŚĆ, przyjmuje się, że pierwsza taka zmiana zaistniała 
w czasie postoju pojazdu (w ten sposób można anulować 
zmianę czynności na PRACA).  
▼B 
50) Funkcja ta przekazuje zmiany czynności do funkcji rejes­
trującej w odstępach co jedną minutę.  
51) W danej minucie zegarowej, jeżeli PROWADZENIE jest 
zarejestrowane jako czynność w minucie bezpośrednio ją 
poprzedzającej i następującej bezpośrednio po niej, to 
cała ta minuta liczy się jako PROWADZENIE.  
52) W danej minucie zegarowej, nietraktowanej jako PROWA­
DZENIE zgodnie z wymaganiem 051, cała taka minuta 
liczy się jako jedna czynność, która trwała najdłużej 
w ciągu tej minuty (lub była najpóźniejsza w przypadku 
czynności o jednakowym czasie trwania).  
53) Funkcja ta także nieprzerwanie monitoruje zarówno 
nieprzerwany czas prowadzenia pojazdu, jak i skumulowany 
czas przerwy dla kierowcy.  
3.5 Monitorowanie stanu prowadzenia pojazdu  
54) Funkcja ta nieprzerwanie i automatycznie monitoruje stan 
prowadzenia pojazdu.  
55) Po włożeniu dwóch ważnych kart kierowcy wybierany jest 
stan prowadzenia pojazdu ZAŁOGA, w każdym innym 
przypadku wybierany jest stan prowadzenia pojazdu 
JEDEN KIEROWCA.  
3.6 Dane wprowadzane przez kierowców  
3.6.1  Wprowadzanie miejsca rozpocz ęcia lub zako ńczenia okresu pracy  
56) Funkcja ta umożliwia wprowadzanie miejsc, gdzie według 
kierowcy lub współkierowcy rozpoczyna się lub kończy 
dzienny okres pracy.  
▼M3 
57) Miejsca definiuje się jako kraj i dodatkowo, gdy stosowne, 
region.  
58) Po wyjęciu karty kierowcy (lub warsztatowej) urządzenie 
rejestrujące wyświetla bieżące miejsce pojazdu na 
podstawie informacji GNSS i zapisanej mapy cyfrowej 
zgodnie z pkt 3.12.19 oraz zwraca się do posiadacza 
karty o potwierdzenie lub ręczne sprostowanie miejsca.  
59) Miejsce wpisane zgodnie z wymogiem 58 uważa się za 
miejsce zakończenia dziennego okresu pracy. Rejestruje 
się je na stosownej karcie kierowcy (lub karcie warsz­
tatowej) jako zapis tymczasowy i w związku z tym może 
być później nadpisane.  
W poniższych warunkach wpis tymczasowy wykonany 
przy ostatnim wyjęciu karty zostaje zatwierdzony (tj. nie 
będzie go już można nadpisać):  
— wpis miejsca, w którym rozpoczyna się bieżący dzienny 
okres pracy, w trakcie ręcznego wprowadzania zgodnie 
z wymogiem 61;  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 32  
— następny wpis miejsca, w którym rozpoczyna się 
bieżący dzienny okres pracy, jeśli posiadacz karty nie 
wpisze żadnego miejsca rozpoczęcia lub zakończenia 
okresu pracy w trakcie ręcznego wprowadzania zgodnie 
z wymogiem 61.  
W poniższych warunkach wpis tymczasowy wykonany 
przy ostatnim wyjęciu karty jest nadpisywany i zatwier­
dzona zostaje nowa wartość:  
— następny wpis miejsca, w którym kończy się bieżący 
dzienny okres pracy, jeśli posiadacz karty nie wpisze 
żadnego miejsca rozpoczęcia lub zakończenia okresu 
pracy w trakcie ręcznego wprowadzania zgodnie 
z wymogiem 61.  
▼B 
60) Możliwe jest wprowadzenie miejsca rozpoczęcia lub zakoń­
czenia dziennego okresu pracy przez wybranie polecenia 
w menu. Jeżeli w ciągu jednej minuty zegarowej wydane 
zostaje więcej poleceń niż jedno, zarejestrowane zostaje 
tylko ostatnie miejsce rozpoczęcia i ostatnie miejsce zakoń­
czenia wybrane w tym czasie.  
▼M3 
Urządzenie rejestrujące wyświetla bieżące miejsce pojazdu 
na podstawie informacji GNSS i zapisanych map cyfro­
wych zgodnie z pkt 3.12.19 oraz zwraca się do kierowcy 
o potwierdzenie lub ręczne sprostowanie miejsca.  
▼B 
3.6.2  R ęczne wprowadzanie czynno ści kierowcy i zgoda kierowcy na 
interfejs ITS  
▼M3 
61) Po włożeniu karty kierowcy (lub warsztatowej), i tylko 
w tym czasie, urządzenie rejestrujące umożliwia ręczne 
wprowadzanie czynności. Ręczne wprowadzanie czynności 
wykonuje się, stosując lokalny czas i datę strefy czasowej 
(przesunięcie UTC) aktualnie ustawione w przyrządzie 
rejestrującym.  
Po włożeniu karty kierowcy lub warsztatowej przyrząd 
rejestrujący przypomina posiadaczowi karty:  
— datę i godzinę ostatniego wyjęcia jego karty;  
— opcjonalnie: przesunięcie czasu lokalnego aktualnie 
ustawionego w przyrządzie rejestrującym.  
Przy pierwszym włożeniu danej karty kierowcy lub warsz­
tatowej, nieznanej przyrządowi rejestrującemu, posiadacz 
karty jest proszony o wyrażenie zgody na wyprowadzenie 
danych osobowych związanych z tachografem poprzez 
interfejs ITS. W celu sprawdzenia, czy karta została już 
włożona, urządzenie rejestrujące wykorzystuje dane karty 
do tachografu zapisane w jego pamięci danych, jak okre­ 
ślono w wymogu 133.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 33  
W dowolnym momencie istnieje możliwość potwierdzenia 
lub wycofania zgody kierowcy (ew. warsztatu) przez 
wybranie polecenia w menu, pod warunkiem że karta 
kierowcy (lub warsztatowa) jest włożona.  
Wprowadzanie czynności jest możliwe z następującymi 
ograniczeniami:  
— rodzajem czynności musi być PRACA, GOTOWOŚĆ 
lub PRZERWA/ODPOCZYNEK;  
— godzina rozpoczęcia i zakończenia każdej czynności 
zawarta jest wyłącznie w okresie między ostatnim wyję­
ciem a bieżącym włożeniem karty;  
— niedopuszczalne jest nakładanie się na siebie w czasie 
okresów wykonywania tych czynności.  
W razie potrzeby możliwe jest ręczne wprowadzanie czyn­
ności przy pierwszym włożeniu uprzednio nieużywanej 
karty kierowcy (lub warsztatowej).  
Procedura ręcznego wprowadzania czynności zawiera tyle 
kolejnych etapów, ile jest konieczne do ustawienia rodzaju 
każdej czynności, godziny jej rozpoczęcia i godziny jej 
zakończenia. Dla całego okresu między ostatnim wyjęciem 
a bieżącym włożeniem karty posiadacz karty może nie 
zgłaszać żadnej czynności.  
Podczas ręcznego wprowadzania danych związanego 
z włożeniem karty, posiadacz karty ma, w stosownych 
przypadkach, możliwość wprowadzenia:  
— miejsca, w którym zakończył się poprzedni dzienny 
okres pracy powiązany z odnośnym czasem (czyli 
nadpisania i zatwierdzenia wpisu przy ostatnim wyjęciu 
karty);  
— miejsca, w którym rozpoczyna się bieżący dzienny 
okres pracy powiązany z odnośnym czasem (czyli 
zatwierdzenia wpisu tymczasowego przy ostatnim 
wyjęciu karty).  
W przypadku miejsca wprowadzonego przy bieżącym 
włożeniu karty jako miejsce, w którym rozpoczyna się 
bieżący dzienny okres pracy, urządzenie rejestrujące 
wyświetla bieżące miejsce pojazdu na podstawie informacji 
GNSS i zapisanych map cyfrowych zgodnie z pkt 3.12.19 
oraz zwraca się do kierowcy o potwierdzenie lub ręczne 
sprostowanie miejsca.  
Jeżeli posiadacz karty nie wprowadzi miejsca rozpoczęcia 
lub zakończenia okresu pracy podczas ręcznego wprowa­
dzania danych związanego z włożeniem karty, będzie to 
równoważne z potwierdzeniem, że okres pracy nie zmienił 
się od ostatniego wyjęcia karty. Kolejne wprowadzenie 
miejsca zakończenia poprzedniego dziennego okresu pracy 
nadpisze wówczas wpis tymczasowy wprowadzony przy 
ostatnim wyjęciu karty.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 34  
Jeżeli wprowadza się miejsce, rejestruje się je na stosownej 
karcie do tachografu.  
Ręczne wprowadzanie zostaje przerwane, jeżeli:  
— karta zostaje wyjęta lub  
— pojazd porusza się, a karta znajduje się w czytniku 
karty kierowcy.  
Dozwolone są dodatkowe przerwy, np. przekroczenie 
dozwolonego czasu po pewnym okresie braku aktywności 
użytkownika. Jeżeli ręczne wprowadzanie zostanie prze­
rwane, urządzenie rejestrujące dokonuje walidacji wszyst­
kich kompletnych miejsc i czynności (mających przypisane 
jednoznaczne miejsce i godzinę lub rodzaj czynności, 
godzinę rozpoczęcia i godzinę zakończenia).  
Jeżeli podczas ręcznego wprowadzania czynności dla 
wcześniej włożonej karty zostanie włożona karta drugiego 
kierowcy lub karta warsztatowa, dopuszcza się uzupełnienie 
ręcznego wprowadzania dla karty włożonej wcześniej przed 
rozpoczęciem ręcznego wprowadzania dla drugiej karty.  
Posiadacz karty ma możliwość ręcznego wprowadzenia 
zgodnie z następującą procedurą minimalną:  
— Ręczne wprowadzenie czynności w kolejności chrono­
logicznej w okresie między ostatnim wyjęciem 
a bieżącym włożeniem karty.  
— Godzina rozpoczęcia pierwszej czynności jest ustawiona 
na godzinę wyjęcia karty. Dla każdego kolejnego zapisu 
godzina rozpoczęcia jest wstępnie ustawiona tak, aby 
następowała bezpośrednio po godzinie zakończenia 
poprzedniego zapisu. Rodzaj czynności i godzinę 
zakończenia wybiera się dla każdej czynności.  
Procedura kończy się, gdy godzina zakończenia ręcznie 
wprowadzanej czynności pokrywa się z godziną włożenia 
karty.  
Urządzenie rejestrujące umożliwia kierowcom i warsztatom 
alternatywne ładowanie ręcznych wpisów, które należy 
wprowadzić podczas procedury za pośrednictwem interfejsu 
ITS określonego w dodatku 13, oraz, opcjonalnie, za 
pośrednictwem innych interfejsów.  
Urządzenie rejestrujące umożliwia posiadaczowi karty 
modyfikowanie ręcznie wprowadzonej czynności aż do 
zatwierdzenia przez wybranie odpowiedniego polecenia. 
W późniejszym czasie wprowadzenie takich zmian jest 
zabronione.  
▼B 
3.6.3  Wprowadzanie warunków szczególnych  
▼M3 
62) Urządzenie rejestrujące umożliwia kierowcy wprowadzenie 
w czasie rzeczywistym następujących dwóch stanów szcze­
gólnych:  
— „POZA ZAKRESEM” (początek, koniec),  
— „PRZEPRAWA PROMOWA/POCIĄGOWA” (początek, 
koniec).  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 35  
Jeżeli otwarty jest stan „POZA ZAKRESEM”, nie może 
równocześnie występować stan „PRZEPRAWA 
PROMOWA/POCIĄGOWA”. Jeżeli otwarto stan „POZA 
ZAKRESEM”, urządzenie rejestrujące nie pozwala użyt­
kownikom na wpisanie flagi początkowej „PRZEPRAWA 
PROMOWA/POCIĄGOWA”.  
Włożenie lub wyjęcie karty kierowcy powoduje automa­
tycznie zakończenie otwartego stanu „POZA ZAKRESEM”.  
Otwarty stan „POZA ZAKRESEM” blokuje następujące 
zdarzenia i ostrzeżenia:  
— prowadzenie pojazdu bez prawidłowej karty,  
— ostrzeżenia związane z nieprzerwanym czasem prowa­
dzenia pojazdu.  
Kierowca wpisuje flagę początkową PRZEPRAWA 
PROMOWA/POCIĄGOWA niezwłocznie po wybraniu czyn­
ności PRZERWA/ODPOCZYNEK na promie lub w pociągu.  
Zamknięcie otwartego stanu PRZEPRAWA PROMOWA/ 
POCIĄGOWA przez urządzenie rejestrujące musi nastąpić, 
jeżeli wystąpi jedna z następujących sytuacji:  
— kierowca ręcznie kończy stan PRZEPRAWA 
PROMOWA/POCIĄGOWA, co następuje po przybyciu 
promu/pociągu do miejsca przeznaczenia, przed zjazdem 
z promu/pociągu,  
— otwarty jest stan „POZA ZAKRESEM”,  
— kierowca wyjmuje swoją kartę,  
— aktywność kierowcy liczona jest jako PROWADZENIE 
w ciągu minuty kalendarzowej zgodnie z pkt 3.4.  
Jeżeli w ciągu jednej minuty kalendarzowej dokonuje się 
więcej niż jednego wpisu stanów szczególnych tego 
samego typu, rejestruje się tylko ostatni z nich.  
3.6.4  Wprowadzanie operacji za ładunku/roz ładunku  
62a) Urządzenie rejestrujące umożliwia kierowcy wprowadzenie 
i potwierdzenie, w czasie rzeczywistym, informacji wska­
zujących, że pojazd jest załadowywany, rozładowywany 
lub że wykonywana jest operacja równoczesnego zała­
dunku/rozładunku.  
Jeżeli w ciągu jednej minuty kalendarzowej dokonuje się 
więcej niż jednego wpisu operacji załadunku/rozładunku 
tego samego typu, rejestruje się tylko ostatni z nich.  
62b) Operacje załadunku, rozładunku lub równoczesnego zała­
dunku/rozładunku rejestruje się jako odrębne zdarzenia.  
62c) Informacje dotyczące załadunku/rozładunku wprowadza się 
przed opuszczeniem przez pojazd miejsca, w którym prze­
prowadzana jest operacja załadunku/rozładunku.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 36  
3.7 Zarz ądzanie blokadami firmowymi  
63) Funkcja ta umożliwia zarządzanie blokadami umieszcza­
nymi przez firmę w celu ograniczenia dostępu do danych, 
gdy urządzenie pracuje w trybie firmowym.  
64) Blokady firmowe polegają na ustawieniu daty/godziny 
rozpoczęcia (włączenie blokady) i daty/godziny zakoń­
czenia (zwolnienie blokady) związanych z identyfikacją 
firmy pobraną z numeru karty firmowej (przy włączeniu 
blokady).  
65) Blokady można włączać i zwalniać tylko w czasie 
rzeczywistym.  
66) Blokadę może zwolnić tylko ta firma, która ją włączyła 
(identyfikowana na podstawie pierwszych 13 cyfr numeru 
karty firmowej), lub  
67) Zwolnienie następuje automatycznie po włączeniu blokady 
przez inną firmę.  
68) W przypadku gdy firma włącza blokadę, a poprzednia 
blokada była włączona przez tę samą firmę, przyjmuje 
się, że poprzednia blokada nie została zwolniona i nadal 
jest włączona.  
3.8 Monitorowanie czynno ści kontrolnych  
69) Funkcja ta monitoruje wykonywane w trybie kontrolnym 
czynności WYŚWIETLANIA, DRUKOWANIA, POBIE­
RANIA DANYCH z przyrządu rejestrującego i karty oraz 
KONTROLI DROGOWEJ KALIBRACJI.  
70) Funkcja ta również monitoruje KONTROLE PRZEKRO­
CZENIA PRĘDKOŚCI wykonywane w trybie kontrolnym. 
Uznaje się, że kontrola przekroczenia prędkości została 
przeprowadzona, gdy w trybie kontrolnym komunikat 
„przekroczenie prędkości” zostaje wysłany do drukarki 
lub wyświetlony na monitorze, lub gdy dane o „zdarzeniach 
i usterkach” zostały pobrane z pamięci danych przyrządu 
rejestrującego.  
3.9 Wykrywanie zdarze ń lub usterek  
71) Funkcja ta wykrywa następujące zdarzenia lub usterki:  
3.9.1  Zdarzenie „w łożenie niewa żnej karty”  
72) Zdarzenie to uruchamiane jest przez włożenie nieważnej 
karty, włożenie karty kierowcy, która została wymieniona, 
lub wygaśnięcie ważności włożonej, ważnej karty.  
3.9.2  Zdarzenie „konflikt kart”  
73) Zdarzenie to uruchamiane jest przez każdą kombinację 
ważnych kart zaznaczoną X w tabeli poniżej:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 37  
Konflikt kart  Czytnik karty kierowcy  
Brak karty  Karta kierowcy  Karta kontrolna  Karta warsztatowa  Karta firmowa
 Czytnik karty współkierowcy 
Brak karty  
Karta kierowcy  X  
Karta kontrolna  X  X  X  
Karta warsztatowa  X  X  X  X  
Karta firmowa  X  X  X  
3.9.3  Zdarzenie,,nak ładające się czasy  
74) Zdarzenie to uruchamiane jest w sytuacji, gdy data/godzina 
ostatniego wyjęcia karty kierowcy, odczytana z karty, jest 
późniejsza niż bieżąca data/godzina urządzenia rejestrują­
cego, do którego karta jest wkładana.  
3.9.4  Zdarzenie „prowadzenie pojazdu bez prawid łowej karty”  
75) Zdarzenie to uruchamiane jest przez każdą kombinację 
ważnych kart do tachografów zaznaczoną X w poniższej 
tabeli, gdy czynność kierowcy zmienia się na PROWA­
DZENIE lub w przypadku zmiany trybu pracy, w czasie 
gdy czynnością wykonywaną przez kierowcę jest PROWA­
DZENIE:  
Prowadzenie pojazdu bez 
prawidłowej 
karty  Czytnik karty kierowcy  
Brak karty (lub 
karta nieważna)  Karta kierowcy  Karta kontrolna  Karta warsztatowa  Karta firmowa
 Czytnik karty współkierowcy 
Brak karty (lub karta 
nieważna)  X X  X  
Karta kierowcy  X  X  X  X  
Karta kontrolna  X  X  X  X  X  
Karta warsztatowa  X  X  X  X  
Karta firmowa  X  X  X  X  X  
3.9.5  Zdarzenie „w łożenie karty podczas prowadzenia pojazdu”  
76) Zdarzenie to uruchamia się, gdy do dowolnego czytnika 
włożona zostaje karta do tachografu, a czynnością kierowcy 
jest PROWADZENIE.  
3.9.6  Zdarzenie „Sesja ostatniej karty niezamkni ęta prawid łowo”  
77) Zdarzenie to uruchamia się, gdy przy wkładaniu karty urzą­
dzenie rejestrujące wykryje, że pomimo przepisów określo­
nych w pkt 3.1 sesja poprzedniej karty nie została prawid­ 
łowo zamknięta (karta została wyjęta przed zapisaniem na 
karcie wszystkich wymaganych danych). Zdarzenie to 
uruchamiają tylko karty kierowcy i warsztatowe.  
3.9.7  Zdarzenie „przekroczenie pr ędkości” 
78) Zdarzenie to uruchamia się przy każdym przekroczeniu 
prędkości.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 38  
3.9.8  Zdarzenie „przerwa w zasilaniu”  
79) Z wyjątkiem trybu kalibracyjnego lub kontrolnego, zdarzenie  
to uruchamia się w przypadku przekraczającej 200 ms 
przerwy w zasilaniu czujnika ruchu lub przyrządu rejestrują­
cego. Wartość progową przerwy definiuje producent. 
Przerwa w zasilaniu spowodowana uruchamianiem silnika 
pojazdu nie może uruchamiać tego zdarzenia.  
3.9.9  Zdarzenie „b łąd połączenia z urz ądzeniem do łączności na odle ­
głość” 
80) Z wyj ątkiem trybu kalibracyjnego , zdarzenie to uruchamia 
się w przypadku gdy urządzenie do łączności na odległość 
nie potwierdza odbioru danych przesyłanych zdalnie z przy­
rządu rejestrującego podczas więcej niż trzech prób.  
3.9.10  Zdarzenie „brak informacji o pozycji z odbiornika GNSS”  
81) Z wyj ątkiem trybu kalibracyjnego , zdarzenie to uruchamia 
się w przypadku braku informacji o pozycji pochodzących 
z odbiornika GNSS (wewnętrznego lub zewnętrznego) przez 
ponad trzy godziny skumulowanego czasu prowadzenia 
pojazdu.  
3.9.11  Zdarzenie „b łąd połączenia z urz ądzeniem zewn ętrznym GNSS”  
82) Z wyj ątkiem trybu kalibracyjnego , zdarzenie to uruchamia 
się w przypadku przerwy w łączności między urządzeniem 
zewnętrznym GNSS a przyrządem rejestrującym przez ponad 
20 kolejnych minut, kiedy pojazd jest w ruchu.  
3.9.12  Zdarzenie „b łąd danych dotycz ących ruchu”  
▼M3 
83) Z wyj ątkiem trybu kalibracyjnego , zdarzenie to uruchamia 
się w przypadku przerwy w normalnym przepływie danych 
między czujnikiem ruchu a przyrządem rejestrującym lub 
w przypadku błędu integralności danych lub błędu uwierzy­
telnienia danych wymienianych między czujnikiem ruchu 
a przyrządem rejestrującym.  Z wyjątkiem trybu kalibracyj ­
nego , zdarzenie to uruchamia się w przypadku, gdy prędkość 
obliczona z impulsów czujnika ruchu wzrośnie z 0 do ponad 
40 km/h w ciągu 1 sekundy, a następnie pozostaje powyżej 
40 km/h przez co najmniej 3 sekundy.  
▼B 
3.9.13  Zdarzenie „konflikt ruchu pojazdu”  
▼M3 
84) Z wyj ątkiem trybu kalibracyjnego , zdarzenie to uruchamia 
się, jak określono w dodatku 12, jeżeli informacje o ruchu 
z czujnika ruchu są sprzeczne z informacjami o ruchu obli­
czonymi z wewnętrznego odbiornika GNSS lub urządzenia 
zewnętrznego GNSS lub z innych niezależnych źródeł 
zgodnie z wymogiem 26. Zdarzenie to nie może być urucho­
mione podczas przeprawy promowej/pociągowej.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 39  
3.9.14  Zdarzenie „próba naruszenia zabezpieczenia”  
85) Zdarzenie to uruchamiane jest przez każde inne zdarzenie 
naruszające zabezpieczenie czujnika ruchu lub przyrządu rejes­
trującego lub urządzenia zewnętrznego GNSS, zgodnie 
z wymogami w dodatku 10, z wyjątkiem trybu kalibracyjnego.  
▼M1 
3.9.15  Zdarzenie „konflikt czasu”  
▼M3 
86) Z wyj ątkiem trybu kalibracyjnego , zdarzenie to 
uruchamia się, jeżeli przyrząd rejestrujący wykryje rozbież­
ność między czasem określonym przez funkcję pomiaru 
czasu w przyrządzie rejestrującym a czasem pochodzącym 
z uwierzytelnionych pozycji przekazywanych przez 
odbiornik GNSS lub urządzenie zewnętrzne GNSS. 
„Rozbieżność czasu” wykrywa się, jeżeli różnica czasu 
przekracza ± 3 sekundy, co odpowiada dokładności czasu 
określonej w wymogu 41a, przy czym ta ostatnia wartość 
zwiększa się o maksymalny dzienny dryft czasu. Zdarzenie 
to jest rejestrowane wraz z wartością wyświetlaną na 
wewnętrznym zegarze urządzenia rejestrującego. Przyrząd 
rejestrujący dokonuje sprawdzenia w celu uruchomienia 
zdarzenia „konflikt czasowy” tuż przed automatycznym 
dostosowaniem wewnętrznego zegara VU, zgodnie z wymo­
giem 211.  
▼B 
3.9.16  Usterka „karta”  
87) Usterkę tę uruchamia błąd karty do tachografu podczas 
pracy.  
3.9.17  Usterka „urz ądzenie rejestruj ące” 
88) Usterkę tę uruchamia dowolny z następujących błędów, 
z wyjątkiem pracy w trybie kalibracyjnym:  
— usterka wewnętrzna przyrządu rejestrującego  
— usterka drukarki  
— usterka wyświetlacza  
— usterka pobierania danych  
— usterka czujnika  
— usterka odbiornika GNSS lub urządzenia zewnętrznego 
GNSS  
— usterka urządzenia do łączności na odległość  
▼M3 
— usterka związana z interfejsem ITS,  
3.9.18  Zdarzenie „anomalia GNSS”  
88a) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia 
się, gdy odbiornik GNSS wykryje atak lub gdy uwierzytel­
nienie komunikatów nawigacyjnych nie powiodło się, jak 
określono w dodatku 12. Po uruchomieniu zdarzenia 
anomalii GNSS przyrząd rejestrujący nie generuje innych 
zdarzeń anomalii GNSS przez kolejnych 10 minut.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 40  
3.10 Testy wbudowane i autotesty  
89) ►M1 Urządzenie rejestrujące wykrywa usterki, wykonując 
autotesty i testy wbudowane, zgodnie z poniższą tabelą: ◄  
Testowany podzespół  Autotest  Test wbudowany  
Oprogramowanie  Integralność  
Pamięć danych  Dostęp  Dostęp, integralność 
danych  
Czytniki kart  Dostęp  Dostęp  
Klawiatura  Kontrola ręczna  
Drukarka  (w gestii produ­
centa)  Wydruk  
Wyświetlacz  Kontrola wzrokowa  
Pobieranie danych 
(wykonywane tylko 
podczas pobierania)  Prawidłowa praca  
Czujnik  Prawidłowa praca  Prawidłowa praca  
Urządzenie do łączności na 
odległość  Prawidłowa praca  Prawidłowa praca  
Urządzenie GNSS  Prawidłowa praca  Prawidłowa praca  
▼M3 
interfejs ITS  Prawidłowa praca  
▼B 
3.11 Odczyt z pami ęci danych  
90) Urządzenie rejestrujące umożliwia odczyt danych przecho­
wywanych w jego pamięci danych.  
3.12 Rejestracja i przechowywanie w pami ęci danych  
▼M3 
Do celów niniejszego punktu:  
— „365 dni” definiuje się jako 365 dni kalendarzowych przecięt­
nych czynności wykonywanych przez kierowców w pojeździe. 
Przeciętne czynności na dzień w pojeździe definiuje się jako co  
najmniej 6 kierowców lub współkierowców, 6 cykli wkładania 
i wyjmowania karty i 256 zmian czynności. „365 dni” obejmuje 
zatem co najmniej 2 190 kierowców lub współkierowców, 2 190 
cykli wkładania i wyjmowania karty i 93 440 zmian czynności,  
— średnią liczbę wpisów na dzień definiuje się jako co najmniej  6 
wpisów, w których rozpoczyna się dzienny okres pracy, oraz 6 
wpisów, w których kończy się dzienny okres pracy, tak więc 
„365 dni” obejmuje co najmniej 4 380 pozycji,  
— średnią liczbę pozycji na dzień, gdy skumulowany czas prowa­
dzenia pojazdu osiąga wielokrotność trzech godzin, definiuje si ę 
jako co najmniej 6 pozycji, a zatem „365 dni” obejmuje co 
najmniej 2 190 takich pozycji,  
— średnią liczbę przekroczeń granicy na dzień definiuje się jak o co 
najmniej 20, a zatem „365 dni” obejmuje co najmniej 7 300 
przekroczeń granicy,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 41  
— średnią liczbę operacji załadunku/rozładunku na dzień definiu je 
się jako co najmniej 25 operacji (niezależnie od typu), a zatem  
„365 dni” obejmuje co najmniej 9 125 operacji załadunku/rozła­
dunku,  
— czas jest rejestrowany z dokładnością do jednej minuty, o ile  nie 
ustalono inaczej,  
— stany licznika kilometrów rejestruje się z dokładnością do 
jednego kilometra,  
— prędkości rejestruje się z dokładnością do 1 km/h,  
— pozycje (szerokości i długości geograficzne) rejestruje się w  stop­
niach i minutach, z dokładnością do 1/10 minuty, z powiązaną 
dokładnością GNSS i czasem pobrania danych, a także z flagą 
wskazującą, czy pozycja została uwierzytelniona.  
▼B 
91) Odcięcie zewnętrznego źródła zasilania na czas krótszy niż 
dwanaście miesięcy, w warunkach homologacyjnych, nie 
może wpływać na dane przechowywane w pamięci danych. 
Ponadto odcięcie zasilania na czas krótszy niż 28 dni nie 
może mieć wpływu na dane przechowywane w zewnętrznym 
urządzeniu do łączności na odległość, zgodnie z definicją 
w dodatku 14.  
92) Urządzenie rejestrujące umożliwia rejestrowanie, pośrednio 
lub bezpośrednio, w pamięci danych następujących informacji:  
3.12.1  Dane identyfikuj ące sprzęt 
3.12.1.1 D a n e i d e n t y f i k u j ą c e p r z y r z ą d r e j e s t r u j ą c y  
93) Urządzenie rejestrujące umożliwia przechowywanie 
w pamięci danych następujących danych identyfikujących 
przyrząd rejestrujący:  
— nazwa producenta,  
— adres producenta,  
— numer części,  
— numer seryjny,  
— generacja przyrządu rejestrującego,  
— możliwość korzystania z kart do tachografów pierwszej 
generacji,  
— numer wersji oprogramowania,  
— data instalacji wersji oprogramowania,  
— rok produkcji urządzenia,  
— numer homologacji,  
▼M3 
— identyfikator wersji mapy cyfrowej (wymóg 133l).  
94) Dane identyfikujące przyrząd rejestrujący są rejestrowane 
i zapisywane w pamięci definitywnie przez producenta 
przyrządu rejestrującego, z wyjątkiem danych, które mogą 
zostać zmienione w przypadku aktualizacji oprogramo­
wania zgodnie z niniejszym rozporządzeniem, oraz z wyjąt­
kiem możliwości korzystania z kart do tachografów pierw­
szej generacji.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 42  
3.12.1.2 D a n e i d e n t y f i k u j ą c e c z u j n i k r u c h u 
95) Czujnik ruchu umożliwia przechowywanie w pamięci 
następujących danych identyfikujących:  
— nazwa producenta,  
— numer seryjny,  
— numer homologacji,  
— identyfikator wbudowanego elementu zabezpieczenia 
(np. numer części wewnętrznego mikroprocesora),  
— identyfikator systemu operacyjnego (np. numer wersji 
oprogramowania).  
96) Dane identyfikujące czujnik ruchu są rejestrowane i zapisy­
wane w czujniku ruchu definitywnie przez producenta czuj­
nika ruchu.  
▼M3 
97) Przyrząd rejestrujący musi mieć możliwość rejestrowania 
i zachowywania w pamięci następujących danych związa­
nych z 20 ostatnimi udanymi sparowaniami czujników 
ruchu (jeżeli podczas jednego dnia kalendarzowego miało 
miejsce wiele sparowań, zachowywane jest tylko pierwsze 
i ostatnie z danego dnia):  
▼B 
Przy każdym sparowaniu rejestruje się następujące dane:  
— dane identyfikujące czujnik ruchu:  
— numer seryjny  
— numer homologacji  
— dane sparowania czujnika ruchu:  
— data sparowania.  
3.12.1.3 D a n e i d e n t y f i k u j ą c e g l o b a l n e g o s y s t e m u n a w i ­
g a c j i s a t e l i t a r n e j  
98) Urządzenie zewnętrzne GNSS umożliwia przechowywanie 
w pamięci następujących danych identyfikujących:  
— nazwa producenta,  
— numer seryjny,  
— numer homologacji,  
— identyfikator wbudowanego elementu zabezpieczenia 
(np. numer części wewnętrznego mikroprocesora),  
— identyfikator systemu operacyjnego (np. numer wersji 
oprogramowania).  
99) Dane identyfikujące są rejestrowane i zapisywane w urzą­
dzeniu zewnętrznym GNSS definitywnie przez producenta 
urządzenia zewnętrznego GNSS.  
▼M3 
100) Przyrząd rejestrujący musi mieć możliwość rejestrowania 
i zachowywania w pamięci następujących danych związa­
nych z 20 ostatnimi udanymi powiązaniami urządzeń 
zewnętrznych GNSS (jeżeli podczas jednego dnia kalenda­
rzowego miało miejsce wiele powiązań, zachowywane jest 
tylko pierwsze i ostatnie z danego dnia).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 43  
Przy każdym powiązaniu rejestruje się następujące dane:  
— dane identyfikujące urządzenia zewnętrznego GNSS:  
— numer seryjny,  
— numer homologacji,  
— dane dotyczące powiązania z urządzeniem zewnętrznym 
GNSS:  
— data powiązania.  
3.12.2  Klucze i certyfikaty  
101) Urządzenie rejestrujące umożliwia przechowywanie szeregu 
kluczy i certyfikatów kryptograficznych, jak określono 
w dodatku 11 część A i część B.  
3.12.3  Dane rejestrowane przy wk ładaniu i wyjmowaniu karty kierowcy 
lub warsztatowej  
102) Przy każdym cyklu wkładania/wyjmowania karty kierowcy 
lub warsztatowej do urządzenia, urządzenie rejestrujące 
rejestruje i przechowuje w pamięci danych następujące 
informacje:  
— nazwisko i imię (imiona) posiadacza karty zapisane na 
karcie,  
— numer karty, państwo członkowskie wydające kartę 
i termin ważności zapisane na karcie,  
— generację karty,  
— datę i godzinę włożenia karty,  
— stan licznika kilometrów przy wkładaniu karty,  
— szczelinę czytnika, do której karta jest wkładana,  
— datę i godzinę wyjęcia karty,  
— stan licznika kilometrów przy wyjęciu karty,  
— następujące informacje o poprzednim pojeździe 
używanym przez kierowcę, zapisane na karcie:  
— numer VRN i państwo członkowskie rejestracji,  
— generacja przyrządu rejestrującego (w razie dostęp­
ności),  
— datę i godzinę wyjęcia karty,  
— wskaźnik stanu pokazujący, czy przy wkładaniu karty 
posiadacz karty wprowadził ręcznie informacje o wyko­
nywaniu czynności.  
103) Pamięć danych wystarcza do przechowywania tych danych 
przez co najmniej 365 dni.  
104) W przypadku zapełnienia pamięci danych nowe dane zastę­
pują dane najstarsze.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 44  
3.12.4  Dane dotycz ące czynno ści kierowcy  
105) Urządzenie rejestrujące rejestruje i przechowuje w pamięci  
danych za każdym razem, kiedy następuje zmiana czyn­
ności kierowcy lub współkierowcy, lub za każdym razem, 
kiedy następuje zmiana stanu prowadzenia pojazdu, lub za 
każdym razem, kiedy następuje włożenie lub wyjęcie karty 
kierowcy lub karty warsztatowej:  
— stan prowadzenia pojazdu (ZAŁOGA, JEDEN 
KIEROWCA),  
— szczelinę czytnika (KIEROWCA, WSPÓŁKIE­
ROWCA),  
— status karty w odpowiedniej szczelinie czytnika kart 
(WŁOŻONA, NIEWŁOŻONA),  
— czynność (PROWADZENIE, GOTOWOŚĆ, PRACA, 
PRZERWA/ODPOCZYNEK),  
— datę i godzinę zmiany.  
WŁOŻONA oznacza, że do czytnika jest włożona ważna 
karta kierowcy lub warsztatowa. NIEWŁOŻONA oznacza 
sytuację przeciwną, tzn. że do czytnika nie jest włożona 
ważna karta kierowcy ani warsztatowa (np. włożona jest 
karta firmowa lub brak jest karty).  
Dane dotyczące czynności ręcznie wprowadzone przez 
kierowcę nie są rejestrowane w pamięci danych.  
106) Pamięć danych wystarcza do przechowywania danych doty­
czących czynności kierowcy przez co najmniej 365 dni.  
107) W przypadku zapełnienia pamięci danych nowe dane zastę­
pują dane najstarsze.  
▼M1 
3.12.5  Miejsca i pozycje, w których zaczynaj ą się i kończą dzienne okresy 
pracy lub w których osi ągnięto 3 godziny skumulowanego czasu 
prowadzenia pojazdu  
108) Urządzenie rejestrujące rejestruje i przechowuje w pamięci  
następujące dane:  
— miejsca i pozycje, w których kierowca lub współkie­
rowca rozpoczynają dzienny okres pracy;  
— pozycje, w których skumulowany czas prowadzenia 
pojazdu osiągnie wielokrotność trzech godzin;  
— miejsca i pozycje, w których kierowca lub współkie­
rowca kończą dzienny okres pracy.  
▼B 
109) Jeżeli w danym momencie pozycja pojazdu nie jest 
dostępna z odbiornika GNSS, urządzenie rejestrujące 
korzysta z ostatniej dostępnej pozycji i odpowiadającej jej 
daty i godziny.  
110) Wraz z miejscem lub pozycją urządzenie rejestrujące rejes­
truje i przechowuje w pamięci następujące dane:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 45  
— numer karty kierowcy lub współkierowcy i państwo 
członkowskie wydające kartę,  
▼B 
— generację karty,  
— datę i godzinę wpisu,  
▼M1 
— rodzaj wpisu (rozpoczęcie, zakończenie lub 3 godziny 
skumulowanego czasu prowadzenia pojazdu),  
▼B 
— w stosownych przypadkach odpowiednią dokładność 
GNSS, datę i godzinę,  
— stan licznika kilometrów,  
▼M3 
— flagę wskazującą, czy pozycja została uwierzytelniona.  
110a) Dla miejsc, w których rozpoczyna się lub kończy dzienny 
okres pracy, wprowadzanych podczas procedury ręcznego 
wprowadzania danych przy wkładaniu karty zgodnie 
z wymogiem 61, należy zapisać bieżący stan licznika kilo­
metrów i pozycję pojazdu.  
▼M1 
111) Pamięć danych wystarcza do przechowywania miejsc 
i pozycji, w których zaczynają się i kończą dzienne okresy 
pracy lub w których osiągnięto 3 godziny skumulowanego 
czasu prowadzenia pojazdu, przez co najmniej 365 dni.  
▼B 
112) W przypadku zapełnienia pamięci danych nowe dane zastę­
pują dane najstarsze.  
3.12.6  Dane dotycz ące licznika kilometrów  
113) Urządzenie rejestrujące rejestruje w pamięci danych stan 
licznika kilometrów i odpowiednią datę o północy każdego 
dnia kalendarzowego.  
114) Pamięć danych wystarcza do przechowywania danych doty­
czących stanu licznika o północy przez co najmniej 365 dni 
kalendarzowych.  
115) W przypadku zapełnienia pamięci danych nowe dane zastę­
pują dane najstarsze.  
3.12.7  Dane szczegó łowe dotycz ące prędkości 
▼M1 
116) Urządzenie rejestrujące rejestruje i przechowuje w pamięci  
danych prędkość chwilową pojazdu wraz z datą i godziną, 
rejestrowane co sekundę przez okres co najmniej ostatnich 
24 godzin, w których pojazd był w ruchu.  
▼B 
3.12.8  Dane dotycz ące zdarze ń 
Do celów niniejszego podpunktu czas rejestruje się z dokładnośc ią 
do 1 sekundy.  
117) Urządzenie rejestrujące rejestruje i przechowuje w pamięci  
danych następujące dane dla każdego zdarzenia wykrytego 
zgodnie z poniższymi zasadami przechowywania danych:  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 46  
Zdarzenie  Zasady przechowywania  Dane rejestrowane dla zdarzenia  
Włożenie nieważnej karty  — 10 ostatnich zdarzeń  — data i godzina zdarzenia 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja karty, która 
wywołała zdarzenie 
— liczba podobnych zdarzeń w tym dniu  
Konflikt kart  — 10 ostatnich zdarzeń  — data i godzina początku zdarzenia 
— data i godzina końca zdarzenia 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja dwóch kart, 
które wywołały konflikt  
Prowadzenie pojazdu bez 
prawidłowej karty  — najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania 
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni  — data i godzina początku zdarzenia 
— data i godzina końca zdarzenia 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja dla każdej 
karty wprowadzonej na początku lub 
pod koniec zdarzenia 
— liczba podobnych zdarzeń w tym dniu  
Włożenie karty podczas 
jazdy  — ostatnie zdarzenie dla każdego z 10 
ostatnich dni ich występowania  — data i godzina zdarzenia 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja 
— liczba podobnych zdarzeń w tym dniu  
▼M3 
Sesja ostatniej karty 
niezamknięta prawidłowo  — 10 ostatnich zdarzeń  — data i godzina włożenia karty 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja 
— dane dotyczące ostatniej sesji odczytane 
z karty: 
— data i godzina włożenia karty  
▼B 
Przekroczenie prędkości 
(1) — najpoważniejsze zdarzenie dla każdego 
z 10 ostatnich dni od zaistnienia 
zdarzenia (tzn. zdarzenie o najwyższej 
przeciętnej prędkości) 
— 5 najpoważniejszych zdarzeń w ciągu 
ostatnich 365 dni 
— pierwsze zdarzenie zaistniałe po ostat­
niej kalibracji  — data i godzina początku zdarzenia 
— data i godzina końca zdarzenia 
— maksymalna prędkość zmierzona w czasie 
zdarzenia 
— średnia arytmetyczna prędkość zmie­
rzona w czasie zdarzenia 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja karty kierowcy 
(w stosownych przypadkach) 
— liczba podobnych zdarzeń w tym dniu  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 47  
Zdarzenie  Zasady przechowywania  Dane rejestrowane dla zdarzenia  
Przerwa w zasilaniu (2)  — najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania 
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni  — data i godzina początku zdarzenia 
— data i godzina końca zdarzenia 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja dla każdej 
karty wprowadzonej na początku lub 
pod koniec zdarzenia 
— liczba podobnych zdarzeń w tym dniu  
Błąd połączenia z urządze­
niem do łączności na 
odległość  — najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania 
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni  — data i godzina początku zdarzenia 
— data i godzina końca zdarzenia 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja dla każdej 
karty wprowadzonej na początku lub 
pod koniec zdarzenia 
— liczba podobnych zdarzeń w tym dniu  
Brak informacji o pozycji 
z odbiornika GNSS  — najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania 
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni  — data i godzina początku zdarzenia 
— data i godzina końca zdarzenia 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja dla każdej 
karty wprowadzonej na początku lub 
pod koniec zdarzenia 
— liczba podobnych zdarzeń w tym dniu  
▼M1 
Błąd połączenia z urządze­
niem zewnętrznym GNSS  — najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania 
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni  — data i godzina początku zdarzenia 
— data i godzina końca zdarzenia 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja dla każdej 
karty wprowadzonej na początku lub 
pod koniec zdarzenia 
— liczba podobnych zdarzeń w tym dniu  
▼B 
Błąd danych dotyczących 
ruchu  — najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania 
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni  — data i godzina początku zdarzenia 
— data i godzina końca zdarzenia 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja dla każdej 
karty wprowadzonej na początku lub 
pod koniec zdarzenia 
— liczba podobnych zdarzeń w tym dniu  
Konflikt ruchu pojazdu  — najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania 
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni  — data i godzina początku zdarzenia 
— data i godzina końca zdarzenia 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja dla każdej 
karty wprowadzonej na początku lub 
pod koniec zdarzenia 
— liczba podobnych zdarzeń w tym dniu  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 48  
Zdarzenie  Zasady przechowywania  Dane rejestrowane dla zdarzenia  
Próba naruszenia zabez­
pieczenia  — 10 ostatnich zdarzeń wg typu zdarzenia  — data i godzina początku zdarzenia 
— data i godzina zakończenia zdarzenia 
(jeżeli jest istotna) 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja dla każdej 
karty wprowadzonej na początku lub 
pod koniec zdarzenia 
— typ zdarzenia  
▼M1 
Konflikt czasu  — najpoważniejsze zdarzenie w każdym 
z 10 ostatnich dni ich występowania 
(tj. zdarzenia z największymi różnicami 
pomiędzy datą i godziną z urządzenia 
rejestrującego a datą i godziną 
z GNSS), 
— 5 najpoważniejszych zdarzeń w ciągu 
ostatnich 365 dni  — data i godzina z urządzenia rejestrują­
cego 
— data i godzina z GNSS 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja dla każdej 
karty wprowadzonej na początku lub 
pod koniec zdarzenia 
— liczba podobnych zdarzeń w tym dniu  
▼M3 
Anomalia GNSS  — najdłuższe zdarzenia w każdym z ostat­
nich 10 dni ich występowania, 
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni  — data i godzina początku zdarzenia 
— data i godzina końca zdarzenia 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja dla każdej 
karty wprowadzonej na początku lub na 
końcu zdarzenia 
— liczba podobnych zdarzeń w tym dniu  
▼B 
(1) Urządzenie rejestrujące rejestruje i przechowuje 
również w pamięci następujące dane:  
— datę i godzinę ostatniej KONTROLI PRZEKRO­
CZENIA PRĘDKOŚCI,  
— datę i godzinę pierwszego przekroczenia prędkości 
po tej ostatniej KONTROLI PRZEKROCZENIA 
PRĘDKOŚCI.  
— liczbę zdarzeń przekroczenia prędkości od ostatniej 
KONTROLI PRZEKROCZENIA PRĘDKOŚCI.  
(2) Dane te mogą być rejestrowane wyłącznie po przywró­
ceniu zasilania, czas może być znany z dokładnością do 
minuty.  
3.12.9  Dane dotycz ące usterek  
Do celów niniejszego podpunktu czas rejestruje się z dokładnośc ią 
do 1 sekundy.  
118) Urządzenie rejestrujące próbuje rejestrować i przechowywać  
w pamięci danych następujące dane dla każdej wykrytej 
usterki zgodnie z następującymi zasadami przechowywania 
danych:  ▼B
02016R0799 — PL — 21.08.2023 — 003.001 — 49  
Usterka  Zasady przechowywania  Dane rejestrowane dla usterki  
Usterka karty  — 10 ostatnich usterek karty kierowcy  — data i godzina początku usterki 
— data i godzina końca usterki 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja  
Usterki urządzenia rejes­
trującego  — 10 ostatnich usterek dla każdego typu 
usterki 
— pierwsza usterka po ostatniej kalibracji  — data i godzina początku usterki 
— data i godzina końca usterki 
— rodzaj usterki 
— typ karty, numer, państwo członkowskie 
wydające kartę i generacja dla każdej 
karty wprowadzonej na początku lub 
pod koniec usterki  
3.12.10  Dane kalibracyjne  
119) Urządzenie rejestrujące rejestruje i przechowuje w pamięci  
następujące dane:  
— parametry kalibracyjne znane w momencie aktywacji,  
— pierwszą kalibrację po aktywacji urządzenia,  
— pierwszą kalibrację w obecnym pojeździe (identyfiko­
wanym numerem VIN),  
— 20 ostatnich kalibracji (jeżeli w czasie jednego dnia 
kalendarzowego jest kilka kalibracji, zapamiętywana 
jest tylko pierwsza i ostatnia kalibracja z tego dnia).  
120) Przy każdej z tych kalibracji rejestruje się następujące d ane: 
— cel kalibracji (aktywacja, pierwsza instalacja, instalacja, 
przegląd okresowy),  
— nazwa i adres warsztatu,  
— numer karty warsztatowej, państwo członkowskie 
wydające kartę i termin ważności karty,  
— identyfikacja pojazdu,  
— parametry uaktualnione lub potwierdzone: w, k, l, 
rozmiar opon, ustawienia urządzenia ograniczenia pręd­
kości, licznik kilometrów (wartości stare i nowe), data 
i godzina (wartości stare i nowe),  
— rodzaje i identyfikatory wszystkich założonych plomb,  
▼M3 
— numery seryjne czujnika ruchu, urządzenia zewnętrz­
nego GNSS (jeżeli występuje) oraz zewnętrznego urzą­
dzenia do łączności na odległość (jeżeli występuje),  
— domyślny typ załadunku związanego z pojazdem (zała­
dunek towarów albo pasażerów),  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 50  
— kraj, w którym wykonano kalibrację, oraz datę i godzinę 
dostarczenia przez odbiornik GNSS pozycji wykorzys­
tanej do określenia tego kraju.  
▼B 
121) Ponadto urządzenie rejestrujące rejestruje i przechowuje 
w pamięci danych zdolność do użytkowania kart do tacho­
grafów pierwszej generacji (aktywowaną lub nie).  
122) Czujnik ruchu rejestruje i przechowuje w pamięci następu­
jące dane instalacyjne czujnika ruchu:  
— pierwsze sparowanie z przyrządem rejestrującym (data, 
godzina, numer homologacji przyrządu rejestrującego, 
numer seryjny przyrządu rejestrującego),  
— ostatnie sparowanie z przyrządem rejestrującym (data, 
godzina, numer homologacji przyrządu rejestrującego, 
numer seryjny przyrządu rejestrującego).  
123) Urządzenie zewnętrzne GNSS rejestruje i przechowuje 
w pamięci następujące dane instalacyjne urządzenia 
zewnętrznego GNSS:  
— pierwsze powiązanie z przyrządem rejestrującym (data, 
godzina, numer homologacji przyrządu rejestrującego, 
numer seryjny przyrządu rejestrującego),  
— ostatnie powiązanie z przyrządem rejestrującym (data, 
godzina, numer homologacji przyrządu rejestrującego, 
numer seryjny przyrządu rejestrującego).  
3.12.11  Dane dotycz ące korekty czasu  
124) Urządzenie rejestrujące rejestruje i przechowuje w pamięci  
danych dane dotyczące korekty czasu przeprowadzonej 
w trybie kalibracyjnym, poza ramami regularnej kalibracji 
(def. f)):  
— ostatnia korekta czasu,  
— 5 największych korekt czasu.  
125) Przy każdej z tych korekt czasu rejestruje się następujące  
dane:  
— data i godzina, stara wartość,  
— data i godzina, nowa wartość,  
— nazwa i adres warsztatu,  
— numer karty warsztatowej, państwo członkowskie 
wydające kartę, generacja karty i termin ważności karty.  
3.12.12  Dane dotycz ące czynno ści kontrolnych  
126) Urządzenie rejestrujące rejestruje i przechowuje w pamięci  
danych następujące dane dotyczące ostatnich 20 czynności 
kontrolnych:  
— data i godzina kontroli,  
— numer karty kontrolnej, państwo członkowskie wyda­
jące kartę i generacja karty,  
— rodzaj kontroli (wyświetlanie lub drukowanie lub pobie­
ranie danych z przyrządu rejestrującego lub karty lub 
kontrola drogowa kalibracji).  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 51  
127) W przypadku pobierania danych rejestruje się także daty 
najstarszych i najnowszych dni, z których dane są pobierane.  
3.12.13  Dane dotycz ące blokad firmowych  
128) Urządzenie rejestrujące rejestruje i przechowuje w pamięci  
następujące dane dotyczące 255 ostatnich blokad 
firmowych:  
— data i godzina założenia blokady,  
— data i godzina zdjęcia blokady,  
— numer karty firmowej, państwo członkowskie wydające 
kartę i generacja karty,  
— nazwa i adres firmy.  
Dane wcześniej zabezpieczone przez blokadę usunięte 
z pamięci z powodu powyższego ograniczenia traktuje się 
jako niezabezpieczone.  
3.12.14  Dane dotycz ące pobierania danych  
129) Urządzenie rejestrujące rejestruje i przechowuje w pamięci  
danych następujące dane dotyczące ostatniego pobierania 
danych z pamięci urządzenia na nośnik zewnętrzny, wyko­
nanego w trybie firmowym lub kalibracyjnym:  
— data i godzina pobrania danych,  
— numer karty firmowej lub warsztatowej, państwo człon­
kowskie wydające kartę i generacja karty,  
— nazwa firmy lub warsztatu.  
3.12.15  Dane dotycz ące warunków szczególnych  
130) Urządzenie rejestrujące rejestruje i przechowuje w pamięci  
danych następujące dane dotyczące warunków szczegól­
nych:  
— data i godzina wprowadzenia danych,  
— rodzaj warunku szczególnego.  
131) Pamięć danych umożliwia przechowywanie danych doty­
czących warunków szczególnych przez co najmniej 365 dni 
(przy założeniu, że przeciętnie otwiera się i zamyka jeden 
warunek dziennie). W przypadku zapełnienia pamięci 
danych nowe dane zastępują dane najstarsze.  
3.12.16  Dane karty do tachografu  
132) Urządzenie rejestrujące umożliwia przechowywanie nastę­
pujących danych dotyczących różnych kart do tachografów, 
które zostały użyte w przyrządzie rejestrującym:  
— numer karty do tachografu i jej numer seryjny,  
— producent karty do tachografu,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 52  
— typ karty do tachografu,  
— wersja karty do tachografu.  
133) Urządzenie rejestrujące umożliwia przechowywanie co 
najmniej 88 takich rekordów danych.  
▼M3 
3.12.17  Przekroczenia granicy  
133a) Urządzenie rejestrujące rejestruje i przechowuje w pamięc i 
danych następujące informacje na temat przekroczeń 
granicy:  
— kraj, który pojazd opuszcza,  
— kraj, do którego pojazd wjeżdża,  
— pozycję, gdzie pojazd przekroczył granicę.  
133b) Wraz z krajami i pozycją urządzenie rejestrujące rejestru je 
i przechowuje w pamięci następujące dane:  
— numer karty kierowcy lub współkierowcy i państwo 
członkowskie wydające kartę,  
— generacja karty,  
— odpowiednia dokładność GNSS, data i godzina,  
— flagę wskazującą, czy pozycja została uwierzytelniona,  
— stan licznika kilometrów w momencie wykrycia prze­
kroczenia granicy.  
133c) Pamięć danych wystarcza do przechowywania danych doty­
czących przekroczeń granicy przez co najmniej 365 dni.  
133d) W przypadku zapełnienia pamięci danych nowe dane zastę­
pują dane najstarsze.  
3.12.18  Operacje za ładunku/roz ładunku  
133e) Urządzenie rejestrujące rejestruje i przechowuje w pamięc i 
danych następujące informacje na temat operacji załadunku 
i rozładunku pojazdu:  
— typ operacji (załadunek, rozładunek lub równoczesny 
załadunek/rozładunek),  
— pozycję, gdzie miała miejsce operacja załadunku/rozła­
dunku.  
133f) Jeżeli w momencie operacji załadunku/rozładunku pozycja 
pojazdu nie jest dostępna z odbiornika GNSS, urządzenie 
rejestrujące korzysta z ostatniej dostępnej pozycji i odpowia­
dającej jej daty i godziny.  
133g) Wraz z typem operacji i pozycją urządzenie rejestrujące 
rejestruje i przechowuje w pamięci następujące dane:  
— numer karty kierowcy lub współkierowcy i państwo 
członkowskie wydające kartę,  
— generacja karty,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 53  
— data i godzina operacji załadunku/rozładunku,  
— w stosownych przypadkach odpowiednia dokładność 
GNSS, data i godzina,  
— flagę wskazującą, czy pozycja została uwierzytelniona,  
— stan licznika kilometrów.  
133h) Pamięć danych wystarcza do przechowywania danych doty­
czących operacji załadunku/rozładunku przez co najmniej 
365 dni kalendarzowych.  
133i) W przypadku zapełnienia pamięci danych nowe dane zastę­
pują dane najstarsze.  
3.12.19  Mapa cyfrowa  
133j) Do celów rejestrowania pozycji pojazdu po przekroczeniu 
granicy krajowej urządzenie rejestrujące przechowuje 
w swojej pamięci danych mapę cyfrową.  
133k) Dopuszczone mapy cyfrowe wspierające funkcję monitoro­
wania przekroczeń granicy przez urządzenie rejestrujące są 
udostępniane przez Komisję Europejską do pobrania ze 
specjalnej zabezpieczonej strony internetowej w różnych 
formatach.  
133l) W przypadku każdej z tych map na stronie internetowej 
udostępnia się identyfikator wersji i wartość skrótu.  
133m) Mapy muszą mieć:  
— poziom szczegółowości odpowiadający poziomowi 
NUTS 0, zgodnie ze wspólną klasyfikacją jednostek 
terytorialnych do celów statystycznych,  
— skalę 1:1 mln.  
133n) Producenci tachografów wybierają mapę ze strony interne­
towej i pobierają ją w bezpieczny sposób.  
133o) Producenci tachografów wykorzystują mapę pobraną ze 
strony internetowej dopiero po sprawdzeniu jej integral­
ności przy użyciu wartości skrótu mapy.  
133p) Wybrana mapa jest importowana przez producenta do urzą­
dzenia rejestrującego we właściwym formacie, ale seman­
tyczna importowanej mapy pozostaje bez zmian.  
133q) Producent przechowuje również identyfikator wersji mapy 
wykorzystywanej w urządzeniu rejestrującym.  
133r) Możliwa jest aktualizacja lub zastąpienie przechowywanej 
mapy cyfrowej nową mapą udostępnioną przez Komisję 
Europejską.  
133s) Aktualizacje mapy cyfrowej przeprowadza się przy użyciu 
mechanizmów aktualizacji oprogramowania ustalonych 
przez producenta, zgodnie z wymogami 226d i 226e, tak 
aby urządzenie rejestrujące mogło zweryfikować autentycz­
ność i integralność nowej importowanej mapy przed jej 
zapisaniem i zastąpieniem poprzedniej mapy.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 54  
133t) Producenci tachografów mogą dodać dodatkowe informacje 
do mapy podstawowej, o której mowa w wymogu 133 m, 
w celach innych niż rejestrowanie przekroczeń granicy, np. 
granic regionów UE, pod warunkiem że nie nastąpi zmiana 
semantyki mapy podstawowej.  
▼B 
3.13 Odczyt kart do tachografów  
134) Urządzenie rejestrujące umożliwia odczyt z kart do tacho­
grafów pierwszej i drugiej generacji, w odpowiednich przy­
padkach, danych niezbędnych do:  
— rozpoznania typu karty, posiadacza karty, wcześniej 
używanego pojazdu, daty i godziny ostatniego wyjęcia 
karty i czynności wybranej dla tego czasu,  
— sprawdzenia, czy ostatnia sesja karty została prawid­ 
łowo zamknięta,  
▼M3 
— wyliczenia dla kierowcy: nieprzerwanego czasu prowa­
dzenia pojazdu, skumulowanego czasu przerwy i skumu­
lowanego czasu prowadzenia za poprzedni i bieżący 
tydzień,  
▼B 
— wydrukowania żądanych wydruków związanych 
z danymi zarejestrowanymi na karcie kierowcy,  
— pobrania danych z karty kierowcy na zewnętrzny 
nośnik.  
Wymóg ten ma zastosowanie tylko do kart do tachografów 
pierwszej generacji, jeżeli ich stosowanie nie zostało wyłą­
czone przez warsztat.  
135) W przypadku błędu odczytu urządzenie rejestrujące maksy­
malnie trzykrotnie powtarza to samo polecenie odczytu 
i w przypadku gdy odczyt nadal nie jest możliwy, uznaje 
kartę za uszkodzoną i nieważną.  
▼M3 
135a) Struktura aplikacji „TACHO_G2” zależy od wersji. Karty 
wersji 2 zawierają dodatkowe pliki elementarne w stosunku 
do kart wersji 1, w szczególności:  
— w kartach kierowcy i warsztatowych:  
— EF Places_Authentication zawiera status uwierzytel­
nienia pozycji pojazdu przechowywanych w EF 
Places. Znacznik czasu jest przechowywany 
z każdym statusem uwierzytelnienia, który musi 
być dokładnie taki sam, jak data i godzina wpisu 
przechowywanego z odpowiednią pozycją w EF 
Places.  
— EF GNSS_Places_Authentication zawiera status 
uwierzytelnienia pozycji pojazdu przechowywanych 
w EF GNSS_Places. Znacznik czasu jest przecho­
wywany z każdym statusem uwierzytelnienia, który 
musi być dokładnie taki sam, jak data i godzina 
wpisu przechowywanego z odpowiednią pozycją 
w EF Places.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 55  
— EF Border_Crossings, EF Load_Unload_Operations 
oraz EF Load_Type_Entries zawierają dane doty­
czące przekroczeń granicy, operacji załadunku/ 
rozładunku oraz typów załadunku;  
— w kartach warsztatowych:  
— EF Calibration_Add_Data zawiera dodatkowe dane 
kalibracyjne poza danymi przechowywanymi w EF 
Calibration. Stara wartość daty i godziny oraz numer 
identyfikacyjny pojazdu przechowywane są wraz 
z każdym dodatkowym rekordem danych dotyczą­
cych kalibracji, który jest dokładnie taki sam, jak 
stara wartość daty i godziny oraz numer identyfika­
cyjny pojazdu przechowywane wraz z odpowiednimi 
danymi kalibracyjnymi w EF Calibration;  
— we wszystkich kartach do tachografów:  
— EF VU_Configuration zawiera szczegółowe usta­
wienia tachografu posiadacza karty.  
Przyrząd rejestrujący nie uwzględnia żadnego statusu uwie­
rzytelnienia znalezionego w EF Places_Authentication lub 
EF GNSS_Places_Authentication, jeżeli w EF Places lub 
EF GNSS_Places nie znaleziono pozycji pojazdu z tym 
samym znacznikiem czasu.  
Przyrząd rejestrujący ignoruje plik elementarny EF VU_Confi­
guration we wszystkich kartach, o ile nie określono szczegó­ 
łowych zasad dotyczących korzystania z takiego pliku elemen­
tarnego. Zasady te określa się poprzez zmianę załącznika IC, 
która obejmuje modyfikację lub uchylenie niniejszego punktu.  
▼B 
3.14 Rejestrowanie i przechowywanie danych na kartach do tacho ­
grafów  
3.14.1  Rejestrowanie i przechowywanie danych na kartach do tachografów 
pierwszej generacji  
136) O ile karty do tachografów pierwszej generacji nie zostały  
wyłączone przez warsztat, urządzenie rejestrujące rejestruje 
i przechowuje dane dokładnie w ten sam sposób co urzą­
dzenie rejestrujące pierwszej generacji.  
137) Urządzenie rejestrujące ustawia „dane sesji karty” na karc ie 
kierowcy lub warsztatowej bezpośrednio po włożeniu karty.  
138) Urządzenie rejestrujące aktualizuje dane zapisane na ważne j 
karcie kierowcy, warsztatowej, firmowej lub kontrolnej, 
wprowadzając wszystkie niezbędne dane odnośnie do 
okresu, w którym karta pozostaje włożona, i odnośnie do 
posiadacza karty. Dane, które są przechowywane na tych 
kartach, określono w rozdziale 4.  
139) Urządzenie rejestrujące aktualizuje dane dotyczące czyn­
ności kierowcy i miejsc (jak określono w pkt 4.5.3.1.9 
i 4.5.3.1.11), zapisane na ważnej karcie kierowcy lub 
warsztatowej, danymi dotyczącymi czynności i miejsc 
wprowadzonymi ręcznie przez posiadacza karty.  
▼M3 
140) Wszystkie zdarzenia niezdefiniowane dla urządzeń rejestru­
jących pierwszej generacji nie są zapisywane na karcie 
kierowcy ani na karcie warsztatowej.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 56  
141) Aktualizacja kart do tachografów odbywa się w taki 
sposób, że gdy zaistnieje taka potrzeba i biorąc pod 
uwagę rzeczywistą zdolność przechowywania danych, 
najstarsze dane są zastępowanymi najnowszymi danymi.  
142) W przypadku błędu zapisu urządzenie rejestrujące maksy­
malnie trzykrotnie powtarza to samo polecenie zapisu 
i w przypadku gdy zapis nadal nie jest możliwy, uznaje 
kartę za uszkodzoną i nieważną.  
▼M3 
143) Przed odblokowaniem karty kierowcy lub karty warsz­
tatowej i po zapisaniu na karcie wszystkich stosownych 
danych urządzenie rejestrujące zeruje „dane sesji karty”.  
▼B 
3.14.2  Rejestrowanie i przechowywanie danych na kartach do tachografów 
drugiej generacji  
144) Karty do tachografów drugiej generacji zawierają 2 różne 
aplikacje kart, z których pierwsza jest dokładnie taka sama 
jak aplikacja TACHO w kartach do tachografów pierwszej 
generacji, a druga aplikacja „TACHO_G2” jest zgodna ze 
specyfikacjami w rozdziale 4 i dodatku 2.  
▼M3 
Struktura aplikacji „TACHO_G2” zależy od wersji. Karty 
wersji 2 zawierają dodatkowe pliki elementarne w stosunku 
do kart wersji 1.  
▼B 
145) Urządzenie rejestrujące ustawia „dane sesji karty” na karc ie 
kierowcy lub warsztatowej bezpośrednio po włożeniu karty.  
146) Urządzenie rejestrujące aktualizuje dane zapisane w 2 apli ­
kacjach ważnej karty kierowcy, warsztatowej, firmowej lub 
kontrolnej, wprowadzając wszystkie niezbędne dane 
odnośnie do okresu, w którym karta pozostaje włożona, 
i odnośnie do posiadacza karty. Dane, które są przechowy­
wane na tych kartach, określono w rozdziale 4.  
147) Urządzenie rejestrujące aktualizuje dane dotyczące miejsc 
i pozycji czynności kierowcy (jak określono w pkt 
4.5.3.1.9, 4.5.3.1.11, 4.5.3.2.9 i 4.5.3.2.11), zapisane na 
ważnej karcie kierowcy lub warsztatowej, danymi dotyczą­
cymi czynności i miejsc wprowadzonymi ręcznie przez 
posiadacza karty.  
▼M3 
147a) Po włożeniu karty kierowcy lub karty warsztatowej urzą­
dzenie rejestrujące zapisuje na karcie domyślny typ zała­
dunku pojazdu.  
147b) Po włożeniu karty kierowcy lub karty warsztatowej i po 
ręcznej procedurze wprowadzania danych urządzenie rejes­
trujące sprawdza ostatnie miejsce rozpoczęcia lub zakoń­
czenia dziennego okresu pracy zapisane na karcie. Miejsce 
to może mieć charakter tymczasowy, jak określono 
w wymogu 59. Jeżeli miejsce to znajduje się w innym 
kraju niż bieżący kraj, w którym pojazd się znajduje, urzą­
dzenie rejestrujące przechowuje na karcie rekord przekro­
czenia granicy wraz z następującymi danymi:  
— krajem, który opuścił kierowca: niedostępne,  
— krajem, do którego wjeżdża kierowca: bieżący kraj, 
w którym pojazd się znajduje,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 57  
— datą i godziną przekroczenia granicy przez kierowcę: 
godzina włożenia karty,  
— pozycją kierowcy po przekroczeniu granicy: niedo­
stępne,  
— stanem licznika kilometrów: niedostępne.  
▼B 
148) Aktualizacja kart do tachografów odbywa się w taki sposób,  
że gdy zaistnieje taka potrzeba i biorąc pod uwagę rzeczy­
wistą zdolność przechowywania danych, najstarsze dane są 
zastępowanymi najnowszymi danymi.  
149) W przypadku błędu zapisu urządzenie rejestrujące maksy­
malnie trzykrotnie powtarza to samo polecenie zapisu 
i w przypadku gdy zapis nadal nie jest możliwy, uznaje 
kartę za uszkodzoną i nieważną.  
150) Przed odblokowaniem karty kierowcy i po zapisaniu 
wszystkich stosownych danych w 2 aplikacjach karty urzą­
dzenie rejestrujące zeruje „dane sesji karty”.  
▼M3 
150a) Przyrząd rejestrujący ignoruje plik elementarny EF VU_Con fi­
guration we wszystkich kartach, o ile nie określono szczegó­ 
łowych zasad dotyczących korzystania z takiego pliku elemen­
tarnego. Zasady te określa się poprzez zmianę załącznika IC, 
która obejmuje modyfikację lub uchylenie niniejszego punktu.  
▼B 
3.15 Wy świetlanie  
151) Wyświetlacz umożliwia wyświetlanie co najmniej 20 
znaków.  
152) Wyświetlane znaki mają wymiary co najmniej 5 mm wyso­
kości i 3,5 mm szerokości.  
153) Wyświetlacz umożliwia wyświetlanie znaków określonych 
w dodatku 1 rozdział 4 „Zestawy znaków”. Wyświetlacz 
może wyświetlać uproszczone glify (np. znaki z akcentami 
można wyświetlać bez akcentu, a małe litery może 
wyświetlać jako duże).  
154) Wyświetlacz musi mieć nieoślepiające oświetlenie.  
155) Wskazania są widoczne spoza urządzenia rejestrującego.  
156) Urządzenie rejestrujące umożliwia wyświetlanie:  
— informacji standardowych,  
— informacji związanych z ostrzeżeniami,  
— informacji związanych z dostępem do menu,  
— innych informacji, których zażąda użytkownik.  
Urządzenie rejestrujące może wyświetlać również dodat­
kowe informacje, z tym jednak, że muszą być one łatwe 
do odróżnienia od wymienionych powyżej, wymaganych 
informacji.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 58  
157) Na wyświetlaczu urządzenia rejestrującego używa się pikto­
gramów lub kombinacji piktogramów wymienionych 
w dodatku 3. Dopuszcza się także dodatkowe piktogramy 
lub kombinacje piktogramów, jeżeli są one łatwe do odróż­
nienia od wymaganych piktogramów lub kombinacji pikto­
gramów.  
158) Gdy pojazd jest w ruchu, wyświetlacz jest stale włączony.  
159) Urządzenie rejestrujące może gasić wyświetlacz automa­
tycznie lub umożliwiać gaszenie ręczne, gdy pojazd nie 
jest w ruchu.  
Format wyświetlania określono w dodatku 5.  
3.15.1  Domy ślne informacje na wy świetlaczu  
160) Gdy nie istnieje potrzeba wyświetlania żadnych innych 
informacji, urządzenie rejestrujące domyślnie wyświetla 
następujące informacje:  
— czas lokalny (wynik czasu UTC + przesunięcie wpro­
wadzone przez kierowcę),  
— tryb pracy,  
— bieżącą czynność kierowcy i bieżącą czynność współ­
kierowcy,  
— informacje odnoszące się do kierowcy:  
— jeżeli jego bieżącą czynnością jest PROWADZENIE, 
jego bieżący nieprzerwany czas prowadzenia pojazdu 
i jego bieżący skumulowany czas przerwy,  
— jeżeli jego bieżącą czynnością nie jest PROWA­
DZENIE, bieżący czas trwania tej czynności (od 
momentu wybrania) i jego bieżący skumulowany czas 
przerwy.  
161) Prezentacja informacji odnoszących się do każdego 
kierowcy jest wyraźna, prosta i jednoznaczna. W przypadku 
gdy informacji odnoszących się do kierowcy i współkie­
rowcy nie można wyświetlić w tym samym czasie, urzą­
dzenie rejestrujące pokazuje domyślnie informacje odno­
szące się do kierowcy i pozwala użytkownikowi wyświetlić 
informacje odnoszące się do współkierowcy.  
162) W przypadku gdy wyświetlacz nie pozwala na domyślne 
pokazywanie trybu pracy, to przy zmianie trybu pracy urzą­
dzenie rejestrujące przez krótki czas pokazuje informację 
o nowym trybie pracy.  
163) Przy wkładaniu karty urządzenie rejestrujące przez krótki 
czas pokazuje nazwisko jej posiadacza.  
164) W przypadku otwarcia warunku „POZA ZAKRESEM” lub 
„PRZEPRAWA PROMOWA/PRZEJAZD KOLEJOWY” 
na domyślnym wyświetlaczu musi pojawić się informacja 
w postaci stosownego piktogramu o tym, że warunek ten 
jest rozpoczęty (dopuszcza się, że w tym samym czasie nie 
jest pokazywana bieżąca czynność kierowcy).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 59  
3.15.2  Wy świetlanie ostrze żeń 
165) Przy wyświetlaniu ostrzeżeń urządzenie rejestrujące 
korzysta przede wszystkim z piktogramów w dodatku 3, 
w razie potrzeby uzupełnionych informacjami w postaci 
kodów liczbowych. Można też dodać wyszczególnienie 
słowne w preferowanym języku kierowcy.  
3.15.3  Dost ęp do menu  
166) Urządzenie rejestrujące udostępnia niezbędne polecenia 
poprzez odpowiednie menu.  
3.15.4  Inne wy świetlane informacje  
167) Na żądanie możliwe jest selektywne wyświetlanie:  
— czasu UTC oraz przesunięcia czasu lokalnego,  
▼M3 
— treści każdego z wydruków wymienionych w wymogu 
169 w takich samych formatach co wydruki,  
▼B 
— nieprzerwanego czasu prowadzenia pojazdu i skumulo­
wanego czasu przerwy kierowcy,  
— nieprzerwanego czasu prowadzenia pojazdu i skumulo­
wanego czasu przerwy współkierowcy,  
▼M3 
— skumulowanego czasu prowadzenia pojazdu przez 
kierowcę za poprzedni i bieżący tydzień,  
— skumulowanego czasu prowadzenia pojazdu przez 
współkierowcę za poprzedni i bieżący tydzień,  
▼B 
opcjonalnie:  
— bieżącego czasu trwania czynności współkierowcy (od 
momentu wybrania),  
▼M3 
— skumulowanego czasu prowadzenia pojazdu przez 
kierowcę za bieżący tydzień,  
— skumulowanego czasu prowadzenia pojazdu przez 
współkierowcę za bieżący dzienny okres pracy,  
— skumulowanego czasu prowadzenia pojazdu przez 
kierowcę za bieżący dzienny okres pracy.  
▼B 
168) Treść wydruku jest wyświetlana sekwencyjnie, wiersz po 
wierszu. Jeżeli w szerokości wyświetlacza mieści się mniej 
niż 24 znaki, użytkownik musi mieć dostęp do pełnej infor­
macji w odpowiedni sposób (w kilku wierszach, przy 
pomocy przewijania itp.).  
Wiersze wydruku przeznaczone na ręczne adnotacje można 
pominąć na wyświetlaczu.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 60  
3.16 Drukowanie  
169) Urządzenie rejestrujące umożliwia drukowanie siedmiu 
określonych poniżej wydruków, na podstawie informacji 
zgromadzonych w pamięci urządzenia lub na kartach do 
tachografów:  
— wydruk dzienny czynności kierowcy z karty,  
— wydruk dzienny czynności kierowcy z przyrządu rejes­
trującego,  
— wydruk zdarzeń i usterek z karty,  
— wydruk zdarzeń i usterek z przyrządu rejestrującego,  
— wydruk danych technicznych,  
— wydruk przekroczenia prędkości,  
— historia danych karty do tachografu dla danego przy­
rządu rejestrującego (zob. rozdział 3.12.16).  
Szczegóły formatu i treści tych wydruków określono 
w dodatku 4.  
Pod koniec wydruku mogą być umieszczane informacje 
dodatkowe.  
Urządzenie rejestrujące może wykonywać także dodatkowe 
wydruki, jeżeli są one łatwe do odróżnienia od siedmiu 
określonych powyżej wydruków.  
170) „Wydruk dzienny czynności kierowcy z karty” i „wydruk 
zdarzeń i usterek z karty” dostępne są jedynie wtedy, gdy 
do urządzenia rejestrującego włożona jest karta kierowcy 
lub karta warsztatowa. Przed uruchomieniem drukowania 
urządzenie rejestrujące aktualizuje dane przechowywane 
na stosownej karcie.  
171) W celu sporządzenia „wydruku dziennego czynności 
kierowcy z karty” lub „wydruku zdarzeń i usterek z karty” 
urządzenie rejestrujące:  
— automatycznie wybiera kartę kierowcy lub kartę warsz­
tatową, jeżeli tylko jedna z tych kart jest włożona do 
urządzenia rejestrującego,  
— lub umożliwia wybór karty źródłowej albo wybiera 
kartę znajdującą się w czytniku karty kierowcy, jeżeli 
obie te karty włożone są do urządzenia rejestrującego.  
172) Drukarka umożliwia drukowanie 24 znaków w wierszu.  
173) Drukowane znaki mają wymiary co najmniej 2,1 mm 
wysokości i 1,5 mm szerokości.  
174) Drukarka umożliwia drukowanie znaków określonych 
w dodatku 1 rozdział 4 „Zestawy znaków”.  
175) Konstrukcja drukarki umożliwia sporządzanie wydruków 
z rozdzielczością eliminującą niejednoznaczność przy 
odczycie.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 61  
176) Wydruki zachowują wymiary i treść w warunkach 
normalnej wilgotności (10–90 %) i temperatury.  
177) Papier homologowany używany w urządzeniu rejestrującym 
musi mieć odpowiedni znak homologacji typu i oznako­
wanie typu (typów) urządzenia rejestrującego, w którym 
może być używany.  
178) Wydruki muszą być łatwe do odczytania i rozróżnienia, 
gdy są przechowywane w normalnych warunkach przecho­
wywania, w normalnym oświetleniu, wilgotności i tempera­
turze, przez okres co najmniej dwóch lat.  
179) Wydruki muszą być zgodne co najmniej ze specyfikacjami 
testów podanymi w dodatku 9.  
180) Na wydruku musi być również możliwość umieszczenia 
ręcznych adnotacji, takich jak podpis kierowcy.  
181) Urządzenie rejestrujące obsługuje zdarzenia „brak papieru”  
w czasie drukowania, a po założeniu papieru, uruchamia 
drukowanie od początku wydruku lub kontynuuje druko­
wanie i umieszcza jednoznaczne odniesienie do części 
wcześniej wydrukowanej.  
3.17 Ostrze żenia 
182) Urządzenie rejestrujące ostrzega kierowcę o wykryciu 
zdarzenia lub usterki.  
183) Ostrzeżenie o przerwie w zasilaniu może być opóźnione do 
czasu przywrócenia zasilania.  
184) Urządzenie rejestrujące ostrzega kierowcę na 15 minut 
przed przekroczeniem i w momencie przekroczenia maksy­
malnego dopuszczalnego nieprzerwanego czasu prowa­
dzenia pojazdu.  
185) Ostrzeżenia są wizualne. Oprócz ostrzeżeń wizualnych 
dopuszcza się ostrzeżenia akustyczne.  
186) Ostrzeżenia wizualne muszą być łatwo rozpoznawalne 
przez użytkownika, znajdować się w polu widzenia 
kierowcy i być łatwe do odczytania tak w dzień, jak 
i w nocy.  
187) Ostrzeżenia wizualne mogą być emitowane bezpośrednio 
przez urządzenie rejestrujące lub zdalnie od urządzenia 
rejestrującego.  
188) W tym ostatnim przypadku są oznaczone symbolem „T”.  
189) Ostrzeżenia trwają przez przynajmniej 30 sekund, chyba że 
są potwierdzone przez użytkownika poprzez wciśnięcie 
jednego lub większej liczby specjalnych przycisków w urzą­
dzeniu rejestrującym. To pierwsze potwierdzenie nie usuwa 
z wyświetlacza informacji o przyczynie ostrzeżenia, o której 
mowa w następnym punkcie.  
190) Urządzenie rejestrujące wyświetla informację o przyczynie 
ostrzeżenia, aż do momentu potwierdzenia przez użytkow­
nika przy pomocy specjalnego przycisku lub polecenia 
urządzenia rejestrującego.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 62  
191) Dopuszcza się dodatkowe ostrzeżenia, pod warunkiem że 
nie są mylące dla kierowców w odniesieniu do wcześniej 
zdefiniowanych ostrzeżeń.  
3.18 Pobieranie danych na no śnik zewn ętrzny  
192) Urządzenie rejestrujące umożliwia, na żądanie, pobieranie 
danych z pamięci danych lub karty kierowcy na zewnętrzny 
nośnik poprzez gniazdo kalibracji/pobierania danych. Przed 
pobraniem danych urządzenie rejestrujące aktualizuje dane 
przechowywane na stosownej karcie.  
▼M3 
193) Dodatkowo i opcjonalnie, urządzenie rejestrujące może 
w dowolnym trybie pracy przesyłać dane poprzez dowolny 
inny interfejs do firmy uwierzytelnionej do korzystania 
z tego kanału. W takim przypadku do tak przesyłanych 
danych stosuje się prawa dostępu obowiązujące dla trybu 
firmowego.  
▼B 
194) Przy pobieraniu danych nie może mieć miejsca zmienianie 
ani usuwanie jakichkolwiek przechowywanych danych.  
195) Specyfikacje elektrycznego interfejsu dla gniazda kalibrac ji/ 
pobierania danych są określone w dodatku 6.  
196) Protokoły pobierania danych są określone w dodatku 7.  
▼M3 
196a) Przedsiębiorstwo transportowe wykorzystujące pojazdy 
wyposażone w urządzenia rejestrujące zgodne z niniejszym 
załącznikiem i objęte zakresem stosowania rozporzą­
dzenia (WE) nr 561/2006 zapewnia pobieranie wszystkich 
danych z przyrządu rejestrującego i kart kierowcy.  
Maksymalny okres na wczytanie odpowiednich danych nie 
przekracza:  
— 90 dni w przypadku danych z przyrządu rejestrującego;  
— 28 dni w przypadku danych z karty kierowcy.  
196b) Przedsiębiorstwa transportowe przechowują dane pobrane 
z przyrządu rejestrującego i kart kierowcy przez okres co 
najmniej dwunastu miesięcy od ich zarejestrowania.  
▼B 
3.19 Łączność na odleg łość na potrzeby ukierunkowanych kontroli 
drogowych  
197) Przy włączonym zapłonie przyrząd rejestrujący co 60 
sekund zachowuje na urządzeniu do łączności na odległość 
najnowsze dane niezbędne na potrzeby ukierunkowanych 
kontroli drogowych. Dane takie są szyfrowane i podpisy­
wane zgodnie z dodatkiem 11 i dodatkiem 14.  
198) Kontrolowane zdalnie dane muszą być dostępne dla czyt­
ników na odległość za pośrednictwem łączności bezprzewo­
dowej, jak określono w dodatku 14.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 63  
199) Dane niezbędne na potrzeby ukierunkowanych kontroli 
drogowych odnoszą się do:  
— ostatniej próby naruszenia zabezpieczenia,  
— najdłuższej przerwy w zasilaniu,  
— usterki czujnika,  
— błędu danych dotyczących ruchu,  
— konfliktu ruchu pojazdu,  
— prowadzenia pojazdu bez ważnej karty,  
— włożenia karty podczas prowadzenia pojazdu,  
— danych dotyczących korekty czasu,  
— danych kalibracyjnych, w tym dat dwóch ostatnio zapi­
sanych rekordów danych kalibracji,  
— numeru rejestracyjnego pojazdu,  
— prędkości zarejestrowanej przez tachograf,  
▼M3 
— pozycji pojazdu,  
— wskazania, czy kierowca prawdopodobnie narusza 
obecnie czas prowadzenia pojazdu.  
3.20 Wymiana danych z dodatkowymi urz ądzeniami zewn ętrznymi  
200) Urządzenie rejestrujące musi być również wyposażone 
w interfejs ITS zgodnie z dodatkiem 13, który umożliwia 
korzystanie przez urządzenie zewnętrzne z danych rejestro­
wanych lub generowanych przez tachograf lub karty do 
tachografu.  
W trybie eksploatacyjnym wymagana jest zgoda kierowcy 
na przesyłanie danych osobowych za pośrednictwem inter­
fejsu ITS. Niemniej jednak zgoda kierowcy nie ma zasto­
sowania do danych tachografu lub karty, do których uzys­
kano dostęp w trybie kontrolnym, firmowym lub kalibra­
cyjnym. Dane i funkcjonalne prawa dostępu dla tych 
trybów określono w wymogach 12 i 13.  
Następujące wymogi mają zastosowanie do danych ITS 
udostępnianych za pośrednictwem tego interfejsu:  
— dane osobowe są udostępniane wyłącznie po uzyskaniu 
możliwej do zweryfikowania zgody kierowcy na to, aby 
dane osobowe z tachografu mogły opuścić sieć pojazdu.  
Zestaw wybranych istniejących danych, które mogą być 
dostępne za pośrednictwem interfejsu ITS, oraz klasyfi­
kację danych jako danych osobowych lub nieosobo­
wych określono w dodatku 13. Oprócz zestawu danych 
przedstawionego w dodatku 13 mogą być również 
generowane dodatkowe dane. Producent VU klasyfikuje 
te dane jako „osobowe” lub „nieosobowe”, a zgoda 
kierowcy dotyczy danych sklasyfikowanych jako 
„osobowe”,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 64  
— w dowolnym momencie istnieje możliwość potwier­
dzenia lub wycofania zgody kierowcy przez wybranie 
polecenia w menu, pod warunkiem że karta kierowcy 
jest włożona,  
— w żadnych okolicznościach obecność interfejsu ITS nie 
może zakłócać prawidłowego funkcjonowania i bezpie­
czeństwa przyrządu rejestrującego ani oddziaływać na 
niego.  
Dodatkowe interfejsy przyrządu rejestrującego mogą współ­
istnieć, pod warunkiem że są w pełni zgodne z wymogami 
określonymi w dodatku 13 w odniesieniu do zgody 
kierowcy. Urządzenie rejestrujące musi posiadać zdolność 
do podawania statusu zgody kierowcy innym platformom 
w sieci pojazdu oraz urządzeniom zewnętrznym.  
W przypadku danych osobowych wprowadzonych do sieci 
pojazdu, które są dalej przetwarzane poza siecią pojazdu, 
producent tachografów nie jest zobowiązany do zapew­
nienia zgodności procedury przetwarzania danych osobo­
wych z mającymi zastosowanie przepisami Unii dotyczą­
cymi ochrony danych.  
Interfejs ITS umożliwia również wprowadzanie danych 
podczas procedury ręcznego wprowadzania danych zgodnie 
z wymogiem 61, zarówno przez kierowcę, jak i współkie­
rowcę.  
Interfejs ITS może być również wykorzystywany do wpro­
wadzania dodatkowych informacji, w czasie rzeczywistym, 
takich jak:  
— wybór czynności kierowcy, zgodnie z wymogiem 46,  
— miejsca, zgodnie z wymogiem 56,  
— stany szczególne, zgodnie z wymogiem 62,  
— operacje załadunku/rozładunku, zgodnie z wymogiem 
62a. 
Informacje te mogą być również wprowadzane za pośred­
nictwem innych interfejsów.  
201) Do celów kompatybilności wstecznej możliwe jest wyposa­ 
żenie tachografów w interfejs szeregowy, jak określono 
w załączniku IB do rozporządzenia (EWG) nr 3821/85 
w ostatniej zmienionej wersji. Łącze szeregowe klasyfikuje 
się jako część sieci pojazdu, zgodnie z wymogiem 200.  
▼B 
3.21 Kalibracja  
202) Funkcja kalibracji umożliwia:  
— automatyczne sparowanie czujnika ruchu z przyrządem 
rejestrującym,  
— automatyczne powiązanie urządzenia zewnętrznego 
GNSS z przyrządem rejestrującym w stosownych 
przypadkach,  
— cyfrowe dostosowanie stałej urządzenia rejestrującego 
(k) do współczynnika charakterystycznego pojazdu (w),  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 65  
— regulację bieżącego wskazania czasu w zakresie okresu 
ważności włożonej karty warsztatowej,  
— regulację bieżącego wskazania licznika kilometrów,  
— aktualizację danych identyfikacyjnych czujnika ruchu 
zapisanych w pamięci danych,  
— aktualizację, w stosownych przypadkach, danych iden­
tyfikacyjnych urządzenia zewnętrznego GNSS zapisa­
nych w pamięci danych,  
— aktualizację rodzajów i identyfikatorów wszystkich 
założonych plomb,  
▼M3 
— aktualizację lub potwierdzenie innych parametrów 
używanych przez urządzenie rejestrujące: identyfikację 
pojazdu, w, l, rozmiar opon i ustawienie urządzenia 
ograniczenia prędkości, w stosownych przypadkach, 
oraz domyślny typ załadunku,  
— automatyczne zapisywanie kraju, w którym wykonano 
kalibrację, oraz daty i godziny dostarczenia przez 
odbiornik GNSS pozycji wykorzystanej do określenia 
tego kraju.  
▼B 
203) Ponadto funkcja kalibracji umożliwia wyłączenie stoso­
wania kart do tachografów pierwszej generacji w urządzeniu 
rejestrującym pod warunkiem spełnienia wymogów okre­ 
ślonych w dodatku 15.  
204) Parowanie czujnika ruchu z przyrządem rejestrującym obej­
muje co najmniej:  
— aktualizację danych instalacyjnych czujnika ruchu zapi­
sanych w pamięci czujnika ruchu (w razie potrzeby),  
— skopiowanie z czujnika ruchu do pamięci danych przy­
rządu rejestrującego niezbędnych danych identyfikacyj­
nych czujnika ruchu.  
▼M3 
205) Powiązanie urządzenia zewnętrznego GNSS z przyrządem 
rejestrującym obejmuje co najmniej:  
— aktualizację danych instalacyjnych urządzenia zewnętrz­
nego GNSS przechowywanych na urządzeniu 
zewnętrznym GNSS (w razie potrzeby),  
— skopiowanie z urządzenia zewnętrznego GNSS do 
pamięci danych przyrządu rejestrującego niezbędnych 
danych identyfikacyjnych GNSS, w tym numeru seryj­
nego urządzenia zewnętrznego GNSS.  
▼B 
206) Funkcja kalibracji umożliwia wprowadzanie niezbędnych 
danych poprzez gniazdo kalibracji/pobierania danych 
zgodnie z protokołem kalibracji zdefiniowanym w dodatku 
8. Funkcja kalibracji może także umożliwiać wprowadzanie 
niezbędnych danych w inny sposób.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 66  
3.22 Kontrola drogowa kalibracji  
207) Funkcja kontroli drogowej kalibracji umożliwia odczyt 
numeru seryjnego czujnika (ewentualnie wbudowanego 
w adapter) oraz numeru seryjnego urządzenia zewnętrznego 
GNSS (w odpowiednich przypadkach), podłączonych do 
przyrządu rejestrującego w momencie wysłania żądania.  
208) Odczyt musi być możliwy na wyświetlaczu przyrządu 
rejestrującego przynajmniej przez wybranie poleceń 
w menu.  
209) Funkcja kontroli drogowej kalibracji umożliwia również 
kontrolowanie wybranego trybu we/wy linii sygnałowej 
we/wy kalibracji, określonej w dodatku 6, za pośrednic­
twem interfejsu K-line. Wykonuje się to poprzez ECUAd­
justmentSession, jak określono w dodatku 8 sekcja 7 Stero­
wanie impulsami testującymi – Jednostka funkcjonalna 
sterowania we/wy.  
▼M3 
Jeżeli tryb we/wy linii sygnałowej we/wy kalibracji jest 
aktywny zgodnie z tym wymogiem, przyrząd rejestrujący 
nie uruchamia ostrzeżenia „Prowadzenie pojazdu bez 
prawidłowej karty” (wymóg 75).  
▼B 
3.23 Korekta czasu  
210) Funkcja korekty czasu umożliwia automatyczną korektę 
bieżącego czasu. W urządzeniu rejestrującym korzysta się 
z dwóch źródeł czasu do celów korekty czasu: 1) 
wewnętrznego zegara przyrządu rejestrującego, 2) odbior­
nika GNSS.  
▼M3 
211) Ustawienia czasu wewnętrznego zegara przyrządu rejestru­
jącego są automatycznie korygowane w zmiennych odstę­
pach czasu. Kolejna automatyczna korekta czasu urucha­
miana jest między 72 a 168 godz. po poprzedniej korekcie 
oraz po tym, jak VU będzie mógł uzyskać dostęp do czasu 
GNSS za pomocą komunikatu o prawidłowej uwierzytel­
nionej pozycji zgodnie z dodatkiem 12. Niemniej jednak 
korekta czasu nie może nigdy przekroczyć skumulowanego 
maksymalnego dryftu czasu na dzień, obliczonego przez 
producenta VU zgodnie z wymogiem 41b. Jeżeli różnica 
między czasem wewnętrznego zegara VU a czasem odbior­
nika GNSS jest większa niż skumulowany maksymalny 
dryft czasu na dzień, wówczas korekta czasu musi dosto­
sować zegar wewnętrzny VU możliwie jak najbliżej czasu 
odbiornika GNSS. Ustawienia czasu można dokonać tylko 
wówczas, gdy czas podawany przez odbiornik GNSS jest 
uzyskiwany przy użyciu komunikatów o uwierzytelnionej 
pozycji określonych w dodatku 12. Czasem odniesienia dla 
automatycznego ustawienia czasu wewnętrznego zegara VU 
jest czas podany w komunikacie o uwierzytelnionej 
pozycji.  
212) W trybie kalibracyjnym funkcja korekty czasu umożliwia 
również wymuszoną korektę bieżącego czasu.  
Warsztaty mogą korygować czas:  
— albo zapisując wartość czasu w VU, korzystając z usługi 
WriteDataByIdentifier zgodnie z sekcją 6.2 w dodatku 8,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 67  
— albo poprzez zwrócenie się o dostosowanie zegara VU 
do czasu podawanego przez odbiornik GNSS. Można 
tego dokonać tylko wówczas, gdy czas podawany przez 
odbiornik GNSS jest uzyskiwany przy użyciu komuni­
katów o uwierzytelnionej pozycji. W tym ostatnim 
przypadku wykorzystuje się usługę RoutineControl 
zgodnie z sekcją 8 w dodatku 8.  
▼B 
3.24 Parametry pracy  
213) Przyrząd rejestrujący musi być w pełni funkcjonalny 
w zakresie temperatur – 20–70 °C, urządzenie zewnętrzne 
GNSS w zakresie temperatur – 20–70 °C, a czujnik ruchu 
w zakresie temperatur – 40–135 °C. Zawartość pamięci 
danych jest zachowywana w temperaturach do – 40 °C.  
214) Tachograf zachowuje pełną funkcjonalność w zakresie 
wilgotności 10–90 %.  
215) Plomby używane w tachografach inteligentnych muszą być 
wytrzymałe w takich samych warunkach, co warunki stoso­
wane względem elementów składowych tachografu, do 
których są dołączone.  
216) Urządzenie rejestrujące jest zabezpieczone przed przepię­
ciami, odwróceniem biegunowości zasilania i zwarciami.  
217) Czujniki ruchu muszą:  
— reagować na pole magnetyczne, które zakłóca wykry­
wanie ruchu pojazdu. W takich okolicznościach przy­
rząd rejestrujący zarejestruje i zapisze w pamięci 
usterkę czujnika (wymaganie 88); albo  
— posiadać czujnik, który jest chroniony przed polami 
magnetycznymi lub odporny na nie.  
218) Urządzenie rejestrujące oraz urządzenie zewnętrzne GNSS 
muszą być zgodne z międzynarodowym regulaminem EKG 
ONZ nr 10 oraz być zabezpieczone przed skutkami wyła­
dowań elektrostatycznych oraz stanów nieustalonych.  
3.25 Materia ły 
219) Wszystkie części składowe urządzenia rejestrującego są 
wykonane z materiałów o wystarczającej stabilności 
i wytrzymałości mechanicznej oraz stabilnych właściwo­ 
ściach elektrycznych i magnetycznych.  
220) W normalnych warunkach eksploatacji wszystkie części 
wewnętrzne urządzeń są zabezpieczone przed wilgocią 
i pyłem.  
221) Przyrząd rejestrujący i urządzenie zewnętrzne GNSS muszą 
spełniać wymagania klasy ochrony IP 40, a czujnik ruchu 
musi spełniać wymagania klasy ochrony IP 64 zgodnie 
z normą IEC 60529:1989 łącznie z A1:1999 i A2:2013.  
222) Urządzenie rejestrujące musi spełniać odpowiednie wyma­
gania techniczne odnoszące się do ergonomii.  
223) Urządzenie rejestrujące jest zabezpieczone przed przypad­
kowym uszkodzeniem.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 68  
3.26 Oznakowania  
224) Jeżeli urządzenie rejestrujące pokazuje stan licznika kilo ­
metrów i prędkość, na wyświetlaczu widoczne są następu­
jące informacje:  
— przy liczbie pokazującej odległość, jednostka miary 
odległości wskazana skrótem „km”,  
— przy liczbie pokazującej prędkość, jednostka „km/h”.  
Urządzenie rejestrujące może być również przełączane na 
wskazywanie prędkości w milach na godzinę, w takim 
przypadku jednostka pomiaru prędkości jest wskazana 
skrótem „mph”. Urządzenie rejestrujące może być również 
przełączane na wskazywanie odległości w milach, w takim 
przypadku jednostka pomiaru odległości jest wskazana 
skrótem „mi”.  
▼M1 
225) Do każdego odrębnego elementu składowego urządzenia 
rejestrującego jest przymocowana tabliczka zawierająca 
następujące informacje:  
— nazwa i adres producenta,  
— numer części producenta i rok produkcji,  
— numer seryjny,  
— znak homologacji typu.  
226) Jeżeli dostępna powierzchnia nie wystarcza do umiesz­
czenia wszystkich powyższych informacji, na tabliczce 
umieszcza się przynajmniej: nazwę producenta lub jego 
logo i numer części.  
▼M3 
3.27 Monitorowanie przekrocze ń granicy  
226a) Funkcja ta wykrywa, kiedy pojazd przekroczył granicę 
krajową, który kraj opuścił oraz do którego kraju wjechał.  
226b) Wykrywanie przekroczenia granicy opiera się na pozycji 
zmierzonej przez urządzenie rejestrujące oraz mapie 
cyfrowej przechowywanej zgodnie z pkt 3.12.19.  
226c) Przekroczenia granicy związane z obecnością pojazdu 
w danym kraju przez okres krótszy niż 120 s nie są 
rejestrowane.  
3.28 Aktualizacja oprogramowania  
226d) Przyrząd rejestrujący musi posiadać funkcję wdrażania 
aktualizacji oprogramowania, jeżeli takie aktualizacje nie 
wymagają dostępności dodatkowych zasobów sprzętowych 
wykraczających poza zasoby określone w wymogu 226f, 
a organy udzielające homologacji typu udzielają zezwolenia 
na aktualizacje oprogramowania oparte na istniejącym przy­
rządzie rejestrującym posiadającym homologację typu, 
zgodnie z art. 12 ust. 5 rozporządzenia (UE) nr 165/2014.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 69  
226e) Funkcja aktualizacji oprogramowania musi być zaprojekto­
wana w taki sposób, aby wspierać następujące aspekty 
funkcjonalne, jeżeli są one prawnie wymagane:  
— modyfikacja funkcji, o których mowa w pkt 2.2, 
z wyjątkiem samej funkcji aktualizacji oprogramowania,  
— dodawanie nowych funkcji bezpośrednio związanych 
z egzekwowaniem przepisów Unii dotyczących trans­
portu drogowego,  
— modyfikacja trybów pracy określonych w pkt 2.3,  
— modyfikacja struktury pliku, np. dodanie nowych 
danych lub zwiększenie rozmiaru pliku,  
— wdrożenie łatek oprogramowania w celu zaradzenia 
usterkom oprogramowania oraz zabezpieczeń lub zgło­
szonym atakom na funkcje urządzenia rejestrującego.  
226f) Przyrząd rejestrujący zapewnia bezpłatne zasoby sprzętowe  
na poziomie co najmniej 35 % dla oprogramowania 
i danych potrzebnych do wdrożenia wymogu 226e oraz 
bezpłatne zasoby sprzętowe na poziomie co najmniej 
65 % na potrzeby aktualizacji mapy cyfrowej w oparciu 
o zasoby sprzętowe wymagane dla wersji mapy NUTS 0 
z 2021 r.  
▼B 
4 WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE KART 
DO TACHOGRAFÓW  
4.1 Dane widzialne  
Na awersie znajdują się:  
227) słowa „Karta kierowcy” lub „Karta kontrolna” lub „Karta 
warsztatowa” lub „Karta firmowa” nadrukowane wersali­
kiem w języku urzędowym lub językach urzędowych 
państwa członkowskiego wydającego kartę, odpowiednio 
do rodzaju karty;  
228) nazwa państwa członkowskiego wydającego kartę (nieobo­
wiązkowo);  
229) wyróżniający znak państwa członkowskiego wydającego 
kartę, drukowany w negatywie w niebieskim prostokącie 
i otoczony 12 żółtymi gwiazdami. Obowiązują następujące 
oznaczenia: 
B 
BG 
CZ 
CY Belgia 
Bułgaria 
Republika Czeska 
Cypr  LV 
L 
LT 
M Łotwa 
Luksemburg 
Litwa 
Malta  
DK Dania  N L  Niderlandy  
D 
EST Niemcy 
Estonia  A 
PL Austria 
Polska  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 70  
GR Grecja  P  
RO 
SK 
SLO  Portugalia 
Rumunia 
Słowacja 
Słowenia  
E Hiszpania  FIN  Finlandia  
F 
HR 
H Francja 
Chorwacja 
Węgry  S Szwecja  
IRL Irlandia  U K  Zjednoczone 
Królestwo  
I Włochy  
230) informacje szczególne dla wydanej karty, ponumerowane 
jak następuje:  
Karta kierowcy  Karta kontrolna  Karta firmowa lub warsztatowa  
1. Nazwisko kierowcy  Nazwa organu kontrolnego  Nazwa firmy lub warsztatu  
2. Imię (imiona) kierowcy  Nazwisko kontrolera 
(w stosownych przypad­
kach)  Nazwisko posiadacza karty 
(w stosownych przypad­
kach)  
3. Data urodzenia kierowcy  Imię (imiona) kontrolera 
(w stosownych przypad­
kach)  Imię (imiona) posiadacza 
karty 
(w stosownych przypad­
kach)  
4.a Data początku okresu ważności karty  
4.b Termin ważności karty  
4.c Nazwa organu wydającego (może być wydrukowana na rewersie)  
4.d Numer inny niż w pozycji 5 do celów administracyjnych (fakulta tywnie)  
5.a Numer prawa jazdy 
(w dniu wydania karty 
kierowcy)  — —  
5.b Numer karty  
6. Zdjęcie kierowcy  Zdjęcie kontrolera (fakulta­
tywnie)  Zdjęcie instalatora (fakulta­
tywnie)  
7. Podpis posiadacza karty (fakultatywnie)  
8. Miejsce stałego zamiesz­
kania lub adres pocztowy 
posiadacza (fakultatywnie)  Adres pocztowy organu 
kontrolnego  Adres pocztowy firmy lub 
warsztatu  
231) daty podaje się w formacie „dd/mm/rrrr” lub „dd.mm.rrrr” 
(dzień, miesiąc, rok).  
Na rewersie znajdują się:  
232) objaśnienia numerowanych pozycji znajdujących się na 
awersie karty;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 71  
233) za szczególną pisemną zgodą posiadacza karty, na karcie 
można dodatkowo umieścić informacje, które nie wiążą się 
z administrowaniem kartą; takie dodatkowe informacje 
w żaden sposób nie zmieniają sposobu używania danego 
modelu jako karty do tachografów;  
234) Karty do tachografów drukuje się w następujących domi­
nujących kolorach tła:  
— karta kierowcy: biały,  
— karta kontrolna: niebieski,  
— karta warsztatowa: czerwony,  
— karta firmowa: żółty.  
235) Karty do tachografów muszą mieć przynajmniej następu­
jące zabezpieczenia przed fałszowaniem i manipulacjami:  
— zabezpieczający wzór tła z drukowanym drobnym gilo­
szem i drukiem irysowym,  
— w obszarze zdjęcia zabezpieczający wzór tła i zdjęcie 
zachodzą na siebie,  
— przynajmniej dwubarwną linię wykonaną techniką 
mikrodruku.
  
► (1) M1 
► (2) M3 
236) Po konsultacji z Komisją państwa członkowskie mogą 
dodać kolory lub oznakowania, takie jak symbole 
państwowe i zabezpieczenia, bez uszczerbku dla innych 
przepisów w niniejszym załączniku.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 72  
237) Karty czasowe, o których mowa w art. 26 ust. 4 rozporzą­
dzenia (UE) nr 165/2014, muszą być zgodne z przepisami 
niniejszego załącznika.  
4.2 Zabezpieczenia  
Celem systemu zabezpieczenia jest ochrona integralności i auten tycz­
ności danych wymienianych między kartami a urządzeniem rejes­
trującym, ochrona integralności i autentyczności danych pobiera ­
nych z kart, umożliwienie niektórych czynności zapisu na kartac h 
tylko urządzeniu rejestrującemu, odszyfrowywania niektórych 
danych, uniemożliwienie fałszowania danych przechowywanych na 
kartach, uniemożliwienie manipulacji i wykrycie wszelkich prób 
takiego działania.  
238) Aby możliwe było osiągnięcie bezpieczeństwa systemu, 
karty do tachografów muszą spełniać wymogi bezpieczeń­
stwa określone w dodatkach 10 i 11.  
239) Karty do tachografów muszą umożliwiać odczyt przy 
pomocy innych urządzeń, takich jak komputer osobisty.  
4.3 Normy  
240) Karty do tachografów muszą spełniać wymagania następu­
jących norm:  
— ISO/IEC 7810 Karty identyfikacyjne – Charakterystyki 
fizyczne,  
— ISO/IEC 7816 Karty identyfikacyjne – Karty stykowe:  
— Część 1: Charakterystyki fizyczne,  
— Część 2: Wymiary i rozmieszczenie styków 
(ISO/IEC 7816-2:2007),  
— Część 3: Interfejs elektryczny i protokoły transmisji 
(ISO/IEC 7816-3:2006),  
— Część 4: Organizacja, zabezpieczenia i polecenia 
wymiany (ISO/IEC 7816-4:2013 + Cor 1:2014),  
— Część 6: Elementy danych wymieniane z otocze­
niem, niezależne od dziedziny zastosowań (ISO/IEC 
7816-6:2004 + Cor 1:2006),  
— Część 8: Polecenia operacji zabezpieczających 
(ISO/IEC 7816-8:2004).  
— Karty do tachografów bada się zgodnie z normą 
SO/IEC 10373-3:2010 Karty identyfikacyjne – Metody 
badań – część 3: Elektroniczne karty stykowe i powią­
zane z nimi urządzenia interfejsowe.  
4.4 Wymagania środowiskowe i elektryczne  
241) Karty do tachografów muszą prawidłowo działać w warun­
kach klimatycznych normalnie występujących na terytorium 
Wspólnoty, przynajmniej w zakresie temperatur od – 25– 
+ 70 °C ze sporadycznymi temperaturami szczytowymi do 
+ 85 °C, przy czym „sporadyczny” oznacza nie dłużej niż 
4 godziny jednorazowo i nie więcej niż 100 razy w okresie 
eksploatacji karty.  
242) Karty do tachografów muszą działać prawidłowo w warun­
kach wilgotności 10 %–90 %.  
243) Karty do tachografów muszą prawidłowo działać przez 
okres pięciu lat, jeżeli są używane w zgodnie z warunkami 
środowiskowymi i elektrycznymi.  
244) W trakcie stosowania karty do tachografów muszą spełniać 
wymogi regulaminu EKG ONZ nr 10 w odniesieniu do 
kompatybilności elektromagnetycznej oraz muszą być chro­
nione przed wyładowaniami elektrostatycznymi.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 73  
4.5 Przechowywanie danych  
Do celów niniejszego pkt:  
— czas jest rejestrowany z dokładnością do jednej minuty, chyba  
że ustalono inaczej,  
— stany licznika kilometrów rejestruje się z dokładnością do 
jednego kilometra,  
— prędkości rejestruje się z dokładnością do 1 km/h,  
— pozycje (szerokość i długość ) rejestruje się w stopniach i m inu­
tach, z dokładnością do 1/10 minuty.  
Funkcje kart do tachografów, polecenia i struktury logiczne, sp eł­
niające wymagania dotyczące przechowywania danych wyszczegól­
niono w dodatku 2.  
O ile nie określono inaczej, przechowywanie danych na kartach d o 
tachografów odbywa się w taki sposób, że najstarsze dane są zas tę­
powane nowymi danymi, jeżeli wyczerpie się pamięć przewidziana 
na określone rekordy danych.  
245) W niniejszym punkcie określono minimalną pojemność 
przechowywania danych dla różnych zbiorów danych apli­
kacyjnych. Karty do tachografów przekazują do urządzenia 
rejestrującego bieżącą pojemność przechowywania danych 
dla tych zbiorów danych.  
▼M3 
246) Wszelkie dodatkowe dane mogą być przechowywane na 
kartach do tachografów, pod warunkiem że przechowy­
wanie tych danych jest zgodne z mającymi zastosowanie 
przepisami dotyczącymi ochrony danych.  
▼B 
247) Każdy plik główny (MF) na każdej karcie do tachografu 
zawiera maksymalnie pięć plików elementarnych (EF) do 
zarządzania kartą, identyfikacji aplikacji i mikroprocesora 
oraz dwa pliki dedykowane (DF):  
— DF Tachograph, który zawiera aplikację dostępną dla 
przyrządów rejestrujących pierwszej generacji, używaną 
również w kartach do tachografów pierwszej generacji,  
— DF Tachograph_G2, który zawiera aplikację dostępną 
tylko dla przyrządów rejestrujących drugiej generacji, 
używaną tylko w kartach do tachografów drugiej 
generacji,  
▼M3 
Uwaga: wersja 2 drugiej generacji kart zawiera dodatkowe 
pliki elementarne w DF Tachograph_G2.  
▼B 
Szczegółowe informacje o strukturze kart do tachografów 
określono w dodatku 2.  
4.5.1  Pliki elementarne do identyfikacji i zarz ądzania kart ą 
4.5.2  Identyfikacja kart mikroprocesorowych  
248) Karty do tachografów umożliwiają przechowywanie nastę­
pujących danych identyfikujących kartę elektroniczną:  
— zatrzymanie zegara,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 74  
— numer seryjny karty (łącznie z numerem producenta),  
— numer homologacji typu dla karty,  
— identyfikator jednostki personalizującej kartę,  
— identyfikator wbudowującego,  
— identyfikator układu scalonego.  
4.5.2.1 I d e n t y f i k a c j a m i k r o p r o c e s o r a  
249) Karty do tachografów umożliwiają przechowywanie nastę­
pujących danych identyfikujących układ scalony (IC):  
— numer seryjny układu scalonego,  
— oznaczenie fabryczne układu scalonego.  
4.5.2.2 D I R ( t y l k o w k a r t a c h d o t a c h o g r a f  ó w d r u g i e j 
g e n e r a c j i )  
250) Karty do tachografów umożliwiają przechowywanie 
obiektów danych identyfikujących aplikacje określonych 
w dodatku 2.  
4.5.2.3 I n f o r m a c j e A T R ( w a r u n k o w e , d o s t  ę p n e t y l k o 
w k a r t a c h d o t a c h o g r a f ó w d r u g i e j g e n e  r a c j i )  
251) Karty do tachografów umożliwiają przechowywanie nastę­
pujących obiektów danych informacji o rozszerzonej 
długości:  
— jeżeli karta do tachografów obsługuje pola o rozsze­
rzonej długości, obiekt danych informacji o rozszerzonej 
długości określony w dodatku 2.  
4.5.2.4 I n f o r m a c j e o r o z s z e r z o n e j d ł u g o  ś c i ( w a r u n ­
k o w e , d o s t ę p n e t y l k o w k a r t a c h d o t a c h  o g r a f ó w 
d r u g i e j g e n e r a c j i )  
252) Karty do tachografów umożliwiają przechowywanie nastę­
pujących obiektów danych informacji o rozszerzonej 
długości:  
— jeżeli karta do tachografów obsługuje pola o rozsze­
rzonej długości, obiekty danych informacji o rozsze­
rzonej długości określony w dodatku 2.  
4.5.3  Karta kierowcy  
4.5.3.1 A p l i k a c j a t a c h o g r a f i c z n a ( d o s t  ę p n a d l a p r z y ­
r z ą d ó w r e j e s t r u j ą c y c h p i e r w s z e j i d r  u g i e j g e n e ­
r a c j i )  
4.5.3.1.1 Identyfikacja aplikacji  
253) Karta kierowcy umożliwia przechowywanie następujących 
danych identyfikujących aplikację:  
— identyfikacja aplikacji tachograficznej,  
— identyfikacja typu karty do tachografów.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 75  
4.5.3.1.2 Klucz i certyfikaty  
254) Karta kierowcy umożliwia przechowywanie szeregu kluczy 
i certyfikatów kryptograficznych, jak określono w dodatku 
11 część A.  
4.5.3.1.3 Identyfikacja karty  
255) Karta kierowcy umożliwia przechowywanie następujących 
danych identyfikujących kartę:  
— numer karty,  
— państwo członkowskie wydające kartę, nazwa organu 
wydającego, data wydania,  
— data rozpoczęcia okresu ważności karty, termin 
ważności karty.  
4.5.3.1.4 Identyfikacja posiadacza karty  
256) Karta kierowcy umożliwia przechowywanie następujących 
danych identyfikujących posiadacza karty:  
— nazwisko posiadacza karty,  
— imię (imiona) posiadacza karty,  
— data urodzenia,  
— preferowany język.  
4.5.3.1.5 Pobieranie danych z karty  
257) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących pobierania danych:  
— data i godzina ostatniego pobrania danych z karty (do 
innych celów niż kontrola).  
258) Karta kierowcy umożliwia przechowywanie jednego 
takiego rekordu danych.  
4.5.3.1.6 Dane dotyczące prawa jazdy  
259) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących prawa jazdy:  
— państwo członkowskie wydające, nazwa organu wyda­
jącego,  
— numer prawa jazdy (w dniu wydania karty).  
4.5.3.1.7 Dane dotyczące zdarzeń  
Do celów niniejszego podpunktu czas zachowuje się z dokładności ą 
do 1 sekundy.  
260) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących zdarzeń wykrytych przez urządzenie 
rejestrujące przy włożonej karcie:  
— nakładające się czasy (w przypadku gdy dana karta jest 
przyczyną zdarzenia),  
— włożenie karty podczas jazdy (w przypadku gdy dana 
karta jest przedmiotem zdarzenia),  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 76  
— sesja ostatniej karty niezamknięta prawidłowo (w przy­
padku gdy dana karta jest przedmiotem zdarzenia),  
— przerwa w zasilaniu,  
— błąd danych dotyczących ruchu,  
— próby naruszenia zabezpieczenia.  
261) Karta kierowcy umożliwia przechowywanie następujących 
danych dla tych zdarzeń:  
— kod zdarzenia,  
— data i godzina rozpoczęcia zdarzenia (lub włożenia 
karty, jeżeli zdarzenie trwało w tym czasie),  
— data i godzina zakończenia zdarzenia (lub wyjęcia 
karty, jeżeli zdarzenie trwało w tym czasie),  
— numer VRN i państwo członkowskie rejestracji 
pojazdu, w którym wystąpiło zdarzenie.  
Uwaga:  dla zdarzenia „nakładające się czasy”:  
— data i godzina rozpoczęcia zdarzenia musi odpowiadać 
dacie i godzinie wyjęcia karty z poprzedniego pojazdu,  
— data i godzina zakończenia zdarzenia musi odpowiadać 
dacie i godzinie włożenia karty w bieżącym pojeździe,  
— dane pojazdu muszą odpowiadać bieżącemu pojazdowi 
powodującemu zdarzenie.  
Uwaga:  dla zdarzenia „sesja ostatniej karty niezamknięta 
prawidłowo”:  
— data i godzina rozpoczęcia zdarzenia musi odpowiadać 
dacie i godzinie włożenia karty dla sesji niezamkniętej 
prawidłowo,  
— data i godzina zakończenia zdarzenia musi odpowiadać 
dacie i godzinie włożenia karty dla sesji, w czasie której 
wykryto zdarzenie (bieżąca sesja),  
— dane pojazdu muszą odpowiadać pojazdowi, w którym 
sesja nie została zamknięta prawidłowo.  
262) Karta kierowcy umożliwia przechowywanie danych doty­
czących sześciu ostatnich zdarzeń każdego typu (łącznie 
36 zdarzeń).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 77  
4.5.3.1.8 Dane dotyczące usterek  
Do celów niniejszego podpunktu czas rejestruje się z dokładnośc ią 
do 1 sekundy.  
263) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących usterek wykrytych przez urządzenie 
rejestrujące przy włożonej karcie:  
▼M1 
— usterka karty (w przypadku gdy dana karta jest przed­
miotem usterki),  
▼B 
— usterka urządzenia rejestrującego.  
264) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących tych usterek:  
— kod usterki,  
— data i godzina rozpoczęcia usterki (lub włożenia karty, 
jeżeli usterka trwała w tym czasie),  
— data i godzina zakończenia usterki (lub wyjęcia karty, 
jeżeli usterka trwała w tym czasie),  
— numer VRN i państwo członkowskie rejestracji 
pojazdu, w którym wystąpiła usterka.  
265) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących dwunastu ostatnich usterek każdego 
rodzaju (łącznie 24 usterki).  
4.5.3.1.9 Dane dotyczące czynności kierowcy  
266) Karta kierowcy umożliwia przechowywanie, dla każdego 
dnia kalendarzowego, w którym karta jest użyta, lub dla 
każdego dnia, dla którego kierowca ręcznie wprowadza 
informacje dotyczące czynności, następujących danych:  
— data,  
— dzienny licznik obecności (zwiększony o jeden dla 
każdego z tych dni kalendarzowych),  
— całkowita droga przebyta przez kierowcę w ciągu tego 
dnia,  
— status kierowcy o godzinie 00:00,  
— za każdym razem, kiedy kierowca zmienia czynność lub 
stan prowadzenia pojazdu lub wkłada lub wyjmuje 
swoją kartę:  
— stan prowadzenia pojazdu (ZAŁOGA, JEDEN 
KIEROWCA),  
— szczelina czytnika (KIEROWCA, WSPÓŁKIE­
ROWCA),  
— status karty (WŁOŻONA, NIEWŁOŻONA),  
— czynność (PROWADZENIE, GOTOWOŚĆ, PRACA, 
PRZERWA/ODPOCZYNEK),  
— godzina zmiany.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 78  
267) Pamięć karty kierowcy wystarcza do przechowywania 
danych dotyczących czynności kierowcy przez co najmniej 
28 dni (przeciętną aktywność kierowcy definiuje się jako 
93 zmiany czynności dziennie).  
268) Dane wyszczególnione w wymaganiach 261, 264 i 266 
przechowuje się w sposób umożliwiający wyszukiwanie 
czynności w kolejności chronologicznej, nawet w przypadku 
nakładania się czasów.  
4.5.3.1.10 Dane dotyczące używanych pojazdów  
269) Karta kierowcy umożliwia przechowywanie, dla każdego 
dnia kalendarzowego, w którym karta jest użyta, i dla 
każdego okresu używania danego pojazdu w tym dniu 
(okres używania obejmuje wszystkie następujące po sobie 
cykle włożenia i wyjęcia karty w danym pojeździe, 
z perspektywy danych zapisanych na karcie), następujących 
danych:  
— data i godzina pierwszego użycia pojazdu (tj. pierwsze 
włożenie karty w tym okresie używania pojazdu lub 
00:00, jeżeli okres używania trwał w tym czasie),  
— stan licznika kilometrów o tej godzinie,  
— data i godzina ostatniego użycia pojazdu, (tj. ostatnie 
wyjęcie karty w tym okresie używania pojazdu lub 
23:59, jeżeli okres używania trwał w tym czasie),  
— stan licznika kilometrów o tej godzinie,  
— numer VRN i państwo członkowskie rejestracji 
pojazdu.  
270) Karta kierowcy umożliwia przechowywanie co najmniej 84 
takich rekordów danych.  
4.5.3.1.11 Miejsca rozpoczęcia lub zakończenia dziennych okresó w pracy  
271) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących miejsc rozpoczęcia lub zakończenia 
dziennych okresów pracy, wprowadzanych przez kierowcę:  
— data i godzina wprowadzenia danych (lub data/godzina 
odnosząca się do wpisu, jeżeli wpis wprowadza się 
w procedurze ręcznego wprowadzania danych),  
— rodzaj wpisu (rozpoczęcie lub zakończenie, status 
wpisu),  
— kraj i region,  
— stan licznika kilometrów.  
272) Pamięć karty kierowcy umożliwia przechowywanie co 
najmniej 42 par takich rekordów danych.  
4.5.3.1.12 Dane sesji karty  
273) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących pojazdu, dla którego otwarto bieżącą 
sesję:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 79  
— data i godzina otwarcia sesji (tj. włożenia karty) 
z dokładnością do jednej sekundy,  
— numer VRN i państwo członkowskie rejestracji.  
4.5.3.1.13 Dane dotyczące czynności kontrolnych  
274) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących czynności kontrolnych:  
— data i godzina kontroli,  
— numer karty kontrolnej i państwo członkowskie wyda­
jące kartę,  
— rodzaj kontroli (wyświetlanie lub drukowanie lub pobie­
ranie danych z przyrządu rejestrującego lub pobieranie 
danych z karty – patrz uwaga),  
— okres, dla którego pobrano dane, w przypadku pobie­
rania danych,  
— numer VRN i państwo członkowskie rejestracji 
pojazdu, w którym miała miejsce kontrola.  
Uwaga:  pobieranie danych z karty jest rejestrowane 
wyłącznie wtedy, gdy jest wykonywane przez urządzenie 
rejestrujące.  
275) Karta kierowcy umożliwia przechowywanie jednego 
takiego rekordu danych.  
4.5.3.1.14 Dane dotyczące warunków szczególnych  
276) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących warunków szczególnych wprowadzo­
nych przy włożonej karcie (niezależnie od tego, do której 
szczeliny czytnika):  
— data i godzina wprowadzenia danych,  
— rodzaj warunku szczególnego.  
277) Karta kierowcy umożliwia przechowywanie co najmniej 56 
takich rekordów danych.  
▼M3 
4.5.3.2 A p l i k a c j a t a c h o g r a f i c z n a g e n e r  a c j i 2 ( n i e d o ­
s t ę p n a d l a p i e r w s z e j g e n e r a c j i p r z y r  z ą d ó w 
r e j e s t r u j ą c y c h , d o s t ę p n a d l a w e r s j i  1  i  w  e  r  s  j  i  2  
d r u g i e j g e n e r a c j i p r z y r z ą d ó w r e j e s t  r u j ą c y c h )  
▼B 
4.5.3.2.1 Identyfikacja aplikacji  
278) Karta kierowcy umożliwia przechowywanie następujących 
danych identyfikujących aplikację:  
— identyfikacja aplikacji tachograficznej,  
— identyfikacja typu karty do tachografów.  
▼M3 
4.5.3.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w p rzypadku wersji 
1 drugiej generacji przyrządów rejestrujących)  
278a) Karta kierowcy umożliwia przechowywanie dodatkowych 
danych identyfikujących aplikacje mających zastosowanie 
wyłącznie do wersji 2.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 80  
4.5.3.2.2 Klucze i certyfikaty  
279) Karta kierowcy umożliwia przechowywanie szeregu kluczy 
i certyfikatów kryptograficznych, jak określono w dodatku 
11 część B.  
4.5.3.2.3 Identyfikacja karty  
280) Karta kierowcy umożliwia przechowywanie następujących 
danych identyfikujących kartę:  
— numer karty,  
— państwo członkowskie wydające kartę, nazwa organu 
wydającego, data wydania,  
— data rozpoczęcia okresu ważności karty, termin ważności 
karty.  
4.5.3.2.4 Identyfikacja posiadacza karty  
281) Karta kierowcy umożliwia przechowywanie następujących 
danych identyfikujących posiadacza karty:  
— nazwisko posiadacza karty,  
— imię (imiona) posiadacza karty,  
— data urodzenia,  
— preferowany język.  
4.5.3.2.5 Pobieranie danych z karty  
282) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących pobierania danych:  
— data i godzina ostatniego pobrania danych z karty (do 
innych celów niż kontrola).  
283) Karta kierowcy umożliwia przechowywanie jednego 
takiego rekordu danych.  
4.5.3.2.6 Dane dotyczące prawa jazdy  
284) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących prawa jazdy:  
— państwo członkowskie wydające, nazwa organu wyda­
jącego,  
— numer prawa jazdy (w dniu wydania karty).  
4.5.3.2.7 Dane dotyczące zdarzeń  
Do celów niniejszego podpunktu czas zachowuje się z dokładności ą 
do 1 sekundy.  
285) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących zdarzeń wykrytych przez urządzenie 
rejestrujące przy włożonej karcie:  
— nakładające się czasy (w przypadku gdy dana karta jest 
przyczyną zdarzenia),  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 81  
— włożenie karty podczas jazdy (w przypadku gdy dana 
karta jest przedmiotem zdarzenia),  
— sesja ostatniej karty niezamknięta prawidłowo (w przy­
padku gdy dana karta jest przedmiotem zdarzenia),  
— przerwa w zasilaniu,  
— błąd połączenia z urządzeniem do łączności na odle­
głość,  
— brak informacji o pozycji z odbiornika GNSS,  
— błąd połączenia z urządzeniem zewnętrznym GNSS,  
— błąd danych dotyczących ruchu,  
— konflikt ruchu pojazdu,  
— próba naruszenia zabezpieczenia,  
— konflikt czasu.  
286) Karta kierowcy umożliwia przechowywanie następujących 
danych dla tych zdarzeń:  
— kod zdarzenia,  
— data i godzina rozpoczęcia zdarzenia (lub włożenia 
karty, jeżeli zdarzenie trwało w tym czasie),  
— data i godzina zakończenia zdarzenia (lub wyjęcia 
karty, jeżeli zdarzenie trwało w tym czasie),  
— numer VRN i państwo członkowskie rejestracji 
pojazdu, w którym wystąpiło zdarzenie.  
Uwaga:  dla zdarzenia „nakładające się czasy”:  
— data i godzina rozpoczęcia zdarzenia musi odpowiadać 
dacie i godzinie wyjęcia karty z poprzedniego pojazdu,  
— data i godzina zakończenia zdarzenia musi odpowiadać 
dacie i godzinie włożenia karty w bieżącym pojeździe,  
— dane pojazdu muszą odpowiadać bieżącemu pojazdowi 
powodującemu zdarzenie.  
Uwaga:  dla zdarzenia „sesja ostatniej karty niezamknięta 
prawidłowo”:  
— data i godzina rozpoczęcia zdarzenia musi odpowiadać 
dacie i godzinie włożenia karty dla sesji niezamkniętej 
prawidłowo,  
— data i godzina zakończenia zdarzenia musi odpowiadać 
dacie i godzinie włożenia karty dla sesji, w czasie której 
wykryto zdarzenie (bieżąca sesja),  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 82  
— dane pojazdu muszą odpowiadać pojazdowi, w którym 
sesja nie została zamknięta prawidłowo.  
▼M3 
287) Karta kierowcy umożliwia przechowywanie danych dotyczą­
cych 12 ostatnich zdarzeń każdego typu (tj. 132 zdarzeń).  
▼B 
4.5.3.2.8 Dane dotyczące usterek  
Do celów niniejszego podpunktu czas rejestruje się z dokładnośc ią 
do 1 sekundy.  
288) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących usterek wykrytych przez urządzenie 
rejestrujące przy włożonej karcie:  
▼M1 
— usterka karty (w przypadku gdy dana karta jest przed­
miotem usterki),  
▼B 
— usterka urządzenia rejestrującego.  
289) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących tych usterek:  
— kod usterki,  
— data i godzina rozpoczęcia usterki (lub włożenia karty, 
jeżeli usterka trwała w tym czasie),  
— data i godzina zakończenia usterki (lub wyjęcia karty, 
jeżeli usterka trwała w tym czasie),  
— numer VRN i państwo członkowskie rejestracji pojazdu, 
w którym wystąpiła usterka.  
▼M3 
290) Karta kierowcy umożliwia przechowywanie danych doty­
czących 24 ostatnich usterek każdego rodzaju (tj. 48 
usterek).  
▼B 
4.5.3.2.9 Dane dotyczące czynności kierowcy  
291) Karta kierowcy umożliwia przechowywanie, dla każdego 
dnia kalendarzowego, w którym karta jest użyta, lub dla 
każdego dnia, dla którego kierowca ręcznie wprowadza 
informacje dotyczące czynności, następujących danych:  
— data,  
— dzienny licznik obecności (zwiększony o jeden dla 
każdego z tych dni kalendarzowych),  
— całkowita droga przebyta przez kierowcę w ciągu tego 
dnia,  
— status kierowcy o godzinie 00:00,  
— za każdym razem, kiedy kierowca zmienia czynność lub 
stan prowadzenia pojazdu lub wkłada lub wyjmuje 
swoją kartę:  
— stan prowadzenia pojazdu (ZAŁOGA, JEDEN 
KIEROWCA),  
— szczelina czytnika (KIEROWCA, WSPÓŁKIE­
ROWCA),  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 83  
— status karty (WŁOŻONA, NIEWŁOŻONA),  
— czynność (PROWADZENIE, GOTOWOŚĆ, 
PRACA, PRZERWA/ODPOCZYNEK),  
— godzina zmiany.  
▼M3 
292) Pamięć karty kierowcy wystarcza do przechowywania 
danych dotyczących czynności kierowcy przez przynaj­
mniej 56 dni (przeciętną aktywność kierowcy definiuje się 
na potrzeby tego wymogu jako 117 zmian czynności 
dziennie).  
▼B 
293) Dane wyszczególnione w wymaganiach 286, 289 i 291 
przechowuje się w sposób umożliwiający wyszukiwanie 
czynności w kolejności chronologicznej, nawet w przypadku 
nakładania się czasów.  
4.5.3.2.10 Dane dotyczące używanych pojazdów  
294) Karta kierowcy umożliwia przechowywanie, dla każdego 
dnia kalendarzowego, w którym karta jest użyta, i dla 
każdego okresu używania danego pojazdu w tym dniu 
(okres używania obejmuje wszystkie następujące po sobie 
cykle włożenia i wyjęcia karty w danym pojeździe, 
z perspektywy danych zapisanych na karcie), następujących 
danych:  
— data i godzina pierwszego użycia pojazdu (tj. pierwsze 
włożenie karty w tym okresie używania pojazdu lub 
00:00, jeżeli okres używania trwał w tym czasie),  
— stan licznika kilometrów w chwili pierwszego użycia,  
— data i godzina ostatniego użycia pojazdu, (tj. ostatnie 
wyjęcie karty w tym okresie używania pojazdu lub 
23:59, jeżeli okres używania trwał w tym czasie),  
— stan licznika kilometrów w chwili ostatniego użycia,  
— numer VRN i państwo członkowskie rejestracji 
pojazdu,  
— numer VIN pojazdu.  
▼M3 
295) Karta kierowcy umożliwia przechowywanie 200 takich 
rekordów danych.  
▼B 
4.5.3.2.11 Miejsca i pozycje rozpoczęcia lub zakończenia dzienn ych okresów 
pracy  
296) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących miejsc rozpoczęcia lub zakończenia 
dziennych okresów pracy, wprowadzanych przez kierowcę:  
— data i godzina wprowadzenia danych (lub data/godzina 
odnosząca się do wpisu, jeżeli wpis wprowadza się 
w procedurze ręcznego wprowadzania danych),  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 84  
— rodzaj wpisu (rozpoczęcie lub zakończenie, status 
wpisu),  
— kraj i region,  
— stan licznika kilometrów,  
— pozycja pojazdu,  
— dokładność GNSS, data i godzina określenia pozycji.  
▼M3 
297) Pamięć karty kierowcy umożliwia przechowywanie 112 
takich rekordów danych.  
▼B 
4.5.3.2.12 Dane sesji karty  
298) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących pojazdu, dla którego otwarto bieżącą 
sesję:  
— data i godzina otwarcia sesji (tj. włożenia karty) 
z dokładnością do jednej sekundy,  
— numer VRN i państwo członkowskie rejestracji.  
4.5.3.2.13 Dane dotyczące czynności kontrolnych  
299) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących czynności kontrolnych:  
— data i godzina kontroli,  
— numer karty kontrolnej i państwo członkowskie wyda­
jące kartę,  
— rodzaj kontroli (wyświetlanie lub drukowanie lub pobie­
ranie danych z przyrządu rejestrującego lub pobieranie 
danych z karty – patrz uwaga),  
— okres, dla którego pobrano dane, w przypadku pobie­
rania danych,  
— numer VRN i państwo członkowskie rejestracji 
pojazdu, w którym miała miejsce kontrola.  
Uwaga:  zgodnie z wymogami bezpieczeństwa pobieranie 
danych z karty jest rejestrowane wyłącznie wtedy, gdy 
jest wykonywane przez urządzenie rejestrujące.  
300) Karta kierowcy umożliwia przechowywanie jednego 
takiego rekordu danych.  
4.5.3.2.14 Dane dotyczące warunków szczególnych  
301) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących warunków szczególnych wprowadzo­
nych przy włożonej karcie (niezależnie od tego, do której 
szczeliny czytnika):  
— data i godzina wprowadzenia danych,  
— rodzaj warunku szczególnego.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 85  
302) Karta kierowcy umożliwia przechowywanie 112 takich 
rekordów danych.  
▼B 
4.5.3.2.15 Dane dotyczące używanych przyrządów rejestrujących  
303) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących różnych przyrządów rejestrujących, 
w których dana karta była używana:  
— data i godzina rozpoczęcia okresu używania przyrządu 
rejestrującego (tj. pierwsze włożenie karty do przyrządu 
rejestrującego dla danego okresu),  
— producent przyrządu rejestrującego,  
— rodzaj przyrządu rejestrującego,  
— numer wersji oprogramowania przyrządu rejestrującego.  
▼M3 
304) Karta kierowcy umożliwia przechowywanie 200 takich 
rekordów danych.  
▼M1 
4.5.3.2.16 Dane miejsc, w których minęły trzy godziny skumulowa nego czasu 
prowadzenia pojazdu  
305) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących pozycji pojazdu, w których skumulo­
wany czas prowadzenia pojazdu osiąga wielokrotność 
trzech godzin:  
— data i godzina, o której skumulowany czas prowadzenia 
pojazdu osiąga wielokrotność trzech godzin,  
— pozycja pojazdu,  
— dokładność GNSS, data i godzina określenia pozycji,  
— stan licznika kilometrów.  
▼M3 
306) Karta kierowcy umożliwia przechowywanie 336 takich 
rekordów danych.  
4.5.3.2.17 Status uwierzytelniania dla pozycji związanych z mie jscami rozpo­
częcia lub zakończenia dziennych okresów pracy (brak dostępu 
w przypadku wersji 1 drugiej generacji przyrządów rejestrującyc h) 
306a) Karta kierowcy umożliwia przechowywanie dodatkowych 
danych dotyczących miejsc rozpoczęcia lub zakończenia 
dziennych okresów pracy, wprowadzanych przez kierowcę 
zgodnie z pkt 4.5.3.2.11:  
— data i godzina wpisu, która musi być dokładnie taka 
sama, jak data i godzina zapisana w EF Places w DF 
Tachograph_G2,  
— flagę wskazującą, czy pozycja została uwierzytelniona.  
306b) Pamięć karty kierowcy umożliwia przechowywanie 112 
takich rekordów danych.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 86  
4.5.3.2.18 Status uwierzytelniania dla pozycji, w których osiąg nięto trzy 
godziny skumulowanego czasu prowadzenia pojazdu (brak dostępu 
w przypadku wersji 1 drugiej generacji przyrządów rejestrującyc h) 
306c) Karta kierowcy umożliwia przechowywanie dodatkowych 
danych dotyczących pozycji pojazdu, w których skumulo­
wany czas prowadzenia pojazdu osiąga wielokrotność 
trzech godzin zgodnie z pkt 4.5.3.2.16:  
— data i godzina, gdy skumulowany czas prowadzenia 
pojazdu osiąga wielokrotność trzech godzin, która 
musi być dokładnie taka sama, jak data i godzina zapi­
sana w EF GNSS_Places w DF Tachograph_G2,  
— flagę wskazującą, czy pozycja została uwierzytelniona.  
306d) Karta kierowcy umożliwia przechowywanie 336 takich 
rekordów danych.  
4.5.3.2.19 Przekroczenia granicy (brak dostępu w przypadku wers ji 1 drugiej 
generacji przyrządów rejestrujących)  
306e) Karta kierowcy umożliwia zapisanie następujących danych 
dotyczących przekroczeń granicy przy wkładaniu karty 
zgodnie z wymogiem 147b albo przy już włożonej karcie:  
— kraj, który pojazd opuszcza,  
— kraj, do którego pojazd wjeżdża,  
— data i godzina przekroczenia granicy przez pojazd,  
— pozycja pojazdu po przekroczeniu granicy,  
— dokładność GNSS,  
— flagę wskazującą, czy pozycja została uwierzytelniona,  
— stan licznika kilometrów.  
306f) Pamięć karty kierowcy umożliwia przechowywanie 1120 
takich rekordów danych.  
4.5.3.2.20 Operacje załadunku/rozładunku (brak dostępu w przypa dku wersji 1 
drugiej generacji przyrządów rejestrujących)  
306g) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących operacji załadunku/rozładunku:  
— typ operacji (załadunek, rozładunek lub równoczesny 
załadunek/rozładunek),  
— data i godzina operacji załadunku/rozładunku,  
— pozycja pojazdu,  
— dokładność GNSS, data i godzina określenia pozycji,  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 87  
— flagę wskazującą, czy pozycja została uwierzytelniona,  
— stan licznika kilometrów.  
306h) Karta kierowcy umożliwia przechowywanie 1624 operacji 
załadunku/rozładunku.  
4.5.3.2.21 Wprowadzanie typu załadunku (brak dostępu w przypadk u wersji 1 
drugiej generacji przyrządów rejestrujących)  
306i) Karta kierowcy umożliwia przechowywanie następujących 
danych dotyczących typu załadunku wprowadzanych auto­
matycznie przez VU przy każdym włożeniu karty:  
— wpisany typ załadunku (towary lub pasażerowie),  
— data i godzina wpisu.  
306j) Karta kierowcy umożliwia przechowywanie 336 takich 
rekordów danych.  
4.5.3.2.22 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
306k) Karta kierowcy umożliwia przechowywanie szczegółowych 
ustawień tachografu posiadacza karty.  
306l) Pojemność karty kierowcy na potrzeby przechowywania 
szczegółowych ustawień tachografu posiadacza karty 
wynosi 3072 bajty.  
▼B 
4.5.4  Karta warsztatowa  
4.5.4.1 A p l i k a c j a t a c h o g r a f i c z n a ( d o s t  ę p n a d l a p r z y ­
r z ą d ó w r e j e s t r u j ą c y c h p i e r w s z e j i d r  u g i e j g e n e ­
r a c j i )  
4.5.4.1.1 Identyfikacja aplikacji  
307) Karta warsztatowa umożliwia przechowywanie następują­
cych danych identyfikujących aplikację:  
— identyfikacja aplikacji tachograficznej,  
— identyfikacja typu karty do tachografów.  
4.5.4.1.2 Klucze i certyfikaty  
308) Karta warsztatowa umożliwia przechowywanie szeregu 
kluczy i certyfikatów kryptograficznych, jak określono 
w dodatku 11 część A.  
309) Karta warsztatowa umożliwia przechowywanie osobistego 
numeru identyfikacyjnego (kodu PIN).  
4.5.4.1.3 Identyfikacja karty  
310) Karta warsztatowa umożliwia przechowywanie następują­
cych danych identyfikujących kartę:  
— numer karty,  
— państwo członkowskie wydające kartę, nazwa organu 
wydającego, data wydania,  
— data rozpoczęcia okresu ważności karty, termin 
ważności karty.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 88  
4.5.4.1.4 Identyfikacja posiadacza karty  
311) Karta warsztatowa umożliwia przechowywanie następują­
cych danych identyfikujących posiadacza karty:  
— nazwa warsztatu,  
— adres warsztatu,  
— nazwisko posiadacza karty,  
— imię (imiona) posiadacza karty,  
— preferowany język.  
4.5.4.1.5 Pobieranie danych z karty  
312) Karta warsztatowa umożliwia przechowywanie rekordu 
danych pobranych z karty, w taki sam sposób jak karta 
kierowcy.  
4.5.4.1.6 Dane dotyczące kalibracji i korekty czasu  
313) Karta warsztatowa umożliwia przechowywanie zapisów 
dotyczących kalibracji lub korekty czasu wykonanych 
przy karcie włożonej do urządzenia rejestrującego.  
314) Każdy rekord danych kalibracji może zawierać następujące 
dane:  
— cel kalibracji (aktywacja, pierwsza instalacja, instalacja, 
przegląd okresowy),  
— identyfikacja pojazdu,  
— parametry uaktualnione lub potwierdzone (w, k, l, 
rozmiar opon, ustawienie urządzenia ograniczenia pręd­
kości, licznik kilometrów (nowe i stare wartości), data 
i godzina (nowe i stare wartości)),  
— identyfikacja urządzenia rejestrującego (numer części 
VU, numer seryjny VU, numer seryjny czujnika ruchu).  
315) Karta warsztatowa umożliwia przechowywanie co najmniej 
88 takich rekordów danych.  
316) Karta warsztatowa jest wyposażona w licznik pokazujący 
łączną liczbę kalibracji wykonanych przy użyciu tej karty.  
317) Karta warsztatowa jest wyposażona w licznik pokazujący 
liczbę kalibracji wykonanych od ostatniego pobrania 
danych.  
4.5.4.1.7 Dane dotyczące zdarzeń i usterek  
318) Karta warsztatowa umożliwia przechowywanie rekordów 
danych zdarzeń i usterek, w taki sam sposób jak karta 
kierowcy.  
319) Karta warsztatowa umożliwia przechowywanie danych 
dotyczących trzech ostatnich zdarzeń każdego rodzaju 
(łącznie 18 zdarzeń) i sześciu ostatnich usterek każdego 
rodzaju (łącznie 12 usterek).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 89  
4.5.4.1.8 Dane dotyczące czynności kierowcy  
320) Karta warsztatowa umożliwia przechowywanie danych 
dotyczących czynności kierowcy, w taki sam sposób jak 
karta kierowcy.  
321) Karta warsztatowa umożliwia przechowywanie danych 
dotyczących czynności kierowcy za co najmniej 1 dzień 
przeciętnej aktywności kierowcy.  
4.5.4.1.9 Dane dotyczące używanych pojazdów  
322) Karta warsztatowa umożliwia przechowywanie rekordów 
danych dotyczących używanego pojazdu, w taki sam 
sposób jak karta kierowcy.  
323) Karta warsztatowa umożliwia przechowywanie co najmniej 
4 takich rekordów.  
4.5.4.1.10 Dane dotyczące rozpoczęcia lub zakończenia dziennych  okresów 
pracy  
324) Karta warsztatowa umożliwia przechowywanie rekordów 
danych dotyczących rozpoczęcia lub zakończenia dzien­
nych okresów pracy, w taki sam sposób jak karta kierowcy.  
325) Karta warsztatowa umożliwia przechowywanie co najmniej 
3 par takich rekordów danych.  
4.5.4.1.11 Dane sesji karty  
326) Karta warsztatowa umożliwia przechowywanie rekordu 
danych sesji karty, w taki sam sposób jak karta kierowcy.  
4.5.4.1.12 Dane dotyczące czynności kontrolnych  
327) Karta warsztatowa umożliwia przechowywanie rekordu 
danych czynności kontrolnych, w taki sam sposób jak 
karta kierowcy.  
4.5.4.1.13 Dane dotyczące warunków szczególnych  
328) Karta warsztatowa umożliwia przechowywanie danych 
dotyczących warunków szczególnych, w taki sam sposób 
jak karta kierowcy.  
329) Karta warsztatowa umożliwia przechowywanie co najmniej 
2 takich rekordów.  
▼M3 
4.5.4.2 A p l i k a c j a t a c h o g r a f i c z n a g e n e r  a c j i 2 ( n i e d o ­
s t ę p n a d l a p i e r w s z e j g e n e r a c j i p r z y r  z ą d ó w 
r e j e s t r u j ą c y c h , d o s t ę p n a d l a w e r s j i  1  i  w  e  r  s  j  i  2  
d r u g i e j g e n e r a c j i p r z y r z ą d ó w r e j e s t  r u j ą c y c h )  
▼B 
4.5.4.2.1 Identyfikacja aplikacji  
330) Karta warsztatowa umożliwia przechowywanie następują­
cych danych identyfikujących aplikację:  
— identyfikacja aplikacji tachograficznej,  
— identyfikacja typu karty do tachografów.  
▼M3 
4.5.4.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w p rzypadku wersji 
1 drugiej generacji przyrządów rejestrujących)  
330a) Karta warsztatowa umożliwia przechowywanie dodatko­
wych danych identyfikujących aplikacje mających zastoso­
wanie wyłącznie do wersji 2.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 90  
4.5.4.2.2 Klucze i certyfikaty  
331) Karta warsztatowa umożliwia przechowywanie szeregu 
kluczy i certyfikatów kryptograficznych, jak określono 
w dodatku 11 część B.  
332) Karta warsztatowa umożliwia przechowywanie osobistego 
numeru identyfikacyjnego (kodu PIN).  
4.5.4.2.3 Identyfikacja karty  
333) Karta warsztatowa umożliwia przechowywanie następują­
cych danych identyfikujących kartę:  
— numer karty,  
— państwo członkowskie wydające kartę, nazwa organu 
wydającego, data wydania,  
— data rozpoczęcia okresu ważności karty, termin 
ważności karty.  
4.5.4.2.4 Identyfikacja posiadacza karty  
334) Karta warsztatowa umożliwia przechowywanie następują­
cych danych identyfikujących posiadacza karty:  
— nazwa warsztatu,  
— adres warsztatu,  
— nazwisko posiadacza karty,  
— imię (imiona) posiadacza karty,  
— preferowany język.  
4.5.4.2.5 Pobieranie danych z karty  
335) Karta warsztatowa umożliwia przechowywanie rekordu 
danych pobranych z karty, w taki sam sposób jak karta 
kierowcy.  
4.5.4.2.6 Dane dotyczące kalibracji i korekty czasu  
336) Karta warsztatowa umożliwia przechowywanie zapisów 
dotyczących kalibracji lub korekty czasu wykonanych 
przy karcie włożonej do urządzenia rejestrującego.  
337) Każdy rekord danych kalibracji może zawierać następujące 
dane:  
— cel kalibracji (aktywacja, pierwsza instalacja, instalacja, 
przegląd okresowy),  
— identyfikacja pojazdu,  
— parametry uaktualnione lub potwierdzone (w, k, l, 
rozmiar opon, ustawienie urządzenia ograniczenia pręd­
kości, licznik kilometrów (nowe i stare wartości), data 
i godzina (nowe i stare wartości)),  
— identyfikacja urządzenia rejestrującego (numer części VU, 
numer seryjny VU, numer seryjny czujnika ruchu, numer 
seryjny urządzenia do łączności na odległość, numer 
seryjny urządzenia zewnętrznego GNSS, w stosownych 
przypadkach),  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 91  
— rodzaje i identyfikatory wszystkich założonych plomb,  
— możliwość korzystania przez przyrząd rejestrujący 
z kart do tachografów pierwszej generacji (włączona 
lub nie).  
▼M3 
338) Karta warsztatowa umożliwia przechowywanie 255 takich 
rekordów danych.  
▼B 
339) Karta warsztatowa jest wyposażona w licznik pokazujący 
łączną liczbę kalibracji wykonanych przy użyciu tej karty.  
340) Karta warsztatowa jest wyposażona w licznik pokazujący 
liczbę kalibracji wykonanych od ostatniego pobrania 
danych.  
4.5.4.2.7 Dane dotyczące zdarzeń i usterek  
341) Karta warsztatowa umożliwia przechowywanie rekordów 
danych zdarzeń i usterek, w taki sam sposób jak karta 
kierowcy.  
342) Karta warsztatowa umożliwia przechowywanie danych 
dotyczących trzech ostatnich zdarzeń każdego rodzaju 
(łącznie 33 zdarzenia) i sześciu ostatnich usterek każdego 
rodzaju (łącznie 12 usterek).  
4.5.4.2.8 Dane dotyczące czynności kierowcy  
343) Karta warsztatowa umożliwia przechowywanie danych 
dotyczących czynności kierowcy, w taki sam sposób jak 
karta kierowcy.  
▼M3 
344) Karta warsztatowa umożliwia przechowywanie danych 
dotyczących czynności kierowcy przez 1 dzień obejmujący 
240 zmian czynności.  
▼B 
4.5.4.2.9 Dane dotyczące używanych pojazdów  
345) Karta warsztatowa umożliwia przechowywanie rekordów 
danych dotyczących używanego pojazdu, w taki sam 
sposób jak karta kierowcy.  
▼M3 
346) Karta warsztatowa umożliwia przechowywanie 8 takich 
rekordów danych.  
4.5.4.2.10 Dane dotyczące miejsc i pozycji rozpoczęcia lub zako ńczenia dzien­
nych okresów pracy  
347) Karta warsztatowa umożliwia przechowywanie rekordów 
danych dotyczących miejsc i pozycji rozpoczęcia lub 
zakończenia dziennych okresów pracy, w taki sam sposób 
jak karta kierowcy.  
348) Karta warsztatowa umożliwia przechowywanie 4 par takich 
rekordów danych.  
▼B 
4.5.4.2.11 Dane sesji karty  
349) Karta warsztatowa umożliwia przechowywanie rekordu 
danych sesji karty, w taki sam sposób jak karta kierowcy.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 92  
4.5.4.2.12 Dane dotyczące czynności kontrolnych  
350) Karta warsztatowa umożliwia przechowywanie rekordu 
danych czynności kontrolnych, w taki sam sposób jak 
karta kierowcy.  
4.5.4.2.13 Dane dotyczące używanych przyrządów rejestrujących  
351) Karta warsztatowa umożliwia przechowywanie następują­
cych danych dotyczących różnych przyrządów rejestrują­
cych, w których dana karta była używana:  
— data i godzina rozpoczęcia okresu używania przyrządu 
rejestrującego (tj. pierwsze włożenie karty do przyrządu 
rejestrującego dla danego okresu),  
— producent przyrządu rejestrującego,  
— rodzaj przyrządu rejestrującego,  
— numer wersji oprogramowania przyrządu rejestrującego.  
▼M3 
352) Karta warsztatowa umożliwia przechowywanie 8 takich 
rekordów danych.  
▼M1 
4.5.4.2.14 Dane miejsc, w których minęły trzy godziny skumulowa nego czasu 
prowadzenia pojazdu  
353) Karta warsztatowa umożliwia przechowywanie następują­
cych danych dotyczących pozycji pojazdu, w których 
skumulowany czas prowadzenia pojazdu osiąga wielokrot­
ność trzech godzin:  
— data i godzina, o której skumulowany czas prowadzenia 
pojazdu osiąga wielokrotność trzech godzin,  
— pozycja pojazdu,  
— dokładność GNSS, data i godzina określenia pozycji,  
— stan licznika kilometrów.  
▼M3 
354) Karta warsztatowa umożliwia przechowywanie 24 takich 
rekordów danych.  
▼B 
4.5.4.2.15 Dane dotyczące warunków szczególnych  
355) Karta warsztatowa umożliwia przechowywanie danych 
dotyczących warunków szczególnych, w taki sam sposób 
jak karta kierowcy.  
▼M3 
356) Karta warsztatowa umożliwia przechowywanie 4 takich 
rekordów danych.  
4.5.4.2.16 Status uwierzytelniania dla pozycji związanych z mie jscami rozpo­
częcia lub zakończenia dziennych okresów pracy (brak dostępu 
w przypadku wersji 1 drugiej generacji przyrządów rejestrującyc h) 
356a) Karta warsztatowa umożliwia przechowywanie dodatko­
wych danych dotyczących miejsc rozpoczęcia lub zakoń­
czenia dziennych okresów pracy, w taki sam sposób jak 
karta kierowcy.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 93  
356b) Pamięć karty warsztatowej umożliwia przechowywanie 4 
par takich rekordów danych.  
4.5.4.2.17 Status uwierzytelniania dla pozycji, w których osiąg nięto trzy 
godziny skumulowanego prowadzenia pojazdu (brak dostępu w przy­
padku wersji 1 drugiej generacji przyrządów rejestrujących)  
356c) Karta warsztatowa umożliwia przechowywanie dodatko­
wych danych dotyczących pozycji pojazdu, w których 
skumulowany czas prowadzenia pojazdu osiąga wielokrot­
ność trzech godzin w taki sam sposób jak karta kierowcy.  
356d) Karta warsztatowa umożliwia przechowywanie 24 takich 
rekordów danych.  
4.5.4.2.18 Przekroczenia granicy (brak dostępu w przypadku wers ji 1 drugiej 
generacji przyrządów rejestrujących)  
356e) Karta warsztatowa umożliwia przechowywanie przekroczeń 
granicy, w taki sam sposób jak karta kierowcy.  
356f) Pamięć karty warsztatowej umożliwia przechowywanie 4 
takich rekordów danych.  
4.5.4.2.19 Operacje załadunku/rozładunku (brak dostępu w przypa dku wersji 1 
drugiej generacji przyrządów rejestrujących)  
356g) Karta warsztatowa umożliwia przechowywanie operacji 
załadunku/rozładunku, w taki sam sposób jak karta 
kierowcy.  
356h) Karta warsztatowa umożliwia przechowywanie 8 operacji 
załadunku, rozładunku lub równoczesnego załadunku/rozła­
dunku.  
4.5.4.2.20 Wprowadzanie typu załadunku (brak dostępu w przypadk u wersji 1 
drugiej generacji przyrządów rejestrujących)  
356i) Karta warsztatowa umożliwia przechowywanie wpisów 
typu załadunku, w taki sam sposób jak karta kierowcy.  
356j) Karta warsztatowa umożliwia przechowywanie 4 takich 
rekordów danych.  
4.5.4.2.21 Dodatkowe dane dotyczące kalibracji (brak dostępu w przypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
356k) Karta warsztatowa umożliwia przechowywanie dodatko­
wych danych identyfikujących aplikacje mających zastoso­
wanie wyłącznie do wersji 2:  
— stara wartość daty i godziny oraz numer identyfikacyjny 
pojazdu, które muszą być dokładnie takie same, jak 
wartości zapisane w EF Calibration w DF Tacho­
graph_G2,  
— domyślny typ załadunku wpisany podczas tej kalibracji,  
— kraj, w którym wykonano kalibrację, oraz data i godzina 
dostarczenia przez odbiornik GNSS pozycji wykorzys­
tanej do określenia tego kraju.  
356l) Karta warsztatowa umożliwia przechowywanie 255 takich 
rekordów danych.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 94  
4.5.4.2.22 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
356m) Karta warsztatowa umożliwia przechowywanie szczegóło­
wych ustawień tachografu posiadacza karty.  
356n) Pojemność karty warsztatowej na potrzeby przechowywania 
szczegółowych ustawień tachografu posiadacza karty 
wynosi 3072 bajty.  
▼B 
4.5.5  Karta kontrolna  
4.5.5.1 A p l i k a c j a t a c h o g r a f i c z n a ( d o s t  ę p n a d l a p r z y ­
r z ą d ó w r e j e s t r u j ą c y c h p i e r w s z e j i d r  u g i e j g e n e ­
r a c j i )  
4.5.5.1.1 Identyfikacja aplikacji  
357) Karta kontrolna umożliwia przechowywanie następujących 
danych identyfikujących aplikację:  
— identyfikacja aplikacji tachograficznej,  
— identyfikacja typu karty do tachografów.  
4.5.5.1.2 Klucze i certyfikaty  
358) Karta kontrolna umożliwia przechowywanie szeregu kluczy 
i certyfikatów kryptograficznych, jak określono w dodatku 
11 część A.  
4.5.5.1.3 Identyfikacja karty  
359) Karta kontrolna umożliwia przechowywanie następujących 
danych identyfikujących kartę:  
— numer karty,  
— państwo członkowskie wydające kartę, nazwa organu 
wydającego, data wydania,  
— data rozpoczęcia okresu ważności karty, termin 
ważności karty (jeżeli jest określony).  
4.5.5.1.4 Identyfikacja posiadacza karty  
360) Karta kontrolna umożliwia przechowywanie następujących 
danych identyfikujących posiadacza karty:  
— nazwa organu kontrolnego,  
— adres organu kontrolnego,  
— nazwisko posiadacza karty,  
— imię (imiona) posiadacza karty,  
— preferowany język.  
4.5.5.1.5 Dane dotyczące czynności kontrolnych  
361) Karta kontrolna umożliwia przechowywanie następujących 
danych dotyczących czynności kontrolnych:  
— data i godzina kontroli,  
▼M3 
— rodzaj kontroli (wyświetlanie lub drukowanie lub pobie­
ranie danych z przyrządu rejestrującego lub pobieranie 
danych z karty),  
▼B 
— okres, dla którego pobrano dane (jeżeli ma zastoso­
wanie),  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 95  
— numer VRN i państwo członkowskie rejestracji kontro­
lowanego pojazdu,  
— numer karty i państwo członkowskie wydające kontro­
lowaną kartę kierowcy.  
362) Karta kontrolna umożliwia przechowywanie co najmniej 
230 takich rekordów danych.  
4.5.5.2 A p l i k a c j a t a c h o g r a f i c z n a 2 . g e n  e r a c j i ( n i e d o ­
s t ę p n a d l a p r z y r z ą d ó w r e j e s t r u j ą c y c  h p i e r w s z e j 
g e n e r a c j i )  
4.5.5.2.1 Identyfikacja aplikacji  
363) Karta kontrolna umożliwia przechowywanie następujących 
danych identyfikujących aplikację:  
— identyfikacja aplikacji tachograficznej,  
— identyfikacja typu karty do tachografów.  
▼M3 
4.5.5.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w p rzypadku wersji 
1 drugiej generacji przyrządów rejestrujących)  
363a) Karta kontrolna umożliwia przechowywanie dodatkowych 
danych identyfikujących aplikacje mających zastosowanie 
wyłącznie do wersji 2.  
▼B 
4.5.5.2.2 Klucze i certyfikaty  
364) Karta kontrolna umożliwia przechowywanie szeregu kluczy 
i certyfikatów kryptograficznych, jak określono w dodatku 
11 część B.  
4.5.5.2.3 Identyfikacja karty  
365) Karta kontrolna umożliwia przechowywanie następujących 
danych identyfikujących kartę:  
— numer karty,  
— państwo członkowskie wydające kartę, nazwa organu 
wydającego, data wydania,  
— data rozpoczęcia okresu ważności karty, termin 
ważności karty (jeżeli jest określony).  
4.5.5.2.4 Identyfikacja posiadacza karty  
366) Karta kontrolna umożliwia przechowywanie następujących 
danych identyfikujących posiadacza karty:  
— nazwa organu kontrolnego,  
— adres organu kontrolnego,  
— nazwisko posiadacza karty,  
— imię (imiona) posiadacza karty,  
— preferowany język.  
4.5.5.2.5 Dane dotyczące czynności kontrolnych  
367) Karta kontrolna umożliwia przechowywanie następujących 
danych dotyczących czynności kontrolnych:  
— data i godzina kontroli,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 96  
— rodzaj kontroli (wyświetlanie lub drukowanie lub pobie­
ranie danych z przyrządu rejestrującego lub karty lub 
kontrola drogowa kalibracji),  
— okres, dla którego pobrano dane (jeżeli ma zastoso­
wanie),  
— numer VRN i państwo członkowskie rejestracji kontro­
lowanego pojazdu,  
— numer karty i państwo członkowskie wydające kontro­
lowaną kartę kierowcy.  
368) Karta kontrolna umożliwia przechowywanie co najmniej 
230 takich rekordów danych.  
▼M3 
4.5.5.2.6 Konfiguracje przyrządu rejestrującego (brak dostępu w  przypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
368a) Karta kontrolna umożliwia przechowywanie szczegółowych 
ustawień tachografu posiadacza karty.  
368b) Pojemność karty kontrolnej na potrzeby przechowywania 
szczegółowych ustawień tachografu posiadacza karty 
wynosi 3072 bajty.  
▼B 
4.5.6  Karta firmowa  
4.5.6.1 A p l i k a c j a t a c h o g r a f i c z n a ( d o s t  ę p n a d l a p r z y ­
r z ą d ó w r e j e s t r u j ą c y c h p i e r w s z e j i d r  u g i e j g e n e ­
r a c j i )  
4.5.6.1.1 Identyfikacja aplikacji  
369) Karta firmowa umożliwia przechowywanie następujących 
danych identyfikujących aplikację:  
— identyfikacja aplikacji tachograficznej,  
— identyfikacja typu karty do tachografów.  
4.5.6.1.2 Klucze i certyfikaty  
370) Karta firmowa umożliwia przechowywanie szeregu kluczy 
i certyfikatów kryptograficznych, jak określono w dodatku 
11 część A.  
4.5.6.1.3 Identyfikacja karty  
371) Karta firmowa umożliwia przechowywanie następujących 
danych identyfikujących kartę:  
— numer karty,  
— państwo członkowskie wydające kartę, nazwa organu 
wydającego, data wydania,  
— data rozpoczęcia okresu ważności karty, termin 
ważności karty (jeżeli jest określony).  
4.5.6.1.4 Identyfikacja posiadacza karty  
372) Karta firmowa umożliwia przechowywanie następujących 
danych identyfikujących posiadacza karty:  
— nazwa firmy,  
— adres firmy.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 97  
4.5.6.1.5 Dane dotyczące czynności wykonywanych przez firmę  
373) Karta firmowa umożliwia przechowywanie następujących 
danych dotyczących czynności wykonywanych przez firmę:  
— data i godzina czynności,  
— typ czynności (blokowanie lub zdejmowanie blokady 
z przyrządu rejestrującego lub pobieranie danych z przy­
rządu rejestrującego lub pobieranie danych z karty),  
— okres, dla którego pobrano dane (jeżeli ma zastoso­
wanie),  
— numer VRN i państwo członkowskie rejestracji 
pojazdu,  
— numer karty i państwo członkowskie wydające kartę 
(w przypadku pobierania danych z karty).  
374) Karta firmowa umożliwia przechowywanie co najmniej 230 
takich rekordów danych.  
4.5.6.2 A p l i k a c j a t a c h o g r a f i c z n a 2 . g e n  e r a c j i ( n i e d o ­
s t ę p n a d l a p r z y r z ą d ó w r e j e s t r u j ą c y c  h p i e r w s z e j 
g e n e r a c j i )  
4.5.6.2.1 Identyfikacja aplikacji  
375) Karta firmowa umożliwia przechowywanie następujących 
danych identyfikujących aplikację:  
— identyfikacja aplikacji tachograficznej,  
— identyfikacja typu karty do tachografów.  
▼M3 
4.5.6.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w p rzypadku wersji 
1 drugiej generacji przyrządów rejestrujących)  
375a) Karta firmowa umożliwia przechowywanie dodatkowych 
danych identyfikujących aplikacje mających zastosowanie 
wyłącznie do wersji 2.  
▼B 
4.5.6.2.2 Klucze i certyfikaty  
376) Karta firmowa umożliwia przechowywanie szeregu kluczy 
i certyfikatów kryptograficznych, jak określono w dodatku 
11 część B.  
4.5.6.2.3 Identyfikacja karty  
377) Karta firmowa umożliwia przechowywanie następujących 
danych identyfikujących kartę:  
— numer karty,  
— państwo członkowskie wydające kartę, nazwa organu 
wydającego, data wydania,  
— data rozpoczęcia okresu ważności karty, termin 
ważności karty (jeżeli jest określony).  
4.5.6.2.4 Identyfikacja posiadacza karty  
378) Karta firmowa umożliwia przechowywanie następujących 
danych identyfikujących posiadacza karty:  
— nazwa firmy,  
— adres firmy.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 98  
4.5.6.2.5 Dane dotyczące czynności wykonywanych przez firmę  
379) Karta firmowa umożliwia przechowywanie następujących 
danych dotyczących czynności wykonywanych przez firmę:  
— data i godzina czynności,  
— typ czynności (blokowanie lub zdejmowanie blokady 
z przyrządu rejestrującego lub pobieranie danych z przy­
rządu rejestrującego lub pobieranie danych z karty),  
— okres, dla którego pobrano dane (jeżeli ma zastoso­
wanie),  
— numer VRN i państwo członkowskie rejestracji 
pojazdu,  
— numer karty i państwo członkowskie wydające kartę 
(w przypadku pobierania danych z karty).  
380) Karta firmowa umożliwia przechowywanie co najmniej 230 
takich rekordów danych.  
▼M3 
4.5.6.2.6 Konfiguracje przyrządu rejestrującego (brak dostępu w  przypadku 
wersji 1 drugiej generacji przyrządów rejestrujących)  
380a) Karta firmowa umożliwia przechowywanie szczegółowych 
ustawień tachografu posiadacza karty.  
380b) Pojemność karty firmowej na potrzeby przechowywania 
szczegółowych ustawień tachografu posiadacza karty 
wynosi 3072 bajty.  
▼B 
5 INSTALACJA URZĄDZENIA REJESTRUJĄCEGO  
5.1 Instalacja  
381) Nowe urządzenie rejestrujące dostarcza się instalatorom lu b 
producentom pojazdów w stanie nieaktywowanym, ze 
wszystkimi parametrami kalibracyjnymi, wyszczególnio­
nymi w rozdziale 3.21, ustawionymi na odpowiednie 
i prawidłowe wartości domyślne. W przypadku gdy nie 
ma konkretnej odpowiedniej wartości, parametry literowe 
należy ustawić jako łańcuchy znaków „?”, a parametry licz­
bowe jako „0”. Dostawę części układu zabezpieczającego 
urządzeń rejestrujących można w razie konieczności ogra­
niczyć podczas certyfikacji bezpieczeństwa.  
382) Przed aktywacją urządzenie rejestrujące umożliwia dostęp 
do funkcji kalibracji, nawet jeśli nie jest w trybie 
kalibracyjnym.  
▼M3 
383) Przed aktywacją urządzenia rejestrującego nie rejestruje o no 
ani nie przechowuje danych, o których mowa w wymogach 
102–133. Niemniej jednak przed aktywacją urządzenia 
rejestrującego może ono rejestrować i przechowywać 
zdarzenia związane z próbami naruszenia zabezpieczenia 
zgodnie z wymogiem 117 oraz usterki urządzenia rejestru­
jącego zgodnie z wymogiem 118.  
▼B 
384) W czasie instalacji producenci pojazdów wstępnie ustawiają  
wszystkie znane parametry.  
385) Producenci pojazdów lub instalatorzy aktywują zainstalo­
wane urządzenie rejestrujące najpóźniej przed rozpoczęciem 
korzystania z pojazdu w zakresie objętym rozporządze­
niem (WE) nr 561/2006.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 99  
386) Aktywacja urządzenia rejestrującego uruchamiana jest auto­
matycznie przez pierwsze włożenie ważnej karty warsz­
tatowej do któregokolwiek czytnika karty.  
387) Szczególne czynności parujące, wymagane między czujni­
kiem ruchu a przyrządem rejestrującym, odbywają się 
w razie potrzeby automatycznie przed aktywacją lub 
w trakcie aktywacji.  
388) Podobnie szczególne czynności powiązania, wymagane 
między urządzeniem zewnętrznym GNSS a przyrządem 
rejestrującym, odbywają się w razie potrzeby automatycznie 
przed aktywacją lub w czasie aktywacji.  
389) Po aktywowaniu urządzenia rejestrującego wszystkie 
funkcje i prawa dostępu do danych muszą być w pełni 
wdrożone.  
390) Po aktywowaniu urządzenie rejestrujące przekazuje do urzą­
dzenia do łączności na odległość zabezpieczone dane 
niezbędne na potrzeby ukierunkowanych kontroli drogowych.  
391) Po aktywowaniu urządzenia rejestrującego funkcje rejestro­
wania i przechowywania muszą być w pełni funkcjonalne.  
▼M3 
392) Następnym krokiem po instalacji jest kalibracja. Podczas 
pierwszej kalibracji nie jest konieczne wprowadzenie iden­
tyfikacji rejestracyjnej pojazdu (VRN i państwo członkow­
skie), jeżeli nie jest ona znana zatwierdzonemu warsztatowi 
mającemu przeprowadzić kalibrację. W tej sytuacji, i tylko 
wtedy, właściciel pojazdu może wprowadzić numer VRN 
i państwo członkowskie, używając swojej karty firmowej 
przed rozpoczęciem korzystania z pojazdu w zakresie 
objętym rozporządzeniem (WE) nr 561/2006 (np. używając 
poleceń poprzez odpowiednie menu interfejsu człowiek- 
maszyna przyrządu rejestrującego). Każda aktualizacja lub 
potwierdzenie wprowadzonych w ten sposób danych są 
możliwe jedynie przy użyciu karty warsztatowej.  
▼B 
393) Instalacja urządzenia zewnętrznego GNSS wymaga powią­
zania z przyrządem rejestrującym, a następnie weryfikacji 
informacji o pozycji GNSS.  
394) Urządzenie rejestrujące musi być umieszczone w pojeździe 
w taki sposób, aby kierowca miał ze swojego siedzenia 
dostęp do niezbędnych funkcji.  
5.2 Tabliczka instalacyjna  
395) ►M3 Po zainstalowaniu i sprawdzeniu urządzenia rejes­
trującego mocuje się na nim dobrze widoczną i łatwo 
dostępną tabliczkę instalacyjną, wygrawerowaną lub nadru­
kowaną w trwały sposób. Jeżeli nie jest to możliwe, 
tabliczkę mocuje się na słupku „B” pojazdu, tak aby była 
dobrze widoczna. W przypadku pojazdów, które nie posia­
dają słupka „B”, tabliczkę instalacyjną należy umocować 
w strefie drzwi pojazdu, tak aby zawsze była dobrze 
widoczna. ◄  
Po każdym przeglądzie przeprowadzonym przez zatwier­
dzonego instalatora lub warsztat, w miejsce starej tabliczki 
mocuje się nową.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 100  
396) Tabliczka zawiera co najmniej następujące dane:  
— nazwa, adres lub nazwa handlowa zatwierdzonego 
instalatora lub warsztatu,  
— współczynnik charakterystyczny pojazdu, w postaci 
„w = …imp/km”,  
— stała urządzenia rejestrującego, w postaci „k = …imp/ 
km”,  
— obwód toczny opon, w postaci „l = …mm”,  
— rozmiar opon,  
— data pomiaru współczynnika charakterystycznego 
pojazdu i obwodu tocznego opon,  
— numer identyfikacyjny pojazdu,  
— obecność (lub brak) urządzenia zewnętrznego GNSS,  
— numer seryjny urządzenia zewnętrznego GNSS, 
w stosownych przypadkach,  
▼M3 
— numer seryjny urządzenia do łączności na odległość, 
jeżeli występuje,  
▼M1 
— numer seryjny wszystkich założonych plomb,  
— część pojazdu, w której zamontowany jest ewentualny 
adapter,  
— część pojazdu, w której zamontowany jest czujnik 
ruchu, jeżeli nie jest podłączony do skrzyni biegów 
lub w przypadku niezastosowania adaptera,  
— kolor przewodu łączącego adapter z częścią pojazdu, 
z której dochodzą impulsy,  
— numer seryjny czujnika ruchu wbudowanego w adapter.  
▼M3 
— domyślny typ załadunku związany z pojazdem.  
▼B 
397) Drugą dodatkową tabliczkę można użyć tylko w pojazdach 
M1 i N1, w których zainstalowany jest adapter zgodnie 
z rozporządzeniem Komisji (WE) nr 68/2009 (  1 ) z później­
szymi zmianami, oraz gdy nie ma możliwości zamiesz­
czenia wszystkich niezbędnych informacji opisanych 
w wymaganiu 396. W takich przypadkach na dodatkowej 
tabliczce zamieszczane są co najmniej ostatnie cztery tiret 
określone w wymaganiu 396.  ▼M1 
( 1 ) Rozporządzenie Komisji (WE) nr 68/2009 z dnia 23 stycznia 200 9 r. dostosowujące do 
postępu technicznego po raz dziewiąty rozporządzenie Rady (EWG)  nr 3821/85 w sprawie 
urządzeń rejestrujących stosowanych w transporcie drogowym (Dz. U. L 21 z 24.1.2009, 
s. 3).
 02016R0799 — PL — 21.08.2023 — 003.001 — 101  
Drugą dodatkową tabliczkę mocuje się w stosownych przy­
padkach obok lub w pobliżu pierwszej podstawowej 
tabliczki opisanej w wymaganiu 396 i zapewnia się jej 
taki sam poziom ochrony. Na dodatkowej tabliczce 
umieszcza się ponadto nazwę, adres lub nazwę handlową 
zatwierdzonego instalatora lub warsztatu, który dokonał 
instalacji, oraz datę instalacji.  
5.3 Plombowanie  
398) Następujące części muszą być zaplombowane:  
— Wszelkie połączenia, których rozłączenie może powo­
dować niewykrywalne zmiany danych lub niewykry­
walne utraty danych (może to dotyczyć np. instalacji 
czujnika ruchu na skrzyni biegów, adapterów w pojaz­
dach M1/N1, połączenia z urządzeniem zewnętrznym 
GNSS lub przyrządu rejestrującego);  
— Tabliczka instalacyjna, chyba że jest przymocowana 
w taki sposób, że nie można jej usunąć bez uszkodzenia 
wykonanych na niej oznaczeń.  
▼M1 
398a) Plomby, o których mowa powyżej, muszą być certyfiko­
wane zgodnie z normą EN 16882:2016.  
▼B 
399) Plomby, o których mowa powyżej, mogą być usunięte:  
— w nagłych przypadkach,  
— w celu zainstalowania, wyregulowania lub naprawy 
urządzenia ograniczenia prędkości lub innego urzą­
dzenia istotnego dla bezpieczeństwa drogowego, 
z zastrzeżeniem że urządzenie rejestrujące nadal pracuje 
niezawodnie i prawidłowo i zostanie powtórnie zaplom­
bowane przez zatwierdzonego instalatora lub warsztat 
(zgodnie z rozdziałem 6) niezwłocznie po zainstalo­
waniu urządzenia ograniczenia prędkości lub innego 
urządzenia istotnego dla bezpieczeństwa drogowego 
lub w terminie siedmiu dni w pozostałych przypadkach.  
400) Każdy przypadek zdjęcia takiej plomby wymaga sporzą­
dzenia pisemnego oświadczenia podającego powody 
takiego działania, a oświadczenie to udostępniane jest 
właściwemu organowi.  
401) Plomby muszą mieć numer identyfikacyjny przydzielony 
przez ich producenta. Numer ten jest niepowtarzalny 
i różny od innych numerów plomb przydzielonych przez 
innych producentów plomb.  
▼M1 
Ten niepowtarzalny numer identyfikacyjny jest określony 
w następujący sposób: MMNNNNNNNN w formie nieda­
jącego się usunąć oznakowania, gdzie MM to jednoznaczny 
identyfikator producenta (numer w bazie danych prowa­
dzonej przez KE), a NNNNNNNN to numer alfanume­
ryczny plomby, niepowtarzalny dla danego producenta.  
▼B 
402) Na plombie musi być wolne miejsce, na którym zatwier­
dzeni instalatorzy, warsztaty lub producenci pojazdów 
mogą dodać specjalny znak zgodnie z art. 22 ust. 3 rozpo­
rządzenia (UE) nr 165/2014.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 102  
Znak ten nie może zakrywać numeru identyfikacyjnego 
plomby.  
▼M1 
403) Producenci plomb muszą być zarejestrowani w specjalnej 
bazie danych, gdy otrzymują model plomby certyfikowany 
zgodnie z normą EN 16882:2016, i muszą udostępniać 
publicznie numery identyfikacyjne plomb w procedurze, 
którą ma określić Komisja Europejska.  
404) Zatwierdzone warsztaty i producenci pojazdów korzystają, 
w ramach rozporządzenia (UE) nr 165/2014, wyłącznie 
z plomb certyfikowanych zgodnie z normą EN 16882:2016 
od producentów plomb zapisanych w bazie danych, o której 
mowa powyżej.  
▼B 
405) Producenci plomb i ich dystrybutorzy zachowują pełną 
dokumentację umożliwiającą identyfikowalność plomb 
sprzedawanych do użytku w ramach rozporządzenia (UE) 
nr 165/2014 i są gotowi do jej przedłużenia właściwym 
organom krajowym w razie potrzeby.  
406) Niepowtarzalne numery identyfikacyjne plomb muszą być 
widoczne na tabliczce instalacyjnej.  
6 KONTROLE, PRZEGLĄDY I NAPRAWY  
Wymagania odnośnie do okoliczności, w jakich można usunąć 
plomby, określone w art. 22 ust. 5 rozporządzenia (UE) nr 165/2 014, 
zostały zdefiniowane w rozdziale 5.3 niniejszego załącznika.  
6.1 Zatwierdzanie instalatorów, warsztatów i producentów 
pojazdów  
Państwa członkowskie zatwierdzają, regularnie kontrolują i cert yfi­
kują instytucje odpowiadające za:  
— instalacje,  
— kontrole,  
— przeglądy,  
— naprawy.  
Karty warsztatowe wydaje się wyłącznie instalatorom lub warsz­
tatom zatwierdzonym do aktywowania lub kalibrowania urządzeń 
rejestrujących zgodnie z niniejszym załącznikiem i, chyba że is tnieją 
inne należyte uzasadnienia,  
— którzy nie kwalifikują się do posiadania karty firmowej,  
— i których inna działalność zawodowa nie stanowi potencjalnego  
zagrożenia dla ogólnego bezpieczeństwa systemu zgodnie 
z wymogami w dodatku 10.  
▼M1 
6.2 Kontrola techniczna elementów sk ładowych nowych lub po 
naprawie  
407) Każdy przyrząd, tak nowy, jak i po naprawie, jest kontro­
lowany pod względem prawidłowego funkcjonowania oraz 
dokładności odczytów i rejestracji, w granicach określo­
nych w rozdziałach 3.2.1, 3.2.2, 3.2.3 oraz 3.3.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 103  
6.3 Przegl ąd instalacyjny  
▼M1 
408) Po zainstalowaniu w pojeździe cała instalacja (włącznie 
z urządzeniem rejestrującym) musi być zgodna z przepisami 
dotyczącymi maksymalnych tolerancji ustanowionymi 
w rozdziałach 3.2.1, 3.2.2, 3.2.3 i 3.3. Cała instalacja 
musi być zaplombowana zgodnie z rozdziałem 5.3 i musi 
obejmować kalibrację.  
▼B 
6.4 Przegl ądy okresowe  
▼M3 
409) Przeglądy okresowe urządzeń zainstalowanych w pojazdach 
przeprowadza się po każdej naprawie urządzenia lub po 
jakiejkolwiek zmianie współczynnika charakterystycznego 
pojazdu lub obwodu tocznego opon, lub gdy czas UTC 
urządzenia różni się od czasu UTC o więcej niż 5 minut, 
lub przy zmianie numeru VRN i przynajmniej raz w okresie 
dwóch lat (24 miesięcy) od ostatniej kontroli.  
▼B 
410) Przeglądy te obejmują następujące kontrole:  
— czy urządzenie rejestrujące działa prawidłowo, włącznie 
z funkcją przechowywania danych na kartach do tacho­
grafów oraz łącznością z czytnikami na odległość,  
— czy jest zachowana zgodność z wymaganiami rozdziału 
3.2.1 i 3.2.2 co do maksymalnych tolerancji przy 
instalacji,  
— czy jest zachowana zgodność z przepisami rozdziałów 
3.2.3 i 3.3,  
— czy urządzenie rejestrujące opatrzone jest znakiem 
homologacji typu,  
— czy tabliczka instalacyjna określona w wymaganiu 396 
oraz tabliczka określona w wymaganiu 225 są 
zamocowane,  
— rozmiaru opon i faktycznego obwodu tocznego opon,  
— czy do urządzenia nie są podłączone żadne urządzenia 
służące do manipulacji,  
— czy plomby są prawidłowo założone, w dobrym stanie, 
czy ich numery identyfikacyjne są ważne (producent 
plomb zatwierdzony w bazie KE) oraz czy ich numery 
identyfikacyjne odpowiadają oznakowaniom na tabliczce 
instalacyjnej (zob. wymaganie 401).  
▼M3 
— czy identyfikator wersji przechowywanej mapy cyfrowej 
jest najnowszym identyfikatorem.  
410a) W przypadku wykrycia manipulacji przez właściwe organy 
krajowe pojazd może zostać wysłany do zatwierdzonego 
warsztatu w celu dokonania ponownej kalibracji urządzenia 
rejestrującego.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 104  
411) Jeżeli jedno ze zdarzeń wymienionych w rozdziale 3.9 
(Wykrywanie zdarzeń lub usterek) pojawiło się od czasu 
poprzedniego przeglądu i producenci tachografów lub 
organy krajowe uważają, że stwarza ono zagrożenie dla 
bezpieczeństwa urządzenia, warsztat:  
a. porównuje dane identyfikacyjne czujnika ruchu podłą­
czonego do skrzyni biegów z danymi sparowanego czuj­
nika ruchu zarejestrowanymi w przyrządzie rejestru­
jącym;  
b. sprawdza, czy informacje zapisane na tabliczce instala­
cyjnej są zgodne z informacjami zawartymi w przyrzą­
dzie rejestrującym;  
c. sprawdza, czy numer seryjny czujnika ruchu i numer 
homologacji, jeżeli są nadrukowane na obudowie czuj­
nika ruchu, są zgodne z informacjami przechowywa­
nymi w pamięci danych urządzenia rejestrującego;  
d. porównuje dane identyfikacyjne umieszczone na tabliczce 
znamionowej ewentualnego urządzenia zewnętrznego 
GNSS z danymi przechowywanymi w pamięci danych 
przyrządu rejestrującego.  
412) Warsztaty odnotowują w swoich sprawozdaniach z prze­
glądu wszystkie ustalenia dotyczące zniszczonych plomb 
lub urządzeń służących do manipulacji. Warsztaty przecho­
wują przedmiotowe sprawozdania co najmniej przez 2 lata 
i udostępniają je każdorazowo na wniosek właściwego 
organu.  
413) W ramach przeglądów wykonuje się kalibrację i zapobie­
gawczą wymianę plomb, za których montaż odpowiadają 
warsztaty.  
6.5 Wyznaczanie b łędów 
414) Wyznaczanie błędów po zainstalowaniu i podczas użytko­
wania jest wykonywane w następujących warunkach, które 
stanowią warunki odniesienia:  
— pojazd bez obciążenia w stanie gotowym do jazdy,  
— ciśnienie w ogumieniu zgodne z instrukcjami producenta,  
— zużycie ogumienia w granicach dopuszczalnych przepi­
sami krajowymi,  
— ruch pojazdu:  
— pojazd porusza się napędzany własnym silnikiem, po 
linii prostej i po poziomej powierzchni, z prędkością 
50 ± 5 km/h. Odległość pomiarowa wynosi przynaj­
mniej 1 000 m.  
— sprawdzenie może być również przeprowadzone inną 
metodą, np. na odpowiednim stanowisku warsztatowym, 
pod warunkiem że zapewni ono porównywalną dokład­
ność. ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 105  
6.6 Naprawy  
415) Warsztaty mogą pobierać dane z urządzenia rejestrującego 
w celu przekazania tych danych odpowiedniej firmie 
przewozowej.  
416) Zatwierdzone warsztaty wydają firmom przewozowym 
zaświadczenie o niemożliwości pobrania danych, w przy­
padku gdy uszkodzenie urządzenia rejestrującego uniemoż­
liwia pobranie zarejestrowanych danych nawet po naprawie 
w tym warsztacie. Warsztaty przechowują kopię każdego 
wydanego zaświadczenia przez okres co najmniej dwóch 
lat. 
7 WYDAWANIE KART  
Procedury wydawania kart określone przez państwa członkowskie 
spełniają następujące wymagania:  
417) Pierwsza karta do tachografów wydana wnioskodawcy ma 
numer karty równy numerowi kolejnemu (jeżeli ma zasto­
sowanie), a numer wymiany i numer odnowienia ustawione 
na „0”.  
418) Numery karty wszystkich nieosobistych kart do tacho­
grafów wydanych jednemu organowi kontrolnemu lub 
jednemu warsztatowi lub jednej firmie przewozowej mają 
te same pierwsze 13 cyfr i wszystkie mają różny numer 
kolejny.  
419) Karta do tachografów wydana jako duplikat istniejącej 
karty do tachografów ma ten sam numer karty co karta 
zastąpiona, z wyjątkiem numeru wymiany, który jest 
zwiększany o „1” (w kolejności 0, …, 9, A, …, Z).  
420) Karta do tachografów wydana jako duplikat istniejącej 
karty do tachografów ma ten sam termin ważności karty 
co karta zastąpiona.  
421) Karta do tachografów wydana jako odnowienie istniejącej 
karty do tachografów ma ten sam numer karty co karta 
odnowiona, z wyjątkiem numeru wymiany, który jest usta­
wiony na „0” i numeru odnowienia, który jest zwiększany 
o „1” (w kolejności 0, …, 9, A, …, Z).  
422) Przy wymianie istniejącej karty do tachografów w celu 
zmiany danych administracyjnych stosuje się te same 
zasady co przy odnawianiu, jeżeli odbywa się w tym 
samym państwie członkowskim, lub te same zasady co 
przy pierwszym wydaniu, jeżeli odbywa się w innym 
państwie członkowskim.  
423) W rubryce „nazwisko posiadacza karty” w przypadku 
nieosobistych kart warsztatowych lub kontrolnych wpisuje 
się albo nazwę warsztatu lub organu kontrolnego albo 
nazwisko instalatora lub funkcjonariusza służb kontrolnych, 
według uznania państw członkowskich.  
424) Państwa członkowskie wymieniają dane drogą elektro­
niczną w celu zapewnienia niepowtarzalności wydawanych 
kart kierowcy zgodnie z art. 31 rozporządzenia (UE) 
nr 165/2014.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 106  
8 HOMOLOGACJA TYPU URZĄDZEŃ REJESTRUJĄCYCH 
I KART DO TACHOGRAFÓW  
8.1 Uwagi ogólne  
▼M1 
Do celów niniejszego rozdziału wyrażenie „urządzenie rejestrują ce” 
oznacza „urządzenie rejestrujące lub jego elementy składowe”. 
Homologacji typu nie wymaga się dla przewodu(-ów) łączącego(- 
ych) czujnik ruchu z przyrządem rejestrującym, urządzenie 
zewnętrzne GNSS z przyrządem rejestrującym lub zewnętrzne urzą­
dzenie do łączności na odległość z przyrządem rejestrującym. Pa pier 
używany przez urządzenie rejestrujące uważa się za element skła ­
dowy urządzenia rejestrującego.  
Każdy producent może zwrócić się o homologację typu elementów 
składowych urządzenia rejestrującego z wszelkimi innymi elemen­
tami składowymi urządzenia rejestrującego, pod warunkiem że 
każdy element składowy jest zgodny z wymogami niniejszego 
załącznika. Producenci mogą również zwrócić się o homologację 
typu urządzenia rejestrującego.  
Jak opisano w definicji 10 w art. 2 niniejszego rozporządzenia,  
przyrządy rejestrujące mają różne warianty zespołów elementów 
składowych. Bez względu na wariant zespołu elementów składo­
wych przyrządu rejestrującego, antena zewnętrzna i rozdzielacz 
antenowy podłączony do odbiornika GNSS lub do urządzenia do 
łączności na odległość nie stanowią części homologacji typu prz y­
rządu rejestrującego.  
Niemniej jednak po uzyskaniu homologacji typu urządzenia rejest rują­
cego producenci prowadzą powszechnie dostępny wykaz anten 
i rozdzielaczy kompatybilnych z każdym homologowanym przyrządem  
rejestrującym, urządzeniem zewnętrznym GNSS i zewnętrznym urzą­
dzeniem do łączności na odległość.  
▼B 
425) Urządzenie rejestrujące dostarcza się do homologacji 
w stanie kompletnym z wszystkimi zintegrowanymi urzą­
dzeniami dodatkowymi.  
426) Homologacja typu urządzenia rejestrującego i kart do 
tachografów obejmuje badania związane z bezpieczeń­
stwem, badania funkcjonalności i badania interoperacyj­
ności. Pozytywne wyniki każdego z tych badań potwierdza 
się odpowiednim świadectwem.  
▼M1 
427) Organy homologacji typu w państwach członkowskich nie 
wydają świadectwa homologacji typu, dopóki nie otrzy­
mają:  
— świadectwa bezpieczeństwa (jeżeli jest ono wymagane 
na podstawie niniejszego załącznika),  
— świadectwa funkcjonalności,  
— świadectwa interoperacyjności (jeżeli jest ono wyma­
gane na podstawie niniejszego załącznika),  
dla urządzenia rejestrującego lub kart do tachografów, dla 
których złożono wniosek o homologację typu.  
▼B 
428) O wszelkich modyfikacjach oprogramowania lub sprzętu 
urządzenia lub rodzaju materiałów użytych do wytworzenia 
urządzenia należy, przed zastosowaniem, zawiadomić 
organ, który wydał homologację typu dla urządzenia. 
Organ ten potwierdza producentowi rozszerzenie homolo­
gacji typu lub też może zażądać uaktualnienia lub potwier­
dzenia stosownych świadectw funkcjonalności, bezpieczeń­
stwa lub interoperacyjności.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 107  
429) Procedury aktualizacji oprogramowania w prawidłowo 
funkcjonującym urządzeniu rejestrującym zatwierdza organ, 
który wydał homologację typu dla tego urządzenia rejes­
trującego. Aktualizacja oprogramowania nie może zmienić 
ani usunąć żadnych danych dotyczących czynności 
kierowcy przechowywanych w pamięci urządzenia rejestru­
jącego. Oprogramowanie można aktualizować wyłącznie na 
odpowiedzialność producenta urządzenia.  
430) Nie można odmówić homologacji typu zmian w oprogramo­
waniu, których celem jest aktualizacja wcześniej homolo­
gowanego typu urządzenia rejestrującego, jeżeli takie 
zmiany dotyczą wyłącznie funkcji nieokreślonych w niniej­
szym załączniku. Aktualizacja oprogramowania urządzenia 
rejestrującego może nie obejmować wprowadzania nowych 
zestawów znaków, jeśli nie jest to technicznie wykonalne.  
▼B 
8.2 Świadectwo bezpiecze ństwa  
431) Świadectwo bezpieczeństwa wydaje się zgodnie z przepi­
sami dodatku 10 do niniejszego załącznika. Elementy skła­
dowe urządzenia rejestrującego objęte certyfikacją to przy­
rząd rejestrujący, czujnik ruchu, urządzenie zewnętrzne 
GNSS i karty do tachografów.  
432) W wyjątkowej sytuacji, gdy organy certyfikacji bezpieczeń­
stwa odmawiają certyfikowania nowego urządzenia 
z powodu przestarzałych mechanizmów bezpieczeństwa, 
homologację typu przyznaje się nadal tylko w tych konkret­
nych i wyjątkowych okolicznościach oraz jeżeli, zgodnie 
z rozporządzeniem, nie istnieje rozwiązanie alternatywne.  
433) W takiej sytuacji dane państwo członkowskie bezzwłocznie 
informuje Komisję Europejską, która w ciągu dwunastu 
miesięcy kalendarzowych od przyznania homologacji typu 
wszczyna procedurę mającą na celu zapewnienie przywró­
cenia poziomu bezpieczeństwa do stanu początkowego.  
8.3 Świadectwo funkcjonalno ści 
434) Każdy ubiegający się o homologację typu dostarcza orga­
nowi państwa członkowskiego właściwemu dla homolo­
gacji typu wszelkie materiały i dokumentacje, jakie organ 
ten uzna za niezbędne.  
435) W ciągu jednego miesiąca od złożenia wniosku producenci 
dostarczają odpowiednie próbki produktów posiadających 
homologację typu i związaną z nimi dokumentację wyma­
ganą przez laboratoria wyznaczone do przeprowadzenia 
badań funkcjonalności. Wnioskodawca ponosi wszystkie 
koszty wynikające z przedmiotowego wniosku. Laboratoria 
zachowują poufność wszystkich informacji wrażliwych pod 
względem handlowym.  
436) Świadectwo funkcjonalności wydaje się producentowi 
wyłącznie po pozytywnym przejściu przynajmniej przez 
wszystkie badania funkcjonalności wyszczególnione 
w dodatku 9.  
437) Organ właściwy dla homologacji typu wydaje świadectwo 
funkcjonalności. W świadectwie tym podaje się, oprócz 
nazwy (nazwiska) otrzymującego świadectwo i identyfikacji 
modelu, szczegółowy wykaz wykonanych badań i uzyska­
nych wyników.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 108  
438) W świadectwie funkcjonalności każdego elementu składo­
wego urządzenia rejestrującego wskazuje się także numery 
homologacji typu wszystkich innych homologowanych 
kompatybilnych elementów składowych urządzenia rejes­
trującego przebadanych do celów certyfikacji.  
439) W świadectwie funkcjonalności każdego elementu składo­
wego urządzenia rejestrującego wskazuje się także normę 
CEN lub ISO, na podstawie której certyfikowano interfejs 
funkcjonalny.  
8.4 Świadectwo interoperacyjno ści 
440) Badania interoperacyjności przeprowadza jedno laborato­
rium w imieniu i na odpowiedzialność Komisji Europej­
skiej.  
441) Laboratorium rejestruje wnioski o badania interoperacyj­
ności złożone przez producentów w kolejności chronolo­
gicznej napływu tych wniosków.  
442) Wnioski rejestruje się oficjalnie tylko wtedy, gdy w posia ­
daniu laboratorium znajdują się:  
— komplet materiałów i dokumentów niezbędnych do 
takich badań interoperacyjności,  
— odpowiednie świadectwo bezpieczeństwa,  
— odpowiednie świadectwo funkcjonalności.  
Producenta zawiadamia się o dacie rejestracji wniosku.  
▼M3 
443) Laboratorium nie może przeprowadzać żadnych badań inte­
roperacyjności urządzeń rejestrujących ani kart do tacho­
grafów, które nie przeszły pomyślnie analizy podatności 
na zagrożenia w ramach ich oceny bezpieczeństwa, 
a także oceny funkcjonalnej, poza wyjątkowymi sytuacjami 
opisanymi w wymogu 432.  
▼B 
444) Producent wnioskujący o przeprowadzenie badań interope­
racyjności zobowiązuje się do pozostawienia w laborato­
rium, które ma przeprowadzić te badania, kompletu mate­
riałów i dokumentów, które dostarczył do przeprowadzenia 
tych badań.  
445) Badania interoperacyjności przeprowadza się, zgodnie 
z przepisami dodatku 9 do niniejszego załącznika, dla, 
odpowiednio, wszystkich typów urządzenia rejestrującego 
lub kart do tachografów:  
— które mają jeszcze ważną homologację typu, lub  
— których homologacja typu jest w toku i które mają 
ważne świadectwo interoperacyjności.  
446) Badania interoperacyjności obejmują wszystkie generacje 
urządzeń rejestrujących lub kart do tachografów będące 
nadal w użyciu.  
▼M3 
447) Laboratorium wydaje producentowi świadectwo interopera­
cyjności tylko wówczas, gdy objęte nim urządzenia 
pomyślnie przejdą wszystkie wymagane badania interope­
racyjności, i po wykazaniu przez producenta, że wydano 
zarówno ważne świadectwo funkcjonalności, jak i ważne 
świadectwo bezpieczeństwa dla produktu, z wyjątkiem 
wyjątkowych okoliczności opisanych w wymogu 432.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 109  
448) Jeżeli co najmniej jedno urządzenie rejestrujące lub karta  
do tachografów nie przejdą pomyślnie badań interoperacyj­
ności, świadectwa interoperacyjności nie wydaje się, dopóki 
wnioskujący producent nie wprowadzi niezbędnych 
poprawek i dopóki nie przejdą one pomyślnie przez 
badania interoperacyjności. Laboratorium, przy pomocy 
zainteresowanych producentów, rozpoznaje przyczynę 
usterki interoperacyjności i dokłada starań, by pomóc 
wnioskującemu producentowi w znalezieniu rozwiązania 
technicznego. W przypadku gdy producent modyfikuje 
swój produkt, odpowiada on za uzyskanie potwierdzenia 
właściwych organów, że świadectwo bezpieczeństwa i świa­
dectwo funkcjonalności nadal zachowują ważność.  
449) Świadectwo interoperacyjności ważne jest przez sześć 
miesięcy. Zostaje ono odwołane na koniec tego okresu, 
jeżeli producent nie uzyska odpowiadającego mu świa­
dectwa homologacji typu. Producent przekazuje to świa­
dectwo organowi homologacji typu w państwie członkow­
skim, który wydał świadectwo funkcjonalności.  
450) Żaden element, który może być źródłem usterki interopera­
cyjności, nie może być użyty do osiągania korzyści 
z pozycji dominującej ani prowadzić do uzyskania takiej 
pozycji.  
8.5 Świadectwo homologacji typu  
451) Organ homologacji typu w państwie członkowskim może 
wydać świadectwo homologacji typu, jeżeli posiada trzy 
wymagane świadectwa.  
452) W świadectwie homologacji typu każdego elementu skła­
dowego urządzenia rejestrującego wskazuje się także 
numery homologacji typu innych homologowanych intero­
peracyjnych urządzeń rejestrujących.  
453) Organ homologacji typu przekazuje kopię świadectwa 
homologacji typu do laboratorium właściwego do przepro­
wadzenia badań interoperacyjności równocześnie z dostar­
czeniem świadectwa producentowi.  
454) Laboratorium właściwe do przeprowadzenia badań intero­
peracyjności prowadzi publiczną stronę internetową, na 
której znajduje się uaktualniony wykaz modeli urządzeń 
rejestrujących lub kart do tachografów:  
— dla których zarejestrowano wniosek o badania interope­
racyjności,  
— które uzyskały świadectwo interoperacyjności (nawet 
czasowe),  
— które uzyskały świadectwo homologacji typu.  
8.6 Procedura szczególna: pierwsze świadectwa interoperacyjno ści 
dla urządzeń rejestruj ących i kart do tachografów 2. generacji  
455) Przez cztery miesiące od czasu, gdy pierwsza para urządzeń  
rejestrujących 2. generacji i kart do tachografów 2. gene­
racji (karty kierowcy, warsztatowe, kontrolne i firmowe) 
uzyska świadectwa interoperacyjności, wszelkie wydane 
świadectwa interoperacyjności (łącznie z pierwszymi), 
w odniesieniu do wniosków zarejestrowanymi w tym 
okresie, uważa się za czasowe.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 110  
456) Jeżeli na koniec tego okresu wszystkie produkty, których t o 
dotyczy, współdziałają, wszystkie odpowiednie świadectwa 
interoperacyjności zastępuje się świadectwem ostatecznym.  
457) Jeżeli w tym okresie wykryje się usterki interoperacyjnośc i, 
laboratorium właściwe do przeprowadzenia badań interope­
racyjności rozpoznaje przyczyny problemów z pomocą 
wszystkich zainteresowanych producentów i zachęca ich 
do wprowadzenia niezbędnych poprawek.  
458) Jeżeli na koniec tego okresu nadal występują problemy 
interoperacyjności, laboratorium właściwe do przeprowa­
dzenia badań interoperacyjności, we współpracy z zaintere­
sowanymi producentami i organami homologacji typu, 
które wydały odpowiednie świadectwa funkcjonalności, 
szuka przyczyn usterek interoperacyjności i ustala, jakie 
poprawki powinien wprowadzić każdy z zainteresowanych 
producentów. Poszukiwanie rozwiązań technicznych trwa 
maksymalnie dwa miesiące, po czym, jeśli nie zostanie 
znalezione wspólne rozwiązanie, Komisja, po konsultacji 
z laboratorium właściwym do przeprowadzenia badań inte­
roperacyjności, decyduje, które urządzenie(-a) i karty otrzy­
mują ostateczne świadectwa interoperacyjności wraz 
z uzasadnieniem swojej decyzji.  
459) Wszelkie wnioski o przeprowadzenie badań interoperacyj­
ności, zarejestrowane przez laboratorium w okresie między 
końcem czteromiesięcznego okresu po dostarczeniu pierw­
szego czasowego świadectwa interoperacyjności a datą 
decyzji Komisji, o której mowa w wymaganiu 455, są 
odraczane aż do rozwiązania początkowych problemów 
interoperacyjności. Następnie wnioski te rozpatruje się 
w kolejności chronologicznej ich rejestracji.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 111  
Dodatek 1  
SPIS DANYCH:  
SPIS TREŚCI  
1. WPROWADZENIE  
1.1. Podejście do definicji typów danych  
1.2. Odniesienia  
2. DEFINICJE TYPÓW DANYCH  
2.1. ActivityChangeInfo  
2.2. Address  
2.3. AESKey  
2.4. AES128Key  
2.5. AES192Key  
2.6. AES256Key  
2.7. BCDString  
2.8. CalibrationPurpose  
2.9. CardActivityDailyRecord  
2.10. CardActivityLengthRange  
2.11. CardApprovalNumber  
▼M3 
2.11a. CardBorderCrossing  
2.11b. CardBorderCrossingRecord  
▼B 
2.12. CardCertificate  
2.13. CardChipIdentification  
2.14. CardConsecutiveIndex  
2.15. CardControlActivityDataRecord  
2.16. CardCurrentUse  
2.17. CardDriverActivity  
2.18. CardDrivingLicenceInformation  
2.19. CardEventData  
2.20. CardEventRecord  
2.21. CardFaultData  
2.22. CardFaultRecord  
2.23. CardIccIdentification  
2.24. CardIdentification  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 112  
2.24a. CardLoadTypeEntries  
2.24b. CardLoadTypeEntryRecord  
2.24c. CardLoadUnloadOperations  
2.24d. CardLoadUnloadRecord  
▼B 
2.25. CardMACertificate  
2.26. CardNumber  
▼M3 
2.26a. CardPlaceAuthDailyWorkPeriod  
▼B 
2.27. CardPlaceDailyWorkPeriod  
2.28. CardPrivateKey  
2.29. CardPublicKey  
2.30. CardRenewalIndex  
2.31. CardReplacementIndex  
2.32. CardSignCertificate  
2.33. CardSlotNumber  
2.34. CardSlotsStatus  
2.35. CardSlotsStatusRecordArray  
2.36. CardStructureVersion  
2.37. CardVehicleRecord  
2.38. CardVehiclesUsed  
2.39. CardVehicleUnitRecord  
2.40. CardVehicleUnitsUsed  
2.41. Certyfikat  
2.42. CertificateContent  
2.43. CertificateHolderAuthorisation  
2.44. CertificateRequestID  
2.45. CertificationAuthorityKID  
2.46. CompanyActivityData  
2.47. CompanyActivityType  
2.48. CompanyCardApplicationIdentification  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 113  
2.48a. CompanyCardApplicationIdentificationV2  
▼B 
2.49. CompanyCardHolderIdentification  
2.50. ControlCardApplicationIdentification  
▼M3 
2.50a. ControlCardApplicationIdentificationV2  
▼B 
2.51. ControlCardControlActivityData  
2.52. ControlCardHolderIdentification  
2.53. ControlType  
2.54. CurrentDateTime  
2.55. CurrentDateTimeRecordArray  
2.56. DailyPresenceCounter  
2.57. Datef  
2.58. DateOfDayDownloaded  
2.59. DateOfDayDownloadedRecordArray  
2.60. Distance  
▼M3 
2.60a. DownloadInterfaceVersion  
▼B 
2.61. DriverCardApplicationIdentification  
▼M3 
2.61a. DriverCardApplicationIdentificationV2  
▼B 
2.62. DriverCardHolderIdentification  
▼M1 
2.63. Zarezerwowany dla przyszłego użytku  
▼B 
2.64. EGFCertificate  
2.65. EmbedderIcAssemblerId  
2.66. EntryTypeDailyWorkPeriod  
2.67. EquipmentType  
2.68. EuropeanPublicKey  
2.69. EventFaultRecordPurpose  
2.70. EventFaultType  
2.71. ExtendedSealIdentifier  
2.72. ExtendedSerialNumber  
2.73. FullCardNumber  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 114  
2.74. FullCardNumberAndGeneration  
2.75. Generation  
2.76. GeoCoordinates  
2.77. GNSSAccuracy  
▼M1 
2.78. GNSSAccumulatedDriving  
2.79. GNSSAccumulatedDrivingRecord  
▼M3 
2.79a. GNSSAuthAccumulatedDriving  
2.79b. GNSSAuthStatusADRecord  
2.79c. GNSSPlaceAuthRecord  
▼B 
2.80. GNSSPlaceRecord  
2.81. HighResOdometer  
2.82. HighResTripDistance  
2.83. HolderName  
▼M3 
2.84. Zarezerwowane dla przyszłego użytku  
▼B 
2.85. K-ConstantOfRecordingEquipment  
2.86. KeyIdentifier  
2.87. KMWCKey  
2.88. Language  
2.89. LastCardDownload  
▼M3 
2.89a. LengthOfFollowingData  
▼B 
2.90. LinkCertificate  
▼M3 
2.90a. LoadType  
▼B 
2.91. L-TyreCircumference  
2.92. MAC  
2.93. ManualInputFlag  
2.94. ManufacturerCode  
2.95. ManufacturerSpecificEventFaultData  
2.96. MemberStateCertificate  
2.97. MemberStateCertificateRecordArray  
2.98. MemberStatePublicKey  
2.99. Name  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 115  
2.100. NationAlpha  
2.101. NationNumeric  
▼M3 
2.101a. NoOfBorderCrossingRecords  
▼B 
2.102. NoOfCalibrationRecords  
2.103. NoOfCalibrationsSinceDownload  
2.104. NoOfCardPlaceRecords  
2.105. NoOfCardVehicleRecords  
2.106. NoOfCardVehicleUnitRecords  
2.107. NoOfCompanyActivityRecords  
2.108. NoOfControlActivityRecords  
2.109. NoOfEventsPerType  
2.110. NoOfFaultsPerType  
▼M1 
2.111. NoOfGNSSADRecords  
▼M3 
2.111a. NoOfLoadUnloadRecords  
▼B 
2.112. NoOfSpecificConditionRecords  
▼M3 
2.112a. NoOfLoadTypeEntryRecords  
▼B 
2.113. OdometerShort,  
2.114. OdometerValueMidnight  
▼M3 
2.114a. OperationType  
▼B 
2.115. OdometerValueMidnightRecordArray  
2.116. OverspeedNumber  
▼M3 
2.116a. PlaceAuthRecord  
2.116b. PlaceAuthStatusRecord  
▼B 
2.117. PlaceRecord  
▼M3 
2.117a. PositionAuthenticationStatus  
▼B 
2.118. PreviousVehicleInfo  
2.119. PublicKey  
2.120. RecordType  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 116  
2.121. RegionAlpha  
2.122. RegionNumeric  
2.123. RemoteCommunicationModuleSerialNumber  
2.124. RSAKeyModulus  
2.125. RSAKeyPrivateExponent  
2.126. RSAKeyPublicExponent  
2.127. RtmData  
2.128. SealDataCard  
2.129. SealDataVu  
2.130. SealRecord  
2.131. SensorApprovalNumber  
2.132. SensorExternalGNSSApprovalNumber  
2.133. SensorExternalGNSSCoupledRecord  
2.134. SensorExternalGNSSIdentification  
2.135. SensorExternalGNSSInstallation  
2.136. SensorExternalGNSSOSIdentifier  
2.137. SensorExternalGNSSSCIdentifier  
2.138. SensorGNSSCouplingDate  
2.139. SensorGNSSSerialNumber  
2.140. SensorIdentification  
2.141. SensorInstallation  
2.142. SensorInstallationSecData  
2.143. SensorOSIdentifier  
2.144. SensorPaired  
2.145. SensorPairedRecord  
2.146. SensorPairingDate  
2.147. SensorSCIdentifier  
2.148. SensorSerialNumber  
2.149. Podpis  
2.150. SignatureRecordArray  
2.151. SimilarEventsNumber  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 117  
2.152. SpecificConditionRecord  
2.153. SpecificConditions  
2.154. SpecificConditionType  
2.155. Prędkość  
2.156. SpeedAuthorised  
2.157. SpeedAverage  
2.158. SpeedMax  
▼M3 
2.158a. TachographCardsGen1Suppression  
▼B 
2.159. TachographPayload  
▼M1 
2.160. Zarezerwowany dla przyszłego użytku  
▼B 
2.161. TDesSessionKey  
2.162. TimeReal  
2.163. TyreSize  
2.164. VehicleIdentificationNumber  
2.165. VehicleIdentificationNumberRecordArray  
2.166. VehicleRegistrationIdentification  
▼M3 
2.166a. VehicleRegistrationIdentificationRecordArray  
▼B 
2.167. VehicleRegistrationNumber  
2.168. VehicleRegistrationNumberRecordArray  
2.169. VuAbility  
2.170. VuActivityDailyData  
2.171. VuActivityDailyRecordArray  
2.172. VuApprovalNumber  
2.173. VuCalibrationData  
2.174. VuCalibrationRecord  
2.175. VuCalibrationRecordArray  
2.176. VuCardIWData  
2.177. VuCardIWRecord  
2.178. VuCardIWRecordArray  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 118  
2.179. VuCardRecord  
2.180. VuCardRecordArray  
2.181. VuCertificate  
2.182. VuCertificateRecordArray  
2.183. VuCompanyLocksData  
2.184. VuCompanyLocksRecord  
2.185. VuCompanyLocksRecordArray  
▼M3 
2.185a. VuConfigurationLengthRange  
▼B 
2.186. VuControlActivityData  
2.187. VuControlActivityRecord  
2.188. VuControlActivityRecordArray  
2.189. VuDataBlockCounter  
2.190. VuDetailedSpeedBlock  
2.191. VuDetailedSpeedBlockRecordArray  
2.192. VuDetailedSpeedData  
▼M3 
2.192a. VuDigitalMapVersion  
▼B 
2.193. VuDownloadablePeriod  
2.194. VuDownloadablePeriodRecordArray  
2.195. VuDownloadActivityData  
2.196. VuDownloadActivityDataRecordArray  
2.197. VuEventData  
2.198. VuEventRecord  
2.199. VuEventRecordArray  
2.200. VuFaultData  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 119  
2.201. VuFaultRecord  
2.202. VuFaultRecordArray  
▼M1 
2.203. VuGNSSADRecord  
▼M3 
2.203a. VuBorderCrossingRecord  
2.203b. VuBorderCrossingRecordArray  
▼M1 
2.204. VuGNSSADRecordArray  
▼M3 
2.204a. VuGnssMaximalTimeDifference  
▼B 
2.205. VuIdentification  
2.206. VuIdentificationRecordArray  
2.207. VuITSConsentRecord  
2.208. VuITSConsentRecordArray  
▼M3 
2.208a. VuLoadUnloadRecord  
2.208b. VuLoadUnloadRecordArray  
▼B 
2.209. VuManufacturerAddress  
2.210. VuManufacturerName  
2.211. VuManufacturingDate  
2.212. VuOverSpeedingControlData  
2.213. VuOverSpeedingControlDataRecordArray  
2.214. VuOverSpeedingEventData  
2.215. VuOverSpeedingEventRecord  
2.216. VuOverSpeedingEventRecordArray  
2.217. VuPartNumber  
2.218. VuPlaceDailyWorkPeriodData  
2.219. VuPlaceDailyWorkPeriodRecord  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 120  
2.220. VuPlaceDailyWorkPeriodRecordArray  
2.221. VuPrivateKey  
2.222. VuPublicKey  
▼M3 
2.222a. VuRtcTime  
▼B 
2.223. VuSerialNumber  
2.224. VuSoftInstallationDate  
2.225. VuSoftwareIdentification  
2.226. VuSoftwareVersion  
2.227. VuSpecificConditionData  
2.228. VuSpecificConditionRecordArray  
2.229. VuTimeAdjustmentData  
▼M1 
2.230. Zarezerwowany dla przyszłego użytku  
2.231. Zarezerwowany dla przyszłego użytku  
▼B 
2.232. VuTimeAdjustmentRecord  
2.233. VuTimeAdjustmentRecordArray  
2.234. WorkshopCardApplicationIdentification  
▼M3 
2.234a. WorkshopCardApplicationIdentificationV2  
2.234b. WorkshopCardCalibrationAddData  
2.234c. WorkshopCardCalibrationAddDataRecord  
▼B 
2.235. WorkshopCardCalibrationData  
2.236. WorkshopCardCalibrationRecord  
2.237. WorkshopCardHolderIdentification  
2.238. WorkshopCardPIN  
2.239. W-VehicleCharacteristicConstant  
2.240. VuPowerSupplyInterruptionRecord  
2.241. VuPowerSupplyInterruptionRecordArray  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 121  
2.242. VuSensorExternalGNSSCoupledRecordArray  
2.243. VuSensorPairedRecordArray  
3. DEFINICJE WARTOŚCI I ZAKRESU WIELKOŚCI  
4. ZESTAW ZNAKÓW:  
5. KODOWANIE  
6. IDENTYFIKATORY OBIEKTU I IDENTYFIKATORY APLIKACJI  
6.1. Identyfikatory obiektu  
6.2. Identyfikatory aplikacji  
1. WPROWADZENIE  
Niniejszy dodatek określa formaty danych, elementy danych i str uktury 
danych przeznaczone do wykorzystania w urządzeniach rejestrując ych 
i kartach do tachografów.  
1.1. Podej ście do definicji typów danych  
W niniejszym dodatku do definiowania typów danych użyto zapisu 
składni abstrakcyjnej 1 (ASN.1). Pozwala to na definiowanie pro stych 
i strukturalnych danych bez narzucania żadnej swoistej składni przesy­ 
łania danych (reguł kodowania), która zależy od aplikacji i śro dowiska.  
Konwencje nazewnictwa typu ASN.1 opracowano zgodnie z normą 
ISO/IEC 8824-1. Powyższe oznacza, że:  
— tam gdzie możliwe wybrane nazwy opisują znaczenie typu,  
— tam gdzie typ danych zbudowany jest z innych typów danych naz wa 
typu danych ma postać pojedynczego ciągu znaków alfanumerycz­
nych zaczynającego się od dużej litery, natomiast duże litery 
wewnątrz nazwy opisują odpowiednie znaczenia,  
— ogólnie nazwy typów danych powiązane są z nazwami typów 
danych, z których są zbudowane, urządzeniem, w którym są zgro­
madzone i funkcją z nimi związaną.  
Jeżeli typ ASN.1 jest już zdefiniowany jako część innej normy i  jeżeli 
jest to właściwe w celu wykorzystania w urządzeniu rejestrujący m, to 
ten typ ASN.1 jest zdefiniowany w niniejszym dodatku.  
Aby umożliwić stosowanie kilku reguł kodowania, niektóre typy A SN.1 
w niniejszym dodatku są ograniczone identyfikatorami zakresu wa rtości. 
Identyfikatory zakresu wartości zostały zdefiniowane w pkt. 3 
i dodatku 2.  
1.2. Odniesienia  
W niniejszym dodatku stosuje się następujące odniesienia:  
ISO 639 Kod reprezentacji nazw języków. Wydanie pierwsze: 
1988.  
ISO 3166 Kody nazw krajów i ich jednostek administracyjnych 
– Część 1: Kody krajów, 2013.  
ISO 3779 Pojazdy drogowe – Numer identyfikacyjny pojazdu 
(VIN) – zawartość i struktura. 2009  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 122  
ISO/IEC 7816-5 Karty identyfikacyjne — Elektroniczne karty styk owe 
— część 5: Rejestracja identyfikatorów aplikacji  
Wydanie drugie: 2004.  
ISO/IEC 7816-6 Karty identyfikacyjne — Elektroniczne karty styk owe 
— część 6: Elementy danych wymieniane z otocze­
niem niezależnie od dziedziny zastosowań, 2004 + 
Poprawka techniczna 1: 2006  
ISO/IEC 8824-1 Informatyka – Zapis składni abstrakcyjnej 1 (ASN .1): 
Specyfikacja notacji podstawowej. 2008 + sprosto­
wanie techniczne 1: 2012 i sprostowanie techniczne 
2: 2014.  
ISO/IEC 8825-2 Informatyka – Reguły kodowania ASN.1: Specyfi­
kacja reguł upakowanego kodowania (PER). 2008.  
ISO/IEC 8859-1 Informatyka – 8-bitowe jednobajtowe zestawy 
znaków graficznych – część 1: Zestaw łaciński 1. 
Wydanie pierwsze: 1998.  
ISO/IEC 8859-7 Informatyka – 8-bitowe jednobajtowe zestawy 
znaków graficznych – część 7: Alfabet łaciński/ 
grecki. 2003.  
ISO 16844-3 Pojazdy drogowe – Systemy tachograficzne – inter­
fejs czujnika ruchu. 2004 + Poprawka techniczna 1: 
2006.  
TR-03110-3 Wytyczne techniczne BSI/ANSSI TR-03110-3, 
Zaawansowane mechanizmy zabezpieczeń doku­
mentów podróży odczytywanych maszynowo 
i token eIDAS – część 3 Wspólne specyfikacje, 
wersja 2.20, 3. Luty 2015 r.  
2. DEFINICJE TYPÓW DANYCH  
▼M3 
Dla każdego z następujących typów danych wartość domyślna 
„nieznane” lub zawartość „nie dotyczy” polega na wypełnieniu el ementu 
danych bajtami Hex „FF”, o ile nie określono inaczej.  
Wszystkie typy danych są wykorzystywane w aplikacjach generacji  1  
i 2, o ile nie określono inaczej. Wskazane są typy danych stoso wane 
wyłącznie w aplikacjach wersji 2 generacji 2.  
W przypadku typów danych karty używanych do aplikacji generacji  1  
i 2 wielkość określona w niniejszym dodatku to wielkość dla apl ikacji 
generacji 2. Wielkość dla aplikacji generacji 1 powinna być już  znana 
dla czytnika. Numery wymogów dotyczących takich typów danych ok re­ 
ślone w załączniku IC obejmują zarówno aplikacje generacji 1, j ak 
i aplikacje generacji 2.  
Typy danych karty niezdefiniowane dla kart generacji 1 nie są z apisy­
wane w aplikacji generacji 1 dla kart generacji 2. W szczególno ści: 
— numery homologacji typu zapisane w aplikacji generacji 1 dla kart 
generacji 2 są, w razie potrzeby, skracane do 8 pierwszych znak ów, 
— W aplikacji generacji 1 dla kart generacji 2 zapisuje się jed ynie 
„początek PRZEPRAWY PROMOWEJ/POCIĄGOWEJ” stanu 
szczególnego „PRZEPRAWA PROMOWA/POCIĄGOWA”.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 123  
2.1. ActivityChangeInfo  
Ten typ danych umożliwia kodowanie, w dwubajtowym słowie, stanu  
szczeliny czytnika o godzinie 00:00 lub statusu kierowcy o godz inie 
00:00 lub zmiany czynności, lub zmiany stanu prowadzenia pojazd u, 
lub zmiany stanu karty dla kierowcy lub współkierowcy. Ten typ danych 
związany jest z wymaganiami 105, 266, 291, 320, 321, 343 i 344 okre­ 
ślonymi w załączniku 1C.
  
Przypisanie warto ści – zapisane oktetami : „scpaattttttttttt”B (16 bitów)  
Zapisy w pamięci danych (lub stan szczeliny czytnika karty):  
„s”B Szczelina czytnika karty:  
„0”B: KIEROWCA,  
„1”B: WSPÓŁKIEROWCA,  
„c”B Stan prowadzenia pojazdu:  
„0”B: JEDEN KIEROWCA,  
„1”B: ZAŁOGA,  
„p”B Stan karty kierowcy (lub warsztatowej) w odpowied­
niej szczelinie czytnika:  
„0”B: WŁOŻONA, karta jest włożona,  
„1”B: NIEWŁOŻONA, brak karty (lub karta jest 
wyjęta),  
„aa”B Czynność:  
„00”B: PRZERWA/ODPOCZYNEK,  
„01”B: GOTOWOŚĆ,  
„10”B: PRACA,  
„11”B: PROWADZENIE,  
„ttttttttttt”B Godzina zmiany: liczba minut od godziny 00:00 
w danym dniu.  
Dla zapisów na kartach kierowcy (lub warsztatowej) (i statusu 
kierowcy):  
„s”B Szczelina czytnika karty (nieistotne, gdy „p” = 1 
z wyjątkiem jak w uwadze poniżej):  
„0”B: KIEROWCA,  
„1”B: WSPÓŁKIEROWCA,  
„c”B Stan prowadzenia pojazdu (przypadek „p” = 0); lub  
Następny stan czynności (przypadek „p” = 1):  
„0”B: JEDEN KIEROWCA,  
„0”B: NIEZNANY  
„1”B: ZAŁOGA,  
„1”B: ZNANY (=wprowadzony ręcznie)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 124  
„p”B Stan karty:  
„0”B: WŁOŻONA, karta jest włożona do urządzenia 
rejestrującego,  
„1”B: NIEWŁOŻONA, brak karty (lub karta jest 
wyjęta)  
„aa”B Czynność (nieistotne, gdy „p” = 1 i „c” = 0 z wyjąt­
kiem jak w uwadze poniżej):  
„00”B: PRZERWA/ODPOCZYNEK,  
„01”B: GOTOWOŚĆ,  
„10”B: PRACA,  
„11”B: PROWADZENIE,  
„ttttttttttt”B Godzina zmiany: liczba minut od godziny 00:00 
w danym dniu.  
Uwaga dla przypadku „wyj ęcie karty”:  
Gdy karta jest wyjęta:  
— „s” odnosi się do szczeliny czytnika i wskazuje szczelinę czy tnika, 
z której wyjęta jest karta,  
— „c” musi być ustawiony na 0,  
— „p” musi być ustawiony na 1,  
— „aa” musi kodować bieżącą czynność wybraną w tym czasie.  
W wyniku ręcznego wprowadzenia danych bity „c” i „aa” słowa (za pi­
sanego na karcie) mogą być nadpisane później w celu odzwiercied lania 
zapisu.  
2.2. Address  
Adres.
  
codePage  określa zestaw znaków zdefiniowany w rozdziale 4,  
address  jest adresem zakodowanym przy użyciu wyszczególnionego 
zestawu znaków.  
2.3. AESKey  
Generacja 2:  
Klucz AES o długości 128, 192 lub 256 bitów.
  
Przypisanie warto ści: nie określa się.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 125  
2.4. AES128Key  
Generacja 2:  
Klucz AES 128.
  
length  oznacza długość klucza AES 128 w oktetach.  
aes128Key  oznacza klucz AES o długości 128 bitów.  
Przypisanie warto ści: 
długość ma wartość 16.  
2.5. AES192Key  
Generacja 2:  
Klucz AES 192.
  
length  oznacza długość klucza AES 192 w oktetach.  
aes192Key  oznacza klucz AES o długości 192 bitów.  
Przypisanie warto ści: 
długość ma wartość 24.  
2.6. AES256Key  
Generacja 2:  
Klucz AES 256.
  
długość oznacza długość klucza AES 256 w oktetach.  
aes256Key  oznacza klucz AES o długości 256 bitów.  
Przypisanie warto ści: 
długość ma wartość 32.  
2.7. BCDString  
BCDString jest stosowany do reprezentacji liczb w zapisie dzies iętnym 
kodowanym dwójkowo (BCD). Tego typu danych używa się do przed­
stawiania jednej cyfry dziesiętnej w półoktecie (4 bity). BCDSt ring 
oparty jest na definicji z normy ISO/IEC 8824-1 „CharacterStrin gType”.
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 126  
BCDString używa notacji „hstring”. Skrajna lewa cyfra heksadecy malna 
jest najbardziej znaczącym półoktetem pierwszego oktetu. Aby ut worzyć 
wielokrotne oktety, wstawia się, gdy trzeba, zerowe półoktety o  lewej 
skrajnej pozycji półoktetu w pierwszym oktecie.  
Dozwolonymi cyframi są: 0, 1, .. 9.  
2.8. CalibrationPurpose  
Kod wyjaśniający, dlaczego zarejestrowano zbiór parametrów kali bracyj­
nych. Ten typ danych związany jest z wymaganiami 097 i 098 okre ­ 
ślonymi w załączniku 1B i wymaganiem 119 określonym w załącznik u 
1C.
 
Przypisanie warto ści: 
Generacja 1:  
„00”H wartość zastrzeżona,  
„01”H aktywacja: zapis parametrów kalibracyjnych 
znanych w momencie aktywacji VU,  
„02”H pierwsza instalacja: pierwsza kalibracja VU po 
aktywacji,  
„03”H instalacja: pierwsza kalibracja VU w bieżącym 
pojeździe,  
„04”H przegląd okresowy.  
Generacja 2:  
Oprócz generacji 1 używane są następujące wartości:  
„05”H wprowadzenie VRN przez firmę,  
„06”H korekta czasu bez kalibracji,  
„07”H to „7F”H RFU,  
„80”H – „FF”H swoisty dla producenta.  
2.9. CardActivityDailyRecord  
Informacje, zapisane na karcie, dotyczące czynności kierowcy w danym 
dniu kalendarzowym. Ten typ danych związany jest z wymaganiami 
266, 291, 320 i 343 określonymi w załączniku 1C.
  
activityPreviousRecordLength  jest całkowitą długością w bajtach 
poprzedniego rekordu dziennego. Maksymalną wartość określa dług ość 
OCTET STRING zawierającego te rekordy (zob. pkt 4 CardActivityL en­
gthRange w dodatku 2). Gdy rekord ten jest najstarszym rekordem  
dziennym, wartość activityPreviousRecordLength musi być ustawio na 
na 0.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 127  
activityRecordLength  jest całkowitą długością tego rekordu w bajtach. 
Maksymalną wartość określa długość OCTET STRING zawierającego t e 
rekordy.  
activityRecordDate  jest datą rekordu.  
activityDailyPresenceCounter  jest licznikiem obecności dla karty 
w tym dniu.  
activityDayDistance  jest całkowitą drogą przebytą w tym dniu.  
activityChangeInfo  jest zbiorem danych ActivityChangeInfo dla 
kierowcy w tym dniu. Może zawierać maksymalnie 1440 wartości (j edna 
zmiana czynności na minutę). W tym zbiorze danych zawsze znajdu je 
się activityChangeInfo określający status kierowcy o godzinie 0 0:00.  
2.10.  CardActivityLengthRange  
Liczba bajtów na karcie kierowcy lub na karcie warsztatowej, do stęp­
nych do przechowywania rekordów z czynnościami kierowcy.
  
Przypisanie warto ści: zob. dodatek 2.  
2.11.  CardApprovalNumber  
Numer homologacji typu karty.
  
Przypisanie warto ści: 
Należy podawać numer homologacji, który został opublikowany na 
odpowiedniej stronie internetowej Komisji Europejskiej, tj. na przykład 
z uwzględnieniem myślników, jeżeli występują. Numer homologacji  
musi być wyrównany do lewej strony.  
▼M3 
2.11a.  CardBorderCrossings  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotyczące przekroczeń granicy przez pojazd, jeżeli prze kroczył 
on granicę krajową (wymogi 306f i 356f określone w załączniku I C).
 
borderCrossingPointerNewestRecord  jest indeksem ostatniego uaktual­
nionego rekordu przekroczenia granicy.  
Przypisanie warto ści: liczba odpowiadająca stanowi licznika rekordu 
dotyczącego przekroczenia granicy, rozpoczynając od „0” dla pie rw­
szego wystąpienia w strukturze rekordu dotyczącego przekroczeni a 
granicy.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 128  
cardBorderCrossingRecords  jest zbiorem rekordów przekroczenia 
granicy.  
2.11b.  CardBorderCrossingRecord  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotyczące przekroczeń granicy przez pojazd, jeżeli prze kroczył 
on granicę krajową (wymogi 147b, 306e i 356e określone w załącz niku 
IC).
 
countryLeft  to kraj, który pojazd opuścił, lub „brak dostępnych infor­
macji” zgodnie z wymogiem 147b określonym w załączniku IC. „Res zta 
świata” (kod 'FF’H NationNumeric) stosuje się, gdy przyrząd rej estru­
jący nie jest w stanie określić kraju, w którym pojazd się znaj duje (np. 
bieżący kraj nie jest objęty zapisanymi mapami cyfrowymi).  
countryEntered  to kraj, do którego pojazd wjechał, lub kraj, w którym 
pojazd się znajduje w momencie włożenia karty. „Reszta świata” (kod 
'FF’H NationNumeric) stosuje się, gdy przyrząd rejestrujący nie  jest 
w stanie określić kraju, w którym pojazd się znajduje (np. bież ący 
kraj nie jest objęty zapisanymi mapami cyfrowymi).  
gnssPlaceAuthRecord  zawiera informacje dotyczące pozycji pojazdu, 
gdy przyrząd rejestrujący wykrył, że pojazd przekroczył granicę  krajową, 
lub „brak dostępnych informacji” zgodnie z wymogiem 147b w załą cz­
niku IC, a także jej statusu uwierzytelnienia.  
vehicleOdometerValue  to stan licznika kilometrów, gdy przyrząd rejes­
trujący wykrył, że pojazd przekroczył granicę krajową, lub „bra k dostęp­
nych informacji” zgodnie z wymogiem 147b w załączniku IC.  
▼B 
2.12.  CardCertificate  
Generacja 1:  
Certyfikat klucza publicznego karty.
  
2.13.  CardChipIdentification  
Informacje, zapisane na karcie, dotyczące identyfikacji układu scalonego 
karty (IC) (wymaganie 249 określone w załączniku 1C). IcSerialN umber 
wraz z icManufacturingReferences identyfikują w sposób niepowta rzalny 
chip karty. Sam IcSerialNumber nie identyfikuje chipu karty w s posób 
niepowtarzalny.
  
icSerialNumber  jest numerem seryjnym IC.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 129  
icManufacturingReferences  jest identyfikatorem swoistym producenta 
IC. 
2.14.  CardConsecutiveIndex  
Numer kolejny karty (definicja h)).
  
Przypisanie warto ści: (zob. rozdział 7 załącznika 1C)  
Kolejność zwiększania: „0, …, 9, A, …, Z, a, …, z”  
2.15.  CardControlActivityDataRecord  
Informacje przechowywane na karcie kierowcy lub warsztatowej do ty­
czące ostatniej kontroli, której poddany był kierowca (wymagani a 274, 
299, 327 i 350 określone w załączniku 1C).
  
controlType  jest typem kontroli.  
controlTime  jest datą i godziną kontroli.  
controlCardNumber  jest numerem karty FullCardNumber funkcjona­
riusza służb kontrolnych przeprowadzającego kontrolę.  
controlVehicleRegistration  jest numerem VRN i państwa członkow­
skiego rejestracji pojazdu, w którym miała miejsce kontrola.  
controlDownloadPeriodBegin  i controlDownloadPeriodEnd  jest 
okresem, dla którego pobrano dane, w przypadku pobierania danyc h. 
2.16.  CardCurrentUse  
Informacje o rzeczywistym użyciu karty (wymagania 273, 298, 326  
i 349 określone w załączniku 1C).
  
sessionOpenTime  jest godziną, o której kartę włożono dla bieżącego 
użycia. Przy wyjęciu karty element ten jest zerowany.  
sessionOpenVehicle  jest identyfikacją aktualnie używanego pojazdu 
ustawianą przy wkładaniu karty. Przy wyjęciu karty element ten jest 
zerowany.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 130  
2.17.  CardDriverActivity  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotyczące czynności kierowcy (wymagania 267, 268, 292, 
293, 321 i 344 określone w załączniku 1C).
  
activityPointerOldestDayRecord  jest wskaźnikiem początku miejsca 
gromadzenia danych (liczba bajtów od początku łańcucha znaków) 
najstarszego, pełnego rekordu dziennego w łańcuchu activityDail yRe­
cords. Maksymalna wartość jest określona długością łańcucha.  
activityPointerNewestRecord  jest wskaźnikiem początku miejsca 
gromadzenia danych (liczba bajtów od początku łańcucha znaków) 
najświeższego rekordu dziennego w łańcuchu activityDailyRecords . 
Maksymalna wartość jest określona długością łańcucha.  
activityDailyRecords  jest przestrzenią dostępną do przechowywania 
danych dotyczących czynności kierowcy (struktura danych: CardAc tivi­
tyDailyRecord) dla każdego dnia kalendarzowego, w którym karta jest 
użyta.  
Przypisanie warto ści: ten OCTET STRING jest cyklicznie wypełniany 
rekordami CardActivityDailyRecord. Przy pierwszym użyciu groma­
dzenie rozpoczyna się od pierwszego bajtu łańcucha. Wszystkie n owe 
rekordy dołącza się do końca poprzedniego rekordu. Gdy łańcuch zostaje 
zapełniony wypełnianie rozpoczyna się od pierwszego bajtu łańcu cha 
niezależnie od przerwy w elemencie danych. Przed wstawieniem do  
łańcucha danych o nowej czynności (zwiększenie bieżącego rekord u 
activityDailyRecord lub wstawienie nowego rekordu activityDaily Re­
cord), który zamienia stare dane o starej czynności, wskaźnik a ctivity­
PointerOldestDayRecord musi być uaktualniony w celu odzwiercied lenia 
nowego położenia najstarszego, pełnego rekordu dziennego a dług ość 
activityPreviousRecordLength tego (nowego) najstarszego, pełneg o 
rekordu dziennego musi być wyzerowana.  
2.18.  CardDrivingLicenceInformation  
Informacje przechowywane na karcie kierowcy dotyczące prawa jaz dy 
posiadacza karty (wymagania 259 i 284 określone w załączniku 1C ).
 
drivingLicenceIssuingAuthority  jest organem, który wydał prawo 
jazdy.  
drivingLicenceIssuingNation  jest przynależnością państwową organu, 
który wydał prawo jazdy.  
drivingLicenceNumber  jest numerem prawa jazdy.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 131  
2.19.  CardEventData  
Generacja 1:  
Informacje przechowywane na karcie kierowcy lub warsztatowej do ty­
czące zdarzeń związanych z posiadaczem karty (wymagania 260 i 3 18 
określone w załączniku IC).
  
CardEventData  jest sekwencją uporządkowaną w kolejności rosnącej 
typu EventFaultType, w zapisach cardEventRecords (z wyjątkiem 
rekordów związanych z próbami naruszenia zabezpieczeń, które gr oma­
dzone są w ostatnim zbiorze sekwencji).  
cardEventRecords  jest zbiorem rekordów ze zdarzeniami dla danego 
typu zdarzenia (lub kategorii prób naruszeń zabezpieczenia).  
Generacja 2:  
Informacje przechowywane na karcie kierowcy lub warsztatowej do ty­
czące zdarzeń związanych z posiadaczem karty (wymagania 285 i 3 41 
określone w załączniku IC).
  
CardEventData  jest sekwencją uporządkowaną w kolejności rosnącej 
typu EventFaultType, w zapisach cardEventRecords (z wyjątkiem 
rekordów związanych z próbami naruszenia zabezpieczeń, które gr oma­
dzone są w ostatnim zbiorze sekwencji).  
cardEventRecords  jest zbiorem rekordów ze zdarzeniami dla danego 
typu zdarzenia (lub kategorii prób naruszeń zabezpieczenia).  
▼B 
2.20.  CardEventRecord  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotyczące zdarzenia związanego z posiadaczem karty (wym a­
gania 261, 286, 318 i 341 określone w załączniku 1C).
  
eventType  jest typem zdarzenia.  
eventBeginTime  jest datą i godziną rozpoczęcia zdarzenia.  
eventEndTime  jest datą i godziną zakończenia zdarzenia.  
eventVehicleRegistration  jest numerem VRN i państwa członkow­
skiego rejestracji pojazdu, w którym zdarzenie miało miejsce.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 132  
2.21.  CardFaultData  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotyczące usterek związanych z posiadaczem karty (wymag ania 
263, 288, 318 i 341 określone w załączniku 1C).
  
CardFaultData  jest sekwencją zbioru rekordów dotyczących usterek 
urządzenia rejestrującego poprzedzającego zbiór rekordów dotycz ących 
usterek kart.  
cardFaultRecords  jest zbiorem rekordów dotyczących usterek danej 
kategorii (urządzenia rejestrującego lub karty).  
2.22.  CardFaultRecord  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotyczące usterki związanej z posiadaczem karty (wymaga nia 
264, 289, 318 i 341 określone w załączniku 1C).
  
faultType  jest typem usterki.  
faultBeginTime  jest datą i godziną początku usterki.  
faultEndTime  jest datą i godziną zakończenia usterki.  
faultVehicleRegistration  jest numerem VRN i państwa członkowskiego 
rejestracji pojazdu, w którym usterka się zdarzyła.  
2.23.  CardIccIdentification  
Informacje zapisane na karcie dotyczące identyfikacji karty z u kładem 
scalonym (IC) (wymaganie 248 określone w załączniku 1C).
  
clockStop  jest trybem Clockstop zdefiniowanym w dodatku 2.  
cardExtendedSerialNumber  jest niepowtarzalnym numerem seryjnym 
karty IC, dodatkowo określonym za pomocą typu danych ExtendedSe ­
rialNumber.  
cardApprovalNumber  jest numerem homologacji typu karty.  
cardPersonaliserID  jest identyfikatorem jednostki personalizującej kartę 
zakodowanym jako ManufacturerCode.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 133  
embedderIcAssemblerId  zapewnia informacje o wbudowującym/montu­
jącym układ scalony.  
icIdentifier  jest identyfikatorem układu scalonego na karcie i producenta 
układu scalonego zdefiniowanym w normie ISO/IEC 7816-6.  
2.24.  CardIdentification  
Informacje zapisane na karcie dotyczące identyfikacji karty (wy magania 
255, 280, 310, 333, 359, 365, 371 i 377 określone w załączniku 1C).
 
cardIssuingMemberState  jest kodem państwa członkowskiego wydają­
cego kartę.  
cardNumber  jest numerem karty.  
cardIssuingAuthorityName  jest nazwą organu wydającego kartę.  
cardIssueDate  jest datą wydania karty aktualnemu posiadaczowi.  
cardValidityBegin  jest pierwszą datą ważności karty.  
cardExpiryDate  jest terminem ważności karty.  
▼M3 
2.24a.  CardLoadTypeEntries  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie kierowcy lub warsztatowej do ty­
czące wpisów typu załadunku, gdy karta jest włożona do przyrząd u 
rejestrującego (wymogi 306j i 356j określone w załączniku IC).
  
loadTypeEntryPointerNewestRecord  to indeks ostatniego uaktualnio­
nego rekordu karty dotyczącego wpisu typu załadunku.  
Przypisanie warto ści: liczba odpowiadająca stanowi licznika rekordu 
karty dotyczącego wpisu typu załadunku, rozpoczynając od „0” dl a 
pierwszego wystąpienia w strukturze rekordu karty dotyczącego w pisu 
typu załadunku.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 134  
cardLoadTypeEntryRecords  to zbiór rekordów zawierających datę 
i godzinę wpisu oraz wpisany typ załadunku.  
2.24b.  CardLoadTypeEntryRecord  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie kierowcy lub warsztatowej do ty­
czące wprowadzonych zmian typu załadunku, gdy karta jest włożon a do 
przyrządu rejestrującego (wymogi 306i i 356i określone w załącz niku 
IC).
 
timeStamp  to data i godzina wpisania typu załadunku.  
loadTypeEntered  to wpisany typ załadunku.  
2.24c.  CardLoadUnloadOperations  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie kierowcy lub warsztatowej do ty­
czące operacji załadunku/rozładunku pojazdu (wymogi 306h i 356h  
określone w załączniku IC).
  
loadUnloadPointerNewestRecord  to indeks ostatniego uaktualnionego 
rekordu karty dotyczącego załadunku/rozładunku.  
Przypisanie warto ści: liczba odpowiadająca stanowi licznika rekordu 
karty dotyczącego załadunku/rozładunku, rozpoczynając od „0” dl a 
pierwszego wystąpienia w strukturze rekordu karty dotyczącego z ała­
dunku/rozładunku.  
cardLoadUnloadRecords  to zbiór rekordów zawierających wskazanie 
typu wykonywanej operacji (załadunek, rozładunek lub równoczesn y 
załadunek/rozładunek), datę i godzinę wprowadzenia operacji zał adunku/ 
rozładunku, informacje o pozycji pojazdu oraz stan licznika kil ometrów.  
2.24d.  CardLoadUnloadRecord  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie kierowcy lub warsztatowej do ty­
czące operacji załadunku/rozładunku pojazdu (wymogi 306g i 356g  
określone w załączniku IC).
  
timeStamp  to data i godzina rozpoczęcia operacji załadunku/rozładunku.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 135  
operationType  to wpisany typ operacji (załadunek, rozładunek lub 
równoczesny załadunek/rozładunek).  
gnssPlaceAuthRecord  zawiera informacje dotyczące pozycji pojazdu.  
vehicleOdometerValue  to stan licznika kilometrów w związku z rozpo­
częciem operacji załadunku/rozładunku.  
▼B 
2.25.  CardMACertificate  
Generacja 2:  
Certyfikat klucza publicznego karty na potrzeby wzajemnego uwie rzy­
telniania z VU. Strukturę tego certyfikatu określono w dodatku 11.
 
2.26.  CardNumber  
Numer karty zgodny z definicją g).
  
driverIdentification  jest jednoznaczną identyfikacją kierowcy 
w państwie członkowskim.  
ownerIdentification  jest jednoznaczną identyfikacją firmy lub warsztatu 
lub organu kontrolnego w państwie członkowskim.  
cardConsecutiveIndex  jest numerem kolejnym karty.  
cardReplacementIndex  jest numerem wymiany karty.  
cardRenewalIndex  jest numerem odnowienia karty.  
Pierwsza wybierana sekwencja umożliwia kodowanie karty kierowcy , 
a druga wybierana sekwencja umożliwia kodowanie numeru karty wa rsz­
tatowej, karty kontrolnej i karty firmowej.  
▼M3 
2.26a.  CardPlaceAuthDailyWorkPeriod  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej, przedstawiające status uwierzytelnienia miejsc rozpocz ęcia lub 
zakończenia dziennych okresów pracy (wymogi 306b i 356b określo ne 
w załączniku IC).  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 136
  
placeAuthPointerNewestRecord  to indeks ostatniego uaktualnionego 
rekordu dotyczącego statusu uwierzytelnienia miejsca.  
Przypisanie warto ści: liczba odpowiadająca stanowi licznika rekordów 
dotyczących statusu uwierzytelnienia miejsca, rozpoczynając od „0” dla 
pierwszego wystąpienia w strukturze rekordów dotyczących status u 
uwierzytelnienia miejsca.  
placeAuthStatusRecords  to zbiór rekordów zawierających status uwie­
rzytelnienia miejsca dla wprowadzanych miejsc.  
▼B 
2.27.  CardPlaceDailyWorkPeriod  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotyczące miejsc rozpoczęcia lub zakończenia dziennych 
okresów pracy (wymagania 272, 297, 325 i 348 określone w załącz niku 
1C).
 
placePointerNewestRecord  jest indeksem ostatniego, uaktualnionego 
rekordu miejsca.  
Przypisanie warto ści: liczba odpowiadająca stanowi licznika rekordów 
miejsca, zaczynająca się od „0” dla pierwszego wystąpienia reko rdów 
miejsca w strukturze.  
placeRecords  jest zbiorem rekordów dotyczących wprowadzonych 
miejsc.  
2.28.  CardPrivateKey  
Generacja 1:  
Klucz prywatny karty.
  
2.29.  CardPublicKey  
Klucz publiczny karty.
  
▼M1 
2.30.  CardRenewalIndex  
Numer odnowienia karty (definicja i)).
  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 137  
Przypisanie warto ści: (zob. rozdział 7 niniejszego załącznika).  
„0” Wydanie pierwsze.  
Kolejność zwiększania:„0, …, 9, A, …, Z”  
▼B 
2.31.  CardReplacementIndex  
Numer wymiany karty (definicja j)).
  
Przypisanie warto ści: (zob. rozdział VII niniejszego załącznika).  
„0” Oryginał karty.  
Kolejność zwiększania: „0, …, 9, A, …, Z”  
2.32.  CardSignCertificate  
Generacja 2:  
Certyfikat klucza publicznego karty do podpisu. Strukturę tego certyfi­
katu określono w dodatku 11.
  
2.33.  CardSlotNumber  
Kod rozróżnienia między dwiema szczelinami kart w przyrządzie r ejes­
trującym.
  
Przypisanie warto ści: nie określa się.  
2.34.  CardSlotsStatus  
Kod wskazujący typ kart włożonych do dwóch szczelin czytników k arty 
przyrządu rejestrującego.
  
Przypisanie warto ści – zapisane oktetami : „ccccdddd”B  
„cccc”B identyfikacja typu karty włożonej do szczeliny karty 
współkierowcy,  
„dddd”B identyfikacja typu karty włożonej do szczeliny karty 
kierowcy,  
z następującymi kodami identyfikującymi:  
„0000”B brak karty,  
„0001”B karta kierowcy jest włożona,  
„0010”B karta warsztatowa jest włożona,  
„0011”B karta kontrolna jest włożona,  
„0100”B karta firmowa jest włożona.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 138  
2.35.  CardSlotsStatusRecordArray  
Generacja 2:  
CardSlotsStatus wraz z metadanymi stosowany w protokole pobiera nia 
danych.
  
recordType  oznacza typ rekordu (CardSlotsStatus).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość CardSlotsStatus w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów CardSlotsStatus.  
2.36.  CardStructureVersion  
Kod wskazujący wersję struktury na karcie do tachografu.
  
Przypsianie warto ści: „aabb”H:  
„aa”H indeks zmian struktury,  
„00”H dla aplikacji generacji 1  
„01”H dla aplikacji generacji 2  
▼M3 
„bb”H indeks zmian dotyczących użycia elementów danych 
zdefiniowanych dla struktury określony wyższym 
bajtem.  
„00”H dla aplikacji generacji 1  
„00”H dla aplikacji wersji 1 generacji 2  
„01”H dla aplikacji wersji 2 generacji 2  
▼B 
2.37.  CardVehicleRecord  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotyczące okresu używania pojazdu w czasie dnia kalenda rzo­
wego (wymagania 269, 294, 322 i 345 określone w załączniku 1C).  
Generacja 1:
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 139  
vehicleOdometerBegin  jest stanem licznika kilometrów na początku 
okresu używania pojazdu.  
vehicleOdometerEnd  jest stanem licznika kilometrów na końcu okresu 
używania pojazdu.  
vehicleFirstUse  jest datą i godziną rozpoczęcia okresu używania 
pojazdu.  
vehicleLastUse  jest datą i godziną zakończenia okresu używania 
pojazdu.  
vehicleRegistration  wskazuje numer VRN i państwo członkowskie 
rejestracji pojazdu.  
vuDataBlockCounter  jest wartością licznika VuDataBlockCounter 
ostatniego wyciągu okresu użycia pojazdu.  
Generacja 2:
  
Oprócz generacji 1 używany jest następujący element danych:  
VehicleIdentificationNumber  jest numerem identyfikacyjnym pojazdu 
odnoszącym się do pojazdu jako całości.  
2.38.  CardVehiclesUsed  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotyczące używanych pojazdów (wymagania 270, 295, 323 
i 346 określone w załączniku 1C).
  
vehiclePointerNewestRecord  jest indeksem ostatniego, uaktualnionego 
rekordu dotyczącego pojazdu.  
Przypisanie warto ści: liczba odpowiadająca stanowi licznika rekordów 
dotyczących pojazdu, rozpoczynając od „0” dla pierwszego wystąp ienia 
w strukturze rekordów dotyczących pojazdu.  
cardVehicleRecords  jest zbiorem rekordów zawierających informacje 
o używanych pojazdach.  
2.39.  CardVehicleUnitRecord  
Generacja 2:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 140  
informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotyczące używanego przyrządu rejestrującego (wymagania  
303 i 351 określone w załączniku 1C).
  
timeStamp  jest początkiem okresu używania przyrządu rejestrującego 
(tj. pierwszym włożeniem karty do przyrządu rejestrującego dla tego 
okresu).  
manufacturerCode  identyfikuje producenta przyrządu rejestrującego.  
deviceID  identyfikuje typ przyrządu rejestrującego producenta. Wartość 
jest swoista dla producenta.  
vuSoftwareVersion  jest numerem wersji oprogramowania przyrządu 
rejestrującego.  
2.40.  CardVehicleUnitsUsed  
▼M3 
Generacja 2:  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotyczące przyrządów rejestrujących używanych przez pos ia­
dacza karty (wymogi 304 i 352 określone w załączniku IC).  
▼B
 
vehiclePointerNewestRecord  jest indeksem ostatniego, uaktualnionego 
rekordu dotyczącego przyrządu rejestrującego.  
Przypisanie warto ści: liczba odpowiadająca stanowi licznika rekordów 
przyrządu rejestrującego, rozpoczynając od „0” dla pierwszego w ystą­
pienia w strukturze rekordów dotyczących przyrządu rejestrujące go. 
cardVehicleUnitRecords  jest zbiorem rekordów zawierających infor­
macje o używanych przyrządach rejestrujących.  
2.41.  Certyfikat  
Certyfikat klucza publicznego wydany przez organ certyfikacji.  
Generacja 1:
  
Przypisanie warto ści: podpis cyfrowy z częściowym odzyskiwaniem 
zawartości CertificateContent, zgodnie z dodatkiem 11 „Wspólne 
mechanizmy bezpieczeństwa”: Podpis (128 bajtów) || Reszta klucz a 
publicznego (58 bajtów) || Odnośnik do organu certyfikacji: (8 bajtów)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 141  
Generacja 2:
  
Przypisanie wartości: zob. dodatek 11  
2.42.  CertificateContent  
Generacja 1:  
Treść certyfikatu klucza publicznego zgodnie z dodatkiem 11 – W spólne 
mechanizmy bezpieczeństwa.
  
certificateProfileIdentifier  jest wersją odpowiedniego certyfikatu.  
Przypisanie warto ści: „01h” dla tej wersji.  
certificationAuthorityReference  identyfikuje organ certyfikacji wyda­
jący certyfikat. Jest tu także odesłanie do klucza publicznego tego 
organu certyfikacji.  
certificateHolderAuthorisation  identyfikuje prawa posiadacza certyfikatu.  
certificateEndOfValidity  jest datą administracyjnego wygaśnięcia 
certyfikatu.  
certificateHolderReference  identyfikuje posiadacza certyfikatu. Jest tu 
także odesłanie do jego klucza publicznego.  
publicKey  jest kluczem publicznym, który jest poświadczony tym 
certyfikatem.  
2.43.  CertificateHolderAuthorisation  
Identyfikacja praw posiadacza certyfikatu.
  
Generacja 1:  
tachographApplicationID  jest identyfikatorem aplikacji dla aplikacji 
tachograficznej.  
Przypisanie warto ści: „FFh” „54h” „41h” „43h” „48h” „4Fh”. Ten 
AID jest zastrzeżonym, nierejestrowanym identyfikatorem aplikac ji 
zgodnie z normą ISO/IEC 7816-5.  
equipmentType  jest identyfikacją typu urządzenia, dla którego przezna­
czony jest certyfikat.  
Przypisanie warto ści: zgodnie z typem danych EquipmentType.  0 gdy 
jest to certyfikat jednego z państw członkowskich.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 142  
Generacja 2:  
tachographApplicationID  oznacza 6 najbardziej znaczących bajtów 
odpowiedniego identyfikatora aplikacji (AID) karty do tachograf u gene­
racji 2. AID dla aplikacji karty do tachografu określono w rozd ziale 6.2.  
Przypisanie warto ści: „FF 53 4D 52 44 54”.  
equipmentType  jest identyfikacją typu urządzenia określonego dla 
generacji 2, dla którego przeznaczony jest certyfikat.  
Przypisanie warto ści: zgodnie z typem danych EquipmentType.  
2.44.  CertificateRequestID  
Jednoznaczna identyfikacja wniosku o certyfikat. Może być także  
używana jako identyfikator klucza publicznego przyrządu rejestr ującego, 
jeżeli numer seryjny przyrządu rejestrującego, do którego ten k lucz jest 
przeznaczony, nie jest znany w czasie sporządzania certyfikatu.
  
requestSerialNumber  jest numerem seryjnym wniosku o certyfikat, 
unikatowym dla producenta i miesiąca określonego poniżej.  
requestMonthYear  jest identyfikacją miesiąca i roku wniosku o certy­
fikat.  
Przypisanie warto ści: miesiąc (dwie cyfry) i rok (dwie ostatnie cyfry) 
w kodzie BCD.  
crIdentifier : jest identyfikatorem umożliwiającym rozróżnienie wniosku 
o certyfikat od rozszerzonego numeru seryjnego.  
Przypisanie warto ści: „FFh”.  
manufacturerCode : jest kodem numerycznym producenta wnioskują­
cego o certyfikat.  
2.45.  CertificationAuthorityKID  
Identyfikator klucza publicznego organu certyfikacji (organu ce rtyfikacji 
państwa członkowskiego lub europejskiego organu certyfikacji).
  
nationNumeric  jest numerycznym kodem krajowym organu certyfikacji.  
nationAlpha  jest alfanumerycznym kodem krajowym organu 
certyfikacji.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 143  
keySerialNumber  jest numerem seryjnym umożliwiającym rozróżnienie 
różnych kluczy organu certyfikacji w przypadku zmiany kluczy.  
additionalInfo  jest dwubajtowym polem przeznaczonym na dodatkowy 
kod (swoisty dla organu certyfikacji).  
caIdentifier  jest identyfikatorem umożliwiającym rozróżnienie identyfi­
katora klucza organu certyfikacji od innych identyfikatorów klu czy. 
Przypisanie warto ści: „01h”.  
2.46.  CompanyActivityData  
Informacje przechowywane na karcie firmowej dotyczące czynności  
wykonanych przy użyciu karty (wymagania 373 i 379 określone 
w załączniku 1C).
  
companyPointerNewestRecord  jest indeksem ostatniego, uaktualnio­
nego zapisu companyActivityRecord.  
Przypisanie warto ści: liczba odpowiadająca stanowi licznika rekordów 
czynności firmy, rozpoczynając od „0” dla pierwszego wystąpieni a 
rekordu czynności firmy w strukturze.  
companyActivityRecords  są zbiorem wszystkich rekordów czynności 
firmy.  
companyActivityRecord  jest sekwencją informacji dotyczących jednej 
czynności firmy.  
companyActivityType  jest typem czynności firmy.  
companyActivityTime  jest datą i godziną czynności firmy.  
cardNumberInformation  jest numerem karty i państwa członkow­
skiego wydającego kartę, z której pobrano dane, gdy dotyczy.  
vehicleRegistrationInformation  jest numerem VRN i państwem człon­
kowskim rejestracji pojazdu, dla którego pobrano dane lub zablo kowano, 
lub zdjęto blokadę.  
downloadPeriodBegin  i downloadPeriodEnd  jest okresem, dla którego 
pobrano dane z VU, gdy dotyczy.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 144  
2.47.  CompanyActivityType  
Kod wskazujący czynność wykonaną przez firmę z wykorzystaniem j ej 
karty firmowej.
  
2.48.  CompanyCardApplicationIdentification  
Informacje przechowywane na karcie firmowej dotyczące identyfik acji 
aplikacji na karcie (wymagania 369 i 375 określone w załączniku  1C).
  
typeOfTachographCardId  określa wdrożony typ karty.  
cardStructureVersion  określa wersję struktury wdrożonej na karcie.  
noOfCompanyActivityRecords  jest liczbą rekordów z czynnościami 
firmy, które można przechowywać na karcie.  
▼M3 
2.48a.  CompanyCardApplicationIdentificationV2  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie firmowej dotyczące identyfik acji 
aplikacji na karcie (wymóg 375a określony w załączniku IC).
  
lengthOfFollowingData  to liczba kolejnych bajtów we wpisie.  
vuConfigurationLengthRange  to liczba bajtów na karcie do tacho­
grafu, dostępnych na potrzeby przechowywania konfiguracji VU.  
▼B 
2.49.  CompanyCardHolderIdentification  
Informacje przechowywane na karcie firmowej dotyczące identyfik acji 
posiadacza karty (wymagania 372 i 378 określone w załączniku 1C ).
 
companyName  jest nazwą firmy posiadającej kartę.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 145  
companyAddress  jest adresem firmy posiadającej kartę.  
cardHolderPreferredLanguage  jest preferowanym językiem posia­
dacza karty.  
2.50.  ControlCardApplicationIdentification  
Informacje przechowywane na karcie kontrolnej dotyczące identyf ikacji 
aplikacji na karcie (wymagania 357 i 363 określone w załączniku  1C).
  
typeOfTachographCardId  określa wdrożony typ karty.  
cardStructureVersion  określa wersję struktury wdrożoną na karcie.  
noOfControlActivityRecords  jest liczbą rekordów czynności kontro­
lnych, które mogą być zapisane na karcie.  
▼M3 
2.50a.  ControlCardApplicationIdentificationV2  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie kontrolnej dotyczące identyf ikacji 
aplikacji karty (wymóg 363a określony w załączniku IC).
  
lengthOfFollowingData  to liczba kolejnych bajtów we wpisie.  
vuConfigurationLengthRange  to liczba bajtów na karcie do tacho­
grafu, dostępnych na potrzeby przechowywania konfiguracji VU.  
▼B 
2.51.  ControlCardControlActivityData  
Informacje przechowywane na karcie kontrolnej dotyczące czynnoś ci 
wykonanych przy użyciu karty (wymagania 361 i 367 określone 
w załączniku 1C).
  
controlPointerNewestRecord  jest indeksem ostatniego, uaktualnionego 
rekordu czynności kontrolnych.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 146  
Przypisanie warto ści: liczba odpowiadająca stanowi licznika rekordów 
czynności kontrolnych, rozpoczynając od „0” dla pierwszego wyst ą­
pienia w strukturze rekordu czynności kontroli.  
controlActivityRecords  jest zbiorem wszystkich rekordów czynności 
kontrolnych.  
controlActivityRecord  jest ciągiem informacji dotyczących jednej 
kontroli.  
controlType  jest typem kontroli.  
controlTime  jest datą i godziną kontroli.  
controlledCardNumber  jest numerem karty i państwa członkowskiego 
wydającego kartę, która jest kontrolowana.  
controlledVehicleRegistration  jest numerem VRN i państwa członkow­
skiego rejestracji pojazdu, w którym miała miejsce kontrola.  
controlDownloadPeriodBegin  i controlDownloadPeriodEnd  wyzna­
czają ostatecznie pobierany okres.  
2.52.  ControlCardHolderIdentification  
Informacje przechowywane na karcie kontrolnej dotyczące identyf ikacji 
posiadacza karty (wymagania 360 i 366 określone w załączniku 1C ).
 
controlBodyName  jest nazwą organu kontrolnego posiadacza karty.  
controlBodyAddress  jest adresem organu kontrolnego posiadacza karty.  
cardHolderName  jest nazwą i imieniem (imionami) posiadacza karty 
kontrolnej.  
cardHolderPreferredLanguage  jest preferowanym językiem posia­
dacza karty.  
2.53.  ControlType  
Kod wskazujący czynności wykonane podczas kontroli. Ten typ dan ych 
związany jest z wymaganiami 126, 274, 299, 327 i 350 określonym i 
w załączniku 1C.
  
Generacja 1:  
Przypisanie warto ści – zapisane oktetami : „cvpdxxxx”B (8 bitów)  
„c”B pobieranie danych z karty:  
„0”B: nie pobrano danych z karty w czasie tej kontroli,  
„1”B: pobrano dane z karty w czasie tej kontroli  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 147  
„v”B pobieranie danych z VU:  
„0”B: nie pobrano danych z VU w czasie tej kontroli,  
„1”B: pobrano dane z VU w czasie tej kontroli  
„p”B drukowanie:  
„0”B: nie wykonano wydruków w czasie tej kontroli,  
„1”B: wykonano wydruki w czasie tej kontroli  
„d”B wyświetlacz:  
„0”B: nie użyto wyświetlacza w czasie tej kontroli,  
„1”B: użyto wyświetlacza w czasie tej kontroli  
„xxxx”B Nieużywany.  
Generacja 2:  
Przypisanie warto ści – zapisane oktetami : „cvpdexxx”B (8 bitów)  
„c”B pobieranie danych z karty:  
„0”B: nie pobrano danych z karty w czasie tej kontroli,  
„1”B: pobrano dane z karty w czasie tej kontroli  
„v”B pobieranie danych z VU:  
„0”B: nie pobrano danych z VU w czasie tej kontroli,  
„1”B: pobrano dane z VU w czasie tej kontroli  
„p”B drukowanie:  
„0”B: nie wykonano wydruków w czasie tej kontroli,  
„1”B: wykonano wydruki w czasie tej kontroli  
„d”B wyświetlacz:  
„0”B: nie użyto wyświetlacza w czasie tej kontroli,  
„1”B: użyto wyświetlacza w czasie tej kontroli  
„e”B kontrola drogowa kalibracji  
„0”B: parametry kalibracyjne nie zostały skontrolowane 
w czasie tej kontroli,  
„1”B: parametry kalibracyjne zostały skontrolowane 
w czasie tej kontroli,  
„xxx”B RFU.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 148  
2.54.  CurrentDateTime  
Bieżąca data i godzina urządzenia rejestrującego.
  
Przypisanie warto ści: nie określa się.  
2.55.  CurrentDateTimeRecordArray  
Generacja 2:  
Bieżąca data i godzina wraz z metadanymi stosowane w protokole 
pobierania danych.
  
recordType  oznacza typ rekordu (CurrentDateTime).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość CurrentDateTime w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów z bieżącego dnia i godziny.  
2.56.  DailyPresenceCounter  
Licznik znajdujący się na karcie kierowcy lub na karcie warszta towej 
zwiększany o jeden dla każdego dnia kalendarzowego, w którym ka rta 
jest włożona do VU. Ten typ danych związany jest z wymaganiami 266, 
299, 320 i 343 określonymi w załączniku 1C.
  
Przypisanie warto ści: Kolejna liczba do maksymalnej wartości = 9 999, 
i następnie ponownie zaczyna od 0. Przy pierwszym wydaniu karty  
licznik jest ustawiany na 0.  
2.57.  Datef  
Data wyrażona w czytelnym, przeznaczonym do druku formacie 
numerycznym.
  
Przypisanie wartości:  
yyyy rok  
mm miesiąc  
dd dzień  
„00000000”H oznacza jednoznacznie brak daty.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 149  
2.58.  DateOfDayDownloaded  
Generacja 2:  
data i godzina pobrania danych;
  
Przypisanie warto ści: nie określa się.  
2.59.  DateOfDayDownloadedRecordArray  
Generacja 2:  
Data i godzina pobrania danych wraz z metadanymi stosowane w pr oto­
kole pobierania danych.
  
recordType  oznacza typ rekordu (DateOfDayDownloaded).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość CurrentDateTime w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem daty i godziny rekordów pobierania danych.  
2.60.  Distance  
Przebyta odległość (wynik obliczenia różnicy między dwoma odczy tami 
licznika kilometrów pojazdu wyrażona w kilometrach).
  
Przypisanie warto ści: liczba binarna bez znaku. Wartość w km 
w zakresie operacyjnym 0 do 9 999 km.  
▼M3 
2.60a.  DownloadInterfaceVersion  
Generacja 2, wersja 2:  
Kod wskazujący wersję interfejsu pobierania danych przyrządu re jestru­
jącego.
  
Przypisanie warto ści: „aabb”H:  
„aa”H „00”H: nieużywany,  
„01”H: przyrząd rejestrujący generacji 2,  
„bb”H „00”H: nieużywany,  
„01”H: przyrząd rejestrujący wersji 2 generacji 2.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 150  
2.61.  DriverCardApplicationIdentification  
Informacje przechowywane na karcie kierowcy dotyczące identyfik acji 
aplikacji na karcie (wymagania 253 i 278 określone w załączniku  1C).  
Generacja 1:
  
typeOfTachographCardId  określa wdrożony typ karty.  
cardStructureVersion  określa wersję struktury wdrożonej na karcie.  
noOfEventsPerType  jest liczbą zdarzeń według typu zdarzenia możli­
wych do zarejestrowania na karcie.  
noOfFaultsPerType  jest liczbą usterek według typu usterki możliwych 
do zarejestrowania na karcie.  
activityStructureLength  podaje liczbę bajtów dostępnych do przecho­
wywania rekordów czynności.  
noOfCardVehicleRecords  jest liczbą rekordów dotyczących pojazdów 
możliwych do zarejestrowania na karcie.  
noOfCardPlaceRecords  jest liczbą miejsc możliwych do zarejestro­
wania na karcie.  
Generacja 2:  
▼M1
 
Oprócz generacji 1 używane są następujące elementy danych:  
noOfGNSSADRecords  jest liczbą rekordów skumulowanego czasu 
prowadzenia pojazdu z GNSS, które mogą być zapisane na karcie.  
noOfSpecificConditionRecords  jest liczbą rekordów warunków szcze­
gólnych, które mogą być zapisane na karcie.  
noOfCardVehicleUnitRecords  jest liczbą rekordów używanych przy­
rządów rejestrujących, które mogą być zapisane na karcie.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 151  
2.61a.  DriverCardApplicationIdentificationV2  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie kierowcy dotyczące identyfik acji 
aplikacji karty (wymóg 278a określony w załączniku IC).
  
lengthOfFollowingData  to liczba kolejnych bajtów we wpisie.  
noOfBorderCrossingRecords  to liczba rekordów dotyczących przekro­
czenia granicy, które mogą być przechowywane na karcie kierowcy . 
noOfLoadUnloadRecords  to liczba rekordów dotyczących załadunku/ 
rozładunku, które mogą być przechowywane na karcie kierowcy.  
noOfLoadTypeEntryRecords  to liczba rekordów dotyczących wpisu 
typu załadunku, które mogą być przechowywane na karcie kierowcy . 
vuConfigurationLengthRange  to liczba bajtów na karcie do tacho­
grafu, dostępnych na potrzeby przechowywania konfiguracji VU.  
▼B 
2.62.  DriverCardHolderIdentification  
Informacje przechowywane na karcie kierowcy dotyczące identyfik acji 
posiadacza karty (wymagania 256 i 281 określone w załączniku 1C ).
 
cardHolderName  jest nazwą i imieniem (imionami) posiadacza karty 
kierowcy.  
cardHolderBirthDate  jest datą urodzenia posiadacza karty kierowcy.  
cardHolderPreferredLanguage  jest preferowanym językiem posia­
dacza karty.  
▼M3 
2.63.  DSRCSecurityData  
Generacja 2:  
Definicja tego typu danych znajduje się w dodatku 11.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 152  
2.64.  EGFCertificate  
Generacja 2:  
Certyfikat klucza publicznego urządzenia zewnętrznego GNSS na 
potrzeby wzajemnego uwierzytelniania z VU. Strukturę tego certy fikatu 
określono w dodatku 11.
  
2.65.  EmbedderIcAssemblerId  
Dostarcza informacje o wbudowującym układ scalony.
  
countryCode  jest 2-literowym kodem państwa wbudowującego moduł 
zgodnie z normą ISO 3166.  
moduleEmbedder  oznacza wbudowującego moduł.  
manufacturerInformation  na potrzeby użytku wewnętrznego 
producenta.  
2.66.  EntryTypeDailyWorkPeriod  
Kod umożliwiający rozróżnienie między początkiem a końcem wpisu  
dotyczącego dziennego okresu pracy oraz miejsca i sposobu wprow a­
dzenia wpisu.  
Generacja 1
  
Przypisanie warto ści: zgodnie z normą ISO/IEC8824-1.  
▼M3 
Generacja 2
  
Przypisanie warto ści: zgodnie z normą ISO/IEC8824-1.  
▼B 
2.67.  EquipmentType  
Kod umożliwiający rozróżnienie typów urządzeń dla aplikacji 
tachograficznej.
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 153  
Generacja 1:
  
Przypisanie warto ści: zgodnie z normą ISO/IEC8824-1.  
Wartość 0 jest zastrzeżona do celów oznaczenia państwa członkow ­
skiego lub Europy w rubryce CHA certyfikatów.  
Generacja 2:  
▼M1 
Takie same wartości jak w przypadku generacji 1 z następującymi  
uzupełnieniami:
  
Uwaga 1:  Wartości generacji 2 dla tabliczki, adaptera, połączenia 
zewnętrznego GNSS, a także wartości generacji 1 dla przyrządu r ejes­
trującego oraz czujnika ruchu mogą być, w stosownych przypadkac h, 
używane w SealRecord.  
Uwaga 2:  W polu CardHolderAuthorisation (CHA) świadectwa gene­
racji 2, wartości (1), (2) i (6) należy interpretować jako wska zujące na 
świadectwo wzajemnego uwierzytelnienia dla danego typu urządzen ia. 
W celu wskazania danego certyfikatu na potrzeby podpisu cyfrowe go 
należy użyć wartości (17), (18) lub (19).  
▼B 
2.68.  EuropeanPublicKey  
Generacja 1:  
Europejski klucz publiczny.
  
2.69.  EventFaultRecordPurpose  
Kod wyjaśniający, dlaczego zarejestrowano zdarzenie lub usterkę .
 
Przypisanie warto ści: ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 154
  
jedno/jedna z 10 ostatnich zdarzeń lub usterek (lub ostatnie/os tatnia zdarzenie lub usterka) 
najdłuższe zdarzenie w jednym z ostatnich 10 dni ich występowan ia 
jedno z 5 najdłuższych zdarzeń w ciągu ostatnich 365 dni 
ostatnie zdarzenie w jednym z ostatnich 10 dni ich występowania  
najpoważniejsze zdarzenie w jednym z ostatnich 10 dni ich wystę powania 
jedno z 5 najpoważniejszych zdarzeń w ciągu ostatnich 365 dni 
pierwsze zdarzenie lub usterka z aistniałe po ostatniej kalibrac ji 
aktywne/trwające zdarzenie lub usterka 
RFU 
swoisty dla producenta.  
2.70.  EventFaultType  
Kod kwalifikujący zdarzenie lub usterkę.
  
Przypisanie warto ści: 
Generacja 1:
  
zdarzenia ogólne 
brak dalszych szczegółów, 
włożenie nieważnej karty, 
konflikt kart, 
nakładające się czasy, 
prowadzenie pojazdu bez prawidłowej karty, 
włożenie karty podczas prowadzenia pojazdu, 
sesja ostatniej karty niezamknięta prawidłowo, 
przekroczenie prędkości, 
przerwa w zasilaniu, 
błąd danych dotyczących ruchu, 
Konflikt ruchu pojazdu, 
RFU,
  
zdarzenia związane z próbami naruszenia zabezpieczenia przyrząd u rejestrującego, 
brak dalszych szczegółów, 
błąd uwierzytelnienia czujnika ruchu, 
błąd uwierzytelnienia kart do tachografów, 
nieupoważniona zmiana w czujniku ruchu, 
błąd integralności wprowadzania danych na kartę 
błąd integralności przechowywanych danych użytkownika, 
błąd wewnętrznego przesyłania danych, 
nieupoważnione otwarcie obudowy, 
uszkodzenie sprzętu, 
RFU,
  
zdarzenia związane z próbami naruszenia zabezpieczenia czujnika , 
brak dalszych szczegółów, 
błąd uwierzytelnienia, 
błąd integralności przechowywanych danych, 
błąd wewnętrznego przesyłania danych, 
nieupoważnione otwarcie obudowy, 
uszkodzenie sprzętu, 
RFU,
  
usterki urządzenia rejestrującego, 
brak dalszych szczegółów, 
usterka wewnętrzna VU, 
usterka drukarki, 
usterka wyświetlacza, 
usterka pobierania danych, 
usterka czujnika, 
RFU,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 155
  
usterki karty, 
brak dalszych szczegółów, 
RFU,
  
RFU,
  
swoisty dla producenta.  
▼M3 
Generacja 2, wersja 1:  
▼M1
 
zdarzenia ogólne, 
brak dalszych szczegółów, 
włożenie nieważnej karty, 
konflikt kart, 
nakładające się czasy, 
prowadzenie pojazdu bez prawidłowej karty, 
włożenie karty podczas prowadzenia pojazdu, 
sesja ostatniej karty niezamknięta prawidłowo, 
przekroczenie prędkości, 
przerwa w zasilaniu, 
błąd danych dotyczących ruchu, 
konflikt ruchu pojazdu, 
konflikt czasowy (między GNSS a wewnętrznym zegarem VU), 
błąd połączenia z urządzeniem do łączności na odległość, 
brak informacji o pozycji z odbiornika GNSS, 
błąd połączenia z urządzeniem zewnętrznym GNSS, 
RFU,
  
zdarzenia związane z próbami naruszenia zabezpieczenia przyrząd u rejestrującego, 
brak dalszych szczegółów, 
błąd uwierzytelnienia czujnika ruchu, 
błąd uwierzytelnienia kart do tachografów, 
nieupoważniona zmiana w czujniku ruchu, 
błąd integralności wprowadzania danych na kartę 
błąd integralności przechowywanych danych użytkownika, 
błąd wewnętrznego przesyłania danych, 
nieupoważnione otwarcie obudowy, 
uszkodzenie sprzętu, 
wykrycie ingerencji w GNSS, 
błąd uwierzytelnienia urządzenia zewnętrznego GNSS, 
wygaśnięcie certyfikatu urządzenia zewnętrznego GNSS, 
RFU,
  
zdarzenia związane z próbami naruszenia zabezpieczenia czujnika , 
brak dalszych szczegółów, 
błąd uwierzytelnienia, 
błąd integralności przechowywanych danych, 
błąd wewnętrznego przesyłania danych, 
nieupoważnione otwarcie obudowy, 
uszkodzenie sprzętu, 
RFU,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 156
  
usterki urządzenia rejestrującego, 
brak dalszych szczegółów, 
usterka wewnętrzna VU, 
usterka drukarki, 
usterka wyświetlacza, 
usterka pobierania danych, 
usterka czujnika, 
wewnętrzny odbiornik GNSS, 
urządzenie zewnętrzne GNSS, 
urządzenie do łączności na odległość, 
interfejs ITS, 
RFU,
  
usterki karty, 
brak dalszych szczegółów, 
RFU,
  
RFU,
  
swoisty dla producenta.  
▼M3 
Generacja 2, wersja 2:  
„0x”H zdarzenia ogólne,  
„00”H brak dalszych szczegółów,  
„01”H włożenie nieważnej karty,  
„02”H konflikt kart,  
„03”H nakładające się czasy,  
„04”H prowadzenie pojazdu bez prawidłowej karty,  
„05”H włożenie karty podczas prowadzenia pojazdu,  
„06”H sesja ostatniej karty niezamknięta prawidłowo,  
„07”H przekroczenie prędkości,  
„08”H przerwa w zasilaniu,  
„09”H błąd danych dotyczących ruchu,  
„0A”H konflikt ruchu pojazdu,  
„0B”H konflikt czasowy (między GNSS a wewnętrznym 
zegarem VU),  
„0C”H błąd połączenia z urządzeniem do łączności na 
odległość,  
„0D”H brak informacji o pozycji z odbiornika GNSS,  
„0E”H błąd połączenia z urządzeniem zewnętrznym 
GNSS,  
„0F”H anomalia GNSS,  
„1x”H zdarzenia związane z próbami naruszenia zabez­
pieczenia przyrządu rejestrującego,  
„10”H brak dalszych szczegółów,  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 157  
„11”H błąd uwierzytelnienia czujnika ruchu,  
„12”H błąd uwierzytelnienia karty do tachografu,  
„13”H nieupoważniona zmiana w czujniku ruchu,  
„14”H błąd integralności wprowadzania danych na kartę,  
„15”H błąd integralności przechowywanych danych użyt­
kownika,  
„16”H błąd wewnętrznego przesyłania danych,  
„17”H nieupoważnione otwarcie obudowy,  
„18”H uszkodzenie sprzętu,  
„19”H wykrycie ingerencji w GNSS,  
„1 A”H błąd uwierzytelnienia urządzenia zewnętrznego 
GNSS,  
„1 B”H wygaśnięcie certyfikatu urządzenia zewnętrznego 
GNSS,  
„1C”H niespójność między danymi dotyczącymi ruchu 
a przechowywanymi danymi dotyczącymi czyn­
ności kierowcy,  
„1D”H do „1F”H RFU,  
„2x”H zdarzenia związane z próbami naruszenia zabez­
pieczenia czujnika,  
„20”H brak dalszych szczegółów,  
„21”H błąd uwierzytelnienia,  
„22”H błąd integralności przechowywanych danych,  
„23”H błąd wewnętrznego przesyłania danych,  
„24”H nieupoważnione otwarcie obudowy,  
„25”H uszkodzenie sprzętu,  
„26”H do „2F”H RFU,  
„3x”H usterki urządzenia rejestrującego,  
„30”H brak dalszych szczegółów,  
„31”H usterka wewnętrzna VU,  
„32”H usterka drukarki,  
„33”H usterka wyświetlacza,  
„34”H usterka pobierania danych,  
„35”H usterka czujnika,  
„36”H wewnętrzny odbiornik GNSS,  
„37”H urządzenie zewnętrzne GNSS,  
„38”H urządzenie do łączności na odległość,  
„39”H interfejs ITS,  
„3 A”H usterka czujnika wewnętrznego,  
„3B”H do „3F”H RFU,  
„4x”H usterki karty,  
„40”H brak dalszych szczegółów,  
„41”H do „4F”H RFU,  
„50”H do „7F”H RFU,  
„80”H do „FF”H swoisty dla producenta.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 158  
2.71.  ExtendedSealIdentifier  
Generacja 2:  
Rozszerzony identyfikator plomby jednoznacznie identyfikuje plo mbę 
(wymóg 401 określony w załączniku IC).
  
manufacturerCode  to kod producenta plomby.  Przypisanie warto ści: 
zob. rejestr bazy danych, którym zarządzać ma Komisja Europejsk a (zob. 
https://dtc.jrc.ec.europa.eu).  
sealIdentifier  to identyfikator plomby, który jest niepowtarzalny dla 
producenta.  Przypisanie warto ści: numer alfanumeryczny, niepowta­
rzalny w domenie producenta zgodnie z [ISO8859-1].  
▼B 
2.72.  ExtendedSerialNumber  
Unikalna identyfikacja urządzenia. Może być używana także jako iden­
tyfikator klucza publicznego urządzenia.  
Generacja 1:
  
serialNumber  jest numerem seryjnym urządzenia, niepowtarzalnym dla 
producenta, typu urządzenia i miesiąca oraz roku, jak wyjaśnion o 
poniżej.  
monthYear  jest identyfikacją miesiąca i roku produkcji (lub przypi­
sanym numerem seryjnym).  
Przypisanie warto ści: miesiąc (dwie cyfry) i rok (dwie ostatnie cyfry) 
w kodzie BCD.  
type jest identyfikatorem typu urządzenia.  
Przypisanie warto ści: swoisty dla producenta, z wartością zastrzeżoną 
„FFh”.  
manufacturerCode : jest kodem numerycznym identyfikującym produ­
centa homologowanego urządzenia.  
Generacja 2:
  
serialNumber , zob. generacja 1  
monthYear , zob. generacja 1  
type jest identyfikatorem typu urządzenia  
manufacturerCode : zob. generacja 1.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 159  
2.73.  FullCardNumber  
Kod całkowicie identyfikujący kartę do tachografu.
  
cardType  jest typem karty do tachografu.  
cardIssuingMemberState  jest kodem państwa członkowskiego, które 
wydało kartę.  
cardNumber  jest numerem karty.  
2.74.  FullCardNumberAndGeneration  
Generacja 2:  
Kod całkowicie identyfikujący kartę do tachografu i jej generac ję.
 
fullcardNumber  identyfikuje kartę do tachografu.  
generation  oznacza generację używanej karty do tachografu.  
2.75.  Generation  
Generacja 2:  
wskazuje generację używanego tachografu.
  
Przypisanie warto ści: 
„00”H RFU  
„01”H Generacja 1  
„02”H Generacja 2  
„03”H .. „FF”H RFU  
2.76.  GeoCoordinates  
▼M3 
Generacja 2:  
Współrzędne geograficzne są zakodowane jako liczby całkowite. T akie 
liczby są wielokrotnościami kodowania ± DDMM.M dla szerokości 
geograficznej i ± DDDMM.M dla długości geograficznej. W powyższ ym 
przypadku odpowiednio ± DD i ± DDD oznaczają stopnie, a MM.M 
minuty. Długość i szerokość geograficzną nieznanej pozycji prze dstawia 
się jako Hex „7FFFFF” (w zapisie dziesiętnym 8388607).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 160
  
latitude  koduje się jako wielokrotność (mnożnik 10) zapisu 
± DDMM.M.  
longitude  koduje się jako wielokrotność (mnożnik 10) zapisu 
± DDMM.M.  
2.77.  GNSSAccuracy  
Generacja 2:  
Dokładność danych GNSS dotyczących położenia (definicja eee)). Taka 
dokładność jest kodowana jako liczba całkowita i jest wielokrot nością 
(mnożnik 10) wartości X.Y podanej w zdaniu GSA NMEA.
  
▼M1 
2.78.  GNSSAccumulatedDriving  
Generacja 2:  
Informacje zapisane na karcie kierowcy lub na karcie warsztatow ej doty­
czące położenia pojazdu z GNSS, jeżeli skumulowany czas prowadz enia 
pojazdu osiągnie wielokrotność trzech godzin (wymagania 306 i 3 54 
określone w załączniku IC).
  
gnssADPointerNewestRecord  jest indeksem ostatniego uaktualnionego 
rekordu skumulowanego prowadzenia pojazdu z GNSS.  
Value assignment  to liczba odpowiadająca stanowi licznika rekordu 
GNSS dotyczącego skumulowanego prowadzenia pojazdu, rozpoczy­
nając od „0” dla pierwszego wystąpienia w strukturze rekordu GN SS 
dotyczącego skumulowanego czasu prowadzenia pojazdu.  
gnssAccumulatedDrivingRecords  jest zbiorem rekordów zawierających 
datę i godzinę, kiedy skumulowany czas prowadzenia pojazdu osią ga 
wielokrotność trzech godzin i informacji na temat położenia poj azdu.  
2.79.  GNSSAccumulatedDrivingRecord  
Generacja 2:  
Informacje zapisane na karcie kierowcy lub na karcie warsztatow ej doty­
czące położenia pojazdu z GNSS, jeżeli skumulowany czas prowadz enia 
pojazdu osiągnie wielokrotność trzech godzin (wymagania 305 i 3 53 
określone w załączniku IC)
  
timeStamp  to data i godzina, o której skumulowany czas prowadzenia 
pojazdu osiąga wielokrotność trzech godzin.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 161  
gnssPlaceRecord  zawiera informacje dotyczące położenia pojazdu.  
vehicleOdometerValue  to wartość stanu licznika kilometrów, przy 
której skumulowany czas prowadzenia pojazdu osiąga wielokrotnoś ć 
trzech godzin.  
▼M3 
2.79a.  GNSSAuthAccumulatedDriving  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie kierowcy lub na karcie warsz tatowej, 
przedstawiające status uwierzytelnienia pozycji GNSS dla pojazd u, jeżeli 
skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trz ech 
godzin (wymogi 306d i 356d określone w załączniku IC).
  
gnssAuthADPointerNewestRecord  to indeks ostatniego uaktualnionego 
rekordu dotyczącego statusu uwierzytelnienia pozycji GNSS.  
Przypisanie warto ści: liczba odpowiadająca stanowi licznika rekordu 
dotyczącego statusu uwierzytelnienia pozycji GNSS, rozpoczynają c od 
„0” dla pierwszego wystąpienia w strukturze rekordu dotyczącego  statusu 
uwierzytelnienia pozycji GNSS.  
gnssAuthStatusADRecords  to zbiór rekordów zawierających datę 
i godzinę, kiedy skumulowany czas prowadzenia pojazdu osiąga wi elo­
krotność trzech godzin, oraz status uwierzytelnienia pozycji GN SS. 
2.79b.  GNSSAuthStatusADRecord  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej, przedstawiające status uwierzytelnienia pozycji pojazd u GNSS, 
jeżeli skumulowany czas prowadzenia pojazdu osiągnie wielokrotn ość 
trzech godzin (wymogi 306c i 356c określone w załączniku IC). I nne 
informacje związane z samą pozycją GNSS są przechowywane w inny m 
rekordzie (zob. 2.79 GNSSAccumulatedDrivingRecord).
  
timeStamp  to data i godzina, gdy skumulowany czas prowadzenia 
pojazdu osiąga wielokrotność trzech godzin (która jest taka sam a, jak 
data i godzina w odpowiednim rekordzie GNSSAccumulatedDrivingRe ­
cord),  
authenticationStatus  to status uwierzytelnienia pozycji GNSS, gdy 
skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzec h 
godzin.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 162  
2.79c.  GNSSPlaceAuthRecord  
Generacja 2, wersja 2:  
Informacje dotyczące pozycji GNSS dla pojazdu (wymogi 108, 109,  110, 
296, 306a, 306c, 306e, 306g, 356a, 356c, 356e i 356g określone 
w załączniku IC).
  
timeStamp  to data i godzina określenia pozycji GNSS dla pojazdu.  
gnssAccuracy  to dokładność danych dotyczących pozycji GNSS.  
geoCoordinates  to lokalizacja zarejestrowana przy użyciu GNSS.  
authenticationStatus  to status uwierzytelnienia pozycji GNSS 
w momencie jej określenia.  
▼B 
2.80.  GNSSPlaceRecord  
Generacja 2:  
Informacje dotyczące położenia GNSS pojazdu (wymagania 108, 109 , 
110, 296, 305, 347 i 353 określone w załączniku 1C).
  
timeStamp  jest datą i godziną określenia położenia GNSS pojazdu.  
gnssAccuracy  jest dokładnością danych dotyczących położenia GNSS.  
geoCoordinates  jest lokalizacją zapisaną przy użyciu GNSS.  
2.81.  HighResOdometer  
Stan licznika kilometrów pojazdu: skumulowana odległość przebyt a 
przez pojazd w czasie jego eksploatacji.
  
Przypisanie warto ści: liczba binarna bez znaku. Wartość wyrażona 
w 1/200 km w zakresie operacyjnym 0 do 21 055 406 km.  
2.82.  HighResTripDistance  
Odległość przebyta w czasie całej lub części podróży.
  
Przypisanie warto ści: liczba binarna bez znaku. Wartość wyrażona 
w 1/200 km w zakresie operacyjnym 0 do 21 055 406 km.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 163  
2.83.  HolderName  
Nazwisko i imię (imiona) posiadacza karty.
  
holderSurname  jest nazwiskiem posiadacza. Do nazwiska nie dodaje się 
tytułów.  
Przypisanie warto ści: w przypadku kart nieosobowych, holderSurname 
zawiera te same informacje, co companyName lub workshopName, lu b 
controlBodyName.  
holderFirstNames  oznacza imię (imiona) i inicjały posiadacza.  
▼M3 
2.84.  Zarezerwowane dla przysz łego użytku 
▼B 
Generacja 2:  
Informacje, czy odbiornik GNSS znajduje się wewnątrz czy na zew nątrz 
przyrządu rejestrującego. Prawda – oznacza, że odbiornik GNSS z najduje 
się wewnątrz VU. Fałsz – oznacza, że odbiornik GNSS jest zewnęt rzny.
  
2.85.  K-ConstantOfRecordingEquipment  
Stała urządzenia rejestrującego (definicja m)).
  
Przypisanie warto ści: liczba impulsów na kilometr w zakresie opera­
cyjnym 0 do 64 255 impulsów/km.  
▼M1 
2.86.  KeyIdentifier  
Unikalny identyfikator klucza publicznego używany przy odwoływa niu 
się do klucza i do wybierania klucza. Identyfikuje także posiad acza 
klucza.
  
Pierwsza pozycja jest odpowiednia przy odesłaniu do klucza publ icznego 
przyrządu rejestrującego, karty do tachografu lub urządzenia ze wnętrz­
nego GNSS.  
Druga pozycja jest odpowiednia przy odesłaniu do klucza publicz nego 
przyrządu rejestrującego (w przypadkach, gdy numer seryjny przy rządu 
rejestrującego może nie być znany w czasie sporządzenia certyfi katu).  
Trzecia pozycja jest odpowiednia przy odesłaniu do klucza publi cznego 
państwa członkowskiego.  
▼B 
2.87.  KMWCKey  
Generacja 2:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 164  
Klucz AES i związana z nim wersja klucza stosowane do sparowani a 
VU z czujnikiem ruchu. Szczegółowe informacje – zob. dodatek 11 .
 
kMWCKey  jest długością klucza AES w szeregu z kluczem stoso­
wanym do sparowania VU z czujnikiem ruchu.  
keyVersion  oznacza wersję klucza AES.  
2.88.  Language  
Kod identyfikujący język.
  
Przypisanie warto ści: kod składający się z dwóch małych liter zgodny 
z normą ISO 639.  
2.89.  LastCardDownload  
Data i godzina, zapisane na karcie kierowcy, ostatniego pobiera nia 
danych z karty (do innych celów niż kontrola) – wymagania 257 
i 282 określone w załączniku 1C. Datę tę aktualizuje VU lub dow olny 
czytnik kart.
  
Przypisanie warto ści: nie określa się.  
▼M3 
2.89a.  LengthOfFollowingData  
Generacja 2, wersja 2:  
Wskaźnik długości dla rozszerzalnych rekordów.
  
Przypisanie warto ści: zob. dodatek 2.  
▼B 
2.90.  LinkCertificate  
Generacja 2:  
Certyfikat połączenia par kluczy Głównego Europejskiego Organu Certy­
fikacji.
  
▼M3 
2.90a.  LoadType  
Generacja 2, wersja 2:  
Kod identyfikujący wpisany typ załadunku.
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 165  
Przypisanie warto ści: 
„00”H nieokreślony typ załadunku,  
„01”H towary,  
„02”H pasażerowie,  
„03”H .. „FF”H RFU.  
▼B 
2.91.  L-TyreCircumference  
Obwód toczny opon (definicja u)).
  
Przypisanie warto ści: liczba binarna bez znaku, wyrażona w 1/8 mm 
w zakresie operacyjnym 0 do 8 031 mm.  
▼M1 
2.92.  MAC  
Generacja 2:  
Kryptograficzna suma kontrolna o długości 8, 12 lub 16 bajtów o dpo­
wiadającej mechanizmom szyfrowania określonym w dodatku 11.
  
▼B 
2.93.  ManualInputFlag  
Kod identyfikujący czy posiadacz karty wprowadza ręcznie czynno ści 
kierowcy przy wkładaniu karty (wymaganie 081 określone w załącz niku 
1B i wymaganie 102 określone w załączniku 1C).
  
Przypisanie warto ści: nie określa się.  
2.94.  ManufacturerCode  
Kod identyfikujący producenta urządzeń posiadających homologacj ę 
typu.
  
Laboratorium właściwe dla przeprowadzania badań interoperacyjno ści 
prowadzi i publikuje wykaz kodów producenta na swojej stronie i nter­
netowej (wymaganie 454 określone w załączniku 1C).  
ManufacturerCodes przyznaje się tymczasowo twórcom tachografów po 
wystąpieniu przez nich z wnioskiem do laboratorium właściwego d la 
przeprowadzania badań interoperacyjności.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 166  
2.95.  ManufacturerSpecificEventFaultData  
Generacja 2:  
Swoiste dla producentów kody błędów upraszczają analizę błędów oraz 
konserwację przyrządów rejestrujących.
  
manufacturerCode  identyfikuje producenta przyrządu rejestrującego.  
manufacturerSpecificErrorCode  jest kodem błędu swoistym dla 
producenta.  
2.96.  MemberStateCertificate  
Certyfikat klucza publicznego państwa członkowskiego wydany prz ez 
europejski organ certyfikacji.
  
2.97.  MemberStateCertificateRecordArray  
Generacja 2:  
Certyfikat państwa członkowskiego wraz z metadanymi stosowany 
w protokole pobierania danych.
  
recordType  oznacza typ rekordu (MemberStateCertificate).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość MemberStateCertificate w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze. Wartość tę należy ustawić 
na 1, ponieważ certyfikaty mogą mieć różne długości.  
records  jest zbiorem certyfikatów państw członkowskich.  
2.98.  MemberStatePublicKey  
Generacja 1:  
Klucz publiczny państwa członkowskiego.
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 167  
2.99.  Name  
Nazwa (nazwisko).
  
codePage  określa zestaw znaków zdefiniowany w rozdziale 4,  
name  jest nazwą zakodowaną przy użyciu wyszczególnionego zestawu 
znaków.  
2.100.  NationAlpha  
Alfabetyczne określenie państwa musi być zgodne ze znakami wyró ż­
niającymi stosowanymi na pojazdach w ruchu międzynarodowym 
(Konwencja wiedeńska Narodów Zjednoczonych o ruchu drogowym 
z 1968 r.).
  
Kody Nation Alpha i Numeric znajdują się na wykazie utrzymywany m 
na stronie internetowej laboratorium wyznaczonego do przeprowad zenia 
badań interoperacyjności zgodnie z wymaganiem 440 określonym 
w załączniku 1C.  
2.101.  NationNumeric  
Numeryczne odesłanie do państwa.
  
Przypisanie warto ści: zob. typ danych w 2.100 (NationAlpha)  
Modyfikacji lub aktualizacji specyfikacji Nation Alpha lub Nume ric 
opisanych w powyższym akapicie dokonuje się dopiero po otrzyman iu 
przez wyznaczone laboratorium opinii producentów przyrządów rej estru­
jących tachografów cyfrowych i inteligentnych posiadających hom olo­
gację typu.  
▼M3 
2.101a.  NoOfBorderCrossingRecords  
Generacja 2, wersja 2:  
Liczba rekordów dotyczących przekroczenia granicy, które mogą b yć 
przechowywane na karcie kierowcy lub na karcie warsztatowej.
  
Przypisanie warto ści: zob. dodatek 2.  
▼B 
2.102.  NoOfCalibrationRecords  
Liczba rekordów kalibracyjnych, możliwych do przechowywania na 
karcie.  
Generacja 1:
  
Przypisanie warto ści: zob. dodatek 2.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 168  
Generacja 2:
  
Przypisanie warto ści: zob. dodatek 2.  
2.103.  NoOfCalibrationsSinceDownload  
Licznik pokazujący liczbę kalibracji wykonanych przy użyciu kar ty 
warsztatowej od ostatniego pobrania danych z tej karty (wymagan ie 
317 i 340 określone w załączniku 1C).
  
Przypisanie warto ści: nie określa się.  
2.104.  NoOfCardPlaceRecords  
Liczba rekordów dotyczących miejsca, możliwych do przechowywani a 
na karcie kierowcy lub na karcie warsztatowej.  
Generacja 1:
  
Przypisanie warto ści: zob. dodatek 2.  
Generacja 2:
  
Przypisanie warto ści: zob. dodatek 2.  
2.105.  NoOfCardVehicleRecords  
Liczba rekordów dotyczących użytych pojazdów, możliwych do prze cho­
wywania na karcie kierowcy lub na karcie warsztatowej.
  
Przypisanie warto ści: zob. dodatek 2.  
2.106.  NoOfCardVehicleUnitRecords  
Generacja 2:  
Liczba rekordów dotyczących przyrządów rejestrujących, możliwyc h do 
przechowywania na karcie kierowcy lub na karcie warsztatowej.
  
Przypisanie warto ści: zob. dodatek 2.  
2.107.  NoOfCompanyActivityRecords  
Liczba rekordów dotyczących czynności firmy, możliwych do przec ho­
wywania na karcie firmowej.
  
Przypisanie warto ści: zob. dodatek 2.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 169  
2.108.  NoOfControlActivityRecords  
Liczba rekordów dotyczących czynności kontrolnych, możliwych do  
przechowywania na karcie kontrolnej.
  
Przypisanie warto ści: zob. dodatek 2.  
2.109.  NoOfEventsPerType  
Liczba zdarzeń według typu, możliwych do przechowywania na karc ie.
 
Przypisanie warto ści: zob. dodatek 2.  
2.110.  NoOfFaultsPerType  
Liczba usterek według typu, możliwych do przechowywania na karc ie.
 
Przypisanie warto ści: zob. dodatek 2.  
▼M1 
2.111.  NoOfGNSSADRecords  
Generacja 2:  
Liczba rekordów skumulowanego czasu prowadzenia pojazdu z GNSS,  
które mogą być przechowywane na karcie.
  
Przypisanie warto ści: zob. dodatek 2.  
▼M3 
2.111a.  NoOfLoadUnloadRecords  
Generacja 2, wersja 2:  
Liczba rekordów dotyczących załadunku/rozładunku, które mogą by ć 
przechowywane na karcie.
  
Przypisanie warto ści: zob. dodatek 2.  
▼B 
2.112.  NoOfSpecificConditionRecords  
Generacja 2:  
Liczba rekordów warunków szczególnych, które mogą być przechowy ­
wane na karcie.
  
Przypisanie warto ści: zob. dodatek 2.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 170  
2.112a.  NoOfLoadTypeEntryRecords  
Generacja 2, wersja 2:  
Liczba rekordów dotyczących typu załadunku, które mogą być prze cho­
wywane na karcie kierowcy lub na karcie warsztatowej.
  
Przypisanie warto ści: zob. dodatek 2.  
▼B 
2.113.  OdometerShort,  
Stan licznika kilometrów pojazdu w skróconej postaci.
  
Przypisanie warto ści: liczba binarna bez znaku. Wartość w km 
w zakresie operacyjnym 0 do 9 999 999 km.  
2.114.  OdometerValueMidnight  
Stan licznika kilometrów o północy w danym dniu (wymaganie 090 
określone w załączniku 1B i wymaganie 113 określone w załącz­
niku 1C).
  
Przypisanie warto ści: nie określa się.  
▼M3 
2.114a.  OperationType  
Generacja 2, wersja 2:  
Kod identyfikujący wpisany typ operacji.
  
Przypisanie warto ści: 
„00”H RFU,  
„01”H operacja załadunku,  
„02”H operacja rozładunku,  
„03”H operacja równoczesnego załadunku/rozładunku,  
„04”H .. „FF”H RFU.  
▼B 
2.115.  OdometerValueMidnightRecordArray  
Generacja 2:  
OdometerValueMidnight wraz z metadanymi stosowany w protokole 
pobierania danych.
  
recordType  oznacza typ rekordu (OdometerValueMidnight).  Przypi­
sanie warto ści: zob. RecordType  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 171  
recordSize  to wielkość OdometerValueMidnight w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów OdometerValueMidnight.  
2.116.  OverspeedNumber  
Liczba zdarzeń przekroczenia prędkości od ostatniej kontroli pr zekro­
czenia prędkości.
  
Przypisanie warto ści: 0 oznacza, że nie było zdarzenia przekroczenie 
prędkości od ostatniej kontroli przekroczenia prędkości, 1 ozna cza, że 
było jedno zdarzenie przekroczenia prędkości od ostatniej kontr oli prze­
kroczenia prędkości... 255 oznacza, że było 255 lub więcej zdar zeń 
przekroczenia prędkości od ostatniej kontroli przekroczenia prę dkości.  
▼M3 
2.116a.  PlaceAuthRecord  
Informacje dotyczące miejsca rozpoczęcia lub zakończenia dzienn ego okresu 
pracy (wymogi 108, 271, 296, 324 i 347 określone w załączniku I C). 
Generacja 2, wersja 2:
  
entryTime  to data i godziną wpisu.  
entryTypeDailyWorkPeriod  to typ wpisu.  
dailyWorkPeriodCountry  to wpisany kraj.  
dailyWorkPeriodRegion  to wpisany region.  
vehicleOdometerValue  to stan licznika kilometrów w momencie wpisy­
wania miejsca.  
entryGNSSPlaceAuthRecord  to zarejestrowana lokalizacja, status uwie­
rzytelnienia GNSS oraz godzina.  
2.116b.  PlaceAuthStatusRecord  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej, przedstawiające status uwierzytelnienia miejsca rozpoc zęcia 
lub zakończenia dziennych okresów pracy (wymogi 306a i 356a okr e­ 
ślone w załączniku IC). Inne informacje związane z samym miejsc em są 
przechowywane w innym rekordzie (zob. 2.117 PlaceRecord).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 172
  
entryTime  to data i godzina związana z wpisem (która jest taką samą 
datą i godziną, jak w odpowiednim rekordzie PlaceRecord).  
authenticationStatus  to status uwierzytelnienia zarejestrowanej pozycji 
GNSS.  
▼B 
2.117.  PlaceRecord  
Informacje dotyczące miejsca rozpoczęcia lub zakończenia dzienn ego 
okresu pracy (wymagania 108, 271, 296, 324 i 347 określone w za łącz­
niku 1C).  
Generacja 1:
  
entryTime  jest datą i godziną wpisu.  
entryTypeDailyWorkPeriod  jest typem wpisu.  
dailyWorkPeriodCountry  jest wprowadzonym państwem.  
dailyWorkPeriodRegion  jest wprowadzonym regionem.  
vehicleOdometerValue  jest stanem licznika kilometrów w czasie wpro­
wadzania miejsca.  
Generacja 2:
  
Oprócz generacji 1 używany jest następujący element składowy:  
entryGNSSPlaceRecord  jest zapisaną lokalizacją i godziną.  
▼M3 
2.117a.  PositionAuthenticationStatus  
Generacja 2, wersja 2:
  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 173  
Przypisanie warto ści (zob. dodatek 12):  
„00”H nieuwierzytelniona (zob. dodatek 12, wymóg 
GNS_39),  
„01”H uwierzytelniona (zob. dodatek 12, wymóg GNS_39),  
„02”H. „FF”H RFU.  
▼B 
2.118.  PreviousVehicleInfo  
Informacje dotyczące pojazdu poprzednio używanego przez kierowc ę 
w chwili wkładania jego karty do przyrządu rejestrującego (wyma ganie 
081 określone w załączniku 1B i wymaganie 102 określone w załąc z­
niku 1C).  
Generacja 1:
  
vehicleRegistrationIdentification  wskazuje numer VRN i państwo 
członkowskie rejestracji pojazdu.  
cardWithdrawalTime  jest datą i godziną wyjęcia karty.  
Generacja 2:
  
Oprócz generacji 1 używany jest następujący element danych:  
vuGeneration  identyfikuje generację przyrządu rejestrującego.  
2.119.  PublicKey  
Generacja 1:  
Klucz publiczny RSA.
  
rsaKeyModulus  jest modułem pary kluczy.  
rsaKeyPublicExponent  jest wykładnikiem publicznym pary kluczy.  
2.120.  RecordType  
Generacja 2:  
Odniesienie do typu rekordu. Ten typ danych stosuje się w Recor dAr­
rays.
 ▼M3
02016R0799 — PL — 21.08.2023 — 003.001 — 174  
Przypisanie warto ści:
 
► (1) M1 
► (2) M3 ActivityChangeInfo, 
CardSlotsStatus, 
CurrentDateTime, 
MemberStateCertificate, 
OdometerValueMidnight, 
DateOfDayDownloaded, 
SensorPaired, 
Signature, 
SpecificConditionRecord, 
VehicleIdentificationNumber, 
VehicleRegistrationNumber, 
VuCalibrationRecord, 
VuCardIWRecord, 
VuCardRecord, 
VuCertificate, 
VuCompanyLocksRecord, 
VuControlActivityRecord, 
VuDetailedSpeedBlock, 
VuDownloadablePeriod, 
VuDownloadActivityData, 
VuEventRecord,  
►M1 VuGNSSADRecord, ◄ 
VuITSConsentRecord, 
VuFaultRecord, 
VuIdentification, 
VuOverSpeedingControlData, 
VuOverSpeedingEventRecord, 
VuPlaceDailyWorkPeriodRecord, 
VuTimeAdjustmentGNSSRecord, 
VuTimeAdjustmentRecord, 
VuPowerSupplyInterruptionRecord, 
SensorPairedRecord, 
SensorExternalGNSSCoupledRecord,  
►M3 VuBorderCrossingRecord, 
VuLoadUnloadRecord, 
VehicleRegistrationIdentification, 
RFU, ◄ 
swoisty dla producenta.  
2.121.  RegionAlpha  
Alfabetyczne odniesienie do regionu w określonym kraju.
  
Generacja 1:  
Przypisanie warto ści:
 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 175  
Generacja 2:  
Kody RegionAlpha znajdują się na wykazie utrzymywanym na stroni e 
internetowej laboratorium wyznaczonego do przeprowadzenia badań  inte­
roperacyjności.  
2.122.  RegionNumeric  
Numeryczne odniesienie do regionu w określonym państwie.
  
Generacja 1:  
Przypisanie warto ści:
 
Generacja 2:  
Kody RegionNumeric znajdują się na wykazie utrzymywanym na stro nie 
internetowej laboratorium wyznaczonego do przeprowadzenia badań  inte­
roperacyjności.  
2.123.  RemoteCommunicationModuleSerialNumber  
Generacja 2:  
Numer seryjny modułu komunikacji na odległość.
  
2.124.  RSAKeyModulus  
Generacja 1:  
Moduł pary kluczy RSA.
  
Przypisanie warto ści: nieokreślona.  
2.125.  RSAKeyPrivateExponent  
Generacja 1:  
Wykładnik prywatny pary kluczy RSA.
  
Przypisanie warto ści: nieokreślona.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 176  
2.126.  RSAKeyPublicExponent  
Generacja1:  
Wykładnik publiczny pary kluczy RSA.
  
Przypisanie warto ści: nieokreślona.  
2.127.  RtmData  
Generacja2:  
Definicja tego typu danych znajduje się w dodatku 14.  
2.128.  SealDataCard  
Generacja 2:  
W tym typie danych przechowuje się informacje o plombach przymo co­
wanych do różnych części pojazdu i jest on przeznaczony do prze cho­
wywania na karcie. Ten typ danych związany jest z wymaganiem 33 7 
określonym w załączniku 1C.
  
noOfSealRecords  jest liczbą rekordów w zbiorze sealRecords.  
sealRecords  jest zbiorem rekordów dotyczących plomb.  
2.129.  SealDataVu  
Generacja 2:  
W tym typie danych przechowuje się informacje o plombach przymo co­
wanych do różnych części pojazdu i jest on przeznaczony do prze cho­
wywania w przyrządzie rejestrującym.
  
sealRecords  jest zbiorem rekordów dotyczących plomb. W przypadku 
gdy dostępnych jest mniej niż 5 plomb wartość EquipmentType we 
wszystkich niewykorzystanych sealRecords należy ustawić na 16, tj. 
niewykorzystane.  
2.130.  SealRecord  
Generacja 2:  
W tym typie danych przechowuje się informacje o plombie przymoc o­
wanej do danego elementu składowego. Ten typ danych związany je st 
z wymaganiem 337 określonym w załączniku 1C.
  
equipmentType  określa typ urządzenia, do którego jest przymocowana 
plomba.  
extendedSealIdentifier  jest identyfikatorem plomby przymocowanej do 
urządzenia.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 177  
2.131.  SensorApprovalNumber  
Numer homologacji typu czujnika.  
Generacja 1:
  
Przypisanie warto ści: nieokreślona.  
Generacja 2:
  
Przypisanie warto ści: 
Należy podawać numer homologacji, który został opublikowany na 
odpowiedniej stronie internetowej Komisji Europejskiej, tj. na przykład 
z uwzględnieniem myślników, jeżeli występują. Numer homologacji  
musi być wyrównany do lewej strony.  
2.132.  SensorExternalGNSSApprovalNumber  
Generacja 2:  
Numer homologacji urządzenia zewnętrznego GNSS.
  
Przypisanie warto ści: 
Należy podawać numer homologacji, który został opublikowany na 
odpowiedniej stronie internetowej Komisji Europejskiej, tj. na przykład 
z uwzględnieniem myślników, jeżeli występują. Numer homologacji  
musi być wyrównany do lewej strony.  
2.133.  SensorExternalGNSSCoupledRecord  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące iden­
tyfikacji urządzenia zewnętrznego GNSS powiązanego z przyrządem  
rejestrującym (wymaganie 100 określone w załączniku 1C).
  
sensorSerialNumber  jest numerem seryjnym urządzenia zewnętrznego 
GNSS powiązanego z przyrządem rejestrującym.  
sensorApprovalNumber  jest numerem homologacji tego urządzenia 
zewnętrznego GNSS.  
sensorCouplingDate  jest datą powiązania tego urządzenia zewnętrznego 
GNSS z przyrządem rejestrującym.  
2.134.  SensorExternalGNSSIdentification  
Generacja 2:  
Informacje dotyczące identyfikacji urządzenia zewnętrznego GNSS  
(wymaganie 98 określone w załączniku 1C).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 178
  
sensorSerialNumber  jest rozszerzonym numerem seryjnym urządzenia 
zewnętrznego GNSS.  
sensorApprovalNumber  jest numerem homologacji urządzenia 
zewnętrznego GNSS.  
sensorSCIdentifier  jest identyfikatorem elementu zabezpieczenia urzą­
dzenia zewnętrznego GNSS.  
sensorOSIdentifier  jest identyfikatorem systemu operacyjnego urzą­
dzenia zewnętrznego GNSS.  
2.135.  SensorExternalGNSSInstallation  
Generacja 2:  
Informacje, przechowywane w urządzeniu zewnętrznym GNSS, doty­
czące instalacji urządzenia zewnętrznego GNSS (wymaganie 123 ok re­ 
ślone w załączniku 1C).
  
sensorCouplingDateFirst  jest datą pierwszego powiązania urządzenia 
zewnętrznego GNSS z przyrządem rejestrującym.  
firstVuApprovalNumber  jest numerem homologacji pierwszego przy­
rządu rejestrującego powiązanego z urządzeniem zewnętrznym GNSS . 
firstVuSerialNumber  jest numerem seryjnym pierwszego przyrządu 
rejestrującego sparowanego z urządzeniem zewnętrznym GNSS.  
sensorCouplingDateCurrent  jest datą obecnego powiązania urządzenia 
zewnętrznego GNSS z przyrządem rejestrującym.  
currentVuApprovalNumber  jest numerem homologacji przyrządu 
rejestrującego powiązanego obecnie z urządzeniem zewnętrznym GN SS. 
currentVUSerialNumber  jest numerem seryjnym przyrządu rejestrują­
cego powiązanego obecnie z urządzeniem zewnętrznym GNSS.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 179  
2.136.  SensorExternalGNSSOSIdentifier  
Generacja 2:  
Identyfikator systemu operacyjnego urządzenia zewnętrznego GNSS .
 
Przypisanie warto ści: swoisty dla producenta.  
2.137.  SensorExternalGNSSSCIdentifier  
Generacja 2:  
Ten typ jest stosowany np. w celu zidentyfikowania kryptografic znego 
modułu urządzenia zewnętrznego GNSS.  
Identyfikator elementu zabezpieczenia urządzenia zewnętrznego G NSS.
  
Przypisanie warto ści: element swoisty dla producenta.  
2.138.  SensorGNSSCouplingDate  
Generacja 2:  
Data powiązania urządzenia zewnętrznego GNSS z przyrządem rejes tru­
jącym.
  
Przypisanie warto ści: nieokreślona.  
2.139.  SensorGNSSSerialNumber  
Generacja 2:  
Ten typ jest wykorzystywany do przechowywania numeru seryjnego 
odbiornika GNSS, zarówno gdy jest w VU, jak i gdy znajduje się 
poza VU.  
Numer seryjny odbiornika GNSS.
  
2.140.  SensorIdentification  
Informacje przechowywane w czujniku ruchu dotyczące jego identy fi­
kacji (wymaganie 077 określone w załączniku 1B i wymaganie 95 o kre­ 
ślone w załączniku 1C).
  
sensorSerialNumber  jest rozszerzonym numerem seryjnym czujnika 
ruchu (zawiera numer części i kod producenta).  
sensorApprovalNumber  jest numerem homologacji czujnika ruchu.  
sensorSCIdentifier  jest identyfikatorem elementu zabezpieczenia czuj­
nika ruchu.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 180  
sensorOSIdentifier  jest identyfikatorem systemu operacyjnego czujnika 
ruchu.  
2.141.  SensorInstallation  
Informacje przechowywane w czujniku ruchu dotyczące jego instal acji 
(wymaganie 099 określone w załączniku 1B i wymaganie 122 określ one 
w załączniku 1C).
  
sensorPairingDateFirst  jest datą pierwszego sparowania czujnika ruchu 
z przyrządem rejestrującym.  
firstVuApprovalNumber  jest numerem homologacji pierwszego przy­
rządu rejestrującego sparowanego z czujnikiem ruchu.  
firstVuSerialNumber  jest numerem seryjnym pierwszego przyrządu 
rejestrującego sparowanego z czujnikiem ruchu.  
sensorPairingDateCurrent  jest datą obecnego sparowania czujnika 
ruchu z przyrządem rejestrującym.  
currentVuApprovalNumber  jest numerem homologacji przyrządu 
rejestrującego obecnie sparowanego z czujnikiem ruchu.  
currentVUSerialNumber  jest numerem seryjnym przyrządu rejestrują­
cego obecnie sparowanego z czujnikiem ruchu.  
2.142.  SensorInstallationSecData  
Informacje przechowywane na karcie warsztatowej dotyczące zabez pie­
czenia potrzebne do sparowania czujników ruchu z przyrządami re jes­
trującymi (wymaganie 308 i 331 określone w załączniku 1C).  
Generacja 1:
  
Przypisanie warto ści: zgodnie z normą ISO 16844-3.  
Generacja 2:  
Zgodnie z opisem w dodatku 11 karta warsztatowa musi przechowyw ać 
maksymalnie trzy klucze na potrzeby parowania czujnika ruchu z VU. 
Klucze te mają różne wersje.
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 181  
2.143.  SensorOSIdentifier  
Identyfikator systemu operacyjnego czujnika ruchu.
  
Przypisanie warto ści: swoisty dla producenta.  
2.144.  SensorPaired  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące iden­
tyfikacji czujnika ruchu sparowanego z przyrządem rejestrującym  
(wymaganie 079 określone w załączniku 1B).
  
sensorSerialNumber  jest numerem seryjnym czujnika ruchu obecnie 
sparowanego z przyrządem rejestrującym.  
sensorApprovalNumber  jest numerem homologacji czujnika ruchu 
obecnie sparowanego z przyrządem rejestrującym.  
sensorPairingDateFirst  jest datą pierwszego sparowania z przyrządem 
rejestrującym czujnika ruchu obecnie sparowanego z przyrządem r ejes­
trującym.  
2.145.  SensorPairedRecord  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące iden­
tyfikacji czujnika ruchu sparowanego z przyrządem rejestrującym  
(wymaganie 97 określone w załączniku 1C).
  
sensorSerialNumber  jest numerem seryjnym czujnika ruchu sparowa­
nego z przyrządem rejestrującym.  
sensorApprovalNumber  jest numerem homologacji tego czujnika 
ruchu.  
sensorPairingDate  jest datą sparowania tego czujnika ruchu z przy­
rządem rejestrującym.  
2.146.  SensorPairingDate  
Data sparowania czujnika ruchu z przyrządem rejestrującym.
  
Przypisanie warto ści: nieokreślona.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 182  
2.147.  SensorSCIdentifier  
Identyfikator elementu zabezpieczenia czujnika ruchu.
  
Przypisanie warto ści: element swoisty dla producenta.  
2.148.  SensorSerialNumber  
Numer seryjny czujnika ruchu.
  
2.149.  Podpis  
Podpis cyfrowy.  
Generacja 1:
  
Przypisanie warto ści: zgodnie z dodatkiem 11 – Wspólne mechanizmy 
zabezpieczenia.  
Generacja 2:
  
Przypisanie warto ści: zgodnie z dodatkiem 11 – Wspólne mechanizmy 
zabezpieczenia.  
2.150.  SignatureRecordArray  
Generacja 2:  
Zbiór podpisów wraz z metadanymi stosowany w protokole pobieran ia 
danych.
  
recordType  oznacza typ rekordu (Signature).  Przypisanie warto ści: 
zob. RecordType  
recordSize  to wielkość Signature w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze. Wartość tę należy ustawić 
na 1, ponieważ podpisy mogą mieć różne długości.  
records  jest zbiorem podpisów.  
2.151.  SimilarEventsNumber  
Liczba podobnych zdarzeń w danym dniu (wymaganie 094 określone 
w załączniku 1B i wymaganie 117 określone w załączniku 1C).
  
Przypisanie warto ści: 0 nie używany, 1 oznacza, że tylko jedno 
zdarzenie tego typu wystąpiło i jest zapamiętane dla tego dnia,  2  
oznacza, że 2 zdarzenia wystąpiły w tym dniu (zapamiętane jest tylko 
jedno),... 255 oznacza, że 255 lub więcej zdarzeń wystąpiło w t ym dniu.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 183  
2.152.  SpecificConditionRecord  
Informacje przechowywane na karcie kierowcy, karcie warsztatowe j lub 
w przyrządzie rejestrującym dotyczące warunku szczególnego (wym a­
gania 130, 276, 301, 328 i 355 określone w załączniku 1C).
  
entryTime  jest datą i godziną wprowadzenia danych.  
specificConditionType  jest kodem identyfikującym warunek szczególny.  
2.153.  SpecificConditions  
Informacje przechowywane na karcie kierowcy, karcie warsztatowe j lub 
w przyrządzie rejestrującym dotyczące warunku szczególnego (wym a­
gania 131, 277, 302, 329 i 356 określone w załączniku 1C).  
Generacja 2:
  
conditionPointerNewestRecord  jest indeksem ostatniego, uaktualnio­
nego rekordu warunku szczególnego.  
Przypisanie warto ści: liczba odpowiadająca stanowi licznika rekordu 
dotyczącego warunku szczególnego, rozpoczynając od „0” dla pier w­
szego wystąpienia w strukturze rekordu dotyczącego warunku szcz egól­
nego.  
specificConditionRecords  jest zbiorem rekordów zawierających infor­
macje o zarejestrowanych warunkach szczególnych.  
2.154.  SpecificConditionType  
Kod identyfikujący warunek szczególny (wymagania 050b, 105a, 21 2a 
i 230a określone w załączniku 1B oraz wymaganie 62 określone 
w załączniku 1C).
  
Generacja 1:  
Przypisanie warto ści: 
„00”H RFU  
„01”H poza zakresem — początek  
„02”H poza zakresem — koniec  
„03”H Przeprawa promowa/przejazd kolejowy  
„04”H .. „FF”H RFU  
Generacja 2:  
Przypisanie warto ści: 
„00”H RFU  
„01”H poza zakresem — początek  
„02”H poza zakresem — koniec  
„03”H Przeprawa promowa/przejazd kolejowy – początek  
„04”H Przeprawa promowa/przejazd kolejowy – koniec  
„05”H .. „FF”H RFU  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 184  
2.155.  Prędkość 
Prędkość pojazdu (km/h).
  
Przypisanie warto ści: kilometry na godzinę w zakresie operacyjnym 0 
do 220 km/h.  
2.156.  SpeedAuthorised  
Maksymalne dozwolone prędkości pojazdu (definicja hh)).
  
2.157.  SpeedAverage  
Prędkość średnia w uprzednio zdefiniowanym przedziale czasu (km /h).
 
2.158.  SpeedMax  
Prędkość maksymalna zmierzona w uprzednio zdefiniowanym przedzi ale 
czasu.
  
▼M3 
2.158a.  TachographCardsGen1Suppression  
Generacja 2, wersja 2:  
Zdolność drugiej generacji VU do używania pierwszej generacji k art 
kierowcy, kontrolnej i firmowej (zob. dodatek 15, MIG_002).
  
Przypisanie warto ści: 
„0000”H przyrząd rejestrujący jest w stanie używać kart do 
tachografów generacji 1 (wartość domyślna),  
„A5E3”H przyrząd rejestrujący nie jest w stanie używać 
kart do tachografów generacji 1,  
Wszelkie inne wartości 
nieużywany.  
▼B 
2.159.  TachographPayload  
Generacja 2:  
Definicja tego typu danych znajduje się w dodatku 14.  
▼M1 
2.160.  Zarezerwowany dla przysz łego użytku 
▼B 
2.161.  TDesSessionKey  
Generacja 1:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 185  
Klucz sesyjny T-DES.
  
Przypisanie warto ści: nie określa się.  
▼M1 
2.162.  TimeReal  
Kod w polu zawierającym łącznie datę i godzinę, gdzie data i go dzina są 
wyrażone w sekundach liczonych od godziny 00h.00m.00s. w dniu 
1 stycznia 1970 r. UTC.
  
Przypisanie warto ści – zapisane oktetami : liczba sekund od północy 
1 stycznia 1970 r. UTC.  
Maksymalna możliwa data/godzina wypada w 2106 r.  
▼B 
2.163.  TyreSize  
Oznaczenie wymiarów opon.
  
Przypisanie warto ści: zgodnie z dyrektywą 92/23 (EWG) z dnia 
31 marca 1992, Dz.U. L 129 s. 95.  
2.164.  VehicleIdentificationNumber  
Numer identyfikacyjny pojazdu (VIN) odnoszący się do pojazdu ja ko 
całości, normalnie numer seryjny nadwozia lub ramy.
  
Przypisanie warto ści: jak określono w normie ISO 3779.  
2.165.  VehicleIdentificationNumberRecordArray  
Generacja 2:  
Numer identyfikacyjny pojazdu wraz z metadanymi stosowany w pro to­
kole pobierania danych.
  
recordType  oznacza typ rekordu (VehicleIdentificationNumber).  Przy­
pisanie warto ści: zob. RecordType  
recordSize  to wielkość VehicleIdentificationNumber w bajtach.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 186  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem numerów identyfikacyjnych pojazdu.  
2.166.  VehicleRegistrationIdentification  
Identyfikacja pojazdu, unikalna dla Europy (VRN i państwo człon kow­
skie).
  
vehicleRegistrationNation  jest państwem, w którym pojazd jest 
zarejestrowany.  
vehicleRegistrationNumber  jest numerem rejestracyjnym 
pojazdu (VRN).  
▼M3 
2.166a.  VehicleRegistrationIdentificationRecordArray  
Generacja 2, wersja 2:  
Identyfikacja rejestracyjna pojazdu wraz z metadanymi stosowana  
w protokole pobierania danych.
  
recordType  oznacza typ rekordu (VehicleRegistrationIdentification).  
Przypisanie warto ści: zob. RecordType.  
recordSize  to wielkość VehicleRegistrationIdentification w bajtach.  
noOfRecords  to liczba rekordów w zbiorze.  
records  to zbiór identyfikacji rejestracyjnej pojazdu.  
▼B 
2.167.  VehicleRegistrationNumber  
Numer rejestracyjny pojazdu (VRN). Numer rejestracyjny przydzie la 
organ rejestracji pojazdów.
  
codePage  określa zestaw znaków zdefiniowany w rozdziale 4,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 187  
vehicleRegNumber  jest numerem VRN zakodowanym przy użyciu 
wyszczególnionego zestawu znaków.  
Przypisanie warto ści: swoisty dla kraju.  
2.168.  VehicleRegistrationNumberRecordArray  
▼M3 
Generacja 2, wersja 1:  
▼B 
Numer rejestracyjny pojazdu wraz z metadanymi stosowany w proto kole 
pobierania danych.
  
recordType  oznacza typ rekordu (VehicleRegistrationNumber).  Przypi­
sanie warto ści: zob. RecordType  
recordSize  to wielkość VehicleRegistrationNumber w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem numerów rejestracyjnych pojazdu.  
2.169.  VuAbility  
Generacja 2:  
Informacje przechowywane w VU dotyczące możliwości stosowania k art 
do tachografów generacji 1 (wymaganie 121 określone w załącznik u 
1C).
 
Przypisanie warto ści – zapisane oktetami : „xxxxxxxa”B (8 bitów)  
Odnośnie do zdolności do obsługi generacji 1:  
„a”B Zdolność do obsługi kart do tachografów generacji 1:  
„0” B generacja 1 jest obsługiwana,  
„1” B generacja 1 nie jest obsługiwana,  
„xxxxxxx”B RFU  
2.170.  VuActivityDailyData  
Generacja 1:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 188  
Informacje przechowywane w VU dotyczące zmian czynności lub zmi an 
stanu prowadzenia pojazdu lub zmian stanu karty dla określonego  dnia 
kalendarzowego (wymaganie 084 określone w załączniku 1B i wyma­
gania 105, 106, 107 określone w załączniku 1C) i stanu czytnikó w 
o godzinie 00:00 tego dnia.
  
noOfActivityChanges  jest liczbą słów ActivityChangeInfo w zbiorze 
activityChangeInfos.  
activityChangeInfos  jest zbiorem słów ActivityChangeInfo przechowy­
wanych w VU dla danego dnia. Zawsze zawiera dwa słowa Activity­
ChangeInfo opisujące stan dwóch czytników o godzinie 00:00 tego  dnia.  
2.171.  VuActivityDailyRecordArray  
Generacja 2:  
Informacje przechowywane w VU dotyczące zmian czynności lub zmi an 
stanu prowadzenia pojazdu lub zmian stanu karty dla określonego  dnia 
kalendarzowego (wymaganie 105, 106, 107 określone w załączniku 1C) 
i stanu szczelin o godzinie 00:00 tego dnia.
  
recordType  oznacza typ rekordu (ActivityChangeInfo).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość ActivityChangeInfo w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem słów ActivityChangeInfo przechowywanych w VU 
dla danego dnia. Zawsze zawiera dwa słowa ActivityChangeInfo op isu­
jące stan dwóch czytników o godzinie 00:00 tego dnia.  
2.172.  VuApprovalNumber  
Numer homologacji typu przyrządu rejestrującego.  
Generacja 1:
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 189  
Przypisanie warto ści: nieokreślona.  
Generacja 2:
  
Przypisanie warto ści: 
Należy podawać numer homologacji, który został opublikowany na 
odpowiedniej stronie internetowej Komisji Europejskiej, tj. na przykład 
z uwzględnieniem myślników, jeżeli występują. Numer homologacji  
musi być wyrównany do lewej strony.  
2.173.  VuCalibrationData  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
kalibracji urządzenia rejestrującego (wymaganie 098 określone w  załącz­
niku 1B).
  
noOfVuCalibrationRecords  jest liczbą rekordów w zbiorze vuCalibra­
tionRecords.  
vuCalibrationRecords  jest zbiorem rekordów kalibracyjnych.  
2.174.  VuCalibrationRecord  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
kalibracji urządzenia rejestrującego (wymaganie 098 określone w  załącz­
niku 1B i wymaganie 119 i 120 określone w załączniku 1C).  
Generacja 1:
  
calibrationPurpose  jest celem kalibracji.  
workshopName, workshopAddress  są nazwą i adresem warsztatu.  
workshopCardNumber  identyfikuje kartę warsztatową używaną przy 
kalibracji.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 190  
workshopCardExpiryDate  jest terminem ważności karty.  
vehicleIdentificationNumber  jest numerem VIN.  
vehicleRegistrationIdentification  zawiera numer VRN i państwa człon­
kowskiego rejestracji.  
wVehicleCharacteristicConstant  jest współczynnikiem charaktery­
stycznym pojazdu.  
kConstantOfRecordingEquipment  jest stałą urządzenia rejestrującego.  
lTyreCircumference  jest obwodem tocznym kół.  
tyreSize  jest oznaczeniem rozmiaru opon zamontowanych w pojeździe.  
authorisedSpeed  jest dozwoloną prędkością pojazdu.  
oldOdometerValue, newOdometerValue  są starym i nowym stanem 
licznika kilometrów.  
oldTimeValue, newTimeValue  są starą i nową wartością daty 
i godziny.  
nextCalibrationDate  jest datą następnej kalibracji typu określonego 
w CalibrationPurpose, którą powinien przeprowadzić autoryzowany  
organ kontrolny.  
▼M3 
Generacja 2, wersja 1:  
▼B
 
Oprócz generacji 1 używany jest następujący element danych:  
sealDataVu  podaje informacje o plombach przymocowanych do 
różnych części pojazdu.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 191  
Generacja 2, wersja 2:
  
Oprócz generacji 1 używany jest następujący element danych:  
sensorSerialNumber  to numer seryjny czujnika ruchu sparowanego 
z przyrządem rejestrującym na końcu kalibracji,  
sensorGNSSSerialNumber  to numer seryjny urządzenia zewnętrznego 
GNSS powiązanego z przyrządem rejestrującym na końcu kalibracji  
(jeżeli dotyczy),  
rcmSerialNumber  to numer seryjny urządzenia do łączności na odle­
głość powiązanego z przyrządem rejestrującym na końcu kalibracj i 
(jeżeli dotyczy),  
sealDataVu  podaje informacje o plombach przymocowanych do 
różnych części pojazdu.  
byDefaultLoadType  to domyślny typ załadunku pojazdu (element 
obecny tylko w wersji 2).  
calibrationCountry  to kraj, w którym wykonano kalibrację.  
calibrationCountryTimestamp  to data i godzina przekazania przez 
odbiornik GNSS pozycji wykorzystanej do określenia kraju, w któ rym 
wykonano kalibrację.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 192  
2.175.  VuCalibrationRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
kalibracji urządzenia rejestrującego (wymagania 119 i 120 okreś lone 
w załączniku 1C).
  
recordType  oznacza typ rekordu (VuCalibrationRecord).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość VuCalibrationRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów kalibracji.  
2.176.  VuCardIWData  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące cykli 
wkładania i wyjmowania kart dla kart kierowcy lub kart warsztat owych 
w przyrządzie rejestrującym (wymaganie 081 określone w załączni ku 1B 
i wymaganie 103 określone w załączniku 1C).
  
noOfIWRecords  jest liczbą rekordów w zbiorze vuCardIWRecords.  
vuCardIWRecords  jest zbiorem rekordów dotyczących cykli wkładania 
i wyjmowania kart.  
2.177.  VuCardIWRecord  
Informacje przechowywane w przyrządzie rejestrującym dotyczące cyklu 
wkładania i wyjmowania karty kierowcy lub karty warsztatowej w przy­
rządzie rejestrującym (wymaganie 081 określone w załączniku 1B 
i wymaganie 102 określone w załączniku 1C).  
Generacja 1:
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 193  
cardHolderName  jest nazwiskiem i imionami posiadacza karty 
kierowcy lub karty warsztatowej zapisanymi na karcie.  
fullCardNumber  jest typem karty, państwem członkowskim wydającym 
kartę i numerem karty zapisanymi na karcie.  
cardExpiryDate  jest terminem ważności karty zapisanym na karcie.  
cardInsertionTime  jest datą i godziną włożenia karty.  
vehicleOdometerValueAtInsertion  jest stanem licznika kilometrów 
przy wkładaniu karty.  
cardSlotNumber  jest szczeliną czytnika, do której karta jest włożona.  
cardWithdrawalTime  jest datą i godziną wyjęcia karty.  
vehicleOdometerValueAtWithdrawal  jest stanem licznika kilometrów 
przy wyjęciu karty.  
previousVehicleInfo  zawiera informacje o pojeździe poprzednio 
używanym przez kierowcę, zapisane na karcie.  
manualInputFlag  jest flagą pokazującą, czy posiadacz karty przy wkła­
daniu karty wprowadził ręcznie czynności kierowcy.  
Generacja 2:
  
Zamiast fullCardNumber w strukturze danych generacji 2 wykorzys tuje 
się następujący element danych.  
fullCardNumberAndGeneration  jest typem karty, państwem człon­
kowskim wydającym kartę, numerem karty i generacją zapisanymi n a 
karcie.  
2.178.  VuCardIWRecordArray  
Generacja 2:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 194  
Informacje przechowywane w przyrządzie rejestrującym dotyczące cykli 
wkładania i wyjmowania kart kierowcy lub kart warsztatowych w p rzy­
rządzie rejestrującym (wymaganie 103 określone w załączniku 1C) .
 
recordType  oznacza typ rekordu (VuCardIWRecord).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość VuCardIWRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów dotyczących cykli wkładania i wyjmo­
wania kart.  
▼M1 
2.179.  VuCardRecord  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
używanej karty do tachografu (wymaganie 132 określone w załączn iku 
IC).
 
cardNumberAndGenerationInformation  jest pełnym numerem karty 
i generacji dla użytej karty (typ danych 2.74).  
cardExtendedSerialNumber  odczytany z pliku EF_ICC w ramach 
pliku głównego karty.  
cardStructureVersion  odczytane z pliku EF_Application_Identification 
w ramach pliku DF_Tachograph_G2.  
cardNumber  odczytane z pliku EF_Identification w ramach pliku 
DF_Tachograph_G2.  
▼B 
2.180.  VuCardRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące kart 
do tachografów używanych w tym VU. Informacje te są przeznaczon e 
do analizy przez VU problemów dotyczących kart (wymaganie 132 
określone w załączniku 1C).
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 195  
recordType  oznacza typ rekordu (VuCardRecord).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość VuCardRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów dotyczących kart do tachografów używa­
nych w VU.  
2.181.  VuCertificate  
Certyfikat klucza publicznego przyrządu rejestrującego.
  
2.182.  VuCertificateRecordArray  
Generacja 2:  
Certyfikat VU wraz z metadanymi stosowany w protokole pobierani a 
danych.
  
recordType  oznacza typ rekordu (VuCertificate).  Przypisanie warto ści: 
zob. RecordType  
recordSize  to wielkość VuCertificate w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze. Wartość tę należy ustawić 
na 1, ponieważ certyfikaty mogą mieć różne długości.  
records  jest zbiorem certyfikatów VU.  
2.183.  VuCompanyLocksData  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
blokad firmowych (wymaganie 104 określone w załączniku 1B).
  
noOfLocks  jest liczbą blokad wyszczególnionych w vuCompanyLoc­
ksRecords.  
vuCompanyLocksRecords  jest zbiorem rekordów blokad firmowych.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 196  
2.184.  VuCompanyLocksRecord  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
jednej blokady (wymaganie 104 określone w załączniku 1B i wymag anie 
128 określone w załączniku 1C).  
Generacja 1:
  
lockInTime, lockOutTime  są datą i godziną założenia i zdjęcia 
blokady.  
companyName, companyAddress  są nazwą i adresem firmy związanej 
z założeniem blokady.  
companyCardNumber  identyfikuje kartę użytą przy założeniu blokady.  
Generacja 2:
  
Zamiast companyCardNumber w strukturze danych generacji 2 wyko­
rzystuje się następujący element danych.  
companyCardNumberAndGeneration  identyfikuje kartę, w tym jej 
generację, użytą przy założeniu blokady.  
2.185.  VuCompanyLocksRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
blokad firmowych (wymaganie 128 określone w załączniku 1C).
  
recordType  oznacza typ rekordu (VuCompanyLocksRecord).  Przypi­
sanie warto ści: zob. RecordType  
recordSize  to wielkość VuCompanyLocksRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze. Wartość 0..255.  
records  jest zbiorem rekordów blokad firmowych.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 197  
2.185a.  VuConfigurationLengthRange  
Generacja 2, wersja 2:  
Liczba bajtów na karcie do tachografu, dostępnych na potrzeby p rzecho­
wywania konfiguracji VU.
  
Przypisanie warto ści: zob. dodatek 2.  
▼B 
2.186.  VuControlActivityData  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym, dotyczące  
kontroli przeprowadzonych przy użyciu tego VU (wymaganie 102 ok re­ 
ślone w załączniku 1B).
  
noOfControls  jest liczbą kontroli wyszczególnionych w vuControlActi­
vityRecords.  
vuControlActivityRecords  jest zbiorem rekordów czynności 
kontrolnych.  
2.187.  VuControlActivityRecord  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
kontroli wykonanej przy użycie tego VU (wymaganie 102 określone  
w załączniku 1B i wymaganie 126 określone w załączniku 1C).  
Generacja 1:
  
controlType  jest typem kontroli.  
controlTime  jest datą i godziną kontroli.  
controlCardNumber  identyfikuje kartę kontrolną użytą przy kontroli.  
downloadPeriodBeginTime  jest czasem rozpoczęcia okresu, dla którego 
pobrano dane, w przypadku pobierania danych.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 198  
downloadPeriodEndTime  jest czasem zakończenia okresu, dla którego 
pobrano dane, w przypadku pobierania danych.  
Generacja 2:
  
Zamiast controlCardNumber w strukturze danych generacji 2 wykor zys­
tuje się następujący element danych.  
controlCardNumberAndGeneration  identyfikuje kartę kontrolną, 
w tym jej generację, użytą przy kontroli.  
2.188.  VuControlActivityRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym, dotyczące  
kontroli przeprowadzonych przy użyciu tego VU (wymaganie 126 ok re­ 
ślone w załączniku 1C).
  
recordType  oznacza typ rekordu (VuControlActivityRecord).  Przypi­
sanie warto ści: zob. RecordType  
recordSize  to wielkość VuControlActivityRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów czynności kontrolnych VU.  
2.189.  VuDataBlockCounter  
Licznik przechowywany na karcie pokazujący kolejno cykle wkłada nia/ 
wyjmowania karty dla przyrządów rejestrujących.
  
Przypisanie warto ści: kolejna liczba, po osiągnięciu wartości maksy­
malnej 9 999 liczenie rozpoczyna się ponownie od 0.  
2.190.  VuDetailedSpeedBlock  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
szczegółowej prędkości pojazdu dla minuty, przez którą pojazd b ył 
w ruchu (wymaganie 093 określone w załączniku 1B i wymaganie 
116 określone w załączniku 1C).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 199
  
speedBlockBeginDate  jest datą i godziną pierwszego odczytu prędkości 
w bloku.  
speedsPerSecond  jest chronologicznym ciągiem prędkości mierzonych 
co sekundę w ciągu minuty rozpoczynającej się od godziny określ onej 
w speedBlockBeginDate (włącznie).  
2.191.  VuDetailedSpeedBlockRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
szczegółowej prędkości pojazdu.
  
recordType  oznacza typ rekordu (VuDetailedSpeedBlock).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość VuDetailedSpeedBlock w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem bloków szczegółowej prędkości.  
2.192.  VuDetailedSpeedData  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
szczegółowej prędkości pojazdu.
  
noOfSpeedBlocks  jest liczbą bloków zarejestrowanych prędkości 
w zbiorze vuDetailedSpeedBlocks.  
vuDetailedSpeedBlocks  jest zbiorem bloków szczegółowej prędkości.  
▼M3 
2.192a.  VuDigitalMapVersion  
Generacja 2, wersja 2:  
Wersja mapy cyfrowej przechowywanej w przyrządzie rejestrującym  
(wymóg 133j określony w załączniku IC).
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 200  
Przypisanie warto ści: jak określono na specjalnej zabezpieczonej 
stronie internetowej udostępnionej przez Komisję Europejską (wy móg 
133k określony w załączniku IC).  
▼B 
2.193.  VuDownloadablePeriod  
Najstarsza i najświeższa data i godzina, wyznaczające okres, dl a którego 
przyrząd rejestrujący przechowuje dane dotyczące czynności kier owców 
(wymagania 081, 084 lub 087 określone w załączniku 1B i wymagan ia 
102, 105, 108 określone w załączniku 1C).
  
minDownloadableTime  jest przechowywaną w VU datą i godziną 
dawniejszego włożenia karty lub zmiany czynności lub miejsca wp ro­
wadzania danych.  
maxDownloadableTime  jest przechowywaną w VU datą i godziną 
ostatniego wyjęcia karty lub zmiany czynności, lub miejsca wpro wa­
dzania danych.  
2.194.  VuDownloadablePeriodRecordArray  
Generacja 2:  
VUDownloadablePeriod wraz z metadanymi stosowany w protokole 
pobierania danych.
  
recordType  oznacza typ rekordu (VuDownloadablePeriod).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość VuDownloadablePeriod w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów VuDownloadablePeriod.  
2.195.  VuDownloadActivityData  
Informacje przechowywane w przyrządzie rejestrującym dotyczące ostat­
niego pobrania danych (wymaganie 105 określone w załączniku 1B 
i wymaganie 129 określone w załączniku 1C).  
Generacja 1:
  
downloadingTime  jest datą i godziną pobierania danych.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 201  
fullCardNumber  identyfikuje kartę użytą do autoryzowania pobierania 
danych.  
companyOrWorkshopName  jest nazwą firmy lub warsztatu.  
Generacja 2:
  
Zamiast fullCardNumber w strukturze danych generacji 2 wykorzys tuje 
się następujący element danych.  
fullCardNumberAndGeneration  identyfikuje kartę kontrolną, w tym 
jej generację, użytą do autoryzacji pobierania danych.  
2.196.  VuDownloadActivityDataRecordArray  
Generacja 2:  
Informacje dotyczące ostatniego pobrania danych z VU (wymaganie  129 
określone w załączniku 1C).
  
recordType  oznacza typ rekordu (VuDownloadActivityData).  Przypi­
sanie warto ści: zob. RecordType  
recordSize  to wielkość VuDownloadActivityData w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów czynności pobierania danych.  
2.197.  VuEventData  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym, dotyczące  
zdarzeń (wymaganie 094 określone w załączniku 1B z wyłączeniem 
przekroczenia prędkości).
  
noOfVuEvents  jest liczbą zdarzeń wyszczególnionych w zbiorze 
vuEventRecords.  
vuEventRecords  jest zbiorem rekordów dotyczących zdarzeń.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 202  
2.198.  VuEventRecord  
Informacje przechowywane w przyrządzie rejestrującym, dotyczące  
zdarzenia (wymaganie 094 określone w załączniku 1B i wymaganie 
117 określone w załączniku 1C z wyłączeniem przekroczenia prędk ości).  
Generacja 1:
  
eventType  jest typem zdarzenia.  
eventRecordPurpose  jest celem, dla którego zarejestrowano to 
zdarzenie.  
eventBeginTime  jest datą i godziną rozpoczęcia zdarzenia.  
eventEndTime  jest datą i godziną zakończenia zdarzenia.  
cardNumberDriverSlotBegin  identyfikuje kartę włożoną do szczeliny 
karty kierowcy na początku zdarzenia.  
cardNumberCodriverSlotBegin  identyfikuje kartę włożoną do szcze­
liny karty współkierowcy na początku zdarzenia.  
cardNumberDriverSlotEnd  identyfikuje kartę włożoną do szczeliny 
karty kierowcy na końcu zdarzenia.  
cardNumberCodriverSlotEnd  identyfikuje kartę włożoną do szczeliny 
karty współkierowcy na końcu zdarzenia.  
similarEventsNumber  jest liczbą podobnych zdarzeń w tym dniu.  
Sekwencji tej można używać dla wszystkich zdarzeń innych niż pr ze­
kroczenie prędkości.  
Generacja 2:
  
Oprócz generacji 1 używane są następujące elementy danych:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 203  
manufacturerSpecificEventFaultData  zawiera dodatkowe, szczegó­ 
łowe informacje o zdarzeniu odnoszące się do danego producenta.  
Zamiast cardNumberDriverSlotBegin, cardNumberCodriverSlotBegin,  
cardNumberDriverSlotEnd i cardNumberCodriverSlotEnd w strukturz e 
danych generacji 2 wykorzystuje się następujący element danych.  
cardNumberAndGenDriverSlotBegin  identyfikuje kartę, w tym jej 
generację, włożoną do szczeliny karty kierowcy na początku zdar zenia.  
cardNumberAndGenCodriverSlotBegin  identyfikuje kartę, w tym jej 
generację, włożoną do szczeliny karty współkierowcy na początku  
zdarzenia.  
cardNumberAndGenDriverSlotEnd  identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny karty kierowcy na końcu zdarzenia.  
cardNumberAndGenCodriverSlotEnd  identyfikuje kartę, w tym jej 
generację, włożoną do szczeliny karty współkierowcy na końcu 
zdarzenia.  
Jeżeli w zdarzeniu zachodzi konflikt czasu eventBeginTime i eve ntEn­
dTime należy interpretować w następujący sposób:  
eventBeginTime  jest datą i godziną urządzenia rejestrującego.  
eventEndTime  jest datą i godziną GNSS.  
2.199.  VuEventRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym, dotyczące  
zdarzeń (wymaganie 117 określone w załączniku 1C z wyłączeniem 
przekroczenia prędkości).
  
recordType  oznacza typ rekordu (VuEventRecord).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość VuEventRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów dotyczących zdarzeń.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 204  
2.200.  VuFaultData  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
usterek (wymaganie 096 określone w załączniku 1B).
  
noOfVuFaults  jest liczbą usterek wyszczególnionych w zbiorze vuFaul­
tRecords.  
vuFaultRecords  jest zbiorem rekordów dotyczących usterek.  
2.201.  VuFaultRecord  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
jednej usterki (wymaganie 096 określone w załączniku 1B i wymag anie 
118 określone w załączniku 1C).  
Generacja 1:
  
faultType  jest typem usterki urządzenia rejestrującego.  
faultRecordPurpose  jest celem, dla którego ta usterka jest 
zarejestrowana.  
faultBeginTime  jest datą i godziną początku usterki.  
faultEndTime  jest datą i godziną zakończenia usterki.  
cardNumberDriverSlotBegin  identyfikuje kartę włożoną do szczeliny 
karty kierowcy na początku usterki.  
cardNumberCodriverSlotBegin  identyfikuje kartę włożoną do szcze­
liny karty współkierowcy na początku usterki.  
cardNumberDriverSlotEnd  identyfikuje kartę włożoną do szczeliny 
karty kierowcy na końcu usterki.  
cardNumberCodriverSlotEnd  identyfikuje kartę włożoną do szczeliny 
karty współkierowcy na końcu usterki.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 205  
Generacja 2:
  
Oprócz generacji 1 używany jest następujący element danych:  
manufacturerSpecificEventFaultData  zawiera dodatkowe, szczegó­ 
łowe informacje o usterce odnoszące się do danego producenta.  
Zamiast cardNumberDriverSlotBegin, cardNumberCodriverSlotBegin,  
cardNumberDriverSlotEnd i cardNumberCodriverSlotEnd w strukturz e 
danych generacji 2 wykorzystuje się następujący element danych.  
cardNumberAndGenDriverSlotBegin  identyfikuje kartę, w tym jej 
generację, włożoną do szczeliny karty kierowcy na początku uste rki. 
cardNumberAndGenCodriverSlotBegin  identyfikuje kartę, w tym jej 
generację, włożoną do szczeliny karty współkierowcy na początku  
usterki.  
cardNumberAndGenDriverSlotEnd  identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny karty kierowcy na końcu usterki.  
cardNumberAndGenCodriverSlotEnd  identyfikuje kartę, w tym jej 
generację, włożoną do szczeliny karty współkierowcy na końcu us terki.  
2.202.  VuFaultRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
usterek (wymaganie 118 określone w załączniku 1C).
  
recordType  oznacza typ rekordu (VuFaultRecord).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość VuFaultRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów dotyczących usterek.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 206  
2.203.  VuGNSSADRecord  
▼M3 
Generacja 2, wersja 1:  
▼M1 
Informacje przechowywane w przyrządzie rejestrującym dotyczące poło­ 
żenia pojazdu z GNSS, jeżeli skumulowany czas prowadzenia pojaz du 
osiągnie wielokrotność trzech godzin (wymagania 108 i 110 okreś lone 
w załączniku IC).
  
timeStamp  to data i godzina, o której skumulowany czas prowadzenia 
pojazdu osiąga wielokrotność trzech godzin.  
cardNumberAndGenDriverSlot  identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny karty kierowcy.  
cardNumberAndGenCodriverSlot  identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny karty współkierowcy.  
gnssPlaceRecord  zawiera informacje dotyczące położenia pojazdu.  
vehicleOdometerValue  to wartość stanu licznika kilometrów, przy 
której skumulowany czas prowadzenia pojazdu osiąga wielokrotnoś ć 
trzech godzin.  
▼M3 
Generacja 2, wersja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
pozycji GNSS dla pojazdu, jeżeli skumulowany czas prowadzenia 
pojazdu osiągnie wielokrotność trzech godzin (wymogi 108 i 110 okre­ 
ślone w załączniku IC).
  
W wersji 2 generacji 2  zamiast gnssPlaceRecord stosuje się rekord 
gnssPlaceAuthRecord, który zawiera dodatkowo status uwierzyteln ienia 
GNSS.  
2.203a.  VuBorderCrossingRecord  
Generacja 2, wersja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące prze­
kroczeń granicy przez pojazd, jeżeli przekroczył on granicę kra jową 
(wymogi 133a i 133b określone w załączniku IC).  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 207
  
cardNumberAndGenDriverSlot  identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny czytnika karty kierowcy.  
cardNumberAndGenCodriverSlot  identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny czytnika karty współkierowcy.  
countryLeft  to kraj, który pojazd opuścił, określony na podstawie ostat­
niej dostępnej pozycji przed wykryciem przekroczenia granicy. „ Reszta 
świata” (kod 'FF’H NationNumeric) stosuje się, gdy przyrząd rej estru­
jący nie jest w stanie określić kraju, w którym pojazd się znaj duje (np. 
bieżący kraj nie jest objęty zapisanymi mapami cyfrowymi).  
countryEntered  to kraj, do którego pojazd wjechał. „Reszta świata” 
(kod 'FF’H NationNumeric) stosuje się, gdy przyrząd rejestrując y nie 
jest w stanie określić kraju, w którym pojazd się znajduje (np.  bieżący 
kraj nie jest objęty zapisanymi mapami cyfrowymi).  
gnssPlaceAuthRecord  zawiera informacje dotyczące pozycji pojazdu 
w momencie wykrycia przekroczenia granicy oraz statusu jej 
uwierzytelnienia.  
vehicleOdometerValue  to stan licznika kilometrów, gdy przyrząd rejes­
trujący wykrył, że pojazd przekroczył granicę krajową.  
2.203b.  VuBorderCrossingRecordArray  
Generacja 2, wersja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące prze­
kroczeń granicy przez pojazd (wymóg 133c określony w załączniku  IC).
  
recordType  oznacza typ rekordu (VuBorderCrossingRecord).  Przypi­
sanie warto ści: zob. RecordType.  
recordSize  to wielkość VuBorderCrossingRecord w bajtach.  
noOfRecords  to liczba rekordów w zbiorze.  
records  to zbiór rekordów dotyczących przekroczenia granicy.  
▼M1 
2.204.  VuGNSSADRecordArray  
Generacja 2:  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 208  
Informacje przechowywane w przyrządzie rejestrującym dotyczące poło­ 
żenia pojazdu z GNSS, jeżeli skumulowany czas prowadzenia pojaz du 
osiągnie wielokrotność trzech godzin (wymagania 108 i 110 okreś lone 
w załączniku IC).
  
recordType  oznacza typ rekordu (VuGNSSADRecord).  
Value Assignment : zob. RecordType  
recordSize  to wielkość VuGNSSADRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów skumulowanego czasu prowadzenia 
pojazdu z GNSS.  
▼M3 
2.204a.  VuGnssMaximalTimeDifference  
Generacja 2, wersja 2:  
Maksymalna różnica między czasem prawdziwym a czasem zegara 
czasu rzeczywistego VU, na podstawie maksymalnego dryftu czasu 
określonego w wymogu 041 w załączniku IC, przekazywanego przez 
przyrząd rejestrujący do urządzenia zewnętrznego GNSS, zob. dod atek 
12, wymóg GNS_3g.
  
▼B 
2.205.  VuIdentification  
Informacje przechowywane w przyrządzie rejestrującym dotyczące jego 
identyfikacji (wymaganie 075 określone w załączniku 1B oraz wym a­
gania 93 i 121 określone w załączniku 1C).  
Generacja 1:
  
vuManufacturerName  jest nazwą producenta przyrządu rejestrującego.  
vuManufacturerAddress  jest adresem producenta przyrządu rejestrują­
cego.  
vuPartNumber  jest numerem części przyrządu rejestrującego.  
vuSerialNumber  jest numerem seryjnym przyrządu rejestrującego.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 209  
vuSoftwareIdentification  identyfikuje oprogramowanie zainstalowane 
w przyrządzie rejestrującym.  
vuManufacturingDate  jest datą produkcji przyrządu rejestrującego.  
vuApprovalNumber  jest numerem homologacji typu przyrządu rejes­
trującego.  
▼M3 
Generacja 2:
  
Oprócz generacji 1 używane są następujące elementy danych:  
vuGeneration  identyfikuje generację przyrządu rejestrującego.  
vuAbility  podaje informację, czy VU obsługuje 1. generację kart do 
tachografu.  
vuDigitalMapVersion  to wersja mapy cyfrowej przechowywanej 
w przyrządzie rejestrującym (element obecny tylko w wersji 2).  
▼B 
2.206.  VuIdentificationRecordArray  
Generacja 2:  
VuIdentification wraz z metadanymi stosowany w protokole pobier ania 
danych.
  
recordType  oznacza typ rekordu (VuIdentification).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość VuIdentification w bajtach.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 210  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów VuIdentification.  
2.207.  VuITSConsentRecord  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
zgody kierowcy na stosowanie inteligentnych systemów transporto wych.
  
companyCardNumberAndGen  identyfikuje kartę, w tym jej generację. 
Musi to być karta kierowcy lub karta warsztatowa.  
consent  jest flagą wskazującą, czy kierowca wyraził zgodę na stoso­
wanie inteligentnych systemów transportowych w danym pojeździe / 
przyrządzie rejestrującym.  
Przypisanie warto ści: 
TRUE wskazuje zgodę kierowcy na stosowanie inteligentnych 
systemów transportowych  
FALSE wskazuje odmowę kierowcy dotyczącą stosowania inte­
ligentnych systemów transportowych  
2.208.  VuITSConsentRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
zgody kierowcy na stosowanie inteligentnych systemów transporto wych 
(wymaganie 200 określone w załączniku 1C).
  
recordType  oznacza typ rekordu (VuITSConsentRecord).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość VuITSConsentRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów ITS.  
▼M3 
2.208a.  VuLoadUnloadRecord  
Generacja 2, wersja 2:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 211  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
wpisanej operacji załadunku/rozładunku (wymogi 133e, 133f i 133 g 
określone w załączniku IC).
  
timeStamp  to data i godzina wpisania operacji załadunku/rozładunku.  
operationType  to wpisany typ operacji (załadunek, rozładunek lub 
równoczesny załadunek/rozładunek).  
cardNumberAndGenDriverSlot  identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny czytnika karty kierowcy.  
cardNumberAndGenCodriverSlot  identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny czytnika karty współkierowcy.  
gnssPlaceAuthRecord  zawiera informacje dotyczące pozycji pojazdu 
oraz jej statusu uwierzytelnienia.  
vehicleOdometerValue  to stan licznika kilometrów w związku 
z operacją załadunku/rozładunku.  
2.208b.  VuLoadUnloadRecordArray  
Generacja 2, wersja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
wpisanej operacji załadunku/rozładunku (wymóg 133h określony w załącz­
niku IC).
  
recordType  oznacza typ rekordu (VuLoadUnloadRecord). Przypisanie 
wartości: zob. RecordType.  
recordSize  to wielkość VuLoadUnloadRecord w bajtach.  
noOfRecords  to liczba rekordów w zbiorze.  
records  to zbiór rekordów dotyczących operacji załadunku/rozładunku.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 212  
2.209.  VuManufacturerAddress  
Adres producenta przyrządu rejestrującego.
  
Przypisanie warto ści: nieokreślona.  
2.210.  VuManufacturerName  
Nazwa producenta przyrządu rejestrującego.
  
Przypisanie warto ści: nieokreślona.  
2.211.  VuManufacturingDate  
Data produkcji przyrządu rejestrującego.
  
Przypisanie warto ści: nieokreślona.  
2.212.  VuOverSpeedingControlData  
Informacje przechowywane w przyrządzie rejestrującym dotyczące prze­
kroczeń prędkości od ostatniej kontroli przekroczenia prędkości  (wyma­
ganie 095 określone w załączniku 1B i wymaganie 117 określone 
w załączniku 1C).
  
lastOverspeedControlTime  jest datą i godziną ostatniej kontroli prze­
kroczenia prędkości.  
firstOverspeedSince  jest datą i godziną pierwszego przekroczenia pręd­
kości po tej ostatniej kontroli przekroczenia prędkości.  
numberOfOverspeedSince  jest liczbą zdarzeń przekroczenia prędkości 
od ostatniej kontroli przekroczenia prędkości.  
2.213.  VuOverSpeedingControlDataRecordArray  
Generacja 2:  
VuOverSpeedingControlData wraz z metadanymi stosowany w protoko le 
pobierania danych.
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 213  
recordType  oznacza typ rekordu (VuOverSpeedingControlData).  Przy­
pisanie warto ści: zob. RecordType  
recordSize  to wielkość VuOverSpeedingControlData w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów danych kontroli przekroczenia prędkości.  
2.214.  VuOverSpeedingEventData  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
zdarzeń przekroczenia prędkości (wymaganie 094 określone w załą czniku 
1B).
 
noOfVuOverSpeedingEvents  jest liczbą zdarzeń wyszczególnionych 
w zbiorze vuOverSpeedingEventRecords.  
vuOverSpeedingEventRecords  jest zbiorem rekordów zdarzeń przekro­
czenia prędkości.  
2.215.  VuOverSpeedingEventRecord  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
zdarzeń przekroczenia prędkości (wymaganie 094 określone w załą czniku 
1B i wymaganie 117 określone w załączniku 1C).
  
eventType  jest typem zdarzenia.  
eventRecordPurpose  jest celem, dla którego zarejestrowano to 
zdarzenie.  
eventBeginTime  jest datą i godziną rozpoczęcia zdarzenia.  
eventEndTime  jest datą i godziną zakończenia zdarzenia.  
maxSpeedValue  jest maksymalną prędkością zmierzoną w czasie 
zdarzenia.  
averageSpeedValue  jest średnią arytmetyczną prędkości zmierzonych 
w czasie zdarzenia.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 214  
cardNumberDriverSlotBegin  identyfikuje kartę włożoną do szczeliny 
karty kierowcy na początku zdarzenia.  
similarEventsNumber  jest liczbą podobnych zdarzeń w tym dniu.  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
zdarzeń przekroczenia prędkości (wymaganie 094 określone w załą czniku 
1B i wymaganie 117 określone w załączniku 1C).
  
Zamiast cardNumberDriverSlotBegin w strukturze danych generacji  2  
wykorzystuje się następujący element danych.  
cardNumberAndGenDriverSlotBegin  identyfikuje kartę, w tym jej 
generację, włożoną do szczeliny karty kierowcy na początku zdar zenia.  
2.216.  VuOverSpeedingEventRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące zdarzeń 
przekroczenia prędkości (wymaganie 117 określone w załączniku 1 C).
 
recordType  oznacza typ rekordu (VuOverSpeedingEventRecord).  Przy­
pisanie warto ści: zob. RecordType  
recordSize  to wielkość VuOverSpeedingEventRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów zdarzeń przekroczenia prędkości.  
2.217.  VuPartNumber  
Numer części przyrządu rejestrującego.
  
Przypisanie warto ści: swoista dla producenta VU.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 215  
2.218.  VuPlaceDailyWorkPeriodData  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
miejsc rozpoczęcia lub zakończenia dziennego okresu pracy kiero wców 
(wymaganie 087 określone w załączniku 1B oraz wymagania 108 i 1 10 
określone w załączniku 1C).
  
noOfPlaceRecords  jest liczbą rekordów wyszczególnionych w zbiorze 
vuPlaceDailyWorkPeriodRecords.  
vuPlaceDailyWorkPeriodRecords  jest zbiorem rekordów dotyczących 
miejsca.  
2.219.  VuPlaceDailyWorkPeriodRecord  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
miejsca rozpoczęcia lub zakończenia dziennego okresu pracy kier owcy 
(wymaganie 087 określone w załączniku 1B oraz wymagania 108 i 1 10 
określone w załączniku 1C).
  
fullCardNumber  zawiera typ karty kierowcy, państwo członkowskie 
wydające kartę i numer karty.  
placeRecord  zawiera informacje dotyczące wprowadzonego miejsca.  
▼M3 
Generacja 2, wersja 1:  
▼B 
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
miejsca rozpoczęcia lub zakończenia dziennego okresu pracy kier owcy 
(wymaganie 087 określone w załączniku 1B oraz wymagania 108 i 1 10 
określone w załączniku 1C).
  
Zamiast fullCardNumber w strukturze danych generacji 2 wykorzys tuje 
się następujący element danych:  
fullCardNumberAndGeneration  jest typem karty, państwem człon­
kowskim wydającym kartę, numerem karty i generacją przechowywa­
nymi na karcie.  
▼M3 
Generacja 2, wersja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
miejsca rozpoczęcia lub zakończenia dziennego okresu pracy kier owcy 
(wymóg 087 określony w załączniku 1B oraz wymogi 108 i 110 okre ­ 
ślone w załączniku 1C).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 216
  
Zamiast placeRecord w strukturze danych wersji 2 generacji 2 wy ko­
rzystuje się następujący element danych:  
placeAuthRecord  zawiera informacje dotyczące wpisanego miejsca, 
zarejestrowanej pozycji, statusu uwierzytelnienia GNSS i godzin y okre­ 
ślenia pozycji.  
▼B 
2.220.  VuPlaceDailyWorkPeriodRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
miejsc rozpoczęcia lub zakończenia dziennego okresu pracy kiero wców 
(wymagania 108 i 110 określone w załączniku 1C).
  
recordType  oznacza typ rekordu (VuPlaceDailyWorkPeriodRecord).  
Przypisanie warto ści: zob. RecordType  
recordSize  to wielkość VuPlaceDailyWorkPeriodRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów dotyczących miejsca.  
2.221.  VuPrivateKey  
Generacja 1:  
Klucz prywatny przyrządu rejestrującego.
  
2.222.  VuPublicKey  
Generacja 1:  
Klucz publiczny przyrządu rejestrującego.
  
▼M3 
2.222a.  VuRtcTime  
Generacja 2, wersja 2:  
Czas zegara czasu rzeczywistego VU, przekazywany przez VU do ur zą­
dzenia zewnętrznego GNSS, zob. dodatek 12, wymóg GNS_3f.
  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 217  
2.223.  VuSerialNumber  
Numer seryjny przyrządu rejestrującego (wymaganie 075 określone  
w załączniku 1B i wymaganie 93 określone w załączniku 1C).
  
2.224.  VuSoftInstallationDate  
Data instalacji wersji oprogramowania przyrządu rejestrującego.
  
Przypisanie warto ści: nieokreślona.  
2.225.  VuSoftwareIdentification  
Informacje przechowywane w przyrządzie rejestrującym dotyczące zain­
stalowanego oprogramowania.
  
vuSoftwareVersion  jest numerem wersji oprogramowania przyrządu 
rejestrującego.  
vuSoftInstallationDate  jest datą zainstalowania wersji oprogramowania.  
2.226.  VuSoftwareVersion  
Numer wersji oprogramowania przyrządu rejestrującego.
  
Przypisanie warto ści: nieokreślona.  
2.227.  VuSpecificConditionData  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
warunków szczególnych.
  
noOfSpecificConditionRecords  jest liczbą rekordów wyszczególnio­
nych w zbiorze specificConditionRecords.  
specificConditionRecords  jest zbiorem rekordów dotyczących 
warunków szczególnych.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 218  
2.228.  VuSpecificConditionRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
warunków szczególnych (wymaganie 130 określone w załączniku 1C) .
 
recordType  oznacza typ rekordu (SpecificConditionRecord).  Przypi­
sanie warto ści: zob. RecordType  
recordSize  to wielkość SpecificConditionRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów dotyczących warunków szczególnych.  
2.229.  VuTimeAdjustmentData  
Generacja 1:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
korekt czasu dokonanych poza regularną kalibracją (wymaganie 10 1 
określone w załączniku 1C).
  
noOfVuTimeAdjRecords  jest liczbą rekordów w zbiorze vuTimeAdjus­
tmentRecords.  
vuTimeAdjustmentRecords  jest zbiorem rekordów dotyczących 
korekty czasu.  
▼M1 
2.230.  Zarezerwowany dla przysz łego użytku  
2.231.  Zarezerwowany dla przysz łego użytku 
▼B 
2.232.  VuTimeAdjustmentRecord  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
korekty czasu dokonanej poza regularną kalibracją (wymaganie 10 1 
określone w załączniku 1B oraz wymagania 124 i 125 określone 
w załączniku 1C).  
Generacja 1:
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 219  
oldTimeValue, newTimeValue  są starą i nową wartością daty 
i godziny.  
workshopName, workshopAddress  są nazwą i adresem warsztatu.  
workshopCardNumber  identyfikuje kartę warsztatowa użytą do doko­
nania korekty czasu.  
Generacja 2:
  
Zamiast workshopCardNumber w strukturze danych generacji 2 wyko ­
rzystuje się następujący element danych.  
workshopCardNumberAndGeneration  identyfikuje kartę warsztatowa, 
w tym jej generację, użytą do dokonania korekty czasu.  
2.233.  VuTimeAdjustmentRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
korekt czasu dokonanych poza regularną kalibracją (wymagania 12 4 
i 125 określone w załączniku 1C).
  
recordType  oznacza typ rekordu (VuTimeAdjustmentRecord).  Przypi­
sanie warto ści: zob. RecordType  
recordSize  to wielkość VuTimeAdjustmentRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów korekty czasu.  
2.234.  WorkshopCardApplicationIdentification  
Informacje przechowywane na karcie warsztatowej dotyczące ident yfi­
kacji aplikacji na karcie (wymagania 307 i 330 określone w załą czniku 
1C). 
Generacja 1:
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 220  
typeOfTachographCardId  określa wdrożony typ karty.  
cardStructureVersion  określa wersję struktury wdrożonej na karcie.  
noOfEventsPerType  jest liczbą zdarzeń według typu zdarzenia możli­
wych do zarejestrowania na karcie.  
noOfFaultsPerType  jest liczbą usterek według typu usterki możliwych 
do zarejestrowania na karcie.  
activityStructureLength  podaje liczbę bajtów dostępnych do przecho­
wywania rekordów czynności.  
noOfCardVehicleRecords  jest liczbą rekordów dotyczących pojazdów 
możliwych do zarejestrowania na karcie.  
noOfCardPlaceRecords  jest liczbą miejsc możliwych do zarejestro­
wania na karcie.  
noOfCalibrationRecords  jest liczbą rekordów kalibracyjnych możli­
wych do zarejestrowania na karcie.  
Generacja 2:  
▼M1
 
Oprócz generacji 1 używane są następujące elementy danych:  
noOfGNSSCDRecords  jest liczbą rekordów skumulowanego czasu 
prowadzenia pojazdu z GNSS, które mogą być zapisane na karcie.  
noOfSpecificConditionRecords  jest liczbą rekordów warunków szcze­
gólnych, które mogą być zapisane na karcie.  
noOfCardVehicleUnitRecords  jest liczbą rekordów używanych przy­
rządów rejestrujących, które mogą być zapisane na karcie.  
▼M3 
2.234a.  WorkshopCardApplicationIdentificationV2  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie warsztatowej dotyczące ident yfi­
kacji aplikacji karty (wymóg 330a określony w załączniku IC).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 221
  
lengthOfFollowingData  to liczba kolejnych bajtów we wpisie.  
noOfBorderCrossingRecords  to liczba rekordów dotyczących przekro­
czenia granicy, które mogą być przechowywane na karcie warsztat owej.  
noOfLoadUnloadRecords  to liczba rekordów dotyczących załadunku/ 
rozładunku, które mogą być przechowywane na karcie warsztatowej . 
noOfLoadTypeEntryRecords  to liczba rekordów dotyczących wpisu 
typu załadunku, które mogą być przechowywane na karcie warsztat owej.  
vuConfigurationLengthRange  to liczba bajtów na karcie do tacho­
grafu, dostępnych na potrzeby przechowywania konfiguracji VU.  
2.234b.  WorkshopCardCalibrationAddData  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie warsztatowej dotyczące dodat ko­
wych danych (tj. domyślnego typu załadunku) wprowadzonych podcz as 
kalibracji (wymóg 356l określony w załączniku IC).
  
calibrationPointerNewestRecord  to indeks ostatniego uaktualnionego 
rekordu dodatkowych danych kalibracyjnych.  
Przypisanie warto ści: liczba odpowiadająca stanowi licznika rekordu 
dodatkowych danych kalibracyjnych, rozpoczynając od „0” dla pie rwszego 
wystąpienia w strukturze rekordu dodatkowych danych kalibracyjn ych. 
workshopCardCalibrationAddDataRecords  to zbiór rekordów zawie­
rających starą wartość daty i godziny, wartość identyfikacji po jazdu oraz 
domyślny typ załadunku pojazdu.  
2.234c.  WorkshopCardCalibrationAddDataRecord  
Generacja 2, wersja 2:  
Informacje przechowywane na karcie warsztatowej dotyczące domyś ­
lnego typu załadunku pojazdu wprowadzonego podczas kalibracji 
(wymóg 356k określony w załączniku IC).  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 222
  
oldTimeValue  to stara wartość daty i godziny zawarta w odpowiednim 
rekordzie WorkshopCardCalibrationRecord,  
vehicleIdentificationNumber  to numer identyfikacyjny pojazdu, 
również zawarty w odpowiednim rekordzie WorkshopCardCalibration ­
Record,  
byDefaultLoadType  to domyślny typ załadunku pojazdu (element 
obecny tylko w wersji 2).  
calibrationCountry  to kraj, w którym wykonano kalibrację,  
calibrationCountryTimestamp  to data i godzina przekazania przez 
odbiornik GNSS pozycji wykorzystanej do określenia tego kraju.  
▼B 
2.235.  WorkshopCardCalibrationData  
Informacje przechowywane na karcie warsztatowej dotyczące czynn ości 
warsztatowych wykonanych przy użyciu karty (wymagania 314, 316,  
337 i 339 określone w załączniku 1C).
  
calibrationTotalNumber  jest całkowitą liczbą kalibracji wykonanych 
przy użyciu karty.  
calibrationPointerNewestRecord  jest indeksem ostatniego, uaktualnio­
nego rekordu kalibracyjnego.  
Przypisanie warto ści: liczba odpowiadającą licznikowi rekordów kalib­
racyjnych, rozpoczynając od „0” dla pierwszego wystąpienia reko rdu 
kalibracyjnego w strukturze.  
calibrationRecords  jest zbiorem rekordów zawierających informacje 
o kalibracji lub korekcie czasu.  
2.236.  WorkshopCardCalibrationRecord  
Informacje przechowywane na karcie warsztatowej dotyczące czynn ości 
wykonanych przy użyciu karty (wymagania 314 i 337 określone 
w załączniku 1C).  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 223  
Generacja 1:
  
calibrationPurpose  jest celem kalibracji.  
vehicleIdentificationNumber  jest numerem VIN.  
vehicleRegistration  zawiera numer VRN i państwa członkowskiego 
rejestracji.  
wVehicleCharacteristicConstant  jest współczynnikiem charaktery­
stycznym pojazdu.  
kConstantOfRecordingEquipment  jest stałą urządzenia rejestrującego.  
lTyreCircumference  jest obwodem tocznym kół.  
tyreSize  jest oznaczeniem rozmiarów opon zamontowanych w pojeź­
dzie.  
authorisedSpeed  jest maksymalną, dozwoloną prędkością pojazdu.  
oldOdometerValue, newOdometerValue  są starym i nowym stanem 
licznika kilometrów.  
oldTimeValue, newTimeValue  są starą i nową wartością daty 
i godziny.  
nextCalibrationDate  jest datą następnej kalibracji typu określonego 
w CalibrationPurpose, którą powinien przeprowadzić autoryzowany  
organ kontrolny.  
vuPartNumber , vuSerialNumber  and sensorSerialNumber  są elemen­
tami danych do identyfikacji urządzenia rejestrującego.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 224  
Generacja 2:
  
Oprócz generacji 1 używane są następujące elementy danych:  
sensorGNSSSerialNumber , który identyfikuje urządzenie zewnętrzne 
GNSS.  
rcmSerialNumber , który identyfikuje moduł komunikacji na odległość.  
sealDataCard  podaje informacje o plombach przymocowanych do 
różnych części pojazdu.  
2.237.  WorkshopCardHolderIdentification  
Informacje przechowywane na karcie warsztatowej dotyczące ident yfikacji 
posiadacza karty (wymagania 311 i 334 określone w załączniku 1C ).
 
workshopName  jest nazwą warsztatu posiadacza karty.  
workshopAddress jest adresem warsztatu posiadacza karty.  
cardHolderName  jest nazwiskiem i imieniem (imionami) posiadacza 
karty (np. nazwiskiem mechanika).  
cardHolderPreferredLanguage  jest preferowanym językiem posiadacza 
karty.  
2.238.  WorkshopCardPIN  
Osobisty numer identyfikacyjny (PIN) karty warsztatowej (wymaga nie 
309 i 332 określone w załączniku 1C).
  
Przypisanie warto ści: PIN znany posiadaczowi karty, z prawej strony 
wypełniony bajtami o wartości „FF” aż do 8 bajtów.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 225  
2.239.  W-VehicleCharacteristicConstant  
Współczynnik charakterystyczny pojazdu (definicja k)).
  
Przypisanie warto ści: liczba impulsów na kilometr w zakresie opera­
cyjnym 0 do 64 255 impulsów/km.  
2.240.  VuPowerSupplyInterruptionRecord  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące 
zdarzeń przerwy w zasilaniu (wymaganie 117 określone w załączni ku 
1C).
 
eventType  jest typem zdarzenia.  
eventRecordPurpose  jest celem, dla którego zarejestrowano to 
zdarzenie.  
eventBeginTime  jest datą i godziną rozpoczęcia zdarzenia.  
eventEndTime  jest datą i godziną zakończenia zdarzenia.  
cardNumberAndGenDriverSlotBegin  identyfikuje kartę, w tym jej 
generację, włożoną do szczeliny karty kierowcy na początku zdar zenia.  
cardNumberAndGenDriverSlotEnd  identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny karty kierowcy na końcu zdarzenia.  
cardNumberAndGenCodriverSlotBegin  identyfikuje kartę, w tym jej 
generację, włożoną do szczeliny karty współkierowcy na początku  
zdarzenia.  
cardNumberAndGenCodriverSlotEnd  identyfikuje kartę, w tym jej 
generację, włożoną do szczeliny karty współkierowcy na końcu 
zdarzenia.  
similarEventsNumber  jest liczbą podobnych zdarzeń w tym dniu.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 226  
2.241.  VuPowerSupplyInterruptionRecordArray  
Generacja 2:  
Informacje przechowywane w przyrządzie rejestrującym dotyczące zdarzeń 
przerwy w zasilaniu (wymaganie 117 określone w załączniku 1C).
  
recordType  oznacza typ rekordu (VuPowerSupplyInterruptionRecord).  
Przypisanie warto ści: zob. RecordType  
recordSize  to wielkość VuPowerSupplyInterruptionRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów zdarzeń przerwy w zasilaniu.  
2.242.  VuSensorExternalGNSSCoupledRecordArray  
Generacja 2:  
Zbiór zapisów SensorExternalGNSSCoupledRecord wraz z metadanymi  
stosowany w protokole pobierania danych.
  
recordType  oznacza typ rekordu (SensorExternalGNSSCoupledRecord).  
Przypisanie warto ści: zob. RecordType  
recordSize  to wielkość SensorExternalGNSSCoupledRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów SensorExternalGNSSCoupled.  
2.243.  VuSensorPairedRecordArray  
Generacja 2:  
Zbiór zapisów SensorPairedRecord wraz z metadanymi stosowany 
w protokole pobierania danych.
  
recordType  oznacza typ rekordu (SensorPairedRecord).  Przypisanie 
wartości: zob. RecordType  
recordSize  to wielkość SensorPairedRecord w bajtach.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 227  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów sparowanego czujnika.  
3. DEFINICJE WARTOŚCI I ZAKRESU WIELKOŚCI  
Definicja wartości zmiennych używana w definicjach w ust. 2.
  
4. ZESTAW ZNAKÓW:  
W łańcuchach IA5Strings używa się znaków ASCII zdefiniowanych 
w normie ISO/IEC 8824-1. Na potrzeby czytelności i łatwego odwo ły­
wania się poniżej podano przypisanie wartości. W przypadku rozb ież­
ności między tą uwagą a normą obowiązują przepisy normy ISO/IEC  
8824-1.
  
W innych łańcuchach znaków (Address, Name, VehicleRegistration­
Number) używa się dodatkowo znaków zdefiniowanych kodami od 161  
do 255 następujących 8-bitowych standardowych zestawów znaków, 
określonych numerem Code Page: 
Standardowy zestaw znaków  Code Page 
(dziesiętny)  
ISO/IEC 8859-1 Latin-1 – dla Europy Zachodniej  1  
ISO/IEC 8859-2 Latin-2 – dla Europy Środkowej i Wschodniej  2  
ISO/IEC 8859-3 Latin-3 – dla Europy Południowej  3  
ISO/IEC 8859-5 Latin – dla cyrylicy  5  
ISO/IEC 8859-7 Latin – dla alfabetu greckiego  7  
ISO/IEC 8859-9 Latin-5 – dla alfabetu tureckiego  9  
ISO/IEC 8859-13 Latin-7 – dla krajów bałtyckich  1 3  
ISO/IEC 8859-15 Latin-9  1 5  
ISO/IEC 8859-16 Latin-10 – dla Europy Południowo-Wschod­
niej 16 
KOI8-R Latin – dla cyrylicy  8 0  
KOI8-U Latin – dla cyrylicy  8 5  
5. KODOWANIE  
Przy kodowaniu zgodnie z zasadami ASN.1, wszystkie zdefiniowane  
typy danych koduje się zgodnie z wariantem unormowanym w ISO/IE C 
8825-2.  
6. IDENTYFIKATORY OBIEKTU I IDENTYFIKATORY APLIKACJI  
6.1. Identyfikatory obiektu  
Identyfikatory obiektu (OID) wymienione w niniejszym rozdziale mają 
zastosowanie wyłącznie do generacji 2. Takie OID wyszczególnion o ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 228  
w TR-03110-3 i powtórzono dla kompletności wywodu. Takie OID 
zawarto w poddrzewie bsi-de:
  
Identyfikatory protoko łu uwierzytelnienia VU
  
Przykład: Załóżmy, że należy dokonać uwierzytelnienia VU za pomocą 
SHA-384, wtedy identyfikatorem obiektu, który należy użyć jest (w składni 
ASN.1)
  .  
Wartość tego identyfikatora obiektu w zapisie kropkowym wynosi
  
. 
Zapis kropkowy  Zapis bajtowy
  
„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”  
Identyfikatory protoko łu uwierzytelnienia z chipem
  
Przykład: Przypuśćmy, że uwierzytelnienie chipu ma zostać doko­
nane za pomocą algorytmu ECDH, co daje długość klucza sesji 
AES 128 bitów. Ten klucz sesji zostanie następnie wykorzystany 
w trybie pracy CBC w celu zapewnienia poufności danych i z algo ­
rytmem CMAC w celu zapewnienia autentyczności danych. Zatem 
identyfikatorem obiektu, który należy użyć jest (w składni ASN. 1)
 
. Wartość 
tego identyfikatora obiektu w zapisie kropkowym wynosi
  
. 
Zapis kropkowy  Zapis bajtowy
  
„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 — PL — 21.08.2023 — 003.001 — 229  
6.2. Identyfikatory aplikacji  
Generacja 2:  
Identyfikator aplikacji (AID) dla urządzenia zewnętrznego GNSS (gene­
racja 2) jest określony za pomocą „FF 44 54 45 47 4D”. Jest to zastrze­ 
żony AID zgodny z normą ISO/IEC 7816-4.  
Uwaga:  5 ostatnich bajtów koduje DTEGM dla urządzenia zewnętrz­
nego GNSS tachografu inteligentnego.  
Identyfikator aplikacji dla aplikacji kart do tachografów gener acji 2 jest 
określony za pomocą „FF 53 4D 52 44 54”. Jest to zastrzeżony AI D 
zgodny z normą ISO/IEC 7816-4.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 230  
Dodatek 2  
SPECYFIKACJA KART DO TACHOGRAFÓW  
SPIS TREŚCI  
1. WPROWADZENIE  
1.1. Skróty  
1.2. Odniesienia  
2. CHARAKTERYSTYKI ELEKTRYCZNE I FIZYCZNE  
2.1. Napięcie zasilające i pobór prądu  
2.2. Napięcie programowania V  pp 
2.3. Generowanie i częstotliwość zegara  
2.4. Styk we/wy  
2.5. Stany karty  
3. SPRZĘT I KOMUNIKACJA  
3.1. Wprowadzenie  
3.2. Protokół komunikacyjny  
3.2.1 Protokoły  
3.2.2 ATR  
3.2.3 PTS  
3.3. Zasady dostępu  
3.4. Przegląd poleceń i kodów błędów  
3.5. Opisy poleceń  
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 — PL — 21.08.2023 — 003.001 — 231  
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE  
3.5.15 PSO: VERIFY DIGITAL SIGNATURE  
3.5.16 PROCESS DSRC MESSAGE  
4. STRUKTURA KART DO TACHOGRAFÓW  
4.1. Plik główny MF  
4.2. Aplikacje karty kierowcy  
4.2.1 Aplikacja karty kierowcy 1. generacji  
4.2.2 Aplikacja karty kierowcy 2. generacji  
4.3. Aplikacje karty warsztatowej  
4.3.1 Aplikacja karty warsztatowej 1. generacji  
4.3.2 Aplikacja karty warsztatowej 2. generacji  
4.4. Aplikacje karty kontrolnej  
4.4.1 Aplikacja karty kontrolnej 1. generacji  
4.4.2 Aplikacja karty kontrolnej 2. generacji  
4.5. Aplikacje karty firmowej  
4.5.1 Aplikacja karty firmowej 1. generacji  
4.5.2 Aplikacja karty firmowej 2. generacji  
1. WPROWADZENIE  
1.1. Skróty  
Do celów niniejszego dodatku stosuje się poniższe skróty.  
AC [Access conditions] warunki dostępu  
AES [Advanced Encryption Standard] zaawansowany standard 
szyfrowania  
AID [Application Identifier] identyfikator aplikacji  
ALW [Always] zawsze  
APDU [Application Protocol Data Unit] jednostka danych proto­
kołu aplikacji (struktura polecenia)  
ATR [Answer To Reset] reakcja na sprowadzenie do stanu 
wyjściowego  
AUT [Authenticated] uwierzytelniony  
C6, C7 styki 6 i 7 karty opisane w normie ISO/IEC 7816-2  
cc [clock cycles] cykle zegarowe  
▼M1 
CHA upoważnienie posiadacza certyfikatu  
▼B 
CHV [Card holder Verification Information] informacje weryfi­
kacyjne posiadacza karty  
CLA bajt klasy w poleceniu APDU  
▼M1 
DO obiekt danych  
▼B 
DSRC [Dedicated Short Range Communication] wydzielona 
łączność krótkiego zasięgu  
DF [Dedicated File] plik dedykowany. DF może zawierać 
inne pliki (EF lub DF)  
ECC [Elliptic Curve Cryptography] kryptografia krzywych 
eliptycznych  
EF [Elementary File] plik elementarny  
etu [elementary time unit] elementarna jednostka czasu  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 232  
G1 [Generation 1] 1. generacja  
G2 [Generation 2] 2. generacja  
IC [Integrated Circuit] układ scalony  
ICC [Integrated Circuit Card] karta z układem scalonym  
ID [Identifier] identyfikator  
IFD [Interface Device] urządzenie interfejsu  
IFS [Information Field Size] wielkość pola informacyjnego  
IFSC [Information Field Size for the card] wielkość pola infor­
macyjnego dla karty  
IFSD [Information Field Size Device] wielkość pola informa­
cyjnego urządzenia (dla terminala)  
INS bajt instrukcji w poleceniu APDU  
Lc długość danych wejściowych dla polecenia APDU  
Le długość danych oczekiwanych (dane wyjściowe dla pole­
cenia)  
MF [Master File] plik główny (root DF)  
NAD [Node Address] adres węzła używany w protokole T=1  
NEV [Never] nigdy  
P1-P2 bajty parametryczne  
PIN [Personal Identification Number] osobisty numer identy­
fikacyjny  
PRO SM [Protected with secure messaging] chroniony z bezpieczną  
wymianą komunikatów  
PTS [Protocol Transmission Selection] wybór protokołu komu­
nikacyjnego  
RFU [Reserved for Future Use] zastrzeżone do wykorzystania 
w przyszłości  
RST [Reset] sprowadzenie do stanu wyjściowego (karty)  
SFID [Short EF Identifier] krótki identyfikator EF  
SM [Secure Messaging] bezpieczna wymiana komunikatów  
SW1-SW2 bajty stanu  
TS początkowy znak ATR  
VPP napięcie programowania  
VU [Vehicle Unit] przyrząd rejestrujący  
XXh wartość XX w zapisie heksadecymalnym  
„XXh” wartość XX w zapisie heksadecymalnym  
|| symbol konkatenacji 03||04=0304  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 233  
1.2. Odniesienia  
W niniejszym dodatku stosuje się następujące odniesienia:  
ISO/IEC 7816-2 Karty identyfikacyjne – Karty z układami scalo­
nymi – część 2: Wymiary i rozmieszczenie styków. 
ISO/IEC 7816-2:2007.  
ISO/IEC 7816-3 Karty identyfikacyjne – Karty z układami scalo­
nymi – część 3: Złącze elektryczne i protokoły 
komunikacyjne. ISO/IEC 7816-3:2006.  
ISO/IEC 7816-4 Karty identyfikacyjne – Karty z układami scalo­
nymi – część 4: Organizacja, zabezpieczenia i pole­
cenia wymiany. ISO/IEC 7816-4:2013 + Cor 1: 
2014.  
ISO/IEC 7816-6 Karty identyfikacyjne – Karty z układami scalo­
nymi – część 6: Międzybranżowe elementy danych 
do wymiany. ISO/IEC 7816-6:2004 + Cor 1: 2006.  
ISO/IEC 7816-8 Karty identyfikacyjne – Karty z układami scalo­
nymi – część 8: Polecenia operacji zabezpieczają­
cych. ISO/IEC 7816-8:2004.  
ISO/IEC 9797-2 Technologia informatyczna – Techniki zabezpie­
czeń – Kody uwierzytelniania wiadomości (MAC) 
– część 2: Mechanizmy wykorzystujące funkcję 
haszującą. ISO/IEC 9797-2:2011  
2. CHARAKTERYSTYKI ELEKTRYCZNE I FIZYCZNE  
TCS_01 Wszystkie sygnały elektryczne muszą być zgodne z normą 
ISO/IEC 7816-3, chyba że określono inaczej.  
TCS_02 Rozmieszczenie i wymiary styków kart muszą być zgodne 
z normą ISO/IEC 7816-2.  
2.1. Napi ęcie zasilaj ące i pobór pr ądu 
TCS_03 Karta pracuje zgodnie ze specyfikacją przy poborze w gra ni­
cach określonych w normie ISO/IEC 7816-3.  
TCS_04 Karta pracuje z Vcc = 3V (± 0,3V) bądź z Vcc = 5V 
(± 0,5V).  
Wybór napięcia odbywa się zgodnie z normą ISO/IEC 
7816-3.  
2.2. Napi ęcie programowania V  pp 
TCS_05 Karta nie wymaga napięcia programowania na pinie C6. 
Oczekuje się, że pin C6 nie jest przyłączony w IFD. 
Styk C6 może być przyłączony do V  cc na karcie, ale nie 
może być przyłączony do masy. W żadnym przypadku 
napięcie to nie może być interpretowane.  
2.3. Generowanie i cz ęstotliwość zegara  
TCS_06 Karta pracuje w zakresie częstotliwości 1–5 MHz i może 
obsługiwać wyższe częstotliwości. W czasie jednej sesji 
karty częstotliwość zegara może zmieniać się w granicach 
± 2 %. Częstotliwość zegara generowana jest przez przy­
rząd rejestrujący, a nie przez kartę. Cykl pracy może zmie­
niać się w granicach 40–60 %.  
TCS_07 W warunkach określonych na karcie w pliku EF ICC 
zewnętrzny zegar może zostać zatrzymany. Pierwszy bajt 
treści pliku EF ICC koduje warunki trybu pracy Clockstop:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 234  
Niski  Wysoki  
Bit 3  Bit 2  Bit 1  
0 0  1  Clockstop dozwolony, brak preferowanego 
poziomu  
0 1  1  Clockstop dozwolony, preferowany poziom 
wysoki  
1 0  1  Clockstop dozwolony, preferowany poziom niski  
0 0  0  Clockstop niedozwolony  
0 1  0  Clockstop dozwolony tylko przy wysokim 
poziomie  
1 0  0  Clockstop dozwolony tylko przy niskim poziomie  
Bitów od 4 do 8 nie używa się.  
2.4. Styk we/wy  
TCS_08 Styk we/wy C7 służy do odbierania i wysyłania danych do 
IFD. W czasie pracy tylko karta albo tylko IFD jest w trybie 
nadawania. Gdyby jednak obie jednostki jednocześnie 
znalazły się w trybie nadawania, nie może to spowodować 
uszkodzenia karty. Karta wchodzi do trybu odbioru, chyba 
że nadaje dane.  
2.5. Stany karty  
TCS_09 Gdy podawane jest napięcie zasilające, karta pracuje 
w dwóch stanach:  
▼M3 
stan operacyjny, w którym karta wykonuje polecenia lub 
jest połączona z przyrządem rejestrującym;  
▼B 
stan jałowy we wszystkich pozostałych sytuacjach (w tym 
stanie karta zachowuje wszystkie dane).  
3. SPRZĘT I KOMUNIKACJA  
3.1. Wprowadzenie  
W punkcie tym opisano minimalną funkcjonalność wymaganą od kart  
do tachografów i VU w celu zagwarantowania prawidłowego funk­
cjonowania i interoperacyjności.  
Karty do tachografów muszą być zgodne, w największym możliwym 
stopniu, z obowiązującymi normami ISO/IEC (w szczególności 
z normą ISO/IEC 7816). Niemniej jednak szczegółowo opisano pole ­
cenia i protokoły w celu określenia niektórych ograniczonych za sto­
sowań lub różnic, o ile takie występują. Opisane polecenia są w  pełni 
zgodne z przywołanymi normami, jeżeli nie wskazano inaczej.  
3.2. Protokó ł komunikacyjny  
TCS_10 Protokół komunikacyjny musi być zgodny z normą 
ISO/IEC 7816-3 dla T = 0 oraz T = 1. W szczególności 
VU musi rozpoznawać wysyłane przez kartę przedłużenia 
czasu oczekiwania.  
3.2.1  Protoko ły 
TCS_11 Karta obsługuje zarówno protokół  T = 0 , jak i protokół  
T=1. Karta może ponadto obsługiwać dodatkowe protokoły 
zorientowane kontaktowo.  
TCS_12  T = 0  jest protokołem domyślnym, dlatego też polecenie  
PTS jest niezbędne do zmiany protokołu na  T = 1 . ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 235  
TCS_13 Urządzenia wykorzystują  konwencj ę bezpośrednią w obu 
protokołach: w związku z tym konwencja bezpośrednia jest 
obowiązkowa dla karty.  
TCS_14 Bajt  karty informacyjnej wielko ści pola  przedstawiony 
jest na ATR pod oznaczeniem TA3. Wartość ta jest nie 
mniejsza niż „F0h” (= 240 bajtów).  
Do protokołów stosuje się następujące ograniczenia:  
TCS_15  T=0  
— Urządzenie interfejsu wspiera odpowiedź na we/wy po 
wzroście krawędzi narastającego sygnału na RST z 400 
cc. 
— Urządzenie interfejsu potrafi odczytać znaki rozdzielone 
12 etu.  
— Urządzenie interfejsu odczytuje błędny znak i jego 
powtórzenie, jeżeli rozdzielone 13 etu. W przypadku 
wykrycia błędnego znaku na we/wy może pojawić się 
sygnał błędu między 1 etu a 2 etu. Urządzenie obsłu­
guje opóźnienie 1 etu.  
— Urządzenie interfejsu akceptuje 33-bajtowe ATR 
(TS + 32)  
— Jeżeli TC1 znajduje się w ATR, to dla znaków wysy­ 
łanych przez urządzenie interfejsu jest dodatkowy czas 
ochronny (Extra Guard Time), chociaż znaki wysyłane 
przez kartę mogą być jeszcze przedzielone odstępami 
12 etu. Odnosi się to także do znaku ACK wysyłanego 
przez kartę po wysłaniu znaku P3 przez urządzenie 
interfejsu.  
— Urządzenie interfejsu bierze pod uwagę znak NUL 
wysyłany przez kartę.  
— Urządzenie interfejsu akceptuje tryb uzupełniający dla 
ACK.  
— Polecenia odbierz-odpowiedź (get-response) nie można 
używać w trybie łańcuchowym do otrzymywania 
danych, których długość może być większa niż 255 
bajtów.  
TCS_16  T=1  
— Bajt NAD: nieużywany (NAD ustawia się na „00”).  
— S-block ABORT: nieużywany.  
— Błąd stanu S-block VPP: nieużywany.  
▼M3 __________  
▼B 
— IFD bezpośrednio po ATR podaje wielkość pola infor­
macyjnego dla urządzenia (IFSD): IFD wysyła żądanie 
S-Block IFS po ATR, a karta odpowiada S-Block IFS. 
Zalecaną wartością dla IFSD są 254 bajty.  
— Karta nie pyta o skorygowane IFS.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 236  
3.2.2  ATR  
TCS_17 Urządzenie sprawdza bajty ATR, zgodnie z normą ISO/IEC 
7816-3. Nie wykonuje się weryfikacji znaków historycz­
nych ATR.  
Przykład podstawowego Biprotocol ATR zgodnego 
z normą ISO/IEC 7816-3  
Znak  Wartość  Uwagi  
TS „3Bh”  wskazuje konwencję bezpośrednią  
T0 „85h”  TD1 obecny; jest 5 bajtów historycznych  
TD1 „80h”  TD2 obecny; będzie użyty T=0  
TD2 „11h”  TA3 obecny; będzie użyty T=1  
TA3 „XXh” (min. „F0h”)  wielkość pola informacyjnego dla karty (IFSC)  
TH1–TH5  „XXh”  znaki historyczne  
TCK  „XXh”  znak kontrolny (exclusive OR)  
TCS_18 Po ATR wybierany jest domyślnie plik główny (MF) i staje  
się katalogiem bieżącym.  
3.2.3  PTS  
TCS_19 Domyślnym protokołem jest T=0. Aby wybrać protokół 
T=1, urządzenie musi wysłać do karty PTS (znane też 
jako PPS).  
TCS_20 Ponieważ oba protokoły T=0 i T=1 są wymagane dla karty, 
podstawowy PTS do przełączania między protokołami jest 
obowiązkowy dla karty.  
PTS można używać, jak wskazano w normie ISO/IEC 
7816-3, do przełączania na szybkości transmisji większe 
niż standardowa, proponowane przez kartę w ATR, jeżeli 
dotyczy (bajt TA(1)).  
Większe szybkości transmisji są opcjonalne dla karty.  
TCS_21 Jeżeli karta nie obsługuje innej szybkości transmisji ni ż 
standardowa (lub jeżeli nie obsługuje wybranej szybkości 
transmisji), karta musi prawidłowo odpowiadać na PTS, 
zgodnie z normą ISO/IEC 7816-3, opuszczając bajt PPS1.  
Poniżej pokazano przykłady podstawowego PTS do 
wyboru protokołu:  
Znak  Wartość  Uwagi  
PPSS  „FFh”  znak inicjujący  
PPS0  „00h” lub „01h”  nie ma PPS1 do PPS3; „00h”, aby wybrać T0, „01h”, aby 
wybrać T1  
PK „XXh”  znak kontrolny: „XXh” = „FFh”, jeżeli PPS0 = „00h”, 
„XXh” = „FEh”, jeżeli PPS0 = „01h”.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 237  
3.3. Zasady dost ępu 
TCS_22 Zasada dostępu określa odpowiednie warunki zabezpie­
czenia dla danego trybu dostępu, tj. polecenia. Jeżeli przed­
miotowe warunki zabezpieczenia są spełnione, odpo­
wiednie polecenie jest przetwarzane.  
TCS_23 Następujące warunki zabezpieczenia są stosowane na 
potrzeby karty do tachografu:  
Skrót  Znaczenie  
ALW  Operacja jest zawsze możliwa i może być wykonywana bez ogranic zeń. 
Polecenie i odpowiedź APDU są wysyłane w postaci zwykłego tekst u, tzn. 
bez bezpiecznej wymiany komunikatów.  
NEV  Operacja nie jest nigdy możliwa.  
PLAIN-C  Polecenie APDU jest wysyłane w postaci zwykłego tekstu, tzn. b ez 
bezpiecznej wymiany komunikatów.  
PWD  Działanie może zostać zrealizowane, wyłącznie jeżeli PIN karty  warsztatowej 
został pomyślnie zweryfikowany, tzn. jeżeli stan zabezpieczenia  wewnętrz­
nego karty ma status „PIN_Verified”. Polecenie musi być przesła ne bez 
bezpiecznej wymiany komunikatów.  
EXT-AUT-G1  Działanie może zostać zrealizowane, wyłącznie jeżeli polecenie  External 
Authenticate dla uwierzytelnienia 1. generacji (zob. także doda tek 11 część 
A) zostało pomyślnie wykonane.  
SM-MAC-G1  Polecenie i odpowiedź APDU muszą być stosowane z bezpieczną wy mianą 
komunikatów 1. generacji w trybie tylko uwierzytelnienia (zob. dodatek 11 
część A).  
SM-C-MAC-G1  Polecenie APDU musi być stosowane z bezpieczną wymianą komunik atów 1. 
generacji w trybie tylko uwierzytelnienia (zob. dodatek 11 częś ć A).  
SM-R-ENC-G1  Odpowiedź APDU musi być stosowana z bezpieczną wymianą komunik atów 
1. generacji w trybie szyfrowania (zob. dodatek 11 część A), tz n. bez zwra­
cania kodu uwierzytelnienia wiadomości.  
SM-R-ENC- 
MAC-G1  Odpowiedź APDU musi być stosowana z bezpieczną wymianą komunika tów 1. 
generacji w trybie szyfrowania i uwierzytelnienia (zob. dodatek  11 część A).  
SM-MAC-G2  Polecenie i odpowiedź APDU muszą być stosowane z bezpieczną wy mianą 
komunikatów 2. generacji w trybie tylko uwierzytelnienia (zob. dodatek 11 
część A).  
SM-C-MAC-G2  Polecenie APDU musi być stosowane z bezpieczną wymianą komunik atów 2. 
generacji w trybie tylko uwierzytelnienia (zob. dodatek 11 częś ć A).  
SM-R-ENC- 
MAC-G2  Odpowiedź APDU musi być stosowana z bezpieczną wymianą komunika tów 2. 
generacji w trybie szyfrowania i uwierzytelnienia (zob. dodatek  11 część A).  
▼M1 
TCS_24 Przedmiotowe warunki zabezpieczenia mogą być powią­
zane ze sobą w następujący sposób:  
AND : muszą zostać spełnione wszystkie warunki zabezpie­
czenia  
OR: musi zostać spełniony przynajmniej jeden warunek 
zabezpieczenia  
Zasady dostępu dla systemu plików, tzn. polecenia 
SELECT, READ BINARY oraz UPDATE BINARY, 
zostały określone w rozdziale 4. Zasady dostępu dla pozos­
tałych poleceń zostały określone w poniższych tabelach. 
Określenie „nie dotyczy” jest stosowane w przypadku 
braku wymogu obsługi danego polecenia. W takim przy­
padku polecenie może być lub nie być obsługiwane, ale 
warunek dostępu jest wyłączony z zakresu zastosowania.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 238  
TCS_25 W przypadku aplikacji DF Tachograph G1 zastosowanie 
mają następujące zasady dostępu:  
▼M1 
Polecenie  Karta kierowcy  Karta warsz­
tatowa  Karta kontrolna  Karta firmowa  
External Authenticate  
— dla uwierzytelnienia 1. gene­
racji ALW  ALW  ALW  ALW  
— dla uwierzytelnienia 2. gene­
racji 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  nie dotyczy  nie dotyczy  nie dotyczy  nie dotyczy  
PSO: Compute Digital Signature  ALW OR 
SM-MAC- 
G2 ALW OR 
SM-MAC- 
G2 nie dotyczy  nie dotyczy  
PSO: Hash  nie dotyczy  nie dotyczy  ALW  nie dotyczy  
PERFORM HASH of FILE  ALW OR 
SM-MAC- 
G2 ALW OR 
SM-MAC- 
G2 nie dotyczy  nie dotyczy  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  nie dotyczy  nie dotyczy  ALW  nie dotyczy  
Verify  nie dotyczy  ALW  nie dotyczy  nie dotyczy  
▼B 
TCS_26 W przypadku aplikacji DF Tachograph_G2 zastosowanie 
mają następujące zasady dostępu:  
▼M1 
Polecenie  Karta kierowcy  Karta warsz­
tatowa  Karta kontrolna  Karta firmowa  
External Authenticate  
— dla uwierzytelnienia 1. 
generacji  nie dotyczy  nie dotyczy  nie dotyczy  nie dotyczy  
— dla uwierzytelnienia 2. 
generacji  ALW  PWD  ALW  ALW  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 239  
Polecenie  Karta kierowcy  Karta warsz­
tatowa  Karta kontrolna  Karta firmowa  
Internal Authenticate  nie dotyczy  nie dotyczy  nie dotyczy  nie dotyczy  
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  nie dotyczy  ALW  ALW  nie dotyczy  
PSO: Compute Digital Signature  ALW OR 
SM-MAC- 
G2 ALW OR 
SM-MAC- 
G2 nie dotyczy  nie dotyczy  
PSO: Hash  nie dotyczy  nie dotyczy  ALW  nie dotyczy  
PERFORM HASH of FILE  ALW OR 
SM-MAC- 
G2 ALW OR 
SM-MAC- 
G2 nie dotyczy  nie dotyczy  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  nie dotyczy  nie dotyczy  ALW  nie dotyczy  
Verify  nie dotyczy  ALW  nie dotyczy  nie dotyczy  
▼B 
TCS_27 W przypadku MF zastosowanie mają następujące zasady 
dostępu:  
▼M1 
Polecenie  Karta kierowcy  Karta warsz­
tatowa  Karta kontrolna  Karta firmowa  
External Authenticate  
— dla uwierzytelnienia 1. 
generacji  nie dotyczy  nie dotyczy  nie dotyczy  nie dotyczy  
— dla uwierzytelnienia 2. 
generacji  ALW  PWD  ALW  ALW  
Internal Authenticate  nie dotyczy  nie dotyczy  nie dotyczy  nie dotyczy  
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 — PL — 21.08.2023 — 003.001 — 240  
Polecenie  Karta kierowcy  Karta warsz­
tatowa  Karta kontrolna  Karta firmowa  
Process DSRC Message  nie dotyczy  nie dotyczy  nie dotyczy  nie dotyczy  
PSO: Compute Digital Signature  nie dotyczy  nie dotyczy  nie dotyczy  nie dotyczy  
PSO: Hash  nie dotyczy  nie dotyczy  nie dotyczy  nie dotyczy  
PERFORM HASH of FILE  nie dotyczy  nie dotyczy  nie dotyczy  nie dotyczy  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  nie dotyczy  nie dotyczy  nie dotyczy  nie dotyczy  
Verify  nie dotyczy  ALW  nie dotyczy  nie dotyczy  
▼B 
TCS_28 Karta do tachografu może, ale nie musi przyjmować 
poleceń z wyższego poziomu zabezpieczenia niż poziom 
określony w warunkach zabezpieczenia. Tzn. jeżeli warun­
kiem zabezpieczenia jest ALW (lub PLAIN-C), karta może 
przyjąć polecenie z bezpieczną wymianą komunikatów 
(w trybie szyfrowania lub uwierzytelnienia). Jeżeli warunek 
zabezpieczenia wymaga bezpiecznej wymiany komuni­
katów w trybie uwierzytelnienia, karta do tachografu 
może przyjąć polecenie z bezpieczną wymianą komuni­
katów tej samej generacji w trybie uwierzytelnienia i szyf­
rowania.  
Uwaga:  Opisy poleceń dostarczają więcej informacji na 
temat obsługi poleceń dla poszczególnych typów kart do 
tachografów oraz poszczególnych DF.  
3.4. Przegl ąd poleceń i kodów b łędów 
Polecenia i organizacja pliku wynikają z normy ISO/IEC 7816-4 
i spełniają jej wymagania.  
W tej sekcji opisano poniższe pary polecenie-odpowiedź dla APDU . 
Warianty poleceń, które są obsługiwane przez aplikacje 1. i 2. gene­
racji, zostały określone w odpowiednich opisach poleceń.  
Polecenie  INS  
SELECT  „A4h”  
READ BINARY  „B0h”, „B1h”  
UPDATE BINARY  „D6h”, „D7h”  
GET CHALLENGE  „84h”  
VERIFY  „20h”  
GET RESPONSE  „C0h”  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 241  
Polecenie  INS  
PERFORM SECURITY OPERA­
TION  „2Ah”  
— VERIFY CERTIFICATE  
— COMPUTE DIGITAL SIGNA­
TURE  
— VERIFY DIGITAL SIGNA­
TURE  
— HASH  
— PERFORM HASH OF FILE  
— PROCESS DSRC MESSAGE  
INTERNAL AUTHENTICATE  „88h”  
EXTERNAL AUTHENTICATE  „82h”  
MANAGE SECURITY ENVIRON­
MENT  „22h”  
— SET DIGITAL SIGNATURE 
TEMPLATE  
— SET AUTHENTICATION 
TEMPLATE  
GENERAL AUTHENTICATE  „86h”  
▼M1 
TCS_29 Słowa stanu SW1 i SW2 są zwracane w komunikacie 
odpowiedzi i oznaczają stan przetwarzania polecenia.  
SW1  SW2  Znaczenie  
90 0 0  Normalne przetwarzanie.  
61 X X  Normalne przetwarzanie. XX = liczba dostępnych bajtów 
odpowiedzi.  
62 8 1  Przetwarzanie ostrzeżenia. Część zwracanych danych może być 
uszkodzona  
63 0 0  Nieudane uwierzytelnienie (ostrzeżenie)  
63 C X  Nieprawidłowe CHV (PIN). „X” oznacza licznik pozostałych 
prób.  
64 0 0  Błąd wykonania – Stan pamięci nieulotnej bez zmian. Błąd inte­
gralności.  
65 0 0  Błąd wykonania – Stan pamięci nieulotnej zmieniony  
65 8 1  Błąd wykonania – Stan pamięci nieulotnej zmieniony – Uszko­
dzona pamięć  
66 8 8  Błąd zabezpieczenia: nieprawidłowa kryptograficzna suma 
kontrolna (w czasie bezpiecznej wymiany 
komunikatów) lub 
nieprawidłowy certyfikat (w czasie wery­
fikacji certyfikatu) lub 
nieprawidłowy kryptogram (w czasie 
zewnętrznego uwierzytelnienia) lub 
nieprawidłowy podpis (w czasie weryfi­
kacji podpisu)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 242  
SW1  SW2  Znaczenie  
67 0 0  Nieprawidłowa długość (nieprawidłowe Lc lub Le)  
68 8 3  Oczekiwane ostatnie polecenie łańcucha  
69 0 0  Niedozwolone polecenie (brak dostępnej odpowiedzi w T=0)  
69 8 2  Niespełniony stan zabezpieczenia.  
69 8 3  Metoda uwierzytelnienia zablokowana.  
69 8 5  Warunki użycia niespełnione.  
69 8 6  Polecenie niedozwolone (brak bieżącego EF).  
69 8 7  Brak oczekiwanych obiektów danych w bezpiecznej wymianie 
komunikatów  
69 8 8  Nieprawidłowe obiekty danych w bezpiecznej wymianie komu­
nikatów  
6A 8 0  Nieprawidłowe parametry w polu danych  
6A 8 2  Nie znaleziono pliku.  
6A 8 6  Nieprawidłowe parametry P1-P2.  
6A 8 8  Nie znaleziono powołanych danych.  
6B 0 0  Nieprawidłowe parametry (przesunięcie poza EF).  
6C X X  Nieprawidłowa długość, SW2 wskazuje dokładną długość. Pole 
danych nie jest zwracane.  
6D 0 0  Kod instrukcji nieobsługiwany lub nieważny.  
6E 0 0  Klasa nieobsługiwana.  
6F 0 0  — Inne błędy kontroli  
Dodatkowe słowa stanu zdefiniowane w normie ISO/IEC 
7816-4 mogą być zwracane, jeżeli ich zachowanie nie jest 
wyraźnie wymienione w niniejszym dodatku.  
Przykładowo następujące słowa stanu mogą być zwracane 
opcjonalnie:  
6881: Kanał logiczny nieobsługiwany  
6882: Bezpieczna wymiana komunikatów nieobsługiwana  
▼B 
TCS_30 W przypadku gdy w jednym poleceniu APDU spełniony 
jest więcej niż jeden warunek wystąpienia błędu, karta 
może odesłać dowolny z odpowiednich słów stanu.  
3.5. Opisy polece ń 
W tym rozdziale opisano obowiązkowe polecenia dla kart do tacho ­
grafów.  
Dodatkowe szczegółowe informacje dotyczące stosowanych czynnośc i 
kryptograficznych zamieszczono w dodatku 11 Wspólne mechanizmy 
zabezpieczenia dla tachografów 1. generacji i 2. generacji.  
Wszystkie polecenia opisane są niezależnie od używanego protoko łu 
(T=0 lub T=1). Bajty CLA, INS, P1, P2, Lc i Le w APDU są zawsze  
wskazywane. Jeżeli Lc lub Le nie jest potrzebny dla opisywanego  
polecenia, związane z nimi długość, wartość i opis są puste.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 243  
TCS_31 Jeżeli żądane są oba bajty długości (Lc i Le), opisywane  
polecenie musi być podzielone na dwie części, jeśli IFD 
używa protokołu T=0: IFD wysyła to polecenie z P3=Lc + 
dane, a następnie wysyła polecenie GET RESPONSE (zob. 
pkt 3.5.6) z P3=Le.  
TCS_32 Jeżeli żądane są oba bajty długości i Le=0 (bezpieczna 
wymiana komunikatów):  
— gdy używany jest protokół T=1, karta odpowiada na 
Le=0, wysyłając wszystkie dostępne dane wyjściowe;  
— gdy używany jest protokół T=0, IFD wysyła pierwsze 
polecenie z P3=Lc + dane, karta odpowiada (na to 
niejawne Le=0) bajtami stanu „ 61La ”, gdzie La jest 
liczbą dostępnych bajtów odpowiedzi. Następnie IFD 
generuje polecenie GET RESPONSE z P3=La w celu 
odczytania danych.  
TCS_33 Karta do tachografu może opcjonalnie obsługiwać pola 
o rozszerzonej długości zgodnie z normą ISO/IEC 7816- 
4. Karta do tachografu, która obsługuje pola o rozszerzonej 
długości, musi:  
— wskazywać możliwość obsługi pól o rozszerzonej 
długości w ATR;  
— zapewniać obsługiwane pojemności bufora za pomocą 
informacji o rozszerzonej długości w EF ATR/INFO, 
zob. TCS_146;  
— wskazywać, czy obsługuje pola o rozszerzonej długości 
dla T = 1 lub T = 0 w EF Extended Length, zob. 
TCS_147.  
— obsługiwać pola o rozszerzonej długości dla aplikacji 
tachograficznej 1. i 2. generacji.  
Uwagi:  
Wszystkie polecenia zostały określone dla pól o krótkiej 
długości. Stosowanie APDU o rozszerzonej długości 
wynika z ISO/IEC 7816-4.  
Polecenia są zasadniczo określone dla trybu zwykłego, tj. 
bez bezpiecznej wymiany komunikatów, ponieważ warstwa 
bezpiecznej wymiany komunikatów została określona 
w dodatku 11. Z zasad dostępu dla polecenia wynika, 
czy polecenie wspiera bezpieczną wymianę komunikatów, 
a także – czy polecenie wspiera bezpieczną wymianę 
komunikatów 1. generacji lub 2. generacji. Niektóre 
warianty poleceń opisano z bezpieczną wymianą komuni­
katów, aby zilustrować stosowanie bezpiecznej wymiany 
komunikatów.  
TCS_34 VU wykonuje pełny protokół 2. generacji wzajemnego 
uwierzytelnienia VU – karta dla sesji, łącznie z weryfikacją 
certyfikatu (jeżeli jest to wymagane), w DF Tachograph, 
w DF Tachograph_G2 lub w MF.  
3.5.1  SELECT  
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego zasto so­
wanie jest ograniczone w porównaniu z poleceniem zdefiniowanym 
w tej normie.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 244  
Polecenia SELECT używa się:  
— do wybierania aplikacji DF (musi być używany wybór przez 
nazwę);  
— do wybierania pliku elementarnego odpowiadającego przekaza­
nemu ID pliku.  
3.5.1.1 W y b ó r p r z e z n a z w ę ( A I D )  
Polecenie to pozwala wybrać aplikację DF na karcie.  
TCS_35 Polecenie to można wykonywać z dowolnego miejsca 
w strukturze pliku (po ATR lub w dowolnym momencie).  
TCS_36 Wybór aplikacji powoduje przywrócenie bieżącego stanu 
środowiska zabezpieczeń do stanu wyjściowego. Po 
wybraniu aplikacji żaden bieżący klucz publiczny nie jest 
już wybierany. Warunek dostępu EXT-AUT-G1 także 
zostaje utracony. Jeżeli polecenie zostało wykonane bez 
bezpiecznej wymiany komunikatów, wcześniejsze klucze 
sesji bezpiecznej wymiany komunikatów nie są już 
dostępne.  
TCS_37  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „A4h”  
P1 1  „04h”  Wybór przez nazwę (AID)  
P2 1  „0Ch”  brak oczekiwanej odpowiedzi  
Lc 1  „NNh”  liczba bajtów wysłanych do karty (długość AID): 
„06h” dla aplikacji tachograficznej  
#6-#(5+NN)  N N  „XX..XXh”  AID: „FF 54 41 43 48 4F” dla aplikacji tachograficznej 
1. generacji 
AID: „FF 53 4D 52 44 54” dla aplikacji tachograficznej 
2. generacji  
Dla polecenia SELECT nie jest potrzebna żadna odpowiedź 
(brak Le w T=1, bądź nie ma żądania odpowiedzi w T=0).  
TCS_38  Komunikat odpowiedzi (brak żądania odpowiedzi)  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli nie znaleziono aplikacji wyszczególnionej przez 
AID, zwróconym stanem przetwarzania jest „ 6A82 ”. 
— W T=1, jeżeli jest bajt Le, zwróconym stanem jest  
„6700” . 
— W T=0, jeżeli po poleceniu SELECT wymaga się odpo­
wiedzi, zwróconym stanem jest  „6900” . 
▼M1 
— Jeżeli wybrana aplikacja uznana jest za uszkodzoną 
(znaleziony błąd integralności w atrybutach pliku), 
zwróconym stanem przetwarzania jest „ 6400 ” lub 
„6500 ”. ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 245  
3.5.1.2 W y b ó r p l i k u e l e m e n t a r n e g o p r z y p  o m o c y i d e n t y ­
f i k a t o r a p l i k u  
TCS_39  Komunikat polecenia  
TCS_40 Karta do tachografu musi obsługiwać bezpieczną wymianę 
komunikatów 2. generacji, jak określono w dodatku 11 
część B dla tego wariantu polecenia.  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „A4h”  
P1 1  „02h”  wybór EF pod bieżącym DF  
P2 1  „0Ch”  brak oczekiwanej odpowiedzi  
Lc 1  „02h”  liczba bajtów wysłanych do karty  
#6-#7  2  „XXXXh”  identyfikator pliku  
Dla polecenia SELECT nie jest potrzebna żadna odpowiedź 
(brak Le w T=1, bądź nie ma żądania odpowiedzi w T=0).  
TCS_41  Komunikat odpowiedzi (brak żądania odpowiedzi)  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli nie znaleziono pliku odpowiadającego identyfika­
torowi pliku, zwróconym stanem przetwarzania jest 
„6A82 ”. 
— W T=1, jeżeli jest bajt Le, zwróconym stanem jest  
„6700” . 
— W T=0, jeżeli po poleceniu SELECT wymaga się odpo­
wiedzi, zwróconym stanem jest  „6900” . 
▼M1 
— Jeżeli wybrany plik uznany jest za uszkodzony (znale­
ziony błąd integralności w atrybutach pliku), zwró­
conym stanem przetwarzania jest „ 6400 ” lub „ 6500 ”. 
▼B 
3.5.2  READ BINARY  
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego zasto so­
wanie jest ograniczone w porównaniu z poleceniem zdefiniowanym 
w tej normie.  
Polecenie READ BINARY służy do odczytu danych z przezroczystego  
pliku.  
Odpowiedź karty obejmuje zwrot odczytanych danych, opcjonalnie 
obudowane w strukturę bezpiecznej wymiany komunikatów.  
3.5.2.1 P o l e c e n i e z p r z e s u n i ę c i e m w P 1 - P  2 
Polecenie to umożliwia IFD odczyt danych z aktualnie wybranego EF 
bez bezpiecznej wymiany komunikatów.  
Uwaga:  Tego polecenia bez bezpiecznej wymiany komunikatów 
można używać tylko do odczytu pliku, który wspiera warunek zabe z­
pieczenia ALW dla trybu dostępu do odczytu.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 246  
TCS_42  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „B0h”  Odczyt binarny  
P1 1  „XXh”  Przesunięcie w bajtach od początku pliku: bajt najbar­
dziej znaczący  
P2 1  „XXh”  Przesunięcie w bajtach od początku pliku: bajt najmniej 
znaczący  
Le 1  „XXh”  Długość oczekiwanych danych. Liczba bajtów do 
odczytu.  
Uwaga:  bit 8 w P1 musi być ustawiony na 0.  
TCS_43  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
#1-#X  X  „XX..XXh”  Odczyt danych  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli nie wybrano EF, zwróconym stanem przetwa­
rzania jest  „6986” . 
— Jeżeli warunki zabezpieczenia wybranego pliku nie są 
spełnione, polecenie zostaje przerwane z „ 6982 ”. 
— Jeżeli przesunięcie nie jest zgodne z wielkością EF 
(przesunięcie > wielkość EF), zwróconym stanem prze­
twarzania jest  „6B00” . 
— Jeżeli wielkość danych do odczytu nie jest zgodna 
z wielkością EF (przesunięcie + Le > wielkość EF), 
zwróconym stanem przetwarzania jest  „6700”  lub  
„6Cxx” , gdzie „xx” wskazuje dokładną długość.  
▼M1 
— Jeżeli błąd integralności zostaje wykryty w atrybutach 
pliku, karta uznaje, że plik jest uszkodzony i nienapra­
wialny, a zwróconym stanem przetwarzania jest „ 6400 ” 
lub „ 6500 ”. 
▼B 
— Jeżeli błąd integralności zostaje wykryty w zgromadzo­
nych danych, karta zwraca żądane dane, a zwróconym 
stanem przetwarzania jest  „6281” . 
3.5.2.1.1 P o l e c e n i e z b e z p i e c z n ą w y m i a n ą  k o m u n i k a t ó w 
( p r z y k ł a d y )  
Polecenie to umożliwia IFD odczyt danych z bieżąco wybranego EF  
z bezpieczną wymianą komunikatów w celu zweryfikowania integral ­
ności odebranych danych oraz ochrony poufności danych, jeżeli z asto­
sowanie ma warunek zabezpieczenia SM-R-ENC-MAC-G1 (1. gene­
racja) lub SM-R-ENC-MAC-G2 (2. generacja).  
TCS_44  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „0Ch”  Żądana bezpieczna wymiana komunikatów  
INS 1  „B0h”  Odczyt binarny  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 247  
Bajt Długość  Wartość  Opis  
P1 1  „XXh”  P1 (przesunięcie w bajtach od początku pliku): bajt 
najbardziej znaczący  
P2 1  „XXh”  P2 (przesunięcie w bajtach od początku pliku): bajt 
najmniej znaczący  
Lc 1  „XXh”  Długość danych wejściowych dla bezpiecznej wymiany 
komunikatów  
#6 1  „97h”  T  LE : znacznik specyfikacji oczekiwanej długości  
#7 1  „01h”  L  LE : długość oczekiwanej długości  
#8 1  „NNh”  Specyfikacja oczekiwanej długości (początkowy Le): 
liczba bajtów do odczytu  
#9 1  „8Eh”  T  CC : znacznik kryptograficznej sumy kontrolnej  
#10 1  „XXh”  L  CC : długość znajdującej się dalej kryptograficznej sumy 
kontrolnej 
„04h” dla bezpiecznej wymiany komunikatów 1. gene­
racji (zob. dodatek 11 część A) 
„08h”, „0Ch” lub „10h”, w zależności od długości 
klucza AES, dla bezpiecznej wymiany komunikatów 2. 
generacji (zob. dodatek 11 część B)  
#11-#(10+L)  L  „XX..XXh”  Kryptograficzna suma kontrolna  
Le 1  „00h”  zgodnie ze specyfikacją w normie ISO/IEC 7816-4  
TCS_45  Komunikat odpowiedzi, je żeli SM-R-ENC-MAC-G1 (1. 
generacja) / SM-R-ENC-MAC-G2 (2. generacja) nie s ą 
wymagane oraz je żeli format wej ściowy bezpiecznej 
wymiany komunikatów jest prawid łowy: 
▼M1 
Bajt Długo­ 
ść Wartość  Opis  
#1 1  „81h”  T  PV : znacznik wartości danych odkrytych  
#2 L  „NNh” lub 
„81 NNh”  L PV : długość zwracanych danych (= począt­
kowemu Le). 
L ma 2 bajty, jeżeli L  PV >127 bajtów  
#(2+L) - #(1+L+NN)  N N  „XX..XXh”  Wartość danych odkrytych  
#(2+L+NN)  1  „99h”  Znacznik stanu przetwarzania (SW1-SW2) – 
opcjonalnie dla bezpiecznej wymiany komu­
nikatów 1. generacji  
#(3+L+NN)  1  „02h”  Długość stanu przetwarzania – opcjonalnie 
dla bezpiecznej wymiany komunikatów 1. 
generacji  
#(4+L+NN) - #(5+L+NN)  2  „XX XXh”  Stan przetwarzania niechronionej odpo­
wiedzi APDU – opcjonalnie dla bezpiecznej 
wymiany komunikatów 1. generacji  
#(6+L+NN)  1  „8Eh”  TCC: znacznik kryptograficznej sumy 
kontrolnej  
#(7+L+NN)  1  „XXh”  LCC: długość znajdującej się dalej krypto­
graficznej sumy kontrolnej 
„04h” dla bezpiecznej wymiany komuni­
katów 1. generacji (zob. dodatek 11 część A) 
„08h”, „0Ch” lub „10h”, w zależności od 
długości klucza AES, dla bezpiecznej 
wymiany komunikatów 2. generacji (zob. 
dodatek 11 część B)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 248  
Bajt Długo­ 
ść Wartość  Opis  
#(8+L+NN)-#(7+M+L+NN)  M  „XX..XXh”  Kryptograficzna suma kontrolna  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
▼B 
TCS_46  Komunikat odpowiedzi, je żeli SM-R-ENC-MAC-G1 (1. 
generacja) / SM-R-ENC-MAC-G2 (2. generacja) s ą 
wymagane oraz je żeli format wej ściowy bezpiecznej 
wymiany komunikatów jest prawid łowy: 
▼M1 
Bajt Długo­ 
ść Wartość  Opis  
#1 1  „87h”  T  PI CG  : znacznik zaszyfrowanych danych 
(kryptogram)  
#2 L  „MMh” lub 
„81 MMh”  L PI CG  : długość zwracanych zaszyfrowanych 
danych (różna od początkowego Le z pole­
cenia, ze względu na wypełnienie) 
L ma 2 bajty, jeżeli LPI CG > 127 bajtów  
#(2+L)-#(1+L+MM)  M M  „01XX..XXh”  dane szyfrowane: wskaźnik wypełnienia 
i kryptogram  
#(2+L+MM)  1  „99h”  Znacznik stanu przetwarzania (SW1-SW2) – 
opcjonalnie dla bezpiecznej wymiany komu­
nikatów 1. generacji  
#(3+L+MM)  1  „02h”  Długość stanu przetwarzania – opcjonalnie 
dla bezpiecznej wymiany komunikatów 1. 
generacji  
#(4+L+MM) - #(5+L+MM)  2  „XX XXh”  Stan przetwarzania niechronionej odpo­
wiedzi APDU – opcjonalnie dla bezpiecznej 
wymiany komunikatów 1. generacji  
#(6+L+MM)  1  „8Eh”  TCC: znacznik kryptograficznej sumy 
kontrolnej  
#(7+L+MM)  1  „XXh”  LCC: długość znajdującej się dalej krypto­
graficznej sumy kontrolnej 
„04h” dla bezpiecznej wymiany komuni­
katów 1. generacji (zob. dodatek 11 część 
A) 
„08h”, „0Ch” lub „10h”, w zależności od 
długości klucza AES, dla bezpiecznej 
wymiany komunikatów 2. generacji (zob. 
dodatek 11 część B)  
#(8+L+MM)- 
#(7+N+L+MM)  N „XX..XXh”  Kryptograficzna suma kontrolna  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
▼B 
Polecenie READ BINARY może zwracać stany regular­
nego przetwarzania, wymienione w TCS_43 pod znaczni­
kiem „99h”, opisane w TCS_59, przy użyciu struktury 
odpowiedzi bezpiecznej wymiany komunikatów.  
Ponadto mogą wystąpić niektóre błędy, swoiście dotyczące 
bezpiecznej wymiany komunikatów. W takim przypadku 
zwracany jest po prostu stan przetwarzania bez struktury 
bezpiecznej wymiany komunikatów:  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 249  
TCS_47  Komunikat odpowiedzi przy nieprawid łowym formacie 
wejściowym bezpiecznej wymiany komunikatów  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli klucz bieżącej sesji nie jest dostępny, zwracany 
jest stan przetwarzania  „6A88” . Zdarza się to 
w sytuacji, gdy klucz sesyjny nie jest już generowany, 
albo w sytuacji, gdy wygaśnie już ważność kluczy 
sesyjnych (w tym przypadku IFD musi powtórnie 
uruchomić proces wzajemnego uwierzytelnienia 
w celu utworzenia nowego klucza sesyjnego).  
— Jeżeli w formacie bezpiecznej wymiany komunikatów 
brakuje pewnych oczekiwanych obiektów (określonych 
powyżej), zwracany jest stan przetwarzania  „6987” : ten 
błąd ma miejsce, jeżeli brakuje oczekiwanego znacz­
nika lub jeżeli treść polecenia nie jest prawidłowo 
skonstruowana.  
— Jeżeli pewne obiekty danych są nieprawidłowe, zwró­
conym stanem przetwarzania jest  „6988” : ten błąd ma 
miejsce, jeżeli obecne są wszystkie wymagane znacz­
niki, ale niektóre długości różnią się od oczekiwanych.  
— Jeżeli weryfikacja kryptograficznej sumy kontrolnej 
wykaże niezgodność, zwróconym stanem przetwarzania 
jest „6688” . 
3.5.2.2 P o l e c e n i e z k r ó t k i m i i d e n t y f i k a  t o r e m E F 
( E l e m e n t a r y F i l e )  
Ten wariant polecenia umożliwia IFD wybór EF przy pomocy krót­
kiego identyfikatora EF oraz odczyt danych z tego EF.  
TCS_48 Karta do tachografu obsługuje ten wariant polecenia dla 
wszystkich plików elementarnych z określonym krótkim 
identyfikatorem EF. Przedmiotowe krótkie identyfikatory 
EF zostały określone w rozdziale 4.  
TCS_49  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „B0h”  Odczyt binarny  
P1 1  „XXh”  Bit 8 ustawiany jest na 1. 
Bity 7 i 6 ustawiane są na 00. 
Bity 5 – 1 kodują krótki identyfikator EF odpowiedniego 
EF. 
P2 1  „XXh”  Koduje przesunięcie od 0 do 255 bajtów w EF przywo­ 
łanym przez P1.  
Le 1  „XXh”  Długość oczekiwanych danych. Liczba bajtów do 
odczytu.  
Uwaga:  Krótkie identyfikatory EF używane na potrzeby 
aplikacji tachograficznej 2. generacji zostały określone 
w rozdziale 4.  
Jeżeli P1 koduje krótki identyfikator EF, a polecenie 
zostało pomyślnie wykonane, ustalone EF staje się bieżąco 
wybranym EF (bieżący EF).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 250  
TCS_50  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
#1-#L  L  „XX..XXh”  Odczyt danych  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli nie znaleziono pliku odpowiadającego krótkiemu 
identyfikatorowi EF, zwróconym stanem przetwarzania 
jest „6A82” . 
— Jeżeli warunki zabezpieczenia wybranego pliku nie są 
spełnione, polecenie zostaje przerwane z „ 6982 ”. 
— Jeżeli przesunięcie nie jest zgodne z wielkością EF 
(przesunięcie > wielkość EF), zwróconym stanem prze­
twarzania jest  „6B00” . 
— Jeżeli wielkość danych do odczytu nie jest zgodna 
z wielkością EF (przesunięcie + Le > wielkość EF), 
zwróconym stanem przetwarzania jest  „6700”  lub  
„6Cxx” , gdzie „xx” wskazuje dokładną długość.  
▼M1 
— Jeżeli błąd integralności zostaje wykryty w atrybutach 
pliku, karta uznaje, że plik jest uszkodzony i nienapra­
wialny, a zwróconym stanem przetwarzania jest „ 6400 ” 
lub„6500 ”. 
▼B 
— Jeżeli błąd integralności zostaje wykryty w zgromadzo­
nych danych, karta zwraca żądane dane, a zwróconym 
stanem przetwarzania jest  „6281” . 
3.5.2.3 P o l e c e n i e z n i e p a r z y s t y m b a j t e m  i n s t r u k c j i  
Ten wariant polecenia umożliwia IFD odczyt danych z EF, który m a 
32 768 bajtów lub więcej.  
TCS_51 Karta do tachografu obsługująca EF, który ma 32 768 
bajtów lub więcej, musi obsługiwać ten wariant polecenia 
dla takich EF. Karta do tachografu może, ale nie musi 
obsługiwać tego wariantu polecenia dla innych EF, z wyjąt­
kiem EF Sensor_Installation_Data (zob. TCS_156 
i TCS_160).  
TCS_52  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „B1h”  Odczyt binarny  
P1 1  „00h”  bieżący EF  
P2 1  „00h”  
Lc 1  „NNh”  Lc długość przesuniętego obiektu danych.  
#6-#(5+NN)  N N  „XX..XXh”  przesunięty obiekt danych: 
znacznik „54h” 
długość „01h” lub „02h” 
wartość przesunięcie  
▼M1 
Le 1  „XXh”  zgodnie ze specyfikacją w normie ISO/IEC 7816-4  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 251  
IFD koduje długość przesuniętego obiektu danych 
z możliwie najmniejszą liczbą oktetów, tzn. przy pomocy 
bajtu długości „01h” IFD koduje przesunięcie od 0 do 255 
bajtów, a przy pomocy bajtu długości „02h” koduje prze­
sunięcie od „256” do „65 535” bajtów.  
▼M1 
W przypadku gdy T=0, karta przyjmuje wartość Le = 
„00h”, jeżeli nie stosuje się bezpiecznej wymiany komuni­
katów.  
W przypadku gdy T = 1, zwróconym stanem przetwarzania 
jest „6700”, jeżeli Le = „01h”.  
▼B 
TCS_53  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
#1-#L  L  „XX..XXh”  Odczytane dane zapakowane do nieokreślonego obiektu 
danych ze znacznikiem „53h”.  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli nie wybrano EF, zwróconym stanem przetwa­
rzania jest  „6986” . 
— Jeżeli warunki zabezpieczenia wybranego pliku nie są 
spełnione, polecenie zostaje przerwane z  „6982” . 
— Jeżeli przesunięcie nie jest zgodne z wielkością EF 
(przesunięcie > wielkość EF), zwróconym stanem prze­
twarzania jest  „6B00” . 
— Jeżeli wielkość danych do odczytu nie jest zgodna 
z wielkością EF (przesunięcie + Le > wielkość EF), 
zwróconym stanem przetwarzania jest  „6700”  lub 
„6Cxx ”, gdzie „xx” wskazuje dokładną długość.  
▼M1 
— Jeżeli błąd integralności zostaje wykryty w atrybutach 
pliku, karta uznaje, że plik jest uszkodzony i nienapra­
wialny, a zwróconym stanem przetwarzania jest „ 6400 ” 
lub „ 6500 ”. 
▼B 
— Jeżeli błąd integralności zostaje wykryty w zgromadzo­
nych danych, karta zwraca żądane dane, a zwróconym 
stanem przetwarzania jest „ 6281 ”. 
3.5.2.3.1 P o l e c e n i e z b e z p i e c z n ą w y m i a n ą  k o m u n i k a t ó w 
( p r z y k ł a d )  
Poniższy przykład ilustruje stosowanie bezpiecznej wymiany komu ni­
katów, jeżeli zastosowanie ma warunek zabezpieczenia SM-MAC-G2.  
TCS_54 Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „0Ch”  Żądana bezpieczna wymiana komunikatów  
INS 1  „B1h”  Odczyt binarny  
P1 1  „00h”  bieżący EF  
P2 1  „00h”  
Lc 1  „XXh”  długość chronionego pola danych  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 252  
Bajt Długość  Wartość  Opis  
#6 1  „B3h”  znacznik wartości danych odkrytych kodowanych 
w BER-TLV  
#7 1  „NNh”  L  PV : długość przesyłanych danych  
#(8)-#(7+NN)  N N  „XX..XXh”  dane odkryte kodowane w BER-TLV, tj. przesunięty 
obiekt danych ze znacznikiem „54”  
#(8+NN)  1  „97h”  T  LE : znacznik specyfikacji oczekiwanej długości  
#(9+NN)  1  „01h”  L  LE : długość oczekiwanej długości  
#(10+NN)  1  „XXh”  specyfikacja oczekiwanej długości (początkowy Le): 
liczba bajtów do odczytu  
#(11+NN)  1  „8Eh”  T  CC : znacznik kryptograficznej sumy kontrolnej  
#(12+NN)  1  „XXh”  L  CC : długość znajdującej się dalej kryptograficznej sumy 
kontrolnej 
„08h”, „0Ch” lub „10h”, w zależności od długości 
klucza AES, dla bezpiecznej wymiany komunikatów 2. 
generacji (zob. dodatek 11 część B)  
#(13+NN)- 
#(12+M+NN)  M „XX..XXh”  Kryptograficzna suma kontrolna  
Le 1  „00h”  zgodnie ze specyfikacją w normie ISO/IEC 7816-4  
TCS_55 komunikat odpowiedzi, jeżeli polecenie zostało pomyślnie  
wykonane  
Bajt Długość  Wartość  Opis  
#1 1  „B3h”  odkryte dane kodowane w BER-TLV  
#2 L  „NNh” lub 
„81 NNh”  L PV : długość zwracanych danych (= początkowemu Le). 
L ma 2 bajty, jeżeli L  PV >127 bajtów  
#(2+L)- 
#(1+L+NN)  NN „XX..XXh”  Wartość odkrytych danych kodowanych w BER-TLV, tj. 
odczytane dane zapakowane do nieokreślonego obiektu 
danych ze znacznikiem „53h”.  
#(2+L+NN)  1  „99h”  Stan przetwarzania niechronionej odpowiedzi APDU  
#(3+L+NN)  1  „02h”  Długość stanu przetwarzania  
#(4+L+NN) – 
#(5+L+NN)  2 „XX XXh”  Stan przetwarzania niechronionej odpowiedzi APDU  
#(6+L+NN)  1  „8Eh”  T  CC : znacznik kryptograficznej sumy kontrolnej  
#(7+L+NN)  1  „XXh”  L  CC : długość znajdującej się dalej kryptograficznej sumy 
kontrolnej 
„08h”, „0Ch” lub „10h”, w zależności od długości 
klucza AES, dla bezpiecznej wymiany komunikatów 2. 
generacji (zob. dodatek 11 część B)  
#(8+L+NN)- 
#(7+M+L+ 
NN) M „XX..XXh”  Kryptograficzna suma kontrolna  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
3.5.3  UPDATE BINARY  
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego zasto so­
wanie jest ograniczone w porównaniu z poleceniem zdefiniowanym 
w tej normie.  
Komunikat polecenia UPDATE BINARY inicjuje aktualizację (kaso­
wanie + zapis) bitów już znajdujących się w binarnym EF, zastęp ując 
je bitami podanymi w poleceniu APDU.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 253  
3.5.3.1 P o l e c e n i e z p r z e s u n i ę c i e m w P 1 - P  2 
Polecenie to umożliwia IFD zapis danych do bieżąco wybranego EF , 
bez sprawdzenia przez kartę integralności otrzymanych danych.  
Uwaga:  Tego polecenia bez bezpiecznej wymiany komunikatów 
można używać tylko do aktualizacji pliku, który wspiera warunek  
zabezpieczenia ALW dla trybu dostępu do aktualizacji.  
TCS_56  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „D6h”  Aktualizacja binarna licznika  
P1 1  „XXh”  Przesunięcie w bajtach od początku pliku: bajt najbar­
dziej znaczący  
P2 1  „XXh”  Przesunięcie w bajtach od początku pliku: bajt najmniej 
znaczący  
Lc 1  „NNh”  Lc długość aktualizowanych danych. Liczba zapisywa­
nych bajtów.  
#6-#(5+NN)  N N  „XX..XXh”  zapisywane dane  
Uwaga:  bit 8 w P1 musi być ustawiony na 0.  
TCS_57  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli nie wybrano EF, zwróconym stanem przetwa­
rzania jest  „6986” . 
— Jeżeli warunki zabezpieczenia wybranego pliku nie są 
spełnione, polecenie zostaje przerwane z „ 6982 ”. 
— Jeżeli przesunięcie nie jest zgodne z wielkością EF 
(przesunięcie > wielkość EF), zwróconym stanem prze­
twarzania jest  „6B00” . 
— Jeżeli wielkość danych, które mają być zapisane, nie 
jest zgodna z wielkością EF (przesunięcie + Lc > wiel­
kość EF), zwróconym stanem przetwarzania jest  
„6700” . 
— Jeżeli błąd integralności zostaje wykryty w atrybutach 
pliku, karta uznaje, że plik jest uszkodzony i nienapra­
wialny, a zwróconym stanem przetwarzania jest  „6400”  
lub „6500” . 
— Jeżeli zapis nie jest wykonany pomyślnie, zwróconym 
stanem przetwarzania jest  „6581” . 
3.5.3.1.1 P o l e c e n i e z b e z p i e c z n ą w y m i a n ą  k o m u n i k a t ó w 
( p r z y k ł a d y )  
Polecenie to umożliwia IFD zapis danych do bieżąco wybranego EF , 
ze sprawdzeniem przez kartę integralności otrzymanych danych. G dy 
nie jest wymagana poufność, dane nie są szyfrowane.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 254  
TCS_58  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „0Ch”  Żądana bezpieczna wymiana komunikatów  
INS 1  „D6h”  Aktualizacja binarna licznika  
P1 1  „XXh”  Przesunięcie w bajtach od początku pliku: 
bajt najbardziej znaczący  
P2 1  „XXh”  Przesunięcie w bajtach od początku pliku: 
bajt najmniej znaczący  
Lc 1  „XXh”  długość chronionego pola danych  
#6 1  „81h”  T  PV : znacznik wartości danych odkrytych  
#7 L  „NNh” lub 
„81 NNh”  L PV : długość transmitowanych danych. 
L ma 2 bajty, jeżeli L  PV >127 bajtów.  
#(7 + L)- 
#(6 + L + NN)  NN „XX..XXh”  wartość odkrytych danych (dane, które mają być zapi­
sane)  
#(7 + L + NN)  1  „8Eh”  T  CC : znacznik kryptograficznej sumy kontrolnej  
#(8 + L + NN)  1  „XXh”  L  CC : długość znajdującej się dalej kryptograficznej sumy 
kontrolnej „04h” dla bezpiecznej wymiany komunikatów 
1. generacji (zob. dodatek 11 część A) 
„08h”, „0Ch” lub „10h”, w zależności od długości 
klucza AES, dla bezpiecznej wymiany komunikatów 2. 
generacji (zob. dodatek 11 część B)  
#(9 + L + NN)- 
#(8 + M + L + 
NN) M „XX..XXh”  Kryptograficzna suma kontrolna  
Le 1  „00h”  zgodnie ze specyfikacją w normie ISO/IEC 7816-4  
TCS_59  Komunikat odpowiedzi przy prawid łowym formacie 
wejściowym bezpiecznej wymiany komunikatów  
Bajt Długość  Wartość  Opis  
#1 1  „99h”  T  SW : znacznik słów stanu (chroniony przez CC)  
#2 1  „02h”  L  SW : długość zwracanego słowa stanu  
#3-#4  2  „XXXXh”  Stan przetwarzania niechronionej odpowiedzi APDU  
#5 1  „8Eh”  T  CC : znacznik kryptograficznej sumy kontrolnej  
#6 1  „XXh”  L  CC : długość znajdującej się dalej kryptograficznej sumy 
kontrolnej 
„04h” dla bezpiecznej wymiany komunikatów 1. gene­
racji (zob. dodatek 11 część A) 
„08h”, „0Ch” lub „10h”, w zależności od długości 
klucza AES, dla bezpiecznej wymiany komunikatów 2. 
generacji (zob. dodatek 11 część B)  
#7-#(6+L)  L  „XX..XXh”  Kryptograficzna suma kontrolna  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
Stany „regularnego” przetwarzania, opisane dla polecenia 
UPDATE BINARY z bezpieczną wymianą komunikatów 
(zob. pkt 3.5.3.1), mogą być zwracane przy użyciu struk­
tury komunikatu odpowiedzi opisanej powyżej.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 255  
Ponadto mogą wystąpić niektóre błędy, swoiście dotyczące 
bezpiecznej wymiany komunikatów. W takim przypadku 
zwracany jest po prostu stan przetwarzania bez struktury 
bezpiecznej wymiany komunikatów:  
TCS_60  Komunikat odpowiedzi w przypadku b łędu 
w bezpiecznej wymianie komunikatów  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli klucz bieżącej sesji nie jest dostępny, zwracany 
jest stan przetwarzania  „6A88” . 
— Jeżeli w formacie bezpiecznej wymiany komunikatów 
brakuje pewnych oczekiwanych obiektów (określonych 
powyżej), zwracany jest stan przetwarzania  „6987” : ten 
błąd ma miejsce, jeżeli brakuje oczekiwanego znacz­
nika lub jeżeli treść polecenia nie jest prawidłowo 
skonstruowana.  
— Jeżeli pewne obiekty danych są nieprawidłowe, zwró­
conym stanem przetwarzania jest  „6988” : ten błąd ma 
miejsce, jeżeli obecne są wszystkie wymagane znacz­
niki, ale niektóre długości różnią się od oczekiwanych.  
— Jeżeli weryfikacja kryptograficznej sumy kontrolnej 
wykaże niezgodność, zwróconym stanem przetwarzania 
jest „6688” . 
3.5.3.2 P o l e c e n i e z k r ó t k i m i i d e n t y f i k a  t o r e m E F  
Ten wariant polecenia umożliwia IFD wybór EF przy pomocy krót­
kiego identyfikatora EF oraz zapis danych z tego EF.  
TCS_61 Karta do tachografu obsługuje ten wariant polecenia dla 
wszystkich plików elementarnych z określonym krótkim 
identyfikatorem EF. Przedmiotowe krótkie identyfikatory 
EF zostały określone w rozdziale 4.  
TCS_62  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „D6h”  Aktualizacja binarna licznika  
P1 1  „XXh”  Bit 8 ustawiany jest na 1. 
Bity 7 i 6 ustawiane są na 00. 
Bity 5 – 1 kodują krótki identyfikator EF odpowiedniego 
EF. 
P2 1  „XXh”  Koduje przesunięcie od 0 do 255 bajtów w EF przywo­ 
łanym przez P1.  
Lc 1  „NNh”  Lc długość aktualizowanych danych. Liczba zapisywa­
nych bajtów.  
#6-#(5+NN)  N N  „XX..XXh”  zapisywane dane  
TCS_63  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
Uwaga:  Krótkie identyfikatory EF używane na potrzeby 
aplikacji tachograficznej 2. generacji zostały określone 
w rozdziale 4.  
Jeżeli P1 koduje krótki identyfikator EF, a polecenie 
zostało pomyślnie wykonane, ustalone EF staje się bieżąco 
wybranym EF (bieżący EF).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 256  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli nie znaleziono pliku odpowiadającego krótkiemu 
identyfikatorowi EF, zwróconym stanem przetwarzania 
jest „6A82” . 
— Jeżeli warunki zabezpieczenia wybranego pliku nie są 
spełnione, polecenie zostaje przerwane z „ 6982 ”. 
— Jeżeli przesunięcie nie jest zgodne z wielkością EF 
(przesunięcie > wielkość EF), zwróconym stanem prze­
twarzania jest  „6B00” . 
— Jeżeli wielkość danych, które mają być zapisane, nie 
jest zgodna z wielkością EF (przesunięcie + Lc > wiel­
kość EF), zwróconym stanem przetwarzania jest  
„6700” . 
▼M1 
— Jeżeli błąd integralności zostaje wykryty w atrybutach 
pliku, karta uznaje, że plik jest uszkodzony i nienapra­
wialny, a zwróconym stanem przetwarzania jest „ 6400 ” 
lub „ 6500 ”. 
▼B 
— Jeżeli zapis nie jest wykonany pomyślnie, zwróconym 
stanem przetwarzania jest  „6581” . 
3.5.3.3 P o l e c e n i e z n i e p a r z y s t y m b a j t e m  i n s t r u k c j i  
Ten wariant polecenia umożliwia IFD zapis danych do EF, który m a 
32 768 bajtów lub więcej.  
TCS_64 Karta do tachografu obsługująca EF, który ma 32 768 
bajtów lub więcej, musi obsługiwać ten wariant polecenia 
dla takich EF. Karta do tachografu może, ale nie musi 
obsługiwać tego wariantu polecenia dla innych EF.  
TCS_65  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „D7h”  Aktualizacja binarna licznika  
P1 1  „00h”  bieżący EF  
P2 1  „00h”  
Lc 1  „NNh”  Lc długość danych w polu danych dotyczących pole­
cenia  
#6-#(5+NN)  N N  „XX..XXh”  przesunięty obiekt danych ze znacznikiem „54h” || 
nieokreślony obiekt danych ze znacznikiem „53h”, 
który pakuje dane do zapisu  
IFD koduje długość przesuniętego obiektu danych oraz 
długość nieokreślonego obiektu danych z możliwie 
najmniejszą liczbą oktetów, tzn. przy pomocy bajtu 
długości „01h” IFD koduje przesunięcie/długość od 0 do 
255 bajtów, a przy pomocy bajtu długości „02h” koduje 
przesunięcie/długość od „256” do „65 535” bajtów.  
TCS_66  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 257  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli nie wybrano EF, zwróconym stanem przetwa­
rzania jest  „6986” . 
— Jeżeli warunki zabezpieczenia wybranego pliku nie są 
spełnione, polecenie zostaje przerwane z „ 6982 ”. 
— Jeżeli przesunięcie nie jest zgodne z wielkością EF 
(przesunięcie > wielkość EF), zwróconym stanem prze­
twarzania jest  „6B00” . 
— Jeżeli wielkość danych, które mają być zapisane, nie 
jest zgodna z wielkością EF (przesunięcie + Lc > wiel­
kość EF), zwróconym stanem przetwarzania jest  
„6700” . 
— Jeżeli błąd integralności zostaje wykryty w atrybutach 
pliku, karta uznaje, że plik jest uszkodzony i nienapra­
wialny, a zwróconym stanem przetwarzania jest  „6400”  
lub „6500” . 
— Jeżeli zapis nie jest wykonany pomyślnie, zwróconym 
stanem przetwarzania jest  „6581” . 
3.5.3.3.1 P o l e c e n i e z b e z p i e c z n ą w y m i a n ą  k o m u n i k a t ó w 
( p r z y k ł a d )  
Poniższy przykład ilustruje stosowanie bezpiecznej wymiany komu ni­
katów, jeżeli zastosowanie ma warunek zabezpieczenia SM-MAC-G2.  
TCS_67 Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „0Ch”  Żądana bezpieczna wymiana komunikatów  
INS 1  „D7h”  Aktualizacja binarna licznika  
P1 1  „00h”  bieżący EF  
P2 1  „00h”  
Lc 1  „XXh”  długość chronionego pola danych  
#6 1  „B3h”  znacznik wartości danych odkrytych kodowanych 
w BER-TLV  
#7 L  „NNh” lub 
„81 NNh”  L PV : długość transmitowanych danych. 
L ma 2 bajty, jeżeli L  PV >127 bajtów.  
#(7+L)- 
#(6+L+NN)  NN „XX..XXh”  dane odkryte kodowane w BER-TLV, tj. przesunięty 
obiekt danych ze znacznikiem „54h” || nieokreślony 
obiekt danych ze znacznikiem „53h”, który pakuje 
dane do zapisu  
#(7+L+NN)  1  „8Eh”  T  CC : znacznik kryptograficznej sumy kontrolnej  
#(8+L+NN)  1  „XXh”  L  CC : długość znajdującej się dalej kryptograficznej sumy 
kontrolnej 
„08h”, „0Ch” lub „10h”, w zależności od długości 
klucza AES, dla bezpiecznej wymiany komunikatów 2. 
generacji (zob. dodatek 11 część B)  
#(9+L+NN)- 
#(8+M+L+ 
NN) M „XX..XXh”  Kryptograficzna suma kontrolna  
Le 1  „00h”  zgodnie ze specyfikacją w normie ISO/IEC 7816-4  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 258  
TCS_68 komunikat odpowiedzi, jeżeli polecenie zostało pomyślnie  
wykonane  
Bajt Długość  Wartość  Opis  
#1 1  „99h”  T  SW : znacznik słów stanu (chroniony przez CC)  
#2 1  „02h”  L  SW : długość zwracanego słowa stanu  
#3-#4  2  „XXXXh”  Stan przetwarzania niechronionej odpowiedzi APDU  
#5 1  „8Eh”  T  CC : znacznik kryptograficznej sumy kontrolnej  
#6 1  „XXh”  L  CC : długość znajdującej się dalej kryptograficznej sumy 
kontrolnej 
„08h”, „0Ch” lub „10h”, w zależności od długości 
klucza AES, dla bezpiecznej wymiany komunikatów 2. 
generacji (zob. dodatek 11 część B)  
#7-#(6 + L)  L  „XX..XXh”  Kryptograficzna suma kontrolna  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
3.5.4  GET CHALLENGE  
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego zasto so­
wanie jest ograniczone w porównaniu z poleceniem zdefiniowanym 
w tej normie.  
Polecenie GET CHALLENGE żąda od karty wydania wyzwania 
w celu użycia go w procedurze związanej z zabezpieczeniem, w kt órej 
do karty wysyłany jest kryptogram lub pewne szyfrowane dane.  
TCS_69 Wyzwanie wydane przez kartę ważne jest tylko dla następ­
nego polecenia, które używa wyzwania, wysłanego do 
karty.  
TCS_70  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „84h”  INS  
P1 1  „00h”  P 1  
P2 1  „00h”  P 2  
Le 1  „08h”  Le (długość oczekiwanego wyzwania).  
TCS_71  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
#1-#8  8  „XX..XXh”  wyzwanie  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli Le jest inne niż „08h”, zwracany jest stan prze­
twarzania  „6700” . 
— Jeżeli parametry P1-P2 są nieprawidłowe, zwracany jest 
stan przetwarzania  „6A86” . ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 259  
3.5.5  VERIFY  
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego zasto so­
wanie jest ograniczone w porównaniu z poleceniem zdefiniowanym 
w tej normie.  
Jedynie karta warsztatowa jest zobowiązana do obsługi tego 
polecenia.  
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować  tego 
polecenia, lecz w przypadku tych kart żadne referencyjne CHV ni e 
jest zindywidualizowane. Karty te nie mogą zatem pomyślnie wyko ­
nywać tego polecenia. Jeśli chodzi o rodzaje kart do tachografó w inne 
niż karta warsztatowa, ich zachowanie, tj. zwracany kod błędu, nie 
jest objęte zakresem zastosowania niniejszej specyfikacji, jeże li pole­
cenie to jest wysyłane.  
Polecenie VERIFY inicjuje porównanie w karcie danych CHV (PIN) 
wysłanych w poleceniu z referencyjnymi CHV przechowywanymi na 
karcie.  
▼M1 
TCS_72 PIN wprowadzony przez użytkownika musi być kodowany 
w ASCII i prawidłowo wypełniony przez IFD bajtami 
„FFh” do długości 8 bajtów (zob. również typ danych 
WorkshopCardPIN w dodatku 1).  
▼B 
TCS_73 Aplikacje tachograficzne 1. i 2. generacji używają tego 
samego referencyjnego CHV.  
TCS_74 Karta do tachografu sprawdza, czy polecenie jest prawid­  
łowo zakodowane. Jeżeli polecenie nie jest prawidłowo 
zakodowane, karta nie porównuje wartości CHV, nie 
zmniejsza licznika dozwolonych prób CHV, ani nie zeruje 
stanu zabezpieczenia „PIN_Verified”, lecz przerywa wyko­
nanie polecenia. Polecenie jest prawidłowo zakodowane, 
jeżeli bajty CLA, INS, P1, P2 i Lc posiadają określone 
wartości, brak jest Le, a pole danych dotyczących polecenia 
posiada odpowiednią długość.  
TCS_75 Jeżeli polecenie zostało pomyślnie wykonane, licznik 
dozwolonych prób CHV zostaje przywrócony do stanu 
wyjściowego. Wartość początkowa licznika dozwolonych 
prób CHV to 5. Jeżeli polecenie zostało pomyślnie wyko­
nane, stan zabezpieczenia wewnętrznego karty otrzymuje 
status „PIN_Verified”. Karta zeruje ten stan zabezpieczenia, 
jeżeli karta jest zresetowana lub jeżeli kod CHV przesłany 
w poleceniu nie odpowiada przechowywanemu referencyj­
nemu CHV.  
Uwaga:  Stosowanie tego samego referencyjnego CHV 
i globalnego stanu zabezpieczenia zapobiega konieczności 
ponownego wprowadzenia PIN przez pracownika warsztatu 
po wybraniu innej aplikacji tachograficznej DF.  
TCS_76 Jeżeli porównanie wykaże niezgodność, jest ono rejestro­
wane na karcie, tzn. licznik dozwolonych prób CHV 
zmniejsza się o jeden, aby ograniczyć liczbę dalszych 
prób użycia referencyjnego CHV.  
TCS_77  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „20h”  INS  
P1 1  „00h”  P 1  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 260  
Bajt Długość  Wartość  Opis  
P2 1  „00h”  P2 (zweryfikowane CHV jest domniemanie znane)  
Lc 1  „08h”  długość przesyłanego kodu CHV  
#6-#13  8  „XX..XXh”  CHV  
TCS_78  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli nie znaleziono referencyjnego CHV, zwróconym 
stanem przetwarzania jest  „6A88” . 
— Jeżeli CHV jest zablokowane (licznik dozwolonych 
prób CHV jest wyzerowany), zwróconym stanem prze­
twarzania jest  „6983” . Po znalezieniu się w tym stanie 
CHV nie może już nigdy być pomyślnie przekazane.  
— Jeżeli porównanie wykaże niezgodność, licznik dozwo­
lonych prób CHV jest zmniejszany i zwracany jest stan  
„63CX”  (X > 0, gdzie X pokazuje stan licznika dozwo­
lonych prób CHV).  
— Jeżeli referencyjne CHV uznane jest za uszkodzone, 
zwróconym stanem przetwarzania jest  „6400”  lub  
„6581” . 
— Jeżeli Lc jest inne niż „08h”, zwracany jest stan prze­
twarzania „ 6700 ”. 
3.5.6  GET RESPONSE  
Polecenie to jest zgodne z normą ISO/IEC 7816-4.  
Polecenia tego (niezbędnego i dostępnego tylko dla protokołu T= 0) 
używa się do przesyłania przygotowanych danych z karty do urzą­
dzenia interfejsu (przypadek, gdy polecenie zawiera oba paramet ry Lc 
i Le).  
Polecenie GET RESPONSE musi być wydane bezpośrednio po pole­
ceniu przygotowującym dane, w przeciwnym przypadku dane są 
tracone. Po wykonaniu polecenia GET RESPONSE (z wyjątkiem 
sytuacji, gdy wystąpi błąd „ 61xx ” lub „ 6Cxx ”, zob. poniżej) wcześ­
niej przygotowane dane nie są już dostępne.  
TCS_79  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „C0h”  
P1 1  „00h”  
P2 1  „00h”  
Le 1  „XXh”  oczekiwana liczba bajtów  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 261  
TCS_80  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
#1-#X  X  „XX..XXh”  dane  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli karta nie przygotuje żadnych danych, zwróconym 
stanem przetwarzania jest  „6900”  lub „6F00”. . 
— Jeżeli Le przekracza liczbę dostępnych bajtów lub Le to 
zero, zwróconym stanem przetwarzania jest  „6Cxx” , 
gdzie „xx” oznacza dokładną liczbę dostępnych bajtów. 
W takim przypadku przygotowane dane pozostają 
dostępne dla kolejnego polecenia GET RESPONSE.  
— Jeżeli Le jest różne od zera i jest mniejsze od liczby 
dostępnych bajtów, karta wysyła normalnie żądane 
dane, a zwróconym stanem przetwarzania jest  „61xx” , 
gdzie „xx” oznacza liczbę dodatkowych bajtów jeszcze 
dostępnych dla kolejnego polecenia GET RESPONSE.  
— Jeżeli polecenie nie jest obsługiwane (protokół T=1), 
karta zwraca  „6D00” . 
3.5.7  PSO: VERIFY CERTIFICATE  
Polecenie to jest zgodne z normą ISO/IEC 7816-8, ale jego zasto so­
wanie jest ograniczone w porównaniu z poleceniem zdefiniowanym 
w tej normie.  
Karta używa polecenia VERIFY_CERTIFICATE do otrzymania 
klucza publicznego z zewnątrz i do sprawdzenia ważności tego 
klucza.  
3.5.7.1 P a r a p o l e c e n i e – o d p o w i e d ź 1 . g e n  e r a c j i  
TCS_81 Ten wariant polecenia jest obsługiwany jedynie przez apl i­
kację tachograficzną 1. generacji.  
TCS_82 W przypadku pomyślnej weryfikacji poleceniem VERIFY 
CERTIFICATE klucz publiczny jest zapamiętany do przy­
szłego wykorzystania w środowisku zabezpieczeń. Klucz 
ten jest jawnie przydzielony do używania w poleceniach 
związanych z zabezpieczeniem (INTERNAL AUTHENTI­
CATE, EXTERNAL AUTHENTICATE lub VERIFY 
CERTIFICATE) przez polecenie MSE (zob. pkt 3.5.11) 
przy użyciu jego identyfikatora klucza.  
TCS_83 W każdym przypadku polecenie VERIFY CERTIFICATE 
używa klucza publicznego uprzednio wybranego przez 
polecenie MSE do otwarcia certyfikatu. Ten klucz 
publiczny musi być kluczem jednego z państw członkow­
skich lub Europy.  
TCS_84  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „2Ah”  wykonanie operacji zabezpieczającej  
P1 1  „00h”  P 1  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 262  
Bajt Długość  Wartość  Opis  
P2 1  „AEh”  P2: dane niekodowane w BER-TLV (konkatenacja 
elementów danych)  
Lc 1  „C2h”  Lc: długość certyfikatu, 194 bajty  
#6-#199  194  „XX..XXh”  certyfikat: konkatenacja elementów danych (opisana 
w dodatku 11)  
TCS_85  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli weryfikacja certyfikatu nie uda się, zwróconym 
stanem przetwarzania jest  „6688” . Proces weryfikacji 
i otwierania certyfikatu opisano w dodatku 11 dla 1. 
generacji i 2. generacji.  
— Jeżeli klucza publicznego nie ma w środowisku zabez­
pieczeń, zwróconym stanem przetwarzania jest  „6A88” . 
— Jeżeli wybrany klucz publiczny (użyty do otwierania 
certyfikatu) uznany jest za uszkodzony, zwróconym 
stanem przetwarzania jest  „6400”  lub „6581” . 
— Wyłącznie 1. generacja: Jeżeli CHA.LSB 
(
 
) wybranego klucza publicznego (użytego do otwierania 
certyfikatu) różni się od „00” (tzn. nie jest kluczem 
państwa członkowskiego lub Europy), zwróconym 
stanem przetwarzania jest  „6985” . 
3.5.7.2 P a r a p o l e c e n i e – o d p o w i e d ź 2 . g e n  e r a c j i  
W zależności od wielkości krzywej certyfikaty ECC mogą być tak 
długie, że nie mogą być przekazywane w jednym APDU. W takim 
przypadku stosowany musi być łańcuch poleceń zgodny z ISO/IEC 
7816-4, a certyfikat musi być przesyłany w dwóch kolejnych pole ce­
niach APDU PSO: Verify Certificate.  
Struktura certyfikatu i parametry domeny zostały określone 
w dodatku 11.  
▼M3 
TCS_86 Polecenie może być wykonywane w MF, w DF Tacho­
graph i w DF Tachograph_G2 (zob. również TCS_34).  
▼B 
TCS_87  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „X0h”  bajt CLA wskazujący łańcuch poleceń: 
„00h” – jedyne lub ostatnie polecenie łańcucha 
„10h” – nieostatnie polecenie łańcucha  
INS 1  „2Ah”  wykonanie operacji zabezpieczającej  
P1 1  „00h”  
P2 1  „BEh”  weryfikacja samoopisującego certyfikatu  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 263  
Bajt Długość  Wartość  Opis  
Lc 1  „XXh”  długość pola danych dotyczących polecenia (zob. 
TCS_88 oraz TCS_89).  
#6-#5+L  L  „XX..XXh”  dane kodowane w DER-TLV: Obiekt danych jednostki 
certyfikującej ECC jako pierwszy obiekt danych konka­
tenowany z obiektem danych podpisu certyfikatu ECC 
jako drugim obiektem danych lub jako częścią tej konka­
tenacji. Znacznik „7F21” i odpowiednia długość nie są 
przekazywane. 
Kolejność tych obiektów danych jest stała.  
▼M3 
TCS_88 W odniesieniu do APDU o krótkiej długości zastosowanie 
mają następujące postanowienia: IFD musi wykorzystywać 
minimalną liczbę APDU wymaganą do przesłania payloadu 
polecenia oraz transmisji maksymalnej liczby bajtów 
w pierwszym poleceniu APDU. Jednak każda wartość 
„Lc” do 255 bajtów musi być obsługiwana przez kartę.  
TCS_89 W odniesieniu do APDU o rozszerzonej długości zastoso­
wanie mają następujące postanowienia: jeżeli certyfikat nie 
jest dopasowany do pojedynczego APDU, karta musi 
obsługiwać łańcuch poleceń. IFD musi wykorzystywać 
minimalną liczbę APDU wymaganą do przesłania payloadu 
polecenia oraz transmisji maksymalnej liczby bajtów 
w pierwszym poleceniu APDU. Jeżeli konieczne jest utwo­
rzenia łańcucha, każda wartość „Lc” do podanej maksy­
malnej wielkości rozszerzonej długości musi być obsługi­
wana przez kartę.  
Uwaga: Zgodnie z dodatkiem 11 karta przechowuje certy­
fikat lub odpowiednie treści certyfikatu oraz uaktualnia 
jego currentAuthenticatedTime.  
Struktura komunikatu odpowiedzi i słowa stanu zostały 
określone w TCS_85.  
▼B 
TCS_90 Oprócz kodów błędów wymienionych w TCS_85, karta 
może zwracać następujące kody błędów:  
— jeżeli CHA.LSB (CertificateHolderAuthorisation.equip­
mentType) wybranego klucza publicznego (użytego do 
otwierania certyfikatu) nie jest odpowiednie dla weryfi­
kacji certyfikatu zgodnie z dodatkiem 11, zwróconym 
stanem przetwarzania jest „ 6985 ”. 
— Jeżeli currentAuthenticatedTime karty jest późniejszy 
niż data upływu ważności certyfikatu, zwróconym 
stanem przetwarzania jest „ 6985 ”. 
— Jeżeli oczekiwane jest ostatnie polecenie łańcucha, karta 
zwraca „ 6883 ”. 
— Jeżeli nieprawidłowe parametry są wysyłane w polu 
danych dotyczących polecenia, karta zwraca „ 6A80 ” 
(także w przypadku, gdy obiekty danych nie są wysy­ 
łane w określonej kolejności).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 264  
3.5.8  INTERNAL AUTHENTICATE  
Polecenie to jest zgodne z normą ISO/IEC 7816-4.  
TCS_91 Wszystkie karty do tachografów obsługują to polecenie 
w DF Tachograph_G1. Polecenie może, ale nie musi być 
dostępne w MF lub DF Tachograph_G2. W takim przy­
padku polecenie zostaje zakończone odpowiednim kodem 
błędu, ponieważ klucz prywatny karty (Card.SK) dla proto­
kołu uwierzytelnienia 1. generacji jest dostępny tylko 
w DF_Tachograph G1.  
Używając polecenia INTERNAL AUTHENTICATE, IFD 
może uwierzytelnić kartę. Proces uwierzytelnienia opisano 
w dodatku 11. W procesie tym używa się następujących 
instrukcji:  
TCS_92 Polecenie INTERNAL AUTHENTICATE używa klucza 
prywatnego karty (wybranego niejawnie) do podpisania 
danych uwierzytelniających obejmujących K1 (pierwszy 
element do uzgodnienia kluczy sesyjnych) i RND1, 
a także używa bieżąco wybranego klucza publicznego 
(w ostatnim poleceniu MSE) do zaszyfrowania podpisu 
i utworzenia tokenu uwierzytelniania (dokładniej opisano 
w dodatku 11).  
TCS_93  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  CLA  
INS 1  „88h”  INS  
P1 1  „00h”  P 1  
P2 1  „00h”  P 2  
Lc 1  „10h”  długość danych wysłanych do karty  
#6 – #13  8  „XX..XXh”  wyzwanie użyte do uwierzytelnienia karty  
#14 -#21  8  „XX..XXh”  VU.CHR (zob. dodatek 11)  
Le 1  „80h”  długość danych oczekiwanych z karty  
TCS_94  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
#1-#128  128  „XX..XXh”  token uwierzytelniania karty (zob. dodatek 11)  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli klucza publicznego nie ma w środowisku zabez­
pieczeń, zwróconym stanem przetwarzania jest  „6A88” . 
— Jeżeli klucza prywatnego nie ma w środowisku zabez­
pieczeń, zwróconym stanem przetwarzania jest  „6A88” . 
— Jeżeli VU.CHR nie zgadza się z bieżącym identyfika­
torem klucza publicznego, zwróconym stanem przetwa­
rzania jest  „6A88” . ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 265  
— Jeżeli wybrany klucz prywatny uznany jest za uszko­
dzony, zwróconym stanem przetwarzania jest  „6400”  
lub „6581” . 
▼M1 
TCS_95 Jeżeli uwierzytelnienie poleceniem INTERNAL AUTHEN­
TICATE jest pomyślne, klucz bieżącej sesji 1. generacji 
(o ile istnieje) zostaje skasowany i nie jest dalej dostępny. 
W celu uzyskania nowego klucza sesji 1.generacji 
konieczne jest pomyślne wykonanie uwierzytelnienia pole­
ceniem EXTERNAL AUTHENTICATE dla mechanizmu 
uwierzytelnienia 1. generacji.  
Uwaga:  Zob. dodatek 11 pozycje CSM_193 i CSM_195 
odnośnie do kluczy sesji 2. generacji. Jeżeli ustanowiono 
klucze sesji 2. generacji, a karta do tachografu otrzymuje 
odkryte polecenie APDU INTERNAL AUTHENTICATE, 
przerywa sesję bezpiecznej wymiany komunikatów 2. gene­
racji i niszczy klucze sesji 2. generacji.  
▼B 
3.5.9  EXTERNAL AUTHENTICATE  
Polecenie to jest zgodne z normą ISO/IEC 7816-4.  
Poleceniem EXTERNAL AUTHENTICATE karta może uwierzytelnić 
IFD. Proces uwierzytelnienia opisano w dodatku 11 dla tachograf ów 
1. generacji i 2. generacji (uwierzytelnienie VU).  
TCS_96 Wariant polecenia dla mechanizmu wzajemnego uwierzy­
telnienia 1. generacji jest obsługiwany jedynie przez apli­
kację tachograficzną 1. generacji.  
▼M1 
TCS_97 Wariant polecenia dla wzajemnego uwierzytelnienia VU – 
karta drugiej generacji można wykonać w MF, DF Tacho­
graph i DF Tachograph_G2 (zob. również TCS_34). Jeżeli 
uwierzytelnienie poleceniem 2. generacji EXTERNAL 
AUTHENTICATE jest pomyślne, klucz bieżącej sesji 1. 
generacji (o ile istnieje) zostaje skasowany i nie jest dalej 
dostępny.  
Uwaga:  Zob. dodatek 11 pozycje CSM_193 i CSM_195 
odnośnie do kluczy sesji 2. generacji. Jeżeli ustanowiono 
klucze sesji 2. generacji, a karta do tachografu otrzymuje 
odkryte polecenie APDU EXTERNAL AUTHENTICATE, 
przerywa sesję bezpiecznej wymiany komunikatów 2. gene­
racji i niszczy klucze sesji 2. generacji.  
▼B 
TCS_98  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  CLA  
INS 1  „82h”  INS  
P1 1  „00h”  klucze i algorytmy domniemanie znane  
P2 1  „00h”  
Lc 1  „XXh”  Lc (długość danych wysłanych do karty)  
#6-#(5+L)  L  „XX..XXh”  uwierzytelnienie 1. generacji: kryptogram (zob. dodatek 
11 część A) 
uwierzytelnienie 2. generacji: podpis wygenerowany 
przez IFD (zob. dodatek 11 część B)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 266  
TCS_99  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli CHA bieżąco ustawionego klucza publicznego 
nie jest konkatenacją AID aplikacji tachograficznej 
i typu urządzenia VU, zwróconym stanem przetwa­
rzania jest  „6F00” . 
— Jeżeli bezpośrednio przed poleceniem nie znajduje się 
polecenie GET CHALLENGE, zwróconym stanem 
przetwarzania jest  „6985” . 
Aplikacja tachograficzna 1. generacji może zwracać nastę­
pujące dodatkowe kody błędów:  
— Jeżeli klucza publicznego nie ma w środowisku zabez­
pieczeń, zwróconym stanem przetwarzania jest  „6A88” . 
— Jeżeli klucza prywatnego nie ma w środowisku zabez­
pieczeń, zwróconym stanem przetwarzania jest  „6A88” . 
— Jeżeli weryfikacja kryptogramu daje zły wynik, zwró­
conym stanem przetwarzania jest  „6688” . 
— Jeżeli wybrany klucz prywatny uznany jest za uszko­
dzony, zwróconym stanem przetwarzania jest  „6400”  
lub „6581” . 
Wariant polecenia dla uwierzytelnienia 2. generacji może 
zwracać następujący dodatkowy kod błędu:  
— Jeżeli podpis jest zweryfikowany negatywnie, karta 
zwraca „ 6300 ”. 
3.5.10  GENERAL AUTHENTICATE  
Polecenie to jest używane na potrzeby protokołu uwierzytelnieni a 
mikroprocesora 2. generacji, określonego w dodatku 11 część B, 
i jest zgodne z normą ISO/IEC 7816-4.  
TCS_100 Polecenie może być wykonywane w MF, DF Tachograph 
i DF Tachograph_G2 (zob. również TCS_34).  
TCS_101  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „86h”  
P1 1  „00h”  klucze i protokół domniemanie znane  
P2 1  „00h”  
Lc 1  „NNh”  Lc: długość następnego pola danych  
#6-#(5+L)  L  „7Ch” + L  7C + 
„80h” + L  80 + 
„XX..XXh”  Wartość efemerycznego klucza publicznego kodo­
wana w DER-TLV (zob. dodatek 11) 
VU wysyła obiekty danych w tej kolejności.  
▼M3 
Le 1  „00h”  zgodnie ze specyfikacją w normie ISO/IEC 7816-4  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 267  
TCS_102  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
#1-#L  L  „7Ch” + L  7C + „81h” 
+ „08h” + 
„XX..XXh” + „82h” 
+ L  82 + „XX..XXh”  dane dynamicznego uwierzytelniania kodowane 
w DER-TLV: nonce i token uwierzytelniania 
(zob. dodatek 11)  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Karta zwraca „ 6A80 ”, aby wskazać nieprawidłowe 
parametry w polu danych.  
— Karta zwraca „ 6982 ”, jeżeli uwierzytelnienie polece­
niem EXTERNAL AUTHENTICATE nie zostało 
pomyślnie wykonane.  
Obiekt danych dynamicznego uwierzytelnienia odpowiedzi 
„7Ch”  
— musi być obecny, jeżeli operacja została pomyślnie 
wykonana, tzn. słowa stanu to „ 9000 ”, 
— musi być nieobecny w przypadku błędu wykonania lub 
błędu kontroli, tzn. jeśli słowa stanu mieszczą się 
w zakresie „ 6400 ” – „ 6FFF ”, oraz  
— musi być nieobecny w przypadku ostrzeżenia, tzn. jeśli 
słowa stanu mieszczą się w zakresie „ 6200 ” – „ 63FF ”. 
3.5.11  MANAGE SECURITY ENVIRONMENT  
Poleceniem tym ustawia się klucz publiczny na potrzeby 
uwierzytelnienia.  
3.5.11.1 P a r a p o l e c e n i e – o d p o w i e d ź 1 . g e n e r a c j i  
Polecenie to jest zgodne z normą ISO/IEC 7816-4. Zastosowanie t ego 
polecenia jest ograniczone w porównaniu z poleceniem zdefinio­
wanym w tej normie.  
TCS_103 To polecenie jest obsługiwane jedynie przez aplikację 
tachograficzną 1. generacji.  
TCS_104 Klucz powołany w polu danych MSE pozostaje bieżącym 
kluczem publicznym aż do następnego prawidłowego pole­
cenia MSE, DF zostaje wybrany lub karta zostaje 
zresetowana.  
TCS_105 Jeżeli powołanego klucza nie ma (już) na karcie, środo­
wisko zabezpieczeń pozostaje niezmienione.  
TCS_106  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  CLA  
INS 1  „22h”  INS  
P1 1  „C1h”  P1: powołany klucz ważny dla wszystkich czynności 
kryptograficznych  
P2 1  „B6h”  P2 (powołane dane dotyczące podpisu cyfrowego)  
Lc 1  „0Ah”  Lc: długość następnego pola danych  
#6 1  „83h”  znacznik do powołanego klucza publicznego w przypad­
kach asymetrycznych  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 268  
Bajt Długość  Wartość  Opis  
#7 1  „08h”  długość referencji klucza (identyfikator klucza)  
#8-#15  8  „XX..XXh”  identyfikator klucza określony w dodatku 11  
TCS_107  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli powołany klucz nie znajduje się na karcie, zwró­
conym stanem przetwarzania jest  „6A88” . 
— Jeżeli niektórych oczekiwanych obiektów danych 
brakuje w formacie bezpiecznej wymiany komuni­
katów, zwracany jest stan przetwarzania  „6987” . To 
może zdarzyć się, gdy brakuje znacznika „83h”.  
— Jeżeli pewne obiekty danych są nieprawidłowe, zwró­
conym stanem przetwarzania jest  „6988” . To może 
zdarzyć się, gdy długość identyfikatora klucza różna 
jest od „08h”.  
— Jeżeli wybrany klucz uznany jest za uszkodzony, zwró­
conym stanem przetwarzania jest  „6400”  lub „6581” . 
3.5.11.2 P a r y p o l e c e n i e – o d p o w i e d ź 2 . g e n e r a c j i  
Jeśli chodzi o uwierzytelnienie 2. generacji, karta do tachogra fu obsłu­
guje następujące MSE: Wersje zbioru poleceń, które są zgodne 
z normą ISO/IEC 7816-4. Te wersje poleceń nie są obsługiwane na  
potrzeby uwierzytelnienia 1. generacji.  
3.5.11.2.1 M S E : S E T A T n a p o t r z e b y u w i e r z y t e l n i e n i a 
m i k r o p r o c e s o r a  
Poniższego polecenia MSE:SET AT używa się do wyboru para­
metrów na potrzeby uwierzytelnienia mikroprocesora, które jest wyko­
nywane kolejnym poleceniem General Authenticate.  
TCS_108 Polecenie może być wykonywane w MF, DF Tachograph 
i DF Tachograph_G2 (zob. również TCS_34).  
TCS_109  Komunikat polecenia MSE:SET AT na potrzeby uwie ­
rzytelnienia mikroprocesora  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „22h”  
P1 1  „41h”  przydzielone do uwierzytelnienia wewnętrznego  
P2 1  „A4h”  Uwierzytelnienie  
Lc 1  „NNh”  Lc: długość następnego pola danych  
#6-#(5+L)  L  „80h” + 
„0Ah” + 
„XX..XXh”  Odniesienie do mechanizmu kryptograficznego kodowa­
nego w DER-TLV: identyfikator obiektu uwierzytel­
nienia mikroprocesora (wyłącznie wartość, znacznik 
„06h” jest pomijany). 
Zob. dodatek 1 dla wartości identyfikatorów obiektu; 
Stosuje się zapis bajtowy. Zob. dodatek 11 zawierający 
wytyczne dotyczące sposobu wyboru jednego z tych 
identyfikatorów obiektu.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 269  
3.5.11.2.2 M S E : S E T A T n a p o t r z e b y u w i e r z y t e l n i e n i a V U  
Poniższego polecenia MSE:SET AT używa się do wyboru para­
metrów i kluczy na potrzeby uwierzytelnienia VU, które jest wyk o­
nywane kolejnym poleceniem External Authenticate.  
TCS_110 Polecenie może być wykonywane w MF, DF Tachograph 
i DF Tachograph_G2 (zob. również TCS_34).  
TCS_111  Komunikat polecenia MSE:SET AT na potrzeby uwie ­
rzytelnienia VU  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „22h”  
P1 1  „81h”  przydzielone do uwierzytelnienia zewnętrznego  
P2 1  „A4h”  Uwierzytelnienie  
Lc 1  „NNh”  Lc: długość następnego pola danych  
#6-#(5+L)  L  „80h” + 
„0Ah” + 
„XX..XXh”  Odniesienie do mechanizmu kryptograficznego kodowa­
nego w DER-TLV: identyfikator obiektu uwierzytel­
nienia VU (wyłącznie wartość, znacznik „06h” jest 
pomijany). 
Zob. dodatek 1 dla wartości identyfikatorów obiektu; 
Stosuje się zapis bajtowy. Zob. dodatek 11 zawierający 
wytyczne dotyczące sposobu wyboru jednego z tych 
identyfikatorów obiektu.  
„83h” + 
„08h” + 
„XX..XXh”  kodowane w DER-TL odniesienie klucza publicznego 
VU przez Certificate Holder Reference wymienione 
w jego certyfikacie  
„91h” + 
L 91 + 
„XX..XXh”  kodowana w DER-TLV skompresowana reprezentacja 
efemerycznego klucza publicznego VU do stosowania 
podczas uwierzytelnienia mikroprocesora (zob. dodatek 11)  
3.5.11.2.3 M S E : S E T D S T  
Poniższego polecenia MSE:SET DST używa się do ustawienia klucza  
publicznego  
— albo do weryfikacji podpisu, który znajduje się w następnym p ole­
ceniu PSO: Verify Digital Signature  
— albo do weryfikacji podpisem certyfikatu, który znajduje się 
w następnym poleceniu PSO: Verify Certificate.  
TCS_112 Polecenie może być wykonywane w MF, w DF Tacho­
graph i w DF Tachograph_G2 (zob. również TCS_33).  
TCS_113  Komunikat polecenia MSE:SET DST  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  
INS 1  „22h”  
P1 1  „81h”  przydzielone do weryfikacji  
P2 1  „B6h”  podpis cyfrowy  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 270  
Bajt Długość  Wartość  Opis  
Lc 1  „NNh”  Lc: długość następnego pola danych  
#6-#(5+L)  L  „83h” + 
„08h” + 
„XX...XXh”  kodowane w DER-TLV odniesienie klucza publicznego, 
tj. Certificate Holder Reference w certyfikacie klucza 
publicznego (zob.dodatek 11)  
Dla wszystkich wersji polecenia struktura komunikatu odpowiedzi  
i słowa stanu podane są przez:  
TCS_114  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. Protokół został wybrany i zainicjo­
wany.  
— „6A80”  oznacza nieprawidłowe parametry w polu 
danych dotyczących polecenia.  
— „6A88”  oznacza, że przywołane dane (tj. powołany 
klucz) nie są dostępne.  
▼M1 
— Jeżeli currentAuthenticatedTime karty jest późniejszy 
niż data upływu ważności wybranego klucza publicz­
nego, zwróconym stanem przetwarzania jest „ 6A88 ”. 
Uwaga:  W przypadku polecenia MSE: SET AT na 
potrzeby uwierzytelnienia VU powołany klucz to klucz 
publiczny VU_MA. Karta ustawia klucz publiczny 
VU_MA do użytku, jeżeli jest on dostępny w jej pamięci, 
który pokrywa się z odniesieniem do posiadacza certyfi­
katu (CHR) podanym w polu danych dotyczących pole­
cenia (karta może zidentyfikować klucze publiczne 
VU_MA za pomocą pola CHA certyfikatu). Karta zwraca 
„6A 88” temu poleceniu, w przypadku gdy jest dostępny 
jedynie klucz publiczny VU_Sign lub nie jest dostępny 
żaden klucz publiczny przyrządu rejestrującego. Zob. defi­
nicja pola CHA w dodatku 11 i typu danych equipment­
Type w dodatku 1.  
Analogicznie w przypadku polecenia MSE: SET DST 
odwołującego się do EQT (tzn. przyrządu rejestrującego 
lub karty), które jest przesyłane do karty kontrolnej, 
zgodnie z CSM_234 powołany klucz to zawsze klucz 
EQT_Sign, który musi być stosowany na potrzeby weryfi­
kacji podpisu cyfrowego. Zgodnie z rys. 13 w dodatku 11 
karta kontrolna będzie zawsze przechowywać odpowiedni 
klucz publiczny EQT_Sign. W pewnych przypadkach karta 
kontrolna może przechowywać odpowiadający klucz 
publiczny EQT_MA. Karta kontrolna musi zawsze usta­
wiać klucz publiczny EQT_Sign do użytku, gdy otrzyma 
polecenie MSE: SET DST.  
▼B 
3.5.12  PSO: HASH  
Polecenia tego używa się do przesłania na kartę wyniku obliczeń  
funkcji skrótu dla niektórych danych. Polecenia tego używa się do 
weryfikowania podpisów cyfrowych. Wartość skrótu jest tymczasow o 
zachowywana dla kolejnego polecenia PSO: Verify Digital Signatu re. 
Polecenie to jest zgodne z normą ISO/IEC 7816-8. Zastosowanie t ego 
polecenia jest ograniczone w porównaniu z poleceniem zdefinio­
wanym w tej normie.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 271  
Tylko karta kontrolna jest zobowiązana obsługiwać to polecenie w DF 
Tachograph i DF Tachograph_G2.  
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować  tego 
polecenia. Polecenie może, ale nie musi być dostępne w MF.  
Aplikacja karty kontrolnej 1. generacji obsługuje tylko SHA-1.  
TCS_115 Tymczasowo zachowana wartość skrótu jest usuwana, 
jeżeli nowa wartość skrótu zostaje obliczona za pomocą 
polecenia PSO: HASH, jeżeli DF jest wybrany oraz jeżeli 
karta do tachografu jest zresetowana.  
TCS_116  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  CLA  
INS 1  „2Ah”  wykonanie operacji zabezpieczającej  
P1 1  „90h”  zwróć kod skrótu  
P2 1  „A0h”  Znacznik: pole danych zawiera DO stosowne do obli­
czania skrótu  
Lc 1  „XXh”  Lc długość następnego pola danych  
#6 1  „90h”  znacznik dla kodu skrótu  
#7 1  „XXh”  długość L kodu skrótu: 
„14h” dla aplikacji 1. generacji (zob. dodatek 11 część 
A) 
„20h”, „30h” lub „40h” dla aplikacji 2. generacji (zob. 
dodatek 11 część B)  
#8-#(7+L)  L  „XX..XXh”  kod skrótu  
TCS_117  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli brakuje niektórych oczekiwanych obiektów 
danych (jak określone powyżej), zwracany jest stan 
przetwarzania  „6987” . To może zdarzyć się, jeżeli 
brakuje jednego ze znaczników „90h”.  
— Jeżeli pewne obiekty danych są nieprawidłowe, zwró­
conym stanem przetwarzania jest  „6988” . Ten błąd 
zdarza się, gdy wymagany znacznik jest obecny, ale 
ma długość różną niż „14h” dla SHA-1, „20h” dla 
SHA-256, „30h” dla SHA-384, „40h” dla SHA-512 
(aplikacja 2. generacji).  
3.5.13  PERFORM HASH of FILE  
Polecenie to nie jest zgodne z normą ISO/IEC 7816-8. Tym samym 
bajt CLA w tym poleceniu wskazuje na zastrzeżone użycie polecen ia 
PERFORM SECURITY OPERATION/HASH.  
Tylko karta kierowcy i karta warsztatowa są zobowiązane obsługi wać 
to polecenie w DF Tachograph i DF Tachograph_G2.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 272  
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować  tego 
polecenia. Jeżeli przedsiębiorstwo lub karta kontrolna realizuj ą to 
polecenie, odbywa się to zgodnie z opisem w niniejszym rozdzial e. 
Polecenie może, ale nie musi być dostępne w MF. W takim przy­
padku polecenie realizowane jest zgodnie z opisem w niniejszym 
rozdziale, tzn. nie pozwala na obliczenie wartości skrótu, ale zostaje 
zakończone odpowiednim kodem błędu.  
TCS_118 Polecenia PERFORM HASH of FILE używa się do obli­
czenia skrótu obszaru danych aktualnie wybranego przezro­
czystego pliku EF.  
TCS_119 Karta do tachografu obsługuje to polecenie jedynie dla EF, 
które są wymienione w rozdziale 4 pod DF_Tachograph 
i DF_Tachograph_G2 z poniższym wyjątkiem. Karta do 
tachografu nie obsługuje polecenia dla EF Sensor_Installa­
tion_Data w DF_Tachograph_G2.  
TCS_120 Wynik operacji obliczania skrótu przechowywany jest 
tymczasowo na karcie. Następnie może być używany do 
otrzymania podpisu cyfrowego pliku przy pomocy pole­
cenia PSO: COMPUTE DIGITAL SIGNATURE.  
▼M1 
TCS_121 Tymczasowo zachowana wartość skrótu pliku jest usuwana,  
jeżeli nowa wartość skrótu zostaje obliczona za pomocą 
polecenia PERFORM HASH of FILE, jeżeli DF jest 
wybrany oraz jeżeli karta do tachografu jest zresetowana.  
▼B 
TCS_122 Aplikacja tachograficzna 1. generacji obsługuje SHA-1.  
▼M1 
TCS_123 Aplikacja tachograficzna 2. generacji musi obsługiwać 
algorytm SHA-2 (SHA-256, SHA-384 lub SHA-512), okre­ 
ślony za pomocą mechanizmu szyfrowania w dodatku 11 
część B dla klucza podpisu karty Card_Sign.  
▼B 
TCS_124  Komunikat polecenia  
▼M1 
Bajt Długość  Wartość  Opis  
CLA  1  „80h”  CLA  
INS 1  „2Ah”  wykonanie operacji zabezpieczającej  
P1 1  „90h”  znacznik: Hash  
P2 1  „00h”  algorytm niejawnie znany 
W przypadku aplikacji tachograficznej 1. generacji: 
SHA-1 
W przypadku aplikacji tachograficznej 2. generacji: algo­
rytm SHA-2 (SHA-256, SHA-384 lub SHA-512) zdefi­
niowany za pomocą mechanizmu szyfrowania w dodatku 
11 część B dla klucza podpisu karty Card_Sign  
▼B 
TCS_125  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli bieżący EF nie dopuszcza tego polecenia (EF 
Sensor_Installation_Data in DF Tachograph_G2), zwró­
conym stanem przetwarzania jest  „6985” . ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 273  
— Jeżeli wybrany plik EF uznany jest za uszkodzony 
(błąd atrybutów pliku lub błąd integralności przechowy­
wanych danych), zwróconym stanem przetwarzania jest 
„6400 ” lub  „6581” . 
— Jeżeli wybrany plik nie jest plikiem przezroczystym, 
zwróconym stanem przetwarzania jest „ 6986 ”. 
3.5.14  PSO: COMPUTE DIGITAL SIGNATURE  
▼M1 
Polecenia tego używa się do obliczania podpisu cyfrowego z obli czo­
nego wcześniej kodu skrótu (zob. polecenie PERFORM HASH of 
FILE, pkt 3.5.13).  
Tylko karta kierowcy i karta warsztatowa są zobowiązane obsługi wać 
to polecenie w DF Tachograph i DF Tachograph_G2.  
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować  tego 
polecenia. W przypadku aplikacji tachograficznej 2. generacji j edynie 
karta kierowcy i karta warsztatowa mają klucz podpisu 2. genera cji, 
inne karty nie mają możliwości skutecznego wykonania polecenia 
i kończą je odpowiednim kodem błędu.  
Polecenie może, ale nie musi być dostępne w MF. Jeżeli poleceni e nie 
jest dostępne w MF, zostaje zakończone odpowiednim kodem błędu.  
Polecenie to jest zgodne z normą ISO/IEC 7816-8. Zastosowanie t ego 
polecenia jest ograniczone w porównaniu z poleceniem zdefinio­
wanym w tej normie.  
▼B 
TCS_126 Polecenie to nie oblicza podpisu cyfrowego z obliczoneg o 
wcześniej kodu skrótu poleceniem PSO: HASH.  
TCS_127 Klucza prywatnego karty, który jest niejawnie znany kar cie, 
używa się do obliczania podpisu cyfrowego.  
TCS_128 Aplikacja tachograficzna 1. generacji wykonuje podpis 
cyfrowy metodą wypełniania zgodną z PKCS1 (zob. 
dokładniejszy opis w dodatku 11).  
TCS_129 Aplikacja tachograficzna 2. generacji oblicza podpis 
cyfrowy oparty na krzywej eliptycznej (zob. dokładniejszy 
opis w dodatku 11).  
TCS_130  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  CLA  
INS 1  „2Ah”  wykonanie operacji zabezpieczającej  
P1 1  „9Eh”  zwracany podpis cyfrowy  
P2 1  „9Ah”  znacznik: pole danych zawiera dane do podpisania. Gdy 
nie zawarto pola danych, przyjmuje się, że dane te są już 
na karcie (skrót pliku).  
Le 1  „NNh”  długość oczekiwanego podpisu  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 274  
TCS_131  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
#1-#L  L  „XX..XXh”  podpis uprzednio obliczonego skrótu  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli niejawnie wybrany klucz prywatny uznany jest za 
uszkodzony, zwróconym stanem przetwarzania jest 
„6400 ” lub  „6581” . 
— Jeżeli skrót, który został obliczony w ramach poprzed­
niego polecenia Perform Hash of File nie jest dostępny, 
zwróconym stanem przetwarzania jest  „6985” . 
3.5.15  PSO: VERIFY DIGITAL SIGNATURE  
Polecenia tego używa się do weryfikowania podpisu cyfrowego 
dostarczanego jako dane wejściowe, którego skrót jest znany kar cie. 
Algorytm podpisu jest niejawnie znany karcie.  
Polecenie to jest zgodne z normą ISO/IEC 7816-8. Zastosowanie t ego 
polecenia jest ograniczone w porównaniu z poleceniem zdefinio­
wanym w tej normie.  
Tylko karta kontrolna jest zobowiązana obsługiwać to polecenie w DF 
Tachograph i DF Tachograph_G2.  
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować  tego 
polecenia. Polecenie może, ale nie musi być dostępne w MF.  
TCS_132 Polecenie VERIFY DIGITAL SIGNATURE zawsze używa 
klucza publicznego wybranego poprzednim poleceniem 
Manage Security Environment MSE: Set DST i poprzednim 
kodem skrótu wprowadzonym poleceniem PSO: HASH.  
TCS_133  Komunikat polecenia  
▼M1 
Bajt Długość  Wartość  Opis  
CLA  1  „00h”  CLA  
INS 1  „2Ah”  wykonanie operacji zabezpieczającej  
P1 1  „00h”  
P2 1  „A8h”  Znacznik: pole danych zawiera obiekty DO stosowne do 
weryfikacji  
Lc 1  „XXh”  Lc długość następnego pola danych  
#6 1  „9Eh”  znacznik dla podpisu cyfrowego  
#7 lub 
#7-#8  L „NNh” lub 
„81 NNh”  Długość podpisu cyfrowego (L ma 2 bajty, jeżeli podpis 
cyfrowy jest dłuższy niż 127 bajtów): 
128 bajtów kodowanych zgodnie z dodatkiem 11 część 
A dla aplikacji tachograficznej 1. generacji. 
w zależności od wybranej krzywej dla aplikacji tacho­
graficznej 2. generacji (zob. dodatek 11 część B).  
#(7+L)- 
#(6+L+NN)  NN „XX..XXh”  treść podpisu cyfrowego  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 275  
TCS_134  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— Jeżeli podpis jest zweryfikowany negatywnie, zwró­
conym stanem przetwarzania jest  „6688” . Proces wery­
fikacji opisano w dodatku 11.  
— Jeżeli nie wybrano klucza publicznego, zwróconym 
stanem przetwarzania jest  „6A88” . 
— Jeżeli brakuje niektórych oczekiwanych obiektów 
danych (jak określone powyżej), zwracany jest stan 
przetwarzania  „6987” . To może się zdarzyć, gdy 
brakuje jednego z wymaganych znaczników.  
— Jeżeli kod skrótu nie jest dostępny dla przetwarzania 
polecenia (w wyniku poprzedniego polecenia PSO: 
Hash), zwróconym stanem przetwarzania jest  „6985” . 
— Jeżeli pewne obiekty danych są nieprawidłowe, zwró­
conym stanem przetwarzania jest  „6988” . To może się 
zdarzyć, gdy długość jednego z wymaganych obiektów 
danych jest nieprawidłowa.  
— Jeżeli wybrany klucz publiczny uznany jest za uszko­
dzony, zwróconym stanem przetwarzania jest  „6400”  
lub „6581” . 
▼M1 
— Jeżeli wybrany klucz publiczny (używany do weryfi­
kacji podpisu cyfrowego) ma CHA.LSB (Certificate­
HolderAuthorisation.equipmentType), które nie jest 
odpowiednie dla weryfikacji podpisu cyfrowego 
zgodnie z dodatkiem 11, zwróconym stanem przetwa­
rzania jest „ 6985 ”. 
▼B 
3.5.16  PROCESS DSRC MESSAGE  
Polecenia tego używa się do weryfikowania integralności i auten tycz­
ności komunikatu DSRC oraz odszyfrowania danych przekazywanych 
z VU do organu kontrolnego lub warsztatu poprzez łącze DSRC. 
Karta wyprowadza klucz szyfrujący oraz klucz MAC stosowane do 
zabezpieczenia komunikatu DSRC zgodnie z opisem w dodatku 11 
część B rozdział 13.  
Tylko karta kontrolna i karta warsztatowa są zobowiązane obsług iwać 
to polecenie w DF Tachograph_G2.  
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować  tego 
polecenia, lecz nie mogą mieć klucza głównego DSRC. Dlatego też  
karty te nie mogą wykonać pomyślnie polecenia, ale kończą je od po­
wiednim kodem błędu.  
Polecenie może, ale nie musi być dostępne w MF lub DF Tachograp h. 
W takim przypadku polecenie zostaje zakończone odpowiednim 
kodem błędu.  
TCS_135 Klucz główny DSRC jest dostępny tylko w DF Tacho­
graph_G2, tzn. karta kontrolna i karta warsztatowa obsłu­
gują pomyślne wykonanie polecenia tylko w DF Tacho­
graph_G2.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 276  
TCS_136 Polecenie służy jedynie do odszyfrowania danych i weryf i­
kacji kryptograficznej sumy kontrolnej, ale nie ma interpre­
tować danych wejściowych.  
TCS_137 Kolejność obiektów danych w polu danych dotyczących 
polecenia jest ustalona w niniejszej specyfikacji.  
TCS_138  Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „80h”  zastrzeżone CLA  
INS 1  „2Ah”  wykonanie operacji zabezpieczającej  
P1 1  „80h”  dane reakcji: wartość odkryta  
P2 1  „B0h”  dane dotyczące polecenia: wartość odkryta kodowana 
w BER-TLV i z uwzględnieniem obiektów danych SM  
Lc 1  „NNh”  Lc długość następnego pola danych  
#6-#(5+L)  L  „87h” + L  87 + 
„XX..XXh”  Kodowany w DER-TLV bajt wskaźnika wypełnienia, 
a następnie zaszyfrowany payload tachografu. Na 
potrzeby bajtu wskaźnika wypełnienia używa się wartości 
„00h” („brak dalszych wskazań” zgodnie z normą ISO/ 
IEC 7816-4:2013 tabela 52). Informacje dotyczące mecha­
nizmu szyfrowania znajdują się w dodatku 11 część B 
rozdział 13. 
Dozwolone wartości dla długości L  87 to wielokrotności 
długości bloku AES plus 1 dla bajtu wskaźnika wypeł­
nienia, tj. od 17 bajtów do 193 bajtów włącznie.  
Uwaga:  zob. ISO/IEC 7816-4:2013 tabela 49 dla 
obiektów danych SM ze znacznikiem „87h”.  
„81h” + „10h”  kodowany w DER-TLV referencyjny szablon kontrolny, 
zagnieżdżający konkatenację następujących elementów 
danych (zob. dodatek 1 DSRCSecurityData oraz dodatek 
11 część B rozdział 13): 
— 4-bajtowy znacznik czasu 
— 3-bajtowy licznik 
— 8-bajtowy numer seryjny VU 
— 1-bajtowa wersja klucza głównego DSRC  
Uwaga:  zob. ISO/IEC 7816-4:2013 tabela 49 dla 
obiektów danych SM ze znacznikiem „81h”.  
„8Eh” + L  8E + 
„XX..XXh”  Kodowany w DER-TLV MAC nad komunikatem DSRC. 
Informacje dotyczące algorytmu i obliczania MAC znaj­
dują się w dodatku 11 część B rozdział 13.  
Uwaga:  zob. ISO/IEC 7816-4:2013 tabela 49 dla 
obiektów danych SM ze znacznikiem „8Eh”.  
▼M3 
Le 1  „00h”  zgodnie ze specyfikacją w normie ISO/IEC 7816-4  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 277  
TCS_139  Komunikat odpowiedzi  
Bajt Długość  Wartość  Opis  
#1-#L  L  „XX..XXh”  nieobecny (w przypadku błędu) lub dane odszyfrowane 
(wypełnienie usunięte)  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli polecenie zostało pomyślnie wykonane, karta 
zwraca „ 9000 ”. 
— „6A80”  oznacza nieprawidłowe parametry w polu 
danych dotyczących polecenia (używane także w przy­
padku, gdy obiekty danych nie są wysyłane w okre­ 
ślonej kolejności).  
— „6A88”  oznacza, że przywołane dane nie są dostępne, 
tzn. nie jest dostępny powołany klucz główny DSRC.  
— „6900”  oznacza, że nie udało się wykonać weryfikacji 
kryptograficznej sumy kontrolnej lub odszyfrowywania 
danych.  
▼M1 
— „ 6985 ” wskazuje, że 4-bajtowy znacznik czasu podany 
w polu danych dotyczących polecenia jest wcześniejszy 
niż cardValidityBegin lub późniejszy niż cardExpiry­
Date.  
▼B 
4. STRUKTURA KART DO TACHOGRAFÓW  
W niniejszym punkcie opisano struktury plików na kartach do tac ho­
grafów przeznaczonych do gromadzenia dostępnych danych.  
Nie stanowi to opisu wewnętrznych struktur właściwych dla produ ­
centa, takich jak nagłówki plików, ani sposobu gromadzenia 
elementów danych tylko do użytku wewnętrznego (takich jak
  
,
 ,
  
lub
 ) i manipulowania tymi elementami danych.  
TCS_140 Karta do tachografu 2. generacji jest hostem dla pliku głów­
nego MF oraz aplikacji tachograficznej 1. generacji i 2. 
generacji tego samego typu (np. aplikacje karty kierowcy).  
TCS_141 Karta do tachografu musi obsługiwać co najmniej minimal ną 
liczbę rekordów określoną dla odpowiednich aplikacji i nie 
może obsługiwać więcej rekordów niż maksymalna liczba 
rekordów określona dla odpowiednich aplikacji.  
▼M3 
Minimalne i maksymalne liczby rekordów zostały okre­ 
ślone w niniejszym rozdziale dla poszczególnych aplikacji. 
W przypadku wersji 2 generacji 2 kart kierowcy i warsz­
tatowej aplikacja generacji 1 obsługuje maksymalną liczbę 
rekordów określoną w TCS_150 i TCS_158.  
▼B 
Jeśli chodzi o warunki zabezpieczenia stosowane w zasa­
dach dostępu w niniejszym rozdziale, zob. rozdział 3.3. 
Ogólnie tryb dostępu „odczyt” oznacza polecenie READ 
BINARY z parzystym i (jeżeli obsługiwane) z nieparzystym 
bajtem INS, z wyjątkiem EF Sensor_Installation_Data na 
karcie warsztatowej (zob. TCS_156 i TCS_160). Tryb 
dostępu „aktualizacja” oznacza polecenie Update Binary 
z parzystym i (jeżeli obsługiwany) z nieparzystym bajtem 
INS, a tryb dostępu „wybór” – polecenie SELECT.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 278  
4.1. Plik g łówny MF  
TCS_142 Po personalizacji plik główny MF ma następującą, trwałą  
strukturę plików i zasady dostępu do plików:  
Uwaga:  The short EF identifier SFID podany jest jako 
liczba dziesiętna, np. wartość 30 odpowiada zapisowi 
11110 w systemie binarnym.
  
W tabeli zastosowano następujący skrót dla warunku 
zabezpieczenia:  
SC1 ALW OR SM-MAC-G2  
TCS_143 Wszystkie struktury plików EF są przezroczyste.  
TCS_144 Plik główny (MF) ma następującą strukturę danych:
  
TCS_145 Plik elementarny EF DIR zawiera następujące obiekty 
danych dotyczące aplikacji: „61 08 4F 06 FF 54 41 43 
48 4F 61 08 4F 06 FF 53 4D 52 44 54”  
TCS_146 Plik elementarny EF ATR/INFO musi być obecny, jeżeli 
karta do tachografu wskaże w swojej ATR, że obsługuje 
pola o rozszerzonej długości. W takim przypadku EF ATR/ 
INFO zawiera obiekt danych z informacjami o rozszerzonej 
długości (DO„7F66”) zgodnie z opisem w normie ISO/IEC 
7816-4:2013 pkt 12.7.1.  
TCS_147 Plik elementarny EF Extended_Length musi być obecny, 
jeżeli karta do tachografu wskaże w swojej ATR, że obsłu­
guje pola o rozszerzonej długości. W takim przypadku EF 
zawiera następujący obiekt danych: „02 01 xx”, gdzie 
wartość „xx” wskazuje, czy pola o rozszerzonej długości 
są obsługiwane dla protokołu T = 1 lub T = 0.  
Wartość „01” oznacza obsługiwanie pola o rozszerzonej 
długości dla protokołu T = 1.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 279  
Wartość „10” oznacza obsługiwanie pola o rozszerzonej 
długości dla protokołu T = 0.  
Wartość „11” oznacza obsługiwanie pola o rozszerzonej 
długości dla protokołu T = 1 i T = 0.  
4.2. Aplikacje karty kierowcy  
4.2.1  Aplikacja karty kierowcy 1. generacji  
TCS_148 Po personalizacji aplikacja karty kierowcy 1. generacji  ma 
trwałą strukturę plików i zasady dostępu do plików, jak 
określono poniżej:
  
W tabeli zastosowano następujące skróty dla warunków 
bezpieczeństwa:  
SC1 ALW OR SM-MAC-G2  
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2  
SC3 SM-MAC-G1 OR SM-MAC-G2  
TCS_149 Wszystkie struktury plików EF są przezroczyste.  
TCS_150 Aplikacja karty kierowcy 1. generacji ma następującą st ruk­
turę danych:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 280
  
► (1) (2) M3 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 281
  
▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 282  
TCS_151 W tabeli poniżej podano wartości odnoszące się do tabel i 
powyżej, wyznaczające minimalne i maksymalne liczby 
rekordów, które musi stosować struktura danych karty 
kierowcy dla aplikacji 1. generacji:
  
4.2.2  Aplikacja karty kierowcy 2. generacji  
▼M3 
TCS_152 Po personalizacji aplikacja karty kierowcy 2. generacji  ma 
trwałą strukturę plików i zasady dostępu do plików, jak 
określono poniżej:  
Uwagi:  
— Krótki identyfikator EF (SFID) podany jest jako liczba 
dziesiętna, np. wartość 30 odpowiada zapisowi 11110 
w systemie binarnym.  
— Elementy: EF Application_Identification_V2, EF 
Places_Authentication, EF GNSS_Places_Authentication, 
EF Border_Crossings, EF Load_Unload_Operations, EF 
VU_Configuration oraz EF Load_Type_Entries są obecne 
tylko w wersji 2 generacji 2 kart kierowcy.  
— cardStructureVersion w EF Application_Identification jest 
równy {01 01} dla wersji 2 generacji 2 kart kierowcy, 
natomiast jest równy {01 00} dla wersji 1 generacji 2 
kart kierowcy.
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 283  
W tabeli zastosowano następujące skróty dla warunków 
bezpieczeństwa:  
SC1 ALW OR SM-MAC-G2  
SC5 Dla polecenia Read Binary z parzystym bajtem INS: 
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2  
Dla polecenia Read Binary z nieparzystym bajtem 
INS (jeżeli obsługiwane): NEV  
▼B 
TCS_153 Wszystkie struktury plików EF są przezroczyste.  
▼M3 
TCS_154 Aplikacja karty kierowcy 2. generacji ma następującą st ruk­
turę danych:
  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 284
  
▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 285
  
▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 286  
TCS_155 W tabeli poniżej podano wartości odnoszące się do tabel i 
powyżej, wyznaczające minimalne i maksymalne liczby 
rekordów, które musi stosować struktura danych karty 
kierowcy dla aplikacji 2. generacji:  
▼M3 
Min.  Maks.  
n 1 NoOfEventsPerType  1 2  1 2  
n 2 NoOfFaultsPerType  2 4  2 4  
n 3 NoOfCardVehicleRecords  200  200  
n 4 NoOfCardPlaceRecords  112  112  
n 6 CardActivityLengthRange  13776 bajtów 
(56 dni * 117 zmian 
czynności)  13776 bajtów 
(56 dni * 117 zmian 
czynności)  
n 7 NoOfCardVehicleUnitRecords  200  200  
n 8 NoOfGNSSADRecords  336  336  
n 9 NoOfSpecificConditionRecords  112  112  
n 10 NoOfBorderCrossingRecords  1120  1120  
n 11 NoOfLoadUnloadRecords  1624  1624  
n 12 NoOfLoadTypeEntryRecords  336  336  
n 13 VuConfigurationLengthRange  3072 bajty  3072 bajty  
▼B 
4.3. Aplikacje karty warsztatowej  
4.3.1  Aplikacja karty warsztatowej 1. generacji  
TCS_156 Po personalizacji aplikacja karty warsztatowej 1. gener acji 
ma trwałą strukturę plików i zasady dostępu do plików, jak 
określono poniżej.
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 287  
W tabeli zastosowano następujące skróty dla warunków 
bezpieczeństwa:  
SC1 ALW OR SM-MAC-G2  
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2  
SC3 SM-MAC-G1 OR SM-MAC-G2  
▼M1 
SC4 Dla polecenia READ BINARY z parzystym bajtem 
INS:  
(SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR  
(SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)  
Dla polecenia READ BINARY z nieparzystym 
bajtem INS (jeżeli obsługiwane): NEV  
▼B 
TCS_157 Wszystkie struktury plików EF są przezroczyste.  
TCS_158 Aplikacja karty warsztatowej 1. generacji ma następując ą 
strukturę danych:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 288
  
▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 289
  
▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 290
  
TCS_159 W tabeli poniżej podano wartości odnoszące się do tabel i 
powyżej, wyznaczające minimalne i maksymalne liczby 
rekordów, które musi stosować struktura danych karty 
warsztatowej dla aplikacji 1. generacji:
  
4.3.2  Aplikacja karty warsztatowej 2. generacji  
▼M3 
TCS_160 Po personalizacji aplikacja karty warsztatowej 2. gener acji 
ma trwałą strukturę plików i zasady dostępu do plików, jak 
określono poniżej.  
Uwagi:  
— Krótki identyfikator EF (SFID) podany jest jako liczba 
dziesiętna, np. wartość 30 odpowiada zapisowi 11110 
w systemie binarnym.  
— Elementy: EF Application_Identification_V2, EF 
Places_Authentication, EF GNSS_Places_Authentica­
tion, EF Border_Crossings, EF Load_Unload_Opera­
tions, EF Load_Type_Entries, EF VU_Configuration 
oraz EF Calibration_Add_Data są obecne tylko w wersji 
2 generacji 2 kart warsztatowych.  
— cardStructureVersion w EF Application_Identification 
jest równy {01 01} dla wersji 2 generacji 2 kart warsz­
tatowych, natomiast jest równy {01 00} dla wersji 1 
generacji 2 kart warsztatowych.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 291
  
W tabeli zastosowano następujące skróty dla warunków 
bezpieczeństwa:  
SC1 ALW OR SM-MAC-G2  
SC5 Dla polecenia Read Binary z parzystym bajtem INS: 
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2  
Dla polecenia Read Binary z nieparzystym bajtem 
INS (jeżeli obsługiwane): NEV  
▼B 
TCS_161 Wszystkie struktury plików EF są przezroczyste.  
TCS_162 Aplikacja karty warsztatowej 2. generacji ma następując ą 
strukturę danych:  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 292
  
▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 293
  
▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 294
  
▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 295
  
▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 296  
TCS_163 W tabeli poniżej podano wartości odnoszące się do tabel i 
powyżej, wyznaczające minimalne i maksymalne liczby 
rekordów, które musi stosować struktura danych karty 
warsztatowej dla aplikacji 2. generacji:  
▼M3 
Min.  Maks.  
n 1 NoOfEventsPerType  3  3  
n 2 NoOfFaultsPerType  6  6  
n 3 NoOfCardVehicleRecords  8  8  
n 4 NoOfCardPlaceRecords  8  8  
n 5 NoOfCalibrationRecords  255  255  
n 6 CardActivityLengthRange  492 bajty 
(1 dzień * 240 zmian 
czynności)  492 bajty 
(1 dzień *240 zmian 
czynności)  
n 7 NoOfCardVehicleUnitRecords  8  8  
n 8 NoOfGNSSADRecords  2 4  2 4  
n 9 NoOfSpecificConditionRecords  4  4  
n 10 NoOfBorderCrossingRecords  4  4  
n 11 NoOfLoadUnloadRecords  8  8  
n 12 NoOfLoadTypeEntryRecords  4  4  
n 13 VuConfigurationLengthRange  3072 bajty  3072 bajty  
▼B 
4.4. Aplikacje karty kontrolnej  
4.4.1  Aplikacja karty kontrolnej 1. generacji  
TCS_164 Po personalizacji aplikacja karty kontrolnej 1. generac ji ma 
trwałą strukturę plików i zasady dostępu do plików, jak 
określono poniżej.
  
W tabeli zastosowano następujące skróty dla warunków 
bezpieczeństwa:  
SC1 ALW OR SM-MAC-G2  
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2  
SC3 SM-MAC-G1 OR SM-MAC-G2  
SC6 EXT-AUT-G1 OR SM-MAC-G1 OR SM-MAC-G2  
TCS_165 Wszystkie struktury plików EF są przezroczyste.  
TCS_166 Aplikacja karty kontrolnej 1. generacji ma następującą 
strukturę danych:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 297
  
TCS_167 W tabeli poniżej podano wartości odnoszące się do tabel i 
powyżej, wyznaczające minimalne i maksymalne liczby 
rekordów, które musi stosować struktura danych karty 
kontrolnej dla aplikacji 1. generacji:
  
4.4.2  Aplikacja karty kontrolnej 2. generacji  
▼M3 
TCS_168 Po personalizacji aplikacja karty kontrolnej 2. generac ji ma 
trwałą strukturę plików i zasady dostępu do plików, jak 
określono poniżej.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 298  
Uwagi:  
— krótki identyfikator EF (SFID) podany jest jako liczba 
dziesiętna, np. wartość 30 odpowiada zapisowi 11110 
w systemie binarnym.  
— Elementy: EF Application_Identification_V2 oraz EF 
VU_Configuration są obecne tylko w wersji 2 generacji 
2 kart kontrolnych,  
— cardStructureVersion w EF Application_Identification 
jest równy {01 01} dla wersji 2 generacji 2 kart kontro­
lnych, natomiast jest równy {01 00} dla wersji 1 gene­
racji 2 kart kontrolnych.
  
W tabeli zastosowano następujące skróty dla warunków 
bezpieczeństwa:  
SC1 ALW OR SM-MAC-G2  
SC5 Dla polecenia Read Binary z parzystym bajtem 
INS: SM-C-MAC-G2 AND SM-R-ENC-MAC- 
G2 
Dla polecenia Read Binary z nieparzystym 
bajtem INS (jeżeli obsługiwane): NEV  
▼B 
TCS_169 Wszystkie struktury plików EF są przezroczyste.  
TCS_170 Aplikacja karty kontrolnej 2. generacji ma następującą 
strukturę danych:  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 299
  
▼B 
TCS_171 W tabeli poniżej podano wartości odnoszące się do tabel i 
powyżej, wyznaczające minimalne i maksymalne liczby 
rekordów, które musi stosować struktura danych karty 
kontrolnej dla aplikacji 2. generacji:  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 300  
Min.  Maks.  
n 7 NoOfControlActivityRecords  230  520  
n 13 VuConfigurationLengthRange  3072 ajty  3072 bajty  
▼B 
4.5. Aplikacje karty firmowej  
4.5.1  Aplikacja karty firmowej 1. generacji  
TCS_172 Po personalizacji aplikacja karty firmowej 1. generacji  ma 
trwałą strukturę plików i zasady dostępu do plików, jak 
określono poniżej.
  
W tabeli zastosowano następujące skróty dla warunków 
bezpieczeństwa:  
SC1 ALW OR SM-MAC-G2  
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2  
SC3 SM-MAC-G1 OR SM-MAC-G2  
SC6 EXT-AUT-G1 OR SM-MAC-G1 OR SM-MAC-G2  
TCS_173 Wszystkie struktury plików EF są przezroczyste.  
TCS_174 Aplikacja karty firmowej 1. generacji ma następującą st ruk­
turę danych:
  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 301  
TCS_175 W tabeli poniżej podano wartości odnoszące się do tabel i 
powyżej, wyznaczające minimalne i maksymalne liczby 
rekordów, które musi stosować struktura danych karty 
firmowej dla aplikacji 1. generacji:
  
4.5.2  Aplikacja karty firmowej 2. generacji  
▼M3 
TCS_176 Po personalizacji aplikacja karty firmowej 2. generacji  ma 
trwałą strukturę plików i zasady dostępu do plików, jak 
określono poniżej.  
Uwagi:  
— krótki identyfikator EF (SFID) podany jest jako liczba 
dziesiętna, np. wartość 30 odpowiada zapisowi 11110 
w systemie binarnym.  
— Elementy: EF Application_Identification_V2 oraz EF 
VU_Configuration są obecne tylko w wersji 2 generacji 
2 kart firmowych,  
— cardStructureVersion w EF Application_Identification 
jest równy {01 01} dla wersji 2 generacji 2 kart firmo­
wych, natomiast jest równy {01 00} dla wersji 1 gene­
racji 2 kart firmowych.
  
W tabeli zastosowano następujące skróty dla warunków 
bezpieczeństwa:  
SC1 ALW OR SM-MAC-G2  
SC5 Dla polecenia Read Binary z parzystym bajtem 
INS: SM-C-MAC-G2 AND SM-R-ENC-MAC- 
G2 
Dla polecenia Read Binary z nieparzystym 
bajtem INS (jeżeli obsługiwane): NEV  
▼B 
TCS_177 Wszystkie struktury plików EF są przezroczyste.  
TCS_178 Aplikacja karty firmowej 2. generacji ma następującą st ruk­
turę danych:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 302
  
▼B 
TCS_179 W tabeli poniżej podano wartości odnoszące się do tabel i 
powyżej, wyznaczające minimalne i maksymalne liczby 
rekordów, które musi stosować struktura danych karty 
firmowej dla aplikacji 2. generacji:  
▼M3 
Min.  Maks.  
n 8 NoOfCompanyActivityRecords  230  520  
n 13 VuConfigurationLengthRange  3072 bajty  3072 bajty  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 303  
Dodatek 3  
PIKTOGRAMY  
PIC_001 Tachograf może opcjonalnie używać następujących piktogr amów 
i kombinacji piktogramów (lub piktogramów i kombinacji wystarcz a­
jąco do nich podobnych, aby można je było z nimi jednoznacznie 
identyfikować):  
1. PODSTAWOWE PIKTOGRAMY  
Osoby  Operacje  Tryby pracy
  
firma  tryb firmowy
  
kontroler  kontrola  tryb kontrolny
  
kierowca  prowadzenie pojazdu  tryb eksploatacyjny
  
warsztat/stanowisko badań  przegląd/kalibracja  tryb kalibracyjny
  
producent  
Czynności Czas trwania
  
gotowość  bieżący okres gotowości
  
prowadzenie pojazdu  nieprzerwany czas prowadzenia pojazdu
  
odpoczynek  bieżący okres odpoczynku
  
inna praca  bieżący okres pracy
  
przerwa  skumulowany czas przerwy
  
nieznane  
Urządzenie  Funkcje
  
szczelina karty kierowcy
  
szczelina karty współkierowcy
  
karta
  
zegar
  
wyświetlacz  wyświetlanie
  
zewnętrzne gromadzenie danych  pobieranie danych
  
zasilanie
  
drukarka/wydruk  drukowanie
  
czujnik
  
rozmiar opon
  
pojazd/przyrząd rejestrujący
  
urządzenie GNSS
  
urządzenie wykrywania na odle­
głość
  
interfejs ITS  ▼B
02016R0799 — PL — 21.08.2023 — 003.001 — 304  
Stany szczególne, wpisy wprowadzane r ęcznie
  
poza zakresem
  
przeprawa promowa/pociągowa
  
operacja załadunku
  
operacja rozładunku
  
operacja równoczesnego załadunku/rozładunku
  
typ załadunku: pasażerowie
  
typ załadunku: towary
  
typ załadunku: nieokreślony typ załadunku  
▼B 
Różne
 
zdarzenia
  usterki
  
początek dziennego okresu pracy
  koniec dziennego okresu pracy
  
umiejscowienie
  
ręczne wprowadzenie czynności 
kierowcy  
▼M3
 
zabezpieczenie/uwierzytelnione dane/ 
plomby  
▼B
 
prędkość
  
godzina
  
razem/podsumowanie  
▼M3
 
mapa cyfrowa/przekroczenie granicy  
▼B 
Kwalifikatory  
24h dobowo
  
tygodniowo
  
dwa tygodnie
  
od lub do  
2. KOMBINACJE PIKTOGRAMÓW  
Różne
 
miejsce kontroli
  
miejsce rozpoczęcia dzien­
nego okresu pracy
  miejsce zakończenia dziennego 
okresu pracy  
▼M1
 
położenie po 3 godzinach skumulowa­
nego czasu prowadzenia pojazdu  
▼B
 
od godziny
  do godziny
  
z pojazdu
  
początek poza zakresem
  koniec poza zakresem  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 305
  
pozycja, gdzie pojazd przekroczył 
granicę między dwoma krajami
  
pozycja, gdzie miała miejsce operacja 
załadunku
  
pozycja, gdzie miała miejsce operacja 
rozładunku
  
pozycja, gdzie miała miejsce operacja 
równoczesnego załadunku/rozładunku  
▼B 
Karty
  
karta kierowcy
  
karta firmowa
  
karta kontrolna
  
karta warsztatowa
  
brak karty  
Prowadzenie pojazdu
  
załoga
  
czas prowadzenia w ciągu jednego tygodnia
  
czas prowadzenia w ciągu dwóch tygodni  
Wydruki
  
wydruk dzienny czynności kierowcy z karty
  
wydruk dzienny czynności kierowcy z VU
  
wydruk zdarzeń i usterek z karty
  
wydruk zdarzeń i usterek z VU
  
wydruk danych technicznych
  
wydruk przekroczenia prędkości  
▼M3
 
wydruk historii włożonych kart  
▼B 
Zdarzenia
  
włożenie nieważnej karty
  
konflikt kart
  
nakładające się czasy
  
prowadzenie pojazdu bez prawidłowej karty
  
włożenie karty podczas prowadzenia pojazdu
  
sesja ostatniej karty niezamknięta prawidłowo
  
przekroczenie prędkości
  
przerwa w zasilaniu
  
błąd danych dotyczących ruchu
  
konflikt ruchu pojazdu
  
naruszenie zabezpieczenia  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 306
  
konflikt czasu lub korekta czasu (w warsztacie)  
▼B
 
kontrola przekroczenia prędkości  
▼M1
 
brak informacji o pozycji z odbiornika GNSS lub błąd połączenia  z urzą­
dzeniem zewnętrznym GNSS
  
błąd połączenia z urządzeniem do łączności na odległość  
▼M3
 
anomalia GNSS  
▼B 
Usterki
  
usterka karty (szczelina karty kierowcy)
  
usterka karty (szczelina karty współkierowcy)
  
usterka wyświetlacza
  
usterka pobierania danych
  
usterka drukarki
  
usterka czujnika
  
usterka wewnętrzna VU
  
usterka GNSS
  
usterka urządzenia wykrywania na odległość  
Procedura r ęcznego wprowadzania danych
  
Czy nadal ten sam dzienny okres pracy?
  
Czy koniec poprzedniego okresu pracy?
  
potwierdź lub wprowadź miejsce zakończenia okresu pracy
  
wprowadź godzinę rozpoczęcia
  
wprowadź miejsce rozpoczęcia okresu pracy  
Uwaga:  dodatkowe kombinacje piktogramów używane do tworzenia 
bloków wydruków lub identyfikatorów zapisów określono w dodatku  4 . ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 307  
Dodatek 4  
WYDRUKI  
SPIS TREŚCI  
1. ZASADY OGÓLNE  
2. SPECYFIKACJA BLOKÓW DANYCH  
3. SPECYFIKACJE WYDRUKU  
3.1. Wydruk dzienny czynności kierowcy z karty  
3.2. Wydruk dzienny czynności kierowcy z VU  
3.3. Wydruk zdarzeń i usterek z karty  
3.4. Wydruk zdarzeń i usterek z VU  
3.5. Wydruk danych technicznych  
3.6. Wydruk przekroczenia prędkości  
3.7 Historia włożonych kart  
1. ZASADY OGÓLNE  
Wszystkie wydruki tworzy się poprzez zbudowanie łańcucha różnyc h 
bloków danych, w miarę możliwości identyfikowanych identyfikato rem 
bloku.  
Blok danych składa się z jednego lub więcej rekordów, o ile moż liwe 
identyfikowanych identyfikatorem rekordu.  
PRT_001 Jeżeli identyfikator bloku bezpośrednio poprzedza ident yfi­
kator rekordu, identyfikator rekordu nie jest drukowany.  
PRT_002 W przypadku gdy pozycja danych nie jest znana lub nie 
może być drukowana z uwagi na prawa dostępu do danych, 
zamiast tej pozycji drukowane są spacje.  
PRT_003 Jeżeli zawartość pełnego wiersza nie jest znana lub nie  
wymaga drukowania, cały wiersz jest pomijany.  
PRT_004 Numeryczne pola danych są drukowane z wyrównaniem do 
prawej strony, ze spacją oddzielającą tysiące i miliony i bez 
zer z lewej strony.  
▼M3 
PRT_005 Pola danych tekstowych są drukowane z wyrównaniem do 
lewej strony i wypełniane spacjami do długości danej pozycji 
danych lub w razie potrzeby obcinane do długości danej 
pozycji. Nazwy i adresy mogą być wydrukowane w dwóch 
wierszach.  
▼B 
PRT_006 W przypadku łamania wiersza w związku z długością tekst u 
pierwszym znakiem w nowym wierszu powinien być znak 
specjalny (kropka w połowie wysokości wiersza: „•”).  
2. SPECYFIKACJA BLOKÓW DANYCH  
W tym rozdziale przyjęto następujące konwencje zapisu formatu:  
— Znaki drukowane  wytłuszczonym  drukiem oznaczają zwykły tekst, 
który ma być drukowany (wydruk normalną czcionką),  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 308  
— Znaki normalną czcionką oznaczają zmienne (piktogramy lub dan e), 
które na wydruku są zastępowane odpowiednimi wartościami,  
— Nazwy zmiennych wypełniono znakami podkreślenia w celu poka­
zania długości pozycji danych dostępnej dla zmiennej,  
— Daty podawane są w układzie „dd/mm/rrrr” (dzień, miesiąc, rok ). 
Dopuszczalny jest także układ „dd.mm.rrrr”.  
— Wyrażenie „identyfikacja karty” oznacza następujący zestaw da nych: 
typ karty w postaci kombinacji piktogramów, kod państwa człon­
kowskiego, które wydało kartę, ukośnik prawy i numer karty wraz  
z numerem wymiany i numerem odnowienia rozdzielonymi 
spacjami: 
P
 x  x  x  / x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x
 Kombinacja 
piktogramów  
Kod państwa wyda- 
jącego Pierwsze 14 znaków numeru karty 
(ewentualnie z numerem kolejnym)
 
Numer wymiany  
Numer odnowienia 
▼M3 
— w bloku danych tekst po „pi=” odnosi się do odpowiedniego pik to­
gramu lub kombinacji piktogramów określonych w dodatku 3,  
— w przypadku wydruku po długości i szerokości geograficznej za reje­
strowanej pozycji lub po znaczniku czasu, gdy pozycja została o kre­ 
ślona,
  piktogram wskazuje, że pozycję tę obliczono na podstawie 
uwierzytelnionych komunikatów nawigacyjnych,  
— * dane dostępne tylko w tachografach GEN2 (wszystkie wersje),  
— ** dane dostępne tylko w GEN2 wersja 2.  ▼B
02016R0799 — PL — 21.08.2023 — 003.001 — 309  
PRT_007 W wydrukach korzysta się z następujących bloków danych lub 
rekordów danych w opisanym poniżej znaczeniu i formacie:
  
► (1) (2) (3) (4) (5)  M3 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 310
  
► (1) (2) (3)  M3 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 311
  
► (1) (2) M3 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 312
  
▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 313
  
► (1) (2) (3) (4)  M3 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 314
  
▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 315
  
► (1) M3 
3. SPECYFIKACJE WYDRUKU  
W tym rozdziale przyjęto następujące konwencje zapisu: 
N Wydruk bloku lub rekordu o numerze N  
N Wydruk bloku lub rekordu o numerze N powtarzany tyle razy, ile jest 
to niezbędne  
X/Y Wydruk bloków lub rekordów X lub Y w zależności od potrzeby 
i powtórzenie tyle razy, ile jest to niezbędne  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 316  
3.1. Wydruk dzienny czynno ści kierowcy z karty  
▼M3 
PRT_008 Wydruk dzienny czynności kierowcy z karty jest zgodny 
z poniższym formatem:
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 317  
3.2. Wydruk dzienny czynno ści kierowcy z VU  
▼M3 
PRT_009 Wydruk dzienny czynności kierowcy z VU jest zgodny 
z poniższym formatem:
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 318  
3.3. Wydruk zdarze ń i usterek z karty  
PRT_010 Wydruk zdarzeń i usterek z karty jest zgodny z poniższy m 
formatem: 
1 Data i godzina drukowania dokumentu  
2 Typ wydruku  
3 Identyfikacja kontrolera (jeżeli w czytniku VU znajduje się kar ta 
kontrolna + GEN)  
3 Identyfikacja kierowcy (z karty, dla której sporządzany jest wy druk)  
4 Identyfikacja pojazdu (tego, dla którego sporządzany jest wydru k) 
12.2 Ogranicznik zdarzeń  
12.4 Rekordy zdarzeń (wszystkie zdarzenia zarejestrowane na karcie)  
12.3 Ogranicznik usterek  
12.4 Rekordy usterek (wszystkie usterki zarejestrowane na karcie)  
22.1 Miejsce kontroli  
22.2 Podpis kontrolera  
22.5 Podpis kierowcy  
3.4. Wydruk zdarze ń i usterek z VU  
PRT_011 Wydruk zdarzeń i usterek z VU jest zgodny z poniższym 
formatem: 
1 Data i godzina drukowania dokumentu  
2 Typ wydruku  
3 Identyfikacja posiadacza karty (dla wszystkich kart włożonych d o 
VU + GEN)  
4 Identyfikacja pojazdu (tego, dla którego sporządzany jest wydru k) 
13.2 Ogranicznik zdarzeń  
13.4 Rekordy zdarzeń (wszystkie zdarzenia zarejestrowane lub trwając e 
w VU)  
13.3 Ogranicznik usterek  
13.4 Rekordy usterek (wszystkie usterki zarejestrowane lub trwające 
w VU)  
22.1 Miejsce kontroli  
22.2 Podpis kontrolera  
22.5 Podpis kierowcy  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 319  
3.5. Wydruk danych technicznych  
▼M3 
PRT_012 Wydruk danych technicznych jest zgodny z poniższym 
formatem:
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 320  
3.6. Wydruk przekroczenia pr ędkości 
PRT_013 Wydruk przekroczenia prędkości jest zgodny z poniższym 
formatem: 
1 Data i godzina drukowania dokumentu  
2 Typ wydruku  
3 Identyfikacja posiadacza karty (dla wszystkich kart włożonych d o 
VU + GEN)  
4 Identyfikacja pojazdu (tego, dla którego sporządzany jest wydru k) 
20 Informacje dotyczące kontroli przekroczenia prędkości  
21.1 Identyfikator danych dotyczących przekroczenia prędkości  
21.4 / 21.5  Pierwsze przekroczenie prędkości po ostatniej kalibracji  
21.2 Identyfikator danych dotyczących przekroczenia prędkości  
21.4 / 21.5  5 najpoważniejszych przekroczeń prędkości w ciągu ostatnich 365  dni 
21.3 Identyfikator danych dotyczących przekroczenia prędkości  
21.4 / 21.5  Najpoważniejsze przekroczenie prędkości dla każdego z ostatnich  10 
dni ich występowania  
22.1 Miejsce kontroli  
22.2 Podpis kontrolera  
22.5 Podpis kierowcy  
3.7. Historia w łożonych kart  
PRT_014 Wydruk historii włożonych kart jest zgodny z poniższym 
formatem:  
▼M3
 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 321  
Dodatek 5  
WYŚWIETLACZ  
W niniejszym dodatku przyjęto następujące konwencje zapisu form atu: 
— znaki  wytłuszczonym  drukiem oznaczają odkryty tekst widoczny na 
wyświetlaczu (są wyświetlane jako normalne znaki),  
— znaki normalne oznaczają zmienne (piktogramy lub dane), które  na wyświet­
laczu zastępowane są przez odpowiadające im wartości:  
— dd mm yyyy: dzień, miesiąc, rok,  
— hh: godziny,  
— mm: minuty,  
— D: piktogram czasu trwania,  
— EF: kombinacja piktogramów zdarzeń lub usterek,  
— O: piktogram trybu pracy.  
DIS_001 Tachograf wyświetla dane zgodnie z poniższymi formatami : 
Dane  Format  
Domyślne informacje na wy świetlaczu  
Czas miejscowy
  
Tryb pracy
  
Informacje dotyczące kierowcy
  
Informacje dotyczące współkierowcy
  
Otwarty warunek poza zakresem
  
Wyświetlanie ostrze żeń 
Nadmierny nieprzerwany czas prowadzenia pojazdu
  
Zdarzenie lub usterka
  
Inne wyświetlane informacje  
Data UTC
  
godzina  
Nieprzerwany czas prowadzenia pojazdu przez kierowcę 
i skumulowany czas przerwy
  
Nieprzerwany czas prowadzenia pojazdu przez współkie­
rowcę i skumulowany czas przerwy
  
Skumulowany czas prowadzenia pojazdu przez kierowcę za 
ubiegły i obecny tydzień
  
Skumulowany czas prowadzenia pojazdu przez współkie­
rowcę za ubiegły i obecny tydzień
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 322  
Dodatek 6  
PRZEDNIE Z ŁĄCZE KALIBRACJI I POBIERANIA DANYCH  
SPIS TREŚCI  
1. SPRZĘT  
1.1. Złącze  
1.2. Rozmieszczenie styków  
1.3. Schemat blokowy  
2. INTERFEJS POBIERANIA DANYCH  
3. INTERFEJS KALIBRACYJNY  
1. SPRZĘT  
1.1. Złącze 
INT_001 Złącze pobierania danych/kalibracji jest złączem sześci opi­
nowym, dostępnym od strony panelu czołowego bez potrzeby 
odłączania jakiejkolwiek części tachografu. Złącze musi mieć 
wymiary zgodne z pokazanymi na rysunku poniżej (wszystkie 
wymiary w milimetrach):
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 323  
Na rysunku poniżej pokazano typową sześciopinową wtyczkę 
złączną:
  
1.2. Rozmieszczenie styków  
INT_002 Rozmieszczenie styków opisuje poniższa tabela:  
Pin Wyszczególnienie  Uwagi  
1 minus akumulatora  przyłączony do minusa akumulatora pojazdu  
2 przesyłanie danych  K-line (ISO 14230-1)  
3 RxD – pobieranie danych  dane wprowadzane do tachografu  
4 sygnał we/wy  kalibracja  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 324  
Pin Wyszczególnienie  Uwagi  
5 stałe wyjście zasilania  Zakres napięcia musi być taki jak dla zasilania pojazdu 
minus 3V w celu umożliwienia spadku napięcia na obwo­
dzie ochronnym. 
Wyjście 40 mA  
6 TxD – pobieranie danych  dane pobierane z tachografu  
1.3. Schemat blokowy  
INT_003 Schemat blokowy jest następujący:
  
2. INTERFEJS POBIERANIA DANYCH  
INT_004 Interfejs pobierania danych musi być zgodny z wymagania mi 
RS232.  
INT_005 Interfejs pobierania danych jest skonfigurowany w nastę pujący 
sposób: jeden bit startowy, 8 bitów danych najmniej znaczących 
na początku, jeden bit parzystości i jeden bit stopu.
  
Organizacja bajtu danych  
bit startowy: jeden bit na poziomie logicznym 0  
bity danych: przesyłane z najmniej znaczącym na początku  
bit parzystości: kontrola parzystości;  
bit stopu: jeden bit na poziomie logicznym 1  
W przypadku przesyłania danych liczbowych złożonych z więcej ni ż 
jednego bajtu bajt najbardziej znaczący jest przesyłany pierwsz y, a bajt 
najmniej znaczący – ostatni.  
INT_006 Szybkość transmisji danych w bodach regulowana jest w z akresie 
od 9 600 b/s do 115 200 b/s. Transmisja odbywa się z najwyższą 
możliwą szybkością, przy czym szybkość początkowa przy 
inicjowaniu sesji ustawiona jest na 9 600 b/s.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 325  
3. Interfejs kalibracyjny  
INT_007 Przesyłanie danych musi być zgodne z normą ISO 14230-1 
Pojazdy drogowe – Systemy diagnostyczne – Protokół słów 
kluczowych 2000 – część 1: Warstwa fizyczna (wydanie 
pierwsze: 1999 r.).  
INT_008 Sygnał we/wy musi być zgodny z następującymi wymaganiam i 
elektrycznymi:  
Parametr  Min.  Typowy  Maks.  Uwagi  
U low (we) 1,0 V  I = 750 μA  
U high (we) 4  V  I = 200 μA  
Częstotliwość  4 kHz  
U low (wy)  1,0 V  I  =  1  m A  
U high (wy)  4  V  I  =  1  m A  
INT_009 Sygnał we/wy musi być zgodny z następującymi przebiegam i 
czasowymi:
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 326  
Dodatek 7  
PROTOKO ŁY POBIERANIA DANYCH  
SPIS TREŚCI  
1. WPROWADZENIE  
1.1. Zakres  
1.2. Akronimy i skróty  
2. POBIERANIE DANYCH Z VU  
2.1. Procedura pobierania danych  
2.2. Protokół pobierania danych  
2.2.1 Struktura komunikatu  
2.2.2 Typy komunikatów  
2.2.2.1 Start Communication Request (SID 81)  
2.2.2.2 Positive Response Start Communication (SID C1)  
2.2.2.3 Start Diagnostic Session Request (SID 10)  
2.2.2.4 Positive Response Start Diagnostic (SID 50)  
2.2.2.5 Link Control Service (SID 87)  
2.2.2.6 Link Control Positive Response (SID C7)  
2.2.2.7 Request Upload (SID 35)  
2.2.2.8 Positive Response Request Upload (SID 75)  
2.2.2.9 Transfer Data Request (SID 36)  
2.2.2.10 Positive Response Transfer Data (SID 76)  
2.2.2.11 Request Transfer Exit (SID 37)  
2.2.2.12 Positive Response Request Transfer Exit (SID 77)  
2.2.2.13 Stop Communication Request (SID 82)  
2.2.2.14 Positive Response Stop Communication (SID C2)  
2.2.2.15 Acknowledge Sub Message (SID 83)  
2.2.2.16 Negative Response (SID 7F)  
2.2.3 Przepływ komunikatów  
2.2.4 Przebiegi czasowe  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 327  
2.2.5 Obsługa błędów  
2.2.5.1 Faza rozpoczęcia komunikacji  
2.2.5.2 Faza komunikacji  
2.2.6 Treść komunikatu odpowiedzi  
▼M3 
2.2.6.1 Positive Response Transfer Data Download Interface Vers ion (Pozy­ 
tywna odpowiedź na żądanie przesłania danych dotyczących wersji  
interfejsu pobierania danych)  
2.2.6.2 Positive Response Transfer Data Overview (Pozytywna odp owiedź na 
żądanie przesłania danych przeglądowych)  
2.2.6.3 Positive Response Transfer Data Activities (Pozytywna o dpowiedź na 
żądanie przesłania danych dotyczących czynności)  
2.2.6.4 Positive Response Transfer Data Events and Faults (Pozy tywna odpo­ 
wiedź na żądanie przesłania danych dotyczących zdarzeń i ustere k) 
2.2.6.5 Positive Response Transfer Data Detailed Speed (Pozytyw na odpowiedź 
na żądanie przesłania danych szczegółowych dotyczących prędkośc i) 
2.2.6.6 Positive Response Transfer Data Technical Data (Pozytyw na odpowiedź 
na żądanie przesłania danych technicznych)  
▼B 
2.3. Gromadzenie plików na ESM  
3. PROTOKÓŁ POBIERANIA DANYCH Z KART DO TACHO­ 
GRAFÓW  
3.1. Zakres  
3.2. Definicje  
3.3. Pobieranie danych z karty  
3.3.1 Sekwencja inicjalizująca  
3.3.2 Sekwencja dla niepodpisanych plików danych  
3.3.3 Sekwencja dla podpisanych plików danych  
3.3.4 Sekwencja zerowania licznika kalibracji  
3.4. Format gromadzenia danych  
3.4.1 Wprowadzenie  
3.4.2 Format pliku  
4. POBIERANIE DANYCH Z KARTY DO TACHOGRAFU ZA 
POŚREDNICTWEM PRZYRZĄDU REJESTRUJĄCEGO  
1. WPROWADZENIE  
Niniejszy dodatek zawiera procedury stosowane przy pobieraniu 
danych różnych typów na zewnętrzny nośnik danych (ESM), wraz 
z protokołami, które muszą być wdrożone w celu zagwarantowania 
prawidłowego przesyłania danych i pełnej zgodności formatu pobr a­
nych danych, tak by umożliwić każdemu kontrolerowi sprawdzenie 
tych danych oraz sprawdzenie autentyczności i integralności prz ed 
przystąpieniem do analizy danych.  
▼M1 
1.1. Zakres  
Dane mogą być pobierane na ESM:  
— z przyrządu rejestrującego za pośrednictwem inteligentnego ur zą­
dzenia dedykowanego (IDE) przyłączonego do VU,  
— z karty do tachografu za pośrednictwem IDE spasowanego z czyt ­
nikiem karty (IFD),  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 328  
— z karty do tachografu za pośrednictwem przyrządu rejestrujące go 
poprzez IDE przyłączone do VU.  
Aby umożliwić weryfikację autentyczności i integralności pobran ych 
danych przechowywanych na ESM, dane są pobierane razem z dołą­
czonym podpisem, zgodnie z dodatkiem 11 „Wspólne mechanizmy 
zabezpieczenia”. Razem z danymi pobierane są również identyfika cja 
urządzenia źródłowego (VU lub karta) i jego świadectwa bezpiecz eń­
stwa (państwo członkowskie i urządzenie). Niezależnie od tego w ery­
fikator danych musi mieć zaufany europejski klucz publiczny.  
Dane pobrane z przyrządu rejestrującego są podpisywane przy uży ciu 
wspólnych mechanizmów zabezpieczeń określonych w dodatku 11 
część B (System tachografu drugiej generacji), z wyjątkiem sytu acji, 
gdy kontrolę kierowców przeprowadza organ kontrolny spoza UE, 
używając karty kontrolnej pierwszej generacji, w którym to przy padku 
dane są podpisywane przy użyciu wspólnych mechanizmów zabezpie­
czeń określonych w dodatku 11 część A (System tachografu pierws zej 
generacji), zgodnie z wymogiem określonym w dodatku 15 „Migracj a”, 
wymóg MIG_015.  
Niniejszy dodatek określa zatem dwa typy pobrań danych z VU:  
— pobranie danych z VU typu 2. generacji, zapewniające struktur ę 
danych 2. generacji, podpisanych przy użyciu wspólnych mecha­
nizmów zabezpieczeń określonych w dodatku 11 część B,  
— pobranie danych z VU typu 1. generacji, zapewniające struktur ę 
danych 1. generacji, podpisanych przy użyciu wspólnych mecha­
nizmów zabezpieczeń określonych w dodatku 11 część A,  
Analogicznie występują dwa typy pobrań danych z kart kierowcy 2 . 
generacji włożonych do przyrządu rejestrującego, jak określono w pkt 
3 i 4 niniejszego dodatku.  
▼B 
1.2. Akronimy i skróty  
W niniejszym dodatku używa się następujących skrótów:  
AID [Application Identifier] identyfikator aplikacji  
ATR  [Answer To Reset] reakcja na sprowadzenie do stanu wyjścio­
wego  
CS [Checksum byte] bajt sumy kontrolnej  
DF [Dedicated File] plik dedykowany  
DS_ [Diagnostic Session] sesja diagnostyczna  
EF [Elementary File] plik elementarny  
ESM  [External Storage Medium] zewnętrzny nośnik danych  
FID [File Identifier] identyfikator pliku (ID pliku)  
FMT  [Format Byte] bajt formatu (pierwszy bajt nagłówka komuni­
katu)  
ICC [Integrated Circuit Card] karta z układem scalonym  
IDE [Intelligent Dedicated Equipment] inteligentne urządzenie 
dedykowane: urządzenie służące do pobierania danych na 
ESM (np. komputer osobisty)  
IFD [Interface Device] urządzenie interfejsu  
KWP  [Keyword Protocol 2000] protokół słowa kluczowego 2000  
LEN  [Length Byte] bajt długości (ostatni bajt nagłówka komuni­
katu)  
PPS [Protocol Parameter Selection] wybór parametru protokołu  
PSO  [Perform Security Operation] wykonanie operacji zabezpiecza­
jącej  
SID [Service Identifier] identyfikator usługi  
SRC  [Source byte] bajt źródłowy  
TGT  [Target Byte] bajt docelowy  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 329  
TLV  [Tag Length Value] wartość długości znacznika  
TREP  [Transfer Response Parameter] parametr odpowiedzi na prze­
słanie danych  
TRTP  [Transfer Request Parameter] parametr żądania przesłania 
danych  
VU [Vehicle Unit] przyrząd rejestrujący  
2. POBIERANIE DANYCH Z VU  
2.1. Procedura pobierania danych  
W celu pobrania danych z VU operator musi wykonać następujące 
czynności:  
— włożyć swoją kartę do tachografu do czytnika karty w VU (*);  
— podłączyć IDE do gniazda pobierania w VU;  
— nawiązać połączenie między IDE i VU;  
— wybrać w IDE dane do pobrania i wysłać żądanie do VU;  
— zamknąć sesję pobierania danych.  
2.2. Protokó ł pobierania danych  
Protokół skonstruowany jest zgodnie z zasadą nadrzędny-podległy , 
gdzie IDE jest urządzeniem nadrzędnym a VU podległym.  
Struktura komunikatu, typy komunikatów i przepływ są zasadniczo  
oparte na Protokole słowa kluczowego 2000 (KWP) (według normy 
ISO 14230-2 Pojazdy drogowe – Systemy diagnostyczne – Protokół 
słowa kluczowego 2000 – część 2: Warstwa łącza danych).  
Warstwa aplikacji zbudowana jest zasadniczo w oparciu o bieżący  
projekt normy ISO 14229-1 (Pojazdy drogowe – Systemy diagno­
styczne – część 1: Usługi diagnostyczne, wersja 6 z dnia 22 lut ego 
2001 r.)  
2.2.1  Struktura komunikatu  
DDP_002 Wszystkie komunikaty wymieniane między IDE i VU mają 
strukturę złożoną z następujących trzech części:  
— nagłówek zawierający bajt formatu (FMT), bajt 
docelowy (TGT), bajt źródłowy (SRC) i ewentualnie 
bajt długości (LEN);  
— pole danych zawierające bajt identyfikator usługi (SID) 
i zmienną liczbę bajtów z danymi, w których może być 
bajt opcjonalnej sesji diagnostycznej (DS_) lub bajt 
opcjonalnego parametru przesyłania (TRTP lub TREP);  
— suma kontrolna zawierająca bajt sumy kontrolnej (CS).  
Nagłówek  Pole danych  Suma kontrolna  
FMT  TGT  SRC  LEN  SID  DATA  …  …  …  C S  
4 bajty  Maks. 255 bajtów  1 bajt  
Bajty TGT i SRC reprezentują fizyczny adres adresata 
i źródła komunikatu. Przyjmują one wartości F0 Hex dla 
IDE i EE Hex dla VU.  
Bajt LEN jest długością pola danych.  ▼B 
(*) Włożenie karty spowoduje aktywację właściwych praw dostępu do funkcji pobierania 
i do danych. Możliwe jest jednak pobieranie danych z karty kier owcy włożonej do 
jednej ze szczelin VU, jeżeli w drugiej szczelinie nie ma żadne j innej karty.
 02016R0799 — PL — 21.08.2023 — 003.001 — 330  
Bajt sumy kontrolnej jest ośmiobitową sumą serii modulo 
256 wszystkich bajtów komunikatu, z wyłączeniem bajtu CS.  
Bajty FMT, SID, DS_, TRTP i TREP są zdefiniowane 
w dalszej części niniejszego dokumentu.  
DDP_003 W przypadku gdy dane przesyłane komunikatem są dłuższe 
niż dysponowane pole danych, komunikat wysyła się 
w kilku podkomunikatach. Każdy podkomunikat ma 
nagłówek, te same bajty SID i TREP oraz dwubajtowy 
licznik podkomunikatu pokazujący liczbę podkomunikatów 
w całym komunikacie. Aby umożliwić kontrolę błędów 
i przerwanie przesyłania, IDE potwierdza każdy podkomu­
nikat. IDE może przyjmować podkomunikat, żądać powtó­
rzenia transmisji, żądać od VU powtórzenia transmisji od 
początku lub przerwania transmisji.  
DDP_004 Jeżeli ostatni podkomunikat ma dokładnie 255 bajtów w p olu 
danych, musi być dołączony końcowy podkomunikat 
z pustym polem danych (z wyjątkiem SID TREP i licznika 
podkomunikatów) w celu pokazania końca komunikatu.  
Przykład: 
Nagłówek  SID  TREP  Komunikat  C S  
4 bajty  dłuższy niż 255 bajtów  
zostanie przesłany w następujący sposób:  
Nagłówek  SID  TREP  0 0  0 1  Podkomunikat 1  C S  
4 bajty  255 bajtów  
Nagłówek  SID  TREP  0 0  0 2  Podkomunikat 2  C S  
4 bajty  255 bajtów  
… 
Nagłówek  SID  TREP  x x  y y  Podkomunikat n  C S  
4 bajty  mniej niż 255 bajtów  
lub w taki sposób:  
Nagłówek  SID  TREP  0 0  0 1  Podkomunikat 1  C S  
4 bajty  255 bajtów  
Nagłówek  SID  TREP  0 0  0 2  Podkomunikat 2  C S  
4 bajty  255 bajtów  
… 
Nagłówek  SID  TREP  x x  y y  Podkomunikat n  C S  
4 bajty  255 bajtów  
Nagłówek  SID  TREP  x x  yy + 1  C S  
4 bajty  4 bajty  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 331  
2.2.2  Typy komunikatów  
Protokół komunikacyjny pobierania danych między VU i IDE wymaga  
wymiany komunikatów 8 różnych typów.  
W tabeli poniżej opisano te komunikaty.  
▼M3 
Struktura komunikatu  Maks. 4 bajty  Maks. 255 bajtów  1 bajt  
Nagłówek  Dane  Suma 
kontrolna  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  C S  
Żądanie rozpoczęcia transmisji  8 1  E E  F 0  8 1  E 0  
Pozytywna odpowiedź na żądanie 
rozpoczęcia transmisji  80 F 0  E E  0 3  C 1  EA, 8F  9 B  
Żądanie rozpoczęcia sesji diagno­
stycznej  80 E E  F 0  0 2  1 0  8 1  F 1  
Pozytywna odpowiedź na żądanie 
rozpoczęcia sesji diagnostycznej  80 F 0  E E  0 2  5 0  8 1  3 1  
Obsługa sterowania łączem  
Weryfikacja szybkości transmisji (etap 1)  
9 600 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,01  E C  
19 200 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,02  E D  
38 400 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,03  E E  
57 600 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,04  E F  
115 200 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,05  F 0  
Pozytywna odpowiedź na weryfikację 
szybkości transmisji  80 F 0  E E  0 2  C 7  0 1  2 8  
Zmiana szybkości transmisji (etap 
2) 80 E E  F 0  0 3  8 7  0 2  0 3  E D  
Żądanie wczytywania  8 0  E E  F 0  0 A  3 5  00,00,00,00, 
00,FF,FF, 
FF,FF  99 
Pozytywna odpowiedź na żądanie 
wczytywania  80 F 0  E E  0 3  7 5  00,FF  D 5  
Żądanie przesłania danych  
Wersja interfejsu pobierania 
danych  80 E E  F 0  0 2  3 6  0 0  9 6  
Przegląd  80 E E  F 0  0 2  3 6  01, 21 lub 31  C S  
Czynności  80 E E  F 0  0 6  3 6  02, 22 lub 32  Data  C S  
Zdarzenia i usterki  80 E E  F 0  0 2  3 6  03, 23 lub 33  Data  C S  
Szczegółowe dane dotyczące pręd­
kości  80 E E  F 0  0 2  3 6  04 lub 24  Data  C S  
Dane techniczne  80 E E  F 0  0 2  3 6  05, 25 lub 35  Data  C S  
Pobieranie danych z karty  80 E E  F 0  02 lub 03  3 6  0 6  Szczelina 
czytnika karty  CS ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 332  
Struktura komunikatu  Maks. 4 bajty  Maks. 255 bajtów  1 bajt  
Nagłówek  Dane  Suma 
kontrolna  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  C S  
Pozytywna odpowiedź na żądanie 
przesłania danych  80 F 0  E E  Len  7 6  TREP  Dane  C S  
Żądanie wyjścia z przesyłania danych  8 0  E E  F 0  0 1  3 7  9 6  
Pozytywna odpowiedź na żądanie 
wyjścia z przesyłania danych  80 F 0  E E  0 1  7 7  D 6  
Żądanie zatrzymania transmisji  8 0  E E  F 0  0 1  8 2  E 1  
Pozytywna odpowiedź na żądanie 
zatrzymania transmisji  80 F 0  E E  0 1  C 2  2 1  
Potwierdzenie podkomunikatu  8 0  E E  F 0  Len  8 3  Dane  C S  
Odpowiedzi negatywne  
Generalne odrzucenie  8 0  F 0  E E  0 3  7 F  Sid Req  1 0  C S  
Usługa nieobsługiwana  8 0  F 0  E E  0 3  7 F  Sid Req  1 1  C S  
Podfunkcja nieobsługiwana  8 0  F 0  E E  0 3  7 F  Sid Req  1 2  C S  
Nieprawidłowa długość komunikatu  8 0  F 0  E E  0 3  7 F  Sid Req  1 3  C S  
Nieprawidłowe warunki lub błąd 
kolejności żądań  80 F 0  E E  0 3  7 F  Sid Req  2 2  C S  
Żądanie poza zakresem  8 0  F 0  E E  0 3  7 F  Sid Req  3 1  C S  
Ładowanie nieprzyjęte  8 0  F 0  E E  0 3  7 F  Sid Req  5 0  C S  
Oczekiwanie na odpowiedź  8 0  F 0  E E  0 3  7 F  Sid Req  7 8  C S  
Brak dostępnych danych  8 0  F 0  E E  0 3  7 F  Sid Req  F A  C S  
Uwagi:  
— Sid Req = Sid odpowiadającego żądania.  
— TREP = TRTP odpowiadającego żądania.  
— Ciemne rubryki oznaczają, że nic nie jest przesyłane.  
— Pojęcia „ładowanie” (z perspektywy IDE) używa się zgodnie 
z normą ISO 14229. Oznacza to samo co pobieranie (z perspektywy  
VU).  
— W tabeli nie pokazano potencjalnych dwubajtowych liczników 
podkomunikatów.  
— „Szczelina” dotyczy numeru szczeliny: „1” (karta w szczelinie  czyt­
nika karty kierowcy) albo „2” (karta w szczelinie czytnika kart y 
współkierowcy).  
— W przypadku gdy szczelina nie jest określona, VU wybiera szcz e­
linę 1, jeżeli karta jest włożona w tę szczelinę, a szczelinę 2  
wybiera tylko wówczas, gdy użytkownik specjalnie ją wybierze.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 333  
— TRTP 24 używa się w przypadku żądań pobrania danych z przy­
rządu rejestrującego generacji 2 (wersja 1 i wersja 2).  
— TRTP 00, 31, 32, 33 i 35 używa się w przypadku żądań pobrania  
danych z przyrządu rejestrującego generacji 2 (wersja 2).  
— TRTP 21, 22, 23 i 25 używa się w przypadku żądań pobrania 
danych z przyrządu rejestrującego generacji 2 (wersja 1).  
— TRTP 01 do 05 używa się w przypadku żądań pobrania danych 
z przyrządu rejestrującego generacji 1. Opcjonalnie mogą być on e 
akceptowane przez przyrząd rejestrujący generacji 2, ale tylko 
w ramach kontroli kierowców przeprowadzanej przez organ 
kontrolny spoza UE, przy użyciu karty kontrolnej pierwszej 
generacji.  
— TRTP 11 do 1F są zarezerwowane dla żądań pobrania swoistych 
dla producenta.  
▼B 
2.2.2.1 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 Komunikat ten wysyła IDE w celu zestawienia łącza komu­
nikacyjnego z VU. Początkowe komunikaty są zawsze 
wysyłane z szybkością 9 600 bodów (aż do ewentualnej 
zmiany szybkości transmisji przy wykorzystaniu odpowied­
niej obsługi sterowania łączem).  
2.2.2.2 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 Komunikat ten wysyła VU w celu przesłania pozytywnej 
odpowiedzi na żądanie rozpoczęcia transmisji. Komunikat 
zawiera 2 kluczowe bajty („EA” „8F”) wskazujące, że urzą­
dzenie obsługuje protokół z nagłówkiem zawierającym 
informacje o adresie, źródle i długości.  
2.2.2.3 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 wysyła komunikat „Start Diagnostic Session Request”  
w celu zażądania nowej sesji diagnostycznej z VU. Podfun­
kcja „default session” (81 Hex) wskazuje, że IDE żąda 
otwarcia standardowej sesji diagnostycznej.  
2.2.2.4 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 VU wysyła komunikat „Positive Response Start Diagnostic ” 
w celu przesłania pozytywnej odpowiedzi na żądanie „Diag­
nostic Session Request”.  
2.2.2.5 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 IDE używa obsługi sterowania łączem do zainicjowania 
zmiany szybkości transmisji w bodach. Odbywa się to 
dwustopniowo. Najpierw IDE proponuje zmianę szybkości 
transmisji podając nową szybkość (pierwszy krok). Po 
otrzymaniu pozytywnej odpowiedzi od VU IDE wysyła do 
VU potwierdzenie zmiany szybkości (drugi krok). Następnie 
IDE przechodzi na nową szybkość transmisji. Po otrzymaniu 
potwierdzenia VU przechodzi na nową szybkość transmisji.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 334  
2.2.2.6 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 VU wysyła odpowiedź „Link Control Positive Response” 
w celu przesłania pozytywnej odpowiedzi na żądanie 
„Link Control Service” (pierwszy krok). Należy zwrócić 
uwagę, że na żądanie potwierdzenia (drugi krok) nie ma 
odpowiedzi.  
2.2.2.7 R e q u e s t U p l o a d ( S I D 3 5 )  
DDP_009 IDE wysyła komunikat „Request Upload” w celu przeka­
zania VU, że żądana jest operacja pobierania. Aby spełnić 
wymagania normy ISO14229 przesyłane są szczegółowe 
informacje dotyczące adresu, wielkości i szczegółów żąda­
nych danych. Ponieważ informacje te nie są znane IDE 
przed pobieraniem, adres pamięci ustawiony jest na 0, 
format jest nieszyfrowany i bez kompresji, a wielkość 
pamięci ustawiona na maksimum.  
2.2.2.8 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 VU wysyła komunikat „Positive Response Request 
Upload”, aby wskazać IDE, że VU jest gotowe do pobie­
rania danych. Aby spełnić wymagania normy ISO 14229 ten 
komunikat pozytywnej odpowiedzi zawiera dane wskazujące 
IDE, że dalsze komunikaty „Positive Response Transfer 
Data” będą zawierały maksymalnie 00FF hex bajtów.  
2.2.2.9 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 IDE wysyła żądanie „Transfer Data Request” w celu wska­
zania VU typu danych, które mają być pobierane. Jednobaj­
towy parametr „Transfer Request Parameter” (TRTP) wska­
zuje typ przesyłania.  
▼M3 
Rozróżnia się siedem typów przesyłania danych: Na 
potrzeby pobierania danych z przyrządu rejestrującego dla 
każdego typu transferu można użyć dwóch różnych wartości 
TRTP:  
Typ transferu danych  Wartość TRTP w przypadku 
żądań pobrania danych z przy­
rządu rejestrującego typu 1. 
generacji  Wartość TRTP w przypadku 
żądań pobrania danych z przy­
rządu rejestrującego typu 2. 
generacji (wersja 1)  Wartość TRTP w przypadku 
żądań pobrania danych z przy­
rządu rejestrującego typu 2. 
generacji (wersja 2)  
Wersja interfejsu pobierania 
danych  Nieużywany  Nieużywany  0 0  
Przegląd  0 1  2 1  3 1  
Czynności o określonej dacie  0 2  2 2  3 2  
Zdarzenia i usterki  0 3  2 3  3 3  
Szczegółowe dane dotyczące 
prędkości  04 2 4  2 4  
Dane techniczne  0 5  2 5  3 5  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 335  
Typ transferu 
danych  Wartość TRTP  
Pobieranie 
danych z karty  06 
▼M3 
DDP_054 IDE musi obowiązkowo zażądać przesłania danych przeglą­
dowych (TRTP 01, 21 lub 31) w czasie sesji pobierania, 
ponieważ tylko to zagwarantuje, że certyfikaty VU są 
zarejestrowane w pobieranym pliku (i umożliwi weryfikację 
podpisu cyfrowego).  
W trzecim przypadku (TRTP 02, 22 lub 32) w komunikacie żądania 
przesłania danych znajduje się informacja o dniu kalendarzowym 
(format TimeReal), dla którego dane mają być pobrane.  
▼B 
2.2.2.10 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 VU wysyła pozytywną odpowiedź „Positive Response 
Transfer Data” w odpowiedzi na żądanie „Transfer Data 
Request”. Komunikat zawiera żądane dane z parametrem 
„Transfer Response Parameter” (TREP) odpowiadającym 
TRTP żądania.  
▼M3 
DDP_055 W pierwszym przypadku (TREP 01, 21 lub 31) VU wyśle 
dane pomagające operatorowi IDE w wyborze danych, które 
chce dalej pobrać. Komunikat ten zawiera następujące 
informacje:  
▼M1 
— świadectwa bezpieczeństwa,  
— identyfikacja pojazdu,  
— bieżąca data i godzina VU,  
— minimalna i maksymalna data, dla której można 
dokonać pobrania (dane z VU),  
— sygnalizacja obecności kart w VU,  
— poprzednie pobranie dla firmy,  
— blokady firmowe,  
— poprzednie kontrole.  
▼B 
2.2.2.11 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 IDE wysyła komunikat „Request Transfer Exit” w celu 
zawiadomienia VU, że sesja pobierania jest zakończona.  
2.2.2.12 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 ( S I D 7 7 )  
DDP_014 VU wysyła komunikat „Positive Response Request Transfer  
Exit” w celu potwierdzenia otrzymania żądania wyjścia 
z przesyłania danych „Request Transfer Exit”.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 336  
2.2.2.13 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 IDE wysyła komunikat „Stop Communication Request” 
w celu rozłączenia łącza komunikacyjnego z VU.  
2.2.2.14 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 VU wysyła komunikat „Positive Response Stop Communi­
cation” w celu potwierdzenia otrzymania żądania „Stop 
Communication Request”.  
2.2.2.15 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 IDE wysyła potwierdzenie podkomunikatu w celu potwier­
dzenia otrzymania każdej części komunikatu przesyłanego 
w kilku podkomunikatach. W polu danych znajduje się 
SID otrzymany z VU i dwubajtowy kod opisany poniżej:  
— MsgC +1 potwierdza prawidłowy odbiór podkomunikatu 
o numerze MsgC.  
Żądanie od IDE dla VU wysłania następnego 
podkomunikatu.  
— MsgC wskazuje na problem z odbiorem podkomunikatu 
o numerze MsgC.  
Żądanie od IDE dla VU wysłania powtórnie następnego 
podkomunikatu.  
— FFFF żąda zakończenia komunikatu.  
IDE może użyć tego do zakończenia transmisji komuni­
katu z VU z dowolnej przyczyny.  
Ostatni podkomunikat komunikatu (bajt LEN < 255) może 
być potwierdzony przy pomocy dowolnego z tych kodów 
lub być niepotwierdzony.  
Odpowiedziami VU, które składają się z kilku podkomuni­
katów są:  
— Positive Response Transfer Data (SID 76)  
2.2.2.16 N e g a t i v e R e s p o n s e ( S I D 7 F )  
DDP_018 VU wysyła komunikat „Negative Response” w odpowiedzi 
na powyższe komunikaty żądań, gdy VU nie może obsłużyć 
żądania. Pole danych komunikatu zawiera SID odpowiedzi 
(7F), SID żądania i kod podający przyczynę negatywnej 
odpowiedzi. Dozwolone są następujące kody:  
— 10 generalne odrzucenie  
Czynności nie można wykonać z przyczyny innej niż 
określone poniżej.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 337  
— 11 usługa nieobsługiwana  
SID żądania nie jest zrozumiany.  
— 12 podfunkcja nieobsługiwana  
DS_ lub TRTP żądania nie jest zrozumiany lub nie ma 
dalszych komunikatów do wysłania.  
— 13 nieprawidłowa długość komunikatu  
Długość odebranego komunikatu jest nieprawidłowa.  
— 22 nieprawidłowe warunki lub błąd kolejności żądań  
Żądana usługa nie jest aktywna lub sekwencja komuni­
katów żądań nie jest prawidłowa.  
— 31 żądanie poza zakresem  
Żądany rekord dotyczący parametru (pole danych) nie 
jest ważny.  
— 50 ładowanie nieprzyjęte  
Żądania nie można obsłużyć (VU w nieodpowiednim 
trybie pracy lub usterka wewnętrzna VU).  
— 78 odpowiedź zawieszona  
Czynności nie można zakończyć na czas i VU nie jest 
gotowe do przyjęcia innego żądania.  
▼M1 
— FA brak dostępnych danych  
Obiekt danych żądania transferu danych nie jest 
dostępny w przyrządzie rejestrującym (np. karta nie 
jest włożona, zażądano pobrania danych z przyrządu 
rejestrującego typu generacji 1 poza ramami kontroli 
kierowców przez organ kontrolny spoza UE ...).  
▼B 
2.2.3  Przep ływ komunikatów  
Typowy przepływ komunikatów podczas normalnej procedury pobie­
rania danych wygląda następująco:  
IDE V U  
Start Communication Request  ⇨ 
⇦  Positive Response  
Start Diagnostic Service Request  ⇨ 
⇦  Positive Response  
Request Upload  ⇨ 
⇦  Positive Response  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 338  
IDE V U  
Transfer Data Request Overview  ⇨ 
⇦  Positive Response  
Transfer Data Request #2  ⇨ 
⇦  Positive Response #1  
Acknowledge Sub Message #1  ⇨ 
⇦  Positive Response #2  
Acknowledge Sub Message #2  ⇨ 
⇦  Positive Response #m  
Acknowledge Sub Message #m  ⇨ 
⇦  Positive Response (Data Field<255 Bytes)  
Acknowledge Sub Message (optional)  ⇨  
… 
Transfer Data Request #n  ⇨ 
⇦  Positive Response  
Request Transfer Exit  ⇨ 
⇦  Positive Response  
Stop Communication Request  ⇨ 
⇦  Positive Response  
2.2.4  Przebiegi czasowe  
DDP_019 Podczas normalnej pracy przebiegi czasowe wyglądają tak  
jak na poniższym rysunku:  
Rysunek 1  
Przepływ komunikatów, przebiegi czasowe
  
Gdzie:  
P1 = czas między bajtami dla odpowiedzi VU.  
P2 = czas między końcem żądania IDE a początkiem odpo­
wiedzi VU, lub między końcem potwierdzenia IDE 
a początkiem następnej odpowiedzi VU.  
P3 = czas między końcem odpowiedzi VU a początkiem 
nowego żądania IDE, bądź między końcem odpo­
wiedzi VU a początkiem potwierdzenia IDE, bądź 
między końcem żądania IDE a początkiem nowego 
żądania IDE, jeżeli VU nie odpowiada.  
P4 = czas między bajtami dla żądania IDE.  
P5 = przedłużona wartość P3 dla pobierania danych z karty.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 339  
Dozwolone wartości przebiegów czasowych pokazano 
w tabeli poniżej (KWP rozszerzony zestaw parametrów 
przebiegów czasowych używany w przypadku adresowania 
fizycznego w celu uzyskania szybszej komunikacji).  
Parametr czasowy  Dolna wartość graniczna 
(ms) Górna wartość graniczna 
(ms) 
P1 0  2 0  
P2 2 0  1 000 (*)  
P3 1 0  5 000  
P4 5  2 0  
P5 1 0  20 minut  
(*) Jeżeli VU daje negatywną odpowiedź „Negative Response” zawi erającą kod o znaczeniu „żądanie odebrane 
prawidłowo, odpowiedź zawieszona”, wartość ta zostaje przedłużo na do górnej wartości granicznej P3.  
2.2.5  Obsługa błędów 
W przypadku wystąpienia błędu w czasie wymiany komunikatów, 
schemat przepływu komunikatów zostaje zmodyfikowany zależnie od  
tego, które urządzenia wykryło błąd, i od komunikatu generujące go 
błąd.  
Na rysunkach 2 i 3 pokazano odpowiednio procedury obsługi błędó w 
dla VU i IDE.  
2.2.5.1 F a z a r o z p o c z ę c i a k o m u n i k a c j i  
DDP_020 Jeżeli w czasie fazy rozpoczęcia komunikacji IDE wykryj e 
błąd synchronizacji lub strumienia bitowego, to odczekuje 
okres P3min przed powtórnym wysłaniem żądania.  
DDP_021 Jeżeli VU wykryje błąd w sekwencji przychodzącej z IDE,  
to nie wysyła żadnej odpowiedzi i czeka na następny komu­
nikat „Start Communication Request” przez okres P3 max.  
2.2.5.2 F a z a k o m u n i k a c j i  
W tym przypadku można zdefiniować dwa różne obszary obsługi 
błędów:  
1. VU wykrywa b łąd transmisji IDE.  
DDP_022 Dla każdego odebranego komunikatu VU wykrywa błędy 
synchronizacji, błędy formatu bajtowego (np. błędy bitów 
startu i stopu) i błędy ramki (zła liczba odebranych 
bajtów, zły bajt sumy kontrolnej).  
DDP_023 Jeżeli VU wykryje jeden z powyższych błędów, to nie 
wysyła odpowiedzi i ignoruje odebrany komunikat.  
DDP_024 VU może wykrywać inne błędy formatu lub treści otrzy­
manego komunikatu (np. komunikat nieobsługiwany), 
nawet jeżeli długości i sumy kontrolne są prawidłowe; 
w takim przypadku VU wysyła do IDE komunikat nega­
tywnej odpowiedzi „Negative Response” określający 
charakter błędu.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 340  
Rysunek 2  
Obsługa błędów w VU
  
▼B 
2. IDE WYKRYWA B ŁĄD TRANSMISJI VU  
DDP_025 Dla każdego odebranego komunikatu IDE wykrywa 
błędy synchronizacji, błędy formatu bajtowego (np. 
błędy bitów startu i stopu) i błędy ramki (zła liczba 
odebranych bajtów, zły bajt sumy kontrolnej).  
DDP_026 IDE wykrywa błędy kolejności, np. nieprawidłowe 
zwiększenie stanu licznika podkomunikatów w kolejnych 
komunikatach.  
DDP_027 Jeżeli IDE wykrywa błąd lub nie ma odpowiedzi z VU 
w okresie P2max, wysyła ponownie komunikat żądania, 
z tym że mogą być maksymalnie trzy transmisje. Na 
potrzeby tego wykrywania błędów VU traktuje potwier­
dzenie podkomunikatu jako żądanie.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 341  
DDP_028 Przed rozpoczęciem każdej transmisji IDE oczekuje przez  
okres P3min; okres oczekiwania odmierza się od ostat­
niego bitu stopu po wykryciu błędu.  
Rysunek 3  
Obsługa błędów w IDE
  
2.2.6  Treść komunikatu odpowiedzi  
W tym punkcie określono treść pól danych w różnych komunikatach  
pozytywnej odpowiedzi.  
Elementy danych zdefiniowano w dodatku 1 „Słownik danych”.  
Uwaga: W przypadku pobrań 2. generacji każdy element danych 
najwyższego poziomu jest reprezentowany przez tablicę rekordów,  
nawet jeśli zawiera tylko jeden rekord. Tablica rekordów zaczyn a się 
od nagłówka; nagłówek ten zawiera typ rekordu, wielkość rekordu  
i liczbę rekordów. Tablice rekordów oznaczone są za pomocą 
„…RecordArray” (z nagłówkiem) w poniższych tabelach.  
▼M3 
2.2.6.1 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  D o w n l o a d I n t e r ­
f a c e V e r s i o n ( P o z y t y w n a o d p o w i e d ź n a  ż ą d a n i e 
p r z e s ł a n i a d a n y c h d o t y c z ą c y c h w e r s j  i i n t e r f e j s u 
p o b i e r a n i a d a n y c h )  
DDP_028a Pole danych w komunikacie „Positive Response Transfer 
Data Download Interface Version” zawiera następujące 
dane w określonej tu kolejności pod SID 76 Hex, TREP 
00 Hex:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 342  
Struktura danych generacji 2, wersja 2 (TREP 00 Hex)  
Element danych  Uwagi  
DownloadInterfaceVersion  Generacja i wersja VU: 02,02 Hex dla wersji 2 
generacji 2. 
Nieobsługiwany przez VU generacji 1 oraz wersji 
1 generacji 2, które muszą reagować negatywnie 
(podfunkcja nieobsługiwana, zob. DDP_018)  
2.2.6.2 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  O v e r v i e w ( P o z y ­
t y w n a o d p o w i e d ź n a ż ą d a n i e p r z e s ł a n i  a d a n y c h 
p r z e g l ą d o w y c h )  
DDP_029 Pole danych w komunikacie „Positive Response Transfer 
Data Overview” zawiera następujące dane w określonej tu 
kolejności pod SID 76 Hex, TREP 01, 21 lub 31 Hex, 
z odpowiednim podziałem na podkomunikaty i licznikami:  
Struktura danych generacji 1 (TREP 01 Hex)  
Element danych  Uwagi  
MemberStateCertificate  świadectwa bezpieczeństwa VU  
VUCertificate  
VehicleIdentificationNumber  identyfikacja pojazdu  
VehicleRegistrationIdentification  
CurrentDateTime  bieżąca data i godzina VU  
VuDownloadablePeriod  okres do pobrania  
CardSlotsStatus  typy kart włożonych do VU  
VuDownloadActivityData  poprzednie pobranie danych z VU  
VuCompanyLocksData  Wszystkie przechowywane blokady firmowe. 
Jeżeli sekcja jest pusta, wysyłany jest jedynie 
noOfLocks = 0.  
VuControlActivityData  Wszystkie rekordy dotyczące kontroli przechowy­
wane w VU. Jeżeli sekcja jest pusta, wysyłany 
jest jedynie noOfControls = 0.  
Signature  Podpis RSA wszystkich danych (z wyjątkiem 
certyfikatów), począwszy od elementu VehicleI­
dentificationNumber aż do ostatniego bajtu ostat­
niego elementu VuControlActivityData.  
Struktura danych generacji 2, wersja 1 (TREP 21 Hex)  
Element danych  Uwagi  
MemberStateCertificateRecordArray  certyfikat państwa członkowskiego  
VUCertificateRecordArray  certyfikat VU  
VehicleIdentificationNumberRecordArray  identyfikacja pojazdu  ▼M3
02016R0799 — PL — 21.08.2023 — 003.001 — 343  
Element danych  Uwagi  
VehicleRegistrationIdentificationRecordArray  numer rejestracyjny pojazdu  
CurrentDateTimeRecordArray  bieżąca data i godzina VU  
VuDownloadablePeriodRecordArray  okres do pobrania  
CardSlotsStatusRecordArray  typy kart włożonych do VU  
VuDownloadActivityDataRecordArray  poprzednie pobranie danych z VU  
VuCompanyLocksRecordArray  Wszystkie przechowywane blokady firmowe. 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek 
tablicy z noOfRecords = 0.  
VuControlActivityRecordArray  Wszystkie rekordy dotyczące kontroli przechowy­
wane w VU. Jeżeli sekcja jest pusta, wysyłany 
jest nagłówek tablicy z noOfRecords = 0.  
SignatureRecordArray  Podpis ECC wszystkich poprzednich danych, 
z wyjątkiem certyfikatów.  
Struktura danych generacji 2, wersja 2 (TREP 31 Hex)  
Element danych  Uwagi  
MemberStateCertificateRecordArray  certyfikat państwa członkowskiego  
VUCertificateRecordArray  certyfikat VU  
VehicleIdentificationNumberRecordArray  identyfikacja pojazdu  
VehicleRegistrationNumberRecordArray  numer rejestracyjny pojazdu  
CurrentDateTimeRecordArray  bieżąca data i godzina VU  
VuDownloadablePeriodRecordArray  okres do pobrania  
CardSlotsStatusRecordArray  typy kart włożonych do VU  
VuDownloadActivityDataRecordArray  poprzednie pobranie danych z VU  
VuCompanyLocksRecordArray  Wszystkie przechowywane blokady firmowe. 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek 
tablicy z noOfRecords = 0.  
VuControlActivityRecordArray  Wszystkie rekordy dotyczące kontroli przechowy­
wane w VU. Jeżeli sekcja jest pusta, wysyłany 
jest nagłówek tablicy z noOfRecords = 0.  
SignatureRecordArray  Podpis ECC wszystkich poprzednich danych, 
z wyjątkiem certyfikatów.  
2.2.6.3 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  A c t i v i t i e s ( P o z y ­
t y w n a o d p o w i e d ź n a ż ą d a n i e p r z e s ł a n i  a d a n y c h 
d o t y c z ą c y c h c z y n n o ś c i )  
DDP_030 Pole danych w komunikacie „Positive Response Transfer 
Data Activities” zawiera następujące dane w określonej tu 
kolejności pod SID 76 Hex, TREP 02, 22 lub 32 Hex, 
z odpowiednim podziałem na podkomunikaty i licznikami:  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 344  
Struktura danych generacji 1 (TREP 02 Hex)  
Element danych  Uwagi  
TimeReal  data pobieranego dnia  
OdometerValueMidnight  stan licznika kilometrów na koniec pobieranego dnia  
VuCardIWData  Dane dotyczące cykli wkładania wyjmowania kart. 
— Jeżeli sekcja ta nie zawiera dostępnych danych, 
wysyłany jest jedynie noOfVuCardIWRecords = 0. 
— Jeżeli VuCardIWRecord wykracza poza 00:00 
(włożenie karty poprzedniego dnia) lub poza 
24:00 (wyjęcie karty następnego dnia), musi poja­
wiać się w pełni w ciągu dwóch odpowiednich dni.  
VuActivityDailyData  Stan szczelin o godzinie 00:00 i zmiany czynności zapi­
sane dla pobieranego dnia.  
VuPlaceDailyWorkPeriodData  Dane dotyczące miejsc zapisane dla pobieranego dnia. 
Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfPla­
ceRecords = 0.  
VuSpecificConditionData  Dane dotyczące stanów szczególnych zapisane dla 
pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany 
jest jedynie noOfSpecificConditionRecords=0.  
Signature  Podpis RSA wszystkich danych, począwszy od 
elementu TimeReal aż do ostatniego bajtu ostatniego 
rekordu dotyczącego stanu szczególnego.  
Struktura danych generacji 2, wersja 1 (TREP 22 Hex)  
Element danych  Uwagi  
DateOfDayDownloadedRecordArray  data pobieranego dnia  
OdometerValueMidnightRecordArray  stan licznika kilometrów na koniec pobieranego dnia  
VuCardIWRecordArray  Dane dotyczące cykli wkładania wyjmowania kart. 
— Jeżeli ta sekcja nie zawiera dostępnych danych, 
wysyłany jest nagłówek tablicy z noOfRecords = 0. 
— Jeżeli VuCardIWRecord wykracza poza 00:00 
(włożenie karty poprzedniego dnia) lub poza 
24:00 (wyjęcie karty następnego dnia), musi poja­
wiać się w pełni w ciągu dwóch odpowiednich dni.  
VuActivityDailyRecordArray  Stan szczelin o godzinie 00:00 i zmiany czynności zapi­
sane dla pobieranego dnia.  
VuPlaceDailyWorkPeriodRecordArray  Dane dotyczące miejsc zapisane dla pobieranego dnia. 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy 
z noOfRecords = 0.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 345  
Element danych  Uwagi  
VuGNSSADRecordArray  Pozycje GNSS dla pojazdu, jeżeli skumulowany czas 
prowadzenia pojazdu osiągnie wielokrotność trzech 
godzin. Jeżeli sekcja jest pusta, wysyłany jest nagłówek 
tablicy z noOfRecords = 0.  
VuSpecificConditionRecordArray  Dane dotyczące stanów szczególnych zapisane dla 
pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany 
jest nagłówek tablicy z noOfRecords =0.  
SignatureRecordArray  Podpis ECC wszystkich poprzednich danych.  
Struktura danych generacji 2, wersja 2 (TREP 32 Hex)  
Element danych  Uwagi  
DateOfDayDownloadedRecordArray  data pobieranego dnia  
OdometerValueMidnightRecordArray  stan licznika kilometrów na koniec pobieranego dnia  
VuCardIWRecordArray  Dane dotyczące cykli wkładania wyjmowania kart. 
— Jeżeli ta sekcja nie zawiera dostępnych danych, 
wysyłany jest nagłówek tablicy z noOfRecords = 0. 
— Jeżeli VuCardIWRecord wykracza poza 00:00 
(włożenie karty poprzedniego dnia) lub poza 
24:00 (wyjęcie karty następnego dnia), musi poja­
wiać się w pełni w ciągu dwóch odpowiednich dni.  
VuActivityDailyRecordArray  Stan szczelin o godzinie 00:00 i zmiany czynności zapi­
sane dla pobieranego dnia.  
VuPlaceDailyWorkPeriodRecordArray  Dane dotyczące miejsc zapisane dla pobieranego dnia. 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy 
z noOfRecords = 0.  
VuGNSSADRecordArray  Pozycje GNSS dla pojazdu, jeżeli skumulowany czas 
prowadzenia pojazdu osiągnie wielokrotność trzech 
godzin. Jeżeli sekcja jest pusta, wysyłany jest nagłówek 
tablicy z noOfRecords = 0.  
VuSpecificConditionRecordArray  Dane dotyczące stanów szczególnych zapisane dla 
pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany 
jest nagłówek tablicy z noOfRecords =0.  
VuBorderCrossingRecordArray  Przekroczenia granicy dla pobranego dnia. Jeżeli sekcja 
jest pusta, wysyłany jest nagłówek tablicy z noOfRe­
cords = 0.  
VuLoadUnloadRecordArray  Operacje załadunku/rozładunku dla pobranego dnia. 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy 
z noOfRecords = 0.  
SignatureRecordArray  Podpis ECC wszystkich poprzednich danych.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 346  
2.2.6.4 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  E v e n t s a n d F a u l t s 
( P o z y t y w n a o d p o w i e d ź n a ż ą d a n i e p r z e  s ł a n i a 
d a n y c h d o t y c z ą c y c h z d a r z e ń i u s t e r e k  ) 
DDP_031 Pole danych w komunikacie „Positive Response Transfer 
Data Events and Faults” zawiera następujące dane w okre­ 
ślonej tu kolejności pod SID 76 Hex, TREP 03, 23 lub 33 
Hex, z odpowiednim podziałem na podkomunikaty i liczni­
kami:  
Struktura danych generacji 1 (TREP 03 Hex)  
Element danych  Uwagi  
VuFaultData  Wszystkie usterki przechowywane lub trwające w VU. 
Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfVu­
Faults = 0.  
VuEventData  Wszystkie zdarzenia (z wyjątkiem przekroczenia pręd­
kości) przechowywane lub trwające w VU. 
Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfVu­
Events = 0.  
VuOverSpeedingControlData  Dane dotyczące ostatniej kontroli przekroczenia pręd­
kości (wartość domyślna w przypadku braku danych).  
VuOverSpeedingEventData  Wszystkie zdarzenia dotyczące przekroczenia prędkości 
przechowywane w VU. 
Jeżeli sekcja jest pusta, wysyłany jest jedynie noOf­
VuOverSpeedingEvents = 0.  
VuTimeAdjustmentData  Wszystkie zdarzenia dotyczące korekty czasu przecho­
wywane w VU (poza ramami pełnej kalibracji). 
Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfVu­
TimeAdjRecords = 0.  
Signature  Podpis RSA wszystkich danych, począwszy od noOf­
VuFaults aż do ostatniego bajtu ostatniego rekordu 
dotyczącego korekty czasu.  
Struktura danych generacji 2, wersja 1 (TREP 23 Hex)  
Element danych  Uwagi  
VuFaultRecordArray  Wszystkie usterki przechowywane lub trwające w VU. 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy 
z noOfRecords = 0.  
VuEventRecordArray  Wszystkie zdarzenia (z wyjątkiem przekroczenia pręd­
kości) przechowywane lub trwające w VU. 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy 
z noOfRecords = 0.  
VuOverSpeedingControlDataRecordArray  Dane dotyczące ostatniej kontroli przekroczenia pręd­
kości (wartość domyślna w przypadku braku danych).  
VuOverSpeedingEventRecordArray  Wszystkie zdarzenia dotyczące przekroczenia prędkości 
przechowywane w VU. 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy 
z noOfRecords = 0.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 347  
Element danych  Uwagi  
VuTimeAdjustmentRecordArray  Wszystkie zdarzenia dotyczące korekty czasu przecho­
wywane w VU (poza ramami pełnej kalibracji). 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy 
z noOfRecords = 0.  
SignatureRecordArray  Podpis ECC wszystkich poprzednich danych.  
Struktura danych generacji 2, wersja 2 (TREP 33 Hex)  
Element danych  Uwagi  
VuFaultRecordArray  Wszystkie usterki przechowywane lub trwające w VU. 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy 
z noOfRecords = 0.  
VuEventRecordArray  Wszystkie zdarzenia (z wyjątkiem przekroczenia pręd­
kości) przechowywane lub trwające w VU. 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy 
z noOfRecords = 0.  
VuOverSpeedingControlDataRecordArray  Dane dotyczące ostatniej kontroli przekroczenia pręd­
kości (wartość domyślna w przypadku braku danych).  
VuOverSpeedingEventRecordArray  Wszystkie zdarzenia dotyczące przekroczenia prędkości 
przechowywane w VU. 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy 
z noOfRecords = 0.  
VuTimeAdjustmentRecordArray  Wszystkie zdarzenia dotyczące korekty czasu przecho­
wywane w VU (poza ramami pełnej kalibracji). 
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy 
z noOfRecords = 0.  
SignatureRecordArray  Podpis ECC wszystkich poprzednich danych.  
2.2.6.5 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  D e t a i l e d S p e e d 
( P o z y t y w n a o d p o w i e d ź n a ż ą d a n i e p r z e  s ł a n i a 
d a n y c h s z c z e g ó ł o w y c h d o t y c z ą c y c h p r  ę d k o ś c i )  
DDP_032 Pole danych w komunikacie „Positive Response Transfer 
Data Detailed Speed” zawiera następujące dane w okre­ 
ślonej tu kolejności pod SID 76 Hex, TREP 04 lub 24 
Hex, z odpowiednim podziałem na podkomunikaty i liczni­
kami:  
Struktura danych generacji 1 (TREP 04 Hex)  
Element danych  Uwagi  
VuDetailedSpeedData  Wszystkie szczegółowe dane dotyczące prędkości prze­
chowywane w VU (jeden blok prędkości dla minuty, 
przez którą pojazd był w ruchu). 
60 wartości prędkości na minutę (jedna na sekundę).  
Signature  Podpis RSA wszystkich danych, począwszy od noOf­
SpeedBlocks aż do ostatniego bajtu ostatniego bloku 
prędkości.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 348  
Struktura danych generacji 2 (TREP 24 Hex)  
Element danych  Uwagi  
VuDetailedSpeedBlockRecordArray  Wszystkie szczegółowe dane dotyczące prędkości prze­
chowywane w VU (jeden blok prędkości dla minuty, 
przez którą pojazd był w ruchu). 
60 wartości prędkości na minutę (jedna na sekundę).  
SignatureRecordArray  Podpis ECC wszystkich poprzednich danych.  
2.2.6.6 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  T e c h n i c a l D a t a 
( P o z y t y w n a o d p o w i e d ź n a ż ą d a n i e p r z e  s ł a n i a 
d a n y c h t e c h n i c z n y c h )  
DDP_033 Pole danych w komunikacie „Positive Response Transfer 
Data Technical Data” zawiera następujące dane w określonej 
tu kolejności pod SID 76 Hex, TREP 05, 25 lub 35 Hex, 
z odpowiednim podziałem na podkomunikaty i licznikami:  
Struktura danych generacji 1 (TREP 05 Hex)  
Element danych  Uwagi  
VuIdentification  
SensorPaired  
VuCalibrationData  Wszystkie rekordy dotyczące kalibracji przechowywane 
w VU.  
Signature  Podpis RSA wszystkich danych, począwszy od vuMa­
nufacturerName aż do ostatniego bajtu ostatniego 
VuCalibrationRecord.  
Struktura danych generacji 2, wersja 1 (TREP 25 Hex)  
Element danych  Uwagi  
VuIdentificationRecordArray  
VuSensorPairedRecordArray  Wszystkie sparowania państw członkowskich przecho­
wywane w VU.  
VuSensorExternalGNSSCoupledRecor­
dArray  Wszystkie powiązania urządzenia zewnętrznego GNSS 
przechowywane w VU.  
VuCalibrationRecordArray  Wszystkie rekordy dotyczące kalibracji przechowywane 
w VU.  
VuCardRecordArray  Wszystkie dane dotyczące włożenia karty przechowy­
wane w VU.  
VuITSConsentRecordArray  
VuPowerSupplyInterruptionRecordArray  
SignatureRecordArray  Podpis ECC wszystkich poprzednich danych.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 349  
Struktura danych generacji 2, wersja 2 (TREP 35 Hex)  
Element danych  Uwagi  
VuIdentificationRecordArray  
VuSensorPairedRecordArray  Wszystkie sparowania państw członkowskich przecho­
wywane w VU.  
VuSensorExternalGNSSCoupledRecor­
dArray  Wszystkie powiązania urządzenia zewnętrznego GNSS 
przechowywane w VU.  
VuCalibrationRecordArray  Wszystkie rekordy dotyczące kalibracji przechowywane 
w VU.  
VuCardRecordArray  Wszystkie dane dotyczące włożenia karty przechowy­
wane w VU.  
VuITSConsentRecordArray  
VuPowerSupplyInterruptionRecordArray  
SignatureRecordArray  Podpis ECC wszystkich poprzednich danych.  
▼B 
2.3. Gromadzenie plików na ESM  
DDP_034 Jeżeli sesja pobierania obejmuje przesłanie danych z VU , 
IDE w jednym fizycznym pliku przechowuje wszystkie 
dane odebrane z VU w czasie tej sesji przesłane z komuni­
katami „Positive Response Transfer Data”. Dane przecho­
wuje się bez nagłówków komunikatów, liczników podko­
munikatów, pustych podkomunikatów i sum kontrolnych, 
ale wraz z SID i TREP (tylko pierwszego podkomunikatu 
w przypadku kilku podkomunikatów).  
3. PROTOKÓŁ POBIERANIA DANYCH Z KART DO TACHO­
GRAFÓW  
3.1. Zakres  
W tym punkcie opisano bezpośrednie pobieranie danych z karty do  
tachografu do IDE. IDE nie jest częścią bezpiecznego środowiska ; 
dlatego też nie wykonuje się uwierzytelnienia między kartą a ID E. 
3.2. Definicje  
Sesja pobierania : Sesja pobierania ma miejsce za 
każdym razem, gdy pobiera się 
dane z karty ICC. Sesja obej­
muje całą procedurę od zaini­
cjowania karty ICC przez IFD 
do dezaktywowania karty ICC 
(wyjęcie karty lub następne 
zainicjowanie).  
Podpisany plik danych : Plik z karty ICC. Plik przesyła 
się do IFD w formie odkrytego 
tekstu. Na karcie ICC skrót 
pliku jest obliczany i podpisy­
wany, a podpis jest przesyłany 
do IFD.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 350  
3.3. Pobieranie danych z karty  
▼M3 
DDP_035 Pobieranie danych z karty do tachografu obejmuje następ u­
jące kroki:  
— Pobieranie wspólnych informacji zawartych na karcie 
w plikach EF ICC oraz IC. Dane te są nieobowiązkowe 
i nie są chronione podpisem cyfrowym.  
— W przypadku kart do tachografów pierwszej i drugiej 
generacji  
— Pobieranie w plikach EF w Tachograph DF:  
— Wczytanie plików EF Card_Certificate i CA_Certifi­
cate. Dane te nie są chronione podpisem cyfrowym.  
Pobranie tych plików jest obowiązkowe dla 
każdej sesji pobierania.  
— Wczytanie plików EF zawierających inne dane 
aplikacyjne (w DF Tachograph) z wyłączeniem 
EF Card_Download. Informacje takie są zabez­
pieczone podpisem cyfrowym przy użyciu 
wspólnych mechanizmów zabezpieczenia okre­ 
ślonych w dodatku 11 część A.  
— Pobranie przynajmniej plików EF Applica­
tion_Identification oraz Identification jest 
obowiązkowe dla każdej sesji pobierania.  
— Przy pobieraniu danych z karty kierowcy 
obowiązkowe jest pobranie także następujących 
plików EF:  
Events_Data,  
Faults_Data,  
Driver_Activity_Data,  
Vehicles_Used,  
Places,  
Control_Activity_Data,  
Specific_Conditions.  
— Wyłącznie w przypadku kart do tachografów drugiej 
generacji:  
— Z wyjątkiem sytuacji gdy pobranie danych z karty 
kierowcy włożonej do przyrządu rejestrującego 
odbywa się w trakcie kontroli kierowców przeprowa­
dzanej przez organ kontrolny spoza UE przy użyciu 
karty kontrolnej pierwszej generacji, pobieranie 
w plikach EF Tachograph_G2 DF:  
— Pobieranie w plikach EF CardSignCertificate, 
CA_Certificate oraz Link_Certificate. Dane te 
nie są chronione podpisem cyfrowym.  
— Pobranie tych plików jest obowiązkowe dla 
każdej sesji pobierania.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 351  
— Wczytanie plików EF zawierających inne dane 
aplikacyjne (w Tachograph_G2 DF) z wyłącze­
niem EF Card_Download. Informacje takie są 
zabezpieczone podpisem cyfrowym przy użyciu 
wspólnych mechanizmów zabezpieczenia okre­ 
ślonych w dodatku 11 część B.  
— Pobranie przynajmniej plików EF: Applica­
tion_Identification, Application_Identifica­
tion_V2 (jeżeli występuje) oraz Identification 
jest obowiązkowe dla każdej sesji pobierania.  
— Przy pobieraniu danych z karty kierowcy 
obowiązkowe jest pobranie także następujących 
plików EF:  
Events_Data,  
Faults_Data,  
Driver_Activity_Data,  
Vehicles_Used,  
Places,  
Control_Activity_Data,  
Specific_Conditions,  
VehicleUnits_Used,  
GNSS_Places,  
Places_Authentication, jeżeli występuje,  
GNSS_Places_Authentication, jeżeli występuje,  
Border_Crossings, jeżeli występuje,  
Load_Unload_Operations, jeżeli występuje,  
Load_Type_Entries, jeżeli występuje.  
— Przy wczytywaniu danych z karty kierowcy 
aktualizowana jest data LastCardDownload 
w pliku EF Card_Download, w DF Tachograph 
i, w stosownych przypadkach, Tachograph_G2.  
— Przy pobieraniu danych z karty warsztatowej 
zerowany jest licznik kalibracji w pliku EF 
CardDownload w DF Tachograph i, w stosow­
nych przypadkach, Tachograph_G2.  
— Przy pobieraniu danych z karty warsztatowej 
pliki EF Sensor_Installation_Data w DF Tacho­
graph i, w stosownych przypadkach, Tacho­
graph_G2 nie mogą być pobierane.  
▼B 
3.3.1  Sekwencja inicjalizuj ąca 
DDP_036 IDE inicjuje następującą sekwencję:  
Karta  Kierunek  IDE/IFD  Znaczenie/Uwagi  
⇦ restart sprzętowy  
ATR ⇨ 
Opcjonalnie można używać protokołu PPS do przełączania 
na większą szybkość transmisji, o ile ICC obsługuje tę 
funkcję.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 352  
3.3.2  Sekwencja dla niepodpisanych plików danych  
DDP_037  ►M1 Sekwencja pobierania plików elementarnych ICC, 
IC, Card_Certificate (lub CardSignCertificate dla DF Tacho­
graph_G2), CA_Certificate i Link_Certificate (wyłącznie dla 
DF Tachograph_G2) jest następująca: ◄  
Karta  Kierunek  IDE/IFD  Znaczenie/Uwagi  
⇦ Select File  wybierz poprzez identyfikator 
pliku  
OK ⇨ 
⇦ Read Binary  Jeżeli wielkość danych 
w pliku jest większa od 
pojemności bufora czytnika 
lub karty, polecenie musi 
być powtarzane aż do odczy­
tania całego pliku.  
File Data 
OK ⇨ zapisz dane na ESM  zgodnie z pkt  3.4  Format 
gromadzenia danych  
Uwaga 1:  przed wybraniem Card_Certificate (lub CardSign­
Certificate) EF musi być wybrana aplikacja tachograficzna 
(wybór poprzez AID).  
Uwaga 2:  wybór i odczyt pliku może być również wyko­
nany za jednym razem przy użyciu polecenia Read Binary 
z krótkim identyfikatorem EF.  
3.3.3  Sekwencja dla podpisanych plików danych  
DDP_038 Dla każdego pliku, który pobrany jest z podpisem, stosu je 
się następującą sekwencję operacji:  
▼M1 
Karta  Kierunek  IDE/IFD  Znaczenie / Uwagi
  
Select File  
OK
 
Perform Hash of File  — Oblicza wartość skrótu dla 
danych wybranego pliku 
przy pomocy wymaga­
nego algorytmu skrótu 
zgodnie z dodatkiem 11 
część A lub B. Polecenie 
to nie jest poleceniem 
ISO. 
oblicz skrót pliku 
i czasowo zachowaj 
wartość skrótu  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 353  
Karta  Kierunek  IDE/IFD  Znaczenie / Uwagi  
OK
 
Read Binary  Jeżeli wielkość danych 
w pliku jest większa od 
pojemności bufora czytnika 
lub karty, polecenie musi 
być powtarzane aż do odczy­
tania całego pliku.  
File Data 
OK
 zapisz odebrane dane na 
ESM  zgodnie z  3.4  Data storage 
format
  
PSO: Compute Digital 
Signature  
wykonaj operację 
zabezpieczającą 
„Compute Digital 
Signature”, używając 
czasowo zachowaną 
wartość skrótu  
Signature 
OK
 dołącz dane do poprzednio 
zapisanych danych na ESM  zgodnie z  3.4  Data storage 
format  
▼B 
Uwaga:  wybór i odczyt pliku może być również wykonany 
za jednym razem przy użyciu polecenia Read Binary 
z krótkim identyfikatorem EF. W tym przypadku EF może 
być wybrany i odczytany przed zastosowaniem polecenia 
Perform Hash of File.  
3.3.4  Sekwencja zerowania licznika kalibracji  
DDP_039 Sekwencja zerowania licznika kalibracji
  
w pliku EF
  
na karcie warsztatowej jest następująca:  
Karta  Kierunek  IDE/IFD  Znaczenie/Uwagi  
⇦ Select File  EF 
Card_Download  wybierz poprzez identyfikator 
pliku  
OK ⇨ 
⇦ Update Binary  
NoOfCalibrationsSinceDown­
load = „00 00”  
zeruje liczbę pobrań 
danych z karty  
OK ⇨ 
Uwaga:  wybór i odczyt pliku może być również wykonany 
za jednym razem przy użyciu polecenia Update Binary 
z krótkim identyfikatorem EF.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 354  
3.4. Format gromadzenia danych  
3.4.1  Wprowadzenie  
DDP_040 Pobrane dane należy przechowywać w sposób zgodny 
z następującymi wymaganiami:  
— Dane przechowuje się transparentnie. Oznacza to, że 
przy gromadzeniu należy zachować kolejność bajtów, 
jak i kolejność bitów w bajcie taką jak przy przesyłaniu 
z karty.  
— Wszystkie pliki pobrane z karty w ramach sesji pobie­
rania przechowuje się w jednym pliku na ESM.  
3.4.2  Format pliku  
DDP_041 Format pliku jest konkatenacją kilku obiektów TLV.  
DDP_042 Znacznikiem pliku EF jest jego identyfikator FID z doda t­
kiem „00”.  
DDP_043 Znacznikiem podpisu pliku EF jest identyfikator pliku F ID 
z dodatkiem „01”.  
DDP_044 Długość podana jest w postaci dwubajtowej wartości. 
Wartość określa liczbę bajtów w polu wartości. Wartość 
„FF FF” w polu długości jest zastrzeżona do wykorzystania 
w przyszłości.  
DDP_045 Gdy plik nie jest pobrany, nie zachowuje się żadnych 
danych dotyczących tego pliku (nie ma znacznika i nie 
ma zerowej długości).  
▼M1 
DDP_046 Podpis zachowuje się w obiekcie TLV znajdującym się 
bezpośrednio za obiektem TLV zawierającym dane pliku.  
Definicja  Znaczenie  Długość  
FID (2 bajty) || „00”  Znacznik pliku EF (FID) 
w DF
  lub 
wspólnych informacji 
zawartych na karcie  3 bajty  
FID (2 bajty) || „01”  Znacznik podpisu pliku 
EF (FID) w DF
  3 bajty  
FID (2 bajty) || „02”  Znacznik podpisu pliku 
EF (FID) w DF
  3 bajty  
FID (2 bajty) || „03”  Znacznik podpisu pliku 
EF (FID) w DF
  3 bajty  
xx xx  długość pola wartości  2 bajty  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 355  
Przykładowe dane w pliku pobranym na ESM:  
Znacznik  Długość  Wartość
  
— Dane pliku EF ICC
  
— Dane pliku EF Card_Certificate  
— ...
  
Dane pliku EF
  (w DF
  
)
 
Podpis pliku EF
  (w DF
  
)
 
Dane pliku EF
  ­
w DF
  
Podpis pliku EF
  ­
_Used w DF
  
▼B 
4. POBIERANIE DANYCH Z KARTY DO TACHOGRAFU ZA 
POŚREDNICTWEM PRZYRZĄDU REJESTRUJĄCEGO  
DDP_047 VU musi umożliwiać pobieranie danych z włożonej karty 
kierowcy do przyłączonego IDE.  
DDP_048 IDE wysyła do VU komunikat „Transfer Data Request Card 
Download” w celu zainicjowania tego trybu (zob. pkt 
2.2.2.9).  
▼M1 
DDP_049 Karty kierowcy pierwszej generacji: Dane pobiera się pr zy 
użyciu protokołu pobierania danych pierwszej generacji, 
a pobierane dane muszą mieć taki sam format jak dane 
pobierane z przyrządu rejestrującego pierwszej generacji.  
Karty kierowcy drugiej generacji: Następnie VU pobiera 
wszystkie dane z karty, plik po pliku, zgodnie z protokołem 
pobierania danych z karty zdefiniowanym w pkt 3, oraz 
przekazuje wszystkie dane odebrane z karty do IDE w odpo­
wiednim formacie pliku TLV (zob. 3.4.2) i zapakowane 
w komunikacie „Positive Response Transfer Data”.  
▼B 
DDP_050 IDE odzyskuje dane z karty z komunikatu „Positive 
Response Transfer Data” (usuwając wszystkie nagłówki, 
SID, TREP, liczniki podkomunikatów i sumy kontrolne) 
i zachowuje te dane w jednym fizycznym pliku jak opisano 
w pkt 2.3.  
DDP_051 Następnie VU, stosownie do przypadku, aktualizuje plik­
  
lub
 na karcie 
kierowcy.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 356  
Dodatek 8  
PROTOKÓ Ł KALIBRACJI  
SPIS TREŚCI  
1. WPROWADZENIE  
2. POJĘCIA, DEFINICJE I ODNIESIENIA  
3. INFORMACJE OGÓLNE O USŁUGACH  
3.1. Dostępne usługi  
3.2. Kody odpowiedzi  
4. USŁUGI KOMUNIKACYJNE  
4.1. Usługa StartCommunication  
4.2. Usługa StopCommunication  
4.2.1 Opis komunikatu  
4.2.2 Format komunikatu  
4.2.3 Definicja parametru  
4.3. Usługa TesterPresent  
4.3.1 Opis komunikatu  
4.3.2 Format komunikatu  
5. USŁUGI ZARZĄDZANIA  
5.1. Usługa StartDiagnosticSession  
5.1.1 Opis komunikatu  
5.1.2 Format komunikatu  
5.1.3 Definicja parametru  
5.2. Usługa SecurityAccess  
5.2.1 Opis komunikatu  
5.2.2 Format komunikatu – SecurityAccess – requestSeed  
5.2.3 Format komunikatu – SecurityAccess – sendKey  
6. USŁUGI PRZESYŁANIA DANYCH  
6.1. Usługa ReadDataByIdentifier  
6.1.1 Opis komunikatu  
6.1.2 Format komunikatu  
6.1.3 Definicja parametru  
6.2. UsługaWriteDataByIdentifier  
6.2.1 Opis komunikatu  
6.2.2 Format komunikatu  
6.2.3 Definicja parametru  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 357  
7. STEROWANIE IMPULSAMI TESTUJĄCYMI – JEDNOSTKA 
FUNKCJONALNA STEROWANIA WE/WY  
7.1. Usługa InputOutputControlByIdentifier  
7.1.1 Opis komunikatu  
7.1.2 Format komunikatu  
7.1.3 Definicja parametru  
▼M3 
8. USŁUGA ROUTINECONTROL (KOREKTA CZASU)  
8.1. Opis komunikatu  
8.2. Format komunikatu  
9. FORMATY DATARECORDS  
9.1. Zakresy przesyłanych parametrów  
9.2. Formaty dataRecords  
▼B 
1. WPROWADZENIE  
Niniejszy dodatek opisuje wymianę danych między przyrządem reje s­
trującym a testerem poprzez łącze K-line, które stanowi część i nterfejsu 
kalibracyjnego opisanego w dodatku 6. Opisano tu także sterowan ie 
linią sygnałową we/wy w złączu kalibracji.  
Komunikaty zestawiające łącze K-line opisano w sekcji 4 „Usługi  
komunikacyjne”.  
W niniejszym dodatku wykorzystano koncepcję „sesji” diagnostycz ­
nych do ustalania zakresu kontroli K-line dla różnych warunków.  
Sesją domyślną jest „StandardDiagnosticSession”, w której wszys tkie 
dane można odczytać z przyrządu rejestrującego, ale żadnych dan ych 
nie można zapisać w przyrządzie rejestrującym.  
Wybór sesji diagnostycznej opisano w sekcji 5 „Usługi zarządzan ia”. 
Niniejszy dodatek musi być uznany za odnoszący się do obu gener acji 
VU i kart warsztatowych, zgodnie z wymaganiami w zakresie inter o­
peracyjności określonymi w niniejszym rozporządzeniu.  
CPR_001 Sesja „ECUProgrammingSession” umożliwia wprowadzanie 
danych do przyrządu rejestrującego. W przypadku wprowa­
dzania danych kalibracyjnych przyrząd rejestrujący musi 
pracować w trybie KALIBRACYJNYM.  
Przesyłanie danych poprzez K-line opisano w sekcji 6 
„Usługi przesyłania danych”. Formaty przesyłanych danych 
opisano szczegółowo w sekcji 8 „Formaty dataRecords”.  
CPR_002 Sesja „ECUAdjustmentSession” umożliwia wybranie trybu 
we/wy dla linii sygnałowej we/wy kalibracji poprzez inter­
fejs K-line. Sterowanie linią sygnałową we/wy kalibracji 
opisano w sekcji 7„Sterowanie impulsami testującymi – 
jednostka funkcjonalna sterowania we/wy”.  
CPR_003 W niniejszym dokumencie adres testera określony jest ja ko 
„tt”. Chociaż mogą być zalecane adresy dla testerów, VU 
odpowiada prawidłowo na dowolny adres testera. 
Fizycznym adresem VU jest 0xEE.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 358  
2. POJĘCIA, DEFINICJE I ODNIESIENIA  
Protokoły, komunikaty i kody błędów oparte są zasadniczo na 
projekcie normy ISO 14229-1 (Pojazdy drogowe — Systemy diagno­
styczne — część 1: Usługi diagnostyczne, wersja 6 z dnia 22 lut ego 
2001 r.).  
Kodowania bajtowego i wartości heksadecymalnych używa się w ide n­
tyfikatorach usług, żądaniach usług i odpowiedziach oraz parame trach 
standardowych.  
Pojęcie „tester” oznacza urządzenie służące do wprowadzania do VU 
danych programistycznych/kalibracyjnych.  
Pojęcia „klient” i „serwer” oznaczają odpowiednio tester i VU.  
Pojęcie ECU oznacza „sterownik elektroniczny” i odnosi się do V U. 
Odniesienia:  
▼M1 
ISO 14230-2: Pojazdy drogowe – Systemy diagnostyczne – Protokół  
słowa kluczowego 2000 – część 2: Warstwa łącza danych.  
Wydanie pierwsze: 1999.  
▼B 
3. INFORMACJE OGÓLNE O USŁUGACH  
3.1. Dost ępne usługi 
Tabela poniżej zawiera informacje ogólne o usługach, które są 
dostępne w tachografie i są zdefiniowane w niniejszym dokumenci e. 
CPR_004 Tabela wskazuje usługi dostępne przy włączonej sesji 
diagnostycznej.  
— Pierwsza kolumna  zawiera wykaz dostępnych usług.  
— Druga kolumna  zawiera numer sekcji w niniejszym 
dodatku, gdzie usługa jest dokładniej zdefiniowana.  
— Trzecia kolumna  przypisuje wartości identyfikatora 
usługi dla komunikatów żądań.  
— Czwarta kolumna  określa usługi  „StandardDiagnos ­
ticSession” (SD) , których wdrożenie jest wymagane 
w każdym VU.  
— Piąta kolumna  określa usługi  „ECUAdjustmentSes ­
sion” (ECUAS) , które muszą być wdrożone w celu 
umożliwienia sterowania linią sygnałową we/wy 
w złączu kalibracji w panelu czołowym VU.  
— Szósta kolumna  określa usługi  „ECUProgrammin ­
gSession” (ECUPS) , które muszą być wdrożone 
w celu umożliwienia programowania parametrów w VU.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 359  
Tabela 1  
Zestawienie warto ści identyfikatorów us ług 
Sesje diagnostyczne  
Nazwa usługi diagnostycznej  Sekcja nr  Wartość SId 
Req. SD ECUAS  ECUPS  
StartCommunication  4.1  8 1  ■  ■  ■  
StopCommunication  4.2  8 2  ■  
TesterPresent  4.3  3 E  ■  ■  ■  
StartDiagnosticSession  5.1  1 0  ■  ■  ■  
SecurityAccess  5.2  2 7  ■  ■  ■  
ReadDataByIdentifier  6.1  2 2  ■  ■  ■  
WriteDataByIdentifier  6.2  2 E  ■  
InputOutputControlByIdentifier  7.1  2 F  ■  
▼M3 
RoutineControl  8  3 1  ■  ■  
▼B 
■ Symbol ten oznacza, że usługa jest obowiązkowa w tej sesji dia gnostycznej. 
Brak symbolu oznacza, że usługa nie jest dozwolona w tej sesji diagnostycznej.  
3.2. Kody odpowiedzi  
Kody odpowiedzi są zdefiniowane dla każdej usługi.  
4. USŁUGI KOMUNIKACYJNE  
Niektóre usługi są niezbędne do ustanowienia i utrzymania komun i­
kacji. Nie występują one w warstwie aplikacji. Dostępne usługi 
wyszczególniono w tabeli poniżej:  
Tabela 2  
Usługi komunikacyjne  
Nazwa usługi  Wyszczególnienie  
StartCommunication  Klient żąda rozpoczęcia sesji komuni­
kacyjnej z serwerem(-ami).  
StopCommunication  Klient żąda zaprzestania bieżącej sesji 
komunikacyjnej.  
TesterPresent  Klient wskazuje serwerowi, że jest 
jeszcze obecny.  
CPR_005 Usługa StartCommunication służy do rozpoczęcia komuni­
kacji. W celu wykonania usługi konieczne jest zainicjowanie 
komunikacji i ustawienie parametrów odpowiednio dla 
pożądanego trybu.  
4.1. Usługa StartCommunication  
CPR_006 Po odebraniu prymitywu wskazania StartCommunication 
VU sprawdza, czy w obecnych warunkach można zaini­
cjować żądane łącze komunikacyjne. Warunki zezwalające 
na zainicjowanie łącza komunikacyjnego opisano w normie 
ISO 14230-2.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 360  
CPR_007 Następnie VU wykonuje wszystkie działania niezbędne do 
zainicjowania łącza komunikacyjnego i wysyła prymityw 
odpowiedzi StartCommunication z wybranymi parametrami 
Positive Response.  
CPR_008 Jeżeli VU, który jest już zainicjowany (ma otwartą dowo lną 
sesję diagnostyczną), otrzymuje nowe żądanie StartCommu­
nication (np. wskutek usuwania błędu w testerze), żądanie 
zostanie przyjęte, a VU ponownie zainicjowany.  
CPR_009 Jeżeli z jakiejkolwiek przyczyny nie można zainicjować łącza 
komunikacyjnego, VU pracuje tak jak pracował bezpośrednio 
przed próbą zainicjowania łącza komunikacyjnego.  
CPR_010 Komunikat żądania StartCommunication musi mieć fizyczny  
adres.  
CPR_011 Inicjowanie usług w VU odbywa się metodą „szybkiej 
inicjalizacji”:  
— Przed każdą czynnością występuje czas jałowy 
magistrali.  
— Następnie tester wysyła kod inicjujący.  
— Wszystkie informacje niezbędne do nawiązania komuni­
kacji zawarte są w odpowiedzi VU.  
CPR_012 Po zakończeniu inicjalizacji:  
— Wszystkie parametry komunikacyjne zostają ustawione 
na wartości zdefiniowane w tabeli 4 zgodnie z bajtami 
kluczowymi.  
— VU czeka na pierwsze żądanie testera.  
— VU znajduje się w domyślnym trybie diagnostycznym, 
tj. StandardDiagnosticSession.  
— Linia sygnałowa we/wy kalibracji jest w stanie 
domyślnym, tj. w stanie „disabled” (wyłączona).  
CPR_014 Szybkość transmisji K-line jest ustawiona na 10 400 bod ów. 
CPR_016 Szybką inicjalizację uruchamia tester, wysyłając kod wy wo­ 
ływania (Wup) przez K-line. Kod rozpoczyna się po czasie 
jałowym na K-line niskim stanem w czasie Tinil. Tester 
wysyła pierwszy bit usługi StartCommunication po czasie 
Twup następującym po pierwszej krawędzi opadającej.
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 361  
CPR_017 Wartości czasów dla szybkiej inicjalizacji i ogólnie ko mu­
nikatów podano w tabeli poniżej. Dla czasu jałowego są 
różne możliwości:  
— pierwsza transmisja po włączeniu zasilania, Tidle = 
300 ms;  
— po zakończeniu usługi StopCommunication, Tidle = P3 
min; 
— po zatrzymaniu komunikacji wskutek upływu czasu 
oczekiwania P3 max, Tidle = 0.  
Tabela 3  
Wartości czasów dla szybkiej inicjalizacji  
Parametr  Wartość min.  Wartość maks.  
Tinil  25 ± 1 ms  24 ms  26 ms  
Twup  50 ± 1 ms  49 ms  51 ms  
Tabela 4  
Wartości czasów dla komunikacji  
Parametr 
czasowy  Opis parametru  Dolna granica 
[ms] Górna granica 
[ms] 
min. maks.  
P1 Czas między bajtami dla odpo­
wiedzi VU  0 2 0  
P2 Czas między żądaniem testera 
a odpowiedzią VU lub dwiema 
odpowiedziami VU  25 250  
P3 Czas między końcem odpo­
wiedzi VU a początkiem 
nowego żądania testera  55 5 000  
P4 Czas między bajtami dla 
żądania testera  5 2 0  
CPR_018 Format komunikatu dla szybkiej inicjalizacji opisano sz cze­
gółowo w poniższych tabelach.  
Tabela 5  
Komunikat StartCommunication Request  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  81 FMT  
#2 Bajt adresu docelowego  E E  TGT  
#3 Bajt adresu źródłowego  t t  SRC  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 362  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#4 StartCommunication Request 
Service Id  81 SCR  
#5 Suma kontrolna  00-FF  C S  
Tabela 6  
Komunikat StartCommunication Positive Reponse  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 3  LEN  
#5 StartCommunication Positive 
Response Service Id  C1 SCRPR  
#6 Bajt kluczowy 1  E A  KB1  
#7 Bajt kluczowy 2  8 F  KB2  
#8 Suma kontrolna  00-FF  C S  
CPR_019 Nie ma negatywnej odpowiedzi na komunikat StartCommu­
nication Request, gdy nie zostanie wysłana pozytywna 
odpowiedź, VU nie zostaje zainicjowany, nic nie jest prze­
syłane i VU pozostaje w stanie normalnej pracy.  
4.2. Usługa StopCommunication  
4.2.1  Opis komunikatu  
Celem tej usługi warstwy komunikacji jest zakończenie sesji 
komunikacyjnej.  
CPR_020 Po odebraniu prymitywu wskazania StopCommunication 
VU sprawdza, czy bieżące warunki pozwalają na zakoń­
czenie tej komunikacji. W tym przypadku VU wykonuje 
wszystkie działania niezbędne do zakończenia sesji 
komunikacyjnej.  
CPR_021 Jeżeli zakończenie sesji komunikacyjnej jest możliwe, V U – 
przed zakończeniem komunikacji – wysyła prymityw odpo­
wiedzi StopCommunication z wybranymi parametrami Posi­
tive Response.  
CPR_022 Jeżeli zakończenie sesji komunikacyjnej nie jest możliw e 
z jakiejkolwiek przyczyny, VU wysyła prymityw odpo­
wiedzi StopCommunication z wybranym parametrem Nega­
tive Response.  
CPR_023 Jeżeli VU wykryje przekroczenie czasu P3 max, komuni­
kacja zostaje zakończona bez wysyłania żadnego prymitywu 
odpowiedzi.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 363  
4.2.2  Format komunikatu  
CPR_024 Formaty komunikatu dla prymitywów StopCommunication 
opisano szczegółowo w poniższych tabelach.  
Tabela 7  
Komunikat StopCommunication Request  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  E E  TGT  
#3 Bajt adresu źródłowego  t t  SRC  
#4 Dodatkowy bajt długości  0 1  LEN  
#5 StopCommunication Request 
Service Id  82 SPR  
#6 Suma kontrolna  00-FF  C S  
Tabela 8  
Komunikat StopCommunication Positive Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 1  LEN  
#5 StopCommunication Positive 
Response Service Id  C2 SPRPR  
#6 Suma kontrolna  00-FF  C S  
Tabela 9  
Komunikat StopCommunication Negative Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 3  LEN  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 364  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#5 negative Response Service Id  7F  NR  
#6 StopCommunication Request 
Service Identification  82 SPR  
#7 responseCode = generalReject  1 0  RC_GR  
#8 Suma kontrolna  00-FF  C S  
4.2.3  Definicja parametru  
Ta usługa nie wymaga żadnych definicji parametrów.  
4.3. Usługa TesterPresent  
4.3.1  Opis komunikatu  
Tester używa usługi TesterPresent do wskazania serwerowi, że je szcze 
jest obecny, w celu zapobieżenia automatycznemu powrotowi serwe ra 
do normalnego trybu pracy i zerwania komunikacji. Usługa ta, wy sy­ 
łana okresowo, utrzymuje sesję diagnostyczną/komunikacyjną w st anie 
aktywnym, zerując timer P3 za każdym razem po odebraniu żądania  tej 
usługi.  
4.3.2  Format komunikatu  
CPR_079 Formaty komunikatu dla prymitywów TesterPresent opisano  
szczegółowo w poniższych tabelach.  
Tabela 10  
Komunikat TesterPresent Request  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  E E  TGT  
#3 Bajt adresu źródłowego  t t  SRC  
#4 Dodatkowy bajt długości  0 2  LEN  
#5 TesterPresent Request 
Service Id  3E TP  
#6 podfunkcja = respon­
seRequired =  [ tak  0 1  RESPREQ_Y  
nie ]  0 2  RESPREQ_NO  
#7 Suma kontrolna  00-FF  C S  
CPR_080 Jeżeli parametr responseRequired jest ustawiony na „tak ”, to 
serwer odpowie niżej przedstawionym komunikatem pozy­
tywnej odpowiedzi. Jeżeli jest ustawiony na „nie”, serwer 
nie wysyła żadnej odpowiedzi.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 365  
Tabela 11  
Komunikat TesterPresent Positive Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 1  LEN  
#5 TesterPresent Positive 
Response Service Id  7E TPPR  
#6 Suma kontrolna  00-FF  C S  
CPR_081 Usługa używa następujących kodów negatywnej 
odpowiedzi:  
Tabela 12  
Komunikat TesterPresent Negative Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 3  LEN  
#5 negative Response Service Id  7F  NR  
#6 TesterPresent Request Service Identi­
fication  3E T P  
#7 response­
Code =  [SubFunctionNotSup­
ported-InvalidFormat  12 RC_SFNS_IF  
incorrectMessage­
Length ]  13 RC_IML  
#8 Suma kontrolna  00-FF  C S  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 366  
5. USŁUGI ZARZĄDZANIA  
Dostępne usługi wyszczególniono w tabeli poniżej:  
Tabela 13  
Usługi zarządzania  
Nazwa usługi  Wyszczególnienie  
StartDiagnosticSession  Klient żąda rozpoczęcia sesji diagnostycznej 
z VU.  
SecurityAccess  Klient żąda dostępu do funkcji zastrzeżonych 
dla uprawnionych użytkowników.  
5.1. Usługa StartDiagnosticSession  
5.1.1  Opis komunikatu  
CPR_025 Usługa StartDiagnosticSession służy do włączania różnyc h 
sesji diagnostycznych w serwerze. Sesja diagnostyczna 
udostępnia swoisty zestaw usług zgodnie z opisem w Tabeli 
17. Sesja może udostępnić producentowi pojazdu usługi 
swoiste nieobjęte tym dokumentem. Zasady wdrożenia 
muszą spełniać następujące wymagania:  
— W VU aktywna jest zawsze dokładnie jedna sesja 
diagnostyczna.  
— Po włączeniu zasilania VU zawsze uruchamia Standard­
DiagnosticSession. Jeżeli żadna inna sesja diagnostyczna 
nie zostanie uruchomiona, wówczas StandardDiagnostic­
Session pozostaje uruchomiona tak długo, jak włączone 
jest zasilanie VU.  
— Jeżeli jest już uruchomiona sesja diagnostyczna zażą­
dana przez tester, VU wysyła komunikat pozytywnej 
odpowiedzi.  
— Za każdym razem kiedy tester żąda nowej sesji diagno­
stycznej, VU najpierw wysyła komunikat pozytywnej 
odpowiedzi StartDiagnosticSession, zanim nowa sesja 
stanie się aktywna w VU. Jeżeli VU nie może 
uruchomić żądanej nowej sesji diagnostycznej, to odpo­
wiada komunikatem negatywnej odpowiedzi StartDiag­
nosticSession i bieżąca sesja jest kontynuowana.  
CPR_026 Sesja diagnostyczna może zostać uruchomiona tylko wtedy , 
gdy nawiązana jest komunikacja między klientem a VU.  
CPR_027 Parametry czasowe zdefiniowane w tabeli 4 są aktywne po  
pomyślnym uruchomieniu sesji StartDiagnosticSession 
z parametrem diagnosticSession ustawionym na „Standard­
DiagnosticSession” w komunikacie żądania, jeżeli 
poprzednio aktywna była inna sesja diagnostyczna.  
5.1.2  Format komunikatu  
CPR_028 Formaty komunikatu dla prymitywów StartDiagnosticSes­
sion opisano szczegółowo w poniższych tabelach.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 367  
Tabela 14  
Komunikat StartDiagnosticSession Request  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  E E  TGT  
#3 Bajt adresu źródłowego  t t  SRC  
#4 Dodatkowy bajt długości  0 2  LEN  
#5 StartDiagnosticSession 
Request Service Id  10 STDS  
#6 diagnosticSession = [jedna 
wartość z tabeli 17]  xx DS_…  
#7 Suma kontrolna  00-FF  C S  
Tabela 15  
Komunikat StartDiagnosticSession Positive Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 2  LEN  
#5 StartDiagnosticSession Posi ­
tive Response Service Id  50 STDSPR  
#6 diagnosticSession = [ta sama 
wartość jak dla bajtu #6 
w tabeli 14]  xx DS_…  
#7 Suma kontrolna  00-FF  C S  
Tabela 16  
Komunikat StartDiagnosticSession Negative Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 368  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#4 Dodatkowy bajt długości  0 3  LEN  
#5 Negative Response Service Id  7F  NR  
#6 StartDiagnosticSession Request 
Service Id  10 STDS  
#7 Response­
Code =  [subFunctionNotSup­
ported (  α ) 12 RC_SFNS  
incorrectMessage­
Length (  β ) 13 RC_IML  
conditionsNotCor­
rect (  γ ) 22 RC_CNC  
#8 Suma kontrolna  00-FF  C S  
( α ) – wartość wstawiona w bajcie #6 komunikatu żądania nie jest o bsługiwana, tzn. nie 
ma jej w tabeli 17; 
( β ) – długość komunikatu jest nieprawidłowa; 
( γ ) – kryteria żądania StartDiagnosticSession nie są spełnione.  
5.1.3  Definicja parametru  
CPR_029 Parametr  diagnosticSession (DS_)  używany jest w usłudze 
StartDiagnosticSession do wybierania szczególnego zacho­
wania serwera(-ów). W niniejszym dokumencie określone są 
następujące sesje diagnostyczne:  
Tabela 17  
Definicja warto ści diagnosticSession  
Heks  Wyszczególnienie  Mnemonik  
81 StandardDiagnosticSession  
Ta sesja diagnostyczna udostępnia wszystkie 
usługi wyszczególnione w  tabeli 1 w kolumnie 
4 „SD” . Usługi te umożliwiają odczyt danych 
z serwera (VU). Ta sesja diagnostyczna jest 
aktywna po pomyślnym zakończeniu inicjacji 
między klientem (tester) a serwerem (VU). Tę 
sesję diagnostyczną można zastąpić każdą inną 
sesją diagnostyczną wyszczególnioną w tej 
sekcji.  SD 
85 ECUProgrammingSession  
Ta sesja diagnostyczna udostępnia wszystkie 
usługi wyszczególnione w  tabeli 1 w kolumnie 
6 „ECUPS” . Usługi te wspomagają programo- 
wanie pamięci serwera (VU). Tę sesję diagnos- 
tyczną można zastąpić każdą inną sesją 
diagnostyczną wyszczególnioną w tej sekcji.  ECUPS  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 369  
Heks  Wyszczególnienie  Mnemonik  
87 ECUAdjustmentSession  
Ta sesja diagnostyczna udostępnia wszystkie 
usługi wyszczególnione w  tabeli 1 w kolumnie 
5 „ECUAS”.  Usługi te wspomagają sterowania 
we/wy serwera (VU). Tę sesję diagnostyczną 
można zastąpić każdą inną sesją diagnostyczną 
wyszczególnioną w tej sekcji.  ECUAS  
5.2. Usługa SecurityAccess  
Zapis danych kalibracyjnych nie jest możliwy w trybie KALIBRA­
CYJNYM. Dodatkowo, oprócz włożenia do VU ważnej karty warsz­
tatowej, niezbędne jest wprowadzenie numeru PIN do VU przed uzy s­
kaniem dostępu do trybu KALIBRACYJNEGO.  
Jeżeli VU jest w trybie KALIBRACYJNYM lub KONTROLNYM, 
dostęp do linii we/wy kalibracji jest również możliwy.  
Usługa SecurityAccess umożliwia wprowadzenie numeru PIN i przek a­
zanie testerowi, czy VU jest w trybie KALIBRACYJNYM.  
Dopuszcza się wprowadzanie numeru PIN alternatywnymi metodami.  
5.2.1  Opis komunikatu  
Usługa SecurityAccess zawiera komunikat SecurityAccess „reques­
tSeed”, po którym może nastąpić komunikat SecurityAccess 
„sendKey”. Usługa SecurityAccess musi być przeprowadzona po 
usłudze StartDiagnosticSession.  
CPR_033 Tester używa komunikatu SecurityAccess „requestSeed” do  
sprawdzenia, czy przyrząd rejestrujący jest gotowy do przy­
jęcia numeru PIN.  
CPR_034 Jeżeli przyrząd rejestrujący jest już w trybie KALIBRA­
CYJNYM, odpowiada na żądanie wysyłając „seed” równy 
0x0000 przy pomocy usługi SecurityAccess Positive 
Response.  
CPR_035 Jeżeli przyrząd rejestrujący jest gotowy do przyjęcia n umeru 
PIN w celu zweryfikowania go przez kartę warsztatową, 
odpowiada na żądanie wysyłając „seed” większy niż 0x0000 
przy pomocy usługi SecurityAccess Positive Response.  
CPR_036 Jeżeli przyrząd rejestrujący nie jest gotowy do przyjęc ia 
numeru PIN z testera, albo z tego powodu, że włożona 
karta warsztatowa nie jest ważna lub nie włożono żadnej 
karty warsztatowej lub przyrząd rejestrujący oczekuje na 
wprowadzenie numeru PIN inną metodą, odpowiada na 
żądanie wysyłając negatywną odpowiedź (Negative 
Reponse) z kodem odpowiedzi ustawionym na condition­
sNotCorrectOrRequestSequenceError.  
CPR_037 Następnie tester używa ostatecznie komunikatu SecurityA c­
cess „sendKey” do przesłania numeru PIN do przyrządu 
rejestrującego. Aby karta miała wystarczający czas na prze­
prowadzenie uwierzytelnienia, VU w celu przedłużenia czasu 
oczekiwania na odpowiedź używa kodu negatywnej odpo­
wiedzi requestCorrectlyReceived-ResponsePending. Maksy­
malny czas oczekiwania na odpowiedź nie może jednak prze­
kraczać 5 minut. Gdy tylko żądana usługa zostaje zakoń­
czona, VU wysyła komunikat pozytywnej odpowiedzi lub  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 370  
komunikat negatywnej odpowiedzi z kodem odpowiedzi 
różnym od tego pierwszego kodu. VU może powtarzać kod 
negatywnej odpowiedzi requestCorrectlyReceived-Response­
Pending aż do zakończenia żądanej usługi i wysłania komu­
nikatu ostatecznej odpowiedzi.  
CPR_038 Przyrząd rejestrujący odpowiada na to żądanie przy pomo cy 
usługi SecurityAccess Positive Response jedynie wtedy, gdy 
jest w trybie KALIBRACYJNYM.  
CPR_039 W następujących przypadkach przyrząd rejestrujący odpo­
wiada na to żądanie negatywną odpowiedzią (Negative 
Reponse) z następującą wartością kodu odpowiedzi:  
— subFunctionNot supported: niedozwolony format dla 
parametru podfunkcji (accessType);  
— conditionsNotCorrectOrRequestSequenceError: przyrząd 
rejestrujący nie jest gotowy do przyjęcia numeru PIN;  
— invalidKey: nieprawidłowy numer PIN i nieprzekroczona 
dozwolona liczba prób sprawdzania numeru PIN;  
— exceededNumberOfAttempts: nieprawidłowy numer PIN 
i przekroczona dozwolona liczba prób sprawdzania 
numeru PIN;  
— generalReject: prawidłowy numer PIN, ale nieudane 
wzajemne uwierzytelnienie z kartą warsztatową.  
5.2.2  Format komunikatu – SecurityAccess – requestSeed  
CPR_040 Formaty komunikatu dla prymitywów SecurityAccess 
„requestSeed” opisano szczegółowo w poniższych tabelach.  
Tabela 18  
Komunikat SecurityAccess Request- requestSeed  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  E E  TGT  
#3 Bajt adresu źródłowego  t t  SRC  
#4 Dodatkowy bajt długości  0 2  LEN  
#5 SecurityAccess Request 
Service Id  27 SA  
#6 accessType – requestSeed  7 D  AT_RSD  
#7 Suma kontrolna  00-FF  C S  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 371  
Tabela 19  
Komunikat SecurityAccess – requestSeed Positive Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 4  LEN  
#5 SecurityAccess Positive 
Response Service Id  67 SAPR  
#6 accessType – requestSeed  7 D  AT_RSD  
#7 Seed High  00-FF  SEEDH  
#8 Seed Low  00-FF  SEEDL  
#9 Suma kontrolna  00-FF  C S  
Tabela 20  
Komunikat SecurityAccess Negative Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 3  LEN  
#5 negativeResponse Service Id  7F  NR  
#6 SecurityAccess Request Service Id  2 7  S A  
#7 response­
Code =  [conditionsNotCorrec­
tOrRequestSequence­
Error  22 RC_CNC  
incorrectMessage­
Length]  13 RC_IML  
#8 Suma kontrolna  00-FF  C S  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 372  
5.2.3  Format komunikatu – SecurityAccess – sendKey  
CPR_041 Formaty komunikatu dla prymitywów SecurityAccess 
„sendKey” opisano szczegółowo w poniższych tabelach.  
Tabela 21  
Komunikat SecurityAccess Request – sendKey  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  E E  TGT  
#3 Bajt adresu źródłowego  t t  SRC  
#4 Dodatkowy bajt długości  m+2  LEN  
#5 SecurityAccess Request 
Service Id  27 SA  
#6 accessType – sendKey  7 E  AT_SK  
#7 do #m+6  Klucz#1 (najwyższy)  x x  KEY  
… …  
Klucz #m (niższy, m musi być 
minimum 4 i maksimum 8)  xx 
#m+7  Suma kontrolna  00-FF  C S  
Tabela 22  
Komunikat SecurityAccess – sendKey Positive Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 2  LEN  
#5 SecurityAccess Positive 
Response Service Id  67 SAPR  
#6 accessType – sendKey  7 E  AT_SK  
#7 Suma kontrolna  00-FF  C S  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 373  
Tabela 23  
Komunikat SecurityAccess Negative Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 3  LEN  
#5 NegativeResponse Service Id  7F  NR  
#6 SecurityAccess Request Service Id  2 7  S A  
#7 Response­
Code =  [generalReject  1 0  RC_GR  
subFunctionNotSup­
ported  12 RC_SFNS  
incorrectMessage­
Length  13 RC_IML  
conditionsNotCorrec­
tOrRequestSequence­
Error  22 RC_CNC  
invalidKey  3 5  RC_IK  
exceededNumberO­
fAttempts  36 RC_ENA  
requestCorrectlyRe­
ceived-ResponsePen­
ding]  78 RC_RCR_RP  
#8 Suma kontrolna  00-FF  C S  
6. USŁUGI PRZESYŁANIA DANYCH  
Dostępne usługi wyszczególniono w tabeli poniżej:  
Tabela 24  
Usługi przesy łania danych  
Nazwa usługi  Wyszczególnienie  
ReadDataByIdentifier  Klient żąda przesłania bieżącej wartości 
rekordu z dostępem poprzez recordDataIden­
tifier.  
WriteDataByIdentifier  Klient żąda zapisu rekordu z dostępem 
poprzez recordDataIdentifier.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 374  
6.1. Usługa ReadDataByIdentifier  
6.1.1  Opis komunikatu  
CPR_050 Klient używa usługi ReadDataByIdentifier do żądania 
wartości rekordów danych z serwera. Dane są identyfiko­
wane przez recordDataIdentifier. Producent VU odpowiada 
za spełnienie warunków serwera przy wykonywaniu tej 
usługi.  
6.1.2  Format komunikatu  
CPR_051 Formaty komunikatu dla prymitywów ReadDataByIdentifier 
opisano szczegółowo w poniższych tabelach.  
Tabela 25  
Komunikat ReadDataByIdentifier Request  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  E E  TGT  
#3 Bajt adresu źródłowego  t t  SRC  
#4 Dodatkowy bajt długości  0 3  LEN  
#5 ReadDataByIdentifier 
Request Service Id  22 RDBI  
#6 do #7  recordDataIdentifier = [wartość 
z tabeli 28]  xxxx  RDI_…  
#8 Suma kontrolna  00-FF  C S  
Tabela 26  
Komunikat ReadDataByIdentifier Positive Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  m  +  3  LEN  
#5 ReadDataByIdentifier Positive 
Response Service Id  62 RDBIPR  
#6 i #7  recordDataIdentifier = [ta sama 
wartość jak dla bajtów #6 i #7 
w tabeli 25]  xxxx  RDI_…  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 375  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#8 do 
#m + 7  dataRecord[] =  [data#1  x x  DREC_DAT­
A1 
: :  :  
data#m]  x x  DREC_DAT­
Am 
#m+8  Suma kontrolna  00-FF  C S  
Tabela 27  
Komunikat ReadDataByIdentifier Negative Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 3  LEN  
#5 NegativeResponse Service Id  7F  NR  
#6 ReadDataByIdentifier Request 
Service Id  22 RDBI  
#7 Response­
Code=  [requestOutOf­
Range  31 RC_ROOR  
incorrectMessage­
Length  13 RC_IML  
conditionsNotCor­
rect] 22 RC_CNC  
#8 Suma kontrolna  00-FF  C S  
6.1.3  Definicja parametru  
CPR_052 Parametr  recordDataIdentifier (RDI_)  w komunikacie 
żądania ReadDataByIdentifier wskazuje rekord danych.  
▼M3 
CPR_053 Wartości recordDataIdentifier zdefiniowane w tym doku­
mencie pokazano w tabeli poniżej.  
Tabela recordDataIdentifier składa się z pięciu kolumn 
i wielu wierszy.  
— Pierwsza kolumna (Heks)  zawiera „wartość heksadecy­
malną” przypisaną identyfikatorowi recordDataIdentifier 
z trzeciej kolumny.  
— Druga kolumna (Element danych)  określa element 
danych z dodatku 1, na którym oparty jest identyfikator 
recordDataIdentifier (czasami niezbędne jest przekodo­
wanie).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 376  
— Trzecia kolumna (Opis)  podaje nazwę odpowiadają­
cego identyfikatora recordDataIdentifier.  
— Czwarta kolumna (Prawa dost ępu) określa prawa 
dostępu do tego identyfikatora recordDataIdentifier.  
— Piąta kolumna (Mnemonik)  podaje mnemonik tego 
identyfikatora recordDataIdentifier.  
Tabela 28  
Definicja warto ści recordDataIdentifier  
Heks  Element danych  Nazwa recordDataldentifier 
(zob. format w sekcji 8.2)  Prawa 
dostępu 
(Read/ 
Write)  Mnemonik  
F90B  CurrentDateTime  TimeDate  R/W  RDI_TD  
F912  HighResOdometer  HighResolutionTotalVehicleDis­
tance  R/W  RDI_HRTVD  
F918  K-ConstantOfRecordingEquipment  Kfactor  R/W  RDI_KF  
F91C  L-TyreCircumference  LfactorTyreCircumference  R/W  RDI_LF  
F91D  W-VehicleCharacteristicConstant  WvehicleCharacteristicFactor  R/W  RDI_WVCF  
F921  TyreSize  TyreSize  R/W  RDI_TS  
F922  nextCalibrationDate  NextCalibrationDate  R/W  RDI_NCD  
F92C  SpeedAuthorised  SpeedAuthorised  R/W  RDI_SA  
F97D  vehicleRegistrationNation  RegisteringMemberState  R/W  RDI_RMS  
F97E  VehicleRegistrationNumber  VehicleRegistrationNumber  R/W  RDI_ VRN  
F190  VehicleIdentificationNumber  VIN  R/W  RDI_ VIN  
F9D0  SensorSerialNumber  MotionSensorSerialNumber  R  RDI_SSN  
F9D1  RemoteCommunicationModuleSerial­
Number  RemoteCommunicationFacility­
SerialNumber  R RDI_RCSN  
F9D2  SensorGNSSSerialNumber  ExternalGNSSFacilitySerial­
Number  R RDI_GSSN  
F9D3  SealDataVu  SmartTachographSealsSerial­
Number  R/W  RDI_SDV  
F9D4  VuSerialNumber  VuSerialNumber  R  RDI_VSN  
F9D5  ByDefaultLoadType  ByDefaultLoadType  R/W  RDI_BDLT  
F9D6  TachographCardsGen1Suppression  TachographCardsGen1Suppres­
sion R/W  RDI_TCG1S  
F9D7  VehiclePosition  VehiclePosition  R  RDI_VP  
F9D8  LastCalibrationCountry  CalibrationCountry  R  RDI_CC  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 377  
CPR_054 Parametr  dataRecord (DREC_)  używany jest w komunikacie 
pozytywnej odpowiedzi ReadDataByIdentifier do dostar­
czania wartości rekordu danych wskazanego klientowi 
(testerowi) identyfikatorem recordDataIdentifier. Formaty 
danych określono w sekcji 8. Można wprowadzić dodat­
kowe opcjonalne dataRecords użytkownika obejmujące 
szczególne dane wejściowe, wewnętrzne i wyjściowe VU, 
ale nie są one zdefiniowane w tym dokumencie.  
6.2. UsługaWriteDataByIdentifier  
6.2.1  Opis komunikatu  
CPR_056 Usługa WriteDataByIdentifier używana jest przez klienta  do 
zapisania wartości rekordu danych w serwerze. Dane są 
identyfikowane przez recordDataIdentifier. Producent VU 
odpowiada za spełnienie warunków serwera przy wykony­
waniu tej usługi. Aby aktualizować parametry wymienione 
w tabeli 28, VU musi być w trybie KALIBRACYJNYM.  
6.2.2  Format komunikatu  
CPR_057 Formaty komunikatu dla prymitywów WriteDataByIdentifier  
opisano szczegółowo w poniższych tabelach.  
Tabela 29  
Komunikat WriteDataByIdentifier Request  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  E E  TGT  
#3 Bajt adresu źródłowego  t t  SRC  
#4 Dodatkowy bajt długości  m+3  LEN  
#5 WriteDataByIdentifier Request 
Service Id  2E WDBI  
#6 do #7  recordDataIdentifier = [wartość 
z tabeli 28]  xxxx  RDI_…  
#8 do m+7  dataRecord[] =  [data#1  x x  DREC_DAT­
A1 
: :  :  
data#m]  x x  DREC_DAT­
Am 
#m+8  Suma kontrolna  00-FF  C S  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 378  
Tabela 30  
Komunikat WriteDataByIdentifier Positive Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 3  LEN  
#5 WriteDataByIdentifier Posi ­
tive Response Service Id  6E WDBIPR  
#6 do #7  recordDataIdentifier = [ta sama 
wartość jak dla bajtów #6 i #7 
w tabeli 29]  xxxx  RDI_…  
#8 Suma kontrolna  00-FF  C S  
Tabela 31  
Komunikat WriteDataByIdentifier Negative Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 3  LEN  
#5 NegativeResponse Service Id  7F  NR  
#6 WriteDataByIdentifier Request 
Service Id  2E WDBI  
#7 Response­
Code=  [requestOutOf­
Range  31 RC_ROOR  
incorrectMessage­
Length  13 RC_IML  
conditionsNotCor­
rect] 22 RC_CNC  
#8 Suma kontrolna  00-FF  C S  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 379  
6.2.3  Definicja parametru  
Parametr  recordDataIdentifier (RDI_)  zdefiniowano w tabeli 28.  
Parametr  dataRecord (DREC_)  używany jest w komunikacie żądania 
WriteDataByIdentifier do dostarczenia wartości rekordu danych w ska­
zanego serwerowi (VU) przez recordDataIdentifier. Formaty danyc h 
określono w sekcji 8.  
7. STEROWANIE IMPULSAMI TESTUJĄCYMI – JEDNOSTKA 
FUNKCJONALNA STEROWANIA WE/WY  
Dostępne usługi wyszczególniono w tabeli poniżej:  
Tabela 32  
Jednostka funkcjonalna sterowania we/wy  
Nazwa usługi  Wyszczególnienie  
InputOutputControl­
ByIdentifier  Klient żąda sterowania we/wy specyficznego 
dla serwera.  
7.1. Usługa InputOutputControlByIdentifier  
7.1.1  Opis komunikatu  
Przez przednie gniazdo zestawione jest połączenie, które umożli wia 
sterowanie lub monitorowanie impulsów testowych przy pomocy odp o­
wiedniego testera.  
CPR_058 Tę linię sygnałową we/wy kalibracji można skonfigurować  
poleceniem K-line, posługując się usługą InputOutputCon­
trolByIdentifier w celu wybrania dla linii wymaganej funkcji 
wejścia lub wyjścia. Linia może przyjmować następujące 
stany:  
— disabled (wyłączona);  
— speedSignalInput, w którym linia sygnałowa we/wy 
kalibracji używana jest do wprowadzenia sygnału pręd­
kości (sygnał testowy) zastępującego sygnał prędkości 
z czujnika ruchu; ta funkcja nie jest dostępna w trybie 
KONTROLNYM;  
— realTimeSpeedSignalOutputSensor, w którym linia 
sygnałowa we/wy kalibracji używana jest do wyprowa­
dzenia sygnału prędkości z czujnika ruchu;  
— RTCOutput, w którym linia sygnałowa we/wy kalibracji 
używana jest do wyprowadzenia sygnału zegarowego 
UTC; ta funkcja nie jest dostępna w trybie KONTRO­
LNYM.  
CPR_059 Przyrząd rejestrujący musi być wprowadzony do sesji reg u­
lacji i być w trybie KALIBRACYJNYM lub KONTRO­
LNYM w celu skonfigurowania stanu linii. Jeżeli VU jest 
w trybie KALIBRACYJNYM, można wybrać cztery stany 
linii (disabled, speedSignalInput, realTimeSpeedSignalOut­
putSensor, RTCOutput). Jeżeli VU jest w trybie KONTRO­
LNYM, można wybrać tylko dwa stany linii (disabled, real­
TimeSpeedOutputSensor). Na zakończenie sesji regulacji 
lub trybu KALIBRACYJNEGO lub KONTROLNEGO 
przyrząd rejestrujący musi zapewnić, aby linia sygnałowa 
we/wy kalibracji powróciła do stanu „disabled” (wyłączona 
– stan domyślny).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 380  
CPR_060 Jeżeli impulsy prędkości odbierane są w czasie rzeczy­
wistym z linii sygnału wejściowego prędkości w VU, nato­
miast linia sygnałowa we/wy kalibracji jest ustawiona na 
wejście, to linia sygnałowa we/wy kalibracji zostanie usta­
wiona na wyjście lub powróci do stanu „disabled” (wyłą­
czona).  
CPR_061 Kolejność czynności jest następująca:  
— uruchomienie komunikacji usługą StartCommunication;  
— otworzenie sesji regulacji usługą StartDiagnosticSession 
i wejście do trybu KALIBRACYJNEGO lub KONTRO­
LNEGO (kolejność tych dwóch czynności nie ma 
znaczenia);  
— zmiana stanu wyjścia usługą InputOutputControlByIden­
tifier.  
7.1.2  Format komunikatu  
CPR_062 Formaty komunikatu dla prymitywów InputOutputControl­
ByIdentifier opisano szczegółowo w poniższych tabelach.  
Tabela 33  
Komunikat InputOutputControlByIdentifier Request  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  E E  TGT  
#3 Bajt adresu źródłowego  t t  SRC  
#4 Dodatkowy bajt długości  x x  LEN  
#5 InputOutputControlByIden ­
tifier Request Sid  2F IOCBI  
#6 i #7  InputOutputIdentifier = [Calib­
rationInputOutput]  F960  IOI_CIO  
#8 lub 
#8 do #9  ControlOptionRecord = [  COR_…  
inputOutputControlParameter – 
jedna wartość z tabeli 36  xx IOCP_…  
controlState – jedna wartość 
z tabeli 37 (zob. uwaga 
poniżej)]  xx CS_…  
#9 lub #10  Suma kontrolna  00-FF  C S  
Uwaga:  Parametr controlState występuje tylko w określo­
nych przypadkach (zob. 7.1.3).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 381  
Tabela 34  
Komunikat InputOutputControlByIdentifier Positive Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  x x  LEN  
#5 inputOutputControlByIdenti ­
fier Positive Response SId  6F IOCBIPR  
#6 i #7  inputOutputIdentifier = [Calib­
rationInputOutput]  F960  IOI_CIO  
#8 lub 
#8 do #9  controlStatusRecord = [  CSR_  
inputOutputControlParameter 
(ta sama wartość jak dla bajtu 
#8 w tabeli 33)  xx IOCP_…  
controlState (ta sama wartość 
jak dla bajtu #9 w tabeli 33)] 
(jeżeli dotyczy)  xx CS_…  
#9 lub #10  Suma kontrolna  00-FF  C S  
Tabela 35  
Komunikat InputOutputControlByIdentifier Negative Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 3  LEN  
#5 negativeResponse Service Id  7F  NR  
#6 inputOutputControlByIdentifier 
Request SId  2F IOCBI  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 382  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#7 responseCode=[  
incorrectMessageLength  1 3  RC_IML  
conditionsNotCorrect  2 2  RC_CNC  
requestOutOfRange  3 1  RC_ROOR  
deviceControlLimitsExceeded]  7 A  RC_DCLE  
#8 Suma kontrolna  00-FF  C S  
7.1.3  Definicja parametru  
CPR_064 Parametr  inputOutputControlParameter (IOCP_)  zdefinio­
wano w poniższej tabeli.  
Tabela 36  
Definicja warto ści inputOutputControlParameter  
Heks  Wyszczególnienie  Mnemonik  
00 ReturnControlToECU  
Wartość ta wskazuje serwerowi (VU), że tester 
już nie steruje linią sygnałową we/wy kalibracji.  RCTECU  
01 ResetToDefault  
Wartość ta wskazuje serwerowi (VU), że wyma- 
gane jest przełączenie linii sygnałowej we/wy 
kalibracji do stanu domyślnego.  RTD  
03 ShortTermAdjustment  
Wartość ta wskazuje serwerowi (VU), że wyma- 
gane jest przełączenie linii sygnałowej we/wy 
kalibracji do żądanej wartości w celu wyregulo- 
wania parametru controlState.  STA  
CPR_065 Parametr  controlState  występuje jedynie wtedy, gdy para­
metr inputOutputControlParameter jest ustawiony na Shor­
tTermAdjustment i przyjmuje wartości zdefiniowane 
w poniższej tabeli.  
Tabela 37  
Definicja warto ści controlState  
Tryb  Wartość heksa­
decymalna  Wyszczególnienie  
wyłączony  0 0  linia we/wy wyłączona (stan domyślny)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 383  
Tryb  Wartość heksa­
decymalna  Wyszczególnienie  
włączony  0 1  włącz linię sygnałową we/wy kalibracji jako 
speedSignalInput  
włączony  0 2  włącz linię sygnałową we/wy kalibracji jako 
realTimeSpeedSignalOutputSensor  
włączony  0 3  włącz linię sygnałową we/wy kalibracji jako 
RTCOutput  
▼M3 
8. USŁUGA ROUTINECONTROL (KOREKTA CZASU)  
8.1. Opis komunikatu  
CPR_065a Usługa RoutineControl (TimeAdjustment) umożliwia 
uruchomienie operacji dostosowania zegara VU do czasu 
podawanego przez odbiornik GNSS.  
Na potrzeby realizacji usługi RoutineControl (TimeAdjus­
tment) VU musi być w trybie KALIBRACYJNYM.  
Warunek wst ępny: zapewnia się zdolność VU do odbie­
rania komunikatów o uwierzytelnionej pozycji z odbiornika 
GNSS.  
Dopóki trwa korekta czasu, VU odpowiada na żądanie 
RoutineControl, podfunkcja requestRoutineResults, z routi­
neInfo = 0x78.  
Uwaga: korekta czasu może być dość czasochłonna. Tester 
diagnostyczny żąda statusu korekty czasu za pomocą 
podfunkcji requestRoutineResults.  
8.2. Format komunikatu  
CPR_065b Formaty komunikatu dla usługi RoutineControl (TimeAd­
justment) i jej prymitywów opisano szczegółowo w poniż­
szych tabelach.  
Tabela 37a  
RoutineControl, komunikat żądania procedury (TimeAdjustment), podfunkcja startRoutine  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  E E  TGT  
#3 Bajt adresu źródłowego  t t  SRC  
#4 Dodatkowy bajt długości  x x  LEN  
#5 RoutineControl Request Sid (Sid żądania RoutineControl)  31  RC  
#6 routineControlType = [startRoutine]  0 1  RCTP_STR  
#7 i #8  routineIdentifier = [TimeAdjustment]  0100  RI_TA  
#9 Suma kontrolna  00-FF  C S  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 384  
Tabela 37b  
RoutineControl, procedura (TimeAdjustment), podfunkcja startRoutine, komunikat pozytywnej odpowiedzi  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  x x  LEN  
#5 RoutineControl Positive Response Sid (Sid pozytywnej odpowiedzi 
na RoutineControl)  71 RCPR  
#6 routineControlType = [startRoutine]  0 1  RCTP_STR  
#7 i #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 Suma kontrolna  00-FF  C S  
Tabela 37c  
RoutineControl, komunikat żądania procedury (TimeAdjustment), podfunkcja requestRoutineResults  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  E E  TGT  
#3 Bajt adresu źródłowego  t t  SRC  
#4 Dodatkowy bajt długości  x x  LEN  
#5 RoutineControl Request Sid (Sid żądania RoutineControl)  31  RC  
#6 routineControlType = [requestRoutineResults]  0 3  RCTP_RRR  
#7 i #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 Suma kontrolna  00-FF  C S  
Tabela 37d  
RoutineControl, procedura (TimeAdjustment), podfunkcja requestRoutineResults, komunikat pozytywnej 
odpowiedzi  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  x x  LEN  
#5 RoutineControl Positive Response Sid (Sid pozytywnej odpowiedzi 
na RoutineControl)  71 RCPR  
#6 routineControlType = [requestRoutineResults]  0 3  RCTP_RRR  
#7 i #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 routineInfo (zob. tabela 37f)  X X  RINF_TA  
#10 routineStatusRecord[] = routineStatus#1 (zob. tabela 37g)  X X  RS_TA  
#11 Suma kontrolna  00-FF  C S  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 385  
Tabela 37e  
RoutineControl, komunikat negatywnej odpowiedzi na procedur ę (TimeAdjustment)  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  8 0  FMT  
#2 Bajt adresu docelowego  t t  TGT  
#3 Bajt adresu źródłowego  E E  SRC  
#4 Dodatkowy bajt długości  0 3  LEN  
#5 negativeResponse Service Id (ID us ługi negatywnej odpowiedzi)  7F  NR  
#6 inputOutputControlByIdentifier Request SId  3 1  RC  
#7 responseCode=[ 
sub-functionNotSupported 
incorrectMessageLengthOrInvalidFormat 
conditionsNotCorrect 
requestOutOfRange 
] 12 
13 
22 
31 SFNS 
IMLOIF 
CNC 
ROOR  
#8 Suma kontrolna  00-FF  C S  
Tabela 37f  
RoutineControl, procedura (TimeAdjustment), routineInfo  
routineInfo  Wartość heksa­
decymalna  Opis 
NormalExitWithResultAvailable  6 1  Procedura została wykonana w całości; dostępne są 
dodatkowe wyniki procedury.  
RoutineExecutionOngoing  7 8  Żądana procedura jest nadal wykonywana.  
Tabela 37g  
RoutineControl, procedura (TimeAdjustment), routineStatus  
Wartość heksadecy­
malna  Wynik próby  Opis  
01 pozytywny  Korekta czasu zakończyła się pomyślnie.  
02..0F  RFU  
10 negatywny  Brak odbioru sygnału GNSS.  
11..7F  RFU  
80..FF  swoisty dla producenta  
9. FORMATY DATARECORDS  
W tej sekcji opisano szczegółowo:  
— ogólne zasady odnoszące się do szeregu parametrów wysyłanych 
przez przyrząd rejestrujący do testera,  
— formaty, które należy stosować dla danych przesyłanych poprze z 
usługi przesyłania danych opisane w sekcji 6.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 386  
CPR_067 VU obsługuje wszystkie wyszczególnione parametry.  
CPR_068 Dane wysyłane przez przyrząd rejestrujący do testera 
w odpowiedzi na komunikat żądania są typu pomiarowego 
(tj. bieżąca wartość żądanego parametru pomierzona lub 
stwierdzona przez VU).  
9.1. Zakresy przesy łanych parametrów  
CPR_069 W tabeli 38 podano wartości zakresów używane do spraw­
dzania poprawności przesłanego parametru.  
CPR_070 Wartości w zakresie „wskaźnik błędu” umożliwiają przyrz ą­
dowi rejestrującemu niezwłoczne wskazanie, że poprawne 
dane parametryczne nie są dostępne w bieżącym czasie 
wskutek pewnego typu błędu w tachografie.  
CPR_071 Wartości w zakresie „niedostępne” umożliwiają przyrzą­
dowi rejestrującemu wysłanie komunikatu zawierającego 
parametr, który nie jest dostępny bądź nie jest obsługiwany 
w tym module. Wartości w zakresie „nieżądane” umożli­
wiają urządzeniu wysłanie komunikatu polecenia i wska­
zanie tych parametrów, w przypadku gdy od urządzenia 
odbierającego oczekiwany jest brak odpowiedzi.  
CPR_072 Jeżeli usterka elementu składowego uniemożliwia wysłani e 
prawidłowych danych dla parametru, zamiast danych para­
metru używa się wskaźnika błędu opisanego w tabeli 38. 
Jednak jeżeli dane pomierzone lub obliczone dają wartość, 
która jest poprawna, ale wychodzi poza zdefiniowany 
zakres parametru, nie należy używać wskaźnika błędu. 
Dane przesyłane są używając odpowiednio wartości mini­
malnej lub maksymalnej parametru.  
Tabela 38  
Zakresy dataRecords  
Nazwa zakresu  1 bajt 
(wartość heksa­
decymalna)  2 bajty 
(wartość heksadecy­
malna)  4 bajty 
(wartość heksadecymalna)  ASCII  
Prawidłowy sygnał  00 do FA  0000 do FAFF  00000000 do FAFFFFFF  1 do 254  
Szczególny wskaźnik parametru  F B  FB00 do FBFF  FB000000 do FBFFFFFF  brak  
Zastrzeżony zakres do wykorzystania 
w przyszłości  FC do FD  FC00 do FDFF  FC000000 do FDFFFFFF  brak  
Wskaźnik błędu  F E  FE00 do FEFF  FE000000 do FEFFFFFF  0  
Niedostępne lub nieżądane  F F  FF00 do FFFF  FF000000 do FFFFFFFF  F F  
CPR_073 Dla parametrów kodowanych w ASCII znak ASCII „*” jest 
zastrzeżony jako ogranicznik.  
9.2. Formaty dataRecords  
W tabelach od 39 do 42 poniżej opisano szczegółowo formaty 
używane przez usługi ReadDataByIdentifier i WriteDataByIdentifi er. ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 387  
CPR_074 W tabeli 39 podano długość, rozdzielczość i zakres robo czy 
dla każdego parametru identyfikowanego przez recordDataI­
dentifier:  
Tabela 39  
Format dataRecords  
Nazwa parametru  Długość 
danych 
(w bajtach)  Rozdzielczość  Zakres roboczy  
TimeDate  8  Zob. szczegółowy opis w tabeli 40  
HighResolutionTotalVehicleDis­
tance  4 wzmocnienie 5 m/bit, 
offset 0 m  0 do +21 055 406 km  
Kfactor  2  wzmocnienie 0,001 impulsu/m/ 
bit, offset 0  0 do 64,255 impulsu/m  
LfactorTyreCircumference  2  wzmocnienie 0,125 10  -3 m/bit, 
offset 0  0 do 8,031 m  
WvehicleCharacteristicFactor  2  wzmocnienie 0,001 impulsu/m/ 
bit, offset 0  0 do 64,255 impulsu/m  
TyreSize  1 5  ASCII  ASCII  
NextCalibrationDate  3  Zob. szczegółowy opis w tabeli 41  
SpeedAuthorised  2  wzmocnienie 1/256km/h/bit, 
offset 0  0 do 250,996 km/h  
RegisteringMemberState  3  ASCII  ASCII  
VehicleRegistrationNumber  1 4  Zob. szczegółowy opis w tabeli 42  
VIN 1 7  ASCII  ASCII  
SealDataVu  5 5  Zob. szczegółowy opis w tabeli 43  
ByDefaultLoadType  1  Zob. szczegółowy opis w tabeli 44  
VuSerialNumber  8  Zob. szczegółowy opis w tabeli 45  
SensorSerialNumber  8  Zob. szczegółowy opis w tabeli 45  
SensorGNSSSerialNumber  8  Zob. szczegółowy opis w tabeli 45  
RemoteCommunicationModuleSe­
rialNumber  8 Zob. szczegółowy opis w tabeli 45  
TachographCardsGen1Suppression  2  Zob. szczegółowy opis w tabeli 46  
VehiclePosition  1 4  Zob. szczegółowy opis w tabeli 47  
CalibrationCountry  3  ASCII  NationAlpha zgodnie z definicją 
w dodatku 1  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 388  
CPR_075 W tabeli 40 zamieszczono szczegółowy opis formatów 
poszczególnych bajtów parametru TimeDate:  
Tabela 40  
Szczegółowy opis formatu TimeDate (warto ść recordDataIdentifier # F90B)  
Bajt Definicja parametru  Rozdzielczość  Zakres roboczy  
1 Sekundy  wzmocnienie 0,25 s/bit, offset 0 s  0 do 59,75s  
2 Minuty  wzmocnienie 1 minuta/bit, offset 0 minut  0 do 59 minut  
3 Godziny  wzmocnienie 1 h/bit, offset 0 h  0 do 23 h  
4 Miesiąc  wzmocnienie 1 miesiąc/bit, offset 0 miesięcy  1 do 12 miesięcy  
5 Dzień  wzmocnienie 0,25 dnia/bit, offset 0 dni (zob. 
UWAGA pod tabelą 41)  0,25 do 31,75 dnia  
6 Rok  wzmocnienie 1 rok/bit, offset rok +1985 
(zob. UWAGA pod tabelą 41)  lata od 1985 do 2235  
7 lokalne przesunięcie dla 
minut  wzmocnienie 1 minuta/bit, offset -125 minut  -59 do +59 minut  
8 lokalne przesunięcie dla 
godzin  wzmocnienie 1 h/bit, offset -125 h  -23 do +23 h  
CPR_076 W tabeli 41 zamieszczono szczegółowy opis formatów 
poszczególnych bajtów parametru NextCalibrationDate:  
Tabela 41  
Szczegółowy opis formatu NextCalibrationDate (warto ść recordDataIdentifier # F922)  
Bajt Definicja parametru  Rozdzielczość  Zakres roboczy  
1 Miesiąc  wzmocnienie 1 miesiąc/bit, offset 0 miesięcy  1 do 12 miesięcy  
2 Dzień  wzmocnienie 0,25 dnia/bit, offset 0 dni (zob. 
UWAGA poniżej)  0,25 do 31,75 dnia  
3 Rok  wzmocnienie 1 rok/bit, offset rok +1985 
(zob. UWAGA poniżej)  lata od 1985 do 2235  
UWAGA dotycząca zastosowania parametru „dzień”:  
1) Wartość 0 dla daty nie istnieje. Wartości 1, 2, 3 i 4 są 
stosowane do oznaczenia pierwszego dnia miesiąca, 5, 
6, 7 i 8 – do oznaczenia drugiego dnia miesiąca, itd.  
2) Ten parametr nie ma wpływu na parametr „godzina” ani 
go nie zmienia.  
UWAGA dotycząca zastosowania parametru „rok”:  
Wartość 0 dla roku oznacza rok 1985, wartość 1 oznacza 
rok 1986, itd.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 389  
CPR_078 W tabeli 42 zamieszczono szczegółowy opis formatów 
poszczególnych bajtów parametru VehicleRegistration­
Number:  
Tabela 42  
Szczegółowy opis formatu VehicleRegistrationNumber (warto ść recordDataIdentifier # F97E)  
Bajt Definicja parametru  Rozdzielczość  Zakres roboczy  
1 Strona kodowa (zdefiniowana w dodatku 1)  nie dotyczy  VehicleRegistrationNumber  
2 – 14  Numer rejestracyjny pojazdu (zdefiniowany 
w dodatku 1)  nie dotyczy  VehicleRegistrationNumber  
CPR_090 W tabeli 43 zamieszczono szczegółowy opis formatów 
poszczególnych bajtów parametru SealDataVu:  
Tabela 43  
Szczegółowy opis formatu SealDataVu (warto ść recordDataIdentifier # F9D3)  
Bajt Definicja parametru  Rozdzielczość  Zakres roboczy  
1 – 11  sealRecord1. Format SealRecord zdefinio­
wany w dodatku 1.  nie dotyczy  SealRecord  
12 - 22  sealRecord2. Format SealRecord zdefinio­
wany w dodatku 1.  nie dotyczy  SealRecord  
23 – 33  sealRecord3. Format SealRecord zdefinio­
wany w dodatku 1.  nie dotyczy  SealRecord  
34 – 44  sealRecord4. Format SealRecord zdefinio­
wany w dodatku 1.  nie dotyczy  SealRecord  
45 – 55  sealRecord5. Format SealRecord zdefinio­
wany w dodatku 1.  nie dotyczy  SealRecord  
UWAGA:  W przypadku gdy dostępnych jest mniej niż 5 plomb 
wartość EquipmentType we wszystkich niewykorzystanych 
sealRecords należy ustawić na 15, tj. niewykorzystane.  
CPR_091 W tabeli 44 zamieszczono szczegółowy opis formatów 
poszczególnych bajtów parametru ByDefaultLoadType:  
Tabela 44  
Szczegółowy opis formatu ByDefaultLoadType (warto ść recordDataIdentifier # F9D5)  
Bajt Definicja parametru  Rozdzielczość  Zakres roboczy  
1 loadType 
'00'H: nieokreślony typ załadunku 
'01'H: towary 
'02'H: pasażerowie  nie dotyczy  '00'H do '02'H  
CPR_092 W tabeli 45 zamieszczono szczegółowy opis formatów 
poszczególnych bajtów parametrów VuSerialNumber, 
SensorSerialNumber, SensorGNSSSerialNumber oraz 
RemoteCommunicationModuleSerialNumber:  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 390  
Tabela 45  
Szczegółowy opis formatu VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber oraz 
RemoteCommunicationModuleSerialNumber (warto ści recordDataIdentifier # F9D4, F9D0, F9D2, F9D1)  
Bajt Definicja parametru  Rozdzielczość  Zakres roboczy  
1 VuSerialNumber, SensorSerialNumber, Sensor 
GNSSSerialNumber and RemoteCommunica­
tionModuleSerialNumber: 
Format ExtendedSerialNumber zdefiniowany 
w dodatku 1.  nie dotyczy  ExtendedSerialNumber  
CPR_093 W tabeli 46 zamieszczono szczegółowy opis formatów 
poszczególnych bajtów parametru TachographCar­
dsGen1Suppression:  
Tabela 46  
Szczegółowy opis formatu TachographCardsGen1Suppression (warto ść recordDataIdentifier # F9D6)  
Bajt Definicja parametru  Rozdzielczość  Zakres roboczy  
1-2 TachographCardsGen1Suppression. Format 
TachographCardsGen1Suppression zdefinio­
wany w dodatku 1.  nie dotyczy  '0000'H, 'A5E3'H  
CPR_094 W tabeli 47 zamieszczono szczegółowy opis formatów 
poszczególnych bajtów parametru VehiclePosition:  
Tabela 47  
Szczegółowy opis formatu VehiclePosition (warto ść recordDataIdentifier # F9D7)  
Bajt Definicja parametru  Rozdzielczość  Zakres roboczy  
1 - 4  Określono znacznik czasu pozycji pojazdu.  nie dotyczy  TimeReal  
5 Dokładność GNSS  nie dotyczy  GNSSAccuracy  
6 - 11  Pozycja pojazdu  nie dotyczy  GeoCoordinates  
12 Status uwierzytelnienia  nie dotyczy  PositionAuthenticationStatus  
13 Bieżący kraj  nie dotyczy  NationNumeric  
14 Bieżący region  nie dotyczy  RegionNumeric  
Uwaga : po aktualizacji pozycji pojazdu aktualizacja bieżą­
cego kraju i regionu może zostać opóźniona.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 391  
Dodatek 9  
HOMOLOGACJA TYPU WYKAZ MINIMUM WYMAGANYCH BADA Ń 
SPIS TREŚCI  
1. WPROWADZENIE  
2. BADANIA FUNKCJONALNOŚCI PRZYRZĄDU REJESTRUJĄCEGO  
3. BADANIA FUNKCJONALNOŚCI CZUJNIKA RUCHU  
4. BADANIA FUNKCJONALNOŚCI KART DO TACHOGRAFU  
5. BADANIA URZĄDZENIA ZEWNĘTRZNEGO GNSS  
▼M1 
6. BADANIA ZEWNĘTRZNEGO URZĄDZENIA DO ŁĄCZNOŚCI NA 
ODLEGŁOŚĆ  
▼B 
7. BADANIA FUNKCJONALNOŚCI PAPIERU  
8. BADANIA INTEROPERACYJNOŚCI  
▼M3 
9. BADANIA OSNMA  
▼B 
1. WPROWADZENIE  
1.1. Homologacja typu  
Homologacja typu WE urządzenia rejestrującego (lub elementu skł ado­
wego) lub karty do tachografu opiera się na następujących dokum entach:  
▼M1 
— świadectwie bezpiecze ństwa , opartym na specyfikacjach normy 
„Common Criteria”, w odniesieniu do celu bezpieczeństwa w pełni  zgod­
nego z celami przedstawionymi w dodatku 10 do niniejszego załąc znika,  
▼B 
— świadectwie funkcjonalno ści wystawionym przez organ państwa człon­
kowskiego i zaświadczającym, że badany element spełnia wymogi o kre­ 
ślone w niniejszym załączniku pod względem wykonywanych funkcji , 
dokładności pomiarów i charakterystyki środowiskowej,  
— świadectwie interoperacyjno ści wystawionym przez właściwy organ 
i zaświadczającym, że urządzenie rejestrujące (lub karta do tac hografu) 
jest w pełni interoperacyjne z wymaganymi typami kart do tachog rafu 
(lub urządzenia rejestrującego) (zob. rozdział 8 niniejszego za łącz­
nika).  
W niniejszym dodatku określa się, które badania, jako minimum, musi 
przeprowadzić organ państwa członkowskiego w ramach badań funkc jo­
nalności, i które badania, jako minimum, musi przeprowadzić wła ściwy 
organ w ramach badań interoperacyjności. Nie określa się dokład nie 
procedur przeprowadzania tych badań ani ich rodzajów.  
Niniejszy dodatek nie obejmuje aspektów świadectwa bezpieczeńst wa. 
Jeżeli niektóre badania wymagane na potrzeby homologacji typu p rzepro­
wadza się przy ocenie bezpieczeństwa i w ramach procesu certyfi kacji, to 
nie trzeba ich przeprowadzać ponownie. W takim przypadku można 
poddać kontroli tylko wyniki takich badań bezpieczeństwa. Do ce lów 
informacyjnych wymogi, które mają zostać poddane badaniom (lub ściśle 
wiążą się z badaniami, które mają zostać przeprowadzone) w rama ch 
certyfikacji bezpieczeństwa, są w niniejszym dodatku oznaczone 
symbolem „*”.  
Ponumerowane wymogi odnoszą się do tekstu głównego załącznika, nato­
miast pozostałe wymogi odnoszą się do innych dodatków (np. PIC_ 001 
odnosi się do wymogu PIC_001 zawartego w dodatku 3 Piktogramy).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 392  
W niniejszym dodatku oddzielnie przedstawiono informacje na tem at 
homologacji typu czujnika ruchu, przyrządu rejestrującego oraz urządzenia 
zewnętrznego GNSS jako elementów składowych urządzenia rejestru ją­
cego. Każdy element składowy uzyska oddzielne świadectwo homolo gacji 
typu, w którym wskazane zostaną pozostałe kompatybilne elementy  s kł a ­
dowe. Badanie funkcjonalności czujnika ruchu (lub urządzenia ze wnętrz­
nego GNSS) wykonuje się wraz z badaniem funkcjonalności przyrzą du 
rejestrującego i odwrotnie.  
Nie wymaga się zapewnienia interoperacyjności między każdym mod elem 
czujnika ruchu (lub urządzenia zewnętrznego GNSS) i każdym mode lem 
przyrządu rejestrującego. W takim przypadku homologacja typu cz ujnika 
ruchu (lub odpowiednio urządzenia zewnętrznego GNSS) może być 
wydana tylko w połączeniu z homologacją typu właściwego przyrzą du 
rejestrującego i odwrotnie.  
▼M3 
Organ państwa członkowskiego odpowiedzialny za badania funkcjon al­
ności przyrządu rejestrującego lub urządzenia zewnętrznego GNSS  musi 
upewnić się, że wbudowany odbiornik GNSS przeszedł pomyślnie ba dania 
OSNMA określone w niniejszym dodatku. Badania te uznaje się za część 
badań funkcjonalności przyrządu rejestrującego lub urządzenia z ewnętrz­
nego GNSS.  
▼B 
1.2. Odniesienia  
W niniejszym dodatku używa się następujących odniesień:  
IEC 60068-2-1: Badania środowiskowe – Część 2-1: Próby – Próba A: 
Zimno  
IEC 60068-2-2: Podstawowe procedury badań środowiskowych – Częś ć 2: 
Próby – Próba B: Suche gorąco (harmoniczne).  
IEC 60068-2-6: Badania środowiskowe – Część 2: Próby – Próba Fc : 
Wibracje  
IEC 60068-2-14: Badania środowiskowe – Część 2-14: Próby – Prób a N: 
Zmiany temperatury  
IEC 60068-2-27: Badania środowiskowe – Część 2: Próby – Próba E a 
i wytyczne: Udary  
IEC 60068-2-30: Badania środowiskowe – Część 2-30: Próby – Prób a Db: 
Wilgotne gorąco, cykliczne (cykl 12+12 h)  
IEC 60068-2-64: Badania środowiskowe – Część 2-64: Próby – Prób a Fh: 
Wibracje szerokopasmowe losowe i wytyczne  
IEC 60068-2-78: Badania środowiskowe – Część 2-78: Próby – Prób a 
Cab: Wilgotne gorąco stałe  
ISO 16750-3 – Obciążenia mechaniczne (2012-12)  
ISO 16750-4 – Obciążenia klimatyczne (2010-04)  
ISO 20653: Pojazdy drogowe – Stopień ochrony (kod IP) – Ochrona  
urządzeń elektrycznych przed ciałami obcymi, wodą i dostępem  
ISO 10605:2008 + Sprostowanie techniczne:2010 + AMD1:2014 Pojaz dy 
drogowe – Metody badań zakłóceń elektrycznych powodowanych prze z 
wyładowania elektrostatyczne  
ISO 7637-1:2002 + AMD1:2008 Pojazdy drogowe – Zakłócenia elek­
tryczne przenoszone przez przewodzenie i przez sprzężenie – Czę ść 1: 
Definicje i postanowienia ogólne  
ISO 7637-2 Pojazdy drogowe – Zakłócenia elektryczne przenoszone  przez 
przewodzenie i przez sprzężenie – Część 2: Przewodzenie przebie gów 
przejściowych wyłącznie wzdłuż przewodów zasilających  
ISO 7637-3 Pojazdy drogowe – Zakłócenia elektryczne przenoszone  przez 
przewodzenie i przez sprzężenie – Część 3: Przenoszenie elektry cznych 
przebiegów przejściowych przez sprzężenia pojemnościowe i induk cyjne 
przez linie inne niż linie zasilające  
ISO/IEC 7816-1 Karty identyfikacyjne – Karty elektroniczne – Cz ęść 1: 
Karty stykowe – Charakterystyki fizyczne  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 393  
ISO/IEC 7816-2 Technologia informacyjna – Karty identyfikacyjne  –  
Karty elektroniczne – Część 2: Karty stykowe – Wymiary i rozmie szczenie 
styków  
ISO/IEC 7816-3 Technologia informacyjna – Karty identyfikacyjne  –  
Karty elektroniczne – Część 3: Karty Stykowe – Sygnały elektryc zne 
i protokoły transmisji  
ISO/IEC 10373-1:2006 + AMD1:2012 Karty identyfikacyjne – Metody  
badań – Część 1: Charakterystyki ogólne  
ISO/IEC 10373-3:2010 + Sprostowanie techniczne: 2013 Karty iden tyfi­
kacyjne – Metody badań – Część 3: Karty elektroniczne i powiąza ne 
z nimi urządzenia interfejsowe  
ISO 16844-3:2004, Sprostowanie 1: 2006 Pojazdy drogowe – System y 
tachograficzne – Część 3: Interfejs czujnika ruchu (z przyrząda mi rejes­
trującymi)  
ISO 16844-4 Pojazdy drogowe – Systemy tachograficzne – Część 4:  
Interfejs CAN  
ISO 16844-6 Pojazdy drogowe – Systemy tachograficzne – Część 6:  
Diagnostyka  
ISO 16844-7 Pojazdy drogowe – Systemy tachograficzne – Część 7:  
Parametry  
ISO 534 Papier i tektura – Oznaczanie grubości, gęstości pozorn ej i obję­
tości właściwej  
▼M3 
RGODP Sprawozdanie techniczne JRC – Receiver guidelines for OSN MA 
data processing (Wytyczne dla odbiorników w zakresie przetwarza nia 
danych OSNMA)  
▼B 
EKG ONZ R10 Jednolite przepisy dotyczące homologacji pojazdów 
w odniesieniu do kompatybilności elektromagnetycznej (Europejsk a 
Komisja Gospodarcza ONZ)  
2. BADANIA FUNKCJONALNOŚCI PRZYRZĄDU REJESTRUJĄCEGO  
▼M1 
Nr Badanie  Opis  Powiązane wymogi  
1. Badanie administracyjne  
1.1 Dokumentacja  Prawidłowość dokumentacji  
1.2 Wyniki badań produ­
centa  Wyniki badań producenta przeprowadzonych 
podczas integracji. 
Przedstawienie dokumentów papierowych.  88, 89,91  
2. Kontrola wizualna  
2.1 Zgodność z dokumentacją  
2.2 Identyfikacja/oznakowanie  224–226  
2.3 Materiały  219–223  
2.4 Plombowanie  398, 401–405  
2.5 Interfejsy zewnętrzne  
3. Badania funkcjonalno ści ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 394  
Nr Badanie  Opis  Powiązane wymogi  
▼M3 
3.1 Obsługiwane funkcje  02, 03, 04, 05, 07, 382,  
3.2 Tryby pracy  09 do 11*, 134, 135  
3.3 Prawa dostępu do funkcji i danych  12*, 13*, 382, 383, 386 do 389  
3.4 Monitorowanie wkładania i wyjmowania kart  15, 16, 17, 18, 19*, 20*, 134  
3.5 Pomiar prędkości, pozycji i odległości  21 do 37  
3.6 Pomiar czasu (badanie przeprowadzone w temperaturze 20 °C)  38 do 43  
3.7 Monitorowanie czynności kierowcy  44 do 53, 134  
3.8 Monitorowanie stanu prowadzenia pojazdu  54, 55, 134  
3.9 Dane wprowadzane przez kierowców  56 do 62c  
3.10 Zarządzanie blokadami firmowymi  63 do 68  
3.11 Monitorowanie czynności kontrolnych  69, 70  
3.12 Wykrywanie zdarzeń lub usterek  71 do 88a, 134  
3.13 Dane identyfikujące sprzęt  93*, 94*, 97, 100  
3.14 Dane rejestrowane przy wkładaniu i wyjmowaniu karty kierowcy l ub 
warsztatowej  102* do 104*  
3.15 Dane dotyczące czynności kierowcy  105* do 107*  
3.16 Dane dotyczące miejsc i pozycji  108* do 112*  
3.17 Dane dotyczące licznika kilometrów  113* do 115*  
3.18 Dane szczegółowe dotyczące prędkości  116*  
3.19 Dane dotyczące zdarzeń  117*  
3.20 Dane dotyczące usterek  118*  
3.21 Dane dotyczące kalibracji  119* do 121*  
3.22 Dane dotyczące korekty czasu  124*, 125*  
3.23 Dane dotyczące czynności kontrolnych  126*, 127*  
3.24 Dane dotyczące blokad firmowych  128*  
3.25 Dane dotyczące czynności pobierania  129*  
3.26 Dane dotyczące stanów szczególnych  130*, 131*  
3.27 Dane karty do tachografu  132*, 133*  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 395  
Nr Badanie  Opis  Powiązane wymogi  
3.28 Przekroczenia granicy  133a* do 133d*  
3.29 Operacja załadunku/rozładunku  133e* do 133i*  
3.30 Mapa cyfrowa  133j* do 133t*  
3.31 Rejestrowanie i przechowywanie danych na kartach do tachografó w 136, 137, 138*, 139*, 141*, 
142, 143 
144, 145, 146*, 147*, 147a*, 
147b*, 148*, 149, 150, 150a  
3.32 Wyświetlanie  90, 134, 
151 do 168, 
PIC_001, DIS_001  
3.33 Drukowanie  90, 134, 
169 do 181, PIC_001, 
PRT_001 do PRT_014  
3.34 Ostrzeganie  134, 182 do 191, 
PIC_001  
3.35 Pobieranie danych na nośnik zewnętrzny  90, 134, 192 do 196  
3.36 Łączność na odległość na potrzeby ukierunkowanych kontroli dro go­
wych  197 do 199  
3.37 Wymiana danych z dodatkowymi urządzeniami zewnętrznymi  200, 201  
3.38 Kalibracja  202 do 206*, 383, 384, 386 
do 391  
3.39 Drogowe kontrole kalibracji  207 do 209  
3.40 Korekta czasu  210 do 212*  
3.41 Monitorowanie przekroczeń granicy  226a do 226c  
3.42 Aktualizacja oprogramowania  226d do 226f  
3.43 Niezakłócanie funkcji dodatkowych  06, 425  
3.44 Interfejs czujnika ruchu  02, 122  
3.45 Urządzenie zewnętrzne GNSS  03, 123  
3.46 Sprawdzenie, czy VU wykrywa, rejestruje i zapisuje zdarzenie 
(zdarzenia) lub usterkę (usterki) określone przez producenta VU , gdy 
sparowany czujnik ruchu reaguje na pola magnetyczne zaburzające  
wykrywanie ruchu pojazdu.  217 
3.47 Pakiet szyfrów i standardowe parametry domeny  CSM_48, CSM_50  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 396  
Nr Badanie  Opis  Powiązane wymogi  
4. Badania środowiskowe  
4.1 Temperatura  Sprawdzenie funkcjonalności za pomocą: 
badania zgodnie z normą ISO 16750-4, 
rozdział 5.1.1.2: Próba eksploatacyjna 
w niskiej temperaturze (72 h w temperaturze 
-20 °C). 
Badanie to odnosi się do normy IEC 60068-2- 
1: Badania środowiskowe – Część 2-1: Próby 
– Próba A: Zimno 
badania zgodnie z normą ISO 16750-4: 
Rozdział 5.1.2.2: Próba eksploatacyjna 
w wysokiej temperaturze (72 h w tempera­
turze 70 °C). 
Badanie to odnosi się do normy IEC 60068-2- 
2: Podstawowe procedury badań środowisko­
wych – Część 2: Próby – Próba B: Suche 
gorąco; 
badania zgodnie z normą ISO 16750-4: 
Rozdział 5.3.2: Nagła zmiana temperatury 
z określonym okresem przejściowym (-20 °C 
/ 70 °C, 20 cykli, czas przebywania: 2 h 
w każdej temperaturze). 
Można przeprowadzić skrócony zestaw badań 
(spośród tych zdefiniowanych w sekcji 3 
niniejszej tabeli) w niższej temperaturze, 
wyższej temperaturze i w czasie cykli 
temperaturowych.  213 
4.2 Wilgotność  Sprawdzenie odporności przyrządu rejestrują­
cego na cykliczne zmiany wilgotności (próba 
gorąca) za pomocą próby wg normy IEC 
60068-2-30, w sześciu 24-godzinnych 
cyklach, w każdym ze zmieniającą się tempe­
raturą od +25 °C do +55 °C i wilgotnością 
względną 97 % w temperaturze +25 °C 
i 93 % w temperaturze +55 °C  214 
4.3 M/echanika  1. Drgania harmoniczne: 
sprawdzenie odporności przyrządu rejes­
trującego na drgania harmoniczne o nastę­
pujących właściwościach: 
stałe przemieszczenie przy częstotliwości 
5–11 Hz: 10-milimetrowa amplituda; 
stałe przyspieszenie przy częstotliwości 
11–300 Hz: 5g. 
Wymóg ten sprawdza się za pomocą próby 
Fc wg normy IEC 60068-2-6, z mini­
malnym czasem trwania próby 3 × 12 h 
(12 h na oś). 
ISO 16750-3 nie wymaga przeprowadzenia 
badania drgań harmonicznych w przypadku 
urządzeń znajdujących się w oddzielnej 
kabinie pojazdu. 
2. Drgania swobodne: 
Próba zgodnie z normą ISO 16750-3: 
Rozdział 4.1.2.8: Próba VIII: Pojazd użyt­
kowy, oddzielna kabina pojazdu.  219 ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 397  
Nr Badanie  Opis  Powiązane wymogi  
Próba drgań swobodnych: 10...2000 Hz, 
wertykalna średnia kwadratowa 21,3 m/s  2 , 
wzdłużna średnia kwadratowa 11,8 m/s  2 , 
poprzeczna średnia kwadratowa 13,1 m/s  2 , 3 
osie, 32 h na oś, w tym cykl temperaturowy 
-20...70 °C. 
Badanie to odnosi się do normy IEC 60068-2- 
64: Badania środowiskowe – Część 2-64: 
Próby – Próba Fh: Wibracje szerokopasmowe 
losowe i wytyczne 
3. Udary: 
udar mechaniczny przy impulsie półsinu­
soidalnym 3 g wg normy ISO 16750. 
Opisane powyżej badania przeprowadza się 
na różnych próbkach urządzeń poddawanych 
badaniom.  
4.4 Ochrona przed wodą 
i ciałami obcymi  Badanie zgodnie z normą ISO 20653: 
Pojazdy drogowe – Stopień ochrony (kod 
IP) – Ochrona urządzeń elektrycznych przed 
ciałami obcymi, wodą i dostępem (bez zmian 
parametrów); minimalna wartość IP – 40  220, 221  
4.5 Zabezpieczenie nadna­
pięciowe  Sprawdzenie odporności przyrządu rejestrują­
cego na napięcie zasilania: 
wersje 24 V: 34 V przy +40 °C przez 
1 godzinę 
wersje 12 V: 17 V przy +40 °C przez 
1 godzinę 
(ISO 16750-2)  216 
4.6 Zabezpieczenie przed 
odwróceniem polary­
zacji  Sprawdzenie odporności przyrządu rejestrują­
cego na odwrócenie biegunów napięcia zasi­
lającego. 
(ISO 16750-2)  216 
4.7 Zabezpieczenie zwar­
ciowe  Sprawdzenie, czy sygnały wyjściowe są 
zabezpieczone przed zwarciem do napięcia 
zasilającego i do masy. 
(ISO 16750-2)  216 
5. Badania EMC  
5.1 Emisje radiacyjne 
i wrażliwość na radiację  Zgodność z regulaminem nr 10 EKG ONZ  218  
5.2 Wyładowania elektro­
statyczne  Zgodność z normą ISO 10605:2008 + 
Sprostowanie techniczne:2010 + 
AMD1:2014: +/- 4kV w przypadku styku 
i +/- 8kV w przypadku rozładowania do 
powietrza  218 ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 398  
Nr Badanie  Opis  Powiązane wymogi  
5.3 Wrażliwość na stany 
nieustalone w zasilaniu  W przypadku wersji 24 V: zgodność z normą 
ISO 7637-2 i wersją 3 regulaminu nr 10 EKG 
ONZ: 
impuls 1a: Vs = -450 V, Ri = 50 omów 
impuls 2a: Vs = +37 V, Ri = 2 omy 
impuls 2b: Vs = +20 V, Ri = 0,05 oma 
impuls 3a: Vs = -150 V, Ri = 50 omów 
impuls 3b: Vs = +150 V, Ri = 50 omów 
impuls 4: Vs = -16 V Va = -12V, t6 = 100ms 
impuls 5: Vs = +120 V, Ri = 2,2 oma, td = 
250 ms 
W przypadku wersji 12V: zgodność z normą 
ISO 7637-1 i wersją 3 regulaminu nr 10 EKG 
ONZ: 
impuls 1: Vs = -75 V, Ri = 10 omów 
impuls 2a: Vs = +37 V, Ri = 2 omy 
impuls 2b: Vs = +10 V, Ri = 0,05 oma 
impuls 3a: Vs = -112 V, Ri = 50 omów 
impuls 3b: Vs = +75 V, Ri = 50 omów 
impuls 4: Vs = -6 V, Va = -5 V, t6 = 15 ms 
impuls 5: Vs = +65 V, Ri = 3 omy, td = 100 
ms 
Impuls 5 należy testować tylko w przypadku 
przyrządów rejestrujących przeznaczonych do 
zainstalowania w pojazdach, w których nie 
zainstalowano zewnętrznego, wspólnego 
zabezpieczenia przed spadkiem obciążenia. 
Aby uzyskać informacje na temat propozycji 
zabezpieczenia przed spadkiem obciążenia, 
zob. norma ISO 16750-2 wydanie 4, rozdział 
4.6.4.  218 
▼B 
3. BADANIA FUNKCJONALNOŚCI CZUJNIKA RUCHU  
Nr Badanie  Opis  Powiązane wymogi  
1. Badanie administracyjne  
1.1 Dokumentacja  Prawidłowość dokumentacji  
2. Kontrola wizualna  
2.1 Zgodność z dokumentacją  
2.2 Identyfikacja/oznakowanie  225, 226,  
2.3 Materiały  219–223  
2.4 Plombowanie  398, 401–405  
3. Badania funkcjonalno ści 
3.1 Dane identyfikacyjne czujnika  95–97*  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 399  
Nr Badanie  Opis  Powiązane wymogi  
3.2 Parowanie czujnik ruchu — przyrząd rejestrujący  122*, 204  
3.3 Wykrywanie ruchu 
Dokładność pomiaru ruchu  30–35  
3.4 Interfejs przyrządu rejestrującego  0 2  
3.5 Sprawdzenie, czy działanie stałego pola magnetycznego nie wpły wa na czujnik 
ruchu. Ewentualnie sprawdzenie, czy czujnik ruchu reaguje na dz iałanie stałych 
pól magnetycznych zaburzających wykrywanie ruchu pojazdu, tak a by podłą­
czony VU mógł wykrywać, rejestrować i zapisywać usterki czujnik a. 217 
4. Badania środowiskowe  
4.1 Temperatura pracy  Sprawdzenie funkcjonalności (zdefiniowanej 
w ramach badania nr 3.3) w zakresie temperatur 
[– 40 – + 135 °C] za pomocą: 
próby Ad wg normy IEC 60068-2-1, z czasem 
trwania badania 96 h w najniższej temperaturze 
To min , 
próby Bd wg normy IEC 60068-2-2, z czasem 
trwania badania 96 h w najwyższej tempera­
turze To  max , 
badania zgodnie z normą ISO 16750-4: 
Rozdział 5.1.1.2: Próba eksploatacyjna w niskiej 
temperaturze (24 h w temperaturze – 40 °C). 
Badanie to odnosi się do normy IEC 60068-2-1: 
Badania środowiskowe – Część 2-1: Próby – 
Próba A: Zimno, wg próby Bd w ramach 
normy IEC 68-2-2, z czasem trwania 96 h 
w najniższej temperaturze – 40 °C 
badania zgodnie z normą ISO 16750-4: 
Rozdział 5.1.2.2: Próba eksploatacyjna w niskiej 
temperaturze (96 h w temperaturze 135 °C). 
Badanie to odnosi się do normy IEC 60068-2-2: 
Podstawowe procedury badań środowiskowych 
– Część 2: Próby – Próba B: Suche gorąco;  213 
4.2 Cykle temperaturowe  Badanie zgodnie z normą ISO 16750-4: 
Rozdział 5.3.2: Nagła zmiana temperatury 
z określonym okresem przejściowym (– 40 
°C/135 °C, 20 cykli, czas przebywania: 30 min 
w każdej temperaturze). 
IEC 60068-2-14: Badania środowiskowe – 
Część 2-14: Próby – Próba N: Zmiany tempe­
ratury  213 
4.3 Cykle wilgotności  Sprawdzenie funkcjonalności (zdefiniowanej 
w ramach badania nr 3.3) za pomocą próby 
Db wg normy IEC 60068-2-30, w sześciu 24- 
godzinnych cyklach, w każdym ze zmieniającą 
się temperaturą od + 25 °C do + 55 °C i wilgot­
nością względną 97 % w + 25 °C i 93 % 
w + 55 °C  214 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 400  
Nr Badanie  Opis  Powiązane wymogi  
4.4 Drgania  ISO 16750-3: Rozdział 4.1.2.6: Próba IV: 
Pojazd użytkowy, silnik, skrzynia biegów 
Badanie drgań w trybie mieszanym obejmujące: 
a) badanie drgań harmonicznych, 20…520 Hz, 
11,4 … 120 m/s  2 , <= 0,5 oct/min 
b) badanie drgań swobodnych, 10 … 2 000 Hz, 
średnia kwadratowa 177 m/s  2 , 
94 h na oś, z cyklem temperaturowym 
-20…70 °C). 
Badanie to odnosi się do normy IEC 60068-2- 
80: Badania środowiskowe – Część 2-80: Próby 
– Próba Fi: Wibracje – tryb mieszany  219 
4.5 Udar mechaniczny  ISO 16750-3: Rozdział 4.2.3: Próba IV: Próba 
dla urządzeń znajdujących się w skrzyni biegów 
lub na skrzyni biegów 
Udar o impulsie półsinusoidalnym, przyspie­
szenie do uzgodnienia w zakresie 3 000 … 
15 000 m/s  2 , czas trwania impulsu do uzgod­
nienia, ale < 1 ms, liczba wstrząsów: do uzgod­
nienia. 
Badanie to odnosi się do normy IEC 60068-2- 
27: Badania środowiskowe – Część 2: Próby – 
Próba Ea i wytyczne: Udary  219 
4.6 Ochrona przed wodą i ciałami 
obcymi  Badanie zgodnie z normą ISO 20653: Pojazdy 
drogowe – Stopień ochrony (kod IP) – Ochrona 
urządzeń elektrycznych przed ciałami obcymi, 
wodą i dostępem 
(docelowa wartość IP – 64)  220, 221  
4.7 Zabezpieczenie przed odwró­
ceniem polaryzacji  Sprawdzenie odporności czujnika ruchu na 
odwrócenie biegunów napięcia zasilającego.  216 
4.8 Zabezpieczenie zwarciowe  Sprawdzenie, czy sygnały wyjściowe są zabez­
pieczone przed zwarciem do napięcia zasilają­
cego i do masy.  216 
5. Badania kompatybilno ści elektromagnetycznej  
5.1 Emisje radiacyjne i wrażli­
wość na radiację  Sprawdzenie zgodności z regulaminem nr 10 
EKG ONZ  218 
5.2 Wyładowania elektrosta­
tyczne  Zgodność z normą ISO 10605:2008 + Sprosto­
wanie techniczne:2010 + AMD1:2014: +/– 4kV 
w przypadku styku i +/– 8kV w przypadku 
rozładowania do powietrza  218 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 401  
Nr Badanie  Opis  Powiązane wymogi  
5.3 Wrażliwość na stany nieusta­
lone na liniach danych  W przypadku wersji 24 V: zgodność z normą 
ISO 7637-2 i wersją 3 regulaminu nr 10 EKG 
ONZ: 
impuls 1a: Vs = – 450 V, Ri = 50 omów 
impuls 2a: Vs = + 37 V, Ri = 2 omy 
impuls 2b: Vs = + 20 V, Ri = 0,05 oma 
impuls 3a: Vs = – 150 V, Ri = 50 omów 
impuls 3b: Vs = + 150 V, Ri = 50 omów 
impuls 4: Vs = – 16 V Va = – 12V, t6 = 100ms 
impuls 5: Vs = + 120 V, Ri = 2,2 oma, td = 
250 ms 
W przypadku wersji 12 V: zgodność z normą 
ISO 7637-1 i wersją 3 regulaminu nr 10 EKG 
ONZ: 
impuls 1: Vs = – 75 V, Ri = 10 omów 
impuls 2a: Vs = + 37 V, Ri = 2 omy 
impuls 2b: Vs = + 10 V, Ri = 0,05 oma 
impuls 3a: Vs = – 112 V, Ri = 50 omów 
impuls 3b: Vs = + 75 V, Ri = 50 omów 
impuls 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms 
impuls 5: Vs = + 65 V, Ri = 3 omy, td = 
100 ms 
Impuls 5 należy testować tylko w przypadku 
przyrządów rejestrujących przeznaczonych do 
zainstalowania w pojazdach, w których nie 
zainstalowano zewnętrznego, wspólnego zabez­
pieczenia przed spadkiem obciążenia. 
Aby uzyskać informacje na temat propozycji 
zabezpieczenia przed spadkiem obciążenia, 
zob. norma ISO 16750-2 wydanie 4. rozdział 
4.6.4.  218 
4. BADANIA FUNKCJONALNOŚCI KART DO TACHOGRAFU  
Badania zgodnie z niniejszą sekcją 4  
nr 5 „Testy protokołów”,  
nr 6 „Struktura karty” i  
nr 7 „Badania funkcjonalności”  
może przeprowadzić jednostka dokonująca oceny lub jednostka cer tyfiku­
jąca w trakcie procesu wydawania świadectwa bezpieczeństwa dla modułu 
chipowego zgodnie z normą „Common Criteria” (CC).  
Badania nr 2.3 i 4.2 są identyczne. Są to próby mechaniczne kom binacji 
karty i modułu chipowego. Jeżeli jeden z tych elementów (karta,  moduł 
chipowy) zostanie zmieniony, wówczas przeprowadzenie tych badań  jest 
konieczne.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 402  
Nr Badanie  Opis  Powiązane wymogi  
1. Badanie administracyjne  
1.1 Dokumentacja  Prawidłowość dokumentacji  
2 Karta  
2.1 Nadruk  Sprawdzenie, czy wszystkie zabezpieczenia 
i widoczne dane są prawidłowo nadrukowane 
i zgodne z wymogami. 
[Oznaczenie] 
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 227) 
Na awersie znajdują się: 
wyrażenia „Karta kierowcy”, „Karta kontrolna”, 
„Karta warsztatowa”, lub „Karta firmowa” nadruko­
wane wielkimi literami w języku urzędowym lub 
językach urzędowych państwa członkowskiego 
wydającego kartę, zgodnie z typem karty. 
[Nazwa państwa członkowskiego] 
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 228) 
Na awersie znajdują się: 
nazwa państwa członkowskiego wydającego kartę 
(nieobowiązkowo). 
[Znak] 
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 229) 
Na awersie znajdują się: 
wyróżniający znak państwa członkowskiego wydają- 
cego kartę, drukowany w negatywie w niebieskim 
prostokącie i otoczony 12 żółtymi gwiazdkami. 
[Oznaczenie liczby] 
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 232) 
Na awersie znajdują się: 
objaśnienia numerowanych pozycji znajdujących się 
na awersie karty. 
[Kolor] 
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 234) 
Karty do tachografu drukuje się w następujących 
dominujących kolorach tła: 
— karta kierowcy: biały, 
— karta warsztatowa: czerwony, 
— karta kontrolna: niebieski, 
— karta firmowa: żółty.  227–229, 232, 234– 
236 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 403  
Nr Badanie  Opis  Powiązane wymogi  
[Zabezpieczenie] 
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 235) 
Karty do tachografu mają przynajmniej następujące 
zabezpieczenia przed fałszowaniem i manipulowa- 
niem: 
— zabezpieczający wzór tła z drukowanym drobnym 
giloszem i tęczą, 
— przynajmniej dwubarwną linię wykonaną techniką 
mikrodruku. 
[Oznakowania] 
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 236) 
Państwa członkowskie mogą dodawać kolory lub 
oznakowania, takie jak symbole państwowe i zabez- 
pieczenia. 
[Znak homologacji] 
Karta do tachografu jest opatrzona znakiem homo- 
logacji. 
Znak homologacji składa się z: 
— prostokąta, wewnątrz którego jest umieszczona 
litera „e”, po której następuje liczba lub litera 
oznaczająca państwo, które wydało homologację, 
— numeru homologacji typu odpowiadającego nu- 
merowi świadectwa homologacji typu karty do 
tachografu, umieszczonego bezpośrednio obok 
wspomnianego wyżej prostokąta.  
2.2 Próby mechaniczne  
[Wielkość karty] 
Karty do tachografu muszą być zgodne z wymo­
gami normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakte­
rystyki fizyczne, 
[5] Wymiary karty 
[5.1] Wielkość karty 
[5.1.1] Wymiary i tolerancje karty 
Typ karty ID-1 Karta nieużywana 
[Krawędzie karty] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[5] Wymiary karty 
[5.1] Wielkość karty 
[5.1.2] Krawędzie karty  240, 243 
ISO/IEC 7810  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 404  
Nr Badanie  Opis  Powiązane wymogi  
[Struktura karty] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[6] Struktura karty 
[Materiały, z których wykonane są karty] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[7] Materiały, z których wykonane są karty 
[Odporność na zginanie] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[8] Charakterystyki kart 
[8.1] Odporność na zginanie 
[Toksyczność] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[8] Charakterystyki kart 
[8.3] Toksyczność 
[Odporność na działanie czynników chemicznych] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[8] Charakterystyki kart 
[8.4] Odporność na działanie czynników chemicznych 
[Stabilność kart] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[8] Charakterystyki kart 
[8.5] Stabilność wymiarowa kart i odkształcenie 
wywołane przez temperaturę i wilgotność  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 405  
Nr Badanie  Opis  Powiązane wymogi  
[Światło] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[8] Charakterystyki kart 
[8.6.] Światło 
[Trwałość] 
Załącznik 1C rozdział 4.4 „Wymagania środowiskowe 
i elektryczne”, 241) 
Karty do tachografu prawidłowo pracują przez okres 
pięciu lat, jeżeli są używane w określonych warun- 
kach środowiskowych i elektrycznych. 
[Wytrzymałość na rozwarstwienie] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[8] Charakterystyki kart 
[8.8] Wytrzymałość na rozwarstwienie 
[Przyczepność lub blokowanie] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[8] Charakterystyki kart 
[8.9] Przyczepność lub blokowanie 
[Odkształcenie] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[8] Charakterystyki kart 
[8.11] Ogólne odkształcenie kart 
[Odporność na działanie wysokich temperatur] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[8] Charakterystyki kart 
[8.12] Odporność na działanie wysokich temperatur  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 406  
Nr Badanie  Opis  Powiązane wymogi  
[Zniekształcenia powierzchni] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[8] Charakterystyki kart 
[8.13] Zniekształcenia powierzchni 
[Zanieczyszczenie] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charakterys- 
tyki fizyczne, 
[8] Charakterystyki kart 
[8.14] Zanieczyszczenie i interakcje komponentów 
kart 
2.3 Próby mechaniczne 
z wbudowanym 
modułem chipowym  [Zginanie] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810:2003/zmiana 1:2009, Karty identyfi­
kacyjne – Charakterystyki fizyczne, zmiana 1: 
Kryteria dotyczące kart elektronicznych 
[9.2] Dynamiczne naprężenie zginające 
Łączna liczba cykli zginania: 4 000. 
[Skręcanie] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810:2003/zmiana 1:2009, Karty identyfika- 
cyjne – Charakterystyki fizyczne, zmiana 1: Kryteria 
dotyczące kart elektronicznych 
[9.3] Dynamiczne naprężenie skręcające 
Łączna liczba cykli skręcania: 4 000.  ISO/IEC 7810  
3 Modu ł 
3.1 Moduł  Moduł to obudowa chipu i płyta stykowa. 
[Profil powierzchni] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7816-1:2011, Karty identyfikacyjne – Karty 
elektroniczne – Część 1: Karty stykowe – Charakte­
rystyki fizyczne 
[4.2] Profil powierzchni styków  ISO/IEC 7816  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 407  
Nr Badanie  Opis  Powiązane wymogi  
[Wytrzymałość mechaniczna] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7816-1:2011, Karty identyfikacyjne – Karty 
elektroniczne – Część 1: Karty stykowe – Charakte­
rystyki fizyczne 
[4.3] Wytrzymałość mechaniczna (karty i styków) 
[Rezystancja] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7816-1:2011, Karty identyfikacyjne – Karty 
elektroniczne – Część 1: Karty stykowe – Charakter- 
ystyki fizyczne 
[4.4] Rezystancja (styków) 
[Wymiary] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7816-2:2007, Karty identyfikacyjne – Karty 
elektroniczne – Część 2: Karty stykowe – Wymiary 
i rozmieszczenie styków 
[3] Wymiary styków 
[Rozmieszczenie] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7816-2:2007, Karty identyfikacyjne – Karty 
elektroniczne – Część 2: Karty stykowe – Wymiary 
i rozmieszczenie styków 
[4] Liczba i rozmieszczenie styków 
W przypadku modułów z sześcioma stykami styki 
„C4” i „C8” nie są objęte tym wymogiem dotyczącym 
próby.  
4 Chip  
4.1 Chip  
[Temperatura pracy] 
Chip karty do tachografu pracuje w temperaturze 
otoczenia wynoszącej od – 25 °C do + 85 °C.  241–244 
Regulamin nr 10 
EKG ONZ 
ISO/IEC 7810 
ISO/IEC 10373  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 408  
Nr Badanie  Opis  Powiązane wymogi  
[Temperatura i wilgotność] 
Załącznik 1C rozdział 4.4 „Wymagania środowi­
skowe i elektryczne”, 241) 
Karty do tachografu prawidłowo pracują we wszyst­
kich warunkach klimatycznych normalnie występują­
cych na terytorium Wspólnoty, przynajmniej 
w zakresie temperatur od – 25 do + 70 °C ze spora­
dycznymi temperaturami szczytowymi do +85 °C, 
przy czym „sporadyczny” oznacza nie dłużej niż 4 
godziny jednorazowo i nie więcej niż 100 razy 
w okresie eksploatacji karty. 
Karty do tachografu naraża się kolejno na następu­
jące temperatury i wilgotność przez określony czas. 
Po każdym etapie kartę do tachografu bada się pod 
kątem funkcjonalności elektrycznej. 
1. Temperatura – 20 °C przez 2 h. 
2. Temperatura +/– 0 °C przez 2 h. 
3. Temperatura + 20 °C, wilgotność względna 
50 %, przez 2 h. 
4. Temperatura + 50 °C, wilgotność względna 
50 %, przez 2 h 
5. Temperatura + 70 °C, wilgotność względna 
50 %, przez 2 h. 
Temperatura jest zwiększana sporadycznie do + 85 
°C, wilgotność względna wynosi 50 %, przez 60 
min. 
6. Temperatura + 70 °C, wilgotność względna 
85 %, przez 2 h. 
Temperatura jest zwiększana sporadycznie do + 85 
°C, wilgotność względna wynosi 85 %, przez 30 
min. 
[Wilgotność] 
Załącznik 1C rozdział 4.4 „Wymagania środowiskowe 
i elektryczne”, 242) 
Karty do tachografu prawidłowo pracują w zakresie 
wilgotności od 10 % do 90 %. 
[Kompatybilność elektromagnetyczna – EMC] 
Załącznik 1C rozdział 4.4 „Wymagania środowiskowe 
i elektryczne”, 244) 
W trakcie pracy karty do tachografu zachowują 
zgodność z regulaminem nr 10 EKG ONZ pod 
względem kompatybilności elektromagnetycznej.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 409  
Nr Badanie  Opis  Powiązane wymogi  
[Elektryczność statyczna] 
Załącznik 1C rozdział 4.4 „Wymagania środowiskowe 
i elektryczne”, 244) 
W trakcie pracy karty do tachografu muszą być 
zabezpieczone przed wyładowaniami elektrostatycz- 
nymi. 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810:2003/zmiana 1:2009, Karty identyfika- 
cyjne – Charakterystyki fizyczne, zmiana 1: Kryteria 
dotyczące kart elektronicznych 
[9.4] Elektryczność statyczna 
[9.4.1] Karty elektroniczne ze stykami 
Napięcie próbne: 4 000 V. 
[Urządzenia rentgenowskie] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810:2003/zmiana 1:2009, Karty identyfika- 
cyjne – Charakterystyki fizyczne, zmiana 1: Kryteria 
dotyczące kart elektronicznych 
[9.1.] Urządzenia rentgenowskie 
[Promieniowanie ultrafioletowe] 
ISO/IEC 10373-1:2006, Karty identyfikacyjne – 
Metody badań – Część 1: Charakterystyki ogólne 
[5.11] Promieniowanie ultrafioletowe 
[trzykołowe] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 10373-1:2006/zmiana 1:2012, Karty identy- 
fikacyjne – Metody badań – Część 1: Charakterystyki 
ogólne, zmiana 1 
[5.22] Karta elektroniczna – Wytrzymałość mechan- 
iczna: trzykołowy test kart elektronicznych ze stykami 
[Nawijanie] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
MasterCard CQM V2.03:2013 
[11.1.3] R-L3-14-8: Próba trwałości nawijania 
[13.2.1.32] TM-422: Niezawodność mechaniczna: 
próba nawijania  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 410  
Nr Badanie  Opis  Powiązane wymogi  
4.2 Próby mechaniczne 
modułu chipowego 
wbudowanego w kartę 
-> takie same jak 
w sekcji 2.3  [Zginanie] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810:2003/zmiana 1:2009, Karty identyfi­
kacyjne – Charakterystyki fizyczne, zmiana 1: 
Kryteria dotyczące kart elektronicznych 
[9.2] Dynamiczne naprężenie zginające 
Łączna liczba cykli zginania: 4 000. 
[Skręcanie] 
Karty do tachografu muszą być zgodne z wymogami 
normy 
ISO/IEC 7810:2003/zmiana 1:2009, Karty identyfika- 
cyjne – Charakterystyki fizyczne, zmiana 1: Kryteria 
dotyczące kart elektronicznych 
[9.3] Dynamiczne naprężenie skręcające 
Łączna liczba cykli skręcania: 4 000.  ISO/IEC 7810  
5 Testy protoko łów 
5.1 Ciąg ATR  Sprawdzenie zgodności ciągu ATR.  ISO/IEC 7816-3 
TCS_14, TCS_17, 
TCS_18  
5.2 T=0  Sprawdzenie zgodności protokołu T=0.  ISO/IEC 7816-3 
TCS_11, TCS_12, 
TCS_13, TCS_15  
5.3 PTS  Sprawdzenie zgodności polecenia PTS przez usta­
wienie T = 1 z T = 0.  ISO/IEC 7816-3 
TCS_12, TCS_19, 
TCS_20, TCS_21  
5.4 T=1  Sprawdzenie zgodności protokołu T = 1.  ISO/IEC 7816-3 
TCS_11, TCS_13, 
TCS_16  
6 Struktura karty  
6.1 Sprawdzenie zgodności struktury plików na karcie 
przez sprawdzenie, czy na karcie są wymagane pliki 
oraz sprawdzenie warunków dostępu do plików.  TCS_22–TCS_28 
TCS_140–TCS_179  
7 Badania funkcjonalno ści 
7.1 Normalne przetwa­
rzanie  Sprawdzenie co najmniej raz każdego, dozwolonego 
użycia każdego polecenia (np.: sprawdzenie polecenia 
UPDATE BINARY z CLA = „00”, CLA = „0C” 
i z różnymi parametrami P1, P2 i Lc). 
Sprawdzenie, czy karta rzeczywiście wykonuje czyn­
ności (np.: odczytując plik poleceniem wykonywanym 
na tym pliku).  TCS_29–TCS_139  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 411  
Nr Badanie  Opis  Powiązane wymogi  
7.2 Komunikaty błędu  Sprawdzenie co najmniej raz każdego komunikatu 
błędu (określonego w dodatku 2) dla każdego pole­
cenia. 
Sprawdzenie co najmniej raz każdego błędu ogólnego 
(z wyjątkiem błędów integralności „ 6400 ” sprawdza­
nych w trakcie certyfikacji bezpieczeństwa).  
7.3 Pakiet szyfrów i standardowe parametry domeny  CSM_48, CSM_50  
8 Personalizacja  
8.1 Personalizacja 
optyczna  (Załącznik 1C rozdział 4.1 „Dane widzialne”, 230) 
Na awersie znajdują się: 
informacje szczególne dla wydanej karty. 
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 231) 
Na awersie znajdują się: 
daty podaje się w formacie „dd/mm/rrrr” lub 
„dd.mm.rrrr” (dzień, miesiąc, rok). 
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 235) 
Karty do tachografu mają przynajmniej następujące 
zabezpieczenia przed fałszowaniem i manipulowa- 
niem: 
— w obszarze zdjęcia zabezpieczający wzór tła 
i zdjęcie- 
zachodzą na siebie.  230, 231, 235  
5. BADANIA URZĄDZENIA ZEWNĘTRZNEGO GNSS  
Nr Badanie  Opis  Powiązane wymogi  
1. Badanie administracyjne  
1.1 Dokumentacja  Prawidłowość dokumentacji  
2. Kontrola wizualna urz ądzenia zewn ętrznego GNSS  
2.1 Zgodność z dokumentacją  
2.2 Identyfikacja/oznakowanie  224–226  
2.3 Materiały  219–223  
3. Badania funkcjonalno ści 
3.1 Dane identyfikacyjne czujnika  98, 99  
3.2 Połączenie między zewnętrznym modułem GNSS a przyrządem rejest rującym  123, 205  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 412  
Nr Badanie  Opis  Powiązane wymogi  
3.3 Położenie GNSS  36, 37  
3.4 Interfejs przyrządu rejestrującego, gdy odbiornik GNSS znajduj e się na 
zewnątrz przyrządu rejestrującego  03 
3.5 Pakiet szyfrów i standardowe parametry domeny  CSM_48, CSM_50  
4. Badania środowiskowe  
4.1 Temperatura  Sprawdzenie funkcjonalności za pomocą: 
badania zgodnie z normą ISO 16750-4, Rozdział 5.1.1.2: 
Próba eksploatacyjna w niskiej temperaturze (72 h w tempe­
raturze – 20 °C). 
Badanie to odnosi się do normy IEC 60068-2-1: Badania 
środowiskowe – Część 2-1: Próby – Próba A: Zimno. 
badania zgodnie z normą ISO 16750-4, Rozdział 5.1.2.2: 
Próba eksploatacyjna w wysokiej temperaturze (72 h 
w temperaturze 70 °C). 
Badanie to odnosi się do normy IEC 60068-2-2: Podstawowe 
procedury badań środowiskowych – Część 2: Próby – Próba 
B: Suche gorąco; 
Badanie zgodnie z normą ISO 16750-4: Rozdział 5.3.2: 
Nagła zmiana temperatury z określonym okresem przej­ 
ściowym (20 °C/70 °C, 20 cykli, czas przebywania: 1 h 
w każdej temperaturze). 
Można przeprowadzić skrócony zestaw badań (spośród tych 
zdefiniowanych w sekcji 3 niniejszej tabeli) w niższej tempe­
raturze, wyższej temperaturze i w czasie cykli 
temperaturowych.  213 
4.2 Wilgotność  Sprawdzenie odporności przyrządu rejestrującego na 
cykliczne zmiany wilgotności (próba gorąca) za pomocą 
próby Db wg normy IEC 60068-2-30, w sześciu 24-godzin­
nych cyklach, w każdym ze zmieniającą się temperaturą od 
+ 25 °C do + 55 °C i wilgotnością względną 97 % w 
+ 25 °C i 93 % w + 55 °C  214 
4.3 Mechanika  1. Drgania harmoniczne: 
sprawdzenie odporności przyrządu rejestrującego na 
drgania harmoniczne o następujących właściwościach: 
stałe przemieszczenie przy częstotliwości 5–11 Hz: 10- 
milimetrowa amplituda; 
stałe przyspieszenie przy częstotliwości 11–300 Hz: 5g. 
Wymóg ten sprawdza się za pomocą próby Fc wg normy 
IEC 60068-2-6, z minimalnym czasem trwania próby 3 × 
12 h (12 h na oś). 
ISO 16750-3 nie wymaga przeprowadzenia testu drgań 
harmonicznych w przypadku urządzeń znajdujących się 
w oddzielnej kabinie pojazdu.  219 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 413  
Nr Badanie  Opis  Powiązane wymogi  
2. Drgania swobodne: 
Próba zgodnie z ISO 16750-3: Rozdział 4.1.2.8: Próba 
VIII: Pojazd użytkowy, oddzielna kabina pojazdu. 
Próba drgań swobodnych: 10 … 2 000 Hz, wertykalna 
średnia kwadratowa 21,3 m/s  2 , wzdłużna średnia kwadra- 
towa 11,8 m/s  2 , poprzeczna średnia kwadratowa 13,1 m/s  2 , 
3 osie, 32 h na oś, w tym cykl temperaturowy – 20 … 
70°C. 
Badanie to odnosi się do normy IEC 60068-2-64: Badania 
środowiskowe – Część 2-64: Próby – Próba Fh: Wibracje 
szerokopasmowe losowe i wytyczne. 
3. Udary: 
udar mechaniczny przy impulsie półsinusoidalnym 3 g wg 
normy ISO 16750. 
Opisane powyżej badania przeprowadza się na różnych 
próbkach urządzeń poddawanych badaniom.  
4.4 Ochrona przed 
wodą i ciałami 
obcymi  Badanie zgodnie z normą ISO 20653: Pojazdy drogowe – 
Stopień ochrony (kod IP) – Ochrona urządzeń elektrycznych 
przed ciałami obcymi, wodą i dostępem (bez zmian para­
metrów)  220, 221  
4.5 Zabezpieczenie 
nadnapięciowe  Sprawdzenie odporności przyrządu rejestrującego na napięcie 
zasilania:  216 
wersje 24 V:  34 V przy + 40 °C 
przez 1 godzinę  
wersje 12 V:  17 V przy + 40 °C 
przez 1 godzinę  
(ISO 16750-2 rozdział 4.3)  
4.6 Zabezpieczenie 
przed odwróce­
niem polary­
zacji  Sprawdzenie odporności przyrządu rejestrującego na odwró­
cenie biegunów napięcia zasilającego. 
(ISO 16750-2 rozdział 4.7)  216 
4.7 Zabezpieczenie 
zwarciowe  Sprawdzenie, czy sygnały wyjściowe są zabezpieczone przed 
zwarciem do napięcia zasilającego i do masy. 
(ISO 16750-2 rozdział 4.10)  216 
5 Badania EMC  
5.1 Emisje radia­
cyjne i wrażli­
wość na 
radiację  Zgodność z regulaminem nr 10 EKG ONZ  218  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 414  
Nr Badanie  Opis  Powiązane wymogi  
5.2 Wyładowania 
elektrostatyczne  Zgodność z normą ISO 10605:2008 + Sprostowanie tech­
niczne: 2010 + AMD1: 2014: +/– 4 kV w przypadku styku 
i +/– 8 kV w przypadku rozładowania do powietrza  218 
5.3 Wrażliwość na 
stany nieusta­
lone w zasilaniu  W przypadku wersji 24 V: zgodność z normą ISO 7637-2 
i wersją 3 regulaminu nr 10 EKG ONZ: 
impuls 1a: Vs = – 450 V, Ri = 50 omów 
impuls 2a: Vs = + 37 V, Ri = 2 omy 
impuls 2b: Vs = + 20 V, Ri = 0,05 oma 
impuls 3a: Vs = – 150 V, Ri = 50 omów 
impuls 3b: Vs = + 150 V, Ri = 50 omów 
impuls 4: Vs = – 16 V Va = – 12V, t6 = 100 ms 
impuls 5: Vs = + 120 V, Ri = 2,2 oma, td = 250 ms 
W przypadku wersji 12 V: zgodność z normą ISO 7637-1 
i wersją 3 regulaminu nr 10 EKG ONZ: 
impuls 1: Vs = – 75 V, Ri = 10 omów 
impuls 2a: Vs = + 37 V, Ri = 2 omy 
impuls 2b: Vs = + 10 V, Ri = 0,05 oma 
impuls 3a: Vs = – 112 V, Ri = 50 omów 
impuls 3b: Vs = + 75 V, Ri = 50 omów 
impuls 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms 
impuls 5: Vs = + 65 V, Ri = 3 omy, td = 100 ms 
Impuls 5 należy testować tylko w przypadku przyrządów 
rejestrujących przeznaczonych do zainstalowania w pojaz­
dach, w których nie zainstalowano zewnętrznego, wspólnego 
zabezpieczenia przed spadkiem obciążenia. 
Aby uzyskać informacje na temat propozycji zabezpieczenia 
przed spadkiem obciążenia, zob. norma ISO 16750-2 
wydanie 4. rozdział 4.6.4.  218 
▼M1 
6. BADANIE ZEWNĘTRZNEGO URZĄDZENIA DO ŁĄCZNOŚCI NA 
ODLEGŁOŚĆ  
Nr Badanie  Opis  Powiązane wymogi  
1. Badanie administracyjne  
1.1 Dokumentacja  Prawidłowość doku­
mentacji  
2. Kontrola wizualna  
2.1. Zgodność z dokumentacją  
2.2. Identyfikacja/oznakowanie  225, 226  
2.3 Materiały  219–223  
3. Badania funkcjonalno ści 
3.1 Łączność na odległość na potrzeby ukierunkowanych kontroli dro gowych  4, 197–199  
3.2 Rejestrowanie i przechowywanie w pamięci danych  9 1  
3.3 Łączność z przyrządem rejestrującym  Dodatek 14 pozycje 
DSC_66–DSC_70, 
DSC_71–DSC_76  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 415  
Nr Badanie  Opis  Powiązane wymogi  
4. Badania środowiskowe  
4.1 Temperatura  Sprawdzenie funkcjonalności za pomocą: 
badania zgodnie z normą ISO 16750-4, rozdział 5.1.1.2: 
Próba eksploatacyjna w niskiej temperaturze (72 h 
w temperaturze -20 °C). 
Badanie to odnosi się do normy IEC 60068-2-1: Badania 
środowiskowe – Część 2-1: Próby – Próba A: Zimno 
Badanie zgodnie z normą ISO 16750-4: Rozdział 
5.1.2.2: Próba eksploatacyjna w wysokiej temperaturze 
(72 h w temperaturze 70 °C). 
Badanie to odnosi się do normy IEC 60068-2-2: Podsta­
wowe procedury badań środowiskowych – Część 2: 
Próby – Próba B: Suche gorąco; 
Badanie zgodnie z normą ISO 16750-4: Rozdział 5.3.2: 
Nagła zmiana temperatury z określonym okresem przej­ 
ściowym (-20 °C/70 °C, 20 cykli, czas przebywania: 1 h 
w każdej temperaturze). 
Można przeprowadzić skrócony zestaw badań (spośród 
tych zdefiniowanych w sekcji 3 niniejszej tabeli) 
w niższej temperaturze, wyższej temperaturze i w czasie 
cykli temperaturowych.  213 
4.2 Ochrona przed 
wodą i ciałami 
obcymi  Badanie zgodnie z normą ISO 20653: Pojazdy drogowe 
– Stopień ochrony (kod IP) – Ochrona urządzeń elek­
trycznych przed ciałami obcymi, wodą i dostępem 
(wartość docelowa IP40)  220, 221  
5 Badania EMC  
5.1 Emisje radiacyjne 
i wrażliwość na 
radiację  Zgodność z regulaminem nr 10 EKG ONZ  218  
5.2 Wyładowania elek­
trostatyczne  Zgodność z normą ISO 10605:2008 + Sprostowanie 
techniczne: 2010 + AMD1:2014: +/- 4kV w przypadku 
styku i +/- 8kV w przypadku rozładowania do powietrza  218 
5.3 Wrażliwość na 
stany nieustalone 
w zasilaniu  W przypadku wersji 24 V: zgodność z normą ISO 7637- 
2 i wersją 3 regulaminu nr 10 EKG ONZ: 
impuls 1a: Vs = -450 V, Ri = 50 omów 
impuls 2a: Vs = +37 V, Ri = 2 omy 
impuls 2b: Vs = +20 V, Ri = 0,05 oma 
impuls 3a: Vs = -150 V, Ri = 50 omów 
impuls 3b: Vs = +150 V, Ri = 50 omów 
impuls 4: Vs = -16 V, Va = -12V, t6 = 100 ms 
impuls 5: Vs = +120 V, Ri = 2,2 oma, td = 250 ms 
W przypadku wersji 12 V: zgodność z normą ISO 7637- 
1 i wersją 3 regulaminu nr 10 EKG ONZ: 
impuls 1: Vs = -75 V, Ri = 10 omów 
impuls 2a: Vs = +37 V, Ri = 2 omy 
impuls 2b: Vs = +10 V, Ri = 0,05 oma 
impuls 3a: Vs = -112 V, Ri = 50 omów  218 ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 416  
Nr Badanie  Opis  Powiązane wymogi  
impuls 3b: Vs = +75 V, Ri = 50 omów 
impuls 4: Vs = -6 V, Va = -5 V, t6 = 15 ms 
impuls 5: Vs = +65 V, Ri = 3 omy, td = 100 ms 
Impuls 5 należy testować tylko w przypadku przyrządów 
rejestrujących przeznaczonych do zainstalowania 
w pojazdach, w których nie zainstalowano zewnętrz­
nego, wspólnego zabezpieczenia przed spadkiem obcią­ 
żenia. 
Aby uzyskać informacje na temat propozycji zabezpie­
czenia przed spadkiem obciążenia, zob. norma ISO 
16750-2 wydanie 4, rozdział 4.6.4.  
▼B 
7. BADANIA FUNKCJONALNOŚCI PAPIERU  
Nr Badanie  Opis  Powiązane wymogi  
1. Badanie administracyjne  
1.1 Dokumentacja  Prawidłowość dokumentacji  
2 Badania ogólne  
2.1 Liczba znaków 
w wierszu  Kontrola wizualna wydruków  172  
2.2 Minimalna wielkość 
czcionki  Kontrola wizualna wydruków i kontrola znaków  173  
2.3 Obsługiwane 
zestawy znaków  Drukarka umożliwia drukowanie znaków określonych 
w dodatku 1 rozdział 4 „Zestawy znaków”.  174 
2.4 Definicja wydruków  Sprawdzenie homologacji typu tachografu i przeprowa­
dzenie kontroli wizualnej wydruków  174 
2.5 Czytelność i identyfi­
kacja wydruków  Kontrola wydruków 
Potwierdzona sprawozdaniami z badań i protokołami 
badań przez producenta. 
Wszystkie numery homologacyjne tachografów, 
z którymi można używać danego papieru do drukarek, 
wydrukowano na papierze.  175, 177, 178  
2.6 Dodawanie uwag 
odręcznych  Kontrola wizualna: dostępne jest miejsce na podpis 
kierowcy. 
Dostępne jest miejsce na inne dodatkowe wpisy 
odręczne.  180 
2.7 Dodatkowe infor­
macje szczegółowe 
na pierwszej stronie 
kartki papieru  Pierwsza i druga strona kartki papieru mogą zawierać 
dodatkowe szczegółowe dane i informacje. 
Tego rodzaju dodatkowe szczegółowe dane i informacje 
nie mogą ograniczać czytelności wydruków. 
Kontrola wizualna  177, 178  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 417  
Nr Badanie  Opis  Powiązane wymogi  
3 Badania przechowywania  
3.1 Suche gorąco  Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C 
± 2 °C/przy wilgotności względnej 55 % ± 3 %. 
Środowisko testowe: 72 h w temperaturze + 70 °C ± 2 °C. 
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy 
wilgotności względnej 55 % ± 3 %.  176, 178 
IEC 60068-2-2-Bb  
2.2 Wilgotne gorąco  Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C 
± 2 °C/przy wilgotności względnej 55 % ± 3 %. 
Środowisko testowe: 144 h w temperaturze + 55 °C 
± 2 °C/przy wilgotności względnej 93 % ± 3 %. 
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy 
wilgotności względnej 55 % ± 3 %.  176, 178 
IEC 60068-2-78-Cab  
4 Badania papieru w u życiu 
4.1 Podstawowa odpor­
ność na działanie 
wilgoci (papier 
niezadrukowany)  Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C 
± 2 °C/przy wilgotności względnej 55 % ± 3 %. 
Środowisko testowe: 144 h w temperaturze + 55 °C 
± 2 °C/przy wilgotności względnej 93 % ± 3 %. 
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy 
wilgotności względnej 55 % ± 3 %.  176, 178 
IEC 60068-2-78-Cab  
4.2 Drukowność  Kondycjonowanie wstępne: 24 h w temperaturze + 40 °C 
± 2 °C/przy wilgotności względnej 93 % ± 3 %. 
Środowisko testowe: wydruk sporządzony w temperaturze 
+ 23 °C ± 2 °C 
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy 
wilgotności względnej 55 % ± 3 %.  176, 178  
4.3 Odporność na dzia­ 
łanie wysokich 
temperatur  Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C 
± 2 °C/przy wilgotności względnej 55 % ± 3 %. 
Środowisko testowe: 2 h w temperaturze + 70 °C ± 2 °C, 
suche gorąco 
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy 
wilgotności względnej 55 % ± 3 %.  176, 178 
IEC 60068-2-2-Bb  
4.4 Odporność na dzia­ 
łanie niskich tempe­
ratur  Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C 
± 2 °C/przy wilgotności względnej 55 % ± 3 %. 
Środowisko testowe: 24 h w temperaturze – 20 °C ± 3 °C, 
suche zimno 
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy 
wilgotności względnej 55 % ± 3 %.  176, 178 
ISO 60068-2-1-Ab  
4.5 Światłoodporność  Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C 
± 2 °C/przy wilgotności względnej 55 % ± 3 %. 
Środowisko testowe: 100 h pod oświetleniem o natężeniu 
5 000 luksów w temperaturze + 23 °C ± 2 °C przy wilgot­
ności względnej 55 % ± 3 % 
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy 
wilgotności względnej 55 % ± 3 %.  176, 178  
Kryteria czytelności w odniesieniu do badań 3.x i 4.x:  
Czytelność wydruku jest zapewniona, jeżeli gęstości optyczne są  zgodne 
z następującymi ograniczeniami:  
Wielkość drukowanych znaków: min. 1,0  
Tło (papier niezadrukowany): maks. 0,2  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 418  
Gęstości optyczne otrzymanych wydruków mierzy się według DIN EN  
ISO 534.  
Wydruki muszą przedstawiać niezmienione wymiary i być wyraźnie 
czytelne.  
8. BADANIA INTEROPERACYJNOŚCI  
▼M1 
Nr Badanie  Opis  
8.1 Badania interoperacyjności między przyrządami rejestrującym i a kartami do tachografu  
1 Wzajemne uwierzytelnienie  Sprawdzenie, czy wzajemne uwierzytelnienie między przyrządem 
rejestrującym a kartą do tachografu przebiega normalnie.  
2 Próby zapisu/odczytu  Wykonanie scenariusza typowej czynności na przyrządzie rejestr u­
jącym. Scenariusz dostosowany jest do typu badanej karty i obej ­
muje zapis na karcie tak wielu EF, jak to możliwe. 
Sprawdzenie poprzez pobieranie danych z przyrządu rejestrują­
cego, czy wszystkie odpowiednie zapisy zostały wykonane prawid­  
łowo. 
Sprawdzenie poprzez pobieranie danych z karty, czy wszystkie 
odpowiednie zapisy zostały wykonane prawidłowo. 
Sprawdzenie poprzez dzienny wydruk z karty, czy wszystkie odpo­
wiednie zapisy mogą być odczytane prawidłowo.  
8.2 Badania interoperacyjności między przyrządami rejestrującym i a czujnikami ruchu  
1 Parowanie  Sprawdzenie, czy parowanie przyrządu rejestrującego z czujnika mi 
ruchu przebiega normalnie.  
2 Badania czynności  Wykonanie scenariusza typowej czynności na czujniku ruchu. 
Scenariusz obejmuje normalną czynność i wygenerowanie jak 
największej liczby zdarzeń lub usterek. 
Sprawdzenie poprzez pobieranie danych z przyrządu rejestrują­
cego, czy wszystkie odpowiednie zapisy zostały wykonane prawid­  
łowo. 
Sprawdzenie poprzez pobieranie danych z karty, czy wszystkie 
odpowiednie zapisy zostały wykonane prawidłowo. 
Sprawdzenie poprzez dzienny wydruk, czy wszystkie odpowiednie 
zapisy mogą być odczytane prawidłowo.  
8.3 Badania interoperacyjności między przyrządami rejestrującym i a urządzeniem zewnętrznym GNSS 
(w stosownych przypadkach)  
1 Wzajemne uwierzytelnienie  Sprawdzenie, czy wzajemne uwierzytelnienie (połączenie) między  
przyrządem rejestrującym a zewnętrznym modułem GNSS prze­
biega normalnie.  
2 Badania czynności  Wykonanie scenariusza typowej czynności na zewnętrznym urzą­
dzeniu GNSS. Scenariusz obejmuje normalną czynność i wygene­
rowanie jak największej liczby zdarzeń lub usterek. 
Sprawdzenie poprzez pobieranie danych z przyrządu rejestrują­
cego, czy wszystkie odpowiednie zapisy zostały wykonane prawid­  
łowo. 
Sprawdzenie poprzez pobieranie danych z karty, czy wszystkie 
odpowiednie zapisy zostały wykonane prawidłowo. 
Sprawdzenie poprzez dzienny wydruk, czy wszystkie odpowiednie 
zapisy mogą być odczytane prawidłowo.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 419  
9. BADANIA OSNMA  
9.1. Wprowadzenie  
W niniejszym rozdziale opisano badania mające na celu wykazanie  
prawidłowego wdrożenia OSNMA w odbiorniku GNSS. Ponieważ uwie­
rzytelnianie sygnału satelitarnego jest wykonywane wyłącznie pr zez 
odbiornik GNSS niezależnie od jakiegokolwiek innego elementu sk łado­
wego tachografu, badania określone w niniejszym rozdziale mogą być 
przeprowadzane na odbiorniku GNSS jako samodzielnym elemencie. 
W takim przypadku producent tachografów przedstawia organom udz iela­
jącym homologacji typu sprawozdanie zawierające szczegółowe inf or­
macje na temat rozwoju i wyników badań przeprowadzanych na odpo wie­
dzialność producenta odbiorników GNSS.  
9.2 Warunki maj ące zastosowanie  
— Kryteria zaliczenia/niezaliczenia określone w badaniach OSNMA  
uznaje się za ważne tylko w odniesieniu do określonych warunków  
badania.  
— Kryteria te mogą zostać zmienione w momencie składania deklar acji 
usług Galileo OSNMA i z uwzględnieniem związanych z nimi zobo­
wiązań w zakresie wydajności usług.  
9.3. Definicje i skróty  
9.3.1. Definicje  
Zimny/ciepły/gorący 
rozruch GNSS:: dotyczy warunku startowego odbiornika 
GNSS w oparciu o dostępność czasu (T), 
bieżący almanach (A) i efemerydy (E) oraz 
pozycję (P):  
— zimny rozruch GNSS: brak  
— ciepły rozruch GNSS: T, A, P  
— gorący rozruch GNSS: T, A, E, P  
Zimny/ciepły/gorący 
rozruch OSNMA: dotyczy warunku startowego funkcji OSNMA 
w oparciu o dostępność klucza publicznego (P) 
oraz informacji DSM-KROOT (K) (jak okre­ 
ślono w wytycznych dla odbiorników w zakresie 
OSNMA, o których mowa w dodatku 12):  
— zimny rozruch OSNMA: brak  
— ciepły rozruch OSNMA: P  
— gorący rozruch OSNMA: P, K  
9.3.2. Akronimy  
ADKD Authentication Data & Key Delay [dane uwierzytelniania 
i opóźnienie klucza]  
DSM-KROOT Digital Signature Message KROOT [KROOT komunikatu 
podpisu cyfrowego]  
GNSS Global Navigation Satellite System [globalny system 
nawigacji satelitarnej]  
KROOT Root Key of the TESLA key chain [klucz główny 
łańcucha kluczy TESLA]  
MAC Message Authentication Code [kod uwierzytelniania 
komunikatów]  
NMACK Number of MAC & key blocks (per 30 seconds) [liczba 
MAC i bloków kluczy (na każde 30 sekund)]  
OSNMA Galileo Open Service Navigation Message Authentication 
[uwierzytelnianie komunikatów nawigacyjnych usługi 
otwartej Galileo]  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 420  
SLMAC Slow MAC (powolny MAC)  
TESLA Timed Efficient Stream Loss-tolerant Authentication 
[efektywne czasowo uwierzytelnianie odporne na utratę 
strumienia] (protokół używany w OSNMA)  
9.4. Sprzęt do generowania sygna łów GNSS  
Generowanie sygnałów GNSS może odbywać się za pomocą wielokon­
stelacyjnego symulatora GNSS obsługującego przesyłanie komunika tów 
OSNMA. Ewentualnie można zastosować odtwarzacz sygnału częstotl i­
wości radiowej umożliwiający odtwarzanie próbek sygnału GNSS 
z plików. Typowa głębokość bitu i częstotliwość pobierania prób ek 
wynoszą odpowiednio 4 bity I/Q i 10 MHz.  
Zakłada się, że odbiornik GNSS posiada interfejsy umożliwiające  oczysz­
czenie pamięci odbiornika (aby niezależnie usunąć klucz publicz ny, 
KROOT, informacje zegarowe, informacje o pozycji, efemerydy i a lma­
nach), ustawienie realizacji czasu lokalnego odbiornika na potr zeby wery­
fikacji czasu OSNMA oraz załadowanie informacji kryptograficzny ch. 
Polecenia te mogą ograniczać się do celów testowych i w związku  
z tym mogą nie być dostępne na potrzeby nominalnego działania 
odbiornika.  
9.5 Warunki badania  
9.5.1. Warunki GNSS  
Symulowane lub odtwarzane sygnały GNSS będą miały następującą 
charakterystykę:  
— statyczny scenariusz odbiornika użytkownika;  
— co najmniej konstelacje GPS i Galileo;  
— częstotliwość E1/L1;  
— co najmniej 4 satelity Galileo o kącie elewacji większym niż 5°; 
— czas trwania wymagany dla każdego badania;  
— stałe efemerydy nawigacyjne z satelitów podczas badania.  
9.5.2. Warunki OSNMA  
Komunikat OSNMA przekazywany za pośrednictwem sygnału RF będzie  
miał następującą charakterystykę:  
— komunikat HKROOT ze statusem OSNMA ustawionym na tryb 
eksploatacyjny lub testowy oraz ustalony DSM-KROOT składający 
się z 8 bloków dla obowiązującego łańcucha;  
— co najmniej 4 satelity Galileo transmitujące OSNMA;  
— komunikat MACK z jednym blokiem MACK (tj. NMACK=1) oraz co 
najmniej jeden ADKD=0 oraz jeden ADKD=12 na satelitę i blok 
MACK;  
— wielkość znacznika wynosząca 40 bitów;  
— minimalna równoważna długości znacznika zgodnie z wymogami 
określonymi w wytycznych dla odbiorników w zakresie OSNMA 
(obecnie 80 bitów).  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 421  
O ile nie zaznaczono inaczej, realizacja czasu odbiornika wewnę trznego 
musi być znana z wystarczającą dokładnością i odpowiednio zsync hroni­
zowana z czasem symulowanym. Gwarantuje to spełnienie wymogu 
synchronizacji czasu początkowego OSNMA dla każdego warunku 
badania, tj. synchronizacji nominalnej dla wszystkich badań z w yjątkiem 
SLMAC. Więcej informacji na temat inicjalizacji czasu można zna leźć 
w wytycznych dla odbiorników w zakresie OSNMA.  
Należy zauważyć, że wskazane kryteria zaliczenia/niezaliczenia są zacho­
wawcze i nie odzwierciedlają oczekiwanych wyników OSNMA Galileo . 
9.6. Specyfikacja dotycz ąca badań 
Nr Badanie  Opis  Odpowiednie wymogi  
1. Badanie administracyjne  
1.1 Dokumentacja  Prawidłowość dokumentacji  
2 Badania ogólne  
2.1 Gorący rozruch 
OSNMA  Cel: sprawdzenie, czy odbiornik GNSS oblicza pozycję 
przy użyciu OSNMA po gorącym rozruchu. 
Procedura: 
Odbiornik GNSS uruchamia się w warunkach gorącego 
rozruchu GNSS i OSNMA oraz pozyskuje sygnały 
widocznych satelitów Galileo. 
Odbiornik uwierzytelnia dane nawigacyjne Galileo za 
pomocą OSNMA (ADKD = 0) i podaje pozycję z uwie­
rzytelnionymi danymi. 
Kryteria zaliczenia/niezaliczenia: odbiornik oblicza 
ustaloną uwierzytelnioną pozycję w ciągu 160 sekund.  Dodatek 12, 
GNS_3b  
2.2 Ciepły rozruch 
OSNMA  Cel: sprawdzenie, czy odbiornik GNSS oblicza pozycję 
przy użyciu OSNMA po ciepłym rozruchu. 
Procedura: 
Przed rozpoczęciem badania informacje dotyczące 
efemerydów i KROOT usuwa się z pamięci odbiornika 
GNSS w celu wymuszenia ciepłego rozruchu GNSS 
i OSNMA. 
Odbiornik GNSS uruchamia się i pozyskuje sygnały 
widocznych satelitów Galileo. 
DSM-KROOT jest odbierany i weryfikowany. 
Odbiornik uwierzytelnia dane nawigacyjne Galileo za 
pomocą OSNMA (ADKD=0) i podaje pozycję z uwie­
rzytelnionymi danymi. 
Kryteria zaliczenia/niezaliczenia: odbiornik oblicza 
ustaloną uwierzytelnioną ważną pozycję w ciągu 430 
sekund.  Dodatek 12, 
GNS_3b  
2.3 Ciepły rozruch 
OSNMA z SLMAC  Cel: sprawdzenie, czy odbiornik GNSS oblicza pozycję 
za pomocą OSNMA po ciepłym rozruchu z inicjacją 
czasu wymagającą trybu SLMAC, jak określono 
w wytycznych dla odbiorników w zakresie OSNMA. 
Procedura: 
Realizacja czasu odbiornika wewnętrznego musi być 
skonfigurowana w taki sposób, aby początkowa 
niepewność czasu wynosiła od 2 do 2,5 minuty, tak 
aby zgodnie z wytycznymi dla odbiorników w zakresie 
OSNMA aktywować tryb Slow MAC.  Dodatek 12, 
GNS_3b  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 422  
Nr Badanie  Opis  Odpowiednie wymogi  
Przed rozpoczęciem badań informacje dotyczące efeme­
rydów i KROOT usuwa się z pamięci odbiornika 
GNSS w celu wymuszenia ciepłego rozruchu GNSS 
i OSNMA. 
Odbiornik GNSS uruchamia się i pozyskuje sygnały 
widocznych satelitów Galileo. 
DSM-KROOT jest odbierany i weryfikowany. 
Odbiornik uwierzytelnia dane nawigacyjne Galileo 
wyłącznie za pomocą OSNMA Slow MAC 
(ADKD=12) i podaje pozycję z uwierzytelnionymi 
danymi. 
Kryteria zaliczenia/niezaliczenia: odbiornik oblicza 
ustaloną uwierzytelnioną ważną pozycję w ciągu 730 
sekund.  
2.4 Gorący rozruch 
OSNMA z odtwa­
rzanym sygnałem  Cel: sprawdzenie, czy odbiornik GNSS wykrywa 
odtwarzany sygnał. 
Procedura: 
Odbiornik GNSS uruchamia się w warunkach gorącego 
rozruchu GNSS i OSNMA oraz pozyskuje sygnały 
widocznych satelitów Galileo. 
Odbiornik uwierzytelnia dane nawigacyjne Galileo za 
pomocą OSNMA (ADKD=0) i podaje pozycję z uwie­
rzytelnionymi danymi. 
Gdy odbiornik dostarczy rozwiązanie PVT z uwierzytel­
nionymi danymi, zostaje wyłączony. 
Symulowany jest odtwarzany sygnał z opóźnieniem 40 
sekund w stosunku do poprzedniego, a odbiornik 
zostaje włączony. 
Odbiornik wykrywa, że czas systemu Galileo z czasu 
sygnału w przestrzeni oraz realizacja czasu lokalnego 
czasu nie spełniają wymogu synchronizacji i zaprzestaje 
przetwarzania danych OSNMA, jak określono 
w wytycznych dla odbiorników w zakresie OSNMA. 
Kryteria zaliczenia/niezaliczenia: odbiornik wykrywa 
odtwarzanie i nie oblicza uwierzytelnionej ważnej 
pozycji od początku odtwarzania do końca badania.  Dodatek 12, 
GNS_3b  
2.5 Gorący rozruch 
OSNMA z fałszywymi 
danymi  Cel: sprawdzenie, czy OSNMA wykrywa fałszywe 
dane. 
Procedura: 
Odbiornik GNSS uruchamia się w warunkach gorącego 
rozruchu GNSS i OSNMA. 
Odbiornik GNSS jest w stanie pozyskać sygnał wszyst­
kich widocznych satelitów Galileo i zweryfikować 
autentyczność ich komunikatów nawigacyjnych za 
pomocą OSNMA. 
Co najmniej jeden bit danych efemerycznych dostarczo­
nych przez każdego satelitę Galileo nie odpowiada pier­
wotnym i uwierzytelnionym danym, ale komunikat 
Galileo I/NAV musi być spójny, z uwzględnieniem 
CRC. 
Kryteria zaliczenia/niezaliczenia: odbiornik wykrywa 
fałszywe dane w ciągu 160 sekund i nie oblicza uwie­
rzytelnionej ważnej pozycji do zakończenia badania.  Dodatek 12, 
GNS_3b  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 423  
Dodatek 10  
WYMOGI BEZPIECZE ŃSTWA  
W niniejszym dodatku określono wymogi bezpieczeństwa informatyc znego doty­
czące elementów składowych systemu tachografu inteligentnego (t achografu 
drugiej generacji).  
SEC_001 Następujące elementy składowe systemu tachografu inteli gentnego 
muszą posiadać certyfikacje bezpieczeństwa zgodnie z systemem 
wspólnych kryteriów:  
— przyrząd rejestrujący;  
— karta do tachografu;  
— czujnik ruchu;  
— urządzenie zewnętrzne GNSS.  
SEC_002 Minimalne wymogi bezpieczeństwa informatycznego, jakie ma spełnić 
każdy element składowy, który musi posiadać certyfikację bezpie czeń­
stwa, określa się w profilu zabezpieczenia dla elementu składow ego, 
zgodnie z systemem wspólnych kryteriów.  
SEC_003 Komisja Europejska upewnia się, że cztery profile zabez pieczenia 
zgodne z niniejszym załącznikiem są finansowane, opracowywane, 
zatwierdzane przez rządowe jednostki certyfikujące ds. bezpiecz eństwa 
informatycznego, skupione w grupie roboczej ds. wspólnej interp re­
tacji (JIWG), która wspiera wzajemne uznawanie certyfikatów pod  
egidą SOGIS-MRA (Umowa o wzajemnym uznawaniu świadectw 
z oceny bezpieczeństwa informatycznego), oraz rejestrowane:  
— profil zabezpieczenia dla przyrządu rejestrującego;  
— profil zabezpieczenia dla karty do tachografu;  
— profil zabezpieczenia dla czujnika ruchu;  
— profil zabezpieczenia dla urządzenia zewnętrznego GNSS.  
Profil zabezpieczenia dla przyrządu rejestrującego uwzględnia p rzypadki, gdy 
przyrząd rejestrujący jest przeznaczony do użytkowania z urządz eniem 
zewnętrznym GNSS, jak i gdy nie jest do tego przeznaczony. W ty m pierwszym 
przypadku wymogi bezpieczeństwa dotyczące urządzenia zewnętrzne go GNSS 
zostają podane w specjalnym profilu zabezpieczenia.  
SEC_004 Aby nadać kształt celowi zabezpieczenia, który stanowi podstawę do 
uzyskania certyfikacji bezpieczeństwa elementu składowego, prod u­
cenci elementów składowych przygotowują i kompletują niezbędny 
profil zabezpieczenia dla odpowiedniego elementu składowego bez  
poprawiania i usuwania istniejących zagrożeń, celów, środków pr oce­
duralnych i specyfikacji funkcji realizujących zabezpieczenia.  
SEC_005 Ścisła zgodność takiego konkretnego celu zabezpieczenia  z odpo­
wiednim profilem zabezpieczenia musi zostać stwierdzona w proce sie 
oceny.  
SEC_006 Poziomem gwarancji dla każdego profilu zabezpieczenia j est poziom 
EAL4 wzmocniony elementami gwarancji ATE_DPT.2 i AVA_VAN.5.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 424  
Dodatek 11  
WSPÓLNE MECHANIZMY ZABEZPIECZENIA  
SPIS TREŚCI  
INFORMACJE OGÓLNE  
CZĘŚĆ A SYSTEM TACHOGRAFU PIERWSZEJ GENERACJI  
1. WPROWADZENIE  
1.1. Odniesienia  
1.2. Oznaczenia i skróty  
2. SYSTEMY I ALGORYTMY KRYPTOGRAFICZNE  
2.1. Systemy kryptograficzne  
2.2. Algorytmy kryptograficzne  
2.2.1 Algorytm RSA  
2.2.2 Algorytm skrótu  
2.2.3 Algorytm szyfrowania danych  
3. KLUCZE I CERTYFIKATY  
3.1. Generowanie i dystrybucja kluczy  
3.1.1 Generowanie i dystrybucja kluczy RSA  
3.1.2 Klucze testowe RSA  
3.1.3 Klucze czujnika ruchu  
3.1.4 Generowanie i dystrybucja kluczy sesji T-DES  
3.2. Klucze  
3.3. Certyfikaty  
3.3.1 Treść certyfikatów  
3.3.2 Wydane certyfikaty  
3.3.3 Weryfikacja i rozpakowanie certyfikatu  
4. MECHANIZM WZAJEMNEGO UWIERZYTELNIENIA  
5. POUFNOŚĆ, INTEGRALNOŚĆ I MECHANIZMY UWIERZY­ 
TELNIANIA PRZESYŁANIA DANYCH MIĘDZY VU 
A KARTAMI  
5.1. Bezpieczna wymiana komunikatów  
5.2. Obsługa błędów w bezpiecznej wymianie komunikatów  
5.3. Algorytm obliczania kryptograficznych sum kontrolnych  
5.4. Algorytm obliczania kryptogramów dla poufnych obiektów dan ych 
6. MECHANIZMY CYFROWEGO PODPISU DLA POBIERANIA 
DANYCH  
6.1. Generowanie podpisu  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 425  
6.2. Weryfikacja podpisu  
CZĘŚĆ B SYSTEM TACHOGRAFU DRUGIEJ GENERACJI  
7. WPROWADZENIE  
7.1. Odniesienia  
7.2. Oznaczenia i skróty  
7.3. Definicje  
8. SYSTEMY I ALGORYTMY KRYPTOGRAFICZNE  
8.1. Systemy kryptograficzne  
8.2. Algorytmy kryptograficzne  
8.2.1 Algorytmy symetryczne  
8.2.2 Algorytmy asymetryczne i standardowe parametry domeny  
8.2.3 Algorytmy skrótu  
8.2.4 Mechanizm szyfrowania  
9. KLUCZE I CERTYFIKATY  
9.1. Pary kluczy asymetrycznych i certyfikaty kluczy publicznyc h 
9.1.1 Uwagi ogólne  
9.1.2 Poziom europejski  
9.1.3 Poziom państwa członkowskiego  
9.1.4 Poziom urządzenia: przyrządy rejestrujące  
9.1.5 Poziom urządzenia: karty do tachografu  
9.1.6 Poziom urządzenia: urządzenia zewnętrzne GNSS  
9.1.7 Przegląd: zastąpienie certyfikatu  
9.2. Klucze symetryczne  
9.2.1 Klucze do zabezpieczania łączności między VU a czujnikiem  ruchu  
9.2.2 Klucze do zabezpieczania łączności DSRC  
9.3. Certyfikaty  
9.3.1 Uwagi ogólne  
9.3.2 Treść certyfikatu  
9.3.3 Składanie wniosków o certyfikaty  
10. WZAJEMNE UWIERZYTELNIANIE I BEZPIECZNA 
WYMIANA KOMUNIKATÓW MIĘDZY VU A KARTĄ  
10.1. Uwagi ogólne  
10.2. Wzajemna weryfikacja łańcucha certyfikatów  
10.2.1 Weryfikacja łańcucha certyfikatów karty przez VU  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 426  
10.2.2 Weryfikacja łańcucha certyfikatów VU przez kartę  
10.3. Uwierzytelnienie VU  
10.4. Uwierzytelnianie chipu i uzgadnianie klucza sesji  
10.5. Bezpieczna wymiana komunikatów  
10.5.1 Uwagi ogólne  
10.5.2 Struktura bezpiecznego komunikatu  
10.5.3 Przerwanie sesji bezpiecznej wymiany komunikatów  
11. POWIĄZANIE, WZAJEMNE UWIERZYTELNIANIE 
I BEZPIECZNA WYMIANA KOMUNIKATÓW MIĘDZY VU 
A URZĄDZENIEM ZEWNĘTRZNYM GNSS  
11.1. Uwagi ogólne  
11.2. Ustanowienie powiązania między VU a urządzeniem zewnętrzn ym 
GNSS  
11.3. Wzajemna weryfikacja łańcucha certyfikatów  
11.3.1 Uwagi ogólne  
11.3.2 Podczas ustanawiania powiązania między VU a EGF  
11.3.3 W czasie normalnej pracy  
11.4. Uwierzytelnienie VU, uwierzytelnienie chipu i uzgodnienie  klucza 
sesji 
11.5. Bezpieczna wymiana komunikatów  
12. PAROWANIE VU Z CZUJNIKIEM RUCHU I ŁĄCZNOŚĆ 
MIĘDZY TYMI URZĄDZENIAMI  
12.1. Uwagi ogólne  
12.2. Parowanie VU z czujnikiem ruchu przy użyciu różnych gener acji 
kluczy  
12.3. Parowanie VU z czujnikiem ruchu i łączność między tymi ur zą­ 
dzeniami z wykorzystaniem AES  
12.4. Parowanie VU z czujnikiem ruchu w przypadku różnych gener acji 
urządzeń  
13. BEZPIECZEŃSTWO ŁĄCZNOŚCI NA ODLEGŁOŚĆ 
W RAMACH DSRC  
13.1. Uwagi ogólne  
13.2. Szyfrowanie ładunku tachografu i generowanie MAC  
13.3. Weryfikacja i odszyfrowywanie ładunku tachografu  
14. PODPISYWANIE POBIERANYCH DANYCH I SPRAWDZANIE 
PODPISÓW  
14.1. Uwagi ogólne  
14.2. Generowanie podpisu  
14.3. Weryfikacja podpisu  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 427  
INFORMACJE OGÓLNE  
W niniejszym dodatku określa się mechanizmy zabezpieczenia zape wniające:  
— wzajemne uwierzytelnienie między różnymi elementami składowym i systemu 
tachografu;  
— poufność, integralność, autentyczność lub niezaprzeczalność d anych przeka­
zywanych między różnymi elementami składowymi systemu tachograf u lub 
pobieranych na zewnętrzne nośniki danych.  
Niniejszy dodatek składa się z dwóch części. W części A opisano  mechanizmy 
zabezpieczenia stosowane w systemie tachografu pierwszej genera cji (tachograf 
cyfrowy). W części B opisano mechanizmy zabezpieczenia stosowan e w systemie 
tachografu drugiej generacji (tachograf inteligentny).  
Mechanizmy opisane w części A niniejszego dodatku stosuje się, jeżeli przynaj­
mniej jeden element składowy systemu tachografu wykorzystywany w procesie 
wzajemnego uwierzytelniania lub przesyłania danych jest urządze niem pierwszej 
generacji.  
Mechanizmy opisane w części B niniejszego dodatku stosuje się, jeżeli obydwa 
elementy składowe systemu tachografu wykorzystywane w procesie wzajemnego 
uwierzytelniania lub przesyłania danych są urządzeniami drugiej  generacji.  
Dodatek 15 zawiera dodatkowe informacje na temat korzystania z elementów 
składowych pierwszej generacji w połączeniu z elementami składo wymi drugiej 
generacji.  
CZĘŚĆ A  
SYSTEM TACHOGRAFU PIERWSZEJ GENERACJI  
1. WPROWADZENIE  
1.1. Odniesienia  
W niniejszym dodatku używa się następujących odniesień:  
SHA-1 Narodowy Instytut Standaryzacji i Technologii (NIST).  
FIPS Publikacja 180-1: Bezpieczny standard skrótu.  
Kwiecień 1995 r.  
PKCS1 RSA Laboratories. PCKS # 1:  Standard szyfrowania 
RSA. Wersja 2.0. Październik 1998 r.  
TDES Narodowy Instytut Standaryzacji i Technologii (NIST).  
FIPS Publikacja 46-3: Symetryczny algorytm krypto ­
graficzny . Projekt 1999 r.  
TDES-OP ANSI X9.52, Tryby pracy algorytmu trzyetapowego 
szyfrowania danych. 1998 r.  
ISO/IEC 7816-4 Technologia informacyjna – Karty identyfikacyjne  –  
Elektroniczne karty stykowe – Część 4: Międzybran­ 
żowe polecenia wymiany informacji. Wydanie 
pierwsze: 1995 r. + zmiana 1: 1997 r.  
ISO/IEC 7816-6 Technologia informacyjna – Karty identyfikacyjne  –  
Elektroniczne karty stykowe – Część 6: Międzybran­ 
żowe elementy danych. Wydanie pierwsze: 1996 r. + 
zmiana 1: 1998 r.  
ISO/IEC 7816-8 Technologia informacyjna – Karty identyfikacyjne  –  
Elektroniczne karty stykowe – Część 8: Międzybran­ 
żowe polecenia związane z bezpieczeństwem. 
Wydanie pierwsze: 1999 r.  
ISO/IEC 9796-2 Technologia informacyjna – Techniki zabezpieczeń  –  
Schematy podpisu cyfrowego z odtwarzaniem wiado­
mości – Część 2: Mechanizmy oparte na faktoryzacji 
liczb całkowitych. Wydanie pierwsze: 1997 r.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 428  
ISO/IEC 9798-3 Technologia informacyjna – Techniki zabezpieczeń  –  
Mechanizmy uwierzytelnienia jednostki – Część 3: 
Uwierzytelnienie jednostki przy użyciu algorytmu 
klucza publicznego. Wydanie drugie: 1998 r.  
ISO 16844-3 Pojazdy drogowe – Systemy tachograficzne – Część 3:  
Interfejs czujnika ruchu.  
1.2. Oznaczenia i skróty  
W niniejszym dodatku używa się następujących oznaczeń i skrótów : 
(K a , K  b , K  c ) wiązka kluczy używanych w algorytmie trzyetapo­
wego szyfrowania danych,  
CA organ certyfikacji  
CAR odniesienie do organu certyfikacji  
CC kryptograficzna suma kontrolna  
CG kryptogram  
CH nagłówek polecenia  
CHA upoważnienie posiadacza certyfikatu  
CHR odniesienie do posiadacza certyfikatu  
D() deszyfracja DES  
DE element danych  
DO obiekt danych  
d klucz prywatny RSA, wykładnik prywatny  
e klucz publiczny RSA, wykładnik publiczny  
E() szyfrowanie DES  
EQT urządzenie  
Hash()  skrót, wartość wyjściowa funkcji skrótu  
Hash  funkcja skrótu  
KID identyfikator klucza  
Km klucz TDES, klucz główny wg normy ISO 16844-3  
Km  VU klucz TDES umieszczony w przyrządzie rejestrującym  
Km  WC klucz TDES umieszczony w kartach warsztatowych  
m reprezentacja komunikatu, liczba całkowita z prze­
działu od 0 do n-1  
n klucze RSA, moduły  
PB bajty wypełnienia  
PI bajt wskaźnik wypełnienia (do zastosowania w krypto­
gramie dla poufności DO)  
PV wartość odkryta  
s reprezentacja podpisu, liczba całkowita z przedziału 
od 0 do n-1  
SSC licznik sekwencji wysyłania  
SM bezpieczna wymiana komunikatów  
TCBC tryb wiązania bloków zaszyfrowanych TDEA  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 429  
TDEA algorytm trzyetapowego szyfrowania danych  
TLV obiekt TLV  
VU przyrząd rejestrujący  
X.C certyfikat użytkownika X wydany przez organ certy­
fikacji  
X.CA organ certyfikacji użytkownika X  
X.CA.PK  o X.C Operacja rozpakowania certyfikatu w celu wyodręb­
nienia klucza publicznego. Jest to operator wrost­
kowy, którego argumentem lewostronnym jest klucz 
publiczny organu certyfikacji, a argumentem prawo­
stronnym jest certyfikat wydany przez ten organ certy­
fikacji. Wynikiem jest klucz publiczny użytkownika 
X, którego certyfikat jest argumentem prawostronnym.  
X.PK klucz publiczny użytkownika X  
X.PK[I] szyfrowanie RSA pewnych informacji kluczem 
publicznym I użytkownika X  
X.SK klucz prywatny RSA użytkownika X  
X.SK[I] szyfrowanie RSA pewnych informacji kluczem 
prywatnym I użytkownika X  
„xx” wartość heksadecymalna  
|| operator konkatenacji  
2. SYSTEMY I ALGORYTMY KRYPTOGRAFICZNE  
2.1. Systemy kryptograficzne  
CSM_001 Przyrządy rejestrujące i karty do tachografu używają kl asycz­
nego systemu kryptograficznego RSA z kluczem publicznym 
do realizowania następujących mechanizmów zabezpieczenia:  
— uwierzytelnienie między przyrządami rejestrującymi 
a kartami,  
— transport kluczy sesji Triple-DES między przyrządami 
rejestrującymi a kartami do tachografu,  
— podpis cyfrowy danych pobieranych z przyrządów rejes­
trujących lub kart do tachografu do zewnętrznych 
nośników.  
CSM_002 Przyrządy rejestrujące i karty do tachografu używają sy met­
rycznego systemu kryptograficznego Triple-DES do zrealizo­
wania mechanizmu zapewniającego integralność danych 
w czasie wymiany danych użytkownika między przyrządami 
rejestrującymi a kartami do tachografu i zapewnienia, 
w stosownych przypadkach, poufności wymiany danych 
między przyrządami rejestrującymi a kartami do tachografu.  
2.2. Algorytmy kryptograficzne  
2.2.1  Algorytm RSA  
CSM_003 Algorytm RSA w pełni definiują następujące relacje:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 430  
X.SK[ m] = s = m d mod n 
X.PK[ s] = m = s e mod n 
Bardziej wyczerpujący opis funkcji RSA można znaleźć 
w odniesieniu [PKCS1]. Wykładnik publiczny, e, dla obliczeń 
RSA jest liczbą całkowitą pomiędzy 3 i n-1 spełniającą gcd(e, 
lcm(p-1, q-1))=1.  
2.2.2  Algorytm skrótu  
CSM_004 Mechanizmy podpisu cyfrowego używają algorytmu skrótu 
SHA-1 zdefiniowanego w odniesieniu [SHA-1].  
2.2.3  Algorytm szyfrowania danych  
CSM_005 Algorytmy oparte na algorytmie DES są używane w trybie 
wiązania bloków zaszyfrowanych.  
3. KLUCZE I CERTYFIKATY  
3.1. Generowanie i dystrybucja kluczy  
3.1.1  Generowanie i dystrybucja kluczy RSA  
CSM_006 Klucze RSA są generowane na trzech hierarchicznych pozi o­
mach funkcjonalnych:  
— poziomie europejskim,  
— poziomie państwa członkowskiego,  
— poziomie urządzenia.  
CSM_007 Na poziomie europejskim generuje się jedną parę kluczy 
europejskich (EUR.SK i EUR.PK). Do poświadczania kluczy 
publicznych państw członkowskich służy europejski klucz 
prywatny. Należy prowadzić rejestry wszystkich certyfikowa­
nych kluczy. Organem odpowiedzialnym za realizację tych 
zadań jest europejski organ certyfikacji, działający z upoważ­
nienia i na odpowiedzialność Komisji Europejskiej.  
CSM_008 Na poziomie państwa członkowskiego generuje się parę 
kluczy państwa członkowskiego (MS.SK i MS.PK). Klucze 
publiczne państwa członkowskiego certyfikuje europejski 
organ certyfikacji. Klucza prywatnego państwa członkow­
skiego używa się do certyfikowania kluczy publicznych 
umieszczanych w urządzeniach (w przyrządzie rejestrującym 
lub karcie do tachografu). Należy prowadzić rejestry wszyst­
kich certyfikowanych kluczy publicznych wraz z identyfikacją 
urządzeń, dla których są przewidziane. Organem realizującym 
te zadania jest organ certyfikacji państwa członkowskiego. 
Państwo członkowskie może okresowo zmieniać swoją parę 
kluczy.  
CSM_009 Na poziomie urządzenia generuje się jedną parę kluczy 
(EQT.SK i EQT.PK), którą umieszcza się w każdym urzą­
dzeniu. Klucze publiczne urządzenia certyfikuje organ certy­
fikacji państwa członkowskiego. Zadania te mogą realizować 
producenci urządzeń, jednostki personalizujące urządzenia lub 
organy państwa członkowskiego. Wspomnianej pary kluczy 
używa się do uwierzytelniania, składania podpisu cyfrowego 
oraz świadczenia usług w zakresie szyfrowania.  
CSM_010 W czasie generowania, ewentualnego transportu i przecho wy­
wania należy zachować poufność kluczy prywatnych.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 431  
Na poniższym rysunku zobrazowano przepływ danych w tym 
procesie:
  
3.1.2  Klucze testowe RSA  
CSM_011 Do celów testowania urządzeń (włącznie z badaniami inte ro­
peracyjności) europejski organ certyfikacji generuje różniące 
się pary kluczy, jedną europejską parę kluczy testowych 
i przynajmniej dwie pary kluczy testowych państwa człon­
kowskiego, których klucze publiczne są certyfikowane euro­
pejskim prywatnym kluczem testowym. Producenci umiesz­
czają w urządzeniach przechodzących testy homologacji typu 
klucze testowe certyfikowane jednym z tych kluczy testowych 
państwa członkowskiego.  
3.1.3  Klucze czujnika ruchu  
W czasie generowania, ewentualnego transportu i przechowywania 
w należyty sposób zachowuje się poufność trzech kluczy Triple D ES 
opisanych poniżej.  
W celu obsługi elementów składowych tachografu zgodnych z normą  
ISO 16844 europejski organ certyfikacji i organ certyfikacji pa ństwa 
członkowskiego dodatkowo zapewniają, co następuje:  
CSM_036 europejski organ certyfikacji generuje KmVU i KmWC, dwa  
niezależne i unikatowe klucze Triple DES, oraz generuje Km 
jako:  Km = Km  VU XOR KM  WC . Europejski organ certyfikacji 
przesyła te klucze, z zachowaniem stosownych procedur bezpie­
czeństwa, organom certyfikacji państw członkowskich na ich 
wniosek.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 432  
CSM_037 Organy certyfikacji państw członkowskich:  
— używają Km do szyfrowania danych czujnika ruchu 
wymaganych przez producentów czujników ruchu (dane, 
które mają być zaszyfrowane kluczem Km, są określone 
w normie ISO 16844-3),  
— przesyłają klucz Km  VU producentom przyrządów rejestru­
jących z zachowaniem należytych procedur bezpieczeń­
stwa w celu umieszczenia w przyrządach rejestrujących,  
— zapewniają umieszczenie klucza Km  WC we wszystkich kartach 
warsztatowych
  
w pliku elementarnym
  
w czasie personalizacji kart.  
3.1.4  Generowanie i dystrybucja kluczy sesji T-DES  
CSM_012 W ramach procesu wzajemnego uwierzytelnienia przyrządy 
rejestrujące i karty do tachografu generują i wymieniają 
niezbędne dane w celu uzyskania wspólnego klucza sesji 
Triple DES. Poufność tej wymiany informacji jest chroniona 
mechanizmem kryptograficznym RSA.  
CSM_013 Klucz ten stosuje się we wszystkich późniejszych czynno ­ 
ściach kryptograficznych, używając bezpiecznej wymiany 
komunikatów. Ważność tego klucza wygasa z końcem sesji 
(wyjęcie karty lub wyzerowanie karty) lub po 240 użyciach 
(jedno użycie klucza = jedno polecenie używające 
bezpiecznej wymiany komunikatów wysłane do karty i zwią­
zana z nim odpowiedź).  
3.2. Klucze  
CSM_014 Długości kluczy RSA (niezależnie od poziomu) są następu ­
jące: moduł  n 1 024 bity, wykładnik publiczny  e maksy­
malnie 64 bity, wykładnik prywatny  d 1 024 bity.  
CSM_015 Klucze Triple DES mają postać (K  a , K b , K a ), gdzie K  a i K b są 
niezależnymi 64-bitowymi kluczami. Nie dopuszcza się 
możliwości ustawiania jakichkolwiek bitów wykrywania 
błędu parzystości.  
3.3. Certyfikaty  
CSM_016 Certyfikaty klucza publicznego RSA są certyfikatami „ni esa­
moopisującymi”, weryfikowalnymi przez kartę (CVC) (zob. 
norma ISO/IEC 7816-8).  
3.3.1  Treść certyfikatów  
CSM_017 Certyfikaty klucza publicznego RSA zawierają następując e 
dane w określonym poniżej porządku:  
Dane  Format  Bajty  Opis  
CPI INTEGER  1  Identyfikator profilu certy­
fikatu („01” dla tej wersji)  
CAR  OCTET 
STRING  8 Odniesienie do organu 
certyfikacji  
CHA  OCTET 
STRING  7 upoważnienie posiadacza 
certyfikatu  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 433  
Dane  Format  Bajty  Opis  
EOV  TimeReal  4  Koniec terminu ważności 
certyfikatu. Opcjonalny, 
gdy nieużywany, wypeł­
niony „FF”.  
CHR  OCTET 
STRING  8 odniesienie do posiadacza 
certyfikatu  
n OCTET 
STRING  128 Klucz publiczny (moduł)  
e OCTET 
STRING  8 Klucz publiczny 
(wykładnik publiczny)  
164 
Uwagi:  
1. „Identyfikator profilu certyfikatu” (CPI) wyznacza dokładną strukturę 
certyfikatu uwierzytelniania. Można go używać jako wewnętrznego  
identyfikatora urządzenia w odpowiednim wykazie nagłówków, 
który opisuje konkatenację elementów danych w certyfikacie.  
Wykaz nagłówków związanych z treścią certyfikatu jest następują cy: 
„4D”  „16”  „5F 
29” „01”  „42”  „08”  „5F 
4B” „07”  „5F 
24” „04”  „5F 
20” „08”  „7F 
49” „05”  „81”  „81 
80” „82”  „08”
 Znacznik rozszerzonego wykazu nagłówków  
Długość wykazu nagłówków  
Znacznik CPI  
Długość CPI  
Znacznik CAR  
Długość CAR  
Znacznik CHA  
Długość CHA  
Znacznik EOV  
Długość EOV  
Znacznik CHR  
Długość CHR  
Znacznik klucza publicznego (zbudowany)  
Długość następnych DO  
Znacznik modułu  
Długość modułu  
Znacznik wykładnika publicznego  
Długość wykładnika publicznego 
2. „Odniesienie do organu certyfikacji” (CAR) ma na celu identy fikację 
organu certyfikacji wydającego certyfikat, w taki sposób, że te n 
element danych może być użyty jednocześnie jako identyfikator 
klucza organu w celu odniesienia do klucza publicznego organu c erty­
fikacji (kodowanie — patrz Identyfikator klucza poniżej).  
3. „Upoważnienie posiadacza certyfikatu” (CHA) służy do identyf iko­
wania praw posiadacza certyfikatu. Składa się ono z ID aplikacj i 
tachograficznej i typu urządzenia, dla którego certyfikat jest przezna­
czony (zgodnie z elementem danych
  , „00” dla 
państwa członkowskiego).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 434  
4. „Odniesienie do posiadacza certyfikatu” (CHR) ma na celu jed no­
znaczną identyfikację posiadacza certyfikatu, w taki sposób, że  ten 
element danych może być użyty jednocześnie jako identyfikator 
klucza podmiotu w celu odniesienia do posiadacza certyfikatu kl ucza 
publicznego.  
5. Identyfikatory kluczy jednoznacznie identyfikują posiadacza certyfi­
katu lub organy certyfikacji. Są one kodowane w następujący spo sób: 
5.1. Urządzenie (VU lub karta): 
Dane  Numer 
seryjny 
urządzenia  Data  Typ  Producent  
Długość  4 bajty  2 bajty  1 bajt  1 bajt  
Wartość  liczba 
całkowita  kodowanie BCD 
mm rr  specyficzny dla 
producenta  kod producenta  
W przypadku VU producent, gdy wnioskuje o certyfikaty, może, 
ale nie musi, znać identyfikację urządzenia, w którym mają być 
umieszczone klucze.  
W pierwszym przypadku producent wysyła identyfikację urzą­
dzenia z kluczem publicznym do organu swojego państwa człon­
kowskiego w celu certyfikacji. W tym przypadku certyfikat 
będzie zawierał identyfikację urządzenia i producent musi 
zapewnić umieszczenie kluczy i certyfikatu w przewidzianym 
urządzeniu. Identyfikator klucza ma przedstawioną powyżej 
postać.  
W drugim przypadku producent musi tylko jednoznacznie ziden­
tyfikować każdy wniosek o certyfikat i wysłać tę identyfikację 
z kluczem publicznym do organu swojego państwa członkow­
skiego w celu certyfikacji. W tym przypadku certyfikat będzie 
zawierał wnioskowaną identyfikację. Po zainstalowaniu klucza 
w urządzeniu producent musi zawiadomić zwrotnie organ 
swojego państwa członkowskiego o przyporządkowaniu klucza 
do urządzenia (tj. podać identyfikację wniosku o certyfikat, id en­
tyfikację urządzenia). Identyfikator klucza ma następującą post ać: 
Dane  Numer 
seryjny 
wniosku 
ocertyfikat  Data  Typ  Producent  
Długość  4 bajty  2 bajty  1 bajt  1 bajt  
Wartość  liczba 
całkowita  kodowanie BCD 
mm rr  „FF”  kod producenta  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 435  
5.2. Organ certyfikacji: 
Dane  Identyfikacja 
organu  Numer 
seryjny klucza  Dodatkowe 
informacje  Identyfikator  
Długość  4 bajty  1 bajt  2 bajty  1 bajt  
Wartość  1-bajtowy kod 
numeryczny 
państwa 
3-bajtowy kod 
alfanumeryczny 
państwa  liczba całko­
wita dodatkowe 
kodowanie 
(specyficzne 
dla CA) 
„FF FF”, gdy 
nie jest 
używany  „01”  
Numer seryjny klucza służy do rozróżniania różnych kluczy 
państwa członkowskiego w przypadku zmiany klucza.  
6. Weryfikatory certyfikatów wiedzą niejawnie o tym, iż certyfi kowany 
klucz publiczny jest kluczem RSA właściwym do uwierzytelnienia,  
weryfikacji podpisu cyfrowego i szyfrowania dla poufnych usług 
(certyfikat nie zawiera identyfikatora obiektu, który by to okr eślał).  
3.3.2  Wydane certyfikaty  
CSM_018 Wydany certyfikat jest podpisem cyfrowym z częściowym 
odzyskiwaniem treści certyfikatu zgodnie z normą ISO/IEC 
9796-2 (z wyjątkiem jego załącznika A4) z dołączonym 
„odniesieniem do organu certyfikacji”.  
X.C = X.CA.SK[„6A” || C  r || Hash  (Cc) || „BC”] || C  n || X.CAR 
z treścią 
certyfikatu 
= Cc =  C r || C  n 
106 bajtów  58 bajtów  
Uwagi:  
1. Ten certyfikat zawiera 194 bajty.  
2. CAR, utajniony podpisem, jest również dołączony do podpisu, 
w związku z czym do weryfikacji certyfikatu można wybrać klucz 
publiczny organu certyfikacji.  
3. Weryfikator certyfikatu zna niejawnie algorytm użyty przez o rgan 
certyfikacji do podpisania certyfikatu.  
4. Wykaz nagłówków związanych z wydanym certyfikatem jest nastę ­
pujący: 
„7F 21”  „09”  „5F 37”  „81 80”  „5F 38”  „3A”  „42”  „08”
 Znacznik certyfikatu 
CV (zbudowany)  
Długość następnych DO  
Znacznik podpisu  
Długość podpisu  
Znacznik reszty  
Długość reszty  
Znacznik CAR  
Długość CAR ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 436  
3.3.3  Weryfikacja i rozpakowanie certyfikatu  
Weryfikacja i rozpakowanie certyfikatu obejmuje sprawdzenie pod pisu 
zgodnie z normą ISO/IEC 9796-2, odzyskanie treści certyfikatu i  klucza 
publicznego: X.PK = X.CA.PK  o X.C. oraz sprawdzenie ważności 
certyfikatu.  
CSM_019 Procedura ta składa się z następujących etapów:  
weryfikacja podpisu i odzyskanie treści: 
— z X.C odzyskaj Sign, C  n „i CAR”:  X.C =  Sign  | |  C  n „ | |  CAR”  
128 bajtów  58 bajtów  8 bajtów  
— z CAR' wybierz odpowiednio klucz publiczny organu 
certyfikacji (jeżeli nie uzyskano go wcześniej innymi 
środkami)  
— odtwórz Sign z klucza publicznego CA: Sr'= X.CA.PK 
[Sign]  
— sprawdź, czy Sr' zaczyna się od „6A” i kończy na „BC” 
— oblicz C  r ' i H' z: Sr' =  „6A”  | | C  r ' | |  H '  | |  „BC”  
106 bajtów  20 bajtów  
— odzyskaj treść certyfikatu C' = C  r „|| C  n ” 
— sprawdź, czy  Hash  (C') = H'  
Jeżeli rezultat kontroli będzie prawidłowy, certyfikat jest 
prawdziwy, a jego treść to C'.  
Sprawdzenie ważności z C':  
— w stosownych przypadkach sprawdź koniec daty 
ważności,  
odzyskaj i zachowaj klucz publiczny, identyfikator klucza, 
upoważnienie posiadacza certyfikatu i koniec ważności certy­
fikatu z C':  
— X.PK =  n | | e 
— X.KID = CHR  
— X.CHA = CHA  
— X.EOV = EOV  
4. MECHANIZM WZAJEMNEGO UWIERZYTELNIENIA  
Wzajemne uwierzytelnienie między kartami a VU odbywa się według  
opisanej poniżej zasady.  
Każda strona wykazuje drugiej, że posiada ważną parę kluczy, z której 
klucz publiczny jest certyfikowany przez organ certyfikacji pań stwa 
członkowskiego, który uzyskał certyfikat wydany przez europejsk i 
organ certyfikacji.  
Wykazanie polega na podpisaniu kluczem prywatnym losowej liczby  
przysłanej przez drugą stronę, która musi odzyskać tę liczbę pr zy spraw­
dzaniu tego podpisu.  
Mechanizm zostaje uruchomiony przez VU w chwili włożenia karty.  
Procedura rozpoczyna się od wymiany certyfikatów i rozpakowania  
kluczy, a kończy ustaleniem klucza sesji.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 437  
CSM_020 W procesie tym stosuje się następujący protokół (strzał ki 
oznaczają polecenia i wymianę danych (zob. dodatek 2)):
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 438
  
▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 439  
5. POUFNOŚĆ, INTEGRALNOŚĆ I MECHANIZMY UWIERZYTEL­
NIANIA PRZESYŁANIA DANYCH MIĘDZY VU A KARTAMI  
5.1. Bezpieczna wymiana komunikatów  
CSM_021 Bezpieczna wymiana komunikatów chroni integralność prze ­
syłania danych między VU a kartami zgodnie z odniesieniami 
[ISO/IEC 7816-4] i [ISO/IEC 7816-8].  
CSM_022 W przypadku konieczności zapewnienia ochrony przesyła­
nych danych do obiektów danych wysyłanych w poleceniu 
lub odpowiedzi dołącza się obiekt danych z kryptograficzną 
sumą kontrolną. Kryptograficzną sumę kontrolną weryfikuje 
odbiorca.  
CSM_023 Kryptograficzna suma kontrolna danych wysyłanych w pole ­
ceniu integruje nagłówek polecenia i wszystkie wysyłane 
obiekty danych (=>CLA = „0C”, a wszystkie obiekty danych 
są ograniczone znacznikami, w których b1=1).  
CSM_024 Bajty stanu odpowiedzi-informacji są chronione kryptogr a­
ficzną sumą kontrolną, jeżeli odpowiedź nie zawiera żadnego 
pola danych.  
CSM_025 Kryptograficzne sumy kontrolne składają się z 4 bajtów.  
W związku z tym struktura poleceń i odpowiedzi w ramach 
bezpiecznej wymiany komunikatów przedstawia się w nastę­
pujący sposób:  
Wykorzystywane DO stanowią częściowy zbiór DO stosowa­
nych w ramach bezpiecznej wymiany komunikatów, o których 
mowa w normie ISO/IEC 7816-4:  
Znacznik  Mnemonik  Znaczenie  
„81”  T  PV Odkryta wartość danych niekodowanych w BER- 
TLV (chroniona przez kryptograficzną sumę 
kontrolną)  
„97”  T  LE Wartość Le w niezabezpieczonym poleceniu (chro­
niona przez kryptograficzną sumę kontrolną)  
„99”  T  SW Stan-Info (chronione przez kryptograficzną sumę 
kontrolną)  
„8E”  T  CC Kryptograficzna suma kontrolna  
„87”  T  PI CG  Bajt wskaźnika wypełnienia || Kryptogram (odkryta 
wartość niekodowana w BER-TLV)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 440  
Dla danej pary niezabezpieczone polecenie – odpowiedź:  
Nagłówek polecenia  Treść polecenia  
CLA  INS  P 1  P 2  [Pole L  c ] [Pole danych]  [Pole L  e ] 
cztery bajty  Bajty L, oznaczone od B  1 do B  L 
Treść odpowiedzi  Stopka odpowiedzi  
[Pole danych]  SW1  SW2  
Bajty danych L  r dwa bajty  
Odpowiadająca para zabezpieczone polecenie – odpowiedź 
jest następująca:  
Zabezpieczone polecenie:  
Nagłówek polecenia (CH)  Treść polecenia  
CLA  INS  P 1  P 2  [Nowe pole L  c ] [Nowe pole danych]  [Nowe 
pole L  e ] 
„OC”  Długość nowego 
pola danych  T PV L PV PV T  LE L LE L e T CC L CC CC „00”  
„81”  L  c pole danych  „97”  „01”  L  e „8E”  „04”  C C  
Dane zintegrowane w sumie kontrolnej = CH || PB || T  PV || 
L PV || PV || T  LE || L  LE || L  e || PB  
PB = bajty wypełnienia (80 .. 00) zgodnie z normami 
ISO-IEC 7816-4 i ISO 9797 metoda 2.  
Obiekty DO PV i LE występują tylko wtedy, gdy są pewne 
odpowiadające im dane w niezabezpieczonym poleceniu.  
Zabezpieczona odpowiedź:  
1. Przypadek, gdy pole danych odpowiedzi nie jest puste 
i nie wymaga ochrony poufności:  
Treść odpowiedzi  Stopka odpowiedzi  
[Nowe pole danych]  nowe SW1 SW2  
T PV L PV PV T  CC L CC CC 
„81”  L  r pole danych  „8E”  „04”  C C  
Dane zintegrowane w sumie kontrolnej = T  PV || L  PV || PV 
|| PB  
2. Przypadek, gdy pole danych odpowiedzi nie jest puste 
i wymaga ochrony poufności:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 441  
Treść odpowiedzi  Stopka odpowiedzi  
[Nowe pole danych]  nowe SW1 SW2  
T PI CG  L PI 
CG PI CG  T  CC L CC CC 
„87”  PI || CG  „8E”  „04”  C C  
Dane przenoszone przez CG: dane niekodowane w BER- 
TLV i bajty wypełnienia.  
Dane zintegrowane w sumie kontrolnej = T  PI CG  || L PI CG  || 
PI CG || PB  
3. Przypadek, gdy pole danych odpowiedzi jest puste:  
Treść odpowiedzi  Stopka odpowiedzi  
[Nowe pole danych]  nowe SW1 SW2  
T SW L SW SW T  CC L CC CC 
„99”  „02”  nowe SW1 SW2  „8E”  „04”  C C  
Dane zintegrowane w sumie kontrolnej = T  SW || L SW || SW 
|| PB  
5.2. Obsługa błędów w bezpiecznej wymianie komunikatów  
CSM_026 Gdy karta do tachografu wykryje błąd SM podczas interpr e­
towania polecenia, w odpowiedzi musi zwrócić bajty stanu 
bez SM. Zgodnie z normą ISO/IEC 7816-4 błędy SM wska­
zuje się następującymi bajtami stanu:  
„66 88”: błąd weryfikacji kryptograficznej sumy kontrolnej,  
„69 87”: brak oczekiwanych obiektów danych SM,  
„69 88”: nieprawidłowe obiekty danych SM.  
CSM_027 W przypadku gdy karta do tachografu zwraca bajty stanu bez 
obiektów danych SM lub z błędnym obiektem danych SM, 
VU musi przerwać sesję.  
5.3. Algorytm obliczania kryptograficznych sum kontrolnych  
CSM_028 Kryptograficzne sumy kontrolne tworzy się za pomocą jed no­
kierunkowej funkcji skrótu MAC zgodnie z normą ANSI 
X9.19 z DES:  
— etap początkowy: początkowy blok kontrolny y0 jest 
E(Ka, SSC),  
— etap sekwencyjny: bloki kontrolne y1,…, yn oblicza się 
za pomocą Ka,  
— etap końcowy: kryptograficzną sumę kontrolną oblicza się 
z ostatniego bloku yn jako: E(Ka, D(Kb, yn)),  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 442  
gdzie E() oznacza szyfrowanie z DES, a D() oznacza deszyf­
rowanie z DES.  
Cztery najbardziej znaczące bajty kryptograficznej sumy 
kontrolnej są przesyłane.  
CSM_029 Licznik sekwencji wysyłania (SSC) jest inicjowany podcz as 
procedury uzgadniania klucza:  
początkowy SSC: Rnd3 (4 najmniej znaczące bajty) || Rnd1 
(4 najmniej znaczące bajty).  
CSM_030 Licznik SSC zwiększa się za każdym razem o 1 przed obli ­
czeniem MAC (tj. SSC dla pierwszego polecenia będzie 
początkowy SSC + 1, SSC dla pierwszej odpowiedzi będzie 
początkowy SSC + 2).  
Na poniższym rysunku pokazano obliczenie skrótu MAC:
  
5.4. Algorytm obliczania kryptogramów dla poufnych obiektów danych  
CSM_031 Kryptogramy oblicza się za pomocą TDEA w trybie pracy 
TCBC zgodnie z odniesieniami (TDES) i (TDES-OP) 
i wektorem zerowym jako blokiem wartości początkowych.  
Na poniższym rysunku pokazano zastosowanie kluczy 
w TDES:
  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 443  
6. MECHANIZMY CYFROWEGO PODPISU DLA POBIERANIA 
DANYCH  
CSM_032 Inteligentne urządzenie dedykowane (IDE) przechowuje da ne 
otrzymane z urządzenia (VU lub karty) podczas jednej sesji 
pobierania w jednym fizycznym pliku danych. Plik ten musi 
zawierać certyfikaty MSi.C i EQT.C. Plik zawiera podpisy 
cyfrowe bloków danych zgodnie z opisem znajdującym się 
w dodatku 7 Protokoły pobierania danych.  
CSM_033 Podpisy cyfrowe pobranych danych korzystają ze schematu  
podpisu cyfrowego z dodatkiem, przy czym, w razie 
potrzeby, pobrane dane można odczytać bez deszyfrowania.  
6.1. Generowanie podpisu  
CSM_034 Urządzenie generuje podpis danych zgodnie ze schematem 
podpisu z dodatkiem zdefiniowanym w odniesieniu [PKCS1] 
z funkcją skrótu SHA-1:  
Podpis = EQT.SK[„00” || „01” ||  PS || „00” || DER(SHA- 
1(Data))]  
PS = Wypełnienie ciągiem oktetów o wartości „FF” do 
długości 128.  
DER(SHA-1( M)) to kodowanie identyfikatora algorytmu dla 
funkcji skrótu, a wartość skrótu jest wartością w ASN.1 typu 
DigestInfo (wyróżnione reguły kodowania):  
„30”||„21”||„30”||„09”||„06”||„05”||„2B”||„0E”||„03”||„02”||„1A ”|| 
„05”||„00”||„04”||„14”||wartość skrótu.  
6.2. Weryfikacja podpisu  
CSM_035 Weryfikacja podpisu danych dla pobranych danych odbywa 
się zgodnie ze schematem podpisu z dodatkiem zdefinio­
wanym w odniesieniu (PKCS1) z funkcją skrótu SHA-1.  
Europejski klucz publiczny EUR.PK musi być niezależnie 
znany (i zaufany) przez weryfikatora.  
Na schemacie poniżej zilustrowano protokół przenoszenia 
IDE, z którego może korzystać karta kontrolna przy spraw­
dzaniu integralności danych pobranych i zapisanych na 
zewnętrznym nośniku danych (ESM). Karta kontrolna służy 
do deszyfrowania podpisów cyfrowych. W tym przypadku ta 
funkcja nie musi być zaimplementowana w IDE.  
Urządzenie, które pobiera i podpisuje dane przeznaczone do 
analizowania, oznaczono EQT.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 444
  
CZĘŚĆ B  
SYSTEM TACHOGRAFU DRUGIEJ GENERACJI  
7. WPROWADZENIE  
7.1. Odniesienia  
W tej części dodatku używa się następujących odniesień:  
AES Narodowy Instytut Standaryzacji i Technologii (NIST), 
FIPS Publikacja 197: Symetryczny szyfr blokowy (AES), 
26 listopada 2001 r.  
DSS Narodowy Instytut Standaryzacji i Technologii (NIST), 
FIPS Publikacja 186-4: Standard podpisu cyfrowego 
(DSS), lipiec 2013 r.  
ISO 7816-4 ISO/IEC 7816-4, Karty identyfikacyjne – Karty elektr o­
niczne – Część 4: Organizacja, zabezpieczenia i polecenia 
wymiany. Wydanie trzecie 2013-04-15  
ISO 7816-8 ISO/IEC 7816-8, Karty identyfikacyjne – Karty elektr o­
niczne – Część 8: Polecenia operacji zabezpieczających. 
Wydanie drugie, 2004-06-01  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 445  
ISO 8825-1 ISO/I EC 8825- 1 Technologia informacyjna – Reguły kod o­
wania ASN.1: Specyfikacja podstawowych reguł kodowania 
(BER), kanonicznych reguł kodowania (CER) i wyróżnio­
nych reguł kodowania (DER). Wydanie czwarte, 2008-12-15.  
ISO 9797-1 ISO/IEC 9797-1, Technologia informacyjna – Techniki 
zabezpieczeń – Kody uwierzytelniania komunikatów 
(MAC) – Część 1: Mechanizmy stosujące szyfr blokowy. 
Wydanie drugie, 2011-03-01  
ISO 10116 ISO/IEC 10116, Technologia informacyjna – Techniki 
zabezpieczeń – Tryby pracy algorytmu szyfrowania 
bloków n-bitowych. Wydanie trzecie, 2006-02-01  
ISO 16844-3 ISO 16844-3, Pojazdy drogowe – Systemy tachograficz ne 
– Część 3: Interfejs czujnika ruchu. Wydanie pierwsze 
z 2004 r., w tym sprostowanie techniczne 1 z 2006 r.  
RFC 5480 Kryptografia oparta na krzywej eliptycznej – Informacj e 
na temat klucza publicznego podmiotu, marzec 2009 r.  
RFC 5639 Kryptografia oparta na krzywej eliptycznej (ECC) – Sta n­
dardowe krzywe Brainpool i generowanie krzywych, 
2010 r.  
RFC 5869 Funkcja wyprowadzania klucza przez wyodrębnianie i roz wi­
janie oparta na algorytmie HMAC (HKDF), maj 2010 r.  
SHS Narodowy Instytut Standary zacji i Technologii (NIST), FIPS 
Publikacja 180-4: Bezpieczny standard skrótu, marzec 2012 r.  
SP 800-38B Narodowy Instytut Standaryzacji i Technologii (NIST) , 
Specjalna publikacja 800-38B: Zalecenie dotyczące trybów 
pracy szyfru blokowego: tryb uwierzytelniania CMAC, 
2005 r.  
TR-03111 Wytyczne techniczne BSI TR-03111, Kryptografia oparta 
na krzywej eliptycznej, wersja 2.00, 2012-06-28  
7.2. Oznaczenia i skróty  
W niniejszym dodatku używa się następujących oznaczeń i skrótów : 
AES symetryczny szyfr blokowy  
CA organ certyfikacji  
CAR odniesienie do organu certyfikacji  
CBC tryb wiązania bloków zaszyfrowanych (tryb pracy)  
CH nagłówek polecenia  
CHA upoważnienie posiadacza certyfikatu  
CHR odniesienie do posiadacza certyfikatu  
CV wektor stały  
DER wyróżnione reguły kodowania  
DO obiekt danych  
DSRC dedykowana łączność krótkiego zasięgu  
ECC kryptografia oparta na krzywej eliptycznej  
ECDSA algorytm podpisu cyfrowego krzywej eliptycznej  
ECDH krzywa eliptyczna Diffiego-Hellmana (algorytm uzgad­
niania klucza)  
EGF urządzenie zewnętrzne GNSS  
EQT urządzenia  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 446  
IDE inteligentne urządzenie dedykowane  
K M klucz główny czujnika ruchu umożliwiający sparowanie 
przyrządu rejestrującego z czujnikiem ruchu  
K M-VU  klucz umieszczony w przyrządach rejestrujących, umożli­
wiający VU wyprowadzenie klucza głównego czujnika 
ruchu, jeżeli karta warsztatowa została włożona do VU  
K M-WC  klucz umieszczony w kartach warsztatowych, umożliwia­
jący VU wyprowadzenie klucza głównego czujnika ruchu, 
jeżeli karta warsztatowa została włożona do VU  
MAC kod uwierzytelniania komunikatów  
MoS czujnik ruchu  
MSB najbardziej znaczący bit  
PKI infrastruktura klucza publicznego  
RCF urządzenie do łączności na odległość  
SSC licznik sekwencji wysyłania  
SM bezpieczna wymiana komunikatów  
TDES potrójny algorytm DES  
TLV obiekt TLV (Tag-Length-Value)  
VU przyrząd rejestrujący  
X.C certyfikat klucza publicznego użytkownika X  
X.CA organ certyfikacji, który wydał certyfikat użytkownika X  
X.CAR odniesienie do organu certyfikacji, o którym mowa w certy ­
fikacie użytkownika X  
X.CHR odniesienie do posiadacza certyfikatu, o którym mowa 
w certyfikacie użytkownika X  
X.PK klucz publiczny użytkownika X  
X.SK klucz prywatny użytkownika X  
X.PK  eph efemeryczny klucz publiczny użytkownika X  
X.SK  eph efemeryczny klucz prywatny użytkownika X  
„xx” wartość heksadecymalna  
|| operator konkatenacji  
7.3. Definicje  
Definicje terminów stosowanych w niniejszym dodatku włączono do  
sekcji I załącznika 1C.  
8. SYSTEMY I ALGORYTMY KRYPTOGRAFICZNE  
8.1. Systemy kryptograficzne  
CSM_38 Przyrządy rejestrujące i karty do tachografu używają 
systemu kryptograficznego opartego na krzywej eliptycznej 
z kluczem publicznym do zapewniania następujących 
usług zabezpieczających:  
— wzajemne uwierzytelnienie między przyrządem rejes­
trującym a kartą,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 447  
— zgodność kluczy sesji AES między przyrządem rejes­
trującym a kartą,  
— zapewnienie autentyczności, integralności i niezaprze­
czalności danych pobranych z przyrządów rejestrują­
cych lub kart do tachografu do zewnętrznych 
nośników.  
CSM_39 Przyrządy rejestrujące i zewnętrzne urządzenia GNSS 
używają systemu kryptograficznego opartego na krzywej 
eliptycznej z kluczem publicznym do zapewniania nastę­
pujących usług zabezpieczających:  
— powiązanie między przyrządem rejestrującym a urzą­
dzeniem zewnętrznym GNSS,  
— wzajemne uwierzytelnienie między przyrządem rejes­
trującym a urządzeniem zewnętrznym GNSS,  
— zgodność klucza sesji AES między przyrządem rejes­
trującym a urządzeniem zewnętrznym GNSS.  
CSM_40 Przyrządy rejestrujące i karty do tachografu używają 
symetrycznego systemu kryptograficznego opartego na 
AES do zapewniania następujących usług zabezpieczają­
cych:  
— zapewnienie autentyczności i integralności danych 
wymienianych między przyrządem rejestrującym 
a kartą do tachografu,  
— w stosownych przypadkach zapewnienie poufności 
danych wymienianych między przyrządem rejestru­
jącym a kartą do tachografu.  
CSM_41 Przyrządy rejestrujące i urządzenia zewnętrzne GNSS 
używają symetrycznego systemu kryptograficznego opar­
tego na AES do zapewniania następujących usług zabez­
pieczających:  
— zapewnienie autentyczności i integralności danych 
wymienianych między przyrządem rejestrującym 
a urządzeniem zewnętrznym GNSS.  
CSM_42 Przyrządy rejestrujące i czujniki ruchu używają symetryc z­
nego systemu kryptograficznego opartego na AES do 
zapewniania następujących usług zabezpieczających:  
— sparowanie przyrządu rejestrującego z czujnikiem 
ruchu,  
— wzajemne uwierzytelnienie między przyrządem rejes­
trującym a czujnikiem ruchu,  
— zapewnienie poufności danych wymienianych między 
przyrządem rejestrującym a czujnikiem ruchu.  
CSM_43 Przyrządy rejestrujące i karty kontrolne używają symet­
rycznego systemu kryptograficznego opartego na AES do 
zapewniania następujących usług zabezpieczających na 
interfejsie łączności na odległość:  
— zapewnienie poufności, autentyczności i integralności 
danych przekazywanych z przyrządu rejestrującego 
do karty kontrolnej.  
Uwagi  
— Ściśle rzecz ujmując, dane przekazywane z przyrządu 
rejestrującego do zdalnego interrogatora pod nadzorem 
funkcjonariusza służb kontrolnych, za pomocą urzą­
dzenia do łączności na odległość, które może znaj­
dować się wewnątrz lub na zewnątrz VU, zob. dodatek 
14. Zdalny interrogator wysyła jednak otrzymane dane  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 448  
do karty kontrolnej w celu deszyfrowania i potwier­
dzenia autentyczności. Z punktu widzenia bezpieczeń­
stwa urządzenie do łączności na odległość i zdalny 
interrogator cechują się pełną przejrzystością.  
— Karta warsztatowa zapewnia interfejsowi DSRC takie 
same usługi zabezpieczające jak karta kontrolna. 
Dzięki temu warsztat może zatwierdzać prawidłowe 
funkcjonowanie interfejsu łączności na odległość VU, 
z uwzględnieniem bezpieczeństwa. Więcej informacji 
można znaleźć w sekcji 9.2.2.  
8.2. Algorytmy kryptograficzne  
8.2.1  Algorytmy symetryczne  
CSM_44 Przyrządy rejestrujące, karty do tachografu, czujniki ru chu 
i urządzenia zewnętrzne GNSS obsługują algorytm AES, 
jak określono w [AES], o długościach klucza wynoszących 
128, 192 i 256 bitów.  
8.2.2  Algorytmy asymetryczne i standardowe parametry domeny  
CSM_45 Przyrządy rejestrujące, karty do tachografu i urządzenia  
zewnętrzne GNSS obsługują kryptografię opartą na 
krzywej eliptycznej z kluczami o wielkości 256, 384 
i 512/521 bitów.  
CSM_46 Przyrządy rejestrujące, karty do tachografu i urządzenia  
zewnętrzne GNSS obsługują algorytm podpisywania 
ECDSA, jak określono w [DSS].  
CSM_47 Przyrządy rejestrujące, karty do tachografu i urządzenia  
zewnętrzne GNSS obsługują algorytm uzgadniania klucza 
ECKA-EG, jak określono w [TR 03111].  
CSM_48 Przyrządy rejestrujące, karty do tachografu i urządzenia  
zewnętrzne GNSS obsługują wszystkie standardowe para­
metry domeny określone w tabeli 1 poniżej w odniesieniu 
do kryptografii opartej na krzywej eliptycznej.  
Tabela 1  
Standardowe parametry domeny  
Nazwa  Wielkość (bity)  Odniesienie  Identyfikator obiektu  
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 — PL — 21.08.2023 — 003.001 — 449  
Uwaga:  identyfikatory obiektu wspomniane w ostatniej 
kolumnie tabeli 1 są określone w [RFC 5639] w odnie­
sieniu do krzywych Brainpool oraz w [RFC 5480] w odnie­
sieniu do krzywych NIST.
  
8.2.3  Algorytmy skrótu  
▼M1 
CSM_49 Przyrządy rejestrujące, karty do tachografu i urządzenia  
zewnętrzne GNSS obsługują algorytmy SHA-256, 
SHA-384 i SHA-512 określone w [SHS].  
▼B 
8.2.4  Mechanizm szyfrowania  
CSM_50 W przypadku algorytmu symetrycznego stosuje się łącznie 
algorytm asymetryczny lub algorytm skrótu w celu utwo­
rzenia protokołu zabezpieczeń, zaś długości kluczy i wiel­
kości skrótów obu algorytmów są (w przybliżeniu) tak 
samo silne. W tabeli 2 przedstawiono dozwolone mecha­
nizmy szyfrowania:  
Tabela 2  
Dozwolone mechanizmy szyfrowania  
Nr identyfikacyjny 
mechanizmu szyfro­
wania  Wielkość klucza ECC 
(bity)  Długość klucza AES 
(bity)  Algorytm skrótu  Długość MAC 
(bajty)  
CS#1  256  128  SHA-256  8  
CS#2  384  192  SHA-384  1 2  
CS#3  512/521  256  SHA-512  1 6  
Uwaga:  klucze ECC o wielkości 512 i 521 bitów uznaje 
się za równe pod względem siły do wszystkich celów 
określonych w niniejszym dodatku.  
9. KLUCZE I CERTYFIKATY  
9.1. Pary kluczy asymetrycznych i certyfikaty kluczy publicznych  
9.1.1  Uwagi ogólne  
Uwaga:  klucze opisane w tej sekcji wykorzystuje się do wzajemnego 
uwierzytelniania i bezpiecznej wymiany komunikatów między przyr zą­
dami rejestrującymi a kartami do tachografu oraz między przyrzą dami 
rejestrującymi a urządzenia zewnętrznymi GNSS. Procesy te opisa no 
szczegółowo w rozdziałach 10 i 11 niniejszego dodatku.  
CSM_51 W ramach europejskiego systemu tachografów inteligent­
nych pary kluczy ECC i odpowiadające im certyfikaty są 
generowane i zarządzane na trzech funkcjonalnych pozio­
mach hierarchicznych:  
— poziomie europejskim,  
— poziomie państwa członkowskiego,  
— poziomie urządzenia.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 450  
CSM_52 W ramach całego europejskiego systemu tachografów inte­
ligentnych klucze publiczne i prywatne oraz certyfikaty są 
generowane, zarządzane i przekazywane za pomocą stan­
dardowych i bezpiecznych metod.  
9.1.2  Poziom europejski  
CSM_53 Na poziomie europejskim generuje się jedną unikatową 
parę kluczy ECC oznaczoną jako EUR. Składa się ona 
z klucza prywatnego (EUR.SK) i klucza publicznego 
(EUR.PK). Ta para kluczy tworzy parę kluczy głównych 
całego europejskiego systemu tachografów inteligentnych 
PKI. Organem realizującym to zadanie jest Główny Euro­
pejski Organ Certyfikacji (ERCA), działający z upoważ­
nienia i na odpowiedzialność Komisji Europejskiej.  
CSM_54 ERCA używa europejskiego klucza prywatnego do podpi­
sania głównego certyfikatu (z podpisem własnym) europej­
skiego klucza publicznego i przekazuje ten europejski 
certyfikat główny wszystkim państwom członkowskim.  
CSM_55 ERCA używa europejskiego klucza prywatnego do podpi­
sywania na żądanie certyfikatów kluczy publicznych 
państw członkowskich. ERCA prowadzi rejestry wszyst­
kich podpisanych certyfikatów kluczy publicznych państw 
członkowskich.  
CSM_56 Jak przedstawiono na rys. 1 w sekcji 9.1.7, ERCA gene­
ruje nową parę europejskich kluczy głównych co 17 lat. 
Ilekroć ERCA generuje nową parę europejskich kluczy 
głównych, tworzy nowy certyfikat główny z podpisem 
własnym dla nowego europejskiego klucza publicznego. 
Okres ważności europejskiego certyfikatu głównego 
wynosi 34 lata i 3 miesiące.  
Uwaga:  wprowadzenie nowej pary kluczy głównych 
oznacza również, że ERCA wygeneruje nowy klucz 
główny czujnika ruchu i nowy klucz główny DSRC, 
zob. sekcje 9.2.1.2 i 9.2.2.2.  
CSM_57 Przed wygenerowaniem nowej pary europejskich kluczy 
głównych ERCA przeprowadza analizę siły kryptogra­
ficznej, jaka jest potrzebna w odniesieniu do nowej pary 
kluczy, biorąc po uwagę fakt, że powinna pozostać 
bezpieczna przez kolejne 34 lata. W razie konieczności 
ERCA przechodzi na mechanizm szyfrowania, który jest 
mocniejszy niż obecny, jak określono wCSM_50.  
▼M1 
CSM_58 Ilekroć ERCA generuje nową parę europejskich kluczy 
głównych, tworzy certyfikat łączący dla nowego europej­
skiego klucza publicznego i podpisuje go za pomocą 
poprzedniego europejskiego klucza prywatnego. Okres 
ważności certyfikatu łączy wynosi 17 lat i 3 miesiące. 
Przedstawiono to również na rys. 1 w sekcji 9.1.7.  
▼B 
Uwaga:  ze względu na fakt, że certyfikat łączący zawiera 
klucz publiczny ERCA generacji  X i jest podpisany za 
pomocą klucza prywatnego ERCA generacji  X – 1 , certy­
fikat łączący oferuje urządzenie wydane w generacji  X – 1 , 
metodę potwierdzenia niezawodności urządzenia wyda­
nego w generacji  X. 
CSM_59 ERCA nie może używać klucza prywatnego z pary kluczy 
głównych do jakiegokolwiek celu, po tym jak nowy certy­
fikat kluczy głównych stanie się ważny.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 451  
CSM_60 W każdym momencie ERCA dysponuje następującymi 
kluczami i certyfikatami kryptograficznymi:  
— bieżąca para kluczy europejskich i powiązany 
certyfikat;  
— wszystkie wcześniejsze certyfikaty EUR wykorzysty­
wane do weryfikacji certyfikatów MSCA, które nadal 
są ważne;  
— certyfikaty łączące dla wszystkich generacji certyfi­
katów EUR, z wyjątkiem pierwszej.  
9.1.3  Poziom pa ństwa członkowskiego  
CSM_61 Na poziomie państwa członkowskiego wszystkie państwa 
członkowskie zobowiązane do podpisania certyfikatów 
kart do tachografu generują co najmniej jedną unikatową 
parę kluczy ECC oznaczoną jako MSCA_Card. Wszystkie 
państwa członkowskie zobowiązane do podpisania certyfi­
katów dla przyrządów rejestrujących lub urządzeń zewnętrz­
nych GNSS dodatkowo generują co najmniej jedną unika­
tową parę kluczy ECC oznaczoną jako MSCA_VU-EGF.  
CSM_62 Organem odpowiedzialnym za generowanie par kluczy 
państwa członkowskiego jest organ certyfikacji państwa 
członkowskiego (MSCA). Ilekroć MSCA generuje parę 
kluczy państwa członkowskiego, przesyła ERCA klucz 
publiczny, aby uzyskać powiązany z nim certyfikat 
państwa członkowskiego podpisany przez ERCA.  
CSM_63 MSCA dobiera siłę pary kluczy państwa członkowskiego 
w taki sposób, by odpowiadała ona sile pary europejskich 
kluczy głównych użytej do podpisania powiązanego certy­
fikatu państwa członkowskiego.  
CSM_64 Para kluczy MSCA_VU-EGF, jeżeli występuje, składa się 
z klucza prywatnego MSCA_VU-EGF.SK i klucza 
publicznego MSCA_VU-EGF.PK. MSCA używa klucza 
prywatnego MSCA_VU-EGF.SK wyłącznie do podpisy­
wania certyfikatów klucza publicznego przyrządów rejes­
trujących oraz urządzeń zewnętrznych GNSS.  
CSM_65 Para kluczy MSCA_Card składa się z klucza prywatnego 
MSCA_Card.SK i klucza publicznego MSCA_Card.PK. 
MSCA używa klucza prywatnego MSCA_Card.SK wyłącznie 
do podpisywania certyfikatów klucza publicznego kart do 
tachografu.  
CSM_66 MSCA prowadzi rejestry wszystkich podpisanych certyfi­
katów VU, certyfikatów urządzeń zewnętrznych GNSS 
oraz certyfikatów karty i zamieszcza w nim również infor­
macje pozwalające zidentyfikować urządzenie, dla którego 
wydano dany certyfikat.  
CSM_67 Okres ważności certyfikatu MSCA_VU-EGF wynosi 17 lat 
i 3 miesiące. Okres ważności certyfikatu MSCA_Card 
wynosi 7 lat i 1 miesiąc.  
CSM_68 Jak przedstawiono na rys. 1 w sekcji 9.1.7, okres użytko ­
wania klucza prywatnego pary kluczy MSCA_VU-EGF 
i klucza prywatnego pary kluczy MSCA_Card wynosi 
dwa lata.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 452  
CSM_69 MSCA nie może używać klucza prywatnego wchodzącego 
w skład pary kluczy MSCA_VU-EGF do żadnych celów 
po zakończeniu okresu jego użytkowania. Podobnie 
MSCA nie może używać klucza prywatnego wchodzącego 
w skład pary kluczy MSCA_Card do żadnych celów, po 
zakończeniu okresu jego użytkowania.  
CSM_70 W każdym momencie MSCA dysponuje następującymi 
kluczami i certyfikatami kryptograficznymi:  
— bieżącą parą kluczy MSCA_Card i powiązanym 
certyfikatem;  
— wszystkimi poprzednimi certyfikatami MSCA_Card, 
które mają służyć do weryfikacji certyfikatów kart do 
tachografu, które są nadal ważne;  
— bieżącym certyfikatem EUR koniecznym do przepro­
wadzenia weryfikacji bieżącego certyfikatu MSCA;  
— wszystkimi poprzednimi certyfikatami EUR koniecz­
nymi do zweryfikowania wszystkich certyfikatów 
MSCA, które są nadal ważne.  
CSM_71 Jeżeli MSCA jest również zobowiązana do podpisywania 
certyfikatów dla przyrządów rejestrujących lub urządzeń 
zewnętrznych GNSS, musi dodatkowo dysponować nastę­
pującymi kluczami i certyfikatami:  
— bieżącą parą kluczy MSCA_VU-EGF i powiązanym 
certyfikatem;  
— wszystkimi poprzednimi kluczami publicznymi 
MSCA_VU-EGF, które mają służyć do weryfikacji 
certyfikatów VU lub urządzeń zewnętrznych GNSS, 
które są nadal ważne.  
9.1.4  Poziom urz ądzenia: przyrz ądy rejestruj ące 
▼M1 
CSM_72 Dla każdego przyrządu rejestrującego generuje się dwie 
unikatowe pary kluczy ECC oznaczone jako VU_MA 
i VU_Sign. Zadanie to realizują producenci VU. Ilekroć 
generowana jest para kluczy VU, organ generujący klucz 
przekazuje klucz publiczny swojemu MSCA, aby uzyskać 
powiązany certyfikat VU podpisany przez MSCA. Klucz 
prywatny może być używany wyłącznie przez przyrząd 
rejestrujący.  
▼B 
CSM_73 Data wejścia w życie certyfikatów VU_MA i VU_Sign 
danego przyrządu rejestrującego musi być taka sama.  
CSM_74 Producent VU dobiera siłę pary kluczy VU w taki sposób, 
by odpowiadała ona sile pary kluczy MSCA użytej do 
podpisania powiązanego certyfikatu VU.  
CSM_75 Przyrząd rejestrujący używa swojej pary kluczy VU_MA, 
w której skład wchodzi klucz prywatny VU_MA.SK 
i klucz publiczny VU_MA.PK, wyłącznie do uwierzytel­
nienia VU w stosunku do kart do tachografu i urządzeń 
zewnętrznych GNSS, jak określono w sekcjach 10.3 i 11.4 
niniejszego dodatku.  
CSM_76 Przyrząd rejestrujący musi mieć możliwość generowania 
par efemerycznych kluczy ECC i musi używać pary kluczy 
efemerycznych wyłącznie do przeprowadzenia operacji 
uzgadniania klucza sesji z kartą do tachografu lub urzą­
dzeniem zewnętrznym GNSS, jak określono w sekcjach 
10.4 i 11.4 niniejszego dodatku.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 453  
CSM_77 Przyrząd rejestrujący używa klucza prywatnego 
VU_Sign.SK wchodzącego w skład pary kluczy VU_Sign 
wyłącznie do podpisywania pobranych plików danych, jak 
określono w rozdziale 14 niniejszego dodatku. Powiązanego 
klucza publicznego VU_Sign.PK używa się wyłącznie do 
weryfikacji podpisów wygenerowanych przez przyrząd 
rejestrujący.  
CSM_78 Zgodnie z informacjami przedstawionymi na rys. 1 
w sekcji 9.1.7 okres ważności certyfikatu VU_MA wynosi 
15 lat i 3 miesiące. Okres ważności certyfikatu VU_Sign 
również wynosi 15 lat i 3 miesiące.  
Uwagi  
— Wydłużony okres ważności certyfikatu VU_Sign 
umożliwia przyrządowi rejestrującemu generowanie 
ważnych podpisów w odniesieniu do pobieranych 
danych przez pierwsze trzy miesiące po wygaśnięciu 
certyfikatu zgodnie z przepisami rozporządzenia (UE) 
nr 581/2010.  
— Wydłużony okres ważności certyfikatu VU_MA jest 
potrzebny, aby umożliwić VU uwierzytelnianie karty 
kontrolnej lub karty firmowej w ciągu pierwszych 
trzech miesięcy po wygaśnięciu certyfikatu, dzięki 
czemu istnieje możliwość pobrania danych.  
CSM_79 Przyrząd rejestrujący nie może używać klucza prywatnego 
wchodzącego w skład pary kluczy VU do żadnych celów 
po wygaśnięciu powiązanego z nim certyfikatu.  
CSM_80 Par kluczy VU (z wyjątkiem par kluczy efemerycznych) 
i powiązanych z nimi certyfikatów danego przyrządu rejes­
trującego nie można zastępować ani odnawiać w warun­
kach polowych po rozpoczęciu eksploatacji przyrządu 
rejestrującego.  
Uwagi  
— Wymóg ten nie ma zastosowania do par kluczy efeme­
rycznych, ponieważ VU generuje nową parę kluczy 
efemerycznych w ramach każdego procesu uwierzytel­
niania mikroprocesora i uzgadniania klucza sesji – zob. 
sekcja 10.4. Należy zwrócić uwagę na fakt, że pary 
kluczy efemerycznych nie są powiązane z żadnymi 
certyfikatami.  
— Wymóg ten nie uniemożliwia zastąpienia statycznych 
par kluczy VU w trakcie modernizacji lub naprawy 
przeprowadzanej w bezpiecznym środowisku kontrolo­
wanym przez producenta VU.  
CSM_81 W chwili ich oddawania do eksploatacji przyrządy rejes­
trujące muszą zawierać następujące klucze i certyfikaty 
kryptograficzne:  
— klucz prywatny VU_MA i powiązany certyfikat;  
— klucz prywatny VU_Sign i powiązany certyfikat;  
— certyfikat MSCA_VU-EGF zawierający klucz 
publiczny MSCA_VU-EGF.PK służący do weryfikacji 
certyfikatu VU_MA oraz certyfikatu VU_Sign;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 454  
— certyfikat EUR zawierający klucz publiczny EUR.PK 
służący do weryfikacji certyfikatu MSCA_VU-EGF;  
— certyfikat EUR, którego okres ważności wygasa bezpo­ 
średnio przed okresem ważności certyfikatu EUR 
służącego do weryfikacji certyfikatu MSCA_VU- 
EGF, o ile istnieje;  
— certyfikat łączący wspomniane dwa certyfikaty EUR, 
o ile istnieje.  
CSM_82 Poza kluczami i certyfikatami kryptograficznymi wymie­
nionymi w CSM_81 przyrządy rejestrujące muszą również 
zawierać klucze i certyfikaty wskazane w części A niniej­
szego dodatku, dzięki czemu przyrząd rejestrujący może 
komunikować się z kartami do tachografu pierwszej 
generacji.  
9.1.5  Poziom urz ądzenia: karty do tachografu  
▼M1 
CSM_83 Dla każdej karty do tachografu generuje się jedną unika­
tową parę kluczy ECC oznaczoną jako Card_MA. Dla 
każdej karty kierowcy i karty warsztatowej generuje się 
dodatkowo drugą unikatową parę kluczy ECC oznaczoną 
jako Card_Sign. Zadanie to mogą realizować producenci 
kart lub instytucje dokonujące personalizacji kart. Ilekroć 
generowana jest para kluczy karty, organ generujący klucz 
przekazuje klucz publiczny swojemu MSCA, aby uzyskać 
powiązany certyfikat karty podpisany przez MSCA. Klucz 
prywatny może być używany wyłącznie przez kartę do 
tachografu.  
▼B 
CSM_84 Data wejścia w życie certyfikatów Card_MA i Card_Sign 
danej karty kierowcy i karty warsztatowej musi być taka 
sama.  
CSM_85 Producent kart lub instytucja dokonująca personalizacji 
kart dobiera siłę par kluczy karty w taki sposób, by odpo­
wiadała ona sile pary kluczy MSCA użytej do podpisania 
powiązanego certyfikatu karty.  
CSM_86 Karta do tachografu używa swojej pary kluczy Card_MA, 
w której skład wchodzi klucz prywatny Card_MA.SK 
i klucz publiczny Card_MA.PK, wyłącznie do wzajem­
nego uwierzytelniania i uzgadniania klucza sesji 
w stosunku do przyrządów rejestrujących, jak określono 
w sekcjach 10.3 i 10.4 niniejszego dodatku.  
CSM_87 Karta kierowcy lub karta warsztatowa używa klucza 
prywatnego Card_Sign.SK wchodzącego w skład pary 
kluczy Card_Sign wyłącznie do podpisywania pobranych 
plików danych, jak określono w rozdziale 14 niniejszego 
dodatku. Powiązanego klucza publicznego Card_Sign.PK 
używa się wyłącznie do weryfikacji podpisów wygenero­
wanych przez kartę.  
▼M1 
CSM_88 Okres ważności certyfikatu Card_MA wynosi:  
— w przypadku kart kierowcy: 5 lat,  
— w przypadku kart firmowych: 5 lat,  
— w przypadku kart kontrolnych: 2 lata,  
— w przypadku kart warsztatowych: 1 rok.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 455  
CSM_89 Okres ważności certyfikatu Card_Sign wynosi: 
— w przypadku kart kierowcy:  5 lat i 1 miesiąc;  
— w przypadku kart warsztato­
wych:  1 rok i 1 miesiąc.  
Uwaga:  wydłużony okres ważności certyfikatu Card_Sign 
umożliwia karta kierowcy generowanie ważnych podpisów 
w odniesieniu do pobieranych danych przez pierwszy 
miesiąc po wygaśnięciu certyfikatu. Jest to konieczne 
w świetle wymogu ustanowionego w rozporządzeniu (UE) 
nr 581/2010, zgodnie z którym pobranie danych z karty 
kierowcy musi być możliwe przez okres do 28 dni od daty 
dokonania ostatniego zapisu danych na tej karcie.  
CSM_90 Par kluczy i powiązanych certyfikatów danej karty do 
tachografu nie można zastępować ani odnawiać po 
wydaniu karty.  
CSM_91 W chwili ich wydawania karty do tachografu muszą 
zawierać następujące klucze i certyfikaty kryptograficzne:  
— klucz prywatny Card_MA i powiązany certyfikat;  
— w przypadku kart kierowcy i kart warsztatowych 
dodatkowo: klucz prywatny Card_Sign i powiązany 
certyfikat;  
— certyfikat MSCA_Card zawierający klucz publiczny 
MSCA_Card.PK służący do weryfikacji certyfikatu 
Card_MA oraz certyfikatu Card_Sign;  
— certyfikat EUR zawierający klucz publiczny EUR.PK 
służący do weryfikacji certyfikatu MSCA_Card;  
— certyfikat EUR, którego okres ważności wygasa bezpo­ 
średnio przed okresem ważności certyfikatu EUR 
służącego do weryfikacji certyfikatu MSCA_Card, 
o ile istnieje;  
— certyfikat łączący wspomniane dwa certyfikaty EUR, 
o ile istnieje.  
▼M1 
— dodatkowo tylko w przypadku kart kontrolnych, kart 
firmowych i kart warsztatowych i tylko jeżeli takie 
karty zostały wydane w ciągu pierwszych trzech 
miesięcy okresu ważności nowego certyfikatu EUR: 
certyfikat EUR starszy o dwie generacje, jeżeli wystę­
puje.  
Uwaga do tiret ostatniego:  Przykładowo w pierwszych 
trzech miesiącach certyfikatu ERCA(3) (zob. rys. 1) 
wspomniane karty zawierają certyfikat ERCA(1). 
Uwzględnienie certyfikatu ERCA(1) jest konieczne 
w celu zapewnienia możliwości używania tych kart 
na potrzeby pobierania danych z przyrządów rejestru­
jących, których normalny okres użyteczności wyno­
szący 15 lat plus trzy miesiące okresu pobierania 
danych upływa w ciągu tych miesięcy; zob. tiret 
ostatnie wymogu 13 w załączniku IC.  
▼B 
CSM_92 Poza kluczami i certyfikatami kryptograficznymi wymie­
nionymi w CSM_91 karty do tachografu muszą również 
zawierać klucze i certyfikaty wskazane w części A niniej­
szego dodatku, dzięki czemu mogą komunikować się z VU 
pierwszej generacji.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 456  
9.1.6  Poziom urz ądzenia: urz ądzenia zewn ętrzne GNSS  
▼M1 
CSM_93 Dla każdego urządzenia zewnętrznego GNSS generuje się 
jedną unikatową parę kluczy ECC oznaczoną jako 
EGF_MA. Zadanie to realizują producenci urządzeń 
zewnętrznych GNSS. Ilekroć generowana jest para kluczy 
EGF_MA, organ generujący klucz przekazuje klucz 
publiczny swojemu MSCA, aby uzyskać powiązany certy­
fikat EGF_MA podpisany przez MSCA. Klucz prywatny 
może być używany wyłącznie przez urządzenie zewnętrzne 
GNSS.  
▼B 
CSM_94 Producent EGF dobiera siłę pary kluczy EGF_MA w taki 
sposób, by odpowiadała ona sile pary kluczy MSCA użytej 
do podpisania powiązanego certyfikatu EGF_MA.  
▼M1 
CSM_95 Urządzenie zewnętrzne GNSS używa swojej pary kluczy 
EGF_MA, w której skład wchodzi klucz prywatny 
EGF_MA.SK i klucz publiczny EGF_MA.PK, wyłącznie 
do wzajemnego uwierzytelniania i uzgadniania klucza sesji 
w stosunku do przyrządów rejestrujących, jak określono 
w sekcji 11.4 niniejszego dodatku.  
▼B 
CSM_96 Okres ważności certyfikatu EGF_MA wynosi 15 lat.  
CSM_97 Urządzenie zewnętrzne GNSS nie może używać klucza 
prywatnego wchodzącego w skład pary kluczy EGF_MA 
do wiązania się z przyrządem rejestrującym po wygaś­
nięciu powiązanego z nim certyfikatu.  
Uwaga:  jak wyjaśniono w sekcji 11.3.3, EGF może poten­
cjalnie używać swojego klucza prywatnego na potrzeby 
wzajemnego uwierzytelniania w stosunku do VU, jeżeli 
został już z nim powiązany, nawet po upływie okresu 
ważności powiązanego certyfikatu.  
CSM_98 Pary kluczy EGF_MA i powiązanych certyfikatów danego 
urządzenia zewnętrznego GNSS nie można zastępować ani 
odnawiać w warunkach polowych po rozpoczęciu eksploa­
tacji EGF.  
Uwaga:  wymóg ten nie uniemożliwia zastąpienia par 
kluczy EGF w trakcie modernizacji lub naprawy przepro­
wadzanej w bezpiecznym środowisku kontrolowanym 
przez producenta EGF.  
CSM_99 W chwili ich oddawania do eksploatacji urządzenia 
zewnętrzne GNSS muszą zawierać następujące klucze 
i certyfikaty kryptograficzne:  
— klucz prywatny EGF_MA i powiązany certyfikat;  
— certyfikat MSCA_VU-EGF zawierający klucz 
publiczny MSCA_VU-EGF.PK służący do weryfikacji 
certyfikatu EGF_MA;  
— certyfikat EUR zawierający klucz publiczny EUR.PK 
służący do weryfikacji certyfikatu MSCA_VU-EGF;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 457  
— certyfikat EUR, którego okres ważności wygasa bezpo­ 
średnio przed okresem ważności certyfikatu EUR 
służącego do weryfikacji certyfikatu MSCA_VU- 
EGF, o ile istnieje;  
— certyfikat łączący wspomniane dwa certyfikaty EUR, 
o ile istnieje.  
9.1.7  Przegl ąd: zastąpienie certyfikatu  
Na rys. 1 poniżej przedstawiono, w jaki sposób różne generacje certyfi­
katów głównych ERCA, certyfikatów łączących ERCA, certyfikatów 
MSCA oraz certyfikatów urządzeń (VU i kart) są wydawane i wykor zy­
stywane na przestrzeni czasu:  
▼M1 
Rysunek 1  
Wydawanie i u żywanie ró żnych generacji certyfikatów g łównych ERCA, certyfikatów łączących ERCA, 
certyfikatów MSCA i certyfikatów urz ądzeń
 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 458  
Uwagi do rys. 1  
1. poszczególne generacje certyfikatów głównych oznaczono cyfrą  
w nawiasie. Na przykład ERCA (1) oznacza pierwszą generację cer ty­
fikatu głównego ERCA, ERCA (2) – drugą generację itd.;  
2. pozostałe certyfikaty są oznaczone dwiema cyframi w nawiasac h: 
pierwsza z nich wskazuje generację certyfikatu głównego, w któr ej 
wydano dany certyfikat, natomiast druga określa generację sameg o 
certyfikatu. Na przykład MSCA_Card (1-1) oznacza pierwszy certy ­
fikat MSCA_Card wydany na podstawie ERCA (1); MSCA_Card (2- 
1) oznacza pierwszy certyfikat MSCA_Card wydany na podstawie 
ERCA (2); MSCA_Card (2-ostatni) oznacza ostatni certyfikat 
MSCA_Card wydany na podstawie ERCA (2); Card_MA (2-1) 
oznacza pierwszy certyfikat karty na potrzeby wzajemnego uwierz y­
telnienia wydany na podstawie ERCA (2) itp.;  
3. certyfikaty MSCA_Card (2-1) i MSCA_Card (1-ostatni) wydaje s ię 
z bardzo zbliżoną datą. MSCA_Card (2-1) oznacza pierwszy certy­
fikat MSCA_Card wydany na podstawie ERCA (2), który wydaje się 
nieco później niż MSCA_Card (1-ostatni), czyli ostatni certyfik at 
MSCA_Card wydany na podstawie ERCA (1);  
4. zgodnie z informacjami przedstawionymi na rysunku pierwsze c erty­
fikaty VU i certyfikaty karty wydane na podstawie ERCA (2) poja wią 
się niemal dwa lata przed ostatnimi certyfikatami VU i certyfik atami 
karty wydanymi na podstawie ERCA (1). Wynika to z faktu, że 
certyfikaty VU i certyfikaty karty wydaje się na podstawie cert yfikatu 
MSCA, nie zaś bezpośrednio na podstawie certyfikatu ERCA. Certy ­
fikat MSCA (2-1) zostanie wydany bezpośrednio po uzyskaniu 
ważności przez ERCA (2), ale certyfikat MSCA (1-ostatni) zostan ie 
wydany tylko nieznacznie później, tj. w ostatnim dniu, w którym  
certyfikat ERCA (1) jest nadal ważny. Z tego względu obydwa cer ty­
fikaty MSCA będą miały niemal taki sam okres ważności, mimo że 
należą do różnych generacji;  
5. podany okres ważności kart odpowiada okresowi ważności kart 
kierowcy (5 lat);  
▼M1 
6. aby zaoszczędzić miejsce, różnica w okresie ważności certyfi katów 
Card_MA i Card_Sign została podana wyłącznie dla certyfikatów 
pierwszej generacji.  
▼B 
9.2. Klucze symetryczne  
9.2.1  Klucze do zabezpieczania łączności między VU a czujnikiem ruchu  
9.2.1.1  Uwagi ogólne  
Uwaga:  zakłada się, że czytelnicy tego rozdziału są zaznajomieni z tr eścią 
normy [ISO 16844-3], w której opisano interfejs pomiędzy przyrz ądem 
rejestrującym a czujnikiem ruchu. Proces parowania VU i czujnik a ruchu 
opisano szczegółowo w rozdziale 12 niniejszego dodatku.  
CSM_100 Potrzeba wielu kluczy symetrycznych do sparowania przy­
rządów rejestrujących i czujników ruchu, wzajemnego uwie­
rzytelnienia między przyrządami rejestrującymi a czujnikami 
ruchu oraz zaszyfrowania łączności między przyrządami 
rejestrującymi a czujnikami ruchu, jak pokazano w tabeli 
3. Wszystkie te klucze muszą być kluczami AES o długości 
klucza równej długości klucza głównego czujnika ruchu, 
która z kolei musi być powiązana z (przewidywaną) długo­ 
ścią pary europejskich kluczy głównych, jak opisano 
w CSM_50.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 459  
Tabela 3  
Klucze do zabezpieczania łączności między przyrz ądem rejestruj ącym a czujnikiem ruchu  
Klucz  Symbol  Generowany przez  Metoda generowania  Przechowywany przez  
Klucz główny czujnika 
ruchu – część dotycząca 
VU K M-VU  ERCA  Losowo  ERCA, MSCA zaangażowane 
w wydawanie certyfikatów 
VU, producenci VU, przyrządy 
rejestrujące  
Klucz główny czujnika 
ruchu – część dotycząca 
warsztatu  K M-WC  ERCA  Losowo  ERCA, MSCA, producenci 
kart, karty warsztatowe  
Klucz główny czujnika 
ruchu  K M Nie jest genero­
wany oddzielnie  Obliczany jako K  M = 
K M-VU  XOR K  M-WC  ERCA, MSCA zaangażowane 
w wydawanie kluczy czuj­
ników ruchu (opcjonalnie) (*)  
Klucz identyfikacyjny  K  ID Nie jest genero­
wany oddzielnie  Obliczany jako K  ID = 
K M XOR CV, gdzie 
CV jest określony 
w CSM_106  ERCA, MSCA zaangażowane 
w wydawanie kluczy czuj­
ników ruchu (opcjonalnie) (*)  
Klucz parowania  K  P Producent czujnika 
ruchu  Losowo  Jeden czujnik ruchu  
Klucz sesji  K  S VU (w trakcie 
parowania VU 
z czujnikiem 
ruchu)  Losowo  Jeden VU i jeden czujnik 
ruchu  
(*) Przechowywanie K  M i K  ID jest opcjonalne, ponieważ klucze te można wyprowadzić z K  M-VU  , K  M-WC  i CV.  
CSM_101 Główny Europejski Organ Certyfikacji generuje K  M-WU  
i K  M-WC  , dwa losowe, unikatowe klucze AES, na podstawie 
których można obliczyć klucz główny czujnika ruchu K  M 
jako K  M-VU  XOR K  M-WC  . Na wniosek organów certyfikacji 
państw członkowskich ERCA przekazuje im K  M , K  M-VU  
i K  M-WC  . 
CSM_102 ERCA przypisuje każdemu kluczowi głównemu czujnika 
ruchu K  M unikatowy numer wersji mający zastosowanie 
również do kluczy ustanawiających K  M-VU  i K  M-WC  oraz 
do powiązanego klucza identyfikacyjnego K  ID . ERCA 
powiadamia MSCA o numerze wersji, gdy przekazuje im 
K M-VU  i K  M-WC  . 
Uwaga:  numer wersji wykorzystuje się do rozróżnienia 
poszczególnych generacji wspomnianych kluczy, jak wyjaś­
niono szczegółowo w sekcji 9.2.1.2.  
CSM_103 Organ certyfikacji państwa członkowskiego przekazuje K  M- 
VU wraz z jego numerem wersji producentom przyrządów 
rejestrujących na ich wniosek. Producenci VU umieszczają 
K M-VU  wraz z jego numerem wersji we wszystkich wytwa­
rzanych VU.  
CSM_104 Organ certyfikacji państwa członkowskiego zapewnia 
umieszczenie K  M-WC  wraz z jego numerem wersji w każdej 
karcie warsztatowej wydanej pod nadzorem MSCA.  
Uwagi  
— Zobacz opis typu danych
  
w dodatku 2.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 460  
— Jak wyjaśniono w sekcji 9.2.1.2, w praktyce w niektó­
rych przypadkach może zachodzić konieczność umiesz­
czenia wielu generacji K  M-WC  w pojedynczej karcie 
warsztatowej.  
CSM_105 Poza kluczem AES, o którym mowa w CSM_104, MSCA 
zapewnia również umieszczenie klucza TDES Km  WC, , 
o którym mowa w wymogu CSM_037 w części A niniej­
szego dodatku, w każdej karcie warsztatowej wydanej pod 
nadzorem MSCA.  
Uwagi  
— Zapewnia to możliwość użycia karty warsztatowej 
drugiej generacji do powiązania z VU pierwszej 
generacji.  
— Karta warsztatowa drugiej generacji będzie posiadała 
dwie różne aplikacje, z których jedna będzie zgodna 
z częścią B niniejszego dodatku, a druga – z częścią 
A niniejszego dodatku. Ta druga aplikacja będzie zawie­
rała klucz TDES Km  WC . 
CSM_106 MSCA zaangażowany w wydawanie certyfikatów czujników 
ruchu wyprowadza klucz identyfikacyjny z klucza głównego 
czujnika ruchu, za pomocą funkcji XOR z wykorzystaniem 
wektora stałego CV. Przyjmuje się, że CV ma następującą 
wartość:  
▼M1 
— w odniesieniu do 128-bitowych kluczy głównych czuj­
nika ruchu: CV = „B6 44 2C 45 0E F8 D3 62 0B 7A 
8A 97 91 E4 5D 83”  
▼B 
— w odniesieniu do 192-bitowych kluczy głównych czuj­
nika ruchu: 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”  
— w odniesieniu do 256-bitowych kluczy głównych czuj­
nika ruchu: 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”  
Uwaga:  wektory stałe generuje się w następujący sposób:  
Pi_10 = pierwsze 10 bajtów dziesiętnej części stałej mate­
matycznej π = „24 3F 6A 88 85 A3 08 D3 13 19”  
CV_128-bits = pierwszych 16 bajtów SHA-256(Pi_10)  
CV_192-bits = pierwsze 24 bajty SHA-384(Pi_10)  
CV_256-bits = pierwsze 32 bajty SHA-512(Pi_10)  
CSM_107  ►M1 Każdy producent czujników ruchu generuje losowy 
i unikatowy klucz parowania K  P dla każdego czujnika ruchu 
i przesyła każdy klucz parowania organowi certyfikacji 
państwa członkowskiego (MSCA). MSCA szyfruje każdy 
klucz parowania oddzielnie za pomocą klucza głównego 
czujnika ruchu K  M i zwraca zaszyfrowany klucz producen­
towi czujników ruchu. W przypadku każdego zaszyfrowa­
nego klucza MSCA powiadamia producenta czujników 
ruchu o numerze wersji powiązanego K  M . ◄ 
Uwaga:  jak wyjaśniono w sekcji 9.2.1.2, w praktyce może 
zachodzić konieczność wygenerowania przez producenta 
czujników ruchu wielu unikatowych kluczy parowania dla 
pojedynczego czujnika ruchu.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 461  
CSM_108 Każdy producent czujników ruchu generuje unikatowy 
numer seryjny dla każdego czujnika ruchu i przesyła 
wszystkie numery seryjne swojemu organowi certyfikacji 
państwa członkowskiego. MSCA szyfruje każdy numer 
seryjny oddzielnie za pomocą klucza identyfikacyjnego 
K ID i zwraca zaszyfrowany numer seryjny producentowi 
czujników ruchu. W przypadku każdego zaszyfrowanego 
numeru seryjnego MSCA powiadamia producenta czujników 
ruchu o numerze wersji powiązanego K  ID . 
▼B 
CSM_109 W odniesieniu do wymogów CSM_107 i CSM_108 MSCA 
korzysta z algorytmu AES w trybie wiązania bloków zaszyf­
rowanych, jak określono w normie [ISO 10116], z naprze­
miennym parametrem  m = 1 oraz wektorem inicjującym SV 
= „00” {16}, tj. szesnaście bajtów o wartości binarnej 0. 
W razie potrzeby MSCA korzysta z metody wypełniania 2 
określonej w normie [ISO 9797-1].  
CSM_110 Producent czujników ruchu przechowuje zaszyfrowany 
klucz parowania i zaszyfrowany numer seryjny w przewi­
dzianym czujniku ruchu wraz z odpowiadającymi warto­ 
ściami zwykłego tekstu i numerem wersji K  M i K  ID użytymi 
do szyfrowania.  
Uwaga:  jak wyjaśniono w sekcji 9.2.1.2, w praktyce może 
zachodzić konieczność umieszczenia przez producenta czuj­
ników ruchu wielu zaszyfrowanych kluczy parowania 
i wielu zaszyfrowanych numerów seryjnych w pojedynczym 
czujniku ruchu.  
CSM_111 Oprócz materiału kryptograficznego opartego na AES okre ­ 
ślonego w CSM_110, producent czujników ruchu może 
również przechowywać w każdym czujniku ruchu materiał 
kryptograficzny oparty na TDES, jak określono w niniejszym 
dodatku część A wymóg CSM_037.  
Uwaga:  dzięki temu możliwe będzie powiązanie czujnika 
ruchu drugiej generacji z VU pierwszej generacji.  
CSM_112 Długość klucza sesji K  S wygenerowanego przez VU 
w trakcie parowania z czujnikiem ruchu jest powiązana 
z długością jego K  M-VU  , jak opisano w CSM_50.  
9.2.1.2  Zastąpienie klucza g łównego czujnika ruchu w urz ądzeniu drugiej gene ­
racji  
CSM_113 Każdy klucz główny czujnika ruchu i wszystkie powiązane  
klucze (zob. tabela 3) są powiązane z określoną generacją 
pary kluczy głównych ERCA. Klucze te wymienia się zatem 
co 17 lat. Okres ważności każdej generacji klucza głównego 
czujnika ruchu rozpoczyna się rok wcześniej, zanim powią­
zana para kluczy głównych ERCA stanie się ważna, i kończy 
się po upływie ważności powiązanej pary kluczy głównych 
ERCA. Przedstawiono to na rys. 2.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 462  
Rys. 2  
Wydawanie ró żnych generacji klucza g łównego czujnika ruchu i ich u żywanie w przyrz ądach rejestruj ących, 
czujnikach ruchu i kartach warsztatowych
  
CSM_114 Co najmniej rok przed wygenerowaniem nowej pary euro­
pejskich kluczy głównych, jak opisano w CSM_56, ERCA 
generuje nowy klucz główny czujnika ruchu K  M poprzez 
wygenerowanie nowych K  M-VU  i K  M-WC  . Długość klucza 
głównego czujnika ruchu jest powiązana z przewidywaną 
siłą nowej pary europejskich kluczy głównych zgodnie 
z CSM_50. Na wniosek MSCA ERCA przekazuje im 
nowe K  M , K  M-VU  i K  M-WC  wraz z ich numerem wersji.  
CSM_115 MSCA zapewnia, aby wszystkie ważne generacje K  M-WC  
były przechowywane na karcie warsztatowej wydanej 
z jego upoważnienia wraz z numerami wersji, jak przedsta­
wiono na rys. 2.  
Uwaga:  oznacza to, że w ostatnim roku okresu ważności 
certyfikatu ERCA karty warsztatowe będą wydawane z trzema 
różnymi generacjami K  M-WC  , jak przedstawiono na rys. 2.  
CSM_116 W odniesieniu do procesu opisanego w CSM_107 
i CSM_108 powyżej: MSCA szyfruje każdy klucz paro­
wania K  P , który otrzymuje od producenta czujników ruchu, 
oddzielnie za pomocą każdej ważnej generacji klucza głów­
nego czujnika ruchu K  M . MSCA szyfruje również każdy 
numer seryjny, który otrzymuje od producenta czujników 
ruchu, oddzielnie za pomocą każdej ważnej generacji klucza 
identyfikacyjnego K  ID . Producent czujników ruchu przecho­
wuje wszystkie zaszyfrowane klucze parowania i wszystkie 
zaszyfrowane numery seryjne w przewidzianym czujniku 
ruchu wraz z odpowiadającymi wartościami zwykłego tekstu 
i numerami wersji K  M i K  ID użytymi do szyfrowania.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 463  
Uwaga:  oznacza to, że w ostatnim roku okresu ważności 
certyfikatu ERCA czujniki ruchu będą wydawane z zaszyfro­
wanymi danymi opartymi na trzech różnych generacjach 
K M, , jak przedstawiono na rys. 2.  
CSM_117 W odniesieniu do procesu opisanego powyżej w CSM_107: 
ze względu na fakt, że długość klucza parowania K  P jest 
powiązana z długością K  M (zob. CSM_100), producent czuj­
nika ruchu może być zmuszony do wygenerowania do 
trzech różnych kluczy parowania (o różnej długości) dla 
jednego czujnika ruchu, w przypadku gdy kolejne generacje 
K M mają różne długości. W takim przypadku producent 
przesyła MSCA każdy klucz parowania. MSCA zapewnia, 
aby każdy klucz parowania był zaszyfrowany za pomocą 
prawidłowej generacji klucza głównego czujnika ruchu tj. 
klucza mającego taką samą długość.  
Uwaga:  w przypadku gdy producent czujników ruchu 
zdecyduje się wygenerować klucz parowania oparty na 
TDES dla czujnika ruchu drugiej generacji (zob. CSM_111), 
producent wskazuje MSCA, że klucz główny czujnika ruchu 
oparty na TDES musi zostać użyty do zaszyfrowania tego 
klucza parowania. Wynika to z tego, że długość klucza 
TDES może być równa długości klucza AES, tak więc 
MSCA nie może dokonać oceny wyłącznie na podstawie 
długości klucza.  
CSM_118 Producenci przyrządów rejestrujących umieszczają tylko 
jedną generację K  M-VU  w każdym przyrządzie rejestrującym 
wraz z jego numerem wersji. Wspomniana generacja K  M-VU  
musi być powiązana z certyfikatem ERCA, na których opie­
rają się certyfikaty VU.  
Uwagi  
— Przyrząd rejestrujący oparty na certyfikacie ERCA gene­
racji X zawiera jedynie K  M-VU  generacji X, nawet jeżeli 
został wydany po rozpoczęciu okresu ważności certyfi­
katu ERCA generacji  X + 1.  Przedstawiono to na rys. 2.  
— Przyrządu rejestrującego generacji  X nie można 
sparować z czujnikiem ruchu generacji  X – 1 . 
— Ze względu na fakt, że okres ważności kart warsztato­
wych wynosi jeden rok, w wyniku zastosowania 
CSM_113 – CSM_118 wszystkie karty warsztatowe 
będą zawierały nowy K  M-WC  w momencie wydania 
pierwszego VU zawierającego nowy K  M-VU  . W związku 
z tym taki VU zawsze będzie w stanie obliczyć nowy 
K M . Ponadto do tego czasu większość nowych czuj­
ników ruchu będzie zawierała zaszyfrowane dane 
również oparte na nowym K  M . 
9.2.2  Klucze do zabezpieczania łączności DSRC  
9.2.2.1  Uwagi ogólne  
CSM_119 Autentyczność i poufność danych przekazanych organowi 
kontrolnemu z przyrządu rejestrującego za pośrednictwem 
kanału DSRC do łączności na odległość zapewnia się za 
pomocą zestawu kluczy AES specyficznych dla VU, który 
wyprowadzono z pojedynczego klucza głównego DSRC, 
KM  DSRC  . ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 464  
CSM_120 Klucz główny DSRC KM  DSRC  stanowi klucz AES, który 
jest bezpiecznie generowany, przechowywany i rozpo­
wszechniany przez ERCA. Długość klucza może wynosić 
128, 192 lub 256 bitów i jest powiązana z długością pary 
europejskich kluczy głównych, jak opisano w CSM_50.  
CSM_121 Na wniosek organów certyfikacji państw członkowskich 
ERCA przekazuje im klucz główny DSRC w sposób 
bezpieczny w celu umożliwienia im wyprowadzenia kluczy 
DSRC specyficznych dla VU i zapewnienia umieszczenia 
klucza głównego DSRC we wszystkich kartach kontrolnych 
i kartach warsztatowych wydanych na ich odpowiedzialność.  
CSM_122 ERCA przypisuje każdemu kluczowi głównemu DSRC 
unikatowy numer wersji. ERCA powiadamia MSCA 
o numerze wersji, gdy przesyła im klucz główny DSRC.  
Uwaga:  numer wersji wykorzystuje się do rozróżnienia 
poszczególnych generacji klucza głównego DSRC, jak 
wyjaśniono szczegółowo w sekcji 9.2.2.2.  
▼M1 
CSM_123 W odniesieniu do każdego przyrządu rejestrującego produ ­
cent takiego przyrządu tworzy unikatowy numer seryjny VU 
i przesyła taki numer swojemu organowi certyfikacji 
państwa członkowskiego we wniosku w celu uzyskania 
zestawu dwóch kluczy DSRC specyficznych dla VU. 
Numer seryjny VU posiada typ danych VuSerialNumber.  
Uwaga:  
— Taki numer seryjny VU musi być identyczny 
z elementem vuSerialNumber w VuIdentification (zob. 
dodatek 1) i z odniesieniem do posiadacza certyfikatu 
w certyfikatach VU.  
— Numer seryjny VU może nie być znany w momencie 
żądania przez producenta przyrządu rejestrującego 
kluczy DSRC specyficznych dla VU. W takim przy­
padku producent VU wysyła zastępczo unikatowy iden­
tyfikator wniosku o certyfikat, którego użył, występując 
o certyfikaty VU. zob. CSM_153; Taki identyfikator 
wniosku o certyfikat musi być zatem identyczny z odnie­
sieniem do posiadacza certyfikatu w certyfikatach VU.  
▼B 
CSM_124 Po otrzymaniu wniosku o klucze DSRC specyficzne dla VU 
MSCA wyprowadza dwa klucze AES dla przyrządu rejes­
trującego, zwane K_VU  DSRC  _ENC i K_VU  DSRC  _MAC. 
Wspomniane klucze specyficzne dla VU mają taką samą 
długość jak klucz główny DSRC. MSCA korzysta z funkcji 
wyprowadzania klucza zdefiniowanej w [RFC 5869]. 
Funkcja skrótu, która jest niezbędna do utworzenia wystą­
pienia funkcji HMAC-Hash, jest powiązana z długością 
klucza głównego DSRC, jak opisano w CSM_50. Z funkcji 
wyprowadzania klucza w [RFC 5869] korzysta się w nastę­
pujący sposób:  
krok 1: (wyodrębnienie):  
— PRK  = HMAC-Hash ( salt, IKM ) gdzie  salt  oznacza 
pusty ciąg „”, a  IKM  oznacza KM  DSRC  ; ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 465  
krok 2: (rozszerzenie):  
— OKM  = T(1) , gdzie  
T(1) = HMAC-Hash ( PRK , T(0)  | | info  || „01”)  
— T(0)  = pusty ciąg („”)  
— ►M1 info  = numer seryjny VU lub identyfikator 
wniosku o certyfikat, jak określono w CSM_123  
— K_VU  DSRC  _ENC = pierwsze oktety  L OKM  i 
K_VU  DSRC  _MAC = ostatnie oktety  L OKM  
gdzie  L oznacza wymaganą długość K_VU  DSRC  _ENC 
i K_VU  DSRC  _MAC w oktetach.  
CSM_125 MSCA przekazuje K_VU  DSRC  _ENC i K_VU  DSRC  _MAC 
producentowi VU w sposób bezpieczny w celu umiesz­
czenia w przewidzianym przyrządzie rejestrującym.  
CSM_126 Po wydaniu przyrząd rejestrujący przechowuje 
K_VU  DSRC  _ENC i K_VU  DSRC  _MAC w swojej bezpiecznej 
pamięci, aby móc zapewnić integralność, autentyczność 
i poufność danych wysyłanych za pośrednictwem kanału 
do łączności na odległość. Przyrząd rejestrujący przecho­
wuje również numer wersji klucza głównego DSRC użyty 
do wyprowadzenia tych kluczy specyficznych dla VU.  
CSM_127 Po wydaniu karty kontrolne i karty warsztatowe przecho­
wują KM  DSRC  w swojej bezpiecznej pamięci, aby móc 
zweryfikować integralność i autentyczność danych wysyła­
nych przez VU za pośrednictwem kanału do łączności na 
odległość oraz aby deszyfrować te dane. Karty kontrolne 
i karty warsztatowe przechowują również numer wersji 
klucza głównego DSRC.  
Uwaga:  jak wyjaśniono w sekcji 9.2.2.2, w praktyce może 
zachodzić konieczność umieszczenia wielu generacji 
KM  DSRC  w pojedynczej karcie warsztatowej lub pojedynczej 
karcie kontrolnej.  
▼M1 
CSM_128 MSCA prowadzi rejestry wszystkich wygenerowanych 
kluczy DSRC specyficznych dla VU, ich numerów wersji 
i numerów seryjnych VU lub identyfikatorów wniosku 
o certyfikat wykorzystanych w celu ich wyprowadzenia.  
9.2.2.2  Zastąpienie klucza g łównego DSRC  
CSM_129 Każdy klucz główny DSRC jest powiązany z określoną 
generacją pary kluczy głównych ERCA. ERCA zastępuje 
zatem klucz główny DSRC co 17 lat. Okres ważności każdej 
generacji klucza głównego DSRC rozpoczyna się dwa lata 
wcześniej, zanim powiązana para kluczy głównych ERCA 
stanie się ważna, i kończy się po upływie ważności powią­
zanej pary kluczy głównych ERCA. Przedstawiono to na 
rys. 3.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 466  
Rys. 3  
Wydawanie ró żnych generacji klucza g łównego DSRC i ich u żywanie w przyrz ądach rejestruj ących, kartach 
warsztatowych i kartach kontrolnych
  
CSM_130 Co najmniej dwa lata przed wygenerowaniem nowej pary 
europejskich kluczy głównych, jak opisano w CSM_56, 
ERCA generuje nowy klucz główny DSRC. Długość klucza 
DSRC jest powiązana z przewidywaną siłą nowej pary euro­
pejskich kluczy głównych zgodnie z CSM_50. Na wniosek 
MSCA ERCA przekazuje im nowy klucz główny DSRC 
wraz z jego numerem wersji.  
CSM_131 MSCA zapewnia, aby wszystkie ważne generacje KM  DSRC  
były przechowywane na karcie kontrolnej wydanej z jego 
upoważnienia wraz z numerami wersji, jak przedstawiono na 
rys. 3.  
Uwaga:  oznacza to, że w ciągu ostatnich dwóch lat okresu 
ważności certyfikatu ERCA karty kontrolne będą wydawane 
z trzema różnymi generacjami KM  DSRC  , jak przedstawiono 
na rys. 3.  
CSM_132 MSCA zapewnia, aby wszystkie generacje KM  DSRC  , które 
były ważne przez co najmniej rok i nadal są ważne, były 
przechowywane na karcie warsztatowej wydanej z jego 
upoważnienia wraz z numerami wersji, jak przedstawiono 
na rys. 3.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 467  
Uwaga:  oznacza to, że w ostatnim roku okresu ważności 
certyfikatu ERCA karty warsztatowe będą wydawane 
z trzema różnymi generacjami KM  DSRC  , jak przedstawiono 
na rys. 3.  
CSM_133 Producenci przyrządów rejestrujących umieszczają tylko 
jeden zestaw kluczy DSRC specyficznych dla VU w każdym 
przyrządzie rejestrującym wraz z jego numerem wersji. 
Wspomniany zestaw kluczy wyprowadza się z generacji 
KM  DSRC  powiązanej z certyfikatem ERCA, na którym opie­
rają się certyfikaty VU.  
Uwagi  
— Oznacza to, że przyrząd rejestrujący oparty na certyfikacie 
ERCA generacji  X zawiera jedynie K_VU  DSRC  _ENC 
i K_VU  DSRC  _MAC generacji  X, nawet jeżeli VU został 
wydany po rozpoczęciu okresu ważności certyfikatu 
ERCA generacji  X + 1.  Przedstawiono to na rys. 3.  
— Ze względu na fakt, że okres ważności kart warsztato­
wych wynosi jeden rok, a kart kontrolnych dwa lata, 
w wyniku zastosowania CSM_131 – CSM_133 wszystkie 
karty warsztatowe i karty kontrolne będą zawierały nowy 
klucz główny DSRC w momencie wydania pierwszego 
VU zawierającego klucze specyficzne dla VU, oparte na 
przedmiotowym kluczu głównym.  
9.3. Certyfikaty  
9.3.1  Uwagi ogólne  
CSM_134 Wszystkie certyfikaty w europejskim systemie tachografó w 
inteligentnych są certyfikatami samoopisującymi, weryfiko­
walnymi przez kartę (CV) zgodnie z normami [ISO 7816-4] 
i [ISO 7816-8].  
CSM_135  ►M1 Wyróżnione reguły kodowania (DER) zgodnie 
z [normą ISO 8825-1] wykorzystuje się do kodowania 
obiektów danych w ramach certyfikatów. W tabeli 4 przed­
stawiono pełne kodowanie świadectw, z uwzględnieniem 
wszystkich bajtów znaczników i długości. ◄  
Uwaga:  w wyniku takiego kodowania uzyskuje się następu­
jącą strukturę TLV:  
znacznik: znacznik jest zakodowany w jednym oktecie lub 
dwóch oktetach i określa treść;  
długość: długość jest zakodowana jako liczba całkowita bez 
znaku w jednym oktecie, dwóch lub trzech okte­
tach, co skutkuje uzyskaniem maksymalnej 
długości 65 535 oktetów. Stosuje się minimalną 
liczbę oktetów;  
wartość: wartość nie jest zakodowana w żadnym oktecie 
lub jest zakodowana w większej liczbie oktetów.  
9.3.2  Treść certyfikatu  
CSM_136 Wszystkie certyfikaty mają strukturę przedstawioną w pr ofilu 
certyfikatu w tabeli 4.  
Tabela 4  
Wersja 1 profilu certyfikatu  
Pole Nr ID pola  Znacznik  Długość (bajty)  Typ danych ASN.1 
(zob. dodatek 1)  
Certyfikat ECC  C  „7F 21”  var  
Treść certyfikatu 
ECC  B „7F 4E”  var  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 468  
Pole Nr ID pola  Znacznik  Długość (bajty)  Typ danych ASN.1 
(zob. dodatek 1)  
Identyfikator profilu 
certyfikatu  CPI „5F 29”  „01”
  
odniesienie do organu 
certyfikacji  CAR  „42”  „08”
  
upoważnienie posia­
dacza certyfikatu  CHA  „5F 4C”  „07”
  
Klucz publiczny  P K  „7F 49”  var  
Parametry domeny  D P  „06”  var
  
Punkt publiczny  P P  „86”  var
  
odniesienie do posia­
dacza certyfikatu  CHR  „5F 20”  „08”
  
Data wejścia w życie 
certyfikatu  CEfD  „5F 25”  „04”
  
Data wygaśnięcia 
certyfikatu  CExD  „5F 24”  „04”
  
Podpis certyfikatu 
ECC  S „5F 37”  var
  
Uwaga:  identyfikator pola zostanie wykorzystany w dalszych 
częściach niniejszego dodatku w celu wskazania poszczegól­
nych pól certyfikatu np. X.CAR oznacza odniesienie do 
organu certyfikacji, o którym mowa w certyfikacie użytkow­
nika X.  
9.3.2.1 Identyfikator profilu certyfikatu  
CSM_137 Certyfikaty używają identyfikatora profilu certyfikatu do 
wskazania użytego profilu certyfikatu. Wersję 1, jak wska­
zano w tabeli 4, określa się za pomocą wartości „00”.  
9.3.2.2 Odniesienie do organu certyfikacji  
CSM_138 Odniesienie do organu certyfikacji wykorzystuje się do okre­ 
ślenia klucza publicznego, który ma zostać użyty do wery­
fikacji podpisu certyfikatu. Odniesienie do organu certyfi­
kacji pokrywa się zatem z odniesieniem do posiadacza certy­
fikatu w certyfikacie odpowiedniego organu certyfikacji.  
CSM_139 Certyfikat główny ERCA jest certyfikatem z podpisem 
własnym, tj. odniesienie do organu certyfikacji pokrywa 
się z odniesieniem do posiadacza certyfikatu w certyfikacie.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 469  
CSM_140 W przypadku certyfikatu łączącego ERCA odniesienie do 
posiadacza certyfikatu pokrywa się z odniesieniem do posia­
dacza certyfikatu nowego certyfikatu głównego ERCA. 
W przypadku certyfikatu łączącego odniesienie do organu 
certyfikacji pokrywa się z odniesieniem do posiadacza certy­
fikatu poprzedniego certyfikatu głównego ERCA.  
9.3.2.3 Upoważnienie posiadacza certyfikatu  
▼M1 
CSM_141 Upoważnienie posiadacza certyfikatu służy do identyfiko ­
wania rodzaju certyfikatu. Składa się ono z sześciu najbar­
dziej znaczących bajtów identyfikatora aplikacji tachogra­
ficznej, połączonych z typem urządzenia, który wskazuje 
typ urządzenia, dla którego certyfikat jest przeznaczony. 
W przypadku certyfikatu VU, certyfikatu karty kierowcy 
lub certyfikatu karty warsztatowej typu urządzenia używa 
się również w celu rozróżnienia świadectwa wzajemnego 
uwierzytelnienia i certyfikatu na potrzeby tworzenia podpisu 
cyfrowego (zob. pkt 9.1 i dodatek 1, typ danych Equipment­
Type).  
▼B 
9.3.2.4 Klucz publiczny  
Klucz publiczny zawiera dwa elementy danych: standardowe parame try 
domeny stosowane z kluczem publicznym w certyfikacie i wartość punktu 
publicznego.  
CSM_142 Element danych „parametry domeny” zawiera jeden z iden­
tyfikatorów obiektu określony w tabeli 1 w celu odniesienia 
do zestawu standardowych parametrów domeny.  
CSM_143 Element danych „punkt publiczny” zawiera punkt publiczn y. 
Punkty publiczne krzywej eliptycznej przekształca się w ciągi 
oktetowe, jak określono w [TR-03111]. Stosuje się nieskom­
presowany format kodowania. Podczas odzyskiwania punktu 
krzywej eliptycznej z jej zakodowanego formatu zawsze prze­
prowadza się autoryzacje opisane w [TR-03111].  
9.3.2.5 odniesienie do posiadacza certyfikatu  
CSM_144 Odniesienie do posiadacza certyfikatu to identyfikator klucza 
publicznego umieszczony w certyfikacie. Używa się go 
celem odniesienia do tego klucza publicznego w innych 
certyfikatach.  
CSM_145 W przypadku certyfikatów kart i certyfikatów urządzeń 
zewnętrznych GNSS odniesienie do posiadacza certyfikatu 
posiada typ danych
  , okre­ 
ślony w dodatku 1.  
CSM_146 W przypadku przyrządów rejestrujących producent, skła­
dając wniosek o certyfikat, może znać specyficzny dla 
danego producenta numer seryjny VU, dla którego przezna­
czony jest dany certyfikat i powiązany klucz prywatny, ale 
nie musi go znać. W pierwszym przypadku odniesienie do 
posiadacza certyfikatu posiada typ danych
  
, określony w dodatku 1. 
W tym drugim przypadku odniesienie do posiadacza certy­
fikatu posiada typ danych
  ,  
określony w dodatku 1.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 470  
Uwaga:  W przypadku certyfikatu karty wartość CHR musi 
być równa wartości cardExtendedSerialNumber w EF_ICC; 
zob. dodatek 2. W przypadku certyfikatu EGF wartość CHR 
musi być równa wartości sensorGNSSSerialNumber 
w EF_ICC; zob. dodatek 14. W przypadku certyfikatu VU 
wartość CHR musi być równa elementowi vuSerialNumber 
w VuIdentification (zob. dodatek 1), chyba że producent nie 
zna specyficznego dla danego producenta numeru seryjnego, 
w momencie gdy wystąpiono o certyfikat.  
▼B 
CSM_147 W przypadku certyfikatów ERCA i MSCA odniesienie do pos ia­
dacza certyfikatu posiada typ danych
  ,  
określony w dodatku 1.  
9.3.2.6 Data wejścia w życie certyfikatu  
▼M1 
CSM_148 Data wejścia w życie certyfikatu określa datę i godzinę  
rozpoczęcia okresu ważności certyfikatu.  
▼B 
9.3.2.7 Data wygaśnięcia certyfikatu  
CSM_149 Data wygaśnięcia certyfikatu określa datę i godzinę zak oń­
czenia okresu ważności certyfikatu.  
9.3.2.8 Podpis certyfikatu  
CSM_150 Podpis na certyfikacie tworzy się nad zakodowaną treści ą 
certyfikatu, uwzględniając znacznik i długość treści certyfi­
katu. Algorytmem podpisu jest ECDSA, jak określono 
w [DSS], używający algorytmu skrótu powiązanego z wiel­
kością klucza jednostki podpisującej, jak określono 
w CSM_50. Format podpisu jest odkryty, jak określono 
w [TR-03111].  
9.3.3  Składanie wniosków o certyfikaty  
CSM_151  ►M1 Składając wniosek o certyfikat, MSCA przesyła 
ERCA następujące dane: ◄  
— identyfikator profilu certyfikatu, którego dotyczy 
wniosek;  
— odniesienie do organu certyfikacji, w przypadku którego 
oczekuje się, że zostanie użyte do podpisania certyfikatu;  
— klucz publiczny, który ma zostać podpisany.  
CSM_152 Oprócz danych określonych w CSM_151 MSCA przesyła 
ERCA następujące dane we wniosku o certyfikat, co umoż­
liwi ERCA utworzenie odniesienia do posiadacza certyfikatu 
dla nowego certyfikatu MSCA:  
— numeryczny kod krajowy organu certyfikacji (typ 
danych
  , określony w dodatku 1);  
— alfanumeryczny kod krajowy organu certyfikacji (typ 
danych
  , określony w dodatku 1);  
— 1-bajtowy numer seryjny umożliwiającym rozróżnienie 
poszczególnych kluczy organu certyfikacji w przypadku 
zmiany kluczy;  
— 2-bajtowe pole zawierające dodatkowe informacje na 
temat określonego organu certyfikacji.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 471  
CSM_153 Producent urządzenia przesyła MSCA następujące dane we 
wniosku o certyfikat, co umożliwi MSCA utworzenie odnie­
sienia do posiadacza certyfikatu dla nowego certyfikatu 
urządzenia:  
— numer seryjny urządzenia, unikalny dla producenta, typu 
urządzenia i miesiąc wyprodukowania, jeżeli dane te są 
znane (zob. CSM_154). W przeciwnym razie – unika­
towy identyfikator wniosku o certyfikat,  
— miesiąc i rok produkcji urządzenia lub miesiąc i rok 
sporządzenia wniosku o certyfikat.  
Producent zapewnia, aby przedmiotowe dane były prawidłowe, a ce rty­
fikat zwrócony przez MSCA został umieszczony w przewidzianym ur zą­
dzeniu.  
▼B 
CSM_154 W przypadku VU producent, składając wniosek o certyfika t, 
może znać specyficzny dla danego producenta numer 
seryjny VU, dla którego przeznaczony jest dany certyfikat 
i powiązany klucz prywatny, ale nie musi go znać. Produ­
cent VU przesyła MSCA numer seryjny, jeżeli jest on 
znany. Jeżeli nie jest znany, producent jednoznacznie iden­
tyfikuje każdy wniosek o certyfikat i przesyła MSCA taki 
numer seryjny wniosku o certyfikat. Otrzymany certyfikat 
będzie wówczas zawierał numer seryjny wniosku o certy­
fikat. Po umieszczeniu certyfikatu w określonym VU produ­
cent informuje MSCA o połączeniu między numerem 
seryjnym wniosku o certyfikat a identyfikacją VU.  
10. WZAJEMNE UWIERZYTELNIANIE I BEZPIECZNA WYMIANA 
KOMUNIKATÓW MIĘDZY VU A KARTĄ  
10.1.  Uwagi ogólne  
CSM_155 Na wysokim szczeblu bezpieczna łączność między przy­
rządem rejestrującym a kartą do tachografu odbywa się 
w następujących etapach:  
— po pierwsze każda strona wykazuje drugiej, że posiada 
ważny certyfikat klucza publicznego, podpisany przez 
organ certyfikacji państwa członkowskiego. Z kolei 
certyfikat klucza publicznego MSCA musi zostać podpi­
sany przez Główny Europejski Organ Certyfikacji. Etap 
ten nazywany jest weryfikacją łańcucha certyfikatów 
i został szczegółowo opisany w sekcji 10.2;  
— po drugie przyrząd rejestrujący wykazuje karcie, że 
posiada klucz prywatny odpowiadający kluczowi 
publicznemu w przedstawionym certyfikacie. Dokonuje 
tego poprzez podpisanie losowego numeru wysłanego 
przez kartę. Karta weryfikuje podpis na losowym 
numerze. Jeżeli weryfikacja zakończy się powodzeniem, 
VU zostaje uwierzytelniony. Etap ten nazywany jest 
uwierzytelnieniem VU i został szczegółowo opisany 
w sekcji 10.3;  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 472  
— po trzecie obie strony niezależnie obliczają dwa klucze 
sesji AES, korzystając z asymetrycznego algorytmu 
uzgadniania klucza. Korzystając z jednego z tych kluczy 
sesji karta tworzy kod uwierzytelniania komunikatów 
(MAC) w odniesieniu do niektórych danych wysłanych 
przez VU. VU weryfikuje MAC. Jeżeli weryfikacja 
zakończy się powodzeniem, karta zostaje uwierzytel­
niona. Etap ten nazywany jest uwierzytelnieniem karty 
i został szczegółowo opisany w sekcji 10.4;  
— po czwarte VU i karta używają zatwierdzonych kluczy 
sesji w celu zapewnienia poufności, integralności i auten­
tyczności wszystkich wymienianych komunikatów. Etap 
ten nazywany jest bezpieczną wymianą komunikatów 
i został szczegółowo opisany w sekcji 10.5.  
CSM_156 Mechanizm opisany w CSM_155 jest uruchamiany przez 
przyrząd rejestrujący za każdym razem, gdy w jeden z czyt­
ników kart zostaje włożona karta.  
10.2.  Wzajemna weryfikacja łańcucha certyfikatów  
10.2.1  Weryfikacja łańcucha certyfikatów karty przez VU  
CSM_157  ►M1 Przyrządy rejestrujące używają protokołu przedsta­
wionego na rys. 4 w celu weryfikacji łańcucha certyfikatów 
karty do tachografu. Dla każdego certyfikatu odczytywanego 
z karty przyrząd rejestrujący weryfikuje prawidłowość pola 
Upoważnienie Posiadacza Certyfikatu (CHA):  
— Pole CHA certyfikatu karty wskazuje certyfikat karty na 
potrzeby wzajemnego uwierzytelnienia (zob. dodatek 1, 
typ danych EquipmentType).  
— CHA certyfikatu Card.CA musi wskazywać MSCA.  
— CHA certyfikatu Card.Link musi wskazywać ERCA. ◄  
Uwagi do rys. 4:  
— certyfikaty i klucze publiczne karty wskazane na 
rysunku są certyfikatami i kluczami, których używa się 
do wzajemnego uwierzytelnienia. W sekcji 9.1.5 ozna­
czono je jako Card_MA;  
— certyfikaty i klucze publiczne Card.CA wskazane na 
rysunku są certyfikatami i kluczami używanymi do 
podpisywania certyfikatów karty i jest to wskazane 
w CAR certyfikatu Card.CA. W sekcji 9.1.3 oznaczono 
je jako MSCA_Card;  
— certyfikat Card.CA.EUR wspomniany na rysunku jest 
europejskim certyfikatem głównym wskazanym 
w CAR certyfikatu Card.CA;  
— certyfikat Card.Link wskazany na rysunku jest certyfi­
katem łączącym karty, o ile istnieje. Jak określono 
w sekcji 9.1.2, jest to certyfikat łączący dla nowej 
pary europejskich kluczy głównych wygenerowanej 
przez ERCA i podpisanej za pomocą poprzedniego euro­
pejskiego klucza prywatnego;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 473  
— certyfikat Card.Link.EUR jest europejskim certyfikatem 
głównym wskazanym w CAR certyfikatu Card.Link.  
CSM_158 Jak wskazano na rys. 4, weryfikacja łańcucha certyfikat ów 
karty rozpoczyna się po włożeniu karty. Przyrząd rejestru­
jący odczytuje odniesienie do posiadacza karty 
(
 ) z pliku elementarnego 
ICC. VU sprawdza, czy zna kartę tj. czy pomyślnie zwery­
fikował łańcuch certyfikatów karty w przeszłości i zapisało 
go na potrzeby przyszłych odniesień. Jeżeli VU zna kartę, 
certyfikat karty nadal jest ważny, a proces jest kontynuo­
wany i następuje weryfikacja łańcucha certyfikatów VU. 
W przeciwnym razie VU kolejno odczytuje z karty certy­
fikat MSCA_Card, który ma służyć do weryfikacji certyfi­
katu karty Card.CA, certyfikat EUR, który ma służyć do 
weryfikacji certyfikatu MSCA_Card, oraz ewentualnie certy­
fikat łączący, do momentu aż znajdzie certyfikat, który 
rozpozna lub może zweryfikować. Jeżeli znajdzie taki certy­
fikat, VU używa tego certyfikatu w celu zweryfikowania 
podstawowych certyfikatów karty, które odczytał z karty. 
Jeżeli proces przebiegnie pomyślnie, nastąpi weryfikacja 
łańcucha certyfikatów VU. Jeżeli nie, VU zignoruje kartę.  
Uwaga:  istnieją trzy sposoby na rozpoznanie certyfikatu 
Card.CA.EUR przez VU:  
— certyfikat Card.CA.EUR jest taki sam jak certyfikat EUR 
VU; 
— certyfikat Card.CA.EUR poprzedza certyfikat EUR VU 
i VU zawierał już ten certyfikat w chwili wydania (zob. 
CSM_81);  
— certyfikat Card.CA.EUR zastępuje certyfikat EUR VU 
i VU otrzymał w przeszłości certyfikat łączący z innej 
karty do tachografu, zweryfikował go i zapisał na 
potrzeby przyszłych odniesień.  
CSM_159 Jak wskazano na rys. 4, po zweryfikowaniu przez VU aute n­
tyczności i ważności uprzednio nieznanego certyfikatu VU 
może zapisać ten certyfikat na potrzeby przyszłych odnie­
sień, tak aby nie musiał po raz kolejny weryfikować auten­
tyczności tego certyfikatu, gdy zostanie mu ponownie przed­
stawiony. Zamiast zapisywać cały certyfikat, VU może 
zdecydować się na zapisanie jedynie treści certyfikatu, jak 
określono w sekcji 9.3.2.  ►M1 Zważywszy że przechowy­
wanie wszystkich pozostałych typów certyfikatu jest fakul­
tatywne, VU musi przechowywać nowy certyfikat łączący 
przedstawiony przez kartę. ◄  
CSM_160 VU weryfikuje czasową ważność każdego certyfikatu odczy ­
tanego 
z karty lub przechowywanego w jej pamięci i odrzuca 
certyfikaty, które wygasły. W celu zweryfikowania czasowej 
ważności certyfikatu przedstawionego przez kartę VU używa 
swojego wewnętrznego zegara.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 474  
Rys. 4  
Protokół weryfikacji łańcucha certyfikatów karty przez VU
  
10.2.2  Weryfikacja łańcucha certyfikatów VU przez kart ę 
CSM_161  ►M1 Karty do tachografu używają protokołu przedstawio­
nego na rys. 5 w celu weryfikacji łańcucha certyfikatów 
VU. Dla każdego certyfikatu przedstawionego przez przy­
rząd rejestrujący karta weryfikuje prawidłowość pola 
Upoważnienie Posiadacza Certyfikatu (CHA):  
— CHA certyfikatu VU.Link musi wskazywać ERCA.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 475  
— CHA certyfikatu VU.CA musi wskazywać MSCA.  
— Pole CHA certyfikatu VU wskazuje certyfikat VU na 
potrzeby wzajemnego uwierzytelnienia (zob. dodatek 1, 
typ danych EquipmentType). ◄  
Rys. 5  
Protokół weryfikacji łańcucha certyfikatów VU przez kart ę
 
Uwagi do rys. 5:  
— certyfikaty i klucze publiczne VU wskazane na rysunku są cert yfika­
tami i kluczami, których używa się do wzajemnego uwierzytelnien ia. 
W sekcji 9.1.4 oznaczono je jako VU_MA;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 476  
— certyfikaty i klucze publiczne VU.CA wskazane na rysunku są c erty­
fikatami i kluczami używanymi do podpisywania certyfikatów VU 
i urządzenia zewnętrznego GNSS. W sekcji 9.1.3 oznaczono je jak o 
MSCA_VU-EGF;  
— certyfikat VU.CA.EUR przedstawiony na rysunku jest europejski m 
certyfikatem głównym wskazanym w CAR certyfikatu VU.CA;  
— certyfikat VU.Link wskazany na rysunku jest certyfikatem łącz ącym 
VU, o ile istnieje. Jak określono w sekcji 9.1.2, jest to certy fikat 
łączący dla nowej pary europejskich kluczy głównych wygenero­
wanej przez ERCA i podpisanej za pomocą poprzedniego europej­
skiego klucza prywatnego;  
— certyfikat VU.Link.EUR jest europejskim certyfikatem głównym 
wskazanym w CAR certyfikatu VU.Link.  
CSM_162 Jak wskazano na rys. 5, weryfikacja łańcucha certyfikat ów 
przyrządu rejestrującego rozpoczyna się, gdy przyrząd rejes­
trujący podejmuje próbę ustawienia swojego własnego 
klucza publicznego w celu użycia go w karcie do tacho­
grafu. Jeżeli proces ten powiedzie się, oznacza to, że karta 
pomyślnie zweryfikowała łańcuch certyfikatów VU w prze­
szłości i zapisała certyfikat VU na potrzeby przyszłych 
odniesień. W tym przypadku certyfikat VU ustawia się 
jako używany, a proces jest kontynuowany i następuje 
uwierzytelnienie VU. Jeżeli karta nie zna certyfikatu VU, 
VU kolejno przedstawia certyfikat VU.CA, który ma służyć 
do weryfikacji certyfikatu VU, certyfikat VU.CA.EUR, 
który ma służyć do weryfikacji certyfikatu VU.CA, oraz 
ewentualnie certyfikat łączący, w celu znalezienia certyfi­
katu rozpoznanego lub weryfikowalnego przez kartę. 
W przypadku znalezienia takiego certyfikatu karta używa 
tego certyfikatu do zweryfikowania podstawowych certyfi­
katów VU przedstawionych jej przez VU. Jeżeli proces 
przebiegnie pomyślnie, VU ostatecznie ustawi swój klucz 
publiczny do używania w karcie do tachografu. Jeżeli nie, 
VU zignoruje kartę.  
Uwaga: istniej ą dwa sposoby na rozpoznanie certyfikatu 
VU.CA.EUR:  
— certyfikat VU.CA.EUR jest taki sam jak certyfikat EUR 
karty;  
— certyfikat VU.CA.EUR poprzedza certyfikat EUR karty 
i karta zawierała już ten certyfikat w chwili wydania 
(zob. CSM_91);  
— certyfikat VU.CA.EUR zastępuje certyfikat EUR karty 
i karta otrzymała w przeszłości certyfikat łączący 
z innego przyrządu rejestrującego, zweryfikowała go 
i zapisała na potrzeby przyszłych odniesień.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 477  
CSM_163 VU używa polecenia MSE:Set AT, aby ustawić swój klucz 
publiczny do używania w karcie do tachografu. Jak okre­ 
ślono w dodatku 2, polecenie to zawiera opis mechanizmu 
kryptograficznego, który będzie używany wraz z usta­
wionym kluczem. Mechanizm ten określa się mianem uwie­
rzytelnienia VU za pomocą algorytmu ECDSA w połączeniu 
z algorytmem skrótu powiązanym z wielkością pary kluczy 
VU VU_MA, jak określono w CSM_50.  
CSM_164 Polecenie MSE: Set AT zawiera również opis pary kluczy 
efemerycznych, których VU będzie używał podczas uzgad­
niania klucza sesji (zob. sekcja 10.4). W związku z tym 
przed wysłaniem polecenia MSE: Set AT VU generuje 
parę kluczy efemerycznych ECC. W celu wygenerowania 
pary kluczy efemerycznych VU używa standardowych para­
metrów domeny wskazanych w certyfikacie karty. Parę 
kluczy efemerycznych oznacza się jako (VU.SK  eph , 
VU.PK  eph , Card.DP). VU uznaje współrzędną x 
efemerycznego punktu publicznego ECDH za identyfikację 
klucza; określa się to mianem skompresowanej reprezentacji 
klucza publicznego i oznacza jako Comp(VU.PK  eph ). 
▼M1 
CSM_165 Jeżeli polecenie MSE: Set AT jest skuteczne, karta usta wia 
wskazany VU.PK w celu późniejszego użycia podczas 
uwierzytelnienia przyrządu rejestrującego i tymczasowo 
zapisuje Comp(VU.PKeph). W przypadku wysłania co 
najmniej dwóch skutecznych poleceń MSE: Set AT przed 
uzgodnieniem klucza sesji karta zapisuje tylko ostatni otrzy­
many Comp(VU.PKeph). Karta zeruje Comp(VU.PKeph) 
po skutecznym poleceniu GENERAL AUTHENTICATE.  
▼B 
CSM_166 Karta weryfikuje czasową ważność każdego certyfikatu 
przedstawionego przez VU lub wskazanego przez VU 
przez odniesienie i zapisanego w pamięci karty i odrzuca 
certyfikaty, które wygasły.  
CSM_167 W celu zweryfikowania czasowej ważności certyfikatu 
przedstawionego przez VU każda karta do tachografu zapi­
suje wewnętrznie niektóre dane pokazujące czas bieżący. 
Dane te nie mogą podlegać bezpośredniej aktualizacji 
przez VU. W momencie wydania czas bieżący karty ustawia 
się tak, aby odpowiadał dacie wejścia w życie certyfikatu 
karty Card_MA. Karta aktualizuje swój czas bieżący, jeżeli 
data wejścia w życie autentycznego certyfikatu będącego 
„wiarygodnym źródłem czasu” i przedstawionego przez 
VU jest późniejsza niż czas bieżący określony na karcie. 
W takim przypadku karta ustawia swój czas bieżący 
zgodnie z datą wejścia w życie takiego certyfikatu. Za 
wiarygodne źródło czasu karta uznaje wyłącznie następujące 
certyfikaty:  
— certyfikaty łączące ERCA drugiej generacji  
— certyfikaty MSCA drugiej generacji  
— certyfikaty VU drugiej generacji wydane przez to samo 
państwo, które wydało certyfikaty własne karty.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 478  
Uwaga:  ostatni wymóg oznacza, że karta jest w stanie 
rozpoznać CAR certyfikatu VU, tj. certyfikatu 
MSCA_VU-EGF. Nie będzie się on pokrywał z CAR certy­
fikatu własnego karty, którym jest certyfikat MSCA_Card.  
CSM_168 Jak wskazano na rys. 5, po zweryfikowaniu przez kartę 
autentyczności i ważności uprzednio nieznanego certyfikatu, 
karta może zapisać ten certyfikat na potrzeby przyszłych 
odniesień, tak aby nie musiała po raz kolejny weryfikować 
autentyczności tego certyfikatu, gdy zostanie jej ponownie 
przedstawiony. Zamiast zapisywać cały certyfikat, karta 
może zdecydować się na zapisanie jedynie treści certyfikatu, 
jak określono w sekcji 9.3.2.  
10.3.  Uwierzytelnienie VU  
CSM_169 Przyrządy rejestrujące i karty używają protokołu uwierz ytel­
niania Vu wskazanego na rys. 6 w celu uwierzytelnienia 
VU w stosunku do karty. Uwierzytelnienie VU umożliwia 
karcie do tachografu wyraźne zweryfikowanie, że VU jest 
autentyczny. W tym celu VU używa swojego klucza 
prywatnego do podpisania żądania wygenerowanego przez 
kartę.  
CSM_170  ►M1 Oprócz żądania karty VU umieszcza w podpisie 
odniesienie do posiadacza certyfikatu uzyskane z certyfikatu 
karty. ◄  
Uwaga:  gwarantuje to, że karta, w odniesieniu do której 
VU się uwierzytelnia, jest tą samą kartą, której łańcuch 
certyfikatów został wcześniej zweryfikowany przez VU.  
CSM_171 VU umieszcza również w podpisie identyfikator efemerycz ­
nego klucza publicznego Comp(VU.PK  eph ), z którego 
będzie korzystał w celu ustanowienia bezpiecznej wymiany 
komunikatów podczas procesu uwierzytelniania chipu okre­ 
ślonego w sekcji 10.4.  
Uwaga:  gwarantuje to, że VU, z którym karta komunikuje 
się podczas sesji bezpiecznej wymiany komunikatów, jest 
tym samym VU, który został uwierzytelniony przez kartę.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 479  
Rysunek 6  
Protokół uwierzytelniania VU
  
▼B 
CSM_172 Jeżeli VU wysyła wielokrotnie polecenie GET CHAL­
LENGE podczas uwierzytelniania VU, karta zwraca za 
każdym razem nowe 8-bajtowe losowe żądanie, ale zapisuje 
tylko ostatnie żądanie.  
CSM_173 Algorytmem podpisywania używanym przez VU w celu 
uwierzytelnienia VU jest ECDSA, jak określono w [DSS], 
używający algorytmu skrótu powiązanego z wielkością 
klucza pary kluczy VU VU_MA, jak określono w CSM_50. 
Format podpisu jest odkryty, jak określono w [TR-03111]. 
VU przesyła uzyskany podpis karcie.  
▼M1 
CSM_174 Po otrzymaniu podpisu VU w poleceniu EXTERNAL 
AUTHENTICATE karta:  
— oblicza token uwierzytelniania poprzez połączenie 
Card.CHR, żądania karty rcard i identyfikatora efeme­
rycznego klucza publicznego VU Comp(VU.PKeph);  
— weryfikuje podpis VU za pomocą algorytmu ECDSA, 
używając algorytmu skrótu powiązanego z wielkością 
pary kluczy VU VU_MA, jak określono w CSM_50, 
w połączeniu z VU.PK i obliczonym tokenem 
uwierzytelniania.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 480  
10.4.  Uwierzytelnianie chipu i uzgadnianie klucza sesji  
CSM_175 Przyrządy rejestrujące i karty korzystają z protokołu u wie­
rzytelniania chipu wskazanego na  rys. 7  w celu uwierzytel­
nienia karty w stosunku do VU. Uwierzytelnienie chipu 
umożliwia przyrządowi rejestrującemu wyraźne zweryfiko­
wanie, że karta jest autentyczna.  
Rys. 7  
Uwierzytelnianie chipu i uzgadnianie klucza sesji
  
CSM_176 VU i karta podejmują następujące kroki:  
1. przyrząd rejestrujący inicjuje proces uwierzytelniania 
chipu poprzez wysłanie polecenia MSE: Set AT określa­
jącego uwierzytelnianie chipu za pomocą algorytmu 
ECDH, w wyniku którego długość klucza sesji AES 
jest powiązana z wielkością klucza w parze kluczy 
karty Card_MA, jak określono w CSM_50. VU określa 
wielkość klucza w parze kluczy karty na podstawie 
certyfikatu karty;  
▼M1 
2. VU przesyła karcie punkt publiczny VU.PK  eph swojej 
pary kluczy efemerycznych. Punkt publiczny przekształca 
się w ciąg oktetowy, jak określono w [TR-03111]. Stosuje 
się nieskompresowany format kodowania. Jak wyjaśniono 
w CSM_164, VU wygenerował tę parę kluczy efemerycz­
nych przed zweryfikowaniem łańcucha certyfikatów VU. 
VU przesłał karcie identyfikator efemerycznego klucza 
publicznego Comp(VU.PK  eph ) i karta zapisuje ten 
identyfikator;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 481  
3. karta oblicza Comp(VU.PK  eph ) na podstawie VU.PK  eph 
i porównuje go z zapisaną wartością Comp(VU.PK  eph ); 
4. używając algorytmu ECDH w połączeniu ze statycznym 
kluczem prywatnym karty i efemerycznym kluczem 
publicznym VU, karta oblicza tajny K;  
5. karta wybiera losowy 8-bajtowy identyfikator jednora­
zowy N  PICC i używa go do wyprowadzenia dwóch 
kluczy sesji AES K  MAC i K  ENC z K. Zob. CSM_179;  
▼M1 
6. za pomocą K  MAC , karta oblicza token uwierzytelniania 
w odniesieniu do identyfikatora efemerycznego punktu 
publicznego VU: T  PICC = CMAC(K  MAC , VU.PK  eph ). 
Punkt publiczny musi być w formacie używanym przez 
VU (zob. ppkt 2 powyżej). Karta wysyła N  PICC i T PICC 
do przyrządu rejestrującego;  
▼B 
7. używając algorytmu ECDH w połączeniu ze statycznym 
kluczem publicznym karty i efemerycznym kluczem 
prywatnym VU, przyrząd rejestrujący oblicza ten sam 
tajny K co karta w ramach kroku 4;  
8. VU wyprowadza klucze sesji K  MAC i K  ENC z K i N  PICC ; 
zob. CSM_179;  
9. VU weryfikuje token uwierzytelniania T  PICC . 
CSM_177 W ramach powyższego kroku 3 karta oblicza 
Comp(VU.PKeph) jako współrzędną x punktu publicznego 
w VU.PKeph.  
CSM_178 W ramach powyższych kroków 4 i 7 karta i przyrząd rejes ­
trujący używają algorytmu ECKA-EG, jak określono 
w [TR-03111].  
CSM_179 W ramach powyższych kroków 5 i 8 karta i przyrząd rejes ­
trujący używają funkcji wyprowadzania klucza w odnie­
sieniu do kluczy sesji AES zdefiniowanych w [TR-03111] 
z następującą dokładnością i następującymi zmianami:  
— wartość licznika wynosi „00 00 00 01” w odniesieniu 
do K  ENC i „00 00 00 02” w odniesieniu do K  MAC ; 
— używa się opcjonalnego identyfikatora jednorazowego  r, 
który jest równy N  PICC ; 
— w celu wyprowadzenia 128-bitowych kluczy AES 
używa się algorytmu skrótu SHA-256;  
— w celu wyprowadzenia 192-bitowych kluczy AES 
używa się algorytmu skrótu SHA-384;  
— w celu wyprowadzenia 256-bitowych kluczy AES 
używa się algorytmu skrótu SHA-512.  
Długość kluczy sesji (tj. długość, do której skrócono skrót) 
jest powiązana z wielkością pary kluczy Card_MA, jak 
określono w CSM_50.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 482  
CSM_180 W powyższych krokach 6 i 9 karta i przyrząd rejestrując y 
używają algorytmu AES w trybie CMAC, jak określono 
w [SP 800-38B]. Długość T  PICC jest powiązana z długością 
kluczy sesji AES, jak określono w CSM_50.  
10.5.  Bezpieczna wymiana komunikatów  
10.5.1  Uwagi ogólne  
CSM_181 Wszystkie polecenia i odpowiedzi wymieniane między 
przyrządem rejestrującym a kartą do tachografu po 
pomyślnym uwierzytelnieniu chipu oraz do zakończenia 
sesji są chronione za pomocą bezpiecznej wymiany komu­
nikatów.  
CSM_182 Z wyjątkiem sytuacji, w której ma miejsce odczyt z plik u 
z warunkiem dostępu SM-R-ENC-MAC-G2 (zob. dodatek 2 
sekcja 4), bezpieczną wymianę komunikatów stosuje się 
w trybie tylko uwierzytelniania. W tym trybie kryptogra­
ficzną sumę kontrolną (zwaną również MAC) dodaje się 
do wszystkich poleceń i odpowiedzi w celu zapewnienia 
autentyczności i integralności komunikatów.  
CSM_183 Przy odczycie danych z pliku z warunkiem dostępu SM-R- 
ENC-MAC-G2 bezpieczną wymianę komunikatów stosuje 
się w trybie uwierzytelniania po wcześniejszym zaszyfro­
waniu, co oznacza, że dane odpowiedzi najpierw są szyfro­
wane w celu zapewnienia poufności komunikatu, a następnie 
obliczany jest MAC w stosunku do sformatowanych zaszyf­
rowanych danych w celu zapewnienia autentyczności i inte­
gralności.  
CSM_184 W ramach bezpiecznej wymiany komunikatów stosuje się 
AES określony w [AES] z kluczami sesji K  MAC i K  ENC 
uzgodnionymi w procesie uwierzytelniania chipu.  
CSM_185 Jako licznik sekwencji wysyłania (SSC) stosuje się licz bę 
całkowitą bez znaku w celu zapobieżenia atakom przez 
powtórzenie. Rozmiar SSC jest równy rozmiarowi bloku 
AES, tj. wynosi 128 bitów. SSC ma format, w którym 
najbardziej znaczący bit znajduje się na początku. Licznik 
sekwencji wysyłania jest zerowany (tj. ma wartość „00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00”) w momencie 
rozpoczęcia bezpiecznej wymiany komunikatów. Wartość 
SSC jest zwiększana przed każdym wygenerowaniem pole­
cenia lub odpowiedzi APDU, czyli ponieważ wartością 
początkową SSC w sesji bezpiecznej wymiany komuni­
katów jest 0, wartość SSC w pierwszym poleceniu będzie 
wynosiła 1. Wartość SSC dla pierwszej odpowiedzi będzie 
wynosiła 2.  
CSM_186 W przypadku szyfrowania komunikatów stosuje się klucz 
K ENC z AES w trybie wiązania bloków zaszyfrowanych, 
jak określono w normie [ISO 10116], z naprzemiennym 
parametrem  m = 1 oraz wektorem inicjującym SV = 
E(K  ENC , SSC), tj. bieżącą wartością licznika sekwencji 
wysyłania zaszyfrowanego kluczem K  ENC . 
CSM_187 Do uwierzytelniania komunikatów stosuje się klucz K  MAC 
z AES w trybie CMAC, jak określono w [SP 800-38B]. 
Długość MAC jest powiązana z długością kluczy sesji 
AES, jak określono w CSM_50. Licznik sekwencji wysy­ 
łania uwzględnia się w MAC poprzez dodanie go przed 
datagramem, który ma zostać uwierzytelniony.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 483  
10.5.2  Struktura bezpiecznego komunikatu  
CSM_188 W bezpiecznej wymianie komunikatów używa się 
wyłącznie obiektów danych bezpiecznej wymiany komuni­
katów (zob. [ISO 7816-4]) wymienionych w tabeli 5. 
W każdym komunikacie wspomniane obiekty danych 
stosuje się w kolejności określonej w poniższej tabeli.  
Tabela 5  
Obiekty danych bezpiecznej wymiany komunikatów  
Nazwa obiektu danych  Znacznik  Obecność: 
obowiązkowa (M), 
warunkowa (C) lub 
zabroniona (F) w  
poleceniach  odpowie­
dziach  
Odkryta wartość niekodowana w BER- 
TLV  „81”  C  C  
Odkryta wartość kodowana w BER- 
TLV, lecz nie zawiera obiektów danych 
bezpiecznej wymiany komunikatów  „B3”  C  C  
Po wskaźniku treści wypełnienia nastę­
puje kryptogram, wartość odkryta nie 
jest kodowana w BER-TLV  „87”  C  C  
Chroniona długość  „97”  C  F  
Status przetwarzania  „99”  F  M  
Kryptograficzna suma kontrolna  „8E”  M  M  
Uwaga:  jak określono w dodatku 2, karty do tachografu 
mogą obsługiwać polecenia READ BINARY i UPDATE 
BINARY z nieparzystym bajtem INS („B1” odp. „D7”). 
Wymaga się, aby przedstawione warianty poleceń umożli­
wiały odczyt i aktualizację plików o rozmiarze 32 768 
bajtów lub więcej. W przypadku zastosowania takiego 
wariantu używa się obiektu danych ze znacznikiem „B3” 
zamiast obiektu ze znacznikiem „81”. Aby uzyskać więcej 
informacji, zob. dodatek 2.  
CSM_189 Wszystkie obiekty danych bezpiecznej wymiany komuni­
katów koduje się w DER TLV, jak określono w [ISO 
8825-1]. W wyniku takiego kodowania uzyskuje się nastę­
pującą strukturę TLV:  
znacznik: znacznik jest zakodowany w jednym oktecie lub 
dwóch oktetach i określa treść;  
długość: długość jest zakodowana jako liczba całkowita 
bez znaku w jednym oktecie, dwóch lub trzech 
oktetach, co skutkuje uzyskaniem maksymalnej 
długości 65 535 oktetów. Stosuje się minimalną 
liczbę oktetów;  
wartość: wartość nie jest zakodowana w żadnym oktecie 
lub jest zakodowana w większej liczbie oktetów.  
CSM_190 Polecenia APDU chronione bezpieczną wymianą komuni­
katów generuje się w następujący sposób:  
— nagłówek polecenia uwzględnia się w obliczeniach 
MAC, w związku z czym wartość „0C” stosuje się 
w przypadku klasy bajtów CLA;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 484  
— jak określono w dodatku 2, wszystkie bajty INS są 
parzyste, ewentualnie z wyjątkiem nieparzystych bajtów 
INS w przypadku poleceń READ BINARY i UPDATE 
BINARY;  
— wartość rzeczywista Lc zostanie zmieniona na Lc' po 
zastosowaniu bezpiecznej wymiany komunikatów;  
— pole danych składa się z obiektów danych bezpiecznej 
wymiany komunikatów;  
— w chronionym poleceniu APDU nowy bajt Le otrzy­
muje wartość „00”. W razie konieczności obiekt danych 
„97” umieszcza się w polu danych w celu przekazania 
wartości oryginalnej bajtu Le.  
▼M1 
CSM_191 Każdy obiekt danych wymagający zaszyfrowania wypełnia 
się zgodnie z [ISO 7816-4] przy użyciu wskaźnika treści 
wypełnienia „01”. Na potrzeby obliczenia MAC obiekty 
danych w APDU wypełnia się również zgodnie z [ISO 
7816-4].  
Uwaga:  wypełnianie na potrzeby bezpiecznej wymiany 
komunikatów zawsze przeprowadza się za pomocą warstwy 
bezpiecznej wymiany komunikatów, a nie algorytmów 
CMAC czy CBC.  
Podsumowanie i przyk łady 
Polecenie APDU z zastosowaniem bezpiecznej wymiany komunikatów 
będzie miało następującą strukturę w zależności od przypadku od powia­
dającego mu niezabezpieczonego polecenia („DO” oznacza obiekt 
danych):  
Przypadek 1: CLA INS P1 P2 || Lc' || DO „8E” 
|| Le 
Przypadek 2: CLA INS P1 P2 || Lc' || DO „97” || 
DO „8E” || Le  
Przypadek 3 (parzysty bajt INS): CLA INS P1 P2 || Lc' || DO „81 ” || 
DO „8E” || Le  
Przypadek 3 (nieparzysty bajt INS): CLA INS P1 P2 || Lc' || DO „B3” 
|| DO „8E” || Le  
Przypadek 4 (parzysty bajt INS): CLA INS P1 P2 || Lc' || DO „81 ” || 
DO „97” || DO „8E” || Le  
Przypadek 4 (nieparzysty bajt INS): CLA INS P1 P2 || Lc' || DO „B3” 
|| DO „97” || DO „8E” || Le  
gdzie Le = „00” albo „00 00” w zależności od tego, czy stosuje się 
krótkie długości pól czy rozszerzone długości pól; zob. [ISO 78 16-4].  
Odpowiedź APDU z zastosowaniem bezpiecznej wymiany komunikatów 
będzie miała następującą strukturę w zależności od przypadku od powia­
dającej mu niezabezpieczonej odpowiedzi:  
Przypadek 1 lub 3: DO „99” || DO „8E” || 
SW1SW2  
Przypadek 2 lub 4 (parzysty bajt INS) 
bez szyfrowania 
: DO „81” || DO „99” || DO 
„8E” || SW1SW2  
Przypadek 2 lub 4 (parzysty bajt INS) 
z szyfrowaniem 
: DO „87” || DO „99” || DO 
„8E” || SW1SW2  
Przypadek 2 lub 4 (nieparzysty 
bajt INS) 
bez szyfrowania2: DO „B3” || DO „99” || DO 
„8E” || SW1SW  
Uwaga:  przypadków 2 lub 4 (nieparzysty bajt INS) z szyfrowaniem 
nigdy nie stosuje się w łączności między VU a kartą.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 485  
Poniżej przedstawiono trzy przykłady przekształceń APDU w odnie sieniu 
do poleceń z parzystym kodem INS. Rys. 8 przedstawia uwierzytel nione 
polecenie APDU określone w przypadku 4, rys. 9 przedstawia uwie rzy­
telnioną odpowiedź APDU określoną w przypadku 1 / przypadku 3, 
a rys. 10 przedstawia zaszyfrowaną i uwierzytelnioną odpowiedź 
APDU określoną w przypadku 2/4.  
Rysunek 8  
Przekszta łcenie uwierzytelnionego polecenia APDU okre ślonego w przypadku 4
  
Rysunek 9  
Przekszta łcenie uwierzytelnionej odpowiedzi APDU okre ślonej w przypadku 
1/ przypadku 3
  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 486  
Rysunek 10  
Przekszta łcenie zaszyfrowanej i uwierzytelnionej odpowiedzi APDU okre ślonej w przypadku 2/ przypadku 4
  
▼B 
10.5.3  Przerwanie sesji bezpiecznej wymiany komunikatów  
CSM_192 Przyrząd rejestrujący przerywa trwającą sesję bezpieczn ej 
wymiany komunikatów tylko i wyłącznie wówczas, gdy zaist­
nieje jeden z poniższych warunków:  
— przyrząd otrzyma odkrytą odpowiedź APDU;  
— przyrząd wykryje błąd bezpiecznej wymiany komuni­
katów w odpowiedzi APDU:  
— brak oczekiwanego obiektu danych bezpiecznej 
wymiany komunikatów, nieprawidłową kolejność 
obiektów danych lub uwzględnienie nieznanego 
obiektu danych,  
— nieprawidłowy obiekt danych bezpiecznej wymiany 
komunikatów, np. nieprawidłowa wartość MAC, 
nieprawidłową strukturę TLV lub wskaźnik wypeł­
nienia w znaczniku „87” nie jest równy „01”,  
— karta wyśle bajt stanu wskazujący na wykrycie błędu 
bezpiecznej wymiany komunikatów (zob. CSM_194);  
— osiągnięty zostanie limit dotyczący liczby poleceń i powią­
zanych odpowiedzi w ramach bieżącej sesji. Dla danego 
VU limit ten określa producent, uwzględniając wymogi 
bezpieczeństwa dotyczące używanego sprzętu, przy 
czym maksymalna liczba poleceń i powiązanych odpo­
wiedzi w ramach bezpiecznej wymiany komunikatów 
wynosi 240 w każdej sesji.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 487  
CSM_193 Karta do tachografu przerywa trwającą sesję bezpiecznej  
wymiany komunikatów tylko i wyłącznie wówczas, gdy zaist­
nieje jeden z poniższych warunków:  
— karta otrzyma odkryte polecenie APDU,  
— karta wykryje błąd bezpiecznej wymiany komunikatów 
w poleceniu APDU:  
— brak oczekiwanego obiektu danych bezpiecznej 
wymiany komunikatów, nieprawidłową kolejność 
obiektów danych lub uwzględnienie nieznanego 
obiektu danych,  
— nieprawidłowy obiekt danych bezpiecznej wymiany 
komunikatów, np. nieprawidłowa wartość MAC lub 
nieprawidłowa struktura TLV;  
— karta straci zasilanie lub zostanie zresetowana;  
— VU rozpocznie proces uwierzytelniania VU;  
— osiągnięty zostanie limit dotyczący liczby poleceń i powią­
zanych odpowiedzi w ramach bieżącej sesji. W odniesieniu 
do danej karty limit ten określa producent, uwzględniając 
wymogi bezpieczeństwa dotyczące używanego sprzętu, 
przy czym maksymalna liczba poleceń i powiązanych 
odpowiedzi w ramach bezpiecznej wymiany komunikatów 
wynosi 240 w każdej sesji.  
▼B 
CSM_194 W odniesieniu do obsługi błędów w ramach bezpiecznej 
wymiany komunikatów przez kartę do tachografu:  
— jeżeli w poleceniu APDU wystąpi brak niektórych ocze­
kiwanych obiektów danych bezpiecznej wymiany komu­
nikatów, kolejność obiektów danych jest nieprawidłowa 
lub zawarto nieznane obiekty danych, karta do tachografu 
wysyła odpowiedź zawierającą bajty stanu „69 87”;  
— jeżeli w poleceniu APDU obiekt danych bezpiecznej 
wymiany komunikatów jest nieprawidłowy, karta do 
tachografu wysyła odpowiedź zawierającą bajty stanu 
„69 88”.  
W takim przypadku bajty stanu są odsyłane bez zastosowania 
bezpiecznej wymiany komunikatów.  
CSM_195 Jeżeli sesja bezpiecznej wymiany komunikatów między VU 
a kartą do tachografu zostanie przerwana, VU i karta do 
tachografu:  
— w bezpieczny sposób niszczą przechowywane klucze 
sesji;  
— natychmiast ustanawiają nową sesję bezpiecznej wymiany 
komunikatów, jak opisano w sekcjach 10.2 – 10.5.  
CSM_196 Jeżeli z jakiejkolwiek przyczyny VU zdecyduje się ponow nie 
uruchomić proces wzajemnego uwierzytelniania w stosunku 
do włożonej karty, proces ten ponownie rozpoczyna się od 
weryfikacji łańcucha certyfikatów karty, jak opisano w sekcji 
10.2, i jest kontynuowany, jak opisano w sekcjach 10.2–10.5.  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 488  
11. POWIĄZANIE, WZAJEMNE UWIERZYTELNIANIE I BEZPIECZNA 
WYMIANA KOMUNIKATÓW MIĘDZY VU A URZĄDZENIEM 
ZEWNĘTRZNYM GNSS  
11.1.  Uwagi ogólne  
CSM_197 Urządzenie GNSS wykorzystywane przez VU do ustalania 
jego położenia może być wewnętrzne (tj. wbudowane 
w obudowę VU i nieodłączalne) bądź też może stanowić 
moduł zewnętrzny. W pierwszym przypadku standaryzacja 
łączności wewnętrznej między urządzeniem GNSS a VU nie 
jest potrzebna, a wymogi określone w tym rozdziale nie mają 
zastosowania. W drugim przypadku łączność między VU 
a urządzeniem zewnętrznym GNSS wymaga standaryzacji 
i ochrony, jak opisano w tym rozdziale.  
CSM_198 Bezpieczna łączność między przyrządem rejestrującym a u rzą­
dzeniem zewnętrznym GNSS odbywa się na takiej samej 
zasadzie jak bezpieczna łączność między przyrządem rejes­
trującym a kartą do tachografu, przy czym urządzenie 
zewnętrzne GNSS przyjmuje rolę karty. Urządzenie 
zewnętrzne GNSS musi spełniać wszystkie wymogi, o których 
mowa w rozdziale 10 w odniesieniu do kart do tachografu, 
z uwzględnieniem odstępstw, wyjaśnień i uzupełnień przed­
stawionych w tym rozdziale. W szczególności procesy 
wzajemnej weryfikacji łańcucha certyfikatów, uwierzytel­
niania VU i uwierzytelniania chipu przeprowadza się 
w sposób opisany w sekcjach 11.3 i 11.4.  
CSM_199 Łączność między przyrządem rejestrującym a EGF różni si ę 
od łączności między przyrządem rejestrującym a kartą pod 
takim względem, że przyrząd rejestrujący i EGF muszą zostać 
powiązane w warsztacie, zanim będą mogły dokonywać 
wymiany danych opartych na GNSS w trakcie normalnej 
pracy. Proces ustanawiania powiązania opisano w sekcji 11.2.  
CSM_200 W przypadku łączności między przyrządem rejestrującym 
a EGF stosuje się polecenia i odpowiedzi APDU na 
podstawie [ISO 7816-4] i [ISO 7816-8]. Dokładną składnię 
tych poleceń i odpowiedzi APDU określono w dodatku 2 do 
niniejszego załącznika.  
11.2.  Ustanowienie powi ązania mi ędzy VU a urz ądzeniem zewn ętrznym 
GNSS  
CSM_201 Powiązanie między przyrządem rejestrującym a EGF w poje ź­
dzie ustanawia warsztat. W trakcie normalnej pracy tylko 
powiązany przyrząd rejestrujący i EGF mogą nawiązywać 
łączność.  
CSM_202 Ustanowienie powiązania między przyrządem rejestrującym  
a EGF jest możliwe, wyłącznie gdy przyrząd rejestrujący 
znajduje się w trybie kalibracyjnym. Proces ustanawiania 
powiązania inicjuje przyrząd rejestrujący.  
CSM_203 Warsztat może w dowolnym momencie ponownie połączyć 
przyrząd rejestrujący z innym lub z tym samym EGF. 
W trakcie ustanawiania ponownego połączenia VU w sposób 
bezpieczny niszczy istniejący certyfikat EGF_MA w jego 
pamięci i przechowuje certyfikat EGF_MA EGF, z którym 
jest powiązany.  
CSM_204 Warsztat może w dowolnym momencie ponownie powiązać 
urządzenie zewnętrzne GNSS z innym lub tym samym VU. 
W trakcie ustanawiania ponownego powiązania EGF w sposób 
bezpieczny niszczy istniejący certyfikat VU_MA w jego 
pamięci i przechowuje certyfikat VU_MA VU, z którym 
jest wiązany.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 489  
11.3.  Wzajemna weryfikacja łańcucha certyfikatów  
11.3.1  Uwagi ogólne  
CSM_205 Wzajemna weryfikacja łańcucha certyfikatów między VU 
a EGF odbywa się wyłącznie w trakcie procesu ustanawiania 
przez warsztat powiązania między VU a EGF. W czasie 
normalnej pracy powiązanego VU i EGF nie przeprowadza 
się weryfikacji certyfikatów. Zamiast tego VU i EGF ufają 
certyfikatom, które zapisały podczas ustanawiania powią­
zania, po sprawdzeniu czasowej ważności tych certyfikatów. 
VU i EGF nie mogą ufać żadnym innym certyfikatom doty­
czącym ochrony łączności między VU a EGF w czasie 
normalnej pracy.  
11.3.2  Podczas ustanawiania powi ązania między VU a EGF  
CSM_206 Podczas ustanawiania powiązania z EGF przyrząd rejestru jący 
używa protokołu przedstawionego na rys. 4 (sekcja 10.2.1) 
w celu weryfikacji łańcucha certyfikatów urządzenia 
zewnętrznego GNSS.  
Uwagi do rys. 4 w tym kontek ście: 
— kontrola łączności nie jest objęta zakresem niniejszego 
dodatku. EGF nie jest jednak inteligentną kartą, a zatem 
VU prawdopodobnie nie wyśle komunikatu „Reset” 
w celu nawiązania łączności i nie otrzyma odpowiedzi 
na ponowne inicjowanie (ATR);  
— certyfikaty i klucze publiczne karty wskazane na rysunku 
interpretuje się jako certyfikaty i klucze publiczne EGF na 
potrzeby wzajemnego uwierzytelniania. W sekcji 9.1.6 
oznaczono je jako EGF_MA;  
— certyfikaty i klucze publiczne Card.CA wskazane na 
rysunku interpretuje się jako certyfikaty i klucze publiczne 
MSCA na potrzeby podpisywania certyfikatów EGF. 
W sekcji 9.1.3 oznaczono je jako MSCA_VU-EGF;  
— certyfikat Card.CA.EUR przedstawiony na rysunku inter­
pretuje się jako europejski certyfikat główny wskazany 
w CAR certyfikatu MSCA_VU-EGF;  
— certyfikat Card.Link wskazany na rysunku interpretuje się 
jako certyfikat łączący EGF, o ile istnieje. Jak określono 
w sekcji 9.1.2, jest to certyfikat łączący dla nowej pary 
europejskich kluczy głównych wygenerowanej przez 
ERCA i podpisanej za pomocą poprzedniego europej­
skiego klucza prywatnego;  
— certyfikat Card.Link.EUR jest europejskim certyfikatem 
głównym wskazanym w CAR certyfikatu Card.Link.  
— zamiast
  VU odczyta
  
z pliku elementarnego 
ICC;  
— zamiast AID tachografu VU wybiera AID EGF;  
— komunikat „Ignore Card” interpretuje się jako komunikat 
„Ignore EGF”.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 490  
CSM_207 Po zweryfikowaniu certyfikatu EGF_MA przyrząd rejestru­
jący zapisuje ten certyfikat do wykorzystania w czasie 
normalnej pracy; zob. sekcja 11.3.3.  
CSM_208  ►M1 Podczas ustanawiania powiązania z VU urządzenie 
zewnętrzne GNSS używa protokołu przedstawionego na rys. 
5 (sekcja 10.2.2) w celu weryfikacji łańcucha certyfikatów 
VU. ◄  
Uwagi do rys. 5 w tym kontek ście: 
— VU generuje nową parę kluczy efemerycznych przy 
użyciu parametrów domeny określonych w certyfikacie 
EGF;  
— certyfikaty i klucze publiczne VU wskazane na rysunku są 
certyfikatami i kluczami, których używa się do wzajem­
nego uwierzytelnienia. W sekcji 9.1.4 oznaczono je jako 
VU_MA;  
— certyfikaty i klucze publiczne VU.CA wskazane na 
rysunku są certyfikatami i kluczami używanymi do podpi­
sywania certyfikatów VU i urządzenia zewnętrznego 
GNSS. W sekcji 9.1.3 oznaczono je jako MSCA_VU- 
EGF;  
— certyfikat VU.CA.EUR przedstawiony na rysunku jest 
europejskim certyfikatem głównym wskazanym w CAR 
certyfikatu VU.CA;  
— certyfikat VU.Link wskazany na rysunku jest certyfikatem 
łączącym VU, o ile istnieje. Jak określono w sekcji 9.1.2, 
jest to certyfikat łączący dla nowej pary europejskich 
kluczy głównych wygenerowanej przez ERCA i podpi­
sanej za pomocą poprzedniego europejskiego klucza 
prywatnego;  
— certyfikat VU.Link.EUR jest europejskim certyfikatem 
głównym wskazanym w CAR certyfikatu VU.Link.  
CSM_209 W odróżnieniu od wymogu CSM_167 EGF wykorzystuje 
czas GNSS do celów weryfikacji czasowej ważności każdego 
przedstawionego certyfikatu.  
▼M1 
CSM_210 Po zweryfikowaniu certyfikatu VU_MA urządzenie 
zewnętrzne GNSS przechowuje ten certyfikat do wykorzys­
tania w czasie normalnej pracy; zob. sekcja 11.3.3.  
▼B 
11.3.3  W czasie normalnej pracy  
CSM_211  ►M1 W czasie normalnej pracy przyrząd rejestrujący i EGF 
używają protokołu wskazanego na rys. 11 w celu weryfikacji 
czasowej ważności przechowywanych certyfikatu EGF_MA 
oraz do celów ustalenia klucza publicznego VU_MA na 
potrzeby późniejszego uwierzytelnienia VU. W czasie 
normalnej pracy nie odbywa się dalsza wzajemna weryfikacja 
łańcuchów certyfikatów. ◄  
Należy zauważyć, że rys. 11 zasadniczo zawiera pierwsze 
kroki przedstawione na rys. 4 i rys. 5. Ponownie należy 
zauważyć, że ponieważ EGF nie jest inteligentną kartą, VU 
prawdopodobnie nie wyśle komunikatu „Reset” w celu 
nawiązania łączności i nie otrzyma ATR. W żadnym przy­
padku kwestia ta nie jest objęta zakresem niniejszego 
dodatku.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 491  
Rys. 11  
Wzajemna weryfikacja czasowej wa żności certyfikatu w czasie normalnej pracy VU–EGF
  
CSM_212 Jak przedstawiono na rys. 11, przyrząd rejestrujący rej estruje 
błąd, jeżeli certyfikat EGF_MA nie jest już aktualny. 
Wzajemne uwierzytelnienie, uzgodnienie klucza i późniejsza 
łączność za pośrednictwem bezpiecznej wymiany komuni­
katów odbywa się jednak normalnie.  
11.4.  Uwierzytelnienie VU, uwierzytelnienie chipu i uzgodnienie klucza 
sesji 
CSM_213 Uwierzytelnienie VU, uwierzytelnienie chipu i uzgodnien ie 
klucza sesji między VU a EGF odbywa się podczas ustana­
wiania powiązania oraz za każdym razem, gdy sesja 
bezpiecznej wymiany komunikatów jest ponownie ustana­
wiana w czasie normalnej pracy. VU i EGF przeprowadzają 
procesy opisane w sekcjach 10.3 i 10.4. Zastosowanie mają 
wszystkie wymogi określone w tych sekcjach.  
11.5.  Bezpieczna wymiana komunikatów  
CSM_214 Wszystkie polecenia i odpowiedzi wymieniane między przy ­
rządem rejestrującym a urządzeniem zewnętrznym GNSS po 
pomyślnym uwierzytelnieniu chipu i do zakończenia sesji są 
chronione za pomocą bezpiecznej wymiany komunikatów 
odbywającej się w trybie tylko uwierzytelniania. Zastoso­
wanie mają wszystkie wymogi określone w sekcji 10.5.  
CSM_215 W przypadku przerwania sesji bezpiecznej wymiany komuni ­
katów między VU a EGF przyrząd rejestrujący natychmiast 
ustanawia nową sesję bezpiecznej wymiany komunikatów, jak 
opisano w sekcjach 11.3.3 i 11.4.  
12. PAROWANIE VU Z CZUJNIKIEM RUCHU I ŁĄCZNOŚĆ MIĘDZY 
TYMI URZĄDZENIAMI  
12.1.  Uwagi ogólne  
CSM_216 Łączność pomiędzy przyrządem rejestrującym a czujnikiem  
ruchu odbywa się za pomocą protokołu interfejsu określonego 
w [ISO 16844-3] w czasie parowania i normalnej pracy, 
z uwzględnieniem zmian opisanych w tym rozdziale oraz 
w sekcji 9.2.1.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 492  
Uwaga:  zakłada się, że czytelnicy tego rozdziału są zaznajo­
mieni 
z treścią normy [ISO 16844-3].  
12.2.  Parowanie VU z czujnikiem ruchu przy u życiu różnych generacji 
kluczy  
Jak wyjaśniono w sekcji 9.2.1, klucz główny czujnika ruchu i ws zystkie 
powiązane klucze są regularnie zastępowane. Skutkuje to obecnoś cią do 
trzech kluczy AES K  M-WC  związanych z czujnikiem ruchu (kolejnych 
generacji kluczy) w kartach warsztatowych. Podobnie w czujnikac h 
ruchu może występować do trzech różnych rodzajów szyfrowania da nych 
opartych na AES (na podstawie kolejnych generacji klucza główne go 
czujnika ruchu K  M ). Przyrząd rejestrujący zawiera tylko jeden klucz 
K M-VU  związany z czujnikiem ruchu.  
CSM_217 Parowanie VU drugiej generacji i czujnika ruchu drugiej  
generacji odbywa się w sposób przedstawiony poniżej (por. 
tabela 6 w [ISO 16844-3]).  
1. Kartę warsztatową drugiej generacji wkłada się do VU, 
który jest połączony z czujnikiem ruchu.  
2. VU odczytuje wszystkie dostępne klucze K  M-WC  z karty 
warsztatowej, sprawdza ich numery wersji kluczy i wybiera 
klucz pasujący do numeru wersji klucza K  M-VU  VU. Jeżeli 
w karcie warsztatowej nie ma pasującego klucza K  M-WC  , 
VU przerywa proces parowania i wyświetla posiadaczowi 
karty warsztatowej odpowiedni komunikat o błędzie.  
3. VU oblicza klucz główny czujnika ruchu K  M na podstawie 
K M-VU  i K  M-WC  oraz klucz identyfikacyjny K  ID na 
podstawie K  M , jak określono w sekcji 9.2.1.  
4. VU wysyła instrukcję rozpoczęcia procesu pasowania 
w stosunku do czujnika ruchu, jak opisano w normie 
[ISO 16844-3], i szyfruje numer seryjny otrzymany od 
czujnika ruchu za pomocą klucza identyfikacyjnego K  ID . 
VU wysyła zaszyfrowany numer seryjny z powrotem do 
czujnika ruchu.  
5. Czujnik ruchu dopasowuje zaszyfrowany numer seryjny 
kolejno do każdego przechowywanego wewnętrznie 
zaszyfrowanego numeru seryjnego. Jeżeli znajdzie odpo­
wiedni numer, VU zostaje uwierzytelniony. Czujnik ruchu 
rejestruje generację klucza K  ID użytego przez VU i przeka­
zuje z powrotem pasującą zaszyfrowaną wersję klucza 
parowania; tj. zaszyfrowany numer stworzony przy zasto­
sowaniu klucza K  M tej samej generacji.  
6. VU odszyfrowuje klucz parowania za pomocą klucza K  M , 
generuje klucz sesji K  S, szyfruje go za pomocą klucza 
parowania i wysyła uzyskany rezultat do czujnika ruchu. 
Czujnik ruchu odszyfrowuje klucz K  S . 
7. VU gromadzi informacje o parowaniu, jak określono 
w [ISO 16844-3], szyfruje te informacje za pomocą klucza 
parowania i wysyła uzyskany rezultat do czujnika ruchu. 
Czujnik ruchu odszyfrowuje informacje o parowaniu.  
8. Czujnik ruchu szyfruje otrzymane informacje o parowaniu 
za pomocą otrzymanego klucza K  S i przesyła te informacje 
z powrotem do VU. VU sprawdza, czy informacje o paro­
waniu są tymi samymi informacjami, które VU wysłał do 
czujnika ruchu w poprzednim kroku. Jeżeli tak, oznacza 
to, że czujnik ruchu użył tego samego klucza K  S co VU  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 493  
i zgodnie z krokiem 5 wysłał swój klucz parowania 
zaszyfrowany za pomocą klucza K  M prawidłowej gene­
racji. Czujnik ruchu jest zatem uwierzytelniony.  
Należy zauważyć, że kroki 2 i 5 różnią się od standardowego 
procesu określonego w [ISO 16844-3]; pozostałe kroki są 
krokami standardowymi.  
Przykład: załóżmy, że proces parowania odbywa się w pierw­
szym roku ważności certyfikatu ERCA (3); zob. rys. 2 
w sekcji 9.2.1.2. Ponadto  
— załóżmy, że czujnik ruchu wydano w ostatnim roku 
ważności certyfikatu ERCA (1). Będzie zatem zawierał 
następujące klucze i dane:  
— N  s [1]: swój numer seryjny zaszyfrowany kluczem K  ID 
1. generacji;  
— N  s [2]: swój numer seryjny zaszyfrowany kluczem K  ID 
2. generacji;  
— N  s [3]: swój numer seryjny zaszyfrowany kluczem K  ID 
3. generacji;  
— K  P [1]: swój klucz parowania 1. generacji (  1 ), zaszyf­
rowany kluczem K  M 1. generacji;  
— K  P [2]: swój klucz parowania 2. generacji, zaszyfro­
wany kluczem K  M 2. generacji;  
— K  P [3]: swój klucz parowania 3. generacji, zaszyfro­
wany kluczem K  M 3. generacji;  
— załóżmy, że kartę warsztatową wydano w pierwszym roku 
ważności certyfikatu ERCA (3). Będzie zatem zawierała 
klucz K  M-WC  2. i 3. generacji;  
— załóżmy, że VU jest VU 2. generacji zawierającym klucz 
K M-VU  2. generacji.  
W takim przypadku w krokach 2–5 zajdą następujące 
procesy:  
— krok 2: VU odczytuje klucze K  M-WC  2. i 3. generacji 
z karty warsztatowej i sprawdza ich numery wersji;  
— krok 3: VU łączy klucz K  M-WC  2. generacji ze swoim 
kluczem K  M-VU  w celu obliczenia kluczy K  M i K  ID ; 
— krok 4: VU szyfruje numer seryjny otrzymany od czujnika 
ruchu za pomocą klucza K  ID ; 
— krok 5: czujnik ruchu porównuje otrzymane dane 
z numerem N  s [1] i nie znajduje odpowiedniego numeru. 
Następnie porównuje dane z numerem N  s [2] i znajduje 
odpowiedni numer. Ustala, że VU jest VU 2. generacji, 
w związku z czym odsyła klucz K  P [2]. ▼B 
( 1 ) Należy zauważyć, że klucze parowania 1., 2. i 3. generacji mo gą w rzeczywistości być 
tym samym kluczem lub mogą być trzema różnymi kluczami różnej d ługości, jak wyjaś­
niono w CSM_117.
 02016R0799 — PL — 21.08.2023 — 003.001 — 494  
12.3.  Parowanie VU z czujnikiem ruchu i łączność między tymi urz ądze­
niami z wykorzystaniem AES  
CSM_218 Zgodnie z tabelą 3 w sekcji 9.2.1 wszystkie klucze ucze stni­
czące w parowaniu przyrządu rejestrującego i czujnika ruchu 
(drugiej generacji) oraz w późniejszej łączności są kluczami 
AES, a nie kluczami TDES podwójnej długości, jak okre­ 
ślono w [ISO 16844-3]. Takie klucze AES mogą mieć 
długość 128, 192 lub 256 bitów. Ponieważ rozmiar bloku 
AES wynosi 16 bajtów, długość zaszyfrowanego komunikatu 
musi stanowić wielokrotność 16 bajtów, w porównaniu z 8 
bajtami w przypadku TDES. Ponadto niektóre takie komuni­
katy będą wykorzystywane do transportu kluczy AES, 
których długość może wynosić 128, 192 lub 256 bitów. 
W związku z tym liczbę bajtów danych zgodnie z instrukcją 
w tabeli 5 normy [ISO 16844-3] należy zmienić w sposób 
określony w tabeli 6:  
▼M1 
Tabela 6  
Liczba bajtów danych zwyk łego tekstu i danych zaszyfrowanych zgodnie z instrukcj ą określoną w [ISO 16844-3]  
Instrukcja  Żądanie / 
odpowiedź  Opis danych  Liczba bajtów 
danych zwykłego 
tekstu zgodnie z 
[ISO 16844-3]  Liczba bajtów 
danych zwykłego 
tekstu przy użyciu 
kluczy AES  Liczba bajtów zaszyfrowanych 
danych przy użyciu kluczy 
AES o długości w bitach  
128 192  256  
10 żądanie  Dane uwierzytel­
niania + numer pliku  8 8  1 6  1 6  1 6  
11 odpowiedź  Dane uwierzytel­
niania + zawartość 
pliku  16 lub 32 w zależ­
ności od pliku  16 lub 32 w zależ­
ności od pliku  32 / 48  32 / 48  32 / 48  
41 żądanie  Numer seryjny czuj­
nika ruchu  8 8  1 6  1 6  1 6  
41 odpowiedź  Klucz parowania  1 6  16 / 24 / 32  1 6  3 2  3 2  
42 żądanie  Klucz sesji  1 6  16 / 24 / 32  1 6  3 2  3 2  
43 żądanie  Informacje o paro­
waniu  24 2 4  3 2  3 2  3 2  
50 odpowiedź  Informacje o paro­
waniu  24 2 4  3 2  3 2  3 2  
70 żądanie  Dane uwierzytel­
niania  8 8  1 6  1 6  1 6  
80 odpowiedź  Wartość licznika 
czujnika ruchu + 
dane uwierzytelniania  8 8  1 6  1 6  1 6  
▼B 
CSM_219 Informacje o parowaniu wysyłane w instrukcjach 43 (żąda nie 
VU) i 50 (odpowiedź czujnika ruchu) są gromadzone zgodnie 
z wymogami określonymi w sekcji 7.6.10 normy [ISO 16844- 
3], z tym że zamiast algorytmu TDES należy stosować algo­
rytm AES w systemie szyfrowania danych dotyczących paro­
wania, co skutkuje uzyskaniem dwóch szyfrów AES i przyję­
ciem wypełnienia zgodnie z CSM_220 w celu dopasowania 
do rozmiaru bloku AES. Klucz K'  p , używany do takiego 
szyfrowania, generuje się w następujący sposób:  
— jeżeli długość klucza parowania K  P wynosi 16 bajtów: K'  p 
= K  P XOR (N  s ||N s ), ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 495  
— jeżeli długość klucza parowania K  P wynosi 24 bajty: K'  p 
= K  P XOR (N  s ||N s ||N s ), 
— jeżeli długość klucza parowania K  P wynosi 32 bajty: K'  p 
= K  P XOR (N  s ||N s ||N s ||N s ), 
gdzie N  s jest 8-bajtowym numerem seryjnym czujnika ruchu.  
CSM_220 Jeżeli długość danych zwykłego tekstu (przy użyciu kluc zy 
AES) nie jest wielokrotnością 16 bajtów, należy stosować 
metodę wypełniania 2 określoną w normie [ISO 9797-1].  
Uwaga:  w normie [ISO 16844-3] liczba bajtów danych 
zwykłego tekstu jest zawsze wielokrotnością 8, tak aby 
wypełnienie nie było konieczne przy użyciu TDES. Definicja 
danych i komunikatów w normie [ISO 16844-3] nie jest 
zmieniona w tej części niniejszego dodatku, co pociąga za 
sobą konieczność stosowania wypełnienia.  
CSM_221 W odniesieniu do instrukcji 11 i w przypadku koniecznoś ci 
zaszyfrowania więcej niż jednego bloku danych stosuje się 
tryb wiązania bloków zaszyfrowanych zgodnie z wymogami 
normy [ISO 10116], z naprzemiennym parametrem  m = 1. 
Wektorem inicjującym, jaki należy zastosować, jest:  
— w przypadku instrukcji 11: 8-bajtowy blok uwierzytel­
niania zdefiniowany w sekcji 7.6.3.3 normy [ISO 
16844-3], wypełniony za pomocą metody wypełniania 2 
określonej w normie [ISO 9797-1]; zob. również sekcja 
7.6.5 i 7.6.6 normy [ISO 16844-3];  
— w przypadku wszystkich pozostałych instrukcji, w których 
przekazuje się więcej niż 16 bajtów, zgodnie z tabelą 6: 
„00” {16}, tj. szesnaście bajtów o wartości binarnej 0.  
Uwaga:  jak przedstawiono w sekcjach 7.6.5 i 7.6.6 normy 
[ISO 16844-3], w momencie gdy czujnik ruchu szyfruje pliki 
danych do celów włączenia ich do instrukcji 11, blok uwie­
rzytelniania jest zarówno:  
— używany jako wektor inicjujący do celów szyfrowania 
plików danych w trybie CBC; jak i  
— szyfrowany i włączany jako pierwszy blok w danych, 
które są wysyłane do VU.  
12.4.  Parowanie VU z czujnikiem ruchu w przypadku ró żnych generacji 
urządzeń 
CSM_222 Jak wyjaśniono w sekcji 9.2.1, czujnik ruchu drugiej ge ne­
racji może zawierać zaszyfrowane w oparciu o TDES dane 
dotyczące parowania (zgodnie z częścią A niniejszego 
dodatku), co umożliwia parowanie tego czujnika ruchu 
z VU pierwszej generacji. W takim przypadku proces paro­
wania VU pierwszej generacji z czujnikiem ruchu drugiej 
generacji odbywa się zgodnie z opisem przedstawionym 
w części A niniejszego dodatku oraz w normie [ISO 16844- 
3]. Na potrzeby procesu parowania można użyć karty warsz­
tatowej pierwszej lub drugiej generacji.  
Uwagi  
— Nie jest możliwe sparowanie VU drugiej generacji z czuj­
nikiem ruchu pierwszej generacji.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 496  
— Nie jest możliwe użycie karty warsztatowej pierwszej 
generacji do celów powiązania VU drugiej generacji 
z czujnikiem ruchu.  
13. BEZPIECZEŃSTWO ŁĄCZNOŚCI NA ODLEGŁOŚĆ W RAMACH 
DSRC  
13.1.  Uwagi ogólne  
Jak określono w dodatku 14, VU regularnie generuje dane dotyczą ce 
zdalnego monitorowania tachografu (RTM) i wysyła te dane do 
(wewnętrznego lub zewnętrznego) urządzenia do łączności na 
odległość (RCF). Urządzenie do łączności na odległość odpowiada  za 
wysłanie tych danych za pośrednictwem interfejsu DSRC opisanego  
w dodatku 14 do zdalnego interrogatora. W dodatku 1 określono, że 
dane dotyczące zdalnego monitorowania tachografu stanowią połąc zenie:  
zaszyfrowanego ładunku tachografu  zaszyfrowanego zwykłego tekstu 
ładunku tachografu;  
danych zabezpieczaj ące DSRC  opisanych poniżej.  
Format danych ładunku tachografu zawierających zwykły tekst okr eślono 
w dodatku 1 i szczegółowo opisano w dodatku 14. W tej sekcji op isano 
strukturę danych zabezpieczających DSRC; formalne specyfikacje przed­
stawiono w dodatku 1.  
CSM_223 Dane zawierające zwykły tekst
  
przekazywane przez VU do urządzenia do łączności na odle­
głość (jeżeli RCF znajduje się na zewnątrz VU) lub przez 
przyrząd rejestrujący do zdalnego interrogatora za pośrednic­
twem interfejsu DSRC (jeżeli RCF znajduje się wewnątrz 
VU) są chronione w trybie uwierzytelnienia po wcześniej­
szym zaszyfrowaniu, co oznacza, że dane dotyczące ładunku 
tachografu są najpierw szyfrowane w celu zapewnienia pouf­
ności komunikatu, a następnie obliczany jest MAC w celu 
zapewnienia autentyczności i integralności.  
CSM_224 Dane zabezpieczające DSRC składają się z połączenia pon iż­
szych elementów danych w następującej kolejności; zob. 
również rys. 12:  
aktualnej daty i godziny  tj. aktualnej data i godziny VU (typ danych
  
) 
licznika  tj. 3-bajtowego licznika, zob. CSM_225  
▼M1 
numeru seryjnego VU  tj. numeru seryjnego VU lub identyfikatora 
wniosku o certyfikat (typ danych VuSerial­
Number lub CertificateRequestID) – zob. 
CSM_123  
▼B 
numeru wersji klucza g łównego DSRC  tj. 1-bajtowego numeru wersji klucza głów­
nego DSRC, z którego wyprowadzono klucze 
DSRC specyficzne dla VU; zob. sekcja 9.2.2.  
MAC  tj. MAC obliczanego na podstawie wszystkich 
wcześniejszych bajtów w danych dotyczących 
zdalnego monitorowania tachografu.  
CSM_225 3-bajtowy licznik w danych zabezpieczających DSRC ma 
format, w którym najbardziej znaczący bit znajduje się na 
początku. Za pierwszym razem, gdy VU oblicza zbiór danych 
dotyczących zdalnego monitorowania tachografu po rozpo­
częciu jego produkcji, ustawia wartość licznika na 0. VU 
zwiększa wartość licznika o 1 za każdym razem, zanim 
obliczy kolejny zbiór danych dotyczących zdalnego monito­
rowania tachografu.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 497  
13.2.  Szyfrowanie ładunku tachografu i generowanie MAC  
CSM_226 Po otrzymaniu elementu danych w formie zwykłego tekstu 
zawierającego typ danych
  , jak 
opisano w dodatku 14, VU szyfruje te dane zgodnie z rys. 
12: służącego do szyfrowania klucza DSRC przyrządu rejes­
trującego K_VU  DSRC  _ENC (zob. sekcja9.2.2) używa się wraz 
z AES w trybie wiązania bloków zaszyfrowanych (CBC), jak 
określono w [ISO 10116], z naprzemiennym parametrem  m = 
1. Wektor inicjujący ma wartość  IV = aktualna data i godzina  
|| „00 00 00 00 00 00 00 00 00”  | | licznik , przy czym 
wartości  aktualnej daty i godzina  oraz  licznika  określono 
w CSM_224. Dane, które mają zostać zaszyfrowane, 
wypełnia się za pomocą metody 2 określonej w [ISO 9797-1].  
CSM_227 VU oblicza MAC w danych zabezpieczających DSRC 
zgodnie z rys. 12: MAC oblicza się na podstawie wszystkich 
wcześniejszych bajtów zawartych w danych dotyczących 
zdalnego monitorowania tachografu, do wartości numeru 
wersji klucza głównego DSRC włącznie oraz z uwzględnie­
niem znaczników i długości obiektów danych. VU używa 
swojego klucza DSRC do zapewnienia autentyczności 
K_VU  DSRC  _MAC (zob. sekcja 9.2.2) z algorytmem AES 
w trybie CMAC, jak określono w [SP 800-38B]. Długość 
MAC jest powiązana z długością kluczy DSRC specyficznych 
dla VU, jak określono w CSM_50.  
Rys. 12  
Szyfrowanie ładunku tachografu i generowanie MAC
  
13.3.  Weryfikacja i odszyfrowywanie ładunku tachografu  
CSM_228 Gdy zdalny interrogator otrzymuje od VU dane dotyczące 
zdalnego monitorowania tachografu, wysyła wszystkie dane 
dotyczące zdalnego monitorowania tachografu do karty 
kontrolnej w polu danych polecenia PROCESS DSRC 
MESSAGE, jak opisano w dodatku 2. Następnie:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 498  
1. karta kontrolna sprawdza numer wersji klucza głównego 
DSRC w danych zabezpieczających DSRC. Jeżeli karta 
kontrolna nie rozpozna wskazanego klucza głównego 
DSRC, zwraca komunikat o błędzie określony w dodatku 
2 i przerywa proces;  
▼M1 
2. karta kontrolna stosuje wskazany klucz główny DSRC 
w połączeniu z numerem seryjnym VU lub identyfika­
torem wniosku o certyfikat zawartym w danych zabezpie­
czających DSRC w celu wyprowadzenia specyficznych dla 
VU kluczy DSRC K_VU  DSRC  _ENC i K_VU  DSRC  _MAC, 
jak określono w CSM_124;  
▼B 
3. karta kontrolna używa klucza K_VU  DSRC  _MAC do wery­
fikacji MAC zawartego w danych zabezpieczających 
DSRC, jak określono w CSM_227. Jeżeli MAC jest 
nieprawidłowy, karta kontrolna zwraca komunikat o błędzie 
określony w dodatku 2 i przerywa proces;  
4. karta kontrolna wykorzystuje klucz K_VU  DSRC  _ENC do 
celów odszyfrowania zaszyfrowanego ładunku tachografu, 
jak określono w CSM_226. Karta kontrolna usuwa wypeł­
nienie i odsyła odszyfrowane dane ładunku tachografu do 
zdalnego interrogatora.  
CSM_229 W celu zapobieżenia atakom przez powtórzenie zdalny int er­
rogator weryfikuje aktualność danych dotyczących zdalnego 
monitorowania tachografu poprzez sprawdzenie, czy  aktualna 
data i godzina  zawarta w danych zabezpieczających DSRC 
nie odbiega zbytnio od czasu bieżącego zdalnego 
interrogatora.  
Uwagi  
— W tym celu konieczne jest, aby zdalny interrogator 
posiadał dokładne i wiarygodne źródło czasu.  
— Ponieważ dodatek 14 zawiera wymóg, aby VU obliczał 
nowy zbiór danych dotyczących zdalnego monitorowania 
tachografu co 60 sekund, a zegar VU może odbiegać od 
czasu rzeczywistego o 1 minutę, dolna granica w odnie­
sieniu do aktualności danych dotyczących zdalnego moni­
torowania tachografu wynosi 2 minuty. Faktyczna aktual­
ność, jaka jest wymagana, zależy również od dokładności 
zegara zdalnego interrogatora.  
CSM_230 Gdy warsztat weryfikuje prawidłowość działania funkcji 
DSRC VU, wysyła wszystkie otrzymane od VU dane doty­
czące zdalnego monitorowania tachografu do karty warsz­
tatowej w polu danych polecenia PROCESS DSRC 
MESSAGE, jak opisano w dodatku 2. Karta warsztatowa 
przeprowadza wszystkie kontrole i działania określone 
w wymogu CSM_228.  
14. PODPISYWANIE POBIERANYCH DANYCH I SPRAWDZANIE 
PODPISÓW  
14.1.  Uwagi ogólne  
CSM_231 Inteligentne urządzenie dedykowane (IDE) przechowuje da ne 
otrzymane z VU lub karty podczas jednej sesji pobierania 
w jednym fizycznym pliku danych. Dane mogą być przecho­
wywane na zewnętrznym nośniku danych. Plik zawiera 
podpisy cyfrowe bloków danych zgodnie z opisem znajdu­
jącym się w dodatku 7. Plik ten zawiera również następujące 
certyfikaty (zob. sekcja 9.1):  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 499  
— w przypadku pobierania przez VU:  
— certyfikat VU_Sign;  
— certyfikat MSCA_VU-EGF zawierający klucz 
publiczny służący do weryfikacji certyfikatu 
VU_Sign;  
— w przypadku pobierania przez kartę:  
— certyfikat Card_Sign;  
— certyfikat MSCA_Card zawierający klucz publiczny 
służący do weryfikacji certyfikatu Card_Sign.  
CSM_232 IDE posiada również:  
— w przypadku gdy używa karty kontrolnej do weryfikacji 
podpisu, jak wskazano na rys. 13: certyfikat łączący 
najnowszy certyfikat EUR z certyfikatem EUR, którego 
okres ważności wygasa bezpośrednio przed okresem 
ważności tego najnowszego certyfikatu EUR, o ile 
istnieje;  
— w przypadku gdy samodzielnie weryfikuje podpis: 
wszystkie ważne europejskie certyfikaty główne.  
Uwaga:  metody stosowanej przez IDE do pobierania tych 
certyfikatów nie określono w niniejszym dodatku.  
14.2.  Generowanie podpisu  
CSM_233 Algorytmem podpisywania służącym do tworzenia podpisów 
cyfrowych w odniesieniu do pobieranych danych jest 
ECDSA, jak określono w [DSS], używający algorytmu skrótu 
powiązanego z wielkością klucza VU lub karty, jak określono 
w CSM_50. Format podpisu jest odkryty, jak określono 
w [TR-03111].  
14.3.  Weryfikacja podpisu  
CSM_234  ►M1 IDE może samodzielnie przeprowadzać weryfikację 
podpisu złożonego w odniesieniu do pobranych danych lub 
może do tego celu używać karty kontrolnej. W przypadku 
używania karty kontrolnej weryfikacja podpisów odbywa się 
zgodnie ze schematem przedstawionym na rysunku 13. 
W celu zweryfikowania czasowej ważności certyfikatu przed­
stawionego przez IDE karta kontrolna używa swojego 
wewnętrznego czasu bieżącego, jak określono w pozycji 
CSM_167. Karta kontrolna aktualizuje swój czas bieżący, 
jeżeli data wejścia w życie autentycznego certyfikatu będą­
cego „wiarygodnym źródłem czasu” jest późniejsza niż czas 
bieżący określony na karcie. Za wiarygodne źródło czasu 
karta uznaje wyłącznie następujące certyfikaty:  
— certyfikaty łączące ERCA drugiej generacji,  
— certyfikaty MSCA drugiej generacji,  
— certyfikaty VU_Sign lub Card_Sign drugiej generacji 
wydane przez to samo państwo, które wydało certyfikat 
własny karty kontrolnej.  
W przypadku gdy urządzenie samodzielnie przeprowadza 
weryfikację podpisy, IDE weryfikuje autentyczność i ważność 
wszystkich certyfikatów w łańcuchu certyfikatów w pliku 
danych oraz weryfikuje podpis złożony w stosunku do 
danych według schematu podpisu określonego w [DSS]. 
W obu przypadkach dla każdego certyfikatu odczytywanego 
z pliku danych konieczne jest sprawdzenie prawidłowości 
pola Upoważnienie Posiadacza Certyfikatu (CHA):  
— Pole CHA certyfikatu EQT wskazuje certyfikat VU lub 
karty (odpowiednio do przypadku) na potrzeby podpisu 
(zob. dodatek 1, typ danych EquipmentType).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 500  
— CHA certyfikatu EQT.CA musi wskazywać MSCA.  
— CHA certyfikatu EQT.Link musi wskazywać ERCA. ◄  
Uwagi do rys. 13:  
— urządzenie, które podpisuje dane przeznaczone do anali­
zowania, oznaczono EQT.  
— certyfikaty i klucze publiczne ETQ wskazane na rysunku 
są certyfikatami i kluczami używanymi do podpisywania, 
tj. VU_Sign lub Card_Sign;  
— certyfikaty EQT.CA i klucze publiczne wskazane na 
rysunku są certyfikatami i kluczami używanymi do podpi­
sywania w stosownych przypadkach certyfikatów VU lub 
kart; 
— certyfikat EQT.CA.EUR wskazany na rysunku jest euro­
pejskim certyfikatem głównym wskazanym w CAR certy­
fikatu EQT.CA;  
— certyfikat EQT.Link wskazany na rysunku jest certyfi­
katem łączącym EQT, o ile istnieje. Jak określono w sekcji 
9.1.2, jest to certyfikat łączący dla nowej pary europej­
skich kluczy głównych wygenerowanej przez ERCA 
i podpisanej za pomocą poprzedniego europejskiego 
klucza prywatnego;  
— certyfikat EQT.Link.EUR jest europejskim certyfikatem 
głównym wskazanym w CAR certyfikatu EQT.Link.  
CSM_235 Do celów obliczania skrótu M wysyłanego do karty kontro ­
lnej w poleceniu PSO:Hash IDE stosuje algorytm skrótu 
powiązany z wielkością klucza VU lub karty, z których 
dane są pobierane, jak określono w CSM_50.  
CSM_236 Do celów zweryfikowania podpisu EQT karta kontrolna 
wykonuje czynności według schematu podpisu określonego 
w [DSS].  
Uwaga:  w niniejszym dokumencie nie określono żadnego 
działania, jakie należy podjąć, jeżeli podpisu złożonego 
w odniesieniu do pobranego pliku danych nie można zwery­
fikować lub jeżeli weryfikacja się nie powiedzie.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 501  
Rysunek 13  
Protokół weryfikacji podpisu z łożonego w odniesieniu do pobranego pliku danych
  ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 502  
Dodatek 12  
OKREŚLANIE PO ŁOŻENIA Z WYKORZYSTANIEM GLOBALNEGO 
SYSTEMU NAWIGACJI SATELITARNEJ (GNSS)  
SPIS TREŚCI  
1. WPROWADZENIE  
1.1. Zakres stosowania  
▼M3 
1.1.1 Odniesienia  
▼B 
1.2. Akronimy i skróty  
▼M3 
2. PODSTAWOWA CHARAKTERYSTYKA ODBIORNIKA GNSS  
3. KOMUNIKATY PODAWANE PRZEZ ODBIORNIK GNSS  
▼B 
4. PRZYRZĄD REJESTRUJĄCY Z URZĄDZENIEM ZEWNĘTRZNYM 
GNSS  
4.1. Konfiguracja  
4.1.1 Główne elementy składowe i interfejsy  
4.1.2 Stan urządzenia zewnętrznego GNSS na koniec procesu produ kcji 
4.2. Łączność między urządzeniem zewnętrznym GNSS a przyrządem rejes­ 
trującym  
4.2.1 Protokół łączności  
4.2.2 Bezpieczne przesyłanie danych GNSS  
4.2.3 Struktura polecenia Read Record  
▼M3 
4.2.4 Struktura polecenia WriteRecord  
4.2.5. Inne polecenia  
▼B 
4.3. Powiązanie, wzajemne uwierzytelnienie i uzgodnienie klucza  sesji 
między urządzeniem zewnętrznym GNSS a przyrządem rejestrującym  
4.4. Obsługa błędów  
4.4.1 Błąd komunikacji z urządzeniem zewnętrznym GNSS  
4.4.2 Naruszenie integralności fizycznej urządzenia zewnętrzneg o GNSS  
4.4.3 Brak informacji o położeniu z odbiornika GNSS  
4.4.4 Wygaśnięcie certyfikatu urządzenia zewnętrznego GNSS  
5. PRZYRZĄD REJESTRUJĄCY BEZ URZĄDZENIA ZEWNĘTRZ­ 
NEGO GNSS  
5.1. Konfiguracja  
▼M3 
5.2. Transfer informacji z odbiornika GNSS do VU  
__________  
5.3. Transfer informacji z VU do odbiornika GNSS  
5.4. Obsługa błędów  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 503  
5.4.1. Brak informacji o pozycji z odbiornika GNSS  
6. PRZETWARZANIE I REJESTRACJA DANYCH O POZYCJI PRZEZ 
VU 
7. KONFLIKT CZASOWY GNSS  
8. KONFLIKT RUCHU POJAZDU  
1. WPROWADZENIE  
Niniejszy dodatek zawiera wymogi techniczne dotyczące odbiornik a 
GNSS oraz danych GNSS wykorzystywanych przez przyrząd rejestru­
jący, z uwzględnieniem protokołów, które należy wdrożyć w celu zapew­
nienia bezpiecznego i prawidłowego przesyłania danych z informa cjami 
o pozycji.  
1.1. Zakres  
GNS_1 Przyrząd rejestrujący musi gromadzić dane dotyczące lokal izacji 
z co najmniej jednej sieci satelitarnej GNSS.  
Przyrząd rejestrujący może posiadać urządzenie zewnętrzne 
GNSS lub nie, jak przedstawiono na rys. 1:  
1.1.1  Odniesienia  
W tej części dodatku używa się następujących odniesień:  
NMEA NMEA (National Marine Electronics Association) [Narodowe 
Stowarzyszenie Elektroniki Morskiej] 0183 Interface Standard 
[standard dla interfejsów], V4.11  
▼B 
Rys. 1  
Różne konfiguracje odbiornika GNSS.
  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 504  
1.2. Akronimy i skróty  
W niniejszym dodatku używa się następujących skrótów:  
DOP Rozmycie dokładności  
EGF Plik elementarny urządzenia GNSS  
GNSS Globalny system nawigacji satelitarnej  
EGNOS Europejski system wspomagania satelitarnego  
GSA Rozmycie dokładności GPS i aktywne satelity  
HDOP Poziome rozmycie dokładności  
ICD Dokument kontroli interfejsu  
NMEA National Marine Electronics Association  
▼M3 
OSNMA Galileo Open Service Navigation Message Authentication 
[uwierzytelnianie komunikatów nawigacyjnych usługi 
otwartej Galileo]  
▼B 
PDOP Trójwymiarowe rozmycie dokładności  
RMC Zalecane minimalne dane GNSS  
▼M3 
RTC Real Time Clock [zegar czasu rzeczywistego]  
▼B 
SIS Sygnał w przestrzeni  
VDOP Pionowe rozmycie dokładności  
VU Przyrząd rejestrujący  
▼M3 
2. PODSTAWOWA CHARAKTERYSTYKA ODBIORNIKA GNSS  
▼B 
Niezależnie od konfiguracji tachografu inteligentnego z urządze niem 
zewnętrznym GNSS lub bez niego, dostarczanie dokładnych i wiary god­
nych informacji o położeniu jest niezbędne do zapewnienia skute cznego 
funkcjonowania tachografów inteligentnych. W związku z tym nale ży 
wprowadzić wymóg zapewnienia kompatybilności tego systemu z usł u­
gami świadczonymi przez programy Galileo i European Geostationa ry 
Navigation Overlay Service (EGNOS), które zostały określone w r ozpo­
rządzeniu Parlamentu Europejskiego i Rady (UE) nr 1285/2013 (  1 ). 
System ustanowiony w ramach programu Galileo jest niezależnym ś wia­
towym systemem nawigacji satelitarnej, zaś system ustanowiony 
w ramach programu EGNOS jest regionalnym systemem nawigacji sat e­
litarnej poprawiającym jakość sygnału globalnego systemu 
pozycjonowania.  
GNS_2 Producenci zapewniają, aby odbiorniki GNSS instalowane 
w tachografach inteligentnych były kompatybilne z usługami 
w zakresie lokalizacji zapewnianymi przez systemy Galileo 
i EGNOS. Ponadto producenci mogą również wybrać kompa­
tybilność z innymi systemami nawigacji satelitarnej.  ▼B 
( 1 ) Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 1285/2 013 z dnia 11 grudnia 
2013 r. w sprawie realizacji i eksploatacji europejskich system ów nawigacji satelitarnej 
oraz uchylające rozporządzenie Rady (WE) nr 876/2002 i rozporzą dzenie Parlamentu 
Europejskiego i Rady (WE) nr 683/2008 (Dz.U. L 347 z 20.12.2013 , s. 1).
 02016R0799 — PL — 21.08.2023 — 003.001 — 505  
GNS_3 Odbiornik GNSS musi być w stanie obsługiwać uwierzytel­
nianie komunikatów nawigacyjnych w ramach usługi otwartej 
Galileo (OSNMA).  
GNS_3a Odbiornik GNSS przeprowadza szereg kontroli spójności 
w celu sprawdzenia, czy pomiary obliczane przez odbiornik 
GNSS na podstawie danych OSNMA doprowadziły do uzys­
kania prawidłowych informacji na temat pozycji, prędkości 
i danych pojazdu, a zatem nie były przedmiotem żadnego 
ataku zewnętrznego, który wywarłby nie na wpływ, takiego 
jak meaconing. Przedmiotowe kontrole spójności obejmują na 
przykład:  
— wykrywanie nietypowych emisji mocy za pomocą połączo­
nego monitorowania automatycznej kontroli wzmocnienia 
(AGC) i stosunku gęstości nośnej do szumu (C/N0),  
— spójności pomiaru pseudozakresów oraz spójności pomiaru 
Dopplera w czasie, w tym wykrywanie nagłych skoków 
pomiarowych,  
— techniki niezależnego monitorowania spójności odbiornika 
(RAIM), w tym wykrywanie niespójnych pomiarów z szaco­
waną pozycją,  
— kontrole pozycji i prędkości, w tym nietypowych wskazań 
pozycji i prędkości, nagłych skoków i zachowań niezgod­
nych z dynamiką pojazdu,  
— spójność czasu i częstotliwości, w tym skoki zegarowe 
i dryfty, które nie są spójne z charakterystyką zegara 
odbiornika.  
GNS_3b Komisja Europejska opracowuje i zatwierdza następujące 
dokumenty:  
— dokument kontroli interfejsu sygnału w przestrzeni (SIS 
ICD), określający szczegółowo informacje OSNMA prze­
kazywane w ramach sygnału Galileo;  
— wytyczne dla odbiorników w zakresie OSNMA, określające 
wymogi i procesy dotyczące odbiorników, niezbędne do 
zagwarantowania bezpiecznego wdrożenia OSNMA, 
a także zalecenia dotyczące poprawy działania OSNMA.  
Odbiorniki GNSS instalowane w tachografach, zarówno 
wewnętrzne, jak i zewnętrzne, muszą być skonstruowane 
zgodnie z dokumentem SIS ICD i wytycznymi dla odbior­
ników w zakresie OSNMA.  
GNS_3c Odbiornik GNSS dostarcza komunikaty o pozycji, zwane 
w niniejszym załączniku i dodatkach do niego komunikatami 
o uwierzytelnionej pozycji, opracowane z wykorzystaniem 
wyłącznie satelitów przekazujących komunikaty nawigacyjne, 
których autentyczność została z powodzeniem zweryfikowana.  
GNS_3d Odbiornik GNSS dostarcza również komunikaty o standardow ej 
pozycji opracowane z wykorzystaniem widocznych satelitów, 
niezależnie od tego, czy są one uwierzytelnione, czy nie.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 506  
GNS_3e Odbiornik GNSS wykorzystuje zegar czasu rzeczywistego 
(RTC) VU jako odniesienie dla synchronizacji czasu na 
potrzeby OSNMA.  
GNS_3f Czas RTC VU jest przekazywany przez VU do odbiornika 
GNSS.  
GNS_3g VU przekazuje do odbiornika GNSS maksymalny dryft czasu okre­ 
ślony w wymogu 41 w załączniku IC, wraz z czasem RTC VU.  
3. KOMUNIKATY PODAWANE PRZEZ ODBIORNIK GNSS  
W niniejszej sekcji opisano komunikaty wykorzystywane w funkcjo no­
waniu tachografu inteligentnego do przekazywania komunikatów o stan­
dardowej i uwierzytelnionej pozycji. Sekcja ta ma zastosowanie w odnie­
sieniu do konfiguracji tachografu inteligentnego z urządzeniem 
zewnętrznym GNSS lub bez niego.  
GNS_4 Dane o standardowej pozycji opierają się na zalecanych mi ni­
malnych danych GNSS (RMC) w komunikacie NMEA, który 
zawiera informacje o pozycji (długość i szerokość geogra­
ficzną), czas w formacie UTC (hhmmss.ss), prędkość nad 
dnem wyrażoną w węzłach oraz dodatkowe wartości.  
Format komunikatu RMC jest następujący (według standardu 
NMEA V4.11):  
Rysunek 2  
Struktura komunikatu RMC
  
$–RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x .x,xxxx,x.x,a,a,a* hh 
1) Czas (UTC)  
2) Status, A= prawidłowe położenie, V= ostrzeżenie  
3) Szerokość geograficzna  
4) N lub S  
5) Długość geograficzna  
6) E lub W  
7) Prędkość nad dnem w węzłach  
8) Tor prawidłowy, stopnie prawidłowe  
9) Data, ddmmrr  
10) Deklinacja magnetyczna w stopniach  
11) E lub W  
12) Wskaźnik trybu FAA  
13) Status nawigacji  
14) Suma kontrolna  
Status nawigacji ma charakter opcjonalny i może być 
nieobecny w komunikacie RMC.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 507  
Parametr „Status” informuje o tym, czy sygnał GNSS jest 
dostępny. Dopóki wartość statusu nie zostanie ustawiona na 
„A”, otrzymywanych danych (np. dotyczących czasu lub 
długości/szerokości geograficznej) nie można wykorzystywać 
do rejestrowania pozycji pojazdu w VU.  
Dokładność położenia opiera się na formacie komunikatu 
RMC opisanym powyżej. Pierwszą część pól 3 i 5 wykorzys­
tuje się do określenia stopni. Pozostałe określają minuty 
kątowe z dokładnością do trzech miejsc po przecinku. 
Zatem dokładność wynosi 1/1 000 minuty kątowej 
lub 1/60 000 stopnia (ponieważ jedna minuta to 1/60 stopnia).  
GNS_4a Dane o uwierzytelnionej pozycji opierają się na komunika cie 
podobnym do NMEA, z uwierzytelnionymi minimalnymi 
danymi (AMC), który zawiera informacje o pozycji (długość 
i szerokość geograficzną), czas w formacie UTC (hhmmss.ss), 
prędkość nad dnem wyrażoną w węzłach oraz dodatkowe 
wartości.  
Format komunikatu AMC jest następujący (według standardu 
NMEA V4.11, z wyjątkiem wartości nr 2):  
Rysunek 3  
Struktura komunikatu AMC
  
$–AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*h h 
1) Czas (UTC)  
2) Status, A=uwierzytelniona pozycja (ustalona przy użyciu co n ajmniej 4 
satelitów przekazujących komunikaty nawigacyjne, których autent yczność 
została z powodzeniem zweryfikowana), J= jamming  [celowe zakłócanie] 
lub O=inny atak na GNSS w razie braku nieprawidłowego uwierzyte lnienia 
komunikatów nawigacyjnych (poprzez wdrożone kontrole spójności zgodnie 
z GNS_3a), F= nieudane uwierzytelnienie komunikatów nawigacyjny ch 
(wykryte w wyniku weryfikacji OSNMA określonych w dokumentach, 
o których mowa w GNS_3b), V=puste (uwierzytelniona pozycja nie jest 
dostępna z innego powodu)  
3) Szerokość geograficzna  
4) N lub S  
5) Długość geograficzna  
6) E lub W  
7) Prędkość nad dnem w węzłach  
8) Tor prawidłowy, stopnie prawidłowe  
9) Data, ddmmrr  
10) Deklinacja magnetyczna w stopniach  
11) E lub W  
12) Wskaźnik trybu FAA  
13) Status nawigacji  
14) Suma kontrolna  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 508  
Status nawigacji ma charakter opcjonalny i może być 
nieobecny w komunikacie AMC.  
Status wskazuje, czy uwierzytelniona pozycja GNSS dostępna 
jest dostępna, czy wykryto atak na sygnały GNSS, czy uwie­
rzytelnienie komunikatów nawigacyjnych nie powiodło się, 
lub czy pozycja GNSS jest pusta. Dopóki wartość statusu 
nie zostanie ustawiona na „A”, otrzymywanych danych (np. 
dotyczących czasu lub długości/szerokości geograficznej) nie 
uznaje się za ważne i nie można ich wykorzystywać do reje­
strowania pozycji pojazdu w VU. Jeżeli wartość statusu jest 
ustawiona na „J” (jamming), „O” (inny atak na GNSS) lub 
„F” (nieupoważnione uwierzytelnienie komunikatów nawiga­
cyjnych), w VU rejestruje się zdarzenie anomalii GNSS, jak 
określono w załączniku IC i dodatku 1 (EventFaultCode).  
GNS_5 Przyrząd rejestrujący przechowuje w bazie danych VU infor ­
macje o położeniu dotyczące szerokości i długości geogra­
ficznej z dokładnością 1/10 minuty kątowej lub 1/600 stopnia, 
jak określono w dodatku 1 w odniesieniu do współrzędnych 
geograficznych GeoCoordinates.  
VU może wykorzystać polecenie GSA (dotyczące rozmycia 
dokładności GPS i satelitów czynnych), zgodnie ze stan­
dardem NMEA V4.11, w celu ustalenia i zarejestrowania 
dostępności sygnału i dokładności standardowych pozycji. 
W szczególności HDOP stosuje się w celu wskazania 
poziomu dokładności zarejestrowanych danych dotyczących 
lokalizacji (zob. pkt 4.2.2). VU będzie przechowywał wartość 
poziomego rozmycia dokładności (HDOP) obliczaną jako 
minimum wartości HDOP zgromadzonych w dostępnych 
systemach GNSS.  
Identyfikator GNSS wskazuje odpowiedni identyfikator 
NMEA dla każdej konstelacji GNSS i systemu wspomagają­
cego opartego na wyposażeniu satelitarnym SBAS.  
Rysunek 4  
Struktura komunikatu GSA (standardowe pozycje)
  
$–GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h  
1) Tryb wyboru  
2) Tryb  
3) ID pierwszego satelity użytego do ustalenia pozycji  
4) ID drugiego satelity użytego do ustalenia pozycji  
… 
14) ID dwunastego satelity użytego do ustalenia pozycji  
15) PDOP  
16) HDOP  
17) VDOP  
18) ID systemu  
19) Suma kontrolna  
ID systemu ma charakter opcjonalny i może być nieobecny 
w komunikacie GSA.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 509  
Podobnie VU może wykorzystywać polecenie ASA (doty­
czące uwierzytelnionych satelitów czynnych) z komunikatem 
podobnym do NMEA w celu ustalenia i zarejestrowania goto­
wości sygnału i dokładności uwierzytelnionych pozycji. 
Wartości 1–18 są zdefiniowane w standardzie NMEA V4.11.  
Rysunek 5  
Struktura komunikatu ASA (uwierzytelnione pozycje)
  
$–ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h  
1) Tryb wyboru  
2) Tryb  
3) ID pierwszego satelity użytego do ustalenia pozycji  
4) ID drugiego satelity użytego do ustalenia pozycji  
… 
14) ID dwunastego satelity użytego do ustalenia pozycji  
15) PDOP  
16) HDOP  
17) VDOP  
18) ID systemu  
19) Suma kontrolna  
ID systemu ma charakter opcjonalny i może być nieobecny 
w komunikacie ASA.  
GNS_6 W przypadku korzystania z urządzenia zewnętrznego GNSS 
komunikat  GSA  przechowuje się w bezpiecznym 
nadajniku-odbiorniku GNSS z numerem rekordu „02” do 
„06”, a komunikat ASA przechowuje się z numerem rekordu 
„12” do „16”.  
GNS_7 Maksymalny rozmiar komunikatów (np. RMC, AMC, GSA, 
ASA lub innych), jaki można zastosować w celu ustalenia 
rozmiaru polecenia odczytu rekordu, wynosi 85 bajtów (zob. 
tabela 1).  
▼B 
4. PRZYRZĄD REJESTRUJĄCY Z URZĄDZENIEM 
ZEWNĘTRZNYM GNSS  
4.1. Konfiguracja  
4.1.1  Główne elementy sk ładowe i interfejsy  
W tej konfiguracji odbiornik GNSS stanowi część urządzenia 
zewnętrznego GNSS.  
GNS_8 Urządzenie zewnętrzne GNSS musi być obsługiwane przez 
specjalny interfejs pojazdu.  
▼M3 
GNS_9 Urządzenie zewnętrzne GNSS składa się z następujących 
elementów składowych (zob. rys. 6):  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 510  
a) komercyjnego odbiornika GNSS zapewniającego dane 
o pozycji za pośrednictwem interfejsu danych GNSS. 
Przykładowo interfejs danych GNSS może być w stan­
dardzie NMEA V4.11, gdzie odbiornik GNSS pełni 
funkcję nadajnika i przesyła komunikaty NMEA do 
bezpiecznego nadajnika-odbiornika GNSS z częstotliwo­ 
ścią 1 Hz dla zdefiniowanego wcześniej zbioru komuni­
katów NMEA i podobnych do NMEA, który musi 
zawierać co najmniej komunikaty RMC, AMC, GSA 
i ASAA. Wdrożenie interfejsu danych GNSS zależy 
od uznania producentów urządzeń zewnętrznych GNSS.  
▼B 
b) zespołu nadajnika-odbiornika (bezpiecznego nadajnika- 
odbiornika GNSS) zdolnego do zapewnienia zgodności 
z wymogami normy ISO/IEC 7816-4:2013 (zob. 
pkt 4.2.1) w celu łączenia się z przyrządem rejestru­
jącym i obsługi interfejsu danych GNSS odbiornika 
GNSS. Zespół ten jest wyposażony w pamięć do prze­
chowywania danych identyfikacyjnych z odbiornika 
GNSS i urządzenia zewnętrznego GNSS;  
▼M3 
c) systemu obudowy z funkcją wykrywania manipulo­
wania, obejmującego zarówno odbiornik GNSS, jak 
i bezpieczny nadajnik-odbiornik GNSS. Funkcja wykry­
wania manipulowania umożliwia wdrażanie środków 
bezpieczeństwa zgodnie z wymogami określonymi 
w profilu zabezpieczenia tachografu inteligentnego.  
▼B 
d) anteny GNSS zainstalowanej na pojeździe i połączonej 
z odbiornikiem GNSS poprzez system obudowy.  
GNS_10 Urządzenie zewnętrzne GNSS posiada co najmniej następu­
jące interfejsy zewnętrzne:  
a) interfejs anteny GNSS zainstalowanej na pojeździe cięża­
rowym w przypadku korzystania z anteny zewnętrznej;  
b) interfejs przyrządu rejestrującego.  
GNS_11 W VU bezpieczny nadajnik-odbiornik VU znajduje się na 
drugim końcu bezpiecznej łączności z bezpiecznym 
nadajnikiem-odbiornikiem GNSS i musi zapewniać zgod­
ność z wymogami normy ISO/IEC 7816-4:2013 w zakresie 
łączności z urządzeniem zewnętrznym GNSS.  
GNS_12 W zakresie warstwy fizycznej łączności z urządzeniem 
zewnętrznym GNSS przyrząd rejestrujący musi zapewniać 
zgodność z wymogami normy ISO/IEC 7816-12:2005 lub 
innej normy zgodnej z normą ISO/IEC 7816-4:2013 (zob. 
pkt 4.2.1).  
4.1.2  Stan urz ądzenia zewn ętrznego GNSS na koniec procesu produkcji  
GNS_13 Urządzenie zewnętrzne GNSS przechowuje następujące 
wartości w pamięci trwałej bezpiecznego nadajnika-odbiornika 
GNSS w momencie opuszczenia zakładu produkcyjnego:  
— parę kluczy EGF_MA i powiązany certyfikat;  
— certyfikat MSCA_VU-EGF zawierający klucz publiczny 
MSCA_VU-EGF.PK służący do weryfikacji certyfikatu 
EGF_MA;  
— certyfikat EUR zawierający klucz publiczny EUR.PK 
służący do weryfikacji certyfikatu MSCA_VU-EGF;  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 511  
— certyfikat EUR, którego okres ważności wygasa bezpo­ 
średnio przed okres ważności certyfikatu EUR służą­
cego do celów weryfikacji certyfikatu MSCA_VU- 
EGF, o ile istnieje;  
— certyfikat łączący wspomniane dwa certyfikaty EUR, 
o ile istnieje;  
— rozszerzony numer seryjny urządzenia zewnętrznego 
GNSS;  
— identyfikator systemu operacyjnego urządzenia GNSS;  
— numer homologacji typu urządzenia zewnętrznego 
GNSS;  
— identyfikator elementu zabezpieczenia modułu 
zewnętrznego GNSS.  
4.2. Łączność między urządzeniem zewn ętrznym GNSS a przyrz ądem 
rejestrującym 
4.2.1  Protokó ł łączności 
▼M3 
GNS_14 Protokół łączności między urządzeniem zewnętrznym 
GNSS a przyrządem rejestrującym obsługuje następujące 
funkcje:  
1. gromadzenie i rozpowszechnianie danych GNSS (np. 
pozycja, czas, prędkość);  
2. gromadzenie danych dotyczących konfiguracji urzą­
dzenia zewnętrznego GNSS;  
3. protokół zarządzania na potrzeby obsługi powiązania, 
wzajemnego uwierzytelnienia i uzgadniania klucza sesji 
między urządzeniem zewnętrznym GNSS a VU;  
4. przekazywanie do urządzenia zewnętrznego GNSS czasu 
RTC VU oraz maksymalnej różnicy między czasem 
prawdziwym a czasem RTC VU.  
▼B 
GNS_15 Protokół łączności bazuje na wymogach normy ISO/IEC 
7816-4:2013, przy czym bezpieczny nadajnik-odbiornik 
VU odgrywa rolę nadrzędną, a bezpieczny 
nadajnik-odbiornik GNSS – rolę podrzędną. Fizyczne połą­
czenie między urządzeniem zewnętrznym GNSS a przy­
rządem rejestrującym bazuje na normie ISO/IEC 7816- 
12:2005 lub innej normie zgodnej z normą ISO/IEC 
7816-4:2013.  
▼M1 
GNS_16 W protokole łączności nie są obsługiwane pola o rozsze­
rzonej długości.  
▼B 
GNS_17 Protokół łączności bazujący na wymogach normy ISO 7816 
(zarówno *-4:2013, jak i *-12:2005) między urządzeniem 
zewnętrznym GNSS a VU ustawia się na wartość T=1.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 512  
GNS_18 Jeżeli chodzi o funkcje: 1) gromadzenia i rozpowszechnia nia 
danych GNSS; 2) gromadzenia danych dotyczących konfi­
guracji urządzenia zewnętrznego GNSS; oraz 3) protokołu 
zarządzania, bezpieczny nadajnik-odbiornik GNSS symu­
luje inteligentną kartę za pomocą architektury systemu 
plików składającej się z pliku głównego (MF), pliku dedy­
kowanego (DF) z identyfikatorem aplikacji określonym 
w dodatku 1 rozdział 6.2 („FF 44 54 45 47 4D”) i z trzema 
plikami elementarnymi (EF) zawierającymi certyfikaty oraz 
jednego pojedynczego pliku elementarnego (EF.EGF) 
z identyfikatorem pliku równym „2F2F”, jak opisano 
w tabeli 1.  
▼M3 
GNS_18a W odniesieniu do funkcji 4 (przekazywanie do urządzenia  
zewnętrznego GNSS czasu RTC VU oraz maksymalnej 
różnicy między czasem prawdziwym a czasem RTC VU) 
bezpieczny nadajnik-odbiornik GNSS wykorzystuje EF (EF 
VU) w tym samym DF z identyfikatorem pliku równym 
„2F30”, jak opisano w tabeli 1.  
▼B 
GNS_19 Bezpieczny nadajnik-odbiornik GNSS przechowuje dane 
z odbiornika GNSS i konfigurację w pliku elementarnym 
EF.EGF. Jest to liniowy plik rekordu o zmiennej długości 
z identyfikatorem równym „2F2F” w formacie 
heksadecymalnym.  
▼M3 
GNS_19a Bezpieczny nadajnik-odbiornik GNSS przechowuje dane 
z VU w EF VU. Jest to liniowy plik rekordu o stałej 
długości z identyfikatorem równym „2F30” w formacie 
heksadecymalnym.  
GNS_20 Bezpieczny nadajnik-odbiornik GNSS używa pamięci do 
przechowywania danych i jest w stanie przeprowadzić 
tyle cykli odczytu/zapisu, ile jest potrzebnych w okresie 
eksploatacji wynoszącym co najmniej 15 lat. Poza tym 
aspektem o konstrukcji wewnętrznej i wdrażaniu bezpiecz­
nego nadajnika-odbiornika GNSS decydują producenci.  
▼M1 
Mapowanie numerów rekordów i danych przedstawiono 
w tabeli 1. Należy zauważyć, że istnieje pięć komunikatów 
GSA dotyczących konstelacji GNSS i systemu wspomaga­
jącego opartego na wyposażeniu satelitarnym SBAS.  
▼B 
GNS_21 Strukturę plików przedstawiono w tabeli 1. Aby uzyskać 
informacje na temat warunków dostępu (ALW, NEV, 
SM-MAC), zob. dodatek 2 rozdział 3.5.  
▼M3 
Tabela 1  
Struktura plików  
Warunki dostępu  
File ID pliku  Odczyt  Aktualizacja  Zaszyfrowany  
MF 3F00  
EF.ICC  0002  ALW  NEV 
(ze strony VU)  Nie ▼M1
 02016R0799 — PL — 21.08.2023 — 003.001 — 513  
Warunki dostępu  
File ID pliku  Odczyt  Aktualizacja  Zaszyfrowany  
DF GNSS Facility  0501  ALW  NEV  Nie  
EF EGF_MACertificate  C100  ALW  NEV  Nie  
EF CA_Certificate  C108  ALW  NEV  Nie  
EF Link_Certificate  C109  ALW  NEV  Nie  
EF EGF  2F2F  SM-MAC  NEV 
(ze strony VU)  Nie 
EF VU  2F30  SM-MAC  SM-MAC  Nie  
Plik / element danych  Nr rekordu  Rozmiar (w bajtach)  Wartości 
domyślne  
Min.  Maks.  
MF 552  1031  
EF.ICC  
sensorGNSSSerialNumber  8  8  
DF GNSS Facility  612  1023  
EF EGF_MACertificate  204  341  
EGFCertificate  204  341  {00..00}  
EF CA_Certificate  204  341  
MemberStateCertificate  204  341  {00..00}  
EF Link_Certificate  204  341  
LinkCertificate  204  341  {00..00}  
EF EGF  
Komunikat RMC NMEA  '01'  8 5  8 5  
Pierwszy komunikat GSA NMEA  '02'  8 5  8 5  
Drugi komunikat GSA NMEA  '03'  8 5  8 5  
Trzeci komunikat GSA NMEA  '04'  8 5  8 5  
Czwarty komunikat GSA NMEA  '05'  8 5  8 5  
Piąty komunikat GSA NMEA  '06'  8 5  8 5  
Rozszerzony numer seryjny urządzenia 
zewnętrznego GNSS zdefiniowany 
w dodatku 1 jako SensorGNSSSerial­
Number.  '07' 8  8  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 514  
Plik / element danych  Nr rekordu  Rozmiar (w bajtach)  Wartości 
domyślne  
Identyfikator systemu operacyjnego 
bezpiecznego nadajnika-odbiornika 
GNSS zdefiniowany w dodatku 
1 jako SensorOSIdentifier.  '08' 2  2  
Numer homologacji typu urządzenia 
zewnętrznego GNSS zdefiniowany 
w dodatku 1 jako SensorExternal­
GNSSApprovalNumber.  '09' 1 6  1 6  
Identyfikator elementu zabezpieczenia 
urządzenia zewnętrznego GNSS zdefi­
niowany w dodatku 1 jako SensorEx­
ternalGNSSSCIdentifier.  '10' 8  8  
Komunikat AMC  '11'  8 5  8 5  
Pierwszy komunikat ASA  '12'  8 5  8 5  
Drugi komunikat ASA  '13'  8 5  8 5  
Trzeci komunikat ASA  '14'  8 5  8 5  
Czwarty komunikat ASA  '15'  8 5  8 5  
Piąty komunikat ASA  '16'  8 5  8 5  
RFU – zarezerwowane dla przyszłego 
użytku  Od '17' do 
'FD' 
EF VU  
VuRtcTime (zob. dodatek 1)  '01'  4  4  {00..00}  
VuGnssMaximalTimeDifference (zob. 
dodatek 1)  '02' 2  2  {00..00}  
▼B 
4.2.2  Bezpieczne przesy łanie danych GNSS  
▼M3 
GNS_22 Bezpieczne przesyłanie danych GNSS o pozycji, czasu 
RTC VU i maksymalnej różnicy czasowej między czasem 
prawdziwym a czasem RTC VU jest dozwolone wyłącznie 
w następujących warunkach:  
▼B 
1. proces powiązania został przeprowadzony w sposób 
opisany w dodatku 11 „Wspólne mechanizmy zabezpie­
czenia”;  
2. proces okresowego wzajemnego uwierzytelniania 
i uzgadniania klucza sesji między VU a urządzeniem 
zewnętrznym GNSS, również opisany w dodatku 11 
„Wspólne mechanizmy zabezpieczenia”, przeprowa­
dzono ze wskazaną częstotliwością.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 515  
GNS_23 Co T sekund, gdzie T jest wartością nie większą niż 20, 
chyba że trwa proces powiązania lub wzajemnego uwierzy­
telnienia i uzgadniania klucza sesji, VU żąda od urządzenia 
zewnętrznego GNSS przesłania informacji o pozycji 
w oparciu o poniższy schemat.  
1. VU żąda od urządzenia zewnętrznego GNSS przesłania 
danych dotyczących pozycji wraz z danymi dotyczącymi 
rozmycia dokładności (z komunikatów GSA i ASA). 
Bezpieczny nadajnik-odbiornik VU stosuje zgodne z wymo­
gami normy ISO/IEC 7816-4:2013 polecenia SELECT 
[wybór] i READ RECORD(S) [odczyt rekordu(-ów)] 
w trybie tylko uwierzytelniania bezpiecznej wymiany komu­
nikatów, jak opisano w dodatku 11 sekcja 11.5, z identyfi­
katorem pliku „2F2F” i numerem rekordu „01” w przypadku 
komunikatu RMC NMEA, „02”,„03”,„04”,„05”,„06” 
w przypadku komunikatu GSA NMEA, „11” w przypadku 
komunikatu AMC oraz „12”,„13”,„14”,„15”,„16” w przy­
padku komunikatu ASA.  
2. Dane dotyczące pozycji otrzymane jako ostatnie są prze­
chowywane w pliku elementarnym z identyfikatorem 
„2F2F” i rekordami opisanymi w tabeli 1 w bezpiecznym 
nadajniku-odbiorniku GNSS, ponieważ bezpieczny 
nadajnik-odbiornik GNSS otrzymuje dane NMEA z częs­
totliwością co najmniej 1 Hz od odbiornika GNSS za 
pośrednictwem interfejsu danych GNSS.  
3. Bezpieczny nadajnik-odbiornik GNSS wysyła odpo­
wiedź do bezpiecznego nadajnika-odbiornika VU za 
pomocą komunikatu odpowiedzi APDU w trybie tylko 
uwierzytelniania bezpiecznej wymiany komunikatów, 
zgodnie z opisem przedstawionym w dodatku 11 sekcja 
11.5.  
4. Bezpieczny nadajnik-odbiornik VU weryfikuje auten­
tyczność i integralność otrzymanej odpowiedzi. W przy­
padku pozytywnego wyniku dane dotyczące pozycji są 
przekazywane do procesora VU za pośrednictwem inter­
fejsu danych GNSS.  
5. Procesor VU sprawdza otrzymane dane, wyodrębniając 
informacje (np. o długości geograficznej, szerokości 
geograficznej, czasie) z komunikatu NMEA RMC. 
Komunikat RMC NMEA zawiera informację o tym, 
czy nieuwierzytelniona pozycja jest prawidłowa. Jeżeli 
uwierzytelniona pozycja jest prawidłowa, procesor VU 
wyodrębnia również wartości HDOP z komunikatów 
NMEA GSA i oblicza minimalną wartość w stosunku 
do dostępnych systemów satelitarnych (tj. jeżeli usta­
lenie pozycji jest możliwe).  
6. Procesor VU wyodrębnia również informacje (np. 
o długości geograficznej, szerokości geograficznej, 
czasie) z komunikatu AMC. Komunikat AMC zawiera 
informacje, czy uwierzytelniona pozycja jest nieprawid­ 
łowa lub czy sygnał GNSS został zaatakowany. Jeżeli 
pozycja jest prawidłowa, procesor VU wyodrębnia 
również wartości HDOP z komunikatów ASA i oblicza 
minimalną wartość w stosunku do dostępnych systemów 
satelitarnych (tj. jeżeli ustalenie pozycji jest możliwe).  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 516  
GNS_23a VU zapisuje również czas RTC VU i maksymalną różnicę 
czasu między czasem prawdziwym a czasem RTC VU, 
stosownie do potrzeb, stosując polecenia SELECT [wybór] 
i WRITE RECORD(S) [zapis rekordu(-ów)] zgodnie 
z normą ISO/IEC 7816-4:2013 w trybie tylko uwierzytel­
niania bezpiecznej wymiany komunikatów, jak opisano 
w dodatku 11 sekcja 11.5, z identyfikatorem pliku „2F30” 
i numerem rekordu równym „01” dla VuRtcTime oraz „02” 
for MaximalTimeDifference.  
▼B 
4.2.3  Struktura polecenia Read Record  
Poniższa sekcja zawiera szczegółowy opis struktury polecenia Re ad 
Record. Zgodnie z opisem przedstawionym w dodatku 11 „Wspólne 
mechanizmy zabezpieczenia” dodaje się funkcję bezpiecznej wymia ny 
komunikatów (tryb tylko uwierzytelniania).  
GNS_24 Polecenie to obsługuje tryb tylko uwierzytelniania 
bezpiecznej wymiany komunikatów, zob. dodatek 11.  
GNS_25 Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „0Ch”  Żądanie bezpiecznej wymiany komuni­
katów  
INS 1  „B2h”  Odczyt rekordu  
P1 1  „XXh”  Numer rekordu („00” oznacza bieżący 
rekord)  
P2 1  „04h”  Odczytaj rekord o numerze rekordu 
wskazanym w P1  
Le 1  „XXh”  Długość oczekiwanych danych. Liczba 
bajtów do odczytu  
GNS_26 Rekord wskazany w P1 staje się rekordem bieżącym.  
Bajt Długość  Wartość  Opis  
#1-#X  X  „XX..XXh”  Odczyt danych  
SW 2  „XXXXh”  Słowo stanu (SW1, SW2)  
— jeżeli wykonanie polecenia zakończyło się pomyślnie, 
bezpieczny nadajnik-odbiornik GNSS zwraca komu­
nikat „ 9000 ”, 
— jeżeli bieżący plik nie jest ukierunkowany na rekord, 
bezpieczny nadajnik-odbiornik GNSS zwraca komu­
nikat  „6981” , 
— jeżeli stosuje się polecenie z P1= „00”, lecz nie ma 
żadnego bieżącego pliku elementarnego, bezpieczny 
nadajnik-odbiornik GNSS zwraca komunikat  „6986”  
(polecenie niedozwolone),  
▼M3 
— jeżeli nie znaleziono rekordu, bezpieczny 
nadajnik-odbiornik GNSS zwraca komunikat „6A83”,  
— jeżeli urządzenie zewnętrzne GNSS wykryje manipulo­
wanie, zwraca słowa stanu „6690”.  
__________  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 517  
4.2.4  Struktura polecenia WriteRecord  
Poniższa sekcja zawiera szczegółowy opis struktury polecenia Wr ite 
Record [zapis rekordu]. Zgodnie z opisem przedstawionym w dodat ku 
11 „Wspólne mechanizmy zabezpieczenia” dodaje się funkcję 
bezpiecznej wymiany komunikatów (tryb tylko uwierzytelniania).  
GNS_26a Polecenie to obsługuje tryb tylko uwierzytelniania 
bezpiecznej wymiany komunikatów, zob. dodatek 11.  
GNS_26b Komunikat polecenia  
Bajt Długość  Wartość  Opis  
CLA  1  „0Ch”  Żądanie bezpiecznej wymiany komuni­
katów  
INS 1  „D2h”  Zapis rekordu  
P1 1  „XXh”  Numer rekordu ('00' oznacza bieżący 
rekord)  
P2 1  „04h”  Zapis rekordu o numerze rekordu wska­
zanym w P1  
Dane  X  „XXh”  Dane  
GNS_26c Rekord wskazany w P1 staje się rekordem bieżącym.  
Bajt Długość  Wartość  Opis  
SW 2  „XXXXh”  Słowa stanu (SW1, SW2)  
— Jeżeli wykonanie polecenia zakończyło się pomyślnie, 
bezpieczny nadajnik-odbiornik GNSS zwraca komu­
nikat „ 9000 ”. 
— Jeżeli bieżący plik nie jest ukierunkowany na rekord, 
bezpieczny nadajnik-odbiornik GNSS zwraca komu­
nikat  '6981' . 
— Jeżeli stosuje się polecenie z P1= „00”, lecz nie ma 
żadnego bieżącego pliku elementarnego, bezpieczny 
nadajnik-odbiornik GNSS zwraca komunikat  '6986'  
(polecenie niedozwolone).  
— Jeżeli nie znaleziono rekordu, bezpieczny 
nadajnik-odbiornik GNSS zwraca komunikat  '6A83' . 
— Jeżeli urządzenie zewnętrzne GNSS wykryje manipulo­
wanie, zwraca słowa stanu  „6690” . 
4.2.5.  Inne polecenia  
GNS_27 Bezpieczny nadajnik-odbiornik GNSS obsługuje następu­
jące polecenia tachografów 2. generacji, wyszczególnione 
w dodatku 2:  
Polecenie  Odniesienie  
Select [wybór]  Dodatek 2 rozdział 3.5.1  
Read Binary [odczyt binarny]  Dodatek 2 rozdział 3.5.2  
Get Challenge [wydanie wezwania]  Dodatek 2 rozdział 3.5.4  
PSO: Verify Certificate [weryfikacja 
certyfikatu]  Dodatek 2 rozdział 3.5.7  
External authenticate [uwierzytel­
nianie zewnętrzne]  Dodatek 2 rozdział 3.5.9  
General Authenticate [uwierzytel­
nianie ogólne]  Dodatek 2 rozdział 3.5.10  
MSE:SET  Dodatek 2 rozdział 3.5.11  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 518  
4.3. Powi ązanie, wzajemne uwierzytelnienie i uzgodnienie klucza sesji 
między urządzeniem zewn ętrznym GNSS a przyrz ądem rejestru ­
jącym 
Proces powiązania, wzajemnego uwierzytelniania i uzgadniania kl ucza 
sesji między urządzeniem zewnętrznym GNSS a przyrządem rejestru ­
jącym opisano w rozdziale 11 dodatku 11 „Wspólne mechanizmy 
zabezpieczenia”.  
4.4. Obs ługa błędów 
W niniejszej sekcji opisano sposób obsługi potencjalnych warunk ów 
błędów przez urządzenie zewnętrzne GNSS oraz ich rejestrowania 
w VU.  
4.4.1  Błąd komunikacji z urz ądzeniem zewn ętrznym GNSS  
▼M3 
GNS_28 Błąd połączenia z urządzeniem zewnętrznym GNSS zapi­
suje się w VU, jak określono w wymogu 82 w załączniku 
IC i dodatku 1 (EventFaultType). W tym kontekście wystę­
puje błąd połączenia, gdy bezpieczny nadajnik-odbiornik 
VU nie otrzyma komunikatu odpowiedzi po wysłaniu 
komunikatu żądania, jak opisano w pkt 4.2.  
▼B 
4.4.2  Naruszenie integralno ści fizycznej urz ądzenia zewn ętrznego GNSS  
▼M3 
GNS_29 W przypadku naruszenia integralności fizycznej urządzeni a 
zewnętrznego GNSS bezpieczny nadajnik-odbiornik GNSS 
gwarantuje niedostępność materiału kryptograficznego. Jak 
opisano w GNS_25 i GNS_26, VU wykrywa manipulo­
wanie, jeżeli odpowiedź ma status „6690”. Następnie VU 
generuje i rejestruje zdarzenie związane z próbą naruszenia 
zabezpieczenia zdefiniowane w wymogu 85 w załączniku 
IC i dodatku 1 (EventFaultType do celów wykrywania 
manipulowania w GNSS). Urządzenie zewnętrzne GNSS 
może ewentualnie odpowiedzieć na żądania VU bez 
bezpiecznej wymiany komunikatów i ze statusem „6A88”.  
▼B 
4.4.3  Brak informacji o po łożeniu z odbiornika GNSS  
▼M3 
GNS_30 Jeżeli bezpieczny nadajnik-odbiornik GNSS nie otrzymuje 
danych z odbiornika GNSS, urządzenie to generuje komu­
nikat odpowiedzi na polecenie READ RECORD [odczyt 
rekordu] z numerem rekordu „01” i polem danych 
o rozmiarze 12 bajtów, wszystkich ustawionych na 0xFF. 
Po otrzymaniu komunikatu odpowiedzi zawierającego tę 
wartość pola danych VU generuje i rejestruje brak infor­
macji o pozycji ze zdarzenia odbiornika GNSS, jak okre­ 
ślono w wymogu 81 w załączniku IC i dodatku 1 (Even­
tFaultType).  
▼B 
4.4.1  Wyga śnięcie certyfikatu urz ądzenia zewn ętrznego GNSS  
▼M3 
GNS_31 Jeżeli VU wykryje, że certyfikat EGF stosowany do 
wzajemnego uwierzytelniania nie jest już ważny, VU gene­
ruje i rejestruje zdarzenie związane z próbą naruszenia 
zabezpieczenia zdefiniowane w wymogu 85 w załączniku 
IC i dodatku 1 (EventFaultType dla wygaśnięcia certyfi­
katu urządzenia zewnętrznego GNSS). VU nadal wyko­
rzystuje otrzymane dane GNSS o pozycji.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 519  
Rysunek 6  
Schemat urz ądzenia zewn ętrznego GNSS  
▼B
 
5. PRZYRZĄD REJESTRUJĄCY BEZ URZĄDZENIA ZEWNĘTRZ­
NEGO GNSS  
5.1. Konfiguracja  
W tej konfiguracji odbiornik GNSS znajduje się wewnątrz przyrzą du 
rejestrującego, jak przedstawiono na rys. 1.  
▼M3 
GNS_32 Na potrzeby przekazywania pozycji, DOP i danych sateli­
tarnych odbiornik GNSS pełni funkcję nadajnika i przesyła 
komunikaty NMEA i podobne do NMEA do procesora 
VU, który pełni funkcję odbiornika o częstotliwości 1/10 
Hz lub większej dla zdefiniowanego wcześniej zbioru 
komunikatów, który musi obejmować co najmniej komu­
nikaty RMC, GSA, AMC i ASA. Procesor VU 
i wewnętrzny odbiornik GNSS mogą ewentualnie wyko­
rzystywać inne formaty danych do wymiany danych zawar­
tych w komunikatach NMEA lub podobnych do NMEA 
określonych w GNS_4, GNS_4a i GNS_5.  
▼B 
GNS_33 Do VU musi być podłączona zewnętrzna antena GNSS 
zainstalowana na pojeździe lub wewnętrzna antena GNSS.  
▼M3 
5.2. Transfer informacji z odbiornika GNSS do VU  
GNS_34 Procesor VU sprawdza otrzymane dane, wyodrębniając 
informacje (np. o długości geograficznej, szerokości 
geograficznej, czasie) z komunikatu RMC NMEA i komu­
nikatu AMC.  
GNS_35 Komunikat RMC NMEA zawiera informację o tym, czy 
nieuwierzytelniona pozycja jest prawidłowa. Jeżeli 
nieuwierzytelniona pozycja nie jest prawidłowa, dane doty­
czące pozycji nie są dostępne i nie można ich wykorzystać 
w celu zarejestrowania pozycji pojazdu. Jeżeli nieuwierzy­
telniona pozycja jest prawidłowa, procesor VU wyodrębnia 
również wartości HDOP z GSA NMEA.  
GNS_36 Procesor VU wyodrębnia również informacje (np. 
o długości geograficznej, szerokości geograficznej, czasie) 
z komunikatu AMC. Komunikat AMC zawiera informację 
o tym, czy nieuwierzytelniona pozycja jest prawidłowa 
zgodnie z GNS_4a. Jeżeli nieuwierzytelniona pozycja jest 
prawidłowa, procesor VU wyodrębnia również wartości 
HDOP z komunikatów ASA.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 520  
5.3. Transfer informacji z VU do odbiornika GNSS  
GNS_37 Procesor VU przekazuje do odbiornika GNSS czas RTC 
VU oraz maksymalną różnicę między czasem prawdziwym 
a czasem RTC VU, zgodnie z GNS_3f i GNS_3g.  
5.4. Obs ługa błędów 
5.4.1. Brak informacji o pozycji z odbiornika GNSS  
GNS_38 VU generuje i rejestruje brak informacji o pozycji ze 
zdarzenia odbiornika GNSS, jak określono w wymogu 81 
w załączniku IC i dodatku 1 (EventFaultType).  
6. PRZETWARZANIE I REJESTRACJA DANYCH O POZYCJI 
PRZEZ VU  
Sekcja ta ma zastosowanie w odniesieniu do konfiguracji tachogr afu 
inteligentnego z urządzeniem zewnętrznym GNSS lub bez niego.  
GNS_39 Dane o pozycji są przechowywane w VU wraz z flagą 
wskazującą, czy pozycja została uwierzytelniona. Jeżeli 
konieczne jest zarejestrowanie danych dotyczących pozycji 
w VU, zastosowanie mają następujące zasady:  
a) Jeżeli zarówno uwierzytelniona pozycja, jak i standar­
dowa pozycja są prawidłowe i spójne, standardową 
pozycję i jej dokładność rejestruje się w VU, a flaga 
ustawiana jest na „uwierzytelniona”.  
b) Jeżeli zarówno uwierzytelniona pozycja, jak i standar­
dowa pozycja są prawidłowe, ale nie są spójne, VU 
zapisuje uwierzytelnioną pozycję i jej dokładność, 
a flaga ustawiana jest na „uwierzytelniona”.  
c) Jeżeli uwierzytelniona pozycja jest prawidłowa, a stan­
dardowa pozycja nie jest prawidłowa, VU rejestruje 
uwierzytelnioną pozycję i jej dokładność, a flaga usta­
wiana jest na „uwierzytelniona”.  
d) Jeżeli standardowa pozycja jest prawidłowa, a uwierzy­
telniona pozycja nie jest prawidłowa, VU rejestruje stan­
dardową pozycję i jej dokładność, a flaga ustawiana jest 
na „nieuwierzytelniona”.  
Uwierzytelnione i standardowe pozycje uznaje się za 
spójne, jak pokazano na rys. 7, jeżeli uwierzytelniona 
pozycja pozioma znajduje się w okręgu o środku w standar­
dowej pozycji poziomej, którego promień wynika z zaokrąg­
lenia w górę do najbliższej liczby całkowitej wartości R_H 
obliczonej według następującego wzoru: 
R_H = 1,74 • σ  UERE  • HDOP  
gdzie:  
— R_H to odpowiedni promień okręgu wokół szacowanej 
pozycji poziomej, w metrach. Jest to wskaźnik używany 
do kontroli spójności między pozycją standardową 
a pozycją uwierzytelnioną.  
— σ  UERE  to odchylenie standardowe ekwiwalentnego 
błędu pomiaru odległości użytkownika (UERE), gdzie 
modeluje się wszystkie błędy pomiaru dla docelowego 
zastosowania, w tym obszarów miejskich. Stosuje się 
wartość stałą σ  UERE  = 10 metrów.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 521  
— HDOP oznacza poziome rozmycie dokładności obliczeń 
odbiornika GNSS.-  
— σ  UERE  . HDOP to oszacowanie pierwiastka błędu śred­
niokwadratowego w poziomie.  
Rysunek 7  
Spójne pozycje uwierzytelnione i standardowe (nieuwierzytelnione)
  
GNS_40 Jeżeli wartość statusu w otrzymanym komunikacie AMC 
jest ustawiona na „J” lub „O” lub „F” zgodnie z wymogiem 
GNS_4a, VU generuje i rejestruje zdarzenie anomalii 
GNSS, jak określono w wymogu 88a w załączniku IC 
i dodatku 1 (EventFaultType). Przyrząd rejestrujący może 
przeprowadzić dodatkowe kontrole przed zapisaniem 
zdarzenia anomalii GNSS po otrzymaniu ustawienia „J” 
lub „O”.  
7. KONFLIKT CZASOWY GNSS  
GNS_41 Jeżeli VU wykryje rozbieżność między czasem funkcji 
pomiaru czasu przyrządu rejestrującego a czasem pocho­
dzącym z sygnałów GNSS, generuje i rejestruje zdarzenie 
konfliktu czasowego, jak określono w wymogu 86 
w załączniku IC i dodatku 1 (EventFaultType).  
8. KONFLIKT RUCHU POJAZDU  
GNS_42 VU uruchamia i rejestruje zdarzenie konfliktu ruchu 
pojazdu zgodnie z wymogiem 84 w załączniku IC, w przy­
padku gdy informacja o ruchu obliczona na podstawie 
czujnika ruchu jest sprzeczna z informacjami o ruchu obli­
czonymi na podstawie wewnętrznego odbiornika GNSS, 
urządzenia zewnętrznego GNSS lub przez inne niezależne 
źródła ruchu określone w wymogu 26 w załączniku IC.  
Zdarzenie konfliktu ruchu pojazdu uruchamia się po wystą­
pieniu jednego z następujących warunków uruchamiają­
cych:  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 522  
Warunek uruchamiający 1:  
W przypadku gdy dostępne są informacje o pozycji 
z odbiornika GNSS i gdy następuje włączenie zapłonu 
pojazdu, należy stosować wartość średniej trymowanej 
różnic prędkości między tymi źródłami, jak określono 
poniżej:  
— maksymalnie co 10 sekund należy obliczać wartość 
bezwzględną różnicy między różnicą prędkości pojazdu 
szacowaną na podstawie danych z odbiornika GNSS 
a różnicą szacowaną na podstawie danych z czujnika 
ruchu,  
— wartość średniej trymowanej oblicza się wykorzystując 
wszystkie obliczone wartości w oknie czasu obejmu­
jącym 5 ostatnich minut ruchu pojazdu,  
— wartość średniej trymowanej oblicza się jako średnią 
80 % wartości pozostałych po wyeliminowaniu najwyż­
szych wartości bezwzględnych.  
zdarzenie konfliktu ruchu pojazdu jest wyzwalane jeżeli 
wartość średniej trymowanej jest wyższa niż 10 km/h 
przez pięć nieprzerwanych minut ruchu pojazdu. (Uwaga: 
średnią trymowaną z ostatnich 5 minut stosuje się, aby 
zmniejszyć ryzyko związane z wartościami skrajnymi 
pomiaru i wartościami chwilowymi).  
Na potrzeby obliczenia średniej trymowanej pojazd uznaje 
się za poruszający się, jeżeli co najmniej jedna wartość 
prędkości pojazdu oszacowana na podstawie czujnika 
ruchu albo odbiornika GNSS nie jest równa zeru.  
Warunek uruchamiający 2:  
Zdarzenie konfliktu ruchu pojazdu jest również urucha­
miane, jeżeli spełniony jest następujący warunek:  
GnssDistance >[OdometerDifference ×OdometerTolerance ­
Factor +Minimum  (SlipDistanceUpperlimit ;(OdometerDiffe ­
rence ×SlipFactor ))+GnssTolerance +FerryTrainDistance ] 
gdzie:  
— GnssDistance  to odległość między bieżącą pozycją 
pojazdu a poprzednią pozycją, uzyskanymi na 
podstawie komunikatów o prawidłowej pozycji uwie­
rzytelnionej, bez uwzględniania wysokości;  
— OdometerDifference  to różnicą między bieżącą warto­ 
ścią licznika kilometrów a wartością licznika kilo­
metrów odpowiadającą poprzedniemu komunikatowi 
o prawidłowej pozycji uwierzytelnionej;  
— OdometerToleranceFactor  wynosi 1,1 (współczynnik 
tolerancji najbardziej niekorzystnego przypadku dla 
wszystkich tolerancji pomiaru licznika kilometrów 
pojazdu);  
— GnssTolerance  wynosi 1 km (najbardziej niekorzystny 
przypadek tolerancji GNSS);  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 523  
— Minimum (SlipDistanceUpperLimit; (OdometerDiffe ­
rence * SlipFactor))  to wartość najmniejsza spośród 
następujących:  
— SlipDistanceUpperLimit , która wynosi 10 km 
(górna granica drogi poślizgu spowodowanej efek­
tami poślizgowymi podczas hamowania)  
— oraz  OdometerDifference * SlipFactor , gdzie Slip­
Factor wynosi 0,2 (maksymalny wpływ efektów 
poślizgowych podczas hamowania),  
— FerryTrainDistance  oblicza się jako: FerryTrainDis­
tance =200km/h * tFerryTrain, gdzie tFerryTrain jest 
sumą czasu trwania (w godzinach) przepraw promo­
wych/pociągowych w analizowanym przedziale 
czasowym. Czas trwania przepraw promowych/pocią­
gowych definiuje się jako różnicę czasu między jego 
flagą końcową a jego flagą początkową.  
Poprzedzające weryfikacje przeprowadza się co 15 minut, 
jeżeli dostępne są niezbędne dane o pozycji, a w prze­
ciwnym razie, gdy tylko dostępne będą dane o pozycji.  
Dla tego warunku uruchamiającego:  
— data i godzina rozpoczęcia zdarzenia równa się dacie 
i godzinie otrzymania poprzedniego komunikatu 
o pozycji,  
— data i godzina zakończenia zdarzenia są równa się 
dacie i godzinie, kiedy sprawdzany warunek staje się 
ponownie fałszywy.  
Warunek uruchamiający 3:  
Przyrząd rejestrujący napotyka rozbieżność polegającą na 
tym, że czujnik ruchu nie wykrywa żadnego ruchu, a nieza­
leżne źródło ruchu wykrywa ruch przez określony czas. 
Producent przyrządów rejestrujących określa warunki reje­
strowania rozbieżności, jak również okres wykrywania 
rozbieżności, przy czym rozbieżności te muszą być wykry­
wane nie później niż w ciągu trzech godzin.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 524  
Dodatek 13  
INTERFEJS ITS  
SPIS TREŚCI  
1. WPROWADZENIE  
1.1. Zakres  
1.2. Akronimy i definicje  
2. PRZYWOŁANE NORMY  
3. ZASADY DZIAŁANIA INTERFEJSU ITS  
3.1. Technologia łączności  
3.2. Dostępne usługi  
3.3. Dostęp poprzez interfejs ITS  
3.4. Dostępne dane i wymóg uzyskania zgody kierowcy  
4. WYKAZ DANYCH DOSTĘPNYCH ZA POŚREDNICTWEM INTER­ 
FEJSU ITS ORAZ KLASYFIKACJA DANYCH JAKO OSOBOWE/ 
NIEOSOBOWE  
1. WPROWADZENIE  
1.1. Zakres  
ITS_01 Niniejszy dodatek określa podstawowe elementy łączności za 
pośrednictwem interfejsu tachografu z inteligentnymi systemami 
transportowymi (ITS), zgodnie z art. 10 i 11 rozporządzenia (UE ) 
nr 165/2014.  
ITS_02 Interfejs ITS umożliwia urządzeniom zewnętrznym uzyskiwa nie 
danych z tachografu, korzystanie z usług tachografu oraz dostar ­
czanie danych do tachografu.  
Do tego celu mogą być również wykorzystywane inne interfejsy 
tachografu (np. szyna CAN).  
Niniejszy dodatek nie określa:  
— w jaki sposób dane dostarczane za pośrednictwem interfejsu 
ITS są gromadzone i zarządzane w ramach tachografu;  
— formy przedstawienia zgromadzonych danych w aplikacji zain­
stalowanej na urządzeniu zewnętrznym;  
— specyfikacji zabezpieczeń ITS uzupełniających zabezpieczenia 
zapewniane przez Bluetooth®;  
— protokołów Bluetooth® wykorzystywanych przez interfejs ITS.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 525  
1.2. Akronimy i definicje  
Stosuje się następujące akronimy i definicje właściwe dla tego dodatku:  
GNSS  Global Navigation Satellite System [globalny system nawi­
gacji satelitarnej]  
ITS Intelligent Transport System [inteligentny system transpor­
towy]  
OSI Open Systems Interconnection [połączenie systemów otwar­
tych]  
VU Vehicle Unit [przyrząd rejestrujący]  
urządzenie ITS urządzenie zewnętrzne lub aplikacja zewnętrzna wykorzys­
tujące interfejs ITS VU.  
2. PRZYWOŁANE NORMY  
ITS_03 Niniejszy dodatek dotyczy wszystkich lub części wskazany ch 
poniżej regulacji i norm i jest od nich zależny. W ramach zapis ów 
niniejszego dodatku wskazano odnośne normy lub odnośne prze­
pisy norm. W razie jakichkolwiek sprzeczności zapisy niniejszeg o 
dodatku są nadrzędne.  
Normami przywołanymi w niniejszym dodatku, są:  
— Bluetooth® – Core Version (wersja podstawowa) 5.0;  
— ISO 16844-7: Pojazdy drogowe – Systemy tachograficzne – 
Część 7: Parametry  
— ISO/IEC7498-1:1994 Technologia informatyczna – Współdzia­ 
łanie systemów otwartych – Podstawowy model odniesienia: 
Model podstawowy  
3. ZASADY DZIAŁANIA INTERFEJSU ITS  
ITS_04 Przyrząd rejestrujący odpowiada za aktualizowanie i utrz ymywanie 
danych tachografu przesyłanych za pośrednictwem interfejsu ITS,  
bez żadnego udziału interfejsu ITS.  
3.1. Technologia łączności 
ITS_05 Łączność poprzez interfejs ITS musi być zapewniana za po średnic­
twem interfejsu Bluetooth® i kompatybilna z Bluetooth® Low 
Energy [o niskim zużyciu energii] zgodnie z wersją 5.0 lub nows zą 
Bluetooth .  
ITS_06 Łączność między VU a urządzeniem ITS ustanawia się po za koń­
czeniu procesu parowania Bluetooth®.  
ITS_07 Ustanawia się bezpieczną i zaszyfrowaną łączność między VU 
a urządzeniem ITS, zgodnie z mechanizmami specyfikacji 
Bluetooth®. Niniejszy dodatek nie określa mechanizmów szyfro­
wania ani innych mechanizmów zabezpieczenia poza tym, co 
zapewnia Bluetooth®.  
ITS_08 Bluetooth® wykorzystuje model serwer/klient do kontroli trans­
misji danych między urządzeniami, gdzie VU jest serwerem, a urz ą­
dzenie ITS klientem.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 526  
3.2. Dostępne usługi 
ITS_09 Dane przekazywane za pośrednictwem interfejsu ITS zgodni e 
z pkt 4 udostępnia się za pośrednictwem usług określonych 
w dodatkach 7 i 8. Ponadto VU udostępnia urządzeniu ITS usługi 
niezbędne do ręcznego wprowadzania danych zgodnie z wymogiem 
61 w załączniku IC oraz opcjonalnie w odniesieniu do innych 
wpisów danych w czasie rzeczywistym.  
Rysunek 1  
Podział łączności poprzez interfejs ITS zgodnie z warstwami modelu OSI
  
ITS_10 Jeżeli interfejs pobierania jest używany przez złącze pr zednie, VU 
nie świadczy usług pobierania określonych w dodatku 7 za pośred ­
nictwem połączenia ITS Bluetooth®.  
ITS_11 Jeżeli interfejs kalibracji jest używany przez złącze pr zednie, VU 
nie świadczy usług kalibracji określonych w dodatku 8 za pośred ­
nictwem połączenia ITS Bluetooth®.  
3.3. Dostęp poprzez interfejs ITS  
ITS_12 Interfejs ITS zapewnia bezprzewodowy dostęp do wszystkic h usług 
określonych w dodatkach 7 i 8, zastępując połączenie kablowe 
z przednim złączem do celów kalibracji i pobierania określonych  
w dodatku 6.  
ITS_13 VU udostępnia interfejs ITS użytkownikowi zgodnie z komb inacją 
ważnych kart do tachografów włożonych do VU, jak określono 
w tabeli 1.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 527  
Tabela 1  
Dostępność interfejsu ITS w zale żności od typu karty w łożonej do tachografu  
Dostępność interfejsu ITS  Szczelina czytnika karty kierowcy  
Brak karty  Karta kierowcy  Karta kontrolna  Karta warsztatowa  Karta firmowa
 Szczelina czytnika karty współkierowcy 
Brak karty  niedostępny  dostępny  dostępny  dostępny  dostępny  
Karta kierowcy  dostępny  dostępny  dostępny  dostępny  dostępny  
Karta kontrolna  dostępny  dostępny  dostępny  niedostępny  niedostępny  
Karta warsz­
tatowa  dostępny  dostępny  niedostępny  dostępny  niedostępny  
Karta firmowa  dostępny  dostępny  niedostępny  niedostępny  dostępny  
ITS_14 Po udanym sparowaniu ITS Bluetooth® VU przypisuje połącz enie ITS Bluetooth® do konkretnej karty 
włożonej do tachografu zgodnie z tabelą 2:  
Tabela 2  
Przypisanie po łączenia ITS w zale żności od typu karty w łożonej do tachografu  
Przypisanie połączenia ITS 
Bluetooth®  Szczelina czytnika karty kierowcy  
Brak karty  Karta kierowcy  Karta kontrolna  Karta warsztatowa  Karta firmowa
 Szczelina czytnika karty współkierowcy Brak karty  niedostępny  Karta kierowcy  Karta kontrolna  Karta warsz­
tatowa  Karta firmowa  
Karta kierowcy  Karta kierowcy  Karta 
kierowcy (**)  Karta kontrolna  Karta warsz­
tatowa  Karta firmowa  
Karta kontrolna  Karta kontrolna  Karta kontrolna  Karta 
kontrolna (*)  niedostępny  niedostępny  
Karta warsz­
tatowa  Karta warsz­
tatowa  Karta warsz­
tatowa  niedostępny  Karta warsz­
tatowa (*)  niedostępny  
Karta firmowa  Karta firmowa  Karta firmowa  niedostępny  niedostępny  Karta 
firmowa (*)  
(*) Połączenie ITS Bluetooth® przypisuje się karcie do tachogra fu w szczelinie czytnika karty kierowcy VU. 
(**) Użytkownik wybiera kartę, do której należy przypisać połąc zenie ITS Bluetooth® (włożoną do szczeliny czytnika karty kiero wcy 
lub współkierowcy).  
ITS_15 Jeżeli karta do tachografu zostaje wyjęta, VU kończy poł ączenie 
ITS Bluetooth®, które jest przypisane do tej karty.  
ITS_16 VU obsługuje połączenie ITS z co najmniej jednym urządze niem 
ITS i może obsługiwać połączenia z wieloma urządzeniami ITS 
w tym samym czasie.  
ITS_17 Oprócz zgody kierowcy określonej w sekcji 3.4 niniejszeg o 
dodatku, prawa dostępu do danych i usług dostępnych za pośred­
nictwem interfejsu ITS muszą być dodatkowo zgodne z wymogami 
12 i 13 w załączniku IC.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 528  
3.4. Dostępne dane i wymóg uzyskania zgody kierowcy  
ITS_18 Wszystkie dane tachografu dostępne za pośrednictwem usłu g, 
o których mowa w pkt 3.3, klasyfikuje się jako dane osobowe 
albo nieosobowe w odniesieniu do kierowcy, współkierowcy lub 
obu tych osób.  
ITS_19 Za pośrednictwem interfejsu ITS udostępnia się przynajmn iej 
wykaz danych sklasyfikowanych w sekcji 4 jako dostępne 
obowiązkowo.  
ITS_20 Dane w sekcji 4, które sklasyfikowano jako „osobowe”, są  
dostępne wyłącznie za zgodą kierowcy, który zaakceptował, że 
dane osobowe mogą opuścić sieć pojazdu, z wyjątkiem przypadku 
określonego w wymogu ITS_25, gdzie zgoda kierowcy nie jest 
wymagana.  
ITS_21 Dane dodatkowe w stosunku do danych zgromadzonych w pkt 4 
i uznanych za obowiązkowe mogą być udostępniane poprzez inter­
fejs ITS. Dodatkowe dane, które nie są wymienione w pkt 4, są 
klasyfikowane przez producenta VU jako „osobowe” lub „nieoso­
bowe”, co oznacza, że kierowca musi wyrazić zgodę na te dane, 
które zostały sklasyfikowane jako dane osobowe, z wyjątkiem 
przypadku określonego w wymogu ITS_25, gdzie zgoda kierowcy 
nie jest wymagana.  
ITS_22 Po włożeniu karty kierowcy, która nie jest znana przyrzą dowi 
rejestrującemu, tachograf wzywa posiadacza karty do wprowa­
dzenia zgody na przesyłanie wyjściowych danych osobowych 
poprzez interfejs ITS, zgodnie z wymogiem 61 w załączniku IC.  
ITS_23 Status zgody (aktywny/nieaktywny) jest zapisywany w pami ęci 
danych przyrządu rejestrującego.  
ITS_24 W przypadku wielu kierowców udostępnianiu poprzez interf ejs ITS 
podlegają wyłącznie dane osobowe dotyczące kierowców, którzy 
wyrazili na to zgodę. Na przykład w przypadku załogi, jeżeli zg odę 
wyraził tylko kierowca, dane osobowe współkierowcy nie są 
udostępniane.  
ITS_25 Jeżeli VU znajduje się w trybie kontrolnym, firmowym lub  kalib­
racyjnym, prawami dostępu poprzez interfejs ITS zarządza się 
zgodnie z wymogami 12 i 13 w załączniku IC, w związku 
z czym zgoda kierowcy nie jest wymagana.  
4. WYKAZ DANYCH DOSTĘPNYCH ZA POŚREDNICTWEM INTER­
FEJSU ITS ORAZ KLASYFIKACJA DANYCH JAKO OSOBOWE/ 
NIEOSOBOWE  
Nazwa danych  Format danych  Źródło  Klasyfikacja danych (osobowe/nieoso­
bowe)  Zgoda na udostęp­
nienie danych  Dostępność  
kierowca  współkierowca  
VehicleIdentification­
Number  Dodatek 8  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
CalibrationDate  ISO 16844-7  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
TachographVehicle 
Speed  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  obowiąz­
kowo  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 529  
Nazwa danych  Format danych  Źródło  Klasyfikacja danych (osobowe/nieoso­
bowe)  Zgoda na udostęp­
nienie danych  Dostępność  
kierowca  współkierowca  
Driver1WorkingState  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  obowiąz­
kowo  
Driver2WorkingState  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  obowiąz­
kowo  
DriveRecognize  ISO 16844-7  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
Driver1TimeRelated­
States  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  obowiąz­
kowo  
Driver2TimeRelated­
States  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  obowiąz­
kowo  
DriverCardDriver1  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  obowiąz­
kowo  
DriverCardDriver2  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  obowiąz­
kowo  
OverSpeed  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  obowiąz­
kowo  
TimeDate  Dodatek 8  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
HighResolutionTotal­
VehicleDistance  ISO 16844-7  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
HighResolutionTrip­
Distance  ISO 16844-7  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
ServiceComponentI­
dentification  ISO 16844-7  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
ServiceDelayCalendar­
TimeBased  ISO 16844-7  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
Driver1Identification  ISO 16844-7  karta 
kier­
owcy  osobowe  nie dotyczy  zgoda kierowcy  obowiąz­
kowo  
Driver2Identification  ISO 16844-7  karta 
kier­
owcy  nie dotyczy  osobowe  zgoda współkie­
rowcy  obowiąz­
kowo  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 530  
Nazwa danych  Format danych  Źródło  Klasyfikacja danych (osobowe/nieoso­
bowe)  Zgoda na udostęp­
nienie danych  Dostępność  
kierowca  współkierowca  
NextCalibrationDate  Dodatek 8  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
Driver1ContinuousDri­
vingTime  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  obowiąz­
kowo  
Driver2ContinuousDri­
vingTime  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  obowiąz­
kowo  
Driver1CumulativeB­
reakTime  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  obowiąz­
kowo  
Driver2CumulativeB­
reakTime  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  obowiąz­
kowo  
Driver1CurrentDuratio­
nOfSelectedActivity  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  obowiąz­
kowo  
Driver2CurrentDuratio­
nOfSelectedActivity  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  obowiąz­
kowo  
SpeedAuthorised  Dodatek 8  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
TachographCardSlot1  ISO 16844-7  V U  nieosobowe  nie dotyczy  zgoda niewyma­
gana  obowiąz­
kowo  
TachographCardSlot2  ISO 16844-7  V U  nie dotyczy  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
Driver1Name  ISO 16844-7  karta 
kier­
owcy  osobowe  nie dotyczy  zgoda kierowcy  obowiąz­
kowo  
Driver2Name  ISO 16844-7  karta 
kier­
owcy  nie dotyczy  osobowe  zgoda współkie­
rowcy  obowiąz­
kowo  
OutOfScopeCondition  ISO 16844-7  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
ModeOfOperation  ISO 16844-7  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
Driver1CumulatedDri­
vingTimePreviousAn­
dCurrentWeek  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  obowiąz­
kowo  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 531  
Nazwa danych  Format danych  Źródło  Klasyfikacja danych (osobowe/nieoso­
bowe)  Zgoda na udostęp­
nienie danych  Dostępność  
kierowca  współkierowca  
Driver2CumulatedDri­
vingTimePreviousAn­
dCurrentWeek  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  obowiąz­
kowo  
EngineSpeed  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
RegisteringMember­
State  Dodatek 8  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
VehicleRegistration­
Number  Dodatek 8  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  obowiąz­
kowo  
Driver1EndOfLastDai­
lyRestPeriod  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2EndOfLastDai­
lyRestPeriod  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1EndOfLas­
tWeeklyRestPeriod  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2EndOfLas­
tWeeklyRestPeriod  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1EndOfSecond­
LastWeeklyRestPeriod  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2EndOfSecond­
LastWeeklyRestPeriod  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1TimeLastLoa­
dUnloadOperation  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2TimeLastLoa­
dUnloadOperation  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1CurrentDaily 
DrivingTime  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2CurrentDaily 
DrivingTime  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1CurrentWee­
klyDrivingTime  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2CurrentWee­
klyDrivingTime  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 532  
Nazwa danych  Format danych  Źródło  Klasyfikacja danych (osobowe/nieoso­
bowe)  Zgoda na udostęp­
nienie danych  Dostępność  
kierowca  współkierowca  
Driver1TimeLeftUntil­
NewDailyRestPeriod  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2TimeLeftUntil­
NewDailyRestPeriod  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1CardExpiry­
Date  ISO 16844-7  karta 
kier­
owcy  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2CardExpiry­
Date  ISO 16844-7  karta 
kier­
owcy  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1CardNextMan­
datoryDownloadDate  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2CardNextMan­
datoryDownloadDate  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
TachographNextMan­
datoryDownloadDate  ISO 16844-7  V U  nieosobowe  nieosobowe  zgoda niewyma­
gana  opcjonalnie  
Driver1TimeLeftUntil­
NewWeeklyRestPeriod  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2TimeLeftUntil­
NewWeeklyRestPeriod  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1Number 
OfTimes9hDaily 
DrivingTimesExceeded  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2Number 
OfTimes9hDaily 
DrivingTimesExceeded  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1Cumulative 
UninterruptedRestTime  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2Cumulative 
UninterruptedRestTime  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1Minimum 
DailyRest  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2Minimum 
DailyRest  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 533  
Nazwa danych  Format danych  Źródło  Klasyfikacja danych (osobowe/nieoso­
bowe)  Zgoda na udostęp­
nienie danych  Dostępność  
kierowca  współkierowca  
Driver1Minimum 
WeeklyRest  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2Minimum 
WeeklyRest  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1Maximum 
DailyPeriod  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2Maximum 
DailyPeriod  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1Maximum 
DailyDrivingTime  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2Maximum 
DailyDrivingTime  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1NumberOf 
UsedReducedDaily 
RestPeriods  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2NumberOf 
UsedReducedDaily 
RestPeriods  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
Driver1Remaining 
CurrentDrivingTime  ISO 16844-7  V U  osobowe  nie dotyczy  zgoda kierowcy  opcjonalnie  
Driver2Remaining 
CurrentDrivingTime  ISO 16844-7  V U  nie dotyczy  osobowe  zgoda współkie­
rowcy  opcjonalnie  
VehiclePosition  Dodatek 8  V U  osobowe  osobowe  zgoda kierowcy 
i współkierowcy  obowiąz­
kowo  
ByDefaultLoadType  Dodatek 8  V U  osobowe  osobowe  zgoda kierowcy 
i współkierowcy  obowiąz­
kowo  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 534  
Dodatek 14  
FUNKCJA ŁĄCZNOŚCI NA ODLEG ŁOŚĆ 
SPIS TREŚCI  
1 WPROWADZENIE  
2 ZAKRES  
3 SKRÓTY, DEFINICJE I OZNACZENIA  
4 SCENARIUSZE OPERACYJNE  
4.1 Informacje ogólne  
4.1.1 Warunki wstępne dotyczące przesyłania danych za pośrednic twem inter­ 
fejsu DSRC działającego na częstotliwości 5,8 GHz  
4.1.2 Profil 1a: kontrole przeprowadzane przy wykorzystaniu ręc znego czyt­ 
nika wczesnego wykrywania na odległość lub czytnika wczesnego 
wykrywania na odległość zainstalowanego tymczasowo na poboczu  
4.1.3 Profil 1b: Kontrole przeprowadzane przy wykorzystaniu uki erunkowa­ 
nego czytnika wczesnego wykrywania na odległość (REDCR) zainsta ­ 
lowanego w pojeździe  
4.2 Bezpieczeństwo/Integralność  
5 PROJEKT I PROTOKOŁY ŁĄCZNOŚCI NA ODLEGŁOŚĆ  
5.1 Projekt  
5.2 Przepływ pracy  
5.2.1 Operacje  
5.2.2 Interpretacja danych otrzymanych za pośrednictwem łącznoś ci DSRC  
5.3 Parametry interfejsu fizycznego DSRC w odniesieniu do łączn ości na 
odległość  
5.3.1 Ograniczenia dotyczące lokalizacji  
5.3.2 Parametry łącza odbiorczego ( downlink ) i łącza nadawczego ( uplink ) 
5.3.3 Projekt anteny  
5.4 Wymogi protokołu DSRC w odniesieniu do zdalnego monitorowan ia 
tachografu  
5.4.1 Informacje ogólne  
5.4.2 Polecenia  
5.4.3 Sekwencja polecenia zapytania  
5.4.4 Struktury danych  
5.4.5 Elementy danych dotyczących zdalnego monitorowania tachog rafu 
(RtmData), wykonywane czynności i definicje  
5.4.6 Mechanizm przesyłania danych  
5.4.7 Szczegółowy opis transakcji DSRC  
5.4.8 Opis transakcji testowej DSRC  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 535  
5.5 Zarezerwowane dla przyszłego użytku  
▼B 
5.6 Przesyłanie danych pomiędzy DSRC-VU a VU  
5.6.1 Połączenie fizyczne i interfejsy  
5.6.2 Protokół aplikacji  
5.7 Obsługa błędów  
5.7.1 Rejestrowanie i przekazywanie danych w DSRC-VU  
5.7.2 Błędy łączności bezprzewodowej  
6 TESTY PRZEPROWADZANE PRZY ODDANIU DO EKSPLOA­ 
TACJI ORAZ TESTY W RAMACH PRZEGLĄDÓW OKRESO­ 
WYCH FUNKCJI ŁĄCZNOŚCI NA ODLEGŁOŚĆ  
6.1 Uwagi ogólne  
6.2 ECHO  
6.3 Testy mające na celu zatwierdzanie treści zabezpieczonych d anych  
1 WPROWADZENIE  
W niniejszym dodatku określono strukturę oraz procedury, które należy 
zastosować w celu wykonania funkcji łączności na odległość („łą cz­
ność”) zgodnie z art. 9 rozporządzenia (UE) nr 165/2014 („rozpo rzą­
dzenie”).  
DSC_1 Zgodnie z rozporządzeniem (UE) nr 165/2014 tachograf musi  
być wyposażony w funkcję łączności na odległość, aby 
zapewnić przedstawicielom właściwych organów kontrolnych 
możliwość odczytywania informacji przekazywanych przez 
tachograf zainstalowany w przejeżdżających pojazdach za 
pomocą urządzeń zdalnej kontroli („czytnik wczesnego wykry­
wania na odległość” (REDCR)), a w szczególności w urzą­
dzenia kontroli łączące się bezprzewodowo za pośrednictwem 
interfejsów dedykowanej łączności krótkiego zasięgu (DSRC) 
pracujących na częstotliwości CEN 5,8 GHz.  
Należy pamiętać, że opisana funkcja jest wykorzystywana 
wyłącznie w celu wstępnej selekcji pojazdów, które zostaną 
wybrane do bardziej szczegółowej kontroli; nie zastępuje ona 
formalnego przeglądu przeprowadzanego zgodnie z przepisami 
rozporządzenia (UE) nr 165/2014. Zobacz motyw 9 w pream­
bule do tego rozporządzenia, w którym stwierdza się, że łącz­
ność na odległość między tachografem a organami kontro­
lnymi na potrzeby kontroli drogowych usprawnia ukierunko­
wane kontrole drogowe.  
DSC_2  Dane  wymienia się za pomocą  Łączności, tj. bezprzewodowej 
wymiany informacji za pośrednictwem systemu łączności 
bezprzewodowej DSRC operującego na częstotliwości 5,8 GHz 
prowadzonej zgodnie z niniejszym dodatkiem, która jest spraw­
dzana pod kątem zgodności z odpowiednimi parametrami prze­
widzianymi w normie 300 674-1 {Kwestie dotyczące kompaty­
bilności elektromagnetycznej i widma radiowego (ERM); telema­
tyka transportu i ruchu drogowego (RTTT); dedykowana łącz­
ność krótkiego zasięgu (DSRC) utrzymywana za pośrednictwem  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 536  
urządzeń transmisyjnych (500 kbit/s / 250 kbit/s) działających na 
częstotliwości 5,8 GHz w paśmie przeznaczonym do zastosowań 
przemysłowych, naukowych i medycznych (ISM); Część 1: 
Charakterystyka ogólna przyrządów instalowanych na poboczu 
(RSU) oraz przyrządów instalowanych w pojeździe (OBU) 
i metody kontrolowania tych przyrządów}.  
DSC_3  Łączność nawiązuje się za pośrednictwem urządzeń do łącz­
ności wyłącznie po otrzymaniu sygnału wyemitowanego przez 
urządzenia właściwego organu kontrolnego przy wykorzys­
taniu zgodnych środków łączności radiowej („ czytnik wczes ­
nego wykrywania na odleg łość” (REDCR) ). 
DSC_4  Dane  zabezpiecza się w celu zapewnienia ich integralności.  
DSC_5 Dostęp do przesyłanych  Danych  jest ograniczony do właści­
wych organów kontrolnych upoważnionych do kontroli naru­
szeń rozporządzenia (WE) nr 561/2006 i rozporządzenia (UE) 
nr 165/2014 oraz do warsztatów w zakresie niezbędnym do 
sprawdzenia poprawnego funkcjonowania tachografu.  
DSC_6  Dane  przesyłane w trakcie utrzymywania  Łączności ograni­
czają się do danych niezbędnych na potrzeby ukierunkowa­
nych kontroli drogowych pojazdów wyposażonych w tacho­
grafy, które mogły zostać niewłaściwie użyte lub stać się 
przedmiotem manipulacji.  
DSC_7 Integralność i bezpieczeństwo  Danych  zapewnia się, zabezpie­
czając  Dane  przechowywane w przyrządzie rejestrującym (VU) 
i przekazując wyłącznie zabezpieczone dane ładunku i dane 
dotyczące zabezpieczeń za pośrednictwem urządzeń bezprzewo­
dowej łączności na odległość DSRC działających na częstotli­
wości 5,8 GHz (zob. pkt 5.4.4), co oznacza, że tylko upoważ­
nieni pracownicy właściwych organów kontrolnych są w stanie 
zrozumieć dane przekazywane w trakcie utrzymywania  Łącz­
ności i są w stanie zweryfikować ich autentyczność. Zob. 
Dodatek 11 – Wspólne mechanizmy zabezpieczenia.  
DSC_8  Dane  muszą zawierać znacznik czasu określający datę 
i godzinę ich ostatniej aktualizacji.  
DSC_9 Treść danych zabezpieczających jest znana wyłącznie 
właściwym organom kontrolnym i tym stronom, którym 
organy udostępniają te informacje, oraz pozostaje pod ich 
kontrolą; treść takich danych wykracza poza zakres przepisów 
dotyczących  Łączności będących przedmiotem niniejszego 
dodatku z wyjątkiem zakresu, w jakim  Łączność zabezpiecza 
przesyłanie pakietu danych zabezpieczających z każdym 
pakietem danych ładunku.  
DSC_10 Należy zapewnić możliwość wykorzystania tej samej archit ek­
tury i tych samych urządzeń do uzyskania innych koncepcji 
danych (jak np. ważenie w pojeździe) z zastosowaniem archi­
tektury określonej w niniejszym dodatku.  
DSC_11 W tym miejscu należy wyjaśnić, że zgodnie z przepisami 
rozporządzenia (UE) nr 165/2014 (art. 7) dane dotyczące 
tożsamości kierowcy nie mogą być przekazywane w ramach  
Łączności. 
2 ZAKRES  
Celem niniejszego dodatku jest określenie, w jaki sposób przeds tawiciele 
właściwych organów kontrolnych mają korzystać z dedykowanego 
systemu łączności bezprzewodowej DSRC działającego w paśmie 5,8  
GHz, aby zdalnie pozyskiwać z pojazdu docelowego dane („ Dane ”) 
wskazujące, że taki pojazd może potencjalnie naruszać przepisy  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 537  
rozporządzenia (UE) nr 165/2014 i że w związku z tym należy roz ważyć 
możliwość jego zatrzymania do bardziej szczegółowej kontroli.  
Zgodnie z wymogiem ustanowionym w rozporządzeniu (UE) 
nr 165/2014 gromadzone  Dane  muszą ograniczać się do danych lub 
dotyczyć danych potwierdzających, że mogło dojść do naruszenia 
praw, zgodnie z definicją przedstawioną w art. 9 rozporządzenia  (UE) 
nr 165/2014.  
▼M1 
W takim przypadku czas dostępny na nawiązanie łączności jest og rani­
czony, ponieważ  łączność ma ukierunkowany charakter i cechuje się 
krótkim zasięgiem. Ponadto właściwe organy kontrolne mogą korzy stać 
ze środków łączności wykorzystywanych do celów zdalnego monitor o­
wania tachografu również do innych celów (np. do przekazywania infor­
macji dotyczących maksymalnych obciążeń i wymiarów pojazdów cię ża­
rowych określonych w dyrektywie (UE) 2015/719), przy czym dział ania 
w tym zakresie mogą być podejmowane oddzielnie lub sekwencyjnie  
według uznania właściwych organów kontrolnych.  
▼B 
W niniejszym dodatku określa się:  
— urządzenia do łączności oraz procedury i protokoły, które nal eży 
stosować do celów  Łączności; 
— normy i przepisy, z którymi urządzenia radiowe muszą być zgod ne; 
— sposób przekazywania  Danych  za pośrednictwem urządzeń do  Łącz­
ności; 
— procedury zapytywania i pobierania oraz sekwencję operacji;  
— Dane , które mają być przekazywane;  
— Możliwe interpretacje  Danych  przesyłanych w ramach  Łączności; 
— przepisy w zakresie danych zabezpieczających dotyczących  Łącz­
ności; 
— dostępność  Danych  dla właściwych organów kontrolnych;  
— sposób, w jaki  Czytnik wczesnego wykrywania na odleg łość m o ż e  
żądać przekazania różnych koncepcji danych dotyczących ładunku 
i floty.  
W tym miejscu należy wyjaśnić, że w niniejszym dodatku  nie określa 
się: 
— operacji gromadzenia  Danych  i zarządzania tym procesem w ramach 
VU (co stanowi funkcję projektu produktu, chyba że zostało okre ­ 
ślone w innym miejscu w rozporządzeniu (UE) nr 165/2014);  
— formy, w jakiej należy przedstawić zgromadzone dane przedstaw i­
cielowi właściwych organów kontrolnych ani kryteriów, z których  
właściwe organy kontrolne muszą korzystać przy podejmowaniu 
decyzji o ewentualnym zatrzymaniu pojazdu (co stanowi funkcję 
projektu produktu, chyba że zostało określone w innym miejscu 
w rozporządzeniu (UE) nr 165/2014 lub zależy od decyzji poli­
tycznej właściwych organów kontrolnych). W tym miejscu należy 
wyjaśnić, że za pośrednictwem  Łączności udostępnia się  Dane  
właściwym organom kontrolnym, wyłącznie aby zapewnić  im możli­
wość podejmowania świadomych decyzji;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 538  
— Przepisów w zakresie bezpieczeństwa danych (takich jak przepi sy 
w zakresie szyfrowania) dotyczących treści  Danych  (które zostaną 
określone w dodatku 11 – Wspólne mechanizmy zabezpieczenia);  
— szczegółowych informacji dotyczących wszelkich koncepcji dany ch 
innych niż RTM, które można pozyskać z zastosowaniem tej samej 
architektury i tych samych urządzeń;  
— szczegółowych informacji dotyczących zachowania i zarządzania  
pomiędzy VU i DSRC-VU ani dotyczących zachowania w ramach 
DSRC-VU (poza przekazywaniem  Danych  na żądanie REDCR).  
3 SKRÓTY, DEFINICJE I OZNACZENIA  
W niniejszym dodatku używa się następujących skrótów i definicj i 
właściwych dla tego dodatku:  
Antena  urządzenie elektryczne przekształca­
jące energię elektryczną w fale 
radiowe i  vice versa , wykorzysty­
wane w połączeniu z nadajnikiem 
radiowym lub odbiornikiem 
radiowym. W trakcie pracy nadajnik 
radiowy generuje drgania elek­
tryczne o częstotliwości fal radio­
wych, które trafiają do gniazd ante­
nowych, a antena emituje energię 
pozyskiwaną z prądu w formie fal 
elektromagnetycznych (fal radio­
wych). Przyjmując fale radiowe, 
antena przechwytuje część energii 
z fali elektromagnetycznej 
i wytwarza niewielkie napięcie 
w gniazdach antenowych, które jest 
następnie przesyłane do odbiornika 
w celu wzmocnienia;  
Łączność wymiana informacji/danych między  
DSRC-REDCR  a DSRC-VU zgodnie 
z przepisami sekcji 5 w trybie 
nadrzędny-podrzędny prowadzona 
w celu pozyskania  Danych ; 
Dane  zabezpieczone dane o określonym 
formacie (zob. pkt 5.4.4) żądane 
przez  DSRC–REDCR  i przekazane 
przez  DSR-VU  za pośrednictwem 
DSRC działającego na częstotli­
wości 5,8 GHz określonego w pkt 
5 poniżej;  
Rozporządzenie (WE) nr 165/2014  Rozporządzenie Parlamentu Euro­
pejskiego i Rady (UE) nr 165/2014 
z dnia 4 lutego 2014 r. w sprawie 
tachografów stosowanych w trans­
porcie drogowym i uchylające  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 539  
rozporządzenie  
Rady (EWG) nr 3821/85 w sprawie 
urządzeń rejestrujących stosowanych 
w transporcie drogowym oraz zmie­
niające rozporządzenie (WE) 
nr 561/2006 Parlamentu Europej­
skiego i Rady w sprawie harmoni­
zacji niektórych przepisów socjal­
nych odnoszących się do transportu 
drogowego;  
AID identyfikator aplikacji  
BLE  Bluetooth Low Energy (łączność 
Bluetooth przy znikomym poborze 
prądu)  
BST  tabela usług sygnału  
CIWD  włożenie karty podczas prowadzenia 
pojazdu  
CRC  cykliczna kontrola nadmiarowa  
DSC (n)  identyfikator wymogu związanego 
z określonym dodatkiem doty­
czącym DSRC  
DSRC  dedykowana łączność krótkiego 
zasięgu  
DSRC-REDCR  DSRC–czytnik wczesnego wykry­
wania na odległość  
DSRC-VU  DSRC–przyrząd rejestrujący. Jest to 
„urządzenie wczesnego wykrywania 
na odległość” zdefiniowana 
w załączniku 1C  
DWVC  prowadzenie pojazdu bez ważnej 
karty  
EID identyfikator elementu  
LLC  sterowanie połączeniem logicznym  
LPDU  jednostka danych protokołu LLC  
OWS  system ważenia zainstalowany 
w pojeździe  
PDU  jednostka danych protokołu  
REDCR  czytnik wczesnego wykrywania na 
odległość. Jest to „urządzenie 
służące jako czytnik wczesnego 
wykrywania na odległość” zdefinio­
wane w załączniku 1C  
RTM  zdalne monitorowanie tachografu  
SM-REDCR  moduł zabezpieczeń–czytnik wczes­
nego wykrywania na odległość  
TARV  aplikacje telematyczne dla pojazdów 
regulowanych (seria norm ISO 
15638)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 540  
VU przyrząd rejestrujący  
VUPM  pamięć ładunku przyrządu rejestru­
jącego  
VUSM  moduł zabezpieczeń przyrządu rejes­
trującego  
VST  tabela usług pojazdu  
WIM  ważenie w ruchu  
WOB  ważenie w pojeździe  
Specyfikacje określone w niniejszym dodatku odnoszą się do wszy stkich 
lub części wskazanych poniżej rozporządzeń i norm i są od nich zależne. 
W ramach zapisów niniejszego dodatku wskazano odnośne normy lub  
odnośne przepisy norm. W razie jakichkolwiek sprzeczności zapis y 
niniejszego dodatku są nadrzędne. W sytuacji wystąpienia jakich kolwiek 
sprzeczności, w przypadku których nie istnieją specyfikacje wyr aźnie 
określone w niniejszym dodatku, należy w pierwszej kolejności z asto­
sować procedury przewidziane w ERC 70-03 (i sprawdzić zgodność 
z odpowiednimi parametrami przewidzianymi w normie EN 300 674- 
1), a następnie procedury przewidziane kolejno w normach EN 127 95, 
EN 12253, EN 12834 i EN 13372 pkt 6.2, 6.3, 6.4 oraz 7.1.  
W niniejszym dodatku przywołano następujące rozporządzenia i no rmy:  
[1] rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 165/ 2014 
z dnia 4 lutego 2014 r. w sprawie tachografów stosowanych 
w transporcie drogowym i uchylające rozporządzenie Rady (EWG) 
nr 3821/85 w sprawie urządzeń rejestrujących stosowanych w tran s­
porcie drogowym oraz zmieniające rozporządzenie (WE) 
nr 561/2006 Parlamentu Europejskiego i Rady w sprawie harmo­
nizacji niektórych przepisów socjalnych odnoszących się do tran s­
portu drogowego;  
[2] rozporządzenie (WE) nr 561/2006 Parlamentu Europejskiego 
i Rady z dnia 15 marca 2006 r. w sprawie harmonizacji niektóryc h 
przepisów socjalnych odnoszących się do transportu drogowego 
oraz zmieniające rozporządzenia Rady (EWG) nr 3821/85 i (WE) 
nr 2135/98, jak również uchylające rozporządzenie Rady (EWG) 
nr 3820/85 (tekst mający znaczenie dla EOG);  
[3] dokument ERC 70-03 CEPT „Zalecenie ECC 70-03 dotyczące 
korzystania z urządzeń bliskiego zasięgu (SRD)”;  
[4] normę ISO 15638 Inteligentne systemy transportowe – Ramy 
wspólnych aplikacji telematycznych dla regulowanych komercyj­
nych samochodów ciężarowych (TARV);  
[5] normę EN 300 674-1 „Kwestie dotyczące kompatybilności elek­
tromagnetycznej i widma radiowego (ERM); telematyka transportu 
i ruchu drogowego (RTTT); dedykowana łączność krótkiego 
zasięgu (DSRC) utrzymywana za pośrednictwem urządzeń trans­
misyjnych (500 kbit/s / 250 kbit/s) działających na częstotliwo ści 
5,8 GHz w paśmie przeznaczonym do zastosowań przemysłowych, 
naukowych i medycznych (ISM); Część 1: Charakterystyka ogólna 
przyrządów instalowanych na poboczu (RSU) oraz przyrządów 
instalowanych w pojeździe (OBU) i metody kontrolowania tych 
przyrządów”;  
[6] normę EN 12253 „Telematyka transportu i ruchu drogowego – 
Wydzielona komunikacja krótkiego zasięgu – Warstwa fizyczna 
wykorzystująca częstotliwość 5,8 GHz”;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 541  
[7] normę EN 12795 „Telematyka transportu i ruchu drogowego – 
Wydzielona komunikacja krótkiego zasięgu (DSRC) – Warstwa 
łącza danych DSRC: sterowanie dostępem nośnika i łączem 
logicznym”;  
[8] normę EN 12834 „Telematyka transportu i ruchu drogowego – 
Wydzielona komunikacja krótkiego zasięgu (DSRC) – Warstwa 
aplikacyjna DSRC”;  
[9] normę EN 13372 „Telematyka transportu i ruchu drogo­
wego (RTTT) – Wydzielona komunikacja krótkiego zasięgu – 
Profile zastosowań RTTT”;  
[10] normę ISO 14906 „Elektroniczny system pobierania opłat – O kre­ 
ślenie interfejsu zastosowań dla wydzielonej komunikacji krótki ego 
zasięgu”.  
4 SCENARIUSZE OPERACYJNE  
4.1 Informacje ogólne  
W rozporządzeniu (UE) nr 165/2014 wskazano konkretne i kontrolo wane 
scenariusze określające sposób stosowania  Łączności. 
Do scenariuszy objętych wsparciem należą:  
„Profil łączności 1: Kontrole drogowe przeprowadzane przy wykorzys ­
taniu czytnika wczesnego wykrywania na odleg łość opartego na techno ­
logii łączności bezprzewodowej krótkiego zasi ęgu dające podstawy do 
wszczęcia fizycznej kontroli drogowej (relacja nadrz ędny-podrz ędny) 
Profil czytnika 1a: Kontrole przeprowadzane przy wykorzystaniu r ęcz­
nego urz ądzenia wczesnego wykrywania na odleg łość lub urządzenia 
wczesnego wykrywania na odleg łość zainstalowanego tymczasowo na 
poboczu  
Profil czytnika 1b: Kontrole przeprowadzane przy wykorzystaniu ukie ­
runkowanego czytnika wczesnego wykrywania na odleg łość zainstalowa ­
nego w poje ździe”.  
4.1.1  Warunki wst ępne dotycz ące przesy łania danych za po średnictwem inter ­
fejsu DSRC dzia łającego na cz ęstotliwości 5,8 GHz  
UWAGA: w celu zrozumienia kontekstu warunków wstępnych warto 
zapoznać się z rys. 14.3 poniżej.  
4.1.1.1 Dane przechowywane w VU  
DSC_12 Przyrząd rejestrujący odpowiada za aktualizowanie co 60 
sekund danych, które mają być przechowywane w VU, bez 
żadnego udziału funkcji łączności DSRC oraz za utrzymy­
wanie tych danych. Środki umożliwiające osiągnięcie tego 
celu znajdują się wewnątrz VU i są określone w sekcji 3.19 
„Łączność na odległość na potrzeby ukierunkowanych kontroli 
drogowych” załącznika 1C do rozporządzenia (UE) 
nr 165/2014, a nie w niniejszym dodatku.  
4.1.1.2 Dane przesyłane do funkcji DSRC-VU  
DSC_13 Przyrząd rejestrujący odpowiada za aktualizowanie danych  
gromadzonych przez tachograf DSRC ( Dane ) za każdym 
razem, gdy następuje aktualizacja danych przechowywanych 
w VU w odstępach czasu określonych w pkt 4.1.1.1 
(DSC_12), bez żadnego udziału funkcji łączności DSRC.  
DSC_14 Dane VU stosuje się jako podstawę do wypełniania i aktua li­
zowania  Danych , przy czym środki umożliwiające osiągnięcie 
tego celu określono w sekcji 3.19 „Łączność na odległość na 
potrzeby ukierunkowanych kontroli drogowych” załącznika 1C 
lub w przypadku braku takiego wyszczególnienia stanowią 
funkcję projektu produktu i nie są określone w niniejszym 
dodatku. Informacje na temat struktury połączenia między 
funkcją DSRC-VU a VU można znaleźć w sekcji 5.6.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 542  
4.1.1.3 Zawartość Danych  
DSC_15 Treść i format  Danych  powinny pozwalać na to, aby po ich 
odszyfrowaniu zachowały one odpowiednią strukturę i pozos­
tały dostępne w formie i formacie określonych w pkt 5.4.4 
niniejszego dodatku (struktury  Danych ). 
4.1.1.4 Przedstawienie Danych  
DSC_16  Dane , który były regularnie aktualizowane zgodnie z procedu­
rami przewidzianymi w pkt 4.1.1.1, zabezpiecza się przed ich 
przedstawieniem  DSRC-VU , a następnie przedstawia jako 
wartość koncepcji danych zabezpieczonych w celu ich tymcza­
sowego przechowania w  DSRC-VU  jako aktualną wersję  
Danych . Dane te przekazuje się z  VUSM  do funkcji DSRC  
VUPM . VUSM  i VUPM  to funkcje, które niekoniecznie 
muszą mieć postać fizyczną. Forma fizycznej konkretyzacji 
służącej wykonywaniu tych funkcji jest kwestią projektu 
produktu, chyba że została określona w innym miejscu 
w rozporządzeniu (UE) nr 165/2014.  
4.1.1.5 Dane zabezpieczające  
▼M3 
DSC_17 Dane zabezpieczające ( DSRCSecurityData) , obejmujące 
żądane przez  REDCR  dane niezbędne do zapewnienia mu 
możliwości odszyfrowania  Danych  przekazuje się zgodnie 
z przepisami dodatku 11 „Wspólne mechanizmy zabezpie­
czenia”, w celu ich tymczasowego przechowania w  DSRC- 
VU jako aktualną wersję  DSRCSecurityData , w formie okre­ 
ślonej w sekcji 5.4.4 niniejszego dodatku.  
▼B 
4.1.1.6 Dane VUPM dostępne do przekazywania za pośrednictwem in terfejsu 
DSRC  
DSC_18 Koncepcja danych, która musi być zawsze dostępna w ramac h 
funkcji DSRC VUPM do celów natychmiastowego przeka­
zania na żądanie  REDCR , została zdefiniowana w sekcji 5.4.4 
w odniesieniu do pełnej specyfikacji modułu ASN.1.  
Informacje ogólne na temat profilu łączności 1  
Profil ten obejmuje przypadek wykorzystania, w którym przedstaw iciel 
właściwego organu kontrolnego używa czytnika wczesnego wykrywan ia 
na odległość (bazującego na interfejsach DSRC działających na c zęstot­
liwości 5,8 GHz w ramach ERC 70-03 i sprawdzonego pod kątem 
zgodności z odpowiednimi parametrami przewidzianymi w normie EN  
300 674-1, jak opisano w sekcji 5) ( REDCR ) w celu zdalnego zidenty­
fikowania pojazdu, który może potencjalnie naruszać przepisy 
rozporządzenia (UE) nr 165/2014. Po zidentyfikowaniu pojazdu pr zed­
stawiciel właściwego organu kontrolnego przeprowadzający kontro lę 
podejmuje o ewentualnym zatrzymaniu pojazdu.  
4.1.2  Profil 1a: Kontrole przeprowadzane przy wykorzystaniu r ęcznego czyt ­
nika wczesnego wykrywania na odleg łość lub czytnika wczesnego wykry ­
wania na odleg łość zainstalowanego tymczasowo na poboczu  
W ramach tego przypadku wykorzystania przedstawiciel właściwego  
organu kontrolnego znajduje się na poboczu i nakierowuje ręczny  
REDCR , REDCR  ustawiony na statywie trójnożnym lub innego rodzaju 
przenośny  REDCR  w kierunku środka szyby przedniej wybranego 
pojazdu. Kontrolę przeprowadza się przy wykorzystaniu interfejs ów 
DSRC działających na częstotliwości 5,8 GHz w ramach ERC 70-03 
i sprawdza pod kątem zgodności z odpowiednimi parametrami przew i­
dzianymi w normie EN 300 674-1, jak opisano w sekcji 5. Zob. ry s. 
14.1 (przypadek wykorzystania 1).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 543  
Rysunek 14.1  
Kontrola drogowa przeprowadzana przy wykorzystaniu interfejsów DSRC 
działających na cz ęstotliwości 5,8 GHz
  
4.1.3  Profil 1b: Kontrole przeprowadzane przy wykorzystaniu ukierunkowa ­
nego czytnika wczesnego wykrywania na odleg łość (REDCR) zainstalo ­
wanego w poje ździe 
W przedmiotowym przypadku wykorzystania przedstawiciel właściwe go 
organu kontrolnego znajduje się w pojeździe będącym w ruchu i n akie­
rowuje ręczny, przenośny  REDCR  znajdujący się wewnątrz pojazdu 
w kierunku środka szyby przedniej wybranego pojazdu albo  REDCR  
jest zainstalowany w pojeździe lub na nim w taki sposób, by był  skie­
rowany w kierunku środka szyby przedniej wybranego pojazdu 
w momencie, gdy pojazd, w którym znajduje się czytnik wczesnego  
wykrywania na odległość, znajduje się w określonym położeniu 
względem wybranego pojazdu (na przykład bezpośrednio przed tym 
pojazdem w strumieniu ruchu). Kontrolę przeprowadza się przy wy ko­
rzystaniu interfejsów DSRC działających na częstotliwości 5,8 G Hz 
w ramach ERC 70-03 i sprawdza pod kątem zgodności z odpowiednim i 
parametrami przewidzianymi w normie EN 300 674-1, jak opisano 
w sekcji 5. Zob. rys. 14.2. (przypadek wykorzystania 2).  
Rysunek 14.2  
Kontrola przeprowadzana z pojazdu korzystaj ącego z interfejsów 
DSRC dzia łających na cz ęstotliwości 5,8 GHz
  
4.2 Bezpiecze ństwo/integralno ść 
Aby umożliwić weryfikację autentyczności i integralności danych  pobra­
nych w ramach łączności na odległość, zabezpieczone  Dane  są weryfi­
kowane i deszyfrowane zgodnie z dodatkiem 11 Wspólne mechanizmy  
zabezpieczenia.  
5 PROJEKT I PROTOKOŁY ŁĄCZNOŚCI NA ODLEGŁOŚĆ  
5.1 Projekt  
Projekt funkcji łączności na odległość w tachografie inteligent nym 
przedstawiono na rys. 14.3.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 544  
Rys. 14.3  
Projekt funkcji łączności na odleg łość
 
DSC_19 W VU zlokalizowane są następujące funkcje:  
— moduł zabezpieczeń ( VUSM ). Ta funkcja występująca 
w VU jest odpowiedzialna za zabezpieczanie  Danych  prze­
syłanych z  DSRC-VU  do przedstawiciela właściwych 
organów kontrolnych za pośrednictwem łączności na odle­
głość;  
— zabezpieczone dane są przechowywane w pamięci VUSM. 
W odstępach czasu określonych w pkt 4.1.1.1 (DSC_12) 
VU szyfruje i uzupełnia koncepcję RTMdata (która obej­
muje wartości koncepcji danych ładunku i danych zabez­
pieczających określone poniżej w tym dodatku) przecho­
wywaną w pamięci DSRC-VU. Działanie modułu zabez­
pieczeń jest zdefiniowane w dodatku 11 „Wspólne mecha­
nizmy zabezpieczenia” i wykracza poza zakres niniejszego 
dodatku, z zastrzeżeniem konieczności zapewnienia aktua­
lizacji urządzenia do łączności VU za każdym razem, gdy 
zmieniają się dane VUSM;  
— łączność między VU a DSRC-VU może być łącznością 
przewodową lub łącznością opartą na technologii 
Bluetooth Low Energy (BLE), a jeżeli chodzi o fizyczną 
lokalizację DSRC-VU, może być ono zintegrowane 
z anteną umieszczoną na szybie przedniej pojazdu, może 
znajdować się wewnątrz VU lub może być umieszczone 
gdzieś pomiędzy;  
— DSRC-VU posiada niezawodne źródło energii dostępne 
w każdej chwili. Sposób zasilania energią zależy od 
projektu;  
— pamięć DSRC-VU jest pamięcią trwałą w celu utrzymania 
danych w DSRC-VU, nawet gdy zapłon pojazdu jest wyłą­
czony;  
— jeżeli łączność między VU a DSRC-VU odbywa się za 
pośrednictwem technologii BLE, a źródłem zasilania jest 
akumulator, którego nie można ponownie naładować, 
źródło zasilania DSRC-VU zastępuje się podczas każdego 
przeglądu okresowego, a producent urządzenia DSRC-VU  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 545  
jest odpowiedzialny za zapewnienie odpowiedniego zasi­
lania energią między jednym przeglądem okresowym 
a drugim, utrzymując normalny dostęp do danych przez 
REDCR przez cały okres bez awarii lub przerwania 
dostaw;  
— funkcja VU umożliwiająca zdalne monitorowanie tacho­
grafu i wyposażona w „pamięć na temat ładunków” 
(VUPM ). Ta funkcja występująca w VU jest odpowie­
dzialna za dostarczanie i aktualizację  Danych . Treść  
Danych  („TachographPayload”) jest zdefiniowana w pkt 
5.4.4/5.4.5 poniżej i jest aktualizowana w odstępach 
czasu określonych w pkt 4.1.1.1 (DSC_12);  
— DSRC-VU. Jest to funkcja w obrębie anteny lub połączona 
z anteną i nawiązująca łączność z VU za pośrednictwem 
połączenia przewodowego lub bezprzewodowego (BLE), 
które posiada aktualne dane ( dane VUPM)  i zarządza 
odpowiedziami na kontrolę prowadzoną przez nośnik 
DSRC działający na częstotliwości 5,8 GHz. Odłączenie 
urządzenia DSRC lub zakłócenie jego funkcjonowania 
podczas normalnej eksploatacji pojazdu z działającym 
urządzeniem DSRC interpretuje się jako naruszenie prze­
pisów rozporządzenia (UE) nr 165/2014;  
— moduł zabezpieczeń (REDCR) ( SM-REDCR ) to funkcja 
wykorzystywana do deszyfrowania i sprawdzania integral­
ności danych pochodzących z VU. Środki umożliwiające 
osiągnięcie tego celu określono w dodatku 11 Wspólne 
mechanizmy zabezpieczenia, a nie w niniejszym dodatku;  
— urządzenie DSRC (REDCR) ( DSRC-REDCR ) obejmuje 
nadajnik-odbiornik działający na częstotliwości 5,8 GHz 
i powiązane oprogramowanie wbudowane i oprogramo­
wanie zwykłe, które zarządza  Łącznością z DSRC-VU  
zgodnie z niniejszym dodatkiem;  
— DSRC-REDCR  wysyła zapytania do  DSRC-VU  w doce­
lowym pojeździe i pozyskuje  Dane  (bieżące  dane VUPM  
docelowego pojazdu) za pośrednictwem łącza DSRC oraz 
przetwarza i przechowuje otrzymane dane w swoim  SM- 
REDCR ; 
▼M1 
— antenę DSRC-VU umieszcza się w miejscu, w którym 
zapewnia optymalną łączność DSRC między pojazdem 
a anteną drogową czytnika, w przypadku gdy czytnik 
został zainstalowany w odległości 15 m z przodu pojazdu 
i na wysokości 2 m, możliwie blisko środkowej części 
szyby w poziomie i w pionie. W przypadku pojazdów 
lekkich odpowiednie jest zainstalowanie anteny w górnej 
części szyby przedniej W przypadku pozostałych pojazdów 
antenę DSRC należy zamontować w pobliżu dolnej albo 
górnej części szyby przedniej.  
▼B 
DSC_20 Antena i Łączność działają w ramach ERC 70-03, są spraw­
dzane pod kątem zgodności z odpowiednimi parametrami 
przewidzianymi w normie EN 300 674-1, jak opisano w sekcji 
5. W odniesieniu do anteny i Łączności można wdrożyć tech­
niki ograniczania ryzyka wystąpienia zakłóceń bezprzewodo­
wych, jak opisano w sprawozdaniu ECC nr 228, przy użyciu 
np. filtrów w łączności CEN DSRC 5.8 GHz.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 546  
DSC_21 Antena DSRC jest połączona z funkcją DSRC-VU bezpo­ 
średnio w obrębie modułu zamontowanego na szybie przedniej 
lub blisko szyby przedniej lub poprzez dedykowany przewód 
zbudowany w taki sposób, aby utrudnić nielegalne odłączenie. 
Odłączenie lub zakłócenie funkcjonowania anteny stanowi 
naruszenie przepisów rozporządzenia (UE) nr 165/2014. 
Zamierzone maskowanie lub inne szkodliwe oddziaływanie 
na funkcjonowanie anteny interpretuje się jako naruszenie 
przepisów rozporządzenia (UE) nr 165/2014.  
DSC_22  ►M1 Współczynnik kształtu anteny nie został zdefiniowany 
i stanowi przedmiot decyzji handlowej, dopóki wbudowany 
DSRC-VU spełnia wymagania zgodności określone w sekcji 
5 poniżej. Antena jest umieszczona w miejscu określonym 
w DSC_19 i skutecznie wspomaga przypadki wykorzystania 
opisane w pkt 4.1.2 i 4.1.3. ◄  
Rys. 14.4  
Przykładowe umieszczenie anteny DSRC dzia łającej na 
częstotliwości 5,8 GHz na szybie przedniej pojazdów regulowanych
  
Współczynnik kształtu  REDCR  i jego anteny może różnić się w zależ­
ności od położenia czytnika (zamontowany statyw, urządzenie ręc zne, 
zamontowany w pojeździe itd.) i trybu działania przyjętego prze z przed­
stawiciela właściwych organów kontrolnych.  
Funkcję wyświetlania lub powiadamiania wykorzystuje się do prze dsta­
wienia przedstawicielowi właściwych organów kontrolnych wyników  
funkcji łączności na odległość. Wyniki mogą być wyświetlane na 
ekranie, w formie wydruku, sygnału audio lub połączenia takich powia­
domień. Forma takiego wyświetlenia lub powiadomienia jest kwest ią 
wymogów przedstawicieli właściwych organów kontrolnych i projek tu 
urządzenia i nie jest określona w niniejszym dodatku.  
DSC_23 Współczynnik projektu i kształtu  REDCR  stanowi funkcję 
projektu komercyjnego, funkcjonującego w ramach ERC 70- 
03, oraz specyfikacji projektu i eksploatacji określonej 
w niniejszym dodatku (sekcja 5.3.2), tym samym zapewniając 
maksymalną elastyczność rynku w zakresie zaprojektowania 
i zapewnienia urządzenia mającego na celu zrealizowanie  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 547  
określonych scenariuszy kontroli dowolnego właściwego 
organu kontrolnego.  
DSC_24 Współczynnik projektu i kształtu  DSRC-VU  i jego pozycjono­
wanie wewnątrz lub na zewnątrz VU stanowią funkcję 
projektu komercyjnego, funkcjonującego w ramach ERC 70- 
03, oraz specyfikacji projektu i eksploatacji określonej 
w niniejszym dodatku (sekcja 5.3.2) i w obrębie tej klauzuli 
(5.1).  
DSC_25 W rozsądnym stopniu  DSRC-VU  musi być jednak w stanie 
zaakceptować wartości koncepcji danych z innego inteligen­
tnego urządzenia rejestrującego za pomocą otwartego standar­
dowego połączenia branżowego i protokołów (na przykład 
z urządzenia służącego do ważenia w pojeździe), dopóki 
takie koncepcje danych są określone unikatowymi i znanymi 
identyfikatorami aplikacji / nazwami plików, zaś instrukcje 
obsługi takich protokołów są udostępniane Komisji Europej­
skiej i są dostępne bezpłatnie dla producentów odpowiednich 
urządzeń.  
5.2 Przep ływ pracy  
5.2.1  Operacje  
Na rys. 14.5 przedstawiono przepływ pracy w odniesieniu do oper acji. 
Rys. 14.5  
Przepływ pracy w odniesieniu do funkcji łączności na odleg łość
 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 548  
Poszczególne kroki opisano poniżej:  
a. ilekroć pojazd jest w ruchu (włączony zapłon), tachograf prz ekazuje 
dane funkcji VU. Funkcja VU przygotowuje  Dane  na potrzeby 
funkcji łączności na odległość (zaszyfrowane) i aktualizuje  VUPM  
przechowywane w pamięci  DSRC-VU  (jak określono w pkt 
4.1.1.1–4.1.1.2). Zebrane  Dane  formatuje się w sposób określony 
w pkt 5.4.4–5.4.5 poniżej;  
b. przy każdej aktualizacji  Danych  aktualizuje się znacznik czasu okre­ 
ślony w koncepcji danych zabezpieczających;  
c. funkcja  VUSM  zabezpiecza dane zgodnie z procedurami określonymi 
w dodatku 11;  
d. przy każdej aktualizacji  Danych  (zob. pkt 4.1.1.1–4.1.1.2)  Dane  
przesyła się do DSRC-VU, gdzie zastępują one wszystkie poprzedn ie 
dane, aby w razie kontroli prowadzonej przez  REDCR  zawsze były 
dostępne zaktualizowane bieżące dane ( Dane ). W przypadku dostar­
czania  Danych  DSRC-VU przez VU  Dane  są identyfikowane po 
nazwie pliku  RTMData  lub ApplicationID i identyfikatorach 
atrybutu;  
e. jeżeli przedstawiciel właściwych organów kontrolnych chce zg roma­
dzić Dane  z wybranego pojazdu docelowego, najpierw umieszcza 
swoją kartę elektroniczną w  REDCR  w celu umożliwienia  Łączności 
i pozwolenia  SM-REDCR  na weryfikację autentyczności karty 
i deszyfrowanie danych;  
f. przedstawiciel właściwego organu kontrolnego wybiera następn ie 
pojazd i żąda przekazania danych za pośrednictwem łączności na 
odległość.  REDCR  otwiera sesję interfejsu DSRC działającego na 
częstotliwości 5,8 GHz z  DSRC-VU  pojazdu docelowego i żąda 
przekazania  Danych . Dane  są przesyłane do  REDCR  za pośrednic­
twem systemu łączności bezprzewodowej jako atrybut DSRC korzys­
tający z usługi aplikacyjnej GET, jak określono w 5.4. Atrybut 
zawiera zaszyfrowane wartości danych ładunku oraz dane zabezpie ­
czające DSCR;  
g. dane są analizowane przez urządzenie  REDCR  i przekazywane 
przedstawicielowi właściwego organu kontrolnego;  
h. przedstawiciel właściwego organu kontrolnego wykorzystuje da ne do 
podjęcia decyzji o ewentualnym zatrzymaniu pojazdu do szczegó­ 
łowej kontroli lub zwrócenia się do innego przedstawiciela właś ci­
wego organu kontrolnego o zatrzymanie pojazdu.  
5.2.2  Interpretacja danych otrzymanych za po średnictwem łączności DSRC  
DSC_26 Dane otrzymywane przez interfejs działający na częstotli wości 
5,8 GHz niosą tylko i wyłącznie znaczenie i import zdefinio­
wane w pkt 5.4.4 i 5.4.5 poniżej i są rozumiane zgodnie 
z celami określonymi w tych punktach. Zgodnie z przepisami 
rozporządzenia (UE) nr 165/2014  Dane  wykorzystuje się 
jedynie w celu przekazania odpowiednich informacji właści­
wemu organowi kontrolnemu, aby pomóc mu w ustaleniu,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 549  
czy należy zatrzymać pojazd do kontroli fizycznej, a następnie  
Dane  te są niszczone zgodnie z art. 9 rozporządzenia (UE) 
nr 165/2014.  
5.3 Parametry interfejsu fizycznego DSRC w odniesieniu do łączności na 
odległość 
5.3.1  Ograniczenia dotycz ące lokalizacji  
DSC_27 Zdalnej kontroli pojazdów korzystających z interfejsu DS RC 
działającego na częstotliwości 5,8 GHz nie należy prowadzić 
w odległości do 200 metrów od uruchomionej suwnicy 
bramowej DSRC działającej na częstotliwości 5,8 GHz.  
5.3.2  Parametry łącza odbiorczego (downlink) i łącza nadawczego (uplink)  
DSC_28 Urządzenia wykorzystywane do zdalnego monitorowania 
tachografu muszą być zgodne z ERC70-03 i parametrami 
określonymi w tabelach 14.1 i 14.2 poniżej oraz muszą 
działać w ramach ERC70-03 i tych parametrów.  
DSC_29 Ponadto aby zapewnić zgodność z parametrami operacyjnymi  
innych standardowych systemów DSRC działających na częs­
totliwości 5,8 GHz, urządzenie wykorzystywane do zdalnego 
monitorowania tachografu musi być zgodne z parametrami 
określonymi w normach EN 12253 i EN 13372.  
Mianowicie:  
Tabela 14.1  
Parametry łącza odbiorczego  
Nr pozycji  Parametr  Wartości  Uwagi  
D1 Częstotliwości nośne łącza 
odbiorczego  Istnieją cztery alternatywne 
częstotliwości, których 
może używać REDCR: 
5,7975 GHz 
5,8025 GHz 
5,8075 GHz 
5,8125 GHz  W ramach ERC 70-03. 
Częstotliwości nośne mogą zostać 
wybrane przez podmiot wdrażający 
system przydrożny i nie muszą być 
znane w DSRC-VU. 
(zgodnie z normami EN 12253 
i EN 13372)  
D1a (*) Tolerancja częstotliwości 
nośnych  w ramach ± 5 ppm  (zgodnie z normą EN 12253)  
D2 (*) Maska zakresu nadajnika 
RSU (REDCR)  W ramach ERC 70-03. 
REDCR jest zgodny z klasą 
B,C, jak określono w normie 
12253. 
Brak innych szczególnych 
wymogów określonych 
w tym załączniku  Parametr stosowany do kontrolo­
wania zakłóceń pomiędzy interro­
gatorami znajdującymi się blisko 
siebie (jak określono w normach 
EN 12253 i EN 13372).  
D3 OBU(DSRC-VU) Mini­
malny zakres częstotliwości  5,795–5,815 GHz  (zgodnie z normą EN 12253)  
D4 (*) Maksymalna EIRP  W ramach ERC 70-03 
(nielicencjonowanego) 
i rozporządzenia krajowego 
Maksymalna wartość + 33 
dBm  (zgodnie z normą EN 12253)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 550  
Nr pozycji  Parametr  Wartości  Uwagi  
D4a Maska kątowa EIRP  Zgodnie z zadeklarowaną 
i opublikowaną specyfi­
kacją projektanta interroga­
tora (zgodnie z normą EN 12253)  
D5 Polaryzacja  Lewostronna kołowa  (zgodnie z normą EN 12253)  
D5a Polaryzacja krzyżowa  XPD: 
Na obszarze pokrycia: 
(REDCR) RSU t ≥ 15 dB 
(DSRC-VU) OBU r ≥ 10 dB 
Na obszarze -3 dB: 
(REDCR) RSU t ≥ 10 dB 
(DSRC-VU) OBU r ≥ 6 dB  (zgodnie z normą EN 12253)  
D6 (*) Modulacja  Dwupoziomowa modulacja 
amplitudy  (zgodnie z normą EN 12253)  
D6a (*) Indeks modulacji  0,5 … 0,9  (zgodnie z normą EN 12253)  
D6b Wzorzec ruchu gałek 
ocznych  ≥90 % (czas) / ≥85 % 
(amplituda)  
D7 (*) Kodowanie danych  FM0 
Bit „1” posiada przejścia 
jedynie na początku 
i końcu interwału bitowego. 
Bit „0” posiada dodatkowe 
przejście w środku inter­
wału bitowego w porów­
naniu z bitem „1”.  (zgodnie z normą EN 12253)  
D8 (*) Szybkość transmisji bitów  500 kBit/s  (zgodnie z normą EN 12253)  
D8a Tolerancja zegara częstotli­
wości  wyższa niż ± 100 ppm  (zgodnie z normą EN 12253)  
D9 (*) Bitowa stopa błędów (BER) 
w odniesieniu do łączności  ≤ 10  – 6 , gdy moc padająca 
w przyrządzie instalo­
wanym w pojeździe 
(DSRC-VU) mieści się 
w zakresie podanym w pkt 
[D11a–D11b].  (zgodnie z normą EN 12253)  
D10 Czynnik uruchamiający 
OBU (DSRC-VU)  OBU (DSRC-VU) 
uruchamia się po otrzy­
maniu dowolnej ramki 
zawierającej co najmniej 
11 oktetów (w tym pream­
bułę)  Nie jest konieczny żaden specjalny 
wzór uruchamiania. 
DSRC-VU może uruchomić się po 
otrzymaniu ramki zawierającej 
mniej niż 11 oktetów 
(zgodnie z normą EN 12253)  
D10a  Maksymalna godzina rozpo­
częcia  ≤5 ms  (zgodnie z normą EN 12253)  
D11 Strefa łączności  Region przestrzenny, 
w którym osiąga się BER 
zgodną z D9a  (zgodnie z normą EN 12253)  
D11a  (*) Limit zasilania w odnie­
sieniu do łączności (górna)  – 24 dBm  (zgodnie z normą EN 12253)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 551  
Nr pozycji  Parametr  Wartości  Uwagi  
D11b  (*) Limit zasilania w odnie­
sieniu do łączności (dolna)  Moc zdarzenia: 
– 43 dBm (obszar pokrycia) 
– 41 dBm (w przedziale 
– 45° ± 45° odpowiada­
jącym płaszczyźnie równo­
ległej do powierzchni drogi, 
gdy DSRC-VU jest później 
instalowany w pojeździe 
(azymut))  (zgodnie z normą EN 12253) 
Rozszerzony wymóg w odniesieniu 
do kątów poziomych do ±45°, ze 
względu na przypadki wykorzys­
tania zdefiniowane w niniejszym 
załączniku.  
D12 (*) Poziom odcięcia zasilania 
(DSRC-VU)  – 60 dBm  (zgodnie z normą EN 12253)  
D13 Preambuła  Preambuła jest obowiąz­
kowa.  (zgodnie z normą EN 12253)  
D13a  Długość i wzór preambuły  16 bitów ± 1 bit FM0 zako­
dowany jako bity „1”  (zgodnie z normą EN 12253)  
D13b  Kształt fali preambuły  Sekwencja naprzemienna 
o niskim i wysokim 
poziomie z czasem trwania 
impulsu równym 2 μs. 
Tolerancja podana w D8a  (zgodnie z normą EN 12253)  
D13c  Bity pomocnicze  RSU (REDCR) może prze­
słać maksymalnie 8 bitów 
po fladze końcowej. Od 
OBU (DSRC-VU) nie 
wymaga się, aby uwzględ­
niał te dodatkowe bity.  (zgodnie z normą EN 12253)  
(*) – Parametry łącza odbiorczego z zastrzeżeniem sprawdzenia p od kątem zgodności z odpowiednim testem parametrów przewi­ 
dzianym w normie EN 300 674-1.  
Tabela 14.2  
Parametry łącza nadawczego  
Nr pozycji  Parametr  Wartości  Uwagi  
U1 (*) Częstotliwości podnośne  OBU (DSRC-VU) obsłu­
guje częstotliwości 1,5 
MHz i 2,0 MHz 
RSU (REDCR) obsługuje 
częstotliwość 1,5 MHz lub 
2,0 MHz lub obie. U1-0: 
1,5 MHz U1-1: 2,0 MHz  Wybór częstotliwości podnośnej 
(1,5 MHz lub 2,0 MHz) zależy od 
wybranego profilu określonego 
w normie EN 13372.  
U1a (*) Tolerancja częstotliwości 
podnośnych  w ramach ± 0,1 %  (zgodnie z normą EN 12253)  
U1b Wykorzystanie wstęg bocz­
nych  Takie same dane po obu 
stronach  (zgodnie z normą EN 12253)  
U2 (*) Maska zakresu nadajnika 
OBU (DSRC-VU)  Zgodnie z EN 12253 
1) Moc poza pasmem 
zob. ETSI EN 300674-1  (zgodnie z normą EN 12253)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 552  
Nr pozycji  Parametr  Wartości  Uwagi  
2) Moc na paśmie: 
[U4a] dBm w 500 kHz 
3) Emisja na dowolnym 
innym kanale łącza 
nadawczego: 
U2(3)-1 = -35 dBm w 
500 kHz  
U4a (*) Maksymalna modulacja 
jednowstęgowa EIRP 
(obszar pokrycia)  Dwie opcje: 
U4a-0: – 14 dBm 
U4a-1: – 21 dBm  Zgodnie z zadeklarowaną i opubli­
kowaną specyfikacją projektanta 
urządzenia  
U4b (*) Maksymalna modulacja 
jednowstęgowa EIRP (35°)  Dwie opcje: 
— Nie dotyczy 
— – 17 dBm  Zgodnie z zadeklarowaną i opubli­
kowaną specyfikacją projektanta 
urządzenia  
U5 Polaryzacja  Lewostronna kołowa  (zgodnie z normą EN 12253)  
U5a Polaryzacja krzyżowa  XPD: 
Na obszarze pokrycia: 
(REDCR) RSU r ≥ 15 dB 
(DSRC-VU) OBU t ≥ 10 dB 
Na obszarze – 3 dB: 
(REDCR) RSU r ≥ 10 dB 
(DSRC-VU) OBU t ≥ 6 dB  (zgodnie z normą EN 12253)  
U6 Modulacja podnośna  2-PSK 
Zakodowane dane zsyn­
chronizowane z częstotliwo­ 
ścią podnośną: przejścia 
zakodowanych danych 
zbieżne z przejściami częs­
totliwości podnośnej.  (zgodnie z normą EN 12253)  
U6b Cykl roboczy  Cykl roboczy: 
50 % ± α, α ≤5 %  (zgodnie z normą EN 12253)  
U6c Modulacja na nośniku  Mnożenie modulowanej 
częstotliwości podnośnej 
przez częstotliwość nośną.  (zgodnie z normą EN 12253)  
U7 (*) Kodowanie danych  NRZI (Brak przejścia na 
początku bitu „1”, przejście 
na początku bitu „0”, brak 
przejścia w ramach bitu)  (zgodnie z normą EN 12253)  
U8 (*) Szybkość transmisji bitów  250 kBit/s  (zgodnie z normą EN 12253)  
U8a Tolerancja zegara częstotli­
wości  w ramach ± 1 000 ppm  (zgodnie z normą EN 12253)  
U9 Bitowa stopa błędów 
(B.E.R.) w odniesieniu do 
łączności  ≤10  – 6 (zgodnie z normą EN 12253)  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 553  
Nr pozycji  Parametr  Wartości  Uwagi  
U11 Strefa łączności  Region przestrzenny, 
w którym zlokalizowany 
jest DSRC-VU, tak że jego 
transmisje są odbierane 
przez REDCR przy BER 
mniejszej niż ta podana 
w pkt U9a.  (zgodnie z normą EN 12253)  
U12a  (*) Zysk z konwersji (dolna 
granica)  1 dB dla każdej wstęgi 
bocznej Zakres kątowy: 
kołowo-symetryczny 
pomiędzy obszarem 
pokrycia a ± 35° 
oraz 
w przedziale – 45° ± 45° 
odpowiadającym płasz­
czyźnie równoległej do 
powierzchni drogi, gdy 
DSRC-VU jest później 
instalowany w pojeździe 
(azymut)  Większy niż określony zakres 
wartości dla kątów poziomych do 
± 45° ze względu na przypadki 
wykorzystania zdefiniowane 
w niniejszym załączniku.  
U12b  (*) Zysk z konwersji (górna 
granica)  10 dB dla każdej wstęgi 
bocznej  Niższy niż określony zakres 
wartości dla każdej wstęgi bocznej 
w obrębie stożka kołowego wokół 
obszaru pokrycia ± 45° kąta 
otwarcia.  
U13 Preambuła  Preambuła jest obowiąz­
kowa.  (zgodnie z normą EN 12253)  
U13a  Długość i wzór 
preambuły  32–36 μs modulowane 
jedynie przy użyciu częstot­
liwości podnośnej, 
a następnie 8 bitów „0” 
zakodowanych jako NRZI.  (zgodnie z normą EN 12253)  
U13b  Bity pomocnicze  DSRC-VU może przesłać 
maksymalnie 8 bitów po 
fladze końcowej. Od 
RSU (REDCR) nie wymaga 
się, aby uwzględniał te 
dodatkowe bity.  (zgodnie z normą EN 12253)  
(*) – Parametry łącza nadawczego z zastrzeżeniem sprawdzenia zg odności z odpowiednim testem parametrów przewidzianym w normie 
EN 300 674-1.  
5.3.3  Projekt anteny  
5.3.3.1 Antena REDCR  
DSC_30 Projekt anteny  REDCR  stanowi funkcję projektu komercyj­
nego, funkcjonującego w granicach określonych w pkt 5.3.2, 
który dostosowano, aby zoptymalizować wydajność odczytu  
DSRC-REDCR  w określonym celu oraz aby odczytać okolicz­
ności, w których w założeniu  REDCR  ma funkcjonować.  
5.3.3.2 Antena VU  
DSC_31 Projekt anteny  DSRC-VU  stanowi funkcję projektu komercyj­
nego, funkcjonującego w granicach określonych w pkt 5.3.2, 
które dostosowano, aby zoptymalizować wydajność odczytu  
DSRC-REDCR  w określonym celu oraz aby odczytać okolicz­
ności, w których w założeniu  REDCR  ma funkcjonować.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 554  
DSC_32 Antena VU jest zamontowana na szybie przedniej pojazdu l ub 
blisko szyby przedniej, jak określono w pkt 5.1 powyżej.  
DSC_33 W środowisku testowym w warsztacie (zob. sekcja 6.3) 
antena DSRC-VU, umieszczona zgodnie z pkt 5.1 powyżej, 
powinna skutecznie połączyć się za pomocą standardowej 
łączności testowej i skutecznie zapewnić transakcję RTM, 
jak określono w tym dodatku, na odległość od 2 do 10 m, 
z wynikiem lepszym niż 99 % przypadków, uśrednionym do 
1 000 kontroli odczytów.  
5.4 Wymogi protoko łu DSRC w odniesieniu do zdalnego monitorowania 
tachografu  
5.4.1  Informacje ogólne  
DSC_34 Protokół transakcji służący do pobierania  Danych  za pomocą 
połączenia interfejsu DSRC działającego na częstotliwości 5,8 
GHz przebiega zgodnie z następującymi krokami. W niniejszej 
sekcji opisuje się przepływ transakcji w warunkach idealnych, 
bez retransmisji czy zakłóceń łączności.  
UWAGA: celem etapu inicjacji (krok 1) jest ustanowienie 
łączności między  REDCR  a DSRC-VU, które znalazły się 
w strefie transakcji DSRC w częstotliwości 5,8 GHz (tryb 
nadrzędny-podrzędny), ale jeszcze nie nawiązały łączności 
z REDCR , a także zgłoszenie procesów aplikacji.  
— Krok 1  Inicjacja.  REDCR  wysyła ramkę zawierającą 
tabelę usług sygnału (BST), która zawiera identyfikatory 
aplikacji (AID) w wykazie obsługiwanych usług. W apli­
kacji RTM będzie to po prostu usługa z wartością AID = 
2 (Freight&Fleet).  DSRC-VU  dokonuje oceny otrzymanej 
BST i odpowiada (zob. poniżej), przekazując wykaz 
obsługiwanych aplikacji w ramach domeny 
Freight&Fleet, lub nie odpowiada, jeżeli żadne aplikacje 
nie są obsługiwane. Jeżeli  REDCR  nie oferuje AID=2, 
DSRC-VU nie odpowiada  REDCR . 
— Krok 2  DSRC-VU  wysyła ramkę zawierającą żądane 
przydzielenia okna prywatnego.  
— Krok 3  REDCR  wysyła ramkę z przydziałem okna 
prywatnego.  
— Krok 4  DSRC-VU  używa przydzielonego okna prywat­
nego do wysłania ramki zawierającej jego tabelę usług 
pojazdu (VST). Tego rodzaju VST zawiera wykaz 
wszystkich różnych wystąpień aplikacji obsługiwanych 
przez ten  DSRC-VU  w ramach AID=2. Poszczególne 
wystąpienia są identyfikowane za pomocą jednorazowo 
generowanych identyfikatorów elementu, z których 
każdy jest powiązany z wartością parametru znacznika 
kontekstowego aplikacji określającą obsługiwaną apli­
kację i normę.  
— Krok 5  Następnie  REDCR  analizuje oferowaną tabelę 
usług pojazdu i albo przerywa łączność (RELEASE), 
ponieważ nie jest zainteresowany niczym, co dana VST 
ma do zaoferowania (tj. otrzymuje VST od  DSRC-VU , 
który nie obsługuje transakcji RTM), albo – jeżeli otrzy­
muje odpowiednią tabelę usług pojazdu – uruchamia 
wystąpienie aplikacji.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 555  
— Krok 6  Aby osiągnąć ten cel, REDCR wysyła ramkę 
zawierającą polecenie pobrania danych dotyczących zdal­
nego monitorowania tachografu i identyfikującą wystą­
pienie aplikacji RTM poprzez wskazanie identyfikatora 
odpowiadającego wystąpieniu aplikacji RTM (jak określił 
DSRC-VU w VST) oraz przydziela okno prywatne.  
— Krok 7  DSRC-VU  używa nowo przydzielonego okna 
prywatnego do wysłania ramki zawierającej adresowany 
identyfikator odpowiadający wystąpieniu aplikacji RTM 
zgodnie z VST, po którym następuje atrybut  RtmData  
(element ładunku + element bezpieczeństwa).  
— Krok 8  W przypadku żądania wielu usług wartość „n” 
zmienia się na kolejny numer referencyjny usługi i proce­
dura zostaje powtórzona.  
— Krok 9  REDCR  potwierdza otrzymanie danych, wysy­ 
łając do  DSRC-VU  ramkę zawierającą polecenie 
RELEASE w celu przerwania sesji LUB, jeżeli nie 
zatwierdził pomyślnego otrzymania LPDU, wraca do 
kroku 6.  
Zob. rys. 14.6 przedstawiający graficzny opis protokołu 
transakcji.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 556  
Rys. 14.6  
Zdalne monitorowanie tachografu w ramach przep ływu procesów DSRC na cz ęstotliwości 5,8 GHz
  
5.4.2  Polecenia  
DSC_35 Poniższe polecenia stanowią jedyne funkcje stosowane na 
etapie transakcji RTM:  
— INITIALISATION.request : polecenie wysyłane 
z REDCR w formie emisji z definicją aplikacji obsługi­
wanych przez ten REDCR;  
— INITIALISATION.response : odpowiedź z DSRC-VU 
potwierdzająca połączenie i zawierająca wykaz obsługi­
wanych wystąpień aplikacji wraz z charakterystyką oraz 
informacjami na temat sposobu postępowania z nimi (EID);  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 557  
— GET.request : polecenie wysyłane z  REDCR  d o DSRC- 
VU, określające wystąpienie aplikacji, którym należy się 
zająć, za pomocą zdefiniowanego EID otrzymanego 
w VST, oraz nakazujące  DSRC-VU  wysłanie wybra­
nego(-ych) atrybutu(-ów) z  Danymi . Celem polecenia 
GET jest umożliwienie  REDCR  otrzymania  Danych  o d 
DSRC-VU ; 
— GET.response : odpowiedź z DSRC-VU zawierająca 
żądane  Dane ; 
— ACTION.request ECHO : polecenie nakazujące  DSRC- 
VU odesłanie danych z  DSRC-VU  d o REDCR . Celem 
polecenia ECHO jest umożliwienie warsztatom lub 
placówkom przeprowadzających testy na potrzeby homo­
logacji typu zbadania, czy połączenie DSRC działa bez 
konieczności dostępu do poświadczeń zabezpieczenia;  
— ACTION .response ECHO: odpowiedź z DSRC-VU na 
polecenie ECHO;  
— EVENT_REPORT.request  RELEASE: polecenie infor­
mujące  DSRC-VU  o zakończeniu transakcji. Celem pole­
cenia RESEALSE jest zakończenie sesji z  DSRC-VU . Po 
otrzymaniu polecenia RELEASE  DSRC-VU  nie odpo­
wiada na żadne dalsze zapytania w ramach bieżącego 
połączenia. Należy zauważyć, że zgodnie z wymogami 
normy EN 12834 DSRC-VU nie połączy się drugi raz 
z tym samym interrogatorem, chyba że znajdował się 
poza strefą łączności przez 255 sekund lub identyfikator 
sygnału interrogatora został zmieniony.  
5.4.3  Sekwencja polecenia zapytania  
DSC_36 Z perspektywy sekwencji polecenia i odpowiedzi transakcj ę 
opisuje się w następujący sposób:  
Sekwencja  Nadajnik  Odbiornik  Opis  Działanie  
1 REDCR  >  DSRC-VU  Inicjacja łącza komunika­
cyjnego żądanie  REDCR emituje BST  
2 DSRC-VU  >  REDCR  Inicjacja łącza komunika ­
cyjnego odpowied ź Jeżeli BST obs ługuje AID=2, 
to DSRC-VU żąda okna 
prywatnego  
3 REDCR  >  DSRC-VU  Przyznaje okno prywatne  Wysyła ramkę zawierającą 
przydział okna prywatnego  
4 DSRC-VU  >  REDCR  Wysy ła VST  Wysy ła ramkę zawieraj ącą 
VST 
5 REDCR  >  DSRC-VU  Wysyła GET.request 
w odniesieniu do danych 
zawartych w Atrybucie 
dotyczącym konkretnego 
EID 
6 DSRC-VU  >  REDCR  Wysy ła GET.response 
z żądanym atrybutem doty ­
czącym konkretnego EID  Wysyła Atrybut (RTMData, 
OWSData….) zawieraj ący 
dane dotycz ące konkretnego 
EID ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 558  
Sekwencja  Nadajnik  Odbiornik  Opis  Działanie  
▼M1 
7 REDCR  >  DSRC-VU  Wysyła GET.request 
w odniesieniu do danych 
innego Atrybutu (w razie 
potrzeby)  
▼B 
8 DSRC-VU  >  REDCR  Wysy ła GET.response 
z żądanym atrybutem  Wysyła Atrybut zawieraj ący 
dane dotycz ące konkretnego 
EID 
9 REDCR  >  DSRC-VU  Potwierdza pomyślne 
otrzymanie danych  Wysyła polecenie RELEASE 
zamykające transakcję  
10 DSRC-VU  Zamyka transakcj ę 
Przykład sekwencji transakcji i zawartości wymienianych 
ramek przedstawiono w pkt 5.4.7 i 5.4.8.  
5.4.4  Struktury danych  
DSC_37 Struktura semantyczna  Danych  przekazywanych przez inter­
fejs DSRC działający na częstotliwości 5,8 GHz jest zgodna 
ze strukturą opisaną w niniejszym dodatku. Strukturę tych 
danych przedstawiono w tym punkcie.  
DSC_38 Ładunek (dane dotyczące zdalnego monitorowania tacho­
grafu) składa się z połączenia:  
1. danych EncryptedTachographPayload stanowiących 
zaszyfrowane dane TachographPayload określone w specy­
fikacji ASN.1 w sekcji 5.4.5. Metodę szyfrowania opisano 
w dodatku 11;  
2. danych DSRCSecurityData określonych w dodatku 11.  
DSC_39 Dane dotyczące zdalnego monitorowania tachografu opisuje  
się jako Atrybut RTM = 1 i przekazuje w kontenerze RTM 
= 10.  
DSC_40 Znacznik kontekstowy RTM określa obsługiwaną część 
normy w serii norm TARV (RTM odnosi się do części 9).  
Zawarta w module ASN.1 definicja danych DSRC w ramach 
aplikacji RTM jest następująca:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 559
  
► (2) (3) M1 
► (1) M3 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 560
  
5.4.5  Elementy danych dotycz ących zdalnego monitorowania tachografu 
(RtmData), wykonywane czynno ści i definicje  
DSC_41 Wartości danych, które mają zostać obliczone przez VU 
i wykorzystane do uaktualnienia zabezpieczonych danych 
w DSRC-VU, oblicza się zgodnie z zasadami przedstawio­
nymi w tabeli 14.3:  
▼M3 
Tabela 14.3  
Elementy RtmData, wykonywane czynno ści i definicje  
1) 
Element danych RTM  2) 
Czynność wykonywana przez VU  3) 
Definicja danych w ASN.1  
RTM1 
Tablica rejestracyjna 
pojazdu  VU ustala wartość  
tp15638VehicleRegistration ­
Plate  elementu danych 
RTM1 na podstawie zareje­
strowanej wartości typu 
danych  
VehicleRegistrationIdentifica ­
tion, jak określono w dodatku 
1 VehicleRegistrationIdentifi ­
cation  Numer tablicy rejestra­
cyjnej pojazdu wyrażony 
jako ciąg znaków  tp15638VehicleRegistration­
Plate LPN, 
–tablica rejestracyjna pojazdu 
ze strukturą danych według 
ISO 14906, ale z następu­
jącym ograniczeniem na 
potrzeby aplikacji RTM: 
SEKWENCJA rozpoczyna się 
od kodu kraju, po którym 
następuje wskaźnik alfabetu, 
po którym następuje sam 
numer tablicy, 
który ma zawsze 14 oktetów 
(wypełnionych zerami), tak 
więc długość typu LPN 
zawsze wynosi 17 oktetów 
(determinant długości nie jest 
potrzebny), z czego 14 to 
„rzeczywisty” numer tablicy.  
RTM2 
Zdarzenia polegaj ące na 
przekroczeniu pr ędkości VU generuje wartość 
logiczną 
w odniesieniu do elementu 
danych RTM2 
tp15638SpeedingEvent. 
VU oblicza wartość 
tp15638SpeedingEvent na 
podstawie zdarzeń przekro­
czenia prędkości zarejestro­
wanych w VU w ciągu 
ostatnich 10 dni, jak okre­ 
ślono w załączniku IC .  1 (PRAWDA): jeżeli 
ostatnie zdarzenie prze­
kroczenia prędkości 
zakończyło się w ciągu 
ostatnich 10 dni lub trwa 
nadal; 
0 (FAŁSZ): w każdym 
innym przypadku.  tp15638SpeedingEvent 
BOOLEAN,  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 561  
1) 
Element danych RTM  2) 
Czynność wykonywana przez VU  3) 
Definicja danych w ASN.1  
RTM3 
Prowadzenie pojazdu 
bez 
ważnej karty  VU generuje wartość 
logiczną 
w odniesieniu do elementu 
danych RTM3 
tp15638DrivingWithoutVa­
lidCard. 
VU przypisuje wartość 
PRAWDA zmiennej 
tp15638DrivingWithoutVa­
lidCard, jeżeli w VU zareje­
strowano co najmniej jedno 
zdarzenie prowadzenia 
pojazdu bez odpowiedniej 
karty w ciągu ostatnich 10 
dni, jak określono w załącz­
niku IC.  1 (PRAWDA): jeżeli 
ostatnie zdarzenie 
prowadzenia pojazdu bez 
odpowiedniej karty 
zakończyło się w ciągu 
ostatnich 10 dni lub trwa 
nadal; 
0 (FAŁSZ): w każdym 
innym przypadku.  tp15638DrivingWithoutValid­
Card 
BOOLEAN,  
RTM4 
Ważna karta kierowcy  VU generuje wartość 
logiczną w odniesieniu do 
elementu danych RTM4 
tp15638DriverCard na 
podstawie ważnej karty 
kierowcy włożonej w szcze­
linę czytnika karty kierowcy.  1 (PRAWDA): jeżeli 
w szczelinie czytnika 
karty kierowcy VU nie 
ma ważnej karty 
kierowcy; 
0 (FAŁSZ): jeżeli 
w szczelinie czytnika 
karty kierowcy VU 
znajduje się ważna karta 
kierowcy.  tp15638DriverCard 
BOOLEAN,  
RTM5 
Włożenie karty podczas 
prowadzenia 
pojazdu  VU generuje wartość 
logiczną w odniesieniu do 
elementu danych RTM5 
tp15638CardInsertion. 
VU przypisuje wartość 
PRAWDA zmiennej 
tp15638CardInsertion, jeżeli 
w VU zarejestrowano co 
najmniej jedno zdarzenie 
włożenia karty podczas 
prowadzenia pojazdu w ciągu 
ostatnich 10 dni, jak okre­ 
ślono w załączniku IC.  1 (PRAWDA): Jeżeli 
ostatnie zdarzenie 
włożenia karty podczas 
prowadzenia pojazdu 
miało miejsce w ciągu 
ostatnich 10 dni; 
0 (FAŁSZ): w każdym 
innym przypadku.  tp15638CardInsertion 
BOOLEAN,  
RTM6 
Błąd danych dotycz ą­
cych ruchu  VU generuje wartość 
logiczną 
w odniesieniu do elementu 
danych RTM6. 
VU przypisuje wartość 
PRAWDA zmiennej 
tp15638MotionDataError, 
jeżeli w VU zarejestrowano 
co najmniej jedno zdarzenie 
błędu danych dotyczących 
ruchu w ciągu ostatnich 10 
dni, jak określono w załącz­
niku IC.  1 (PRAWDA): jeżeli 
ostatnie zdarzenie błędu 
danych dotyczących 
ruchu zakończyło się 
w ciągu ostatnich 10 dni 
lub trwa nadal; 
0 (FAŁSZ): w każdym 
innym przypadku.  tp15638MotionDataError 
BOOLEAN,  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 562  
1) 
Element danych RTM  2) 
Czynność wykonywana przez VU  3) 
Definicja danych w ASN.1  
RTM7 
Konflikt ruchu 
pojazdu  VU generuje wartość 
logiczną 
w odniesieniu do elementu 
danych RTM7. 
VU przypisuje wartość 
PRAWDA zmiennej 
tp15638VehicleMotionCon­
flict, jeżeli w VU zarejestro­
wano co najmniej jedno 
zdarzenie konfliktu ruchu 
pojazdu w ciągu ostatnich 10 
dni. 1 (PRAWDA): jeżeli 
ostatnie zdarzenie 
konfliktu ruchu pojazdu 
zakończyło się w ciągu 
ostatnich 10 dni lub trwa 
nadal; 
0 (FAŁSZ): w każdym 
innym przypadku.  tp15638VehicleMotionConflict 
BOOLEAN,  
RTM8 
Druga karta kierowcy  VU generuje wartość 
logiczną 
w odniesieniu do elementu 
danych RTM8 na podstawie 
załącznika IC („Dane doty­
czące czynności kierowcy” 
w odniesieniu do ZAŁOGI 
i WSPÓŁKIEROWCY). 
W przypadku braku ważnej 
karty współkierowcy VU 
ustawia wartość RTM8 na 
PRAWDA.  1 (PRAWDA): jeżeli 
w VU znajduje się 
ważna karta współkie­
rowcy; 
2 (FAŁSZ): jeżeli w VU 
nie ma ważnej karty 
współkierowcy.  tp156382ndDriverCard 
BOOLEAN,  
RTM9 
Bieżąca czynno ść VU generuje wartość 
logiczną 
w odniesieniu do elementu 
danych RTM9. 
Jeżeli VU zarejestruje bieżącą 
czynność jako jakąkolwiek 
czynność inną niż PROWA­
DZENIE, jak określono 
w załączniku IC, ustawia 
wartość RTM9 na 
PRAWDA.  1 (PRAWDA): inna 
wybrana 
czynność; 
0 (FAŁSZ): wybór 
czynności „prowa­
dzenie”  tp15638CurrentActivityDri­
ving 
BOOLEAN  
RTM10 
Zamknięcie ostatniej 
sesji VU generuje wartość 
logiczną w odniesieniu do 
elementu danych RTM10. 
Jeżeli ostatnia sesja karty nie 
została prawidłowo 
zamknięta zgodnie z proce­
durą opisaną w załączniku 
IC, VU ustawia wartość 
RTM10 na PRAWDA.  1 (PRAWDA): co 
najmniej jedna z włożo­
nych kart wywołała błąd 
niepoprawnego 
zamknięcia ostatniej sesji 
karty; 
0 (FAŁSZ): żadna 
z włożonych kart nie 
wywołała błędu niepo­
prawnego zamknięcia 
ostatniej sesji karty.  tp15638LastSessionClosed 
BOOLEAN  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 563  
1) 
Element danych RTM  2) 
Czynność wykonywana przez VU  3) 
Definicja danych w ASN.1  
RTM11 
Przerwa w zasilaniu  VU generuje wartość 
w postaci 
liczby całkowitej w odnie­
sieniu do elementu danych 
RTM11. 
VU przypisuje zmiennej 
tp15638PowerSupplyInter­
ruption wartość odpowiada­
jącą liczbie zarejestrowanych 
zdarzeń przerwy w zasilaniu 
przechowywanych w VU 
w ciągu ostatnich 10 dni, jak 
określono w załączniku IC. 
Jeżeli VU nie zarejestrował 
żadnego zdarzenia przerwy 
w zasilaniu w ciągu ostatnich 
10 dni, ustala wartość 
RTM11 na 0.  Liczba zarejestrowanych 
przerw w zasilaniu 
w ciągu ostatnich 10 
dni. tp15638PowerSupplyInterrup­
tion 
INTEGER (0..127),  
RTM12 
Usterka czujnika  VU generuje wartość 
w postaci liczby całkowitej 
w odniesieniu do elementu 
danych RTM12. 
VU przypisuje zmiennej 
sensorFault wartość: 
— 1, jeżeli zdarzenie typu 
„35”H związane 
z usterką czujnika 
zostało 
zarejestrowane w ciągu 
ostatnich 10 dni lub trwa 
nadal. 
— 2, jeżeli zdarzenie zwią­
zane z usterką odbior­
nika GNSS (wewnętrz­
nego albo zewnętrznego, 
o wartości enum 
„36”H lub „37”H) 
zakończyło się w ciągu 
ostatnich 10 dni lub trwa 
nadal. 
— 3, jeżeli zdarzenie typu 
„0E”H związane 
z błędem połączenia 
z urządzeniem 
zewnętrznym GNSS 
zakończyło się w ciągu 
ostatnich 10 dni lub trwa 
nadal. 
— 4, jeżeli zarówno usterka 
czujnika, jak i usterka 
odbiornika GNSS zakoń­
czyły się w ciągu ostat­
nich 10 dni lub trwają 
nadal. 
— 5, jeżeli zarówno usterka 
czujnika, jak i błąd 
połączenia z urządzeniem 
zewnętrznym GNSS 
zakończyły się w ciągu 
ostatnich 10 dni lub 
trwają nadal.  –usterka czujnika jeden 
oktet zgodnie ze słowni­
kiem danych  tp15638SensorFault INTEGER 
(0..255),  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 564  
1) 
Element danych RTM  2) 
Czynność wykonywana przez VU  3) 
Definicja danych w ASN.1  
— 6, jeżeli zarówno usterka 
odbiornika GNSS, jak 
i błąd połączenia z urzą­
dzeniem zewnętrznym 
GNSS zakończyły się 
w ciągu ostatnich 10 dni 
lub trwają nadal. 
— 7, jeżeli wszystkie trzy 
usterki czujnika zakoń­
czyły się w ciągu ostat­
nich 10 dni lub trwają 
nadal. 
Jeżeli żadne zdarzenie nie 
zakończyło się w ciągu 
ostatnich 10 dni ani nie trwa 
nadal, VU ustala wartość 
RTM12 na 0.  
RTM13 
Korekta czasu  VU generuje wartość 
w postaci liczby całkowitej 
(timeReal z dodatku 1) dla 
elementu danych RTM13 na 
podstawie obecności danych 
dotyczących korekty czasu 
zdefiniowanych w załączniku 
IC. 
VU ustawia wartość RTM13 
na czas, w którym doszło do 
wystąpienia ostatniego 
zdarzenia polegającego na 
korekcie czasu danych. 
Jeżeli w danych VU nie 
stwierdzono wystąpienia 
żadnego zdarzenia korekty 
czasu zdefiniowanego 
w załączniku IC, wartość 
RTM13 ustala się na 0.  oldTimeValue ostatniej 
korekty czasu.  tp15638TimeAdjustment 
INTEGER(0..4294967295),  
RTM14 
Próba naruszenia 
zabezpieczenia  VU generuje wartość 
w postaci liczby całkowitej 
(timeReal z dodatku 1) dla 
elementu danych RTM14 na 
podstawie wystąpienia 
zdarzenia próby naruszenia 
zabezpieczenia zdefiniowa­
nego w załączniku IC. 
VU ustala wartość czasu, 
w którym doszło do ostat­
niego zarejestrowanego przez 
VU zdarzenia związanego 
z próbą naruszenia zabezpie­
czenia. 
Jeżeli w danych VU nie 
stwierdzono wystąpienia 
żadnego zdarzenia próby 
naruszenia zabezpieczenia 
zdefiniowanego w załączniku 
IC, wartość RTM14 ustala się 
na 0.  Czas rozpoczęcia ostat­
niego zarejestrowanego 
zdarzenia związanego 
z próbą naruszenia 
zabezpieczenia.  tp15638LatestBreachAttempt 
INTEGER(0..4294967295),  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 565  
1) 
Element danych RTM  2) 
Czynność wykonywana przez VU  3) 
Definicja danych w ASN.1  
RTM15 
Ostatnia kalibracja  VU generuje wartość 
w postaci liczby całkowitej 
(timeReal z dodatku 1) dla 
elementu danych RTM15 na 
podstawie obecności danych 
dotyczących ostatniej kalib­
racji zdefiniowanych 
w załączniku IC i dodatku 1. 
VU ustala wartość RTM15 
na old 
TimeValue ostatniego 
rekordu kalibracji. 
Jeżeli kalibracja nie miała 
miejsca, VU ustala wartość 
RTM15 na 0.  oldTimeValue najno­
wszego rekordu 
kalibracji.  tp15638LastCalibrationData 
INTEGER(0..4294967295),  
RTM16 
Poprzednia kalibracja  VU generuje wartość 
w postaci liczby całkowitej 
(timeReal z dodatku 1) dla 
elementu danych RTM16 
z rekordu kalibracyjnego 
poprzedzającego ostatnią 
kalibrację. 
VU ustala wartość RTM16 
na old 
TimeValue rekordu kalibracji 
poprzedzającego ostatnią 
kalibrację. 
Jeżeli nie było poprzedniej 
kalibracji, VU ustala wartość 
RTM16 na 0.  oldTimeValue rekordu 
kalibracji poprzedzają­
cego najnowszy rekord 
kalibracji.  tp15638PrevCalibrationData 
INTEGER(0..4294967295),  
RTM17 
Data pod łączenia 
tachografu  VU generuje wartość 
w postaci liczby całkowitej 
(timeReal z dodatku 1) 
w odniesieniu do elementu 
danych RTM17. 
VU ustala wartość RTM17 
na datę pierwszej kalibracji 
VU w bieżącym pojeździe. 
VU wyodrębnia te dane 
z VuCalibrationData 
(dodatek 1) znajdujących się 
w VuCalibrationRecords 
z CalibrationPurpose 
równym: „03”H 
Jeżeli nie było poprzedniej 
kalibracji, VU ustala wartość 
RTM17 na 0.  Data pierwszej kalibracji 
VU w bieżącym pojeź­
dzie.  tp15638DateTachoConnected 
INTEGER(0..4294967295),  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 566  
1) 
Element danych RTM  2) 
Czynność wykonywana przez VU  3) 
Definicja danych w ASN.1  
RTM18 
Prędkość bieżąca VU generuje wartość 
w postaci 
liczby całkowitej w odnie­
sieniu do elementu danych 
RTM18. 
VU ustala wartość RTM18 
na wartość ostatniej zareje­
strowanej prędkości bieżącej 
w chwili dokonania ostatniej 
aktualizacji RtmData.  Ostatnia zarejestrowana 
prędkość bieżąca  tp15638CurrentSpeed 
INTEGER (0..255),  
RTM19 
Znacznik czasu  VU generuje wartość 
w postaci liczby całkowitej 
w odniesieniu do elementu 
danych RTM19 (timeReal 
z dodatku 1). 
VU ustala wartość RTM19 
na czas ostatniej aktualizacji 
RtmData.  Znacznik czasu bieżą­
cego 
rekordu TachographPay­
load tp15638Timestamp 
INTEGER(0..4294967295),  
RTM20 
Czas, kiedy by ła 
dostępna ostatnia uwie ­
rzytelniona pozycja 
pojazdu  VU generuje wartość 
w postaci liczby całkowitej 
(timeReal z dodatku 1) 
w odniesieniu do elementu 
danych RTM20. 
VU ustala wartość RTM20 
na czas, kiedy ostatnia uwie­
rzytelniona pozycja pojazdu 
była dostępna z odbiornika 
GNSS . 
Jeżeli żadna uwierzytelniona 
pozycja pojazdu nie była 
kiedykolwiek dostępna 
z odbiornika GNSS, VU 
ustawia wartość RTM20 
na 0.  Znacznik czasu ostatniej 
uwierzytelnionej pozycji 
pojazdu  tp15638LatestAuthenticatedPo­
sition 
INTEGER(0..4294967295),  
RTM21 
Nieprzerwany czas 
prowadzenia pojazdu  VU generuje wartość 
w postaci liczby całkowitej 
w odniesieniu do elementu 
danych RTM21. 
VU ustala wartość RTM21 
na trwający nieprzerwany 
czas prowadzenia pojazdu 
przez kierowcę.  Nieprzerwany czas 
prowadzenia pojazdu 
przez kierowcę, zakodo­
wany jako liczba całko­
wita. 
Długość: 1 bajt 
Rozdzielczość: 2 minuty/ 
bit 
Brak offsetu 
Przedział danych: 0 
do 250 
Wartość 250 wskazuje, 
że nieprzerwany czas 
prowadzenia pojazdu 
przez kierowcę wynosi 
co najmniej 500 minut. 
Wartości 251 do 254 nie 
używa się. 
Wartość 255 wskazuje, 
że informacje nie są 
dostępne.  tp15638ContinuousDrivin­
gTime INTEGER(0..255),  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 567  
1) 
Element danych RTM  2) 
Czynność wykonywana przez VU  3) 
Definicja danych w ASN.1  
RTM22 
Najdłuższy dzienny czas 
prowadzenia pojazdu dla 
trwającej i poprzedniej 
zmiany RTM, obliczony 
zgodnie z addendum do 
dodatku 14  VU generuje wartość 
w postaci liczby całkowitej 
w odniesieniu do elementu 
danych RTM22. 
VU ustawia wartość RTM22 
na dłuższy z dwóch dzien­
nych okresów prowadzenia 
pojazdu przez kierowcę, tj. 
na trwającą lub poprzednią 
zmianę RTM.  Dzienny czas prowa­
dzenia pojazdu przez 
kierowcę, zakodowany 
jako liczba całkowita. 
Długość: 1 bajt 
Rozdzielczość: 4 minuty/ 
bit 
Brak offsetu 
Przedział danych: 0 
do 250 
Wartość 250 wskazuje, 
że dzienny czas prowa­
dzenia pojazdu przez 
kierowcę wynosi co 
najmniej 1 000 minut. 
Wartości 251 do 254 nie 
używa się. 
Wartość 255 wskazuje, 
że informacje nie są 
dostępne.  tp15638DailyDrivingTimeShift 
INTEGER(0..255),  
RTM23 
Najdłuższy dzienny czas 
prowadzenia pojazdu 
w trwającym tygodniu, 
obliczony zgodnie 
z addendum do 
dodatku 14  VU generuje wartość 
w postaci liczby całkowitej 
w odniesieniu do elementu 
danych RTM23. 
VU ustawia wartość RTM23 
na najdłuższy dzienny czas 
prowadzenia pojazdu przez 
kierowcę, tj. na trwającą 
zmianę RTM lub jakąkolwiek 
ukończoną zmianę RTM, 
która rozpoczęła się lub 
zakończyła w trwającym 
tygodniu.  Dzienny czas prowa­
dzenia pojazdu przez 
kierowcę, zakodowany 
jako liczba całkowita. 
Długość: 1 bajt 
Rozdzielczość: 4 minuty/ 
bit 
Brak offsetu 
Przedział danych: 0 
do 250 
Wartość 250 wskazuje, 
że dzienny czas prowa­
dzenia pojazdu przez 
kierowcę wynosi co 
najmniej 1 000 minut. 
Wartości 251 do 254 nie 
używa się. 
Wartość 255 wskazuje, 
że informacje nie są 
dostępne.  tp15638DailyDrivingTime­
Week INTEGER(0..255),  
RTM24 
Tygodniowy czas prowa ­
dzenia pojazdu, obliczony 
zgodnie z addendum do 
dodatku 14  VU generuje wartość 
w postaci liczby całkowitej 
w odniesieniu do elementu 
danych RTM24. 
VU ustala wartość RTM24 
na tygodniowy czas prowa­
dzenia pojazdu przez 
kierowcę.  Tygodniowy czas 
prowadzenia pojazdu 
przez kierowcę, zakodo­
wany jako liczba całko­
wita. 
Długość: 1 bajt 
Rozdzielczość: 20 
minuty/bit 
Brak offsetu 
Przedział danych: 0 
do 250 
Wartość 250 wskazuje, 
że tygodniowy czas 
prowadzenia pojazdu 
przez kierowcę wynosi 
co najmniej 5 000 minut. 
Wartości 251 do 254 nie 
używa się. 
Wartość 255 wskazuje, 
że informacje nie są 
dostępne.  tp15638WeeklyDrivingTime 
INTEGER(0..255),  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 568  
1) 
Element danych RTM  2) 
Czynność wykonywana przez VU  3) 
Definicja danych w ASN.1  
RTM25 
Dwutygodniowy czas 
prowadzenia pojazdu, 
obliczony zgodnie 
z addendum do 
dodatku 14  VU generuje wartość 
w postaci liczby całkowitej 
w odniesieniu do elementu 
danych RTM25. 
VU ustala wartość RTM25 
na dwutygodniowy czas 
prowadzenia pojazdu przez 
kierowcę.  Dwutygodniowy czas 
prowadzenia pojazdu 
przez kierowcę, zakodo­
wany jako liczba całko­
wita. 
Długość: 1 bajt 
Rozdzielczość: 30 
minuty/bit 
Brak offsetu 
Przedział danych: 0 
do 250 
Wartość 250 wskazuje, 
że dwutygodniowy czas 
prowadzenia pojazdu 
przez kierowcę wynosi 
co najmniej 7 500 minut. 
Wartości 251 do 254 nie 
używa się. 
Wartość 255 wskazuje, 
że informacje nie są 
dostępne.  tp15638FortnightlyDrivin­
gTime INTEGER(0..255),  
Uwaga: RTM22, RTM23, RTM24 i RTM25 oblicza się zgodnie z addend um do 
niniejszego dodatku.  
▼B 
5.4.6  Mechanizm przesy łania danych  
DSC_42 REDCR wysyła żądanie przekazania zdefiniowanych wcześ­
niej danych ładunku po zakończeniu etapu inicjacji; następnie  
DSRC-VU  przekazuje te dane w przydzielonym oknie. 
REDCR korzysta z polecenia GET w celu pobrania danych.  
▼M1 
DSC_43 Wszystkie dane wymieniane w ramach DSRC koduje się przy 
użyciu reguł PER (Packed Encoding Rules) UNALIGNED, 
z wyjątkiem
  oraz
  
, które koduje się przy użyciu reguł OER (Octet Encoding 
Rules) zdefiniowanych w normie ISO/IEC 8825-7, Rec. 
ITU-T X.696.  
▼B 
5.4.7  Szczegó łowy opis transakcji DSRC  
DSC_44 Inicjację przeprowadza się zgodnie z pkt DSC_44–DSC_48 
oraz tabelami 14.4–14.9. Na etapie inicjacji REDCR rozpo­
czyna przesyłanie ramki zawierającej BST (tabelę usług 
sygnału) zgodnie z normami EN 12834 i EN 13372 pkt 
6.2, 6.3, 6.4 i 7.1 z ustawieniami określonymi w tabeli 14.4 
poniżej.  
Tabela 14.4  
Inicjacja – ustawienia ramki BST  
Pole Ustawienia  
Identyfikator łącza  Adres emisji  
Identyfikator sygnału  Zgodnie z normą EN 12834  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 569  
Czas  Zgodnie z normą EN 12834  
Profil  Brak rozszerzenia, należy 
zastosować 0 lub 1  
Aplikacje obowiązkowe  Brak rozszerzenia, brak EID, 
brak parametru, AID = 2 
Freight&Fleet  
Aplikacje nieobowiązkowe  Brak  
Lista profilów  Brak rozszerzenia, liczba 
profilów na liście = 0  
Nagłówek fragmentacji  Brak fragmentacji  
Ustawienia 2. warstwy  Polecenie PDU, polecenie 
interfejsu użytkownika  
W tabeli 14.5 poniżej przedstawiono praktyczny przykład 
zastosowania ustawień określonych w tabeli 14.4 wraz z infor­
macjami o kodowaniu bitowym.  
Tabela 14.5  
Inicjacja – przyk ładowa zawarto ść ramki BST
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
1 FLAGA
  Flaga początkowa  
2 Identyfikator emisji
  Adres emisji  
3 Pole kontrolne MAC
  Polecenie PDU  
4 Pole kontrolne LLC
  Polecenie interfejsu użyt­
kownika  
5 Nagłówek fragmentacji
  Brak fragmentacji  
6 BST
  Żądanie inicjacji  
SEQUENCE {  
OPTION indicator 
BeaconID SEQUENCE { 
ManufacturerId INTEGER (0..65535)
  Brak aplikacji nieobo­
wiązkowych
  
Identyfikator producenta  
7
 
8
 
IndividualID INTEGER (0..134217727) 
}
 27-bitowy identyfikator 
dostępny dla producenta  
9
 
10
 
11
 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 570
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
12 Time INTEGER (0..4294967295)
  Czas rzeczywisty w 32- 
bitowym systemie UNIX  
13
 
14
 
15
 
16 Profile NTEGER (0..127,...)
  Brak rozszerzenia. Przy­
kładowy profil 0  
17 MandApplications SEQUENCE 
(SIZE(0..127,...)) 
OF {
  Brak rozszerzenia, liczba 
aplikacji obowiązkowych 
= 1 
18 SEQUENCE {  
Wskaźnik WARIANTU
  Brak EID  
Wskaźnik WARIANTU
  Brak parametru  
AID DSRCApplicationEntityID } }
  Brak rozszerzenia. AID= 
2 Freight&Fleet  
19 ProfileList SEQUENCE (0..127,...) OF 
Profile }
  Brak rozszerzenia, liczba 
profilów na liście = 0  
20 FCS
  Sekwencja kontroli ramki  
21
 
22 Flaga
  Flaga końcowa  
DSC_45 Po otrzymaniu BST  DSRC-VU  żąda przydzielenia okna 
prywatnego zgodnie z postanowieniami norm EN 12795 
i EN 13372 pkt 7.1.1, bez określonych ustawień RTM. 
W tabeli 14.6 przedstawiono przykład kodowania bitowego.  
Tabela 14.6  
Inicjacja – zawarto ść ramki dotycz ącej żądania przydzielenia okna prywatnego
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
1 FLAGA
  Flaga początkowa  
2 Prywatny LID
  Adres łącza określonego 
DSRC-VU  
3
 
4
 
5
 
6 Pole kontrolne MAC
  Żądanie przydzielenia 
okna prywatnego  
7 FCS
  Sekwencja kontroli ramki  
8
 
9 Flaga
  Flaga końcowa  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 571  
DSC_46 Następnie REDCR odpowiada, przydzielając okno prywatne 
zgodnie z postanowieniami norm EN 12795 i EN 13372 pkt 
7.1.1, bez określonych ustawień RTM.  
W tabeli 14.7 przedstawiono przykład kodowania bitowego.  
Tabela 14.7  
Inicjacja – zawarto ść ramki dotycz ącej przydzielenia okna prywatnego
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
1 FLAGA
  Flaga początkowa  
2 Prywatny LID
  Adres łącza określonego 
DSRC-VU  
3
 
4
 
5
 
6 Pole kontrolne MAC
  Przydzielenie okna 
prywatnego  
7 FCS
  Sekwencja kontroli ramki  
8
 
9 Flaga
  Flaga końcowa  
DSC_47 Po otrzymaniu przydziału okna prywatnego  DSRC-VU  prze­
syła swoją VST (tabela usług pojazdu), jak określono 
w normach EN 12834 i EN 13372 pkt 6.2, 6.3, 6.4 i 7.1, 
z ustawieniami określonymi w tabeli 14.8 za pomocą przy­
dzielonego okna transmisji.  
Tabela 14.8  
Inicjacja – ustawienia ramki VST  
Pole Ustawienia  
Prywatny LID  Zgodnie z normą EN 12834  
Parametry VST  Wypełnienie = 0; następnie dla każdej 
obsługiwanej aplikacji: EID wystę­
puje, parametr występuje, AID = 2; 
EID zgodny z wygenerowanym 
przez OBU  
Parametr  Brak rozszerzenia, zawiera znacznik 
kontekstowy RTM  
ObeConfiguration  Opcjonalne pole ObeStatus może być 
obecne, ale nie może być stosowane 
przez REDCR  
Nagłówek fragmentacji  Brak fragmentacji  
Ustawienia 2. warstwy  Polecenie PDU, polecenie interfejsu 
użytkownika  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 572  
DSC_48  DSRC-VU  obsługuje aplikację „Ładunek i flota” (Freight and 
Fleet) opatrzoną identyfikatorem aplikacji „2”. Inne identyfi­
katory aplikacji mogą być obsługiwane, ale nie mogą wystę­
pować w tej VST, ponieważ BST wymaga wyłącznie AID=2. 
Pole „Aplikacje” zawiera wykaz wystąpień aplikacji obsługi­
wanych w ramach  DSRC-VU . Dla każdego obsługiwanego 
wystąpienia aplikacji podaje się odniesienie do odpowiedniej 
normy w formie znacznika Rtm Context, który składa się 
z IDENTYFIKATORA OBIEKTU reprezentującego powią­
zaną normę, jej część (9 w przypadku RTM) oraz – w stosow­
nych przypadkach – wersję, a także EID generowanego przez 
DSRC-VU i powiązanego z danym wystąpieniem aplikacji.  
W tabeli 14.9 przedstawiono praktyczny przykład ustawień 
określonych w tabeli 14.8 wraz z informacjami o kodowaniu 
bitowym.  
▼M3 
Tabela 14.9  
Inicjacja – przyk ładowa zawarto ść ramki VST
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
1 FLAG  0111 1110  Flaga początkowa  
2 Private LID  xxxx xxxx  Adres łącza określonego 
DSRC-VU  
3 xxxx xxxx  
4 xxxx xxxx  
5 xxxx xxxx  
6 MAC Control field  1100 0000  Polecenie PDU  
7 LLC Control field  0000 0011  Polecenie interfejsu użyt­
kownika  
8 Fragmentation header  1xxx x001  Brak fragmentacji  
9 VST 
SEQUENCE { 
Fill BIT STRING (SIZE(4))  1001  Odpowiedź na inicjację  
0000  Niewykorzystywane 
i ustawione na 0  
10 Profile INTEGER (0..127,...) 
Applications SEQUENCE OF {  0000 0000  Brak rozszerzenia. Przy­
kładowy profil 0 
Brak rozszerzenia, 1 apli­
kacja  11 0000 0001  
12 SEQUENCE { 
OPTION indicator 
OPTION indicator 
AID DSRCApplicationEntityID  1 EID występuje  
1 Parametr występuje  
00 0010  Brak rozszerzenia. AID= 
2 Freight&Fleet  
13 EID Dsrc-EID  xxxx xxxx  Zdefiniowany przez OBU 
i identyfikujący wystą­
pienie aplikacji.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 573
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
14 Parameter Container {  0000 0010  Brak rozszerzenia, wybór 
kontenera = 02, 
ciąg oktetowy  
15 0000 0110  Brak rozszerzenia, długość 
znacznika kontekstowego 
RTM = 6  
16 Rtm-ContextMark ::= SEQUENCE { 
StandardIdentifier  0000 0101  Wartość pierwszego 
oktetu to 05H i stanowi 
jego długość. 
Kolejne 5 oktetów koduje 
identyfikator obiektu 
obsługiwanej normy, 
części i wersji. 
{ISO (1) norma (0) 
TARV (15638) część 
9(9) wersja 2 (2)}  17 standardIdentifier  0010 1000  
18 1111 1010  
19 0001 0110  
20 0000 1001  
21 0000 0010  
22 ObeConfiguration Sequence { 
OPTION indicator  0 Brak ObeStatus  
EquipmentClass INTEGER (0..32767)  xxx xxxx  To pole używane jest na 
potrzeby  
23 xxxx xxxx  wskazań producenta doty­
czących wersji oprogra­
mowania/sprzętu inter­
fejsu DSRC  
24 ManufacturerId INTEGER (0..65535)  xxxx xxxx  Identyfikator producenta 
dla DSRC-VU opisany 
w rejestrze dotyczącym 
normy ISO 14816  25 xxxx xxxx  
26 FCS  xxxx xxxx  Sekwencja kontroli ramki  
27 xxxx xxxx  
28 Flag  0111 1110  Flaga końcowa  
▼B 
DCS_49 Następnie REDCR odczytuje dane, wydając polecenie GET, 
które odpowiada poleceniu GET zdefiniowanemu w normie 
EN 13372 pkt 6.2, 6.3, 6.4 i w normie EN 12834; ustawienia 
tego polecenia odpowiadają ustawieniom przedstawionym 
w tabeli 14.10.  
Tabela 14.10  
Przedstawienie – ustawienia ramki żądania GET  
Pole Ustawienia  
Identyfikator źródła (IID)  Brak  
Identyfikator łącza (LID)  Adres łącza określonego DSRC-VU  
Tworzenie łańcuchów  Nie  
Identyfikator elementu (EID)  Jak określono w VST. Brak rozsze­
rzenia  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 574  
Pole Ustawienia  
Poświadczenia dostępu  Nie  
AttributeIdList  Brak rozszerzenia, 1 atrybut, Attribu­
teID = 1 (RtmData)  
Fragmentacja  Nie  
Ustawienia 2. warstwy  Polecenie PDU, wysondowane pole­
cenie ACn  
W tabeli 14.11 przedstawiono przykład odczytu danych RTM.  
Tabela 14.11  
Przedstawienie – przyk ład ramki żądania GET
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
1 FLAGA
  Flaga początkowa  
2 Prywatny LID
  Adres łącza określonego 
DSRC-VU  
3
 
4
 
5
 
6 Pole kontrolne MAC
  Polecenie PDU  
7 Pole kontrolne LLC
  Wysondowane polecenie 
ACn, bit n  
8 Nagłówek fragmentacji
  Brak fragmentacji  
9 Get.request 
SEQUENCE {
  Żądanie Get  
Wskaźnik WARIANTU
  Brak poświadczeń 
dostępu  
Wskaźnik WARIANTU
  Brak IID  
Wskaźnik WARIANTU
  Występuje AttributeIdList  
Wypełnienie CIĄG BITÓW 
(ROZMIAR (1) )
  Ustalono na 0.  
10 EID INTEGER(0..127,…)
  EID wystąpienia aplikacji 
RTM, jak określono 
w VST. Brak rozszerzenia  
11 AttributeIdList SEQUENCE OF { 
AttributeId }}
  Brak rozszerzenia, liczba 
atrybutów = 1  
12
 AttributeId=1, RtmData. 
Brak rozszerzenia  
13 FCS
  Sekwencja kontroli ramki  
14
 
15 Flaga
  Flaga końcowa  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 575  
DSC_50 Po otrzymaniu żądania GET  DSRC-VU  wysyła odpowiedź 
GET wraz z żądanymi danymi zgodnymi z odpowiedzią 
GET określonymi w normie EN 13372 pkt 6.2, 6.3, 6.4 
i w normie EN 12834; ustawienia odpowiadają ustawieniom 
określonym w tabeli 14.12.  
Tabela 14.12  
Przedstawienie – ustawienia ramki odpowiedzi GET  
Pole Ustawienia  
Identyfikator źródła (IID)  Brak  
Identyfikator łącza (LID)  Zgodnie z normą EN 12834  
Tworzenie łańcuchów  Nie  
Identyfikator elementu (EID)  Jak określono w VST.  
Poświadczenia dostępu  Nie  
Fragmentacja  Nie  
Ustawienia 2. warstwy  Odpowiedź PDU, dostępna 
odpowiedź i przyjęte pole­
cenie, polecenie ACn  
W tabeli 14.13 przedstawiono przykład odczytu danych RTM.  
Tabela 14.13  
Przedstawienie – przyk ładowa zawarto ść ramki odpowiedzi
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
1 FLAGA
  Flaga początkowa  
2 Prywatny LID
  Adres łącza określonego 
DSRC-VU  
3
 
4
 
5
 
6 Pole kontrolne MAC
  Odpowiedź PDU  
7 Pole kontrolne LLC
  Dostępna odpowiedź, bit 
n polecenia ACn  
8 Pole stanu LLC
  Dostępna odpowiedź 
i przyjęte polecenie  
9 Nagłówek fragmentacji
  Brak fragmentacji  
10 GET.response 
SEQUENCE {
  Odpowiedź na żądanie 
Get ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 576
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
Wskaźnik WARIANTU
  Brak IID  
Wskaźnik WARIANTU
  Lista atrybutów występuje  
Wskaźnik WARIANTU
  Status zwrotu nie wystę­
puje 
Wypełnienie CIĄG BITÓW 
(ROZMIAR (1) )
  Nieużywany  
11 EID INTEGER(0..127,…)
  Odpowiedź z wystąpienia 
aplikacji 
RTM. Brak rozszerzenia  
12 AttributeList SEQUENCE OF {
  Brak rozszerzenia, liczba 
atrybutów = 1  
13 Attributes SEQUENCE { 
AttributeId
  Brak rozszerzenia, Attri­
buteId=1 (RtmData)  
14 AttributeValue CONTAINER {
  Brak rozszerzenia, wybór 
kontenera = 1010.  
15
 RtmData  
16
 
17
 
… …  
n }}}}
  
n+1 FCS
  Sekwencja kontroli ramki  
n+2
 
n+3 Flaga
  Flaga końcowa  
DSC_51 Następnie REDCR zamyka połączenie, wydając polecenie 
EVENT_REPORT, RELEASE zgodnie z normą EN 13372 
pkt 6.2, 6.3, 6.4 i z normą 12834 pkt 7.3.8, bez określonych 
ustawień RTM. W tabeli 14.14 przedstawiono przykład kodo­
wania bitowego polecenia RELEASE.  
Tabela 14.14  
Zakończenie. EVENT_REPORT Uwolnienie zawarto ści ramki
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
1 FLAGA
  Flaga początkowa  
2 Prywatny LID
  Adres łącza określonego 
DSRC-VU  
3
 
4
 ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 577
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
5
 
6 Pole kontrolne MAC
  Ramka zawiera polecenie 
LPDU  
7 Pole kontrolne LLC
  Polecenie interfejsu użyt­
kownika  
8 Nagłówek fragmentacji
  Brak fragmentacji  
9 EVENT_REPORT.request 
SEQUENCE {
  EVENT_REPORT 
(Uwolnienie)  
Wskaźnik WARIANTU
  Brak poświadczeń 
dostępu  
Wskaźnik WARIANTU
  Parametr zdarzenia nie 
występuje  
Wskaźnik WARIANTU
  Brak IID  
Tryb DANYCH LOGICZNYCH
  Odpowiedź nieoczeki­
wana  
10 EID INTEGER (0..127,…)
  Brak rozszerzenia, EID = 
0 (System)  
11 EventType INTEGER (0..127,…) }
  Typ zdarzenia 0 = Uwol­
nienie  
12 FCS
  Sekwencja kontroli ramki  
13
 
14 Flaga
  Flaga końcowa  
DSC_52 Nie oczekuje się, że  DSRC-VU  odpowie na polecenie 
RELEASE. Następnie łączność zostaje zamknięta.  
5.4.8  Opis transakcji testowej DSRC  
DSC_53 Pełne testy obejmujące zabezpieczanie danych muszą być 
przeprowadzane w sposób określony w dodatku 11 „Wspólne 
mechanizmy zabezpieczenia” przez upoważnione osoby, które 
mają dostęp do procedur zabezpieczenia, z zastosowaniem 
standardowych poleceń GET zdefiniowanych powyżej.  
DSC_54 Testy przeprowadzane na zlecenie oraz testy w ramach prz e­
glądów okresowych wiążące się z koniecznością odszyfro­
wania i zrozumienia treści zaszyfrowanych danych przepro­
wadza się zgodnie z postanowieniami dodatku 11 „Wspólne 
mechanizmy zabezpieczenia” oraz dodatku 9 „Homologacja 
typu – wykaz minimalnych wymaganych testów”.  
Test podstawowej łączności DSRC można jednak przeprowa­
dzić za pomocą polecenia ECHO. Tego rodzaju testy mogą 
być przeprowadzane na zlecenie, w ramach przeglądów okre­
sowych lub w inny sposób na żądanie właściwego organu 
kontrolnego lub zgodnie z wymogami określonymi w rozpo­
rządzeniu (UE) nr 165/2014 (zob. pkt 6 poniżej).  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 578  
DSC_55 W celu przeprowadzenia tego podstawowego testu łączności  
REDCR wydaje polecenie ECHO w trakcie sesji, tj. po 
pomyślnym zakończeniu etapu inicjacji. Sekwencja czynności 
jest zatem zbliżona do sekwencji czynności związanych 
z zapytaniem:  
— Etap 1  REDCR  wysyła „tabelę usług sygnału” (BST), 
która zawiera identyfikatory aplikacji (AID) w wykazie 
obsługiwanych usług. W aplikacji RTM będzie to po 
prostu usługa z wartością AID = 2.  
DSRC-VU  oceni otrzymaną BST i jeżeli uzna, że BST 
żąda danych Freight&Fleet (AID = 2),  DSRC-VU  udzieli 
odpowiedzi. Jeżeli  REDCR  nie oferuje AID=2, 
DSRC-VU przerywa transakcję z  REDCR . 
— Krok 2  DSRC-VU  wysyła żądanie przydzielenia okna 
prywatnego.  
— Krok 3 REDCR przesyła przydział okna prywatnego.  
— Krok 4  DSRC-VU  używa przydzielonego okna prywat­
nego do wysłania swojej tabeli usług pojazdu (VST). 
Tego rodzaju VST zawiera wykaz wszystkich różnych 
wystąpień aplikacji obsługiwanych przez ten  DSRC-VU  
w ramach AID=2. Poszczególne wystąpienia są identyfi­
kowane za pomocą jednorazowych identyfikatorów 
elementu, z których każdy jest powiązany z wartością 
parametru określającą wystąpienie obsługiwanej aplikacji.  
— Krok 5 Następnie  REDCR  analizuje oferowaną tabelę 
usług pojazdu i albo przerywa łączność (RELEASE), 
ponieważ nie jest zainteresowany niczym, co dana VST 
ma do zaoferowania (tj. otrzymuje VST od  DSRC-VU , 
która nie jest RTM VU), albo – jeżeli otrzymuje odpo­
wiednią tabelę usług pojazdu – uruchamia wystąpienie 
aplikacji.  
— Krok 6  REDCR  wydaje polecenie (ECHO) określonemu  
DSRC-VU  i przypisuje okno prywatne.  
— Krok 7  DSRC-VU  korzysta z nowo przydzielonego okna 
prywatnego do wysłania ramki odpowiedzi ECHO.  
W poniższych tabelach przedstawiono praktyczny przykład sesji 
wymiany ECHO.  
DSC_56 Inicjację przeprowadza się zgodnie z pkt 5.4.7 
(DSC_44–DSC_48) oraz tabelami 14.4–14.9.  
DSC_57 Następnie REDCR wydaje polecenie ACTION, ECHO 
zgodnie z normą ISO 14906, zawierającą 100 oktetów danych 
i bez określonych ustawień RTM. W tabeli 14.15 przedsta­
wiono zawartość ramki wysłanej przez REDCR.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 579  
Tabela 14.15  
Przykładowa ramka żądania ACTION, ECHO
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
1 FLAGA
  Flaga początkowa  
2 Prywatny LID
  Adres łącza określonego 
DSRC-VU  
3
 
4
 
5
 
6 Pole kontrolne MAC
  Polecenie PDU  
7 Pole kontrolne LLC
  Wysondowane polecenie 
ACn, bit n  
8 Nagłówek fragmentacji
  Brak fragmentacji  
9 ACTION.request 
SEQUENCE {
  Żądanie działania (ECHO)  
Wskaźnik WARIANTU
  Brak poświadczeń dostępu  
Wskaźnik WARIANTU
  Parametr akcji występuje  
Wskaźnik WARIANTU
  Brak IID  
Tryb BOOLEAN
  Odpowiedź oczekiwana  
10 EID INTEGER (0..127,…)
  Brak rozszerzenia, EID = 
0 (System)  
11 ActionType INTEGER (0..127,…)
  Brak rozszerzenia, typ 
działania: żądanie ECHO  
12 ActionParameter CONTAINER {
  Brak rozszerzenia, wybór 
kontenera = 2  
13
 Brak rozszerzenia. 
Długość ciągu = 
100 oktetów  
14
 Dane, które mają być 
powtórzone  
… …  
113 } }
  
114614  FCS
  Sekwencja kontroli ramki  
115715
  
116816  Flaga
  Flaga końcowa  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 580  
DSC_58 Po otrzymaniu żądania ECHO  DSRC-VU  wysyła odpowiedź 
ECHO o długości 100 oktetów danych, odzwierciedlając 
otrzymane polecenie, zgodnie z normą ISO 14906, bez okre­ 
ślonych ustawień RTM. W tabeli 14.16 przedstawiono przy­
kład szyfrowania na poziomie bitów.  
Tabela 14.16  
Przykładowa ramka żądania ACTION, ECHO
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
1 FLAGA
  Flaga początkowa  
2 Prywatny LID
  Adres łącza określonego 
VU 
3
 
4
 
5
 
6 Pole kontrolne MAC
  Odpowiedź PDU  
7 Pole kontrolne LLC
  Polecenie ACn, bit n  
8 Pole stanu LLC
  Odpowiedź dostępna  
9 Nagłówek fragmentacji
  Brak fragmentacji  
10 ACTION.response 
SEQUENCE {
  Odpowiedź na DZIAŁANIE 
(ECHO)  
Wskaźnik WARIANTU
  Brak IID  
Wskaźnik WARIANTU
  Parametr odpowiedzi 
występuje  
Wskaźnik WARIANTU
  Status zwrotu nie wystę­
puje 
Wypełnienie CIĄG BITÓW 
(ROZMIAR (1) )
  Nieużywany  
11 EID INTEGER (0..127,…)
  Brak rozszerzenia, EID = 
0 (System)  
12 KONTENER ResponseParameter {
  Brak rozszerzenia, wybór 
kontenera = 2  
13
 Brak rozszerzenia. 
Długość ciągu = 100 
oktetów  
14
 Powtórzone dane  
… …  
113 } }
  
114 FCS
  Sekwencja kontroli ramki  
115
 
116 Flaga
  Flaga końcowa  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 581  
5.5 Zarezerwowane dla przysz łego użytku 
▼M2 __________  
▼B 
5.6 Przesy łanie danych pomi ędzy DSRC-VU a VU  
5.6.1  Połączenie fizyczne i interfejsy  
DSC_66 Połączenie między  VU  a DSRC-VU  może odbywać się za 
pomocą fizycznego okablowania lub łączności bezprzewo­
dowej o krótkim zasięgu opartej na technologii Bluetooth 
v4.0 BLE.  
DSC_67 Niezależnie od wybranego fizycznego połączenia i interfe jsu 
następujące wymogi muszą być spełnione:  
DSC_68  ►M1 a) aby można było zawierać umowy z różnymi 
dostawcami na dostawę VU i DSRC-VU oraz 
w praktyce różnych serii DSRC-VU, połączenie 
między VU a DSRC-VU niebędącym elementem 
wewnętrznym VU musi być otwartym połączeniem 
standardowym. VU musi być połączony z DSRC- 
VU za pomocą: ◄  
(i) zamontowanego na stałe kabla o długości co 
najmniej 2 metrów z wykorzystaniem łącznika 
Straight DIN 41612 H11 – 11-biegunowego 
zatwierdzonego wtyku z DSRC-VU w celu 
dopasowania do podobnego gniazda zatwier­
dzonego przez DIN/ISO z urządzenia VU albo  
(ii) technologii Bluetooth Low Energy (BLE) albo  
(iii) standardowego połączenia określonego w ISO 
11898 lub SAE J1939,  
DSC_69 b) definicja interfejsów i połączenia między VU i DSRC-V U 
musi obsługiwać polecenia protokołu aplikacji zdefinio­
wane w pkt 5.6.2 oraz  
DSC_70 c) VU i DSRC-VU muszą obsługiwać operację przesyłania 
danych za pośrednictwem połączenia w odniesieniu do 
wydajności i zasilania.  
5.6.2  Protokó ł aplikacji  
DSC_71 Protokół aplikacji między urządzeniem do łączności na od le­
głość w VU a DSRC-VU jest odpowiedzialny za okresowe 
przesyłanie danych dotyczących łączności na odległość z VU 
do DSRC.  
DSC_72 Określono następujące polecenia główne:  
1. Inicjacja łącza komunikacyjnego – żądanie  
2. Inicjacja łącza komunikacyjnego – odpowiedź  
3. Wysyłanie danych z identyfikatorem aplikacji RTM 
i ładunkiem określonym przez dane RTM  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 582  
4. Potwierdzenie danych  
5. Zamknięcie łącza komunikacyjnego – żądanie  
6. Zamknięcie łącza komunikacyjnego – odpowiedź  
DSC_73 W module ASN1.0 wcześniejsze polecenia można zdefi­
niować w następujący sposób:
  
DSC_74 Opis poleceń i parametrów jest następujący:  
—
 ­
stosuje się w celu zainicjowania łącza komunikacyjnego. 
Polecenie jest wysyłane przez VU do DSRC-VU. VU 
ustanawia LinkIdentifier i przekazuje DSRC-VU w celu 
śledzenia określonego łącza komunikacyjnego.  
(Uwaga: służy to obsłudze przyszłych łączy i innych apli­
kacji/modułów takich jak system ważenia w pojeździe);  
—
 jest 
stosowane przez DSRC-VU w celu dostarczenia odpo­
wiedzi na żądanie zainicjowania łącza komunikacyjnego. 
Polecenie jest wysyłane przez DSRC-VU do VU. Pole­
cenie przekazuje wynik inicjacji w formie odpowiedzi = 1 
(Sukces) lub = 0 (Niepowodzenie).  
DSC_75 Zainicjowanie łącza komunikacyjnego następuje dopiero po  
zainstalowaniu, kalibracji i uruchomieniu silnika/VU.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 583  
—
 jest stosowane przez VU do przesy­ 
łania podpisanych RCDTData (tj.  danych dotycz ących 
łączności na odleg łość) do DSRC-VU. Dane będą wysy­ 
łane co 60 sekund. Parametr DataTransactionId identyfi­
kuje określoną transmisję danych. LinkIdentifier wyko­
rzystuje się także do upewnienia się, że łącze jest prawid­ 
łowe;  
—
 jest wysyłane przez 
DSRC-VU w celu dostarczenia VU informacji zwrotnej 
dotyczącej odbioru danych z polecenia­
  
określonego przez parametr Data­
TransactionId. Parametr odpowiedzi to 1 (Sukces) lub 
=0 (Niepowodzenie). Jeżeli VU otrzyma więcej niż trzy 
odpowiedzi równe 0 lub jeżeli VU nie otrzyma komuni­
katu RCDT Data Acknowledgment w odniesieniu do 
konkretnego wysłanego wcześniej polecenia z określonym 
DataTransactionId, VU wygeneruje i zarejestruje 
zdarzenie;  
—
 komunikat 
jest wysyłane przez VU do DSRC-VU w celu zakoń­
czenia łącza w odniesieniu do konkretnego LinkIdentifier.  
DSC_76 Po ponownym uruchomieniu DSRC-VU lub VU wszystkie 
istniejące łącza komunikacyjne należy usunąć, ponieważ 
w związku z nagłym zamknięciem VU mogą wystąpić 
„zawieszone” łącza.  
—
 jest wysy­ 
łane przez DSRC-VU do VU w celu potwierdzenia 
żądania zakończenia łącza przez VU w odniesieniu do 
konkretnego LinkIdentifier.  
5.7 Obs ługa błędów 
5.7.1  Rejestrowanie i przekazywanie danych w DSRC-VU  
▼M3 
DSC_77 Już zabezpieczone  Dane  są przekazywane  DSRC-VU  za 
pomocą funkcji  VUSM  . VUSM  sprawdza, czy dane zareje­
strowane w  DSRC-VU  zostały z powodzeniem przesłane do 
DSRC-VU. Rejestrowanie i zgłaszanie wszelkich błędów, 
jakie wystąpiły podczas przesyłania danych z  VU do pamięci  
DSRC-VU , odbywa się przy użyciu zdarzenia typu Even­
tFaultType z wartością enum ustawioną na „0C”H Błąd łącz­
ności z urządzeniem do łączności na odległość wraz ze znacz­
nikiem czasu.  VUSM  sprawdza, czy dane zostały z powodze­
niem przesłane do DSRC-VU.  
DSC_78 Zarezerwowane dla przyszłego użytku  
▼B 
DSC_79 Jeżeli VUPM próbuje uzyskać dane VU z modułu zabezpie­
czeń (w celu przejścia do urządzenia VU-DSRC), ale kończy 
się to niepowodzeniem, wówczas rejestruje takie niepowo­
dzenie jako zdarzenie typu EventFaultType z wartością 
enum  „62”H B łąd łączności z urządzeniem do łączności na 
odległość wraz ze znacznikiem czasu. Błąd związany z łączno­ 
ścią zostaje wykryty w przypadku nieotrzymania komunikatu  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 584
  
dotyczącego powiązanego (tj. 
z tym samym DataTransactionId w komunikatach
  
) komunikatu
  
więcej niż trzy razy 
z rzędu.  
5.7.2  Błędy łączności bezprzewodowej  
DSC_80 Obsługa błędów związanych z łącznością jest zgodna z pow ią­
zanymi normami dotyczącymi DSRC, mianowicie EN 300 
674-1, EN 12253, EN 12795, EN 12834 i odpowiednimi 
parametrami normy EN 13372.  
5.7.2.1  Błędy szyfrowania i b łędy podpisu  
DSC_81 Błędy szyfrowania i podpisu obsługuje się zgodnie z doda t­
kiem 11 „Wspólne mechanizmy zabezpieczenia”, przy czym 
błędy te nie występują w żadnych komunikatach o błędzie 
związanych z przesyłaniem danych DSRC.  
5.7.2.2  Rejestrowanie b łędów 
Urządzenie DSRC umożliwia dynamiczną łączność bezprzewodową 
w środowisku z niepewnymi warunkami atmosferycznymi i zakłóce­
niami, zwłaszcza w przypadku kombinacji „przenośny REDCR” 
i „pojazd w ruchu” występujących w tej aplikacji. Konieczne jes t 
zatem ustalenie różnicy między „niepowodzeniem odczytu” a „błęd em”. 
Podczas transakcji zachodzącej przez interfejs bezprzewodowy ni epowo­
dzenie odczytu jest zjawiskiem powszechnym, a jego skutkiem jes t 
zwykle ponowienie próby, tj. reemisja BST i ponowna próba sekwe ncji, 
które w większości przypadków doprowadzą do skutecznego nawiąza nia 
łączności i przesłania danych, chyba że docelowy pojazd wyjedzi e poza 
zasięg urządzenia w czasie wymaganym do przeprowadzenia ponowne j 
transmisji. (Przypadek „skutecznego odczytu” może obejmować kil ka 
prób i ponowień).  
Niepowodzenie odczytu może być spowodowane niewłaściwym sparo­
waniem anteny (błąd „celowania”); faktem, że jedna z anten jest  zasło­
nięta – może to być celowe, ale może być też spowodowane fizycz ną 
obecnością innego pojazdu; zakłóceniami radiowymi, szczególnie 
w systemie łączności bezprzewodowej działającym na częstotliwoś ci 
około 5,8 GHz lub w innych systemach publicznej łączności bezpr ze­
wodowej lub może być spowodowane zakłóceniem radarowym lub trud ­
nymi warunkami atmosferycznymi (np. w trakcie burzy); lub po pr ostu 
faktem, że pojazd wyjechał poza obszar objęty zasięgiem łącznoś ci 
DSRC. Poszczególnych przypadków niepowodzenia odczytu, ze 
względu na ich charakter, nie można zarejestrować po prostu dla tego, 
że nie doszło do nawiązania łączności.  
Jeżeli przedstawiciel właściwego organu kontrolnego wybiera poj azd 
i podejmuje próbę skierowania zapytania do jego  DSRC-VU , jednak 
nie dochodzi do skutecznego przesłania danych, usterka taka mog ła 
nastąpić w wyniku celowego manipulowania, w związku z czym prze d­
stawiciel właściwego organu kontrolnego potrzebuje środka, aby móc 
wprowadzić usterkę do rejestru i ostrzec współpracowników znajd ują­
cych się na dalszym etapie łańcucha o możliwym naruszeniu. Wspó ł­
pracownicy mogą wówczas zatrzymać pojazd i przeprowadzić kontro lę 
fizyczną. W związku z tym, że nie nawiązano łączności, DSRC-VU nie 
może jednak dostarczyć danych dotyczących usterki. Przekazywani e 
tego rodzaju sprawozdań powinno być zatem funkcją projektu urzą ­
dzenia REDCR.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 585  
„Niepowodzenie odczytu” różni się pod względem technicznym od 
„błędu”. W tym kontekście „błąd” oznacza pozyskanie błędnej war tości.  
Dane przesłane do  DSRC-VU  są dostarczane w postaci już zabezpie­
czonej, dlatego muszą zostać zweryfikowane przez dostawcę danyc h 
(zob. pkt 5.4).  
Dane przesłane następnie przez interfejs radiowy są sprawdzane 
w ramach cyklicznej kontroli nadmiarowej na poziomie łączności.  Jeżeli 
dane zostaną zatwierdzone w ramach CRC, oznacza to, że są popra wne. 
Jeżeli dane nie zostaną zatwierdzone w ramach CRC, oznacza to r etrans­
misję danych. Prawdopodobieństwo, że niepoprawne dane pomyślnie  
przejdą CRC, jest statystycznie na tyle znikome, że można je po minąć.  
Jeżeli dane nie zostaną zatwierdzone w ramach CRC i nie ma czas u na 
retransmisję i otrzymanie poprawnych danych, wówczas rezultatem  nie 
będzie błąd, lecz wystąpienie określonego typu niepowodzenia od czytu.  
Jedyne znaczące dane na temat „usterki”, które można zarejestro wać, 
dotyczą liczby udanych inicjacji transakcji, które z kolei nie skutkują 
skutecznym przesłaniem danych do REDCR.  
DSC_82 REDCR rejestruje zatem z sygnaturą czasową liczbę przy­
padków, gdy faza „inicjowania” zapytania DSRC przebiegła 
pomyślnie, ale transakcja zakończyła się, zanim REDCR 
pomyślnie pobrał  Dane . Dane te są udostępniane przedstawi­
cielowi właściwego organu kontrolnego i przechowywane 
w pamięci urządzenia REDCR. Środkiem pozwalającym na 
osiągnięcie tego celu jest kwestia projektu produktu lub 
specyfikacja właściwego organu kontrolnego.  
Jedyne znaczące dane na temat „błędów”, które można zareje­
strować, dotyczą liczby przypadków, gdy REDCR nie udało 
się deszyfrować otrzymanych  Danych . Należy jednak 
zauważyć, że będzie to dotyczyło wyłącznie wydajności opro­
gramowania REDCR. Dane można technicznie deszyfrować, 
ale będą pozbawione sensu pod względem semantycznym.  
DSC_83  REDCR  rejestruje zatem z sygnaturą czasową liczbę podję­
tych prób deszyfrowania danych otrzymanych przez interfejs 
DSRC, które zakończyły się niepowodzeniem.  
6 TESTY PRZEPROWADZANE PRZY ODDANIU DO EKSPLOA­
TACJI ORAZ TESTY W RAMACH PRZEGLĄDÓW OKRESOWYCH 
FUNKCJI ŁĄCZNOŚCI NA ODLEGŁOŚĆ  
6.1 Uwagi ogólne  
DSC_84 Przewiduje się dwa rodzaje testów w odniesieniu do funkc ji 
łączności na odległość:  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 586  
1) test ECHO w celu zatwierdzania kanału łączności  bezprze­
wodowej DSRC-REDCR  >>-:-< DSRC-VU;  
2) test bezpieczeństwa typu  end-to-end  przeprowadzany 
w celu zapewnienia, aby karta warsztatowa była w stanie 
uzyskać dostęp do zaszyfrowanych i podpisanych danych 
utworzonych przez VU i przesyłanych za pośrednictwem 
kanału komunikacji bezprzewodowej.  
6.2 ECHO  
Niniejsza klauzula zawiera postanowienia, które mają służyć wył ącznie 
sprawdzeniu, czy połączenie  DSRC-REDCR  >>-:-< DSRC-VU  jest 
aktywne.  
Celem polecenia ECHO jest umożliwienie warsztatom lub placówkom  
przeprowadzających testy na potrzeby homologacji typu zbadania,  czy 
połączenie DSRC działa bez konieczności dostępu do poświadczeń 
zabezpieczenia; Urządzenie testera musi być jedynie w stanie za ini­
cjować łączność DSRC (wysłanie BST z AID=2), a następnie wysłać  
polecenie ECHO i – zakładając, że DSRC pracuje – otrzymać odpo­
wiedź ECHO. Więcej szczegółowych informacji można znaleźć w pkt  
5.4.8. Zakładając, że otrzyma tę odpowiedź prawidłowo, łącze DS RC 
(DSRC-REDCR  >>-:-< DSRC-VU ) można zatwierdzić jako funkcjonujące 
poprawnie.  
6.3 Testy maj ące na celu zatwierdzanie tre ści zabezpieczonych danych  
DSC_85 Tego rodzaju test wykonuje się w celu zatwierdzenia 
bezpiecznych przepływów danych typu end-to-end. Do prze­
prowadzenia takiego testu niezbędny jest czytnik testowy 
DSRC. Czytnik testowy DSRC wykonuje te same funkcje 
i jest wdrażany z tą samą specyfikacją co czytnik wykorzy­
stywany przez przedstawiciela organów ścigania z taką 
różnicą, że to karta warsztatowa jest wykorzystywana do 
uwierzytelniania użytkownika czytnika testowego DSRC, 
a nie karta kontrolna. Test można przeprowadzić po począt­
kowej aktywacji tachografu inteligentnego lub pod koniec 
procedury kalibracji. Po aktywacji przyrząd rejestrujący gene­
ruje zabezpieczone dane dotyczące wczesnego wykrywania 
i przekazuje je do DSRC-VU.  
DSC_86 Pracownicy warsztatu muszą umieścić czytnik testowy DSRC  
w odległości od 2 do 10 m od przodu pojazdu.  
DSC_87 Następnie pracownicy warsztatu włożą kartę warsztatową d o 
czytnika testowego DSRC w celu przekazania przyrządowi 
rejestrującemu zapytania o przekazanie danych dotyczących 
wczesnego wykrywania. Po pomyślnym zapytaniu pracow­
nicy warsztatu uzyskają dostęp do otrzymanych danych 
w celu upewnienia się, że zostały one pomyślnie zatwier­
dzone pod względem integralności i deszyfrowane.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 587  
Addendum  
Zasady obliczania dziennego, tygodniowego i dwutygodniowego cza su prowa­
dzenia pojazdu  
1. Podstawowe zasady dokonywania obliczeń  
VU oblicza dzienny czas prowadzenia pojazdu, tygodniowy czas pr owadzenia 
pojazdu i dwutygodniowy czas prowadzenia pojazdu z wykorzystani em odpo­
wiednich danych zapisanych na karcie kierowcy (lub warsztatowej ) włożonej 
do szczeliny czytnika karty kierowcy (szczelina 1, czytnik kart y #1) przyrządu 
rejestrującego oraz wybranych czynności kierowcy w okresie, w k tórym karta 
ta pozostaje włożona do VU.  
Czasów prowadzenia pojazdu nie wlicza się, gdy żadna karta kier owcy (lub 
warsztatowa) nie jest włożona.  
Wszystkie okresy NIEOKREŚLONE wykryte w obrębie okresu potrzebn ego 
do obliczeń zalicza się do okresu PRZERWA/ODPOCZYNEK.  
Nie uwzględnia się NIEOKREŚLONYCH okresów oraz czynności o ujem nym 
czasie trwania (tzn. gdy początek czynności następuje później n iż koniec 
czynności) wynikających z nakładania się czasów dwóch różnych p rzyrządów 
rejestrujących lub z korekty czasu.  
Czynności zarejestrowane na karcie kierowcy odpowiadające okres om „POZA 
ZAKRESEMS”, zgodnie z definicją w lit. gg) w załączniku IC, int erpretuje 
się w następujący sposób:  
— Okresy PRZERWA/ODPOCZYNEK liczy się jak „PRZERWĘ” lub 
„ODPOCZYNEK”.  
— Okresy PRACA i PROWADZENIE uznaje się za „PRACĘ”.  
— Okres GOTOWOŚĆ uznaje się za „GOTOWOŚĆ”.  
W kontekście niniejszego addendum VU zakłada dzienny okres odpo czynku 
na początku rekordów czynności na karcie.  
2. Pojęcia  
Poniższe pojęcia mają zastosowanie wyłącznie do niniejszego dod atku i mają 
na celu określenie sposobu obliczania przez VU czasu prowadzeni a pojazdu 
i jego późniejszej transmisji przez urządzenie łączności na odl egłość.  
a) „zmiana RTM” oznacza okres między końcem danego dziennego ok resu 
odpoczynku a końcem bezpośrednio następującego po nim dziennego  
okresu odpoczynku.  
VU uruchamia nową zmianę RTM po zakończeniu dziennego okresu 
odpoczynku.  
Trwająca zmiana RTM jest okresem od końca ostatniego dziennego okresu 
odpoczynku;  
b) „skumulowany czas prowadzenia pojazdu” oznacza sumę czasu tr wania 
wszystkich czynności PROWADZENIA wykonywanych przez kierowcę 
w okresie innym niż okres stanu POZA ZAKRESEM;  
c) „dzienny czas prowadzenia pojazdu” oznacza skumulowany czas prowa­
dzenia pojazdu w ramach zmiany RTM;  
d) „tygodniowy czas prowadzenia pojazdu” oznacza skumulowany cz as 
prowadzenia pojazdu w trwającym tygodniu;  
e) „nieprzerwany okres odpoczynku” oznacza nieprzerwany okres 
PRZERWA/ODPOCZYNEK;  
f) „tygodniowy czas prowadzenia pojazdu” oznacza skumulowany cz as 
prowadzenia pojazdu w poprzednim i trwającym tygodniu;  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 588  
g) „dzienny okres odpoczynku” oznacza okres PRZERWA/ODPOCZYNEK,  
który może być:  
— regularnym dziennym okresem odpoczynku,  
— dzielonym dziennym okresem odpoczynku lub  
— skróconym dziennym okresem odpoczynku.  
W kontekście dodatku 14, gdy VU oblicza tygodniowe okresy odpo­
czynku, okresy te uznaje się za dzienne okresy odpoczynku;  
h) „regularny dzienny okres odpoczynku” oznacza nieprzerwany ok res odpo­
czynku trwający co najmniej 11 godzin.  
W drodze wyjątku, jeżeli stan PRZEPRAWA PROMOWA/POCIĄGOWA 
jest aktywny, to regularny dzienny okres odpoczynku może zostać  prze­
rwany maksymalnie dwa razy czynnościami innymi niż odpoczynek, 
o maksymalnym skumulowanym czasie trwania wynoszącym jedną 
godzinę, tzn. regularny dzienny okres odpoczynku zawierający ok resy 
przepraw promowych/pociągowych można podzielić na dwie lub trzy  
części. VU zlicza następnie regularny dzienny okres odpoczynku,  gdy 
skumulowany czas odpoczynku obliczony zgodnie z pkt 3 wynosi co  
najmniej 11 godzin.  
W przypadku przerwania regularnego dziennego okresu odpoczynku przy­
rząd rejestrujący:  
— nie uwzględnia czynności prowadzenia pojazdu zaistniałych pod czas 
tych przerw w obliczeniach dziennego czasu prowadzenia pojazdu oraz 
— rozpoczyna nową zmianę RTM z końcem regularnego dziennego 
okresu odpoczynku, który został przerwany.  
Rysunek 1.  
Przykład dziennego okresu odpoczynku przerwanego w zwi ązku z przepraw ą promow ą/pociągową
 
i) „skrócony dzienny okres odpoczynku” oznacza nieprzerwany okr es odpo­
czynku trwający co najmniej 9 godzin, ale mniej niż 11 godzin;  
j) „dzielony dzienny okres odpoczynku” oznacza dzienny okres od poczynku 
wykorzystywany w dwóch częściach:  
— pierwsza część to nieprzerwany okres odpoczynku trwający co 
najmniej 3 godziny, ale mniej niż 9 godzin;  
— druga część to nieprzerwany okres odpoczynku trwający co najm niej 
9 godzin.  
W drodze wyjątku, jeżeli stan PRZEPRAWA PROMOWA/POCIĄGOWA 
jest aktywny podczas jednej lub obu części dzielonego dziennego  okresu 
odpoczynku, okres ten może zostać przerwany maksymalnie dwa raz y 
czynnościami innymi niż odpoczynek, o maksymalnym skumulowanym 
czasie trwania wynoszącym jedną godzinę, tzn.:  
— pierwszą część dzielonego dziennego okresu odpoczynku można p rze­
rwać jeden raz bądź dwa razy lub  
— drugą część dzielonego dziennego okresu odpoczynku można prze rwać 
jeden raz bądź dwa razy lub  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 589  
— pierwszą część dzielonego dziennego okresu odpoczynku można p rze­
rwać jeden raz i drugą część dzielonego dziennego okresu odpocz ynku 
można przerwać jeden raz.  
VU zlicza następnie dzielony dzienny okres odpoczynku, gdy skum ulo­
wany czas odpoczynku obliczony zgodnie z pkt 3 wynosi:  
— co najmniej trzy godziny, ale mniej niż 11 godzin dla pierwsz ego 
okresu odpoczynku, oraz co najmniej 9 godzin dla drugiego okres u 
odpoczynku, jeżeli pierwszy okres odpoczynku został przerwany 
przez PRZEPRAWĘ PROMOWĄ/POCIĄGOWĄ;  
— co najmniej trzy godziny, ale mniej niż 9 godzin dla pierwsze go okresu 
odpoczynku, oraz co najmniej 9 godzin dla drugiego okresu odpo­
czynku, jeżeli pierwszy okres odpoczynku nie został przerwany p rzez 
PRZEPRAWĘ PROMOWĄ/POCIĄGOWĄ.  
Rysunek 2.  
Przykład dzielonego dziennego okresu odpoczynku przerwanego w zwi ązku z przepraw ą promow ą/pocią­
gową
 
W przypadku dzielonego dziennego okresu odpoczynku przyrząd rej estru­
jący:  
— nie uwzględnia czynności prowadzenia pojazdu zaistniałych pod czas 
tych przerw w obliczeniach dziennego czasu prowadzenia pojazdu oraz 
— rozpoczyna nową zmianę RTM z końcem dzielonego dziennego okre su 
odpoczynku, który został przerwany;  
k) „tydzień” oznacza okres w czasie UTC od godz. 00.00 w ponied ziałek do 
godz. 24:00 w niedzielę.  
3. Obliczanie dziennego okresu odpoczynku przerwanego w związku  z przeprawą 
promową/pociągową  
W celu obliczenia okresu odpoczynku, który został przerwany w z wiązku 
z przeprawą promową/pociągową, VU liczy skumulowany czas odpocz ynku 
zgodnie z następującymi krokami:  
a) Krok 1  
VU wykrywa przerwy w czasie odpoczynku, które wystąpiły przed a kty­
wacją flagi PRZEPRAWA PROMOWA/POCIĄGOWA (POCZĄTEK), 
zgodnie z rys. 3 i w stosownych przypadkach rys. 4, oraz ocenia  w odnie­
sieniu do każdej wykrytej przerwy, czy spełnione są następujące  warunki:  
— przerwa powoduje, że całkowity czas trwania wykrytych przerw,  
w tym w stosownych przypadkach przerw następujących w trakcie 
pierwszej części dzielonego dziennego okresu odpoczynku w związ ku 
z przeprawą promową/pociągową, przekracza łącznie ponad jedną 
godzinę,  
— przerwa powoduje, że całkowita liczba wykrytych przerw, w tym  
w stosownych przypadkach przerw następujących w trakcie pierwsz ej 
części dzielonego dziennego okresu odpoczynku w związku z prze­
prawą promową/pociągową, jest wyższa niż dwa,  
— po zakończeniu przerwy przechowywany jest „Wpis miejsca zakoń ­
czenia dziennego okresu pracy”.  
Jeżeli żaden z powyższych warunków nie jest spełniony, nieprzer wany 
okres odpoczynku bezpośrednio poprzedzający przerwę dodaje się do 
skumulowanego czasu odpoczynku.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 590  
Jeżeli spełniony jest co najmniej jeden z powyższych warunków, VU musi 
zatrzymać obliczanie skumulowanego czasu odpoczynku zgodnie z k rokiem 
2 lub wykryć przerwy w czasie odpoczynku następujące po fladze PRZE­
PRAWA PROMOWA/POCIĄGOWA (POCZĄTEK) zgodnie z krokiem 3.  
b) Krok 2  
W odniesieniu do każdej przerwy wykrytej zgodnie z krokiem 1 VU  
ocenia, czy należy zaprzestać obliczania skumulowanego czasu od po­
czynku. VU zatrzymuje proces obliczeniowy, jeżeli do skumulowan ego 
czasu odpoczynku dodano dwa okresy nieprzerwanego odpoczynku, 
które nastąpiły przed aktywacją flagi PRZEPRAWA PROMOWA/POCIĄ­
GOWA (POCZĄTEK), w tym w stosownych przypadkach okresy odpo­
czynku dodane do pierwszej części dzielonego dziennego okresu o dpo­
czynku również przerwanego w związku z przeprawą promową/pocią­
gową. W przeciwnym razie VU postępuje zgodnie z krokiem 3.  
c) Krok 3  
Jeżeli po wykonaniu kroku 2 VU kontynuuje obliczanie skumulowan ego 
czasu odpoczynku, wykrywa przerwy następujące po dezaktywacji s tanu 
PRZEPRAWA PROMOWA/POCIĄGOWA zgodnie z rys. 3 i w stosow­
nych przypadkach rys. 4.  
W odniesieniu do każdej wykrytej przerwy VU ocenia, czy przerwa  powo­
duje, że całkowity czas wszystkich wykrytych przerw przekracza łącznie 
ponad jedną godzinę, w którym to przypadku obliczanie skumulowa nego 
okresu odpoczynku ustaje z końcem nieprzerwanego okresu odpoczy nku 
poprzedzającego przerwę. W przeciwnym razie do obliczeń dzienne go 
okresu odpoczynku dodaje się nieprzerwane okresy odpoczynku nas tępu­
jące po odpowiednich przerwach, aż do spełnienia warunku z krok u 4. 
d) Krok 4  
Obliczanie skumulowanego czasu odpoczynku zatrzymuje się po dod aniu 
przez VU, w rezultacie zastosowania kroków 1 i 3, maksymalnie d wóch 
nieprzerwanych okresów odpoczynku do okresu odpoczynku, w odnie sieniu 
do którego aktywowany jest stan PRZEPRAWA PROMOWA/POCIĄ­
GOWA, w tym w stosownych przypadkach przerw następujących w tra kcie 
pierwszej części dzielonego dziennego okresu odpoczynku w związ ku 
z przeprawą promową/pociągową.  
Rysunek 3.  
Przetwarzanie czasów odpoczynku przez VU w celu ustalenia, czy przerwany okres odpoczynku liczy si ę 
jako regularny dzienny okres odpoczynku, czy jako pierwsz ą część dzielonego dziennego okresu odpo ­
czynku
  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 591  
Rysunek 4.  
Przetwarzanie czasów odpoczynku przez VU w celu ustalenia, czy przerwany okres odpoczynku liczy si ę 
jako drug ą część dzielonego dziennego okresu odpoczynku
  
Rysunek 5.  
Przykład dziennego okresu odpoczynku przerwanego wi ęcej niż dwukrotnie, co powoduje, że okresu odpo ­
czynku H nie uwzgl ędnia się w obliczeniach
  
Rysunek 6.  
Przykład dziennego okresu odpoczynku, w którym okres obliczeniowy prom/poci ąg rozpoczyna si ę 
z końcem okresu pracy
  
Rysunek 7.  
Przykład dziennego okresu odpoczynku przerwanego wi ęcej niż dwukrotnie, co powoduje, że okresu odpo ­
czynku B nie uwzgl ędnia się w obliczeniach
  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 592  
Rysunek 8.  
Przykład dzielonego dziennego okresu odpoczynku przerwanego jeden raz w trakcie pierwszego okresu 
odpoczynku i jeden raz w trakcie drugiego okresu odpoczynku
  
4. Obliczanie dziennego, tygodniowego i dwutygodniowego czasu p rowadzenia 
pojazdu  
VU oblicza dzienne czasy prowadzenia pojazdu dla trwających i p oprzednich 
zmian RTM. Czasu prowadzenia pojazdu następującego podczas prze rw 
w dziennych okresach odpoczynku nie dodaje się do obliczeń dzie nnego 
czasu prowadzenia pojazdu, jeżeli takie przerwy wynikają z prze prawy 
promowej/pociągowej, a wymogi określone w pkt 2 lit. h) i j) or az w pkt 3 
zostały spełnione. Niemniej jednak, o ile VU nie policzył pełne go regularnego 
lub dzielonego dziennego okresu odpoczynku zgodnie z pkt 3, cza sy prowa­
dzenia pojazdu następujące podczas przerw dodaje się do dzienne go czasu 
prowadzenia pojazdu dla trwającej zmiany RTM.  
VU liczy również tygodniowe i dwutygodniowe czasy prowadzenia p ojazdu. 
Czas prowadzenia pojazdu następujący podczas przerw w dziennych  okresach 
odpoczynku wynikających z przeprawy promowej/pociągowej dodaje się do 
obliczeń tygodniowych i dwutygodniowych czasów prowadzenia poja zdu. ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 593  
Dodatek 15  
MIGRACJA: ZARZ ĄDZANIE WSPÓ ŁISTNIENIEM GENERACJI 
URZĄDZEŃ 
▼B 
SPIS TREŚCI  
1. DEFINICJE  
2. PRZEPISY OGÓLNE  
2.1. Informacje ogólne na temat przejścia  
▼M3 
2.2. Interoperacyjność między VU a kartami  
▼B 
2.3. Interoperacyjność między VU a czujnikami ruchu  
2.4. Interoperacyjność między przyrządami rejestrującymi, karta mi do tacho­ 
grafu i urządzeniami służącymi do pobierania danych  
2.4.1 Bezpośrednie pobieranie danych z karty przez inteligentne  urządzenia 
dedykowane  
2.4.2 Pobieranie danych z karty za pomocą przyrządu rejestrując ego 
2.4.3 Pobieranie danych z przyrządów rejestrujących  
2.5. Interoperacyjność między VU a urządzeniami do kalibracji  
3. GŁÓWNE DZIAŁANIA W OKRESIE POPRZEDZAJĄCYM DATĘ 
WPROWADZENIA  
4. PRZEPISY DOTYCZĄCE OKRESU PO DACIE WPROWADZENIA  
▼M3 
5. REJESTROWANIE PRZEKROCZEŃ GRANICY W TACHOGRAFACH 
PIERWSZEJ GENERACJI I PIERWSZEJ WERSJI DRUGIEJ GENE­ 
RACJI  
▼B 
1. DEFINICJE  
Do celów niniejszego dodatku stosuje się następujące definicje:  
system tachografu inteligentnego:  zgodnie z definicją zawartą w niniej­
szym załączniku (rozdział 1: definicja bbb));  
system tachografu pierwszej generacji:  zgodnie z definicją zawartą 
w niniejszym rozporządzeniu (art. 2: definicja 1));  
system tachografu drugiej generacji:  zgodnie z definicją zawartą 
w niniejszym rozporządzeniu (art. 2: definicja 7));  
data wprowadzenia:  zgodnie z definicją zawartą w niniejszym załączniku 
(rozdział 1: definicja ccc));  
inteligentne urz ądzenie dedykowane (IDE):  urządzenie służące do prze­
prowadzania operacji pobierania danych, zgodnie z definicją zaw artą 
w dodatku 7 do niniejszego załącznika.  
▼M3 
2. PRZEPISY OGÓLNE  
2.1. Informacje ogólne na temat przej ścia 
Wprowadzenie do niniejszego załącznika zawiera ogólne informacj e na 
temat przejścia między systemami tachografu pierwszej i drugiej  generacji 
oraz wprowadzenia drugiej wersji drugiej generacji urządzeń rej estrują­
cych i kart do tachografów.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 594  
Oprócz przepisów zawartych w tym wprowadzeniu należy przypomnie ć 
następujące informacje:  
— czujniki ruchu pierwszej generacji nie są interoperacyjne z ż adną 
wersją przyrządów rejestrujących drugiej generacji,  
— w pojazdach wyposażonych w dowolną wersję przyrządów rejestru ją­
cych drugiej generacji można instalować wyłącznie czujniki ruch u 
drugiej generacji,  
— urządzenia do pobierania i kalibracji danych muszą umożliwiać  korzy­
stanie z obu generacji lub wersji urządzeń rejestrujących i kar t do 
tachografów.  
2.2. Interoperacyjno ść między VU a kartami  
Przyjmuje się, że karty do tachografu pierwszej generacji są in teropera­
cyjne z przyrządami rejestrującymi pierwszej generacji (zgodnie  z załącz­
nikiem IB do rozporządzenia (EWG) nr 3821/85), natomiast karty do 
tachografu dowolnej wersji drugiej generacji są interoperacyjne  z przyrzą­
dami rejestrującymi dowolnej wersji drugiej generacji (zgodnie z załączni­
kiem IC do niniejszego rozporządzenia). Ponadto zastosowanie ma ją 
przedstawione poniżej wymogi.  
MIG_001 Z wyjątkiem treści wymogów MIG_004 i MIG_005, karty do 
tachografu pierwszej generacji mogą być nadal używane 
w dowolnej wersji przyrządów rejestrujących drugiej generacji 
do upływu daty ich ważności. Właściciele takich kart mogą 
jednak wystąpić z wnioskiem o ich wymianę na karty do 
tachografu drugiej generacji, jak tylko te drugie karty staną 
się dostępne.  
MIG_002 Przyrządy rejestrujące dowolnej wersji drugiej generacj i 
muszą być w stanie obsługiwać każdą włożoną ważną kartę 
kierowcy, kartę kontrolną oraz kartę firmową pierwszej 
generacji.  
MIG_003 Warsztaty mogą raz na zawsze pozbawić przyrządy rejestr u­
jącej tej funkcji, tak aby karty do tachografu pierwszej gene­
racji nie mogły być już dłużej akceptowane. Może to nastąpić 
dopiero po wszczęciu przez Komisję Europejską stosownej 
procedury, w ramach której zwróci się ona do warsztatów 
o podjęcie takich działań, np. w ramach każdego przeglądu 
okresowego tachografu.  
MIG_004 Przyrządy rejestrujące drugiej generacji muszą być w st anie 
obsługiwać wyłącznie karty warsztatowe drugiej generacji.  
MIG_005 Do celów określania trybu pracy przyrządy rejestrujące 
dowolnej wersji drugiej generacji rozpoznają wyłącznie typy 
włożonych ważnych kart, bez względu na ich generację lub 
wersję.  
MIG_006 Każda ważna karta do tachografu dowolnej wersji drugiej  
generacji musi umożliwiać jej zastosowanie w przyrządach 
rejestrujących pierwszej generacji w dokładnie taki sam 
sposób jak karty do tachografu pierwszej generacji tego 
samego typu.  
2.3. Interoperacyjno ść między VU a czujnikami ruchu  
Przyjmuje się, że czujniki ruchu pierwszej generacji są interop eracyjne 
z przyrządami rejestrującymi pierwszej generacji, natomiast czu jniki 
ruchu drugiej generacji są interoperacyjne z przyrządami rejest rującymi 
dowolnej wersji drugiej generacji. Ponadto zastosowanie mają pr zedsta­
wione poniżej wymogi.  
MIG_007 Przyrządów rejestrujących dowolnej wersji drugiej gener acji 
nie można parować ani używać z czujnikami ruchu pierwszej 
generacji.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 595  
MIG_008 Czujniki ruchu drugiej generacji można parować i używać  
wyłącznie z przyrządami rejestrującymi drugiej generacji, 
bez względu na wersję, lub z obiema generacjami przyrządów 
rejestrujących.  
2.4. Interoperacyjno ść między przyrz ądami rejestruj ącymi, kartami do 
tachografu i urz ądzeniami s łużącymi do pobierania danych  
MIG_009 Urządzenia do pobierania danych mogą być kompatybilne z e 
wszystkimi generacjami i wersjami przyrządów rejestrujących 
i kart do tachografów.  
2.4.1.  Bezpośrednie pobieranie danych z karty przez inteligentne urz ądzenia 
dedykowane  
MIG_010 Inteligentne urządzenia dedykowane pobierają dane z kar t do 
tachografu danej generacji włożonych do ich czytników kart 
z zastosowaniem mechanizmów zabezpieczenia i protokołu 
pobierania danych tej generacji, a pobierane dane mają format 
zdefiniowany dla danej generacji i wersji.  
MIG_011 Aby organy kontrolne spoza UE mogły kontrolować 
kierowców, należy umożliwić pobieranie danych z kart 
kierowców (i kart warsztatowych) drugiej generacji, bez 
względu na wersję, w dokładnie taki sam sposób, w jaki 
pobierane są dane z kart kierowców (i kart warsztatowych) 
pierwszej generacji. Tego rodzaju pobieranie obejmuje:  
— niepodpisane pliki elementarne IC i ICC (opcjonalnie),  
— niepodpisane pliki elementarne (pierwszej generacji) 
Card_Certificate i CA_Certificate,  
— pliki elementarne zawierające inne dane aplikacyjne 
(w pliku DF Tachograph) żądane przez protokół pobie­
rania danych z kart pierwszej generacji. Informacje takie 
muszą być zabezpieczone podpisem cyfrowym zgodnie 
z mechanizmami zabezpieczenia pierwszej generacji.  
Tego rodzaju pobieranie nie może obejmować plików 
elementarnych zawierających dane aplikacyjne istnieją­
cych wyłącznie w kartach kierowców (i kartach warsz­
tatowych) wersji 1 lub wersji 2 drugiej generacji (pliki 
elementarne zawierające dane aplikacyjne w pliku DF 
Tachograph_G2).  
2.4.2.  Pobieranie danych z karty za pomoc ą przyrządu rejestruj ącego  
MIG_012 Dane z dowolnej wersji karty drugiej generacji włożonej  do 
przyrządu rejestrującego pierwszej generacji są pobierane za 
pomocą protokołu pobierania danych pierwszej generacji. 
Karta taka odpowiada na polecenia przyrządu rejestrującego 
w dokładnie taki sam sposób jak karta pierwszej generacji, 
a pobierane dane mają taki sam format jak dane pobierane 
z karty pierwszej generacji.  
MIG_013 Dane z karty pierwszej generacji włożonej do przyrządu rejes­
trującego dowolnej wersji drugiej generacji są pobierane za 
pomocą protokołu pobierania danych określonego w dodatku 
7 do niniejszego załącznika. Przyrząd rejestrujący wysyła 
polecenia do karty w dokładnie taki sam sposób jak przyrząd 
rejestrujący pierwszej generacji, a pobierane dane mają format 
określony w odniesieniu do kart pierwszej generacji.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 596  
2.4.3.  Pobieranie danych z przyrz ądów rejestruj ących 
MIG_014 Poza ramami kontroli kierowców przez organ kontrolny sp oza 
UE dane z przyrządów rejestrujących drugiej generacji są 
pobierane z zastosowaniem mechanizmów zabezpieczenia 
drugiej generacji i protokołu pobierania danych określonego 
w dodatku 7 do niniejszego załącznika w odniesieniu do 
odpowiedniej wersji.  
MIG_015 Aby organy kontrolne spoza UE mogły kontrolować 
kierowców, opcjonalnie można również umożliwić pobieranie 
danych z przyrządów rejestrujących dowolnej wersji drugiej 
generacji z zastosowaniem mechanizmów zabezpieczenia 
pierwszej generacji. Pobierane dane mają wtedy taki sam 
format, jak dane pobierane z przyrządu rejestrującego pierw­
szej generacji. Funkcję tę można wybrać za pomocą poleceń 
w menu.  
2.5. Interoperacyjno ść między VU a urz ądzeniami do kalibracji  
MIG_016 Urządzenia do kalibracji muszą być w stanie przeprowadz ać 
kalibrację tachografów każdej generacji lub wersji, z zastoso­
waniem protokołu kalibracyjnego danej generacji lub wersji. 
Urządzenia do kalibracji mogą być kompatybilne ze wszyst­
kimi generacjami i wersjami przyrządów rejestrujących.  
3. GŁÓWNE DZIAŁANIA W OKRESIE POPRZEDZAJĄCYM DATĘ 
WPROWADZENIA  
MIG_017 Klucze testowe i certyfikaty muszą zostać udostępnione 
producentom najpóźniej z dniem publikacji niniejszego 
załącznika.  
MIG_018 Badania interoperacyjności muszą być gotowe do rozpoczę cia 
w odniesieniu do wersji 2 przyrządów rejestrujących i wersji 
2 kart do tachografów, na wniosek producentów, najpóźniej  
15 miesięcy przed datą wprowadzenia.  
MIG_019 W przypadku wersji 2 generacji 2 tachografów, kart do t acho­
grafów i czujników ruchu stosuje się te same klucze i certyfi­
katy, co w przypadku urządzeń wersji 1 generacji 2.  
MIG_020 Państwa członkowskie muszą być w stanie rozpocząć wyda­
wanie kart warsztatowych wersji 2 drugiej generacji najpóź­
niej 1 miesiąc przed datą wprowadzenia.  
MIG_021 Państwa członkowskie muszą być w stanie rozpocząć wyda­
wanie wszystkich innych typów wersji 2 drugiej generacji kart 
do tachografu najpóźniej  1 miesiąc przed datą wprowadzenia.  
4. PRZEPISY DOTYCZĄCE OKRESU PO DACIE WPROWADZENIA  
MIG_022 Po upływie daty wprowadzenia państwa członkowskie wydaj ą 
wyłącznie karty do tachografu wersji 2 drugiej generacji.  
MIG_023 Producenci przyrządów rejestrujących / czujników ruchu 
mogą produkować przyrządy rejestrujące / czujniki ruchu 
pierwszej generacji, dopóki są one wykorzystywane 
w danym obszarze, tak aby była możliwa wymiana niepra­
widłowo działających elementów składowych.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 597  
MIG_023a Ze skutkiem od daty wprowadzenia, nieprawidłowo działa jące 
przyrządy rejestrujące lub urządzenia zewnętrzne GNSS 
wersji 1 drugiej generacji zastępuje się przyrządami rejestru­
jącymi lub urządzeniami zewnętrznymi GNSS wersji 2 drugiej 
generacji.  
MIG_024 Producenci przyrządów rejestrujących / czujników ruchu 
mogą ubiegać się o utrzymanie homologacji typu oraz 
uzyskać zgodę na takie utrzymanie w przypadku pierwszej 
generacji przyrządów rejestrujących / czujników ruchu lub 
wersji 1 drugiej generacji przyrządów rejestrujących, posiada­
jących już homologację typu.  
5. REJESTROWANIE PRZEKROCZEŃ GRANICY W TACHOGRAFACH 
PIERWSZEJ GENERACJI I PIERWSZEJ WERSJI DRUGIEJ GENE­
RACJI  
MIG_025 Symbol kraju oraz, w stosownych przypadkach, regionu, d o 
którego kierowca wjeżdża po przekroczeniu granicy państwa 
członkowskiego zgodnie z art. 34 ust. 7 rozporządzenia (UE) 
nr 165/2014, wpisuje się jako miejsce, w którym rozpoczyna 
się dzienny okres pracy, zgodnie z ręcznym wprowadzaniem 
miejsc określonym w wymogu 60 w załączniku IC do rozpo­
rządzenia (UE) nr 165/2014 oraz wymogu 50 w załączniku IB 
do rozporządzenia (EWG) nr 3821/85.  ▼M3
 02016R0799 — PL — 21.08.2023 — 003.001 — 598  
Dodatek 16.  
ADAPTER DO POJAZDÓW KATEGORII M1 I N1  
SPIS TREŚCI  
1. SKRÓTY I DOKUMENTY REFERENCYJNE  
1.1. Skróty  
1.2. Normy referencyjne  
2. OGÓLNA CHARAKTERYSTYKA I FUNKCJE ADAPTERA  
2.1. Ogólny opis adaptera  
2.2. Funkcje  
2.3. Zabezpieczenie  
3. WYMAGANIA DOTYCZĄCE URZĄDZEŃ REJESTRUJĄCYCH 
W PRZYPADKU ZAMONTOWANIA ADAPTERA  
4. WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE 
W STOSUNKU DO ADAPTERA  
4.1. Odbiór i przetwarzanie wejściowych impulsów prędkości  
4.2. Przekazywanie odbieranych impulsów do wbudowanego czujnika  ruchu  
4.3. Wbudowany czujnik ruchu  
4.4. Wymogi bezpieczeństwa  
4.5. Parametry pracy  
4.6. Materiały  
4.7. Oznakowania  
5. INSTALACJA URZĄDZENIA REJESTRUJĄCEGO W PRZYPADKU 
ZASTOSOWANIA ADAPTERA  
5.1. Instalacja  
5.2. Plombowanie  
6. KONTROLE, PRZEGLĄDY I NAPRAWY  
6.1. Przeglądy okresowe  
7. HOMOLOGACJA TYPU URZĄDZENIA REJESTRUJĄCEGO W PRZY­ 
PADKU ZASTOSOWANIA ADAPTERA  
7.1. Uwagi ogólne  
7.2. Świadectwo funkcjonalności  
1. SKRÓTY I DOKUMENTY REFERENCYJNE  
1.1. Skróty  
TBD Do ustalenia  
VU Przyrząd rejestrujący  
1.2. Normy referencyjne  
ISO 16844-3 Pojazdy drogowe – Tachografy – Część 3: Podłączenie  
czujnika ruchu  
2. OGÓLNA CHARAKTERYSTYKA I FUNKCJE ADAPTERA  
2.1. Ogólny opis adaptera  
ADA_001 Adapter dostarcza podłączonemu do niego VU (przyrządowi  
rejestrującemu) w sposób pewny i ciągły dane o ruchu 
pojazdu, odwzorowujące jego prędkość i przebytą drogę.  
Adapter przeznaczony jest wyłącznie do pojazdów, które 
muszą być wyposażone w urządzenie rejestrujące zgodnie 
z niniejszym rozporządzeniem.  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 599  
Instaluje się go i używa wyłącznie w pojazdach określonych 
w definicji yy) „adapter” w załączniku IC, w których z mecha­
nicznego punktu widzenia niemożliwy jest montaż stosowa­
nych czujników ruchu innego rodzaju, pod innym względem 
zgodnych z wymaganiami przedstawionymi w niniejszym 
załączniku i w dodatkach 1–16 do niniejszego załącznika.  
Adapter nie może być mechanicznie sprzężony z ruchomą 
częścią pojazdu, lecz podłącza się go do impulsów prędkości/ 
przebytej drogi, które są generowane przez zintegrowane czuj­
niki lub alternatywne interfejsy.  
ADA_002 Czujnik ruchu posiadający homologację typu (zgodnie z p rze­
pisami niniejszego załącznika IC sekcja 8 – Homologacja typu 
dla urządzenia rejestrującego i kart do tachografów) umiesz­
czony jest w obudowie adaptera, gdzie znajduje się również 
przetwornik przekazujący odbierane impulsy do wbudowanego 
czujnika ruchu. Sam wbudowany czujnik ruchu jest podłą­
czony do VU w taki sposób, aby sprzężenie między VU a adap­
terem było zgodne z wymaganiami ISO16844-3.  
2.2. Funkcje  
ADA_003 Adapter realizuje następujące funkcje:  
— odbiór i adaptacja wejściowych impulsów pomiaru pręd­
kości;  
— przekazywanie odbieranych impulsów do wbudowanego 
czujnika ruchu;  
— wszystkie funkcje wbudowanego czujnika ruchu przekazują 
w sposób pewny dane o ruchu pojazdu do VU.  
2.3. Zabezpieczenie  
ADA_004 Adapter nie musi posiadać certyfikacji bezpieczeństwa z godnie 
z ogólnym celem zabezpieczenia czujnika ruchu określonym 
w dodatku 10 do niniejszego załącznika. Zastosowanie mają 
natomiast wymagania dotyczące zabezpieczenia określone 
w sekcji 4.4 niniejszego dodatku.  
3. WYMAGANIA DOTYCZĄCE URZĄDZEŃ REJESTRUJĄCYCH 
W PRZYPADKU ZAMONTOWANIA ADAPTERA  
Wymagania zawarte w kolejnych rozdziałach wskazują sposób, w ja ki 
należy rozumieć wymagania niniejszego załącznika w przypadku za stoso­
wania adaptera. W nawiasach podano odpowiednie numery poszczegó l­
nych wymagań załącznika IC.  
ADA_005 Urządzenie rejestrujące każdego pojazdu wyposażonego 
w adapter musi być zgodne ze wszystkimi przepisami niniej­
szego załącznika, chyba że w niniejszym dodatku przewidziano 
inaczej.  
ADA_006 W przypadku zainstalowania adaptera, na urządzenie reje stru­
jące składają się przewody, adapter (wraz z czujnikiem ruchu) 
oraz VU [01].  
ADA_007 Przepisy regulujące wykrywanie zdarzeń lub usterek urzą ­
dzenia rejestrującego otrzymują brzmienie:  
— zdarzenie „przerwa w zasilaniu” jest wyzwalane przez VU, 
o ile nie jest on w trybie kalibracyjnym, w przypadku 
każdej przerwy w zasilaniu wbudowanego czujnika ruchu 
przekraczającej 200 milisekund [79];  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 600  
— zdarzenie „błąd danych dotyczących ruchu” jest wyzwalane 
przez UV w przypadku przerwy w normalnym strumieniu 
danych między wbudowanym czujnikiem ruchu a VU lub 
w przypadku błędu spójności lub autentyczności danych, 
który występuje podczas wymiany danych między wbudo­
wanym czujnikiem ruchu a VU [83];  
— zdarzenie „próba naruszenia zabezpieczenia” jest wyzwa­
lane przez VU w przypadku każdego zdarzenia mającego 
wpływ na zabezpieczenie wbudowanego czujnika ruchu, 
o ile nie jest on w trybie kalibracyjnym [85];  
— usterka „urządzenie rejestrujące” jest wyzwalana przez VU, 
o ile nie jest on w trybie kalibracyjnym, w przypadku 
każdej usterki wbudowanego czujnika ruchu [88].  
ADA_008 Usterki adaptera wykrywalne przez urządzenie rejestrują ce to 
usterki związane z wbudowanym czujnikiem ruchu [88].  
ADA_009 Funkcja kalibracji VU pozwala na automatyczne sparowani e 
wbudowanego czujnika ruchu z VU [202, 204].  
4. WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE 
W STOSUNKU DO ADAPTERA  
4.1. Odbiór i przetwarzanie wej ściowych impulsów pr ędkości 
ADA_011 Interfejs wejściowy adaptera odbiera impulsy o częstotl iwości 
odwzorowującej prędkość i przebytą drogę. Własności elek­
tryczne impulsów wejściowych:  do ustalenia przez producenta . 
Prawidłowe sprzężenie wejścia adaptera z pojazdem umożli­
wiają w stosownych przypadkach regulacje, których może 
dokonać wyłącznie producent adaptera lub zatwierdzony 
warsztat montujący adapter.  
▼M3 
ADA_012 Interfejs wejściowy adaptera musi w stosownych przypadk ach 
mnożyć lub dzielić częstotliwość impulsów wejściowych pręd­
kości przez stałą wartość, aby dostosować sygnał do zakresu 
współczynnika k zdefiniowanego w niniejszym załączniku 
(od 2 400 do 25 000 impulsów/km). Wartość stałej może 
zaprogramować wyłącznie producent adaptera lub zatwier­
dzony warsztat instalujący adapter.  
▼B 
4.2. Przekazywanie odbieranych impulsów do wbudowanego czujnika 
ruchu  
ADA_013 Impulsy wejściowe, poddane ewentualnej adaptacji w spos ób 
opisany powyżej, przekazywane są do wbudowanego czujnika 
ruchu w taki sposób, że każdy wejściowy impuls wykrywany 
jest przez czujnik ruchu.  
4.3. Wbudowany czujnik ruchu  
ADA_014 Wbudowany czujnik ruchu stymulowany jest przez przekazy ­
wane impulsy, co pozwala mu na wytwarzanie danych o ruchu, 
dokładnie odwzorowujących ruch pojazdu w taki sposób, jakby 
był on mechanicznie sprzężony z ruchomą częścią pojazdu.  
ADA_015 VU wykorzystuje dane identyfikacyjne wbudowanego czujni ka 
ruchu do identyfikacji adaptera [95].  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 601  
ADA_016 Dane instalacyjne przechowywane we wbudowanym czujniku 
ruchu uważa się za dane instalacyjne adaptera [122].  
4.4. Wymogi bezpiecze ństwa  
ADA_017 Obudowa adaptera musi być wykonana w sposób uniemożli­
wiający jej otwarcie. Musi być zaplombowana, by łatwo można 
było wykryć próby fizycznej ingerencji (np. w drodze oglę­
dzin, zob. ADA_035). Plomby muszą spełniać te same wymogi 
co plomby czujników ruchu [398–406].  
ADA_018 Należy wykluczyć możliwość usunięcia wbudowanego czuj­
nika ruchu z adaptera bez naruszania plomb założonych na 
obudowę adaptera lub uszkodzenia plomb między czujnikiem 
a obudową adaptera (zob. ADA_034).  
ADA_019 Konstrukcja adaptera musi być taka, by dane o ruchu mog ły 
być przetwarzane i odbierane tylko z wejścia adaptera.  
4.5. Parametry pracy  
ADA_020 Adapter musi realizować wszystkie funkcje w zakresie te mpe­
ratur określonym przez producenta.  
ADA_021 Adapter musi realizować wszystkie funkcje w zakresie wi lgot­
ności od 10 % do 90 % [214].  
ADA_022 Adapter musi być zabezpieczony przed zbyt wysokim napię ­
ciem, odwróceniem biegunowości zasilania oraz przed zwar­
ciami [216].  
ADA_023 Adapter musi:  
— reagować na pole magnetyczne, które zakłóca wykrywanie 
ruchu pojazdu. W takich okolicznościach przyrząd rejestru­
jący zarejestruje i zapisze w pamięci usterkę czujnika [88]; 
albo 
— posiadać czujnik, który jest chroniony przed polami magne­
tycznymi lub odporny na nie [217].  
ADA_024 Adapter musi spełniać przepisy międzynarodowego regulam inu 
EKG ONZ nr 10, odnoszące się do kompatybilności elektro­
magnetycznej, jak również musi być zabezpieczony przed skut­
kami wyładowań elektrostatycznych oraz stanów nieustalonych 
[218].  
4.6. Materia ły 
ADA_025 Adapter musi spełniać wymagania odnośnie do stopnia 
ochrony  (do ustalenia przez producenta, zale żnie od miejsca 
instalacji)  [220, 221].  
ADA_026 Obudowa adaptera musi być żółta.  
4.7. Oznakowania  
ADA_027 Do adaptera musi być przymocowana tabliczka opisowa 
z następującymi danymi:  
— nazwa i adres producenta adaptera;  
— numer części producenta i rok produkcji adaptera;  
— znak homologacji typu dla adaptera lub urządzenia rejes­
trującego zawierającego adapter;  
— data instalacji adaptera;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 602  
— numer identyfikacyjny pojazdu, w którym zainstalowano 
dany adapter.  
ADA_028 Na tabliczce opisowej umieszcza się również następujące  dane, 
jeżeli nie można ich bezpośrednio odczytać z zewnątrz na 
wbudowanym czujniku ruchu:  
— nazwa producenta wbudowanego czujnika ruchu;  
— numer części producenta i rok produkcji wbudowanego 
czujnika ruchu;  
— znak homologacji wbudowanego czujnika ruchu.  
5. INSTALACJA URZĄDZENIA REJESTRUJĄCEGO W PRZYPADKU 
ZASTOSOWANIA ADAPTERA  
5.1. Instalacja  
ADA_029 Adaptery przeznaczone do zamontowania w pojazdach są 
montowane wyłącznie przez producentów pojazdów, bądź 
przez zatwierdzone warsztaty, upoważnione do instalacji, akty­
wacji oraz kalibracji tachografów cyfrowych i inteligentnych.  
ADA_030 Taki zatwierdzony warsztat instalujący adaptery musi do sto­
sować interfejs wejściowy oraz wybrać podzielnik wejścio­
wego sygnału (w stosownych przypadkach).  
ADA_031 Taki zatwierdzony warsztat instalujący adapter musi zap lom­
bować jego obudowę.  
ADA_032 Adapter montuje się jak najbliżej tej części pojazdu, k tóra jest 
źródłem impulsów wejściowych.  
ADA_033 Przewody zasilające adapter muszą być czerwone (plus za si­
lania) i czarne (masa).  
5.2. Plombowanie  
ADA_034 W odniesieniu do plombowania zastosowanie mają następuj ące 
wymagania:  
— obudowa adaptera musi być zaplombowana (zob. 
ADA_017);  
— obudowa wbudowanego czujnika ruchu musi być połą­
czona plombą z obudową adaptera, chyba że nie można 
usunąć czujnika ruchu z obudowy adaptera bez naruszania 
plomby(plomb) obudowy adaptera (zob. ADA_018);  
— obudowa adaptera musi być połączona plombą z pojazdem;  
— połączenie między adapterem a urządzeniem będącym 
źródłem impulsów wejściowych musi być zaplombowane 
na obu końcach (na tyle, na ile jest to możliwe).  
6. KONTROLE, PRZEGLĄDY I NAPRAWY  
6.1. Przegl ądy okresowe  
ADA_035 Każdy przegląd okresowy (przegląd okresowy oznacza prze ­
gląd zgodny z wymaganiami [409]–[413] zawartymi w załącz­
niku 1C) urządzenia rejestrującego w przypadku zastosowania 
adaptera obejmuje sprawdzenie:  
— czy na adapterze znajdują się odpowiednie znaki homolo­
gacji typu;  
— czy plomby na adapterze i jego podłączeniach są 
nienaruszone;  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 603  
— czy adapter zainstalowano zgodnie z informacjami poda­
nymi na tabliczce instalacyjnej;  
— czy adapter zainstalowano zgodnie z instrukcjami produ­
centa adaptera lub pojazdu;  
— czy dopuszcza się instalację adaptera w kontrolowanym 
pojeździe.  
ADA_036 Przedmiotowe przeglądy obejmują kalibrację i wymianę 
wszystkich plomb, niezależnie od ich stanu.  
7. HOMOLOGACJA TYPU URZĄDZENIA REJESTRUJĄCEGO W PRZY­
PADKU ZASTOSOWANIA ADAPTERA  
7.1. Uwagi ogólne  
ADA_037 Urządzenie rejestrujące dostarcza się do homologacji ty pu 
w stanie kompletnym z adapterem [425].  
ADA_038 Do homologacji typu można przedstawić sam adapter lub 
adapter jako element składowy urządzenia rejestrującego.  
ADA_039 Homologacja typu obejmuje badania funkcjonalności adapt era. 
Pozytywne wyniki każdego z tych badań potwierdza się odpo­
wiednim świadectwem [426].  
7.2. Świadectwo funkcjonalno ści 
ADA_040 Świadectwo funkcjonalności adaptera lub urządzenia reje stru­
jącego zawierającego adapter wydaje się producentowi adaptera 
wyłącznie po pozytywnym przejściu co najmniej przez 
wszystkie wyszczególnione niżej badania funkcjonalności.  
Nr Badanie  Wyszczególnienie  Odpowiednie wyma­
gania  
1. Badanie administracyjne  
1.1 Dokumentacja  Prawidłowość doku­
mentacji adaptera  
2. Kontrola wizualna  
2.1. Zgodność adaptera z dokumentacją  
2.2. Identyfikacja / oznakowania adaptera  ADA_027, 
ADA_028  
2.3 Materiały, z których wykonany jest adapter  [219]–[223] 
ADA_026  
2.4. Plombowanie  ADA_017, 
ADA_018, 
ADA_034  
3. Badania funkcjonalno ści 
3.1 Przekazywanie impulsów prędkości do wbudo­
wanego czujnika ruchu  ADA_013  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 604  
Nr Badanie  Wyszczególnienie  Odpowiednie wyma­
gania  
3.2 Odbiór i przetwarzanie wejściowych impulsów 
prędkości  ADA_011, 
ADA_012  
3.3 Dokładność pomiaru ruchu  [30]–[35], [217]  
4. Badania środowiskowe  
4.1 Wyniki badań producenta  Wyniki badań 
środowiskowych 
przeprowadzonych 
przez producenta  ADA_020, 
ADA_021, 
ADA_022, 
ADA_024  
5. EMC (kompatybilno ść elektromagnetyczna)  
5.1 Emisje radiacyjne i wrażli­
wość na radiację  Sprawdzenie zgod­
ności z przepisami 
dyrektywy 2006/28/ 
WE ADA_024  
5.2 Wyniki badań producenta  Wyniki badań 
środowiskowych 
przeprowadzonych 
przez producenta  ADA_024  ▼B
 02016R0799 — PL — 21.08.2023 — 003.001 — 605  
ZAŁĄCZNIK II  
ZNAK I ŚWIADECTWO HOMOLOGACJI  
I. ZNAK HOMOLOGACJI  
1. Znak homologacji składa się z:  
a) prostokąta, wewnątrz którego jest umieszczona litera „e”, po  której nastę­
puje liczba lub litera oznaczająca państwo, które wydało homolo gację, 
zgodnie z następującymi umownymi znakami: 
Belgia  6 ,  
Bułgaria  34,  
Republika Czeska  8 ,  
Dania  18,  
Niemcy  1 ,  
Estonia  29,  
Irlandia  24,  
Grecja  23,  
Hiszpania  9 ,  
Francja  2 ,  
Chorwacja  25,  
Włochy  3 ,  
Cypr  CY,  
Łotwa  32,  
Litwa  36,  
Luksemburg  13,  
Węgry  7 ,  
Malta  MT,  
Niderlandy  4 ,  
Austria  12,  
Polska  20,  
Portugalia  21,  
Rumunia  19,  
Słowenia  26,  
Słowacja  27,  
Finlandia  17,  
Szwecja  5 ,  
Zjednoczone Królestwo  11,  
oraz 
▼M1 
b) numeru homologacji odpowiadającego numerowi świadectwa homol ogacji 
wydanego dla prototypu urządzenia rejestrującego lub wykresówki , bądź 
karty do tachografu, umieszczonemu bezpośrednio obok tego prost okąta.  ▼C1
 02016R0799 — PL — 21.08.2023 — 003.001 — 606  
2. Znak homologacji umieszcza się na tabliczce znamionowej każd ego urzą­
dzenia oraz na każdej wykresówce i na każdej karcie do tachogra fu. Musi 
być nieusuwalny i zawsze wyraźnie czytelny.  
3. Wymiary narysowanego poniżej znaku homologacji (  1 ) wyrażone są w mili­
metrach, przy czym są to wymiary minimalne. Zachowuje się propo rcje 
między wymiarami.
  ▼C1 
( 1 ) Dane podane orientacyjnie.
 02016R0799 — PL — 21.08.2023 — 003.001 — 607  
II. ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW 
ANALOGOWYCH  
Państwo członkowskie, które udzieliło homologacji, wystawia wni oskodawcy 
świadectwo homologacji, którego wzór przedstawiono poniżej. Inf ormując inne 
państwa członkowskie o wydanej lub ewentualnie cofniętej homolo gacji, państwo 
członkowskie musi posługiwać się kopiami tego świadectwa.  
ŚWIADECTWO HOMOLOGACJI  
Nazwa właściwej jednostki administracyjnej  
Zgłoszenie dotyczące (  1 ): 
— homologacji typu urządzenia rejestrującego  
— cofnięcia homologacji typu urządzenia rejestrującego  
— homologacji wzoru wykresówki  
— cofnięcia homologacji wzoru wykresówki  
Homologacja nr:  
...................................  
1. Znak handlowy lub nazwa handlowa  
2. Nazwa typu lub modelu  
3. Nazwa producenta  
4. Adres producenta  
5. Zgłoszono do homologacji w dniu  
6. Zbadano w  
7. Data i numer badania(badań)  
8. Data homologacji  
9. Data cofnięcia homologacji  
10. Typ lub typy urządzeń rejestrujących, dla których przeznacz ona jest wykre­
sówka.  
11. Miejscowość  
12. Data  
13. Załączone dokumenty opisowe  
14. Uwagi (w tym, w odpowiednich przypadkach, o umiejscowieniu plomb)  
(Podpis)  ▼C1 
( 1 ) Niepotrzebne skreślić.
 02016R0799 — PL — 21.08.2023 — 003.001 — 608  
III. ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW 
CYFROWYCH  
Państwo członkowskie, które udzieliło homologacji, wystawia wni oskodawcy 
świadectwo homologacji, którego wzór przedstawiono poniżej. Inf ormując inne 
państwa członkowskie o wydanej lub ewentualnie cofniętej homolo gacji, państwo 
członkowskie musi posługiwać się kopiami tego świadectwa.  
ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW CYFROWYCH  
Nazwa właściwej jednostki administracyjnej  
Zgłoszenie dotyczące (  1 ): 
□ homologacji:  □  cofnięcia homologacji:  
□ modelu urządzenia rejestrującego  
□ elementu składowego urządzenia rejestrującego (  2 ) 
□ karty kierowcy  
□ karty warsztatowej  
□ karty firmowej  
□ karty kontrolera  
Homologacja nr:  
1. Marka fabryczna lub znak towarowy  
2. Nazwa modelu  
3. Nazwa producenta  
4. Adres producenta  
▼M1 
5. Zgłoszono do homologacji w dniu:  
▼C1 
6. Laboratorium(laboratoria)  
7. Data i numer protokołu badań  
8. Data homologacji  
9. Data cofnięcia homologacji  
10. Model urządzenia rejestrującego(urządzeń rejestrujących), z  którym(-i) ma 
współpracować element składowy  
11. Miejscowość  
12. Data  
13. Załączone dokumenty opisowe  
14. Uwagi (w tym, w odpowiednich przypadkach, o umiejscowieniu plomb)  
(Podpis)  ▼C1 
( 1 ) Proszę zaznaczyć właściwe pola. 
( 2 ) Wskazać element składowy, o którym mowa w zgłoszeniu.
 02016R0799 — PL — 21.08.2023 — 003.001 — 609  
IV. ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW 
INTELIGENTNYCH  
Państwo członkowskie, które udzieliło homologacji, wystawia wni oskodawcy 
świadectwo homologacji, którego wzór przedstawiono poniżej. Inf ormując inne 
państwa członkowskie o wydanej lub ewentualnie cofniętej homolo gacji, państwo 
członkowskie musi posługiwać się kopią tego świadectwa.  
ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW INTELIGENTNYCH  
Nazwa właściwej jednostki administracyjnej  
Zgłoszenie dotyczące (  1 ): 
□ homologacji:  □  cofnięcia homologacji:  
□ modelu urządzenia rejestrującego  
□ elementu składowego urządzenia rejestrującego (  2 ) 
□ karty kierowcy  
□ karty warsztatowej  
□ karty firmowej  
□ karty kontrolera  
Homologacja nr:  
1. Marka fabryczna lub znak towarowy  
2. Nazwa modelu  
3. Nazwa producenta  
4. Adres producenta  
▼M1 
5. Zgłoszono do homologacji w dniu:  
▼C1 
6. a) Laboratorium badawcze na potrzeby certyfikacji funkcjonal ności  
b) Laboratorium badawcze na potrzeby certyfikacji bezpieczeństw a 
c) Laboratorium badawcze na potrzeby certyfikacji interoperacyj ności  
7. a) Data i numer świadectwa funkcjonalności  
b) Data i numer świadectwa bezpieczeństwa  
c) Data i numer świadectwa interoperacyjności  
8. Data homologacji  
9. Data cofnięcia homologacji  
10. Model urządzenia rejestrującego(urządzeń rejestrujących), z  którym(-i) ma 
współpracować element składowy  
11. Miejscowość  
12. Data  
13. Załączone dokumenty opisowe  
14. Uwagi (w tym, w odpowiednich przypadkach, o umiejscowieniu plomb)  
(Podpis)  ▼C1 
( 1 ) Proszę zaznaczyć właściwe pola. 
( 2 ) Wskazać element składowy, o którym mowa w zgłoszeniu.