EUR-Lex Document 02016R0799-20230821

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
►M3 Rozporządzenie wykonawcze Komisji (UE) 2021/1228 z dnia 16 lipca
2021 r.
L 273 1 30.7.2021
►M4 Rozporządzenie wykonawcze Komisji (UE) 2023/980 z dnia 16 maja
2023 r.
L 134 28 22.5.2023
sprostowane przez:
►C1 Sprostowanie, Dz.U. L 146 z 3.6.2016, s. 31 (2016/799)
►C2 Sprostowanie, Dz.U. L 27 z 1.2.2017, s. 169 (2016/799)
02016R0799 — PL — 21.08.2023 — 003.002 — 1
02016R0799 — PL — 21.08.2023 — 003.002 — 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 — 21.08.2023 — 003.002 — 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 rozpo­
rządzenia;
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 rozmieszczonych
w pojeździe, składających się z jednostki przetwarzającej, pamięci
danych, funkcji pomiaru czasu, dwóch czytników kart inteligentnych
(dla kierowcy i współkierowcy), drukarki, wyświetlacza, złącz i urządzeń
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 4
do wprowadzania danych przez użytkownika, odbiornika GNSS i urzą­
dzenia do łączności na odległość.
Przyrząd rejestrujący może się składać z następujących elementów
składowych podlegających homologacji typu:
— urządzenie rejestrujące jako jeden element składowy (obejmu­
jący odbiornik GNSS i urządzenie do łączności na odległość),
— jednostka główna przyrządu rejestrującego (obejmująca urzą­
dzenie do łączności na odległość) i urządzenie zewnętrzne
GNSS,
— jednostka główna przyrządu rejestrującego (obejmująca
odbiornik GNSS) i zewnętrzne urządzenie do łączności na odle­
głość,
— jednostka główna przyrządu rejestrującego, urządzenie
zewnętrzne GNSS i zewnętrzne urządzenie do łączności na
odległość.
Jeżeli przyrząd rejestrujący składa się z kilku jednostek 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
informacji.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 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 — 21.08.2023 — 003.002 — 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 — 21.08.2023 — 003.002 — 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
▼M3
3.6.4 Wprowadzanie operacji załadunku/rozładunku
▼B
3.7 Zarządzanie blokadami firmowymi
3.8 Monitorowanie czynności kontrolnych
3.9 Wykrywanie zdarzeń lub usterek
3.9.1 Zdarzenie „włożenie nieważnej karty”
3.9.2 Zdarzenie „konflikt kart”
3.9.3 Zdarzenie „nakładające się czasy”
3.9.4 Zdarzenie „prowadzenie pojazdu bez prawidłowej karty”
3.9.5 Zdarzenie „włożenie karty podczas prowadzenia pojazdu”
3.9.6 Zdarzenie „Sesja ostatniej karty niezamknięta prawidłowo”
3.9.7 Zdarzenie „przekroczenie prędkości”
3.9.8 Zdarzenie „przerwa w zasilaniu”
3.9.9 Zdarzenie „błąd połączenia z urządzeniem do łączności na odległość”
3.9.10 Zdarzenie „brak informacji o pozycji z odbiornika GNSS”
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 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”
▼M3
3.9.18 Zdarzenie „anomalia GNSS”
▼B
3.10 Testy wbudowane i autotesty
3.11 Odczyt z pamięci danych
3.12 Rejestracja i przechowywanie w pamięci danych
3.12.1 Dane identyfikujące sprzęt
3.12.1.1 Dane identyfikujące przyrząd rejestrujący
3.12.1.2 Dane identyfikujące czujnik ruchu
3.12.1.3 Dane identyfikujące globalnego systemu nawigacji 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
▼M3
3.12.17 Przekroczenia granicy
3.12.18 Operacje załadunku/rozładunku
3.12.19 Mapa cyfrowa
▼B
3.13 Odczyt kart do tachografów
3.14 Rejestrowanie i przechowywanie danych na kartach do tacho­
grafów
3.14.1 Rejestrowanie i przechowywanie danych na kartach do tacho­
grafów pierwszej generacji
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 9
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
3.15.2 Wyświetlanie ostrzeżeń
3.15.3 Dostęp do menu
3.15.4 Inne wyświetlane informacje
3.16 Drukowanie
3.17 Ostrzeżenia
3.18 Pobieranie danych na nośnik zewnętrzny
3.19 Łączność na odległość na potrzeby ukierunkowanych kontroli
drogowych
▼M3
3.20 Wymiana danych z dodatkowymi urządzeniami zewnętrznymi
▼B
3.21 Kalibracja
3.22 Kontrola drogowa kalibracji
3.23 Korekta czasu
3.24 Parametry pracy
3.25 Materiały
3.26 Oznakowania
▼M3
3.27 Monitorowanie przekroczeń granicy
3.28 Aktualizacja oprogramowania
▼B
4 WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE KART
DO TACHOGRAFÓW
4.1 Dane widzialne
4.2 Zabezpieczenia
4.3 Normy
4.4 Wymagania środowiskowe i elektryczne
4.5 Przechowywanie danych
4.5.1 Pliki elementarne do identyfikacji i zarządzania kartą
4.5.2 Identyfikacja kart mikroprocesorowych
4.5.2.1 Identyfikacja mikroprocesora
4.5.2.2 DIR (tylko w kartach do tachografów drugiej generacji)
4.5.2.3 Informacje ATR (warunkowe, dostępne tylko w kartach do tacho­
grafów drugiej generacji)
4.5.2.4 Informacje o rozszerzonej długości (warunkowe, dostępne tylko
w kartach do tachografów drugiej generacji)
4.5.3 Karta kierowcy
4.5.3.1 Aplikacja tachograficzna (dostępna dla przyrządów 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
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 10
4.5.3.1.5 Pobieranie danych z karty
4.5.3.1.6 Dane dotyczące prawa jazdy
4.5.3.1.7 Dane dotyczące zdarzeń
4.5.3.1.8 Dane dotyczące usterek
4.5.3.1.9 Dane dotyczące czynności kierowcy
4.5.3.1.10 Dane dotyczące używanych pojazdów
4.5.3.1.11 Miejsca rozpoczęcia lub zakończenia dziennych okresów pracy
4.5.3.1.12 Dane sesji karty
4.5.3.1.13 Dane dotyczące czynności kontrolnych
4.5.3.1.14 Dane dotyczące warunków szczególnych
4.5.3.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów
rejestrujących pierwszej generacji)
4.5.3.2.1 Identyfikacja aplikacji
▼M3
4.5.3.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
▼B
4.5.3.2.2 Klucze i certyfikaty
4.5.3.2.3 Identyfikacja karty
4.5.3.2.4 Identyfikacja posiadacza karty
4.5.3.2.5 Pobieranie danych z karty
4.5.3.2.6 Dane dotyczące prawa jazdy
4.5.3.2.7 Dane dotyczące zdarzeń
4.5.3.2.8 Dane dotyczące usterek
4.5.3.2.9 Dane dotyczące czynności kierowcy
4.5.3.2.10 Dane dotyczące używanych pojazdów
4.5.3.2.11 Miejsca i pozycje rozpoczęcia lub zakończenia 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
▼M3
4.5.3.2.17 Status uwierzytelniania dla pozycji związanych z miejscami rozpo­
częcia lub zakończenia dziennych okresów pracy (brak dostępu
w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.3.2.18 Status uwierzytelniania dla pozycji, w których osiągnięto trzy
godziny skumulowanego czasu prowadzenia pojazdu (brak dostępu
w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.3.2.19 Przekroczenia granicy (brak dostępu w przypadku wersji 1 drugiej
generacji przyrządów rejestrujących)
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 11
4.5.3.2.20 Operacje załadunku/rozładunku (brak dostępu w przypadku wersji
1 drugiej generacji przyrządów rejestrujących)
4.5.3.2.21 Wprowadzanie typu załadunku (brak dostępu w przypadku wersji 1
drugiej generacji przyrządów rejestrujących)
4.5.3.2.22 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
▼B
4.5.4 Karta warsztatowa
4.5.4.1 Aplikacja tachograficzna (dostępna dla przyrządów 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
4.5.4.1.13 Dane dotyczące warunków szczególnych
4.5.4.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów
rejestrujących pierwszej generacji)
4.5.4.2.1 Identyfikacja aplikacji
▼M3
4.5.4.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
▼B
4.5.4.2.2 Klucze i certyfikaty
4.5.4.2.3 Identyfikacja karty
4.5.4.2.4 Identyfikacja posiadacza karty
4.5.4.2.5 Pobieranie danych z karty
4.5.4.2.6 Dane dotyczące kalibracji i korekty czasu
4.5.4.2.7 Dane dotyczące zdarzeń i usterek
4.5.4.2.8 Dane dotyczące czynności kierowcy
4.5.4.2.9 Dane dotyczące używanych pojazdów
4.5.4.2.10 Dane dotyczące rozpoczęcia lub zakończenia dziennych okresów
pracy
4.5.4.2.11 Dane sesji karty
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 12
4.5.4.2.12 Dane dotyczące czynności kontrolnych
4.5.4.2.13 Dane dotyczące używanych przyrządów rejestrujących
▼M1
4.5.4.2.14 Dane miejsc, w których minęły trzy godziny skumulowanego czasu
prowadzenia pojazdu
▼B
4.5.4.2.15 Dane dotyczące warunków szczególnych
▼M3
4.5.4.2.16 Status uwierzytelniania dla pozycji związanych z miejscami rozpo­
częcia lub zakończenia dziennych okresów pracy (brak dostępu
w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.4.2.17 Status uwierzytelniania dla pozycji, w których osiągnięto trzy
godziny skumulowanego prowadzenia pojazdu (brak dostępu
w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.4.2.18 Przekroczenia granicy (brak dostępu w przypadku wersji 1 drugiej
generacji przyrządów rejestrujących)
4.5.4.2.19 Operacje załadunku/rozładunku (brak dostępu w przypadku wersji
1 drugiej generacji przyrządów rejestrujących)
4.5.4.2.20 Wprowadzanie typu załadunku (brak dostępu w przypadku wersji 1
drugiej generacji przyrządów rejestrujących)
4.5.4.2.21 Dodatkowe dane dotyczące kalibracji (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.4.2.22 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
▼B
4.5.5 Karta kontrolna
4.5.5.1 Aplikacja tachograficzna (dostępna dla przyrządów 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
▼M3
4.5.5.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
▼B
4.5.5.2.2 Klucze i certyfikaty
4.5.5.2.3 Identyfikacja karty
4.5.5.2.4 Identyfikacja posiadacza karty
4.5.5.2.5 Dane dotyczące czynności kontrolnych
▼M3
4.5.5.2.6 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
▼B
4.5.6 Karta firmowa
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 13
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
4.5.6.1.4 Identyfikacja posiadacza karty
4.5.6.1.5 Dane dotyczące czynności wykonywanych przez firmę
4.5.6.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów
rejestrujących pierwszej generacji)
4.5.6.2.1 Identyfikacja aplikacji
▼M3
4.5.6.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
▼B
4.5.6.2.2 Klucze i certyfikaty
4.5.6.2.3 Identyfikacja karty
4.5.6.2.4 Identyfikacja posiadacza karty
4.5.6.2.5 Dane dotyczące czynności wykonywanych przez firmę
▼M3
4.5.6.2.6 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
▼B
5 INSTALACJA URZĄDZENIA REJESTRUJĄCEGO
5.1 Instalacja
5.2 Tabliczka instalacyjna
5.3 Plombowanie
6 KONTROLE, PRZEGLĄDY I NAPRAWY
6.1 Zatwierdzanie instalatorów, warsztatów i producentów pojazdów
▼M1
6.2 Kontrola techniczna elementów składowych nowych i po 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
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 14
WPROWADZENIE
Niniejszy załącznik zawiera wymogi dotyczące drugiej generacji urządzeń rejes­
trujących i kart do tachografów.
Począwszy od dnia 15 czerwca 2019 r., w pojazdach rejestrowanych po raz
pierwszy w Unii instaluje się urządzenia rejestrujące drugiej generacji i wydaje
się karty do tachografów drugiej generacji.
W celu sprawnego wdrożenia systemu tachografu drugiej generacji, karty do
tachografu drugiej generacji zaprojektowano w taki sposób, aby możliwe było
ich używanie również w przyrządach rejestrujących pierwszej generacji skon­
struowanych zgodnie z załącznikiem IB do rozporządzenia (EWG) nr 3821/85.
Analogicznie karty do tachografu pierwszej generacji mogą być używane w przy­
rządach rejestrujących drugiej generacji. Przyrządy rejestrujące drugiej generacji
mogą być kalibrowane tylko z użyciem kart warsztatowych drugiej generacji.
Wymogi dotyczące interoperacyjności między systemami tachografu pierwszej
i drugiej generacji określono w niniejszym załączniku. W tym względzie dodatek
15 zawiera dodatkowe szczegółowe informacje na temat zarządzania kwestią
współistnienia obu tych generacji.
Ponadto, w związku z wdrożeniem nowych funkcji, takich jak stosowanie uwie­
rzytelniania komunikatów nawigacyjnych w ramach sygnałów otwartych Galileo,
wykrywanie przekroczeń granicy, wpisywanie operacji załadunku i rozładunku,
a także ze względu na konieczność zwiększenia pojemności karty kierowcy
do 56 dni czynności kierowcy, niniejsze rozporządzenie wprowadza wymogi
techniczne dotyczące drugiej wersji drugiej generacji urządzeń rejestrujących
i kart do tachografów.
▼B
Wykaz dodatków
Dodatek 1: SPIS DANYCH
Dodatek 2: SPECYFIKACJA KART DO TACHOGRAFÓW
Dodatek 3: PIKTOGRAMY
Dodatek 4: WYDRUKI
Dodatek 5: WYŚWIETLACZ
Dodatek 6: PRZEDNIE ZŁĄCZE KALIBRACJI I POBIERANIA
DANYCH
Dodatek 7: PROTOKOŁY POBIERANIA DANYCH
Dodatek 8: PROTOKÓŁ KALIBRACJI
Dodatek 9: HOMOLOGACJA TYPU I WYKAZ MINIMUM WYMA­
GANYCH BADAŃ
Dodatek 10: WYMOGI BEZPIECZEŃSTWA
Dodatek 11: WSPÓLNE MECHANIZMY ZABEZPIECZENIA
Dodatek 12: OKREŚLANIE POŁOŻENIA Z WYKORZYSTANIEM
GLOBALNEGO SYSTEMU NAWIGACJI SATELI­
TARNEJ (GNSS)
Dodatek 13: INTERFEJS ITS
Dodatek 14: FUNKCJA ŁĄCZNOŚCI NA ODLEGŁOŚĆ
Dodatek 15: MIGRACJA: ZARZĄDZANIE WSPÓŁISTNIENIEM
GENERACJI URZĄDZEŃ
Dodatek 16: ADAPTER DO POJAZDÓW KATEGORII M1 I N1
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 15
1 DEFINICJE
W niniejszym załączniku:
a) „aktywacja” oznacza:
fazę, gdy tachograf uzyskuje pełną funkcjonalność i uruchamia
wszystkie funkcje, łącznie z funkcjami zabezpieczającymi,
z wykorzystaniem karty warsztatowej;
b) „uwierzytelnienie”oznacza:
funkcję służącą ustanowieniu i kontroli tożsamości;
c) „autentyczność”oznacza:
właściwość polegającą na tym, że informacje przychodzą od
strony, której tożsamość można zweryfikować;
d) „test wbudowany (BIT)”oznacza:
testy wykonywane na żądanie, uruchamiane przez operatora
lub urządzenia zewnętrzne;
e) „dzień kalendarzowy” oznacza:
dzień zaczynający się o godzinie 00:00 i kończący o godzinie
24:00. Wszystkie dni kalendarzowe odnoszą się do czasu UTC
(uniwersalny czas koordynowany);
▼M3
f) „kalibracja tachografu inteligentnego” oznacza:
aktualizację lub potwierdzenie parametrów pojazdu przecho­
wywanych w pamięci danych. Parametry pojazdu obejmują
identyfikację pojazdu (numery VIN, VRN i kod rejestrującego
państwa członkowskiego) i charakterystyki pojazdu (w, k, l,
wielkość opon, ustawienia urządzenia ograniczenia prędkości
(w stosownych przypadkach), bieżący czas UTC, bieżący stan
licznika kilometrów, domyślny typ załadunku); podczas kalib­
racji urządzenia rejestrującego w pamięci danych zachowy­
wane są również rodzaje i identyfikatory odpowiednich
plomb homologacyjnych;
aktualizację lub potwierdzenie jedynie czasu UTC uważa się
za korektę czasu, a nie za kalibrację, pod warunkiem że nie
jest to sprzeczne z wymogiem 409 określonym w pkt 6.4;
do kalibracji urządzenia rejestrującego potrzebna jest karta
warsztatowa;
g) „numer karty” oznacza:
numer składający się z 16 znaków alfanumerycznych, który
jednoznacznie identyfikuje kartę do tachografów w państwie
członkowskim. Numer karty zawiera identyfikację, która
polega na identyfikacji kierowcy lub identyfikacji właściciela
karty wraz z kolejnym numerem karty, numerem wymiany
karty i numerem odnowienia karty;
tym samym karta jest jednoznacznie zidentyfikowana przez
kod państwa członkowskiego wydającego i numer karty;
▼B
h) „numer kolejny karty”oznacza:
14. znak alfanumeryczny w numerze karty, który umożliwia
rozróżnianie różnych kart firmie, warsztatowi lub organowi
kontrolnemu uprawnionym do otrzymania kilku kart do tacho­
grafów. Firmę, warsztat lub organ kontrolny jednoznacznie
identyfikuje pierwszych 13 znaków numeru karty;
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 16
i) „numer odnowienia karty” oznacza:
16. znak alfanumeryczny w numerze karty, który jest zmie­
niany przyrostowo za każdym razem, gdy odnawiana jest karta
do tachografu odpowiadająca danej identyfikacji, tj. identyfi­
kacji kierowcy lub identyfikacji właściciela wraz z kolejnym
numerem karty;
j) „numer wymiany karty” oznacza:
15. znak alfanumeryczny w numerze karty, który jest zmieniany
przyrostowo za każdym razem, gdy wymieniana jest karta do
tachografu odpowiadająca danej identyfikacji, tj. identyfikacji
kierowcy lub identyfikacji właściciela wraz z kolejnym numerem
karty;
▼B
k) „współczynnik charakterystyczny pojazdu”oznacza:
wielkość liczbową określającą wartość sygnału dostarczanego
przez część pojazdu podłączoną do urządzenia rejestrującego
(wał główny skrzyni biegów lub oś) w czasie, gdy pojazd
przebywa drogę o długości jednego kilometra mierzoną
w normalnych warunkach testowych, zgodnie z definicją
w wymaganiu 414. Współczynnik charakterystyczny pojazdu
podaje się w impulsach na kilometr (w =… imp/km);
l) „karta firmowa” oznacza:
kartę do tachografu wydaną przez organy państwa członkow­
skiego przedsiębiorstwu transportowemu używającemu
pojazdów wyposażonych w tachografy, która identyfikuje to
przedsiębiorstwo transportowe i pozwala na wyświetlanie,
pobieranie i drukowanie danych zapisanych w tachografie,
który został zabezpieczony blokadą przez to przedsiębiorstwo
transportowe;
m) „stała urządzenia rejestrującego” oznacza:
wielkość liczbową określającą wartość sygnału wejściowego
wymaganą do wskazania i rejestracji przebytej odległości
jednego kilometra; stała ta jest wyrażona w impulsach na
kilometr (k =…imp/km);
n) „nieprzerwany czas prowadzenia pojazdu” obliczany jest przez
urządzenie rejestrujące w następujący sposób ( 1 ):
nieprzerwany czas prowadzenia pojazdu obliczany jest jako
bieżące, skumulowane czasy prowadzenia pojazdu przez
danego kierowcę od końca jego ostatniego 45-minutowego
lub dłuższego okresu GOTOWOŚCI lub PRZERWY/ODPO­
CZYNKU lub NIEOKREŚLONEGO ( 2 ) (okres ten może być
rozbity zgodnie z rozporządzeniem (WE) nr 561/2006 Parla­
mentu Europejskiego i Rady ( 3 )). W obliczeniach uwzględnia
się, stosownie do okoliczności, wcześniejsze czynności zapi­
sane na karcie kierowcy. Jeżeli kierowca nie włoży swojej
karty, obliczenia wykonuje się na podstawie znajdujących się
w pamięci danych zapisów dla bieżącego okresu, w którym
nie było włożonej karty, i dla stosownego czytnika;
▼M3
( 1 ) Ten sposób obliczania nieprzerwanego czasu prowadzenia 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 — 21.08.2023 — 003.002 — 17
o) „karta kontrolna” oznacza:
kartę do tachografu wydaną krajowemu właściwemu organowi
kontrolnemu przez organy państwa członkowskiego, która
identyfikuje organ kontrolny i fakultatywnie funkcjonariusza
służb kontrolnych oraz umożliwia dostęp do danych zapisa­
nych w pamięci danych lub na kartach kierowcy i fakulta­
tywnie na kartach warsztatowych w celu odczytu, wydruku
lub pobrania danych;
Daje ona również dostęp do funkcji kontroli drogowej kalib­
racji oraz do danych na czytniku wczesnego wykrywania na
odległość.
p) „skumulowany czas przerwy” obliczany jest przez urządzenie
rejestrujące w następujący sposób ( 1 ):
skumulowany czas przerwy w prowadzeniu pojazdu obliczany
jest jako bieżące, zakumulowane, 15-minutowe lub dłuższe
okresy GOTOWOŚCI lub PRZERWY/ODPOCZYNKU lub
NIEOKREŚLONE ( 2 ) dla danego kierowcy, od końca jego
ostatniego 45-minutowego lub dłuższego okresu GOTO­
WOŚCI lub PRZERWY/ODPOCZYNKU lub NIEOKREŚLO­
NEGO ( 2 ) (okres ten może być rozbity zgodnie z rozporządze­
niem (WE) nr 561/2006).
W obliczeniach uwzględnia się, stosownie do okoliczności,
wcześniejsze czynności zapisane na karcie kierowcy. Do obli­
czeń nie bierze się nieokreślonych okresów o ujemnym czasie
trwania (początek nieokreślonego okresu > koniec nieokreślo­
nego okresu) wynikłych z nakładania się czasów z dwóch
różnych urządzeń rejestrujących.
Jeżeli kierowca nie włoży swojej karty, obliczenia wykonuje
się na podstawie znajdujących się w pamięci danych zapisów
dla bieżącego okresu, w którym nie było włożonej karty, i dla
stosownego czytnika.
q) „pamięć danych” oznacza:
elektroniczne urządzenie przechowywania danych wbudowane
w urządzenie rejestrujące;
r) „podpis cyfrowy” oznacza:
dane dołączone do bloku danych lub kryptograficzne prze­
kształcenie bloku danych, które umożliwiają odbiorcy bloku
danych potwierdzenie autentyczności oraz integralności
danego bloku danych;
s) „pobieranie” oznacza:
kopiowanie, wraz z podpisem cyfrowym, części lub komplet­
nego zestawu pliku danych zapisanych w pamięci danych
przyrządu rejestrującego lub w pamięci karty do tachografu,
pod warunkiem że proces ten nie zmienia ani nie usuwa
żadnych zapisanych danych;
▼B
( 1 ) Ten sposób obliczania nieprzerwanego czasu prowadzenia 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.
02016R0799 — PL — 21.08.2023 — 003.002 — 18
Producenci przyrządów rejestrujących tachografów inteligent­
nych oraz producenci urządzeń skonstruowanych i przeznaczo­
nych do pobierania zbiorów danych podejmują wszelkie racjo­
nalne działania zapewniające pobieranie takich danych przez
przedsiębiorstwa transportowe lub kierowców z minimalnym
opóźnieniem.
Pobieranie danych z pliku zawierającego dane szczegółowe
dotyczące prędkości nie jest konieczne do celów zgodności
z rozporządzeniem (WE) nr 561/2006, ale może być wyko­
rzystane do innych celów, takich jak dochodzenie w sprawie
wypadku;
t) „karta kierowcy” oznacza:
kartę do tachografu, która identyfikuje kierowcę i umożliwia
przechowywanie danych dotyczących czynności kierowcy,
wydaną konkretnemu kierowcy przez organy państwa człon­
kowskiego;
u) „obwód toczny kół” oznacza:
wartość średnią długości drogi przebytej przez każde z kół
(napędowych) poruszającego się pojazdu podczas jednego
pełnego obrotu. Pomiar tych długości drogi jest wykonywany
w normalnych warunkach testowych zgodnie z definicją
w wymaganiu 414 i wyrażony jest w postaci „l = … mm”.
Producenci pojazdów mogą zastąpić pomiar odległości obli­
czeniem teoretycznym, w którym uwzględnia się rozkład
ciężaru na osie dla pojazdu bez obciążenia w stanie gotowym
do jazdy ( 1 ). Metody takiego obliczenia teoretycznego podle­
gają zatwierdzeniu przez właściwy organ państwa członkow­
skiego i mogą mieć miejsce tylko przed aktywacją tachografu;
v) „zdarzenie” oznacza:
odbiegające od normy działanie wykryte przez tachograf inte­
ligentny, które może być spowodowane próbą oszustwa;
w) „urządzenie zewnętrzne GNSS” oznacza:
urządzenie, które zawiera odbiornik GNSS, jeżeli przyrząd
rejestrujący nie jest pojedynczą jednostką oraz inne elementy
niezbędne do ochrony przekazywania danych dotyczących
pozycji do pozostałej części przyrządu rejestrującego;
x) „usterka” oznacza:
odbiegające od normy działanie wykryte przez tachograf inte­
ligentny, które może być spowodowane wadliwą pracą lub
awarią urządzeń;
y) „odbiornik GNSS” oznacza:
urządzenie elektroniczne, które odbiera i cyfrowo przetwarza
sygnały z co najmniej jednego globalnego systemu nawigacji
satelitarnej (ang. GNSS) w celu uzyskania informacji o pozycji,
prędkości i czasie.
▼B
( 1 ) Rozporządzenie Komisji (UE) nr 1230/2012 z dnia 12 grudnia 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 — 21.08.2023 — 003.002 — 19
z) „instalacja” oznacza:
montaż tachografu w pojeździe;
aa) „interoperacyjność” oznacza:
zdolność systemów oraz będących ich podstawą procesów
gospodarczych do wymiany danych oraz do wymiany
informacji;
bb) „interfejs” oznacza:
połączenie między systemami, które zapewnia mechanizmy, za
których pośrednictwem systemy te mogą się łączyć i wchodzić
w interakcję;
cc) „pozycja” oznacza:
współrzędne geograficzne pojazdu w danym momencie;
dd) „czujnik ruchu” oznacza:
część tachografu dostarczającą sygnał odzwierciedlający pręd­
kość pojazdu lub przebytą drogę;
▼M3
ee) „karta nieważna” oznacza:
kartę wykrytą jako wadliwa lub kartę, której uwierzytelnienie
nie jest możliwe lub której okres ważności jeszcze się nie
rozpoczął lub już upłynął;
przyrząd rejestrujący uznaje również kartę za nieważną:
— jeżeli karta z tym samym państwem członkowskim wyda­
jącym kartę, taką samą identyfikacją, tj. identyfikacją
kierowcy lub identyfikacją właściciela wraz z kolejnym
numerem karty, oraz z wyższym numerem odnowienia
została już wprowadzona do przyrządu rejestrującego, lub
— jeżeli karta z tym samym państwem członkowskim wyda­
jącym kartę, taką samą identyfikacją, tj. identyfikacją
kierowcy lub identyfikacją właściciela wraz z kolejnym
numerem karty i numerem odnowienia, ale z wyższym
numerem wymiany, została już wprowadzona do przyrządu
rejestrującego;
▼B
ff) „otwarty standard” oznacza:
standard określony w dokumencie specyfikacji standardów
dostępnym bezpłatnie lub za symboliczną opłatą, który może
być kopiowany, rozpowszechniany lub wykorzystywany
bezpłatnie lub za symboliczną opłatą;
gg) „poza zakresem” oznacza:
że zgodnie z przepisami rozporządzenia (WE) nr 561/2006
użycie urządzenia rejestrującego nie jest wymagane;
hh) „przekroczenie prędkości” oznacza:
przekroczenie dozwolonej prędkości pojazdu definiowane jako
dowolny przynajmniej 60-sekundowy okres, w którym zmie­
rzona prędkość pojazdu przekracza wartość ograniczenia dla
urządzenia ograniczenia prędkości ustanowioną w dyrektywie
Rady 92/6/EWG z dnia 10 lutego 1992 r. w sprawie monto­
wania i zastosowania urządzeń ograniczenia prędkości
w niektórych kategoriach pojazdów silnikowych we Wspól­
nocie ( 1 ), z późniejszymi zmianami;
▼B
( 1 ) Dyrektywa Rady 92/6/EWG z dnia 10 lutego 1992 r. w sprawie 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 — 21.08.2023 — 003.002 — 20
ii) „przegląd okresowy”oznacza:
zespół czynności wykonywanych w celu sprawdzenia, czy
tachograf pracuje prawidłowo, czy jego ustawienia odpowia­
dają parametrom pojazdu i czy do tachografu nie podłączono
urządzeń manipulacyjnych;
jj) „drukarka” oznacza:
element składowy urządzenia rejestrującego wykonujący
wydruki danych zapisanych w pamięci;
kk) „wczesne wykrywanie na odległość” oznacza:
łączność między urządzeniem wczesnego wykrywania na odle­
głość a czytnikiem wczesnego wykrywania na odległość
podczas ukierunkowanych kontroli drogowych, mającą na
celu zdalne wykrycie ewentualnych manipulacji lub niewłaści­
wego użycia urządzenia rejestrującego;
▼M3
ll) „urządzenie do łączności na odległość”, „moduł komunikacji
na odległość” lub „urządzenie wczesnego wykrywania na odle­
głość” oznacza:
wyposażenie przyrządu rejestrującego, które jest używane do
przeprowadzania ukierunkowanych kontroli drogowych;
▼B
mm) „czytnik wczesnego wykrywania na odległość” oznacza:
system stosowany przez funkcjonariuszy służb kontrolnych do
ukierunkowanych kontroli drogowych;
▼M3
nn) „odnowienie karty” oznacza:
wydanie nowej karty do tachografu po upływie terminu
ważności dotychczasowej karty lub w przypadku nieprawidło­
wego działania karty i zwrócenia jej organowi wydającemu
kartę;
▼B
oo) „naprawa” oznacza:
każdą naprawę czujnika ruchu lub przyrządu rejestrującego lub
przewodu, wymagającą odłączenia zasilania lub odłączenia od
innych elementów składowych tachografu lub otwarcia czuj­
nika ruchu lub przyrządu rejestrującego;
▼M3
pp) „wymiana karty” oznacza:
wydanie nowej karty do tachografu w celu zastąpienia dotych­
czasowej karty, której utratę, kradzież lub wadliwe działanie
zgłoszono i której nie zwrócono organowi, który wydał kartę;
▼B
qq) „certyfikacja bezpieczeństwa” oznacza:
procedurę polegającą na potwierdzeniu przez jednostkę certy­
fikującą wspólnych kryteriów, że badane urządzenie rejestru­
jące (lub jego element składowy) lub karta do tachografu speł­
niają wymogi bezpieczeństwa określone w odpowiednich
profilach zabezpieczenia;
rr) „autotest” oznacza:
testy wykonywane okresowo i automatycznie przez urządzenie
rejestrujące w celu wykrycia usterek;
ss) „pomiar czasu” oznacza:
trwały cyfrowy zapis uniwersalnej daty koordynowanej
i uniwersalnego czasu koordynowanego (UTC);
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 21
tt) „korekta czasu” oznacza:
korektę bieżącego czasu; może ona być automatyczna z wyko­
rzystaniem czasu podawanego przez odbiornik GNSS jako
odniesienia lub wykonywana w trybie kalibracyjnym;
▼B
uu) „rozmiar opon” oznacza:
oznaczenie wymiarów opon (na zewnętrznych kołach napędo­
wych) zgodne z dyrektywą Rady 92/23/EWG z dnia 31 marca
1992 r. ( 1 ) z późniejszymi zmianami;
vv) „identyfikacja pojazdu” oznacza:
numery identyfikujące pojazd: numer rejestracyjny pojazdu
(VRN) z oznaczeniem państwa członkowskiego rejestracji
i numer identyfikacyjny pojazdu (VIN) ( 2 );
ww) na potrzeby obliczeniowe w urządzeniu rejestrującym
„tydzień”oznacza:
okres między godziną 00.00 UTC w poniedziałek a 24.00
UTC w niedzielę;
xx) „karta warsztatowa” oznacza:
kartę do tachografu wydaną przez organy państwa członkow­
skiego wyznaczonemu personelowi producenta tachografu,
instalatorowi, producentowi pojazdu lub warsztatowi zatwier­
dzonemu przez to państwo członkowskie, która identyfikuje
posiadacza karty i umożliwia testowanie, kalibrację i aktywację
tachografów lub pobieranie z nich danych;
yy) „adapter” oznacza:
urządzenie dostarczające sygnał w sposób ciągły odwzorowu­
jący prędkość pojazdu lub przebytą drogę, inne niż urządzenie
stosowane do niezależnego wykrywania ruchu, oraz:
▼M3
— które jest zainstalowane i stosowane wyłącznie w pojazdach
kategorii M1 i N1, określonych w art. 4 rozporządzenia
Parlamentu Europejskiego i Rady (UE) 2018/858 ( 3 ),
▼B
— które jest zainstalowane w miejscu, w którym z mechanicz­
nego punktu widzenia niemożliwy jest montaż stosowa­
nych czujników ruchu innego rodzaju, pod innym
względem zgodnych z wymaganiami przedstawionymi
w niniejszym załączniku i w dodatkach 1–15 do niniej­
szego załącznika,
▼M3
( 1 ) Dyrektywa Rady 92/23/EWG z dnia 31 marca 1992 r. odnosząca się do opon pojazdów
silnikowych i ich przyczep oraz ich instalowania (Dz.U. L 129 z 14.5.1992, s. 95).
( 2 ) Dyrektywa Rady z dnia 18 grudnia 1975 r. w sprawie zbliżania ustawodawstw Państw
Członkowskich odnoszących się do tabliczek znamionowych i 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).
( 3 ) Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2018/858 z dnia 30 maja 2018 r.
w sprawie homologacji i nadzoru rynku pojazdów silnikowych i ich przyczep oraz
układów, komponentów i oddzielnych zespołów technicznych przeznaczonych do tych
pojazdów, zmieniające rozporządzenie (WE) nr 715/2007 i (WE) nr 595/2009 oraz
uchylające dyrektywę 2007/46/WE (Dz.U. L 151 z 14.6.2018, s. 1).
02016R0799 — PL — 21.08.2023 — 003.002 — 22
— które jest zainstalowane między przyrządem rejestrującym
a miejscem, gdzie generowane są impulsy prędkości/drogi
przez zintegrowane czujniki lub alternatywne interfejsy,
— z punktu widzenia przyrządu rejestrującego zachowanie
adaptera jest takie samo jak czujnika ruchu zgodnego
z wymaganiami w niniejszym załączniku i w dodatkach
1–16 do niniejszego załącznika, w przypadku podłączenia
go do przyrządu rejestrującego;
zastosowanie takiego adaptera w wymienionych wyżej pojaz­
dach musi umożliwiać montaż i poprawne zastosowanie przy­
rządu rejestrującego, zgodnego ze wszystkimi wymaganiami
niniejszego załącznika,
w przypadku tych pojazdów tachograf inteligentny obejmuje
przewody, adapter i przyrząd rejestrujący;
zz) „integralność danych” oznacza:
dokładność i spójność przechowywanych danych, których
potwierdzeniem jest brak jakichkolwiek zmian w danych między
dwoma aktualizacjami rekordu danych. Integralność oznacza, że
dane są dokładną kopią wersji oryginalnej, np. że nie zostały znie­
kształcone w trakcie zapisu na karcie do tachografu lub urzą­
dzeniu dedykowanym lub w trakcie odczytu z nich lub w trakcie
transmisji za pośrednictwem dowolnego kanału komunikacji;
▼M3
aaa) zarezerwowane dla przyszłego użytku;
▼B
bbb) „system tachografu inteligentnego” oznacza:
urządzenia rejestrujące, karty do tachografów oraz zestaw
wszelkich urządzeń współdziałających bezpośrednio lub
pośrednio podczas ich budowy, instalacji, użytkowania, testo­
wania i kontroli, takich jak karty, czytniki na odległość
i wszelkie inne urządzenia do pobierania danych, analizy
danych, kalibracji, generowania i wprowadzania elementów
zabezpieczeń lub zarządzania tymi elementami itp.;
▼M3
ccc) „data wprowadzenia” oznacza:
datę określoną w rozporządzeniu (UE) nr 165/2014, od której
pojazdy zarejestrowane po raz pierwszy są wyposażone
w tachograf zgodnie z niniejszym rozporządzeniem.
▼B
ddd) „profil zabezpieczenia” oznacza:
dokument używany w ramach procesu certyfikacyjnego zgodnie
ze wspólnymi kryteriami, który określa niezależne od wdrożenia
specyfikacje wymogów bezpieczeństwa w zakresie zabezpie­
czania informacji;
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 23
eee) dokładność GNSS:
w zapisywaniu pozycji z globalnego systemu nawigacji sateli­
tarnej (GNSS) z użyciem tachografów, oznacza wartość Hori­
zontal Dilution of Precision (HDOP) obliczaną jako najniższa
z wartości HDOP pobranych z dostępnych systemów GNSS ;
▼M1
(fff) „skumulowany czas prowadzenia pojazdu” oznacza:
wartość odpowiadającą łącznej skumulowanej liczbie minut
prowadzenia danego pojazdu.
Wartość skumulowanego czasu prowadzenia pojazdu to
nieprzerwana liczba wszystkich minut uznanych przez funkcję
monitorowania czynności prowadzenia pojazdu urządzenia
rejestrującego za PROWADZENIE POJAZDU i jest wykorzy­
stywana wyłącznie do uruchomienia rejestracji pozycji pojazdu
za każdym razem, gdy upłynie wielokrotność trzech godzin
skumulowanego czasu prowadzenia pojazdu. Skumulowany
czas zaczyna biec w momencie uruchomienia urządzenia rejes­
trującego. Nie mają na niego wpływu jakiekolwiek inne
warunki, np. poza zakresem lub przeprawa promowa/przejazd
kolejowy.
Nie przewiduje się wyświetlania, drukowania lub pobierania
skumulowanego czasu prowadzenia pojazdu.
▼B
2 CHARAKTERYSTYKA OGÓLNA I FUNKCJE URZĄDZEŃ
REJESTRUJĄCYCH
2.1 Charakterystyka ogólna
Celem urządzenia rejestrującego jest rejestrowanie, przechowy­
wanie, wyświetlanie, drukowanie i wyprowadzanie danych związa­
nych z czynnościami kierowcy.
Pojazd wyposażony w urządzenie rejestrujące spełniające wyma­
gania niniejszego załącznika musi mieć prędkościomierz i 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 wczes­
nego wykrywania na odległość, jak określono w dodatku 14.
▼M3
05) Przyrząd rejestrujący musi obejmować interfejs ITS, który
został określony w dodatku 13.
Urządzenie rejestrujące może być podłączone do innych
urządzeń poprzez dodatkowe interfejsy lub poprzez interfejs
ITS.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 24
06) Zawarcie w urządzeniu rejestrującym lub przyłączenie do
niego jakiejkolwiek funkcji, urządzenia lub urządzeń,
zatwierdzonych lub nie, nie może zakłócać, ani potencjalnie
zakłócać, prawidłowego i bezpiecznego działania urzą­
dzenia rejestrującego ani uchybiać przepisom niniejszego
rozporządzenia.
Użytkowników urządzenia rejestrującego identyfikują
w sprzęcie ich karty do tachografów.
07) Urządzenie rejestrujące zapewnia selektywne prawa dostępu
do danych i funkcji zależnie od rodzaju lub tożsamości
użytkownika.
Urządzenie rejestrujące rejestruje i przechowuje dane w pamięci
danych, w urządzeniu do łączności na odległość i na kartach do
tachografów.
▼M3
Odbywa się to zgodnie z mającymi zastosowanie przepisami Unii
dotyczącymi ochrony danych oraz zgodnie z art. 7 rozporzą­
dzenia (UE) nr 165/2014.
▼B
2.2 Funkcje
08) Urządzenie rejestrujące realizuje następujące funkcje:
— monitorowanie wkładania i wyjmowania kart,
— pomiar prędkości, odległości i pozycji,
— pomiar czasu,
— monitorowanie czynności kierowcy,
— monitorowanie stanu prowadzenia pojazdu,
▼M3
— dane wprowadzane ręcznie przez kierowcę:
— wprowadzanie miejsc rozpoczęcia lub zakończenia
dziennych okresów pracy,
— ręczne wprowadzanie czynności kierowcy i zgody
kierowcy na interfejs ITS,
— wprowadzanie stanów szczególnych,
— wprowadzanie operacji załadunku/rozładunku,
▼B
— zarządzanie blokadami firmowymi,
— monitorowanie czynności kontrolnych,
— wykrywanie zdarzeń lub usterek,
— testy wbudowane i autotesty,
— odczyt z pamięci danych,
— rejestrowanie i przechowywanie w pamięci danych,
— odczyt z kart do tachografów,
— rejestrowanie i przechowywanie na kartach do tacho­
grafów,
— wyświetlanie,
— drukowanie,
— ostrzeganie,
— pobieranie danych na nośniki zewnętrzne,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 25
— łączność na odległość na potrzeby ukierunkowanych
kontroli drogowych,
— wyprowadzanie danych do dodatkowych urządzeń,
— kalibracja,
— kontrola drogowa kalibracji,
— korekta czasu,
▼M3
— monitorowanie przekroczeń granicy,
— aktualizacja oprogramowania.
▼B
2.3 Tryby pracy
09) Urządzenie rejestrujące może pracować w czterech trybach
pracy:
— tryb eksploatacyjny,
— tryb kontrolny,
— tryb kalibracyjny,
— tryb firmowy.
10) Urządzenie rejestrujące przełącza się do następujących
trybów pracy zależnie od rodzaju ważnej karty do tacho­
grafów włożonej do czytników kart. Do określenia trybu
pracy nie jest istotna generacja karty do tachografu, pod
warunkiem że włożona karta jest ważna. Karta warsztatowa
pierwszej generacji będzie zawsze uznawana za nieważną,
jeżeli zostanie włożona do przyrządu rejestracyjnego
drugiej generacji.
Tryb pracy
Czytnik karty kierowcy
Brak karty Karta kierowcy Karta kontrolna Karta warsztatowa Karta firmowa
C
zy
tn
ik
k
ar
ty
w
sp
ół
ki
er
ow
cy

Brak karty eksploatacyjny eksploatacyjny kontrolny kalibracyjny firmowy
Karta kierowcy eksploatacyjny eksploatacyjny kontrolny kalibracyjny firmowy
Karta kontrolna kontrolny kontrolny kontrolny (*) eksploatacyjny eksploatacyjny
Karta warsz­
tatowa
kalibracyjny kalibracyjny eksploatacyjny kalibracyjny (*) eksploatacyjny
Karta firmowa firmowy firmowy eksploatacyjny eksploatacyjny firmowy (*)
(*) W tych sytuacjach urządzenie rejestrujące korzysta tylko z karty do tachografów w czytniku kierowcy.
11) Urządzenie rejestrujące ignoruje włożone karty nieważne,
z wyjątkiem tego, że możliwe jest wyświetlanie, druko­
wanie lub pobieranie danych zgromadzonych na kartach,
których termin ważności minął.
12) Wszystkie funkcje wymienione w 2.2. działają w każdym
trybie pracy z następującymi wyjątkami:
— funkcja kalibracji dostępna jest tylko w trybie
kalibracyjnym,
— funkcja kontroli drogowej kalibracji dostępna jest tylko
w trybie kontrolnym,
— funkcja zarządzania blokadami firmowymi dostępna jest
tylko w trybie firmowym,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 26
— funkcja monitorowania czynności kontrolnych dostępna
jest tylko w trybie kontrolnym,
▼M3
— funkcja pobierania danych nie jest dostępna w trybie
eksploatacyjnym, z wyjątkiem:
a) funkcji przewidzianej w wymogu 193;
b) pobierania danych z karty kierowcy, gdy żadna inna
karta nie jest włożona do przyrządu rejestrującego.
▼B
13) Urządzenie rejestrujące może wyprowadzać dane na
wyświetlacz, do drukarki lub interfejsów zewnętrznych
z następującymi wyjątkami:
— w trybie eksploatacyjnym wszystkie dane identyfikujące
osoby (nazwisko i imię/imiona) nieodpowiadające
włożonej karcie do tachografu są wygaszone, a numer
karty nieodpowiadający włożonej karcie do tachografu
jest częściowo wygaszony (wszystkie nieparzyste znaki
od lewej do prawej są wygaszone),
▼M3
— w trybie firmowym, dane dotyczące kierowcy (wymogi
102, 105, 108, 133a i 133e) mogą być wyprowadzane
tylko dla okresów, w których nie ma żadnej blokady ani
żadna inna firma nie założyła blokady (określona pierw­
szymi 13 cyframi numeru karty firmowej),
▼B
— przy braku karty w czytniku urządzenia rejestrującego
dane dotyczące kierowcy mogą być wyprowadzane
tylko dla bieżącego dnia kalendarzowego i 8 poprzed­
nich dni kalendarzowych,
▼M3
— dane osobowe zarejestrowane i wytworzone przez
tachograf lub karty do tachografu nie są generowane
przez interfejs ITS przyrządu rejestrującego, chyba że
zweryfikowano zgodę kierowcy, którego dane dotyczą.
▼M1
— normalny okres ważności operacji przyrządów rejestru­
jących wynosi 15 lat, począwszy od daty wejścia
w życie świadectwa przyrządu rejestrującego, ale przy­
rządy rejestrujące mogą być wykorzystywane przez
kolejne 3 miesiące wyłącznie do pobierania danych.
▼B
2.4 Zabezpieczenia
▼M1
Celem zabezpieczenia systemu jest taka ochrona pamięci danych, by
uniemożliwić nieautoryzowany dostęp i manipulowanie danymi oraz
wykrycie wszelkich takich prób, ochrona integralności i 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
02016R0799 — PL — 21.08.2023 — 003.002 — 27
14) W celu osiągnięcia bezpieczeństwa systemu, następujące
elementy składowe muszą spełniać wymogi bezpieczeństwa
określone w ich profilach zabezpieczenia, zgodnie z wyma­
ganiami w dodatku 10:
— przyrząd rejestrujący,
— karta do tachografu,
— czujnik ruchu,
▼M3
— urządzenie zewnętrzne GNSS (profil ten jest tylko
konieczny i stosowany do wariantu urządzenia
zewnętrznego GNSS).
▼B
3 WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE URZĄ­
DZEŃ REJESTRUJĄCYCH
3.1 Monitorowanie wkładania i wyjmowania kart
15) Urządzenie rejestrujące monitoruje czytniki kart w celu
wykrycia wkładania i wyjmowania kart.
▼M3
16) Po włożeniu karty (lub zdalnym uwierzytelnieniu karty)
urządzenie rejestrujące wykrywa, czy karta jest ważną
kartą do tachografu zgodnie z definicją w lit. ee) w sekcji
1, i w takim przypadku identyfikuje typ karty i generację
karty.
W celu sprawdzenia, czy karta została już włożona, urzą­
dzenie rejestrujące wykorzystuje dane karty do tachografu
zapisane w jego pamięci danych, jak określono w wymogu
133.
▼B
17) Karty do tachografu pierwszej generacji są uznawane przez
urządzenie rejestrujące za nieważne, po tym jak możliwość
korzystania z kart do tachografu pierwszej generacji została
wyłączona przez warsztat, zgodnie z dodatkiem 15 (wym.
MIG003).
18) Karty warsztatowe pierwszej generacji wkładane do urzą­
dzeń rejestrujących drugiej generacji są uznawane za
nieważne.
19) Urządzenie rejestrujące musi być skonstruowane tak, aby
po prawidłowym włożeniu do czytnika kart do tachografów
były one blokowane we właściwej pozycji.
▼M3
20) wyjmowanie kart do tachografów jest możliwe tylko przy
zatrzymanym pojeździe i po zapisaniu odpowiednich
danych na kartach. Wyjęcie karty wymaga wykonania
przez użytkownika odpowiedniej czynności.
▼B
3.2 Pomiar prędkości, pozycji i odległości
21) Czujnik ruchu (ewentualnie wbudowany w adapter) jest
głównym źródłem pomiaru prędkości i odległości.
22) Funkcja ta nieprzerwanie mierzy i dostarcza wartość stanu
licznika kilometrów odpowiadającą całkowitej drodze prze­
bytej przez pojazd za pomocą impulsów przekazywanych
przez czujnik ruchu.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 28
23) Funkcja ta nieprzerwanie mierzy i dostarcza wartość pręd­
kości pojazdu za pomocą impulsów przekazywanych przez
czujnik ruchu.
24) Funkcja pomiaru prędkości podaje także informacje o tym,
czy pojazd porusza się, czy stoi. Uznaje się, że pojazd
porusza się, gdy funkcja ta wykrywa więcej niż 1 impuls
na sekundę z czujnika ruchu przez co najmniej 5 sekund,
w przeciwnym razie uważa się, że pojazd stoi.
25) Urządzenia do pokazywania prędkości (prędkościomierz)
i łącznej drogi przebytej (licznik kilometrów) zainstalowane
w pojeździe wyposażonym w urządzenie rejestrujące, speł­
niające wymagania niniejszego rozporządzenia, spełniają
wymagania odnośnie do maksymalnych tolerancji (zob.
3.2.1 i 3.2.2) określone w niniejszym załączniku.
▼M3
26) W celu wykrycia manipulowania danymi dotyczącymi
ruchu informacje z czujnika ruchu są potwierdzane przez
informacje dotyczące ruchu pojazdu pochodzące z odbior­
nika GNSS i z innych źródeł niezależnych od czujnika
ruchu. Co najmniej jeszcze jedno niezależne źródło ruchu
pojazdu musi znajdować się wewnątrz przyrządu rejestrują­
cego bez konieczności korzystania z interfejsu zewnętrz­
nego.
27) Funkcja ta mierzy pozycję pojazdu w celu umożliwienia
rejestracji:
— pozycji, w których kierowca lub współkierowca rozpo­
czynają dzienny okres pracy;
— pozycji, w których skumulowany czas prowadzenia
pojazdu osiągnie wielokrotność trzech godzin;
— pozycji, w których pojazd przekroczył granicę krajową;
— pozycji, w których przeprowadzono operacje załadunku/
rozładunku;
— pozycji, w których kierowca lub współkierowca kończą
dzienny okres pracy.
▼B
3.2.1 Pomiar przebytej drogi
28) Długość przebytej drogi może być mierzona, gdy pojazd
porusza się:
— do przodu i do tyłu, albo
— tylko do przodu.
29) Urządzenie rejestrujące mierzy odległość w zakresie
0–9 999 999,9 km.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 29
30) Pomiar odległości jest wykonywany z następującą dokład­
nością (odległości co najmniej 1 000 m):
— ± 1 % przed instalacją,
— ± 2 % po instalacji i przeglądzie okresowym,
— ± 4 % podczas eksploatacji.
▼M3
Tolerancji nie można wykorzystywać do celowej zmiany
zmierzonej odległości.
▼B
31) Pomiar odległości jest wykonywany z rozdzielczością co
najmniej 0,1 km lub większą.
3.2.2 Pomiar prędkości
32) Urządzenie rejestrujące mierzy prędkość w zakresie od 0 do
220 km/h.
▼M3
33) W celu zapewnienia maksymalnej tolerancji wskazywanej
prędkości ± 6 km/h podczas eksploatacji i uwzględniając:
— tolerancję ± 2 km/h na zmiany sygnału wejściowego
(zmiany opon, …),
— tolerancję ± 1 km/h dla pomiarów wykonywanych
w czasie instalacji lub przeglądów okresowych,
urządzenie rejestrujące, dla zakresu prędkości między 20
a 180 km/h i dla współczynników charakterystycznych
pojazdu między 2 400 a 25 000 impulsów na km, mierzy
prędkość z dokładnością ± 1 km/h (przy stałej prędkości).
Uwaga: Rozdzielczość przechowywania danych wprowadza
dodatkową tolerancję ± 0,5 km/h do prędkości zapisanej
przez urządzenie rejestrujące.
▼B
34) Prędkość jest mierzona prawidłowo w zakresie normalnych
tolerancji w czasie nie dłuższym niż 2 sekundy od zakoń­
czenia zmiany prędkości, jeżeli prędkość zmieniła się
w tempie 2 m/s 2 .
35) Pomiar prędkości jest wykonywany z dokładnością co
najmniej 1 km/h lub wyższą.
3.2.3 Pomiar pozycji
36) Urządzenie rejestrujące mierzy bezwzględną pozycję
pojazdu za pomocą odbiornika GNSS.
▼M3
37) Bezwzględną pozycję mierzy się we współrzędnych szero­
kości i długości geograficznej, w stopniach i minutach,
z dokładnością do 1/10 minuty.
▼B
3.3 Pomiar czasu
38) Funkcja pomiaru czasu mierzy czas nieprzerwanie i cyfrowo
podaje czas UTC.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 30
39) Do datowania w urządzeniu rejestrującym (rejestracja,
wymiana danych) i do wszystkich wydruków wymienio­
nych w dodatku 4 „Wydruki” używany jest czas UTC.
40) W celu wizualizacji czasu lokalnego możliwa jest zmiana
przesunięcia wyświetlanego czasu skokowo co pół godziny.
Nie dopuszcza się innych przesunięć poza przesunięciami
wstecz lub do przodu o wielokrotność połowy godziny;
▼M3
41) Dryft czasu musi wynosić ± 1 sekundę dziennie lub mniej,
w warunkach temperaturowych zgodnie z wymogiem 213,
przy braku korekty czasu.
41a) Dokładność czasu, gdy czas jest korygowany przez warsz­
taty zgodnie z wymogiem 212, jest na poziomie 3 sekund
lub lepszym.
41b) Przyrząd rejestrujący musi zawierać dryftomierz, który
wylicza maksymalny dryft czasu od ostatniej korekty
czasu zgodnie z pkt 3.23. Maksymalny dryft czasu jest
określany przez producenta przyrządu rejestrującego i nie
może przekraczać 1 sekundy dziennie, jak określono
w wymogu 41.
41c) Dryftomierz ustawia się ponownie na 1 sekundę po każdej
korekcie czasu urządzenia rejestrującego zgodnie z pkt 3.23.
Obejmuje to:
— automatyczne korekty czasu,
— korekty czasu wykonywane w trybie kalibracyjnym.
▼B
42) Pomiar czasu jest wykonywany z dokładnością co najmniej
1 sekundy lub większą.
43) Odcięcie zewnętrznego źródła zasilania na czas nie krótszy
niż 12 miesięcy w warunkach homologacyjnych nie może
wpływać na pomiar czasu.
3.4 Monitorowanie czynności kierowcy
44) Funkcja ta nieprzerwanie i odrębnie monitoruje czynności
jednego kierowcy i jednego współkierowcy.
45) Czynnościami kierowcy są PROWADZENIE, PRACA,
GOTOWOŚĆ lub PRZERWA/ODPOCZYNEK.
46) Kierowca lub współkierowca mogą ręcznie wybierać
PRACĘ, GOTOWOŚĆ lub PRZERWĘ/ODPOCZYNEK.
47) Gdy pojazd porusza się następuje automatyczne wybór
czynności PROWADZENIE dla kierowcy i GOTOWOŚĆ
dla współkierowcy.
48) Gdy pojazd zatrzymuje się, następuje automatyczne
wybranie czynności PRACA dla kierowcy.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 31
49) Jeżeli w czasie 120 sekund od automatycznej zmiany na
PRACĘ, wskutek zatrzymania pojazdu, nastąpi zmiana
czynności na PRZERWA/ODPOCZYNEK lub GOTO­
WOŚĆ, przyjmuje się, że pierwsza taka zmiana zaistniała
w czasie postoju pojazdu (w ten sposób można anulować
zmianę czynności na PRACA).
▼B
50) Funkcja ta przekazuje zmiany czynności do funkcji rejes­
trującej w odstępach co jedną minutę.
51) W danej minucie zegarowej, jeżeli PROWADZENIE jest
zarejestrowane jako czynność w minucie bezpośrednio ją
poprzedzającej i następującej bezpośrednio po niej, to
cała ta minuta liczy się jako PROWADZENIE.
52) W danej minucie zegarowej, nietraktowanej jako PROWA­
DZENIE zgodnie z wymaganiem 051, cała taka minuta
liczy się jako jedna czynność, która trwała najdłużej
w ciągu tej minuty (lub była najpóźniejsza w przypadku
czynności o jednakowym czasie trwania).
53) Funkcja ta także nieprzerwanie monitoruje zarówno
nieprzerwany czas prowadzenia pojazdu, jak i skumulowany
czas przerwy dla kierowcy.
3.5 Monitorowanie stanu prowadzenia pojazdu
54) Funkcja ta nieprzerwanie i automatycznie monitoruje stan
prowadzenia pojazdu.
55) Po włożeniu dwóch ważnych kart kierowcy wybierany jest
stan prowadzenia pojazdu ZAŁOGA, w każdym innym
przypadku wybierany jest stan prowadzenia pojazdu
JEDEN KIEROWCA.
3.6 Dane wprowadzane przez kierowców
3.6.1 Wprowadzanie miejsca rozpoczęcia lub zakończenia okresu pracy
56) Funkcja ta umożliwia wprowadzanie miejsc, gdzie według
kierowcy lub współkierowcy rozpoczyna się lub kończy
dzienny okres pracy.
▼M3
57) Miejsca definiuje się jako kraj i dodatkowo, gdy stosowne,
region.
58) Po wyjęciu karty kierowcy (lub warsztatowej) urządzenie
rejestrujące wyświetla bieżące miejsce pojazdu na
podstawie informacji GNSS i zapisanej mapy cyfrowej
zgodnie z pkt 3.12.19 oraz zwraca się do posiadacza
karty o potwierdzenie lub ręczne sprostowanie miejsca.
59) Miejsce wpisane zgodnie z wymogiem 58 uważa się za
miejsce zakończenia dziennego okresu pracy. Rejestruje
się je na stosownej karcie kierowcy (lub karcie warsz­
tatowej) jako zapis tymczasowy i w związku z tym może
być później nadpisane.
W poniższych warunkach wpis tymczasowy wykonany
przy ostatnim wyjęciu karty zostaje zatwierdzony (tj. nie
będzie go już można nadpisać):
— wpis miejsca, w którym rozpoczyna się bieżący dzienny
okres pracy, w trakcie ręcznego wprowadzania zgodnie
z wymogiem 61;
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 32
— następny wpis miejsca, w którym rozpoczyna się
bieżący dzienny okres pracy, jeśli posiadacz karty nie
wpisze żadnego miejsca rozpoczęcia lub zakończenia
okresu pracy w trakcie ręcznego wprowadzania zgodnie
z wymogiem 61.
W poniższych warunkach wpis tymczasowy wykonany
przy ostatnim wyjęciu karty jest nadpisywany i zatwier­
dzona zostaje nowa wartość:
— następny wpis miejsca, w którym kończy się bieżący
dzienny okres pracy, jeśli posiadacz karty nie wpisze
żadnego miejsca rozpoczęcia lub zakończenia okresu
pracy w trakcie ręcznego wprowadzania zgodnie
z wymogiem 61.
▼B
60) Możliwe jest wprowadzenie miejsca rozpoczęcia lub zakoń­
czenia dziennego okresu pracy przez wybranie polecenia
w menu. Jeżeli w ciągu jednej minuty zegarowej wydane
zostaje więcej poleceń niż jedno, zarejestrowane zostaje
tylko ostatnie miejsce rozpoczęcia i ostatnie miejsce zakoń­
czenia wybrane w tym czasie.
▼M3
Urządzenie rejestrujące wyświetla bieżące miejsce pojazdu
na podstawie informacji GNSS i zapisanych map cyfro­
wych zgodnie z pkt 3.12.19 oraz zwraca się do kierowcy
o potwierdzenie lub ręczne sprostowanie miejsca.
▼B
3.6.2 Ręczne wprowadzanie czynności kierowcy i zgoda kierowcy na
interfejs ITS
▼M3
61) Po włożeniu karty kierowcy (lub warsztatowej), i tylko
w tym czasie, urządzenie rejestrujące umożliwia ręczne
wprowadzanie czynności. Ręczne wprowadzanie czynności
wykonuje się, stosując lokalny czas i datę strefy czasowej
(przesunięcie UTC) aktualnie ustawione w przyrządzie
rejestrującym.
Po włożeniu karty kierowcy lub warsztatowej przyrząd
rejestrujący przypomina posiadaczowi karty:
— datę i godzinę ostatniego wyjęcia jego karty;
— opcjonalnie: przesunięcie czasu lokalnego aktualnie
ustawionego w przyrządzie rejestrującym.
Przy pierwszym włożeniu danej karty kierowcy lub warsz­
tatowej, nieznanej przyrządowi rejestrującemu, posiadacz
karty jest proszony o wyrażenie zgody na wyprowadzenie
danych osobowych związanych z tachografem poprzez
interfejs ITS. W celu sprawdzenia, czy karta została już
włożona, urządzenie rejestrujące wykorzystuje dane karty
do tachografu zapisane w jego pamięci danych, jak okre­
ślono w wymogu 133.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 33
W dowolnym momencie istnieje możliwość potwierdzenia
lub wycofania zgody kierowcy (ew. warsztatu) przez
wybranie polecenia w menu, pod warunkiem że karta
kierowcy (lub warsztatowa) jest włożona.
Wprowadzanie czynności jest możliwe z następującymi
ograniczeniami:
— rodzajem czynności musi być PRACA, GOTOWOŚĆ
lub PRZERWA/ODPOCZYNEK;
— godzina rozpoczęcia i zakończenia każdej czynności
zawarta jest wyłącznie w okresie między ostatnim wyję­
ciem a bieżącym włożeniem karty;
— niedopuszczalne jest nakładanie się na siebie w czasie
okresów wykonywania tych czynności.
W razie potrzeby możliwe jest ręczne wprowadzanie czyn­
ności przy pierwszym włożeniu uprzednio nieużywanej
karty kierowcy (lub warsztatowej).
Procedura ręcznego wprowadzania czynności zawiera tyle
kolejnych etapów, ile jest konieczne do ustawienia rodzaju
każdej czynności, godziny jej rozpoczęcia i godziny jej
zakończenia. Dla całego okresu między ostatnim wyjęciem
a bieżącym włożeniem karty posiadacz karty może nie
zgłaszać żadnej czynności.
Podczas ręcznego wprowadzania danych związanego
z włożeniem karty, posiadacz karty ma, w stosownych
przypadkach, możliwość wprowadzenia:
— miejsca, w którym zakończył się poprzedni dzienny
okres pracy powiązany z odnośnym czasem (czyli
nadpisania i zatwierdzenia wpisu przy ostatnim wyjęciu
karty);
— miejsca, w którym rozpoczyna się bieżący dzienny
okres pracy powiązany z odnośnym czasem (czyli
zatwierdzenia wpisu tymczasowego przy ostatnim
wyjęciu karty).
W przypadku miejsca wprowadzonego przy bieżącym
włożeniu karty jako miejsce, w którym rozpoczyna się
bieżący dzienny okres pracy, urządzenie rejestrujące
wyświetla bieżące miejsce pojazdu na podstawie informacji
GNSS i zapisanych map cyfrowych zgodnie z pkt 3.12.19
oraz zwraca się do kierowcy o potwierdzenie lub ręczne
sprostowanie miejsca.
Jeżeli posiadacz karty nie wprowadzi miejsca rozpoczęcia
lub zakończenia okresu pracy podczas ręcznego wprowa­
dzania danych związanego z włożeniem karty, będzie to
równoważne z potwierdzeniem, że okres pracy nie zmienił
się od ostatniego wyjęcia karty. Kolejne wprowadzenie
miejsca zakończenia poprzedniego dziennego okresu pracy
nadpisze wówczas wpis tymczasowy wprowadzony przy
ostatnim wyjęciu karty.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 34
Jeżeli wprowadza się miejsce, rejestruje się je na stosownej
karcie do tachografu.
Ręczne wprowadzanie zostaje przerwane, jeżeli:
— karta zostaje wyjęta lub
— pojazd porusza się, a karta znajduje się w czytniku
karty kierowcy.
Dozwolone są dodatkowe przerwy, np. przekroczenie
dozwolonego czasu po pewnym okresie braku aktywności
użytkownika. Jeżeli ręczne wprowadzanie zostanie prze­
rwane, urządzenie rejestrujące dokonuje walidacji wszyst­
kich kompletnych miejsc i czynności (mających przypisane
jednoznaczne miejsce i godzinę lub rodzaj czynności,
godzinę rozpoczęcia i godzinę zakończenia).
Jeżeli podczas ręcznego wprowadzania czynności dla
wcześniej włożonej karty zostanie włożona karta drugiego
kierowcy lub karta warsztatowa, dopuszcza się uzupełnienie
ręcznego wprowadzania dla karty włożonej wcześniej przed
rozpoczęciem ręcznego wprowadzania dla drugiej karty.
Posiadacz karty ma możliwość ręcznego wprowadzenia
zgodnie z następującą procedurą minimalną:
— Ręczne wprowadzenie czynności w kolejności chrono­
logicznej w okresie między ostatnim wyjęciem
a bieżącym włożeniem karty.
— Godzina rozpoczęcia pierwszej czynności jest ustawiona
na godzinę wyjęcia karty. Dla każdego kolejnego zapisu
godzina rozpoczęcia jest wstępnie ustawiona tak, aby
następowała bezpośrednio po godzinie zakończenia
poprzedniego zapisu. Rodzaj czynności i godzinę
zakończenia wybiera się dla każdej czynności.
Procedura kończy się, gdy godzina zakończenia ręcznie
wprowadzanej czynności pokrywa się z godziną włożenia
karty.
Urządzenie rejestrujące umożliwia kierowcom i warsztatom
alternatywne ładowanie ręcznych wpisów, które należy
wprowadzić podczas procedury za pośrednictwem interfejsu
ITS określonego w dodatku 13, oraz, opcjonalnie, za
pośrednictwem innych interfejsów.
Urządzenie rejestrujące umożliwia posiadaczowi karty
modyfikowanie ręcznie wprowadzonej czynności aż do
zatwierdzenia przez wybranie odpowiedniego polecenia.
W późniejszym czasie wprowadzenie takich zmian jest
zabronione.
▼B
3.6.3 Wprowadzanie warunków szczególnych
▼M3
62) Urządzenie rejestrujące umożliwia kierowcy wprowadzenie
w czasie rzeczywistym następujących dwóch stanów szcze­
gólnych:
— „POZA ZAKRESEM” (początek, koniec),
— „PRZEPRAWA PROMOWA/POCIĄGOWA” (początek,
koniec).
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 35
Jeżeli otwarty jest stan „POZA ZAKRESEM”, nie może
równocześnie występować stan „PRZEPRAWA
PROMOWA/POCIĄGOWA”. Jeżeli otwarto stan „POZA
ZAKRESEM”, urządzenie rejestrujące nie pozwala użyt­
kownikom na wpisanie flagi początkowej „PRZEPRAWA
PROMOWA/POCIĄGOWA”.
Włożenie lub wyjęcie karty kierowcy powoduje automa­
tycznie zakończenie otwartego stanu „POZA ZAKRESEM”.
Otwarty stan „POZA ZAKRESEM” blokuje następujące
zdarzenia i ostrzeżenia:
— prowadzenie pojazdu bez prawidłowej karty,
— ostrzeżenia związane z nieprzerwanym czasem prowa­
dzenia pojazdu.
Kierowca wpisuje flagę początkową PRZEPRAWA
PROMOWA/POCIĄGOWA niezwłocznie po wybraniu czyn­
ności PRZERWA/ODPOCZYNEK na promie lub w pociągu.
Zamknięcie otwartego stanu PRZEPRAWA PROMOWA/
POCIĄGOWA przez urządzenie rejestrujące musi nastąpić,
jeżeli wystąpi jedna z następujących sytuacji:
— kierowca ręcznie kończy stan PRZEPRAWA
PROMOWA/POCIĄGOWA, co następuje po przybyciu
promu/pociągu do miejsca przeznaczenia, przed zjazdem
z promu/pociągu,
— otwarty jest stan „POZA ZAKRESEM”,
— kierowca wyjmuje swoją kartę,
— aktywność kierowcy liczona jest jako PROWADZENIE
w ciągu minuty kalendarzowej zgodnie z pkt 3.4.
Jeżeli w ciągu jednej minuty kalendarzowej dokonuje się
więcej niż jednego wpisu stanów szczególnych tego
samego typu, rejestruje się tylko ostatni z nich.
3.6.4 Wprowadzanie operacji załadunku/rozładunku
62a) Urządzenie rejestrujące umożliwia kierowcy wprowadzenie
i potwierdzenie, w czasie rzeczywistym, informacji wska­
zujących, że pojazd jest załadowywany, rozładowywany
lub że wykonywana jest operacja równoczesnego zała­
dunku/rozładunku.
Jeżeli w ciągu jednej minuty kalendarzowej dokonuje się
więcej niż jednego wpisu operacji załadunku/rozładunku
tego samego typu, rejestruje się tylko ostatni z nich.
62b) Operacje załadunku, rozładunku lub równoczesnego zała­
dunku/rozładunku rejestruje się jako odrębne zdarzenia.
62c) Informacje dotyczące załadunku/rozładunku wprowadza się
przed opuszczeniem przez pojazd miejsca, w którym prze­
prowadzana jest operacja załadunku/rozładunku.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 36
3.7 Zarządzanie blokadami firmowymi
63) Funkcja ta umożliwia zarządzanie blokadami umieszcza­
nymi przez firmę w celu ograniczenia dostępu do danych,
gdy urządzenie pracuje w trybie firmowym.
64) Blokady firmowe polegają na ustawieniu daty/godziny
rozpoczęcia (włączenie blokady) i daty/godziny zakoń­
czenia (zwolnienie blokady) związanych z identyfikacją
firmy pobraną z numeru karty firmowej (przy włączeniu
blokady).
65) Blokady można włączać i zwalniać tylko w czasie
rzeczywistym.
66) Blokadę może zwolnić tylko ta firma, która ją włączyła
(identyfikowana na podstawie pierwszych 13 cyfr numeru
karty firmowej), lub
67) Zwolnienie następuje automatycznie po włączeniu blokady
przez inną firmę.
68) W przypadku gdy firma włącza blokadę, a poprzednia
blokada była włączona przez tę samą firmę, przyjmuje
się, że poprzednia blokada nie została zwolniona i nadal
jest włączona.
3.8 Monitorowanie czynności kontrolnych
69) Funkcja ta monitoruje wykonywane w trybie kontrolnym
czynności WYŚWIETLANIA, DRUKOWANIA, POBIE­
RANIA DANYCH z przyrządu rejestrującego i karty oraz
KONTROLI DROGOWEJ KALIBRACJI.
70) Funkcja ta również monitoruje KONTROLE PRZEKRO­
CZENIA PRĘDKOŚCI wykonywane w trybie kontrolnym.
Uznaje się, że kontrola przekroczenia prędkości została
przeprowadzona, gdy w trybie kontrolnym komunikat
„przekroczenie prędkości” zostaje wysłany do drukarki
lub wyświetlony na monitorze, lub gdy dane o „zdarzeniach
i usterkach” zostały pobrane z pamięci danych przyrządu
rejestrującego.
3.9 Wykrywanie zdarzeń lub usterek
71) Funkcja ta wykrywa następujące zdarzenia lub usterki:
3.9.1 Zdarzenie „włożenie nieważnej karty”
72) Zdarzenie to uruchamiane jest przez włożenie nieważnej
karty, włożenie karty kierowcy, która została wymieniona,
lub wygaśnięcie ważności włożonej, ważnej karty.
3.9.2 Zdarzenie „konflikt kart”
73) Zdarzenie to uruchamiane jest przez każdą kombinację
ważnych kart zaznaczoną X w tabeli poniżej:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 37
Konflikt kart
Czytnik karty kierowcy
Brak karty Karta kierowcy Karta kontrolna Karta warsztatowa Karta firmowa
C
zy
tn
ik
k
ar
ty
w
sp
ół
ki
er
ow
cy

Brak karty
Karta kierowcy X
Karta kontrolna X X X
Karta warsztatowa X X X X
Karta firmowa X X X
3.9.3 Zdarzenie,,nakładające się czasy
74) Zdarzenie to uruchamiane jest w sytuacji, gdy data/godzina
ostatniego wyjęcia karty kierowcy, odczytana z karty, jest
późniejsza niż bieżąca data/godzina urządzenia rejestrują­
cego, do którego karta jest wkładana.
3.9.4 Zdarzenie „prowadzenie pojazdu bez prawidłowej karty”
75) Zdarzenie to uruchamiane jest przez każdą kombinację
ważnych kart do tachografów zaznaczoną X w poniższej
tabeli, gdy czynność kierowcy zmienia się na PROWA­
DZENIE lub w przypadku zmiany trybu pracy, w czasie
gdy czynnością wykonywaną przez kierowcę jest PROWA­
DZENIE:
Prowadzenie pojazdu bez
prawidłowej
karty
Czytnik karty kierowcy
Brak karty (lub
karta nieważna)
Karta kierowcy Karta kontrolna Karta warsztatowa Karta firmowa
C
zy
tn
ik
k
ar
ty
w
sp
ół
ki
er
ow
cy

Brak karty (lub karta
nieważna)
X X X
Karta kierowcy X X X X
Karta kontrolna X X X X X
Karta warsztatowa X X X X
Karta firmowa X X X X X
3.9.5 Zdarzenie „włożenie karty podczas prowadzenia pojazdu”
76) Zdarzenie to uruchamia się, gdy do dowolnego czytnika
włożona zostaje karta do tachografu, a czynnością kierowcy
jest PROWADZENIE.
3.9.6 Zdarzenie „Sesja ostatniej karty niezamknięta prawidłowo”
77) Zdarzenie to uruchamia się, gdy przy wkładaniu karty urzą­
dzenie rejestrujące wykryje, że pomimo przepisów określo­
nych w pkt 3.1 sesja poprzedniej karty nie została prawid­
łowo zamknięta (karta została wyjęta przed zapisaniem na
karcie wszystkich wymaganych danych). Zdarzenie to
uruchamiają tylko karty kierowcy i warsztatowe.
3.9.7 Zdarzenie „przekroczenie prędkości”
78) Zdarzenie to uruchamia się przy każdym przekroczeniu
prędkości.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 38
3.9.8 Zdarzenie „przerwa w zasilaniu”
79) Z wyjątkiem trybu kalibracyjnego lub kontrolnego, zdarzenie
to uruchamia się w przypadku przekraczającej 200 ms
przerwy w zasilaniu czujnika ruchu lub przyrządu rejestrują­
cego. Wartość progową przerwy definiuje producent.
Przerwa w zasilaniu spowodowana uruchamianiem silnika
pojazdu nie może uruchamiać tego zdarzenia.
3.9.9 Zdarzenie „błąd połączenia z urządzeniem do łączności na odle­
głość”
80) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia
się w przypadku gdy urządzenie do łączności na odległość
nie potwierdza odbioru danych przesyłanych zdalnie z przy­
rządu rejestrującego podczas więcej niż trzech prób.
3.9.10 Zdarzenie „brak informacji o pozycji z odbiornika GNSS”
81) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia
się w przypadku braku informacji o pozycji pochodzących
z odbiornika GNSS (wewnętrznego lub zewnętrznego) przez
ponad trzy godziny skumulowanego czasu prowadzenia
pojazdu.
3.9.11 Zdarzenie „błąd połączenia z urządzeniem zewnętrznym GNSS”
82) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia
się w przypadku przerwy w łączności między urządzeniem
zewnętrznym GNSS a przyrządem rejestrującym przez ponad
20 kolejnych minut, kiedy pojazd jest w ruchu.
3.9.12 Zdarzenie „błąd danych dotyczących ruchu”
▼M3
83) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia
się w przypadku przerwy w normalnym przepływie danych
między czujnikiem ruchu a przyrządem rejestrującym lub
w przypadku błędu integralności danych lub błędu uwierzy­
telnienia danych wymienianych między czujnikiem ruchu
a przyrządem rejestrującym. Z wyjątkiem trybu kalibracyj­
nego, zdarzenie to uruchamia się w przypadku, gdy prędkość
obliczona z impulsów czujnika ruchu wzrośnie z 0 do ponad
40 km/h w ciągu 1 sekundy, a następnie pozostaje powyżej
40 km/h przez co najmniej 3 sekundy.
▼B
3.9.13 Zdarzenie „konflikt ruchu pojazdu”
▼M3
84) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia
się, jak określono w dodatku 12, jeżeli informacje o ruchu
z czujnika ruchu są sprzeczne z informacjami o ruchu obli­
czonymi z wewnętrznego odbiornika GNSS lub urządzenia
zewnętrznego GNSS lub z innych niezależnych źródeł
zgodnie z wymogiem 26. Zdarzenie to nie może być urucho­
mione podczas przeprawy promowej/pociągowej.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 39
3.9.14 Zdarzenie „próba naruszenia zabezpieczenia”
85) Zdarzenie to uruchamiane jest przez każde inne zdarzenie
naruszające zabezpieczenie czujnika ruchu lub przyrządu rejes­
trującego lub urządzenia zewnętrznego GNSS, zgodnie
z wymogami w dodatku 10, z wyjątkiem trybu kalibracyjnego.
▼M1
3.9.15 Zdarzenie „konflikt czasu”
▼M3
86) Z wyjątkiem trybu kalibracyjnego, zdarzenie to
uruchamia się, jeżeli przyrząd rejestrujący wykryje rozbież­
ność między czasem określonym przez funkcję pomiaru
czasu w przyrządzie rejestrującym a czasem pochodzącym
z uwierzytelnionych pozycji przekazywanych przez
odbiornik GNSS lub urządzenie zewnętrzne GNSS.
„Rozbieżność czasu” wykrywa się, jeżeli różnica czasu
przekracza ± 3 sekundy, co odpowiada dokładności czasu
określonej w wymogu 41a, przy czym ta ostatnia wartość
zwiększa się o maksymalny dzienny dryft czasu. Zdarzenie
to jest rejestrowane wraz z wartością wyświetlaną na
wewnętrznym zegarze urządzenia rejestrującego. Przyrząd
rejestrujący dokonuje sprawdzenia w celu uruchomienia
zdarzenia „konflikt czasowy” tuż przed automatycznym
dostosowaniem wewnętrznego zegara VU, zgodnie z wymo­
giem 211.
▼B
3.9.16 Usterka „karta”
87) Usterkę tę uruchamia błąd karty do tachografu podczas
pracy.
3.9.17 Usterka „urządzenie rejestrujące”
88) Usterkę tę uruchamia dowolny z następujących błędów,
z wyjątkiem pracy w trybie kalibracyjnym:
— usterka wewnętrzna przyrządu rejestrującego
— usterka drukarki
— usterka wyświetlacza
— usterka pobierania danych
— usterka czujnika
— usterka odbiornika GNSS lub urządzenia zewnętrznego
GNSS
— usterka urządzenia do łączności na odległość
▼M3
— usterka związana z interfejsem ITS,
3.9.18 Zdarzenie „anomalia GNSS”
88a) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia
się, gdy odbiornik GNSS wykryje atak lub gdy uwierzytel­
nienie komunikatów nawigacyjnych nie powiodło się, jak
określono w dodatku 12. Po uruchomieniu zdarzenia
anomalii GNSS przyrząd rejestrujący nie generuje innych
zdarzeń anomalii GNSS przez kolejnych 10 minut.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 40
3.10 Testy wbudowane i autotesty
89) ►M1 Urządzenie rejestrujące wykrywa usterki, wykonując
autotesty i testy wbudowane, zgodnie z poniższą tabelą: ◄
Testowany podzespół Autotest Test wbudowany
Oprogramowanie Integralność
Pamięć danych Dostęp Dostęp, integralność
danych
Czytniki kart Dostęp Dostęp
Klawiatura Kontrola ręczna
Drukarka (w gestii produ­
centa)
Wydruk
Wyświetlacz Kontrola wzrokowa
Pobieranie danych
(wykonywane tylko
podczas pobierania)
Prawidłowa praca
Czujnik Prawidłowa praca Prawidłowa praca
Urządzenie do łączności na
odległość
Prawidłowa praca Prawidłowa praca
Urządzenie GNSS Prawidłowa praca Prawidłowa praca
▼M3
interfejs ITS Prawidłowa praca
▼B
3.11 Odczyt z pamięci danych
90) Urządzenie rejestrujące umożliwia odczyt danych przecho­
wywanych w jego pamięci danych.
3.12 Rejestracja i przechowywanie w pamięci danych
▼M3
Do celów niniejszego punktu:
— „365 dni” definiuje się jako 365 dni kalendarzowych przecięt­
nych czynności wykonywanych przez kierowców w pojeździe.
Przeciętne czynności na dzień w pojeździe definiuje się jako co
najmniej 6 kierowców lub współkierowców, 6 cykli wkładania
i wyjmowania karty i 256 zmian czynności. „365 dni” obejmuje
zatem co najmniej 2 190 kierowców lub współkierowców, 2 190
cykli wkładania i wyjmowania karty i 93 440 zmian czynności,
— średnią liczbę wpisów na dzień definiuje się jako co najmniej 6
wpisów, w których rozpoczyna się dzienny okres pracy, oraz 6
wpisów, w których kończy się dzienny okres pracy, tak więc
„365 dni” obejmuje co najmniej 4 380 pozycji,
— średnią liczbę pozycji na dzień, gdy skumulowany czas prowa­
dzenia pojazdu osiąga wielokrotność trzech godzin, definiuje się
jako co najmniej 6 pozycji, a zatem „365 dni” obejmuje co
najmniej 2 190 takich pozycji,
— średnią liczbę przekroczeń granicy na dzień definiuje się jako co
najmniej 20, a zatem „365 dni” obejmuje co najmniej 7 300
przekroczeń granicy,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 41
— średnią liczbę operacji załadunku/rozładunku na dzień definiuje
się jako co najmniej 25 operacji (niezależnie od typu), a zatem
„365 dni” obejmuje co najmniej 9 125 operacji załadunku/rozła­
dunku,
— czas jest rejestrowany z dokładnością do jednej minuty, o ile nie
ustalono inaczej,
— stany licznika kilometrów rejestruje się z dokładnością do
jednego kilometra,
— prędkości rejestruje się z dokładnością do 1 km/h,
— pozycje (szerokości i długości geograficzne) rejestruje się w stop­
niach i minutach, z dokładnością do 1/10 minuty, z powiązaną
dokładnością GNSS i czasem pobrania danych, a także z flagą
wskazującą, czy pozycja została uwierzytelniona.
▼B
91) Odcięcie zewnętrznego źródła zasilania na czas krótszy niż
dwanaście miesięcy, w warunkach homologacyjnych, nie
może wpływać na dane przechowywane w pamięci danych.
Ponadto odcięcie zasilania na czas krótszy niż 28 dni nie
może mieć wpływu na dane przechowywane w zewnętrznym
urządzeniu do łączności na odległość, zgodnie z definicją
w dodatku 14.
92) Urządzenie rejestrujące umożliwia rejestrowanie, pośrednio
lub bezpośrednio, w pamięci danych następujących informacji:
3.12.1 Dane identyfikujące sprzęt
3.12.1.1 D a n e i d e n t y f i k u j ą c e p r z y r z ą d r e j e s t r u j ą c y
93) Urządzenie rejestrujące umożliwia przechowywanie
w pamięci danych następujących danych identyfikujących
przyrząd rejestrujący:
— nazwa producenta,
— adres producenta,
— numer części,
— numer seryjny,
— generacja przyrządu rejestrującego,
— możliwość korzystania z kart do tachografów pierwszej
generacji,
— numer wersji oprogramowania,
— data instalacji wersji oprogramowania,
— rok produkcji urządzenia,
— numer homologacji,
▼M3
— identyfikator wersji mapy cyfrowej (wymóg 133l).
94) Dane identyfikujące przyrząd rejestrujący są rejestrowane
i zapisywane w pamięci definitywnie przez producenta
przyrządu rejestrującego, z wyjątkiem danych, które mogą
zostać zmienione w przypadku aktualizacji oprogramo­
wania zgodnie z niniejszym rozporządzeniem, oraz z wyjąt­
kiem możliwości korzystania z kart do tachografów pierw­
szej generacji.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 42
3.12.1.2 D a n e i d e n t y f i k u j ą c e c z u j n i k r u c h u
95) Czujnik ruchu umożliwia przechowywanie w pamięci
następujących danych identyfikujących:
— nazwa producenta,
— numer seryjny,
— numer homologacji,
— identyfikator wbudowanego elementu zabezpieczenia
(np. numer części wewnętrznego mikroprocesora),
— identyfikator systemu operacyjnego (np. numer wersji
oprogramowania).
96) Dane identyfikujące czujnik ruchu są rejestrowane i zapisy­
wane w czujniku ruchu definitywnie przez producenta czuj­
nika ruchu.
▼M3
97) Przyrząd rejestrujący musi mieć możliwość rejestrowania
i zachowywania w pamięci następujących danych związa­
nych z 20 ostatnimi udanymi sparowaniami czujników
ruchu (jeżeli podczas jednego dnia kalendarzowego miało
miejsce wiele sparowań, zachowywane jest tylko pierwsze
i ostatnie z danego dnia):
▼B
Przy każdym sparowaniu rejestruje się następujące dane:
— dane identyfikujące czujnik ruchu:
— numer seryjny
— numer homologacji
— dane sparowania czujnika ruchu:
— data sparowania.
3.12.1.3 D a n e i d e n t y f i k u j ą c e g l o b a l n e g o s y s t e m u n a w i ­
g a c j i s a t e l i t a r n e j
98) Urządzenie zewnętrzne GNSS umożliwia przechowywanie
w pamięci następujących danych identyfikujących:
— nazwa producenta,
— numer seryjny,
— numer homologacji,
— identyfikator wbudowanego elementu zabezpieczenia
(np. numer części wewnętrznego mikroprocesora),
— identyfikator systemu operacyjnego (np. numer wersji
oprogramowania).
99) Dane identyfikujące są rejestrowane i zapisywane w urzą­
dzeniu zewnętrznym GNSS definitywnie przez producenta
urządzenia zewnętrznego GNSS.
▼M3
100) Przyrząd rejestrujący musi mieć możliwość rejestrowania
i zachowywania w pamięci następujących danych związa­
nych z 20 ostatnimi udanymi powiązaniami urządzeń
zewnętrznych GNSS (jeżeli podczas jednego dnia kalenda­
rzowego miało miejsce wiele powiązań, zachowywane jest
tylko pierwsze i ostatnie z danego dnia).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 43
Przy każdym powiązaniu rejestruje się następujące dane:
— dane identyfikujące urządzenia zewnętrznego GNSS:
— numer seryjny,
— numer homologacji,
— dane dotyczące powiązania z urządzeniem zewnętrznym
GNSS:
— data powiązania.
3.12.2 Klucze i certyfikaty
101) Urządzenie rejestrujące umożliwia przechowywanie szeregu
kluczy i certyfikatów kryptograficznych, jak określono
w dodatku 11 część A i część B.
3.12.3 Dane rejestrowane przy wkładaniu i wyjmowaniu karty kierowcy
lub warsztatowej
102) Przy każdym cyklu wkładania/wyjmowania karty kierowcy
lub warsztatowej do urządzenia, urządzenie rejestrujące
rejestruje i przechowuje w pamięci danych następujące
informacje:
— nazwisko i imię (imiona) posiadacza karty zapisane na
karcie,
— numer karty, państwo członkowskie wydające kartę
i termin ważności zapisane na karcie,
— generację karty,
— datę i godzinę włożenia karty,
— stan licznika kilometrów przy wkładaniu karty,
— szczelinę czytnika, do której karta jest wkładana,
— datę i godzinę wyjęcia karty,
— stan licznika kilometrów przy wyjęciu karty,
— następujące informacje o poprzednim pojeździe
używanym przez kierowcę, zapisane na karcie:
— numer VRN i państwo członkowskie rejestracji,
— generacja przyrządu rejestrującego (w razie dostęp­
ności),
— datę i godzinę wyjęcia karty,
— wskaźnik stanu pokazujący, czy przy wkładaniu karty
posiadacz karty wprowadził ręcznie informacje o wyko­
nywaniu czynności.
103) Pamięć danych wystarcza do przechowywania tych danych
przez co najmniej 365 dni.
104) W przypadku zapełnienia pamięci danych nowe dane zastę­
pują dane najstarsze.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 44
3.12.4 Dane dotyczące czynności kierowcy
105) Urządzenie rejestrujące rejestruje i przechowuje w pamięci
danych za każdym razem, kiedy następuje zmiana czyn­
ności kierowcy lub współkierowcy, lub za każdym razem,
kiedy następuje zmiana stanu prowadzenia pojazdu, lub za
każdym razem, kiedy następuje włożenie lub wyjęcie karty
kierowcy lub karty warsztatowej:
— stan prowadzenia pojazdu (ZAŁOGA, JEDEN
KIEROWCA),
— szczelinę czytnika (KIEROWCA, WSPÓŁKIE­
ROWCA),
— status karty w odpowiedniej szczelinie czytnika kart
(WŁOŻONA, NIEWŁOŻONA),
— czynność (PROWADZENIE, GOTOWOŚĆ, PRACA,
PRZERWA/ODPOCZYNEK),
— datę i godzinę zmiany.
WŁOŻONA oznacza, że do czytnika jest włożona ważna
karta kierowcy lub warsztatowa. NIEWŁOŻONA oznacza
sytuację przeciwną, tzn. że do czytnika nie jest włożona
ważna karta kierowcy ani warsztatowa (np. włożona jest
karta firmowa lub brak jest karty).
Dane dotyczące czynności ręcznie wprowadzone przez
kierowcę nie są rejestrowane w pamięci danych.
106) Pamięć danych wystarcza do przechowywania danych doty­
czących czynności kierowcy przez co najmniej 365 dni.
107) W przypadku zapełnienia pamięci danych nowe dane zastę­
pują dane najstarsze.
▼M1
3.12.5 Miejsca i pozycje, w których zaczynają się i kończą dzienne okresy
pracy lub w których osiągnięto 3 godziny skumulowanego czasu
prowadzenia pojazdu
108) Urządzenie rejestrujące rejestruje i przechowuje w pamięci
następujące dane:
— miejsca i pozycje, w których kierowca lub współkie­
rowca rozpoczynają dzienny okres pracy;
— pozycje, w których skumulowany czas prowadzenia
pojazdu osiągnie wielokrotność trzech godzin;
— miejsca i pozycje, w których kierowca lub współkie­
rowca kończą dzienny okres pracy.
▼B
109) Jeżeli w danym momencie pozycja pojazdu nie jest
dostępna z odbiornika GNSS, urządzenie rejestrujące
korzysta z ostatniej dostępnej pozycji i odpowiadającej jej
daty i godziny.
110) Wraz z miejscem lub pozycją urządzenie rejestrujące rejes­
truje i przechowuje w pamięci następujące dane:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 45
— numer karty kierowcy lub współkierowcy i państwo
członkowskie wydające kartę,
▼B
— generację karty,
— datę i godzinę wpisu,
▼M1
— rodzaj wpisu (rozpoczęcie, zakończenie lub 3 godziny
skumulowanego czasu prowadzenia pojazdu),
▼B
— w stosownych przypadkach odpowiednią dokładność
GNSS, datę i godzinę,
— stan licznika kilometrów,
▼M3
— flagę wskazującą, czy pozycja została uwierzytelniona.
110a) Dla miejsc, w których rozpoczyna się lub kończy dzienny
okres pracy, wprowadzanych podczas procedury ręcznego
wprowadzania danych przy wkładaniu karty zgodnie
z wymogiem 61, należy zapisać bieżący stan licznika kilo­
metrów i pozycję pojazdu.
▼M1
111) Pamięć danych wystarcza do przechowywania miejsc
i pozycji, w których zaczynają się i kończą dzienne okresy
pracy lub w których osiągnięto 3 godziny skumulowanego
czasu prowadzenia pojazdu, przez co najmniej 365 dni.
▼B
112) W przypadku zapełnienia pamięci danych nowe dane zastę­
pują dane najstarsze.
3.12.6 Dane dotyczące licznika kilometrów
113) Urządzenie rejestrujące rejestruje w pamięci danych stan
licznika kilometrów i odpowiednią datę o północy każdego
dnia kalendarzowego.
114) Pamięć danych wystarcza do przechowywania danych doty­
czących stanu licznika o północy przez co najmniej 365 dni
kalendarzowych.
115) W przypadku zapełnienia pamięci danych nowe dane zastę­
pują dane najstarsze.
3.12.7 Dane szczegółowe dotyczące prędkości
▼M1
116) Urządzenie rejestrujące rejestruje i przechowuje w pamięci
danych prędkość chwilową pojazdu wraz z datą i godziną,
rejestrowane co sekundę przez okres co najmniej ostatnich
24 godzin, w których pojazd był w ruchu.
▼B
3.12.8 Dane dotyczące zdarzeń
Do celów niniejszego podpunktu czas rejestruje się z dokładnoś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:
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 46
Zdarzenie Zasady przechowywania Dane rejestrowane dla zdarzenia
Włożenie nieważnej karty — 10 ostatnich zdarzeń — data i godzina zdarzenia
— typ karty, numer, państwo członkowskie
wydające kartę i generacja karty, która
wywołała zdarzenie
— liczba podobnych zdarzeń w tym dniu
Konflikt kart — 10 ostatnich zdarzeń — data i godzina początku zdarzenia
— data i godzina końca zdarzenia
— typ karty, numer, państwo członkowskie
wydające kartę i generacja dwóch kart,
które wywołały konflikt
Prowadzenie pojazdu bez
prawidłowej karty
— najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni
— data i godzina początku zdarzenia
— data i godzina końca zdarzenia
— typ karty, numer, państwo członkowskie
wydające kartę i generacja dla każdej
karty wprowadzonej na początku lub
pod koniec zdarzenia
— liczba podobnych zdarzeń w tym dniu
Włożenie karty podczas
jazdy
— ostatnie zdarzenie dla każdego z 10
ostatnich dni ich występowania
— data i godzina zdarzenia
— typ karty, numer, państwo członkowskie
wydające kartę i generacja
— liczba podobnych zdarzeń w tym dniu
▼M3
Sesja ostatniej karty
niezamknięta prawidłowo
— 10 ostatnich zdarzeń — data i godzina włożenia karty
— typ karty, numer, państwo członkowskie
wydające kartę i generacja
— dane dotyczące ostatniej sesji odczytane
z karty:
— data i godzina włożenia karty
▼B
Przekroczenie prędkości
(1)
— najpoważniejsze zdarzenie dla każdego
z 10 ostatnich dni od zaistnienia
zdarzenia (tzn. zdarzenie o najwyższej
przeciętnej prędkości)
— 5 najpoważniejszych zdarzeń w ciągu
ostatnich 365 dni
— pierwsze zdarzenie zaistniałe po ostat­
niej kalibracji
— data i godzina początku zdarzenia
— data i godzina końca zdarzenia
— maksymalna prędkość zmierzona w czasie
zdarzenia
— średnia arytmetyczna prędkość zmie­
rzona w czasie zdarzenia
— typ karty, numer, państwo członkowskie
wydające kartę i generacja karty kierowcy
(w stosownych przypadkach)
— liczba podobnych zdarzeń w tym dniu
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 47
Zdarzenie Zasady przechowywania Dane rejestrowane dla zdarzenia
Przerwa w zasilaniu (2) — najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni
— data i godzina początku zdarzenia
— data i godzina końca zdarzenia
— typ karty, numer, państwo członkowskie
wydające kartę i generacja dla każdej
karty wprowadzonej na początku lub
pod koniec zdarzenia
— liczba podobnych zdarzeń w tym dniu
Błąd połączenia z urządze­
niem do łączności na
odległość
— najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni
— data i godzina początku zdarzenia
— data i godzina końca zdarzenia
— typ karty, numer, państwo członkowskie
wydające kartę i generacja dla każdej
karty wprowadzonej na początku lub
pod koniec zdarzenia
— liczba podobnych zdarzeń w tym dniu
Brak informacji o pozycji
z odbiornika GNSS
— najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni
— data i godzina początku zdarzenia
— data i godzina końca zdarzenia
— typ karty, numer, państwo członkowskie
wydające kartę i generacja dla każdej
karty wprowadzonej na początku lub
pod koniec zdarzenia
— liczba podobnych zdarzeń w tym dniu
▼M1
Błąd połączenia z urządze­
niem zewnętrznym GNSS
— najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni
— data i godzina początku zdarzenia
— data i godzina końca zdarzenia
— typ karty, numer, państwo członkowskie
wydające kartę i generacja dla każdej
karty wprowadzonej na początku lub
pod koniec zdarzenia
— liczba podobnych zdarzeń w tym dniu
▼B
Błąd danych dotyczących
ruchu
— najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni
— data i godzina początku zdarzenia
— data i godzina końca zdarzenia
— typ karty, numer, państwo członkowskie
wydające kartę i generacja dla każdej
karty wprowadzonej na początku lub
pod koniec zdarzenia
— liczba podobnych zdarzeń w tym dniu
Konflikt ruchu pojazdu — najdłuższe zdarzenie w każdym z ostat­
nich 10 dni ich występowania
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni
— data i godzina początku zdarzenia
— data i godzina końca zdarzenia
— typ karty, numer, państwo członkowskie
wydające kartę i generacja dla każdej
karty wprowadzonej na początku lub
pod koniec zdarzenia
— liczba podobnych zdarzeń w tym dniu
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 48
Zdarzenie Zasady przechowywania Dane rejestrowane dla zdarzenia
Próba naruszenia zabez­
pieczenia
— 10 ostatnich zdarzeń wg typu zdarzenia — data i godzina początku zdarzenia
— data i godzina zakończenia zdarzenia
(jeżeli jest istotna)
— typ karty, numer, państwo członkowskie
wydające kartę i generacja dla każdej
karty wprowadzonej na początku lub
pod koniec zdarzenia
— typ zdarzenia
▼M1
Konflikt czasu — najpoważniejsze zdarzenie w każdym
z 10 ostatnich dni ich występowania
(tj. zdarzenia z największymi różnicami
pomiędzy datą i godziną z urządzenia
rejestrującego a datą i godziną
z GNSS),
— 5 najpoważniejszych zdarzeń w ciągu
ostatnich 365 dni
— data i godzina z urządzenia rejestrują­
cego
— data i godzina z GNSS
— typ karty, numer, państwo członkowskie
wydające kartę i generacja dla każdej
karty wprowadzonej na początku lub
pod koniec zdarzenia
— liczba podobnych zdarzeń w tym dniu
▼M3
Anomalia GNSS — najdłuższe zdarzenia w każdym z ostat­
nich 10 dni ich występowania,
— 5 najdłuższych zdarzeń w ciągu ostat­
nich 365 dni
— data i godzina początku zdarzenia
— data i godzina końca zdarzenia
— typ karty, numer, państwo członkowskie
wydające kartę i generacja dla każdej
karty wprowadzonej na początku lub na
końcu zdarzenia
— liczba podobnych zdarzeń w tym dniu
▼B
(1) Urządzenie rejestrujące rejestruje i przechowuje
również w pamięci następujące dane:
— datę i godzinę ostatniej KONTROLI PRZEKRO­
CZENIA PRĘDKOŚCI,
— datę i godzinę pierwszego przekroczenia prędkości
po tej ostatniej KONTROLI PRZEKROCZENIA
PRĘDKOŚCI.
— liczbę zdarzeń przekroczenia prędkości od ostatniej
KONTROLI PRZEKROCZENIA PRĘDKOŚCI.
(2) Dane te mogą być rejestrowane wyłącznie po przywró­
ceniu zasilania, czas może być znany z dokładnością do
minuty.
3.12.9 Dane dotyczące usterek
Do celów niniejszego podpunktu czas rejestruje się z dokładnoś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:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 49
Usterka Zasady przechowywania Dane rejestrowane dla usterki
Usterka karty — 10 ostatnich usterek karty kierowcy — data i godzina początku usterki
— data i godzina końca usterki
— typ karty, numer, państwo członkowskie
wydające kartę i generacja
Usterki urządzenia rejes­
trującego
— 10 ostatnich usterek dla każdego typu
usterki
— pierwsza usterka po ostatniej kalibracji
— data i godzina początku usterki
— data i godzina końca usterki
— rodzaj usterki
— typ karty, numer, państwo członkowskie
wydające kartę i generacja dla każdej
karty wprowadzonej na początku lub
pod koniec usterki
3.12.10 Dane kalibracyjne
119) Urządzenie rejestrujące rejestruje i przechowuje w pamięci
następujące dane:
— parametry kalibracyjne znane w momencie aktywacji,
— pierwszą kalibrację po aktywacji urządzenia,
— pierwszą kalibrację w obecnym pojeździe (identyfiko­
wanym numerem VIN),
— 20 ostatnich kalibracji (jeżeli w czasie jednego dnia
kalendarzowego jest kilka kalibracji, zapamiętywana
jest tylko pierwsza i ostatnia kalibracja z tego dnia).
120) Przy każdej z tych kalibracji rejestruje się następujące dane:
— cel kalibracji (aktywacja, pierwsza instalacja, instalacja,
przegląd okresowy),
— nazwa i adres warsztatu,
— numer karty warsztatowej, państwo członkowskie
wydające kartę i termin ważności karty,
— identyfikacja pojazdu,
— parametry uaktualnione lub potwierdzone: w, k, l,
rozmiar opon, ustawienia urządzenia ograniczenia pręd­
kości, licznik kilometrów (wartości stare i nowe), data
i godzina (wartości stare i nowe),
— rodzaje i identyfikatory wszystkich założonych plomb ,
▼M3
— numery seryjne czujnika ruchu, urządzenia zewnętrz­
nego GNSS (jeżeli występuje) oraz zewnętrznego urzą­
dzenia do łączności na odległość (jeżeli występuje),
— domyślny typ załadunku związanego z pojazdem (zała­
dunek towarów albo pasażerów),
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 50
— kraj, w którym wykonano kalibrację, oraz datę i godzinę
dostarczenia przez odbiornik GNSS pozycji wykorzys­
tanej do określenia tego kraju.
▼B
121) Ponadto urządzenie rejestrujące rejestruje i przechowuje
w pamięci danych zdolność do użytkowania kart do tacho­
grafów pierwszej generacji (aktywowaną lub nie).
122) Czujnik ruchu rejestruje i przechowuje w pamięci następu­
jące dane instalacyjne czujnika ruchu:
— pierwsze sparowanie z przyrządem rejestrującym (data,
godzina, numer homologacji przyrządu rejestrującego,
numer seryjny przyrządu rejestrującego),
— ostatnie sparowanie z przyrządem rejestrującym (data,
godzina, numer homologacji przyrządu rejestrującego,
numer seryjny przyrządu rejestrującego).
123) Urządzenie zewnętrzne GNSS rejestruje i przechowuje
w pamięci następujące dane instalacyjne urządzenia
zewnętrznego GNSS:
— pierwsze powiązanie z przyrządem rejestrującym (data,
godzina, numer homologacji przyrządu rejestrującego,
numer seryjny przyrządu rejestrującego),
— ostatnie powiązanie z przyrządem rejestrującym (data,
godzina, numer homologacji przyrządu rejestrującego,
numer seryjny przyrządu rejestrującego).
3.12.11 Dane dotyczące korekty czasu
124) Urządzenie rejestrujące rejestruje i przechowuje w pamięci
danych dane dotyczące korekty czasu przeprowadzonej
w trybie kalibracyjnym, poza ramami regularnej kalibracji
(def. f)):
— ostatnia korekta czasu,
— 5 największych korekt czasu.
125) Przy każdej z tych korekt czasu rejestruje się następujące
dane:
— data i godzina, stara wartość,
— data i godzina, nowa wartość,
— nazwa i adres warsztatu,
— numer karty warsztatowej, państwo członkowskie
wydające kartę, generacja karty i termin ważności karty.
3.12.12 Dane dotyczące czynności kontrolnych
126) Urządzenie rejestrujące rejestruje i przechowuje w pamięci
danych następujące dane dotyczące ostatnich 20 czynności
kontrolnych:
— data i godzina kontroli,
— numer karty kontrolnej, państwo członkowskie wyda­
jące kartę i generacja karty,
— rodzaj kontroli (wyświetlanie lub drukowanie lub pobie­
ranie danych z przyrządu rejestrującego lub karty lub
kontrola drogowa kalibracji).
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 51
127) W przypadku pobierania danych rejestruje się także daty
najstarszych i najnowszych dni, z których dane są pobierane.
3.12.13 Dane dotyczące blokad firmowych
128) Urządzenie rejestrujące rejestruje i przechowuje w pamięci
następujące dane dotyczące 255 ostatnich blokad
firmowych:
— data i godzina założenia blokady,
— data i godzina zdjęcia blokady,
— numer karty firmowej, państwo członkowskie wydające
kartę i generacja karty,
— nazwa i adres firmy.
Dane wcześniej zabezpieczone przez blokadę usunięte
z pamięci z powodu powyższego ograniczenia traktuje się
jako niezabezpieczone.
3.12.14 Dane dotyczące pobierania danych
129) Urządzenie rejestrujące rejestruje i przechowuje w pamięci
danych następujące dane dotyczące ostatniego pobierania
danych z pamięci urządzenia na nośnik zewnętrzny, wyko­
nanego w trybie firmowym lub kalibracyjnym:
— data i godzina pobrania danych,
— numer karty firmowej lub warsztatowej, państwo człon­
kowskie wydające kartę i generacja karty,
— nazwa firmy lub warsztatu.
3.12.15 Dane dotyczące warunków szczególnych
130) Urządzenie rejestrujące rejestruje i przechowuje w pamięci
danych następujące dane dotyczące warunków szczegól­
nych:
— data i godzina wprowadzenia danych,
— rodzaj warunku szczególnego.
131) Pamięć danych umożliwia przechowywanie danych doty­
czących warunków szczególnych przez co najmniej 365 dni
(przy założeniu, że przeciętnie otwiera się i zamyka jeden
warunek dziennie). W przypadku zapełnienia pamięci
danych nowe dane zastępują dane najstarsze.
3.12.16 Dane karty do tachografu
132) Urządzenie rejestrujące umożliwia przechowywanie nastę­
pujących danych dotyczących różnych kart do tachografów,
które zostały użyte w przyrządzie rejestrującym:
— numer karty do tachografu i jej numer seryjny,
— producent karty do tachografu,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 52
— typ karty do tachografu,
— wersja karty do tachografu.
133) Urządzenie rejestrujące umożliwia przechowywanie co
najmniej 88 takich rekordów danych.
▼M3
3.12.17 Przekroczenia granicy
133a) Urządzenie rejestrujące rejestruje i przechowuje w pamięci
danych następujące informacje na temat przekroczeń
granicy:
— kraj, który pojazd opuszcza,
— kraj, do którego pojazd wjeżdża,
— pozycję, gdzie pojazd przekroczył granicę.
133b) Wraz z krajami i pozycją urządzenie rejestrujące rejestruje
i przechowuje w pamięci następujące dane:
— numer karty kierowcy lub współkierowcy i państwo
członkowskie wydające kartę,
— generacja karty,
— odpowiednia dokładność GNSS, data i godzina,
— flagę wskazującą, czy pozycja została uwierzytelniona,
— stan licznika kilometrów w momencie wykrycia prze­
kroczenia granicy.
133c) Pamięć danych wystarcza do przechowywania danych doty­
czących przekroczeń granicy przez co najmniej 365 dni.
133d) W przypadku zapełnienia pamięci danych nowe dane zastę­
pują dane najstarsze.
3.12.18 Operacje załadunku/rozładunku
133e) Urządzenie rejestrujące rejestruje i przechowuje w pamięci
danych następujące informacje na temat operacji załadunku
i rozładunku pojazdu:
— typ operacji (załadunek, rozładunek lub równoczesny
załadunek/rozładunek),
— pozycję, gdzie miała miejsce operacja załadunku/rozła­
dunku.
133f) Jeżeli w momencie operacji załadunku/rozładunku pozycja
pojazdu nie jest dostępna z odbiornika GNSS, urządzenie
rejestrujące korzysta z ostatniej dostępnej pozycji i odpowia­
dającej jej daty i godziny.
133g) Wraz z typem operacji i pozycją urządzenie rejestrujące
rejestruje i przechowuje w pamięci następujące dane:
— numer karty kierowcy lub współkierowcy i państwo
członkowskie wydające kartę,
— generacja karty,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 53
— data i godzina operacji załadunku/rozładunku,
— w stosownych przypadkach odpowiednia dokładność
GNSS, data i godzina,
— flagę wskazującą, czy pozycja została uwierzytelniona,
— stan licznika kilometrów.
133h) Pamięć danych wystarcza do przechowywania danych doty­
czących operacji załadunku/rozładunku przez co najmniej
365 dni kalendarzowych.
133i) W przypadku zapełnienia pamięci danych nowe dane zastę­
pują dane najstarsze.
3.12.19 Mapa cyfrowa
133j) Do celów rejestrowania pozycji pojazdu po przekroczeniu
granicy krajowej urządzenie rejestrujące przechowuje
w swojej pamięci danych mapę cyfrową.
133k) Dopuszczone mapy cyfrowe wspierające funkcję monitoro­
wania przekroczeń granicy przez urządzenie rejestrujące są
udostępniane przez Komisję Europejską do pobrania ze
specjalnej zabezpieczonej strony internetowej w różnych
formatach.
133l) W przypadku każdej z tych map na stronie internetowej
udostępnia się identyfikator wersji i wartość skrótu.
133m) Mapy muszą mieć:
— poziom szczegółowości odpowiadający poziomowi
NUTS 0, zgodnie ze wspólną klasyfikacją jednostek
terytorialnych do celów statystycznych,
— skalę 1:1 mln.
133n) Producenci tachografów wybierają mapę ze strony interne­
towej i pobierają ją w bezpieczny sposób.
133o) Producenci tachografów wykorzystują mapę pobraną ze
strony internetowej dopiero po sprawdzeniu jej integral­
ności przy użyciu wartości skrótu mapy.
133p) Wybrana mapa jest importowana przez producenta do urzą­
dzenia rejestrującego we właściwym formacie, ale seman­
tyczna importowanej mapy pozostaje bez zmian.
133q) Producent przechowuje również identyfikator wersji mapy
wykorzystywanej w urządzeniu rejestrującym.
133r) Możliwa jest aktualizacja lub zastąpienie przechowywanej
mapy cyfrowej nową mapą udostępnioną przez Komisję
Europejską.
133s) Aktualizacje mapy cyfrowej przeprowadza się przy użyciu
mechanizmów aktualizacji oprogramowania ustalonych
przez producenta, zgodnie z wymogami 226d i 226e, tak
aby urządzenie rejestrujące mogło zweryfikować autentycz­
ność i integralność nowej importowanej mapy przed jej
zapisaniem i zastąpieniem poprzedniej mapy.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 54
133t) Producenci tachografów mogą dodać dodatkowe informacje
do mapy podstawowej, o której mowa w wymogu 133 m,
w celach innych niż rejestrowanie przekroczeń granicy, np.
granic regionów UE, pod warunkiem że nie nastąpi zmiana
semantyki mapy podstawowej.
▼B
3.13 Odczyt kart do tachografów
134) Urządzenie rejestrujące umożliwia odczyt z kart do tacho­
grafów pierwszej i drugiej generacji, w odpowiednich przy­
padkach, danych niezbędnych do:
— rozpoznania typu karty, posiadacza karty, wcześniej
używanego pojazdu, daty i godziny ostatniego wyjęcia
karty i czynności wybranej dla tego czasu,
— sprawdzenia, czy ostatnia sesja karty została prawid­
łowo zamknięta,
▼M3
— wyliczenia dla kierowcy: nieprzerwanego czasu prowa­
dzenia pojazdu, skumulowanego czasu przerwy i skumu­
lowanego czasu prowadzenia za poprzedni i bieżący
tydzień,
▼B
— wydrukowania żądanych wydruków związanych
z danymi zarejestrowanymi na karcie kierowcy,
— pobrania danych z karty kierowcy na zewnętrzny
nośnik.
Wymóg ten ma zastosowanie tylko do kart do tachografów
pierwszej generacji, jeżeli ich stosowanie nie zostało wyłą­
czone przez warsztat.
135) W przypadku błędu odczytu urządzenie rejestrujące maksy­
malnie trzykrotnie powtarza to samo polecenie odczytu
i w przypadku gdy odczyt nadal nie jest możliwy, uznaje
kartę za uszkodzoną i nieważną.
▼M3
135a) Struktura aplikacji „TACHO_G2” zależy od wersji. Karty
wersji 2 zawierają dodatkowe pliki elementarne w stosunku
do kart wersji 1, w szczególności:
— w kartach kierowcy i warsztatowych:
— EF Places_Authentication zawiera status uwierzytel­
nienia pozycji pojazdu przechowywanych w EF
Places. Znacznik czasu jest przechowywany
z każdym statusem uwierzytelnienia, który musi
być dokładnie taki sam, jak data i godzina wpisu
przechowywanego z odpowiednią pozycją w EF
Places.
— EF GNSS_Places_Authentication zawiera status
uwierzytelnienia pozycji pojazdu przechowywanych
w EF GNSS_Places. Znacznik czasu jest przecho­
wywany z każdym statusem uwierzytelnienia, który
musi być dokładnie taki sam, jak data i godzina
wpisu przechowywanego z odpowiednią pozycją
w EF Places.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 55
— EF Border_Crossings, EF Load_Unload_Operations
oraz EF Load_Type_Entries zawierają dane doty­
czące przekroczeń granicy, operacji załadunku/
rozładunku oraz typów załadunku;
— w kartach warsztatowych:
— EF Calibration_Add_Data zawiera dodatkowe dane
kalibracyjne poza danymi przechowywanymi w EF
Calibration. Stara wartość daty i godziny oraz numer
identyfikacyjny pojazdu przechowywane są wraz
z każdym dodatkowym rekordem danych dotyczą­
cych kalibracji, który jest dokładnie taki sam, jak
stara wartość daty i godziny oraz numer identyfika­
cyjny pojazdu przechowywane wraz z odpowiednimi
danymi kalibracyjnymi w EF Calibration;
— we wszystkich kartach do tachografów:
— EF VU_Configuration zawiera szczegółowe usta­
wienia tachografu posiadacza karty.
Przyrząd rejestrujący nie uwzględnia żadnego statusu uwie­
rzytelnienia znalezionego w EF Places_Authentication lub
EF GNSS_Places_Authentication, jeżeli w EF Places lub
EF GNSS_Places nie znaleziono pozycji pojazdu z tym
samym znacznikiem czasu.
Przyrząd rejestrujący ignoruje plik elementarny EF VU_Confi­
guration we wszystkich kartach, o ile nie określono szczegó­
łowych zasad dotyczących korzystania z takiego pliku elemen­
tarnego. Zasady te określa się poprzez zmianę załącznika IC,
która obejmuje modyfikację lub uchylenie niniejszego punktu.
▼B
3.14 Rejestrowanie i przechowywanie danych na kartach do tacho­
grafów
3.14.1 Rejestrowanie i przechowywanie danych na kartach do tachografów
pierwszej generacji
136) O ile karty do tachografów pierwszej generacji nie zostały
wyłączone przez warsztat, urządzenie rejestrujące rejestruje
i przechowuje dane dokładnie w ten sam sposób co urzą­
dzenie rejestrujące pierwszej generacji.
137) Urządzenie rejestrujące ustawia „dane sesji karty” na 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,
wprowadzając wszystkie niezbędne dane odnośnie do
okresu, w którym karta pozostaje włożona, i odnośnie do
posiadacza karty. Dane, które są przechowywane na tych
kartach, określono w rozdziale 4.
139) Urządzenie rejestrujące aktualizuje dane dotyczące czyn­
ności kierowcy i miejsc (jak określono w pkt 4.5.3.1.9
i 4.5.3.1.11), zapisane na ważnej karcie kierowcy lub
warsztatowej, danymi dotyczącymi czynności i miejsc
wprowadzonymi ręcznie przez posiadacza karty.
▼M3
140) Wszystkie zdarzenia niezdefiniowane dla urządzeń rejestru­
jących pierwszej generacji nie są zapisywane na karcie
kierowcy ani na karcie warsztatowej.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 56
141) Aktualizacja kart do tachografów odbywa się w taki
sposób, że gdy zaistnieje taka potrzeba i biorąc pod
uwagę rzeczywistą zdolność przechowywania danych,
najstarsze dane są zastępowanymi najnowszymi danymi.
142) W przypadku błędu zapisu urządzenie rejestrujące maksy­
malnie trzykrotnie powtarza to samo polecenie zapisu
i w przypadku gdy zapis nadal nie jest możliwy, uznaje
kartę za uszkodzoną i nieważną.
▼M3
143) Przed odblokowaniem karty kierowcy lub karty warsz­
tatowej i po zapisaniu na karcie wszystkich stosownych
danych urządzenie rejestrujące zeruje „dane sesji karty”.
▼B
3.14.2 Rejestrowanie i przechowywanie danych na kartach do tachografów
drugiej generacji
144) Karty do tachografów drugiej generacji zawierają 2 różne
aplikacje kart, z których pierwsza jest dokładnie taka sama
jak aplikacja TACHO w kartach do tachografów pierwszej
generacji, a druga aplikacja „TACHO_G2” jest zgodna ze
specyfikacjami w rozdziale 4 i dodatku 2.
▼M3
Struktura aplikacji „TACHO_G2” zależy od wersji. Karty
wersji 2 zawierają dodatkowe pliki elementarne w stosunku
do kart wersji 1.
▼B
145) Urządzenie rejestrujące ustawia „dane sesji karty” na karcie
kierowcy lub warsztatowej bezpośrednio po włożeniu karty.
146) Urządzenie rejestrujące aktualizuje dane zapisane w 2 apli­
kacjach ważnej karty kierowcy, warsztatowej, firmowej lub
kontrolnej, wprowadzając wszystkie niezbędne dane
odnośnie do okresu, w którym karta pozostaje włożona,
i odnośnie do posiadacza karty. Dane, które są przechowy­
wane na tych kartach, określono w rozdziale 4.
147) Urządzenie rejestrujące aktualizuje dane dotyczące miejsc
i pozycji czynności kierowcy (jak określono w pkt
4.5.3.1.9, 4.5.3.1.11, 4.5.3.2.9 i 4.5.3.2.11), zapisane na
ważnej karcie kierowcy lub warsztatowej, danymi dotyczą­
cymi czynności i miejsc wprowadzonymi ręcznie przez
posiadacza karty.
▼M3
147a) Po włożeniu karty kierowcy lub karty warsztatowej urzą­
dzenie rejestrujące zapisuje na karcie domyślny typ zała­
dunku pojazdu.
147b) Po włożeniu karty kierowcy lub karty warsztatowej i po
ręcznej procedurze wprowadzania danych urządzenie rejes­
trujące sprawdza ostatnie miejsce rozpoczęcia lub zakoń­
czenia dziennego okresu pracy zapisane na karcie. Miejsce
to może mieć charakter tymczasowy, jak określono
w wymogu 59. Jeżeli miejsce to znajduje się w innym
kraju niż bieżący kraj, w którym pojazd się znajduje, urzą­
dzenie rejestrujące przechowuje na karcie rekord przekro­
czenia granicy wraz z następującymi danymi:
— krajem, który opuścił kierowca: niedostępne,
— krajem, do którego wjeżdża kierowca: bieżący kraj,
w którym pojazd się znajduje,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 57
— datą i godziną przekroczenia granicy przez kierowcę:
godzina włożenia karty,
— pozycją kierowcy po przekroczeniu granicy: niedo­
stępne,
— stanem licznika kilometrów: niedostępne.
▼B
148) Aktualizacja kart do tachografów odbywa się w taki sposób,
że gdy zaistnieje taka potrzeba i biorąc pod uwagę rzeczy­
wistą zdolność przechowywania danych, najstarsze dane są
zastępowanymi najnowszymi danymi.
149) W przypadku błędu zapisu urządzenie rejestrujące maksy­
malnie trzykrotnie powtarza to samo polecenie zapisu
i w przypadku gdy zapis nadal nie jest możliwy, uznaje
kartę za uszkodzoną i nieważną.
150) Przed odblokowaniem karty kierowcy i po zapisaniu
wszystkich stosownych danych w 2 aplikacjach karty urzą­
dzenie rejestrujące zeruje „dane sesji karty”.
▼M3
150a) Przyrząd rejestrujący ignoruje plik elementarny EF VU_Confi­
guration we wszystkich kartach, o ile nie określono szczegó­
łowych zasad dotyczących korzystania z takiego pliku elemen­
tarnego. Zasady te określa się poprzez zmianę załącznika IC,
która obejmuje modyfikację lub uchylenie niniejszego punktu.
▼B
3.15 Wyświetlanie
151) Wyświetlacz umożliwia wyświetlanie co najmniej 20
znaków.
152) Wyświetlane znaki mają wymiary co najmniej 5 mm wyso­
kości i 3,5 mm szerokości.
153) Wyświetlacz umożliwia wyświetlanie znaków określonych
w dodatku 1 rozdział 4 „Zestawy znaków”. Wyświetlacz
może wyświetlać uproszczone glify (np. znaki z akcentami
można wyświetlać bez akcentu, a małe litery może
wyświetlać jako duże).
154) Wyświetlacz musi mieć nieoślepiające oświetlenie.
155) Wskazania są widoczne spoza urządzenia rejestrującego.
156) Urządzenie rejestrujące umożliwia wyświetlanie:
— informacji standardowych,
— informacji związanych z ostrzeżeniami,
— informacji związanych z dostępem do menu,
— innych informacji, których zażąda użytkownik.
Urządzenie rejestrujące może wyświetlać również dodat­
kowe informacje, z tym jednak, że muszą być one łatwe
do odróżnienia od wymienionych powyżej, wymaganych
informacji.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 58
157) Na wyświetlaczu urządzenia rejestrującego używa się pikto­
gramów lub kombinacji piktogramów wymienionych
w dodatku 3. Dopuszcza się także dodatkowe piktogramy
lub kombinacje piktogramów, jeżeli są one łatwe do odróż­
nienia od wymaganych piktogramów lub kombinacji pikto­
gramów.
158) Gdy pojazd jest w ruchu, wyświetlacz jest stale włączony.
159) Urządzenie rejestrujące może gasić wyświetlacz automa­
tycznie lub umożliwiać gaszenie ręczne, gdy pojazd nie
jest w ruchu.
Format wyświetlania określono w dodatku 5.
3.15.1 Domyślne informacje na wyświetlaczu
160) Gdy nie istnieje potrzeba wyświetlania żadnych innych
informacji, urządzenie rejestrujące domyślnie wyświetla
następujące informacje:
— czas lokalny (wynik czasu UTC + przesunięcie wpro­
wadzone przez kierowcę),
— tryb pracy,
— bieżącą czynność kierowcy i bieżącą czynność współ­
kierowcy,
— informacje odnoszące się do kierowcy:
— jeżeli jego bieżącą czynnością jest PROWADZENIE,
jego bieżący nieprzerwany czas prowadzenia pojazdu
i jego bieżący skumulowany czas przerwy,
— jeżeli jego bieżącą czynnością nie jest PROWA­
DZENIE, bieżący czas trwania tej czynności (od
momentu wybrania) i jego bieżący skumulowany czas
przerwy.
161) Prezentacja informacji odnoszących się do każdego
kierowcy jest wyraźna, prosta i jednoznaczna. W przypadku
gdy informacji odnoszących się do kierowcy i współkie­
rowcy nie można wyświetlić w tym samym czasie, urzą­
dzenie rejestrujące pokazuje domyślnie informacje odno­
szące się do kierowcy i pozwala użytkownikowi wyświetlić
informacje odnoszące się do współkierowcy.
162) W przypadku gdy wyświetlacz nie pozwala na domyślne
pokazywanie trybu pracy, to przy zmianie trybu pracy urzą­
dzenie rejestrujące przez krótki czas pokazuje informację
o nowym trybie pracy.
163) Przy wkładaniu karty urządzenie rejestrujące przez krótki
czas pokazuje nazwisko jej posiadacza.
164) W przypadku otwarcia warunku „POZA ZAKRESEM” lub
„PRZEPRAWA PROMOWA/PRZEJAZD KOLEJOWY”
na domyślnym wyświetlaczu musi pojawić się informacja
w postaci stosownego piktogramu o tym, że warunek ten
jest rozpoczęty (dopuszcza się, że w tym samym czasie nie
jest pokazywana bieżąca czynność kierowcy).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 59
3.15.2 Wyświetlanie ostrzeżeń
165) Przy wyświetlaniu ostrzeżeń urządzenie rejestrujące
korzysta przede wszystkim z piktogramów w dodatku 3,
w razie potrzeby uzupełnionych informacjami w postaci
kodów liczbowych. Można też dodać wyszczególnienie
słowne w preferowanym języku kierowcy.
3.15.3 Dostęp do menu
166) Urządzenie rejestrujące udostępnia niezbędne polecenia
poprzez odpowiednie menu.
3.15.4 Inne wyświetlane informacje
167) Na żądanie możliwe jest selektywne wyświetlanie:
— czasu UTC oraz przesunięcia czasu lokalnego,
▼M3
— treści każdego z wydruków wymienionych w wymogu
169 w takich samych formatach co wydruki,
▼B
— nieprzerwanego czasu prowadzenia pojazdu i skumulo­
wanego czasu przerwy kierowcy,
— nieprzerwanego czasu prowadzenia pojazdu i skumulo­
wanego czasu przerwy współkierowcy,
▼M3
— skumulowanego czasu prowadzenia pojazdu przez
kierowcę za poprzedni i bieżący tydzień,
— skumulowanego czasu prowadzenia pojazdu przez
współkierowcę za poprzedni i bieżący tydzień,
▼B
opcjonalnie:
— bieżącego czasu trwania czynności współkierowcy (od
momentu wybrania),
▼M3
— skumulowanego czasu prowadzenia pojazdu przez
kierowcę za bieżący tydzień,
— skumulowanego czasu prowadzenia pojazdu przez
współkierowcę za bieżący dzienny okres pracy,
— skumulowanego czasu prowadzenia pojazdu przez
kierowcę za bieżący dzienny okres pracy.
▼B
168) Treść wydruku jest wyświetlana sekwencyjnie, wiersz po
wierszu. Jeżeli w szerokości wyświetlacza mieści się mniej
niż 24 znaki, użytkownik musi mieć dostęp do pełnej infor­
macji w odpowiedni sposób (w kilku wierszach, przy
pomocy przewijania itp.).
Wiersze wydruku przeznaczone na ręczne adnotacje można
pominąć na wyświetlaczu.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 60
3.16 Drukowanie
169) Urządzenie rejestrujące umożliwia drukowanie siedmiu
określonych poniżej wydruków, na podstawie informacji
zgromadzonych w pamięci urządzenia lub na kartach do
tachografów:
— wydruk dzienny czynności kierowcy z karty,
— wydruk dzienny czynności kierowcy z przyrządu rejes­
trującego,
— wydruk zdarzeń i usterek z karty,
— wydruk zdarzeń i usterek z przyrządu rejestrującego,
— wydruk danych technicznych,
— wydruk przekroczenia prędkości,
— historia danych karty do tachografu dla danego przy­
rządu rejestrującego (zob. rozdział 3.12.16).
Szczegóły formatu i treści tych wydruków określono
w dodatku 4.
Pod koniec wydruku mogą być umieszczane informacje
dodatkowe.
Urządzenie rejestrujące może wykonywać także dodatkowe
wydruki, jeżeli są one łatwe do odróżnienia od siedmiu
określonych powyżej wydruków.
170) „Wydruk dzienny czynności kierowcy z karty” i „wydruk
zdarzeń i usterek z karty” dostępne są jedynie wtedy, gdy
do urządzenia rejestrującego włożona jest karta kierowcy
lub karta warsztatowa. Przed uruchomieniem drukowania
urządzenie rejestrujące aktualizuje dane przechowywane
na stosownej karcie.
171) W celu sporządzenia „wydruku dziennego czynności
kierowcy z karty” lub „wydruku zdarzeń i usterek z karty”
urządzenie rejestrujące:
— automatycznie wybiera kartę kierowcy lub kartę warsz­
tatową, jeżeli tylko jedna z tych kart jest włożona do
urządzenia rejestrującego,
— lub umożliwia wybór karty źródłowej albo wybiera
kartę znajdującą się w czytniku karty kierowcy, jeżeli
obie te karty włożone są do urządzenia rejestrującego.
172) Drukarka umożliwia drukowanie 24 znaków w wierszu.
173) Drukowane znaki mają wymiary co najmniej 2,1 mm
wysokości i 1,5 mm szerokości.
174) Drukarka umożliwia drukowanie znaków określonych
w dodatku 1 rozdział 4 „Zestawy znaków”.
175) Konstrukcja drukarki umożliwia sporządzanie wydruków
z rozdzielczością eliminującą niejednoznaczność przy
odczycie.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 61
176) Wydruki zachowują wymiary i treść w warunkach
normalnej wilgotności (10–90 %) i temperatury.
177) Papier homologowany używany w urządzeniu rejestrującym
musi mieć odpowiedni znak homologacji typu i oznako­
wanie typu (typów) urządzenia rejestrującego, w którym
może być używany.
178) Wydruki muszą być łatwe do odczytania i rozróżnienia,
gdy są przechowywane w normalnych warunkach przecho­
wywania, w normalnym oświetleniu, wilgotności i tempera­
turze, przez okres co najmniej dwóch lat.
179) Wydruki muszą być zgodne co najmniej ze specyfikacjami
testów podanymi w dodatku 9.
180) Na wydruku musi być również możliwość umieszczenia
ręcznych adnotacji, takich jak podpis kierowcy.
181) Urządzenie rejestrujące obsługuje zdarzenia „brak papieru”
w czasie drukowania, a po założeniu papieru, uruchamia
drukowanie od początku wydruku lub kontynuuje druko­
wanie i umieszcza jednoznaczne odniesienie do części
wcześniej wydrukowanej.
3.17 Ostrzeżenia
182) Urządzenie rejestrujące ostrzega kierowcę o wykryciu
zdarzenia lub usterki.
183) Ostrzeżenie o przerwie w zasilaniu może być opóźnione do
czasu przywrócenia zasilania.
184) Urządzenie rejestrujące ostrzega kierowcę na 15 minut
przed przekroczeniem i w momencie przekroczenia maksy­
malnego dopuszczalnego nieprzerwanego czasu prowa­
dzenia pojazdu.
185) Ostrzeżenia są wizualne. Oprócz ostrzeżeń wizualnych
dopuszcza się ostrzeżenia akustyczne.
186) Ostrzeżenia wizualne muszą być łatwo rozpoznawalne
przez użytkownika, znajdować się w polu widzenia
kierowcy i być łatwe do odczytania tak w dzień, jak
i w nocy.
187) Ostrzeżenia wizualne mogą być emitowane bezpośrednio
przez urządzenie rejestrujące lub zdalnie od urządzenia
rejestrującego.
188) W tym ostatnim przypadku są oznaczone symbolem „T”.
189) Ostrzeżenia trwają przez przynajmniej 30 sekund, chyba że
są potwierdzone przez użytkownika poprzez wciśnięcie
jednego lub większej liczby specjalnych przycisków w urzą­
dzeniu rejestrującym. To pierwsze potwierdzenie nie usuwa
z wyświetlacza informacji o przyczynie ostrzeżenia, o której
mowa w następnym punkcie.
190) Urządzenie rejestrujące wyświetla informację o przyczynie
ostrzeżenia, aż do momentu potwierdzenia przez użytkow­
nika przy pomocy specjalnego przycisku lub polecenia
urządzenia rejestrującego.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 62
191) Dopuszcza się dodatkowe ostrzeżenia, pod warunkiem że
nie są mylące dla kierowców w odniesieniu do wcześniej
zdefiniowanych ostrzeżeń.
3.18 Pobieranie danych na nośnik zewnętrzny
192) Urządzenie rejestrujące umożliwia, na żądanie, pobieranie
danych z pamięci danych lub karty kierowcy na zewnętrzny
nośnik poprzez gniazdo kalibracji/pobierania danych. Przed
pobraniem danych urządzenie rejestrujące aktualizuje dane
przechowywane na stosownej karcie.
▼M3
193) Dodatkowo i opcjonalnie, urządzenie rejestrujące może
w dowolnym trybie pracy przesyłać dane poprzez dowolny
inny interfejs do firmy uwierzytelnionej do korzystania
z tego kanału. W takim przypadku do tak przesyłanych
danych stosuje się prawa dostępu obowiązujące dla trybu
firmowego.
▼B
194) Przy pobieraniu danych nie może mieć miejsca zmienianie
ani usuwanie jakichkolwiek przechowywanych danych.
195) Specyfikacje elektrycznego interfejsu dla gniazda kalibracji/
pobierania danych są określone w dodatku 6.
196) Protokoły pobierania danych są określone w dodatku 7.
▼M3
196a) Przedsiębiorstwo transportowe wykorzystujące pojazdy
wyposażone w urządzenia rejestrujące zgodne z niniejszym
załącznikiem i objęte zakresem stosowania rozporzą­
dzenia (WE) nr 561/2006 zapewnia pobieranie wszystkich
danych z przyrządu rejestrującego i kart kierowcy.
Maksymalny okres na wczytanie odpowiednich danych nie
przekracza:
— 90 dni w przypadku danych z przyrządu rejestrującego;
— 28 dni w przypadku danych z karty kierowcy.
196b) Przedsiębiorstwa transportowe przechowują dane pobrane
z przyrządu rejestrującego i kart kierowcy przez okres co
najmniej dwunastu miesięcy od ich zarejestrowania.
▼B
3.19 Łączność na odległość na potrzeby ukierunkowanych kontroli
drogowych
197) Przy włączonym zapłonie przyrząd rejestrujący co 60
sekund zachowuje na urządzeniu do łączności na odległość
najnowsze dane niezbędne na potrzeby ukierunkowanych
kontroli drogowych. Dane takie są szyfrowane i podpisy­
wane zgodnie z dodatkiem 11 i dodatkiem 14.
198) Kontrolowane zdalnie dane muszą być dostępne dla czyt­
ników na odległość za pośrednictwem łączności bezprzewo­
dowej, jak określono w dodatku 14.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 63
199) Dane niezbędne na potrzeby ukierunkowanych kontroli
drogowych odnoszą się do:
— ostatniej próby naruszenia zabezpieczenia,
— najdłuższej przerwy w zasilaniu,
— usterki czujnika,
— błędu danych dotyczących ruchu,
— konfliktu ruchu pojazdu,
— prowadzenia pojazdu bez ważnej karty,
— włożenia karty podczas prowadzenia pojazdu,
— danych dotyczących korekty czasu,
— danych kalibracyjnych, w tym dat dwóch ostatnio zapi­
sanych rekordów danych kalibracji,
— numeru rejestracyjnego pojazdu,
— prędkości zarejestrowanej przez tachograf,
▼M3
— pozycji pojazdu,
— wskazania, czy kierowca prawdopodobnie narusza
obecnie czas prowadzenia pojazdu.
3.20 Wymiana danych z dodatkowymi urządzeniami zewnętrznymi
200) Urządzenie rejestrujące musi być również wyposażone
w interfejs ITS zgodnie z dodatkiem 13, który umożliwia
korzystanie przez urządzenie zewnętrzne z danych rejestro­
wanych lub generowanych przez tachograf lub karty do
tachografu.
W trybie eksploatacyjnym wymagana jest zgoda kierowcy
na przesyłanie danych osobowych za pośrednictwem inter­
fejsu ITS. Niemniej jednak zgoda kierowcy nie ma zasto­
sowania do danych tachografu lub karty, do których uzys­
kano dostęp w trybie kontrolnym, firmowym lub kalibra­
cyjnym. Dane i funkcjonalne prawa dostępu dla tych
trybów określono w wymogach 12 i 13.
Następujące wymogi mają zastosowanie do danych ITS
udostępnianych za pośrednictwem tego interfejsu:
— dane osobowe są udostępniane wyłącznie po uzyskaniu
możliwej do zweryfikowania zgody kierowcy na to, aby
dane osobowe z tachografu mogły opuścić sieć pojazdu.
Zestaw wybranych istniejących danych, które mogą być
dostępne za pośrednictwem interfejsu ITS, oraz klasyfi­
kację danych jako danych osobowych lub nieosobo­
wych określono w dodatku 13. Oprócz zestawu danych
przedstawionego w dodatku 13 mogą być również
generowane dodatkowe dane. Producent VU klasyfikuje
te dane jako „osobowe” lub „nieosobowe”, a zgoda
kierowcy dotyczy danych sklasyfikowanych jako
„osobowe”,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 64
— w dowolnym momencie istnieje możliwość potwier­
dzenia lub wycofania zgody kierowcy przez wybranie
polecenia w menu, pod warunkiem że karta kierowcy
jest włożona,
— w żadnych okolicznościach obecność interfejsu ITS nie
może zakłócać prawidłowego funkcjonowania i bezpie­
czeństwa przyrządu rejestrującego ani oddziaływać na
niego.
Dodatkowe interfejsy przyrządu rejestrującego mogą współ­
istnieć, pod warunkiem że są w pełni zgodne z wymogami
określonymi w dodatku 13 w odniesieniu do zgody
kierowcy. Urządzenie rejestrujące musi posiadać zdolność
do podawania statusu zgody kierowcy innym platformom
w sieci pojazdu oraz urządzeniom zewnętrznym.
W przypadku danych osobowych wprowadzonych do sieci
pojazdu, które są dalej przetwarzane poza siecią pojazdu,
producent tachografów nie jest zobowiązany do zapew­
nienia zgodności procedury przetwarzania danych osobo­
wych z mającymi zastosowanie przepisami Unii dotyczą­
cymi ochrony danych.
Interfejs ITS umożliwia również wprowadzanie danych
podczas procedury ręcznego wprowadzania danych zgodnie
z wymogiem 61, zarówno przez kierowcę, jak i współkie­
rowcę.
Interfejs ITS może być również wykorzystywany do wpro­
wadzania dodatkowych informacji, w czasie rzeczywistym,
takich jak:
— wybór czynności kierowcy, zgodnie z wymogiem 46,
— miejsca, zgodnie z wymogiem 56,
— stany szczególne, zgodnie z wymogiem 62,
— operacje załadunku/rozładunku, zgodnie z wymogiem
62a.
Informacje te mogą być również wprowadzane za pośred­
nictwem innych interfejsów.
201) Do celów kompatybilności wstecznej możliwe jest wyposa­
żenie tachografów w interfejs szeregowy, jak określono
w załączniku IB do rozporządzenia (EWG) nr 3821/85
w ostatniej zmienionej wersji. Łącze szeregowe klasyfikuje
się jako część sieci pojazdu, zgodnie z wymogiem 200.
▼B
3.21 Kalibracja
202) Funkcja kalibracji umożliwia:
— automatyczne sparowanie czujnika ruchu z przyrządem
rejestrującym,
— automatyczne powiązanie urządzenia zewnętrznego
GNSS z przyrządem rejestrującym w stosownych
przypadkach,
— cyfrowe dostosowanie stałej urządzenia rejestrującego
(k) do współczynnika charakterystycznego pojazdu (w),
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 65
— regulację bieżącego wskazania czasu w zakresie okresu
ważności włożonej karty warsztatowej,
— regulację bieżącego wskazania licznika kilometrów,
— aktualizację danych identyfikacyjnych czujnika ruchu
zapisanych w pamięci danych,
— aktualizację, w stosownych przypadkach, danych iden­
tyfikacyjnych urządzenia zewnętrznego GNSS zapisa­
nych w pamięci danych,
— aktualizację rodzajów i identyfikatorów wszystkich
założonych plomb,
▼M3
— aktualizację lub potwierdzenie innych parametrów
używanych przez urządzenie rejestrujące: identyfikację
pojazdu, w, l, rozmiar opon i ustawienie urządzenia
ograniczenia prędkości, w stosownych przypadkach,
oraz domyślny typ załadunku,
— automatyczne zapisywanie kraju, w którym wykonano
kalibrację, oraz daty i godziny dostarczenia przez
odbiornik GNSS pozycji wykorzystanej do określenia
tego kraju.
▼B
203) Ponadto funkcja kalibracji umożliwia wyłączenie stoso­
wania kart do tachografów pierwszej generacji w urządzeniu
rejestrującym pod warunkiem spełnienia wymogów okre­
ślonych w dodatku 15.
204) Parowanie czujnika ruchu z przyrządem rejestrującym obej­
muje co najmniej:
— aktualizację danych instalacyjnych czujnika ruchu zapi­
sanych w pamięci czujnika ruchu (w razie potrzeby),
— skopiowanie z czujnika ruchu do pamięci danych przy­
rządu rejestrującego niezbędnych danych identyfikacyj­
nych czujnika ruchu.
▼M3
205) Powiązanie urządzenia zewnętrznego GNSS z przyrządem
rejestrującym obejmuje co najmniej:
— aktualizację danych instalacyjnych urządzenia zewnętrz­
nego GNSS przechowywanych na urządzeniu
zewnętrznym GNSS (w razie potrzeby),
— skopiowanie z urządzenia zewnętrznego GNSS do
pamięci danych przyrządu rejestrującego niezbędnych
danych identyfikacyjnych GNSS, w tym numeru seryj­
nego urządzenia zewnętrznego GNSS.
▼B
206) Funkcja kalibracji umożliwia wprowadzanie niezbędnych
danych poprzez gniazdo kalibracji/pobierania danych
zgodnie z protokołem kalibracji zdefiniowanym w dodatku
8. Funkcja kalibracji może także umożliwiać wprowadzanie
niezbędnych danych w inny sposób.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 66
3.22 Kontrola drogowa kalibracji
207) Funkcja kontroli drogowej kalibracji umożliwia odczyt
numeru seryjnego czujnika (ewentualnie wbudowanego
w adapter) oraz numeru seryjnego urządzenia zewnętrznego
GNSS (w odpowiednich przypadkach), podłączonych do
przyrządu rejestrującego w momencie wysłania żądania.
208) Odczyt musi być możliwy na wyświetlaczu przyrządu
rejestrującego przynajmniej przez wybranie poleceń
w menu.
209) Funkcja kontroli drogowej kalibracji umożliwia również
kontrolowanie wybranego trybu we/wy linii sygnałowej
we/wy kalibracji, określonej w dodatku 6, za pośrednic­
twem interfejsu K-line. Wykonuje się to poprzez ECUAd­
justmentSession, jak określono w dodatku 8 sekcja 7 Stero­
wanie impulsami testującymi – Jednostka funkcjonalna
sterowania we/wy.
▼M3
Jeżeli tryb we/wy linii sygnałowej we/wy kalibracji jest
aktywny zgodnie z tym wymogiem, przyrząd rejestrujący
nie uruchamia ostrzeżenia „Prowadzenie pojazdu bez
prawidłowej karty” (wymóg 75).
▼B
3.23 Korekta czasu
210) Funkcja korekty czasu umożliwia automatyczną korektę
bieżącego czasu. W urządzeniu rejestrującym korzysta się
z dwóch źródeł czasu do celów korekty czasu: 1)
wewnętrznego zegara przyrządu rejestrującego, 2) odbior­
nika GNSS.
▼M3
211) Ustawienia czasu wewnętrznego zegara przyrządu rejestru­
jącego są automatycznie korygowane w zmiennych odstę­
pach czasu. Kolejna automatyczna korekta czasu urucha­
miana jest między 72 a 168 godz. po poprzedniej korekcie
oraz po tym, jak VU będzie mógł uzyskać dostęp do czasu
GNSS za pomocą komunikatu o prawidłowej uwierzytel­
nionej pozycji zgodnie z dodatkiem 12. Niemniej jednak
korekta czasu nie może nigdy przekroczyć skumulowanego
maksymalnego dryftu czasu na dzień, obliczonego przez
producenta VU zgodnie z wymogiem 41b. Jeżeli różnica
między czasem wewnętrznego zegara VU a czasem odbior­
nika GNSS jest większa niż skumulowany maksymalny
dryft czasu na dzień, wówczas korekta czasu musi dosto­
sować zegar wewnętrzny VU możliwie jak najbliżej czasu
odbiornika GNSS. Ustawienia czasu można dokonać tylko
wówczas, gdy czas podawany przez odbiornik GNSS jest
uzyskiwany przy użyciu komunikatów o uwierzytelnionej
pozycji określonych w dodatku 12. Czasem odniesienia dla
automatycznego ustawienia czasu wewnętrznego zegara VU
jest czas podany w komunikacie o uwierzytelnionej
pozycji.
212) W trybie kalibracyjnym funkcja korekty czasu umożliwia
również wymuszoną korektę bieżącego czasu.
Warsztaty mogą korygować czas:
— albo zapisując wartość czasu w VU, korzystając z usługi
WriteDataByIdentifier zgodnie z sekcją 6.2 w dodatku 8,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 67
— albo poprzez zwrócenie się o dostosowanie zegara VU
do czasu podawanego przez odbiornik GNSS. Można
tego dokonać tylko wówczas, gdy czas podawany przez
odbiornik GNSS jest uzyskiwany przy użyciu komuni­
katów o uwierzytelnionej pozycji. W tym ostatnim
przypadku wykorzystuje się usługę RoutineControl
zgodnie z sekcją 8 w dodatku 8.
▼B
3.24 Parametry pracy
213) Przyrząd rejestrujący musi być w pełni funkcjonalny
w zakresie temperatur – 20–70 °C, urządzenie zewnętrzne
GNSS w zakresie temperatur – 20–70 °C, a czujnik ruchu
w zakresie temperatur – 40–135 °C. Zawartość pamięci
danych jest zachowywana w temperaturach do – 40 °C.
214) Tachograf zachowuje pełną funkcjonalność w zakresie
wilgotności 10–90 %.
215) Plomby używane w tachografach inteligentnych muszą być
wytrzymałe w takich samych warunkach, co warunki stoso­
wane względem elementów składowych tachografu, do
których są dołączone.
216) Urządzenie rejestrujące jest zabezpieczone przed przepię­
ciami, odwróceniem biegunowości zasilania i zwarciami.
217) Czujniki ruchu muszą:
— reagować na pole magnetyczne, które zakłóca wykry­
wanie ruchu pojazdu. W takich okolicznościach przy­
rząd rejestrujący zarejestruje i zapisze w pamięci
usterkę czujnika (wymaganie 88); albo
— posiadać czujnik, który jest chroniony przed polami
magnetycznymi lub odporny na nie.
218) Urządzenie rejestrujące oraz urządzenie zewnętrzne GNSS
muszą być zgodne z międzynarodowym regulaminem EKG
ONZ nr 10 oraz być zabezpieczone przed skutkami wyła­
dowań elektrostatycznych oraz stanów nieustalonych.
3.25 Materiały
219) Wszystkie części składowe urządzenia rejestrującego są
wykonane z materiałów o wystarczającej stabilności
i wytrzymałości mechanicznej oraz stabilnych właściwo­
ściach elektrycznych i magnetycznych.
220) W normalnych warunkach eksploatacji wszystkie części
wewnętrzne urządzeń są zabezpieczone przed wilgocią
i pyłem.
221) Przyrząd rejestrujący i urządzenie zewnętrzne GNSS muszą
spełniać wymagania klasy ochrony IP 40, a czujnik ruchu
musi spełniać wymagania klasy ochrony IP 64 zgodnie
z normą IEC 60529:1989 łącznie z A1:1999 i A2:2013.
222) Urządzenie rejestrujące musi spełniać odpowiednie wyma­
gania techniczne odnoszące się do ergonomii.
223) Urządzenie rejestrujące jest zabezpieczone przed przypad­
kowym uszkodzeniem.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 68
3.26 Oznakowania
224) Jeżeli urządzenie rejestrujące pokazuje stan licznika kilo­
metrów i prędkość, na wyświetlaczu widoczne są następu­
jące informacje:
— przy liczbie pokazującej odległość, jednostka miary
odległości wskazana skrótem „km”,
— przy liczbie pokazującej prędkość, jednostka „km/h”.
Urządzenie rejestrujące może być również przełączane na
wskazywanie prędkości w milach na godzinę, w takim
przypadku jednostka pomiaru prędkości jest wskazana
skrótem „mph”. Urządzenie rejestrujące może być również
przełączane na wskazywanie odległości w milach, w takim
przypadku jednostka pomiaru odległości jest wskazana
skrótem „mi”.
▼M1
225) Do każdego odrębnego elementu składowego urządzenia
rejestrującego jest przymocowana tabliczka zawierająca
następujące informacje:
— nazwa i adres producenta,
— numer części producenta i rok produkcji,
— numer seryjny,
— znak homologacji typu.
226) Jeżeli dostępna powierzchnia nie wystarcza do umiesz­
czenia wszystkich powyższych informacji, na tabliczce
umieszcza się przynajmniej: nazwę producenta lub jego
logo i numer części.
▼M3
3.27 Monitorowanie przekroczeń granicy
226a) Funkcja ta wykrywa, kiedy pojazd przekroczył granicę
krajową, który kraj opuścił oraz do którego kraju wjechał.
226b) Wykrywanie przekroczenia granicy opiera się na pozycji
zmierzonej przez urządzenie rejestrujące oraz mapie
cyfrowej przechowywanej zgodnie z pkt 3.12.19.
226c) Przekroczenia granicy związane z obecnością pojazdu
w danym kraju przez okres krótszy niż 120 s nie są
rejestrowane.
3.28 Aktualizacja oprogramowania
226d) Przyrząd rejestrujący musi posiadać funkcję wdrażania
aktualizacji oprogramowania, jeżeli takie aktualizacje nie
wymagają dostępności dodatkowych zasobów sprzętowych
wykraczających poza zasoby określone w wymogu 226f,
a organy udzielające homologacji typu udzielają zezwolenia
na aktualizacje oprogramowania oparte na istniejącym przy­
rządzie rejestrującym posiadającym homologację typu,
zgodnie z art. 12 ust. 5 rozporządzenia (UE) nr 165/2014.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 69
226e) Funkcja aktualizacji oprogramowania musi być zaprojekto­
wana w taki sposób, aby wspierać następujące aspekty
funkcjonalne, jeżeli są one prawnie wymagane:
— modyfikacja funkcji, o których mowa w pkt 2.2,
z wyjątkiem samej funkcji aktualizacji oprogramowania,
— dodawanie nowych funkcji bezpośrednio związanych
z egzekwowaniem przepisów Unii dotyczących trans­
portu drogowego,
— modyfikacja trybów pracy określonych w pkt 2.3,
— modyfikacja struktury pliku, np. dodanie nowych
danych lub zwiększenie rozmiaru pliku,
— wdrożenie łatek oprogramowania w celu zaradzenia
usterkom oprogramowania oraz zabezpieczeń lub zgło­
szonym atakom na funkcje urządzenia rejestrującego.
226f) Przyrząd rejestrujący zapewnia bezpłatne zasoby sprzętowe
na poziomie co najmniej 35 % dla oprogramowania
i danych potrzebnych do wdrożenia wymogu 226e oraz
bezpłatne zasoby sprzętowe na poziomie co najmniej
65 % na potrzeby aktualizacji mapy cyfrowej w oparciu
o zasoby sprzętowe wymagane dla wersji mapy NUTS 0
z 2021 r.
▼B
4 WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE KART
DO TACHOGRAFÓW
4.1 Dane widzialne
Na awersie znajdują się:
227) słowa „Karta kierowcy” lub „Karta kontrolna” lub „Karta
warsztatowa” lub „Karta firmowa” nadrukowane wersali­
kiem w języku urzędowym lub językach urzędowych
państwa członkowskiego wydającego kartę, odpowiednio
do rodzaju karty;
228) nazwa państwa członkowskiego wydającego kartę (nieobo­
wiązkowo);
229) wyróżniający znak państwa członkowskiego wydającego
kartę, drukowany w negatywie w niebieskim prostokącie
i otoczony 12 żółtymi gwiazdami. Obowiązują następujące
oznaczenia:
B
BG
CZ
CY
Belgia
Bułgaria
Republika Czeska
Cypr
LV
L
LT
M
Łotwa
Luksemburg
Litwa
Malta
DK Dania NL Niderlandy
D
EST
Niemcy
Estonia
A
PL
Austria
Polska
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 70
GR Grecja P
RO
SK
SLO
Portugalia
Rumunia
Słowacja
Słowenia
E Hiszpania FIN Finlandia
F
HR
H
Francja
Chorwacja
Węgry
S Szwecja
IRL Irlandia UK Zjednoczone
Królestwo
I Włochy
230) informacje szczególne dla wydanej karty, ponumerowane
jak następuje:
Karta kierowcy Karta kontrolna Karta firmowa lub warsztatowa
1. Nazwisko kierowcy Nazwa organu kontrolnego Nazwa firmy lub warsztatu
2. Imię (imiona) kierowcy Nazwisko kontrolera
(w stosownych przypad­
kach)
Nazwisko posiadacza karty
(w stosownych przypad­
kach)
3. Data urodzenia kierowcy Imię (imiona) kontrolera
(w stosownych przypad­
kach)
Imię (imiona) posiadacza
karty
(w stosownych przypad­
kach)
4.a Data początku okresu ważności karty
4.b Termin ważności karty
4.c Nazwa organu wydającego (może być wydrukowana na rewersie)
4.d Numer inny niż w pozycji 5 do celów administracyjnych (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 — 21.08.2023 — 003.002 — 71
233) za szczególną pisemną zgodą posiadacza karty, na karcie
można dodatkowo umieścić informacje, które nie wiążą się
z administrowaniem kartą; takie dodatkowe informacje
w żaden sposób nie zmieniają sposobu używania danego
modelu jako karty do tachografów;
234) Karty do tachografów drukuje się w następujących domi­
nujących kolorach tła:
— karta kierowcy: biały,
— karta kontrolna: niebieski,
— karta warsztatowa: czerwony,
— karta firmowa: żółty.
235) Karty do tachografów muszą mieć przynajmniej następu­
jące zabezpieczenia przed fałszowaniem i manipulacjami:
— zabezpieczający wzór tła z drukowanym drobnym gilo­
szem i drukiem irysowym,
— w obszarze zdjęcia zabezpieczający wzór tła i zdjęcie
zachodzą na siebie,
— przynajmniej dwubarwną linię wykonaną techniką
mikrodruku.
► (1) M1
► (2) M3
236) Po konsultacji z Komisją państwa członkowskie mogą
dodać kolory lub oznakowania, takie jak symbole
państwowe i zabezpieczenia, bez uszczerbku dla innych
przepisów w niniejszym załączniku.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 72
237) Karty czasowe, o których mowa w art. 26 ust. 4 rozporzą­
dzenia (UE) nr 165/2014, muszą być zgodne z przepisami
niniejszego załącznika.
4.2 Zabezpieczenia
Celem systemu zabezpieczenia jest ochrona integralności i 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ępu­
jących norm:
— ISO/IEC 7810 Karty identyfikacyjne – Charakterystyki
fizyczne,
— ISO/IEC 7816 Karty identyfikacyjne – Karty stykowe:
— Część 1: Charakterystyki fizyczne,
— Część 2: Wymiary i rozmieszczenie styków
(ISO/IEC 7816-2:2007),
— Część 3: Interfejs elektryczny i protokoły transmisji
(ISO/IEC 7816-3:2006),
— Część 4: Organizacja, zabezpieczenia i polecenia
wymiany (ISO/IEC 7816-4:2013 + Cor 1:2014),
— Część 6: Elementy danych wymieniane z otocze­
niem, niezależne od dziedziny zastosowań (ISO/IEC
7816-6:2004 + Cor 1:2006),
— Część 8: Polecenia operacji zabezpieczających
(ISO/IEC 7816-8:2004).
— Karty do tachografów bada się zgodnie z normą
SO/IEC 10373-3:2010 Karty identyfikacyjne – Metody
badań – część 3: Elektroniczne karty stykowe i powią­
zane z nimi urządzenia interfejsowe.
4.4 Wymagania środowiskowe i elektryczne
241) Karty do tachografów muszą prawidłowo działać w warun­
kach klimatycznych normalnie występujących na terytorium
Wspólnoty, przynajmniej w zakresie temperatur od – 25–
+ 70 °C ze sporadycznymi temperaturami szczytowymi do
+ 85 °C, przy czym „sporadyczny” oznacza nie dłużej niż
4 godziny jednorazowo i nie więcej niż 100 razy w okresie
eksploatacji karty.
242) Karty do tachografów muszą działać prawidłowo w warun­
kach wilgotności 10 %–90 %.
243) Karty do tachografów muszą prawidłowo działać przez
okres pięciu lat, jeżeli są używane w zgodnie z warunkami
środowiskowymi i elektrycznymi.
244) W trakcie stosowania karty do tachografów muszą spełniać
wymogi regulaminu EKG ONZ nr 10 w odniesieniu do
kompatybilności elektromagnetycznej oraz muszą być chro­
nione przed wyładowaniami elektrostatycznymi.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 73
4.5 Przechowywanie danych
Do celów niniejszego pkt:
— czas jest rejestrowany z dokładnością do jednej minuty, chyba
że ustalono inaczej,
— stany licznika kilometrów rejestruje się z dokładnością do
jednego kilometra,
— prędkości rejestruje się z dokładnością do 1 km/h,
— pozycje (szerokość i długość ) rejestruje się w stopniach i 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ść
przechowywania danych dla różnych zbiorów danych apli­
kacyjnych. Karty do tachografów przekazują do urządzenia
rejestrującego bieżącą pojemność przechowywania danych
dla tych zbiorów danych.
▼M3
246) Wszelkie dodatkowe dane mogą być przechowywane na
kartach do tachografów, pod warunkiem że przechowy­
wanie tych danych jest zgodne z mającymi zastosowanie
przepisami dotyczącymi ochrony danych.
▼B
247) Każdy plik główny (MF) na każdej karcie do tachografu
zawiera maksymalnie pięć plików elementarnych (EF) do
zarządzania kartą, identyfikacji aplikacji i mikroprocesora
oraz dwa pliki dedykowane (DF):
— DF Tachograph, który zawiera aplikację dostępną dla
przyrządów rejestrujących pierwszej generacji, używaną
również w kartach do tachografów pierwszej generacji,
— DF Tachograph_G2, który zawiera aplikację dostępną
tylko dla przyrządów rejestrujących drugiej generacji,
używaną tylko w kartach do tachografów drugiej
generacji,
▼M3
Uwaga: wersja 2 drugiej generacji kart zawiera dodatkowe
pliki elementarne w DF Tachograph_G2.
▼B
Szczegółowe informacje o strukturze kart do tachografów
określono w dodatku 2.
4.5.1 Pliki elementarne do identyfikacji i zarządzania kartą
4.5.2 Identyfikacja kart mikroprocesorowych
248) Karty do tachografów umożliwiają przechowywanie nastę­
pujących danych identyfikujących kartę elektroniczną:
— zatrzymanie zegara,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 74
— numer seryjny karty (łącznie z numerem producenta),
— numer homologacji typu dla karty,
— identyfikator jednostki personalizującej kartę,
— identyfikator wbudowującego,
— identyfikator układu scalonego.
4.5.2.1 I d e n t y f i k a c j a m i k r o p r o c e s o r a
249) Karty do tachografów umożliwiają przechowywanie nastę­
pujących danych identyfikujących układ scalony (IC):
— numer seryjny układu scalonego,
— oznaczenie fabryczne układu scalonego.
4.5.2.2 D I R ( t y l k o w k a r t a c h d o t a c h o g r a f ó w d r u g i e j
g e n e r a c j i )
250) Karty do tachografów umożliwiają przechowywanie
obiektów danych identyfikujących aplikacje określonych
w dodatku 2.
4.5.2.3 I n f o r m a c j e A T R ( w a r u n k o w e , d o s t ę p n e t y l k o
w k a r t a c h d o t a c h o g r a f ó w d r u g i e j g e n e r a c j i )
251) Karty do tachografów umożliwiają przechowywanie nastę­
pujących obiektów danych informacji o rozszerzonej
długości:
— jeżeli karta do tachografów obsługuje pola o rozsze­
rzonej długości, obiekt danych informacji o rozszerzonej
długości określony w dodatku 2.
4.5.2.4 I n f o r m a c j e o r o z s z e r z o n e j d ł u g o ś c i ( w a r u n ­
k o w e , d o s t ę p n e t y l k o w k a r t a c h d o t a c h o g r a f ó w
d r u g i e j g e n e r a c j i )
252) Karty do tachografów umożliwiają przechowywanie nastę­
pujących obiektów danych informacji o rozszerzonej
długości:
— jeżeli karta do tachografów obsługuje pola o rozsze­
rzonej długości, obiekty danych informacji o rozsze­
rzonej długości określony w dodatku 2.
4.5.3 Karta kierowcy
4.5.3.1 A p l i k a c j a t a c h o g r a f i c z n a ( d o s t ę p n a d l a p r z y ­
r z ą d ó w r e j e s t r u j ą c y c h p i e r w s z e j i d r u g i e j g e n e ­
r a c j i )
4.5.3.1.1 Identyfikacja aplikacji
253) Karta kierowcy umożliwia przechowywanie następujących
danych identyfikujących aplikację:
— identyfikacja aplikacji tachograficznej,
— identyfikacja typu karty do tachografów.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 75
4.5.3.1.2 Klucz i certyfikaty
254) Karta kierowcy umożliwia przechowywanie szeregu kluczy
i certyfikatów kryptograficznych, jak określono w dodatku
11 część A.
4.5.3.1.3 Identyfikacja karty
255) Karta kierowcy umożliwia przechowywanie następujących
danych identyfikujących kartę:
— numer karty,
— państwo członkowskie wydające kartę, nazwa organu
wydającego, data wydania,
— data rozpoczęcia okresu ważności karty, termin
ważności karty.
4.5.3.1.4 Identyfikacja posiadacza karty
256) Karta kierowcy umożliwia przechowywanie następujących
danych identyfikujących posiadacza karty:
— nazwisko posiadacza karty,
— imię (imiona) posiadacza karty,
— data urodzenia,
— preferowany język.
4.5.3.1.5 Pobieranie danych z karty
257) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących pobierania danych:
— data i godzina ostatniego pobrania danych z karty (do
innych celów niż kontrola).
258) Karta kierowcy umożliwia przechowywanie jednego
takiego rekordu danych.
4.5.3.1.6 Dane dotyczące prawa jazdy
259) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących prawa jazdy:
— państwo członkowskie wydające, nazwa organu wyda­
jącego,
— numer prawa jazdy (w dniu wydania karty).
4.5.3.1.7 Dane dotyczące zdarzeń
Do celów niniejszego podpunktu czas zachowuje się z dokładnością
do 1 sekundy.
260) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących zdarzeń wykrytych przez urządzenie
rejestrujące przy włożonej karcie:
— nakładające się czasy (w przypadku gdy dana karta jest
przyczyną zdarzenia),
— włożenie karty podczas jazdy (w przypadku gdy dana
karta jest przedmiotem zdarzenia),
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 76
— sesja ostatniej karty niezamknięta prawidłowo (w przy­
padku gdy dana karta jest przedmiotem zdarzenia),
— przerwa w zasilaniu,
— błąd danych dotyczących ruchu,
— próby naruszenia zabezpieczenia.
261) Karta kierowcy umożliwia przechowywanie następujących
danych dla tych zdarzeń:
— kod zdarzenia,
— data i godzina rozpoczęcia zdarzenia (lub włożenia
karty, jeżeli zdarzenie trwało w tym czasie),
— data i godzina zakończenia zdarzenia (lub wyjęcia
karty, jeżeli zdarzenie trwało w tym czasie),
— numer VRN i państwo członkowskie rejestracji
pojazdu, w którym wystąpiło zdarzenie.
Uwaga: dla zdarzenia „nakładające się czasy”:
— data i godzina rozpoczęcia zdarzenia musi odpowiadać
dacie i godzinie wyjęcia karty z poprzedniego pojazdu,
— data i godzina zakończenia zdarzenia musi odpowiadać
dacie i godzinie włożenia karty w bieżącym pojeździe,
— dane pojazdu muszą odpowiadać bieżącemu pojazdowi
powodującemu zdarzenie.
Uwaga: dla zdarzenia „sesja ostatniej karty niezamknięta
prawidłowo”:
— data i godzina rozpoczęcia zdarzenia musi odpowiadać
dacie i godzinie włożenia karty dla sesji niezamkniętej
prawidłowo,
— data i godzina zakończenia zdarzenia musi odpowiadać
dacie i godzinie włożenia karty dla sesji, w czasie której
wykryto zdarzenie (bieżąca sesja),
— dane pojazdu muszą odpowiadać pojazdowi, w którym
sesja nie została zamknięta prawidłowo.
262) Karta kierowcy umożliwia przechowywanie danych doty­
czących sześciu ostatnich zdarzeń każdego typu (łącznie
36 zdarzeń).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 77
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
rejestrujące przy włożonej karcie:
▼M1
— usterka karty (w przypadku gdy dana karta jest przed­
miotem usterki),
▼B
— usterka urządzenia rejestrującego.
264) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących tych usterek:
— kod usterki,
— data i godzina rozpoczęcia usterki (lub włożenia karty,
jeżeli usterka trwała w tym czasie),
— data i godzina zakończenia usterki (lub wyjęcia karty,
jeżeli usterka trwała w tym czasie),
— numer VRN i państwo członkowskie rejestracji
pojazdu, w którym wystąpiła usterka.
265) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących dwunastu ostatnich usterek każdego
rodzaju (łącznie 24 usterki).
4.5.3.1.9 Dane dotyczące czynności kierowcy
266) Karta kierowcy umożliwia przechowywanie, dla każdego
dnia kalendarzowego, w którym karta jest użyta, lub dla
każdego dnia, dla którego kierowca ręcznie wprowadza
informacje dotyczące czynności, następujących danych:
— data,
— dzienny licznik obecności (zwiększony o jeden dla
każdego z tych dni kalendarzowych),
— całkowita droga przebyta przez kierowcę w ciągu tego
dnia,
— status kierowcy o godzinie 00:00,
— za każdym razem, kiedy kierowca zmienia czynność lub
stan prowadzenia pojazdu lub wkłada lub wyjmuje
swoją kartę:
— stan prowadzenia pojazdu (ZAŁOGA, JEDEN
KIEROWCA),
— szczelina czytnika (KIEROWCA, WSPÓŁKIE­
ROWCA),
— status karty (WŁOŻONA, NIEWŁOŻONA),
— czynność (PROWADZENIE, GOTOWOŚĆ, PRACA,
PRZERWA/ODPOCZYNEK),
— godzina zmiany.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 78
267) Pamięć karty kierowcy wystarcza do przechowywania
danych dotyczących czynności kierowcy przez co najmniej
28 dni (przeciętną aktywność kierowcy definiuje się jako
93 zmiany czynności dziennie).
268) Dane wyszczególnione w wymaganiach 261, 264 i 266
przechowuje się w sposób umożliwiający wyszukiwanie
czynności w kolejności chronologicznej, nawet w przypadku
nakładania się czasów.
4.5.3.1.10 Dane dotyczące używanych pojazdów
269) Karta kierowcy umożliwia przechowywanie, dla każdego
dnia kalendarzowego, w którym karta jest użyta, i dla
każdego okresu używania danego pojazdu w tym dniu
(okres używania obejmuje wszystkie następujące po sobie
cykle włożenia i wyjęcia karty w danym pojeździe,
z perspektywy danych zapisanych na karcie), następujących
danych:
— data i godzina pierwszego użycia pojazdu (tj. pierwsze
włożenie karty w tym okresie używania pojazdu lub
00:00, jeżeli okres używania trwał w tym czasie),
— stan licznika kilometrów o tej godzinie,
— data i godzina ostatniego użycia pojazdu, (tj. ostatnie
wyjęcie karty w tym okresie używania pojazdu lub
23:59, jeżeli okres używania trwał w tym czasie),
— stan licznika kilometrów o tej godzinie,
— numer VRN i państwo członkowskie rejestracji
pojazdu.
270) Karta kierowcy umożliwia przechowywanie co najmniej 84
takich rekordów danych.
4.5.3.1.11 Miejsca rozpoczęcia lub zakończenia dziennych okresów pracy
271) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących miejsc rozpoczęcia lub zakończenia
dziennych okresów pracy, wprowadzanych przez kierowcę:
— data i godzina wprowadzenia danych (lub data/godzina
odnosząca się do wpisu, jeżeli wpis wprowadza się
w procedurze ręcznego wprowadzania danych),
— rodzaj wpisu (rozpoczęcie lub zakończenie, status
wpisu),
— kraj i region,
— stan licznika kilometrów.
272) Pamięć karty kierowcy umożliwia przechowywanie co
najmniej 42 par takich rekordów danych.
4.5.3.1.12 Dane sesji karty
273) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących pojazdu, dla którego otwarto bieżącą
sesję:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 79
— data i godzina otwarcia sesji (tj. włożenia karty)
z dokładnością do jednej sekundy,
— numer VRN i państwo członkowskie rejestracji.
4.5.3.1.13 Dane dotyczące czynności kontrolnych
274) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących czynności kontrolnych:
— data i godzina kontroli,
— numer karty kontrolnej i państwo członkowskie wyda­
jące kartę,
— rodzaj kontroli (wyświetlanie lub drukowanie lub pobie­
ranie danych z przyrządu rejestrującego lub pobieranie
danych z karty – patrz uwaga),
— okres, dla którego pobrano dane, w przypadku pobie­
rania danych,
— numer VRN i państwo członkowskie rejestracji
pojazdu, w którym miała miejsce kontrola.
Uwaga: pobieranie danych z karty jest rejestrowane
wyłącznie wtedy, gdy jest wykonywane przez urządzenie
rejestrujące.
275) Karta kierowcy umożliwia przechowywanie jednego
takiego rekordu danych.
4.5.3.1.14 Dane dotyczące warunków szczególnych
276) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących warunków szczególnych wprowadzo­
nych przy włożonej karcie (niezależnie od tego, do której
szczeliny czytnika):
— data i godzina wprowadzenia danych,
— rodzaj warunku szczególnego.
277) Karta kierowcy umożliwia przechowywanie co najmniej 56
takich rekordów danych.
▼M3
4.5.3.2 A p l i k a c j a t a c h o g r a f i c z n a g e n e r a c j i 2 ( n i e d o ­
s t ę p n a d l a p i e r w s z e j g e n e r a c j i p r z y r z ą d ó w
r e j e s t r u j ą c y c h , d o s t ę p n a d l a w e r s j i 1 i w e r s j i 2
d r u g i e j g e n e r a c j i p r z y r z ą d ó w r e j e s t r u j ą c y c h )
▼B
4.5.3.2.1 Identyfikacja aplikacji
278) Karta kierowcy umożliwia przechowywanie następujących
danych identyfikujących aplikację:
— identyfikacja aplikacji tachograficznej,
— identyfikacja typu karty do tachografów.
▼M3
4.5.3.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji
1 drugiej generacji przyrządów rejestrujących)
278a) Karta kierowcy umożliwia przechowywanie dodatkowych
danych identyfikujących aplikacje mających zastosowanie
wyłącznie do wersji 2.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 80
4.5.3.2.2 Klucze i certyfikaty
279) Karta kierowcy umożliwia przechowywanie szeregu kluczy
i certyfikatów kryptograficznych, jak określono w dodatku
11 część B.
4.5.3.2.3 Identyfikacja karty
280) Karta kierowcy umożliwia przechowywanie następujących
danych identyfikujących kartę:
— numer karty,
— państwo członkowskie wydające kartę, nazwa organu
wydającego, data wydania,
— data rozpoczęcia okresu ważności karty, termin ważności
karty.
4.5.3.2.4 Identyfikacja posiadacza karty
281) Karta kierowcy umożliwia przechowywanie następujących
danych identyfikujących posiadacza karty:
— nazwisko posiadacza karty,
— imię (imiona) posiadacza karty,
— data urodzenia,
— preferowany język.
4.5.3.2.5 Pobieranie danych z karty
282) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących pobierania danych:
— data i godzina ostatniego pobrania danych z karty (do
innych celów niż kontrola).
283) Karta kierowcy umożliwia przechowywanie jednego
takiego rekordu danych.
4.5.3.2.6 Dane dotyczące prawa jazdy
284) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących prawa jazdy:
— państwo członkowskie wydające, nazwa organu wyda­
jącego,
— numer prawa jazdy (w dniu wydania karty).
4.5.3.2.7 Dane dotyczące zdarzeń
Do celów niniejszego podpunktu czas zachowuje się z dokładnością
do 1 sekundy.
285) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących zdarzeń wykrytych przez urządzenie
rejestrujące przy włożonej karcie:
— nakładające się czasy (w przypadku gdy dana karta jest
przyczyną zdarzenia),
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 81
— włożenie karty podczas jazdy (w przypadku gdy dana
karta jest przedmiotem zdarzenia),
— sesja ostatniej karty niezamknięta prawidłowo (w przy­
padku gdy dana karta jest przedmiotem zdarzenia),
— przerwa w zasilaniu,
— błąd połączenia z urządzeniem do łączności na odle­
głość,
— brak informacji o pozycji z odbiornika GNSS,
— błąd połączenia z urządzeniem zewnętrznym GNSS,
— błąd danych dotyczących ruchu,
— konflikt ruchu pojazdu,
— próba naruszenia zabezpieczenia,
— konflikt czasu.
286) Karta kierowcy umożliwia przechowywanie następujących
danych dla tych zdarzeń:
— kod zdarzenia,
— data i godzina rozpoczęcia zdarzenia (lub włożenia
karty, jeżeli zdarzenie trwało w tym czasie),
— data i godzina zakończenia zdarzenia (lub wyjęcia
karty, jeżeli zdarzenie trwało w tym czasie),
— numer VRN i państwo członkowskie rejestracji
pojazdu, w którym wystąpiło zdarzenie.
Uwaga: dla zdarzenia „nakładające się czasy”:
— data i godzina rozpoczęcia zdarzenia musi odpowiadać
dacie i godzinie wyjęcia karty z poprzedniego pojazdu,
— data i godzina zakończenia zdarzenia musi odpowiadać
dacie i godzinie włożenia karty w bieżącym pojeździe,
— dane pojazdu muszą odpowiadać bieżącemu pojazdowi
powodującemu zdarzenie.
Uwaga: dla zdarzenia „sesja ostatniej karty niezamknięta
prawidłowo”:
— data i godzina rozpoczęcia zdarzenia musi odpowiadać
dacie i godzinie włożenia karty dla sesji niezamkniętej
prawidłowo,
— data i godzina zakończenia zdarzenia musi odpowiadać
dacie i godzinie włożenia karty dla sesji, w czasie której
wykryto zdarzenie (bieżąca sesja),
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 82
— dane pojazdu muszą odpowiadać pojazdowi, w którym
sesja nie została zamknięta prawidłowo.
▼M3
287) Karta kierowcy umożliwia przechowywanie danych dotyczą­
cych 12 ostatnich zdarzeń każdego typu (tj. 132 zdarzeń).
▼B
4.5.3.2.8 Dane dotyczące usterek
Do celów niniejszego podpunktu czas rejestruje się z dokładnością
do 1 sekundy.
288) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących usterek wykrytych przez urządzenie
rejestrujące przy włożonej karcie:
▼M1
— usterka karty (w przypadku gdy dana karta jest przed­
miotem usterki),
▼B
— usterka urządzenia rejestrującego.
289) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących tych usterek:
— kod usterki,
— data i godzina rozpoczęcia usterki (lub włożenia karty,
jeżeli usterka trwała w tym czasie),
— data i godzina zakończenia usterki (lub wyjęcia karty,
jeżeli usterka trwała w tym czasie),
— numer VRN i państwo członkowskie rejestracji pojazdu,
w którym wystąpiła usterka.
▼M3
290) Karta kierowcy umożliwia przechowywanie danych doty­
czących 24 ostatnich usterek każdego rodzaju (tj. 48
usterek).
▼B
4.5.3.2.9 Dane dotyczące czynności kierowcy
291) Karta kierowcy umożliwia przechowywanie, dla każdego
dnia kalendarzowego, w którym karta jest użyta, lub dla
każdego dnia, dla którego kierowca ręcznie wprowadza
informacje dotyczące czynności, następujących danych:
— data,
— dzienny licznik obecności (zwiększony o jeden dla
każdego z tych dni kalendarzowych),
— całkowita droga przebyta przez kierowcę w ciągu tego
dnia,
— status kierowcy o godzinie 00:00,
— za każdym razem, kiedy kierowca zmienia czynność lub
stan prowadzenia pojazdu lub wkłada lub wyjmuje
swoją kartę:
— stan prowadzenia pojazdu (ZAŁOGA, JEDEN
KIEROWCA),
— szczelina czytnika (KIEROWCA, WSPÓŁKIE­
ROWCA),
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 83
— status karty (WŁOŻONA, NIEWŁOŻONA),
— czynność (PROWADZENIE, GOTOWOŚĆ,
PRACA, PRZERWA/ODPOCZYNEK),
— godzina zmiany.
▼M3
292) Pamięć karty kierowcy wystarcza do przechowywania
danych dotyczących czynności kierowcy przez przynaj­
mniej 56 dni (przeciętną aktywność kierowcy definiuje się
na potrzeby tego wymogu jako 117 zmian czynności
dziennie).
▼B
293) Dane wyszczególnione w wymaganiach 286, 289 i 291
przechowuje się w sposób umożliwiający wyszukiwanie
czynności w kolejności chronologicznej, nawet w przypadku
nakładania się czasów.
4.5.3.2.10 Dane dotyczące używanych pojazdów
294) Karta kierowcy umożliwia przechowywanie, dla każdego
dnia kalendarzowego, w którym karta jest użyta, i dla
każdego okresu używania danego pojazdu w tym dniu
(okres używania obejmuje wszystkie następujące po sobie
cykle włożenia i wyjęcia karty w danym pojeździe,
z perspektywy danych zapisanych na karcie), następujących
danych:
— data i godzina pierwszego użycia pojazdu (tj. pierwsze
włożenie karty w tym okresie używania pojazdu lub
00:00, jeżeli okres używania trwał w tym czasie),
— stan licznika kilometrów w chwili pierwszego użycia,
— data i godzina ostatniego użycia pojazdu, (tj. ostatnie
wyjęcie karty w tym okresie używania pojazdu lub
23:59, jeżeli okres używania trwał w tym czasie),
— stan licznika kilometrów w chwili ostatniego użycia,
— numer VRN i państwo członkowskie rejestracji
pojazdu,
— numer VIN pojazdu.
▼M3
295) Karta kierowcy umożliwia przechowywanie 200 takich
rekordów danych.
▼B
4.5.3.2.11 Miejsca i pozycje rozpoczęcia lub zakończenia 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),
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 84
— rodzaj wpisu (rozpoczęcie lub zakończenie, status
wpisu),
— kraj i region,
— stan licznika kilometrów,
— pozycja pojazdu,
— dokładność GNSS, data i godzina określenia pozycji.
▼M3
297) Pamięć karty kierowcy umożliwia przechowywanie 112
takich rekordów danych.
▼B
4.5.3.2.12 Dane sesji karty
298) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących pojazdu, dla którego otwarto bieżącą
sesję:
— data i godzina otwarcia sesji (tj. włożenia karty)
z dokładnością do jednej sekundy,
— numer VRN i państwo członkowskie rejestracji.
4.5.3.2.13 Dane dotyczące czynności kontrolnych
299) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących czynności kontrolnych:
— data i godzina kontroli,
— numer karty kontrolnej i państwo członkowskie wyda­
jące kartę,
— rodzaj kontroli (wyświetlanie lub drukowanie lub pobie­
ranie danych z przyrządu rejestrującego lub pobieranie
danych z karty – patrz uwaga),
— okres, dla którego pobrano dane, w przypadku pobie­
rania danych,
— numer VRN i państwo członkowskie rejestracji
pojazdu, w którym miała miejsce kontrola.
Uwaga: zgodnie z wymogami bezpieczeństwa pobieranie
danych z karty jest rejestrowane wyłącznie wtedy, gdy
jest wykonywane przez urządzenie rejestrujące.
300) Karta kierowcy umożliwia przechowywanie jednego
takiego rekordu danych.
4.5.3.2.14 Dane dotyczące warunków szczególnych
301) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących warunków szczególnych wprowadzo­
nych przy włożonej karcie (niezależnie od tego, do której
szczeliny czytnika):
— data i godzina wprowadzenia danych,
— rodzaj warunku szczególnego.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 85
302) Karta kierowcy umożliwia przechowywanie 112 takich
rekordów danych.
▼B
4.5.3.2.15 Dane dotyczące używanych przyrządów rejestrujących
303) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących różnych przyrządów rejestrujących,
w których dana karta była używana:
— data i godzina rozpoczęcia okresu używania przyrządu
rejestrującego (tj. pierwsze włożenie karty do przyrządu
rejestrującego dla danego okresu),
— producent przyrządu rejestrującego,
— rodzaj przyrządu rejestrującego,
— numer wersji oprogramowania przyrządu rejestrującego.
▼M3
304) Karta kierowcy umożliwia przechowywanie 200 takich
rekordów danych.
▼M1
4.5.3.2.16 Dane miejsc, w których minęły trzy godziny skumulowanego czasu
prowadzenia pojazdu
305) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących pozycji pojazdu, w których skumulo­
wany czas prowadzenia pojazdu osiąga wielokrotność
trzech godzin:
— data i godzina, o której skumulowany czas prowadzenia
pojazdu osiąga wielokrotność trzech godzin,
— pozycja pojazdu,
— dokładność GNSS, data i godzina określenia pozycji,
— stan licznika kilometrów.
▼M3
306) Karta kierowcy umożliwia przechowywanie 336 takich
rekordów danych.
4.5.3.2.17 Status uwierzytelniania dla pozycji związanych z miejscami rozpo­
częcia lub zakończenia dziennych okresów pracy (brak dostępu
w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
306a) Karta kierowcy umożliwia przechowywanie dodatkowych
danych dotyczących miejsc rozpoczęcia lub zakończenia
dziennych okresów pracy, wprowadzanych przez kierowcę
zgodnie z pkt 4.5.3.2.11:
— data i godzina wpisu, która musi być dokładnie taka
sama, jak data i godzina zapisana w EF Places w DF
Tachograph_G2,
— flagę wskazującą, czy pozycja została uwierzytelniona.
306b) Pamięć karty kierowcy umożliwia przechowywanie 112
takich rekordów danych.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 86
4.5.3.2.18 Status uwierzytelniania dla pozycji, w których osiągnięto trzy
godziny skumulowanego czasu prowadzenia pojazdu (brak dostępu
w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
306c) Karta kierowcy umożliwia przechowywanie dodatkowych
danych dotyczących pozycji pojazdu, w których skumulo­
wany czas prowadzenia pojazdu osiąga wielokrotność
trzech godzin zgodnie z pkt 4.5.3.2.16:
— data i godzina, gdy skumulowany czas prowadzenia
pojazdu osiąga wielokrotność trzech godzin, która
musi być dokładnie taka sama, jak data i godzina zapi­
sana w EF GNSS_Places w DF Tachograph_G2,
— flagę wskazującą, czy pozycja została uwierzytelniona.
306d) Karta kierowcy umożliwia przechowywanie 336 takich
rekordów danych.
4.5.3.2.19 Przekroczenia granicy (brak dostępu w przypadku wersji 1 drugiej
generacji przyrządów rejestrujących)
306e) Karta kierowcy umożliwia zapisanie następujących danych
dotyczących przekroczeń granicy przy wkładaniu karty
zgodnie z wymogiem 147b albo przy już włożonej karcie:
— kraj, który pojazd opuszcza,
— kraj, do którego pojazd wjeżdża,
— data i godzina przekroczenia granicy przez pojazd,
— pozycja pojazdu po przekroczeniu granicy,
— dokładność GNSS,
— flagę wskazującą, czy pozycja została uwierzytelniona,
— stan licznika kilometrów.
306f) Pamięć karty kierowcy umożliwia przechowywanie 1120
takich rekordów danych.
4.5.3.2.20 Operacje załadunku/rozładunku (brak dostępu w przypadku wersji 1
drugiej generacji przyrządów rejestrujących)
306g) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących operacji załadunku/rozładunku:
— typ operacji (załadunek, rozładunek lub równoczesny
załadunek/rozładunek),
— data i godzina operacji załadunku/rozładunku,
— pozycja pojazdu,
— dokładność GNSS, data i godzina określenia pozycji,
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 87
— flagę wskazującą, czy pozycja została uwierzytelniona,
— stan licznika kilometrów.
306h) Karta kierowcy umożliwia przechowywanie 1624 operacji
załadunku/rozładunku.
4.5.3.2.21 Wprowadzanie typu załadunku (brak dostępu w przypadku wersji 1
drugiej generacji przyrządów rejestrujących)
306i) Karta kierowcy umożliwia przechowywanie następujących
danych dotyczących typu załadunku wprowadzanych auto­
matycznie przez VU przy każdym włożeniu karty:
— wpisany typ załadunku (towary lub pasażerowie),
— data i godzina wpisu.
306j) Karta kierowcy umożliwia przechowywanie 336 takich
rekordów danych.
4.5.3.2.22 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
306k) Karta kierowcy umożliwia przechowywanie szczegółowych
ustawień tachografu posiadacza karty.
306l) Pojemność karty kierowcy na potrzeby przechowywania
szczegółowych ustawień tachografu posiadacza karty
wynosi 3072 bajty.
▼B
4.5.4 Karta warsztatowa
4.5.4.1 A p l i k a c j a t a c h o g r a f i c z n a ( d o s t ę p n a d l a p r z y ­
r z ą d ó w r e j e s t r u j ą c y c h p i e r w s z e j i d r u g i e j g e n e ­
r a c j i )
4.5.4.1.1 Identyfikacja aplikacji
307) Karta warsztatowa umożliwia przechowywanie następują­
cych danych identyfikujących aplikację:
— identyfikacja aplikacji tachograficznej,
— identyfikacja typu karty do tachografów.
4.5.4.1.2 Klucze i certyfikaty
308) Karta warsztatowa umożliwia przechowywanie szeregu
kluczy i certyfikatów kryptograficznych, jak określono
w dodatku 11 część A.
309) Karta warsztatowa umożliwia przechowywanie osobistego
numeru identyfikacyjnego (kodu PIN).
4.5.4.1.3 Identyfikacja karty
310) Karta warsztatowa umożliwia przechowywanie następują­
cych danych identyfikujących kartę:
— numer karty,
— państwo członkowskie wydające kartę, nazwa organu
wydającego, data wydania,
— data rozpoczęcia okresu ważności karty, termin
ważności karty.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 88
4.5.4.1.4 Identyfikacja posiadacza karty
311) Karta warsztatowa umożliwia przechowywanie następują­
cych danych identyfikujących posiadacza karty:
— nazwa warsztatu,
— adres warsztatu,
— nazwisko posiadacza karty,
— imię (imiona) posiadacza karty,
— preferowany język.
4.5.4.1.5 Pobieranie danych z karty
312) Karta warsztatowa umożliwia przechowywanie rekordu
danych pobranych z karty, w taki sam sposób jak karta
kierowcy.
4.5.4.1.6 Dane dotyczące kalibracji i korekty czasu
313) Karta warsztatowa umożliwia przechowywanie zapisów
dotyczących kalibracji lub korekty czasu wykonanych
przy karcie włożonej do urządzenia rejestrującego.
314) Każdy rekord danych kalibracji może zawierać następujące
dane:
— cel kalibracji (aktywacja, pierwsza instalacja, instalacja,
przegląd okresowy),
— identyfikacja pojazdu,
— parametry uaktualnione lub potwierdzone (w, k, l,
rozmiar opon, ustawienie urządzenia ograniczenia pręd­
kości, licznik kilometrów (nowe i stare wartości), data
i godzina (nowe i stare wartości)),
— identyfikacja urządzenia rejestrującego (numer części
VU, numer seryjny VU, numer seryjny czujnika ruchu).
315) Karta warsztatowa umożliwia przechowywanie co najmniej
88 takich rekordów danych.
316) Karta warsztatowa jest wyposażona w licznik pokazujący
łączną liczbę kalibracji wykonanych przy użyciu tej karty.
317) Karta warsztatowa jest wyposażona w licznik pokazujący
liczbę kalibracji wykonanych od ostatniego pobrania
danych.
4.5.4.1.7 Dane dotyczące zdarzeń i usterek
318) Karta warsztatowa umożliwia przechowywanie rekordów
danych zdarzeń i usterek, w taki sam sposób jak karta
kierowcy.
319) Karta warsztatowa umożliwia przechowywanie danych
dotyczących trzech ostatnich zdarzeń każdego rodzaju
(łącznie 18 zdarzeń) i sześciu ostatnich usterek każdego
rodzaju (łącznie 12 usterek).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 89
4.5.4.1.8 Dane dotyczące czynności kierowcy
320) Karta warsztatowa umożliwia przechowywanie danych
dotyczących czynności kierowcy, w taki sam sposób jak
karta kierowcy.
321) Karta warsztatowa umożliwia przechowywanie danych
dotyczących czynności kierowcy za co najmniej 1 dzień
przeciętnej aktywności kierowcy.
4.5.4.1.9 Dane dotyczące używanych pojazdów
322) Karta warsztatowa umożliwia przechowywanie rekordów
danych dotyczących używanego pojazdu, w taki sam
sposób jak karta kierowcy.
323) Karta warsztatowa umożliwia przechowywanie co najmniej
4 takich rekordów.
4.5.4.1.10 Dane dotyczące rozpoczęcia lub zakończenia dziennych okresów
pracy
324) Karta warsztatowa umożliwia przechowywanie rekordów
danych dotyczących rozpoczęcia lub zakończenia dzien­
nych okresów pracy, w taki sam sposób jak karta kierowcy.
325) Karta warsztatowa umożliwia przechowywanie co najmniej
3 par takich rekordów danych.
4.5.4.1.11 Dane sesji karty
326) Karta warsztatowa umożliwia przechowywanie rekordu
danych sesji karty, w taki sam sposób jak karta kierowcy.
4.5.4.1.12 Dane dotyczące czynności kontrolnych
327) Karta warsztatowa umożliwia przechowywanie rekordu
danych czynności kontrolnych, w taki sam sposób jak
karta kierowcy.
4.5.4.1.13 Dane dotyczące warunków szczególnych
328) Karta warsztatowa umożliwia przechowywanie danych
dotyczących warunków szczególnych, w taki sam sposób
jak karta kierowcy.
329) Karta warsztatowa umożliwia przechowywanie co najmniej
2 takich rekordów.
▼M3
4.5.4.2 A p l i k a c j a t a c h o g r a f i c z n a g e n e r a c j i 2 ( n i e d o ­
s t ę p n a d l a p i e r w s z e j g e n e r a c j i p r z y r z ą d ó w
r e j e s t r u j ą c y c h , d o s t ę p n a d l a w e r s j i 1 i w e r s j i 2
d r u g i e j g e n e r a c j i p r z y r z ą d ó w r e j e s t r u j ą c y c h )
▼B
4.5.4.2.1 Identyfikacja aplikacji
330) Karta warsztatowa umożliwia przechowywanie następują­
cych danych identyfikujących aplikację:
— identyfikacja aplikacji tachograficznej,
— identyfikacja typu karty do tachografów.
▼M3
4.5.4.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji
1 drugiej generacji przyrządów rejestrujących)
330a) Karta warsztatowa umożliwia przechowywanie dodatko­
wych danych identyfikujących aplikacje mających zastoso­
wanie wyłącznie do wersji 2.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 90
4.5.4.2.2 Klucze i certyfikaty
331) Karta warsztatowa umożliwia przechowywanie szeregu
kluczy i certyfikatów kryptograficznych, jak określono
w dodatku 11 część B.
332) Karta warsztatowa umożliwia przechowywanie osobistego
numeru identyfikacyjnego (kodu PIN).
4.5.4.2.3 Identyfikacja karty
333) Karta warsztatowa umożliwia przechowywanie następują­
cych danych identyfikujących kartę:
— numer karty,
— państwo członkowskie wydające kartę, nazwa organu
wydającego, data wydania,
— data rozpoczęcia okresu ważności karty, termin
ważności karty.
4.5.4.2.4 Identyfikacja posiadacza karty
334) Karta warsztatowa umożliwia przechowywanie następują­
cych danych identyfikujących posiadacza karty:
— nazwa warsztatu,
— adres warsztatu,
— nazwisko posiadacza karty,
— imię (imiona) posiadacza karty,
— preferowany język.
4.5.4.2.5 Pobieranie danych z karty
335) Karta warsztatowa umożliwia przechowywanie rekordu
danych pobranych z karty, w taki sam sposób jak karta
kierowcy.
4.5.4.2.6 Dane dotyczące kalibracji i korekty czasu
336) Karta warsztatowa umożliwia przechowywanie zapisów
dotyczących kalibracji lub korekty czasu wykonanych
przy karcie włożonej do urządzenia rejestrującego.
337) Każdy rekord danych kalibracji może zawierać następujące
dane:
— cel kalibracji (aktywacja, pierwsza instalacja, instalacja,
przegląd okresowy),
— identyfikacja pojazdu,
— parametry uaktualnione lub potwierdzone (w, k, l,
rozmiar opon, ustawienie urządzenia ograniczenia pręd­
kości, licznik kilometrów (nowe i stare wartości), data
i godzina (nowe i stare wartości)),
— identyfikacja urządzenia rejestrującego (numer części VU,
numer seryjny VU, numer seryjny czujnika ruchu, numer
seryjny urządzenia do łączności na odległość, numer
seryjny urządzenia zewnętrznego GNSS, w stosownych
przypadkach),
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 91
— rodzaje i identyfikatory wszystkich założonych plomb,
— możliwość korzystania przez przyrząd rejestrujący
z kart do tachografów pierwszej generacji (włączona
lub nie).
▼M3
338) Karta warsztatowa umożliwia przechowywanie 255 takich
rekordów danych.
▼B
339) Karta warsztatowa jest wyposażona w licznik pokazujący
łączną liczbę kalibracji wykonanych przy użyciu tej karty.
340) Karta warsztatowa jest wyposażona w licznik pokazujący
liczbę kalibracji wykonanych od ostatniego pobrania
danych.
4.5.4.2.7 Dane dotyczące zdarzeń i usterek
341) Karta warsztatowa umożliwia przechowywanie rekordów
danych zdarzeń i usterek, w taki sam sposób jak karta
kierowcy.
342) Karta warsztatowa umożliwia przechowywanie danych
dotyczących trzech ostatnich zdarzeń każdego rodzaju
(łącznie 33 zdarzenia) i sześciu ostatnich usterek każdego
rodzaju (łącznie 12 usterek).
4.5.4.2.8 Dane dotyczące czynności kierowcy
343) Karta warsztatowa umożliwia przechowywanie danych
dotyczących czynności kierowcy, w taki sam sposób jak
karta kierowcy.
▼M3
344) Karta warsztatowa umożliwia przechowywanie danych
dotyczących czynności kierowcy przez 1 dzień obejmujący
240 zmian czynności.
▼B
4.5.4.2.9 Dane dotyczące używanych pojazdów
345) Karta warsztatowa umożliwia przechowywanie rekordów
danych dotyczących używanego pojazdu, w taki sam
sposób jak karta kierowcy.
▼M3
346) Karta warsztatowa umożliwia przechowywanie 8 takich
rekordów danych.
4.5.4.2.10 Dane dotyczące miejsc i pozycji rozpoczęcia lub zakończenia dzien­
nych okresów pracy
347) Karta warsztatowa umożliwia przechowywanie rekordów
danych dotyczących miejsc i pozycji rozpoczęcia lub
zakończenia dziennych okresów pracy, w taki sam sposób
jak karta kierowcy.
348) Karta warsztatowa umożliwia przechowywanie 4 par takich
rekordów danych.
▼B
4.5.4.2.11 Dane sesji karty
349) Karta warsztatowa umożliwia przechowywanie rekordu
danych sesji karty, w taki sam sposób jak karta kierowcy.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 92
4.5.4.2.12 Dane dotyczące czynności kontrolnych
350) Karta warsztatowa umożliwia przechowywanie rekordu
danych czynności kontrolnych, w taki sam sposób jak
karta kierowcy.
4.5.4.2.13 Dane dotyczące używanych przyrządów rejestrujących
351) Karta warsztatowa umożliwia przechowywanie następują­
cych danych dotyczących różnych przyrządów rejestrują­
cych, w których dana karta była używana:
— data i godzina rozpoczęcia okresu używania przyrządu
rejestrującego (tj. pierwsze włożenie karty do przyrządu
rejestrującego dla danego okresu),
— producent przyrządu rejestrującego,
— rodzaj przyrządu rejestrującego,
— numer wersji oprogramowania przyrządu rejestrującego.
▼M3
352) Karta warsztatowa umożliwia przechowywanie 8 takich
rekordów danych.
▼M1
4.5.4.2.14 Dane miejsc, w których minęły trzy godziny 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 wielokrot­
ność trzech godzin:
— data i godzina, o której skumulowany czas prowadzenia
pojazdu osiąga wielokrotność trzech godzin,
— pozycja pojazdu,
— dokładność GNSS, data i godzina określenia pozycji,
— stan licznika kilometrów.
▼M3
354) Karta warsztatowa umożliwia przechowywanie 24 takich
rekordów danych.
▼B
4.5.4.2.15 Dane dotyczące warunków szczególnych
355) Karta warsztatowa umożliwia przechowywanie danych
dotyczących warunków szczególnych, w taki sam sposób
jak karta kierowcy.
▼M3
356) Karta warsztatowa umożliwia przechowywanie 4 takich
rekordów danych.
4.5.4.2.16 Status uwierzytelniania dla pozycji związanych z miejscami rozpo­
częcia lub zakończenia dziennych okresów pracy (brak dostępu
w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
356a) Karta warsztatowa umożliwia przechowywanie dodatko­
wych danych dotyczących miejsc rozpoczęcia lub zakoń­
czenia dziennych okresów pracy, w taki sam sposób jak
karta kierowcy.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 93
356b) Pamięć karty warsztatowej umożliwia przechowywanie 4
par takich rekordów danych.
4.5.4.2.17 Status uwierzytelniania dla pozycji, w których osiągnięto trzy
godziny skumulowanego prowadzenia pojazdu (brak dostępu w przy­
padku wersji 1 drugiej generacji przyrządów rejestrujących)
356c) Karta warsztatowa umożliwia przechowywanie dodatko­
wych danych dotyczących pozycji pojazdu, w których
skumulowany czas prowadzenia pojazdu osiąga wielokrot­
ność trzech godzin w taki sam sposób jak karta kierowcy.
356d) Karta warsztatowa umożliwia przechowywanie 24 takich
rekordów danych.
4.5.4.2.18 Przekroczenia granicy (brak dostępu w przypadku wersji 1 drugiej
generacji przyrządów rejestrujących)
356e) Karta warsztatowa umożliwia przechowywanie przekroczeń
granicy, w taki sam sposób jak karta kierowcy.
356f) Pamięć karty warsztatowej umożliwia przechowywanie 4
takich rekordów danych.
4.5.4.2.19 Operacje załadunku/rozładunku (brak dostępu w przypadku wersji 1
drugiej generacji przyrządów rejestrujących)
356g) Karta warsztatowa umożliwia przechowywanie operacji
załadunku/rozładunku, w taki sam sposób jak karta
kierowcy.
356h) Karta warsztatowa umożliwia przechowywanie 8 operacji
załadunku, rozładunku lub równoczesnego załadunku/rozła­
dunku.
4.5.4.2.20 Wprowadzanie typu załadunku (brak dostępu w przypadku wersji 1
drugiej generacji przyrządów rejestrujących)
356i) Karta warsztatowa umożliwia przechowywanie wpisów
typu załadunku, w taki sam sposób jak karta kierowcy.
356j) Karta warsztatowa umożliwia przechowywanie 4 takich
rekordów danych.
4.5.4.2.21 Dodatkowe dane dotyczące kalibracji (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
356k) Karta warsztatowa umożliwia przechowywanie dodatko­
wych danych identyfikujących aplikacje mających zastoso­
wanie wyłącznie do wersji 2:
— stara wartość daty i godziny oraz numer identyfikacyjny
pojazdu, które muszą być dokładnie takie same, jak
wartości zapisane w EF Calibration w DF Tacho­
graph_G2,
— domyślny typ załadunku wpisany podczas tej kalibracji,
— kraj, w którym wykonano kalibrację, oraz data i godzina
dostarczenia przez odbiornik GNSS pozycji wykorzys­
tanej do określenia tego kraju.
356l) Karta warsztatowa umożliwia przechowywanie 255 takich
rekordów danych.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 94
4.5.4.2.22 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
356m) Karta warsztatowa umożliwia przechowywanie szczegóło­
wych ustawień tachografu posiadacza karty.
356n) Pojemność karty warsztatowej na potrzeby przechowywania
szczegółowych ustawień tachografu posiadacza karty
wynosi 3072 bajty.
▼B
4.5.5 Karta kontrolna
4.5.5.1 A p l i k a c j a t a c h o g r a f i c z n a ( d o s t ę p n a d l a p r z y ­
r z ą d ó w r e j e s t r u j ą c y c h p i e r w s z e j i d r u g i e j g e n e ­
r a c j i )
4.5.5.1.1 Identyfikacja aplikacji
357) Karta kontrolna umożliwia przechowywanie następujących
danych identyfikujących aplikację:
— identyfikacja aplikacji tachograficznej,
— identyfikacja typu karty do tachografów.
4.5.5.1.2 Klucze i certyfikaty
358) Karta kontrolna umożliwia przechowywanie szeregu kluczy
i certyfikatów kryptograficznych, jak określono w dodatku
11 część A.
4.5.5.1.3 Identyfikacja karty
359) Karta kontrolna umożliwia przechowywanie następujących
danych identyfikujących kartę:
— numer karty,
— państwo członkowskie wydające kartę, nazwa organu
wydającego, data wydania,
— data rozpoczęcia okresu ważności karty, termin
ważności karty (jeżeli jest określony).
4.5.5.1.4 Identyfikacja posiadacza karty
360) Karta kontrolna umożliwia przechowywanie następujących
danych identyfikujących posiadacza karty:
— nazwa organu kontrolnego,
— adres organu kontrolnego,
— nazwisko posiadacza karty,
— imię (imiona) posiadacza karty,
— preferowany język.
4.5.5.1.5 Dane dotyczące czynności kontrolnych
361) Karta kontrolna umożliwia przechowywanie następujących
danych dotyczących czynności kontrolnych:
— data i godzina kontroli,
▼M3
— rodzaj kontroli (wyświetlanie lub drukowanie lub pobie­
ranie danych z przyrządu rejestrującego lub pobieranie
danych z karty),
▼B
— okres, dla którego pobrano dane (jeżeli ma zastoso­
wanie),
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 95
— numer VRN i państwo członkowskie rejestracji kontro­
lowanego pojazdu,
— numer karty i państwo członkowskie wydające kontro­
lowaną kartę kierowcy.
362) Karta kontrolna umożliwia przechowywanie co najmniej
230 takich rekordów danych.
4.5.5.2 A p l i k a c j a t a c h o g r a f i c z n a 2 . g e n e r a c j i ( n i e d o ­
s t ę p n a d l a p r z y r z ą d ó w r e j e s t r u j ą c y c h p i e r w s z e j
g e n e r a c j i )
4.5.5.2.1 Identyfikacja aplikacji
363) Karta kontrolna umożliwia przechowywanie następujących
danych identyfikujących aplikację:
— identyfikacja aplikacji tachograficznej,
— identyfikacja typu karty do tachografów.
▼M3
4.5.5.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji
1 drugiej generacji przyrządów rejestrujących)
363a) Karta kontrolna umożliwia przechowywanie dodatkowych
danych identyfikujących aplikacje mających zastosowanie
wyłącznie do wersji 2.
▼B
4.5.5.2.2 Klucze i certyfikaty
364) Karta kontrolna umożliwia przechowywanie szeregu kluczy
i certyfikatów kryptograficznych, jak określono w dodatku
11 część B.
4.5.5.2.3 Identyfikacja karty
365) Karta kontrolna umożliwia przechowywanie następujących
danych identyfikujących kartę:
— numer karty,
— państwo członkowskie wydające kartę, nazwa organu
wydającego, data wydania,
— data rozpoczęcia okresu ważności karty, termin
ważności karty (jeżeli jest określony).
4.5.5.2.4 Identyfikacja posiadacza karty
366) Karta kontrolna umożliwia przechowywanie następujących
danych identyfikujących posiadacza karty:
— nazwa organu kontrolnego,
— adres organu kontrolnego,
— nazwisko posiadacza karty,
— imię (imiona) posiadacza karty,
— preferowany język.
4.5.5.2.5 Dane dotyczące czynności kontrolnych
367) Karta kontrolna umożliwia przechowywanie następujących
danych dotyczących czynności kontrolnych:
— data i godzina kontroli,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 96
— rodzaj kontroli (wyświetlanie lub drukowanie lub pobie­
ranie danych z przyrządu rejestrującego lub karty lub
kontrola drogowa kalibracji),
— okres, dla którego pobrano dane (jeżeli ma zastoso­
wanie),
— numer VRN i państwo członkowskie rejestracji kontro­
lowanego pojazdu,
— numer karty i państwo członkowskie wydające kontro­
lowaną kartę kierowcy.
368) Karta kontrolna umożliwia przechowywanie co najmniej
230 takich rekordów danych.
▼M3
4.5.5.2.6 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
368a) Karta kontrolna umożliwia przechowywanie szczegółowych
ustawień tachografu posiadacza karty.
368b) Pojemność karty kontrolnej na potrzeby przechowywania
szczegółowych ustawień tachografu posiadacza karty
wynosi 3072 bajty.
▼B
4.5.6 Karta firmowa
4.5.6.1 A p l i k a c j a t a c h o g r a f i c z n a ( d o s t ę p n a d l a p r z y ­
r z ą d ó w r e j e s t r u j ą c y c h p i e r w s z e j i d r u g i e j g e n e ­
r a c j i )
4.5.6.1.1 Identyfikacja aplikacji
369) Karta firmowa umożliwia przechowywanie następujących
danych identyfikujących aplikację:
— identyfikacja aplikacji tachograficznej,
— identyfikacja typu karty do tachografów.
4.5.6.1.2 Klucze i certyfikaty
370) Karta firmowa umożliwia przechowywanie szeregu kluczy
i certyfikatów kryptograficznych, jak określono w dodatku
11 część A.
4.5.6.1.3 Identyfikacja karty
371) Karta firmowa umożliwia przechowywanie następujących
danych identyfikujących kartę:
— numer karty,
— państwo członkowskie wydające kartę, nazwa organu
wydającego, data wydania,
— data rozpoczęcia okresu ważności karty, termin
ważności karty (jeżeli jest określony).
4.5.6.1.4 Identyfikacja posiadacza karty
372) Karta firmowa umożliwia przechowywanie następujących
danych identyfikujących posiadacza karty:
— nazwa firmy,
— adres firmy.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 97
4.5.6.1.5 Dane dotyczące czynności wykonywanych przez firmę
373) Karta firmowa umożliwia przechowywanie następujących
danych dotyczących czynności wykonywanych przez firmę:
— data i godzina czynności,
— typ czynności (blokowanie lub zdejmowanie blokady
z przyrządu rejestrującego lub pobieranie danych z przy­
rządu rejestrującego lub pobieranie danych z karty),
— okres, dla którego pobrano dane (jeżeli ma zastoso­
wanie),
— numer VRN i państwo członkowskie rejestracji
pojazdu,
— numer karty i państwo członkowskie wydające kartę
(w przypadku pobierania danych z karty).
374) Karta firmowa umożliwia przechowywanie co najmniej 230
takich rekordów danych.
4.5.6.2 A p l i k a c j a t a c h o g r a f i c z n a 2 . g e n e r a c j i ( n i e d o ­
s t ę p n a d l a p r z y r z ą d ó w r e j e s t r u j ą c y c h p i e r w s z e j
g e n e r a c j i )
4.5.6.2.1 Identyfikacja aplikacji
375) Karta firmowa umożliwia przechowywanie następujących
danych identyfikujących aplikację:
— identyfikacja aplikacji tachograficznej,
— identyfikacja typu karty do tachografów.
▼M3
4.5.6.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji
1 drugiej generacji przyrządów rejestrujących)
375a) Karta firmowa umożliwia przechowywanie dodatkowych
danych identyfikujących aplikacje mających zastosowanie
wyłącznie do wersji 2.
▼B
4.5.6.2.2 Klucze i certyfikaty
376) Karta firmowa umożliwia przechowywanie szeregu kluczy
i certyfikatów kryptograficznych, jak określono w dodatku
11 część B.
4.5.6.2.3 Identyfikacja karty
377) Karta firmowa umożliwia przechowywanie następujących
danych identyfikujących kartę:
— numer karty,
— państwo członkowskie wydające kartę, nazwa organu
wydającego, data wydania,
— data rozpoczęcia okresu ważności karty, termin
ważności karty (jeżeli jest określony).
4.5.6.2.4 Identyfikacja posiadacza karty
378) Karta firmowa umożliwia przechowywanie następujących
danych identyfikujących posiadacza karty:
— nazwa firmy,
— adres firmy.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 98
4.5.6.2.5 Dane dotyczące czynności wykonywanych przez firmę
379) Karta firmowa umożliwia przechowywanie następujących
danych dotyczących czynności wykonywanych przez firmę:
— data i godzina czynności,
— typ czynności (blokowanie lub zdejmowanie blokady
z przyrządu rejestrującego lub pobieranie danych z przy­
rządu rejestrującego lub pobieranie danych z karty),
— okres, dla którego pobrano dane (jeżeli ma zastoso­
wanie),
— numer VRN i państwo członkowskie rejestracji
pojazdu,
— numer karty i państwo członkowskie wydające kartę
(w przypadku pobierania danych z karty).
380) Karta firmowa umożliwia przechowywanie co najmniej 230
takich rekordów danych.
▼M3
4.5.6.2.6 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku
wersji 1 drugiej generacji przyrządów rejestrujących)
380a) Karta firmowa umożliwia przechowywanie szczegółowych
ustawień tachografu posiadacza karty.
380b) Pojemność karty firmowej na potrzeby przechowywania
szczegółowych ustawień tachografu posiadacza karty
wynosi 3072 bajty.
▼B
5 INSTALACJA URZĄDZENIA REJESTRUJĄCEGO
5.1 Instalacja
381) Nowe urządzenie rejestrujące dostarcza się instalatorom lub
producentom pojazdów w stanie nieaktywowanym, ze
wszystkimi parametrami kalibracyjnymi, wyszczególnio­
nymi w rozdziale 3.21, ustawionymi na odpowiednie
i prawidłowe wartości domyślne. W przypadku gdy nie
ma konkretnej odpowiedniej wartości, parametry literowe
należy ustawić jako łańcuchy znaków „?”, a parametry licz­
bowe jako „0”. Dostawę części układu zabezpieczającego
urządzeń rejestrujących można w razie konieczności ogra­
niczyć podczas certyfikacji bezpieczeństwa.
382) Przed aktywacją urządzenie rejestrujące umożliwia dostęp
do funkcji kalibracji, nawet jeśli nie jest w trybie
kalibracyjnym.
▼M3
383) Przed aktywacją urządzenia rejestrującego nie rejestruje ono
ani nie przechowuje danych, o których mowa w wymogach
102–133. Niemniej jednak przed aktywacją urządzenia
rejestrującego może ono rejestrować i przechowywać
zdarzenia związane z próbami naruszenia zabezpieczenia
zgodnie z wymogiem 117 oraz usterki urządzenia rejestru­
jącego zgodnie z wymogiem 118.
▼B
384) W czasie instalacji producenci pojazdów wstępnie ustawiają
wszystkie znane parametry.
385) Producenci pojazdów lub instalatorzy aktywują zainstalo­
wane urządzenie rejestrujące najpóźniej przed rozpoczęciem
korzystania z pojazdu w zakresie objętym rozporządze­
niem (WE) nr 561/2006.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 99
386) Aktywacja urządzenia rejestrującego uruchamiana jest auto­
matycznie przez pierwsze włożenie ważnej karty warsz­
tatowej do któregokolwiek czytnika karty.
387) Szczególne czynności parujące, wymagane między czujni­
kiem ruchu a przyrządem rejestrującym, odbywają się
w razie potrzeby automatycznie przed aktywacją lub
w trakcie aktywacji.
388) Podobnie szczególne czynności powiązania, wymagane
między urządzeniem zewnętrznym GNSS a przyrządem
rejestrującym, odbywają się w razie potrzeby automatycznie
przed aktywacją lub w czasie aktywacji.
389) Po aktywowaniu urządzenia rejestrującego wszystkie
funkcje i prawa dostępu do danych muszą być w pełni
wdrożone.
390) Po aktywowaniu urządzenie rejestrujące przekazuje do urzą­
dzenia do łączności na odległość zabezpieczone dane
niezbędne na potrzeby ukierunkowanych kontroli drogowych.
391) Po aktywowaniu urządzenia rejestrującego funkcje rejestro­
wania i przechowywania muszą być w pełni funkcjonalne.
▼M3
392) Następnym krokiem po instalacji jest kalibracja. Podczas
pierwszej kalibracji nie jest konieczne wprowadzenie iden­
tyfikacji rejestracyjnej pojazdu (VRN i państwo członkow­
skie), jeżeli nie jest ona znana zatwierdzonemu warsztatowi
mającemu przeprowadzić kalibrację. W tej sytuacji, i tylko
wtedy, właściciel pojazdu może wprowadzić numer VRN
i państwo członkowskie, używając swojej karty firmowej
przed rozpoczęciem korzystania z pojazdu w zakresie
objętym rozporządzeniem (WE) nr 561/2006 (np. używając
poleceń poprzez odpowiednie menu interfejsu człowiek-
maszyna przyrządu rejestrującego). Każda aktualizacja lub
potwierdzenie wprowadzonych w ten sposób danych są
możliwe jedynie przy użyciu karty warsztatowej.
▼B
393) Instalacja urządzenia zewnętrznego GNSS wymaga powią­
zania z przyrządem rejestrującym, a następnie weryfikacji
informacji o pozycji GNSS.
394) Urządzenie rejestrujące musi być umieszczone w pojeździe
w taki sposób, aby kierowca miał ze swojego siedzenia
dostęp do niezbędnych funkcji.
5.2 Tabliczka instalacyjna
395) ►M3 Po zainstalowaniu i sprawdzeniu urządzenia rejes­
trującego mocuje się na nim dobrze widoczną i łatwo
dostępną tabliczkę instalacyjną, wygrawerowaną lub nadru­
kowaną w trwały sposób. Jeżeli nie jest to możliwe,
tabliczkę mocuje się na słupku „B” pojazdu, tak aby była
dobrze widoczna. W przypadku pojazdów, które nie posia­
dają słupka „B”, tabliczkę instalacyjną należy umocować
w strefie drzwi pojazdu, tak aby zawsze była dobrze
widoczna. ◄
Po każdym przeglądzie przeprowadzonym przez zatwier­
dzonego instalatora lub warsztat, w miejsce starej tabliczki
mocuje się nową.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 100
396) Tabliczka zawiera co najmniej następujące dane:
— nazwa, adres lub nazwa handlowa zatwierdzonego
instalatora lub warsztatu,
— współczynnik charakterystyczny pojazdu, w postaci
„w = …imp/km”,
— stała urządzenia rejestrującego, w postaci „k = …imp/
km”,
— obwód toczny opon, w postaci „l = …mm”,
— rozmiar opon,
— data pomiaru współczynnika charakterystycznego
pojazdu i obwodu tocznego opon,
— numer identyfikacyjny pojazdu,
— obecność (lub brak) urządzenia zewnętrznego GNSS,
— numer seryjny urządzenia zewnętrznego GNSS,
w stosownych przypadkach,
▼M3
— numer seryjny urządzenia do łączności na odległość,
jeżeli występuje,
▼M1
— numer seryjny wszystkich założonych plomb,
— część pojazdu, w której zamontowany jest ewentualny
adapter,
— część pojazdu, w której zamontowany jest czujnik
ruchu, jeżeli nie jest podłączony do skrzyni biegów
lub w przypadku niezastosowania adaptera,
— kolor przewodu łączącego adapter z częścią pojazdu,
z której dochodzą impulsy,
— numer seryjny czujnika ruchu wbudowanego w adapter.
▼M3
— domyślny typ załadunku związany z pojazdem.
▼B
397) Drugą dodatkową tabliczkę można użyć tylko w pojazdach
M1 i N1, w których zainstalowany jest adapter zgodnie
z rozporządzeniem Komisji (WE) nr 68/2009 ( 1 ) z później­
szymi zmianami, oraz gdy nie ma możliwości zamiesz­
czenia wszystkich niezbędnych informacji opisanych
w wymaganiu 396. W takich przypadkach na dodatkowej
tabliczce zamieszczane są co najmniej ostatnie cztery tiret
określone w wymaganiu 396.
▼M1
( 1 ) Rozporządzenie Komisji (WE) nr 68/2009 z dnia 23 stycznia 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 — 21.08.2023 — 003.002 — 101
Drugą dodatkową tabliczkę mocuje się w stosownych przy­
padkach obok lub w pobliżu pierwszej podstawowej
tabliczki opisanej w wymaganiu 396 i zapewnia się jej
taki sam poziom ochrony. Na dodatkowej tabliczce
umieszcza się ponadto nazwę, adres lub nazwę handlową
zatwierdzonego instalatora lub warsztatu, który dokonał
instalacji, oraz datę instalacji.
5.3 Plombowanie
398) Następujące części muszą być zaplombowane:
— Wszelkie połączenia, których rozłączenie może powo­
dować niewykrywalne zmiany danych lub niewykry­
walne utraty danych (może to dotyczyć np. instalacji
czujnika ruchu na skrzyni biegów, adapterów w pojaz­
dach M1/N1, połączenia z urządzeniem zewnętrznym
GNSS lub przyrządu rejestrującego);
— Tabliczka instalacyjna, chyba że jest przymocowana
w taki sposób, że nie można jej usunąć bez uszkodzenia
wykonanych na niej oznaczeń.
▼M1
398a) Plomby, o których mowa powyżej, muszą być certyfiko­
wane zgodnie z normą EN 16882:2016.
▼B
399) Plomby, o których mowa powyżej, mogą być usunięte:
— w nagłych przypadkach,
— w celu zainstalowania, wyregulowania lub naprawy
urządzenia ograniczenia prędkości lub innego urzą­
dzenia istotnego dla bezpieczeństwa drogowego,
z zastrzeżeniem że urządzenie rejestrujące nadal pracuje
niezawodnie i prawidłowo i zostanie powtórnie zaplom­
bowane przez zatwierdzonego instalatora lub warsztat
(zgodnie z rozdziałem 6) niezwłocznie po zainstalo­
waniu urządzenia ograniczenia prędkości lub innego
urządzenia istotnego dla bezpieczeństwa drogowego
lub w terminie siedmiu dni w pozostałych przypadkach.
400) Każdy przypadek zdjęcia takiej plomby wymaga sporzą­
dzenia pisemnego oświadczenia podającego powody
takiego działania, a oświadczenie to udostępniane jest
właściwemu organowi.
401) Plomby muszą mieć numer identyfikacyjny przydzielony
przez ich producenta. Numer ten jest niepowtarzalny
i różny od innych numerów plomb przydzielonych przez
innych producentów plomb.
▼M1
Ten niepowtarzalny numer identyfikacyjny jest określony
w następujący sposób: MMNNNNNNNN w formie nieda­
jącego się usunąć oznakowania, gdzie MM to jednoznaczny
identyfikator producenta (numer w bazie danych prowa­
dzonej przez KE), a NNNNNNNN to numer alfanume­
ryczny plomby, niepowtarzalny dla danego producenta.
▼B
402) Na plombie musi być wolne miejsce, na którym zatwier­
dzeni instalatorzy, warsztaty lub producenci pojazdów
mogą dodać specjalny znak zgodnie z art. 22 ust. 3 rozpo­
rządzenia (UE) nr 165/2014.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 102
Znak ten nie może zakrywać numeru identyfikacyjnego
plomby.
▼M1
403) Producenci plomb muszą być zarejestrowani w specjalnej
bazie danych, gdy otrzymują model plomby certyfikowany
zgodnie z normą EN 16882:2016, i muszą udostępniać
publicznie numery identyfikacyjne plomb w procedurze,
którą ma określić Komisja Europejska.
404) Zatwierdzone warsztaty i producenci pojazdów korzystają,
w ramach rozporządzenia (UE) nr 165/2014, wyłącznie
z plomb certyfikowanych zgodnie z normą EN 16882:2016
od producentów plomb zapisanych w bazie danych, o której
mowa powyżej.
▼B
405) Producenci plomb i ich dystrybutorzy zachowują pełną
dokumentację umożliwiającą identyfikowalność plomb
sprzedawanych do użytku w ramach rozporządzenia (UE)
nr 165/2014 i są gotowi do jej przedłużenia właściwym
organom krajowym w razie potrzeby.
406) Niepowtarzalne numery identyfikacyjne plomb muszą być
widoczne na tabliczce instalacyjnej.
6 KONTROLE, PRZEGLĄDY I NAPRAWY
Wymagania odnośnie do okoliczności, w jakich można usunąć
plomby, określone w art. 22 ust. 5 rozporządzenia (UE) nr 165/2014,
zostały zdefiniowane w rozdziale 5.3 niniejszego załącznika.
6.1 Zatwierdzanie instalatorów, warsztatów i producentów
pojazdów
Państwa członkowskie zatwierdzają, regularnie kontrolują i 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 kontro­
lowany pod względem prawidłowego funkcjonowania oraz
dokładności odczytów i rejestracji, w granicach określo­
nych w rozdziałach 3.2.1, 3.2.2, 3.2.3 oraz 3.3.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 103
6.3 Przegląd instalacyjny
▼M1
408) Po zainstalowaniu w pojeździe cała instalacja (włącznie
z urządzeniem rejestrującym) musi być zgodna z przepisami
dotyczącymi maksymalnych tolerancji ustanowionymi
w rozdziałach 3.2.1, 3.2.2, 3.2.3 i 3.3. Cała instalacja
musi być zaplombowana zgodnie z rozdziałem 5.3 i musi
obejmować kalibrację.
▼B
6.4 Przeglądy okresowe
▼M3
409) Przeglądy okresowe urządzeń zainstalowanych w pojazdach
przeprowadza się po każdej naprawie urządzenia lub po
jakiejkolwiek zmianie współczynnika charakterystycznego
pojazdu lub obwodu tocznego opon, lub gdy czas UTC
urządzenia różni się od czasu UTC o więcej niż 5 minut,
lub przy zmianie numeru VRN i przynajmniej raz w okresie
dwóch lat (24 miesięcy) od ostatniej kontroli.
▼B
410) Przeglądy te obejmują następujące kontrole:
— czy urządzenie rejestrujące działa prawidłowo, włącznie
z funkcją przechowywania danych na kartach do tacho­
grafów oraz łącznością z czytnikami na odległość,
— czy jest zachowana zgodność z wymaganiami rozdziału
3.2.1 i 3.2.2 co do maksymalnych tolerancji przy
instalacji,
— czy jest zachowana zgodność z przepisami rozdziałów
3.2.3 i 3.3,
— czy urządzenie rejestrujące opatrzone jest znakiem
homologacji typu,
— czy tabliczka instalacyjna określona w wymaganiu 396
oraz tabliczka określona w wymaganiu 225 są
zamocowane,
— rozmiaru opon i faktycznego obwodu tocznego opon,
— czy do urządzenia nie są podłączone żadne urządzenia
służące do manipulacji,
— czy plomby są prawidłowo założone, w dobrym stanie,
czy ich numery identyfikacyjne są ważne (producent
plomb zatwierdzony w bazie KE) oraz czy ich numery
identyfikacyjne odpowiadają oznakowaniom na tabliczce
instalacyjnej (zob. wymaganie 401).
▼M3
— czy identyfikator wersji przechowywanej mapy cyfrowej
jest najnowszym identyfikatorem.
410a) W przypadku wykrycia manipulacji przez właściwe organy
krajowe pojazd może zostać wysłany do zatwierdzonego
warsztatu w celu dokonania ponownej kalibracji urządzenia
rejestrującego.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 104
411) Jeżeli jedno ze zdarzeń wymienionych w rozdziale 3.9
(Wykrywanie zdarzeń lub usterek) pojawiło się od czasu
poprzedniego przeglądu i producenci tachografów lub
organy krajowe uważają, że stwarza ono zagrożenie dla
bezpieczeństwa urządzenia, warsztat:
a. porównuje dane identyfikacyjne czujnika ruchu podłą­
czonego do skrzyni biegów z danymi sparowanego czuj­
nika ruchu zarejestrowanymi w przyrządzie rejestru­
jącym;
b. sprawdza, czy informacje zapisane na tabliczce instala­
cyjnej są zgodne z informacjami zawartymi w przyrzą­
dzie rejestrującym;
c. sprawdza, czy numer seryjny czujnika ruchu i numer
homologacji, jeżeli są nadrukowane na obudowie czuj­
nika ruchu, są zgodne z informacjami przechowywa­
nymi w pamięci danych urządzenia rejestrującego;
d. porównuje dane identyfikacyjne umieszczone na tabliczce
znamionowej ewentualnego urządzenia zewnętrznego
GNSS z danymi przechowywanymi w pamięci danych
przyrządu rejestrującego.
412) Warsztaty odnotowują w swoich sprawozdaniach z prze­
glądu wszystkie ustalenia dotyczące zniszczonych plomb
lub urządzeń służących do manipulacji. Warsztaty przecho­
wują przedmiotowe sprawozdania co najmniej przez 2 lata
i udostępniają je każdorazowo na wniosek właściwego
organu.
413) W ramach przeglądów wykonuje się kalibrację i zapobie­
gawczą wymianę plomb, za których montaż odpowiadają
warsztaty.
6.5 Wyznaczanie błędów
414) Wyznaczanie błędów po zainstalowaniu i podczas użytko­
wania jest wykonywane w następujących warunkach, które
stanowią warunki odniesienia:
— pojazd bez obciążenia w stanie gotowym do jazdy,
— ciśnienie w ogumieniu zgodne z instrukcjami producenta,
— zużycie ogumienia w granicach dopuszczalnych przepi­
sami krajowymi,
— ruch pojazdu:
— pojazd porusza się napędzany własnym silnikiem, po
linii prostej i po poziomej powierzchni, z prędkością
50 ± 5 km/h. Odległość pomiarowa wynosi przynaj­
mniej 1 000 m.
— sprawdzenie może być również przeprowadzone inną
metodą, np. na odpowiednim stanowisku warsztatowym,
pod warunkiem że zapewni ono porównywalną dokład­
ność.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 105
6.6 Naprawy
415) Warsztaty mogą pobierać dane z urządzenia rejestrującego
w celu przekazania tych danych odpowiedniej firmie
przewozowej.
416) Zatwierdzone warsztaty wydają firmom przewozowym
zaświadczenie o niemożliwości pobrania danych, w przy­
padku gdy uszkodzenie urządzenia rejestrującego uniemoż­
liwia pobranie zarejestrowanych danych nawet po naprawie
w tym warsztacie. Warsztaty przechowują kopię każdego
wydanego zaświadczenia przez okres co najmniej dwóch
lat.
7 WYDAWANIE KART
Procedury wydawania kart określone przez państwa członkowskie
spełniają następujące wymagania:
417) Pierwsza karta do tachografów wydana wnioskodawcy ma
numer karty równy numerowi kolejnemu (jeżeli ma zasto­
sowanie), a numer wymiany i numer odnowienia ustawione
na „0”.
418) Numery karty wszystkich nieosobistych kart do tacho­
grafów wydanych jednemu organowi kontrolnemu lub
jednemu warsztatowi lub jednej firmie przewozowej mają
te same pierwsze 13 cyfr i wszystkie mają różny numer
kolejny.
419) Karta do tachografów wydana jako duplikat istniejącej
karty do tachografów ma ten sam numer karty co karta
zastąpiona, z wyjątkiem numeru wymiany, który jest
zwiększany o „1” (w kolejności 0, …, 9, A, …, Z).
420) Karta do tachografów wydana jako duplikat istniejącej
karty do tachografów ma ten sam termin ważności karty
co karta zastąpiona.
421) Karta do tachografów wydana jako odnowienie istniejącej
karty do tachografów ma ten sam numer karty co karta
odnowiona, z wyjątkiem numeru wymiany, który jest usta­
wiony na „0” i numeru odnowienia, który jest zwiększany
o „1” (w kolejności 0, …, 9, A, …, Z).
422) Przy wymianie istniejącej karty do tachografów w celu
zmiany danych administracyjnych stosuje się te same
zasady co przy odnawianiu, jeżeli odbywa się w tym
samym państwie członkowskim, lub te same zasady co
przy pierwszym wydaniu, jeżeli odbywa się w innym
państwie członkowskim.
423) W rubryce „nazwisko posiadacza karty” w przypadku
nieosobistych kart warsztatowych lub kontrolnych wpisuje
się albo nazwę warsztatu lub organu kontrolnego albo
nazwisko instalatora lub funkcjonariusza służb kontrolnych,
według uznania państw członkowskich.
424) Państwa członkowskie wymieniają dane drogą elektro­
niczną w celu zapewnienia niepowtarzalności wydawanych
kart kierowcy zgodnie z art. 31 rozporządzenia (UE)
nr 165/2014.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 106
8 HOMOLOGACJA TYPU URZĄDZEŃ REJESTRUJĄCYCH
I KART DO TACHOGRAFÓW
8.1 Uwagi ogólne
▼M1
Do celów niniejszego rozdziału wyrażenie „urządzenie rejestrujące”
oznacza „urządzenie rejestrujące lub jego elementy składowe”.
Homologacji typu nie wymaga się dla przewodu(-ów) łączącego(-
ych) czujnik ruchu z przyrządem rejestrującym, urządzenie
zewnętrzne GNSS z przyrządem rejestrującym lub zewnętrzne urzą­
dzenie do łączności na odległość z przyrządem rejestrującym. 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 rejestrują­
cego producenci prowadzą powszechnie dostępny wykaz anten
i rozdzielaczy kompatybilnych z każdym homologowanym przyrządem
rejestrującym, urządzeniem zewnętrznym GNSS i zewnętrznym urzą­
dzeniem do łączności na odległość.
▼B
425) Urządzenie rejestrujące dostarcza się do homologacji
w stanie kompletnym z wszystkimi zintegrowanymi urzą­
dzeniami dodatkowymi.
426) Homologacja typu urządzenia rejestrującego i kart do
tachografów obejmuje badania związane z bezpieczeń­
stwem, badania funkcjonalności i badania interoperacyj­
ności. Pozytywne wyniki każdego z tych badań potwierdza
się odpowiednim świadectwem.
▼M1
427) Organy homologacji typu w państwach członkowskich nie
wydają świadectwa homologacji typu, dopóki nie otrzy­
mają:
— świadectwa bezpieczeństwa (jeżeli jest ono wymagane
na podstawie niniejszego załącznika),
— świadectwa funkcjonalności,
— świadectwa interoperacyjności (jeżeli jest ono wyma­
gane na podstawie niniejszego załącznika),
dla urządzenia rejestrującego lub kart do tachografów, dla
których złożono wniosek o homologację typu.
▼B
428) O wszelkich modyfikacjach oprogramowania lub sprzętu
urządzenia lub rodzaju materiałów użytych do wytworzenia
urządzenia należy, przed zastosowaniem, zawiadomić
organ, który wydał homologację typu dla urządzenia.
Organ ten potwierdza producentowi rozszerzenie homolo­
gacji typu lub też może zażądać uaktualnienia lub potwier­
dzenia stosownych świadectw funkcjonalności, bezpieczeń­
stwa lub interoperacyjności.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 107
429) Procedury aktualizacji oprogramowania w prawidłowo
funkcjonującym urządzeniu rejestrującym zatwierdza organ,
który wydał homologację typu dla tego urządzenia rejes­
trującego. Aktualizacja oprogramowania nie może zmienić
ani usunąć żadnych danych dotyczących czynności
kierowcy przechowywanych w pamięci urządzenia rejestru­
jącego. Oprogramowanie można aktualizować wyłącznie na
odpowiedzialność producenta urządzenia.
430) Nie można odmówić homologacji typu zmian w oprogramo­
waniu, których celem jest aktualizacja wcześniej homolo­
gowanego typu urządzenia rejestrującego, jeżeli takie
zmiany dotyczą wyłącznie funkcji nieokreślonych w niniej­
szym załączniku. Aktualizacja oprogramowania urządzenia
rejestrującego może nie obejmować wprowadzania nowych
zestawów znaków, jeśli nie jest to technicznie wykonalne.
▼B
8.2 Świadectwo bezpieczeństwa
431) Świadectwo bezpieczeństwa wydaje się zgodnie z przepi­
sami dodatku 10 do niniejszego załącznika. Elementy skła­
dowe urządzenia rejestrującego objęte certyfikacją to przy­
rząd rejestrujący, czujnik ruchu, urządzenie zewnętrzne
GNSS i karty do tachografów.
432) W wyjątkowej sytuacji, gdy organy certyfikacji bezpieczeń­
stwa odmawiają certyfikowania nowego urządzenia
z powodu przestarzałych mechanizmów bezpieczeństwa,
homologację typu przyznaje się nadal tylko w tych konkret­
nych i wyjątkowych okolicznościach oraz jeżeli, zgodnie
z rozporządzeniem, nie istnieje rozwiązanie alternatywne.
433) W takiej sytuacji dane państwo członkowskie bezzwłocznie
informuje Komisję Europejską, która w ciągu dwunastu
miesięcy kalendarzowych od przyznania homologacji typu
wszczyna procedurę mającą na celu zapewnienie przywró­
cenia poziomu bezpieczeństwa do stanu początkowego.
8.3 Świadectwo funkcjonalności
434) Każdy ubiegający się o homologację typu dostarcza orga­
nowi państwa członkowskiego właściwemu dla homolo­
gacji typu wszelkie materiały i dokumentacje, jakie organ
ten uzna za niezbędne.
435) W ciągu jednego miesiąca od złożenia wniosku producenci
dostarczają odpowiednie próbki produktów posiadających
homologację typu i związaną z nimi dokumentację wyma­
ganą przez laboratoria wyznaczone do przeprowadzenia
badań funkcjonalności. Wnioskodawca ponosi wszystkie
koszty wynikające z przedmiotowego wniosku. Laboratoria
zachowują poufność wszystkich informacji wrażliwych pod
względem handlowym.
436) Świadectwo funkcjonalności wydaje się producentowi
wyłącznie po pozytywnym przejściu przynajmniej przez
wszystkie badania funkcjonalności wyszczególnione
w dodatku 9.
437) Organ właściwy dla homologacji typu wydaje świadectwo
funkcjonalności. W świadectwie tym podaje się, oprócz
nazwy (nazwiska) otrzymującego świadectwo i identyfikacji
modelu, szczegółowy wykaz wykonanych badań i uzyska­
nych wyników.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 108
438) W świadectwie funkcjonalności każdego elementu składo­
wego urządzenia rejestrującego wskazuje się także numery
homologacji typu wszystkich innych homologowanych
kompatybilnych elementów składowych urządzenia rejes­
trującego przebadanych do celów certyfikacji.
439) W świadectwie funkcjonalności każdego elementu składo­
wego urządzenia rejestrującego wskazuje się także normę
CEN lub ISO, na podstawie której certyfikowano interfejs
funkcjonalny.
8.4 Świadectwo interoperacyjności
440) Badania interoperacyjności przeprowadza jedno laborato­
rium w imieniu i na odpowiedzialność Komisji Europej­
skiej.
441) Laboratorium rejestruje wnioski o badania interoperacyj­
ności złożone przez producentów w kolejności chronolo­
gicznej napływu tych wniosków.
442) Wnioski rejestruje się oficjalnie tylko wtedy, gdy w posia­
daniu laboratorium znajdują się:
— komplet materiałów i dokumentów niezbędnych do
takich badań interoperacyjności,
— odpowiednie świadectwo bezpieczeństwa,
— odpowiednie świadectwo funkcjonalności.
Producenta zawiadamia się o dacie rejestracji wniosku.
▼M3
443) Laboratorium nie może przeprowadzać żadnych badań inte­
roperacyjności urządzeń rejestrujących ani kart do tacho­
grafów, które nie przeszły pomyślnie analizy podatności
na zagrożenia w ramach ich oceny bezpieczeństwa,
a także oceny funkcjonalnej, poza wyjątkowymi sytuacjami
opisanymi w wymogu 432.
▼B
444) Producent wnioskujący o przeprowadzenie badań interope­
racyjności zobowiązuje się do pozostawienia w laborato­
rium, które ma przeprowadzić te badania, kompletu mate­
riałów i dokumentów, które dostarczył do przeprowadzenia
tych badań.
445) Badania interoperacyjności przeprowadza się, zgodnie
z przepisami dodatku 9 do niniejszego załącznika, dla,
odpowiednio, wszystkich typów urządzenia rejestrującego
lub kart do tachografów:
— które mają jeszcze ważną homologację typu, lub
— których homologacja typu jest w toku i które mają
ważne świadectwo interoperacyjności.
446) Badania interoperacyjności obejmują wszystkie generacje
urządzeń rejestrujących lub kart do tachografów będące
nadal w użyciu.
▼M3
447) Laboratorium wydaje producentowi świadectwo interopera­
cyjności tylko wówczas, gdy objęte nim urządzenia
pomyślnie przejdą wszystkie wymagane badania interope­
racyjności, i po wykazaniu przez producenta, że wydano
zarówno ważne świadectwo funkcjonalności, jak i ważne
świadectwo bezpieczeństwa dla produktu, z wyjątkiem
wyjątkowych okoliczności opisanych w wymogu 432.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 109
448) Jeżeli co najmniej jedno urządzenie rejestrujące lub karta
do tachografów nie przejdą pomyślnie badań interoperacyj­
ności, świadectwa interoperacyjności nie wydaje się, dopóki
wnioskujący producent nie wprowadzi niezbędnych
poprawek i dopóki nie przejdą one pomyślnie przez
badania interoperacyjności. Laboratorium, przy pomocy
zainteresowanych producentów, rozpoznaje przyczynę
usterki interoperacyjności i dokłada starań, by pomóc
wnioskującemu producentowi w znalezieniu rozwiązania
technicznego. W przypadku gdy producent modyfikuje
swój produkt, odpowiada on za uzyskanie potwierdzenia
właściwych organów, że świadectwo bezpieczeństwa i świa­
dectwo funkcjonalności nadal zachowują ważność.
449) Świadectwo interoperacyjności ważne jest przez sześć
miesięcy. Zostaje ono odwołane na koniec tego okresu,
jeżeli producent nie uzyska odpowiadającego mu świa­
dectwa homologacji typu. Producent przekazuje to świa­
dectwo organowi homologacji typu w państwie członkow­
skim, który wydał świadectwo funkcjonalności.
450) Żaden element, który może być źródłem usterki interopera­
cyjności, nie może być użyty do osiągania korzyści
z pozycji dominującej ani prowadzić do uzyskania takiej
pozycji.
8.5 Świadectwo homologacji typu
451) Organ homologacji typu w państwie członkowskim może
wydać świadectwo homologacji typu, jeżeli posiada trzy
wymagane świadectwa.
452) W świadectwie homologacji typu każdego elementu skła­
dowego urządzenia rejestrującego wskazuje się także
numery homologacji typu innych homologowanych intero­
peracyjnych urządzeń rejestrujących.
453) Organ homologacji typu przekazuje kopię świadectwa
homologacji typu do laboratorium właściwego do przepro­
wadzenia badań interoperacyjności równocześnie z dostar­
czeniem świadectwa producentowi.
454) Laboratorium właściwe do przeprowadzenia badań intero­
peracyjności prowadzi publiczną stronę internetową, na
której znajduje się uaktualniony wykaz modeli urządzeń
rejestrujących lub kart do tachografów:
— dla których zarejestrowano wniosek o badania interope­
racyjności,
— które uzyskały świadectwo interoperacyjności (nawet
czasowe),
— które uzyskały świadectwo homologacji typu.
8.6 Procedura szczególna: pierwsze świadectwa interoperacyjności
dla urządzeń rejestrujących i kart do tachografów 2. generacji
455) Przez cztery miesiące od czasu, gdy pierwsza para urządzeń
rejestrujących 2. generacji i kart do tachografów 2. gene­
racji (karty kierowcy, warsztatowe, kontrolne i firmowe)
uzyska świadectwa interoperacyjności, wszelkie wydane
świadectwa interoperacyjności (łącznie z pierwszymi),
w odniesieniu do wniosków zarejestrowanymi w tym
okresie, uważa się za czasowe.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 110
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ń interope­
racyjności rozpoznaje przyczyny problemów z pomocą
wszystkich zainteresowanych producentów i zachęca ich
do wprowadzenia niezbędnych poprawek.
458) Jeżeli na koniec tego okresu nadal występują problemy
interoperacyjności, laboratorium właściwe do przeprowa­
dzenia badań interoperacyjności, we współpracy z zaintere­
sowanymi producentami i organami homologacji typu,
które wydały odpowiednie świadectwa funkcjonalności,
szuka przyczyn usterek interoperacyjności i ustala, jakie
poprawki powinien wprowadzić każdy z zainteresowanych
producentów. Poszukiwanie rozwiązań technicznych trwa
maksymalnie dwa miesiące, po czym, jeśli nie zostanie
znalezione wspólne rozwiązanie, Komisja, po konsultacji
z laboratorium właściwym do przeprowadzenia badań inte­
roperacyjności, decyduje, które urządzenie(-a) i karty otrzy­
mują ostateczne świadectwa interoperacyjności wraz
z uzasadnieniem swojej decyzji.
459) Wszelkie wnioski o przeprowadzenie badań interoperacyj­
ności, zarejestrowane przez laboratorium w okresie między
końcem czteromiesięcznego okresu po dostarczeniu pierw­
szego czasowego świadectwa interoperacyjności a datą
decyzji Komisji, o której mowa w wymaganiu 455, są
odraczane aż do rozwiązania początkowych problemów
interoperacyjności. Następnie wnioski te rozpatruje się
w kolejności chronologicznej ich rejestracji.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 111
Dodatek 1
SPIS DANYCH:
SPIS TREŚCI
1. WPROWADZENIE
1.1. Podejście do definicji typów danych
1.2. Odniesienia
2. DEFINICJE TYPÓW DANYCH
2.1. ActivityChangeInfo
2.2. Address
2.3. AESKey
2.4. AES128Key
2.5. AES192Key
2.6. AES256Key
2.7. BCDString
2.8. CalibrationPurpose
2.9. CardActivityDailyRecord
2.10. CardActivityLengthRange
2.11. CardApprovalNumber
▼M3
2.11a. CardBorderCrossing
2.11b. CardBorderCrossingRecord
▼B
2.12. CardCertificate
2.13. CardChipIdentification
2.14. CardConsecutiveIndex
2.15. CardControlActivityDataRecord
2.16. CardCurrentUse
2.17. CardDriverActivity
2.18. CardDrivingLicenceInformation
2.19. CardEventData
2.20. CardEventRecord
2.21. CardFaultData
2.22. CardFaultRecord
2.23. CardIccIdentification
2.24. CardIdentification
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 112
2.24a. CardLoadTypeEntries
2.24b. CardLoadTypeEntryRecord
2.24c. CardLoadUnloadOperations
2.24d. CardLoadUnloadRecord
▼B
2.25. CardMACertificate
2.26. CardNumber
▼M3
2.26a. CardPlaceAuthDailyWorkPeriod
▼B
2.27. CardPlaceDailyWorkPeriod
2.28. CardPrivateKey
2.29. CardPublicKey
2.30. CardRenewalIndex
2.31. CardReplacementIndex
2.32. CardSignCertificate
2.33. CardSlotNumber
2.34. CardSlotsStatus
2.35. CardSlotsStatusRecordArray
2.36. CardStructureVersion
2.37. CardVehicleRecord
2.38. CardVehiclesUsed
2.39. CardVehicleUnitRecord
2.40. CardVehicleUnitsUsed
2.41. Certyfikat
2.42. CertificateContent
2.43. CertificateHolderAuthorisation
2.44. CertificateRequestID
2.45. CertificationAuthorityKID
2.46. CompanyActivityData
2.47. CompanyActivityType
2.48. CompanyCardApplicationIdentification
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 113
2.48a. CompanyCardApplicationIdentificationV2
▼B
2.49. CompanyCardHolderIdentification
2.50. ControlCardApplicationIdentification
▼M3
2.50a. ControlCardApplicationIdentificationV2
▼B
2.51. ControlCardControlActivityData
2.52. ControlCardHolderIdentification
2.53. ControlType
2.54. CurrentDateTime
2.55. CurrentDateTimeRecordArray
2.56. DailyPresenceCounter
2.57. Datef
2.58. DateOfDayDownloaded
2.59. DateOfDayDownloadedRecordArray
2.60. Distance
▼M3
2.60a. DownloadInterfaceVersion
▼B
2.61. DriverCardApplicationIdentification
▼M3
2.61a. DriverCardApplicationIdentificationV2
▼B
2.62. DriverCardHolderIdentification
▼M1
2.63. Zarezerwowany dla przyszłego użytku
▼B
2.64. EGFCertificate
2.65. EmbedderIcAssemblerId
2.66. EntryTypeDailyWorkPeriod
2.67. EquipmentType
2.68. EuropeanPublicKey
2.69. EventFaultRecordPurpose
2.70. EventFaultType
2.71. ExtendedSealIdentifier
2.72. ExtendedSerialNumber
2.73. FullCardNumber
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 114
2.74. FullCardNumberAndGeneration
2.75. Generation
2.76. GeoCoordinates
2.77. GNSSAccuracy
▼M1
2.78. GNSSAccumulatedDriving
2.79. GNSSAccumulatedDrivingRecord
▼M3
2.79a. GNSSAuthAccumulatedDriving
2.79b. GNSSAuthStatusADRecord
2.79c. GNSSPlaceAuthRecord
▼B
2.80. GNSSPlaceRecord
2.81. HighResOdometer
2.82. HighResTripDistance
2.83. HolderName
▼M3
2.84. Zarezerwowane dla przyszłego użytku
▼B
2.85. K-ConstantOfRecordingEquipment
2.86. KeyIdentifier
2.87. KMWCKey
2.88. Language
2.89. LastCardDownload
▼M3
2.89a. LengthOfFollowingData
▼B
2.90. LinkCertificate
▼M3
2.90a. LoadType
▼B
2.91. L-TyreCircumference
2.92. MAC
2.93. ManualInputFlag
2.94. ManufacturerCode
2.95. ManufacturerSpecificEventFaultData
2.96. MemberStateCertificate
2.97. MemberStateCertificateRecordArray
2.98. MemberStatePublicKey
2.99. Name
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 115
2.100. NationAlpha
2.101. NationNumeric
▼M3
2.101a. NoOfBorderCrossingRecords
▼B
2.102. NoOfCalibrationRecords
2.103. NoOfCalibrationsSinceDownload
2.104. NoOfCardPlaceRecords
2.105. NoOfCardVehicleRecords
2.106. NoOfCardVehicleUnitRecords
2.107. NoOfCompanyActivityRecords
2.108. NoOfControlActivityRecords
2.109. NoOfEventsPerType
2.110. NoOfFaultsPerType
▼M1
2.111. NoOfGNSSADRecords
▼M3
2.111a. NoOfLoadUnloadRecords
▼B
2.112. NoOfSpecificConditionRecords
▼M3
2.112a. NoOfLoadTypeEntryRecords
▼B
2.113. OdometerShort,
2.114. OdometerValueMidnight
▼M3
2.114a. OperationType
▼B
2.115. OdometerValueMidnightRecordArray
2.116. OverspeedNumber
▼M3
2.116a. PlaceAuthRecord
2.116b. PlaceAuthStatusRecord
▼B
2.117. PlaceRecord
▼M3
2.117a. PositionAuthenticationStatus
▼B
2.118. PreviousVehicleInfo
2.119. PublicKey
2.120. RecordType
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 116
2.121. RegionAlpha
2.122. RegionNumeric
2.123. RemoteCommunicationModuleSerialNumber
2.124. RSAKeyModulus
2.125. RSAKeyPrivateExponent
2.126. RSAKeyPublicExponent
2.127. RtmData
2.128. SealDataCard
2.129. SealDataVu
2.130. SealRecord
2.131. SensorApprovalNumber
2.132. SensorExternalGNSSApprovalNumber
2.133. SensorExternalGNSSCoupledRecord
2.134. SensorExternalGNSSIdentification
2.135. SensorExternalGNSSInstallation
2.136. SensorExternalGNSSOSIdentifier
2.137. SensorExternalGNSSSCIdentifier
2.138. SensorGNSSCouplingDate
2.139. SensorGNSSSerialNumber
2.140. SensorIdentification
2.141. SensorInstallation
2.142. SensorInstallationSecData
2.143. SensorOSIdentifier
2.144. SensorPaired
2.145. SensorPairedRecord
2.146. SensorPairingDate
2.147. SensorSCIdentifier
2.148. SensorSerialNumber
2.149. Podpis
2.150. SignatureRecordArray
2.151. SimilarEventsNumber
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 117
2.152. SpecificConditionRecord
2.153. SpecificConditions
2.154. SpecificConditionType
2.155. Prędkość
2.156. SpeedAuthorised
2.157. SpeedAverage
2.158. SpeedMax
▼M3
2.158a. TachographCardsGen1Suppression
▼B
2.159. TachographPayload
▼M1
2.160. Zarezerwowany dla przyszłego użytku
▼B
2.161. TDesSessionKey
2.162. TimeReal
2.163. TyreSize
2.164. VehicleIdentificationNumber
2.165. VehicleIdentificationNumberRecordArray
2.166. VehicleRegistrationIdentification
▼M3
2.166a. VehicleRegistrationIdentificationRecordArray
▼B
2.167. VehicleRegistrationNumber
2.168. VehicleRegistrationNumberRecordArray
2.169. VuAbility
2.170. VuActivityDailyData
2.171. VuActivityDailyRecordArray
2.172. VuApprovalNumber
2.173. VuCalibrationData
2.174. VuCalibrationRecord
2.175. VuCalibrationRecordArray
2.176. VuCardIWData
2.177. VuCardIWRecord
2.178. VuCardIWRecordArray
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 118
2.179. VuCardRecord
2.180. VuCardRecordArray
2.181. VuCertificate
2.182. VuCertificateRecordArray
2.183. VuCompanyLocksData
2.184. VuCompanyLocksRecord
2.185. VuCompanyLocksRecordArray
▼M3
2.185a. VuConfigurationLengthRange
▼B
2.186. VuControlActivityData
2.187. VuControlActivityRecord
2.188. VuControlActivityRecordArray
2.189. VuDataBlockCounter
2.190. VuDetailedSpeedBlock
2.191. VuDetailedSpeedBlockRecordArray
2.192. VuDetailedSpeedData
▼M3
2.192a. VuDigitalMapVersion
▼B
2.193. VuDownloadablePeriod
2.194. VuDownloadablePeriodRecordArray
2.195. VuDownloadActivityData
2.196. VuDownloadActivityDataRecordArray
2.197. VuEventData
2.198. VuEventRecord
2.199. VuEventRecordArray
2.200. VuFaultData
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 119
2.201. VuFaultRecord
2.202. VuFaultRecordArray
▼M1
2.203. VuGNSSADRecord
▼M3
2.203a. VuBorderCrossingRecord
2.203b. VuBorderCrossingRecordArray
▼M1
2.204. VuGNSSADRecordArray
▼M3
2.204a. VuGnssMaximalTimeDifference
▼B
2.205. VuIdentification
2.206. VuIdentificationRecordArray
2.207. VuITSConsentRecord
2.208. VuITSConsentRecordArray
▼M3
2.208a. VuLoadUnloadRecord
2.208b. VuLoadUnloadRecordArray
▼B
2.209. VuManufacturerAddress
2.210. VuManufacturerName
2.211. VuManufacturingDate
2.212. VuOverSpeedingControlData
2.213. VuOverSpeedingControlDataRecordArray
2.214. VuOverSpeedingEventData
2.215. VuOverSpeedingEventRecord
2.216. VuOverSpeedingEventRecordArray
2.217. VuPartNumber
2.218. VuPlaceDailyWorkPeriodData
2.219. VuPlaceDailyWorkPeriodRecord
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 120
2.220. VuPlaceDailyWorkPeriodRecordArray
2.221. VuPrivateKey
2.222. VuPublicKey
▼M3
2.222a. VuRtcTime
▼B
2.223. VuSerialNumber
2.224. VuSoftInstallationDate
2.225. VuSoftwareIdentification
2.226. VuSoftwareVersion
2.227. VuSpecificConditionData
2.228. VuSpecificConditionRecordArray
2.229. VuTimeAdjustmentData
▼M1
2.230. Zarezerwowany dla przyszłego użytku
2.231. Zarezerwowany dla przyszłego użytku
▼B
2.232. VuTimeAdjustmentRecord
2.233. VuTimeAdjustmentRecordArray
2.234. WorkshopCardApplicationIdentification
▼M3
2.234a. WorkshopCardApplicationIdentificationV2
2.234b. WorkshopCardCalibrationAddData
2.234c. WorkshopCardCalibrationAddDataRecord
▼B
2.235. WorkshopCardCalibrationData
2.236. WorkshopCardCalibrationRecord
2.237. WorkshopCardHolderIdentification
2.238. WorkshopCardPIN
2.239. W-VehicleCharacteristicConstant
2.240. VuPowerSupplyInterruptionRecord
2.241. VuPowerSupplyInterruptionRecordArray
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 121
2.242. VuSensorExternalGNSSCoupledRecordArray
2.243. VuSensorPairedRecordArray
3. DEFINICJE WARTOŚCI I ZAKRESU WIELKOŚCI
4. ZESTAW ZNAKÓW:
5. KODOWANIE
6. IDENTYFIKATORY OBIEKTU I IDENTYFIKATORY APLIKACJI
6.1. Identyfikatory obiektu
6.2. Identyfikatory aplikacji
1. WPROWADZENIE
Niniejszy dodatek określa formaty danych, elementy danych i 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 — 21.08.2023 — 003.002 — 122
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
▼M3
Dla każdego z następujących typów danych wartość domyślna
„nieznane” lub zawartość „nie dotyczy” polega na wypełnieniu elementu
danych bajtami Hex „FF”, o ile nie określono inaczej.
Wszystkie typy danych są wykorzystywane w aplikacjach generacji 1
i 2, o ile nie określono inaczej. Wskazane są typy danych stosowane
wyłącznie w aplikacjach wersji 2 generacji 2.
W przypadku typów danych karty używanych do aplikacji generacji 1
i 2 wielkość określona w niniejszym dodatku to wielkość dla 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 aplikacje generacji 2.
Typy danych karty niezdefiniowane dla kart generacji 1 nie są zapisy­
wane w aplikacji generacji 1 dla kart generacji 2. W szczególności:
— numery homologacji typu zapisane w aplikacji generacji 1 dla kart
generacji 2 są, w razie potrzeby, skracane do 8 pierwszych znaków,
— W aplikacji generacji 1 dla kart generacji 2 zapisuje się jedynie
„początek PRZEPRAWY PROMOWEJ/POCIĄGOWEJ” stanu
szczególnego „PRZEPRAWA PROMOWA/POCIĄGOWA”.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 123
2.1. ActivityChangeInfo
Ten typ danych umożliwia kodowanie, w dwubajtowym słowie, stanu
szczeliny czytnika o godzinie 00:00 lub statusu kierowcy o 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,
„c”B Stan prowadzenia pojazdu:
„0”B: JEDEN KIEROWCA,
„1”B: ZAŁOGA,
„p”B Stan karty kierowcy (lub warsztatowej) w odpowied­
niej szczelinie czytnika:
„0”B: WŁOŻONA, karta jest włożona,
„1”B: NIEWŁOŻONA, brak karty (lub karta jest
wyjęta),
„aa”B Czynność:
„00”B: PRZERWA/ODPOCZYNEK,
„01”B: GOTOWOŚĆ,
„10”B: PRACA,
„11”B: PROWADZENIE,
„ttttttttttt”B Godzina zmiany: liczba minut od godziny 00:00
w danym dniu.
Dla zapisów na kartach kierowcy (lub warsztatowej) (i statusu
kierowcy):
„s”B Szczelina czytnika karty (nieistotne, gdy „p” = 1
z wyjątkiem jak w uwadze poniżej):
„0”B: KIEROWCA,
„1”B: WSPÓŁKIEROWCA,
„c”B Stan prowadzenia pojazdu (przypadek „p” = 0); lub
Następny stan czynności (przypadek „p” = 1):
„0”B: JEDEN KIEROWCA,
„0”B: NIEZNANY
„1”B: ZAŁOGA,
„1”B: ZNANY (=wprowadzony ręcznie)
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 124
„p”B Stan karty:
„0”B: WŁOŻONA, karta jest włożona do urządzenia
rejestrującego,
„1”B: NIEWŁOŻONA, brak karty (lub karta jest
wyjęta)
„aa”B Czynność (nieistotne, gdy „p” = 1 i „c” = 0 z wyjąt­
kiem jak w uwadze poniżej):
„00”B: PRZERWA/ODPOCZYNEK,
„01”B: GOTOWOŚĆ,
„10”B: PRACA,
„11”B: PROWADZENIE,
„ttttttttttt”B Godzina zmiany: liczba minut od godziny 00:00
w danym dniu.
Uwaga dla przypadku „wyjęcie karty”:
Gdy karta jest wyjęta:
— „s” odnosi się do szczeliny czytnika i wskazuje szczelinę 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ę.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 125
2.4. AES128Key
Generacja 2:
Klucz AES 128.
length oznacza długość klucza AES 128 w oktetach.
aes128Key oznacza klucz AES o długości 128 bitów.
Przypisanie wartości:
długość ma wartość 16.
2.5. AES192Key
Generacja 2:
Klucz AES 192.
length oznacza długość klucza AES 192 w oktetach.
aes192Key oznacza klucz AES o długości 192 bitów.
Przypisanie wartości:
długość ma wartość 24.
2.6. AES256Key
Generacja 2:
Klucz AES 256.
długość oznacza długość klucza AES 256 w oktetach.
aes256Key oznacza klucz AES o długości 256 bitów.
Przypisanie wartości:
długość ma wartość 32.
2.7. BCDString
BCDString jest stosowany do reprezentacji liczb w zapisie 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”.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 126
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.
Przypisanie wartości:
Generacja 1:
„00”H wartość zastrzeżona,
„01”H aktywacja: zapis parametrów kalibracyjnych
znanych w momencie aktywacji VU,
„02”H pierwsza instalacja: pierwsza kalibracja VU po
aktywacji,
„03”H instalacja: pierwsza kalibracja VU w bieżącym
pojeździe,
„04”H przegląd okresowy.
Generacja 2:
Oprócz generacji 1 używane są następujące wartości:
„05”H wprowadzenie VRN przez firmę,
„06”H korekta czasu bez kalibracji,
„07”H to „7F”H RFU,
„80”H – „FF”H swoisty dla producenta.
2.9. CardActivityDailyRecord
Informacje, zapisane na karcie, dotyczące czynności kierowcy w danym
dniu kalendarzowym. Ten typ danych związany jest z wymaganiami
266, 291, 320 i 343 określonymi w załączniku 1C.
activityPreviousRecordLength jest całkowitą długością w bajtach
poprzedniego rekordu dziennego. Maksymalną wartość określa dł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.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 127
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.
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.
▼M3
2.11a. CardBorderCrossings
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsz­
tatowej dotyczące przekroczeń granicy przez pojazd, jeżeli przekroczył
on granicę krajową (wymogi 306f i 356f określone w załączniku IC).
borderCrossingPointerNewestRecord jest indeksem ostatniego uaktual­
nionego rekordu przekroczenia granicy.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordu
dotyczącego przekroczenia granicy, rozpoczynając od „0” dla pierw­
szego wystąpienia w strukturze rekordu dotyczącego przekroczenia
granicy.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 128
cardBorderCrossingRecords jest zbiorem rekordów przekroczenia
granicy.
2.11b. CardBorderCrossingRecord
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsz­
tatowej dotyczące przekroczeń granicy przez pojazd, jeżeli przekroczył
on granicę krajową (wymogi 147b, 306e i 356e określone w załączniku
IC).
countryLeft to kraj, który pojazd opuścił, lub „brak dostępnych infor­
macji” zgodnie z wymogiem 147b określonym w załączniku IC. „Reszta
świata” (kod 'FF’H NationNumeric) stosuje się, gdy przyrząd rejestru­
jący nie jest w stanie określić kraju, w którym pojazd się znajduje (np.
bieżący kraj nie jest objęty zapisanymi mapami cyfrowymi).
countryEntered to kraj, do którego pojazd wjechał, lub kraj, w którym
pojazd się znajduje w momencie włożenia karty. „Reszta świata” (kod
'FF’H NationNumeric) stosuje się, gdy przyrząd rejestrujący nie jest
w stanie określić kraju, w którym pojazd się znajduje (np. bieżący
kraj nie jest objęty zapisanymi mapami cyfrowymi).
gnssPlaceAuthRecord zawiera informacje dotyczące pozycji pojazdu,
gdy przyrząd rejestrujący wykrył, że pojazd przekroczył granicę krajową,
lub „brak dostępnych informacji” zgodnie z wymogiem 147b w załącz­
niku IC, a także jej statusu uwierzytelnienia.
vehicleOdometerValue to stan licznika kilometrów, gdy przyrząd rejes­
trujący wykrył, że pojazd przekroczył granicę krajową, lub „brak dostęp­
nych informacji” zgodnie z wymogiem 147b w załączniku IC.
▼B
2.12. CardCertificate
Generacja 1:
Certyfikat klucza publicznego karty.
2.13. CardChipIdentification
Informacje, zapisane na karcie, dotyczące identyfikacji układu scalonego
karty (IC) (wymaganie 249 określone w załączniku 1C). 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.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 129
icManufacturingReferences jest identyfikatorem swoistym producenta
IC.
2.14. CardConsecutiveIndex
Numer kolejny karty (definicja h)).
Przypisanie wartości: (zob. rozdział 7 załącznika 1C)
Kolejność zwiększania: „0, …, 9, A, …, Z, a, …, z”
2.15. CardControlActivityDataRecord
Informacje przechowywane na karcie kierowcy lub warsztatowej 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
okresem, 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.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 130
2.17. CardDriverActivity
Informacje przechowywane na karcie kierowcy lub na karcie warsz­
tatowej dotyczące czynności kierowcy (wymagania 267, 268, 292,
293, 321 i 344 określone w załączniku 1C).
activityPointerOldestDayRecord jest wskaźnikiem początku miejsca
gromadzenia danych (liczba bajtów od początku łańcucha znaków)
najstarszego, pełnego rekordu dziennego w łańcuchu activityDailyRe­
cords. Maksymalna wartość jest określona długością łańcucha.
activityPointerNewestRecord jest wskaźnikiem początku miejsca
gromadzenia danych (liczba bajtów od początku łańcucha znaków)
najświeższego rekordu dziennego w łańcuchu activityDailyRecords.
Maksymalna wartość jest określona długością łańcucha.
activityDailyRecords jest przestrzenią dostępną do przechowywania
danych dotyczących czynności kierowcy (struktura danych: 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.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 131
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:
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.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 132
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.
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.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 133
embedderIcAssemblerId zapewnia informacje o wbudowującym/montu­
jącym układ scalony.
icIdentifier jest identyfikatorem układu scalonego na karcie i producenta
układu scalonego zdefiniowanym w normie ISO/IEC 7816-6.
2.24. CardIdentification
Informacje zapisane na karcie dotyczące identyfikacji karty (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.
cardExpiryDate jest terminem ważności karty.
▼M3
2.24a. CardLoadTypeEntries
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub warsztatowej doty­
czące wpisów typu załadunku, gdy karta jest włożona do przyrządu
rejestrującego (wymogi 306j i 356j określone w załączniku IC).
loadTypeEntryPointerNewestRecord to indeks ostatniego uaktualnio­
nego rekordu karty dotyczącego wpisu typu załadunku.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordu
karty dotyczącego wpisu typu załadunku, rozpoczynając od „0” dla
pierwszego wystąpienia w strukturze rekordu karty dotyczącego wpisu
typu załadunku.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 134
cardLoadTypeEntryRecords to zbiór rekordów zawierających datę
i godzinę wpisu oraz wpisany typ załadunku.
2.24b. CardLoadTypeEntryRecord
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub warsztatowej doty­
czące wprowadzonych zmian typu załadunku, gdy karta jest włożona do
przyrządu rejestrującego (wymogi 306i i 356i określone w załączniku
IC).
timeStamp to data i godzina wpisania typu załadunku.
loadTypeEntered to wpisany typ załadunku.
2.24c. CardLoadUnloadOperations
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub warsztatowej doty­
czące operacji załadunku/rozładunku pojazdu (wymogi 306h i 356h
określone w załączniku IC).
loadUnloadPointerNewestRecord to indeks ostatniego uaktualnionego
rekordu karty dotyczącego załadunku/rozładunku.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordu
karty dotyczącego załadunku/rozładunku, rozpoczynając od „0” dla
pierwszego wystąpienia w strukturze rekordu karty dotyczącego zała­
dunku/rozładunku.
cardLoadUnloadRecords to zbiór rekordów zawierających wskazanie
typu wykonywanej operacji (załadunek, rozładunek lub równoczesny
załadunek/rozładunek), datę i godzinę wprowadzenia operacji załadunku/
rozładunku, informacje o pozycji pojazdu oraz stan licznika kilometrów.
2.24d. CardLoadUnloadRecord
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub warsztatowej doty­
czące operacji załadunku/rozładunku pojazdu (wymogi 306g i 356g
określone w załączniku IC).
timeStamp to data i godzina rozpoczęcia operacji załadunku/rozładunku.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 135
operationType to wpisany typ operacji (załadunek, rozładunek lub
równoczesny załadunek/rozładunek).
gnssPlaceAuthRecord zawiera informacje dotyczące pozycji pojazdu.
vehicleOdometerValue to stan licznika kilometrów w związku z rozpo­
częciem operacji załadunku/rozładunku.
▼B
2.25. CardMACertificate
Generacja 2:
Certyfikat klucza publicznego karty na potrzeby wzajemnego 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.
▼M3
2.26a. CardPlaceAuthDailyWorkPeriod
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsz­
tatowej, przedstawiające status uwierzytelnienia miejsc rozpoczęcia lub
zakończenia dziennych okresów pracy (wymogi 306b i 356b określone
w załączniku IC).
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 136
placeAuthPointerNewestRecord to indeks ostatniego uaktualnionego
rekordu dotyczącego statusu uwierzytelnienia miejsca.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordów
dotyczących statusu uwierzytelnienia miejsca, rozpoczynając od „0” dla
pierwszego wystąpienia w strukturze rekordów dotyczących statusu
uwierzytelnienia miejsca.
placeAuthStatusRecords to zbiór rekordów zawierających status uwie­
rzytelnienia miejsca dla wprowadzanych miejsc.
▼B
2.27. CardPlaceDailyWorkPeriod
Informacje przechowywane na karcie kierowcy lub na karcie warsz­
tatowej dotyczące miejsc rozpoczęcia lub zakończenia dziennych
okresów pracy (wymagania 272, 297, 325 i 348 określone w załą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.
2.28. CardPrivateKey
Generacja 1:
Klucz prywatny karty.
2.29. CardPublicKey
Klucz publiczny karty.
▼M1
2.30. CardRenewalIndex
Numer odnowienia karty (definicja i)).
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 137
Przypisanie wartości: (zob. rozdział 7 niniejszego załącznika).
„0” Wydanie pierwsze.
Kolejność zwiększania:„0, …, 9, A, …, Z”
▼B
2.31. CardReplacementIndex
Numer wymiany karty (definicja j)).
Przypisanie wartości: (zob. rozdział VII niniejszego załącznika).
„0” Oryginał karty.
Kolejność zwiększania: „0, …, 9, A, …, Z”
2.32. CardSignCertificate
Generacja 2:
Certyfikat klucza publicznego karty do podpisu. Strukturę tego certyfi­
katu określono w dodatku 11.
2.33. CardSlotNumber
Kod rozróżnienia między dwiema szczelinami kart w przyrządzie 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.
Przypisanie wartości – zapisane oktetami: „ccccdddd”B
„cccc”B identyfikacja typu karty włożonej do szczeliny karty
współkierowcy,
„dddd”B identyfikacja typu karty włożonej do szczeliny karty
kierowcy,
z następującymi kodami identyfikującymi:
„0000”B brak karty,
„0001”B karta kierowcy jest włożona,
„0010”B karta warsztatowa jest włożona,
„0011”B karta kontrolna jest włożona,
„0100”B karta firmowa jest włożona.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 138
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
▼M3
„bb”H indeks zmian dotyczących użycia elementów danych
zdefiniowanych dla struktury określony wyższym
bajtem.
„00”H dla aplikacji generacji 1
„00”H dla aplikacji wersji 1 generacji 2
„01”H dla aplikacji wersji 2 generacji 2
▼B
2.37. CardVehicleRecord
Informacje przechowywane na karcie kierowcy lub na karcie warsz­
tatowej dotyczące okresu używania pojazdu w czasie dnia kalendarzo­
wego (wymagania 269, 294, 322 i 345 określone w załączniku 1C).
Generacja 1:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 139
vehicleOdometerBegin jest stanem licznika kilometrów na początku
okresu używania pojazdu.
vehicleOdometerEnd jest stanem licznika kilometrów na końcu okresu
używania pojazdu.
vehicleFirstUse jest datą i godziną rozpoczęcia okresu używania
pojazdu.
vehicleLastUse jest datą i godziną zakończenia okresu używania
pojazdu.
vehicleRegistration wskazuje numer VRN i państwo członkowskie
rejestracji pojazdu.
vuDataBlockCounter jest wartością licznika VuDataBlockCounter
ostatniego wyciągu okresu użycia pojazdu.
Generacja 2:
Oprócz generacji 1 używany jest następujący element danych:
VehicleIdentificationNumber jest numerem identyfikacyjnym pojazdu
odnoszącym się do pojazdu jako całości.
2.38. CardVehiclesUsed
Informacje przechowywane na karcie kierowcy lub na karcie warsz­
tatowej dotyczące używanych pojazdów (wymagania 270, 295, 323
i 346 określone w załączniku 1C).
vehiclePointerNewestRecord jest indeksem ostatniego, uaktualnionego
rekordu dotyczącego pojazdu.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordów
dotyczących pojazdu, rozpoczynając od „0” dla pierwszego wystą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:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 140
informacje przechowywane na karcie kierowcy lub na karcie warsz­
tatowej dotyczące używanego przyrządu rejestrującego (wymagania
303 i 351 określone w załączniku 1C).
timeStamp jest początkiem okresu używania przyrządu rejestrującego
(tj. pierwszym włożeniem karty do przyrządu rejestrującego dla tego
okresu).
manufacturerCode identyfikuje producenta przyrządu rejestrującego.
deviceID identyfikuje typ przyrządu rejestrującego producenta. Wartość
jest swoista dla producenta.
vuSoftwareVersion jest numerem wersji oprogramowania przyrządu
rejestrującego.
2.40. CardVehicleUnitsUsed
▼M3
Generacja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsz­
tatowej dotyczące przyrządów rejestrujących używanych przez posia­
dacza karty (wymogi 304 i 352 określone w załączniku IC).
▼B
vehiclePointerNewestRecord jest indeksem ostatniego, uaktualnionego
rekordu dotyczącego przyrządu rejestrującego.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordów
przyrządu rejestrującego, rozpoczynając od „0” dla pierwszego 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:
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)
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 141
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 certyfikatu.
certificateEndOfValidity jest datą administracyjnego wygaśnięcia
certyfikatu.
certificateHolderReference identyfikuje posiadacza certyfikatu. Jest tu
także odesłanie do jego klucza publicznego.
publicKey jest kluczem publicznym, który jest poświadczony tym
certyfikatem.
2.43. CertificateHolderAuthorisation
Identyfikacja praw posiadacza certyfikatu.
Generacja 1:
tachographApplicationID jest identyfikatorem aplikacji dla aplikacji
tachograficznej.
Przypisanie wartości: „FFh” „54h” „41h” „43h” „48h” „4Fh”. Ten
AID jest zastrzeżonym, nierejestrowanym identyfikatorem 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 — 21.08.2023 — 003.002 — 142
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 certy­
fikat.
Przypisanie wartości: miesiąc (dwie cyfry) i rok (dwie ostatnie cyfry)
w kodzie BCD.
crIdentifier: jest identyfikatorem umożliwiającym rozróżnienie wniosku
o certyfikat od rozszerzonego numeru seryjnego.
Przypisanie wartości: „FFh”.
manufacturerCode: jest kodem numerycznym producenta wnioskują­
cego o certyfikat.
2.45. CertificationAuthorityKID
Identyfikator klucza publicznego organu certyfikacji (organu certyfikacji
państwa członkowskiego lub europejskiego organu certyfikacji).
nationNumeric jest numerycznym kodem krajowym organu certyfikacji.
nationAlpha jest alfanumerycznym kodem krajowym organu
certyfikacji.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 143
keySerialNumber jest numerem seryjnym umożliwiającym rozróżnienie
różnych kluczy organu certyfikacji w przypadku zmiany kluczy.
additionalInfo jest dwubajtowym polem przeznaczonym na dodatkowy
kod (swoisty dla organu certyfikacji).
caIdentifier jest identyfikatorem umożliwiającym rozróżnienie identyfi­
katora klucza organu certyfikacji od innych identyfikatorów 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.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 144
2.47. CompanyActivityType
Kod wskazujący czynność wykonaną przez firmę z wykorzystaniem jej
karty firmowej.
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.
▼M3
2.48a. CompanyCardApplicationIdentificationV2
Generacja 2, wersja 2:
Informacje przechowywane na karcie firmowej dotyczące identyfikacji
aplikacji na karcie (wymóg 375a określony w załączniku IC).
lengthOfFollowingData to liczba kolejnych bajtów we wpisie.
vuConfigurationLengthRange to liczba bajtów na karcie do tacho­
grafu, dostępnych na potrzeby przechowywania konfiguracji VU.
▼B
2.49. CompanyCardHolderIdentification
Informacje przechowywane na karcie firmowej dotyczące identyfikacji
posiadacza karty (wymagania 372 i 378 określone w załączniku 1C).
companyName jest nazwą firmy posiadającej kartę.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 145
companyAddress jest adresem firmy posiadającej kartę.
cardHolderPreferredLanguage jest preferowanym językiem posia­
dacza karty.
2.50. ControlCardApplicationIdentification
Informacje przechowywane na karcie kontrolnej dotyczące 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.
▼M3
2.50a. ControlCardApplicationIdentificationV2
Generacja 2, wersja 2:
Informacje przechowywane na karcie kontrolnej dotyczące identyfikacji
aplikacji karty (wymóg 363a określony w załączniku IC).
lengthOfFollowingData to liczba kolejnych bajtów we wpisie.
vuConfigurationLengthRange to liczba bajtów na karcie do tacho­
grafu, dostępnych na potrzeby przechowywania konfiguracji VU.
▼B
2.51. ControlCardControlActivityData
Informacje przechowywane na karcie kontrolnej dotyczące czynności
wykonanych przy użyciu karty (wymagania 361 i 367 określone
w załączniku 1C).
controlPointerNewestRecord jest indeksem ostatniego, uaktualnionego
rekordu czynności kontrolnych.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 146
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordów
czynności kontrolnych, rozpoczynając od „0” dla pierwszego wystą­
pienia w strukturze rekordu czynności kontroli.
controlActivityRecords jest zbiorem wszystkich rekordów czynności
kontrolnych.
controlActivityRecord jest ciągiem informacji dotyczących jednej
kontroli.
controlType jest typem kontroli.
controlTime jest datą i godziną kontroli.
controlledCardNumber jest numerem karty i państwa członkowskiego
wydającego kartę, która jest kontrolowana.
controlledVehicleRegistration jest numerem VRN i państwa członkow­
skiego rejestracji pojazdu, w którym miała miejsce kontrola.
controlDownloadPeriodBegin i controlDownloadPeriodEnd wyzna­
czają ostatecznie pobierany okres.
2.52. ControlCardHolderIdentification
Informacje przechowywane na karcie kontrolnej dotyczące 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.
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
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 147
„v”B pobieranie danych z VU:
„0”B: nie pobrano danych z VU w czasie tej kontroli,
„1”B: pobrano dane z VU w czasie tej kontroli
„p”B drukowanie:
„0”B: nie wykonano wydruków w czasie tej kontroli,
„1”B: wykonano wydruki w czasie tej kontroli
„d”B wyświetlacz:
„0”B: nie użyto wyświetlacza w czasie tej kontroli,
„1”B: użyto wyświetlacza w czasie tej kontroli
„xxxx”B Nieużywany.
Generacja 2:
Przypisanie wartości – zapisane oktetami: „cvpdexxx”B (8 bitów)
„c”B pobieranie danych z karty:
„0”B: nie pobrano danych z karty w czasie tej kontroli,
„1”B: pobrano dane z karty w czasie tej kontroli
„v”B pobieranie danych z VU:
„0”B: nie pobrano danych z VU w czasie tej kontroli,
„1”B: pobrano dane z VU w czasie tej kontroli
„p”B drukowanie:
„0”B: nie wykonano wydruków w czasie tej kontroli,
„1”B: wykonano wydruki w czasie tej kontroli
„d”B wyświetlacz:
„0”B: nie użyto wyświetlacza w czasie tej kontroli,
„1”B: użyto wyświetlacza w czasie tej kontroli
„e”B kontrola drogowa kalibracji
„0”B: parametry kalibracyjne nie zostały skontrolowane
w czasie tej kontroli,
„1”B: parametry kalibracyjne zostały skontrolowane
w czasie tej kontroli,
„xxx”B RFU.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 148
2.54. CurrentDateTime
Bieżąca data i godzina urządzenia rejestrującego.
Przypisanie wartości: nie określa się.
2.55. CurrentDateTimeRecordArray
Generacja 2:
Bieżąca data i godzina wraz z metadanymi stosowane w protokole
pobierania danych.
recordType oznacza typ rekordu (CurrentDateTime). Przypisanie
wartości: zob. RecordType
recordSize to wielkość CurrentDateTime w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów z bieżącego dnia i godziny.
2.56. DailyPresenceCounter
Licznik znajdujący się na karcie kierowcy lub na karcie 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.
2.57. Datef
Data wyrażona w czytelnym, przeznaczonym do druku formacie
numerycznym.
Przypisanie wartości:
yyyy rok
mm miesiąc
dd dzień
„00000000”H oznacza jednoznacznie brak daty.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 149
2.58. DateOfDayDownloaded
Generacja 2:
data i godzina pobrania danych;
Przypisanie wartości: nie określa się.
2.59. DateOfDayDownloadedRecordArray
Generacja 2:
Data i godzina pobrania danych wraz z metadanymi stosowane w 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.
▼M3
2.60a. DownloadInterfaceVersion
Generacja 2, wersja 2:
Kod wskazujący wersję interfejsu pobierania danych przyrządu rejestru­
jącego.
Przypisanie wartości: „aabb”H:
„aa”H „00”H: nieużywany,
„01”H: przyrząd rejestrujący generacji 2,
„bb”H „00”H: nieużywany,
„01”H: przyrząd rejestrujący wersji 2 generacji 2.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 150
2.61. DriverCardApplicationIdentification
Informacje przechowywane na karcie kierowcy dotyczące identyfikacji
aplikacji na karcie (wymagania 253 i 278 określone w załączniku 1C).
Generacja 1:
typeOfTachographCardId określa wdrożony typ karty.
cardStructureVersion określa wersję struktury wdrożonej na karcie.
noOfEventsPerType jest liczbą zdarzeń według typu zdarzenia możli­
wych do zarejestrowania na karcie.
noOfFaultsPerType jest liczbą usterek według typu usterki możliwych
do zarejestrowania na karcie.
activityStructureLength podaje liczbę bajtów dostępnych do przecho­
wywania rekordów czynności.
noOfCardVehicleRecords jest liczbą rekordów dotyczących pojazdów
możliwych do zarejestrowania na karcie.
noOfCardPlaceRecords jest liczbą miejsc możliwych do zarejestro­
wania na karcie.
Generacja 2:
▼M1
Oprócz generacji 1 używane są następujące elementy danych:
noOfGNSSADRecords jest liczbą rekordów skumulowanego czasu
prowadzenia pojazdu z GNSS, które mogą być zapisane na karcie.
noOfSpecificConditionRecords jest liczbą rekordów warunków szcze­
gólnych, które mogą być zapisane na karcie.
noOfCardVehicleUnitRecords jest liczbą rekordów używanych przy­
rządów rejestrujących, które mogą być zapisane na karcie.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 151
2.61a. DriverCardApplicationIdentificationV2
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy dotyczące identyfikacji
aplikacji karty (wymóg 278a określony w załączniku IC).
lengthOfFollowingData to liczba kolejnych bajtów we wpisie.
noOfBorderCrossingRecords to liczba rekordów dotyczących przekro­
czenia granicy, które mogą być przechowywane na karcie kierowcy.
noOfLoadUnloadRecords to liczba rekordów dotyczących załadunku/
rozładunku, które mogą być przechowywane na karcie kierowcy.
noOfLoadTypeEntryRecords to liczba rekordów dotyczących wpisu
typu załadunku, które mogą być przechowywane na karcie kierowcy.
vuConfigurationLengthRange to liczba bajtów na karcie do tacho­
grafu, dostępnych na potrzeby przechowywania konfiguracji VU.
▼B
2.62. DriverCardHolderIdentification
Informacje przechowywane na karcie kierowcy dotyczące 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.
cardHolderPreferredLanguage jest preferowanym językiem posia­
dacza karty.
▼M3
2.63. DSRCSecurityData
Generacja 2:
Definicja tego typu danych znajduje się w dodatku 11.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 152
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
producenta.
2.66. EntryTypeDailyWorkPeriod
Kod umożliwiający rozróżnienie między początkiem a końcem wpisu
dotyczącego dziennego okresu pracy oraz miejsca i sposobu wprowa­
dzenia wpisu.
Generacja 1
Przypisanie wartości: zgodnie z normą ISO/IEC8824-1.
▼M3
Generacja 2
Przypisanie wartości: zgodnie z normą ISO/IEC8824-1.
▼B
2.67. EquipmentType
Kod umożliwiający rozróżnienie typów urządzeń dla aplikacji
tachograficznej.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 153
Generacja 1:
Przypisanie wartości: zgodnie z normą ISO/IEC8824-1.
Wartość 0 jest zastrzeżona do celów oznaczenia państwa członkow­
skiego lub Europy w rubryce CHA certyfikatów.
Generacja 2:
▼M1
Takie same wartości jak w przypadku generacji 1 z następującymi
uzupełnieniami:
Uwaga 1: Wartości generacji 2 dla tabliczki, adaptera, połączenia
zewnętrznego GNSS, a także wartości generacji 1 dla przyrządu 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 — 21.08.2023 — 003.002 — 154
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 — 21.08.2023 — 003.002 — 155
usterki karty,
brak dalszych szczegółów,
RFU,
RFU,
swoisty dla producenta.
▼M3
Generacja 2, wersja 1:
▼M1
zdarzenia ogólne,
brak dalszych szczegółów,
włożenie nieważnej karty,
konflikt kart,
nakładające się czasy,
prowadzenie pojazdu bez prawidłowej karty,
włożenie karty podczas prowadzenia pojazdu,
sesja ostatniej karty niezamknięta prawidłowo,
przekroczenie prędkości,
przerwa w zasilaniu,
błąd danych dotyczących ruchu,
konflikt ruchu pojazdu,
konflikt czasowy (między GNSS a wewnętrznym zegarem VU),
błąd połączenia z urządzeniem do łączności na odległość,
brak informacji o pozycji z odbiornika GNSS,
błąd połączenia z urządzeniem zewnętrznym GNSS,
RFU,
zdarzenia związane z próbami naruszenia zabezpieczenia przyrzą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 — 21.08.2023 — 003.002 — 156
usterki urządzenia rejestrującego,
brak dalszych szczegółów,
usterka wewnętrzna VU,
usterka drukarki,
usterka wyświetlacza,
usterka pobierania danych,
usterka czujnika,
wewnętrzny odbiornik GNSS,
urządzenie zewnętrzne GNSS,
urządzenie do łączności na odległość,
interfejs ITS,
RFU,
usterki karty,
brak dalszych szczegółów,
RFU,
RFU,
swoisty dla producenta.
▼M3
Generacja 2, wersja 2:
„0x”H zdarzenia ogólne,
„00”H brak dalszych szczegółów,
„01”H włożenie nieważnej karty,
„02”H konflikt kart,
„03”H nakładające się czasy,
„04”H prowadzenie pojazdu bez prawidłowej karty,
„05”H włożenie karty podczas prowadzenia pojazdu,
„06”H sesja ostatniej karty niezamknięta prawidłowo,
„07”H przekroczenie prędkości,
„08”H przerwa w zasilaniu,
„09”H błąd danych dotyczących ruchu,
„0A”H konflikt ruchu pojazdu,
„0B”H konflikt czasowy (między GNSS a wewnętrznym
zegarem VU),
„0C”H błąd połączenia z urządzeniem do łączności na
odległość,
„0D”H brak informacji o pozycji z odbiornika GNSS,
„0E”H błąd połączenia z urządzeniem zewnętrznym
GNSS,
„0F”H anomalia GNSS,
„1x”H zdarzenia związane z próbami naruszenia zabez­
pieczenia przyrządu rejestrującego,
„10”H brak dalszych szczegółów,
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 157
„11”H błąd uwierzytelnienia czujnika ruchu,
„12”H błąd uwierzytelnienia karty do tachografu,
„13”H nieupoważniona zmiana w czujniku ruchu,
„14”H błąd integralności wprowadzania danych na kartę,
„15”H błąd integralności przechowywanych danych użyt­
kownika,
„16”H błąd wewnętrznego przesyłania danych,
„17”H nieupoważnione otwarcie obudowy,
„18”H uszkodzenie sprzętu,
„19”H wykrycie ingerencji w GNSS,
„1 A”H błąd uwierzytelnienia urządzenia zewnętrznego
GNSS,
„1 B”H wygaśnięcie certyfikatu urządzenia zewnętrznego
GNSS,
„1C”H niespójność między danymi dotyczącymi ruchu
a przechowywanymi danymi dotyczącymi czyn­
ności kierowcy,
„1D”H do „1F”H RFU,
„2x”H zdarzenia związane z próbami naruszenia zabez­
pieczenia czujnika,
„20”H brak dalszych szczegółów,
„21”H błąd uwierzytelnienia,
„22”H błąd integralności przechowywanych danych,
„23”H błąd wewnętrznego przesyłania danych,
„24”H nieupoważnione otwarcie obudowy,
„25”H uszkodzenie sprzętu,
„26”H do „2F”H RFU,
„3x”H usterki urządzenia rejestrującego,
„30”H brak dalszych szczegółów,
„31”H usterka wewnętrzna VU,
„32”H usterka drukarki,
„33”H usterka wyświetlacza,
„34”H usterka pobierania danych,
„35”H usterka czujnika,
„36”H wewnętrzny odbiornik GNSS,
„37”H urządzenie zewnętrzne GNSS,
„38”H urządzenie do łączności na odległość,
„39”H interfejs ITS,
„3 A”H usterka czujnika wewnętrznego,
„3B”H do „3F”H RFU,
„4x”H usterki karty,
„40”H brak dalszych szczegółów,
„41”H do „4F”H RFU,
„50”H do „7F”H RFU,
„80”H do „FF”H swoisty dla producenta.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 158
2.71. ExtendedSealIdentifier
Generacja 2:
Rozszerzony identyfikator plomby jednoznacznie identyfikuje plombę
(wymóg 401 określony w załączniku IC).
manufacturerCode to kod producenta plomby. Przypisanie wartości:
zob. rejestr bazy danych, którym zarządzać ma Komisja Europejska (zob.
https://dtc.jrc.ec.europa.eu).
sealIdentifier to identyfikator plomby, który jest niepowtarzalny dla
producenta. Przypisanie wartości: numer alfanumeryczny, niepowta­
rzalny w domenie producenta zgodnie z [ISO8859-1].
▼B
2.72. ExtendedSerialNumber
Unikalna identyfikacja urządzenia. Może być używana także jako iden­
tyfikator klucza publicznego urządzenia.
Generacja 1:
serialNumber jest numerem seryjnym urządzenia, niepowtarzalnym dla
producenta, typu urządzenia i miesiąca oraz roku, jak wyjaśniono
poniżej.
monthYear jest identyfikacją miesiąca i roku produkcji (lub przypi­
sanym numerem seryjnym).
Przypisanie wartości: miesiąc (dwie cyfry) i rok (dwie ostatnie cyfry)
w kodzie BCD.
type jest identyfikatorem typu urządzenia.
Przypisanie wartości: swoisty dla producenta, z wartością zastrzeżoną
„FFh”.
manufacturerCode: jest kodem numerycznym identyfikującym produ­
centa homologowanego urządzenia.
Generacja 2:
serialNumber, zob. generacja 1
monthYear, zob. generacja 1
type jest identyfikatorem typu urządzenia
manufacturerCode: zob. generacja 1.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 159
2.73. FullCardNumber
Kod całkowicie identyfikujący kartę do tachografu.
cardType jest typem karty do tachografu.
cardIssuingMemberState jest kodem państwa członkowskiego, które
wydało kartę.
cardNumber jest numerem karty.
2.74. FullCardNumberAndGeneration
Generacja 2:
Kod całkowicie identyfikujący kartę do tachografu i jej 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
2.76. GeoCoordinates
▼M3
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. Długość i szerokość geograficzną nieznanej pozycji przedstawia
się jako Hex „7FFFFF” (w zapisie dziesiętnym 8388607).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 160
latitude koduje się jako wielokrotność (mnożnik 10) zapisu
± DDMM.M.
longitude koduje się jako wielokrotność (mnożnik 10) zapisu
± DDMM.M.
2.77. GNSSAccuracy
Generacja 2:
Dokładność danych GNSS dotyczących położenia (definicja eee)). Taka
dokładność jest kodowana jako liczba całkowita i jest 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:
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.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 161
gnssPlaceRecord zawiera informacje dotyczące położenia pojazdu.
vehicleOdometerValue to wartość stanu licznika kilometrów, przy
której skumulowany czas prowadzenia pojazdu osiąga wielokrotność
trzech godzin.
▼M3
2.79a. GNSSAuthAccumulatedDriving
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej,
przedstawiające status uwierzytelnienia pozycji GNSS dla pojazdu, jeżeli
skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech
godzin (wymogi 306d i 356d określone w załączniku IC).
gnssAuthADPointerNewestRecord to indeks ostatniego uaktualnionego
rekordu dotyczącego statusu uwierzytelnienia pozycji GNSS.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordu
dotyczącego statusu uwierzytelnienia pozycji GNSS, rozpoczynając od
„0” dla pierwszego wystąpienia w strukturze rekordu dotyczącego statusu
uwierzytelnienia pozycji GNSS.
gnssAuthStatusADRecords to zbiór rekordów zawierających datę
i godzinę, kiedy skumulowany czas prowadzenia pojazdu osiąga wielo­
krotność trzech godzin, oraz status uwierzytelnienia pozycji GNSS.
2.79b. GNSSAuthStatusADRecord
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsz­
tatowej, przedstawiające status uwierzytelnienia pozycji pojazdu GNSS,
jeżeli skumulowany czas prowadzenia pojazdu osiągnie wielokrotność
trzech godzin (wymogi 306c i 356c określone w załączniku IC). Inne
informacje związane z samą pozycją GNSS są przechowywane w innym
rekordzie (zob. 2.79 GNSSAccumulatedDrivingRecord).
timeStamp to data i godzina, gdy skumulowany czas prowadzenia
pojazdu osiąga wielokrotność trzech godzin (która jest taka sama, jak
data i godzina w odpowiednim rekordzie GNSSAccumulatedDrivingRe­
cord),
authenticationStatus to status uwierzytelnienia pozycji GNSS, gdy
skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech
godzin.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 162
2.79c. GNSSPlaceAuthRecord
Generacja 2, wersja 2:
Informacje dotyczące pozycji GNSS dla pojazdu (wymogi 108, 109, 110,
296, 306a, 306c, 306e, 306g, 356a, 356c, 356e i 356g określone
w załączniku IC).
timeStamp to data i godzina określenia pozycji GNSS dla pojazdu.
gnssAccuracy to dokładność danych dotyczących pozycji GNSS.
geoCoordinates to lokalizacja zarejestrowana przy użyciu GNSS.
authenticationStatus to status uwierzytelnienia pozycji GNSS
w momencie jej określenia.
▼B
2.80. GNSSPlaceRecord
Generacja 2:
Informacje dotyczące położenia GNSS pojazdu (wymagania 108, 109,
110, 296, 305, 347 i 353 określone w załączniku 1C).
timeStamp jest datą i godziną określenia położenia GNSS pojazdu.
gnssAccuracy jest dokładnością danych dotyczących położenia GNSS.
geoCoordinates jest lokalizacją zapisaną przy użyciu GNSS.
2.81. HighResOdometer
Stan licznika kilometrów pojazdu: skumulowana odległość 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.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 163
2.83. HolderName
Nazwisko i imię (imiona) posiadacza karty.
holderSurname jest nazwiskiem posiadacza. Do nazwiska nie dodaje się
tytułów.
Przypisanie wartości: w przypadku kart nieosobowych, holderSurname
zawiera te same informacje, co companyName lub workshopName, lub
controlBodyName.
holderFirstNames oznacza imię (imiona) i inicjały posiadacza.
▼M3
2.84. Zarezerwowane dla przyszłego użytku
▼B
Generacja 2:
Informacje, czy odbiornik GNSS znajduje się wewnątrz czy na zewnątrz
przyrządu rejestrującego. Prawda – oznacza, że odbiornik GNSS znajduje
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 publicznego
przyrządu rejestrującego, karty do tachografu lub urządzenia zewnętrz­
nego 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:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 164
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.
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ę.
▼M3
2.89a. LengthOfFollowingData
Generacja 2, wersja 2:
Wskaźnik długości dla rozszerzalnych rekordów.
Przypisanie wartości: zob. dodatek 2.
▼B
2.90. LinkCertificate
Generacja 2:
Certyfikat połączenia par kluczy Głównego Europejskiego Organu Certy­
fikacji.
▼M3
2.90a. LoadType
Generacja 2, wersja 2:
Kod identyfikujący wpisany typ załadunku.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 165
Przypisanie wartości:
„00”H nieokreślony typ załadunku,
„01”H towary,
„02”H pasażerowie,
„03”H .. „FF”H RFU.
▼B
2.91. L-TyreCircumference
Obwód toczny opon (definicja u)).
Przypisanie wartości: liczba binarna bez znaku, wyrażona w 1/8 mm
w zakresie operacyjnym 0 do 8 031 mm.
▼M1
2.92. MAC
Generacja 2:
Kryptograficzna suma kontrolna o długości 8, 12 lub 16 bajtów 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.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 166
2.95. ManufacturerSpecificEventFaultData
Generacja 2:
Swoiste dla producentów kody błędów upraszczają analizę błędów oraz
konserwację przyrządów rejestrujących.
manufacturerCode identyfikuje producenta przyrządu rejestrującego.
manufacturerSpecificErrorCode jest kodem błędu swoistym dla
producenta.
2.96. MemberStateCertificate
Certyfikat klucza publicznego państwa członkowskiego wydany 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.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 167
2.99. Name
Nazwa (nazwisko).
codePage określa zestaw znaków zdefiniowany w rozdziale 4,
name jest nazwą zakodowaną przy użyciu wyszczególnionego zestawu
znaków.
2.100. NationAlpha
Alfabetyczne określenie państwa musi być zgodne ze znakami wyróż­
niającymi stosowanymi na pojazdach w ruchu międzynarodowym
(Konwencja wiedeńska Narodów Zjednoczonych o ruchu drogowym
z 1968 r.).
Kody Nation Alpha i Numeric znajdują się na wykazie 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 rejestru­
jących tachografów cyfrowych i inteligentnych posiadających homolo­
gację typu.
▼M3
2.101a. NoOfBorderCrossingRecords
Generacja 2, wersja 2:
Liczba rekordów dotyczących przekroczenia granicy, które mogą być
przechowywane na karcie kierowcy lub na karcie warsztatowej.
Przypisanie wartości: zob. dodatek 2.
▼B
2.102. NoOfCalibrationRecords
Liczba rekordów kalibracyjnych, możliwych do przechowywania na
karcie.
Generacja 1:
Przypisanie wartości: zob. dodatek 2.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 168
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.
2.105. NoOfCardVehicleRecords
Liczba rekordów dotyczących użytych pojazdów, możliwych do przecho­
wywania na karcie kierowcy lub na karcie warsztatowej.
Przypisanie wartości: zob. dodatek 2.
2.106. NoOfCardVehicleUnitRecords
Generacja 2:
Liczba rekordów dotyczących przyrządów rejestrujących, moż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.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 169
2.108. NoOfControlActivityRecords
Liczba rekordów dotyczących czynności kontrolnych, możliwych do
przechowywania na karcie kontrolnej.
Przypisanie wartości: zob. dodatek 2.
2.109. NoOfEventsPerType
Liczba zdarzeń według typu, możliwych do przechowywania na 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.
▼M1
2.111. NoOfGNSSADRecords
Generacja 2:
Liczba rekordów skumulowanego czasu prowadzenia pojazdu z GNSS,
które mogą być przechowywane na karcie.
Przypisanie wartości: zob. dodatek 2.
▼M3
2.111a. NoOfLoadUnloadRecords
Generacja 2, wersja 2:
Liczba rekordów dotyczących załadunku/rozładunku, które mogą być
przechowywane na karcie.
Przypisanie wartości: zob. dodatek 2.
▼B
2.112. NoOfSpecificConditionRecords
Generacja 2:
Liczba rekordów warunków szczególnych, które mogą być przechowy­
wane na karcie.
Przypisanie wartości: zob. dodatek 2.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 170
2.112a. NoOfLoadTypeEntryRecords
Generacja 2, wersja 2:
Liczba rekordów dotyczących typu załadunku, które mogą być przecho­
wywane na karcie kierowcy lub na karcie warsztatowej.
Przypisanie wartości: zob. dodatek 2.
▼B
2.113. OdometerShort,
Stan licznika kilometrów pojazdu w skróconej postaci.
Przypisanie wartości: liczba binarna bez znaku. Wartość w km
w zakresie operacyjnym 0 do 9 999 999 km.
2.114. OdometerValueMidnight
Stan licznika kilometrów o północy w danym dniu (wymaganie 090
określone w załączniku 1B i wymaganie 113 określone w załącz­
niku 1C).
Przypisanie wartości: nie określa się.
▼M3
2.114a. OperationType
Generacja 2, wersja 2:
Kod identyfikujący wpisany typ operacji.
Przypisanie wartości:
„00”H RFU,
„01”H operacja załadunku,
„02”H operacja rozładunku,
„03”H operacja równoczesnego załadunku/rozładunku,
„04”H .. „FF”H RFU.
▼B
2.115. OdometerValueMidnightRecordArray
Generacja 2:
OdometerValueMidnight wraz z metadanymi stosowany w protokole
pobierania danych.
recordType oznacza typ rekordu (OdometerValueMidnight). Przypi­
sanie wartości: zob. RecordType
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 171
recordSize to wielkość OdometerValueMidnight w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów OdometerValueMidnight.
2.116. OverspeedNumber
Liczba zdarzeń przekroczenia prędkości od ostatniej kontroli 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.
▼M3
2.116a. PlaceAuthRecord
Informacje dotyczące miejsca rozpoczęcia lub zakończenia dziennego okresu
pracy (wymogi 108, 271, 296, 324 i 347 określone w załączniku IC).
Generacja 2, wersja 2:
entryTime to data i godziną wpisu.
entryTypeDailyWorkPeriod to typ wpisu.
dailyWorkPeriodCountry to wpisany kraj.
dailyWorkPeriodRegion to wpisany region.
vehicleOdometerValue to stan licznika kilometrów w momencie wpisy­
wania miejsca.
entryGNSSPlaceAuthRecord to zarejestrowana lokalizacja, status uwie­
rzytelnienia GNSS oraz godzina.
2.116b. PlaceAuthStatusRecord
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsz­
tatowej, przedstawiające status uwierzytelnienia miejsca rozpoczęcia
lub zakończenia dziennych okresów pracy (wymogi 306a i 356a okre­
ślone w załączniku IC). Inne informacje związane z samym miejscem są
przechowywane w innym rekordzie (zob. 2.117 PlaceRecord).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 172
entryTime to data i godzina związana z wpisem (która jest taką samą
datą i godziną, jak w odpowiednim rekordzie PlaceRecord).
authenticationStatus to status uwierzytelnienia zarejestrowanej pozycji
GNSS.
▼B
2.117. PlaceRecord
Informacje dotyczące miejsca rozpoczęcia lub zakończenia 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ą.
▼M3
2.117a. PositionAuthenticationStatus
Generacja 2, wersja 2:
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 173
Przypisanie wartości (zob. dodatek 12):
„00”H nieuwierzytelniona (zob. dodatek 12, wymóg
GNS_39),
„01”H uwierzytelniona (zob. dodatek 12, wymóg GNS_39),
„02”H. „FF”H RFU.
▼B
2.118. PreviousVehicleInfo
Informacje dotyczące pojazdu poprzednio używanego przez kierowcę
w chwili wkładania jego karty do przyrządu rejestrującego (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.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 174
Przypisanie wartości:
► (1) M1
► (2) M3
ActivityChangeInfo,
CardSlotsStatus,
CurrentDateTime,
MemberStateCertificate,
OdometerValueMidnight,
DateOfDayDownloaded,
SensorPaired,
Signature,
SpecificConditionRecord,
VehicleIdentificationNumber,
VehicleRegistrationNumber,
VuCalibrationRecord,
VuCardIWRecord,
VuCardRecord,
VuCertificate,
VuCompanyLocksRecord,
VuControlActivityRecord,
VuDetailedSpeedBlock,
VuDownloadablePeriod,
VuDownloadActivityData,
VuEventRecord,
►M1 VuGNSSADRecord, ◄
VuITSConsentRecord,
VuFaultRecord,
VuIdentification,
VuOverSpeedingControlData,
VuOverSpeedingEventRecord,
VuPlaceDailyWorkPeriodRecord,
VuTimeAdjustmentGNSSRecord,
VuTimeAdjustmentRecord,
VuPowerSupplyInterruptionRecord,
SensorPairedRecord,
SensorExternalGNSSCoupledRecord,
►M3 VuBorderCrossingRecord,
VuLoadUnloadRecord,
VehicleRegistrationIdentification,
RFU, ◄
swoisty dla producenta.
2.121. RegionAlpha
Alfabetyczne odniesienie do regionu w określonym kraju.
Generacja 1:
Przypisanie wartości:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 175
Generacja 2:
Kody RegionAlpha znajdują się na wykazie utrzymywanym na stronie
internetowej laboratorium wyznaczonego do przeprowadzenia badań inte­
roperacyjności.
2.122. RegionNumeric
Numeryczne odniesienie do regionu w określonym państwie.
Generacja 1:
Przypisanie wartości:
Generacja 2:
Kody RegionNumeric znajdują się na wykazie utrzymywanym na stronie
internetowej laboratorium wyznaczonego do przeprowadzenia badań inte­
roperacyjności.
2.123. RemoteCommunicationModuleSerialNumber
Generacja 2:
Numer seryjny modułu komunikacji na odległość.
2.124. RSAKeyModulus
Generacja 1:
Moduł pary kluczy RSA.
Przypisanie wartości: nieokreślona.
2.125. RSAKeyPrivateExponent
Generacja 1:
Wykładnik prywatny pary kluczy RSA.
Przypisanie wartości: nieokreślona.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 176
2.126. RSAKeyPublicExponent
Generacja1:
Wykładnik publiczny pary kluczy RSA.
Przypisanie wartości: nieokreślona.
2.127. RtmData
Generacja2:
Definicja tego typu danych znajduje się w dodatku 14.
2.128. SealDataCard
Generacja 2:
W tym typie danych przechowuje się informacje o plombach przymoco­
wanych do różnych części pojazdu i jest on przeznaczony do przecho­
wywania 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 przymoco­
wanych do różnych części pojazdu i jest on przeznaczony do przecho­
wywania w przyrządzie rejestrującym.
sealRecords jest zbiorem rekordów dotyczących plomb. W przypadku
gdy dostępnych jest mniej niż 5 plomb wartość EquipmentType we
wszystkich niewykorzystanych sealRecords należy ustawić na 16, tj.
niewykorzystane.
2.130. SealRecord
Generacja 2:
W tym typie danych przechowuje się informacje o plombie 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 — 21.08.2023 — 003.002 — 177
2.131. SensorApprovalNumber
Numer homologacji typu czujnika.
Generacja 1:
Przypisanie wartości: nieokreślona.
Generacja 2:
Przypisanie wartości:
Należy podawać numer homologacji, który został opublikowany na
odpowiedniej stronie internetowej Komisji Europejskiej, tj. na przykład
z uwzględnieniem myślników, jeżeli występują. Numer homologacji
musi być wyrównany do lewej strony.
2.132. SensorExternalGNSSApprovalNumber
Generacja 2:
Numer homologacji urządzenia zewnętrznego GNSS.
Przypisanie wartości:
Należy podawać numer homologacji, który został opublikowany na
odpowiedniej stronie internetowej Komisji Europejskiej, tj. na przykład
z uwzględnieniem myślników, jeżeli występują. Numer homologacji
musi być wyrównany do lewej strony.
2.133. SensorExternalGNSSCoupledRecord
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące iden­
tyfikacji urządzenia zewnętrznego GNSS powiązanego z przyrządem
rejestrującym (wymaganie 100 określone w załączniku 1C).
sensorSerialNumber jest numerem seryjnym urządzenia zewnętrznego
GNSS powiązanego z przyrządem rejestrującym.
sensorApprovalNumber jest numerem homologacji tego urządzenia
zewnętrznego GNSS.
sensorCouplingDate jest datą powiązania tego urządzenia zewnętrznego
GNSS z przyrządem rejestrującym.
2.134. SensorExternalGNSSIdentification
Generacja 2:
Informacje dotyczące identyfikacji urządzenia zewnętrznego GNSS
(wymaganie 98 określone w załączniku 1C).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 178
sensorSerialNumber jest rozszerzonym numerem seryjnym urządzenia
zewnętrznego GNSS.
sensorApprovalNumber jest numerem homologacji urządzenia
zewnętrznego GNSS.
sensorSCIdentifier jest identyfikatorem elementu zabezpieczenia urzą­
dzenia zewnętrznego GNSS.
sensorOSIdentifier jest identyfikatorem systemu operacyjnego urzą­
dzenia zewnętrznego GNSS.
2.135. SensorExternalGNSSInstallation
Generacja 2:
Informacje, przechowywane w urządzeniu zewnętrznym GNSS, doty­
czące instalacji urządzenia zewnętrznego GNSS (wymaganie 123 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 — 21.08.2023 — 003.002 — 179
2.136. SensorExternalGNSSOSIdentifier
Generacja 2:
Identyfikator systemu operacyjnego urządzenia zewnętrznego GNSS.
Przypisanie wartości: swoisty dla producenta.
2.137. SensorExternalGNSSSCIdentifier
Generacja 2:
Ten typ jest stosowany np. w celu zidentyfikowania 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 — 21.08.2023 — 003.002 — 180
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 — 21.08.2023 — 003.002 — 181
2.143. SensorOSIdentifier
Identyfikator systemu operacyjnego czujnika ruchu.
Przypisanie wartości: swoisty dla producenta.
2.144. SensorPaired
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące iden­
tyfikacji czujnika ruchu sparowanego z przyrządem rejestrującym
(wymaganie 079 określone w załączniku 1B).
sensorSerialNumber jest numerem seryjnym czujnika ruchu obecnie
sparowanego z przyrządem rejestrującym.
sensorApprovalNumber jest numerem homologacji czujnika ruchu
obecnie sparowanego z przyrządem rejestrującym.
sensorPairingDateFirst jest datą pierwszego sparowania z przyrządem
rejestrującym czujnika ruchu obecnie sparowanego z przyrządem 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 — 21.08.2023 — 003.002 — 182
2.147. SensorSCIdentifier
Identyfikator elementu zabezpieczenia czujnika ruchu.
Przypisanie wartości: element swoisty dla producenta.
2.148. SensorSerialNumber
Numer seryjny czujnika ruchu.
2.149. Podpis
Podpis cyfrowy.
Generacja 1:
Przypisanie wartości: zgodnie z dodatkiem 11 – Wspólne mechanizmy
zabezpieczenia.
Generacja 2:
Przypisanie wartości: zgodnie z dodatkiem 11 – Wspólne mechanizmy
zabezpieczenia.
2.150. SignatureRecordArray
Generacja 2:
Zbiór podpisów wraz z metadanymi stosowany w protokole 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
oznacza, że 2 zdarzenia wystąpiły w tym dniu (zapamiętane jest tylko
jedno),... 255 oznacza, że 255 lub więcej zdarzeń wystąpiło w tym dniu.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 183
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 szczegó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 — 21.08.2023 — 003.002 — 184
2.155. Prędkość
Prędkość pojazdu (km/h).
Przypisanie wartości: kilometry na godzinę w zakresie operacyjnym 0
do 220 km/h.
2.156. SpeedAuthorised
Maksymalne dozwolone prędkości pojazdu (definicja hh)).
2.157. SpeedAverage
Prędkość średnia w uprzednio zdefiniowanym przedziale czasu (km/h).
2.158. SpeedMax
Prędkość maksymalna zmierzona w uprzednio zdefiniowanym przedziale
czasu.
▼M3
2.158a. TachographCardsGen1Suppression
Generacja 2, wersja 2:
Zdolność drugiej generacji VU do używania pierwszej generacji kart
kierowcy, kontrolnej i firmowej (zob. dodatek 15, MIG_002).
Przypisanie wartości:
„0000”H przyrząd rejestrujący jest w stanie używać kart do
tachografów generacji 1 (wartość domyślna),
„A5E3”H przyrząd rejestrujący nie jest w stanie używać
kart do tachografów generacji 1,
Wszelkie inne wartości
nieużywany.
▼B
2.159. TachographPayload
Generacja 2:
Definicja tego typu danych znajduje się w dodatku 14.
▼M1
2.160. Zarezerwowany dla przyszłego użytku
▼B
2.161. TDesSessionKey
Generacja 1:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 185
Klucz sesyjny T-DES.
Przypisanie wartości: nie określa się.
▼M1
2.162. TimeReal
Kod w polu zawierającym łącznie datę i godzinę, gdzie data i 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.
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.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 186
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem numerów identyfikacyjnych pojazdu.
2.166. VehicleRegistrationIdentification
Identyfikacja pojazdu, unikalna dla Europy (VRN i państwo członkow­
skie).
vehicleRegistrationNation jest państwem, w którym pojazd jest
zarejestrowany.
vehicleRegistrationNumber jest numerem rejestracyjnym
pojazdu (VRN).
▼M3
2.166a. VehicleRegistrationIdentificationRecordArray
Generacja 2, wersja 2:
Identyfikacja rejestracyjna pojazdu wraz z metadanymi stosowana
w protokole pobierania danych.
recordType oznacza typ rekordu (VehicleRegistrationIdentification).
Przypisanie wartości: zob. RecordType.
recordSize to wielkość VehicleRegistrationIdentification w bajtach.
noOfRecords to liczba rekordów w zbiorze.
records to zbiór identyfikacji rejestracyjnej pojazdu.
▼B
2.167. VehicleRegistrationNumber
Numer rejestracyjny pojazdu (VRN). Numer rejestracyjny przydziela
organ rejestracji pojazdów.
codePage określa zestaw znaków zdefiniowany w rozdziale 4,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 187
vehicleRegNumber jest numerem VRN zakodowanym przy użyciu
wyszczególnionego zestawu znaków.
Przypisanie wartości: swoisty dla kraju.
2.168. VehicleRegistrationNumberRecordArray
▼M3
Generacja 2, wersja 1:
▼B
Numer rejestracyjny pojazdu wraz z metadanymi stosowany w 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:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 188
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.
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:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 189
Przypisanie wartości: nieokreślona.
Generacja 2:
Przypisanie wartości:
Należy podawać numer homologacji, który został opublikowany na
odpowiedniej stronie internetowej Komisji Europejskiej, tj. na przykład
z uwzględnieniem myślników, jeżeli występują. Numer homologacji
musi być wyrównany do lewej strony.
2.173. VuCalibrationData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
kalibracji urządzenia rejestrującego (wymaganie 098 określone w załącz­
niku 1B).
noOfVuCalibrationRecords jest liczbą rekordów w zbiorze vuCalibra­
tionRecords.
vuCalibrationRecords jest zbiorem rekordów kalibracyjnych.
2.174. VuCalibrationRecord
Informacje przechowywane w przyrządzie rejestrującym dotyczące
kalibracji urządzenia rejestrującego (wymaganie 098 określone w załącz­
niku 1B i wymaganie 119 i 120 określone w załączniku 1C).
Generacja 1:
calibrationPurpose jest celem kalibracji.
workshopName, workshopAddress są nazwą i adresem warsztatu.
workshopCardNumber identyfikuje kartę warsztatową używaną przy
kalibracji.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 190
workshopCardExpiryDate jest terminem ważności karty.
vehicleIdentificationNumber jest numerem VIN.
vehicleRegistrationIdentification zawiera numer VRN i państwa człon­
kowskiego rejestracji.
wVehicleCharacteristicConstant jest współczynnikiem charaktery­
stycznym pojazdu.
kConstantOfRecordingEquipment jest stałą urządzenia rejestrującego.
lTyreCircumference jest obwodem tocznym kół.
tyreSize jest oznaczeniem rozmiaru opon zamontowanych w pojeździe.
authorisedSpeed jest dozwoloną prędkością pojazdu.
oldOdometerValue, newOdometerValue są starym i nowym stanem
licznika kilometrów.
oldTimeValue, newTimeValue są starą i nową wartością daty
i godziny.
nextCalibrationDate jest datą następnej kalibracji typu określonego
w CalibrationPurpose, którą powinien przeprowadzić autoryzowany
organ kontrolny.
▼M3
Generacja 2, wersja 1:
▼B
Oprócz generacji 1 używany jest następujący element danych:
sealDataVu podaje informacje o plombach przymocowanych do
różnych części pojazdu.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 191
Generacja 2, wersja 2:
Oprócz generacji 1 używany jest następujący element danych:
sensorSerialNumber to numer seryjny czujnika ruchu sparowanego
z przyrządem rejestrującym na końcu kalibracji,
sensorGNSSSerialNumber to numer seryjny urządzenia zewnętrznego
GNSS powiązanego z przyrządem rejestrującym na końcu kalibracji
(jeżeli dotyczy),
rcmSerialNumber to numer seryjny urządzenia do łączności na odle­
głość powiązanego z przyrządem rejestrującym na końcu kalibracji
(jeżeli dotyczy),
sealDataVu podaje informacje o plombach przymocowanych do
różnych części pojazdu.
byDefaultLoadType to domyślny typ załadunku pojazdu (element
obecny tylko w wersji 2).
calibrationCountry to kraj, w którym wykonano kalibrację.
calibrationCountryTimestamp to data i godzina przekazania przez
odbiornik GNSS pozycji wykorzystanej do określenia kraju, w którym
wykonano kalibrację.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 192
2.175. VuCalibrationRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
kalibracji urządzenia rejestrującego (wymagania 119 i 120 określone
w załączniku 1C).
recordType oznacza typ rekordu (VuCalibrationRecord). Przypisanie
wartości: zob. RecordType
recordSize to wielkość VuCalibrationRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów kalibracji.
2.176. VuCardIWData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące cykli
wkładania i wyjmowania kart dla kart kierowcy lub kart 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:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 193
cardHolderName jest nazwiskiem i imionami posiadacza karty
kierowcy lub karty warsztatowej zapisanymi na karcie.
fullCardNumber jest typem karty, państwem członkowskim wydającym
kartę i numerem karty zapisanymi na karcie.
cardExpiryDate jest terminem ważności karty zapisanym na karcie.
cardInsertionTime jest datą i godziną włożenia karty.
vehicleOdometerValueAtInsertion jest stanem licznika kilometrów
przy wkładaniu karty.
cardSlotNumber jest szczeliną czytnika, do której karta jest włożona.
cardWithdrawalTime jest datą i godziną wyjęcia karty.
vehicleOdometerValueAtWithdrawal jest stanem licznika kilometrów
przy wyjęciu karty.
previousVehicleInfo zawiera informacje o pojeździe poprzednio
używanym przez kierowcę, zapisane na karcie.
manualInputFlag jest flagą pokazującą, czy posiadacz karty przy wkła­
daniu karty wprowadził ręcznie czynności kierowcy.
Generacja 2:
Zamiast fullCardNumber w strukturze danych generacji 2 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:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 194
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.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów dotyczących cykli wkładania i wyjmo­
wania kart.
▼M1
2.179. VuCardRecord
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
używanej karty do tachografu (wymaganie 132 określone w załą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).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 195
recordType oznacza typ rekordu (VuCardRecord). Przypisanie
wartości: zob. RecordType
recordSize to wielkość VuCardRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów dotyczących kart do tachografów używa­
nych w VU.
2.181. VuCertificate
Certyfikat klucza publicznego przyrządu rejestrującego.
2.182. VuCertificateRecordArray
Generacja 2:
Certyfikat VU wraz z metadanymi stosowany w protokole 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.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 196
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:
lockInTime, lockOutTime są datą i godziną założenia i zdjęcia
blokady.
companyName, companyAddress są nazwą i adresem firmy związanej
z założeniem blokady.
companyCardNumber identyfikuje kartę użytą przy założeniu blokady.
Generacja 2:
Zamiast companyCardNumber w strukturze danych generacji 2 wyko­
rzystuje się następujący element danych.
companyCardNumberAndGeneration identyfikuje kartę, w tym jej
generację, użytą przy założeniu blokady.
2.185. VuCompanyLocksRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
blokad firmowych (wymaganie 128 określone w załączniku 1C).
recordType oznacza typ rekordu (VuCompanyLocksRecord). Przypi­
sanie wartości: zob. RecordType
recordSize to wielkość VuCompanyLocksRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze. Wartość 0..255.
records jest zbiorem rekordów blokad firmowych.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 197
2.185a. VuConfigurationLengthRange
Generacja 2, wersja 2:
Liczba bajtów na karcie do tachografu, dostępnych na potrzeby przecho­
wywania konfiguracji VU.
Przypisanie wartości: zob. dodatek 2.
▼B
2.186. VuControlActivityData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym, dotyczące
kontroli przeprowadzonych przy użyciu tego VU (wymaganie 102 okre­
ślone w załączniku 1B).
noOfControls jest liczbą kontroli wyszczególnionych w vuControlActi­
vityRecords.
vuControlActivityRecords jest zbiorem rekordów czynności
kontrolnych.
2.187. VuControlActivityRecord
Informacje przechowywane w przyrządzie rejestrującym dotyczące
kontroli wykonanej przy użycie tego VU (wymaganie 102 określone
w załączniku 1B i wymaganie 126 określone w załączniku 1C).
Generacja 1:
controlType jest typem kontroli.
controlTime jest datą i godziną kontroli.
controlCardNumber identyfikuje kartę kontrolną użytą przy kontroli.
downloadPeriodBeginTime jest czasem rozpoczęcia okresu, dla którego
pobrano dane, w przypadku pobierania danych.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 198
downloadPeriodEndTime jest czasem zakończenia okresu, dla którego
pobrano dane, w przypadku pobierania danych.
Generacja 2:
Zamiast controlCardNumber w strukturze danych generacji 2 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).
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).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 199
speedBlockBeginDate jest datą i godziną pierwszego odczytu prędkości
w bloku.
speedsPerSecond jest chronologicznym ciągiem prędkości mierzonych
co sekundę w ciągu minuty rozpoczynającej się od godziny okreś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
recordSize to wielkość VuDetailedSpeedBlock w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem bloków szczegółowej prędkości.
2.192. VuDetailedSpeedData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
szczegółowej prędkości pojazdu.
noOfSpeedBlocks jest liczbą bloków zarejestrowanych prędkości
w zbiorze vuDetailedSpeedBlocks.
vuDetailedSpeedBlocks jest zbiorem bloków szczegółowej prędkości.
▼M3
2.192a. VuDigitalMapVersion
Generacja 2, wersja 2:
Wersja mapy cyfrowej przechowywanej w przyrządzie rejestrującym
(wymóg 133j określony w załączniku IC).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 200
Przypisanie wartości: jak określono na specjalnej zabezpieczonej
stronie internetowej udostępnionej przez Komisję Europejską (wymóg
133k określony w załączniku IC).
▼B
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
recordSize to wielkość VuDownloadablePeriod w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów VuDownloadablePeriod.
2.195. VuDownloadActivityData
Informacje przechowywane w przyrządzie rejestrującym dotyczące ostat­
niego pobrania danych (wymaganie 105 określone w załączniku 1B
i wymaganie 129 określone w załączniku 1C).
Generacja 1:
downloadingTime jest datą i godziną pobierania danych.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 201
fullCardNumber identyfikuje kartę użytą do autoryzowania pobierania
danych.
companyOrWorkshopName jest nazwą firmy lub warsztatu.
Generacja 2:
Zamiast fullCardNumber w strukturze danych generacji 2 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.
records jest zbiorem rekordów czynności pobierania danych.
2.197. VuEventData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym, dotyczące
zdarzeń (wymaganie 094 określone w załączniku 1B z wyłączeniem
przekroczenia prędkości).
noOfVuEvents jest liczbą zdarzeń wyszczególnionych w zbiorze
vuEventRecords.
vuEventRecords jest zbiorem rekordów dotyczących zdarzeń.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 202
2.198. VuEventRecord
Informacje przechowywane w przyrządzie rejestrującym, dotyczące
zdarzenia (wymaganie 094 określone w załączniku 1B i wymaganie
117 określone w załączniku 1C z wyłączeniem przekroczenia prędkości).
Generacja 1:
eventType jest typem zdarzenia.
eventRecordPurpose jest celem, dla którego zarejestrowano to
zdarzenie.
eventBeginTime jest datą i godziną rozpoczęcia zdarzenia.
eventEndTime jest datą i godziną zakończenia zdarzenia.
cardNumberDriverSlotBegin identyfikuje kartę włożoną do szczeliny
karty kierowcy na początku zdarzenia.
cardNumberCodriverSlotBegin identyfikuje kartę włożoną do szcze­
liny karty współkierowcy na początku zdarzenia.
cardNumberDriverSlotEnd identyfikuje kartę włożoną do szczeliny
karty kierowcy na końcu zdarzenia.
cardNumberCodriverSlotEnd identyfikuje kartę włożoną do szczeliny
karty współkierowcy na końcu zdarzenia.
similarEventsNumber jest liczbą podobnych zdarzeń w tym dniu.
Sekwencji tej można używać dla wszystkich zdarzeń innych niż prze­
kroczenie prędkości.
Generacja 2:
Oprócz generacji 1 używane są następujące elementy danych:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 203
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
zdarzenia.
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
recordSize to wielkość VuEventRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów dotyczących zdarzeń.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 204
2.200. VuFaultData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
usterek (wymaganie 096 określone w załączniku 1B).
noOfVuFaults jest liczbą usterek wyszczególnionych w zbiorze vuFaul­
tRecords.
vuFaultRecords jest zbiorem rekordów dotyczących usterek.
2.201. VuFaultRecord
Informacje przechowywane w przyrządzie rejestrującym dotyczące
jednej usterki (wymaganie 096 określone w załączniku 1B i 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
zarejestrowana.
faultBeginTime jest datą i godziną początku usterki.
faultEndTime jest datą i godziną zakończenia usterki.
cardNumberDriverSlotBegin identyfikuje kartę włożoną do szczeliny
karty kierowcy na początku usterki.
cardNumberCodriverSlotBegin identyfikuje kartę włożoną do szcze­
liny karty współkierowcy na początku usterki.
cardNumberDriverSlotEnd identyfikuje kartę włożoną do szczeliny
karty kierowcy na końcu usterki.
cardNumberCodriverSlotEnd identyfikuje kartę włożoną do szczeliny
karty współkierowcy na końcu usterki.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 205
Generacja 2:
Oprócz generacji 1 używany jest następujący element danych:
manufacturerSpecificEventFaultData zawiera dodatkowe, szczegó­
łowe informacje o usterce odnoszące się do danego producenta.
Zamiast cardNumberDriverSlotBegin, cardNumberCodriverSlotBegin,
cardNumberDriverSlotEnd i cardNumberCodriverSlotEnd w 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 — 21.08.2023 — 003.002 — 206
2.203. VuGNSSADRecord
▼M3
Generacja 2, wersja 1:
▼M1
Informacje przechowywane w przyrządzie rejestrującym dotyczące poło­
żenia pojazdu z GNSS, jeżeli skumulowany czas prowadzenia 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 gene­
rację, włożoną do szczeliny karty kierowcy.
cardNumberAndGenCodriverSlot identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny karty współkierowcy.
gnssPlaceRecord zawiera informacje dotyczące położenia pojazdu.
vehicleOdometerValue to wartość stanu licznika kilometrów, przy
której skumulowany czas prowadzenia pojazdu osiąga wielokrotność
trzech godzin.
▼M3
Generacja 2, wersja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
pozycji GNSS dla pojazdu, jeżeli skumulowany czas prowadzenia
pojazdu osiągnie wielokrotność trzech godzin (wymogi 108 i 110 okre­
ślone w załączniku IC).
W wersji 2 generacji 2 zamiast gnssPlaceRecord stosuje się rekord
gnssPlaceAuthRecord, który zawiera dodatkowo status uwierzytelnienia
GNSS.
2.203a. VuBorderCrossingRecord
Generacja 2, wersja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące prze­
kroczeń granicy przez pojazd, jeżeli przekroczył on granicę krajową
(wymogi 133a i 133b określone w załączniku IC).
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 207
cardNumberAndGenDriverSlot identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny czytnika karty kierowcy.
cardNumberAndGenCodriverSlot identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny czytnika karty współkierowcy.
countryLeft to kraj, który pojazd opuścił, określony na podstawie ostat­
niej dostępnej pozycji przed wykryciem przekroczenia granicy. „Reszta
świata” (kod 'FF’H NationNumeric) stosuje się, gdy przyrząd rejestru­
jący nie jest w stanie określić kraju, w którym pojazd się znajduje (np.
bieżący kraj nie jest objęty zapisanymi mapami cyfrowymi).
countryEntered to kraj, do którego pojazd wjechał. „Reszta świata”
(kod 'FF’H NationNumeric) stosuje się, gdy przyrząd rejestrujący nie
jest w stanie określić kraju, w którym pojazd się znajduje (np. bieżący
kraj nie jest objęty zapisanymi mapami cyfrowymi).
gnssPlaceAuthRecord zawiera informacje dotyczące pozycji pojazdu
w momencie wykrycia przekroczenia granicy oraz statusu jej
uwierzytelnienia.
vehicleOdometerValue to stan licznika kilometrów, gdy przyrząd rejes­
trujący wykrył, że pojazd przekroczył granicę krajową.
2.203b. VuBorderCrossingRecordArray
Generacja 2, wersja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące prze­
kroczeń granicy przez pojazd (wymóg 133c określony w załączniku IC).
recordType oznacza typ rekordu (VuBorderCrossingRecord). Przypi­
sanie wartości: zob. RecordType.
recordSize to wielkość VuBorderCrossingRecord w bajtach.
noOfRecords to liczba rekordów w zbiorze.
records to zbiór rekordów dotyczących przekroczenia granicy.
▼M1
2.204. VuGNSSADRecordArray
Generacja 2:
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 208
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.
▼M3
2.204a. VuGnssMaximalTimeDifference
Generacja 2, wersja 2:
Maksymalna różnica między czasem prawdziwym a czasem zegara
czasu rzeczywistego VU, na podstawie maksymalnego dryftu czasu
określonego w wymogu 041 w załączniku IC, przekazywanego przez
przyrząd rejestrujący do urządzenia zewnętrznego GNSS, zob. dodatek
12, wymóg GNS_3g.
▼B
2.205. VuIdentification
Informacje przechowywane w przyrządzie rejestrującym dotyczące jego
identyfikacji (wymaganie 075 określone w załączniku 1B oraz wyma­
gania 93 i 121 określone w załączniku 1C).
Generacja 1:
vuManufacturerName jest nazwą producenta przyrządu rejestrującego.
vuManufacturerAddress jest adresem producenta przyrządu rejestrują­
cego.
vuPartNumber jest numerem części przyrządu rejestrującego.
vuSerialNumber jest numerem seryjnym przyrządu rejestrującego.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 209
vuSoftwareIdentification identyfikuje oprogramowanie zainstalowane
w przyrządzie rejestrującym.
vuManufacturingDate jest datą produkcji przyrządu rejestrującego.
vuApprovalNumber jest numerem homologacji typu przyrządu rejes­
trującego.
▼M3
Generacja 2:
Oprócz generacji 1 używane są następujące elementy danych:
vuGeneration identyfikuje generację przyrządu rejestrującego.
vuAbility podaje informację, czy VU obsługuje 1. generację kart do
tachografu.
vuDigitalMapVersion to wersja mapy cyfrowej przechowywanej
w przyrządzie rejestrującym (element obecny tylko w wersji 2).
▼B
2.206. VuIdentificationRecordArray
Generacja 2:
VuIdentification wraz z metadanymi stosowany w protokole pobierania
danych.
recordType oznacza typ rekordu (VuIdentification). Przypisanie
wartości: zob. RecordType
recordSize to wielkość VuIdentification w bajtach.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 210
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów VuIdentification.
2.207. VuITSConsentRecord
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
zgody kierowcy na stosowanie inteligentnych systemów 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 inte­
ligentnych systemów transportowych
2.208. VuITSConsentRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
zgody kierowcy na stosowanie inteligentnych systemów 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.
▼M3
2.208a. VuLoadUnloadRecord
Generacja 2, wersja 2:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 211
Informacje przechowywane w przyrządzie rejestrującym dotyczące
wpisanej operacji załadunku/rozładunku (wymogi 133e, 133f i 133g
określone w załączniku IC).
timeStamp to data i godzina wpisania operacji załadunku/rozładunku.
operationType to wpisany typ operacji (załadunek, rozładunek lub
równoczesny załadunek/rozładunek).
cardNumberAndGenDriverSlot identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny czytnika karty kierowcy.
cardNumberAndGenCodriverSlot identyfikuje kartę, w tym jej gene­
rację, włożoną do szczeliny czytnika karty współkierowcy.
gnssPlaceAuthRecord zawiera informacje dotyczące pozycji pojazdu
oraz jej statusu uwierzytelnienia.
vehicleOdometerValue to stan licznika kilometrów w związku
z operacją załadunku/rozładunku.
2.208b. VuLoadUnloadRecordArray
Generacja 2, wersja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
wpisanej operacji załadunku/rozładunku (wymóg 133h określony w załącz­
niku IC).
recordType oznacza typ rekordu (VuLoadUnloadRecord).Przypisanie
wartości: zob. RecordType.
recordSize to wielkość VuLoadUnloadRecord w bajtach.
noOfRecords to liczba rekordów w zbiorze.
records to zbiór rekordów dotyczących operacji załadunku/rozładunku.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 212
2.209. VuManufacturerAddress
Adres producenta przyrządu rejestrującego.
Przypisanie wartości: nieokreślona.
2.210. VuManufacturerName
Nazwa producenta przyrządu rejestrującego.
Przypisanie wartości: nieokreślona.
2.211. VuManufacturingDate
Data produkcji przyrządu rejestrującego.
Przypisanie wartości: nieokreślona.
2.212. VuOverSpeedingControlData
Informacje przechowywane w przyrządzie rejestrującym dotyczące prze­
kroczeń prędkości od ostatniej kontroli przekroczenia prędkości (wyma­
ganie 095 określone w załączniku 1B i wymaganie 117 określone
w załączniku 1C).
lastOverspeedControlTime jest datą i godziną ostatniej kontroli prze­
kroczenia prędkości.
firstOverspeedSince jest datą i godziną pierwszego przekroczenia pręd­
kości po tej ostatniej kontroli przekroczenia prędkości.
numberOfOverspeedSince jest liczbą zdarzeń przekroczenia prędkości
od ostatniej kontroli przekroczenia prędkości.
2.213. VuOverSpeedingControlDataRecordArray
Generacja 2:
VuOverSpeedingControlData wraz z metadanymi stosowany w protokole
pobierania danych.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 213
recordType oznacza typ rekordu (VuOverSpeedingControlData). Przy­
pisanie wartości: zob. RecordType
recordSize to wielkość VuOverSpeedingControlData w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów danych kontroli przekroczenia prędkości.
2.214. VuOverSpeedingEventData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
zdarzeń przekroczenia prędkości (wymaganie 094 określone w załączniku
1B).
noOfVuOverSpeedingEvents jest liczbą zdarzeń wyszczególnionych
w zbiorze vuOverSpeedingEventRecords.
vuOverSpeedingEventRecords jest zbiorem rekordów zdarzeń przekro­
czenia prędkości.
2.215. VuOverSpeedingEventRecord
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
zdarzeń przekroczenia prędkości (wymaganie 094 określone w załączniku
1B i wymaganie 117 określone w załączniku 1C).
eventType jest typem zdarzenia.
eventRecordPurpose jest celem, dla którego zarejestrowano to
zdarzenie.
eventBeginTime jest datą i godziną rozpoczęcia zdarzenia.
eventEndTime jest datą i godziną zakończenia zdarzenia.
maxSpeedValue jest maksymalną prędkością zmierzoną w czasie
zdarzenia.
averageSpeedValue jest średnią arytmetyczną prędkości zmierzonych
w czasie zdarzenia.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 214
cardNumberDriverSlotBegin identyfikuje kartę włożoną do szczeliny
karty kierowcy na początku zdarzenia.
similarEventsNumber jest liczbą podobnych zdarzeń w tym dniu.
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
zdarzeń przekroczenia prędkości (wymaganie 094 określone w załączniku
1B i wymaganie 117 określone w załączniku 1C).
Zamiast cardNumberDriverSlotBegin w strukturze danych generacji 2
wykorzystuje się następujący element danych.
cardNumberAndGenDriverSlotBegin identyfikuje kartę, w tym jej
generację, włożoną do szczeliny karty kierowcy na początku 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 — 21.08.2023 — 003.002 — 215
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.
▼M3
Generacja 2, wersja 1:
▼B
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.
▼M3
Generacja 2, wersja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
miejsca rozpoczęcia lub zakończenia dziennego okresu pracy kierowcy
(wymóg 087 określony w załączniku 1B oraz wymogi 108 i 110 okre­
ślone w załączniku 1C).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 216
Zamiast placeRecord w strukturze danych wersji 2 generacji 2 wyko­
rzystuje się następujący element danych:
placeAuthRecord zawiera informacje dotyczące wpisanego miejsca,
zarejestrowanej pozycji, statusu uwierzytelnienia GNSS i godziny okre­
ślenia pozycji.
▼B
2.220. VuPlaceDailyWorkPeriodRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
miejsc rozpoczęcia lub zakończenia dziennego okresu pracy 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.
▼M3
2.222a. VuRtcTime
Generacja 2, wersja 2:
Czas zegara czasu rzeczywistego VU, przekazywany przez VU do urzą­
dzenia zewnętrznego GNSS, zob. dodatek 12, wymóg GNS_3f.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 217
2.223. VuSerialNumber
Numer seryjny przyrządu rejestrującego (wymaganie 075 określone
w załączniku 1B i wymaganie 93 określone w załączniku 1C).
2.224. VuSoftInstallationDate
Data instalacji wersji oprogramowania przyrządu rejestrującego.
Przypisanie wartości: nieokreślona.
2.225. VuSoftwareIdentification
Informacje przechowywane w przyrządzie rejestrującym dotyczące zain­
stalowanego oprogramowania.
vuSoftwareVersion jest numerem wersji oprogramowania przyrządu
rejestrującego.
vuSoftInstallationDate jest datą zainstalowania wersji oprogramowania.
2.226. VuSoftwareVersion
Numer wersji oprogramowania przyrządu rejestrującego.
Przypisanie wartości: nieokreślona.
2.227. VuSpecificConditionData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
warunków szczególnych.
noOfSpecificConditionRecords jest liczbą rekordów wyszczególnio­
nych w zbiorze specificConditionRecords.
specificConditionRecords jest zbiorem rekordów dotyczących
warunków szczególnych.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 218
2.228. VuSpecificConditionRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
warunków szczególnych (wymaganie 130 określone w załączniku 1C).
recordType oznacza typ rekordu (SpecificConditionRecord). Przypi­
sanie wartości: zob. RecordType
recordSize to wielkość SpecificConditionRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów dotyczących warunków szczególnych.
2.229. VuTimeAdjustmentData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
korekt czasu dokonanych poza regularną kalibracją (wymaganie 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:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 219
oldTimeValue, newTimeValue są starą i nową wartością daty
i godziny.
workshopName, workshopAddress są nazwą i adresem warsztatu.
workshopCardNumber identyfikuje kartę warsztatowa użytą do doko­
nania korekty czasu.
Generacja 2:
Zamiast workshopCardNumber w strukturze danych generacji 2 wyko­
rzystuje się następujący element danych.
workshopCardNumberAndGeneration identyfikuje kartę warsztatowa,
w tym jej generację, użytą do dokonania korekty czasu.
2.233. VuTimeAdjustmentRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
korekt czasu dokonanych poza regularną kalibracją (wymagania 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:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 220
typeOfTachographCardId określa wdrożony typ karty.
cardStructureVersion określa wersję struktury wdrożonej na karcie.
noOfEventsPerType jest liczbą zdarzeń według typu zdarzenia możli­
wych do zarejestrowania na karcie.
noOfFaultsPerType jest liczbą usterek według typu usterki możliwych
do zarejestrowania na karcie.
activityStructureLength podaje liczbę bajtów dostępnych do przecho­
wywania rekordów czynności.
noOfCardVehicleRecords jest liczbą rekordów dotyczących pojazdów
możliwych do zarejestrowania na karcie.
noOfCardPlaceRecords jest liczbą miejsc możliwych do zarejestro­
wania na karcie.
noOfCalibrationRecords jest liczbą rekordów kalibracyjnych możli­
wych do zarejestrowania na karcie.
Generacja 2:
▼M1
Oprócz generacji 1 używane są następujące elementy danych:
noOfGNSSCDRecords jest liczbą rekordów skumulowanego czasu
prowadzenia pojazdu z GNSS, które mogą być zapisane na karcie.
noOfSpecificConditionRecords jest liczbą rekordów warunków szcze­
gólnych, które mogą być zapisane na karcie.
noOfCardVehicleUnitRecords jest liczbą rekordów używanych przy­
rządów rejestrujących, które mogą być zapisane na karcie.
▼M3
2.234a. WorkshopCardApplicationIdentificationV2
Generacja 2, wersja 2:
Informacje przechowywane na karcie warsztatowej dotyczące identyfi­
kacji aplikacji karty (wymóg 330a określony w załączniku IC).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 221
lengthOfFollowingData to liczba kolejnych bajtów we wpisie.
noOfBorderCrossingRecords to liczba rekordów dotyczących przekro­
czenia granicy, które mogą być przechowywane na karcie warsztatowej.
noOfLoadUnloadRecords to liczba rekordów dotyczących załadunku/
rozładunku, które mogą być przechowywane na karcie warsztatowej.
noOfLoadTypeEntryRecords to liczba rekordów dotyczących wpisu
typu załadunku, które mogą być przechowywane na karcie warsztatowej.
vuConfigurationLengthRange to liczba bajtów na karcie do tacho­
grafu, dostępnych na potrzeby przechowywania konfiguracji VU.
2.234b. WorkshopCardCalibrationAddData
Generacja 2, wersja 2:
Informacje przechowywane na karcie warsztatowej dotyczące dodatko­
wych danych (tj. domyślnego typu załadunku) wprowadzonych podczas
kalibracji (wymóg 356l określony w załączniku IC).
calibrationPointerNewestRecord to indeks ostatniego uaktualnionego
rekordu dodatkowych danych kalibracyjnych.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordu
dodatkowych danych kalibracyjnych, rozpoczynając od „0” dla pierwszego
wystąpienia w strukturze rekordu dodatkowych danych kalibracyjnych.
workshopCardCalibrationAddDataRecords to zbiór rekordów zawie­
rających starą wartość daty i godziny, wartość identyfikacji pojazdu oraz
domyślny typ załadunku pojazdu.
2.234c. WorkshopCardCalibrationAddDataRecord
Generacja 2, wersja 2:
Informacje przechowywane na karcie warsztatowej dotyczące domyś­
lnego typu załadunku pojazdu wprowadzonego podczas kalibracji
(wymóg 356k określony w załączniku IC).
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 222
oldTimeValue to stara wartość daty i godziny zawarta w odpowiednim
rekordzie WorkshopCardCalibrationRecord,
vehicleIdentificationNumber to numer identyfikacyjny pojazdu,
również zawarty w odpowiednim rekordzie WorkshopCardCalibration­
Record,
byDefaultLoadType to domyślny typ załadunku pojazdu (element
obecny tylko w wersji 2).
calibrationCountry to kraj, w którym wykonano kalibrację,
calibrationCountryTimestamp to data i godzina przekazania przez
odbiornik GNSS pozycji wykorzystanej do określenia tego kraju.
▼B
2.235. WorkshopCardCalibrationData
Informacje przechowywane na karcie warsztatowej dotyczące 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).
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 223
Generacja 1:
calibrationPurpose jest celem kalibracji.
vehicleIdentificationNumber jest numerem VIN.
vehicleRegistration zawiera numer VRN i państwa członkowskiego
rejestracji.
wVehicleCharacteristicConstant jest współczynnikiem charaktery­
stycznym pojazdu.
kConstantOfRecordingEquipment jest stałą urządzenia rejestrującego.
lTyreCircumference jest obwodem tocznym kół.
tyreSize jest oznaczeniem rozmiarów opon zamontowanych w pojeź­
dzie.
authorisedSpeed jest maksymalną, dozwoloną prędkością pojazdu.
oldOdometerValue, newOdometerValue są starym i nowym stanem
licznika kilometrów.
oldTimeValue, newTimeValue są starą i nową wartością daty
i godziny.
nextCalibrationDate jest datą następnej kalibracji typu określonego
w CalibrationPurpose, którą powinien przeprowadzić autoryzowany
organ kontrolny.
vuPartNumber, vuSerialNumber and sensorSerialNumber są elemen­
tami danych do identyfikacji urządzenia rejestrującego.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 224
Generacja 2:
Oprócz generacji 1 używane są następujące elementy danych:
sensorGNSSSerialNumber, który identyfikuje urządzenie zewnętrzne
GNSS.
rcmSerialNumber, który identyfikuje moduł komunikacji na odległość.
sealDataCard podaje informacje o plombach przymocowanych do
różnych części pojazdu.
2.237. WorkshopCardHolderIdentification
Informacje przechowywane na karcie warsztatowej dotyczące identyfikacji
posiadacza karty (wymagania 311 i 334 określone w załączniku 1C).
workshopName jest nazwą warsztatu posiadacza karty.
workshopAddressjest 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 — 21.08.2023 — 003.002 — 225
2.239. W-VehicleCharacteristicConstant
Współczynnik charakterystyczny pojazdu (definicja k)).
Przypisanie wartości: liczba impulsów na kilometr w zakresie opera­
cyjnym 0 do 64 255 impulsów/km.
2.240. VuPowerSupplyInterruptionRecord
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące
zdarzeń przerwy w zasilaniu (wymaganie 117 określone w załączniku
1C).
eventType jest typem zdarzenia.
eventRecordPurpose jest celem, dla którego zarejestrowano to
zdarzenie.
eventBeginTime jest datą i godziną rozpoczęcia zdarzenia.
eventEndTime jest datą i godziną zakończenia zdarzenia.
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
zdarzenia.
similarEventsNumber jest liczbą podobnych zdarzeń w tym dniu.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 226
2.241. VuPowerSupplyInterruptionRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące zdarzeń
przerwy w zasilaniu (wymaganie 117 określone w załączniku 1C).
recordType oznacza typ rekordu (VuPowerSupplyInterruptionRecord).
Przypisanie wartości: zob. RecordType
recordSize to wielkość VuPowerSupplyInterruptionRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów zdarzeń przerwy w zasilaniu.
2.242. VuSensorExternalGNSSCoupledRecordArray
Generacja 2:
Zbiór zapisów SensorExternalGNSSCoupledRecord wraz z metadanymi
stosowany w protokole pobierania danych.
recordType oznacza typ rekordu (SensorExternalGNSSCoupledRecord).
Przypisanie wartości: zob. RecordType
recordSize to wielkość SensorExternalGNSSCoupledRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów SensorExternalGNSSCoupled.
2.243. VuSensorPairedRecordArray
Generacja 2:
Zbiór zapisów SensorPairedRecord wraz z metadanymi stosowany
w protokole pobierania danych.
recordType oznacza typ rekordu (SensorPairedRecord). Przypisanie
wartości: zob. RecordType
recordSize to wielkość SensorPairedRecord w bajtach.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 227
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów sparowanego czujnika.
3. DEFINICJE WARTOŚCI I ZAKRESU WIELKOŚCI
Definicja wartości zmiennych używana w definicjach w ust. 2.
4. ZESTAW ZNAKÓW:
W łańcuchach IA5Strings używa się znaków ASCII zdefiniowanych
w normie ISO/IEC 8824-1. Na potrzeby czytelności i łatwego odwoły­
wania się poniżej podano przypisanie wartości. W przypadku 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 — 21.08.2023 — 003.002 — 228
w TR-03110-3 i powtórzono dla kompletności wywodu. Takie OID
zawarto w poddrzewie bsi-de:
Identyfikatory protokołu uwierzytelnienia VU
Przykład: Załóżmy, że należy dokonać uwierzytelnienia VU za pomocą
SHA-384, wtedy identyfikatorem obiektu, który należy użyć jest (w składni
ASN.1) .
Wartość tego identyfikatora obiektu w zapisie kropkowym wynosi
.
Zapis kropkowy Zapis bajtowy
„04 00 7F 00 07 02 02 02 02 03”
„04 00 7F 00 07 02 02 02 02 04”
„04 00 7F 00 07 02 02 02 02 05”
Identyfikatory protokołu uwierzytelnienia z chipem
Przykład: Przypuśćmy, że uwierzytelnienie chipu ma zostać doko­
nane za pomocą algorytmu ECDH, co daje długość klucza sesji
AES 128 bitów. Ten klucz sesji zostanie następnie wykorzystany
w trybie pracy CBC w celu zapewnienia poufności danych i z algo­
rytmem CMAC w celu zapewnienia autentyczności danych. Zatem
identyfikatorem obiektu, który należy użyć jest (w składni ASN.1)
. Wartość
tego identyfikatora obiektu w zapisie kropkowym wynosi
.
Zapis kropkowy Zapis bajtowy
„04 00 7F 00 07 02 02 03 02 02”
„04 00 7F 00 07 02 02 03 02 03”
„04 00 7F 00 07 02 02 03 02 04”
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 229
6.2. Identyfikatory aplikacji
Generacja 2:
Identyfikator aplikacji (AID) dla urządzenia zewnętrznego GNSS (gene­
racja 2) jest określony za pomocą „FF 44 54 45 47 4D”. Jest to zastrze­
żony AID zgodny z normą ISO/IEC 7816-4.
Uwaga: 5 ostatnich bajtów koduje DTEGM dla urządzenia zewnętrz­
nego GNSS tachografu inteligentnego.
Identyfikator aplikacji dla aplikacji kart do tachografów 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 — 21.08.2023 — 003.002 — 230
Dodatek 2
SPECYFIKACJA KART DO TACHOGRAFÓW
SPIS TREŚCI
1. WPROWADZENIE
1.1. Skróty
1.2. Odniesienia
2. CHARAKTERYSTYKI ELEKTRYCZNE I FIZYCZNE
2.1. Napięcie zasilające i pobór prądu
2.2. Napięcie programowania V pp
2.3. Generowanie i częstotliwość zegara
2.4. Styk we/wy
2.5. Stany karty
3. SPRZĘT I KOMUNIKACJA
3.1. Wprowadzenie
3.2. Protokół komunikacyjny
3.2.1 Protokoły
3.2.2 ATR
3.2.3 PTS
3.3. Zasady dostępu
3.4. Przegląd poleceń i kodów błędów
3.5. Opisy poleceń
3.5.1 SELECT
3.5.2 READ BINARY
3.5.3 UPDATE BINARY
3.5.4 GET CHALLENGE
3.5.5 VERIFY
3.5.6 GET RESPONSE
3.5.7 PSO: VERIFY CERTIFICATE
3.5.8 INTERNAL AUTHENTICATE
3.5.9 EXTERNAL AUTHENTICATE
3.5.10 GENERAL AUTHENTICATE
3.5.11 MANAGE SECURITY ENVIRONMENT
3.5.12 PSO: HASH
3.5.13 PERFORM HASH OF FILE
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 231
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE
3.5.15 PSO: VERIFY DIGITAL SIGNATURE
3.5.16 PROCESS DSRC MESSAGE
4. STRUKTURA KART DO TACHOGRAFÓW
4.1. Plik główny MF
4.2. Aplikacje karty kierowcy
4.2.1 Aplikacja karty kierowcy 1. generacji
4.2.2 Aplikacja karty kierowcy 2. generacji
4.3. Aplikacje karty warsztatowej
4.3.1 Aplikacja karty warsztatowej 1. generacji
4.3.2 Aplikacja karty warsztatowej 2. generacji
4.4. Aplikacje karty kontrolnej
4.4.1 Aplikacja karty kontrolnej 1. generacji
4.4.2 Aplikacja karty kontrolnej 2. generacji
4.5. Aplikacje karty firmowej
4.5.1 Aplikacja karty firmowej 1. generacji
4.5.2 Aplikacja karty firmowej 2. generacji
1. WPROWADZENIE
1.1. Skróty
Do celów niniejszego dodatku stosuje się poniższe skróty.
AC [Access conditions] warunki dostępu
AES [Advanced Encryption Standard] zaawansowany standard
szyfrowania
AID [Application Identifier] identyfikator aplikacji
ALW [Always] zawsze
APDU [Application Protocol Data Unit] jednostka danych proto­
kołu aplikacji (struktura polecenia)
ATR [Answer To Reset] reakcja na sprowadzenie do stanu
wyjściowego
AUT [Authenticated] uwierzytelniony
C6, C7 styki 6 i 7 karty opisane w normie ISO/IEC 7816-2
cc [clock cycles] cykle zegarowe
▼M1
CHA upoważnienie posiadacza certyfikatu
▼B
CHV [Card holder Verification Information] informacje weryfi­
kacyjne posiadacza karty
CLA bajt klasy w poleceniu APDU
▼M1
DO obiekt danych
▼B
DSRC [Dedicated Short Range Communication] wydzielona
łączność krótkiego zasięgu
DF [Dedicated File] plik dedykowany. DF może zawierać
inne pliki (EF lub DF)
ECC [Elliptic Curve Cryptography] kryptografia krzywych
eliptycznych
EF [Elementary File] plik elementarny
etu [elementary time unit] elementarna jednostka czasu
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 232
G1 [Generation 1] 1. generacja
G2 [Generation 2] 2. generacja
IC [Integrated Circuit] układ scalony
ICC [Integrated Circuit Card] karta z układem scalonym
ID [Identifier] identyfikator
IFD [Interface Device] urządzenie interfejsu
IFS [Information Field Size] wielkość pola informacyjnego
IFSC [Information Field Size for the card] wielkość pola infor­
macyjnego dla karty
IFSD [Information Field Size Device] wielkość pola informa­
cyjnego urządzenia (dla terminala)
INS bajt instrukcji w poleceniu APDU
Lc długość danych wejściowych dla polecenia APDU
Le długość danych oczekiwanych (dane wyjściowe dla pole­
cenia)
MF [Master File] plik główny (root DF)
NAD [Node Address] adres węzła używany w protokole T=1
NEV [Never] nigdy
P1-P2 bajty parametryczne
PIN [Personal Identification Number] osobisty numer identy­
fikacyjny
PRO SM [Protected with secure messaging] chroniony z bezpieczną
wymianą komunikatów
PTS [Protocol Transmission Selection] wybór protokołu komu­
nikacyjnego
RFU [Reserved for Future Use] zastrzeżone do wykorzystania
w przyszłości
RST [Reset] sprowadzenie do stanu wyjściowego (karty)
SFID [Short EF Identifier] krótki identyfikator EF
SM [Secure Messaging] bezpieczna wymiana komunikatów
SW1-SW2 bajty stanu
TS początkowy znak ATR
VPP napięcie programowania
VU [Vehicle Unit] przyrząd rejestrujący
XXh wartość XX w zapisie heksadecymalnym
„XXh” wartość XX w zapisie heksadecymalnym
|| symbol konkatenacji 03||04=0304
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 233
1.2. Odniesienia
W niniejszym dodatku stosuje się następujące odniesienia:
ISO/IEC 7816-2 Karty identyfikacyjne – Karty z układami scalo­
nymi – część 2: Wymiary i rozmieszczenie styków.
ISO/IEC 7816-2:2007.
ISO/IEC 7816-3 Karty identyfikacyjne – Karty z układami scalo­
nymi – część 3: Złącze elektryczne i protokoły
komunikacyjne. ISO/IEC 7816-3:2006.
ISO/IEC 7816-4 Karty identyfikacyjne – Karty z układami scalo­
nymi – część 4: Organizacja, zabezpieczenia i pole­
cenia wymiany. ISO/IEC 7816-4:2013 + Cor 1:
2014.
ISO/IEC 7816-6 Karty identyfikacyjne – Karty z układami scalo­
nymi – część 6: Międzybranżowe elementy danych
do wymiany. ISO/IEC 7816-6:2004 + Cor 1: 2006.
ISO/IEC 7816-8 Karty identyfikacyjne – Karty z układami scalo­
nymi – część 8: Polecenia operacji zabezpieczają­
cych. ISO/IEC 7816-8:2004.
ISO/IEC 9797-2 Technologia informatyczna – Techniki zabezpie­
czeń – Kody uwierzytelniania wiadomości (MAC)
– część 2: Mechanizmy wykorzystujące funkcję
haszującą. ISO/IEC 9797-2:2011
2. CHARAKTERYSTYKI ELEKTRYCZNE I FIZYCZNE
TCS_01 Wszystkie sygnały elektryczne muszą być zgodne z normą
ISO/IEC 7816-3, chyba że określono inaczej.
TCS_02 Rozmieszczenie i wymiary styków kart muszą być zgodne
z normą ISO/IEC 7816-2.
2.1. Napięcie zasilające i pobór prądu
TCS_03 Karta pracuje zgodnie ze specyfikacją przy poborze w 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 — 21.08.2023 — 003.002 — 234
Niski Wysoki
Bit 3 Bit 2 Bit 1
0 0 1
Clockstop dozwolony, brak preferowanego
poziomu
0 1 1
Clockstop dozwolony, preferowany poziom
wysoki
1 0 1 Clockstop dozwolony, preferowany poziom niski
0 0 0 Clockstop niedozwolony
0 1 0
Clockstop dozwolony tylko przy wysokim
poziomie
1 0 0 Clockstop dozwolony tylko przy niskim poziomie
Bitów od 4 do 8 nie używa się.
2.4. Styk we/wy
TCS_08 Styk we/wy C7 służy do odbierania i wysyłania danych do
IFD. W czasie pracy tylko karta albo tylko IFD jest w trybie
nadawania. Gdyby jednak obie jednostki jednocześnie
znalazły się w trybie nadawania, nie może to spowodować
uszkodzenia karty. Karta wchodzi do trybu odbioru, chyba
że nadaje dane.
2.5. Stany karty
TCS_09 Gdy podawane jest napięcie zasilające, karta pracuje
w dwóch stanach:
▼M3
stan operacyjny, w którym karta wykonuje polecenia lub
jest połączona z przyrządem rejestrującym;
▼B
stan jałowy we wszystkich pozostałych sytuacjach (w tym
stanie karta zachowuje wszystkie dane).
3. SPRZĘT I KOMUNIKACJA
3.1. Wprowadzenie
W punkcie tym opisano minimalną funkcjonalność wymaganą od kart
do tachografów i VU w celu zagwarantowania prawidłowego funk­
cjonowania i interoperacyjności.
Karty do tachografów muszą być zgodne, w największym możliwym
stopniu, z obowiązującymi normami ISO/IEC (w szczególności
z normą ISO/IEC 7816). Niemniej jednak szczegółowo opisano pole­
cenia i protokoły w celu określenia niektórych ograniczonych 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 — 21.08.2023 — 003.002 — 235
TCS_13 Urządzenia wykorzystują konwencję bezpośrednią w obu
protokołach: w związku z tym konwencja bezpośrednia jest
obowiązkowa dla karty.
TCS_14 Bajt karty informacyjnej wielkości pola przedstawiony
jest na ATR pod oznaczeniem TA3. Wartość ta jest nie
mniejsza niż „F0h” (= 240 bajtów).
Do protokołów stosuje się następujące ograniczenia:
TCS_15 T=0
— Urządzenie interfejsu wspiera odpowiedź na we/wy po
wzroście krawędzi narastającego sygnału na RST z 400
cc.
— Urządzenie interfejsu potrafi odczytać znaki rozdzielone
12 etu.
— Urządzenie interfejsu odczytuje błędny znak i jego
powtórzenie, jeżeli rozdzielone 13 etu. W przypadku
wykrycia błędnego znaku na we/wy może pojawić się
sygnał błędu między 1 etu a 2 etu. Urządzenie obsłu­
guje opóźnienie 1 etu.
— Urządzenie interfejsu akceptuje 33-bajtowe ATR
(TS + 32)
— Jeżeli TC1 znajduje się w ATR, to dla znaków wysy­
łanych przez urządzenie interfejsu jest dodatkowy czas
ochronny (Extra Guard Time), chociaż znaki wysyłane
przez kartę mogą być jeszcze przedzielone odstępami
12 etu. Odnosi się to także do znaku ACK wysyłanego
przez kartę po wysłaniu znaku P3 przez urządzenie
interfejsu.
— Urządzenie interfejsu bierze pod uwagę znak NUL
wysyłany przez kartę.
— Urządzenie interfejsu akceptuje tryb uzupełniający dla
ACK.
— Polecenia odbierz-odpowiedź (get-response) nie można
używać w trybie łańcuchowym do otrzymywania
danych, których długość może być większa niż 255
bajtów.
TCS_16 T=1
— Bajt NAD: nieużywany (NAD ustawia się na „00”).
— S-block ABORT: nieużywany.
— Błąd stanu S-block VPP: nieużywany.
▼M3
__________
▼B
— IFD bezpośrednio po ATR podaje wielkość pola infor­
macyjnego dla urządzenia (IFSD): IFD wysyła żądanie
S-Block IFS po ATR, a karta odpowiada S-Block IFS.
Zalecaną wartością dla IFSD są 254 bajty.
— Karta nie pyta o skorygowane IFS.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 236
3.2.2 ATR
TCS_17 Urządzenie sprawdza bajty ATR, zgodnie z normą ISO/IEC
7816-3. Nie wykonuje się weryfikacji znaków historycz­
nych ATR.
Przykład podstawowego Biprotocol ATR zgodnego
z normą ISO/IEC 7816-3
Znak Wartość Uwagi
TS „3Bh” wskazuje konwencję bezpośrednią
T0 „85h” TD1 obecny; jest 5 bajtów historycznych
TD1 „80h” TD2 obecny; będzie użyty T=0
TD2 „11h” TA3 obecny; będzie użyty T=1
TA3 „XXh” (min. „F0h”) wielkość pola informacyjnego dla karty (IFSC)
TH1–TH5 „XXh” znaki historyczne
TCK „XXh” znak kontrolny (exclusive OR)
TCS_18 Po ATR wybierany jest domyślnie plik główny (MF) i staje
się katalogiem bieżącym.
3.2.3 PTS
TCS_19 Domyślnym protokołem jest T=0. Aby wybrać protokół
T=1, urządzenie musi wysłać do karty PTS (znane też
jako PPS).
TCS_20 Ponieważ oba protokoły T=0 i T=1 są wymagane dla karty,
podstawowy PTS do przełączania między protokołami jest
obowiązkowy dla karty.
PTS można używać, jak wskazano w normie ISO/IEC
7816-3, do przełączania na szybkości transmisji większe
niż standardowa, proponowane przez kartę w ATR, jeżeli
dotyczy (bajt TA(1)).
Większe szybkości transmisji są opcjonalne dla karty.
TCS_21 Jeżeli karta nie obsługuje innej szybkości transmisji niż
standardowa (lub jeżeli nie obsługuje wybranej szybkości
transmisji), karta musi prawidłowo odpowiadać na PTS,
zgodnie z normą ISO/IEC 7816-3, opuszczając bajt PPS1.
Poniżej pokazano przykłady podstawowego PTS do
wyboru protokołu:
Znak Wartość Uwagi
PPSS „FFh” znak inicjujący
PPS0 „00h” lub „01h” nie ma PPS1 do PPS3; „00h”, aby wybrać T0, „01h”, aby
wybrać T1
PK „XXh” znak kontrolny: „XXh” = „FFh”, jeżeli PPS0 = „00h”,
„XXh” = „FEh”, jeżeli PPS0 = „01h”.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 237
3.3. Zasady dostępu
TCS_22 Zasada dostępu określa odpowiednie warunki zabezpie­
czenia dla danego trybu dostępu, tj. polecenia. Jeżeli przed­
miotowe warunki zabezpieczenia są spełnione, odpo­
wiednie polecenie jest przetwarzane.
TCS_23 Następujące warunki zabezpieczenia są stosowane na
potrzeby karty do tachografu:
Skrót Znaczenie
ALW Operacja jest zawsze możliwa i może być wykonywana bez 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 — 21.08.2023 — 003.002 — 238
TCS_25 W przypadku aplikacji DF Tachograph G1 zastosowanie
mają następujące zasady dostępu:
▼M1
Polecenie Karta kierowcy
Karta warsz­
tatowa
Karta kontrolna Karta firmowa
External Authenticate
— dla uwierzytelnienia 1. gene­
racji
ALW ALW ALW ALW
— dla uwierzytelnienia 2. gene­
racji
ALW PWD ALW ALW
Internal Authenticate ALW PWD ALW ALW
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message nie dotyczy nie dotyczy nie dotyczy nie dotyczy
PSO: Compute Digital Signature ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
nie dotyczy nie dotyczy
PSO: Hash nie dotyczy nie dotyczy ALW nie dotyczy
PERFORM HASH of FILE ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
nie dotyczy nie dotyczy
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature nie dotyczy nie dotyczy ALW nie dotyczy
Verify nie dotyczy ALW nie dotyczy nie dotyczy
▼B
TCS_26 W przypadku aplikacji DF Tachograph_G2 zastosowanie
mają następujące zasady dostępu:
▼M1
Polecenie Karta kierowcy
Karta warsz­
tatowa
Karta kontrolna Karta firmowa
External Authenticate
— dla uwierzytelnienia 1.
generacji
nie dotyczy nie dotyczy nie dotyczy nie dotyczy
— dla uwierzytelnienia 2.
generacji
ALW PWD ALW ALW
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 239
Polecenie Karta kierowcy
Karta warsz­
tatowa
Karta kontrolna Karta firmowa
Internal Authenticate nie dotyczy nie dotyczy nie dotyczy nie dotyczy
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message nie dotyczy ALW ALW nie dotyczy
PSO: Compute Digital Signature ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
nie dotyczy nie dotyczy
PSO: Hash nie dotyczy nie dotyczy ALW nie dotyczy
PERFORM HASH of FILE ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
nie dotyczy nie dotyczy
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature nie dotyczy nie dotyczy ALW nie dotyczy
Verify nie dotyczy ALW nie dotyczy nie dotyczy
▼B
TCS_27 W przypadku MF zastosowanie mają następujące zasady
dostępu:
▼M1
Polecenie Karta kierowcy
Karta warsz­
tatowa
Karta kontrolna Karta firmowa
External Authenticate
— dla uwierzytelnienia 1.
generacji
nie dotyczy nie dotyczy nie dotyczy nie dotyczy
— dla uwierzytelnienia 2.
generacji
ALW PWD ALW ALW
Internal Authenticate nie dotyczy nie dotyczy nie dotyczy nie dotyczy
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 240
Polecenie Karta kierowcy
Karta warsz­
tatowa
Karta kontrolna Karta firmowa
Process DSRC Message nie dotyczy nie dotyczy nie dotyczy nie dotyczy
PSO: Compute Digital Signature nie dotyczy nie dotyczy nie dotyczy nie dotyczy
PSO: Hash nie dotyczy nie dotyczy nie dotyczy nie dotyczy
PERFORM HASH of FILE nie dotyczy nie dotyczy nie dotyczy nie dotyczy
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature nie dotyczy nie dotyczy nie dotyczy nie dotyczy
Verify nie dotyczy ALW nie dotyczy nie dotyczy
▼B
TCS_28 Karta do tachografu może, ale nie musi przyjmować
poleceń z wyższego poziomu zabezpieczenia niż poziom
określony w warunkach zabezpieczenia. Tzn. jeżeli warun­
kiem zabezpieczenia jest ALW (lub PLAIN-C), karta może
przyjąć polecenie z bezpieczną wymianą komunikatów
(w trybie szyfrowania lub uwierzytelnienia). Jeżeli warunek
zabezpieczenia wymaga bezpiecznej wymiany komuni­
katów w trybie uwierzytelnienia, karta do tachografu
może przyjąć polecenie z bezpieczną wymianą komuni­
katów tej samej generacji w trybie uwierzytelnienia i szyf­
rowania.
Uwaga: Opisy poleceń dostarczają więcej informacji na
temat obsługi poleceń dla poszczególnych typów kart do
tachografów oraz poszczególnych DF.
3.4. Przegląd poleceń i kodów błędów
Polecenia i organizacja pliku wynikają z normy ISO/IEC 7816-4
i spełniają jej wymagania.
W tej sekcji opisano poniższe pary polecenie-odpowiedź dla APDU.
Warianty poleceń, które są obsługiwane przez aplikacje 1. i 2. gene­
racji, zostały określone w odpowiednich opisach poleceń.
Polecenie INS
SELECT „A4h”
READ BINARY „B0h”, „B1h”
UPDATE BINARY „D6h”, „D7h”
GET CHALLENGE „84h”
VERIFY „20h”
GET RESPONSE „C0h”
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 241
Polecenie INS
PERFORM SECURITY OPERA­
TION
„2Ah”
— VERIFY CERTIFICATE
— COMPUTE DIGITAL SIGNA­
TURE
— VERIFY DIGITAL SIGNA­
TURE
— HASH
— PERFORM HASH OF FILE
— PROCESS DSRC MESSAGE
INTERNAL AUTHENTICATE „88h”
EXTERNAL AUTHENTICATE „82h”
MANAGE SECURITY ENVIRON­
MENT
„22h”
— SET DIGITAL SIGNATURE
TEMPLATE
— SET AUTHENTICATION
TEMPLATE
GENERAL AUTHENTICATE „86h”
▼M1
TCS_29 Słowa stanu SW1 i SW2 są zwracane w komunikacie
odpowiedzi i oznaczają stan przetwarzania polecenia.
SW1 SW2 Znaczenie
90 00 Normalne przetwarzanie.
61 XX Normalne przetwarzanie. XX = liczba dostępnych bajtów
odpowiedzi.
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 — 21.08.2023 — 003.002 — 242
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 — 21.08.2023 — 003.002 — 243
TCS_31 Jeżeli żądane są oba bajty długości (Lc i Le), opisywane
polecenie musi być podzielone na dwie części, jeśli IFD
używa protokołu T=0: IFD wysyła to polecenie z P3=Lc +
dane, a następnie wysyła polecenie GET RESPONSE (zob.
pkt 3.5.6) z P3=Le.
TCS_32 Jeżeli żądane są oba bajty długości i Le=0 (bezpieczna
wymiana komunikatów):
— gdy używany jest protokół T=1, karta odpowiada na
Le=0, wysyłając wszystkie dostępne dane wyjściowe;
— gdy używany jest protokół T=0, IFD wysyła pierwsze
polecenie z P3=Lc + dane, karta odpowiada (na to
niejawne Le=0) bajtami stanu „61La”, gdzie La jest
liczbą dostępnych bajtów odpowiedzi. Następnie IFD
generuje polecenie GET RESPONSE z P3=La w celu
odczytania danych.
TCS_33 Karta do tachografu może opcjonalnie obsługiwać pola
o rozszerzonej długości zgodnie z normą ISO/IEC 7816-
4. Karta do tachografu, która obsługuje pola o rozszerzonej
długości, musi:
— wskazywać możliwość obsługi pól o rozszerzonej
długości w ATR;
— zapewniać obsługiwane pojemności bufora za pomocą
informacji o rozszerzonej długości w EF ATR/INFO,
zob. TCS_146;
— wskazywać, czy obsługuje pola o rozszerzonej długości
dla T = 1 lub T = 0 w EF Extended Length, zob.
TCS_147.
— obsługiwać pola o rozszerzonej długości dla aplikacji
tachograficznej 1. i 2. generacji.
Uwagi:
Wszystkie polecenia zostały określone dla pól o krótkiej
długości. Stosowanie APDU o rozszerzonej długości
wynika z ISO/IEC 7816-4.
Polecenia są zasadniczo określone dla trybu zwykłego, tj.
bez bezpiecznej wymiany komunikatów, ponieważ warstwa
bezpiecznej wymiany komunikatów została określona
w dodatku 11. Z zasad dostępu dla polecenia wynika,
czy polecenie wspiera bezpieczną wymianę komunikatów,
a także – czy polecenie wspiera bezpieczną wymianę
komunikatów 1. generacji lub 2. generacji. Niektóre
warianty poleceń opisano z bezpieczną wymianą komuni­
katów, aby zilustrować stosowanie bezpiecznej wymiany
komunikatów.
TCS_34 VU wykonuje pełny protokół 2. generacji wzajemnego
uwierzytelnienia VU – karta dla sesji, łącznie z weryfikacją
certyfikatu (jeżeli jest to wymagane), w DF Tachograph,
w DF Tachograph_G2 lub w MF.
3.5.1 SELECT
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego zastoso­
wanie jest ograniczone w porównaniu z poleceniem zdefiniowanym
w tej normie.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 244
Polecenia SELECT używa się:
— do wybierania aplikacji DF (musi być używany wybór przez
nazwę);
— do wybierania pliku elementarnego odpowiadającego przekaza­
nemu ID pliku.
3.5.1.1 W y b ó r p r z e z n a z w ę ( A I D )
Polecenie to pozwala wybrać aplikację DF na karcie.
TCS_35 Polecenie to można wykonywać z dowolnego miejsca
w strukturze pliku (po ATR lub w dowolnym momencie).
TCS_36 Wybór aplikacji powoduje przywrócenie bieżącego stanu
środowiska zabezpieczeń do stanu wyjściowego. Po
wybraniu aplikacji żaden bieżący klucz publiczny nie jest
już wybierany. Warunek dostępu EXT-AUT-G1 także
zostaje utracony. Jeżeli polecenie zostało wykonane bez
bezpiecznej wymiany komunikatów, wcześniejsze klucze
sesji bezpiecznej wymiany komunikatów nie są już
dostępne.
TCS_37 Komunikat polecenia
Bajt Długość Wartość Opis
CLA 1 „00h”
INS 1 „A4h”
P1 1 „04h” Wybór przez nazwę (AID)
P2 1 „0Ch” brak oczekiwanej odpowiedzi
Lc 1 „NNh” liczba bajtów wysłanych do karty (długość AID):
„06h” dla aplikacji tachograficznej
#6-#(5+NN) 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 — 21.08.2023 — 003.002 — 245
3.5.1.2 W y b ó r p l i k u e l e m e n t a r n e g o p r z y p o m o c y i d e n t y ­
f i k a t o r a p l i k u
TCS_39 Komunikat polecenia
TCS_40 Karta do tachografu musi obsługiwać bezpieczną wymianę
komunikatów 2. generacji, jak określono w dodatku 11
część B dla tego wariantu polecenia.
Bajt Długość Wartość Opis
CLA 1 „00h”
INS 1 „A4h”
P1 1 „02h” wybór EF pod bieżącym DF
P2 1 „0Ch” brak oczekiwanej odpowiedzi
Lc 1 „02h” liczba bajtów wysłanych do karty
#6-#7 2 „XXXXh” identyfikator pliku
Dla polecenia SELECT nie jest potrzebna żadna odpowiedź
(brak Le w T=1, bądź nie ma żądania odpowiedzi w T=0).
TCS_41 Komunikat odpowiedzi (brak żądania odpowiedzi)
Bajt Długość Wartość Opis
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli nie znaleziono pliku odpowiadającego identyfika­
torowi pliku, zwróconym stanem przetwarzania jest
„6A82”.
— W T=1, jeżeli jest bajt Le, zwróconym stanem jest
„6700”.
— W T=0, jeżeli po poleceniu SELECT wymaga się odpo­
wiedzi, zwróconym stanem jest „6900”.
▼M1
— Jeżeli wybrany plik uznany jest za uszkodzony (znale­
ziony błąd integralności w atrybutach pliku), zwró­
conym stanem przetwarzania jest „6400” lub „6500”.
▼B
3.5.2 READ BINARY
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego 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 — 21.08.2023 — 003.002 — 246
TCS_42 Komunikat polecenia
Bajt Długość Wartość Opis
CLA 1 „00h”
INS 1 „B0h” Odczyt binarny
P1 1 „XXh” Przesunięcie w bajtach od początku pliku: bajt najbar­
dziej znaczący
P2 1 „XXh” Przesunięcie w bajtach od początku pliku: bajt najmniej
znaczący
Le 1 „XXh” Długość oczekiwanych danych. Liczba bajtów do
odczytu.
Uwaga: bit 8 w P1 musi być ustawiony na 0.
TCS_43 Komunikat odpowiedzi
Bajt Długość Wartość Opis
#1-#X X „XX..XXh” Odczyt danych
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli nie wybrano EF, zwróconym stanem przetwa­
rzania jest „6986”.
— Jeżeli warunki zabezpieczenia wybranego pliku nie są
spełnione, polecenie zostaje przerwane z „6982”.
— Jeżeli przesunięcie nie jest zgodne z wielkością EF
(przesunięcie > wielkość EF), zwróconym stanem prze­
twarzania jest „6B00”.
— Jeżeli wielkość danych do odczytu nie jest zgodna
z wielkością EF (przesunięcie + Le > wielkość EF),
zwróconym stanem przetwarzania jest „6700” lub
„6Cxx”, gdzie „xx” wskazuje dokładną długość.
▼M1
— Jeżeli błąd integralności zostaje wykryty w atrybutach
pliku, karta uznaje, że plik jest uszkodzony i nienapra­
wialny, a zwróconym stanem przetwarzania jest „6400”
lub „6500”.
▼B
— Jeżeli błąd integralności zostaje wykryty w zgromadzo­
nych danych, karta zwraca żądane dane, a zwróconym
stanem przetwarzania jest „6281”.
3.5.2.1.1 P o l e c e n i e z b e z p i e c z n ą w y m i a n ą k o m u n i k a t ó w
( p r z y k ł a d y )
Polecenie to umożliwia IFD odczyt danych z bieżąco wybranego EF
z bezpieczną wymianą komunikatów w celu zweryfikowania integral­
ności odebranych danych oraz ochrony poufności danych, jeżeli 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 — 21.08.2023 — 003.002 — 247
Bajt Długość Wartość Opis
P1 1 „XXh” P1 (przesunięcie w bajtach od początku pliku): bajt
najbardziej znaczący
P2 1 „XXh” P2 (przesunięcie w bajtach od początku pliku): bajt
najmniej znaczący
Lc 1 „XXh” Długość danych wejściowych dla bezpiecznej wymiany
komunikatów
#6 1 „97h” T LE : znacznik specyfikacji oczekiwanej długości
#7 1 „01h” L LE : długość oczekiwanej długości
#8 1 „NNh” Specyfikacja oczekiwanej długości (początkowy Le):
liczba bajtów do odczytu
#9 1 „8Eh” T CC : znacznik kryptograficznej sumy kontrolnej
#10 1 „XXh” L CC : długość znajdującej się dalej kryptograficznej sumy
kontrolnej
„04h” dla bezpiecznej wymiany komunikatów 1. gene­
racji (zob. dodatek 11 część A)
„08h”, „0Ch” lub „10h”, w zależności od długości
klucza AES, dla bezpiecznej wymiany komunikatów 2.
generacji (zob. dodatek 11 część B)
#11-#(10+L) L „XX..XXh” Kryptograficzna suma kontrolna
Le 1 „00h” zgodnie ze specyfikacją w normie ISO/IEC 7816-4
TCS_45 Komunikat odpowiedzi, jeżeli SM-R-ENC-MAC-G1 (1.
generacja) / SM-R-ENC-MAC-G2 (2. generacja) nie są
wymagane oraz jeżeli format wejściowy bezpiecznej
wymiany komunikatów jest prawidłowy:
▼M1
Bajt
Długo­
ść
Wartość Opis
#1 1 „81h” T PV : znacznik wartości danych odkrytych
#2 L „NNh” lub
„81 NNh”
L PV : długość zwracanych danych (= począt­
kowemu Le).
L ma 2 bajty, jeżeli L PV >127 bajtów
#(2+L) - #(1+L+NN) 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 — 21.08.2023 — 003.002 — 248
Bajt
Długo­
ść
Wartość Opis
#(8+L+NN)-#(7+M+L+NN) M „XX..XXh” Kryptograficzna suma kontrolna
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
▼B
TCS_46 Komunikat odpowiedzi, jeżeli SM-R-ENC-MAC-G1 (1.
generacja) / SM-R-ENC-MAC-G2 (2. generacja) są
wymagane oraz jeżeli format wejściowy bezpiecznej
wymiany komunikatów jest prawidłowy:
▼M1
Bajt
Długo­
ść
Wartość Opis
#1 1 „87h” T PI CG : znacznik zaszyfrowanych danych
(kryptogram)
#2 L „MMh” lub
„81 MMh”
L PI CG : długość zwracanych zaszyfrowanych
danych (różna od początkowego Le z pole­
cenia, ze względu na wypełnienie)
L ma 2 bajty, jeżeli LPI CG > 127 bajtów
#(2+L)-#(1+L+MM) 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 — 21.08.2023 — 003.002 — 249
TCS_47 Komunikat odpowiedzi przy nieprawidłowym formacie
wejściowym bezpiecznej wymiany komunikatów
Bajt Długość Wartość Opis
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli klucz bieżącej sesji nie jest dostępny, zwracany
jest stan przetwarzania „6A88”. Zdarza się to
w sytuacji, gdy klucz sesyjny nie jest już generowany,
albo w sytuacji, gdy wygaśnie już ważność kluczy
sesyjnych (w tym przypadku IFD musi powtórnie
uruchomić proces wzajemnego uwierzytelnienia
w celu utworzenia nowego klucza sesyjnego).
— Jeżeli w formacie bezpiecznej wymiany komunikatów
brakuje pewnych oczekiwanych obiektów (określonych
powyżej), zwracany jest stan przetwarzania „6987”: ten
błąd ma miejsce, jeżeli brakuje oczekiwanego znacz­
nika lub jeżeli treść polecenia nie jest prawidłowo
skonstruowana.
— Jeżeli pewne obiekty danych są nieprawidłowe, zwró­
conym stanem przetwarzania jest „6988”: ten błąd ma
miejsce, jeżeli obecne są wszystkie wymagane znacz­
niki, ale niektóre długości różnią się od oczekiwanych.
— Jeżeli weryfikacja kryptograficznej sumy kontrolnej
wykaże niezgodność, zwróconym stanem przetwarzania
jest „6688”.
3.5.2.2 P o l e c e n i e z k r ó t k i m i i d e n t y f i k a t o r e m E F
( E l e m e n t a r y F i l e )
Ten wariant polecenia umożliwia IFD wybór EF przy pomocy krót­
kiego identyfikatora EF oraz odczyt danych z tego EF.
TCS_48 Karta do tachografu obsługuje ten wariant polecenia dla
wszystkich plików elementarnych z określonym krótkim
identyfikatorem EF. Przedmiotowe krótkie identyfikatory
EF zostały określone w rozdziale 4.
TCS_49 Komunikat polecenia
Bajt Długość Wartość Opis
CLA 1 „00h”
INS 1 „B0h” Odczyt binarny
P1 1 „XXh” Bit 8 ustawiany jest na 1.
Bity 7 i 6 ustawiane są na 00.
Bity 5 – 1 kodują krótki identyfikator EF odpowiedniego
EF.
P2 1 „XXh” Koduje przesunięcie od 0 do 255 bajtów w EF przywo­
łanym przez P1.
Le 1 „XXh” Długość oczekiwanych danych. Liczba bajtów do
odczytu.
Uwaga: Krótkie identyfikatory EF używane na potrzeby
aplikacji tachograficznej 2. generacji zostały określone
w rozdziale 4.
Jeżeli P1 koduje krótki identyfikator EF, a polecenie
zostało pomyślnie wykonane, ustalone EF staje się bieżąco
wybranym EF (bieżący EF).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 250
TCS_50 Komunikat odpowiedzi
Bajt Długość Wartość Opis
#1-#L L „XX..XXh” Odczyt danych
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli nie znaleziono pliku odpowiadającego krótkiemu
identyfikatorowi EF, zwróconym stanem przetwarzania
jest „6A82”.
— Jeżeli warunki zabezpieczenia wybranego pliku nie są
spełnione, polecenie zostaje przerwane z „6982”.
— Jeżeli przesunięcie nie jest zgodne z wielkością EF
(przesunięcie > wielkość EF), zwróconym stanem prze­
twarzania jest „6B00”.
— Jeżeli wielkość danych do odczytu nie jest zgodna
z wielkością EF (przesunięcie + Le > wielkość EF),
zwróconym stanem przetwarzania jest „6700” lub
„6Cxx”, gdzie „xx” wskazuje dokładną długość.
▼M1
— Jeżeli błąd integralności zostaje wykryty w atrybutach
pliku, karta uznaje, że plik jest uszkodzony i nienapra­
wialny, a zwróconym stanem przetwarzania jest „6400”
lub„6500”.
▼B
— Jeżeli błąd integralności zostaje wykryty w zgromadzo­
nych danych, karta zwraca żądane dane, a zwróconym
stanem przetwarzania jest „6281”.
3.5.2.3 P o l e c e n i e z n i e p a r z y s t y m b a j t e m i n s t r u k c j i
Ten wariant polecenia umożliwia IFD odczyt danych z EF, który 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 — 21.08.2023 — 003.002 — 251
IFD koduje długość przesuniętego obiektu danych
z możliwie najmniejszą liczbą oktetów, tzn. przy pomocy
bajtu długości „01h” IFD koduje przesunięcie od 0 do 255
bajtów, a przy pomocy bajtu długości „02h” koduje prze­
sunięcie od „256” do „65 535” bajtów.
▼M1
W przypadku gdy T=0, karta przyjmuje wartość Le =
„00h”, jeżeli nie stosuje się bezpiecznej wymiany komuni­
katów.
W przypadku gdy T = 1, zwróconym stanem przetwarzania
jest „6700”, jeżeli Le = „01h”.
▼B
TCS_53 Komunikat odpowiedzi
Bajt Długość Wartość Opis
#1-#L L „XX..XXh” Odczytane dane zapakowane do nieokreślonego obiektu
danych ze znacznikiem „53h”.
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli nie wybrano EF, zwróconym stanem przetwa­
rzania jest „6986”.
— Jeżeli warunki zabezpieczenia wybranego pliku nie są
spełnione, polecenie zostaje przerwane z „6982”.
— Jeżeli przesunięcie nie jest zgodne z wielkością EF
(przesunięcie > wielkość EF), zwróconym stanem prze­
twarzania jest „6B00”.
— Jeżeli wielkość danych do odczytu nie jest zgodna
z wielkością EF (przesunięcie + Le > wielkość EF),
zwróconym stanem przetwarzania jest „6700” lub
„6Cxx”, gdzie „xx” wskazuje dokładną długość.
▼M1
— Jeżeli błąd integralności zostaje wykryty w atrybutach
pliku, karta uznaje, że plik jest uszkodzony i nienapra­
wialny, a zwróconym stanem przetwarzania jest „6400”
lub „6500”.
▼B
— Jeżeli błąd integralności zostaje wykryty w zgromadzo­
nych danych, karta zwraca żądane dane, a zwróconym
stanem przetwarzania jest „6281”.
3.5.2.3.1 P o l e c e n i e z b e z p i e c z n ą w y m i a n ą k o m u n i k a t ó w
( p r z y k ł a d )
Poniższy przykład ilustruje stosowanie bezpiecznej wymiany 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 — 21.08.2023 — 003.002 — 252
Bajt Długość Wartość Opis
#6 1 „B3h” znacznik wartości danych odkrytych kodowanych
w BER-TLV
#7 1 „NNh” L PV : długość przesyłanych danych
#(8)-#(7+NN) 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.
generacji (zob. dodatek 11 część B)
#(13+NN)-
#(12+M+NN)
M „XX..XXh” Kryptograficzna suma kontrolna
Le 1 „00h” zgodnie ze specyfikacją w normie ISO/IEC 7816-4
TCS_55 komunikat odpowiedzi, jeżeli polecenie zostało pomyślnie
wykonane
Bajt Długość Wartość Opis
#1 1 „B3h” odkryte dane kodowane w BER-TLV
#2 L „NNh” lub
„81 NNh”
L PV : długość zwracanych danych (= początkowemu Le).
L ma 2 bajty, jeżeli L PV >127 bajtów
#(2+L)-
#(1+L+NN)
NN „XX..XXh” Wartość odkrytych danych kodowanych w BER-TLV, tj.
odczytane dane zapakowane do nieokreślonego obiektu
danych ze znacznikiem „53h”.
#(2+L+NN) 1 „99h” Stan przetwarzania niechronionej odpowiedzi APDU
#(3+L+NN) 1 „02h” Długość stanu przetwarzania
#(4+L+NN) –
#(5+L+NN)
2 „XX XXh” Stan przetwarzania niechronionej odpowiedzi APDU
#(6+L+NN) 1 „8Eh” T CC : znacznik kryptograficznej sumy kontrolnej
#(7+L+NN) 1 „XXh” L CC : długość znajdującej się dalej kryptograficznej sumy
kontrolnej
„08h”, „0Ch” lub „10h”, w zależności od długości
klucza AES, dla bezpiecznej wymiany komunikatów 2.
generacji (zob. dodatek 11 część B)
#(8+L+NN)-
#(7+M+L+
NN)
M „XX..XXh” Kryptograficzna suma kontrolna
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
3.5.3 UPDATE BINARY
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego 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 — 21.08.2023 — 003.002 — 253
3.5.3.1 P o l e c e n i e z p r z e s u n i ę c i e m w P 1 - P 2
Polecenie to umożliwia IFD zapis danych do bieżąco wybranego EF,
bez sprawdzenia przez kartę integralności otrzymanych danych.
Uwaga: Tego polecenia bez bezpiecznej wymiany komunikatów
można używać tylko do aktualizacji pliku, który wspiera warunek
zabezpieczenia ALW dla trybu dostępu do aktualizacji.
TCS_56 Komunikat polecenia
Bajt Długość Wartość Opis
CLA 1 „00h”
INS 1 „D6h” Aktualizacja binarna licznika
P1 1 „XXh” Przesunięcie w bajtach od początku pliku: bajt najbar­
dziej znaczący
P2 1 „XXh” Przesunięcie w bajtach od początku pliku: bajt najmniej
znaczący
Lc 1 „NNh” Lc długość aktualizowanych danych. Liczba zapisywa­
nych bajtów.
#6-#(5+NN) 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 — 21.08.2023 — 003.002 — 254
TCS_58 Komunikat polecenia
Bajt Długość Wartość Opis
CLA 1 „0Ch” Żądana bezpieczna wymiana komunikatów
INS 1 „D6h” Aktualizacja binarna licznika
P1 1 „XXh” Przesunięcie w bajtach od początku pliku:
bajt najbardziej znaczący
P2 1 „XXh” Przesunięcie w bajtach od początku pliku:
bajt najmniej znaczący
Lc 1 „XXh” długość chronionego pola danych
#6 1 „81h” T PV : znacznik wartości danych odkrytych
#7 L „NNh” lub
„81 NNh”
L PV : długość transmitowanych danych.
L ma 2 bajty, jeżeli L PV >127 bajtów.
#(7 + L)-
#(6 + L + NN)
NN „XX..XXh” wartość odkrytych danych (dane, które mają być zapi­
sane)
#(7 + L + NN) 1 „8Eh” T CC : znacznik kryptograficznej sumy kontrolnej
#(8 + L + NN) 1 „XXh” L CC : długość znajdującej się dalej kryptograficznej sumy
kontrolnej „04h” dla bezpiecznej wymiany komunikatów
1. generacji (zob. dodatek 11 część A)
„08h”, „0Ch” lub „10h”, w zależności od długości
klucza AES, dla bezpiecznej wymiany komunikatów 2.
generacji (zob. dodatek 11 część B)
#(9 + L + NN)-
#(8 + M + L +
NN)
M „XX..XXh” Kryptograficzna suma kontrolna
Le 1 „00h” zgodnie ze specyfikacją w normie ISO/IEC 7816-4
TCS_59 Komunikat odpowiedzi przy prawidłowym formacie
wejściowym bezpiecznej wymiany komunikatów
Bajt Długość Wartość Opis
#1 1 „99h” T SW : znacznik słów stanu (chroniony przez CC)
#2 1 „02h” L SW : długość zwracanego słowa stanu
#3-#4 2 „XXXXh” Stan przetwarzania niechronionej odpowiedzi APDU
#5 1 „8Eh” T CC : znacznik kryptograficznej sumy kontrolnej
#6 1 „XXh” L CC : długość znajdującej się dalej kryptograficznej sumy
kontrolnej
„04h” dla bezpiecznej wymiany komunikatów 1. gene­
racji (zob. dodatek 11 część A)
„08h”, „0Ch” lub „10h”, w zależności od długości
klucza AES, dla bezpiecznej wymiany komunikatów 2.
generacji (zob. dodatek 11 część B)
#7-#(6+L) L „XX..XXh” Kryptograficzna suma kontrolna
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
Stany „regularnego” przetwarzania, opisane dla polecenia
UPDATE BINARY z bezpieczną wymianą komunikatów
(zob. pkt 3.5.3.1), mogą być zwracane przy użyciu struk­
tury komunikatu odpowiedzi opisanej powyżej.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 255
Ponadto mogą wystąpić niektóre błędy, swoiście dotyczące
bezpiecznej wymiany komunikatów. W takim przypadku
zwracany jest po prostu stan przetwarzania bez struktury
bezpiecznej wymiany komunikatów:
TCS_60 Komunikat odpowiedzi w przypadku błędu
w bezpiecznej wymianie komunikatów
Bajt Długość Wartość Opis
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli klucz bieżącej sesji nie jest dostępny, zwracany
jest stan przetwarzania „6A88”.
— Jeżeli w formacie bezpiecznej wymiany komunikatów
brakuje pewnych oczekiwanych obiektów (określonych
powyżej), zwracany jest stan przetwarzania „6987”: ten
błąd ma miejsce, jeżeli brakuje oczekiwanego znacz­
nika lub jeżeli treść polecenia nie jest prawidłowo
skonstruowana.
— Jeżeli pewne obiekty danych są nieprawidłowe, zwró­
conym stanem przetwarzania jest „6988”: ten błąd ma
miejsce, jeżeli obecne są wszystkie wymagane znacz­
niki, ale niektóre długości różnią się od oczekiwanych.
— Jeżeli weryfikacja kryptograficznej sumy kontrolnej
wykaże niezgodność, zwróconym stanem przetwarzania
jest „6688”.
3.5.3.2 P o l e c e n i e z k r ó t k i m i i d e n t y f i k a t o r e m E F
Ten wariant polecenia umożliwia IFD wybór EF przy pomocy krót­
kiego identyfikatora EF oraz zapis danych z tego EF.
TCS_61 Karta do tachografu obsługuje ten wariant polecenia dla
wszystkich plików elementarnych z określonym krótkim
identyfikatorem EF. Przedmiotowe krótkie identyfikatory
EF zostały określone w rozdziale 4.
TCS_62 Komunikat polecenia
Bajt Długość Wartość Opis
CLA 1 „00h”
INS 1 „D6h” Aktualizacja binarna licznika
P1 1 „XXh” Bit 8 ustawiany jest na 1.
Bity 7 i 6 ustawiane są na 00.
Bity 5 – 1 kodują krótki identyfikator EF odpowiedniego
EF.
P2 1 „XXh” Koduje przesunięcie od 0 do 255 bajtów w EF przywo­
łanym przez P1.
Lc 1 „NNh” Lc długość aktualizowanych danych. Liczba zapisywa­
nych bajtów.
#6-#(5+NN) 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 — 21.08.2023 — 003.002 — 256
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli nie znaleziono pliku odpowiadającego krótkiemu
identyfikatorowi EF, zwróconym stanem przetwarzania
jest „6A82”.
— Jeżeli warunki zabezpieczenia wybranego pliku nie są
spełnione, polecenie zostaje przerwane z „6982”.
— Jeżeli przesunięcie nie jest zgodne z wielkością EF
(przesunięcie > wielkość EF), zwróconym stanem prze­
twarzania jest „6B00”.
— Jeżeli wielkość danych, które mają być zapisane, nie
jest zgodna z wielkością EF (przesunięcie + Lc > wiel­
kość EF), zwróconym stanem przetwarzania jest
„6700”.
▼M1
— Jeżeli błąd integralności zostaje wykryty w atrybutach
pliku, karta uznaje, że plik jest uszkodzony i nienapra­
wialny, a zwróconym stanem przetwarzania jest „6400”
lub „6500”.
▼B
— Jeżeli zapis nie jest wykonany pomyślnie, zwróconym
stanem przetwarzania jest „6581”.
3.5.3.3 P o l e c e n i e z n i e p a r z y s t y m b a j t e m i n s t r u k c j i
Ten wariant polecenia umożliwia IFD zapis danych do EF, który 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 pole­
cenia
#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 — 21.08.2023 — 003.002 — 257
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli nie wybrano EF, zwróconym stanem przetwa­
rzania jest „6986”.
— Jeżeli warunki zabezpieczenia wybranego pliku nie są
spełnione, polecenie zostaje przerwane z „6982”.
— Jeżeli przesunięcie nie jest zgodne z wielkością EF
(przesunięcie > wielkość EF), zwróconym stanem prze­
twarzania jest „6B00”.
— Jeżeli wielkość danych, które mają być zapisane, nie
jest zgodna z wielkością EF (przesunięcie + Lc > wiel­
kość EF), zwróconym stanem przetwarzania jest
„6700”.
— Jeżeli błąd integralności zostaje wykryty w atrybutach
pliku, karta uznaje, że plik jest uszkodzony i nienapra­
wialny, a zwróconym stanem przetwarzania jest „6400”
lub „6500”.
— Jeżeli zapis nie jest wykonany pomyślnie, zwróconym
stanem przetwarzania jest „6581”.
3.5.3.3.1 P o l e c e n i e z b e z p i e c z n ą w y m i a n ą k o m u n i k a t ó w
( p r z y k ł a d )
Poniższy przykład ilustruje stosowanie bezpiecznej wymiany 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.
generacji (zob. dodatek 11 część B)
#(9+L+NN)-
#(8+M+L+
NN)
M „XX..XXh” Kryptograficzna suma kontrolna
Le 1 „00h” zgodnie ze specyfikacją w normie ISO/IEC 7816-4
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 258
TCS_68 komunikat odpowiedzi, jeżeli polecenie zostało pomyślnie
wykonane
Bajt Długość Wartość Opis
#1 1 „99h” T SW : znacznik słów stanu (chroniony przez CC)
#2 1 „02h” L SW : długość zwracanego słowa stanu
#3-#4 2 „XXXXh” Stan przetwarzania niechronionej odpowiedzi APDU
#5 1 „8Eh” T CC : znacznik kryptograficznej sumy kontrolnej
#6 1 „XXh” L CC : długość znajdującej się dalej kryptograficznej sumy
kontrolnej
„08h”, „0Ch” lub „10h”, w zależności od długości
klucza AES, dla bezpiecznej wymiany komunikatów 2.
generacji (zob. dodatek 11 część B)
#7-#(6 + L) L „XX..XXh” Kryptograficzna suma kontrolna
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
3.5.4 GET CHALLENGE
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego 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 — 21.08.2023 — 003.002 — 259
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
polecenia.
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 — 21.08.2023 — 003.002 — 260
Bajt Długość Wartość Opis
P2 1 „00h” P2 (zweryfikowane CHV jest domniemanie znane)
Lc 1 „08h” długość przesyłanego kodu CHV
#6-#13 8 „XX..XXh” CHV
TCS_78 Komunikat odpowiedzi
Bajt Długość Wartość Opis
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli nie znaleziono referencyjnego CHV, zwróconym
stanem przetwarzania jest „6A88”.
— Jeżeli CHV jest zablokowane (licznik dozwolonych
prób CHV jest wyzerowany), zwróconym stanem prze­
twarzania jest „6983”. Po znalezieniu się w tym stanie
CHV nie może już nigdy być pomyślnie przekazane.
— Jeżeli porównanie wykaże niezgodność, licznik dozwo­
lonych prób CHV jest zmniejszany i zwracany jest stan
„63CX” (X > 0, gdzie X pokazuje stan licznika dozwo­
lonych prób CHV).
— Jeżeli referencyjne CHV uznane jest za uszkodzone,
zwróconym stanem przetwarzania jest „6400” lub
„6581”.
— Jeżeli Lc jest inne niż „08h”, zwracany jest stan prze­
twarzania „6700”.
3.5.6 GET RESPONSE
Polecenie to jest zgodne z normą ISO/IEC 7816-4.
Polecenia tego (niezbędnego i dostępnego tylko dla protokołu T=0)
używa się do przesyłania przygotowanych danych z karty do urzą­
dzenia interfejsu (przypadek, gdy polecenie zawiera oba 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 — 21.08.2023 — 003.002 — 261
TCS_80 Komunikat odpowiedzi
Bajt Długość Wartość Opis
#1-#X X „XX..XXh” dane
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli karta nie przygotuje żadnych danych, zwróconym
stanem przetwarzania jest „6900” lub „6F00”..
— Jeżeli Le przekracza liczbę dostępnych bajtów lub Le to
zero, zwróconym stanem przetwarzania jest „6Cxx”,
gdzie „xx” oznacza dokładną liczbę dostępnych bajtów.
W takim przypadku przygotowane dane pozostają
dostępne dla kolejnego polecenia GET RESPONSE.
— Jeżeli Le jest różne od zera i jest mniejsze od liczby
dostępnych bajtów, karta wysyła normalnie żądane
dane, a zwróconym stanem przetwarzania jest „61xx”,
gdzie „xx” oznacza liczbę dodatkowych bajtów jeszcze
dostępnych dla kolejnego polecenia GET RESPONSE.
— Jeżeli polecenie nie jest obsługiwane (protokół T=1),
karta zwraca „6D00”.
3.5.7 PSO: VERIFY CERTIFICATE
Polecenie to jest zgodne z normą ISO/IEC 7816-8, ale jego 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 — 21.08.2023 — 003.002 — 262
Bajt Długość Wartość Opis
P2 1 „AEh” P2: dane niekodowane w BER-TLV (konkatenacja
elementów danych)
Lc 1 „C2h” Lc: długość certyfikatu, 194 bajty
#6-#199 194 „XX..XXh” certyfikat: konkatenacja elementów danych (opisana
w dodatku 11)
TCS_85 Komunikat odpowiedzi
Bajt Długość Wartość Opis
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli weryfikacja certyfikatu nie uda się, zwróconym
stanem przetwarzania jest „6688”. Proces weryfikacji
i otwierania certyfikatu opisano w dodatku 11 dla 1.
generacji i 2. generacji.
— Jeżeli klucza publicznego nie ma w środowisku zabez­
pieczeń, zwróconym stanem przetwarzania jest „6A88”.
— Jeżeli wybrany klucz publiczny (użyty do otwierania
certyfikatu) uznany jest za uszkodzony, zwróconym
stanem przetwarzania jest „6400” lub „6581”.
— Wyłącznie 1. generacja: Jeżeli CHA.LSB
(
) wybranego klucza publicznego (użytego do otwierania
certyfikatu) różni się od „00” (tzn. nie jest kluczem
państwa członkowskiego lub Europy), zwróconym
stanem przetwarzania jest „6985”.
3.5.7.2 P a r a p o l e c e n i e – o d p o w i e d ź 2 . g e n e r a c j i
W zależności od wielkości krzywej certyfikaty ECC mogą być tak
długie, że nie mogą być przekazywane w jednym APDU. W takim
przypadku stosowany musi być łańcuch poleceń zgodny z ISO/IEC
7816-4, a certyfikat musi być przesyłany w dwóch kolejnych polece­
niach APDU PSO: Verify Certificate.
Struktura certyfikatu i parametry domeny zostały określone
w dodatku 11.
▼M3
TCS_86 Polecenie może być wykonywane w MF, w DF Tacho­
graph i w DF Tachograph_G2 (zob. również TCS_34).
▼B
TCS_87 Komunikat polecenia
Bajt Długość Wartość Opis
CLA 1 „X0h” bajt CLA wskazujący łańcuch poleceń:
„00h” – jedyne lub ostatnie polecenie łańcucha
„10h” – nieostatnie polecenie łańcucha
INS 1 „2Ah” wykonanie operacji zabezpieczającej
P1 1 „00h”
P2 1 „BEh” weryfikacja samoopisującego certyfikatu
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 263
Bajt Długość Wartość Opis
Lc 1 „XXh” długość pola danych dotyczących polecenia (zob.
TCS_88 oraz TCS_89).
#6-#5+L L „XX..XXh” dane kodowane w DER-TLV: Obiekt danych jednostki
certyfikującej ECC jako pierwszy obiekt danych konka­
tenowany z obiektem danych podpisu certyfikatu ECC
jako drugim obiektem danych lub jako częścią tej konka­
tenacji. Znacznik „7F21” i odpowiednia długość nie są
przekazywane.
Kolejność tych obiektów danych jest stała.
▼M3
TCS_88 W odniesieniu do APDU o krótkiej długości zastosowanie
mają następujące postanowienia: IFD musi wykorzystywać
minimalną liczbę APDU wymaganą do przesłania payloadu
polecenia oraz transmisji maksymalnej liczby bajtów
w pierwszym poleceniu APDU. Jednak każda wartość
„Lc” do 255 bajtów musi być obsługiwana przez kartę.
TCS_89 W odniesieniu do APDU o rozszerzonej długości zastoso­
wanie mają następujące postanowienia: jeżeli certyfikat nie
jest dopasowany do pojedynczego APDU, karta musi
obsługiwać łańcuch poleceń. IFD musi wykorzystywać
minimalną liczbę APDU wymaganą do przesłania payloadu
polecenia oraz transmisji maksymalnej liczby bajtów
w pierwszym poleceniu APDU. Jeżeli konieczne jest utwo­
rzenia łańcucha, każda wartość „Lc” do podanej maksy­
malnej wielkości rozszerzonej długości musi być obsługi­
wana przez kartę.
Uwaga: Zgodnie z dodatkiem 11 karta przechowuje certy­
fikat lub odpowiednie treści certyfikatu oraz uaktualnia
jego currentAuthenticatedTime.
Struktura komunikatu odpowiedzi i słowa stanu zostały
określone w TCS_85.
▼B
TCS_90 Oprócz kodów błędów wymienionych w TCS_85, karta
może zwracać następujące kody błędów:
— jeżeli CHA.LSB (CertificateHolderAuthorisation.equip­
mentType) wybranego klucza publicznego (użytego do
otwierania certyfikatu) nie jest odpowiednie dla weryfi­
kacji certyfikatu zgodnie z dodatkiem 11, zwróconym
stanem przetwarzania jest „6985”.
— Jeżeli currentAuthenticatedTime karty jest późniejszy
niż data upływu ważności certyfikatu, zwróconym
stanem przetwarzania jest „6985”.
— Jeżeli oczekiwane jest ostatnie polecenie łańcucha, karta
zwraca „6883”.
— Jeżeli nieprawidłowe parametry są wysyłane w polu
danych dotyczących polecenia, karta zwraca „6A80”
(także w przypadku, gdy obiekty danych nie są wysy­
łane w określonej kolejności).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 264
3.5.8 INTERNAL AUTHENTICATE
Polecenie to jest zgodne z normą ISO/IEC 7816-4.
TCS_91 Wszystkie karty do tachografów obsługują to polecenie
w DF Tachograph_G1. Polecenie może, ale nie musi być
dostępne w MF lub DF Tachograph_G2. W takim przy­
padku polecenie zostaje zakończone odpowiednim kodem
błędu, ponieważ klucz prywatny karty (Card.SK) dla proto­
kołu uwierzytelnienia 1. generacji jest dostępny tylko
w DF_Tachograph G1.
Używając polecenia INTERNAL AUTHENTICATE, IFD
może uwierzytelnić kartę. Proces uwierzytelnienia opisano
w dodatku 11. W procesie tym używa się następujących
instrukcji:
TCS_92 Polecenie INTERNAL AUTHENTICATE używa klucza
prywatnego karty (wybranego niejawnie) do podpisania
danych uwierzytelniających obejmujących K1 (pierwszy
element do uzgodnienia kluczy sesyjnych) i RND1,
a także używa bieżąco wybranego klucza publicznego
(w ostatnim poleceniu MSE) do zaszyfrowania podpisu
i utworzenia tokenu uwierzytelniania (dokładniej opisano
w dodatku 11).
TCS_93 Komunikat polecenia
Bajt Długość Wartość Opis
CLA 1 „00h” CLA
INS 1 „88h” INS
P1 1 „00h” 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 — 21.08.2023 — 003.002 — 265
— Jeżeli wybrany klucz prywatny uznany jest za uszko­
dzony, zwróconym stanem przetwarzania jest „6400”
lub „6581”.
▼M1
TCS_95 Jeżeli uwierzytelnienie poleceniem INTERNAL AUTHEN­
TICATE jest pomyślne, klucz bieżącej sesji 1. generacji
(o ile istnieje) zostaje skasowany i nie jest dalej dostępny.
W celu uzyskania nowego klucza sesji 1.generacji
konieczne jest pomyślne wykonanie uwierzytelnienia pole­
ceniem EXTERNAL AUTHENTICATE dla mechanizmu
uwierzytelnienia 1. generacji.
Uwaga: Zob. dodatek 11 pozycje CSM_193 i CSM_195
odnośnie do kluczy sesji 2. generacji. Jeżeli ustanowiono
klucze sesji 2. generacji, a karta do tachografu otrzymuje
odkryte polecenie APDU INTERNAL AUTHENTICATE,
przerywa sesję bezpiecznej wymiany komunikatów 2. gene­
racji i niszczy klucze sesji 2. generacji.
▼B
3.5.9 EXTERNAL AUTHENTICATE
Polecenie to jest zgodne z normą ISO/IEC 7816-4.
Poleceniem EXTERNAL AUTHENTICATE karta może uwierzytelnić
IFD. Proces uwierzytelnienia opisano w dodatku 11 dla tachografów
1. generacji i 2. generacji (uwierzytelnienie VU).
TCS_96 Wariant polecenia dla mechanizmu wzajemnego uwierzy­
telnienia 1. generacji jest obsługiwany jedynie przez apli­
kację tachograficzną 1. generacji.
▼M1
TCS_97 Wariant polecenia dla wzajemnego uwierzytelnienia VU –
karta drugiej generacji można wykonać w MF, DF Tacho­
graph i DF Tachograph_G2 (zob. również TCS_34). Jeżeli
uwierzytelnienie poleceniem 2. generacji EXTERNAL
AUTHENTICATE jest pomyślne, klucz bieżącej sesji 1.
generacji (o ile istnieje) zostaje skasowany i nie jest dalej
dostępny.
Uwaga: Zob. dodatek 11 pozycje CSM_193 i CSM_195
odnośnie do kluczy sesji 2. generacji. Jeżeli ustanowiono
klucze sesji 2. generacji, a karta do tachografu otrzymuje
odkryte polecenie APDU EXTERNAL AUTHENTICATE,
przerywa sesję bezpiecznej wymiany komunikatów 2. gene­
racji i niszczy klucze sesji 2. generacji.
▼B
TCS_98 Komunikat polecenia
Bajt Długość Wartość Opis
CLA 1 „00h” CLA
INS 1 „82h” INS
P1 1 „00h” klucze i algorytmy domniemanie znane
P2 1 „00h”
Lc 1 „XXh” Lc (długość danych wysłanych do karty)
#6-#(5+L) L „XX..XXh” uwierzytelnienie 1. generacji: kryptogram (zob. dodatek
11 część A)
uwierzytelnienie 2. generacji: podpis wygenerowany
przez IFD (zob. dodatek 11 część B)
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 266
TCS_99 Komunikat odpowiedzi
Bajt Długość Wartość Opis
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli CHA bieżąco ustawionego klucza publicznego
nie jest konkatenacją AID aplikacji tachograficznej
i typu urządzenia VU, zwróconym stanem przetwa­
rzania jest „6F00”.
— Jeżeli bezpośrednio przed poleceniem nie znajduje się
polecenie GET CHALLENGE, zwróconym stanem
przetwarzania jest „6985”.
Aplikacja tachograficzna 1. generacji może zwracać nastę­
pujące dodatkowe kody błędów:
— Jeżeli klucza publicznego nie ma w środowisku zabez­
pieczeń, zwróconym stanem przetwarzania jest „6A88”.
— Jeżeli klucza prywatnego nie ma w środowisku zabez­
pieczeń, zwróconym stanem przetwarzania jest „6A88”.
— Jeżeli weryfikacja kryptogramu daje zły wynik, zwró­
conym stanem przetwarzania jest „6688”.
— Jeżeli wybrany klucz prywatny uznany jest za uszko­
dzony, zwróconym stanem przetwarzania jest „6400”
lub „6581”.
Wariant polecenia dla uwierzytelnienia 2. generacji może
zwracać następujący dodatkowy kod błędu:
— Jeżeli podpis jest zweryfikowany negatywnie, karta
zwraca „6300”.
3.5.10 GENERAL AUTHENTICATE
Polecenie to jest używane na potrzeby protokołu 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.
▼M3
Le 1 „00h” zgodnie ze specyfikacją w normie ISO/IEC 7816-4
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 267
TCS_102 Komunikat odpowiedzi
Bajt Długość Wartość Opis
#1-#L L „7Ch” + L 7C + „81h”
+ „08h” +
„XX..XXh” + „82h”
+ L 82 + „XX..XXh”
dane dynamicznego uwierzytelniania kodowane
w DER-TLV: nonce i token uwierzytelniania
(zob. dodatek 11)
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Karta zwraca „6A80”, aby wskazać nieprawidłowe
parametry w polu danych.
— Karta zwraca „6982”, jeżeli uwierzytelnienie polece­
niem EXTERNAL AUTHENTICATE nie zostało
pomyślnie wykonane.
Obiekt danych dynamicznego uwierzytelnienia odpowiedzi
„7Ch”
— musi być obecny, jeżeli operacja została pomyślnie
wykonana, tzn. słowa stanu to „9000”,
— musi być nieobecny w przypadku błędu wykonania lub
błędu kontroli, tzn. jeśli słowa stanu mieszczą się
w zakresie „6400” – „6FFF”, oraz
— musi być nieobecny w przypadku ostrzeżenia, tzn. jeśli
słowa stanu mieszczą się w zakresie „6200” – „63FF”.
3.5.11 MANAGE SECURITY ENVIRONMENT
Poleceniem tym ustawia się klucz publiczny na potrzeby
uwierzytelnienia.
3.5.11.1 P a r a p o l e c e n i e – o d p o w i e d ź 1 . g e n e r a c j i
Polecenie to jest zgodne z normą ISO/IEC 7816-4. Zastosowanie 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
zresetowana.
TCS_105 Jeżeli powołanego klucza nie ma (już) na karcie, środo­
wisko zabezpieczeń pozostaje niezmienione.
TCS_106 Komunikat polecenia
Bajt Długość Wartość Opis
CLA 1 „00h” CLA
INS 1 „22h” INS
P1 1 „C1h” P1: powołany klucz ważny dla wszystkich czynności
kryptograficznych
P2 1 „B6h” P2 (powołane dane dotyczące podpisu cyfrowego)
Lc 1 „0Ah” Lc: długość następnego pola danych
#6 1 „83h” znacznik do powołanego klucza publicznego w przypad­
kach asymetrycznych
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 268
Bajt Długość Wartość Opis
#7 1 „08h” długość referencji klucza (identyfikator klucza)
#8-#15 8 „XX..XXh” identyfikator klucza określony w dodatku 11
TCS_107 Komunikat odpowiedzi
Bajt Długość Wartość Opis
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli powołany klucz nie znajduje się na karcie, zwró­
conym stanem przetwarzania jest „6A88”.
— Jeżeli niektórych oczekiwanych obiektów danych
brakuje w formacie bezpiecznej wymiany komuni­
katów, zwracany jest stan przetwarzania „6987”. To
może zdarzyć się, gdy brakuje znacznika „83h”.
— Jeżeli pewne obiekty danych są nieprawidłowe, zwró­
conym stanem przetwarzania jest „6988”. To może
zdarzyć się, gdy długość identyfikatora klucza różna
jest od „08h”.
— Jeżeli wybrany klucz uznany jest za uszkodzony, zwró­
conym stanem przetwarzania jest „6400” lub „6581”.
3.5.11.2 P a r y p o l e c e n i e – o d p o w i e d ź 2 . g e n e r a c j i
Jeśli chodzi o uwierzytelnienie 2. generacji, karta do 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 — 21.08.2023 — 003.002 — 269
3.5.11.2.2 M S E : S E T A T n a p o t r z e b y u w i e r z y t e l n i e n i a V U
Poniższego polecenia MSE:SET AT używa się do wyboru para­
metrów i kluczy na potrzeby uwierzytelnienia VU, które jest 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
pomijany).
Zob. dodatek 1 dla wartości identyfikatorów obiektu;
Stosuje się zapis bajtowy. Zob. dodatek 11 zawierający
wytyczne dotyczące sposobu wyboru jednego z tych
identyfikatorów obiektu.
„83h” +
„08h” +
„XX..XXh”
kodowane w DER-TL odniesienie klucza publicznego
VU przez Certificate Holder Reference wymienione
w jego certyfikacie
„91h” +
L 91 +
„XX..XXh”
kodowana w DER-TLV skompresowana reprezentacja
efemerycznego klucza publicznego VU do stosowania
podczas uwierzytelnienia mikroprocesora (zob. dodatek 11)
3.5.11.2.3 M S E : S E T D S T
Poniższego polecenia MSE:SET DST używa się do ustawienia klucza
publicznego
— albo do weryfikacji podpisu, który znajduje się w następnym 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 — 21.08.2023 — 003.002 — 270
Bajt Długość Wartość Opis
Lc 1 „NNh” Lc: długość następnego pola danych
#6-#(5+L) L „83h” +
„08h” +
„XX...XXh”
kodowane w DER-TLV odniesienie klucza publicznego,
tj. Certificate Holder Reference w certyfikacie klucza
publicznego (zob.dodatek 11)
Dla wszystkich wersji polecenia struktura komunikatu odpowiedzi
i słowa stanu podane są przez:
TCS_114 Komunikat odpowiedzi
Bajt Długość Wartość Opis
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”. Protokół został wybrany i zainicjo­
wany.
— „6A80” oznacza nieprawidłowe parametry w polu
danych dotyczących polecenia.
— „6A88” oznacza, że przywołane dane (tj. powołany
klucz) nie są dostępne.
▼M1
— Jeżeli currentAuthenticatedTime karty jest późniejszy
niż data upływu ważności wybranego klucza publicz­
nego, zwróconym stanem przetwarzania jest „6A88”.
Uwaga: W przypadku polecenia MSE: SET AT na
potrzeby uwierzytelnienia VU powołany klucz to klucz
publiczny VU_MA. Karta ustawia klucz publiczny
VU_MA do użytku, jeżeli jest on dostępny w jej pamięci,
który pokrywa się z odniesieniem do posiadacza certyfi­
katu (CHR) podanym w polu danych dotyczących pole­
cenia (karta może zidentyfikować klucze publiczne
VU_MA za pomocą pola CHA certyfikatu). Karta zwraca
„6A 88” temu poleceniu, w przypadku gdy jest dostępny
jedynie klucz publiczny VU_Sign lub nie jest dostępny
żaden klucz publiczny przyrządu rejestrującego. Zob. defi­
nicja pola CHA w dodatku 11 i typu danych equipment­
Type w dodatku 1.
Analogicznie w przypadku polecenia MSE: SET DST
odwołującego się do EQT (tzn. przyrządu rejestrującego
lub karty), które jest przesyłane do karty kontrolnej,
zgodnie z CSM_234 powołany klucz to zawsze klucz
EQT_Sign, który musi być stosowany na potrzeby weryfi­
kacji podpisu cyfrowego. Zgodnie z rys. 13 w dodatku 11
karta kontrolna będzie zawsze przechowywać odpowiedni
klucz publiczny EQT_Sign. W pewnych przypadkach karta
kontrolna może przechowywać odpowiadający klucz
publiczny EQT_MA. Karta kontrolna musi zawsze usta­
wiać klucz publiczny EQT_Sign do użytku, gdy otrzyma
polecenie MSE: SET DST.
▼B
3.5.12 PSO: HASH
Polecenia tego używa się do przesłania na kartę wyniku obliczeń
funkcji skrótu dla niektórych danych. Polecenia tego używa się do
weryfikowania podpisów cyfrowych. Wartość skrótu jest 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 — 21.08.2023 — 003.002 — 271
Tylko karta kontrolna jest zobowiązana obsługiwać to polecenie w DF
Tachograph i DF Tachograph_G2.
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować tego
polecenia. Polecenie może, ale nie musi być dostępne w MF.
Aplikacja karty kontrolnej 1. generacji obsługuje tylko SHA-1.
TCS_115 Tymczasowo zachowana wartość skrótu jest usuwana,
jeżeli nowa wartość skrótu zostaje obliczona za pomocą
polecenia PSO: HASH, jeżeli DF jest wybrany oraz jeżeli
karta do tachografu jest zresetowana.
TCS_116 Komunikat polecenia
Bajt Długość Wartość Opis
CLA 1 „00h” CLA
INS 1 „2Ah” wykonanie operacji zabezpieczającej
P1 1 „90h” zwróć kod skrótu
P2 1 „A0h” Znacznik: pole danych zawiera DO stosowne do obli­
czania skrótu
Lc 1 „XXh” Lc długość następnego pola danych
#6 1 „90h” znacznik dla kodu skrótu
#7 1 „XXh” długość L kodu skrótu:
„14h” dla aplikacji 1. generacji (zob. dodatek 11 część
A)
„20h”, „30h” lub „40h” dla aplikacji 2. generacji (zob.
dodatek 11 część B)
#8-#(7+L) L „XX..XXh” kod skrótu
TCS_117 Komunikat odpowiedzi
Bajt Długość Wartość Opis
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli brakuje niektórych oczekiwanych obiektów
danych (jak określone powyżej), zwracany jest stan
przetwarzania „6987”. To może zdarzyć się, jeżeli
brakuje jednego ze znaczników „90h”.
— Jeżeli pewne obiekty danych są nieprawidłowe, zwró­
conym stanem przetwarzania jest „6988”. Ten błąd
zdarza się, gdy wymagany znacznik jest obecny, ale
ma długość różną niż „14h” dla SHA-1, „20h” dla
SHA-256, „30h” dla SHA-384, „40h” dla SHA-512
(aplikacja 2. generacji).
3.5.13 PERFORM HASH of FILE
Polecenie to nie jest zgodne z normą ISO/IEC 7816-8. Tym samym
bajt CLA w tym poleceniu wskazuje na zastrzeżone użycie 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 — 21.08.2023 — 003.002 — 272
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować tego
polecenia. Jeżeli przedsiębiorstwo lub karta kontrolna realizują to
polecenie, odbywa się to zgodnie z opisem w niniejszym 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 — 21.08.2023 — 003.002 — 273
— Jeżeli wybrany plik EF uznany jest za uszkodzony
(błąd atrybutów pliku lub błąd integralności przechowy­
wanych danych), zwróconym stanem przetwarzania jest
„6400” lub „6581”.
— Jeżeli wybrany plik nie jest plikiem przezroczystym,
zwróconym stanem przetwarzania jest „6986”.
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE
▼M1
Polecenia tego używa się do obliczania podpisu cyfrowego z 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 — 21.08.2023 — 003.002 — 274
TCS_131 Komunikat odpowiedzi
Bajt Długość Wartość Opis
#1-#L L „XX..XXh” podpis uprzednio obliczonego skrótu
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli niejawnie wybrany klucz prywatny uznany jest za
uszkodzony, zwróconym stanem przetwarzania jest
„6400” lub „6581”.
— Jeżeli skrót, który został obliczony w ramach poprzed­
niego polecenia Perform Hash of File nie jest dostępny,
zwróconym stanem przetwarzania jest „6985”.
3.5.15 PSO: VERIFY DIGITAL SIGNATURE
Polecenia tego używa się do weryfikowania podpisu cyfrowego
dostarczanego jako dane wejściowe, którego skrót jest znany 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 — 21.08.2023 — 003.002 — 275
TCS_134 Komunikat odpowiedzi
Bajt Długość Wartość Opis
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— Jeżeli podpis jest zweryfikowany negatywnie, zwró­
conym stanem przetwarzania jest „6688”. Proces wery­
fikacji opisano w dodatku 11.
— Jeżeli nie wybrano klucza publicznego, zwróconym
stanem przetwarzania jest „6A88”.
— Jeżeli brakuje niektórych oczekiwanych obiektów
danych (jak określone powyżej), zwracany jest stan
przetwarzania „6987”. To może się zdarzyć, gdy
brakuje jednego z wymaganych znaczników.
— Jeżeli kod skrótu nie jest dostępny dla przetwarzania
polecenia (w wyniku poprzedniego polecenia PSO:
Hash), zwróconym stanem przetwarzania jest „6985”.
— Jeżeli pewne obiekty danych są nieprawidłowe, zwró­
conym stanem przetwarzania jest „6988”. To może się
zdarzyć, gdy długość jednego z wymaganych obiektów
danych jest nieprawidłowa.
— Jeżeli wybrany klucz publiczny uznany jest za uszko­
dzony, zwróconym stanem przetwarzania jest „6400”
lub „6581”.
▼M1
— Jeżeli wybrany klucz publiczny (używany do weryfi­
kacji podpisu cyfrowego) ma CHA.LSB (Certificate­
HolderAuthorisation.equipmentType), które nie jest
odpowiednie dla weryfikacji podpisu cyfrowego
zgodnie z dodatkiem 11, zwróconym stanem przetwa­
rzania jest „6985”.
▼B
3.5.16 PROCESS DSRC MESSAGE
Polecenia tego używa się do weryfikowania integralności i 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 — 21.08.2023 — 003.002 — 276
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 mecha­
nizmu szyfrowania znajdują się w dodatku 11 część B
rozdział 13.
Dozwolone wartości dla długości L 87 to wielokrotności
długości bloku AES plus 1 dla bajtu wskaźnika wypeł­
nienia, tj. od 17 bajtów do 193 bajtów włącznie.
Uwaga: zob. ISO/IEC 7816-4:2013 tabela 49 dla
obiektów danych SM ze znacznikiem „87h”.
„81h” + „10h” kodowany w DER-TLV referencyjny szablon kontrolny,
zagnieżdżający konkatenację następujących elementów
danych (zob. dodatek 1 DSRCSecurityData oraz dodatek
11 część B rozdział 13):
— 4-bajtowy znacznik czasu
— 3-bajtowy licznik
— 8-bajtowy numer seryjny VU
— 1-bajtowa wersja klucza głównego DSRC
Uwaga: zob. ISO/IEC 7816-4:2013 tabela 49 dla
obiektów danych SM ze znacznikiem „81h”.
„8Eh” + L 8E +
„XX..XXh”
Kodowany w DER-TLV MAC nad komunikatem DSRC.
Informacje dotyczące algorytmu i obliczania MAC znaj­
dują się w dodatku 11 część B rozdział 13.
Uwaga: zob. ISO/IEC 7816-4:2013 tabela 49 dla
obiektów danych SM ze znacznikiem „8Eh”.
▼M3
Le 1 „00h” zgodnie ze specyfikacją w normie ISO/IEC 7816-4
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 277
TCS_139 Komunikat odpowiedzi
Bajt Długość Wartość Opis
#1-#L L „XX..XXh” nieobecny (w przypadku błędu) lub dane odszyfrowane
(wypełnienie usunięte)
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli polecenie zostało pomyślnie wykonane, karta
zwraca „9000”.
— „6A80” oznacza nieprawidłowe parametry w polu
danych dotyczących polecenia (używane także w przy­
padku, gdy obiekty danych nie są wysyłane w okre­
ślonej kolejności).
— „6A88” oznacza, że przywołane dane nie są dostępne,
tzn. nie jest dostępny powołany klucz główny DSRC.
— „6900” oznacza, że nie udało się wykonać weryfikacji
kryptograficznej sumy kontrolnej lub odszyfrowywania
danych.
▼M1
— „6985” wskazuje, że 4-bajtowy znacznik czasu podany
w polu danych dotyczących polecenia jest wcześniejszy
niż cardValidityBegin lub późniejszy niż cardExpiry­
Date.
▼B
4. STRUKTURA KART DO TACHOGRAFÓW
W niniejszym punkcie opisano struktury plików na kartach do tacho­
grafów przeznaczonych do gromadzenia dostępnych danych.
Nie stanowi to opisu wewnętrznych struktur właściwych dla produ­
centa, takich jak nagłówki plików, ani sposobu gromadzenia
elementów danych tylko do użytku wewnętrznego (takich jak
, ,
lub ) i manipulowania tymi elementami danych.
TCS_140 Karta do tachografu 2. generacji jest hostem dla pliku głów­
nego MF oraz aplikacji tachograficznej 1. generacji i 2.
generacji tego samego typu (np. aplikacje karty kierowcy).
TCS_141 Karta do tachografu musi obsługiwać co najmniej minimalną
liczbę rekordów określoną dla odpowiednich aplikacji i nie
może obsługiwać więcej rekordów niż maksymalna liczba
rekordów określona dla odpowiednich aplikacji.
▼M3
Minimalne i maksymalne liczby rekordów zostały okre­
ślone w niniejszym rozdziale dla poszczególnych aplikacji.
W przypadku wersji 2 generacji 2 kart kierowcy i warsz­
tatowej aplikacja generacji 1 obsługuje maksymalną liczbę
rekordów określoną w TCS_150 i TCS_158.
▼B
Jeśli chodzi o warunki zabezpieczenia stosowane w zasa­
dach dostępu w niniejszym rozdziale, zob. rozdział 3.3.
Ogólnie tryb dostępu „odczyt” oznacza polecenie READ
BINARY z parzystym i (jeżeli obsługiwane) z nieparzystym
bajtem INS, z wyjątkiem EF Sensor_Installation_Data na
karcie warsztatowej (zob. TCS_156 i TCS_160). Tryb
dostępu „aktualizacja” oznacza polecenie Update Binary
z parzystym i (jeżeli obsługiwany) z nieparzystym bajtem
INS, a tryb dostępu „wybór” – polecenie SELECT.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 278
4.1. Plik główny MF
TCS_142 Po personalizacji plik główny MF ma następującą, trwałą
strukturę plików i zasady dostępu do plików:
Uwaga: The short EF identifier SFID podany jest jako
liczba dziesiętna, np. wartość 30 odpowiada zapisowi
11110 w systemie binarnym.
W tabeli zastosowano następujący skrót dla warunku
zabezpieczenia:
SC1 ALW OR SM-MAC-G2
TCS_143 Wszystkie struktury plików EF są przezroczyste.
TCS_144 Plik główny (MF) ma następującą strukturę danych:
TCS_145 Plik elementarny EF DIR zawiera następujące obiekty
danych dotyczące aplikacji: „61 08 4F 06 FF 54 41 43
48 4F 61 08 4F 06 FF 53 4D 52 44 54”
TCS_146 Plik elementarny EF ATR/INFO musi być obecny, jeżeli
karta do tachografu wskaże w swojej ATR, że obsługuje
pola o rozszerzonej długości. W takim przypadku EF ATR/
INFO zawiera obiekt danych z informacjami o rozszerzonej
długości (DO„7F66”) zgodnie z opisem w normie ISO/IEC
7816-4:2013 pkt 12.7.1.
TCS_147 Plik elementarny EF Extended_Length musi być obecny,
jeżeli karta do tachografu wskaże w swojej ATR, że obsłu­
guje pola o rozszerzonej długości. W takim przypadku EF
zawiera następujący obiekt danych: „02 01 xx”, gdzie
wartość „xx” wskazuje, czy pola o rozszerzonej długości
są obsługiwane dla protokołu T = 1 lub T = 0.
Wartość „01” oznacza obsługiwanie pola o rozszerzonej
długości dla protokołu T = 1.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 279
Wartość „10” oznacza obsługiwanie pola o rozszerzonej
długości dla protokołu T = 0.
Wartość „11” oznacza obsługiwanie pola o rozszerzonej
długości dla protokołu T = 1 i T = 0.
4.2. Aplikacje karty kierowcy
4.2.1 Aplikacja karty kierowcy 1. generacji
TCS_148 Po personalizacji aplikacja karty kierowcy 1. generacji ma
trwałą strukturę plików i zasady dostępu do plików, jak
określono poniżej:
W tabeli zastosowano następujące skróty dla warunków
bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
TCS_149 Wszystkie struktury plików EF są przezroczyste.
TCS_150 Aplikacja karty kierowcy 1. generacji ma następującą struk­
turę danych:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 280
► (1) (2) M3
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 281
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 282
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
▼M3
TCS_152 Po personalizacji aplikacja karty kierowcy 2. generacji ma
trwałą strukturę plików i zasady dostępu do plików, jak
określono poniżej:
Uwagi:
— Krótki identyfikator EF (SFID) podany jest jako liczba
dziesiętna, np. wartość 30 odpowiada zapisowi 11110
w systemie binarnym.
— Elementy: EF Application_Identification_V2, EF
Places_Authentication, EF GNSS_Places_Authentication,
EF Border_Crossings, EF Load_Unload_Operations, EF
VU_Configuration oraz EF Load_Type_Entries są obecne
tylko w wersji 2 generacji 2 kart kierowcy.
— cardStructureVersion w EF Application_Identification jest
równy {01 01} dla wersji 2 generacji 2 kart kierowcy,
natomiast jest równy {01 00} dla wersji 1 generacji 2
kart kierowcy.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 283
W tabeli zastosowano następujące skróty dla warunków
bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC5 Dla polecenia Read Binary z parzystym bajtem INS:
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
Dla polecenia Read Binary z nieparzystym bajtem
INS (jeżeli obsługiwane): NEV
▼B
TCS_153 Wszystkie struktury plików EF są przezroczyste.
▼M3
TCS_154 Aplikacja karty kierowcy 2. generacji ma następującą struk­
turę danych:
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 284
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 285
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 286
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:
▼M3
Min. Maks.
n 1 NoOfEventsPerType 12 12
n 2 NoOfFaultsPerType 24 24
n 3 NoOfCardVehicleRecords 200 200
n 4 NoOfCardPlaceRecords 112 112
n 6 CardActivityLengthRange 13776 bajtów
(56 dni * 117 zmian
czynności)
13776 bajtów
(56 dni * 117 zmian
czynności)
n 7 NoOfCardVehicleUnitRecords 200 200
n 8 NoOfGNSSADRecords 336 336
n 9 NoOfSpecificConditionRecords 112 112
n 10 NoOfBorderCrossingRecords 1120 1120
n 11 NoOfLoadUnloadRecords 1624 1624
n 12 NoOfLoadTypeEntryRecords 336 336
n 13 VuConfigurationLengthRange 3072 bajty 3072 bajty
▼B
4.3. Aplikacje karty warsztatowej
4.3.1 Aplikacja karty warsztatowej 1. generacji
TCS_156 Po personalizacji aplikacja karty warsztatowej 1. generacji
ma trwałą strukturę plików i zasady dostępu do plików, jak
określono poniżej.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 287
W tabeli zastosowano następujące skróty dla warunków
bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
▼M1
SC4 Dla polecenia READ BINARY z parzystym bajtem
INS:
(SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR
(SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)
Dla polecenia READ BINARY z nieparzystym
bajtem INS (jeżeli obsługiwane): NEV
▼B
TCS_157 Wszystkie struktury plików EF są przezroczyste.
TCS_158 Aplikacja karty warsztatowej 1. generacji ma następującą
strukturę danych:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 288
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 289
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 290
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
▼M3
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.
Uwagi:
— Krótki identyfikator EF (SFID) podany jest jako liczba
dziesiętna, np. wartość 30 odpowiada zapisowi 11110
w systemie binarnym.
— Elementy: EF Application_Identification_V2, EF
Places_Authentication, EF GNSS_Places_Authentica­
tion, EF Border_Crossings, EF Load_Unload_Opera­
tions, EF Load_Type_Entries, EF VU_Configuration
oraz EF Calibration_Add_Data są obecne tylko w wersji
2 generacji 2 kart warsztatowych.
— cardStructureVersion w EF Application_Identification
jest równy {01 01} dla wersji 2 generacji 2 kart warsz­
tatowych, natomiast jest równy {01 00} dla wersji 1
generacji 2 kart warsztatowych.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 291
W tabeli zastosowano następujące skróty dla warunków
bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC5 Dla polecenia Read Binary z parzystym bajtem INS:
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
Dla polecenia Read Binary z nieparzystym bajtem
INS (jeżeli obsługiwane): NEV
▼B
TCS_161 Wszystkie struktury plików EF są przezroczyste.
TCS_162 Aplikacja karty warsztatowej 2. generacji ma następującą
strukturę danych:
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 292
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 293
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 294
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 295
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 296
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:
▼M3
Min. Maks.
n 1 NoOfEventsPerType 3 3
n 2 NoOfFaultsPerType 6 6
n 3 NoOfCardVehicleRecords 8 8
n 4 NoOfCardPlaceRecords 8 8
n 5 NoOfCalibrationRecords 255 255
n 6 CardActivityLengthRange 492 bajty
(1 dzień * 240 zmian
czynności)
492 bajty
(1 dzień *240 zmian
czynności)
n 7 NoOfCardVehicleUnitRecords 8 8
n 8 NoOfGNSSADRecords 24 24
n 9 NoOfSpecificConditionRecords 4 4
n 10 NoOfBorderCrossingRecords 4 4
n 11 NoOfLoadUnloadRecords 8 8
n 12 NoOfLoadTypeEntryRecords 4 4
n 13 VuConfigurationLengthRange 3072 bajty 3072 bajty
▼B
4.4. Aplikacje karty kontrolnej
4.4.1 Aplikacja karty kontrolnej 1. generacji
TCS_164 Po personalizacji aplikacja karty kontrolnej 1. 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 — 21.08.2023 — 003.002 — 297
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
▼M3
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.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 298
Uwagi:
— krótki identyfikator EF (SFID) podany jest jako liczba
dziesiętna, np. wartość 30 odpowiada zapisowi 11110
w systemie binarnym.
— Elementy: EF Application_Identification_V2 oraz EF
VU_Configuration są obecne tylko w wersji 2 generacji
2 kart kontrolnych,
— cardStructureVersion w EF Application_Identification
jest równy {01 01} dla wersji 2 generacji 2 kart kontro­
lnych, natomiast jest równy {01 00} dla wersji 1 gene­
racji 2 kart kontrolnych.
W tabeli zastosowano następujące skróty dla warunków
bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC5 Dla polecenia Read Binary z parzystym bajtem
INS: SM-C-MAC-G2 AND SM-R-ENC-MAC-
G2
Dla polecenia Read Binary z nieparzystym
bajtem INS (jeżeli obsługiwane): NEV
▼B
TCS_169 Wszystkie struktury plików EF są przezroczyste.
TCS_170 Aplikacja karty kontrolnej 2. generacji ma następującą
strukturę danych:
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 299
▼B
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:
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 300
Min. Maks.
n 7 NoOfControlActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 ajty 3072 bajty
▼B
4.5. Aplikacje karty firmowej
4.5.1 Aplikacja karty firmowej 1. generacji
TCS_172 Po personalizacji aplikacja karty firmowej 1. generacji ma
trwałą strukturę plików i zasady dostępu do plików, jak
określono poniżej.
W tabeli zastosowano następujące skróty dla warunków
bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
SC6 EXT-AUT-G1 OR SM-MAC-G1 OR SM-MAC-G2
TCS_173 Wszystkie struktury plików EF są przezroczyste.
TCS_174 Aplikacja karty firmowej 1. generacji ma następującą struk­
turę danych:
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 301
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
▼M3
TCS_176 Po personalizacji aplikacja karty firmowej 2. generacji ma
trwałą strukturę plików i zasady dostępu do plików, jak
określono poniżej.
Uwagi:
— krótki identyfikator EF (SFID) podany jest jako liczba
dziesiętna, np. wartość 30 odpowiada zapisowi 11110
w systemie binarnym.
— Elementy: EF Application_Identification_V2 oraz EF
VU_Configuration są obecne tylko w wersji 2 generacji
2 kart firmowych,
— cardStructureVersion w EF Application_Identification
jest równy {01 01} dla wersji 2 generacji 2 kart firmo­
wych, natomiast jest równy {01 00} dla wersji 1 gene­
racji 2 kart firmowych.
W tabeli zastosowano następujące skróty dla warunków
bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC5 Dla polecenia Read Binary z parzystym bajtem
INS: SM-C-MAC-G2 AND SM-R-ENC-MAC-
G2
Dla polecenia Read Binary z nieparzystym
bajtem INS (jeżeli obsługiwane): NEV
▼B
TCS_177 Wszystkie struktury plików EF są przezroczyste.
TCS_178 Aplikacja karty firmowej 2. generacji ma następującą struk­
turę danych:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 302
▼B
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:
▼M3
Min. Maks.
n 8 NoOfCompanyActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 bajty 3072 bajty
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 303
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
02016R0799 — PL — 21.08.2023 — 003.002 — 304
Stany szczególne, wpisy wprowadzane ręcznie
poza zakresem
przeprawa promowa/pociągowa
operacja załadunku
operacja rozładunku
operacja równoczesnego załadunku/rozładunku
typ załadunku: pasażerowie
typ załadunku: towary
typ załadunku: nieokreślony typ załadunku
▼B
Różne
zdarzenia usterki
początek dziennego okresu pracy koniec dziennego okresu pracy
umiejscowienie
ręczne wprowadzenie czynności
kierowcy
▼M3
zabezpieczenie/uwierzytelnione dane/
plomby
▼B
prędkość
godzina
razem/podsumowanie
▼M3
mapa cyfrowa/przekroczenie granicy
▼B
Kwalifikatory
24h dobowo
tygodniowo
dwa tygodnie
od lub do
2. KOMBINACJE PIKTOGRAMÓW
Różne
miejsce kontroli
miejsce rozpoczęcia dzien­
nego okresu pracy
miejsce zakończenia dziennego
okresu pracy
▼M1
położenie po 3 godzinach skumulowa­
nego czasu prowadzenia pojazdu
▼B
od godziny do godziny
z pojazdu
początek poza zakresem koniec poza zakresem
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 305
pozycja, gdzie pojazd przekroczył
granicę między dwoma krajami
pozycja, gdzie miała miejsce operacja
załadunku
pozycja, gdzie miała miejsce operacja
rozładunku
pozycja, gdzie miała miejsce operacja
równoczesnego załadunku/rozładunku
▼B
Karty
karta kierowcy
karta firmowa
karta kontrolna
karta warsztatowa
brak karty
Prowadzenie pojazdu
załoga
czas prowadzenia w ciągu jednego tygodnia
czas prowadzenia w ciągu dwóch tygodni
Wydruki
wydruk dzienny czynności kierowcy z karty
wydruk dzienny czynności kierowcy z VU
wydruk zdarzeń i usterek z karty
wydruk zdarzeń i usterek z VU
wydruk danych technicznych
wydruk przekroczenia prędkości
▼M3
wydruk historii włożonych kart
▼B
Zdarzenia
włożenie nieważnej karty
konflikt kart
nakładające się czasy
prowadzenie pojazdu bez prawidłowej karty
włożenie karty podczas prowadzenia pojazdu
sesja ostatniej karty niezamknięta prawidłowo
przekroczenie prędkości
przerwa w zasilaniu
błąd danych dotyczących ruchu
konflikt ruchu pojazdu
naruszenie zabezpieczenia
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 306
konflikt czasu lub korekta czasu (w warsztacie)
▼B
kontrola przekroczenia prędkości
▼M1
brak informacji o pozycji z odbiornika GNSS lub błąd połączenia z urzą­
dzeniem zewnętrznym GNSS
błąd połączenia z urządzeniem do łączności na odległość
▼M3
anomalia GNSS
▼B
Usterki
usterka karty (szczelina karty kierowcy)
usterka karty (szczelina karty współkierowcy)
usterka wyświetlacza
usterka pobierania danych
usterka drukarki
usterka czujnika
usterka wewnętrzna VU
usterka GNSS
usterka urządzenia wykrywania na odległość
Procedura ręcznego wprowadzania danych
Czy nadal ten sam dzienny okres pracy?
Czy koniec poprzedniego okresu pracy?
potwierdź lub wprowadź miejsce zakończenia okresu pracy
wprowadź godzinę rozpoczęcia
wprowadź miejsce rozpoczęcia okresu pracy
Uwaga: dodatkowe kombinacje piktogramów używane do tworzenia
bloków wydruków lub identyfikatorów zapisów określono w dodatku 4.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 307
Dodatek 4
WYDRUKI
SPIS TREŚCI
1. ZASADY OGÓLNE
2. SPECYFIKACJA BLOKÓW DANYCH
3. SPECYFIKACJE WYDRUKU
3.1. Wydruk dzienny czynności kierowcy z karty
3.2. Wydruk dzienny czynności kierowcy z VU
3.3. Wydruk zdarzeń i usterek z karty
3.4. Wydruk zdarzeń i usterek z VU
3.5. Wydruk danych technicznych
3.6. Wydruk przekroczenia prędkości
3.7 Historia włożonych kart
1. ZASADY OGÓLNE
Wszystkie wydruki tworzy się poprzez zbudowanie łańcucha róż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.
▼M3
PRT_005 Pola danych tekstowych są drukowane z wyrównaniem do
lewej strony i wypełniane spacjami do długości danej pozycji
danych lub w razie potrzeby obcinane do długości danej
pozycji. Nazwy i adresy mogą być wydrukowane w dwóch
wierszach.
▼B
PRT_006 W przypadku łamania wiersza w związku z długością 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 — 21.08.2023 — 003.002 — 308
— 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
K
om
bi
na
cj
a
pi
kt
og
ra
m
ów

K
od
p
ań
st
w
a
w
yd
a-

ją
ce
go

Pierwsze 14 znaków numeru karty
(ewentualnie z numerem kolejnym)
N
um
er
w
ym
ia
ny

N
um
er
o
dn
ow
ie
ni
a
▼M3
— w bloku danych tekst po „pi=” odnosi się do odpowiedniego pikto­
gramu lub kombinacji piktogramów określonych w dodatku 3,
— w przypadku wydruku po długości i szerokości geograficznej zareje­
strowanej pozycji lub po znaczniku czasu, gdy pozycja została okre­
ślona, piktogram wskazuje, że pozycję tę obliczono na podstawie
uwierzytelnionych komunikatów nawigacyjnych,
— * dane dostępne tylko w tachografach GEN2 (wszystkie wersje),
— ** dane dostępne tylko w GEN2 wersja 2.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 309
PRT_007 W wydrukach korzysta się z następujących bloków danych lub
rekordów danych w opisanym poniżej znaczeniu i formacie:
► (1) (2) (3) (4) (5) M3
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 310
► (1) (2) (3) M3
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 311
► (1) (2) M3
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 312
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 313
► (1) (2) (3) (4) M3
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 314
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 315
► (1) M3
3. SPECYFIKACJE WYDRUKU
W tym rozdziale przyjęto następujące konwencje zapisu:
N Wydruk bloku lub rekordu o numerze N
N
Wydruk bloku lub rekordu o numerze N powtarzany tyle razy, ile jest
to niezbędne
X/Y
Wydruk bloków lub rekordów X lub Y w zależności od potrzeby
i powtórzenie tyle razy, ile jest to niezbędne
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 316
3.1. Wydruk dzienny czynności kierowcy z karty
▼M3
PRT_008 Wydruk dzienny czynności kierowcy z karty jest zgodny
z poniższym formatem:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 317
3.2. Wydruk dzienny czynności kierowcy z VU
▼M3
PRT_009 Wydruk dzienny czynności kierowcy z VU jest zgodny
z poniższym formatem:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 318
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
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
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 319
3.5. Wydruk danych technicznych
▼M3
PRT_012 Wydruk danych technicznych jest zgodny z poniższym
formatem:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 320
3.6. Wydruk przekroczenia prędkości
PRT_013 Wydruk przekroczenia prędkości jest zgodny z poniższym
formatem:
1 Data i godzina drukowania dokumentu
2 Typ wydruku
3
Identyfikacja posiadacza karty (dla wszystkich kart włożonych 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
PRT_014 Wydruk historii włożonych kart jest zgodny z poniższym
formatem:
▼M3
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 321
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 — 21.08.2023 — 003.002 — 322
Dodatek 6
PRZEDNIE ZŁĄCZE KALIBRACJI I POBIERANIA DANYCH
SPIS TREŚCI
1. SPRZĘT
1.1. Złącze
1.2. Rozmieszczenie styków
1.3. Schemat blokowy
2. INTERFEJS POBIERANIA DANYCH
3. INTERFEJS KALIBRACYJNY
1. SPRZĘT
1.1. Złącze
INT_001 Złącze pobierania danych/kalibracji jest złączem sześciopi­
nowym, dostępnym od strony panelu czołowego bez potrzeby
odłączania jakiejkolwiek części tachografu. Złącze musi mieć
wymiary zgodne z pokazanymi na rysunku poniżej (wszystkie
wymiary w milimetrach):
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 323
Na rysunku poniżej pokazano typową sześciopinową wtyczkę
złączną:
1.2. Rozmieszczenie styków
INT_002 Rozmieszczenie styków opisuje poniższa tabela:
Pin Wyszczególnienie Uwagi
1 minus akumulatora przyłączony do minusa akumulatora pojazdu
2 przesyłanie danych K-line (ISO 14230-1)
3 RxD – pobieranie danych dane wprowadzane do tachografu
4 sygnał we/wy kalibracja
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 324
Pin Wyszczególnienie Uwagi
5 stałe wyjście zasilania Zakres napięcia musi być taki jak dla zasilania pojazdu
minus 3V w celu umożliwienia spadku napięcia na obwo­
dzie ochronnym.
Wyjście 40 mA
6 TxD – pobieranie danych dane pobierane z tachografu
1.3. Schemat blokowy
INT_003 Schemat blokowy jest następujący:
2. INTERFEJS POBIERANIA DANYCH
INT_004 Interfejs pobierania danych musi być zgodny z 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 — 21.08.2023 — 003.002 — 325
3. Interfejs kalibracyjny
INT_007 Przesyłanie danych musi być zgodne z normą ISO 14230-1
Pojazdy drogowe – Systemy diagnostyczne – Protokół słów
kluczowych 2000 – część 1: Warstwa fizyczna (wydanie
pierwsze: 1999 r.).
INT_008 Sygnał we/wy musi być zgodny z następującymi 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 — 21.08.2023 — 003.002 — 326
Dodatek 7
PROTOKOŁY POBIERANIA DANYCH
SPIS TREŚCI
1. WPROWADZENIE
1.1. Zakres
1.2. Akronimy i skróty
2. POBIERANIE DANYCH Z VU
2.1. Procedura pobierania danych
2.2. Protokół pobierania danych
2.2.1 Struktura komunikatu
2.2.2 Typy komunikatów
2.2.2.1 Start Communication Request (SID 81)
2.2.2.2 Positive Response Start Communication (SID C1)
2.2.2.3 Start Diagnostic Session Request (SID 10)
2.2.2.4 Positive Response Start Diagnostic (SID 50)
2.2.2.5 Link Control Service (SID 87)
2.2.2.6 Link Control Positive Response (SID C7)
2.2.2.7 Request Upload (SID 35)
2.2.2.8 Positive Response Request Upload (SID 75)
2.2.2.9 Transfer Data Request (SID 36)
2.2.2.10 Positive Response Transfer Data (SID 76)
2.2.2.11 Request Transfer Exit (SID 37)
2.2.2.12 Positive Response Request Transfer Exit (SID 77)
2.2.2.13 Stop Communication Request (SID 82)
2.2.2.14 Positive Response Stop Communication (SID C2)
2.2.2.15 Acknowledge Sub Message (SID 83)
2.2.2.16 Negative Response (SID 7F)
2.2.3 Przepływ komunikatów
2.2.4 Przebiegi czasowe
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 327
2.2.5 Obsługa błędów
2.2.5.1 Faza rozpoczęcia komunikacji
2.2.5.2 Faza komunikacji
2.2.6 Treść komunikatu odpowiedzi
▼M3
2.2.6.1 Positive Response Transfer Data Download Interface Version (Pozy­
tywna odpowiedź na żądanie przesłania danych dotyczących wersji
interfejsu pobierania danych)
2.2.6.2 Positive Response Transfer Data Overview (Pozytywna odpowiedź na
żądanie przesłania danych przeglądowych)
2.2.6.3 Positive Response Transfer Data Activities (Pozytywna odpowiedź na
żądanie przesłania danych dotyczących czynności)
2.2.6.4 Positive Response Transfer Data Events and Faults (Pozytywna odpo­
wiedź na żądanie przesłania danych dotyczących zdarzeń i usterek)
2.2.6.5 Positive Response Transfer Data Detailed Speed (Pozytywna odpowiedź
na żądanie przesłania danych szczegółowych dotyczących prędkości)
2.2.6.6 Positive Response Transfer Data Technical Data (Pozytywna odpowiedź
na żądanie przesłania danych technicznych)
▼B
2.3. Gromadzenie plików na ESM
3. PROTOKÓŁ POBIERANIA DANYCH Z KART DO TACHO­
GRAFÓW
3.1. Zakres
3.2. Definicje
3.3. Pobieranie danych z karty
3.3.1 Sekwencja inicjalizująca
3.3.2 Sekwencja dla niepodpisanych plików danych
3.3.3 Sekwencja dla podpisanych plików danych
3.3.4 Sekwencja zerowania licznika kalibracji
3.4. Format gromadzenia danych
3.4.1 Wprowadzenie
3.4.2 Format pliku
4. POBIERANIE DANYCH Z KARTY DO TACHOGRAFU ZA
POŚREDNICTWEM PRZYRZĄDU REJESTRUJĄCEGO
1. WPROWADZENIE
Niniejszy dodatek zawiera procedury stosowane przy pobieraniu
danych różnych typów na zewnętrzny nośnik danych (ESM), wraz
z protokołami, które muszą być wdrożone w celu zagwarantowania
prawidłowego przesyłania danych i pełnej zgodności formatu 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 — 21.08.2023 — 003.002 — 328
— 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 — 21.08.2023 — 003.002 — 329
TLV [Tag Length Value] wartość długości znacznika
TREP [Transfer Response Parameter] parametr odpowiedzi na prze­
słanie danych
TRTP [Transfer Request Parameter] parametr żądania przesłania
danych
VU [Vehicle Unit] przyrząd rejestrujący
2. POBIERANIE DANYCH Z VU
2.1. Procedura pobierania danych
W celu pobrania danych z VU operator musi wykonać następujące
czynności:
— włożyć swoją kartę do tachografu do czytnika karty w VU (*);
— podłączyć IDE do gniazda pobierania w VU;
— nawiązać połączenie między IDE i VU;
— wybrać w IDE dane do pobrania i wysłać żądanie do VU;
— zamknąć sesję pobierania danych.
2.2. Protokół pobierania danych
Protokół skonstruowany jest zgodnie z zasadą nadrzędny-podległy,
gdzie IDE jest urządzeniem nadrzędnym a VU podległym.
Struktura komunikatu, typy komunikatów i przepływ są zasadniczo
oparte na Protokole słowa kluczowego 2000 (KWP) (według normy
ISO 14230-2 Pojazdy drogowe – Systemy diagnostyczne – Protokół
słowa kluczowego 2000 – część 2: Warstwa łącza danych).
Warstwa aplikacji zbudowana jest zasadniczo w oparciu o bieżący
projekt normy ISO 14229-1 (Pojazdy drogowe – Systemy diagno­
styczne – część 1: Usługi diagnostyczne, wersja 6 z dnia 22 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
docelowy (TGT), bajt źródłowy (SRC) i ewentualnie
bajt długości (LEN);
— pole danych zawierające bajt identyfikator usługi (SID)
i zmienną liczbę bajtów z danymi, w których może być
bajt opcjonalnej sesji diagnostycznej (DS_) lub bajt
opcjonalnego parametru przesyłania (TRTP lub TREP);
— suma kontrolna zawierająca bajt sumy kontrolnej (CS).
Nagłówek Pole danych Suma kontrolna
FMT TGT SRC LEN SID DATA … … … 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 — 21.08.2023 — 003.002 — 330
Bajt sumy kontrolnej jest ośmiobitową sumą serii modulo
256 wszystkich bajtów komunikatu, z wyłączeniem bajtu CS.
Bajty FMT, SID, DS_, TRTP i TREP są zdefiniowane
w dalszej części niniejszego dokumentu.
DDP_003 W przypadku gdy dane przesyłane komunikatem są dłuższe
niż dysponowane pole danych, komunikat wysyła się
w kilku podkomunikatach. Każdy podkomunikat ma
nagłówek, te same bajty SID i TREP oraz dwubajtowy
licznik podkomunikatu pokazujący liczbę podkomunikatów
w całym komunikacie. Aby umożliwić kontrolę błędów
i przerwanie przesyłania, IDE potwierdza każdy podkomu­
nikat. IDE może przyjmować podkomunikat, żądać powtó­
rzenia transmisji, żądać od VU powtórzenia transmisji od
początku lub przerwania transmisji.
DDP_004 Jeżeli ostatni podkomunikat ma dokładnie 255 bajtów w polu
danych, musi być dołączony końcowy podkomunikat
z pustym polem danych (z wyjątkiem SID TREP i licznika
podkomunikatów) w celu pokazania końca komunikatu.
Przykład:
Nagłówek SID TREP Komunikat 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 — 21.08.2023 — 003.002 — 331
2.2.2 Typy komunikatów
Protokół komunikacyjny pobierania danych między VU i IDE wymaga
wymiany komunikatów 8 różnych typów.
W tabeli poniżej opisano te komunikaty.
▼M3
Struktura komunikatu Maks. 4 bajty Maks. 255 bajtów 1 bajt
Nagłówek Dane
Suma
kontrolna
IDE ->
Żądanie rozpoczęcia transmisji 81 EE F0 81 E0
Pozytywna odpowiedź na żądanie
rozpoczęcia transmisji
80 F0 EE 03 C1 EA, 8F 9B
Żądanie rozpoczęcia sesji diagno­
stycznej
80 EE F0 02 10 81 F1
Pozytywna odpowiedź na żądanie
rozpoczęcia sesji diagnostycznej
80 F0 EE 02 50 81 31
Obsługa sterowania łączem
Weryfikacja szybkości transmisji (etap 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
Pozytywna odpowiedź na weryfikację
szybkości transmisji
80 F0 EE 02 C7 01 28
Zmiana szybkości transmisji (etap
2)
80 EE F0 03 87 02 03 ED
Żądanie wczytywania 80 EE F0 0A 35 00,00,00,00,
00,FF,FF,
FF,FF
99
Pozytywna odpowiedź na żądanie
wczytywania
80 F0 EE 03 75 00,FF D5
Żądanie przesłania danych
Wersja interfejsu pobierania
danych
80 EE F0 02 36 00 96
Przegląd 80 EE F0 02 36 01, 21 lub 31 CS
Czynności 80 EE F0 06 36 02, 22 lub 32 Data CS
Zdarzenia i usterki 80 EE F0 02 36 03, 23 lub 33 Data CS
Szczegółowe dane dotyczące pręd­
kości
80 EE F0 02 36 04 lub 24 Data CS
Dane techniczne 80 EE F0 02 36 05, 25 lub 35 Data CS
Pobieranie danych z karty 80 EE F0 02 lub 03 36 06 Szczelina
czytnika karty
CS
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 332
Struktura komunikatu Maks. 4 bajty Maks. 255 bajtów 1 bajt
Nagłówek Dane
Suma
kontrolna
IDE ->
Pozytywna odpowiedź na żądanie
przesłania danych
80 F0 EE Len 76 TREP Dane CS
Żądanie wyjścia z przesyłania danych 80 EE F0 01 37 96
Pozytywna odpowiedź na żądanie
wyjścia z przesyłania danych
80 F0 EE 01 77 D6
Żądanie zatrzymania transmisji 80 EE F0 01 82 E1
Pozytywna odpowiedź na żądanie
zatrzymania transmisji
80 F0 EE 01 C2 21
Potwierdzenie podkomunikatu 80 EE F0 Len 83 Dane CS
Odpowiedzi negatywne
Generalne odrzucenie 80 F0 EE 03 7F Sid Req 10 CS
Usługa nieobsługiwana 80 F0 EE 03 7F Sid Req 11 CS
Podfunkcja nieobsługiwana 80 F0 EE 03 7F Sid Req 12 CS
Nieprawidłowa długość komunikatu 80 F0 EE 03 7F Sid Req 13 CS
Nieprawidłowe warunki lub błąd
kolejności żądań
80 F0 EE 03 7F Sid Req 22 CS
Żądanie poza zakresem 80 F0 EE 03 7F Sid Req 31 CS
Ładowanie nieprzyjęte 80 F0 EE 03 7F Sid Req 50 CS
Oczekiwanie na odpowiedź 80 F0 EE 03 7F Sid Req 78 CS
Brak dostępnych danych 80 F0 EE 03 7F Sid Req FA CS
Uwagi:
— Sid Req = Sid odpowiadającego żądania.
— TREP = TRTP odpowiadającego żądania.
— Ciemne rubryki oznaczają, że nic nie jest przesyłane.
— Pojęcia „ładowanie” (z perspektywy IDE) używa się zgodnie
z normą ISO 14229. Oznacza to samo co pobieranie (z perspektywy
VU).
— W tabeli nie pokazano potencjalnych dwubajtowych liczników
podkomunikatów.
— „Szczelina” dotyczy numeru szczeliny: „1” (karta w szczelinie czyt­
nika karty kierowcy) albo „2” (karta w szczelinie czytnika 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.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 333
— TRTP 24 używa się w przypadku żądań pobrania danych z przy­
rządu rejestrującego generacji 2 (wersja 1 i wersja 2).
— TRTP 00, 31, 32, 33 i 35 używa się w przypadku żądań pobrania
danych z przyrządu rejestrującego generacji 2 (wersja 2).
— TRTP 21, 22, 23 i 25 używa się w przypadku żądań pobrania
danych z przyrządu rejestrującego generacji 2 (wersja 1).
— TRTP 01 do 05 używa się w przypadku żądań pobrania danych
z przyrządu rejestrującego generacji 1. Opcjonalnie mogą być one
akceptowane przez przyrząd rejestrujący generacji 2, ale tylko
w ramach kontroli kierowców przeprowadzanej przez organ
kontrolny spoza UE, przy użyciu karty kontrolnej pierwszej
generacji.
— TRTP 11 do 1F są zarezerwowane dla żądań pobrania swoistych
dla producenta.
▼B
2.2.2.1 S t a r t C o m m u n i c a t i o n R e q u e s t ( S I D 8 1 )
DDP_005 Komunikat ten wysyła IDE w celu zestawienia łącza komu­
nikacyjnego z VU. Początkowe komunikaty są zawsze
wysyłane z szybkością 9 600 bodów (aż do ewentualnej
zmiany szybkości transmisji przy wykorzystaniu odpowied­
niej obsługi sterowania łączem).
2.2.2.2 P o s i t i v e R e s p o n s e S t a r t C o m m u n i c a t i o n ( S I D C 1 )
DDP_006 Komunikat ten wysyła VU w celu przesłania pozytywnej
odpowiedzi na żądanie rozpoczęcia transmisji. Komunikat
zawiera 2 kluczowe bajty („EA” „8F”) wskazujące, że urzą­
dzenie obsługuje protokół z nagłówkiem zawierającym
informacje o adresie, źródle i długości.
2.2.2.3 S t a r t D i a g n o s t i c S e s s i o n R e q u e s t ( S I D 1 0 )
DDP_007 IDE wysyła komunikat „Start Diagnostic Session Request”
w celu zażądania nowej sesji diagnostycznej z VU. Podfun­
kcja „default session” (81 Hex) wskazuje, że IDE żąda
otwarcia standardowej sesji diagnostycznej.
2.2.2.4 P o s i t i v e R e s p o n s e S t a r t D i a g n o s t i c ( S I D 5 0 )
DDP_008 VU wysyła komunikat „Positive Response Start Diagnostic”
w celu przesłania pozytywnej odpowiedzi na żądanie „Diag­
nostic Session Request”.
2.2.2.5 L i n k C o n t r o l S e r v i c e ( S I D 8 7 )
DDP_052 IDE używa obsługi sterowania łączem do zainicjowania
zmiany szybkości transmisji w bodach. Odbywa się to
dwustopniowo. Najpierw IDE proponuje zmianę szybkości
transmisji podając nową szybkość (pierwszy krok). Po
otrzymaniu pozytywnej odpowiedzi od VU IDE wysyła do
VU potwierdzenie zmiany szybkości (drugi krok). Następnie
IDE przechodzi na nową szybkość transmisji. Po otrzymaniu
potwierdzenia VU przechodzi na nową szybkość transmisji.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 334
2.2.2.6 L i n k C o n t r o l P o s i t i v e R e s p o n s e ( S I D C 7 )
DDP_053 VU wysyła odpowiedź „Link Control Positive Response”
w celu przesłania pozytywnej odpowiedzi na żądanie
„Link Control Service” (pierwszy krok). Należy zwrócić
uwagę, że na żądanie potwierdzenia (drugi krok) nie ma
odpowiedzi.
2.2.2.7 R e q u e s t U p l o a d ( S I D 3 5 )
DDP_009 IDE wysyła komunikat „Request Upload” w celu przeka­
zania VU, że żądana jest operacja pobierania. Aby spełnić
wymagania normy ISO14229 przesyłane są szczegółowe
informacje dotyczące adresu, wielkości i szczegółów żąda­
nych danych. Ponieważ informacje te nie są znane IDE
przed pobieraniem, adres pamięci ustawiony jest na 0,
format jest nieszyfrowany i bez kompresji, a wielkość
pamięci ustawiona na maksimum.
2.2.2.8 P o s i t i v e R e s p o n s e R e q u e s t U p l o a d ( S I D 7 5 )
DDP_010 VU wysyła komunikat „Positive Response Request
Upload”, aby wskazać IDE, że VU jest gotowe do pobie­
rania danych. Aby spełnić wymagania normy ISO 14229 ten
komunikat pozytywnej odpowiedzi zawiera dane wskazujące
IDE, że dalsze komunikaty „Positive Response Transfer
Data” będą zawierały maksymalnie 00FF hex bajtów.
2.2.2.9 T r a n s f e r D a t a R e q u e s t ( S I D 3 6 )
▼M1
DDP_011 IDE wysyła żądanie „Transfer Data Request” w celu wska­
zania VU typu danych, które mają być pobierane. Jednobaj­
towy parametr „Transfer Request Parameter” (TRTP) wska­
zuje typ przesyłania.
▼M3
Rozróżnia się siedem typów przesyłania danych: Na
potrzeby pobierania danych z przyrządu rejestrującego dla
każdego typu transferu można użyć dwóch różnych wartości
TRTP:
Typ transferu danych
Wartość TRTP w przypadku
żądań pobrania danych z przy­
rządu rejestrującego typu 1.
generacji
Wartość TRTP w przypadku
żądań pobrania danych z przy­
rządu rejestrującego typu 2.
generacji (wersja 1)
Wartość TRTP w przypadku
żądań pobrania danych z przy­
rządu rejestrującego typu 2.
generacji (wersja 2)
Wersja interfejsu pobierania
danych
Nieużywany Nieużywany 00
Przegląd 01 21 31
Czynności o określonej dacie 02 22 32
Zdarzenia i usterki 03 23 33
Szczegółowe dane dotyczące
prędkości
04 24 24
Dane techniczne 05 25 35
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 335
Typ transferu
danych
Wartość TRTP
Pobieranie
danych z karty
06
▼M3
DDP_054 IDE musi obowiązkowo zażądać przesłania danych przeglą­
dowych (TRTP 01, 21 lub 31) w czasie sesji pobierania,
ponieważ tylko to zagwarantuje, że certyfikaty VU są
zarejestrowane w pobieranym pliku (i umożliwi weryfikację
podpisu cyfrowego).
W trzecim przypadku (TRTP 02, 22 lub 32) w komunikacie żądania
przesłania danych znajduje się informacja o dniu kalendarzowym
(format TimeReal), dla którego dane mają być pobrane.
▼B
2.2.2.10 P o s i t i v e R e s p o n s e T r a n s f e r D a t a ( S I D 7 6 )
DDP_012 VU wysyła pozytywną odpowiedź „Positive Response
Transfer Data” w odpowiedzi na żądanie „Transfer Data
Request”. Komunikat zawiera żądane dane z parametrem
„Transfer Response Parameter” (TREP) odpowiadającym
TRTP żądania.
▼M3
DDP_055 W pierwszym przypadku (TREP 01, 21 lub 31) VU wyśle
dane pomagające operatorowi IDE w wyborze danych, które
chce dalej pobrać. Komunikat ten zawiera następujące
informacje:
▼M1
— świadectwa bezpieczeństwa,
— identyfikacja pojazdu,
— bieżąca data i godzina VU,
— minimalna i maksymalna data, dla której można
dokonać pobrania (dane z VU),
— sygnalizacja obecności kart w VU,
— poprzednie pobranie dla firmy,
— blokady firmowe,
— poprzednie kontrole.
▼B
2.2.2.11 R e q u e s t T r a n s f e r E x i t ( S I D 3 7 )
DDP_013 IDE wysyła komunikat „Request Transfer Exit” w celu
zawiadomienia VU, że sesja pobierania jest zakończona.
2.2.2.12 P o s i t i v e R e s p o n s e R e q u e s t T r a n s f e r E x i t ( S I D 7 7 )
DDP_014 VU wysyła komunikat „Positive Response Request Transfer
Exit” w celu potwierdzenia otrzymania żądania wyjścia
z przesyłania danych „Request Transfer Exit”.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 336
2.2.2.13 S t o p C o m m u n i c a t i o n R e q u e s t ( S I D 8 2 )
DDP_015 IDE wysyła komunikat „Stop Communication Request”
w celu rozłączenia łącza komunikacyjnego z VU.
2.2.2.14 P o s i t i v e R e s p o n s e S t o p C o m m u n i c a t i o n ( S I D C 2 )
DDP_016 VU wysyła komunikat „Positive Response Stop Communi­
cation” w celu potwierdzenia otrzymania żądania „Stop
Communication Request”.
2.2.2.15 A c k n o w l e d g e S u b M e s s a g e ( S I D 8 3 )
DDP_017 IDE wysyła potwierdzenie podkomunikatu w celu potwier­
dzenia otrzymania każdej części komunikatu przesyłanego
w kilku podkomunikatach. W polu danych znajduje się
SID otrzymany z VU i dwubajtowy kod opisany poniżej:
— MsgC +1 potwierdza prawidłowy odbiór podkomunikatu
o numerze MsgC.
Żądanie od IDE dla VU wysłania następnego
podkomunikatu.
— MsgC wskazuje na problem z odbiorem podkomunikatu
o numerze MsgC.
Żądanie od IDE dla VU wysłania powtórnie następnego
podkomunikatu.
— FFFF żąda zakończenia komunikatu.
IDE może użyć tego do zakończenia transmisji komuni­
katu z VU z dowolnej przyczyny.
Ostatni podkomunikat komunikatu (bajt LEN
być potwierdzony przy pomocy dowolnego z tych kodów
lub być niepotwierdzony.
Odpowiedziami VU, które składają się z kilku podkomuni­
katów są:
— Positive Response Transfer Data (SID 76)
2.2.2.16 N e g a t i v e R e s p o n s e ( S I D 7 F )
DDP_018 VU wysyła komunikat „Negative Response” w odpowiedzi
na powyższe komunikaty żądań, gdy VU nie może obsłużyć
żądania. Pole danych komunikatu zawiera SID odpowiedzi
(7F), SID żądania i kod podający przyczynę negatywnej
odpowiedzi. Dozwolone są następujące kody:
— 10 generalne odrzucenie
Czynności nie można wykonać z przyczyny innej niż
określone poniżej.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 337
— 11 usługa nieobsługiwana
SID żądania nie jest zrozumiany.
— 12 podfunkcja nieobsługiwana
DS_ lub TRTP żądania nie jest zrozumiany lub nie ma
dalszych komunikatów do wysłania.
— 13 nieprawidłowa długość komunikatu
Długość odebranego komunikatu jest nieprawidłowa.
— 22 nieprawidłowe warunki lub błąd kolejności żądań
Żądana usługa nie jest aktywna lub sekwencja komuni­
katów żądań nie jest prawidłowa.
— 31 żądanie poza zakresem
Żądany rekord dotyczący parametru (pole danych) nie
jest ważny.
— 50 ładowanie nieprzyjęte
Żądania nie można obsłużyć (VU w nieodpowiednim
trybie pracy lub usterka wewnętrzna VU).
— 78 odpowiedź zawieszona
Czynności nie można zakończyć na czas i VU nie jest
gotowe do przyjęcia innego żądania.
▼M1
— FA brak dostępnych danych
Obiekt danych żądania transferu danych nie jest
dostępny w przyrządzie rejestrującym (np. karta nie
jest włożona, zażądano pobrania danych z przyrządu
rejestrującego typu generacji 1 poza ramami kontroli
kierowców przez organ kontrolny spoza UE ...).
▼B
2.2.3 Przepływ komunikatów
Typowy przepływ komunikatów podczas normalnej procedury pobie­
rania danych wygląda następująco:
IDE VU
Start Communication Request ⇨
⇦ Positive Response
Start Diagnostic Service Request ⇨
⇦ Positive Response
Request Upload ⇨
⇦ Positive Response
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 338
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
Acknowledge Sub Message (optional) ⇨
…
Transfer Data Request #n ⇨
⇦ Positive Response
Request Transfer Exit ⇨
⇦ Positive Response
Stop Communication Request ⇨
⇦ Positive Response
2.2.4 Przebiegi czasowe
DDP_019 Podczas normalnej pracy przebiegi czasowe wyglądają tak
jak na poniższym rysunku:
Rysunek 1
Przepływ komunikatów, przebiegi czasowe
Gdzie:
P1 = czas między bajtami dla odpowiedzi VU.
P2 = czas między końcem żądania IDE a początkiem odpo­
wiedzi VU, lub między końcem potwierdzenia IDE
a początkiem następnej odpowiedzi VU.
P3 = czas między końcem odpowiedzi VU a początkiem
nowego żądania IDE, bądź między końcem odpo­
wiedzi VU a początkiem potwierdzenia IDE, bądź
między końcem żądania IDE a początkiem nowego
żądania IDE, jeżeli VU nie odpowiada.
P4 = czas między bajtami dla żądania IDE.
P5 = przedłużona wartość P3 dla pobierania danych z karty.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 339
Dozwolone wartości przebiegów czasowych pokazano
w tabeli poniżej (KWP rozszerzony zestaw parametrów
przebiegów czasowych używany w przypadku adresowania
fizycznego w celu uzyskania szybszej komunikacji).
Parametr czasowy
Dolna wartość graniczna
(ms)
Górna wartość graniczna
(ms)
P1 0 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 — 21.08.2023 — 003.002 — 340
Rysunek 2
Obsługa błędów w VU
▼B
2. IDE WYKRYWA BŁĄD TRANSMISJI VU
DDP_025 Dla każdego odebranego komunikatu IDE wykrywa
błędy synchronizacji, błędy formatu bajtowego (np.
błędy bitów startu i stopu) i błędy ramki (zła liczba
odebranych bajtów, zły bajt sumy kontrolnej).
DDP_026 IDE wykrywa błędy kolejności, np. nieprawidłowe
zwiększenie stanu licznika podkomunikatów w kolejnych
komunikatach.
DDP_027 Jeżeli IDE wykrywa błąd lub nie ma odpowiedzi z VU
w okresie P2max, wysyła ponownie komunikat żądania,
z tym że mogą być maksymalnie trzy transmisje. Na
potrzeby tego wykrywania błędów VU traktuje potwier­
dzenie podkomunikatu jako żądanie.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 341
DDP_028 Przed rozpoczęciem każdej transmisji IDE oczekuje przez
okres P3min; okres oczekiwania odmierza się od ostat­
niego bitu stopu po wykryciu błędu.
Rysunek 3
Obsługa błędów w IDE
2.2.6 Treść komunikatu odpowiedzi
W tym punkcie określono treść pól danych w różnych komunikatach
pozytywnej odpowiedzi.
Elementy danych zdefiniowano w dodatku 1 „Słownik danych”.
Uwaga: W przypadku pobrań 2. generacji każdy element danych
najwyższego poziomu jest reprezentowany przez tablicę rekordów,
nawet jeśli zawiera tylko jeden rekord. Tablica rekordów zaczyna się
od nagłówka; nagłówek ten zawiera typ rekordu, wielkość rekordu
i liczbę rekordów. Tablice rekordów oznaczone są za pomocą
„…RecordArray” (z nagłówkiem) w poniższych tabelach.
▼M3
2.2.6.1 P o s i t i v e R e s p o n s e T r a n s f e r D a t a D o w n l o a d I n t e r ­
f a c e V e r s i o n ( P o z y t y w n a o d p o w i e d ź n a ż ą d a n i e
p r z e s ł a n i a d a n y c h d o t y c z ą c y c h w e r s j i i n t e r f e j s u
p o b i e r a n i a d a n y c h )
DDP_028a Pole danych w komunikacie „Positive Response Transfer
Data Download Interface Version” zawiera następujące
dane w określonej tu kolejności pod SID 76 Hex, TREP
00 Hex:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 342
Struktura danych generacji 2, wersja 2 (TREP 00 Hex)
Element danych Uwagi
DownloadInterfaceVersion Generacja i wersja VU: 02,02 Hex dla wersji 2
generacji 2.
Nieobsługiwany przez VU generacji 1 oraz wersji
1 generacji 2, które muszą reagować negatywnie
(podfunkcja nieobsługiwana, zob. DDP_018)
2.2.6.2 P o s i t i v e R e s p o n s e T r a n s f e r D a t a O v e r v i e w ( P o z y ­
t y w n a o d p o w i e d ź n a ż ą d a n i e p r z e s ł a n i a d a n y c h
p r z e g l ą d o w y c h )
DDP_029 Pole danych w komunikacie „Positive Response Transfer
Data Overview” zawiera następujące dane w określonej tu
kolejności pod SID 76 Hex, TREP 01, 21 lub 31 Hex,
z odpowiednim podziałem na podkomunikaty i licznikami:
Struktura danych generacji 1 (TREP 01 Hex)
Element danych Uwagi
MemberStateCertificate świadectwa bezpieczeństwa VU
VUCertificate
VehicleIdentificationNumber identyfikacja pojazdu
VehicleRegistrationIdentification
CurrentDateTime bieżąca data i godzina VU
VuDownloadablePeriod okres do pobrania
CardSlotsStatus typy kart włożonych do VU
VuDownloadActivityData poprzednie pobranie danych z VU
VuCompanyLocksData Wszystkie przechowywane blokady firmowe.
Jeżeli sekcja jest pusta, wysyłany jest jedynie
noOfLocks = 0.
VuControlActivityData Wszystkie rekordy dotyczące kontroli przechowy­
wane w VU. Jeżeli sekcja jest pusta, wysyłany
jest jedynie noOfControls = 0.
Signature Podpis RSA wszystkich danych (z wyjątkiem
certyfikatów), począwszy od elementu VehicleI­
dentificationNumber aż do ostatniego bajtu ostat­
niego elementu VuControlActivityData.
Struktura danych generacji 2, wersja 1 (TREP 21 Hex)
Element danych Uwagi
MemberStateCertificateRecordArray certyfikat państwa członkowskiego
VUCertificateRecordArray certyfikat VU
VehicleIdentificationNumberRecordArray identyfikacja pojazdu
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 343
Element danych Uwagi
VehicleRegistrationIdentificationRecordArray numer rejestracyjny pojazdu
CurrentDateTimeRecordArray bieżąca data i godzina VU
VuDownloadablePeriodRecordArray okres do pobrania
CardSlotsStatusRecordArray typy kart włożonych do VU
VuDownloadActivityDataRecordArray poprzednie pobranie danych z VU
VuCompanyLocksRecordArray Wszystkie przechowywane blokady firmowe.
Jeżeli sekcja jest pusta, wysyłany jest nagłówek
tablicy z noOfRecords = 0.
VuControlActivityRecordArray Wszystkie rekordy dotyczące kontroli przechowy­
wane w VU. Jeżeli sekcja jest pusta, wysyłany
jest nagłówek tablicy z noOfRecords = 0.
SignatureRecordArray Podpis ECC wszystkich poprzednich danych,
z wyjątkiem certyfikatów.
Struktura danych generacji 2, wersja 2 (TREP 31 Hex)
Element danych Uwagi
MemberStateCertificateRecordArray certyfikat państwa członkowskiego
VUCertificateRecordArray certyfikat VU
VehicleIdentificationNumberRecordArray identyfikacja pojazdu
VehicleRegistrationNumberRecordArray numer rejestracyjny pojazdu
CurrentDateTimeRecordArray bieżąca data i godzina VU
VuDownloadablePeriodRecordArray okres do pobrania
CardSlotsStatusRecordArray typy kart włożonych do VU
VuDownloadActivityDataRecordArray poprzednie pobranie danych z VU
VuCompanyLocksRecordArray Wszystkie przechowywane blokady firmowe.
Jeżeli sekcja jest pusta, wysyłany jest nagłówek
tablicy z noOfRecords = 0.
VuControlActivityRecordArray Wszystkie rekordy dotyczące kontroli przechowy­
wane w VU. Jeżeli sekcja jest pusta, wysyłany
jest nagłówek tablicy z noOfRecords = 0.
SignatureRecordArray Podpis ECC wszystkich poprzednich danych,
z wyjątkiem certyfikatów.
2.2.6.3 P o s i t i v e R e s p o n s e T r a n s f e r D a t a A c t i v i t i e s ( P o z y ­
t y w n a o d p o w i e d ź n a ż ą d a n i e p r z e s ł a n i a d a n y c h
d o t y c z ą c y c h c z y n n o ś c i )
DDP_030 Pole danych w komunikacie „Positive Response Transfer
Data Activities” zawiera następujące dane w określonej tu
kolejności pod SID 76 Hex, TREP 02, 22 lub 32 Hex,
z odpowiednim podziałem na podkomunikaty i licznikami:
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 344
Struktura danych generacji 1 (TREP 02 Hex)
Element danych Uwagi
TimeReal data pobieranego dnia
OdometerValueMidnight stan licznika kilometrów na koniec pobieranego dnia
VuCardIWData Dane dotyczące cykli wkładania wyjmowania kart.
— Jeżeli sekcja ta nie zawiera dostępnych danych,
wysyłany jest jedynie noOfVuCardIWRecords = 0.
— Jeżeli VuCardIWRecord wykracza poza 00:00
(włożenie karty poprzedniego dnia) lub poza
24:00 (wyjęcie karty następnego dnia), musi poja­
wiać się w pełni w ciągu dwóch odpowiednich dni.
VuActivityDailyData Stan szczelin o godzinie 00:00 i zmiany czynności zapi­
sane dla pobieranego dnia.
VuPlaceDailyWorkPeriodData Dane dotyczące miejsc zapisane dla pobieranego dnia.
Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfPla­
ceRecords = 0.
VuSpecificConditionData Dane dotyczące stanów szczególnych zapisane dla
pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany
jest jedynie noOfSpecificConditionRecords=0.
Signature Podpis RSA wszystkich danych, począwszy od
elementu TimeReal aż do ostatniego bajtu ostatniego
rekordu dotyczącego stanu szczególnego.
Struktura danych generacji 2, wersja 1 (TREP 22 Hex)
Element danych Uwagi
DateOfDayDownloadedRecordArray data pobieranego dnia
OdometerValueMidnightRecordArray stan licznika kilometrów na koniec pobieranego dnia
VuCardIWRecordArray Dane dotyczące cykli wkładania wyjmowania kart.
— Jeżeli ta sekcja nie zawiera dostępnych danych,
wysyłany jest nagłówek tablicy z noOfRecords = 0.
— Jeżeli VuCardIWRecord wykracza poza 00:00
(włożenie karty poprzedniego dnia) lub poza
24:00 (wyjęcie karty następnego dnia), musi poja­
wiać się w pełni w ciągu dwóch odpowiednich dni.
VuActivityDailyRecordArray Stan szczelin o godzinie 00:00 i zmiany czynności zapi­
sane dla pobieranego dnia.
VuPlaceDailyWorkPeriodRecordArray Dane dotyczące miejsc zapisane dla pobieranego dnia.
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy
z noOfRecords = 0.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 345
Element danych Uwagi
VuGNSSADRecordArray Pozycje GNSS dla pojazdu, jeżeli skumulowany czas
prowadzenia pojazdu osiągnie wielokrotność trzech
godzin. Jeżeli sekcja jest pusta, wysyłany jest nagłówek
tablicy z noOfRecords = 0.
VuSpecificConditionRecordArray Dane dotyczące stanów szczególnych zapisane dla
pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany
jest nagłówek tablicy z noOfRecords =0.
SignatureRecordArray Podpis ECC wszystkich poprzednich danych.
Struktura danych generacji 2, wersja 2 (TREP 32 Hex)
Element danych Uwagi
DateOfDayDownloadedRecordArray data pobieranego dnia
OdometerValueMidnightRecordArray stan licznika kilometrów na koniec pobieranego dnia
VuCardIWRecordArray Dane dotyczące cykli wkładania wyjmowania kart.
— Jeżeli ta sekcja nie zawiera dostępnych danych,
wysyłany jest nagłówek tablicy z noOfRecords = 0.
— Jeżeli VuCardIWRecord wykracza poza 00:00
(włożenie karty poprzedniego dnia) lub poza
24:00 (wyjęcie karty następnego dnia), musi poja­
wiać się w pełni w ciągu dwóch odpowiednich dni.
VuActivityDailyRecordArray Stan szczelin o godzinie 00:00 i zmiany czynności zapi­
sane dla pobieranego dnia.
VuPlaceDailyWorkPeriodRecordArray Dane dotyczące miejsc zapisane dla pobieranego dnia.
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy
z noOfRecords = 0.
VuGNSSADRecordArray Pozycje GNSS dla pojazdu, jeżeli skumulowany czas
prowadzenia pojazdu osiągnie wielokrotność trzech
godzin. Jeżeli sekcja jest pusta, wysyłany jest nagłówek
tablicy z noOfRecords = 0.
VuSpecificConditionRecordArray Dane dotyczące stanów szczególnych zapisane dla
pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany
jest nagłówek tablicy z noOfRecords =0.
VuBorderCrossingRecordArray Przekroczenia granicy dla pobranego dnia. Jeżeli sekcja
jest pusta, wysyłany jest nagłówek tablicy z noOfRe­
cords = 0.
VuLoadUnloadRecordArray Operacje załadunku/rozładunku dla pobranego dnia.
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy
z noOfRecords = 0.
SignatureRecordArray Podpis ECC wszystkich poprzednich danych.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 346
2.2.6.4 P o s i t i v e R e s p o n s e T r a n s f e r D a t a E v e n t s a n d F a u l t s
( P o z y t y w n a o d p o w i e d ź n a ż ą d a n i e p r z e s ł a n i a
d a n y c h d o t y c z ą c y c h z d a r z e ń i u s t e r e k )
DDP_031 Pole danych w komunikacie „Positive Response Transfer
Data Events and Faults” zawiera następujące dane w okre­
ślonej tu kolejności pod SID 76 Hex, TREP 03, 23 lub 33
Hex, z odpowiednim podziałem na podkomunikaty i liczni­
kami:
Struktura danych generacji 1 (TREP 03 Hex)
Element danych Uwagi
VuFaultData Wszystkie usterki przechowywane lub trwające w VU.
Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfVu­
Faults = 0.
VuEventData Wszystkie zdarzenia (z wyjątkiem przekroczenia pręd­
kości) przechowywane lub trwające w VU.
Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfVu­
Events = 0.
VuOverSpeedingControlData Dane dotyczące ostatniej kontroli przekroczenia pręd­
kości (wartość domyślna w przypadku braku danych).
VuOverSpeedingEventData Wszystkie zdarzenia dotyczące przekroczenia prędkości
przechowywane w VU.
Jeżeli sekcja jest pusta, wysyłany jest jedynie noOf­
VuOverSpeedingEvents = 0.
VuTimeAdjustmentData Wszystkie zdarzenia dotyczące korekty czasu przecho­
wywane w VU (poza ramami pełnej kalibracji).
Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfVu­
TimeAdjRecords = 0.
Signature Podpis RSA wszystkich danych, począwszy od noOf­
VuFaults aż do ostatniego bajtu ostatniego rekordu
dotyczącego korekty czasu.
Struktura danych generacji 2, wersja 1 (TREP 23 Hex)
Element danych Uwagi
VuFaultRecordArray Wszystkie usterki przechowywane lub trwające w VU.
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy
z noOfRecords = 0.
VuEventRecordArray Wszystkie zdarzenia (z wyjątkiem przekroczenia pręd­
kości) przechowywane lub trwające w VU.
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy
z noOfRecords = 0.
VuOverSpeedingControlDataRecordArray Dane dotyczące ostatniej kontroli przekroczenia pręd­
kości (wartość domyślna w przypadku braku danych).
VuOverSpeedingEventRecordArray Wszystkie zdarzenia dotyczące przekroczenia prędkości
przechowywane w VU.
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy
z noOfRecords = 0.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 347
Element danych Uwagi
VuTimeAdjustmentRecordArray Wszystkie zdarzenia dotyczące korekty czasu przecho­
wywane w VU (poza ramami pełnej kalibracji).
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy
z noOfRecords = 0.
SignatureRecordArray Podpis ECC wszystkich poprzednich danych.
Struktura danych generacji 2, wersja 2 (TREP 33 Hex)
Element danych Uwagi
VuFaultRecordArray Wszystkie usterki przechowywane lub trwające w VU.
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy
z noOfRecords = 0.
VuEventRecordArray Wszystkie zdarzenia (z wyjątkiem przekroczenia pręd­
kości) przechowywane lub trwające w VU.
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy
z noOfRecords = 0.
VuOverSpeedingControlDataRecordArray Dane dotyczące ostatniej kontroli przekroczenia pręd­
kości (wartość domyślna w przypadku braku danych).
VuOverSpeedingEventRecordArray Wszystkie zdarzenia dotyczące przekroczenia prędkości
przechowywane w VU.
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy
z noOfRecords = 0.
VuTimeAdjustmentRecordArray Wszystkie zdarzenia dotyczące korekty czasu przecho­
wywane w VU (poza ramami pełnej kalibracji).
Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy
z noOfRecords = 0.
SignatureRecordArray Podpis ECC wszystkich poprzednich danych.
2.2.6.5 P o s i t i v e R e s p o n s e T r a n s f e r D a t a D e t a i l e d S p e e d
( P o z y t y w n a o d p o w i e d ź n a ż ą d a n i e p r z e s ł a n i a
d a n y c h s z c z e g ó ł o w y c h d o t y c z ą c y c h p r ę d k o ś c i )
DDP_032 Pole danych w komunikacie „Positive Response Transfer
Data Detailed Speed” zawiera następujące dane w okre­
ślonej tu kolejności pod SID 76 Hex, TREP 04 lub 24
Hex, z odpowiednim podziałem na podkomunikaty i liczni­
kami:
Struktura danych generacji 1 (TREP 04 Hex)
Element danych Uwagi
VuDetailedSpeedData Wszystkie szczegółowe dane dotyczące prędkości prze­
chowywane w VU (jeden blok prędkości dla minuty,
przez którą pojazd był w ruchu).
60 wartości prędkości na minutę (jedna na sekundę).
Signature Podpis RSA wszystkich danych, począwszy od noOf­
SpeedBlocks aż do ostatniego bajtu ostatniego bloku
prędkości.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 348
Struktura danych generacji 2 (TREP 24 Hex)
Element danych Uwagi
VuDetailedSpeedBlockRecordArray Wszystkie szczegółowe dane dotyczące prędkości prze­
chowywane w VU (jeden blok prędkości dla minuty,
przez którą pojazd był w ruchu).
60 wartości prędkości na minutę (jedna na sekundę).
SignatureRecordArray Podpis ECC wszystkich poprzednich danych.
2.2.6.6 P o s i t i v e R e s p o n s e T r a n s f e r D a t a T e c h n i c a l D a t a
( P o z y t y w n a o d p o w i e d ź n a ż ą d a n i e p r z e s ł a n i a
d a n y c h t e c h n i c z n y c h )
DDP_033 Pole danych w komunikacie „Positive Response Transfer
Data Technical Data” zawiera następujące dane w określonej
tu kolejności pod SID 76 Hex, TREP 05, 25 lub 35 Hex,
z odpowiednim podziałem na podkomunikaty i licznikami:
Struktura danych generacji 1 (TREP 05 Hex)
Element danych Uwagi
VuIdentification
SensorPaired
VuCalibrationData Wszystkie rekordy dotyczące kalibracji przechowywane
w VU.
Signature Podpis RSA wszystkich danych, począwszy od vuMa­
nufacturerName aż do ostatniego bajtu ostatniego
VuCalibrationRecord.
Struktura danych generacji 2, wersja 1 (TREP 25 Hex)
Element danych Uwagi
VuIdentificationRecordArray
VuSensorPairedRecordArray Wszystkie sparowania państw członkowskich przecho­
wywane w VU.
VuSensorExternalGNSSCoupledRecor­
dArray
Wszystkie powiązania urządzenia zewnętrznego GNSS
przechowywane w VU.
VuCalibrationRecordArray Wszystkie rekordy dotyczące kalibracji przechowywane
w VU.
VuCardRecordArray Wszystkie dane dotyczące włożenia karty przechowy­
wane w VU.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray Podpis ECC wszystkich poprzednich danych.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 349
Struktura danych generacji 2, wersja 2 (TREP 35 Hex)
Element danych Uwagi
VuIdentificationRecordArray
VuSensorPairedRecordArray Wszystkie sparowania państw członkowskich przecho­
wywane w VU.
VuSensorExternalGNSSCoupledRecor­
dArray
Wszystkie powiązania urządzenia zewnętrznego GNSS
przechowywane w VU.
VuCalibrationRecordArray Wszystkie rekordy dotyczące kalibracji przechowywane
w VU.
VuCardRecordArray Wszystkie dane dotyczące włożenia karty przechowy­
wane w VU.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray Podpis ECC wszystkich poprzednich danych.
▼B
2.3. Gromadzenie plików na ESM
DDP_034 Jeżeli sesja pobierania obejmuje przesłanie danych z VU,
IDE w jednym fizycznym pliku przechowuje wszystkie
dane odebrane z VU w czasie tej sesji przesłane z komuni­
katami „Positive Response Transfer Data”. Dane przecho­
wuje się bez nagłówków komunikatów, liczników podko­
munikatów, pustych podkomunikatów i sum kontrolnych,
ale wraz z SID i TREP (tylko pierwszego podkomunikatu
w przypadku kilku podkomunikatów).
3. PROTOKÓŁ POBIERANIA DANYCH Z KART DO TACHO­
GRAFÓW
3.1. Zakres
W tym punkcie opisano bezpośrednie pobieranie danych z karty do
tachografu do IDE. IDE nie jest częścią bezpiecznego środowiska;
dlatego też nie wykonuje się uwierzytelnienia między kartą a 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).
Podpisany plik danych: Plik z karty ICC. Plik przesyła
się do IFD w formie odkrytego
tekstu. Na karcie ICC skrót
pliku jest obliczany i podpisy­
wany, a podpis jest przesyłany
do IFD.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 350
3.3. Pobieranie danych z karty
▼M3
DDP_035 Pobieranie danych z karty do tachografu obejmuje następu­
jące kroki:
— Pobieranie wspólnych informacji zawartych na karcie
w plikach EF ICC oraz IC. Dane te są nieobowiązkowe
i nie są chronione podpisem cyfrowym.
— W przypadku kart do tachografów pierwszej i drugiej
generacji
— Pobieranie w plikach EF w Tachograph DF:
— Wczytanie plików EF Card_Certificate i CA_Certifi­
cate. Dane te nie są chronione podpisem cyfrowym.
Pobranie tych plików jest obowiązkowe dla
każdej sesji pobierania.
— Wczytanie plików EF zawierających inne dane
aplikacyjne (w DF Tachograph) z wyłączeniem
EF Card_Download. Informacje takie są zabez­
pieczone podpisem cyfrowym przy użyciu
wspólnych mechanizmów zabezpieczenia okre­
ślonych w dodatku 11 część A.
— Pobranie przynajmniej plików EF Applica­
tion_Identification oraz Identification jest
obowiązkowe dla każdej sesji pobierania.
— Przy pobieraniu danych z karty kierowcy
obowiązkowe jest pobranie także następujących
plików EF:
Events_Data,
Faults_Data,
Driver_Activity_Data,
Vehicles_Used,
Places,
Control_Activity_Data,
Specific_Conditions.
— Wyłącznie w przypadku kart do tachografów drugiej
generacji:
— Z wyjątkiem sytuacji gdy pobranie danych z karty
kierowcy włożonej do przyrządu rejestrującego
odbywa się w trakcie kontroli kierowców przeprowa­
dzanej przez organ kontrolny spoza UE przy użyciu
karty kontrolnej pierwszej generacji, pobieranie
w plikach EF Tachograph_G2 DF:
— Pobieranie w plikach EF CardSignCertificate,
CA_Certificate oraz Link_Certificate. Dane te
nie są chronione podpisem cyfrowym.
— Pobranie tych plików jest obowiązkowe dla
każdej sesji pobierania.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 351
— Wczytanie plików EF zawierających inne dane
aplikacyjne (w Tachograph_G2 DF) z wyłącze­
niem EF Card_Download. Informacje takie są
zabezpieczone podpisem cyfrowym przy użyciu
wspólnych mechanizmów zabezpieczenia okre­
ślonych w dodatku 11 część B.
— Pobranie przynajmniej plików EF: Applica­
tion_Identification, Application_Identifica­
tion_V2 (jeżeli występuje) oraz Identification
jest obowiązkowe dla każdej sesji pobierania.
— Przy pobieraniu danych z karty kierowcy
obowiązkowe jest pobranie także następujących
plików EF:
Events_Data,
Faults_Data,
Driver_Activity_Data,
Vehicles_Used,
Places,
Control_Activity_Data,
Specific_Conditions,
VehicleUnits_Used,
GNSS_Places,
Places_Authentication, jeżeli występuje,
GNSS_Places_Authentication, jeżeli występuje,
Border_Crossings, jeżeli występuje,
Load_Unload_Operations, jeżeli występuje,
Load_Type_Entries, jeżeli występuje.
— Przy wczytywaniu danych z karty kierowcy
aktualizowana jest data LastCardDownload
w pliku EF Card_Download, w DF Tachograph
i, w stosownych przypadkach, Tachograph_G2.
— Przy pobieraniu danych z karty warsztatowej
zerowany jest licznik kalibracji w pliku EF
CardDownload w DF Tachograph i, w stosow­
nych przypadkach, Tachograph_G2.
— Przy pobieraniu danych z karty warsztatowej
pliki EF Sensor_Installation_Data w DF Tacho­
graph i, w stosownych przypadkach, Tacho­
graph_G2 nie mogą być pobierane.
▼B
3.3.1 Sekwencja inicjalizująca
DDP_036 IDE inicjuje następującą sekwencję:
Karta Kierunek IDE/IFD Znaczenie/Uwagi
⇦ restart sprzętowy
ATR ⇨
Opcjonalnie można używać protokołu PPS do przełączania
na większą szybkość transmisji, o ile ICC obsługuje tę
funkcję.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 352
3.3.2 Sekwencja dla niepodpisanych plików danych
DDP_037 ►M1 Sekwencja pobierania plików elementarnych ICC,
IC, Card_Certificate (lub CardSignCertificate dla DF Tacho­
graph_G2), CA_Certificate i Link_Certificate (wyłącznie dla
DF Tachograph_G2) jest następująca: ◄
Karta Kierunek IDE/IFD Znaczenie/Uwagi
⇦ Select File wybierz poprzez identyfikator
pliku
OK ⇨
⇦ Read Binary Jeżeli wielkość danych
w pliku jest większa od
pojemności bufora czytnika
lub karty, polecenie musi
być powtarzane aż do odczy­
tania całego pliku.
File Data
OK
⇨ zapisz dane na ESM zgodnie z pkt 3.4 Format
gromadzenia danych
Uwaga 1: przed wybraniem Card_Certificate (lub CardSign­
Certificate) EF musi być wybrana aplikacja tachograficzna
(wybór poprzez AID).
Uwaga 2: wybór i odczyt pliku może być również wyko­
nany za jednym razem przy użyciu polecenia Read Binary
z krótkim identyfikatorem EF.
3.3.3 Sekwencja dla podpisanych plików danych
DDP_038 Dla każdego pliku, który pobrany jest z podpisem, 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 wymaga­
nego algorytmu skrótu
zgodnie z dodatkiem 11
część A lub B. Polecenie
to nie jest poleceniem
ISO.
oblicz skrót pliku
i czasowo zachowaj
wartość skrótu
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 353
Karta Kierunek IDE/IFD Znaczenie / Uwagi
OK
Read Binary Jeżeli wielkość danych
w pliku jest większa od
pojemności bufora czytnika
lub karty, polecenie musi
być powtarzane aż do odczy­
tania całego pliku.
File Data
OK
zapisz odebrane dane na
ESM
zgodnie z 3.4 Data storage
format
PSO: Compute Digital
Signature
wykonaj operację
zabezpieczającą
„Compute Digital
Signature”, używając
czasowo zachowaną
wartość skrótu
Signature
OK
dołącz dane do poprzednio
zapisanych danych na ESM
zgodnie z 3.4 Data storage
format
▼B
Uwaga: wybór i odczyt pliku może być również wykonany
za jednym razem przy użyciu polecenia Read Binary
z krótkim identyfikatorem EF. W tym przypadku EF może
być wybrany i odczytany przed zastosowaniem polecenia
Perform Hash of File.
3.3.4 Sekwencja zerowania licznika kalibracji
DDP_039 Sekwencja zerowania licznika kalibracji
w pliku EF
na karcie warsztatowej jest następująca:
Karta Kierunek IDE/IFD Znaczenie/Uwagi
⇦ Select File EF
Card_Download
wybierz poprzez identyfikator
pliku
OK ⇨
⇦ Update Binary
NoOfCalibrationsSinceDown­
load = „00 00”
zeruje liczbę pobrań
danych z karty
OK ⇨
Uwaga: wybór i odczyt pliku może być również wykonany
za jednym razem przy użyciu polecenia Update Binary
z krótkim identyfikatorem EF.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 354
3.4. Format gromadzenia danych
3.4.1 Wprowadzenie
DDP_040 Pobrane dane należy przechowywać w sposób zgodny
z następującymi wymaganiami:
— Dane przechowuje się transparentnie. Oznacza to, że
przy gromadzeniu należy zachować kolejność bajtów,
jak i kolejność bitów w bajcie taką jak przy przesyłaniu
z karty.
— Wszystkie pliki pobrane z karty w ramach sesji pobie­
rania przechowuje się w jednym pliku na ESM.
3.4.2 Format pliku
DDP_041 Format pliku jest konkatenacją kilku obiektów TLV.
DDP_042 Znacznikiem pliku EF jest jego identyfikator FID z 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
FID (2 bajty) || „02” Znacznik podpisu pliku
EF (FID) w DF
3 bajty
FID (2 bajty) || „03” Znacznik podpisu pliku
EF (FID) w DF
3 bajty
xx xx długość pola wartości 2 bajty
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 355
Przykładowe dane w pliku pobranym na ESM:
Znacznik Długość Wartość
— Dane pliku EF ICC
— Dane pliku EF Card_Certificate
— ...
Dane pliku EF (w DF
)
Podpis pliku EF (w DF
)
Dane pliku EF ­
w DF
Podpis pliku EF ­
_Used w DF
▼B
4. POBIERANIE DANYCH Z KARTY DO TACHOGRAFU ZA
POŚREDNICTWEM PRZYRZĄDU REJESTRUJĄCEGO
DDP_047 VU musi umożliwiać pobieranie danych z włożonej karty
kierowcy do przyłączonego IDE.
DDP_048 IDE wysyła do VU komunikat „Transfer Data Request Card
Download” w celu zainicjowania tego trybu (zob. pkt
2.2.2.9).
▼M1
DDP_049 Karty kierowcy pierwszej generacji: Dane pobiera się 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 — 21.08.2023 — 003.002 — 356
Dodatek 8
PROTOKÓŁ KALIBRACJI
SPIS TREŚCI
1. WPROWADZENIE
2. POJĘCIA, DEFINICJE I ODNIESIENIA
3. INFORMACJE OGÓLNE O USŁUGACH
3.1. Dostępne usługi
3.2. Kody odpowiedzi
4. USŁUGI KOMUNIKACYJNE
4.1. Usługa StartCommunication
4.2. Usługa StopCommunication
4.2.1 Opis komunikatu
4.2.2 Format komunikatu
4.2.3 Definicja parametru
4.3. Usługa TesterPresent
4.3.1 Opis komunikatu
4.3.2 Format komunikatu
5. USŁUGI ZARZĄDZANIA
5.1. Usługa StartDiagnosticSession
5.1.1 Opis komunikatu
5.1.2 Format komunikatu
5.1.3 Definicja parametru
5.2. Usługa SecurityAccess
5.2.1 Opis komunikatu
5.2.2 Format komunikatu – SecurityAccess – requestSeed
5.2.3 Format komunikatu – SecurityAccess – sendKey
6. USŁUGI PRZESYŁANIA DANYCH
6.1. Usługa ReadDataByIdentifier
6.1.1 Opis komunikatu
6.1.2 Format komunikatu
6.1.3 Definicja parametru
6.2. UsługaWriteDataByIdentifier
6.2.1 Opis komunikatu
6.2.2 Format komunikatu
6.2.3 Definicja parametru
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 357
7. STEROWANIE IMPULSAMI TESTUJĄCYMI – JEDNOSTKA
FUNKCJONALNA STEROWANIA WE/WY
7.1. Usługa InputOutputControlByIdentifier
7.1.1 Opis komunikatu
7.1.2 Format komunikatu
7.1.3 Definicja parametru
▼M3
8. USŁUGA ROUTINECONTROL (KOREKTA CZASU)
8.1. Opis komunikatu
8.2. Format komunikatu
9. FORMATY DATARECORDS
9.1. Zakresy przesyłanych parametrów
9.2. Formaty dataRecords
▼B
1. WPROWADZENIE
Niniejszy dodatek opisuje wymianę danych między przyrządem 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 — 21.08.2023 — 003.002 — 358
2. POJĘCIA, DEFINICJE I ODNIESIENIA
Protokoły, komunikaty i kody błędów oparte są zasadniczo na
projekcie normy ISO 14229-1 (Pojazdy drogowe — Systemy diagno­
styczne — część 1: Usługi diagnostyczne, wersja 6 z dnia 22 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
diagnostycznej.
— Pierwsza kolumna zawiera wykaz dostępnych usług.
— Druga kolumna zawiera numer sekcji w niniejszym
dodatku, gdzie usługa jest dokładniej zdefiniowana.
— Trzecia kolumna przypisuje wartości identyfikatora
usługi dla komunikatów żądań.
— Czwarta kolumna określa usługi „StandardDiagnos­
ticSession” (SD), których wdrożenie jest wymagane
w każdym VU.
— Piąta kolumna określa usługi „ECUAdjustmentSes­
sion” (ECUAS), które muszą być wdrożone w celu
umożliwienia sterowania linią sygnałową we/wy
w złączu kalibracji w panelu czołowym VU.
— Szósta kolumna określa usługi „ECUProgrammin­
gSession” (ECUPS), które muszą być wdrożone
w celu umożliwienia programowania parametrów w VU.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 359
Tabela 1
Zestawienie wartości identyfikatorów usług
Sesje diagnostyczne
Nazwa usługi diagnostycznej Sekcja nr
Wartość SId
Req.
SD ECUAS ECUPS
StartCommunication 4.1 81 ■ ■ ■
StopCommunication 4.2 82 ■
TesterPresent 4.3 3E ■ ■ ■
StartDiagnosticSession 5.1 10 ■ ■ ■
SecurityAccess 5.2 27 ■ ■ ■
ReadDataByIdentifier 6.1 22 ■ ■ ■
WriteDataByIdentifier 6.2 2E ■
InputOutputControlByIdentifier 7.1 2F ■
▼M3
RoutineControl 8 31 ■ ■
▼B
■ 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 komuni­
kacji. Nie występują one w warstwie aplikacji. Dostępne usługi
wyszczególniono w tabeli poniżej:
Tabela 2
Usługi komunikacyjne
Nazwa usługi Wyszczególnienie
StartCommunication Klient żąda rozpoczęcia sesji komuni­
kacyjnej z serwerem(-ami).
StopCommunication Klient żąda zaprzestania bieżącej sesji
komunikacyjnej.
TesterPresent Klient wskazuje serwerowi, że jest
jeszcze obecny.
CPR_005 Usługa StartCommunication służy do rozpoczęcia komuni­
kacji. W celu wykonania usługi konieczne jest zainicjowanie
komunikacji i ustawienie parametrów odpowiednio dla
pożądanego trybu.
4.1. Usługa StartCommunication
CPR_006 Po odebraniu prymitywu wskazania StartCommunication
VU sprawdza, czy w obecnych warunkach można zaini­
cjować żądane łącze komunikacyjne. Warunki zezwalające
na zainicjowanie łącza komunikacyjnego opisano w normie
ISO 14230-2.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 360
CPR_007 Następnie VU wykonuje wszystkie działania niezbędne do
zainicjowania łącza komunikacyjnego i wysyła prymityw
odpowiedzi StartCommunication z wybranymi parametrami
Positive Response.
CPR_008 Jeżeli VU, który jest już zainicjowany (ma otwartą 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 komunikacyjnego.
CPR_010 Komunikat żądania StartCommunication musi mieć fizyczny
adres.
CPR_011 Inicjowanie usług w VU odbywa się metodą „szybkiej
inicjalizacji”:
— Przed każdą czynnością występuje czas jałowy
magistrali.
— Następnie tester wysyła kod inicjujący.
— Wszystkie informacje niezbędne do nawiązania komuni­
kacji zawarte są w odpowiedzi VU.
CPR_012 Po zakończeniu inicjalizacji:
— Wszystkie parametry komunikacyjne zostają ustawione
na wartości zdefiniowane w tabeli 4 zgodnie z bajtami
kluczowymi.
— VU czeka na pierwsze żądanie testera.
— VU znajduje się w domyślnym trybie diagnostycznym,
tj. StandardDiagnosticSession.
— Linia sygnałowa we/wy kalibracji jest w stanie
domyślnym, tj. w stanie „disabled” (wyłączona).
CPR_014 Szybkość transmisji K-line jest ustawiona na 10 400 bodów.
CPR_016 Szybką inicjalizację uruchamia tester, wysyłając kod 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 — 21.08.2023 — 003.002 — 361
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 — 21.08.2023 — 003.002 — 362
# 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
komunikacyjnej.
CPR_020 Po odebraniu prymitywu wskazania StopCommunication
VU sprawdza, czy bieżące warunki pozwalają na zakoń­
czenie tej komunikacji. W tym przypadku VU wykonuje
wszystkie działania niezbędne do zakończenia sesji
komunikacyjnej.
CPR_021 Jeżeli zakończenie sesji komunikacyjnej jest możliwe, 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 — 21.08.2023 — 003.002 — 363
4.2.2 Format komunikatu
CPR_024 Formaty komunikatu dla prymitywów StopCommunication
opisano szczegółowo w poniższych tabelach.
Tabela 7
Komunikat StopCommunication Request
# bajtu Nazwa parametru
Wartość heksa­
decymalna
Mnemonik
#1 Bajt formatu – adresowanie
fizyczne
80 FMT
#2 Bajt adresu docelowego 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 — 21.08.2023 — 003.002 — 364
# bajtu Nazwa parametru
Wartość heksa­
decymalna
Mnemonik
#5 negative Response Service Id 7F NR
#6 StopCommunication Request
Service Identification
82 SPR
#7 responseCode = generalReject 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 — 21.08.2023 — 003.002 — 365
Tabela 11
Komunikat TesterPresent Positive Response
# bajtu Nazwa parametru
Wartość heksa­
decymalna
Mnemonik
#1 Bajt formatu – adresowanie
fizyczne
80 FMT
#2 Bajt adresu docelowego 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
odpowiedzi:
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 — 21.08.2023 — 003.002 — 366
5. USŁUGI ZARZĄDZANIA
Dostępne usługi wyszczególniono w tabeli poniżej:
Tabela 13
Usługi zarządzania
Nazwa usługi Wyszczególnienie
StartDiagnosticSession Klient żąda rozpoczęcia sesji diagnostycznej
z VU.
SecurityAccess Klient żąda dostępu do funkcji zastrzeżonych
dla uprawnionych użytkowników.
5.1. Usługa StartDiagnosticSession
5.1.1 Opis komunikatu
CPR_025 Usługa StartDiagnosticSession służy do włączania róż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
diagnostyczna.
— Po włączeniu zasilania VU zawsze uruchamia Standard­
DiagnosticSession. Jeżeli żadna inna sesja diagnostyczna
nie zostanie uruchomiona, wówczas StandardDiagnostic­
Session pozostaje uruchomiona tak długo, jak włączone
jest zasilanie VU.
— Jeżeli jest już uruchomiona sesja diagnostyczna zażą­
dana przez tester, VU wysyła komunikat pozytywnej
odpowiedzi.
— Za każdym razem kiedy tester żąda nowej sesji diagno­
stycznej, VU najpierw wysyła komunikat pozytywnej
odpowiedzi StartDiagnosticSession, zanim nowa sesja
stanie się aktywna w VU. Jeżeli VU nie może
uruchomić żądanej nowej sesji diagnostycznej, to odpo­
wiada komunikatem negatywnej odpowiedzi StartDiag­
nosticSession i bieżąca sesja jest kontynuowana.
CPR_026 Sesja diagnostyczna może zostać uruchomiona tylko wtedy,
gdy nawiązana jest komunikacja między klientem a VU.
CPR_027 Parametry czasowe zdefiniowane w tabeli 4 są aktywne po
pomyślnym uruchomieniu sesji StartDiagnosticSession
z parametrem diagnosticSession ustawionym na „Standard­
DiagnosticSession” w komunikacie żądania, jeżeli
poprzednio aktywna była inna sesja diagnostyczna.
5.1.2 Format komunikatu
CPR_028 Formaty komunikatu dla prymitywów StartDiagnosticSes­
sion opisano szczegółowo w poniższych tabelach.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 367
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 — 21.08.2023 — 003.002 — 368
# 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 ( α )
12 RC_SFNS
incorrectMessage­
Length ( β )
13 RC_IML
conditionsNotCor­
rect ( γ )
22 RC_CNC
#8 Suma kontrolna 00-FF CS
( α ) – wartość wstawiona w bajcie #6 komunikatu żądania nie jest obsługiwana, tzn. nie
ma jej w tabeli 17;
( β ) – długość komunikatu jest nieprawidłowa;
( γ ) – kryteria żądania StartDiagnosticSession nie są spełnione.
5.1.3 Definicja parametru
CPR_029 Parametr diagnosticSession (DS_) używany jest w usłudze
StartDiagnosticSession do wybierania szczególnego zacho­
wania serwera(-ów). W niniejszym dokumencie określone są
następujące sesje diagnostyczne:
Tabela 17
Definicja wartości diagnosticSession
Heks Wyszczególnienie Mnemonik
81 StandardDiagnosticSession
Ta sesja diagnostyczna udostępnia wszystkie
usługi wyszczególnione w tabeli 1 w kolumnie
4 „SD”. Usługi te umożliwiają odczyt danych
z serwera (VU). Ta sesja diagnostyczna jest
aktywna po pomyślnym zakończeniu inicjacji
między klientem (tester) a serwerem (VU). Tę
sesję diagnostyczną można zastąpić każdą inną
sesją diagnostyczną wyszczególnioną w tej
sekcji.
SD
85 ECUProgrammingSession
Ta sesja diagnostyczna udostępnia wszystkie
usługi wyszczególnione w tabeli 1 w kolumnie
6 „ECUPS”. Usługi te wspomagają programo-
wanie pamięci serwera (VU). Tę sesję diagnos-
tyczną można zastąpić każdą inną sesją
diagnostyczną wyszczególnioną w tej sekcji.
ECUPS
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 369
Heks Wyszczególnienie Mnemonik
87 ECUAdjustmentSession
Ta sesja diagnostyczna udostępnia wszystkie
usługi wyszczególnione w tabeli 1 w kolumnie
5 „ECUAS”. Usługi te wspomagają sterowania
we/wy serwera (VU). Tę sesję diagnostyczną
można zastąpić każdą inną sesją diagnostyczną
wyszczególnioną w tej sekcji.
ECUAS
5.2. Usługa SecurityAccess
Zapis danych kalibracyjnych nie jest możliwy w trybie KALIBRA­
CYJNYM. Dodatkowo, oprócz włożenia do VU ważnej karty warsz­
tatowej, niezbędne jest wprowadzenie numeru PIN do VU przed uzys­
kaniem dostępu do trybu KALIBRACYJNEGO.
Jeżeli VU jest w trybie KALIBRACYJNYM lub KONTROLNYM,
dostęp do linii we/wy kalibracji jest również możliwy.
Usługa SecurityAccess umożliwia wprowadzenie numeru PIN i 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 „reques­
tSeed”, po którym może nastąpić komunikat SecurityAccess
„sendKey”. Usługa SecurityAccess musi być przeprowadzona po
usłudze StartDiagnosticSession.
CPR_033 Tester używa komunikatu SecurityAccess „requestSeed” do
sprawdzenia, czy przyrząd rejestrujący jest gotowy do przy­
jęcia numeru PIN.
CPR_034 Jeżeli przyrząd rejestrujący jest już w trybie KALIBRA­
CYJNYM, odpowiada na żądanie wysyłając „seed” równy
0x0000 przy pomocy usługi SecurityAccess Positive
Response.
CPR_035 Jeżeli przyrząd rejestrujący jest gotowy do przyjęcia 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 odpo­
wiedzi requestCorrectlyReceived-ResponsePending. Maksy­
malny czas oczekiwania na odpowiedź nie może jednak prze­
kraczać 5 minut. Gdy tylko żądana usługa zostaje zakoń­
czona, VU wysyła komunikat pozytywnej odpowiedzi lub
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 370
komunikat negatywnej odpowiedzi z kodem odpowiedzi
różnym od tego pierwszego kodu. VU może powtarzać kod
negatywnej odpowiedzi requestCorrectlyReceived-Response­
Pending aż do zakończenia żądanej usługi i wysłania komu­
nikatu ostatecznej odpowiedzi.
CPR_038 Przyrząd rejestrujący odpowiada na to żądanie przy 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 — 21.08.2023 — 003.002 — 371
Tabela 19
Komunikat SecurityAccess – requestSeed Positive Response
# bajtu Nazwa parametru
Wartość heksa­
decymalna
Mnemonik
#1 Bajt formatu – adresowanie
fizyczne
80 FMT
#2 Bajt adresu docelowego 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 — 21.08.2023 — 003.002 — 372
5.2.3 Format komunikatu – SecurityAccess – sendKey
CPR_041 Formaty komunikatu dla prymitywów SecurityAccess
„sendKey” opisano szczegółowo w poniższych tabelach.
Tabela 21
Komunikat SecurityAccess Request – sendKey
# bajtu Nazwa parametru
Wartość heksa­
decymalna
Mnemonik
#1 Bajt formatu – adresowanie
fizyczne
80 FMT
#2 Bajt adresu docelowego 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 — 21.08.2023 — 003.002 — 373
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
incorrectMessage­
Length
13 RC_IML
conditionsNotCorrec­
tOrRequestSequence­
Error
22 RC_CNC
invalidKey 35 RC_IK
exceededNumberO­
fAttempts
36 RC_ENA
requestCorrectlyRe­
ceived-ResponsePen­
ding]
78 RC_RCR_RP
#8 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 — 21.08.2023 — 003.002 — 374
6.1. Usługa ReadDataByIdentifier
6.1.1 Opis komunikatu
CPR_050 Klient używa usługi ReadDataByIdentifier do żądania
wartości rekordów danych z serwera. Dane są identyfiko­
wane przez recordDataIdentifier. Producent VU odpowiada
za spełnienie warunków serwera przy wykonywaniu tej
usługi.
6.1.2 Format komunikatu
CPR_051 Formaty komunikatu dla prymitywów ReadDataByIdentifier
opisano szczegółowo w poniższych tabelach.
Tabela 25
Komunikat ReadDataByIdentifier Request
# bajtu Nazwa parametru
Wartość heksa­
decymalna
Mnemonik
#1 Bajt formatu – adresowanie
fizyczne
80 FMT
#2 Bajt adresu docelowego 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 — 21.08.2023 — 003.002 — 375
# bajtu Nazwa parametru
Wartość
heksade­
cymalna
Mnemonik
#8 do
#m + 7
dataRecord[] = [data#1 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DAT­
Am
#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 Response­
Code=
[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.
▼M3
CPR_053 Wartości recordDataIdentifier zdefiniowane w tym doku­
mencie pokazano w tabeli poniżej.
Tabela recordDataIdentifier składa się z pięciu kolumn
i wielu wierszy.
— Pierwsza kolumna (Heks) zawiera „wartość heksadecy­
malną” przypisaną identyfikatorowi recordDataIdentifier
z trzeciej kolumny.
— Druga kolumna (Element danych) określa element
danych z dodatku 1, na którym oparty jest identyfikator
recordDataIdentifier (czasami niezbędne jest przekodo­
wanie).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 376
— Trzecia kolumna (Opis) podaje nazwę odpowiadają­
cego identyfikatora recordDataIdentifier.
— Czwarta kolumna (Prawa dostępu) określa prawa
dostępu do tego identyfikatora recordDataIdentifier.
— Piąta kolumna (Mnemonik) podaje mnemonik tego
identyfikatora recordDataIdentifier.
Tabela 28
Definicja wartości recordDataIdentifier
Heks Element danych
Nazwa recordDataldentifier
(zob. format w sekcji 8.2)
Prawa
dostępu
(Read/
Write)
Mnemonik
F90B CurrentDateTime TimeDate R/W RDI_TD
F912 HighResOdometer HighResolutionTotalVehicleDis­
tance
R/W RDI_HRTVD
F918 K-ConstantOfRecordingEquipment Kfactor R/W RDI_KF
F91C L-TyreCircumference LfactorTyreCircumference R/W RDI_LF
F91D W-VehicleCharacteristicConstant WvehicleCharacteristicFactor R/W RDI_WVCF
F921 TyreSize TyreSize R/W RDI_TS
F922 nextCalibrationDate NextCalibrationDate R/W RDI_NCD
F92C SpeedAuthorised SpeedAuthorised R/W RDI_SA
F97D vehicleRegistrationNation RegisteringMemberState R/W RDI_RMS
F97E VehicleRegistrationNumber VehicleRegistrationNumber R/W RDI_ VRN
F190 VehicleIdentificationNumber VIN R/W RDI_ VIN
F9D0 SensorSerialNumber MotionSensorSerialNumber R RDI_SSN
F9D1 RemoteCommunicationModuleSerial­
Number
RemoteCommunicationFacility­
SerialNumber
R RDI_RCSN
F9D2 SensorGNSSSerialNumber ExternalGNSSFacilitySerial­
Number
R RDI_GSSN
F9D3 SealDataVu SmartTachographSealsSerial­
Number
R/W RDI_SDV
F9D4 VuSerialNumber VuSerialNumber R RDI_VSN
F9D5 ByDefaultLoadType ByDefaultLoadType R/W RDI_BDLT
F9D6 TachographCardsGen1Suppression TachographCardsGen1Suppres­
sion
R/W RDI_TCG1S
F9D7 VehiclePosition VehiclePosition R RDI_VP
F9D8 LastCalibrationCountry CalibrationCountry R RDI_CC
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 377
CPR_054 Parametr dataRecord (DREC_) używany jest w komunikacie
pozytywnej odpowiedzi ReadDataByIdentifier do dostar­
czania wartości rekordu danych wskazanego klientowi
(testerowi) identyfikatorem recordDataIdentifier. Formaty
danych określono w sekcji 8. Można wprowadzić dodat­
kowe opcjonalne dataRecords użytkownika obejmujące
szczególne dane wejściowe, wewnętrzne i wyjściowe VU,
ale nie są one zdefiniowane w tym dokumencie.
6.2. UsługaWriteDataByIdentifier
6.2.1 Opis komunikatu
CPR_056 Usługa WriteDataByIdentifier używana jest przez klienta do
zapisania wartości rekordu danych w serwerze. Dane są
identyfikowane przez recordDataIdentifier. Producent VU
odpowiada za spełnienie warunków serwera przy wykony­
waniu tej usługi. Aby aktualizować parametry wymienione
w tabeli 28, VU musi być w trybie KALIBRACYJNYM.
6.2.2 Format komunikatu
CPR_057 Formaty komunikatu dla prymitywów WriteDataByIdentifier
opisano szczegółowo w poniższych tabelach.
Tabela 29
Komunikat WriteDataByIdentifier Request
# bajtu Nazwa parametru
Wartość
heksade­
cymalna
Mnemonik
#1 Bajt formatu – adresowanie fizyczne 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_DAT­
A1
: : :
data#m] xx DREC_DAT­
Am
#m+8 Suma kontrolna 00-FF CS
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 378
Tabela 30
Komunikat WriteDataByIdentifier Positive Response
# bajtu Nazwa parametru
Wartość heksa­
decymalna
Mnemonik
#1 Bajt formatu – adresowanie
fizyczne
80 FMT
#2 Bajt adresu docelowego 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
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
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 379
6.2.3 Definicja parametru
Parametr recordDataIdentifier (RDI_) zdefiniowano w tabeli 28.
Parametr dataRecord (DREC_) używany jest w komunikacie żądania
WriteDataByIdentifier do dostarczenia wartości rekordu danych 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.
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).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 380
CPR_060 Jeżeli impulsy prędkości odbierane są w czasie rzeczy­
wistym z linii sygnału wejściowego prędkości w VU, nato­
miast linia sygnałowa we/wy kalibracji jest ustawiona na
wejście, to linia sygnałowa we/wy kalibracji zostanie usta­
wiona na wyjście lub powróci do stanu „disabled” (wyłą­
czona).
CPR_061 Kolejność czynności jest następująca:
— uruchomienie komunikacji usługą StartCommunication;
— otworzenie sesji regulacji usługą StartDiagnosticSession
i wejście do trybu KALIBRACYJNEGO lub KONTRO­
LNEGO (kolejność tych dwóch czynności nie ma
znaczenia);
— zmiana stanu wyjścia usługą InputOutputControlByIden­
tifier.
7.1.2 Format komunikatu
CPR_062 Formaty komunikatu dla prymitywów InputOutputControl­
ByIdentifier opisano szczegółowo w poniższych tabelach.
Tabela 33
Komunikat InputOutputControlByIdentifier Request
# bajtu Nazwa parametru
Wartość heksa­
decymalna
Mnemonik
#1 Bajt formatu – adresowanie
fizyczne
80 FMT
#2 Bajt adresu docelowego 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).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 381
Tabela 34
Komunikat InputOutputControlByIdentifier Positive Response
# bajtu Nazwa parametru
Wartość heksa­
decymalna
Mnemonik
#1 Bajt formatu – adresowanie
fizyczne
80 FMT
#2 Bajt adresu docelowego 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
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
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 382
# bajtu Nazwa parametru
Wartość heksa­
decymalna
Mnemonik
#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
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)
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 383
Tryb
Wartość heksa­
decymalna
Wyszczególnienie
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
▼M3
8. USŁUGA ROUTINECONTROL (KOREKTA CZASU)
8.1. Opis komunikatu
CPR_065a Usługa RoutineControl (TimeAdjustment) umożliwia
uruchomienie operacji dostosowania zegara VU do czasu
podawanego przez odbiornik GNSS.
Na potrzeby realizacji usługi RoutineControl (TimeAdjus­
tment) VU musi być w trybie KALIBRACYJNYM.
Warunek wstępny: zapewnia się zdolność VU do odbie­
rania komunikatów o uwierzytelnionej pozycji z odbiornika
GNSS.
Dopóki trwa korekta czasu, VU odpowiada na żądanie
RoutineControl, podfunkcja requestRoutineResults, z routi­
neInfo = 0x78.
Uwaga: korekta czasu może być dość czasochłonna. Tester
diagnostyczny żąda statusu korekty czasu za pomocą
podfunkcji requestRoutineResults.
8.2. Format komunikatu
CPR_065b Formaty komunikatu dla usługi RoutineControl (TimeAd­
justment) i jej prymitywów opisano szczegółowo w poniż­
szych tabelach.
Tabela 37a
RoutineControl, komunikat żądania procedury (TimeAdjustment), podfunkcja startRoutine
# bajtu Nazwa parametru
Wartość heksa­
decymalna
Mnemonik
#1 Bajt formatu – adresowanie fizyczne 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 RoutineControl Request Sid (Sid żądania RoutineControl) 31 RC
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 i #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 Suma kontrolna 00-FF CS
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 384
Tabela 37b
RoutineControl, procedura (TimeAdjustment), podfunkcja startRoutine, komunikat pozytywnej odpowiedzi
# 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 RoutineControl Positive Response Sid (Sid pozytywnej odpowiedzi
na RoutineControl)
71 RCPR
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 i #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 Suma kontrolna 00-FF CS
Tabela 37c
RoutineControl, komunikat żądania procedury (TimeAdjustment), podfunkcja requestRoutineResults
# 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 RoutineControl Request Sid (Sid żądania RoutineControl) 31 RC
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 i #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 Suma kontrolna 00-FF CS
Tabela 37d
RoutineControl, procedura (TimeAdjustment), podfunkcja requestRoutineResults, komunikat pozytywnej
odpowiedzi
# 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 RoutineControl Positive Response Sid (Sid pozytywnej odpowiedzi
na RoutineControl)
71 RCPR
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 i #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 routineInfo (zob. tabela 37f) XX RINF_TA
#10 routineStatusRecord[] = routineStatus#1 (zob. tabela 37g) XX RS_TA
#11 Suma kontrolna 00-FF CS
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 385
Tabela 37e
RoutineControl, komunikat negatywnej odpowiedzi na procedurę (TimeAdjustment)
# 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 (ID usługi negatywnej odpowiedzi) 7F NR
#6 inputOutputControlByIdentifier Request SId 31 RC
#7 responseCode=[
sub-functionNotSupported
incorrectMessageLengthOrInvalidFormat
conditionsNotCorrect
requestOutOfRange
]
12
13
22
31
SFNS
IMLOIF
CNC
ROOR
#8 Suma kontrolna 00-FF CS
Tabela 37f
RoutineControl, procedura (TimeAdjustment), routineInfo
routineInfo
Wartość heksa­
decymalna
Opis
NormalExitWithResultAvailable 61 Procedura została wykonana w całości; dostępne są
dodatkowe wyniki procedury.
RoutineExecutionOngoing 78 Żądana procedura jest nadal wykonywana.
Tabela 37g
RoutineControl, procedura (TimeAdjustment), routineStatus
Wartość heksadecy­
malna
Wynik próby Opis
01 pozytywny Korekta czasu zakończyła się pomyślnie.
02..0F RFU
10 negatywny Brak odbioru sygnału GNSS.
11..7F RFU
80..FF swoisty dla producenta
9. FORMATY DATARECORDS
W tej sekcji opisano szczegółowo:
— ogólne zasady odnoszące się do szeregu parametrów wysyłanych
przez przyrząd rejestrujący do testera,
— formaty, które należy stosować dla danych przesyłanych poprzez
usługi przesyłania danych opisane w sekcji 6.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 386
CPR_067 VU obsługuje wszystkie wyszczególnione parametry.
CPR_068 Dane wysyłane przez przyrząd rejestrujący do testera
w odpowiedzi na komunikat żądania są typu pomiarowego
(tj. bieżąca wartość żądanego parametru pomierzona lub
stwierdzona przez VU).
9.1. Zakresy przesyłanych parametrów
CPR_069 W tabeli 38 podano wartości zakresów używane do spraw­
dzania poprawności przesłanego parametru.
CPR_070 Wartości w zakresie „wskaźnik błędu” umożliwiają przyrzą­
dowi rejestrującemu niezwłoczne wskazanie, że poprawne
dane parametryczne nie są dostępne w bieżącym czasie
wskutek pewnego typu błędu w tachografie.
CPR_071 Wartości w zakresie „niedostępne” umożliwiają przyrzą­
dowi rejestrującemu wysłanie komunikatu zawierającego
parametr, który nie jest dostępny bądź nie jest obsługiwany
w tym module. Wartości w zakresie „nieżądane” umożli­
wiają urządzeniu wysłanie komunikatu polecenia i wska­
zanie tych parametrów, w przypadku gdy od urządzenia
odbierającego oczekiwany jest brak odpowiedzi.
CPR_072 Jeżeli usterka elementu składowego uniemożliwia wysł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 przesyłane są używając odpowiednio wartości mini­
malnej lub maksymalnej parametru.
Tabela 38
Zakresy dataRecords
Nazwa zakresu
1 bajt
(wartość heksa­
decymalna)
2 bajty
(wartość heksadecy­
malna)
4 bajty
(wartość heksadecymalna)
ASCII
Prawidłowy sygnał 00 do FA 0000 do FAFF 00000000 do FAFFFFFF 1 do 254
Szczególny wskaźnik parametru FB FB00 do FBFF FB000000 do FBFFFFFF brak
Zastrzeżony zakres do wykorzystania
w przyszłości
FC do FD FC00 do FDFF FC000000 do FDFFFFFF brak
Wskaźnik błędu 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.
9.2. Formaty dataRecords
W tabelach od 39 do 42 poniżej opisano szczegółowo formaty
używane przez usługi ReadDataByIdentifier i WriteDataByIdentifier.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 387
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
HighResolutionTotalVehicleDis­
tance
4 wzmocnienie 5 m/bit,
offset 0 m
0 do +21 055 406 km
Kfactor 2 wzmocnienie 0,001 impulsu/m/
bit, offset 0
0 do 64,255 impulsu/m
LfactorTyreCircumference 2 wzmocnienie 0,125 10 -3 m/bit,
offset 0
0 do 8,031 m
WvehicleCharacteristicFactor 2 wzmocnienie 0,001 impulsu/m/
bit, offset 0
0 do 64,255 impulsu/m
TyreSize 15 ASCII ASCII
NextCalibrationDate 3 Zob. szczegółowy opis w tabeli 41
SpeedAuthorised 2 wzmocnienie 1/256km/h/bit,
offset 0
0 do 250,996 km/h
RegisteringMemberState 3 ASCII ASCII
VehicleRegistrationNumber 14 Zob. szczegółowy opis w tabeli 42
VIN 17 ASCII ASCII
SealDataVu 55 Zob. szczegółowy opis w tabeli 43
ByDefaultLoadType 1 Zob. szczegółowy opis w tabeli 44
VuSerialNumber 8 Zob. szczegółowy opis w tabeli 45
SensorSerialNumber 8 Zob. szczegółowy opis w tabeli 45
SensorGNSSSerialNumber 8 Zob. szczegółowy opis w tabeli 45
RemoteCommunicationModuleSe­
rialNumber
8 Zob. szczegółowy opis w tabeli 45
TachographCardsGen1Suppression 2 Zob. szczegółowy opis w tabeli 46
VehiclePosition 14 Zob. szczegółowy opis w tabeli 47
CalibrationCountry 3 ASCII NationAlpha zgodnie z definicją
w dodatku 1
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 388
CPR_075 W tabeli 40 zamieszczono szczegółowy opis formatów
poszczególnych bajtów parametru TimeDate:
Tabela 40
Szczegółowy opis formatu TimeDate (wartość recordDataIdentifier # F90B)
Bajt Definicja parametru Rozdzielczość Zakres roboczy
1 Sekundy wzmocnienie 0,25 s/bit, offset 0 s 0 do 59,75s
2 Minuty wzmocnienie 1 minuta/bit, offset 0 minut 0 do 59 minut
3 Godziny wzmocnienie 1 h/bit, offset 0 h 0 do 23 h
4 Miesiąc wzmocnienie 1 miesiąc/bit, offset 0 miesięcy 1 do 12 miesięcy
5 Dzień wzmocnienie 0,25 dnia/bit, offset 0 dni (zob.
UWAGA pod tabelą 41)
0,25 do 31,75 dnia
6 Rok wzmocnienie 1 rok/bit, offset rok +1985
(zob. UWAGA pod tabelą 41)
lata od 1985 do 2235
7 lokalne przesunięcie dla
minut
wzmocnienie 1 minuta/bit, offset -125 minut -59 do +59 minut
8 lokalne przesunięcie dla
godzin
wzmocnienie 1 h/bit, offset -125 h -23 do +23 h
CPR_076 W tabeli 41 zamieszczono szczegółowy opis formatów
poszczególnych bajtów parametru NextCalibrationDate:
Tabela 41
Szczegółowy opis formatu NextCalibrationDate (wartość recordDataIdentifier # F922)
Bajt Definicja parametru Rozdzielczość Zakres roboczy
1 Miesiąc wzmocnienie 1 miesiąc/bit, offset 0 miesięcy 1 do 12 miesięcy
2 Dzień wzmocnienie 0,25 dnia/bit, offset 0 dni (zob.
UWAGA poniżej)
0,25 do 31,75 dnia
3 Rok wzmocnienie 1 rok/bit, offset rok +1985
(zob. UWAGA poniżej)
lata od 1985 do 2235
UWAGA dotycząca zastosowania parametru „dzień”:
1) Wartość 0 dla daty nie istnieje. Wartości 1, 2, 3 i 4 są
stosowane do oznaczenia pierwszego dnia miesiąca, 5,
6, 7 i 8 – do oznaczenia drugiego dnia miesiąca, itd.
2) Ten parametr nie ma wpływu na parametr „godzina” ani
go nie zmienia.
UWAGA dotycząca zastosowania parametru „rok”:
Wartość 0 dla roku oznacza rok 1985, wartość 1 oznacza
rok 1986, itd.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 389
CPR_078 W tabeli 42 zamieszczono szczegółowy opis formatów
poszczególnych bajtów parametru VehicleRegistration­
Number:
Tabela 42
Szczegółowy opis formatu VehicleRegistrationNumber (wartość recordDataIdentifier # F97E)
Bajt Definicja parametru Rozdzielczość Zakres roboczy
1 Strona kodowa (zdefiniowana w dodatku 1) nie dotyczy VehicleRegistrationNumber
2 – 14 Numer rejestracyjny pojazdu (zdefiniowany
w dodatku 1)
nie dotyczy VehicleRegistrationNumber
CPR_090 W tabeli 43 zamieszczono szczegółowy opis formatów
poszczególnych bajtów parametru SealDataVu:
Tabela 43
Szczegółowy opis formatu SealDataVu (wartość recordDataIdentifier # F9D3)
Bajt Definicja parametru Rozdzielczość Zakres roboczy
1 – 11 sealRecord1. Format SealRecord zdefinio­
wany w dodatku 1.
nie dotyczy SealRecord
12 - 22 sealRecord2. Format SealRecord zdefinio­
wany w dodatku 1.
nie dotyczy SealRecord
23 – 33 sealRecord3. Format SealRecord zdefinio­
wany w dodatku 1.
nie dotyczy SealRecord
34 – 44 sealRecord4. Format SealRecord zdefinio­
wany w dodatku 1.
nie dotyczy SealRecord
45 – 55 sealRecord5. Format SealRecord zdefinio­
wany w dodatku 1.
nie dotyczy SealRecord
UWAGA: W przypadku gdy dostępnych jest mniej niż 5 plomb
wartość EquipmentType we wszystkich niewykorzystanych
sealRecords należy ustawić na 15, tj. niewykorzystane.
CPR_091 W tabeli 44 zamieszczono szczegółowy opis formatów
poszczególnych bajtów parametru ByDefaultLoadType:
Tabela 44
Szczegółowy opis formatu ByDefaultLoadType (wartość recordDataIdentifier # F9D5)
Bajt Definicja parametru Rozdzielczość Zakres roboczy
1 loadType
'00'H: nieokreślony typ załadunku
'01'H: towary
'02'H: pasażerowie
nie dotyczy '00'H do '02'H
CPR_092 W tabeli 45 zamieszczono szczegółowy opis formatów
poszczególnych bajtów parametrów VuSerialNumber,
SensorSerialNumber, SensorGNSSSerialNumber oraz
RemoteCommunicationModuleSerialNumber:
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 390
Tabela 45
Szczegółowy opis formatu VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber oraz
RemoteCommunicationModuleSerialNumber (wartości recordDataIdentifier # F9D4, F9D0, F9D2, F9D1)
Bajt Definicja parametru Rozdzielczość Zakres roboczy
1 VuSerialNumber, SensorSerialNumber, Sensor
GNSSSerialNumber and RemoteCommunica­
tionModuleSerialNumber:
Format ExtendedSerialNumber zdefiniowany
w dodatku 1.
nie dotyczy ExtendedSerialNumber
CPR_093 W tabeli 46 zamieszczono szczegółowy opis formatów
poszczególnych bajtów parametru TachographCar­
dsGen1Suppression:
Tabela 46
Szczegółowy opis formatu TachographCardsGen1Suppression (wartość recordDataIdentifier # F9D6)
Bajt Definicja parametru Rozdzielczość Zakres roboczy
1-2 TachographCardsGen1Suppression. Format
TachographCardsGen1Suppression zdefinio­
wany w dodatku 1.
nie dotyczy '0000'H, 'A5E3'H
CPR_094 W tabeli 47 zamieszczono szczegółowy opis formatów
poszczególnych bajtów parametru VehiclePosition:
Tabela 47
Szczegółowy opis formatu VehiclePosition (wartość recordDataIdentifier # F9D7)
Bajt Definicja parametru Rozdzielczość Zakres roboczy
1 - 4 Określono znacznik czasu pozycji pojazdu. nie dotyczy TimeReal
5 Dokładność GNSS nie dotyczy GNSSAccuracy
6 - 11 Pozycja pojazdu nie dotyczy GeoCoordinates
12 Status uwierzytelnienia nie dotyczy PositionAuthenticationStatus
13 Bieżący kraj nie dotyczy NationNumeric
14 Bieżący region nie dotyczy RegionNumeric
Uwaga: po aktualizacji pozycji pojazdu aktualizacja bieżą­
cego kraju i regionu może zostać opóźniona.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 391
Dodatek 9
HOMOLOGACJA TYPU WYKAZ MINIMUM WYMAGANYCH BADAŃ
SPIS TREŚCI
1. WPROWADZENIE
2. BADANIA FUNKCJONALNOŚCI PRZYRZĄDU REJESTRUJĄCEGO
3. BADANIA FUNKCJONALNOŚCI CZUJNIKA RUCHU
4. BADANIA FUNKCJONALNOŚCI KART DO TACHOGRAFU
5. BADANIA URZĄDZENIA ZEWNĘTRZNEGO GNSS
▼M1
6. BADANIA ZEWNĘTRZNEGO URZĄDZENIA DO ŁĄCZNOŚCI NA
ODLEGŁOŚĆ
▼B
7. BADANIA FUNKCJONALNOŚCI PAPIERU
8. BADANIA INTEROPERACYJNOŚCI
▼M3
9. BADANIA OSNMA
▼B
1. WPROWADZENIE
1.1. Homologacja typu
Homologacja typu WE urządzenia rejestrującego (lub elementu składo­
wego) lub karty do tachografu opiera się na następujących dokumentach:
▼M1
— świadectwie bezpieczeństwa, opartym na specyfikacjach normy
„Common Criteria”, w odniesieniu do celu bezpieczeństwa w pełni zgod­
nego z celami przedstawionymi w dodatku 10 do niniejszego załą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łącz­
nika).
W niniejszym dodatku określa się, które badania, jako minimum, musi
przeprowadzić organ państwa członkowskiego w ramach badań funkcjo­
nalnoś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 przepro­
wadza 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 badaniami, które mają zostać przeprowadzone) w ramach
certyfikacji bezpieczeństwa, są w niniejszym dodatku oznaczone
symbolem „*”.
Ponumerowane wymogi odnoszą się do tekstu głównego załącznika, nato­
miast pozostałe wymogi odnoszą się do innych dodatków (np. PIC_001
odnosi się do wymogu PIC_001 zawartego w dodatku 3 Piktogramy).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 392
W niniejszym dodatku oddzielnie przedstawiono informacje na temat
homologacji 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ła­
dowe. Badanie funkcjonalności czujnika ruchu (lub urządzenia zewnętrz­
nego GNSS) wykonuje się wraz z badaniem funkcjonalności przyrządu
rejestrującego i odwrotnie.
Nie wymaga się zapewnienia interoperacyjności między każdym 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.
▼M3
Organ państwa członkowskiego odpowiedzialny za badania funkcjonal­
ności przyrządu rejestrującego lub urządzenia zewnętrznego GNSS musi
upewnić się, że wbudowany odbiornik GNSS przeszedł pomyślnie badania
OSNMA określone w niniejszym dodatku. Badania te uznaje się za część
badań funkcjonalności przyrządu rejestrującego lub urządzenia zewnętrz­
nego GNSS.
▼B
1.2. Odniesienia
W niniejszym dodatku używa się następujących odniesień:
IEC 60068-2-1: Badania środowiskowe – Część 2-1: Próby – Próba A:
Zimno
IEC 60068-2-2: Podstawowe procedury badań środowiskowych – Część 2:
Próby – Próba B: Suche gorąco (harmoniczne).
IEC 60068-2-6: Badania środowiskowe – Część 2: Próby – Próba Fc:
Wibracje
IEC 60068-2-14: Badania środowiskowe – Część 2-14: Próby – Pró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 elek­
tryczne przenoszone przez przewodzenie i przez sprzężenie – Część 1:
Definicje i postanowienia ogólne
ISO 7637-2 Pojazdy drogowe – Zakłócenia elektryczne przenoszone przez
przewodzenie i przez sprzężenie – Część 2: Przewodzenie 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 — 21.08.2023 — 003.002 — 393
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 identyfi­
kacyjne – 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 rejes­
trującymi)
ISO 16844-4 Pojazdy drogowe – Systemy tachograficzne – Część 4:
Interfejs CAN
ISO 16844-6 Pojazdy drogowe – Systemy tachograficzne – Część 6:
Diagnostyka
ISO 16844-7 Pojazdy drogowe – Systemy tachograficzne – Część 7:
Parametry
ISO 534 Papier i tektura – Oznaczanie grubości, gęstości pozornej i obję­
tości właściwej
▼M3
RGODP Sprawozdanie techniczne JRC – Receiver guidelines for OSNMA
data processing (Wytyczne dla odbiorników w zakresie przetwarzania
danych OSNMA)
▼B
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
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 394
Nr Badanie Opis Powiązane wymogi
▼M3
3.1 Obsługiwane funkcje 02, 03, 04, 05, 07, 382,
3.2 Tryby pracy 09 do 11*, 134, 135
3.3 Prawa dostępu do funkcji i danych 12*, 13*, 382, 383, 386 do 389
3.4 Monitorowanie wkładania i wyjmowania kart 15, 16, 17, 18, 19*, 20*, 134
3.5 Pomiar prędkości, pozycji i odległości 21 do 37
3.6 Pomiar czasu (badanie przeprowadzone w temperaturze 20 °C) 38 do 43
3.7 Monitorowanie czynności kierowcy 44 do 53, 134
3.8 Monitorowanie stanu prowadzenia pojazdu 54, 55, 134
3.9 Dane wprowadzane przez kierowców 56 do 62c
3.10 Zarządzanie blokadami firmowymi 63 do 68
3.11 Monitorowanie czynności kontrolnych 69, 70
3.12 Wykrywanie zdarzeń lub usterek 71 do 88a, 134
3.13 Dane identyfikujące sprzęt 93*, 94*, 97, 100
3.14 Dane rejestrowane przy wkładaniu i wyjmowaniu karty kierowcy lub
warsztatowej
102* do 104*
3.15 Dane dotyczące czynności kierowcy 105* do 107*
3.16 Dane dotyczące miejsc i pozycji 108* do 112*
3.17 Dane dotyczące licznika kilometrów 113* do 115*
3.18 Dane szczegółowe dotyczące prędkości 116*
3.19 Dane dotyczące zdarzeń 117*
3.20 Dane dotyczące usterek 118*
3.21 Dane dotyczące kalibracji 119* do 121*
3.22 Dane dotyczące korekty czasu 124*, 125*
3.23 Dane dotyczące czynności kontrolnych 126*, 127*
3.24 Dane dotyczące blokad firmowych 128*
3.25 Dane dotyczące czynności pobierania 129*
3.26 Dane dotyczące stanów szczególnych 130*, 131*
3.27 Dane karty do tachografu 132*, 133*
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 395
Nr Badanie Opis Powiązane wymogi
3.28 Przekroczenia granicy 133a* do 133d*
3.29 Operacja załadunku/rozładunku 133e* do 133i*
3.30 Mapa cyfrowa 133j* do 133t*
3.31 Rejestrowanie i przechowywanie danych na kartach do tachografów 136, 137, 138*, 139*, 141*,
142, 143
144, 145, 146*, 147*, 147a*,
147b*, 148*, 149, 150, 150a
3.32 Wyświetlanie 90, 134,
151 do 168,
PIC_001, DIS_001
3.33 Drukowanie 90, 134,
169 do 181, PIC_001,
PRT_001 do PRT_014
3.34 Ostrzeganie 134, 182 do 191,
PIC_001
3.35 Pobieranie danych na nośnik zewnętrzny 90, 134, 192 do 196
3.36 Łączność na odległość na potrzeby ukierunkowanych kontroli drogo­
wych
197 do 199
3.37 Wymiana danych z dodatkowymi urządzeniami zewnętrznymi 200, 201
3.38 Kalibracja 202 do 206*, 383, 384, 386
do 391
3.39 Drogowe kontrole kalibracji 207 do 209
3.40 Korekta czasu 210 do 212*
3.41 Monitorowanie przekroczeń granicy 226a do 226c
3.42 Aktualizacja oprogramowania 226d do 226f
3.43 Niezakłócanie funkcji dodatkowych 06, 425
3.44 Interfejs czujnika ruchu 02, 122
3.45 Urządzenie zewnętrzne GNSS 03, 123
3.46 Sprawdzenie, czy VU wykrywa, rejestruje i zapisuje zdarzenie
(zdarzenia) lub usterkę (usterki) określone przez producenta VU, gdy
sparowany czujnik ruchu reaguje na pola magnetyczne zaburzające
wykrywanie ruchu pojazdu.
217
3.47 Pakiet szyfrów i standardowe parametry domeny CSM_48, CSM_50
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 396
Nr Badanie Opis Powiązane wymogi
4. Badania środowiskowe
4.1 Temperatura Sprawdzenie funkcjonalności za pomocą:
badania zgodnie z normą ISO 16750-4,
rozdział 5.1.1.2: Próba eksploatacyjna
w niskiej temperaturze (72 h w temperaturze
-20 °C).
Badanie to odnosi się do normy IEC 60068-2-
1: Badania środowiskowe – Część 2-1: Próby
– Próba A: Zimno
badania zgodnie z normą ISO 16750-4:
Rozdział 5.1.2.2: Próba eksploatacyjna
w wysokiej temperaturze (72 h w tempera­
turze 70 °C).
Badanie to odnosi się do normy IEC 60068-2-
2: Podstawowe procedury badań środowisko­
wych – Część 2: Próby – Próba B: Suche
gorąco;
badania zgodnie z normą ISO 16750-4:
Rozdział 5.3.2: Nagła zmiana temperatury
z określonym okresem przejściowym (-20 °C
/ 70 °C, 20 cykli, czas przebywania: 2 h
w każdej temperaturze).
Można przeprowadzić skrócony zestaw badań
(spośród tych zdefiniowanych w sekcji 3
niniejszej tabeli) w niższej temperaturze,
wyższej temperaturze i w czasie cykli
temperaturowych.
213
4.2 Wilgotność Sprawdzenie odporności przyrządu rejestrują­
cego na cykliczne zmiany wilgotności (próba
gorąca) za pomocą próby wg normy IEC
60068-2-30, w sześciu 24-godzinnych
cyklach, w każdym ze zmieniającą się tempe­
raturą od +25 °C do +55 °C i wilgotnością
względną 97 % w temperaturze +25 °C
i 93 % w temperaturze +55 °C
214
4.3 M/echanika 1. Drgania harmoniczne:
sprawdzenie odporności przyrządu rejes­
trującego na drgania harmoniczne o nastę­
pujących właściwościach:
stałe przemieszczenie przy częstotliwości
5–11 Hz: 10-milimetrowa amplituda;
stałe przyspieszenie przy częstotliwości
11–300 Hz: 5g.
Wymóg ten sprawdza się za pomocą próby
Fc wg normy IEC 60068-2-6, z mini­
malnym czasem trwania próby 3 × 12 h
(12 h na oś).
ISO 16750-3 nie wymaga przeprowadzenia
badania drgań harmonicznych w przypadku
urządzeń znajdujących się w oddzielnej
kabinie pojazdu.
2. Drgania swobodne:
Próba zgodnie z normą ISO 16750-3:
Rozdział 4.1.2.8: Próba VIII: Pojazd użyt­
kowy, oddzielna kabina pojazdu.
219
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 397
Nr Badanie Opis Powiązane wymogi
Próba drgań swobodnych: 10...2000 Hz,
wertykalna średnia kwadratowa 21,3 m/s 2 ,
wzdłużna średnia kwadratowa 11,8 m/s 2 ,
poprzeczna średnia kwadratowa 13,1 m/s 2 , 3
osie, 32 h na oś, w tym cykl temperaturowy
-20...70 °C.
Badanie to odnosi się do normy IEC 60068-2-
64: Badania środowiskowe – Część 2-64:
Próby – Próba Fh: Wibracje szerokopasmowe
losowe i wytyczne
3. Udary:
udar mechaniczny przy impulsie półsinu­
soidalnym 3 g wg normy ISO 16750.
Opisane powyżej badania przeprowadza się
na różnych próbkach urządzeń poddawanych
badaniom.
4.4 Ochrona przed wodą
i ciałami obcymi
Badanie zgodnie z normą ISO 20653:
Pojazdy drogowe – Stopień ochrony (kod
IP) – Ochrona urządzeń elektrycznych przed
ciałami obcymi, wodą i dostępem (bez zmian
parametrów); minimalna wartość IP – 40
220, 221
4.5 Zabezpieczenie nadna­
pięciowe
Sprawdzenie odporności przyrządu rejestrują­
cego na napięcie zasilania:
wersje 24 V: 34 V przy +40 °C przez
1 godzinę
wersje 12 V: 17 V przy +40 °C przez
1 godzinę
(ISO 16750-2)
216
4.6 Zabezpieczenie przed
odwróceniem polary­
zacji
Sprawdzenie odporności przyrządu rejestrują­
cego na odwrócenie biegunów napięcia zasi­
lającego.
(ISO 16750-2)
216
4.7 Zabezpieczenie zwar­
ciowe
Sprawdzenie, czy sygnały wyjściowe są
zabezpieczone przed zwarciem do napięcia
zasilającego i do masy.
(ISO 16750-2)
216
5. Badania EMC
5.1 Emisje radiacyjne
i wrażliwość na radiację
Zgodność z regulaminem nr 10 EKG ONZ 218
5.2 Wyładowania elektro­
statyczne
Zgodność z normą ISO 10605:2008 +
Sprostowanie techniczne:2010 +
AMD1:2014: +/- 4kV w przypadku styku
i +/- 8kV w przypadku rozładowania do
powietrza
218
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 398
Nr Badanie Opis Powiązane wymogi
5.3 Wrażliwość na stany
nieustalone w zasilaniu
W przypadku wersji 24 V: zgodność z normą
ISO 7637-2 i wersją 3 regulaminu nr 10 EKG
ONZ:
impuls 1a: Vs = -450 V, Ri = 50 omów
impuls 2a: Vs = +37 V, Ri = 2 omy
impuls 2b: Vs = +20 V, Ri = 0,05 oma
impuls 3a: Vs = -150 V, Ri = 50 omów
impuls 3b: Vs = +150 V, Ri = 50 omów
impuls 4: Vs = -16 V Va = -12V, t6 = 100ms
impuls 5: Vs = +120 V, Ri = 2,2 oma, td =
250 ms
W przypadku wersji 12V: zgodność z normą
ISO 7637-1 i wersją 3 regulaminu nr 10 EKG
ONZ:
impuls 1: Vs = -75 V, Ri = 10 omów
impuls 2a: Vs = +37 V, Ri = 2 omy
impuls 2b: Vs = +10 V, Ri = 0,05 oma
impuls 3a: Vs = -112 V, Ri = 50 omów
impuls 3b: Vs = +75 V, Ri = 50 omów
impuls 4: Vs = -6 V, Va = -5 V, t6 = 15 ms
impuls 5: Vs = +65 V, Ri = 3 omy, td = 100
ms
Impuls 5 należy testować tylko w przypadku
przyrządów rejestrujących przeznaczonych do
zainstalowania w pojazdach, w których nie
zainstalowano zewnętrznego, wspólnego
zabezpieczenia przed spadkiem obciążenia.
Aby uzyskać informacje na temat propozycji
zabezpieczenia przed spadkiem obciążenia,
zob. norma ISO 16750-2 wydanie 4, rozdział
4.6.4.
218
▼B
3. BADANIA FUNKCJONALNOŚCI CZUJNIKA RUCHU
Nr Badanie Opis Powiązane wymogi
1. Badanie administracyjne
1.1 Dokumentacja Prawidłowość dokumentacji
2. Kontrola wizualna
2.1 Zgodność z dokumentacją
2.2 Identyfikacja/oznakowanie 225, 226,
2.3 Materiały 219–223
2.4 Plombowanie 398, 401–405
3. Badania funkcjonalności
3.1 Dane identyfikacyjne czujnika 95–97*
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 399
Nr Badanie Opis Powiązane wymogi
3.2 Parowanie czujnik ruchu — przyrząd rejestrujący 122*, 204
3.3 Wykrywanie ruchu
Dokładność pomiaru ruchu
30–35
3.4 Interfejs przyrządu rejestrującego 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 tempera­
turze To max ,
badania zgodnie z normą ISO 16750-4:
Rozdział 5.1.1.2: Próba eksploatacyjna w niskiej
temperaturze (24 h w temperaturze – 40 °C).
Badanie to odnosi się do normy IEC 60068-2-1:
Badania środowiskowe – Część 2-1: Próby –
Próba A: Zimno, wg próby Bd w ramach
normy IEC 68-2-2, z czasem trwania 96 h
w najniższej temperaturze – 40 °C
badania zgodnie z normą ISO 16750-4:
Rozdział 5.1.2.2: Próba eksploatacyjna w niskiej
temperaturze (96 h w temperaturze 135 °C).
Badanie to odnosi się do normy IEC 60068-2-2:
Podstawowe procedury badań środowiskowych
– Część 2: Próby – Próba B: Suche gorąco;
213
4.2 Cykle temperaturowe Badanie zgodnie z normą ISO 16750-4:
Rozdział 5.3.2: Nagła zmiana temperatury
z określonym okresem przejściowym (– 40
°C/135 °C, 20 cykli, czas przebywania: 30 min
w każdej temperaturze).
IEC 60068-2-14: Badania środowiskowe –
Część 2-14: Próby – Próba N: Zmiany tempe­
ratury
213
4.3 Cykle wilgotności Sprawdzenie funkcjonalności (zdefiniowanej
w ramach badania nr 3.3) za pomocą próby
Db wg normy IEC 60068-2-30, w sześciu 24-
godzinnych cyklach, w każdym ze zmieniającą
się temperaturą od + 25 °C do + 55 °C i wilgot­
nością względną 97 % w + 25 °C i 93 %
w + 55 °C
214
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 400
Nr Badanie Opis Powiązane wymogi
4.4 Drgania ISO 16750-3: Rozdział 4.1.2.6: Próba IV:
Pojazd użytkowy, silnik, skrzynia biegów
Badanie drgań w trybie mieszanym obejmujące:
a) badanie drgań harmonicznych, 20…520 Hz,
11,4 … 120 m/s 2 ,
b) badanie drgań swobodnych, 10 … 2 000 Hz,
średnia kwadratowa 177 m/s 2 ,
94 h na oś, z cyklem temperaturowym
-20…70 °C).
Badanie to odnosi się do normy IEC 60068-2-
80: Badania środowiskowe – Część 2-80: Próby
– Próba Fi: Wibracje – tryb mieszany
219
4.5 Udar mechaniczny ISO 16750-3: Rozdział 4.2.3: Próba IV: Próba
dla urządzeń znajdujących się w skrzyni biegów
lub na skrzyni biegów
Udar o impulsie półsinusoidalnym, przyspie­
szenie do uzgodnienia w zakresie 3 000 …
15 000 m/s 2 , czas trwania impulsu do uzgod­
nienia, ale
nienia.
Badanie to odnosi się do normy IEC 60068-2-
27: Badania środowiskowe – Część 2: Próby –
Próba Ea i wytyczne: Udary
219
4.6 Ochrona przed wodą i ciałami
obcymi
Badanie zgodnie z normą ISO 20653: Pojazdy
drogowe – Stopień ochrony (kod IP) – Ochrona
urządzeń elektrycznych przed ciałami obcymi,
wodą i dostępem
(docelowa wartość IP – 64)
220, 221
4.7 Zabezpieczenie przed odwró­
ceniem polaryzacji
Sprawdzenie odporności czujnika ruchu na
odwrócenie biegunów napięcia zasilającego.
216
4.8 Zabezpieczenie zwarciowe Sprawdzenie, czy sygnały wyjściowe są zabez­
pieczone przed zwarciem do napięcia zasilają­
cego i do masy.
216
5. Badania kompatybilności elektromagnetycznej
5.1 Emisje radiacyjne i wrażli­
wość na radiację
Sprawdzenie zgodności z regulaminem nr 10
EKG ONZ
218
5.2 Wyładowania elektrosta­
tyczne
Zgodność z normą ISO 10605:2008 + Sprosto­
wanie techniczne:2010 + AMD1:2014: +/– 4kV
w przypadku styku i +/– 8kV w przypadku
rozładowania do powietrza
218
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 401
Nr Badanie Opis Powiązane wymogi
5.3 Wrażliwość na stany nieusta­
lone na liniach danych
W przypadku wersji 24 V: zgodność z normą
ISO 7637-2 i wersją 3 regulaminu nr 10 EKG
ONZ:
impuls 1a: Vs = – 450 V, Ri = 50 omów
impuls 2a: Vs = + 37 V, Ri = 2 omy
impuls 2b: Vs = + 20 V, Ri = 0,05 oma
impuls 3a: Vs = – 150 V, Ri = 50 omów
impuls 3b: Vs = + 150 V, Ri = 50 omów
impuls 4: Vs = – 16 V Va = – 12V, t6 = 100ms
impuls 5: Vs = + 120 V, Ri = 2,2 oma, td =
250 ms
W przypadku wersji 12 V: zgodność z normą
ISO 7637-1 i wersją 3 regulaminu nr 10 EKG
ONZ:
impuls 1: Vs = – 75 V, Ri = 10 omów
impuls 2a: Vs = + 37 V, Ri = 2 omy
impuls 2b: Vs = + 10 V, Ri = 0,05 oma
impuls 3a: Vs = – 112 V, Ri = 50 omów
impuls 3b: Vs = + 75 V, Ri = 50 omów
impuls 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms
impuls 5: Vs = + 65 V, Ri = 3 omy, td =
100 ms
Impuls 5 należy testować tylko w przypadku
przyrządów rejestrujących przeznaczonych do
zainstalowania w pojazdach, w których nie
zainstalowano zewnętrznego, wspólnego zabez­
pieczenia przed spadkiem obciążenia.
Aby uzyskać informacje na temat propozycji
zabezpieczenia przed spadkiem obciążenia,
zob. norma ISO 16750-2 wydanie 4. rozdział
4.6.4.
218
4. BADANIA FUNKCJONALNOŚCI KART DO TACHOGRAFU
Badania zgodnie z niniejszą sekcją 4
nr 5 „Testy protokołów”,
nr 6 „Struktura karty” i
nr 7 „Badania funkcjonalności”
może przeprowadzić jednostka dokonująca oceny lub jednostka 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 — 21.08.2023 — 003.002 — 402
Nr Badanie Opis Powiązane wymogi
1. Badanie administracyjne
1.1 Dokumentacja Prawidłowość dokumentacji
2 Karta
2.1 Nadruk
Sprawdzenie, czy wszystkie zabezpieczenia
i widoczne dane są prawidłowo nadrukowane
i zgodne z wymogami.
[Oznaczenie]
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 227)
Na awersie znajdują się:
wyrażenia „Karta kierowcy”, „Karta kontrolna”,
„Karta warsztatowa”, lub „Karta firmowa” nadruko­
wane wielkimi literami w języku urzędowym lub
językach urzędowych państwa członkowskiego
wydającego kartę, zgodnie z typem karty.
[Nazwa państwa członkowskiego]
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 228)
Na awersie znajdują się:
nazwa państwa członkowskiego wydającego kartę
(nieobowiązkowo).
[Znak]
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 229)
Na awersie znajdują się:
wyróżniający znak państwa członkowskiego wydają-
cego kartę, drukowany w negatywie w niebieskim
prostokącie i otoczony 12 żółtymi gwiazdkami.
[Oznaczenie liczby]
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 232)
Na awersie znajdują się:
objaśnienia numerowanych pozycji znajdujących się
na awersie karty.
[Kolor]
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 234)
Karty do tachografu drukuje się w następujących
dominujących kolorach tła:
— karta kierowcy: biały,
— karta warsztatowa: czerwony,
— karta kontrolna: niebieski,
— karta firmowa: żółty.
227–229, 232, 234–
236
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 403
Nr Badanie Opis Powiązane wymogi
[Zabezpieczenie]
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 235)
Karty do tachografu mają przynajmniej następujące
zabezpieczenia przed fałszowaniem i manipulowa-
niem:
— zabezpieczający wzór tła z drukowanym drobnym
giloszem i tęczą,
— przynajmniej dwubarwną linię wykonaną techniką
mikrodruku.
[Oznakowania]
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 236)
Państwa członkowskie mogą dodawać kolory lub
oznakowania, takie jak symbole państwowe i zabez-
pieczenia.
[Znak homologacji]
Karta do tachografu jest opatrzona znakiem homo-
logacji.
Znak homologacji składa się z:
— prostokąta, wewnątrz którego jest umieszczona
litera „e”, po której następuje liczba lub litera
oznaczająca państwo, które wydało homologację,
— numeru homologacji typu odpowiadającego nu-
merowi świadectwa homologacji typu karty do
tachografu, umieszczonego bezpośrednio obok
wspomnianego wyżej prostokąta.
2.2 Próby mechaniczne
[Wielkość karty]
Karty do tachografu muszą być zgodne z wymo­
gami normy
ISO/IEC 7810: Karty identyfikacyjne – Charakte­
rystyki fizyczne,
[5] Wymiary karty
[5.1] Wielkość karty
[5.1.1] Wymiary i tolerancje karty
Typ karty ID-1 Karta nieużywana
[Krawędzie karty]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[5] Wymiary karty
[5.1] Wielkość karty
[5.1.2] Krawędzie karty
240, 243
ISO/IEC 7810
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 404
Nr Badanie Opis Powiązane wymogi
[Struktura karty]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[6] Struktura karty
[Materiały, z których wykonane są karty]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[7] Materiały, z których wykonane są karty
[Odporność na zginanie]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[8] Charakterystyki kart
[8.1] Odporność na zginanie
[Toksyczność]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[8] Charakterystyki kart
[8.3] Toksyczność
[Odporność na działanie czynników chemicznych]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[8] Charakterystyki kart
[8.4] Odporność na działanie czynników chemicznych
[Stabilność kart]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[8] Charakterystyki kart
[8.5] Stabilność wymiarowa kart i odkształcenie
wywołane przez temperaturę i wilgotność
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 405
Nr Badanie Opis Powiązane wymogi
[Światło]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[8] Charakterystyki kart
[8.6.] Światło
[Trwałość]
Załącznik 1C rozdział 4.4 „Wymagania środowiskowe
i elektryczne”, 241)
Karty do tachografu prawidłowo pracują przez okres
pięciu lat, jeżeli są używane w określonych warun-
kach środowiskowych i elektrycznych.
[Wytrzymałość na rozwarstwienie]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[8] Charakterystyki kart
[8.8] Wytrzymałość na rozwarstwienie
[Przyczepność lub blokowanie]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[8] Charakterystyki kart
[8.9] Przyczepność lub blokowanie
[Odkształcenie]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[8] Charakterystyki kart
[8.11] Ogólne odkształcenie kart
[Odporność na działanie wysokich temperatur]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[8] Charakterystyki kart
[8.12] Odporność na działanie wysokich temperatur
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 406
Nr Badanie Opis Powiązane wymogi
[Zniekształcenia powierzchni]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[8] Charakterystyki kart
[8.13] Zniekształcenia powierzchni
[Zanieczyszczenie]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810: Karty identyfikacyjne – Charakterys-
tyki fizyczne,
[8] Charakterystyki kart
[8.14] Zanieczyszczenie i interakcje komponentów
kart
2.3 Próby mechaniczne
z wbudowanym
modułem chipowym
[Zginanie]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810:2003/zmiana 1:2009, Karty identyfi­
kacyjne – Charakterystyki fizyczne, zmiana 1:
Kryteria dotyczące kart elektronicznych
[9.2] Dynamiczne naprężenie zginające
Łączna liczba cykli zginania: 4 000.
[Skręcanie]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810:2003/zmiana 1:2009, Karty identyfika-
cyjne – Charakterystyki fizyczne, zmiana 1: Kryteria
dotyczące kart elektronicznych
[9.3] Dynamiczne naprężenie skręcające
Łączna liczba cykli skręcania: 4 000.
ISO/IEC 7810
3 Moduł
3.1 Moduł
Moduł to obudowa chipu i płyta stykowa.
[Profil powierzchni]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7816-1:2011, Karty identyfikacyjne – Karty
elektroniczne – Część 1: Karty stykowe – Charakte­
rystyki fizyczne
[4.2] Profil powierzchni styków
ISO/IEC 7816
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 407
Nr Badanie Opis Powiązane wymogi
[Wytrzymałość mechaniczna]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7816-1:2011, Karty identyfikacyjne – Karty
elektroniczne – Część 1: Karty stykowe – Charakte­
rystyki fizyczne
[4.3] Wytrzymałość mechaniczna (karty i styków)
[Rezystancja]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7816-1:2011, Karty identyfikacyjne – Karty
elektroniczne – Część 1: Karty stykowe – Charakter-
ystyki fizyczne
[4.4] Rezystancja (styków)
[Wymiary]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7816-2:2007, Karty identyfikacyjne – Karty
elektroniczne – Część 2: Karty stykowe – Wymiary
i rozmieszczenie styków
[3] Wymiary styków
[Rozmieszczenie]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7816-2:2007, Karty identyfikacyjne – Karty
elektroniczne – Część 2: Karty stykowe – Wymiary
i rozmieszczenie styków
[4] Liczba i rozmieszczenie styków
W przypadku modułów z sześcioma stykami styki
„C4” i „C8” nie są objęte tym wymogiem dotyczącym
próby.
4 Chip
4.1 Chip
[Temperatura pracy]
Chip karty do tachografu pracuje w temperaturze
otoczenia wynoszącej od – 25 °C do + 85 °C.
241–244
Regulamin nr 10
EKG ONZ
ISO/IEC 7810
ISO/IEC 10373
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 408
Nr Badanie Opis Powiązane wymogi
[Temperatura i wilgotność]
Załącznik 1C rozdział 4.4 „Wymagania środowi­
skowe i elektryczne”, 241)
Karty do tachografu prawidłowo pracują we wszyst­
kich warunkach klimatycznych normalnie występują­
cych na terytorium Wspólnoty, przynajmniej
w zakresie temperatur od – 25 do + 70 °C ze spora­
dycznymi temperaturami szczytowymi do +85 °C,
przy czym „sporadyczny” oznacza nie dłużej niż 4
godziny jednorazowo i nie więcej niż 100 razy
w okresie eksploatacji karty.
Karty do tachografu naraża się kolejno na następu­
jące temperatury i wilgotność przez określony czas.
Po każdym etapie kartę do tachografu bada się pod
kątem funkcjonalności elektrycznej.
1. Temperatura – 20 °C przez 2 h.
2. Temperatura +/– 0 °C przez 2 h.
3. Temperatura + 20 °C, wilgotność względna
50 %, przez 2 h.
4. Temperatura + 50 °C, wilgotność względna
50 %, przez 2 h
5. Temperatura + 70 °C, wilgotność względna
50 %, przez 2 h.
Temperatura jest zwiększana sporadycznie do + 85
°C, wilgotność względna wynosi 50 %, przez 60
min.
6. Temperatura + 70 °C, wilgotność względna
85 %, przez 2 h.
Temperatura jest zwiększana sporadycznie do + 85
°C, wilgotność względna wynosi 85 %, przez 30
min.
[Wilgotność]
Załącznik 1C rozdział 4.4 „Wymagania środowiskowe
i elektryczne”, 242)
Karty do tachografu prawidłowo pracują w zakresie
wilgotności od 10 % do 90 %.
[Kompatybilność elektromagnetyczna – EMC]
Załącznik 1C rozdział 4.4 „Wymagania środowiskowe
i elektryczne”, 244)
W trakcie pracy karty do tachografu zachowują
zgodność z regulaminem nr 10 EKG ONZ pod
względem kompatybilności elektromagnetycznej.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 409
Nr Badanie Opis Powiązane wymogi
[Elektryczność statyczna]
Załącznik 1C rozdział 4.4 „Wymagania środowiskowe
i elektryczne”, 244)
W trakcie pracy karty do tachografu muszą być
zabezpieczone przed wyładowaniami elektrostatycz-
nymi.
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810:2003/zmiana 1:2009, Karty identyfika-
cyjne – Charakterystyki fizyczne, zmiana 1: Kryteria
dotyczące kart elektronicznych
[9.4] Elektryczność statyczna
[9.4.1] Karty elektroniczne ze stykami
Napięcie próbne: 4 000 V.
[Urządzenia rentgenowskie]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810:2003/zmiana 1:2009, Karty identyfika-
cyjne – Charakterystyki fizyczne, zmiana 1: Kryteria
dotyczące kart elektronicznych
[9.1.] Urządzenia rentgenowskie
[Promieniowanie ultrafioletowe]
ISO/IEC 10373-1:2006, Karty identyfikacyjne –
Metody badań – Część 1: Charakterystyki ogólne
[5.11] Promieniowanie ultrafioletowe
[trzykołowe]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 10373-1:2006/zmiana 1:2012, Karty identy-
fikacyjne – Metody badań – Część 1: Charakterystyki
ogólne, zmiana 1
[5.22] Karta elektroniczna – Wytrzymałość mechan-
iczna: trzykołowy test kart elektronicznych ze stykami
[Nawijanie]
Karty do tachografu muszą być zgodne z wymogami
normy
MasterCard CQM V2.03:2013
[11.1.3] R-L3-14-8: Próba trwałości nawijania
[13.2.1.32] TM-422: Niezawodność mechaniczna:
próba nawijania
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 410
Nr Badanie Opis Powiązane wymogi
4.2 Próby mechaniczne
modułu chipowego
wbudowanego w kartę
-> takie same jak
w sekcji 2.3
[Zginanie]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810:2003/zmiana 1:2009, Karty identyfi­
kacyjne – Charakterystyki fizyczne, zmiana 1:
Kryteria dotyczące kart elektronicznych
[9.2] Dynamiczne naprężenie zginające
Łączna liczba cykli zginania: 4 000.
[Skręcanie]
Karty do tachografu muszą być zgodne z wymogami
normy
ISO/IEC 7810:2003/zmiana 1:2009, Karty identyfika-
cyjne – Charakterystyki fizyczne, zmiana 1: Kryteria
dotyczące kart elektronicznych
[9.3] Dynamiczne naprężenie skręcające
Łączna liczba cykli skręcania: 4 000.
ISO/IEC 7810
5 Testy protokołów
5.1 Ciąg ATR Sprawdzenie zgodności ciągu ATR. ISO/IEC 7816-3
TCS_14, TCS_17,
TCS_18
5.2 T=0 Sprawdzenie zgodności protokołu T=0. ISO/IEC 7816-3
TCS_11, TCS_12,
TCS_13, TCS_15
5.3 PTS Sprawdzenie zgodności polecenia PTS przez usta­
wienie T = 1 z T = 0.
ISO/IEC 7816-3
TCS_12, TCS_19,
TCS_20, TCS_21
5.4 T=1 Sprawdzenie zgodności protokołu T = 1. ISO/IEC 7816-3
TCS_11, TCS_13,
TCS_16
6 Struktura karty
6.1 Sprawdzenie zgodności struktury plików na karcie
przez sprawdzenie, czy na karcie są wymagane pliki
oraz sprawdzenie warunków dostępu do plików.
TCS_22–TCS_28
TCS_140–TCS_179
7 Badania funkcjonalności
7.1 Normalne przetwa­
rzanie
Sprawdzenie co najmniej raz każdego, dozwolonego
użycia każdego polecenia (np.: sprawdzenie polecenia
UPDATE BINARY z CLA = „00”, CLA = „0C”
i z różnymi parametrami P1, P2 i Lc).
Sprawdzenie, czy karta rzeczywiście wykonuje czyn­
ności (np.: odczytując plik poleceniem wykonywanym
na tym pliku).
TCS_29–TCS_139
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 411
Nr Badanie Opis Powiązane wymogi
7.2 Komunikaty błędu Sprawdzenie co najmniej raz każdego komunikatu
błędu (określonego w dodatku 2) dla każdego pole­
cenia.
Sprawdzenie co najmniej raz każdego błędu ogólnego
(z wyjątkiem błędów integralności „6400” sprawdza­
nych w trakcie certyfikacji bezpieczeństwa).
7.3 Pakiet szyfrów i standardowe parametry domeny CSM_48, CSM_50
8 Personalizacja
8.1 Personalizacja
optyczna (Załącznik 1C rozdział 4.1 „Dane widzialne”, 230)
Na awersie znajdują się:
informacje szczególne dla wydanej karty.
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 231)
Na awersie znajdują się:
daty podaje się w formacie „dd/mm/rrrr” lub
„dd.mm.rrrr” (dzień, miesiąc, rok).
(Załącznik 1C rozdział 4.1 „Dane widzialne”, 235)
Karty do tachografu mają przynajmniej następujące
zabezpieczenia przed fałszowaniem i manipulowa-
niem:
— w obszarze zdjęcia zabezpieczający wzór tła
i zdjęcie-
zachodzą na siebie.
230, 231, 235
5. BADANIA URZĄDZENIA ZEWNĘTRZNEGO GNSS
Nr Badanie Opis Powiązane wymogi
1. Badanie administracyjne
1.1 Dokumentacja Prawidłowość dokumentacji
2. Kontrola wizualna urządzenia zewnętrznego GNSS
2.1 Zgodność z dokumentacją
2.2 Identyfikacja/oznakowanie 224–226
2.3 Materiały 219–223
3. Badania funkcjonalności
3.1 Dane identyfikacyjne czujnika 98, 99
3.2 Połączenie między zewnętrznym modułem GNSS a przyrządem rejestrującym 123, 205
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 412
Nr Badanie Opis Powiązane wymogi
3.3 Położenie GNSS 36, 37
3.4 Interfejs przyrządu rejestrującego, gdy odbiornik GNSS 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: Podstawowe
procedury badań środowiskowych – Część 2: Próby – Próba
B: Suche gorąco;
Badanie zgodnie z normą ISO 16750-4: Rozdział 5.3.2:
Nagła zmiana temperatury z określonym okresem przej­
ściowym (20 °C/70 °C, 20 cykli, czas przebywania: 1 h
w każdej temperaturze).
Można przeprowadzić skrócony zestaw badań (spośród tych
zdefiniowanych w sekcji 3 niniejszej tabeli) w niższej tempe­
raturze, wyższej temperaturze i w czasie cykli
temperaturowych.
213
4.2 Wilgotność Sprawdzenie odporności przyrządu rejestrującego na
cykliczne zmiany wilgotności (próba gorąca) za pomocą
próby Db wg normy IEC 60068-2-30, w sześciu 24-godzin­
nych cyklach, w każdym ze zmieniającą się temperaturą od
+ 25 °C do + 55 °C i wilgotnością względną 97 % w
+ 25 °C i 93 % w + 55 °C
214
4.3 Mechanika 1. Drgania harmoniczne:
sprawdzenie odporności przyrządu rejestrującego na
drgania harmoniczne o następujących właściwościach:
stałe przemieszczenie przy częstotliwości 5–11 Hz: 10-
milimetrowa amplituda;
stałe przyspieszenie przy częstotliwości 11–300 Hz: 5g.
Wymóg ten sprawdza się za pomocą próby Fc wg normy
IEC 60068-2-6, z minimalnym czasem trwania próby 3 ×
12 h (12 h na oś).
ISO 16750-3 nie wymaga przeprowadzenia testu drgań
harmonicznych w przypadku urządzeń znajdujących się
w oddzielnej kabinie pojazdu.
219
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 413
Nr Badanie Opis Powiązane wymogi
2. Drgania swobodne:
Próba zgodnie z ISO 16750-3: Rozdział 4.1.2.8: Próba
VIII: Pojazd użytkowy, oddzielna kabina pojazdu.
Próba drgań swobodnych: 10 … 2 000 Hz, wertykalna
średnia kwadratowa 21,3 m/s 2 , wzdłużna średnia kwadra-
towa 11,8 m/s 2 , poprzeczna średnia kwadratowa 13,1 m/s 2 ,
3 osie, 32 h na oś, w tym cykl temperaturowy – 20 …
70°C.
Badanie to odnosi się do normy IEC 60068-2-64: Badania
środowiskowe – Część 2-64: Próby – Próba Fh: Wibracje
szerokopasmowe losowe i wytyczne.
3. Udary:
udar mechaniczny przy impulsie półsinusoidalnym 3 g wg
normy ISO 16750.
Opisane powyżej badania przeprowadza się na różnych
próbkach urządzeń poddawanych badaniom.
4.4 Ochrona przed
wodą i ciałami
obcymi
Badanie zgodnie z normą ISO 20653: Pojazdy drogowe –
Stopień ochrony (kod IP) – Ochrona urządzeń elektrycznych
przed ciałami obcymi, wodą i dostępem (bez zmian para­
metrów)
220, 221
4.5 Zabezpieczenie
nadnapięciowe
Sprawdzenie odporności przyrządu rejestrującego na napięcie
zasilania:
216
wersje 24 V: 34 V przy + 40 °C
przez 1 godzinę
wersje 12 V: 17 V przy + 40 °C
przez 1 godzinę
(ISO 16750-2 rozdział 4.3)
4.6 Zabezpieczenie
przed odwróce­
niem polary­
zacji
Sprawdzenie odporności przyrządu rejestrującego na odwró­
cenie biegunów napięcia zasilającego.
(ISO 16750-2 rozdział 4.7)
216
4.7 Zabezpieczenie
zwarciowe
Sprawdzenie, czy sygnały wyjściowe są zabezpieczone przed
zwarciem do napięcia zasilającego i do masy.
(ISO 16750-2 rozdział 4.10)
216
5 Badania EMC
5.1 Emisje radia­
cyjne i wrażli­
wość na
radiację
Zgodność z regulaminem nr 10 EKG ONZ 218
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 414
Nr Badanie Opis Powiązane wymogi
5.2 Wyładowania
elektrostatyczne
Zgodność z normą ISO 10605:2008 + Sprostowanie tech­
niczne: 2010 + AMD1: 2014: +/– 4 kV w przypadku styku
i +/– 8 kV w przypadku rozładowania do powietrza
218
5.3 Wrażliwość na
stany nieusta­
lone w zasilaniu
W przypadku wersji 24 V: zgodność z normą ISO 7637-2
i wersją 3 regulaminu nr 10 EKG ONZ:
impuls 1a: Vs = – 450 V, Ri = 50 omów
impuls 2a: Vs = + 37 V, Ri = 2 omy
impuls 2b: Vs = + 20 V, Ri = 0,05 oma
impuls 3a: Vs = – 150 V, Ri = 50 omów
impuls 3b: Vs = + 150 V, Ri = 50 omów
impuls 4: Vs = – 16 V Va = – 12V, t6 = 100 ms
impuls 5: Vs = + 120 V, Ri = 2,2 oma, td = 250 ms
W przypadku wersji 12 V: zgodność z normą ISO 7637-1
i wersją 3 regulaminu nr 10 EKG ONZ:
impuls 1: Vs = – 75 V, Ri = 10 omów
impuls 2a: Vs = + 37 V, Ri = 2 omy
impuls 2b: Vs = + 10 V, Ri = 0,05 oma
impuls 3a: Vs = – 112 V, Ri = 50 omów
impuls 3b: Vs = + 75 V, Ri = 50 omów
impuls 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms
impuls 5: Vs = + 65 V, Ri = 3 omy, td = 100 ms
Impuls 5 należy testować tylko w przypadku przyrządów
rejestrujących przeznaczonych do zainstalowania w pojaz­
dach, w których nie zainstalowano zewnętrznego, wspólnego
zabezpieczenia przed spadkiem obciążenia.
Aby uzyskać informacje na temat propozycji zabezpieczenia
przed spadkiem obciążenia, zob. norma ISO 16750-2
wydanie 4. rozdział 4.6.4.
218
▼M1
6. BADANIE ZEWNĘTRZNEGO URZĄDZENIA DO ŁĄCZNOŚCI NA
ODLEGŁOŚĆ
Nr Badanie Opis Powiązane wymogi
1. Badanie administracyjne
1.1 Dokumentacja Prawidłowość doku­
mentacji
2. Kontrola wizualna
2.1. Zgodność z dokumentacją
2.2. Identyfikacja/oznakowanie 225, 226
2.3 Materiały 219–223
3. Badania funkcjonalności
3.1 Łączność na odległość na potrzeby ukierunkowanych kontroli 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 — 21.08.2023 — 003.002 — 415
Nr Badanie Opis Powiązane wymogi
4. Badania środowiskowe
4.1 Temperatura Sprawdzenie funkcjonalności za pomocą:
badania zgodnie z normą ISO 16750-4, rozdział 5.1.1.2:
Próba eksploatacyjna w niskiej temperaturze (72 h
w temperaturze -20 °C).
Badanie to odnosi się do normy IEC 60068-2-1: Badania
środowiskowe – Część 2-1: Próby – Próba A: Zimno
Badanie zgodnie z normą ISO 16750-4: Rozdział
5.1.2.2: Próba eksploatacyjna w wysokiej temperaturze
(72 h w temperaturze 70 °C).
Badanie to odnosi się do normy IEC 60068-2-2: Podsta­
wowe procedury badań środowiskowych – Część 2:
Próby – Próba B: Suche gorąco;
Badanie zgodnie z normą ISO 16750-4: Rozdział 5.3.2:
Nagła zmiana temperatury z określonym okresem przej­
ściowym (-20 °C/70 °C, 20 cykli, czas przebywania: 1 h
w każdej temperaturze).
Można przeprowadzić skrócony zestaw badań (spośród
tych zdefiniowanych w sekcji 3 niniejszej tabeli)
w niższej temperaturze, wyższej temperaturze i w czasie
cykli temperaturowych.
213
4.2 Ochrona przed
wodą i ciałami
obcymi
Badanie zgodnie z normą ISO 20653: Pojazdy drogowe
– Stopień ochrony (kod IP) – Ochrona urządzeń elek­
trycznych przed ciałami obcymi, wodą i dostępem
(wartość docelowa IP40)
220, 221
5 Badania EMC
5.1 Emisje radiacyjne
i wrażliwość na
radiację
Zgodność z regulaminem nr 10 EKG ONZ 218
5.2 Wyładowania elek­
trostatyczne
Zgodność z normą ISO 10605:2008 + Sprostowanie
techniczne: 2010 + AMD1:2014: +/- 4kV w przypadku
styku i +/- 8kV w przypadku rozładowania do powietrza
218
5.3 Wrażliwość na
stany nieustalone
w zasilaniu
W przypadku wersji 24 V: zgodność z normą ISO 7637-
2 i wersją 3 regulaminu nr 10 EKG ONZ:
impuls 1a: Vs = -450 V, Ri = 50 omów
impuls 2a: Vs = +37 V, Ri = 2 omy
impuls 2b: Vs = +20 V, Ri = 0,05 oma
impuls 3a: Vs = -150 V, Ri = 50 omów
impuls 3b: Vs = +150 V, Ri = 50 omów
impuls 4: Vs = -16 V, Va = -12V, t6 = 100 ms
impuls 5: Vs = +120 V, Ri = 2,2 oma, td = 250 ms
W przypadku wersji 12 V: zgodność z normą ISO 7637-
1 i wersją 3 regulaminu nr 10 EKG ONZ:
impuls 1: Vs = -75 V, Ri = 10 omów
impuls 2a: Vs = +37 V, Ri = 2 omy
impuls 2b: Vs = +10 V, Ri = 0,05 oma
impuls 3a: Vs = -112 V, Ri = 50 omów
218
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 416
Nr Badanie Opis Powiązane wymogi
impuls 3b: Vs = +75 V, Ri = 50 omów
impuls 4: Vs = -6 V, Va = -5 V, t6 = 15 ms
impuls 5: Vs = +65 V, Ri = 3 omy, td = 100 ms
Impuls 5 należy testować tylko w przypadku przyrządów
rejestrujących przeznaczonych do zainstalowania
w pojazdach, w których nie zainstalowano zewnętrz­
nego, wspólnego zabezpieczenia przed spadkiem obcią­
żenia.
Aby uzyskać informacje na temat propozycji zabezpie­
czenia przed spadkiem obciążenia, zob. norma ISO
16750-2 wydanie 4, rozdział 4.6.4.
▼B
7. BADANIA FUNKCJONALNOŚCI PAPIERU
Nr Badanie Opis Powiązane wymogi
1. Badanie administracyjne
1.1 Dokumentacja Prawidłowość dokumentacji
2 Badania ogólne
2.1 Liczba znaków
w wierszu
Kontrola wizualna wydruków 172
2.2 Minimalna wielkość
czcionki
Kontrola wizualna wydruków i kontrola znaków 173
2.3 Obsługiwane
zestawy znaków
Drukarka umożliwia drukowanie znaków określonych
w dodatku 1 rozdział 4 „Zestawy znaków”.
174
2.4 Definicja wydruków Sprawdzenie homologacji typu tachografu i przeprowa­
dzenie kontroli wizualnej wydruków
174
2.5 Czytelność i identyfi­
kacja wydruków
Kontrola wydruków
Potwierdzona sprawozdaniami z badań i protokołami
badań przez producenta.
Wszystkie numery homologacyjne tachografów,
z którymi można używać danego papieru do drukarek,
wydrukowano na papierze.
175, 177, 178
2.6 Dodawanie uwag
odręcznych
Kontrola wizualna: dostępne jest miejsce na podpis
kierowcy.
Dostępne jest miejsce na inne dodatkowe wpisy
odręczne.
180
2.7 Dodatkowe infor­
macje szczegółowe
na pierwszej stronie
kartki papieru
Pierwsza i druga strona kartki papieru mogą zawierać
dodatkowe szczegółowe dane i informacje.
Tego rodzaju dodatkowe szczegółowe dane i informacje
nie mogą ograniczać czytelności wydruków.
Kontrola wizualna
177, 178
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 417
Nr Badanie Opis Powiązane wymogi
3 Badania przechowywania
3.1 Suche gorąco Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C
± 2 °C/przy wilgotności względnej 55 % ± 3 %.
Środowisko testowe: 72 h w temperaturze + 70 °C ± 2 °C.
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy
wilgotności względnej 55 % ± 3 %.
176, 178
IEC 60068-2-2-Bb
2.2 Wilgotne gorąco Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C
± 2 °C/przy wilgotności względnej 55 % ± 3 %.
Środowisko testowe: 144 h w temperaturze + 55 °C
± 2 °C/przy wilgotności względnej 93 % ± 3 %.
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy
wilgotności względnej 55 % ± 3 %.
176, 178
IEC 60068-2-78-Cab
4 Badania papieru w użyciu
4.1 Podstawowa odpor­
ność na działanie
wilgoci (papier
niezadrukowany)
Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C
± 2 °C/przy wilgotności względnej 55 % ± 3 %.
Środowisko testowe: 144 h w temperaturze + 55 °C
± 2 °C/przy wilgotności względnej 93 % ± 3 %.
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy
wilgotności względnej 55 % ± 3 %.
176, 178
IEC 60068-2-78-Cab
4.2 Drukowność Kondycjonowanie wstępne: 24 h w temperaturze + 40 °C
± 2 °C/przy wilgotności względnej 93 % ± 3 %.
Środowisko testowe: wydruk sporządzony w temperaturze
+ 23 °C ± 2 °C
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy
wilgotności względnej 55 % ± 3 %.
176, 178
4.3 Odporność na dzia­
łanie wysokich
temperatur
Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C
± 2 °C/przy wilgotności względnej 55 % ± 3 %.
Środowisko testowe: 2 h w temperaturze + 70 °C ± 2 °C,
suche gorąco
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy
wilgotności względnej 55 % ± 3 %.
176, 178
IEC 60068-2-2-Bb
4.4 Odporność na dzia­
łanie niskich tempe­
ratur
Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C
± 2 °C/przy wilgotności względnej 55 % ± 3 %.
Środowisko testowe: 24 h w temperaturze – 20 °C ± 3 °C,
suche zimno
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy
wilgotności względnej 55 % ± 3 %.
176, 178
ISO 60068-2-1-Ab
4.5 Światłoodporność Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C
± 2 °C/przy wilgotności względnej 55 % ± 3 %.
Środowisko testowe: 100 h pod oświetleniem o natężeniu
5 000 luksów w temperaturze + 23 °C ± 2 °C przy wilgot­
ności względnej 55 % ± 3 %
Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy
wilgotności względnej 55 % ± 3 %.
176, 178
Kryteria czytelności w odniesieniu do badań 3.x i 4.x:
Czytelność wydruku jest zapewniona, jeżeli gęstości optyczne są zgodne
z następującymi ograniczeniami:
Wielkość drukowanych znaków: min. 1,0
Tło (papier niezadrukowany): maks. 0,2
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 418
Gęstości optyczne otrzymanych wydruków mierzy się według DIN EN
ISO 534.
Wydruki muszą przedstawiać niezmienione wymiary i być wyraźnie
czytelne.
8. BADANIA INTEROPERACYJNOŚCI
▼M1
Nr Badanie Opis
8.1 Badania interoperacyjności między przyrządami rejestrują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 rejestru­
jącym. Scenariusz dostosowany jest do typu badanej karty i obej­
muje zapis na karcie tak wielu EF, jak to możliwe.
Sprawdzenie poprzez pobieranie danych z przyrządu rejestrują­
cego, czy wszystkie odpowiednie zapisy zostały wykonane prawid­
łowo.
Sprawdzenie poprzez pobieranie danych z karty, czy wszystkie
odpowiednie zapisy zostały wykonane prawidłowo.
Sprawdzenie poprzez dzienny wydruk z karty, czy wszystkie odpo­
wiednie zapisy mogą być odczytane prawidłowo.
8.2 Badania interoperacyjności między przyrządami rejestrują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.
Scenariusz obejmuje normalną czynność i wygenerowanie jak
największej liczby zdarzeń lub usterek.
Sprawdzenie poprzez pobieranie danych z przyrządu rejestrują­
cego, czy wszystkie odpowiednie zapisy zostały wykonane prawid­
łowo.
Sprawdzenie poprzez pobieranie danych z karty, czy wszystkie
odpowiednie zapisy zostały wykonane prawidłowo.
Sprawdzenie poprzez dzienny wydruk, czy wszystkie odpowiednie
zapisy mogą być odczytane prawidłowo.
8.3 Badania interoperacyjności między przyrządami rejestrują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 prze­
biega normalnie.
2 Badania czynności Wykonanie scenariusza typowej czynności na zewnętrznym urzą­
dzeniu GNSS. Scenariusz obejmuje normalną czynność i wygene­
rowanie jak największej liczby zdarzeń lub usterek.
Sprawdzenie poprzez pobieranie danych z przyrządu rejestrują­
cego, czy wszystkie odpowiednie zapisy zostały wykonane prawid­
łowo.
Sprawdzenie poprzez pobieranie danych z karty, czy wszystkie
odpowiednie zapisy zostały wykonane prawidłowo.
Sprawdzenie poprzez dzienny wydruk, czy wszystkie odpowiednie
zapisy mogą być odczytane prawidłowo.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 419
9. BADANIA OSNMA
9.1. Wprowadzenie
W niniejszym rozdziale opisano badania mające na celu wykazanie
prawidłowego wdrożenia OSNMA w odbiorniku GNSS. Ponieważ uwie­
rzytelnianie sygnału satelitarnego jest wykonywane wyłącznie przez
odbiornik GNSS niezależnie od jakiegokolwiek innego elementu składo­
wego tachografu, badania określone w niniejszym rozdziale mogą być
przeprowadzane na odbiorniku GNSS jako samodzielnym elemencie.
W takim przypadku producent tachografów przedstawia organom udziela­
jącym homologacji typu sprawozdanie zawierające szczegółowe infor­
macje na temat rozwoju i wyników badań przeprowadzanych na odpowie­
dzialność producenta odbiorników GNSS.
9.2 Warunki mające zastosowanie
— Kryteria zaliczenia/niezaliczenia określone w badaniach OSNMA
uznaje się za ważne tylko w odniesieniu do określonych warunków
badania.
— Kryteria te mogą zostać zmienione w momencie składania deklaracji
usług Galileo OSNMA i z uwzględnieniem związanych z nimi zobo­
wiązań w zakresie wydajności usług.
9.3. Definicje i skróty
9.3.1. Definicje
Zimny/ciepły/gorący
rozruch GNSS::
dotyczy warunku startowego odbiornika
GNSS w oparciu o dostępność czasu (T),
bieżący almanach (A) i efemerydy (E) oraz
pozycję (P):
— zimny rozruch GNSS: brak
— ciepły rozruch GNSS: T, A, P
— gorący rozruch GNSS: T, A, E, P
Zimny/ciepły/gorący
rozruch OSNMA:
dotyczy warunku startowego funkcji OSNMA
w oparciu o dostępność klucza publicznego (P)
oraz informacji DSM-KROOT (K) (jak okre­
ślono w wytycznych dla odbiorników w zakresie
OSNMA, o których mowa w dodatku 12):
— zimny rozruch OSNMA: brak
— ciepły rozruch OSNMA: P
— gorący rozruch OSNMA: P, K
9.3.2. Akronimy
ADKD Authentication Data & Key Delay [dane uwierzytelniania
i opóźnienie klucza]
DSM-KROOT Digital Signature Message KROOT [KROOT komunikatu
podpisu cyfrowego]
GNSS Global Navigation Satellite System [globalny system
nawigacji satelitarnej]
KROOT Root Key of the TESLA key chain [klucz główny
łańcucha kluczy TESLA]
MAC Message Authentication Code [kod uwierzytelniania
komunikatów]
NMACK Number of MAC & key blocks (per 30 seconds) [liczba
MAC i bloków kluczy (na każde 30 sekund)]
OSNMA Galileo Open Service Navigation Message Authentication
[uwierzytelnianie komunikatów nawigacyjnych usługi
otwartej Galileo]
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 420
SLMAC Slow MAC (powolny MAC)
TESLA Timed Efficient Stream Loss-tolerant Authentication
[efektywne czasowo uwierzytelnianie odporne na utratę
strumienia] (protokół używany w OSNMA)
9.4. Sprzęt do generowania sygnałów GNSS
Generowanie sygnałów GNSS może odbywać się za pomocą wielokon­
stelacyjnego symulatora GNSS obsługującego przesyłanie komunikatów
OSNMA. Ewentualnie można zastosować odtwarzacz sygnału częstotli­
wości radiowej umożliwiający odtwarzanie próbek sygnału GNSS
z plików. Typowa głębokość bitu i częstotliwość pobierania próbek
wynoszą odpowiednio 4 bity I/Q i 10 MHz.
Zakłada się, że odbiornik GNSS posiada interfejsy umożliwiające oczysz­
czenie pamięci odbiornika (aby niezależnie usunąć klucz publiczny,
KROOT, informacje zegarowe, informacje o pozycji, efemerydy i alma­
nach), ustawienie realizacji czasu lokalnego odbiornika na potrzeby wery­
fikacji czasu OSNMA oraz załadowanie informacji kryptograficznych.
Polecenia te mogą ograniczać się do celów testowych i w związku
z tym mogą nie być dostępne na potrzeby nominalnego działania
odbiornika.
9.5 Warunki badania
9.5.1. Warunki GNSS
Symulowane lub odtwarzane sygnały GNSS będą miały następującą
charakterystykę:
— statyczny scenariusz odbiornika użytkownika;
— co najmniej konstelacje GPS i Galileo;
— częstotliwość E1/L1;
— co najmniej 4 satelity Galileo o kącie elewacji większym niż 5°;
— czas trwania wymagany dla każdego badania;
— stałe efemerydy nawigacyjne z satelitów podczas badania.
9.5.2. Warunki OSNMA
Komunikat OSNMA przekazywany za pośrednictwem sygnału RF będzie
miał następującą charakterystykę:
— komunikat HKROOT ze statusem OSNMA ustawionym na tryb
eksploatacyjny lub testowy oraz ustalony DSM-KROOT składający
się z 8 bloków dla obowiązującego łańcucha;
— co najmniej 4 satelity Galileo transmitujące OSNMA;
— komunikat MACK z jednym blokiem MACK (tj. NMACK=1) oraz co
najmniej jeden ADKD=0 oraz jeden ADKD=12 na satelitę i blok
MACK;
— wielkość znacznika wynosząca 40 bitów;
— minimalna równoważna długości znacznika zgodnie z wymogami
określonymi w wytycznych dla odbiorników w zakresie OSNMA
(obecnie 80 bitów).
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 421
O ile nie zaznaczono inaczej, realizacja czasu odbiornika wewnętrznego
musi być znana z wystarczającą dokładnością i odpowiednio zsynchroni­
zowana z czasem symulowanym. Gwarantuje to spełnienie wymogu
synchronizacji czasu początkowego OSNMA dla każdego warunku
badania, tj. synchronizacji nominalnej dla wszystkich badań z wyjątkiem
SLMAC. Więcej informacji na temat inicjalizacji czasu można znaleźć
w wytycznych dla odbiorników w zakresie OSNMA.
Należy zauważyć, że wskazane kryteria zaliczenia/niezaliczenia są zacho­
wawcze i nie odzwierciedlają oczekiwanych wyników OSNMA Galileo.
9.6. Specyfikacja dotycząca badań
Nr Badanie Opis Odpowiednie wymogi
1. Badanie administracyjne
1.1 Dokumentacja Prawidłowość dokumentacji
2 Badania ogólne
2.1 Gorący rozruch
OSNMA
Cel: sprawdzenie, czy odbiornik GNSS oblicza pozycję
przy użyciu OSNMA po gorącym rozruchu.
Procedura:
Odbiornik GNSS uruchamia się w warunkach gorącego
rozruchu GNSS i OSNMA oraz pozyskuje sygnały
widocznych satelitów Galileo.
Odbiornik uwierzytelnia dane nawigacyjne Galileo za
pomocą OSNMA (ADKD = 0) i podaje pozycję z uwie­
rzytelnionymi danymi.
Kryteria zaliczenia/niezaliczenia: odbiornik oblicza
ustaloną uwierzytelnioną pozycję w ciągu 160 sekund.
Dodatek 12,
GNS_3b
2.2 Ciepły rozruch
OSNMA
Cel: sprawdzenie, czy odbiornik GNSS oblicza pozycję
przy użyciu OSNMA po ciepłym rozruchu.
Procedura:
Przed rozpoczęciem badania informacje dotyczące
efemerydów i KROOT usuwa się z pamięci odbiornika
GNSS w celu wymuszenia ciepłego rozruchu GNSS
i OSNMA.
Odbiornik GNSS uruchamia się i pozyskuje sygnały
widocznych satelitów Galileo.
DSM-KROOT jest odbierany i weryfikowany.
Odbiornik uwierzytelnia dane nawigacyjne Galileo za
pomocą OSNMA (ADKD=0) i podaje pozycję z uwie­
rzytelnionymi danymi.
Kryteria zaliczenia/niezaliczenia: odbiornik oblicza
ustaloną uwierzytelnioną ważną pozycję w ciągu 430
sekund.
Dodatek 12,
GNS_3b
2.3 Ciepły rozruch
OSNMA z SLMAC
Cel: sprawdzenie, czy odbiornik GNSS oblicza pozycję
za pomocą OSNMA po ciepłym rozruchu z inicjacją
czasu wymagającą trybu SLMAC, jak określono
w wytycznych dla odbiorników w zakresie OSNMA.
Procedura:
Realizacja czasu odbiornika wewnętrznego musi być
skonfigurowana w taki sposób, aby początkowa
niepewność czasu wynosiła od 2 do 2,5 minuty, tak
aby zgodnie z wytycznymi dla odbiorników w zakresie
OSNMA aktywować tryb Slow MAC.
Dodatek 12,
GNS_3b
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 422
Nr Badanie Opis Odpowiednie wymogi
Przed rozpoczęciem badań informacje dotyczące efeme­
rydów i KROOT usuwa się z pamięci odbiornika
GNSS w celu wymuszenia ciepłego rozruchu GNSS
i OSNMA.
Odbiornik GNSS uruchamia się i pozyskuje sygnały
widocznych satelitów Galileo.
DSM-KROOT jest odbierany i weryfikowany.
Odbiornik uwierzytelnia dane nawigacyjne Galileo
wyłącznie za pomocą OSNMA Slow MAC
(ADKD=12) i podaje pozycję z uwierzytelnionymi
danymi.
Kryteria zaliczenia/niezaliczenia: odbiornik oblicza
ustaloną uwierzytelnioną ważną pozycję w ciągu 730
sekund.
2.4 Gorący rozruch
OSNMA z odtwa­
rzanym sygnałem
Cel: sprawdzenie, czy odbiornik GNSS wykrywa
odtwarzany sygnał.
Procedura:
Odbiornik GNSS uruchamia się w warunkach gorącego
rozruchu GNSS i OSNMA oraz pozyskuje sygnały
widocznych satelitów Galileo.
Odbiornik uwierzytelnia dane nawigacyjne Galileo za
pomocą OSNMA (ADKD=0) i podaje pozycję z uwie­
rzytelnionymi danymi.
Gdy odbiornik dostarczy rozwiązanie PVT z uwierzytel­
nionymi danymi, zostaje wyłączony.
Symulowany jest odtwarzany sygnał z opóźnieniem 40
sekund w stosunku do poprzedniego, a odbiornik
zostaje włączony.
Odbiornik wykrywa, że czas systemu Galileo z czasu
sygnału w przestrzeni oraz realizacja czasu lokalnego
czasu nie spełniają wymogu synchronizacji i zaprzestaje
przetwarzania danych OSNMA, jak określono
w wytycznych dla odbiorników w zakresie OSNMA.
Kryteria zaliczenia/niezaliczenia: odbiornik wykrywa
odtwarzanie i nie oblicza uwierzytelnionej ważnej
pozycji od początku odtwarzania do końca badania.
Dodatek 12,
GNS_3b
2.5 Gorący rozruch
OSNMA z fałszywymi
danymi
Cel: sprawdzenie, czy OSNMA wykrywa fałszywe
dane.
Procedura:
Odbiornik GNSS uruchamia się w warunkach gorącego
rozruchu GNSS i OSNMA.
Odbiornik GNSS jest w stanie pozyskać sygnał wszyst­
kich widocznych satelitów Galileo i zweryfikować
autentyczność ich komunikatów nawigacyjnych za
pomocą OSNMA.
Co najmniej jeden bit danych efemerycznych dostarczo­
nych przez każdego satelitę Galileo nie odpowiada pier­
wotnym i uwierzytelnionym danym, ale komunikat
Galileo I/NAV musi być spójny, z uwzględnieniem
CRC.
Kryteria zaliczenia/niezaliczenia: odbiornik wykrywa
fałszywe dane w ciągu 160 sekund i nie oblicza uwie­
rzytelnionej ważnej pozycji do zakończenia badania.
Dodatek 12,
GNS_3b
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 423
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 interpre­
tacji (JIWG), która wspiera wzajemne uznawanie certyfikatów pod
egidą SOGIS-MRA (Umowa o wzajemnym uznawaniu świadectw
z oceny bezpieczeństwa informatycznego), oraz rejestrowane:
— profil zabezpieczenia dla przyrządu rejestrującego;
— profil zabezpieczenia dla karty do tachografu;
— profil zabezpieczenia dla czujnika ruchu;
— profil zabezpieczenia dla urządzenia zewnętrznego GNSS.
Profil zabezpieczenia dla przyrządu rejestrującego uwzględnia 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 — 21.08.2023 — 003.002 — 424
Dodatek 11
WSPÓLNE MECHANIZMY ZABEZPIECZENIA
SPIS TREŚCI
INFORMACJE OGÓLNE
CZĘŚĆ A SYSTEM TACHOGRAFU PIERWSZEJ GENERACJI
1. WPROWADZENIE
1.1. Odniesienia
1.2. Oznaczenia i skróty
2. SYSTEMY I ALGORYTMY KRYPTOGRAFICZNE
2.1. Systemy kryptograficzne
2.2. Algorytmy kryptograficzne
2.2.1 Algorytm RSA
2.2.2 Algorytm skrótu
2.2.3 Algorytm szyfrowania danych
3. KLUCZE I CERTYFIKATY
3.1. Generowanie i dystrybucja kluczy
3.1.1 Generowanie i dystrybucja kluczy RSA
3.1.2 Klucze testowe RSA
3.1.3 Klucze czujnika ruchu
3.1.4 Generowanie i dystrybucja kluczy sesji T-DES
3.2. Klucze
3.3. Certyfikaty
3.3.1 Treść certyfikatów
3.3.2 Wydane certyfikaty
3.3.3 Weryfikacja i rozpakowanie certyfikatu
4. MECHANIZM WZAJEMNEGO UWIERZYTELNIENIA
5. POUFNOŚĆ, INTEGRALNOŚĆ I MECHANIZMY UWIERZY­
TELNIANIA PRZESYŁANIA DANYCH MIĘDZY VU
A KARTAMI
5.1. Bezpieczna wymiana komunikatów
5.2. Obsługa błędów w bezpiecznej wymianie komunikatów
5.3. Algorytm obliczania kryptograficznych sum kontrolnych
5.4. Algorytm obliczania kryptogramów dla poufnych obiektów danych
6. MECHANIZMY CYFROWEGO PODPISU DLA POBIERANIA
DANYCH
6.1. Generowanie podpisu
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 425
6.2. Weryfikacja podpisu
CZĘŚĆ B SYSTEM TACHOGRAFU DRUGIEJ GENERACJI
7. WPROWADZENIE
7.1. Odniesienia
7.2. Oznaczenia i skróty
7.3. Definicje
8. SYSTEMY I ALGORYTMY KRYPTOGRAFICZNE
8.1. Systemy kryptograficzne
8.2. Algorytmy kryptograficzne
8.2.1 Algorytmy symetryczne
8.2.2 Algorytmy asymetryczne i standardowe parametry domeny
8.2.3 Algorytmy skrótu
8.2.4 Mechanizm szyfrowania
9. KLUCZE I CERTYFIKATY
9.1. Pary kluczy asymetrycznych i certyfikaty kluczy 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 — 21.08.2023 — 003.002 — 426
10.2.2 Weryfikacja łańcucha certyfikatów VU przez kartę
10.3. Uwierzytelnienie VU
10.4. Uwierzytelnianie chipu i uzgadnianie klucza sesji
10.5. Bezpieczna wymiana komunikatów
10.5.1 Uwagi ogólne
10.5.2 Struktura bezpiecznego komunikatu
10.5.3 Przerwanie sesji bezpiecznej wymiany komunikatów
11. POWIĄZANIE, WZAJEMNE UWIERZYTELNIANIE
I BEZPIECZNA WYMIANA KOMUNIKATÓW MIĘDZY VU
A URZĄDZENIEM ZEWNĘTRZNYM GNSS
11.1. Uwagi ogólne
11.2. Ustanowienie powiązania między VU a urządzeniem zewnę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 — 21.08.2023 — 003.002 — 427
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 krypto­
graficzny. Projekt 1999 r.
TDES-OP ANSI X9.52, Tryby pracy algorytmu trzyetapowego
szyfrowania danych. 1998 r.
ISO/IEC 7816-4 Technologia informacyjna – Karty identyfikacyjne –
Elektroniczne karty stykowe – Część 4: Międzybran­
żowe polecenia wymiany informacji. Wydanie
pierwsze: 1995 r. + zmiana 1: 1997 r.
ISO/IEC 7816-6 Technologia informacyjna – Karty identyfikacyjne –
Elektroniczne karty stykowe – Część 6: Międzybran­
żowe elementy danych. Wydanie pierwsze: 1996 r. +
zmiana 1: 1998 r.
ISO/IEC 7816-8 Technologia informacyjna – Karty identyfikacyjne –
Elektroniczne karty stykowe – Część 8: Międzybran­
żowe polecenia związane z bezpieczeństwem.
Wydanie pierwsze: 1999 r.
ISO/IEC 9796-2 Technologia informacyjna – Techniki zabezpieczeń –
Schematy podpisu cyfrowego z odtwarzaniem wiado­
mości – Część 2: Mechanizmy oparte na faktoryzacji
liczb całkowitych. Wydanie pierwsze: 1997 r.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 428
ISO/IEC 9798-3 Technologia informacyjna – Techniki zabezpieczeń –
Mechanizmy uwierzytelnienia jednostki – Część 3:
Uwierzytelnienie jednostki przy użyciu algorytmu
klucza publicznego. Wydanie drugie: 1998 r.
ISO 16844-3 Pojazdy drogowe – Systemy tachograficzne – Część 3:
Interfejs czujnika ruchu.
1.2. Oznaczenia i skróty
W niniejszym dodatku używa się następujących oznaczeń i skrótów:
(K a , K b , K c ) wiązka kluczy używanych w algorytmie trzyetapo­
wego szyfrowania danych,
CA organ certyfikacji
CAR odniesienie do organu certyfikacji
CC kryptograficzna suma kontrolna
CG kryptogram
CH nagłówek polecenia
CHA upoważnienie posiadacza certyfikatu
CHR odniesienie do posiadacza certyfikatu
D() deszyfracja DES
DE element danych
DO obiekt danych
d klucz prywatny RSA, wykładnik prywatny
e klucz publiczny RSA, wykładnik publiczny
E() szyfrowanie DES
EQT urządzenie
Hash() skrót, wartość wyjściowa funkcji skrótu
Hash funkcja skrótu
KID identyfikator klucza
Km klucz TDES, klucz główny wg normy ISO 16844-3
Km VU klucz TDES umieszczony w przyrządzie rejestrującym
Km WC klucz TDES umieszczony w kartach warsztatowych
m reprezentacja komunikatu, liczba całkowita z prze­
działu od 0 do n-1
n klucze RSA, moduły
PB bajty wypełnienia
PI bajt wskaźnik wypełnienia (do zastosowania w krypto­
gramie dla poufności DO)
PV wartość odkryta
s reprezentacja podpisu, liczba całkowita z przedziału
od 0 do n-1
SSC licznik sekwencji wysyłania
SM bezpieczna wymiana komunikatów
TCBC tryb wiązania bloków zaszyfrowanych TDEA
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 429
TDEA algorytm trzyetapowego szyfrowania danych
TLV obiekt TLV
VU przyrząd rejestrujący
X.C certyfikat użytkownika X wydany przez organ certy­
fikacji
X.CA organ certyfikacji użytkownika X
X.CA.PK o X.C Operacja rozpakowania certyfikatu w celu wyodręb­
nienia klucza publicznego. Jest to operator wrost­
kowy, którego argumentem lewostronnym jest klucz
publiczny organu certyfikacji, a argumentem prawo­
stronnym jest certyfikat wydany przez ten organ certy­
fikacji. Wynikiem jest klucz publiczny użytkownika
X, którego certyfikat jest argumentem prawostronnym.
X.PK klucz publiczny użytkownika X
X.PK[I] szyfrowanie RSA pewnych informacji kluczem
publicznym I użytkownika X
X.SK klucz prywatny RSA użytkownika X
X.SK[I] szyfrowanie RSA pewnych informacji kluczem
prywatnym I użytkownika X
„xx” wartość heksadecymalna
|| operator konkatenacji
2. SYSTEMY I ALGORYTMY KRYPTOGRAFICZNE
2.1. Systemy kryptograficzne
CSM_001 Przyrządy rejestrujące i karty do tachografu używają 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śnikó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 — 21.08.2023 — 003.002 — 430
X.SK[m] = s = m d mod n
X.PK[s] = m = s e mod n
Bardziej wyczerpujący opis funkcji RSA można znaleźć
w odniesieniu [PKCS1]. Wykładnik publiczny, e, dla obliczeń
RSA jest liczbą całkowitą pomiędzy 3 i n-1 spełniającą gcd(e,
lcm(p-1, q-1))=1.
2.2.2 Algorytm skrótu
CSM_004 Mechanizmy podpisu cyfrowego używają algorytmu skrótu
SHA-1 zdefiniowanego w odniesieniu [SHA-1].
2.2.3 Algorytm szyfrowania danych
CSM_005 Algorytmy oparte na algorytmie DES są używane w trybie
wiązania bloków zaszyfrowanych.
3. KLUCZE I CERTYFIKATY
3.1. Generowanie i dystrybucja kluczy
3.1.1 Generowanie i dystrybucja kluczy RSA
CSM_006 Klucze RSA są generowane na trzech hierarchicznych 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 realizującym
te zadania jest organ certyfikacji państwa członkowskiego.
Państwo członkowskie może okresowo zmieniać swoją parę
kluczy.
CSM_009 Na poziomie urządzenia generuje się jedną parę kluczy
(EQT.SK i EQT.PK), którą umieszcza się w każdym urzą­
dzeniu. Klucze publiczne urządzenia certyfikuje organ certy­
fikacji państwa członkowskiego. Zadania te mogą realizować
producenci urządzeń, jednostki personalizujące urządzenia lub
organy państwa członkowskiego. Wspomnianej pary kluczy
używa się do uwierzytelniania, składania podpisu cyfrowego
oraz świadczenia usług w zakresie szyfrowania.
CSM_010 W czasie generowania, ewentualnego transportu i przechowy­
wania należy zachować poufność kluczy prywatnych.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 431
Na poniższym rysunku zobrazowano przepływ danych w tym
procesie:
3.1.2 Klucze testowe RSA
CSM_011 Do celów testowania urządzeń (włącznie z badaniami 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 testowych
państwa członkowskiego.
3.1.3 Klucze czujnika ruchu
W czasie generowania, ewentualnego transportu i przechowywania
w należyty sposób zachowuje się poufność trzech kluczy Triple 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 — 21.08.2023 — 003.002 — 432
CSM_037 Organy certyfikacji państw członkowskich:
— używają Km do szyfrowania danych czujnika ruchu
wymaganych przez producentów czujników ruchu (dane,
które mają być zaszyfrowane kluczem Km, są określone
w normie ISO 16844-3),
— przesyłają klucz Km VU producentom przyrządów rejestru­
jących z zachowaniem należytych procedur bezpieczeń­
stwa w celu umieszczenia w przyrządach rejestrujących,
— zapewniają umieszczenie klucza Km WC we wszystkich kartach
warsztatowych
w pliku elementarnym
w czasie personalizacji kart.
3.1.4 Generowanie i dystrybucja kluczy sesji T-DES
CSM_012 W ramach procesu wzajemnego uwierzytelnienia przyrządy
rejestrujące i karty do tachografu generują i wymieniają
niezbędne dane w celu uzyskania wspólnego klucza sesji
Triple DES. Poufność tej wymiany informacji jest chroniona
mechanizmem kryptograficznym RSA.
CSM_013 Klucz ten stosuje się we wszystkich późniejszych czynno­
ściach kryptograficznych, używając bezpiecznej wymiany
komunikatów. Ważność tego klucza wygasa z końcem sesji
(wyjęcie karty lub wyzerowanie karty) lub po 240 użyciach
(jedno użycie klucza = jedno polecenie używające
bezpiecznej wymiany komunikatów wysłane do karty i zwią­
zana z nim odpowiedź).
3.2. Klucze
CSM_014 Długości kluczy RSA (niezależnie od poziomu) są następu­
jące: moduł n 1 024 bity, wykładnik publiczny e maksy­
malnie 64 bity, wykładnik prywatny d 1 024 bity.
CSM_015 Klucze Triple DES mają postać (K a , K b , K a ), gdzie K a i K b są
niezależnymi 64-bitowymi kluczami. Nie dopuszcza się
możliwości ustawiania jakichkolwiek bitów wykrywania
błędu parzystości.
3.3. Certyfikaty
CSM_016 Certyfikaty klucza publicznego RSA są certyfikatami „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 — 21.08.2023 — 003.002 — 433
Dane Format Bajty Opis
EOV TimeReal 4 Koniec terminu ważności
certyfikatu. Opcjonalny,
gdy nieużywany, wypeł­
niony „FF”.
CHR OCTET
STRING
8 odniesienie do posiadacza
certyfikatu
n OCTET
STRING
128 Klucz publiczny (moduł)
e OCTET
STRING
8 Klucz publiczny
(wykładnik publiczny)
164
Uwagi:
1. „Identyfikator profilu certyfikatu” (CPI) wyznacza dokładną strukturę
certyfikatu uwierzytelniania. Można go używać jako wewnętrznego
identyfikatora urządzenia w odpowiednim wykazie nagłówków,
który opisuje konkatenację elementów danych w certyfikacie.
Wykaz nagłówków związanych z treścią certyfikatu jest następujący:
„4D” „16” „5F
29”
„01” „42” „08” „5F
4B”
„07” „5F
24”
„04” „5F
20”
„08” „7F
49”
„05” „81” „81
80”
„82” „08”
Z
na
cz
ni
k
ro
zs
ze
rz
on
eg
o
w
yk
az
u
na
gł
ów
kó
w

D
łu
go
ść
w
yk
az
u
na
gł
ów
kó
w

Z
na
cz
ni
k
C
P
I
D
łu
go
ść
C
P
I
Z
na
cz
ni
k
C
A
R

D
łu
go
ść
C
A
R

Z
na
cz
ni
k
C
H
A

D
łu
go
ść
C
H
A

Z
na
cz
ni
k
E
O
V

D
łu
go
ść
E
O
V

Z
na
cz
ni
k
C
H
R

D
łu
go
ść
C
H
R

Z
na
cz
ni
k
kl
uc
za
p
ub
li
cz
ne
go
(
zb
ud
ow
an
y)

D
łu
go
ść
n
as
tę
pn
yc
h
D
O

Z
na
cz
ni
k
m
od
uł
u
D
łu
go
ść
m
od
uł
u
Z
na
cz
ni
k
w
yk
ła
dn
ik
a
pu
bl
ic
zn
eg
o
D
łu
go
ść
w
yk
ła
dn
ik
a
pu
bl
ic
zn
eg
o
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 — 21.08.2023 — 003.002 — 434
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
ocertyfikat
Data Typ Producent
Długość 4 bajty 2 bajty 1 bajt 1 bajt
Wartość liczba
całkowita
kodowanie BCD
mm rr
„FF” kod producenta
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 435
5.2. Organ certyfikacji:
Dane Identyfikacja
organu
Numer
seryjny klucza
Dodatkowe
informacje
Identyfikator
Długość 4 bajty 1 bajt 2 bajty 1 bajt
Wartość 1-bajtowy kod
numeryczny
państwa
3-bajtowy kod
alfanumeryczny
państwa
liczba całko­
wita
dodatkowe
kodowanie
(specyficzne
dla CA)
„FF FF”, gdy
nie jest
używany
„01”
Numer seryjny klucza służy do rozróżniania różnych kluczy
państwa członkowskiego w przypadku zmiany klucza.
6. Weryfikatory certyfikatów wiedzą niejawnie o tym, iż certyfikowany
klucz publiczny jest kluczem RSA właściwym do uwierzytelnienia,
weryfikacji podpisu cyfrowego i szyfrowania dla poufnych usług
(certyfikat nie zawiera identyfikatora obiektu, który by to 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”
Z
na
cz
ni
k
ce
rt
yf
ik
at
u
C
V
(
zb
ud
ow
an
y)

D
łu
go
ść
n
as
tę
pn
yc
h
D
O

Z
na
cz
ni
k
po
dp
is
u
D
łu
go
ść
p
od
pi
su

Z
na
cz
ni
k
re
sz
ty

D
łu
go
ść
r
es
zt
y
Z
na
cz
ni
k
C
A
R

D
łu
go
ść
C
A
R

▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 436
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
certyfikatu.
CSM_019 Procedura ta składa się z następujących etapów:
weryfikacja podpisu i odzyskanie treści:
— z X.C odzyskaj Sign, C n „i CAR”: X.C = Sign || C n „ || CAR”
128 bajtów 58 bajtów 8 bajtów
— z CAR' wybierz odpowiednio klucz publiczny organu
certyfikacji (jeżeli nie uzyskano go wcześniej innymi
środkami)
— odtwórz Sign z klucza publicznego CA: Sr'= X.CA.PK
[Sign]
— sprawdź, czy Sr' zaczyna się od „6A” i kończy na „BC”
— oblicz C r ' i H' z: Sr' = „6A” || C r ' || H' || „BC”
106 bajtów 20 bajtów
— odzyskaj treść certyfikatu C' = C r „|| C n ”
— sprawdź, czy Hash (C') = H'
Jeżeli rezultat kontroli będzie prawidłowy, certyfikat jest
prawdziwy, a jego treść to C'.
Sprawdzenie ważności z C':
— w stosownych przypadkach sprawdź koniec daty
ważności,
odzyskaj i zachowaj klucz publiczny, identyfikator klucza,
upoważnienie posiadacza certyfikatu i koniec ważności certy­
fikatu z C':
— X.PK = n || e
— X.KID = CHR
— X.CHA = CHA
— X.EOV = EOV
4. MECHANIZM WZAJEMNEGO UWIERZYTELNIENIA
Wzajemne uwierzytelnienie między kartami a VU odbywa się według
opisanej poniżej zasady.
Każda strona wykazuje drugiej, że posiada ważną parę kluczy, z której
klucz publiczny jest certyfikowany przez organ certyfikacji państwa
członkowskiego, który uzyskał certyfikat wydany przez 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 — 21.08.2023 — 003.002 — 437
CSM_020 W procesie tym stosuje się następujący protokół (strzałki
oznaczają polecenia i wymianę danych (zob. dodatek 2)):
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 438
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 439
5. POUFNOŚĆ, INTEGRALNOŚĆ I MECHANIZMY UWIERZYTEL­
NIANIA PRZESYŁANIA DANYCH MIĘDZY VU A KARTAMI
5.1. Bezpieczna wymiana komunikatów
CSM_021 Bezpieczna wymiana komunikatów chroni integralność prze­
syłania danych między VU a kartami zgodnie z odniesieniami
[ISO/IEC 7816-4] i [ISO/IEC 7816-8].
CSM_022 W przypadku konieczności zapewnienia ochrony przesyła­
nych danych do obiektów danych wysyłanych w poleceniu
lub odpowiedzi dołącza się obiekt danych z kryptograficzną
sumą kontrolną. Kryptograficzną sumę kontrolną weryfikuje
odbiorca.
CSM_023 Kryptograficzna suma kontrolna danych wysyłanych w pole­
ceniu integruje nagłówek polecenia i wszystkie wysyłane
obiekty danych (=>CLA = „0C”, a wszystkie obiekty danych
są ograniczone znacznikami, w których b1=1).
CSM_024 Bajty stanu odpowiedzi-informacji są chronione 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ę
kontrolną)
„97” T LE Wartość Le w niezabezpieczonym poleceniu (chro­
niona przez kryptograficzną sumę kontrolną)
„99” T SW Stan-Info (chronione przez kryptograficzną sumę
kontrolną)
„8E” T CC Kryptograficzna suma kontrolna
„87” T PI CG Bajt wskaźnika wypełnienia || Kryptogram (odkryta
wartość niekodowana w BER-TLV)
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 440
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 — 21.08.2023 — 003.002 — 441
Treść odpowiedzi Stopka odpowiedzi
[Nowe pole danych] nowe SW1 SW2
T PI CG L PI
CG
PI CG T CC L CC CC
„87” PI || CG „8E” „04” 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ą jedno­
kierunkowej funkcji skrótu MAC zgodnie z normą ANSI
X9.19 z DES:
— etap początkowy: początkowy blok kontrolny y0 jest
E(Ka, SSC),
— etap sekwencyjny: bloki kontrolne y1,…, yn oblicza się
za pomocą Ka,
— etap końcowy: kryptograficzną sumę kontrolną oblicza się
z ostatniego bloku yn jako: E(Ka, D(Kb, yn)),
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 442
gdzie E() oznacza szyfrowanie z DES, a D() oznacza deszyf­
rowanie z DES.
Cztery najbardziej znaczące bajty kryptograficznej sumy
kontrolnej są przesyłane.
CSM_029 Licznik sekwencji wysyłania (SSC) jest inicjowany 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 — 21.08.2023 — 003.002 — 443
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(Data))]
PS = Wypełnienie ciągiem oktetów o wartości „FF” do
długości 128.
DER(SHA-1(M)) to kodowanie identyfikatora algorytmu dla
funkcji skrótu, a wartość skrótu jest wartością w ASN.1 typu
DigestInfo (wyróżnione reguły kodowania):
„30”||„21”||„30”||„09”||„06”||„05”||„2B”||„0E”||„03”||„02”||„1A”||
„05”||„00”||„04”||„14”||wartość skrótu.
6.2. Weryfikacja podpisu
CSM_035 Weryfikacja podpisu danych dla pobranych danych odbywa
się zgodnie ze schematem podpisu z dodatkiem zdefinio­
wanym w odniesieniu (PKCS1) z funkcją skrótu SHA-1.
Europejski klucz publiczny EUR.PK musi być niezależnie
znany (i zaufany) przez weryfikatora.
Na schemacie poniżej zilustrowano protokół przenoszenia
IDE, z którego może korzystać karta kontrolna przy spraw­
dzaniu integralności danych pobranych i zapisanych na
zewnętrznym nośniku danych (ESM). Karta kontrolna służy
do deszyfrowania podpisów cyfrowych. W tym przypadku ta
funkcja nie musi być zaimplementowana w IDE.
Urządzenie, które pobiera i podpisuje dane przeznaczone do
analizowania, oznaczono EQT.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 444
CZĘŚĆ B
SYSTEM TACHOGRAFU DRUGIEJ GENERACJI
7. WPROWADZENIE
7.1. Odniesienia
W tej części dodatku używa się następujących odniesień:
AES Narodowy Instytut Standaryzacji i Technologii (NIST),
FIPS Publikacja 197: Symetryczny szyfr blokowy (AES),
26 listopada 2001 r.
DSS Narodowy Instytut Standaryzacji i Technologii (NIST),
FIPS Publikacja 186-4: Standard podpisu cyfrowego
(DSS), lipiec 2013 r.
ISO 7816-4 ISO/IEC 7816-4, Karty identyfikacyjne – Karty 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 — 21.08.2023 — 003.002 — 445
ISO 8825-1 ISO/IEC 8825-1 Technologia informacyjna – Reguły kodo­
wania ASN.1: Specyfikacja podstawowych reguł kodowania
(BER), kanonicznych reguł kodowania (CER) i wyróżnio­
nych reguł kodowania (DER). Wydanie czwarte, 2008-12-15.
ISO 9797-1 ISO/IEC 9797-1, Technologia informacyjna – Techniki
zabezpieczeń – Kody uwierzytelniania komunikatów
(MAC) – Część 1: Mechanizmy stosujące szyfr blokowy.
Wydanie drugie, 2011-03-01
ISO 10116 ISO/IEC 10116, Technologia informacyjna – Techniki
zabezpieczeń – Tryby pracy algorytmu szyfrowania
bloków n-bitowych. Wydanie trzecie, 2006-02-01
ISO 16844-3 ISO 16844-3, Pojazdy drogowe – Systemy 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 rozwi­
janie 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 — 21.08.2023 — 003.002 — 446
IDE inteligentne urządzenie dedykowane
K M klucz główny czujnika ruchu umożliwiający sparowanie
przyrządu rejestrującego z czujnikiem ruchu
K M-VU klucz umieszczony w przyrządach rejestrujących, umożli­
wiający VU wyprowadzenie klucza głównego czujnika
ruchu, jeżeli karta warsztatowa została włożona do VU
K M-WC klucz umieszczony w kartach warsztatowych, umożliwia­
jący VU wyprowadzenie klucza głównego czujnika ruchu,
jeżeli karta warsztatowa została włożona do VU
MAC kod uwierzytelniania komunikatów
MoS czujnik ruchu
MSB najbardziej znaczący bit
PKI infrastruktura klucza publicznego
RCF urządzenie do łączności na odległość
SSC licznik sekwencji wysyłania
SM bezpieczna wymiana komunikatów
TDES potrójny algorytm DES
TLV obiekt TLV (Tag-Length-Value)
VU przyrząd rejestrujący
X.C certyfikat klucza publicznego użytkownika X
X.CA organ certyfikacji, który wydał certyfikat użytkownika X
X.CAR odniesienie do organu certyfikacji, o którym mowa w certy­
fikacie użytkownika X
X.CHR odniesienie do posiadacza certyfikatu, o którym mowa
w certyfikacie użytkownika X
X.PK klucz publiczny użytkownika X
X.SK klucz prywatny użytkownika X
X.PK eph efemeryczny klucz publiczny użytkownika X
X.SK eph efemeryczny klucz prywatny użytkownika X
„xx” wartość heksadecymalna
|| operator konkatenacji
7.3. Definicje
Definicje terminów stosowanych w niniejszym dodatku włączono do
sekcji I załącznika 1C.
8. SYSTEMY I ALGORYTMY KRYPTOGRAFICZNE
8.1. Systemy kryptograficzne
CSM_38 Przyrządy rejestrujące i karty do tachografu używają
systemu kryptograficznego opartego na krzywej eliptycznej
z kluczem publicznym do zapewniania następujących
usług zabezpieczających:
— wzajemne uwierzytelnienie między przyrządem rejes­
trującym a kartą,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 447
— zgodność kluczy sesji AES między przyrządem rejes­
trującym a kartą,
— zapewnienie autentyczności, integralności i niezaprze­
czalności danych pobranych z przyrządów rejestrują­
cych lub kart do tachografu do zewnętrznych
nośników.
CSM_39 Przyrządy rejestrujące i zewnętrzne urządzenia GNSS
używają systemu kryptograficznego opartego na krzywej
eliptycznej z kluczem publicznym do zapewniania nastę­
pujących usług zabezpieczających:
— powiązanie między przyrządem rejestrującym a urzą­
dzeniem zewnętrznym GNSS,
— wzajemne uwierzytelnienie między przyrządem rejes­
trującym a urządzeniem zewnętrznym GNSS,
— zgodność klucza sesji AES między przyrządem rejes­
trującym a urządzeniem zewnętrznym GNSS.
CSM_40 Przyrządy rejestrujące i karty do tachografu używają
symetrycznego systemu kryptograficznego opartego na
AES do zapewniania następujących usług zabezpieczają­
cych:
— zapewnienie autentyczności i integralności danych
wymienianych między przyrządem rejestrującym
a kartą do tachografu,
— w stosownych przypadkach zapewnienie poufności
danych wymienianych między przyrządem rejestru­
jącym a kartą do tachografu.
CSM_41 Przyrządy rejestrujące i urządzenia zewnętrzne GNSS
używają symetrycznego systemu kryptograficznego opar­
tego na AES do zapewniania następujących usług zabez­
pieczających:
— zapewnienie autentyczności i integralności danych
wymienianych między przyrządem rejestrującym
a urządzeniem zewnętrznym GNSS.
CSM_42 Przyrządy rejestrujące i czujniki ruchu używają 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 — 21.08.2023 — 003.002 — 448
do karty kontrolnej w celu deszyfrowania i potwier­
dzenia autentyczności. Z punktu widzenia bezpieczeń­
stwa urządzenie do łączności na odległość i zdalny
interrogator cechują się pełną przejrzystością.
— Karta warsztatowa zapewnia interfejsowi DSRC takie
same usługi zabezpieczające jak karta kontrolna.
Dzięki temu warsztat może zatwierdzać prawidłowe
funkcjonowanie interfejsu łączności na odległość VU,
z uwzględnieniem bezpieczeństwa. Więcej informacji
można znaleźć w sekcji 9.2.2.
8.2. Algorytmy kryptograficzne
8.2.1 Algorytmy symetryczne
CSM_44 Przyrządy rejestrujące, karty do tachografu, czujniki 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 — 21.08.2023 — 003.002 — 449
Uwaga: identyfikatory obiektu wspomniane w ostatniej
kolumnie tabeli 1 są określone w [RFC 5639] w odnie­
sieniu do krzywych Brainpool oraz w [RFC 5480] w odnie­
sieniu do krzywych NIST.
8.2.3 Algorytmy skrótu
▼M1
CSM_49 Przyrządy rejestrujące, karty do tachografu i urządzenia
zewnętrzne GNSS obsługują algorytmy SHA-256,
SHA-384 i SHA-512 określone w [SHS].
▼B
8.2.4 Mechanizm szyfrowania
CSM_50 W przypadku algorytmu symetrycznego stosuje się łącznie
algorytm asymetryczny lub algorytm skrótu w celu utwo­
rzenia protokołu zabezpieczeń, zaś długości kluczy i wiel­
kości skrótów obu algorytmów są (w przybliżeniu) tak
samo silne. W tabeli 2 przedstawiono dozwolone mecha­
nizmy szyfrowania:
Tabela 2
Dozwolone mechanizmy szyfrowania
Nr identyfikacyjny
mechanizmu szyfro­
wania
Wielkość klucza ECC
(bity)
Długość klucza AES
(bity)
Algorytm skrótu
Długość MAC
(bajty)
CS#1 256 128 SHA-256 8
CS#2 384 192 SHA-384 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 — 21.08.2023 — 003.002 — 450
CSM_52 W ramach całego europejskiego systemu tachografów inte­
ligentnych klucze publiczne i prywatne oraz certyfikaty są
generowane, zarządzane i przekazywane za pomocą stan­
dardowych i bezpiecznych metod.
9.1.2 Poziom europejski
CSM_53 Na poziomie europejskim generuje się jedną unikatową
parę kluczy ECC oznaczoną jako EUR. Składa się ona
z klucza prywatnego (EUR.SK) i klucza publicznego
(EUR.PK). Ta para kluczy tworzy parę kluczy głównych
całego europejskiego systemu tachografów inteligentnych
PKI. Organem realizującym to zadanie jest Główny Euro­
pejski Organ Certyfikacji (ERCA), działający z upoważ­
nienia i na odpowiedzialność Komisji Europejskiej.
CSM_54 ERCA używa europejskiego klucza prywatnego do podpi­
sania głównego certyfikatu (z podpisem własnym) europej­
skiego klucza publicznego i przekazuje ten europejski
certyfikat główny wszystkim państwom członkowskim.
CSM_55 ERCA używa europejskiego klucza prywatnego do podpi­
sywania na żądanie certyfikatów kluczy publicznych
państw członkowskich. ERCA prowadzi rejestry wszyst­
kich podpisanych certyfikatów kluczy publicznych państw
członkowskich.
CSM_56 Jak przedstawiono na rys. 1 w sekcji 9.1.7, ERCA gene­
ruje nową parę europejskich kluczy głównych co 17 lat.
Ilekroć ERCA generuje nową parę europejskich kluczy
głównych, tworzy nowy certyfikat główny z podpisem
własnym dla nowego europejskiego klucza publicznego.
Okres ważności europejskiego certyfikatu głównego
wynosi 34 lata i 3 miesiące.
Uwaga: wprowadzenie nowej pary kluczy głównych
oznacza również, że ERCA wygeneruje nowy klucz
główny czujnika ruchu i nowy klucz główny DSRC,
zob. sekcje 9.2.1.2 i 9.2.2.2.
CSM_57 Przed wygenerowaniem nowej pary europejskich kluczy
głównych ERCA przeprowadza analizę siły kryptogra­
ficznej, jaka jest potrzebna w odniesieniu do nowej pary
kluczy, biorąc po uwagę fakt, że powinna pozostać
bezpieczna przez kolejne 34 lata. W razie konieczności
ERCA przechodzi na mechanizm szyfrowania, który jest
mocniejszy niż obecny, jak określono wCSM_50.
▼M1
CSM_58 Ilekroć ERCA generuje nową parę europejskich kluczy
głównych, tworzy certyfikat łączący dla nowego europej­
skiego klucza publicznego i podpisuje go za pomocą
poprzedniego europejskiego klucza prywatnego. Okres
ważności certyfikatu łączy wynosi 17 lat i 3 miesiące.
Przedstawiono to również na rys. 1 w sekcji 9.1.7.
▼B
Uwaga: ze względu na fakt, że certyfikat łączący zawiera
klucz publiczny ERCA generacji X i jest podpisany za
pomocą klucza prywatnego ERCA generacji X – 1, certy­
fikat łączący oferuje urządzenie wydane w generacji X – 1,
metodę potwierdzenia niezawodności urządzenia wyda­
nego w generacji X.
CSM_59 ERCA nie może używać klucza prywatnego z pary kluczy
głównych do jakiegokolwiek celu, po tym jak nowy certy­
fikat kluczy głównych stanie się ważny.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 451
CSM_60 W każdym momencie ERCA dysponuje następującymi
kluczami i certyfikatami kryptograficznymi:
— bieżąca para kluczy europejskich i powiązany
certyfikat;
— wszystkie wcześniejsze certyfikaty EUR wykorzysty­
wane do weryfikacji certyfikatów MSCA, które nadal
są ważne;
— certyfikaty łączące dla wszystkich generacji certyfi­
katów EUR, z wyjątkiem pierwszej.
9.1.3 Poziom państwa członkowskiego
CSM_61 Na poziomie państwa członkowskiego wszystkie państwa
członkowskie zobowiązane do podpisania certyfikatów
kart do tachografu generują co najmniej jedną unikatową
parę kluczy ECC oznaczoną jako MSCA_Card. Wszystkie
państwa członkowskie zobowiązane do podpisania certyfi­
katów dla przyrządów rejestrujących lub urządzeń zewnętrz­
nych GNSS dodatkowo generują co najmniej jedną unika­
tową parę kluczy ECC oznaczoną jako MSCA_VU-EGF.
CSM_62 Organem odpowiedzialnym za generowanie par kluczy
państwa członkowskiego jest organ certyfikacji państwa
członkowskiego (MSCA). Ilekroć MSCA generuje parę
kluczy państwa członkowskiego, przesyła ERCA klucz
publiczny, aby uzyskać powiązany z nim certyfikat
państwa członkowskiego podpisany przez ERCA.
CSM_63 MSCA dobiera siłę pary kluczy państwa członkowskiego
w taki sposób, by odpowiadała ona sile pary europejskich
kluczy głównych użytej do podpisania powiązanego certy­
fikatu państwa członkowskiego.
CSM_64 Para kluczy MSCA_VU-EGF, jeżeli występuje, składa się
z klucza prywatnego MSCA_VU-EGF.SK i klucza
publicznego MSCA_VU-EGF.PK. MSCA używa klucza
prywatnego MSCA_VU-EGF.SK wyłącznie do podpisy­
wania certyfikatów klucza publicznego przyrządów rejes­
trujących oraz urządzeń zewnętrznych GNSS.
CSM_65 Para kluczy MSCA_Card składa się z klucza prywatnego
MSCA_Card.SK i klucza publicznego MSCA_Card.PK.
MSCA używa klucza prywatnego MSCA_Card.SK wyłącznie
do podpisywania certyfikatów klucza publicznego kart do
tachografu.
CSM_66 MSCA prowadzi rejestry wszystkich podpisanych certyfi­
katów VU, certyfikatów urządzeń zewnętrznych GNSS
oraz certyfikatów karty i zamieszcza w nim również infor­
macje pozwalające zidentyfikować urządzenie, dla którego
wydano dany certyfikat.
CSM_67 Okres ważności certyfikatu MSCA_VU-EGF wynosi 17 lat
i 3 miesiące. Okres ważności certyfikatu MSCA_Card
wynosi 7 lat i 1 miesiąc.
CSM_68 Jak przedstawiono na rys. 1 w sekcji 9.1.7, okres użytko­
wania klucza prywatnego pary kluczy MSCA_VU-EGF
i klucza prywatnego pary kluczy MSCA_Card wynosi
dwa lata.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 452
CSM_69 MSCA nie może używać klucza prywatnego wchodzącego
w skład pary kluczy MSCA_VU-EGF do żadnych celów
po zakończeniu okresu jego użytkowania. Podobnie
MSCA nie może używać klucza prywatnego wchodzącego
w skład pary kluczy MSCA_Card do żadnych celów, po
zakończeniu okresu jego użytkowania.
CSM_70 W każdym momencie MSCA dysponuje następującymi
kluczami i certyfikatami kryptograficznymi:
— bieżącą parą kluczy MSCA_Card i powiązanym
certyfikatem;
— wszystkimi poprzednimi certyfikatami MSCA_Card,
które mają służyć do weryfikacji certyfikatów kart do
tachografu, które są nadal ważne;
— bieżącym certyfikatem EUR koniecznym do przepro­
wadzenia weryfikacji bieżącego certyfikatu MSCA;
— wszystkimi poprzednimi certyfikatami EUR koniecz­
nymi do zweryfikowania wszystkich certyfikatów
MSCA, które są nadal ważne.
CSM_71 Jeżeli MSCA jest również zobowiązana do podpisywania
certyfikatów dla przyrządów rejestrujących lub urządzeń
zewnętrznych GNSS, musi dodatkowo dysponować nastę­
pującymi kluczami i certyfikatami:
— bieżącą parą kluczy MSCA_VU-EGF i powiązanym
certyfikatem;
— wszystkimi poprzednimi kluczami publicznymi
MSCA_VU-EGF, które mają służyć do weryfikacji
certyfikatów VU lub urządzeń zewnętrznych GNSS,
które są nadal ważne.
9.1.4 Poziom urządzenia: przyrządy rejestrujące
▼M1
CSM_72 Dla każdego przyrządu rejestrującego generuje się dwie
unikatowe pary kluczy ECC oznaczone jako VU_MA
i VU_Sign. Zadanie to realizują producenci VU. Ilekroć
generowana jest para kluczy VU, organ generujący klucz
przekazuje klucz publiczny swojemu MSCA, aby uzyskać
powiązany certyfikat VU podpisany przez MSCA. Klucz
prywatny może być używany wyłącznie przez przyrząd
rejestrujący.
▼B
CSM_73 Data wejścia w życie certyfikatów VU_MA i VU_Sign
danego przyrządu rejestrującego musi być taka sama.
CSM_74 Producent VU dobiera siłę pary kluczy VU w taki sposób,
by odpowiadała ona sile pary kluczy MSCA użytej do
podpisania powiązanego certyfikatu VU.
CSM_75 Przyrząd rejestrujący używa swojej pary kluczy VU_MA,
w której skład wchodzi klucz prywatny VU_MA.SK
i klucz publiczny VU_MA.PK, wyłącznie do uwierzytel­
nienia VU w stosunku do kart do tachografu i urządzeń
zewnętrznych GNSS, jak określono w sekcjach 10.3 i 11.4
niniejszego dodatku.
CSM_76 Przyrząd rejestrujący musi mieć możliwość generowania
par efemerycznych kluczy ECC i musi używać pary kluczy
efemerycznych wyłącznie do przeprowadzenia operacji
uzgadniania klucza sesji z kartą do tachografu lub urzą­
dzeniem zewnętrznym GNSS, jak określono w sekcjach
10.4 i 11.4 niniejszego dodatku.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 453
CSM_77 Przyrząd rejestrujący używa klucza prywatnego
VU_Sign.SK wchodzącego w skład pary kluczy VU_Sign
wyłącznie do podpisywania pobranych plików danych, jak
określono w rozdziale 14 niniejszego dodatku. Powiązanego
klucza publicznego VU_Sign.PK używa się wyłącznie do
weryfikacji podpisów wygenerowanych przez przyrząd
rejestrujący.
CSM_78 Zgodnie z informacjami przedstawionymi na rys. 1
w sekcji 9.1.7 okres ważności certyfikatu VU_MA wynosi
15 lat i 3 miesiące. Okres ważności certyfikatu VU_Sign
również wynosi 15 lat i 3 miesiące.
Uwagi
— Wydłużony okres ważności certyfikatu VU_Sign
umożliwia przyrządowi rejestrującemu generowanie
ważnych podpisów w odniesieniu do pobieranych
danych przez pierwsze trzy miesiące po wygaśnięciu
certyfikatu zgodnie z przepisami rozporządzenia (UE)
nr 581/2010.
— Wydłużony okres ważności certyfikatu VU_MA jest
potrzebny, aby umożliwić VU uwierzytelnianie karty
kontrolnej lub karty firmowej w ciągu pierwszych
trzech miesięcy po wygaśnięciu certyfikatu, dzięki
czemu istnieje możliwość pobrania danych.
CSM_79 Przyrząd rejestrujący nie może używać klucza prywatnego
wchodzącego w skład pary kluczy VU do żadnych celów
po wygaśnięciu powiązanego z nim certyfikatu.
CSM_80 Par kluczy VU (z wyjątkiem par kluczy efemerycznych)
i powiązanych z nimi certyfikatów danego przyrządu rejes­
trującego nie można zastępować ani odnawiać w warun­
kach polowych po rozpoczęciu eksploatacji przyrządu
rejestrującego.
Uwagi
— Wymóg ten nie ma zastosowania do par kluczy efeme­
rycznych, ponieważ VU generuje nową parę kluczy
efemerycznych w ramach każdego procesu uwierzytel­
niania mikroprocesora i uzgadniania klucza sesji – zob.
sekcja 10.4. Należy zwrócić uwagę na fakt, że pary
kluczy efemerycznych nie są powiązane z żadnymi
certyfikatami.
— Wymóg ten nie uniemożliwia zastąpienia statycznych
par kluczy VU w trakcie modernizacji lub naprawy
przeprowadzanej w bezpiecznym środowisku kontrolo­
wanym przez producenta VU.
CSM_81 W chwili ich oddawania do eksploatacji przyrządy rejes­
trujące muszą zawierać następujące klucze i certyfikaty
kryptograficzne:
— klucz prywatny VU_MA i powiązany certyfikat;
— klucz prywatny VU_Sign i powiązany certyfikat;
— certyfikat MSCA_VU-EGF zawierający klucz
publiczny MSCA_VU-EGF.PK służący do weryfikacji
certyfikatu VU_MA oraz certyfikatu VU_Sign;
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 454
— certyfikat EUR zawierający klucz publiczny EUR.PK
służący do weryfikacji certyfikatu MSCA_VU-EGF;
— certyfikat EUR, którego okres ważności wygasa bezpo­
średnio przed okresem ważności certyfikatu EUR
służącego do weryfikacji certyfikatu MSCA_VU-
EGF, o ile istnieje;
— certyfikat łączący wspomniane dwa certyfikaty EUR,
o ile istnieje.
CSM_82 Poza kluczami i certyfikatami kryptograficznymi wymie­
nionymi w CSM_81 przyrządy rejestrujące muszą również
zawierać klucze i certyfikaty wskazane w części A niniej­
szego dodatku, dzięki czemu przyrząd rejestrujący może
komunikować się z kartami do tachografu pierwszej
generacji.
9.1.5 Poziom urządzenia: karty do tachografu
▼M1
CSM_83 Dla każdej karty do tachografu generuje się jedną unika­
tową parę kluczy ECC oznaczoną jako Card_MA. Dla
każdej karty kierowcy i karty warsztatowej generuje się
dodatkowo drugą unikatową parę kluczy ECC oznaczoną
jako Card_Sign. Zadanie to mogą realizować producenci
kart lub instytucje dokonujące personalizacji kart. Ilekroć
generowana jest para kluczy karty, organ generujący klucz
przekazuje klucz publiczny swojemu MSCA, aby uzyskać
powiązany certyfikat karty podpisany przez MSCA. Klucz
prywatny może być używany wyłącznie przez kartę do
tachografu.
▼B
CSM_84 Data wejścia w życie certyfikatów Card_MA i Card_Sign
danej karty kierowcy i karty warsztatowej musi być taka
sama.
CSM_85 Producent kart lub instytucja dokonująca personalizacji
kart dobiera siłę par kluczy karty w taki sposób, by odpo­
wiadała ona sile pary kluczy MSCA użytej do podpisania
powiązanego certyfikatu karty.
CSM_86 Karta do tachografu używa swojej pary kluczy Card_MA,
w której skład wchodzi klucz prywatny Card_MA.SK
i klucz publiczny Card_MA.PK, wyłącznie do wzajem­
nego uwierzytelniania i uzgadniania klucza sesji
w stosunku do przyrządów rejestrujących, jak określono
w sekcjach 10.3 i 10.4 niniejszego dodatku.
CSM_87 Karta kierowcy lub karta warsztatowa używa klucza
prywatnego Card_Sign.SK wchodzącego w skład pary
kluczy Card_Sign wyłącznie do podpisywania pobranych
plików danych, jak określono w rozdziale 14 niniejszego
dodatku. Powiązanego klucza publicznego Card_Sign.PK
używa się wyłącznie do weryfikacji podpisów wygenero­
wanych przez kartę.
▼M1
CSM_88 Okres ważności certyfikatu Card_MA wynosi:
— w przypadku kart kierowcy: 5 lat,
— w przypadku kart firmowych: 5 lat,
— w przypadku kart kontrolnych: 2 lata,
— w przypadku kart warsztatowych: 1 rok.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 455
CSM_89 Okres ważności certyfikatu Card_Sign wynosi:
— w przypadku kart kierowcy: 5 lat i 1 miesiąc;
— w przypadku kart warsztato­
wych:
1 rok i 1 miesiąc.
Uwaga: wydłużony okres ważności certyfikatu Card_Sign
umożliwia karta kierowcy generowanie ważnych podpisów
w odniesieniu do pobieranych danych przez pierwszy
miesiąc po wygaśnięciu certyfikatu. Jest to konieczne
w świetle wymogu ustanowionego w rozporządzeniu (UE)
nr 581/2010, zgodnie z którym pobranie danych z karty
kierowcy musi być możliwe przez okres do 28 dni od daty
dokonania ostatniego zapisu danych na tej karcie.
CSM_90 Par kluczy i powiązanych certyfikatów danej karty do
tachografu nie można zastępować ani odnawiać po
wydaniu karty.
CSM_91 W chwili ich wydawania karty do tachografu muszą
zawierać następujące klucze i certyfikaty kryptograficzne:
— klucz prywatny Card_MA i powiązany certyfikat;
— w przypadku kart kierowcy i kart warsztatowych
dodatkowo: klucz prywatny Card_Sign i powiązany
certyfikat;
— certyfikat MSCA_Card zawierający klucz publiczny
MSCA_Card.PK służący do weryfikacji certyfikatu
Card_MA oraz certyfikatu Card_Sign;
— certyfikat EUR zawierający klucz publiczny EUR.PK
służący do weryfikacji certyfikatu MSCA_Card;
— certyfikat EUR, którego okres ważności wygasa bezpo­
średnio przed okresem ważności certyfikatu EUR
służącego do weryfikacji certyfikatu MSCA_Card,
o ile istnieje;
— certyfikat łączący wspomniane dwa certyfikaty EUR,
o ile istnieje.
▼M1
— dodatkowo tylko w przypadku kart kontrolnych, kart
firmowych i kart warsztatowych i tylko jeżeli takie
karty zostały wydane w ciągu pierwszych trzech
miesięcy okresu ważności nowego certyfikatu EUR:
certyfikat EUR starszy o dwie generacje, jeżeli wystę­
puje.
Uwaga do tiret ostatniego: Przykładowo w pierwszych
trzech miesiącach certyfikatu ERCA(3) (zob. rys. 1)
wspomniane karty zawierają certyfikat ERCA(1).
Uwzględnienie certyfikatu ERCA(1) jest konieczne
w celu zapewnienia możliwości używania tych kart
na potrzeby pobierania danych z przyrządów rejestru­
jących, których normalny okres użyteczności wyno­
szący 15 lat plus trzy miesiące okresu pobierania
danych upływa w ciągu tych miesięcy; zob. tiret
ostatnie wymogu 13 w załączniku IC.
▼B
CSM_92 Poza kluczami i certyfikatami kryptograficznymi wymie­
nionymi w CSM_91 karty do tachografu muszą również
zawierać klucze i certyfikaty wskazane w części A niniej­
szego dodatku, dzięki czemu mogą komunikować się z VU
pierwszej generacji.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 456
9.1.6 Poziom urządzenia: urządzenia zewnętrzne GNSS
▼M1
CSM_93 Dla każdego urządzenia zewnętrznego GNSS generuje się
jedną unikatową parę kluczy ECC oznaczoną jako
EGF_MA. Zadanie to realizują producenci urządzeń
zewnętrznych GNSS. Ilekroć generowana jest para kluczy
EGF_MA, organ generujący klucz przekazuje klucz
publiczny swojemu MSCA, aby uzyskać powiązany certy­
fikat EGF_MA podpisany przez MSCA. Klucz prywatny
może być używany wyłącznie przez urządzenie zewnętrzne
GNSS.
▼B
CSM_94 Producent EGF dobiera siłę pary kluczy EGF_MA w taki
sposób, by odpowiadała ona sile pary kluczy MSCA użytej
do podpisania powiązanego certyfikatu EGF_MA.
▼M1
CSM_95 Urządzenie zewnętrzne GNSS używa swojej pary kluczy
EGF_MA, w której skład wchodzi klucz prywatny
EGF_MA.SK i klucz publiczny EGF_MA.PK, wyłącznie
do wzajemnego uwierzytelniania i uzgadniania klucza sesji
w stosunku do przyrządów rejestrujących, jak określono
w sekcji 11.4 niniejszego dodatku.
▼B
CSM_96 Okres ważności certyfikatu EGF_MA wynosi 15 lat.
CSM_97 Urządzenie zewnętrzne GNSS nie może używać klucza
prywatnego wchodzącego w skład pary kluczy EGF_MA
do wiązania się z przyrządem rejestrującym po wygaś­
nięciu powiązanego z nim certyfikatu.
Uwaga: jak wyjaśniono w sekcji 11.3.3, EGF może poten­
cjalnie używać swojego klucza prywatnego na potrzeby
wzajemnego uwierzytelniania w stosunku do VU, jeżeli
został już z nim powiązany, nawet po upływie okresu
ważności powiązanego certyfikatu.
CSM_98 Pary kluczy EGF_MA i powiązanych certyfikatów danego
urządzenia zewnętrznego GNSS nie można zastępować ani
odnawiać w warunkach polowych po rozpoczęciu eksploa­
tacji EGF.
Uwaga: wymóg ten nie uniemożliwia zastąpienia par
kluczy EGF w trakcie modernizacji lub naprawy przepro­
wadzanej w bezpiecznym środowisku kontrolowanym
przez producenta EGF.
CSM_99 W chwili ich oddawania do eksploatacji urządzenia
zewnętrzne GNSS muszą zawierać następujące klucze
i certyfikaty kryptograficzne:
— klucz prywatny EGF_MA i powiązany certyfikat;
— certyfikat MSCA_VU-EGF zawierający klucz
publiczny MSCA_VU-EGF.PK służący do weryfikacji
certyfikatu EGF_MA;
— certyfikat EUR zawierający klucz publiczny EUR.PK
służący do weryfikacji certyfikatu MSCA_VU-EGF;
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 457
— certyfikat EUR, którego okres ważności wygasa bezpo­
średnio przed okresem ważności certyfikatu EUR
służącego do weryfikacji certyfikatu MSCA_VU-
EGF, o ile istnieje;
— certyfikat łączący wspomniane dwa certyfikaty EUR,
o ile istnieje.
9.1.7 Przegląd: zastąpienie certyfikatu
Na rys. 1 poniżej przedstawiono, w jaki sposób różne generacje certyfi­
katów głównych ERCA, certyfikatów łączących ERCA, certyfikatów
MSCA oraz certyfikatów urządzeń (VU i kart) są wydawane i 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 — 21.08.2023 — 003.002 — 458
Uwagi do rys. 1
1. poszczególne generacje certyfikatów głównych oznaczono cyfrą
w nawiasie. Na przykład ERCA (1) oznacza pierwszą generację 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 — 21.08.2023 — 003.002 — 459
Tabela 3
Klucze do zabezpieczania łączności między przyrządem rejestrującym a czujnikiem ruchu
Klucz Symbol Generowany przez Metoda generowania Przechowywany przez
Klucz główny czujnika
ruchu – część dotycząca
VU
K M-VU ERCA Losowo ERCA, MSCA zaangażowane
w wydawanie certyfikatów
VU, producenci VU, przyrządy
rejestrujące
Klucz główny czujnika
ruchu – część dotycząca
warsztatu
K M-WC ERCA Losowo ERCA, MSCA, producenci
kart, karty warsztatowe
Klucz główny czujnika
ruchu
K M Nie jest genero­
wany oddzielnie
Obliczany jako K M =
K M-VU XOR K M-WC
ERCA, MSCA zaangażowane
w wydawanie kluczy czuj­
ników ruchu (opcjonalnie) (*)
Klucz identyfikacyjny K ID Nie jest genero­
wany oddzielnie
Obliczany jako K ID =
K M XOR CV, gdzie
CV jest określony
w CSM_106
ERCA, MSCA zaangażowane
w wydawanie kluczy czuj­
ników ruchu (opcjonalnie) (*)
Klucz parowania K P Producent czujnika
ruchu
Losowo Jeden czujnik ruchu
Klucz sesji K S VU (w trakcie
parowania VU
z czujnikiem
ruchu)
Losowo Jeden VU i jeden czujnik
ruchu
(*) Przechowywanie K M i K ID jest opcjonalne, ponieważ klucze te można wyprowadzić z K M-VU , K M-WC i CV.
CSM_101 Główny Europejski Organ Certyfikacji generuje K M-WU
i K M-WC , dwa losowe, unikatowe klucze AES, na podstawie
których można obliczyć klucz główny czujnika ruchu K M
jako K M-VU XOR K M-WC . Na wniosek organów certyfikacji
państw członkowskich ERCA przekazuje im K M , K M-VU
i K M-WC .
CSM_102 ERCA przypisuje każdemu kluczowi głównemu czujnika
ruchu K M unikatowy numer wersji mający zastosowanie
również do kluczy ustanawiających K M-VU i K M-WC oraz
do powiązanego klucza identyfikacyjnego K ID . ERCA
powiadamia MSCA o numerze wersji, gdy przekazuje im
K M-VU i K M-WC .
Uwaga: numer wersji wykorzystuje się do rozróżnienia
poszczególnych generacji wspomnianych kluczy, jak wyjaś­
niono szczegółowo w sekcji 9.2.1.2.
CSM_103 Organ certyfikacji państwa członkowskiego przekazuje K M-
VU wraz z jego numerem wersji producentom przyrządów
rejestrujących na ich wniosek. Producenci VU umieszczają
K M-VU wraz z jego numerem wersji we wszystkich wytwa­
rzanych VU.
CSM_104 Organ certyfikacji państwa członkowskiego zapewnia
umieszczenie K M-WC wraz z jego numerem wersji w każdej
karcie warsztatowej wydanej pod nadzorem MSCA.
Uwagi
— Zobacz opis typu danych
w dodatku 2.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 460
— Jak wyjaśniono w sekcji 9.2.1.2, w praktyce w niektó­
rych przypadkach może zachodzić konieczność umiesz­
czenia wielu generacji K M-WC w pojedynczej karcie
warsztatowej.
CSM_105 Poza kluczem AES, o którym mowa w CSM_104, MSCA
zapewnia również umieszczenie klucza TDES Km WC, ,
o którym mowa w wymogu CSM_037 w części A niniej­
szego dodatku, w każdej karcie warsztatowej wydanej pod
nadzorem MSCA.
Uwagi
— Zapewnia to możliwość użycia karty warsztatowej
drugiej generacji do powiązania z VU pierwszej
generacji.
— Karta warsztatowa drugiej generacji będzie posiadała
dwie różne aplikacje, z których jedna będzie zgodna
z częścią B niniejszego dodatku, a druga – z częścią
A niniejszego dodatku. Ta druga aplikacja będzie zawie­
rała klucz TDES Km WC .
CSM_106 MSCA zaangażowany w wydawanie certyfikatów czujników
ruchu wyprowadza klucz identyfikacyjny z klucza głównego
czujnika ruchu, za pomocą funkcji XOR z wykorzystaniem
wektora stałego CV. Przyjmuje się, że CV ma następującą
wartość:
▼M1
— w odniesieniu do 128-bitowych kluczy głównych czuj­
nika ruchu: CV = „B6 44 2C 45 0E F8 D3 62 0B 7A
8A 97 91 E4 5D 83”
▼B
— w odniesieniu do 192-bitowych kluczy głównych czuj­
nika ruchu: CV = „72 AD EA FA 00 BB F4 EE F4 99
15 70 5B 7E EE BB 1C 54 ED 46 8B 0E F8 25”
— w odniesieniu do 256-bitowych kluczy głównych czuj­
nika ruchu: CV = „1D 74 DB F0 34 C7 37 2F 65 55 DE
D5 DC D1 9A C3 23 D6 A6 25 64 CD BE 2D 42 0D
85 D2 32 63 AD 60”
Uwaga: wektory stałe generuje się w następujący sposób:
Pi_10 = pierwsze 10 bajtów dziesiętnej części stałej mate­
matycznej π = „24 3F 6A 88 85 A3 08 D3 13 19”
CV_128-bits = pierwszych 16 bajtów SHA-256(Pi_10)
CV_192-bits = pierwsze 24 bajty SHA-384(Pi_10)
CV_256-bits = pierwsze 32 bajty SHA-512(Pi_10)
CSM_107 ►M1 Każdy producent czujników ruchu generuje losowy
i unikatowy klucz parowania K P dla każdego czujnika ruchu
i przesyła każdy klucz parowania organowi certyfikacji
państwa członkowskiego (MSCA). MSCA szyfruje każdy
klucz parowania oddzielnie za pomocą klucza głównego
czujnika ruchu K M i zwraca zaszyfrowany klucz producen­
towi czujników ruchu. W przypadku każdego zaszyfrowa­
nego klucza MSCA powiadamia producenta czujników
ruchu o numerze wersji powiązanego K M . ◄
Uwaga: jak wyjaśniono w sekcji 9.2.1.2, w praktyce może
zachodzić konieczność wygenerowania przez producenta
czujników ruchu wielu unikatowych kluczy parowania dla
pojedynczego czujnika ruchu.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 461
CSM_108 Każdy producent czujników ruchu generuje unikatowy
numer seryjny dla każdego czujnika ruchu i przesyła
wszystkie numery seryjne swojemu organowi certyfikacji
państwa członkowskiego. MSCA szyfruje każdy numer
seryjny oddzielnie za pomocą klucza identyfikacyjnego
K ID i zwraca zaszyfrowany numer seryjny producentowi
czujników ruchu. W przypadku każdego zaszyfrowanego
numeru seryjnego MSCA powiadamia producenta czujników
ruchu o numerze wersji powiązanego K ID .
▼B
CSM_109 W odniesieniu do wymogów CSM_107 i CSM_108 MSCA
korzysta z algorytmu AES w trybie wiązania bloków zaszyf­
rowanych, jak określono w normie [ISO 10116], z naprze­
miennym parametrem m = 1 oraz wektorem inicjującym SV
= „00” {16}, tj. szesnaście bajtów o wartości binarnej 0.
W razie potrzeby MSCA korzysta z metody wypełniania 2
określonej w normie [ISO 9797-1].
CSM_110 Producent czujników ruchu przechowuje zaszyfrowany
klucz parowania i zaszyfrowany numer seryjny w przewi­
dzianym czujniku ruchu wraz z odpowiadającymi warto­
ściami zwykłego tekstu i numerem wersji K M i K ID użytymi
do szyfrowania.
Uwaga: jak wyjaśniono w sekcji 9.2.1.2, w praktyce może
zachodzić konieczność umieszczenia przez producenta czuj­
ników ruchu wielu zaszyfrowanych kluczy parowania
i wielu zaszyfrowanych numerów seryjnych w pojedynczym
czujniku ruchu.
CSM_111 Oprócz materiału kryptograficznego opartego na AES okre­
ślonego w CSM_110, producent czujników ruchu może
również przechowywać w każdym czujniku ruchu materiał
kryptograficzny oparty na TDES, jak określono w niniejszym
dodatku część A wymóg CSM_037.
Uwaga: dzięki temu możliwe będzie powiązanie czujnika
ruchu drugiej generacji z VU pierwszej generacji.
CSM_112 Długość klucza sesji K S wygenerowanego przez VU
w trakcie parowania z czujnikiem ruchu jest powiązana
z długością jego K M-VU , jak opisano w CSM_50.
9.2.1.2 Zastąpienie klucza głównego czujnika ruchu w urządzeniu drugiej gene­
racji
CSM_113 Każdy klucz główny czujnika ruchu i wszystkie powiązane
klucze (zob. tabela 3) są powiązane z określoną generacją
pary kluczy głównych ERCA. Klucze te wymienia się zatem
co 17 lat. Okres ważności każdej generacji klucza głównego
czujnika ruchu rozpoczyna się rok wcześniej, zanim powią­
zana para kluczy głównych ERCA stanie się ważna, i kończy
się po upływie ważności powiązanej pary kluczy głównych
ERCA. Przedstawiono to na rys. 2.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 462
Rys. 2
Wydawanie różnych generacji klucza głównego czujnika ruchu i ich używanie w przyrządach rejestrujących,
czujnikach ruchu i kartach warsztatowych
CSM_114 Co najmniej rok przed wygenerowaniem nowej pary euro­
pejskich kluczy głównych, jak opisano w CSM_56, ERCA
generuje nowy klucz główny czujnika ruchu K M poprzez
wygenerowanie nowych K M-VU i K M-WC . Długość klucza
głównego czujnika ruchu jest powiązana z przewidywaną
siłą nowej pary europejskich kluczy głównych zgodnie
z CSM_50. Na wniosek MSCA ERCA przekazuje im
nowe K M , K M-VU i K M-WC wraz z ich numerem wersji.
CSM_115 MSCA zapewnia, aby wszystkie ważne generacje K M-WC
były przechowywane na karcie warsztatowej wydanej
z jego upoważnienia wraz z numerami wersji, jak przedsta­
wiono na rys. 2.
Uwaga: oznacza to, że w ostatnim roku okresu ważności
certyfikatu ERCA karty warsztatowe będą wydawane z trzema
różnymi generacjami K M-WC , jak przedstawiono na rys. 2.
CSM_116 W odniesieniu do procesu opisanego w CSM_107
i CSM_108 powyżej: MSCA szyfruje każdy klucz paro­
wania K P , który otrzymuje od producenta czujników ruchu,
oddzielnie za pomocą każdej ważnej generacji klucza głów­
nego czujnika ruchu K M . MSCA szyfruje również każdy
numer seryjny, który otrzymuje od producenta czujników
ruchu, oddzielnie za pomocą każdej ważnej generacji klucza
identyfikacyjnego K ID . Producent czujników ruchu przecho­
wuje wszystkie zaszyfrowane klucze parowania i wszystkie
zaszyfrowane numery seryjne w przewidzianym czujniku
ruchu wraz z odpowiadającymi wartościami zwykłego tekstu
i numerami wersji K M i K ID użytymi do szyfrowania.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 463
Uwaga: oznacza to, że w ostatnim roku okresu ważności
certyfikatu ERCA czujniki ruchu będą wydawane z zaszyfro­
wanymi danymi opartymi na trzech różnych generacjach
K M, , jak przedstawiono na rys. 2.
CSM_117 W odniesieniu do procesu opisanego powyżej w CSM_107:
ze względu na fakt, że długość klucza parowania K P jest
powiązana z długością K M (zob. CSM_100), producent czuj­
nika ruchu może być zmuszony do wygenerowania do
trzech różnych kluczy parowania (o różnej długości) dla
jednego czujnika ruchu, w przypadku gdy kolejne generacje
K M mają różne długości. W takim przypadku producent
przesyła MSCA każdy klucz parowania. MSCA zapewnia,
aby każdy klucz parowania był zaszyfrowany za pomocą
prawidłowej generacji klucza głównego czujnika ruchu tj.
klucza mającego taką samą długość.
Uwaga: w przypadku gdy producent czujników ruchu
zdecyduje się wygenerować klucz parowania oparty na
TDES dla czujnika ruchu drugiej generacji (zob. CSM_111),
producent wskazuje MSCA, że klucz główny czujnika ruchu
oparty na TDES musi zostać użyty do zaszyfrowania tego
klucza parowania. Wynika to z tego, że długość klucza
TDES może być równa długości klucza AES, tak więc
MSCA nie może dokonać oceny wyłącznie na podstawie
długości klucza.
CSM_118 Producenci przyrządów rejestrujących umieszczają tylko
jedną generację K M-VU w każdym przyrządzie rejestrującym
wraz z jego numerem wersji. Wspomniana generacja K M-VU
musi być powiązana z certyfikatem ERCA, na których opie­
rają się certyfikaty VU.
Uwagi
— Przyrząd rejestrujący oparty na certyfikacie ERCA gene­
racji X zawiera jedynie K M-VU generacji X, nawet jeżeli
został wydany po rozpoczęciu okresu ważności certyfi­
katu ERCA generacji X + 1. Przedstawiono to na rys. 2.
— Przyrządu rejestrującego generacji X nie można
sparować z czujnikiem ruchu generacji X – 1.
— Ze względu na fakt, że okres ważności kart warsztato­
wych wynosi jeden rok, w wyniku zastosowania
CSM_113 – CSM_118 wszystkie karty warsztatowe
będą zawierały nowy K M-WC w momencie wydania
pierwszego VU zawierającego nowy K M-VU . W związku
z tym taki VU zawsze będzie w stanie obliczyć nowy
K M . Ponadto do tego czasu większość nowych czuj­
ników ruchu będzie zawierała zaszyfrowane dane
również oparte na nowym K M .
9.2.2 Klucze do zabezpieczania łączności DSRC
9.2.2.1 Uwagi ogólne
CSM_119 Autentyczność i poufność danych przekazanych organowi
kontrolnemu z przyrządu rejestrującego za pośrednictwem
kanału DSRC do łączności na odległość zapewnia się za
pomocą zestawu kluczy AES specyficznych dla VU, który
wyprowadzono z pojedynczego klucza głównego DSRC,
KM DSRC .
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 464
CSM_120 Klucz główny DSRC KM DSRC stanowi klucz AES, który
jest bezpiecznie generowany, przechowywany i rozpo­
wszechniany przez ERCA. Długość klucza może wynosić
128, 192 lub 256 bitów i jest powiązana z długością pary
europejskich kluczy głównych, jak opisano w CSM_50.
CSM_121 Na wniosek organów certyfikacji państw członkowskich
ERCA przekazuje im klucz główny DSRC w sposób
bezpieczny w celu umożliwienia im wyprowadzenia kluczy
DSRC specyficznych dla VU i zapewnienia umieszczenia
klucza głównego DSRC we wszystkich kartach kontrolnych
i kartach warsztatowych wydanych na ich odpowiedzialność.
CSM_122 ERCA przypisuje każdemu kluczowi głównemu DSRC
unikatowy numer wersji. ERCA powiadamia MSCA
o numerze wersji, gdy przesyła im klucz główny DSRC.
Uwaga: numer wersji wykorzystuje się do rozróżnienia
poszczególnych generacji klucza głównego DSRC, jak
wyjaśniono szczegółowo w sekcji 9.2.2.2.
▼M1
CSM_123 W odniesieniu do każdego przyrządu rejestrującego produ­
cent takiego przyrządu tworzy unikatowy numer seryjny VU
i przesyła taki numer swojemu organowi certyfikacji
państwa członkowskiego we wniosku w celu uzyskania
zestawu dwóch kluczy DSRC specyficznych dla VU.
Numer seryjny VU posiada typ danych VuSerialNumber.
Uwaga:
— Taki numer seryjny VU musi być identyczny
z elementem vuSerialNumber w VuIdentification (zob.
dodatek 1) i z odniesieniem do posiadacza certyfikatu
w certyfikatach VU.
— Numer seryjny VU może nie być znany w momencie
żądania przez producenta przyrządu rejestrującego
kluczy DSRC specyficznych dla VU. W takim przy­
padku producent VU wysyła zastępczo unikatowy iden­
tyfikator wniosku o certyfikat, którego użył, występując
o certyfikaty VU. zob. CSM_153; Taki identyfikator
wniosku o certyfikat musi być zatem identyczny z odnie­
sieniem do posiadacza certyfikatu w certyfikatach VU.
▼B
CSM_124 Po otrzymaniu wniosku o klucze DSRC specyficzne dla VU
MSCA wyprowadza dwa klucze AES dla przyrządu rejes­
trującego, zwane K_VU DSRC _ENC i K_VU DSRC _MAC.
Wspomniane klucze specyficzne dla VU mają taką samą
długość jak klucz główny DSRC. MSCA korzysta z funkcji
wyprowadzania klucza zdefiniowanej w [RFC 5869].
Funkcja skrótu, która jest niezbędna do utworzenia wystą­
pienia funkcji HMAC-Hash, jest powiązana z długością
klucza głównego DSRC, jak opisano w CSM_50. Z funkcji
wyprowadzania klucza w [RFC 5869] korzysta się w nastę­
pujący sposób:
krok 1: (wyodrębnienie):
— PRK = HMAC-Hash (salt, IKM) gdzie salt oznacza
pusty ciąg „”, a IKM oznacza KM DSRC ;
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 465
krok 2: (rozszerzenie):
— OKM = T(1), gdzie
T(1) = HMAC-Hash (PRK, T(0) || info || „01”)
— T(0) = pusty ciąg („”)
— ►M1 info = numer seryjny VU lub identyfikator
wniosku o certyfikat, jak określono w CSM_123
— K_VU DSRC _ENC = pierwsze oktety L OKM i
K_VU DSRC _MAC = ostatnie oktety L OKM
gdzie L oznacza wymaganą długość K_VU DSRC _ENC
i K_VU DSRC _MAC w oktetach.
CSM_125 MSCA przekazuje K_VU DSRC _ENC i K_VU DSRC _MAC
producentowi VU w sposób bezpieczny w celu umiesz­
czenia w przewidzianym przyrządzie rejestrującym.
CSM_126 Po wydaniu przyrząd rejestrujący przechowuje
K_VU DSRC _ENC i K_VU DSRC _MAC w swojej bezpiecznej
pamięci, aby móc zapewnić integralność, autentyczność
i poufność danych wysyłanych za pośrednictwem kanału
do łączności na odległość. Przyrząd rejestrujący przecho­
wuje również numer wersji klucza głównego DSRC użyty
do wyprowadzenia tych kluczy specyficznych dla VU.
CSM_127 Po wydaniu karty kontrolne i karty warsztatowe przecho­
wują KM DSRC w swojej bezpiecznej pamięci, aby móc
zweryfikować integralność i autentyczność danych wysyła­
nych przez VU za pośrednictwem kanału do łączności na
odległość oraz aby deszyfrować te dane. Karty kontrolne
i karty warsztatowe przechowują również numer wersji
klucza głównego DSRC.
Uwaga: jak wyjaśniono w sekcji 9.2.2.2, w praktyce może
zachodzić konieczność umieszczenia wielu generacji
KM DSRC w pojedynczej karcie warsztatowej lub pojedynczej
karcie kontrolnej.
▼M1
CSM_128 MSCA prowadzi rejestry wszystkich wygenerowanych
kluczy DSRC specyficznych dla VU, ich numerów wersji
i numerów seryjnych VU lub identyfikatorów wniosku
o certyfikat wykorzystanych w celu ich wyprowadzenia.
9.2.2.2 Zastąpienie klucza głównego DSRC
CSM_129 Każdy klucz główny DSRC jest powiązany z określoną
generacją pary kluczy głównych ERCA. ERCA zastępuje
zatem klucz główny DSRC co 17 lat. Okres ważności każdej
generacji klucza głównego DSRC rozpoczyna się dwa lata
wcześniej, zanim powiązana para kluczy głównych ERCA
stanie się ważna, i kończy się po upływie ważności powią­
zanej pary kluczy głównych ERCA. Przedstawiono to na
rys. 3.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 466
Rys. 3
Wydawanie różnych generacji klucza głównego DSRC i ich używanie w przyrządach rejestrujących, kartach
warsztatowych i kartach kontrolnych
CSM_130 Co najmniej dwa lata przed wygenerowaniem nowej pary
europejskich kluczy głównych, jak opisano w CSM_56,
ERCA generuje nowy klucz główny DSRC. Długość klucza
DSRC jest powiązana z przewidywaną siłą nowej pary euro­
pejskich kluczy głównych zgodnie z CSM_50. Na wniosek
MSCA ERCA przekazuje im nowy klucz główny DSRC
wraz z jego numerem wersji.
CSM_131 MSCA zapewnia, aby wszystkie ważne generacje KM DSRC
były przechowywane na karcie kontrolnej wydanej z jego
upoważnienia wraz z numerami wersji, jak przedstawiono na
rys. 3.
Uwaga: oznacza to, że w ciągu ostatnich dwóch lat okresu
ważności certyfikatu ERCA karty kontrolne będą wydawane
z trzema różnymi generacjami KM DSRC , jak przedstawiono
na rys. 3.
CSM_132 MSCA zapewnia, aby wszystkie generacje KM DSRC , które
były ważne przez co najmniej rok i nadal są ważne, były
przechowywane na karcie warsztatowej wydanej z jego
upoważnienia wraz z numerami wersji, jak przedstawiono
na rys. 3.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 467
Uwaga: oznacza to, że w ostatnim roku okresu ważności
certyfikatu ERCA karty warsztatowe będą wydawane
z trzema różnymi generacjami KM DSRC , jak przedstawiono
na rys. 3.
CSM_133 Producenci przyrządów rejestrujących umieszczają tylko
jeden zestaw kluczy DSRC specyficznych dla VU w każdym
przyrządzie rejestrującym wraz z jego numerem wersji.
Wspomniany zestaw kluczy wyprowadza się z generacji
KM DSRC powiązanej z certyfikatem ERCA, na którym opie­
rają się certyfikaty VU.
Uwagi
— Oznacza to, że przyrząd rejestrujący oparty na certyfikacie
ERCA generacji X zawiera jedynie K_VU DSRC _ENC
i K_VU DSRC _MAC generacji X, nawet jeżeli VU został
wydany po rozpoczęciu okresu ważności certyfikatu
ERCA generacji X + 1. Przedstawiono to na rys. 3.
— Ze względu na fakt, że okres ważności kart warsztato­
wych wynosi jeden rok, a kart kontrolnych dwa lata,
w wyniku zastosowania CSM_131 – CSM_133 wszystkie
karty warsztatowe i karty kontrolne będą zawierały nowy
klucz główny DSRC w momencie wydania pierwszego
VU zawierającego klucze specyficzne dla VU, oparte na
przedmiotowym kluczu głównym.
9.3. Certyfikaty
9.3.1 Uwagi ogólne
CSM_134 Wszystkie certyfikaty w europejskim systemie tachografów
inteligentnych są certyfikatami samoopisującymi, weryfiko­
walnymi przez kartę (CV) zgodnie z normami [ISO 7816-4]
i [ISO 7816-8].
CSM_135 ►M1 Wyróżnione reguły kodowania (DER) zgodnie
z [normą ISO 8825-1] wykorzystuje się do kodowania
obiektów danych w ramach certyfikatów. W tabeli 4 przed­
stawiono pełne kodowanie świadectw, z uwzględnieniem
wszystkich bajtów znaczników i długości. ◄
Uwaga: w wyniku takiego kodowania uzyskuje się następu­
jącą strukturę TLV:
znacznik: znacznik jest zakodowany w jednym oktecie lub
dwóch oktetach i określa treść;
długość: długość jest zakodowana jako liczba całkowita bez
znaku w jednym oktecie, dwóch lub trzech okte­
tach, co skutkuje uzyskaniem maksymalnej
długości 65 535 oktetów. Stosuje się minimalną
liczbę oktetów;
wartość: wartość nie jest zakodowana w żadnym oktecie
lub jest zakodowana w większej liczbie oktetów.
9.3.2 Treść certyfikatu
CSM_136 Wszystkie certyfikaty mają strukturę przedstawioną w 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
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 468
Pole Nr ID pola Znacznik Długość (bajty)
Typ danych ASN.1
(zob. dodatek 1)
Identyfikator profilu
certyfikatu
CPI „5F 29” „01”
odniesienie do organu
certyfikacji
CAR „42” „08”
upoważnienie posia­
dacza certyfikatu
CHA „5F 4C” „07”
Klucz publiczny 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łasnym, tj. odniesienie do organu certyfikacji pokrywa
się z odniesieniem do posiadacza certyfikatu w certyfikacie.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 469
CSM_140 W przypadku certyfikatu łączącego ERCA odniesienie do
posiadacza certyfikatu pokrywa się z odniesieniem do posia­
dacza certyfikatu nowego certyfikatu głównego ERCA.
W przypadku certyfikatu łączącego odniesienie do organu
certyfikacji pokrywa się z odniesieniem do posiadacza certy­
fikatu poprzedniego certyfikatu głównego ERCA.
9.3.2.3 Upoważnienie posiadacza certyfikatu
▼M1
CSM_141 Upoważnienie posiadacza certyfikatu służy do identyfiko­
wania rodzaju certyfikatu. Składa się ono z sześciu najbar­
dziej znaczących bajtów identyfikatora aplikacji tachogra­
ficznej, połączonych z typem urządzenia, który wskazuje
typ urządzenia, dla którego certyfikat jest przeznaczony.
W przypadku certyfikatu VU, certyfikatu karty kierowcy
lub certyfikatu karty warsztatowej typu urządzenia używa
się również w celu rozróżnienia świadectwa wzajemnego
uwierzytelnienia i certyfikatu na potrzeby tworzenia podpisu
cyfrowego (zob. pkt 9.1 i dodatek 1, typ danych Equipment­
Type).
▼B
9.3.2.4 Klucz publiczny
Klucz publiczny zawiera dwa elementy danych: standardowe 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ę nieskom­
presowany format kodowania. Podczas odzyskiwania punktu
krzywej eliptycznej z jej zakodowanego formatu zawsze prze­
prowadza się autoryzacje opisane w [TR-03111].
9.3.2.5 odniesienie do posiadacza certyfikatu
CSM_144 Odniesienie do posiadacza certyfikatu to identyfikator klucza
publicznego umieszczony w certyfikacie. Używa się go
celem odniesienia do tego klucza publicznego w innych
certyfikatach.
CSM_145 W przypadku certyfikatów kart i certyfikatów urządzeń
zewnętrznych GNSS odniesienie do posiadacza certyfikatu
posiada typ danych , okre­
ślony w dodatku 1.
CSM_146 W przypadku przyrządów rejestrujących producent, skła­
dając wniosek o certyfikat, może znać specyficzny dla
danego producenta numer seryjny VU, dla którego przezna­
czony jest dany certyfikat i powiązany klucz prywatny, ale
nie musi go znać. W pierwszym przypadku odniesienie do
posiadacza certyfikatu posiada typ danych
, określony w dodatku 1.
W tym drugim przypadku odniesienie do posiadacza certy­
fikatu posiada typ danych ,
określony w dodatku 1.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 470
Uwaga: W przypadku certyfikatu karty wartość CHR musi
być równa wartości cardExtendedSerialNumber w EF_ICC;
zob. dodatek 2. W przypadku certyfikatu EGF wartość CHR
musi być równa wartości sensorGNSSSerialNumber
w EF_ICC; zob. dodatek 14. W przypadku certyfikatu VU
wartość CHR musi być równa elementowi vuSerialNumber
w VuIdentification (zob. dodatek 1), chyba że producent nie
zna specyficznego dla danego producenta numeru seryjnego,
w momencie gdy wystąpiono o certyfikat.
▼B
CSM_147 W przypadku certyfikatów ERCA i MSCA odniesienie do posia­
dacza certyfikatu posiada typ danych ,
określony w dodatku 1.
9.3.2.6 Data wejścia w życie certyfikatu
▼M1
CSM_148 Data wejścia w życie certyfikatu określa datę i godzinę
rozpoczęcia okresu ważności certyfikatu.
▼B
9.3.2.7 Data wygaśnięcia certyfikatu
CSM_149 Data wygaśnięcia certyfikatu określa datę i godzinę 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
wniosek;
— odniesienie do organu certyfikacji, w przypadku którego
oczekuje się, że zostanie użyte do podpisania certyfikatu;
— klucz publiczny, który ma zostać podpisany.
CSM_152 Oprócz danych określonych w CSM_151 MSCA przesyła
ERCA następujące dane we wniosku o certyfikat, co umoż­
liwi ERCA utworzenie odniesienia do posiadacza certyfikatu
dla nowego certyfikatu MSCA:
— numeryczny kod krajowy organu certyfikacji (typ
danych , określony w dodatku 1);
— alfanumeryczny kod krajowy organu certyfikacji (typ
danych , określony w dodatku 1);
— 1-bajtowy numer seryjny umożliwiającym rozróżnienie
poszczególnych kluczy organu certyfikacji w przypadku
zmiany kluczy;
— 2-bajtowe pole zawierające dodatkowe informacje na
temat określonego organu certyfikacji.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 471
CSM_153 Producent urządzenia przesyła MSCA następujące dane we
wniosku o certyfikat, co umożliwi MSCA utworzenie odnie­
sienia do posiadacza certyfikatu dla nowego certyfikatu
urządzenia:
— numer seryjny urządzenia, unikalny dla producenta, typu
urządzenia i miesiąc wyprodukowania, jeżeli dane te są
znane (zob. CSM_154). W przeciwnym razie – unika­
towy identyfikator wniosku o certyfikat,
— miesiąc i rok produkcji urządzenia lub miesiąc i rok
sporządzenia wniosku o certyfikat.
Producent zapewnia, aby przedmiotowe dane były prawidłowe, a certy­
fikat zwrócony przez MSCA został umieszczony 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 certy­
fikat. Po umieszczeniu certyfikatu w określonym VU produ­
cent informuje MSCA o połączeniu między numerem
seryjnym wniosku o certyfikat a identyfikacją VU.
10. WZAJEMNE UWIERZYTELNIANIE I BEZPIECZNA WYMIANA
KOMUNIKATÓW MIĘDZY VU A KARTĄ
10.1. Uwagi ogólne
CSM_155 Na wysokim szczeblu bezpieczna łączność między przy­
rządem rejestrującym a kartą do tachografu odbywa się
w następujących etapach:
— po pierwsze każda strona wykazuje drugiej, że posiada
ważny certyfikat klucza publicznego, podpisany przez
organ certyfikacji państwa członkowskiego. Z kolei
certyfikat klucza publicznego MSCA musi zostać podpi­
sany przez Główny Europejski Organ Certyfikacji. Etap
ten nazywany jest weryfikacją łańcucha certyfikatów
i został szczegółowo opisany w sekcji 10.2;
— po drugie przyrząd rejestrujący wykazuje karcie, że
posiada klucz prywatny odpowiadający kluczowi
publicznemu w przedstawionym certyfikacie. Dokonuje
tego poprzez podpisanie losowego numeru wysłanego
przez kartę. Karta weryfikuje podpis na losowym
numerze. Jeżeli weryfikacja zakończy się powodzeniem,
VU zostaje uwierzytelniony. Etap ten nazywany jest
uwierzytelnieniem VU i został szczegółowo opisany
w sekcji 10.3;
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 472
— po trzecie obie strony niezależnie obliczają dwa klucze
sesji AES, korzystając z asymetrycznego algorytmu
uzgadniania klucza. Korzystając z jednego z tych kluczy
sesji karta tworzy kod uwierzytelniania komunikatów
(MAC) w odniesieniu do niektórych danych wysłanych
przez VU. VU weryfikuje MAC. Jeżeli weryfikacja
zakończy się powodzeniem, karta zostaje uwierzytel­
niona. Etap ten nazywany jest uwierzytelnieniem karty
i został szczegółowo opisany w sekcji 10.4;
— po czwarte VU i karta używają zatwierdzonych kluczy
sesji w celu zapewnienia poufności, integralności i auten­
tyczności wszystkich wymienianych komunikatów. Etap
ten nazywany jest bezpieczną wymianą komunikatów
i został szczegółowo opisany w sekcji 10.5.
CSM_156 Mechanizm opisany w CSM_155 jest uruchamiany przez
przyrząd rejestrujący za każdym razem, gdy w jeden z czyt­
ników kart zostaje włożona karta.
10.2. Wzajemna weryfikacja łańcucha certyfikatów
10.2.1 Weryfikacja łańcucha certyfikatów karty przez VU
CSM_157 ►M1 Przyrządy rejestrujące używają protokołu przedsta­
wionego na rys. 4 w celu weryfikacji łańcucha certyfikatów
karty do tachografu. Dla każdego certyfikatu odczytywanego
z karty przyrząd rejestrujący weryfikuje prawidłowość pola
Upoważnienie Posiadacza Certyfikatu (CHA):
— Pole CHA certyfikatu karty wskazuje certyfikat karty na
potrzeby wzajemnego uwierzytelnienia (zob. dodatek 1,
typ danych EquipmentType).
— CHA certyfikatu Card.CA musi wskazywać MSCA.
— CHA certyfikatu Card.Link musi wskazywać ERCA. ◄
Uwagi do rys. 4:
— certyfikaty i klucze publiczne karty wskazane na
rysunku są certyfikatami i kluczami, których używa się
do wzajemnego uwierzytelnienia. W sekcji 9.1.5 ozna­
czono je jako Card_MA;
— certyfikaty i klucze publiczne Card.CA wskazane na
rysunku są certyfikatami i kluczami używanymi do
podpisywania certyfikatów karty i jest to wskazane
w CAR certyfikatu Card.CA. W sekcji 9.1.3 oznaczono
je jako MSCA_Card;
— certyfikat Card.CA.EUR wspomniany na rysunku jest
europejskim certyfikatem głównym wskazanym
w CAR certyfikatu Card.CA;
— certyfikat Card.Link wskazany na rysunku jest certyfi­
katem łączącym karty, o ile istnieje. Jak określono
w sekcji 9.1.2, jest to certyfikat łączący dla nowej
pary europejskich kluczy głównych wygenerowanej
przez ERCA i podpisanej za pomocą poprzedniego euro­
pejskiego klucza prywatnego;
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 473
— certyfikat Card.Link.EUR jest europejskim certyfikatem
głównym wskazanym w CAR certyfikatu Card.Link.
CSM_158 Jak wskazano na rys. 4, weryfikacja łańcucha certyfikatów
karty rozpoczyna się po włożeniu karty. Przyrząd rejestru­
jący odczytuje odniesienie do posiadacza karty
( ) z pliku elementarnego
ICC. VU sprawdza, czy zna kartę tj. czy pomyślnie zwery­
fikował łańcuch certyfikatów karty w przeszłości i zapisało
go na potrzeby przyszłych odniesień. Jeżeli VU zna kartę,
certyfikat karty nadal jest ważny, a proces jest kontynuo­
wany i następuje weryfikacja łańcucha certyfikatów VU.
W przeciwnym razie VU kolejno odczytuje z karty certy­
fikat MSCA_Card, który ma służyć do weryfikacji certyfi­
katu karty Card.CA, certyfikat EUR, który ma służyć do
weryfikacji certyfikatu MSCA_Card, oraz ewentualnie certy­
fikat łączący, do momentu aż znajdzie certyfikat, który
rozpozna lub może zweryfikować. Jeżeli znajdzie taki certy­
fikat, VU używa tego certyfikatu w celu zweryfikowania
podstawowych certyfikatów karty, które odczytał z karty.
Jeżeli proces przebiegnie pomyślnie, nastąpi weryfikacja
łańcucha certyfikatów VU. Jeżeli nie, VU zignoruje kartę.
Uwaga: istnieją trzy sposoby na rozpoznanie certyfikatu
Card.CA.EUR przez VU:
— certyfikat Card.CA.EUR jest taki sam jak certyfikat EUR
VU;
— certyfikat Card.CA.EUR poprzedza certyfikat EUR VU
i VU zawierał już ten certyfikat w chwili wydania (zob.
CSM_81);
— certyfikat Card.CA.EUR zastępuje certyfikat EUR VU
i VU otrzymał w przeszłości certyfikat łączący z innej
karty do tachografu, zweryfikował go i zapisał na
potrzeby przyszłych odniesień.
CSM_159 Jak wskazano na rys. 4, po zweryfikowaniu przez VU 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 — 21.08.2023 — 003.002 — 474
Rys. 4
Protokół weryfikacji łańcucha certyfikatów karty przez VU
10.2.2 Weryfikacja łańcucha certyfikatów VU przez kartę
CSM_161 ►M1 Karty do tachografu używają protokołu przedstawio­
nego na rys. 5 w celu weryfikacji łańcucha certyfikatów
VU. Dla każdego certyfikatu przedstawionego przez przy­
rząd rejestrujący karta weryfikuje prawidłowość pola
Upoważnienie Posiadacza Certyfikatu (CHA):
— CHA certyfikatu VU.Link musi wskazywać ERCA.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 475
— CHA certyfikatu VU.CA musi wskazywać MSCA.
— Pole CHA certyfikatu VU wskazuje certyfikat VU na
potrzeby wzajemnego uwierzytelnienia (zob. dodatek 1,
typ danych EquipmentType). ◄
Rys. 5
Protokół weryfikacji łańcucha certyfikatów VU przez kartę
Uwagi do rys. 5:
— certyfikaty i klucze publiczne VU wskazane na rysunku są 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 — 21.08.2023 — 003.002 — 476
— 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 — 21.08.2023 — 003.002 — 477
CSM_163 VU używa polecenia MSE:Set AT, aby ustawić swój klucz
publiczny do używania w karcie do tachografu. Jak okre­
ślono w dodatku 2, polecenie to zawiera opis mechanizmu
kryptograficznego, który będzie używany wraz z usta­
wionym kluczem. Mechanizm ten określa się mianem uwie­
rzytelnienia VU za pomocą algorytmu ECDSA w połączeniu
z algorytmem skrótu powiązanym z wielkością pary kluczy
VU VU_MA, jak określono w CSM_50.
CSM_164 Polecenie MSE: Set AT zawiera również opis pary kluczy
efemerycznych, których VU będzie używał podczas uzgad­
niania klucza sesji (zob. sekcja 10.4). W związku z tym
przed wysłaniem polecenia MSE: Set AT VU generuje
parę kluczy efemerycznych ECC. W celu wygenerowania
pary kluczy efemerycznych VU używa standardowych para­
metrów domeny wskazanych w certyfikacie karty. Parę
kluczy efemerycznych oznacza się jako (VU.SK eph ,
VU.PK eph , Card.DP). VU uznaje współrzędną x
efemerycznego punktu publicznego ECDH za identyfikację
klucza; określa się to mianem skompresowanej reprezentacji
klucza publicznego i oznacza jako Comp(VU.PK eph ).
▼M1
CSM_165 Jeżeli polecenie MSE: Set AT jest skuteczne, karta 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 — 21.08.2023 — 003.002 — 478
Uwaga: ostatni wymóg oznacza, że karta jest w stanie
rozpoznać CAR certyfikatu VU, tj. certyfikatu
MSCA_VU-EGF. Nie będzie się on pokrywał z CAR certy­
fikatu własnego karty, którym jest certyfikat MSCA_Card.
CSM_168 Jak wskazano na rys. 5, po zweryfikowaniu przez kartę
autentyczności i ważności uprzednio nieznanego certyfikatu,
karta może zapisać ten certyfikat na potrzeby przyszłych
odniesień, tak aby nie musiała po raz kolejny weryfikować
autentyczności tego certyfikatu, gdy zostanie jej ponownie
przedstawiony. Zamiast zapisywać cały certyfikat, karta
może zdecydować się na zapisanie jedynie treści certyfikatu,
jak określono w sekcji 9.3.2.
10.3. Uwierzytelnienie VU
CSM_169 Przyrządy rejestrujące i karty używają protokołu 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 — 21.08.2023 — 003.002 — 479
Rysunek 6
Protokół uwierzytelniania VU
▼B
CSM_172 Jeżeli VU wysyła wielokrotnie polecenie GET CHAL­
LENGE podczas uwierzytelniania VU, karta zwraca za
każdym razem nowe 8-bajtowe losowe żądanie, ale zapisuje
tylko ostatnie żądanie.
CSM_173 Algorytmem podpisywania używanym przez VU w celu
uwierzytelnienia VU jest ECDSA, jak określono w [DSS],
używający algorytmu skrótu powiązanego z wielkością
klucza pary kluczy VU VU_MA, jak określono w CSM_50.
Format podpisu jest odkryty, jak określono w [TR-03111].
VU przesyła uzyskany podpis karcie.
▼M1
CSM_174 Po otrzymaniu podpisu VU w poleceniu EXTERNAL
AUTHENTICATE karta:
— oblicza token uwierzytelniania poprzez połączenie
Card.CHR, żądania karty rcard i identyfikatora efeme­
rycznego klucza publicznego VU Comp(VU.PKeph);
— weryfikuje podpis VU za pomocą algorytmu ECDSA,
używając algorytmu skrótu powiązanego z wielkością
pary kluczy VU VU_MA, jak określono w CSM_50,
w połączeniu z VU.PK i obliczonym tokenem
uwierzytelniania.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 480
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 przekształca
się w ciąg oktetowy, jak określono w [TR-03111]. Stosuje
się nieskompresowany format kodowania. Jak wyjaśniono
w CSM_164, VU wygenerował tę parę kluczy efemerycz­
nych przed zweryfikowaniem łańcucha certyfikatów VU.
VU przesłał karcie identyfikator efemerycznego klucza
publicznego Comp(VU.PK eph ) i karta zapisuje ten
identyfikator;
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 481
3. karta oblicza Comp(VU.PK eph ) na podstawie VU.PK eph
i porównuje go z zapisaną wartością Comp(VU.PK eph );
4. używając algorytmu ECDH w połączeniu ze statycznym
kluczem prywatnym karty i efemerycznym kluczem
publicznym VU, karta oblicza tajny K;
5. karta wybiera losowy 8-bajtowy identyfikator jednora­
zowy N PICC i używa go do wyprowadzenia dwóch
kluczy sesji AES K MAC i K ENC z K. Zob. CSM_179;
▼M1
6. za pomocą K MAC , karta oblicza token uwierzytelniania
w odniesieniu do identyfikatora efemerycznego punktu
publicznego VU: T PICC = CMAC(K MAC , VU.PK eph ).
Punkt publiczny musi być w formacie używanym przez
VU (zob. ppkt 2 powyżej). Karta wysyła N PICC i T PICC
do przyrządu rejestrującego;
▼B
7. używając algorytmu ECDH w połączeniu ze statycznym
kluczem publicznym karty i efemerycznym kluczem
prywatnym VU, przyrząd rejestrujący oblicza ten sam
tajny K co karta w ramach kroku 4;
8. VU wyprowadza klucze sesji K MAC i K ENC z K i N PICC ;
zob. CSM_179;
9. VU weryfikuje token uwierzytelniania T PICC .
CSM_177 W ramach powyższego kroku 3 karta oblicza
Comp(VU.PKeph) jako współrzędną x punktu publicznego
w VU.PKeph.
CSM_178 W ramach powyższych kroków 4 i 7 karta i przyrząd rejes­
trujący używają algorytmu ECKA-EG, jak określono
w [TR-03111].
CSM_179 W ramach powyższych kroków 5 i 8 karta i przyrząd rejes­
trujący używają funkcji wyprowadzania klucza w odnie­
sieniu do kluczy sesji AES zdefiniowanych w [TR-03111]
z następującą dokładnością i następującymi zmianami:
— wartość licznika wynosi „00 00 00 01” w odniesieniu
do K ENC i „00 00 00 02” w odniesieniu do K MAC ;
— używa się opcjonalnego identyfikatora jednorazowego r,
który jest równy N PICC ;
— w celu wyprowadzenia 128-bitowych kluczy AES
używa się algorytmu skrótu SHA-256;
— w celu wyprowadzenia 192-bitowych kluczy AES
używa się algorytmu skrótu SHA-384;
— w celu wyprowadzenia 256-bitowych kluczy AES
używa się algorytmu skrótu SHA-512.
Długość kluczy sesji (tj. długość, do której skrócono skrót)
jest powiązana z wielkością pary kluczy Card_MA, jak
określono w CSM_50.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 482
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 zaszyfro­
waniu, co oznacza, że dane odpowiedzi najpierw są szyfro­
wane w celu zapewnienia poufności komunikatu, a następnie
obliczany jest MAC w stosunku do sformatowanych zaszyf­
rowanych danych w celu zapewnienia autentyczności i inte­
gralności.
CSM_184 W ramach bezpiecznej wymiany komunikatów stosuje się
AES określony w [AES] z kluczami sesji K MAC i K ENC
uzgodnionymi w procesie uwierzytelniania chipu.
CSM_185 Jako licznik sekwencji wysyłania (SSC) stosuje się 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 — 21.08.2023 — 003.002 — 483
10.5.2 Struktura bezpiecznego komunikatu
CSM_188 W bezpiecznej wymianie komunikatów używa się
wyłącznie obiektów danych bezpiecznej wymiany komuni­
katów (zob. [ISO 7816-4]) wymienionych w tabeli 5.
W każdym komunikacie wspomniane obiekty danych
stosuje się w kolejności określonej w poniższej tabeli.
Tabela 5
Obiekty danych bezpiecznej wymiany komunikatów
Nazwa obiektu danych Znacznik
Obecność:
obowiązkowa (M),
warunkowa (C) lub
zabroniona (F) w
poleceniach
odpowie­
dziach
Odkryta wartość niekodowana w BER-
TLV
„81” C C
Odkryta wartość kodowana w BER-
TLV, lecz nie zawiera obiektów danych
bezpiecznej wymiany komunikatów
„B3” C C
Po wskaźniku treści wypełnienia nastę­
puje kryptogram, wartość odkryta nie
jest kodowana w BER-TLV
„87” C C
Chroniona długość „97” C F
Status przetwarzania „99” F M
Kryptograficzna suma kontrolna „8E” M M
Uwaga: jak określono w dodatku 2, karty do tachografu
mogą obsługiwać polecenia READ BINARY i UPDATE
BINARY z nieparzystym bajtem INS („B1” odp. „D7”).
Wymaga się, aby przedstawione warianty poleceń umożli­
wiały odczyt i aktualizację plików o rozmiarze 32 768
bajtów lub więcej. W przypadku zastosowania takiego
wariantu używa się obiektu danych ze znacznikiem „B3”
zamiast obiektu ze znacznikiem „81”. Aby uzyskać więcej
informacji, zob. dodatek 2.
CSM_189 Wszystkie obiekty danych bezpiecznej wymiany komuni­
katów koduje się w DER TLV, jak określono w [ISO
8825-1]. W wyniku takiego kodowania uzyskuje się nastę­
pującą strukturę TLV:
znacznik: znacznik jest zakodowany w jednym oktecie lub
dwóch oktetach i określa treść;
długość: długość jest zakodowana jako liczba całkowita
bez znaku w jednym oktecie, dwóch lub trzech
oktetach, co skutkuje uzyskaniem maksymalnej
długości 65 535 oktetów. Stosuje się minimalną
liczbę oktetów;
wartość: wartość nie jest zakodowana w żadnym oktecie
lub jest zakodowana w większej liczbie oktetów.
CSM_190 Polecenia APDU chronione bezpieczną wymianą komuni­
katów generuje się w następujący sposób:
— nagłówek polecenia uwzględnia się w obliczeniach
MAC, w związku z czym wartość „0C” stosuje się
w przypadku klasy bajtów CLA;
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 484
— jak określono w dodatku 2, wszystkie bajty INS są
parzyste, ewentualnie z wyjątkiem nieparzystych bajtów
INS w przypadku poleceń READ BINARY i UPDATE
BINARY;
— wartość rzeczywista Lc zostanie zmieniona na Lc' po
zastosowaniu bezpiecznej wymiany komunikatów;
— pole danych składa się z obiektów danych bezpiecznej
wymiany komunikatów;
— w chronionym poleceniu APDU nowy bajt Le otrzy­
muje wartość „00”. W razie konieczności obiekt danych
„97” umieszcza się w polu danych w celu przekazania
wartości oryginalnej bajtu Le.
▼M1
CSM_191 Każdy obiekt danych wymagający zaszyfrowania wypełnia
się zgodnie z [ISO 7816-4] przy użyciu wskaźnika treści
wypełnienia „01”. Na potrzeby obliczenia MAC obiekty
danych w APDU wypełnia się również zgodnie z [ISO
7816-4].
Uwaga: wypełnianie na potrzeby bezpiecznej wymiany
komunikatów zawsze przeprowadza się za pomocą warstwy
bezpiecznej wymiany komunikatów, a nie algorytmów
CMAC czy CBC.
Podsumowanie i przykłady
Polecenie APDU z zastosowaniem bezpiecznej wymiany komunikatów
będzie miało następującą strukturę w zależności od przypadku 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 — 21.08.2023 — 003.002 — 485
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 — 21.08.2023 — 003.002 — 486
Rysunek 10
Przekształcenie zaszyfrowanej i uwierzytelnionej odpowiedzi APDU określonej w przypadku 2/ przypadku 4
▼B
10.5.3 Przerwanie sesji bezpiecznej wymiany komunikatów
CSM_192 Przyrząd rejestrujący przerywa trwającą sesję bezpiecznej
wymiany komunikatów tylko i wyłącznie wówczas, gdy zaist­
nieje jeden z poniższych warunków:
— przyrząd otrzyma odkrytą odpowiedź APDU;
— przyrząd wykryje błąd bezpiecznej wymiany komuni­
katów w odpowiedzi APDU:
— brak oczekiwanego obiektu danych bezpiecznej
wymiany komunikatów, nieprawidłową kolejność
obiektów danych lub uwzględnienie nieznanego
obiektu danych,
— nieprawidłowy obiekt danych bezpiecznej wymiany
komunikatów, np. nieprawidłowa wartość MAC,
nieprawidłową strukturę TLV lub wskaźnik wypeł­
nienia w znaczniku „87” nie jest równy „01”,
— karta wyśle bajt stanu wskazujący na wykrycie błędu
bezpiecznej wymiany komunikatów (zob. CSM_194);
— osiągnięty zostanie limit dotyczący liczby poleceń i powią­
zanych odpowiedzi w ramach bieżącej sesji. Dla danego
VU limit ten określa producent, uwzględniając wymogi
bezpieczeństwa dotyczące używanego sprzętu, przy
czym maksymalna liczba poleceń i powiązanych odpo­
wiedzi w ramach bezpiecznej wymiany komunikatów
wynosi 240 w każdej sesji.
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 487
CSM_193 Karta do tachografu przerywa trwającą sesję bezpiecznej
wymiany komunikatów tylko i wyłącznie wówczas, gdy zaist­
nieje jeden z poniższych warunków:
— karta otrzyma odkryte polecenie APDU,
— karta wykryje błąd bezpiecznej wymiany komunikatów
w poleceniu APDU:
— brak oczekiwanego obiektu danych bezpiecznej
wymiany komunikatów, nieprawidłową kolejność
obiektów danych lub uwzględnienie nieznanego
obiektu danych,
— nieprawidłowy obiekt danych bezpiecznej wymiany
komunikatów, np. nieprawidłowa wartość MAC lub
nieprawidłowa struktura TLV;
— karta straci zasilanie lub zostanie zresetowana;
— VU rozpocznie proces uwierzytelniania VU;
— osiągnięty zostanie limit dotyczący liczby poleceń i powią­
zanych odpowiedzi w ramach bieżącej sesji. W odniesieniu
do danej karty limit ten określa producent, uwzględniając
wymogi bezpieczeństwa dotyczące używanego sprzętu,
przy czym maksymalna liczba poleceń i powiązanych
odpowiedzi w ramach bezpiecznej wymiany komunikatów
wynosi 240 w każdej sesji.
▼B
CSM_194 W odniesieniu do obsługi błędów w ramach bezpiecznej
wymiany komunikatów przez kartę do tachografu:
— jeżeli w poleceniu APDU wystąpi brak niektórych ocze­
kiwanych obiektów danych bezpiecznej wymiany komu­
nikatów, kolejność obiektów danych jest nieprawidłowa
lub zawarto nieznane obiekty danych, karta do tachografu
wysyła odpowiedź zawierającą bajty stanu „69 87”;
— jeżeli w poleceniu APDU obiekt danych bezpiecznej
wymiany komunikatów jest nieprawidłowy, karta do
tachografu wysyła odpowiedź zawierającą bajty stanu
„69 88”.
W takim przypadku bajty stanu są odsyłane bez zastosowania
bezpiecznej wymiany komunikatów.
CSM_195 Jeżeli sesja bezpiecznej wymiany komunikatów między VU
a kartą do tachografu zostanie przerwana, VU i karta do
tachografu:
— w bezpieczny sposób niszczą przechowywane klucze
sesji;
— natychmiast ustanawiają nową sesję bezpiecznej wymiany
komunikatów, jak opisano w sekcjach 10.2 – 10.5.
CSM_196 Jeżeli z jakiejkolwiek przyczyny VU zdecyduje się 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 — 21.08.2023 — 003.002 — 488
11. POWIĄZANIE, WZAJEMNE UWIERZYTELNIANIE I BEZPIECZNA
WYMIANA KOMUNIKATÓW MIĘDZY VU A URZĄDZENIEM
ZEWNĘTRZNYM GNSS
11.1. Uwagi ogólne
CSM_197 Urządzenie GNSS wykorzystywane przez VU do ustalania
jego położenia może być wewnętrzne (tj. wbudowane
w obudowę VU i nieodłączalne) bądź też może stanowić
moduł zewnętrzny. W pierwszym przypadku standaryzacja
łączności wewnętrznej między urządzeniem GNSS a VU nie
jest potrzebna, a wymogi określone w tym rozdziale nie mają
zastosowania. W drugim przypadku łączność między VU
a urządzeniem zewnętrznym GNSS wymaga standaryzacji
i ochrony, jak opisano w tym rozdziale.
CSM_198 Bezpieczna łączność między przyrządem rejestrującym a urzą­
dzeniem zewnętrznym GNSS odbywa się na takiej samej
zasadzie jak bezpieczna łączność między przyrządem rejes­
trującym a kartą do tachografu, przy czym urządzenie
zewnętrzne GNSS przyjmuje rolę karty. Urządzenie
zewnętrzne GNSS musi spełniać wszystkie wymogi, o których
mowa w rozdziale 10 w odniesieniu do kart do tachografu,
z uwzględnieniem odstępstw, wyjaśnień i uzupełnień przed­
stawionych w tym rozdziale. W szczególności procesy
wzajemnej weryfikacji łańcucha certyfikatów, uwierzytel­
niania VU i uwierzytelniania chipu przeprowadza się
w sposób opisany w sekcjach 11.3 i 11.4.
CSM_199 Łączność między przyrządem rejestrującym a EGF różni się
od łączności między przyrządem rejestrującym a kartą pod
takim względem, że przyrząd rejestrujący i EGF muszą zostać
powiązane w warsztacie, zanim będą mogły dokonywać
wymiany danych opartych na GNSS w trakcie normalnej
pracy. Proces ustanawiania powiązania opisano w sekcji 11.2.
CSM_200 W przypadku łączności między przyrządem rejestrującym
a EGF stosuje się polecenia i odpowiedzi APDU na
podstawie [ISO 7816-4] i [ISO 7816-8]. Dokładną składnię
tych poleceń i odpowiedzi APDU określono w dodatku 2 do
niniejszego załącznika.
11.2. Ustanowienie powiązania między VU a urządzeniem zewnętrznym
GNSS
CSM_201 Powiązanie między przyrządem rejestrującym a EGF w pojeź­
dzie ustanawia warsztat. W trakcie normalnej pracy tylko
powiązany przyrząd rejestrujący i EGF mogą nawiązywać
łączność.
CSM_202 Ustanowienie powiązania między przyrządem rejestrującym
a EGF jest możliwe, wyłącznie gdy przyrząd rejestrujący
znajduje się w trybie kalibracyjnym. Proces ustanawiania
powiązania inicjuje przyrząd rejestrujący.
CSM_203 Warsztat może w dowolnym momencie ponownie połączyć
przyrząd rejestrujący z innym lub z tym samym EGF.
W trakcie ustanawiania ponownego połączenia VU w sposób
bezpieczny niszczy istniejący certyfikat EGF_MA w jego
pamięci i przechowuje certyfikat EGF_MA EGF, z którym
jest powiązany.
CSM_204 Warsztat może w dowolnym momencie ponownie powiązać
urządzenie zewnętrzne GNSS z innym lub tym samym VU.
W trakcie ustanawiania ponownego powiązania EGF w sposób
bezpieczny niszczy istniejący certyfikat VU_MA w jego
pamięci i przechowuje certyfikat VU_MA VU, z którym
jest wiązany.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 489
11.3. Wzajemna weryfikacja łańcucha certyfikatów
11.3.1 Uwagi ogólne
CSM_205 Wzajemna weryfikacja łańcucha certyfikatów między VU
a EGF odbywa się wyłącznie w trakcie procesu ustanawiania
przez warsztat powiązania między VU a EGF. W czasie
normalnej pracy powiązanego VU i EGF nie przeprowadza
się weryfikacji certyfikatów. Zamiast tego VU i EGF ufają
certyfikatom, które zapisały podczas ustanawiania powią­
zania, po sprawdzeniu czasowej ważności tych certyfikatów.
VU i EGF nie mogą ufać żadnym innym certyfikatom doty­
czącym ochrony łączności między VU a EGF w czasie
normalnej pracy.
11.3.2 Podczas ustanawiania powiązania między VU a EGF
CSM_206 Podczas ustanawiania powiązania z EGF przyrząd rejestrujący
używa protokołu przedstawionego na rys. 4 (sekcja 10.2.1)
w celu weryfikacji łańcucha certyfikatów urządzenia
zewnętrznego GNSS.
Uwagi do rys. 4 w tym kontekście:
— kontrola łączności nie jest objęta zakresem niniejszego
dodatku. EGF nie jest jednak inteligentną kartą, a zatem
VU prawdopodobnie nie wyśle komunikatu „Reset”
w celu nawiązania łączności i nie otrzyma odpowiedzi
na ponowne inicjowanie (ATR);
— certyfikaty i klucze publiczne karty wskazane na rysunku
interpretuje się jako certyfikaty i klucze publiczne EGF na
potrzeby wzajemnego uwierzytelniania. W sekcji 9.1.6
oznaczono je jako EGF_MA;
— certyfikaty i klucze publiczne Card.CA wskazane na
rysunku interpretuje się jako certyfikaty i klucze publiczne
MSCA na potrzeby podpisywania certyfikatów EGF.
W sekcji 9.1.3 oznaczono je jako MSCA_VU-EGF;
— certyfikat Card.CA.EUR przedstawiony na rysunku inter­
pretuje się jako europejski certyfikat główny wskazany
w CAR certyfikatu MSCA_VU-EGF;
— certyfikat Card.Link wskazany na rysunku interpretuje się
jako certyfikat łączący EGF, o ile istnieje. Jak określono
w sekcji 9.1.2, jest to certyfikat łączący dla nowej pary
europejskich kluczy głównych wygenerowanej przez
ERCA i podpisanej za pomocą poprzedniego europej­
skiego klucza prywatnego;
— certyfikat Card.Link.EUR jest europejskim certyfikatem
głównym wskazanym w CAR certyfikatu Card.Link.
— zamiast VU odczyta
z pliku elementarnego
ICC;
— zamiast AID tachografu VU wybiera AID EGF;
— komunikat „Ignore Card” interpretuje się jako komunikat
„Ignore EGF”.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 490
CSM_207 Po zweryfikowaniu certyfikatu EGF_MA przyrząd rejestru­
jący zapisuje ten certyfikat do wykorzystania w czasie
normalnej pracy; zob. sekcja 11.3.3.
CSM_208 ►M1 Podczas ustanawiania powiązania z VU urządzenie
zewnętrzne GNSS używa protokołu przedstawionego na rys.
5 (sekcja 10.2.2) w celu weryfikacji łańcucha certyfikatów
VU. ◄
Uwagi do rys. 5 w tym kontekście:
— VU generuje nową parę kluczy efemerycznych przy
użyciu parametrów domeny określonych w certyfikacie
EGF;
— certyfikaty i klucze publiczne VU wskazane na rysunku są
certyfikatami i kluczami, których używa się do wzajem­
nego uwierzytelnienia. W sekcji 9.1.4 oznaczono je jako
VU_MA;
— certyfikaty i klucze publiczne VU.CA wskazane na
rysunku są certyfikatami i kluczami używanymi do podpi­
sywania certyfikatów VU i urządzenia zewnętrznego
GNSS. W sekcji 9.1.3 oznaczono je jako MSCA_VU-
EGF;
— certyfikat VU.CA.EUR przedstawiony na rysunku jest
europejskim certyfikatem głównym wskazanym w CAR
certyfikatu VU.CA;
— certyfikat VU.Link wskazany na rysunku jest certyfikatem
łączącym VU, o ile istnieje. Jak określono w sekcji 9.1.2,
jest to certyfikat łączący dla nowej pary europejskich
kluczy głównych wygenerowanej przez ERCA i podpi­
sanej za pomocą poprzedniego europejskiego klucza
prywatnego;
— certyfikat VU.Link.EUR jest europejskim certyfikatem
głównym wskazanym w CAR certyfikatu VU.Link.
CSM_209 W odróżnieniu od wymogu CSM_167 EGF wykorzystuje
czas GNSS do celów weryfikacji czasowej ważności każdego
przedstawionego certyfikatu.
▼M1
CSM_210 Po zweryfikowaniu certyfikatu VU_MA urządzenie
zewnętrzne GNSS przechowuje ten certyfikat do wykorzys­
tania w czasie normalnej pracy; zob. sekcja 11.3.3.
▼B
11.3.3 W czasie normalnej pracy
CSM_211 ►M1 W czasie normalnej pracy przyrząd rejestrujący i EGF
używają protokołu wskazanego na rys. 11 w celu weryfikacji
czasowej ważności przechowywanych certyfikatu EGF_MA
oraz do celów ustalenia klucza publicznego VU_MA na
potrzeby późniejszego uwierzytelnienia VU. W czasie
normalnej pracy nie odbywa się dalsza wzajemna weryfikacja
łańcuchów certyfikatów. ◄
Należy zauważyć, że rys. 11 zasadniczo zawiera pierwsze
kroki przedstawione na rys. 4 i rys. 5. Ponownie należy
zauważyć, że ponieważ EGF nie jest inteligentną kartą, VU
prawdopodobnie nie wyśle komunikatu „Reset” w celu
nawiązania łączności i nie otrzyma ATR. W żadnym przy­
padku kwestia ta nie jest objęta zakresem niniejszego
dodatku.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 491
Rys. 11
Wzajemna weryfikacja czasowej ważności certyfikatu w czasie normalnej pracy VU–EGF
CSM_212 Jak przedstawiono na rys. 11, przyrząd rejestrujący 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 komuni­
katów między VU a EGF przyrząd rejestrujący natychmiast
ustanawia nową sesję bezpiecznej wymiany komunikatów, jak
opisano w sekcjach 11.3.3 i 11.4.
12. PAROWANIE VU Z CZUJNIKIEM RUCHU I ŁĄCZNOŚĆ MIĘDZY
TYMI URZĄDZENIAMI
12.1. Uwagi ogólne
CSM_216 Łączność pomiędzy przyrządem rejestrującym a czujnikiem
ruchu odbywa się za pomocą protokołu interfejsu określonego
w [ISO 16844-3] w czasie parowania i normalnej pracy,
z uwzględnieniem zmian opisanych w tym rozdziale oraz
w sekcji 9.2.1.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 492
Uwaga: zakłada się, że czytelnicy tego rozdziału są zaznajo­
mieni
z treścią normy [ISO 16844-3].
12.2. Parowanie VU z czujnikiem ruchu przy użyciu różnych generacji
kluczy
Jak wyjaśniono w sekcji 9.2.1, klucz główny czujnika ruchu i 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 przeka­
zuje z powrotem pasującą zaszyfrowaną wersję klucza
parowania; tj. zaszyfrowany numer stworzony przy zasto­
sowaniu klucza K M tej samej generacji.
6. VU odszyfrowuje klucz parowania za pomocą klucza K M ,
generuje klucz sesji K S, szyfruje go za pomocą klucza
parowania i wysyła uzyskany rezultat do czujnika ruchu.
Czujnik ruchu odszyfrowuje klucz K S .
7. VU gromadzi informacje o parowaniu, jak określono
w [ISO 16844-3], szyfruje te informacje za pomocą klucza
parowania i wysyła uzyskany rezultat do czujnika ruchu.
Czujnik ruchu odszyfrowuje informacje o parowaniu.
8. Czujnik ruchu szyfruje otrzymane informacje o parowaniu
za pomocą otrzymanego klucza K S i przesyła te informacje
z powrotem do VU. VU sprawdza, czy informacje o paro­
waniu są tymi samymi informacjami, które VU wysłał do
czujnika ruchu w poprzednim kroku. Jeżeli tak, oznacza
to, że czujnik ruchu użył tego samego klucza K S co VU
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 493
i zgodnie z krokiem 5 wysłał swój klucz parowania
zaszyfrowany za pomocą klucza K M prawidłowej gene­
racji. Czujnik ruchu jest zatem uwierzytelniony.
Należy zauważyć, że kroki 2 i 5 różnią się od standardowego
procesu określonego w [ISO 16844-3]; pozostałe kroki są
krokami standardowymi.
Przykład: załóżmy, że proces parowania odbywa się w pierw­
szym roku ważności certyfikatu ERCA (3); zob. rys. 2
w sekcji 9.2.1.2. Ponadto
— załóżmy, że czujnik ruchu wydano w ostatnim roku
ważności certyfikatu ERCA (1). Będzie zatem zawierał
następujące klucze i dane:
— N s [1]: swój numer seryjny zaszyfrowany kluczem K ID
1. generacji;
— N s [2]: swój numer seryjny zaszyfrowany kluczem K ID
2. generacji;
— N s [3]: swój numer seryjny zaszyfrowany kluczem K ID
3. generacji;
— K P [1]: swój klucz parowania 1. generacji ( 1 ), zaszyf­
rowany kluczem K M 1. generacji;
— K P [2]: swój klucz parowania 2. generacji, zaszyfro­
wany kluczem K M 2. generacji;
— K P [3]: swój klucz parowania 3. generacji, zaszyfro­
wany kluczem K M 3. generacji;
— załóżmy, że kartę warsztatową wydano w pierwszym roku
ważności certyfikatu ERCA (3). Będzie zatem zawierała
klucz K M-WC 2. i 3. generacji;
— załóżmy, że VU jest VU 2. generacji zawierającym klucz
K M-VU 2. generacji.
W takim przypadku w krokach 2–5 zajdą następujące
procesy:
— krok 2: VU odczytuje klucze K M-WC 2. i 3. generacji
z karty warsztatowej i sprawdza ich numery wersji;
— krok 3: VU łączy klucz K M-WC 2. generacji ze swoim
kluczem K M-VU w celu obliczenia kluczy K M i K ID ;
— krok 4: VU szyfruje numer seryjny otrzymany od czujnika
ruchu za pomocą klucza K ID ;
— krok 5: czujnik ruchu porównuje otrzymane dane
z numerem N s [1] i nie znajduje odpowiedniego numeru.
Następnie porównuje dane z numerem N s [2] i znajduje
odpowiedni numer. Ustala, że VU jest VU 2. generacji,
w związku z czym odsyła klucz K P [2].
▼B
( 1 ) Należy zauważyć, że klucze parowania 1., 2. i 3. generacji 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 — 21.08.2023 — 003.002 — 494
12.3. Parowanie VU z czujnikiem ruchu i łączność między tymi urządze­
niami z wykorzystaniem AES
CSM_218 Zgodnie z tabelą 3 w sekcji 9.2.1 wszystkie klucze 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 komunikatu
musi stanowić wielokrotność 16 bajtów, w porównaniu z 8
bajtami w przypadku TDES. Ponadto niektóre takie komuni­
katy będą wykorzystywane do transportu kluczy AES,
których długość może wynosić 128, 192 lub 256 bitów.
W związku z tym liczbę bajtów danych zgodnie z instrukcją
w tabeli 5 normy [ISO 16844-3] należy zmienić w sposób
określony w tabeli 6:
▼M1
Tabela 6
Liczba bajtów danych zwykłego tekstu i danych zaszyfrowanych zgodnie z instrukcją określoną w [ISO 16844-3]
Instrukcja
Żądanie /
odpowiedź
Opis danych
Liczba bajtów
danych zwykłego
tekstu zgodnie z
[ISO 16844-3]
Liczba bajtów
danych zwykłego
tekstu przy użyciu
kluczy AES
Liczba bajtów zaszyfrowanych
danych przy użyciu kluczy
AES o długości w bitach
128 192 256
10 żądanie Dane uwierzytel­
niania + numer pliku
8 8 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 paro­
waniu
24 24 32 32 32
50 odpowiedź Informacje o paro­
waniu
24 24 32 32 32
70 żądanie Dane uwierzytel­
niania
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ą gromadzone zgodnie
z wymogami określonymi w sekcji 7.6.10 normy [ISO 16844-
3], z tym że zamiast algorytmu TDES należy stosować algo­
rytm AES w systemie szyfrowania danych dotyczących paro­
wania, co skutkuje uzyskaniem dwóch szyfrów AES i przyję­
ciem wypełnienia zgodnie z CSM_220 w celu dopasowania
do rozmiaru bloku AES. Klucz K' p , używany do takiego
szyfrowania, generuje się w następujący sposób:
— jeżeli długość klucza parowania K P wynosi 16 bajtów: K' p
= K P XOR (N s ||N s ),
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 495
— jeżeli długość klucza parowania K P wynosi 24 bajty: K' p
= K P XOR (N s ||N s ||N s ),
— jeżeli długość klucza parowania K P wynosi 32 bajty: K' p
= K P XOR (N s ||N s ||N s ||N s ),
gdzie N s jest 8-bajtowym numerem seryjnym czujnika ruchu.
CSM_220 Jeżeli długość danych zwykłego tekstu (przy użyciu 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
dodatku), co umożliwia parowanie tego czujnika ruchu
z VU pierwszej generacji. W takim przypadku proces paro­
wania VU pierwszej generacji z czujnikiem ruchu drugiej
generacji odbywa się zgodnie z opisem przedstawionym
w części A niniejszego dodatku oraz w normie [ISO 16844-
3]. Na potrzeby procesu parowania można użyć karty warsz­
tatowej pierwszej lub drugiej generacji.
Uwagi
— Nie jest możliwe sparowanie VU drugiej generacji z czuj­
nikiem ruchu pierwszej generacji.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 496
— Nie jest możliwe użycie karty warsztatowej pierwszej
generacji do celów powiązania VU drugiej generacji
z czujnikiem ruchu.
13. BEZPIECZEŃSTWO ŁĄCZNOŚCI NA ODLEGŁOŚĆ W RAMACH
DSRC
13.1. Uwagi ogólne
Jak określono w dodatku 14, VU regularnie generuje dane dotyczące
zdalnego monitorowania tachografu (RTM) i wysyła te dane do
(wewnętrznego lub zewnętrznego) urządzenia do łączności na
odległość (RCF). Urządzenie do łączności na odległość odpowiada za
wysłanie tych danych za pośrednictwem interfejsu DSRC opisanego
w dodatku 14 do zdalnego interrogatora. W dodatku 1 określono, że
dane dotyczące zdalnego monitorowania tachografu stanowią połą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 wszystkich
wcześniejszych bajtów w danych dotyczących
zdalnego monitorowania tachografu.
CSM_225 3-bajtowy licznik w danych zabezpieczających DSRC ma
format, w którym najbardziej znaczący bit znajduje się na
początku. Za pierwszym razem, gdy VU oblicza zbiór danych
dotyczących zdalnego monitorowania tachografu po rozpo­
częciu jego produkcji, ustawia wartość licznika na 0. VU
zwiększa wartość licznika o 1 za każdym razem, zanim
obliczy kolejny zbiór danych dotyczących zdalnego monito­
rowania tachografu.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 497
13.2. Szyfrowanie ładunku tachografu i generowanie MAC
CSM_226 Po otrzymaniu elementu danych w formie zwykłego tekstu
zawierającego typ danych , jak
opisano w dodatku 14, VU szyfruje te dane zgodnie z rys.
12: służącego do szyfrowania klucza DSRC przyrządu rejes­
trującego K_VU DSRC _ENC (zob. sekcja9.2.2) używa się wraz
z AES w trybie wiązania bloków zaszyfrowanych (CBC), jak
określono w [ISO 10116], z naprzemiennym parametrem m =
1. Wektor inicjujący ma wartość IV = aktualna data i godzina
|| „00 00 00 00 00 00 00 00 00” || licznik, przy czym
wartości aktualnej daty i godzina oraz licznika określono
w CSM_224. Dane, które mają zostać zaszyfrowane,
wypełnia się za pomocą metody 2 określonej w [ISO 9797-1].
CSM_227 VU oblicza MAC w danych zabezpieczających DSRC
zgodnie z rys. 12: MAC oblicza się na podstawie wszystkich
wcześniejszych bajtów zawartych w danych dotyczących
zdalnego monitorowania tachografu, do wartości numeru
wersji klucza głównego DSRC włącznie oraz z uwzględnie­
niem znaczników i długości obiektów danych. VU używa
swojego klucza DSRC do zapewnienia autentyczności
K_VU DSRC _MAC (zob. sekcja 9.2.2) z algorytmem AES
w trybie CMAC, jak określono w [SP 800-38B]. Długość
MAC jest powiązana z długością kluczy DSRC specyficznych
dla VU, jak określono w CSM_50.
Rys. 12
Szyfrowanie ładunku tachografu i generowanie MAC
13.3. Weryfikacja i odszyfrowywanie ładunku tachografu
CSM_228 Gdy zdalny interrogator otrzymuje od VU dane dotyczące
zdalnego monitorowania tachografu, wysyła wszystkie dane
dotyczące zdalnego monitorowania tachografu do karty
kontrolnej w polu danych polecenia PROCESS DSRC
MESSAGE, jak opisano w dodatku 2. Następnie:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 498
1. karta kontrolna sprawdza numer wersji klucza głównego
DSRC w danych zabezpieczających DSRC. Jeżeli karta
kontrolna nie rozpozna wskazanego klucza głównego
DSRC, zwraca komunikat o błędzie określony w dodatku
2 i przerywa proces;
▼M1
2. karta kontrolna stosuje wskazany klucz główny DSRC
w połączeniu z numerem seryjnym VU lub identyfika­
torem wniosku o certyfikat zawartym w danych zabezpie­
czających DSRC w celu wyprowadzenia specyficznych dla
VU kluczy DSRC K_VU DSRC _ENC i K_VU DSRC _MAC,
jak określono w CSM_124;
▼B
3. karta kontrolna używa klucza K_VU DSRC _MAC do wery­
fikacji MAC zawartego w danych zabezpieczających
DSRC, jak określono w CSM_227. Jeżeli MAC jest
nieprawidłowy, karta kontrolna zwraca komunikat o błędzie
określony w dodatku 2 i przerywa proces;
4. karta kontrolna wykorzystuje klucz K_VU DSRC _ENC do
celów odszyfrowania zaszyfrowanego ładunku tachografu,
jak określono w CSM_226. Karta kontrolna usuwa wypeł­
nienie i odsyła odszyfrowane dane ładunku tachografu do
zdalnego interrogatora.
CSM_229 W celu zapobieżenia atakom przez powtórzenie zdalny 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 zdalnego
interrogatora.
Uwagi
— W tym celu konieczne jest, aby zdalny interrogator
posiadał dokładne i wiarygodne źródło czasu.
— Ponieważ dodatek 14 zawiera wymóg, aby VU obliczał
nowy zbiór danych dotyczących zdalnego monitorowania
tachografu co 60 sekund, a zegar VU może odbiegać od
czasu rzeczywistego o 1 minutę, dolna granica w odnie­
sieniu do aktualności danych dotyczących zdalnego moni­
torowania tachografu wynosi 2 minuty. Faktyczna aktual­
ność, jaka jest wymagana, zależy również od dokładności
zegara zdalnego interrogatora.
CSM_230 Gdy warsztat weryfikuje prawidłowość działania funkcji
DSRC VU, wysyła wszystkie otrzymane od VU dane doty­
czące zdalnego monitorowania tachografu do karty warsz­
tatowej w polu danych polecenia PROCESS DSRC
MESSAGE, jak opisano w dodatku 2. Karta warsztatowa
przeprowadza wszystkie kontrole i działania określone
w wymogu CSM_228.
14. PODPISYWANIE POBIERANYCH DANYCH I SPRAWDZANIE
PODPISÓW
14.1. Uwagi ogólne
CSM_231 Inteligentne urządzenie dedykowane (IDE) przechowuje 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 — 21.08.2023 — 003.002 — 499
— w przypadku pobierania przez VU:
— certyfikat VU_Sign;
— certyfikat MSCA_VU-EGF zawierający klucz
publiczny służący do weryfikacji certyfikatu
VU_Sign;
— w przypadku pobierania przez kartę:
— certyfikat Card_Sign;
— certyfikat MSCA_Card zawierający klucz publiczny
służący do weryfikacji certyfikatu Card_Sign.
CSM_232 IDE posiada również:
— w przypadku gdy używa karty kontrolnej do weryfikacji
podpisu, jak wskazano na rys. 13: certyfikat łączący
najnowszy certyfikat EUR z certyfikatem EUR, którego
okres ważności wygasa bezpośrednio przed okresem
ważności tego najnowszego certyfikatu EUR, o ile
istnieje;
— w przypadku gdy samodzielnie weryfikuje podpis:
wszystkie ważne europejskie certyfikaty główne.
Uwaga: metody stosowanej przez IDE do pobierania tych
certyfikatów nie określono w niniejszym dodatku.
14.2. Generowanie podpisu
CSM_233 Algorytmem podpisywania służącym do tworzenia podpisów
cyfrowych w odniesieniu do pobieranych danych jest
ECDSA, jak określono w [DSS], używający algorytmu skrótu
powiązanego z wielkością klucza VU lub karty, jak określono
w CSM_50. Format podpisu jest odkryty, jak określono
w [TR-03111].
14.3. Weryfikacja podpisu
CSM_234 ►M1 IDE może samodzielnie przeprowadzać weryfikację
podpisu złożonego w odniesieniu do pobranych danych lub
może do tego celu używać karty kontrolnej. W przypadku
używania karty kontrolnej weryfikacja podpisów odbywa się
zgodnie ze schematem przedstawionym na rysunku 13.
W celu zweryfikowania czasowej ważności certyfikatu przed­
stawionego przez IDE karta kontrolna używa swojego
wewnętrznego czasu bieżącego, jak określono w pozycji
CSM_167. Karta kontrolna aktualizuje swój czas bieżący,
jeżeli data wejścia w życie autentycznego certyfikatu będą­
cego „wiarygodnym źródłem czasu” jest późniejsza niż czas
bieżący określony na karcie. Za wiarygodne źródło czasu
karta uznaje wyłącznie następujące certyfikaty:
— certyfikaty łączące ERCA drugiej generacji,
— certyfikaty MSCA drugiej generacji,
— certyfikaty VU_Sign lub Card_Sign drugiej generacji
wydane przez to samo państwo, które wydało certyfikat
własny karty kontrolnej.
W przypadku gdy urządzenie samodzielnie przeprowadza
weryfikację podpisy, IDE weryfikuje autentyczność i ważność
wszystkich certyfikatów w łańcuchu certyfikatów w pliku
danych oraz weryfikuje podpis złożony w stosunku do
danych według schematu podpisu określonego w [DSS].
W obu przypadkach dla każdego certyfikatu odczytywanego
z pliku danych konieczne jest sprawdzenie prawidłowości
pola Upoważnienie Posiadacza Certyfikatu (CHA):
— Pole CHA certyfikatu EQT wskazuje certyfikat VU lub
karty (odpowiednio do przypadku) na potrzeby podpisu
(zob. dodatek 1, typ danych EquipmentType).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 500
— CHA certyfikatu EQT.CA musi wskazywać MSCA.
— CHA certyfikatu EQT.Link musi wskazywać ERCA. ◄
Uwagi do rys. 13:
— urządzenie, które podpisuje dane przeznaczone do anali­
zowania, oznaczono EQT.
— certyfikaty i klucze publiczne ETQ wskazane na rysunku
są certyfikatami i kluczami używanymi do podpisywania,
tj. VU_Sign lub Card_Sign;
— certyfikaty EQT.CA i klucze publiczne wskazane na
rysunku są certyfikatami i kluczami używanymi do podpi­
sywania w stosownych przypadkach certyfikatów VU lub
kart;
— certyfikat EQT.CA.EUR wskazany na rysunku jest euro­
pejskim certyfikatem głównym wskazanym w CAR certy­
fikatu EQT.CA;
— certyfikat EQT.Link wskazany na rysunku jest certyfi­
katem łączącym EQT, o ile istnieje. Jak określono w sekcji
9.1.2, jest to certyfikat łączący dla nowej pary europej­
skich kluczy głównych wygenerowanej przez ERCA
i podpisanej za pomocą poprzedniego europejskiego
klucza prywatnego;
— certyfikat EQT.Link.EUR jest europejskim certyfikatem
głównym wskazanym w CAR certyfikatu EQT.Link.
CSM_235 Do celów obliczania skrótu M wysyłanego do karty kontro­
lnej w poleceniu PSO:Hash IDE stosuje algorytm skrótu
powiązany z wielkością klucza VU lub karty, z których
dane są pobierane, jak określono w CSM_50.
CSM_236 Do celów zweryfikowania podpisu EQT karta kontrolna
wykonuje czynności według schematu podpisu określonego
w [DSS].
Uwaga: w niniejszym dokumencie nie określono żadnego
działania, jakie należy podjąć, jeżeli podpisu złożonego
w odniesieniu do pobranego pliku danych nie można zwery­
fikować lub jeżeli weryfikacja się nie powiedzie.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 501
Rysunek 13
Protokół weryfikacji podpisu złożonego w odniesieniu do pobranego pliku danych
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 502
Dodatek 12
OKREŚLANIE POŁOŻENIA Z WYKORZYSTANIEM GLOBALNEGO
SYSTEMU NAWIGACJI SATELITARNEJ (GNSS)
SPIS TREŚCI
1. WPROWADZENIE
1.1. Zakres stosowania
▼M3
1.1.1 Odniesienia
▼B
1.2. Akronimy i skróty
▼M3
2. PODSTAWOWA CHARAKTERYSTYKA ODBIORNIKA GNSS
3. KOMUNIKATY PODAWANE PRZEZ ODBIORNIK GNSS
▼B
4. PRZYRZĄD REJESTRUJĄCY Z URZĄDZENIEM ZEWNĘTRZNYM
GNSS
4.1. Konfiguracja
4.1.1 Główne elementy składowe i interfejsy
4.1.2 Stan urządzenia zewnętrznego GNSS na koniec procesu 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
▼M3
4.2.4 Struktura polecenia WriteRecord
4.2.5. Inne polecenia
▼B
4.3. Powiązanie, wzajemne uwierzytelnienie i uzgodnienie klucza sesji
między urządzeniem zewnętrznym GNSS a przyrządem rejestrującym
4.4. Obsługa błędów
4.4.1 Błąd komunikacji z urządzeniem zewnętrznym GNSS
4.4.2 Naruszenie integralności fizycznej urządzenia zewnę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
▼M3
5.2. Transfer informacji z odbiornika GNSS do VU
__________
5.3. Transfer informacji z VU do odbiornika GNSS
5.4. Obsługa błędów
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 503
5.4.1. Brak informacji o pozycji z odbiornika GNSS
6. PRZETWARZANIE I REJESTRACJA DANYCH O POZYCJI PRZEZ
VU
7. KONFLIKT CZASOWY GNSS
8. KONFLIKT RUCHU POJAZDU
1. WPROWADZENIE
Niniejszy dodatek zawiera wymogi techniczne dotyczące odbiornika
GNSS oraz danych GNSS wykorzystywanych przez przyrząd rejestru­
jący, z uwzględnieniem protokołów, które należy wdrożyć w celu zapew­
nienia bezpiecznego i prawidłowego przesyłania danych z informacjami
o pozycji.
1.1. Zakres
GNS_1 Przyrząd rejestrujący musi gromadzić dane dotyczące lokalizacji
z co najmniej jednej sieci satelitarnej GNSS.
Przyrząd rejestrujący może posiadać urządzenie zewnętrzne
GNSS lub nie, jak przedstawiono na rys. 1:
1.1.1 Odniesienia
W tej części dodatku używa się następujących odniesień:
NMEA NMEA (National Marine Electronics Association) [Narodowe
Stowarzyszenie Elektroniki Morskiej] 0183 Interface Standard
[standard dla interfejsów], V4.11
▼B
Rys. 1
Różne konfiguracje odbiornika GNSS.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 504
1.2. Akronimy i skróty
W niniejszym dodatku używa się następujących skrótów:
DOP Rozmycie dokładności
EGF Plik elementarny urządzenia GNSS
GNSS Globalny system nawigacji satelitarnej
EGNOS Europejski system wspomagania satelitarnego
GSA Rozmycie dokładności GPS i aktywne satelity
HDOP Poziome rozmycie dokładności
ICD Dokument kontroli interfejsu
NMEA National Marine Electronics Association
▼M3
OSNMA Galileo Open Service Navigation Message Authentication
[uwierzytelnianie komunikatów nawigacyjnych usługi
otwartej Galileo]
▼B
PDOP Trójwymiarowe rozmycie dokładności
RMC Zalecane minimalne dane GNSS
▼M3
RTC Real Time Clock [zegar czasu rzeczywistego]
▼B
SIS Sygnał w przestrzeni
VDOP Pionowe rozmycie dokładności
VU Przyrząd rejestrujący
▼M3
2. PODSTAWOWA CHARAKTERYSTYKA ODBIORNIKA GNSS
▼B
Niezależnie od konfiguracji tachografu inteligentnego z urzą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 rozpo­
rządzeniu Parlamentu Europejskiego i Rady (UE) nr 1285/2013 ( 1 ).
System ustanowiony w ramach programu Galileo jest niezależnym świa­
towym systemem nawigacji satelitarnej, zaś system ustanowiony
w ramach programu EGNOS jest regionalnym systemem nawigacji sate­
litarnej poprawiającym jakość sygnału globalnego systemu
pozycjonowania.
GNS_2 Producenci zapewniają, aby odbiorniki GNSS instalowane
w tachografach inteligentnych były kompatybilne z usługami
w zakresie lokalizacji zapewnianymi przez systemy Galileo
i EGNOS. Ponadto producenci mogą również wybrać kompa­
tybilność z innymi systemami nawigacji satelitarnej.
▼B
( 1 ) Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 1285/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 — 21.08.2023 — 003.002 — 505
GNS_3 Odbiornik GNSS musi być w stanie obsługiwać uwierzytel­
nianie komunikatów nawigacyjnych w ramach usługi otwartej
Galileo (OSNMA).
GNS_3a Odbiornik GNSS przeprowadza szereg kontroli spójności
w celu sprawdzenia, czy pomiary obliczane przez odbiornik
GNSS na podstawie danych OSNMA doprowadziły do uzys­
kania prawidłowych informacji na temat pozycji, prędkości
i danych pojazdu, a zatem nie były przedmiotem żadnego
ataku zewnętrznego, który wywarłby nie na wpływ, takiego
jak meaconing. Przedmiotowe kontrole spójności obejmują na
przykład:
— wykrywanie nietypowych emisji mocy za pomocą połączo­
nego monitorowania automatycznej kontroli wzmocnienia
(AGC) i stosunku gęstości nośnej do szumu (C/N0),
— spójności pomiaru pseudozakresów oraz spójności pomiaru
Dopplera w czasie, w tym wykrywanie nagłych skoków
pomiarowych,
— techniki niezależnego monitorowania spójności odbiornika
(RAIM), w tym wykrywanie niespójnych pomiarów z szaco­
waną pozycją,
— kontrole pozycji i prędkości, w tym nietypowych wskazań
pozycji i prędkości, nagłych skoków i zachowań niezgod­
nych z dynamiką pojazdu,
— spójność czasu i częstotliwości, w tym skoki zegarowe
i dryfty, które nie są spójne z charakterystyką zegara
odbiornika.
GNS_3b Komisja Europejska opracowuje i zatwierdza następujące
dokumenty:
— dokument kontroli interfejsu sygnału w przestrzeni (SIS
ICD), określający szczegółowo informacje OSNMA prze­
kazywane w ramach sygnału Galileo;
— wytyczne dla odbiorników w zakresie OSNMA, określające
wymogi i procesy dotyczące odbiorników, niezbędne do
zagwarantowania bezpiecznego wdrożenia OSNMA,
a także zalecenia dotyczące poprawy działania OSNMA.
Odbiorniki GNSS instalowane w tachografach, zarówno
wewnętrzne, jak i zewnętrzne, muszą być skonstruowane
zgodnie z dokumentem SIS ICD i wytycznymi dla odbior­
ników w zakresie OSNMA.
GNS_3c Odbiornik GNSS dostarcza komunikaty o pozycji, zwane
w niniejszym załączniku i dodatkach do niego komunikatami
o uwierzytelnionej pozycji, opracowane z wykorzystaniem
wyłącznie satelitów przekazujących komunikaty nawigacyjne,
których autentyczność została z powodzeniem zweryfikowana.
GNS_3d Odbiornik GNSS dostarcza również komunikaty o standardowej
pozycji opracowane z wykorzystaniem widocznych satelitów,
niezależnie od tego, czy są one uwierzytelnione, czy nie.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 506
GNS_3e Odbiornik GNSS wykorzystuje zegar czasu rzeczywistego
(RTC) VU jako odniesienie dla synchronizacji czasu na
potrzeby OSNMA.
GNS_3f Czas RTC VU jest przekazywany przez VU do odbiornika
GNSS.
GNS_3g VU przekazuje do odbiornika GNSS maksymalny dryft czasu okre­
ślony w wymogu 41 w załączniku IC, wraz z czasem RTC VU.
3. KOMUNIKATY PODAWANE PRZEZ ODBIORNIK GNSS
W niniejszej sekcji opisano komunikaty wykorzystywane w funkcjono­
waniu tachografu inteligentnego do przekazywania komunikatów o stan­
dardowej i uwierzytelnionej pozycji. Sekcja ta ma zastosowanie w odnie­
sieniu do konfiguracji tachografu inteligentnego z urządzeniem
zewnętrznym GNSS lub bez niego.
GNS_4 Dane o standardowej pozycji opierają się na zalecanych mini­
malnych danych GNSS (RMC) w komunikacie NMEA, który
zawiera informacje o pozycji (długość i szerokość geogra­
ficzną), czas w formacie UTC (hhmmss.ss), prędkość nad
dnem wyrażoną w węzłach oraz dodatkowe wartości.
Format komunikatu RMC jest następujący (według standardu
NMEA V4.11):
Rysunek 2
Struktura komunikatu RMC
$–RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x .x,xxxx,x.x,a,a,a*hh
1) Czas (UTC)
2) Status, A= prawidłowe położenie, V= ostrzeżenie
3) Szerokość geograficzna
4) N lub S
5) Długość geograficzna
6) E lub W
7) Prędkość nad dnem w węzłach
8) Tor prawidłowy, stopnie prawidłowe
9) Data, ddmmrr
10) Deklinacja magnetyczna w stopniach
11) E lub W
12) Wskaźnik trybu FAA
13) Status nawigacji
14) Suma kontrolna
Status nawigacji ma charakter opcjonalny i może być
nieobecny w komunikacie RMC.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 507
Parametr „Status” informuje o tym, czy sygnał GNSS jest
dostępny. Dopóki wartość statusu nie zostanie ustawiona na
„A”, otrzymywanych danych (np. dotyczących czasu lub
długości/szerokości geograficznej) nie można wykorzystywać
do rejestrowania pozycji pojazdu w VU.
Dokładność położenia opiera się na formacie komunikatu
RMC opisanym powyżej. Pierwszą część pól 3 i 5 wykorzys­
tuje się do określenia stopni. Pozostałe określają minuty
kątowe z dokładnością do trzech miejsc po przecinku.
Zatem dokładność wynosi 1/1 000 minuty kątowej
lub 1/60 000 stopnia (ponieważ jedna minuta to 1/60 stopnia).
GNS_4a Dane o uwierzytelnionej pozycji opierają się na komunikacie
podobnym do NMEA, z uwierzytelnionymi minimalnymi
danymi (AMC), który zawiera informacje o pozycji (długość
i szerokość geograficzną), czas w formacie UTC (hhmmss.ss),
prędkość nad dnem wyrażoną w węzłach oraz dodatkowe
wartości.
Format komunikatu AMC jest następujący (według standardu
NMEA V4.11, z wyjątkiem wartości nr 2):
Rysunek 3
Struktura komunikatu AMC
$–AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
1) Czas (UTC)
2) Status, A=uwierzytelniona pozycja (ustalona przy użyciu co najmniej 4
satelitów przekazujących komunikaty nawigacyjne, których autentyczność
została z powodzeniem zweryfikowana), J=jamming [celowe zakłócanie]
lub O=inny atak na GNSS w razie braku nieprawidłowego uwierzytelnienia
komunikatów nawigacyjnych (poprzez wdrożone kontrole spójności zgodnie
z GNS_3a), F= nieudane uwierzytelnienie komunikatów nawigacyjnych
(wykryte w wyniku weryfikacji OSNMA określonych w dokumentach,
o których mowa w GNS_3b), V=puste (uwierzytelniona pozycja nie jest
dostępna z innego powodu)
3) Szerokość geograficzna
4) N lub S
5) Długość geograficzna
6) E lub W
7) Prędkość nad dnem w węzłach
8) Tor prawidłowy, stopnie prawidłowe
9) Data, ddmmrr
10) Deklinacja magnetyczna w stopniach
11) E lub W
12) Wskaźnik trybu FAA
13) Status nawigacji
14) Suma kontrolna
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 508
Status nawigacji ma charakter opcjonalny i może być
nieobecny w komunikacie AMC.
Status wskazuje, czy uwierzytelniona pozycja GNSS dostępna
jest dostępna, czy wykryto atak na sygnały GNSS, czy uwie­
rzytelnienie komunikatów nawigacyjnych nie powiodło się,
lub czy pozycja GNSS jest pusta. Dopóki wartość statusu
nie zostanie ustawiona na „A”, otrzymywanych danych (np.
dotyczących czasu lub długości/szerokości geograficznej) nie
uznaje się za ważne i nie można ich wykorzystywać do reje­
strowania pozycji pojazdu w VU. Jeżeli wartość statusu jest
ustawiona na „J” (jamming), „O” (inny atak na GNSS) lub
„F” (nieupoważnione uwierzytelnienie komunikatów nawiga­
cyjnych), w VU rejestruje się zdarzenie anomalii GNSS, jak
określono w załączniku IC i dodatku 1 (EventFaultCode).
GNS_5 Przyrząd rejestrujący przechowuje w bazie danych VU infor­
macje o położeniu dotyczące szerokości i długości geogra­
ficznej z dokładnością 1/10 minuty kątowej lub 1/600 stopnia,
jak określono w dodatku 1 w odniesieniu do współrzędnych
geograficznych GeoCoordinates.
VU może wykorzystać polecenie GSA (dotyczące rozmycia
dokładności GPS i satelitów czynnych), zgodnie ze stan­
dardem NMEA V4.11, w celu ustalenia i zarejestrowania
dostępności sygnału i dokładności standardowych pozycji.
W szczególności HDOP stosuje się w celu wskazania
poziomu dokładności zarejestrowanych danych dotyczących
lokalizacji (zob. pkt 4.2.2). VU będzie przechowywał wartość
poziomego rozmycia dokładności (HDOP) obliczaną jako
minimum wartości HDOP zgromadzonych w dostępnych
systemach GNSS.
Identyfikator GNSS wskazuje odpowiedni identyfikator
NMEA dla każdej konstelacji GNSS i systemu wspomagają­
cego opartego na wyposażeniu satelitarnym SBAS.
Rysunek 4
Struktura komunikatu GSA (standardowe pozycje)
$–GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h
1) Tryb wyboru
2) Tryb
3) ID pierwszego satelity użytego do ustalenia pozycji
4) ID drugiego satelity użytego do ustalenia pozycji
…
14) ID dwunastego satelity użytego do ustalenia pozycji
15) PDOP
16) HDOP
17) VDOP
18) ID systemu
19) Suma kontrolna
ID systemu ma charakter opcjonalny i może być nieobecny
w komunikacie GSA.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 509
Podobnie VU może wykorzystywać polecenie ASA (doty­
czące uwierzytelnionych satelitów czynnych) z komunikatem
podobnym do NMEA w celu ustalenia i zarejestrowania goto­
wości sygnału i dokładności uwierzytelnionych pozycji.
Wartości 1–18 są zdefiniowane w standardzie NMEA V4.11.
Rysunek 5
Struktura komunikatu ASA (uwierzytelnione pozycje)
$–ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h
1) Tryb wyboru
2) Tryb
3) ID pierwszego satelity użytego do ustalenia pozycji
4) ID drugiego satelity użytego do ustalenia pozycji
…
14) ID dwunastego satelity użytego do ustalenia pozycji
15) PDOP
16) HDOP
17) VDOP
18) ID systemu
19) Suma kontrolna
ID systemu ma charakter opcjonalny i może być nieobecny
w komunikacie ASA.
GNS_6 W przypadku korzystania z urządzenia zewnętrznego GNSS
komunikat GSA przechowuje się w bezpiecznym
nadajniku-odbiorniku GNSS z numerem rekordu „02” do
„06”, a komunikat ASA przechowuje się z numerem rekordu
„12” do „16”.
GNS_7 Maksymalny rozmiar komunikatów (np. RMC, AMC, GSA,
ASA lub innych), jaki można zastosować w celu ustalenia
rozmiaru polecenia odczytu rekordu, wynosi 85 bajtów (zob.
tabela 1).
▼B
4. PRZYRZĄD REJESTRUJĄCY Z URZĄDZENIEM
ZEWNĘTRZNYM GNSS
4.1. Konfiguracja
4.1.1 Główne elementy składowe i interfejsy
W tej konfiguracji odbiornik GNSS stanowi część urządzenia
zewnętrznego GNSS.
GNS_8 Urządzenie zewnętrzne GNSS musi być obsługiwane przez
specjalny interfejs pojazdu.
▼M3
GNS_9 Urządzenie zewnętrzne GNSS składa się z następujących
elementów składowych (zob. rys. 6):
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 510
a) komercyjnego odbiornika GNSS zapewniającego dane
o pozycji za pośrednictwem interfejsu danych GNSS.
Przykładowo interfejs danych GNSS może być w stan­
dardzie NMEA V4.11, gdzie odbiornik GNSS pełni
funkcję nadajnika i przesyła komunikaty NMEA do
bezpiecznego nadajnika-odbiornika GNSS z częstotliwo­
ścią 1 Hz dla zdefiniowanego wcześniej zbioru komuni­
katów NMEA i podobnych do NMEA, który musi
zawierać co najmniej komunikaty RMC, AMC, GSA
i ASAA. Wdrożenie interfejsu danych GNSS zależy
od uznania producentów urządzeń zewnętrznych GNSS.
▼B
b) zespołu nadajnika-odbiornika (bezpiecznego nadajnika-
odbiornika GNSS) zdolnego do zapewnienia zgodności
z wymogami normy ISO/IEC 7816-4:2013 (zob.
pkt 4.2.1) w celu łączenia się z przyrządem rejestru­
jącym i obsługi interfejsu danych GNSS odbiornika
GNSS. Zespół ten jest wyposażony w pamięć do prze­
chowywania danych identyfikacyjnych z odbiornika
GNSS i urządzenia zewnętrznego GNSS;
▼M3
c) systemu obudowy z funkcją wykrywania manipulo­
wania, obejmującego zarówno odbiornik GNSS, jak
i bezpieczny nadajnik-odbiornik GNSS. Funkcja wykry­
wania manipulowania umożliwia wdrażanie środków
bezpieczeństwa zgodnie z wymogami określonymi
w profilu zabezpieczenia tachografu inteligentnego.
▼B
d) anteny GNSS zainstalowanej na pojeździe i połączonej
z odbiornikiem GNSS poprzez system obudowy.
GNS_10 Urządzenie zewnętrzne GNSS posiada co najmniej następu­
jące interfejsy zewnętrzne:
a) interfejs anteny GNSS zainstalowanej na pojeździe cięża­
rowym w przypadku korzystania z anteny zewnętrznej;
b) interfejs przyrządu rejestrującego.
GNS_11 W VU bezpieczny nadajnik-odbiornik VU znajduje się na
drugim końcu bezpiecznej łączności z bezpiecznym
nadajnikiem-odbiornikiem GNSS i musi zapewniać zgod­
ność z wymogami normy ISO/IEC 7816-4:2013 w zakresie
łączności z urządzeniem zewnętrznym GNSS.
GNS_12 W zakresie warstwy fizycznej łączności z urządzeniem
zewnętrznym GNSS przyrząd rejestrujący musi zapewniać
zgodność z wymogami normy ISO/IEC 7816-12:2005 lub
innej normy zgodnej z normą ISO/IEC 7816-4:2013 (zob.
pkt 4.2.1).
4.1.2 Stan urządzenia zewnętrznego GNSS na koniec procesu produkcji
GNS_13 Urządzenie zewnętrzne GNSS przechowuje następujące
wartości w pamięci trwałej bezpiecznego nadajnika-odbiornika
GNSS w momencie opuszczenia zakładu produkcyjnego:
— parę kluczy EGF_MA i powiązany certyfikat;
— certyfikat MSCA_VU-EGF zawierający klucz publiczny
MSCA_VU-EGF.PK służący do weryfikacji certyfikatu
EGF_MA;
— certyfikat EUR zawierający klucz publiczny EUR.PK
służący do weryfikacji certyfikatu MSCA_VU-EGF;
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 511
— certyfikat EUR, którego okres ważności wygasa bezpo­
średnio przed okres ważności certyfikatu EUR służą­
cego do celów weryfikacji certyfikatu MSCA_VU-
EGF, o ile istnieje;
— certyfikat łączący wspomniane dwa certyfikaty EUR,
o ile istnieje;
— rozszerzony numer seryjny urządzenia zewnętrznego
GNSS;
— identyfikator systemu operacyjnego urządzenia GNSS;
— numer homologacji typu urządzenia zewnętrznego
GNSS;
— identyfikator elementu zabezpieczenia modułu
zewnętrznego GNSS.
4.2. Łączność między urządzeniem zewnętrznym GNSS a przyrządem
rejestrującym
4.2.1 Protokół łączności
▼M3
GNS_14 Protokół łączności między urządzeniem zewnętrznym
GNSS a przyrządem rejestrującym obsługuje następujące
funkcje:
1. gromadzenie i rozpowszechnianie danych GNSS (np.
pozycja, czas, prędkość);
2. gromadzenie danych dotyczących konfiguracji urzą­
dzenia zewnętrznego GNSS;
3. protokół zarządzania na potrzeby obsługi powiązania,
wzajemnego uwierzytelnienia i uzgadniania klucza sesji
między urządzeniem zewnętrznym GNSS a VU;
4. przekazywanie do urządzenia zewnętrznego GNSS czasu
RTC VU oraz maksymalnej różnicy między czasem
prawdziwym a czasem RTC VU.
▼B
GNS_15 Protokół łączności bazuje na wymogach normy ISO/IEC
7816-4:2013, przy czym bezpieczny nadajnik-odbiornik
VU odgrywa rolę nadrzędną, a bezpieczny
nadajnik-odbiornik GNSS – rolę podrzędną. Fizyczne połą­
czenie między urządzeniem zewnętrznym GNSS a przy­
rządem rejestrującym bazuje na normie ISO/IEC 7816-
12:2005 lub innej normie zgodnej z normą ISO/IEC
7816-4:2013.
▼M1
GNS_16 W protokole łączności nie są obsługiwane pola o rozsze­
rzonej długości.
▼B
GNS_17 Protokół łączności bazujący na wymogach normy ISO 7816
(zarówno *-4:2013, jak i *-12:2005) między urządzeniem
zewnętrznym GNSS a VU ustawia się na wartość T=1.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 512
GNS_18 Jeżeli chodzi o funkcje: 1) gromadzenia i rozpowszechniania
danych GNSS; 2) gromadzenia danych dotyczących konfi­
guracji urządzenia zewnętrznego GNSS; oraz 3) protokołu
zarządzania, bezpieczny nadajnik-odbiornik GNSS symu­
luje inteligentną kartę za pomocą architektury systemu
plików składającej się z pliku głównego (MF), pliku dedy­
kowanego (DF) z identyfikatorem aplikacji określonym
w dodatku 1 rozdział 6.2 („FF 44 54 45 47 4D”) i z trzema
plikami elementarnymi (EF) zawierającymi certyfikaty oraz
jednego pojedynczego pliku elementarnego (EF.EGF)
z identyfikatorem pliku równym „2F2F”, jak opisano
w tabeli 1.
▼M3
GNS_18a W odniesieniu do funkcji 4 (przekazywanie do urządzenia
zewnętrznego GNSS czasu RTC VU oraz maksymalnej
różnicy między czasem prawdziwym a czasem RTC VU)
bezpieczny nadajnik-odbiornik GNSS wykorzystuje EF (EF
VU) w tym samym DF z identyfikatorem pliku równym
„2F30”, jak opisano w tabeli 1.
▼B
GNS_19 Bezpieczny nadajnik-odbiornik GNSS przechowuje dane
z odbiornika GNSS i konfigurację w pliku elementarnym
EF.EGF. Jest to liniowy plik rekordu o zmiennej długości
z identyfikatorem równym „2F2F” w formacie
heksadecymalnym.
▼M3
GNS_19a Bezpieczny nadajnik-odbiornik GNSS przechowuje dane
z VU w EF VU. Jest to liniowy plik rekordu o stałej
długości z identyfikatorem równym „2F30” w formacie
heksadecymalnym.
GNS_20 Bezpieczny nadajnik-odbiornik GNSS używa pamięci do
przechowywania danych i jest w stanie przeprowadzić
tyle cykli odczytu/zapisu, ile jest potrzebnych w okresie
eksploatacji wynoszącym co najmniej 15 lat. Poza tym
aspektem o konstrukcji wewnętrznej i wdrażaniu bezpiecz­
nego nadajnika-odbiornika GNSS decydują producenci.
▼M1
Mapowanie numerów rekordów i danych przedstawiono
w tabeli 1. Należy zauważyć, że istnieje pięć komunikatów
GSA dotyczących konstelacji GNSS i systemu wspomaga­
jącego opartego na wyposażeniu satelitarnym SBAS.
▼B
GNS_21 Strukturę plików przedstawiono w tabeli 1. Aby uzyskać
informacje na temat warunków dostępu (ALW, NEV,
SM-MAC), zob. dodatek 2 rozdział 3.5.
▼M3
Tabela 1
Struktura plików
Warunki dostępu
File ID pliku Odczyt Aktualizacja Zaszyfrowany
MF 3F00
EF.ICC 0002 ALW NEV
(ze strony VU)
Nie
▼M1
02016R0799 — PL — 21.08.2023 — 003.002 — 513
Warunki dostępu
File ID pliku Odczyt Aktualizacja Zaszyfrowany
DF GNSS Facility 0501 ALW NEV Nie
EF EGF_MACertificate C100 ALW NEV Nie
EF CA_Certificate C108 ALW NEV Nie
EF Link_Certificate C109 ALW NEV Nie
EF EGF 2F2F SM-MAC NEV
(ze strony VU)
Nie
EF VU 2F30 SM-MAC SM-MAC Nie
Plik / element danych Nr rekordu Rozmiar (w bajtach)
Wartości
domyślne
Min. Maks.
MF 552 1031
EF.ICC
sensorGNSSSerialNumber 8 8
DF GNSS Facility 612 1023
EF EGF_MACertificate 204 341
EGFCertificate 204 341 {00..00}
EF CA_Certificate 204 341
MemberStateCertificate 204 341 {00..00}
EF Link_Certificate 204 341
LinkCertificate 204 341 {00..00}
EF EGF
Komunikat RMC NMEA '01' 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 zdefiniowany
w dodatku 1 jako SensorGNSSSerial­
Number.
'07' 8 8
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 514
Plik / element danych Nr rekordu Rozmiar (w bajtach)
Wartości
domyślne
Identyfikator systemu operacyjnego
bezpiecznego nadajnika-odbiornika
GNSS zdefiniowany w dodatku
1 jako SensorOSIdentifier.
'08' 2 2
Numer homologacji typu urządzenia
zewnętrznego GNSS zdefiniowany
w dodatku 1 jako SensorExternal­
GNSSApprovalNumber.
'09' 16 16
Identyfikator elementu zabezpieczenia
urządzenia zewnętrznego GNSS zdefi­
niowany w dodatku 1 jako SensorEx­
ternalGNSSSCIdentifier.
'10' 8 8
Komunikat AMC '11' 85 85
Pierwszy komunikat ASA '12' 85 85
Drugi komunikat ASA '13' 85 85
Trzeci komunikat ASA '14' 85 85
Czwarty komunikat ASA '15' 85 85
Piąty komunikat ASA '16' 85 85
RFU – zarezerwowane dla przyszłego
użytku
Od '17' do
'FD'
EF VU
VuRtcTime (zob. dodatek 1) '01' 4 4 {00..00}
VuGnssMaximalTimeDifference (zob.
dodatek 1)
'02' 2 2 {00..00}
▼B
4.2.2 Bezpieczne przesyłanie danych GNSS
▼M3
GNS_22 Bezpieczne przesyłanie danych GNSS o pozycji, czasu
RTC VU i maksymalnej różnicy czasowej między czasem
prawdziwym a czasem RTC VU jest dozwolone wyłącznie
w następujących warunkach:
▼B
1. proces powiązania został przeprowadzony w sposób
opisany w dodatku 11 „Wspólne mechanizmy zabezpie­
czenia”;
2. proces okresowego wzajemnego uwierzytelniania
i uzgadniania klucza sesji między VU a urządzeniem
zewnętrznym GNSS, również opisany w dodatku 11
„Wspólne mechanizmy zabezpieczenia”, przeprowa­
dzono ze wskazaną częstotliwością.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 515
GNS_23 Co T sekund, gdzie T jest wartością nie większą niż 20,
chyba że trwa proces powiązania lub wzajemnego uwierzy­
telnienia i uzgadniania klucza sesji, VU żąda od urządzenia
zewnętrznego GNSS przesłania informacji o pozycji
w oparciu o poniższy schemat.
1. VU żąda od urządzenia zewnętrznego GNSS przesłania
danych dotyczących pozycji wraz z danymi dotyczącymi
rozmycia dokładności (z komunikatów GSA i ASA).
Bezpieczny nadajnik-odbiornik VU stosuje zgodne z wymo­
gami normy ISO/IEC 7816-4:2013 polecenia SELECT
[wybór] i READ RECORD(S) [odczyt rekordu(-ów)]
w trybie tylko uwierzytelniania bezpiecznej wymiany komu­
nikatów, jak opisano w dodatku 11 sekcja 11.5, z identyfi­
katorem pliku „2F2F” i numerem rekordu „01” w przypadku
komunikatu RMC NMEA, „02”,„03”,„04”,„05”,„06”
w przypadku komunikatu GSA NMEA, „11” w przypadku
komunikatu AMC oraz „12”,„13”,„14”,„15”,„16” w przy­
padku komunikatu ASA.
2. Dane dotyczące pozycji otrzymane jako ostatnie są prze­
chowywane w pliku elementarnym z identyfikatorem
„2F2F” i rekordami opisanymi w tabeli 1 w bezpiecznym
nadajniku-odbiorniku GNSS, ponieważ bezpieczny
nadajnik-odbiornik GNSS otrzymuje dane NMEA z częs­
totliwością co najmniej 1 Hz od odbiornika GNSS za
pośrednictwem interfejsu danych GNSS.
3. Bezpieczny nadajnik-odbiornik GNSS wysyła odpo­
wiedź do bezpiecznego nadajnika-odbiornika VU za
pomocą komunikatu odpowiedzi APDU w trybie tylko
uwierzytelniania bezpiecznej wymiany komunikatów,
zgodnie z opisem przedstawionym w dodatku 11 sekcja
11.5.
4. Bezpieczny nadajnik-odbiornik VU weryfikuje auten­
tyczność i integralność otrzymanej odpowiedzi. W przy­
padku pozytywnego wyniku dane dotyczące pozycji są
przekazywane do procesora VU za pośrednictwem inter­
fejsu danych GNSS.
5. Procesor VU sprawdza otrzymane dane, wyodrębniając
informacje (np. o długości geograficznej, szerokości
geograficznej, czasie) z komunikatu NMEA RMC.
Komunikat RMC NMEA zawiera informację o tym,
czy nieuwierzytelniona pozycja jest prawidłowa. Jeżeli
uwierzytelniona pozycja jest prawidłowa, procesor VU
wyodrębnia również wartości HDOP z komunikatów
NMEA GSA i oblicza minimalną wartość w stosunku
do dostępnych systemów satelitarnych (tj. jeżeli usta­
lenie pozycji jest możliwe).
6. Procesor VU wyodrębnia również informacje (np.
o długości geograficznej, szerokości geograficznej,
czasie) z komunikatu AMC. Komunikat AMC zawiera
informacje, czy uwierzytelniona pozycja jest nieprawid­
łowa lub czy sygnał GNSS został zaatakowany. Jeżeli
pozycja jest prawidłowa, procesor VU wyodrębnia
również wartości HDOP z komunikatów ASA i oblicza
minimalną wartość w stosunku do dostępnych systemów
satelitarnych (tj. jeżeli ustalenie pozycji jest możliwe).
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 516
GNS_23a VU zapisuje również czas RTC VU i maksymalną różnicę
czasu między czasem prawdziwym a czasem RTC VU,
stosownie do potrzeb, stosując polecenia SELECT [wybór]
i WRITE RECORD(S) [zapis rekordu(-ów)] zgodnie
z normą ISO/IEC 7816-4:2013 w trybie tylko uwierzytel­
niania bezpiecznej wymiany komunikatów, jak opisano
w dodatku 11 sekcja 11.5, z identyfikatorem pliku „2F30”
i numerem rekordu równym „01” dla VuRtcTime oraz „02”
for MaximalTimeDifference.
▼B
4.2.3 Struktura polecenia Read Record
Poniższa sekcja zawiera szczegółowy opis struktury polecenia 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 komuni­
katów
INS 1 „B2h” Odczyt rekordu
P1 1 „XXh” Numer rekordu („00” oznacza bieżący
rekord)
P2 1 „04h” Odczytaj rekord o numerze rekordu
wskazanym w P1
Le 1 „XXh” Długość oczekiwanych danych. Liczba
bajtów do odczytu
GNS_26 Rekord wskazany w P1 staje się rekordem bieżącym.
Bajt Długość Wartość Opis
#1-#X X „XX..XXh” Odczyt danych
SW 2 „XXXXh” Słowo stanu (SW1, SW2)
— jeżeli wykonanie polecenia zakończyło się pomyślnie,
bezpieczny nadajnik-odbiornik GNSS zwraca komu­
nikat „9000”,
— jeżeli bieżący plik nie jest ukierunkowany na rekord,
bezpieczny nadajnik-odbiornik GNSS zwraca komu­
nikat „6981”,
— jeżeli stosuje się polecenie z P1= „00”, lecz nie ma
żadnego bieżącego pliku elementarnego, bezpieczny
nadajnik-odbiornik GNSS zwraca komunikat „6986”
(polecenie niedozwolone),
▼M3
— jeżeli nie znaleziono rekordu, bezpieczny
nadajnik-odbiornik GNSS zwraca komunikat „6A83”,
— jeżeli urządzenie zewnętrzne GNSS wykryje manipulo­
wanie, zwraca słowa stanu „6690”.
__________
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 517
4.2.4 Struktura polecenia WriteRecord
Poniższa sekcja zawiera szczegółowy opis struktury polecenia Write
Record [zapis rekordu]. Zgodnie z opisem przedstawionym w dodatku
11 „Wspólne mechanizmy zabezpieczenia” dodaje się funkcję
bezpiecznej wymiany komunikatów (tryb tylko uwierzytelniania).
GNS_26a Polecenie to obsługuje tryb tylko uwierzytelniania
bezpiecznej wymiany komunikatów, zob. dodatek 11.
GNS_26b Komunikat polecenia
Bajt Długość Wartość Opis
CLA 1 „0Ch” Żądanie bezpiecznej wymiany komuni­
katów
INS 1 „D2h” Zapis rekordu
P1 1 „XXh” Numer rekordu ('00' oznacza bieżący
rekord)
P2 1 „04h” Zapis rekordu o numerze rekordu wska­
zanym w P1
Dane X „XXh” Dane
GNS_26c Rekord wskazany w P1 staje się rekordem bieżącym.
Bajt Długość Wartość Opis
SW 2 „XXXXh” Słowa stanu (SW1, SW2)
— Jeżeli wykonanie polecenia zakończyło się pomyślnie,
bezpieczny nadajnik-odbiornik GNSS zwraca komu­
nikat „9000”.
— Jeżeli bieżący plik nie jest ukierunkowany na rekord,
bezpieczny nadajnik-odbiornik GNSS zwraca komu­
nikat '6981'.
— Jeżeli stosuje się polecenie z P1= „00”, lecz nie ma
żadnego bieżącego pliku elementarnego, bezpieczny
nadajnik-odbiornik GNSS zwraca komunikat '6986'
(polecenie niedozwolone).
— Jeżeli nie znaleziono rekordu, bezpieczny
nadajnik-odbiornik GNSS zwraca komunikat '6A83'.
— Jeżeli urządzenie zewnętrzne GNSS wykryje manipulo­
wanie, zwraca słowa stanu „6690”.
4.2.5. Inne polecenia
GNS_27 Bezpieczny nadajnik-odbiornik GNSS obsługuje następu­
jące polecenia tachografów 2. generacji, wyszczególnione
w dodatku 2:
Polecenie Odniesienie
Select [wybór] Dodatek 2 rozdział 3.5.1
Read Binary [odczyt binarny] Dodatek 2 rozdział 3.5.2
Get Challenge [wydanie wezwania] Dodatek 2 rozdział 3.5.4
PSO: Verify Certificate [weryfikacja
certyfikatu]
Dodatek 2 rozdział 3.5.7
External authenticate [uwierzytel­
nianie zewnętrzne]
Dodatek 2 rozdział 3.5.9
General Authenticate [uwierzytel­
nianie ogólne]
Dodatek 2 rozdział 3.5.10
MSE:SET Dodatek 2 rozdział 3.5.11
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 518
4.3. Powiązanie, wzajemne uwierzytelnienie i uzgodnienie klucza sesji
między urządzeniem zewnętrznym GNSS a przyrządem rejestru­
jącym
Proces powiązania, wzajemnego uwierzytelniania i uzgadniania klucza
sesji między urządzeniem zewnętrznym GNSS a przyrządem rejestru­
jącym opisano w rozdziale 11 dodatku 11 „Wspólne mechanizmy
zabezpieczenia”.
4.4. Obsługa błędów
W niniejszej sekcji opisano sposób obsługi potencjalnych warunków
błędów przez urządzenie zewnętrzne GNSS oraz ich rejestrowania
w VU.
4.4.1 Błąd komunikacji z urządzeniem zewnętrznym GNSS
▼M3
GNS_28 Błąd połączenia z urządzeniem zewnętrznym GNSS zapi­
suje się w VU, jak określono w wymogu 82 w załączniku
IC i dodatku 1 (EventFaultType). W tym kontekście wystę­
puje błąd połączenia, gdy bezpieczny nadajnik-odbiornik
VU nie otrzyma komunikatu odpowiedzi po wysłaniu
komunikatu żądania, jak opisano w pkt 4.2.
▼B
4.4.2 Naruszenie integralności fizycznej urządzenia zewnętrznego GNSS
▼M3
GNS_29 W przypadku naruszenia integralności fizycznej urządzenia
zewnętrznego GNSS bezpieczny nadajnik-odbiornik GNSS
gwarantuje niedostępność materiału kryptograficznego. Jak
opisano w GNS_25 i GNS_26, VU wykrywa manipulo­
wanie, jeżeli odpowiedź ma status „6690”. Następnie VU
generuje i rejestruje zdarzenie związane z próbą naruszenia
zabezpieczenia zdefiniowane w wymogu 85 w załączniku
IC i dodatku 1 (EventFaultType do celów wykrywania
manipulowania w GNSS). Urządzenie zewnętrzne GNSS
może ewentualnie odpowiedzieć na żądania VU bez
bezpiecznej wymiany komunikatów i ze statusem „6A88”.
▼B
4.4.3 Brak informacji o położeniu z odbiornika GNSS
▼M3
GNS_30 Jeżeli bezpieczny nadajnik-odbiornik GNSS nie otrzymuje
danych z odbiornika GNSS, urządzenie to generuje komu­
nikat odpowiedzi na polecenie READ RECORD [odczyt
rekordu] z numerem rekordu „01” i polem danych
o rozmiarze 12 bajtów, wszystkich ustawionych na 0xFF.
Po otrzymaniu komunikatu odpowiedzi zawierającego tę
wartość pola danych VU generuje i rejestruje brak infor­
macji o pozycji ze zdarzenia odbiornika GNSS, jak okre­
ślono w wymogu 81 w załączniku IC i dodatku 1 (Even­
tFaultType).
▼B
4.4.1 Wygaśnięcie certyfikatu urządzenia zewnętrznego GNSS
▼M3
GNS_31 Jeżeli VU wykryje, że certyfikat EGF stosowany do
wzajemnego uwierzytelniania nie jest już ważny, VU gene­
ruje i rejestruje zdarzenie związane z próbą naruszenia
zabezpieczenia zdefiniowane w wymogu 85 w załączniku
IC i dodatku 1 (EventFaultType dla wygaśnięcia certyfi­
katu urządzenia zewnętrznego GNSS). VU nadal wyko­
rzystuje otrzymane dane GNSS o pozycji.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 519
Rysunek 6
Schemat urządzenia zewnętrznego GNSS
▼B
5. PRZYRZĄD REJESTRUJĄCY BEZ URZĄDZENIA ZEWNĘTRZ­
NEGO GNSS
5.1. Konfiguracja
W tej konfiguracji odbiornik GNSS znajduje się wewnątrz przyrządu
rejestrującego, jak przedstawiono na rys. 1.
▼M3
GNS_32 Na potrzeby przekazywania pozycji, DOP i danych sateli­
tarnych odbiornik GNSS pełni funkcję nadajnika i przesyła
komunikaty NMEA i podobne do NMEA do procesora
VU, który pełni funkcję odbiornika o częstotliwości 1/10
Hz lub większej dla zdefiniowanego wcześniej zbioru
komunikatów, który musi obejmować co najmniej komu­
nikaty RMC, GSA, AMC i ASA. Procesor VU
i wewnętrzny odbiornik GNSS mogą ewentualnie wyko­
rzystywać inne formaty danych do wymiany danych zawar­
tych w komunikatach NMEA lub podobnych do NMEA
określonych w GNS_4, GNS_4a i GNS_5.
▼B
GNS_33 Do VU musi być podłączona zewnętrzna antena GNSS
zainstalowana na pojeździe lub wewnętrzna antena GNSS.
▼M3
5.2. Transfer informacji z odbiornika GNSS do VU
GNS_34 Procesor VU sprawdza otrzymane dane, wyodrębniając
informacje (np. o długości geograficznej, szerokości
geograficznej, czasie) z komunikatu RMC NMEA i komu­
nikatu AMC.
GNS_35 Komunikat RMC NMEA zawiera informację o tym, czy
nieuwierzytelniona pozycja jest prawidłowa. Jeżeli
nieuwierzytelniona pozycja nie jest prawidłowa, dane doty­
czące pozycji nie są dostępne i nie można ich wykorzystać
w celu zarejestrowania pozycji pojazdu. Jeżeli nieuwierzy­
telniona pozycja jest prawidłowa, procesor VU wyodrębnia
również wartości HDOP z GSA NMEA.
GNS_36 Procesor VU wyodrębnia również informacje (np.
o długości geograficznej, szerokości geograficznej, czasie)
z komunikatu AMC. Komunikat AMC zawiera informację
o tym, czy nieuwierzytelniona pozycja jest prawidłowa
zgodnie z GNS_4a. Jeżeli nieuwierzytelniona pozycja jest
prawidłowa, procesor VU wyodrębnia również wartości
HDOP z komunikatów ASA.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 520
5.3. Transfer informacji z VU do odbiornika GNSS
GNS_37 Procesor VU przekazuje do odbiornika GNSS czas RTC
VU oraz maksymalną różnicę między czasem prawdziwym
a czasem RTC VU, zgodnie z GNS_3f i GNS_3g.
5.4. Obsługa błędów
5.4.1. Brak informacji o pozycji z odbiornika GNSS
GNS_38 VU generuje i rejestruje brak informacji o pozycji ze
zdarzenia odbiornika GNSS, jak określono w wymogu 81
w załączniku IC i dodatku 1 (EventFaultType).
6. PRZETWARZANIE I REJESTRACJA DANYCH O POZYCJI
PRZEZ VU
Sekcja ta ma zastosowanie w odniesieniu do konfiguracji tachografu
inteligentnego z urządzeniem zewnętrznym GNSS lub bez niego.
GNS_39 Dane o pozycji są przechowywane w VU wraz z flagą
wskazującą, czy pozycja została uwierzytelniona. Jeżeli
konieczne jest zarejestrowanie danych dotyczących pozycji
w VU, zastosowanie mają następujące zasady:
a) Jeżeli zarówno uwierzytelniona pozycja, jak i standar­
dowa pozycja są prawidłowe i spójne, standardową
pozycję i jej dokładność rejestruje się w VU, a flaga
ustawiana jest na „uwierzytelniona”.
b) Jeżeli zarówno uwierzytelniona pozycja, jak i standar­
dowa pozycja są prawidłowe, ale nie są spójne, VU
zapisuje uwierzytelnioną pozycję i jej dokładność,
a flaga ustawiana jest na „uwierzytelniona”.
c) Jeżeli uwierzytelniona pozycja jest prawidłowa, a stan­
dardowa pozycja nie jest prawidłowa, VU rejestruje
uwierzytelnioną pozycję i jej dokładność, a flaga usta­
wiana jest na „uwierzytelniona”.
d) Jeżeli standardowa pozycja jest prawidłowa, a uwierzy­
telniona pozycja nie jest prawidłowa, VU rejestruje stan­
dardową pozycję i jej dokładność, a flaga ustawiana jest
na „nieuwierzytelniona”.
Uwierzytelnione i standardowe pozycje uznaje się za
spójne, jak pokazano na rys. 7, jeżeli uwierzytelniona
pozycja pozioma znajduje się w okręgu o środku w standar­
dowej pozycji poziomej, którego promień wynika z zaokrąg­
lenia w górę do najbliższej liczby całkowitej wartości R_H
obliczonej według następującego wzoru:
R_H = 1,74 • σ UERE • HDOP
gdzie:
— R_H to odpowiedni promień okręgu wokół szacowanej
pozycji poziomej, w metrach. Jest to wskaźnik używany
do kontroli spójności między pozycją standardową
a pozycją uwierzytelnioną.
— σ UERE to odchylenie standardowe ekwiwalentnego
błędu pomiaru odległości użytkownika (UERE), gdzie
modeluje się wszystkie błędy pomiaru dla docelowego
zastosowania, w tym obszarów miejskich. Stosuje się
wartość stałą σ UERE = 10 metrów.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 521
— HDOP oznacza poziome rozmycie dokładności obliczeń
odbiornika GNSS.-
— σ UERE . HDOP to oszacowanie pierwiastka błędu śred­
niokwadratowego w poziomie.
Rysunek 7
Spójne pozycje uwierzytelnione i standardowe (nieuwierzytelnione)
GNS_40 Jeżeli wartość statusu w otrzymanym komunikacie AMC
jest ustawiona na „J” lub „O” lub „F” zgodnie z wymogiem
GNS_4a, VU generuje i rejestruje zdarzenie anomalii
GNSS, jak określono w wymogu 88a w załączniku IC
i dodatku 1 (EventFaultType). Przyrząd rejestrujący może
przeprowadzić dodatkowe kontrole przed zapisaniem
zdarzenia anomalii GNSS po otrzymaniu ustawienia „J”
lub „O”.
7. KONFLIKT CZASOWY GNSS
GNS_41 Jeżeli VU wykryje rozbieżność między czasem funkcji
pomiaru czasu przyrządu rejestrującego a czasem pocho­
dzącym z sygnałów GNSS, generuje i rejestruje zdarzenie
konfliktu czasowego, jak określono w wymogu 86
w załączniku IC i dodatku 1 (EventFaultType).
8. KONFLIKT RUCHU POJAZDU
GNS_42 VU uruchamia i rejestruje zdarzenie konfliktu ruchu
pojazdu zgodnie z wymogiem 84 w załączniku IC, w przy­
padku gdy informacja o ruchu obliczona na podstawie
czujnika ruchu jest sprzeczna z informacjami o ruchu obli­
czonymi na podstawie wewnętrznego odbiornika GNSS,
urządzenia zewnętrznego GNSS lub przez inne niezależne
źródła ruchu określone w wymogu 26 w załączniku IC.
Zdarzenie konfliktu ruchu pojazdu uruchamia się po wystą­
pieniu jednego z następujących warunków uruchamiają­
cych:
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 522
Warunek uruchamiający 1:
W przypadku gdy dostępne są informacje o pozycji
z odbiornika GNSS i gdy następuje włączenie zapłonu
pojazdu, należy stosować wartość średniej trymowanej
różnic prędkości między tymi źródłami, jak określono
poniżej:
— maksymalnie co 10 sekund należy obliczać wartość
bezwzględną różnicy między różnicą prędkości pojazdu
szacowaną na podstawie danych z odbiornika GNSS
a różnicą szacowaną na podstawie danych z czujnika
ruchu,
— wartość średniej trymowanej oblicza się wykorzystując
wszystkie obliczone wartości w oknie czasu obejmu­
jącym 5 ostatnich minut ruchu pojazdu,
— wartość średniej trymowanej oblicza się jako średnią
80 % wartości pozostałych po wyeliminowaniu najwyż­
szych wartości bezwzględnych.
zdarzenie konfliktu ruchu pojazdu jest wyzwalane jeżeli
wartość średniej trymowanej jest wyższa niż 10 km/h
przez pięć nieprzerwanych minut ruchu pojazdu. (Uwaga:
średnią trymowaną z ostatnich 5 minut stosuje się, aby
zmniejszyć ryzyko związane z wartościami skrajnymi
pomiaru i wartościami chwilowymi).
Na potrzeby obliczenia średniej trymowanej pojazd uznaje
się za poruszający się, jeżeli co najmniej jedna wartość
prędkości pojazdu oszacowana na podstawie czujnika
ruchu albo odbiornika GNSS nie jest równa zeru.
Warunek uruchamiający 2:
Zdarzenie konfliktu ruchu pojazdu jest również urucha­
miane, jeżeli spełniony jest następujący warunek:
GnssDistance>[OdometerDifference×OdometerTolerance­
Factor+Minimum (SlipDistanceUpperlimit;(OdometerDiffe­
rence×SlipFactor))+GnssTolerance+FerryTrainDistance]
gdzie:
— GnssDistance to odległość między bieżącą pozycją
pojazdu a poprzednią pozycją, uzyskanymi na
podstawie komunikatów o prawidłowej pozycji uwie­
rzytelnionej, bez uwzględniania wysokości;
— OdometerDifference to różnicą między bieżącą warto­
ścią licznika kilometrów a wartością licznika kilo­
metrów odpowiadającą poprzedniemu komunikatowi
o prawidłowej pozycji uwierzytelnionej;
— OdometerToleranceFactor wynosi 1,1 (współczynnik
tolerancji najbardziej niekorzystnego przypadku dla
wszystkich tolerancji pomiaru licznika kilometrów
pojazdu);
— GnssTolerance wynosi 1 km (najbardziej niekorzystny
przypadek tolerancji GNSS);
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 523
— Minimum (SlipDistanceUpperLimit; (OdometerDiffe­
rence * SlipFactor)) to wartość najmniejsza spośród
następujących:
— SlipDistanceUpperLimit, która wynosi 10 km
(górna granica drogi poślizgu spowodowanej efek­
tami poślizgowymi podczas hamowania)
— oraz OdometerDifference * SlipFactor, gdzie Slip­
Factor wynosi 0,2 (maksymalny wpływ efektów
poślizgowych podczas hamowania),
— FerryTrainDistance oblicza się jako: FerryTrainDis­
tance =200km/h * tFerryTrain, gdzie tFerryTrain jest
sumą czasu trwania (w godzinach) przepraw promo­
wych/pociągowych w analizowanym przedziale
czasowym. Czas trwania przepraw promowych/pocią­
gowych definiuje się jako różnicę czasu między jego
flagą końcową a jego flagą początkową.
Poprzedzające weryfikacje przeprowadza się co 15 minut,
jeżeli dostępne są niezbędne dane o pozycji, a w prze­
ciwnym razie, gdy tylko dostępne będą dane o pozycji.
Dla tego warunku uruchamiającego:
— data i godzina rozpoczęcia zdarzenia równa się dacie
i godzinie otrzymania poprzedniego komunikatu
o pozycji,
— data i godzina zakończenia zdarzenia są równa się
dacie i godzinie, kiedy sprawdzany warunek staje się
ponownie fałszywy.
Warunek uruchamiający 3:
Przyrząd rejestrujący napotyka rozbieżność polegającą na
tym, że czujnik ruchu nie wykrywa żadnego ruchu, a nieza­
leżne źródło ruchu wykrywa ruch przez określony czas.
Producent przyrządów rejestrujących określa warunki reje­
strowania rozbieżności, jak również okres wykrywania
rozbieżności, przy czym rozbieżności te muszą być wykry­
wane nie później niż w ciągu trzech godzin.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 524
Dodatek 13
INTERFEJS ITS
SPIS TREŚCI
1. WPROWADZENIE
1.1. Zakres
1.2. Akronimy i definicje
2. PRZYWOŁANE NORMY
3. ZASADY DZIAŁANIA INTERFEJSU ITS
3.1. Technologia łączności
3.2. Dostępne usługi
3.3. Dostęp poprzez interfejs ITS
3.4. Dostępne dane i wymóg uzyskania zgody kierowcy
4. WYKAZ DANYCH DOSTĘPNYCH ZA POŚREDNICTWEM INTER­
FEJSU ITS ORAZ KLASYFIKACJA DANYCH JAKO OSOBOWE/
NIEOSOBOWE
1. WPROWADZENIE
1.1. Zakres
ITS_01 Niniejszy dodatek określa podstawowe elementy łączności za
pośrednictwem interfejsu tachografu z inteligentnymi systemami
transportowymi (ITS), zgodnie z art. 10 i 11 rozporządzenia (UE)
nr 165/2014.
ITS_02 Interfejs ITS umożliwia urządzeniom zewnętrznym uzyskiwanie
danych z tachografu, korzystanie z usług tachografu oraz dostar­
czanie danych do tachografu.
Do tego celu mogą być również wykorzystywane inne interfejsy
tachografu (np. szyna CAN).
Niniejszy dodatek nie określa:
— w jaki sposób dane dostarczane za pośrednictwem interfejsu
ITS są gromadzone i zarządzane w ramach tachografu;
— formy przedstawienia zgromadzonych danych w aplikacji zain­
stalowanej na urządzeniu zewnętrznym;
— specyfikacji zabezpieczeń ITS uzupełniających zabezpieczenia
zapewniane przez Bluetooth®;
— protokołów Bluetooth® wykorzystywanych przez interfejs ITS.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 525
1.2. Akronimy i definicje
Stosuje się następujące akronimy i definicje właściwe dla tego dodatku:
GNSS Global Navigation Satellite System [globalny system nawi­
gacji satelitarnej]
ITS Intelligent Transport System [inteligentny system transpor­
towy]
OSI Open Systems Interconnection [połączenie systemów otwar­
tych]
VU Vehicle Unit [przyrząd rejestrujący]
urządzenie ITSurządzenie zewnętrzne lub aplikacja zewnętrzna wykorzys­
tujące interfejs ITS VU.
2. PRZYWOŁANE NORMY
ITS_03 Niniejszy dodatek dotyczy wszystkich lub części wskazanych
poniżej regulacji i norm i jest od nich zależny. W ramach zapisów
niniejszego dodatku wskazano odnośne normy lub odnośne prze­
pisy norm. W razie jakichkolwiek sprzeczności zapisy niniejszego
dodatku są nadrzędne.
Normami przywołanymi w niniejszym dodatku, są:
— Bluetooth® – Core Version (wersja podstawowa) 5.0;
— ISO 16844-7: Pojazdy drogowe – Systemy tachograficzne –
Część 7: Parametry
— ISO/IEC7498-1:1994 Technologia informatyczna – Współdzia­
łanie systemów otwartych – Podstawowy model odniesienia:
Model podstawowy
3. ZASADY DZIAŁANIA INTERFEJSU ITS
ITS_04 Przyrząd rejestrujący odpowiada za aktualizowanie i utrzymywanie
danych tachografu przesyłanych za pośrednictwem interfejsu ITS,
bez żadnego udziału interfejsu ITS.
3.1. Technologia łączności
ITS_05 Łączność poprzez interfejs ITS musi być zapewniana za pośrednic­
twem interfejsu Bluetooth® i kompatybilna z Bluetooth® Low
Energy [o niskim zużyciu energii] zgodnie z wersją 5.0 lub nowszą
Bluetooth .
ITS_06 Łączność między VU a urządzeniem ITS ustanawia się po zakoń­
czeniu procesu parowania Bluetooth®.
ITS_07 Ustanawia się bezpieczną i zaszyfrowaną łączność między VU
a urządzeniem ITS, zgodnie z mechanizmami specyfikacji
Bluetooth®. Niniejszy dodatek nie określa mechanizmów szyfro­
wania ani innych mechanizmów zabezpieczenia poza tym, co
zapewnia Bluetooth®.
ITS_08 Bluetooth® wykorzystuje model serwer/klient do kontroli trans­
misji danych między urządzeniami, gdzie VU jest serwerem, a urzą­
dzenie ITS klientem.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 526
3.2. Dostępne usługi
ITS_09 Dane przekazywane za pośrednictwem interfejsu ITS zgodnie
z pkt 4 udostępnia się za pośrednictwem usług określonych
w dodatkach 7 i 8. Ponadto VU udostępnia urządzeniu ITS usługi
niezbędne do ręcznego wprowadzania danych zgodnie z wymogiem
61 w załączniku IC oraz opcjonalnie w odniesieniu do innych
wpisów danych w czasie rzeczywistym.
Rysunek 1
Podział łączności poprzez interfejs ITS zgodnie z warstwami modelu OSI
ITS_10 Jeżeli interfejs pobierania jest używany przez złącze przednie, VU
nie świadczy usług pobierania określonych w dodatku 7 za pośred­
nictwem połączenia ITS Bluetooth®.
ITS_11 Jeżeli interfejs kalibracji jest używany przez złącze przednie, VU
nie świadczy usług kalibracji określonych w dodatku 8 za pośred­
nictwem połączenia ITS Bluetooth®.
3.3. Dostęp poprzez interfejs ITS
ITS_12 Interfejs ITS zapewnia bezprzewodowy dostęp do wszystkich usług
określonych w dodatkach 7 i 8, zastępując połączenie kablowe
z przednim złączem do celów kalibracji i pobierania określonych
w dodatku 6.
ITS_13 VU udostępnia interfejs ITS użytkownikowi zgodnie z kombinacją
ważnych kart do tachografów włożonych do VU, jak określono
w tabeli 1.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 527
Tabela 1
Dostępność interfejsu ITS w zależności od typu karty włożonej do tachografu
Dostępność interfejsu ITS Szczelina czytnika karty kierowcy
Brak karty Karta kierowcy Karta kontrolna Karta warsztatowa Karta firmowa
S
zc
ze
li
na
c
zy
tn
ik
a
ka
rt
y
w
sp
ół
ki
er
ow
cy

Brak karty niedostępny dostępny dostępny dostępny dostępny
Karta kierowcy dostępny dostępny dostępny dostępny dostępny
Karta kontrolna dostępny dostępny dostępny niedostępny niedostępny
Karta warsz­
tatowa
dostępny dostępny niedostępny dostępny niedostępny
Karta firmowa dostępny dostępny niedostępny niedostępny dostępny
ITS_14 Po udanym sparowaniu ITS Bluetooth® VU przypisuje połączenie ITS Bluetooth® do konkretnej karty
włożonej do tachografu zgodnie z tabelą 2:
Tabela 2
Przypisanie połączenia ITS w zależności od typu karty włożonej do tachografu
Przypisanie połączenia ITS
Bluetooth®
Szczelina czytnika karty kierowcy
Brak karty Karta kierowcy Karta kontrolna Karta warsztatowa Karta firmowa
S
zc
ze
li
na
c
zy
tn
ik
a
ka
rt
y
w
sp
ół
ki
er
ow
cy

Brak karty niedostępny Karta kierowcy Karta kontrolna Karta warsz­
tatowa
Karta firmowa
Karta kierowcy Karta kierowcy Karta
kierowcy (**)
Karta kontrolna Karta warsz­
tatowa
Karta firmowa
Karta kontrolna Karta kontrolna Karta kontrolna Karta
kontrolna (*)
niedostępny niedostępny
Karta warsz­
tatowa
Karta warsz­
tatowa
Karta warsz­
tatowa
niedostępny Karta warsz­
tatowa (*)
niedostępny
Karta firmowa Karta firmowa Karta firmowa niedostępny niedostępny Karta
firmowa (*)
(*) Połączenie ITS Bluetooth® przypisuje się karcie do tachografu w szczelinie czytnika karty kierowcy VU.
(**) Użytkownik wybiera kartę, do której należy przypisać połączenie ITS Bluetooth® (włożoną do szczeliny czytnika karty kierowcy
lub współkierowcy).
ITS_15 Jeżeli karta do tachografu zostaje wyjęta, VU kończy połączenie
ITS Bluetooth®, które jest przypisane do tej karty.
ITS_16 VU obsługuje połączenie ITS z co najmniej jednym urządzeniem
ITS i może obsługiwać połączenia z wieloma urządzeniami ITS
w tym samym czasie.
ITS_17 Oprócz zgody kierowcy określonej w sekcji 3.4 niniejszego
dodatku, prawa dostępu do danych i usług dostępnych za pośred­
nictwem interfejsu ITS muszą być dodatkowo zgodne z wymogami
12 i 13 w załączniku IC.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 528
3.4. Dostępne dane i wymóg uzyskania zgody kierowcy
ITS_18 Wszystkie dane tachografu dostępne za pośrednictwem usług,
o których mowa w pkt 3.3, klasyfikuje się jako dane osobowe
albo nieosobowe w odniesieniu do kierowcy, współkierowcy lub
obu tych osób.
ITS_19 Za pośrednictwem interfejsu ITS udostępnia się przynajmniej
wykaz danych sklasyfikowanych w sekcji 4 jako dostępne
obowiązkowo.
ITS_20 Dane w sekcji 4, które sklasyfikowano jako „osobowe”, są
dostępne wyłącznie za zgodą kierowcy, który zaakceptował, że
dane osobowe mogą opuścić sieć pojazdu, z wyjątkiem przypadku
określonego w wymogu ITS_25, gdzie zgoda kierowcy nie jest
wymagana.
ITS_21 Dane dodatkowe w stosunku do danych zgromadzonych w pkt 4
i uznanych za obowiązkowe mogą być udostępniane poprzez inter­
fejs ITS. Dodatkowe dane, które nie są wymienione w pkt 4, są
klasyfikowane przez producenta VU jako „osobowe” lub „nieoso­
bowe”, co oznacza, że kierowca musi wyrazić zgodę na te dane,
które zostały sklasyfikowane jako dane osobowe, z wyjątkiem
przypadku określonego w wymogu ITS_25, gdzie zgoda kierowcy
nie jest wymagana.
ITS_22 Po włożeniu karty kierowcy, która nie jest znana przyrządowi
rejestrującemu, tachograf wzywa posiadacza karty do wprowa­
dzenia zgody na przesyłanie wyjściowych danych osobowych
poprzez interfejs ITS, zgodnie z wymogiem 61 w załączniku IC.
ITS_23 Status zgody (aktywny/nieaktywny) jest zapisywany w pamięci
danych przyrządu rejestrującego.
ITS_24 W przypadku wielu kierowców udostępnianiu poprzez interfejs ITS
podlegają wyłącznie dane osobowe dotyczące kierowców, którzy
wyrazili na to zgodę. Na przykład w przypadku załogi, jeżeli zgodę
wyraził tylko kierowca, dane osobowe współkierowcy nie są
udostępniane.
ITS_25 Jeżeli VU znajduje się w trybie kontrolnym, firmowym lub kalib­
racyjnym, prawami dostępu poprzez interfejs ITS zarządza się
zgodnie z wymogami 12 i 13 w załączniku IC, w związku
z czym zgoda kierowcy nie jest wymagana.
4. WYKAZ DANYCH DOSTĘPNYCH ZA POŚREDNICTWEM INTER­
FEJSU ITS ORAZ KLASYFIKACJA DANYCH JAKO OSOBOWE/
NIEOSOBOWE
Nazwa danych Format danych Źródło
Klasyfikacja danych (osobowe/nieoso­
bowe) Zgoda na udostęp­
nienie danych
Dostępność
kierowca współkierowca
VehicleIdentification­
Number
Dodatek 8 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
CalibrationDate ISO 16844-7 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
TachographVehicle
Speed
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy obowiąz­
kowo
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 529
Nazwa danych Format danych Źródło
Klasyfikacja danych (osobowe/nieoso­
bowe) Zgoda na udostęp­
nienie danych
Dostępność
kierowca współkierowca
Driver1WorkingState ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy obowiąz­
kowo
Driver2WorkingState ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
obowiąz­
kowo
DriveRecognize ISO 16844-7 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
Driver1TimeRelated­
States
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy obowiąz­
kowo
Driver2TimeRelated­
States
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
obowiąz­
kowo
DriverCardDriver1 ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy obowiąz­
kowo
DriverCardDriver2 ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
obowiąz­
kowo
OverSpeed ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy obowiąz­
kowo
TimeDate Dodatek 8 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
HighResolutionTotal­
VehicleDistance
ISO 16844-7 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
HighResolutionTrip­
Distance
ISO 16844-7 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
ServiceComponentI­
dentification
ISO 16844-7 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
ServiceDelayCalendar­
TimeBased
ISO 16844-7 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
Driver1Identification ISO 16844-7 karta
kier­
owcy
osobowe nie dotyczy zgoda kierowcy obowiąz­
kowo
Driver2Identification ISO 16844-7 karta
kier­
owcy
nie dotyczy osobowe zgoda współkie­
rowcy
obowiąz­
kowo
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 530
Nazwa danych Format danych Źródło
Klasyfikacja danych (osobowe/nieoso­
bowe) Zgoda na udostęp­
nienie danych
Dostępność
kierowca współkierowca
NextCalibrationDate Dodatek 8 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
Driver1ContinuousDri­
vingTime
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy obowiąz­
kowo
Driver2ContinuousDri­
vingTime
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
obowiąz­
kowo
Driver1CumulativeB­
reakTime
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy obowiąz­
kowo
Driver2CumulativeB­
reakTime
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
obowiąz­
kowo
Driver1CurrentDuratio­
nOfSelectedActivity
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy obowiąz­
kowo
Driver2CurrentDuratio­
nOfSelectedActivity
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
obowiąz­
kowo
SpeedAuthorised Dodatek 8 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
TachographCardSlot1 ISO 16844-7 VU nieosobowe nie dotyczy zgoda niewyma­
gana
obowiąz­
kowo
TachographCardSlot2 ISO 16844-7 VU nie dotyczy nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
Driver1Name ISO 16844-7 karta
kier­
owcy
osobowe nie dotyczy zgoda kierowcy obowiąz­
kowo
Driver2Name ISO 16844-7 karta
kier­
owcy
nie dotyczy osobowe zgoda współkie­
rowcy
obowiąz­
kowo
OutOfScopeCondition ISO 16844-7 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
ModeOfOperation ISO 16844-7 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
Driver1CumulatedDri­
vingTimePreviousAn­
dCurrentWeek
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy obowiąz­
kowo
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 531
Nazwa danych Format danych Źródło
Klasyfikacja danych (osobowe/nieoso­
bowe) Zgoda na udostęp­
nienie danych
Dostępność
kierowca współkierowca
Driver2CumulatedDri­
vingTimePreviousAn­
dCurrentWeek
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
obowiąz­
kowo
EngineSpeed ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
RegisteringMember­
State
Dodatek 8 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
VehicleRegistration­
Number
Dodatek 8 VU nieosobowe nieosobowe zgoda niewyma­
gana
obowiąz­
kowo
Driver1EndOfLastDai­
lyRestPeriod
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2EndOfLastDai­
lyRestPeriod
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1EndOfLas­
tWeeklyRestPeriod
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2EndOfLas­
tWeeklyRestPeriod
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1EndOfSecond­
LastWeeklyRestPeriod
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2EndOfSecond­
LastWeeklyRestPeriod
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1CurrentDaily
DrivingTime
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2CurrentDaily
DrivingTime
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1CurrentWee­
klyDrivingTime
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2CurrentWee­
klyDrivingTime
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 532
Nazwa danych Format danych Źródło
Klasyfikacja danych (osobowe/nieoso­
bowe) Zgoda na udostęp­
nienie danych
Dostępność
kierowca współkierowca
Driver1TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1CardExpiry­
Date
ISO 16844-7 karta
kier­
owcy
osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2CardExpiry­
Date
ISO 16844-7 karta
kier­
owcy
nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1CardNextMan­
datoryDownloadDate
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2CardNextMan­
datoryDownloadDate
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
TachographNextMan­
datoryDownloadDate
ISO 16844-7 VU nieosobowe nieosobowe zgoda niewyma­
gana
opcjonalnie
Driver1TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1Number
OfTimes9hDaily
DrivingTimesExceeded
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2Number
OfTimes9hDaily
DrivingTimesExceeded
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1Cumulative
UninterruptedRestTime
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2Cumulative
UninterruptedRestTime
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1Minimum
DailyRest
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2Minimum
DailyRest
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 533
Nazwa danych Format danych Źródło
Klasyfikacja danych (osobowe/nieoso­
bowe) Zgoda na udostęp­
nienie danych
Dostępność
kierowca współkierowca
Driver1Minimum
WeeklyRest
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2Minimum
WeeklyRest
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1Maximum
DailyPeriod
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2Maximum
DailyPeriod
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1Maximum
DailyDrivingTime
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2Maximum
DailyDrivingTime
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1NumberOf
UsedReducedDaily
RestPeriods
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2NumberOf
UsedReducedDaily
RestPeriods
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
Driver1Remaining
CurrentDrivingTime
ISO 16844-7 VU osobowe nie dotyczy zgoda kierowcy opcjonalnie
Driver2Remaining
CurrentDrivingTime
ISO 16844-7 VU nie dotyczy osobowe zgoda współkie­
rowcy
opcjonalnie
VehiclePosition Dodatek 8 VU osobowe osobowe zgoda kierowcy
i współkierowcy
obowiąz­
kowo
ByDefaultLoadType Dodatek 8 VU osobowe osobowe zgoda kierowcy
i współkierowcy
obowiąz­
kowo
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 534
Dodatek 14
FUNKCJA ŁĄCZNOŚCI NA ODLEGŁOŚĆ
SPIS TREŚCI
1 WPROWADZENIE
2 ZAKRES
3 SKRÓTY, DEFINICJE I OZNACZENIA
4 SCENARIUSZE OPERACYJNE
4.1 Informacje ogólne
4.1.1 Warunki wstępne dotyczące przesyłania danych za poś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 — 21.08.2023 — 003.002 — 535
5.5 Zarezerwowane dla przyszłego użytku
▼B
5.6 Przesyłanie danych pomiędzy DSRC-VU a VU
5.6.1 Połączenie fizyczne i interfejsy
5.6.2 Protokół aplikacji
5.7 Obsługa błędów
5.7.1 Rejestrowanie i przekazywanie danych w DSRC-VU
5.7.2 Błędy łączności bezprzewodowej
6 TESTY PRZEPROWADZANE PRZY ODDANIU DO EKSPLOA­
TACJI ORAZ TESTY W RAMACH PRZEGLĄDÓW OKRESO­
WYCH FUNKCJI ŁĄCZNOŚCI NA ODLEGŁOŚĆ
6.1 Uwagi ogólne
6.2 ECHO
6.3 Testy mające na celu zatwierdzanie treści zabezpieczonych 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ą­
dzenie”).
DSC_1 Zgodnie z rozporządzeniem (UE) nr 165/2014 tachograf musi
być wyposażony w funkcję łączności na odległość, aby
zapewnić przedstawicielom właściwych organów kontrolnych
możliwość odczytywania informacji przekazywanych przez
tachograf zainstalowany w przejeżdżających pojazdach za
pomocą urządzeń zdalnej kontroli („czytnik wczesnego wykry­
wania na odległość” (REDCR)), a w szczególności w urzą­
dzenia kontroli łączące się bezprzewodowo za pośrednictwem
interfejsów dedykowanej łączności krótkiego zasięgu (DSRC)
pracujących na częstotliwości CEN 5,8 GHz.
Należy pamiętać, że opisana funkcja jest wykorzystywana
wyłącznie w celu wstępnej selekcji pojazdów, które zostaną
wybrane do bardziej szczegółowej kontroli; nie zastępuje ona
formalnego przeglądu przeprowadzanego zgodnie z przepisami
rozporządzenia (UE) nr 165/2014. Zobacz motyw 9 w pream­
bule do tego rozporządzenia, w którym stwierdza się, że łącz­
ność na odległość między tachografem a organami kontro­
lnymi na potrzeby kontroli drogowych usprawnia ukierunko­
wane kontrole drogowe.
DSC_2 Dane wymienia się za pomocą Łączności, tj. bezprzewodowej
wymiany informacji za pośrednictwem systemu łączności
bezprzewodowej DSRC operującego na częstotliwości 5,8 GHz
prowadzonej zgodnie z niniejszym dodatkiem, która jest spraw­
dzana pod kątem zgodności z odpowiednimi parametrami prze­
widzianymi w normie 300 674-1 {Kwestie dotyczące kompaty­
bilności elektromagnetycznej i widma radiowego (ERM); telema­
tyka transportu i ruchu drogowego (RTTT); dedykowana łącz­
ność krótkiego zasięgu (DSRC) utrzymywana za pośrednictwem
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 536
urządzeń transmisyjnych (500 kbit/s / 250 kbit/s) działających na
częstotliwości 5,8 GHz w paśmie przeznaczonym do zastosowań
przemysłowych, naukowych i medycznych (ISM); Część 1:
Charakterystyka ogólna przyrządów instalowanych na poboczu
(RSU) oraz przyrządów instalowanych w pojeździe (OBU)
i metody kontrolowania tych przyrządów}.
DSC_3 Łączność nawiązuje się za pośrednictwem urządzeń do łącz­
ności wyłącznie po otrzymaniu sygnału wyemitowanego przez
urządzenia właściwego organu kontrolnego przy wykorzys­
taniu zgodnych środków łączności radiowej („czytnik wczes­
nego wykrywania na odległość” (REDCR)).
DSC_4 Dane zabezpiecza się w celu zapewnienia ich integralności.
DSC_5 Dostęp do przesyłanych Danych jest ograniczony do właści­
wych organów kontrolnych upoważnionych do kontroli naru­
szeń rozporządzenia (WE) nr 561/2006 i rozporządzenia (UE)
nr 165/2014 oraz do warsztatów w zakresie niezbędnym do
sprawdzenia poprawnego funkcjonowania tachografu.
DSC_6 Dane przesyłane w trakcie utrzymywania Łączności ograni­
czają się do danych niezbędnych na potrzeby ukierunkowa­
nych kontroli drogowych pojazdów wyposażonych w tacho­
grafy, które mogły zostać niewłaściwie użyte lub stać się
przedmiotem manipulacji.
DSC_7 Integralność i bezpieczeństwo Danych zapewnia się, zabezpie­
czając Dane przechowywane w przyrządzie rejestrującym (VU)
i przekazując wyłącznie zabezpieczone dane ładunku i dane
dotyczące zabezpieczeń za pośrednictwem urządzeń bezprzewo­
dowej łączności na odległość DSRC działających na częstotli­
wości 5,8 GHz (zob. pkt 5.4.4), co oznacza, że tylko upoważ­
nieni pracownicy właściwych organów kontrolnych są w stanie
zrozumieć dane przekazywane w trakcie utrzymywania Łącz­
ności i są w stanie zweryfikować ich autentyczność. Zob.
Dodatek 11 – Wspólne mechanizmy zabezpieczenia.
DSC_8 Dane muszą zawierać znacznik czasu określający datę
i godzinę ich ostatniej aktualizacji.
DSC_9 Treść danych zabezpieczających jest znana wyłącznie
właściwym organom kontrolnym i tym stronom, którym
organy udostępniają te informacje, oraz pozostaje pod ich
kontrolą; treść takich danych wykracza poza zakres przepisów
dotyczących Łączności będących przedmiotem niniejszego
dodatku z wyjątkiem zakresu, w jakim Łączność zabezpiecza
przesyłanie pakietu danych zabezpieczających z każdym
pakietem danych ładunku.
DSC_10 Należy zapewnić możliwość wykorzystania tej samej 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 5,8
GHz, aby zdalnie pozyskiwać z pojazdu docelowego dane („Dane”)
wskazujące, że taki pojazd może potencjalnie naruszać przepisy
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 537
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
dotyczyć danych potwierdzających, że mogło dojść do naruszenia
praw, zgodnie z definicją przedstawioną w art. 9 rozporządzenia (UE)
nr 165/2014.
▼M1
W takim przypadku czas dostępny na nawiązanie łączności jest 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 Łącz­
noś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 — 21.08.2023 — 003.002 — 538
— 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łca­
jące energię elektryczną w fale
radiowe i vice versa, wykorzysty­
wane w połączeniu z nadajnikiem
radiowym lub odbiornikiem
radiowym. W trakcie pracy nadajnik
radiowy generuje drgania elek­
tryczne o częstotliwości fal radio­
wych, które trafiają do gniazd ante­
nowych, a antena emituje energię
pozyskiwaną z prądu w formie fal
elektromagnetycznych (fal radio­
wych). Przyjmując fale radiowe,
antena przechwytuje część energii
z fali elektromagnetycznej
i wytwarza niewielkie napięcie
w gniazdach antenowych, które jest
następnie przesyłane do odbiornika
w celu wzmocnienia;
Łączność wymiana informacji/danych między
DSRC-REDCR a DSRC-VU zgodnie
z przepisami sekcji 5 w trybie
nadrzędny-podrzędny prowadzona
w celu pozyskania Danych;
Dane zabezpieczone dane o określonym
formacie (zob. pkt 5.4.4) żądane
przez DSRC–REDCR i przekazane
przez DSR-VU za pośrednictwem
DSRC działającego na częstotli­
wości 5,8 GHz określonego w pkt
5 poniżej;
Rozporządzenie (WE) nr 165/2014 Rozporządzenie Parlamentu Euro­
pejskiego i Rady (UE) nr 165/2014
z dnia 4 lutego 2014 r. w sprawie
tachografów stosowanych w trans­
porcie drogowym i uchylające
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 539
rozporządzenie
Rady (EWG) nr 3821/85 w sprawie
urządzeń rejestrujących stosowanych
w transporcie drogowym oraz zmie­
niające rozporządzenie (WE)
nr 561/2006 Parlamentu Europej­
skiego i Rady w sprawie harmoni­
zacji niektórych przepisów socjal­
nych odnoszących się do transportu
drogowego;
AID identyfikator aplikacji
BLE Bluetooth Low Energy (łączność
Bluetooth przy znikomym poborze
prądu)
BST tabela usług sygnału
CIWD włożenie karty podczas prowadzenia
pojazdu
CRC cykliczna kontrola nadmiarowa
DSC (n) identyfikator wymogu związanego
z określonym dodatkiem doty­
czącym DSRC
DSRC dedykowana łączność krótkiego
zasięgu
DSRC-REDCR DSRC–czytnik wczesnego wykry­
wania na odległość
DSRC-VU DSRC–przyrząd rejestrujący. Jest to
„urządzenie wczesnego wykrywania
na odległość” zdefiniowana
w załączniku 1C
DWVC prowadzenie pojazdu bez ważnej
karty
EID identyfikator elementu
LLC sterowanie połączeniem logicznym
LPDU jednostka danych protokołu LLC
OWS system ważenia zainstalowany
w pojeździe
PDU jednostka danych protokołu
REDCR czytnik wczesnego wykrywania na
odległość. Jest to „urządzenie
służące jako czytnik wczesnego
wykrywania na odległość” zdefinio­
wane w załączniku 1C
RTM zdalne monitorowanie tachografu
SM-REDCR moduł zabezpieczeń–czytnik wczes­
nego wykrywania na odległość
TARV aplikacje telematyczne dla pojazdów
regulowanych (seria norm ISO
15638)
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 540
VU przyrząd rejestrujący
VUPM pamięć ładunku przyrządu rejestru­
jącego
VUSM moduł zabezpieczeń przyrządu rejes­
trującego
VST tabela usług pojazdu
WIM ważenie w ruchu
WOB ważenie w pojeździe
Specyfikacje określone w niniejszym dodatku odnoszą się do 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 trans­
porcie drogowym oraz zmieniające rozporządzenie (WE)
nr 561/2006 Parlamentu Europejskiego i Rady w sprawie harmo­
nizacji niektórych przepisów socjalnych odnoszących się do 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 — 21.08.2023 — 003.002 — 541
[7] normę EN 12795 „Telematyka transportu i ruchu drogowego –
Wydzielona komunikacja krótkiego zasięgu (DSRC) – Warstwa
łącza danych DSRC: sterowanie dostępem nośnika i łączem
logicznym”;
[8] normę EN 12834 „Telematyka transportu i ruchu drogowego –
Wydzielona komunikacja krótkiego zasięgu (DSRC) – Warstwa
aplikacyjna DSRC”;
[9] normę EN 13372 „Telematyka transportu i ruchu drogo­
wego (RTTT) – Wydzielona komunikacja krótkiego zasięgu –
Profile zastosowań RTTT”;
[10] normę ISO 14906 „Elektroniczny system pobierania opłat – 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 — 21.08.2023 — 003.002 — 542
4.1.1.3 Zawartość Danych
DSC_15 Treść i format Danych powinny pozwalać na to, aby po ich
odszyfrowaniu zachowały one odpowiednią strukturę i pozos­
tały dostępne w formie i formacie określonych w pkt 5.4.4
niniejszego dodatku (struktury Danych).
4.1.1.4 Przedstawienie Danych
DSC_16 Dane, który były regularnie aktualizowane zgodnie z procedu­
rami przewidzianymi w pkt 4.1.1.1, zabezpiecza się przed ich
przedstawieniem DSRC-VU, a następnie przedstawia jako
wartość koncepcji danych zabezpieczonych w celu ich tymcza­
sowego przechowania w DSRC-VU jako aktualną wersję
Danych. Dane te przekazuje się z VUSM do funkcji DSRC
VUPM. VUSM i VUPM to funkcje, które niekoniecznie
muszą mieć postać fizyczną. Forma fizycznej konkretyzacji
służącej wykonywaniu tych funkcji jest kwestią projektu
produktu, chyba że została określona w innym miejscu
w rozporządzeniu (UE) nr 165/2014.
4.1.1.5 Dane zabezpieczające
▼M3
DSC_17 Dane zabezpieczające (DSRCSecurityData), obejmujące
żądane przez REDCR dane niezbędne do zapewnienia mu
możliwości odszyfrowania Danych przekazuje się zgodnie
z przepisami dodatku 11 „Wspólne mechanizmy zabezpie­
czenia”, w celu ich tymczasowego przechowania w DSRC-
VU jako aktualną wersję DSRCSecurityData, w formie okre­
ślonej w sekcji 5.4.4 niniejszego dodatku.
▼B
4.1.1.6 Dane VUPM dostępne do przekazywania za pośrednictwem 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
zgodności z odpowiednimi parametrami przewidzianymi w normie EN
300 674-1, jak opisano w sekcji 5) (REDCR) w celu zdalnego zidenty­
fikowania pojazdu, który może potencjalnie naruszać przepisy
rozporządzenia (UE) nr 165/2014. Po zidentyfikowaniu pojazdu przed­
stawiciel 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 — 21.08.2023 — 003.002 — 543
Rysunek 14.1
Kontrola drogowa przeprowadzana przy wykorzystaniu interfejsów DSRC
działających na częstotliwości 5,8 GHz
4.1.3 Profil 1b: Kontrole przeprowadzane przy wykorzystaniu ukierunkowa­
nego czytnika wczesnego wykrywania na odległość (REDCR) zainstalo­
wanego w pojeździe
W przedmiotowym przypadku wykorzystania przedstawiciel właś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 — 21.08.2023 — 003.002 — 544
Rys. 14.3
Projekt funkcji łączności na odległość
DSC_19 W VU zlokalizowane są następujące funkcje:
— moduł zabezpieczeń (VUSM). Ta funkcja występująca
w VU jest odpowiedzialna za zabezpieczanie Danych prze­
syłanych z DSRC-VU do przedstawiciela właściwych
organów kontrolnych za pośrednictwem łączności na odle­
głość;
— zabezpieczone dane są przechowywane w pamięci VUSM.
W odstępach czasu określonych w pkt 4.1.1.1 (DSC_12)
VU szyfruje i uzupełnia koncepcję RTMdata (która obej­
muje wartości koncepcji danych ładunku i danych zabez­
pieczających określone poniżej w tym dodatku) przecho­
wywaną w pamięci DSRC-VU. Działanie modułu zabez­
pieczeń jest zdefiniowane w dodatku 11 „Wspólne mecha­
nizmy zabezpieczenia” i wykracza poza zakres niniejszego
dodatku, z zastrzeżeniem konieczności zapewnienia aktua­
lizacji urządzenia do łączności VU za każdym razem, gdy
zmieniają się dane VUSM;
— łączność między VU a DSRC-VU może być łącznością
przewodową lub łącznością opartą na technologii
Bluetooth Low Energy (BLE), a jeżeli chodzi o fizyczną
lokalizację DSRC-VU, może być ono zintegrowane
z anteną umieszczoną na szybie przedniej pojazdu, może
znajdować się wewnątrz VU lub może być umieszczone
gdzieś pomiędzy;
— DSRC-VU posiada niezawodne źródło energii dostępne
w każdej chwili. Sposób zasilania energią zależy od
projektu;
— pamięć DSRC-VU jest pamięcią trwałą w celu utrzymania
danych w DSRC-VU, nawet gdy zapłon pojazdu jest wyłą­
czony;
— jeżeli łączność między VU a DSRC-VU odbywa się za
pośrednictwem technologii BLE, a źródłem zasilania jest
akumulator, którego nie można ponownie naładować,
źródło zasilania DSRC-VU zastępuje się podczas każdego
przeglądu okresowego, a producent urządzenia DSRC-VU
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 545
jest odpowiedzialny za zapewnienie odpowiedniego zasi­
lania energią między jednym przeglądem okresowym
a drugim, utrzymując normalny dostęp do danych przez
REDCR przez cały okres bez awarii lub przerwania
dostaw;
— funkcja VU umożliwiająca zdalne monitorowanie tacho­
grafu i wyposażona w „pamięć na temat ładunków”
(VUPM). Ta funkcja występująca w VU jest odpowie­
dzialna za dostarczanie i aktualizację Danych. Treść
Danych („TachographPayload”) jest zdefiniowana w pkt
5.4.4/5.4.5 poniżej i jest aktualizowana w odstępach
czasu określonych w pkt 4.1.1.1 (DSC_12);
— DSRC-VU. Jest to funkcja w obrębie anteny lub połączona
z anteną i nawiązująca łączność z VU za pośrednictwem
połączenia przewodowego lub bezprzewodowego (BLE),
które posiada aktualne dane (dane VUPM) i zarządza
odpowiedziami na kontrolę prowadzoną przez nośnik
DSRC działający na częstotliwości 5,8 GHz. Odłączenie
urządzenia DSRC lub zakłócenie jego funkcjonowania
podczas normalnej eksploatacji pojazdu z działającym
urządzeniem DSRC interpretuje się jako naruszenie prze­
pisów rozporządzenia (UE) nr 165/2014;
— moduł zabezpieczeń (REDCR) (SM-REDCR) to funkcja
wykorzystywana do deszyfrowania i sprawdzania integral­
ności danych pochodzących z VU. Środki umożliwiające
osiągnięcie tego celu określono w dodatku 11 Wspólne
mechanizmy zabezpieczenia, a nie w niniejszym dodatku;
— urządzenie DSRC (REDCR) (DSRC-REDCR) obejmuje
nadajnik-odbiornik działający na częstotliwości 5,8 GHz
i powiązane oprogramowanie wbudowane i oprogramo­
wanie zwykłe, które zarządza Łącznością z DSRC-VU
zgodnie z niniejszym dodatkiem;
— DSRC-REDCR wysyła zapytania do DSRC-VU w doce­
lowym pojeździe i pozyskuje Dane (bieżące dane VUPM
docelowego pojazdu) za pośrednictwem łącza DSRC oraz
przetwarza i przechowuje otrzymane dane w swoim SM-
REDCR;
▼M1
— antenę DSRC-VU umieszcza się w miejscu, w którym
zapewnia optymalną łączność DSRC między pojazdem
a anteną drogową czytnika, w przypadku gdy czytnik
został zainstalowany w odległości 15 m z przodu pojazdu
i na wysokości 2 m, możliwie blisko środkowej części
szyby w poziomie i w pionie. W przypadku pojazdów
lekkich odpowiednie jest zainstalowanie anteny w górnej
części szyby przedniej W przypadku pozostałych pojazdów
antenę DSRC należy zamontować w pobliżu dolnej albo
górnej części szyby przedniej.
▼B
DSC_20 Antena i Łączność działają w ramach ERC 70-03, są spraw­
dzane pod kątem zgodności z odpowiednimi parametrami
przewidzianymi w normie EN 300 674-1, jak opisano w sekcji
5. W odniesieniu do anteny i Łączności można wdrożyć tech­
niki ograniczania ryzyka wystąpienia zakłóceń bezprzewodo­
wych, jak opisano w sprawozdaniu ECC nr 228, przy użyciu
np. filtrów w łączności CEN DSRC 5.8 GHz.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 546
DSC_21 Antena DSRC jest połączona z funkcją DSRC-VU bezpo­
średnio w obrębie modułu zamontowanego na szybie przedniej
lub blisko szyby przedniej lub poprzez dedykowany przewód
zbudowany w taki sposób, aby utrudnić nielegalne odłączenie.
Odłączenie lub zakłócenie funkcjonowania anteny stanowi
naruszenie przepisów rozporządzenia (UE) nr 165/2014.
Zamierzone maskowanie lub inne szkodliwe oddziaływanie
na funkcjonowanie anteny interpretuje się jako naruszenie
przepisów rozporządzenia (UE) nr 165/2014.
DSC_22 ►M1 Współczynnik kształtu anteny nie został zdefiniowany
i stanowi przedmiot decyzji handlowej, dopóki wbudowany
DSRC-VU spełnia wymagania zgodności określone w sekcji
5 poniżej. Antena jest umieszczona w miejscu określonym
w DSC_19 i skutecznie wspomaga przypadki wykorzystania
opisane w pkt 4.1.2 i 4.1.3. ◄
Rys. 14.4
Przykładowe umieszczenie anteny DSRC działającej na
częstotliwości 5,8 GHz na szybie przedniej pojazdów regulowanych
Współczynnik kształtu REDCR i jego anteny może różnić się w zależ­
ności od położenia czytnika (zamontowany statyw, urządzenie rę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
ekranie, w formie wydruku, sygnału audio lub połączenia takich powia­
domień. 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
maksymalną elastyczność rynku w zakresie zaprojektowania
i zapewnienia urządzenia mającego na celu zrealizowanie
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 547
określonych scenariuszy kontroli dowolnego właściwego
organu kontrolnego.
DSC_24 Współczynnik projektu i kształtu DSRC-VU i jego pozycjono­
wanie wewnątrz lub na zewnątrz VU stanowią funkcję
projektu komercyjnego, funkcjonującego w ramach ERC 70-
03, oraz specyfikacji projektu i eksploatacji określonej
w niniejszym dodatku (sekcja 5.3.2) i w obrębie tej klauzuli
(5.1).
DSC_25 W rozsądnym stopniu DSRC-VU musi być jednak w stanie
zaakceptować wartości koncepcji danych z innego inteligen­
tnego urządzenia rejestrującego za pomocą otwartego standar­
dowego połączenia branżowego i protokołów (na przykład
z urządzenia służącego do ważenia w pojeździe), dopóki
takie koncepcje danych są określone unikatowymi i znanymi
identyfikatorami aplikacji / nazwami plików, zaś instrukcje
obsługi takich protokołów są udostępniane Komisji Europej­
skiej i są dostępne bezpłatnie dla producentów odpowiednich
urządzeń.
5.2 Przepływ pracy
5.2.1 Operacje
Na rys. 14.5 przedstawiono przepływ pracy w odniesieniu do operacji.
Rys. 14.5
Przepływ pracy w odniesieniu do funkcji łączności na odległość
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 548
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
przechowywane w pamięci DSRC-VU (jak określono w pkt
4.1.1.1–4.1.1.2). Zebrane Dane formatuje się w sposób określony
w pkt 5.4.4–5.4.5 poniżej;
b. przy każdej aktualizacji Danych aktualizuje się znacznik czasu okre­
ślony w koncepcji danych zabezpieczających;
c. funkcja VUSM zabezpiecza dane zgodnie z procedurami określonymi
w dodatku 11;
d. przy każdej aktualizacji Danych (zob. pkt 4.1.1.1–4.1.1.2) Dane
przesyła się do DSRC-VU, gdzie zastępują one wszystkie 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 deszyfrowanie 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
przekazania Danych. Dane są przesyłane do REDCR za pośrednic­
twem systemu łączności bezprzewodowej jako atrybut DSRC korzys­
tający z usługi aplikacyjnej GET, jak określono w 5.4. Atrybut
zawiera zaszyfrowane wartości danych ładunku oraz dane zabezpie­
czające DSCR;
g. dane są analizowane przez urządzenie REDCR i przekazywane
przedstawicielowi właściwego organu kontrolnego;
h. przedstawiciel właściwego organu kontrolnego wykorzystuje dane do
podjęcia decyzji o ewentualnym zatrzymaniu pojazdu do szczegó­
łowej kontroli lub zwrócenia się do innego przedstawiciela właści­
wego organu kontrolnego o zatrzymanie pojazdu.
5.2.2 Interpretacja danych otrzymanych za pośrednictwem łączności DSRC
DSC_26 Dane otrzymywane przez interfejs działający na czę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ę
jedynie w celu przekazania odpowiednich informacji właści­
wemu organowi kontrolnemu, aby pomóc mu w ustaleniu,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 549
czy należy zatrzymać pojazd do kontroli fizycznej, a następnie
Dane te są niszczone zgodnie z art. 9 rozporządzenia (UE)
nr 165/2014.
5.3 Parametry interfejsu fizycznego DSRC w odniesieniu do łączności na
odległość
5.3.1 Ograniczenia dotyczące lokalizacji
DSC_27 Zdalnej kontroli pojazdów korzystających z interfejsu 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
(nielicencjonowanego)
i rozporządzenia krajowego
Maksymalna wartość + 33
dBm
(zgodnie z normą EN 12253)
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 550
Nr pozycji Parametr Wartości Uwagi
D4a Maska kątowa EIRP Zgodnie z zadeklarowaną
i opublikowaną specyfi­
kacją projektanta interroga­
tora
(zgodnie z normą EN 12253)
D5 Polaryzacja Lewostronna kołowa (zgodnie z normą EN 12253)
D5a Polaryzacja krzyżowa XPD:
Na obszarze pokrycia:
(REDCR) RSU t ≥ 15 dB
(DSRC-VU) OBU r ≥ 10 dB
Na obszarze -3 dB:
(REDCR) RSU t ≥ 10 dB
(DSRC-VU) OBU r ≥ 6 dB
(zgodnie z normą EN 12253)
D6 (*) Modulacja Dwupoziomowa modulacja
amplitudy
(zgodnie z normą EN 12253)
D6a (*) Indeks modulacji 0,5 … 0,9 (zgodnie z normą EN 12253)
D6b Wzorzec ruchu gałek
ocznych
≥90 % (czas) / ≥85 %
(amplituda)
D7 (*) Kodowanie danych FM0
Bit „1” posiada przejścia
jedynie na początku
i końcu interwału bitowego.
Bit „0” posiada dodatkowe
przejście w środku inter­
wału bitowego w porów­
naniu z bitem „1”.
(zgodnie z normą EN 12253)
D8 (*) Szybkość transmisji bitów 500 kBit/s (zgodnie z normą EN 12253)
D8a Tolerancja zegara częstotli­
wości
wyższa niż ± 100 ppm (zgodnie z normą EN 12253)
D9 (*) Bitowa stopa błędów (BER)
w odniesieniu do łączności
≤ 10 – 6 , gdy moc padająca
w przyrządzie instalo­
wanym w pojeździe
(DSRC-VU) mieści się
w zakresie podanym w pkt
[D11a–D11b].
(zgodnie z normą EN 12253)
D10 Czynnik uruchamiający
OBU (DSRC-VU)
OBU (DSRC-VU)
uruchamia się po otrzy­
maniu dowolnej ramki
zawierającej co najmniej
11 oktetów (w tym pream­
bułę)
Nie jest konieczny żaden specjalny
wzór uruchamiania.
DSRC-VU może uruchomić się po
otrzymaniu ramki zawierającej
mniej niż 11 oktetów
(zgodnie z normą EN 12253)
D10a Maksymalna godzina rozpo­
częcia
≤5 ms (zgodnie z normą EN 12253)
D11 Strefa łączności Region przestrzenny,
w którym osiąga się BER
zgodną z D9a
(zgodnie z normą EN 12253)
D11a (*) Limit zasilania w odnie­
sieniu do łączności (górna)
– 24 dBm (zgodnie z normą EN 12253)
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 551
Nr pozycji Parametr Wartości Uwagi
D11b (*) Limit zasilania w odnie­
sieniu do łączności (dolna)
Moc zdarzenia:
– 43 dBm (obszar pokrycia)
– 41 dBm (w przedziale
– 45° ± 45° odpowiada­
jącym płaszczyźnie równo­
ległej do powierzchni drogi,
gdy DSRC-VU jest później
instalowany w pojeździe
(azymut))
(zgodnie z normą EN 12253)
Rozszerzony wymóg w odniesieniu
do kątów poziomych do ±45°, ze
względu na przypadki wykorzys­
tania zdefiniowane w niniejszym
załączniku.
D12 (*) Poziom odcięcia zasilania
(DSRC-VU)
– 60 dBm (zgodnie z normą EN 12253)
D13 Preambuła Preambuła jest obowiąz­
kowa.
(zgodnie z normą EN 12253)
D13a Długość i wzór preambuły 16 bitów ± 1 bit FM0 zako­
dowany jako bity „1”
(zgodnie z normą EN 12253)
D13b Kształt fali preambuły Sekwencja naprzemienna
o niskim i wysokim
poziomie z czasem trwania
impulsu równym 2 μs.
Tolerancja podana w D8a
(zgodnie z normą EN 12253)
D13c Bity pomocnicze RSU (REDCR) może prze­
słać maksymalnie 8 bitów
po fladze końcowej. Od
OBU (DSRC-VU) nie
wymaga się, aby uwzględ­
niał te dodatkowe bity.
(zgodnie z normą EN 12253)
(*) – Parametry łącza odbiorczego z zastrzeżeniem sprawdzenia 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 — 21.08.2023 — 003.002 — 552
Nr pozycji Parametr Wartości Uwagi
2) Moc na paśmie:
[U4a] dBm w 500 kHz
3) Emisja na dowolnym
innym kanale łącza
nadawczego:
U2(3)-1 = -35 dBm w
500 kHz
U4a (*) Maksymalna modulacja
jednowstęgowa EIRP
(obszar pokrycia)
Dwie opcje:
U4a-0: – 14 dBm
U4a-1: – 21 dBm
Zgodnie z zadeklarowaną i opubli­
kowaną specyfikacją projektanta
urządzenia
U4b (*) Maksymalna modulacja
jednowstęgowa EIRP (35°)
Dwie opcje:
— Nie dotyczy
— – 17 dBm
Zgodnie z zadeklarowaną i opubli­
kowaną specyfikacją projektanta
urządzenia
U5 Polaryzacja Lewostronna kołowa (zgodnie z normą EN 12253)
U5a Polaryzacja krzyżowa XPD:
Na obszarze pokrycia:
(REDCR) RSU r ≥ 15 dB
(DSRC-VU) OBU t ≥ 10 dB
Na obszarze – 3 dB:
(REDCR) RSU r ≥ 10 dB
(DSRC-VU) OBU t ≥ 6 dB
(zgodnie z normą EN 12253)
U6 Modulacja podnośna 2-PSK
Zakodowane dane zsyn­
chronizowane z częstotliwo­
ścią podnośną: przejścia
zakodowanych danych
zbieżne z przejściami częs­
totliwości podnośnej.
(zgodnie z normą EN 12253)
U6b Cykl roboczy Cykl roboczy:
50 % ± α, α ≤5 %
(zgodnie z normą EN 12253)
U6c Modulacja na nośniku Mnożenie modulowanej
częstotliwości podnośnej
przez częstotliwość nośną.
(zgodnie z normą EN 12253)
U7 (*) Kodowanie danych NRZI (Brak przejścia na
początku bitu „1”, przejście
na początku bitu „0”, brak
przejścia w ramach bitu)
(zgodnie z normą EN 12253)
U8 (*) Szybkość transmisji bitów 250 kBit/s (zgodnie z normą EN 12253)
U8a Tolerancja zegara częstotli­
wości
w ramach ± 1 000 ppm (zgodnie z normą EN 12253)
U9 Bitowa stopa błędów
(B.E.R.) w odniesieniu do
łączności
≤10 – 6 (zgodnie z normą EN 12253)
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 553
Nr pozycji Parametr Wartości Uwagi
U11 Strefa łączności Region przestrzenny,
w którym zlokalizowany
jest DSRC-VU, tak że jego
transmisje są odbierane
przez REDCR przy BER
mniejszej niż ta podana
w pkt U9a.
(zgodnie z normą EN 12253)
U12a (*) Zysk z konwersji (dolna
granica)
1 dB dla każdej wstęgi
bocznej Zakres kątowy:
kołowo-symetryczny
pomiędzy obszarem
pokrycia a ± 35°
oraz
w przedziale – 45° ± 45°
odpowiadającym płasz­
czyźnie równoległej do
powierzchni drogi, gdy
DSRC-VU jest później
instalowany w pojeździe
(azymut)
Większy niż określony zakres
wartości dla kątów poziomych do
± 45° ze względu na przypadki
wykorzystania zdefiniowane
w niniejszym załączniku.
U12b (*) Zysk z konwersji (górna
granica)
10 dB dla każdej wstęgi
bocznej
Niższy niż określony zakres
wartości dla każdej wstęgi bocznej
w obrębie stożka kołowego wokół
obszaru pokrycia ± 45° kąta
otwarcia.
U13 Preambuła Preambuła jest obowiąz­
kowa.
(zgodnie z normą EN 12253)
U13a Długość i wzór
preambuły
32–36 μs modulowane
jedynie przy użyciu częstot­
liwości podnośnej,
a następnie 8 bitów „0”
zakodowanych jako NRZI.
(zgodnie z normą EN 12253)
U13b Bity pomocnicze DSRC-VU może przesłać
maksymalnie 8 bitów po
fladze końcowej. Od
RSU (REDCR) nie wymaga
się, aby uwzględniał te
dodatkowe bity.
(zgodnie z normą EN 12253)
(*) – Parametry łącza nadawczego z zastrzeżeniem sprawdzenia 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 — 21.08.2023 — 003.002 — 554
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 warunkach idealnych,
bez retransmisji czy zakłóceń łączności.
UWAGA: celem etapu inicjacji (krok 1) jest ustanowienie
łączności między REDCR a DSRC-VU, które znalazły się
w strefie transakcji DSRC w częstotliwości 5,8 GHz (tryb
nadrzędny-podrzędny), ale jeszcze nie nawiązały łączności
z REDCR, a także zgłoszenie procesów aplikacji.
— Krok 1 Inicjacja. REDCR wysyła ramkę zawierającą
tabelę usług sygnału (BST), która zawiera identyfikatory
aplikacji (AID) w wykazie obsługiwanych usług. W apli­
kacji RTM będzie to po prostu usługa z wartością AID =
2 (Freight&Fleet). DSRC-VU dokonuje oceny otrzymanej
BST i odpowiada (zob. poniżej), przekazując wykaz
obsługiwanych aplikacji w ramach domeny
Freight&Fleet, lub nie odpowiada, jeżeli żadne aplikacje
nie są obsługiwane. Jeżeli REDCR nie oferuje AID=2,
DSRC-VU nie odpowiada REDCR.
— Krok 2 DSRC-VU wysyła ramkę zawierającą żądane
przydzielenia okna prywatnego.
— Krok 3 REDCR wysyła ramkę z przydziałem okna
prywatnego.
— Krok 4 DSRC-VU używa przydzielonego okna prywat­
nego do wysłania ramki zawierającej jego tabelę usług
pojazdu (VST). Tego rodzaju VST zawiera wykaz
wszystkich różnych wystąpień aplikacji obsługiwanych
przez ten DSRC-VU w ramach AID=2. Poszczególne
wystąpienia są identyfikowane za pomocą jednorazowo
generowanych identyfikatorów elementu, z których
każdy jest powiązany z wartością parametru znacznika
kontekstowego aplikacji określającą obsługiwaną apli­
kację i normę.
— Krok 5 Następnie REDCR analizuje oferowaną tabelę
usług pojazdu i albo przerywa łączność (RELEASE),
ponieważ nie jest zainteresowany niczym, co dana VST
ma do zaoferowania (tj. otrzymuje VST od DSRC-VU,
który nie obsługuje transakcji RTM), albo – jeżeli otrzy­
muje odpowiednią tabelę usług pojazdu – uruchamia
wystąpienie aplikacji.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 555
— Krok 6 Aby osiągnąć ten cel, REDCR wysyła ramkę
zawierającą polecenie pobrania danych dotyczących zdal­
nego monitorowania tachografu i identyfikującą wystą­
pienie aplikacji RTM poprzez wskazanie identyfikatora
odpowiadającego wystąpieniu aplikacji RTM (jak określił
DSRC-VU w VST) oraz przydziela okno prywatne.
— Krok 7 DSRC-VU używa nowo przydzielonego okna
prywatnego do wysłania ramki zawierającej adresowany
identyfikator odpowiadający wystąpieniu aplikacji RTM
zgodnie z VST, po którym następuje atrybut RtmData
(element ładunku + element bezpieczeństwa).
— Krok 8 W przypadku żądania wielu usług wartość „n”
zmienia się na kolejny numer referencyjny usługi i proce­
dura zostaje powtórzona.
— Krok 9 REDCR potwierdza otrzymanie danych, wysy­
łając do DSRC-VU ramkę zawierającą polecenie
RELEASE w celu przerwania sesji LUB, jeżeli nie
zatwierdził pomyślnego otrzymania LPDU, wraca do
kroku 6.
Zob. rys. 14.6 przedstawiający graficzny opis protokołu
transakcji.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 556
Rys. 14.6
Zdalne monitorowanie tachografu w ramach przepływu procesów DSRC na częstotliwości 5,8 GHz
5.4.2 Polecenia
DSC_35 Poniższe polecenia stanowią jedyne funkcje stosowane na
etapie transakcji RTM:
— INITIALISATION.request: polecenie wysyłane
z REDCR w formie emisji z definicją aplikacji obsługi­
wanych przez ten REDCR;
— INITIALISATION.response: odpowiedź z DSRC-VU
potwierdzająca połączenie i zawierająca wykaz obsługi­
wanych wystąpień aplikacji wraz z charakterystyką oraz
informacjami na temat sposobu postępowania z nimi (EID);
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 557
— 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 wybra­
nego(-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 komunika­
cyjnego odpowiedź
Jeżeli BST obsługuje AID=2,
to DSRC-VU żąda okna
prywatnego
3 REDCR > DSRC-VU Przyznaje okno prywatne Wysyła ramkę zawierającą
przydział okna prywatnego
4 DSRC-VU > REDCR Wysyła VST Wysyła ramkę zawierającą
VST
5 REDCR > DSRC-VU Wysyła GET.request
w odniesieniu do danych
zawartych w Atrybucie
dotyczącym konkretnego
EID
6 DSRC-VU > REDCR Wysyła GET.response
z żądanym atrybutem doty­
czącym konkretnego EID
Wysyła Atrybut (RTMData,
OWSData….) zawierający
dane dotyczące konkretnego
EID
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 558
Sekwencja Nadajnik Odbiornik Opis Działanie
▼M1
7 REDCR > DSRC-VU Wysyła GET.request
w odniesieniu do danych
innego Atrybutu (w razie
potrzeby)
▼B
8 DSRC-VU > REDCR Wysyła GET.response
z żądanym atrybutem
Wysyła Atrybut zawierający
dane dotyczące konkretnego
EID
9 REDCR > DSRC-VU Potwierdza pomyślne
otrzymanie danych
Wysyła polecenie RELEASE
zamykające transakcję
10 DSRC-VU Zamyka transakcję
Przykład sekwencji transakcji i zawartości wymienianych
ramek przedstawiono w pkt 5.4.7 i 5.4.8.
5.4.4 Struktury danych
DSC_37 Struktura semantyczna Danych przekazywanych przez inter­
fejs DSRC działający na częstotliwości 5,8 GHz jest zgodna
ze strukturą opisaną w niniejszym dodatku. Strukturę tych
danych przedstawiono w tym punkcie.
DSC_38 Ładunek (dane dotyczące zdalnego monitorowania tacho­
grafu) składa się z połączenia:
1. danych EncryptedTachographPayload stanowiących
zaszyfrowane dane TachographPayload określone w specy­
fikacji ASN.1 w sekcji 5.4.5. Metodę szyfrowania opisano
w dodatku 11;
2. danych DSRCSecurityData określonych w dodatku 11.
DSC_39 Dane dotyczące zdalnego monitorowania tachografu opisuje
się jako Atrybut RTM = 1 i przekazuje w kontenerze RTM
= 10.
DSC_40 Znacznik kontekstowy RTM określa obsługiwaną część
normy w serii norm TARV (RTM odnosi się do części 9).
Zawarta w module ASN.1 definicja danych DSRC w ramach
aplikacji RTM jest następująca:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 559
► (2) (3) M1
► (1) M3
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 560
5.4.5 Elementy danych dotyczących zdalnego monitorowania tachografu
(RtmData), wykonywane czynności i definicje
DSC_41 Wartości danych, które mają zostać obliczone przez VU
i wykorzystane do uaktualnienia zabezpieczonych danych
w DSRC-VU, oblicza się zgodnie z zasadami przedstawio­
nymi w tabeli 14.3:
▼M3
Tabela 14.3
Elementy RtmData, wykonywane czynności i definicje
1)
Element danych RTM
2)
Czynność wykonywana przez VU
3)
Definicja danych w ASN.1
RTM1
Tablica rejestracyjna
pojazdu
VU ustala wartość
tp15638VehicleRegistration­
Plate elementu danych
RTM1 na podstawie zareje­
strowanej wartości typu
danych
VehicleRegistrationIdentifica­
tion, jak określono w dodatku
1 VehicleRegistrationIdentifi­
cation
Numer tablicy rejestra­
cyjnej pojazdu wyrażony
jako ciąg znaków
tp15638VehicleRegistration­
Plate LPN,
–tablica rejestracyjna pojazdu
ze strukturą danych według
ISO 14906, ale z następu­
jącym ograniczeniem na
potrzeby aplikacji RTM:
SEKWENCJA rozpoczyna się
od kodu kraju, po którym
następuje wskaźnik alfabetu,
po którym następuje sam
numer tablicy,
który ma zawsze 14 oktetów
(wypełnionych zerami), tak
więc długość typu LPN
zawsze wynosi 17 oktetów
(determinant długości nie jest
potrzebny), z czego 14 to
„rzeczywisty” numer tablicy.
RTM2
Zdarzenia polegające na
przekroczeniu prędkości
VU generuje wartość
logiczną
w odniesieniu do elementu
danych RTM2
tp15638SpeedingEvent.
VU oblicza wartość
tp15638SpeedingEvent na
podstawie zdarzeń przekro­
czenia prędkości zarejestro­
wanych w VU w ciągu
ostatnich 10 dni, jak okre­
ślono w załączniku IC .
1 (PRAWDA): jeżeli
ostatnie zdarzenie prze­
kroczenia prędkości
zakończyło się w ciągu
ostatnich 10 dni lub trwa
nadal;
0 (FAŁSZ): w każdym
innym przypadku.
tp15638SpeedingEvent
BOOLEAN,
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 561
1)
Element danych RTM
2)
Czynność wykonywana przez VU
3)
Definicja danych w ASN.1
RTM3
Prowadzenie pojazdu
bez
ważnej karty
VU generuje wartość
logiczną
w odniesieniu do elementu
danych RTM3
tp15638DrivingWithoutVa­
lidCard.
VU przypisuje wartość
PRAWDA zmiennej
tp15638DrivingWithoutVa­
lidCard, jeżeli w VU zareje­
strowano co najmniej jedno
zdarzenie prowadzenia
pojazdu bez odpowiedniej
karty w ciągu ostatnich 10
dni, jak określono w załącz­
niku IC.
1 (PRAWDA): jeżeli
ostatnie zdarzenie
prowadzenia pojazdu bez
odpowiedniej karty
zakończyło się w ciągu
ostatnich 10 dni lub trwa
nadal;
0 (FAŁSZ): w każdym
innym przypadku.
tp15638DrivingWithoutValid­
Card
BOOLEAN,
RTM4
Ważna karta kierowcy
VU generuje wartość
logiczną w odniesieniu do
elementu danych RTM4
tp15638DriverCard na
podstawie ważnej karty
kierowcy włożonej w szcze­
linę czytnika karty kierowcy.
1 (PRAWDA): jeżeli
w szczelinie czytnika
karty kierowcy VU nie
ma ważnej karty
kierowcy;
0 (FAŁSZ): jeżeli
w szczelinie czytnika
karty kierowcy VU
znajduje się ważna karta
kierowcy.
tp15638DriverCard
BOOLEAN,
RTM5
Włożenie karty podczas
prowadzenia
pojazdu
VU generuje wartość
logiczną w odniesieniu do
elementu danych RTM5
tp15638CardInsertion.
VU przypisuje wartość
PRAWDA zmiennej
tp15638CardInsertion, jeżeli
w VU zarejestrowano co
najmniej jedno zdarzenie
włożenia karty podczas
prowadzenia pojazdu w ciągu
ostatnich 10 dni, jak okre­
ślono w załączniku IC.
1 (PRAWDA): Jeżeli
ostatnie zdarzenie
włożenia karty podczas
prowadzenia pojazdu
miało miejsce w ciągu
ostatnich 10 dni;
0 (FAŁSZ): w każdym
innym przypadku.
tp15638CardInsertion
BOOLEAN,
RTM6
Błąd danych dotyczą­
cych ruchu
VU generuje wartość
logiczną
w odniesieniu do elementu
danych RTM6.
VU przypisuje wartość
PRAWDA zmiennej
tp15638MotionDataError,
jeżeli w VU zarejestrowano
co najmniej jedno zdarzenie
błędu danych dotyczących
ruchu w ciągu ostatnich 10
dni, jak określono w załącz­
niku IC.
1 (PRAWDA): jeżeli
ostatnie zdarzenie błędu
danych dotyczących
ruchu zakończyło się
w ciągu ostatnich 10 dni
lub trwa nadal;
0 (FAŁSZ): w każdym
innym przypadku.
tp15638MotionDataError
BOOLEAN,
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 562
1)
Element danych RTM
2)
Czynność wykonywana przez VU
3)
Definicja danych w ASN.1
RTM7
Konflikt ruchu
pojazdu
VU generuje wartość
logiczną
w odniesieniu do elementu
danych RTM7.
VU przypisuje wartość
PRAWDA zmiennej
tp15638VehicleMotionCon­
flict, jeżeli w VU zarejestro­
wano co najmniej jedno
zdarzenie konfliktu ruchu
pojazdu w ciągu ostatnich 10
dni.
1 (PRAWDA): jeżeli
ostatnie zdarzenie
konfliktu ruchu pojazdu
zakończyło się w ciągu
ostatnich 10 dni lub trwa
nadal;
0 (FAŁSZ): w każdym
innym przypadku.
tp15638VehicleMotionConflict
BOOLEAN,
RTM8
Druga karta kierowcy
VU generuje wartość
logiczną
w odniesieniu do elementu
danych RTM8 na podstawie
załącznika IC („Dane doty­
czące czynności kierowcy”
w odniesieniu do ZAŁOGI
i WSPÓŁKIEROWCY).
W przypadku braku ważnej
karty współkierowcy VU
ustawia wartość RTM8 na
PRAWDA.
1 (PRAWDA): jeżeli
w VU znajduje się
ważna karta współkie­
rowcy;
2 (FAŁSZ): jeżeli w VU
nie ma ważnej karty
współkierowcy.
tp156382ndDriverCard
BOOLEAN,
RTM9
Bieżąca czynność
VU generuje wartość
logiczną
w odniesieniu do elementu
danych RTM9.
Jeżeli VU zarejestruje bieżącą
czynność jako jakąkolwiek
czynność inną niż PROWA­
DZENIE, jak określono
w załączniku IC, ustawia
wartość RTM9 na
PRAWDA.
1 (PRAWDA): inna
wybrana
czynność;
0 (FAŁSZ): wybór
czynności „prowa­
dzenie”
tp15638CurrentActivityDri­
ving
BOOLEAN
RTM10
Zamknięcie ostatniej
sesji
VU generuje wartość
logiczną w odniesieniu do
elementu danych RTM10.
Jeżeli ostatnia sesja karty nie
została prawidłowo
zamknięta zgodnie z proce­
durą opisaną w załączniku
IC, VU ustawia wartość
RTM10 na PRAWDA.
1 (PRAWDA): co
najmniej jedna z włożo­
nych kart wywołała błąd
niepoprawnego
zamknięcia ostatniej sesji
karty;
0 (FAŁSZ): żadna
z włożonych kart nie
wywołała błędu niepo­
prawnego zamknięcia
ostatniej sesji karty.
tp15638LastSessionClosed
BOOLEAN
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 563
1)
Element danych RTM
2)
Czynność wykonywana przez VU
3)
Definicja danych w ASN.1
RTM11
Przerwa w zasilaniu
VU generuje wartość
w postaci
liczby całkowitej w odnie­
sieniu do elementu danych
RTM11.
VU przypisuje zmiennej
tp15638PowerSupplyInter­
ruption wartość odpowiada­
jącą liczbie zarejestrowanych
zdarzeń przerwy w zasilaniu
przechowywanych w VU
w ciągu ostatnich 10 dni, jak
określono w załączniku IC.
Jeżeli VU nie zarejestrował
żadnego zdarzenia przerwy
w zasilaniu w ciągu ostatnich
10 dni, ustala wartość
RTM11 na 0.
Liczba zarejestrowanych
przerw w zasilaniu
w ciągu ostatnich 10
dni.
tp15638PowerSupplyInterrup­
tion
INTEGER (0..127),
RTM12
Usterka czujnika
VU generuje wartość
w postaci liczby całkowitej
w odniesieniu do elementu
danych RTM12.
VU przypisuje zmiennej
sensorFault wartość:
— 1, jeżeli zdarzenie typu
„35”H związane
z usterką czujnika
zostało
zarejestrowane w ciągu
ostatnich 10 dni lub trwa
nadal.
— 2, jeżeli zdarzenie zwią­
zane z usterką odbior­
nika GNSS (wewnętrz­
nego albo zewnętrznego,
o wartości enum
„36”H lub „37”H)
zakończyło się w ciągu
ostatnich 10 dni lub trwa
nadal.
— 3, jeżeli zdarzenie typu
„0E”H związane
z błędem połączenia
z urządzeniem
zewnętrznym GNSS
zakończyło się w ciągu
ostatnich 10 dni lub trwa
nadal.
— 4, jeżeli zarówno usterka
czujnika, jak i usterka
odbiornika GNSS zakoń­
czyły się w ciągu ostat­
nich 10 dni lub trwają
nadal.
— 5, jeżeli zarówno usterka
czujnika, jak i błąd
połączenia z urządzeniem
zewnętrznym GNSS
zakończyły się w ciągu
ostatnich 10 dni lub
trwają nadal.
–usterka czujnika jeden
oktet zgodnie ze słowni­
kiem danych
tp15638SensorFault INTEGER
(0..255),
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 564
1)
Element danych RTM
2)
Czynność wykonywana przez VU
3)
Definicja danych w ASN.1
— 6, jeżeli zarówno usterka
odbiornika GNSS, jak
i błąd połączenia z urzą­
dzeniem zewnętrznym
GNSS zakończyły się
w ciągu ostatnich 10 dni
lub trwają nadal.
— 7, jeżeli wszystkie trzy
usterki czujnika zakoń­
czyły się w ciągu ostat­
nich 10 dni lub trwają
nadal.
Jeżeli żadne zdarzenie nie
zakończyło się w ciągu
ostatnich 10 dni ani nie trwa
nadal, VU ustala wartość
RTM12 na 0.
RTM13
Korekta czasu
VU generuje wartość
w postaci liczby całkowitej
(timeReal z dodatku 1) dla
elementu danych RTM13 na
podstawie obecności danych
dotyczących korekty czasu
zdefiniowanych w załączniku
IC.
VU ustawia wartość RTM13
na czas, w którym doszło do
wystąpienia ostatniego
zdarzenia polegającego na
korekcie czasu danych.
Jeżeli w danych VU nie
stwierdzono wystąpienia
żadnego zdarzenia korekty
czasu zdefiniowanego
w załączniku IC, wartość
RTM13 ustala się na 0.
oldTimeValue ostatniej
korekty czasu.
tp15638TimeAdjustment
INTEGER(0..4294967295),
RTM14
Próba naruszenia
zabezpieczenia
VU generuje wartość
w postaci liczby całkowitej
(timeReal z dodatku 1) dla
elementu danych RTM14 na
podstawie wystąpienia
zdarzenia próby naruszenia
zabezpieczenia zdefiniowa­
nego w załączniku IC.
VU ustala wartość czasu,
w którym doszło do ostat­
niego zarejestrowanego przez
VU zdarzenia związanego
z próbą naruszenia zabezpie­
czenia.
Jeżeli w danych VU nie
stwierdzono wystąpienia
żadnego zdarzenia próby
naruszenia zabezpieczenia
zdefiniowanego w załączniku
IC, wartość RTM14 ustala się
na 0.
Czas rozpoczęcia ostat­
niego zarejestrowanego
zdarzenia związanego
z próbą naruszenia
zabezpieczenia.
tp15638LatestBreachAttempt
INTEGER(0..4294967295),
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 565
1)
Element danych RTM
2)
Czynność wykonywana przez VU
3)
Definicja danych w ASN.1
RTM15
Ostatnia kalibracja
VU generuje wartość
w postaci liczby całkowitej
(timeReal z dodatku 1) dla
elementu danych RTM15 na
podstawie obecności danych
dotyczących ostatniej kalib­
racji zdefiniowanych
w załączniku IC i dodatku 1.
VU ustala wartość RTM15
na old
TimeValue ostatniego
rekordu kalibracji.
Jeżeli kalibracja nie miała
miejsca, VU ustala wartość
RTM15 na 0.
oldTimeValue najno­
wszego rekordu
kalibracji.
tp15638LastCalibrationData
INTEGER(0..4294967295),
RTM16
Poprzednia kalibracja
VU generuje wartość
w postaci liczby całkowitej
(timeReal z dodatku 1) dla
elementu danych RTM16
z rekordu kalibracyjnego
poprzedzającego ostatnią
kalibrację.
VU ustala wartość RTM16
na old
TimeValue rekordu kalibracji
poprzedzającego ostatnią
kalibrację.
Jeżeli nie było poprzedniej
kalibracji, VU ustala wartość
RTM16 na 0.
oldTimeValue rekordu
kalibracji poprzedzają­
cego najnowszy rekord
kalibracji.
tp15638PrevCalibrationData
INTEGER(0..4294967295),
RTM17
Data podłączenia
tachografu
VU generuje wartość
w postaci liczby całkowitej
(timeReal z dodatku 1)
w odniesieniu do elementu
danych RTM17.
VU ustala wartość RTM17
na datę pierwszej kalibracji
VU w bieżącym pojeździe.
VU wyodrębnia te dane
z VuCalibrationData
(dodatek 1) znajdujących się
w VuCalibrationRecords
z CalibrationPurpose
równym: „03”H
Jeżeli nie było poprzedniej
kalibracji, VU ustala wartość
RTM17 na 0.
Data pierwszej kalibracji
VU w bieżącym pojeź­
dzie.
tp15638DateTachoConnected
INTEGER(0..4294967295),
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 566
1)
Element danych RTM
2)
Czynność wykonywana przez VU
3)
Definicja danych w ASN.1
RTM18
Prędkość bieżąca
VU generuje wartość
w postaci
liczby całkowitej w odnie­
sieniu do elementu danych
RTM18.
VU ustala wartość RTM18
na wartość ostatniej zareje­
strowanej prędkości bieżącej
w chwili dokonania ostatniej
aktualizacji RtmData.
Ostatnia zarejestrowana
prędkość bieżąca
tp15638CurrentSpeed
INTEGER (0..255),
RTM19
Znacznik czasu
VU generuje wartość
w postaci liczby całkowitej
w odniesieniu do elementu
danych RTM19 (timeReal
z dodatku 1).
VU ustala wartość RTM19
na czas ostatniej aktualizacji
RtmData.
Znacznik czasu bieżą­
cego
rekordu TachographPay­
load
tp15638Timestamp
INTEGER(0..4294967295),
RTM20
Czas, kiedy była
dostępna ostatnia uwie­
rzytelniona pozycja
pojazdu
VU generuje wartość
w postaci liczby całkowitej
(timeReal z dodatku 1)
w odniesieniu do elementu
danych RTM20.
VU ustala wartość RTM20
na czas, kiedy ostatnia uwie­
rzytelniona pozycja pojazdu
była dostępna z odbiornika
GNSS .
Jeżeli żadna uwierzytelniona
pozycja pojazdu nie była
kiedykolwiek dostępna
z odbiornika GNSS, VU
ustawia wartość RTM20
na 0.
Znacznik czasu ostatniej
uwierzytelnionej pozycji
pojazdu
tp15638LatestAuthenticatedPo­
sition
INTEGER(0..4294967295),
RTM21
Nieprzerwany czas
prowadzenia pojazdu
VU generuje wartość
w postaci liczby całkowitej
w odniesieniu do elementu
danych RTM21.
VU ustala wartość RTM21
na trwający nieprzerwany
czas prowadzenia pojazdu
przez kierowcę.
Nieprzerwany czas
prowadzenia pojazdu
przez kierowcę, zakodo­
wany jako liczba całko­
wita.
Długość: 1 bajt
Rozdzielczość: 2 minuty/
bit
Brak offsetu
Przedział danych: 0
do 250
Wartość 250 wskazuje,
że nieprzerwany czas
prowadzenia pojazdu
przez kierowcę wynosi
co najmniej 500 minut.
Wartości 251 do 254 nie
używa się.
Wartość 255 wskazuje,
że informacje nie są
dostępne.
tp15638ContinuousDrivin­
gTime INTEGER(0..255),
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 567
1)
Element danych RTM
2)
Czynność wykonywana przez VU
3)
Definicja danych w ASN.1
RTM22
Najdłuższy dzienny czas
prowadzenia pojazdu dla
trwającej i poprzedniej
zmiany RTM, obliczony
zgodnie z addendum do
dodatku 14
VU generuje wartość
w postaci liczby całkowitej
w odniesieniu do elementu
danych RTM22.
VU ustawia wartość RTM22
na dłuższy z dwóch dzien­
nych okresów prowadzenia
pojazdu przez kierowcę, tj.
na trwającą lub poprzednią
zmianę RTM.
Dzienny czas prowa­
dzenia pojazdu przez
kierowcę, zakodowany
jako liczba całkowita.
Długość: 1 bajt
Rozdzielczość: 4 minuty/
bit
Brak offsetu
Przedział danych: 0
do 250
Wartość 250 wskazuje,
że dzienny czas prowa­
dzenia pojazdu przez
kierowcę wynosi co
najmniej 1 000 minut.
Wartości 251 do 254 nie
używa się.
Wartość 255 wskazuje,
że informacje nie są
dostępne.
tp15638DailyDrivingTimeShift
INTEGER(0..255),
RTM23
Najdłuższy dzienny czas
prowadzenia pojazdu
w trwającym tygodniu,
obliczony zgodnie
z addendum do
dodatku 14
VU generuje wartość
w postaci liczby całkowitej
w odniesieniu do elementu
danych RTM23.
VU ustawia wartość RTM23
na najdłuższy dzienny czas
prowadzenia pojazdu przez
kierowcę, tj. na trwającą
zmianę RTM lub jakąkolwiek
ukończoną zmianę RTM,
która rozpoczęła się lub
zakończyła w trwającym
tygodniu.
Dzienny czas prowa­
dzenia pojazdu przez
kierowcę, zakodowany
jako liczba całkowita.
Długość: 1 bajt
Rozdzielczość: 4 minuty/
bit
Brak offsetu
Przedział danych: 0
do 250
Wartość 250 wskazuje,
że dzienny czas prowa­
dzenia pojazdu przez
kierowcę wynosi co
najmniej 1 000 minut.
Wartości 251 do 254 nie
używa się.
Wartość 255 wskazuje,
że informacje nie są
dostępne.
tp15638DailyDrivingTime­
Week INTEGER(0..255),
RTM24
Tygodniowy czas prowa­
dzenia pojazdu, obliczony
zgodnie z addendum do
dodatku 14
VU generuje wartość
w postaci liczby całkowitej
w odniesieniu do elementu
danych RTM24.
VU ustala wartość RTM24
na tygodniowy czas prowa­
dzenia pojazdu przez
kierowcę.
Tygodniowy czas
prowadzenia pojazdu
przez kierowcę, zakodo­
wany jako liczba całko­
wita.
Długość: 1 bajt
Rozdzielczość: 20
minuty/bit
Brak offsetu
Przedział danych: 0
do 250
Wartość 250 wskazuje,
że tygodniowy czas
prowadzenia pojazdu
przez kierowcę wynosi
co najmniej 5 000 minut.
Wartości 251 do 254 nie
używa się.
Wartość 255 wskazuje,
że informacje nie są
dostępne.
tp15638WeeklyDrivingTime
INTEGER(0..255),
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 568
1)
Element danych RTM
2)
Czynność wykonywana przez VU
3)
Definicja danych w ASN.1
RTM25
Dwutygodniowy czas
prowadzenia pojazdu,
obliczony zgodnie
z addendum do
dodatku 14
VU generuje wartość
w postaci liczby całkowitej
w odniesieniu do elementu
danych RTM25.
VU ustala wartość RTM25
na dwutygodniowy czas
prowadzenia pojazdu przez
kierowcę.
Dwutygodniowy czas
prowadzenia pojazdu
przez kierowcę, zakodo­
wany jako liczba całko­
wita.
Długość: 1 bajt
Rozdzielczość: 30
minuty/bit
Brak offsetu
Przedział danych: 0
do 250
Wartość 250 wskazuje,
że dwutygodniowy czas
prowadzenia pojazdu
przez kierowcę wynosi
co najmniej 7 500 minut.
Wartości 251 do 254 nie
używa się.
Wartość 255 wskazuje,
że informacje nie są
dostępne.
tp15638FortnightlyDrivin­
gTime INTEGER(0..255),
Uwaga: RTM22, RTM23, RTM24 i RTM25 oblicza się zgodnie z addendum do
niniejszego dodatku.
▼B
5.4.6 Mechanizm przesyłania danych
DSC_42 REDCR wysyła żądanie przekazania zdefiniowanych wcześ­
niej danych ładunku po zakończeniu etapu inicjacji; następnie
DSRC-VU przekazuje te dane w przydzielonym oknie.
REDCR korzysta z polecenia GET w celu pobrania danych.
▼M1
DSC_43 Wszystkie dane wymieniane w ramach DSRC koduje się przy
użyciu reguł PER (Packed Encoding Rules) UNALIGNED,
z wyjątkiem oraz
, które koduje się przy użyciu reguł OER (Octet Encoding
Rules) zdefiniowanych w normie ISO/IEC 8825-7, Rec.
ITU-T X.696.
▼B
5.4.7 Szczegółowy opis transakcji DSRC
DSC_44 Inicjację przeprowadza się zgodnie z pkt DSC_44–DSC_48
oraz tabelami 14.4–14.9. Na etapie inicjacji REDCR rozpo­
czyna przesyłanie ramki zawierającej BST (tabelę usług
sygnału) zgodnie z normami EN 12834 i EN 13372 pkt
6.2, 6.3, 6.4 i 7.1 z ustawieniami określonymi w tabeli 14.4
poniżej.
Tabela 14.4
Inicjacja – ustawienia ramki BST
Pole Ustawienia
Identyfikator łącza Adres emisji
Identyfikator sygnału Zgodnie z normą EN 12834
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 569
Czas Zgodnie z normą EN 12834
Profil Brak rozszerzenia, należy
zastosować 0 lub 1
Aplikacje obowiązkowe Brak rozszerzenia, brak EID,
brak parametru, AID = 2
Freight&Fleet
Aplikacje nieobowiązkowe Brak
Lista profilów Brak rozszerzenia, liczba
profilów na liście = 0
Nagłówek fragmentacji Brak fragmentacji
Ustawienia 2. warstwy Polecenie PDU, polecenie
interfejsu użytkownika
W tabeli 14.5 poniżej przedstawiono praktyczny przykład
zastosowania ustawień określonych w tabeli 14.4 wraz z infor­
macjami o kodowaniu bitowym.
Tabela 14.5
Inicjacja – przykładowa zawartość ramki BST
O
kt
et
#

Atrybut/Pole Bity w oktecie Opis
1 FLAGA Flaga początkowa
2 Identyfikator emisji Adres emisji
3 Pole kontrolne MAC Polecenie PDU
4 Pole kontrolne LLC Polecenie interfejsu użyt­
kownika
5 Nagłówek fragmentacji Brak fragmentacji
6 BST Żądanie inicjacji
SEQUENCE {
OPTION indicator
BeaconID SEQUENCE {
ManufacturerId INTEGER (0..65535)
Brak aplikacji nieobo­
wiązkowych
Identyfikator producenta
7
8
IndividualID INTEGER (0..134217727)
}
27-bitowy identyfikator
dostępny dla producenta
9
10
11
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 570
O
kt
et
#

Atrybut/Pole Bity w oktecie Opis
12 Time INTEGER (0..4294967295) Czas rzeczywisty w 32-
bitowym systemie UNIX
13
14
15
16 Profile NTEGER (0..127,...) Brak rozszerzenia. Przy­
kładowy profil 0
17 MandApplications SEQUENCE
(SIZE(0..127,...))
OF {
Brak rozszerzenia, liczba
aplikacji obowiązkowych
= 1
18 SEQUENCE {
Wskaźnik WARIANTU Brak EID
Wskaźnik WARIANTU Brak parametru
AID DSRCApplicationEntityID } } Brak rozszerzenia. AID=
2 Freight&Fleet
19 ProfileList SEQUENCE (0..127,...) OF
Profile }
Brak rozszerzenia, liczba
profilów na liście = 0
20 FCS Sekwencja kontroli ramki
21
22 Flaga Flaga końcowa
DSC_45 Po otrzymaniu BST DSRC-VU żąda przydzielenia okna
prywatnego zgodnie z postanowieniami norm EN 12795
i EN 13372 pkt 7.1.1, bez określonych ustawień RTM.
W tabeli 14.6 przedstawiono przykład kodowania bitowego.
Tabela 14.6
Inicjacja – zawartość ramki dotyczącej żądania przydzielenia okna prywatnego
O
kt
et
#

Atrybut/Pole Bity w oktecie Opis
1 FLAGA Flaga początkowa
2 Prywatny LID Adres łącza określonego
DSRC-VU
3
4
5
6 Pole kontrolne MAC Żądanie przydzielenia
okna prywatnego
7 FCS Sekwencja kontroli ramki
8
9 Flaga Flaga końcowa
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 571
DSC_46 Następnie REDCR odpowiada, przydzielając okno prywatne
zgodnie z postanowieniami norm EN 12795 i EN 13372 pkt
7.1.1, bez określonych ustawień RTM.
W tabeli 14.7 przedstawiono przykład kodowania bitowego.
Tabela 14.7
Inicjacja – zawartość ramki dotyczącej przydzielenia okna prywatnego
O
kt
et
#

Atrybut/Pole Bity w oktecie Opis
1 FLAGA Flaga początkowa
2 Prywatny LID Adres łącza określonego
DSRC-VU
3
4
5
6 Pole kontrolne MAC Przydzielenie okna
prywatnego
7 FCS Sekwencja kontroli ramki
8
9 Flaga Flaga końcowa
DSC_47 Po otrzymaniu przydziału okna prywatnego DSRC-VU prze­
syła swoją VST (tabela usług pojazdu), jak określono
w normach EN 12834 i EN 13372 pkt 6.2, 6.3, 6.4 i 7.1,
z ustawieniami określonymi w tabeli 14.8 za pomocą przy­
dzielonego okna transmisji.
Tabela 14.8
Inicjacja – ustawienia ramki VST
Pole Ustawienia
Prywatny LID Zgodnie z normą EN 12834
Parametry VST Wypełnienie = 0; następnie dla każdej
obsługiwanej aplikacji: EID wystę­
puje, parametr występuje, AID = 2;
EID zgodny z wygenerowanym
przez OBU
Parametr Brak rozszerzenia, zawiera znacznik
kontekstowy RTM
ObeConfiguration Opcjonalne pole ObeStatus może być
obecne, ale nie może być stosowane
przez REDCR
Nagłówek fragmentacji Brak fragmentacji
Ustawienia 2. warstwy Polecenie PDU, polecenie interfejsu
użytkownika
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 572
DSC_48 DSRC-VU obsługuje aplikację „Ładunek i flota” (Freight and
Fleet) opatrzoną identyfikatorem aplikacji „2”. Inne identyfi­
katory aplikacji mogą być obsługiwane, ale nie mogą wystę­
pować w tej VST, ponieważ BST wymaga wyłącznie AID=2.
Pole „Aplikacje” zawiera wykaz wystąpień aplikacji obsługi­
wanych w ramach DSRC-VU. Dla każdego obsługiwanego
wystąpienia aplikacji podaje się odniesienie do odpowiedniej
normy w formie znacznika Rtm Context, który składa się
z IDENTYFIKATORA OBIEKTU reprezentującego powią­
zaną normę, jej część (9 w przypadku RTM) oraz – w stosow­
nych przypadkach – wersję, a także EID generowanego przez
DSRC-VU i powiązanego z danym wystąpieniem aplikacji.
W tabeli 14.9 przedstawiono praktyczny przykład ustawień
określonych w tabeli 14.8 wraz z informacjami o kodowaniu
bitowym.
▼M3
Tabela 14.9
Inicjacja – przykładowa zawartość ramki VST
O
kt
et
#

Atrybut/Pole Bity w oktecie Opis
1 FLAG 0111 1110 Flaga początkowa
2 Private LID xxxx xxxx Adres łącza określonego
DSRC-VU
3 xxxx xxxx
4 xxxx xxxx
5 xxxx xxxx
6 MAC Control field 1100 0000 Polecenie PDU
7 LLC Control field 0000 0011 Polecenie interfejsu użyt­
kownika
8 Fragmentation header 1xxx x001 Brak fragmentacji
9 VST
SEQUENCE {
Fill BIT STRING (SIZE(4))
1001 Odpowiedź na inicjację
0000 Niewykorzystywane
i ustawione na 0
10 Profile INTEGER (0..127,...)
Applications SEQUENCE OF {
0000 0000 Brak rozszerzenia. Przy­
kładowy profil 0
Brak rozszerzenia, 1 apli­
kacja
11 0000 0001
12 SEQUENCE {
OPTION indicator
OPTION indicator
AID DSRCApplicationEntityID
1 EID występuje
1 Parametr występuje
00 0010 Brak rozszerzenia. AID=
2 Freight&Fleet
13 EID Dsrc-EID xxxx xxxx Zdefiniowany przez OBU
i identyfikujący wystą­
pienie aplikacji.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 573
O
kt
et
#

Atrybut/Pole Bity w oktecie Opis
14 Parameter Container { 0000 0010 Brak rozszerzenia, wybór
kontenera = 02,
ciąg oktetowy
15 0000 0110 Brak rozszerzenia, długość
znacznika kontekstowego
RTM = 6
16 Rtm-ContextMark ::= SEQUENCE {
StandardIdentifier
0000 0101 Wartość pierwszego
oktetu to 05H i stanowi
jego długość.
Kolejne 5 oktetów koduje
identyfikator obiektu
obsługiwanej normy,
części i wersji.
{ISO (1) norma (0)
TARV (15638) część
9(9) wersja 2 (2)}
17 standardIdentifier 0010 1000
18 1111 1010
19 0001 0110
20 0000 1001
21 0000 0010
22 ObeConfiguration Sequence {
OPTION indicator
0 Brak ObeStatus
EquipmentClass INTEGER (0..32767) xxx xxxx To pole używane jest na
potrzeby
23 xxxx xxxx wskazań producenta doty­
czących wersji oprogra­
mowania/sprzętu inter­
fejsu DSRC
24 ManufacturerId INTEGER (0..65535) xxxx xxxx Identyfikator producenta
dla DSRC-VU opisany
w rejestrze dotyczącym
normy ISO 14816
25 xxxx xxxx
26 FCS xxxx xxxx Sekwencja kontroli ramki
27 xxxx xxxx
28 Flag 0111 1110 Flaga końcowa
▼B
DCS_49 Następnie REDCR odczytuje dane, wydając polecenie GET,
które odpowiada poleceniu GET zdefiniowanemu w normie
EN 13372 pkt 6.2, 6.3, 6.4 i w normie EN 12834; ustawienia
tego polecenia odpowiadają ustawieniom przedstawionym
w tabeli 14.10.
Tabela 14.10
Przedstawienie – ustawienia ramki żądania GET
Pole Ustawienia
Identyfikator źródła (IID) Brak
Identyfikator łącza (LID) Adres łącza określonego DSRC-VU
Tworzenie łańcuchów Nie
Identyfikator elementu (EID) Jak określono w VST. Brak rozsze­
rzenia
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 574
Pole Ustawienia
Poświadczenia dostępu Nie
AttributeIdList Brak rozszerzenia, 1 atrybut, Attribu­
teID = 1 (RtmData)
Fragmentacja Nie
Ustawienia 2. warstwy Polecenie PDU, wysondowane pole­
cenie ACn
W tabeli 14.11 przedstawiono przykład odczytu danych RTM.
Tabela 14.11
Przedstawienie – przykład ramki żądania GET
O
kt
et
#

Atrybut/Pole Bity w oktecie Opis
1 FLAGA Flaga początkowa
2 Prywatny LID Adres łącza określonego
DSRC-VU
3
4
5
6 Pole kontrolne MAC Polecenie PDU
7 Pole kontrolne LLC Wysondowane polecenie
ACn, bit n
8 Nagłówek fragmentacji Brak fragmentacji
9 Get.request
SEQUENCE {
Żądanie Get
Wskaźnik WARIANTU Brak poświadczeń
dostępu
Wskaźnik WARIANTU Brak IID
Wskaźnik WARIANTU Występuje AttributeIdList
Wypełnienie CIĄG BITÓW
(ROZMIAR (1) )
Ustalono na 0.
10 EID INTEGER(0..127,…) EID wystąpienia aplikacji
RTM, jak określono
w VST. Brak rozszerzenia
11 AttributeIdList SEQUENCE OF {
AttributeId }}
Brak rozszerzenia, liczba
atrybutów = 1
12 AttributeId=1, RtmData.
Brak rozszerzenia
13 FCS Sekwencja kontroli ramki
14
15 Flaga Flaga końcowa
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 575
DSC_50 Po otrzymaniu żądania GET DSRC-VU wysyła odpowiedź
GET wraz z żądanymi danymi zgodnymi z odpowiedzią
GET określonymi w normie EN 13372 pkt 6.2, 6.3, 6.4
i w normie EN 12834; ustawienia odpowiadają ustawieniom
określonym w tabeli 14.12.
Tabela 14.12
Przedstawienie – ustawienia ramki odpowiedzi GET
Pole Ustawienia
Identyfikator źródła (IID) Brak
Identyfikator łącza (LID) Zgodnie z normą EN 12834
Tworzenie łańcuchów Nie
Identyfikator elementu (EID) Jak określono w VST.
Poświadczenia dostępu Nie
Fragmentacja Nie
Ustawienia 2. warstwy Odpowiedź PDU, dostępna
odpowiedź i przyjęte pole­
cenie, polecenie ACn
W tabeli 14.13 przedstawiono przykład odczytu danych RTM.
Tabela 14.13
Przedstawienie – przykładowa zawartość ramki odpowiedzi
O
kt
et
#

Atrybut/Pole Bity w oktecie Opis
1 FLAGA Flaga początkowa
2 Prywatny LID Adres łącza określonego
DSRC-VU
3
4
5
6 Pole kontrolne MAC Odpowiedź PDU
7 Pole kontrolne LLC Dostępna odpowiedź, bit
n polecenia ACn
8 Pole stanu LLC Dostępna odpowiedź
i przyjęte polecenie
9 Nagłówek fragmentacji Brak fragmentacji
10 GET.response
SEQUENCE {
Odpowiedź na żądanie
Get
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 576
O
kt
et
#

Atrybut/Pole Bity w oktecie Opis
Wskaźnik WARIANTU Brak IID
Wskaźnik WARIANTU Lista atrybutów występuje
Wskaźnik WARIANTU Status zwrotu nie wystę­
puje
Wypełnienie CIĄG BITÓW
(ROZMIAR (1) )
Nieużywany
11 EID INTEGER(0..127,…) Odpowiedź z wystąpienia
aplikacji
RTM. Brak rozszerzenia
12 AttributeList SEQUENCE OF { Brak rozszerzenia, liczba
atrybutów = 1
13 Attributes SEQUENCE {
AttributeId
Brak rozszerzenia, Attri­
buteId=1 (RtmData)
14 AttributeValue CONTAINER { Brak rozszerzenia, wybór
kontenera = 1010.
15 RtmData
16
17
… …
n }}}}
n+1 FCS Sekwencja kontroli ramki
n+2
n+3 Flaga Flaga końcowa
DSC_51 Następnie REDCR zamyka połączenie, wydając polecenie
EVENT_REPORT, RELEASE zgodnie z normą EN 13372
pkt 6.2, 6.3, 6.4 i z normą 12834 pkt 7.3.8, bez określonych
ustawień RTM. W tabeli 14.14 przedstawiono przykład kodo­
wania bitowego polecenia RELEASE.
Tabela 14.14
Zakończenie. EVENT_REPORT Uwolnienie zawartości ramki
O
kt
et
#

Atrybut/Pole Bity w oktecie Opis
1 FLAGA Flaga początkowa
2 Prywatny LID Adres łącza określonego
DSRC-VU
3
4
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 577
O
kt
et
#

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 rozpo­
rządzeniu (UE) nr 165/2014 (zob. pkt 6 poniżej).
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 578
DSC_55 W celu przeprowadzenia tego podstawowego testu łączności
REDCR wydaje polecenie ECHO w trakcie sesji, tj. po
pomyślnym zakończeniu etapu inicjacji. Sekwencja czynności
jest zatem zbliżona do sekwencji czynności związanych
z zapytaniem:
— Etap 1 REDCR wysyła „tabelę usług sygnału” (BST),
która zawiera identyfikatory aplikacji (AID) w wykazie
obsługiwanych usług. W aplikacji RTM będzie to po
prostu usługa z wartością AID = 2.
DSRC-VU oceni otrzymaną BST i jeżeli uzna, że BST
żąda danych Freight&Fleet (AID = 2), DSRC-VU udzieli
odpowiedzi. Jeżeli REDCR nie oferuje AID=2,
DSRC-VU przerywa transakcję z REDCR.
— Krok 2 DSRC-VU wysyła żądanie przydzielenia okna
prywatnego.
— Krok 3 REDCR przesyła przydział okna prywatnego.
— Krok 4 DSRC-VU używa przydzielonego okna prywat­
nego do wysłania swojej tabeli usług pojazdu (VST).
Tego rodzaju VST zawiera wykaz wszystkich różnych
wystąpień aplikacji obsługiwanych przez ten DSRC-VU
w ramach AID=2. Poszczególne wystąpienia są identyfi­
kowane za pomocą jednorazowych identyfikatorów
elementu, z których każdy jest powiązany z wartością
parametru określającą wystąpienie obsługiwanej aplikacji.
— Krok 5 Następnie REDCR analizuje oferowaną tabelę
usług pojazdu i albo przerywa łączność (RELEASE),
ponieważ nie jest zainteresowany niczym, co dana VST
ma do zaoferowania (tj. otrzymuje VST od DSRC-VU,
która nie jest RTM VU), albo – jeżeli otrzymuje odpo­
wiednią tabelę usług pojazdu – uruchamia wystąpienie
aplikacji.
— Krok 6 REDCR wydaje polecenie (ECHO) określonemu
DSRC-VU i przypisuje okno prywatne.
— Krok 7 DSRC-VU korzysta z nowo przydzielonego okna
prywatnego do wysłania ramki odpowiedzi ECHO.
W poniższych tabelach przedstawiono praktyczny przykład sesji
wymiany ECHO.
DSC_56 Inicjację przeprowadza się zgodnie z pkt 5.4.7
(DSC_44–DSC_48) oraz tabelami 14.4–14.9.
DSC_57 Następnie REDCR wydaje polecenie ACTION, ECHO
zgodnie z normą ISO 14906, zawierającą 100 oktetów danych
i bez określonych ustawień RTM. W tabeli 14.15 przedsta­
wiono zawartość ramki wysłanej przez REDCR.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 579
Tabela 14.15
Przykładowa ramka żądania ACTION, ECHO
O
kt
et
#

Atrybut/Pole Bity w oktecie Opis
1 FLAGA Flaga początkowa
2 Prywatny LID Adres łącza określonego
DSRC-VU
3
4
5
6 Pole kontrolne MAC Polecenie PDU
7 Pole kontrolne LLC Wysondowane polecenie
ACn, bit n
8 Nagłówek fragmentacji Brak fragmentacji
9 ACTION.request
SEQUENCE {
Żądanie działania (ECHO)
Wskaźnik WARIANTU Brak poświadczeń dostępu
Wskaźnik WARIANTU Parametr akcji występuje
Wskaźnik WARIANTU Brak IID
Tryb BOOLEAN Odpowiedź oczekiwana
10 EID INTEGER (0..127,…) Brak rozszerzenia, EID =
0 (System)
11 ActionType INTEGER (0..127,…) Brak rozszerzenia, typ
działania: żądanie ECHO
12 ActionParameter CONTAINER { Brak rozszerzenia, wybór
kontenera = 2
13 Brak rozszerzenia.
Długość ciągu =
100 oktetów
14 Dane, które mają być
powtórzone
… …
113 }}
114614 FCS Sekwencja kontroli ramki
115715
116816 Flaga Flaga końcowa
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 580
DSC_58 Po otrzymaniu żądania ECHO DSRC-VU wysyła odpowiedź
ECHO o długości 100 oktetów danych, odzwierciedlając
otrzymane polecenie, zgodnie z normą ISO 14906, bez okre­
ślonych ustawień RTM. W tabeli 14.16 przedstawiono przy­
kład szyfrowania na poziomie bitów.
Tabela 14.16
Przykładowa ramka żądania ACTION, ECHO
O
kt
et
#

Atrybut/Pole Bity w oktecie Opis
1 FLAGA Flaga początkowa
2 Prywatny LID Adres łącza określonego
VU
3
4
5
6 Pole kontrolne MAC Odpowiedź PDU
7 Pole kontrolne LLC Polecenie ACn, bit n
8 Pole stanu LLC Odpowiedź dostępna
9 Nagłówek fragmentacji Brak fragmentacji
10 ACTION.response
SEQUENCE {
Odpowiedź na DZIAŁANIE
(ECHO)
Wskaźnik WARIANTU Brak IID
Wskaźnik WARIANTU Parametr odpowiedzi
występuje
Wskaźnik WARIANTU Status zwrotu nie wystę­
puje
Wypełnienie CIĄG BITÓW
(ROZMIAR (1) )
Nieużywany
11 EID INTEGER (0..127,…) Brak rozszerzenia, EID =
0 (System)
12 KONTENER ResponseParameter { Brak rozszerzenia, wybór
kontenera = 2
13 Brak rozszerzenia.
Długość ciągu = 100
oktetów
14 Powtórzone dane
… …
113 }}
114 FCS Sekwencja kontroli ramki
115
116 Flaga Flaga końcowa
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 581
5.5 Zarezerwowane dla przyszłego użytku
▼M2
__________
▼B
5.6 Przesyłanie danych pomiędzy DSRC-VU a VU
5.6.1 Połączenie fizyczne i interfejsy
DSC_66 Połączenie między VU a DSRC-VU może odbywać się za
pomocą fizycznego okablowania lub łączności bezprzewo­
dowej o krótkim zasięgu opartej na technologii Bluetooth
v4.0 BLE.
DSC_67 Niezależnie od wybranego fizycznego połączenia i 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
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 582
4. Potwierdzenie danych
5. Zamknięcie łącza komunikacyjnego – żądanie
6. Zamknięcie łącza komunikacyjnego – odpowiedź
DSC_73 W module ASN1.0 wcześniejsze polecenia można zdefi­
niować w następujący sposób:
DSC_74 Opis poleceń i parametrów jest następujący:
— ­
stosuje się w celu zainicjowania łącza komunikacyjnego.
Polecenie jest wysyłane przez VU do DSRC-VU. VU
ustanawia LinkIdentifier i przekazuje DSRC-VU w celu
śledzenia określonego łącza komunikacyjnego.
(Uwaga: służy to obsłudze przyszłych łączy i innych apli­
kacji/modułów takich jak system ważenia w pojeździe);
— jest
stosowane przez DSRC-VU w celu dostarczenia odpo­
wiedzi na żądanie zainicjowania łącza komunikacyjnego.
Polecenie jest wysyłane przez DSRC-VU do VU. Pole­
cenie przekazuje wynik inicjacji w formie odpowiedzi = 1
(Sukces) lub = 0 (Niepowodzenie).
DSC_75 Zainicjowanie łącza komunikacyjnego następuje dopiero po
zainstalowaniu, kalibracji i uruchomieniu silnika/VU.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 583
— jest stosowane przez VU do przesy­
łania podpisanych RCDTData (tj. danych dotyczących
łączności na odległość) do DSRC-VU. Dane będą wysy­
łane co 60 sekund. Parametr DataTransactionId identyfi­
kuje określoną transmisję danych. LinkIdentifier wyko­
rzystuje się także do upewnienia się, że łącze jest prawid­
łowe;
— jest wysyłane przez
DSRC-VU w celu dostarczenia VU informacji zwrotnej
dotyczącej odbioru danych z polecenia­
określonego przez parametr Data­
TransactionId. Parametr odpowiedzi to 1 (Sukces) lub
=0 (Niepowodzenie). Jeżeli VU otrzyma więcej niż trzy
odpowiedzi równe 0 lub jeżeli VU nie otrzyma komuni­
katu RCDT Data Acknowledgment w odniesieniu do
konkretnego wysłanego wcześniej polecenia z określonym
DataTransactionId, VU wygeneruje i zarejestruje
zdarzenie;
— komunikat
jest wysyłane przez VU do DSRC-VU w celu zakoń­
czenia łącza w odniesieniu do konkretnego LinkIdentifier.
DSC_76 Po ponownym uruchomieniu DSRC-VU lub VU wszystkie
istniejące łącza komunikacyjne należy usunąć, ponieważ
w związku z nagłym zamknięciem VU mogą wystąpić
„zawieszone” łącza.
— jest wysy­
łane przez DSRC-VU do VU w celu potwierdzenia
żądania zakończenia łącza przez VU w odniesieniu do
konkretnego LinkIdentifier.
5.7 Obsługa błędów
5.7.1 Rejestrowanie i przekazywanie danych w DSRC-VU
▼M3
DSC_77 Już zabezpieczone Dane są przekazywane DSRC-VU za
pomocą funkcji VUSM . VUSM sprawdza, czy dane zareje­
strowane w DSRC-VU zostały z powodzeniem przesłane do
DSRC-VU. Rejestrowanie i zgłaszanie wszelkich błędów,
jakie wystąpiły podczas przesyłania danych z VU do pamięci
DSRC-VU, odbywa się przy użyciu zdarzenia typu Even­
tFaultType z wartością enum ustawioną na „0C”H Błąd łącz­
ności z urządzeniem do łączności na odległość wraz ze znacz­
nikiem czasu. VUSM sprawdza, czy dane zostały z powodze­
niem przesłane do DSRC-VU.
DSC_78 Zarezerwowane dla przyszłego użytku
▼B
DSC_79 Jeżeli VUPM próbuje uzyskać dane VU z modułu zabezpie­
czeń (w celu przejścia do urządzenia VU-DSRC), ale kończy
się to niepowodzeniem, wówczas rejestruje takie niepowo­
dzenie jako zdarzenie typu EventFaultType z wartością
enum „62”H Błąd łączności z urządzeniem do łączności na
odległość wraz ze znacznikiem czasu. Błąd związany z łączno­
ścią zostaje wykryty w przypadku nieotrzymania komunikatu
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 584
dotyczącego powiązanego (tj.
z tym samym DataTransactionId w komunikatach
) komunikatu
więcej niż trzy razy
z rzędu.
5.7.2 Błędy łączności bezprzewodowej
DSC_80 Obsługa błędów związanych z łącznością jest zgodna z 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 bezprze­
wodowej 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.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 585
„Niepowodzenie odczytu” różni się pod względem technicznym od
„błędu”. W tym kontekście „błąd” oznacza pozyskanie błędnej wartości.
Dane przesłane do DSRC-VU są dostarczane w postaci już zabezpie­
czonej, 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ę przy­
padków, gdy faza „inicjowania” zapytania DSRC przebiegła
pomyślnie, ale transakcja zakończyła się, zanim REDCR
pomyślnie pobrał Dane. Dane te są udostępniane przedstawi­
cielowi właściwego organu kontrolnego i przechowywane
w pamięci urządzenia REDCR. Środkiem pozwalającym na
osiągnięcie tego celu jest kwestia projektu produktu lub
specyfikacja właściwego organu kontrolnego.
Jedyne znaczące dane na temat „błędów”, które można zareje­
strować, dotyczą liczby przypadków, gdy REDCR nie udało
się deszyfrować otrzymanych Danych. Należy jednak
zauważyć, że będzie to dotyczyło wyłącznie wydajności opro­
gramowania REDCR. Dane można technicznie deszyfrować,
ale będą pozbawione sensu pod względem semantycznym.
DSC_83 REDCR rejestruje zatem z sygnaturą czasową liczbę podję­
tych prób deszyfrowania danych otrzymanych przez interfejs
DSRC, które zakończyły się niepowodzeniem.
6 TESTY PRZEPROWADZANE PRZY ODDANIU DO EKSPLOA­
TACJI ORAZ TESTY W RAMACH PRZEGLĄDÓW OKRESOWYCH
FUNKCJI ŁĄCZNOŚCI NA ODLEGŁOŚĆ
6.1 Uwagi ogólne
DSC_84 Przewiduje się dwa rodzaje testów w odniesieniu do funkcji
łączności na odległość:
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 586
1) test ECHO w celu zatwierdzania kanału łączności bezprze­
wodowej DSRC-REDCR >>-:-
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 >>-:-
aktywne.
Celem polecenia ECHO jest umożliwienie warsztatom lub placówkom
przeprowadzających testy na potrzeby homologacji typu zbadania, czy
połączenie DSRC działa bez konieczności dostępu do poświadczeń
zabezpieczenia; Urządzenie testera musi być jedynie w stanie 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 >>-:-
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 — 21.08.2023 — 003.002 — 587
Addendum
Zasady obliczania dziennego, tygodniowego i dwutygodniowego czasu prowa­
dzenia pojazdu
1. Podstawowe zasady dokonywania obliczeń
VU oblicza dzienny czas prowadzenia pojazdu, tygodniowy czas prowadzenia
pojazdu i dwutygodniowy czas prowadzenia pojazdu z wykorzystaniem odpo­
wiednich danych zapisanych na karcie kierowcy (lub warsztatowej) włożonej
do szczeliny czytnika karty kierowcy (szczelina 1, czytnik karty #1) przyrządu
rejestrującego oraz wybranych czynności kierowcy w okresie, w którym karta
ta pozostaje włożona do VU.
Czasów prowadzenia pojazdu nie wlicza się, gdy żadna karta kierowcy (lub
warsztatowa) nie jest włożona.
Wszystkie okresy NIEOKREŚLONE wykryte w obrębie okresu potrzebnego
do obliczeń zalicza się do okresu PRZERWA/ODPOCZYNEK.
Nie uwzględnia się NIEOKREŚLONYCH okresów oraz czynności o ujemnym
czasie trwania (tzn. gdy początek czynności następuje później niż koniec
czynności) wynikających z nakładania się czasów dwóch różnych przyrządów
rejestrujących lub z korekty czasu.
Czynności zarejestrowane na karcie kierowcy odpowiadające okresom „POZA
ZAKRESEMS”, zgodnie z definicją w lit. gg) w załączniku IC, interpretuje
się w następujący sposób:
— Okresy PRZERWA/ODPOCZYNEK liczy się jak „PRZERWĘ” lub
„ODPOCZYNEK”.
— Okresy PRACA i PROWADZENIE uznaje się za „PRACĘ”.
— Okres GOTOWOŚĆ uznaje się za „GOTOWOŚĆ”.
W kontekście niniejszego addendum VU zakłada dzienny okres odpoczynku
na początku rekordów czynności na karcie.
2. Pojęcia
Poniższe pojęcia mają zastosowanie wyłącznie do niniejszego dodatku i mają
na celu określenie sposobu obliczania przez VU czasu prowadzenia pojazdu
i jego późniejszej transmisji przez urządzenie łączności na odległość.
a) „zmiana RTM” oznacza okres między końcem danego dziennego okresu
odpoczynku a końcem bezpośrednio następującego po nim dziennego
okresu odpoczynku.
VU uruchamia nową zmianę RTM po zakończeniu dziennego okresu
odpoczynku.
Trwająca zmiana RTM jest okresem od końca ostatniego dziennego okresu
odpoczynku;
b) „skumulowany czas prowadzenia pojazdu” oznacza sumę czasu trwania
wszystkich czynności PROWADZENIA wykonywanych przez kierowcę
w okresie innym niż okres stanu POZA ZAKRESEM;
c) „dzienny czas prowadzenia pojazdu” oznacza skumulowany czas prowa­
dzenia pojazdu w ramach zmiany RTM;
d) „tygodniowy czas prowadzenia pojazdu” oznacza skumulowany czas
prowadzenia pojazdu w trwającym tygodniu;
e) „nieprzerwany okres odpoczynku” oznacza nieprzerwany okres
PRZERWA/ODPOCZYNEK;
f) „tygodniowy czas prowadzenia pojazdu” oznacza skumulowany czas
prowadzenia pojazdu w poprzednim i trwającym tygodniu;
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 588
g) „dzienny okres odpoczynku” oznacza okres PRZERWA/ODPOCZYNEK,
który może być:
— regularnym dziennym okresem odpoczynku,
— dzielonym dziennym okresem odpoczynku lub
— skróconym dziennym okresem odpoczynku.
W kontekście dodatku 14, gdy VU oblicza tygodniowe okresy odpo­
czynku, okresy te uznaje się za dzienne okresy odpoczynku;
h) „regularny dzienny okres odpoczynku” oznacza nieprzerwany okres odpo­
czynku trwający co najmniej 11 godzin.
W drodze wyjątku, jeżeli stan PRZEPRAWA PROMOWA/POCIĄGOWA
jest aktywny, to regularny dzienny okres odpoczynku może zostać prze­
rwany maksymalnie dwa razy czynnościami innymi niż odpoczynek,
o maksymalnym skumulowanym czasie trwania wynoszącym jedną
godzinę, tzn. regularny dzienny okres odpoczynku zawierający okresy
przepraw promowych/pociągowych można podzielić na dwie lub trzy
części. VU zlicza następnie regularny dzienny okres odpoczynku, gdy
skumulowany czas odpoczynku obliczony zgodnie z pkt 3 wynosi co
najmniej 11 godzin.
W przypadku przerwania regularnego dziennego okresu odpoczynku przy­
rząd rejestrujący:
— nie uwzględnia czynności prowadzenia pojazdu zaistniałych podczas
tych przerw w obliczeniach dziennego czasu prowadzenia pojazdu oraz
— rozpoczyna nową zmianę RTM z końcem regularnego dziennego
okresu odpoczynku, który został przerwany.
Rysunek 1.
Przykład dziennego okresu odpoczynku przerwanego w związku z przeprawą promową/pociągową
i) „skrócony dzienny okres odpoczynku” oznacza nieprzerwany okres odpo­
czynku trwający co najmniej 9 godzin, ale mniej niż 11 godzin;
j) „dzielony dzienny okres odpoczynku” oznacza dzienny okres odpoczynku
wykorzystywany w dwóch częściach:
— pierwsza część to nieprzerwany okres odpoczynku trwający co
najmniej 3 godziny, ale mniej niż 9 godzin;
— druga część to nieprzerwany okres odpoczynku trwający co najmniej
9 godzin.
W drodze wyjątku, jeżeli stan PRZEPRAWA PROMOWA/POCIĄGOWA
jest aktywny podczas jednej lub obu części dzielonego dziennego okresu
odpoczynku, okres ten może zostać przerwany maksymalnie dwa razy
czynnościami innymi niż odpoczynek, o maksymalnym skumulowanym
czasie trwania wynoszącym jedną godzinę, tzn.:
— pierwszą część dzielonego dziennego okresu odpoczynku można prze­
rwać jeden raz bądź dwa razy lub
— drugą część dzielonego dziennego okresu odpoczynku można przerwać
jeden raz bądź dwa razy lub
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 589
— pierwszą część dzielonego dziennego okresu odpoczynku można prze­
rwać jeden raz i drugą część dzielonego dziennego okresu odpoczynku
można przerwać jeden raz.
VU zlicza następnie dzielony dzienny okres odpoczynku, gdy skumulo­
wany czas odpoczynku obliczony zgodnie z pkt 3 wynosi:
— co najmniej trzy godziny, ale mniej niż 11 godzin dla pierwszego
okresu odpoczynku, oraz co najmniej 9 godzin dla drugiego okresu
odpoczynku, jeżeli pierwszy okres odpoczynku został przerwany
przez PRZEPRAWĘ PROMOWĄ/POCIĄGOWĄ;
— co najmniej trzy godziny, ale mniej niż 9 godzin dla pierwszego okresu
odpoczynku, oraz co najmniej 9 godzin dla drugiego okresu odpo­
czynku, jeżeli pierwszy okres odpoczynku nie został przerwany przez
PRZEPRAWĘ PROMOWĄ/POCIĄGOWĄ.
Rysunek 2.
Przykład dzielonego dziennego okresu odpoczynku przerwanego w związku z przeprawą promową/pocią­
gową
W przypadku dzielonego dziennego okresu odpoczynku przyrząd rejestru­
jący:
— nie uwzględnia czynności prowadzenia pojazdu zaistniałych podczas
tych przerw w obliczeniach dziennego czasu prowadzenia pojazdu oraz
— rozpoczyna nową zmianę RTM z końcem dzielonego dziennego okresu
odpoczynku, który został przerwany;
k) „tydzień” oznacza okres w czasie UTC od godz. 00.00 w poniedziałek do
godz. 24:00 w niedzielę.
3. Obliczanie dziennego okresu odpoczynku przerwanego w związku z przeprawą
promową/pociągową
W celu obliczenia okresu odpoczynku, który został przerwany w związku
z przeprawą promową/pociągową, VU liczy skumulowany czas odpoczynku
zgodnie z następującymi krokami:
a) Krok 1
VU wykrywa przerwy w czasie odpoczynku, które wystąpiły przed akty­
wacją flagi PRZEPRAWA PROMOWA/POCIĄGOWA (POCZĄTEK),
zgodnie z rys. 3 i w stosownych przypadkach rys. 4, oraz ocenia w odnie­
sieniu do każdej wykrytej przerwy, czy spełnione są następujące warunki:
— przerwa powoduje, że całkowity czas trwania wykrytych przerw,
w tym w stosownych przypadkach przerw następujących w trakcie
pierwszej części dzielonego dziennego okresu odpoczynku w związku
z przeprawą promową/pociągową, przekracza łącznie ponad jedną
godzinę,
— przerwa powoduje, że całkowita liczba wykrytych przerw, w tym
w stosownych przypadkach przerw następujących w trakcie pierwszej
części dzielonego dziennego okresu odpoczynku w związku z prze­
prawą promową/pociągową, jest wyższa niż dwa,
— po zakończeniu przerwy przechowywany jest „Wpis miejsca zakoń­
czenia dziennego okresu pracy”.
Jeżeli żaden z powyższych warunków nie jest spełniony, nieprzerwany
okres odpoczynku bezpośrednio poprzedzający przerwę dodaje się do
skumulowanego czasu odpoczynku.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 590
Jeżeli spełniony jest co najmniej jeden z powyższych warunków, VU musi
zatrzymać obliczanie skumulowanego czasu odpoczynku zgodnie z krokiem
2 lub wykryć przerwy w czasie odpoczynku następujące po fladze PRZE­
PRAWA PROMOWA/POCIĄGOWA (POCZĄTEK) zgodnie z krokiem 3.
b) Krok 2
W odniesieniu do każdej przerwy wykrytej zgodnie z krokiem 1 VU
ocenia, czy należy zaprzestać obliczania skumulowanego czasu odpo­
czynku. VU zatrzymuje proces obliczeniowy, jeżeli do skumulowanego
czasu odpoczynku dodano dwa okresy nieprzerwanego odpoczynku,
które nastąpiły przed aktywacją flagi PRZEPRAWA PROMOWA/POCIĄ­
GOWA (POCZĄTEK), w tym w stosownych przypadkach okresy odpo­
czynku dodane do pierwszej części dzielonego dziennego okresu odpo­
czynku również przerwanego w związku z przeprawą promową/pocią­
gową. W przeciwnym razie VU postępuje zgodnie z krokiem 3.
c) Krok 3
Jeżeli po wykonaniu kroku 2 VU kontynuuje obliczanie skumulowanego
czasu odpoczynku, wykrywa przerwy następujące po dezaktywacji stanu
PRZEPRAWA PROMOWA/POCIĄGOWA zgodnie z rys. 3 i w stosow­
nych przypadkach rys. 4.
W odniesieniu do każdej wykrytej przerwy VU ocenia, czy przerwa powo­
duje, że całkowity czas wszystkich wykrytych przerw przekracza łącznie
ponad jedną godzinę, w którym to przypadku obliczanie skumulowanego
okresu odpoczynku ustaje z końcem nieprzerwanego okresu odpoczynku
poprzedzającego przerwę. W przeciwnym razie do obliczeń dziennego
okresu odpoczynku dodaje się nieprzerwane okresy odpoczynku następu­
jące po odpowiednich przerwach, aż do spełnienia warunku z kroku 4.
d) Krok 4
Obliczanie skumulowanego czasu odpoczynku zatrzymuje się po dodaniu
przez VU, w rezultacie zastosowania kroków 1 i 3, maksymalnie dwóch
nieprzerwanych okresów odpoczynku do okresu odpoczynku, w odniesieniu
do którego aktywowany jest stan PRZEPRAWA PROMOWA/POCIĄ­
GOWA, w tym w stosownych przypadkach przerw następujących w trakcie
pierwszej części dzielonego dziennego okresu odpoczynku w związku
z przeprawą promową/pociągową.
Rysunek 3.
Przetwarzanie czasów odpoczynku przez VU w celu ustalenia, czy przerwany okres odpoczynku liczy się
jako regularny dzienny okres odpoczynku, czy jako pierwszą część dzielonego dziennego okresu odpo­
czynku
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 591
Rysunek 4.
Przetwarzanie czasów odpoczynku przez VU w celu ustalenia, czy przerwany okres odpoczynku liczy się
jako drugą część dzielonego dziennego okresu odpoczynku
Rysunek 5.
Przykład dziennego okresu odpoczynku przerwanego więcej niż dwukrotnie, co powoduje, że okresu odpo­
czynku H nie uwzględnia się w obliczeniach
Rysunek 6.
Przykład dziennego okresu odpoczynku, w którym okres obliczeniowy prom/pociąg rozpoczyna się
z końcem okresu pracy
Rysunek 7.
Przykład dziennego okresu odpoczynku przerwanego więcej niż dwukrotnie, co powoduje, że okresu odpo­
czynku B nie uwzględnia się w obliczeniach
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 592
Rysunek 8.
Przykład dzielonego dziennego okresu odpoczynku przerwanego jeden raz w trakcie pierwszego okresu
odpoczynku i jeden raz w trakcie drugiego okresu odpoczynku
4. Obliczanie dziennego, tygodniowego i dwutygodniowego czasu prowadzenia
pojazdu
VU oblicza dzienne czasy prowadzenia pojazdu dla trwających i poprzednich
zmian RTM. Czasu prowadzenia pojazdu następującego podczas przerw
w dziennych okresach odpoczynku nie dodaje się do obliczeń dziennego
czasu prowadzenia pojazdu, jeżeli takie przerwy wynikają z przeprawy
promowej/pociągowej, a wymogi określone w pkt 2 lit. h) i j) oraz w pkt 3
zostały spełnione. Niemniej jednak, o ile VU nie policzył pełnego regularnego
lub dzielonego dziennego okresu odpoczynku zgodnie z pkt 3, czasy prowa­
dzenia pojazdu następujące podczas przerw dodaje się do dziennego czasu
prowadzenia pojazdu dla trwającej zmiany RTM.
VU liczy również tygodniowe i dwutygodniowe czasy prowadzenia pojazdu.
Czas prowadzenia pojazdu następujący podczas przerw w dziennych okresach
odpoczynku wynikających z przeprawy promowej/pociągowej dodaje się do
obliczeń tygodniowych i dwutygodniowych czasów prowadzenia pojazdu.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 593
Dodatek 15
MIGRACJA: ZARZĄDZANIE WSPÓŁISTNIENIEM GENERACJI
URZĄDZEŃ
▼B
SPIS TREŚCI
1. DEFINICJE
2. PRZEPISY OGÓLNE
2.1. Informacje ogólne na temat przejścia
▼M3
2.2. Interoperacyjność między VU a kartami
▼B
2.3. Interoperacyjność między VU a czujnikami ruchu
2.4. Interoperacyjność między przyrządami rejestrującymi, kartami do tacho­
grafu i urządzeniami służącymi do pobierania danych
2.4.1 Bezpośrednie pobieranie danych z karty przez inteligentne urządzenia
dedykowane
2.4.2 Pobieranie danych z karty za pomocą przyrządu rejestrują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 POPRZEDZAJĄCYM DATĘ
WPROWADZENIA
4. PRZEPISY DOTYCZĄCE OKRESU PO DACIE WPROWADZENIA
▼M3
5. REJESTROWANIE PRZEKROCZEŃ GRANICY W TACHOGRAFACH
PIERWSZEJ GENERACJI I PIERWSZEJ WERSJI DRUGIEJ GENE­
RACJI
▼B
1. DEFINICJE
Do celów niniejszego dodatku stosuje się następujące definicje:
system tachografu inteligentnego: zgodnie z definicją zawartą w niniej­
szym załączniku (rozdział 1: definicja bbb));
system tachografu pierwszej generacji: zgodnie z definicją zawartą
w niniejszym rozporządzeniu (art. 2: definicja 1));
system tachografu drugiej generacji: zgodnie z definicją zawartą
w niniejszym rozporządzeniu (art. 2: definicja 7));
data wprowadzenia: zgodnie z definicją zawartą w niniejszym załączniku
(rozdział 1: definicja ccc));
inteligentne urządzenie dedykowane (IDE): urządzenie służące do prze­
prowadzania operacji pobierania danych, zgodnie z definicją zawartą
w dodatku 7 do niniejszego załącznika.
▼M3
2. PRZEPISY OGÓLNE
2.1. Informacje ogólne na temat przejścia
Wprowadzenie do niniejszego załącznika zawiera ogólne informacje na
temat przejścia między systemami tachografu pierwszej i drugiej generacji
oraz wprowadzenia drugiej wersji drugiej generacji urządzeń rejestrują­
cych i kart do tachografów.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 594
Oprócz przepisów zawartych w tym wprowadzeniu należy przypomnieć
następujące informacje:
— czujniki ruchu pierwszej generacji nie są interoperacyjne z żadną
wersją przyrządów rejestrujących drugiej generacji,
— w pojazdach wyposażonych w dowolną wersję przyrządów rejestrują­
cych drugiej generacji można instalować wyłącznie czujniki ruchu
drugiej generacji,
— urządzenia do pobierania i kalibracji danych muszą umożliwiać korzy­
stanie z obu generacji lub wersji urządzeń rejestrujących i kart do
tachografów.
2.2. Interoperacyjność między VU a kartami
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 dowolnej wersji drugiej generacji są interoperacyjne z przyrzą­
dami rejestrującymi dowolnej wersji drugiej generacji (zgodnie z załączni­
kiem IC do niniejszego rozporządzenia). Ponadto zastosowanie mają
przedstawione poniżej wymogi.
MIG_001 Z wyjątkiem treści wymogów MIG_004 i MIG_005, karty do
tachografu pierwszej generacji mogą być nadal używane
w dowolnej wersji przyrządów rejestrujących drugiej generacji
do upływu daty ich ważności. Właściciele takich kart mogą
jednak wystąpić z wnioskiem o ich wymianę na karty do
tachografu drugiej generacji, jak tylko te drugie karty staną
się dostępne.
MIG_002 Przyrządy rejestrujące dowolnej wersji drugiej 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
dowolnej wersji drugiej generacji rozpoznają wyłącznie typy
włożonych ważnych kart, bez względu na ich generację lub
wersję.
MIG_006 Każda ważna karta do tachografu dowolnej wersji drugiej
generacji musi umożliwiać jej zastosowanie w przyrządach
rejestrujących pierwszej generacji w dokładnie taki sam
sposób jak karty do tachografu pierwszej generacji tego
samego typu.
2.3. Interoperacyjność między VU a czujnikami ruchu
Przyjmuje się, że czujniki ruchu pierwszej generacji są interoperacyjne
z przyrządami rejestrującymi pierwszej generacji, natomiast czujniki
ruchu drugiej generacji są interoperacyjne z przyrządami rejestrującymi
dowolnej wersji drugiej generacji. Ponadto zastosowanie mają przedsta­
wione poniżej wymogi.
MIG_007 Przyrządów rejestrujących dowolnej wersji drugiej generacji
nie można parować ani używać z czujnikami ruchu pierwszej
generacji.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 595
MIG_008 Czujniki ruchu drugiej generacji można parować i używać
wyłącznie z przyrządami rejestrującymi drugiej generacji,
bez względu na wersję, lub z obiema generacjami przyrządów
rejestrujących.
2.4. Interoperacyjność między przyrządami rejestrującymi, kartami do
tachografu i urządzeniami służącymi do pobierania danych
MIG_009 Urządzenia do pobierania danych mogą być kompatybilne ze
wszystkimi generacjami i wersjami przyrządów rejestrujących
i kart do tachografów.
2.4.1. Bezpośrednie pobieranie danych z karty przez inteligentne urządzenia
dedykowane
MIG_010 Inteligentne urządzenia dedykowane pobierają dane z 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 i wersji.
MIG_011 Aby organy kontrolne spoza UE mogły kontrolować
kierowców, należy umożliwić pobieranie danych z kart
kierowców (i kart warsztatowych) drugiej generacji, bez
względu na wersję, w dokładnie taki sam sposób, w jaki
pobierane są dane z kart kierowców (i kart warsztatowych)
pierwszej generacji. Tego rodzaju pobieranie obejmuje:
— niepodpisane pliki elementarne IC i ICC (opcjonalnie),
— niepodpisane pliki elementarne (pierwszej generacji)
Card_Certificate i CA_Certificate,
— pliki elementarne zawierające inne dane aplikacyjne
(w pliku DF Tachograph) żądane przez protokół pobie­
rania danych z kart pierwszej generacji. Informacje takie
muszą być zabezpieczone podpisem cyfrowym zgodnie
z mechanizmami zabezpieczenia pierwszej generacji.
Tego rodzaju pobieranie nie może obejmować plików
elementarnych zawierających dane aplikacyjne istnieją­
cych wyłącznie w kartach kierowców (i kartach warsz­
tatowych) wersji 1 lub wersji 2 drugiej generacji (pliki
elementarne zawierające dane aplikacyjne w pliku DF
Tachograph_G2).
2.4.2. Pobieranie danych z karty za pomocą przyrządu rejestrującego
MIG_012 Dane z dowolnej wersji karty drugiej generacji włożonej do
przyrządu rejestrującego pierwszej generacji są pobierane za
pomocą protokołu pobierania danych pierwszej generacji.
Karta taka odpowiada na polecenia przyrządu rejestrującego
w dokładnie taki sam sposób jak karta pierwszej generacji,
a pobierane dane mają taki sam format jak dane pobierane
z karty pierwszej generacji.
MIG_013 Dane z karty pierwszej generacji włożonej do przyrządu rejes­
trującego dowolnej wersji drugiej generacji są pobierane za
pomocą protokołu pobierania danych określonego w dodatku
7 do niniejszego załącznika. Przyrząd rejestrujący wysyła
polecenia do karty w dokładnie taki sam sposób jak przyrząd
rejestrujący pierwszej generacji, a pobierane dane mają format
określony w odniesieniu do kart pierwszej generacji.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 596
2.4.3. Pobieranie danych z przyrządów rejestrujących
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 w odniesieniu do
odpowiedniej wersji.
MIG_015 Aby organy kontrolne spoza UE mogły kontrolować
kierowców, opcjonalnie można również umożliwić pobieranie
danych z przyrządów rejestrujących dowolnej wersji drugiej
generacji z zastosowaniem mechanizmów zabezpieczenia
pierwszej generacji. Pobierane dane mają wtedy taki sam
format, jak dane pobierane z przyrządu rejestrującego pierw­
szej generacji. Funkcję tę można wybrać za pomocą poleceń
w menu.
2.5. Interoperacyjność między VU a urządzeniami do kalibracji
MIG_016 Urządzenia do kalibracji muszą być w stanie przeprowadzać
kalibrację tachografów każdej generacji lub wersji, z zastoso­
waniem protokołu kalibracyjnego danej generacji lub wersji.
Urządzenia do kalibracji mogą być kompatybilne ze wszyst­
kimi generacjami i wersjami przyrządów rejestrujących.
3. GŁÓWNE DZIAŁANIA W OKRESIE POPRZEDZAJĄCYM DATĘ
WPROWADZENIA
MIG_017 Klucze testowe i certyfikaty muszą zostać udostępnione
producentom najpóźniej z dniem publikacji niniejszego
załącznika.
MIG_018 Badania interoperacyjności muszą być gotowe do rozpoczęcia
w odniesieniu do wersji 2 przyrządów rejestrujących i wersji
2 kart do tachografów, na wniosek producentów, najpóźniej
15 miesięcy przed datą wprowadzenia.
MIG_019 W przypadku wersji 2 generacji 2 tachografów, kart do tacho­
grafów i czujników ruchu stosuje się te same klucze i certyfi­
katy, co w przypadku urządzeń wersji 1 generacji 2.
MIG_020 Państwa członkowskie muszą być w stanie rozpocząć wyda­
wanie kart warsztatowych wersji 2 drugiej generacji najpóź­
niej 1 miesiąc przed datą wprowadzenia.
MIG_021 Państwa członkowskie muszą być w stanie rozpocząć wyda­
wanie wszystkich innych typów wersji 2 drugiej generacji kart
do tachografu najpóźniej 1 miesiąc przed datą wprowadzenia.
4. PRZEPISY DOTYCZĄCE OKRESU PO DACIE WPROWADZENIA
MIG_022 Po upływie daty wprowadzenia państwa członkowskie wydają
wyłącznie karty do tachografu wersji 2 drugiej generacji.
MIG_023 Producenci przyrządów rejestrujących / czujników ruchu
mogą produkować przyrządy rejestrujące / czujniki ruchu
pierwszej generacji, dopóki są one wykorzystywane
w danym obszarze, tak aby była możliwa wymiana niepra­
widłowo działających elementów składowych.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 597
MIG_023a Ze skutkiem od daty wprowadzenia, nieprawidłowo działające
przyrządy rejestrujące lub urządzenia zewnętrzne GNSS
wersji 1 drugiej generacji zastępuje się przyrządami rejestru­
jącymi lub urządzeniami zewnętrznymi GNSS wersji 2 drugiej
generacji.
MIG_024 Producenci przyrządów rejestrujących / czujników ruchu
mogą ubiegać się o utrzymanie homologacji typu oraz
uzyskać zgodę na takie utrzymanie w przypadku pierwszej
generacji przyrządów rejestrujących / czujników ruchu lub
wersji 1 drugiej generacji przyrządów rejestrujących, posiada­
jących już homologację typu.
5. REJESTROWANIE PRZEKROCZEŃ GRANICY W TACHOGRAFACH
PIERWSZEJ GENERACJI I PIERWSZEJ WERSJI DRUGIEJ GENE­
RACJI
MIG_025 Symbol kraju oraz, w stosownych przypadkach, regionu, do
którego kierowca wjeżdża po przekroczeniu granicy państwa
członkowskiego zgodnie z art. 34 ust. 7 rozporządzenia (UE)
nr 165/2014, wpisuje się jako miejsce, w którym rozpoczyna
się dzienny okres pracy, zgodnie z ręcznym wprowadzaniem
miejsc określonym w wymogu 60 w załączniku IC do rozpo­
rządzenia (UE) nr 165/2014 oraz wymogu 50 w załączniku IB
do rozporządzenia (EWG) nr 3821/85.
▼M3
02016R0799 — PL — 21.08.2023 — 003.002 — 598
Dodatek 16.
ADAPTER DO POJAZDÓW KATEGORII M1 I N1
SPIS TREŚCI
1. SKRÓTY I DOKUMENTY REFERENCYJNE
1.1. Skróty
1.2. Normy referencyjne
2. OGÓLNA CHARAKTERYSTYKA I FUNKCJE ADAPTERA
2.1. Ogólny opis adaptera
2.2. Funkcje
2.3. Zabezpieczenie
3. WYMAGANIA DOTYCZĄCE URZĄDZEŃ REJESTRUJĄCYCH
W PRZYPADKU ZAMONTOWANIA ADAPTERA
4. WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE
W STOSUNKU DO ADAPTERA
4.1. Odbiór i przetwarzanie wejściowych impulsów prędkości
4.2. Przekazywanie odbieranych impulsów do wbudowanego czujnika ruchu
4.3. Wbudowany czujnik ruchu
4.4. Wymogi bezpieczeństwa
4.5. Parametry pracy
4.6. Materiały
4.7. Oznakowania
5. INSTALACJA URZĄDZENIA REJESTRUJĄCEGO W PRZYPADKU
ZASTOSOWANIA ADAPTERA
5.1. Instalacja
5.2. Plombowanie
6. KONTROLE, PRZEGLĄDY I NAPRAWY
6.1. Przeglądy okresowe
7. HOMOLOGACJA TYPU URZĄDZENIA REJESTRUJĄCEGO W PRZY­
PADKU ZASTOSOWANIA ADAPTERA
7.1. Uwagi ogólne
7.2. Świadectwo funkcjonalności
1. SKRÓTY I DOKUMENTY REFERENCYJNE
1.1. Skróty
TBD Do ustalenia
VU Przyrząd rejestrujący
1.2. Normy referencyjne
ISO 16844-3 Pojazdy drogowe – Tachografy – Część 3: Podłączenie
czujnika ruchu
2. OGÓLNA CHARAKTERYSTYKA I FUNKCJE ADAPTERA
2.1. Ogólny opis adaptera
ADA_001 Adapter dostarcza podłączonemu do niego VU (przyrządowi
rejestrującemu) w sposób pewny i ciągły dane o ruchu
pojazdu, odwzorowujące jego prędkość i przebytą drogę.
Adapter przeznaczony jest wyłącznie do pojazdów, które
muszą być wyposażone w urządzenie rejestrujące zgodnie
z niniejszym rozporządzeniem.
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 599
Instaluje się go i używa wyłącznie w pojazdach określonych
w definicji yy) „adapter” w załączniku IC, w których z mecha­
nicznego punktu widzenia niemożliwy jest montaż stosowa­
nych czujników ruchu innego rodzaju, pod innym względem
zgodnych z wymaganiami przedstawionymi w niniejszym
załączniku i w dodatkach 1–16 do niniejszego załącznika.
Adapter nie może być mechanicznie sprzężony z ruchomą
częścią pojazdu, lecz podłącza się go do impulsów prędkości/
przebytej drogi, które są generowane przez zintegrowane czuj­
niki lub alternatywne interfejsy.
ADA_002 Czujnik ruchu posiadający homologację typu (zgodnie z 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 adap­
terem było zgodne z wymaganiami ISO16844-3.
2.2. Funkcje
ADA_003 Adapter realizuje następujące funkcje:
— odbiór i adaptacja wejściowych impulsów pomiaru pręd­
kości;
— przekazywanie odbieranych impulsów do wbudowanego
czujnika ruchu;
— wszystkie funkcje wbudowanego czujnika ruchu przekazują
w sposób pewny dane o ruchu pojazdu do VU.
2.3. Zabezpieczenie
ADA_004 Adapter nie musi posiadać certyfikacji bezpieczeństwa 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 — 21.08.2023 — 003.002 — 600
— zdarzenie „błąd danych dotyczących ruchu” jest wyzwalane
przez UV w przypadku przerwy w normalnym strumieniu
danych między wbudowanym czujnikiem ruchu a VU lub
w przypadku błędu spójności lub autentyczności danych,
który występuje podczas wymiany danych między wbudo­
wanym czujnikiem ruchu a VU [83];
— zdarzenie „próba naruszenia zabezpieczenia” jest wyzwa­
lane przez VU w przypadku każdego zdarzenia mającego
wpływ na zabezpieczenie wbudowanego czujnika ruchu,
o ile nie jest on w trybie kalibracyjnym [85];
— usterka „urządzenie rejestrujące” jest wyzwalana przez VU,
o ile nie jest on w trybie kalibracyjnym, w przypadku
każdej usterki wbudowanego czujnika ruchu [88].
ADA_008 Usterki adaptera wykrywalne przez urządzenie rejestrujące to
usterki związane z wbudowanym czujnikiem ruchu [88].
ADA_009 Funkcja kalibracji VU pozwala na automatyczne 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.
▼M3
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
(od 2 400 do 25 000 impulsów/km). Wartość stałej może
zaprogramować wyłącznie producent adaptera lub zatwier­
dzony warsztat instalujący adapter.
▼B
4.2. Przekazywanie odbieranych impulsów do wbudowanego czujnika
ruchu
ADA_013 Impulsy wejściowe, poddane ewentualnej adaptacji w sposób
opisany powyżej, przekazywane są do wbudowanego czujnika
ruchu w taki sposób, że każdy wejściowy impuls wykrywany
jest przez czujnik ruchu.
4.3. Wbudowany czujnik ruchu
ADA_014 Wbudowany czujnik ruchu stymulowany jest przez przekazy­
wane impulsy, co pozwala mu na wytwarzanie danych o ruchu,
dokładnie odwzorowujących ruch pojazdu w taki sposób, jakby
był on mechanicznie sprzężony z ruchomą częścią pojazdu.
ADA_015 VU wykorzystuje dane identyfikacyjne wbudowanego czujnika
ruchu do identyfikacji adaptera [95].
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 601
ADA_016 Dane instalacyjne przechowywane we wbudowanym czujniku
ruchu uważa się za dane instalacyjne adaptera [122].
4.4. Wymogi bezpieczeństwa
ADA_017 Obudowa adaptera musi być wykonana w sposób uniemożli­
wiający jej otwarcie. Musi być zaplombowana, by łatwo można
było wykryć próby fizycznej ingerencji (np. w drodze oglę­
dzin, zob. ADA_035). Plomby muszą spełniać te same wymogi
co plomby czujników ruchu [398–406].
ADA_018 Należy wykluczyć możliwość usunięcia wbudowanego czuj­
nika ruchu z adaptera bez naruszania plomb założonych na
obudowę adaptera lub uszkodzenia plomb między czujnikiem
a obudową adaptera (zob. ADA_034).
ADA_019 Konstrukcja adaptera musi być taka, by dane o ruchu mogły
być przetwarzane i odbierane tylko z wejścia adaptera.
4.5. Parametry pracy
ADA_020 Adapter musi realizować wszystkie funkcje w zakresie 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 — 21.08.2023 — 003.002 — 602
— numer identyfikacyjny pojazdu, w którym zainstalowano
dany adapter.
ADA_028 Na tabliczce opisowej umieszcza się również następujące dane,
jeżeli nie można ich bezpośrednio odczytać z zewnątrz na
wbudowanym czujniku ruchu:
— nazwa producenta wbudowanego czujnika ruchu;
— numer części producenta i rok produkcji wbudowanego
czujnika ruchu;
— znak homologacji wbudowanego czujnika ruchu.
5. INSTALACJA URZĄDZENIA REJESTRUJĄCEGO W PRZYPADKU
ZASTOSOWANIA ADAPTERA
5.1. Instalacja
ADA_029 Adaptery przeznaczone do zamontowania w pojazdach są
montowane wyłącznie przez producentów pojazdów, bądź
przez zatwierdzone warsztaty, upoważnione do instalacji, akty­
wacji oraz kalibracji tachografów cyfrowych i inteligentnych.
ADA_030 Taki zatwierdzony warsztat instalujący adaptery musi 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 zasi­
lania) i czarne (masa).
5.2. Plombowanie
ADA_034 W odniesieniu do plombowania zastosowanie mają następujące
wymagania:
— obudowa adaptera musi być zaplombowana (zob.
ADA_017);
— obudowa wbudowanego czujnika ruchu musi być połą­
czona plombą z obudową adaptera, chyba że nie można
usunąć czujnika ruchu z obudowy adaptera bez naruszania
plomby(plomb) obudowy adaptera (zob. ADA_018);
— obudowa adaptera musi być połączona plombą z pojazdem;
— połączenie między adapterem a urządzeniem będącym
źródłem impulsów wejściowych musi być zaplombowane
na obu końcach (na tyle, na ile jest to możliwe).
6. KONTROLE, PRZEGLĄDY I NAPRAWY
6.1. Przeglądy okresowe
ADA_035 Każdy przegląd okresowy (przegląd okresowy oznacza prze­
gląd zgodny z wymaganiami [409]–[413] zawartymi w załącz­
niku 1C) urządzenia rejestrującego w przypadku zastosowania
adaptera obejmuje sprawdzenie:
— czy na adapterze znajdują się odpowiednie znaki homolo­
gacji typu;
— czy plomby na adapterze i jego podłączeniach są
nienaruszone;
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 603
— czy adapter zainstalowano zgodnie z informacjami poda­
nymi na tabliczce instalacyjnej;
— czy adapter zainstalowano zgodnie z instrukcjami produ­
centa adaptera lub pojazdu;
— czy dopuszcza się instalację adaptera w kontrolowanym
pojeździe.
ADA_036 Przedmiotowe przeglądy obejmują kalibrację i wymianę
wszystkich plomb, niezależnie od ich stanu.
7. HOMOLOGACJA TYPU URZĄDZENIA REJESTRUJĄCEGO W PRZY­
PADKU ZASTOSOWANIA ADAPTERA
7.1. Uwagi ogólne
ADA_037 Urządzenie rejestrujące dostarcza się do homologacji 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 wyma­
gania
1. Badanie administracyjne
1.1 Dokumentacja Prawidłowość doku­
mentacji adaptera
2. Kontrola wizualna
2.1. Zgodność adaptera z dokumentacją
2.2. Identyfikacja / oznakowania adaptera ADA_027,
ADA_028
2.3 Materiały, z których wykonany jest adapter [219]–[223]
ADA_026
2.4. Plombowanie ADA_017,
ADA_018,
ADA_034
3. Badania funkcjonalności
3.1 Przekazywanie impulsów prędkości do wbudo­
wanego czujnika ruchu
ADA_013
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 604
Nr Badanie Wyszczególnienie
Odpowiednie wyma­
gania
3.2 Odbiór i przetwarzanie wejściowych impulsów
prędkości
ADA_011,
ADA_012
3.3 Dokładność pomiaru ruchu [30]–[35], [217]
4. Badania środowiskowe
4.1 Wyniki badań producenta Wyniki badań
środowiskowych
przeprowadzonych
przez producenta
ADA_020,
ADA_021,
ADA_022,
ADA_024
5. EMC (kompatybilność elektromagnetyczna)
5.1 Emisje radiacyjne i wrażli­
wość na radiację
Sprawdzenie zgod­
ności z przepisami
dyrektywy 2006/28/
WE
ADA_024
5.2 Wyniki badań producenta Wyniki badań
środowiskowych
przeprowadzonych
przez producenta
ADA_024
▼B
02016R0799 — PL — 21.08.2023 — 003.002 — 605
Dodatek 17
PRZEPISY PRZEJŚCIOWE ZWIĄZANE Z KORZYSTANIEM PRZEZ
TACHOGRAFY Z OSNMA
1. DEFINICJE I AKRONIMY
1.1. Definicje
Deklaracja usługi uwierzytelniania komunikatów nawigacyjnych
usługi otwartej Galileo (OSNMA) oznacza deklarację Komisji Europej­
skiej, że OSNMA Galileo wchodzi w fazę operacyjną.
Przejściowy przyrząd rejestrujący: przyrząd rejestrujący zgodny z prze­
pisami niniejszego dodatku.
Przejściowe przyrządy rejestrujące są konstruowane zgodnie z dokumentem
kontroli interfejsu sygnału w przestrzeni (SIS ICD) i wytycznymi dla
odbiorników w zakresie OSNMA, mającymi zastosowanie w fazie testów
publicznych OSNMA. Są wyposażone w odbiornik GNSS, który umoż­
liwia korzystanie z usługi OSNMA dostępnej w fazie testów publicznych.
Przejściowe przyrządy rejestrujące nie są jednak w stanie uwierzytelnić
komunikatów nawigacyjnych dostępnych po złożeniu deklaracji usługi
OSNMA ze względu na niezbędną aktualizację materiału kryptograficz­
nego w przyrządzie rejestrującym. Należy dokonać odpowiedniej aktuali­
zacji oprogramowania, tak aby mogły one zacząć korzystać z OSNMA
i spełnić wszystkie wymogi załącznika IC oraz dodatków 1–16 do tego
załącznika. Przed aktualizacją przejściowe przyrządy rejestrujące wdrażają
funkcje związane z OSNMA zgodnie z niniejszym dodatkiem. Funkcje
niezwiązane z OSNMA pozostają niezmienione.
Po dokonaniu odpowiedniej aktualizacji oprogramowania przejściowe
przyrządy rejestrujące wdrażają dokument SIS ICD i wytyczne dla odbior­
ników w zakresie OSNMA, mające zastosowanie w fazie operacyjnej
OSNMA, oraz spełniają wszystkie wymogi załącznika IC i dodatków
1–16 do tego załącznika, przy korzystaniu z usługi OSNMA dostępnej
w fazie operacyjnej.
Przejściowy tachograf: tachograf wyposażony w przejściowy przyrząd
rejestrujący.
1.2. Akronimy
ICD Dokument kontroli interfejsu
OSNMA Galileo Open Service Navigation Message Authen­
tication [uwierzytelnianie komunikatów nawigacyj­
nych usługi otwartej Galileo]
SIS Sygnał w przestrzeni
VU Przyrząd rejestrujący
▼M4
02016R0799 — PL — 21.08.2023 — 003.002 — 606
2. UWAGI OGÓLNE DOTYCZĄCE OSNMA
Aby zapewnić możliwość wyposażenia pojazdów rejestrowanych po raz
pierwszy w wersję 2 tachografów drugiej generacji, począwszy od wnio­
skowanej daty wprowadzenia określonej w sekcji 1 lit. ccc) załącznika IC
do rozporządzenia wykonawczego (UE) 2016/799, konieczne jest uzys­
kanie homologacji typu, wyprodukowanie i wprowadzenie do obrotu przy­
rządów rejestrujących przed złożeniem deklaracji usługi OSNMA. W przy­
padku tych przyrządów rejestrujących, określanych jako przejściowe przy­
rządy rejestrujące, należy dostosować wymogi dotyczące OSNMA okre­
ślone w załączniku IC i w dodatkach 1–16 do tego załącznika, tak aby
mogły one uzyskać homologację typu i być wykorzystywane w terenie.
W przepisach zawartych w niniejszym dodatku określono szczególne
wymogi mające zastosowanie do przejściowych przyrządów rejestrują­
cych. Mają one zastosowanie wyłącznie do przyrządów rejestrujących
wyposażonych w wewnętrzny odbiornik GNSS.
3. WYMOGI MAJĄCE ZASTOSOWANIE DO ODBIORNIKA GNSS
W TACHOGRAFACH PRZEJŚCIOWYCH
TRA_001 Przejściowe przyrządy rejestrujące są wyposażone w odbiornik
GNSS, który umożliwia korzystanie z usługi OSNMA dostępnej w fazie
testów publicznych.
TRA_002 Wymogi określone w dodatku 12 mają zastosowanie do
odbiornika GNSS znajdującego się w przejściowych przyrządach rejestru­
jących, przy czym zastosowanie mają następujące wykładnie:
— wspomniane wyżej dokument SIS ICD i wytyczne dla odbiorników
w zakresie OSNMA to dokumenty dostępne na potrzeby fazy testów
publicznych:
— „Galileo Open Service Navigation Message Authentication
(OSNMA) User ICD for the Test Phase” [„Uwierzytelnianie komu­
nikatów nawigacyjnych usługi otwartej Galileo – dokument
kontroli interfejsu dla użytkownika na potrzeby fazy testowej”],
wersja 1.0, listopad 2021,
— „Galileo Open Service Navigation Message Authentication
(OSNMA) Receiver Guidelines for the Test Phase” [„Uwierzytel­
nianie komunikatów nawigacyjnych usługi otwartej Galileo –
wytyczne dotyczące odbiornika na potrzeby fazy testowej”], wersja
1.0, listopad 2021,
— OSNMA to usługa dostępna w fazie testów publicznych,
— SIS to sygnał w przestrzeni dostępny w fazie testów publicznych.
TRA_003 Odbiornik GNSS znajdujący się w przejściowych przyrządach
rejestrujących jest tak skonstruowany, aby po aktualizacji jego oprogra­
mowania, dokonanej poprzez aktualizację oprogramowania przyrządu
rejestrującego, w pełni spełniał wymogi załącznika 12 przy korzystaniu
z usługi OSNMA dostępnej w fazie operacyjnej.
4. WYMOGI MAJĄCE ZASTOSOWANIE DO PRZEJŚCIOWYCH PRZY­
RZĄDÓW REJESTRUJĄCYCH
Przejściowe przyrządy rejestrujące mogą przetwarzać sygnał OSNMA
dostępny w publicznej fazie testowej, ale nie mają możliwości zgłaszania
statusu uwierzytelnienia komunikatów nawigacyjnych z SIS dostępnego
w fazie operacyjnej OSNMA do czasu dokonania odpowiedniej aktuali­
zacji oprogramowania. W związku z tym przyjmują one, że standardowe
pozycje przekazywane przez odbiornik GNSS są zawsze uwierzytelnione.
Obowiązują wymogi określone w załączniku IC i dodatkach 1-16 do tego
załącznika, przy czym stosuje się poniższe wykładnie.
▼M4
02016R0799 — PL — 21.08.2023 — 003.002 — 607
TRA_004 Załącznik IC, pkt 3.9.15 – Zdarzenie „konflikt czasu”, wymóg
86, należy rozumieć w następujący sposób:
Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się, jeżeli
przyrząd rejestrujący wykryje rozbieżność między czasem określonym
przez funkcję pomiaru czasu w przyrządzie rejestrującym a czasem pocho­
dzącym ze standardowych pozycji przekazywanych przez odbiornik GNSS
lub urządzenie zewnętrzne GNSS. „Rozbieżność czasu” wykrywa się, jeżeli
różnica czasu przekracza ± 3 sekundy, co odpowiada dokładności czasu
określonej w wymogu 41a, przy czym ta ostatnia wartość zwiększa się
o maksymalny dzienny dryft czasu. Zdarzenie to jest rejestrowane wraz
z wartością wyświetlaną na wewnętrznym zegarze urządzenia rejestrują­
cego. Przyrząd rejestrujący dokonuje sprawdzenia w celu uruchomienia
zdarzenia „konflikt czasowy” tuż przed automatycznym dostosowaniem
wewnętrznego zegara VU, zgodnie z wymogiem 211.
TRA_005 Załącznik IC, pkt 3.9.18 – Zdarzenie „anomalia GNSS”,
wymóg 88a, należy rozumieć w następujący sposób:
Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się, gdy
odbiornik GNSS wykryje atak , jak określono w dodatku 12. Po urucho­
mieniu zdarzenia anomalii GNSS przyrząd rejestrujący nie generuje
innych zdarzeń anomalii GNSS przez kolejnych 10 minut.
TRA_006 Załącznik IC, pkt 3.12.5 – Rejestracja i przechowywanie
w pamięci danych – 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, wymóg 110, należy rozumieć w następujący
sposób:
Wraz z miejscem lub pozycją urządzenie rejestrujące rejestruje i przecho­
wuje w pamięci następujące dane:
— numer karty kierowcy lub współkierowcy i państwo członkowskie
wydające kartę,
— generację karty,
— datę i godzinę wpisu,
— rodzaj wpisu (rozpoczęcie, zakończenie lub 3 godziny skumulowanego
czasu prowadzenia pojazdu),
— w stosownych przypadkach odpowiednią dokładność GNSS, datę
i godzinę,
— stan licznika kilometrów,
— flagę wskazującą, czy pozycję uznano za uwierzytelnioną.
TRA_007 Załącznik IC, pkt 3.12.17 – Rejestracja i przechowywanie
w pamięci danych – Przekroczenia granicy, wymóg 133b, należy rozumieć
w następujący sposób:
Wraz z krajami i pozycją urządzenie rejestrujące rejestruje i przechowuje
w pamięci następujące dane:
— numer karty kierowcy lub współkierowcy i państwo członkowskie
wydające kartę,
— generację karty,
— odpowiednią dokładność GNSS, datę i godzinę,
— flagę wskazującą, czy pozycję uznano za uwierzytelnioną,
— stan licznika kilometrów w momencie wykrycia przekroczenia granicy.
▼M4
02016R0799 — PL — 21.08.2023 — 003.002 — 608
TRA_008 Załącznik IC, pkt 3.12.18 – Rejestracja i przechowywanie
w pamięci danych – Operacje załadunku/rozładunku, wymóg 133 g,
należy rozumieć w następujący sposób:
Wraz z typem operacji i pozycją urządzenie rejestrujące rejestruje i prze­
chowuje w pamięci następujące dane:
— numer karty kierowcy lub współkierowcy i państwo członkowskie
wydające kartę,
— generację karty,
— datę i godzinę operacji załadunku/rozładunku,
— w stosownych przypadkach odpowiednią dokładność GNSS, datę
i godzinę,
— flagę wskazującą, czy pozycję uznano za uwierzytelnioną,
— stan licznika kilometrów.
TRA_009 Załącznik IC, pkt 3.23 – Korekta czasu, wymóg 211, należy
rozumieć w następujący sposób:
Ustawienia czasu wewnętrznego zegara przyrządu rejestrującego są auto­
matycznie korygowane w zmiennych odstępach czasu. Kolejna automa­
tyczna korekta czasu uruchamiana jest między 72 a 168 godz. po poprzed­
niej korekcie oraz po tym, jak VU będzie mógł uzyskać dostęp do czasu
GNSS za pomocą komunikatu o prawidłowej uwierzytelnionej pozycji
zgodnie z dodatkiem 12. Niemniej jednak korekta czasu nie może nigdy
przekroczyć skumulowanego maksymalnego dryftu czasu na dzień, obli­
czonego przez producenta VU zgodnie z wymogiem 41b. Jeżeli różnica
między czasem wewnętrznego zegara VU a czasem odbiornika GNSS jest
większa niż skumulowany maksymalny dryft czasu na dzień, wówczas
korekta czasu musi dostosować zegar wewnętrzny VU możliwie jak
najbliżej czasu odbiornika GNSS. Ustawienia czasu można dokonać
tylko wówczas, gdy czas podawany przez odbiornik GNSS jest uzyski­
wany przy użyciu komunikatów o uwierzytelnionej pozycji określonych
w dodatku 12. Czasem odniesienia dla automatycznego ustawienia czasu
wewnętrznego zegara VU jest czas podany w komunikacie o uwierzytel­
nionej pozycji.
TRA_010 Załącznik IC, pkt 3.23 – Korekta czasu, wymóg 212, należy
rozumieć w następujący sposób:
W trybie kalibracyjnym funkcja korekty czasu umożliwia również wymu­
szoną korektę bieżącego czasu.
Warsztaty mogą korygować czas:
— albo zapisując wartość czasu w VU, korzystając z usługi WriteData­
ByIdentifier zgodnie z sekcją 6.2 w dodatku 8,
— albo poprzez zwrócenie się o dostosowanie zegara VU do czasu poda­
wanego przez odbiornik GNSS. Można tego dokonać tylko wówczas,
gdy czas podawany przez odbiornik GNSS jest uzyskiwany przy użyciu
komunikatów o standardowej pozycji. W tym ostatnim przypadku wyko­
rzystuje się usługę RoutineControl zgodnie z sekcją 8 w dodatku 8.
▼M4
02016R0799 — PL — 21.08.2023 — 003.002 — 609
TRA_011 Dodatek 4, pkt 2 – Specyfikacja bloków danych, akapit
pierwszy tiret siódme, należy rozumieć w następujący sposób:
W przypadku wydruku po długości i szerokości geograficznej zarejestro­
wanej pozycji lub po znaczniku czasu, gdy pozycja została określona,
piktogram wskazuje, że pozycję tę uznano za uwierzytelnioną.
TRA_012 Dodatek 8, pkt 8.1 – Usługa RoutineControl (korekta czasu) –
Opis komunikatu, wymóg CPR_065a, należy rozumieć w następujący
sposób:
Usługa RoutineControl (TimeAdjustment) umożliwia uruchomienie
operacji dostosowania zegara VU do czasu podawanego przez odbiornik
GNSS.
Na potrzeby realizacji usługi RoutineControl (TimeAdjustment) VU musi
być w trybie KALIBRACYJNYM.
Warunek wstępny: zapewnia się zdolność VU do odbierania komunikatów
o standardowej pozycji z odbiornika GNSS.
Dopóki trwa korekta czasu, VU odpowiada na żądanie RoutineControl,
podfunkcja requestRoutineResults, z routineInfo = 0x78.
Uwaga: korekta czasu może być dość czasochłonna. Tester diagnostyczny
żąda statusu korekty czasu za pomocą podfunkcji requestRoutineResults.
TRA_013 Dodatek 12, pkt 3 – Komunikaty podawane przez odbiornik
GNSS, wymóg GNS_4a:
Dane zawarte w komunikatach AMC podanych przez odbiornik GNSS,
jeżeli występują, nie mogą być wykorzystywane przez przyrząd rejestru­
jący, z wyjątkiem następujących wartości statusu:
J = jamming [celowe zakłócanie] lub O = other GNSS attack [inny atak
na GNSS] (poprzez wdrożone kontrole spójności zgodnie z GNS_3a),
V = void [puste] (uwierzytelniona pozycja nie jest dostępna z innego
powodu).
TRA_014 Dodatek 12, pkt 3 – Komunikaty podawane przez odbiornik
GNSS, wymóg GNS_5:
Dane zawarte w komunikatach ASA podanych przez odbiornik GNSS,
jeżeli występują, nie mogą być wykorzystywane przez przyrząd rejestru­
jący.
TRA_015 Dodatek 12, pkt 5.2 – Przyrząd rejestrujący bez urządzenia
zewnętrznego GNSS – Transfer informacji z odbiornika GNSS do VU,
wymogi GNS_34 i 36:
Procesor VU nie może wykorzystywać informacji pochodzących z komuni­
katu AMC, z wyjątkiem następujących wartości statusu:
J = jamming [celowe zakłócanie] lub O = other GNSS attack [inny atak
na GNSS] (poprzez wdrożone kontrole spójności zgodnie z GNS_3a),
V = void [puste] (uwierzytelniona pozycja nie jest dostępna z innego
powodu).
Procesor VU nie może wykorzystywać informacji pochodzących z komuni­
katu AMC.
▼M4
02016R0799 — PL — 21.08.2023 — 003.002 — 610
TRA_016 Dodatek 12, pkt 6 – Przetwarzanie i rejestracja danych
o pozycji przez VU, wymóg GNS_39, należy rozumieć w następujący
sposób:
Dane o pozycji są przechowywane w VU wraz z flagą wskazującą, czy
pozycja została uznana za uwierzytelnioną. Jeżeli konieczne jest zareje­
strowanie danych dotyczących pozycji w VU, zastosowanie ma następu­
jąca zasada:
a) Jeżeli standardowa pozycja jest prawidłowa, standardową pozycję i jej
dokładność rejestruje się w VU, a flaga ustawiana jest na »uwierzy­
telniona«.
TRA_017 Dodatek 12, pkt 6 – Przetwarzanie i rejestracja danych
o pozycji przez VU, wymóg GNS_40, należy rozumieć w następujący
sposób:
Jeżeli wartość statusu w otrzymanym komunikacie AMC jest ustawiona na
‘J’ lub ‘O’ zgodnie z wymogiem GNS_4a, VU generuje i rejestruje
zdarzenie anomalii GNSS, jak określono w wymogu 88a w załączniku
IC i dodatku 1 (EventFaultType). Przyrząd rejestrujący może przeprowa­
dzić dodatkowe kontrole przed zapisaniem zdarzenia anomalii GNSS po
otrzymaniu ustawienia ‘J’ lub ‘O’.
TRA_018 Dodatek 12, pkt 8 – Konflikt ruchu pojazdu, wymóg GNS_42,
Warunek uruchamiający 2, tiret pierwsze i drugie po wzorze należy rozu­
mieć w następujący sposób:
— GnssDistance to odległość między bieżącą pozycją pojazdu
a poprzednią pozycją, uzyskanymi na podstawie komunikatów
o prawidłowej standardowej pozycji, bez uwzględniania wysokości;
— OdometerDifference to różnicą między bieżącą wartością licznika kilo­
metrów a wartością licznika kilometrów odpowiadającą poprzedniemu
komunikatowi o prawidłowej standardowej pozycji.
TRA_019 Dodatek 14, pkt 5.4.5 – Wymogi protokołu DSRC – Elementy
danych dotyczących zdalnego monitorowania tachografu (RtmData),
wykonywane czynności i definicje, wymóg DSC_41, tabela 14.3, druga
komórka w wierszu RTM20, należy rozumieć w następujący sposób:
VU generuje wartość w postaci liczby całkowitej (timeReal z dodatku 1)
w odniesieniu do elementu danych RTM20.
VU ustala wartość RTM20 na czas, kiedy ostatnia standardowa pozycja
pojazdu była dostępna z odbiornika GNSS.
Jeżeli żadna standardowa pozycja pojazdu nie była kiedykolwiek dostępna
z odbiornika GNSS, VU ustawia wartość RTM20 na 0.
TRA_020 Producent przejściowego przyrządu rejestrującego, który
uzyskał homologację typu, przekazuje Komisji informacje o wersjach
jego oprogramowania. Komisja publikuje informacje o tych wersjach
oprogramowania na publicznie dostępnej stronie internetowej.
▼M4
02016R0799 — PL — 21.08.2023 — 003.002 — 611
5. PRZEPISY SZCZEGÓŁOWE DOTYCZĄCE HOMOLOGACJI TYPU
I STOSOWANIA TACHOGRAFÓW PRZEJŚCIOWYCH
TRA_021 Przejściowe przyrządy rejestrujące muszą uzyskać homologację
typu zgodnie z wymogami załącznika IC i dodatków 1–16 do tego załącz­
nika, uzupełnionymi przepisami niniejszego dodatku.
TRA_022 Wnioski o wydanie świadectw homologacji typu dla przejścio­
wych przyrządów rejestrujących i przejściowych tachografów można
składać wyłącznie do dnia 31 grudnia 2023 r. lub do daty złożenia dekla­
racji usługi OSNMA, w zależności od tego, która z tych dat jest
późniejsza.
TRA_023 Przejściowe przyrządy rejestrujące mogą być montowane
w pojazdach zarejestrowanych po raz pierwszy tylko do dnia 31 maja
2024 r. lub do 5 miesięcy po dacie złożenia deklaracji usługi OSNMA,
w zależności od tego, która z tych dat jest późniejsza.
▼M4
02016R0799 — PL — 21.08.2023 — 003.002 — 612
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 — 21.08.2023 — 003.002 — 613
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 — 21.08.2023 — 003.002 — 614
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 — 21.08.2023 — 003.002 — 615
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 — 21.08.2023 — 003.002 — 616
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.


Full & Egal Universal Law Academy