EUR-Lex Access to European Union law

Back to EUR-Lex homepage

This document is an excerpt from the EUR-Lex website

Document 32021R1228

Rozporządzenie wykonawcze Komisji (UE) 2021/1228 z dnia 16 lipca 2021 r. zmieniające rozporządzenie wykonawcze (UE) 2016/799 w odniesieniu do wymogów dotyczących budowy, sprawdzania, instalacji, użytkowania i naprawy tachografów inteligentnych oraz ich elementów składowych (Tekst mający znaczenie dla EOG)

C/2021/5125

OJ L 273, 30.7.2021, p. 1–140 (BG, ES, CS, DA, DE, ET, EL, EN, FR, GA, HR, IT, LV, LT, HU, MT, NL, PL, PT, RO, SK, SL, FI, SV)

Legal status of the document In force: This act has been changed. Current consolidated version: 21/08/2023

ELI: http://data.europa.eu/eli/reg_impl/2021/1228/oj

30.7.2021   

PL

Dziennik Urzędowy Unii Europejskiej

L 273/1


ROZPORZĄDZENIE WYKONAWCZE KOMISJI (UE) 2021/1228

z dnia 16 lipca 2021 r.

zmieniające rozporządzenie wykonawcze (UE) 2016/799 w odniesieniu do wymogów dotyczących budowy, sprawdzania, instalacji, użytkowania i naprawy tachografów inteligentnych oraz ich elementów składowych

(Tekst mający znaczenie dla EOG)

KOMISJA EUROPEJSKA,

uwzględniając Traktat o funkcjonowaniu Unii Europejskiej,

uwzględniając rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 165/2014 z dnia 4 lutego 2014 r. w sprawie tachografów stosowanych w transporcie drogowym (1), w szczególności jego art. 11,

a także mając na uwadze, co następuje:

(1)

Rozporządzeniem (UE) nr 165/2014 wprowadzono tachografy inteligentne, które obejmują połączenie z urządzeniem globalnego systemu nawigacji satelitarnej („GNSS”), urządzenie wczesnego wykrywania na odległość oraz interfejs do inteligentnych systemów transportowych.

(2)

Wymogi techniczne dotyczące budowy, sprawdzania, instalacji, użytkowania i naprawy tachografów oraz ich elementów składowych określono w rozporządzeniu wykonawczym Komisji (UE) 2016/799 (2).

(3)

Rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 165/2014 i (WE) nr 561/2006 (3) zostały zmienione rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2020/1054 (4). Rozporządzenie (UE) 2020/1054 wymaga wdrożenia dodatkowych funkcji w tachografie inteligentnym. W związku z tym należy określić nową wersję tachografów inteligentnych w drodze zmiany rozporządzenia (UE) 2016/799.

(4)

Zgodnie z art. 8 ust. 1 rozporządzenia (UE) nr 165/2014 położenie pojazdu należy rejestrować automatycznie za każdym razem, kiedy pojazd przekracza granicę państwa członkowskiego, i za każdym razem, gdy pojazd wykonuje czynności załadunku lub rozładunku.

(5)

Interfejs do inteligentnych systemów transportowych, który jest opcjonalny w wersji tachografu inteligentnego wdrożonej z dniem 15 czerwca 2019 r., powinien być obowiązkowy dla nowej wersji tachografu inteligentnego.

(6)

Nowa wersja tachografu inteligentnego powinna zostać przygotowana do uwierzytelniania sygnału satelitarnego Galileo, gdy tylko system Galileo rozpocznie funkcjonowanie.

(7)

Aby uniknąć fizycznej wymiany urządzeń rejestrujących za każdym razem, gdy przyjmowana jest modyfikacja specyfikacji technicznych tachografu, konieczne jest zapewnienie, aby przyszłe funkcje tachografu mogły być wdrażane i ulepszane za pomocą aktualizacji oprogramowania.

(8)

Rozporządzenie (UE) 2016/799 umożliwia zainstalowanie adaptera między czujnikiem ruchu a tachografem w pojazdach, które chociaż mają masę poniżej 3,5 tony, mogą niekiedy przekroczyć ten próg, na przykład podczas ciągnięcia przyczepy. W następstwie zmiany rozporządzenia (WE) nr 561/2006 obowiązek instalowania tachografu rozszerzono na pojazdy o masie powyżej 2,5 tony. Obowiązkowe instalowanie tachografu inteligentnego w lekkich pojazdach użytkowych wymaga zwiększenia poziomu zabezpieczeń zapewnianego przez adapter poprzez zainstalowanie w tachografie wewnętrznego czujnika, który będzie niezależny od sygnału czujnika ruchu.

(9)

Środki przewidziane w niniejszym rozporządzeniu są zgodne z opinią Komitetu ustanowionego na mocy art. 42 ust. 1 rozporządzenia (UE) nr 165/2014,

PRZYJMUJE NINIEJSZE ROZPORZĄDZENIE:

Artykuł 1

W załączniku IC do rozporządzenia (UE) 2016/799 wprowadza się zmiany określone w załączniku do niniejszego rozporządzenia.

Artykuł 2

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 21 sierpnia 2023 r.

Niniejsze rozporządzenie wiąże w całości i jest bezpośrednio stosowane we wszystkich państwach członkowskich.

Sporządzono w Brukseli dnia 16 lipca 2021 r.

W imieniu Komisji

Ursula VON DER LEYEN

Przewodnicząca


(1)  Dz.U. L 60 z 28.2.2014, s. 1.

(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 (Dz.U. L 139 z 26.5.2016, s. 1).

(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).

(4)  Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2020/1054 z dnia 15 lipca 2020 r. zmieniające rozporządzenie (WE) nr 561/2006 w odniesieniu do minimalnych wymogów dotyczących maksymalnego dziennego i tygodniowego czasu prowadzenia pojazdu, minimalnych przerw oraz dziennego i tygodniowego okresu odpoczynku oraz zmieniające rozporządzenie (UE) nr 165/2014 w odniesieniu do określania położenia za pomocą tachografów (Dz.U. L 249 z 31.7.2020, s. 1).


ZAŁĄCZNIK

W załączniku IC do rozporządzenia wykonawczego (UE) 2016/799 wprowadza się następujące zmiany:

1)

w spisie treści wprowadza się następujące zmiany:

a)

dodaje się pkt 3.6.4 w brzmieniu:

„3.6.4

Wprowadzanie operacji załadunku/rozładunku”;

b)

dodaje się pkt 3.9.18 w brzmieniu:

„3.9.18

Zdarzenie »anomalia GNSS«”;

c)

dodaje się pkt 3.12.17, 3.12.18 i 3.12.19 w brzmieniu:

„3.12.17

Przekroczenia granicy

3.12.18

Operacje załadunku/rozładunku

3.12.19

Mapa cyfrowa”;

d)

pkt 3.20 otrzymuje brzmienie:

„3.20

Wymiana danych z dodatkowymi urządzeniami zewnętrznymi”;

e)

dodaje się pkt 3.27 i 3.28 w brzmieniu:

„3.27

Monitorowanie przekroczeń granicy

3.28

Aktualizacja oprogramowania”;

f)

dodaje się pkt 4.5.3.2.1.1 w brzmieniu:

„4.5.3.2.1.1

Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)”;

g)

dodaje się pkt 4.5.3.2.17–4.5.3.2.22 w brzmieniu:

„4.5.3.2.17

Status uwierzytelniania dla pozycji związanych z miejscami rozpoczę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)

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)”;

h)

dodaje się pkt 4.5.4.2.1.1 w brzmieniu:

„4.5.4.2.1.1

Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)”;

i)

dodaje się pkt 4.5.4.2.16–4.5.4.2.22 w brzmieniu:

„4.5.4.2.16

Status uwierzytelniania dla pozycji związanych z miejscami rozpoczę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)”;

j)

po pkt 4.5.5.2.1 dodaje się pkt 4.5.5.2.1.1 w brzmieniu:

„4.5.5.2.1.1

Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)”;

k)

dodaje się pkt 4.5.5.2.6 w brzmieniu:

„4.5.5.2.6

Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)”;

l)

po pkt 4.5.6.2.1 dodaje się pkt 4.5.6.2.1.1 w brzmieniu:

„4.5.6.2.1.1

Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)”;

m)

dodaje się pkt 4.5.6.2.6 w brzmieniu:

„4.5.6.2.6

Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)”;

2)

tekst wprowadzający przed nagłówkiem „Wykaz dodatków” otrzymuje brzmienie:

„WPROWADZENIE

Niniejszy załącznik zawiera wymogi dotyczące drugiej generacji urządzeń rejestrują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 skonstruowanych zgodnie z załącznikiem IB do rozporządzenia (EWG) nr 3821/85.

Analogicznie karty do tachografu pierwszej generacji mogą być używane w przyrzą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 uwierzytelniania 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.”;

3)

w sekcji 1 wprowadza się następujące zmiany:

a)

lit. f) otrzymuje brzmienie:

„f)

»kalibracja tachografu inteligentnego« oznacza:

aktualizację lub potwierdzenie parametrów pojazdu przechowywanych 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 kalibracji urządzenia rejestrującego w pamięci danych zachowywane 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;”;

b)

lit. g) otrzymuje brzmienie:

„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;”;

c)

lit. i) oraz j) otrzymują brzmienie:

„i)

»numer odnowienia karty« oznacza:

16. znak alfanumeryczny w numerze karty, który jest zmieniany przyrostowo za każdym razem, gdy odnawiana jest karta do tachografu odpowiadająca danej identyfikacji, tj. identyfikacji 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;”;

d)

lit. ee) otrzymuje brzmienie:

„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 wydają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 wydają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;”;

e)

lit. ll) otrzymuje brzmienie:

„ll)

»urządzenie do łączności na odległość«, »moduł komunikacji na odległość« lub »urządzenie wczesnego wykrywania na odległość« oznacza:

wyposażenie przyrządu rejestrującego, które jest używane do przeprowadzania ukierunkowanych kontroli drogowych;”;

f)

lit. nn) otrzymuje brzmienie:

„nn)

»odnowienie karty« oznacza:

wydanie nowej karty do tachografu po upływie terminu ważności dotychczasowej karty lub w przypadku nieprawidłowego działania karty i zwrócenia jej organowi wydającemu kartę;”;

g)

lit. pp) otrzymuje brzmienie:

„pp)

»wymiana karty« oznacza:

wydanie nowej karty do tachografu w celu zastąpienia dotychczasowej karty, której utratę, kradzież lub wadliwe działanie zgłoszono i której nie zwrócono organowi, który wydał kartę;”;

h)

lit. tt) otrzymuje brzmienie:

„tt)

»korekta czasu« oznacza:

korektę bieżącego czasu; może ona być automatyczna z wykorzystaniem czasu podawanego przez odbiornik GNSS jako odniesienia lub wykonywana w trybie kalibracyjnym;”;

i)

lit. yy) tiret pierwsze otrzymuje brzmienie:

„-

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 (1),”;

j)

lit. aaa) otrzymuje brzmienie:

„aaa)

zarezerwowane dla przyszłego użytku;”;

k)

lit. ccc) otrzymuje brzmienie:

„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.”;

4)

w pkt 2.1 wprowadza się następujące zmiany:

a)

pkt 5 otrzymuje brzmienie:

„5)

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)

pkt 7 akapit ostatni otrzymuje brzmienie:

„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.”;

5)

w pkt 2.2 wprowadza się następujące zmiany:

a)

tiret szóste otrzymuje brzmienie:

„-

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)

dodaje się tiret w brzmieniu:

„-

monitorowanie przekroczeń granicy,

aktualizacja oprogramowania.”;

6)

w pkt 2.3 wprowadza się następujące zmiany:

a)

pkt 12 tiret piąte otrzymuje brzmienie:

„-

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)

w pkt 13 wprowadza się następujące zmiany:

(i)

tiret drugie otrzymuje brzmienie:

„-

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 pierwszymi 13 cyframi numeru karty firmowej),”;

(ii)

tiret czwarte otrzymuje brzmienie:

„-

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ą.”;

7)

w pkt 2.4 pkt 14 tiret czwarte otrzymuje brzmienie:

„-

urządzenie zewnętrzne GNSS (profil ten jest tylko konieczny i stosowany do wariantu urządzenia zewnętrznego GNSS).”;

8)

w pkt 3.1 wprowadza się następujące zmiany:

a)

pkt 16 otrzymuje brzmienie:

„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)

pkt 20 otrzymuje brzmienie:

„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.”;

9)

w pkt 3.2 wprowadza się następujące zmiany:

a)

pkt 26 i 27 otrzymują brzmienie:

„26)

W celu wykrycia manipulowania danymi dotyczącymi ruchu informacje z czujnika ruchu są potwierdzane przez informacje dotyczące ruchu pojazdu pochodzące z odbiornika GNSS i 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ętrznego.

27)

Funkcja ta mierzy pozycję pojazdu w celu umożliwienia rejestracji:

pozycji, w których kierowca lub współkierowca rozpoczynają 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)

w pkt 3.2.1 dodaje się zdanie w pkt 30 w brzmieniu:

„Tolerancji nie można wykorzystywać do celowej zmiany zmierzonej odległości.”;

c)

w pkt 3.2.2 pkt 33 otrzymuje brzmienie:

„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.”;

d)

w pkt 3.2.3 pkt 37 otrzymuje brzmienie:

„37)

Bezwzględną pozycję mierzy się we współrzędnych szerokości i długości geograficznej, w stopniach i minutach, z dokładnością do 1/10 minuty.”;

10)

w pkt 3.3 wprowadza się następujące zmiany:

a)

pkt 41 otrzymuje brzmienie:

„41)

Dryft czasu musi wynosić ± 1 sekundę dziennie lub mniej, w warunkach temperaturowych zgodnie z wymogiem 213, przy braku korekty czasu.”;

b)

dodaje się ust. 41a, 41b i 41c w brzmieniu:

„41a)

Dokładność czasu, gdy czas jest korygowany przez warsztaty 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.”;

11)

w pkt 3.6 wprowadza się następujące zmiany:

a)

w pkt 3.6.1 wprowadza się następujące zmiany:

(i)

pkt 57–59 otrzymują brzmienie:

„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 warsztatowej) 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;

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 zatwierdzona 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.”;

(ii)

w pkt 60 dodaje się akapit w brzmieniu:

„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.”;

b)

w pkt 3.6.2 pkt 61 otrzymuje brzmienie:

„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 warsztatowej, 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.

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 czynnoś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 wprowadzania danych związanego z włożeniem karty, będzie to równoważne z potwierdzeniem, że okres pracy nie zmienił się od ostatniego wyjęcia karty. Kolejne wprowadzenie miejsca zakończenia poprzedniego dziennego okresu pracy nadpisze wówczas wpis tymczasowy wprowadzony przy ostatnim wyjęciu karty.

Jeżeli wprowadza się miejsce, rejestruje się je na stosownej karcie do tachografu.

Ręczne wprowadzanie zostaje przerwane, jeżeli:

karta zostaje wyjęta lub

pojazd porusza się, 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 przerwane, urządzenie rejestrujące dokonuje walidacji wszystkich 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 chronologicznej 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.”;

c)

w pkt 3.6.3 pkt 62 otrzymuje brzmienie:

„62)

Urządzenie rejestrujące umożliwia kierowcy wprowadzenie w czasie rzeczywistym następujących dwóch stanów szczególnych:

»POZA ZAKRESEM« (początek, koniec),

»PRZEPRAWA PROMOWA/POCIĄGOWA« (początek, koniec).

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żytkownikom na wpisanie flagi początkowej »PRZEPRAWA PROMOWA/POCIĄGOWA«.

Włożenie lub wyjęcie karty kierowcy powoduje automatycznie 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 prowadzenia pojazdu.

Kierowca wpisuje flagę początkową PRZEPRAWA PROMOWA/POCIĄGOWA niezwłocznie po wybraniu czynnoś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.”;

d)

dodaje się pkt 3.6.4 w brzmieniu:

„3.6.4

Wprowadzanie operacji załadunku/rozładunku

62a)

Urządzenie rejestrujące umożliwia kierowcy wprowadzenie i potwierdzenie, w czasie rzeczywistym, informacji wskazujących, że pojazd jest załadowywany, rozładowywany lub że wykonywana jest operacja równoczesnego załadunku/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ładunku/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 przeprowadzana jest operacja załadunku/rozładunku.”;

(12)

w pkt 3.9 wprowadza się następujące zmiany:

a)

w pkt 3.9.12 pkt 83 otrzymuje brzmienie:

„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 uwierzytelnienia danych wymienianych między czujnikiem ruchu a przyrządem rejestrującym. Z wyjątkiem trybu kalibracyjnego, 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)

w pkt 3.9.13 pkt 84 otrzymuje brzmienie:

„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 obliczonymi 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ć uruchomione podczas przeprawy promowej/pociągowej.”;

c)

w pkt 3.9.15 pkt 86 otrzymuje brzmienie:

„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 wymogiem 211.”;

d)

w pkt 3.9.17 tiret ósme otrzymuje brzmienie:

„-

usterka związana z interfejsem ITS,”;

e)

dodaje się literę w brzmieniu:

„3.9.18

Zdarzenie »anomalia GNSS«

88a)

Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się, gdy odbiornik GNSS wykryje atak lub gdy uwierzytelnienie 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.”;

13)

w pkt 3.10 ostatni wiersz w tabeli otrzymuje brzmienie:

„interfejs ITS

Prawidłowa praca”;

 

14)

w pkt 3.12 wprowadza się następujące zmiany:

a)

akapit pierwszy otrzymuje brzmienie:

Do celów niniejszego punktu:

»365 dni« definiuje się jako 365 dni kalendarzowych przeciętnych 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 prowadzenia 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,

ś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ładunku,

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 stopniach 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)

w pkt 3.12.1.1 wprowadza się następujące zmiany:

(i)

w pkt 93 dodaje się tiret w brzmieniu:

„-

identyfikator wersji mapy cyfrowej (wymóg 133l).”;

(ii)

pkt 94 otrzymuje brzmienie:

„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 oprogramowania zgodnie z niniejszym rozporządzeniem, oraz z wyjątkiem możliwości korzystania z kart do tachografów pierwszej generacji.”;

c)

w pkt 3.12.1.2 pkt 97 akapit pierwszy otrzymuje brzmienie:

„97)

Przyrząd rejestrujący musi mieć możliwość rejestrowania i zachowywania w pamięci następujących danych związanych 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):”;

d)

w pkt 3.12.1.3 pkt 100 akapit pierwszy otrzymuje brzmienie:

„100)

Przyrząd rejestrujący musi mieć możliwość rejestrowania i zachowywania w pamięci następujących danych związanych z 20 ostatnimi udanymi powiązaniami urządzeń zewnętrznych GNSS (jeżeli podczas jednego dnia kalendarzowego miało miejsce wiele powiązań, zachowywane jest tylko pierwsze i ostatnie z danego dnia).”;

e)

w pkt 3.12.5 wprowadza się następujące zmiany:

(i)

w pkt 110 wprowadza się następujące zmiany:

1)

tiret pierwsze otrzymuje brzmienie:

„-

numer karty kierowcy lub współkierowcy i państwo członkowskie wydające kartę,”;

2)

dodaje się tiret w brzmieniu:

„-

flagę wskazującą, czy pozycja została uwierzytelniona.”;

(ii)

dodaje się pkt 110a w brzmieniu:

„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 kilometrów i pozycję pojazdu.”;

f)

w pkt 3.12.8 w tabeli w pkt 117 wprowadza się następujące zmiany:

(i)

wiersz piąty otrzymuje brzmienie:

„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”;

(ii)

dodaje się wiersz w brzmieniu:

„Anomalia GNSS

najdłuższe zdarzenia w każdym z ostatnich 10 dni ich występowania,

5 najdłuższych zdarzeń w ciągu ostatnich 365 dni

data i godzina początku zdarzenia

data i godzina końca zdarzenia

typ karty, numer, państwo członkowskie wydające kartę i generacja dla każdej karty wprowadzonej na początku lub na końcu zdarzenia

liczba podobnych zdarzeń w tym dniu”;

g)

w pkt 3.12.10 pkt 120 dodaje się akapity w brzmieniu:

„-

numery seryjne czujnika ruchu, urządzenia zewnętrznego 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ładunek towarów albo pasażerów),

-

kraj, w którym wykonano kalibrację, oraz datę i godzinę dostarczenia przez odbiornik GNSS pozycji wykorzystanej do określenia tego kraju.”;

h)

dodaje się punkty w brzmieniu:

„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 przekroczenia granicy.

133c)

Pamięć danych wystarcza do przechowywania danych dotyczą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ładunku.

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 odpowiadają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,

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 dotyczą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ę monitorowania 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 internetowej i pobierają ją w bezpieczny sposób.

133o)

Producenci tachografów wykorzystują mapę pobraną ze strony internetowej dopiero po sprawdzeniu jej integralnoś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 semantyczna 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ć autentyczność i integralność nowej importowanej mapy przed jej zapisaniem i zastąpieniem poprzedniej mapy.

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.”;

15)

w pkt 3.13 wprowadza się następujące zmiany:

a)

pkt 134 tiret trzecie otrzymuje brzmienie:

„-

wyliczenia dla kierowcy: nieprzerwanego czasu prowadzenia pojazdu, skumulowanego czasu przerwy i skumulowanego czasu prowadzenia za poprzedni i bieżący tydzień,”;

b)

dodaje się pkt 135a w brzmieniu:

„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 uwierzytelnienia 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 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 Border_Crossings, EF Load_Unload_Operations oraz EF Load_Type_Entries zawierają dane dotyczą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 identyfikacyjny pojazdu przechowywane wraz z odpowiednimi danymi kalibracyjnymi w EF Calibration;

we wszystkich kartach do tachografów:

EF VU_Configuration zawiera szczegółowe ustawienia tachografu posiadacza karty.

Przyrząd rejestrujący nie uwzględnia żadnego statusu uwierzytelnienia 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_Configuration we wszystkich kartach, o ile nie określono szczegółowych zasad dotyczących korzystania z takiego pliku elementarnego. Zasady te określa się poprzez zmianę załącznika IC, która obejmuje modyfikację lub uchylenie niniejszego punktu.”;

16)

w pkt 3.14 wprowadza się następujące zmiany:

a)

w pkt 3.14.1 wprowadza się następujące zmiany:

(i)

pkt 140 otrzymuje brzmienie:

„140)

Wszystkie zdarzenia niezdefiniowane dla urządzeń rejestrujących pierwszej generacji nie są zapisywane na karcie kierowcy ani na karcie warsztatowej.”;

(ii)

pkt 143 otrzymuje brzmienie:

„143)

Przed odblokowaniem karty kierowcy lub karty warsztatowej i po zapisaniu na karcie wszystkich stosownych danych urządzenie rejestrujące zeruje »dane sesji karty«.”;

b)

w pkt 3.14.2 wprowadza się następujące zmiany:

(i)

w pkt 144 dodaje się akapit w brzmieniu:

„Struktura aplikacji »TACHO_G2« zależy od wersji. Karty wersji 2 zawierają dodatkowe pliki elementarne w stosunku do kart wersji 1.”;

(ii)

dodaje się pkt 147a i 147b w brzmieniu:

„147a)

Po włożeniu karty kierowcy lub karty warsztatowej urządzenie rejestrujące zapisuje na karcie domyślny typ załadunku pojazdu.

147b)

Po włożeniu karty kierowcy lub karty warsztatowej i po ręcznej procedurze wprowadzania danych urządzenie rejestrują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 przekroczenia 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,

datą i godziną przekroczenia granicy przez kierowcę: godzina włożenia karty,

pozycją kierowcy po przekroczeniu granicy: niedostępne,

stanem licznika kilometrów: niedostępne.”;

(iii)

dodaje się pkt 150a w brzmieniu:

„150a)

Przyrząd rejestrujący ignoruje plik elementarny EF VU_Configuration we wszystkich kartach, o ile nie określono szczegółowych zasad dotyczących korzystania z takiego pliku elementarnego. Zasady te określa się poprzez zmianę załącznika IC, która obejmuje modyfikację lub uchylenie niniejszego punktu.”;

17)

w pkt 3.15.4 pkt 167 wprowadza się następujące zmiany:

a)

tiret drugie otrzymuje brzmienie:

„-

treści każdego z wydruków wymienionych w wymogu 169 w takich samych formatach co wydruki,”;

b)

tiret piąte i szóste otrzymują brzmienie:

„-

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ń,”;

c)

tiret ósme, dziewiąte i dziesiąte otrzymują brzmienie:

„-

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.”;

18)

w pkt 3.18 wprowadza się następujące zmiany:

a)

pkt 193 otrzymuje brzmienie:

„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)

dodaje się pkt 196a i 196b w brzmieniu:

„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.”;

19)

w pkt 3.19 pkt 199 dodaje się akapity w brzmieniu:

„-

pozycji pojazdu,

-

wskazania, czy kierowca prawdopodobnie narusza obecnie czas prowadzenia pojazdu.”;

20)

w pkt 3.20 wprowadza się następujące zmiany:

a)

nagłówek otrzymuje brzmienie:

„3.20

Wymiana danych z dodatkowymi urządzeniami zewnętrznymi”;

b)

pkt 200 otrzymuje brzmienie:

„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 rejestrowanych lub generowanych przez tachograf lub karty do tachografu.

W trybie eksploatacyjnym wymagana jest zgoda kierowcy na przesyłanie danych osobowych za pośrednictwem interfejsu ITS. Niemniej jednak zgoda kierowcy nie ma zastosowania do danych tachografu lub karty, do których uzyskano dostęp w trybie kontrolnym, firmowym lub kalibracyjnym. 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 klasyfikację danych jako danych osobowych lub nieosobowych 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”,

w dowolnym momencie istnieje możliwość potwierdzenia lub wycofania zgody kierowcy przez wybranie polecenia w menu, pod warunkiem że karta kierowcy jest włożona,

w żadnych okolicznościach obecność interfejsu ITS nie może zakłócać prawidłowego funkcjonowania i bezpieczeństwa przyrządu rejestrującego ani oddziaływać na niego.

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 zapewnienia zgodności procedury przetwarzania danych osobowych 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ółkierowcę.

Interfejs ITS może być również wykorzystywany do wprowadzania 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średnictwem innych interfejsów.”;

c)

pkt 201 otrzymuje brzmienie:

„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.”;

21)

w pkt 3.21 wprowadza się następujące zmiany:

a)

w pkt 202 wprowadza się następujące zmiany:

(i)

tiret dziewiąte otrzymuje brzmienie:

„-

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,”;

(ii)

dodaje się tiret w brzmieniu:

„-

automatyczne zapisywanie kraju, w którym wykonano kalibrację, oraz daty i godziny dostarczenia przez odbiornik GNSS pozycji wykorzystanej do określenia tego kraju.”;

b)

pkt 205 otrzymuje brzmienie:

„205)

Powiązanie urządzenia zewnętrznego GNSS z przyrządem rejestrującym obejmuje co najmniej:

aktualizację danych instalacyjnych urządzenia zewnętrznego 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 seryjnego urządzenia zewnętrznego GNSS.”;

22)

w pkt 3.22 pkt 209 dodaje się akapity w brzmieniu:

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).”;

23)

w pkt 3.23 wprowadza się następujące zmiany:

a)

pkt 211 otrzymuje brzmienie:

„211)

Ustawienia czasu wewnętrznego zegara przyrządu rejestrującego są automatycznie korygowane w zmiennych odstępach czasu. Kolejna automatyczna korekta czasu uruchamiana 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 uwierzytelnionej 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 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 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.”;

b)

pkt 212 otrzymuje brzmienie:

„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,

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 komunikatów o uwierzytelnionej pozycji. W tym ostatnim przypadku wykorzystuje się usługę RoutineControl zgodnie z sekcją 8 w dodatku 8.”;

24)

dodaje się pkt 3.27 i 3.28 w brzmieniu:

„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 przyrządzie rejestrującym posiadającym homologację typu, zgodnie z art. 12 ust. 5 rozporządzenia (UE) nr 165/2014.

226e)

Funkcja aktualizacji oprogramowania musi być zaprojektowana 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 transportu 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łoszonym 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.”;

25)

w pkt 4.1, w ilustracji „Wzory wspólnotowych kart do tachografów” po pkt 235, wzór na odwrocie karty kontrolnej zastępuje się następującym wzorem:

Image 1

”;

26)

w pkt 4.5 wprowadza się następujące zmiany:

a)

pkt 246 otrzymuje brzmienie:

„246)

Wszelkie dodatkowe dane mogą być przechowywane na kartach do tachografów, pod warunkiem że przechowywanie tych danych jest zgodne z mającymi zastosowanie przepisami dotyczącymi ochrony danych.”;

b)

w pkt 247 po drugim tiret dodaje się uwagę w brzmieniu:

„Uwaga: wersja 2 drugiej generacji kart zawiera dodatkowe pliki elementarne w DF Tachograph_G2.”;

c)

w pkt 4.5.3.2 wprowadza się następujące zmiany:

(i)

nagłówek otrzymuje brzmienie:

„4.5.3.2

Aplikacja tachograficzna generacji 2 (niedostępna dla pierwszej generacji przyrządów rejestrujących, dostępna dla wersji 1 i wersji 2 drugiej generacji przyrządów rejestrujących)”;

(ii)

po pkt 4.5.3.2.1 dodaje się pkt 4.5.3.2.1.1 w brzmieniu:

„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.”;

(iii)

w pkt 4.5.3.2.7 pkt 287 otrzymuje brzmienie:

„287)

Karta kierowcy umożliwia przechowywanie danych dotyczących 12 ostatnich zdarzeń każdego typu (tj. 132 zdarzeń).”;

(iv)

w pkt 4.5.3.2.8 pkt 290 otrzymuje brzmienie:

„290)

Karta kierowcy umożliwia przechowywanie danych dotyczących 24 ostatnich usterek każdego rodzaju (tj. 48 usterek).”;

(v)

w pkt 4.5.3.2.9 pkt 292 otrzymuje brzmienie:

„292)

Pamięć karty kierowcy wystarcza do przechowywania danych dotyczących czynności kierowcy przez przynajmniej 56 dni (przeciętną aktywność kierowcy definiuje się na potrzeby tego wymogu jako 117 zmian czynności dziennie).”;

(vi)

w pkt 4.5.3.2.10 pkt 295 otrzymuje brzmienie:

„295)

Karta kierowcy umożliwia przechowywanie 200 takich rekordów danych.”;

(vii)

w pkt 4.5.3.2.11 pkt 297 otrzymuje brzmienie:

„297)

Pamięć karty kierowcy umożliwia przechowywanie 112 takich rekordów danych.”;

(viii)

w pkt 4.5.3.2.14 pkt 302 otrzymuje brzmienie:

„302)

Karta kierowcy umożliwia przechowywanie 112 takich rekordów danych.”;

(ix)

w pkt 4.5.3.2.15 pkt 304 otrzymuje brzmienie:

„304)

Karta kierowcy umożliwia przechowywanie 200 takich rekordów danych.”;

(x)

w pkt 4.5.3.2.16 pkt 306 otrzymuje brzmienie:

„306)

Karta kierowcy umożliwia przechowywanie 336 takich rekordów danych.”;

(xi)

dodaje się pkt 4.5.3.2.17–4.5.3.2.22 w brzmieniu:

„4.5.3.2.17

Status uwierzytelniania dla pozycji związanych z miejscami rozpoczę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.

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 skumulowany 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 zapisana 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,

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 automatycznie 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.”;

d)

w pkt 4.5.4.2 wprowadza się następujące zmiany:

(i)

nagłówek otrzymuje brzmienie:

„4.5.4.2

Aplikacja tachograficzna generacji 2 (niedostępna dla pierwszej generacji przyrządów rejestrujących, dostępna dla wersji 1 i wersji 2 drugiej generacji przyrządów rejestrujących)”;

(ii)

po pkt 4.5.4.2.1 dodaje się pkt 4.5.4.2.1.1 w brzmieniu:

„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 dodatkowych danych identyfikujących aplikacje mających zastosowanie wyłącznie do wersji 2.”;

(iii)

w pkt 4.5.4.2.6 pkt 338 otrzymuje brzmienie:

„338)

Karta warsztatowa umożliwia przechowywanie 255 takich rekordów danych.”;

(iv)

w pkt 4.5.4.2.8 pkt 344 otrzymuje brzmienie:

„344)

Karta warsztatowa umożliwia przechowywanie danych dotyczących czynności kierowcy przez 1 dzień obejmujący 240 zmian czynności.”;

(v)

w pkt 4.5.4.2.9 pkt 346 otrzymuje brzmienie:

„346)

Karta warsztatowa umożliwia przechowywanie 8 takich rekordów danych.”;

(vi)

pkt 4.5.4.2.10 otrzymuje brzmienie:

„4.5.4.2.10

Dane dotyczące miejsc i pozycji rozpoczęcia lub zakończenia dziennych 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.”;

(vii)

w pkt 4.5.4.2.13 pkt 352 otrzymuje brzmienie:

„352)

Karta warsztatowa umożliwia przechowywanie 8 takich rekordów danych.”;

(viii)

w pkt 4.5.4.2.14 pkt 354 otrzymuje brzmienie:

„354)

Karta warsztatowa umożliwia przechowywanie 24 takich rekordów danych.”;

(ix)

w pkt 4.5.4.2.15 pkt 356 otrzymuje brzmienie:

„356)

Karta warsztatowa umożliwia przechowywanie 4 takich rekordów danych.”;

(x)

dodaje się pkt 4.5.4.2.16–4.5.4.2.22 w brzmieniu:

„4.5.4.2.16

Status uwierzytelniania dla pozycji związanych z miejscami rozpoczę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 dodatkowych danych dotyczących miejsc rozpoczęcia lub zakończenia dziennych okresów pracy, w taki sam sposób jak karta kierowcy.

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 przypadku wersji 1 drugiej generacji przyrządów rejestrujących)

356c)

Karta warsztatowa umożliwia przechowywanie dodatkowych danych dotyczących pozycji pojazdu, w których skumulowany czas prowadzenia pojazdu osiąga wielokrotność 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ładunku.

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 dodatkowych danych identyfikujących aplikacje mających zastosowanie 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 Tachograph_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 wykorzystanej do określenia tego kraju.

356l)

Karta warsztatowa umożliwia przechowywanie 255 takich rekordów danych.

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ółowych ustawień tachografu posiadacza karty.

356n)

Pojemność karty warsztatowej na potrzeby przechowywania szczegółowych ustawień tachografu posiadacza karty wynosi 3072 bajty.”;

e)

w pkt 4.5.5 wprowadza się następujące zmiany:

(i)

pkt 4.5.5.1.5 tiret drugie otrzymuje brzmienie:

„-

rodzaj kontroli (wyświetlanie lub drukowanie lub pobieranie danych z przyrządu rejestrującego lub pobieranie danych z karty),”;

(ii)

po pkt 4.5.5.2.1 dodaje się pkt 4.5.5.2.1.1 w brzmieniu:

„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.”;

(iii)

po pkt 4.5.5.2.5 dodaje się punkt w brzmieniu:

„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.”;

f)

w pkt 4.5.6.2 wprowadza się następujące zmiany:

(i)

po pkt 4.5.6.2.1 dodaje się punkt w brzmieniu:

„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.”;

(ii)

dodaje się pkt 4.5.6.2.6 w brzmieniu:

„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.”;

27)

w pkt 5 wprowadza się następujące zmiany:

a)

w pkt 5.1 wprowadza się następujące zmiany:

(i)

pkt 383 otrzymuje brzmienie:

„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 rejestrującego zgodnie z wymogiem 118.”;

(ii)

pkt 392 otrzymuje brzmienie:

„392)

Następnym krokiem po instalacji jest kalibracja. Podczas pierwszej kalibracji nie jest konieczne wprowadzenie identyfikacji rejestracyjnej pojazdu (VRN i państwo członkowskie), 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)

w pkt 5.2 wprowadza się następujące zmiany:

(i)

pkt 395 akapit pierwszy otrzymuje brzmienie:

Po zainstalowaniu i sprawdzeniu urządzenia rejestrującego mocuje się na nim dobrze widoczną i łatwo dostępną tabliczkę instalacyjną, wygrawerowaną lub nadrukowaną w trwały sposób. Jeżeli nie jest to możliwe, tabliczkę mocuje się na słupku „B” pojazdu, tak aby była dobrze widoczna. W przypadku pojazdów, które nie posiadają słupka „B”, tabliczkę instalacyjną należy umocować w strefie drzwi pojazdu, tak aby zawsze była dobrze widoczna.”;

(ii)

w pkt 396 wprowadza się następujące zmiany:

1)

tiret dziesiąte otrzymuje brzmienie:

„-

numer seryjny urządzenia do łączności na odległość, jeżeli występuje,”;

2)

dodaje się tiret szesnaste w brzmieniu:

„-

domyślny typ załadunku związany z pojazdem.”;

28)

w pkt 6.4 wprowadza się następujące zmiany:

a)

pkt 409 otrzymuje brzmienie:

„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)

w pkt 410 dodaje się tiret dziewiąte w brzmieniu:

„-

czy identyfikator wersji przechowywanej mapy cyfrowej jest najnowszym identyfikatorem.”;

c)

dodaje się pkt 410 a w brzmieniu:

„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.”;

29)

w pkt 8 wprowadza się następujące zmiany:

a)

w pkt 8.1 pkt 429 i 430 otrzymują brzmienie:

„429)

Procedury aktualizacji oprogramowania w prawidłowo funkcjonującym urządzeniu rejestrującym zatwierdza organ, który wydał homologację typu dla tego urządzenia rejestrującego. Aktualizacja oprogramowania nie może zmienić ani usunąć żadnych danych dotyczących czynności kierowcy przechowywanych w pamięci urządzenia rejestrującego. Oprogramowanie można aktualizować wyłącznie na odpowiedzialność producenta urządzenia.

430)

Nie można odmówić homologacji typu zmian w oprogramowaniu, których celem jest aktualizacja wcześniej homologowanego typu urządzenia rejestrującego, jeżeli takie zmiany dotyczą wyłącznie funkcji nieokreślonych w niniejszym 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)

w pkt 8.4 wprowadza się następujące zmiany:

(i)

pkt 443 otrzymuje brzmienie:

„443)

Laboratorium nie może przeprowadzać żadnych badań interoperacyjności urządzeń rejestrujących ani kart do tachografó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.”;

(ii)

pkt 447 otrzymuje brzmienie:

„447)

Laboratorium wydaje producentowi świadectwo interoperacyjności tylko wówczas, gdy objęte nim urządzenia pomyślnie przejdą wszystkie wymagane badania interoperacyjnoś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.”;

30)

w dodatku 1 wprowadza się następujące zmiany:

a)

w spisie treści wprowadza się następujące zmiany:

(i)

dodaje się pkt 2.11a i 2.11b w brzmieniu:

„2.11a.

CardBorderCrossing

2.11b.

CardBorderCrossingRecord”;

(ii)

dodaje się pkt 2.24a, 2.24b, 2.24c i 2.24d w brzmieniu:

„2.24a.

CardLoadTypeEntries

2.24b.

CardLoadTypeEntryRecord

2.24c.

CardLoadUnloadOperations

2.24d.

CardLoadUnloadRecord”;

(iii)

dodaje się pkt 2.26a w brzmieniu:

„2.26a.

CardPlaceAuthDailyWorkPeriod”;

(iv)

dodaje się pkt 2.48a w brzmieniu:

„2.48a.

CompanyCardApplicationIdentificationV2”;

(v)

dodaje się pkt 2.50a w brzmieniu:

„2.50a.

ControlCardApplicationIdentificationV2”;

(vi)

dodaje się pkt 2.60a w brzmieniu:

„2.60a.

DownloadInterfaceVersion”;

(vii)

dodaje się pkt 2.61a w brzmieniu:

„2.61a.

DriverCardApplicationIdentificationV2”;

(viii)

dodaje się pkt 2.79a, 2.79b i 2.79c w brzmieniu:

„2.79a.

GNSSAuthAccumulatedDriving

2.79b.

GNSSAuthStatusADRecord

2.79c.

GNSSPlaceAuthRecord”;

(ix)

pkt 2.84 otrzymuje brzmienie:

„2.84.

Zarezerwowane dla przyszłego użytku”;

(x)

dodaje się pkt 2.89a w brzmieniu:

„2.89a.

LengthOfFollowingData”;

(xi)

dodaje się pkt 2.90a w brzmieniu:

„2.90a.

LoadType”;

(xii)

dodaje się pkt 2.101a w brzmieniu:

„2.101a.

NoOfBorderCrossingRecords”;

(xiii)

dodaje się pkt 2.111a w brzmieniu:

„2.111a.

NoOfLoadUnloadRecords”;

(xiv)

dodaje się pkt 2.112a w brzmieniu:

„2.112a.

NoOfLoadTypeEntryRecords”;

(xv)

dodaje się pkt 2.114a w brzmieniu:

„2.114a.

OperationType”;

(xvi)

dodaje się pkt 2.116a i 2.116b w brzmieniu:

„2.116a.

PlaceAuthRecord

2.116b.

PlaceAuthStatusRecord”;

(xvii)

dodaje się pkt 2.117a w brzmieniu:

„2.117a.

PositionAuthenticationStatus”;

(xviii)

dodaje się pkt 2.158a w brzmieniu:

„2.158a.

TachographCardsGen1Suppression”;

(xix)

dodaje się pkt 2.166a w brzmieniu:

„2.166a.

VehicleRegistrationIdentificationRecordArray”;

(xx)

dodaje się pkt 2.185a w brzmieniu:

„2.185a.

VuConfigurationLengthRange”;

(xxi)

dodaje się pkt 2.192a w brzmieniu:

„2.192a.

VuDigitalMapVersion”;

(xxii)

dodaje się pkt 2.203a i 2.203b w brzmieniu:

„2.203a.

VuBorderCrossingRecord

2.203b.

VuBorderCrossingRecordArray”;

(xxiii)

dodaje się pkt 2.204a w brzmieniu:

„2.204a.

VuGnssMaximalTimeDifference”;

(xxiv)

dodaje się pkt 2.208a i 2.208b w brzmieniu:

„2.208a.

VuLoadUnloadRecord

2.208b.

VuLoadUnloadRecordArray”;

(xxv)

dodaje się pkt 2.222a w brzmieniu:

„2.222a.

VuRtcTime”;

(xxvi)

dodaje się pkt 2.234a, 2.234b i 2.234c w brzmieniu:

„2.234a.

WorkshopCardApplicationIdentificationV2

2.234b.

WorkshopCardCalibrationAddData

2.234c.

WorkshopCardCalibrationAddDataRecord”;

b)

w pkt 2 tekst wprowadzający przed pkt 2.1 otrzymuje brzmienie:

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ą zapisywane 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«.”;

c)

dodaje się pkt 2.11a i 2.11b w brzmieniu:

„2.11a.

CardBorderCrossings

Generacja 2, wersja 2:

Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące przekroczeń granicy przez pojazd, jeżeli przekroczył on granicę krajową (wymogi 306f i 356f określone w załączniku IC).

Image 2

borderCrossingPointerNewestRecord jest indeksem ostatniego uaktualnionego rekordu przekroczenia granicy.

Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordu dotyczącego przekroczenia granicy, rozpoczynając od ‘0’ dla pierwszego wystąpienia w strukturze rekordu dotyczącego przekroczenia granicy.

cardBorderCrossingRecords jest zbiorem rekordów przekroczenia granicy.

2.11b.

CardBorderCrossingRecord

Generacja 2, wersja 2:

Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące przekroczeń granicy przez pojazd, jeżeli przekroczył on granicę krajową (wymogi 147b, 306e i 356e określone w załączniku IC).

Image 3

countryLeft to kraj, który pojazd opuścił, lub „brak dostępnych informacji” zgodnie z wymogiem 147b określonym w załączniku IC. „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).

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łączniku IC, a także jej statusu uwierzytelnienia.

vehicleOdometerValue to stan licznika kilometrów, gdy przyrząd rejestrujący wykrył, że pojazd przekroczył granicę krajową, lub „brak dostępnych informacji” zgodnie z wymogiem 147b w załączniku IC.”;

d)

dodaje się pkt 2.24a, 2.24b, 2.24c i 2.24d w brzmieniu:

„2.24a.

CardLoadTypeEntries

Generacja 2, wersja 2:

Informacje przechowywane na karcie kierowcy lub warsztatowej dotyczą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).

Image 4

loadTypeEntryPointerNewestRecord to indeks ostatniego uaktualnionego 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.

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 dotyczą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).

Image 5

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 dotyczące operacji załadunku/rozładunku pojazdu (wymogi 306h i 356h określone w załączniku IC).

Image 6

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ładunku/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 dotyczące operacji załadunku/rozładunku pojazdu (wymogi 306g i 356g określone w załączniku IC).

Image 7

timeStamp to data i godzina rozpoczęcia operacji załadunku/rozładunku.

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 rozpoczęciem operacji załadunku/rozładunku.”;

e)

dodaje się pkt 2.26a w brzmieniu:

„2.26a.

CardPlaceAuthDailyWorkPeriod

Generacja 2, wersja 2:

Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej, przedstawiające status uwierzytelnienia miejsc rozpoczęcia lub zakończenia dziennych okresów pracy (wymogi 306b i 356b określone w załączniku IC).

Image 8

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 uwierzytelnienia miejsca dla wprowadzanych miejsc.”;

f)

w pkt 2.36 wiersz odpowiadający przypisaniu wartości ‘bbH’ otrzymuje brzmienie:

 

‘‘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”;

g)

w pkt 2.40 akapit między nagłówkiem a kodem otrzymuje brzmienie:

„Generacja 2:

Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące przyrządów rejestrujących używanych przez posiadacza karty (wymogi 304 i 352 określone w załączniku IC).”;

h)

dodaje się pkt 2.48a w brzmieniu:

„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).

Image 9

lengthOfFollowingData to liczba kolejnych bajtów we wpisie.

vuConfigurationLengthRange to liczba bajtów na karcie do tachografu, dostępnych na potrzeby przechowywania konfiguracji VU.”;

i)

dodaje się pkt 2.50a w brzmieniu:

„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).

Image 10

lengthOfFollowingData to liczba kolejnych bajtów we wpisie.

vuConfigurationLengthRange to liczba bajtów na karcie do tachografu, dostępnych na potrzeby przechowywania konfiguracji VU.”;

j)

dodaje się pkt 2.60a w brzmieniu:

„2.60a.

DownloadInterfaceVersion

Generacja 2, wersja 2:

Kod wskazujący wersję interfejsu pobierania danych przyrządu rejestrującego.

Image 11

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.”;

k)

dodaje się pkt 2.61a w brzmieniu:

„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).

Image 12

lengthOfFollowingData to liczba kolejnych bajtów we wpisie.

noOfBorderCrossingRecords to liczba rekordów dotyczących przekroczenia 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 tachografu, dostępnych na potrzeby przechowywania konfiguracji VU.”;

l)

pkt 2.63 otrzymuje brzmienie:

„2.63.

DSRCSecurityData

Generacja 2:

Definicja tego typu danych znajduje się w dodatku 11.”;

m)

w pkt 2.66 tekst związany z nagłówkiem „Generacja 2” zastępuje się tekstem w brzmieniu:

„Generacja 2

Image 13

Przypisanie wartości: zgodnie z normą ISO/IEC8824-1.”;

n)

w pkt 2.70 wprowadza się następujące zmiany:

i)

nagłówek „Generacja 2” zastępuje się nagłówkiem w brzmieniu:

„Generacja 2, wersja 1:”;

ii)

dodaje się tekst w brzmieniu;

 

„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 zabezpieczenia przyrządu rejestrującego,

‘10’H

brak dalszych szczegółów,

‘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żytkownika,

‘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 czynności kierowcy,

‘1D’H do ‘1F’H

RFU,

‘2x’H

zdarzenia związane z próbami naruszenia zabezpieczenia 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.”;

o)

pkt 2.71 otrzymuje brzmienie:

„2.71.

ExtendedSealIdentifier

Generacja 2:

Rozszerzony identyfikator plomby jednoznacznie identyfikuje plombę (wymóg 401 określony w załączniku IC).

Image 14

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, niepowtarzalny w domenie producenta zgodnie z [ISO8859-1].”;

p)

w pkt 2.76 akapit między nagłówkiem a kodem otrzymuje brzmienie:

„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).”;

q)

dodaje się pkt 2.79a, 2.79b i 2.79c w brzmieniu:

„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).

Image 15

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 wielokrotność trzech godzin, oraz status uwierzytelnienia pozycji GNSS.

2.79b.

GNSSAuthStatusADRecord

Generacja 2, wersja 2:

Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej, 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).

Image 16

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 GNSSAccumulatedDrivingRecord),

authenticationStatus to status uwierzytelnienia pozycji GNSS, gdy skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin.

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).

Image 17

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.”;

r)

pkt 2.84 otrzymuje brzmienie:

„2.84.

Zarezerwowane dla przyszłego użytku”;

s)

dodaje się pkt 2.89a w brzmieniu:

„2.89a.

LengthOfFollowingData

Generacja 2, wersja 2:

Wskaźnik długości dla rozszerzalnych rekordów.

Image 18

Przypisanie wartości: zob. dodatek 2.”;

t)

dodaje się pkt 2.90a w brzmieniu:

„2.90a.

LoadType

Generacja 2, wersja 2:

Kod identyfikujący wpisany typ załadunku.

Image 19

Przypisanie wartości:

‘00’H

nieokreślony typ załadunku,

‘01’H

towary,

‘02’H

pasażerowie,

‘03’H .. ‘FF’H

RFU.”;

u)

dodaje się pkt 2.101a w brzmieniu:

„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.

Image 20

Przypisanie wartości: zob. dodatek 2.”;

v)

dodaje się pkt 2.111a w brzmieniu:

„2.111a.

NoOfLoadUnloadRecords

Generacja 2, wersja 2:

Liczba rekordów dotyczących załadunku/rozładunku, które mogą być przechowywane na karcie.

Image 21

Przypisanie wartości: zob. dodatek 2.”;

w)

dodaje się pkt 2.112a w brzmieniu:

„2.112a.

NoOfLoadTypeEntryRecords

Generacja 2, wersja 2:

Liczba rekordów dotyczących typu załadunku, które mogą być przechowywane na karcie kierowcy lub na karcie warsztatowej.

Image 22

Przypisanie wartości: zob. dodatek 2.”;

x)

dodaje się pkt 2.114a w brzmieniu:

„2.114a.

OperationType

Generacja 2, wersja 2:

Kod identyfikujący wpisany typ operacji.

Image 23

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.”;

y)

dodaje się pkt 2.116a i 2.116b w brzmieniu:

„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:

Image 24

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 wpisywania miejsca.

entryGNSSPlaceAuthRecord to zarejestrowana lokalizacja, status uwierzytelnienia GNSS oraz godzina.

2.116b.

PlaceAuthStatusRecord

Generacja 2, wersja 2:

Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej, 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).

Image 25

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.”;

z)

dodaje się pkt 2.117a w brzmieniu:

„2.117a.

PositionAuthenticationStatus

Generacja 2, wersja 2:

Image 26

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.”;

aa)

w pkt 2.120 tekst dotyczący przypisania wartości ‘22’H to ‘7F’H zastępuje się tekstem w brzmieniu:

„‘22’H

VuBorderCrossingRecord,

‘23’H

VuLoadUnloadRecord,

‘24’H

VehicleRegistrationIdentification,

‘25’H do ‘7F’H

RFU.”;

bb)

dodaje się pkt 2.158a w brzmieniu:

„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).

Image 27 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.”;

cc)

dodaje się pkt 2.166a w brzmieniu:

„2.166a.

VehicleRegistrationIdentificationRecordArray

Generacja 2, wersja 2:

Identyfikacja rejestracyjna pojazdu wraz z metadanymi stosowana w protokole pobierania danych.

Image 28

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.”;

dd)

w pkt 2.168 wiersz pierwszy pod nagłówkiem otrzymuje brzmienie:

„Generacja 2, wersja 1:”;

ee)

w pkt 2.174 wprowadza się następujące zmiany:

i)

nagłówek „Generacja 2” zastępuje się nagłówkiem w brzmieniu:

„Generacja 2, wersja 1:”;

ii)

dodaje się tekst w brzmieniu;

„Generacja 2, wersja 2:

Image 29

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 odległ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ę.”;

ff)

dodaje się pkt 2.185a w brzmieniu:

„2.185a.

VuConfigurationLengthRange

Generacja 2, wersja 2:

Liczba bajtów na karcie do tachografu, dostępnych na potrzeby przechowywania konfiguracji VU.

Image 30

Przypisanie wartości: zob. dodatek 2.”;

gg)

dodaje się pkt 2.192a w brzmieniu:

„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).

Image 31

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).”;

hh)

w pkt 2.203 wprowadza się następujące zmiany:

i)

nagłówek „Generacja 2” zastępuje się nagłówkiem w brzmieniu:

„Generacja 2, wersja 1:”;

ii)

dodaje się tekst w brzmieniu;

„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).

Image 32

W wersji 2 generacji 2 zamiast gnssPlaceRecord stosuje się rekord gnssPlaceAuthRecord, który zawiera dodatkowo status uwierzytelnienia GNSS.”;

ii)

dodaje się pkt 2.203a i 2.203b w brzmieniu:

„2.203a.

VuBorderCrossingRecord

Generacja 2, wersja 2:

Informacje przechowywane w przyrządzie rejestrującym dotyczące przekroczeń granicy przez pojazd, jeżeli przekroczył on granicę krajową (wymogi 133a i 133b określone w załączniku IC).

Image 33

cardNumberAndGenDriverSlot identyfikuje kartę, w tym jej generację, włożoną do szczeliny czytnika karty kierowcy.

cardNumberAndGenCodriverSlot identyfikuje kartę, w tym jej generację, włożoną do szczeliny czytnika karty współkierowcy.

countryLeft to kraj, który pojazd opuścił, określony na podstawie ostatniej dostępnej pozycji przed wykryciem przekroczenia granicy. „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).

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 rejestrujący wykrył, że pojazd przekroczył granicę krajową.

2.203b.

VuBorderCrossingRecordArray

Generacja 2, wersja 2:

Informacje przechowywane w przyrządzie rejestrującym dotyczące przekroczeń granicy przez pojazd (wymóg 133c określony w załączniku IC).

Image 34

recordType oznacza typ rekordu (VuBorderCrossingRecord). Przypisanie 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.”;

jj)

dodaje się pkt 2.204a w brzmieniu:

„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.

Image 35

”;

kk)

w pkt 2.205 tekst związany z nagłówkiem „Generacja 2” zastępuje się tekstem w brzmieniu:

„Generacja 2:

Image 36

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).”;

ll)

dodaje się pkt 2.208a i 2.208b w brzmieniu:

„2.208a.

VuLoadUnloadRecord

Generacja 2, wersja 2:

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).

Image 37

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 generację, włożoną do szczeliny czytnika karty kierowcy.

cardNumberAndGenCodriverSlot identyfikuje kartę, w tym jej generację, 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łączniku IC).

Image 38

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.”;

mm)

w pkt 2.219 wprowadza się następujące zmiany:

i)

nagłówek „Generacja 2” zastępuje się nagłówkiem w brzmieniu:

„Generacja 2, wersja 1:”;

ii)

dodaje się tekst w brzmieniu;

„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).

Image 39

Zamiast placeRecord w strukturze danych wersji 2 generacji 2 wykorzystuje się następujący element danych:

placeAuthRecord zawiera informacje dotyczące wpisanego miejsca, zarejestrowanej pozycji, statusu uwierzytelnienia GNSS i godziny określenia pozycji.”;

nn)

po pkt 2.222 dodaje się punkt w brzmieniu:

„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.

Image 40

”;

oo)

dodaje się pkt 2.234a, 2.234b i 2.234c w brzmieniu:

„2.234a.

WorkshopCardApplicationIdentificationV2

Generacja 2, wersja 2:

Informacje przechowywane na karcie warsztatowej dotyczące identyfikacji aplikacji karty (wymóg 330a określony w załączniku IC).

Image 41

lengthOfFollowingData to liczba kolejnych bajtów we wpisie.

noOfBorderCrossingRecords to liczba rekordów dotyczących przekroczenia 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 tachografu, dostępnych na potrzeby przechowywania konfiguracji VU.

2.234b.

WorkshopCardCalibrationAddData

Generacja 2, wersja 2:

Informacje przechowywane na karcie warsztatowej dotyczące dodatkowych danych (tj. domyślnego typu załadunku) wprowadzonych podczas kalibracji (wymóg 356l określony w załączniku IC).

Image 42

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 zawierają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).

Image 43

oldTimeValue to stara wartość daty i godziny zawarta w odpowiednim rekordzie WorkshopCardCalibrationRecord,

vehicleIdentificationNumber to numer identyfikacyjny pojazdu, również zawarty w odpowiednim rekordzie WorkshopCardCalibrationRecord,

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.”;

31)

w dodatku 2 wprowadza się następujące zmiany:

a)

w pkt 2.5 pozycja TCS_09 akapit drugi otrzymuje brzmienie:

„stan operacyjny, w którym karta wykonuje polecenia lub jest połączona z przyrządem rejestrującym;”;

b)

w pkt 3 wprowadza się następujące zmiany:

i)

w pkt 3.2.1 uchyla się tiret czwarte w pozycji TCS_16:

ii)

w pkt 3.5.7.2 wprowadza się następujące zmiany:

1)

pozycja TCS_86 otrzymuje brzmienie:

„TCS_86

Polecenie może być wykonywane w MF, w DF Tachograph i w DF Tachograph_G2 (zob. również TCS_34).”;

2)

pozycje TCS_88 i TCS_89 otrzymują brzmienie:

„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 zastosowanie 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 utworzenia łańcucha, każda wartość ‘Lc’ do podanej maksymalnej wielkości rozszerzonej długości musi być obsługiwana przez kartę.

  Uwaga: Zgodnie z dodatkiem 11 karta przechowuje certyfikat lub odpowiednie treści certyfikatu oraz uaktualnia jego currentAuthenticatedTime.

  Struktura komunikatu odpowiedzi i słowa stanu zostały określone w TCS_85.”;

iii)

w pkt 3.5.10 ostatni wiersz tabeli w pozycji TCS_101 otrzymuje brzmienie:

„Le

1

‘00h’

zgodnie ze specyfikacją w normie ISO/IEC 7816-4

”;

iv)

w pkt 3.5.16 ostatni wiersz tabeli w pozycji TCS_138 otrzymuje brzmienie:

„Le

1

‘00h’

zgodnie ze specyfikacją w normie ISO/IEC 7816-4

”;

c)

w pkt 4 wprowadza się następujące zmiany:

i)

pozycja TCS_141 akapit drugi otrzymuje brzmienie:

„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 warsztatowej aplikacja generacji 1 obsługuje maksymalną liczbę rekordów określoną w TCS_150 i TCS_158.”;

ii)

w pkt 4.2.1 w tabeli w pozycji TCS_150 wprowadza się następujące zmiany:

1)

wiersz dotyczący cardIssuingAuthorityName zastępuje się tekstem w brzmieniu:

Image 44

”;

2)

wiersz dotyczący LastCardDownload zastępuje się tekstem w brzmieniu:

Image 45

”;

iii)

w pkt 4.2.2 wprowadza się następujące zmiany:

1)

pozycja TCS_152 otrzymuje brzmienie:

„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.

Image 46

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”;

2)

pozycja TCS_154 otrzymuje brzmienie:

„TCS_154

Aplikacja karty kierowcy 2. generacji ma następującą strukturę danych:

Image 47

Image 48

Image 49

”;

3)

tabela w pozycji TCS_155 otrzymuje brzmienie:

 

 

 

 

 

 

Min.

Maks.

n1

NoOfEventsPerType

12

12

n2

NoOfFaultsPerType

24

24

n3

NoOfCardVehicleRecords

200

200

n4

NoOfCardPlaceRecords

112

112

n6

CardActivityLengthRange

13776 bajtów

(56 dni * 117 zmian czynności)

13776 bajtów

(56 dni * 117 zmian czynności)

n7

NoOfCardVehicleUnitRecords

200

200

n8

NoOfGNSSADRecords

336

336

n9

NoOfSpecificConditionRecords

112

112

n10

NoOfBorderCrossingRecords

1120

1120

n11

NoOfLoadUnloadRecords

1624

1624

n12

NoOfLoadTypeEntryRecords

336

336

n13

VuConfigurationLengthRange

3072 bajty

3072 bajty

”;

iv)

w pkt 4.3.2 wprowadza się następujące zmiany:

1)

pozycja TCS_160 otrzymuje brzmienie:

„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_Authentication, EF Border_Crossings, EF Load_Unload_Operations, 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 warsztatowych, natomiast jest równy {01 00} dla wersji 1 generacji 2 kart warsztatowych.

Image 50

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”;

2)

tabela w pozycji TCS_162 otrzymuje brzmienie:

Image 51

Image 52

Image 53

Image 54

”;

3)

tabela w pozycji TCS_163 otrzymuje brzmienie:

 

 

 

 

 

 

Min.

Maks.

n1

NoOfEventsPerType

3

3

n2

NoOfFaultsPerType

6

6

n3

NoOfCardVehicleRecords

8

8

n4

NoOfCardPlaceRecords

8

8

n5

NoOfCalibrationRecords

255

255

n6

CardActivityLengthRange

492 bajty (1 dzień * 240 zmian czynności)

492 bajty (1 dzień *

240 zmian czynności)

n7

NoOfCardVehicleUnitRecords

8

8

n8

NoOfGNSSADRecords

24

24

n9

NoOfSpecificConditionRecords

4

4

n10

NoOfBorderCrossingRecords

4

4

n11

NoOfLoadUnloadRecords

8

8

n12

NoOfLoadTypeEntryRecords

4

4

n13

VuConfigurationLengthRange

3072 bajty

3072 bajty

”;

v)

w pkt 4.4.2 wprowadza się następujące zmiany:

1)

pozycja TCS_168 otrzymuje brzmienie:

„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.

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 kontrolnych, natomiast jest równy {01 00} dla wersji 1 generacji 2 kart kontrolnych.

Image 55

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”;

2)

tabela w pozycji TCS_170 otrzymuje brzmienie:

Image 56

Image 57

”;

3)

tabela w pozycji TCS_171 otrzymuje brzmienie:

 

 

 

 

 

 

Min.

Maks.

n7

NoOfControlActivityRecords

230

520

n13

VuConfigurationLengthRange

3072 ajty

3072 bajty

”;

vi)

w pkt 4.5.2 wprowadza się następujące zmiany:

1)

pozycja TCS_176 otrzymuje brzmienie:

„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 firmowych, natomiast jest równy {01 00} dla wersji 1 generacji 2 kart firmowych.

Image 58

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”;

2)

tabela w pozycji TCS_178 otrzymuje brzmienie:

Image 59

”;

3)

tabela w pozycji TCS_179 otrzymuje brzmienie:

 

 

 

 

 

 

Min.

Maks.

n8

NoOfCompanyActivityRecords

230

520

n13

VuConfigurationLengthRange

3072 bajty

3072 bajty

”;

32)

w dodatku 3 wprowadza się następujące zmiany:

a)

w pkt 1 wprowadza się następujące zmiany:

i)

akapit z nagłówkiem „Warunki szczególne” otrzymuje brzmienie:

Stany szczególne, wpisy wprowadzane ręcznie

Image 60

poza zakresem

Image 61

przeprawa promowa/pociągowa

Image 62

operacja załadunku

Image 63

operacja rozładunku

Image 64

operacja równoczesnego załadunku/rozładunku

Image 65

typ załadunku: pasażerowie

Image 66

typ załadunku: towary

Image 67

typ załadunku: nieokreślony typ załadunku”;

ii)

w piktogramach pod nagłówkiem „Różne” wprowadza się następujące zmiany:

1)

piktogram „zabezpieczenie” zastępuje się następującym piktogramem:

Image 68

zabezpieczenie/uwierzytelnione dane/plomby”;

2)

dodaje się następujący piktogram:

Image 69

mapa cyfrowa/przekroczenie granicy”;

b)

w pkt 2 wprowadza się następujące zmiany:

i)

do piktogramów pod nagłówkiem „Różne” dodaje się następujące kombinacje piktogramów:

 

Image 70

pozycja, gdzie pojazd przekroczył granicę między dwoma krajami

Image 71

pozycja, gdzie miała miejsce operacja załadunku

Image 72

pozycja, gdzie miała miejsce operacja rozładunku

Image 73

pozycja, gdzie miała miejsce operacja równoczesnego załadunku/rozładunku”;

ii)

do piktogramów pod nagłówkiem „Wydruki” dodaje się następującą kombinację piktogramów:

Image 74

wydruk historii włożonych kart”;

iii)

do piktogramów pod nagłówkiem „Zdarzenia” dodaje się następującą kombinację piktogramów:

Image 75

anomalia GNSS”;

33)

w dodatku 4 wprowadza się następujące zmiany:

a)

w pkt 1 pozycja PRT_005 otrzymuje brzmienie:

„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)

w pkt 2 wprowadza się następujące zmiany:

i)

po tabeli i przed pozycją PRT_007 dodaje się tiret w brzmieniu:

„-

w bloku danych tekst po ‘pi=’ odnosi się do odpowiedniego piktogramu lub kombinacji piktogramów określonych w dodatku 3,

-

w przypadku wydruku po długości i szerokości geograficznej zarejestrowanej pozycji lub po znaczniku czasu, gdy pozycja została określona, Image 76 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.”;

ii)

bloki 2 i 3 otrzymują brzmienie:

Image 77

Image 78

W przypadku gdy karta nie jest kartą osobistą i nie zawiera nazwiska posiadacza karty, zamiast nazwiska drukuje się nazwę przedsiębiorstwa, warsztatu lub organu kontrolnego.”;

iii)

przed blokiem 4 skreśla się zdanie poprzedzone gwiazdką.

iv)

po bloku 4 dodaje się blok w brzmieniu:

Image 79

”;

v)

blok 5 otrzymuje brzmienie:

Image 80

”;

vi)

przed blokiem 6 skreśla się zdanie poprzedzone gwiazdką.

vii)

po bloku 8a dodaje się blok w brzmieniu:

Image 81

”;

(viii)

blok 8.2 otrzymuje brzmienie:

Image 82

”;

ix)

blok 10.2 otrzymuje brzmienie:

Image 83

”;

x)

przed blokiem 11 skreśla się zdanie poprzedzone gwiazdką.

xi)

bloki 11.4 i 11.5 otrzymują brzmienie:

Image 84

Image 85

Image 86

Image 87

”;

xii)

blok 14 otrzymuje brzmienie:

Image 88

”;

(xiii)

blok 15.1 otrzymuje brzmienie:

Image 89

”;

xiv)

bloki 16 i 16.1 otrzymują brzmienie:

16

Identyfikacja urządzenia GNSS*

Image 90

Image 91

Image 92

Image 93

”;

xv)

blok 17.1 otrzymuje brzmienie:

Image 94

Cel kalibracji (p) jest kodem numerycznym wyjaśniającym, dlaczego zapisano parametry kalibracji, i jest kodowany zgodnie z elementem danych CalibrationPurpose.”;

xvi)

blok 23 otrzymuje brzmienie:

Image 95 ”;

c)

w pkt 3 wprowadza się następujące zmiany:

i)

w pkt 3.1 pozycja PRT_008 otrzymuje brzmienie:

„PRT_008

Wydruk dzienny czynności kierowcy z karty jest zgodny z poniższym formatem:

Image 96 ”;

ii)

w pkt 3.2 pozycja PRT_009 otrzymuje brzmienie:

„PRT_009

Wydruk dzienny czynności kierowcy z VU jest zgodny z poniższym formatem:

Image 97 ”;

iii)

w pkt 3.5 pozycja PRT_012 otrzymuje brzmienie:

„PRT_012

Wydruk danych technicznych jest zgodny z poniższym formatem:

Image 98 ”;

iv)

w pkt 3.7 pozycja PRT_014 otrzymuje brzmienie:

„PRT_014

Wydruk historii włożonych kart jest zgodny z poniższym formatem:

Image 99 ”;

34)

w dodatku 7 wprowadza się następujące zmiany:

a)

w spisie treści wprowadza się następujące zmiany:

i)

pkt 2.2.6.1–2.2.6.5 otrzymują brzmienie:

„2.2.6.1

Positive Response Transfer Data Download Interface Version (Pozytywna 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 odpowiedź 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)”;

ii)

dodaje się literę w brzmieniu:

„2.2.6.6

Positive Response Transfer Data Technical Data (Pozytywna odpowiedź na żądanie przesłania danych technicznych)”;

b)

w pkt 2 wprowadza się następujące zmiany:

i)

w pkt 2.2.2 tabela struktury komunikatu i uwagi po tabeli otrzymują brzmienie:

Struktura komunikatu

Maks. 4 bajty

Maks. 255 bajtów

1 bajt

 

 

Nagłówek

Dane

Suma kontrolna

IDE ->

<- VU

FMT

TGT

SRC

LEN

SID

DS_ / TRTP

DATA

CS

Żą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 diagnostycznej

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ędkoś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

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 czytnika karty kierowcy) albo ‘2’ (karta w szczelinie czytnika karty współkierowcy).

W przypadku gdy szczelina nie jest określona, VU wybiera szczelinę 1, jeżeli karta jest włożona w tę szczelinę, a szczelinę 2 wybiera tylko wówczas, gdy użytkownik specjalnie ją wybierze.

TRTP 24 używa się w przypadku żądań pobrania danych z przyrzą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.”;

ii)

w pkt 2.2.2.9 wprowadza się następujące zmiany:

1)

w pozycji DDP_011 akapit drugi i tabela pierwsza otrzymują brzmienie:

„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 przyrządu rejestrującego typu 1. generacji

 

Wartość TRTP w przypadku żądań pobrania danych z przyrządu rejestrującego typu 2. generacji (wersja 1)

 

Wartość TRTP w przypadku żądań pobrania danych z przyrzą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

”;

2)

pozycja DDP_054 otrzymuje brzmienie:

„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.”;

iii)

w pkt 2.2.2.10 tekst przed tiret w pozycji DDP_055 otrzymuje brzmienie:

„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:”;

iv)

w pkt 2.2.5.2 rys. 2 zastępuje się następującym rysunkiem:

Image 100 ”;

v)

pkt 2.2.6.1–2.2.6.5 otrzymują brzmienie:

„2.2.6.1

Positive Response Transfer Data Download Interface Version (Pozytywna odpowiedź na żądanie przesłania danych dotyczących wersji interfejsu pobierania danych)

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:

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

Positive Response Transfer Data Overview (Pozytywna odpowiedź na żądanie przesłania danych przeglądowych)

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 przechowywane 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 VehicleIdentificationNumber aż do ostatniego bajtu ostatniego 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

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 przechowywane 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 przechowywane 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

Positive Response Transfer Data Activities (Pozytywna odpowiedź na żądanie przesłania danych dotyczących czynności)

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:

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 pojawiać się w pełni w ciągu dwóch odpowiednich dni.

 

 

 

 

 

 

 

VuActivityDailyData

 

Stan szczelin o godzinie 00:00 i zmiany czynności zapisane dla pobieranego dnia.

 

 

VuPlaceDailyWorkPeriodData

 

Dane dotyczące miejsc zapisane dla pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfPlaceRecords = 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 pojawiać się w pełni w ciągu dwóch odpowiednich dni.

VuActivityDailyRecordArray

 

Stan szczelin o godzinie 00:00 i zmiany czynności zapisane 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.

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 pojawiać się w pełni w ciągu dwóch odpowiednich dni.

VuActivityDailyRecordArray

 

Stan szczelin o godzinie 00:00 i zmiany czynności zapisane 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 noOfRecords = 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.

 

 

 

2.2.6.4

Positive Response Transfer Data Events and Faults (Pozytywna odpowiedź na żądanie przesłania danych dotyczących zdarzeń i usterek)

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 licznikami:

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 noOfVuFaults = 0.

VuEventData

 

Wszystkie zdarzenia (z wyjątkiem przekroczenia prędkości) przechowywane lub trwające w VU.

Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfVuEvents = 0.

VuOverSpeedingControlData

 

Dane dotyczące ostatniej kontroli przekroczenia prędkoś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 noOfVuOverSpeedingEvents = 0.

VuTimeAdjustmentData

 

Wszystkie zdarzenia dotyczące korekty czasu przechowywane w VU (poza ramami pełnej kalibracji).

Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfVuTimeAdjRecords = 0.

Signature

 

Podpis RSA wszystkich danych, począwszy od noOfVuFaults 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ędkoś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ędkoś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 przechowywane 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ędkoś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ędkoś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 przechowywane 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

Positive Response Transfer Data Detailed Speed (Pozytywna odpowiedź na żądanie przesłania danych szczegółowych dotyczących prędkości)

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 licznikami:

Struktura danych generacji 1 (TREP 04 Hex)

Element danych

 

Uwagi

VuDetailedSpeedData

 

Wszystkie szczegółowe dane dotyczące prędkości przechowywane 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 noOfSpeedBlocks aż do ostatniego bajtu ostatniego bloku prędkości.

 

 

 

Struktura danych generacji 2 (TREP 24 Hex)

Element danych

 

Uwagi

VuDetailedSpeedBlockRecordArray

 

Wszystkie szczegółowe dane dotyczące prędkości przechowywane 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.

 

 

 

”;

vi)

dodaje się literę w brzmieniu:

„2.2.6.6

Positive Response Transfer Data Technical Data (Pozytywna odpowiedź na żądanie przesłania danych technicznych)

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 vuManufacturerName 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 przechowywane w VU.

VuSensorExternalGNSSCoupledRecordArray

 

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 przechowywane w VU.

VuITSConsentRecordArray

 

 

VuPowerSupplyInterruptionRecordArray

 

 

SignatureRecordArray

 

Podpis ECC wszystkich poprzednich danych.

 

 

 

Struktura danych generacji 2, wersja 2 (TREP 35 Hex)

Element danych

 

Uwagi

VuIdentificationRecordArray

 

 

VuSensorPairedRecordArray

 

Wszystkie sparowania państw członkowskich przechowywane w VU.

VuSensorExternalGNSSCoupledRecordArray

 

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 przechowywane w VU.

VuITSConsentRecordArray

 

 

VuPowerSupplyInterruptionRecordArray

 

 

SignatureRecordArray

 

Podpis ECC wszystkich poprzednich danych.

 

 

 

”;

c)

w pkt 3.3 pozycja DDP_035 otrzymuje brzmienie:

„DDP_035

Pobieranie danych z karty do tachografu obejmuje następują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_Certificate. 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ą zabezpieczone podpisem cyfrowym przy użyciu wspólnych mechanizmów zabezpieczenia określonych w dodatku 11 część A.

Pobranie przynajmniej plików EF Application_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 przeprowadzanej 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.

Wczytanie plików EF zawierających inne dane aplikacyjne (w Tachograph_G2 DF) z wyłączeniem 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: Application_Identification, Application_Identification_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 stosownych przypadkach, Tachograph_G2.

Przy pobieraniu danych z karty warsztatowej pliki EF Sensor_Installation_Data w DF Tachograph i, w stosownych przypadkach, Tachograph_G2 nie mogą być pobierane.”;

35)

w dodatku 8 wprowadza się następujące zmiany:

a)

w spisie treści wprowadza się następujące zmiany:

i)

pkt 8, 8.1 i 8.2 otrzymują brzmienie:

„8.

USŁUGA ROUTINECONTROL (KOREKTA CZASU)

8.1.

Opis komunikatu

8.2.

Format komunikatu”;

ii)

dodaje się pkt 9, 9.1 i 9.2 w brzmieniu:

„9.

FORMATY DATARECORDS

9.1.

Zakresy przesyłanych parametrów

9.2.

Formaty dataRecords”;

b)

w pkt 3.1 w tabeli 1 dodaje się wiersz w brzmieniu:

 

Sesje diagnostyczne

RoutineControl

8

31

 

Image 101

Image 102

”;

c)

w pkt 6.1.3 pozycja CPR_053 otrzymuje brzmienie:

„CPR_053

Wartości recordDataIdentifier zdefiniowane w tym dokumencie pokazano w tabeli poniżej.

Tabela recordDataIdentifier składa się z pięciu kolumn i wielu wierszy.

Pierwsza kolumna (Heks) zawiera »wartość heksadecymalną« 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 przekodowanie).

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

HighResolutionTotalVehicleDistance

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

RemoteCommunicationModuleSerialNumber

RemoteCommunicationFacilitySerialNumber

R

RDI_RCSN

F9D2

SensorGNSSSerialNumber

ExternalGNSSFacilitySerialNumber

R

RDI_GSSN

F9D3

SealDataVu

SmartTachographSealsSerialNumber

R/W

RDI_SDV

F9D4

VuSerialNumber

VuSerialNumber

R

RDI_VSN

F9D5

ByDefaultLoadType

ByDefaultLoadType

R/W

RDI_BDLT

F9D6

TachographCardsGen1Suppression

TachographCardsGen1Suppression

R/W

RDI_TCG1S

F9D7

VehiclePosition

VehiclePosition

R

RDI_VP

F9D8

LastCalibrationCountry

CalibrationCountry

R

RDI_CC

”;

d)

pkt 8 otrzymuje brzmienie:

„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 (TimeAdjustment) VU musi być w trybie KALIBRACYJNYM.

Warunek wstępny: zapewnia się zdolność VU do odbierania komunikatów o uwierzytelnionej 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.

8.2.

Format komunikatu

CPR_065b

Formaty komunikatu dla usługi RoutineControl (TimeAdjustment) i jej prymitywów opisano szczegółowo w poniższych tabelach.

Tabela 37a

RoutineControl, komunikat żądania procedury (TimeAdjustment), podfunkcja startRoutine

# bajtu

Nazwa parametru

Wartość heksadecymalna

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

Tabela 37b

RoutineControl, procedura (TimeAdjustment), podfunkcja startRoutine, komunikat pozytywnej odpowiedzi

# bajtu

Nazwa parametru

Wartość heksadecymalna

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ść heksadecymalna

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ść heksadecymalna

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

Tabela 37e

RoutineControl, komunikat negatywnej odpowiedzi na procedurę (TimeAdjustment)

# bajtu

Nazwa parametru

Wartość heksadecymalna

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ść heksadecymalna

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ść heksadecymalna

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

”;

e)

dodaje się pkt 9 w brzmieniu:

„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.

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 sprawdzania 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żliwiają urządzeniu wysłanie komunikatu polecenia i wskazanie 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 parametru 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 minimalnej lub maksymalnej parametru.

Tabela 38

Zakresy dataRecords

Nazwa zakresu

1 bajt

(wartość heksadecymalna)

2 bajty

(wartość heksadecymalna)

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.

CPR_074

W tabeli 39 podano długość, rozdzielczość i zakres roboczy dla każdego parametru identyfikowanego przez recordDataIdentifier:

Tabela 39

Format dataRecords

Nazwa parametru

Długość danych (w bajtach)

Rozdzielczość

Zakres roboczy

TimeDate

8

Zob. szczegółowy opis w tabeli 40

HighResolutionTotalVehicleDistance

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-3m/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

RemoteCommunicationModuleSerialNumber

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

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.

CPR_078

W tabeli 42 zamieszczono szczegółowy opis formatów poszczególnych bajtów parametru VehicleRegistrationNumber:

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 zdefiniowany w dodatku 1.

nie dotyczy

SealRecord

12 - 22

sealRecord2. Format SealRecord zdefiniowany w dodatku 1.

nie dotyczy

SealRecord

23 – 33

sealRecord3. Format SealRecord zdefiniowany w dodatku 1.

nie dotyczy

SealRecord

34 – 44

sealRecord4. Format SealRecord zdefiniowany w dodatku 1.

nie dotyczy

SealRecord

45 – 55

sealRecord5. Format SealRecord zdefiniowany 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:

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, SensorGNSSSerialNumber and RemoteCommunicationModuleSerialNumber:

 

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 TachographCardsGen1Suppression:

Tabela 46

Szczegółowy opis formatu TachographCardsGen1Suppression (wartość recordDataIdentifier # F9D6)

Bajt

Definicja parametru

Rozdzielczość

Zakres roboczy

1-2

TachographCardsGen1Suppression. Format TachographCardsGen1Suppression zdefiniowany 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.”;

36)

w dodatku 9 wprowadza się następujące zmiany:

a)

w spisie treści dodaje się pkt 9 w brzmieniu:

„9.

BADANIA OSNMA”;

b)

w pkt 1 wprowadza się następujące zmiany:

i)

w pkt 1.1 dodaje się akapit w brzmieniu:

„Organ państwa członkowskiego odpowiedzialny za badania funkcjonalnoś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ętrznego GNSS.”;

ii)

w pkt 1.2 dodaje się odniesienie w brzmieniu:

„RGODP

Sprawozdanie techniczne JRC – Receiver guidelines for OSNMA data processing (Wytyczne dla odbiorników w zakresie przetwarzania danych OSNMA)”;

c)

w pkt 2 wiersze 3.1–3.41 otrzymują brzmienie:

„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*

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 drogowych

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”;

d)

dodaje się pkt 9 w brzmieniu:

„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ż uwierzytelnianie sygnału satelitarnego jest wykonywane wyłącznie przez odbiornik GNSS niezależnie od jakiegokolwiek innego elementu składowego tachografu, badania określone w niniejszym rozdziale mogą być przeprowadzane na odbiorniku GNSS jako samodzielnym elemencie. W takim przypadku producent tachografów przedstawia organom udzielającym homologacji typu sprawozdanie zawierające szczegółowe informacje na temat rozwoju i wyników badań przeprowadzanych na odpowiedzialność 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 zobowią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]

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ą wielokonstelacyjnego symulatora GNSS obsługującego przesyłanie komunikatów OSNMA. Ewentualnie można zastosować odtwarzacz sygnału częstotliwoś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 oczyszczenie pamięci odbiornika (aby niezależnie usunąć klucz publiczny, KROOT, informacje zegarowe, informacje o pozycji, efemerydy i almanach), ustawienie realizacji czasu lokalnego odbiornika na potrzeby weryfikacji 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).

O ile nie zaznaczono inaczej, realizacja czasu odbiornika wewnętrznego musi być znana z wystarczającą dokładnością i odpowiednio zsynchronizowana 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ą zachowawcze 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 uwierzytelnionymi 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 uwierzytelnionymi 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.

 

Przed rozpoczęciem badań 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 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.

Dodatek 12,

GNS_3b

2.4

Gorący rozruch OSNMA z odtwarzanym 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 uwierzytelnionymi danymi.

 

Gdy odbiornik dostarczy rozwiązanie PVT z uwierzytelnionymi 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ł wszystkich widocznych satelitów Galileo i zweryfikować autentyczność ich komunikatów nawigacyjnych za pomocą OSNMA.

 

Co najmniej jeden bit danych efemerycznych dostarczonych przez każdego satelitę Galileo nie odpowiada pierwotnym 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 uwierzytelnionej ważnej pozycji do zakończenia badania.

Dodatek 12,

GNS_3b

”;

37)

w dodatku 12 wprowadza się następujące zmiany:

a)

w spisie treści wprowadza się następujące zmiany:

i)

po pkt 1.1 dodaje się pkt 1.1.1 w brzmieniu:

„1.1.1

Odniesienia”;

ii)

pkt 2 otrzymuje brzmienie:

„2.

PODSTAWOWA CHARAKTERYSTYKA ODBIORNIKA GNSS”

iii)

pkt 3 otrzymuje brzmienie:

„3.

KOMUNIKATY PODAWANE PRZEZ ODBIORNIK GNSS”;

iv)

dodaje się pkt 4.2.4 i 4.2.5 w brzmieniu:

„4.2.4

Struktura polecenia WriteRecord

4.2.5.

Inne polecenia”;

v)

pkt 5.2 otrzymuje brzmienie:

„5.2.

Transfer informacji z odbiornika GNSS do VU”;

vi)

uchyla się pkt 5.2.1;

vii)

dodaje się pkt 5.3, 5.4 i 5.4.1 w brzmieniu:

„5.3.

Transfer informacji z VU do odbiornika GNSS

5.4.

Obsługa błędów

5.4.1.

Brak informacji o pozycji z odbiornika GNSS”;

(viii)

pkt 6 i 7 otrzymują brzmienie:

„6.

PRZETWARZANIE I REJESTRACJA DANYCH O POZYCJI PRZEZ VU

7.

KONFLIKT CZASOWY GNSS”;

ix)

dodaje się pkt 8 w brzmieniu:

„8.

KONFLIKT RUCHU POJAZDU”;

b)

w pkt 1 wprowadza się następujące zmiany:

i)

tekst przed rys. 1 zastępuje się tekstem w brzmieniu:

„1.   WPROWADZENIE

Niniejszy dodatek zawiera wymogi techniczne dotyczące odbiornika GNSS oraz danych GNSS wykorzystywanych przez przyrząd rejestrujący, z uwzględnieniem protokołów, które należy wdrożyć w celu zapewnienia 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:”;

ii)

po pkt 1.1 dodaje się pkt 1.1.1 w brzmieniu:

„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”;

iii)

w pkt 1.2 dodaje się akronimy w brzmieniu:

OSNMA

Galileo Open Service Navigation Message Authentication [uwierzytelnianie komunikatów nawigacyjnych usługi otwartej Galileo]

RTC

Real Time Clock [zegar czasu rzeczywistego]

”;

c)

w pkt 2 wprowadza się następujące zmiany:

i)

nagłówek otrzymuje brzmienie:

„2.

PODSTAWOWA CHARAKTERYSTYKA ODBIORNIKA GNSS”

ii)

pozycja GNS_3 otrzymuje brzmienie:

„GNS_3

Odbiornik GNSS musi być w stanie obsługiwać uwierzytelnianie komunikatów nawigacyjnych w ramach usługi otwartej Galileo (OSNMA).”;

iii)

dodaje się pozycje od GNS_3a do GNS_3g w brzmieniu:

„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 uzyskania 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łączonego 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 szacowaną pozycją,

kontrole pozycji i prędkości, w tym nietypowych wskazań pozycji i prędkości, nagłych skoków i zachowań niezgodnych 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 przekazywane 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 odbiornikó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.

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.”;

d)

pkt 3 otrzymuje brzmienie:

„3.

KOMUNIKATY PODAWANE PRZEZ ODBIORNIK GNSS

W niniejszej sekcji opisano komunikaty wykorzystywane w funkcjonowaniu tachografu inteligentnego do przekazywania komunikatów o standardowej i uwierzytelnionej pozycji. Sekcja ta ma zastosowanie w odniesieniu do konfiguracji tachografu inteligentnego z urządzeniem zewnętrznym GNSS lub bez niego.

GNS_4

Dane o standardowej pozycji opierają się na zalecanych minimalnych danych GNSS (RMC) w komunikacie NMEA, 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 RMC jest następujący (według standardu NMEA V4.11):

Image 103

$--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.

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 wykorzystuje się do określenia stopni. Pozostałe określają minuty kątowe z dokładnością do trzech miejsc po przecinku. Zatem dokładność wynosi 1/1 000 minuty kątowej lub 1/60 000 stopnia (ponieważ jedna minuta to 1/60 stopnia).

GNS_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):

Image 104

$--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

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 uwierzytelnienie 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 rejestrowania 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 nawigacyjnych), 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 informacje o położeniu dotyczące szerokości i długości geograficznej 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 standardem 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.

Image 105

$--GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh

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.

Podobnie VU może wykorzystywać polecenie ASA (dotyczące uwierzytelnionych satelitów czynnych) z komunikatem podobnym do NMEA w celu ustalenia i zarejestrowania gotowości sygnału i dokładności uwierzytelnionych pozycji. Wartości 1–18 są zdefiniowane w standardzie NMEA V4.11.

Image 106

$--ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh

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).”;

e)

w pkt 4 wprowadza się następujące zmiany:

i)

w pkt 4.1.1 w pozycji GNS_9 wprowadza się następujące zmiany:

1)

tekst przed lit. b) zastępuje się tekstem w brzmieniu:

„GNS_9

Urządzenie zewnętrzne GNSS składa się z następujących elementów składowych (zob. rys. 6):

a)

komercyjnego odbiornika GNSS zapewniającego dane o pozycji za pośrednictwem interfejsu danych GNSS. Przykładowo interfejs danych GNSS może być w standardzie 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 komunikató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.”;

2)

lit. c) otrzymuje brzmienie:

„c)

systemu obudowy z funkcją wykrywania manipulowania, obejmującego zarówno odbiornik GNSS, jak i bezpieczny nadajnik-odbiornik GNSS. Funkcja wykrywania manipulowania umożliwia wdrażanie środków bezpieczeństwa zgodnie z wymogami określonymi w profilu zabezpieczenia tachografu inteligentnego.”;

ii)

w pkt 4.2.1 wprowadza się następujące zmiany:

1)

pozycja GNS_14 otrzymuje brzmienie:

„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.”;

2)

po pozycji GNS_18 dodaje się pozycję w brzmieniu:

„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.”;

3)

po pozycji GNS_19 dodaje się pozycję w brzmieniu:

„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.”;

4)

pozycja GNS_20 akapit pierwszy otrzymuje brzmienie:

„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 bezpiecznego nadajnika-odbiornika GNSS decydują producenci.”;

5)

w pozycji GNS_21 tabela 1 otrzymuje brzmienie:

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

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 SensorGNSSSerialNumber.

'07'

8

8

 

Identyfikator systemu operacyjnego bezpiecznego nadajnika-odbiornika GNSS zdefiniowany w dodatku 1 jako SensorOSIdentifier.

'08'

2

2

 

Numer homologacji typu urządzenia zewnętrznego GNSS zdefiniowany w dodatku 1 jako SensorExternalGNSSApprovalNumber.

'09'

16

16

 

Identyfikator elementu zabezpieczenia urządzenia zewnętrznego GNSS zdefiniowany w dodatku 1 jako SensorExternalGNSSSCIdentifier.

'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}

”;

iii)

w pkt 4.2.2 wprowadza się następujące zmiany:

1)

pozycja GNS_22 akapit pierwszy otrzymuje brzmienie:

„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:”;

2)

pozycja GNS_23 otrzymuje brzmienie:

„GNS_23

Co T sekund, gdzie T jest wartością nie większą niż 20, chyba że trwa proces powiązania lub wzajemnego uwierzytelnienia 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 wymogami normy ISO/IEC 7816-4:2013 polecenia SELECT [wybór] i READ RECORD(S) [odczyt rekordu(-ów)] w trybie tylko uwierzytelniania bezpiecznej wymiany komunikatów, jak opisano w dodatku 11 sekcja 11.5, z identyfikatorem 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 przypadku komunikatu ASA.

2.

Dane dotyczące pozycji otrzymane jako ostatnie są przechowywane 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ęstotliwością co najmniej 1 Hz od odbiornika GNSS za pośrednictwem interfejsu danych GNSS.

3.

Bezpieczny nadajnik-odbiornik GNSS wysyła odpowiedź 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 autentyczność i integralność otrzymanej odpowiedzi. W przypadku pozytywnego wyniku dane dotyczące pozycji są przekazywane do procesora VU za pośrednictwem interfejsu 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 ustalenie 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).

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 uwierzytelniania 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.”;

iv)

w pkt 4.2.3 wprowadza się następujące zmiany:

1)

pozycja GNS_26 tiret czwarte i piąte otrzymują brzmienie:

„-

jeżeli nie znaleziono rekordu, bezpieczny nadajnik-odbiornik GNSS zwraca komunikat ‘6A83’,

-

jeżeli urządzenie zewnętrzne GNSS wykryje manipulowanie, zwraca słowa stanu ‘6690’.”;

2)

uchyla się pozycję GNS_27;

v)

dodaje się pkt 4.2.4 i 4.2.5 w brzmieniu:

„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 komunikatów

INS

1

‘D2h’

Zapis rekordu

P1

1

‘XXh’

Numer rekordu ('00' oznacza bieżący rekord)

P2

1

‘04h’

Zapis rekordu o numerze rekordu wskazanym 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 komunikat ‘9000’.

Jeżeli bieżący plik nie jest ukierunkowany na rekord, bezpieczny nadajnik-odbiornik GNSS zwraca komunikat '6981'.

Jeżeli stosuje się polecenie z P1= ‘00’, lecz nie ma żadnego bieżącego pliku elementarnego, bezpieczny 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 manipulowanie, zwraca słowa stanu ’6690’.

4.2.5.

Inne polecenia

GNS_27

Bezpieczny nadajnik-odbiornik GNSS obsługuje następują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 [uwierzytelnianie zewnętrzne]

Dodatek 2 rozdział 3.5.9

General Authenticate [uwierzytelnianie ogólne]

Dodatek 2 rozdział 3.5.10

MSE:SET

Dodatek 2 rozdział 3.5.11

”;

vi)

w pkt 4.4.1 pozycja GNS_28 otrzymuje brzmienie:

„GNS_28

Błąd połączenia z urządzeniem zewnętrznym GNSS zapisuje 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.”;

vii)

w pkt 4.4.2 pozycja GNS_29 otrzymuje brzmienie:

„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 manipulowanie, 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’.”;

(viii)

w pkt 4.4.3 pozycja GNS_30 otrzymuje brzmienie:

„GNS_30

Jeżeli bezpieczny nadajnik-odbiornik GNSS nie otrzymuje danych z odbiornika GNSS, urządzenie to generuje komunikat 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 informacji o pozycji ze zdarzenia odbiornika GNSS, jak określono w wymogu 81 w załączniku IC i dodatku 1 (EventFaultType).”;

ix)

w pkt 4.4.4 wprowadza się następujące zmiany:

1)

pozycja GNS_31 otrzymuje brzmienie:

„GNS_31

Jeżeli VU wykryje, że certyfikat EGF stosowany do wzajemnego uwierzytelniania nie jest już ważny, VU generuje 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 certyfikatu urządzenia zewnętrznego GNSS). VU nadal wykorzystuje otrzymane dane GNSS o pozycji.”;

2)

nagłówek rysunku 4 otrzymuje brzmienie:

Rysunek 6

Schemat urządzenia zewnętrznego GNSS”;

f)

w pkt 5 wprowadza się następujące zmiany:

i)

w pkt 5.1 pozycja GNS_32 otrzymuje brzmienie:

„GNS_32

Na potrzeby przekazywania pozycji, DOP i danych satelitarnych 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 komunikaty RMC, GSA, AMC i ASA. Procesor VU i wewnętrzny odbiornik GNSS mogą ewentualnie wykorzystywać inne formaty danych do wymiany danych zawartych w komunikatach NMEA lub podobnych do NMEA określonych w GNS_4, GNS_4a i GNS_5.”;

ii)

pkt 5.2 otrzymuje brzmienie:

„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 komunikatu 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 dotyczące pozycji nie są dostępne i nie można ich wykorzystać w celu zarejestrowania pozycji pojazdu. Jeżeli nieuwierzytelniona 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.

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).”;

g)

pkt 6 i 7 otrzymują brzmienie:

„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 standardowa 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 standardowa 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 standardowa pozycja nie jest prawidłowa, VU rejestruje uwierzytelnioną pozycję i jej dokładność, a flaga ustawiana jest na »uwierzytelniona«.

d)

Jeżeli standardowa pozycja jest prawidłowa, a uwierzytelniona pozycja nie jest prawidłowa, VU rejestruje standardową 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 standardowej pozycji poziomej, którego promień wynika z zaokrąglenia 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.

HDOP oznacza poziome rozmycie dokładności obliczeń odbiornika GNSS.-

σUERE . HDOP to oszacowanie pierwiastka błędu średniokwadratowego w poziomie.

Image 107

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 pochodzą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).”;

h)

dodaje się pkt 8 w brzmieniu:

„8.

KONFLIKT RUCHU POJAZDU

GNS_42

VU uruchamia i rejestruje zdarzenie konfliktu ruchu pojazdu zgodnie z wymogiem 84 w załączniku IC, w przypadku gdy informacja o ruchu obliczona na podstawie czujnika ruchu jest sprzeczna z informacjami o ruchu obliczonymi 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:

 

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 obejmują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ż uruchamiane, jeżeli spełniony jest następujący warunek:

GnssDistance>[OdometerDifference×OdometerToleranceFactor+Minimum(SlipDistanceUpperlimit;(OdometerDifference×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 uwierzytelnionej, bez uwzględniania wysokości;

OdometerDifference to różnicą między bieżącą wartością licznika kilometrów a wartością licznika kilometró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);

Minimum (SlipDistanceUpperLimit; (OdometerDifference * SlipFactor)) to wartość najmniejsza spośród następujących:

SlipDistanceUpperLimit, która wynosi 10 km (górna granica drogi poślizgu spowodowanej efektami poślizgowymi podczas hamowania)

oraz OdometerDifference * SlipFactor, gdzie SlipFactor wynosi 0,2 (maksymalny wpływ efektów poślizgowych podczas hamowania),

FerryTrainDistance oblicza się jako: FerryTrainDistance =200km/h * tFerryTrain, gdzie tFerryTrain jest sumą czasu trwania (w godzinach) przepraw promowych/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 przeciwnym 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 niezależne źródło ruchu wykrywa ruch przez określony czas. Producent przyrządów rejestrujących określa warunki rejestrowania rozbieżności, jak również okres wykrywania rozbieżności, przy czym rozbieżności te muszą być wykrywane nie później niż w ciągu trzech godzin.”;

38)

dodatek 13 otrzymuje brzmienie:

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 INTERFEJSU 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 dostarczanie 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 zainstalowanej na urządzeniu zewnętrznym;

specyfikacji zabezpieczeń ITS uzupełniających zabezpieczenia zapewniane przez Bluetooth®;

protokołów Bluetooth® wykorzystywanych przez interfejs ITS.

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 nawigacji satelitarnej]

ITS

Intelligent Transport System [inteligentny system transportowy]

OSI

Open Systems Interconnection [połączenie systemów otwartych]

VU

Vehicle Unit [przyrząd rejestrujący]

urządzenie ITS

urządzenie zewnętrzne lub aplikacja zewnętrzna wykorzystują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 przepisy 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średnictwem 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 szyfrowania ani innych mechanizmów zabezpieczenia poza tym, co zapewnia Bluetooth®.

ITS_08

Bluetooth® wykorzystuje model serwer/klient do kontroli transmisji danych między urządzeniami, gdzie VU jest serwerem, a urządzenie ITS klientem.

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.

Image 108

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średnictwem 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średnictwem 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.

Tabela 1

Dostępność interfejsu ITS w zależności od typu karty włożonej do tachografu

Dostępność interfejsu ITS

Szczelina czytnika karty kierowcy

 

Brak karty

Karta kierowcy

Karta kontrolna

Karta warsztatowa

Karta firmowa

Szczelina czytnika karty współkierowcy

Brak karty

niedostępny

dostępny

dostępny

dostępny

dostępny

Karta kierowcy

dostępny

dostępny

dostępny

dostępny

dostępny

Karta kontrolna

dostępny

dostępny

dostępny

niedostępny

niedostępny

Karta warsztatowa

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

Szczelina czytnika karty współkierowcy

Brak karty

niedostępny

Karta kierowcy

Karta kontrolna

Karta warsztatowa

Karta firmowa

Karta kierowcy

Karta kierowcy

Karta kierowcy  (*2)

Karta kontrolna

Karta warsztatowa

Karta firmowa

Karta kontrolna

Karta kontrolna

Karta kontrolna

Karta kontrolna  (*1)

niedostępny

niedostępny

Karta warsztatowa

Karta warsztatowa

Karta warsztatowa

niedostępny

Karta warsztatowa  (*1)

niedostępny

Karta firmowa

Karta firmowa

Karta firmowa

niedostępny

niedostępny

Karta firmowa  (*1)

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średnictwem interfejsu ITS muszą być dodatkowo zgodne z wymogami 12 i 13 w załączniku IC.

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 interfejs ITS. Dodatkowe dane, które nie są wymienione w pkt 4, są klasyfikowane przez producenta VU jako »osobowe« lub »nieosobowe«, 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 wprowadzenia 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 kalibracyjnym, 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 INTERFEJSU ITS ORAZ KLASYFIKACJA DANYCH JAKO OSOBOWE/NIEOSOBOWE

Nazwa danych

Format danych

Źródło

Klasyfikacja danych (osobowe/nieosobowe)

Zgoda na udostępnienie danych

Dostępność

kierowca

współkierowca

VehicleIdentificationNumber

Dodatek 8

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

CalibrationDate

ISO 16844-7

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

TachographVehicleSpeed

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

obowiązkowo

Driver1WorkingState

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

obowiązkowo

Driver2WorkingState

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

obowiązkowo

DriveRecognize

ISO 16844-7

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

Driver1TimeRelatedStates

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

obowiązkowo

Driver2TimeRelatedStates

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

obowiązkowo

DriverCardDriver1

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

obowiązkowo

DriverCardDriver2

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

obowiązkowo

OverSpeed

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

obowiązkowo

TimeDate

Dodatek 8

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

HighResolutionTotalVehicleDistance

ISO 16844-7

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

HighResolutionTripDistance

ISO 16844-7

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

ServiceComponentIdentification

ISO 16844-7

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

ServiceDelayCalendarTimeBased

ISO 16844-7

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

Driver1Identification

ISO 16844-7

karta kierowcy

osobowe

nie dotyczy

zgoda kierowcy

obowiązkowo

Driver2Identification

ISO 16844-7

karta kierowcy

nie dotyczy

osobowe

zgoda współkierowcy

obowiązkowo

NextCalibrationDate

Dodatek 8

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

Driver1ContinuousDrivingTime

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

obowiązkowo

Driver2ContinuousDrivingTime

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

obowiązkowo

Driver1CumulativeBreakTime

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

obowiązkowo

Driver2CumulativeBreakTime

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

obowiązkowo

Driver1CurrentDurationOfSelectedActivity

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

obowiązkowo

Driver2CurrentDurationOfSelectedActivity

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

obowiązkowo

SpeedAuthorised

Dodatek 8

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

TachographCardSlot1

ISO 16844-7

VU

nieosobowe

nie dotyczy

zgoda niewymagana

obowiązkowo

TachographCardSlot2

ISO 16844-7

VU

nie dotyczy

nieosobowe

zgoda niewymagana

obowiązkowo

Driver1Name

ISO 16844-7

karta kierowcy

osobowe

nie dotyczy

zgoda kierowcy

obowiązkowo

Driver2Name

ISO 16844-7

karta kierowcy

nie dotyczy

osobowe

zgoda współkierowcy

obowiązkowo

OutOfScopeCondition

ISO 16844-7

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

ModeOfOperation

ISO 16844-7

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

Driver1CumulatedDrivingTimePreviousAndCurrentWeek

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

obowiązkowo

Driver2CumulatedDrivingTimePreviousAndCurrentWeek

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

obowiązkowo

EngineSpeed

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

RegisteringMemberState

Dodatek 8

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

VehicleRegistrationNumber

Dodatek 8

VU

nieosobowe

nieosobowe

zgoda niewymagana

obowiązkowo

Driver1EndOfLastDailyRestPeriod

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2EndOfLastDailyRestPeriod

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1EndOfLastWeeklyRestPeriod

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2EndOfLastWeeklyRestPeriod

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1EndOfSecondLastWeeklyRestPeriod

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2EndOfSecondLastWeeklyRestPeriod

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1TimeLastLoadUnloadOperation

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2TimeLastLoadUnloadOperation

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1CurrentDailyDrivingTime

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2CurrentDailyDrivingTime

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1CurrentWeeklyDrivingTime

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2CurrentWeeklyDrivingTime

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1TimeLeftUntilNewDailyRestPeriod

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2TimeLeftUntilNewDailyRestPeriod

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1CardExpiryDate

ISO 16844-7

karta kierowcy

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2CardExpiryDate

ISO 16844-7

karta kierowcy

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1CardNextMandatoryDownloadDate

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2CardNextMandatoryDownloadDate

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

TachographNextMandatoryDownloadDate

ISO 16844-7

VU

nieosobowe

nieosobowe

zgoda niewymagana

opcjonalnie

Driver1TimeLeftUntilNewWeeklyRestPeriod

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2TimeLeftUntilNewWeeklyRestPeriod

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1NumberOfTimes9hDailyDrivingTimesExceeded

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2NumberOfTimes9hDailyDrivingTimesExceeded

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1CumulativeUninterruptedRestTime

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2CumulativeUninterruptedRestTime

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1MinimumDailyRest

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2MinimumDailyRest

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1MinimumWeeklyRest

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2MinimumWeeklyRest

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1MaximumDailyPeriod

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2MaximumDailyPeriod

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1MaximumDailyDrivingTime

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2MaximumDailyDrivingTime

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1NumberOfUsedReducedDailyRestPeriods

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2NumberOfUsedReducedDailyRestPeriods

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

Driver1RemainingCurrentDrivingTime

ISO 16844-7

VU

osobowe

nie dotyczy

zgoda kierowcy

opcjonalnie

Driver2RemainingCurrentDrivingTime

ISO 16844-7

VU

nie dotyczy

osobowe

zgoda współkierowcy

opcjonalnie

VehiclePosition

Dodatek 8

VU

osobowe

osobowe

zgoda kierowcy i współkierowcy

obowiązkowo

ByDefaultLoadType

Dodatek 8

VU

osobowe

osobowe

zgoda kierowcy i współkierowcy

obowiązkowo

39)

w dodatku 14 wprowadza się następujące zmiany:

a)

w spisie treści po pkt 5.4.8 dodaje się punkt w brzmieniu:

„5.5

Zarezerwowane dla przyszłego użytku”;

b)

w pkt 4.1.1.5 pozycja DCS_17 otrzymuje brzmienie:

„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 zabezpieczenia”, w celu ich tymczasowego przechowania w DSRC-VU jako aktualną wersję DSRCSecurityData, w formie określonej w sekcji 5.4.4 niniejszego dodatku.”

c)

w pkt 5 wprowadza się następujące zmiany:

i)

w pkt 5.4.4 sekwencja TachographPayload w definicji modułu ASN.1 dla danych DSRC w aplikacji RTM otrzymuje brzmienie:

Image 109

”;

ii)

w pkt 5.4.5 tabela 14.3 otrzymuje brzmienie:

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ść tp15638VehicleRegistrationPlate elementu danych RTM1 na podstawie zarejestrowanej wartości typu danych

VehicleRegistrationIdentification, jak określono w dodatku 1 VehicleRegistrationIdentification

Numer tablicy rejestracyjnej pojazdu wyrażony jako ciąg znaków

tp15638VehicleRegistrationPlate LPN,

--tablica rejestracyjna pojazdu ze strukturą danych według ISO 14906, ale z następują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ń przekroczenia prędkości zarejestrowanych w VU w ciągu ostatnich 10 dni, jak określono w załączniku IC .

1 (PRAWDA): jeżeli ostatnie zdarzenie przekroczenia 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,

RTM3

Prowadzenie pojazdu bez

ważnej karty

VU generuje wartość logiczną

w odniesieniu do elementu danych RTM3

tp15638DrivingWithoutValidCard.

VU przypisuje wartość PRAWDA zmiennej tp15638DrivingWithoutValidCard, jeżeli w VU zarejestrowano co najmniej jedno zdarzenie prowadzenia pojazdu bez odpowiedniej karty w ciągu ostatnich 10 dni, jak określono w załączniku 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.

tp15638DrivingWithoutValidCard

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 szczelinę 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łączniku 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,

RTM7

Konflikt ruchu

pojazdu

VU generuje wartość logiczną

w odniesieniu do elementu danych RTM7.

VU przypisuje wartość PRAWDA zmiennej tp15638VehicleMotionConflict, jeżeli w VU zarejestrowano 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 dotyczą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ółkierowcy;

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ż PROWADZENIE, jak określono w załączniku IC, ustawia wartość RTM9 na PRAWDA.

1 (PRAWDA): inna wybrana

czynność;

0 (FAŁSZ): wybór czynności »prowadzenie«

tp15638CurrentActivityDriving

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 procedurą opisaną w załączniku IC, VU ustawia wartość RTM10 na PRAWDA.

1 (PRAWDA): co najmniej jedna z włożonych 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 niepoprawnego zamknięcia ostatniej sesji karty.

tp15638LastSessionClosed

BOOLEAN

RTM11

Przerwa w zasilaniu

 

VU generuje wartość w postaci

liczby całkowitej w odniesieniu do elementu danych RTM11.

VU przypisuje zmiennej tp15638PowerSupplyInterruption wartość odpowiadają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.

tp15638PowerSupplyInterruption

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ą odbiornika GNSS (wewnętrznego 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 ostatnich 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.

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 ostatnich 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.

--usterka czujnika jeden oktet zgodnie ze słownikiem danych

tp15638SensorFault INTEGER (0..255),

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 zdefiniowanego w załączniku IC.

VU ustala wartość czasu, w którym doszło do ostatniego zarejestrowanego przez VU zdarzenia związanego z próbą naruszenia zabezpieczenia.

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 ostatniego zarejestrowanego zdarzenia związanego z próbą naruszenia zabezpieczenia.

tp15638LatestBreachAttempt

INTEGER(0..4294967295),

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 kalibracji 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 najnowszego 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),

RTM18

Prędkość bieżąca

VU generuje wartość w postaci

liczby całkowitej w odniesieniu do elementu danych RTM18.

VU ustala wartość RTM18 na wartość ostatniej zarejestrowanej 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 TachographPayload

tp15638Timestamp

INTEGER(0..4294967295),

RTM20

Czas, kiedy była dostępna ostatnia uwierzytelniona 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 uwierzytelniona 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

tp15638LatestAuthenticatedPosition

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ę, zakodowany jako liczba całkowita.

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.

tp15638ContinuousDrivingTime INTEGER(0..255),

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 dziennych okresów prowadzenia pojazdu przez kierowcę, tj. na trwającą lub poprzednią zmianę RTM.

Dzienny czas prowadzenia 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 prowadzenia 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 prowadzenia 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 prowadzenia 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.

tp15638DailyDrivingTimeWeek INTEGER(0..255),

RTM24

Tygodniowy czas prowadzenia 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 prowadzenia pojazdu przez kierowcę.

Tygodniowy czas prowadzenia pojazdu przez kierowcę, zakodowany jako liczba całkowita.

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),

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ę, zakodowany jako liczba całkowita.

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.

tp15638FortnightlyDrivingTime INTEGER(0..255),

Uwaga: RTM22, RTM23, RTM24 i RTM25 oblicza się zgodnie z addendum do niniejszego dodatku.”;

iii)

w pkt 5.4.7 tabela 14.9 otrzymuje brzmienie:

Tabela 14.9

Inicjacja – przykładowa zawartość ramki VST

Oktet #

Atrybut/Pole

Bity w oktecie

Opis

1

FLAG

0111 1110

Flaga początkowa

2

Private LID

xxxx xxxx

Adres łącza określonego DSRC-VU

3

 

xxxx xxxx

4

 

xxxx xxxx

5

 

xxxx xxxx

6

MAC Control field

1100 0000

Polecenie PDU

7

LLC Control field

0000 0011

Polecenie interfejsu użytkownika

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. Przykładowy profil 0

Brak rozszerzenia, 1 aplikacja

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.

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 dotyczących wersji oprogramowania/sprzętu interfejsu 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

”;

iv)

dodaje się pkt 5.5 w brzmieniu:

„5.5

Zarezerwowane dla przyszłego użytku”;

v)

w pkt 5.7 pozycje DSC_77 i DSC_78 otrzymują brzmienie:

„DSC_77

Już zabezpieczone Dane są przekazywane DSRC-VU za pomocą funkcji VUSM . VUSM sprawdza, czy dane zarejestrowane 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 EventFaultType z wartością enum ustawioną na ‘0C’H Błąd łączności z urządzeniem do łączności na odległość wraz ze znacznikiem czasu. VUSM sprawdza, czy dane zostały z powodzeniem przesłane do DSRC-VU.

DSC_78

Zarezerwowane dla przyszłego użytku”;

d)

dodaje się addendum w brzmieniu;

„Addendum

Zasady obliczania dziennego, tygodniowego i dwutygodniowego czasu prowadzenia pojazdu

1.   

Podstawowe zasady dokonywania obliczeń

VU oblicza dzienny czas prowadzenia pojazdu, tygodniowy czas prowadzenia pojazdu i dwutygodniowy czas prowadzenia pojazdu z wykorzystaniem odpowiednich 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 prowadzenia 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;

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 odpoczynku, okresy te uznaje się za dzienne okresy odpoczynku;

h)

»regularny dzienny okres odpoczynku« oznacza nieprzerwany okres odpoczynku 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ć przerwany 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 przyrzą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.

Image 110

i)

»skrócony dzienny okres odpoczynku« oznacza nieprzerwany okres odpoczynku 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 przerwać jeden raz bądź dwa razy lub

drugą część dzielonego dziennego okresu odpoczynku można przerwać jeden raz bądź dwa razy lub

pierwszą część dzielonego dziennego okresu odpoczynku można przerwać jeden raz i drugą część dzielonego dziennego okresu odpoczynku można przerwać jeden raz.

VU zlicza następnie dzielony dzienny okres odpoczynku, gdy skumulowany 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 odpoczynku, jeżeli pierwszy okres odpoczynku nie został przerwany przez PRZEPRAWĘ PROMOWĄ/POCIĄGOWĄ.

Image 111

W przypadku dzielonego dziennego okresu odpoczynku przyrzą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 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 aktywacją flagi PRZEPRAWA PROMOWA/POCIĄGOWA (POCZĄTEK), zgodnie z rys. 3 i w stosownych przypadkach rys. 4, oraz ocenia w odniesieniu 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 przeprawą 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.

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 PRZEPRAWA 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 odpoczynku. 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 odpoczynku dodane do pierwszej części dzielonego dziennego okresu odpoczynku 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 stosownych przypadkach rys. 4.

W odniesieniu do każdej wykrytej przerwy VU ocenia, czy przerwa powoduje, ż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ępują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ą.

Image 112

Image 113

Image 114

Image 115

Image 116

Image 117

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 prowadzenia 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.

40)

w dodatku 15 wprowadza się następujące zmiany:

a)

nagłówek otrzymuje brzmienie:

„Dodatek 15

MIGRACJA: ZARZĄDZANIE WSPÓŁISTNIENIEM GENERACJI URZĄDZEŃ

b)

w spisie treści wprowadza się następujące zmiany:

i)

pkt 2.2 otrzymuje brzmienie:

„2.2.

Interoperacyjność między VU a kartami”;

ii)

dodaje się pkt 5 w brzmieniu:

„5.

REJESTROWANIE PRZEKROCZEŃ GRANICY W TACHOGRAFACH PIERWSZEJ GENERACJI I PIERWSZEJ WERSJI DRUGIEJ GENERACJI”;

c)

pkt 2–4 otrzymują brzmienie:

„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.

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ć korzystanie 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ą interoperacyjne z przyrządami rejestrującymi pierwszej generacji (zgodnie z załącznikiem 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łącznikiem 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 rejestrującej tej funkcji, tak aby karty do tachografu pierwszej generacji 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ą przedstawione 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.

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ół pobierania 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 warsztatowych) 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 rejestrują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.

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 pierwszej 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 zastosowaniem protokołu kalibracyjnego danej generacji lub wersji. Urządzenia do kalibracji mogą być kompatybilne ze wszystkimi 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 tachografów i czujników ruchu stosuje się te same klucze i certyfikaty, co w przypadku urządzeń wersji 1 generacji 2.

MIG_020

Państwa członkowskie muszą być w stanie rozpocząć wydawanie 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ąć wydawanie 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 nieprawidłowo działających elementów składowych.

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 rejestrują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, posiadających już homologację typu.”

d)

dodaje się pkt 5 w brzmieniu:

„5.

REJESTROWANIE PRZEKROCZEŃ GRANICY W TACHOGRAFACH PIERWSZEJ GENERACJI I PIERWSZEJ WERSJI DRUGIEJ GENERACJI

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 rozporządzenia (UE) nr 165/2014 oraz wymogu 50 w załączniku IB do rozporządzenia (EWG) nr 3821/85.”;

41)

w dodatku 16 pozycja ADA_012 otrzymuje brzmienie:

„ADA_012

Interfejs wejściowy adaptera musi w stosownych przypadkach mnożyć lub dzielić częstotliwość impulsów wejściowych prędkoś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 zatwierdzony warsztat instalujący adapter.”.


(1)  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).

(*1)  Połączenie ITS Bluetooth® przypisuje się karcie do tachografu w szczelinie czytnika karty kierowcy VU.

(*2)  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).


Top