ZAŁĄCZNIK I

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

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

a)	punkt 3.12.5. otrzymuje brzmienie: „3.12.5. Miejsca i pozycje, w których zaczynają się i kończą dzienne okresy pracy lub w których osiągnięto 3 godziny skumulowanego czasu prowadzenia pojazdu”;

b)	pkt 4.5.3.2.16 otrzymuje brzmienie: „4.5.3.2.16 Dane miejsc, w których minęły trzy godziny skumulowanego czasu prowadzenia pojazdu”;

c)	pkt 4.5.4.2.14 otrzymuje brzmienie: „4.5.4.2.14 Dane miejsc, w których minęły trzy godziny skumulowanego czasu prowadzenia pojazdu”;

d)	pkt 6.2 otrzymuje brzmienie: „6.2. Kontrola techniczna elementów składowych nowych i po naprawie”;

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

definicja ll) otrzymuje brzmienie:

„ll)	»urządzenie do łączności 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;”;

definicja tt) otrzymuje brzmienie:

„tt)	»korekta czasu« oznacza: korektę bieżącego czasu; może ona być automatyczna w regularnych odstępach z wykorzystaniem czasu podawanego przez odbiornik GNSS jako odniesienia lub wykonywana w trybie kalibracyjnym;”;

tiret pierwsze definicji yy) otrzymuje brzmienie:

„—	które jest zainstalowane i stosowane wyłącznie w pojazdach kategorii M1 i N1 (określonych w załączniku II do dyrektywy 2007/46/WE Parlamentu Europejskiego i Rady (*) z późniejszymi zmianami),”;

dodaje się nową definicję fff):

„(fff)

»skumulowany czas prowadzenia pojazdu« oznacza:

wartość odpowiadającą łącznej skumulowanej liczbie minut prowadzenia danego pojazdu.

Wartość skumulowanego czasu prowadzenia pojazdu to nieprzerwana liczba wszystkich minut uznanych przez funkcję monitorowania czynności prowadzenia pojazdu urządzenia rejestrującego za PROWADZENIE POJAZDU i jest wykorzystywana wyłącznie do uruchomienia rejestracji pozycji pojazdu za każdym razem, gdy upłynie wielokrotność trzech godzin skumulowanego czasu prowadzenia pojazdu. Skumulowany czas zaczyna biec w momencie uruchomienia urządzenia rejestrującego. Nie mają na niego wpływu jakiekolwiek inne warunki, np. poza zakresem lub przeprawa promowa/przejazd kolejowy.

Nie przewiduje się wyświetlania, drukowania lub pobierania skumulowanego czasu prowadzenia pojazdu;”;

pkt 2.3 ppkt 13 akapit ostatni otrzymuje brzmienie:

„—	normalny okres ważności operacji przyrządów rejestrujących wynosi 15 lat, począwszy od daty wejścia w życie świadectwa przyrządu rejestrującego, ale przyrządy rejestrujące mogą być wykorzystywane przez kolejne 3 miesiące wyłącznie do pobierania danych.”;

pkt 2.4 akapit pierwszy otrzymuje brzmienie:

„Celem zabezpieczenia systemu jest taka ochrona pamięci danych, by uniemożliwić nieautoryzowany dostęp i manipulowanie danymi oraz wykrycie wszelkich takich prób, ochrona integralności i autentyczności danych wymienianych między czujnikiem ruchu a przyrządem rejestrującym, ochrona integralności i autentyczności danych wymienianych między urządzeniem rejestrującym a kartami do tachografów, ochrona integralności i autentyczności danych wymienianych między przyrządem rejestrującym a ewentualnym urządzeniem zewnętrznym GNSS, ochrona poufności, integralności i autentyczności danych wymienianych w ramach wczesnego wykrywania na odległość na potrzeby kontroli oraz sprawdzenie integralności i autentyczności pobieranych danych.”;

w pkt 3.2 ppkt 27 tiret drugie otrzymuje brzmienie:

„—	pozycji, w których skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech godzin;”;

w pkt 3.4 ppkt 49 otrzymuje brzmienie:

„49)	Jeżeli w czasie 120 sekund od automatycznej zmiany na PRACĘ, wskutek zatrzymania pojazdu, nastąpi zmiana czynności na PRZERWA/ODPOCZYNEK lub GOTOWOŚĆ, przyjmuje się, że pierwsza taka zmiana zaistniała w czasie postoju pojazdu (w ten sposób można anulować zmianę czynności na PRACA).”;

w pkt 3.6.1 ppkt 59 otrzymuje brzmienie:

„59)

Kierowca wprowadza wówczas bieżące miejsce pojazdu, a wpis ten uznaje się za tymczasowy.

W poniższych warunkach wpis tymczasowy wykonany przy ostatnim wyjęciu karty zostaje zatwierdzony (tj. nie będzie go już można nadpisać):

—	wpis miejsca, w którym rozpoczyna się obecny dzienny okres pracy, w trakcie ręcznego wprowadzania zgodnie z wymogiem 61;

—	następny wpis miejsca, w którym rozpoczyna się obecny dzienny okres pracy, jeśli posiadacz karty nie wpisze żadnego miejsca rozpoczęcia lub zakończenia okresu pracy w trakcie ręcznego wprowadzania zgodnie z 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 zakończenia obecnego dziennego okresu pracy, jeśli posiadacz karty nie wpisze żadnego miejsca rozpoczęcia lub zakończenia okresu pracy w trakcie ręcznego wprowadzania zgodnie z wymogiem 61.”;

w pkt 3.6.2 tiret szóste i siódme otrzymują brzmienie:

„—	miejsca, w którym zakończył się poprzedni dzienny okres pracy powiązany z odnośnym czasem (czyli nadpisania i zatwierdzenia wpisu przy ostatnim wyjęciu karty),

—	miejsca, w którym rozpoczyna się obecny dzienny okres pracy powiązany z odnośnym czasem (czyli zatwierdzenia wpisu tymczasowego przy ostatnim wyjęciu karty).”;

pkt 3.9.15 otrzymuje brzmienie:

„3.9.15 Zdarzenie »,konflikt czasu«

86)

Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się, jeżeli przyrząd rejestrujący wykryje rozbieżność większą niż 1 min. między czasem określonym przez funkcję pomiaru czasu w przyrządzie rejestrującym a czasem pochodzącym z odbiornika GNSS. Zdarzenie to jest rejestrowane wraz z wartością wyświetlaną na wewnętrznym zegarze przyrządu rejestrującego i wiąże się z automatyczną korektą czasu. Po uruchomieniu zdarzenia konfliktu czasu przyrząd rejestrujący nie generuje innych zdarzeń konfliktu czasu przez kolejnych 12 godzin. Zdarzenie nie zostanie wywołane w przypadkach, w których odbiornik GNSS nie mógł wykryć prawidłowego sygnału GNSS przez co najmniej 30 dni.”;

10)

w pkt 3.9.17 dodaje się tiret w brzmieniu:

„—	usterka interfejsu ITS (w stosownych przypadkach).”;

11)

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

(i)	tekst przed tabelą w pkt 89 otrzymuje brzmienie: „Urządzenie rejestrujące wykrywa usterki, wykonując autotesty i testy wbudowane, zgodnie z poniższą tabelą:”;

(ii)

w tabeli dodaje się wiersz w brzmieniu:

„Interfejs ITS (fakultatywnie)

Prawidłowa praca”

12)

w pkt 3.12 tiret drugie otrzymuje brzmienie:

„—

średnia liczba pozycji na dzień jest definiowana jako co najmniej 6 pozycji, w których rozpoczyna się dzienny okres pracy, 6 pozycji, w których skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin, oraz 6 pozycji, w których kończy się dzienny okres pracy, tak więc »365 dni« obejmuje co najmniej 6570 pozycji,”;

13)

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

nagłówek i pkt 108 otrzymują brzmienie:

„3.12.5. Miejsca i pozycje, w których zaczynają się i kończą dzienne okresy pracy lub w których osiągnięto 3 godziny skumulowanego czasu prowadzenia pojazdu”;

108)

Urządzenie rejestrujące rejestruje i przechowuje w pamięci następujące dane:

—	miejsca i pozycje, w których kierowca lub współkierowca rozpoczynają dzienny okres pracy;

—	pozycje, w których skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech godzin;

—	miejsca i pozycje, w których kierowca lub współkierowca kończą dzienny okres pracy.”;

w pkt 110 tiret czwarte otrzymuje brzmienie:

„—	rodzaj wpisu (rozpoczęcie, zakończenie lub 3 godziny skumulowanego czasu prowadzenia pojazdu),”;

pkt 111 otrzymuje brzmienie:

„111)

Pamięć danych wystarcza do przechowywania miejsc i pozycji, w których zaczynają się i kończą dzienne okresy pracy lub w których osiągnięto 3 godziny skumulowanego czasu prowadzenia pojazdu, przez co najmniej 365 dni.”;

14)

w pkt 3.12.7 ppkt 116 otrzymuje brzmienie:

„116)

Urządzenie rejestrujące rejestruje i przechowuje w pamięci danych prędkość chwilową pojazdu wraz z datą i godziną, rejestrowane co sekundę przez okres co najmniej ostatnich 24 godzin, w których pojazd był w ruchu.”;

15)

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

między zdarzenia „Brak informacji o pozycji z odbiornika GNSS” i „Błąd danych dotyczących ruchu” dodaje się zdarzenie w brzmieniu:

„Błąd połączenia z urządzeniem zewnętrznym GNSS

—	najdłuższe zdarzenie 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 pod koniec zdarzenia

—	liczba podobnych zdarzeń w tym dniu”

zdarzenie „Konflikt czasu” otrzymuje brzmienie:

„Konflikt czasu

—	najpoważniejsze zdarzenie w każdym z 10 ostatnich dni ich występowania (tj. zdarzenia z największymi różnicami pomiędzy datą i godziną z urządzenia rejestrującego a datą i godziną z GNSS),

—	5 najpoważniejszych zdarzeń w ciągu ostatnich 365 dni

—	data i godzina z urządzenia rejestrującego

—	data i godzina z GNSS

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

—	liczba podobnych zdarzeń w tym dniu”

16)

w pkt 3.20 ppkt 200 otrzymuje brzmienie:

„200)

Urządzenie rejestrujące może być również wyposażone w znormalizowane interfejsy pozwalające na wykorzystywanie przez urządzenie zewnętrzne danych rejestrowanych lub generowanych przez tachograf w trybie operacyjnym lub kalibracyjnym.

W dodatku 13 określono i podano normę dla opcjonalnego interfejsu ITS. Inne podobne interfejsy przyrządu rejestrującego mogą współistnieć, pod warunkiem że są w pełni zgodne z wymogami określonymi w dodatku 13 w odniesieniu do minimalnego wykazu danych, zabezpieczeń i zgody kierowcy.

Zgoda kierowcy nie ma zastosowania do danych przekazywanych przez urządzenie rejestrujące do sieci pojazdu. W przypadku gdy dane osobowe wprowadzone do sieci pojazdu są dalej przetwarzane poza siecią pojazdu, producent pojazdu jest zobowiązany do zapewnienia zgodności procedury przetwarzania danych osobowych z rozporządzeniem (UE) 2016/679 (»ogólne rozporządzenie o ochronie danych«).

Zgoda kierowcy nie ma zastosowania do danych z tachografu pobranych zdalnie przez firmę (wymóg 193), ponieważ taka sytuacja jest monitorowana przez prawo dostępu karty firmowej.

Następujące wymagania mają zastosowanie do danych ITS udostępnianych za pośrednictwem tego interfejsu:

—	dane te stanowią zbiór wybranych istniejących danych ze słownika danych tachografu (dodatek 1),

—	podzbiór tych wybranych danych jest oznaczony jako »dane osobowe«,

—	podzbiór »danych osobowych« jest dostępny jedynie w przypadku, gdy włączona jest opcja podlegającej weryfikacji zgody kierowcy na wyprowadzenie jego danych osobowych z sieci pojazdu,

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

—	zbiór i podzbiór danych są przekazywane za pośrednictwem protokołu bezprzewodowego Bluetooth w promieniu kabiny pojazdu, z częstotliwością odświeżania co 1 minutę,

—	sparowanie urządzenia zewnętrznego z interfejsem ITS jest zabezpieczone dedykowanym losowym kodem PIN składającym się z co najmniej 4 cyfr, zapisywanym i dostępnym przez wyświetlacz każdego przyrządu rejestrującego,

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

Można wyprowadzać również inne dane oprócz zbioru wybranych istniejących danych, uznawanych za wykaz minimalny, pod warunkiem że nie można ich uważać za dane osobowe.

Urządzenie rejestrujące musi posiadać zdolność do podawania statusu zgody kierowcy innym platformom w sieci pojazdu.

Przy włączonym zapłonie pojazdu dane te udostępniane są nieprzerwanie.”;

17)

w pkt 3.23 ppkt 211 otrzymuje brzmienie:

„211)

Ustawienia czasu zegara wewnętrznego przyrządu rejestrującego są automatycznie korygowane co 12 godzin. Jeżeli korekta nie jest możliwa, ponieważ sygnał GNSS nie jest dostępny, ustawienie czasu wprowadza się, jak tylko przyrząd rejestrujący uzyska dostęp do prawidłowego czasu z odbiornika GNSS, zależnie od stanu włączenia zapłonu pojazdu. Czasem odniesienia dla automatycznego ustawienia wewnętrznego zegara przyrządu rejestrującego jest czas pobrany z odbiornika GNSS.”;

18)

w pkt 3.26 ppkt 225 i 226 otrzymują brzmienie:

„225)

Do każdego odrębnego elementu składowego urządzenia rejestrującego jest przymocowana tabliczka zawierająca następujące informacje:

—	nazwa i adres producenta,

—	numer części producenta i rok produkcji,

—	numer seryjny,

—	znak homologacji typu.

226)	Jeżeli dostępna powierzchnia nie wystarcza do umieszczenia wszystkich powyższych informacji, na tabliczce umieszcza się przynajmniej: nazwę producenta lub jego logo i numer części.”;

19)	w pkt 4.1 rysunek odpowiadający awersowi i rewersowi karty kierowcy zastępuje się następującym rysunkiem: „ Tekst z obrazka „ ” ”

20)

w pkt 4.5.3.1.8 ppkt 263 tiret pierwsze otrzymuje brzmienie:

„—	usterka karty (w przypadku gdy dana karta jest przedmiotem usterki),”;

21)

w pkt 4.5.3.2.8 ppkt 288 tiret pierwsze otrzymuje brzmienie:

„—	usterka karty (w przypadku gdy dana karta jest przedmiotem usterki),”;

22)

pkt 4.5.3.2.16 otrzymuje brzmienie:

„4.5.3.2.16 Dane miejsc, w których minęły trzy godziny skumulowanego czasu prowadzenia pojazdu

305)

Karta kierowcy umożliwia przechowywanie następujących danych dotyczących pozycji pojazdu, w których skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin:

—	data i godzina, o której skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin,

—	pozycja pojazdu,

—	dokładność GNSS, data i godzina określenia pozycji,

—	stan licznika kilometrów.

306)

Karta kierowcy umożliwia przechowywanie co najmniej 252 takich rekordów danych.”;

23)

pkt 4.5.4.2.14 otrzymuje brzmienie:

„4.5.4.2.14 Dane miejsc, w których minęły trzy godziny skumulowanego czasu prowadzenia pojazdu

353)

Karta warsztatowa umożliwia przechowywanie następujących danych dotyczących pozycji pojazdu, w których skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin:

—	data i godzina, o której skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin,

—	pozycja pojazdu,

—	dokładność GNSS, data i godzina określenia pozycji,

—	stan licznika kilometrów.

354)

Karta warsztatowa umożliwia przechowywanie co najmniej 18 takich rekordów danych.”;

24)

w pkt 5.2 ppkt 396 otrzymuje brzmienie:

„396)

Tabliczka zawiera co najmniej następujące dane:

—	nazwa, adres lub nazwa handlowa zatwierdzonego instalatora lub warsztatu,

—	współczynnik charakterystyczny pojazdu, w postaci »w = …imp/km«,

—	stała urządzenia rejestrującego, w postaci »k = …imp/km«,

—	obwód toczny opon, w postaci „l = …mm”,

—	rozmiar opon,

—	data pomiaru współczynnika charakterystycznego pojazdu i obwodu tocznego opon,

—	numer identyfikacyjny pojazdu,

—	obecność (lub brak) urządzenia zewnętrznego GNSS,

—	numer seryjny urządzenia zewnętrznego GNSS, w stosownych przypadkach,

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

—	numer seryjny wszystkich założonych plomb,

—	część pojazdu, w której zamontowany jest ewentualny adapter,

—	część pojazdu, w której zamontowany jest czujnik ruchu, jeżeli nie jest podłączony do skrzyni biegów lub w przypadku niezastosowania adaptera,

—	kolor przewodu łączącego adapter z częścią pojazdu, z której dochodzą impulsy,

—	numer seryjny czujnika ruchu wbudowanego w adapter.”;

25)

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

po ppkt 398 dodaje się nowy ppkt 398a w brzmieniu:

„398a

Plomby, o których mowa powyżej, muszą być certyfikowane zgodnie z normą EN 16882:2016.”;

w ppkt 401 akapit drugi otrzymuje brzmienie:

„Ten niepowtarzalny numer identyfikacyjny jest określony w następujący sposób: MMNNNNNNNN w formie niedającego się usunąć oznakowania, gdzie MM to jednoznaczny identyfikator producenta (numer w bazie danych prowadzonej przez KE), a NNNNNNNN to numer alfanumeryczny plomby, niepowtarzalny dla danego producenta.”;

ppkt 403 otrzymuje brzmienie:

„403)

Producenci plomb muszą być zarejestrowani w specjalnej bazie danych, gdy otrzymują model plomby certyfikowany zgodnie z normą EN 16882:2016, i muszą udostępniać publicznie numery identyfikacyjne plomb w procedurze, którą ma określić Komisja Europejska.”;

ppkt 404 otrzymuje brzmienie:

„404)

Zatwierdzone warsztaty i producenci pojazdów korzystają, w ramach rozporządzenia (UE) nr 165/2014, wyłącznie z plomb certyfikowanych zgodnie z normą EN 16882:2016 od producentów plomb zapisanych w bazie danych, o której mowa powyżej.”;

26)

pkt 6.2 otrzymuje brzmienie:

„6.2. Kontrola techniczna elementów składowych nowych lub po naprawie

407)

Każdy przyrząd, tak nowy, jak i po naprawie, jest kontrolowany pod względem prawidłowego funkcjonowania oraz dokładności odczytów i rejestracji, w granicach określonych w rozdziałach 3.2.1, 3.2.2, 3.2.3 oraz 3.3.”;

27)

w pkt 6.3 ppkt 408 otrzymuje brzmienie:

„408)

Po zainstalowaniu w pojeździe cała instalacja (włącznie z urządzeniem rejestrującym) musi być zgodna z przepisami dotyczącymi maksymalnych tolerancji ustanowionymi w rozdziałach 3.2.1, 3.2.2, 3.2.3 i 3.3. Cała instalacja musi być zaplombowana zgodnie z rozdziałem 5.3 i musi obejmować kalibrację.”;

28)

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

w pkt 8.1 tekst wprowadzający przed ppkt 425 otrzymuje brzmienie:

„Do celów niniejszego rozdziału wyrażenie »urządzenie rejestrujące« oznacza »urządzenie rejestrujące lub jego elementy składowe«. Homologacji typu nie wymaga się dla przewodu(-ów) łączącego(-ych) czujnik ruchu z przyrządem rejestrującym, urządzenie zewnętrzne GNSS z przyrządem rejestrującym lub zewnętrzne urządzenie do łączności na odległość z przyrządem rejestrującym. Papier używany przez urządzenie rejestrujące uważa się za element składowy urządzenia rejestrującego.

Każdy producent może zwrócić się o homologację typu elementów składowych urządzenia rejestrującego z wszelkimi innymi elementami składowymi urządzenia rejestrującego, pod warunkiem że każdy element składowy jest zgodny z wymogami niniejszego załącznika. Producenci mogą również zwrócić się o homologację typu urządzenia rejestrującego.

Jak opisano w definicji 10 w art. 2 niniejszego rozporządzenia, przyrządy rejestrujące mają różne warianty zespołów elementów składowych. Bez względu na wariant zespołu elementów składowych przyrządu rejestrującego, antena zewnętrzna i rozdzielacz antenowy podłączony do odbiornika GNSS lub do urządzenia do łączności na odległość nie stanowią części homologacji typu przyrządu rejestrującego.

Niemniej jednak po uzyskaniu homologacji typu urządzenia rejestrującego producenci prowadzą powszechnie dostępny wykaz anten i rozdzielaczy kompatybilnych z każdym homologowanym przyrządem rejestrującym, urządzeniem zewnętrznym GNSS i zewnętrznym urządzeniem do łączności na odległość.”;

ppkt 427 otrzymuje brzmienie:

„427)

Organy homologacji typu w państwach członkowskich nie wydają świadectwa homologacji typu, dopóki nie otrzymają:

—	świadectwa bezpieczeństwa (jeżeli jest ono wymagane na podstawie niniejszego załącznika),

—	świadectwa funkcjonalności,

—	świadectwa interoperacyjności (jeżeli jest ono wymagane na podstawie niniejszego załącznika),

dla urządzenia rejestrującego lub kart do tachografów, dla których złożono wniosek o homologację typu.”;

29)

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

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

(i)	pkt 2.63 otrzymuje brzmienie: „2.63. Zarezerwowany dla przyszłego użytku.”;

(ii)	pkt 2.78 otrzymuje brzmienie: „2.78. GNSSAccumulatedDriving”;

(iii)

pkt 2.79 otrzymuje brzmienie:

„2.79. GNSSAccumulatedDrivingRecord”;

(iv)	pkt 2.111 otrzymuje brzmienie: „2.111. NoOfGNSSADRecords”;

(v)	pkt 2.160 otrzymuje brzmienie: „2.160. Zarezerwowany dla przyszłego użytku.”;

(vi)	pkt 2.203 otrzymuje brzmienie: „2.203. VuGNSSADRecord”;

(vii)

pkt 2.204 otrzymuje brzmienie:

„2.204. VuGNSSADRecordArray”;

(viii)

pkt 2.230 otrzymuje brzmienie:

„2.230. Zarezerwowany dla przyszłego użytku.”;

(ix)	pkt 2.231 otrzymuje brzmienie: „2.231. Zarezerwowany dla przyszłego użytku.”;

w pkt 2 dodaje się przed pkt 2.1 tekst w brzmieniu:

„W przypadku typów danych karty używanych do aplikacji generacji 1 i generacji 2, wielkość określona w niniejszym dodatku to wielkość dla aplikacji generacji 2. Wielkość dla aplikacji generacji 1 powinna być już znana dla czytnika. Numery wymogów dotyczących takich typów danych określone w załączniku IC obejmują zarówno aplikacje generacji 1, jak i generacji 2.”;

pkt 2.19 otrzymuje brzmienie:

„2.19. CardEventData

Generacja 1:

Informacje przechowywane na karcie kierowcy lub warsztatowej dotyczące zdarzeń związanych z posiadaczem karty (wymagania 260 i 318 określone w załączniku IC).

Tekst z obrazka

CardEventData jest sekwencją uporządkowaną w kolejności rosnącej typu EventFaultType, w zapisach cardEventRecords (z wyjątkiem rekordów związanych z próbami naruszenia zabezpieczeń, które gromadzone są w ostatnim zbiorze sekwencji).

cardEventRecords jest zbiorem rekordów ze zdarzeniami dla danego typu zdarzenia (lub kategorii prób naruszeń zabezpieczenia).

Generacja 2:

Informacje przechowywane na karcie kierowcy lub warsztatowej dotyczące zdarzeń związanych z posiadaczem karty (wymagania 285 i 341 określone w załączniku IC).

Tekst z obrazka

cardEventRecords jest zbiorem rekordów ze zdarzeniami dla danego typu zdarzenia (lub kategorii prób naruszeń zabezpieczenia).”

pkt 2.30 otrzymuje brzmienie:

„2.30. CardRenewalIndex

Numer odnowienia karty (definicja i)).

Tekst z obrazka

Przypisanie wartości: (zob. rozdział 7 niniejszego załącznika).

»0«	Wydanie pierwsze.

Kolejność zwiększania:»0, …, 9, A, …, Z « ”;

w pkt 2.61 tekst po nagłówku „Generacja 2” otrzymuje brzmienie:

„

Tekst z obrazka

Oprócz generacji 1 używane są następujące elementy danych:

noOfGNSSADRecords jest liczbą rekordów skumulowanego czasu prowadzenia pojazdu z GNSS, które mogą być zapisane na karcie.

noOfSpecificConditionRecords jest liczbą rekordów warunków szczególnych, które mogą być zapisane na karcie.

noOfCardVehicleUnitRecords jest liczbą rekordów używanych przyrządów rejestrujących, które mogą być zapisane na karcie.”;

f)	pkt 2.63 otrzymuje brzmienie: „2.63. Zarezerwowany dla przyszłego użytku.”;

w pkt 2.67 tekst pod nagłówkiem „Generacja 2” otrzymuje brzmienie:

„Takie same wartości jak w przypadku generacji 1 z następującymi uzupełnieniami:

Tekst z obrazka

Uwaga 1:

Wartości generacji 2 dla tabliczki, adaptera, połączenia zewnętrznego GNSS, a także wartości generacji 1 dla przyrządu rejestrującego oraz czujnika ruchu mogą być, w stosownych przypadkach, używane w SealRecord.

Uwaga 2:

W polu CardHolderAuthorisation (CHA) świadectwa generacji 2, wartości (1), (2) i (6) należy interpretować jako wskazujące na świadectwo wzajemnego uwierzytelnienia dla danego typu urządzenia. W celu wskazania danego certyfikatu na potrzeby podpisu cyfrowego należy użyć wartości (17), (18) lub (19).”;

w pkt 2.70 tekst pod nagłówkiem „Generacja 2” otrzymuje brzmienie:

„Generacja 2:

zdarzenia ogólne,

brak dalszych szczegółów,

włożenie nieważnej karty,

konflikt kart,

nakładające się czasy,

prowadzenie pojazdu bez prawidłowej karty,

włożenie karty podczas prowadzenia pojazdu,

sesja ostatniej karty niezamknięta prawidłowo,

przekroczenie prędkości,

przerwa w zasilaniu,

błąd danych dotyczących ruchu,

konflikt ruchu pojazdu,

konflikt czasowy (między GNSS a wewnętrznym zegarem VU),

błąd połączenia z urządzeniem do łączności na odległość,

brak informacji o pozycji z odbiornika GNSS,

błąd połączenia z urządzeniem zewnętrznym GNSS,

RFU,

zdarzenia związane z próbami naruszenia zabezpieczenia przyrządu rejestrującego,

brak dalszych szczegółów,

błąd uwierzytelnienia czujnika ruchu,

błąd uwierzytelnienia kart do tachografów,

nieupoważniona zmiana w czujniku ruchu,

błąd integralności wprowadzania danych na kartę

błąd integralności przechowywanych danych użytkownika,

błąd wewnętrznego przesyłania danych,

nieupoważnione otwarcie obudowy,

uszkodzenie sprzętu,

wykrycie ingerencji w GNSS,

błąd uwierzytelnienia urządzenia zewnętrznego GNSS,

wygaśnięcie certyfikatu urządzenia zewnętrznego GNSS,

RFU,

zdarzenia związane z próbami naruszenia zabezpieczenia czujnika,

brak dalszych szczegółów,

błąd uwierzytelnienia,

błąd integralności przechowywanych danych,

błąd wewnętrznego przesyłania danych,

nieupoważnione otwarcie obudowy,

uszkodzenie sprzętu,

RFU,

usterki urządzenia rejestrującego,

brak dalszych szczegółów,

usterka wewnętrzna VU,

usterka drukarki,

usterka wyświetlacza,

usterka pobierania danych,

usterka czujnika,

wewnętrzny odbiornik GNSS,

urządzenie zewnętrzne GNSS,

urządzenie do łączności na odległość,

interfejs ITS,

RFU,

usterki karty,

brak dalszych szczegółów,

RFU,

RFU,

swoisty dla producenta.”;

pkt 2.71 otrzymuje brzmienie:

„2.71. ExtendedSealIdentifier

Generacja 2:

Rozszerzony identyfikator plomby jednoznacznie identyfikuje plombę (wymaganie 401 określone w załączniku IC).

Tekst z obrazka

manufacturerCode: jest kodem producenta plomby.

sealIdentifier jest identyfikatorem plomby, który jest niepowtarzalny dla producenta.”;

pkt 2.78 i 2.79 otrzymują brzmienie:

„2.78. GNSSAccumulatedDriving

Generacja 2:

Informacje zapisane na karcie kierowcy lub na karcie warsztatowej dotyczące położenia pojazdu z GNSS, jeżeli skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech godzin (wymagania 306 i 354 określone w załączniku IC).

Tekst z obrazka

gnssADPointerNewestRecord jest indeksem ostatniego uaktualnionego rekordu skumulowanego prowadzenia pojazdu z GNSS.

Value assignment to liczba odpowiadająca stanowi licznika rekordu GNSS dotyczącego skumulowanego prowadzenia pojazdu, rozpoczynając od »0« dla pierwszego wystąpienia w strukturze rekordu GNSS dotyczącego skumulowanego czasu prowadzenia pojazdu.

gnssAccumulatedDrivingRecords jest zbiorem rekordów zawierających datę i godzinę, kiedy skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin i informacji na temat położenia pojazdu.

2.79. GNSSAccumulatedDrivingRecord

Generacja 2:

Tekst z obrazka

timeStamp to data i godzina, o której skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin.

gnssPlaceRecord zawiera informacje dotyczące położenia pojazdu.

vehicleOdometerValue to wartość stanu licznika kilometrów, przy której skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin.”;

pkt 2.86 otrzymuje brzmienie:

„2.86. KeyIdentifier

Unikalny identyfikator klucza publicznego używany przy odwoływaniu się do klucza i do wybierania klucza. Identyfikuje także posiadacza klucza.

Tekst z obrazka

Pierwsza pozycja jest odpowiednia przy odesłaniu do klucza publicznego przyrządu rejestrującego, karty do tachografu lub urządzenia zewnętrznego GNSS.

Druga pozycja jest odpowiednia przy odesłaniu do klucza publicznego przyrządu rejestrującego (w przypadkach, gdy numer seryjny przyrządu rejestrującego może nie być znany w czasie sporządzenia certyfikatu).

Trzecia pozycja jest odpowiednia przy odesłaniu do klucza publicznego państwa członkowskiego.”;

pkt 2.92 otrzymuje brzmienie:

„2.92. MAC

Generacja 2:

Kryptograficzna suma kontrolna o długości 8, 12 lub 16 bajtów odpowiadającej mechanizmom szyfrowania określonym w dodatku 11.

Tekst z obrazka ”

m)	pkt 2.111 otrzymuje brzmienie: „2.111. NoOfGNSSADRecords Generacja 2: Liczba rekordów skumulowanego czasu prowadzenia pojazdu z GNSS, które mogą być przechowywane na karcie. Tekst z obrazka NoOfGNSSADRecords ::= INTEGER (0..216-1) Przypisanie wartości: zob. dodatek 2.”;

n)	w pkt 2.120 przypisanie wartości „16H” otrzymuje brzmienie: „ Tekst z obrazka ’16’HVuGNSSADRecord ”;

o)	pkt 2.160 otrzymuje brzmienie: „2.160. Zarezerwowany dla przyszłego użytku.”;

pkt 2.162 otrzymuje brzmienie:

„2.162. TimeReal

Kod w polu zawierającym łącznie datę i godzinę, gdzie data i godzina są wyrażone w sekundach liczonych od godziny 00h.00m.00s. w dniu 1 stycznia 1970 r. UTC.

Tekst z obrazka

Przypisanie wartości – zapisane oktetami: liczba sekund od północy 1 stycznia 1970 r. UTC.

Maksymalna możliwa data/godzina wypada w 2106 r.”;

pkt 2.179 otrzymuje brzmienie:

„2.179. VuCardRecord

Generacja 2:

Informacje przechowywane w przyrządzie rejestrującym dotyczące używanej karty do tachografu (wymaganie 132 określone w załączniku IC).

Tekst z obrazka

cardNumberAndGenerationInformation jest pełnym numerem karty i generacji dla użytej karty (typ danych 2.74).

cardExtendedSerialNumber odczytany z pliku EF_ICC w ramach pliku głównego karty.

cardStructureVersion odczytane z pliku EF_Application_Identification w ramach pliku DF_Tachograph_G2.

cardNumber odczytane z pliku EF_Identification w ramach pliku DF_Tachograph_G2.”;

pkt 2.203 i 2.204 otrzymują brzmienie:

„2.203. VuGNSSADRecord

Generacja 2:

Informacje przechowywane w przyrządzie rejestrującym dotyczące położenia pojazdu z GNSS, jeżeli skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech godzin (wymagania 108 i 110 określone w załączniku IC).

Tekst z obrazka

timeStamp to data i godzina, o której skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin.

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

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

gnssPlaceRecord zawiera informacje dotyczące położenia pojazdu.

vehicleOdometerValue to wartość stanu licznika kilometrów, przy której skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin.

2.204. VuGNSSADRecordArray

Generacja 2:

Tekst z obrazka

recordType oznacza typ rekordu (VuGNSSADRecord).

Value Assignment: zob. RecordType

recordSize to wielkość VuGNSSADRecord w bajtach.

noOfRecords jest liczbą rekordów w zbiorze.

records jest zbiorem rekordów skumulowanego czasu prowadzenia pojazdu z GNSS.”;

s)	pkt 2.230 i 2.231 otrzymują brzmienie: „2.230. Zarezerwowany dla przyszłego użytku. 2.231. Zarezerwowany dla przyszłego użytku.”;

w pkt 2.234 tekst pod nagłówkiem „Generacja 2” otrzymuje brzmienie:

„

Tekst z obrazka

Oprócz generacji 1 używane są następujące elementy danych:

noOfGNSSCDRecords jest liczbą rekordów skumulowanego czasu prowadzenia pojazdu z GNSS, które mogą być zapisane na karcie.

noOfSpecificConditionRecords jest liczbą rekordów warunków szczególnych, które mogą być zapisane na karcie.

noOfCardVehicleUnitRecords jest liczbą rekordów używanych przyrządów rejestrujących, które mogą być zapisane na karcie.”;

30)

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

w pkt 1.1 dodaje się następujące skróty:

„CHA	upoważnienie posiadacza certyfikatu
DO	obiekt danych”;

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

(i)

punkt TCS_24 otrzymuje brzmienie:

„TCS_24

Przedmiotowe warunki zabezpieczenia mogą być powiązane ze sobą w następujący sposób:

AND: muszą zostać spełnione wszystkie warunki zabezpieczenia

OR: musi zostać spełniony przynajmniej jeden warunek zabezpieczenia

Zasady dostępu dla systemu plików, tzn. polecenia SELECT, READ BINARY oraz UPDATE BINARY, zostały określone w rozdziale 4. Zasady dostępu dla pozostałych poleceń zostały określone w poniższych tabelach. Określenie »nie dotyczy« jest stosowane w przypadku braku wymogu obsługi danego polecenia. W takim przypadku polecenie może być lub nie być obsługiwane, ale warunek dostępu jest wyłączony z zakresu zastosowania.”;

(ii)

w pkt TCS_25 tabela otrzymuje brzmienie:

„Polecenie

Karta kierowcy

Karta warsztatowa

Karta kontrolna

Karta firmowa

External Authenticate

—	dla uwierzytelnienia 1. generacji

ALW

—	dla uwierzytelnienia 2. generacji

ALW

PWD

ALW

Internal Authenticate

ALW

PWD

ALW

General Authenticate

ALW

Get Challenge

ALW

MSE:SET AT

ALW

MSE:SET DST

ALW

Process DSRC Message

nie dotyczy

PSO: Compute Digital Signature

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

nie dotyczy

PSO: Hash

nie dotyczy

ALW

nie dotyczy

PERFORM HASH of FILE

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

nie dotyczy

PSO: Verify Certificate

ALW

PSO: Verify Digital Signature

nie dotyczy

ALW

nie dotyczy

Verify

nie dotyczy

ALW

nie dotyczy

nie dotyczy ”

(iii)

w pkt TCS_26 tabela otrzymuje brzmienie:

„Polecenie

Karta kierowcy

Karta warsztatowa

Karta kontrolna

Karta firmowa

External Authenticate

—	dla uwierzytelnienia 1. generacji

nie dotyczy

—	dla uwierzytelnienia 2. generacji

ALW

PWD

ALW

Internal Authenticate

nie dotyczy

General Authenticate

ALW

Get Challenge

ALW

MSE:SET AT

ALW

MSE:SET DST

ALW

Process DSRC Message

nie dotyczy

ALW

nie dotyczy

PSO: Compute Digital Signature

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

nie dotyczy

PSO: Hash

nie dotyczy

ALW

nie dotyczy

PERFORM HASH of FILE

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

nie dotyczy

PSO: Verify Certificate

ALW

PSO: Verify Digital Signature

nie dotyczy

ALW

nie dotyczy

Verify

nie dotyczy

ALW

nie dotyczy

nie dotyczy”

(iv)

w pkt TCS_27 tabela otrzymuje brzmienie:

„Polecenie

Karta kierowcy

Karta warsztatowa

Karta kontrolna

Karta firmowa

External Authenticate

—	dla uwierzytelnienia 1. generacji

nie dotyczy

—	dla uwierzytelnienia 2. generacji

ALW

PWD

ALW

Internal Authenticate

nie dotyczy

General Authenticate

ALW

Get Challenge

ALW

MSE:SET AT

ALW

MSE:SET DST

ALW

Process DSRC Message

nie dotyczy

PSO: Compute Digital Signature

nie dotyczy

PSO: Hash

nie dotyczy

PERFORM HASH of FILE

nie dotyczy

PSO: Verify Certificate

ALW

PSO: Verify Digital Signature

nie dotyczy

Verify

nie dotyczy

ALW

nie dotyczy

nie dotyczy ”

w pkt 3.4 ppkt TCS_29 otrzymuje brzmienie:

„TCS_29

Słowa stanu SW1 i SW2 są zwracane w komunikacie odpowiedzi i oznaczają stan przetwarzania polecenia.

SW1

SW2

Znaczenie

Normalne przetwarzanie.

Normalne przetwarzanie. XX = liczba dostępnych bajtów odpowiedzi.

Przetwarzanie ostrzeżenia. Część zwracanych danych może być uszkodzona

Nieudane uwierzytelnienie (ostrzeżenie)

Nieprawidłowe CHV (PIN). »X« oznacza licznik pozostałych prób.

Błąd wykonania – Stan pamięci nieulotnej bez zmian. Błąd integralności.

Błąd wykonania – Stan pamięci nieulotnej zmieniony

Błąd wykonania – Stan pamięci nieulotnej zmieniony – Uszkodzona pamięć

Błąd zabezpieczenia

nieprawidłowa kryptograficzna suma kontrolna (w czasie bezpiecznej wymiany komunikatów) lub

nieprawidłowy certyfikat (w czasie weryfikacji certyfikatu) lub

nieprawidłowy kryptogram (w czasie zewnętrznego uwierzytelnienia) lub

nieprawidłowy podpis (w czasie weryfikacji podpisu)

Nieprawidłowa długość (nieprawidłowe Lc lub Le)

Oczekiwane ostatnie polecenie łańcucha

Niedozwolone polecenie (brak dostępnej odpowiedzi w T=0)

Niespełniony stan zabezpieczenia.

Metoda uwierzytelnienia zablokowana.

Warunki użycia niespełnione.

Polecenie niedozwolone (brak bieżącego EF).

Brak oczekiwanych obiektów danych w bezpiecznej wymianie komunikatów

Nieprawidłowe obiekty danych w bezpiecznej wymianie komunikatów

Nieprawidłowe parametry w polu danych

Nie znaleziono pliku.

Nieprawidłowe parametry P1-P2.

Nie znaleziono powołanych danych.

Nieprawidłowe parametry (przesunięcie poza EF).

Nieprawidłowa długość, SW2 wskazuje dokładną długość. Pole danych nie jest zwracane.

Kod instrukcji nieobsługiwany lub nieważny.

Klasa nieobsługiwana.

—	Inne błędy kontroli

Dodatkowe słowa stanu zdefiniowane w normie ISO/IEC 7816-4 mogą być zwracane, jeżeli ich zachowanie nie jest wyraźnie wymienione w niniejszym dodatku.

Przykładowo następujące słowa stanu mogą być zwracane opcjonalnie:

6881: Kanał logiczny nieobsługiwany

6882: Bezpieczna wymiana komunikatów nieobsługiwana”;

w pkt 3.5.1.1 tiret ostatnie pozycji TCS_38 otrzymuje brzmienie:

„—	Jeżeli wybrana aplikacja uznana jest za uszkodzoną (znaleziony błąd integralności w atrybutach pliku), zwróconym stanem przetwarzania jest »6400« lub »6500«.”;

w pkt 3.5.1.2 tiret ostatnie pozycji TCS_41 otrzymuje brzmienie:

„—	Jeżeli wybrany plik uznany jest za uszkodzony (znaleziony błąd integralności w atrybutach pliku), zwróconym stanem przetwarzania jest »6400« lub »6500«.”;

w pkt 3.5.2.1 tiret szóste pozycji TCS_43 otrzymuje brzmienie:

„—	Jeżeli błąd integralności zostaje wykryty w atrybutach pliku, karta uznaje, że plik jest uszkodzony i nienaprawialny, a zwróconym stanem przetwarzania jest »6400« lub »6500«.”;

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

(i)

w pozycji TCS_45 tabela otrzymuje brzmienie:

„Bajt

Długość

Wartość

Opis

»81h«

TPV: znacznik wartości danych odkrytych

»NNh« lub

»81 NNh«

LPV: długość zwracanych danych (= początkowemu Le).

L ma 2 bajty, jeżeli LPV>127 bajtów

#(2+L) - #(1+L+NN)

»XX..XXh«

Wartość danych odkrytych

#(2+L+NN)

»99h«

Znacznik stanu przetwarzania (SW1-SW2) – opcjonalnie dla bezpiecznej wymiany komunikatów 1. generacji

#(3+L+NN)

»02h«

Długość stanu przetwarzania – opcjonalnie dla bezpiecznej wymiany komunikatów 1. generacji

#(4+L+NN) - #(5+L+NN)

»XX XXh«

Stan przetwarzania niechronionej odpowiedzi APDU – opcjonalnie dla bezpiecznej wymiany komunikatów 1. generacji

#(6+L+NN)

»8Eh«

TCC: znacznik kryptograficznej sumy kontrolnej

#(7+L+NN)

»XXh«

LCC: długość znajdującej się dalej kryptograficznej sumy kontrolnej

»04h« dla bezpiecznej wymiany komunikatów 1. generacji (zob. dodatek 11 część A)

»08h«, »0Ch« lub »10h«, w zależności od długości klucza AES, dla bezpiecznej wymiany komunikatów 2. generacji (zob. dodatek 11 część B)

#(8+L+NN)-#(7+M+L+NN)

»XX..XXh«

Kryptograficzna suma kontrolna

»XXXXh«

Słowa stanu (SW1, SW2)”

(ii)

w pozycji TCS_46 tabela otrzymuje brzmienie:

„Bajt

Długość

Wartość

Opis

»87h«

TPI CG: znacznik zaszyfrowanych danych (kryptogram)

»MMh« lub

»81 MMh«

LPI CG: długość zwracanych zaszyfrowanych danych (różna od początkowego Le z polecenia, ze względu na wypełnienie)

L ma 2 bajty, jeżeli LPI CG > 127 bajtów

#(2+L)-#(1+L+MM)

»01XX..XXh«

dane szyfrowane: wskaźnik wypełnienia i kryptogram

#(2+L+MM)

»99h«

Znacznik stanu przetwarzania (SW1-SW2) – opcjonalnie dla bezpiecznej wymiany komunikatów 1. generacji

#(3+L+MM)

»02h«

Długość stanu przetwarzania – opcjonalnie dla bezpiecznej wymiany komunikatów 1. generacji

#(4+L+MM) - #(5+L+MM)

»XX XXh«

Stan przetwarzania niechronionej odpowiedzi APDU – opcjonalnie dla bezpiecznej wymiany komunikatów 1. generacji

#(6+L+MM)

»8Eh«

TCC: znacznik kryptograficznej sumy kontrolnej

#(7+L+MM)

»XXh«

LCC: długość znajdującej się dalej kryptograficznej sumy kontrolnej

»04h« dla bezpiecznej wymiany komunikatów 1. generacji (zob. dodatek 11 część A)

»08h«, »0Ch« lub »10h«, w zależności od długości klucza AES, dla bezpiecznej wymiany komunikatów 2. generacji (zob. dodatek 11 część B)

#(8+L+MM)-#(7+N+L+MM)

»XX..XXh«

Kryptograficzna suma kontrolna

»XXXXh«

Słowa stanu (SW1, SW2)”

w pkt 3.5.2.2 tiret szóste pozycji TCS_50 otrzymuje brzmienie:

„—	Jeżeli błąd integralności zostaje wykryty w atrybutach pliku, karta uznaje, że plik jest uszkodzony i nienaprawialny, a zwróconym stanem przetwarzania jest »6400« lub »6500«.”;

w pkt 3.5.2.3 w pozycji TCS_52 wprowadza się następujące zmiany:

(i)

wiersz ostatni tabeli otrzymuje brzmienie:

„Le

»XXh«

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

(ii)	dodaje się zdanie w brzmieniu: „W przypadku gdy T=0, karta przyjmuje wartość Le = »00h«, jeżeli nie stosuje się bezpiecznej wymiany komunikatów. W przypadku gdy T = 1, zwróconym stanem przetwarzania jest »6700«, jeżeli Le = »01h«.”;

w pkt 3.5.2.3 tiret szóste pozycji TCS_53 otrzymuje brzmienie:

„—	Jeżeli błąd integralności zostaje wykryty w atrybutach pliku, karta uznaje, że plik jest uszkodzony i nienaprawialny, a zwróconym stanem przetwarzania jest »6400« lub »6500«.”;

w pkt 3.5.3.2 tiret szóste pozycji TCS_63 otrzymuje brzmienie:

„—	Jeżeli błąd integralności zostaje wykryty w atrybutach pliku, karta uznaje, że plik jest uszkodzony i nienaprawialny, a zwróconym stanem przetwarzania jest »6400« lub »6500«.”;

w pkt 3.5.5 pozycja TCS_72 otrzymuje brzmienie:

„TCS_72

PIN wprowadzony przez użytkownika musi być kodowany w ASCII i prawidłowo wypełniony przez IFD bajtami »FFh« do długości 8 bajtów (zob. również typ danych WorkshopCardPIN w dodatku 1).”;

w pkt 3.5.8 pozycja TCS_95 otrzymuje brzmienie:

„TCS_95

Jeżeli uwierzytelnienie poleceniem INTERNAL AUTHENTICATE jest pomyślne, klucz bieżącej sesji 1. generacji (o ile istnieje) zostaje skasowany i nie jest dalej dostępny. W celu uzyskania nowego klucza sesji 1.generacji konieczne jest pomyślne wykonanie uwierzytelnienia poleceniem EXTERNAL AUTHENTICATE dla mechanizmu uwierzytelnienia 1. generacji.

Uwaga:

Zob. dodatek 11 pozycje CSM_193 i CSM_195 odnośnie do kluczy sesji 2. generacji. Jeżeli ustanowiono klucze sesji 2. generacji, a karta do tachografu otrzymuje odkryte polecenie APDU INTERNAL AUTHENTICATE, przerywa sesję bezpiecznej wymiany komunikatów 2. generacji i niszczy klucze sesji 2. generacji.”;

w pkt 3.5.9 pozycja TCS_97 otrzymuje brzmienie:

„TCS_97

Wariant polecenia dla wzajemnego uwierzytelnienia VU – karta drugiej generacji można wykonać w MF, DF Tachograph i DF Tachograph_G2 (zob. również TCS_34). Jeżeli uwierzytelnienie poleceniem 2. generacji EXTERNAL AUTHENTICATE jest pomyślne, klucz bieżącej sesji 1. generacji (o ile istnieje) zostaje skasowany i nie jest dalej dostępny.

Uwaga:

Zob. dodatek 11 pozycje CSM_193 i CSM_195 odnośnie do kluczy sesji 2. generacji. Jeżeli ustanowiono klucze sesji 2. generacji, a karta do tachografu otrzymuje odkryte polecenie APDU EXTERNAL AUTHENTICATE, przerywa sesję bezpiecznej wymiany komunikatów 2. generacji i niszczy klucze sesji 2. generacji.”;

w pkt 3.5.10 w tabeli w pozycji TCS_101 dodaje się wiersz w brzmieniu:

„5 + L + 1

»00h«

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

w pkt 3.5.11.2.3 w pozycji TCS_114 dodaje się następujące akapity:

„-	Jeżeli currentAuthenticatedTime karty jest późniejszy niż data upływu ważności wybranego klucza publicznego, zwróconym stanem przetwarzania jest »6A88«.

Uwaga:

W przypadku polecenia MSE: SET AT na potrzeby uwierzytelnienia VU powołany klucz to klucz publiczny VU_MA. Karta ustawia klucz publiczny VU_MA do użytku, jeżeli jest on dostępny w jej pamięci, który pokrywa się z odniesieniem do posiadacza certyfikatu (CHR) podanym w polu danych dotyczących polecenia (karta może zidentyfikować klucze publiczne VU_MA za pomocą pola CHA certyfikatu). Karta zwraca »6A 88« temu poleceniu, w przypadku gdy jest dostępny jedynie klucz publiczny VU_Sign lub nie jest dostępny żaden klucz publiczny przyrządu rejestrującego. Zob. definicja pola CHA w dodatku 11 i typu danych equipmentType w dodatku 1.

Analogicznie w przypadku polecenia MSE: SET DST odwołującego się do EQT (tzn. przyrządu rejestrującego lub karty), które jest przesyłane do karty kontrolnej, zgodnie z CSM_234 powołany klucz to zawsze klucz EQT_Sign, który musi być stosowany na potrzeby weryfikacji podpisu cyfrowego. Zgodnie z rys. 13 w dodatku 11 karta kontrolna będzie zawsze przechowywać odpowiedni klucz publiczny EQT_Sign. W pewnych przypadkach karta kontrolna może przechowywać odpowiadający klucz publiczny EQT_MA. Karta kontrolna musi zawsze ustawiać klucz publiczny EQT_Sign do użytku, gdy otrzyma polecenie MSE: SET DST.”;

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

(i)

pozycja TCS_121 otrzymuje brzmienie:

„TCS_121

Tymczasowo zachowana wartość skrótu pliku jest usuwana, jeżeli nowa wartość skrótu zostaje obliczona za pomocą polecenia PERFORM HASH of FILE, jeżeli DF jest wybrany oraz jeżeli karta do tachografu jest zresetowana.”;

(ii)

pozycja TCS_123 otrzymuje brzmienie:

„TCS_123

Aplikacja tachograficzna 2. generacji musi obsługiwać algorytm SHA-2 (SHA-256, SHA-384 lub SHA-512), określony za pomocą mechanizmu szyfrowania w dodatku 11 część B dla klucza podpisu karty Card_Sign.”;

(iii)

tabela w pozycji TCS_124 otrzymuje brzmienie:

„Bajt	Długość	Wartość	Opis
CLA	1	»80h«	CLA
INS	1	»2Ah«	wykonanie operacji zabezpieczającej
P1	1	»90h«	znacznik: Hash
P2	1	»00h«	algorytm niejawnie znany W przypadku aplikacji tachograficznej 1. generacji: SHA-1 W przypadku aplikacji tachograficznej 2. generacji: algorytm SHA-2 (SHA-256, SHA-384 lub SHA-512) zdefiniowany za pomocą mechanizmu szyfrowania w dodatku 11 część B dla klucza podpisu karty Card_Sign”

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

tekst pod nagłówkiem aż do pozycji TCS_126 otrzymuje brzmienie:

„Polecenia tego używa się do obliczania podpisu cyfrowego z obliczonego wcześniej kodu skrótu (zob. polecenie PERFORM HASH of FILE, pkt 3.5.13).

Tylko karta kierowcy i karta warsztatowa są zobowiązane obsługiwać to polecenie w DF Tachograph i DF Tachograph_G2.

Inne rodzaje kart do tachografów mogą, ale nie muszą realizować tego polecenia. W przypadku aplikacji tachograficznej 2. generacji jedynie karta kierowcy i karta warsztatowa mają klucz podpisu 2. generacji, inne karty nie mają możliwości skutecznego wykonania polecenia i kończą je odpowiednim kodem błędu.

Polecenie może, ale nie musi być dostępne w MF. Jeżeli polecenie nie jest dostępne w MF, zostaje zakończone odpowiednim kodem błędu.

Polecenie to jest zgodne z normą ISO/IEC 7816-8. Zastosowanie tego polecenia jest ograniczone w porównaniu z poleceniem zdefiniowanym w tej normie.”;

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

(i)

tabela w pozycji TCS_133 otrzymuje brzmienie:

„Bajt

Długość

Wartość

Opis

CLA

»00h«

CLA

INS

»2Ah«

wykonanie operacji zabezpieczającej

»00h«

»A8h«

Znacznik: pole danych zawiera obiekty DO stosowne do weryfikacji

»XXh«

Lc długość następnego pola danych

»9Eh«

znacznik dla podpisu cyfrowego

#7 lub

#7-#8

»NNh« lub

»81 NNh«

Długość podpisu cyfrowego (L ma 2 bajty, jeżeli podpis cyfrowy jest dłuższy niż 127 bajtów):

128 bajtów kodowanych zgodnie z dodatkiem 11 część A dla aplikacji tachograficznej 1. generacji.

w zależności od wybranej krzywej dla aplikacji tachograficznej 2. generacji (zob. dodatek 11 część B).

#(7+L)-#(6+L+NN)

»XX..XXh«

treść podpisu cyfrowego”

(ii)

w pozycji TCS_134 dodaje się tiret w brzmieniu:

„—	Jeżeli wybrany klucz publiczny (używany do weryfikacji podpisu cyfrowego) ma CHA.LSB (CertificateHolderAuthorisation.equipmentType), które nie jest odpowiednie dla weryfikacji podpisu cyfrowego zgodnie z dodatkiem 11, zwróconym stanem przetwarzania jest »6985«.”;

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

(i)

w tabeli w pozycji TCS_138 dodaje się wiersz w brzmieniu:

„5 + L + 1

»00h«

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

(ii)

w pozycji TCS_139 dodaje się akapit w brzmieniu:

„—	»6985« wskazuje, że 4-bajtowy znacznik czasu podany w polu danych dotyczących polecenia jest wcześniejszy niż cardValidityBegin lub późniejszy niż cardExpiryDate.”;

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

(i)	w strukturze danych w pozycji TCS_154 wiersze od DF Tachograph G2 do EF CardMA_Certificate oraz wiersze od EF GNSS_Places do końca tego podpunktu otrzymują brzmienie: „ Tekst z obrazka Plik / element danych Liczba rekordów Wielkość (w bajtach) Wartości domyślne Min. Maks. ”

(ii)

w pozycji TCS_155 element

w tabeli otrzymuje brzmienie:

„

252

336”

w pkt 4.3.1 tekst towarzyszący skrótowi SC4 w pozycji TCS_156 otrzymuje brzmienie:

„SC4	Dla polecenia READ BINARY z parzystym bajtem INS: (SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR (SM-C-MAC-G2 AND SM-R-ENC-MAC-G2) Dla polecenia READ BINARY z nieparzystym bajtem INS (jeżeli obsługiwane): NEV”;

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

(i)

w strukturze danych w pozycji TCS_162 wiersze od DF Tachograph G2 do EF CardMA_Certificate, wiersze od EF Calibration do extendedSealIdentifier oraz wiersze od EF GNSS_Places do vehicleOdometerValue otrzymują brzmienie:

„

Tekst z obrazka

”

(ii)

w pozycji TCS_163 element NoOfGNSSCDRecords w tabeli otrzymuje brzmienie:

„

24”

31)

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

a)	po wierszu z piktogramami „miejsce rozpoczęcia dziennego okresu pracy” i „miejsce zakończenia dziennego okresu pracy dodaje się wiersz w brzmieniu: „ położenie po 3 godzinach skumulowanego czasu prowadzenia pojazdu”;

b)	kombinacja piktogramów „korekta czasu (w warsztacie)” otrzymuje brzmienie: „ konflikt czasu lub korekta czasu (w warsztacie)”;

c)	do wykazu zdarzeń dodaje się następujące kombinacje piktogramów: „ brak informacji o pozycji z odbiornika GNSS lub błąd połączenia z urządzeniem zewnętrznym GNSS; błąd połączenia z urządzeniem do łączności na odległość”;

32)

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

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

(i)

blok nr 11.4 otrzymuje brzmienie:

„11.4

Wprowadzanie miejsca rozpoczęcia lub zakończenia dziennego okresu pracy

pi = piktogram miejsca rozpoczęcia / zakończenia, godzina, kraj, region

długość geograficzna zarejestrowanej pozycji

szerokość geograficzna zarejestrowanej pozycji

znacznik momentu określenia pozycji

Stan licznika kilometrów

pihh:mm Cou Reg

lon ±DDDoMM.M’

lat ± DDoMM.M’

hh:mm

x xxx xxx km”

(ii)

blok nr 11.5 otrzymuje brzmienie:

„11.5

Położenia po 3 godzinach skumulowanego czasu prowadzenia pojazdu”;

pi = położenie po 3 godzinach skumulowanego czasu prowadzenia pojazdu;

godzina

długość geograficzna zarejestrowanej pozycji

szerokość geograficzna zarejestrowanej pozycji

znacznik momentu określenia pozycji

Stan licznika kilometrów

”

w pkt 3.1 pozycja 11.15 formatu dziennego wydruku otrzymuje brzmienie:

„11.5

Położenia po 3 godzinach skumulowanego czasu prowadzenia pojazdu w kolejności chronologicznej”

w pkt 3.2 format dziennego wydruku otrzymuje brzmienie:

„1		Data i godzina drukowania dokumentu
2		Typ wydruku
3		Identyfikacja posiadacza karty (dla wszystkich kart włożonych do VU + GEN)
4		Identyfikacja pojazdu (tego, dla którego sporządzany jest wydruk)
5		Identyfikacja VU (z którego uzyskano wydruk +GEN)
6		Ostatnia kalibracja tego VU
7		Ostatnia kontrola tego tachografu
9		Ogranicznik czynności kierowcy
10		Ogranicznik szczeliny czytnika karty kierowcy (szczelina 1)
10 a		Stan poza zakresem na początku danego dnia
10.1 / 10.2 / 10.3 /10.3a / 10.4		Czynności w kolejności chronologicznej (szczelina czytnika karty kierowcy)
10		Ogranicznik szczeliny czytnika karty współkierowcy (szczelina 2)
10a		Stan poza zakresem na początku danego dnia
10.1 / 10.2 / 10.3 /10.3a / 10.4		Czynności w kolejności chronologicznej (szczelina czytnika karty współkierowcy)
11		Ogranicznik dziennego zestawienia
11.1		Zestawienie okresów bez karty w szczelinie czytnika karty kierowcy
11.4		Miejsca wprowadzone w kolejności chronologicznej
11.5		Położenia po 3 godzinach skumulowanego czasu prowadzenia pojazdu w kolejności chronologicznej
11.7		Podsumowania dla czynności
11.2		Zestawienie okresów bez karty w szczelinie czytnika karty współkierowcy
11.4		Miejsca wprowadzone w kolejności chronologicznej
11.5		Położenia po 3 godzinach skumulowanego czasu prowadzenia pojazdu w kolejności chronologicznej
11.8		Podsumowania dla czynności
11.3		Zestawienie czynności dla kierowcy z uwzględnieniem obu szczelin czytnika kart
	11.4	Miejsca wprowadzone przez danego kierowcę w kolejności chronologicznej
	11.5	Położenia po 3 godzinach skumulowanego czasu prowadzenia pojazdu w kolejności chronologicznej
11.9		Podsumowania dla czynności danego kierowcy
13.1		Ogranicznik zdarzeń/ usterek
13.4		Rekordy zdarzeń/ usterek (5 ostatnich zdarzeń lub usterek zapisanych lub trwających na VU)
22.1		Miejsce kontroli
22.2		Podpis kontrolera
22.3		Od godziny (miejsce przeznaczone dla kierowcy bez karty w celu wskazania
22.4		Do godziny dotyczących go okresów)
22.5		Podpis kierowcy”

w pkt 3.7 pozycja PRT_014 otrzymuje brzmienie:

„PRT_014

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

1	Data i godzina drukowania dokumentu
2	Typ wydruku
3	Identyfikacja posiadacza karty (dla wszystkich kart włożonych do przyrządu rejestrującego)
23	Karta ostatnio włożona do VU
23.1	Włożone karty (maks. 88 rekordów)
12.3	Ogranicznik usterek”

33)

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

pkt 1.1 otrzymuje brzmienie:

„1.1. Zakres

Dane mogą być pobierane na ESM:

—	z przyrządu rejestrującego za pośrednictwem inteligentnego urządzenia dedykowanego (IDE) przyłączonego do VU,

—	z karty do tachografu za pośrednictwem IDE spasowanego z czytnikiem karty (IFD),

—	z karty do tachografu za pośrednictwem przyrządu rejestrującego poprzez IDE przyłączone do VU.

Aby umożliwić weryfikację autentyczności i integralności pobranych danych przechowywanych na ESM, dane są pobierane razem z dołączonym podpisem, zgodnie z dodatkiem 11 »Wspólne mechanizmy zabezpieczenia«. Razem z danymi pobierane są również identyfikacja urządzenia źródłowego (VU lub karta) i jego świadectwa bezpieczeństwa (państwo członkowskie i urządzenie). Niezależnie od tego weryfikator danych musi mieć zaufany europejski klucz publiczny.

Dane pobrane z przyrządu rejestrującego są podpisywane przy użyciu wspólnych mechanizmów zabezpieczeń określonych w dodatku 11 część B (System tachografu drugiej generacji), z wyjątkiem sytuacji, gdy kontrolę kierowców przeprowadza organ kontrolny spoza UE, używając karty kontrolnej pierwszej generacji, w którym to przypadku dane są podpisywane przy użyciu wspólnych mechanizmów zabezpieczeń określonych w dodatku 11 część A (System tachografu pierwszej generacji), zgodnie z wymogiem określonym w dodatku 15 »Migracja«, wymóg MIG_015.

Niniejszy dodatek określa zatem dwa typy pobrań danych z VU:

—	pobranie danych z VU typu 2. generacji, zapewniające strukturę danych 2. generacji, podpisanych przy użyciu wspólnych mechanizmów zabezpieczeń określonych w dodatku 11 część B,

—	pobranie danych z VU typu 1. generacji, zapewniające strukturę danych 1. generacji, podpisanych przy użyciu wspólnych mechanizmów zabezpieczeń określonych w dodatku 11 część A,

Analogicznie występują dwa typy pobrań danych z kart kierowcy 2. generacji włożonych do przyrządu rejestrującego, jak określono w pkt 3 i 4 niniejszego dodatku.”;

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

(i)

tabela otrzymuje brzmienie:

„Struktura komunikatu		Maks. 4 bajty Nagłówek				Maks. 255 bajtów Dane			1 bajt Suma kontrolna
IDE ->	<- VU	FMT	TGT	SRC	LEN	SID	DS_ / TRTP	DANE	CS
Start Communication Request		81	EE	F0		81			E0
Positive Response Start Communication		80	F0	EE	03	C1		EA, 8F	9B
Start Diagnostic Session Request		80	EE	F0	02	10	81		F1
Positive Response Start Diagnostic		80	F0	EE	02	50	81		31
Link Control Service
Verify Baud Rate (stage 1)
9 600 Bd		80	EE	F0	04	87		01,01,01	EC
19 200 Bd		80	EE	F0	04	87		01,01,02	ED
38 400 Bd		80	EE	F0	04	87		01,01,03	EE
57 600 Bd		80	EE	F0	04	87		01,01,04	EF
115 200 Bd		80	EE	F0	04	87		01,01,05	F0
Positive Response Verify Baud Rate		80	F0	EE	02	C7		01	28
Transition Baud Rate (stage 2)		80	EE	F0	03	87		02,03	ED
Request Upload		80	EE	F0	0A	35		00,00,00,00,00,FF,FF, FF,FF	99
Positive Response Request Upload		80	F0	EE	03	75		00,FF	D5
Transfer Data Request
Overview		80	EE	F0	02	36	01 lub 21		97
Activities		80	EE	F0	06	36	02 lub 22	Date	CS
Events & Faults		80	EE	F0	02	36	03 lub 23	Date	99
Detailed Speed		80	EE	F0	02	36	04 lub 24	Date	9A
Technical Data		80	EE	F0	02	36	05 lub 25	Date	9B
Card download		80	EE	F0	02	36	06	Slot	CS
Positive Response Transfer Data		80	F0	EE	Len	76	TREP	Data	CS
Request Transfer Exit		80	EE	F0	01	37			96
Positive Response Request Transfer Exit		80	F0	EE	01	77			D6
Stop Communication Request		80	EE	F0	01	82			E1
Positive Response Stop Communication		80	F0	EE	01	C2			21
Acknowledge sub message		80	EE	F0	Len	83		Data	CS
Negative responses
General reject		80	F0	EE	03	7F	Sid Req	10	CS
Service not supported		80	F0	EE	03	7F	Sid Req	11	CS
Sub function not supported		80	F0	EE	03	7F	Sid Req	12	CS
Incorrect Message Length		80	F0	EE	03	7F	Sid Req	13	CS
Conditions not correct or Request sequence error		80	F0	EE	03	7F	Sid Req	22	CS
Request out of range		80	F0	EE	03	7F	Sid Req	31	CS
Upload not accepted		80	F0	EE	03	7F	Sid Req	50	CS
Response pending		80	F0	EE	03	7F	Sid Req	78	CS
Data not available		80	F0	EE	03	7F	Sid Req	FA	CS”

(ii)

do uwag pod tabelą dodaje się tiret w brzmieniu:

„—

TRTP 21–25 używa się w przypadku żądań pobrania danych z przyrządu rejestrującego typu 2. generacji, TRTP 01–05 używa się w przypadku żądań pobrania danych z przyrządu rejestrującego typu 1. generacji, które mogą zostać zaakceptowane przez przyrząd rejestrujący w ramach kontroli kierowcy przeprowadzanej przez organ kontrolny spoza UE przy użyciu karty kontrolnej 1. generacji,

—	TRTP 11–19 oraz 31–39 są zarezerwowane dla żądań pobrania swoistych dla producenta.”;

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

(i)

punkt DDP_011 otrzymuje brzmienie:

„DDP_011

IDE wysyła żądanie »Transfer Data Request« w celu wskazania VU typu danych, które mają być pobierane. Jednobajtowy parametr »Transfer Request Parameter« (TRTP) wskazuje typ przesyłania.

Rozróżnia się sześć typów przesyłania danych: Na potrzeby pobierania danych z przyrządu rejestrującego dla każdego typu transferu można użyć dwóch różnych wartości TRTP:

Typ transferu danych	Wartość TRTP w przypadku żądań pobrania danych z przyrządu rejestrującego typu 1. generacji	Wartość TRTP w przypadku żądań pobrania danych z przyrządu rejestrującego typu 2. generacji
Przegląd	01	21
Czynności o określonej dacie	02	22
Zdarzenia i usterki	03	23
Szczegółowe dane dotyczące prędkości	04	24
Dane techniczne	05	25

Typ transferu danych	Wartość TRTP
Pobieranie danych z karty	06”

(ii)

pozycja DDP_054 otrzymuje brzmienie:

„DDP_054

IDE musi obowiązkowo zażądać przesłania danych Informacje ogólne (TRTP 01 lub 21) w czasie sesji pobierania, ponieważ tylko to zagwarantuje, że certyfikaty VU są zarejestrowane w pobieranym pliku (i umożliwi weryfikację podpisu cyfrowego).

W drugim przypadku (TRTP 02 lub 22) w komunikacie »Transfer Data Request« znajduje się informacja o dniu kalendarzowym (format

), dla którego dane mają być pobrane.”;

w pkt 2.2.2.10 pozycja DDP_055 otrzymuje brzmienie:

„DDP_055

W pierwszym przypadku (TREP 01 lub 21) VU wyśle dane pomagające operatorowi IDE w wyborze danych, które chce dalej pobrać. Komunikat ten zawiera następujące informacje:

—	świadectwa bezpieczeństwa,

—	identyfikacja pojazdu,

—	bieżąca data i godzina VU,

—	minimalna i maksymalna data, dla której można dokonać pobrania (dane z VU),

—	sygnalizacja obecności kart w VU,

—	poprzednie pobranie dla firmy,

—	blokady firmowe,

—	poprzednie kontrole.”;

w pkt 2.2.2.16 tiret ostatnie pozycji DDP_018 otrzymuje brzmienie:

„—	FA brak dostępnych danych Obiekt danych żądania transferu danych nie jest dostępny w przyrządzie rejestrującym (np. karta nie jest włożona, zażądano pobrania danych z przyrządu rejestrującego typu generacji 1 poza ramami kontroli kierowców przez organ kontrolny spoza UE ...).”;

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

(i)	pozycja DDP_029 akapit pierwszy otrzymuje brzmienie: „Pole danych w komunikacie „Positive Response Transfer Data Overview” zawiera następujące dane w określonej tu kolejności pod SID 76 Hex, TREP 01 lub 21 Hex z odpowiednim podziałem na podkomunikaty i licznikami:”;

(ii)	nagłówek „Struktura danych 1. generacji” otrzymuje brzmienie: „Struktura danych 1. generacji (TREP 01 Hex)”;

(iii)

nagłówek „Struktura danych 2. generacji” otrzymuje brzmienie:

„Struktura danych 2. generacji (TREP 21 Hex)”;

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

(i)	pozycja DDP_030 akapit pierwszy otrzymuje brzmienie: „Pole danych w komunikacie »Positive Response Transfer Data Activities« zawiera następujące dane w określonej tu kolejności pod SID 76 Hex, TREP 02 lub 22 Hex z odpowiednim podziałem na podkomunikaty i licznikami:”;

(ii)	nagłówek „Struktura danych 1. generacji” otrzymuje brzmienie: „Struktura danych 1. generacji (TREP 02 Hex)”;

(iii)

nagłówek „Struktura danych 2. generacji” otrzymuje brzmienie:

„Struktura danych 2. generacji (TREP 22 Hex)”;

(iv)

element VuGNSSCDRecordArray pod nagłówkiem „Struktura danych 2. generacji (TREP 22 Hex)” otrzymuje brzmienie:

„

Pozycje GNSS dla pojazdu, gdy skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech godzin. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0.”

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

(i)	pozycja DDP_031 akapit pierwszy otrzymuje brzmienie: „Pole danych w komunikacie »Positive Response Transfer Data Events and Faults« zawiera następujące dane w określonej tu kolejności pod SID 76 Hex, TREP 03 lub 23 Hex, z odpowiednim podziałem na podkomunikaty i z licznikami:”;

(ii)	nagłówek „Struktura danych 1. generacji” otrzymuje brzmienie: „Struktura danych 1. generacji (TREP 03 Hex)”;

(iii)

nagłówek „Struktura danych 2. generacji” otrzymuje brzmienie:

„Struktura danych 2. generacji (TREP 23 Hex)”;

(iv)	skreśla się element VuTimeAdjustmentGNSSRecordArray pod nagłówkiem „Struktura danych 2. generacji (TREP 23 Hex)”;

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

(i)	pozycja DDP_032 akapit pierwszy otrzymuje brzmienie: „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:”;

(ii)	nagłówek „Struktura danych 1. generacji” otrzymuje brzmienie: „Struktura danych 1. generacji (TREP 04)”;

(iii)

nagłówek „Struktura danych 2. generacji” otrzymuje brzmienie:

„Struktura danych 2. generacji (TREP 24)”;

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

(i)	pozycja DDP_033 akapit pierwszy otrzymuje brzmienie: „Pole danych w komunikacie »Positive Response Transfer Data Technical Data« zawiera następujące dane w określonej tu kolejności pod SID 76 Hex, TREP 05 lub 25 Hex z odpowiednim podziałem na podkomunikaty i licznikami:”;

(ii)	nagłówek „Struktura danych 1. generacji” otrzymuje brzmienie: „Struktura danych 1. generacji (TREP 05)”;

(iii)

nagłówek „Struktura danych 2. generacji” otrzymuje brzmienie:

„Struktura danych 2. generacji (TREP 25)”;

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 oraz Dane te są nieobowiązkowe i nie są chronione podpisem cyfrowym.

—

(w przypadku kart do tachografów pierwszej i drugiej generacji) Pobieranie w plikach EF w

—	Wczytanie plików EF i Dane te nie są chronione podpisem cyfrowym. Pobranie tych plików jest obowiązkowe dla każdej sesji pobierania.

—	wczytanie plików EF zawierających inne dane aplikacyjne (w ) z wyłączeniem EF 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 i jest obowiązkowe dla każdej sesji pobierania.

—	Przy pobieraniu danych z karty kierowcy obowiązkowe jest pobranie także następujących plików EF: Tekst z obrazka Events_Data, Faults_Data, Tekst z obrazka Driver_Activity_Data, Vehicles_Used, Places, Control_Activity_Data, Specific_Conditions,

—

(w przypadku wyłącznie kart do tachografów drugiej generacji) Z wyjątkiem sytuacji gdy pobranie danych z karty kierowcy włożonej do przyrządu rejestrującego odbywa się w trakcie kontroli kierowców przeprowadzanej przez organ kontrolny spoza UE przy użyciu karty kontrolnej pierwszej generacji, pobieranie w plikach EF

—	Pobieranie w plikach EF CardSignCertificate, CA_Certificate oraz Link_Certificate (jeżeli występują). Dane te nie są chronione podpisem cyfrowym. Pobranie tych plików jest obowiązkowe dla każdej sesji pobierania.

—	Wczytanie plików EF zawierających inne dane aplikacyjne (w ) z wyłączeniem EF 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 i jest obowiązkowe dla każdej sesji pobierania.

—	Przy pobieraniu danych z karty kierowcy obowiązkowe jest pobranie także następujących plików EF: Tekst z obrazka Events_Data, Faults_Data, Driver_Activity_Data, Vehicles_Used, Places, Control_Activity_Data, Specific_Conditions, VehicleUnits_Used, GNSS Places.

—	Przy wczytywaniu danych z karty kierowcy aktualizowana jest data w pliku EF w DF i, w stosownych przypadkach,

—	Przy pobieraniu danych z karty warsztatowej zerowany jest licznik kalibracji w pliku EF w DF i, w stosownych przypadkach,

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

l)	pkt 3.3.2 pozycja DDP_037 akapit pierwszy otrzymuje brzmienie: „Sekwencja pobierania plików elementarnych ICC, IC, Card_Certificate (lub CardSignCertificate dla DF Tachograph_G2), CA_Certificate i Link_Certificate (wyłącznie dla DF Tachograph_G2) jest następująca:”;

w pkt 3.3.3 tabela otrzymuje brzmienie:

„Karta

Kierunek

IDE/IFD

Znaczenie / Uwagi

Select File

Perform Hash of File

—	Oblicza wartość skrótu dla danych wybranego pliku przy pomocy wymaganego algorytmu skrótu zgodnie z dodatkiem 11 część A lub B. Polecenie to nie jest poleceniem ISO.

oblicz skrót pliku i czasowo zachowaj wartość skrótu

Read Binary

Jeżeli wielkość danych w pliku jest większa od pojemności bufora czytnika lub karty, polecenie musi być powtarzane aż do odczytania całego pliku.

File Data

zapisz odebrane dane na ESM

zgodnie z 3.4 Data storage format

PSO: Compute Digital Signature

wykonaj operację zabezpieczającą »Compute Digital Signature«, używając czasowo zachowaną wartość skrótu

Signature

dołącz dane do poprzednio zapisanych danych na ESM

zgodnie z 3.4 Data storage format”

w pkt 3.4.2 pozycja DDP_046 otrzymuje brzmienie:

„DDP_046

Podpis zachowuje się w obiekcie TLV znajdującym się bezpośrednio za obiektem TLV zawierającym dane pliku.

Definicja	Znaczenie	Długość
FID (2 bajty) \|\| »00«	Znacznik pliku EF (FID) w DF lub wspólnych informacji zawartych na karcie	3 bajty
FID (2 bajty) \|\| »01«	Znacznik podpisu pliku EF (FID) w DF	3 bajty
FID (2 bajty) \|\| »02«	Znacznik podpisu pliku EF (FID) w DF	3 bajty
FID (2 bajty) \|\| »03«	Znacznik podpisu pliku EF (FID) w DF	3 bajty
xx xx	długość pola wartości	2 bajty

Przykładowe dane w pliku pobranym na ESM:

Znacznik

Długość

Wartość

—	Dane pliku EF ICC

—	Dane pliku EF Card_Certificate

—

...

Dane pliku EF

(w DF

)

Podpis pliku EF

(w DF

)

Dane pliku EF

w DF

Podpis pliku EF

_Used w DF

”

w pkt 4 pozycja DDP_049 otrzymuje brzmienie:

„DDP_049

Karty kierowcy pierwszej generacji: Dane pobiera się przy użyciu protokołu pobierania danych pierwszej generacji, a pobierane dane muszą mieć taki sam format jak dane pobierane z przyrządu rejestrującego pierwszej generacji.

Karty kierowcy drugiej generacji: Następnie VU pobiera wszystkie dane z karty, plik po pliku, zgodnie z protokołem pobierania danych z karty zdefiniowanym w pkt 3, oraz przekazuje wszystkie dane odebrane z karty do IDE w odpowiednim formacie pliku TLV (zob. 3.4.2) i zapakowane w komunikacie »Positive Response Transfer Data«.”;

34)	w dodatku 8 w pkt 2 akapit pod nagłówkiem „Odniesienia” otrzymuje brzmienie: „ISO 14230-2: Pojazdy drogowe – Systemy diagnostyczne – Protokół słowa kluczowego 2000 – część 2: Warstwa łącza danych. Wydanie pierwsze: 1999.”;

35)

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

pkt 6 spisu treści otrzymuje brzmienie:

„6.	BADANIA ZEWNĘTRZNEGO URZĄDZENIA DO ŁĄCZNOŚCI NA ODLEGŁOŚĆ”;

w pkt 1.1 tiret pierwsze otrzymuje brzmienie:

„—	świadectwie bezpieczeństwa, opartym na specyfikacjach normy »Common Criteria«, w odniesieniu do celu bezpieczeństwa w pełni zgodnego z celami przedstawionymi w dodatku 10 do niniejszego załącznika,”;

w pkt 2 tabela dotycząca badań funkcjonalności przyrządu rejestrującego otrzymuje brzmienie:

„Nr

Badanie

Opis

Powiązane wymogi

Badanie administracyjne

1.1

Dokumentacja

Prawidłowość dokumentacji

1.2

Wyniki badań producenta

Wyniki badań producenta przeprowadzonych podczas integracji.

Przedstawienie dokumentów papierowych.

88, 89,91

Kontrola wizualna

2.1

Zgodność z dokumentacją

2.2

Identyfikacja/oznakowanie

224–226

2.3

Materiały

219–223

2.4

Plombowanie

398, 401–405

2.5

Interfejsy zewnętrzne

Badania funkcjonalności

3.1

Obsługiwane funkcje

02, 03, 04, 05, 07, 382

3.2

Tryby pracy

09–11*, 134, 135

3.3

Prawa dostępu do funkcji i danych

12* 13*, 382, 383, 386–389

3.4

Monitorowanie wkładania i wyjmowania kart

15, 16, 17, 18, 19*, 20*, 134

3.5

Pomiar prędkości i odległości

21–31

3.6

Pomiar czasu (badanie przeprowadzone w temperaturze 20 °C)

38–43

3.7

Monitorowanie czynności kierowcy

44–53, 134

3.8

Monitorowanie stanu prowadzenia pojazdu

54, 55, 134

3.9

Pozycje wprowadzane ręcznie

56–62

3.10

Zarządzanie blokadami firmowymi

63–68

3.11

Monitorowanie czynności kontrolnych

69, 70

3.12

Wykrywanie zdarzeń lub usterek

71–88, 134

3.13

Dane identyfikujące urządzenie

93*, 94*, 97, 100

3.14

Dane dotyczące wkładania i wyjmowania karty kierowcy

102*–104*

3.15

Dane dotyczące czynności kierowcy

105*–107*

3.16

Dane dotyczące miejsc i położenia

108*–112*

3.17

Dane dotyczące licznika kilometrów

113*–115*

3.18

Szczegółowe dane dotyczące prędkości

116*

3.19

Dane dotyczące zdarzeń

117*

3.20

Dane dotyczące usterek

118*

3.21

Dane dotyczące kalibracji

119*–121*

3.22

Dane dotyczące korekty czasu

124*, 125*

3.23

Dane dotyczące czynności kontrolnej

126*, 127*

3.24

Dane dotyczące blokad firmowych

128*

3.25

Dane dotyczące czynności pobierania

129*

3.26

Dane dotyczące warunków szczególnych

130*, 131*

3.27

Rejestrowanie i przechowywanie danych na kartach do tachografu

136, 137, 138*, 139*, 141*, 142, 143

144, 145, 146*, 147*, 148*, 149, 150

3.28

Wyświetlanie

90, 134,

151–168

PIC_001, DIS_001

3.29

Drukowanie

90, 134,

169–181, PIC_001, PRT_001–PRT_014

3.30

Ostrzeganie

134, 182–191,

PIC_001

3.31

Pobieranie danych na nośnik zewnętrzny

90, 134, 192–196

3.32

Łączność na odległość na potrzeby ukierunkowanych kontroli drogowych

197–199

3.33

Wyprowadzanie danych do dodatkowych urządzeń zewnętrznych

200, 201

3.34

Kalibracja

202–206*, 383, 384, 386–391

3.35

Drogowe kontrole kalibracji

207–209

3.36

Korekta czasu

210–212*

3.37

Niezakłócanie funkcji dodatkowych

06, 425

3.38

Interfejs czujnika ruchu

02, 122

3.39

Urządzenie zewnętrzne GNSS

03, 123

3.40

Sprawdzenie, czy VU wykrywa, rejestruje i zapisuje zdarzenie (zdarzenia) lub usterkę (usterki) określone przez producenta VU, gdy sparowany czujnik ruchu reaguje na pola magnetyczne zaburzające wykrywanie ruchu pojazdu.

217

3.41

Pakiet szyfrów i standardowe parametry domeny

CSM_48, CSM_50

Badania środowiskowe

4.1

Temperatura

Sprawdzenie funkcjonalności za pomocą:

badania zgodnie z normą ISO 16750-4, rozdział 5.1.1.2: Próba eksploatacyjna w niskiej temperaturze (72 h w temperaturze -20 °C).

Badanie to odnosi się do normy IEC 60068-2-1: Badania środowiskowe – Część 2-1: Próby – Próba A: Zimno

badania zgodnie z normą ISO 16750-4: Rozdział 5.1.2.2: Próba eksploatacyjna w wysokiej temperaturze (72 h w temperaturze 70 °C).

Badanie to odnosi się do normy IEC 60068-2-2: Podstawowe procedury badań środowiskowych – Część 2: Próby – Próba B: Suche gorąco;

badania zgodnie z normą ISO 16750-4: Rozdział 5.3.2: Nagła zmiana temperatury z określonym okresem przejściowym (-20 °C / 70 °C, 20 cykli, czas przebywania: 2 h w każdej temperaturze).

Można przeprowadzić skrócony zestaw badań (spośród tych zdefiniowanych w sekcji 3 niniejszej tabeli) w niższej temperaturze, wyższej temperaturze i w czasie cykli temperaturowych.

213

4.2

Wilgotność

Sprawdzenie odporności przyrządu rejestrującego na cykliczne zmiany wilgotności (próba gorąca) za pomocą próby wg normy IEC 60068-2-30, w sześciu 24-godzinnych cyklach, w każdym ze zmieniającą się temperaturą od +25 °C do +55 °C i wilgotnością względną 97 % w temperaturze +25 °C i 93 % w temperaturze +55 °C

214

4.3

M/echanika

Drgania harmoniczne:

sprawdzenie odporności przyrządu rejestrującego na drgania harmoniczne o następujących właściwościach:

stałe przemieszczenie przy częstotliwości 5–11 Hz: 10-milimetrowa amplituda;

stałe przyspieszenie przy częstotliwości 11–300 Hz: 5g.

Wymóg ten sprawdza się za pomocą próby Fc wg normy IEC 60068-2-6, z minimalnym czasem trwania próby 3 × 12 h (12 h na oś).

ISO 16750-3 nie wymaga przeprowadzenia badania drgań harmonicznych w przypadku urządzeń znajdujących się w oddzielnej kabinie pojazdu.

Drgania swobodne:

Próba zgodnie z normą ISO 16750-3: Rozdział 4.1.2.8: Próba VIII: Pojazd użytkowy, oddzielna kabina pojazdu.

Próba drgań swobodnych: 10...2000 Hz, wertykalna średnia kwadratowa 21,3 m/s2, wzdłużna średnia kwadratowa 11,8 m/s2, poprzeczna średnia kwadratowa 13,1 m/s2, 3 osie, 32 h na oś, w tym cykl temperaturowy -20...70 °C.

Badanie to odnosi się do normy IEC 60068-2-64: Badania środowiskowe – Część 2-64: Próby – Próba Fh: Wibracje szerokopasmowe losowe i wytyczne

3.	Udary: udar mechaniczny przy impulsie półsinusoidalnym 3 g wg normy ISO 16750.

Opisane powyżej badania przeprowadza się na różnych próbkach urządzeń poddawanych badaniom.

219

4.4

Ochrona przed wodą i ciałami obcymi

Badanie zgodnie z normą ISO 20653: Pojazdy drogowe – Stopień ochrony (kod IP) – Ochrona urządzeń elektrycznych przed ciałami obcymi, wodą i dostępem (bez zmian parametrów); minimalna wartość IP – 40

220, 221

4.5

Zabezpieczenie nadnapięciowe

Sprawdzenie odporności przyrządu rejestrującego na napięcie zasilania:

wersje 24 V	:	34 V przy +40 °C przez 1 godzinę
wersje 12 V	:	17 V przy +40 °C przez 1 godzinę

(ISO 16750-2)

216

4.6

Zabezpieczenie przed odwróceniem polaryzacji

Sprawdzenie odporności przyrządu rejestrującego na odwrócenie biegunów napięcia zasilającego.

(ISO 16750-2)

216

4.7

Zabezpieczenie zwarciowe

Sprawdzenie, czy sygnały wyjściowe są zabezpieczone przed zwarciem do napięcia zasilającego i do masy.

(ISO 16750-2)

216

Badania EMC

5.1

Emisje radiacyjne i wrażliwość na radiację

Zgodność z regulaminem nr 10 EKG ONZ

218

5.2

Wyładowania elektrostatyczne

Zgodność z normą ISO 10605:2008 +

Sprostowanie techniczne:2010 +

AMD1:2014: +/- 4kV w przypadku styku i +/- 8kV w przypadku rozładowania do powietrza

218

5.3

Wrażliwość na stany nieustalone w zasilaniu

W przypadku wersji 24 V: zgodność z normą ISO 7637-2 i wersją 3 regulaminu nr 10 EKG ONZ:

impuls 1a: Vs = -450 V, Ri = 50 omów

impuls 2a: Vs = +37 V, Ri = 2 omy

impuls 2b: Vs = +20 V, Ri = 0,05 oma

impuls 3a: Vs = -150 V, Ri = 50 omów

impuls 3b: Vs = +150 V, Ri = 50 omów

impuls 4: Vs = -16 V Va = -12V, t6 = 100ms

impuls 5: Vs = +120 V, Ri = 2,2 oma, td = 250 ms

W przypadku wersji 12V: zgodność z normą ISO 7637-1 i wersją 3 regulaminu nr 10 EKG ONZ:

impuls 1: Vs = -75 V, Ri = 10 omów

impuls 2a: Vs = +37 V, Ri = 2 omy

impuls 2b: Vs = +10 V, Ri = 0,05 oma

impuls 3a: Vs = -112 V, Ri = 50 omów

impuls 3b: Vs = +75 V, Ri = 50 omów

impuls 4: Vs = -6 V, Va = -5 V, t6 = 15 ms

impuls 5: Vs = +65 V, Ri = 3 omy, td = 100 ms

Impuls 5 należy testować tylko w przypadku przyrządów rejestrujących przeznaczonych do zainstalowania w pojazdach, w których nie zainstalowano zewnętrznego, wspólnego zabezpieczenia przed spadkiem obciążenia.

Aby uzyskać informacje na temat propozycji zabezpieczenia przed spadkiem obciążenia, zob. norma ISO 16750-2 wydanie 4, rozdział 4.6.4.

218”

pkt 6 otrzymuje brzmienie:

„6. BADANIE ZEWNĘTRZNEGO URZĄDZENIA DO ŁĄCZNOŚCI NA ODLEGŁOŚĆ”;

Badanie

Opis

Powiązane wymogi

Badanie administracyjne

1.1

Dokumentacja

Prawidłowość dokumentacji

Kontrola wizualna

2.1.

Zgodność z dokumentacją

2.2.

Identyfikacja/oznakowanie

225, 226

2.3

Materiały

219–223

Badania funkcjonalności

3.1

Łączność na odległość na potrzeby ukierunkowanych kontroli drogowych

4, 197–199

3.2

Rejestrowanie i przechowywanie w pamięci danych

3.3

Łączność z przyrządem rejestrującym

Dodatek 14 pozycje DSC_66–DSC_70, DSC_71–DSC_76

Badania środowiskowe

4.1

Temperatura

Sprawdzenie funkcjonalności za pomocą:

badania zgodnie z normą ISO 16750-4, rozdział 5.1.1.2: Próba eksploatacyjna w niskiej temperaturze (72 h w temperaturze -20 °C).

Badanie to odnosi się do normy IEC 60068-2-1: Badania środowiskowe – Część 2-1: Próby – Próba A: Zimno

Badanie zgodnie z normą ISO 16750-4: Rozdział 5.1.2.2: Próba eksploatacyjna w wysokiej temperaturze (72 h w temperaturze 70 °C).

Badanie to odnosi się do normy IEC 60068-2-2: Podstawowe procedury badań środowiskowych – Część 2: Próby – Próba B: Suche gorąco;

Badanie zgodnie z normą ISO 16750-4: Rozdział 5.3.2: Nagła zmiana temperatury z określonym okresem przejściowym (-20 °C/70 °C, 20 cykli, czas przebywania: 1 h w każdej temperaturze).

Można przeprowadzić skrócony zestaw badań (spośród tych zdefiniowanych w sekcji 3 niniejszej tabeli) w niższej temperaturze, wyższej temperaturze i w czasie cykli temperaturowych.

213

4.2

Ochrona przed wodą i ciałami obcymi

Badanie zgodnie z normą ISO 20653: Pojazdy drogowe – Stopień ochrony (kod IP) – Ochrona urządzeń elektrycznych przed ciałami obcymi, wodą i dostępem (wartość docelowa IP40)

220, 221

Badania EMC

5.1

Emisje radiacyjne i wrażliwość na radiację

Zgodność z regulaminem nr 10 EKG ONZ

218

5.2

Wyładowania elektrostatyczne

Zgodność z normą ISO 10605:2008 + Sprostowanie techniczne: 2010 + AMD1:2014: +/- 4kV w przypadku styku i +/- 8kV w przypadku rozładowania do powietrza

218

5.3

Wrażliwość na stany nieustalone w zasilaniu

W przypadku wersji 24 V: zgodność z normą ISO 7637-2 i wersją 3 regulaminu nr 10 EKG ONZ:

impuls 1a: Vs = -450 V, Ri = 50 omów

impuls 2a: Vs = +37 V, Ri = 2 omy

impuls 2b: Vs = +20 V, Ri = 0,05 oma

impuls 3a: Vs = -150 V, Ri = 50 omów

impuls 3b: Vs = +150 V, Ri = 50 omów

impuls 4: Vs = -16 V, Va = -12V, t6 = 100 ms

impuls 5: Vs = +120 V, Ri = 2,2 oma, td = 250 ms

W przypadku wersji 12 V: zgodność z normą ISO 7637-1 i wersją 3 regulaminu nr 10 EKG ONZ:

impuls 1: Vs = -75 V, Ri = 10 omów

impuls 2a: Vs = +37 V, Ri = 2 omy

impuls 2b: Vs = +10 V, Ri = 0,05 oma

impuls 3a: Vs = -112 V, Ri = 50 omów

impuls 3b: Vs = +75 V, Ri = 50 omów

impuls 4: Vs = -6 V, Va = -5 V, t6 = 15 ms

impuls 5: Vs = +65 V, Ri = 3 omy, td = 100 ms

Aby uzyskać informacje na temat propozycji zabezpieczenia przed spadkiem obciążenia, zob. norma ISO 16750-2 wydanie 4, rozdział 4.6.4.

218”

tabela w pkt 8 dotycząca badań interoperacyjności otrzymuje brzmienie:

„Nr	Badanie	Opis
8.1 Badania interoperacyjności między przyrządami rejestrującymi a kartami do tachografu
1	Wzajemne uwierzytelnienie	Sprawdzenie, czy wzajemne uwierzytelnienie między przyrządem rejestrującym a kartą do tachografu przebiega normalnie.
2	Próby zapisu/odczytu	Wykonanie scenariusza typowej czynności na przyrządzie rejestrującym. Scenariusz dostosowany jest do typu badanej karty i obejmuje zapis na karcie tak wielu EF, jak to możliwe. Sprawdzenie poprzez pobieranie danych z przyrządu rejestrującego, czy wszystkie odpowiednie zapisy zostały wykonane prawidłowo. Sprawdzenie poprzez pobieranie danych z karty, czy wszystkie odpowiednie zapisy zostały wykonane prawidłowo. Sprawdzenie poprzez dzienny wydruk z karty, czy wszystkie odpowiednie zapisy mogą być odczytane prawidłowo.
8.2 Badania interoperacyjności między przyrządami rejestrującymi a czujnikami ruchu
1	Parowanie	Sprawdzenie, czy parowanie przyrządu rejestrującego z czujnikami ruchu przebiega normalnie.
2	Badania czynności	Wykonanie scenariusza typowej czynności na czujniku ruchu. Scenariusz obejmuje normalną czynność i wygenerowanie jak największej liczby zdarzeń lub usterek. Sprawdzenie poprzez pobieranie danych z przyrządu rejestrującego, czy wszystkie odpowiednie zapisy zostały wykonane prawidłowo. Sprawdzenie poprzez pobieranie danych z karty, czy wszystkie odpowiednie zapisy zostały wykonane prawidłowo. Sprawdzenie poprzez dzienny wydruk, czy wszystkie odpowiednie zapisy mogą być odczytane prawidłowo.
8.3 Badania interoperacyjności między przyrządami rejestrującymi a urządzeniem zewnętrznym GNSS (w stosownych przypadkach)
1	Wzajemne uwierzytelnienie	Sprawdzenie, czy wzajemne uwierzytelnienie (połączenie) między przyrządem rejestrującym a zewnętrznym modułem GNSS przebiega normalnie.
2	Badania czynności	Wykonanie scenariusza typowej czynności na zewnętrznym urządzeniu GNSS. Scenariusz obejmuje normalną czynność i wygenerowanie jak największej liczby zdarzeń lub usterek. Sprawdzenie poprzez pobieranie danych z przyrządu rejestrującego, czy wszystkie odpowiednie zapisy zostały wykonane prawidłowo. Sprawdzenie poprzez pobieranie danych z karty, czy wszystkie odpowiednie zapisy zostały wykonane prawidłowo. Sprawdzenie poprzez dzienny wydruk, czy wszystkie odpowiednie zapisy mogą być odczytane prawidłowo.”

36)

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

pkt 8.2.3 pozycja CSM_49 otrzymuje brzmienie:

„CSM_49

Przyrządy rejestrujące, karty do tachografu i urządzenia zewnętrzne GNSS obsługują algorytmy SHA-256, SHA-384 i SHA-512 określone w [SHS].”;

pkt 9.1.2 pozycja CSM_58 akapit pierwszy otrzymuje brzmienie:

„CSM_58

Ilekroć ERCA generuje nową parę europejskich kluczy głównych, tworzy certyfikat łączący dla nowego europejskiego klucza publicznego i podpisuje go za pomocą poprzedniego europejskiego klucza prywatnego. Okres ważności certyfikatu łączy wynosi 17 lat i 3 miesiące. Przedstawiono to również na rys. 1 w sekcji 9.1.7.”;

pkt 9.1.4 pozycja CSM_72 otrzymuje brzmienie:

„CSM_72

Dla każdego przyrządu rejestrującego generuje się dwie unikatowe pary kluczy ECC oznaczone jako VU_MA i VU_Sign. Zadanie to realizują producenci VU. Ilekroć generowana jest para kluczy VU, organ generujący klucz przekazuje klucz publiczny swojemu MSCA, aby uzyskać powiązany certyfikat VU podpisany przez MSCA. Klucz prywatny może być używany wyłącznie przez przyrząd rejestrujący.”;

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

(i)

pozycja CSM_83 otrzymuje brzmienie:

„CSM_83

Dla każdej karty do tachografu generuje się jedną unikatową parę kluczy ECC oznaczoną jako Card_MA. Dla każdej karty kierowcy i karty warsztatowej generuje się dodatkowo drugą unikatową parę kluczy ECC oznaczoną jako Card_Sign. Zadanie to mogą realizować producenci kart lub instytucje dokonujące personalizacji kart. Ilekroć generowana jest para kluczy karty, organ generujący klucz przekazuje klucz publiczny swojemu MSCA, aby uzyskać powiązany certyfikat karty podpisany przez MSCA. Klucz prywatny może być używany wyłącznie przez kartę do tachografu.”;

(ii)

pozycja CSM_88 otrzymuje brzmienie:

„CSM_88

Okres ważności certyfikatu Card_MA wynosi:

—	w przypadku kart kierowcy: 5 lat,

—	w przypadku kart firmowych: 5 lat,

—	w przypadku kart kontrolnych: 2 lata,

—	w przypadku kart warsztatowych: 1 rok.”;

(iii)

w pozycji CSM_91 dodaje się tekst w brzmieniu:

„—

Dodatkowo tylko w przypadku kart kontrolnych, kart firmowych i kart warsztatowych i tylko jeżeli takie karty zostały wydane w ciągu pierwszych trzech miesięcy okresu ważności nowego certyfikatu EUR: certyfikat EUR starszy o dwie generacje, jeżeli występuje.

Uwaga do tiret ostatniego: Przykładowo w pierwszych trzech miesiącach certyfikatu ERCA(3) (zob. rys. 1) wspomniane karty zawierają certyfikat ERCA(1). Uwzględnienie certyfikatu ERCA(1) jest konieczne w celu zapewnienia możliwości używania tych kart na potrzeby pobierania danych z przyrządów rejestrujących, których normalny okres użyteczności wynoszący 15 lat plus trzy miesiące okresu pobierania danych upływa w ciągu tych miesięcy; zob. tiret ostatnie wymogu 13 w załączniku IC.”;

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

(i)

pozycja CSM_93 otrzymuje brzmienie:

„CSM_93

Dla każdego urządzenia zewnętrznego GNSS generuje się jedną unikatową parę kluczy ECC oznaczoną jako EGF_MA. Zadanie to realizują producenci urządzeń zewnętrznych GNSS. Ilekroć generowana jest para kluczy EGF_MA, organ generujący klucz przekazuje klucz publiczny swojemu MSCA, aby uzyskać powiązany certyfikat EGF_MA podpisany przez MSCA. Klucz prywatny może być używany wyłącznie przez urządzenie zewnętrzne GNSS.”;

(ii)

pozycja CSM_95 otrzymuje brzmienie:

„CSM_95

Urządzenie zewnętrzne GNSS używa swojej pary kluczy EGF_MA, w której skład wchodzi klucz prywatny EGF_MA.SK i klucz publiczny EGF_MA.PK, wyłącznie do wzajemnego uwierzytelniania i uzgadniania klucza sesji w stosunku do przyrządów rejestrujących, jak określono w sekcji 11.4 niniejszego dodatku.”;

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

(i)

rys. 1 zastępuje się następującym rysunkiem:

„ Rysunek 1

Wydawanie i używanie różnych generacji certyfikatów głównych ERCA, certyfikatów łączących ERCA, certyfikatów MSCA i certyfikatów urządzeń

Tekst z obrazka ”

(ii)

pkt 6 w uwagach do rys. 1 otrzymuje brzmienie:

„6.	aby zaoszczędzić miejsce, różnica w okresie ważności certyfikatów Card_MA i Card_Sign została podana wyłącznie dla certyfikatów pierwszej generacji.”;

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

(i)

pozycja CSM_106 tiret pierwsze otrzymuje brzmienie:

„—	w odniesieniu do 128-bitowych kluczy głównych czujnika ruchu: CV = »B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83«”;

(ii)

pozycja CSM_107 akapit pierwszy otrzymuje brzmienie:

„Każdy producent czujników ruchu generuje losowy i unikatowy klucz parowania KP dla każdego czujnika ruchu i przesyła każdy klucz parowania organowi certyfikacji państwa członkowskiego (MSCA). MSCA szyfruje każdy klucz parowania oddzielnie za pomocą klucza głównego czujnika ruchu KM i zwraca zaszyfrowany klucz producentowi czujników ruchu. W przypadku każdego zaszyfrowanego klucza MSCA powiadamia producenta czujników ruchu o numerze wersji powiązanego KM.”;

(iii)

pozycja CSM_108 otrzymuje brzmienie:

„CSM_108

Każdy producent czujników ruchu generuje unikatowy numer seryjny dla każdego czujnika ruchu i przesyła wszystkie numery seryjne swojemu organowi certyfikacji państwa członkowskiego. MSCA szyfruje każdy numer seryjny oddzielnie za pomocą klucza identyfikacyjnego KID i zwraca zaszyfrowany numer seryjny producentowi czujników ruchu. W przypadku każdego zaszyfrowanego numeru seryjnego MSCA powiadamia producenta czujników ruchu o numerze wersji powiązanego KID.”;

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

(i)

pozycja CSM_123 otrzymuje brzmienie:

„CSM_123

W odniesieniu do każdego przyrządu rejestrującego producent takiego przyrządu tworzy unikatowy numer seryjny VU i przesyła taki numer swojemu organowi certyfikacji państwa członkowskiego we wniosku w celu uzyskania zestawu dwóch kluczy DSRC specyficznych dla VU. Numer seryjny VU posiada typ danych VuSerialNumber.

Uwaga:

—	Taki numer seryjny VU musi być identyczny z elementem vuSerialNumber w VuIdentification (zob. dodatek 1) i z odniesieniem do posiadacza certyfikatu w certyfikatach VU.

—

Numer seryjny VU może nie być znany w momencie żądania przez producenta przyrządu rejestrującego kluczy DSRC specyficznych dla VU. W takim przypadku producent VU wysyła zastępczo unikatowy identyfikator wniosku o certyfikat, którego użył, występując o certyfikaty VU. zob. CSM_153; Taki identyfikator wniosku o certyfikat musi być zatem identyczny z odniesieniem do posiadacza certyfikatu w certyfikatach VU.”;

(ii)	w pozycji CSM_124 wymóg dotyczący informacji w kroku 2 otrzymuje brzmienie: „info = numer seryjny VU lub identyfikator wniosku o certyfikat, jak określono w CSM_123”;

(iii)

pozycja CSM_128 otrzymuje brzmienie:

„CSM_128

MSCA prowadzi rejestry wszystkich wygenerowanych kluczy DSRC specyficznych dla VU, ich numerów wersji i numerów seryjnych VU lub identyfikatorów wniosku o certyfikat wykorzystanych w celu ich wyprowadzenia.”;

pkt 9.3.1 pozycja CSM_135 akapit pierwszy otrzymuje brzmienie:

„Wyróżnione reguły kodowania (DER) zgodnie z [normą ISO 8825-1] wykorzystuje się do kodowania obiektów danych w ramach certyfikatów. W tabeli 4 przedstawiono pełne kodowanie świadectw, z uwzględnieniem wszystkich bajtów znaczników i długości.”;

w pkt 9.3.2.3 pozycja CSM_141 otrzymuje brzmienie:

„CSM_141

Upoważnienie posiadacza certyfikatu służy do identyfikowania rodzaju certyfikatu. Składa się ono z sześciu najbardziej znaczących bajtów identyfikatora aplikacji tachograficznej, połączonych z typem urządzenia, który wskazuje typ urządzenia, dla którego certyfikat jest przeznaczony. W przypadku certyfikatu VU, certyfikatu karty kierowcy lub certyfikatu karty warsztatowej typu urządzenia używa się również w celu rozróżnienia świadectwa wzajemnego uwierzytelnienia i certyfikatu na potrzeby tworzenia podpisu cyfrowego (zob. pkt 9.1 i dodatek 1, typ danych EquipmentType).”;

w pkt 9.3.2.5 w pozycji CSM_146 dodaje się następujący akapit:

„ Uwaga: W przypadku certyfikatu karty wartość CHR musi być równa wartości cardExtendedSerialNumber w EF_ICC; zob. dodatek 2. W przypadku certyfikatu EGF wartość CHR musi być równa wartości sensorGNSSSerialNumber w EF_ICC; zob. dodatek 14. W przypadku certyfikatu VU wartość CHR musi być równa elementowi vuSerialNumber w VuIdentification (zob. dodatek 1), chyba że producent nie zna specyficznego dla danego producenta numeru seryjnego, w momencie gdy wystąpiono o certyfikat.”;

pkt 9.3.2.6 pozycja CSM_148 otrzymuje brzmienie:

„CSM_148

Data wejścia w życie certyfikatu określa datę i godzinę rozpoczęcia okresu ważności certyfikatu.”;

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

(i)	pozycja CSM_151 akapit pierwszy otrzymuje brzmienie: Składając wniosek o certyfikat, MSCA przesyła ERCA następujące dane:

(ii)

pozycja CSM_153 otrzymuje brzmienie:

„CSM_153

Producent urządzenia przesyła MSCA następujące dane we wniosku o certyfikat, co umożliwi MSCA utworzenie odniesienia do posiadacza certyfikatu dla nowego certyfikatu urządzenia:

—	numer seryjny urządzenia, unikalny dla producenta, typu urządzenia i miesiąc wyprodukowania, jeżeli dane te są znane (zob. CSM_154). W przeciwnym razie – unikatowy identyfikator wniosku o certyfikat,

—	miesiąc i rok produkcji urządzenia lub miesiąc i rok sporządzenia wniosku o certyfikat.

Producent zapewnia, aby przedmiotowe dane były prawidłowe, a certyfikat zwrócony przez MSCA został umieszczony w przewidzianym urządzeniu.”;

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

(i)

w pozycji CSM_157 tekst przed uwagami do rys. 4 otrzymuje brzmienie:

„Przyrządy rejestrujące używają protokołu przedstawionego na rys. 4 w celu weryfikacji łańcucha certyfikatów karty do tachografu. Dla każdego certyfikatu odczytywanego z karty przyrząd rejestrujący weryfikuje prawidłowość pola Upoważnienie Posiadacza Certyfikatu (CHA):

—	Pole CHA certyfikatu karty wskazuje certyfikat karty na potrzeby wzajemnego uwierzytelnienia (zob. dodatek 1, typ danych EquipmentType).

—	CHA certyfikatu Card.CA musi wskazywać MSCA.

—	CHA certyfikatu Card.Link musi wskazywać ERCA.”;

(ii)	w pozycji CSM_159 dodaje się zdanie w brzmieniu: „Zważywszy że przechowywanie wszystkich pozostałych typów certyfikatu jest fakultatywne, VU musi przechowywać nowy certyfikat łączący przedstawiony przez kartę.”;

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

(i)

w pozycji CSM_161 tekst przed rys. 5 otrzymuje brzmienie:

„Karty do tachografu używają protokołu przedstawionego na rys. 5 w celu weryfikacji łańcucha certyfikatów VU. Dla każdego certyfikatu przedstawionego przez przyrząd rejestrujący karta weryfikuje prawidłowość pola Upoważnienie Posiadacza Certyfikatu (CHA):

—	CHA certyfikatu VU.Link musi wskazywać ERCA.

—	CHA certyfikatu VU.CA musi wskazywać MSCA.

—	Pole CHA certyfikatu VU wskazuje certyfikat VU na potrzeby wzajemnego uwierzytelnienia (zob. dodatek 1, typ danych EquipmentType).”;

(ii)

pozycja CSM_165 otrzymuje brzmienie:

„CSM_165

Jeżeli polecenie MSE: Set AT jest skuteczne, karta ustawia wskazany VU.PK w celu późniejszego użycia podczas uwierzytelnienia przyrządu rejestrującego i tymczasowo zapisuje Comp(VU.PKeph). W przypadku wysłania co najmniej dwóch skutecznych poleceń MSE: Set AT przed uzgodnieniem klucza sesji karta zapisuje tylko ostatni otrzymany Comp(VU.PKeph). Karta zeruje Comp(VU.PKeph) po skutecznym poleceniu GENERAL AUTHENTICATE.”;

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

(i)	pozycja CSM_170 akapit pierwszy otrzymuje brzmienie: „Oprócz żądania karty VU umieszcza w podpisie odniesienie do posiadacza certyfikatu uzyskane z certyfikatu karty.”;

(ii)	w pkt CSM_171 rys. 6 otrzymuje brzmienie: „ Rysunek 6 Protokół uwierzytelniania VU ”

(iii)

pozycja CSM_174 otrzymuje brzmienie:

„CSM_174

Po otrzymaniu podpisu VU w poleceniu EXTERNAL AUTHENTICATE karta:

—	oblicza token uwierzytelniania poprzez połączenie Card.CHR, żądania karty rcard i identyfikatora efemerycznego klucza publicznego VU Comp(VU.PKeph);

—	weryfikuje podpis VU za pomocą algorytmu ECDSA, używając algorytmu skrótu powiązanego z wielkością pary kluczy VU VU_MA, jak określono w CSM_50, w połączeniu z VU.PK i obliczonym tokenem uwierzytelniania.”;

w pkt 10.4 pozycja CSM_176 wprowadza się następujące zmiany:

(i)

ppkt 2 otrzymuje brzmienie:

„2.

VU przesyła karcie punkt publiczny VU.PKeph swojej pary kluczy efemerycznych. Punkt publiczny przekształca się w ciąg oktetowy, jak określono w [TR-03111]. Stosuje się nieskompresowany format kodowania. Jak wyjaśniono w CSM_164, VU wygenerował tę parę kluczy efemerycznych przed zweryfikowaniem łańcucha certyfikatów VU. VU przesłał karcie identyfikator efemerycznego klucza publicznego Comp(VU.PKeph) i karta zapisuje ten identyfikator”;

(ii)

ppkt 6 otrzymuje brzmienie:

„6.	za pomocą KMAC, karta oblicza token uwierzytelniania w odniesieniu do identyfikatora efemerycznego punktu publicznego VU: TPICC = CMAC(KMAC, VU.PKeph). Punkt publiczny musi być w formacie używanym przez VU (zob. ppkt 2 powyżej). Karta wysyła NPICC i TPICC do przyrządu rejestrującego.”;

w pkt 10.5.2 pozycja CSM_191 otrzymuje brzmienie:

„CSM_191

Każdy obiekt danych wymagający zaszyfrowania wypełnia się zgodnie z [ISO 7816-4] przy użyciu wskaźnika treści wypełnienia »01«. Na potrzeby obliczenia MAC obiekty danych w APDU wypełnia się również zgodnie z [ISO 7816-4].

Uwaga: wypełnianie na potrzeby bezpiecznej wymiany komunikatów zawsze przeprowadza się za pomocą warstwy bezpiecznej wymiany komunikatów, a nie algorytmów CMAC czy CBC.

Podsumowanie i przykłady

Polecenie APDU z zastosowaniem bezpiecznej wymiany komunikatów będzie miało następującą strukturę w zależności od przypadku odpowiadającego mu niezabezpieczonego polecenia (»DO« oznacza obiekt danych):

Przypadek 1	:	CLA INS P1 P2 \|\| Lc' \|\| DO »8E« \|\| Le
Przypadek 2	:	CLA INS P1 P2 \|\| Lc' \|\| DO »97« \|\| DO »8E« \|\| Le
Przypadek 3 (parzysty bajt INS)	:	CLA INS P1 P2 \|\| Lc' \|\| DO »81« \|\| DO »8E« \|\| Le
Przypadek 3 (nieparzysty bajt INS)	:	CLA INS P1 P2 \|\| Lc' \|\| DO »B3« \|\| DO »8E« \|\| Le
Przypadek 4 (parzysty bajt INS)	:	CLA INS P1 P2 \|\| Lc' \|\| DO »81« \|\| DO »97« \|\| DO »8E« \|\| Le
Przypadek 4 (nieparzysty bajt INS)	:	CLA INS P1 P2 \|\| Lc' \|\| DO »B3« \|\| DO »97« \|\| DO »8E« \|\| Le

gdzie Le = »00« albo »00 00« w zależności od tego, czy stosuje się krótkie długości pól czy rozszerzone długości pól; zob. [ISO 7816-4].

Odpowiedź APDU z zastosowaniem bezpiecznej wymiany komunikatów będzie miała następującą strukturę w zależności od przypadku odpowiadającej mu niezabezpieczonej odpowiedzi:

Przypadek 1 lub 3	:	DO »99« \|\| DO »8E« \|\| SW1SW2
Przypadek 2 lub 4 (parzysty bajt INS) bez szyfrowania	:	DO »81« \|\| DO »99« \|\| DO »8E« \|\| SW1SW2
Przypadek 2 lub 4 (parzysty bajt INS) z szyfrowaniem	:	DO »87« \|\| DO »99« \|\| DO »8E« \|\| SW1SW2
Przypadek 2 lub 4 (nieparzysty bajt INS) bez szyfrowania2	:	DO »B3« \|\| DO »99« \|\| DO »8E« \|\| SW1SW

Uwaga: przypadków 2 lub 4 (nieparzysty bajt INS) z szyfrowaniem nigdy nie stosuje się w łączności między VU a kartą.

Poniżej przedstawiono trzy przykłady przekształceń APDU w odniesieniu do poleceń z parzystym kodem INS. Rys. 8 przedstawia uwierzytelnione polecenie APDU określone w przypadku 4, rys. 9 przedstawia uwierzytelnioną odpowiedź APDU określoną w przypadku 1 / przypadku 3, a rys. 10 przedstawia zaszyfrowaną i uwierzytelnioną odpowiedź APDU określoną w przypadku 2/4.

Rysunek 8

Przekształcenie uwierzytelnionego polecenia APDU określonego w przypadku 4

Rysunek 9

Przekształcenie uwierzytelnionej odpowiedzi APDU określonej w przypadku 1/ przypadku 3

Rysunek 10

Przekształcenie zaszyfrowanej i uwierzytelnionej odpowiedzi APDU określonej w przypadku 2/ przypadku 4

”

w pkt 10.5.3 pozycja CSM_193 otrzymuje brzmienie:

„CSM_193

Karta do tachografu przerywa trwającą sesję bezpiecznej wymiany komunikatów tylko i wyłącznie wówczas, gdy zaistnieje jeden z poniższych warunków:

—	karta otrzyma odkryte polecenie APDU,

—

karta wykryje błąd bezpiecznej wymiany komunikatów w poleceniu APDU:

—	brak oczekiwanego obiektu danych bezpiecznej wymiany komunikatów, nieprawidłową kolejność obiektów danych lub uwzględnienie nieznanego obiektu danych,

—	nieprawidłowy obiekt danych bezpiecznej wymiany komunikatów, np. nieprawidłowa wartość MAC lub nieprawidłowa struktura TLV;

—	karta straci zasilanie lub zostanie zresetowana;

—	VU rozpocznie proces uwierzytelniania VU;

—

osiągnięty zostanie limit dotyczący liczby poleceń i powiązanych odpowiedzi w ramach bieżącej sesji. W odniesieniu do danej karty limit ten określa producent, uwzględniając wymogi bezpieczeństwa dotyczące używanego sprzętu, przy czym maksymalna liczba poleceń i powiązanych odpowiedzi w ramach bezpiecznej wymiany komunikatów wynosi 240 w każdej sesji.”;

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

(i)	pozycja CSM_208 akapit pierwszy otrzymuje brzmienie: „Podczas ustanawiania powiązania z VU urządzenie zewnętrzne GNSS używa protokołu przedstawionego na rys. 5 (sekcja 10.2.2) w celu weryfikacji łańcucha certyfikatów VU.”;

(ii)

pozycja CSM_210 otrzymuje brzmienie:

„CSM_210

Po zweryfikowaniu certyfikatu VU_MA urządzenie zewnętrzne GNSS przechowuje ten certyfikat do wykorzystania w czasie normalnej pracy; zob. sekcja 11.3.3.”;

pkt 11.3.3 pozycja CSM_211 akapit pierwszy otrzymuje brzmienie:

„W czasie normalnej pracy przyrząd rejestrujący i EGF używają protokołu wskazanego na rys. 11 w celu weryfikacji czasowej ważności przechowywanych certyfikatu EGF_MA oraz do celów ustalenia klucza publicznego VU_MA na potrzeby późniejszego uwierzytelnienia VU. W czasie normalnej pracy nie odbywa się dalsza wzajemna weryfikacja łańcuchów certyfikatów.”;

tabela 6 w pkt 12.3 otrzymuje brzmienie:

„Tabela 6

Liczba bajtów danych zwykłego tekstu i danych zaszyfrowanych zgodnie z instrukcją określoną w [ISO 16844-3]

Instrukcja	Żądanie / odpowiedź	Opis danych	Liczba bajtów danych zwykłego tekstu zgodnie z [ISO 16844-3]	Liczba bajtów danych zwykłego tekstu przy użyciu kluczy AES	Liczba bajtów zaszyfrowanych danych przy użyciu kluczy AES o długości w bitach
Instrukcja	Żądanie / odpowiedź	Opis danych		Liczba bajtów danych zwykłego tekstu przy użyciu kluczy AES	128	192	256
10	żądanie	Dane uwierzytelniania + numer pliku	8	8	16	16	16
11	odpowiedź	Dane uwierzytelniania + zawartość pliku	16 lub 32 w zależności od pliku	16 lub 32 w zależności od pliku	32 / 48	32 / 48	32 / 48
41	żądanie	Numer seryjny czujnika ruchu	8	8	16	16	16
41	odpowiedź	Klucz parowania	16	16 / 24 / 32	16	32	32
42	żądanie	Klucz sesji	16	16 / 24 / 32	16	32	32
43	żądanie	Informacje o parowaniu	24	24	32	32	32
50	odpowiedź	Informacje o parowaniu	24	24	32	32	32
70	żądanie	Dane uwierzytelniania	8	8	16	16	16
80	odpowiedź	Wartość licznika czujnika ruchu + dane uwierzytelniania	8	8	16	16	16”

w pkt 13.1 wymóg dotyczący numeru seryjnego VU w pozycji CSM_224 otrzymuje brzmienie:

„numeru seryjnego VU

tj. numeru seryjnego VU lub identyfikatora wniosku o certyfikat (typ danych VuSerialNumber lub CertificateRequestID) – zob. CSM_123”;

w pkt 13.3 pozycja CSM_228 ppkt 2 otrzymuje brzmienie:

„2.	karta kontrolna stosuje wskazany klucz główny DSRC w połączeniu z numerem seryjnym VU lub identyfikatorem wniosku o certyfikat zawartym w danych zabezpieczających DSRC w celu wyprowadzenia specyficznych dla VU kluczy DSRC K_VUDSRC_ENC i K_VUDSRC_MAC, jak określono w CSM_124;”;

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

(i)

w pozycji CSM_234 tekst przed uwagami do rys. 13 otrzymuje brzmienie:

„IDE może samodzielnie przeprowadzać weryfikację podpisu złożonego w odniesieniu do pobranych danych lub może do tego celu używać karty kontrolnej. W przypadku używania karty kontrolnej weryfikacja podpisów odbywa się zgodnie ze schematem przedstawionym na rysunku 13. W celu zweryfikowania czasowej ważności certyfikatu przedstawionego przez IDE karta kontrolna używa swojego wewnętrznego czasu bieżącego, jak określono w pozycji CSM_167. Karta kontrolna aktualizuje swój czas bieżący, jeżeli data wejścia w życie autentycznego certyfikatu będącego »wiarygodnym źródłem czasu« jest późniejsza niż czas bieżący określony na karcie. Za wiarygodne źródło czasu karta uznaje wyłącznie następujące certyfikaty:

—	certyfikaty łączące ERCA drugiej generacji,

—	certyfikaty MSCA drugiej generacji,

—	certyfikaty VU_Sign lub Card_Sign drugiej generacji wydane przez to samo państwo, które wydało certyfikat własny karty kontrolnej.

W przypadku gdy urządzenie samodzielnie przeprowadza weryfikację podpisy, IDE weryfikuje autentyczność i ważność wszystkich certyfikatów w łańcuchu certyfikatów w pliku danych oraz weryfikuje podpis złożony w stosunku do danych według schematu podpisu określonego w [DSS]. W obu przypadkach dla każdego certyfikatu odczytywanego z pliku danych konieczne jest sprawdzenie prawidłowości pola Upoważnienie Posiadacza Certyfikatu (CHA):

—	Pole CHA certyfikatu EQT wskazuje certyfikat VU lub karty (odpowiednio do przypadku) na potrzeby podpisu (zob. dodatek 1, typ danych EquipmentType).

—	CHA certyfikatu EQT.CA musi wskazywać MSCA.

—	CHA certyfikatu EQT.Link musi wskazywać ERCA.”;

(ii)	rys. 13 zastępuje się następującym rysunkiem: „ Rysunek 13 Protokół weryfikacji podpisu złożonego w odniesieniu do pobranego pliku danych ”

37)

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

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

(i)

w pozycji GNS_4 akapit drugi po rys. 2 otrzymuje brzmienie:

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

(ii)

punkt GNS_5 otrzymuje brzmienie:

„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 aktywnych satelitów) w celu ustalenia i zarejestrowania gotowości i dokładności sygnału. W szczególności HDOP stosuje się w celu wskazania poziomu dokładności zarejestrowanych danych dotyczących lokalizacji (zob. pkt 4.2.2). VU będzie przechowywał wartość poziomego rozmycia dokładności (HDOP) obliczaną jako minimum wartości HDOP zgromadzonych w dostępnych systemach GNSS.

Identyfikator GNSS wskazuje odpowiedni identyfikator NMEA dla każdej konstelacji GNSS i systemu wspomagającego opartego na wyposażeniu satelitarnym SBAS.

Rysunek 3

Struktura komunikatu GSA

”

(iii)

pozycja GNS_6 otrzymuje brzmienie:

„GNS_6

Komunikat GSA przechowuje się z numerem rekordu »02«–»06«.”;

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

(i)

pozycja GNS_16 otrzymuje brzmienie:

„GNS_16

W protokole łączności nie są obsługiwane pola o rozszerzonej długości.”;

(ii)

pozycja GNS_18 otrzymuje brzmienie:

„GNS_18

Jeżeli chodzi o funkcje: 1) gromadzenia i rozpowszechniania danych GNSS; 2) gromadzenia danych dotyczących konfiguracji urządzenia zewnętrznego GNSS; oraz 3) protokołu zarządzania, bezpieczny nadajnik-odbiornik GNSS symuluje inteligentną kartę za pomocą architektury systemu plików składającej się z pliku głównego (MF), pliku dedykowanego (DF) z identyfikatorem aplikacji określonym w dodatku 1 rozdział 6.2 (»FF 44 54 45 47 4D«) i z trzema plikami elementarnymi (EF) zawierającymi certyfikaty oraz jednego pojedynczego pliku elementarnego (EF.EGF) z identyfikatorem pliku równym »2F2F«, jak opisano w tabeli 1.”;

(iii)

pozycja GNS_20 otrzymuje brzmienie:

„GNS_20

Bezpieczny nadajnik-odbiornik GNSS używa pamięci do przechowywania danych i jest w stanie przeprowadzić co najmniej 20 milionów cyklów zapisu/odczytu. Poza tym aspektem o konstrukcji wewnętrznej i wdrażaniu bezpiecznego nadajnika-odbiornika GNSS decydują producenci.

Mapowanie numerów rekordów i danych przedstawiono w tabeli 1. Należy zauważyć, że istnieje pięć komunikatów GSA dotyczących konstelacji GNSS i systemu wspomagającego opartego na wyposażeniu satelitarnym SBAS.”;

w pkt 4.2.2 pozycja GNS_23 ppkt 5 otrzymuje brzmienie:

„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 położenie jest prawidłowe. Jeżeli położenie nie jest prawidłowe, dane dotyczące lokalizacji nie są jeszcze dostępne i nie można ich wykorzystać w celu zarejestrowania położenia pojazdu. Jeżeli położenie jest prawidłowe, procesor VU wyodrębnia również wartości HDOP z komunikatów NMEA GSA i oblicza minimalną wartość w stosunku do dostępnych systemów satelitarnych (tj. jeżeli ustalenie położenia jest możliwe).”;

w pkt 4.4.1 pozycja GNS_28 otrzymuje brzmienie:

„GNS_28

Jeżeli VU nie uda się nawiązać połączenia z powiązanym urządzeniem zewnętrznym GNSS przez dłużej niż 20 minut ciągłej pracy, przyrząd ten generuje i rejestruje zdarzenie typu »EventFaultType« z wartością enum »0E«H Błąd komunikacji z urządzeniem zewnętrznym GNSS oraz ze znacznikiem czasu ustawionym na bieżącą godzinę. Zdarzenie zostanie wygenerowane, wyłącznie jeżeli spełnione będą następujące dwa warunki: a) tachograf inteligentny nie znajduje się w trybie kalibracyjnym; oraz b) pojazd jest w ruchu. W tym kontekście występuje błąd połączenia, gdy bezpieczny nadajnik-odbiornik VU nie otrzyma komunikatu odpowiedzi po wysłaniu komunikatu żądania, jak opisano w pkt 4.2.”;

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 kasuje całą swoją pamięć, w tym materiał kryptograficzny. Jak opisano w GNS_25 i GNS_26, VU wykrywa manipulowanie, jeżeli odpowiedź ma status »6690«. Następnie VU generuje zdarzenie typu »EventFaultType« z wartością enum »19«H Wykrywanie manipulowania GNSS. Urządzenie zewnętrzne GNSS nie może już również odpowiadać na żadne żądania zewnętrzne.”;

w pkt 4.4.3 pozycja GNS_30 otrzymuje brzmienie:

„GNS_30

Jeżeli bezpieczny nadajnik-odbiornik GNSS nie otrzymuje danych z odbiornika GNSS przez dłużej niż 3 godziny ciągłej pracy, urządzenie to generuje komunikat odpowiedzi na polecenie READ RECORD z numerem rekordu »01« i polem danych o rozmiarze 12 bajtów, wszystkich ustawionych na 0xFF. Po otrzymaniu komunikatu odpowiedzi z określoną wartością pola danych VU generuje i rejestruje zdarzenie typu »EventFaultType« z wartością enum »0D«H Brak informacji o pozycji z odbiornika GNSS ze znacznikiem czasu o bieżącej wartości czasu, wyłącznie jeżeli spełnione będą następujące dwa warunki: a) tachograf inteligentny nie znajduje się w trybie kalibracyjnym; oraz b) pojazd jest w ruchu.”;

w pkt 4.4.4 tekst w pozycji GNS_31 aż do rys. 4 otrzymuje brzmienie:

„Jeżeli VU wykryje, że certyfikat EGF wykorzystywany do celów wzajemnego uwierzytelniania stracił ważność, przyrząd rejestrujący generuje i rejestruje zdarzenie przyrządu rejestrującego typu »EventFaultType« z wartością enum »1B«H Wygaśnięcie certyfikatu urządzenia zewnętrznego GNSS ze znacznikiem czasu o bieżącej wartości czasu. VU nadal wykorzystuje otrzymane dane GNSS o położeniu.”;

w pkt 5.2.1 pozycja GNS_34 otrzymuje brzmienie:

»GNS_34

Jeżeli VU nie otrzymuje danych z odbiornika GNSS przez dłużej niż 3 godziny ciągłej pracy, przyrząd ten generuje i rejestruje zdarzenie typu »EventFaultType« z wartością enum »0D«H Brak informacji o pozycji z odbiornika GNSS ze znacznikiem czasu o bieżącej wartości czasu, wyłącznie jeżeli spełnione będą następujące dwa warunki: a) tachograf inteligentny nie znajduje się w trybie kalibracyjnym; oraz b) pojazd jest w ruchu.«;

pkt 6 otrzymuje brzmienie:

„6. KONFLIKT CZASOWY GNSS

Jeżeli VU wykryje rozbieżność wynoszącą ponad 1 minutę między czasem funkcji pomiaru czasu przyrządu rejestrującego a czasem z odbiornika GNSS, przyrząd rejestrujący zarejestruje zdarzenie typu „EventFaultType” z wartością enum »0B«H Konflikt czasowy (między GNSS a wewnętrznym zegarem VU). Po wywołaniu zdarzenia dotyczącego konfliktu czasowego VU nie weryfikuje rozbieżności czasu przez następne 12 godzin. Wydarzenie to nie uruchamia się, jeżeli odbiornik GNSS nie wykrywał prawidłowego sygnału GNSS w ciągu ostatnich 30 dni.”;

38)

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

w pkt 2 akapit czwarty otrzymuje brzmienie:

„W tym miejscu należy wyjaśnić, że w niniejszym dodatku nie określa się:

—	operacji gromadzenia danych i zarządzania tym procesem w ramach VU (co jest określone w innym miejscu w rozporządzeniu lub w przeciwnym razie stanowi funkcję projektu produktu);

—	formy przedstawienia zgromadzonych danych w aplikacji zainstalowanej na urządzeniu zewnętrznym;

—	przepisów dotyczących bezpieczeństwa danych wykraczających poza zabezpieczenia zapewniane przez Bluetooth® (takie jak szyfrowanie) w odniesieniu do treści danych (które zostaną określone w innym miejscu w rozporządzeniu [dodatek 11 »Wspólne mechanizmy zabezpieczenia«]);

—	protokołów Bluetooth® wykorzystywanych przez interfejs ITS.”;

w pkt 4.2 akapit trzeci otrzymuje brzmienie:

„W momencie gdy urządzenie zewnętrzne pojawi się po raz pierwszy w zakresie działania VU, można rozpocząć proces parowania Bluetooth® (zob. również załącznik 2). Urządzenia wymieniają adresy, nazwy, profile i wspólny klucz tajny, co pozwala im się łączyć, ilekroć znajdą się w pobliżu siebie w przyszłości. Po zakończeniu tego etapu urządzenie zewnętrzne uzyskuje status urządzenia zaufanego i jest w stanie inicjować żądania pobrania danych z tachografu. Nie przewiduje się możliwości dodawania mechanizmów szyfrowania poza mechanizmami zapewnianymi przez Bluetooth®. Jeżeli jednak dodatkowe mechanizmy zabezpieczeń są konieczne, zostaną one dodane zgodnie z dodatkiem 11 »Wspólne mechanizmy zabezpieczenia«.”;

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

(i)

akapit pierwszy otrzymuje brzmienie:

„Ze względów bezpieczeństwa VU będzie wymagał systemu autoryzacji za pomocą kodu PIN działającego oddzielnie od systemu parowania Bluetooth. Każdy VU musi być w stanie generować kody PIN służące do uwierzytelniania, składające się z co najmniej 4 cyfr. Za każdym razem gdy urządzenie zewnętrzne paruje się z VU, musi wprowadzić poprawny kod PIN, zanim otrzyma jakiekolwiek dane.”;

(ii)	akapit trzeci po tabeli 1 otrzymuje brzmienie: „Podczas gdy producent może zapewnić możliwość zmiany kodu PIN bezpośrednio przez VU, kodu PUC nie można zmienić. Zmiana kodu PIN, o ile jest możliwa, wymaga wprowadzenia obecnego kodu PIN bezpośrednio w VU.”;

w pkt 4.4 akapit drugi po nagłówku »Pole danych« otrzymuje brzmienie:

„Jeżeli dane, które mają być obsługiwane, są większe niż miejsce dostępne w jednym komunikacie, zostaną podzielone na kilka podkomunikatów. Każdy podkomunikat ma taki sam nagłówek i SID, ale zawiera dwubajtowy licznik, bieżący licznik (Counter Current, CC) i maksymalny licznik (Counter Max, CM), w celu wskazania numeru podkomunikatu. Aby umożliwić kontrolę błędów i przerwanie przesyłania, urządzenie przyjmujące zatwierdza każdy podkomunikat. Urządzenie przyjmujące może przyjąć podkomunikat, zażądać ponownego przesłania podkomunikatu, zażądać od urządzenia wysyłającego ponownego rozpoczęcia transmisji lub jej przerwania.”;

w załączniku 1 wprowadza się następujące zmiany:

(i)	tytuł otrzymuje brzmienie: „1) WYKAZ DANYCH DOSTĘPNYCH ZA POŚREDNICTWEM INTERFEJSU ITS”;

(ii)

w tabeli w pkt 3 po pozycji „Brak informacji o położeniu z odbiornika GNSS” dodaje się pozycję w brzmieniu:

„Błąd połączenia z urządzeniem zewnętrznym GNSS

—	najdłuższe zdarzenie 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 pod koniec zdarzenia,

—	liczba podobnych zdarzeń w tym dniu.”

(iii)

w pkt 5 dodaje się tiret w brzmieniu:

„—	usterka interfejsu ITS (w stosownych przypadkach).”;

w specyfikacjach ASN.1 w załączniku 3 wprowadza się następujące zmiany:

(i)	po wierszu 206 dodaje się wiersze 206a–206e w brzmieniu: „ Tekst z obrazka ”206a 206b DriverID ::= SEQUENCE{ 206c issuingMemberState OCTET STRING (SIZE(3)), 206d cardNumber OCTET STRING (SIZE(16)) 206e }”; ”

(ii)	wiersze 262–264 otrzymują brzmienie: „ Tekst z obrazka „262 driveRecognize BIT STRING ('00'B UNION '01'B), 263 driverCardDriver1 BIT STRING ('00'B UNION '01'B), 264 driverCardDriver2 BIT STRING ('00'B UNION '01'B), ”; ”

(iii)

wiersz 275 otrzymuje brzmienie:

„

Tekst z obrazka ”

(iv)

wiersze 288–310 otrzymują brzmienie:

„

Tekst z obrazka ”

(v)	wiersze 362 i 363 otrzymują brzmienie: „ Tekst z obrazka „362 driver1MaximumDailyDrivingTime BIT STRING (SIZE(4)), 363 driver2MaximumDailyDrivingTime BIT STRING (SIZE(4)),”; ”

(vi)	po wierszu 410 dodaje się wiersze 410a i 410b w brzmieniu: „ Tekst z obrazka „410a comErrorWithExternalGNSSFacility 410b CommunicationErrorWithTheExternalGNSSFacility,”; ”

(vii)

po wierszu 539 dodaje się wiersze 539a–539j w brzmieniu:

„

Tekst z obrazka ”

39)

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

a)	pkt 5.5 w spisie treści otrzymuje brzmienie: „5.5 Wsparcie wdrażania dyrektywy (UE) 2015/719 … 490”;

w pkt 2 akapit trzeci otrzymuje brzmienie:

„W takim przypadku czas dostępny na nawiązanie łączności jest ograniczony, ponieważ łączność ma ukierunkowany charakter i cechuje się krótkim zasięgiem. Ponadto właściwe organy kontrolne mogą korzystać ze środków łączności wykorzystywanych do celów zdalnego monitorowania tachografu również do innych celów (np. do przekazywania informacji dotyczących maksymalnych obciążeń i wymiarów pojazdów ciężarowych określonych w dyrektywie (UE) 2015/719), przy czym działania w tym zakresie mogą być podejmowane oddzielnie lub sekwencyjnie według uznania właściwych organów kontrolnych.”;

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

(i)

pozycja DSC_19 tiret dwunaste otrzymuje brzmienie:

„—

antenę DSRC-VU umieszcza się w miejscu, w którym zapewnia optymalną łączność DSRC między pojazdem a anteną drogową czytnika, w przypadku gdy czytnik został zainstalowany w odległości 15 m z przodu pojazdu i na wysokości 2 m, możliwie blisko środkowej części szyby w poziomie i w pionie. W przypadku pojazdów lekkich odpowiednie jest zainstalowanie anteny w górnej części szyby przedniej W przypadku pozostałych pojazdów antenę DSRC należy zamontować w pobliżu dolnej albo górnej części szyby przedniej.”;

(ii)

pozycja DSC_22 akapit pierwszy otrzymuje brzmienie:

„Współczynnik kształtu anteny nie został zdefiniowany i stanowi przedmiot decyzji handlowej, dopóki wbudowany DSRC-VU spełnia wymagania zgodności określone w sekcji 5 poniżej. Antena jest umieszczona w miejscu określonym w DSC_19 i skutecznie wspomaga przypadki wykorzystania opisane w pkt 4.1.2 i 4.1.3.”;

w pkt 5.4.3 sekwencja 7 otrzymuje brzmienie:

„7

REDCR

DSRC-VU

Wysyła GET.request w odniesieniu do danych innego Atrybutu (w razie potrzeby)”;

w pkt 5.4.4 w definicji modułu ASN.1 w pozycji DCS_40 wprowadza się następujące zmiany:

(i)	wiersz pierwszy sekwencji dla otrzymuje brzmienie: „ Tekst z obrazka „tp15638VehicleRegistrationPlate LPN – Vehicle Registration Plate as per EN 155091” ”

(ii)

dodaje się przypis 1 w brzmieniu:

„1.	Jeżeli LPN zawiera AlphabetIndicator LatinAlphabetNo2 lub latinCyrillicAlphabet, znaki specjalne są ponownie mapowane w urządzeniu interrogatora drogowego przy zastosowaniu specjalnych przepisów zgodnie z załącznikiem E do normy ISO/DIS 14 906,2.”;

(iii)

usuwa się cyfrę 2 w górnym indeksie z wiersza, w którym zdefiniowano znacznik czasu bieżącego rekordu (Timestamp of current record);

(iv)	definicja modułu ASN.1 dla otrzymuje brzmienie: „ Tekst z obrazka „RtmTransferAck ::= INTEGER { Ok (1), NoK (2) } (1..255)”; ”

w pkt 5.4.5 pozycja RTM12 w tabeli 14.3 otrzymuje brzmienie:

„RTM12

Usterka czujnika

VU generuje wartość w postaci liczby całkowitej w odniesieniu do elementu danych RTM12.

VU przypisuje zmiennej sensorFault wartość:

—	1 w przypadku zarejestrowania w ciągu ostatnich 10 dni zdarzenia typu »35H« związanego z usterką czujnika,

—	2 w przypadku zarejestrowania w ciągu ostatnich 10 dni typu zdarzenia związanego z usterką odbiornika GNSS (wewnętrznego albo zewnętrznego, o wartości enum»36«H lub »37« H);

—	3 w przypadku zarejestrowania w ciągu ostatnich 10 dni zdarzenia typu »0E«H związanego z błędem łączności z urządzeniem zewnętrznym GNSS;

—	4 w przypadku zarejestrowania w ciągu ostatnich 10 dni zarówno usterki czujnika, jak i usterki odbiornika GNSS;

—	5 w przypadku zarejestrowania w ciągu ostatnich 10 dni zarówno zdarzenia typu usterka czujnika, jak i błąd łączności z urządzeniem zewnętrznym GNSS;

—	6 w przypadku zarejestrowania w ciągu ostatnich 10 dni zarówno zdarzenia typu usterka odbiornika GNSS, jaki i błąd łączności z urządzeniem zewnętrznym GNSS;

—	7 w przypadku zarejestrowania w ciągu ostatnich 10 dni występowania wszystkich trzech usterek czujnika, W PRZECIWNYM WYPADKU przypisuje wartość 0, jeżeli w ciągu ostatnich 10 dni nie zarejestrowano żadnych zdarzeń.

— usterka czujnika jeden oktet zgodnie ze słownikiem danych

”

pkt 5.4.6 pozycja DSC_43 otrzymuje brzmienie:

„DSC_43

Wszystkie dane wymieniane w ramach DSRC koduje się przy użyciu reguł PER (Packed Encoding Rules) UNALIGNED, z wyjątkiem

oraz

, które koduje się przy użyciu reguł OER (Octet Encoding Rules) zdefiniowanych w normie ISO/IEC 8825-7, Rec. ITU-T X.696.”;

w pkt 5.4.7 w kolumnie czwartej w tabeli 14.9 tekst w rubryce opisującej

otrzymuje brzmienie:

„Identyfikator obiektu obsługiwanej normy, części i wersji. Przykład: ISO (1) norma (0) TARV (15638) część 9 (9) wersja 1 (1).

Wartość pierwszego oktetu to 06H i stanowi identyfikator obiektu. Wartość drugiego oktetu to 06H i stanowi jego długość. Kolejne 6 oktetów koduje przykładowy identyfikator obiektu.”;

pkt 5.5 i 5.5.1 otrzymują brzmienie:

„5.5. Wsparcie wdrażania dyrektywy (UE) 2015/719

5.5.1. Przegląd

DSC_59

W celu wsparcia wdrażania dyrektywy (UE) 2015/719 w sprawie maksymalnych obciążeń i wymiarów pojazdów ciężarowych protokół transakcji służący do pobierania danych OWS za pośrednictwem połączenia interfejsu DSRC działającego na częstotliwości 5,8 GHz będzie taki sam jak protokół używany do przekazywania danych dotyczących zdalnego monitorowania tachografu (zob. 5.4.1) – jedyna różnica polega na tym, że identyfikator obiektu odnoszący się do normy TARV będzie odnosił się do części 20 normy ISO 15638 (TARV) dotyczącej systemów ważenia w pojeździe.”;

pkt 5.6.1 pozycja DSC_68 lit. a) otrzymuje brzmienie:

„a)	aby można było zawierać umowy z różnymi dostawcami na dostawę VU i DSRC-VU oraz w praktyce różnych serii DSRC-VU, połączenie między VU a DSRC-VU niebędącym elementem wewnętrznym VU musi być otwartym połączeniem standardowym. VU musi być połączony z DSRC-VU za pomocą:”;

pkt 5.7.1 pozycja DSC_77 otrzymuje brzmienie:

„DSC_77

Już zabezpieczone dane są przekazywane DSRC-VU za pomocą funkcji VUSM. VUSM sprawdza, czy dane zarejestrowane w DSRC-VU zostały poprawnie zarejestrowane. 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.”;

40)

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

pkt 2.2 akapit pierwszy otrzymuje brzmienie:

„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 drugiej generacji są interoperacyjne z przyrządami rejestrującymi drugiej generacji zgodnie z załącznikiem IC do niniejszego rozporządzenia. Ponadto zastosowanie mają przedstawione poniżej wymogi.”;

w pkt 2.4.1 pozycja MIG_011 wprowadza się następujące zmiany:

(i)

tiret pierwsze otrzymuje brzmienie:

„—	niepodpisane pliki elementarne IC i ICC (fakultatywnie),”;

(ii)

tiret trzecie otrzymuje brzmienie:

„—	pliki elementarne zawierające inne dane aplikacyjne (w pliku DF Tachograph) żądane przez protokół pobierania danych z kart pierwszej generacji. Informacje takie są 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) drugiej generacji (pliki elementarne zawierające dane aplikacyjne w pliku DF Tachograph_G2).”;

w pkt 2.4.3 pozycje MIG_014 i MIG_015 otrzymują brzmienie:

„MIG_014

Poza ramami kontroli kierowców przez organ kontrolny spoza UE dane z przyrządów rejestrujących drugiej generacji są pobierane z zastosowaniem mechanizmów zabezpieczenia drugiej generacji i protokołu pobierania danych określonego w dodatku 7 do niniejszego załącznika.

MIG_015

Aby organy kontrolne spoza UE mogły kontrolować kierowców, opcjonalnie można również umożliwić pobieranie danych z przyrządów rejestrujących 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.”.