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 lutego 
2018 r.  L 85  1  28.3.2018  
►M2 Rozporz ądzenie wykonawcze Komisji (UE) 2020/158 z dnia 5 lutego 
2020 r.  L 34  20  6.2.2020  
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 — 26.02.2020 — 002.001 — 1
02016R0799 — PL — 26.02.2020 — 002.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 jedno ­
litego stosowania nast ępujących aspektów dotycz ących tachografów:  
a) zapisywanie po łożenia pojazdu w pewnych punktach podczas dzien ­
nego okresu pracy kierowcy;  
b) wczesne wykrywanie na odleg łość możliwych przypadków manipu ­
lowania tachografami inteligentnymi lub ich niew łaściwego użytko­
wania;  
c) interfejs do inteligentnych systemów transportowych;  
d) wymogi administracyjne i techniczne dotycz ące procedur homolo ­
gacji typu dla tachografów, w tym mechanizmy zabezpieczaj ące. 
▼M1 
2. Budowa, sprawdzanie, instalacja, kontrola, u żytkowanie i naprawa 
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 Parla ­
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 16 kwietnia 
2014 r. w sprawie harmonizacji ustawodawstw pa ństw członkowskich 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 — 26.02.2020 — 002.001 — 3  
Zastosowanie maj ą ponadto nast ępujące definicje:  
1) „tachograf cyfrowy” lub „tachograf pierwszej generacji” oznacza 
tachograf cyfrowy inny ni ż tachograf inteligentny;  
2) „urządzenie zewn ętrzne GNSS” oznacza urz ądzenie, które zawiera 
odbiornik GNSS, je żeli przyrząd rejestrujący nie jest pojedynczym 
urządzeniem, a tak że inne elementy sk ładowe niezb ędne do 
ochrony przekazywania danych o po łożeniu reszcie przyrz ądu rejes­
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 udziela ­
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 doku ­
menty dodane przez organ udzielaj ący homologacji typu do folderu 
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 pakietu;  
6) „urządzenie wczesnego wykrywania na odleg łość” oznacza urz ą­
dzenie przyrz ądu rejestruj ącego, które jest u żywane do przeprowa ­
dzania ukierunkowanych kontroli drogowych;  
▼M1 
7) „tachograf inteligentny” lub „tachograf drugiej generacji” oznacza 
tachograf cyfrowy spe łniający wymogi art. 8, 9 i 10 rozporz ądzenia 
(UE) nr 165/2014 oraz za łącznika IC do niniejszego rozporz ądze­
nia; 
8) „element sk ładowy tachografu” oznacza dowolny z nast ępujących 
elementów: przyrz ąd rejestrujący, czujnik ruchu, wykresówka, urz ą­
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 ruchu i prze ­
wodów do przy łączenia czujnika ruchu.  
Może to być pojedyncza jednostka lub kilka jednostek rozmiesz ­
czonych w poje ździe, składających się z jednostki przetwarzaj ącej, 
pamięci danych, funkcji pomiaru czasu, dwóch czytników kart inte ­
ligentnych (dla kierowcy i wspó łkierowcy), drukarki, wy świetlacza,  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 4  
złącz i urządzeń 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 rozmiesz ­
czonych w poje ździe, jednostk ą główną przyrządu rejestruj ącego 
jest jednostka zawieraj ąca jednostk ę przetwarzaj ącą, pamięć danych 
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 rejes­
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 system 
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 udzielenie 
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 przypadku 
organ udzielaj ący homologacji typu wydaje wnioskodawcy świadectwo 
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 producenta 
lub jego przedstawiciela dostarczenia wszelkich dodatkowych informa ­
cji. ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 5  
4. Producent lub jego przedstawiciel udost ępnia organom udziela ­
jącym homologacji typu, jak równie ż podmiotom odpowiedzialnym za 
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 homologacj ę 
typu niektórych elementów sk ładowych lub grup elementów sk łado­
wych tachografu, musi dostarczy ć organom udzielaj ącym homologacji 
typu inne elementy sk ładowe, które uzyska ły już homologacj ę typu, 
a także inne części niezbędne do zbudowania kompletnego tachografu, 
aby umożliwić tym organom przeprowadzenie niezb ędnych bada ń. 
Artykuł 5 
Modyfikacje homologacji typu  
1. Producent lub jego przedstawiciel informuje niezw łocznie organy 
udzielające homologacji typu, które udzieli ły pierwotnej homologacji 
typu, o wszelkich modyfikacjach oprogramowania lub sprz ętu tacho­
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ą homo­
logację typu w zale żności od rodzaju i w łaściwości tych modyfikacji.  
„Rewizja” 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 ą niewielkie. W takich przypad ­
kach organ udzielaj ący homologacji typu wydaje zrewidowane doku ­
menty pakietu informacyjnego, wskazuj ąc rodzaj dokonanych modyfi ­
kacji i dat ę ich zatwierdzenia. Zaktualizowana wersja pakietu informa ­
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 takich 
przypadkach Komisja mo że zwrócić się o przeprowadzenie nowych 
badań i poinformowa ć o tym odpowiednio producenta lub jego upowa ż­
nionego przedstawiciela. Je śli wyniki tych bada ń okażą się zadowala ­
jące, organ udzielaj ący homologacji typu wydaje zrewidowane świa­
dectwo homologacji typu, które zawiera numer odnosz ący się do udzie­
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 ących 
homologacj ę typu prowadzi łyby do wydania nowego świadectwa 
bezpieczeństwa lub interoperacyjno ści. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 6  
Artykuł 6 
Wejście w życie 
Niniejsze rozporz ądzenie wchodzi w życie dwudziestego dnia po jego 
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 wyj ą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 stosowane 
we wszystkich pa ństwach członkowskich.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.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 pracy  
3.6.2 R ęczne wprowadzanie czynno ści kierowcy i zgoda kierowcy na 
interfejs ITS  
3.6.3 Wprowadzanie warunków szczególnych  
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 odle ­ 
głość” 
3.9.10 Zdarzenie „brak informacji o pozycji z odbiornika GNSS”  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 8  
3.9.11 Zdarzenie „b łąd połączenia z urz ądzeniem zewn ętrznym GNSS”  
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” 
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 satelitarnej  
3.12.2 Klucze i certyfikaty  
3.12.3 Dane rejestrowane przy wk ładaniu i wyjmowaniu karty kierowcy 
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ą dzienne 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  
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 tacho ­ 
grafów pierwszej generacji  
3.14.2 Rejestrowanie i przechowywanie danych na kartach do tacho ­ 
grafów drugiej generacji  
3.15 Wy świetlanie  
3.15.1 Domy ślne informacje na wy świetlaczu  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 9  
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  
3.20 Wyprowadzanie danych do dodatkowych urz ądzeń zewnętrznych  
3.21 Kalibracja  
3.22 Kontrola drogowa kalibracji  
3.23 Korekta czasu  
3.24 Parametry pracy  
3.25 Materia ły 
3.26 Oznakowania  
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 rejestruj ą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  
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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 10  
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  
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 dziennych 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 skumulowanego czasu 
prowadzenia pojazdu  
▼B 
4.5.4 Karta warsztatowa  
4.5.4.1 Aplikacja tachograficzna (dost ępna dla przyrz ądów rejestruj ą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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 11  
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  
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  
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 skumulowanego czasu 
prowadzenia pojazdu  
▼B 
4.5.4.2.15 Dane dotycz ące warunków szczególnych  
4.5.5 Karta kontrolna  
4.5.5.1 Aplikacja tachograficzna (dost ępna dla przyrz ądów rejestruj ą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  
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  
4.5.6 Karta firmowa  
4.5.6.1 Aplikacja tachograficzna (dost ępna dla przyrz ądów rejestruj ą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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 12  
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  
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 ę 
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 naprawie  
▼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 ści dla 
urządzeń rejestrujących i kart do tachografów 2. generacji  
WPROWADZENIE  
Pierwsza generacja tachografów cyfrowych jest w u życiu od 1 maja 2006 r. 
Można z nich korzysta ć do czasu wycofania z eksploatacji w transporcie krajo ­
wym. 15 lat po wej ściu w życie niniejszego rozporz ądzenia Komisji wszystkie 
pojazdy w transporcie mi ędzynarodowym musz ą być wyposażone w zgodne 
z przepisami tachografy inteligentne drugiej generacji, wprowadzone niniejszym 
rozporządzeniem.  
Niniejszy za łącznik zawiera wymagania dotycz ące drugiej generacji urz ądzeń 
rejestrujących i kart do tachografów. Pocz ąwszy od daty wprowadzenia, w pojaz ­
dach rejestrowanych po raz pierwszy instaluje si ę urządzenia rejestruj ące drugiej 
generacji i wydaje si ę karty do tachografów drugiej generacji.  
Aby wprowadzenie systemu tachografów drugiej generacji przebieg ło płynnie:  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 13  
— karty do tachografów drugiej generacji zaprojektowane s ą w taki sposób, aby 
możliwe było ich używanie równie ż w przyrządach rejestruj ących pierwszej 
generacji,  
— wraz z dat ą wprowadzenia nie wymaga si ę wymiany wa żnych kart do tacho ­
grafów pierwszej generacji.  
Pozwoli to kierowcom na zachowanie jednej karty kierowcy, z której b ędą mogli 
korzystać w obu systemach.  
Urządzenia rejestruj ące drugiej generacji s ą natomiast kalibrowane tylko 
z użyciem kart warsztatowych drugiej generacji.  
Niniejszy za łącznik zawiera wszelkie wymogi zwi ązane z interoperacyjno ścią 
między pierwsz ą a drugą generacją systemu tachografów.  
Dodatek 15 zawiera dodatkowe szczegó łowe informacje dotycz ące zarządzania 
współistnieniem dwóch systemów.  
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  
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;  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 14  
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);  
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 żąca 
wartość licznika kilometrów); podczas kalibracji urz ądzenia 
rejestrującego w pami ęci danych zachowywane s ą również 
rodzaje i identyfikatory odpowiednich plomb homologacyj ­
nych;  
aktualizacj ę lub potwierdzenie jedynie czasu UTC uwa ża się 
za korektę czasu, a nie za kalibracj ę, pod warunkiem że nie 
jest to sprzeczne z wymaganiem 409;  
do kalibracji urz ądzenia rejestruj ącego niezb ędna 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 (w stosownych przypad ­
kach) numer kolejny karty, numer wymiany karty i numer 
odnowienia karty;  
tym samym karta jest jednoznacznie zidentyfikowana przez 
kod państwa członkowskiego wydaj ącego i numer karty;  
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;  
i) „numer odnowienia karty”oznacza:  
16. znak alfanumeryczny w numerze karty, który jest zmie ­
niany przyrostowo przy ka żdym odnowieniu karty do tacho ­
grafów;  
j) „numer wymiany karty”oznacza:  
15. znak alfanumeryczny w numerze karty, który jest zmie ­
niany przyrostowo przy ka żdej wymianie karty do tachogra ­
fów; 
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;  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 15  
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;  
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.  ▼B 
( 1 ) Ten sposób obliczania nieprzerwanego czasu prowadzenia pojazdu oraz skumulowanego 
czasu przerwy s łuży urządzeniu rejestruj ącemu do obliczenia ostrze żenia o nieprze ­
rwanym czasie prowadzenia. Nie przes ądza on o prawnej interpretacji tych czasów. 
Można stosowa ć alternatywne sposoby obliczania nieprzerwanego czasu prowadzenia 
pojazdu i skumulowanego czasu przerw w celu zast ąpienia niniejszych 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 nie jest w łożona 
do urządzenia rejestruj ącego, oraz w których nie dokonano r ęcznej rejestracji czynno ści 
kierowcy. 
( 3 ) Rozporz ądzenie (WE) nr 561/2006 Parlamentu Europejskiego i Rady 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 3820/85 (Dz.U. L 102 
z 11.4.2006, s. 1).
 02016R0799 — PL — 26.02.2020 — 002.001 — 16  
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;  
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 
podlegają zatwierdzeniu przez w łaściwy organ pa ństwa człon­
kowskiego i mog ą mieć miejsce tylko przed aktywacj ą tacho­
grafu;  
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;  ▼B 
( 1 ) Rozporz ądzenie Komisji (UE) nr 1230/2012 z dnia 12 grudnia 2012 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 Europejskiego 
i Rady (Dz.U. L 353 z 21.12.2012, s. 31), z pó źniejszymi zmianami.
 02016R0799 — PL — 26.02.2020 — 002.001 — 17  
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.  
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 infor ­
macji;  
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ę; 
ee) „karta niewa żna” oznacza:  
kartę wykrytą jako wadliwa lub kart ę, której wst ępne uwierzy ­
telnienie nie jest mo żliwe lub której okres wa żności jeszcze si ę 
nie rozpocz ął lub już upłynął; 
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;  
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;  ▼B 
( 1 ) Dyrektywa Rady 92/6/EWG z dnia 10 lutego 1992 r. w sprawie montowania 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 — 26.02.2020 — 002.001 — 18  
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;  
▼M1 
ll) „urządzenie do łączności na odleg łość” lub „urządzenie wczes ­
nego wykrywania na odleg ł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;  
nn) „odnowienie” 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ę. Odnowienie jest zawsze gwarancj ą, że dwie wa żne 
karty nie wspó łistnieją; 
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;  
pp) „wymiana karty”oznacza:  
wydanie karty do tachografu w celu zast ąpienia dotychcza ­
sowej karty, której utrat ę, kradzież lub wadliwe dzia łanie zgło­
szono i której nie zwrócono organowi, który wyda ł kartę. 
Wymiana zawsze wi ąże się z ryzykiem, że mogą współistnieć 
dwie ważne karty;  
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);  
▼M1 
tt) „korekta czasu” oznacza:  
korektę bieżącego czasu; mo że ona być automatyczna w regu ­
larnych odst ępach z wykorzystaniem 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;  ▼B 
( 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).
 02016R0799 — PL — 26.02.2020 — 002.001 — 19  
vv) „identyfikacja pojazdu” oznacza:  
numery identyfikuj ące pojazd: numer rejestracyjny pojazdu 
(VRN) z oznaczeniem pa ństwa członkowskiego rejestracji 
i numer identyfikacyjny pojazdu (VIN) (  1 ); 
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:  
▼M1 
— które jest zainstalowane i stosowane wy łącznie w pojazdach 
kategorii M1 i N1 (okre ślonych w za łączniku II do dyre ­
ktywy 2007/46/WE Parlamentu Europejskiego i Rady (  2 ) 
z późniejszymi zmianami),  
▼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,  
— 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; ▼B 
( 1 ) Dyrektywa Rady z dnia 18 grudnia 1975 r. w sprawie zbli żania ustawodawstw Pa ństw 
Członkowskich odnosz ących się do tabliczek znamionowych i oznakowania identyfika ­
cyjnego pojazdów silnikowych i ich przyczep oraz sposobu i miejsca ich umieszczania 
(Dz.U. L 24 z 30.1.1976, s. 1). 
( 2 ) Dyrektywa 2007/46/WE Parlamentu Europejskiego i Rady z dnia 5 wrze śnia 2007 r. 
ustanawiaj ąca ramy dla homologacji pojazdów silnikowych i ich przyczep oraz uk ładów, 
części i oddzielnych zespo łów technicznych przeznaczonych do tych pojazdów (dyrek ­
tywa ramowa ) (Dz.U. L 263 z 9.10.2007, s.1).
 02016R0799 — PL — 26.02.2020 — 002.001 — 20  
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 zniekszta ł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;  
aaa) „prywatno ść danych” oznacza:  
ogólne środki techniczne podj ęte w celu zapewnienia w łaści­
wego wdro żenia zasad okre ślonych w dyrektywie 95/46/WE 
Parlamentu Europejskiego i Rady (  1 ), a także zasad okre ślo­
nych w dyrektywie 2002/58/WE Parlamentu Europejskiego 
i Rady (  2 ); 
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.;  
ccc) data wprowadzenia:  
36 miesięcy po wej ściu w życie szczegó łowych przepisów, 
o których mowa w art. 11 rozporz ądzenia Parlamentu Europej ­
skiego i Rady (UE) nr 165/2014 (  3 ). 
Jest to data, po której rejestrowane po raz pierwszy pojazdy:  
— muszą być wyposażone w tachograf pod łączony do us ługi 
określania pozycji opartej na systemie nawigacji satelitar ­
nej, 
— muszą mieć możliwość przekazywania danych w łaściwym 
organom kontrolnym na potrzeby ukierunkowanych 
kontroli drogowych podczas ruchu pojazdu.  
— oraz mog ą być wyposażone w znormalizowane interfejsy 
pozwalające na wykorzystywanie przez urz ądzenie 
zewnętrzne danych rejestrowanych lub generowanych 
przez tachografy w trybie operacyjnym.  
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 zabezpieczania informacji;  ▼B 
( 1 ) Dyrektywa 95/46/WE Parlamentu Europejskiego i Rady z dnia 24 pa ździernika 1995 r. 
w sprawie ochrony osób fizycznych w zakresie przetwarzania danych osobowych 
i swobodnego przep ływu tych danych (Dz.U. L 281 z 23.11.1995, s. 31). 
( 2 ) Dyrektywa 2002/58/WE Parlamentu Europejskiego i Rady z dnia 12 lipca 2002 r. doty ­
cząca przetwarzania danych osobowych i ochrony prywatno ści w sektorze łączności 
elektronicznej (Dz.U. L 201 z 31.7.2002, s. 37). 
( 3 ) 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 transporcie drogowym oraz zmieniaj ące rozporz ądzenie (WE) nr 561/2006 Parlamentu 
Europejskiego i Rady w sprawie harmonizacji niektórych przepisów socjalnych odno ­
szących się do transportu drogowego (Dz.U. L 60 z 28.2.2014, s. 1).
 02016R0799 — PL — 26.02.2020 — 002.001 — 21  
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, przechowywa ­
nie, wyświetlanie, drukowanie i wyprowadzanie danych zwi ązanych 
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 licznik 
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 wczesnego 
wykrywania na odleg łość, jak określono w dodatku 14.  
05) Przyrz ąd rejestruj ący może 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 opcjonalny 
interfejs ITS.  
06) Zawarcie w urz ądzeniu rejestruj ącym lub przy łączenie do 
niego jakiejkolwiek funkcji, urz ądzenia lub urz ądzeń, zatwier­
dzonych 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żyt­
kownika.  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 22  
Odbywa si ę to zgodnie z dyrektyw ą 95/46/WE z dnia 24 pa ździer­
nika 1995 r. w sprawie ochrony osób fizycznych w zakresie prze ­
twarzania danych osobowych i swobodnego przep ływu tych 
danych (  1 ), dyrektyw ą 2002/58/WE z dnia 12 lipca 2002 r. doty ­
czącą przetwarzania danych osobowych i ochrony prywatno ści 
w sektorze łączności elektronicznej (  2 ) oraz zgodnie z art. 7 
rozporządzenia (UE) nr 165/2014.  
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,  
— dane wprowadzane r ęcznie przez kierowc ę: 
— wprowadzanie miejsca rozpocz ęcia lub zako ńczenia 
okresu pracy,  
— ręczne wprowadzanie danych o czynno ściach 
kierowcy,  
— warunki szczególne,  
— 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 tachogra ­
fów, 
— wyświetlanie,  
— drukowanie,  
— ostrzeganie,  
— pobieranie danych na no śniki zewnętrzne,  
— łączność na odleg łość na potrzeby ukierunkowanych 
kontroli drogowych,  
— wyprowadzanie danych do dodatkowych urz ądzeń, 
— kalibracja,  
— kontrola drogowa kalibracji  
— korekta czasu.  
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 tachografó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 gene ­
racji będzie zawsze uznawana za niewa żną, jeżeli zostanie 
włożona do przyrz ądu rejestracyjnego drugiej generacji.  ▼B 
( 1 ) Dz.U. L 281 z 23.11.1995, s. 31. 
( 2 ) Dz.U. L 201 z 31.7.2002, s. 37.
 02016R0799 — PL — 26.02.2020 — 002.001 — 23  
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, drukowanie 
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 kalibracyj ­
nym,  
— funkcja kontroli drogowej kalibracji dost ępna jest tylko 
w trybie kontrolnym,  
— funkcja zarz ądzania blokadami firmowymi dost ępna jest 
tylko w trybie firmowym,  
— funkcja monitorowania czynno ści kontrolnych dost ępna 
jest tylko w trybie kontrolnym,  
— funkcja pobierania danych nie jest dost ępna w trybie 
eksploatacyjnym, z wyj ątkiem przypadków w wymaganiu 
193 i z wyj ątkiem pobierania danych z karty kierowcy, 
gdy żadna inna karta nie jest w łożona do przyrz ądu rejes­
trującego.  
13) Urządzenie rejestruj ące może wyprowadza ć dane na wy świet­
lacz, 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),  
— w trybie firmowym, dane dotycz ące kierowcy (wymagania 
102, 105 i 108) mog ą być wyprowadzane tylko dla okre ­
sów, w których nie ma żadnej blokady ani żadna inna 
firma nie za łożyła blokady (okre ślona pierwszymi 13 
cyframi numeru karty firmowej),  
— przy braku karty w czytniku urz ądzenia rejestruj ącego 
dane dotycz ące kierowcy mog ą być wyprowadzane tylko 
dla bieżącego dnia kalendarzowego i 8 poprzednich dni 
kalendarzowych,  
— dane osobowe pochodz ące z przyrz ądu rejestruj ącego nie 
mogą być wyprowadzane poprzez interfejs ITS przyrz ądu, 
o ile nie sprawdzono, że zgodził się na to kierowca, 
którego dane dotycz ą, ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 24  
— normalny okres wa żności operacji przyrz ądów rejestruj ą­
cych wynosi 15 lat, pocz ąwszy od daty wej ścia w życie 
świadectwa przyrz ądu rejestruj ącego, ale przyrz ądy rejes­
trują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 autentycz ­
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 wymie ­
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 ści 
i autentyczno ści pobieranych danych.  
▼B 
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 wymaga ­
niami w dodatku 10:  
— przyrząd rejestrujący, 
— karta do tachografu,  
— czujnik ruchu,  
— urządzenie zewn ętrzne GNSS (profil ten jest tylko 
konieczny i stosowany do zewn ętrznego wariantu GNSS).  
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.  
16) Po w łożeniu karty urz ądzenie rejestruj ące sprawdza, czy 
włożona karta jest wa żną kartą do tachografu i w przypadku 
ważnej karty sprawdza typ i generacj ę karty.  
Jeżeli do urz ądzenia rejestruj ącego włożona już była karta 
o tym samym numerze karty i wy ższym numerze odnowienia, 
karta jest zg łaszana jako niewa żna. 
Jeżeli do urz ądzenia rejestruj ącego włożona już była karta 
o tym samym numerze karty i numerze odnowienia, ale 
wyższym numerze wymiany, karta jest zg łaszana jako 
nieważna. 
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. ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 25  
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.  
20) Odblokowanie kart do tachografów jest mo żliwe tylko przy 
zatrzymanym poje ździe i po zapisaniu odpowiednich danych 
na kartach. Odblokowanie karty wymaga wykonania przez 
użytkownika odpowiedniej czynno ści. 
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.  
23) Funkcja ta nieprzerwanie mierzy i dostarcza warto ść prędkoś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łnia­
jące wymagania niniejszego rozporz ądzenia, spe łniają wyma­
gania odno śnie do maksymalnych tolerancji (zob. 3.2.1 i 3.2.2) 
określone w niniejszym za łączniku.  
26) W celu wykrycia manipulowania danymi dotycz ącymi ruchu 
informacje z czujnika ruchu s ą potwierdzane przez informacje 
dotyczące ruchu pojazdu pochodz ące z odbiornika GNSS 
i opcjonalnie z innych źródeł niezależnych od czujnika ruchu.  
27) Funkcja ta mierzy pozycj ę pojazdu w celu umo żliwienia auto ­
matycznej rejestracji:  
— pozycji, w których kierowca lub wspó łkierowca rozpoczy ­
nają dzienny okres pracy;  
▼M1 
— pozycji, w których skumulowany czas prowadzenia 
pojazdu osi ągnie wielokrotno ść trzech godzin;  
▼B 
— pozycji, w których kierowca lub wspó łkierowca ko ńczą 
dzienny okres pracy;  
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 — 26.02.2020 — 002.001 — 26  
30) Pomiar odleg łości jest wykonywany z nast ępującą dokładno­ 
ścią (odległości co najmniej 1 000 m):  
— ± 1 % przed instalacj ą, 
— ± 2 % po instalacji i przegl ądzie okresowym,  
— ± 4 % podczas eksploatacji.  
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.  
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 4 000 a 25 000 impulsów na km, mierzy 
prędkość z dokładnością ± 1 km/godz. (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. 
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.  
37) Bezwzgl ędną pozycję mierzy się we współrzędnych szeroko ści 
i długości geograficznej, w stopniach i minutach, z dok ładno­ 
ścią do 1/10 minuty.  
3.3 Pomiar czasu  
38) Funkcja pomiaru czasu mierzy czas nieprzerwanie i cyfrowo 
podaje czas UTC.  
39) Do datowania w urz ądzeniu rejestruj ącym (rejestracja, 
wymiana danych) i do wszystkich wydruków wymienionych 
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;  
41) Dryft czasu musi mie ścić się w granicach ± 2 sek. dziennie 
w warunkach homologacyjnych, przy braku korekty czasu.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 27  
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 czyn ­
ności PROWADZENIE dla kierowcy i GOTOWO ŚĆ dla 
współkierowcy.  
48) Gdy pojazd zatrzymuje si ę, następuje automatyczne wybranie 
czynności PRACA dla kierowcy.  
▼M1 
49) Jeżeli w czasie 120 sekund od automatycznej zmiany na 
PRACĘ, wskutek zatrzymania pojazdu, nast ąpi zmiana czyn ­
ności na PRZERWA/ODPOCZYNEK lub GOTOWO ŚĆ, 
przyjmuje si ę, że pierwsza taka zmiana zaistnia ła w czasie 
postoju pojazdu (w ten sposób mo żna anulowa ć zmianę czyn­
ności na PRACA).  
▼B 
50) Funkcja ta przekazuje zmiany czynno ści do funkcji rejestru ­
ją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 nieprze ­
rwany 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 przy ­
padku 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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 28  
57) Miejsca definiuje si ę jako kraj i dodatkowo, w stosownych 
przypadkach, region; s ą one wprowadzane lub potwierdzane 
ręcznie.  
58) W chwili wyj ęcia karty kierowcy urz ądzenie rejestruj ące 
sygnalizuje, że oczekuje od (wspó ł)kierowcy wprowadzenia 
„miejsca zako ńczenia dziennego okresu pracy”.  
▼M1 
59) Kierowca wprowadza wówczas bie żące miejsce pojazdu, 
a wpis ten uznaje si ę za tymczasowy.  
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 ę obecny dzienny 
okres pracy, w trakcie r ęcznego wprowadzania zgodnie 
z wymogiem 61;  
— następny wpis miejsca, w którym rozpoczyna si ę obecny 
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 wymo ­
giem 61.  
W poniższych warunkach wpis tymczasowy wykonany przy 
ostatnim wyj ęciu karty jest nadpisywany i zatwierdzona 
zostaje nowa warto ść: 
— następny wpis miejsca zako ńczenia obecnego dziennego 
okresu pracy, je śli posiadacz karty nie wpisze żadnego 
miejsca rozpocz ęcia lub zako ńczenia okresu pracy 
w trakcie r ęcznego wprowadzania zgodnie z wymo ­
giem 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.  
3.6.2  R ęczne wprowadzanie czynno ści kierowcy i zgoda kierowcy na 
interfejs ITS  
61) Po w łożeniu karty kierowcy (lub warsztatowej), i tylko w tym 
czasie, urz ądzenie rejestruj ące umożliwia ręczne wprowa ­
dzanie 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 rejes­
trujący przypomina posiadaczowi karty:  
— datę i godzinę ostatniego wyj ęcia jego karty;  
— opcjonalnie: przesuni ęcie czasu lokalnego aktualnie usta ­
wionego w przyrz ądzie rejestruj ącym.  
Przy pierwszym w łożeniu danej karty kierowcy lub warsztato ­
wej, nieznanej przyrz ądowi rejestruj ącemu, posiadacz karty 
jest proszony o wyra żenie zgody na wyprowadzenie danych 
osobowych zwi ązanych z tachografem poprzez opcjonalny 
interfejs ITS.  
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 ogra­
niczeniami:  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 29  
— 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 obecnym 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 obecnym w łożeniem karty posiadacz karty mo że nie zgła­
szać żadnej czynno ści. 
Podczas ręcznego wprowadzania danych zwi ązanego z w łoże­
niem karty, posiadacz karty ma, w stosownych przypadkach, 
możliwość wprowadzenia:  
▼M1 
— 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 ę obecny dzienny okres 
pracy powi ązany z odno śnym czasem (czyli zatwierdzenia 
wpisu tymczasowego przy ostatnim wyj ęciu karty).  
▼B 
Jeżeli posiadacz karty nie wprowadzi miejsca rozpocz ęcia lub 
zakończenia okresu pracy podczas r ęcznego wprowadzania 
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.  
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 ę i karta znajduje si ę w czytniku karty 
kierowcy.  
Dozwolone s ą dodatkowe przerwy, np. przekroczenie dozwo ­
lonego czasu po pewnym okresie braku aktywno ści użytkow­
nika. Jeżeli ręczne wprowadzanie zostanie przerwane, urz ą­
dzenie rejestruj ące dokonuje walidacji wszystkich komplet ­
nych 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 chronolo ­
gicznej w okresie mi ędzy ostatnim wyj ęciem a obecnym 
włożeniem karty.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 30  
— 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 wpro ­
wadzanej czynno ści pokrywa si ę z godzin ą włożenia karty. 
Urządzenie rejestruj ące umożliwia opcjonalnie posiadaczowi 
karty modyfikowanie r ęcznie wprowadzonej czynno ści aż do 
zatwierdzenia przez wybranie odpowiedniego polecenia. 
W późniejszym czasie wprowadzenie takich zmian jest zabro ­
nione.  
3.6.3  Wprowadzanie warunków szczególnych  
62) Urządzenie rejestruj ące umożliwia kierowcy wprowadzenie 
w czasie rzeczywistym nast ępujących dwóch warunków szcze ­
gólnych:  
— „POZA ZAKRESEM” (pocz ątek, koniec)  
— „PRZEPRAWA PROMOWA / PRZEJAZD KOLEJOWY” 
(początek, koniec).  
Jeżeli wybrany jest warunek „POZA ZAKRESEM”, nie mo że 
równocześnie wyst ępować warunek „PRZEPRAWA 
PROMOWA / PRZEJAZD KOLEJOWY”.  
Włożenie lub wyj ęcie karty kierowcy powoduje automatycznie 
zakończenie wybranego stanu „POZA ZAKRESEM”.  
Wybrany 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.  
Znacznik rozpocz ęcia PRZEPRAWY PROMOWEJ / PRZE ­
JAZDU KOLEJOWEGO ustawia si ę przed wy łączeniem 
silnika na promie/w poci ągu. 
Zamknięcie otwartego stanu PRZEPRAWA PROMOWA / 
PRZEJAZD KOLEJOWY musi nast ąpić, jeżeli wystąpi jedna 
z następujących sytuacji:  
— kierowca r ęcznie kończy stan PRZEPRAWA PROMOWA 
/ PRZEJAZD KOLEJOWY;  
— kierowca wyjmuje swoj ą kartę. 
Otwarty stan PRZEPRAWA PROMOWA / PRZEJAZD 
KOLEJOWY ko ńczy się w momencie, gdy przystaje by ć on 
ważny na podstawie zasad okre ślonych w rozporz ądzeniu 
(WE) nr 561/2006.  
3.7 Zarz ądzanie blokadami firmowymi  
63) Funkcja ta umo żliwia zarządzanie blokadami umieszczanymi 
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 rzeczywis ­
tym. 
66) Blokad ę może zwolnić tylko ta firma, która j ą włączyła (iden­
tyfikowana na podstawie pierwszych 13 cyfr numeru karty 
firmowej), lub  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 31  
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 prze­
prowadzona, gdy w trybie kontrolnym komunikat „przekro ­
czenie prędkości” zostaje wys łany do drukarki lub wy świet­
lony 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: 
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:  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 32  
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 ęd­
kości. 
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 zasi ­
laniu 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 przyrz ą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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 33  
3.9.12  Zdarzenie „b łąd danych dotycz ących ruchu”  
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 uwierzytel ­
nienia danych wymienianych mi ędzy czujnikiem ruchu a przy ­
rządem rejestruj ącym.  
3.9.13  Zdarzenie „konflikt ruchu pojazdu”  
84) Z wyjątkiem trybu kalibracyjnego , zdarzenie to uruchamia 
się, jeżeli informacje o ruchu z czujnika ruchu s ą sprzeczne 
z informacjami o ruchu obliczonymi z wewn ętrznego odbior ­
nika GNSS lub urz ądzenia zewn ętrznego GNSS i ewentualnie 
z innych niezale żnych źródeł, jak okre ślono w dodatku 12. 
Zdarzenie to nie uruchamia si ę podczas przeprawy promowej 
lub przejazdu kolejowego, w przypadku stanu POZA ZAKRE ­
SEM, ani w razie niedost ępności informacji o pozycji z odbior ­
nika GNSS.  
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”  
86) Z wyjątkiem trybu kalibracyjnego , zdarzenie to uruchamia 
się, jeżeli przyrząd rejestrujący wykryje rozbie żność większą 
niż 1 min. mi ędzy czasem okre ślonym przez funkcj ę pomiaru 
czasu w przyrz ądzie rejestruj ącym a czasem pochodz ącym 
z odbiornika GNSS. Zdarzenie to jest rejestrowane wraz 
z wartością wyświetlaną na wewn ętrznym zegarze przyrz ądu 
rejestrującego i wiąże się z automatyczn ą korektą czasu. Po 
uruchomieniu zdarzenia konfliktu czasu przyrz ąd rejestrujący 
nie generuje innych zdarze ń konfliktu czasu przez kolejnych 
12 godzin. Zdarzenie nie zostanie wywo łane w przypadkach, 
w których odbiornik GNSS nie móg ł wykryć prawidłowego 
sygnału GNSS przez co najmniej 30 dni.  
▼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ść 
▼M1 
— usterka interfejsu ITS (w stosownych przypadkach)  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 34  
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 producen ­
ta) 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  
▼M1 
Interfejs ITS (fakultatywnie)  Prawid łowa praca  
▼B 
3.11 Odczyt z pami ęci danych  
90) Urządzenie rejestruj ące umożliwia odczyt danych przechowy ­
wanych w jego pami ęci danych.  
3.12 Rejestracja i przechowywanie w pami ęci danych  
Do celów niniejszego pkt:  
— „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 (wspó ł)kierowców, 2 190 cykli wk ła­
dania i wyjmowania karty i 93 440 zmian czynno ści, 
▼M1 
— średnia liczba pozycji na dzie ń jest definiowana jako co 
najmniej 6 pozycji, w których rozpoczyna si ę dzienny okres 
pracy, 6 pozycji, w których skumulowany czas prowadzenia 
pojazdu osi ąga wielokrotno ść trzech godzin, oraz 6 pozycji, 
w których ko ńczy się dzienny okres pracy, tak wi ęc „365 dni” 
obejmuje co najmniej 6570 pozycji,  
▼B 
— 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 minu ­
tach, z dok ładnością do 1/10 minuty, z powi ązaną dokładnością 
GNSS i czasem pobrania danych.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 35  
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 informa ­
cji: 
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,  
94) Dane identyfikuj ące przyrząd rejestruj ący są rejestrowane 
i zapisywane w pami ęci definitywnie przez producenta przy ­
rządu rejestruj ącego, z wyj ątkiem danych dotycz ących opro­
gramowania i numeru homologacji, które mog ą zmieniać się 
w przypadku aktualizacji oprogramowania, oraz z wyj ątkiem 
możliwości korzystania z kart do tachografów pierwszej 
generacji.  
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.  
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 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
 02016R0799 — PL — 26.02.2020 — 002.001 — 36  
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.  
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 powi ązaniami urz ądzeń zewnętrznych 
GNSS (jeżeli podczas jednego dnia kalendarzowego mia ło 
miejsce wiele powi ązań, zachowywane jest tylko pierwsze 
i ostatnie z danego dnia).  
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 rejes­
truje i przechowuje w pami ęci danych nast ępujące informa ­
cje: 
— 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,  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 37  
— 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 ępno­ 
ści), 
— datę i godzinę wyjęcia karty,  
— wskaźnik stanu pokazuj ący, czy przy wk ładaniu karty 
posiadacz karty wprowadzi ł ręcznie informacje o wykony ­
waniu 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.  
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 czynno ś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 KIEROW ­
CA),  
— szczelin ę czytnika (KIEROWCA, WSPÓ ŁKIEROWCA),  
— 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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 38  
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ó łkierowca 
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ó łkierowca 
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 ostat ­
niej 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:  
— numer karty (wspó ł)kierowcy i pa ństwo członkowskie 
wydające kartę, 
— 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.  
▼M1 
111) Pami ęć danych wystarcza do przechowywania miejsc i pozy ­
cji, 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 licz ­
nika 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ścią 
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:  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 39  
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  
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 
— numer VRN, pa ństwo członkowskie 
rejestracji i generacja przyrz ądu 
rejestrującego  
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 — 26.02.2020 — 002.001 — 40  
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 — 26.02.2020 — 002.001 — 41  
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  
▼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ścią 
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:  
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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 42  
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 kalen ­
darzowego 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 dane:  
— cel kalibracji (aktywacja, pierwsza instalacja, instalacja, 
przegląd okresowy),  
— nazwa i adres warsztatu,  
— numer karty warsztatowej, pa ństwo członkowskie wyda ­
jące kartę i termin wa żności karty,  
— identyfikacja pojazdu,  
— parametry uaktualnione lub potwierdzone: w, k, l, rozmiar 
opon, ustawienia urz ądzenia ograniczenia pr ędkoś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.  
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ępują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 ętrz­
nego 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 wyda ­
jące kartę, generacja karty i termin wa żności karty.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 43  
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 wydaj ą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).  
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, wykona ­
nego 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ólnych:  
— data i godzina wprowadzenia danych,  
— rodzaj warunku szczególnego.  
131) Pami ęć danych umo żliwia przechowywanie danych dotycz ą­
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 — 26.02.2020 — 002.001 — 44  
— typ karty do tachografu,  
— wersja karty do tachografu.  
133) Urządzenie rejestruj ące umożliwia przechowywanie co 
najmniej 88 takich rekordów danych.  
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, 
— wyliczenia dla kierowcy: nieprzerwanego czasu prowa ­
dzenia pojazdu, skumulowanego czasu przerwy i skumulo ­
wanego czasu prowadzenia za poprzedni i obecny tydzie ń, 
— 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ą. 
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 karcie 
kierowcy lub warsztatowej bezpo średnio po w łożeniu karty.  
138) Urządzenie rejestruj ące aktualizuje dane zapisane na wa żnej 
karcie kierowcy, warsztatowej, firmowej lub kontrolnej, wpro ­
wadzają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 czynno ś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.  
140) Wszystkie wydarzenia niezdefiniowane dla urz ądzeń rejestru­
jących pierwszej generacji nie s ą zapisywane na karcie 
kierowcy ani na karcie warsztatowej.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 45  
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ępo­
wanymi najnowszymi danymi.  
142) W przypadku b łędu zapisu urz ądzenie rejestruj ące maksy­
malnie trzykrotnie powtarza to samo polecenie zapisu i w przy ­
padku gdy zapis nadal nie jest mo żliwy, uznaje kart ę za 
uszkodzon ą i nieważną. 
143) Przed odblokowaniem karty kierowcy i po zapisaniu na karcie 
wszystkich stosownych danych urz ądzenie rejestruj ące zeruje 
„dane sesji karty”.  
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 apli­
kacje kart, z których pierwsza jest dok ładnie taka sama jak 
aplikacja TACHO w kartach do tachografów pierwszej gene ­
racji, a druga aplikacja „TACHO_G2” jest zgodna ze specy ­
fikacjami w rozdziale 4 i dodatku 2.  
145) Urządzenie rejestruj ące ustawia „dane sesji karty” na karcie 
kierowcy lub warsztatowej bezpo średnio po w łożeniu karty.  
146) Urządzenie rejestruj ące aktualizuje dane zapisane w 2 aplika ­
cjach 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 ą przechowywane 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.  
148) 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ępo­
wanymi najnowszymi danymi.  
149) W przypadku b łędu zapisu urz ądzenie rejestruj ące maksy­
malnie trzykrotnie powtarza to samo polecenie zapisu i w przy ­
padku gdy zapis nadal nie jest mo żliwy, uznaje kart ę za 
uszkodzon ą i nieważną. 
150) Przed odblokowaniem karty kierowcy i po zapisaniu wszyst ­
kich stosownych danych w 2 aplikacjach karty urz ądzenie 
rejestrujące zeruje „dane sesji karty”.  
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). ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 46  
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ż dodatkowe 
informacje, z tym jednak, że muszą być one łatwe do odró ż­
nienia od wymienionych powy żej, wymaganych informacji.  
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 piktogra ­
mów.  
158) Gdy pojazd jest w ruchu, wy świetlacz jest stale w łączony.  
159) Urządzenie rejestruj ące może gasić wyświetlacz automatycznie 
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 infor ­
macji, urz ądzenie rejestruj ące domyślnie wyświetla nast ępu­
jące informacje:  
— czas lokalny (wynik czasu UTC + przesuni ęcie wprowa ­
dzone przez kierowc ę), 
— tryb pracy,  
— bieżącą czynność kierowcy i bie żącą czynność współkie­
rowcy,  
— 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 PROWADZENIE, 
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 infor ­
macji odnosz ących się do kierowcy i wspó łkierowcy nie 
można wyświetlić w tym samym czasie, urz ądzenie rejestru ­
jące pokazuje domy ślnie informacje odnosz ą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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 47  
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).  
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 licz ­
bowych. Mo żna też dodać wyszczególnienie s łowne w prefero ­
wanym 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,  
— treści każdego z sze ściu wydruków w takim samym 
formacie jak wydruki,  
— nieprzerwanego czasu prowadzenia pojazdu i skumulowa ­
nego czasu przerwy kierowcy,  
— nieprzerwanego czasu prowadzenia pojazdu i skumulowa ­
nego czasu przerwy wspó łkierowcy,  
— skumulowanego czasu prowadzenia pojazdu kierowcy za 
poprzedni i bie żący tydzień, 
— skumulowanego czasu prowadzenia pojazdu wspó łkie­
rowcy za poprzedni i bie żący tydzień, 
opcjonalnie:  
— bieżącego czasu trwania czynno ści współkierowcy (od 
momentu wybrania),  
— skumulowanego czasu prowadzenia pojazdu kierowcy za 
bieżący tydzień, 
— skumulowanego czasu prowadzenia pojazdu wspó łkie­
rowcy za bie żący dzienny okres pracy,  
— skumulowanego czasu prowadzenia pojazdu kierowcy za 
bieżący dzienny okres pracy.  
168) Treść wydruku jest wy świetlana sekwencyjnie, wiersz po wier ­
szu. Jeżeli w szeroko ści wyświetlacza mie ści się mniej niż 24 
znaki, użytkownik musi mie ć dostęp do pełnej informacji 
w odpowiedni sposób (w kilku wierszach, przy pomocy prze ­
wijania itp.).  
Wiersze wydruku przeznaczone na r ęczne adnotacje mo żna 
pominąć na wyświetlaczu.  
3.16 Drukowanie  
169) Urządzenie rejestruj ące umożliwia drukowanie siedmiu okre ­ 
ślonych poni żej wydruków, na podstawie informacji zgroma ­
dzonych 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 rejestru ­
jącego,  
— wydruk zdarze ń i usterek z karty,  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 48  
— wydruk zdarze ń i usterek z przyrz ądu rejestruj ącego,  
— wydruk danych technicznych,  
— wydruk przekroczenia pr ędkości, 
— historia danych karty do tachografu dla danego przyrz ą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 dodat ­
kowe.  
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 wyso ­
koś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 odczy ­
cie. 
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 oznakowanie 
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 przechowywania, 
w normalnym o świetleniu, wilgotno ści i temperaturze, 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 ęcz­
nych adnotacji, takich jak podpis kierowcy.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 49  
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 drukowanie 
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 maksymalnego 
dopuszczalnego nieprzerwanego czasu prowadzenia 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 rejes ­
trują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 żytkownika 
przy pomocy specjalnego przycisku lub polecenia urz ądzenia 
rejestrującego.  
191) Dopuszcza si ę dodatkowe ostrze żenia, pod warunkiem że nie 
są mylące dla kierowców w odniesieniu do wcze śniej zdefi­
niowanych 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.  
193) Dodatkowo i opcjonalnie, urz ądzenie rejestruj ące może 
w dowolnym trybie pracy przesy łać dane w dowolny inny 
sposób 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.  
194) Przy pobieraniu danych nie mo że mieć miejsca zmienianie ani 
usuwanie jakichkolwiek przechowywanych danych.  
195) Specyfikacje elektrycznego interfejsu dla gniazda kalibracji/ 
pobierania danych s ą określone w dodatku 6.  
196) Protoko ły pobierania danych s ą określone w dodatku 7.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 50  
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 drogo ­
wych. Dane takie s ą szyfrowane i podpisywane zgodnie 
z dodatkiem 11 i dodatkiem 14.  
198) Kontrolowane zdalnie dane musz ą być dostępne dla czytników 
na odległość za pośrednictwem łączności bezprzewodowej, jak 
określono w dodatku 14.  
199) Dane niezb ędne na potrzeby ukierunkowanych kontroli drogo ­
wych 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 zapisa ­
nych rekordów danych kalibracji,  
— numeru rejestracyjnego pojazdu,  
— prędkości zarejestrowanej przez tachograf.  
3.20 Wyprowadzanie danych do dodatkowych urz ądzeń zewnętrz­
nych 
▼M1 
200) Urządzenie rejestruj ące może być również wyposażone w znor ­
malizowane interfejsy pozwalaj ące na wykorzystywanie przez 
urządzenie zewn ętrzne danych rejestrowanych lub generowa ­
nych przez tachograf w trybie operacyjnym lub kalibracyjnym.  
W dodatku 13 okre ślono i podano norm ę dla opcjonalnego 
interfejsu ITS. Inne podobne 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 
minimalnego wykazu danych, zabezpiecze ń i zgody kierowcy.  
Zgoda kierowcy nie ma zastosowania do danych przekazywa ­
nych przez urz ądzenie rejestruj ące do sieci pojazdu. W przy ­
padku gdy dane osobowe wprowadzone do sieci pojazdu s ą 
dalej przetwarzane poza sieci ą pojazdu, producent pojazdu jest 
zobowiązany do zapewnienia zgodno ści procedury przetwa ­
rzania danych osobowych z rozporz ądzeniem (UE) 2016/679 
(„ogólne rozporz ądzenie o ochronie danych”).  
Zgoda kierowcy nie ma zastosowania do danych z tachografu 
pobranych zdalnie przez firm ę (wymóg 193), poniewa ż taka 
sytuacja jest monitorowana przez prawo dost ępu karty firmo ­
wej. 
Następujące wymagania maj ą zastosowanie do danych ITS 
udostępnianych za po średnictwem tego interfejsu:  
— dane te stanowi ą zbiór wybranych istniej ących danych ze 
słownika danych tachografu (dodatek 1),  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 51  
— podzbiór tych wybranych danych jest oznaczony jako 
„dane osobowe”,  
— podzbiór „danych osobowych” jest dost ępny jedynie 
w przypadku, gdy w łączona jest opcja podlegaj ącej wery­
fikacji zgody kierowcy na wyprowadzenie jego danych 
osobowych z sieci pojazdu,  
— w dowolnym momencie istnieje mo żliwość potwierdzenia 
lub wycofania zgody kierowcy przez wybranie polecenia 
w menu, pod warunkiem że karta kierowcy jest w łożona, 
— zbiór i podzbiór danych s ą przekazywane za po średnic­
twem protoko łu bezprzewodowego Bluetooth w promieniu 
kabiny pojazdu, z cz ęstotliwością odświeżania co 1 
minutę, 
— sparowanie urz ądzenia zewn ętrznego z interfejsem ITS jest 
zabezpieczone dedykowanym losowym kodem PIN sk ła­
dającym się z co najmniej 4 cyfr, zapisywanym 
i dostępnym przez wy świetlacz ka żdego przyrz ądu rejes­
trującego,  
— w żadnych okoliczno ściach obecno ść interfejsu ITS nie 
może zakłócać prawidłowego funkcjonowania i bezpiecze ń­
stwa przyrz ądu rejestruj ącego ani oddzia ływać na niego.  
Można wyprowadza ć również inne dane oprócz zbioru wybra ­
nych istniej ących danych, uznawanych za wykaz minimalny, 
pod warunkiem że nie można ich uwa żać za dane osobowe.  
Urządzenie rejestruj ące musi posiada ć zdolność do podawania 
statusu zgody kierowcy innym platformom w sieci pojazdu.  
Przy włączonym zap łonie pojazdu dane te udost ępniane są 
nieprzerwanie.  
▼B 
201) Do celów kompatybilno ści wstecznej mo żliwe jest wyposa ­ 
żenie tachografów w interfejs szeregowy, jak okre ślono 
w załączniku 1B do rozporz ądzenia (EWG) nr 3821/85. 
Nadal wymagana jest zgoda kierowcy w przypadku gdy prze ­
kazywane s ą dane osobowe.  
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),  
— 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 zapi ­
sanych w pami ęci danych,  
— aktualizacj ę, w stosownych przypadkach, danych identyfi ­
kacyjnych urz ądzenia zewn ętrznego GNSS zapisanych 
w pamięci danych,  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 52  
— aktualizacj ę rodzajów i identyfikatorów wszystkich za łożo­
nych plomb,  
— aktualizacj ę lub potwierdzenie innych parametrów u żywa­
nych przez urz ądzenie rejestruj ące: identyfikacj ę pojazdu, 
w, l, rozmiar opon i ustawienie urz ądzenia ograniczenia 
prędkości, w stosownych przypadkach.  
203) Ponadto funkcja kalibracji umo żliwia wyłączenie stosowania 
kart do tachografów pierwszej generacji w urz ądzeniu rejes ­
trują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 zapisa ­
nych 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.  
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 iden ­
tyfikacyjnych GNSS, w tym numeru seryjnego urz ądzenia 
zewnętrznego GNSS.  
Po powiązaniu nast ępuje weryfikacja informacji o pozycji 
GNSS.  
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.  
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 przy ­
rządu rejestruj ącego w momencie wys łania żądania.  
208) Odczyt musi by ć możliwy na wy świetlaczu przyrz ądu rejes­
trują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 średnictwem 
interfejsu K-line. Wykonuje si ę to poprzez ECUAdjustmen ­
tSession, jak okre ślono w dodatku 8 sekcja 7 Sterowanie 
impulsami testuj ącymi – Jednostka funkcjonalna sterowania 
we/wy.  
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) odbiornika GNSS.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 53  
211) Ustawienia czasu zegara wewn ętrznego przyrz ądu rejestruj ą­
cego są automatycznie korygowane co 12 godzin. Je żeli 
korekta nie jest mo żliwa, poniewa ż sygnał GNSS nie jest 
dostępny, ustawienie czasu wprowadza si ę, jak tylko przyrz ąd 
rejestrujący uzyska dost ęp do prawid łowego czasu z odbiornika 
GNSS, zale żnie od stanu w łączenia zap łonu pojazdu. Czasem 
odniesienia dla automatycznego ustawienia wewn ętrznego 
zegara przyrz ądu rejestruj ącego jest czas pobrany z odbiornika 
GNSS.  
▼B 
212) W trybie kalibracyjnym funkcja korekty czasu umo żliwia 
również wymuszon ą korektę bieżącego czasu.  
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 wilgot ­
noś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 wykrywanie 
ruchu pojazdu. W takich okoliczno ściach przyrz ąd rejes­
trują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ą wyko­
nane 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 wymagania 
techniczne odnosz ące się do ergonomii.  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 54  
223) Urządzenie rejestruj ące jest zabezpieczone przed przypad ­
kowym uszkodzeniem.  
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ępujące 
informacje:  
— przy liczbie pokazuj ącej odległość, jednostka miary odle ­
gł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 przy ­
padku 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 rejes ­
trują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 umieszczenia 
wszystkich powy ższych informacji, na tabliczce umieszcza si ę 
przynajmniej: nazw ę producenta lub jego logo i numer cz ęści. 
▼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 wersalikiem 
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  NL  Niderlandy  
D 
EST Niemcy 
Estonia  A 
PL Austria 
Polska  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 55  
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  UK  Zjednoczone Króle ­
stwo  
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 przypadkach)  
3. Data urodzenia kierowcy  Imię (imiona) kontrolera 
(w stosownych przypad ­
kach)  Imię (imiona) posiadacza 
karty 
(w stosownych przypadkach)  
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 (fakultatywnie)  
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 — 26.02.2020 — 002.001 — 56  
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 dominuj ą­
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 ępują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ą mikro­
druku.
  
► (1) M1 
236) Po konsultacji z Komisj ą państwa członkowskie mog ą dodać 
kolory lub oznakowania, takie jak symbole pa ństwowe i zabez ­
pieczenia, bez uszczerbku dla innych przepisów w niniejszym 
załączniku.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 57  
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 autentycz ­
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 kartach 
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 ępują­
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 otoczeniem, 
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 warunkach 
klimatycznych normalnie wyst ępujących na terytorium Wspól ­
noty, 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 jedno ­
razowo i nie wi ęcej niż 100 razy w okresie eksploatacji karty.  
242) Karty do tachografów musz ą działać prawidłowo w warunkach 
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 środowi­
skowymi 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 — 26.02.2020 — 002.001 — 58  
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 minu ­
tach, z dok ładnością do 1/10 minuty.  
Funkcje kart do tachografów, polecenia i struktury logiczne, spe ł­
niające wymagania dotycz ące przechowywania danych wyszczegól ­
niono w dodatku 2.  
O ile nie okre ślono inaczej, przechowywanie danych na kartach do 
tachografów odbywa si ę w taki sposób, że najstarsze dane s ą zastę­
powane nowymi danymi, je żeli wyczerpie si ę pamięć przewidziana 
na określone rekordy danych.  
245) W niniejszym punkcie okre ślono minimaln ą pojemność prze­
chowywania danych dla ró żnych zbiorów danych aplikacyj ­
nych. Karty do tachografów przekazuj ą do urządzenia rejes ­
trującego bieżącą pojemność przechowywania danych dla tych 
zbiorów danych.  
246) Wszelkie dodatkowe dane, które mog ą być zapisywane na 
kartach do tachografów, zwi ązane z innymi aplikacjami ewen ­
tualnie zamieszczonymi na karcie, s ą przechowywane zgodnie 
z dyrektyw ą 95/46/WE oraz dyrektyw ą 2002/58/WE oraz 
zgodnie z art. 7 rozporz ądzenia (UE) nr 165/2014.  
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 przy­
rzą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,  
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 ępu­
jących danych identyfikuj ących kartę elektroniczn ą: 
— zatrzymanie zegara,  
— numer seryjny karty ( łącznie z numerem producenta),  
— numer homologacji typu dla karty,  
— identyfikator jednostki personalizuj ącej kartę, 
— identyfikator wbudowuj ącego,  
— identyfikator uk ładu scalonego.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 59  
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 ępu­
ją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 ępu­
jących obiektów danych informacji o rozszerzonej d ługości: 
— jeżeli karta do tachografów obs ługuje pola o rozszerzonej 
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 ępu­
jących obiektów danych informacji o rozszerzonej d ługości: 
— jeżeli karta do tachografów obs ługuje pola o rozszerzonej 
długości, obiekty danych informacji o rozszerzonej 
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.  
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. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 60  
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 wydaj ą­
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),  
— 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),  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 61  
— dane pojazdu musz ą odpowiada ć pojazdowi, w którym 
sesja nie zosta ła zamknięta prawidłowo.  
262) Karta kierowcy umo żliwia przechowywanie danych dotycz ą­
cych sześciu ostatnich zdarze ń każdego typu ( łącznie 36 
zdarzeń). 
4.5.3.1.8 Dane dotycz ące usterek  
Do celów niniejszego podpunktu czas rejestruje si ę z dokładnością 
do 1 sekundy.  
263) Karta kierowcy umo żliwia przechowywanie nast ępujących 
danych dotycz ących usterek wykrytych przez urz ądzenie rejes ­
trują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Ó ŁKIEROW­
CA),  
— status karty (W ŁOŻONA, NIEW ŁOŻONA),  
— czynno ść (PROWADZENIE, GOTOWO ŚĆ, PRACA, 
PRZERWA/ODPOCZYNEK),  
— godzina zmiany.  
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).  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 62  
268) Dane wyszczególnione w wymaganiach 261, 264 i 266 prze ­
chowuje 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ę: 
— data i godzina otwarcia sesji (tj. w łożenia karty) z dok ład­
noś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 wydaj ące 
kartę, 
— rodzaj kontroli (wy świetlanie lub drukowanie lub pobie ­
ranie danych z przyrz ądu rejestruj ącego lub pobieranie 
danych z karty – patrz uwaga),  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 63  
— okres, dla którego pobrano dane, w przypadku pobierania 
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 wprowadzonych 
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.  
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 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.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.  
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 wydaj ą­
cego,  
— numer prawa jazdy (w dniu wydania karty).  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 64  
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),  
— 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 odleg ł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 — 26.02.2020 — 002.001 — 65  
— dane pojazdu musz ą odpowiada ć pojazdowi, w którym 
sesja nie zosta ła zamknięta prawidłowo.  
287) Karta kierowcy umo żliwia przechowywanie danych dotycz ą­
cych sześciu ostatnich zdarze ń każdego typu ( łącznie 66 
zdarzeń). 
4.5.3.2.8 Dane dotycz ące usterek  
Do celów niniejszego podpunktu czas rejestruje si ę z dokładnością 
do 1 sekundy.  
288) Karta kierowcy umo żliwia przechowywanie nast ępujących 
danych dotycz ących usterek wykrytych przez urz ądzenie rejes ­
trują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.  
290) Karta kierowcy umo żliwia przechowywanie nast ępujących 
danych dotycz ących dwunastu ostatnich usterek ka żdego 
rodzaju (łącznie 24 usterki).  
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Ó ŁKIEROW­
CA),  
— status karty (W ŁOŻONA, NIEW ŁOŻONA),  
— czynno ść (PROWADZENIE, GOTOWO ŚĆ, PRACA, 
PRZERWA/ODPOCZYNEK),  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 66  
— godzina zmiany.  
292) 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).  
293) Dane wyszczególnione w wymaganiach 286, 289 i 291 prze ­
chowuje 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.  
295) Karta kierowcy umo żliwia przechowywanie co najmniej 84 
takich rekordów danych.  
4.5.3.2.11 Miejsca i pozycje rozpocz ęcia lub zako ńczenia dziennych 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),  
— 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.  
297) Pami ęć karty kierowcy umo żliwia przechowywanie co 
najmniej 84 par takich rekordów danych.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 67  
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 ład­
noś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 wydaj ą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 pobierania 
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 wprowadzonych 
przy włożonej karcie (niezale żnie od tego, do której szczeliny 
czytnika):  
— data i godzina wprowadzenia danych,  
— rodzaj warunku szczególnego.  
302) Karta kierowcy umo żliwia przechowywanie co najmniej 56 
takich rekordów danych.  
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.  
304) Karta kierowcy umo żliwia przechowywanie co najmniej 84 
takich rekordów danych.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 68  
4.5.3.2.16 Dane miejsc, w których min ęły trzy godziny skumulowanego czasu 
prowadzenia pojazdu  
305) Karta kierowcy umo żliwia przechowywanie nast ępujących 
danych dotycz ących pozycji pojazdu, w których skumulowany 
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.  
306) Karta kierowcy umo żliwia przechowywanie co najmniej 252 
takich rekordów danych.  
▼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.  
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.  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 69  
4.5.4.1.6 Dane dotycz ące kalibracji i korekty czasu  
313) Karta warsztatowa umo żliwia przechowywanie zapisów doty ­
czą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 ędkoś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 doty ­
czących trzech ostatnich zdarze ń każdego rodzaju ( łącznie 18 
zdarzeń) i sześciu ostatnich usterek ka żdego rodzaju ( łącznie 
12 usterek).  
4.5.4.1.8 Dane dotycz ące czynności kierowcy  
320) Karta warsztatowa umo żliwia przechowywanie danych doty ­
czących czynno ści kierowcy, w taki sam sposób jak karta 
kierowcy.  
321) Karta warsztatowa umo żliwia przechowywanie danych doty ­
czących czynno ści kierowcy za co najmniej 1 dzie ń prze­
cię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 dziennych 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 70  
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 doty ­
czą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.  
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 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.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.  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 71  
4.5.4.2.6 Dane dotycz ące kalibracji i korekty czasu  
336) Karta warsztatowa umo żliwia przechowywanie zapisów doty ­
czą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 ędkoś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),  
— 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).  
338) Karta warsztatowa umo żliwia przechowywanie co najmniej 88 
takich rekordów danych.  
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 doty ­
czą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 doty ­
czących czynno ści kierowcy, w taki sam sposób jak karta 
kierowcy.  
344) Karta warsztatowa umo żliwia przechowywanie danych doty ­
czących czynno ści kierowcy za co najmniej 1 dzie ń prze­
ciętnej aktywno ści kierowcy.  
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.  
346) Karta warsztatowa umo żliwia przechowywanie co najmniej 4 
takich rekordów.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 72  
4.5.4.2.10 Dane dotycz ące rozpocz ęcia lub zako ńczenia dziennych okresów 
pracy  
347) Karta warsztatowa umo żliwia przechowywanie rekordów 
danych dotycz ących rozpocz ęcia lub zako ńczenia dziennych 
okresów pracy, w taki sam sposób jak karta kierowcy.  
348) Karta warsztatowa umo żliwia przechowywanie co najmniej 3 
par takich rekordów danych.  
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.  
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.  
352) Karta warsztatowa umo żliwia przechowywanie co najmniej 4 
takich rekordów.  
▼M1 
4.5.4.2.14 Dane miejsc, w których min ęły trzy godziny skumulowanego 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 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.  
354) Karta warsztatowa umo żliwia przechowywanie co najmniej 18 
takich rekordów danych.  
▼B 
4.5.4.2.15 Dane dotycz ące warunków szczególnych  
355) Karta warsztatowa umo żliwia przechowywanie danych doty ­
czących warunków szczególnych, w taki sam sposób jak karta 
kierowcy.  
356) Karta warsztatowa umo żliwia przechowywanie co najmniej 2 
takich rekordów.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 73  
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,  
— 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 zastosowanie),  
— numer VRN i pa ństwo członkowskie rejestracji kontrolo ­
wanego pojazdu,  
— numer karty i pa ństwo członkowskie wydaj ące kontrolo ­
waną kartę kierowcy.  
362) Karta kontrolna umo żliwia przechowywanie co najmniej 230 
takich rekordów danych.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 74  
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.  
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,  
— 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 zastosowanie),  
— numer VRN i pa ństwo członkowskie rejestracji kontrolo ­
wanego pojazdu,  
— numer karty i pa ństwo członkowskie wydaj ące kontrolo ­
waną kartę kierowcy.  
368) Karta kontrolna umo żliwia przechowywanie co najmniej 230 
takich rekordów danych.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 75  
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.  
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 zastosowanie),  
— 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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 76  
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.  
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.  
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 zastosowanie),  
— 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.  
5 INSTALACJA URZ ĄDZENIA REJESTRUJ ĄCEGO  
5.1 Instalacja  
381) Nowe urz ądzenie rejestruj ące dostarcza si ę instalatorom lub 
producentom pojazdów w stanie nieaktywowanym, ze wszyst ­
kimi parametrami kalibracyjnymi, wyszczególnionymi 
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 liczbowe jako „0”. 
Dostawę części układu zabezpieczaj ącego urządzeń rejestrują­
cych można w razie konieczno ści ograniczy ć podczas certyfi ­
kacji bezpiecze ństwa. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 77  
382) Przed aktywacj ą urządzenie rejestruj ące umożliwia dostęp do 
funkcji kalibracji, nawet je śli nie jest w trybie kalibracyjnym.  
383) Przed aktywacj ą urządzenie rejestruj ące nie może rejestrowa ć 
ani przechowywa ć danych, o których mowa w pkt 3.12.3, 
3.12.9 oraz 3.12.12–3.12.15.  
384) W czasie instalacji producenci pojazdów wst ępnie ustawiaj ą 
wszystkie znane parametry.  
385) Producenci pojazdów lub instalatorzy aktywuj ą zainstalowane 
urządzenie rejestruj ące najpóźniej przed rozpocz ęciem korzys ­
tania z pojazdu w zakresie obj ętym rozporz ądzeniem (WE) nr 
561/2006.  
386) Aktywacja urz ądzenia rejestruj ącego uruchamiana jest automa ­
tycznie przez pierwsze w łożenie ważnej karty warsztatowej do 
któregokolwiek czytnika karty.  
387) Szczególne czynno ści parujące, wymagane mi ędzy czujnikiem 
ruchu a przyrz ądem rejestruj ącym, odbywaj ą się w razie 
potrzeby automatycznie przed aktywacj ą lub w trakcie akty ­
wacji.  
388) Podobnie szczególne czynno ści powiązania, wymagane 
między urządzeniem zewn ętrznym GNSS a przyrz ądem rejes­
trują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.  
392) Następnym krokiem po instalacji jest kalibracja. Podczas 
pierwszej kalibracji nie jest konieczne wprowadzenie numeru 
rejestracyjnego pojazdu (VRN), je żeli nie jest on znany 
zatwierdzonemu warsztatowi maj ącemu przeprowadzi ć kalib­
rację. W tej sytuacji, i tylko wtedy, w łaściciel pojazdu mo że 
wprowadzi ć numer VRN, 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 przy ­
rządu rejestruj ącego) (  1 ). Każda aktualizacja lub potwierdzenie 
wprowadzonych w ten sposób danych s ą możliwe jedynie 
przy użyciu karty warsztatowej.  
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.  ▼B 
( 1 ) Dz.U. L 102 z 11.4.2006, s. 1.
 02016R0799 — PL — 26.02.2020 — 002.001 — 78  
5.2 Tabliczka instalacyjna  
395) Po zainstalowaniu i sprawdzeniu urz ądzenia rejestruj ącego 
mocuje się na nim dobrze widoczn ą i łatwo dostępną tabliczkę 
instalacyjn ą, wygrawerowan ą lub nadrukowan ą 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 przy ­
padku pojazdów, które nie posiadaj ą słupka „B”, tabliczk ę 
instalacyjn ą należy umocowa ć na ościeżnicy po stronie 
kierowcy pojazdu, tak aby zawsze by ła dobrze widoczna.  
Po każdym przegl ądzie przeprowadzonym przez zatwierdzo ­
nego instalatora lub warsztat, w miejsce starej tabliczki mocuje 
się nową. 
▼M1 
396) Tabliczka zawiera co najmniej nast ępujące dane:  
— nazwa, adres lub nazwa handlowa zatwierdzonego instala ­
tora 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 stosow ­
nych przypadkach,  
— numer seryjny urz ądzenia do łączności na odleg łość, jeżeli 
występuje,  
— 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 przy ­
padku niezastosowania adaptera,  
— kolor przewodu łączącego adapter z cz ęścią pojazdu, 
z której dochodz ą impulsy,  
— numer seryjny czujnika ruchu wbudowanego w adapter.  
▼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 zamieszczenia 
wszystkich niezb ędnych informacji opisanych w wymaganiu 
396. W takich przypadkach na dodatkowej tabliczce zamiesz ­
czane są co najmniej ostatnie cztery tiret okre ślone w wyma ­
ganiu 396.  ▼B 
( 1 ) Rozporz ądzenie Komisji (WE) nr 68/2009 z dnia 23 stycznia 2009 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 — 26.02.2020 — 002.001 — 79  
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 niewykrywalne 
utraty danych (mo że to dotyczy ć np. instalacji czujnika 
ruchu na skrzyni biegów, adapterów w pojazdach M1/N1, 
połączenia z urz ądzeniem zewn ętrznym GNSS lub przy ­
rzą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ć certyfikowane 
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 zaplombowane przez 
zatwierdzonego instalatora lub warsztat (zgodnie 
z rozdziałem 6) niezw łocznie po zainstalowaniu 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 niedaj ą­
cego się usunąć oznakowania, gdzie MM to jednoznaczny 
identyfikator producenta (numer w bazie danych prowa ­
dzonej przez KE), a NNNNNNNN to numer alfanumeryczny 
plomby, niepowtarzalny dla danego producenta.  
▼B 
402) Na plombie musi by ć wolne miejsce, na którym zatwierdzeni 
instalatorzy, warsztaty lub producenci pojazdów mog ą dodać 
specjalny znak zgodnie z art. 22 ust. 3 rozporz ądzenia (UE) 
nr 165/2014.  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 80  
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ą doku­
mentację umożliwiającą identyfikowalno ść plomb sprzedawa ­
nych 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/2014, zosta ły zdefiniowane w rozdziale 5.3 niniejszego za łącz­
nika.  
6.1 Zatwierdzanie instalatorów, warsztatów i producentów 
pojazdów  
Państwa członkowskie zatwierdzaj ą, regularnie kontroluj ą i certyfi­
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 istnieją 
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 kontrolo ­
wany pod wzgl ędem prawid łowego funkcjonowania oraz 
dokładności odczytów i rejestracji, w granicach okre ślonych 
w rozdziałach 3.2.1, 3.2.2, 3.2.3 oraz 3.3.  
▼B 
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 obej ­
mować kalibrację. 
▼B 
6.4 Przegl ądy okresowe  
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ż 20 minut, lub 
przy zmianie numeru VRN i przynajmniej raz w okresie 
dwóch lat (24 miesi ęcy) od ostatniej kontroli.  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 81  
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 instala ­
cji, 
— czy jest zachowana zgodno ść z przepisami rozdzia łów 
3.2.3 i 3.3,  
— czy urz ądzenie rejestruj ące opatrzone jest znakiem homo ­
logacji typu,  
— czy tabliczka instalacyjna okre ślona w wymaganiu 396 
oraz tabliczka okre ślona w wymaganiu 225 s ą zamoco­
wane,  
— 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).  
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 łączo­
nego do skrzyni biegów z danymi sparowanego czujnika 
ruchu zarejestrowanymi w przyrz ądzie rejestruj ą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 czujnika 
ruchu, są zgodne z informacjami przechowywanymi 
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 przegl ądu 
wszystkie ustalenia dotycz ące zniszczonych plomb lub urz ą­
dzeń służących do manipulacji. Warsztaty przechowuj ą 
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:  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 82  
— 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 przynajmniej 
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ść. 
6.6 Naprawy  
415) Warsztaty mog ą pobierać dane z urz ądzenia rejestruj ącego 
w celu przekazania tych danych odpowiedniej firmie prze ­
wozowej.  
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 zastoso ­
wanie), a numer wymiany i numer odnowienia ustawione na 
„0”. 
418) Numery karty wszystkich nieosobistych kart do tachografó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 odno ­
wiona, z wyj ątkiem numeru wymiany, który jest ustawiony 
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 pierw ­
szym wydaniu, je żeli odbywa si ę w innym pa ństwie człon­
kowskim.  
423) W rubryce „nazwisko posiadacza karty” w przypadku nieoso ­
bistych kart warsztatowych lub kontrolnych wpisuje si ę albo 
nazwę warsztatu lub organu kontrolnego albo nazwisko insta ­
latora lub funkcjonariusza s łużb kontrolnych, wed ług uznania 
państw członkowskich.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 83  
424) Państwa członkowskie wymieniaj ą dane drog ą elektroniczn ą 
w celu zapewnienia niepowtarzalno ści wydawanych kart 
kierowcy zgodnie z art. 31 rozporz ądzenia (UE) nr 165/2014.  
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. Papier 
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 przy ­
rządu rejestruj ącego.  
Niemniej jednak po uzyskaniu homologacji typu urz ądzenia rejes ­
trującego producenci prowadz ą powszechnie dost ępny wykaz anten 
i rozdzielaczy kompatybilnych z ka żdym homologowanym przy ­
rzą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 tacho ­
grafów obejmuje badania zwi ązane z bezpiecze ństwem, 
badania funkcjonalno ści i badania interoperacyjno ści. Pozy­
tywne wyniki ka żdego z tych bada ń potwierdza si ę odpo­
wiednim świadectwem.  
▼M1 
427) Organy homologacji typu w pa ństwach członkowskich nie 
wydają świadectwa homologacji typu, dopóki nie otrzymaj ą: 
— świadectwa bezpiecze ństwa (jeżeli jest ono wymagane na 
podstawie niniejszego za łącznika),  
— świadectwa funkcjonalno ści, 
— świadectwa interoperacyjno ści (jeżeli jest ono wymagane 
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
 02016R0799 — PL — 26.02.2020 — 002.001 — 84  
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 homologacji typu lub 
też może zażądać uaktualnienia lub potwierdzenia stosow ­
nych świadectw funkcjonalno ści, bezpiecze ństwa lub intero ­
peracyjności. 
429) Procedury aktualizacji oprogramowania w prawid łowo funk­
cjonującym urządzeniu rejestruj ącym zatwierdza organ, który 
wydał homologacj ę typu dla tego urz ądzenia rejestruj ącego. 
Aktualizacja oprogramowania nie mo że zmienić ani usunąć 
żadnych danych dotycz ących czynno ści kierowcy przecho ­
wywanych w pami ęci urządzenia rejestruj ącego. Oprogramo ­
wanie 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 homologo ­
wanego typu urz ądzenia rejestruj ącego, jeżeli takie zmiany 
dotyczą wyłącznie funkcji nieokre ślonych w niniejszym 
załączniku. Aktualizacja oprogramowania urz ądzenia rejes ­
trującego może nie obejmowa ć wprowadzania nowych 
zestawów znaków, je śli nie jest to technicznie wykonalne.  
8.2 Świadectwo bezpiecze ństwa  
431) Świadectwo bezpiecze ństwa wydaje si ę zgodnie z przepisami 
dodatku 10 do niniejszego za łącznika. Elementy sk ładowe 
urządzenia rejestruj ącego objęte certyfikacj ą to przyrz ą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 konkretnych i wyj ątko­
wych 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 homologacji 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 85  
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 uzyskanych 
wyników.  
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 rejestru ­
ją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 laboratorium 
w imieniu i na odpowiedzialno ść Komisji Europejskiej.  
441) Laboratorium rejestruje wnioski o badania interoperacyjno ści 
złożone przez producentów w kolejno ści chronologicznej 
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.  
443) Laboratorium nie przeprowadza żadnych bada ń interoperacyj ­
ności urządzeń rejestrujących ani kart do tachografów, 
którym nie przyznano świadectwa bezpiecze ństwa i świa­
dectwa funkcjonalno ści, poza wyj ątkowymi sytuacjami opisa ­
nymi w wymaganiu 432.  
444) Producent wnioskuj ący o przeprowadzenie bada ń interopera ­
cyjności zobowiązuje się do pozostawienia w laboratorium, 
które ma przeprowadzi ć te badania, kompletu materia łów 
i dokumentów, które dostarczy ł do przeprowadzenia tych 
badań. 
445) Badania interoperacyjno ści przeprowadza si ę, zgodnie z prze ­
pisami dodatku 9 do niniejszego za łącznika, dla, odpowied ­
nio, 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.  
447) Laboratorium wydaje producentowi świadectwo interopera ­
cyjności tylko wtedy, gdy obj ęte nim urz ądzenia pomy ślnie 
przejdą wszystkie wymagane badania interoperacyjno ści. 
448) Jeżeli co najmniej jedno urz ądzenie rejestruj ące lub karta do 
tachografów nie przejd ą pomyślnie badań interoperacyjno ści, 
świadectwa interoperacyjno ści nie wydaje si ę, dopóki wniosku ­
ją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,  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 86  
rozpoznaje przyczyn ę usterki interoperacyjno ści i dokłada 
starań, by pomóc wnioskuj ącemu producentowi w znalezieniu 
rozwiązania technicznego. W przypadku gdy producent mody ­
fikuje 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 świadectwa 
homologacji typu. Producent przekazuje to świadectwo orga ­
nowi homologacji typu w pa ństwie członkowskim, 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 łado­
wego urządzenia rejestruj ącego wskazuje si ę także numery 
homologacji typu innych homologowanych interoperacyjnych 
urządzeń rejestrujących.  
453) Organ homologacji typu przekazuje kopi ę świadectwa homo ­
logacji typu do laboratorium w łaściwego do przeprowadzenia 
badań interoperacyjno ści równocze śnie z dostarczeniem świa­
dectwa producentowi.  
454) Laboratorium w łaściwe do przeprowadzenia bada ń interope­
racyjnoś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. generacji 
(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 — 26.02.2020 — 002.001 — 87  
456) Jeżeli na koniec tego okresu wszystkie produkty, których to 
dotyczy, wspó łdziałają, wszystkie odpowiednie świadectwa 
interoperacyjno ści zastępuje się świadectwem ostatecznym.  
457) Jeżeli w tym okresie wykryje si ę usterki interoperacyjno ści, 
laboratorium w łaściwe do przeprowadzenia bada ń interopera ­
cyjności rozpoznaje przyczyny problemów z pomoc ą wszyst­
kich zainteresowanych producentów i zach ęca ich do wpro ­
wadzenia niezb ędnych poprawek.  
458) Jeżeli na koniec tego okresu nadal wyst ępują problemy inte ­
roperacyjno ści, laboratorium w łaściwe do przeprowadzenia 
badań interoperacyjno ści, we wspó łpracy z zainteresowanymi 
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. Poszu ­
kiwanie 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 ń interoperacyjno ści, 
decyduje, które urz ądzenie(-a) i karty otrzymuj ą ostateczne 
świadectwa interoperacyjno ści wraz z uzasadnieniem swojej 
decyzji.  
459) Wszelkie wnioski o przeprowadzenie bada ń interoperacyjno ­ 
ś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 ą odra­
czane aż do rozwiązania pocz ątkowych problemów interope ­
racyjności. Następnie wnioski te rozpatruje si ę w kolejno ści 
chronologicznej ich rejestracji.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 88  
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  
2.12. CardCertificate  
2.13. CardChipIdentification  
2.14. CardConsecutiveIndex  
2.15. CardControlActivityDataRecord  
2.16. CardCurrentUse  
2.17. CardDriverActivity  
2.18. CardDrivingLicenceInformation  
2.19. CardEventData  
2.20. CardEventRecord  
2.21. CardFaultData  
2.22. CardFaultRecord  
2.23. CardIccIdentification  
2.24. CardIdentification  
2.25. CardMACertificate  
2.26. CardNumber  
2.27. CardPlaceDailyWorkPeriod  
2.28. CardPrivateKey  
2.29. CardPublicKey  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 89  
2.30. CardRenewalIndex  
2.31. CardReplacementIndex  
2.32. CardSignCertificate  
2.33. CardSlotNumber  
2.34. CardSlotsStatus  
2.35. CardSlotsStatusRecordArray  
2.36. CardStructureVersion  
2.37. CardVehicleRecord  
2.38. CardVehiclesUsed  
2.39. CardVehicleUnitRecord  
2.40. CardVehicleUnitsUsed  
2.41. Certyfikat  
2.42. CertificateContent  
2.43. CertificateHolderAuthorisation  
2.44. CertificateRequestID  
2.45. CertificationAuthorityKID  
2.46. CompanyActivityData  
2.47. CompanyActivityType  
2.48. CompanyCardApplicationIdentification  
2.49. CompanyCardHolderIdentification  
2.50. ControlCardApplicationIdentification  
2.51. ControlCardControlActivityData  
2.52. ControlCardHolderIdentification  
2.53. ControlType  
2.54. CurrentDateTime  
2.55. CurrentDateTimeRecordArray  
2.56. DailyPresenceCounter  
2.57. Datef  
2.58. DateOfDayDownloaded  
2.59. DateOfDayDownloadedRecordArray  
2.60. Distance  
2.61. DriverCardApplicationIdentification  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 90  
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  
2.74. FullCardNumberAndGeneration  
2.75. Generation  
2.76. GeoCoordinates  
2.77. GNSSAccuracy  
▼M1 
2.78. GNSSAccumulatedDriving  
2.79. GNSSAccumulatedDrivingRecord  
▼B 
2.80. GNSSPlaceRecord  
2.81. HighResOdometer  
2.82. HighResTripDistance  
2.83. HolderName  
2.84. InternalGNSSReceiver  
2.85. K-ConstantOfRecordingEquipment  
2.86. KeyIdentifier  
2.87. KMWCKey  
2.88. Language  
2.89. LastCardDownload  
2.90. LinkCertificate  
2.91. L-TyreCircumference  
2.92. MAC  
2.93. ManualInputFlag  
2.94. ManufacturerCode  
2.95. ManufacturerSpecificEventFaultData  
2.96. MemberStateCertificate  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 91  
2.97. MemberStateCertificateRecordArray  
2.98. MemberStatePublicKey  
2.99. Name  
2.100. NationAlpha  
2.101. NationNumeric  
2.102. NoOfCalibrationRecords  
2.103. NoOfCalibrationsSinceDownload  
2.104. NoOfCardPlaceRecords  
2.105. NoOfCardVehicleRecords  
2.106. NoOfCardVehicleUnitRecords  
2.107. NoOfCompanyActivityRecords  
2.108. NoOfControlActivityRecords  
2.109. NoOfEventsPerType  
2.110. NoOfFaultsPerType  
▼M1 
2.111. NoOfGNSSADRecords  
▼B 
2.112. NoOfSpecificConditionRecords  
2.113. OdometerShort,  
2.114. OdometerValueMidnight  
2.115. OdometerValueMidnightRecordArray  
2.116. OverspeedNumber  
2.117. PlaceRecord  
2.118. PreviousVehicleInfo  
2.119. PublicKey  
2.120. RecordType  
2.121. RegionAlpha  
2.122. RegionNumeric  
2.123. RemoteCommunicationModuleSerialNumber  
2.124. RSAKeyModulus  
2.125. RSAKeyPrivateExponent  
2.126. RSAKeyPublicExponent  
2.127. RtmData  
2.128. SealDataCard  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 92  
2.129. SealDataVu  
2.130. SealRecord  
2.131. SensorApprovalNumber  
2.132. SensorExternalGNSSApprovalNumber  
2.133. SensorExternalGNSSCoupledRecord  
2.134. SensorExternalGNSSIdentification  
2.135. SensorExternalGNSSInstallation  
2.136. SensorExternalGNSSOSIdentifier  
2.137. SensorExternalGNSSSCIdentifier  
2.138. SensorGNSSCouplingDate  
2.139. SensorGNSSSerialNumber  
2.140. SensorIdentification  
2.141. SensorInstallation  
2.142. SensorInstallationSecData  
2.143. SensorOSIdentifier  
2.144. SensorPaired  
2.145. SensorPairedRecord  
2.146. SensorPairingDate  
2.147. SensorSCIdentifier  
2.148. SensorSerialNumber  
2.149. Podpis  
2.150. SignatureRecordArray  
2.151. SimilarEventsNumber  
2.152. SpecificConditionRecord  
2.153. SpecificConditions  
2.154. SpecificConditionType  
2.155. Pr ędkość 
2.156. SpeedAuthorised  
2.157. SpeedAverage  
2.158. SpeedMax  
2.159. TachographPayload  
▼M1 
2.160. Zarezerwowany dla przysz łego użytku ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 93  
2.161. TDesSessionKey  
2.162. TimeReal  
2.163. TyreSize  
2.164. VehicleIdentificationNumber  
2.165. VehicleIdentificationNumberRecordArray  
2.166. VehicleRegistrationIdentification  
2.167. VehicleRegistrationNumber  
2.168. VehicleRegistrationNumberRecordArray  
2.169. VuAbility  
2.170. VuActivityDailyData  
2.171. VuActivityDailyRecordArray  
2.172. VuApprovalNumber  
2.173. VuCalibrationData  
2.174. VuCalibrationRecord  
2.175. VuCalibrationRecordArray  
2.176. VuCardIWData  
2.177. VuCardIWRecord  
2.178. VuCardIWRecordArray  
2.179. VuCardRecord  
2.180. VuCardRecordArray  
2.181. VuCertificate  
2.182. VuCertificateRecordArray  
2.183. VuCompanyLocksData  
2.184. VuCompanyLocksRecord  
2.185. VuCompanyLocksRecordArray  
2.186. VuControlActivityData  
2.187. VuControlActivityRecord  
2.188. VuControlActivityRecordArray  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 94  
2.189. VuDataBlockCounter  
2.190. VuDetailedSpeedBlock  
2.191. VuDetailedSpeedBlockRecordArray  
2.192. VuDetailedSpeedData  
2.193. VuDownloadablePeriod  
2.194. VuDownloadablePeriodRecordArray  
2.195. VuDownloadActivityData  
2.196. VuDownloadActivityDataRecordArray  
2.197. VuEventData  
2.198. VuEventRecord  
2.199. VuEventRecordArray  
2.200. VuFaultData  
2.201. VuFaultRecord  
2.202. VuFaultRecordArray  
▼M1 
2.203. VuGNSSADRecord  
2.204. VuGNSSADRecordArray  
▼B 
2.205. VuIdentification  
2.206. VuIdentificationRecordArray  
2.207. VuITSConsentRecord  
2.208. VuITSConsentRecordArray  
2.209. VuManufacturerAddress  
2.210. VuManufacturerName  
2.211. VuManufacturingDate  
2.212. VuOverSpeedingControlData  
2.213. VuOverSpeedingControlDataRecordArray  
2.214. VuOverSpeedingEventData  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 95  
2.215. VuOverSpeedingEventRecord  
2.216. VuOverSpeedingEventRecordArray  
2.217. VuPartNumber  
2.218. VuPlaceDailyWorkPeriodData  
2.219. VuPlaceDailyWorkPeriodRecord  
2.220. VuPlaceDailyWorkPeriodRecordArray  
2.221. VuPrivateKey  
2.222. VuPublicKey  
2.223. VuSerialNumber  
2.224. VuSoftInstallationDate  
2.225. VuSoftwareIdentification  
2.226. VuSoftwareVersion  
2.227. VuSpecificConditionData  
2.228. VuSpecificConditionRecordArray  
2.229. VuTimeAdjustmentData  
▼M1 
2.230. Zarezerwowany dla przysz łego użytku 
2.231. Zarezerwowany dla przysz łego użytku 
▼B 
2.232. VuTimeAdjustmentRecord  
2.233. VuTimeAdjustmentRecordArray  
2.234. WorkshopCardApplicationIdentification  
2.235. WorkshopCardCalibrationData  
2.236. WorkshopCardCalibrationRecord  
2.237. WorkshopCardHolderIdentification  
2.238. WorkshopCardPIN  
2.239. W-VehicleCharacteristicConstant  
2.240. VuPowerSupplyInterruptionRecord  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 96  
2.241. VuPowerSupplyInterruptionRecordArray  
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 struktury 
danych przeznaczone do wykorzystania w urz ądzeniach rejestruj ących 
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 prostych 
i strukturalnych danych bez narzucania żadnej swoistej sk ładni przesy ­ 
łania danych (regu ł kodowania), która zale ży od aplikacji i środowiska.  
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 nazwa 
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 ącym, to 
ten typ ASN.1 jest zdefiniowany w niniejszym dodatku.  
Aby umo żliwić stosowanie kilku regu ł kodowania, niektóre typy 
ASN.1 w niniejszym dodatku s ą ograniczone identyfikatorami zakresu 
wartoś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 — 26.02.2020 — 002.001 — 97  
ISO/IEC 7816-5 Karty identyfikacyjne — Elektroniczne karty stykowe 
— część 5: Rejestracja identyfikatorów aplikacji  
Wydanie drugie: 2004.  
ISO/IEC 7816-6 Karty identyfikacyjne — Elektroniczne karty stykowe 
— 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  
Dla każdego z nast ępujących typów danych warto ść domyślna „nie­
znane” lub zawarto ść „nie dotyczy” polega na wype łnieniu elementu 
danych bajtami „FF”.  
Wszystkie typy danych s ą wykorzystywane w aplikacjach generacji 1 
i generacji 2, chyba że określono inaczej.  
▼M1 
W przypadku typów danych karty u żywanych do aplikacji generacji 1 
i generacji 2, wielko ść określona w niniejszym dodatku to wielko ść dla 
aplikacji generacji 2. Wielko ść dla aplikacji generacji 1 powinna by ć już 
znana dla czytnika. Numery wymogów dotycz ących takich typów 
danych okre ślone w załączniku IC obejmuj ą zarówno aplikacje generacji 
1, jak i generacji 2.  
▼B 
2.1. ActivityChangeInfo  
Ten typ danych umo żliwia kodowanie, w dwubajtowym s łowie, stanu 
szczeliny czytnika o godzinie 00:00 lub statusu kierowcy o godzinie 
00:00 lub zmiany czynno ści, lub zmiany stanu prowadzenia pojazdu, 
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,  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 98  
‘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 kierow ­
cy): 
‘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)  
‘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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 99  
Uwaga dla przypadku „wyj ęcie karty”:  
Gdy karta jest wyj ęta: 
— „s” odnosi si ę do szczeliny czytnika i wskazuje szczelin ę czytnika, 
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 (zapi­
sanego na karcie) mog ą być nadpisane pó źniej w celu odzwierciedlania 
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ę. 
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. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 100  
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 dziesi ętnym 
kodowanym dwójkowo (BCD). Tego typu danych u żywa się do przed­
stawiania jednej cyfry dziesi ętnej w pó łoktecie (4 bity). BCDString 
oparty jest na definicji z normy ISO/IEC 8824-1 „CharacterStringType”.
  
BCDString u żywa notacji „hstring”. Skrajna lewa cyfra heksadecymalna 
jest najbardziej znacz ącym półoktetem pierwszego oktetu. Aby utworzy ć 
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 kalibracyj ­
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 łączniku 
1C.
 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 101  
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 akty ­
wacji,  
‘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ługość 
OCTET STRING zawieraj ącego te rekordy (zob. pkt 4 CardActivityLen ­
gthRange w dodatku 2). Gdy rekord ten jest najstarszym rekordem 
dziennym, warto ść activityPreviousRecordLength musi by ć ustawiona 
na 0.  
activityRecordLength  jest całkowitą długością tego rekordu w bajtach. 
Maksymaln ą wartość określa długość OCTET STRING zawieraj ącego te 
rekordy.  
activityRecordDate  jest datą rekordu.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 102  
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 (jedna 
zmiana czynno ści na minut ę). W tym zbiorze danych zawsze znajduje 
się activityChangeInfo okre ślający status kierowcy o godzinie 00:00.  
2.10.  CardActivityLengthRange  
Liczba bajtów na karcie kierowcy lub na karcie warsztatowej, dost ę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.  
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). IcSerialNumber 
wraz z icManufacturingReferences identyfikuj ą w sposób niepowtarzalny 
chip karty. Sam IcSerialNumber nie identyfikuje chipu karty w sposób 
niepowtarzalny.
  
icSerialNumber  jest numerem seryjnym IC.  
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’  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 103  
2.15.  CardControlActivityDataRecord  
Informacje przechowywane na karcie kierowcy lub warsztatowej doty ­
czące ostatniej kontroli, której poddany by ł kierowca (wymagania 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 okre­
sem, dla którego pobrano dane, w przypadku pobierania danych.  
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.  
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 activityDailyRe ­
cords. Maksymalna warto ść jest określona długością łańcucha.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 104  
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: CardActivi ­
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 nowe 
rekordy do łącza się do końca poprzedniego rekordu. Gdy łańcuch zostaje 
zapełniony wype łnianie rozpoczyna si ę od pierwszego bajtu łańcucha 
niezależnie od przerwy w elemencie danych. Przed wstawieniem do 
łańcucha danych o nowej czynno ści (zwiększenie bie żącego rekordu 
activityDailyRecord lub wstawienie nowego rekordu activityDailyRe ­
cord), który zamienia stare dane o starej czynno ści, wskaźnik activity ­
PointerOldestDayRecord musi by ć uaktualniony w celu odzwierciedlenia 
nowego po łożenia najstarszego, pe łnego rekordu dziennego a d ługość 
activityPreviousRecordLength tego (nowego) najstarszego, pe łnego 
rekordu dziennego musi by ć wyzerowana.  
2.18.  CardDrivingLicenceInformation  
Informacje przechowywane na karcie kierowcy dotycz ące prawa jazdy 
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.  
▼M1 
2.19.  CardEventData  
Generacja 1:  
Informacje przechowywane na karcie kierowcy lub warsztatowej doty ­
czące zdarzeń związanych z posiadaczem karty (wymagania 260 i 318 
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 groma ­
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:  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 105  
Informacje przechowywane na karcie kierowcy lub warsztatowej doty ­
czące zdarzeń związanych z posiadaczem karty (wymagania 285 i 341 
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 groma ­
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 (wyma ­
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.  
2.21.  CardFaultData  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotycz ące usterek zwi ązanych z posiadaczem karty (wymagania 
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 (wymagania 
264, 289, 318 i 341 okre ślone w załączniku 1C).
  
faultType  jest typem usterki.  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 106  
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 uk ł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.  
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 (wymagania 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 107  
cardExpiryDate  jest terminem wa żności karty.  
2.25.  CardMACertificate  
Generacja 2:  
Certyfikat klucza publicznego karty na potrzeby wzajemnego uwierzy ­
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 warsz ­
tatowej, karty kontrolnej i karty firmowej.  
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łączniku 
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 rekordów 
miejsca w strukturze.  
placeRecords  jest zbiorem rekordów dotycz ących wprowadzonych 
miejsc.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 108  
2.28.  CardPrivateKey  
Generacja 1:  
Klucz prywatny karty.
  
2.29.  CardPublicKey  
Klucz publiczny karty.
  
▼M1 
2.30.  CardRenewalIndex  
Numer odnowienia karty (definicja i)).
  
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 rejes­
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 karty 
przyrządu rejestruj ącego.
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 109  
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. 
2.35.  CardSlotsStatusRecordArray  
Generacja 2:  
CardSlotsStatus wraz z metadanymi stosowany w protokole pobierania 
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  
‘bb’H indeks zmian dotycz ących użycia elementów danych 
zdefiniowanych dla struktury okre ślony wyższym 
bajtem.  
‘00’H dla tej wersji aplikacji generacji 1  
‘00’H la tej wersji aplikacji generacji 2  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 110  
2.37.  CardVehicleRecord  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotycz ące okresu u żywania pojazdu w czasie dnia kalendarzo ­
wego (wymagania 269, 294, 322 i 345 okre ślone w za łączniku 1C).  
Generacja 1:
  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 111  
Przypisanie warto ści: liczba odpowiadaj ąca stanowi licznika rekordów 
dotyczących pojazdu, rozpoczynaj ąc od „0” dla pierwszego wyst ąpienia 
w strukturze rekordów dotycz ących pojazdu.  
cardVehicleRecords  jest zbiorem rekordów zawieraj ących informacje 
o używanych pojazdach.  
2.39.  CardVehicleUnitRecord  
Generacja 2:  
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  
Generacja 2:  
Informacje przechowywane na karcie kierowcy lub na karcie warsz ­
tatowej dotycz ące przyrządów rejestruj ących używanych przez posia ­
dacza karty (wymagania 306 i 352 okre ślone w załączniku 1C).
  
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 wyst ą­
pienia w strukturze rekordów dotycz ących przyrz ądu rejestruj ącego.  
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:
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 112  
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 klucza 
publicznego (58 bajtów) || Odno śnik do organu certyfikacji: (8 bajtów)  
Generacja 2:
  
Przypisanie warto ści: zob. dodatek 11  
2.42.  CertificateContent  
Generacja 1:  
Treść certyfikatu klucza publicznego zgodnie z dodatkiem 11 – Wspó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 certyfi ­
katu.  
certificateEndOfValidity  jest datą administracyjnego wyga śnięcia certy­
fikatu.  
certificateHolderReference  identyfikuje posiadacza certyfikatu. Jest tu 
także odesłanie do jego klucza publicznego.  
publicKey  jest kluczem publicznym, który jest po świadczony tym certy ­
fikatem.  
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 aplikacji 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 — 26.02.2020 — 002.001 — 113  
Generacja 2:  
tachographApplicationID  oznacza 6 najbardziej znacz ących bajtów 
odpowiedniego identyfikatora aplikacji (AID) karty do tachografu gene ­
racji 2. AID dla aplikacji karty do tachografu okre ślono w rozdziale 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 rejestruj ącego, 
jeżeli numer seryjny przyrz ądu rejestruj ącego, do którego ten klucz 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 certyfi ­
kat. 
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 certyfikacji 
państwa członkowskiego lub europejskiego organu certyfikacji).
  
nationNumeric  jest numerycznym kodem krajowym organu certyfikacji.  
nationAlpha  jest alfanumerycznym kodem krajowym organu certyfika ­
cji. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 114  
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 kluczy.  
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 ąpienia 
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 zablokowano, 
lub zdjęto blokadę. 
downloadPeriodBegin  i downloadPeriodEnd  jest okresem, dla którego 
pobrano dane z VU, gdy dotyczy.  
2.47.  CompanyActivityType  
Kod wskazuj ący czynno ść wykonaną przez firm ę z wykorzystaniem jej 
karty firmowej.
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 115  
2.48.  CompanyCardApplicationIdentification  
Informacje przechowywane na karcie firmowej dotycz ące identyfikacji 
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.  
2.49.  CompanyCardHolderIdentification  
Informacje przechowywane na karcie firmowej dotycz ące identyfikacji 
posiadacza karty (wymagania 372 i 378 okre ślone w za łączniku 1C).
  
companyName  jest nazw ą firmy posiadaj ącej kartę. 
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 identyfikacji 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 116  
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.  
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 identyfikacji 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 117  
cardHolderPreferredLanguage  jest preferowanym j ęzykiem posia ­
dacza karty.  
2.53.  ControlType  
Kod wskazuj ący czynności wykonane podczas kontroli. Ten typ danych 
związany jest z wymaganiami 126, 274, 299, 327 i 350 okre ślonymi 
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  
‘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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 118  
‘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.  
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 warsztatowej 
zwiększany o jeden dla ka żdego dnia kalendarzowego, w którym karta 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 119  
2.57.  Datef  
Data wyra żona w czytelnym, przeznaczonym do druku formacie nume ­
rycznym.
  
Przypisanie warto ści: 
yyyy rok  
mm miesi ąc 
dd dzie ń 
‘00000000’H oznacza jednoznacznie brak daty.  
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 proto ­
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 odczytami 
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.  
2.61.  DriverCardApplicationIdentification  
Informacje przechowywane na karcie kierowcy dotycz ące identyfikacji 
aplikacji na karcie (wymagania 253 i 278 okre ślone w załączniku 1C).  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 120  
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 
2.62.  DriverCardHolderIdentification  
Informacje przechowywane na karcie kierowcy dotycz ące identyfikacji 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 121  
cardHolderPreferredLanguage  jest preferowanym j ęzykiem posia ­
dacza karty.  
▼M1 
2.63.  Zarezerwowany dla przysz łego użytku 
▼B 
2.64.  EGFCertificate  
Generacja 2:  
Certyfikat klucza publicznego urz ądzenia zewn ętrznego GNSS na 
potrzeby wzajemnego uwierzytelniania z VU. Struktur ę tego certyfikatu 
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 produ ­
centa.  
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 wprowa ­
dzenia wpisu.  
Generacja 1
  
Przypisanie warto ści: zgodnie z norm ą ISO/IEC8824-1.  
Generacja 2
  
Przypisanie warto ści: zgodnie z norm ą ISO/IEC8824-1.  
2.67.  EquipmentType  
Kod umożliwiający rozróżnienie typów urz ądzeń dla aplikacji tachogra ­
ficznej.
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 122  
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 rejes­
trującego oraz czujnika ruchu mog ą być, w stosownych przypadkach, 
używane w SealRecord.  
Uwaga 2:  W polu CardHolderAuthorisation (CHA) świadectwa gene ­
racji 2, warto ści (1), (2) i (6) nale ży interpretowa ć jako wskazuj ące na 
świadectwo wzajemnego uwierzytelnienia dla danego typu urz ądzenia. 
W celu wskazania danego certyfikatu na potrzeby podpisu cyfrowego 
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 — 26.02.2020 — 002.001 — 123 
jedno/jedna z 10 ostatnich zdarze ń lub usterek (lub ostatnie/ostatnia zdarzenie lub 
usterka) 
najdłuższe zdarzenie w jednym z ostatnich 10 dni ich wyst ępowania 
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 zaistnia łe po ostatniej kalibracji 
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 ądu 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 — 26.02.2020 — 002.001 — 124 
usterki karty, 
brak dalszych szczegó łów, 
RFU,
  
RFU,
  
swoisty dla producenta.  
▼M1
Generacja 2:
  
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 ądu 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 — 26.02.2020 — 002.001 — 125
  
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.  
2.71.  ExtendedSealIdentifier  
Generacja 2:  
Rozszerzony identyfikator plomby jednoznacznie identyfikuje plomb ę 
(wymaganie 401 okre ślone w załączniku IC).
  
manufacturerCode : jest kodem producenta plomby.  
sealIdentifier  jest identyfikatorem plomby, który jest niepowtarzalny dla 
producenta.  
▼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 śniono poni ­ 
żej. 
monthYear  jest identyfikacj ą miesiąca i roku produkcji (lub przypi ­
sanym numerem seryjnym).  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 126  
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.  
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 generacj ę.
 
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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 127  
2.76.  GeoCoordinates  
Generacja 2:  
Współrzędne geograficzne s ą zakodowane jako liczby ca łkowite. Takie 
liczby są wielokrotno ściami kodowania ± DDMM.M dla szeroko ści 
geograficznej i ± DDDMM.M dla d ługości geograficznej. W powy ższym 
przypadku odpowiednio ± DD i ± DDD oznaczaj ą stopnie, a MM.M 
minuty.
  
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 wielokrotno ś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 warsztatowej doty ­
czące położenia pojazdu z GNSS, je żeli skumulowany czas prowadzenia 
pojazdu osi ągnie wielokrotno ść trzech godzin (wymagania 306 i 354 
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 GNSS 
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 pojazdu.  
2.79.  GNSSAccumulatedDrivingRecord  
Generacja 2:  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 128  
Informacje zapisane na karcie kierowcy lub na karcie warsztatowej doty ­
czące położenia pojazdu z GNSS, je żeli skumulowany czas prowadzenia 
pojazdu osi ągnie wielokrotno ść trzech godzin (wymagania 305 i 353 
określone w załączniku IC)
  
timeStamp  to data i godzina, o której skumulowany czas prowadzenia 
pojazdu osi ąga wielokrotno ść trzech godzin.  
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.  
▼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ść przebyta 
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.  
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, lub 
controlBodyName.  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 129  
holderFirstNames  oznacza imi ę (imiona) i inicja ły posiadacza.  
2.84.  InternalGNSSReceiver  
Generacja 2:  
Informacje, czy odbiornik GNSS znajduje si ę wewnątrz czy na zewn ątrz 
przyrządu rejestruj ącego. Prawda – oznacza, że odbiornik GNSS znaj ­
duje się wewnątrz VU. Fa łsz – oznacza, że odbiornik GNSS jest 
zewnętrzny.
  
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 ływaniu 
się do klucza i do wybierania klucza. Identyfikuje tak że posiadacza 
klucza.
  
Pierwsza pozycja jest odpowiednia przy odes łaniu do klucza publicz ­
nego przyrz ądu rejestruj ącego, karty do tachografu lub urz ądzenia 
zewnętrznego GNSS.  
Druga pozycja jest odpowiednia przy odes łaniu do klucza publicznego 
przyrządu rejestruj ącego (w przypadkach, gdy numer seryjny przyrz ądu 
rejestrującego może nie być znany w czasie sporz ądzenia certyfikatu).  
Trzecia pozycja jest odpowiednia przy odes łaniu do klucza publicznego 
państwa członkowskiego.  
▼B 
2.87.  KMWCKey  
Generacja 2:  
Klucz AES i zwi ązana z nim wersja klucza stosowane do sparowania 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 130  
2.89.  LastCardDownload  
Data i godzina, zapisane na karcie kierowcy, ostatniego pobierania 
danych z karty (do innych celów ni ż kontrola) – wymagania 257 
i 282 okre ślone w załączniku 1C. Dat ę tę aktualizuje VU lub dowolny 
czytnik kart.
  
Przypisanie warto ści: nie określa się. 
2.90.  LinkCertificate  
Generacja 2:  
Certyfikat po łączenia par kluczy G łównego Europejskiego Organu 
Certyfikacji.
  
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 odpo ­
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łączniku 
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 inter ­
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 dla 
przeprowadzania bada ń interoperacyjno ści. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 131  
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 przez 
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.
  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 132  
2.100.  NationAlpha  
Alfabetyczne okre ślenie państwa musi by ć zgodne ze znakami wyró ż­
niającymi stosowanymi na pojazdach w ruchu mi ędzynarodowym (Kon ­
wencja wiede ńska Narodów Zjednoczonych o ruchu drogowym 
z 1968 r.).
  
Kody Nation Alpha i Numeric znajduj ą się na wykazie utrzymywanym 
na stronie internetowej laboratorium wyznaczonego do przeprowadzenia 
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 Numeric 
opisanych w powy ższym akapicie dokonuje si ę dopiero po otrzymaniu 
przez wyznaczone laboratorium opinii producentów przyrz ądów rejes­
trujących tachografów cyfrowych i inteligentnych posiadaj ących homo ­
logację typu.  
2.102.  NoOfCalibrationRecords  
Liczba rekordów kalibracyjnych, mo żliwych do przechowywania na 
karcie.  
Generacja 1:
  
Przypisanie warto ści: zob. dodatek 2.  
Generacja 2:
  
Przypisanie warto ści: zob. dodatek 2.  
2.103.  NoOfCalibrationsSinceDownload  
Licznik pokazuj ący liczbę kalibracji wykonanych przy u życiu karty 
warsztatowej od ostatniego pobrania danych z tej karty (wymaganie 
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 przechowywania 
na karcie kierowcy lub na karcie warsztatowej.  
Generacja 1:
  
Przypisanie warto ści: zob. dodatek 2.  
Generacja 2:
  
Przypisanie warto ści: zob. dodatek 2.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 133  
2.105.  NoOfCardVehicleRecords  
Liczba rekordów dotycz ących użytych pojazdów, mo żliwych do prze ­
chowywania 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żliwych 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 przecho ­
wywania na karcie firmowej.
  
Przypisanie warto ści: zob. dodatek 2.  
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 karcie.
  
Przypisanie warto ści: zob. dodatek 2.  
2.110.  NoOfFaultsPerType  
Liczba usterek wed ług typu, mo żliwych do przechowywania na karcie.
  
Przypisanie warto ści: zob. dodatek 2.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 134  
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.  
▼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.  
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ę. 
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  
recordSize  to wielko ść OdometerValueMidnight w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów OdometerValueMidnight.  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 135  
2.116.  OverspeedNumber  
Liczba zdarze ń przekroczenia pr ędkości od ostatniej kontroli przekro ­
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 oznacza, że 
było jedno zdarzenie przekroczenia pr ędkości od ostatniej kontroli prze ­
kroczenia pr ędkości... 255 oznacza, że było 255 lub wi ęcej zdarze ń 
przekroczenia pr ędkości od ostatniej kontroli przekroczenia pr ędkości. 
2.117.  PlaceRecord  
Informacje dotycz ące miejsca rozpocz ęcia lub zako ńczenia dziennego 
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ą. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 136  
2.118.  PreviousVehicleInfo  
Informacje dotycz ące pojazdu poprzednio u żywanego przez kierowc ę 
w chwili wk ładania jego karty do przyrz ądu rejestruj ącego (wymaganie 
081 określone w załączniku 1B i wymaganie 102 okre ślone w załącz­
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 RecordAr ­
rays.
 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 137  
Przypisanie warto ści:
 
► (1) M1 ActivityChangeInfo, 
CardSlotsStatus, 
CurrentDateTime, 
MemberStateCertificate, 
OdometerValueMidnight, 
DateOfDayDownloaded, 
SensorPaired, 
Signature, 
SpecificConditionRecord, 
VehicleIdentificationNumber, 
VehicleRegistrationNumber, 
VuCalibrationRecord, 
VuCardIWRecord, 
VuCardRecord, 
VuCertificate, 
VuCompanyLocksRecord, 
VuControlActivityRecord, 
VuDetailedSpeedBlock, 
VuDownloadablePeriod, 
VuDownloadActivityData, 
VuEventRecord,  
►M1 VuGNSSADRecord, ◄ 
VuITSConsentRecord, 
VuFaultRecord, 
VuIdentification, 
VuOverSpeedingControlData, 
VuOverSpeedingEventRecord, 
VuPlaceDailyWorkPeriodRecord, 
VuTimeAdjustmentGNSSRecord, 
VuTimeAdjustmentRecord, 
VuPowerSupplyInterruptionRecord, 
SensorPairedRecord, 
SensorExternalGNSSCoupledRecord, 
RFU, 
swoisty dla producenta.  
2.121.  RegionAlpha  
Alfabetyczne odniesienie do regionu w okre ślonym kraju.
  
Generacja 1:  
Przypisanie warto ści:
 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 138  
Generacja 2:  
Kody RegionAlpha znajduj ą się na wykazie utrzymywanym na stronie 
internetowej laboratorium wyznaczonego do przeprowadzenia bada ń 
interoperacyjno ś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 stronie 
internetowej laboratorium wyznaczonego do przeprowadzenia bada ń 
interoperacyjno ś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 — 26.02.2020 — 002.001 — 139  
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 ­
cowanych do ró żnych części pojazdu i jest on przeznaczony do prze ­
chowywania na karcie. Ten typ danych zwi ązany jest z wymaganiem 
337 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 ­
cowanych do ró żnych części pojazdu i jest on przeznaczony do prze ­
chowywania 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 przymoco ­
wanej do danego elementu sk ładowego. Ten typ danych zwi ązany jest 
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 — 26.02.2020 — 002.001 — 140  
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 — 26.02.2020 — 002.001 — 141
  
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 okre ­ 
ś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 GNSS.  
currentVUSerialNumber  jest numerem seryjnym przyrz ądu rejestruj ą­
cego powi ązanego obecnie z urz ądzeniem zewn ętrznym GNSS.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 142  
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 kryptograficznego 
modułu urządzenia zewn ętrznego GNSS.  
Identyfikator elementu zabezpieczenia urz ądzenia zewn ętrznego GNSS.
  
Przypisanie warto ści: element swoisty dla producenta.  
2.138.  SensorGNSSCouplingDate  
Generacja 2:  
Data powi ązania urządzenia zewn ętrznego GNSS z przyrz ądem rejestru ­
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 identyfi ­
kacji (wymaganie 077 okre ślone w załączniku 1B i wymaganie 95 okre ­ 
ś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 — 26.02.2020 — 002.001 — 143  
sensorOSIdentifier  jest identyfikatorem systemu operacyjnego czujnika 
ruchu.  
2.141.  SensorInstallation  
Informacje przechowywane w czujniku ruchu dotycz ące jego instalacji 
(wymaganie 099 okre ślone w załączniku 1B i wymaganie 122 okre ślone 
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 zabezpie ­
czenia potrzebne do sparowania czujników ruchu z przyrz ądami rejes ­
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 przechowywa ć 
maksymalnie trzy klucze na potrzeby parowania czujnika ruchu z VU. 
Klucze te maj ą różne wersje.
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 144  
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 rejes­
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 — 26.02.2020 — 002.001 — 145  
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 pobierania 
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 ozna ­
cza, ż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 tym dniu.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 146  
2.152.  SpecificConditionRecord  
Informacje przechowywane na karcie kierowcy, karcie warsztatowej lub 
w przyrządzie rejestruj ącym dotycz ące warunku szczególnego (wyma ­
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 szcze ­
gólny.  
2.153.  SpecificConditions  
Informacje przechowywane na karcie kierowcy, karcie warsztatowej lub 
w przyrządzie rejestruj ącym dotycz ące warunku szczególnego (wyma ­
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 pierw ­
szego wyst ąpienia w strukturze rekordu dotycz ącego warunku szczegó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, 212a 
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 — 26.02.2020 — 002.001 — 147  
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 przedziale 
czasu.
  
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:  
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 godzina 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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 148  
2.164.  VehicleIdentificationNumber  
Numer identyfikacyjny pojazdu (VIN) odnosz ący się do pojazdu jako 
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 proto ­
kole pobierania danych.
  
recordType  oznacza typ rekordu (VehicleIdentificationNumber).  Przy­
pisanie warto ści: zob. RecordType  
recordSize  to wielko ść VehicleIdentificationNumber w bajtach.  
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łonkow­
skie).
  
vehicleRegistrationNation  jest państwem, w którym pojazd jest zareje ­
strowany.  
vehicleRegistrationNumber  jest numerem rejestracyjnym pojazdu 
(VRN).  
2.167.  VehicleRegistrationNumber  
Numer rejestracyjny pojazdu (VRN). Numer rejestracyjny przydziela 
organ rejestracji pojazdów.
  
codePage  określa zestaw znaków zdefiniowany w rozdziale 4,  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 149  
vehicleRegNumber  jest numerem VRN zakodowanym przy u życiu 
wyszczególnionego zestawu znaków.  
Przypisanie warto ści: swoisty dla kraju.  
2.168.  VehicleRegistrationNumberRecordArray  
Generacja 2:  
Numer rejestracyjny pojazdu wraz z metadanymi stosowany w protokole 
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 kart 
do tachografów generacji 1 (wymaganie 121 okre ślone w za łączniku 
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:  
Informacje przechowywane w VU dotycz ące zmian czynno ści lub zmian 
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.
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 150  
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 zmian 
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 opisu ­
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:
  
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:  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 151  
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.  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 152  
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.  
Generacja 2:
  
Oprócz generacji 1 u żywany jest nast ępujący element danych:  
sealDataVu  podaje informacje o plombach przymocowanych do 
różnych części pojazdu.  
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).  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 153
  
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 warsztatowych 
w przyrządzie rejestruj ącym (wymaganie 081 okre ślone w załączniku 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:
  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 154  
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 wykorzystuje 
się następujący element danych.  
fullCardNumberAndGeneration  jest typem karty, pa ństwem człon­
kowskim wydaj ącym kartę, numerem karty i generacj ą zapisanymi na 
karcie.  
2.178.  VuCardIWRecordArray  
Generacja 2:  
Informacje przechowywane w przyrz ądzie rejestruj ącym dotycz ące cykli 
wkładania i wyjmowania kart kierowcy lub kart warsztatowych w przy ­
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 155  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów dotycz ących cykli wk ładania 
i wyjmowania 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łączniku 
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 ą przeznaczone 
do analizy przez VU problemów dotycz ących kart (wymaganie 132 
określone w załączniku 1C).
  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 156  
2.181.  VuCertificate  
Certyfikat klucza publicznego przyrz ądu rejestruj ącego.
  
2.182.  VuCertificateRecordArray  
Generacja 2:  
Certyfikat VU wraz z metadanymi stosowany w protokole pobierania 
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.  
2.184.  VuCompanyLocksRecord  
Informacje przechowywane w przyrz ądzie rejestruj ącym dotycz ące 
jednej blokady (wymaganie 104 okre ślone w załączniku 1B i wymaganie 
128 określone w załączniku 1C).  
Generacja 1:
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 157  
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.  
2.186.  VuControlActivityData  
Generacja 1:  
Informacje przechowywane w przyrz ądzie rejestruj ącym, dotycz ące 
kontroli przeprowadzonych przy u życiu tego VU (wymaganie 102 okre ­ 
ślone w załączniku 1B).
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 158  
noOfControls  jest liczbą kontroli wyszczególnionych w vuControlActi ­
vityRecords.  
vuControlActivityRecords  jest zbiorem rekordów czynno ści kontro­
lnych.  
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.  
downloadPeriodEndTime  jest czasem zako ńczenia okresu, dla którego 
pobrano dane, w przypadku pobierania danych.  
Generacja 2:
  
Zamiast controlCardNumber w strukturze danych generacji 2 wykorzys ­
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 okre ­ 
ślone w załączniku 1C).  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 159
  
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 ładania/ 
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 by ł 
w ruchu (wymaganie 093 okre ślone w za łączniku 1B i wymaganie 
116 określone w załączniku 1C).
  
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 ślonej 
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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 160  
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. 
2.193.  VuDownloadablePeriod  
Najstarsza i naj świeższa data i godzina, wyznaczaj ące okres, dla którego 
przyrząd rejestrujący przechowuje dane dotycz ące czynności kierowców 
(wymagania 081, 084 lub 087 okre ślone w załączniku 1B i wymagania 
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 wpro ­
wadzania danych.  
maxDownloadableTime  jest przechowywan ą w VU dat ą i godzin ą 
ostatniego wyj ęcia karty lub zmiany czynno ści, lub miejsca wprowa ­
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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 161  
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.  
fullCardNumber  identyfikuje kart ę użytą do autoryzowania pobierania 
danych.  
companyOrWorkshopName  jest nazw ą firmy lub warsztatu.  
Generacja 2:
  
Zamiast fullCardNumber w strukturze danych generacji 2 wykorzystuje 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 162  
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 ń. 
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 ędkości). 
Generacja 1:
  
eventType  jest typem zdarzenia.  
eventRecordPurpose  jest celem, dla którego zarejestrowano to zdarze ­
nie. 
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 ż prze­
kroczenie pr ędkości. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 163  
Generacja 2:
  
Oprócz generacji 1 u żywane są następujące elementy danych:  
manufacturerSpecificEventFaultData  zawiera dodatkowe, szczegó ­ 
łowe informacje o zdarzeniu odnosz ące się do danego producenta.  
Zamiast cardNumberDriverSlotBegin, cardNumberCodriverSlotBegin, 
cardNumberDriverSlotEnd i cardNumberCodriverSlotEnd 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 zdarzenia.  
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 zdarze­
nia. 
Jeżeli w zdarzeniu zachodzi konflikt czasu eventBeginTime i eventEn ­
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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 164  
recordSize  to wielko ść VuEventRecord w bajtach.  
noOfRecords  jest liczbą rekordów w zbiorze.  
records  jest zbiorem rekordów dotycz ących zdarze ń. 
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 wymaganie 
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 zarejestro ­
wana.  
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 — 26.02.2020 — 002.001 — 165  
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 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 usterki.  
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 usterki.  
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 — 26.02.2020 — 002.001 — 166  
2.203.  VuGNSSADRecord  
Generacja 2:  
Informacje przechowywane w przyrz ądzie rejestruj ącym dotycz ące poło­ 
żenia pojazdu z GNSS, je żeli skumulowany czas prowadzenia pojazdu 
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 genera ­
cję, 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.  
2.204.  VuGNSSADRecordArray  
Generacja 2:  
Informacje przechowywane w przyrz ądzie rejestruj ącym dotycz ące poło­ 
żenia pojazdu z GNSS, je żeli skumulowany czas prowadzenia pojazdu 
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.  
▼B 
2.205.  VuIdentification  
Informacje przechowywane w przyrz ądzie rejestruj ącym dotycz ące jego 
identyfikacji (wymaganie 075 okre ślone w za łączniku 1B oraz wyma ­
gania 93 i 121 okre ślone w załączniku 1C).  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 167  
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.  
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.  
Generacja 2:
  
Oprócz generacji 1 u żywane są następujące elementy danych:  
vuGeneration  identyfikuje generacj ę przyrządu rejestruj ącego.  
vuAbility  zapewnia informacje, czy VU obs ługuje karty do tachografu 
generacji 1.  
2.206.  VuIdentificationRecordArray  
Generacja 2:  
VuIdentification wraz z metadanymi stosowany w protokole pobierania 
danych.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 168
  
recordType  oznacza typ rekordu (VuIdentification).  Przypisanie warto ­ 
ści: zob. RecordType  
recordSize  to wielko ść VuIdentification w bajtach.  
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 transportowych.
  
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 inteligent ­
nych systemów transportowych  
2.208.  VuITSConsentRecordArray  
Generacja 2:  
Informacje przechowywane w przyrz ądzie rejestruj ącym dotycz ące 
zgody kierowcy na stosowanie inteligentnych systemów transportowych 
(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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 169  
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 protokole 
pobierania danych.
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 170  
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 zdarze ­
nie. 
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 — 26.02.2020 — 002.001 — 171  
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 zdarzenia.  
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 
1C).
 
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 — 26.02.2020 — 002.001 — 172  
2.218.  VuPlaceDailyWorkPeriodData  
Generacja 1:  
Informacje przechowywane w przyrz ądzie rejestruj ącym dotycz ące 
miejsc rozpocz ęcia lub zako ńczenia dziennego okresu pracy kierowców 
(wymaganie 087 okre ślone w załączniku 1B oraz wymagania 108 i 110 
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 kierowcy 
(wymaganie 087 okre ślone w załączniku 1B oraz wymagania 108 i 110 
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.  
Generacja 2:  
Informacje przechowywane w przyrz ądzie rejestruj ącym dotycz ące 
miejsca rozpocz ęcia lub zako ńczenia dziennego okresu pracy kierowcy 
(wymaganie 087 okre ślone w załączniku 1B oraz wymagania 108 i 110 
określone w załączniku 1C).
  
Zamiast fullCardNumber w strukturze danych generacji 2 wykorzystuje 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 173  
2.220.  VuPlaceDailyWorkPeriodRecordArray  
Generacja 2:  
Informacje przechowywane w przyrz ądzie rejestruj ącym dotycz ące 
miejsc rozpocz ęcia lub zako ńczenia dziennego okresu pracy kierowcó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.
  
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. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 174  
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.  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 175  
2.229.  VuTimeAdjustmentData  
Generacja 1:  
Informacje przechowywane w przyrz ądzie rejestruj ącym dotycz ące 
korekt czasu dokonanych poza regularn ą kalibracją (wymaganie 101 
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 101 
określone w za łączniku 1B oraz wymagania 124 i 125 okre ślone 
w załączniku 1C).  
Generacja 1:
  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 176  
2.233.  VuTimeAdjustmentRecordArray  
Generacja 2:  
Informacje przechowywane w przyrz ądzie rejestruj ącym dotycz ące 
korekt czasu dokonanych poza regularn ą kalibracją (wymagania 124 
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 identyfi ­
kacji aplikacji na karcie (wymagania 307 i 330 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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 177  
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.  
▼B 
2.235.  WorkshopCardCalibrationData  
Informacje przechowywane na karcie warsztatowej dotycz ące czynnoś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 rekordu 
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 czynności 
wykonanych przy u życiu karty (wymagania 314 i 337 okre ślone 
w załączniku 1C).  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 178  
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 — 26.02.2020 — 002.001 — 179  
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 identyfi ­
kacji 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 (wymaganie 
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 — 26.02.2020 — 002.001 — 180  
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 łączniku 
1C).
 
eventType  jest typem zdarzenia.  
eventRecordPurpose  jest celem, dla którego zarejestrowano to zdarze ­
nie. 
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 zdarzenia.  
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 zdarze­
nia. 
similarEventsNumber  jest liczbą podobnych zdarze ń w tym dniu.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 181  
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 — 26.02.2020 — 002.001 — 182  
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 rozbie ż­
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  13  
ISO/IEC 8859-15 Latin-9  15  
ISO/IEC 8859-16 Latin-10 – dla Europy Po łudniowo-Wschod ­
niej 16 
KOI8-R Latin – dla cyrylicy  80  
KOI8-U Latin – dla cyrylicy  85  
5. KODOWANIE  
Przy kodowaniu zgodnie z zasadami ASN.1, wszystkie zdefiniowane 
typy danych koduje si ę zgodnie z wariantem unormowanym w ISO/IEC 
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ólniono  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 183  
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 ć dokonane 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 algorytmem 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 — 26.02.2020 — 002.001 — 184  
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 generacji 2 jest 
określony za pomoc ą „FF 53 4D 52 44 54”. Jest to zastrze żony AID 
zgodny z norm ą ISO/IEC 7816-4.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 185  
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 — 26.02.2020 — 002.001 — 186  
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE  
3.5.15 PSO: VERIFY DIGITAL SIGNATURE  
3.5.16 PROCESS DSRC MESSAGE  
4. 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 — 26.02.2020 — 002.001 — 187  
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 — 26.02.2020 — 002.001 — 188  
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 grani ­
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 — 26.02.2020 — 002.001 — 189  
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 pozio ­
mie 
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:  
stan operacyjny, w którym karta wykonuje polecenia lub 
jest połączona z jednostk ą cyfrową; 
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 zasto ­
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 — 26.02.2020 — 002.001 — 190  
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.  
— Całkowita długość łańcucha dla pola danych nie mo że 
przekracza ć 255 bajtów (IFD musi to zapewnia ć). 
— 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 — 26.02.2020 — 002.001 — 191  
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 — 26.02.2020 — 002.001 — 192  
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 ogranicze ń. 
Polecenie i odpowied ź APDU są wysyłane w postaci zwyk łego tekstu, 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. bez 
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łane 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 dodatek 11 cz ęść 
A) zostało pomyślnie wykonane.  
SM-MAC-G1  Polecenie i odpowied ź APDU musz ą być stosowane z bezpieczn ą wymianą 
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ą komunikatów 1. 
generacji w trybie tylko uwierzytelnienia (zob. dodatek 11 cz ęść A). 
SM-R-ENC-G1  Odpowied ź APDU musi by ć stosowana z bezpieczn ą wymianą komunikatów 
1. generacji w trybie szyfrowania (zob. dodatek 11 cz ęść A), tzn. bez zwra ­
cania kodu uwierzytelnienia wiadomo ści. 
SM-R-ENC- 
MAC-G1  Odpowiedź APDU musi by ć stosowana z bezpieczn ą wymianą komunikató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 ą wymianą 
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ą komunikató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ą komunikató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 — 26.02.2020 — 002.001 — 193  
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. 
generacji  ALW  ALW  ALW  ALW  
— dla uwierzytelnienia 2. 
generacji  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 — 26.02.2020 — 002.001 — 194  
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 — 26.02.2020 — 002.001 — 195  
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 — 26.02.2020 — 002.001 — 196  
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 00  Normalne przetwarzanie.  
61 XX  Normalne przetwarzanie. XX = liczba dost ępnych bajtów odpo ­
wiedzi.  
62 81  Przetwarzanie ostrze żenia. Część zwracanych danych mo że być 
uszkodzona  
63 00  Nieudane uwierzytelnienie (ostrze żenie)  
63 CX  Nieprawid łowe CHV (PIN). „X” oznacza licznik pozosta łych 
prób.  
64 00  Błąd wykonania – Stan pami ęci nieulotnej bez zmian. B łąd inte­
gralności. 
65 00  Błąd wykonania – Stan pami ęci nieulotnej zmieniony  
65 81  Błąd wykonania – Stan pami ęci nieulotnej zmieniony – Uszko ­
dzona pami ęć 
66 88  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 — 26.02.2020 — 002.001 — 197  
SW1  SW2  Znaczenie  
67 00  Nieprawid łowa długość (nieprawid łowe Lc lub Le)  
68 83  Oczekiwane ostatnie polecenie łańcucha  
69 00  Niedozwolone polecenie (brak dost ępnej odpowiedzi w T=0)  
69 82  Niespe łniony stan zabezpieczenia.  
69 83  Metoda uwierzytelnienia zablokowana.  
69 85  Warunki u życia niespe łnione.  
69 86  Polecenie niedozwolone (brak bie żącego EF).  
69 87  Brak oczekiwanych obiektów danych w bezpiecznej wymianie 
komunikatów  
69 88  Nieprawid łowe obiekty danych w bezpiecznej wymianie komu ­
nikatów  
6A 80  Nieprawid łowe parametry w polu danych  
6A 82  Nie znaleziono pliku.  
6A 86  Nieprawid łowe parametry P1-P2.  
6A 88  Nie znaleziono powo łanych danych.  
6B 00  Nieprawid łowe parametry (przesuni ęcie poza EF).  
6C XX  Nieprawid łowa długość, SW2 wskazuje dok ładną długość. Pole 
danych nie jest zwracane.  
6D 00  Kod instrukcji nieobs ługiwany lub niewa żny. 
6E 00  Klasa nieobs ługiwana.  
6F 00  — 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 ści 
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 — 26.02.2020 — 002.001 — 198  
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 zastoso ­
wanie jest ograniczone w porównaniu z poleceniem zdefiniowanym 
w tej normie.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 199  
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)  NN  ‘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 — 26.02.2020 — 002.001 — 200  
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 zastoso ­
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 zabez ­
pieczenia ALW dla trybu dost ępu do odczytu.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 201  
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 odczy ­
tu. 
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 zasto­
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 — 26.02.2020 — 002.001 — 202  
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. gene ­
racji (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)  NN  ‘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 — 26.02.2020 — 002.001 — 203  
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 polece ­
nia, ze wzgl ędu na wype łnienie) 
L ma 2 bajty, je żeli LPI CG > 127 bajtów  
#(2+L)-#(1+L+MM)  MM  ‘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 — 26.02.2020 — 002.001 — 204  
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 skon­
struowana.  
— 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 odczy ­
tu. 
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 — 26.02.2020 — 002.001 — 205  
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 ma 
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)  NN  ‘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 — 26.02.2020 — 002.001 — 206  
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 komuni ­
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 — 26.02.2020 — 002.001 — 207  
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)  NN  ‘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. gene ­
racji (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. gene ­
racji (zob. dodatek 11 cz ęść B) 
#(8+L+NN)- 
#(7+M+L+N ­
N) 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 zastoso ­
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 ępując 
je bitami podanymi w poleceniu APDU.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 208  
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)  NN  ‘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. Gdy 
nie jest wymagana poufno ść, dane nie s ą szyfrowane.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 209  
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ć 
zapisane)  
#(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. gene ­
racji (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 — 26.02.2020 — 002.001 — 210  
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 skon­
struowana.  
— 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)  NN  ‘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 — 26.02.2020 — 002.001 — 211  
— 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 ma 
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 polece ­
nia 
#6-#(5+NN)  NN  ‘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 — 26.02.2020 — 002.001 — 212  
— 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 komuni ­
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. gene ­
racji (zob. dodatek 11 cz ęść B) 
#(9+L+NN)- 
#(8+M+L+N ­
N) M ‘XX..XXh’  Kryptograficzna suma kontrolna  
Le 1  ‘00h’  zgodnie ze specyfikacj ą w normie ISO/IEC 7816-4  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 213  
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. gene ­
racji (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 zastoso ­
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’  P1  
P2 1  ‘00h’  P2  
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 — 26.02.2020 — 002.001 — 214  
3.5.5  VERIFY  
Polecenie to jest zgodne z norm ą ISO/IEC 7816-4, ale jego zastoso ­
wanie jest ograniczone w porównaniu z poleceniem zdefiniowanym 
w tej normie.  
Jedynie karta warsztatowa jest zobowi ązana do obs ługi tego polece ­
nia. 
Inne rodzaje kart do tachografów mog ą, ale nie musz ą realizować tego 
polecenia, lecz w przypadku tych kart żadne referencyjne CHV nie 
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 żeli 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’  P1  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 215  
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 parametry 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 — 26.02.2020 — 002.001 — 216  
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 zastoso ­
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 apli ­
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’  P1  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 217  
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 polece ­
niach APDU PSO: Verify Certificate.  
Struktura certyfikatu i parametry domeny zosta ły określone 
w dodatku 11.  
TCS_86 Polecenie mo że być wykonywane w MF, w DF Tacho ­
graph i w DF Tachograph_G2 (zob. równie ż TCS_33).  
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 — 26.02.2020 — 002.001 — 218  
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. 
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 zgodnie z warto ścią bajtu 
wielkości pola informacyjnego dla karty (zob. TCS_14). 
Jeżeli IFD dzia ła inaczej, zachowanie karty nie jest obj ęte 
zakresem zastosowania.  
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 IFD dzia ła inaczej, 
zachowanie karty nie jest obj ęte zakresem zastosowania.  
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.  
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 — 26.02.2020 — 002.001 — 219  
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’  P1  
P2 1  ‘00h’  P2  
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 — 26.02.2020 — 002.001 — 220  
— 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 — 26.02.2020 — 002.001 — 221  
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 uwierzytelnienia 
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. 
▼M1 
5 + L + 1  1  ‘00h’  zgodnie ze specyfikacj ą w normie ISO/IEC 7816-4  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 222  
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 para­
metry w polu danych.  
— Karta zwraca ‘ 6982 ’, jeżeli uwierzytelnienie poleceniem 
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 uwierzytel ­
nienia.  
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 tego 
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 zreseto ­
wana.  
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 — 26.02.2020 — 002.001 — 223  
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 komunika ­
tó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 tachografu 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 — 26.02.2020 — 002.001 — 224  
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 wyko ­
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 pomi ­
jany). 
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 pole ­
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 — 26.02.2020 — 002.001 — 225  
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 zainicjowany.  
— ‘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 certyfikatu 
(CHR) podanym w polu danych dotycz ących polecenia 
(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. definicja 
pola CHA w dodatku 11 i typu danych equipmentType 
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 tymczasowo 
zachowywana dla kolejnego polecenia PSO: Verify Digital Signature.  
Polecenie to jest zgodne z norm ą ISO/IEC 7816-8. Zastosowanie tego 
polecenia jest ograniczone w porównaniu z poleceniem zdefinio ­
wanym w tej normie.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 226  
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 polecenia 
PERFORM SECURITY OPERATION/HASH.  
Tylko karta kierowcy i karta warsztatowa s ą zobowiązane obsługiwać 
to polecenie w DF Tachograph i DF Tachograph_G2.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 227  
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 rozdziale.  
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 — 26.02.2020 — 002.001 — 228  
— 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 obliczo ­
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ługiwać 
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 jedynie 
karta kierowcy i karta warsztatowa maj ą klucz podpisu 2. generacji, 
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 polecenie nie 
jest dostępne w MF, zostaje zako ńczone odpowiednim kodem b łędu. 
Polecenie to jest zgodne z norm ą ISO/IEC 7816-8. Zastosowanie tego 
polecenia jest ograniczone w porównaniu z poleceniem zdefinio ­
wanym w tej normie.  
▼B 
TCS_126 Polecenie to nie oblicza podpisu cyfrowego z obliczonego 
wcześniej kodu skrótu poleceniem PSO: HASH.  
TCS_127 Klucza prywatnego karty, który jest niejawnie znany karcie, 
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 — 26.02.2020 — 002.001 — 229  
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 karcie. 
Algorytm podpisu jest niejawnie znany karcie.  
Polecenie to jest zgodne z norm ą ISO/IEC 7816-8. Zastosowanie tego 
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 — 26.02.2020 — 002.001 — 230  
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 autentycz ­
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ługiwać 
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 odpo­
wiednim kodem b łędu. 
Polecenie mo że, ale nie musi by ć dostępne w MF lub DF Tachograph. 
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 — 26.02.2020 — 002.001 — 231  
TCS_136 Polecenie s łuży jedynie do odszyfrowania danych i weryfi ­
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 mechanizmu 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 znajduj ą 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’.  
▼M1 
5 + L + 1  1  ‘00h’  zgodnie ze specyfikacj ą w normie ISO/IEC 7816-4  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 232  
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 tacho ­
grafów przeznaczonych do gromadzenia dost ępnych danych.  
Nie stanowi to opisu wewn ętrznych struktur w łaściwych dla 
producenta, 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łównego MF oraz aplikacji tachograficznej 1. generacji 
i 2. generacji tego samego typu (np. aplikacje karty kierow ­
cy). 
TCS_141 Karta do tachografu musi obs ługiwać co najmniej mini ­
malną liczbę rekordów okre śloną dla odpowiednich apli ­
kacji i nie mo że obsługiwać więcej rekordów ni ż maksy­
malna liczba rekordów okre ślona dla odpowiednich aplika ­
cji. 
Minimalne i maksymalne liczby rekordów zosta ły okre­ 
ślone w niniejszym rozdziale dla poszczególnych aplikacji.  
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 — 26.02.2020 — 002.001 — 233  
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 — 26.02.2020 — 002.001 — 234  
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ą struk­
turę danych:  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 235
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 236
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 237  
TCS_151 W tabeli poni żej podano warto ści odnoszące się do tabeli 
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  
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. 
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_153 Wszystkie struktury plików EF s ą przezroczyste.  
TCS_154 Aplikacja karty kierowcy 2. generacji ma nast ępującą struk­
turę danych:  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 238
  
► (1) M1 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 239
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 240
  
► (1) M1 
TCS_155 W tabeli poni żej podano warto ści odnoszące się do tabeli 
powyżej, wyznaczaj ące minimalne i maksymalne liczby 
rekordów, które musi stosowa ć struktura danych karty 
kierowcy dla aplikacji 2. generacji:
  
► (1) M1 
4.3. Aplikacje karty warsztatowej  
4.3.1  Aplikacja karty warsztatowej 1. generacji  
TCS_156 Po personalizacji aplikacja karty warsztatowej 1. generacji 
ma trwałą strukturę plików i zasady dost ępu do plików, jak 
określono poniżej. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 241
  
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 — 26.02.2020 — 002.001 — 242
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 243
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 244
  
TCS_159 W tabeli poni żej podano warto ści odnoszące się do tabeli 
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  
TCS_160 Po personalizacji aplikacja karty warsztatowej 2. generacji 
ma trwałą strukturę plików i zasady dost ępu do plików, jak 
określono poniżej. 
Uwaga:  .The short EF identifier SFID podany jest jako 
liczba dziesi ętna, np. warto ść 30 odpowiada zapisowi 
11110 w systemie binarnym.
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 245  
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  
TCS_161 Wszystkie struktury plików EF s ą przezroczyste.  
TCS_162 Aplikacja karty warsztatowej 2. generacji ma nast ępującą 
strukturę danych:
  
► (1) (2) M1 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 246
  
► (1) M1 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 247
  
► (1) M1 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 248  
TCS_163 W tabeli poni żej podano warto ści odnoszące się do tabeli 
powyżej, wyznaczaj ące minimalne i maksymalne liczby 
rekordów, które musi stosowa ć struktura danych karty 
warsztatowej dla aplikacji 2. generacji:
  
► (1) M1 
4.4. Aplikacje karty kontrolnej  
4.4.1  Aplikacja karty kontrolnej 1. generacji  
TCS_164 Po personalizacji aplikacja karty kontrolnej 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_165 Wszystkie struktury plików EF s ą przezroczyste.  
TCS_166 Aplikacja karty kontrolnej 1. generacji ma nast ępującą 
strukturę danych:  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 249
  
TCS_167 W tabeli poni żej podano warto ści odnoszące się do tabeli 
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  
TCS_168 Po personalizacji aplikacja karty kontrolnej 2. generacji ma 
trwałą strukturę plików i zasady dost ępu do plików, jak 
określono poniżej. 
Uwaga:  .The short EF identifier SFID podany jest jako 
liczba dziesi ętna, np. warto ść 30 odpowiada zapisowi 
11110 w systemie binarnym.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 250
  
W tabeli zastosowano nast ępujący skrót dla warunku 
zabezpieczenia:  
SC1 ALW OR SM-MAC-G2  
TCS_169 Wszystkie struktury plików EF s ą przezroczyste.  
TCS_170 Aplikacja karty kontrolnej 2. generacji ma nast ępującą 
strukturę danych:
  
TCS_171 W tabeli poni żej podano warto ści odnoszące się do tabeli 
powyżej, wyznaczaj ące minimalne i maksymalne liczby 
rekordów, które musi stosowa ć struktura danych karty 
kontrolnej dla aplikacji 2. generacji:  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 251
  
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ą struk­
turę danych:
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 252  
TCS_175 W tabeli poni żej podano warto ści odnoszące się do tabeli 
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  
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. 
Uwaga:  Krótki identyfikator EF (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_177 Wszystkie struktury plików EF s ą przezroczyste.  
TCS_178 Aplikacja karty firmowej 2. generacji ma nast ępującą struk­
turę danych:
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 253  
TCS_179 W tabeli poni żej podano warto ści odnoszące się do tabeli 
powyżej, wyznaczaj ące minimalne i maksymalne liczby 
rekordów, które musi stosowa ć struktura danych karty 
firmowej dla aplikacji 2. generacji:
  ▼B
02016R0799 — PL — 26.02.2020 — 002.001 — 254 
Dodatek 3  
PIKTOGRAMY 
PIC_001 Tachograf mo że opcjonalnie u żywać następujących piktogramów 
i kombinacji piktogramów (lub piktogramów i kombinacji wystarcza ­
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
Warunki szczególne
  
poza zakresem
  
przeprawa promowa/przejazd kolejowy  
Różne
 
zdarzenia
 usterki
  
początek dziennego okresu pracy
 koniec dziennego okresu pracy
  
umiejscowienie
  
ręczne wprowadzenie czynno ści 
kierowcy
  
zabezpieczenie
  
prędkość
 
godzina
  
razem/podsumowanie  
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  
Karty
  
karta kierowcy
  
karta firmowa
  
karta kontrolna
  
karta warsztatowa
  
brak karty  ▼B02016R0799 — PL — 26.02.2020 — 002.001 — 255 
02016R0799 — PL — 26.02.2020 — 002.001 — 256 
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 
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  
▼M1
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ść 
▼B
Usterki
  
usterka karty (szczelina karty kierowcy)
  
usterka karty (szczelina karty wspó łkierowcy)
  
usterka wy świetlacza  ▼B
02016R0799 — PL — 26.02.2020 — 002.001 — 257 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 258  
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óżnych 
bloków danych, w miar ę możliwości identyfikowanych identyfikatorem 
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 identyfi ­
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.  
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, nazwiska i adresy).  
PRT_006 W przypadku łamania wiersza w zwi ązku z długością tekstu 
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 — 26.02.2020 — 002.001 — 259  
— Znaki normaln ą czcionką oznaczają zmienne (piktogramy lub dane), 
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 danych: 
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 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 260  
PRT_007 W wydrukach korzysta si ę z następujących bloków danych lub 
rekordów danych w opisanym poni żej znaczeniu i formacie:
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 261
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 262
  
► (1) (2) M1 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 263
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 264
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 265
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 266
  
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 
3.1. Wydruk dzienny czynno ści kierowcy z karty  
PRT_008 Wydruk dzienny czynno ści kierowcy z karty jest zgodny 
z poniższym formatem: 
1 Data i godzina drukowania dokumentu  
2 Typ wydruku  
3 Identyfikacja kontrolera (je żeli w czytniku VU znajduje si ę karta 
kontrolna)  
3 Identyfikacja kierowcy (z karty, dla której sporz ądzany jest wydruk)  
4 Identyfikacja pojazdu (tego, dla którego sporz ądzany jest wydruk)  
5 Identyfikacja VU (z którego uzyskano wydruk)  
6 Ostatnia kalibracja VU  
7 Ostatnia kontrola sprawdzanego kierowcy  
8 Ogranicznik czynno ści kierowcy  
8a Stan poza zakresem na pocz ątku danego dnia  
8.1a / 8.1b / 8.1c / 8.2 / 
8.3 / 8.3a / 8.4  Czynności kierowcy w kolejno ści chronologicznej  
11 Ogranicznik dziennego zestawienia  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 267  
11.4 Miejsca wprowadzone w kolejno ści chronologicznej  
▼M1 
11.5 Położenia po 3 godzinach skumulowanego czasu prowadzenia 
pojazdu w kolejno ści chronologicznej  
▼B 
11.6 Podsumowania dla czynno ści 
12.1 Zdarzenia lub usterki z ogranicznika karty  
12.4 Rekordy zdarze ń/ usterek (5 ostatnich zdarze ń lub usterek zapisanych 
na karcie)  
13.1 Zdarzenia lub usterki z ogranicznika VU  
13.4 Rekordy zdarze ń/ usterek (5 ostatnich zdarze ń lub usterek zapisanych 
lub trwających na VU)  
22.1 Miejsce kontroli  
22.2 Podpis kontrolera  
22.5 Podpis kierowcy  
3.2. Wydruk dzienny czynno ści kierowcy z VU  
PRT_009 Wydruk dzienny czynno ści kierowcy z VU jest zgodny 
z poniższym formatem:  
▼M1 
1 Data i godzina drukowania dokumentu  
2 Typ wydruku  
3 Identyfikacja posiadacza karty (dla wszystkich kart w łożo­
nych do VU + GEN)  
4 Identyfikacja pojazdu (tego, dla którego sporz ądzany jest 
wydruk)  
5 Identyfikacja VU (z którego uzyskano wydruk +GEN)  
6 Ostatnia kalibracja tego VU  
7 Ostatnia kontrola tego tachografu  
9 Ogranicznik czynno ści kierowcy  
10 Ogranicznik szczeliny czytnika karty kierowcy (szczelina 1)  
10 a Stan poza zakresem na pocz ątku danego dnia  
10.1 / 10.2 / 10.3 / 
10.3a / 10.4  Czynności w kolejno ści chronologicznej (szczelina czytnika 
karty kierowcy)  
10 Ogranicznik szczeliny czytnika karty wspó łkierowcy (szcze ­
lina 2)  
10a Stan poza zakresem na pocz ątku danego dnia  
10.1 / 10.2 / 
10.3 /10.3a / 10.4  Czynności w kolejno ści chronologicznej (szczelina czytnika 
karty wspó łkierowcy)  
11 Ogranicznik dziennego zestawienia  
11.1 Zestawienie okresów bez karty w szczelinie czytnika karty 
kierowcy  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 268  
11.4 Miejsca wprowadzone w kolejno ści chronologicznej  
11.5 Położenia po 3 godzinach skumulowanego czasu prowa ­
dzenia pojazdu w kolejno ści chronologicznej  
11.7 Podsumowania dla czynno ści 
11.2 Zestawienie okresów bez karty w szczelinie czytnika karty 
współkierowcy  
11.4 Miejsca wprowadzone w kolejno ści chronologicznej  
11.5 Położenia po 3 godzinach skumulowanego czasu prowa ­
dzenia pojazdu w kolejno ści chronologicznej  
11.8 Podsumowania dla czynno ści 
11.3 Zestawienie czynno ści dla kierowcy z uwzgl ędnieniem obu 
szczelin czytnika kart  
11.4 Miejsca wprowadzone przez danego kierowc ę w kolejno ści 
chronologicznej  
11.5 Położenia po 3 godzinach skumulowanego czasu prowa ­
dzenia pojazdu w kolejno ści chronologicznej  
11.9 Podsumowania dla czynno ści danego kierowcy  
13.1 Ogranicznik zdarze ń/ usterek  
13.4 Rekordy zdarze ń/ usterek (5 ostatnich zdarze ń lub usterek 
zapisanych lub trwaj ących na VU)  
22.1 Miejsce kontroli  
22.2 Podpis kontrolera  
22.3 Od godziny (miejsce przeznaczone dla kierowcy bez karty 
w celu wskazania  
22.4 Do godziny dotycz ących go okresów)  
22.5 Podpis kierowcy  
▼B 
3.3. Wydruk zdarze ń i usterek z karty  
PRT_010 Wydruk zdarze ń i usterek z karty jest zgodny z poni ższym 
formatem: 
1 Data i godzina drukowania dokumentu  
2 Typ wydruku  
3 Identyfikacja kontrolera (je żeli w czytniku VU znajduje si ę karta 
kontrolna + GEN)  
3 Identyfikacja kierowcy (z karty, dla której sporz ądzany jest wydruk)  
4 Identyfikacja pojazdu (tego, dla którego sporz ądzany jest wydruk)  
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  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 269  
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 do VU 
+ GEN)  
4 Identyfikacja pojazdu (tego, dla którego sporz ądzany jest wydruk)  
13.2 Ogranicznik zdarze ń 
13.4 Rekordy zdarze ń (wszystkie zdarzenia zarejestrowane lub trwaj ące 
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  
3.5. Wydruk danych technicznych  
PRT_012 Wydruk danych technicznych 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 do VU 
+ GEN)  
4 Identyfikacja pojazdu (tego, dla którego sporz ądzany jest wydruk)  
14 Identyfikacja VU  
15 Identyfikacja czujnika  
15.1 Dane sparowania czujnika (wszystkie dane dost ępne w kolejno ści 
chronologicznej)  
16 Identyfikacja urz ądzenia GNSS  
16.1 Dane powi ązania urządzenia zewn ętrznego GNSS (wszystkie dane 
dostępne w kolejno ści chronologicznej)  
17 Ogranicznik danych kalibracyjnych  
17.1 Rekordy kalibracji (wszystkie dost ępne rekordy w kolejno ści chrono­
logicznej)  
18 Ogranicznik korekty czasu  
18.1 Rekordy korekty czasu (wszystkie dost ępne rekordy z rekordów 
korekty czasu i kalibracji)  
19 Ostatnie zdarzenie i usterka zarejestrowane w VU  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 270  
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 do VU 
+ GEN)  
4 Identyfikacja pojazdu (tego, dla którego sporz ądzany jest wydruk)  
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  
▼M1 
PRT_014 Wydruk historii w łożonych kart 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 do 
przyrządu rejestruj ącego)  
23 Karta ostatnio w łożona do VU  
23.1 Włożone karty (maks. 88 rekordów)  
12.3 Ogranicznik usterek  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 271  
Dodatek 5  
WYŚWIETLACZ  
W niniejszym dodatku przyj ęto następujące konwencje zapisu formatu:  
— 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 — 26.02.2020 — 002.001 — 272  
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ściopino­
wym, 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 — 26.02.2020 — 002.001 — 273  
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 — 26.02.2020 — 002.001 — 274  
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 wymaganiami 
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 pierwszy, a bajt 
najmniej znacz ący – ostatni.  
INT_006 Szybko ść transmisji danych w bodach regulowana jest w zakresie 
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 — 26.02.2020 — 002.001 — 275  
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 pierw ­
sze: 1999 r.).  
INT_008 Sygna ł we/wy musi by ć zgodny z nast ępującymi wymaganiami 
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 mA  
U high (wy)  4 V  I = 1 mA  
INT_009 Sygna ł we/wy musi by ć zgodny z nast ępującymi przebiegami 
czasowymi:
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 276  
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 — 26.02.2020 — 002.001 — 277  
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  
2.2.6.1 Positive Response Transfer Data Overview  
2.2.6.2 Positive Response Transfer Data Activities  
2.2.6.3 Positive Response Transfer Data Events and Faults  
2.2.6.4 Positive Response Transfer Data Detailed Speed  
2.2.6.5 Positive Response Transfer Data Technical Data  
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 pobra ­
nych danych, tak by umo żliwić każdemu kontrolerowi sprawdzenie 
tych danych oraz sprawdzenie autentyczno ści i integralno ści przed 
przystąpieniem do analizy danych.  
▼M1 
1.1. Zakres  
Dane mog ą być pobierane na ESM:  
— z przyrz ądu rejestruj ącego za po średnictwem inteligentnego urz ą­
dzenia dedykowanego (IDE) przy łączonego do VU,  
— z karty do tachografu za po średnictwem IDE spasowanego z czyt ­
nikiem karty (IFD),  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 278  
— z karty do tachografu za po średnictwem przyrz ądu rejestruj ącego 
poprzez IDE przy łączone do VU.  
Aby umożliwić weryfikacj ę autentyczno ści i integralno ści pobranych 
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ż identyfikacja 
urządzenia źródłowego (VU lub karta) i jego świadectwa bezpiecze ń­
stwa (państwo członkowskie i urz ądzenie). Niezale żnie od tego wery ­
fikator danych musi mie ć zaufany europejski klucz publiczny.  
Dane pobrane z przyrz ądu rejestruj ącego są podpisywane przy u życiu 
wspólnych mechanizmów zabezpiecze ń określonych w dodatku 11 
część B (System tachografu drugiej generacji), z wyj ątkiem sytuacji, 
gdy kontrol ę kierowców przeprowadza organ kontrolny spoza UE, 
używając karty kontrolnej pierwszej generacji, w którym to przypadku 
dane są podpisywane przy u życiu wspólnych mechanizmów zabezpie ­
czeń określonych w dodatku 11 cz ęść A (System tachografu pierwszej 
generacji), zgodnie z wymogiem okre ślonym w dodatku 15 „Migracja”, 
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 — 26.02.2020 — 002.001 — 279  
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 lutego 
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 doce ­
lowy (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  …  …  …  CS  
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 kierowcy w łożonej do 
jednej ze szczelin VU, je żeli w drugiej szczelinie nie ma żadnej innej karty.
 02016R0799 — PL — 26.02.2020 — 002.001 — 280  
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 polu danych, musi by ć dołączony końcowy podkomu ­
nikat z pustym polem danych (z wyj ątkiem SID TREP 
i licznika podkomunikatów) w celu pokazania ko ńca komu­
nikatu.  
Przykład: 
Nagłówek  SID  TREP  Komunikat  CS  
4 bajty  d łuższy niż 255 bajtów  
zostanie przes łany w nast ępujący sposób:  
Nagłówek  SID  TREP  00  01  Podkomunikat 
1 CS 
4 bajty  255 bajtów  
Nagłówek  SID  TREP  00  02  Podkomunikat 
2 CS 
4 bajty  255 bajtów  
… 
Nagłówek  SID  TREP  xx  yy  Podkomunikat 
n CS 
4 bajty  mniej ni ż 255 bajtów  
lub w taki sposób:  
Nagłówek  SID  TREP  00  01  Podkomunikat 
1 CS 
4 bajty  255 bajtów  
Nagłówek  SID  TREP  00  02  Podkomunikat 
2 CS 
4 bajty  255 bajtów  
… 
Nagłówek  SID  TREP  xx  yy  Podkomunikat 
n CS 
4 bajty  255 bajtów  
Nagłówek  SID  TREP  xx  yy + 1  CS  
4 bajty  4 bajty  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 281  
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.  
▼M1 
Struktura komunikatu  Maks. 4 bajty Nag łówek  Maks. 255 bajtów Dane  1 bajt 
Suma 
kontro­
lna 
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DANE  CS  
Start Communication Request  81  EE  F0  81  E0  
Positive Response Start 
Communication  80 F0  EE  03  C1  EA, 8F  9B  
Start Diagnostic Session 
Request  80 EE  F0  02  10  81  F1  
Positive Response Start 
Diagnostic  80 F0  EE  02  50  81  31  
Link Control Service  
Verify Baud Rate (stage 1)  
9 600 Bd  80  EE  F0  04  87  01,01,01  EC  
19 200 Bd  80  EE  F0  04  87  01,01,02  ED  
38 400 Bd  80  EE  F0  04  87  01,01,03  EE  
57 600 Bd  80  EE  F0  04  87  01,01,04  EF  
115 200 Bd  80  EE  F0  04  87  01,01,05  F0  
Positive Response Verify Baud 
Rate 80 F0  EE  02  C7  01  28  
Transition Baud Rate (stage 2)  80  EE  F0  03  87  02,03  ED  
Request Upload  80  EE  F0  0A  35  00,00,00,00, 
00,FF,FF, 
FF,FF  99 
Positive Response Request 
Upload  80 F0  EE  03  75  00,FF  D5  
Transfer Data Request  
Overview  80  EE  F0  02  36  01 lub 21  97  
Activities  80  EE  F0  06  36  02 lub 22  Date  CS  
Events & Faults  80  EE  F0  02  36  03 lub 23  Date  99  
Detailed Speed  80  EE  F0  02  36  04 lub 24  Date  9A  
Technical Data  80  EE  F0  02  36  05 lub 25  Date  9B  
Card download  80  EE  F0  02  36  06  Slot  CS  
Positive Response Transfer 
Data  80 F0  EE  Len  76  TREP  Data  CS  
Request Transfer Exit  80  EE  F0  01  37  96  
Positive Response Request 
Transfer Exit  80 F0  EE  01  77  D6  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 282  
Struktura komunikatu  Maks. 4 bajty Nag łówek  Maks. 255 bajtów Dane  1 bajt 
Suma 
kontro­
lna 
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DANE  CS  
Stop Communication Request  80  EE  F0  01  82  E1  
Positive Response Stop 
Communication  80 F0  EE  01  C2  21  
Acknowledge sub message  80  EE  F0  Len  83  Data  CS  
Negative responses  
General reject  80  F0  EE  03  7F  Sid Req  10  CS  
Service not supported  80  F0  EE  03  7F  Sid Req  11  CS  
Sub function not supported  80  F0  EE  03  7F  Sid Req  12  CS  
Incorrect Message Length  80  F0  EE  03  7F  Sid Req  13  CS  
Conditions not correct or 
Request sequence error  80 F0  EE  03  7F  Sid Req  22  CS  
Request out of range  80  F0  EE  03  7F  Sid Req  31  CS  
Upload not accepted  80  F0  EE  03  7F  Sid Req  50  CS  
Response pending  80  F0  EE  03  7F  Sid Req  78  CS  
Data not available  80  F0  EE  03  7F  Sid Req  FA  CS  
▼B 
Uwagi:  
▼M1 
— TRTP 21–25 u żywa się w przypadku żądań pobrania danych z przy ­
rządu rejestruj ącego typu 2. generacji, TRTP 01–05 u żywa się 
w przypadku żądań pobrania danych z przyrz ądu rejestruj ącego 
typu 1. generacji, które mog ą zostać zaakceptowane przez przyrz ąd 
rejestrujący w ramach kontroli kierowcy przeprowadzanej przez 
organ kontrolny spoza UE przy u życiu karty kontrolnej 1. genera ­
cji. 
— TRTP 11–19 oraz 31–39 s ą zarezerwowane dla żądań pobrania 
swoistych dla producenta.  
▼B 
— 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 karty 
współkierowcy)  
— W przypadku gdy szczelina nie jest okre ślona, VU wybiera szcze ­
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.  
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).  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 283  
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.  
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 Uplo ­
ad”, aby wskaza ć IDE, że VU jest gotowe do pobierania 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 284  
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.  
Rozróżnia się sześć 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 przyrządu rejestru ­
jącego typu 1. gene ­
racji Wartość TRTP 
w przypadku żądań 
pobrania danych 
z przyrządu rejestru ­
jącego typu 2. gene ­
racji 
Przegląd 01  21  
Czynności o okre­ 
ślonej dacie  02 22  
Zdarzenia i usterki  03  23  
Szczegółowe dane 
dotyczące prędko­ 
ści 04 24  
Dane techniczne  05  25  
Typ transferu 
danych  Wartość TRTP  
Pobieranie 
danych z karty  06 
DDP_054 IDE musi obowi ązkowo zażądać przesłania danych Infor ­
macje ogólne (TRTP 01 lub 21) w czasie sesji pobierania, 
ponieważ tylko to zagwarantuje, że certyfikaty VU s ą 
zarejestrowane w pobieranym pliku (i umo żliwi weryfikacj ę 
podpisu cyfrowego).  
W drugim przypadku (TRTP 02 lub 22) w komunikacie 
„Transfer Data Request” znajduje si ę informacja o dniu 
kalendarzowym (format
  ), 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.  
▼M1 
DDP_055 W pierwszym przypadku (TREP 01 lub 21) VU wy śle dane 
pomagające operatorowi IDE w wyborze danych, które chce 
dalej pobra ć. Komunikat ten zawiera nast ępujące informa ­
cje: 
— świadectwa bezpiecze ństwa, ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 285  
— 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”.  
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 podkomu ­
nikatu.  
— 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)  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 286  
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. 
— 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 VU  
Start Communication Request  ⇨ 
⇦  Positive Response  
Start Diagnostic Service Request  ⇨ 
⇦  Positive Response  
Request Upload  ⇨ 
⇦  Positive Response  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 287  
IDE VU  
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 — 26.02.2020 — 002.001 — 288  
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  20  
P2 20  1 000 (*)  
P3 10  5 000  
P4 5  20  
P5 10  20 minut  
(*) Jeżeli VU daje negatywn ą odpowied ź „Negative Response” zawieraj ącą kod o znaczeniu „ żądanie odebrane 
prawidłowo, odpowied ź zawieszona”, warto ść ta zostaje przed łużona 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 ącego 
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 wykryje 
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 — 26.02.2020 — 002.001 — 289  
Rysunek 2  
Obsługa błędów w VU
  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 290  
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 zaczyna si ę 
od nagłówka; nag łówek ten zawiera typ rekordu, wielko ść rekordu 
i liczbę rekordów. Tablice rekordów oznaczone s ą za pomoc ą „…Re­
cordArray” (z nag łówkiem) w poni ższych tabelach.  
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 O v e r v i e w  
DDP_029  ►M1 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 lub 21 Hex 
z odpowiednim podzia łem na podkomunikaty 
i licznikami: ◄ ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 291  
Struktura danych 1. generacji (TREP 01 Hex)  
▼B 
Element danych  Uwagi
  
świadectwa bezpiecze ństwa VU
  
identyfikacja pojazdu
  
bieżąca data i godzina VU
  
okres do pobrania
  
typy kart w łożonych do VU
  
poprzednie pobranie danych z VU
  
Wszystkie przechowywane blokady firmowe. 
Jeżeli sekcja jest pusta, wysy łany jest jedynie 
noOfLocks = 0.
  
Wszystkie rekordy dotycz ące kontroli przecho ­
wywane w VU. Je żeli sekcja jest pusta, wysy ­ 
łany jest jedynie noOfControls = 0.
  
Podpis RSA wszystkich danych (z wyj ątkiem 
certyfikatów), pocz ąwszy od elementu VehicleI ­
dentificationNumber a ż do ostatniego bajtu ostat ­
niego elementu VuControlActivityData.  
▼M1 
Struktura danych 2. generacji (TREP 21 Hex)  
▼B 
Element danych  Uwagi
  
certyfikat pa ństwa członkowskiego
  
certyfikat VU
  
identyfikacja pojazdu
  
numer rejestracyjny pojazdu
  
bieżąca data i godzina VU
  
okres do pobrania
  
typy kart w łożonych do VU
  
poprzednie pobranie danych z VU
  
Wszystkie przechowywane blokady firmowe. 
Jeżeli sekcja jest pusta, wysy łany jest nag łówek 
tablicy z noOfRecords = 0.
  
Wszystkie rekordy dotycz ące kontroli przecho ­
wywane w VU. Je żeli sekcja jest pusta, wysy ­ 
łany jest nag łówek tablicy z noOfRecords = 0.
  
Podpis ECC wszystkich poprzednich danych, 
z wyjątkiem certyfikatów.  
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 A c t i v i t i e s  
DDP_030  ►M1 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 lub 22 Hex 
z odpowiednim podzia łem na podkomunikaty 
i licznikami: ◄ ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 292  
Struktura danych 1. generacji (TREP 02 Hex)  
▼B 
Element danych  Uwagi
  
data pobieranego dnia
  
stan licznika kilometrów na koniec pobieranego dnia
  
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 pojawia ć się 
w pełni w ciągu dwóch odpowiednich dni.
  
Stan szczelin o godzinie 00:00 i zmiany czynno ści zapi­
sane dla pobieranego dnia.
  
Dane dotycz ące miejsc zapisane dla pobieranego dnia. 
Jeżeli sekcja jest pusta, wysy łany jest jedynie noOfPlace ­
Records = 0.
  
Dane dotycz ące warunków szczególnych zapisane dla 
pobieranego dnia. Je żeli sekcja jest pusta, wysy łany 
jest jedynie noOfSpecificConditionRecords=0.
  
Podpis RSA wszystkich danych, pocz ąwszy od elementu 
TimeReal a ż do ostatniego bajtu ostatniego rekordu doty ­
czącego stanu szczególnego.  
▼M1 
Struktura danych 2. generacji (TREP 22 Hex)  
▼B 
Element danych  Uwagi
  
data pobieranego dnia
  
stan licznika kilometrów na koniec pobieranego dnia
  
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 pojawia ć się 
w pełni w ciągu dwóch odpowiednich dni.
  
Stan szczelin o godzinie 00:00 i zmiany czynno ści zapi­
sane dla pobieranego dnia.
  
Dane dotycz ące miejsc zapisane dla pobieranego dnia. 
Jeżeli sekcja jest pusta, wysy łany jest nag łówek tablicy 
z noOfRecords = 0.  
▼M1
 
Pozycje GNSS dla pojazdu, gdy skumulowany czas 
prowadzenia pojazdu osi ągnie wielokrotno ść trzech 
godzin. Jeżeli sekcja jest pusta, wysy łany jest nag łówek 
tablicy z noOfRecords = 0.  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 293  
Element danych  Uwagi
  
Dane dotycz ące warunków szczególnych zapisane dla 
pobieranego dnia. Je żeli sekcja jest pusta, wysy łany 
jest nagłówek tablicy z noOfRecords =0.
  
Podpis ECC wszystkich poprzednich danych.  
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 E v e n t s a n d F a u l t s  
DDP_031  ►M1 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 lub 23 Hex, z odpowiednim podzia łem na podkomuni ­
katy i z licznikami: ◄ 
▼M1 
Struktura danych 1. generacji (TREP 03 Hex)  
▼B 
Element danych  Uwagi
  
Wszystkie usterki przechowywane lub trwaj ące 
w VU. 
Jeżeli sekcja jest pusta, wysy łany jest jedynie 
noOfVuFaults = 0.
  
Wszystkie zdarzenia (z wyj ątkiem przekroczenia 
prędkości) przechowywane lub trwaj ące w VU. 
Jeżeli sekcja jest pusta, wysy łany jest jedynie 
noOfVuEvents = 0.
  
Dane dotycz ące ostatniej kontroli przekroczenia 
prędkości (wartość domyślna w przypadku braku 
danych).
  
Wszystkie zdarzenia dotycz ące przekroczenia 
prędkości przechowywane w VU. 
Jeżeli sekcja jest pusta, wysy łany jest jedynie 
noOfVuOverSpeedingEvents = 0.
  
Wszystkie zdarzenia dotycz ące korekty czasu 
przechowywane w VU (poza ramami pe łnej 
kalibracji). 
Jeżeli sekcja jest pusta, wysy łany jest jedynie 
noOfVuTimeAdjRecords = 0.
  
Podpis RSA wszystkich danych, pocz ąwszy od 
noOfVuFaults a ż do ostatniego bajtu ostatniego 
rekordu dotycz ącego korekty czasu.  
▼M1 
Struktura danych 2. generacji (TREP 23 Hex)  
▼B 
Element danych  Uwagi
  
Wszystkie usterki przechowywane lub trwaj ące 
w VU. 
Jeżeli sekcja jest pusta, wysy łany jest nag łówek 
tablicy z noOfRecords = 0.
  
Wszystkie zdarzenia (z wyj ątkiem przekroczenia 
prędkości) przechowywane lub trwaj ące w VU. 
Jeżeli sekcja jest pusta, wysy łany jest nag łówek 
tablicy z noOfRecords = 0.
  
Dane dotycz ące ostatniej kontroli przekroczenia 
prędkości (wartość domyślna w przypadku braku 
danych).
  
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.  ▼B
02016R0799 — PL — 26.02.2020 — 002.001 — 294 
Element danych Uwagi
  
Wszystkie zdarzenia dotycz ące korekty czasu przechowy ­
wane w VU (poza ramami pe łnej kalibracji). 
Jeżeli sekcja jest pusta, wysy łany jest nag łówek tablicy 
z noOfRecords = 0.  
▼M1__________  
▼B
Podpis ECC wszystkich poprzednich danych.  
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 D e t a i l e d S p e e d  
DDP_032 ►M1 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 licznikami: ◄ 
▼M1
Struktura danych 1. generacji (TREP 04)  
▼B
Element danych Uwagi
  
Wszystkie szczegó łowe dane dotycz ące pręd­
kości przechowywane w VU (jeden blok pr ęd­
kości dla minuty, przez któr ą pojazd by ł 
w ruchu). 
60 wartości prę dkości na minut ę (jedna na 
sekundę).
 
Podpis RSA wszystkich danych, pocz ąwszy od 
noOfSpeedBlocks a ż do ostatniego bajtu ostat ­
niego bloku pr ędkości. 
▼M1
Struktura danych 2. generacji (TREP 24)  
▼B
Element danych Uwagi
  
Wszystkie szczegó łowe dane dotycz ące pręd­
kości przechowywane w VU (jeden blok pr ęd­
kości dla minuty, przez któr ą pojazd by ł 
w ruchu). 
60 wartości prę dkości na minut ę (jedna na 
sekundę).
 
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 T e c h n i c a l D a t a  
DDP_033 ►M1 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 lub 
25 Hex z odpowiednim podzia łem na podkomunikaty 
i licznikami: ◄ ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 295  
Struktura danych 1. generacji (TREP 05)  
▼B 
Element danych  Uwagi
  
Wszystkie rekordy dotycz ące kalibracji przecho ­
wywane w VU.
  
Podpis RSA wszystkich danych, pocz ąwszy od 
vuManufacturerName a ż do ostatniego bajtu 
ostatniego VuCalibrationRecord.  
▼M1 
Struktura danych 2. generacji (TREP 25)  
▼B 
Element danych  Uwagi
  
Wszystkie sparowania pa ństw członkowskich 
przechowywane w VU.
  
Wszystkie powi ązania urządzenia zewn ętrznego 
GNSS przechowywane w VU.
  
Wszystkie rekordy dotycz ące kalibracji przecho ­
wywane w VU.
  
Wszystkie dane dotycz ące włożenia karty prze ­
chowywane w VU.
  
Podpis ECC wszystkich poprzednich danych.  
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 komunikatami 
„Positive Response Transfer Data”. Dane przechowuje si ę 
bez nagłówków komunikatów, liczników podkomunikatów, 
pustych podkomunikatów i sum kontrolnych, ale wraz 
z SID i TREP (tylko pierwszego podkomunikatu w przy ­
padku 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 IDE.  
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).  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 296  
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.  
3.3. Pobieranie danych z karty  
▼M1 
DDP_035 Pobieranie danych z karty do tachografu obejmuje nast ępu­
jące kroki:  
— Pobieranie wspólnych informacji zawartych na karcie 
w plikach EF
  oraz
  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
  
: 
— Wczytanie plików EF
  i
  
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 apli ­
kacyjne (w
  ) z wy łączeniem EF
  
Informacje takie s ą zabezpie­
czone podpisem cyfrowym przy u życiu wspólnych 
mechanizmów zabezpieczenia okre ślonych w dodatku 
11 część A. 
— Pobranie przynajmniej plików EF
  
i
 
jest obowi ązkowe dla ka żdej 
sesji pobierania.  
— Przy pobieraniu danych z karty kierowcy obowi ąz­
kowe jest pobranie tak że następujących plików EF:
  
— (w przypadku wy łącznie 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 prze ­
prowadzanej przez organ kontrolny spoza UE przy 
użyciu karty kontrolnej pierwszej generacji, pobie ­
ranie w plikach EF
  :  
— Pobieranie w plikach EF CardSignCertificate, 
CA_Certificate oraz Link_Certificate (je żeli 
występują). 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
  ) 
z wyłączeniem EF
  Infor ­
macje takie s ą zabezpieczone podpisem 
cyfrowym przy u życiu wspólnych mechanizmów 
zabezpieczenia okre ślonych w dodatku 11 
część B. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 297  
— Pobranie przynajmniej plików EF
  
i
 
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:
  
— Przy wczytywaniu danych z karty kierowcy aktua ­
lizowana jest data
  
w pliku EF
  w DF
  
i, w stosownych przypadkach,
  
— Przy pobieraniu danych z karty warsztatowej 
zerowany jest licznik kalibracji w pliku EF
  
w DF
  
i, w stosownych przypadkach,
  
— Przy pobieraniu danych z karty warsztatowej pliki 
EF
 w DF
  
i, w stosownych przypadkach,
  
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ę funk­
cję. 
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  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 298  
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, stosuje 
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 
wymaganego algorytmu 
skrótu zgodnie z dodat ­
kiem 11 cz ęść A lub B. 
Polecenie to nie jest 
poleceniem ISO.  
oblicz skrót pliku 
i czasowo zachowaj 
wartość skrótu  
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ą „Com­
pute 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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 299  
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.  
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 dodat ­
kiem „00”.  
DDP_043 Znacznikiem podpisu pliku EF jest identyfikator pliku FID 
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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 300  
Definicja  Znaczenie  D ługość 
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  
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 ę przy 
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 — 26.02.2020 — 002.001 — 301  
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 — 26.02.2020 — 002.001 — 302  
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  
8. FORMATY DATARECORDS  
8.1. Zakresy przesy łanych parametrów  
8.2. Formaty dataRecords  
1. WPROWADZENIE  
Niniejszy dodatek opisuje wymian ę danych mi ędzy przyrz ądem rejes­
trującym a testerem poprzez łącze K-line, które stanowi cz ęść interfejsu 
kalibracyjnego opisanego w dodatku 6. Opisano tu tak że sterowanie 
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 wszystkie 
dane można odczyta ć z przyrządu rejestruj ącego, ale żadnych danych 
nie można zapisać w przyrządzie rejestruj ącym.  
Wybór sesji diagnostycznej opisano w sekcji 5 „Us ługi zarządzania”.  
Niniejszy dodatek musi by ć uznany za odnosz ący się do obu generacji 
VU i kart warsztatowych, zgodnie z wymaganiami w zakresie intero ­
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 jako 
„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 — 26.02.2020 — 002.001 — 303  
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 lutego 
2001 r.).  
Kodowania bajtowego i warto ści heksadecymalnych u żywa się w iden­
tyfikatorach us ług, żądaniach us ług i odpowiedziach oraz parametrach 
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 VU.  
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 dokumencie.  
CPR_004 Tabela wskazuje us ługi dostępne przy w łączonej sesji diag ­
nostycznej.  
— 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 — 26.02.2020 — 002.001 — 304  
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  81  ■ ■ ■ 
StopCommunication  4.2  82  ■ 
TesterPresent  4.3  3E  ■ ■ ■ 
StartDiagnosticSession  5.1  10  ■ ■ ■ 
SecurityAccess  5.2  27  ■ ■ ■ 
ReadDataByIdentifier  6.1  22  ■ ■ ■ 
WriteDataByIdentifier  6.2  2E  ■ 
InputOutputControlByIdentifier  7.1  2F  ■ 
■ Symbol ten oznacza, że usługa jest obowi ązkowa w tej sesji diagnostycznej. 
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 komunika ­
cji. Nie wyst ępują one w warstwie aplikacji. Dost ępne usługi wyszcze ­
gó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 — 26.02.2020 — 002.001 — 305  
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 ą dowolną 
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 komunikacyj ­
nego.  
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 magist ­
rali. 
— 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 śl­
nym, 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 wywo ­ 
ł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 — 26.02.2020 — 002.001 — 306  
CPR_017 Warto ści czasów dla szybkiej inicjalizacji i ogólnie komu ­
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 20  
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 20  
CPR_018 Format komunikatu dla szybkiej inicjalizacji opisano szcze ­
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  EE  TGT  
#3 Bajt adresu źródłowego  tt  SRC  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 307  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#4 StartCommunication Request 
Service Id  81 SCR  
#5 Suma kontrolna  00-FF  CS  
Tabela 6  
Komunikat StartCommunication Positive Reponse  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 03  LEN  
#5 StartCommunication Positive 
Response Service Id  C1 SCRPR  
#6 Bajt kluczowy 1  EA  KB1  
#7 Bajt kluczowy 2  8F  KB2  
#8 Suma kontrolna  00-FF  CS  
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 komuni ­
kacyjnej.  
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 komu ­
nikacyjnej.  
CPR_021 Je żeli zakończenie sesji komunikacyjnej jest mo żliwe, VU – 
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 żliwe 
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 — 26.02.2020 — 002.001 — 308  
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  EE  TGT  
#3 Bajt adresu źródłowego  tt  SRC  
#4 Dodatkowy bajt d ługości 01  LEN  
#5 StopCommunication Request 
Service Id  82 SPR  
#6 Suma kontrolna  00-FF  CS  
Tabela 8  
Komunikat StopCommunication Positive Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 01  LEN  
#5 StopCommunication Positive 
Response Service Id  C2 SPRPR  
#6 Suma kontrolna  00-FF  CS  
Tabela 9  
Komunikat StopCommunication Negative Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 03  LEN  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 309  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#5 negative Response Service Id  7F  NR  
#6 StopCommunication Request 
Service Identification  82 SPR  
#7 responseCode = generalReject  10  RC_GR  
#8 Suma kontrolna  00-FF  CS  
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 jeszcze 
jest obecny, w celu zapobie żenia automatycznemu powrotowi serwera 
do normalnego trybu pracy i zerwania komunikacji. Us ługa ta, wysy ­ 
łana okresowo, utrzymuje sesj ę diagnostyczn ą/komunikacyjn ą w stanie 
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  EE  TGT  
#3 Bajt adresu źródłowego  tt  SRC  
#4 Dodatkowy bajt d ługości 02  LEN  
#5 TesterPresent Request 
Service Id  3E TP  
#6 podfunkcja = respon ­
seRequired =  [ tak  01  RESPREQ_Y  
nie ]  02  RESPREQ_NO  
#7 Suma kontrolna  00-FF  CS  
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 — 26.02.2020 — 002.001 — 310  
Tabela 11  
Komunikat TesterPresent Positive Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 01  LEN  
#5 TesterPresent Positive 
Response Service Id  7E TPPR  
#6 Suma kontrolna  00-FF  CS  
CPR_081 Us ługa używa następujących kodów negatywnej odpowie ­
dzi: 
Tabela 12  
Komunikat TesterPresent Negative Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  80  FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 03  LEN  
#5 negative Response Service Id  7F  NR  
#6 TesterPresent Request Service Identi ­
fication  3E TP  
#7 response ­
Code =  [SubFunctionNotSup ­
ported-InvalidFormat  12 RC_SFNS_IF  
incorrectMessage ­
Length ]  13 RC_IML  
#8 Suma kontrolna  00-FF  CS  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 311  
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 diagno ­
stycznej z VU.  
SecurityAccess  Klient żąda dostępu do funkcji 
zastrzeżonych dla uprawnionych u żyt­
kowników.  
5.1. Usługa StartDiagnosticSession  
5.1.1  Opis komunikatu  
CPR_025 Us ługa StartDiagnosticSession s łuży do włączania różnych 
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 diag ­
nostyczna.  
— 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 — 26.02.2020 — 002.001 — 312  
Tabela 14  
Komunikat StartDiagnosticSession Request  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  EE  TGT  
#3 Bajt adresu źródłowego  tt  SRC  
#4 Dodatkowy bajt d ługości 02  LEN  
#5 StartDiagnosticSession 
Request Service Id  10 STDS  
#6 diagnosticSession = [jedna 
wartość z tabeli 17]  xx DS_…  
#7 Suma kontrolna  00-FF  CS  
Tabela 15  
Komunikat StartDiagnosticSession Positive Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 02  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  CS  
Tabela 16  
Komunikat StartDiagnosticSession Negative Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  80  FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 313  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#4 Dodatkowy bajt d ługości 03  LEN  
#5 Negative Response Service Id  7F  NR  
#6 StartDiagnosticSession Request 
Service Id  10 STDS  
#7 Response ­
Code =  [subFunctionNotSup ­
ported (  a ) 12 RC_SFNS  
incorrectMessage ­
Length (  b ) 13 RC_IML  
conditionsNotCor ­
rect (  c ) 22 RC_CNC  
#8 Suma kontrolna  00-FF  CS  
( a ) – wartość wstawiona w bajcie #6 komunikatu żądania nie jest obs ługiwana, tzn. nie 
ma jej w tabeli 17; 
( b ) – długość komunikatu jest nieprawid łowa; 
( c ) – 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 — 26.02.2020 — 002.001 — 314  
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 KALIBRACYJ ­
NYM. Dodatkowo, oprócz w łożenia do VU wa żnej karty warsztatowej, 
niezbędne jest wprowadzenie numeru PIN do VU przed uzyskaniem 
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 przeka ­
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 „requestSe ­
ed”, po którym mo że nastąpić komunikat SecurityAccess „sendKey”. 
Usługa SecurityAccess musi by ć przeprowadzona po us łudze Start ­
DiagnosticSession.  
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 KALIBRACYJ ­
NYM, 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 numeru 
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 ęcia 
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 SecurityAc ­
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 
odpowiedzi requestCorrectlyReceived-ResponsePending. 
Maksymalny czas oczekiwania na odpowied ź nie może 
jednak przekracza ć 5 minut. Gdy tylko żądana usługa ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 315  
zostaje zako ńczona, VU wysy ła komunikat pozytywnej 
odpowiedzi lub komunikat negatywnej odpowiedzi 
z kodem odpowiedzi ró żnym od tego pierwszego kodu. 
VU może powtarza ć kod negatywnej odpowiedzi reques ­
tCorrectlyReceived-ResponsePending a ż do zako ńczenia 
żądanej usługi i wysłania komunikatu ostatecznej odpowie ­
dzi. 
CPR_038 Przyrz ąd rejestrujący odpowiada na to żądanie przy pomocy 
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  EE  TGT  
#3 Bajt adresu źródłowego  tt  SRC  
#4 Dodatkowy bajt d ługości 02  LEN  
#5 SecurityAccess Request 
Service Id  27 SA  
#6 accessType – requestSeed  7D  AT_RSD  
#7 Suma kontrolna  00-FF  CS  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 316  
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  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 04  LEN  
#5 SecurityAccess Positive 
Response Service Id  67 SAPR  
#6 accessType – requestSeed  7D  AT_RSD  
#7 Seed High  00-FF  SEEDH  
#8 Seed Low  00-FF  SEEDL  
#9 Suma kontrolna  00-FF  CS  
Tabela 20  
Komunikat SecurityAccess Negative Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  80  FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 03  LEN  
#5 negativeResponse Service Id  7F  NR  
#6 SecurityAccess Request Service Id  27  SA  
#7 response ­
Code =  [conditionsNotCorrec ­
tOrRequestSequence ­
Error  22 RC_CNC  
incorrectMessage ­
Length]  13 RC_IML  
#8 Suma kontrolna  00-FF  CS  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 317  
5.2.3  Format komunikatu – SecurityAccess – sendKey  
CPR_041 Formaty komunikatu dla prymitywów SecurityAccess „sen ­
dKey” 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  EE  TGT  
#3 Bajt adresu źródłowego  tt  SRC  
#4 Dodatkowy bajt d ługości m+2  LEN  
#5 SecurityAccess Request 
Service Id  27 SA  
#6 accessType – sendKey  7E  AT_SK  
#7 do #m+6  Klucz#1 (najwy ższy) xx  KEY  
… …  
Klucz #m (ni ższy, m musi by ć 
minimum 4 i maksimum 8)  xx 
#m+7  Suma kontrolna  00-FF  CS  
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  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 02  LEN  
#5 SecurityAccess Positive 
Response Service Id  67 SAPR  
#6 accessType – sendKey  7E  AT_SK  
#7 Suma kontrolna  00-FF  CS  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 318  
Tabela 23  
Komunikat SecurityAccess Negative Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  80  FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 03  LEN  
#5 NegativeResponse Service Id  7F  NR  
#6 SecurityAccess Request Service Id  27  SA  
#7 Response ­
Code =  [generalReject  10  RC_GR  
subFunctionNotSup ­
ported  12 RC_SFNS  
incorrectMessageLen ­
gth 13 RC_IML  
conditionsNotCorrec ­
tOrRequestSequence ­
Error  22 RC_CNC  
invalidKey  35  RC_IK  
exceededNumberO ­
fAttempts  36 RC_ENA  
requestCorrectlyRe ­
ceived-ResponsePen ­
ding]  78 RC_RCR_RP  
#8 Suma kontrolna  00-FF  CS  
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 — 26.02.2020 — 002.001 — 319  
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  EE  TGT  
#3 Bajt adresu źródłowego  tt  SRC  
#4 Dodatkowy bajt d ługości 03  LEN  
#5 ReadDataByIdentifier 
Request Service Id  22 RDBI  
#6 do #7  recordDataIdentifier = [warto ść 
z tabeli 28]  xxxx  RDI_…  
#8 Suma kontrolna  00-FF  CS  
Tabela 26  
Komunikat ReadDataByIdentifier Positive Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  80  FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  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 — 26.02.2020 — 002.001 — 320  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#8 do 
#m + 7  dataRecord[] =  [data#1  xx  DREC_DA ­
TA1 
: :  :  
data#m]  xx  DREC_DA ­
TAm  
#m+8  Suma kontrolna  00-FF  CS  
Tabela 27  
Komunikat ReadDataByIdentifier Negative Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  80  FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 03  LEN  
#5 NegativeResponse Service Id  7F  NR  
#6 ReadDataByIdentifier Request 
Service Id  22 RDBI  
#7 ResponseCo ­
de= [requestOutOf ­
Range  31 RC_ROOR  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCor ­
rect] 22 RC_CNC  
#8 Suma kontrolna  00-FF  CS  
6.1.3  Definicja parametru  
CPR_052 Parametr  recordDataIdentifier (RDI_)  w komunikacie 
żądania ReadDataByIdentifier wskazuje rekord danych.  
CPR_053 Warto ści recordDataIdentifier zdefiniowane w tym doku ­
mencie pokazano w tabeli poni żej. 
Tabela recordDataIdentifier sk łada się z czterech kolumn 
i wielu rzędów.  
— 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 — 26.02.2020 — 002.001 — 321  
— Trzecia kolumna (Opis)  podaje nazw ę odpowiadaj ą­
cego identyfikatora recordDataIdentifier.  
— Czwarta kolumna (Mnemonik)  podaje mnemonik tego 
identyfikatora recordDataIdentifier.  
Tabela 28  
Definicja warto ści recordDataIdentifier  
Heks  Element danych  Nazwa recordDataldentifier 
(zob. format w sekcji 8.2)  Mnemonik  
F90B
  TimeDate  RDI_TD  
F912
  HighResolutionTotalVehicle ­
Distance  RDI_HRTVD  
F918
  Kfactor  RDI_KF  
F91C
  LfactorTyreCircumference  RDI_LF  
F91D
  WvehicleCharacteristicFactor  RDI_WVCF  
F921
  TyreSize  RDI_TS  
F922
  NextCalibrationDate  RDI_NCD  
F92C
  SpeedAuthorised  RDI_SA  
F97D
  RegisteringMemberState  RDI_RMS  
F97E
  VehicleRegistrationNumber  RDI_ VRN  
F190
  VIN  RDI_ VIN  
CPR_054 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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 322  
Tabela 29  
Komunikat WriteDataByIdentifier Request  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  80  FMT  
#2 Bajt adresu docelowego  EE  TGT  
#3 Bajt adresu źródłowego  tt  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  xx  DREC_DA ­
TA1 
: :  :  
data#m]  xx  DREC_DA ­
TAm  
#m+8  Suma kontrolna  00-FF  CS  
Tabela 30  
Komunikat WriteDataByIdentifier Positive Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 03  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  CS  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 323  
Tabela 31  
Komunikat WriteDataByIdentifier Negative Response  
# bajtu  Nazwa parametru  Wartość 
heksade­
cymalna  Mnemonik  
#1 Bajt formatu – adresowanie fizyczne  80  FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 03  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  CS  
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 wska ­
zanego serwerowi (VU) przez recordDataIdentifier. Formaty danych 
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 żliwia 
sterowanie lub monitorowanie impulsów testowych przy pomocy odpo ­
wiedniego testera.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 324  
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 regu ­
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). 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 325  
Tabela 33  
Komunikat InputOutputControlByIdentifier Request  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  EE  TGT  
#3 Bajt adresu źródłowego  tt  SRC  
#4 Dodatkowy bajt d ługości xx  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  CS  
Uwaga:  Parametr controlState wyst ępuje tylko w okre ślo­
nych przypadkach (zob. 7.1.3).  
Tabela 34  
Komunikat InputOutputControlByIdentifier Positive 
Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości xx  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  CS  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 326  
Tabela 35  
Komunikat InputOutputControlByIdentifier Negative Response  
# bajtu  Nazwa parametru  Wartość heksa­
decymalna  Mnemonik  
#1 Bajt formatu – adresowanie 
fizyczne  80 FMT  
#2 Bajt adresu docelowego  tt  TGT  
#3 Bajt adresu źródłowego  EE  SRC  
#4 Dodatkowy bajt d ługości 03  LEN  
#5 negativeResponse Service Id  7F  NR  
#6 inputOutputControlByIdentifier 
Request SId  2F IOCBI  
#7 responseCode=[  
incorrectMessageLength  13  RC_IML  
conditionsNotCorrect  22  RC_CNC  
requestOutOfRange  31  RC_ROOR  
deviceControlLimitsExceeded]  7A  RC_DCLE  
#8 Suma kontrolna  00-FF  CS  
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 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 327  
Heks  Wyszczególnienie  Mnemonik  
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  00  linia we/wy wy łączona (stan domy ślny) 
włączony  01  włącz linię sygnałową we/wy kalibracji jako 
speedSignalInput  
włączony  02  włącz linię sygnałową we/wy kalibracji jako 
realTimeSpeedSignalOutputSensor  
włączony  03  włącz linię sygnałową we/wy kalibracji jako 
RTCOutput  
8. 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 poprzez 
usługi przesy łania danych opisane w sekcji 6.  
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).  
8.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 para ­
metr, 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 wskazanie 
tych parametrów, w przypadku gdy od urz ądzenia odbiera ­
jącego oczekiwany jest brak odpowiedzi.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 328  
CPR_072 Je żeli usterka elementu sk ładowego uniemo żliwia wysłanie 
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 prze ­
syłane są przy użyciu odpowiednio warto ści minimalnej lub 
maksymalnej parametru.  
Tabela 38  
Zakresy dataRecords  
Nazwa zakresu  1 bajt 
(wartość heksade­
cymalna)  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  FB  FB00 do FBFF  FB000000 do FBFFFFFF  brak  
Zastrzeżony zakres do wyko ­
rzystania w przysz łości FC do FD  FC00 do FDFF  FC000000 do FDFFFFFF  brak  
Wskaźnik błędu FE  FE00 do FEFF  FE000000 do FEFFFFFF  0  
Niedostępne lub nie żądane  FF  FF00 do FFFF  FF000000 do FFFFFFFF  FF  
CPR_073 Dla parametrów kodowanych w ASCII znak ASCII „*” jest 
zastrzeżony jako ogranicznik.  
8.2. Formaty dataRecords  
W tabelach od 39 do 42 poni żej opisano szczegó łowo formaty 
używane przez us ługi ReadDataByIdentifier i WriteDataByIdentifier.  
CPR_074 W tabeli 39 podano d ługość, rozdzielczo ść i zakres roboczy 
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  
HighResolutionTotalVehicle ­
Distance  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  15  ASCII  ASCII  
NextCalibrationDate  3  Zob. szczegó łowy opis w tabeli 41  
SpeedAuthorised  2  wzmocnienie 1/256 km/h/bit, 
offset 0  0 do 250,996 km/h  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 329  
Nazwa parametru  Długość danych 
(w bajtach)  Rozdzielczo ść Zakres roboczy  
RegisteringMemberState  3  ASCII  ASCII  
VehicleRegistrationNumber  14  Zob. szczegó łowy opis w tabeli 42  
VIN 17  ASCII  ASCII  
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 para ­
metru  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 dzie ń/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 przesu ­
nięcie dla 
minut  wzmocnienie 1 minuta/bit, 
offset – 125 minut  – 59 do + 59 
minut  
8 lokalne przesu ­
nię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 para ­
metru  Rozdzielczo ść Zakres roboczy  
1 Miesi ąc wzmocnienie 1 miesi ąc/bit, 
offset 0 miesi ęcy 1 do 12 
miesięcy 
2 Dzie ń 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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 330  
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.  
CPR_078 W tabeli 42 zamieszczono szczegó łowy opis formatów 
poszczególnych bajtów parametru VehicleRegistrationNum ­
ber. 
Tabela 42  
Szczegółowy opis formatu VehicleRegistrationNumber (warto ść 
recordDataIdentifier # F97E)  
Bajt Definicja parametru  Rozdzielczo ść Zakres roboczy  
1 Strona kodowa (zdefiniowana 
w dodatku 1)  ASCII  01 do 0A  
2 – 14  Numer rejestracyjny pojazdu 
(zdefiniowany w dodatku 1)  ASCII  ASCII  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 331  
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 
1. WPROWADZENIE  
1.1. Homologacja typu  
Homologacja typu WE urz ądzenia rejestruj ącego (lub elementu sk ładowego) 
lub karty do tachografu opiera si ę na następujących dokumentach:  
▼M1 
— świadectwie bezpiecze ństwa , opartym na specyfikacjach normy 
„Common Criteria”, w odniesieniu do celu bezpiecze ństwa w pe łni 
zgodnego z celami przedstawionymi w dodatku 10 do niniejszego 
załącznika,  
▼B 
— świadectwie funkcjonalno ści wystawionym przez organ pa ństwa człon­
kowskiego i za świadczającym, że badany element spe łnia wymogi okre ­ 
ś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 tachografu) 
jest w pełni interoperacyjne z wymaganymi typami kart do tachografu 
(lub urządzenia rejestruj ącego) (zob. rozdzia ł 8 niniejszego za łącznika).  
W niniejszym dodatku okre śla się, które badania, jako minimum, musi 
przeprowadzi ć organ państwa członkowskiego w ramach bada ń funkcjonal ­
ności, i które badania, jako minimum, musi przeprowadzi ć właściwy organ 
w ramach bada ń interoperacyjno ści. Nie okre śla się dokładnie procedur 
przeprowadzania tych bada ń ani ich rodzajów.  
Niniejszy dodatek nie obejmuje aspektów świadectwa bezpiecze ństwa. Jeżeli 
niektóre badania wymagane na potrzeby homologacji typu przeprowadza si ę 
przy ocenie bezpiecze ństwa i w ramach procesu certyfikacji, to nie trzeba 
ich przeprowadza ć ponownie. W takim przypadku mo żna poddać kontroli 
tylko wyniki takich bada ń bezpiecze ństwa. Do celów informacyjnych 
wymogi, które maj ą zostać poddane badaniom (lub ściśle wiążą się z bada­
niami, które maj ą zostać przeprowadzone) w ramach certyfikacji bezpie ­
czeń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).  
W niniejszym dodatku oddzielnie przedstawiono informacje na temat homo ­
logacji typu czujnika ruchu, przyrz ądu rejestruj ącego oraz urz ądzenia 
zewnętrznego GNSS jako elementów sk ładowych urz ądzenia rejestruj ącego. 
Każdy element sk ładowy uzyska oddzielne świadectwo homologacji typu, 
w którym wskazane zostan ą pozostałe kompatybilne elementy sk ładowe.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 332  
Badanie funkcjonalno ści czujnika ruchu (lub urz ądzenia zewn ętrznego 
GNSS) wykonuje si ę wraz z badaniem funkcjonalno ści przyrządu rejestru ­
jącego i odwrotnie.  
Nie wymaga si ę zapewnienia interoperacyjno ści między każdym modelem 
czujnika ruchu (lub urz ądzenia zewn ętrznego GNSS) i ka żdym modelem 
przyrządu rejestruj ącego. W takim przypadku homologacja typu czujnika 
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.  
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óba N: 
Zmiany temperatury  
IEC 60068-2-27: Badania środowiskowe – Cz ęść 2: Próby – Próba Ea 
i wytyczne: Udary  
IEC 60068-2-30: Badania środowiskowe – Cz ęść 2-30: Próby – Próba Db: 
Wilgotne gor ąco, cykliczne (cykl 12+12 h)  
IEC 60068-2-64: Badania środowiskowe – Cz ęść 2-64: Próby – Próba Fh: 
Wibracje szerokopasmowe losowe i wytyczne  
IEC 60068-2-78: Badania środowiskowe – Cz ęść 2-78: Próby – Próba 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 Pojazdy 
drogowe – Metody bada ń zakłóceń elektrycznych powodowanych przez 
wyładowania elektrostatyczne  
ISO 7637-1:2002 + AMD1:2008 Pojazdy drogowe – Zak łócenia elektryczne 
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 przebiegó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 elektrycznych 
przebiegów przej ściowych przez sprz ężenia pojemno ściowe i indukcyjne 
przez linie inne ni ż linie zasilaj ące 
ISO/IEC 7816-1 Karty identyfikacyjne – Karty elektroniczne – Cz ęść 1: 
Karty stykowe – Charakterystyki fizyczne  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 333  
ISO/IEC 7816-2 Technologia informacyjna – Karty identyfikacyjne – Karty 
elektroniczne – Cz ęść 2: Karty stykowe – Wymiary i rozmieszczenie styków  
ISO/IEC 7816-3 Technologia informacyjna – Karty identyfikacyjne – Karty 
elektroniczne – Cz ęść 3: Karty Stykowe – Sygna ły elektryczne 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 identyfika ­
cyjne – Metody bada ń – Część 3: Karty elektroniczne i powi ązane z nimi 
urządzenia interfejsowe  
ISO 16844-3:2004, Sprostowanie 1: 2006 Pojazdy drogowe – Systemy 
tachograficzne – Cz ęść 3: Interfejs czujnika ruchu (z przyrz ądami rejestru ­
jącymi)  
ISO 16844-4 Pojazdy drogowe – Systemy tachograficzne – Cz ęść 4: Inter­
fejs CAN  
ISO 16844-6 Pojazdy drogowe – Systemy tachograficzne – Cz ęść 6: Diag­
nostyka  
ISO 16844-7 Pojazdy drogowe – Systemy tachograficzne – Cz ęść 7: Para­
metry  
ISO 534 Papier i tektura – Oznaczanie grubo ści, gęstości pozornej i obj ętości 
właściwej  
EKG ONZ R10 Jednolite przepisy dotycz ące homologacji pojazdów 
w odniesieniu do kompatybilno ści elektromagnetycznej (Europejska 
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 
3.1 Obsługiwane funkcje  02, 03, 04, 05, 07, 382  
3.2 Tryby pracy  09–11*, 134, 135  
3.3 Prawa dost ępu do funkcji i danych  12* 13*, 382, 383, 386–389  
3.4 Monitorowanie wk ładania i wyjmowania kart  15, 16, 17, 18, 19*, 20*, 134  
3.5 Pomiar pr ędkości i odległości 21–31  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 334  
Nr Badanie  Opis  Powi ązane wymogi  
3.6 Pomiar czasu (badanie przeprowadzone w temperaturze 20 °C)  38–43  
3.7 Monitorowanie czynno ści kierowcy  44–53, 134  
3.8 Monitorowanie stanu prowadzenia pojazdu  54, 55, 134  
3.9 Pozycje wprowadzane r ęcznie  56–62  
3.10 Zarządzanie blokadami firmowymi  63–68  
3.11 Monitorowanie czynno ści kontrolnych  69, 70  
3.12 Wykrywanie zdarze ń lub usterek  71–88, 134  
3.13 Dane identyfikuj ące urządzenie  93*, 94*, 97, 100  
3.14 Dane dotycz ące wkładania i wyjmowania karty kierowcy  102*–104*  
3.15 Dane dotycz ące czynności kierowcy  105*–107*  
3.16 Dane dotycz ące miejsc i po łożenia 108*–112*  
3.17 Dane dotycz ące licznika kilometrów  113*–115*  
3.18 Szczegó łowe dane 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*–121*  
3.22 Dane dotycz ące korekty czasu  124*, 125*  
3.23 Dane dotycz ące czynności kontrolnej  126*, 127*  
3.24 Dane dotycz ące blokad firmowych  128*  
3.25 Dane dotycz ące czynności pobierania  129*  
3.26 Dane dotycz ące warunków szczególnych  130*, 131*  
3.27 Rejestrowanie i przechowywanie danych na kartach do tachografu  136, 137, 138*, 139*, 141*, 
142, 143 
144, 145, 146*, 147*, 148*, 
149, 150  
3.28 Wyświetlanie  90, 134, 
151–168 
PIC_001, DIS_001  
3.29 Drukowanie  90, 134, 
169–181, PIC_001, PRT_001– 
PRT_014  
3.30 Ostrzeganie  134, 182–191, 
PIC_001  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 335  
Nr Badanie  Opis  Powi ązane wymogi  
3.31 Pobieranie danych na no śnik zewnętrzny  90, 134, 192–196  
3.32 Łączność na odległość na potrzeby ukierunkowanych kontroli drogo ­
wych  197–199  
3.33 Wyprowadzanie danych do dodatkowych urz ądzeń zewnętrznych  200, 201  
3.34 Kalibracja  202–206*, 383, 384, 386–391  
3.35 Drogowe kontrole kalibracji  207–209  
3.36 Korekta czasu  210–212*  
3.37 Niezakłócanie funkcji dodatkowych  06, 425  
3.38 Interfejs czujnika ruchu  02, 122  
3.39 Urządzenie zewn ętrzne GNSS  03, 123  
3.40 Sprawdzenie, czy VU wykrywa, rejestruje i zapisuje zdarzenie (zdarze ­
nia) lub usterk ę (usterki) okre ślone przez producenta VU, gdy sparo ­
wany czujnik ruchu reaguje na pola magnetyczne zaburzaj ące wykry­
wanie ruchu pojazdu.  217 
3.41 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 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 tempe ­
raturowych.  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 ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 336  
Nr Badanie  Opis  Powi ązane wymogi  
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. 
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 tempe ­
raturowy -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.  219 
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 
nadnapię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 ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 337  
Nr Badanie  Opis  Powi ązane wymogi  
4.6 Zabezpieczenie przed 
odwróceniem polaryza ­
cji 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 radia­
cję 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 
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 ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 338  
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*  
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  02  
3.5 Sprawdzenie, czy dzia łanie stałego pola magnetycznego nie wp ływa na czujnik 
ruchu. Ewentualnie sprawdzenie, czy czujnik ruchu reaguje na dzia łanie stałych 
pól magnetycznych zaburzaj ących wykrywanie ruchu pojazdu, tak aby 
podłączony VU móg ł wykrywać, rejestrowa ć i zapisywa ć usterki czujnika.  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 temperaturze 
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 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 339  
Nr Badanie  Opis  Powi ązane wymogi  
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 tempera ­
tury 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 
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 uzgodnie ­
nia, ale < 1 ms, liczba wstrz ąsów: do uzgodnie ­
nia. 
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 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 340  
Nr Badanie  Opis  Powi ązane wymogi  
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 
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 certyfiku ­
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 kombinacji 
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 — 26.02.2020 — 002.001 — 341  
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 — 26.02.2020 — 002.001 — 342  
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 wymogami 
normy 
ISO/IEC 7810: Karty identyfikacyjne – Charaktery ­
styki 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 — 26.02.2020 — 002.001 — 343  
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 — 26.02.2020 — 002.001 — 344  
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 środowis- 
kowe 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 — 26.02.2020 — 002.001 — 345  
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 — 26.02.2020 — 002.001 — 346  
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 — 26.02.2020 — 002.001 — 347  
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 środowis- 
kowe 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 środowis- 
kowe 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 — 26.02.2020 — 002.001 — 348  
Nr Badanie  Opis  Powi ązane wymogi  
[Elektryczno ść statyczna] 
Załącznik 1C rozdzia ł 4.4 „Wymagania środowis- 
kowe 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 — 26.02.2020 — 002.001 — 349  
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 przetwarza ­
nie 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 — 26.02.2020 — 002.001 — 350  
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 polece ­
nia. 
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 rejestruj ącym 123, 205  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 351  
Nr Badanie  Opis  Powi ązane wymogi  
3.3 Położenie GNSS  36, 37  
3.4 Interfejs przyrz ądu rejestruj ącego, gdy odbiornik GNSS znajduje 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: 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 tempe ­
raturowych.  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 — 26.02.2020 — 002.001 — 352  
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 polaryzacji  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 — 26.02.2020 — 002.001 — 353  
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 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 
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ól ­
nego 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 drogowych  4, 197–199  
3.2 Rejestrowanie i przechowywanie w pami ęci danych  91  
3.3 Łączność z przyrządem rejestruj ącym Dodatek 14 pozycje 
DSC_66–DSC_70, 
DSC_71–DSC_76  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 354  
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 (war­
tość 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 — 26.02.2020 — 002.001 — 355  
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 ęcz­
ne. 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 — 26.02.2020 — 002.001 — 356  
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 tempera ­
turze + 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 wilgotno ś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 — 26.02.2020 — 002.001 — 357  
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 ącymi 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 rejestruj ą­
cym. Scenariusz dostosowany jest do typu badanej karty i obejmuje 
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 ącymi a czujnikami ruchu  
1 Parowanie  Sprawdzenie, czy parowanie przyrz ądu rejestruj ącego z czujnikami 
ruchu przebiega normalnie.  
2 Badania czynno ści Wykonanie scenariusza typowej czynno ści na czujniku ruchu. Scena ­
riusz 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 ącymi 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 przebiega 
normalnie.  
2 Badania czynno ści Wykonanie scenariusza typowej czynno ści na zewn ętrznym urz ą­
dzeniu GNSS. Scenariusz obejmuje normaln ą czynność i wygenero ­
wanie 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 — 26.02.2020 — 002.001 — 358  
Dodatek 10  
WYMOGI BEZPIECZE ŃSTWA  
W niniejszym dodatku okre ślono wymogi bezpiecze ństwa informatycznego doty ­
czące elementów sk ładowych systemu tachografu inteligentnego (tachografu 
drugiej generacji).  
SEC_001 Nast ępujące elementy sk ładowe systemu tachografu inteligentnego 
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 ę 
bezpieczeństwa, okre śla się w profilu zabezpieczenia dla elementu 
składowego, zgodnie z systemem wspólnych kryteriów.  
SEC_003 Komisja Europejska upewnia si ę, że cztery profile zabezpieczenia 
zgodne z niniejszym za łącznikiem s ą finansowane, opracowywane, 
zatwierdzane przez rz ądowe jednostki certyfikuj ące ds. bezpiecze ń­
stwa informatycznego, skupione w grupie roboczej ds. wspólnej inter ­
pretacji (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 przypadki, gdy 
przyrząd rejestruj ący jest przeznaczony do u żytkowania z urz ądzeniem 
zewnętrznym GNSS, jak i gdy nie jest do tego przeznaczony. W tym pierwszym 
przypadku wymogi bezpiecze ństwa dotycz ące urządzenia zewn ętrznego 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, produ ­
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 proce ­
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 procesie 
oceny.  
SEC_006 Poziomem gwarancji dla ka żdego profilu zabezpieczenia jest poziom 
EAL4 wzmocniony elementami gwarancji ATE_DPT.2 i AVA_VAN.5.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 359  
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 danych  
6. MECHANIZMY CYFROWEGO PODPISU DLA POBIERANIA 
DANYCH  
6.1. Generowanie podpisu  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 360  
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 publicznych  
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 — 26.02.2020 — 002.001 — 361  
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 ętrznym 
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 generacji 
kluczy  
12.3. Parowanie VU z czujnikiem ruchu i łączność między tymi urz ą­ 
dzeniami z wykorzystaniem AES  
12.4. Parowanie VU z czujnikiem ruchu w przypadku ró żnych generacji 
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 — 26.02.2020 — 002.001 — 362  
INFORMACJE OGÓLNE  
W niniejszym dodatku okre śla się mechanizmy zabezpieczenia zapewniaj ące: 
— wzajemne uwierzytelnienie mi ędzy różnymi elementami sk ładowymi systemu 
tachografu;  
— poufno ść, integralno ść, autentyczno ść lub niezaprzeczalno ść danych przeka ­
zywanych mi ędzy różnymi elementami sk ładowymi systemu tachografu 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 generacji (tachograf 
cyfrowy). W cz ęści B opisano mechanizmy zabezpieczenia stosowane 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 ądzeniem 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 ładowymi 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 
kryptograficzny . 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 pierw ­
sze: 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 — 26.02.2020 — 002.001 — 363  
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 — 26.02.2020 — 002.001 — 364  
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ą klasycz­
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 śni­
ków.  
CSM_002 Przyrz ądy rejestruj ące i karty do tachografu u żywają symet­
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 — 26.02.2020 — 002.001 — 365  
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 obli ­
czeń 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 pozio ­
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 realizu ­
jącym te zadania jest organ certyfikacji pa ństwa członkow­
skiego. 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 przechowy ­
wania nale ży zachowa ć poufność kluczy prywatnych.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 366  
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 intero ­
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 testo ­
wych 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 DES 
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 — 26.02.2020 — 002.001 — 367  
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 rejes­
trujących z zachowaniem nale żytych procedur bezpie ­
czeństwa w celu umieszczenia w przyrz ądach rejestruj ą­
cych,  
— zapewniaj ą umieszczenie klucza Km  WC we 
wszystkich kartach warsztatowych
  
w pliku elemen ­
tarnym
  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 „niesa ­
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ące 
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 — 26.02.2020 — 002.001 — 368  
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 identyfikacj ę 
organu certyfikacji wydaj ącego certyfikat, w taki sposób, że ten 
element danych mo że być użyty jednocze śnie jako identyfikator 
klucza organu w celu odniesienia do klucza publicznego organu certy ­
fikacji (kodowanie — patrz Identyfikator klucza poni żej). 
3. „Upowa żnienie posiadacza certyfikatu” (CHA) s łuży do identyfiko ­
wania praw posiadacza certyfikatu. Sk łada się ono z ID aplikacji 
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 — 26.02.2020 — 002.001 — 369  
4. „Odniesienie do posiadacza certyfikatu” (CHR) ma na celu jedno ­
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 klucza 
publicznego.  
5. Identyfikatory kluczy jednoznacznie identyfikuj ą posiadacza certyfi ­
katu lub organy certyfikacji. S ą one kodowane w nast ępujący sposó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, iden ­
tyfikację urządzenia). Identyfikator klucza ma nast ępującą postać: 
Dane  Numer 
seryjny 
wniosku 
o certyfi­
kat 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 — 26.02.2020 — 002.001 — 370  
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 ż certyfikowany 
klucz publiczny jest kluczem RSA w łaściwym do uwierzytelnienia, 
weryfikacji podpisu cyfrowego i szyfrowania dla poufnych us ług (cer­
tyfikat nie zawiera identyfikatora obiektu, który by to okre ś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 organ 
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 — 26.02.2020 — 002.001 — 371  
3.3.3  Weryfikacja i rozpakowanie certyfikatu  
Weryfikacja i rozpakowanie certyfikatu obejmuje sprawdzenie podpisu 
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 certy­
fikatu.  
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 europejski 
organ certyfikacji.  
Wykazanie polega na podpisaniu kluczem prywatnym losowej liczby 
przysłanej przez drug ą stronę, która musi odzyska ć tę liczbę przy 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 — 26.02.2020 — 002.001 — 372  
CSM_020 W procesie tym stosuje si ę następujący protokó ł (strzałki 
oznaczają polecenia i wymian ę danych (zob. dodatek 2)):
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 373
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 374  
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 kryptogra ­
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ę kontro­
lną) 
‘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 — 26.02.2020 — 002.001 — 375  
Dla danej pary niezabezpieczone polecenie – odpowied ź: 
Nagłówek polecenia  Tre ść polecenia  
CLA  INS  P1  P2  [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  P1  P2  [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’  CC  
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’  CC  
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 — 26.02.2020 — 002.001 — 376  
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’  CC  
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’  CC  
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 interpre ­
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 ą 
jednokierunkowej 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)),  
gdzie E() oznacza szyfrowanie z DES, a D() oznacza deszyf ­
rowanie z DES.  
Cztery najbardziej znacz ące bajty kryptograficznej sumy 
kontrolnej s ą przesyłane. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 377  
CSM_029 Licznik sekwencji wysy łania (SSC) jest inicjowany podczas 
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 — 26.02.2020 — 002.001 — 378  
6. MECHANIZMY CYFROWEGO PODPISU DLA POBIERANIA 
DANYCH  
CSM_032 Inteligentne urz ądzenie dedykowane (IDE) przechowuje dane 
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(Da ­
ta))] 
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 — 26.02.2020 — 002.001 — 379
  
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 elektro ­
niczne – Cz ęść 4: Organizacja, zabezpieczenia i polecenia 
wymiany. Wydanie trzecie 2013-04-15  
ISO 7816-8 ISO/IEC 7816-8, Karty identyfikacyjne – Karty elektro ­
niczne – Cz ęść 8: Polecenia operacji zabezpieczaj ących. 
Wydanie drugie, 2004-06-01  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 380  
ISO 8825-1 ISO/IEC 8825-1 Technologia informacyjna – Regu ły 
kodowania ASN.1: Specyfikacja podstawowych regu ł 
kodowania (BER), kanonicznych regu ł kodowania 
(CER) i wyró żnionych 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 tachograficzne 
– 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 – Informacje 
na temat klucza publicznego podmiotu, marzec 2009 r.  
RFC 5639 Kryptografia oparta na krzywej eliptycznej (ECC) – Stan ­
dardowe krzywe Brainpool i generowanie krzywych, 
2010 r.  
RFC 5869 Funkcja wyprowadzania klucza przez wyodr ębnianie 
i rozwijanie oparta na algorytmie HMAC (HKDF), maj 
2010 r.  
SHS Narodowy Instytut Standaryzacji 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 — 26.02.2020 — 002.001 — 381  
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 — 26.02.2020 — 002.001 — 382  
— 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 śni­
kó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ą symetrycz ­
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 — 26.02.2020 — 002.001 — 383  
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 ruchu 
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 — 26.02.2020 — 002.001 — 384  
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  12  
CS#3  512/521  256  SHA-512  16  
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 przyrz ą­
dami rejestruj ącymi a kartami do tachografu oraz mi ędzy przyrz ądami 
rejestrującymi a urz ądzenia zewn ętrznymi GNSS. Procesy te opisano 
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 — 26.02.2020 — 002.001 — 385  
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 
podpisania g łównego certyfikatu (z podpisem w łasnym) 
europejskiego klucza publicznego i przekazuje ten euro ­
pejski certyfikat g łówny wszystkim pa ństwom członkow­
skim.  
CSM_55 ERCA u żywa europejskiego klucza prywatnego do 
podpisywania 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 kryptograficz ­
nej, 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 — 26.02.2020 — 002.001 — 386  
CSM_60 W ka żdym momencie ERCA dysponuje nast ępującymi 
kluczami i certyfikatami kryptograficznymi:  
— bieżąca para kluczy europejskich i powi ązany certyfi ­
kat; 
— 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ętrznych GNSS dodatkowo generuj ą co najmniej 
jedną unikatow ą 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 publicz ­
nego 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 — 26.02.2020 — 002.001 — 387  
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 certy ­
fikatem;  
— 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 — 26.02.2020 — 002.001 — 388  
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 ąza­
nego 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 — 26.02.2020 — 002.001 — 389  
— 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 gene ­
racji.  
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 — 26.02.2020 — 002.001 — 390  
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 rejestruj ących, 
których normalny okres u żyteczności wynosz ą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 — 26.02.2020 — 002.001 — 391  
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 — 26.02.2020 — 002.001 — 392  
— 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 wykorzy ­
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 — 26.02.2020 — 002.001 — 393  
Uwagi do rys. 1  
1. poszczególne generacje certyfikatów g łównych oznaczono cyfr ą 
w nawiasie. Na przyk ład ERCA (1) oznacza pierwsz ą generację certy­
fikatu głównego ERCA, ERCA (2) – drug ą generację itd.;  
2. pozosta łe certyfikaty s ą oznaczone dwiema cyframi w nawiasach: 
pierwsza z nich wskazuje generacj ę certyfikatu g łównego, w której 
wydano dany certyfikat, natomiast druga okre śla generacj ę samego 
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 uwierzy ­
telnienia wydany na podstawie ERCA (2) itp.;  
3. certyfikaty MSCA_Card (2-1) i MSCA_Card (1-ostatni) wydaje si ę 
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 certyfikat 
MSCA_Card wydany na podstawie ERCA (1);  
4. zgodnie z informacjami przedstawionymi na rysunku pierwsze certy ­
fikaty VU i certyfikaty karty wydane na podstawie ERCA (2) pojawi ą 
się niemal dwa lata przed ostatnimi certyfikatami VU i certyfikatami 
karty wydanymi na podstawie ERCA (1). Wynika to z faktu, że 
certyfikaty VU i certyfikaty karty wydaje si ę na podstawie certyfikatu 
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) zostanie 
wydany tylko nieznacznie pó źniej, tj. w ostatnim dniu, w którym 
certyfikat ERCA (1) jest nadal wa żny. Z tego wzgl ędu obydwa certy ­
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 certyfikató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 tre ścią 
normy [ISO 16844-3], w której opisano interfejs pomi ędzy przyrz ądem 
rejestrującym a czujnikiem ruchu. Proces parowania VU i czujnika 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 — 26.02.2020 — 002.001 — 394  
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 — 26.02.2020 — 002.001 — 395  
— Jak wyja śniono w sekcji 9.2.1.2, w praktyce w niektó ­
rych przypadkach mo że zachodzi ć konieczno ść 
umieszczenia 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 gene ­
racji.  
— 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 
zawierał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 — 26.02.2020 — 002.001 — 396  
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 — 26.02.2020 — 002.001 — 397  
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 — 26.02.2020 — 002.001 — 398  
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 — 26.02.2020 — 002.001 — 399  
CSM_120 Klucz g łówny DSRC KM  DSRC  stanowi klucz AES, który 
jest bezpiecznie generowany, przechowywany 
i rozpowszechniany 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 — 26.02.2020 — 002.001 — 400  
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.  
▼B 
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 — 26.02.2020 — 002.001 — 401  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 402  
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 certyfi ­
kacie 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.  Przedsta­
wiono 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 specy ­
ficzne dla VU, oparte na przedmiotowym kluczu g łów­
nym.  
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 
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.  
9.3.2  Treść certyfikatu  
CSM_136 Wszystkie certyfikaty maj ą strukturę przedstawion ą w profilu 
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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 403  
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  PK  ‘7F 49’  var  
Parametry domeny  DP  ‘06’  var
  
Punkt publiczny  PP  ‘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 łas­
nym, tj. odniesienie do organu certyfikacji pokrywa si ę 
z odniesieniem do posiadacza certyfikatu w certyfikacie.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 404  
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 parametry 
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 publiczny. 
Punkty publiczne krzywej eliptycznej przekszta łca się 
w ciągi oktetowe, jak okre ślono w [TR-03111]. Stosuje si ę 
nieskompresowany format kodowania. Podczas odzyski ­
wania punktu krzywej eliptycznej z jej zakodowanego 
formatu zawsze przeprowadza 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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 405  
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 
posiadacza 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ę zakoń­
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 wnio ­
sek; 
— 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 — 26.02.2020 — 002.001 — 406  
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 certyfikat zwrócony przez MSCA zosta ł umiesz­
czony w przewidzianym urz ądzeniu.  
▼B 
CSM_154 W przypadku VU producent, sk ładając wniosek o certyfikat, 
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 certyfi ­
kat. 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 ć 
podpisany przez G łówny Europejski Organ Certyfikacji. 
Etap ten nazywany jest weryfikacj ą łańcucha certyfi ­
kató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 nume ­
rze. Jeżeli weryfikacja zako ńczy się powodzeniem, VU 
zostaje uwierzytelniony. Etap ten nazywany jest uwie ­
rzytelnieniem VU i zosta ł szczegółowo opisany w sekcji 
10.3; ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 407  
— 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 — 26.02.2020 — 002.001 — 408  
— 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 auten ­
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 — 26.02.2020 — 002.001 — 409  
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 przyrz ąd 
rejestrujący karta weryfikuje prawid łowość pola Upowa ż­
nienie Posiadacza Certyfikatu (CHA):  
— CHA certyfikatu VU.Link musi wskazywa ć ERCA.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 410  
— 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 ą certyfika­
tami i kluczami, których u żywa się do wzajemnego uwierzytelnienia. 
W sekcji 9.1.4 oznaczono je jako VU_MA;  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 411  
— certyfikaty i klucze publiczne VU.CA wskazane na rysunku s ą certy­
fikatami i kluczami u żywanymi do podpisywania 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 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 — 26.02.2020 — 002.001 — 412  
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 efemerycz ­
nego 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 ustawia 
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 — 26.02.2020 — 002.001 — 413  
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 uwierzytel ­
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 — 26.02.2020 — 002.001 — 414  
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 uwierzy ­
telniania.  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 415  
10.4.  Uwierzytelnianie chipu i uzgadnianie klucza sesji  
CSM_175 Przyrz ądy rejestruj ące i karty korzystaj ą z protoko łu uwie­
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 prze ­
kształca się w ciąg oktetowy, jak okre ślono w [TR- 
03111]. Stosuje si ę nieskompresowany format kodowa ­
nia. Jak wyja śniono w CSM_164, VU wygenerowa ł tę 
parę kluczy efemerycznych przed zweryfikowaniem 
łańcucha certyfikatów VU. VU przes łał karcie identyfi ­
kator efemerycznego klucza publicznego 
Comp(VU.PK  eph ) i karta zapisuje ten identyfikator;  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 416  
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 — 26.02.2020 — 002.001 — 417  
CSM_180 W powy ższych krokach 6 i 9 karta i przyrz ąd rejestrujący 
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 pliku 
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 zaszyfrowa ­
niu, 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 ę liczbę 
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 — 26.02.2020 — 002.001 — 418  
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 — 26.02.2020 — 002.001 — 419  
— 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 odpowia ­
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 7816-4].  
Odpowiedź APDU z zastosowaniem bezpiecznej wymiany komunikatów 
będzie miała następującą strukturę w zależności od przypadku odpowia ­
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 — 26.02.2020 — 002.001 — 420  
Poniżej przedstawiono trzy przyk łady przekszta łceń APDU w odniesieniu 
do poleceń z parzystym kodem INS. Rys. 8 przedstawia uwierzytelnione 
polecenie APDU okre ślone w przypadku 4, rys. 9 przedstawia uwierzy ­
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 — 26.02.2020 — 002.001 — 421  
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ę bezpiecznej 
wymiany komunikatów tylko i wy łącznie wówczas, gdy 
zaistnieje 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 
odpowiedzi w ramach bezpiecznej wymiany komuni ­
katów wynosi 240 w ka żdej sesji.  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 422  
CSM_193 Karta do tachografu przerywa trwaj ącą sesję bezpiecznej 
wymiany komunikatów tylko i wy łącznie wówczas, gdy 
zaistnieje 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 tacho ­
grafu 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 zastoso ­
wania 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 ę 
ponownie 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 — 26.02.2020 — 002.001 — 423  
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 urządzeniem zewn ętrznym GNSS odbywa si ę na takiej 
samej zasadzie jak bezpieczna łączność między przyrz ądem 
rejestrują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ń przedstawionych w tym rozdziale. W szczególno ści 
procesy wzajemnej weryfikacji łańcucha certyfikatów, uwie ­
rzytelniania 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 doko­
nywać 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 — 26.02.2020 — 002.001 — 424  
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 ąza­
nia, 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 odpo ­
wiedzi 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 euro ­
pejskiego 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 — 26.02.2020 — 002.001 — 425  
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 certyfi ­
kató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 
wzajemnego 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 
podpisywania certyfikatów VU i urz ądzenia zewn ętrz­
nego 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 certyfi ­
katem łączącym VU, 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 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 — 26.02.2020 — 002.001 — 426  
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 rejestruje 
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 uzgodnienie 
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 komu ­
nikatów mi ędzy VU a EGF przyrz ąd rejestruj ący natych­
miast ustanawia now ą sesję bezpiecznej wymiany komuni ­
kató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 ślo­
nego 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 — 26.02.2020 — 002.001 — 427  
Uwaga:  zakłada się, że czytelnicy tego rozdzia łu są zazna­
jomieni 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 wszystkie 
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 czujnikach 
ruchu może występować do trzech ró żnych rodzajów szyfrowania danych 
opartych na AES (na podstawie kolejnych generacji klucza g łównego 
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 przekazuje z powrotem pasuj ącą zaszyfrowan ą wersję 
klucza parowania; tj. zaszyfrowany numer stworzony 
przy zastosowaniu 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 parowa ­
niu. 
8. Czujnik ruchu szyfruje otrzymane informacje o parowaniu 
za pomocą otrzymanego klucza K  S i przesyła te infor­
macje z powrotem do VU. VU sprawdza, czy informacje 
o parowaniu s ą tymi samymi informacjami, które VU 
wysłał do czujnika ruchu w poprzednim kroku.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 428  
Jeżeli tak, oznacza to, że czujnik ruchu u żył tego samego 
klucza K  S co VU i zgodnie z krokiem 5 wys łał swój 
klucz parowania zaszyfrowany za pomoc ą klucza K  M 
prawidłowej generacji. Czujnik ruchu jest zatem uwierzy ­
telniony.  
Należy zauważyć, że kroki 2 i 5 ró żnią się od standardo ­
wego 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 czuj ­
nika 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 mog ą 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 — 26.02.2020 — 002.001 — 429  
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 uczestni ­
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 komuni ­
katu musi stanowi ć wielokrotno ść 16 bajtów, w porównaniu 
z 8 bajtami w przypadku TDES. Ponadto niektóre takie 
komunikaty 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  16  16  16  
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  16  16  16  
41 odpowied ź Klucz parowania  16  16 / 24 / 32  16  32  32  
42 żądanie  Klucz sesji  16  16 / 24 / 32  16  32  32  
43 żądanie  Informacje o parowa ­
niu 24 24  32  32  32  
50 odpowied ź Informacje o parowa ­
niu 24 24  32  32  32  
70 żądanie  Dane uwierzytelnia ­
nia 8 8  16  16  16  
80 odpowied ź Wartość licznika 
czujnika ruchu + 
dane uwierzytelniania  8 8  16  16  16  
▼B 
CSM_219 Informacje o parowaniu wysy łane w instrukcjach 43 
(żądanie VU) i 50 (odpowied ź czujnika ruchu) s ą groma­
dzone zgodnie z wymogami okre ślonymi w sekcji 7.6.10 
normy [ISO 16844-3], z tym że zamiast algorytmu TDES 
należy stosowa ć algorytm AES w systemie szyfrowania 
danych dotycz ących parowania, 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 — 26.02.2020 — 002.001 — 430  
— 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 kluczy 
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 gene ­
racji może zawierać zaszyfrowane w oparciu o TDES dane 
dotyczące parowania (zgodnie z cz ęścią A niniejszego dodat ­
ku), co umo żliwia parowanie tego czujnika ruchu z VU 
pierwszej generacji. W takim przypadku proces parowania 
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 warsztatowej 
pierwszej lub drugiej generacji.  
Uwagi  
— Nie jest mo żliwe sparowanie VU drugiej generacji z czuj ­
nikiem ruchu pierwszej generacji.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 431  
— 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łączenie:  
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 okre ślono 
w dodatku 1 i szczegó łowo opisano w dodatku 14. W tej sekcji opisano 
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 poni ż­
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 wszyst ­
kich wcześniejszych bajtów w danych doty ­
czą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 
rozpoczę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 — 26.02.2020 — 002.001 — 432  
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 specyficz ­
nych 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 — 26.02.2020 — 002.001 — 433  
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 tacho ­
grafu, 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 inter ­
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 zdal­
nego 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 dane 
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 — 26.02.2020 — 002.001 — 434  
— 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 
przedstawionego 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 — 26.02.2020 — 002.001 — 435  
— 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 
podpisywania w stosownych przypadkach certyfikatów 
VU lub kart;  
— certyfikat EQT.CA.EUR wskazany na rysunku jest euro ­
pejskim certyfikatem g łównym wskazanym w CAR 
certyfikatu 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 
europejskich kluczy g łównych wygenerowanej przez 
ERCA i podpisanej za pomoc ą poprzedniego europej ­
skiego 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 — 26.02.2020 — 002.001 — 436  
Rysunek 13  
Protokół weryfikacji podpisu z łożonego w odniesieniu do pobranego pliku danych
  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 437  
Dodatek 12  
OKREŚLANIE PO ŁOŻENIA Z WYKORZYSTANIEM GLOBALNEGO 
SYSTEMU NAWIGACJI SATELITARNEJ (GNSS)  
SPIS TRE ŚCI 
1. WPROWADZENIE  
1.1. Zakres stosowania  
1.2. Akronimy i skróty  
2. SPECYFIKACJA ODBIORNIKA GNSS  
3. KOMUNIKATY NMEA  
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 produkcji  
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  
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 ętrznego 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  
5.2. Obs ługa błędów 
5.2.1 Brak informacji o po łożeniu z odbiornika GNSS  
6. KONFLIKT CZASOWY GNSS  
7. KONFLIKT RUCHU POJAZDU  
1. WPROWADZENIE  
Niniejszy dodatek zawiera wymogi techniczne dotycz ące danych GNSS 
wykorzystywanych przez przyrz ąd rejestrujący, z uwzgl ędnieniem proto ­
kołów, które nale ży wdrożyć w celu zapewnienia bezpiecznego i prawid ­ 
łowego przesy łania danych z informacjami o po łożeniu.  
Głównymi artyku łami w niniejszym rozporz ądzeniu (UE) nr 165/2014, 
na których opieraj ą się te wymogi, s ą: „Artykuł 8 Zapisywanie po łożenia 
pojazdu w pewnych punktach podczas dziennego okresu pracy”, 
„Artykuł 10 Interfejs do inteligentnych systemów transportowych” oraz 
„Artykuł 11 Szczegó łowe przepisy dotycz ące inteligentnych tachogra ­
fów”.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 438  
1.1. Zakres stosowania  
GNS_1 Przyrz ąd rejestrujący musi gromadzi ć dane dotycz ące lokalizacji 
z co najmniej jednego GNSS w celu wsparcia wdro żenia prze­
pisów art. 8.  
Przyrząd rejestruj ący może posiadać urządzenie zewn ętrzne GNSS lub 
nie, jak przedstawiono na rys. 1:  
Rys. 1  
Różne konfiguracje odbiornika GNSS.
  
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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 439  
PDOP Trójwymiarowe rozmycie dok ładności 
RMC Zalecane minimalne dane GNSS  
SIS Sygna ł w przestrzeni  
VDOP Pionowe rozmycie dok ładności 
VU Przyrz ąd rejestrujący 
2. SPECYFIKACJA ODBIORNIKA GNSS  
Niezależnie od konfiguracji tachografu inteligentnego z urz ądzeniem 
zewnętrznym GNSS lub bez niego, dostarczanie dok ładnych i wiarygod ­
nych informacji o po łożeniu jest niezb ędne do zapewnienia skutecznego 
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 Geostationary 
Navigation Overlay Service (EGNOS), które zosta ły określone 
w rozporz ądzeniu Parlamentu Europejskiego i Rady (UE) nr 
1285/2013 (  1 ). System ustanowiony w ramach programu Galileo jest 
niezależnym światowym systemem nawigacji satelitarnej, za ś system 
ustanowiony w ramach programu EGNOS jest regionalnym systemem 
nawigacji satelitarnej 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.  
GNS_3 Odbiornik GNSS musi by ć zdolny do obs ługi uwierzytelniania 
sygnałów usługi otwartej systemu Galileo, kiedy us ługę taką 
będzie oferowa ł system Galileo i gdy b ędzie ona wspierana 
przez producentów odbiorników GNSS. Jednak w przypadku 
tachografów inteligentnych wprowadzonych do obrotu przed 
spełnieniem powy ższych warunków i niezdolnych do wspie ­
rania uwierzytelnienia us ługi otwartej Galileo, modernizacja 
nie będzie wymagana.  
3. KOMUNIKATY NMEA  
Niniejsza sekcja zawiera opis komunikatów NMEA wykorzystywanych 
w funkcjonowaniu tachografu inteligentnego. Sekcja ta ma zastosowanie 
w odniesieniu do konfiguracji tachografu inteligentnego z urz ądzeniem 
zewnętrznym GNSS lub bez niego.  
GNS_4 Dane dotycz ące lokalizacji opieraj ą się na zalecanych mini ­
malnych danych GNSS (RMC) w komunikacie NMEA, 
który zawiera informacje o po łożeniu (długość i szeroko ść 
geograficzn ą), czas w formacie UTC (ggmmss,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.1):  ▼B 
( 1 ) Rozporz ądzenie Parlamentu Europejskiego i Rady (UE) nr 1285/2013 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 — 26.02.2020 — 002.001 — 440  
Rys. 2  
Struktura komunikatu RMC
  
Parametr „Status” informuje o tym, czy sygna ł GNSS jest dost ępny. 
Dopóki warto ść „Statusu” nie zostanie ustawiona na „A”, otrzymywa ­
nych danych (np. dotycz ących czasu lub d ługości/szerokości geograficz ­
nej) nie mo żna wykorzystywa ć do rejestrowania po łożenia pojazdu 
w VU.  
▼M1 
Dokładność położenia opiera si ę na formacie komunikatu RMC 
opisanym powy żej. Pierwsz ą część pól 3 i 5 wykorzystuje 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_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 aktywnych satelitów) w celu ustalenia 
i zarejestrowania gotowo ści i dokładności sygnału. W szcze ­
gólności HDOP stosuje si ę w celu wskazania poziomu dok ład­
noś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.  
Ŕysunek 3  
Struktura komunikatu GSA
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 441  
GNS_6 Komunikat GSA przechowuje si ę z numerem rekordu 
„02”–„06”.  
▼B 
GNS_7 Maksymalny rozmiar komunikatów NMEA (np. RMC, GSA 
lub innych), jaki mo żna zastosowa ć w celu ustalenia rozmiaru 
polecenia Read Record, wynosi 85 bajtów (zob. tabela 1).  
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 ętrz­
nego GNSS.  
GNS_8 Urz ądzenie zewn ętrzne GNSS musi by ć obsługiwane przez 
specjalny interfejs pojazdu.  
GNS_9 Urz ądzenie zewn ętrzne GNSS sk łada się z następujących 
elementów sk ładowych (zob. rys. 4):  
a) komercyjnego odbiornika GNSS zapewniaj ącego dane 
o położeniu za po średnictwem interfejsu danych GNSS. 
Przykładowo interfejs danych GNSS mo że być w standar ­
dzie NMEA V4.10, 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 komunikatów NMEA, 
który musi zawiera ć co najmniej komunikaty RMC 
i GSA. Wdro żenie interfejsu danych GNSS zale ży od 
uznania producentów urz ądzeń zewnętrznych GNSS;  
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 rejestruj ącym i obs ługi 
interfejsu danych GNSS odbiornika GNSS. Zespó ł ten jest 
wyposażony w pami ęć do przechowywania danych identy ­
fikacyjnych z odbiornika GNSS i urz ądzenia zewn ętrznego 
GNSS;  
c) systemu obudowy z funkcj ą wykrywania manipulowania, 
obejmującego zarówno odbiornik GNSS, jak i bezpieczny 
nadajnik-odbiornik GNSS. Funkcja wykrywania manipulo ­
wania umo żliwia wdra żanie środków bezpiecze ństwa 
zgodnie z wymogami okre ślonymi w profilu zabezpie ­
czenia tachografu inteligentnego;  
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 ępują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 nadajni ­
kiem-odbiornikiem GNSS i musi zapewnia ć zgodność z wymo­
gami normy ISO/IEC 7816-4:2013 w zakresie łączności z urzą­
dzeniem zewn ętrznym GNSS.  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 442  
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;  
— 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ętrz­
nego GNSS.  
4.2. Łączność między urządzeniem zewn ętrznym GNSS a przyrz ądem 
rejestrującym 
4.2.1  Protokó ł łączności 
GNS_14 Protokó ł łączności między urządzeniem zewn ętrznym GNSS 
a przyrządem rejestruj ącym obsługuje trzy funkcje:  
1. gromadzenie i rozpowszechnianie danych GNSS (np. po ło­ 
żenie, 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.  
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ądze­
niem zewn ętrznym GNSS a przyrz ądem rejestruj ącym bazuje 
na normie ISO/IEC 7816-12:2005 lub innej normie zgodnej 
z normą ISO/IEC 7816-4:2013.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 443  
GNS_16 W protokole łączności nie są obsługiwane pola o rozszerzonej 
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.  
▼M1 
GNS_18 Je żeli chodzi o funkcje: 1) gromadzenia i rozpowszechniania 
danych GNSS; 2) gromadzenia danych dotycz ących konfigu ­
racji urządzenia zewn ętrznego GNSS; oraz 3) protoko łu zarzą­
dzania, bezpieczny nadajnik-odbiornik GNSS symuluje inteli ­
gentną kartę za pomoc ą architektury systemu plików sk łada­
jącej się z pliku g łównego (MF), pliku dedykowanego (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.  
▼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 heksadecymal ­
nym. 
▼M1 
GNS_20 Bezpieczny nadajnik-odbiornik GNSS u żywa pamięci do prze­
chowywania danych i jest w stanie przeprowadzi ć co najmniej 
20 milionów cyklów zapisu/odczytu. Poza tym aspektem 
o konstrukcji wewn ętrznej i wdra żaniu bezpiecznego nadaj ­
nika-odbiornika GNSS decyduj ą producenci.  
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 wspomagaj ą­
cego opartego na wyposa żeniu satelitarnym SBAS.  
▼B 
GNS_21 Struktur ę plików przedstawiono w tabeli 1. Aby uzyska ć infor­
macje na temat warunków dost ępu (ALW, NEV, SM-MAC), 
zob. dodatek 2 rozdzia ł 3.5.  
Tabela 1  
Struktura plików  
Warunki dost ępu 
Plik Identyfikator pliku  Odczyt  Aktualizacja  Zaszyfrowany  
Plik główny (MF)  3F00  
EF.ICC  0002  ALW  NEV 
(przez VU)  Nie 
Plik katalogowy urz ądzenia GNSS  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 
(przez VU)  Nie ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 444  
Plik / element danych  Nr rekordu  Rozmiar (w bajtach)  Wartości 
domyślne 
Min.  Maks.  
Plik główny (MF)  552  1 031  
EF.ICC  
sensorGNSSSerialNumber  8  8  
Plik katalogowy urz ądzenia GNSS  612  1 023  
EF EGF_MACertificate  204  341  
EGFCertificate  204  341  {00..00}  
EF CA_Certificate  204  341  
MemberStateCertificate  204  341  {00..00}  
EF Link_Certificate  204  341  
LinkCertificate  204  341  {00..00}  
EF.EGF  
Komunikat RMC NMEA  ‘01’  85  85  
Pierwszy komunikat GSA NMEA  ‘02’  85  85  
Drugi komunikat GSA NMEA  ‘03’  85  85  
Trzeci komunikat GSA NMEA  ‘04’  85  85  
Czwarty komunikat GSA NMEA  ‘05’  85  85  
Piąty komunikat GSA NMEA  ‘06’  85  85  
Rozszerzony numer seryjny urz ą­
dzenia zewn ętrznego GNSS zdefinio ­
wany w dodatku 1 jako „Sensor ­
GNSSSerialNumber”.  ‘07’ 8  8  
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’ 16  16  
Identyfikator elementu zabezpieczenia 
urządzenia zewn ętrznego GNSS 
zdefiniowany w dodatku 1 jako „Sen ­
sorExternalGNSSSCIdentifier”.  ‘10’ 8  8  
RFU – zastrze żony do wykorzystania 
w przyszłości Od ‘11’ do 
‘FD’  
4.2.2  Bezpieczne przesy łanie danych GNSS  
GNS_22 Bezpiecznie przesy łanie danych GNSS o po łożeniu jest 
dozwolone wy łącznie w nast ępujących warunkach:  
1. proces powi ązania zosta ł przeprowadzony w sposób 
opisany w dodatku 11 „Wspólne mechanizmy zabezpiecze ­
nia”; ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 445  
2. proces okresowego wzajemnego uwierzytelniania i uzgad ­
niania klucza sesji mi ędzy VU a urz ądzeniem zewn ętrznym 
GNSS, równie ż opisany w dodatku 11 „Wspólne mecha ­
nizmy zabezpieczenia”, przeprowadzono ze wskazan ą częs­
totliwością. 
GNS_23 Co T sekund, gdzie T jest warto ścią nie większą niż 10, chyba 
że trwa proces powi ązania lub wzajemnego uwierzytelnienia 
i uzgadniania klucza sesji, VU żąda od urządzenia zewn ętrz­
nego GNSS przes łania informacji o po łożeniu w oparciu 
o poniższy schemat.  
1. VU żąda od urz ądzenia zewn ętrznego GNSS przes łania 
danych dotycz ących lokalizacji wraz z danymi dotycz ącymi 
rozmycia precyzji (z komunikatu NMEA GSA). 
Bezpieczny nadajnik-odbiornik VU stosuje zgodne z wymo ­
gami normy ISO/IEC 7816-4:2013 polecenia SELECT 
i READ RECORD(S) w trybie tylko uwierzytelniania 
bezpiecznej wymiany komunikatów, jak opisano w dodatku 
11 sekcja 11.5, z identyfikatorem pliku ‘2F2F’ i numerem 
zapisu „01” w przypadku komunikatu NMEA RMC oraz 
‘02’,‘03’,‘04’,‘05’,‘06’ w przypadku komunikatu NMEA 
GSA.  
2. Dane dotycz ące lokalizacji 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 nadaj ­
nik-odbiornik GNSS otrzymuje dane NMEA z cz ęstotliwo­ 
ścią co najmniej 1 Hz od odbiornika GNSS za po średnic­
twem interfejsu danych GNSS.  
3. Bezpieczny nadajnik-odbiornik GNSS wysy ła odpowied ź 
do bezpiecznego nadajnika-odbiornika VU za pomoc ą 
komunikatu odpowiedzi APDU w trybie tylko uwierzytel ­
niania bezpiecznej wymiany komunikatów, zgodnie 
z opisem przedstawionym w dodatku 11 sekcja 11.5.  
4. Bezpieczny nadajnik-odbiornik VU weryfikuje autentycz ­
ność i integralno ść otrzymanej odpowiedzi. W przypadku 
pozytywnego wyniku dane dotycz ące lokalizacji s ą przeka­
zywane do procesora VU za po średnictwem interfejsu 
danych GNSS.  
▼M1 
5. Procesor VU sprawdza otrzymane dane, wyodr ębniając 
informacje (np. o d ługości geograficznej, szeroko ści 
geograficznej, czasie) z komunikatu NMEA RMC. Komu ­
nikat RMC NMEA zawiera informacj ę o tym, czy po ło­ 
żenie jest prawid łowe. Jeżeli położenie nie jest prawid łowe, 
dane dotycz ące lokalizacji nie s ą jeszcze dost ępne i nie 
można ich wykorzysta ć w celu zarejestrowania po łożenia 
pojazdu. Je żeli położenie jest prawid łowe, 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 ustalenie po ło­ 
żenia jest mo żliwe).  
▼B 
6. Procesor VU przechowuje otrzymane i przetworzone infor ­
macje, takie jak d ługość geograficzna, szeroko ść geogra­
ficzna, czas i pr ędkość, w VU w formacie zdefiniowanym 
w słowniku danych w dodatku 1 jako wspó łrzędne geogra ­
ficzne „GeoCoordinates” wraz z warto ścią HDOP obli ­
czoną jako minimum z warto ści HDOP zgromadzonych 
w ramach dost ępnych systemów GNSS.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 446  
4.2.3  Struktura polecenia Read Record  
Poniższa sekcja zawiera szczegó łowy opis struktury polecenia Read 
Record. Zgodnie z opisem przedstawionym w dodatku 11 „Wspólne 
mechanizmy zabezpieczenia” dodaje si ę funkcję bezpiecznej wymiany 
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 komunikatów  
INS 1  ‘B2h’  Odczyt rekordu  
P1 1  ‘XXh’  Numer rekordu (‘00’ oznacza bie żący 
rekord)  
P2 1  ‘04h’  Odczytaj rekord o numerze rekordu wska ­
zanym 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 komunikat 
‘9000 ’, 
— jeżeli bieżący plik nie jest ukierunkowany na rekord, 
bezpieczny nadajnik-odbiornik GNSS zwraca komunikat  
‘6981’ , 
— jeżeli stosuje si ę polecenie z P1= ‘00’, lecz nie ma 
żadnego bie żącego pliku elementarnego, bezpieczny nadaj ­
nik-odbiornik GNSS zwraca komunikat  ‘6986’  (polecenie 
niedozwolone),  
— jeżeli nie znaleziono rekordu, bezpieczny nadajnik- 
odbiornik GNSS zwraca komunikat ‘ 6A 83 ’, 
— jeżeli urządzenie zewn ętrzne GNSS wykryje manipulowa ­
nie, zwraca s łowa stanu „ 66 90 ”. 
GNS_27 Bezpieczny nadajnik-odbiornik GNSS obs ługuje nast ępujące 
polecenia tachografów 2. generacji, wyszczególnione 
w dodatku 2:  
Polecenie  Odniesienie  
Select  Dodatek 2 rozdzia ł 3.5.1  
Read Binary  Dodatek 2 rozdzia ł 3.5.2  
Get Challenge  Dodatek 2 rozdzia ł 3.5.4  
PSO: Verify Certificate  Dodatek 2 rozdzia ł 3.5.7  
External Authenticate  Dodatek 2 rozdzia ł 3.5.9  
General Authenticate  Dodatek 2 rozdzia ł 3.5.10  
MSE:SET  Dodatek 2 rozdzia ł 3.5.11  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 447  
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 klucza 
sesji między urządzeniem zewn ętrznym GNSS a przyrz ądem rejestru ­
jącym opisano w rozdziale 11 dodatku 11 „Wspólne mechanizmy zabez ­
pieczenia”.  
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  
▼M1 
GNS_28 Je żeli VU nie uda si ę nawiązać połączenia z powi ązanym 
urządzeniem zewn ętrznym GNSS przez d łużej niż 20 minut 
ciągłej pracy, przyrz ąd ten generuje i rejestruje zdarzenie typu 
„EventFaultType” z warto ścią enum „0E”H B łąd komunikacji 
z urządzeniem zewn ętrznym GNSS oraz ze znacznikiem czasu 
ustawionym na bie żącą godzinę. Zdarzenie zostanie wygene ­
rowane, wy łącznie jeżeli spełnione będą następujące dwa 
warunki: a) tachograf inteligentny nie znajduje si ę w trybie 
kalibracyjnym; oraz b) pojazd jest w ruchu. W tym kontek ście 
występuje błąd połączenia, gdy bezpieczny nadajnik-odbiornik 
VU nie otrzyma komunikatu odpowiedzi po wys łaniu komu ­
nikatu żądania, jak opisano w pkt 4.2.  
▼B 
4.4.2  Naruszenie integralno ści fizycznej urz ądzenia zewn ętrznego GNSS  
▼M1 
GNS_29 W przypadku naruszenia integralno ści fizycznej urz ądzenia 
zewnętrznego GNSS bezpieczny nadajnik-odbiornik GNSS 
kasuje całą swoją pamięć, w tym materia ł kryptograficzny. 
Jak opisano w GNS_25 i GNS_26, VU wykrywa manipulo ­
wanie, jeżeli odpowied ź ma status „6690”. Nast ępnie VU 
generuje zdarzenie typu „EventFaultType” z warto ścią enum 
„19”H Wykrywanie manipulowania GNSS. Urz ądzenie 
zewnętrzne GNSS nie mo że już również odpowiada ć na 
żadne żądania zewn ętrzne.  
▼B 
4.4.3  Brak informacji o po łożeniu z odbiornika GNSS  
▼M1 
GNS_30 Je żeli bezpieczny nadajnik-odbiornik GNSS nie otrzymuje 
danych z odbiornika GNSS przez d łużej niż 3 godziny ci ągłej 
pracy, urządzenie to generuje komunikat odpowiedzi na pole ­
cenie READ RECORD z numerem rekordu „01” i polem 
danych o rozmiarze 12 bajtów, wszystkich ustawionych na 
0xFF. Po otrzymaniu komunikatu odpowiedzi z okre śloną 
wartością pola danych VU generuje i rejestruje zdarzenie 
typu „EventFaultType” z warto ścią enum „0D”H Brak infor ­
macji o pozycji z odbiornika GNSS ze znacznikiem czasu 
o bieżącej wartości czasu, wy łącznie jeżeli spełnione będą 
następujące dwa warunki: a) tachograf inteligentny nie znaj ­
duje się w trybie kalibracyjnym; oraz b) pojazd jest w ruchu.  
▼B 
4.4.1  Wygaśnięcie certyfikatu urz ądzenia zewn ętrznego GNSS  
GNS_31  ►M1 Jeżeli VU wykryje, że certyfikat EGF wykorzystywany 
do celów wzajemnego uwierzytelniania straci ł ważność, przy­
rząd rejestruj ący generuje i rejestruje zdarzenie przyrz ądu 
rejestrującego typu „EventFaultType” z warto ścią enum  
„1B”H Wyga śnięcie certyfikatu urz ądzenia zewn ętrznego 
GNSS  ze znacznikiem czasu o bie żącej wartości czasu. VU 
nadal wykorzystuje otrzymane dane GNSS o po łożeniu. ◄ ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 448  
Rys. 4  
Schemat urz ądzenia zewn ętrznego GNSS
  
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.  
GNS_32 Odbiornik GNSS pe łni funkcję nadajnika i przesy ła komuni­
katy 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 NMEA, który musi obej ­
mować co najmniej komunikaty RMC i GSA.  
GNS_33 Do VU musi by ć podłączona zewn ętrzna antena GNSS zain ­
stalowana na poje ździe lub wewn ętrzna antena GNSS.  
5.2. Obsługa błędów 
5.2.1  Brak informacji o po łożeniu z odbiornika GNSS  
▼M1 
GNS_34 Je żeli VU nie otrzymuje danych z odbiornika GNSS przez 
dłużej niż 3 godziny ci ągłej pracy, przyrz ąd ten generuje 
i rejestruje zdarzenie typu „EventFaultType” z warto ścią 
enum „0D”H Brak informacji o pozycji z odbiornika GNSS 
ze znacznikiem czasu o bie żącej wartości czasu, wy łącznie 
jeżeli spełnione będą następujące dwa warunki: a) tachograf 
inteligentny nie znajduje si ę w trybie kalibracyjnym; oraz b) 
pojazd jest w ruchu.  
6. KONFLIKT CZASOWY GNSS  
Jeżeli VU wykryje rozbie żność wynoszącą ponad 1 minut ę między 
czasem funkcji pomiaru czasu przyrz ądu rejestruj ącego a czasem 
z odbiornika GNSS, przyrz ąd rejestruj ący zarejestruje zdarzenie typu 
„EventFaultType” z warto ścią enum  „0B”H Konflikt czasowy (mi ędzy 
GNSS a wewn ętrznym zegarem VU) . Po wywo łaniu zdarzenia dotycz ą­
cego konfliktu czasowego VU nie weryfikuje rozbie żności czasu przez 
następne 12 godzin. Wydarzenie to nie uruchamia si ę, jeżeli odbiornik 
GNSS nie wykrywa ł prawidłowego sygna łu GNSS w ci ągu ostatnich 
30 dni.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 449  
7. KONFLIKT RUCHU POJAZDU  
GNS_35 VU wyzwala i rejestruje zdarzenie  Konflikt ruchu pojazdu  
(zob. w wymaganiu 84 w niniejszym za łączniku) znacznikiem 
czasu o bie żącej wartości czasu, 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. W celu wykrycia takich sprzeczno ści 
wartość mediany ró żnicy prędkości pochodz ących z tych 
źródeł należy stosować w sposób okre ślony 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ść mediany oblicza si ę wykorzystuj ąc wszystkie obli ­
czone warto ści w oknie czasu obejmuj ącym pięć ostatnich 
minut ruchu,  
— wartość mediany oblicza si ę jako średnią 80 % warto ści 
pozostałych po wyeliminowaniu najwy ższych warto ści 
bezwzględnych,  
zdarzenie  Konflikt ruchu pojazdu  jest wyzwalane je żeli 
wartość mediany jest wy ższa niż 10 km/h przez pi ęć nieprze­
rwanych minut ruchu pojazdu. Opcjonalnie mo żna wyko­
rzystać inne niezale żne źródła wykrywania ruchu pojazdu, 
aby zapewni ć skuteczniejsze wykrywanie manipulacji zwi ąza­
nych z tachografem. (Uwaga: median ę z ostatnich 5 minut 
stosuje się aby zmniejszy ć ryzyko zwi ązane z warto ściami 
skrajnymi pomiaru i warto ściami chwilowymi). Zdarzenie 
takie nie uruchamia si ę w następujących warunkach: a) 
podczas przeprawy promowej / przejazdu kolejowego; b) 
jeżeli informacje o po łożeniu z odbiornika GNSS nie s ą 
dostępne; oraz c) podczas trwania trybu kalibracyjnego.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 450  
Dodatek 13  
INTERFEJS ITS  
SPIS TRE ŚCI 
1. WPROWADZENIE  
2. ZAKRES  
2.1. Skróty, definicje i oznaczenia  
3. PRZYWO ŁANE ROZPORZ ĄDZENIA I NORMY  
4. ZASADY DZIA ŁANIA INTERFEJSU  
4.1. Warunki wst ępne dotycz ące przesyłania danych za po średnictwem inter ­ 
fejsu ITS  
4.1.1 Dane dostarczane za po średnictwem interfejsu ITS  
4.1.2 Zawarto ść Danych  
4.1.3 Aplikacje ITS  
4.2. Technologia łączności 
4.3. Autoryzacja za pomoc ą kodu PIN  
4.4. Format komunikatu  
4.5. Zgoda kierowcy  
4.6. Pobieranie danych standardowych  
4.7. Pobieranie danych osobowych  
4.8. Pobieranie danych dotycz ących zdarze ń i usterek  
1. WPROWADZENIE  
W niniejszym dodatku okre ślono struktur ę oraz procedury, które nale ży 
zastosować w celu wdro żenia interfejsu do inteligentnych systemów trans ­
portowych (ITS) zgodnie z art. 10 rozporz ądzenia (UE) nr 165/2014 
(„Rozporządzenie ”). 
W Rozporządzeniu  określono, że tachografy pojazdów mog ą być wyposa­ 
żone w znormalizowane interfejsy pozwalaj ące na wykorzystywanie przez 
urządzenie zewn ętrzne danych rejestrowanych lub generowanych przez 
tachograf w trybie operacyjnym, z zastrze żeniem spełnienia nast ępujących 
warunków:  
a) interfejs nie ma wp ływu na autentyczno ść i integralno ść danych tacho ­
grafu;  
b) interfejs spe łnia wymogi szczegó łowych przepisów art. 11  Rozporzą­
dzenia ; 
c) urządzenie zewn ętrzne podłączone do interfejsu uzyskuje dost ęp do 
danych osobowych, w tym do danych geopozycyjnych, dopiero po 
udzieleniu przez kierowc ę, którego te dane dotycz ą, podlegającej wery­
fikacji zgody.  
2. ZAKRES  
Celem niniejszego dodatku jest okre ślenie sposobu, w jaki aplikacje zain ­
stalowane na urz ądzeniach zewn ętrznych mog ą uzyskiwa ć dane ( Dane ) 
z tachografu poprzez po łączenie Bluetooth®.  
Dane  dostępne za pośrednictwem tego interfejsu s ą opisane w za łączniku 
1 do niniejszego dokumentu. Stosowanie przedmiotowego interfejsu nie 
uniemożliwia wdro żenia innych interfejsów (np. za po średnictwem szyny 
CAN) do celów przekazywania danych z VU do innych jednostek prze ­
twarzania pojazdu.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 451  
W niniejszym dodatku okre śla się: 
— Dane  dostępne za pośrednictwem interfejsu ITS;  
— profil Bluetooth® wykorzystywany do przesy łania danych;  
— procedury zapytywania i pobierania oraz sekwencj ę operacji;  
— mechanizm parowania mi ędzy tachografem a urz ądzeniem zewn ętrz­
nym;  
— mechanizm udzielania zgody udost ępniony kierowcy.  
▼M1 
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 jest okre ślone w innym miejscu w  rozporządzeniu  lub w prze ­
ciwnym razie stanowi funkcj ę projektu produktu);  
— formy przedstawienia zgromadzonych danych w aplikacji zainstalo ­
wanej na urz ądzeniu zewn ętrznym;  
— przepisów dotycz ących bezpiecze ństwa danych wykraczaj ących poza 
zabezpieczenia zapewniane przez Bluetooth® (takie jak szyfrowanie) 
w odniesieniu do tre ści danych  (które zostan ą określone w innym 
miejscu w  rozporządzeniu  [dodatek 11 „Wspólne mechanizmy zabez ­
pieczenia”]);  
— protoko łów Bluetooth® wykorzystywanych przez interfejs ITS.  
▼B 
2.1. Skróty, definicje i oznaczenia  
W niniejszym dodatku stosuje si ę następujące skróty i definicje w łaściwe 
dla tego dodatku:  
Łączność wymiana informacji/danych mi ędzy jednostk ą centralną 
(tj. tachografem) a jednostk ą zewnętrzną poprzez inter ­
fejs ITS za po średnictwem po łączenia Bluetooth®  
Dane  zbiory danych okre ślone w załączniku 1  
Rozporządzenie  rozporządzenie Parlamentu Europejskiego i Rady (UE) 
nr 165/2014 z dnia 4 lutego 2014 r. w sprawie tacho ­
grafów stosowanych w transporcie drogowym i uchyla ­
jące rozporz ądzenie Rady (EWG) nr 3821/85 w sprawie 
urządzeń rejestrujących stosowanych w transporcie 
drogowym oraz zmieniaj ące rozporz ądzenie (WE) nr 
561/2006 Parlamentu Europejskiego i Rady w sprawie 
harmonizacji niektórych przepisów socjalnych odnosz ą­
cych się do transportu drogowego  
BR podstawowa szybko ść 
EDR  zwi ększona szybko ść danych  
GNSS  globalny system nawigacji satelitarnej  
IRK  klucz do ustalania to żsamości 
ITS inteligentny system transportowy  
LE niski poziom energii  
PIN osobisty numer identyfikacyjny  
PUC  osobisty szyfr odblokowuj ący 
SID identyfikator us ługi 
SPP profil portu szeregowego  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 452  
SSP bezpieczne i łatwe parowanie  
TRTP  parametr żądania przes łania danych  
TREP  parametr odpowiedzi na przes łanie danych  
VU przyrz ąd rejestrujący 
3. PRZYWO ŁANE ROZPORZ ĄDZENIA I NORMY  
Specyfikacje okre ślone w niniejszym dodatku odnosz ą się do wszystkich 
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 zapisy niniej ­
szego dodatku s ą nadrzędne. 
W niniejszym dodatku przywo łano następujące rozporz ądzenia i normy:  
— rozporz ądzenie Parlamentu Europejskiego i Rady (UE) nr 165/2014 
z dnia 4 lutego 2014 r. w sprawie tachografów stosowanych w trans ­
porcie drogowym i uchylaj ące rozporz ądzenie Rady (EWG) nr 
3821/85 w sprawie urz ądzeń rejestrujących stosowanych w transporcie 
drogowym oraz zmieniaj ące rozporz ądzenie (WE) nr 561/2006 Parla ­
mentu Europejskiego i Rady w sprawie harmonizacji niektórych prze ­
pisów socjalnych odnosz ących się do transportu drogowego;  
— rozporz ądzenie (WE) nr 561/2006 Parlamentu Europejskiego i Rady 
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) nr 2135/98, jak 
również uchylające rozporz ądzenie Rady (EWG) nr 3820/85;  
— normę ISO 16844 – 4: Pojazdy drogowe – Systemy tachograficzne – 
Część 4: Interfejs CAN;  
— normę ISO 16844 – 7: Pojazdy drogowe – Systemy tachograficzne – 
Część 7: Parametry;  
— Bluetooth® – Profil portu szeregowego – V1.2 (Bluetooth® – Serial 
Port Profile – V1.2);  
— Bluetooth® – Wersja podstawowa 4.2 (Bluetooth® – Core Version 
4.2); 
— protokó ł NMEA 0183 V4.1.  
4. ZASADY DZIA ŁANIA INTERFEJSU  
4.1. Warunki wst ępne dotycz ące przesy łania danych za po średnictwem 
interfejsu ITS  
Przyrząd rejestruj ący odpowiada za aktualizowanie i utrzymywanie 
danych, które maj ą być przechowywane w VU, bez żadnego udzia łu 
interfejsu ITS. Środki umo żliwiające osiągnięcie tego celu znajduj ą się 
wewnątrz VU i s ą określone w innym miejscu w rozporz ądzeniu, a nie 
w niniejszym dodatku.  
4.1.1  Dane dostarczane za po średnictwem interfejsu ITS  
Przyrząd rejestruj ący odpowiada za aktualizowanie danych, które b ędą 
dostępne za po średnictwem interfejsu ITS z cz ęstotliwością ustaloną 
w procedurach VU, bez żadnego udzia łu interfejsu ITS. Dane VU stosuje 
się jako podstaw ę do wypełniania i aktualizowania  Danych , przy czym 
środki umo żliwiające osiągnięcie tego celu okre ślono w innym miejscu 
w Rozporz ądzeniu , lub w przypadku braku takiego wyszczególnienia 
stanowią funkcję projektu produktu i nie s ą określone w niniejszym 
dodatku.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 453  
4.1.2  Zawarto ść Danych  
Zawartość Danych  pokrywa si ę z zawartością określoną w załączniku 1 do 
niniejszego dodatku.  
4.1.3  Aplikacje ITS  
Aplikacje ITS b ędą wykorzystywa ły dane udost ępnione za po średnictwem 
interfejsu ITS na przyk ład w celu zoptymalizowania zarz ądzania czynno ­ 
ściami kierowcy przy jednoczesnym przestrzeganiu przepisów rozporz ą­
dzenia, w celu wykrywania mo żliwych usterek tachografu lub w celu 
stosowania danych GNSS. Specyfikacje dotycz ące aplikacji nie s ą objęte 
zakresem niniejszego dodatku.  
4.2. Technologia łączności 
Wymiana  Danych  za pomoc ą interfejsu ITS jest prowadzona za po średnic­
twem interfejsu Bluetooth® kompatybilnego z wersj ą 4.2 lub pó źniejszą. 
Bluetooth® funkcjonuje w nielicencjonowanym pa śmie 2,4–2,485 GHz 
przeznaczonym do zastosowa ń przemysłowych, naukowych i medycznych 
(ISM). Bluetooth® 4.2 oferuje ulepszone mechanizmy ochrony prywat ­
ności i zabezpieczenia oraz zwi ększoną prędkość i niezawodno ść prze­
syłów danych. Do celów poni ższej specyfikacji wykorzystuje si ę urzą­
dzenie radiowe Bluetooth® klasy 2 zapewniaj ące zasięg do 10 metrów. 
Więcej informacji na temat Bluetooth® 4.2 mo żna znaleźć na stronie 
internetowej www.bluetooth.com (https://www.bluetooth.org/en-us/specifi ­
cation/adopted-specifications?_ga=1.215147412.2083380574.14 353056 
76). 
Łączność jest nawiązywana z urz ądzeniami do łączności po zako ńczeniu 
procesu parowania przez autoryzowane urz ądzenie. Poniewa ż Bluetooth® 
wykorzystuje model urz ądzeń nadrzędnych/podrz ędnych w celu kontrolo ­
wania, kiedy i gdzie urz ądzenia mog ą przesyłać dane, tachograf b ędzie 
odgrywał rolę urządzenia nadrz ędnego, natomiast urz ądzenie zewn ętrzne 
będzie pełniło funkcję urządzenia podrz ędnego.  
▼M1 
W momencie gdy urz ądzenie zewn ętrzne pojawi si ę po raz pierwszy 
w zakresie dzia łania VU, mo żna rozpocz ąć proces parowania Bluetooth® 
(zob. równie ż załącznik 2). Urz ądzenia wymieniaj ą adresy, nazwy, profile 
i wspólny klucz tajny, co pozwala im si ę łączyć, ilekroć znajdą się 
w pobliżu siebie w przysz łości. Po zako ńczeniu tego etapu urz ądzenie 
zewnętrzne uzyskuje status urz ądzenia zaufanego i jest w stanie inicjowa ć 
żądania pobrania danych z tachografu. Nie przewiduje si ę możliwości 
dodawania mechanizmów szyfrowania poza mechanizmami zapewnianymi 
przez Bluetooth®. Je żeli jednak dodatkowe mechanizmy zabezpiecze ń są 
konieczne, zostan ą one dodane zgodnie z dodatkiem 11 „Wspólne mecha ­
nizmy zabezpieczenia”.  
▼B 
Ogólna zasada łączności jest opisana na poni ższym rysunku.
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 454  
Profil SPP (profil portu szeregowego) Bluetooth® wykorzystuje si ę do 
przesyłania danych z VU do urz ądzenia zewn ętrznego.  
4.3. Autoryzacja za pomoc ą kodu PIN  
▼M1 
Ze względów bezpiecze ństwa VU b ędzie wymaga ł systemu autoryzacji za 
pomocą kodu PIN dzia łającego oddzielnie od systemu parowania Blueto ­
oth. Każdy VU musi by ć w stanie generowa ć kody PIN s łużące do uwie ­
rzytelniania, sk ładające się z co najmniej 4 cyfr. Za ka żdym razem gdy 
urządzenie zewn ętrzne paruje si ę z VU, musi wprowadzi ć poprawny kod 
PIN, zanim otrzyma jakiekolwiek dane.  
▼B 
Pomyślne wprowadzenie kodu PIN skutkuje umieszczeniem urz ądzenia na 
tzw. białej liście. Biała lista zawiera co najmniej 64 urz ądzenia sparowane 
z danym VU.  
Wprowadzenie b łędnego kodu PIN trzy razy pod rz ąd skutkuje czasowym 
umieszczeniem danego urz ądzenia na tzw. czarnej li ście. Gdy urz ądzenie 
trafi na czarn ą listę, każda ponowna próba nawi ązania połączenia przez to 
urządzenie jest odrzucana. Dalsze wprowadzanie b łędnego kodu PIN trzy 
razy pod rz ąd skutkuje na łożeniem blokady dost ępu obowiązującej przez 
dłuższy okres (zob. tabela 1). Wprowadzenie poprawnego kodu PIN 
usuwa blokad ę i zeruje liczb ę prób. Rysunek 1 w za łączniku 2 przedstawia 
diagram sekwencji próby autoryzacji kodu PIN.  
Tabela 1  
Czas trwania blokady w zale żności od liczby kolejnych nieudanych 
prób wprowadzenia poprawnego kodu PIN  
Liczba kolejnych b łędnych prób  Czas trwania blokady  
3 30 sekund  
6 5 minut  
9 1 godzina  
12 24 godziny  
15 Sta ła 
Wprowadzenie b łędnego kodu PIN pi ętnaście razy (5x3) skutkuje umiesz ­
czeniem na sta łe danego urz ądzenia ITS na czarnej li ście. Usunięcie takiej 
stałej blokady jest mo żliwe wyłącznie poprzez wprowadzenie poprawnego 
kodu PUC.  
Kod PUC sk łada się z 8 cyfr i jest dostarczany przez producenta wraz 
z VU. Wprowadzenie b łędnego kodu PUC dziesi ęć razy pod rz ąd będzie 
skutkowało nieodwo łalnym umieszczeniem danego urz ądzenia ITS na 
czarnej liście. 
▼M1 
Podczas gdy producent mo że zapewni ć możliwość zmiany kodu PIN 
bezpośrednio przez VU, kodu PUC nie mo żna zmienić. Zmiana kodu 
PIN, o ile jest mo żliwa, wymaga wprowadzenia obecnego kodu PIN 
bezpośrednio w VU.  
▼B 
Ponadto wszelkie urz ądzenia znajduj ące się na białej liście pozostaj ą na 
niej do momentu ich r ęcznego usuni ęcia przez u żytkownika (np. za 
pośrednictwem interfejsu cz łowiek-maszyna VU lub w inny sposób). 
W ten sposób z bia łej listy mo żna usunąć zgubione lub skradzione urz ą­
dzenia ITS. Ponadto ka żde urządzenie ITS opuszczaj ące zasięg połączenia 
Bluetooth na ponad 24 godziny zostaje automatycznie usuni ęte z białej 
listy VU, a przy kolejnej próbie nawi ązania połączenia konieczne jest 
ponowne wprowadzenie poprawnego kodu PIN.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 455  
Format komunikatów mi ędzy interfejsem VU a VU nie jest okre ślony 
i decyzję w tej sprawie podejmuje producent. Wspomniany producent 
zapewnia jednak, aby stosowano okre ślony format komunikatów wymie ­
nianych mi ędzy urządzeniem ITS a interfejsem VU (zob. specyfikacje 
ASN.1).  
Każdemu żądaniu przes łania danych towarzyszy zatem odpowiednia wery ­
fikacja tożsamości wysyłającego, zanim zostanie ono w jakikolwiek 
sposób rozpatrzone. Rysunek 2 w za łączniku 2 przedstawia diagram 
sekwencji dotycz ący tej procedury. Ka żde urządzenie umieszczone na 
czarnej liście automatycznie zostanie odrzucone, a ka żde urządzenie 
nieumieszczone na czarnej ani bia łej liście otrzyma żądanie wprowadzenia 
kodu PIN, które musi spe łnić, zanim ponownie wy śle swoje żądanie 
przesłania danych.  
4.4. Format komunikatu  
Wszystkie komunikaty wymieniane mi ędzy urządzeniem ITS a interfejsem 
VU mają strukturę złożoną z następujących trzech cz ęści: nagłówka obej ­
mującego bajt docelowy (TGT), bajt źródłowy (SRC) i bajt d ługości 
(LEN).  
Pole danych zawiera bajt identyfikatora us ługi (SID) i zmienn ą liczbę 
bajtów z danymi (maksymalnie 255).  
Bajt sumy kontrolnej to 1-bajtow ą sumą serii modulo 256 wszystkich 
bajtów komunikatu, z wy łączeniem samego CS.  
Komunikat zapisuje si ę w formacie Big Endian.  
Tabela 2  
Ogólny format komunikatu  
Nagłówek  Pole danych  Suma kontro ­
lna 
TGT  SRC  LEN  SID  TRTP  CC  CM  DANE  CS  
3 bajty  Maks. 255 bajtów  1 bajt  
Nagłówek  
TGT i SRC: ID docelowych (TGT) i źródłowych (SRC) urz ądzeń, których 
dotyczy dany komunikat. Interfejs VU posiada domy ślne ID „EE”. Nie 
można zmienić tego ID. Urz ądzenie ITS u żywa domy ślnego ID „A0” na 
potrzeby swojego pierwszego komunikatu sesji łączności. Następnie inter­
fejs VU przypisuje temu urz ądzeniu ITS unikatowy ID i powiadamia go 
o tym ID na potrzeby przysz łych komunikatów podczas sesji.  
Bajt LEN uwzgl ędnia tylko cz ęść „DANE” pola danych (zob. tabela 2), 4 
pierwsze bajty s ą niejawne.  
Interfejs VU potwierdza autentyczno ść wysyłającego komunikat poprzez 
weryfikacj ę krzyżową własnej IDList z danymi Bluetooth, sprawdzaj ąc, 
czy urządzenie ITS umieszczone na li ście z podanym ID znajduje si ę 
obecnie w zasi ęgu połączenia Bluetooth.  
Pole danych  
Poza SID pole danych zawiera równie ż inne parametry: parametr żądania 
przesłania danych (TRTP) i bajty licznika.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 456  
Jeżeli dane, które maj ą być obsługiwane, s ą większe niż miejsce dost ępne 
w jednym komunikacie, zostan ą podzielone na kilka podkomunikatów. 
Każdy podkomunikat ma taki sam nag łówek i SID, ale zawiera dwubaj ­
towy licznik, bie żący licznik (Counter Current, CC) i maksymalny licznik 
(Counter Max, CM), w celu wskazania numeru podkomunikatu. Aby 
umożliwić kontrolę błędów i przerwanie przesy łania, urządzenie przyj ­
mujące zatwierdza ka żdy podkomunikat. Urz ądzenie przyjmuj ące może 
przyjąć podkomunikat, za żądać ponownego przes łania podkomunikatu, 
zażądać od urządzenia wysy łającego ponownego rozpocz ęcia transmisji 
lub jej przerwania.  
▼B 
Jeżeli CC i CM nie s ą używane, przyznaje si ę im wartość 0xFF.  
Przykładowo poni ższy komunikat  
NAGŁÓWEK  SID  TRTP  CC  CM  DANE  CS  
3 bajty  D łuższy niż 255 bajtów  1 bajt  
zostanie przes łany w nast ępujący sposób:  
NAGŁÓWEK  SID  TRTP  01  n  DANE  CS  
3 bajty  255 bajtów  1 bajt  
NAGŁÓWEK  SID  TRTP  02  n  DANE  CS  
3 bajty  255 bajtów  1 bajt  
... 
NAGŁÓWEK  SID  TRTP  N  N  DANE  CS  
3 bajty  Maks. 255 bajtów  1 bajt  
Tabela 3 zawiera komunikaty, jakie VU i urz ądzenie ITS powinny by ć 
w stanie wymienia ć. Zawartość każdego parametru podano w zapisie 
heksadecymalnym. CC i CM nie s ą podane w tabeli w celu zapewnienia 
przejrzysto ści, kompletny format przedstawiono powy żej. 
Tabela 3  
Szczegółowa treść komunikatu  
Komunikat  Nagłówek  DANE  Suma 
kontrolna  
TGT  SRC  LEN  SID  TRTP  DANE  
RequestPIN  ITSID  EE  00  01  FF  
SendITSID  ITSID  EE  01  02  FF  ITSID  
SendPIN  EE  ITSID  04  03  FF  4*INTEGER (0..9)  
PairingResult  ITSID  EE  01  04  FF  BOOLEAN (T/F)  
SendPUC  EE  ITSID  08  05  FF  8*INTEGER (0..9)  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 457  
Komunikat  Nagłówek  DANE  Suma 
kontrolna  
TGT  SRC  LEN  SID  TRTP  DANE  
BanLiftingResult  ITSID  EE  01  06  FF  BOOLEAN (T/F)  
RequestRejected  ITSID  EE  08  07  FF  Godzina  
RequestData  
standardTachData  EE  ITSID  01  08  01  
personalTachData  EE  ITSID  01  08  02  
gnssData  EE  ITSID  01  08  03  
standardEventData  EE  ITSID  01  08  04  
personalEventData  EE  ITSID  01  08  05  
standardFaultData  EE  ITSID  01  08  06  
manufacturerData  EE  ITSID  01  08  07  
ResquestAccepted  ITSID  EE  Len  09  TREP  Dane  
DataUnavailable  
Brak danych  ITSID  EE  02  0A  TREP  10  
Dane osobowe nie 
podlegają wymia­
nie ITSID  EE  02  0A  TREP  11  
NegativeAnswer  
Generalne odrzu ­
cenie  ITSID  EE  02  0B  SID Req  10  
Usługa nieobs łu­
giwana  ITSID  EE  02  0B  SID Req  11  
Podfunkcja 
nieobsługiwana  ITSID  EE  02  0B  SID Req  12  
Nieprawidłowa 
długość komuni­
katu ITSID  EE  02  0B  SID Req  13  
Nieprawidłowe 
warunki lub b łąd 
kolejności żądań ITSID  EE  02  0B  SID Req  22  
Żądanie poza 
zakresem  ITSID  EE  02  0B  SID Req  31  
Oczekiwanie na 
odpowiedź ITSID  EE  02  0B  SID Req  78  
Rozbieżność ID 
ITS ITSID  EE  02  0B  SID Req  FC  
Nie znaleziono ID 
ITS ITSID  EE  02  0B  SID Req  FB  
RequestPIN (SID 01)  
Interfejs VU wysy ła ten komunikat w odpowiedzi na żądanie przes łania 
danych przes łane przez urz ądzenie ITS, które nie znajduje si ę ani na 
czarnej liście, ani na bia łej liście. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 458  
SendITSID (SID 02)  
Interfejs VU wysy ła ten komunikat za ka żdym razem, gdy nowe urz ą­
dzenie przesy ła żądanie. Takie urz ądzenie stosuje domy ślne ID „A0”, 
zanim otrzyma przypisane unikatowe ID na potrzeby sesji łączności. 
SendPIN (SID 03)  
Komunikat ten wysy ła urządzenie ITS, aby trafi ć na białą listę interfejsu 
VU. Treść tego komunikatu to kod zawieraj ący 4 liczby ca łkowite z prze ­
działu od 0 do 9.  
PairingResult (SID 04)  
Interfejs VU wysy ła ten komunikat, aby poinformowa ć urządzenie ITS, 
czy przesłany przez nie kod PIN by ł poprawny. Tre ść tego komunikatu to 
wartość logiczna „Prawda” (True), je żeli kod PIN jest poprawny, i „Fa łsz” 
(False), jeżeli PIN jest niepoprawny.  
SendPUC (SID 05)  
Komunikat ten wysy ła urządzenie ITS w celu usuni ęcia go z czarnej listy 
interfejsu VU. Tre ść tego komunikatu to kod zawieraj ący 8 liczb ca łko­
witych z przedzia łu od 0 do 9.  
BanLiftingResult (SID 06)  
Interfejs VU wysy ła ten komunikat, aby poinformowa ć urządzenie ITS, 
czy przesłany przez nie kod PUC by ł poprawny. Tre ść tego komunikatu to 
wartość logiczna „Prawda” (True), je żeli kod PUC jest poprawny, i „Fa łsz” 
(False), jeżeli PIN jest niepoprawny.  
RequestRejected (SID 07)  
Interfejs VU wysy ła ten komunikat w odpowiedzi na ka żdy komunikat 
urządzenia ITS umieszczonego na czarnej li ście poza komunikatem „Sen ­
dPUC”. Komunikat ten zawiera czas, przez jaki dane urz ądzenie ITS ma 
pozostać na czarnej li ście, zgodnie z formatem sekwencji „Time” (Czas) 
określonym w za łączniku 3.  
RequestData (SID 08)  
Komunikat ten dotycz ący uzyskania dost ępu do danych wysy ła urządzenie 
ITS. Jednobajtowy parametr żądania przes łania danych (TRTP) wskazuje 
typ żądanych danych. Rozró żnia się kilka typów danych:  
— standardTachData (TRTP 01): dane dost ępne z tachografu sklasyfiko ­
wane jako nieosobowe;  
— personalTachData (TRTP 02): dane dost ępne z tachografu sklasyfiko ­
wane jako osobowe;  
— gnssData (TRTP 03): dane GNSS, zawsze osobowe;  
— standardEventData (TRTP 04): dane dotycz ące zarejestrowanego 
zdarzenia sklasyfikowane jako nieosobowe;  
— personalEventData (TRTP 05): dane dotycz ące zarejestrowanego 
zdarzenia sklasyfikowane jako osobowe;  
— standardFaultData (TRTP 06): dane dotycz ące zarejestrowanych 
usterek sklasyfikowane jako nieosobowe;  
— manufacturerData (TRTP 07): dane udost ępnione przez producenta.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 459  
Aby uzyska ć więcej informacji na temat zawarto ści każdego typu danych, 
zob. załącznik 3 do niniejszego dodatku.  
Aby uzyska ć więcej informacji o formacie i zawarto ści danych GNSS, 
zob. dodatek 12.  
Więcej informacji na temat kodów danych dotycz ących zdarze ń i usterek 
można znaleźć w załącznikach IB i IC.  
ResquestAccepted (SID 09)  
Komunikat ten wysy ła interfejs VU w przypadku zaakceptowania komu ­
nikatu „RequestData” przes łanego przez urz ądzenie ITS. Komunikat ten 
zawiera 1-bajtowy TREP, który stanowi bajt TRTP powi ązanego komu ­
nikatu „RequestData”, oraz wszystkie dane żądanego typu.  
DataUnavailable (SID 0A)  
Komunikat ten wysy ła interfejs VU, je żeli, z określonego powodu, żądane 
dane, które maj ą być wysłane do umieszczonego na bia łej liście urzą­
dzenia ITS, nie s ą dostępne. Komunikat ten zawiera 1-bajtowy TREP, 
który stanowi TRTP żądanych danych oraz 1-bajtowy kod b łędu okre­ 
ślony w tabeli 3. Dozwolone s ą następujące kody:  
— brak danych (10): interfejs VU nie mo że uzyskać dostępu do danych 
VU z nieokre ślonych powodów;  
— dane osobowe nie podlegaj ą wymianie (11): urz ądzenie ITS usi łuje 
pobrać dane osobowe, w przypadku gdy nie podlegaj ą one wymianie.  
NegativeAnswer (SID 0B)  
Interfejs VU wysy ła takie komunikaty, je żeli żądanie nie mo że zostać 
zrealizowane z ka żdego powodu innego ni ż brak dost ępności danych. 
Komunikaty takie s ą zazwyczaj przesy łane w odpowiedzi na nieprawid ­ 
łowy format żądania (długość, SID, ID ITS itd.), lecz nie tylko. TRTP 
w polu danych zawiera SID żądania. Pola danych zawiera kod identyfi ­
kujący powód uzyskania negatywnej odpowiedzi. Dozwolone s ą następu­
jące kody:  
— Generalne odrzucenie (kod: 10)  
— Czynno ść nie może zostać zrealizowana z powodu nieokre ślonego 
poniżej ani w sekcji (wprowadzi ć numer sekcji  DataUnavailable).  
— Usługa nieobs ługiwana (kod: 11)  
— SID żądania jest niezrozumia ły. 
— Podfunkcja nieobs ługiwana (kod: 12)  
— TRTP żądania jest niezrozumia ły. Może go np. brakowa ć lub jego 
wartość może znajdowa ć się poza dopuszczalnym zakresem.  
— Nieprawid łowa długość komunikatu (kod: 13)  
— Długość otrzymanego komunikatu jest nieprawid łowa (rozbie żność 
między bajtem LEN a faktyczn ą długością komunikatu).  
— Nieprawid łowe warunki lub b łąd kolejności żądań (kod: 22)  
— Żądana usługa nie jest aktywna lub sekwencja komunikatów żądań nie 
jest prawid łowa.  
— Żądanie poza zakresem (kod: 33)  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 460  
— Żądany rekord parametru (pole danych) nie jest prawid łowy.  
— Oczekiwanie na odpowied ź (kod: 78)  
— Żądanej czynno ści nie mo żna zakończyć na czas, a VU nie jest 
gotowy do przyj ęcia kolejnego żądania.  
— Rozbie żność ID ITS  (kod: FB)  
— ID ITS  SRC nie odpowiada powi ązanemu urz ądzeniu po dokonaniu 
porównania z informacjami o Bluetooth.  
— Nie znaleziono  ID ITS  (kod: FC)  
— ID ITS  SRC nie jest powi ązane z żadnym urz ądzeniem.  
Wiersze 1–72 ( FormatMessageModule ) kodu ASN.1 w za łączniku 3 
określają format komunikatów opisany w tabeli 3. Poni żej przedstawiono 
więcej informacji szczegó łowych na temat tre ści komunikatów.  
4.5. Zgoda kierowcy  
Wszystkie dost ępne dane s ą klasyfikowane jako standardowe albo 
osobowe. Dost ęp do danych osobowych jest mo żliwy wyłącznie po uzys ­
kaniu zgody kierowcy na to, aby dotycz ące go dane osobowe z tachografu 
mogły opuścić sieć pojazdu do celów wykorzystania tych danych przez 
osoby trzecie.  
Kierowca udziela zgody w momencie, gdy przy pierwszym w łożeniu 
danej karty kierowcy lub karty warsztatowej nieznanej jeszcze przyrz ą­
dowi rejestruj ącemu właściciel karty zostanie poproszony o wyra żenie 
zgody na udost ępnianie danych osobowych zwi ązanych z tachografem 
za pośrednictwem opcjonalnego interfejsu ITS (zob. równie ż pkt 
3.6.2 w za łączniku IC).  
Status zgody (aktywny/nieaktywny) jest zapisywany w pami ęci tacho­
grafu.  
W przypadku wielu kierowców wymianie z interfejsem ITS podlegaj ą 
wyłącznie dane osobowe dotycz ące kierowców, którzy wyrazili na to 
zgodę. Przykładowo jeżeli w poje ździe znajduje si ę dwóch kierowców 
i tylko pierwszy z nich zgodzi ł się na udostępnienie swoich danych osobo ­
wych, dane osobowe dotycz ące drugiego kierowcy nie podlegaj ą wymia­
nie. 
4.6. Pobieranie danych standardowych  
Rysunek 3 w za łączniku 2 przedstawia diagramy sekwencji prawid łowego 
żądania wys łanego przez urz ądzenie ITS w celu uzyskania dost ępu do 
danych standardowych. Urz ądzenie ITS zosta ło prawidłowo umieszczone 
na białej liście i nie żąda dostępu do danych osobowych, zatem nie jest 
wymagana dalsza weryfikacja. W ramach schematów za łożono, że zasto­
sowano ju ż odpowiedni ą procedurę przedstawion ą na rys. 2 w za łączniku 
2. Można je przyrówna ć do szarej ramki „REQUEST TREATMENT” na 
rys. 2.  
Spośród dostępnych danych nast ępujące dane uznaje si ę za standardowe:  
— standardTachData (TRTP 01)  
— StandardEventData (TRTP 04)  
— standardFaultData (TRTP 06)  
4.7. Pobieranie danych osobowych  
Rysunek 4 w za łączniku 2 przedstawia diagram sekwencji dotycz ący prze­
twarzania żądania dostępu do danych osobowych. Jak wspomniano wcze ś­
niej, interfejs VU wysy ła dane osobowe, wy łącznie jeżeli kierowca 
wyraźnie wyrazi ł na to zgod ę (zob. równie ż pkt 4.5). W przeciwnym 
razie żądanie musi zosta ć automatycznie odrzucone.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 461  
Spośród dostępnych danych nast ępujące dane uznaje si ę za osobowe:  
— personalTachData (TRTP 02)  
— gnssData (TRTP 03)  
— personalEventData (TRTP 05)  
— manufacturerData (TRTP 07)  
4.8. Pobieranie danych dotycz ących zdarze ń i usterek  
Urządzenia ITS musz ą być w stanie żądać dostępu do danych dotycz ących 
zdarzeń zawierających wykaz wszystkich nieoczekiwanych zdarze ń. Tego 
rodzaju dane klasyfikuje si ę jako standardowe lub osobowe, zob. za łącznik 
3. Zawarto ść każdego zdarzenia jest zgodna z dokumentami przedstawio ­
nymi w za łączniku 1 do niniejszego dodatku.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 462  
ZAŁĄCZNIK 1  
▼M1 
1) WYKAZ DANYCH DOST ĘPNYCH ZA PO ŚREDNICTWEM INTER ­
FEJSU ITS  
▼C2 
Dane  Źródło Klasyfikacja 
danych (osobowe/ 
nieosobowe)  
VehicleIdentificationNumber  Przyrz ąd rejestrujący nieosobowe  
CalibrationDate  Przyrz ąd rejestrujący nieosobowe  
TachographVehicleSpeed speed instant t  Przyrz ąd rejestrujący osobowe  
Driver1WorkingState Selector driver  Przyrz ąd rejestrujący osobowe  
Driver2WorkingState  Przyrz ąd rejestrujący osobowe  
DriveRecognize Speed Threshold detected  Przyrz ąd rejestrujący nieosobowe  
Driver1TimeRelatedStates Weekly day time  Karta kierowcy  osobowe  
Driver2TimeRelatedStates  Karta kierowcy  osobowe  
DriverCardDriver1  Przyrz ąd rejestrujący nieosobowe  
DriverCardDriver2  Przyrz ąd rejestrujący nieosobowe  
OverSpeed  Przyrz ąd rejestrujący osobowe  
TimeDate  Przyrz ąd rejestrujący nieosobowe  
HighResolutionTotalVehicleDistance  Przyrz ąd rejestrujący nieosobowe  
ServiceComponentIdentification  Przyrz ąd rejestrujący nieosobowe  
ServiceDelayCalendarTimeBased  Przyrz ąd rejestrujący nieosobowe  
Driver1Identification  Karta kierowcy  osobowe  
Driver2Identification  Karta kierowcy  osobowe  
NextCalibrationDate  Przyrz ąd rejestrujący nieosobowe  
Driver1ContinuousDrivingTime  Karta kierowcy  osobowe  
Driver2ContinuousDrivingTime  Karta kierowcy  osobowe  
Driver1CumulativeBreakTime  Karta kierowcy  osobowe  
Driver2CumulativeBreakTime  Karta kierowcy  osobowe  
Driver1CurrentDurationOfSelectedActivity  Karta kierowcy  osobowe  
Driver2CurrentDurationOfSelectedActivity  Karta kierowcy  osobowe  
SpeedAuthorised  Przyrz ąd rejestrujący nieosobowe  
TachographCardSlot1  Karta kierowcy  nieosobowe  
TachographCardSlot2  Karta kierowcy  nieosobowe  
Driver1Name  Karta kierowcy  osobowe  
Driver2Name  Karta kierowcy  osobowe  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 463  
Dane  Źródło Klasyfikacja 
danych (osobowe/ 
nieosobowe)  
OutOfScopeCondition  Przyrz ąd rejestrujący nieosobowe  
ModeOfOperation  Przyrz ąd rejestrujący nieosobowe  
Driver1CumulatedDrivingTimePreviousAndCur ­
rentWeek  Karta kierowcy  osobowe  
Driver2CumulatedDrivingTimePreviousAndCur ­
rentWeek  Karta kierowcy  osobowe  
EngineSpeed  Przyrz ąd rejestrujący osobowe  
RegisteringMemberState  Przyrz ąd rejestrujący nieosobowe  
VehicleRegistrationNumber  Przyrz ąd rejestrujący nieosobowe  
Driver1EndOfLastDailyRestPeriod  Karta kierowcy  osobowe  
Driver2EndOfLastDailyRestPeriod  Karta kierowcy  osobowe  
Driver1EndOfLastWeeklyRestPeriod  Karta kierowcy  osobowe  
Driver2EndOfLastWeeklyRestPeriod  Karta kierowcy  osobowe  
Driver1EndOfSecondLastWeeklyRestPeriod  Karta kierowcy  osobowe  
Driver2EndOfSecondLastWeeklyRestPeriod  Karta kierowcy  osobowe  
Driver1CurrentDailyDrivingTime  Karta kierowcy  osobowe  
Driver2CurrentDailyDrivingTime  Karta kierowcy  osobowe  
Driver1CurrentWeeklyDrivingTime  Karta kierowcy  osobowe  
Driver2CurrentWeeklyDrivingTime  Karta kierowcy  osobowe  
Driver1TimeLeftUntilNewDailyRestPeriod  Karta kierowcy  osobowe  
Driver2TimeLeftUntilNewDailyRestPeriod  Karta kierowcy  osobowe  
Driver1CardExpiryDate  Karta kierowcy  osobowe  
Driver2CardExpiryDate  Karta kierowcy  osobowe  
Driver1CardNextMandatoryDownloadDate  Karta kierowcy  osobowe  
Driver2CardNextMandatoryDownloadDate  Karta kierowcy  osobowe  
TachographNextMandatoryDownloadDate  Przyrz ąd rejestrujący nieosobowe  
Driver1TimeLeftUntilNewWeeklyRestPeriod  Karta kierowcy  osobowe  
Driver2TimeLeftUntilNewWeeklyRestPeriod  Karta kierowcy  osobowe  
Driver1NumberOfTimes9hDailyDrivingTimesEx ­
ceeded  Karta kierowcy  osobowe  
Driver2NumberOfTimes9hDailyDrivingTimesEx ­
ceeced  Karta kierowcy  osobowe  ▼C2
 02016R0799 — PL — 26.02.2020 — 002.001 — 464  
Dane  Źródło Klasyfikacja 
danych (osobowe/ 
nieosobowe)  
Driver1CumulativeUninterruptedRestTime  Karta kierowcy  osobowe  
Driver2CumulativeUninterruptedRestTime  Karta kierowcy  osobowe  
Driver1MinimumDailyRest  Karta kierowcy  osobowe  
Driver2MinimumDailyRest  Karta kierowcy  osobowe  
Driver1MinimumWeeklyRest  Karta kierowcy  osobowe  
Driver2MinimumWeeklyRest  Karta kierowcy  osobowe  
Driver1MaximumDailyPeriod  Karta kierowcy  osobowe  
Driver2MaximumDailyPeriod  Karta kierowcy  osobowe  
Driver1MaximumDailyDrivingTime  Karta kierowcy  osobowe  
Driver2MaximumDailyDrivingTime  Karta kierowcy  osobowe  
Driver1NumberOfUsedReducedDailyRestPeriods  Karta kierowcy  osobowe  
Driver2NumberOfUsedReducedDailyRestPeriods  Karta kierowcy  osobowe  
Driver1RemainingCurrentDrivingTime  Karta kierowcy  osobowe  
Driver2RemainingCurrentDrivingTime  Karta kierowcy  osobowe  
GNSS position  Przyrz ąd rejestrujący osobowe  
▼B 
2) STAŁY DOST ĘP DO DANYCH GNSSPO UZYSKANIU ZGODY 
KIEROWCY  
Zobacz dodatek 12 – GNSS.  
3) KODY ZDARZE Ń DOSTĘPNE BEZ ZGODY KIEROWCY  
Zdarzenie  Zasady gromadzenia danych  Dane rejestrowane dla zdarzenia  
Włożenie karty niewa żnej — 10 ostatnich zdarze ń — data i godzina wyst ąpienia zdarzenia, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja karty powoduj ącej zdarzenie, 
— liczba podobnych zdarze ń w tym dniu.  
Konflikt kart  — 10 ostatnich zdarze ń — data i godzina rozpocz ęcia zdarzenia, 
— data i godzina zako ńczenia zdarzenia, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja obu kart powoduj ących konflikt.  
Sesja ostatniej karty nieza ­
mknięta prawidłowo — 10 ostatnich zdarze ń — data i godzina w łożenia karty, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja karty, 
— dane dotycz ące ostatniej sesji odczytane 
z karty: 
— data i godzina w łożenia karty, 
— numer VRN, pa ństwo członkowskie 
rejestracji oraz generacja VU.  ▼C2
 02016R0799 — PL — 26.02.2020 — 002.001 — 465  
Zdarzenie  Zasady gromadzenia danych  Dane rejestrowane dla zdarzenia  
Przerwa w zasilaniu (2)  — najd łuższe zdarzenie w ka żdym 
z ostatnich 10 dni ich wyst ępo­
wania, 
— 5 najd łużej trwających zdarze ń 
w ciągu ostatnich 365 dni.  — data i godzina rozpocz ęcia zdarzenia, 
— data i godzina zako ńczenia zdarzenia, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja każdej karty w łożonej na pocz ątku 
lub po zako ńczeniu zdarzenia, 
— liczba podobnych zdarze ń w tym dniu.  
Błąd łączności z urządzeniem 
do łączności na odleg łość — najdłuższe zdarzenie w ka żdym 
z ostatnich 10 dni ich wyst ępo­
wania, 
— 5 najd łużej trwających zdarze ń 
w ciągu ostatnich 365 dni.  — data i godzina rozpocz ęcia zdarzenia, 
— data i godzina zako ńczenia zdarzenia, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja każdej karty w łożonej na pocz ątku 
lub po zako ńczeniu zdarzenia, 
— liczba podobnych zdarze ń w tym dniu.  
Brak informacji o po łożeniu 
z odbiornika GNSS  — najdłuższe zdarzenie w ka żdym 
z ostatnich 10 dni ich wyst ępo­
wania, 
— 5 najd łużej trwających zdarze ń 
w ciągu ostatnich 365 dni.  — data i godzina rozpocz ęcia zdarzenia, 
— data i godzina zako ńczenia zdarzenia, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja każdej karty w łożonej na pocz ątku 
lub po zako ńczeniu 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 ostatnich 10 dni ich wyst ępo­
wania, 
— 5 najd łuższych zdarze ń w ciągu 
ostatnich 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 ostatnich 10 dni ich wyst ępo­
wania, 
— 5 najd łużej trwających zdarze ń 
w ciągu ostatnich 365 dni.  — data i godzina rozpocz ęcia zdarzenia, 
— data i godzina zako ńczenia zdarzenia, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja każdej karty w łożonej na pocz ątku 
lub po zako ńczeniu zdarzenia, 
— liczba podobnych zdarze ń w tym dniu.  
Konflikt ruchu pojazdu  — najd łuższe zdarzenie w ka żdym 
z ostatnich 10 dni ich wyst ępo­
wania, 
— 5 najd łużej trwających zdarze ń 
w ciągu ostatnich 365 dni.  — data i godzina rozpocz ęcia zdarzenia, 
— data i godzina zako ńczenia zdarzenia, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja każdej karty w łożonej na pocz ątku 
lub po zako ńczeniu zdarzenia, 
— liczba podobnych zdarze ń w tym dniu.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 466  
Zdarzenie  Zasady gromadzenia danych  Dane rejestrowane dla zdarzenia  
Próba naruszenia zabezpie ­
czenia  10 ostatnich zdarze ń wg typu zdarze ­
nia. — data i godzina rozpocz ęcia zdarzenia, 
— data i godzina zako ńczenia zdarzenia (o ile 
dotyczy), 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja każdej karty w łożonej na pocz ątku 
lub po zako ńczeniu zdarzenia, 
— typ zdarzenia.  
Konflikt czasowy  — najd łuższe zdarzenie w ka żdym 
z ostatnich 10 dni ich wyst ępo­
wania, 
— 5 najd łużej trwających zdarze ń 
w ciągu ostatnich 365 dni.  — data i godzina na urz ądzeniu rejestruj ącym, 
— data i godzina na odbiorniku GNSS, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja każdej karty w łożonej na pocz ątku 
lub po zako ńczeniu zdarzenia, 
— liczba podobnych zdarze ń w tym dniu.  
4) KODY ZDARZENIA DOST ĘPNE BEZ ZGODY KIEROWCY  
Zdarzenie  Zasady gromadzenia danych  Dane rejestrowane dla zdarzenia  
Prowadzenie bez prawid ­ 
łowej karty  — najdłuższe zdarzenie w ka żdym 
z ostatnich 10 dni ich wyst ępo­
wania, 
— 5 najd łużej trwających zdarze ń 
w ciągu ostatnich 365 dni.  — data i godzina rozpocz ęcia zdarzenia, 
— data i godzina zako ńczenia zdarzenia, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja każdej karty w łożonej na pocz ątku 
lub po zako ńczeniu zdarzenia, 
— liczba podobnych zdarze ń w tym dniu.  
Włożenie karty podczas 
prowadzenia pojazdu  — ostatnie zdarzenie dla ka żdego 
z 10 ostatnich dni od zaistnienia 
zdarzenia.  — data i godzina zdarzenia, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja karty, 
— liczba podobnych zdarze ń w tym dniu.  
Przekroczenie pr ędkości (1)  — najpowa żniejsze zdarzenie dla 
każdego z 10 ostatnich dni od 
zaistnienia zdarzenia (tzn. 
zdarzenie o najwy ższej, prze ­
ciętnej prędkości), 
— 5 najpowa żniejszych zdarze ń 
w okresie ostatnich 365 dni, 
— pierwsze zdarzenie zaistnia łe po 
ostatniej kalibracji.  — data i godzina rozpocz ęcia zdarzenia, 
— data i godzina zako ńczenia zdarzenia, 
— maksymalna pr ędkość zmierzona w czasie 
zdarzenia, 
— średnia arytmetyczna pr ędkość zmierzona 
w czasie zdarzenia, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja karty kierowcy (o ile dotyczy), 
— liczba podobnych zdarze ń w tym dniu.  
5) KODY DANYCH DOTYCZ ĄCYCH USTEREK DOST ĘPNE BEZ ZGODY 
KIEROWCY  
Usterka  Zasady gromadzenia danych  Dane rejestrowane dla usterki  
Usterka karty  — 10 ostatnich usterek karty 
kierowcy,  — data i godzina rozpocz ęcia usterki, 
— data i godzina zako ńczenia usterki, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja karty.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 467  
Usterka  Zasady gromadzenia danych  Dane rejestrowane dla usterki  
Usterki urz ądzenia rejestruj ą­
cego  — 10 ostatnich usterek dla ka żdego 
typu usterki, 
— pierwsza usterka po ostatniej 
kalibracji.  — data i godzina rozpocz ęcia usterki, 
— data i godzina zako ńczenia usterki, 
— typ usterki, 
— typ karty, numer karty i pa ństwo człon­
kowskie, które wyda ło kartę, oraz gene ­
racja każdej karty w łożonej na pocz ątku 
lub po zako ńczeniu usterki.  
Usterkę tę uruchamia dowolna z nast ępujących usterek, z wy łączeniem pracy 
w trybie kalibracyjnym:  
— usterka wewn ętrzna VU  
— 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ść 
▼M1 
— usterka interfejsu ITS (w stosownych przypadkach)  
▼B 
6) ZDARZENIA I USTERKI DOTYCZ ĄCE KONKRETNEGO PRODU ­
CENTA BEZ ZGODY KIEROWCY  
Zdarzenie lub usterka  Zasady gromadzenia danych  Dane rejestrowane dla zdarzenia  
Określi producent  Okre śli producent  Okre śli producent  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 468  
ZAŁĄCZNIK 2  
DIAGRAMY SEKWENCJI WYMIANY KOMUNIKATÓW Z URZ ĄDZENIEM ITS.  
Rys. 1  
Diagram sekwencji próby autoryzacji kodu PIN
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 469  
Rys. 2  
Diagram sekwencji weryfikacji autoryzacji urz ądzenia ITS
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 470  
Rys. 3  
Diagram sekwencji przetworzenia żądania przedstawienia danych zaklasyfikowanych jako nieosobowe (po 
poprawnym uzyskaniu dost ępu za pomoc ą kodu PIN)
  
Rys. 4  
Diagram sekwencji przetworzenia żądania przedstawienia danych zaklasyfikowanych jako osobowe (po 
poprawnym uzyskaniu dost ępu za pomoc ą kodu PIN)
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 471  
Rys. 5  
Diagram sekwencji próby autoryzacji kodu PIN
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 472  
ZAŁĄCZNIK 3  
SPECYFIKACJE ASN.1
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 473
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 474
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 475
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 476
  
► (1) M1 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 477
  
► (1) (2) (3)  M1 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 478
  
► (1) M1 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 479
  
► (1) (2) M1 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 480
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 481
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 482
  
► (1) M1 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 483
  
▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 484  
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 średnictwem inter ­ 
fejsu DSRC dzia łającego na cz ęstotliwości 5,8 GHz  
4.1.2 Profil 1a: kontrole przeprowadzane przy wykorzystaniu r ęcznego 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 ukierunkowa ­ 
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 łącznoś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 monitorowania 
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 tachografu 
(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 — 26.02.2020 — 002.001 — 485  
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 danych  
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 („rozporz ądze­
nie”).  
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 sprawdzana pod k ątem zgodno ści z odpowiednimi para ­
metrami przewidzianymi w normie 300 674-1 {Kwestie doty ­
czące kompatybilno ści elektromagnetycznej i widma radio ­
wego (ERM); telematyka transportu i ruchu drogowego 
(RTTT); dedykowana łączność krótkiego zasi ęgu (DSRC) 
utrzymywana za po średnictwem urz ądzeń transmisyjnych  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 486  
(500 kbit/s / 250 kbit/s) dzia łających na cz ęstotliwości 
5,8 GHz w pa śmie przeznaczonym do zastosowa ń przemysło­
wych, naukowych i medycznych (ISM); Cz ęść 1: Charaktery ­
styka 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ń 
bezprzewodowej łączności na odleg łość DSRC dzia łających 
na częstotliwości 5,8 GHz (zob. pkt 5.4.4), co oznacza, że 
tylko upowa żnieni pracownicy w łaściwych organów kontro ­
lnych są w stanie zrozumie ć dane przekazywane w trakcie 
utrzymywania  Łączności i są w stanie zweryfikowa ć ich auten­
tyczność. Zob. Dodatek 11 – Wspólne mechanizmy zabezpie ­
czenia.  
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 architek ­
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 przedstawiciele 
właściwych organów kontrolnych maj ą korzystać z dedykowanego 
systemu łączności bezprzewodowej DSRC dzia łającego w pa śmie ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 487  
5,8 GHz, aby zdalnie pozyskiwa ć z pojazdu docelowego dane („ Dane ”) 
wskazujące, że taki pojazd mo że potencjalnie narusza ć przepisy 
rozporządzenia (UE) nr 165/2014 i że w związku z tym nale ży rozważ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 doty ­
czyć 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 ograni ­
czony, poniewa ż łączność ma ukierunkowany charakter i cechuje si ę 
krótkim zasi ęgiem. Ponadto w łaściwe organy kontrolne mog ą korzystać 
ze środków łączności wykorzystywanych do celów zdalnego monitoro ­
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 nale ży 
stosować do celów  Łączności; 
— normy i przepisy, z którymi urz ądzenia radiowe musz ą być zgodne;  
— 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  Łączno­ 
ści; 
— dostępność Danych  dla właściwych organów kontrolnych;  
— sposób, w jaki  Czytnik wczesnego wykrywania na odleg łość moż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 przedstawi ­
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 — 26.02.2020 — 002.001 — 488  
— Przepisów w zakresie bezpiecze ństwa danych (takich jak przepisy 
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 danych 
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 definicji 
właściwych dla tego dodatku:  
Antena  urz ądzenie elektryczne przekszta ł­
cające energię elektryczn ą w fale 
radiowe i  vice versa , wykorzysty ­
wane w po łączeniu z nadajnikiem 
radiowym lub odbiornikiem radio ­
wym. W trakcie pracy nadajnik 
radiowy generuje drgania elek ­
tryczne o cz ęstotliwości fal radio ­
wych, które trafiaj ą do gniazd 
antenowych, a antena emituje 
energię pozyskiwan ą z prądu 
w formie fal elektromagnetycz ­
nych (fal radiowych). Przyjmuj ąc 
fale radiowe, antena przechwytuje 
część energii z fali elektromagne ­
tycznej 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 stosowa ­
nych w transporcie drogowym 
i uchylające rozporz ądzenie Rady 
(EWG) nr 3821/85 w sprawie  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 489  
urządzeń rejestrujących stosowa ­
nych w transporcie drogowym 
oraz zmieniaj ące rozporz ądzenie 
(WE) nr 561/2006 Parlamentu 
Europejskiego i Rady w sprawie 
harmonizacji niektórych przepisów 
socjalnych 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 prowa ­
dzenia 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 wykry ­
wania 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ść” zdefi­
niowane w za łączniku 1C  
RTM  zdalne monitorowanie tachografu  
SM-REDCR  modu ł zabezpiecze ń–czytnik 
wczesnego wykrywania na odle ­
głość 
TARV  aplikacje telematyczne dla 
pojazdów regulowanych (seria 
norm ISO 15638)  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 490  
VU przyrz ąd rejestrujący 
VUPM  pami ęć ładunku przyrz ądu rejestru ­
jącego  
VUSM  modu ł zabezpiecze ń przyrządu 
rejestrują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 wszystkich 
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 zapisy 
niniejszego dodatku s ą nadrzędne. W sytuacji wyst ąpienia jakichkolwiek 
sprzeczności, w przypadku których nie istniej ą specyfikacje wyra źnie 
określone w niniejszym dodatku, nale ży w pierwszej kolejno ści zasto­
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 12795, 
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 normy:  
[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 transporcie drogowym oraz zmieniaj ące rozporz ądzenie (WE) nr 
561/2006 Parlamentu Europejskiego i Rady w sprawie harmoni ­
zacji niektórych przepisów socjalnych odnosz ących się do trans­
portu drogowego;  
[2] rozporz ądzenie (WE) nr 561/2006 Parlamentu Europejskiego 
i Rady 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) 
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 — 26.02.2020 — 002.001 — 491  
[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 logicz ­
nym”;  
[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 drogowego 
(RTTT) – Wydzielona komunikacja krótkiego zasi ęgu – Profile 
zastosowań RTTT”;  
[10] norm ę ISO 14906 „Elektroniczny system pobierania op łat – Okre­ 
ślenie interfejsu zastosowa ń dla wydzielonej komunikacji krótkiego 
zasięgu”. 
4 SCENARIUSZE OPERACYJNE  
4.1 Informacje ogólne  
W rozporz ądzeniu (UE) nr 165/2014 wskazano konkretne i kontrolowane 
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 aktuali ­
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 — 26.02.2020 — 002.001 — 492  
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 
DSC_17 Dane zabezpieczaj ące (securityData ) 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 zabezpieczenia”, po czym 
przedstawia si ę je jako warto ść koncepcji danych w celu ich 
tymczasowego przechowania w  DSRC-VU  jako aktualn ą 
wersję SecurityData  w formie okre ślonej w sekcji 5.4.4 niniej ­
szego dodatku.  
4.1.1.6 Dane VUPM dost ępne do przekazywania za po średnictwem interfejsu 
DSRC  
DSC_18 Koncepcja danych, która musi by ć zawsze dost ępna w ramach 
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 przedstawiciel 
właściwego organu kontrolnego u żywa czytnika wczesnego wykrywania 
na odległość (bazującego na interfejsach DSRC dzia łających na cz ęstot­
liwości 5,8 GHz w ramach ERC 70-03 i sprawdzonego pod k ątem zgod­
ności z odpowiednimi parametrami przewidzianymi w normie EN 300 
674-1, jak opisano w sekcji 5) ( REDCR ) w celu zdalnego zidentyfiko ­
wania pojazdu, który mo że potencjalnie narusza ć przepisy rozporz ą­
dzenia (UE) nr 165/2014. Po zidentyfikowaniu pojazdu przedstawiciel 
właściwego organu kontrolnego przeprowadzaj ący kontrol ę 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 przewi ­
dzianymi w normie EN 300 674-1, jak opisano w sekcji 5. Zob. rys. 
14.1 (przypadek wykorzystania 1).  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 493  
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ściwego 
organu kontrolnego znajduje si ę w pojeździe będącym w ruchu i nakie ­
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 wyko ­
rzystaniu 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 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 inteligentnym 
przedstawiono na rys. 14.3.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 494  
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 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 495  
przeglądu okresowego, a producent urz ądzenia DSRC-VU 
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 — 26.02.2020 — 002.001 — 496  
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 naru ­
szenie 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ęczne, 
zamontowany w poje ździe itd.) i trybu dzia łania przyjętego przez przed ­
stawiciela w łaściwych organów kontrolnych.  
Funkcję wyświetlania lub powiadamiania wykorzystuje si ę do przedsta ­
wienia przedstawicielowi w łaściwych organów kontrolnych wyników 
funkcji łączności na odleg łość. Wyniki mog ą być wyświetlane na ekra ­
nie, w formie wydruku, sygna łu audio lub po łączenia takich powiado ­
mień. Forma takiego wy świetlenia lub powiadomienia jest kwesti ą 
wymogów przedstawicieli w łaściwych organów kontrolnych i projektu 
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 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 497  
maksymaln ą elastyczno ść rynku w zakresie zaprojektowania 
i zapewnienia urz ądzenia maj ącego na celu zrealizowanie 
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 operacji.  
Rys. 14.5  
Przepływ pracy w odniesieniu do funkcji łączności na odleg łość
 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 498  
Poszczególne kroki opisano poni żej: 
a. ilekroć pojazd jest w ruchu (w łączony zap łon), tachograf przekazuje 
dane funkcji VU. Funkcja VU przygotowuje  Dane  na potrzeby funkcji 
łączności na odleg łość (zaszyfrowane) i aktualizuje  VUPM  przecho­
wywane 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  prze­
syła się do DSRC-VU, gdzie zast ępują one wszystkie poprzednie 
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 zgroma ­
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 deszyf ­
rowanie danych;  
f. przedstawiciel w łaściwego organu kontrolnego wybiera nast ępnie 
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 prze­
kazania  Danych . Dane  są przesyłane do  REDCR  za pośrednictwem 
systemu łączności bezprzewodowej jako atrybut DSRC korzystaj ący 
z usługi aplikacyjnej GET, jak okre ślono w 5.4. Atrybut zawiera 
zaszyfrowane warto ści danych ładunku oraz dane zabezpieczaj ące 
DSCR;  
g. dane są analizowane przez urz ądzenie  REDCR  i przekazywane przed ­
stawicielowi w łaściwego organu kontrolnego;  
h. przedstawiciel w łaściwego organu kontrolnego wykorzystuje dane do 
podjęcia decyzji o ewentualnym zatrzymaniu pojazdu do szczegó łowej 
kontroli lub zwrócenia si ę do innego przedstawiciela w łaściwego 
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ęstotliwoś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 ę ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 499  
jedynie w celu przekazania odpowiednich informacji w łaści­
wemu organowi kontrolnemu, aby pomóc mu w ustaleniu, 
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 DSRC 
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 (nie ­
licencjonowanego) 
i rozporządzenia krajowego 
Maksymalna warto ść 
+ 33 dBm  (zgodnie z norm ą EN 12253)  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 500  
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 instalowanym 
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 
rozpoczę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 — 26.02.2020 — 002.001 — 501  
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 ązko­
wa. (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 pod 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 — 26.02.2020 — 002.001 — 502  
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 — 26.02.2020 — 002.001 — 503  
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 otwar­
cia. 
U13 Preambu ła Preambu ła jest obowi ązko­
wa. (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 dodat ­
kowe bity.  (zgodnie z norm ą EN 12253)  
(*) – Parametry łącza nadawczego z zastrze żeniem sprawdzenia zgodno ś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 — 26.02.2020 — 002.001 — 504  
DSC_32 Antena VU jest zamontowana na szybie przedniej pojazdu lub 
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 warun ­
kach 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 — 26.02.2020 — 002.001 — 505  
— 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 trans­
akcji.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 506  
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 — 26.02.2020 — 002.001 — 507  
— GET.request : polecenie wysy łane z  REDCR  do 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 wybrane ­
go(-ych) atrybutu(-ów) z  Danymi . Celem polecenia GET 
jest umożliwienie  REDCR  otrzymania  Danych  od 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  do 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 komuni ­
kacyjnego 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 
dotyczącym konkretnego 
EID Wysyła Atrybut (RTMData, 
OWSData….) zawieraj ący 
dane dotycz ące konkretnego 
EID ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 508  
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 — 26.02.2020 — 002.001 — 509
  
► (1) (2) (3) (4)  M1 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 510
  
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:  
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 rejes ­
tracyjna 
pojazdu  VU ustala warto ść tp15638VehicleRegistration ­
Plate  elementu danych RTM1 na podstawie 
zarejestrowanej warto ści typu danych  Vehicle­
RegistrationIdentification , jak okre ślono 
w dodatku 1  VehicleRegistrationIdentification  Numer tablicy 
rejestracyjnej 
pojazdu wyra ­ 
żony jako ci ąg 
znaków
  
RTM2 
Zdarzenia 
polegające na 
przekro­
czeniu pr ęd­
kości VU generuje warto ść logiczną w odniesieniu 
do elementu danych RTM2 tp15638Speedin ­
gEvent. 
VU oblicza warto ść tp15638SpeedingEvent na 
podstawie liczby zdarze ń przekroczenia pr ęd­
kości zarejestrowanych w VU w ci ągu ostat­
nich 10 dni wyst ępowania, jak okre ślono 
w załączniku 1C.  1 (PRAWDA) – 
wskazuje na 
nieprawidłowości 
w prędkości 
w ciągu 10 
ostatnich dni 
występowania
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 511  
(1) Element 
danych RTM  (2) Czynność wykonywana przez VU  (3)  Definicja danych w ASN.1  
Jeżeli w ostatnich 10 dniach wyst ępowania 
zarejestrowano co najmniej jedno zdarzenie 
tp15638SpeedingEvent, ustawia si ę wartość 
tp15638SpeedingEvent na PRAWDA. 
W PRZECIWNYM WYPADKU, je żeli 
w ostatnich 10 dniach wyst ępowania nie zare ­
jestrowano żadnego zdarzenia, ustawia si ę 
wartość tp15638SpeedingEvent na FA ŁSZ. 
RTM3 
Prowadzenie 
pojazdu bez 
ważnej karty  VU generuje warto ść logiczną w odniesieniu 
do elementu danych RTM3. tp15638Drivin ­
gWithoutValidCard. 
VU przypisuje warto ść PRAWDA zmiennej 
tp15638DrivingWithoutValidCard w przypadku 
zarejestrowania w danych VU w ci ągu ostat­
nich 10 dni wyst ępowania co najmniej jednego 
zdarzenia typu „Prowadzenie bez prawid łowej 
karty”, jak okre ślono w za łączniku 1C. 
W PRZECIWNYM WYPADKU, je żeli 
w ostatnich 10 dniach wyst ępowania nie zare ­
jestrowano żadnego zdarzenia, ustawia si ę 
wartość zmiennej tp15638DrivingWithoutVa ­
lidCard na FA ŁSZ. 1 (PRAWDA) = 
wskazuje na 
stosowanie 
nieważnej karty
  
RTM4 
Ważna karta 
kierowcy  VU generuje warto ść logiczną w odniesieniu 
do elementu danych RTM4 
tp15638DriverCard na podstawie danych zgro ­
madzonych w VU i okre ślonych w dodatku 1. 
W przypadku braku wa żnej karty kierowcy 
VU ustawia warto ść zmiennej na PRAWDA. 
W PRZECIWNYM WYPADKU, je żeli istnieje 
ważna karta kierowcy, VU ustawia warto ść 
zmiennej na FA ŁSZ. 0 (FAŁSZ) = 
wskazuje 
istnienie wa żnej 
karty kierowcy
  
RTM5 
Włożenie 
karty podczas 
prowadzenia 
pojazdu  VU generuje warto ść logiczną w odniesieniu 
do elementu danych RTM5. 
VU przypisuje warto ść PRAWDA zmiennej 
tp15638CardInsertion w przypadku zarejestro ­
wania w danych VU w ci ągu ostatnich 10 dni 
występowania co najmniej jednego zdarzenia 
typu „włożenie karty podczas prowadzenia 
pojazdu”, jak okre ślono w za łączniku 1C. 
W PRZECIWNYM WYPADKU, je żeli 
w ostatnich 10 dniach wyst ępowania nie zare ­
jestrowano żadnego takiego zdarzenia, ustawia 
się wartość zmiennej tp15638CardInsertion na 
FAŁSZ. 1 (PRAWDA) = 
wskazuje na 
wystąpienie 
zdarzenia polega ­
jącego na 
włożeniu karty 
podczas prowa ­
dzenia pojazdu 
w ciągu 10 
ostatnich wyst ę­
powania
  
RTM6 
Błąd danych 
dotyczących 
ruchu  VU generuje warto ść logiczną w odniesieniu 
do elementu danych RTM6. 
VU przypisuje warto ść PRAWDA zmiennej 
tp15638MotionDataError w przypadku zareje ­
strowania w danych VU w ci ągu ostatnich 
10 dni wyst ępowania co najmniej jednego 
zdarzenia typu „b łąd danych dotycz ących 
ruchu”, jak okre ślono w za łączniku 1C. 
W PRZECIWNYM WYPADKU, je żeli 
w ostatnich 10 dniach wyst ępowania nie zare ­
jestrowano żadnego takiego zdarzenia, ustawia 
się wartość zmiennej tp15638MotionDataError 
na FAŁSZ. 1 (PRAWDA) – 
wskazuje na 
wystąpienie 
zdarzenia typu 
„błąd danych 
dotyczących 
ruchu” w ci ągu 
10 ostatnich dni 
występowania
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 512  
(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 
tp15638vehicleMotionConflict w przypadku 
zarejestrowania w danych VU w ci ągu ostat­
nich 10 dni wyst ępowania co najmniej jednego 
zdarzenia typu „konflikt ruchu pojazdu” (war ­
tość ‘0A’H). 
W PRZECIWNYM WYPADKU, je żeli 
w ostatnich 10 dniach wyst ępowania nie zare ­
jestrowano żadnego zdarzenia, ustawia si ę 
wartość zmiennej tp15638vehicleMotionCon ­
flict na FA ŁSZ. 1 (PRAWDA) – 
wskazuje na 
wystąpienie 
zdarzenia typu 
„konflikt ruchu 
pojazdu” w ci ągu 
10 ostatnich dni 
występowania
  
RTM8 
Druga karta 
kierowcy  VU generuje warto ść logiczną w odniesieniu 
do elementu danych RTM8 na podstawie 
załącznika 1C („Dane dotycz ące czynno ści 
kierowcy” w odniesieniu do ZA ŁOGI 
i WSPÓŁKIEROWCY). 
W przypadku istnienia drugiej wa żnej karty 
kierowcy VU ustawia warto ść zmiennej na 
PRAWDA. 
W PRZECIWNYM WYPADKU, w przypadku 
braku drugiej wa żnej karty kierowcy VU 
ustawia warto ść zmiennej na FA ŁSZ. 1 (PRAWDA) = 
wskazuje na 
włożenie drugiej 
karty kierowcy
  
RTM9 
Bieżące dzia­ 
łania VU generuje warto ść logiczną w odniesieniu 
do elementu danych RTM9. 
Jeżeli VU zarejestruje bie żącą czynność jako 
jakąkolwiek czynno ść inną niż „PROWADZE ­
NIE”, jak okre ślono w za łączniku 1C, ustawia 
wartość zmiennej na PRAWDA. 
W PRZECIWNYM WYPADKU, je żeli VU 
zarejestruje bie żącą czynność jako „PROWA ­
DZENIE”, VU ustawia warto ść zmiennej na 
FAŁSZ. 1 (PRAWDA) = 
inna wybrana 
czynność; 
0 (FAŁSZ) = 
wybór czynno ści 
„prowadzenie”.
  
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 procedur ą opisaną 
w załączniku 1C, VU ustawia warto ść 
zmiennej na PRAWDA. 
W PRZECIWNYM WYPADKU, je żeli 
ostatnia sesja karty zosta ła prawid łowo 
zamknięta, VU ustawia warto ść zmiennej na 
FAŁSZ. 1 (PRAWDA) = 
sesja zamkni ęta 
nieprawidłowo; 
0 (FAŁSZ) = 
sesja zamkni ęta 
prawidłowo.
  
RTM11 
Przerwa 
w zasilaniu  VU generuje warto ść całkowitą dla elementu 
danych RTM11. 
VU przypisuje zmiennej tp15638PowerSupp ­
lyInterruption warto ść odpowiadaj ącą „najdłuż­
szej przerwie w zasilaniu” zgodnie z art. 9 
rozporządzenia (UE) nr 165/2014 w odniesieniu 
do zdarzenia typu „przerwa w zasilaniu”, jak 
określono w za łączniku 1C.  — Liczba 
przerw 
w zasilaniu 
w ostatnich 
10 dniach 
występowa­
nia
 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 513  
(1) Element 
danych RTM  (2) Czynność wykonywana przez VU  (3)  Definicja danych w ASN.1  
W PRZECIWNYM WYPADKU, je żeli 
w ostatnich 10 dniach wyst ępowania nie zare ­
jestrowano żadnego zdarzenia zwi ązanego 
z przerwą w zasilaniu, warto ść liczby ca łko­
witej ustawia si ę na 0.  
▼M1 
RTM12 
Usterka czuj ­
nika  VU generuje warto ść w postaci liczby ca łko­
witej w odniesieniu do elementu danych 
RTM12. 
VU przypisuje zmiennej sensorFault warto ść: 
— 1 w przypadku zarejestrowania w ci ągu 
ostatnich 10 dni zdarzenia typu „35H” 
związanego z usterk ą czujnika; 
— 2 w przypadku zarejestrowania w ci ągu 
ostatnich 10 dni typu zdarzenia zwi ąza­
nego z usterk ą odbiornika GNSS 
(wewnętrznego albo zewn ętrznego, 
o wartości enum„36”H lub „37” H); 
— 3 w przypadku zarejestrowania w ci ągu 
ostatnich 10 dni zdarzenia typu „0E”H 
związanego z b łędem łączności z urządze­
niem zewn ętrznym GNSS; 
— 4 w przypadku zarejestrowania w ci ągu 
ostatnich 10 dni zarówno usterki czujnika, 
jak i usterki odbiornika GNSS; 
— 5 w przypadku zarejestrowania w ci ągu 
ostatnich 10 dni zarówno zdarzenia typu 
usterka czujnika, jak i b łąd łączności 
z urządzeniem zewn ętrznym GNSS; 
— 6 w przypadku zarejestrowania w ci ągu 
ostatnich 10 dni zarówno zdarzenia typu 
usterka odbiornika GNSS, jaki i b łąd łącz­
ności z urządzeniem zewn ętrznym GNSS; 
— 7 w przypadku zarejestrowania w ci ągu 
ostatnich 10 dni wyst ępowania wszystkich 
trzech usterek czujnika, W PRZECIWNYM 
WYPADKU przypisuje warto ść 0, jeżeli 
w ciągu ostatnich 10 dni nie zarejestro ­
wano żadnych zdarze ń. — usterka czuj ­
nika jeden 
oktet zgodnie 
ze słownikiem 
danych
  
▼B 
RTM13 
Korekta 
czasu  VU generuje warto ść w postaci liczby ca łko­
witej (timeReal z dodatku 1) dla elementu 
danych RTM13 na podstawie obecno ści 
danych dotycz ących korekty czasu zdefiniowa ­
nych w za łączniku 1C. 
VU przypisuje warto ść czasu, w którym dosz ło 
do wystąpienia ostatniego zdarzenia polegaj ą­
cego na korekcie czasu danych. 
W PRZECIWNYM WYPADKU, je żeli 
w danych VU nie stwierdzono wyst ąpienia 
żadnego zdarzenia typu „korekta czasu” zdefi ­
niowanego w za łączniku 1C, warto ść ustala się 
na 0.  Czas ostatniej 
korekty czasu
  
RTM14 
Próba naru ­
szenia zabez ­
pieczenia  VU generuje warto ść w postaci liczby ca łko­
witej (timeReal z dodatku 1) dla elementu 
danych RTM14 na podstawie wyst ąpienia 
zdarzenia typu „próba naruszenia zabezpiecze ­
nia” zdefiniowanego w za łączniku 1C.  Czas ostatniej 
próby naruszenia 
zabezpieczenia 
— Warto ść 
domyślna = 
0x00FF
  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 514  
(1) Element 
danych RTM  (2) Czynność wykonywana przez VU  (3)  Definicja danych w ASN.1  
VU ustala warto ść czasu, w którym dosz ło do 
ostatniego zarejestrowanego przez VU 
zdarzenia zwi ązanego z prób ą naruszenia 
zabezpieczenia. 
W PRZECIWNYM WYPADKU, je żeli 
w danych VU nie stwierdzono wyst ąpienia 
żadnego zdarzenia typu „próba naruszenia 
zabezpieczenia” zdefiniowanego w za łączniku 
1C, wartość ustala się na 0x00FF.  
RTM15 
Ostatnia 
kalibracja  VU generuje warto ść w postaci liczby ca łko­
witej (timeReal z dodatku 1) dla elementu 
danych RTM15 na podstawie obecno ści 
danych dotycz ących ostatniej kalibracji zdefi ­
niowanych w za łączniku 1C. 
VU ustala warto ść czasu, w którym dokonano 
dwóch ostatnich kalibracji (RTM15 i RTM16) 
ustanowionych w VuCalibrationData zdefinio ­
wanych w dodatku 1. 
VU ustala warto ść RTM15 na timeReal zapisu 
ostatniej kalibracji.  Dane dotycz ące 
czasu ostatniej 
kalibracji
  
RTM16 
Poprzednia 
kalibracja  VU generuje warto ść w postaci liczby ca łko­
witej (timeReal z dodatku 1) dla elementu 
danych RTM16 z zapisu kalibracyjnego 
poprzedzaj ącego zapis ostatniej kalibracji. 
W PRZECIWNYM WYPADKU, je żeli 
poprzednia kalibracja nie mia ła miejsca, VU 
ustala warto ść RTM16 na 0.  Dane dotycz ące 
czasu poprzedniej 
kalibracji
  
RTM17 
Data 
podłączenia 
tachografu  Dla elementu danych RTM17 VU generuje 
wartość w postaci liczby ca łkowitej (timeReal 
z dodatku 1). 
VU ustala warto ść czasu wst ępnej instalacji 
VU. 
VU wyodr ębnia te dane z VuCalibrationData 
(dodatek 1) znajduj ących się w VuCalibration ­
Records z CalibrationPurpose równym: ‘03’H  Data podłączenia 
tachografu
  
RTM18 
Prędkość 
bieżąca VU generuje warto ść w postaci liczby ca łko­
witej w odniesieniu do elementu danych 
RTM18. 
VU ustala warto ść RTM16 na warto ść ostatniej 
zarejestrowanej pr ędkości bieżącej w chwili 
dokonania ostatniej aktualizacji RtmData.  Ostatnia zareje ­
strowana pr ęd­
kość bieżąca
 
RTM19 
Znacznik 
czasu  Dla elementu danych RTM19 VU generuje 
wartość w postaci liczby ca łkowitej (timeReal 
z dodatku 1). 
VU ustala warto ść RTM19 na czas ostatniej 
aktualizacji RtmData.  Znacznik czasu 
aktualnego 
rekordu Tacho ­
graphPayload
  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 515  
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 
rozpoczyna 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  
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  ▼M1
 02016R0799 — PL — 26.02.2020 — 002.001 — 516
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
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
 
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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 517
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
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  
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
 ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 518
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
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  
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 519  
Tabela 14.9  
Inicjacja – przyk ładowa zawarto ść ramki VST
 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
  Polecenie interfejsu u żyt­
kownika  
8 Nagłówek fragmentacji
  Brak fragmentacji  
9 VST 
SEQUENCE {
  Odpowiedź na inicjacj ę 
Wypełnienie CI ĄG BITÓW (ROZ ­
MIAR (4) )
  Niewykorzystywane 
i ustawione na 0  
10 Profil INTEGER (0..127,…) 
Aplikacje SEQUENCE OF {
  Brak rozszerzenia. Przy ­
kładowy profil 0  
11
 Brak rozszerzenia, 1 apli ­
kacja  
12 SEQUENCE {  
Wskaźnik WARIANTU
  EID występuje 
Wskaźnik WARIANTU
  Parametr wyst ępuje 
AID DSRCApplicationEntityID
  Brak rozszerzenia. AID= 
2 Freight&Fleet  
13 EID Dsrc-EID
  Zdefiniowany przez OBU 
i identyfikuj ący wystą­
pienie aplikacji.  
14 Kontener parametru {
  Brak rozszerzenia, wybór 
kontenera = 02, ci ąg okte­
towy  
15
 Brak rozszerzenia, d ługość 
znacznika kontekstowego 
RTM = 8  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 520
 Oktet # 
Atrybut/Pole  Bity w oktecie  Opis  
16 Rtm-ContextMark::= SEQUENCE 
{ 
StandardIdentifier 
standardIdentifier
  ►M1 Identyfikator 
obiektu obs ługiwanej 
normy, cz ęści i wersji. 
Przykład: ISO (1) norma 
(0) TARV (15638) cz ęść 
9 (9) wersja 1 (1). 
Wartość pierwszego 
oktetu to 06H i stanowi 
identyfikator obiektu. 
Wartość drugiego oktetu 
to 06H i stanowi jego 
długość. Kolejne 6 
oktetów koduje przyk ła­
dowy identyfikator 
obiektu. ◄ 17
 
18
 
19
 
20
 
21
 
22
 
23
 
24 ObeConfiguration Sequence {  
Wskaźnik WARIANTU
  Brak ObeStatus  
EquipmentClass INTEGER (0..32767)
  
25
 
26 ManufacturerId INTEGER (0..65535)
  Identyfikator producenta 
dla DSRC-VU opisany 
w rejestrze dotycz ącym 
normy ISO 14816  27
 
28 FCS
  Sekwencja kontroli ramki  
29
 
30 Flaga
  Flaga ko ńcowa  
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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 521  
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 (ROZ ­
MIAR (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 — 26.02.2020 — 002.001 — 522  
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 polece­
nie, 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 — 26.02.2020 — 002.001 — 523
 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 (ROZ ­
MIAR (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 — 26.02.2020 — 002.001 — 524
 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 prze ­
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 rozporządzeniu (UE) nr 165/2014 (zob. pkt 6 poni żej). ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 525  
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 — 26.02.2020 — 002.001 — 526  
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 okte ­
tów 
14
 Dane, które maj ą być 
powtórzone  
… …  
113 }}
  
114614  FCS
  Sekwencja kontroli ramki  
115715
  
116816  Flaga
  Flaga ko ńcowa  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 527  
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 (ROZ ­
MIAR (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 okte ­
tów 
14
 Powtórzone dane  
… …  
113 }}
  
114 FCS
  Sekwencja kontroli ramki  
115
 
116 Flaga
  Flaga ko ńcowa  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 528  
__________  
▼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 interfejsu 
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-VU 
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 odle­
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  
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:  ▼M2
 02016R0799 — PL — 26.02.2020 — 002.001 — 529
  
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 
odpowiedzi na żądanie zainicjowania łącza komunikacyj ­
nego. Polecenie jest wysy łane przez DSRC-VU do VU. 
Polecenie 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 — 26.02.2020 — 002.001 — 530  
—
 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 zdarze ­
nie; 
—
 
komunikat jest wysy łane przez VU do DSRC-VU w celu 
zakończenia łącza w odniesieniu do konkretnego LinkI ­
dentifier.  
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 potwier ­
dzenia żą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  
▼M1 
DSC_77 Ju ż zabezpieczone dane s ą przekazywane  DSRC-VU  za 
pomocą funkcji  VUSM . VUSM  sprawdza, czy dane zarejestro ­
wane w  DSRC-VU  zostały poprawnie zarejestrowane. Reje ­
strowanie 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 EventFaultType 
z wartością enum ustawion ą na „0C”H B łąd łączności z urzą­
dzeniem do łączności na odleg łość wraz ze znacznikiem 
czasu.  
▼B 
DSC_78  VU  zachowuje plik opatrzony unikatow ą nazwą, która jest 
łatwa do zidentyfikowania dla inspektorów w celu zarejestro ­
wania „usterek łączności wewnętrznej VU”.  
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  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 531  
odległość wraz ze znacznikiem czasu. B łąd związany z łączno­ 
ścią zostaje wykryty w przypadku nieotrzymania 
komunikatu
  dotycz ącego powi ąza­
nego (tj. z tym samym DataTransactionId w komuni- 
katach
  ) 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 powi ą­
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 dodat ­
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 jest 
zatem ustalenie ró żnicy między „niepowodzeniem odczytu” a „b łędem”. 
Podczas transakcji zachodz ącej przez interfejs bezprzewodowy niepowo ­
dzenie odczytu jest zjawiskiem powszechnym, a jego skutkiem jest 
zwykle ponowienie próby, tj. reemisja BST i ponowna próba sekwencji, 
które w wi ększości przypadków doprowadz ą do skutecznego nawi ązania 
łączności i przesłania danych, chyba że docelowy pojazd wyjedzie poza 
zasięg urządzenia w czasie wymaganym do przeprowadzenia ponownej 
transmisji. (Przypadek „skutecznego odczytu” mo że obejmowa ć kilka 
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 fizyczn ą 
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 bezprzewo ­
dowej lub mo że być spowodowane zak łóceniem radarowym lub trud ­
nymi warunkami atmosferycznymi (np. w trakcie burzy); lub po prostu 
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 dlatego, 
że nie dosz ło do nawi ązania łączności. 
Jeżeli przedstawiciel w łaściwego organu kontrolnego wybiera pojazd 
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 przed ­
stawiciel w łaściwego organu kontrolnego potrzebuje środka, aby móc 
wprowadzi ć usterkę do rejestru i ostrzec wspó łpracowników znajduj ą­
cych się na dalszym etapie łańcucha o mo żliwym naruszeniu. Wspó ł­
pracownicy mog ą wówczas zatrzyma ć pojazd i przeprowadzi ć kontrolę 
fizyczną. W związku z tym, że nie nawi ązano łączności, DSRC-VU nie 
może jednak dostarczy ć danych dotycz ących usterki. Przekazywanie 
tego rodzaju sprawozda ń powinno by ć zatem funkcj ą projektu urz ą­
dzenia REDCR.  
„Niepowodzenie odczytu” ró żni się pod względem technicznym od „b łę­
du”. W tym kontek ście „błąd” oznacza pozyskanie b łędnej warto ści. ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 532  
Dane przes łane do  DSRC-VU  są dostarczane w postaci ju ż zabezpieczo ­
nej, dlatego musz ą zostać zweryfikowane przez dostawc ę danych (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ą poprawne. 
Jeżeli dane nie zostan ą zatwierdzone w ramach CRC, oznacza to retrans ­
misję danych. Prawdopodobie ństwo, że niepoprawne dane pomy ślnie 
przejdą CRC, jest statystycznie na tyle znikome, że można je pomin ąć. 
Jeżeli dane nie zostan ą zatwierdzone w ramach CRC i nie ma czasu na 
retransmisj ę i otrzymanie poprawnych danych, wówczas rezultatem nie 
będzie błąd, lecz wyst ąpienie okre ślonego typu niepowodzenia odczytu.  
Jedyne znacz ące dane na temat „usterki”, które mo żna zarejestrowa ć, 
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ę przypad­
kó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 oprogramo ­
wania 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 funkcji 
łączności na odleg łość: 
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.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 533  
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 zaini ­
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 DSRC 
(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 ą do 
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 — 26.02.2020 — 002.001 — 534  
Dodatek 15  
MIGRACJA: ZARZ ĄDZANIE WSPÓ ŁISTNIENIEM GENERACJI 
URZĄDZEŃ 
SPIS TRE ŚCI 
1. DEFINICJE  
2. PRZEPISY OGÓLNE  
2.1. Informacje ogólne na temat przej ścia 
2.2. Interoperacyjno ść między VU a kartami  
2.3. Interoperacyjno ść między VU a czujnikami ruchu  
2.4. Interoperacyjno ść między przyrz ądami rejestruj ącymi, 
kartami do tachografu i urz ądzeniami s łużącymi do pobie ­ 
rania 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 ą­ 
cego  
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 POPRZEDZA ­ 
JĄCYM DAT Ę WPROWADZENIA  
4. PRZEPISY DOTYCZ ĄCE OKRESU PO DACIE WPRO ­ 
WADZENIA  
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 łącz­
niku (rozdzia ł 1: definicja ccc));  
inteligentne urz ądzenie dedykowane (IDE) : urządzenie służące do 
przeprowadzania operacji pobierania danych, zgodnie z definicj ą zawartą 
w dodatku 7 do niniejszego za łącznika.  
2. PRZEPISY OGÓLNE  
2.1. Informacje ogólne na temat przej ścia 
Preambuła do niniejszego za łącznika zawiera informacje ogólne na temat 
przejścia od stosowania systemów tachografów pierwszej generacji do 
stosowania systemów tachografów drugiej generacji.  
W uzupełnieniu postanowie ń niniejszej preambu ły: 
— czujniki ruchu pierwszej generacji nie b ędą interoperacyjne z przy ­
rządami rejestruj ącymi drugiej generacji;  
— instalacja czujników ruchu drugiej generacji rozpocznie si ę w tym 
samym czasie co instalacja przyrz ądów rejestruj ących drugiej gene ­
racji; ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 535  
— urządzenia do pobierania i kalibracji danych b ędą musiały ewoluo­
wać, aby mogły obsługiwać urządzenia rejestruj ące i karty do tacho ­
grafu obu generacji.  
2.2. Interoperacyjno ść między VU a kartami  
▼M1 
Przyjmuje si ę, że karty do tachografu pierwszej generacji s ą interopera ­
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 drugiej generacji s ą interoperacyjne z przyrz ądami rejestruj ą­
cymi drugiej generacji zgodnie z za łącznikiem IC do niniejszego 
rozporządzenia. Ponadto zastosowanie maj ą przedstawione poni żej 
wymogi.  
▼B 
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 przyrządach 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 drugiej generacji 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 rejestru ­
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 stanie 
obsługiwać wyłącznie karty warsztatowe drugiej generacji.  
MIG_005 Do celów okre ślania trybu pracy przyrz ądy rejestruj ące 
drugiej generacji rozpoznaj ą wyłącznie typy w łożonych 
ważnych kart, bez wzgl ędu na ich generacj ę. 
MIG_006 Ka żda ważna karta do tachografu 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 ą interoperacyjne 
z przyrządami rejestruj ącymi pierwszej generacji, natomiast czujniki 
ruchu drugiej generacji s ą interoperacyjne z przyrz ądami rejestruj ącymi 
drugiej generacji. Ponadto zastosowanie maj ą przedstawione poni żej 
wymogi.  
MIG_007 Przyrz ądów rejestruj ących drugiej generacji nie b ędzie 
można parowa ć ani używać z czujnikami ruchu pierwszej 
generacji.  
MIG_008 Czujniki ruchu drugiej generacji mo żna parowa ć i używać 
wyłącznie z przyrz ądami rejestruj ącymi drugiej generacji 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 służące do pobierania danych mog ą być używane 
tylko z jedn ą generacją przyrządów rejestruj ących i kart do 
tachografu b ądź z obiema generacjami.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 536  
2.4.1  Bezpo średnie pobieranie danych z karty przez inteligentne urz ądzenia 
dedykowane  
MIG_010 Inteligentne urz ądzenia dedykowane pobieraj ą dane z kart 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.  
MIG_011 Aby organy kontrolne spoza UE mog ły kontrolowa ć kierow­
ców, należy umożliwić pobieranie danych z kart kierowców 
(i kart warsztatowych) drugiej generacji 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:  
▼M1 
— niepodpisane pliki elementarne IC i ICC (fakultatywnie),  
▼B 
— niepodpisane pliki elementarne (pierwszej generacji)
  
i
 ,  
▼M1 
— pliki elementarne zawieraj ące inne dane aplikacyjne 
(w pliku DF Tachograph) żądane przez protokó ł pobie­
rania danych z kart pierwszej generacji. Informacje takie 
są zabezpieczone podpisem cyfrowym zgodnie z mecha ­
nizmami 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 warsztatowych) 
drugiej generacji (pliki elementarne zawieraj ące dane aplika ­
cyjne w pliku DF Tachograph_G2).  
▼B 
2.4.2  Pobieranie danych z karty za pomoc ą przyrządu rejestruj ącego  
MIG_012 Dane z karty drugiej generacji w łożonej do przyrz ądu rejes­
trującego pierwszej generacji s ą pobierane za pomoc ą proto­
kołu pobierania danych pierwszej generacji. Karta taka odpo ­
wiada 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 
rejestrującego 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 pole­
cenia 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.  
2.4.3  Pobieranie danych z przyrz ądów rejestruj ących 
▼M1 
MIG_014 Poza ramami kontroli kierowców przez organ kontrolny 
spoza 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.  
MIG_015 Aby organy kontrolne spoza UE mog ły kontrolowa ć kierow­
ców, opcjonalnie mo żna równie ż umożliwić pobieranie 
danych z przyrz ądów rejestruj ących drugiej generacji z zasto ­
sowaniem mechanizmów zabezpieczenia pierwszej generacji. 
Pobierane dane maj ą wtedy taki sam format jak dane pobie ­
rane z przyrz ądu rejestruj ącego pierwszej generacji. Funkcj ę 
tę można wybrać za pomoc ą poleceń w menu.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 537  
2.5. Interoperacyjno ść między VU a urz ądzeniami do kalibracji  
MIG_016 Urz ądzenia do kalibracji musz ą być w stanie przeprowadza ć 
kalibrację tachografów ka żdej generacji, z zastosowaniem 
protokołu kalibracyjnego danej generacji. Urz ądzenia do 
kalibracji mog ą być używane tylko z jedn ą generacją tacho­
grafów bądź z obiema generacjami.  
3. GŁÓWNE DZIA ŁANIA W OKRESIE POPRZEDZAJ ĄCYM DAT Ę 
WPROWADZENIA  
MIG_017 Klucze testowe i certyfikaty musz ą zostać udostępnione 
producentom najpó źniej 30 miesi ęcy przed datą wprowadze ­
nia. 
MIG_018 Badania interoperacyjno ści muszą być gotowe do 
rozpoczęcia na wniosek producentów najpó źniej 15 miesi ęcy 
przed datą wprowadzenia.  
MIG_019 Oficjalne klucze i certyfikaty musz ą zostać udostępnione 
producentom najpó źniej 12 miesi ęcy przed datą wprowadze ­
nia. 
MIG_020 Pa ństwa członkowskie musz ą być w stanie rozpocz ąć wyda­
wanie kart warsztatowych drugiej generacji najpó źniej 3 
miesiące przed dat ą wprowadzenia.  
MIG_021 Pa ństwa członkowskie musz ą być w stanie rozpocz ąć wyda­
wanie wszystkich typów kart do tachografu drugiej generacji 
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 drugiej generacji.  
MIG_023 Producenci przyrz ądów rejestruj ących / czujników ruchu 
mogą produkowa ć przyrząd 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.  
MIG_024 Producenci przyrz ądów rejestruj ących / czujników ruchu 
mogą ubiegać się o utrzymanie homologacji typu przyrz ądów 
rejestrujących / czujników ruchu pierwszej generacji, które 
mają już homologacj ę typu, oraz uzyska ć zgodę na takie 
utrzymanie.  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 538  
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 — 26.02.2020 — 002.001 — 539  
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 prze ­
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 adapterem 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 ędko­ 
ś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 zgodnie 
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 jaki 
należy rozumieć wymagania niniejszego za łącznika w przypadku zastoso ­
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 rejestru ­
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 — 26.02.2020 — 002.001 — 540  
— 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 sparowanie 
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 ęstotliwoś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.  
ADA_012 Interfejs wej ściowy adaptera musi w stosownych przypadkach 
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 
(4 000 do 25 000 impulsów/km). Warto ść stałej może zapro­
gramować wyłącznie producent adaptera lub zatwierdzony 
warsztat instaluj ący adapter.  
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 czujnika 
ruchu do identyfikacji adaptera [95].  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 541  
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 tempe ­
ratur określonym przez producenta.  
ADA_021 Adapter musi realizowa ć wszystkie funkcje w zakresie wilgot ­
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 regulaminu 
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 — 26.02.2020 — 002.001 — 542  
— 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 dosto ­
sować interfejs wej ściowy oraz wybra ć podzielnik wej ścio­
wego sygna łu (w stosownych przypadkach).  
ADA_031 Taki zatwierdzony warsztat instaluj ący adapter musi zaplom ­
bować jego obudow ę. 
ADA_032 Adapter montuje si ę jak najbli żej tej części pojazdu, która jest 
źródłem impulsów wej ściowych.  
ADA_033 Przewody zasilaj ące adapter musz ą być czerwone (plus zasila ­
nia) 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 ą nienaru­
szone;  ▼B
 02016R0799 — PL — 26.02.2020 — 002.001 — 543  
— 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 typu 
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 adaptera. 
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 rejestru ­
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 wymaga ­
nia 
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 — 26.02.2020 — 002.001 — 544  
Nr Badanie  Wyszczególnienie  Odpowiednie wymaga ­
nia 
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 — 26.02.2020 — 002.001 — 545  
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 homologacj ę, 
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 homologacji 
wydanego dla prototypu urz ądzenia rejestruj ącego lub wykresówki, b ądź 
karty do tachografu, umieszczonemu bezpo średnio obok tego prostok ąta. ▼C1
 02016R0799 — PL — 26.02.2020 — 002.001 — 546  
2. Znak homologacji umieszcza si ę na tabliczce znamionowej ka żdego urzą­
dzenia oraz na ka żdej wykresówce i na ka żdej karcie do tachografu. 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 ę proporcje 
między wymiarami.
  ▼C1 
( 1 ) Dane podane orientacyjnie.
 02016R0799 — PL — 26.02.2020 — 002.001 — 547  
II. ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW 
ANALOGOWYCH  
Państwo członkowskie, które udzieli ło homologacji, wystawia wnioskodawcy 
świadectwo homologacji, którego wzór przedstawiono poni żej. Informuj ąc inne 
państwa członkowskie o wydanej lub ewentualnie cofni ętej homologacji, 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 przeznaczona 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 — 26.02.2020 — 002.001 — 548  
III. ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW 
CYFROWYCH  
Państwo członkowskie, które udzieli ło homologacji, wystawia wnioskodawcy 
świadectwo homologacji, którego wzór przedstawiono poni żej. Informuj ąc inne 
państwa członkowskie o wydanej lub ewentualnie cofni ętej homologacji, 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 — 26.02.2020 — 002.001 — 549  
IV. ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW 
INTELIGENTNYCH  
Państwo członkowskie, które udzieli ło homologacji, wystawia wnioskodawcy 
świadectwo homologacji, którego wzór przedstawiono poni żej. Informuj ąc inne 
państwa członkowskie o wydanej lub ewentualnie cofni ętej homologacji, 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 funkcjonalno ści 
b) Laboratorium badawcze na potrzeby certyfikacji bezpiecze ństwa 
c) Laboratorium badawcze na potrzeby certyfikacji interoperacyjno ś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.