Rozporządzenie wykonawcze 2016/799 w sprawie wykonania rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 165/2014 ustanawiającego wymogi dotyczące budowy, sprawdzania, instalacji, użytkowania i naprawy tachografów oraz ich elementów składowych
Dz.U.UE.L.2016.139.1
Akt obowiązującyROZPORZĄDZENIE WYKONAWCZE KOMISJI (UE) 2016/799
z dnia 18 marca 2016 r.
w sprawie wykonania rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 165/2014 ustanawiającego wymogi dotyczące budowy, sprawdzania, instalacji, użytkowania i naprawy tachografów oraz ich elementów składowych
(Tekst mający znaczenie dla EOG)
uwzględniając Traktat o funkcjonowaniu Unii Europejskiej,
uwzględniając rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 165/2014 z dnia 4 lutego 2014 r. w sprawie tachografów stosowanych w transporcie drogowym 1 , w szczególności jego art. 11 i art. 12 ust. 7,
(1) Rozporządzeniem (UE) nr 165/2014 wprowadzono tzw. drugą generację tachografów cyfrowych (tzw. tachografów inteligentnych), które obejmują połączenie z urządzeniem GNSS (globalny system nawigacji satelitarnej), urządzenie wczesnego wykrywania na odległość oraz interfejs do inteligentnych systemów transportowych. Należy ustanowić specyfikacje dotyczące wymogów technicznych w zakresie budowy tachografów inteligentnych.
(2) Urządzenie wczesnego wykrywania na odległość, przewidziane na mocy art. 9 ust. 4 rozporządzenia (UE) nr 165/2014, powinno przekazywać funkcjonariuszowi kontroli drogowej dane z tachografu cyfrowego oraz informacje dotyczące mas oraz masy przypadającej na osie całego zespołu pojazdów (ciągnika i przyczep lub naczep), zgodnie z dyrektywą 96/53/WE Parlamentu Europejskiego i Rady 2 . Powinno to umożliwić skuteczną i szybką kontrolę pojazdów przez organy kontrolne, przy zmniejszeniu liczby urządzeń elektronicznych w kabinie pojazdu.
(3) Zgodnie z dyrektywą 96/53/WE, w przypadku urządzenia wczesnego wykrywania na odległość należy stosować normy CEN DSRC 3 , o których mowa we wspomnianej dyrektywie, w zakresie częstotliwości 5795-5805 MHz. Ponieważ ten zakres częstotliwości jest wykorzystywany również na potrzeby elektronicznych systemów pobierania opłat, a także w celu uniknięcia zakłóceń między aplikacjami służącymi do pobierania i kontroli opłat drogowych, funkcjonariusze służb kontrolnych nie powinni używać urządzenia wczesnego wykrywania na odległość na placu poboru opłat.
(4) Należy wprowadzić w tachografie inteligentnym nowe mechanizmy zabezpieczeń na potrzeby utrzymania poziomu bezpieczeństwa tachografu cyfrowego, aby wyeliminować obecne luki w zakresie bezpieczeństwa. Jednym z takich zagrożeń jest brak daty ważności certyfikatów cyfrowych. W celu uwzględnienia najlepszych praktyk w dziedzinie bezpieczeństwa zaleca się unikanie stosowania certyfikatów cyfrowych bez dat ważności. Okres ważności normalnie użytkowanych przyrządów rejestrujących powinien wynosić 15 lat, licząc od dnia wystawienia certyfikatu cyfrowego przyrządu rejestrującego. Przyrządy rejestrujące powinny być wymieniane po upływie tego okresu ważności.
(5) Zapewnienie bezpiecznych i wiarygodnych informacji o położeniu jest niezbędnym elementem skutecznego działania tachografów inteligentnych. Dlatego też należy zapewnić ich kompatybilność z usługami dodanymi oferowanymi przez program Galileo, określonymi w rozporządzeniu Parlamentu Europejskiego i Rady (UE) nr 1285/2013 4 , aby poprawić bezpieczeństwo tachografów inteligentnych.
(6) Zgodnie z art. 8 ust. 1, art. 9 ust. 1 oraz art. 10 ust. 1 i 2 rozporządzenia (UE) nr 165/2014, stosowanie mechanizmów zabezpieczających wprowadzonych przez to rozporządzenie powinno rozpocząć się po 36 miesiącach od wejścia w życie niezbędnych aktów wykonawczych, aby umożliwić producentom opracowanie nowej generacji tachografów inteligentnych oraz uzyskanie świadectw homologacji typu od właściwych organów.
(7) Zgodnie z rozporządzeniem (UE) nr 165/2014, pojazdy zarejestrowane po raz pierwszy w państwie członkowskim po upływie 36 miesięcy od wejścia w życie niniejszego rozporządzenia Komisji, powinny być wyposażone w tachograf inteligentny spełniający jego wymogi. W każdym przypadku wszystkie pojazdy użytkowane w państwie członkowskim innym niż ich państwo członkowskie rejestracji powinny zostać wyposażone w tachograf inteligentny spełniający wymogi w ciągu 15 lat od daty rozpoczęcia stosowania tych wymogów.
(8) Rozporządzeniem Komisji (WE) nr 68/2009 5 zezwolono na stosowanie - w okresie przejściowym upływającym dnia 31 grudnia 2013 r. - adaptera, aby umożliwić instalowanie tachografów w pojazdach kategorii M1 i N1. Biorąc pod uwagę trudności techniczne związane z poszukiwaniem rozwiązania alternatywnego dla stosowania adaptera, eksperci z sektora motoryzacji i tachografów wraz z Komisją stwierdzili, że żadne alternatywne rozwiązanie dla adaptera nie jest wykonalne bez poniesienia przez branżę wysokich kosztów, które byłyby nieproporcjonalne do rozmiaru rynku. W związku z tym należy bezterminowo dopuścić stosowanie adapterów w pojazdach kategorii M1 i N1.
(9) Środki przewidziane w niniejszym rozporządzeniu są zgodne z opinią komitetu, o którym mowa w art. 42 ust. 3 rozporządzenia (UE) nr 165/2014,
PRZYJMUJE NINIEJSZE ROZPORZĄDZENIE:
Przedmiot i zakres stosowania
Definicje
Do celów niniejszego rozporządzenia zastosowanie mają definicje zawarte w art. 2 rozporządzenia (UE) nr 165/2014.
Zastosowanie mają ponadto następujące definicje:
Może to być pojedyncza jednostka lub kilka jednostek rozmieszczonych w pojeździe, składających się z jednostki przetwarzającej, pamięci danych, funkcji pomiaru czasu, dwóch czytników kart inteligentnych (dla kierowcy i współkierowcy), drukarki, wyświetlacza, złącz i urządzeń do wprowadzania danych przez użytkownika, odbiornika GNSS i urządzenia do łączności na odległość.
Przyrząd rejestrujący może się składać z następujących elementów składowych podlegających homologacji typu:
Jeżeli przyrząd rejestrujący składa się z kilku jednostek rozmieszczonych w pojeździe, jednostką główną przyrządu rejestrującego jest jednostka zawierająca jednostkę przetwarzającą, pamięć danych i funkcję pomiaru czasu.
Określenie "przyrząd rejestrujący" stosuje się w odniesieniu do "przyrządu rejestrującego" lub "jednostki głównej przyrządu rejestrującego".
Usługi w zakresie lokalizacji
Procedura homologacji typu tachografu i elementów składowych tachografu
Modyfikacje homologacji typu
"Rewizja" ma miejsce, jeżeli organ udzielający homologacji typu uzna, że modyfikacje oprogramowania lub sprzętu tachografu, bądź rodzaju materiałów użytych do jego produkcji, są niewielkie. W takich przypadkach organ udzielający homologacji typu wydaje zrewidowane dokumenty pakietu informacyjnego, wskazując rodzaj dokonanych modyfikacji i datę ich zatwierdzenia. Zaktualizowana wersja pakietu informacyjnego w formie skonsolidowanej, której towarzyszy szczegółowy opis dokonanych modyfikacji, jest wystarczająca do spełnienia tego wymogu.
"Rozszerzenie" ma miejsce, jeżeli organ udzielający homologacji typu uzna, że modyfikacje oprogramowania lub sprzętu tachografu, bądź rodzaju materiałów użytych do jego produkcji, są istotne. W takich przypadkach Komisja może zwrócić się o przeprowadzenie nowych badań i poinformować o tym odpowiednio producenta lub jego upoważnionego przedstawiciela. Jeśli wyniki tych badań okażą się zadowalające, organ udzielający homologacji typu wydaje zrewidowane świadectwo homologacji typu, które zawiera numer odnoszący się do udzielonego rozszerzenia. Świadectwo homologacji typu wskazuje powód rozszerzenia oraz datę jego wydania.
Wejście w życie
Niniejsze rozporządzenie wchodzi w życie dwudziestego dnia po jego opublikowaniu w Dzienniku Urzędowym Unii Europejskiej.
Niniejsze rozporządzenie stosuje się od dnia 2 marca 2016 r.
Załącznik IC stosuje się jednak od dnia 15 czerwca 2019 r., z wyjątkiem dodatku 16, który stosuje się od dnia 2 marca 2016 r.
| W imieniu Komisji | |
| Jean-Claude JUNCKER | |
| Przewodniczący |
ZAŁĄCZNIK IC 16
Wymagania w zakresie budowy, badań, instalacji i kontroli
Wymagania w zakresie budowy, badań, instalacji i kontroli
1 DEFINICJE ...............................................................................................................
2 CHARAKTERYSTYKA OGÓLNA I FUNKCJE URZĄDZEŃ REJESTRUJĄCYCH ......................................................
2.1 Charakterystyka ogólna ..............................................................................................
2.2 Funkcje ......................................................................................................................
2.3 Tryby pracy ................................................................................................................
2.4 Zabezpieczenia ...........................................................................................................
3 WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE URZĄDZEŃ REJESTRUJĄCYCH .....................................
3.1 Monitorowanie wkładania i wyjmowania kart ..............................................................
3.2 Pomiar prędkości, pozycji i odległości .........................................................................
3.2.1 Pomiar przebytej drogi ................................................................................................
3.2.2 Pomiar prędkości .......................................................................................................
3.2.3 Pomiar pozycji ............................................................................................................
3.3 Pomiar czasu ..............................................................................................................
3.4 Monitorowanie czynności kierowcy .............................................................................
3.5 Monitorowanie stanu prowadzenia pojazdu .................................................................
3.6 Dane wprowadzane przez kierowców .........................................................................
3.6.1 Wprowadzanie miejsca rozpoczęcia lub zakończenia okresu pracy ..............................
3.6.2 Ręczne wprowadzanie czynności kierowcy i zgoda kierowcy na interfejs ITS ...............
3.6.3 Wprowadzanie warunków szczególnych ......................................................................
3.6.4 Wprowadzanie operacji załadunku/rozładunku
3.7 Zarządzanie blokadami firmowymi ...............................................................................
3.8 Monitorowanie czynności kontrolnych .........................................................................
3.9 Wykrywanie zdarzeń lub usterek .................................................................................
3.9.1 Zdarzenie "włożenie nieważnej karty" ..........................................................................
3.9.2 Zdarzenie "konflikt kart" ..............................................................................................
3.9.3 Zdarzenie "nakładające się czasy" ................................................................................
3.9.4 Zdarzenie "prowadzenie pojazdu bez prawidłowej karty" .............................................
3.9.5 Zdarzenie "włożenie karty podczas prowadzenia pojazdu" ...........................................
3.9.6 Zdarzenie "Sesja ostatniej karty niezamknięta prawidłowo" ..........................................
3.9.7 Zdarzenie "przekroczenie prędkości" ...........................................................................
3.9.8 Zdarzenie "przerwa w zasilaniu" ...................................................................................
3.9.9 Zdarzenie "błąd połączenia z urządzeniem do łączności na odległość" ...........................
3.9.10 Zdarzenie "brak informacji o pozycji z odbiornika GNSS" ...........................................
3.9.11 Zdarzenie "błąd połączenia z urządzeniem zewnętrznym GNSS" ...................................
3.9.12 Zdarzenie "błąd danych dotyczących ruchu" .................................................................
3.9.13 Zdarzenie "konflikt ruchu pojazdu" ..............................................................................
3.9.14 Zdarzenie "próba naruszenia zabezpieczenia" ...............................................................
3.9.15 Zdarzenie "konflikt czasu" ...........................................................................................
3.9.16 Usterka "karta" ...........................................................................................................
3.9.17 Usterka "urządzenie rejestrujące" ................................................................................
3.9.18 Zdarzenie "anomalia GNSS"
3.10 Testy wbudowane i autotesty ......................................................................................
3.11 Odczyt z pamięci danych ............................................................................................
3.12 Rejestracja i przechowywanie w pamięci danych .........................................................
3.12.1 Dane identyfikujące sprzęt ..........................................................................................
3.12.1.1 Dane identyfikujące przyrząd rejestrujący ....................................................................
3.12.1.2 Dane identyfikujące czujnik ruchu ................................................................................
3.12.1.3 Dane identyfikujące globalnego systemu nawigacji satelitarnej ......................................
3.12.2 Klucze i certyfikaty .....................................................................................................
3.12.3 Dane rejestrowane przy wkładaniu i wyjmowaniu karty kierowcy lub warsztatowej ......
3.12.4 Dane dotyczące czynności kierowcy ...........................................................................
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 ....................
3.12.6 Dane dotyczące licznika kilometrów ............................................................................
3.12.7 Dane szczegółowe dotyczące prędkości ......................................................................
3.12.8 Dane dotyczące zdarzeń .............................................................................................
3.12.9 Dane dotyczące usterek ..............................................................................................
3.12.10 Dane kalibracyjne .......................................................................................................
3.12.11 Dane dotyczące korekty czasu ....................................................................................
3.12.12 Dane dotyczące czynności kontrolnych ........................................................................
3.12.13 Dane dotyczące blokad firmowych ..............................................................................
3.12.14 Dane dotyczące pobierania danych .............................................................................
3.12.15 Dane dotyczące warunków szczególnych ....................................................................
3.12.16 Dane karty do tachografu ............................................................................................
3.12.17 Przekroczenia granicy
3.12.18 Operacje załadunku/rozładunku
3.12.19 Mapa cyfrowa
3.13 Odczyt kart do tachografów .......................................................................................
3.14 Rejestrowanie i przechowywanie danych na kartach do tachografów ...........................
3.14.1 Rejestrowanie i przechowywanie danych na kartach do tachografów pierwszej generacji ..............................................................
3.14.2 Rejestrowanie i przechowywanie danych na kartach do tachografów drugiej generacji ..
3.15 Wyświetlanie ..............................................................................................................
3.15.1 Domyślne informacje na wyświetlaczu .........................................................................
3.15.2 Wyświetlanie ostrzeżeń ...............................................................................................
3.15.3 Dostęp do menu .........................................................................................................
3.15.4 Inne wyświetlane informacje ........................................................................................
3.16 Drukowanie ................................................................................................................
3.17 Ostrzeżenia .................................................................................................................
3.18 Pobieranie danych na nośnik zewnętrzny .....................................................................
3.19 Łączność na odległość na potrzeby ukierunkowanych kontroli drogowych ...................
3.20 Wymiana danych z dodatkowymi urządzeniami zewnętrznymi
3.21 Kalibracja ..................................................................................................................
3.22 Kontrola drogowa kalibracji .......................................................................................
3.23 Korekta czasu ............................................................................................................
3.24 Parametry pracy .........................................................................................................
3.25 Materiały ....................................................................................................................
3.26 Oznakowania .............................................................................................................
3.27 Monitorowanie przekroczeń granicy
3.28 Aktualizacja oprogramowania
4 WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE KART DO TACHOGRAFÓW .........................................................
4.1 Dane widzialne ...........................................................................................................
4.2 Zabezpieczenia ...........................................................................................................
4.3 Normy .......................................................................................................................
4.4 Wymagania środowiskowe i elektryczne .....................................................................
4.5 Przechowywanie danych .............................................................................................
4.5.1 Pliki elementarne do identyfikacji i zarządzania kartą ....................................................
4.5.2 Identyfikacja kart mikroprocesorowych ......................................................................
4.5.2.1 Identyfikacja mikroprocesora ......................................................................................
4.5.2.2 DIR (tylko w kartach do tachografów drugiej generacji) ..............................................
4.5.2.3 Informacje ATR (warunkowe, dostępne tylko w kartach do tachografów drugiej generacji) .................................................................
4.5.2.4 Informacje o rozszerzonej długości (warunkowe, dostępne tylko w kartach do tachografów drugiej generacji) ....................................
4.5.3 Karta kierowcy ..........................................................................................................
4.5.3.1 Aplikacja tachograficzna (dostępna dla przyrządów rejestrujących pierwszej i drugiej generacji) ...........................................................
4.5.3.1.1 Identyfikacja aplikacji .................................................................................................
4.5.3.1.2 Klucz i certyfikaty .......................................................................................................
4.5.3.1.3 Identyfikacja karty ......................................................................................................
4.5.3.1.4 Identyfikacja posiadacza karty ....................................................................................
4.5.3.1.5 Pobieranie danych z karty ...........................................................................................
4.5.3.1.6 Dane dotyczące prawa jazdy ......................................................................................
4.5.3.1.7 Dane dotyczące zdarzeń .............................................................................................
4.5.3.1.8 Dane dotyczące usterek ..............................................................................................
4.5.3.1.9 Dane dotyczące czynności kierowcy ...........................................................................
4.5.3.1.10 Dane dotyczące używanych pojazdów ........................................................................
4.5.3.1.11 Miejsca rozpoczęcia lub zakończenia dziennych okresów pracy ...................................
4.5.3.1.12 Dane sesji karty ..........................................................................................................
4.5.3.1.13 Dane dotyczące czynności kontrolnych ........................................................................
4.5.3.1.14 Dane dotyczące warunków szczególnych ....................................................................
4.5.3.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów rejestrujących pierwszej generacji) .....................................................
4.5.3.2.1 Identyfikacja aplikacji .................................................................................................
4.5.3.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.3.2.2 Klucze i certyfikaty .....................................................................................................
4.5.3.2.3 Identyfikacja karty ......................................................................................................
4.5.3.2.4 Identyfikacja posiadacza karty ....................................................................................
4.5.3.2.5 Pobieranie danych z karty ...........................................................................................
4.5.3.2.6 Dane dotyczące prawa jazdy ......................................................................................
4.5.3.2.7 Dane dotyczące zdarzeń .............................................................................................
4.5.3.2.8 Dane dotyczące usterek ..............................................................................................
4.5.3.2.9 Dane dotyczące czynności kierowcy ...........................................................................
4.5.3.2.10 Dane dotyczące używanych pojazdów ........................................................................
4.5.3.2.11 Miejsca i pozycje rozpoczęcia lub zakończenia dziennych okresów pracy ....................
4.5.3.2.12 Dane sesji karty ..........................................................................................................
4.5.3.2.13 Dane dotyczące czynności kontrolnych ........................................................................
4.5.3.2.14 Dane dotyczące warunków szczególnych ....................................................................
4.5.3.2.15 Dane dotyczące używanych przyrządów rejestrujących ................................................
4.5.3.2.16 Dane miejsc, w których minęły trzy godziny skumulowanego czasu prowadzenia pojazdu .......................................................................
4.5.3.2.17 Status uwierzytelniania dla pozycji związanych z miejscami rozpoczęcia lub zakończenia dziennych okresów pracy (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.3.2.18 Status uwierzytelniania dla pozycji, w których osiągnięto trzy godziny skumulowanego czasu prowadzenia pojazdu (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.3.2.19 Przekroczenia granicy (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.3.2.20 Operacje załadunku/rozładunku (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.3.2.21 Wprowadzanie typu załadunku (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.3.2.22 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.4 Karta warsztatowa .....................................................................................................
4.5.4.1 Aplikacja tachograficzna (dostępna dla przyrządów rejestrujących pierwszej i drugiej generacji) .............................................................
4.5.4.1.1 Identyfikacja aplikacji .................................................................................................
4.5.4.1.2 Klucze i certyfikaty .....................................................................................................
4.5.4.1.3 Identyfikacja karty ......................................................................................................
4.5.4.1.4 Identyfikacja posiadacza karty ....................................................................................
4.5.4.1.5 Pobieranie danych z karty ...........................................................................................
4.5.4.1.6 Dane dotyczące kalibracji i korekty czasu ...................................................................
4.5.4.1.7 Dane dotyczące zdarzeń i usterek ................................................................................
4.5.4.1.8 Dane dotyczące czynności kierowcy ...........................................................................
4.5.4.1.9 Dane dotyczące używanych pojazdów ........................................................................
4.5.4.1.10 Dane dotyczące rozpoczęcia lub zakończenia dziennych okresów pracy .......................
4.5.4.1.11 Dane sesji karty ..........................................................................................................
4.5.4.1.12 Dane dotyczące czynności kontrolnych ........................................................................
4.5.4.1.13 Dane dotyczące warunków szczególnych ....................................................................
4.5.4.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów rejestrujących pierwszej generacji) ..................................................
4.5.4.2.1 Identyfikacja aplikacji .................................................................................................
4.5.4.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.4.2.2 Klucze i certyfikaty .....................................................................................................
4.5.4.2.3 Identyfikacja karty ......................................................................................................
4.5.4.2.4 Identyfikacja posiadacza karty ....................................................................................
4.5.4.2.5 Pobieranie danych z karty ...........................................................................................
4.5.4.2.6 Dane dotyczące kalibracji i korekty czasu ...................................................................
4.5.4.2.7 Dane dotyczące zdarzeń i usterek ................................................................................
4.5.4.2.8 Dane dotyczące czynności kierowcy ...........................................................................
4.5.4.2.9 Dane dotyczące używanych pojazdów ........................................................................
4.5.4.2.10 Dane dotyczące rozpoczęcia lub zakończenia dziennych okresów pracy .......................
4.5.4.2.11 Dane sesji karty ..........................................................................................................
4.5.4.2.12 Dane dotyczące czynności kontrolnych ........................................................................
4.5.4.2.13 Dane dotyczące używanych przyrządów rejestrujących ................................................
4.5.4.2.14 Dane miejsc, w których minęły trzy godziny skumulowanego czasu prowadzenia pojazdu .......................................................................
4.5.4.2.15 Dane dotyczące warunków szczególnych ....................................................................
4.5.4.2.16 Status uwierzytelniania dla pozycji związanych z miejscami rozpoczęcia lub zakończenia dziennych okresów pracy (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.4.2.17 Status uwierzytelniania dla pozycji, w których osiągnięto trzy godziny skumulowanego prowadzenia pojazdu (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.4.2.18 Przekroczenia granicy (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.4.2.19 Operacje załadunku/rozładunku (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.4.2.20 Wprowadzanie typu załadunku (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.4.2.21 Dodatkowe dane dotyczące kalibracji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.4.2.22 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.5 Karta kontrolna ..........................................................................................................
4.5.5.1 Aplikacja tachograficzna (dostępna dla przyrządów rejestrujących pierwszej i drugiej generacji) ............................................................
4.5.5.1.1 Identyfikacja aplikacji .................................................................................................
4.5.5.1.2 Klucze i certyfikaty .....................................................................................................
4.5.5.1.3 Identyfikacja karty ......................................................................................................
4.5.5.1.4 Identyfikacja posiadacza karty ....................................................................................
4.5.5.1.5 Dane dotyczące czynności kontrolnych ........................................................................
4.5.5.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów rejestrujących pierwszej generacji).. ..................................................
4.5.5.2.1 Identyfikacja aplikacji .................................................................................................
4.5.5.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.5.2.2 Klucze i certyfikaty .....................................................................................................
4.5.5.2.3 Identyfikacja karty ......................................................................................................
4.5.5.2.4 Identyfikacja posiadacza karty ....................................................................................
4.5.5.2.5 Dane dotyczące czynności kontrolnych ........................................................................
4.5.5.2.6 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.6 Karta firmowa ............................................................................................................
4.5.6.1 Aplikacja tachograficzna (dostępna dla przyrządów rejestrujących pierwszej i drugiej generacji) ...............................................................
4.5.6.1.1 Identyfikacja aplikacji .................................................................................................
4.5.6.1.2 Klucze i certyfikaty .....................................................................................................
4.5.6.1.3 Identyfikacja karty ......................................................................................................
4.5.6.1.4 Identyfikacja posiadacza karty ....................................................................................
4.5.6.1.5 Dane dotyczące czynności wykonywanych przez firmę ................................................
4.5.6.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów rejestrujących pierwszej generacji) .....................................................
4.5.6.2.1 Identyfikacja aplikacji .................................................................................................
4.5.6.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
4.5.6.2.2 Klucze i certyfikaty .....................................................................................................
4.5.6.2.3 Identyfikacja karty ......................................................................................................
4.5.6.2.4 Identyfikacja posiadacza karty ....................................................................................
4.5.6.2.5 Dane dotyczące czynności wykonywanych przez firmę ................................................
4.5.6.2.6 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
5 INSTALACJA URZĄDZENIA REJESTRUJĄCEGO ...............................................
5.1 Instalacja ....................................................................................................................
5.2 Tabliczka instalacyjna .................................................................................................
5.3 Plombowanie ..............................................................................................................
6 KONTROLE, PRZEGLĄDY I NAPRAWY .............................................................
6.1 Zatwierdzanie instalatorów, warsztatów i producentów pojazdów ................................
6.2 Kontrola techniczna elementów składowych nowych i po naprawie ...............................................
6.3 Przegląd instalacyjny ...................................................................................................
6.4 Przeglądy okresowe ...................................................................................................
6.5 Wyznaczanie błędów ..................................................................................................
6.6 Naprawy ....................................................................................................................
7 WYDAWANIE KART ..............................................................................................
8 HOMOLOGACJA TYPU URZĄDZEŃ REJESTRUJĄCYCH I KART DO TACHOGRAFÓW ............................................................
8.1 Uwagi ogólne .............................................................................................................
8.2 Świadectwo bezpieczeństwa .......................................................................................
8.3 Świadectwo funkcjonalności .......................................................................................
8.4 Świadectwo interoperacyjności ...................................................................................
8.5 Świadectwo homologacji typu .....................................................................................
8.6 Procedura szczególna: pierwsze świadectwa interoperacyjności dla urządzeń rejestrujących i kart do tachografów 2. generacji ....................
WPROWADZENIE
Niniejszy załącznik zawiera wymogi dotyczące drugiej generacji urządzeń rejestrujących i kart do tachografów.
Począwszy od dnia 15 czerwca 2019 r., w pojazdach rejestrowanych po raz pierwszy w Unii instaluje się urządzenia rejestrujące drugiej generacji i wydaje się karty do tachografów drugiej generacji.
W celu sprawnego wdrożenia systemu tachografu drugiej generacji, karty do tachografu drugiej generacji zaprojektowano w taki sposób, aby możliwe było ich używanie również w przyrządach rejestrujących pierwszej generacji skonstruowanych zgodnie z załącznikiem IB do rozporządzenia (EWG) nr 3821/85.
Analogicznie karty do tachografu pierwszej generacji mogą być używane w przyrządach rejestrujących drugiej generacji. Przyrządy rejestrujące drugiej generacji mogą być kalibrowane tylko z użyciem kart warsztatowych drugiej generacji.
Wymogi dotyczące interoperacyjności między systemami tachografu pierwszej i drugiej generacji określono w niniejszym załączniku. W tym względzie dodatek 15 zawiera dodatkowe szczegółowe informacje na temat zarządzania kwestią współistnienia obu tych generacji.
Ponadto, w związku z wdrożeniem nowych funkcji, takich jak stosowanie uwierzytelniania komunikatów nawigacyjnych w ramach sygnałów otwartych Galileo, wykrywanie przekroczeń granicy, wpisywanie operacji załadunku i rozładunku, a także ze względu na konieczność zwiększenia pojemności karty kierowcy do 56 dni czynności kierowcy, niniejsze rozporządzenie wprowadza wymogi techniczne dotyczące drugiej wersji drugiej generacji urządzeń rejestrujących i kart do tachografów
Wykaz dodatków
Dodatek 1: SPIS DANYCH
Dodatek 2: SPECYFIKACJA KART DO TACHOGRAFÓW
Dodatek 3: PIKTOGRAMY
Dodatek 4: WYDRUKI
Dodatek 5: WYŚWIETLACZ
Dodatek 6: PRZEDNIE ZŁĄCZE KALIBRACJI I POBIERANIA DANYCH
Dodatek 7: PROTOKOŁY POBIERANIA DANYCH
Dodatek 8: PROTOKÓŁ KALIBRACJI
Dodatek 9: HOMOLOGACJA TYPU I WYKAZ MINIMUM WYMAGANYCH BADAŃ
Dodatek 10: WYMOGI BEZPIECZEŃSTWA
Dodatek 11: WSPÓLNE MECHANIZMY ZABEZPIECZENIA
Dodatek 12: OKREŚLANIE POŁOŻENIA Z WYKORZYSTANIEM GLOBALNEGO SYSTEMU NAWIGACJI SATELITARNEJ (GNSS)
Dodatek 13: INTERFEJS ITS
Dodatek 14: FUNKCJA ŁĄCZNOŚCI NA ODLEGŁOŚĆ
Dodatek 15: MIGRACJA: ZARZĄDZANIE WSPÓŁISTNIENIEM GENERACJI URZĄDZEŃ
Dodatek 16: ADAPTER DO POJAZDÓW KATEGORII M1 I N1
1 DEFINICJE
W niniejszym załączniku:
a) "aktywacja" oznacza:
fazę, gdy tachograf uzyskuje pełną funkcjonalność i uruchamia wszystkie funkcje, łącznie z funkcjami zabezpieczającymi, z wykorzystaniem karty warsztatowej;
b) "uwierzytelnienie" oznacza:
funkcję służącą ustanowieniu i kontroli tożsamości;
c) "autentyczność" oznacza:
właściwość polegającą na tym, że informacje przychodzą od strony, której tożsamość można zweryfikować;
d) "test wbudowany (BIT)"oznacza:
testy wykonywane na żądanie, uruchamiane przez operatora lub urządzenia zewnętrzne;
e) "dzień kalendarzowy" oznacza:
dzień zaczynający się o godzinie 00:00 i kończący o godzinie 24:00. Wszystkie dni kalendarzowe odnoszą się do czasu UTC (uniwersalny czas koordynowany);
f) "kalibracja" tachografu inteligentnego oznacza:
aktualizację lub potwierdzenie parametrów pojazdu przechowywanych w pamięci danych. Parametry pojazdu obejmują identyfikację pojazdu (numery VIN, VRN i kod rejestrującego Stronę) i charakterystyki pojazdu (w, k, l, wielkość opon, ustawienia urządzenia ograniczenia prędkości (w stosownych przypadkach), bieżący czas UTC, bieżący stan licznika kilometrów, domyślny typ załadunku); podczas kalibracji urządzenia rejestrującego w pamięci danych zachowywane są również rodzaje i identyfikatory odpowiednich plomb homologacyjnych;
aktualizację lub potwierdzenie jedynie czasu UTC uważa się za korektę czasu, a nie za kalibrację, pod warunkiem że nie jest to sprzeczne z wymogiem 409 określonym w pkt 6.4;
do kalibracji urządzenia rejestrującego potrzebna jest karta warsztatowa;
g) "numer karty" oznacza:
numer składający się z 16 znaków alfanumerycznych, który jednoznacznie identyfikuje kartę do tachografów w państwie członkowskim. Numer karty zawiera identyfikację, która polega na identyfikacji kierowcy lub identyfikacji właściciela karty wraz z kolejnym numerem karty, numerem wymiany karty i numerem odnowienia karty;
tym samym karta jest jednoznacznie zidentyfikowana przez kod Strony wydającego i numer karty;
h) "numer kolejny karty"oznacza:
14. znak alfanumeryczny w numerze karty, który umożliwia rozróżnianie różnych kart firmie, warsztatowi lub organowi kontrolnemu uprawnionym do otrzymania kilku kart do tachografów. Firmę, warsztat lub organ kontrolny jednoznacznie identyfikuje pierwszych 13 znaków numeru karty;
i) "numer odnowienia karty"oznacza:
numer składający się z 16 znaków alfanumerycznych, który jednoznacznie identyfikuje kartę do tachografów w państwie członkowskim. Numer karty zawiera identyfikację, która polega na identyfikacji kierowcy lub identyfikacji właściciela karty wraz z kolejnym numerem karty, numerem wymiany karty i numerem odnowienia karty;
tym samym karta jest jednoznacznie zidentyfikowana przez kod Strony wydającego i numer karty;
j) "numer wymiany karty"oznacza:
znak alfanumeryczny w numerze karty, który jest zmieniany przyrostowo za każdym razem, gdy wymieniana jest karta do tachografu odpowiadająca danej identyfikacji, tj. identyfikacji kierowcy lub identyfikacji właściciela wraz z kolejnym numerem karty;
k) "współczynnik charakterystyczny pojazdu"oznacza:
wielkość liczbową określającą wartość sygnału dostarczanego przez część pojazdu podłączoną do urządzenia rejestrującego (wał główny skrzyni biegów lub oś) w czasie, gdy pojazd przebywa drogę o długości jednego kilometra mierzoną w normalnych warunkach testowych, zgodnie z definicją w wymaganiu 414. Współczynnik charakterystyczny pojazdu podaje się w impulsach na kilometr (w =... imp/km);
l) "karta firmowa" oznacza:
kartę do tachografu wydaną przez organy Strony przedsiębiorstwu transportowemu używającemu pojazdów wyposażonych w tachografy, która identyfikuje to przedsiębiorstwo transportowe i pozwala na wyświetlanie, pobieranie i drukowanie danych zapisanych w tachografie, który został zabezpieczony blokadą przez to przedsiębiorstwo transportowe;
m) "stała urządzenia rejestrującego" oznacza:
wielkość liczbową określającą wartość sygnału wejściowego wymaganą do wskazania i rejestracji przebytej odległości jednego kilometra; stała ta jest wyrażona w impulsach na kilometr (k =...imp/ km);
n) "nieprzerwany czas prowadzenia pojazdu" obliczany jest przez urządzenie rejestrujące w następujący sposób 17 :
nieprzerwany czas prowadzenia pojazdu obliczany jest jako bieżące, skumulowane czasy prowadzenia pojazdu przez danego kierowcę od końca jego ostatniego 45-minutowego lub dłuższego okresu GOTOWOŚCI lub PRZERWY/ODPOCZYNKU lub NIEOKREŚLONEGO 18 (okres ten może być rozbity zgodnie z rozporządzeniem (WE) nr 561/2006 Parlamentu Europejskiego i Rady 19 ). W obliczeniach uwzględnia się, stosownie do okoliczności, wcześniejsze czynności zapisane na karcie kierowcy. Jeżeli kierowca nie włoży swojej karty, obliczenia wykonuje się na podstawie znajdujących się w pamięci danych zapisów dla bieżącego okresu, w którym nie było włożonej karty, i dla stosownego czytnika;
o) "karta kontrolna" oznacza:
kartę do tachografu wydaną krajowemu właściwemu organowi kontrolnemu przez organy Strony, która identyfikuje organ kontrolny i fakultatywnie funkcjonariusza służb kontrolnych oraz umożliwia dostęp do danych zapisanych w pamięci danych lub na kartach kierowcy i fakultatywnie na kartach warsztatowych w celu odczytu, wydruku lub pobrania danych;
Daje ona również dostęp do funkcji kontroli drogowej kalibracji oraz do danych na czytniku wczesnego wykrywania na odległość.
p) "skumulowany czas przerwy" obliczany jest przez urządzenie rejestrujące w następujący sposób 20 :
skumulowany czas przerwy w prowadzeniu pojazdu obliczany jest jako bieżące, zakumulowane, 15-minutowe lub dłuższe okresy GOTOWOŚCI lub PRZERWY/ODPOCZYNKU lub NIEOKREŚLONE 21 dla danego kierowcy, od końca jego ostatniego 45-minutowego lub dłuższego okresu GOTOWOŚCI lub PRZERWY/ODPOCZYNKU lub NIEOKREŚLONEGO 22 (okres ten może być rozbity zgodnie z rozporządzeniem (WE) nr 561/2006).
W obliczeniach uwzględnia się, stosownie do okoliczności, wcześniejsze czynności zapisane na karcie kierowcy. Do obliczeń nie bierze się nieokreślonych okresów o ujemnym czasie trwania (początek nieokreślonego okresu > koniec nieokreślonego okresu) wynikłych z nakładania się czasów z dwóch różnych urządzeń rejestrujących.
Jeżeli kierowca nie włoży swojej karty, obliczenia wykonuje się na podstawie znajdujących się w pamięci danych zapisów dla bieżącego okresu, w którym nie było włożonej karty, i dla stosownego czytnika.
q) "pamięć danych" oznacza:
elektroniczne urządzenie przechowywania danych wbudowane w urządzenie rejestrujące;
r) "podpis cyfrowy" oznacza:
dane dołączone do bloku danych lub kryptograficzne przekształcenie bloku danych, które umożliwiają odbiorcy bloku danych potwierdzenie autentyczności oraz integralności danego bloku danych;
s) "pobieranie" oznacza:
kopiowanie, wraz z podpisem cyfrowym, części lub kompletnego zestawu pliku danych zapisanych w pamięci danych przyrządu rejestrującego lub w pamięci karty do tachografu, pod warunkiem że proces ten nie zmienia ani nie usuwa żadnych zapisanych danych;
Producenci przyrządów rejestrujących tachografów inteligentnych oraz producenci urządzeń skonstruowanych i przeznaczonych do pobierania zbiorów danych podejmują wszelkie racjonalne działania zapewniające pobieranie takich danych przez przedsiębiorstwa transportowe lub kierowców z minimalnym opóźnieniem.
Pobieranie danych z pliku zawierającego dane szczegółowe dotyczące prędkości nie jest konieczne do celów zgodności z rozporządzeniem (WE) nr 561/2006, ale może być wykorzystane do innych celów, takich jak dochodzenie w sprawie wypadku;
t) "karta kierowcy" oznacza:
kartę do tachografu, która identyfikuje kierowcę i umożliwia przechowywanie danych dotyczących czynności kierowcy, wydaną konkretnemu kierowcy przez organy Strony;
u) "obwód toczny kół" oznacza: wartość średnią długości drogi przebytej przez każde z kół (napędowych) poruszającego się pojazdu podczas jednego pełnego obrotu. Pomiar tych długości drogi jest wykonywany w normalnych warunkach testowych zgodnie z definicją w wymaganiu 414 i wyrażony jest w postaci »l = ... mm«. Producenci pojazdów mogą zastąpić pomiar tych odległości obliczeniem teoretycznym, które uwzględnia rozkład ciężaru na osie, pojazd nieobciążony w normalnym stanie gotowym do jazdy, mianowicie z płynem chłodzącym, smarami, paliwem, narzędziami, kołem zapasowym i kierowcą. Metody takich teoretycznych obliczeń podlegają zatwierdzeniu przez właściwy organ Strony i mogą mieć miejsce wyłącznie przed aktywacją tachografu;
v) "zdarzenie" oznacza:
odbiegające od normy działanie wykryte przez tachograf inteligentny, które może być spowodowane próbą oszustwa;
w) "urządzenie zewnętrzne GNSS" oznacza:
urządzenie, które zawiera odbiornik GNSS, jeżeli przyrząd rejestrujący nie jest pojedynczą jednostką oraz inne elementy niezbędne do ochrony przekazywania danych dotyczących pozycji do pozostałej części przyrządu rejestrującego;
x) "usterka" oznacza:
odbiegające od normy działanie wykryte przez tachograf inteligentny, które może być spowodowane wadliwą pracą lub awarią urządzeń;
y) "odbiornik GNSS" oznacza:
urządzenie elektroniczne, które odbiera i cyfrowo przetwarza sygnały z co najmniej jednego globalnego systemu nawigacji satelitarnej (ang. GNSS) w celu uzyskania informacji o pozycji, prędkości i czasie.
z) "instalacja" oznacza:
montaż tachografu w pojeździe;
aa) "interoperacyjność" oznacza:
zdolność systemów oraz będących ich podstawą procesów gospodarczych do wymiany danych oraz do wymiany informacji;
bb) "interfejs" oznacza:
połączenie między systemami, które zapewnia mechanizmy, za których pośrednictwem systemy te mogą się łączyć i wchodzić w interakcję;
cc) "pozycja" oznacza:
współrzędne geograficzne pojazdu w danym momencie;
dd) "czujnik ruchu" oznacza:
część tachografu dostarczającą sygnał odzwierciedlający prędkość pojazdu lub przebytą drogę;
ee) "karta nieważna" oznacza:
kartę wykrytą jako wadliwa lub kartę, której uwierzytelnienie nie jest możliwe lub której okres ważności jeszcze się nie rozpoczął lub już upłynął;
przyrząd rejestrujący uznaje również kartę za nieważną:
ff) "otwarty standard" oznacza:
standard określony w dokumencie specyfikacji standardów dostępnym bezpłatnie lub za symboliczną opłatą, który może być kopiowany, rozpowszechniany lub wykorzystywany bezpłatnie lub za symboliczną opłatą;
gg) "poza zakresem" oznacza:
że zgodnie z przepisami rozporządzenia (WE) nr 561/2006 użycie urządzenia rejestrującego nie jest wymagane;
hh) "przekroczenie prędkości" oznacza:
przekroczenie dozwolonej prędkości pojazdu definiowane jako dowolny przynajmniej 60-sekundowy okres, w którym zmierzona prędkość pojazdu przekracza wartość ograniczenia dla urządzenia ograniczenia prędkości mającego zastosowanie prawa każdej ze Stron;
ii) "przegląd okresowy"oznacza:
zespół czynności wykonywanych w celu sprawdzenia, czy tachograf pracuje prawidłowo, czy jego ustawienia odpowiadają parametrom pojazdu i czy do tachografu nie podłączono urządzeń manipulacyjnych;
jj) "drukarka" oznacza:
element składowy urządzenia rejestrującego wykonujący wydruki danych zapisanych w pamięci;
kk) "wczesne wykrywanie na odległość" oznacza:
łączność między urządzeniem wczesnego wykrywania na odległość a czytnikiem wczesnego wykrywania na odległość podczas ukierunkowanych kontroli drogowych, mającą na celu zdalne wykrycie ewentualnych manipulacji lub niewłaściwego użycia urządzenia rejestrującego;
ll) "urządzenie do łączności na odległość", "moduł komunikacji na odległość" lub "urządzenie wczesnego wykrywania na odległość" oznacza:
wyposażenie przyrządu rejestrującego, które jest używane do przeprowadzania ukierunkowanych kontroli drogowych;
mm) "czytnik wczesnego wykrywania na odległość" oznacza:
system stosowany przez funkcjonariuszy służb kontrolnych do ukierunkowanych kontroli drogowych;
nn) "odnowienie karty" oznacza:
wydanie nowej karty do tachografu po upływie terminu ważności dotychczasowej karty lub w przypadku nieprawidłowego działania karty i zwrócenia jej organowi wydającemu kartę;
oo) "naprawa" oznacza:
każdą naprawę czujnika ruchu lub przyrządu rejestrującego lub przewodu, wymagającą odłączenia zasilania lub odłączenia od innych elementów składowych tachografu lub otwarcia czujnika ruchu lub przyrządu rejestrującego;
pp) "wymiana karty"oznacza:
wydanie nowej karty do tachografu w celu zastąpienia dotychczasowej karty, której utratę, kradzież lub wadliwe działanie zgłoszono i której nie zwrócono organowi, który wydał kartę;
qq) "certyfikacja bezpieczeństwa" oznacza:
procedurę polegającą na potwierdzeniu przez jednostkę certyfikującą wspólnych kryteriów, że badane urządzenie rejestrujące (lub jego element składowy) lub karta do tachografu spełniają wymogi bezpieczeństwa określone w odpowiednich profilach zabezpieczenia;
rr) "autotest" oznacza:
testy wykonywane okresowo i automatycznie przez urządzenie rejestrujące w celu wykrycia usterek;
ss) "pomiar czasu" oznacza:
trwały cyfrowy zapis uniwersalnej daty koordynowanej i uniwersalnego czasu koordynowanego (UTC);
tt) "korekta czasu" oznacza:
korektę bieżącego czasu; może ona być automatyczna z wykorzystaniem czasu podawanego przez odbiornik GNSS jako odniesienia lub wykonywana w trybie kalibracyjnym;
uu) "rozmiar opon" oznacza:
oznaczenie wymiarów opon (na zewnętrznych kołach napędowych) zgodne z regulaminem EKG ONZ nr 54;
vv) "identyfikacja pojazdu" oznacza:
numery identyfikujące pojazd: numer rejestracyjny pojazdu (VRN) z oznaczeniem Strony rejestracji i numer identyfikacyjny pojazdu (VIN) 23 ;
ww) na potrzeby obliczeniowe w urządzeniu rejestrującym "tydzień"oznacza:
okres między godziną 00.00 UTC w poniedziałek a 24.00 UTC w niedzielę;
xx) "karta warsztatowa" oznacza:
kartę do tachografu wydaną przez organy Strony wyznaczonemu personelowi producenta tachografu, instalatorowi, producentowi pojazdu lub warsztatowi zatwierdzonemu przez to państwo członkowskie, która identyfikuje posiadacza karty i umożliwia testowanie, kalibrację i aktywację tachografów lub pobieranie z nich danych;
yy) "adapter" oznacza:
urządzenie dostarczające sygnał w sposób ciągły odwzorowujący prędkość pojazdu lub przebytą drogę, inne niż urządzenie stosowane do niezależnego wykrywania ruchu, oraz:
- zainstalowana i stosowana wyłącznie w pojazdach kategorii M1 i N1 zgodnie z definicją z ujednoliconej rezolucji w sprawie budowy pojazdów (R.E.3),
- które jest zainstalowane w miejscu, w którym z mechanicznego punktu widzenia niemożliwy jest montaż stosowanych czujników ruchu innego rodzaju, pod innym względem zgodnych z wymaganiami przedstawionymi w niniejszym załączniku i w dodatkach 1-15 do niniejszego załącznika,
- które jest zainstalowane między przyrządem rejestrującym a miejscem, gdzie generowane są impulsy prędkości/drogi przez zintegrowane czujniki lub alternatywne interfejsy,
- z punktu widzenia przyrządu rejestrującego zachowanie adaptera jest takie samo jak czujnika ruchu zgodnego z wymaganiami w niniejszym załączniku i w dodatkach 1-16 do niniejszego załącznika, w przypadku podłączenia go do przyrządu rejestrującego;
zastosowanie takiego adaptera w wymienionych wyżej pojazdach musi umożliwiać montaż i poprawne zastosowanie przyrządu rejestrującego, zgodnego ze wszystkimi wymaganiami niniejszego załącznika,
w przypadku tych pojazdów tachograf inteligentny obejmuje przewody, adapter i przyrząd rejestrujący;
zz) "integralność danych" oznacza:
dokładność i spójność przechowywanych danych, których potwierdzeniem jest brak jakichkolwiek zmian w danych między dwoma aktualizacjami rekordu danych. Integralność oznacza, że dane są dokładną kopią wersji oryginalnej, np. że nie zostały zniekształcone w trakcie zapisu na karcie do tachografu lub urządzeniu dedykowanym lub w trakcie odczytu z nich lub w trakcie transmisji za pośrednictwem dowolnego kanału komunikacji;
aaa) (skreślona).
bbb) "system tachografu inteligentnego" oznacza:
urządzenia rejestrujące, karty do tachografów oraz zestaw wszelkich urządzeń współdziałających bezpośrednio lub pośrednio podczas ich budowy, instalacji, użytkowania, testowania i kontroli, takich jak karty, czytniki na odległość i wszelkie inne urządzenia do pobierania danych, analizy danych, kalibracji, generowania i wprowadzania elementów zabezpieczeń lub zarządzania tymi elementami itp.;
ccc) "data wprowadzenia" oznacza:
datę rozpoczęcia stosowania decyzji nr 1/2023 Specjalnego Komitetu ds. Transportu Drogowego ustanowionego Umową o handlu i współpracy między Unią Europejską i Europejską Wspólnotą Energii Atomowej, z jednej strony, a Zjednoczonym Królestwem Wielkiej Brytanii i Irlandii Północnej, z drugiej strony.
ddd) "profil zabezpieczenia" oznacza:
dokument używany w ramach procesu certyfikacyjnego zgodnie ze wspólnymi kryteriami, który określa niezależne od wdrożenia specyfikacje wymogów bezpieczeństwa w zakresie zabezpieczania informacji;
eee) dokładność GNSS:
w zapisywaniu pozycji z globalnego systemu nawigacji satelitarnej (GNSS) z użyciem tachografów, oznacza wartość Horizontal Dilution of Precision (HDOP) obliczaną jako najniższa z wartości HDOP pobranych z dostępnych systemów GNSS;
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;
2 CHARAKTERYSTYKA OGÓLNA I FUNKCJE URZĄDZEŃ REJESTRUJĄCYCH
2.1 Charakterystyka ogólna
Celem urządzenia rejestrującego jest rejestrowanie, przechowywanie, wyświetlanie, drukowanie i wyprowadzanie danych związanych z czynnościami kierowcy.
Pojazd wyposażony w urządzenie rejestrujące spełniające wymagania niniejszego załącznika musi mieć prędkościomierz i licznik kilometrów. Funkcje te może spełniać urządzenie rejestrujące.
01) Urządzenie rejestrujące składa się z przewodów, czujnika ruchu i przyrządu rejestrującego.
02) Interfejs między czujnikami ruchu i przyrządami rejestrującymi musi być zgodny z wymogami określonymi w dodatku 11.
03) Przyrząd rejestrujący musi być podłączony do globalnego(-ych) systemu(-ów) nawigacji satelitarnej, jak określono w dodatku 12.
04) Przyrząd rejestrujący musi łączyć się z czytnikami wczesnego wykrywania na odległość, jak określono w dodatku 14.
05) Przyrząd rejestrujący musi obejmować interfejs ITS, który został określony w dodatku 13.
Urządzenie rejestrujące może być podłączone do innych urządzeń poprzez dodatkowe interfejsy lub poprzez interfejs ITS.
06) Zawarcie w urządzeniu rejestrującym lub przyłączenie do niego jakiejkolwiek funkcji, urządzenia lub urządzeń, zatwierdzonych lub nie, nie może zakłócać, ani potencjalnie zakłócać, prawidłowego i bezpiecznego działania urządzenia rejestrującego ani uchybiać przepisom niniejszego rozporządzenia.
Użytkowników urządzenia rejestrującego identyfikują w sprzęcie ich karty do tachografów.
07) Urządzenie rejestrujące zapewnia selektywne prawa dostępu do danych i funkcji zależnie od rodzaju lub tożsamości użytkownika.
Urządzenie rejestrujące rejestruje i przechowuje dane w pamięci danych, w urządzeniu do łączności na odległość i na kartach do tachografów.
Odbywa się to zgodnie z częścią C sekcja 2 art. 4 załącznika 31 do Umowy o handlu i współpracy między Unią Europejską i Europejską Wspólnotą Energii Atomowej, z jednej strony, a Zjednoczonym Królestwem Wielkiej Brytanii i Irlandii Północnej, z drugiej strony.
2.2 Funkcje
08) Urządzenie rejestrujące realizuje następujące funkcje:
- monitorowanie wkładania i wyjmowania kart,
- pomiar prędkości, odległości i pozycji,
- pomiar czasu,
- monitorowanie czynności kierowcy,
- monitorowanie stanu prowadzenia pojazdu,
- dane wprowadzane ręcznie przez kierowcę:
- wprowadzanie miejsc rozpoczęcia lub zakończenia dziennych okresów pracy,
- ręczne wprowadzanie czynności kierowcy i zgody kierowcy na interfejs ITS,
- wprowadzanie stanów szczególnych,
- wprowadzanie operacji załadunku/rozładunku,
- zarządzanie blokadami firmowymi,
- monitorowanie czynności kontrolnych,
- wykrywanie zdarzeń lub usterek,
- testy wbudowane i autotesty,
- odczyt z pamięci danych,
- rejestrowanie i przechowywanie w pamięci danych,
- odczyt z kart do tachografów,
- rejestrowanie i przechowywanie na kartach do tachografów,
- wyświetlanie,
- drukowanie,
- ostrzeganie,
- pobieranie danych na nośniki zewnętrzne,
- łączność na odległość na potrzeby ukierunkowanych kontroli drogowych,
- wyprowadzanie danych do dodatkowych urządzeń,
- kalibracja,
- kontrola drogowa kalibracji,
- korekta czasu,
- monitorowanie przekroczeń granicy,
- aktualizacja oprogramowania.
2.3 Tryby pracy
09) Urządzenie rejestrujące może pracować w czterech trybach pracy:
- tryb eksploatacyjny,
- tryb kontrolny,
- tryb kalibracyjny,
- tryb firmowy.
10) Urządzenie rejestrujące przełącza się do następujących trybów pracy zależnie od rodzaju ważnej karty do tachografów włożonej do czytników kart. Do określenia trybu pracy nie jest istotna generacja karty do tachografu, pod warunkiem że włożona karta jest ważna. Karta warsztatowa pierwszej generacji będzie zawsze uznawana za nieważną, jeżeli zostanie włożona do przyrządu rejestracyjnego drugiej generacji.
| Tryb pracy | Czytnik karty kierowcy | ||||
| Brak karty | Karta kierowcy | Karta kontrolna | Karta warsztatowa | Karta firmowa | |
| Czytnik karty współkierowcy | Brak karty | eksploatacyjny | eksploatacyjny | kontrolny | kalibracyjny | firmowy |
| Karta kierowcy | eksploatacyjny | eksploatacyjny | kontrolny | kalibracyjny | firmowy | |
| Karta kontrolna | kontrolny | kontrolny | kontrolny (*) | eksploatacyjny | eksploatacyjny | |
| Karta warsztatowa | kalibracyjny | kalibracyjny | eksploatacyjny | kalibracyjny (*) | eksploatacyjny | |
| Karta firmowa | firmowy | firmowy | eksploatacyjny | eksploatacyjny | firmowy (*) |
| (*) W tych sytuacjach urządzenie rejestrujące korzysta tylko z karty do tachografów w czytniku kierowcy. |
11) Urządzenie rejestrujące ignoruje włożone karty nieważne, z wyjątkiem tego, że możliwe jest wyświetlanie, drukowanie lub pobieranie danych zgromadzonych na kartach, których termin ważności minął.
12) Wszystkie funkcje wymienione w 2.2. działają w każdym trybie pracy z następującymi wyjątkami:
- funkcja kalibracji dostępna jest tylko w trybie kalibracyjnym,
- funkcja kontroli drogowej kalibracji dostępna jest tylko w trybie kontrolnym,
- funkcja zarządzania blokadami firmowymi dostępna jest tylko w trybie firmowym,
- funkcja monitorowania czynności kontrolnych dostępna jest tylko w trybie kontrolnym,
- funkcja pobierania danych nie jest dostępna w trybie eksploatacyjnym, z wyjątkiem:
a) funkcji przewidzianej w wymogu 193;
b) pobierania danych z karty kierowcy, gdy żadna inna karta nie jest włożona do przyrządu rejestrującego.
13) Urządzenie rejestrujące może wyprowadzać dane na wyświetlacz, do drukarki lub interfejsów zewnętrznych z następującymi wyjątkami:
- w trybie eksploatacyjnym wszystkie dane identyfikujące osoby (nazwisko i imię/imiona) nieodpowiadające włożonej karcie do tachografu są wygaszone, a numer karty nieodpowiadający włożonej karcie do tachografu jest częściowo wygaszony (wszystkie nieparzyste znaki od lewej do prawej są wygaszone),
- w trybie firmowym, dane dotyczące kierowcy (wymogi 102, 105, 108, 133a i 133e) mogą być wyprowadzane tylko dla okresów, w których nie ma żadnej blokady ani żadna inna firma nie założyła blokady (określona pierwszymi 13 cyframi numeru karty firmowej),
- przy braku karty w czytniku urządzenia rejestrującego dane dotyczące kierowcy mogą być wyprowadzane tylko dla bieżącego dnia kalendarzowego i 8 poprzednich dni kalendarzowych,
- dane osobowe zarejestrowane i wytworzone przez tachograf lub karty do tachografu nie są generowane przez interfejs ITS przyrządu rejestrującego, chyba że zweryfikowano zgodę kierowcy, którego dane dotyczą,
- 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.
2.4 Zabezpieczenia
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.
14) W celu osiągnięcia bezpieczeństwa systemu, następujące elementy składowe muszą spełniać wymogi bezpieczeństwa określone w ich profilach zabezpieczenia, zgodnie z wymaganiami w dodatku 10:
- przyrząd rejestrujący,
- karta do tachografu,
- czujnik ruchu,
- urządzenie zewnętrzne GNSS (profil ten jest tylko konieczny i stosowany do wariantu urządzenia zewnętrznego GNSS).
3 WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE URZĄDZEŃ REJESTRUJĄCYCH
3.1 Monitorowanie wkładania i wyjmowania kart
15) Urządzenie rejestrujące monitoruje czytniki kart w celu wykrycia wkładania i wyjmowania kart.
16) Po włożeniu karty (lub zdalnym uwierzytelnieniu karty) urządzenie rejestrujące wykrywa, czy karta jest ważną kartą do tachografu zgodnie z definicją w lit. ee) w sekcji 1, i w takim przypadku identyfikuje typ karty i generację karty.
W celu sprawdzenia, czy karta została już włożona, urządzenie rejestrujące wykorzystuje dane karty do tachografu zapisane w jego pamięci danych, jak określono w wymogu 133.
17) Karty do tachografu pierwszej generacji są uznawane przez urządzenie rejestrujące za nieważne, po tym jak możliwość korzystania z kart do tachografu pierwszej generacji została wyłączona przez warsztat, zgodnie z dodatkiem 15 (wym. MIG003).
18) Karty warsztatowe pierwszej generacji wkładane do urządzeń rejestrujących drugiej generacji są uznawane za nieważne.
19) Urządzenie rejestrujące musi być skonstruowane tak, aby po prawidłowym włożeniu do czytnika kart do tachografów były one blokowane we właściwej pozycji.
20) wyjmowanie kart do tachografów jest możliwe tylko przy zatrzymanym pojeździe i po zapisaniu odpowiednich danych na kartach. Wyjęcie karty wymaga wykonania przez użytkownika odpowiedniej czynności.
3.2 Pomiar prędkości, pozycji i odległości
21) Czujnik ruchu (ewentualnie wbudowany w adapter) jest głównym źródłem pomiaru prędkości i odległości.
22) Funkcja ta nieprzerwanie mierzy i dostarcza wartość stanu licznika kilometrów odpowiadającą całkowitej drodze przebytej przez pojazd za pomocą impulsów przekazywanych przez czujnik ruchu.
23) Funkcja ta nieprzerwanie mierzy i dostarcza wartość prędkości pojazdu za pomocą impulsów przekazywanych przez czujnik ruchu.
24) Funkcja pomiaru prędkości podaje także informacje o tym, czy pojazd porusza się, czy stoi. Uznaje się, że pojazd porusza się, gdy funkcja ta wykrywa więcej niż 1 impuls na sekundę z czujnika ruchu przez co najmniej 5 sekund, w przeciwnym razie uważa się, że pojazd stoi.
25) Urządzenia do pokazywania prędkości (prędkościomierz) i łącznej drogi przebytej (licznik kilometrów) zainstalowane w pojeździe wyposażonym w urządzenie rejestrujące, spełniające wymagania niniejszego rozporządzenia, spełniają wymagania odnośnie do maksymalnych tolerancji (zob. 3.2.1 i 3.2.2) określone w niniejszym załączniku.
26) W celu wykrycia manipulowania danymi dotyczącymi ruchu informacje z czujnika ruchu są potwierdzane przez informacje dotyczące ruchu pojazdu pochodzące z odbiornika GNSS i z innych źródeł niezależnych od czujnika ruchu. Co najmniej jeszcze jedno niezależne źródło ruchu pojazdu musi znajdować się wewnątrz przyrządu rejestrującego bez konieczności korzystania z interfejsu zewnętrznego.
27) Funkcja ta mierzy pozycję pojazdu w celu umożliwienia rejestracji:
- pozycji, w których kierowca lub współkierowca rozpoczynają dzienny okres pracy;
- pozycji, w których skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech godzin;
- pozycji, w których pojazd przekroczył granicę krajową;
- pozycji, w których przeprowadzono operacje załadunku/rozładunku;
- pozycji, w których kierowca lub współkierowca kończą dzienny okres pracy;
3.2.1 Pomiar przebytej drogi
28) Długość przebytej drogi może być mierzona, gdy pojazd porusza się:
- do przodu i do tyłu, albo
- tylko do przodu.
29) Urządzenie rejestrujące mierzy odległość w zakresie 0-9 999 999,9 km.
30) Pomiar odległości jest wykonywany z następującą dokładnością (odległości co najmniej 1 000 m):
- ± 1 % przed instalacją,
- ± 2 % po instalacji i przeglądzie okresowym,
- ± 4 % podczas eksploatacji.
Tolerancji nie można wykorzystywać do celowej zmiany zmierzonej odległości.
31) Pomiar odległości jest wykonywany z rozdzielczością co najmniej 0,1 km lub większą.
3.2.2 Pomiar prędkości
32) Urządzenie rejestrujące mierzy prędkość w zakresie od 0 do 220 km/h.
33) W celu zapewnienia maksymalnej tolerancji wskazywanej prędkości ± 6 km/h podczas eksploatacji i uwzględniając:
- tolerancję ± 2 km/h na zmiany sygnału wejściowego (zmiany opon, ...),
- tolerancję ± 1 km/h dla pomiarów wykonywanych w czasie instalacji lub przeglądów okresowych, urządzenie rejestrujące, dla zakresu prędkości między 20 a 180 km/h i dla współczynników charakterystycznych pojazdu między 2 400 a 25 000 impulsów na km, mierzy prędkość z dokładnością ± 1 km/h (przy stałej prędkości).
Uwaga: Rozdzielczość przechowywania danych wprowadza dodatkową tolerancję ± 0,5 km/h do prędkości zapisanej przez urządzenie rejestrujące.
34) Prędkość jest mierzona prawidłowo w zakresie normalnych tolerancji w czasie nie dłuższym niż 2 sekundy od zakończenia zmiany prędkości, jeżeli prędkość zmieniła się w tempie 2 m/s2.
35) Pomiar prędkości jest wykonywany z dokładnością co najmniej 1 km/h lub wyższą.
3.2.3 Pomiar pozycji
36) Urządzenie rejestrujące mierzy bezwzględną pozycję pojazdu za pomocą odbiornika GNSS.
37) Bezwzględną pozycję mierzy się we współrzędnych szerokości i długości geograficznej, w stopniach i minutach, z dokładnością do 1/10 minuty.
3.3 Pomiar czasu
38) Funkcja pomiaru czasu mierzy czas nieprzerwanie i cyfrowo podaje czas UTC.
39) Do datowania w urządzeniu rejestrującym (rejestracja, wymiana danych) i do wszystkich wydruków wymienionych w dodatku 4 "Wydruki" używany jest czas UTC.
40) W celu wizualizacji czasu lokalnego możliwa jest zmiana przesunięcia wyświetlanego czasu skokowo co pół godziny. Nie dopuszcza się innych przesunięć poza przesunięciami wstecz lub do przodu o wielokrotność połowy godziny;
41) Dryft czasu musi wynosić ± 1 sekundę dziennie lub mniej, w warunkach temperaturowych zgodnie z wymogiem 213, przy braku korekty czasu.
41a) Dokładność czasu, gdy czas jest korygowany przez warsztaty zgodnie z wymogiem 212, jest na poziomie 3 sekund lub lepszym.
41b) Przyrząd rejestrujący musi zawierać dryftomierz, który wylicza maksymalny dryft czasu od ostatniej korekty czasu zgodnie z pkt 3.23. Maksymalny dryft czasu jest określany przez producenta przyrządu rejestrującego i nie może przekraczać 1 sekundy dziennie, jak określono w wymogu 41.
41c) Dryftomierz ustawia się ponownie na 1 sekundę po każdej korekcie czasu urządzenia rejestrującego zgodnie z pkt 3.23. Obejmuje to:
- automatyczne korekty czasu,
- korekty czasu wykonywane w trybie kalibracyjnym.
42) Pomiar czasu jest wykonywany z dokładnością co najmniej 1 sekundy lub większą.
43) Odcięcie zewnętrznego źródła zasilania na czas nie krótszy niż 12 miesięcy w warunkach homologacyjnych nie może wpływać na pomiar czasu.
3.4 Monitorowanie czynności kierowcy
44) Funkcja ta nieprzerwanie i odrębnie monitoruje czynności jednego kierowcy i jednego współkierowcy.
45) Czynnościami kierowcy są PROWADZENIE, PRACA, GOTOWOŚĆ lub PRZERWA/ODPOCZYNEK.
46) Kierowca lub współkierowca mogą ręcznie wybierać PRACĘ, GOTOWOŚĆ lub PRZERWĘ/ODPOCZYNEK.
47) Gdy pojazd porusza się następuje automatyczne wybór czynności PROWADZENIE dla kierowcy i GOTOWOŚĆ dla współkierowcy.
48) Gdy pojazd zatrzymuje się, następuje automatyczne wybranie czynności PRACA dla kierowcy.
49) eż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).
50) Funkcja ta przekazuje zmiany czynności do funkcji rejestrującej w odstępach co jedną minutę.
51) W danej minucie zegarowej, jeżeli PROWADZENIE jest zarejestrowane jako czynność w minucie bezpośrednio ją poprzedzającej i następującej bezpośrednio po niej, to cała ta minuta liczy się jako PROWADZENIE.
52) W danej minucie zegarowej, nietraktowanej jako PROWADZENIE zgodnie z wymaganiem 051, cała taka minuta liczy się jako jedna czynność, która trwała najdłużej w ciągu tej minuty (lub była najpóźniejsza w przypadku czynności o jednakowym czasie trwania).
53) Funkcja ta także nieprzerwanie monitoruje zarówno nieprzerwany czas prowadzenia pojazdu, jak i skumulowany czas przerwy dla kierowcy.
3.5 Monitorowanie stanu prowadzenia pojazdu
54) Funkcja ta nieprzerwanie i automatycznie monitoruje stan prowadzenia pojazdu.
55) Po włożeniu dwóch ważnych kart kierowcy wybierany jest stan prowadzenia pojazdu ZAŁOGA, w każdym innym przypadku wybierany jest stan prowadzenia pojazdu JEDEN KIEROWCA.
3.6 Dane wprowadzane przez kierowców
3.6.1 Wprowadzanie miejsca rozpoczęcia lub zakończenia okresu pracy
56) Funkcja ta umożliwia wprowadzanie miejsc, gdzie według kierowcy lub współkierowcy rozpoczyna się lub kończy dzienny okres pracy.
57) Miejsca definiuje się jako kraj i dodatkowo, gdy stosowne, region.
58) Po wyjęciu karty kierowcy (lub warsztatowej) urządzenie rejestrujące wyświetla bieżące miejsce pojazdu na podstawie informacji GNSS i zapisanej mapy cyfrowej zgodnie z pkt 3.12.19 oraz zwraca się do posiadacza karty o potwierdzenie lub ręczne sprostowanie miejsca.
59) Miejsce wpisane zgodnie z wymogiem 58 uważa się za miejsce zakończenia dziennego okresu pracy. Rejestruje się je na stosownej karcie kierowcy (lub karcie warsztatowej) jako zapis tymczasowy i w związku z tym może być później nadpisane.
W poniższych warunkach wpis tymczasowy wykonany przy ostatnim wyjęciu karty zostaje zatwierdzony (tj. nie będzie go już można nadpisać):
- wpis miejsca, w którym rozpoczyna się bieżący dzienny okres pracy, w trakcie ręcznego wprowadzania zgodnie z wymogiem 61;
- następny wpis miejsca, w którym rozpoczyna się bieżący dzienny okres pracy, jeśli posiadacz karty nie wpisze żadnego miejsca rozpoczęcia lub zakończenia okresu pracy w trakcie ręcznego wprowadzania zgodnie z wymogiem 61.
W poniższych warunkach wpis tymczasowy wykonany przy ostatnim wyjęciu karty jest nadpisywany i zatwierdzona zostaje nowa wartość:
- następny wpis miejsca, w którym kończy się bieżący dzienny okres pracy, jeśli posiadacz karty nie wpisze żadnego miejsca rozpoczęcia lub zakończenia okresu pracy w trakcie ręcznego wprowadzania zgodnie z wymogiem 61.
60) Możliwe jest wprowadzenie miejsca rozpoczęcia lub zakończenia dziennego okresu pracy przez wybranie polecenia w menu. Jeżeli w ciągu jednej minuty zegarowej wydane zostaje więcej poleceń niż jedno, zarejestrowane zostaje tylko ostatnie miejsce rozpoczęcia i ostatnie miejsce zakończenia wybrane w tym czasie.
Urządzenie rejestrujące wyświetla bieżące miejsce pojazdu na podstawie informacji GNSS i zapisanych map cyfrowych zgodnie z pkt 3.12.19 oraz zwraca się do kierowcy o potwierdzenie lub ręczne sprostowanie miejsca.
3.6.2 Ręczne wprowadzanie czynności kierowcy i zgoda kierowcy na interfejs ITS
61) Po włożeniu karty kierowcy (lub warsztatowej), i tylko w tym czasie, urządzenie rejestrujące umożliwia ręczne wprowadzanie czynności. Ręczne wprowadzanie czynności wykonuje się, stosując lokalny czas i datę strefy czasowej (przesunięcie UTC) aktualnie ustawione w przyrządzie rejestrującym.
Po włożeniu karty kierowcy lub warsztatowej przyrząd rejestrujący przypomina posiadaczowi karty:
Przy pierwszym włożeniu danej karty kierowcy lub warsztatowej, nieznanej przyrządowi rejestrującemu, posiadacz karty jest proszony o wyrażenie zgody na wyprowadzenie danych osobowych związanych z tachografem poprzez interfejs ITS. W celu sprawdzenia, czy karta została już włożona, urządzenie rejestrujące wykorzystuje dane karty do tachografu zapisane w jego pamięci danych, jak określono w wymogu 133.
W dowolnym momencie istnieje możliwość potwierdzenia lub wycofania zgody kierowcy (ew. warsztatu) przez wybranie polecenia w menu, pod warunkiem że karta kierowcy (lub warsztatowa) jest włożona.
Wprowadzanie czynności jest możliwe z następującymi ograniczeniami:
W razie potrzeby możliwe jest ręczne wprowadzanie czynności przy pierwszym włożeniu uprzednio nieużywanej karty kierowcy (lub warsztatowej).
Procedura ręcznego wprowadzania czynności zawiera tyle kolejnych etapów, ile jest konieczne do ustawienia rodzaju każdej czynności, godziny jej rozpoczęcia i godziny jej zakończenia. Dla całego okresu między ostatnim wyjęciem a bieżącym włożeniem karty posiadacz karty może nie zgłaszać żadnej czynności.
Podczas ręcznego wprowadzania danych związanego z włożeniem karty, posiadacz karty ma, w stosownych przypadkach, możliwość wprowadzenia:
W przypadku miejsca wprowadzonego przy bieżącym włożeniu karty jako miejsce, w którym rozpoczyna się bieżący dzienny okres pracy, urządzenie rejestrujące wyświetla bieżące miejsce pojazdu na podstawie informacji GNSS i zapisanych map cyfrowych zgodnie z pkt 3.12.19 oraz zwraca się do kierowcy o potwierdzenie lub ręczne sprostowanie miejsca.
Jeżeli posiadacz karty nie wprowadzi miejsca rozpoczęcia lub zakończenia okresu pracy podczas ręcznego wprowadzania danych związanego z włożeniem karty, będzie to równoważne z potwierdzeniem, że okres pracy nie zmienił się od ostatniego wyjęcia karty. Kolejne wprowadzenie miejsca zakończenia poprzedniego dziennego okresu pracy nadpisze wówczas wpis tymczasowy wprowadzony przy ostatnim wyjęciu karty.
Jeżeli wprowadza się miejsce, rejestruje się je na stosownej karcie do tachografu.
Ręczne wprowadzanie zostaje przerwane, jeżeli:
Dozwolone są dodatkowe przerwy, np. przekroczenie dozwolonego czasu po pewnym okresie braku aktywności użytkownika. Jeżeli ręczne wprowadzanie zostanie przerwane, urządzenie rejestrujące dokonuje walidacji wszystkich kompletnych miejsc i czynności (mających przypisane jednoznaczne miejsce i godzinę lub rodzaj czynności, godzinę rozpoczęcia i godzinę zakończenia).
Jeżeli podczas ręcznego wprowadzania czynności dla wcześniej włożonej karty zostanie włożona karta drugiego kierowcy lub karta warsztatowa, dopuszcza się uzupełnienie ręcznego wprowadzania dla karty włożonej wcześniej przed rozpoczęciem ręcznego wprowadzania dla drugiej karty.
Posiadacz karty ma możliwość ręcznego wprowadzenia zgodnie z następującą procedurą minimalną:
Procedura kończy się, gdy godzina zakończenia ręcznie wprowadzanej czynności pokrywa się z godziną włożenia karty.
Urządzenie rejestrujące umożliwia kierowcom i warsztatom alternatywne ładowanie ręcznych wpisów, które należy wprowadzić podczas procedury za pośrednictwem interfejsu ITS określonego w dodatku 13, oraz, opcjonalnie, za pośrednictwem innych interfejsów.
Urządzenie rejestrujące umożliwia posiadaczowi karty modyfikowanie ręcznie wprowadzonej czynności aż do zatwierdzenia przez wybranie odpowiedniego polecenia. W późniejszym czasie wprowadzenie takich zmian jest zabronione.
3.6.3 Wprowadzanie warunków szczególnych
62) Urządzenie rejestrujące umożliwia kierowcy wprowadzenie w czasie rzeczywistym następujących dwóch stanów szczególnych:
- »POZA ZAKRESEM« (początek, koniec),
- »PRZEPRAWA PROMOWA/POCIĄGOWA« (początek, koniec).
Jeżeli otwarty jest stan »POZA ZAKRESEM«, nie może równocześnie występować stan »PRZEPRAWA PRO- MOWA/POCIĄGOWA«. Jeżeli otwarto stan »POZA ZAKRESEM«, urządzenie rejestrujące nie pozwala użytkownikom na wpisanie flagi początkowej »PRZEPRAWA PROMOWA/POCIĄGOWA«.
Włożenie lub wyjęcie karty kierowcy powoduje automatycznie zakończenie otwartego stanu »POZA ZAKRESEM«.
Otwarty stan »POZA ZAKRESEM« blokuje następujące zdarzenia i ostrzeżenia:
- prowadzenie pojazdu bez prawidłowej karty,
- ostrzeżenia związane z nieprzerwanym czasem prowadzenia pojazdu.
Kierowca wpisuje flagę początkową PRZEPRAWA PROMOWA/POCIĄGOWA niezwłocznie po wybraniu czynności PRZERWA/ODPOCZYNEK na promie lub w pociągu.
Zamknięcie otwartego stanu PRZEPRAWA PROMOWA/POCIĄGOWA przez urządzenie rejestrujące musi nastąpić, jeżeli wystąpi jedna z następujących sytuacji:
- kierowca ręcznie kończy stan PRZEPRAWA PROMOWA/POCIĄGOWA, co następuje po przybyciu promu/pociągu do miejsca przeznaczenia, przed zjazdem z promu/pociągu,
- otwarty jest stan »POZA ZAKRESEM«,
- kierowca wyjmuje swoją kartę,
- aktywność kierowcy liczona jest jako PROWADZENIE w ciągu minuty kalendarzowej zgodnie z pkt 3.4.
Jeżeli w ciągu jednej minuty kalendarzowej dokonuje się więcej niż jednego wpisu stanów szczególnych tego samego typu, rejestruje się tylko ostatni z nich.
3.6.4 Wprowadzanie operacji załadunku/rozładunku
62a) Urządzenie rejestrujące umożliwia kierowcy wprowadzenie i potwierdzenie, w czasie rzeczywistym, informacji wskazujących, że pojazd jest załadowywany, rozładowywany lub że wykonywana jest operacja równoczesnego załadunku/rozładunku.
Jeżeli w ciągu jednej minuty kalendarzowej dokonuje się więcej niż jednego wpisu operacji załadunku/rozładunku tego samego typu, rejestruje się tylko ostatni z nich.
62b) Operacje załadunku, rozładunku lub równoczesnego załadunku/rozładunku rejestruje się jako odrębne zdarzenia.
62c) Informacje dotyczące załadunku/rozładunku wprowadza się przed opuszczeniem przez pojazd miejsca, w którym przeprowadzana jest operacja załadunku/rozładunku.
3.7 Zarządzanie blokadami firmowymi
63) Funkcja ta umożliwia zarządzanie blokadami umieszczanymi przez firmę w celu ograniczenia dostępu do danych, gdy urządzenie pracuje w trybie firmowym.
64) Blokady firmowe polegają na ustawieniu daty/godziny rozpoczęcia (włączenie blokady) i daty/ godziny zakończenia (zwolnienie blokady) związanych z identyfikacją firmy pobraną z numeru karty firmowej (przy włączeniu blokady).
65) Blokady można włączać i zwalniać tylko w czasie rzeczywistym.
66) Blokadę może zwolnić tylko ta firma, która ją włączyła (identyfikowana na podstawie pierwszych 13 cyfr numeru karty firmowej), lub
67) Zwolnienie następuje automatycznie po włączeniu blokady przez inną firmę.
68) W przypadku gdy firma włącza blokadę, a poprzednia blokada była włączona przez tę samą firmę, przyjmuje się, że poprzednia blokada nie została zwolniona i nadal jest włączona.
3.8 Monitorowanie czynności kontrolnych
69) Funkcja ta monitoruje wykonywane w trybie kontrolnym czynności WYŚWIETLANIA, DRUKOWANIA, POBIERANIA DANYCH z przyrządu rejestrującego i karty oraz KONTROLI DROGOWEJ KALIBRACJI.
70) Funkcja ta również monitoruje KONTROLE PRZEKROCZENIA PRĘDKOŚCI wykonywane w trybie kontrolnym. Uznaje się, że kontrola przekroczenia prędkości została przeprowadzona, gdy w trybie kontrolnym komunikat "przekroczenie prędkości" zostaje wysłany do drukarki lub wyświetlony na monitorze, lub gdy dane o "zdarzeniach i usterkach" zostały pobrane z pamięci danych przyrządu rejestrującego.
3.9 Wykrywanie zdarzeń lub usterek
71) Funkcja ta wykrywa następujące zdarzenia lub usterki:
3.9.1 Zdarzenie "włożenie nieważnej karty"
72) Zdarzenie to uruchamiane jest przez włożenie nieważnej karty, włożenie karty kierowcy, która została wymieniona, lub wygaśnięcie ważności włożonej, ważnej karty.
3.9.2 Zdarzenie "konflikt kart"
73) Zdarzenie to uruchamiane jest przez każdą kombinację ważnych kart zaznaczoną X w tabeli poniżej:
| Konflikt kart | Czytnik karty kierowcy | ||||
| Brak karty | Karta kierowcy | Karta kontrolna | Karta warsztatowa | Karta firmowa | |
| Czytnik karty współkierowcy | Brak karty | |||||
| Karta kierowcy | X | |||||
| Karta kontrolna | X | X | X | |||
| Karta warsztatowa | X | X | X | X | ||
| Karta firmowa | X | X | X |
3.9.3 Zdarzenie "nakładające się czasy
74) Zdarzenie to uruchamiane jest w sytuacji, gdy data/godzina ostatniego wyjęcia karty kierowcy, odczytana z karty, jest późniejsza niż bieżąca data/godzina urządzenia rejestrującego, do którego karta jest wkładana.
3.9.4 Zdarzenie "prowadzenie pojazdu bez prawidłowej karty"
75) Zdarzenie to uruchamiane jest przez każdą kombinację ważnych kart do tachografów zaznaczoną X w poniższej tabeli, gdy czynność kierowcy zmienia się na PROWADZENIE lub w przypadku zmiany trybu pracy, w czasie gdy czynnością wykonywaną przez kierowcę jest PROWADZENIE:
| Prowadzenie pojazdu bez prawidłowej karty | Czytnik karty kierowcy | ||||
| Brak karty (lub karta nieważna) | Karta kierowcy | Karta kontrolna | Karta warsztatowa | Karta firmowa | |
| Czytnik karty współkierowcy | Brak karty (lub karta nieważna) | X | X | X | ||
| Karta kierowcy | X | X | X | X | ||
| Karta kontrolna | X | X | X | X | X | |
| Karta warsztatowa | X | X | X | X | ||
| Karta firmowa | X | X | X | X | X |
3.9.5 Zdarzenie "włożenie karty podczas prowadzenia pojazdu"
76) Zdarzenie to uruchamia się, gdy do dowolnego czytnika włożona zostaje karta do tachografu, a czynnością kierowcy jest PROWADZENIE.
3.9.6 Zdarzenie "Sesja ostatniej karty niezamknięta prawidłowo"
77) Zdarzenie to uruchamia się, gdy przy wkładaniu karty urządzenie rejestrujące wykryje, że pomimo przepisów określonych w pkt 3.1 sesja poprzedniej karty nie została prawidłowo zamknięta (karta została wyjęta przed zapisaniem na karcie wszystkich wymaganych danych). Zdarzenie to uruchamiają tylko karty kierowcy i warsztatowe.
3.9.7 Zdarzenie "przekroczenie prędkości"
78) Zdarzenie to uruchamia się przy każdym przekroczeniu prędkości.
3.9.8 Zdarzenie "przerwa w zasilaniu"
79) Z wyjątkiem trybu kalibracyjnego lub kontrolnego, zdarzenie to uruchamia się w przypadku przekraczającej 200 ms przerwy w zasilaniu czujnika ruchu lub przyrządu rejestrującego. Wartość progową przerwy definiuje producent. Przerwa w zasilaniu spowodowana uruchamianiem silnika pojazdu nie może uruchamiać tego zdarzenia.
3.9.9 Zdarzenie "błąd połączenia z urządzeniem do łączności na odległość"
80) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się w przypadku gdy urządzenie do łączności na odległość nie potwierdza odbioru danych przesyłanych zdalnie z przyrządu rejestrującego podczas więcej niż trzech prób.
3.9.10 Zdarzenie "brak informacji o pozycji z odbiornika GNSS"
81) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się w przypadku braku informacji o pozycji pochodzących z odbiornika GNSS (wewnętrznego lub zewnętrznego) przez ponad trzy godziny skumulowanego czasu prowadzenia pojazdu.
3.9.11 Zdarzenie "błąd połączenia z urządzeniem zewnętrznym GNSS"
82) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się w przypadku przerwy w łączności między urządzeniem zewnętrznym GNSS a przyrządem rejestrującym przez ponad 20 kolejnych minut, kiedy pojazd jest w ruchu.
3.9.12 Zdarzenie "błąd danych dotyczących ruchu"
83) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się w przypadku przerwy w normalnym przepływie danych między czujnikiem ruchu a przyrządem rejestrującym lub w przypadku błędu integralności danych lub błędu uwierzytelnienia danych wymienianych między czujnikiem ruchu a przyrządem rejestrującym. Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się w przypadku, gdy prędkość obliczona z impulsów czujnika ruchu wzrośnie z 0 do ponad 40 km/h w ciągu 1 sekundy, a następnie pozostaje powyżej 40 km/h przez co najmniej 3 sekundy.
3.9.13 Zdarzenie "konflikt ruchu pojazdu"
84) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się, jak określono w dodatku 12, jeżeli informacje o ruchu z czujnika ruchu są sprzeczne z informacjami o ruchu obliczonymi z wewnętrznego odbiornika GNSS lub urządzenia zewnętrznego GNSS lub z innych niezależnych źródeł zgodnie z wymogiem 26. Zdarzenie to nie może być uruchomione podczas przeprawy promowej/pociągowej.
3.9.14 Zdarzenie "próba naruszenia zabezpieczenia"
85) Zdarzenie to uruchamiane jest przez każde inne zdarzenie naruszające zabezpieczenie czujnika ruchu lub przyrządu rejestrującego lub urządzenia zewnętrznego GNSS, zgodnie z wymogami w dodatku 10, z wyjątkiem trybu kalibracyjnego.
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ść między czasem określonym przez funkcję pomiaru czasu w przyrządzie rejestrującym a czasem pochodzącym z uwierzytelnionych pozycji przekazywanych przez odbiornik GNSS lub urządzenie zewnętrzne GNSS. "Rozbieżność czasu" wykrywa się, jeżeli różnica czasu przekracza ± 3 sekundy, co odpowiada dokładności czasu określonej w wymogu 41a, przy czym ta ostatnia wartość zwiększa się o maksymalny dzienny dryft czasu. Zdarzenie to jest rejestrowane wraz z wartością wyświetlaną na wewnętrznym zegarze urządzenia rejestrującego. Przyrząd rejestrujący dokonuje sprawdzenia w celu uruchomienia zdarzenia "konkonflikt czasowy" tuż przed automatycznym dostosowaniem wewnętrznego zegara VU, zgodnie z wymogiem 211.
3.9.16 Usterka "karta"
87) Usterkę tę uruchamia błąd karty do tachografu podczas pracy.
3.9.17 Usterka "urządzenie rejestrujące"
88) Usterkę tę uruchamia dowolny z następujących błędów, z wyjątkiem pracy w trybie kalibracyjnym:
- usterka wewnętrzna przyrządu rejestrującego
- usterka drukarki
- usterka wyświetlacza
- usterka pobierania danych
- usterka czujnika
- usterka odbiornika GNSS lub urządzenia zewnętrznego GNSS
- usterka urządzenia do łączności na odległość
- usterka związana z interfejsem ITS.
3.9.18 Zdarzenie »anomalia GNSS«
88a) Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się, gdy odbiornik GNSS wykryje atak lub gdy uwierzytelnienie komunikatów nawigacyjnych nie powiodło się, jak określono w dodatku 12. Po uruchomieniu zdarzenia anomalii GNSS przyrząd rejestrujący nie generuje innych zdarzeń anomalii GNSS przez kolejnych 10 minut.
3.10 Testy wbudowane i autotesty
89) Urządzenie rejestrujące wykrywa usterki, wykonując autotesty i testy wbudowane, zgodnie z poniższą tabelą:
| Testowany podzespół | Autotest | Test wbudowany |
| Oprogramowanie | Integralność | |
| Pamięć danych | Dostęp | Dostęp, integralność danych |
| Czytniki kart | Dostęp | Dostęp |
| Klawiatura | Kontrola ręczna | |
| Drukarka | (w gestii producenta) | Wydruk |
| Wyświetlacz | Kontrola wzrokowa | |
| Pobieranie danych (wykonywane tylko podczas pobierania) | Prawidłowa praca | |
| Czujnik | Prawidłowa praca | Prawidłowa praca |
| Urządzenie do łączności na odległość | Prawidłowa praca | Prawidłowa praca |
| Urządzenie GNSS | Prawidłowa praca | Prawidłowa praca |
| interfejs ITS | Prawidłowa praca |
3.11 Odczyt z pamięci danych
90) Urządzenie rejestrujące umożliwia odczyt danych przechowywanych w jego pamięci danych.
3.12 Do celów niniejszego punktu:
- »365 dni« definiuje się jako 365 dni kalendarzowych przeciętnych czynności wykonywanych przez kierowców w pojeździe. Przeciętne czynności na dzień w pojeździe definiuje się jako co najmniej 6 kierowców lub współkierowców, 6 cykli wkładania i wyjmowania karty i 256 zmian czynności. »365 dni« obejmuje zatem co najmniej 2 190 kierowców lub współkierowców, 2 190 cykli wkładania i wyjmowania karty i 93 440 zmian czynności,
- średnią liczbę wpisów na dzień definiuje się jako co najmniej 6 wpisów, w których rozpoczyna się dzienny okres pracy, oraz 6 wpisów, w których kończy się dzienny okres pracy, tak więc »365 dni« obejmuje co najmniej 4 380 pozycji,
- średnią liczbę pozycji na dzień, gdy skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin, definiuje się jako co najmniej 6 pozycji, a zatem »365 dni« obejmuje co najmniej 2 190 takich pozycji,
- średnią liczbę przekroczeń granicy na dzień definiuje się jako co najmniej 20, a zatem »365 dni« obejmuje co najmniej 7 300 przekroczeń granicy,
- średnią liczbę operacji załadunku/rozładunku na dzień definiuje się jako co najmniej 25 operacji (niezależnie od typu), a zatem »365 dni« obejmuje co najmniej 9 125 operacji załadunku/rozładunku,
- czas jest rejestrowany z dokładnością do jednej minuty, o ile nie ustalono inaczej,
- stany licznika kilometrów rejestruje się z dokładnością do jednego kilometra,
- prędkości rejestruje się z dokładnością do 1 km/h,
- pozycje (szerokości i długości geograficzne) rejestruje się w stopniach i minutach, z dokładnością do 1/10 minuty, z powiązaną dokładnością GNSS i czasem pobrania danych, a także z flagą wskazującą, czy pozycja została uwierzytelniona.
91) Odcięcie zewnętrznego źródła zasilania na czas krótszy niż dwanaście miesięcy, w warunkach homologacyjnych, nie może wpływać na dane przechowywane w pamięci danych. Ponadto odcięcie zasilania na czas krótszy niż 28 dni nie może mieć wpływu na dane przechowywane w zewnętrznym urządzeniu do łączności na odległość, zgodnie z definicją w dodatku 14.
92) Urządzenie rejestrujące umożliwia rejestrowanie, pośrednio lub bezpośrednio, w pamięci danych następujących informacji:
3.12.1 Dane identyfikujące sprzęt
3.12.1.1 Dane identyfikujące przyrząd rejestrujący
93) Urządzenie rejestrujące umożliwia przechowywanie w pamięci danych następujących danych identyfikujących przyrząd rejestrujący:
- nazwa producenta,
- adres producenta,
- numer części,
- numer seryjny,
- generacja przyrządu rejestrującego,
- możliwość korzystania z kart do tachografów pierwszej generacji,
- numer wersji oprogramowania,
- data instalacji wersji oprogramowania,
- rok produkcji urządzenia,
- numer homologacji,
- identyfikator wersji mapy cyfrowej (wymóg 133l).
94) Dane identyfikujące przyrząd rejestrujący są rejestrowane i zapisywane w pamięci definitywnie przez producenta przyrządu rejestrującego, z wyjątkiem danych, które mogą zostać zmienione w przypadku aktualizacji oprogramowania zgodnie z niniejszym rozporządzeniem, oraz z wyjątkiem możliwości korzystania z kart do tachografów pierwszej generacji.
3.12.1.2 Dane identyfikujące czujnik ruchu
95) Czujnik ruchu umożliwia przechowywanie w pamięci następujących danych identyfikujących:
- nazwa producenta,
- numer seryjny,
- numer homologacji,
- identyfikator wbudowanego elementu zabezpieczenia (np. numer części wewnętrznego mikroprocesora),
- identyfikator systemu operacyjnego (np. numer wersji oprogramowania).
96) Dane identyfikujące czujnik ruchu są rejestrowane i zapisywane w czujniku ruchu definitywnie przez producenta czujnika ruchu.
97) Dane identyfikujące przyrząd rejestrujący są rejestrowane i zapisywane w pamięci definitywnie przez producenta przyrządu rejestrującego, z wyjątkiem danych, które mogą zostać zmienione w przypadku aktualizacji oprogramowania zgodnie z niniejszym rozporządzeniem, oraz z wyjątkiem możliwości korzystania z kart do tachografów pierwszej generacji:
Przy każdym sparowaniu rejestruje się następujące dane:
- dane identyfikujące czujnik ruchu:
- numer seryjny
- numer homologacji
- dane sparowania czujnika ruchu:
- data sparowania.
3.12.1.3 Dane identyfikujące globalnego systemu nawigacji satelitarnej
98) Urządzenie zewnętrzne GNSS umożliwia przechowywanie w pamięci następujących danych identyfikujących:
- nazwa producenta,
- numer seryjny,
- numer homologacji,
- identyfikator wbudowanego elementu zabezpieczenia (np. numer części wewnętrznego mikroprocesora),
- identyfikator systemu operacyjnego (np. numer wersji oprogramowania).
99) Dane identyfikujące są rejestrowane i zapisywane w urządzeniu zewnętrznym GNSS definitywnie przez producenta urządzenia zewnętrznego GNSS.
100) Przyrząd rejestrujący musi mieć możliwość rejestrowania i zachowywania w pamięci następujących danych związanych z 20 ostatnimi udanymi powiązaniami urządzeń zewnętrznych GNSS (jeżeli podczas jednego dnia kalendarzowego miało miejsce wiele powiązań, zachowywane jest tylko pierwsze i ostatnie z danego dnia).
Przy każdym powiązaniu rejestruje się następujące dane:
- dane identyfikujące urządzenia zewnętrznego GNSS:
- numer seryjny,
- numer homologacji,
- dane dotyczące powiązania z urządzeniem zewnętrznym GNSS:
- data powiązania.
3.12.2 Klucze i certyfikaty
101) Urządzenie rejestrujące umożliwia przechowywanie szeregu kluczy i certyfikatów kryptograficznych, jak określono w dodatku 11 część A i część B.
3.12.3 Dane rejestrowane przy wkładaniu i wyjmowaniu karty kierowcy lub warsztatowej
102) Przy każdym cyklu wkładania/wyjmowania karty kierowcy lub warsztatowej do urządzenia, urządzenie rejestrujące rejestruje i przechowuje w pamięci danych następujące informacje:
- nazwisko i imię (imiona) posiadacza karty zapisane na karcie,
- numer karty, państwo członkowskie wydające kartę i termin ważności zapisane na karcie,
- generację karty,
- datę i godzinę włożenia karty,
- stan licznika kilometrów przy wkładaniu karty,
- szczelinę czytnika, do której karta jest wkładana,
- datę i godzinę wyjęcia karty,
- stan licznika kilometrów przy wyjęciu karty,
- następujące informacje o poprzednim pojeździe używanym przez kierowcę, zapisane na karcie:
- numer VRN i państwo członkowskie rejestracji,
- generacja przyrządu rejestrującego (w razie dostępności),
- datę i godzinę wyjęcia karty,
- wskaźnik stanu pokazujący, czy przy wkładaniu karty posiadacz karty wprowadził ręcznie informacje o wykonywaniu czynności.
103) Pamięć danych wystarcza do przechowywania tych danych przez co najmniej 365 dni.
104) W przypadku zapełnienia pamięci danych nowe dane zastępują dane najstarsze.
3.12.4 Dane dotyczące czynności kierowcy
105) Urządzenie rejestrujące rejestruje i przechowuje w pamięci danych za każdym razem, kiedy następuje zmiana czynności kierowcy lub współkierowcy, lub za każdym razem, kiedy następuje zmiana stanu prowadzenia pojazdu, lub za każdym razem, kiedy następuje włożenie lub wyjęcie karty kierowcy lub karty warsztatowej:
- stan prowadzenia pojazdu (ZAŁOGA, JEDEN KIEROWCA),
- szczelinę czytnika (KIEROWCA, WSPÓŁKIEROWCA),
- status karty w odpowiedniej szczelinie czytnika kart (WŁOŻONA, NIEWŁOŻONA),
- czynność (PROWADZENIE, GOTOWOŚĆ, PRACA, PRZERWA/ODPOCZYNEK),
- datę i godzinę zmiany.
WŁOŻONA oznacza, że do czytnika jest włożona ważna karta kierowcy lub warsztatowa. NIEWŁOŻONA oznacza sytuację przeciwną, tzn. że do czytnika nie jest włożona ważna karta kierowcy ani warsztatowa (np. włożona jest karta firmowa lub brak jest karty).
Dane dotyczące czynności ręcznie wprowadzone przez kierowcę nie są rejestrowane w pamięci danych.
106) Pamięć danych wystarcza do przechowywania danych dotyczących czynności kierowcy przez co najmniej 365 dni.
107) W przypadku zapełnienia pamięci danych nowe dane zastępują dane najstarsze.
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;
109) Jeżeli w danym momencie pozycja pojazdu nie jest dostępna z odbiornika GNSS, urządzenie rejestrujące korzysta z ostatniej dostępnej pozycji i odpowiadającej jej daty i godziny.
110) Wraz z miejscem lub pozycją urządzenie rejestrujące rejestruje i przechowuje w pamięci następujące dane:
- numer karty kierowcy lub współkierowcy i państwo członkowskie wydające kartę,
- generację karty,
- datę i godzinę wpisu,
- rodzaj wpisu (rozpoczęcie, zakończenie lub 3 godziny skumulowanego czasu prowadzenia pojazdu),
- w stosownych przypadkach odpowiednią dokładność GNSS, datę i godzinę,
- stan licznika kilometrów,
- flagę wskazującą, czy pozycja została uwierzytelniona.
110a) Dla miejsc, w których rozpoczyna się lub kończy dzienny okres pracy, wprowadzanych podczas procedury ręcznego wprowadzania danych przy wkładaniu karty zgodnie z wymogiem 61, należy zapisać bieżący stan licznika kilometrów i pozycję pojazdu.
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.
112) W przypadku zapełnienia pamięci danych nowe dane zastępują dane najstarsze.
3.12.6 Dane dotyczące licznika kilometrów
113) Urządzenie rejestrujące rejestruje w pamięci danych stan licznika kilometrów i odpowiednią datę o północy każdego dnia kalendarzowego.
114) Pamięć danych wystarcza do przechowywania danych dotyczących stanu licznika o północy przez co najmniej 365 dni kalendarzowych.
115) W przypadku zapełnienia pamięci danych nowe dane zastępują dane najstarsze.
3.12.7 Dane szczegółowe dotyczące prędkości
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.
3.12.8 Dane dotyczące zdarzeń
Do celów niniejszego podpunktu czas rejestruje się z dokładnością do 1 sekundy.
117) Urządzenie rejestrujące rejestruje i przechowuje w pamięci danych następujące dane dla każdego zdarzenia wykrytego zgodnie z poniższymi zasadami przechowywania danych:
| Zdarzenie | Zasady przechowywania | Dane rejestrowane dla zdarzenia |
| Włożenie nieważnej karty | - 10 ostatnich zdarzeń | - data i godzina zdarzenia - typ karty, numer, państwo członkowskie wydające kartę i generacja karty, która wywołała zdarzenie - liczba podobnych zdarzeń w tym dniu |
| Konflikt kart | - 10 ostatnich zdarzeń | - data i godzina początku zdarzenia - data i godzina końca zdarzenia - typ karty, numer, państwo członkowskie wydające kartę i generacja dwóch kart, które wywołały konflikt |
| Prowadzenie pojazdu bez prawidłowej karty | - najdłuższe zdarzenie w każdym z 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 |
| Włożenie karty podczas jazdy | - ostatnie zdarzenie dla każdego z 10 ostatnich dni ich występowania | - data i godzina zdarzenia - typ karty, numer, państwo członkowskie wydające kartę i generacja - liczba podobnych zdarzeń w tym dniu |
| Sesja ostatniej karty niezamknięta prawidłowo | - 10 ostatnich zdarzeń | — data i godzina włożenia karty — typ karty, numer, państwo członkowskie wydające kartę i generacja — dane dotyczące ostatniej sesji odczytane z karty: — data i godzina włożenia karty |
| Przekroczenie prędkości (1) | - najpoważniejsze zdarzenie dla każdego z 10 ostatnich dni od zaistnienia zdarzenia (tzn. zdarzenie o najwyższej przeciętnej prędkości) - 5 najpoważniejszych zdarzeń w ciągu ostatnich 365 dni - pierwsze zdarzenie zaistniałe po ostatniej kalibracji | - data i godzina początku zdarzenia - data i godzina końca zdarzenia - maksymalna prędkość zmierzona w czasie zdarzenia - średnia arytmetyczna prędkość zmierzona w czasie zdarzenia - typ karty, numer, państwo członkowskie wydające kartę i generacja karty kierowcy (w stosownych przypadkach) - liczba podobnych zdarzeń w tym dniu |
| Przerwa w zasilaniu (2) | - 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 |
| Błąd połączenia z urządzeniem do łączności na odległość | - 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 |
| Brak informacji o pozycji z odbiornika 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 |
| 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 |
| Błąd danych dotyczących ruchu | - 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 |
| Konflikt ruchu pojazdu | - 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 |
| Próba naruszenia zabezpieczenia | - 10 ostatnich zdarzeń wg typu zdarzenia | - data i godzina początku zdarzenia - data i godzina zakończenia zdarzenia (jeżeli jest istotna) - typ karty, numer, państwo członkowskie wydające kartę i generacja dla każdej karty wprowadzonej na początku lub pod koniec zdarzenia - typ zdarzenia |
| 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 |
| Anomalia GNSS | — najdłuższe zdarzenia w każdym z ostatnich 10 dni ich występowania, — 5 najdłuższych zdarzeń w ciągu ostatnich 365 dni | — data i godzina początku zdarzenia — data i godzina końca zdarzenia — typ karty, numer, państwo członkowskie wydające kartę i generacja dla każdej karty wprowadzonej na początku lub na końcu zdarzenia — liczba podobnych zdarzeń w tym dniu |
| (1) Urządzenie rejestrujące rejestruje i przechowuje również w pamięci następujące dane: - datę i godzinę ostatniej KONTROLI PRZEKROCZENIA PRĘDKOŚCI, - datę i godzinę pierwszego przekroczenia prędkości po tej ostatniej KONTROLI PRZEKROCZENIA PRĘDKOŚCI. - liczbę zdarzeń przekroczenia prędkości od ostatniej KONTROLI PRZEKROCZENIA PRĘDKOŚCI. (2) Dane te mogą być rejestrowane wyłącznie po przywróceniu zasilania, czas może być znany z dokładnością do minuty. |
3.12.9 Dane dotyczące usterek
Do celów niniejszego podpunktu czas rejestruje się z dokładnością do 1 sekundy.
118) Urządzenie rejestrujące próbuje rejestrować i przechowywać w pamięci danych następujące dane dla każdej wykrytej usterki zgodnie z następującymi zasadami przechowywania danych:
| Usterka | Zasady przechowywania | Dane rejestrowane dla usterki |
| Usterka karty | - 10 ostatnich usterek karty kierowcy | - data i godzina początku usterki - data i godzina końca usterki - typ karty, numer, państwo członkowskie wydające kartę i generacja |
| Usterki urządzenia rejestrującego | - 10 ostatnich usterek dla każdego typu usterki - pierwsza usterka po ostatniej kalibracji | - data i godzina początku usterki - data i godzina końca usterki - rodzaj usterki - typ karty, numer, państwo członkowskie wydające kartę i generacja dla każdej karty wprowadzonej na początku lub pod koniec usterki |
3.12.10 Dane kalibracyjne
119) Urządzenie rejestrujące rejestruje i przechowuje w pamięci następujące dane:
- parametry kalibracyjne znane w momencie aktywacji,
- pierwszą kalibrację po aktywacji urządzenia,
- pierwszą kalibrację w obecnym pojeździe (identyfikowanym numerem VIN),
- 20 ostatnich kalibracji (jeżeli w czasie jednego dnia kalendarzowego jest kilka kalibracji, zapamiętywana jest tylko pierwsza i ostatnia kalibracja z tego dnia).
120) Przy każdej z tych kalibracji rejestruje się następujące dane:
- cel kalibracji (aktywacja, pierwsza instalacja, instalacja, przegląd okresowy),
- nazwa i adres warsztatu,
- numer karty warsztatowej, państwo członkowskie wydające kartę i termin ważności karty,
- identyfikacja pojazdu,
- parametry uaktualnione lub potwierdzone: w, k, l, rozmiar opon, ustawienia urządzenia ograniczenia prędkości, licznik kilometrów (wartości stare i nowe), data i godzina (wartości stare i nowe),
- rodzaje i identyfikatory wszystkich założonych plomb,
- numery seryjne czujnika ruchu, urządzenia zewnętrznego GNSS (jeżeli występuje) oraz zewnętrznego urządzenia do łączności na odległość (jeżeli występuje),
- domyślny typ załadunku związanego z pojazdem (załadunek towarów albo pasażerów),
- kraj, w którym wykonano kalibrację, oraz datę i godzinę dostarczenia przez odbiornik GNSS pozycji wykorzystanej do określenia tego kraju.
121) Ponadto urządzenie rejestrujące rejestruje i przechowuje w pamięci danych zdolność do użytkowania kart do tachografów pierwszej generacji (aktywowaną lub nie).
122) Czujnik ruchu rejestruje i przechowuje w pamięci następujące dane instalacyjne czujnika ruchu:
- pierwsze sparowanie z przyrządem rejestrującym (data, godzina, numer homologacji przyrządu rejestrującego, numer seryjny przyrządu rejestrującego),
- ostatnie sparowanie z przyrządem rejestrującym (data, godzina, numer homologacji przyrządu rejestrującego, numer seryjny przyrządu rejestrującego).
123) Urządzenie zewnętrzne GNSS rejestruje i przechowuje w pamięci następujące dane instalacyjne urządzenia zewnętrznego GNSS:
- pierwsze powiązanie z przyrządem rejestrującym (data, godzina, numer homologacji przyrządu rejestrującego, numer seryjny przyrządu rejestrującego),
- ostatnie powiązanie z przyrządem rejestrującym (data, godzina, numer homologacji przyrządu rejestrującego, numer seryjny przyrządu rejestrującego).
3.12.11 Dane dotyczące korekty czasu
124) Urządzenie rejestrujące rejestruje i przechowuje w pamięci danych dane dotyczące korekty czasu przeprowadzonej w trybie kalibracyjnym, poza ramami regularnej kalibracji (def. f)):
- ostatnia korekta czasu,
- 5 największych korekt czasu.
125) Przy każdej z tych korekt czasu rejestruje się następujące dane:
- data i godzina, stara wartość,
- data i godzina, nowa wartość,
- nazwa i adres warsztatu,
- numer karty warsztatowej, państwo członkowskie wydające kartę, generacja karty i termin ważności karty.
3.12.12 Dane dotyczące czynności kontrolnych
126) Urządzenie rejestrujące rejestruje i przechowuje w pamięci danych następujące dane dotyczące ostatnich 20 czynności kontrolnych:
- data i godzina kontroli,
- numer karty kontrolnej, państwo członkowskie wydające kartę i generacja karty,
- rodzaj kontroli (wyświetlanie lub drukowanie lub pobieranie danych z przyrządu rejestrującego lub karty lub kontrola drogowa kalibracji).
127) W przypadku pobierania danych rejestruje się także daty najstarszych i najnowszych dni, z których dane są pobierane.
3.12.13 Dane dotyczące blokad firmowych
128) Urządzenie rejestrujące rejestruje i przechowuje w pamięci następujące dane dotyczące 255 ostatnich blokad firmowych:
- data i godzina założenia blokady,
- data i godzina zdjęcia blokady,
- numer karty firmowej, państwo członkowskie wydające kartę i generacja karty,
- nazwa i adres firmy.
Dane wcześniej zabezpieczone przez blokadę usunięte z pamięci z powodu powyższego ograniczenia traktuje się jako niezabezpieczone.
3.12.14 Dane dotyczące pobierania danych
129) Urządzenie rejestrujące rejestruje i przechowuje w pamięci danych następujące dane dotyczące ostatniego pobierania danych z pamięci urządzenia na nośnik zewnętrzny, wykonanego w trybie firmowym lub kalibracyjnym:
- data i godzina pobrania danych,
- numer karty firmowej lub warsztatowej, państwo członkowskie wydające kartę i generacja karty,
- nazwa firmy lub warsztatu.
3.12.15 Dane dotyczące warunków szczególnych
130) Urządzenie rejestrujące rejestruje i przechowuje w pamięci danych następujące dane dotyczące warunków szczególnych:
- data i godzina wprowadzenia danych,
- rodzaj warunku szczególnego.
131) Pamięć danych umożliwia przechowywanie danych dotyczących warunków szczególnych przez co najmniej 365 dni (przy założeniu, że przeciętnie otwiera się i zamyka jeden warunek dziennie). W przypadku zapełnienia pamięci danych nowe dane zastępują dane najstarsze.
3.12.16 Dane karty do tachografu
132) Urządzenie rejestrujące umożliwia przechowywanie następujących danych dotyczących różnych kart do tachografów, które zostały użyte w przyrządzie rejestrującym:
- numer karty do tachografu i jej numer seryjny,
- producent karty do tachografu,
- typ karty do tachografu,
- wersja karty do tachografu.
133) Urządzenie rejestrujące umożliwia przechowywanie co najmniej 88 takich rekordów danych.
3.12.17 Przekroczenia granicy
133a) Urządzenie rejestrujące rejestruje i przechowuje w pamięci danych następujące informacje na temat przekroczeń granicy:
- kraj, który pojazd opuszcza,
- kraj, do którego pojazd wjeżdża,
- pozycję, gdzie pojazd przekroczył granicę.
133b) Wraz z krajami i pozycją urządzenie rejestrujące rejestruje i przechowuje w pamięci następujące dane:
- numer karty kierowcy lub współkierowcy i państwo członkowskie wydające kartę,
- generacja karty,
- odpowiednia dokładność GNSS, data i godzina,
- flagę wskazującą, czy pozycja została uwierzytelniona,
- stan licznika kilometrów w momencie wykrycia przekroczenia granicy.
133c) Pamięć danych wystarcza do przechowywania danych dotyczących przekroczeń granicy przez co najmniej 365 dni.
133d) W przypadku zapełnienia pamięci danych nowe dane zastępują dane najstarsze.
3.12.18 Operacje załadunku/rozładunku
133e) Urządzenie rejestrujące rejestruje i przechowuje w pamięci danych następujące informacje na temat operacji załadunku i rozładunku pojazdu:
- typ operacji (załadunek, rozładunek lub równoczesny załadunek/rozładunek),
- pozycję, gdzie miała miejsce operacja załadunku/rozładunku.
133f) Jeżeli w momencie operacji załadunku/rozładunku pozycja pojazdu nie jest dostępna z odbiornika GNSS, urządzenie rejestrujące korzysta z ostatniej dostępnej pozycji i odpowiadającej jej daty i godziny.
133g) Wraz z typem operacji i pozycją urządzenie rejestrujące rejestruje i przechowuje w pamięci następujące dane:
- numer karty kierowcy lub współkierowcy i państwo członkowskie wydające kartę,
- generacja karty,
- data i godzina operacji załadunku/rozładunku,
- w stosownych przypadkach odpowiednia dokładność GNSS, data i godzina,
- flagę wskazującą, czy pozycja została uwierzytelniona,
- stan licznika kilometrów.
133h) Pamięć danych wystarcza do przechowywania danych dotyczących operacji załadunku/rozła- dunku przez co najmniej 365 dni kalendarzowych.
133i) W przypadku zapełnienia pamięci danych nowe dane zastępują dane najstarsze.
3.12.19 Mapa cyfrowa
133j) Do celów rejestrowania pozycji pojazdu po przekroczeniu granicy krajowej urządzenie rejestrujące przechowuje w swojej pamięci danych mapę cyfrową.
133k) Dopuszczone mapy cyfrowe wspierające funkcję monitorowania przekroczeń granicy przez urządzenie rejestrujące są udostępniane przez Komisję Europejską do pobrania ze specjalnej zabezpieczonej strony internetowej w różnych formatach.
133l) W przypadku każdej z tych map na stronie internetowej udostępnia się identyfikator wersji i wartość skrótu.
133m) Mapy muszą mieć:
- poziom szczegółowości odpowiadający poziomowi NUTS 0, zgodnie ze wspólną klasyfikacją jednostek terytorialnych do celów statystycznych,
- skalę 1:1 mln.
133n) Producenci tachografów wybierają mapę ze strony internetowej i pobierają ją w bezpieczny sposób.
133o) Producenci tachografów wykorzystują mapę pobraną ze strony internetowej dopiero po sprawdzeniu jej integralności przy użyciu wartości skrótu mapy.
133p) Wybrana mapa jest importowana przez producenta do urządzenia rejestrującego we właściwym formacie, ale semantyczna importowanej mapy pozostaje bez zmian.
133q) Producent przechowuje również identyfikator wersji mapy wykorzystywanej w urządzeniu rejestrującym.
133r) Możliwa jest aktualizacja lub zastąpienie przechowywanej mapy cyfrowej nową mapą udostępnioną przez Komisję Europejską.
133s) Aktualizacje mapy cyfrowej przeprowadza się przy użyciu mechanizmów aktualizacji oprogramowania ustalonych przez producenta, zgodnie z wymogami 226d i 226e, tak aby urządzenie rejestrujące mogło zweryfikować autentyczność i integralność nowej importowanej mapy przed jej zapisaniem i zastąpieniem poprzedniej mapy.
133t) Producenci tachografów mogą dodać dodatkowe informacje do mapy podstawowej, o której mowa w wymogu 133 m, w celach innych niż rejestrowanie przekroczeń granicy, np. granic regionów UE, pod warunkiem że nie nastąpi zmiana semantyki mapy podstawowej.
3.13 Odczyt kart do tachografów
134) Urządzenie rejestrujące umożliwia odczyt z kart do tachografów pierwszej i drugiej generacji, w odpowiednich przypadkach, danych niezbędnych do:
- rozpoznania typu karty, posiadacza karty, wcześniej używanego pojazdu, daty i godziny ostatniego wyjęcia karty i czynności wybranej dla tego czasu,
- sprawdzenia, czy ostatnia sesja karty została prawidłowo zamknięta,
- wyliczenia dla kierowcy: nieprzerwanego czasu prowadzenia pojazdu, skumulowanego czasu przerwy i skumulowanego czasu prowadzenia za poprzedni i bieżący tydzień,
- wydrukowania żądanych wydruków związanych z danymi zarejestrowanymi na karcie kierowcy,
- pobrania danych z karty kierowcy na zewnętrzny nośnik.
Wymóg ten ma zastosowanie tylko do kart do tachografów pierwszej generacji, jeżeli ich stosowanie nie zostało wyłączone przez warsztat.
135) W przypadku błędu odczytu urządzenie rejestrujące maksymalnie trzykrotnie powtarza to samo polecenie odczytu i w przypadku gdy odczyt nadal nie jest możliwy, uznaje kartę za uszkodzoną i nieważną.
135a) Struktura aplikacji »TACHO_G2« zależy od wersji. Karty wersji 2 zawierają dodatkowe pliki elementarne w stosunku do kart wersji 1, w szczególności:
- w kartach kierowcy i warsztatowych:
- EF Places_Authentication zawiera status uwierzytelnienia pozycji pojazdu przechowywanych w EF Places. Znacznik czasu jest przechowywany z każdym statusem uwierzytelnienia, który musi być dokładnie taki sam, jak data i godzina wpisu przechowywanego z odpowiednią pozycją w EF Places.
- EF GNSS_Places_Authentication zawiera status uwierzytelnienia pozycji pojazdu przechowywanych w EF GNSS_Places. Znacznik czasu jest przechowywany z każdym statusem uwierzytelnienia, który musi być dokładnie taki sam, jak data i godzina wpisu przechowywanego z odpowiednią pozycją w EF Places.
- EF Border_Crossings, EF Load_Unload_Operations oraz EF Load_Type_Entries zawierają dane dotyczące przekroczeń granicy, operacji załadunku/rozładunku oraz typów załadunku;
- w kartach warsztatowych:
- EF Calibration_Add_Data zawiera dodatkowe dane kalibracyjne poza danymi przechowywanymi w EF Calibration. Stara wartość daty i godziny oraz numer identyfikacyjny pojazdu przechowywane są wraz z każdym dodatkowym rekordem danych dotyczących kalibracji, który jest dokładnie taki sam, jak stara wartość daty i godziny oraz numer identyfikacyjny pojazdu przechowywane wraz z odpowiednimi danymi kalibracyjnymi w EF Calibration;
- we wszystkich kartach do tachografów:
- EF VU_Configuration zawiera szczegółowe ustawienia tachografu posiadacza karty.
Przyrząd rejestrujący nie uwzględnia żadnego statusu uwierzytelnienia znalezionego w EF Places_Authen- tication lub EF GNSS_Places_Authentication, jeżeli w EF Places lub EF GNSS_Places nie znaleziono pozycji pojazdu z tym samym znacznikiem czasu.
Przyrząd rejestrujący ignoruje plik elementarny EF VU_Configuration we wszystkich kartach, o ile nie określono szczegółowych zasad dotyczących korzystania z takiego pliku elementarnego. Zasady te określa się poprzez zmianę załącznika IC, która obejmuje modyfikację lub uchylenie niniejszego punktu.
3.14 Rejestrowanie i przechowywanie danych na kartach do tachografów
3.14.1 Rejestrowanie i przechowywanie danych na kartach do tachografów pierwszej generacji
136) O ile karty do tachografów pierwszej generacji nie zostały wyłączone przez warsztat, urządzenie rejestrujące rejestruje i przechowuje dane dokładnie w ten sam sposób co urządzenie rejestrujące pierwszej generacji.
137) Urządzenie rejestrujące ustawia "dane sesji karty" na karcie kierowcy lub warsztatowej bezpośrednio po włożeniu karty.
138) Urządzenie rejestrujące aktualizuje dane zapisane na ważnej karcie kierowcy, warsztatowej, firmowej lub kontrolnej, wprowadzając wszystkie niezbędne dane odnośnie do okresu, w którym karta pozostaje włożona, i odnośnie do posiadacza karty. Dane, które są przechowywane na tych kartach, określono w rozdziale 4.
139) Urządzenie rejestrujące aktualizuje dane dotyczące czynności kierowcy i miejsc (jak określono w pkt 4.5.3.1.9 i 4.5.3.1.11), zapisane na ważnej karcie kierowcy lub warsztatowej, danymi dotyczącymi czynności i miejsc wprowadzonymi ręcznie przez posiadacza karty.
140) Wszystkie zdarzenia niezdefiniowane dla urządzeń rejestrujących pierwszej generacji nie są zapisywane na karcie kierowcy ani na karcie warsztatowej.
141) Aktualizacja kart do tachografów odbywa się w taki sposób, że gdy zaistnieje taka potrzeba i biorąc pod uwagę rzeczywistą zdolność przechowywania danych, najstarsze dane są zastępowanymi najnowszymi danymi.
142) W przypadku błędu zapisu urządzenie rejestrujące maksymalnie trzykrotnie powtarza to samo polecenie zapisu i w przypadku gdy zapis nadal nie jest możliwy, uznaje kartę za uszkodzoną i nieważną.
143) Przed odblokowaniem karty kierowcy lub karty warsztatowej i po zapisaniu na karcie wszystkich stosownych danych urządzenie rejestrujące zeruje »dane sesji karty".
3.14.2 Rejestrowanie i przechowywanie danych na kartach do tachografów drugiej generacji
144) Karty do tachografów drugiej generacji zawierają 2 różne aplikacje kart, z których pierwsza jest dokładnie taka sama jak aplikacja TACHO w kartach do tachografów pierwszej generacji, a druga aplikacja "TACHO_G2" jest zgodna ze specyfikacjami w rozdziale 4 i dodatku 2.
Struktura aplikacji »TACHO_G2« zależy od wersji. Karty wersji 2 zawierają dodatkowe pliki elementarne w stosunku do kart wersji 1.
145) Urządzenie rejestrujące ustawia "dane sesji karty" na karcie kierowcy lub warsztatowej bezpośrednio po włożeniu karty.
146) Urządzenie rejestrujące aktualizuje dane zapisane w 2 aplikacjach ważnej karty kierowcy, warsztatowej, firmowej lub kontrolnej, wprowadzając wszystkie niezbędne dane odnośnie do okresu, w którym karta pozostaje włożona, i odnośnie do posiadacza karty. Dane, które są przechowywane na tych kartach, określono w rozdziale 4.
147) Urządzenie rejestrujące aktualizuje dane dotyczące miejsc i pozycji czynności kierowcy (jak określono w pkt 4.5.3.1.9, 4.5.3.1.11, 4.5.3.2.9 i 4.5.3.2.11), zapisane na ważnej karcie kierowcy lub warsztatowej, danymi dotyczącymi czynności i miejsc wprowadzonymi ręcznie przez posiadacza karty.
147a) Po włożeniu karty kierowcy lub karty warsztatowej urządzenie rejestrujące zapisuje na karcie domyślny typ załadunku pojazdu.
147b) Po włożeniu karty kierowcy lub karty warsztatowej i po ręcznej procedurze wprowadzania danych urządzenie rejestrujące sprawdza ostatnie miejsce rozpoczęcia lub zakończenia dziennego okresu pracy zapisane na karcie. Miejsce to może mieć charakter tymczasowy, jak określono w wymogu 59. Jeżeli miejsce to znajduje się w innym kraju niż bieżący kraj, w którym pojazd się znajduje, urządzenie rejestrujące przechowuje na karcie rekord przekroczenia granicy wraz z następującymi danymi:
- krajem, który opuścił kierowca: niedostępne,
- krajem, do którego wjeżdża kierowca: bieżący kraj, w którym pojazd się znajduje,
- datą i godziną przekroczenia granicy przez kierowcę: godzina włożenia karty,
- pozycją kierowcy po przekroczeniu granicy: niedostępne,
- stanem licznika kilometrów: niedostępne.
148) Aktualizacja kart do tachografów odbywa się w taki sposób, że gdy zaistnieje taka potrzeba i biorąc pod uwagę rzeczywistą zdolność przechowywania danych, najstarsze dane są zastępowanymi najnowszymi danymi.
149) W przypadku błędu zapisu urządzenie rejestrujące maksymalnie trzykrotnie powtarza to samo polecenie zapisu i w przypadku gdy zapis nadal nie jest możliwy, uznaje kartę za uszkodzoną i nieważną.
150) Przed odblokowaniem karty kierowcy i po zapisaniu wszystkich stosownych danych w 2 aplikacjach karty urządzenie rejestrujące zeruje "dane sesji karty".
150a) Przyrząd rejestrujący ignoruje plik elementarny EF VU_Configuration we wszystkich kartach, o ile nie określono szczegółowych zasad dotyczących korzystania z takiego pliku elementarnego. Zasady te określa się poprzez zmianę załącznika IC, która obejmuje modyfikację lub uchylenie niniejszego punktu.
3.15 Wyświetlanie
151) Wyświetlacz umożliwia wyświetlanie co najmniej 20 znaków.
152) Wyświetlane znaki mają wymiary co najmniej 5 mm wysokości i 3,5 mm szerokości.
153) Wyświetlacz umożliwia wyświetlanie znaków określonych w dodatku 1 rozdział 4 "Zestawy znaków". Wyświetlacz może wyświetlać uproszczone glify (np. znaki z akcentami można wyświetlać bez akcentu, a małe litery może wyświetlać jako duże).
154) Wyświetlacz musi mieć nieoślepiające oświetlenie.
155) Wskazania są widoczne spoza urządzenia rejestrującego.
156) Urządzenie rejestrujące umożliwia wyświetlanie:
- informacji standardowych,
- informacji związanych z ostrzeżeniami,
- informacji związanych z dostępem do menu,
- innych informacji, których zażąda użytkownik.
Urządzenie rejestrujące może wyświetlać również dodatkowe informacje, z tym jednak, że muszą być one łatwe do odróżnienia od wymienionych powyżej, wymaganych informacji.
157) Na wyświetlaczu urządzenia rejestrującego używa się piktogramów lub kombinacji piktogramów wymienionych w dodatku 3. Dopuszcza się także dodatkowe piktogramy lub kombinacje piktogramów, jeżeli są one łatwe do odróżnienia od wymaganych piktogramów lub kombinacji piktogramów.
158) Gdy pojazd jest w ruchu, wyświetlacz jest stale włączony.
159) Urządzenie rejestrujące może gasić wyświetlacz automatycznie lub umożliwiać gaszenie ręczne, gdy pojazd nie jest w ruchu.
Format wyświetlania określono w dodatku 5.
3.15.1 Domyślne informacje na wyświetlaczu
160) Gdy nie istnieje potrzeba wyświetlania żadnych innych informacji, urządzenie rejestrujące domyślnie wyświetla następujące informacje:
- czas lokalny (wynik czasu UTC + przesunięcie wprowadzone przez kierowcę),
- tryb pracy,
- bieżącą czynność kierowcy i bieżącą czynność współkierowcy,
- informacje odnoszące się do kierowcy:
- jeżeli jego bieżącą czynnością jest PROWADZENIE, jego bieżący nieprzerwany czas prowadzenia pojazdu i jego bieżący skumulowany czas przerwy,
- jeżeli jego bieżącą czynnością nie jest PROWADZENIE, bieżący czas trwania tej czynności (od momentu wybrania) i jego bieżący skumulowany czas przerwy.
161) Prezentacja informacji odnoszących się do każdego kierowcy jest wyraźna, prosta i jednoznaczna. W przypadku gdy informacji odnoszących się do kierowcy i współkierowcy nie można wyświetlić w tym samym czasie, urządzenie rejestrujące pokazuje domyślnie informacje odnoszące się do kierowcy i pozwala użytkownikowi wyświetlić informacje odnoszące się do współkierowcy.
162) W przypadku gdy wyświetlacz nie pozwala na domyślne pokazywanie trybu pracy, to przy zmianie trybu pracy urządzenie rejestrujące przez krótki czas pokazuje informację o nowym trybie pracy.
163) Przy wkładaniu karty urządzenie rejestrujące przez krótki czas pokazuje nazwisko jej posiadacza.
164) W przypadku otwarcia warunku "POZA ZAKRESEM" lub "PRZEPRAWA PROMOWA/PRZEJAZD KOLEJOWY" na domyślnym wyświetlaczu musi pojawić się informacja w postaci stosownego piktogramu o tym, że warunek ten jest rozpoczęty (dopuszcza się, że w tym samym czasie nie jest pokazywana bieżąca czynność kierowcy).
3.15.2 Wyświetlanie ostrzeżeń
165) Przy wyświetlaniu ostrzeżeń urządzenie rejestrujące korzysta przede wszystkim z piktogramów w dodatku 3, w razie potrzeby uzupełnionych informacjami w postaci kodów liczbowych. Można też dodać wyszczególnienie słowne w preferowanym języku kierowcy.
3.15.3 Dostęp do menu
166) Urządzenie rejestrujące udostępnia niezbędne polecenia poprzez odpowiednie menu.
3.15.4 Inne wyświetlane informacje
167) Na żądanie możliwe jest selektywne wyświetlanie:
- czasu UTC oraz przesunięcia czasu lokalnego,
- treści każdego z wydruków wymienionych w wymogu 169 w takich samych formatach co wydruki,
- nieprzerwanego czasu prowadzenia pojazdu i skumulowanego czasu przerwy kierowcy,
- nieprzerwanego czasu prowadzenia pojazdu i skumulowanego czasu przerwy współkierowcy,
- skumulowanego czasu prowadzenia pojazdu przez kierowcę za poprzedni i bieżący tydzień,
- skumulowanego czasu prowadzenia pojazdu przez współkierowcę za poprzedni i bieżący tydzień;
- bieżącego czasu trwania czynności współkierowcy (od momentu wybrania),
- skumulowanego czasu prowadzenia pojazdu przez kierowcę za bieżący tydzień,
- skumulowanego czasu prowadzenia pojazdu przez współkierowcę za bieżący dzienny okres pracy,
- skumulowanego czasu prowadzenia pojazdu przez kierowcę za bieżący dzienny okres pracy.
168) Treść wydruku jest wyświetlana sekwencyjnie, wiersz po wierszu. Jeżeli w szerokości wyświetlacza mieści się mniej niż 24 znaki, użytkownik musi mieć dostęp do pełnej informacji w odpowiedni sposób (w kilku wierszach, przy pomocy przewijania itp.).
Wiersze wydruku przeznaczone na ręczne adnotacje można pominąć na wyświetlaczu.
3.16 Drukowanie
169) Urządzenie rejestrujące umożliwia drukowanie siedmiu określonych poniżej wydruków, na podstawie informacji zgromadzonych w pamięci urządzenia lub na kartach do tachografów:
- wydruk dzienny czynności kierowcy z karty,
- wydruk dzienny czynności kierowcy z przyrządu rejestrującego,
- wydruk zdarzeń i usterek z karty,
- wydruk zdarzeń i usterek z przyrządu rejestrującego,
- wydruk danych technicznych,
- wydruk przekroczenia prędkości,
- historia danych karty do tachografu dla danego przyrządu rejestrującego (zob. rozdział 3.12.16). Szczegóły formatu i treści tych wydruków określono w dodatku 4.
Pod koniec wydruku mogą być umieszczane informacje dodatkowe.
Urządzenie rejestrujące może wykonywać także dodatkowe wydruki, jeżeli są one łatwe do odróżnienia od siedmiu określonych powyżej wydruków.
170) "Wydruk dzienny czynności kierowcy z karty" i "wydruk zdarzeń i usterek z karty" dostępne są jedynie wtedy, gdy do urządzenia rejestrującego włożona jest karta kierowcy lub karta warsztatowa. Przed uruchomieniem drukowania urządzenie rejestrujące aktualizuje dane przechowywane na stosownej karcie.
171) W celu sporządzenia "wydruku dziennego czynności kierowcy z karty" lub "wydruku zdarzeń i usterek z karty" urządzenie rejestrujące:
- automatycznie wybiera kartę kierowcy lub kartę warsztatową, jeżeli tylko jedna z tych kart jest włożona do urządzenia rejestrującego,
- lub umożliwia wybór karty źródłowej albo wybiera kartę znajdującą się w czytniku karty kierowcy, jeżeli obie te karty włożone są do urządzenia rejestrującego.
172) Drukarka umożliwia drukowanie 24 znaków w wierszu.
173) Drukowane znaki mają wymiary co najmniej 2,1 mm wysokości i 1,5 mm szerokości.
174) Drukarka umożliwia drukowanie znaków określonych w dodatku 1 rozdział 4 "Zestawy znaków".
175) Konstrukcja drukarki umożliwia sporządzanie wydruków z rozdzielczością eliminującą niejednoznaczność przy odczycie.
176) Wydruki zachowują wymiary i treść w warunkach normalnej wilgotności (10-90 %) i temperatury.
177) Papier homologowany używany w urządzeniu rejestrującym musi mieć odpowiedni znak homologacji typu i oznakowanie typu (typów) urządzenia rejestrującego, w którym może być używany.
178) Wydruki muszą być łatwe do odczytania i rozróżnienia, gdy są przechowywane w normalnych warunkach przechowywania, w normalnym oświetleniu, wilgotności i temperaturze, przez okres co najmniej dwóch lat.
179) Wydruki muszą być zgodne co najmniej ze specyfikacjami testów podanymi w dodatku 9.
180) Na wydruku musi być również możliwość umieszczenia ręcznych adnotacji, takich jak podpis kierowcy.
181) Urządzenie rejestrujące obsługuje zdarzenia "brak papieru" w czasie drukowania, a po założeniu papieru, uruchamia drukowanie od początku wydruku lub kontynuuje drukowanie i umieszcza jednoznaczne odniesienie do części wcześniej wydrukowanej.
3.17 Ostrzeżenia
182) Urządzenie rejestrujące ostrzega kierowcę o wykryciu zdarzenia lub usterki.
183) Ostrzeżenie o przerwie w zasilaniu może być opóźnione do czasu przywrócenia zasilania.
184) Urządzenie rejestrujące ostrzega kierowcę na 15 minut przed przekroczeniem i w momencie przekroczenia maksymalnego dopuszczalnego nieprzerwanego czasu prowadzenia pojazdu.
185) Ostrzeżenia są wizualne. Oprócz ostrzeżeń wizualnych dopuszcza się ostrzeżenia akustyczne.
186) Ostrzeżenia wizualne muszą być łatwo rozpoznawalne przez użytkownika, znajdować się w polu widzenia kierowcy i być łatwe do odczytania tak w dzień, jak i w nocy.
187) Ostrzeżenia wizualne mogą być emitowane bezpośrednio przez urządzenie rejestrujące lub zdalnie od urządzenia rejestrującego.
188) W tym ostatnim przypadku są oznaczone symbolem "T".
189) Ostrzeżenia trwają przez przynajmniej 30 sekund, chyba że są potwierdzone przez użytkownika poprzez wciśnięcie jednego lub większej liczby specjalnych przycisków w urządzeniu rejestrującym. To pierwsze potwierdzenie nie usuwa z wyświetlacza informacji o przyczynie ostrzeżenia, o której mowa w następnym punkcie.
190) Urządzenie rejestrujące wyświetla informację o przyczynie ostrzeżenia, aż do momentu potwierdzenia przez użytkownika przy pomocy specjalnego przycisku lub polecenia urządzenia rejestrującego.
191) Dopuszcza się dodatkowe ostrzeżenia, pod warunkiem że nie są mylące dla kierowców w odniesieniu do wcześniej zdefiniowanych ostrzeżeń.
3.18 Pobieranie danych na nośnik zewnętrzny
192) Urządzenie rejestrujące umożliwia, na żądanie, pobieranie danych z pamięci danych lub karty kierowcy na zewnętrzny nośnik poprzez gniazdo kalibracji/pobierania danych. Przed pobraniem danych urządzenie rejestrujące aktualizuje dane przechowywane na stosownej karcie.
193) Dodatkowo i opcjonalnie, urządzenie rejestrujące może w dowolnym trybie pracy przesyłać dane poprzez dowolny inny interfejs do firmy uwierzytelnionej do korzystania z tego kanału. W takim przypadku do tak przesyłanych danych stosuje się prawa dostępu obowiązujące dla trybu firmowego.
194) Przy pobieraniu danych nie może mieć miejsca zmienianie ani usuwanie jakichkolwiek przechowywanych danych.
195) Specyfikacje elektrycznego interfejsu dla gniazda kalibracji/pobierania danych są określone w dodatku 6.
196) Protokoły pobierania danych są określone w dodatku 7.
196a) Przedsiębiorstwo transportowe wykorzystujące pojazdy wyposażone w urządzenia rejestrujące zgodne z niniejszym załącznikiem i objęte zakresem stosowania rozporządzenia (WE) nr 561/2006 zapewnia pobieranie wszystkich danych z przyrządu rejestrującego i kart kierowcy.
Maksymalny okres na wczytanie odpowiednich danych nie przekracza:
- 90 dni w przypadku danych z przyrządu rejestrującego;
- 28 dni w przypadku danych z karty kierowcy.
196b) Przedsiębiorstwa transportowe przechowują dane pobrane z przyrządu rejestrującego i kart kierowcy przez okres co najmniej dwunastu miesięcy od ich zarejestrowania.
3.19 Łączność na odległość na potrzeby ukierunkowanych kontroli drogowych
197) Przy włączonym zapłonie przyrząd rejestrujący co 60 sekund zachowuje na urządzeniu do łączności na odległość najnowsze dane niezbędne na potrzeby ukierunkowanych kontroli drogowych. Dane takie są szyfrowane i podpisywane zgodnie z dodatkiem 11 i dodatkiem 14.
198) Kontrolowane zdalnie dane muszą być dostępne dla czytników na odległość za pośrednictwem łączności bezprzewodowej, jak określono w dodatku 14.
199) Dane niezbędne na potrzeby ukierunkowanych kontroli drogowych odnoszą się do:
- ostatniej próby naruszenia zabezpieczenia,
- najdłuższej przerwy w zasilaniu,
- usterki czujnika,
- błędu danych dotyczących ruchu,
- konfliktu ruchu pojazdu,
- prowadzenia pojazdu bez ważnej karty,
- włożenia karty podczas prowadzenia pojazdu,
- danych dotyczących korekty czasu,
- danych kalibracyjnych, w tym dat dwóch ostatnio zapisanych rekordów danych kalibracji,
- numeru rejestracyjnego pojazdu,
- prędkości zarejestrowanej przez tachograf,
- pozycji pojazdu,
- wskazania, czy kierowca prawdopodobnie narusza obecnie czas prowadzenia pojazdu.
3.20 Wymiana danych z dodatkowymi urządzeniami zewnętrznymi
200) Urządzenie rejestrujące musi być również wyposażone w interfejs ITS zgodnie z dodatkiem 13, który umożliwia korzystanie przez urządzenie zewnętrzne z danych rejestrowanych lub generowanych przez tachograf lub karty do tachografu.
W trybie eksploatacyjnym wymagana jest zgoda kierowcy na przesyłanie danych osobowych za pośrednictwem interfejsu ITS. Niemniej jednak zgoda kierowcy nie ma zastosowania do danych tachografu lub karty, do których uzyskano dostęp w trybie kontrolnym, firmowym lub kalibracyjnym. Dane i funkcjonalne prawa dostępu dla tych trybów określono w wymogach 12 i 13.
Następujące wymogi mają zastosowanie do danych ITS udostępnianych za pośrednictwem tego interfejsu:
- dane osobowe są udostępniane wyłącznie po uzyskaniu możliwej do zweryfikowania zgody kierowcy na to, aby dane osobowe z tachografu mogły opuścić sieć pojazdu.
Zestaw wybranych istniejących danych, które mogą być dostępne za pośrednictwem interfejsu ITS, oraz klasyfikację danych jako danych osobowych lub nieosobowych określono w dodatku 13. Oprócz zestawu danych przedstawionego w dodatku 13 mogą być również generowane dodatkowe dane. Producent VU klasyfikuje te dane jako "osobowe" lub "nieosobowe", a zgoda kierowcy dotyczy danych sklasyfikowanych jako "osobowe",
- w dowolnym momencie istnieje możliwość potwierdzenia lub wycofania zgody kierowcy przez wybranie polecenia w menu, pod warunkiem że karta kierowcy jest włożona,
- w żadnych okolicznościach obecność interfejsu ITS nie może zakłócać prawidłowego funkcjonowania i bezpieczeństwa przyrządu rejestrującego ani oddziaływać na niego.
Dodatkowe interfejsy przyrządu rejestrującego mogą współistnieć, pod warunkiem że są w pełni zgodne z wymogami określonymi w dodatku 13 w odniesieniu do zgody kierowcy. Urządzenie rejestrujące musi posiadać zdolność do podawania statusu zgody kierowcy innym platformom w sieci pojazdu oraz urządzeniom zewnętrznym.
W przypadku danych osobowych wprowadzonych do sieci pojazdu, które są dalej przetwarzane poza siecią pojazdu, producent tachografów nie jest zobowiązany do zapewnienia zgodności procedury przetwarzania danych osobowych z mającymi zastosowanie przepisami Unii dotyczącymi ochrony danych.
Interfejs ITS umożliwia również wprowadzanie danych podczas procedury ręcznego wprowadzania danych zgodnie z wymogiem 61, zarówno przez kierowcę, jak i współkierowcę.
Interfejs ITS może być również wykorzystywany do wprowadzania dodatkowych informacji, w czasie rzeczywistym, takich jak:
- wybór czynności kierowcy, zgodnie z wymogiem 46,
- miejsca, zgodnie z wymogiem 56,
- stany szczególne, zgodnie z wymogiem 62,
- operacje załadunku/rozładunku, zgodnie z wymogiem 62a.
Informacje te mogą być również wprowadzane za pośrednictwem innych interfejsów.
201) Przyrząd rejestrujący może umożliwiać też wyprowadzanie następujących danych poprzez odpowiednie, specjalne łącze szeregowe niezależnie od opcjonalnego przyłączenia szyny CAN (norma ISO 11898 Pojazdy drogowe - Wymiana cyfrowych informacji - Szybka sieć obszaru kontroli CAN), aby umożliwić innym urządzeniom elektrycznym zainstalowanym w pojeździe przetwarzanie następujących danych:
Poza tym wykazem minimalnym mogą być również inne dane wyjściowe.
Po włączeniu zapłonu pojazdu dane te muszą być stale nadawane. Przy wyłączonym zapłonie pojazdu na odpowiednich wyjściach generowane są dane przynajmniej przy każdej zmianie czynności kierowcy lub współkierowcy lub włożeniu lub wyjęciu karty do tachografu. W przypadku gdy przy wyłączonym zapłonie wyprowadzanie danych jest zablokowane, dane te zostają udostępnione ponownie z chwilą włączenia zapłonu pojazdu.
W przypadku gdy przekazywane są dane osobowe, wymagana jest zgoda kierowcy.
3.21 Kalibracja
202) Funkcja kalibracji umożliwia:
- automatyczne sparowanie czujnika ruchu z przyrządem rejestrującym,
- automatyczne powiązanie urządzenia zewnętrznego GNSS z przyrządem rejestrującym w stosownych przypadkach,
- cyfrowe dostosowanie stałej urządzenia rejestrującego (k) do współczynnika charakterystycznego pojazdu (w),
- regulację bieżącego wskazania czasu w zakresie okresu ważności włożonej karty warsztatowej,
- regulację bieżącego wskazania licznika kilometrów,
- aktualizację danych identyfikacyjnych czujnika ruchu zapisanych w pamięci danych,
- aktualizację, w stosownych przypadkach, danych identyfikacyjnych urządzenia zewnętrznego GNSS zapisanych w pamięci danych,
- aktualizację rodzajów i identyfikatorów wszystkich założonych plomb,
- aktualizację lub potwierdzenie innych parametrów używanych przez urządzenie rejestrujące: identyfikację pojazdu, w, l, rozmiar opon i ustawienie urządzenia ograniczenia prędkości, w stosownych przypadkach, oraz domyślny typ załadunku,
- automatyczne zapisywanie kraju, w którym wykonano kalibrację, oraz daty i godziny dostarczenia przez odbiornik GNSS pozycji wykorzystanej do określenia tego kraju.
203) Ponadto funkcja kalibracji umożliwia wyłączenie stosowania kart do tachografów pierwszej generacji w urządzeniu rejestrującym pod warunkiem spełnienia wymogów określonych w dodatku 15.
204) Parowanie czujnika ruchu z przyrządem rejestrującym obejmuje co najmniej:
- aktualizację danych instalacyjnych czujnika ruchu zapisanych w pamięci czujnika ruchu (w razie potrzeby),
- skopiowanie z czujnika ruchu do pamięci danych przyrządu rejestrującego niezbędnych danych identyfikacyjnych czujnika ruchu.
205) Powiązanie urządzenia zewnętrznego GNSS z przyrządem rejestrującym obejmuje co najmniej:
- aktualizację danych instalacyjnych urządzenia zewnętrznego GNSS przechowywanych na urządzeniu zewnętrznym GNSS (w razie potrzeby),
- skopiowanie z urządzenia zewnętrznego GNSS do pamięci danych przyrządu rejestrującego niezbędnych danych identyfikacyjnych GNSS, w tym numeru seryjnego urządzenia zewnętrznego GNSS
206) Funkcja kalibracji umożliwia wprowadzanie niezbędnych danych poprzez gniazdo kalibracji/ pobierania danych zgodnie z protokołem kalibracji zdefiniowanym w dodatku 8. Funkcja kalibracji może także umożliwiać wprowadzanie niezbędnych danych w inny sposób.
3.22 Kontrola drogowa kalibracji
207) Funkcja kontroli drogowej kalibracji umożliwia odczyt numeru seryjnego czujnika (ewentualnie wbudowanego w adapter) oraz numeru seryjnego urządzenia zewnętrznego GNSS (w odpowiednich przypadkach), podłączonych do przyrządu rejestrującego w momencie wysłania żądania.
208) Odczyt musi być możliwy na wyświetlaczu przyrządu rejestrującego przynajmniej przez wybranie poleceń w menu.
209) Funkcja kontroli drogowej kalibracji umożliwia również kontrolowanie wybranego trybu we/wy linii sygnałowej we/wy kalibracji, określonej w dodatku 6, za pośrednictwem interfejsu K-line. Wykonuje się to poprzez ECUAdjustmentSession, jak określono w dodatku 8 sekcja 7 Sterowanie impulsami testującymi - Jednostka funkcjonalna sterowania we/wy.
Jeżeli tryb we/wy linii sygnałowej we/wy kalibracji jest aktywny zgodnie z tym wymogiem, przyrząd rejestrujący nie uruchamia ostrzeżenia »Prowadzenie pojazdu bez prawidłowej karty« (wymóg 75).
3.23 Korekta czasu
210) Funkcja korekty czasu umożliwia automatyczną korektę bieżącego czasu. W urządzeniu rejestrującym korzysta się z dwóch źródeł czasu do celów korekty czasu: 1) wewnętrznego zegara przyrządu rejestrującego, 2) odbiornika GNSS.
211) Ustawienia czasu wewnętrznego zegara przyrządu rejestrującego są automatycznie korygowane w zmiennych odstępach czasu. Kolejna automatyczna korekta czasu uruchamiana jest między 72 a 168 godz. po poprzedniej korekcie oraz po tym, jak VU będzie mógł uzyskać dostęp do czasu GNSS za pomocą komunikatu o prawidłowej uwierzytelnionej pozycji zgodnie z dodatkiem 12. Niemniej jednak korekta czasu nie może nigdy przekroczyć skumulowanego maksymalnego dryftu czasu na dzień, obliczonego przez producenta VU zgodnie z wymogiem 41b. Jeżeli różnica między czasem wewnętrznego zegara VU a czasem odbiornika GNSS jest większa niż skumulowany maksymalny dryft czasu na dzień, wówczas korekta czasu musi dostosować zegar wewnętrzny VU możliwie jak najbliżej czasu odbiornika GNSS. Ustawienia czasu można dokonać tylko wówczas, gdy czas podawany przez odbiornik GNSS jest uzyskiwany przy użyciu komunikatów o uwierzytelnionej pozycji określonych w dodatku 12. Czasem odniesienia dla automatycznego ustawienia czasu wewnętrznego zegara VU jest czas podany w komunikacie o uwierzytelnionej pozycji.
212) W trybie kalibracyjnym funkcja korekty czasu umożliwia również wymuszoną korektę bieżącego czasu.
Warsztaty mogą korygować czas:
- albo zapisując wartość czasu w VU, korzystając z usługi WriteDataByIdentifier zgodnie z sekcją 6.2 w dodatku 8,
- albo poprzez zwrócenie się o dostosowanie zegara VU do czasu podawanego przez odbiornik GNSS. Można tego dokonać tylko wówczas, gdy czas podawany przez odbiornik GNSS jest uzyskiwany przy użyciu komunikatów o uwierzytelnionej pozycji. W tym ostatnim przypadku wykorzystuje się usługę RoutineControl zgodnie z sekcją 8 w dodatku 8.
3.24 Parametry pracy
213) Przyrząd rejestrujący musi być w pełni funkcjonalny w zakresie temperatur - 20-70 °C, urządzenie zewnętrzne GNSS w zakresie temperatur - 20-70 °C, a czujnik ruchu w zakresie temperatur - 40- 135 °C. Zawartość pamięci danych jest zachowywana w temperaturach do - 40 °C.
214) Tachograf zachowuje pełną funkcjonalność w zakresie wilgotności 10-90 %.
215) Plomby używane w tachografach inteligentnych muszą być wytrzymałe w takich samych warunkach, co warunki stosowane względem elementów składowych tachografu, do których są dołączone.
216) Urządzenie rejestrujące jest zabezpieczone przed przepięciami, odwróceniem biegunowości zasilania i zwarciami.
217) Czujniki ruchu muszą:
- reagować na pole magnetyczne, które zakłóca wykrywanie ruchu pojazdu. W takich okolicznościach przyrząd rejestrujący zarejestruje i zapisze w pamięci usterkę czujnika (wymaganie 88); albo
- posiadać czujnik, który jest chroniony przed polami magnetycznymi lub odporny na nie.
218) Urządzenie rejestrujące oraz urządzenie zewnętrzne GNSS muszą być zgodne z międzynarodowym regulaminem EKG ONZ nr 10 oraz być zabezpieczone przed skutkami wyładowań elektrostatycznych oraz stanów nieustalonych.
3.25 Materiały
219) Wszystkie części składowe urządzenia rejestrującego są wykonane z materiałów o wystarczającej stabilności i wytrzymałości mechanicznej oraz stabilnych właściwościach elektrycznych i magnetycznych.
220) W normalnych warunkach eksploatacji wszystkie części wewnętrzne urządzeń są zabezpieczone przed wilgocią i pyłem.
221) Przyrząd rejestrujący i urządzenie zewnętrzne GNSS muszą spełniać wymagania klasy ochrony IP 40, a czujnik ruchu musi spełniać wymagania klasy ochrony IP 64 zgodnie z normą IEC 60529:1989 łącznie z A1:1999 i A2:2013.
222) Urządzenie rejestrujące musi spełniać odpowiednie wymagania techniczne odnoszące się do ergonomii.
223) Urządzenie rejestrujące jest zabezpieczone przed przypadkowym uszkodzeniem.
3.26 Oznakowania
224) Jeżeli urządzenie rejestrujące pokazuje stan licznika kilometrów i prędkość, na wyświetlaczu widoczne są następujące informacje:
- przy liczbie pokazującej odległość, jednostka miary odległości wskazana skrótem "km",
- przy liczbie pokazującej prędkość, jednostka "km/h".
Urządzenie rejestrujące może być również przełączane na wskazywanie prędkości w milach na godzinę, w takim przypadku jednostka pomiaru prędkości jest wskazana skrótem "mph". Urządzenie rejestrujące może być również przełączane na wskazywanie odległości w milach, w takim przypadku jednostka pomiaru odległości jest wskazana skrótem "mi".
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.
3.27 Monitorowanie przekroczeń granicy
226a) Funkcja ta wykrywa, kiedy pojazd przekroczył granicę krajową, który kraj op kraju wjechał.
226b) Wykrywanie przekroczenia granicy opiera się na pozycji zmierzonej przez urząd mapie cyfrowej przechowywanej zgodnie z pkt 3.12.19.
226c) Przekroczenia granicy związane z obecnością pojazdu w danym kraju przez o s nie są rejestrowane.
3.28 Aktualizacja oprogramowania
226d) Przyrząd rejestrujący musi posiadać funkcję wdrażania aktualizacji oprogramow alizacje nie wymagają dostępności dodatkowych zasobów sprzętowych wykrac określone w wymogu 226f, a organy udzielające homologacji typu udzielają zezw oprogramowania oparte na istniejącym przyrządzie rejestrującym posiadający.
226e) Funkcja aktualizacji oprogramowania musi być zaprojektowana w taki sposób, a jące aspekty funkcjonalne, jeżeli są one prawnie wymagane:
- modyfikacja funkcji, o których mowa w pkt 2.2, z wyjątkiem samej funkcji ak wania,
- dodawanie nowych funkcji bezpośrednio związanych z egzekwowaniem prz cych transportu drogowego,
- modyfikacja trybów pracy określonych w pkt 2.3,
- modyfikacja struktury pliku, np. dodanie nowych danych lub zwiększenie roz
- wdrożenie łatek oprogramowania w celu zaradzenia usterkom oprogramowa lub zgłoszonym atakom na funkcje urządzenia rejestrującego.
226f) Przyrząd rejestrujący zapewnia bezpłatne zasoby sprzętowe na poziomie co naj gramowania i danych potrzebnych do wdrożenia wymogu 226e oraz bezpłatne poziomie co najmniej 65 % na potrzeby aktualizacji mapy cyfrowej w oparciu wymagane dla wersji mapy NUTS 0 z 2021 r.
4 WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE KART DO TACHOGRAFÓW
4.1 Dane widzialne
Na awersie znajdują się:
227) słowa "Karta kierowcy" lub "Karta kontrolna" lub "Karta warsztatowa" lub "Karta firmowa" nadrukowane wersalikiem w języku urzędowym lub językach urzędowych Strony wydającego kartę, odpowiednio do rodzaju karty;
228) nazwa Strony wydającego kartę (nieobowiązkowo);
229) wyróżniający znak Strony wydającego kartę, drukowany w negatywie w niebieskim prostokącie i otoczony 12 żółtymi gwiazdami. Obowiązują następujące oznaczenia:
| B | Belgia | LV | Łotwa |
| BG | Bułgaria | L | Luksemburg |
| CZ | Republika Czeska | LT | Litwa |
| CY | Cypr | M | Malta |
| DK | Dania | NL | Niderlandy |
| D | Niemcy | A | Austria |
| EST | Estonia | PL | Polska |
| GR | Grecja | P | Portugalia |
| RO | Rumunia | ||
| SK | Słowacja | ||
| SLO | Słowenia | ||
| E | Hiszpania | FIN | Finlandia |
| F | Francja | S | Szwecja |
| HR | Chorwacja | ||
| H | Węgry | ||
| IRL | Irlandia | UK | Zjednoczone Królestwo |
| I | Włochy |
W przypadku Zjednoczonego Królestwa znakiem wyróżniającym jest: UK
230) informacje szczególne dla wydanej karty, ponumerowane jak następuje:
| Karta kierowcy | Karta kontrolna | Karta firmowa lub warsztatowa | |
| 1. | Nazwisko kierowcy | Nazwa organu kontrolnego | Nazwa firmy lub warsztatu |
| 2. | Imię (imiona) kierowcy | Nazwisko kontrolera (w stosownych przypadkach) | Nazwisko posiadacza karty (w stosownych przypadkach) |
| 3. | Data urodzenia kierowcy | Imię (imiona) kontrolera (w stosownych przypadkach) | Imię (imiona) posiadacza karty (w stosownych przypadkach) |
| 4.a | Data początku okresu ważności karty |
| 4.b | Termin ważności karty |
| 4.c | Nazwa organu wydającego (może być wydrukowana na rewersie) |
| 4.d | Numer inny niż w pozycji 5 do celów administracyjnych (fakultatywnie) |
| 5.a | Numer prawa jazdy (w dniu wydania karty kierowcy) | - | - |
| 5.b | Numer karty |
| 6. | Zdjęcie kierowcy | Zdjęcie kontrolera (fakultatywnie) | Zdjęcie instalatora (fakultatywnie) |
| 7. | Podpis posiadacza karty (fakultatywnie) |
| 8. | Miejsce stałego zamieszkania lub adres pocztowy posiadacza (fakultatywnie) | Adres pocztowy organu kontrolnego | Adres pocztowy firmy lub warsztatu |
231) daty podaje się w formacie "dd/mm/rrrr" lub "dd.mm.rrrr" (dzień, miesiąc, rok). Na rewersie znajdują się:
232) objaśnienia numerowanych pozycji znajdujących się na awersie karty;
233) za szczególną pisemną zgodą posiadacza karty, na karcie można dodatkowo umieścić informacje, które nie wiążą się z administrowaniem kartą; takie dodatkowe informacje w żaden sposób nie zmieniają sposobu używania danego modelu jako karty do tachografów;
234) Karty do tachografów drukuje się w następujących dominujących kolorach tła:
- karta kierowcy: biały,
- karta kontrolna: niebieski,
- karta warsztatowa: czerwony,
- karta firmowa: żółty.
235) Karty do tachografów muszą mieć przynajmniej następujące zabezpieczenia przed fałszowaniem i manipulacjami:
- zabezpieczający wzór tła z drukowanym drobnym giloszem i drukiem irysowym,
- w obszarze zdjęcia zabezpieczający wzór tła i zdjęcie zachodzą na siebie,
- przynajmniej dwubarwną linię wykonaną techniką mikrodruku.
WZORY WSPÓLNOTOWYCH KART DO TACHOGRAFÓW
236) Po konsultacji z Komisją państwa członkowskie mogą dodać kolory lub oznakowania, takie jak symbole państwowe i zabezpieczenia, bez uszczerbku dla innych przepisów w niniejszym załączniku.
237) Karty czasowe, o których mowa w art. 9 ust. 2 sekcji 2 części C załącznika 31 do Umowy o handlu i współpracy między Unią Europejską i Europejską Wspólnotą Energii Atomowej, z jednej strony, a Zjednoczonym Królestwem Wielkiej Brytanii i Irlandii Północnej, z drugiej strony, muszą być zgodne z przepisami niniejszego załącznika.
4.2 Zabezpieczenia
Celem systemu zabezpieczenia jest ochrona integralności i autentyczności danych wymienianych między kartami a urządzeniem rejestrującym, ochrona integralności i autentyczności danych pobieranych z kart, umożliwienie niektórych czynności zapisu na kartach tylko urządzeniu rejestrującemu, odszyfrowywania niektórych danych, uniemożliwienie fałszowania danych przechowywanych na kartach, uniemożliwienie manipulacji i wykrycie wszelkich prób takiego działania.
238) Aby możliwe było osiągnięcie bezpieczeństwa systemu, karty do tachografów muszą spełniać wymogi bezpieczeństwa określone w dodatkach 10 i 11.
239) Karty do tachografów muszą umożliwiać odczyt przy pomocy innych urządzeń, takich jak komputer osobisty.
4.3 Normy
240) Karty do tachografów muszą spełniać wymagania następujących norm:
- ISO/IEC 7810 Karty identyfikacyjne - Charakterystyki fizyczne,
- ISO/IEC 7816 Karty identyfikacyjne - Karty stykowe:
- Część 1: Charakterystyki fizyczne,
- Część 2: Wymiary i rozmieszczenie styków (ISO/IEC 7816-2:2007),
- Część 3: Interfejs elektryczny i protokoły transmisji (ISO/IEC 7816-3:2006),
- Część 4: Organizacja, zabezpieczenia i polecenia wymiany (ISO/IEC 7816-4:2013 + Cor 1:2014),
- Część 6: Elementy danych wymieniane z otoczeniem, niezależne od dziedziny zastosowań (ISO/IEC 7816-6:2004 + Cor 1:2006),
- Część 8: Polecenia operacji zabezpieczających (ISO/IEC 7816-8:2004).
- Karty do tachografów bada się zgodnie z normą SO/IEC 10373-3:2010 Karty identyfikacyjne - Metody badań - część 3: Elektroniczne karty stykowe i powiązane z nimi urządzenia interfejsowe.
4.4 Wymagania środowiskowe i elektryczne
241) Karty do tachografów muszą prawidłowo działać w warunkach klimatycznych normalnie występujących na terytorium Unii i Zjednoczonego Królestwa, przynajmniej w zakresie temperatur od - 25- + 70 °C ze sporadycznymi temperaturami szczytowymi do + 85 °C, przy czym "sporadyczny" oznacza nie dłużej niż 4 godziny jednorazowo i nie więcej niż 100 razy w okresie eksploatacji karty.
242) Karty do tachografów muszą działać prawidłowo w warunkach wilgotności 10 %-90 %.
243) Karty do tachografów muszą prawidłowo działać przez okres pięciu lat, jeżeli są używane w zgodnie z warunkami środowiskowymi i elektrycznymi.
244) W trakcie stosowania karty do tachografów muszą spełniać wymogi regulaminu EKG ONZ nr 10 w odniesieniu do kompatybilności elektromagnetycznej oraz muszą być chronione przed wyładowaniami elektrostatycznymi.
4.5 Przechowywanie danych
Do celów niniejszego pkt:
- czas jest rejestrowany z dokładnością do jednej minuty, chyba że ustalono inaczej,
- stany licznika kilometrów rejestruje się z dokładnością do jednego kilometra,
- prędkości rejestruje się z dokładnością do 1 km/h,
- pozycje (szerokość i długość) rejestruje się w stopniach i minutach, z dokładnością do 1/10 minuty.
Funkcje kart do tachografów, polecenia i struktury logiczne, spełniające wymagania dotyczące przechowywania danych wyszczególniono w dodatku 2.
O ile nie określono inaczej, przechowywanie danych na kartach do tachografów odbywa się w taki sposób, że najstarsze dane są zastępowane nowymi danymi, jeżeli wyczerpie się pamięć przewidziana na określone rekordy danych.
245) W niniejszym punkcie określono minimalną pojemność przechowywania danych dla różnych zbiorów danych aplikacyjnych. Karty do tachografów przekazują do urządzenia rejestrującego bieżącą pojemność przechowywania danych dla tych zbiorów danych.
246) Wszelkie dodatkowe dane mogą być przechowywane na kartach do tachografów, pod warunkiem że przechowywanie tych danych jest zgodne z mającymi zastosowanie przepisami dotyczącymi ochrony danych.
247) Każdy plik główny (MF) na każdej karcie do tachografu zawiera maksymalnie pięć plików elementarnych (EF) do zarządzania kartą, identyfikacji aplikacji i mikroprocesora oraz dwa pliki dedykowane (DF):
- DF Tachograph, który zawiera aplikację dostępną dla przyrządów rejestrujących pierwszej generacji, używaną również w kartach do tachografów pierwszej generacji,
- DF Tachograph_G2, który zawiera aplikację dostępną tylko dla przyrządów rejestrujących drugiej generacji, używaną tylko w kartach do tachografów drugiej generacji,
Uwaga: wersja 2 drugiej generacji kart zawiera dodatkowe pliki elementarne w DF Tachograph_G2.
Szczegółowe informacje o strukturze kart do tachografów określono w dodatku 2.
4.5.1 Pliki elementarne do identyfikacji i zarządzania kartą
4.5.2 Identyfikacja kart mikroprocesorowych
248) Karty do tachografów umożliwiają przechowywanie następujących danych identyfikujących kartę elektroniczną:
- zatrzymanie zegara,
- numer seryjny karty (łącznie z numerem producenta),
- numer homologacji typu dla karty,
- identyfikator jednostki personalizującej kartę,
- identyfikator wbudowującego,
- identyfikator układu scalonego.
4.5.2.1 Identyfikacja mikroprocesora
249) Karty do tachografów umożliwiają przechowywanie następujących danych identyfikujących układ scalony (IC):
- numer seryjny układu scalonego,
- oznaczenie fabryczne układu scalonego.
4.5.2.2 DIR (tylko w kartach do tachografów drugiej generacji)
250) Karty do tachografów umożliwiają przechowywanie obiektów danych identyfikujących aplikacje określonych w dodatku 2.
4.5.2.3 Informacje ATR (warunkowe, dostępne tylko w kartach do tachografów drugiej generacji)
251) Karty do tachografów umożliwiają przechowywanie następujących obiektów danych informacji o rozszerzonej długości:
- jeżeli karta do tachografów obsługuje pola o rozszerzonej długości, obiekt danych informacji o rozszerzonej długości określony w dodatku 2.
4.5.2.4 Informacje o rozszerzonej długości (warunkowe, dostępne tylko w kartach do tachografów drugiej generacji)
252) Karty do tachografów umożliwiają przechowywanie następujących obiektów danych informacji o rozszerzonej długości:
- jeżeli karta do tachografów obsługuje pola o rozszerzonej długości, obiekty danych informacji o rozszerzonej długości określony w dodatku 2.
4.5.3 Karta kierowcy
4.5.3.1 Aplikacja tachograficzna (dostępna dla przyrządów rejestrujących pier wszej i drugiej generacji)
4.5.3.1.1 Identyfikacja aplikacji
253) Karta kierowcy umożliwia przechowywanie następujących danych identyfikujących aplikację:
- identyfikacja aplikacji tachograficznej,
- identyfikacja typu karty do tachografów.
4.5.3.1.2 Klucz i certyfikaty
254) Karta kierowcy umożliwia przechowywanie szeregu kluczy i certyfikatów kryptograficznych, jak określono w dodatku 11 część A.
4.5.3.1.3 Identyfikacja karty
255) Karta kierowcy umożliwia przechowywanie następujących danych identyfikujących kartę:
- numer karty,
- państwo członkowskie wydające kartę, nazwa organu wydającego, data wydania,
- data rozpoczęcia okresu ważności karty, termin ważności karty.
4.5.3.1.4 Identyfikacja posiadacza karty
256) Karta kierowcy umożliwia przechowywanie następujących danych identyfikujących posiadacza karty:
- nazwisko posiadacza karty,
- imię (imiona) posiadacza karty,
- data urodzenia,
- preferowany język.
4.5.3.1.5 Pobieranie danych z karty
257) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących pobierania danych:
- data i godzina ostatniego pobrania danych z karty (do innych celów niż kontrola).
258) Karta kierowcy umożliwia przechowywanie jednego takiego rekordu danych.
4.5.3.1.6 Dane dotyczące prawa jazdy
259) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących prawa jazdy:
- państwo członkowskie wydające, nazwa organu wydającego,
- numer prawa jazdy (w dniu wydania karty).
4.5.3.1.7 Dane dotyczące zdarzeń
Do celów niniejszego podpunktu czas zachowuje się z dokładnością do 1 sekundy.
260) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących zdarzeń wykrytych przez urządzenie rejestrujące przy włożonej karcie:
- nakładające się czasy (w przypadku gdy dana karta jest przyczyną zdarzenia),
- włożenie karty podczas jazdy (w przypadku gdy dana karta jest przedmiotem zdarzenia),
- sesja ostatniej karty niezamknięta prawidłowo (w przypadku gdy dana karta jest przedmiotem zdarzenia),
- przerwa w zasilaniu,
- błąd danych dotyczących ruchu,
- próby naruszenia zabezpieczenia.
261) Karta kierowcy umożliwia przechowywanie następujących danych dla tych zdarzeń:
- kod zdarzenia,
- data i godzina rozpoczęcia zdarzenia (lub włożenia karty, jeżeli zdarzenie trwało w tym czasie),
- data i godzina zakończenia zdarzenia (lub wyjęcia karty, jeżeli zdarzenie trwało w tym czasie),
- numer VRN i państwo członkowskie rejestracji pojazdu, w którym wystąpiło zdarzenie.
Uwaga: dla zdarzenia "nakładające się czasy":
- data i godzina rozpoczęcia zdarzenia musi odpowiadać dacie i godzinie wyjęcia karty z poprzedniego pojazdu,
- data i godzina zakończenia zdarzenia musi odpowiadać dacie i godzinie włożenia karty w bieżącym pojeździe,
- dane pojazdu muszą odpowiadać bieżącemu pojazdowi powodującemu zdarzenie.
Uwaga: dla zdarzenia "sesja ostatniej karty niezamknięta prawidłowo":
- data i godzina rozpoczęcia zdarzenia musi odpowiadać dacie i godzinie włożenia karty dla sesji niezamkniętej prawidłowo,
- data i godzina zakończenia zdarzenia musi odpowiadać dacie i godzinie włożenia karty dla sesji, w czasie której wykryto zdarzenie (bieżąca sesja),
- dane pojazdu muszą odpowiadać pojazdowi, w którym sesja nie została zamknięta prawidłowo.
262) Karta kierowcy umożliwia przechowywanie danych dotyczących sześciu ostatnich zdarzeń każdego typu (łącznie 36 zdarzeń).
4.5.3.1.8 Dane dotyczące usterek
Do celów niniejszego podpunktu czas rejestruje się z dokładnością do 1 sekundy.
263) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących usterek wykrytych przez urządzenie rejestrujące przy włożonej karcie:
- usterka karty (w przypadku gdy dana karta jest przedmiotem usterki),
- usterka urządzenia rejestrującego.
264) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących tych usterek:
- kod usterki,
- data i godzina rozpoczęcia usterki (lub włożenia karty, jeżeli usterka trwała w tym czasie),
- data i godzina zakończenia usterki (lub wyjęcia karty, jeżeli usterka trwała w tym czasie),
- numer VRN i państwo członkowskie rejestracji pojazdu, w którym wystąpiła usterka.
265) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących dwunastu ostatnich usterek każdego rodzaju (łącznie 24 usterki).
4.5.3.1.9 Dane dotyczące czynności kierowcy
266) Karta kierowcy umożliwia przechowywanie, dla każdego dnia kalendarzowego, w którym karta jest użyta, lub dla każdego dnia, dla którego kierowca ręcznie wprowadza informacje dotyczące czynności, następujących danych:
- data,
- dzienny licznik obecności (zwiększony o jeden dla każdego z tych dni kalendarzowych),
- całkowita droga przebyta przez kierowcę w ciągu tego dnia,
- status kierowcy o godzinie 00:00,
- za każdym razem, kiedy kierowca zmienia czynność lub stan prowadzenia pojazdu lub wkłada lub wyjmuje swoją kartę:
- stan prowadzenia pojazdu (ZAŁOGA, JEDEN KIEROWCA),
- szczelina czytnika (KIEROWCA, WSPÓŁKIEROWCA),
- status karty (WŁOŻONA, NIEWŁOŻONA),
- czynność (PROWADZENIE, GOTOWOŚĆ, PRACA, PRZERWA/ODPOCZYNEK),
- godzina zmiany.
267) Pamięć karty kierowcy wystarcza do przechowywania danych dotyczących czynności kierowcy przez co najmniej 28 dni (przeciętną aktywność kierowcy definiuje się jako 93 zmiany czynności dziennie).
268) Dane wyszczególnione w wymaganiach 261, 264 i 266 przechowuje się w sposób umożliwiający wyszukiwanie czynności w kolejności chronologicznej, nawet w przypadku nakładania się czasów.
4.5.3.1.10 Dane dotyczące używanych pojazdów
269) Karta kierowcy umożliwia przechowywanie, dla każdego dnia kalendarzowego, w którym karta jest użyta, i dla każdego okresu używania danego pojazdu w tym dniu (okres używania obejmuje wszystkie następujące po sobie cykle włożenia i wyjęcia karty w danym pojeździe, z perspektywy danych zapisanych na karcie), następujących danych:
- data i godzina pierwszego użycia pojazdu (tj. pierwsze włożenie karty w tym okresie używania pojazdu lub 00:00, jeżeli okres używania trwał w tym czasie),
- stan licznika kilometrów o tej godzinie,
- data i godzina ostatniego użycia pojazdu, (tj. ostatnie wyjęcie karty w tym okresie używania pojazdu lub 23:59, jeżeli okres używania trwał w tym czasie),
- stan licznika kilometrów o tej godzinie,
- numer VRN i państwo członkowskie rejestracji pojazdu.
270) Karta kierowcy umożliwia przechowywanie co najmniej 84 takich rekordów danych.
4.5.3.1.11 Miejsca rozpoczęcia lub zakończenia dziennych okresów pracy
271) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących miejsc rozpoczęcia lub zakończenia dziennych okresów pracy, wprowadzanych przez kierowcę:
- data i godzina wprowadzenia danych (lub data/godzina odnosząca się do wpisu, jeżeli wpis wprowadza się w procedurze ręcznego wprowadzania danych),
- rodzaj wpisu (rozpoczęcie lub zakończenie, status wpisu),
- kraj i region,
- stan licznika kilometrów.
272) Pamięć karty kierowcy umożliwia przechowywanie co najmniej 42 par takich rekordów danych.
4.5.3.1.12 Dane sesji karty
273) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących pojazdu, dla którego otwarto bieżącą sesję:
- data i godzina otwarcia sesji (tj. włożenia karty) z dokładnością do jednej sekundy,
- numer VRN i państwo członkowskie rejestracji.
4.5.3.1.13 Dane dotyczące czynności kontrolnych
274) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących czynności kontrolnych:
- data i godzina kontroli,
- numer karty kontrolnej i państwo członkowskie wydające kartę,
- rodzaj kontroli (wyświetlanie lub drukowanie lub pobieranie danych z przyrządu rejestrującego lub pobieranie danych z karty - patrz uwaga),
- okres, dla którego pobrano dane, w przypadku pobierania danych,
- numer VRN i państwo członkowskie rejestracji pojazdu, w którym miała miejsce kontrola.
Uwaga: pobieranie danych z karty jest rejestrowane wyłącznie wtedy, gdy jest wykonywane przez urządzenie rejestrujące.
275) Karta kierowcy umożliwia przechowywanie jednego takiego rekordu danych.
4.5.3.1.14 Dane dotyczące warunków szczególnych
276) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących warunków szczególnych wprowadzonych przy włożonej karcie (niezależnie od tego, do której szczeliny czytnika):
- data i godzina wprowadzenia danych,
- rodzaj warunku szczególnego.
277) Karta kierowcy umożliwia przechowywanie co najmniej 56 takich rekordów danych.
4.5.3.2 Aplikacja tachograficzna generacji 2 (niedostępna dla pierwszej generacji przyrządów rejestrujących, dostępna dla wersji 1 i wersji 2 drugiej generacji przyrządów rejestrujących)
4.5.3.2.1 Identyfikacja aplikacji
278) Karta kierowcy umożliwia przechowywanie następujących danych identyfikujących aplikację:
- identyfikacja aplikacji tachograficznej,
- identyfikacja typu karty do tachografów.
4.5.3.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
278a) Karta kierowcy umożliwia przechowywanie dodatkowych danych identyfikujących aplikacje mających zastosowanie wyłącznie do wersji 2.
4.5.3.2.2 Klucze i certyfikaty
279) Karta kierowcy umożliwia przechowywanie szeregu kluczy i certyfikatów kryptograficznych, jak określono w dodatku 11 część B.
4.5.3.2.3 Identyfikacja karty
280) Karta kierowcy umożliwia przechowywanie następujących danych identyfikujących kartę:
- numer karty,
- państwo członkowskie wydające kartę, nazwa organu wydającego, data wydania,
- data rozpoczęcia okresu ważności karty, termin ważności karty.
4.5.3.2.4 Identyfikacja posiadacza karty
281) Karta kierowcy umożliwia przechowywanie następujących danych identyfikujących posiadacza karty:
- nazwisko posiadacza karty,
- imię (imiona) posiadacza karty,
- data urodzenia,
- preferowany język.
4.5.3.2.5 Pobieranie danych z karty
282) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących pobierania danych:
- data i godzina ostatniego pobrania danych z karty (do innych celów niż kontrola).
283) Karta kierowcy umożliwia przechowywanie jednego takiego rekordu danych.
4.5.3.2.6 Dane dotyczące prawa jazdy
284) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących prawa jazdy:
- państwo członkowskie wydające, nazwa organu wydającego,
- numer prawa jazdy (w dniu wydania karty).
4.5.3.2.7 Dane dotyczące zdarzeń
Do celów niniejszego podpunktu czas zachowuje się z dokładnością do 1 sekundy.
285) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących zdarzeń wykrytych przez urządzenie rejestrujące przy włożonej karcie:
- nakładające się czasy (w przypadku gdy dana karta jest przyczyną zdarzenia),
- włożenie karty podczas jazdy (w przypadku gdy dana karta jest przedmiotem zdarzenia),
- sesja ostatniej karty niezamknięta prawidłowo (w przypadku gdy dana karta jest przedmiotem zdarzenia),
- przerwa w zasilaniu,
- błąd połączenia z urządzeniem do łączności na odległość,
- brak informacji o pozycji z odbiornika GNSS,
- błąd połączenia z urządzeniem zewnętrznym GNSS,
- błąd danych dotyczących ruchu,
- konflikt ruchu pojazdu,
- próba naruszenia zabezpieczenia,
- konflikt czasu.
286) Karta kierowcy umożliwia przechowywanie następujących danych dla tych zdarzeń:
- kod zdarzenia,
- data i godzina rozpoczęcia zdarzenia (lub włożenia karty, jeżeli zdarzenie trwało w tym czasie),
- data i godzina zakończenia zdarzenia (lub wyjęcia karty, jeżeli zdarzenie trwało w tym czasie),
- numer VRN i państwo członkowskie rejestracji pojazdu, w którym wystąpiło zdarzenie.
Uwaga: dla zdarzenia "nakładające się czasy":
- data i godzina rozpoczęcia zdarzenia musi odpowiadać dacie i godzinie wyjęcia karty z poprzedniego pojazdu,
- data i godzina zakończenia zdarzenia musi odpowiadać dacie i godzinie włożenia karty w bieżącym pojeździe,
- dane pojazdu muszą odpowiadać bieżącemu pojazdowi powodującemu zdarzenie.
Uwaga: dla zdarzenia "sesja ostatniej karty niezamknięta prawidłowo":
- data i godzina rozpoczęcia zdarzenia musi odpowiadać dacie i godzinie włożenia karty dla sesji niezamkniętej prawidłowo,
- data i godzina zakończenia zdarzenia musi odpowiadać dacie i godzinie włożenia karty dla sesji, w czasie której wykryto zdarzenie (bieżąca sesja),
- dane pojazdu muszą odpowiadać pojazdowi, w którym sesja nie została zamknięta prawidłowo.
287) Karta kierowcy umożliwia przechowywanie danych dotyczących 12 ostatnich zdarzeń każdego typu (tj. 132 zdarzeń).
4.5.3.2.8 Dane dotyczące usterek
Do celów niniejszego podpunktu czas rejestruje się z dokładnością do 1 sekundy.
288) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących usterek wykrytych przez urządzenie rejestrujące przy włożonej karcie:
- usterka karty (w przypadku gdy dana karta jest przedmiotem usterki),
- usterka urządzenia rejestrującego.
289) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących tych usterek:
- kod usterki,
- data i godzina rozpoczęcia usterki (lub włożenia karty, jeżeli usterka trwała w tym czasie),
- data i godzina zakończenia usterki (lub wyjęcia karty, jeżeli usterka trwała w tym czasie),
- numer VRN i państwo członkowskie rejestracji pojazdu, w którym wystąpiła usterka.
290) Karta kierowcy umożliwia przechowywanie danych dotyczących 24 ostatnich usterek każdego rodzaju (tj. 48 usterek).
4.5.3.2.9 Dane dotyczące czynności kierowcy
291) Karta kierowcy umożliwia przechowywanie, dla każdego dnia kalendarzowego, w którym karta jest użyta, lub dla każdego dnia, dla którego kierowca ręcznie wprowadza informacje dotyczące czynności, następujących danych:
- data,
- dzienny licznik obecności (zwiększony o jeden dla każdego z tych dni kalendarzowych),
- całkowita droga przebyta przez kierowcę w ciągu tego dnia,
- status kierowcy o godzinie 00:00,
- za każdym razem, kiedy kierowca zmienia czynność lub stan prowadzenia pojazdu lub wkłada lub wyjmuje swoją kartę:
- stan prowadzenia pojazdu (ZAŁOGA, JEDEN KIEROWCA),
- szczelina czytnika (KIEROWCA, WSPÓŁKIEROWCA),
- status karty (WŁOŻONA, NIEWŁOŻONA),
- czynność (PROWADZENIE, GOTOWOŚĆ, PRACA, PRZERWA/ODPOCZYNEK),
- godzina zmiany.
292) Pamięć karty kierowcy wystarcza do przechowywania danych dotyczących czynności kierowcy przez przynajmniej 56 dni (przeciętną aktywność kierowcy definiuje się na potrzeby tego wymogu jako 117 zmian czynności dziennie).
293) Dane wyszczególnione w wymaganiach 286, 289 i 291 przechowuje się w sposób umożliwiający wyszukiwanie czynności w kolejności chronologicznej, nawet w przypadku nakładania się czasów.
4.5.3.2.10 Dane dotyczące używanych pojazdów
294) Karta kierowcy umożliwia przechowywanie, dla każdego dnia kalendarzowego, w którym karta jest użyta, i dla każdego okresu używania danego pojazdu w tym dniu (okres używania obejmuje wszystkie następujące po sobie cykle włożenia i wyjęcia karty w danym pojeździe, z perspektywy danych zapisanych na karcie), następujących danych:
- data i godzina pierwszego użycia pojazdu (tj. pierwsze włożenie karty w tym okresie używania pojazdu lub 00:00, jeżeli okres używania trwał w tym czasie),
- stan licznika kilometrów w chwili pierwszego użycia,
- data i godzina ostatniego użycia pojazdu, (tj. ostatnie wyjęcie karty w tym okresie używania pojazdu lub 23:59, jeżeli okres używania trwał w tym czasie),
- stan licznika kilometrów w chwili ostatniego użycia,
- numer VRN i państwo członkowskie rejestracji pojazdu,
- numer VIN pojazdu.
295) Karta kierowcy umożliwia przechowywanie 200 takich rekordów danych.
4.5.3.2.11 Miejsca i pozycje rozpoczęcia lub zakończenia dziennych okresów pracy
296) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących miejsc rozpoczęcia lub zakończenia dziennych okresów pracy, wprowadzanych przez kierowcę:
- data i godzina wprowadzenia danych (lub data/godzina odnosząca się do wpisu, jeżeli wpis wprowadza się w procedurze ręcznego wprowadzania danych),
- rodzaj wpisu (rozpoczęcie lub zakończenie, status wpisu),
- kraj i region,
- stan licznika kilometrów,
- pozycja pojazdu,
- dokładność GNSS, data i godzina określenia pozycji.
297) Pamięć karty kierowcy umożliwia przechowywanie 112 takich rekordów danych.
4.5.3.2.12 Dane sesji karty
298) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących pojazdu, dla którego otwarto bieżącą sesję:
- data i godzina otwarcia sesji (tj. włożenia karty) z dokładnością do jednej sekundy,
- numer VRN i państwo członkowskie rejestracji.
4.5.3.2.13 Dane dotyczące czynności kontrolnych
299) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących czynności kontrolnych:
- data i godzina kontroli,
- numer karty kontrolnej i państwo członkowskie wydające kartę,
- rodzaj kontroli (wyświetlanie lub drukowanie lub pobieranie danych z przyrządu rejestrującego lub pobieranie danych z karty - patrz uwaga),
- okres, dla którego pobrano dane, w przypadku pobierania danych,
- numer VRN i państwo członkowskie rejestracji pojazdu, w którym miała miejsce kontrola.
Uwaga: zgodnie z wymogami bezpieczeństwa pobieranie danych z karty jest rejestrowane wyłącznie wtedy, gdy jest wykonywane przez urządzenie rejestrujące.
300) Karta kierowcy umożliwia przechowywanie jednego takiego rekordu danych.
4.5.3.2.14 Dane dotyczące warunków szczególnych
301) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących warunków szczególnych wprowadzonych przy włożonej karcie (niezależnie od tego, do której szczeliny czytnika):
- data i godzina wprowadzenia danych,
- rodzaj warunku szczególnego.
302) Karta kierowcy umożliwia przechowywanie 112 takich rekordów danych.
4.5.3.2.15 Dane dotyczące używanych przyrządów rejestrujących
303) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących różnych przyrządów rejestrujących, w których dana karta była używana:
- data i godzina rozpoczęcia okresu używania przyrządu rejestrującego (tj. pierwsze włożenie karty do przyrządu rejestrującego dla danego okresu),
- producent przyrządu rejestrującego,
- rodzaj przyrządu rejestrującego,
- numer wersji oprogramowania przyrządu rejestrującego.
304) Karta kierowcy umożliwia przechowywanie 200 takich rekordów danych.
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 336 takich rekordów danych.
4.5.3.2.17 Status uwierzytelniania dla pozycji związanych z miejscami rozpoczęcia lub zakończenia dziennych okresów pracy (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
306a) Karta kierowcy umożliwia przechowywanie dodatkowych danych dotyczących miejsc rozpoczęcia lub zakończenia dziennych okresów pracy, wprowadzanych przez kierowcę zgodnie z pkt 4.5.3.2.11:
- data i godzina wpisu, która musi być dokładnie taka sama, jak data i godzina zapisana w EF Places w DF Tachograph_G2,
- flagę wskazującą, czy pozycja została uwierzytelniona.
306b) Pamięć karty kierowcy umożliwia przechowywanie 112 takich rekordów danych.
4.5.3.2.18 Status uwierzytelniania dla pozycji, w których osiągnięto trzy godziny skumulowanego czasu prowadzenia pojazdu (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
306c) Karta kierowcy umożliwia przechowywanie dodatkowych danych dotyczących pozycji pojazdu, w których skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin zgodnie z pkt 4.5.3.2.16:
- data i godzina, gdy skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin, która musi być dokładnie taka sama, jak data i godzina zapisana w EF GNSS_Places w DF Tachograph_G2,
- flagę wskazującą, czy pozycja została uwierzytelniona.
306d) Karta kierowcy umożliwia przechowywanie 336 takich rekordów danych.
4.5.3.2.19 Przekroczenia granicy (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
306e) Karta kierowcy umożliwia zapisanie następujących danych dotyczących przekroczeń granicy przy wkładaniu karty zgodnie z wymogiem 147b albo przy już włożonej karcie:
- kraj, który pojazd opuszcza,
- kraj, do którego pojazd wjeżdża,
- data i godzina przekroczenia granicy przez pojazd,
- pozycja pojazdu po przekroczeniu granicy,
- dokładność GNSS,
- flagę wskazującą, czy pozycja została uwierzytelniona,
- stan licznika kilometrów.
306f) Pamięć karty kierowcy umożliwia przechowywanie 1120 takich rekordów danych.
4.5.3.2.20 Operacje załadunku/rozładunku (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
306g) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących operacji załadunku/rozładunku:
- typ operacji (załadunek, rozładunek lub równoczesny załadunek/rozładunek),
- data i godzina operacji załadunku/rozładunku,
- pozycja pojazdu,
- dokładność GNSS, data i godzina określenia pozycji,
- flagę wskazującą, czy pozycja została uwierzytelniona,
- stan licznika kilometrów.
306h) Karta kierowcy umożliwia przechowywanie 1624 operacji załadunku/rozładunku.
4.5.3.2.21 Wprowadzanie typu załadunku (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
306i) Karta kierowcy umożliwia przechowywanie następujących danych dotyczących typu załadunku wprowadzanych automatycznie przez VU przy każdym włożeniu karty:
- wpisany typ załadunku (towary lub pasażerowie),
- data i godzina wpisu.
306j) Karta kierowcy umożliwia przechowywanie 336 takich rekordów danych.
4.5.3.2.22 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
306k) Karta kierowcy umożliwia przechowywanie szczegółowych ustawień tachografu posiadacza karty.
306l) Pojemność karty kierowcy na potrzeby przechowywania szczegółowych ustawień tachografu posiadacza karty wynosi 3072 bajty.
4.5.4 Karta warsztatowa
4.5.4.1 Aplikacja tachograficzna (dostępna dla przyrządów rejestrujących pierwszej i drugiej generacji)
4.5.4.1.1 Identyfikacja aplikacji
307) Karta warsztatowa umożliwia przechowywanie następujących danych identyfikujących aplikację:
- identyfikacja aplikacji tachograficznej,
- identyfikacja typu karty do tachografów.
4.5.4.1.2 Klucze i certyfikaty
308) Karta warsztatowa umożliwia przechowywanie szeregu kluczy i certyfikatów kryptograficznych, jak określono w dodatku 11 część A.
309) Karta warsztatowa umożliwia przechowywanie osobistego numeru identyfikacyjnego (kodu PIN).
4.5.4.1.3 Identyfikacja karty
310) Karta warsztatowa umożliwia przechowywanie następujących danych identyfikujących kartę:
- numer karty,
- państwo członkowskie wydające kartę, nazwa organu wydającego, data wydania,
- data rozpoczęcia okresu ważności karty, termin ważności karty.
4.5.4.1.4 Identyfikacja posiadacza karty
311) Karta warsztatowa umożliwia przechowywanie następujących danych identyfikujących posiadacza karty:
- nazwa warsztatu,
- adres warsztatu,
- nazwisko posiadacza karty,
- imię (imiona) posiadacza karty,
- preferowany język.
4.5.4.1.5 Pobieranie danych z karty
312) Karta warsztatowa umożliwia przechowywanie rekordu danych pobranych z karty, w taki sam sposób jak karta kierowcy.
4.5.4.1.6 Dane dotyczące kalibracji i korekty czasu
313) Karta warsztatowa umożliwia przechowywanie zapisów dotyczących kalibracji lub korekty czasu wykonanych przy karcie włożonej do urządzenia rejestrującego.
314) Każdy rekord danych kalibracji może zawierać następujące dane:
- cel kalibracji (aktywacja, pierwsza instalacja, instalacja, przegląd okresowy),
- identyfikacja pojazdu,
- parametry uaktualnione lub potwierdzone (w, k, l, rozmiar opon, ustawienie urządzenia ograniczenia prędkości, licznik kilometrów (nowe i stare wartości), data i godzina (nowe i stare wartości)),
- identyfikacja urządzenia rejestrującego (numer części VU, numer seryjny VU, numer seryjny czujnika ruchu).
315) Karta warsztatowa umożliwia przechowywanie co najmniej 88 takich rekordów danych.
316) Karta warsztatowa jest wyposażona w licznik pokazujący łączną liczbę kalibracji wykonanych przy użyciu tej karty.
317) Karta warsztatowa jest wyposażona w licznik pokazujący liczbę kalibracji wykonanych od ostatniego pobrania danych.
4.5.4.1.7 Dane dotyczące zdarzeń i usterek
318) Karta warsztatowa umożliwia przechowywanie rekordów danych zdarzeń i usterek, w taki sam sposób jak karta kierowcy.
319) Karta warsztatowa umożliwia przechowywanie danych dotyczących trzech ostatnich zdarzeń każdego rodzaju (łącznie 18 zdarzeń) i sześciu ostatnich usterek każdego rodzaju (łącznie 12 usterek).
4.5.4.1.8 Dane dotyczące czynności kierowcy
320) Karta warsztatowa umożliwia przechowywanie danych dotyczących czynności kierowcy, w taki sam sposób jak karta kierowcy.
321) Karta warsztatowa umożliwia przechowywanie danych dotyczących czynności kierowcy za co najmniej 1 dzień przeciętnej aktywności kierowcy.
4.5.4.1.9 Dane dotyczące używanych pojazdów
322) Karta warsztatowa umożliwia przechowywanie rekordów danych dotyczących używanego pojazdu, w taki sam sposób jak karta kierowcy.
323) Karta warsztatowa umożliwia przechowywanie co najmniej 4 takich rekordów.
4.5.4.1.10 Dane dotyczące rozpoczęcia lub zakończenia dziennych okresów pracy
324) Karta warsztatowa umożliwia przechowywanie rekordów danych dotyczących rozpoczęcia lub zakończenia dziennych okresów pracy, w taki sam sposób jak karta kierowcy.
325) Karta warsztatowa umożliwia przechowywanie co najmniej 3 par takich rekordów danych.
4.5.4.1.11 Dane sesji karty
326) Karta warsztatowa umożliwia przechowywanie rekordu danych sesji karty, w taki sam sposób jak karta kierowcy.
4.5.4.1.12 Dane dotyczące czynności kontrolnych
327) Karta warsztatowa umożliwia przechowywanie rekordu danych czynności kontrolnych, w taki sam sposób jak karta kierowcy.
4.5.4.1.13 Dane dotyczące warunków szczególnych
328) Karta warsztatowa umożliwia przechowywanie danych dotyczących warunków szczególnych, w taki sam sposób jak karta kierowcy.
329) Karta warsztatowa umożliwia przechowywanie co najmniej 2 takich rekordów.
4.5.4.2 Aplikacja tachograficzna generacji 2 (niedostępna dla pierwszej generacji przyrządów rejestrujących, dostępna dla wersji 1 i wersji 2 drugiej generacji przyrządów rejestrujących)
4.5.4.2.1 Identyfikacja aplikacji
330) Karta warsztatowa umożliwia przechowywanie następujących danych identyfikujących aplikację:
- identyfikacja aplikacji tachograficznej,
- identyfikacja typu karty do tachografów.
4.5.4.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
330a) Karta warsztatowa umożliwia przechowywanie dodatkowych danych identyfikujących aplikacje mających zastosowanie wyłącznie do wersji 2.
4.5.4.2.2 Klucze i certyfikaty
331) Karta warsztatowa umożliwia przechowywanie szeregu kluczy i certyfikatów kryptograficznych, jak określono w dodatku 11 część B.
332) Karta warsztatowa umożliwia przechowywanie osobistego numeru identyfikacyjnego (kodu PIN).
4.5.4.2.3 Identyfikacja karty
333) Karta warsztatowa umożliwia przechowywanie następujących danych identyfikujących kartę:
- numer karty,
- państwo członkowskie wydające kartę, nazwa organu wydającego, data wydania,
- data rozpoczęcia okresu ważności karty, termin ważności karty.
4.5.4.2.4 Identyfikacja posiadacza karty
334) Karta warsztatowa umożliwia przechowywanie następujących danych identyfikujących posiadacza karty:
- nazwa warsztatu,
- adres warsztatu,
- nazwisko posiadacza karty,
- imię (imiona) posiadacza karty,
- preferowany język.
4.5.4.2.5 Pobieranie danych z karty
335) Karta warsztatowa umożliwia przechowywanie rekordu danych pobranych z karty, w taki sam sposób jak karta kierowcy.
4.5.4.2.6 Dane dotyczące kalibracji i korekty czasu
336) Karta warsztatowa umożliwia przechowywanie zapisów dotyczących kalibracji lub korekty czasu wykonanych przy karcie włożonej do urządzenia rejestrującego.
337) Każdy rekord danych kalibracji może zawierać następujące dane:
- cel kalibracji (aktywacja, pierwsza instalacja, instalacja, przegląd okresowy),
- identyfikacja pojazdu,
- parametry uaktualnione lub potwierdzone (w, k, l, rozmiar opon, ustawienie urządzenia ograniczenia prędkości, licznik kilometrów (nowe i stare wartości), data i godzina (nowe i stare wartości)),
- identyfikacja urządzenia rejestrującego (numer części VU, numer seryjny VU, numer seryjny czujnika ruchu, numer seryjny urządzenia do łączności na odległość, numer seryjny urządzenia zewnętrznego GNSS, w stosownych przypadkach),
- rodzaje i identyfikatory wszystkich założonych plomb,
- możliwość korzystania przez przyrząd rejestrujący z kart do tachografów pierwszej generacji (włączona lub nie).
338) Karta warsztatowa umożliwia przechowywanie 255 takich rekordów danych.
339) Karta warsztatowa jest wyposażona w licznik pokazujący łączną liczbę kalibracji wykonanych przy użyciu tej karty.
340) Karta warsztatowa jest wyposażona w licznik pokazujący liczbę kalibracji wykonanych od ostatniego pobrania danych.
4.5.4.2.7 Dane dotyczące zdarzeń i usterek
341) Karta warsztatowa umożliwia przechowywanie rekordów danych zdarzeń i usterek, w taki sam sposób jak karta kierowcy.
342) Karta warsztatowa umożliwia przechowywanie danych dotyczących trzech ostatnich zdarzeń każdego rodzaju (łącznie 33 zdarzenia) i sześciu ostatnich usterek każdego rodzaju (łącznie 12 usterek).
4.5.4.2.8 Dane dotyczące czynności kierowcy
343) Karta warsztatowa umożliwia przechowywanie danych dotyczących czynności kierowcy, w taki sam sposób jak karta kierowcy.
344) Karta warsztatowa umożliwia przechowywanie danych dotyczących czynności kierowcy przez 1 dzień obejmujący 240 zmian czynności.
4.5.4.2.9 Dane dotyczące używanych pojazdów
345) Karta warsztatowa umożliwia przechowywanie rekordów danych dotyczących używanego pojazdu, w taki sam sposób jak karta kierowcy.
346) Karta warsztatowa umożliwia przechowywanie 8 takich rekordów danych.
4.5.4.2.10 Dane dotyczące miejsc i pozycji rozpoczęcia lub zakończenia dziennych okresów pracy
347) Karta warsztatowa umożliwia przechowywanie rekordów danych dotyczących miejsc i pozycji rozpoczęcia lub zakończenia dziennych okresów pracy, w taki sam sposób jak karta kierowcy.
348) Karta warsztatowa umożliwia przechowywanie 4 par takich rekordów danych.
4.5.4.2.11 Dane sesji karty
349) Karta warsztatowa umożliwia przechowywanie rekordu danych sesji karty, w taki sam sposób jak karta kierowcy.
4.5.4.2.12 Dane dotyczące czynności kontrolnych
350) Karta warsztatowa umożliwia przechowywanie rekordu danych czynności kontrolnych, w taki sam sposób jak karta kierowcy.
4.5.4.2.13 Dane dotyczące używanych przyrządów rejestrujących
351) Karta warsztatowa umożliwia przechowywanie następujących danych dotyczących różnych przyrządów rejestrujących, w których dana karta była używana:
- data i godzina rozpoczęcia okresu używania przyrządu rejestrującego (tj. pierwsze włożenie karty do przyrządu rejestrującego dla danego okresu),
- producent przyrządu rejestrującego,
- rodzaj przyrządu rejestrującego,
- numer wersji oprogramowania przyrządu rejestrującego.
352) Karta warsztatowa umożliwia przechowywanie 8 takich rekordów danych.
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 24 takich rekordów danych.
4.5.4.2.15 Dane dotyczące warunków szczególnych
355) Karta warsztatowa umożliwia przechowywanie danych dotyczących warunków szczególnych, w taki sam sposób jak karta kierowcy.
356) Karta warsztatowa umożliwia przechowywanie 4 takich rekordów danych.
4.5.4.2.16 Status uwierzytelniania dla pozycji związanych z miejscami rozpoczęcia lub zakończenia dziennych okresów pracy (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
356a) Karta warsztatowa umożliwia przechowywanie dodatkowych danych dotyczących miejsc rozpoczęcia lub zakończenia dziennych okresów pracy, w taki sam sposób jak karta kierowcy.
356b) Pamięć karty warsztatowej umożliwia przechowywanie 4 par takich rekordów danych.
4.5.4.2.17 Status uwierzytelniania dla pozycji, w których osiągnięto trzy godziny skumulowanego prowadzenia pojazdu (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
356c) Karta warsztatowa umożliwia przechowywanie dodatkowych danych dotyczących pozycji pojazdu, w których skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin w taki sam sposób jak karta kierowcy.
356d) Karta warsztatowa umożliwia przechowywanie 24 takich rekordów danych.
4.5.4.2.18 Przekroczenia granicy (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
356e) Karta warsztatowa umożliwia przechowywanie przekroczeń granicy, w taki sam sposób jak karta kierowcy.
356f) Pamięć karty warsztatowej umożliwia przechowywanie 4 takich rekordów danych.
4.5.4.2.19 Operacje załadunku/rozładunku (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
356g) Karta warsztatowa umożliwia przechowywanie operacji załadunku/rozładunku, w taki sam sposób jak karta kierowcy.
356h) Karta warsztatowa umożliwia przechowywanie 8 operacji załadunku, rozładunku lub równoczesnego załadunku/rozładunku.
4.5.4.2.20 Wprowadzanie typu załadunku (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
356i) Karta warsztatowa umożliwia przechowywanie wpisów typu załadunku, w taki sam sposób jak karta kierowcy.
356j) Karta warsztatowa umożliwia przechowywanie 4 takich rekordów danych.
4.5.4.2.21 Dodatkowe dane dotyczące kalibracji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
356k) Karta warsztatowa umożliwia przechowywanie dodatkowych danych identyfikujących aplikacje mających zastosowanie wyłącznie do wersji 2:
- stara wartość daty i godziny oraz numer identyfikacyjny pojazdu, które muszą być dokładnie takie same, jak wartości zapisane w EF Calibration w DF Tachograph_G2,
- domyślny typ załadunku wpisany podczas tej kalibracji,
- kraj, w którym wykonano kalibrację, oraz data i godzina dostarczenia przez odbiornik GNSS pozycji wykorzystanej do określenia tego kraju.
356l) Karta warsztatowa umożliwia przechowywanie 255 takich rekordów danych.
4.5.4.2.22 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
356m) Karta warsztatowa umożliwia przechowywanie szczegółowych ustawień tachografu posiadacza karty.
356n) Pojemność karty warsztatowej na potrzeby przechowywania szczegółowych ustawień tachografu posiadacza karty wynosi 3072 bajty.
4.5.5 Karta kontrolna
4.5.5.1 Aplikacja tachograficzna (dostępna dla przyrządów rejestrujących pier wszej i drugiej generacji)
4.5.5.1.1 Identyfikacja aplikacji
357) Karta kontrolna umożliwia przechowywanie następujących danych identyfikujących aplikację:
- identyfikacja aplikacji tachograficznej,
- identyfikacja typu karty do tachografów.
4.5.5.1.2 Klucze i certyfikaty
358) Karta kontrolna umożliwia przechowywanie szeregu kluczy i certyfikatów kryptograficznych, jak określono w dodatku 11 część A.
4.5.5.1.3 Identyfikacja karty
359) Karta kontrolna umożliwia przechowywanie następujących danych identyfikujących kartę:
- numer karty,
- państwo członkowskie wydające kartę, nazwa organu wydającego, data wydania,
- data rozpoczęcia okresu ważności karty, termin ważności karty (jeżeli jest określony).
4.5.5.1.4 Identyfikacja posiadacza karty
360) Karta kontrolna umożliwia przechowywanie następujących danych identyfikujących posiadacza karty:
- nazwa organu kontrolnego,
- adres organu kontrolnego,
- nazwisko posiadacza karty,
- imię (imiona) posiadacza karty,
- preferowany język.
4.5.5.1.5 Dane dotyczące czynności kontrolnych
361) Karta kontrolna umożliwia przechowywanie następujących danych dotyczących czynności kontrolnych:
- data i godzina kontroli,
- rodzaj kontroli (wyświetlanie lub drukowanie lub pobieranie danych z przyrządu rejestrującego lub pobieranie danych z karty),
- okres, dla którego pobrano dane (jeżeli ma zastosowanie),
- numer VRN i państwo członkowskie rejestracji kontrolowanego pojazdu,
- numer karty i państwo członkowskie wydające kontrolowaną kartę kierowcy.
362) Karta kontrolna umożliwia przechowywanie co najmniej 230 takich rekordów danych.
4.5.5.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów rejestrujących pierwszej generacji)
4.5.5.2.1 Identyfikacja aplikacji
363) Karta kontrolna umożliwia przechowywanie następujących danych identyfikujących aplikację:
- identyfikacja aplikacji tachograficznej,
- identyfikacja typu karty do tachografów.
4.5.5.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
363a) Karta kontrolna umożliwia przechowywanie dodatkowych danych identyfikujących aplikacje mających zastosowanie wyłącznie do wersji 2.
4.5.5.2.2 Klucze i certyfikaty
364) Karta kontrolna umożliwia przechowywanie szeregu kluczy i certyfikatów kryptograficznych, jak określono w dodatku 11 część B.
4.5.5.2.3 Identyfikacja karty
365) Karta kontrolna umożliwia przechowywanie następujących danych identyfikujących kartę:
- numer karty,
- państwo członkowskie wydające kartę, nazwa organu wydającego, data wydania,
- data rozpoczęcia okresu ważności karty, termin ważności karty (jeżeli jest określony).
4.5.5.2.4 Identyfikacja posiadacza karty
366) Karta kontrolna umożliwia przechowywanie następujących danych identyfikujących posiadacza karty:
- nazwa organu kontrolnego,
- adres organu kontrolnego,
- nazwisko posiadacza karty,
- imię (imiona) posiadacza karty,
- preferowany język.
4.5.5.2.5 Dane dotyczące czynności kontrolnych
367) Karta kontrolna umożliwia przechowywanie następujących danych dotyczących czynności kontrolnych:
- data i godzina kontroli,
- rodzaj kontroli (wyświetlanie lub drukowanie lub pobieranie danych z przyrządu rejestrującego lub karty lub kontrola drogowa kalibracji),
- okres, dla którego pobrano dane (jeżeli ma zastosowanie),
- numer VRN i państwo członkowskie rejestracji kontrolowanego pojazdu,
- numer karty i państwo członkowskie wydające kontrolowaną kartę kierowcy.
368) Karta kontrolna umożliwia przechowywanie co najmniej 230 takich rekordów danych.
4.5.5.2.6 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
368a) Karta kontrolna umożliwia przechowywanie szczegółowych ustawień tachografu posiadacza karty.
368b) Pojemność karty kontrolnej na potrzeby przechowywania szczegółowych ustawień tachografu posiadacza karty wynosi 3072 bajty.
4.5.6 Karta firmowa
4.5.6.1 Aplikacja tachograficzna (dostępna dla przyrządów rejestrujących pierwszej i drugiej generacji)
4.5.6.1.1 Identyfikacja aplikacji
369) Karta firmowa umożliwia przechowywanie następujących danych identyfikujących aplikację:
- identyfikacja aplikacji tachograficznej,
- identyfikacja typu karty do tachografów.
4.5.6.1.2 Klucze i certyfikaty
370) Karta firmowa umożliwia przechowywanie szeregu kluczy i certyfikatów kryptograficznych, jak określono w dodatku 11 część A.
4.5.6.1.3 Identyfikacja karty
371) Karta firmowa umożliwia przechowywanie następujących danych identyfikujących kartę:
- numer karty,
- państwo członkowskie wydające kartę, nazwa organu wydającego, data wydania,
- data rozpoczęcia okresu ważności karty, termin ważności karty (jeżeli jest określony).
4.5.6.1.4 Identyfikacja posiadacza karty
372) Karta firmowa umożliwia przechowywanie następujących danych identyfikujących posiadacza karty:
- nazwa firmy,
- adres firmy.
4.5.6.1.5 Dane dotyczące czynności wykonywanych przez firmę
373) Karta firmowa umożliwia przechowywanie następujących danych dotyczących czynności wykonywanych przez firmę:
- data i godzina czynności,
- typ czynności (blokowanie lub zdejmowanie blokady z przyrządu rejestrującego lub pobieranie danych z przyrządu rejestrującego lub pobieranie danych z karty),
- okres, dla którego pobrano dane (jeżeli ma zastosowanie),
- numer VRN i państwo członkowskie rejestracji pojazdu,
- numer karty i państwo członkowskie wydające kartę (w przypadku pobierania danych z karty).
374) Karta firmowa umożliwia przechowywanie co najmniej 230 takich rekordów danych.
4.5.6.2 Aplikacja tachograficzna 2. generacji (niedostępna dla przyrządów rejestrujących pierwszej generacji)
4.5.6.2.1 Identyfikacja aplikacji
375) Karta firmowa umożliwia przechowywanie następujących danych identyfikujących aplikację:
- identyfikacja aplikacji tachograficznej,
- identyfikacja typu karty do tachografów.
4.5.6.2.1.1 Dodatkowa identyfikacja aplikacji (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
375a) Karta firmowa umożliwia przechowywanie dodatkowych danych identyfikujących aplikacje mających zastosowanie wyłącznie do wersji 2.
4.5.6.2.2 Klucze i certyfikaty
376) Karta firmowa umożliwia przechowywanie szeregu kluczy i certyfikatów kryptograficznych, jak określono w dodatku 11 część B.
4.5.6.2.3 Identyfikacja karty
377) Karta firmowa umożliwia przechowywanie następujących danych identyfikujących kartę:
- numer karty,
- państwo członkowskie wydające kartę, nazwa organu wydającego, data wydania,
- data rozpoczęcia okresu ważności karty, termin ważności karty (jeżeli jest określony).
4.5.6.2.4 Identyfikacja posiadacza karty
378) Karta firmowa umożliwia przechowywanie następujących danych identyfikujących posiadacza karty:
- nazwa firmy,
- adres firmy.
4.5.6.2.5 Dane dotyczące czynności wykonywanych przez firmę
379) Karta firmowa umożliwia przechowywanie następujących danych dotyczących czynności wykonywanych przez firmę:
- data i godzina czynności,
- typ czynności (blokowanie lub zdejmowanie blokady z przyrządu rejestrującego lub pobieranie danych z przyrządu rejestrującego lub pobieranie danych z karty),
- okres, dla którego pobrano dane (jeżeli ma zastosowanie),
- numer VRN i państwo członkowskie rejestracji pojazdu,
- numer karty i państwo członkowskie wydające kartę (w przypadku pobierania danych z karty).
380) Karta firmowa umożliwia przechowywanie co najmniej 230 takich rekordów danych.
4.5.6.2.6 Konfiguracje przyrządu rejestrującego (brak dostępu w przypadku wersji 1 drugiej generacji przyrządów rejestrujących)
380a) Karta firmowa umożliwia przechowywanie szczegółowych ustawień tachografu posiadacza karty.
380b) Pojemność karty firmowej na potrzeby przechowywania szczegółowych ustawień tachografu posiadacza karty wynosi 3072 bajty.
5 INSTALACJA URZĄDZENIA REJESTRUJĄCEGO
5.1 Instalacja
381) Nowe urządzenie rejestrujące dostarcza się instalatorom lub producentom pojazdów w stanie nieaktywowanym, ze wszystkimi parametrami kalibracyjnymi, wyszczególnionymi w rozdziale 3.21, ustawionymi na odpowiednie i prawidłowe wartości domyślne. W przypadku gdy nie ma konkretnej odpowiedniej wartości, parametry literowe należy ustawić jako łańcuchy znaków "?", a parametry liczbowe jako "0". Dostawę części układu zabezpieczającego urządzeń rejestrujących można w razie konieczności ograniczyć podczas certyfikacji bezpieczeństwa.
382) Przed aktywacją urządzenie rejestrujące umożliwia dostęp do funkcji kalibracji, nawet jeśli nie jest w trybie kalibracyjnym.
383) Przed aktywacją urządzenia rejestrującego nie rejestruje ono ani nie przechowuje danych, o których mowa w wymogach 102-133. Niemniej jednak przed aktywacją urządzenia rejestrującego może ono rejestrować i przechowywać zdarzenia związane z próbami naruszenia zabezpieczenia zgodnie z wymogiem 117 oraz usterki urządzenia rejestrującego zgodnie z wymogiem 118.
384) W czasie instalacji producenci pojazdów wstępnie ustawiają wszystkie znane parametry.
385) Producenci pojazdów lub instalatorzy aktywują zainstalowane urządzenie rejestrujące najpóźniej przed rozpoczęciem korzystania z pojazdu w zakresie objętym rozporządzeniem (WE) nr 561/2006.
386) Aktywacja urządzenia rejestrującego uruchamiana jest automatycznie przez pierwsze włożenie ważnej karty warsztatowej do któregokolwiek czytnika karty.
387) Szczególne czynności parujące, wymagane między czujnikiem ruchu a przyrządem rejestrującym, odbywają się w razie potrzeby automatycznie przed aktywacją lub w trakcie aktywacji.
388) Podobnie szczególne czynności powiązania, wymagane między urządzeniem zewnętrznym GNSS a przyrządem rejestrującym, odbywają się w razie potrzeby automatycznie przed aktywacją lub w czasie aktywacji.
389) Po aktywowaniu urządzenia rejestrującego wszystkie funkcje i prawa dostępu do danych muszą być w pełni wdrożone.
390) Po aktywowaniu urządzenie rejestrujące przekazuje do urządzenia do łączności na odległość zabezpieczone dane niezbędne na potrzeby ukierunkowanych kontroli drogowych.
391) Po aktywowaniu urządzenia rejestrującego funkcje rejestrowania i przechowywania muszą być w pełni funkcjonalne.
392) Następnym krokiem po instalacji jest kalibracja. Podczas pierwszej kalibracji nie jest konieczne wprowadzenie identyfikacji rejestracyjnej pojazdu (VRN i państwo członkowskie), jeżeli nie jest ona znana zatwierdzonemu warsztatowi mającemu przeprowadzić kalibrację. W tej sytuacji, i tylko wtedy, właściciel pojazdu może wprowadzić numer VRN i państwo członkowskie, używając swojej karty firmowej przed rozpoczęciem korzystania z pojazdu w zakresie objętym rozporządzeniem (WE) nr 561/2006 (np. używając poleceń poprzez odpowiednie menu interfejsu człowiek-maszyna przyrządu rejestrującego). Każda aktualizacja lub potwierdzenie wprowadzonych w ten sposób danych są możliwe jedynie przy użyciu karty warsztatowej.
393) Instalacja urządzenia zewnętrznego GNSS wymaga powiązania z przyrządem rejestrującym, a następnie weryfikacji informacji o pozycji GNSS.
394) Urządzenie rejestrujące musi być umieszczone w pojeździe w taki sposób, aby kierowca miał ze swojego siedzenia dostęp do niezbędnych funkcji.
5.2 Tabliczka instalacyjna
395) Po zainstalowaniu i sprawdzeniu urządzenia rejestrującego mocuje się na nim dobrze widoczną i łatwo dostępną tabliczkę instalacyjną, wygrawerowaną lub nadrukowaną w trwały sposób. Jeżeli nie jest to możliwe, tabliczkę mocuje się na słupku "B" pojazdu, tak aby była dobrze widoczna. W przypadku pojazdów, które nie posiadają słupka "B", tabliczkę instalacyjną należy umocować w strefie drzwi pojazdu, tak aby zawsze była dobrze widoczna.
Po każdym przeglądzie przeprowadzonym przez zatwierdzonego instalatora lub warsztat, w miejsce starej tabliczki mocuje się nową.
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,
- domyślny typ załadunku związany z pojazdem.
397) Drugiej, dodatkowej tabliczki można użyć tylko w pojazdach M1 i N1, w których zainstalowany jest adapter zgodnie z dodatkiem 16 do niniejszego załącznika, oraz gdy nie ma możliwości zamieszczenia wszystkich niezbędnych informacji opisanych w wymogu 396. W takich przypadkach ta dodatkowa tabliczka zawiera co najmniej cztery ostatnie tiret opisane w wymaganiu 396.
Drugą dodatkową tabliczkę mocuje się w stosownych przypadkach obok lub w pobliżu pierwszej podstawowej tabliczki opisanej w wymaganiu 396 i zapewnia się jej taki sam poziom ochrony. Na dodatkowej tabliczce umieszcza się ponadto nazwę, adres lub nazwę handlową zatwierdzonego instalatora lub warsztatu, który dokonał instalacji, oraz datę instalacji.
5.3 Plombowanie
398) Następujące części muszą być zaplombowane:
- Wszelkie połączenia, których rozłączenie może powodować niewykrywalne zmiany danych lub niewykrywalne utraty danych (może to dotyczyć np. instalacji czujnika ruchu na skrzyni biegów, adapterów w pojazdach M1/N1, połączenia z urządzeniem zewnętrznym GNSS lub przyrządu rejestrującego);
- Tabliczka instalacyjna, chyba że jest przymocowana w taki sposób, że nie można jej usunąć bez uszkodzenia wykonanych na niej oznaczeń.
398a Plomby, o których mowa powyżej, muszą być certyfikowane zgodnie z normą EN 16882:2016.
399) Plomby, o których mowa powyżej, mogą być usunięte:
- w nagłych przypadkach,
- w celu zainstalowania, wyregulowania lub naprawy urządzenia ograniczenia prędkości lub innego urządzenia istotnego dla bezpieczeństwa drogowego, z zastrzeżeniem że urządzenie rejestrujące nadal pracuje niezawodnie i prawidłowo i zostanie powtórnie zaplombowane przez zatwierdzonego instalatora lub warsztat (zgodnie z rozdziałem 6) niezwłocznie po zainstalowaniu urządzenia ograniczenia prędkości lub innego urządzenia istotnego dla bezpieczeństwa drogowego lub w terminie siedmiu dni w pozostałych przypadkach.
400) Każdy przypadek zdjęcia takiej plomby wymaga sporządzenia pisemnego oświadczenia podającego powody takiego działania, a oświadczenie to udostępniane jest właściwemu organowi.
401) Plomby muszą mieć numer identyfikacyjny przydzielony przez ich producenta. Numer ten jest niepowtarzalny i różny od innych numerów plomb przydzielonych przez innych producentów plomb.
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.
402) Na plombie musi być wolne miejsce, na którym zatwierdzeni instalatorzy, warsztaty lub producenci pojazdów mogą dodać specjalny znak zgodnie z art. 5 ust. 3 sekcji 2 części C załącznika 31 do Umowy o handlu i współpracy między Unią Europejską i Europejską Wspólnotą Energii Atomowej, z jednej strony, a Zjednoczonym Królestwem Wielkiej Brytanii i Irlandii Północnej, z drugiej strony..
Znak ten nie może zakrywać numeru identyfikacyjnego plomby.
403) Producenci plomb muszą być zarejestrowani w specjalnej bazie danych, gdy otrzymują model plomby certyfikowany zgodnie z normą EN 16882:2016, i muszą udostępniać publicznie numery identyfikacyjne plomb w procedurze, którą ma określić Komisja Europejska.
404) Zatwierdzone warsztaty i producenci pojazdów korzystają, w ramach rozporządzenia (UE) nr 165/2014, wyłącznie z plomb certyfikowanych zgodnie z normą EN 16882:2016 od producentów plomb zapisanych w bazie danych, o której mowa powyżej.
405) Producenci plomb i ich dystrybutorzy zachowują pełną dokumentację umożliwiającą identyfikowalność plomb sprzedawanych do użytku w ramach rozporządzenia (UE) nr 165/2014 i są gotowi do jej przedłużenia właściwym organom krajowym w razie potrzeby.
406) Niepowtarzalne numery identyfikacyjne plomb muszą być widoczne na tabliczce instalacyjnej.
6 KONTROLE, PRZEGLĄDY I NAPRAWY
Wymogi dotyczące okoliczności, w jakich można usunąć plomby, określono w rozdziale 5.3 niniejszego załącznika.
6.1 Zatwierdzanie instalatorów, warsztatów i producentów pojazdów
Państwa członkowskie zatwierdzają, regularnie kontrolują i certyfikują instytucje odpowiadające za:
- instalacje,
- kontrole,
- przeglądy,
- naprawy.
Karty warsztatowe wydaje się wyłącznie instalatorom lub warsztatom zatwierdzonym do aktywowania lub kalibrowania urządzeń rejestrujących zgodnie z niniejszym załącznikiem i, chyba że istnieją inne należyte uzasadnienia,
- którzy nie kwalifikują się do posiadania karty firmowej,
- i których inna działalność zawodowa nie stanowi potencjalnego zagrożenia dla ogólnego bezpieczeństwa systemu zgodnie z wymogami w dodatku 10.
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.
6.3 Przegląd instalacyjny
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ę.
6.4 Przeglądy okresowe
409) Przeglądy okresowe urządzeń zainstalowanych w pojazdach przeprowadza się po każdej naprawie urządzenia lub po jakiejkolwiek zmianie współczynnika charakterystycznego pojazdu lub obwodu tocznego opon, lub gdy czas UTC urządzenia różni się od czasu UTC o więcej niż 5 minut, lub przy zmianie numeru VRN i przynajmniej raz w okresie dwóch lat (24 miesięcy) od ostatniej kontroli.
410) Przeglądy te obejmują następujące kontrole:
- czy urządzenie rejestrujące działa prawidłowo, włącznie z funkcją przechowywania danych na kartach do tachografów oraz łącznością z czytnikami na odległość,
- czy jest zachowana zgodność z wymaganiami rozdziału 3.2.1 i 3.2.2 co do maksymalnych tolerancji przy instalacji,
- czy jest zachowana zgodność z przepisami rozdziałów 3.2.3 i 3.3,
- czy urządzenie rejestrujące opatrzone jest znakiem homologacji typu,
- czy tabliczka instalacyjna określona w wymaganiu 396 oraz tabliczka określona w wymaganiu 225 są zamocowane,
- rozmiaru opon i faktycznego obwodu tocznego opon,
- czy do urządzenia nie są podłączone żadne urządzenia służące do manipulacji,
- czy plomby są prawidłowo założone, w dobrym stanie, czy ich numery identyfikacyjne są ważne (producent plomb zatwierdzony w bazie KE) oraz czy ich numery identyfikacyjne odpowiadają oznakowaniom na tabliczce instalacyjnej (zob. wymaganie 401),
- czy identyfikator wersji przechowywanej mapy cyfrowej jest najnowszym identyfikatorem.
410a) W przypadku wykrycia manipulacji przez właściwe organy krajowe pojazd może zostać wysłany do zatwierdzonego warsztatu w celu dokonania ponownej kalibracji urządzenia rejestrującego.
411) Jeżeli jedno ze zdarzeń wymienionych w rozdziale 3.9 (Wykrywanie zdarzeń lub usterek) pojawiło się od czasu poprzedniego przeglądu i producenci tachografów lub organy krajowe uważają, że stwarza ono zagrożenie dla bezpieczeństwa urządzenia, warsztat:
a. porównuje dane identyfikacyjne czujnika ruchu podłączonego do skrzyni biegów z danymi sparowanego czujnika ruchu zarejestrowanymi w przyrządzie rejestrującym;
b. sprawdza, czy informacje zapisane na tabliczce instalacyjnej są zgodne z informacjami zawartymi w przyrządzie rejestrującym;
c. sprawdza, czy numer seryjny czujnika ruchu i numer homologacji, jeżeli są nadrukowane na obudowie czujnika ruchu, są zgodne z informacjami przechowywanymi w pamięci danych urządzenia rejestrującego;
d. porównuje dane identyfikacyjne umieszczone na tabliczce znamionowej ewentualnego urządzenia zewnętrznego GNSS z danymi przechowywanymi w pamięci danych przyrządu rejestrującego.
412) Warsztaty odnotowują w swoich sprawozdaniach z przeglądu wszystkie ustalenia dotyczące zniszczonych plomb lub urządzeń służących do manipulacji. Warsztaty przechowują przedmiotowe sprawozdania co najmniej przez 2 lata i udostępniają je każdorazowo na wniosek właściwego organu.
413) W ramach przeglądów wykonuje się kalibrację i zapobiegawczą wymianę plomb, za których montaż odpowiadają warsztaty.
6.5 Wyznaczanie błędów
414) Wyznaczanie błędów po zainstalowaniu i podczas użytkowania jest wykonywane w następujących warunkach, które stanowią warunki odniesienia:
- pojazd bez obciążenia w stanie gotowym do jazdy,
- ciśnienie w ogumieniu zgodne z instrukcjami producenta,
- zużycie ogumienia w granicach dopuszczalnych przepisami krajowymi,
- ruch pojazdu:
- pojazd porusza się napędzany własnym silnikiem, po linii prostej i po poziomej powierzchni, z prędkością 50 ± 5 km/h. Odległość pomiarowa wynosi przynajmniej 1 000 m.
- sprawdzenie może być również przeprowadzone inną metodą, np. na odpowiednim stanowisku warsztatowym, pod warunkiem że zapewni ono porównywalną dokładność.
6.6 Naprawy
415) Warsztaty mogą pobierać dane z urządzenia rejestrującego w celu przekazania tych danych odpowiedniej firmie przewozowej.
416) Zatwierdzone warsztaty wydają firmom przewozowym zaświadczenie o niemożliwości pobrania danych, w przypadku gdy uszkodzenie urządzenia rejestrującego uniemożliwia pobranie zarejestrowanych danych nawet po naprawie w tym warsztacie. Warsztaty przechowują kopię każdego wydanego zaświadczenia przez okres co najmniej dwóch lat.
7 WYDAWANIE KART
Procedury wydawania kart określone przez państwa członkowskie spełniają następujące wymagania:
417) Pierwsza karta do tachografów wydana wnioskodawcy ma numer karty równy numerowi kolejnemu (jeżeli ma zastosowanie), a numer wymiany i numer odnowienia ustawione na "0".
418) Numery karty wszystkich nieosobistych kart do tachografów wydanych jednemu organowi kontrolnemu lub jednemu warsztatowi lub jednej firmie przewozowej mają te same pierwsze 13 cyfr i wszystkie mają różny numer kolejny.
419) Karta do tachografów wydana jako duplikat istniejącej karty do tachografów ma ten sam numer karty co karta zastąpiona, z wyjątkiem numeru wymiany, który jest zwiększany o "1" (w kolejności 0, ..., 9, A, ..., Z).
420) Karta do tachografów wydana jako duplikat istniejącej karty do tachografów ma ten sam termin ważności karty co karta zastąpiona.
421) Karta do tachografów wydana jako odnowienie istniejącej karty do tachografów ma ten sam numer karty co karta odnowiona, z wyjątkiem numeru wymiany, który jest ustawiony na "0" i numeru odnowienia, który jest zwiększany o "1" (w kolejności 0, ..., 9, A, ..., Z).
422) Przy wymianie istniejącej karty do tachografów w celu zmiany danych administracyjnych stosuje się te same zasady co przy odnawianiu, jeżeli odbywa się w tym samym państwie członkowskim, lub te same zasady co przy pierwszym wydaniu, jeżeli odbywa się w innym państwie członkowskim.
423) W rubryce "nazwisko posiadacza karty" w przypadku nieosobistych kart warsztatowych lub kontrolnych wpisuje się albo nazwę warsztatu lub organu kontrolnego albo nazwisko instalatora lub funkcjonariusza służb kontrolnych, według uznania Stron.
424) Państwa członkowskie i Zjednoczone Królestwo wymieniają dane drogą elektroniczną w celu zapewnienia niepowtarzalności wydawanych kart kierowcy zgodnie z art. 13 sekcji 2 części C załącznika 31 do Umowy o handlu i współpracy między Unią Europejską i Europejską Wspólnotą Energii Atomowej, z jednej strony, a Zjednoczonym Królestwem Wielkiej Brytanii i Irlandii Północnej, z drugiej strony.
8 HOMOLOGACJA TYPU URZĄDZEŃ REJESTRUJĄCYCH I KART DO TACHOGRAFÓW
8.1 Uwagi ogólne
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ść.
425) Urządzenie rejestrujące dostarcza się do homologacji w stanie kompletnym z wszystkimi zintegrowanymi urządzeniami dodatkowymi.
426) Homologacja typu urządzenia rejestrującego i kart do tachografów obejmuje badania związane z bezpieczeństwem, badania funkcjonalności i badania interoperacyjności. Pozytywne wyniki każdego z tych badań potwierdza się odpowiednim świadectwem.
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.
428) O wszelkich modyfikacjach oprogramowania lub sprzętu urządzenia lub rodzaju materiałów użytych do wytworzenia urządzenia należy, przed zastosowaniem, zawiadomić organ, który wydał homologację typu dla urządzenia. Organ ten potwierdza producentowi rozszerzenie homologacji typu lub też może zażądać uaktualnienia lub potwierdzenia stosownych świadectw funkcjonalności, bezpieczeństwa lub interoperacyjności.
429) Procedury aktualizacji oprogramowania w prawidłowo funkcjonującym urządzeniu rejestrującym zatwierdza organ, który wydał homologację typu dla tego urządzenia rejestrującego. Aktualizacja oprogramowania nie może zmienić ani usunąć żadnych danych dotyczących czynności kierowcy przechowywanych w pamięci urządzenia rejestrującego. Oprogramowanie można aktualizować wyłącznie na odpowiedzialność producenta urządzenia.
430) Nie można odmówić homologacji typu zmian w oprogramowaniu, których celem jest aktualizacja wcześniej homologowanego typu urządzenia rejestrującego, jeżeli takie zmiany dotyczą wyłącznie funkcji nieokreślonych w niniejszym załączniku. Aktualizacja oprogramowania urządzenia rejestrującego może nie obejmować wprowadzania nowych zestawów znaków, jeśli nie jest to technicznie wykonalne.
8.2 Świadectwo bezpieczeństwa
431) Świadectwo bezpieczeństwa wydaje się zgodnie z przepisami dodatku 10 do niniejszego załącznika. Elementy składowe urządzenia rejestrującego objęte certyfikacją to przyrząd rejestrujący, czujnik ruchu, urządzenie zewnętrzne GNSS i karty do tachografów.
432) W wyjątkowej sytuacji, gdy organy certyfikacji bezpieczeństwa odmawiają certyfikowania nowego urządzenia z powodu przestarzałych mechanizmów bezpieczeństwa, homologację typu przyznaje się nadal tylko w tych konkretnych i wyjątkowych okolicznościach oraz jeżeli, zgodnie z rozporządzeniem, nie istnieje rozwiązanie alternatywne.
433) W takiej sytuacji dane państwo członkowskie bezzwłocznie informuje Komisję Europejską, która w ciągu dwunastu miesięcy kalendarzowych od przyznania homologacji typu wszczyna procedurę mającą na celu zapewnienie przywrócenia poziomu bezpieczeństwa do stanu początkowego.
8.3 Świadectwo funkcjonalności
434) Każdy ubiegający się o homologację typu dostarcza organowi Strony właściwemu dla homologacji typu wszelkie materiały i dokumentacje, jakie organ ten uzna za niezbędne.
435) W ciągu jednego miesiąca od złożenia wniosku producenci dostarczają odpowiednie próbki produktów posiadających homologację typu i związaną z nimi dokumentację wymaganą przez laboratoria wyznaczone do przeprowadzenia badań funkcjonalności. Wnioskodawca ponosi wszystkie koszty wynikające z przedmiotowego wniosku. Laboratoria zachowują poufność wszystkich informacji wrażliwych pod względem handlowym.
436) Świadectwo funkcjonalności wydaje się producentowi wyłącznie po pozytywnym przejściu przynajmniej przez wszystkie badania funkcjonalności wyszczególnione w dodatku 9.
437) Organ właściwy dla homologacji typu wydaje świadectwo funkcjonalności. W świadectwie tym podaje się, oprócz nazwy (nazwiska) otrzymującego świadectwo i identyfikacji modelu, szczegółowy wykaz wykonanych badań i uzyskanych wyników.
438) W świadectwie funkcjonalności każdego elementu składowego urządzenia rejestrującego wskazuje się także numery homologacji typu wszystkich innych homologowanych kompatybilnych elementów składowych urządzenia rejestrującego przebadanych do celów certyfikacji.
439) W świadectwie funkcjonalności każdego elementu składowego urządzenia rejestrującego wskazuje się także normę CEN lub ISO, na podstawie której certyfikowano interfejs funkcjonalny.
8.4 Świadectwo interoperacyjności
440) Badania interoperacyjności przeprowadza jedno laboratorium w imieniu i na odpowiedzialność Komisji Europejskiej.
441) Laboratorium rejestruje wnioski o badania interoperacyjności złożone przez producentów w kolejności chronologicznej napływu tych wniosków.
442) Wnioski rejestruje się oficjalnie tylko wtedy, gdy w posiadaniu laboratorium znajdują się:
- komplet materiałów i dokumentów niezbędnych do takich badań interoperacyjności,
- odpowiednie świadectwo bezpieczeństwa,
- odpowiednie świadectwo funkcjonalności. Producenta zawiadamia się o dacie rejestracji wniosku.
443) Laboratorium nie może przeprowadzać żadnych badań interoperacyjności urządzeń rejestrujących ani kart do tachografów, które nie przeszły pomyślnie analizy podatności na zagrożenia w ramach ich oceny bezpieczeństwa, a także oceny funkcjonalnej, poza wyjątkowymi sytuacjami opisanymi w wymogu 432.
444) Producent wnioskujący o przeprowadzenie badań interoperacyjności zobowiązuje się do pozostawienia w laboratorium, które ma przeprowadzić te badania, kompletu materiałów i dokumentów, które dostarczył do przeprowadzenia tych badań.
445) Badania interoperacyjności przeprowadza się, zgodnie z przepisami dodatku 9 do niniejszego załącznika, dla, odpowiednio, wszystkich typów urządzenia rejestrującego lub kart do tachografów:
- które mają jeszcze ważną homologację typu, lub
- których homologacja typu jest w toku i które mają ważne świadectwo interoperacyjności.
446) Badania interoperacyjności obejmują wszystkie generacje urządzeń rejestrujących lub kart do tachografów będące nadal w użyciu.
447) Laboratorium wydaje producentowi świadectwo interoperacyjności tylko wówczas, gdy objęte nim urządzenia pomyślnie przejdą wszystkie wymagane badania interoperacyjności, i po wykazaniu przez producenta, że wydano zarówno ważne świadectwo funkcjonalności, jak i ważne świadectwo bezpieczeństwa dla produktu, z wyjątkiem wyjątkowych okoliczności opisanych w wymogu 432.
448) Jeżeli co najmniej jedno urządzenie rejestrujące lub karta do tachografów nie przejdą pomyślnie badań interoperacyjności, świadectwa interoperacyjności nie wydaje się, dopóki wnioskujący producent nie wprowadzi niezbędnych poprawek i dopóki nie przejdą one pomyślnie przez badania interoperacyjności. Laboratorium, przy pomocy zainteresowanych producentów, rozpoznaje przyczynę usterki interoperacyjności i dokłada starań, by pomóc wnioskującemu producentowi w znalezieniu rozwiązania technicznego. W przypadku gdy producent modyfikuje swój produkt, odpowiada on za uzyskanie potwierdzenia właściwych organów, że świadectwo bezpieczeństwa i świadectwo funkcjonalności nadal zachowują ważność.
449) Świadectwo interoperacyjności ważne jest przez sześć miesięcy. Zostaje ono odwołane na koniec tego okresu, jeżeli producent nie uzyska odpowiadającego mu świadectwa homologacji typu. Producent przekazuje to świadectwo organowi homologacji typu w państwie członkowskim, który wydał świadectwo funkcjonalności.
450) Żaden element, który może być źródłem usterki interoperacyjności, nie może być użyty do osiągania korzyści z pozycji dominującej ani prowadzić do uzyskania takiej pozycji.
8.5 Świadectwo homologacji typu
451) Organ homologacji typu w państwie członkowskim może wydać świadectwo homologacji typu, jeżeli posiada trzy wymagane świadectwa.
452) W świadectwie homologacji typu każdego elementu składowego urządzenia rejestrującego wskazuje się także numery homologacji typu innych homologowanych interoperacyjnych urządzeń rejestrujących.
453) Organ homologacji typu przekazuje kopię świadectwa homologacji typu do laboratorium właściwego do przeprowadzenia badań interoperacyjności równocześnie z dostarczeniem świadectwa producentowi.
454) Laboratorium właściwe do przeprowadzenia badań interoperacyjności prowadzi publiczną stronę internetową, na której znajduje się uaktualniony wykaz modeli urządzeń rejestrujących lub kart do tachografów:
- dla których zarejestrowano wniosek o badania interoperacyjności,
- które uzyskały świadectwo interoperacyjności (nawet czasowe),
- które uzyskały świadectwo homologacji typu.
8.6 Procedura szczególna: pierwsze świadectwa interoperacyjności dla urządzeń rejestrujących i kart do tachografów 2. generacji
455) Przez cztery miesiące od czasu, gdy pierwsza para urządzeń rejestrujących 2. generacji i kart do tachografów 2. generacji (karty kierowcy, warsztatowe, kontrolne i firmowe) uzyska świadectwa interoperacyjności, wszelkie wydane świadectwa interoperacyjności (łącznie z pierwszymi), w odniesieniu do wniosków zarejestrowanymi w tym okresie, uważa się za czasowe.
456) Jeżeli na koniec tego okresu wszystkie produkty, których to dotyczy, współdziałają, wszystkie odpowiednie świadectwa interoperacyjności zastępuje się świadectwem ostatecznym.
457) Jeżeli w tym okresie wykryje się usterki interoperacyjności, laboratorium właściwe do przeprowadzenia badań interoperacyjności rozpoznaje przyczyny problemów z pomocą wszystkich zainteresowanych producentów i zachęca ich do wprowadzenia niezbędnych poprawek.
458) Jeżeli na koniec tego okresu nadal występują problemy interoperacyjności, laboratorium właściwe do przeprowadzenia badań interoperacyjności, we współpracy z zainteresowanymi producentami i organami homologacji typu, które wydały odpowiednie świadectwa funkcjonalności, szuka przyczyn usterek interoperacyjności i ustala, jakie poprawki powinien wprowadzić każdy z zainteresowanych producentów. Poszukiwanie rozwiązań technicznych trwa maksymalnie dwa miesiące, po czym, jeśli nie zostanie znalezione wspólne rozwiązanie, Komisja, po konsultacji z laboratorium właściwym do przeprowadzenia badań interoperacyjności, decyduje, które urządzenie(-a) i karty otrzymują ostateczne świadectwa interoperacyjności wraz z uzasadnieniem swojej decyzji.
459) Wszelkie wnioski o przeprowadzenie badań interoperacyjności, zarejestrowane przez laboratorium w okresie między końcem czteromiesięcznego okresu po dostarczeniu pierwszego czasowego świadectwa interoperacyjności a datą decyzji Komisji, o której mowa w wymaganiu 455, są odraczane aż do rozwiązania początkowych problemów interoperacyjności. Następnie wnioski te rozpatruje się w kolejności chronologicznej ich rejestracji.
Dodatek 1 24
SPIS DANYCH:
SPIS DANYCH:
1. WPROWADZENIE ........................................................................................................
1.1. Podejście do definicji typów danych .................................................................................
1.2. Odniesienia ......................................................................................................................
2. DEFINICJE TYPÓW DANYCH ....................................................................................
2.1. ActivityChangeInfo ...........................................................................................................
2.2. Address ...........................................................................................................................
2.3. AESKey ..........................................................................................................................
2.4. AES128Key ....................................................................................................................
2.5. AES192Key ....................................................................................................................
2.6. AES256Key ....................................................................................................................
2.7. BCDString .......................................................................................................................
2.8. CalibrationPurpose ...........................................................................................................
2.9. CardActivityDailyRecord .................................................................................................
2.10. CardActivityLengthRange .................................................................................................
2.11. CardApprovalNumber .....................................................................................................
2.11a. CardBorderCrossing
2.11b. CardBorderCrossingRecord
2.12. CardCertificate ................................................................................................................
2.13. CardChipIdentification .....................................................................................................
2.14. CardConsecutiveIndex .....................................................................................................
2.15. CardControlActivityDataRecord ......................................................................................
2.16. CardCurrentUse ..............................................................................................................
2.17. CardDriverActivity ...........................................................................................................
2.18. CardDrivingLicenceInformation ........................................................................................
2.19. CardEventData ................................................................................................................
2.20. CardEventRecord ............................................................................................................
2.21. CardFaultData .................................................................................................................
2.22. CardFaultRecord .............................................................................................................
2.23. CardIccIdentification ........................................................................................................
2.24. CardIdentification .............................................................................................................
2.24a. CardLoadTypeEntries
2.24b. CardLoadTypeEntryRecord
2.24c. CardLoadUnloadOperations
2.24d. CardLoadUnloadRecord
2.25. CardMACertificate ..........................................................................................................
2.26. CardNumber ...................................................................................................................
2.26a. CardPlaceAuthDailyWorkPeriod
2.27. CardPlaceDailyWorkPeriod .............................................................................................
2.28. CardPrivateKey ...............................................................................................................
2.29. CardPublicKey ................................................................................................................
2.30. CardRenewalIndex ..........................................................................................................
2.31. CardReplacementIndex ....................................................................................................
2.32. CardSignCertificate ..........................................................................................................
2.33. CardSlotNumber .............................................................................................................
2.34. CardSlotsStatus ...............................................................................................................
2.35. CardSlotsStatusRecordArray ...........................................................................................
2.36. CardStructureVersion ......................................................................................................
2.37. CardVehicleRecord .........................................................................................................
2.38. CardVehiclesUsed ...........................................................................................................
2.39. CardVehicleUnitRecord ...................................................................................................
2.40. CardVehicleUnitsUsed .....................................................................................................
2.41. Certyfikat .........................................................................................................................
2.42. CertificateContent ............................................................................................................
2.43. CertificateHolderAuthorisation ..........................................................................................
2.44. CertificateRequestID ........................................................................................................
2.45. CertificationAuthorityKID ................................................................................................
2.46. CompanyActivityData ......................................................................................................
2.47. CompanyActivityType ......................................................................................................
2.48. CompanyCardApplicationIdentification .............................................................................
2.48a. CompanyCardApplicationIdentificationV2
2.49. CompanyCardHolderIdentification ...................................................................................
2.50. ControlCardApplicationIdentification ................................................................................
2.50a. ControlCardApplicationIdentificationV2
2.51. ControlCardControlActivityData ......................................................................................
2.52. ControlCardHolderIdentification .......................................................................................
2.53. ControlType ....................................................................................................................
2.54. CurrentDateTime .............................................................................................................
2.55. CurrentDateTimeRecordArray .........................................................................................
2.56. DailyPresenceCounter ......................................................................................................
2.57. Datef ...............................................................................................................................
2.58. DateOfDayDownloaded ...................................................................................................
2.59. DateOfDayDownloadedRecordArray ...............................................................................
2.60. Distance ...........................................................................................................................
2.60a. DownloadInterfaceVersion
2.61. DriverCardApplicationIdentification ..................................................................................
2.61a. DriverCardApplicationIdentificationV2
2.62. DriverCardHolderIdentification .........................................................................................
2.63. Zarezerwowany dla przyszłego użytku ..........................................................................................................
2.64. EGFCertificate .................................................................................................................
2.65. EmbedderIcAssemblerId ..................................................................................................
2.66. EntryTypeDailyWorkPeriod .............................................................................................
2.67. EquipmentType ................................................................................................................
2.68. EuropeanPublicKey .........................................................................................................
2.69. EventFaultRecordPurpose ................................................................................................
2.70. EventFaultType ................................................................................................................
2.71. ExtendedSealIdentifier ......................................................................................................
2.72. ExtendedSerialNumber ....................................................................................................
2.73. FullCardNumber ..............................................................................................................
2.74. FullCardNumberAndGeneration .......................................................................................
2.75. Generation .......................................................................................................................
2.76. GeoCoordinates ...............................................................................................................
2.77. GNSSAccuracy ...............................................................................................................
2.78. GNSSAccumulatedDriving ..................................................................................................
2.79. GNSSAccumulatedDrivingRecord ......................................................................................
2.79a. GNSSAuthAccumulatedDriving
2.79b. GNSSAuthStatusADRecord
2.79c. GNSSPlaceAuthRecord
2.80. GNSSPlaceRecord ..........................................................................................................
2.81. HighResOdometer ...........................................................................................................
2.82. HighResTripDistance ........................................................................................................
2.83. HolderName ....................................................................................................................
2.84. Zarezerwowane dla przyszłego użytku.....................................................................................................
2.85. K-ConstantOfRecordingEquipment ..................................................................................
2.86. KeyIdentifier ....................................................................................................................
2.87. KMWCKey ....................................................................................................................
2.88. Language .........................................................................................................................
2.89. LastCardDownload ..........................................................................................................
2.89a. LengthOfFollowingData
2.90. LinkCertificate .................................................................................................................
2.90a. LoadType
2.91. L-TyreCircumference .......................................................................................................
2.92. MAC ...............................................................................................................................
2.93. ManualInputFlag ..............................................................................................................
2.94. ManufacturerCode ...........................................................................................................
2.95. ManufacturerSpecificEventFaultData ................................................................................
2.96. MemberStateCertificate ...................................................................................................
2.97. MemberStateCertificateRecordArray ...............................................................................
2.98. MemberStatePublicKey ...................................................................................................
2.99. Name ..............................................................................................................................
2.100. NationAlpha ....................................................................................................................
2.101. NationNumeric ................................................................................................................
2.101a. NoOfBorderCrossingRecords
2.102. NoOfCalibrationRecords .................................................................................................
2.103. NoOfCalibrationsSinceDownload .....................................................................................
2.104. NoOfCardPlaceRecords ..................................................................................................
2.105. NoOfCardVehicleRecords ...............................................................................................
2.106. NoOfCardVehicleUnitRecords .........................................................................................
2.107. NoOfCompanyActivityRecords ........................................................................................
2.108. NoOfControlActivityRecords ...........................................................................................
2.109. NoOfEventsPerType ........................................................................................................
2.110. NoOfFaultsPerType .........................................................................................................
2.111. NoOfGNSSADRecords ..................................................................................................
2.111a. NoOfLoadUnloadRecords
2.112. NoOfSpecificConditionRecords .......................................................................................
2.112a. NoOfLoadTypeEntryRecords
2.113. OdometerShort, ...............................................................................................................
2.114. OdometerValueMidnight ..................................................................................................
2.114a. OperationType
2.115. OdometerValueMidnightRecordArray ..............................................................................
2.116. OverspeedNumber ..........................................................................................................
2.116a. PlaceAuthRecord
2.116b. PlaceAuthStatusRecord
2.117. PlaceRecord ....................................................................................................................
2.117a. PositionAuthenticationStatus
2.118. PreviousVehicleInfo .........................................................................................................
2.119. PublicKey ........................................................................................................................
2.120. RecordType .....................................................................................................................
2.121. RegionAlpha ....................................................................................................................
2.122. RegionNumeric ................................................................................................................
2.123. RemoteCommunicationModuleSerialNumber ....................................................................
2.124. RSAKeyModulus ............................................................................................................
2.125. RSAKeyPrivateExponent .................................................................................................
2.126. RSAKeyPublicExponent ..................................................................................................
2.127. RtmData ..........................................................................................................................
2.128. SealDataCard ..................................................................................................................
2.129. SealDataVu .....................................................................................................................
2.130. SealRecord ......................................................................................................................
2.131. SensorApprovalNumber ..................................................................................................
2.132. SensorExternalGNSSApprovalNumber ............................................................................
2.133. SensorExternalGNSSCoupledRecord ..............................................................................
2.134. SensorExternalGNSSIdentification ...................................................................................
2.135. SensorExternalGNSSInstallation .......................................................................................
2.136. SensorExternalGNSSOSIdentifier ....................................................................................
2.137. SensorExternalGNSSSCIdentifier ....................................................................................
2.138. SensorGNSSCouplingDate ..............................................................................................
2.139. SensorGNSSSerialNumber ..............................................................................................
2.140. SensorIdentification ..........................................................................................................
2.141. SensorInstallation .............................................................................................................
2.142. SensorInstallationSecData ................................................................................................
2.143. SensorOSIdentifier ...........................................................................................................
2.144. SensorPaired ...................................................................................................................
2.145. SensorPairedRecord ........................................................................................................
2.146. SensorPairingDate ............................................................................................................
2.147. SensorSCIdentifier ...........................................................................................................
2.148. SensorSerialNumber ........................................................................................................
2.149. Podpis .............................................................................................................................
2.150. SignatureRecordArray ......................................................................................................
2.151. SimilarEventsNumber .......................................................................................................
2.152. SpecificConditionRecord ..................................................................................................
2.153. SpecificConditions ...........................................................................................................
2.154. SpecificConditionType .....................................................................................................
2.155. Prędkość .........................................................................................................................
2.156. SpeedAuthorised .............................................................................................................
2.157. SpeedAverage .................................................................................................................
2.158. SpeedMax .......................................................................................................................
2.158a. TachographCardsGen1Suppression
2.159. TachographPayload .........................................................................................................
2.160. Zarezerwowany dla przyszłego użytku ..........................................................................................
2.161. TDesSessionKey .............................................................................................................
2.162. TimeReal .........................................................................................................................
2.163. TyreSize ..........................................................................................................................
2.164. VehicleIdentificationNumber .............................................................................................
2.165. VehicleIdentificationNumberRecordArray .........................................................................
2.166. VehicleRegistrationIdentification .......................................................................................
2.166a. VehicleRegistrationIdentificationRecordArray
2.167. VehicleRegistrationNumber ..............................................................................................
2.168. VehicleRegistrationNumberRecordArray ..........................................................................
2.169. VuAbility .........................................................................................................................
2.170. VuActivityDailyData .........................................................................................................
2.171. VuActivityDailyRecordArray ............................................................................................
2.172. VuApprovalNumber ........................................................................................................
2.173. VuCalibrationData ...........................................................................................................
2.174. VuCalibrationRecord .......................................................................................................
2.175. VuCalibrationRecordArray ...............................................................................................
2.176. VuCardIWData ...............................................................................................................
2.177. VuCardIWRecord ...........................................................................................................
2.178. VuCardIWRecordArray ..................................................................................................
2.179. VuCardRecord ................................................................................................................
2.180. VuCardRecordArray .......................................................................................................
2.181. VuCertificate ....................................................................................................................
2.182. VuCertificateRecordArray ................................................................................................
2.183. VuCompanyLocksData ....................................................................................................
2.184. VuCompanyLocksRecord ................................................................................................
2.185. VuCompanyLocksRecordArray .......................................................................................
2.185a. VuConfigurationLengthRange
2.186. VuControlActivityData .....................................................................................................
2.187. VuControlActivityRecord .................................................................................................
2.188. VuControlActivityRecordArray ........................................................................................
2.189. VuDataBlockCounter .......................................................................................................
2.190. VuDetailedSpeedBlock ....................................................................................................
2.191. VuDetailedSpeedBlockRecordArray ................................................................................
2.192. VuDetailedSpeedData ......................................................................................................
2.192a. VuDigitalMapVersion
2.193. VuDownloadablePeriod ...................................................................................................
2.194. VuDownloadablePeriodRecordArray ...............................................................................
2.195. VuDownloadActivityData .................................................................................................
2.196. VuDownloadActivityDataRecordArray .............................................................................
2.197. VuEventData ...................................................................................................................
2.198. VuEventRecord ...............................................................................................................
2.199. VuEventRecordArray .......................................................................................................
2.200. VuFaultData ....................................................................................................................
2.201. VuFaultRecord ................................................................................................................
2.202. VuFaultRecordArray ........................................................................................................
2.203. VuGNSSADRecord ........................................................................................................
2.203a. VuBorderCrossingRecord
2.203b. VuBorderCrossingRecordArray
2.204. VuGNSSADRecordArray ...............................................................................................
2.204a. VuGnssMaximalTimeDifference
2.205. VuIdentification ................................................................................................................
2.206. VuIdentificationRecordArray ............................................................................................
2.207. VuITSConsentRecord ......................................................................................................
2.208. VuITSConsentRecordArray .............................................................................................
2.208a. VuLoadUnloadRecord
2.208b. VuLoadUnloadRecordArray
2.209. VuManufacturerAddress ..................................................................................................
2.210. VuManufacturerName ......................................................................................................
2.211. VuManufacturingDate ......................................................................................................
2.212. VuOverSpeedingControlData ...........................................................................................
2.213. VuOverSpeedingControlDataRecordArray .......................................................................
2.214. VuOverSpeedingEventData ..............................................................................................
2.215. VuOverSpeedingEventRecord ..........................................................................................
2.216. VuOverSpeedingEventRecordArray .................................................................................
2.217. VuPartNumber ................................................................................................................
2.218. VuPlaceDailyWorkPeriodData .........................................................................................
2.219. VuPlaceDailyWorkPeriodRecord .....................................................................................
2.220. VuPlaceDailyWorkPeriodRecordArray ............................................................................
2.221. VuPrivateKey ..................................................................................................................
2.222. VuPublicKey ...................................................................................................................
2.222a. VuRtcTime
2.223. VuSerialNumber ..............................................................................................................
2.224. VuSoftInstallationDate ......................................................................................................
2.225. VuSoftwareIdentification ..................................................................................................
2.226. VuSoftwareVersion ..........................................................................................................
2.227. VuSpecificConditionData .................................................................................................
2.228. VuSpecificConditionRecordArray ....................................................................................
2.229. VuTimeAdjustmentData ...................................................................................................
2.230. Zarezerwowany dla przyszłego użytku .....................................................................................
2.231. Zarezerwowany dla przyszłego użytku ............................................................................
2.232. VuTimeAdjustmentRecord ...............................................................................................
2.233. VuTimeAdjustmentRecordArray ......................................................................................
2.234. WorkshopCardApplicationIdentification ...........................................................................
2.234a. WorkshopCardApplicationIdentificationV2
2.234b. WorkshopCardCalibrationAddData
2.234c. WorkshopCardCalibrationAddDataRecord
2.235. WorkshopCardCalibrationData ........................................................................................
2.236. WorkshopCardCalibrationRecord ....................................................................................
2.237. WorkshopCardHolderIdentification ..................................................................................
2.238. WorkshopCardPIN .........................................................................................................
2.239. W-VehicleCharacteristicConstant .....................................................................................
2.240. VuPowerSupplyInterruptionRecord ..................................................................................
2.241. VuPowerSupplyInterruptionRecordArray .........................................................................
2.242. VuSensorExternalGNSSCoupledRecordArray .................................................................
2.243. VuSensorPairedRecordArray ...........................................................................................
3. DEFINICJE WARTOŚCI I ZAKRESU WIELKOŚCI ...................................................
4. ZESTAW ZNAKÓW: .....................................................................................................
5. KODOWANIE ...............................................................................................................
6. IDENTYFIKATORY OBIEKTU I IDENTYFIKATORY APLIKACJI ..........................
6.1. Identyfikatory obiektu ......................................................................................................
6.2. Identyfikatory aplikacji .....................................................................................................
1. WPROWADZENIE
Niniejszy dodatek określa formaty danych, elementy danych i struktury danych przeznaczone do wykorzystania w urządzeniach rejestrujących i kartach do tachografów.
1.1. Podejście do definicji typów danych
W niniejszym dodatku do definiowania typów danych użyto zapisu składni abstrakcyjnej 1 (ASN.1). Pozwala to na definiowanie prostych i strukturalnych danych bez narzucania żadnej swoistej składni przesyłania danych (reguł kodowania), która zależy od aplikacji i środowiska.
Konwencje nazewnictwa typu ASN.1 opracowano zgodnie z normą ISO/IEC 8824-1. Powyższe oznacza, że:
- tam gdzie możliwe wybrane nazwy opisują znaczenie typu,
- tam gdzie typ danych zbudowany jest z innych typów danych nazwa typu danych ma postać pojedynczego ciągu znaków alfanumerycznych zaczynającego się od dużej litery, natomiast duże litery wewnątrz nazwy opisują odpowiednie znaczenia,
- ogólnie nazwy typów danych powiązane są z nazwami typów danych, z których są zbudowane, urządzeniem, w którym są zgromadzone i funkcją z nimi związaną.
Jeżeli typ ASN.1 jest już zdefiniowany jako część innej normy i jeżeli jest to właściwe w celu wykorzystania w urządzeniu rejestrującym, to ten typ ASN.1 jest zdefiniowany w niniejszym dodatku.
Aby umożliwić stosowanie kilku reguł kodowania, niektóre typy ASN.1 w niniejszym dodatku są ograniczone identyfikatorami zakresu wartości. Identyfikatory zakresu wartości zostały zdefiniowane w pkt. 3 i dodatku 2.
1.2. Odniesienia
W niniejszym dodatku stosuje się następujące odniesienia:
ISO 639 Kod reprezentacji nazw języków. Wydanie pierwsze: 1988.
ISO 3166 Kody nazw krajów i ich jednostek administracyjnych - Część 1: Kody krajów, 2013.
ISO 3779 Pojazdy drogowe - Numer identyfikacyjny pojazdu (VIN) - zawartość i struktura. 2009
ISO/IEC 7816-5 Karty identyfikacyjne - Elektroniczne karty stykowe - część 5: Rejestracja identyfikatorów aplikacji
Wydanie drugie: 2004.
ISO/IEC 7816-6 Karty identyfikacyjne - Elektroniczne karty stykowe - część 6: Elementy danych wymieniane z otoczeniem niezależnie od dziedziny zastosowań, 2004 + Poprawka techniczna 1: 2006
ISO/IEC 8824-1 Informatyka - Zapis składni abstrakcyjnej 1 (ASN.1): Specyfikacja notacji podstawowej. 2008 + sprostowanie techniczne 1: 2012 i sprostowanie techniczne 2: 2014.
ISO/IEC 8825-2 Informatyka - Reguły kodowania ASN.1: Specyfikacja reguł upakowanego kodowania (PER). 2008.
ISO/IEC 8859-1 Informatyka - 8-bitowe jednobajtowe zestawy znaków graficznych - część 1: Zestaw łaciński 1. Wydanie pierwsze: 1998.
ISO/IEC 8859-7 Informatyka - 8-bitowe jednobajtowe zestawy znaków graficznych - część 7: Alfabet łaciński/ grecki. 2003.
ISO 16844-3 Pojazdy drogowe - Systemy tachograficzne - interfejs czujnika ruchu. 2004 + Poprawka techniczna 1: 2006.
TR-03110-3 Wytyczne techniczne BSI/ANSSI TR-03110-3, Zaawansowane mechanizmy zabezpieczeń dokumentów podróży odczytywanych maszynowo i token eIDAS - część 3 Wspólne specyfikacje, wersja 2.20, 3. Luty 2015 r.
2. DEFINICJE TYPÓW DANYCH
Dla każdego z następujących typów danych wartość domyślna "nieznane" lub zawartość "nie dotyczy" polega na wypełnieniu elementu danych bajtami Hex 'FF', o ile nie określono inaczej.
Wszystkie typy danych są wykorzystywane w aplikacjach generacji 1 i 2, o ile nie określono inaczej. Wskazane są typy danych stosowane wyłącznie w aplikacjach wersji 2 generacji 2.
W przypadku typów danych karty używanych do aplikacji generacji 1 i 2 wielkość określona w niniejszym dodatku to wielkość dla aplikacji generacji 2. Wielkość dla aplikacji generacji 1 powinna być już znana dla czytnika. Numery wymogów dotyczących takich typów danych określone w załączniku IC obejmują zarówno aplikacje generacji 1, jak i aplikacje generacji 2.
Typy danych karty niezdefiniowane dla kart generacji 1 nie są zapisywane w aplikacji generacji 1 dla kart generacji 2. W szczególności:
- numery homologacji typu zapisane w aplikacji generacji 1 dla kart generacji 2 są, w razie potrzeby, skracane do 8 pierwszych znaków,
- W aplikacji generacji 1 dla kart generacji 2 zapisuje się jedynie »początek PRZEPRAWY PROMOWEJ/ POCIĄGOWEJ« stanu szczególnego »PRZEPRAWA PROMOWA/POCIĄGOWA«.
2.1. ActivityChangeInfo
Ten typ danych umożliwia kodowanie, w dwubajtowym słowie, stanu szczeliny czytnika o godzinie 00:00 lub statusu kierowcy o godzinie 00:00 lub zmiany czynności, lub zmiany stanu prowadzenia pojazdu, lub zmiany stanu karty dla kierowcy lub współkierowcy. Ten typ danych związany jest z wymaganiami 105, 266, 291, 320, 321, 343 i 344 określonymi w załączniku 1C.
ActivityChangelnfo::= OCTET STRING (SIZE (2))
Przypisanie wartości - zapisane oktetami: scpaattttttttttt'B (16 bitów)
Zapisy w pamięci danych (lub stan szczeliny czytnika karty):
's'B Szczelina czytnika karty:
'0'B: KIEROWCA,
'1'B: WSPÓŁKIEROWCA,
'c'B Stan prowadzenia pojazdu:
'0'B: JEDEN KIEROWCA,
'1'B: ZAŁOGA,
'p'B Stan karty kierowcy (lub warsztatowej) w odpowiedniej szczelinie czytnika:
'0'B: WŁOŻONA, karta jest włożona,
'1'B: NIEWŁOŻONA, brak karty (lub karta jest wyjęta),
'aa'B Czynność:
'00'B: PRZERWA/ODPOCZYNEK,
'01'B: GOTOWOŚĆ,
'10'B: PRACA,
'11'B: PROWADZENIE,
'ttttttttttt'B Godzina zmiany: liczba minut od godziny 00:00 w danym dniu.
Dla zapisów na kartach kierowcy (lub warsztatowej) (i statusu kierowcy):
's'B Szczelina czytnika karty (nieistotne, gdy "p" = 1 z wyjątkiem jak w uwadze poniżej):
'0'B: KIEROWCA,
'1'B: WSPÓŁKIEROWCA,
'c'B Stan prowadzenia pojazdu (przypadek "p" = 0); lub
Następny stan czynności (przypadek "p" = 1):
'0'B: JEDEN KIEROWCA,
'0'B: NIEZNANY
'1'B: ZAŁOGA,
'1'B: ZNANY (=wprowadzony ręcznie)
'p'B Stan karty:
'0'B: WŁOŻONA, karta jest włożona do urządzenia rejestrującego,
'1'B: NIEWŁOŻONA, brak karty (lub karta jest wyjęta)
'aa'B Czynność (nieistotne, gdy "p" = 1 i "c" = 0 z wyjątkiem jak w uwadze poniżej):
'00'B: PRZERWA/ODPOCZYNEK,
'01'B: GOTOWOŚĆ,
'10'B: PRACA,
'11'B: PROWADZENIE,
'ttttttttttt'B Godzina zmiany: liczba minut od godziny 00:00 w danym dniu.
Uwaga dla przypadku "wyjęcie karty":
Gdy karta jest wyjęta:
- "s" odnosi się do szczeliny czytnika i wskazuje szczelinę czytnika, z której wyjęta jest karta,
- "c" musi być ustawiony na 0,
- "p" musi być ustawiony na 1,
- "aa" musi kodować bieżącą czynność wybraną w tym czasie.
W wyniku ręcznego wprowadzenia danych bity "c" i "aa" słowa (zapisanego na karcie) mogą być nadpisane później w celu odzwierciedlania zapisu.
2.2. Address
Adres.
Address::= SEQUENCE {
codePage INTEGER (0..255),
address OCTET STRING (SIZE (35))
}
codePage określa zestaw znaków zdefiniowany w rozdziale 4,
address jest adresem zakodowanym przy użyciu wyszczególnionego zestawu znaków.
2.3. AESKey
Generacja 2:
Klucz AES o długości 128, 192 lub 256 bitów.
AESKey::= CHOICE {
aesl28Key AES128Key,
aesl92Key AES192Key,
aes256Key AES256Key
}
Przypisanie wartości: nie określa się.
2.4. AES128Key
Generacja 2:
Klucz AES 128.
AES128Key::= SEQUENCE {
length INTEGER(0..255),
aesl28Key OCTET STRING (SIZE (16))
}
length oznacza długość klucza AES 128 w oktetach.
aes128Key oznacza klucz AES o długości 128 bitów.
Przypisanie wartości:
długość ma wartość 16.
2.5. AES192Key
Generacja 2:
Klucz AES 192.
AES192Key::= SEQUENCE {
length INTEGER(0..255),
aesl9 Key OCTET STRING (SIZE (24))
}
length oznacza długość klucza AES 192 w oktetach.
aes192Key oznacza klucz AES o długości 192 bitów.
Przypisanie wartości:
długość ma wartość 24.
2.6. AES256Key
Generacja 2:
Klucz AES 256.
AES256Key::= SEQUENCE {
length INTEGER(О..255),
aes256Key OCTET STRING (SIZE (32))
}
długość oznacza długość klucza AES 256 w oktetach.
aes256Key oznacza klucz AES o długości 256 bitów.
Przypisanie wartości:
długość ma wartość 32.
2.7. BCDString
BCDString jest stosowany do reprezentacji liczb w zapisie dziesiętnym kodowanym dwójkowo (BCD). Tego typu danych używa się do przedstawiania jednej cyfry dziesiętnej w półoktecie (4 bity). BCDString oparty jest na definicji z normy ISO/IEC 8824-1 "CharacterStringType".
BCDString::= CHARACTER STRING (WITH COMPONENTS {
identification (WITH COMPONENTS {
fixed PRESENT }) })
BCDString używa notacji "hstring". Skrajna lewa cyfra heksadecymalna jest najbardziej znaczącym półoktetem pierwszego oktetu. Aby utworzyć wielokrotne oktety, wstawia się, gdy trzeba, zerowe półoktety o lewej skrajnej pozycji półoktetu w pierwszym oktecie.
Dozwolonymi cyframi są: 0, 1, .. 9.
2.8. CalibrationPurpose
Kod wyjaśniający, dlaczego zarejestrowano zbiór parametrów kalibracyjnych. Ten typ danych związany jest z wymaganiami 097 i 098 określonymi w załączniku 1B i wymaganiem 119 określonym w załączniku 1C.
CalibrationPurpose::= OCTET STRING (SIZE(l))
Przypisanie wartości:
Generacja 1:
'00'H wartość zastrzeżona,
'01'H aktywacja: zapis parametrów kalibracyjnych znanych w momencie aktywacji VU,
'02'H pierwsza instalacja: pierwsza kalibracja VU po aktywacji,
'03'H instalacja: pierwsza kalibracja VU w bieżącym pojeździe,
'04'H przegląd okresowy.
Generacja 2:
Oprócz generacji 1 używane są następujące wartości:
'05'H wprowadzenie VRN przez firmę,
'06'H korekta czasu bez kalibracji,
'07'H to '7FH RFU,
'80'H - 'FF'H swoisty dla producenta.
2.9. CardActivityDailyRecord
Informacje, zapisane na karcie, dotyczące czynności kierowcy w danym dniu kalendarzowym. Ten typ danych związany jest z wymaganiami 266, 291, 320 i 343 określonymi w załączniku 1C.
CardActivityDailyRecord::= SEQUENCE {
activityPreviousRecordLength INTEGER(0..CardActivityLengthRange),
activityRecordLength INTEGER(0..CardActivityLengthRange),
activityRecordDate TimeReal,
activityDailyPresenceCounter DailyPresenceCounter,
activityDayDistance Distance,
activityChangelnfo SET SIZE(1..1440) OF ActivityChangelnfо
}
activityPreviousRecordLength jest całkowitą długością w bajtach poprzedniego rekordu dziennego. Maksymalną wartość określa długość OCTET STRING zawierającego te rekordy (zob. pkt 4 CardActivityLengthRange w dodatku 2). Gdy rekord ten jest najstarszym rekordem dziennym, wartość activityPreviousRecordLength musi być ustawiona na 0.
activityRecordLength jest całkowitą długością tego rekordu w bajtach. Maksymalną wartość określa długość OCTET STRING zawierającego te rekordy.
activityRecordDate jest datą rekordu.
activityDailyPresenceCounter jest licznikiem obecności dla karty w tym dniu.
activityDayDistance jest całkowitą drogą przebytą w tym dniu.
activityChangeInfo jest zbiorem danych ActivityChangeInfo dla kierowcy w tym dniu. Może zawierać maksymalnie 1440 wartości (jedna zmiana czynności na minutę). W tym zbiorze danych zawsze znajduje się activityChangeInfo określający status kierowcy o godzinie 00:00.
2.10. CardActivityLengthRange
Liczba bajtów na karcie kierowcy lub na karcie warsztatowej, dostępnych do przechowywania rekordów z czynnościami kierowcy.
CardActivityLengthRange::= INTEGER(0..216-1)
Przypisanie wartości: zob. dodatek 2.
2.11. CardApprovalNumber
Numer homologacji typu karty.
CardApprovalNumber::= IA5String(SIZE(8))
Przypisanie wartości:
Należy podawać numer homologacji, który został opublikowany na odpowiedniej stronie internetowej Komisji Europejskiej, tj. na przykład z uwzględnieniem myślników, jeżeli występują. Numer homologacji musi być wyrównany do lewej strony.
2.11a. CardBorderCrossings
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące przekroczeń granicy przez pojazd, jeżeli przekroczył on granicę krajową (wymogi 306f i 356f określone w załączniku IC).
borderCrossingPointerNewestRecord jest indeksem ostatniego uaktualnionego rekordu przekroczenia granicy.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordu dotyczącego przekroczenia granicy, rozpoczynając od '0' dla pierwszego wystąpienia w strukturze rekordu dotyczącego przekroczenia granicy.
cardBorderCrossingRecords jest zbiorem rekordów przekroczenia granicy.
2.11b. CardBorderCrossingRecord
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące przekroczeń granicy przez pojazd, jeżeli przekroczył on granicę krajową (wymogi 147b, 306e i 356e określone w załączniku IC).
countryLeft to kraj, który pojazd opuścił, lub "brak dostępnych informacji" zgodnie z wymogiem 147b określonym w załączniku IC. "Reszta świata" (kod 'FF'H NationNumeric) stosuje się, gdy przyrząd rejestrujący nie jest w stanie określić kraju, w którym pojazd się znajduje (np. bieżący kraj nie jest objęty zapisanymi mapami cyfrowymi).
countryEntered to kraj, do którego pojazd wjechał, lub kraj, w którym pojazd się znajduje w momencie włożenia karty. "Reszta świata" (kod 'FF'H NationNumeric) stosuje się, gdy przyrząd rejestrujący nie jest w stanie określić kraju, w którym pojazd się znajduje (np. bieżący kraj nie jest objęty zapisanymi mapami cyfrowymi).
gnssPlaceAuthRecord zawiera informacje dotyczące pozycji pojazdu, gdy przyrząd rejestrujący wykrył, że pojazd przekroczył granicę krajową, lub "brak dostępnych informacji" zgodnie z wymogiem 147b w załączniku IC, a także jej statusu uwierzytelnienia.
vehicleOdometerValue to stan licznika kilometrów, gdy przyrząd rejestrujący wykrył, że pojazd przekroczył granicę krajową, lub "brak dostępnych informacji" zgodnie z wymogiem 147b w załączniku IC.
2.12. CardCertificate
Generacja 1:
Certyfikat klucza publicznego karty.
CardCertificate::= Certificate
2.13. CardChipIdentification
Informacje, zapisane na karcie, dotyczące identyfikacji układu scalonego karty (IC) (wymaganie 249 określone w załączniku 1C). IcSerialNumber wraz z icManufacturingReferences identyfikują w sposób niepowtarzalny chip karty. Sam IcSerialNumber nie identyfikuje chipu karty w sposób niepowtarzalny.
CardChipIdentification::= SEQUENCE {
IcSerialNumber OCTET STRING (SIZE(4)),
icManufacturingReferences OCTET STRING (SIZE(4))
}
icSerialNumber jest numerem seryjnym IC.
icManufacturingReferences jest identyfikatorem swoistym producenta IC.
2.14. CardConsecutiveIndex
Numer kolejny karty (definicja h)).
CardConsecutivelndex::= IA5String(SIZE(1))
Przypisanie wartości: (zob. rozdział 7 załącznika 1C)
Kolejność zwiększania: '0, ..., 9, A, ..., Z, a, ..., z'
2.15. CardControlActivityDataRecord
Informacje przechowywane na karcie kierowcy lub warsztatowej dotyczące ostatniej kontroli, której poddany był kierowca (wymagania 274, 299, 327 i 350 określone w załączniku 1C).
CardControlActivityDataRecord::= SEQUENCE {
controlType ControlType,
controlTime TimeReal,
controlCardNumber FullCardNumber,
controlVehicleRegistration VénieleRegistrationldentification,
controlDownloadPeriodBegin TimeReal,
controlDownloadPeriodEnd TimeReal
}
controlType jest typem kontroli.
controlTime jest datą i godziną kontroli.
controlCardNumber jest numerem karty FullCardNumber funkcjonariusza służb kontrolnych przeprowadzającego kontrolę.
controlVehicleRegistration jest numerem VRN i Strony rejestracji pojazdu, w którym miała miejsce kontrola.
controlDownloadPeriodBegin i controlDownloadPeriodEnd jest okresem, dla którego pobrano dane, w przypadku pobierania danych.
2.16. CardCurrentUse
Informacje o rzeczywistym użyciu karty (wymagania 273, 298, 326 i 349 określone w załączniku 1C).
CardCurrentUse::= SEQUENCE {
sessionOpenTime TimeReal,
sessionOpenVehicle VehicleRegistrationldentification
}
sessionOpenTime jest godziną, o której kartę włożono dla bieżącego użycia. Przy wyjęciu karty element ten jest zerowany.
sessionOpenVehicle jest identyfikacją aktualnie używanego pojazdu ustawianą przy wkładaniu karty. Przy wyjęciu karty element ten jest zerowany.
2.17. CardDriverActivity
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące czynności kierowcy (wymagania 267, 268, 292, 293, 321 i 344 określone w załączniku 1C).
CardDriverActivity::= SEQUENCE {
activityPointerOldestDayRecord INTEGER(0.. CardActivityLengthRange-1),
activityPointerNewestRecord INTEGER(0.. CardActivityLengthRange-1),
activityDailyRecords OCTET STRING
(SIZE(CardActivityLengthRange))
}
activityPointerOldestDayRecord jest wskaźnikiem początku miejsca gromadzenia danych (liczba bajtów od początku łańcucha znaków) najstarszego, pełnego rekordu dziennego w łańcuchu activityDailyRecords. Maksymalna wartość jest określona długością łańcucha.
activityPointerNewestRecord jest wskaźnikiem początku miejsca gromadzenia danych (liczba bajtów od początku łańcucha znaków) najświeższego rekordu dziennego w łańcuchu activityDailyRecords. Maksymalna wartość jest określona długością łańcucha.
activityDailyRecords jest przestrzenią dostępną do przechowywania danych dotyczących czynności kierowcy (struktura danych: CardActivityDailyRecord) dla każdego dnia kalendarzowego, w którym karta jest użyta.
Przypisanie wartości: ten OCTET STRING jest cyklicznie wypełniany rekordami CardActivityDailyRecord. Przy pierwszym użyciu gromadzenie rozpoczyna się od pierwszego bajtu łańcucha. Wszystkie nowe rekordy dołącza się do końca poprzedniego rekordu. Gdy łańcuch zostaje zapełniony wypełnianie rozpoczyna się od pierwszego bajtu łańcucha niezależnie od przerwy w elemencie danych. Przed wstawieniem do łańcucha danych o nowej czynności (zwiększenie bieżącego rekordu activityDailyRecord lub wstawienie nowego rekordu activityDaily-Record), który zamienia stare dane o starej czynności, wskaźnik activityPointerOldestDayRecord musi być uaktualniony w celu odzwierciedlenia nowego położenia najstarszego, pełnego rekordu dziennego a długość activityPreviousRecordLength tego (nowego) najstarszego, pełnego rekordu dziennego musi być wyzerowana.
2.18. CardDrivingLicenceInformation
Informacje przechowywane na karcie kierowcy dotyczące prawa jazdy posiadacza karty (wymagania 259 i 284 określone w załączniku 1C).
CardDrivingLicencelnformation::= SEQUENCE {
drivingLicencelssuingAuthority Name,
drivingLicencelssuingNation NationNumeric,
drivingLicenceNumber IA5String(SIZE(16))
}
drivingLicenceIssuingAuthority jest organem, który wydał prawo jazdy. drivingLicenceIssuingNation jest przynależnością państwową organu, który wydał prawo jazdy. drivingLicenceNumber jest numerem prawa jazdy.
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).
CardEventData::= SEQUENCE SIZE (6) OF {
cardEventRecords SET SIZE(NoOfEventsPerType) OF
CardEventRecord
}
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).
CardEventData::= SEQUENCE SIZE(11) OF {
cardEventRecords SET SIZE(NoOfEventsPerType) OF
CardEventRecord
}
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).
2.20. CardEventRecord
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące zdarzenia związanego z posiadaczem karty (wymagania 261, 286, 318 i 341 określone w załączniku 1C).
CardEventRecord::= SEQUENCE {
eventType EventFaultType,
eventBeginTime TimeReal,
eventEndTime TimeReal,
eventVehicleRegistration VehicleRegistrationldentification
}
eventType jest typem zdarzenia.
eventBeginTime jest datą i godziną rozpoczęcia zdarzenia.
eventEndTime jest datą i godziną zakończenia zdarzenia.
eventVehicleRegistration jest numerem VRN i Strony rejestracji pojazdu, w którym zdarzenie miało miejsce.
2.21. CardFaultData
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące usterek związanych z posiadaczem karty (wymagania 263, 288, 318 i 341 określone w załączniku 1C).
CardFaultData::= SEQUENCE SIZE (2) OF {
cardFaultRecords SET SIZE(NoOfFaultsPerType) OF
CardFaultRecord
CardFaultData jest sekwencją zbioru rekordów dotyczących usterek urządzenia rejestrującego poprzedzającego zbiór rekordów dotyczących usterek kart.
cardFaultRecords jest zbiorem rekordów dotyczących usterek danej kategorii (urządzenia rejestrującego lub karty).
2.22. CardFaultRecord
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące usterki związanej z posiadaczem karty (wymagania 264, 289, 318 i 341 określone w załączniku 1C).
CardFaultRecord::= SEQUENCE {
faultType EventFaultType,
faultBeginTime TimeReal,
faultEndTime TimeReal,
faultVehicleRegistration VehicleRegistrationldentification
}
faultType jest typem usterki.
faultBeginTime jest datą i godziną początku usterki.
faultEndTime jest datą i godziną zakończenia usterki.
faultVehicleRegistration jest numerem VRN i Strony rejestracji pojazdu, w którym usterka się zdarzyła.
2.23. CardIccIdentification
Informacje zapisane na karcie dotyczące identyfikacji karty z układem scalonym (IC) (wymaganie 248 określone w załączniku 1C).
Cardlccldentification::= SEQUENCE {
clockStop OCTET STRING (SIZE(l)),
cardExtendedSerialNumber ExtendedSerialNumber,
cardApprovalNumber CardApprovalNumber,
cardPersonaliserlD ManufacturerCode,
embedderIcAssemb1erId EmbedderIcAssemb1erId,
icldentifier OCTET STRING (SIZE (2))
}
clockStop jest trybem Clockstop zdefiniowanym w dodatku 2.
cardExtendedSerialNumber jest niepowtarzalnym numerem seryjnym karty IC, dodatkowo określonym za pomocą typu danych ExtendedSerialNumber.
cardApprovalNumber jest numerem homologacji typu karty.
cardPersonaliserID jest identyfikatorem jednostki personalizującej kartę zakodowanym jako ManufacturerCode.
embedderIcAssemblerId zapewnia informacje o wbudowującym/montującym układ scalony.
icIdentifier jest identyfikatorem układu scalonego na karcie i producenta układu scalonego zdefiniowanym w normie ISO/IEC 7816-6.
2.24. CardIdentification
Informacje zapisane na karcie dotyczące identyfikacji karty (wymagania 255, 280, 310, 333, 359, 365, 371 i 377 określone w załączniku 1C).
Cardldentification::= SEQUENCE {
cardlssuingMemberState NationNumeric,
cardNumber CardNumber,
cardlssuingAuthorityName Name,
cardlssueDate TimeReal,
cardValidityBegin TimeReal,
cardExpiryDate TimeReal
}
cardIssuingMemberState jest kodem Strony wydającego kartę.
cardNumber jest numerem karty.
cardIssuingAuthorityName jest nazwą organu wydającego kartę.
cardIssueDate jest datą wydania karty aktualnemu posiadaczowi.
cardValidityBegin jest pierwszą datą ważności karty.
cardExpiryDate jest terminem ważności karty.
2.24a. CardLoadTypeEntries
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub warsztatowej dotyczące wpisów typu załadunku, gdy karta jest włożona do przyrządu rejestrującego (wymogi 306j i 356j określone w załączniku IC).
loadTypeEntryPointerNewestRecord to indeks ostatniego uaktualnionego rekordu karty dotyczącego wpisu typu załadunku.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordu karty dotyczącego wpisu typu załadunku, rozpoczynając od '0' dla pierwszego wystąpienia w strukturze rekordu karty dotyczącego wpisu typu załadunku.
cardLoadTypeEntryRecords to zbiór rekordów zawierających datę i godzinę wpisu oraz wpisany typ załadunku.
2.24b. CardLoadTypeEntryRecord
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub warsztatowej dotyczące wprowadzonych zmian typu załadunku, gdy karta jest włożona do przyrządu rejestrującego (wymogi 306i i 356i określone w załączniku IC).
timeStamp to data i godzina wpisania typu załadunku.
loadTypeEntered to wpisany typ załadunku.
2.24c. CardLoadUnloadOperations
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub warsztatowej dotyczące operacji załadunku/rozła- dunku pojazdu (wymogi 306h i 356h określone w załączniku IC).
loadUnloadPointerNewestRecord to indeks ostatniego uaktualnionego rekordu karty dotyczącego załadunku/rozładunku.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordu karty dotyczącego załadunku/ rozładunku, rozpoczynając od '0' dla pierwszego wystąpienia w strukturze rekordu karty dotyczącego załadunku/rozładunku.
cardLoadUnloadRecords to zbiór rekordów zawierających wskazanie typu wykonywanej operacji (załadunek, rozładunek lub równoczesny załadunek/rozładunek), datę i godzinę wprowadzenia operacji załadunku/rozładunku, informacje o pozycji pojazdu oraz stan licznika kilometrów.
2.24d. CardLoadUnloadRecord
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub warsztatowej dotyczące operacji załadunku/rozła- dunku pojazdu (wymogi 306g i 356g określone w załączniku IC).
timeStamp to data i godzina rozpoczęcia operacji załadunku/rozładunku.
operationType to wpisany typ operacji (załadunek, rozładunek lub równoczesny załadunek/rozładunek). gnssPlaceAuthRecord zawiera informacje dotyczące pozycji pojazdu.
vehicleOdometerValue to stan licznika kilometrów w związku z rozpoczęciem operacji załadunku/ rozładunku.
2.25. CardMACertificate
Generacja 2:
Certyfikat klucza publicznego karty na potrzeby wzajemnego uwierzytelniania z VU. Strukturę tego certyfikatu określono w dodatku 11.
CardMACertificate::= Certificate
2.26. CardNumber
Numer karty zgodny z definicją g).
CardNumber::= CHOICE {
SEQUENCE {
driverIdentification IA5String(SIZE(14)),
cardReplacementIndex CardReplacementIndex,
cardRenewalIndex CardRenewalIndex
SEQUENCE {
ownerldentification IA5String(SIZE(13)),
cardConsecutivelndex CardConsecutivelndex,
cardReplacementIndex CardReplacementIndex,
cardRenewalIndex CardRenewalIndex
}
driverIdentification jest jednoznaczną identyfikacją kierowcy w państwie członkowskim.
ownerIdentification jest jednoznaczną identyfikacją firmy lub warsztatu lub organu kontrolnego w państwie członkowskim.
cardConsecutiveIndex jest numerem kolejnym karty.
cardReplacementIndex jest numerem wymiany karty.
cardRenewalIndex jest numerem odnowienia karty.
Pierwsza wybierana sekwencja umożliwia kodowanie karty kierowcy, a druga wybierana sekwencja umożliwia kodowanie numeru karty warsztatowej, karty kontrolnej i karty firmowej.
2.26a. CardPlaceAuthDailyWorkPeriod
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej, przedstawiające status uwierzytelnienia miejsc rozpoczęcia lub zakończenia dziennych okresów pracy (wymogi 306b i 356b określone w załączniku IC).
placeAuthPointerNewestRecord to indeks ostatniego uaktualnionego rekordu dotyczącego statusu uwierzytelnienia miejsca.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordów dotyczących statusu uwierzytelnienia miejsca, rozpoczynając od '0' dla pierwszego wystąpienia w strukturze rekordów dotyczących statusu uwierzytelnienia miejsca.
placeAuthStatusRecords to zbiór rekordów zawierających status uwierzytelnienia miejsca dla wprowadzanych miejsc.
2.27. CardPlaceDailyWorkPeriod
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące miejsc rozpoczęcia lub zakończenia dziennych okresów pracy (wymagania 272, 297, 325 i 348 określone w załączniku 1C).
CardPlaceDailyWorkPeriod::= SEQUENCE {
placePointerNewestRecord INTEGER(0 .. NoOfCardPlaceRecords-l),
placeRecords SET SIZE(NoOfCardPlaceRecords) OF PlaceRecord
}
placePointerNewestRecord jest indeksem ostatniego, uaktualnionego rekordu miejsca.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordów miejsca, zaczynająca się od "0" dla pierwszego wystąpienia rekordów miejsca w strukturze.
placeRecords jest zbiorem rekordów dotyczących wprowadzonych miejsc.
2.28. CardPrivateKey
Generacja 1:
Klucz prywatny karty.
CardPrivateKey::= RSAKeyPrivateExponent
2.29. CardPublicKey
Klucz publiczny karty. CardPublicKey::= PublicKey
2.30. CardRenewalIndex
Numer odnowienia karty (definicja i)).
CardRenewallndex::= IA5String(SIZE (1))
Przypisanie wartości: (zob. rozdział 7 niniejszego załącznika).
"0" Wydanie pierwsze.
Kolejność zwiększania:"0, ..., 9, A, ..., Z "
2.31. CardReplacementIndex
Numer wymiany karty (definicja j)).
CardReplacementlndex::= IA5String(SIZE(1))
Przypisanie wartości: (zob. rozdział VII niniejszego załącznika).
'0' Oryginał karty.
Kolejność zwiększania: '0, ..., 9, A, ..., Z'
2.32. CardSignCertificate
Generacja 2:
Certyfikat klucza publicznego karty do podpisu. Strukturę tego certyfikatu określono w dodatku 11.
CardSignCertifícate::= Certificate
2.33. CardSlotNumber
Kod rozróżnienia między dwiema szczelinami kart w przyrządzie rejestrującym.
CardSlotNumber::= INTEGER {
driverSlot (0),
co-driverSlot (1)
Przypisanie wartości: nie określa się.
2.34. CardSlotsStatus
Kod wskazujący typ kart włożonych do dwóch szczelin czytników karty przyrządu rejestrującego.
CardSlotsStatus::= OCTET STRING (SIZE(l))
Przypisanie wartości - zapisane oktetami: ccccdddd'B
'cccc'B identyfikacja typu karty włożonej do szczeliny karty współkierowcy,
'dddd'B identyfikacja typu karty włożonej do szczeliny karty kierowcy,
z następującymi kodami identyfikującymi:
'0000'B brak karty,
'0001'B karta kierowcy jest włożona,
'0010'B karta warsztatowa jest włożona,
'0011'B karta kontrolna jest włożona,
'0100'B karta firmowa jest włożona.
2.35. CardSlotsStatusRecordArray
Generacja 2:
CardSlotsStatus wraz z metadanymi stosowany w protokole pobierania danych.
CardSlotsStatusRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF CardSlotsStatus
}
recordType oznacza typ rekordu (CardSlotsStatus). Przypisanie wartości: zob. RecordType
recordSize to wielkość CardSlotsStatus w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów CardSlotsStatus.
2.36. CardStructureVersion
Kod wskazujący wersję struktury na karcie do tachografu.
CardStructureVersion::= OCTET STRING (SIZE (2))
Przypsianie wartości: 'aabb'H:
'aa'H indeks zmian struktury,
'00'H dla aplikacji generacji 1
'01'H dla aplikacji generacji 2
'bb'H bb'H indeks zmian dotyczących użycia elementów danych zdefiniowanych dla struktury określony wyższym bajtem.
'00'H dla aplikacji generacji 1
'00'H dla aplikacji wersji 1 generacji 2
'01'H dla aplikacji wersji 2 generacji 2
2.37. CardVehicleRecord
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące okresu używania pojazdu w czasie dnia kalendarzowego (wymagania 269, 294, 322 i 345 określone w załączniku 1C).
Generacja 1:
CardVehicleRecord::= SEQUENCE {
vehicleOdometerBegin OdometerShort,
vehicleOdometerEnd OdometerShort,
vehicleFirstUse TimeReal,
vehicleLastUse TimeReal,
vehicleRegistration VehicleRegistrationldentification,
vuDataBlockCounter VuDataBlockCounter
}
vehicleOdometerBegin jest stanem licznika kilometrów na początku okresu używania pojazdu.
vehicleOdometerEnd jest stanem licznika kilometrów na końcu okresu używania pojazdu.
vehicleFirstUse jest datą i godziną rozpoczęcia okresu używania pojazdu.
vehicleLastUse jest datą i godziną zakończenia okresu używania pojazdu.
vehicleRegistration wskazuje numer VRN i państwo członkowskie rejestracji pojazdu.
vuDataBlockCounter jest wartością licznika VuDataBlockCounter ostatniego wyciągu okresu użycia pojazdu.
Generacja 2:
CardVehicleRecord::= SEQUENCE {
vehicleOdometerBegin OdometerShort,
vehicleOdometerEnd OdometerShort,
vehicleFirstUse TimeReal,
vehicleLastUse TimeReal,
vehicleRegistration VehicleRegistrationldentification,
vuDataBlockCounter VuDataBlockCounter,
vehicieldentificationNumber VehicleIdentificationNumber
}
Oprócz generacji 1 używany jest następujący element danych:
VehicleIdentificationNumber jest numerem identyfikacyjnym pojazdu odnoszącym się do pojazdu jako całości.
2.38. CardVehiclesUsed
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące używanych pojazdów (wymagania 270, 295, 323 i 346 określone w załączniku 1C).
CardVehiclesUsed:= SEQUENCE {
vehiclePointerNewestRecord INTEGER(0..NoOfCardVehicleRecords-l),
cardVehicleRecords SET SIZE(NoOfCardVehicleRecords) OF
CardVehicleRecord
}
vehiclePointerNewestRecord jest indeksem ostatniego, uaktualnionego rekordu dotyczącego pojazdu.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordów dotyczących pojazdu, rozpoczynając od "0" dla pierwszego wystąpienia w strukturze rekordów dotyczących pojazdu.
cardVehicleRecords jest zbiorem rekordów zawierających informacje o używanych pojazdach.
2.39. CardVehicleUnitRecord
Generacja 2:
informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące używanego przyrządu rejestrującego (wymagania 303 i 351 określone w załączniku 1C).
CardVehicleUnitRecord::= SEQUENCE {
timeStamp TimeReal,
manufacturerCode ManufacturerCode,
devicelD INTEGER(0..255),
vuSoftwareVersion VuSoftwareVersion
}
timeStamp jest początkiem okresu używania przyrządu rejestrującego (tj. pierwszym włożeniem karty do przyrządu rejestrującego dla tego okresu).
manufacturerCode identyfikuje producenta przyrządu rejestrującego.
deviceID identyfikuje typ przyrządu rejestrującego producenta. Wartość jest swoista dla producenta.
vuSoftwareVersion jest numerem wersji oprogramowania przyrządu rejestrującego.
2.40. CardVehicleUnitsUsed
Generacja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej dotyczące przyrządów rejestrujących używanych przez posiadacza karty (wymogi 304 i 352 określone w załączniku IC).
CardVehicleUnitsUsed:= SEQUENCE {
vehicleUnitPointerNewestRecord INTEGER(0..NoOfCardVehicleUnitRecords-1),
cardVehicleUnitRecords SET SIZE(NoOfCardVehicleUnitRecords) OF
CardVehicleUnitRecord
}
vehiclePointerNewestRecord jest indeksem ostatniego, uaktualnionego rekordu dotyczącego przyrządu rejestrującego.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordów przyrządu rejestrującego, rozpoczynając od "0" dla pierwszego wystąpienia w strukturze rekordów dotyczących przyrządu rejestrującego.
cardVehicleUnitRecords jest zbiorem rekordów zawierających informacje o używanych przyrządach rejestrujących.
2.41. Certyfikat
Certyfikat klucza publicznego wydany przez organ certyfikacji.
Generacja 1:
Certificate::= OCTET STRING (SIZE (194))
Przypisanie wartości: podpis cyfrowy z częściowym odzyskiwaniem zawartości CertificateContent, zgodnie z dodatkiem 11 "Wspólne mechanizmy bezpieczeństwa": Podpis (128 bajtów) || Reszta klucza publicznego (58 bajtów) || Odnośnik do organu certyfikacji: (8 bajtów)
Generacja 2:
Certificate::= OCTET STRING (SIZE (204 .. 341))
Przypisanie wartości: zob. dodatek 11
2.42. CertificateContent
Generacja 1:
Treść certyfikatu klucza publicznego zgodnie z dodatkiem 11 - Wspólne mechanizmy bezpieczeństwa.
CertificateContent::= SEQUENCE {
certificateProfileldentifier INTEGER(0..255),
certificationAuthorityReference Keyldentifier,
certificateHolderAuthorisation CertificateHolderAuthorisation,
certificateEndOfValidity TimeReal,
certificateHolderReference Keyldentifier,
publicKey PublicKey
}
certificateProfileIdentifier jest wersją odpowiedniego certyfikatu.
Przypisanie wartości: '01h' dla tej wersji.
certificationAuthorityReference identyfikuje organ certyfikacji wydający certyfikat. Jest tu także odesłanie do klucza publicznego tego organu certyfikacji.
certificateHolderAuthorisation identyfikuje prawa posiadacza certyfikatu.
certificateEndOfValidity jest datą administracyjnego wygaśnięcia certyfikatu.
certificateHolderReference identyfikuje posiadacza certyfikatu. Jest tu także odesłanie do jego klucza publicznego.
publicKey jest kluczem publicznym, który jest poświadczony tym certyfikatem.
2.43. CertificateHolderAuthorisation
Identyfikacja praw posiadacza certyfikatu.
CertificateHolderAuthorisation::= SEQUENCE {
tachographApplicationID OCTET STRING(SIZE(6))
equipmentType EquipmentType
Generacja 1:
}
tachographApplicationID jest identyfikatorem aplikacji dla aplikacji tachograficznej.
Przypisanie wartości: 'FFh' '54h' '41h' '43h' '48h' '4Fh'. Ten AID jest zastrzeżonym, nierejestrowanym identyfikatorem aplikacji zgodnie z normą ISO/IEC 7816-5.
equipmentType jest identyfikacją typu urządzenia, dla którego przeznaczony jest certyfikat.
Przypisanie wartości: zgodnie z typem danych EquipmentType. 0 gdy jest to certyfikat jednego z Stron.
Generacja 2:
tachographApplicationID oznacza 6 najbardziej znaczących bajtów odpowiedniego identyfikatora aplikacji (AID) karty do tachografu generacji 2. AID dla aplikacji karty do tachografu określono w rozdziale 6.2.
Przypisanie wartości: FF 53 4D 52 44 54'.
equipmentType jest identyfikacją typu urządzenia określonego dla generacji 2, dla którego przeznaczony jest certyfikat.
Przypisanie wartości: zgodnie z typem danych EquipmentType.
2.44. CertificateRequestID
Jednoznaczna identyfikacja wniosku o certyfikat. Może być także używana jako identyfikator klucza publicznego przyrządu rejestrującego, jeżeli numer seryjny przyrządu rejestrującego, do którego ten klucz jest przeznaczony, nie jest znany w czasie sporządzania certyfikatu.
CertifícateRequestID::= SEQUENCE{
requestSerialNumber INTEGER(0..232-l),
requestMonthYear BCDString(SIZE(2)),
crldentifier OCTET STRING(SIZE(1)),
manufacturerCode ManufacturerCode
}
requestSerialNumber jest numerem seryjnym wniosku o certyfikat, unikatowym dla producenta i miesiąca określonego poniżej.
requestMonthYear jest identyfikacją miesiąca i roku wniosku o certyfikat.
Przypisanie wartości: miesiąc (dwie cyfry) i rok (dwie ostatnie cyfry) w kodzie BCD.
crIdentifier: jest identyfikatorem umożliwiającym rozróżnienie wniosku o certyfikat od rozszerzonego numeru seryjnego.
Przypisanie wartości: FFh'.
manufacturerCode: jest kodem numerycznym producenta wnioskującego o certyfikat.
2.45. CertificationAuthorityKID
Identyfikator klucza publicznego organu certyfikacji (organu certyfikacji Strony lub europejskiego organu certyfikacji).
CertificationAuthorityKID::= SEQUENCE{
nationNumeric NationNumeric,
nationAlpha NationAlpha,
keySerialNumber INTEGER(0..255),
additionallnfo OCTET STRING(SIZE(2)),
caldentifier OCTET STRING(SIZE(1))
}
nationNumeric jest numerycznym kodem krajowym organu certyfikacji.
nationAlpha jest alfanumerycznym kodem krajowym organu certyfikacji.
keySerialNumber jest numerem seryjnym umożliwiającym rozróżnienie różnych kluczy organu certyfikacji w przypadku zmiany kluczy.
additionalInfo jest dwubajtowym polem przeznaczonym na dodatkowy kod (swoisty dla organu certyfikacji).
caIdentifier jest identyfikatorem umożliwiającym rozróżnienie identyfikatora klucza organu certyfikacji od innych identyfikatorów kluczy.
Przypisanie wartości: '01h'.
2.46. CompanyActivityData
Informacje przechowywane na karcie firmowej dotyczące czynności wykonanych przy użyciu karty (wymagania 373 i 379 określone w załączniku 1C).
CompanyActivityData::= SEQUENCE {
companyPointerNewestRecord INTEGER(0..NoOfCompanyActivityRecords-1),
companyActivityRecords SET SIZE(NoOfCompanyActivityRecords) OF
companyActivityRecord SEQUENCE {
companyActivityType CompanyActivityType,
companyActivityTime TimeReal,
cardNumberInformation FullCardNumber,
vehicleRegistrationlηformation VehicleRegistrationldentification,
downloadPeriodBegin TimeReal,
}
companyPointerNewestRecord jest indeksem ostatniego, uaktualnionego zapisu companyActivityRecord.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordów czynności firmy, rozpoczynając od "0" dla pierwszego wystąpienia rekordu czynności firmy w strukturze.
companyActivityRecords są zbiorem wszystkich rekordów czynności firmy.
companyActivityRecord jest sekwencją informacji dotyczących jednej czynności firmy.
companyActivityType jest typem czynności firmy.
companyActivityTime jest datą i godziną czynności firmy.
cardNumberInformation jest numerem karty i Strony wydającego kartę, z której pobrano dane, gdy dotyczy.
vehicleRegistrationInformation jest numerem VRN i państwem członkowskim rejestracji pojazdu, dla którego pobrano dane lub zablokowano, lub zdjęto blokadę.
downloadPeriodBegin i downloadPeriodEnd jest okresem, dla którego pobrano dane z VU, gdy dotyczy.
2.47. CompanyActivityType
Kod wskazujący czynność wykonaną przez firmę z wykorzystaniem jej karty firmowej.
CompanyActivityType::= INTEGER {
card downloading (1),
VU downloading (2),
VU lock-in (3),
VU lock-out (4)
}
2.48. CompanyCardApplicationIdentification
Informacje przechowywane na karcie firmowej dotyczące identyfikacji aplikacji na karcie (wymagania 369 i 375 określone w załączniku 1C).
CompanyCardApplicationldentification::= SEQUENCE {
typeOfTachographCardld EquipmentType,
cardStructureVersion CardstructureVersion,
noOfCompanyActivityRecords NoOfCompanyActivityRecords
}
typeOfTachographCardId określa wdrożony typ karty.
cardStructureVersion określa wersję struktury wdrożonej na karcie.
noOfCompanyActivityRecords jest liczbą rekordów z czynnościami firmy, które można przechowywać na karcie.
2.48a. CompanyCardApplicationIdentificationV2
Generacja 2, wersja 2:
Informacje przechowywane na karcie firmowej dotyczące identyfikacji aplikacji na karcie (wymóg 375a określony w załączniku IC).
lengthOfFollowingData to liczba kolejnych bajtów we wpisie. vuConfigurationLengthRange to liczba bajtów na karcie do tachografu, dostępnych na potrzeby przechowywania konfiguracji VU.
2.49. CompanyCardHolderIdentification
Informacje przechowywane na karcie firmowej dotyczące identyfikacji posiadacza karty (wymagania 372 i 378 określone w załączniku 1C).
CompanyCardHolderldentification::= SEQUENCE {
companyName Name,
companyAddress Address,
cardHolderPreferredLanguage Language
}
companyName jest nazwą firmy posiadającej kartę.
companyAddress jest adresem firmy posiadającej kartę.
cardHolderPreferredLanguage jest preferowanym językiem posiadacza karty.
2.50. ControlCardApplicationIdentification
Informacje przechowywane na karcie kontrolnej dotyczące identyfikacji aplikacji na karcie (wymagania 357 i 363 określone w załączniku 1C).
ControlCardApplicationldentification::= SEQUENCE {
typeOfTachographCardld EquipmentType,
cardStructureVersion CardStructureVersion,
noOfControlActivityRecords NoOfControlActivityRecords
}
typeOfTachographCardId określa wdrożony typ karty.
cardStructureVersion określa wersję struktury wdrożoną na karcie.
noOfControlActivityRecords jest liczbą rekordów czynności kontrolnych, które mogą być zapisane na karcie.
2.50a. ControlCardApplicationIdentificationV2
Generacja 2, wersja 2:
Informacje przechowywane na karcie kontrolnej dotyczące identyfikacji aplikacji karty (wymóg 363a określony w załączniku IC).
lengthOfFollowingData to liczba kolejnych bajtów we wpisie.
vuConfigurationLengthRange to liczba bajtów na karcie do tachografu, dostępnych na potrzeby przechowywania konfiguracji VU.
2.51. ControlCardControlActivityData
Informacje przechowywane na karcie kontrolnej dotyczące czynności wykonanych przy użyciu karty (wymagania 361 i 367 określone w załączniku 1C).
ControlCardControlActivityData::= SEQUENCE {
controlPointerNewestRecord INTEGER(0.. NoOfControlActivityRecords-l),
controlActivityRecords SET SIZE(NoOfControlActivityRecords) OF
controlActivityRecord SEQUENCE {
controlType ControlType,
controlTime TimeReal,
controlledCardNumber FullCardNumber,
controlledVehicleRegistration VehicleRegistrationldentification,
controlDownloadPeriodBegin TimeReal,
}
controlPointerNewestRecord jest indeksem ostatniego, uaktualnionego rekordu czynności kontrolnych.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordów czynności kontrolnych, rozpoczynając od "0" dla pierwszego wystąpienia w strukturze rekordu czynności kontroli.
controlActivityRecords jest zbiorem wszystkich rekordów czynności kontrolnych.
controlActivityRecord jest ciągiem informacji dotyczących jednej kontroli.
controlType jest typem kontroli.
controlTime jest datą i godziną kontroli.
controlledCardNumber jest numerem karty i Strony wydającego kartę, która jest kontrolowana.
controlledVehicleRegistration jest numerem VRN i Strony rejestracji pojazdu, w którym miała miejsce kontrola.
controlDownloadPeriodBegin i controlDownloadPeriodEnd wyznaczają ostatecznie pobierany okres.
2.52. ControlCardHolderIdentification
Informacje przechowywane na karcie kontrolnej dotyczące identyfikacji posiadacza karty (wymagania 360 i 366 określone w załączniku 1C).
ControlCardHolderldentification::= SEQUENCE {
controlBodyName Name,
controlBodyAddress Address,
cardHolderName HolderName,
cardHolderPreferredLanguage Language
}
controlBodyName jest nazwą organu kontrolnego posiadacza karty. controlBodyAddress jest adresem organu kontrolnego posiadacza karty. cardHolderName jest nazwą i imieniem (imionami) posiadacza karty kontrolnej. cardHolderPreferredLanguage jest preferowanym językiem posiadacza karty.
2.53. ControlType
Kod wskazujący czynności wykonane podczas kontroli. Ten typ danych związany jest z wymaganiami 126, 274, 299, 327 i 350 określonymi w załączniku 1C.
ControlType::= OCTET STRING (SIZE(l))
Generacja 1:
Przypisanie wartości - zapisane oktetami: 'cvpdxxxx'B (8 bitów)
'c'B pobieranie danych z karty:
'0'B: nie pobrano danych z karty w czasie tej kontroli,
'1'B: pobrano dane z karty w czasie tej kontroli
'v'B pobieranie danych z VU:
'0'B: nie pobrano danych z VU w czasie tej kontroli,
'1'B: pobrano dane z VU w czasie tej kontroli
'p'B drukowanie:
'0'B: nie wykonano wydruków w czasie tej kontroli,
'1'B: wykonano wydruki w czasie tej kontroli
'd'B wyświetlacz:
'0'B: nie użyto wyświetlacza w czasie tej kontroli,
'1'B: użyto wyświetlacza w czasie tej kontroli
'xxxx'B Nieużywany.
Generacja 2:
Przypisanie wartości - zapisane oktetami: cvpdexxx'B (8 bitów)
'c'B pobieranie danych z karty:
'0'B: nie pobrano danych z karty w czasie tej kontroli,
'1'B: pobrano dane z karty w czasie tej kontroli
'v'B pobieranie danych z VU:
'0'B: nie pobrano danych z VU w czasie tej kontroli,
'1'B: pobrano dane z VU w czasie tej kontroli
'p'B drukowanie:
'0'B: nie wykonano wydruków w czasie tej kontroli,
'1'B: wykonano wydruki w czasie tej kontroli
'd'B wyświetlacz:
'0'B: nie użyto wyświetlacza w czasie tej kontroli,
'1'B: użyto wyświetlacza w czasie tej kontroli
'e'B kontrola drogowa kalibracji
'0'B: parametry kalibracyjne nie zostały skontrolowane w czasie tej kontroli, '1'B: parametry kalibracyjne zostały skontrolowane w czasie tej kontroli,
'xxx'B RFU.
2.54. CurrentDateTime
Bieżąca data i godzina urządzenia rejestrującego.
CurrentDateTime::= TimeReal
Przypisanie wartości: nie określa się.
2.55. CurrentDateTimeRecordArray
Generacja 2:
Bieżąca data i godzina wraz z metadanymi stosowane w protokole pobierania danych.
CurrentDateTimeRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF CurrentDateTime
}
recordType oznacza typ rekordu (CurrentDateTime). Przypisanie wartości: zob. RecordType
recordSize to wielkość CurrentDateTime w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów z bieżącego dnia i godziny.
2.56. DailyPresenceCounter
Licznik znajdujący się na karcie kierowcy lub na karcie warsztatowej zwiększany o jeden dla każdego dnia kalendarzowego, w którym karta jest włożona do VU. Ten typ danych związany jest z wymaganiami 266, 299, 320 i 343 określonymi w załączniku 1C.
DailyPresenceCounter::= BCDString(SIZE(2))
Przypisanie wartości: Kolejna liczba do maksymalnej wartości = 9 999, i następnie ponownie zaczyna od 0. Przy pierwszym wydaniu karty licznik jest ustawiany na 0.
2.57. Datef
Data wyrażona w czytelnym, przeznaczonym do druku formacie numerycznym.
Datef::= SEQUENCE {
year BCDString (SIZE (2)),
month BCDString (SIZE (1)),
day BCDString(SIZE(1))
}
Przypisanie wartości:
yyyy rok
mm miesiąc
dd dzień
'00000000'H oznacza jednoznacznie brak daty.
2.58. DateOfDayDownloaded
Generacja 2:
data i godzina pobrania danych;
DateOfDayDownloaded::= TimeReal
Przypisanie wartości: nie określa się.
2.59. DateOfDayDownloadedRecordArray
Generacja 2:
Data i godzina pobrania danych wraz z metadanymi stosowane w protokole pobierania danych.
DateOfDayDownloadedRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
DateOfDayDownloaded
}
recordType oznacza typ rekordu (DateOfDayDownloaded). Przypisanie wartości: zob. RecordType
recordSize to wielkość CurrentDateTime w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem daty i godziny rekordów pobierania danych.
2.60. Distance
Przebyta odległość (wynik obliczenia różnicy między dwoma odczytami licznika kilometrów pojazdu wyrażona w kilometrach).
Distance::= INTEGER (0 .. 216-1)
Przypisanie wartości: liczba binarna bez znaku. Wartość w km w zakresie operacyjnym 0 do 9 999 km.
2.60a. DownloadInterfaceVersion
Generacja 2, wersja 2:
Kod wskazujący wersję interfejsu pobierania danych przyrządu rejestrującego.
DownloadlnterfaceVersion::= OCTET STRING (SIZE (2))
Przypisanie wartości: 'aabb'H:
'aa'H '00'H: nieużywany,
'01'H: przyrząd rejestrujący generacji 2,
'bb'H '00'H: nieużywany,
'01'H: przyrząd rejestrujący wersji 2 generacji 2.
2.61. DriverCardApplicationIdentification
Informacje przechowywane na karcie kierowcy dotyczące identyfikacji aplikacji na karcie (wymagania 253 i 278 określone w załączniku 1C).
Generacja 1:
DriverCardApplicationldentification::= SEQUENCE {
typeOfTachographCardld EquipmentType,
cardStructureVersion CardstructureVersion,
noOfΕventsPerType NoOfΕventsPerType,
noOfFaultsPerType NoOfFaultsPerType,
activityStructureLength CardActivityLengthRange,
noOfCardVehicleRecords NoOfCardVehicleRecords,
noOfCardPlaceRecords NoOfCardPlaceRecords
}
typeOfTachographCardId określa wdrożony typ karty.
cardStructureVersion określa wersję struktury wdrożonej na karcie.
noOfEventsPerType jest liczbą zdarzeń według typu zdarzenia możliwych do zarejestrowania na karcie.
noOfFaultsPerType jest liczbą usterek według typu usterki możliwych do zarejestrowania na karcie.
activityStructureLength podaje liczbę bajtów dostępnych do przechowywania rekordów czynności.
noOfCardVehicleRecords jest liczbą rekordów dotyczących pojazdów możliwych do zarejestrowania na karcie.
noOfCardPlaceRecords jest liczbą miejsc możliwych do zarejestrowania na karcie.
Generacja 2:
DriverCardApplicationldentification::= SEQUENCE {
typeOfTachographCardld EquipmentType,
cardstructureVersion CardStructureVersion,
noOfEventsPerType NoOfEventsPerType,
noOfFaultsPerType NoOfFaultsPerType,
activityStructureLength CardActivityLengthRange,
noOfCardVehicleRecords NoOfCardVehicleRecords,
noOfCardPlaceRecords NoOfCardPlaceRecords,
noOfGNSSADRecords NoOfGNSSADRecords,
noOfSpecificConditionRecords NoOfSpecificConditionRecords
noOfCardVehicleUnitRecords NoOfCardVehicleUnitRecords
}
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.
2.61a. DriverCardApplicationIdentificationV2
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy dotyczące identyfikacji aplikacji karty (wymóg 278a określony w załączniku IC).
lengthOfFollowingData to liczba kolejnych bajtów we wpisie.
noOfBorderCrossingRecords to liczba rekordów dotyczących przekroczenia granicy, które mogą być przechowywane na karcie kierowcy.
noOfLoadUnloadRecords to liczba rekordów dotyczących załadunku/rozładunku, które mogą być przechowywane na karcie kierowcy.
noOfLoadTypeEntryRecords to liczba rekordów dotyczących wpisu typu załadunku, które mogą być przechowywane na karcie kierowcy.
vuConfigurationLengthRange to liczba bajtów na karcie do tachografu, dostępnych na potrzeby przechowywania konfiguracji VU.
2.62. Dr iverCardHolderIdentification
Informacje przechowywane na karcie kierowcy dotyczące identyfikacji posiadacza karty (wymagania 256 i 281 określone w załączniku 1C).
DriverCardHolderldentification::= SEQUENCE {
cardHolderName HolderName,
cardHolderBirthDate Datef,
cardHolderPreferredLanguage Language
)
cardHolderName jest nazwą i imieniem (imionami) posiadacza karty kierowcy.
cardHolderBirthDate jest datą urodzenia posiadacza karty kierowcy. cardHolderPreferredLanguage jest preferowanym językiem posiadacza karty.
2.63. DSRCSecurityData
Generacja 2:
Definicja tego typu danych znajduje się w dodatku 11.
2.64. EGFCertificate
Generacja 2:
Certyfikat klucza publicznego urządzenia zewnętrznego GNSS na potrzeby wzajemnego uwierzytelniania z VU. Strukturę tego certyfikatu określono w dodatku 11.
EGFCertificate::= Certificate
2.65. EmbedderIcAssemblerId
Dostarcza informacje o wbudowującym układ scalony.
EmbedderlcAssemblerld::= SEQUENCE{
countryCode IA5String(SIZE(2)),
moduleEmbedder BCDString(SIZE(2)),
manufacturerlnformation OCTET STRING(SIZE(1))
}
countryCode jest 2-literowym kodem państwa wbudowującego moduł zgodnie z normą ISO 3166.
moduleEmbedder oznacza wbudowującego moduł.
manufacturerInformation na potrzeby użytku wewnętrznego producenta.
2.66. EntryTypeDailyWorkPeriod
Kod umożliwiający rozróżnienie między początkiem a końcem wpisu dotyczącego dziennego okresu pracy oraz miejsca i sposobu wprowadzenia wpisu.
Generacja 1
EntryTypeDailyWorkPeriod::= INTEGER {
Begin, related time = card insertion time or time of entry(0),
End, related time = card withdrawal time or time of entry(1),
Begin, related time manually entered (start time)(2),
End, related time manually entered (end of work period)(3),
Begin, related time assumed by VU(4),
End, related time assumed by VU(5)
}
Przypisanie wartości: zgodnie z normą ISO/IEC8824-1.
Generacja 2
Przypisanie wartości: zgodnie z normą ISO/IEC8824-1.
2.67. EquipmentType
Kod umożliwiający rozróżnienie typów urządzeń dla aplikacji tachograficznej.
EquipmentType::= INTEGER(0..255)
Generacja 1:
--Reserved (0),
--Driver Card (1),
--Workshop Card (2),
--Control Card (3),
--Company Card (4),
--Manufacturing Card (5),
-Vehicle Unit (6),
--Motion Sensor (7),
-RFU (8..255)
Przypisanie wartości: zgodnie z normą ISO/IEC8824-1.
Wartość 0 jest zastrzeżona do celów oznaczenia Strony lub Europy w rubryce CHA certyfikatów.
Generacja 2:
Takie same wartości jak w przypadku generacji 1 z następującymi uzupełnieniami:
--GNSS Facility (8),
--Remote Communication Module (9),
--ITS interface module (10),
--Plaque (11),-may be used in SealRecord
--Ml/Nl Adapter (12),-may be used in SealRecord
--European Root CA (ERCA) (13),
--Member State CA (MSCA) (14),
--External GNSS connection (15),-may be used in SealRecord
--Unused (16),-used in SealDataVu
--Driver Card (Sign) (17),-only to be used in the CHA
field of a signing certificate
--Workshop Card (Sign) (18), --only to be used in the CHA
field of a signing certificate
--Vehicle Unit (Sign) (19), --only to be used in the CHA
field of a signing certificate
--RFU (20..255)
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).
2.68. EuropeanPublicKey
Generacja 1:
Europejski klucz publiczny.
EuropeanPublicKey::= PublicKey
2.69. EventFaultRecordPurpose
Kod wyjaśniający, dlaczego zarejestrowano zdarzenie lub usterkę.
EventFaultRecordPurpose::= OCTET STRING (SIZE(l))
Przypisanie wartości:
'00' H jedno/jedna z 10 ostatnich zdarzeń lub usterek (lub ostatnie/ostatnia
zdarzenie lub usterka)
'01' H najdłuższe zdarzenie w jednym z ostatnich 10 dni ich występowania
'02' H jedno z 5 najdłuższych zdarzeń w ciągu ostatnich 365 dni
'03' H ostatnie zdarzenie w jednym z ostatnich 10 dni ich występowania
'04' H najpoważniejsze zdarzenie w jednym z ostatnich 10 dni ich występowania
'05' H jedno z 5 najpoważniejszych zdarzeń w ciągu ostatnich 365 dni
'06' H pierwsze zdarzenie lub usterka zaistniałe po ostatniej kalibracji
'07' H aktywne/trwające zdarzenie lub usterka
'08'H to '7F'H RFU
'80' H to 'FF' H swoisty dla producenta.
2.70. EventFaultType
Kod kwalifikujący zdarzenie lub usterkę.
EventFaultType::= OCTET STRING (SIZE(l))
Przypisanie wartości:
Generacja 1:
'0x' H zdarzenia ogólne
'00 ' H brak dalszych szczegółów,
'01' H włożenie nieważnej karty,
'02' H konflikt kart,
'03' H nakładające się czasy,
'04' H prowadzenie pojazdu bez prawidłowej karty,
'05' H włożenie karty podczas prowadzenia pojazdu,
'06' H sesja ostatniej karty niezamknięta prawidłowo,
'07' H przekroczenie prędkości,
'08' H przerwa w zasilaniu,
'09' H błąd danych dotyczących ruchu,
'0A' H Konflikt ruchu pojazdu,
'OB' to '0F' H RFU,
zdarzenia związane z próbami naruszenia zabezpieczenia przyrządu rejestrującego,
'1x" H brak dalszych szczegółów,
'10' H błąd uwierzytelnienia czujnika ruchu,
'11' H błąd uwierzytelnienia kart do tachografów,
'12' H nieupoważniona zmiana w czujniku ruchu,
'13' H błąd integralności wprowadzania danych na kartę
'14' H błąd integralności przechowywanych danych użytkownika,
'15' H błąd wewnętrznego przesyłania danych,
'16' H nieupoważnione otwarcie obudowy,
'17' H uszkodzenie sprzętu,
'18' H RFU,
'19'H to '1F' H
'2x' Η zdarzenia związane z próbami naruszenia zabezpieczenia czujnika,
'20' H brak dalszych szczegółów,
'21' H błąd uwierzytelnienia,
'22' H błąd integralności przechowywanych danych,
'23' H błąd wewnętrznego przesyłania danych,
'24' H nieupoważnione otwarcie obudowy,
'25' H uszkodzenie sprzętu,
'26' H to '2F' H RFU,
'3х' H usterki urządzenia rejestrującego,
'30' H brak dalszych szczegółów,
'31' H usterka wewnętrzna VU,
'32' H usterka drukarki,
'33' H usterka wyświetlacza,
'34' H usterka pobierania danych,
'35' H usterka czujnika,
'36' H to '3F' H RFU,
'4x' H usterki karty,
'40' H brak dalszych szczegółów,
'41' H to '4F' H RFU,
'50' Н to '7F' H RFU,
'80' H to 'FF' H swoisty dla producenta.
Generacja 2, wersja 1:
' 0x'H zdarzenia ogólne,
' 00' H brak dalszych szczegółów,
' 01' H włożenie nieważnej karty,
' 02' H konflikt kart,
' 03' H nakładające się czasy,
' 04' H prowadzenie pojazdu bez prawidłowej karty,
' 05' H włożenie karty podczas prowadzenia pojazdu,
' 06' H sesja ostatniej karty niezamknięta prawidłowo,
' 07' H przekroczenie prędkości,
' 08' H przerwa w zasilaniu,
' 09' H błąd danych dotyczących ruchu,
' 0A' Η konflikt ruchu pojazdu,
' 0Β' H konflikt czasowy (między GNSS a wewnętrznym zegarem VU),
' 0C' H błąd połączenia z urządzeniem do łączności na odległość,
' 0D' H brak informacji o pozycji z odbiornika GNSS,
' 0Ε' H błąd połączenia z urządzeniem zewnętrznym GNSS,
' 0F' H RFU,
' 1x' H zdarzenia związane z próbami naruszenia zabezpieczenia przyrządu rejestrującego,
' 10' Η brak dalszych szczegółów,
' 11' H błąd uwierzytelnienia czujnika ruchu,
' 12 ' Η błąd uwierzytelnienia kart do tachografów,
' 13 ' Η nieupoważniona zmiana w czujniku ruchu,
' 14' H błąd integralności wprowadzania danych na kartę
' 15' H błąd integralności przechowywanych danych użytkownika,
' 16' H błąd wewnętrznego przesyłania danych,
' 17' H nieupoważnione otwarcie obudowy,
' 18' H uszkodzenie sprzętu,
' 19' H wykrycie ingerencji w GNSS,
' 1Α' Η błąd uwierzytelnienia urządzenia zewnętrznego GNSS,
' 1B' H wygaśnięcie certyfikatu urządzenia zewnętrznego GNSS,
' 1C' H to '1F' H RFU,
' 2x' H zdarzenia związane z próbami naruszenia zabezpieczenia czujnika,
' 20' H brak dalszych szczegółów,
' 21' H błąd uwierzytelnienia,
'22' H błąd integralności przechowywanych danych,
' 23' H błąd wewnętrznego przesyłania danych,
' 24' H nieupoważnione otwarcie obudowy,
' 25' H uszkodzenie sprzętu,
'26' H to '2F' H RFU,
' Зх' Н usterki urządzenia rejestrującego,
' 30' H brak dalszych szczegółów,
' 31' H usterka wewnętrzna VU,
' 32' H usterka drukarki,
' 33' H usterka wyświetlacza,
' 34' H usterka pobierania danych,
' 35' H usterka czujnika,
' 36' H wewnętrzny odbiornik GNSS,
' 37' H urządzenie zewnętrzne GNSS,
' 38' H urządzenie do łączności na odległość,
' 39' H interfejs ITS,
' 3Α' H to '3F' H RFU,
'4x' H usterki karty,
' 40' H rak dalszych szczegółów,
'41' H to '4F' H RFU,
'50' H to '7F' H RFU,
'80' H to 'FF' H swoisty dla producenta.
Generacja 2, wersja 2:
| '0x'H | zdarzenia ogólne, |
| '00'H | brak dalszych szczegółów, |
| '01'H | włożenie nieważnej karty, |
| '02'H | konflikt kart, |
| '03'H | nakładające się czasy, |
| '04'H | prowadzenie pojazdu bez prawidłowej karty, |
| '05'H | włożenie karty podczas prowadzenia pojazdu, |
| '06'H | sesja ostatniej karty niezamknięta prawidłowo, |
| '07'H | przekroczenie prędkości, |
| '08'H | przerwa w zasilaniu, |
| '09'H | błąd danych dotyczących ruchu, |
| '0A'H | konflikt ruchu pojazdu, |
| '0B'H | konflikt czasowy (między GNSS a wewnętrznym zegarem VU), |
| '0C'H | błąd połączenia z urządzeniem do łączności na odległość, |
| '0D'H | brak informacji o pozycji z odbiornika GNSS, |
| '0E'H | błąd połączenia z urządzeniem zewnętrznym GNSS, |
| '0F'H | anomalia GNSS, |
| '1x'H | zdarzenia związane z próbami naruszenia zabezpieczenia przyrządu rejestrującego, |
| '10'H | brak dalszych szczegółów, |
| '11'H | błąd uwierzytelnienia czujnika ruchu, |
| '12'H | błąd uwierzytelnienia karty do tachografu, |
| '13'H | nieupoważniona zmiana w czujniku ruchu, |
| '14'H | błąd integralności wprowadzania danych na kartę, |
| '15'H | błąd integralności przechowywanych danych użytkownika, |
| '16'H | błąd wewnętrznego przesyłania danych, |
| '17'H | nieupoważnione otwarcie obudowy, |
| '18'H | uszkodzenie sprzętu, |
| '19'H | wykrycie ingerencji w GNSS, |
| '1 A'H | błąd uwierzytelnienia urządzenia zewnętrznego GNSS, |
| '1 B'H | wygaśnięcie certyfikatu urządzenia zewnętrznego GNSS, |
| '1C'H | niespójność między danymi dotyczącymi ruchu a przechowywanymi danymi dotyczącymi czynności kierowcy, |
| '1D'H do '1F'H | RFU, |
| '2x'H | zdarzenia związane z próbami naruszenia zabezpieczenia czujnika, |
| '20'H | brak dalszych szczegółów, |
| '21'H | błąd uwierzytelnienia, |
| '22'H | błąd integralności przechowywanych danych, |
| '23'H | błąd wewnętrznego przesyłania danych, |
| '24'H | nieupoważnione otwarcie obudowy, |
| '25'H | uszkodzenie sprzętu, |
| '26'H do '2F'H | RFU, |
| '3x'H | usterki urządzenia rejestrującego, |
| '30'H | brak dalszych szczegółów, |
| '31'H | usterka wewnętrzna VU, |
| '32'H | usterka drukarki, |
| '33'H | usterka wyświetlacza, |
| '34'H | usterka pobierania danych, |
| '35'H | usterka czujnika, |
| '36'H | wewnętrzny odbiornik GNSS, |
| '37'H | urządzenie zewnętrzne GNSS, |
| '38'H | urządzenie do łączności na odległość, |
| '39'H | interfejs ITS, |
| '3 A'H | usterka czujnika wewnętrznego, |
| '3B'H do '3F'H | RFU, |
| '4x'H | usterki karty, |
| '40'H | brak dalszych szczegółów, |
| '41'H do '4F'H | RFU, |
| '50'H do '7F'H | RFU, |
| '80'H do 'FF'H | swoisty dla producenta. |
2.71. ExtendedSealIdentifier
Generacja 2:
Rozszerzony identyfikator plomby jednoznacznie identyfikuje plombę (wymóg 401 określony w załączniku IC).
manufacturerCode to kod producenta plomby. Przypisanie wartości: zob. rejestr bazy danych, którym zarządzać ma Komisja Europejska (zob. https://dtc.jrc.ec.europa.eu).
sealIdentifier to identyfikator plomby, który jest niepowtarzalny dla producenta. Przypisanie wartości: numer alfanumeryczny, niepowtarzalny w domenie producenta zgodnie z [ISO8859-1].
2.72. ExtendedSerialNumber
Unikalna identyfikacja urządzenia. Może być używana także jako identyfikator klucza publicznego urządzenia.
Generacja 1:
ExtendedSerialNumber::= SEQUENCE{
serialNumber INTEGER (0 .. 232-l),
monthYear BCDString(SIZE(2)),
type OCTET STRING(SIZE(1)),
manufacturerCode ManufacturerCode
}
serialNumber jest numerem seryjnym urządzenia, niepowtarzalnym dla producenta, typu urządzenia i miesiąca oraz roku, jak wyjaśniono poniżej.
monthYear jest identyfikacją miesiąca i roku produkcji (lub przypisanym numerem seryjnym).
Przypisanie wartości: miesiąc (dwie cyfry) i rok (dwie ostatnie cyfry) w kodzie BCD.
type jest identyfikatorem typu urządzenia.
Przypisanie wartości: swoisty dla producenta, z wartością zastrzeżoną "FFh".
manufacturerCode: jest kodem numerycznym identyfikującym producenta homologowanego urządzenia.
Generacja 2:
ExtendedSerialNumber::= SEQUENCE{
serialNumber INTEGER (0 .. 232-l),
monthYear BCDString(SIZE(2)),
type EquipmentType,
manufacturerCode ManufacturerCode
}
serialNumber, zob. generacja 1
monthYear, zob. generacja 1
type jest identyfikatorem typu urządzenia
manufacturerCode: zob. generacja 1.
2.73. FullCardNumber
Kod całkowicie identyfikujący kartę do tachografu.
FullCardNumber::= SEQUENCE {
cardType EquipmentType,
cardlssuingMemberState NationNumeric,
cardNumber CardNumber
}
cardType jest typem karty do tachografu.
cardIssuingMemberState jest kodem Strony, które wydało kartę.
cardNumber jest numerem karty.
2.74. FullCardNumberAndGeneration
Generacja 2:
Kod całkowicie identyfikujący kartę do tachografu i jej generację.
FullCardNumberAndGeneration::= SEQUENCE {
fullCardNumber FullCardNumber,
generation Generation
}
fullcardNumber identyfikuje kartę do tachografu.
generation oznacza generację używanej karty do tachografu.
2.75. Generation
Generacja 2:
wskazuje generację używanego tachografu.
Generation::= INTEGER(0..255)
Przypisanie wartości:
'00'H RFU
'01'H Generacja 1
'02'H Generacja 2
'03'H .. 'FF'H RFU
2.76. GeoCoordinates
Generacja 2:
Współrzędne geograficzne są zakodowane jako liczby całkowite. Takie liczby są wielokrotnościami kodowania ± DDMM.M dla szerokości geograficznej i ± DDDMM.M dla długości geograficznej. W powyższym przypadku odpowiednio ± DD i ± DDD oznaczają stopnie, a MM.M minuty. Długość i szerokość geograficzną nieznanej pozycji przedstawia się jako Hex '7FFFFF' (w zapisie dziesiętnym 8388607).
GeoCoordinates::= SEQUENCE {
latitude INTEGER(-90000..90001),
longitude INTEGER(-18 0000..18 0001)
}
latitude koduje się jako wielokrotność (mnożnik 10) zapisu ± DDMM.M.
longitude koduje się jako wielokrotność (mnożnik 10) zapisu ± DDMM.M.
2.77. GNSSAccuracy
Generacja 2:
Dokładność danych GNSS dotyczących położenia (definicja eee)). Taka dokładność jest kodowana jako liczba całkowita i jest wielokrotnością (mnożnik 10) wartości X.Y podanej w zdaniu GSA NMEA.
GNSSAccuracy::= INTEGER(1..100)
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).
GNSSAccumulatedDriving:= SEQUENCE {
gnssADPointerNewestRecord INTEGER(0..NoOfGNSSADRecords -1), gnssAccumulatedDrivingRecords SET SIZE(NoOfGNSSADRecords) OF
GNSSAccumulatedDrivingRecord
}
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:
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 305 i 353 określone w załączniku IC)
GNSSAccumulatedDrivingRecord::= SEQUENCE {
timeStamp TimeReal,
gnssPlaceRecord GNSSPlaceRecord,
vehicleOdometerValue OdometerShort
}
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.
2.79a. GNSSAuthAccumulatedDriving
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej, przedstawiające status uwierzytelnienia pozycji GNSS dla pojazdu, jeżeli skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech godzin (wymogi 306d i 356d określone w załączniku IC).
gnssAuthADPointerNewestRecord to indeks ostatniego uaktualnionego rekordu dotyczącego statusu uwierzytelnienia pozycji GNSS.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordu dotyczącego statusu uwierzytelnienia pozycji GNSS, rozpoczynając od "0" dla pierwszego wystąpienia w strukturze rekordu dotyczącego statusu uwierzytelnienia pozycji GNSS.
gnssAuthStatusADRecords to zbiór rekordów zawierających datę i godzinę, kiedy skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin, oraz status uwierzytelnienia pozycji GNSS.
2.79b. GNSSAuthStatusADRecord
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej, przedstawiające status uwierzytelnienia pozycji pojazdu GNSS, jeżeli skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech godzin (wymogi 306c i 356c określone w załączniku IC). Inne informacje związane z samą pozycją GNSS są przechowywane w innym rekordzie (zob. 2.79 GNSSAccumulatedDrivingRecord).
timeStamp to data i godzina, gdy skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin (która jest taka sama, jak data i godzina w odpowiednim rekordzie GNSSAccumulatedD- rivingRecord),
authenticationStatus to status uwierzytelnienia pozycji GNSS, gdy skumulowany czas prowadzenia pojazdu osiąga wielokrotność trzech godzin.
2.79c. GNSSPlaceAuthRecord
Generacja 2, wersja 2:
Informacje dotyczące pozycji GNSS dla pojazdu (wymogi 108, 109, 110, 296, 306a, 306c, 306e, 306g, 356a, 356c, 356e i 356g określone w załączniku IC).
timeStamp to data i godzina określenia pozycji GNSS dla pojazdu.
gnssAccuracy to dokładność danych dotyczących pozycji GNSS. geoCoordinates to lokalizacja zarejestrowana przy użyciu GNSS.
authenticationStatus to status uwierzytelnienia pozycji GNSS w momencie jej określenia.
2.80. GNSSPlaceRecord
Generacja 2:
Informacje dotyczące położenia GNSS pojazdu (wymagania 108, 109, 110, 296, 305, 347 i 353 określone w załączniku 1C).
GNSSPlaceRecord::= SEQUENCE {
timeStamp TimeReal,
gnssAccuracy GNSSAccuracy,
geoCoordinates GeoCoordinates
}
timeStamp jest datą i godziną określenia położenia GNSS pojazdu.
gnssAccuracy jest dokładnością danych dotyczących położenia GNSS.
geoCoordinates jest lokalizacją zapisaną przy użyciu GNSS.
2.81. HighResOdometer
Stan licznika kilometrów pojazdu: skumulowana odległość przebyta przez pojazd w czasie jego eksploatacji.
HighResOdometer::= INTEGER (0 .. 232-l)
Przypisanie wartości: liczba binarna bez znaku. Wartość wyrażona w 1/200 km w zakresie operacyjnym 0 do 21 055 406 km.
2.82. HighResTripDistance
Odległość przebyta w czasie całej lub części podróży.
HighResTripDistance::= INTEGER(0..232-l)
Przypisanie wartości: liczba binarna bez znaku. Wartość wyrażona w 1/200 km w zakresie operacyjnym 0 do 21 055 406 km.
2.83. HolderName
Nazwisko i imię (imiona) posiadacza karty.
HolderName::= SEQUENCE {
holderSurname Name,
holderFirstNames Name
holderSurname jest nazwiskiem posiadacza. Do nazwiska nie dodaje się tytułów.
Przypisanie wartości: w przypadku kart nieosobowych, holderSurname zawiera te same informacje, co companyName lub workshopName, lub controlBodyName.
holderFirstNames oznacza imię (imiona) i inicjały posiadacza.
2.84. Zarezerwowane dla przyszłego użytku
2.85. K-ConstantOfRecordingEquipment
Stała urządzenia rejestrującego (definicja m)).
K-ConstantOfRecordingEquipment::= INTEGER(0..216-1)
Przypisanie wartości: liczba impulsów na kilometr w zakresie operacyjnym 0 do 64 255 impulsów/km.
2.86. KeyIdentifier
Unikalny identyfikator klucza publicznego używany przy odwoływaniu się do klucza i do wybierania klucza. Identyfikuje także posiadacza klucza.
Keyldentifier::= CHOICE {
extendedSerialNumber ExtendedSerialNumber,
certificateRequestID CertificateRequestID,
certificationAuthorityKID CertificationAuthorityKID
}
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 Strony.
2.87. KMWCKey
Generacja 2:
Klucz AES i związana z nim wersja klucza stosowane do sparowania VU z czujnikiem ruchu. Szczegółowe informacje - zob. dodatek 11.
KMWCKey::= SEQUENCE {
kMWCKey AESKey,
keyVersion INTEGER (SIZE(l))
}
kMWCKey jest długością klucza AES w szeregu z kluczem stosowanym do sparowania VU z czujnikiem ruchu.
keyVersion oznacza wersję klucza AES.
2.88. Language
Kod identyfikujący język.
Language::= IA5String(SIZE(2))
Przypisanie wartości: kod składający się z dwóch małych liter zgodny z normą ISO 639.
2.89. LastCardDownload
Data i godzina, zapisane na karcie kierowcy, ostatniego pobierania danych z karty (do innych celów niż kontrola) - wymagania 257 i 282 określone w załączniku 1C. Datę tę aktualizuje VU lub dowolny czytnik kart.
LastCardDownload::= TimeReal
Przypisanie wartości: nie określa się.
2.89a. LengthOfFollowingData
Generacja 2, wersja 2:
Wskaźnik długości dla rozszerzalnych rekordów.
LengthOfFollowingData::= INTEGER(0.. 216-1)
Przypisanie wartości: zob. dodatek 2.
2.90. LinkCertificate
Generacja 2:
Certyfikat połączenia par kluczy Głównego Europejskiego Organu Certyfikacji.
LinkCertificate::= Certificate
2.90a. LoadType
Generacja 2, wersja 2:
Kod identyfikujący wpisany typ załadunku.
LoadType::= INTEGER(0..255)
Przypisanie wartości:
'00'H nieokreślony typ załadunku,
'01'H towary,
'02'H pasażerowie,
'03'H .. 'FF'H RFU.
2.91. L-TyreCircumference
Obwód toczny opon (definicja u)).
L-TyreCircumference::= INTEGER(0.. 216-l)
Przypisanie wartości: liczba binarna bez znaku, wyrażona w 1/8 mm w zakresie operacyjnym 0 do 8 031 mm.
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.
MAC::= CHOICE {
Mac8 OCTET STRING (SIZE(8)),
Mac12 OCTET STRING (SIZE (12)),
Mac16 OCTET STRING (SIZE (16)),
}
2.93. ManualInputFlag
Kod identyfikujący czy posiadacz karty wprowadza ręcznie czynności kierowcy przy wkładaniu karty (wymaganie 081 określone w załączniku 1B i wymaganie 102 określone w załączniku 1C).
ManuallnputFlag::= INTEGER {
noEntry (0)
manualEntries (1)
}
Przypisanie wartości: nie określa się.
2.94. ManufacturerCode
Kod identyfikujący producenta urządzeń posiadających homologację typu.
ManufacturerCode::= INTEGER(0..255)
Laboratorium właściwe dla przeprowadzania badań interoperacyjności prowadzi i publikuje wykaz kodów producenta na swojej stronie internetowej (wymaganie 454 określone w załączniku 1C).
ManufacturerCodes przyznaje się tymczasowo twórcom tachografów po wystąpieniu przez nich z wnioskiem do laboratorium właściwego dla przeprowadzania badań interoperacyjności.
2.95. ManufacturerSpecificEventFaultData
Generacja 2:
Swoiste dla producentów kody błędów upraszczają analizę błędów oraz konserwację przyrządów rejestrujących.
ManufacturerSpecificEventFaultData::= SEQUENCE {
manufacturerCode ManufacturerCode,
manufacturerSpecificErrorCode OCTET STRING(SIZE (3))
}
manufacturerCode identyfikuje producenta przyrządu rejestrującego. manufacturerSpecificErrorCode jest kodem błędu swoistym dla producenta.
2.96. MemberStateCertificate
Certyfikat klucza publicznego Strony wydany przez europejski organ certyfikacji. MemberStateCertificate::= Certificate
2.97. MemberStateCertificateRecordArray
Generacja 2:
Certyfikat Strony wraz z metadanymi stosowany w protokole pobierania danych.
MemberStateCertificateRecordArray::= SEQUENCE { recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
MemberStateCertificate
}
recordType oznacza typ rekordu (MemberStateCertificate). Przypisanie wartości: zob. RecordType
recordSize to wielkość MemberStateCertificate w bajtach.
noOfRecords jest liczbą rekordów w zbiorze. Wartość tę należy ustawić na 1, ponieważ certyfikaty mogą mieć różne długości.
records jest zbiorem certyfikatów Stron.
2.98. MemberStatePublicKey
Generacja 1:
Klucz publiczny Strony.
MemberStatePublicKey::= PublicKey
2.99. Name
Nazwa (nazwisko).
Name::= SEQUENCE {
codePage INTEGER (0..255),
name OCTET STRING (SIZE (35))
}
codePage określa zestaw znaków zdefiniowany w rozdziale 4,
name jest nazwą zakodowaną przy użyciu wyszczególnionego zestawu znaków.
2.100. NationAlpha
Alfabetyczne określenie państwa musi być zgodne ze znakami wyróżniającymi stosowanymi na pojazdach w ruchu międzynarodowym (Konwencja wiedeńska Narodów Zjednoczonych o ruchu drogowym z 1968 r.).
NationAlpha::= IA5String(SIZE(3))
Kody Nation Alpha i Numeric znajdują się na wykazie utrzymywanym na stronie internetowej laboratorium wyznaczonego do przeprowadzenia badań interoperacyjności zgodnie z wymaganiem 440 określonym w załączniku 1C.
2.101. NationNumeric
Numeryczne odesłanie do państwa.
NationNumeric::= INTEGER(0 .. 255)
Przypisanie wartości: zob. typ danych w 2.100 (NationAlpha)
Modyfikacji lub aktualizacji specyfikacji Nation Alpha lub Numeric opisanych w powyższym akapicie dokonuje się dopiero po otrzymaniu przez wyznaczone laboratorium opinii producentów przyrządów rejestrujących tachografów cyfrowych i inteligentnych posiadających homologację typu.
2.101a. NoOfBorderCrossingRecords
Generacja 2, wersja 2:
Liczba rekordów dotyczących przekroczenia granicy, które mogą być przechowywane na karcie kierowcy lub na karcie warsztatowej.
NoOfBorderCrossingRecords::= INTEGER(0.. 216-1)
Przypisanie wartości: zob. dodatek 2.
2.102. NoOfCalibrationRecords
Liczba rekordów kalibracyjnych, możliwych do przechowywania na karcie.
Generacja 1:
NoOfCalibrationRecords::= INTEGER(0..255)
Przypisanie wartości: zob. dodatek 2.
Generacja 2:
NoOfCalibrationRecords::= INTEGER(0..216-1)
Przypisanie wartości: zob. dodatek 2.
2.103. NoOfCalibrationsSinceDownload
Licznik pokazujący liczbę kalibracji wykonanych przy użyciu karty warsztatowej od ostatniego pobrania danych z tej karty (wymaganie 317 i 340 określone w załączniku 1C).
NoOfCalibrationsSinceDownload::= INTEGER(0..216-1)
Przypisanie wartości: nie określa się.
2.104. NoOfCardPlaceRecords
Liczba rekordów dotyczących miejsca, możliwych do przechowywania na karcie kierowcy lub na karcie warsztatowej.
Generacja 1:
NoOfCardPlaceRecords::= INTEGER(0..255)
Przypisanie wartości: zob. dodatek 2.
Generacja 2:
NoOfCardPlaceRecords::= INTEGER(0..216-1)
Przypisanie wartości: zob. dodatek 2.
2.105. NoOfCardVehicleRecords
Liczba rekordów dotyczących użytych pojazdów, możliwych do przechowywania na karcie kierowcy lub na karcie warsztatowej.
NoOfCardVehicleRecords::= INTEGER(0.. 216-l)
Przypisanie wartości: zob. dodatek 2.
2.106. NoOfCardVehicleUnitRecords
Generacja 2:
Liczba rekordów dotyczących przyrządów rejestrujących, możliwych do przechowywania na karcie kierowcy lub na karcie warsztatowej.
NoOfCardVehicleUnitRecords::= INTEGER(0.. 216-l)
Przypisanie wartości: zob. dodatek 2.
2.107. NoOfCompanyActivityRecords
Liczba rekordów dotyczących czynności firmy, możliwych do przechowywania na karcie firmowej. NoOfCompanyActivityRecords::= INTEGER(0.. 216-l)
Przypisanie wartości: zob. dodatek 2.
2.108. NoOfControlActivityRecords
Liczba rekordów dotyczących czynności kontrolnych, możliwych do przechowywania na karcie kontrolnej. NoOfControlActivityRecords::= INTEGER(0.. 216-l)
Przypisanie wartości: zob. dodatek 2.
2.109. NoOfEventsPerType
Liczba zdarzeń według typu, możliwych do przechowywania na karcie. NoOfEventsPerType::= INTEGER(0..255)
Przypisanie wartości: zob. dodatek 2.
2.110. NoOfFaultsPerType
Liczba usterek według typu, możliwych do przechowywania na karcie. NoOfFaultsPerType::= INTEGER(0..255)
Przypisanie wartości: zob. dodatek 2.
2.111. NoOfGNSSADRecords
Generacja 2:
Liczba rekordów skumulowanego czasu prowadzenia pojazdu z GNSS, które mogą być przechowywane na karcie.
NoOfGNSSADRecords::= INTEGER (0..216-1)
Przypisanie wartości: zob. dodatek 2.
2.111a. NoOfLoadUnloadRecords
Generacja 2, wersja 2:
Liczba rekordów dotyczących załadunku/rozładunku, które mogą być przechowywane na karcie.
NoOfLoadUnloadRecords::= INTEGER (0 .. 216-1)
Przypisanie wartości: zob. dodatek 2.
2.112. NoOfSpecificConditionRecords
Generacja 2:
Liczba rekordów warunków szczególnych, które mogą być przechowywane na karcie.
NoOfSpecificConditionRecords::= INTEGER(0..216-1)
Przypisanie wartości: zob. dodatek 2.
2.112a. NoOfLoadTypeEntryRecords
Generacja 2, wersja 2:
Liczba rekordów dotyczących typu załadunku, które mogą być przechowywane na karcie kierowcy lub na karcie warsztatowej.
NoOfLoadTypeEntryRecords::= INTEGER (0 .. 216-1)
Przypisanie wartości: zob. dodatek 2.
2.113. OdometerShort,
Stan licznika kilometrów pojazdu w skróconej postaci.
OdometerShort::= INTEGER (0 .. 224-l)
Przypisanie wartości: liczba binarna bez znaku. Wartość w km w zakresie operacyjnym 0 do 9 999 999 km.
2.114. OdometerValueMidnight
Stan licznika kilometrów o północy w danym dniu (wymaganie 090 określone w załączniku 1B i wymaganie 113 określone w załączniku 1C).
OdometerValueMidnight::= OdometerShort
Przypisanie wartości: nie określa się.
2.114a. OperationType
Generacja 2, wersja 2:
Kod identyfikujący wpisany typ operacji.
OperationType:INTEGER(0..255)
Przypisanie wartości:
'00'H RFU,
'01'H operacja załadunku,
'02'H operacja rozładunku,
'03'H operacja równoczesnego załadunku/rozładunku,
'04'H .. 'FF'H RFU.
2.115. OdometerValueMidnightRecordArray
Generacja 2:
OdometerValueMidnight wraz z metadanymi stosowany w protokole pobierania danych.
OdometerValueMidnightRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
OdometerValueMidnight
}
recordType oznacza typ rekordu (OdometerValueMidnight). Przypisanie wartości: zob. RecordType
recordSize to wielkość OdometerValueMidnight w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów OdometerValueMidnight.
2.116. OverspeedNumber
Liczba zdarzeń przekroczenia prędkości od ostatniej kontroli przekroczenia prędkości.
OverspeedNumber::= INTEGER(0..255)
Przypisanie wartości: 0 oznacza, że nie było zdarzenia przekroczenie prędkości od ostatniej kontroli przekroczenia prędkości, 1 oznacza, że było jedno zdarzenie przekroczenia prędkości od ostatniej kontroli przekroczenia prędkości... 255 oznacza, że było 255 lub więcej zdarzeń przekroczenia prędkości od ostatniej kontroli przekroczenia prędkości.
2.116a. PlaceAuthRecord
Informacje dotyczące miejsca rozpoczęcia lub zakończenia dziennego okresu pracy (wymogi 108, 271, 296, 324 i 347 określone w załączniku IC).
Generacja 2, wersja 2:
entryTime to data i godziną wpisu. entryTypeDailyWorkPeriod to typ wpisu. dailyWorkPeriodCountry to wpisany kraj. dailyWorkPeriodRegion to wpisany region. vehicleOdometerValue to stan licznika kilometrów w momencie wpisywania miejsca. entryGNSSPlaceAuthRecord to zarejestrowana lokalizacja, status uwierzytelnienia GNSS oraz godzina.
2.116b. PlaceAuthStatusRecord
Generacja 2, wersja 2:
Informacje przechowywane na karcie kierowcy lub na karcie warsztatowej, przedstawiające status uwierzytelnienia miejsca rozpoczęcia lub zakończenia dziennych okresów pracy (wymogi 306a i 356a określone w załączniku IC). Inne informacje związane z samym miejscem są przechowywane w innym rekordzie (zob. 2.117 PlaceRecord).
entryTime to data i godzina związana z wpisem (która jest taką samą datą i godziną, jak w odpowiednim rekordzie PlaceRecord).
authenticationStatus to status uwierzytelnienia zarejestrowanej pozycji GNSS.
2.117. PlaceRecord
Informacje dotyczące miejsca rozpoczęcia lub zakończenia dziennego okresu pracy (wymagania 108, 271, 296, 324 i 347 określone w załączniku 1C).
Generacja 1:
PlaceRecord::= SEQUENCE {
entryTime TimeReal,
entryTypeDailyWorkPeriod EntryTypeDailyWorkPeriod,
dailyWorkPeriodCountry NationNumeric,
dailyWorkPeriodRegion RegionNumeric,
vehicleOdometerValue OdometerShort
}
entryTime jest datą i godziną wpisu.
entryTypeDailyWorkPeriod jest typem wpisu.
dailyWorkPeriodCountry jest wprowadzonym państwem.
dailyWorkPeriodRegion jest wprowadzonym regionem.
vehicleOdometerValue jest stanem licznika kilometrów w czasie wprowadzania miejsca.
Generacja 2:
PlaceRecord::= SEQUENCE {
entryTime TimeReal,
entryTypeDailyWorkPeriod EntryTypeDailyWorkPeriod,
dailyWorkPeriodCountry NationNumeric,
dailyWorkPeriodRegion RegionNumeric,
vehicleOdometerValue OdometerShort,
entryGNSSPlaceRecord GNSSPlaceRecord
}
Oprócz generacji 1 używany jest następujący element składowy: entryGNSSPlaceRecord jest zapisaną lokalizacją i godziną.
2.117a. PositionAuthenticationStatus
Generacja 2, wersja 2:
PositionAuthenticationStatus::= INTEGER(0..255)
Przypisanie wartości (zob. dodatek 12):
'00'H nieuwierzytelniona (zob. dodatek 12, wymóg GNS_39),
'01'H uwierzytelniona (zob. dodatek 12, wymóg GNS_39),
'02'H. 'FF'H RFU.
2.118. PreviousVehicleInfo
Informacje dotyczące pojazdu poprzednio używanego przez kierowcę w chwili wkładania jego karty do przyrządu rejestrującego (wymaganie 081 określone w załączniku 1B i wymaganie 102 określone w załączniku 1C).
Generacja 1:
PreviousVehiclelnfo::= SEQUENCE {
vehicleRegistrationidentification VehicleRegistrationldentification,
cardWithdrawalTime TimeReal
}
vehicleRegistrationIdentification wskazuje numer VRN i państwo członkowskie rejestracji pojazdu.
cardWithdrawalTime jest datą i godziną wyjęcia karty.
Generacja 2:
PreviousVehiclelnfo::= SEQUENCE {
VehicleRegistrationldentification VehicleRegistrationldentification,
cardWithdrawalTime TimeReal,
vuGeneration Generation
}
Oprócz generacji 1 używany jest następujący element danych:
vuGeneration identyfikuje generację przyrządu rejestrującego.
2.119. PublicKey Generacja 1:
Klucz publiczny RSA.
PublicKey::= SEQUENCE {
rsaKeyModulus RSAKeyModulus,
rsaKeyPublicExponent RSAKeyPublicExponent
}
rsaKeyModulus jest modułem pary kluczy.
rsaKeyPublicExponent jest wykładnikiem publicznym pary kluczy.
2.120. RecordType Generacja 2:
Odniesienie do typu rekordu. Ten typ danych stosuje się w RecordArrays.
RecordType::= OCTET STRING(SIZE(1))
Przypisanie wartości:
'01' H ActivityChangeInfo,
'02' H CardSlotsStatus,
'03' H CurrentDateTime,
'04' H MemberStateCertificate,
'05' H OdometerValueMidnight,
'0б' H DateOfDayDownloaded,
'07' H SensorPaired,
'08' H Signature,
'09' H SpecificConditionRecord,
'0А' H VehicleIdentificationNumber,
'0B' H VehicleRegistrationNumber,
'0С' H VuCalibrationRecord,
'0D' H VuCardIWRecord,
'0Ε' H VuCardRecord,
'0F' Η VuCertificate,
'10' H VuCompanyLocksRecord,
'11' H VuControlActivityRecord,
'12' H VuDetailedSpeedBlock,
'13' H VuDownloadablePeriod,
'14' H VuDownloadActivityData,
'15' H VuEventRecord,
'16' H VuGNSSADRecord,
'17' H VuITSConsentRecord,
'18' H VuFaultRecord,
'19' H VuIdentification,
'1A' H VuOverSpeedingControlData,
'1B' H VuOverSpeedingEventRecord,
'1С' H VuPlaceDailyWorkPeriodRecord,
'ID' H VuTimeAdjustmentGNSSRecord,
'IE' H VuTimeAdjustmentRecord,
'1F' H VuPowerSupplyInterruptionRecord,
'20' Η SensorPairedRecord,
'21' H SensorExternalGNSSCoupledRecord,
22'H VuBorderCrossingRecord,
'23'H VuLoadUnloadRecord,
'24'H VehicleRegistrationIdentification,
'25'H do '7F'H RFU,
'80' Н to 'FF' Н swoisty dla producenta.
2.121. RegionAlpha
Alfabetyczne odniesienie do regionu w określonym kraju.
RegionAlpha::= IA5STRING(SIZE(3))
Generacja 1:
Przypisanie wartości:
' ' No information available,
Spain:
'ΑΝ' Andalucia,
'AR' Aragon,
'AST' Asturias,
'С' Cantabria,
'САТ' Cataluňa,
'CL' Castilla-León,
'СМ' Castilla-La-Mancha,
'CV' Valencia,
'ЕХТ' Extremadura,
'G' Galicia,
'ΙΒ' Baléares,
'IС' Canarias,
'LR' La Rioja,
'М' Madrid,
'MU' Murcia,
'ΝΑ' Navarra,
'PV' Pais Vasco
Generacja 2:
Kody RegionAlpha znajdują się na wykazie utrzymywanym na stronie internetowej laboratorium wyznaczonego do przeprowadzenia badań interoperacyjności.
2.122. RegionNumeric
Numeryczne odniesienie do regionu w określonym państwie.
RegionNumeric::= OCTET STRING (SIZE(l))
Generacja 1:
Przypisanie wartości:
'00' Н No information available,
Spain:
'01' Н Andalucia,
'02' Н Aragon,
'03' Н Asturias,
'04' Н Cantabria,
'05' Н Cataluňa,
'06' Н Castilla-León,
'07' Н Castilla-La-Mancha,
'08' Н Valencia,
'09' Н Extremadura,
'0А' Н Galicia,
'0В' Н Baléares,
'0С' Н Canarias,
'0D' H La Rioja,
'0Ε' H Madrid,
'0F' H Murcia,
'10' Η Navarra,
'11' Н Pais Vasco
Generacja 2:
Kody RegionNumeric znajdują się na wykazie utrzymywanym na stronie internetowej laboratorium wyznaczonego do przeprowadzenia badań interoperacyjności.
2.123. RemoteCommunicationModuleSerialNumber
Generacja 2:
Numer seryjny modułu komunikacji na odległość.
RemoteCommunicationModuleSerialNumber::= ExtendedSerialNumber
2.124. RSAKeyModulus
Generacja 1:
Moduł pary kluczy RSA.
RSAKeyModulus::= OCTET STRING (SIZE (128))
Przypisanie wartości: nieokreślona.
2.125. RSAKeyPrivateExponent
Generacja 1:
Wykładnik prywatny pary kluczy RSA.
RSAKeyPrivateExponent::= OCTET STRING (SIZE (128))
Przypisanie wartości: nieokreślona.
2.126. RSAKeyPublicExponent
Generacja1:
Wykładnik publiczny pary kluczy RSA.
RSAKeyPublicExponent::= OCTET STRING (SIZE (8))
Przypisanie wartości: nieokreślona.
2.127. RtmData Generacja2:
Definicja tego typu danych znajduje się w dodatku 14.
2.128. SealDataCard
Generacja 2:
W tym typie danych przechowuje się informacje o plombach przymocowanych do różnych części pojazdu i jest on przeznaczony do przechowywania na karcie. Ten typ danych związany jest z wymaganiem 337 określonym w załączniku 1C.
SealDataCard::= SEQUENCE {
noOfSealRecords INTEGER(1..5),
sealRecords SET SIZE(noOfSealRecords) OF SealRecord
}
noOfSealRecords jest liczbą rekordów w zbiorze sealRecords.
sealRecords jest zbiorem rekordów dotyczących plomb.
2.129. SealDataVu
Generacja 2:
W tym typie danych przechowuje się informacje o plombach przymocowanych do różnych części pojazdu i jest on przeznaczony do przechowywania w przyrządzie rejestrującym.
SealDataVu::= SEQUENCE SIZE (5) OF {
sealRecords SealRecord
}
sealRecords jest zbiorem rekordów dotyczących plomb. W przypadku gdy dostępnych jest mniej niż 5 plomb wartość EquipmentType we wszystkich niewykorzystanych sealRecords należy ustawić na 16, tj. niewykorzystane.
2.130. SealRecord
Generacja 2:
W tym typie danych przechowuje się informacje o plombie przymocowanej do danego elementu składowego. Ten typ danych związany jest z wymaganiem 337 określonym w załączniku 1C.
SealRecord::= SEQUENCE {
equipmentType EquipmentType,
extendedSealIdentifier ExtendedSealIdentifier
}
equipmentType określa typ urządzenia, do którego jest przymocowana plomba. extendedSealIdentifier jest identyfikatorem plomby przymocowanej do urządzenia.
2.131. SensorApprovalNumber
Numer homologacji typu czujnika. Generacja 1:
SensorApprovalNumber::= IA5String(SIZE(8))
Przypisanie wartości: nieokreślona. Generacja 2:
SensorApprovalNumber::= IA5String(SIZE(16))
Przypisanie wartości:
Należy podawać numer homologacji, który został opublikowany na odpowiedniej stronie internetowej Komisji Europejskiej, tj. na przykład z uwzględnieniem myślników, jeżeli występują. Numer homologacji musi być wyrównany do lewej strony.
2.132. SensorExternalGNSSApprovalNumber
Generacja 2:
Numer homologacji urządzenia zewnętrznego GNSS.
SensorExternalGNSSApprovalNumber::= IA5String(SIZE(16))
Przypisanie wartości:
Należy podawać numer homologacji, który został opublikowany na odpowiedniej stronie internetowej Komisji Europejskiej, tj. na przykład z uwzględnieniem myślników, jeżeli występują. Numer homologacji musi być wyrównany do lewej strony.
2.133. SensorExternalGNSSCoupledRecord
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące identyfikacji urządzenia zewnętrznego GNSS powiązanego z przyrządem rejestrującym (wymaganie 100 określone w załączniku 1C).
SensorExternalGNSSCoupledRecord::= SEQUENCE {
sensorSerialNumber SensorGNSSSerialNumber,
sensorApprovalNumber SensorExternalGNSSApprovalNumber,
sensorCouplingDate SensorGNSSCouplingDate
}
sensorSerialNumber jest numerem seryjnym urządzenia zewnętrznego GNSS powiązanego z przyrządem rejestrującym.
sensorApprovalNumber jest numerem homologacji tego urządzenia zewnętrznego GNSS.
sensorCouplingDate jest datą powiązania tego urządzenia zewnętrznego GNSS z przyrządem rejestrującym.
2.134. SensorExternalGNSSIdentification
Generacja 2:
Informacje dotyczące identyfikacji urządzenia zewnętrznego GNSS (wymaganie 98 określone w załączniku 1C).
SensorExternalGNSSIdentification::= SEQUENCE {
sensorSerialNumber SensorGNSSSerialNumber,
sensorApprovalNumber SensorExternalGNSSApprovalNumber,
sensorSCIdentifier SensorExternalGNSSSCIdentifier,
}
sensorSerialNumber jest rozszerzonym numerem seryjnym urządzenia zewnętrznego GNSS.
sensorApprovalNumber jest numerem homologacji urządzenia zewnętrznego GNSS.
sensorSCIdentifier jest identyfikatorem elementu zabezpieczenia urządzenia zewnętrznego GNSS.
sensorOSIdentifier jest identyfikatorem systemu operacyjnego urządzenia zewnętrznego GNSS.
2.135. SensorExternalGNSSInstallation
Generacja 2:
Informacje, przechowywane w urządzeniu zewnętrznym GNSS, dotyczące instalacji urządzenia zewnętrznego GNSS (wymaganie 123 określone w załączniku 1C).
SensorExternalGNSSInstallation::= SEQUENCE {
sensorCouplingDateFirst SensorGNSSCouplingDate,
firstVuApprovalNumber VuApprovalNumber,
firstVuSerialNumber VuSerialNumber,
sensorCouplingDateCurrent SensorGNSSCouplingDate,
currentVuApprovalNumber VuApprovalNumber,
sensorCouplingDateFirst jest datą pierwszego powiązania urządzenia zewnętrznego GNSS z przyrządem rejestrującym.
firstVuApprovalNumber jest numerem homologacji pierwszego przyrządu rejestrującego powiązanego z urządzeniem zewnętrznym GNSS.
firstVuSerialNumber jest numerem seryjnym pierwszego przyrządu rejestrującego sparowanego z urządzeniem zewnętrznym GNSS.
sensorCouplingDateCurrent jest datą obecnego powiązania urządzenia zewnętrznego GNSS z przyrządem rejestrującym.
currentVuApprovalNumber jest numerem homologacji przyrządu rejestrującego powiązanego obecnie z urządzeniem zewnętrznym GNSS.
currentVUSerialNumber jest numerem seryjnym przyrządu rejestrującego powiązanego obecnie z urządzeniem zewnętrznym GNSS.
2.136. SensorExternalGNSSOSIdentifier
Generacja 2:
Identyfikator systemu operacyjnego urządzenia zewnętrznego GNSS. SensorOSIdentifier::= IA5String(SIZE(2))
Przypisanie wartości: swoisty dla producenta.
2.137. SensorExternalGNSSSCIdentifier
Generacja 2:
Ten typ jest stosowany np. w celu zidentyfikowania kryptograficznego modułu urządzenia zewnętrznego GNSS.
Identyfikator elementu zabezpieczenia urządzenia zewnętrznego GNSS.
SensorExternalGNSSSCIdentifíer::= IA5String(SIZE(8))
Przypisanie wartości: element swoisty dla producenta.
2.138. SensorGNSSCouplingDate
Generacja 2:
Data powiązania urządzenia zewnętrznego GNSS z przyrządem rejestrującym.
SensorGNSSCouplingDate::= TimeReal
Przypisanie wartości: nieokreślona.
2.139. SensorGNSSSerialNumber
Generacja 2:
Ten typ jest wykorzystywany do przechowywania numeru seryjnego odbiornika GNSS, zarówno gdy jest w VU, jak i gdy znajduje się poza VU.
Numer seryjny odbiornika GNSS.
SensorGNSSSerialNumber::= ExtendedSerialNumber
2.140. SensorIdentification
Informacje przechowywane w czujniku ruchu dotyczące jego identyfikacji (wymaganie 077 określone w załączniku 1B i wymaganie 95 określone w załączniku 1C).
Sensorldentification::= SEQUENCE {
sensorSerialNumber SensorSerialNumber,
sensorApprovalNumber SensorApprovalNumber,
sensorSCIdentifier SensorSCIdentifier,
sensorOSIdentifier SensorOSIdentifier
}
sensorSerialNumber jest rozszerzonym numerem seryjnym czujnika ruchu (zawiera numer części i kod producenta).
sensorApprovalNumber jest numerem homologacji czujnika ruchu.
sensorSCIdentifier jest identyfikatorem elementu zabezpieczenia czujnika ruchu.
sensorOSIdentifier jest identyfikatorem systemu operacyjnego czujnika ruchu.
2.141. SensorInstallation
Informacje przechowywane w czujniku ruchu dotyczące jego instalacji (wymaganie 099 określone w załączniku 1B i wymaganie 122 określone w załączniku 1C).
Sensorlnstallation::= SEQUENCE {
sensorPairingDateFirst SensorPairingDate,
firstVuApprovalNumber VuApprovalNumber,
firstVuSerialNumber VuSerialNumber,
sensorPairingDateCurrent SensorPairingDate,
currentVuApprovalNumber VuApprovalNumber,
currentVUSerialNumber VuSerialNumber
}
sensorPairingDateFirst jest datą pierwszego sparowania czujnika ruchu z przyrządem rejestrującym.
firstVuApprovalNumber jest numerem homologacji pierwszego przyrządu rejestrującego sparowanego z czujnikiem ruchu.
firstVuSerialNumber jest numerem seryjnym pierwszego przyrządu rejestrującego sparowanego z czujnikiem ruchu.
sensorPairingDateCurrent jest datą obecnego sparowania czujnika ruchu z przyrządem rejestrującym.
currentVuApprovalNumber jest numerem homologacji przyrządu rejestrującego obecnie sparowanego z czujnikiem ruchu.
currentVUSerialNumber jest numerem seryjnym przyrządu rejestrującego obecnie sparowanego z czujnikiem ruchu.
2.142. SensorInstallationSecData
Informacje przechowywane na karcie warsztatowej dotyczące zabezpieczenia potrzebne do sparowania czujników ruchu z przyrządami rejestrującymi (wymaganie 308 i 331 określone w załączniku 1C).
Generacja 1:
SensorlnstallationSecData::= TdesSessionKey
Przypisanie wartości: zgodnie z normą ISO 16844-3.
Generacja 2:
Zgodnie z opisem w dodatku 11 karta warsztatowa musi przechowywać maksymalnie trzy klucze na potrzeby parowania czujnika ruchu z VU. Klucze te mają różne wersje.
SensorlnstallationSecData::= SEQUENCE {
kMWCKeyl KMWCKey,
kMWCKey2 KMWCKey OPTIONAL,
kMWCKey3 KMWCKey OPTIONAL
}
2.143. SensorOSIdentifier
Identyfikator systemu operacyjnego czujnika ruchu.
SensorOSIdentifier::= IA5String(SIZE(2))
Przypisanie wartości: swoisty dla producenta.
2.144. SensorPaired
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące identyfikacji czujnika ruchu sparowanego z przyrządem rejestrującym (wymaganie 079 określone w załączniku 1B).
SensorPaired::= SEQUENCE {
sensorSerialNumber SensorSerialNumber,
sensorApprovalNumber SensorApprovalNumber,
sensorPairingDateFirst SensorPairingDate
}
sensorSerialNumber jest numerem seryjnym czujnika ruchu obecnie sparowanego z przyrządem rejestrującym.
sensorApprovalNumber jest numerem homologacji czujnika ruchu obecnie sparowanego z przyrządem rejestrującym.
sensorPairingDateFirst jest datą pierwszego sparowania z przyrządem rejestrującym czujnika ruchu obecnie sparowanego z przyrządem rejestrującym.
2.145. SensorPairedRecord
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące identyfikacji czujnika ruchu sparowanego z przyrządem rejestrującym (wymaganie 97 określone w załączniku 1C).
SensorPairedRecord::= SEQUENCE {
sensorSerialNumber SensorSerialNumber,
sensorApprovalNumber SensorApprovalNumber,
sensorPairingDate SensorPairingDate
}
sensorSerialNumber jest numerem seryjnym czujnika ruchu sparowanego z przyrządem rejestrującym.
sensorApprovalNumber jest numerem homologacji tego czujnika ruchu.
sensorPairingDate jest datą sparowania tego czujnika ruchu z przyrządem rejestrującym.
2.146. SensorPairingDate
Data sparowania czujnika ruchu z przyrządem rejestrującym.
SensorPairingDate::= TimeReal
Przypisanie wartości: nieokreślona.
2.147. SensorSCIdentifier
Identyfikator elementu zabezpieczenia czujnika ruchu.
SensorSCIdentifier::= IA5String(SIZE(8).
Przypisanie wartości: element swoisty dla producenta.
2.148. SensorSerialNumber
Numer seryjny czujnika ruchu.
SensorSerialNumber::= ExtendedSerialNumber
2.149. Podpis
Podpis cyfrowy.
Generacja 1:
Signature::= OCTET STRING (SIZE (128))
Przypisanie wartości: zgodnie z dodatkiem 11 - Wspólne mechanizmy zabezpieczenia. Generacja 2:
Signature::= OCTET STRING (SIZE (64.. 132))
Przypisanie wartości: zgodnie z dodatkiem 11 - Wspólne mechanizmy zabezpieczenia.
2.150. SignatureRecordArray
Generacja 2:
Zbiór podpisów wraz z metadanymi stosowany w protokole pobierania danych.
SignatureRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF Signature
}
recordType oznacza typ rekordu (Signature). Przypisanie wartości: zob. RecordType
recordSize to wielkość Signature w bajtach.
noOfRecords jest liczbą rekordów w zbiorze. Wartość tę należy ustawić na 1, ponieważ podpisy mogą mieć różne długości.
records jest zbiorem podpisów.
2.151. SimilarEventsNumber
Liczba podobnych zdarzeń w danym dniu (wymaganie 094 określone w załączniku 1B i wymaganie 117 określone w załączniku 1C).
SimilarEventsNumber::= INTEGER(0..255)
Przypisanie wartości: 0 nie używany, 1 oznacza, że tylko jedno zdarzenie tego typu wystąpiło i jest zapamiętane dla tego dnia, 2 oznacza, że 2 zdarzenia wystąpiły w tym dniu (zapamiętane jest tylko jedno),... 255 oznacza, że 255 lub więcej zdarzeń wystąpiło w tym dniu.
2.152. SpecificConditionRecord
Informacje przechowywane na karcie kierowcy, karcie warsztatowej lub w przyrządzie rejestrującym dotyczące warunku szczególnego (wymagania 130, 276, 301, 328 i 355 określone w załączniku 1C).
SpecificConditionRecord::= SEQUENCE {
entryTime TimeReal,
specificConditionType SpecificConditionType
entryTime jest datą i godziną wprowadzenia danych.
specificConditionType jest kodem identyfikującym warunek szczególny.
2.153. SpecificConditions
Informacje przechowywane na karcie kierowcy, karcie warsztatowej lub w przyrządzie rejestrującym dotyczące warunku szczególnego (wymagania 131, 277, 302, 329 i 356 określone w załączniku 1C).
Generacja 2:
SpecificConditions:= SEQUENCE {
conditionPointerNewestRecord INTEGER(0..NoOfSpecificConditionRecords-1),
specificConditionRecords SET SIZE(NoOfSpecificConditionRecords) OF
SpecificConditionRecord
}
conditionPointerNewestRecord jest indeksem ostatniego, uaktualnionego rekordu warunku szczególnego.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordu dotyczącego warunku szczególnego, rozpoczynając od "0" dla pierwszego wystąpienia w strukturze rekordu dotyczącego warunku szczególnego.
specificConditionRecords jest zbiorem rekordów zawierających informacje o zarejestrowanych warunkach szczególnych.
2.154. SpecificConditionType
Kod identyfikujący warunek szczególny (wymagania 050b, 105a, 212a i 230a określone w załączniku 1B oraz wymaganie 62 określone w załączniku 1C).
SpecificConditionType::= INTEGER(0..255)
Generacja 1:
Przypisanie wartości:
'00' H RFU
'01' H poza zakresem - początek
'02' H poza zakresem - koniec
'03' H Przeprawa promowa/przejazd kolejowy
'04' H .. 'FF'H RFU
Generacja 2:
Przypisanie wartości:
'00' H RFU
'01' H poza zakresem - początek
'02' H poza zakresem - koniec
'03' H Przeprawa promowa/przejazd kolejowy - początek
'04' H Przeprawa promowa/przejazd kolejowy - koniec
'05' H .. 'FF'H RFU
2.155. Prędkość
Prędkość pojazdu (km/h).
Speed::= INTEGER(0..255)
Przypisanie wartości: kilometry na godzinę w zakresie operacyjnym 0 do 220 km/h.
2.156. SpeedAuthorised
Maksymalne dozwolone prędkości pojazdu (definicja hh)).
SpeedAuthorised::= Speed
2.157. SpeedAverage
Prędkość średnia w uprzednio zdefiniowanym przedziale czasu (km/h).
SpeedAverage::= Speed
2.158. SpeedMax
Prędkość maksymalna zmierzona w uprzednio zdefiniowanym przedziale czasu.
SpeedMax::= Speed
2.158a. TachographCardsGen1Suppression
Generacja 2, wersja 2:
Zdolność drugiej generacji VU do używania pierwszej generacji kart kierowcy, kontrolnej i firmowej (zob. dodatek 15, MIG_002).
TachographCardsGenlSuppression::= INTEGER (O..216-l)
Przypisanie wartości:
'0000'H przyrząd rejestrujący jest w stanie używać kart do tachografów generacji 1
(wartość domyślna),
'A5E3'H przyrząd rejestrujący nie jest w stanie używać kart do tachografów generacji 1,
Wszelkie inne wartości nieużywany.
2.159. TachographPayload
Generacja 2:
Definicja tego typu danych znajduje się w dodatku 14.
2.160. Zarezerwowany dla przyszłego użytku.
2.161. TDesSessionKey
Generacja 1:
Klucz sesyjny T-DES.
TDesSessionKey::= SEQUENCE {
tDesKeyA OCTET STRING (SIZE(8)),
tDesKeyB OCTET STRING (SIZE(8))
}
Przypisanie wartości: nie określa się.
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.
TimeReal {INTEGER:TimeRealRange}::= INTEGER (0..TimeRealRange)
Przypisanie wartości - zapisane oktetami: liczba sekund od północy 1 stycznia 1970 r. UTC.
Maksymalna możliwa data/godzina wypada w 2106 r.
2.163. TyreSize
Oznaczenie wymiarów opon.
TyreSize::= IA5String(SIZE(15))
Przypisanie wartości: zgodnie z regulaminem EKG ONZ nr 54.
2.164. VehicleIdentificationNumber
Numer identyfikacyjny pojazdu (VIN) odnoszący się do pojazdu jako całości, normalnie numer seryjny nadwozia lub ramy.
VehicleldentificationNumber::= IA5String(SIZE(17))
Przypisanie wartości: jak określono w normie ISO 3779.
2.165. VehicleIdentificationNumberRecordArray
Generacja 2:
Numer identyfikacyjny pojazdu wraz z metadanymi stosowany w protokole pobierania danych.
VehicleldentificationNumberRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
VehicleldentificationNumber
}
recordType oznacza typ rekordu (VehicleIdentificationNumber). Przypisanie wartości: zob. RecordType
recordSize to wielkość VehicleIdentificationNumber w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem numerów identyfikacyjnych pojazdu.
2.166. VehicleRegistrationIdentification
Identyfikacja pojazdu, unikalna dla Europy (VRN i państwo członkowskie).
VehicleRegistrationldentification::= SEQUENCE {
vehicleRegistrationNation NationNumeric,
vehicleRegistrationNumber VehicleRegistrationNumber
}
vehicleRegistrationNation jest państwem, w którym pojazd jest zarejestrowany. vehicleRegistrationNumber jest numerem rejestracyjnym pojazdu (VRN).
2.166a. VehicleRegistrationIdentificationRecordArray
Generacja 2, wersja 2:
Identyfikacja rejestracyjna pojazdu wraz z metadanymi stosowana w protokole pobierania danych.
recordType oznacza typ rekordu (VehicleRegistrationIdentification). Przypisanie wartości: zob. RecordType.
recordSize to wielkość VehicleRegistrationIdentification w bajtach.
noOfRecords to liczba rekordów w zbiorze.
records to zbiór identyfikacji rejestracyjnej pojazdu.
2.167. VehicleRegistrationNumber
Numer rejestracyjny pojazdu (VRN). Numer rejestracyjny przydziela organ rejestracji pojazdów.
VehicleRegistrationNumber::= SEQUENCE {
codePage INTEGER (0..255),
vehicleRegNumber OCTET STRING (SIZE (13))
}
codePage określa zestaw znaków zdefiniowany w rozdziale 4,
vehicleRegNumber jest numerem VRN zakodowanym przy użyciu wyszczególnionego zestawu znaków.
Przypisanie wartości: swoisty dla kraju.
2.168. VehicleRegistrationNumberRecordArray
Generacja 2, wersja 1:
Numer rejestracyjny pojazdu wraz z metadanymi stosowany w protokole pobierania danych.
VehicleRegistrationNumberRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
VehicleRegistrationNumber
}
recordType oznacza typ rekordu (VehicleRegistrationNumber). Przypisanie wartości: zob. RecordType
recordSize to wielkość VehicleRegistrationNumber w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem numerów rejestracyjnych pojazdu.
2.169. VuAbility
Generacja 2:
Informacje przechowywane w VU dotyczące możliwości stosowania kart do tachografów generacji 1 (wymaganie 121 określone w załączniku 1C).
VuAbility::= OCTET STRING (SIZE(l))
Przypisanie wartości - zapisane oktetami: xxxxxxxa'B (8 bitów)
Odnośnie do zdolności do obsługi generacji 1:
'a'B Zdolność do obsługi kart do tachografów generacji 1:
'0' B generacja 1 jest obsługiwana,
'1' B generacja 1 nie jest obsługiwana,
'xxxxxxx'B RFU
2.170. VuActivityDailyData
Generacja 1:
Informacje przechowywane w VU dotyczące zmian czynności lub zmian stanu prowadzenia pojazdu lub zmian stanu karty dla określonego dnia kalendarzowego (wymaganie 084 określone w załączniku 1B i wymagania 105, 106, 107 określone w załączniku 1C) i stanu czytników o godzinie 00:00 tego dnia.
VuActivityDailyData::= SEQUENCE {
noOfActivityChanges INTEGER SIZE (0..1440),
activityChangelnfos SET SIZE(noOfActivityChanges) OF
ActivityChangelnfо
}
noOfActivityChanges jest liczbą słów ActivityChangeInfo w zbiorze activityChangeInfos.
activityChangeInfos jest zbiorem słów ActivityChangeInfo przechowywanych w VU dla danego dnia. Zawsze zawiera dwa słowa ActivityChangeInfo opisujące stan dwóch czytników o godzinie 00:00 tego dnia.
2.171. VuActivityDailyRecordArray
Generacja 2:
Informacje przechowywane w VU dotyczące zmian czynności lub zmian stanu prowadzenia pojazdu lub zmian stanu karty dla określonego dnia kalendarzowego (wymaganie 105, 106, 107 określone w załączniku 1C) i stanu szczelin o godzinie 00:00 tego dnia.
VuActivityDailyRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF ActivityChangelnfo
}
recordType oznacza typ rekordu (ActivityChangeInfo). Przypisanie wartości: zob. RecordType
recordSize to wielkość ActivityChangeInfo w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem słów ActivityChangeInfo przechowywanych w VU dla danego dnia. Zawsze zawiera dwa słowa ActivityChangeInfo opisujące stan dwóch czytników o godzinie 00:00 tego dnia.
2.172. VuApprovalNumber
Numer homologacji typu przyrządu rejestrującego.
Generacja 1:
VuApprovalNumber::= IA5String(SIZE(8))
Przypisanie wartości: nieokreślona. Generacja 2:
VuApprovalNumber::= IA5String(SIZE(16))
Przypisanie wartości:
Należy podawać numer homologacji, który został opublikowany na odpowiedniej stronie internetowej Komisji Europejskiej, tj. na przykład z uwzględnieniem myślników, jeżeli występują. Numer homologacji musi być wyrównany do lewej strony.
2.173. VuCalibrationData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące kalibracji urządzenia rejestrującego (wymaganie 098 określone w załączniku 1B).
VuCalibrationData::= SEQUENCE {
noOfVuCalibrationRecords INTEGER(0..255),
vuCalibrationRecords SET SIZE(noOfVuCalibrationRecords) OF
VuCalibrationRecord
}
noOfVuCalibrationRecords jest liczbą rekordów w zbiorze vuCalibrationRecords.
vuCalibrationRecords jest zbiorem rekordów kalibracyjnych.
2.174. VuCalibrationRecord
Informacje przechowywane w przyrządzie rejestrującym dotyczące kalibracji urządzenia rejestrującego (wymaganie 098 określone w załączniku 1B i wymaganie 119 i 120 określone w załączniku 1C).
Generacja 2, wersja 1:
VuCalibrationRecord::= SEQUENCE {
calibrationPurpose CalibrationPurpose,
workshopName Name,
workshopAddress Address,
workshopCardNumber FullCardNumber,
workshopCardExpiryDate TimeReal,
vehicleIdentificationNumber VehicleIdentificationNumber,
vehicleRegistrationldentification VehicleRegistrationldentification,
wVehicleCharacteristicConstant W-VehicleCharacteristicConstant,
kConstantOfRecordingEquipment K-ConstantOfRecordingEquipment,
lTyreCircumference L-TyreCircumference,
tyreSize TyreSize,
authorisedSpeed SpeedAuthorised,
oldOdometerValue OdometerShort,
newOdometerValue OdometerShort,
oldTimeValue TimeReal,
newTimeValue TimeReal,
nextCalibrationDate TimeReal
}
calibrationPurpose jest celem kalibracji.
workshopName, workshopAddress są nazwą i adresem warsztatu.
workshopCardNumber identyfikuje kartę warsztatową używaną przy kalibracji.
workshopCardExpiryDate jest terminem ważności karty.
vehicleIdentificationNumber jest numerem VIN.
vehicleRegistrationIdentification zawiera numer VRN i Strony rejestracji.
wVehicleCharacteristicConstant jest współczynnikiem charakterystycznym pojazdu.
kConstantOfRecordingEquipment jest stałą urządzenia rejestrującego.
lTyreCircumference jest obwodem tocznym kół.
tyreSize jest oznaczeniem rozmiaru opon zamontowanych w pojeździe.
authorisedSpeed jest dozwoloną prędkością pojazdu.
oldOdometerValue, newOdometerValue są starym i nowym stanem licznika kilometrów.
oldTimeValue, newTimeValue są starą i nową wartością daty i godziny.
nextCalibrationDate jest datą następnej kalibracji typu określonego w CalibrationPurpose, którą powinien przeprowadzić autoryzowany organ kontrolny.
Generacja 2:
VuCalibrationRecord::= SEQUENCE {
CalibrationPurpose CalibrationPurpose,
workshopName Name,
workshopAddress Address,
workshopCardNumber FullCardNumber,
workshopCardExpiryDate TimeReal,
vehicleIdentificationNumber VehicleldentifícationNumber,
vehicleRegistrationldentification VehicleRegistrationldentification,
wVehicleCharacteristicConstant W-VehicleCharacteristicConstant,
kConstantOfRecordingEquipment K-ConstantOfRecordingEquipment,
lTyreCircumference L-TyreCircumference,
tyreSize TyreSize,
authorisedSpeed SpeedAuthorised,
oldOdometerValue OdometerShort,
newOdometerValue OdometerShort,
oldTimeValue TimeReal,
newTimeValue TimeReal,
nextCalibrationDate TimeReal,
sealDataVu SealDataVu
}
Oprócz generacji 1 używany jest następujący element danych:
sealDataVu podaje informacje o plombach przymocowanych do różnych części pojazdu.
Generacja 2, wersja 2:
Oprócz generacji 1 używany jest następujący element danych:
sensorSerialNumber to numer seryjny czujnika ruchu sparowanego z przyrządem rejestrującym na końcu kalibracji,
sensorGNSSSerialNumber to numer seryjny urządzenia zewnętrznego GNSS powiązanego z przyrządem rejestrującym na końcu kalibracji (jeżeli dotyczy),
rcmSerialNumber to numer seryjny urządzenia do łączności na odległość powiązanego z przyrządem rejestrującym na końcu kalibracji (jeżeli dotyczy),
sealDataVu podaje informacje o plombach przymocowanych do różnych części pojazdu. byDefaultLoadType to domyślny typ załadunku pojazdu (element obecny tylko w wersji 2). calibrationCountry to kraj, w którym wykonano kalibrację.
calibrationCountryTimestamp to data i godzina przekazania przez odbiornik GNSS pozycji wykorzystanej do określenia kraju, w którym wykonano kalibrację.
2.175. VuCalibrationRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące kalibracji urządzenia rejestrującego (wymagania 119 i 120 określone w załączniku 1C).
VuCalibrationRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
VuCalibrationRecord
}
recordType oznacza typ rekordu (VuCalibrationRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuCalibrationRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów kalibracji.
2.176. VuCardIWData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące cykli wkładania i wyjmowania kart dla kart kierowcy lub kart warsztatowych w przyrządzie rejestrującym (wymaganie 081 określone w załączniku 1B i wymaganie 103 określone w załączniku 1C).
VuCardIWData::= SEQUENCE {
noOflWRecords INTEGER (0 .. 216-1),
vuCardlWRecords SET SIZE(noOflWRecords) OF VuCardlWRecord
}
noOfIWRecords jest liczbą rekordów w zbiorze vuCardIWRecords.
vuCardIWRecords jest zbiorem rekordów dotyczących cykli wkładania i wyjmowania kart.
2.177. VuCardIWRecord
Informacje przechowywane w przyrządzie rejestrującym dotyczące cyklu wkładania i wyjmowania karty kierowcy lub karty warsztatowej w przyrządzie rejestrującym (wymaganie 081 określone w załączniku 1B i wymaganie 102 określone w załączniku 1C).
Generacja 1:
VuCardlWRecord::= SEQUENCE {
cardHolderName HolderName,
fullCardNumber FullCardNumber,
cardExpiryDate TimeReal,
cardlnsertionTime TimeReal,
vehicleOdometerValueAtInsertion OdometerShort,
cardSlotNumber CardSlotNumber,
cardWithdrawalTime TimeReal,
vehicleOdometerValueAtWithdrawal OdometerShort,
previousVehicleInfo PreviousVehiclelnfо,
manuallnputFlag ManuallnputFlag
}
cardHolderName jest nazwiskiem i imionami posiadacza karty kierowcy lub karty warsztatowej zapisanymi na karcie.
fullCardNumber jest typem karty, państwem członkowskim wydającym kartę i numerem karty zapisanymi na karcie.
cardExpiryDate jest terminem ważności karty zapisanym na karcie.
cardInsertionTime jest datą i godziną włożenia karty.
vehicleOdometerValueAtInsertion jest stanem licznika kilometrów przy wkładaniu karty.
cardSlotNumber jest szczeliną czytnika, do której karta jest włożona.
cardWithdrawalTime jest datą i godziną wyjęcia karty.
vehicleOdometerValueAtWithdrawal jest stanem licznika kilometrów przy wyjęciu karty.
previousVehicleInfo zawiera informacje o pojeździe poprzednio używanym przez kierowcę, zapisane na karcie.
manualInputFlag jest flagą pokazującą, czy posiadacz karty przy wkładaniu karty wprowadził ręcznie czynności kierowcy.
Generacja 2:
VuCardIWRecord::= SEQUENCE {
cardHolderName HolderName,
fullCardNumberAndGeneration FullCardNumberAndGeneration,
cardExpiryDate TimeReal,
cardlnsertionTime TimeReal,
vehicleOdometerValueAtInsertion OdometerShort,
cardSlotNumber CardSlotNumber,
cardWithdrawalTime TimeReal,
vehicleOdometerValueAtWithdrawal OdometerShort,
previousVehiclelnfo PreviousVehiclelnfo,
manuallnputFlag ManuallnputFlag
}
Zamiast fullCardNumber w strukturze danych generacji 2 wykorzystuje się następujący element danych.
fullCardNumberAndGeneration jest typem karty, państwem członkowskim wydającym kartę, numerem karty i generacją zapisanymi na karcie.
2.178. VuCardIWRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące cykli wkładania i wyjmowania kart kierowcy lub kart warsztatowych w przyrządzie rejestrującym (wymaganie 103 określone w załączniku 1C).
VuCardIWRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF VuCardIWRecord
}
recordType oznacza typ rekordu (VuCardIWRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuCardIWRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów dotyczących cykli wkładania i wyjmowania kart.
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).
VuCardRecord::= SEQUENCE {
cardNumberAndGenerationlnformátion FullCardNumberAndGeneration,
cardExtendedSerialNumber ExtendedSerialNumber,
cardStructureVersion CardStructureVersion,
cardNumber CardNumber
}
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.
2.180. VuCardRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące kart do tachografów używanych w tym VU. Informacje te są przeznaczone do analizy przez VU problemów dotyczących kart (wymaganie 132 określone w załączniku 1C).
VuCardRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF VuCardRecord
}
recordType oznacza typ rekordu (VuCardRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuCardRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów dotyczących kart do tachografów używanych w VU.
2.181. VuCertificate
Certyfikat klucza publicznego przyrządu rejestrującego.
VuCertifícate::= Certificate
2.182. VuCertificateRecordArray
Generacja 2:
Certyfikat VU wraz z metadanymi stosowany w protokole pobierania danych.
VuCertifícateRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF VuCertifícate
}
recordType oznacza typ rekordu (VuCertificate). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuCertificate w bajtach.
noOfRecords jest liczbą rekordów w zbiorze. Wartość tę należy ustawić na 1, ponieważ certyfikaty mogą mieć różne długości.
records jest zbiorem certyfikatów VU.
2.183. VuCompanyLocksData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące blokad firmowych (wymaganie 104 określone w załączniku 1B).
VuCompanyLocksData::= SEQUENCE {
noOfLocks INTEGER(0..255),
vuCompanyLocksRecords SET SIZE(noOfLocks) OF VuCompanyLocksRecord
}
noOfLocks jest liczbą blokad wyszczególnionych w vuCompanyLocksRecords. vuCompanyLocksRecords jest zbiorem rekordów blokad firmowych.
2.184. VuCompanyLocksRecord
Informacje przechowywane w przyrządzie rejestrującym dotyczące jednej blokady (wymaganie 104 określone w załączniku 1B i wymaganie 128 określone w załączniku 1C).
Generacja 1:
VuCompanyLocksRecord::= SEQUENCE {
locklnTime TimeReal,
lockOutTime TimeReal,
companyName Name,
companyAddress Address,
companyCardNumber FullCardNumber
}
lockInTime, lockOutTime są datą i godziną założenia i zdjęcia blokady.
companyName, companyAddress są nazwą i adresem firmy związanej z założeniem blokady.
companyCardNumber identyfikuje kartę użytą przy założeniu blokady.
Generacja 2:
VuCompanyLocksRecord::= SEQUENCE {
locklnTime TimeReal,
lockOutTime TimeReal,
companyName Name,
companyAddress Address,
companyCardNumberAndGeneration FullCardNumberAndGeneration
}
Zamiast companyCardNumber w strukturze danych generacji 2 wykorzystuje się następujący element danych.
companyCardNumberAndGeneration identyfikuje kartę, w tym jej generację, użytą przy założeniu blokady.
2.185. VuCompanyLocksRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące blokad firmowych (wymaganie 128 określone w załączniku 1C).
VuCompanyLocksRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
VuCompanyLocksRecord
}
recordType oznacza typ rekordu (VuCompanyLocksRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuCompanyLocksRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze. Wartość 0..255.
records jest zbiorem rekordów blokad firmowych.
2.185a. VuConfigurationLengthRange
Generacja 2, wersja 2:
Liczba bajtów na karcie do tachografu, dostępnych na potrzeby przechowywania konfiguracji VU.
VuConfigurationLengthRange::= INTEGER (0 .. 216-1)
Przypisanie wartości: zob. dodatek 2.
2.186. VuControlActivityData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym, dotyczące kontroli przeprowadzonych przy użyciu tego VU (wymaganie 102 określone w załączniku 1B).
VuControlActivityData::= SEQUENCE {
noOfControls INTEGER(0..20),
vuControlActivityRecords SET SIZE(noOfControls) OF
VuControlActivityRecord
}
noOfControls jest liczbą kontroli wyszczególnionych w vuControlActivityRecords.
vuControlActivityRecords jest zbiorem rekordów czynności kontrolnych.
2.187. VuControlActivityRecord
Informacje przechowywane w przyrządzie rejestrującym dotyczące kontroli wykonanej przy użycie tego VU (wymaganie 102 określone w załączniku 1B i wymaganie 126 określone w załączniku 1C).
Generacja 1:
VuControlActivityRecord::= SEQUENCE {
controlType ControlType,
controlTime TimeReal,
controlCardNumber FullCardNumber,
downloadPeriodBeginTime TimeReal,
downloadPeriodEndTime TimeReal
}
controlType jest typem kontroli.
controlTime jest datą i godziną kontroli.
controlCardNumber identyfikuje kartę kontrolną użytą przy kontroli.
downloadPeriodBeginTime jest czasem rozpoczęcia okresu, dla którego pobrano dane, w przypadku pobierania danych.
downloadPeriodEndTime jest czasem zakończenia okresu, dla którego pobrano dane, w przypadku pobierania danych.
Generacja 2:
VuControlActivityRecord::= SEQUENCE {
controlType ControlType,
controlTime TimeReal,
controlCardNumberAndGeneration FullCardNumberAndGeneration,
downloadPeriodBeginTime TimeReal,
downloadPeriodEndTime TimeReal
}
Zamiast controlCardNumber w strukturze danych generacji 2 wykorzystuje się następujący element danych.
controlCardNumberAndGeneration identyfikuje kartę kontrolną, w tym jej generację, użytą przy kontroli.
2.188. VuControlActivityRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym, dotyczące kontroli przeprowadzonych przy użyciu tego VU (wymaganie 126 określone w załączniku 1C).
VuControlActivityRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
VuControlActivityRecord
}
recordType oznacza typ rekordu (VuControlActivityRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuControlActivityRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów czynności kontrolnych VU.
2.189. VuDataBlockCounter
Licznik przechowywany na karcie pokazujący kolejno cykle wkładania/wyjmowania karty dla przyrządów rejestrujących.
VuDataBlockCounter::= BCDString (SIZE (2))
Przypisanie wartości: kolejna liczba, po osiągnięciu wartości maksymalnej 9 999 liczenie rozpoczyna się ponownie od 0.
2.190. VuDetailedSpeedBlock
Informacje przechowywane w przyrządzie rejestrującym dotyczące szczegółowej prędkości pojazdu dla minuty, przez którą pojazd był w ruchu (wymaganie 093 określone w załączniku 1B i wymaganie 116 określone w załączniku 1C).
VuDetailedSpeedBlock::= SEQUENCE {
speedBlockBeginDate TimeReal,
speedsPerSecond SEQUENCE SIZE (60) OF Speed
}
speedBlockBeginDate jest datą i godziną pierwszego odczytu prędkości w bloku.
speedsPerSecond jest chronologicznym ciągiem prędkości mierzonych co sekundę w ciągu minuty rozpoczynającej się od godziny określonej w speedBlockBeginDate (włącznie).
2.191. VuDetailedSpeedBlockRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące szczegółowej prędkości pojazdu.
VuDetailedSpeedBlockRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
VuDetailedSpeedBlock
}
recordType oznacza typ rekordu (VuDetailedSpeedBlock). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuDetailedSpeedBlock w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem bloków szczegółowej prędkości.
2.192. VuDetailedSpeedData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące szczegółowej prędkości pojazdu.
VuDetailedSpeedData::= SEQUENCE {
noOfSpeedBlocks INTEGER(0..216-1),
vuDetailedSpeedBlocks SET SIZE(noOfSpeedBlocks) OF
VuDetailedSpeedBlock
}
noOfSpeedBlocks jest liczbą bloków zarejestrowanych prędkości w zbiorze vuDetailedSpeedBlocks.
vuDetailedSpeedBlocks jest zbiorem bloków szczegółowej prędkości.
2.192a. VuDigitalMapVersion
Generacja 2, wersja 2:
Wersja mapy cyfrowej przechowywanej w przyrządzie rejestrującym (wymóg 133j określony w załączniku IC).
VuDigitalMapVersion::= IA5String(SIZE(12))
Przypisanie wartości: jak określono na specjalnej zabezpieczonej stronie internetowej udostępnionej przez Komisję Europejską (wymóg 133k określony w załączniku IC).
2.193. VuDownloadablePeriod
Najstarsza i najświeższa data i godzina, wyznaczające okres, dla którego przyrząd rejestrujący przechowuje dane dotyczące czynności kierowców (wymagania 081, 084 lub 087 określone w załączniku 1B i wymagania 102, 105, 108 określone w załączniku 1C).
VuDownloadablePeriod::= SEQUENCE {
minDownloadableTime TimeReal
maxDownloadableTime TimeReal
}
minDownloadableTime jest przechowywaną w VU datą i godziną dawniejszego włożenia karty lub zmiany czynności lub miejsca wprowadzania danych.
maxDownloadableTime jest przechowywaną w VU datą i godziną ostatniego wyjęcia karty lub zmiany czynności, lub miejsca wprowadzania danych.
2.194. VuDownloadablePeriodRecordArray
Generacja 2:
VUDownloadablePeriod wraz z metadanymi stosowany w protokole pobierania danych.
VuDownloadablePeriodRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
VuDownloadablePeriod
}
recordType oznacza typ rekordu (VuDownloadablePeriod). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuDownloadablePeriod w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów VuDownloadablePeriod.
2.195. VuDownloadActivityData
Informacje przechowywane w przyrządzie rejestrującym dotyczące ostatniego pobrania danych (wymaganie 105 określone w załączniku 1B i wymaganie 129 określone w załączniku 1C).
Generacja 1:
VuDownloadActivityData::= SEQUENCE {
downloadingTime TimeReal,
fullCardNumber FullCardNumber,
companyOrWorkshopName Name
}
downloadingTime jest datą i godziną pobierania danych.
fullCardNumber identyfikuje kartę użytą do autoryzowania pobierania danych.
companyOrWorkshopName jest nazwą firmy lub warsztatu.
Generacja 2:
VuDownloadActivityData::= SEQUENCE {
downloadingTime TimeReal,
fullCardNumberAndGeneration FullCardNumberAndGeneration,
companyOrWorkshopName Name
}
Zamiast fullCardNumber w strukturze danych generacji 2 wykorzystuje się następujący element danych.
fullCardNumberAndGeneration identyfikuje kartę kontrolną, w tym jej generację, użytą do autoryzacji pobierania danych.
2.196. VuDownloadActivityDataRecordArray
Generacja 2:
Informacje dotyczące ostatniego pobrania danych z VU (wymaganie 129 określone w załączniku 1C).
VuDownloadActivityDataRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF VuDownloadActivityData
}
recordType oznacza typ rekordu (VuDownloadActivityData). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuDownloadActivityData w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów czynności pobierania danych.
2.197. VuEventData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym, dotyczące zdarzeń (wymaganie 094 określone w załączniku 1B z wyłączeniem przekroczenia prędkości).
VuEventData::= SEQUENCE {
noOfVuEvents INTEGER(0..255),
vuEventRecords SET SIZE(noOfVuEvents) OF VuEventRecord
}
noOfVuEvents jest liczbą zdarzeń wyszczególnionych w zbiorze vuEventRecords. vuEventRecords jest zbiorem rekordów dotyczących zdarzeń.
2.198. VuEventRecord
Informacje przechowywane w przyrządzie rejestrującym, dotyczące zdarzenia (wymaganie 094 określone w załączniku 1B i wymaganie 117 określone w załączniku 1C z wyłączeniem przekroczenia prędkości).
Generacja 1:
VuEventRecord::= SEQUENCE {
eventType EventFaultType,
eventRecordPurpose EventFaultRecordPurpose,
eventBeginTime TimeReal,
eventEndTime TimeReal,
cardNumberDriverSlotBegin FullCardNumber,
cardNumberCodriverSlotBegin FullCardNumber,
cardNumberDriverSlotEnd FullCardNumber,
cardNumberCodriverSlotEnd FullCardNumber,
similarEventsNumber SimilarEventsNumber
}
eventType jest typem zdarzenia.
eventRecordPurpose jest celem, dla którego zarejestrowano to zdarzenie.
eventBeginTime jest datą i godziną rozpoczęcia zdarzenia.
eventEndTime jest datą i godziną zakończenia zdarzenia.
cardNumberDriverSlotBegin identyfikuje kartę włożoną do szczeliny karty kierowcy na początku zdarzenia.
cardNumberCodriverSlotBegin identyfikuje kartę włożoną do szczeliny karty współkierowcy na początku zdarzenia.
cardNumberDriverSlotEnd identyfikuje kartę włożoną do szczeliny karty kierowcy na końcu zdarzenia.
cardNumberCodriverSlotEnd identyfikuje kartę włożoną do szczeliny karty współkierowcy na końcu zdarzenia.
similarEventsNumber jest liczbą podobnych zdarzeń w tym dniu.
Sekwencji tej można używać dla wszystkich zdarzeń innych niż przekroczenie prędkości.
Generacja 2:
VuEventRecord::= SEQUENCE {
eventType EventFaultType,
eventRecordPurpose EventFaultRecordPurpose,
eventBeginTime TimeReal,
eventEndTime TimeReal,
cardNumberAndGenDriverSlotBegin FullCardNumberAndGeneration,
cardNumberAndGenCodriverSlotBegin FullCardNumberAndGeneration,
cardNumberAndGenDriverSlotEnd FullCardNumberAndGeneration,
cardNumberAndGenCodriverSlotEnd FullCardNumberAndGeneration,
similarEventsNumber SimilarEventsNumber,
manufacturerSpecificEventFaultData ManufасturerSpecificEventFaultData
}
Oprócz generacji 1 używane są następujące elementy danych:
manufacturerSpecificEventFaultData zawiera dodatkowe, szczegółowe informacje o zdarzeniu odnoszące się do danego producenta.
Zamiast cardNumberDriverSlotBegin, cardNumberCodriverSlotBegin, cardNumberDriverSlotEnd i cardNumber-CodriverSlotEnd w strukturze danych generacji 2 wykorzystuje się następujący element danych.
cardNumberAndGenDriverSlotBegin identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty kierowcy na początku zdarzenia.
cardNumberAndGenCodriverSlotBegin identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty współkierowcy na początku zdarzenia.
cardNumberAndGenDriverSlotEnd identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty kierowcy na końcu zdarzenia.
cardNumberAndGenCodriverSlotEnd identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty współkierowcy na końcu zdarzenia.
Jeżeli w zdarzeniu zachodzi konflikt czasu eventBeginTime i eventEndTime należy interpretować w następujący sposób:
eventBeginTime jest datą i godziną urządzenia rejestrującego.
eventEndTime jest datą i godziną GNSS.
2.199. VuEventRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym, dotyczące zdarzeń (wymaganie 117 określone w załączniku 1C z wyłączeniem przekroczenia prędkości).
VuEventRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF VuEventRecord
recordType oznacza typ rekordu (VuEventRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuEventRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów dotyczących zdarzeń.
2.200. VuFaultData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące usterek (wymaganie 096 określone w załączniku 1B).
VuFaultData::= SEQUENCE {
noOfVuFaults INTEGER(0..255),
vuFaultRecords SET SIZE(noOfVuFaults) OF VuFaultRecord
}
noOfVuFaults jest liczbą usterek wyszczególnionych w zbiorze vuFaultRecords. vuFaultRecords jest zbiorem rekordów dotyczących usterek.
2.201. VuFaultRecord
Informacje przechowywane w przyrządzie rejestrującym dotyczące jednej usterki (wymaganie 096 określone w załączniku 1B i wymaganie 118 określone w załączniku 1C).
Generacja 1:
VuFaultRecord::= SEQUENCE {
faultType EventFaultType,
faultRecordPurpose EventFaultRecordPurpose,
faultBeginTime TimeReal,
faultEndTime TimeReal,
cardNumberDriverSlotBegin FullCardNumber,
cardNumberCodriverSlotBegin FullCardNumber,
cardNumberDriverSlotEnd FullCardNumber,
cardNumberCodriverSlotEnd FullCardNumber
}
faultType jest typem usterki urządzenia rejestrującego.
faultRecordPurpose jest celem, dla którego ta usterka jest zarejestrowana.
faultBeginTime jest datą i godziną początku usterki.
faultEndTime jest datą i godziną zakończenia usterki.
cardNumberDriverSlotBegin identyfikuje kartę włożoną do szczeliny karty kierowcy na początku usterki.
cardNumberCodriverSlotBegin identyfikuje kartę włożoną do szczeliny karty współkierowcy na początku usterki.
cardNumberDriverSlotEnd identyfikuje kartę włożoną do szczeliny karty kierowcy na końcu usterki.
cardNumberCodriverSlotEnd identyfikuje kartę włożoną do szczeliny karty współkierowcy na końcu usterki.
Generacja 2:
VuFaultRecord::= SEQUENCE {
faultType EventFaultType,
faultRecordPurpose EventFaultRecordPurpose,
faultBeginTime TimeReal,
faultEndTime TimeReal,
cardNumberAndGenDriverSlotBegin FullCardNumberAndGeneration,
cardNumberAndGenCodriverSlotBegin FullCardNumberAndGeneration,
cardNumberAndGenDriverSlotEnd FullCardNumberAndGeneration,
cardNumberAndGenCodriverSlotEnd FullCardNumberAndGeneration,
manufacturerSpecificEventFaultData ManufасturerSpecificEventFaultData
}
Oprócz generacji 1 używany jest następujący element danych:
manufacturerSpecificEventFaultData zawiera dodatkowe, szczegółowe informacje o usterce odnoszące się do danego producenta.
Zamiast cardNumberDriverSlotBegin, cardNumberCodriverSlotBegin, cardNumberDriverSlotEnd i cardNumber-CodriverSlotEnd w strukturze danych generacji 2 wykorzystuje się następujący element danych.
cardNumberAndGenDriverSlotBegin identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty kierowcy na początku usterki.
cardNumberAndGenCodriverSlotBegin identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty współkierowcy na początku usterki.
cardNumberAndGenDriverSlotEnd identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty kierowcy na końcu usterki.
cardNumberAndGenCodriverSlotEnd identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty współkierowcy na końcu usterki.
2.202. VuFaultRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące usterek (wymaganie 118 określone w załączniku 1C).
VuFaultRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF VuFaultRecord
}
recordType oznacza typ rekordu (VuFaultRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuFaultRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów dotyczących usterek.
2.203. VuGNSSCDRecord
Generacja 2, wersja 1:
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).
VuGNSSADRecord::= SEQUENCE {
timeStamp TimeReal,
cardNumberAndGenDriverSlot FullCardNumberAndGeneration,
cardNumberAndGenCodriverSlot FullCardNumberAndGeneration,
gnssPlaceRecord GNSSPlaceRecord,
vehicleOdometerValue OdometerShort
}
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.
Generacja 2, wersja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące pozycji GNSS dla pojazdu, jeżeli skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech godzin (wymogi 108 i 110 określone w załączniku IC).
W wersji 2 generacji 2 zamiast gnssPlaceRecord stosuje się rekord gnssPlaceAuthRecord, który zawiera dodatkowo status uwierzytelnienia GNSS.
2.203a. VuBorderCrossingRecord
Generacja 2, wersja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące przekroczeń granicy przez pojazd, jeżeli przekroczył on granicę krajową (wymogi 133a i 133b określone w załączniku IC).
cardNumberAndGenDriverSlot identyfikuje kartę, w tym jej generację, włożoną do szczeliny czytnika karty kierowcy.
cardNumberAndGenCodriverSlot identyfikuje kartę, w tym jej generację, włożoną do szczeliny czytnika karty współkierowcy.
countryLeft to kraj, który pojazd opuścił, określony na podstawie ostatniej dostępnej pozycji przed wykryciem przekroczenia granicy. "Reszta świata" (kod 'FF'H NationNumeric) stosuje się, gdy przyrząd rejestrujący nie jest w stanie określić kraju, w którym pojazd się znajduje (np. bieżący kraj nie jest objęty zapisanymi mapami cyfrowymi).
countryEntered to kraj, do którego pojazd wjechał. "Reszta świata" (kod 'FF'H NationNumeric) stosuje się, gdy przyrząd rejestrujący nie jest w stanie określić kraju, w którym pojazd się znajduje (np. bieżący kraj nie jest objęty zapisanymi mapami cyfrowymi).
gnssPlaceAuthRecord zawiera informacje dotyczące pozycji pojazdu w momencie wykrycia przekroczenia granicy oraz statusu jej uwierzytelnienia.
vehicleOdometerValue to stan licznika kilometrów, gdy przyrząd rejestrujący wykrył, że pojazd przekroczył granicę krajową.
2.203b. VuBorderCrossingRecordArray
Generacja 2, wersja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące przekroczeń granicy przez pojazd (wymóg 133c określony w załączniku IC).
recordType oznacza typ rekordu (VuBorderCrossingRecord). Przypisanie wartości: zob. RecordType.
recordSize to wielkość VuBorderCrossingRecord w bajtach.
noOfRecords to liczba rekordów w zbiorze.
records to zbiór rekordów dotyczących przekroczenia granicy.
2.204. VuGNSSADRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące położenia pojazdu z GNSS, jeżeli skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech godzin (wymagania 108 i 110 określone w załączniku IC).
VuGNSSADRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE (noOfRecords) OF VuGNSSADRecord
}
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.
2.204a. VuGnssMaximalTimeDifference
Generacja 2, wersja 2:
Maksymalna różnica między czasem prawdziwym a czasem zegara czasu rzeczywistego VU, na podstawie maksymalnego dryftu czasu określonego w wymogu 041 w załączniku IC, przekazywanego przez przyrząd rejestrujący do urządzenia zewnętrznego GNSS, zob. dodatek 12, wymóg GNS_3g.
VuGnssMaximalTimeDifference::= INTEGER(0..65535)
2.205. VuIdentification
Informacje przechowywane w przyrządzie rejestrującym dotyczące jego identyfikacji (wymaganie 075 określone w załączniku 1B oraz wymagania 93 i 121 określone w załączniku 1C).
Generacja 1:
Vuldentifícation::= SEQUENCE {
vuManufacturerName VuManufacturerName,
vuManufacturerAddress VuManufacturerAddress,
vuPartNumber VuPartNumber,
vuSerialNumber VuSerialNumber,
vuSoftwareIdentification VuSoftwareldentification,
vuManufacturingDate VuManufacturingDate,
vuApprovalNumber VuApprovalNumber
}
vuManufacturerName jest nazwą producenta przyrządu rejestrującego. vuManufacturerAddress jest adresem producenta przyrządu rejestrującego.
vuPartNumber jest numerem części przyrządu rejestrującego.
vuSerialNumber jest numerem seryjnym przyrządu rejestrującego.
vuSoftwareIdentification identyfikuje oprogramowanie zainstalowane w przyrządzie rejestrującym.
vuManufacturingDate jest datą produkcji przyrządu rejestrującego.
vuApprovalNumber jest numerem homologacji typu przyrządu rejestrującego.
Generacja 2:
Oprócz generacji 1 używane są następujące elementy danych: vuGeneration identyfikuje generację przyrządu rejestrującego.
vuAbility podaje informację, czy VU obsługuje 1. generację kart do tachografu.
vuDigitalMapVersion to wersja mapy cyfrowej przechowywanej w przyrządzie rejestrującym (element obecny tylko w wersji 2).
2.206. VuIdentificationRecordArray
Generacja 2:
VuIdentification wraz z metadanymi stosowany w protokole pobierania danych.
VuIdentificationRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF Vuldentification
}
recordType oznacza typ rekordu (VuIdentification). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuIdentification w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów VuIdentification.
2.207. VuITSConsentRecord
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące zgody kierowcy na stosowanie inteligentnych systemów transportowych.
VuITSConsentRecord::= SEQUENCE {
cardNumberAndGen FullCardNumberAndGeneration,
consent BOOLEAN
}
companyCardNumberAndGen identyfikuje kartę, w tym jej generację. Musi to być karta kierowcy lub karta warsztatowa.
consent jest flagą wskazującą, czy kierowca wyraził zgodę na stosowanie inteligentnych systemów transportowych w danym pojeździe / przyrządzie rejestrującym.
Przypisanie wartości:
TRUE wskazuje zgodę kierowcy na stosowanie inteligentnych systemów transportowych
FALSE wskazuje odmowę kierowcy dotyczącą stosowania inteligentnych systemów transportowych
2.208. VuITSConsentRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące zgody kierowcy na stosowanie inteligentnych systemów transportowych (wymaganie 200 określone w załączniku 1C).
VuITSConsentRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF VuITSConsentRecord
}
recordType oznacza typ rekordu (VuITSConsentRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuITSConsentRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów ITS.
2.208a. VuLoadUnloadRecord
Generacja 2, wersja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące wpisanej operacji załadunku/roz- ładunku (wymogi 133e, 133f i 133g określone w załączniku IC).
timeStamp to data i godzina wpisania operacji załadunku/rozładunku.
operationType to wpisany typ operacji (załadunek, rozładunek lub równoczesny załadunek/rozładunek).
cardNumberAndGenDriverSlot identyfikuje kartę, w tym jej generację, włożoną do szczeliny czytnika karty kierowcy.
cardNumberAndGenCodriverSlot identyfikuje kartę, w tym jej generację, włożoną do szczeliny czytnika karty współkierowcy.
gnssPlaceAuthRecord zawiera informacje dotyczące pozycji pojazdu oraz jej statusu uwierzytelnienia.
vehicleOdometerValue to stan licznika kilometrów w związku z operacją załadunku/rozładunku.
2.208b. VuLoadUnloadRecordArray
Generacja 2, wersja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące wpisanej operacji załadunku/roz- ładunku (wymóg 133h określony w załączniku IC).
recordType oznacza typ rekordu (VuLoadUnloadRecord).Przypisanie wartości: zob. RecordType. recordSize to wielkość VuLoadUnloadRecord w bajtach.
noOfRecords to liczba rekordów w zbiorze.
records to zbiór rekordów dotyczących operacji załadunku/rozładunku.
2.209. VuManufacturerAddress
Adres producenta przyrządu rejestrującego.
VuManufacturerAddress::= Address
Przypisanie wartości: nieokreślona.
2.210. VuManufacturerName
Nazwa producenta przyrządu rejestrującego.
VuManufacturerName::= Name
Przypisanie wartości: nieokreślona.
2.211. VuManufacturingDate
Data produkcji przyrządu rejestrującego.
VuManufacturingDate::= TimeReal
Przypisanie wartości: nieokreślona.
2.212. VuOverSpeedingControlData
Informacje przechowywane w przyrządzie rejestrującym dotyczące przekroczeń prędkości od ostatniej kontroli przekroczenia prędkości (wymaganie 095 określone w załączniku 1B i wymaganie 117 określone w załączniku 1C).
VuOverSpeedingControlData::= SEQUENCE {
lastOverspeedControiTime TimeReal,
firstOverspeedSince TimeReal,
numberOfOverspeedsince OverspeedNumber
}
lastOverspeedControlTime jest datą i godziną ostatniej kontroli przekroczenia prędkości.
firstOverspeedSince jest datą i godziną pierwszego przekroczenia prędkości po tej ostatniej kontroli przekroczenia prędkości.
numberOfOverspeedSince jest liczbą zdarzeń przekroczenia prędkości od ostatniej kontroli przekroczenia prędkości.
2.213. VuOverSpeedingControlDataRecordArray
Generacja 2:
VuOverSpeedingControlData wraz z metadanymi stosowany w protokole pobierania danych.
VuOverSpeedingControlDataRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
VuOverSpeedingControlData
}
recordType oznacza typ rekordu (VuOverSpeedingControlData). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuOverSpeedingControlData w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów danych kontroli przekroczenia prędkości.
2.214. VuOverSpeedingEventData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące zdarzeń przekroczenia prędkości (wymaganie 094 określone w załączniku 1B).
VuOverSpeedingEventData::= SEQUENCE {
noOfVuOverSpeedingEvents INTEGER(0..255),
vuOverSpeedingEventRecords SET SIZE(noOfVuOverSpeedingEvents) OF
VuOverSpeedingEventRecord
}
noOfVuOverSpeedingEvents jest liczbą zdarzeń wyszczególnionych w zbiorze vuOverSpeedingEventRecords.
vuOverSpeedingEventRecords jest zbiorem rekordów zdarzeń przekroczenia prędkości.
2.215. VuOverSpeedingEventRecord
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące zdarzeń przekroczenia prędkości (wymaganie 094 określone w załączniku 1B i wymaganie 117 określone w załączniku 1C).
VuOverSpeedingEventRecord::= SEQUENCE {
eventType EventFaultType,
eventRecordPurpose EventFaultRecordPurpose,
eventBeginTime TimeReal,
eventEndTime TimeReal,
maxSpeedValue SpeedMax,
averageSpeedValue SpeedAverage,
cardNumberDriverSlotBegin FullCardNumber,
similarEventsNumber SimilarEventsNumber
}
eventType jest typem zdarzenia.
eventRecordPurpose jest celem, dla którego zarejestrowano to zdarzenie.
eventBeginTime jest datą i godziną rozpoczęcia zdarzenia.
eventEndTime jest datą i godziną zakończenia zdarzenia.
maxSpeedValue jest maksymalną prędkością zmierzoną w czasie zdarzenia.
averageSpeedValue jest średnią arytmetyczną prędkości zmierzonych w czasie zdarzenia.
cardNumberDriverSlotBegin identyfikuje kartę włożoną do szczeliny karty kierowcy na początku zdarzenia.
similarEventsNumber jest liczbą podobnych zdarzeń w tym dniu.
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące zdarzeń przekroczenia prędkości (wymaganie 094 określone w załączniku 1B i wymaganie 117 określone w załączniku 1C).
VuOverSpeedingEventRecord::= SEQUENCE {
eventType EventFaultType,
eventRecordPurpose EventFaultRecordPurpose,
eventBeginTime TimeReal,
eventEndTime TimeReal,
maxSpeedValue SpeedMax,
averageSpeedValue SpeedAverage,
cardNumberAndGenDriverSlotBegin FullCardNumberAndGeneration,
similarEventsNumber SimilarEventsNumber
}
Zamiast cardNumberDriverSlotBegin w strukturze danych generacji 2 wykorzystuje się następujący element danych.
cardNumberAndGenDriverSlotBegin identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty kierowcy na początku zdarzenia.
2.216. VuOverSpeedingEventRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące zdarzeń przekroczenia prędkości (wymaganie 117 określone w załączniku 1C).
VuOverSpeedingEventRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
VuOverSpeedingEventRecord
}
recordType oznacza typ rekordu (VuOverSpeedingEventRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuOverSpeedingEventRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów zdarzeń przekroczenia prędkości.
2.217. VuPartNumber
Numer części przyrządu rejestrującego.
VuPartNumber::= IA5String(SIZE(16))
Przypisanie wartości: swoista dla producenta VU.
2.218. VuPlaceDailyWorkPeriodData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące miejsc rozpoczęcia lub zakończenia dziennego okresu pracy kierowców (wymaganie 087 określone w załączniku 1B oraz wymagania 108 i 110 określone w załączniku 1C).
VuPlaceDailyWorkPeriodData::= SEQUENCE {
noOfPlaceRecords INTEGER(0..255),
vuPlaceDailyWorkPeriodRecords SET SIZE(noOfPlaceRecords) OF
VuPlaceDailyWorkPeriodRecord
}
noOfPlaceRecords jest liczbą rekordów wyszczególnionych w zbiorze vuPlaceDailyWorkPeriodRecords.
vuPlaceDailyWorkPeriodRecords jest zbiorem rekordów dotyczących miejsca.
2.219. VuPlaceDailyWorkPeriodRecord
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące miejsca rozpoczęcia lub zakończenia dziennego okresu pracy kierowcy (wymaganie 087 określone w załączniku 1B oraz wymagania 108 i 110 określone w załączniku 1C).
VuPlaceDailyWorkPeriodRecord::= SEQUENCE {
fullCardNumber FullCardNumber,
placeRecord PlaceRecord
}
fullCardNumber zawiera typ karty kierowcy, państwo członkowskie wydające kartę i numer karty.
placeRecord zawiera informacje dotyczące wprowadzonego miejsca.
Generacja 2, wersja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące miejsca rozpoczęcia lub zakończenia dziennego okresu pracy kierowcy (wymaganie 087 określone w załączniku 1B oraz wymagania 108 i 110 określone w załączniku 1C).
VuPlaceDailyWorkPeriodRecord::= SEQUENCE {
fullCardNumberAndGeneration FullCardNumberAndGeneration,
placeRecord PlaceRecord
}
Zamiast fullCardNumber w strukturze danych generacji 2 wykorzystuje się następujący element danych:
fullCardNumberAndGeneration jest typem karty, państwem członkowskim wydającym kartę, numerem karty i generacją przechowywanymi na karcie.
Generacja 2, wersja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące miejsca rozpoczęcia lub zakończenia dziennego okresu pracy kierowcy (wymóg 087 określony w załączniku 1B oraz wymogi 108 i 110 określone w załączniku 1C).
Zamiast placeRecord w strukturze danych wersji 2 generacji 2 wykorzystuje się następujący element danych:
placeAuthRecord zawiera informacje dotyczące wpisanego miejsca, zarejestrowanej pozycji, statusu uwierzytelnienia GNSS i godziny określenia pozycji.
2.220. VuPlaceDailyWorkPeriodRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące miejsc rozpoczęcia lub zakończenia dziennego okresu pracy kierowców (wymagania 108 i 110 określone w załączniku 1C).
VuPlaceDailyWorkPeriodRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
VuPlaceDailyWorkPeriodRecord
}
recordType oznacza typ rekordu (VuPlaceDailyWorkPeriodRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuPlaceDailyWorkPeriodRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów dotyczących miejsca.
2.221. VuPrivateKey
Generacja 1:
Klucz prywatny przyrządu rejestrującego.
VuPrivateKey::= RSAKeyPrivateExponent
2.222. VuPublicKey
Generacja 1:
Klucz publiczny przyrządu rejestrującego.
VuPublicKey::= PublicKey
2.222a. VuRtcTime
Generacja 2, wersja 2:
Czas zegara czasu rzeczywistego VU, przekazywany przez VU do urządzenia zewnętrznego GNSS, zob. dodatek 12, wymóg GNS_3f.
VuRtcTime::= TimeReal
2.223. VuSerialNumber
Numer seryjny przyrządu rejestrującego (wymaganie 075 określone w załączniku 1B i wymaganie 93 określone w załączniku 1C).
VuSerialNumber::= ExtendedSerialNumber
2.224. VuSoftInstallationDate
Data instalacji wersji oprogramowania przyrządu rejestrującego.
VuSoftlnstallationDate::= TimeReal
Przypisanie wartości: nieokreślona.
2.225. VuSoftwareIdentification
Informacje przechowywane w przyrządzie rejestrującym dotyczące zainstalowanego oprogramowania.
VuSoftwareldentification::= SEQUENCE {
vuSoftwareVersion VuSoftwareVersion,
vuSoftlnstallationDate VuSoftinstallationDate
}
vuSoftwareVersion jest numerem wersji oprogramowania przyrządu rejestrującego. vuSoftInstallationDate jest datą zainstalowania wersji oprogramowania.
2.226. VuSoftwareVersion
Numer wersji oprogramowania przyrządu rejestrującego.
VuSoftwareVersion::= IA5String(SIZE(4))
Przypisanie wartości: nieokreślona.
2.227. VuSpecificConditionData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące warunków szczególnych.
VuSpecificConditionData::= SEQUENCE {
noOfSpecificConditionRecords INTEGER(0..216-1)
specificConditionRecords SET SIZE (noOfSpecificConditionRecords) OF
SpecificConditionRecord
}
noOfSpecificConditionRecords jest liczbą rekordów wyszczególnionych w zbiorze specificConditionRecords.
specificConditionRecords jest zbiorem rekordów dotyczących warunków szczególnych.
2.228. VuSpecificConditionRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące warunków szczególnych (wymaganie 130 określone w załączniku 1C).
VuSpecificConditionRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
SpecificConditionRecord
}
recordType oznacza typ rekordu (SpecificConditionRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość SpecificConditionRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów dotyczących warunków szczególnych.
2.229. VuTimeAdjustmentData
Generacja 1:
Informacje przechowywane w przyrządzie rejestrującym dotyczące korekt czasu dokonanych poza regularną kalibracją (wymaganie 101 określone w załączniku 1C).
VuTimeAdjustmentData::= SEQUENCE {
noOfVuTimeAdjRecords INTEGER(0..6),
vuTimeAdjustmentRecords SET SIZE(noOfVuTimeAdjRecords) OF
VuTimeAdj ustmentRecord
}
noOfVuTimeAdjRecords jest liczbą rekordów w zbiorze vuTimeAdjustmentRecords.
vuTimeAdjustmentRecords jest zbiorem rekordów dotyczących korekty czasu.
2.230. Zarezerwowany dla przyszłego użytku
2.231. Zarezerwowany dla przyszłego użytku
2.232. VuTimeAdjustmentRecord
Informacje przechowywane w przyrządzie rejestrującym dotyczące korekty czasu dokonanej poza regularną kalibracją (wymaganie 101 określone w załączniku 1B oraz wymagania 124 i 125 określone w załączniku 1C).
Generacja 1:
VuTimeAdjustmentRecord::= SEQUENCE {
oldTimeValue TimeReal,
newTimeValue TimeReal,
workshopName Name,
workshopAddress Address,
workshopCardNumber FullCardNumber
}
oldTimeValue, newTimeValue są starą i nową wartością daty i godziny.
workshopName, workshopAddress są nazwą i adresem warsztatu.
workshopCardNumber identyfikuje kartę warsztatowa użytą do dokonania korekty czasu.
Generacja 2:
VuTimeAdjustmentRecord::= SEQUENCE {
oldTimeValue TimeReal,
newTimeValue TimeReal,
workshopName Name,
workshopAddress Address,
workshopCardNumberAndGeneration FullCardNumberAndGeneration
}
Zamiast workshopCardNumber w strukturze danych generacji 2 wykorzystuje się następujący element danych.
workshopCardNumberAndGeneration identyfikuje kartę warsztatowa, w tym jej generację, użytą do dokonania korekty czasu.
2.233. VuTimeAdjustmentRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące korekt czasu dokonanych poza regularną kalibracją (wymagania 124 i 125 określone w załączniku 1C).
VuTimeAdjustmentRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
VuTimeAdj ustmentRecord
}
recordType oznacza typ rekordu (VuTimeAdjustmentRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuTimeAdjustmentRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów korekty czasu.
2.234. WorkshopCardApplicationIdentification
Informacje przechowywane na karcie warsztatowej dotyczące identyfikacji aplikacji na karcie (wymagania 307 i 330 określone w załączniku 1C).
Generacja 1:
WorkshopCardApplicationldentification::= SEQUENCE {
typeOfTachographCardld EquipmentType,
cardStructureVersion CardstructureVersion,
noOfΕventsPerType NoOfΕventsPerType,
noOfFaultsPerType NoOfFaultsPerType,
activityStructureLength CardActivityLengthRange,
noOfCardVehicleRecords NoOfCardVehicleRecords,
noOfCardPlaceRecords NoOfCardPlaceRecords,
noOfCalibrationRecords NoOfCalibrationRecords
}
typeOfTachographCardId określa wdrożony typ karty.
cardStructureVersion określa wersję struktury wdrożonej na karcie.
noOfEventsPerType jest liczbą zdarzeń według typu zdarzenia możliwych do zarejestrowania na karcie.
noOfFaultsPerType jest liczbą usterek według typu usterki możliwych do zarejestrowania na karcie.
activityStructureLength podaje liczbę bajtów dostępnych do przechowywania rekordów czynności.
noOfCardVehicleRecords jest liczbą rekordów dotyczących pojazdów możliwych do zarejestrowania na karcie.
noOfCardPlaceRecords jest liczbą miejsc możliwych do zarejestrowania na karcie.
noOfCalibrationRecords jest liczbą rekordów kalibracyjnych możliwych do zarejestrowania na karcie.
Generacja 2:
WorkshopCardApplicationldentification::= SEQUENCE {
typeOfTachographCardld EquipmentType,
cardStructureVersion CardStructureVersion,
noOfEventsPerType NoOfEventsPerType,
noOfFaultsPerType NoOfFaultsPerType,
activityStructureLength CardActivityLengthRange,
noOfCardVehicleRecords NoOfCardVehicleRecords,
noOfCardPlaceRecords NoOfCardPlaceRecords,
noOfCalibrationRecords NoOfCalibrationRecords,
noOfGNSSADRecords NoOfGNSSADRecords,
noOfSpecificConditionRecords NoOfSpecificConditionRecords,
noOfCardVehicleUnitRecords NoOfCardVehicleUnitRecords
}
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.
2.234a. WorkshopCardApplicationIdentificationV2
Generacja 2, wersja 2:
Informacje przechowywane na karcie warsztatowej dotyczące identyfikacji aplikacji karty (wymóg 330a określony w załączniku IC).
lengthOfFollowingData to liczba kolejnych bajtów we wpisie.
noOfBorderCrossingRecords to liczba rekordów dotyczących przekroczenia granicy, które mogą być przechowywane na karcie warsztatowej.
noOfLoadUnloadRecords to liczba rekordów dotyczących załadunku/rozładunku, które mogą być przechowywane na karcie warsztatowej.
noOfLoadTypeEntryRecords to liczba rekordów dotyczących wpisu typu załadunku, które mogą być przechowywane na karcie warsztatowej.
vuConfigurationLengthRange to liczba bajtów na karcie do tachografu, dostępnych na potrzeby przechowywania konfiguracji VU.
2.234b. WorkshopCardCalibrationAddData
Generacja 2, wersja 2:
Informacje przechowywane na karcie warsztatowej dotyczące dodatkowych danych (tj. domyślnego typu załadunku) wprowadzonych podczas kalibracji (wymóg 356l określony w załączniku IC).
calibrationPointerNewestRecord to indeks ostatniego uaktualnionego rekordu dodatkowych danych kalibracyjnych.
Przypisanie wartości: liczba odpowiadająca stanowi licznika rekordu dodatkowych danych kalibra- cyjnych, rozpoczynając od '0' dla pierwszego wystąpienia w strukturze rekordu dodatkowych danych kalibracyjnych.
workshopCardCalibrationAddDataRecords to zbiór rekordów zawierających starą wartość daty i godziny, wartość identyfikacji pojazdu oraz domyślny typ załadunku pojazdu.
2.234c. WorkshopCardCalibrationAddDataRecord
Generacja 2, wersja 2:
Informacje przechowywane na karcie warsztatowej dotyczące domyślnego typu załadunku pojazdu wprowadzonego podczas kalibracji (wymóg 356k określony w załączniku IC).
oldTimeValue to stara wartość daty i godziny zawarta w odpowiednim rekordzie WorkshopCardCalibrationRecord,
vehicleIdentificationNumber to numer identyfikacyjny pojazdu, również zawarty w odpowiednim rekordzie WorkshopCardCalibrationRecord,
byDefaultLoadType to domyślny typ załadunku pojazdu (element obecny tylko w wersji 2).
calibrationCountry to kraj, w którym wykonano kalibrację, calibrationCountryTimestamp to data i godzina przekazania przez odbiornik GNSS pozycji wykorzystanej do określenia tego kraju.
2.235. WorkshopCardCalibrationData
Informacje przechowywane na karcie warsztatowej dotyczące czynności warsztatowych wykonanych przy użyciu karty (wymagania 314, 316, 337 i 339 określone w załączniku 1C).
WorkshopCardCalibrationData::= SEQUENCE {
calibrationTotalNumber INTEGER(0 .. 216-l),
calibrationPointerNewestRecord INTEGER(0.. NoOfCalibrationRecords-l),
calibrationRecords SET SIZE(NoOfCalibrationRecords) OF
WorkshopCardCalibrationRecord
}
calibrationTotalNumber jest całkowitą liczbą kalibracji wykonanych przy użyciu karty.
calibrationPointerNewestRecord jest indeksem ostatniego, uaktualnionego rekordu kalibracyjnego.
Przypisanie wartości: liczba odpowiadającą licznikowi rekordów kalibracyjnych, rozpoczynając od "0" dla pierwszego wystąpienia rekordu kalibracyjnego w strukturze.
calibrationRecords jest zbiorem rekordów zawierających informacje o kalibracji lub korekcie czasu.
2.236. WorkshopCardCalibrationRecord
Informacje przechowywane na karcie warsztatowej dotyczące czynności wykonanych przy użyciu karty (wymagania 314 i 337 określone w załączniku 1C).
Generacja 1:
WorkshopCardCalibrationRecord::= SEQUENCE {
calibrationPurpose CalibrationPurpose,
vehicleIdentificationNumber VehicleIdentificationNumber,
vehicleRegistration VehicleRegistrationldentification,
wVehicleCharacteristicConstant W-VehicleCharacteristicConstant,
kConstantOfRecordingEquipment K-ConstantOfRecordingEquipment,
lTyreCircumference L-TyreCircumference,
tyreSize TyreSize,
authorisedSpeed SpeedAuthorised,
oldOdometerValue OdometerShort,
newOdometerValue OdometerShort,
oldTimeValue TimeReal,
newTimeValue TimeReal,
nextCalibrationDate TimeReal,
vuPartNumber VuPartNumber,
vuSerialNumber VuSerialNumber,
sensorSerialNumber SensorSerialNumber
}
calibrationPurpose jest celem kalibracji.
vehicleIdentificationNumber jest numerem VIN.
vehicleRegistration zawiera numer VRN i Strony rejestracji.
wVehicleCharacteristicConstant jest współczynnikiem charakterystycznym pojazdu.
kConstantOfRecordingEquipment jest stałą urządzenia rejestrującego.
lTyreCircumference jest obwodem tocznym kół.
tyreSize jest oznaczeniem rozmiarów opon zamontowanych w pojeździe.
authorisedSpeed jest maksymalną, dozwoloną prędkością pojazdu.
oldOdometerValue, newOdometerValue są starym i nowym stanem licznika kilometrów.
oldTimeValue, newTimeValue są starą i nową wartością daty i godziny.
nextCalibrationDate jest datą następnej kalibracji typu określonego w CalibrationPurpose, którą powinien przeprowadzić autoryzowany organ kontrolny.
vuPartNumber, vuSerialNumber and sensorSerialNumber są elementami danych do identyfikacji urządzenia rejestrującego.
Generacja 2:
WorkshopCardCalibrationRecord::= SEQUENCE {
CalibrationPurpose CalibrationPurpose,
vehicleIdentificationNumber VehicleIdentificationNumber,
vehicleRegistration VehicleRegistrationldentification,
wVehicleCharacteristicConstant W-VehicleCharacteristicConstant,
kConstantOfRecordingEquipment K-ConstantOfRecordingEquipment,
lTyreCircumference L-TyreCircumference,
tyreSize TyreSize,
authorisedSpeed SpeedAuthorised,
oldOdometerValue OdometerShort,
newOdometerValue OdometerShort,
oldTimeValue TimeReal,
newTimeValue TimeReal,
nextCalibrationDate TimeReal,
vuPartNumber VuPartNumber,
vuSerialNumber VuSerialNumber,
sensorSerialNumber SensorSerialNumber,
sensorGNSSSerialNumber SensorGNSSSerialNumber,
rcmSerialNumber RemoteCommunicationModuleSerialNumber,
sealDataCard SealDataCard
}
Oprócz generacji 1 używane są następujące elementy danych:
sensorGNSSSerialNumber, który identyfikuje urządzenie zewnętrzne GNSS.
rcmSerialNumber, który identyfikuje moduł komunikacji na odległość.
sealDataCard podaje informacje o plombach przymocowanych do różnych części pojazdu.
2.237. WorkshopCardHolderIdentif ication
Informacje przechowywane na karcie warsztatowej dotyczące identyfikacji posiadacza karty (wymagania 311 i 334 określone w załączniku 1C).
WorkshopCardHolderldentification::= SEQUENCE {
workshopName Name,
workshopAddress Address,
cardHolderName HolderName,
cardHolderPreferredLanguage Language
}
workshopName jest nazwą warsztatu posiadacza karty.
workshopAddressjest adresem warsztatu posiadacza karty.
cardHolderName jest nazwiskiem i imieniem (imionami) posiadacza karty (np. nazwiskiem mechanika).
cardHolderPreferredLanguage jest preferowanym językiem posiadacza karty.
2.238. WorkshopCardPIN
Osobisty numer identyfikacyjny (PIN) karty warsztatowej (wymaganie 309 i 332 określone w załączniku 1C).
WorkshopCardPIN::= IA5String(SIZE(8))
Przypisanie wartości: PIN znany posiadaczowi karty, z prawej strony wypełniony bajtami o wartości "FF" aż do 8 bajtów.
2.239. W-VehicleCharacteristicConstant
Współczynnik charakterystyczny pojazdu (definicja k)).
W-VehicleCharacteristicConstant::= INTEGER(0..216-1))
Przypisanie wartości: liczba impulsów na kilometr w zakresie operacyjnym 0 do 64 255 impulsów/km.
2.240. VuPowerSupplyInterruptionRecord
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące zdarzeń przerwy w zasilaniu (wymaganie 117 określone w załączniku 1C).
VuPowerSupplylnterruptionRecord::= SEQUENCE {
eventType EventFaultType,
eventRecordPurpose EventFaultRecordPurpose,
eventBeginTime TimeReal,
eventEndTime TimeReal,
cardNumberAndGenDriverSlotBegin FullCardNumberAndGeneration,
cardNumberAndGenDriverSlotEnd FullCardNumberAndGeneration,
cardNumberAndGenCodriverSlotBegin FullCardNumberAndGeneration,
cardNumberAndGenCodriverSlotEnd FullCardNumberAndGeneration,
similarEventsNumber SimilarEventsNumber
}
eventType jest typem zdarzenia.
eventRecordPurpose jest celem, dla którego zarejestrowano to zdarzenie.
eventBeginTime jest datą i godziną rozpoczęcia zdarzenia.
eventEndTime jest datą i godziną zakończenia zdarzenia.
cardNumberAndGenDriverSlotBegin identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty kierowcy na początku zdarzenia.
cardNumberAndGenDriverSlotEnd identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty kierowcy na końcu zdarzenia.
cardNumberAndGenCodriverSlotBegin identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty współkierowcy na początku zdarzenia.
cardNumberAndGenCodriverSlotEnd identyfikuje kartę, w tym jej generację, włożoną do szczeliny karty współkierowcy na końcu zdarzenia.
similarEventsNumber jest liczbą podobnych zdarzeń w tym dniu.
2.241. VuPowerSupplyInterruptionRecordArray
Generacja 2:
Informacje przechowywane w przyrządzie rejestrującym dotyczące zdarzeń przerwy w zasilaniu (wymaganie 117 określone w załączniku 1C).
VuPowerSupplylnterruptionRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
VuPowerSupplylnterruptionRecord
}
recordType oznacza typ rekordu (VuPowerSupplyInterruptionRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość VuPowerSupplyInterruptionRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów zdarzeń przerwy w zasilaniu.
2.242. VuSensorExternalGNSSCoupledRecordArray
Generacja 2:
Zbiór zapisów SensorExternalGNSSCoupledRecord wraz z metadanymi stosowany w protokole pobierania danych.
VuSensorExternalGNSSCoupledRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF
SensorExternalGNSSCoupledRecord
}
recordType oznacza typ rekordu (SensorExternalGNSSCoupledRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość SensorExternalGNSSCoupledRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów SensorExternalGNSSCoupled.
2.243. VuSensorPairedRecordArray
Generacja 2:
Zbiór zapisów SensorPairedRecord wraz z metadanymi stosowany w protokole pobierania danych.
VuSensorPairedRecordArray::= SEQUENCE {
recordType RecordType,
recordSize INTEGER(1..65535),
noOfRecords INTEGER(0..65535),
records SET SIZE(noOfRecords) OF SensorPairedRecord
}
recordType oznacza typ rekordu (SensorPairedRecord). Przypisanie wartości: zob. RecordType
recordSize to wielkość SensorPairedRecord w bajtach.
noOfRecords jest liczbą rekordów w zbiorze.
records jest zbiorem rekordów sparowanego czujnika.
3. DEFINICJE WARTOŚCI I ZAKRESU WIELKOŚCI
Definicja wartości zmiennych używana w definicjach w ust. 2.
TimeRealRange::= 232-l
4. ZESTAW ZNAKÓW:
W łańcuchach IA5Strings używa się znaków ASCII zdefiniowanych w normie ISO/IEC 8824-1. Na potrzeby czytelności i łatwego odwoływania się poniżej podano przypisanie wartości. W przypadku rozbieżności między tą uwagą a normą obowiązują przepisy normy ISO/IEC 8824-1.
! "#$%&' () * +, -. /0123456789:;< = >?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ [\] ^ _
' abcdefghijklmnopqrstuvwxyz{ | } ~
| W innych łańcuchach znaków (Address, Name, VehicleRegistrationNumber) używa się dodatkowo znaków zdefiniowanych kodami od 161 do 255 następujących 8-bitowych standardowych zestawów znaków, określonych numerem Code Page: Standardowy zestaw znaków | Code Page (dziesiętny) |
| ISO/IEC 8859-1 Latin-1 - dla Europy Zachodniej | 1 |
| ISO/IEC 8859-2 Latin-2 - dla Europy Środkowej i Wschodniej | 2 |
| ISO/IEC 8859-3 Latin-3 - dla Europy Południowej | 3 |
| ISO/IEC 8859-5 Latin - dla cyrylicy | 5 |
| ISO/IEC 8859-7 Latin - dla alfabetu greckiego | 7 |
| ISO/IEC 8859-9 Latin-5 - dla alfabetu tureckiego | 9 |
| ISO/IEC 8859-13 Latin-7 - dla krajów bałtyckich | 13 |
| ISO/IEC 8859-15 Latin-9 | 15 |
| ISO/IEC 8859-16 Latin-10 - dla Europy Południowo-Wschodniej | 16 |
| KOI8-R Latin - dla cyrylicy | 80 |
| KOI8-U Latin - dla cyrylicy | 85 |
5. KODOWANIE
Przy kodowaniu zgodnie z zasadami ASN.1, wszystkie zdefiniowane typy danych koduje się zgodnie z wariantem unormowanym w ISO/IEC 8825-2.
6. IDENTYFIKATORY OBIEKTU I IDENTYFIKATORY APLIKACJI
6.1. Identyfikatory obiektu
Identyfikatory obiektu (OID) wymienione w niniejszym rozdziale mają zastosowanie wyłącznie do generacji 2. Takie OID wyszczególniono w TR-03110-3 i powtórzono dla kompletności wywodu. Takie OID zawarto w poddrzewie bsi-de:
bsi-de OBJECT IDENTIFIER::= {
itu-t(O) identified-organization(4) etsi(0)
reserved(127) etsi-identified-organization(0) 7
}
Identyfikatory protokołu uwierzytelnienia VU
id-TA OBJECT IDENTIFIER::= {bsi-de protocols (2) smartcard(2) 2}
id-TA-ECDSA OBJECT IDENTIFIER::= {id-TA 2}
id-TA-ECDSA-SHA-256 OBJECT IDENTIFIER::= {id-TA-ECDSA 3}
id-TA-ECDSA-SHA-384 OBJECT IDENTIFIER::= {id-TA-ECDSA 4}
id-TA-ECDSA-SHA-512 OBJECT IDENTIFIER::= {id-TA-ECDSA 5}
Przykład: Załóżmy, że należy dokonać uwierzytelnienia VU za pomocą SHA-384, wtedy identyfikatorem obiektu, który należy użyć jest (w składni ASN.1) bsi-de protocols (2) smartcard(2) 2 2 4. Wartość tego identyfikatora obiektu w zapisie kropkowym wynosi 0.4.0.127.0.7.2.2.2.2.4.
| Zapis kropkowy | Zapis bajtowy | |
| id-TA-ECDSA-SHA-2 5 6 | 0.4.0.127.0.7.2.2.2.2.3 | '04 00 7F 00 07 02 02 02 02 03' |
| id-TA-ECDSA-SHA-38 4 | 0.4.0.127.0.7.2.2.2.2.4 | '04 00 7F 00 07 02 02 02 02 04' |
| id-TA-ECDSA-SHA-512 | 0.4.0.127.0.7.2.2.2.2.5 | '04 00 7F 00 07 02 02 02 02 05' |
Identyfikatory protokołu uwierzytelnienia z chipem
id-CA OBJECT IDENTIFIER::= {bsi-de protocols (2) smartcard(2) 3}
id-CA-ECDH OBJECT IDENTIFIER::= {id-CA 2}
id-CA-ECDH-AES-CBC-CMAC-128 OBJECT IDENTIFIER::= {id-CA-ECDH 2}
id-CA-ECDH-AES-CBC-CMAC-192 OBJECT IDENTIFIER::= {id-CA-ECDH 3}
id-CA-ECDH-AES-CBC-CMAC-25 6 OBJECT IDENTIFIER::= {id-CA-ECDH 4}
Przykład: Przypuśćmy, że uwierzytelnienie chipu ma zostać dokonane za pomocą algorytmu ECDH, co daje długość klucza sesji AES 128 bitów. Ten klucz sesji zostanie następnie wykorzystany w trybie pracy CBC w celu zapewnienia poufności danych i z algorytmem CMAC w celu zapewnienia autentyczności danych. Zatem identyfikatorem obiektu, który należy użyć jest (w składni ASN.1) bsi-de protocols (2) smartcard (2) 3 2 2. Wartość tego identyfikatora obiektu w zapisie kropkowym wynosi 0.4.0.127.0.7.2.2.3.2.2.
| Zapis kropkowy | Zapis bajtowy | |
| id-CA-ECDH-AES-CBC-CMAC-12 8 | 0.4.0.127.0.7.2.2.3.2.2 | '04 00 7F 00 07 02 02 03 02 02' |
| id-CA-ECDH-AES-CBC-CMAC-192 | 0.4.0.127.0.7.2.2.3.2.3 | '04 00 7F 00 07 02 02 03 02 03' |
| id-CA-ECDH-AES-CBC-CMAC-25 6 | 0.4.0.127.0.7.2.2.3.2.4 | '04 00 7F 00 07 02 02 03 02 04' |
6.2. Identyfikatory aplikacji
Generacja 2:
Identyfikator aplikacji (AID) dla urządzenia zewnętrznego GNSS (generacja 2) jest określony za pomocą "FF 44 54 45 47 4D". Jest to zastrzeżony AID zgodny z normą ISO/IEC 7816-4.
Uwaga: 5 ostatnich bajtów koduje DTEGM dla urządzenia zewnętrznego GNSS tachografu inteligentnego.
Identyfikator aplikacji dla aplikacji kart do tachografów generacji 2 jest określony za pomocą "FF 53 4D 52 44 54". Jest to zastrzeżony AID zgodny z normą ISO/IEC 7816-4.
Dodatek 2 25
SPECYFIKACJA KART DO TACHOGRAFÓW
SPECYFIKACJA KART DO TACHOGRAFÓW
1. WPROWADZENIE ........................................................................................................
1.1. Skróty .............................................................................................................................
1.2. Odniesienia ......................................................................................................................
2. CHARAKTERYSTYKI ELEKTRYCZNE I FIZYCZNE ...............................................
2.1. Napięcie zasilające i pobór prądu .....................................................................................
2.2. Napięcie programowania Vpp ..........................................................................................
2.3. Generowanie i częstotliwość zegara ..................................................................................
2.4. Styk we/wy ......................................................................................................................
2.5. Stany karty ......................................................................................................................
3. SPRZĘT I KOMUNIKACJA .........................................................................................
3.1. Wprowadzenie .................................................................................................................
3.2. Protokół komunikacyjny ...................................................................................................
3.2.1 Protokoły .........................................................................................................................
3.2.2 ATR ................................................................................................................................
3.2.3 PTS .................................................................................................................................
3.3. Zasady dostępu ................................................................................................................
3.4. Przegląd poleceń i kodów błędów ....................................................................................
3.5. Opisy poleceń ..................................................................................................................
3.5.1 SELECT ..........................................................................................................................
3.5.2 READ BINARY ..............................................................................................................
3.5.3 UPDATE BINARY .........................................................................................................
3.5.4 GET CHALLENGE ........................................................................................................
3.5.5 VERIFY ..........................................................................................................................
3.5.6 GET RESPONSE ............................................................................................................
3.5.7 PSO: VERIFY CERTIFICATE .......................................................................................
3.5.8 INTERNAL AUTHENTICATE ......................................................................................
3.5.9 EXTERNAL AUTHENTICATE .....................................................................................
3.5.10 GENERAL AUTHENTICATE ........................................................................................
3.5.11 MANAGE SECURITY ENVIRONMENT .....................................................................
3.5.12 PSO: HASH ....................................................................................................................
3.5.13 PERFORM HASH OF FILE ...........................................................................................
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE .....................................................................
3.5.15 PSO: VERIFY DIGITAL SIGNATURE ..........................................................................
3.5.16 PROCESS DSRC MESSAGE ........................................................................................
4. STRUKTURA KART DO TACHOGRAFÓW ...............................................................
4.1. Plik główny MF ...............................................................................................................
4.2. Aplikacje karty kierowcy .................................................................................................
4.2.1 Aplikacja karty kierowcy 1. generacji ...............................................................................
4.2.2 Aplikacja karty kierowcy 2. generacji ...............................................................................
4.3. Aplikacje karty warsztatowej ...........................................................................................
4.3.1 Aplikacja karty warsztatowej 1. generacji .........................................................................
4.3.2 Aplikacja karty warsztatowej 2. generacji .........................................................................
4.4. Aplikacje karty kontrolnej ................................................................................................
4.4.1 Aplikacja karty kontrolnej 1. generacji ..............................................................................
4.4.2 Aplikacja karty kontrolnej 2. generacji ..............................................................................
4.5. Aplikacje karty firmowej ..................................................................................................
4.5.1 Aplikacja karty firmowej 1. generacji ................................................................................
4.5.2 Aplikacja karty firmowej 2. generacji ................................................................................
1. WPROWADZENIE
1.1. Skróty
Do celów niniejszego dodatku stosuje się poniższe skróty.
AC [Access conditions] warunki dostępu
AES [Advanced Encryption Standard] zaawansowany standard szyfrowania
AID [Application Identifier] identyfikator aplikacji
ALW [Always] zawsze
APDU [Application Protocol Data Unit] jednostka danych protokołu aplikacji (struktura polecenia)
ATR [Answer To Reset] reakcja na sprowadzenie do stanu wyjściowego
AUT [Authenticated] uwierzytelniony
C6, C7 styki 6 i 7 karty opisane w normie ISO/IEC 7816-2
cc [clock cycles] cykle zegarowe
CHV [Card holder Verification Information] informacje weryfikacyjne posiadacza karty
CLA bajt klasy w poleceniu APDU
DSRC [Dedicated Short Range Communication] wydzielona łączność krótkiego zasięgu
DF [Dedicated File] plik dedykowany. DF może zawierać inne pliki (EF lub DF)
ECC [Elliptic Curve Cryptography] kryptografia krzywych eliptycznych
EF [Elementary File] plik elementarny
etu [elementary time unit] elementarna jednostka czasu
G1 [Generation 1] 1. generacja
G2 [Generation 2] 2. generacja
IC [Integrated Circuit] układ scalony
ICC [Integrated Circuit Card] karta z układem scalonym
ID [Identifier] identyfikator
IFD [Interface Device] urządzenie interfejsu
IFS [Information Field Size] wielkość pola informacyjnego
IFSC [Information Field Size for the card] wielkość pola informacyjnego dla karty
IFSD [Information Field Size Device] wielkość pola informacyjnego urządzenia (dla terminala)
INS bajt instrukcji w poleceniu APDU
Lc długość danych wejściowych dla polecenia APDU
Le długość danych oczekiwanych (dane wyjściowe dla polecenia)
MF [Master File] plik główny (root DF)
NAD [Node Address] adres węzła używany w protokole T=1
NEV [Never] nigdy
P1-P2 bajty parametryczne
PIN [Personal Identification Number] osobisty numer identyfikacyjny
PRO SM [Protected with secure messaging] chroniony z bezpieczną wymianą komunikatów
PTS [Protocol Transmission Selection] wybór protokołu komunikacyjnego
RFU [Reserved for Future Use] zastrzeżone do wykorzystania w przyszłości
RST [Reset] sprowadzenie do stanu wyjściowego (karty)
SFID [Short EF Identifier] krótki identyfikator EF
SM [Secure Messaging] bezpieczna wymiana komunikatów
SW1-SW2 bajty stanu
TS początkowy znak ATR
VPP napięcie programowania
VU [Vehicle Unit] przyrząd rejestrujący
XXh wartość XX w zapisie heksadecymalnym
'XXh' wartość XX w zapisie heksadecymalnym
|| symbol konkatenacji 03||04=0304
CHA upoważnienie posiadacza certyfikatu
DO obiekt danych
1.2. Odniesienia
W niniejszym dodatku stosuje się następujące odniesienia:
ISO/IEC 7816-2 Karty identyfikacyjne - Karty z układami scalonymi - część 2: Wymiary i rozmieszczenie styków. ISO/IEC 7816-2:2007.
ISO/IEC 7816-3 Karty identyfikacyjne - Karty z układami scalonymi - część 3: Złącze elektryczne i protokoły komunikacyjne. ISO/IEC 7816-3:2006.
ISO/IEC 7816-4 Karty identyfikacyjne - Karty z układami scalonymi - część 4: Organizacja, zabezpieczenia i polecenia wymiany. ISO/IEC 7816-4:2013 + Cor 1: 2014.
ISO/IEC 7816-6 Karty identyfikacyjne - Karty z układami scalonymi - część 6: Międzybranżowe elementy danych do wymiany. ISO/IEC 7816-6:2004 + Cor 1: 2006.
ISO/IEC 7816-8 Karty identyfikacyjne - Karty z układami scalonymi - część 8: Polecenia operacji zabezpieczających. ISO/IEC 7816-8:2004.
ISO/IEC 9797-2 Technologia informatyczna - Techniki zabezpieczeń - Kody uwierzytelniania wiadomości (MAC) - część 2: Mechanizmy wykorzystujące funkcję haszującą. ISO/IEC 9797-2:2011
2. CHARAKTERYSTYKI ELEKTRYCZNE I FIZYCZNE
TCS_01 Wszystkie sygnały elektryczne muszą być zgodne z normą ISO/IEC 7816-3, chyba że określono inaczej.
TCS_02 Rozmieszczenie i wymiary styków kart muszą być zgodne z normą ISO/IEC 7816-2.
2.1. Napięcie zasilające i pobór prądu
TCS_03 Karta pracuje zgodnie ze specyfikacją przy poborze w granicach określonych w normie ISO/IEC 7816-3.
TCS_04 Karta pracuje z Vcc = 3V (± 0,3V) bądź z Vcc = 5V (± 0,5V).
Wybór napięcia odbywa się zgodnie z normą ISO/IEC 7816-3.
2.2. Napięcie programowania Vpp
TCS_05 Karta nie wymaga napięcia programowania na pinie C6. Oczekuje się, że pin C6 nie jest przyłączony w IFD. Styk C6 może być przyłączony do Vcc na karcie, ale nie może być przyłączony do masy. W żadnym przypadku napięcie to nie może być interpretowane.
2.3. Generowanie i częstotliwość zegara
TCS_06 Karta pracuje w zakresie częstotliwości 1-5 MHz i może obsługiwać wyższe częstotliwości. W czasie jednej sesji karty częstotliwość zegara może zmieniać się w granicach ± 2 %. Częstotliwość zegara generowana jest przez przyrząd rejestrujący, a nie przez kartę. Cykl pracy może zmieniać się w granicach 40-60 %.
TCS_07 W warunkach określonych na karcie w pliku EF ICC zewnętrzny zegar może zostać zatrzymany. Pierwszy bajt treści pliku EF ICC koduje warunki trybu pracy Clockstop:
| Niski | Wysoki | ||
| Bit 3 | Bit 2 | Bit 1 | |
| 0 | 0 | 1 | Clockstop dozwolony, brak preferowanego poziomu |
| 0 | 1 | 1 | Clockstop dozwolony, preferowany poziom wysoki |
| 1 | 0 | 1 | Clockstop dozwolony, preferowany poziom niski |
| 0 | 0 | 0 | Clockstop niedozwolony |
| 0 | 1 | 0 | Clockstop dozwolony tylko przy wysokim poziomie |
| 1 | 0 | 0 | Clockstop dozwolony tylko przy niskim poziomie |
Bitów od 4 do 8 nie używa się.
2.4. Styk we/wy
TCS_08 Styk we/wy C7 służy do odbierania i wysyłania danych do IFD. W czasie pracy tylko karta albo tylko IFD jest w trybie nadawania. Gdyby jednak obie jednostki jednocześnie znalazły się w trybie nadawania, nie może to spowodować uszkodzenia karty. Karta wchodzi do trybu odbioru, chyba że nadaje dane.
2.5. Stany karty
TCS_09 Gdy podawane jest napięcie zasilające, karta pracuje w dwóch stanach:
stan operacyjny, w którym karta wykonuje polecenia lub jest połączona z przyrządem rejestrującym;
stan jałowy we wszystkich pozostałych sytuacjach (w tym stanie karta zachowuje wszystkie dane).
3. SPRZĘT I KOMUNIKACJA
3.1. Wprowadzenie
W punkcie tym opisano minimalną funkcjonalność wymaganą od kart do tachografów i VU w celu zagwarantowania prawidłowego funkcjonowania i interoperacyjności.
Karty do tachografów muszą być zgodne, w największym możliwym stopniu, z obowiązującymi normami ISO/IEC (w szczególności z normą ISO/IEC 7816). Niemniej jednak szczegółowo opisano polecenia i protokoły w celu określenia niektórych ograniczonych zastosowań lub różnic, o ile takie występują. Opisane polecenia są w pełni zgodne z przywołanymi normami, jeżeli nie wskazano inaczej.
3.2. Protokół komunikacyjny
TCS_10 Protokół komunikacyjny musi być zgodny z normą ISO/IEC 7816-3 dla T = 0 oraz T = 1. W szczególności VU musi rozpoznawać wysyłane przez kartę przedłużenia czasu oczekiwania.
3.2.1 Protokoły
TCS_11 Karta obsługuje zarówno protokół T = 0, jak i protokół T=1. Karta może ponadto obsługiwać dodatkowe protokoły zorientowane kontaktowo.
TCS_12 T = 0 jest protokołem domyślnym, dlatego też polecenie PTS jest niezbędne do zmiany protokołu na T = 1.
TCS_13 Urządzenia wykorzystują konwencję bezpośrednią w obu protokołach: w związku z tym konwencja bezpośrednia jest obowiązkowa dla karty.
TCS_14 Bajt karty informacyjnej wielkości pola przedstawiony jest na ATR pod oznaczeniem TA3. Wartość ta jest nie mniejsza niż 'F0h' (= 240 bajtów).
Do protokołów stosuje się następujące ograniczenia:
TCS_15 T=0
- Urządzenie interfejsu wspiera odpowiedź na we/wy po wzroście krawędzi narastającego sygnału na RST z 400 cc.
- Urządzenie interfejsu potrafi odczytać znaki rozdzielone 12 etu.
- Urządzenie interfejsu odczytuje błędny znak i jego powtórzenie, jeżeli rozdzielone 13 etu. W przypadku wykrycia błędnego znaku na we/wy może pojawić się sygnał błędu między 1 etu a 2 etu. Urządzenie obsługuje opóźnienie 1 etu.
- Urządzenie interfejsu akceptuje 33-bajtowe ATR (TS + 32)
- Jeżeli TC1 znajduje się w ATR, to dla znaków wysyłanych przez urządzenie interfejsu jest dodatkowy czas ochronny (Extra Guard Time), chociaż znaki wysyłane przez kartę mogą być jeszcze przedzielone odstępami 12 etu. Odnosi się to także do znaku ACK wysyłanego przez kartę po wysłaniu znaku P3 przez urządzenie interfejsu.
- Urządzenie interfejsu bierze pod uwagę znak NUL wysyłany przez kartę.
- Urządzenie interfejsu akceptuje tryb uzupełniający dla ACK.
- Polecenia odbierz-odpowiedź (get-response) nie można używać w trybie łańcuchowym do otrzymywania danych, których długość może być większa niż 255 bajtów.
TCS_16 T=1
- Bajt NAD: nieużywany (NAD ustawia się na '00').
- S-block ABORT: nieużywany.
- Błąd stanu S-block VPP: nieużywany.
- (uchyla).
- IFD bezpośrednio po ATR podaje wielkość pola informacyjnego dla urządzenia (IFSD): IFD wysyła żądanie S-Block IFS po ATR, a karta odpowiada S-Block IFS. Zalecaną wartością dla IFSD są 254 bajty.
- Karta nie pyta o skorygowane IFS.
3.2.2 ATR
TCS_17 Urządzenie sprawdza bajty ATR, zgodnie z normą ISO/IEC 7816-3. Nie wykonuje się weryfikacji znaków historycznych ATR.
Przykład podstawowego Biprotocol ATR zgodnego z normą ISO/IEC 7816-3
| Znak | Wartość | Uwagi |
| TS | '3Bh' | wskazuje konwencję bezpośrednią |
| T0 | '85h' | TD1 obecny; jest 5 bajtów historycznych |
| TD1 | '80h' | TD2 obecny; będzie użyty T=0 |
| TD2 | '11h' | TA3 obecny; będzie użyty T=1 |
| TA3 | 'XXh' (min. 'F0h') | wielkość pola informacyjnego dla karty (IFSC) |
| TH1-TH5 | 'XXh' | znaki historyczne |
| TCK | 'XXh' | znak kontrolny (exclusive OR) |
TCS_18 Po ATR wybierany jest domyślnie plik główny (MF) i staje się katalogiem bieżącym.
3.2.3 PTS
TCS_19 Domyślnym protokołem jest T=0. Aby wybrać protokół T=1, urządzenie musi wysłać do karty PTS (znane też jako PPS).
TCS_20 Ponieważ oba protokoły T=0 i T=1 są wymagane dla karty, podstawowy PTS do przełączania między protokołami jest obowiązkowy dla karty.
PTS można używać, jak wskazano w normie ISO/IEC 7816-3, do przełączania na szybkości transmisji większe niż standardowa, proponowane przez kartę w ATR, jeżeli dotyczy (bajt TA(1)).
Większe szybkości transmisji są opcjonalne dla karty.
TCS_21 Jeżeli karta nie obsługuje innej szybkości transmisji niż standardowa (lub jeżeli nie obsługuje wybranej szybkości transmisji), karta musi prawidłowo odpowiadać na PTS, zgodnie z normą ISO/ IEC 7816-3, opuszczając bajt PPS1.
Poniżej pokazano przykłady podstawowego PTS do wyboru protokołu:
| Znak | Wartość | Uwagi |
| PPSS | 'FFh' | znak inicjujący |
| PPS0 | '00h' lub '01h' | nie ma PPS1 do PPS3; '00h', aby wybrać T0, '01h', aby wybrać T1 |
| PK | 'XXh' | znak kontrolny: 'XXh' = 'FFh', jeżeli PPS0 = '00h', 'XXh' = 'FEh', jeżeli PPS0 = '01h'. |
3.3. Zasady dostępu
TCS_22 Zasada dostępu określa odpowiednie warunki zabezpieczenia dla danego trybu dostępu, tj. polecenia. Jeżeli przedmiotowe warunki zabezpieczenia są spełnione, odpowiednie polecenie jest przetwarzane.
TCS_23 Następujące warunki zabezpieczenia są stosowane na potrzeby karty do tachografu:
| Skrót | Znaczenie |
| ALW | Operacja jest zawsze możliwa i może być wykonywana bez ograniczeń. Polecenie i odpowiedź APDU są wysyłane w postaci zwykłego tekstu, tzn. bez bezpiecznej wymiany komunikatów. |
| NEV | Operacja nie jest nigdy możliwa. |
| PLAIN-C | Polecenie APDU jest wysyłane w postaci zwykłego tekstu, tzn. bez bezpiecznej wymiany komunikatów. |
| PWD | Działanie może zostać zrealizowane, wyłącznie jeżeli PIN karty warsztatowej został pomyślnie zweryfikowany, tzn. jeżeli stan zabezpieczenia wewnętrznego karty ma status "PIN_Verified". Polecenie musi być przesłane bez bezpiecznej wymiany komunikatów. |
| EXT-AUT-G1 | Działanie może zostać zrealizowane, wyłącznie jeżeli polecenie External Authenticate dla uwierzytelnienia 1. generacji (zob. także dodatek 11 część A) zostało pomyślnie wykonane. |
| SM-MAC-G1 | Polecenie i odpowiedź APDU muszą być stosowane z bezpieczną wymianą komunikatów 1. generacji w trybie tylko uwierzytelnienia (zob. dodatek 11 część A). |
| SM-C-MAC-G1 | Polecenie APDU musi być stosowane z bezpieczną wymianą komunikatów 1. generacji w trybie tylko uwierzytelnienia (zob. dodatek 11 część A). |
| SM-R-ENC-G1 | Odpowiedź APDU musi być stosowana z bezpieczną wymianą komunikatów 1. generacji w trybie szyfrowania (zob. dodatek 11 część A), tzn. bez zwracania kodu uwierzytelnienia wiadomości. |
| SM-R-ENC-MAC-G1 | Odpowiedź APDU musi być stosowana z bezpieczną wymianą komunikatów 1. generacji w trybie szyfrowania i uwierzytelnienia (zob. dodatek 11 część A). |
| SM-MAC-G2 | Polecenie i odpowiedź APDU muszą być stosowane z bezpieczną wymianą komunikatów 2. generacji w trybie tylko uwierzytelnienia (zob. dodatek 11 część A). |
| SM-C-MAC-G2 | Polecenie APDU musi być stosowane z bezpieczną wymianą komunikatów 2. generacji w trybie tylko uwierzytelnienia (zob. dodatek 11 część A). |
| SM-R-ENC-MAC-G2 | Odpowiedź APDU musi być stosowana z bezpieczną wymianą komunikatów 2. generacji w trybie szyfrowania i uwierzytelnienia (zob. dodatek 11 część A). |
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.
TCS_25 W przypadku aplikacji DF Tachograph G1 zastosowanie mają następujące zasady dostępu:
| Polecenie | Karta kierowcy | Karta warsztatowa | Karta kontrolna | Karta firmowa |
| External Authenticate | ||||
| - dla uwierzytelnienia 1. generacji | ALW | ALW | ALW | ALW |
| - dla uwierzytelnienia 2. generacji | ALW | PWD | ALW | ALW |
| Internal Authenticate | ALW | PWD | ALW | ALW |
| General Authenticate | ALW | ALW | ALW | ALW |
| Get Challenge | ALW | ALW | ALW | ALW |
| MSE:SET AT | ALW | ALW | ALW | ALW |
| MSE:SET DST | ALW | ALW | ALW | ALW |
| Process DSRC Message | nie dotyczy | nie dotyczy | nie dotyczy | nie dotyczy |
| PSO: Compute Digital Signature | ALW OR SM-MAC-G2 | ALW OR SM-MAC-G2 | nie dotyczy | nie dotyczy |
| PSO: Hash | nie dotyczy | nie dotyczy | ALW | nie dotyczy |
| PERFORM HASH of FILE | ALW OR SM-MAC-G2 | ALW OR SM-MAC-G2 | nie dotyczy | nie dotyczy |
| PSO: Verify Certificate | ALW | ALW | ALW | ALW |
| PSO: Verify Digital Signature | nie dotyczy | nie dotyczy | ALW | nie dotyczy |
| Verify | nie dotyczy | ALW | nie dotyczy | nie dotyczy |
TCS_26 W przypadku aplikacji DF Tachograph_G2 zastosowanie mają następujące zasady dostępu:
| Polecenie | Karta kierowcy | Karta warsztatowa | Karta kontrolna | Karta firmowa |
| External Authenticate | ||||
| - dla uwierzytelnienia 1. generacji | nie dotyczy | nie dotyczy | nie dotyczy | nie dotyczy |
| - dla uwierzytelnienia 2. generacji | ALW | PWD | ALW | ALW |
| Internal Authenticate | nie dotyczy | nie dotyczy | nie dotyczy | nie dotyczy |
| General Authenticate | ALW | ALW | ALW | ALW |
| Get Challenge | ALW | ALW | ALW | ALW |
| MSE:SET AT | ALW | ALW | ALW | ALW |
| MSE:SET DST | ALW | ALW | ALW | ALW |
| Process DSRC Message | nie dotyczy | ALW | ALW | nie dotyczy |
| PSO: Compute Digital Signature | ALW OR SM-MAC-G2 | ALW OR SM-MAC-G2 | nie dotyczy | nie dotyczy |
| PSO: Hash | nie dotyczy | nie dotyczy | ALW | nie dotyczy |
| PERFORM HASH of FILE | ALW OR SM-MAC-G2 | ALW OR SM-MAC-G2 | nie dotyczy | nie dotyczy |
| PSO: Verify Certificate | ALW | ALW | ALW | ALW |
| PSO: Verify Digital Signature | nie dotyczy | nie dotyczy | ALW | nie dotyczy |
| Verify | nie dotyczy | ALW | nie dotyczy | nie dotyczy |
TCS_27 W przypadku MF zastosowanie mają następujące zasady dostępu:
| Polecenie | Karta kierowcy | Karta warsztatowa | Karta kontrolna | Karta firmowa |
| External Authenticate | ||||
| - dla uwierzytelnienia 1. generacji | nie dotyczy | nie dotyczy | nie dotyczy | nie dotyczy |
| - dla uwierzytelnienia 2. generacji | ALW | PWD | ALW | ALW |
| Internal Authenticate | nie dotyczy | nie dotyczy | nie dotyczy | nie dotyczy |
| General Authenticate | ALW | ALW | ALW | ALW |
| Get Challenge | ALW | ALW | ALW | ALW |
| MSE:SET AT | ALW | ALW | ALW | ALW |
| MSE:SET DST | ALW | ALW | ALW | ALW |
| Process DSRC Message | nie dotyczy | nie dotyczy | nie dotyczy | nie dotyczy |
| PSO: Compute Digital Signature | nie dotyczy | nie dotyczy | nie dotyczy | nie dotyczy |
| PSO: Hash | nie dotyczy | nie dotyczy | nie dotyczy | nie dotyczy |
| PERFORM HASH of FILE | nie dotyczy | nie dotyczy | nie dotyczy | nie dotyczy |
| PSO: Verify Certificate | ALW | ALW | ALW | ALW |
| PSO: Verify Digital Signature | nie dotyczy | nie dotyczy | nie dotyczy | nie dotyczy |
| Verify | nie dotyczy | ALW | nie dotyczy | nie dotyczy |
TCS_28 Karta do tachografu może, ale nie musi przyjmować poleceń z wyższego poziomu zabezpieczenia niż poziom określony w warunkach zabezpieczenia. Tzn. jeżeli warunkiem zabezpieczenia jest ALW (lub PLAIN-C), karta może przyjąć polecenie z bezpieczną wymianą komunikatów (w trybie szyfrowania lub uwierzytelnienia). Jeżeli warunek zabezpieczenia wymaga bezpiecznej wymiany komunikatów w trybie uwierzytelnienia, karta do tachografu może przyjąć polecenie z bezpieczną wymianą komunikatów tej samej generacji w trybie uwierzytelnienia i szyfrowania.
Uwaga: Opisy poleceń dostarczają więcej informacji na temat obsługi poleceń dla poszczególnych typów kart do tachografów oraz poszczególnych DF.
3.4. Przegląd poleceń i kodów błędów
Polecenia i organizacja pliku wynikają z normy ISO/IEC 7816-4 i spełniają jej wymagania.
W tej sekcji opisano poniższe pary polecenie-odpowiedź dla APDU. Warianty poleceń, które są obsługiwane przez aplikacje 1. i 2. generacji, zostały określone w odpowiednich opisach poleceń.
| Polecenie | INS |
| SELECT | 'A4h' |
| READ BINARY | 'B0h', 'B1h' |
| UPDATE BINARY | 'D6h', 'D7h' |
| GET CHALLENGE | '84h' |
| VERIFY | '20h' |
| GET RESPONSE | 'C0h' |
| PERFORM SECURITY OPERATION | '2Ah' |
| - VERIFY CERTIFICATE | |
| - COMPUTE DIGITAL SIGNATURE | |
| - VERIFY DIGITAL SIGNATURE | |
| - HASH | |
| - PERFORM HASH OF FILE | |
| - PROCESS DSRC MESSAGE | |
| INTERNAL AUTHENTICATE | '88h' |
| EXTERNAL AUTHENTICATE | '82h' |
| MANAGE SECURITY ENVIRONMENT | '22h' |
| - SET DIGITAL SIGNATURE TEMPLATE | |
| - SET AUTHENTICATION TEMPLATE | |
| GENERAL AUTHENTICATE | '86h' |
TCS_29 Słowa stanu SW1 i SW2 są zwracane w komunikacie odpowiedzi i oznaczają stan przetwarzania polecenia.
| SW1 | SW2 | Znaczenie |
| 90 | 00 | Normalne przetwarzanie. |
| 61 | XX | Normalne przetwarzanie. XX = liczba dostępnych bajtów odpowiedzi. |
| 62 | 81 | Przetwarzanie ostrzeżenia. Część zwracanych danych może być uszkodzona |
| 63 | 00 | Nieudane uwierzytelnienie (ostrzeżenie) |
| 63 | CX | Nieprawidłowe CHV (PIN). "X" oznacza licznik pozostałych prób. |
| 64 | 00 | Błąd wykonania - Stan pamięci nieulotnej bez zmian. Błąd integralności. |
| 65 | 00 | Błąd wykonania - Stan pamięci nieulotnej zmieniony |
| 65 | 81 | Błąd wykonania - Stan pamięci nieulotnej zmieniony - Uszkodzona pamięć |
| 66 | 88 | 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) |
| 67 | 00 | Nieprawidłowa długość (nieprawidłowe Lc lub Le) |
| 68 | 83 | Oczekiwane ostatnie polecenie łańcucha |
| 69 | 00 | Niedozwolone polecenie (brak dostępnej odpowiedzi w T=0) |
| 69 | 82 | Niespełniony stan zabezpieczenia. |
| 69 | 83 | Metoda uwierzytelnienia zablokowana. |
| 69 | 85 | Warunki użycia niespełnione. |
| 69 | 86 | Polecenie niedozwolone (brak bieżącego EF). |
| 69 | 87 | Brak oczekiwanych obiektów danych w bezpiecznej wymianie komunikatów |
| 69 | 88 | Nieprawidłowe obiekty danych w bezpiecznej wymianie komunikatów |
| 6A | 80 | Nieprawidłowe parametry w polu danych |
| 6A | 82 | Nie znaleziono pliku. |
| 6A | 86 | Nieprawidłowe parametry P1-P2. |
| 6A | 88 | Nie znaleziono powołanych danych. |
| 6B | 00 | Nieprawidłowe parametry (przesunięcie poza EF). |
| 6C | XX | Nieprawidłowa długość, SW2 wskazuje dokładną długość. Pole danych nie jest zwracane. |
| 6D | 00 | Kod instrukcji nieobsługiwany lub nieważny. |
| 6E | 00 | Klasa nieobsługiwana. |
| 6F | 00 | - Inne błędy kontroli |
Dodatkowe słowa stanu zdefiniowane w normie ISO/IEC 7816-4 mogą być zwracane, jeżeli ich zachowanie nie jest wyraźnie wymienione w niniejszym dodatku.
Przykładowo następujące słowa stanu mogą być zwracane opcjonalnie:
6881: Kanał logiczny nieobsługiwany
6882: Bezpieczna wymiana komunikatów nieobsługiwana
TCS_30 W przypadku gdy w jednym poleceniu APDU spełniony jest więcej niż jeden warunek wystąpienia błędu, karta może odesłać dowolny z odpowiednich słów stanu.
3.5. Opisy poleceń
W tym rozdziale opisano obowiązkowe polecenia dla kart do tachografów.
Dodatkowe szczegółowe informacje dotyczące stosowanych czynności kryptograficznych zamieszczono w dodatku 11 Wspólne mechanizmy zabezpieczenia dla tachografów 1. generacji i 2. generacji.
Wszystkie polecenia opisane są niezależnie od używanego protokołu (T=0 lub T=1). Bajty CLA, INS, P1, P2, Lc i Le w APDU są zawsze wskazywane. Jeżeli Lc lub Le nie jest potrzebny dla opisywanego polecenia, związane z nimi długość, wartość i opis są puste.
TCS_31 Jeżeli żądane są oba bajty długości (Lc i Le), opisywane polecenie musi być podzielone na dwie części, jeśli IFD używa protokołu T=0: IFD wysyła to polecenie z P3=Lc + dane, a następnie wysyła polecenie GET RESPONSE (zob. pkt 3.5.6) z P3=Le.
TCS_32 Jeżeli żądane są oba bajty długości i Le=0 (bezpieczna wymiana komunikatów):
- gdy używany jest protokół T=1, karta odpowiada na Le=0, wysyłając wszystkie dostępne dane wyjściowe;
- gdy używany jest protokół T=0, IFD wysyła pierwsze polecenie z P3=Lc + dane, karta odpowiada (na to niejawne Le=0) bajtami stanu '61La', gdzie La jest liczbą dostępnych bajtów odpowiedzi. Następnie IFD generuje polecenie GET RESPONSE z P3=La w celu odczytania danych.
TCS_33 Karta do tachografu może opcjonalnie obsługiwać pola o rozszerzonej długości zgodnie z normą ISO/IEC 7816-4. Karta do tachografu, która obsługuje pola o rozszerzonej długości, musi:
- wskazywać możliwość obsługi pól o rozszerzonej długości w ATR;
- zapewniać obsługiwane pojemności bufora za pomocą informacji o rozszerzonej długości w EF ATR/INFO, zob. TCS_146;
- wskazywać, czy obsługuje pola o rozszerzonej długości dla T = 1 lub T = 0 w EF Extended Length, zob. TCS_147.
- obsługiwać pola o rozszerzonej długości dla aplikacji tachograficznej 1. i 2. generacji.
Uwagi:
Wszystkie polecenia zostały określone dla pól o krótkiej długości. Stosowanie APDU o rozszerzonej długości wynika z ISO/IEC 7816-4.
Polecenia są zasadniczo określone dla trybu zwykłego, tj. bez bezpiecznej wymiany komunikatów, ponieważ warstwa bezpiecznej wymiany komunikatów została określona w dodatku 11. Z zasad dostępu dla polecenia wynika, czy polecenie wspiera bezpieczną wymianę komunikatów, a także - czy polecenie wspiera bezpieczną wymianę komunikatów 1. generacji lub 2. generacji. Niektóre warianty poleceń opisano z bezpieczną wymianą komunikatów, aby zilustrować stosowanie bezpiecznej wymiany komunikatów.
TCS_34 VU wykonuje pełny protokół 2. generacji wzajemnego uwierzytelnienia VU - karta dla sesji, łącznie z weryfikacją certyfikatu (jeżeli jest to wymagane), w DF Tachograph, w DF Tachograph_G2 lub w MF.
3.5.1 SELECT
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego zastosowanie jest ograniczone w porównaniu z poleceniem zdefiniowanym w tej normie.
Polecenia SELECT używa się:
- do wybierania aplikacji DF (musi być używany wybór przez nazwę);
- do wybierania pliku elementarnego odpowiadającego przekazanemu ID pliku.
3.5.1.1 Wybór przez nazwę (AID)
Polecenie to pozwala wybrać aplikację DF na karcie.
TCS_35 Polecenie to można wykonywać z dowolnego miejsca w strukturze pliku (po ATR lub w dowolnym momencie).
TCS_36 Wybór aplikacji powoduje przywrócenie bieżącego stanu środowiska zabezpieczeń do stanu wyjściowego. Po wybraniu aplikacji żaden bieżący klucz publiczny nie jest już wybierany. Warunek dostępu EXT-AUT-G1 także zostaje utracony. Jeżeli polecenie zostało wykonane bez bezpiecznej wymiany komunikatów, wcześniejsze klucze sesji bezpiecznej wymiany komunikatów nie są już dostępne.
TCS_37 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | 'A4h' | |
| P1 | 1 | '04h' | Wybór przez nazwę (AID) |
| P2 | 1 | '0Ch' | brak oczekiwanej odpowiedzi |
| Lc | 1 | 'NNh' | liczba bajtów wysłanych do karty (długość AID): '06h' dla aplikacji tachograficznej |
| #6-#(5+NN) | NN | 'XX..XXh' | AID: 'FF 54 41 43 48 4F' dla aplikacji tachograficznej 1. generacji AID: 'FF 53 4D 52 44 54' dla aplikacji tachograficznej 2. generacji |
Dla polecenia SELECT nie jest potrzebna żadna odpowiedź (brak Le w T=1, bądź nie ma żądania odpowiedzi w T=0).
TCS_38 Komunikat odpowiedzi (brak żądania odpowiedzi)
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli nie znaleziono aplikacji wyszczególnionej przez AID, zwróconym stanem przetwarzania jest '6A82'.
- W T=1, jeżeli jest bajt Le, zwróconym stanem jest '6700'.
- W T=0, jeżeli po poleceniu SELECT wymaga się odpowiedzi, zwróconym stanem jest '6900'.
- Jeżeli wybrana aplikacja uznana jest za uszkodzoną (znaleziony błąd integralności w atrybutach pliku), zwróconym stanem przetwarzania jest "6400" lub "6500".
3.5.1.2 Wybór pliku elementarnego przy pomocy identyfikatora pliku
TCS_39 Komunikat polecenia
TCS_40 Karta do tachografu musi obsługiwać bezpieczną wymianę komunikatów 2. generacji, jak określono w dodatku 11 część B dla tego wariantu polecenia.
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | 'A4h' | |
| P1 | 1 | '02h' | wybór EF pod bieżącym DF |
| P2 | 1 | '0Ch' | brak oczekiwanej odpowiedzi |
| Lc | 1 | '02h' | liczba bajtów wysłanych do karty |
| #6-#7 | 2 | 'XXXXh' | identyfikator pliku |
Dla polecenia SELECT nie jest potrzebna żadna odpowiedź (brak Le w T=1, bądź nie ma żądania odpowiedzi w T=0).
TCS_41 Komunikat odpowiedzi (brak żądania odpowiedzi)
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli nie znaleziono pliku odpowiadającego identyfikatorowi pliku, zwróconym stanem przetwarzania jest '6A82'.
- W T=1, jeżeli jest bajt Le, zwróconym stanem jest '6700'.
- W T=0, jeżeli po poleceniu SELECT wymaga się odpowiedzi, zwróconym stanem jest '6900'.
- Jeżeli wybrany plik uznany jest za uszkodzony (znaleziony błąd integralności w atrybutach pliku), zwróconym stanem przetwarzania jest "6400" lub "6500".
3.5.2 READ BINARY
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego zastosowanie jest ograniczone w porównaniu z poleceniem zdefiniowanym w tej normie.
Polecenie READ BINARY służy do odczytu danych z przezroczystego pliku.
Odpowiedź karty obejmuje zwrot odczytanych danych, opcjonalnie obudowane w strukturę bezpiecznej wymiany komunikatów.
3.5.2.1 Polecenie z przesunięciem w P1-P2
Polecenie to umożliwia IFD odczyt danych z aktualnie wybranego EF bez bezpiecznej wymiany komunikatów.
Uwaga: Tego polecenia bez bezpiecznej wymiany komunikatów można używać tylko do odczytu pliku, który wspiera warunek zabezpieczenia ALW dla trybu dostępu do odczytu.
TCS_42 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | 'B0h' | Odczyt binarny |
| P1 | 1 | 'XXh' | Przesunięcie w bajtach od początku pliku: bajt najbardziej znaczący |
| P2 | 1 | 'XXh' | Przesunięcie w bajtach od początku pliku: bajt najmniej znaczący |
| Le | 1 | 'XXh' | Długość oczekiwanych danych. Liczba bajtów do odczytu. |
Uwaga: bit 8 w P1 musi być ustawiony na 0.
TCS_43 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| #1-#X | X | 'XX..XXh' | Odczyt danych |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli nie wybrano EF, zwróconym stanem przetwarzania jest '6986'.
- Jeżeli warunki zabezpieczenia wybranego pliku nie są spełnione, polecenie zostaje przerwane z '6982'.
- Jeżeli przesunięcie nie jest zgodne z wielkością EF (przesunięcie > wielkość EF), zwróconym stanem przetwarzania jest '6B00'.
- Jeżeli wielkość danych do odczytu nie jest zgodna z wielkością EF (przesunięcie + Le > wielkość EF), zwróconym stanem przetwarzania jest '6700' lub '6Cxx', gdzie "xx" wskazuje dokładną długość.
- 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".
- Jeżeli błąd integralności zostaje wykryty w zgromadzonych danych, karta zwraca żądane dane, a zwróconym stanem przetwarzania jest '6281'.
3.5.2.1.1 Polecenie z bezpieczną wymianą komunikatów (przykłady)
Polecenie to umożliwia IFD odczyt danych z bieżąco wybranego EF z bezpieczną wymianą komunikatów w celu zweryfikowania integralności odebranych danych oraz ochrony poufności danych, jeżeli zastosowanie ma warunek zabezpieczenia SM-R-ENC-MAC-G1 (1. generacja) lub SM-R-ENC-MAC-G2 (2. generacja).
TCS_44 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '0Ch' | Żądana bezpieczna wymiana komunikatów |
| INS | 1 | 'B0h' | Odczyt binarny |
| P1 | 1 | 'XXh' | P1 (przesunięcie w bajtach od początku pliku): bajt najbardziej znaczący |
| P2 | 1 | 'XXh' | P2 (przesunięcie w bajtach od początku pliku): bajt najmniej znaczący |
| Lc | 1 | 'XXh' | Długość danych wejściowych dla bezpiecznej wymiany komunikatów |
| #6 | 1 | '97h' | TLE: znacznik specyfikacji oczekiwanej długości |
| #7 | 1 | '01h' | LLE: długość oczekiwanej długości |
| #8 | 1 | 'NNh' | Specyfikacja oczekiwanej długości (początkowy Le): liczba bajtów do odczytu |
| #9 | 1 | '8Eh' | TCC: znacznik kryptograficznej sumy kontrolnej |
| #10 | 1 | '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) |
| #11-#(10+L) | L | 'XX..XXh' | Kryptograficzna suma kontrolna |
| Le | 1 | '00h' | zgodnie ze specyfikacją w normie ISO/IEC 7816-4 |
TCS_45 Komunikat odpowiedzi, jeżeli SM-R-ENC-MAC-G1 (1. generacja) / SM-R-ENC-MAC-G2 (2. generacja) nie są wymagane oraz jeżeli format wejściowy bezpiecznej wymiany komunikatów jest prawidłowy:
| Bajt | Długość | Wartość | Opis |
| #1 | 1 | "81h" | TPV: znacznik wartości danych odkrytych |
| #2 | L | "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) | NN | "XX..XXh" | Wartość danych odkrytych |
| #(2+L+NN) | 1 | "99h" | Znacznik stanu przetwarzania (SW1-SW2) - opcjonalnie dla bezpiecznej wymiany komunikatów 1. generacji |
| #(3+L+NN) | 1 | "02h" | Długość stanu przetwarzania - opcjonalnie dla bezpiecznej wymiany komunikatów 1. generacji |
| #(4+L+NN) - #(5+L+NN) | 2 | "XX XXh" | Stan przetwarzania niechronionej odpowiedzi APDU - opcjonalnie dla bezpiecznej wymiany komunikatów 1. generacji |
| #(6+L+NN) | 1 | "8Eh" | TCC: znacznik kryptograficznej sumy kontrolnej |
| #(7+L+NN) | 1 | "XXh" | LCC: długość znajdującej się dalej kryptograficznej sumy kontrolnej "04h" dla bezpiecznej wymiany komunikatów 1. gene- racji (zob. dodatek 11 część A) "08h", "0Ch" lub "10h", w zależności od długości klucza AES, dla bezpiecznej wymiany komunikatów 2. generacji (zob. dodatek 11 część B) |
| #(8+L+NN)-#(7+M+L+NN) | M | "XX..XXh" | Kryptograficzna suma kontrolna |
| SW | 2 | "XXXXh" | Słowa stanu (SW1, SW2) |
TCS_46 Komunikat odpowiedzi, jeżeli SM-R-ENC-MAC-G1 (1. generacja) / SM-R-ENC-MAC-G2 (2. generacja) są wymagane oraz jeżeli format wejściowy bezpiecznej wymiany komunikatów jest prawidłowy:
| "Bajt | Długość | Wartość | Opis |
| #1 | 1 | "87h" | TPI CG: znacznik zaszyfrowanych danych (kryptogram) |
| #2 | L | "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) | MM | "01XX..XXh" | dane szyfrowane: wskaźnik wypełnienia i kryptogram |
| #(2+L+MM) | 1 | "99h" | Znacznik stanu przetwarzania (SW1-SW2) - opcjonalnie dla bezpiecznej wymiany komunikatów 1. generacji |
| #(3+L+MM) | 1 | "02h" | Długość stanu przetwarzania - opcjonalnie dla bezpiecznej wymiany komunikatów 1. generacji |
| #(4+L+MM) - #(5+L+MM) | 2 | "XX XXh" | Stan przetwarzania niechronionej odpowiedzi APDU - opcjonalnie dla bezpiecznej wymiany komunikatów 1. generacji |
| #(6+L+MM) | 1 | "8Eh" | TCC: znacznik kryptograficznej sumy kontrolnej |
| #(7+L+MM) | 1 | "XXh" | LCC: długość znajdującej się dalej 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) | N | "XX..XXh" | Kryptograficzna suma kontrolna |
| SW | 2 | "XXXXh" | Słowa stanu (SW1, SW2) |
Polecenie READ BINARY może zwracać stany regularnego przetwarzania, wymienione w TCS_43 pod znacznikiem '99h', opisane w TCS_59, przy użyciu struktury odpowiedzi bezpiecznej wymiany komunikatów.
Ponadto mogą wystąpić niektóre błędy, swoiście dotyczące bezpiecznej wymiany komunikatów. W takim przypadku zwracany jest po prostu stan przetwarzania bez struktury bezpiecznej wymiany komunikatów:
TCS_47 Komunikat odpowiedzi przy nieprawidłowym formacie wejściowym bezpiecznej wymiany komunikatów
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli klucz bieżącej sesji nie jest dostępny, zwracany jest stan przetwarzania '6A88'. Zdarza się to w sytuacji, gdy klucz sesyjny nie jest już generowany, albo w sytuacji, gdy wygaśnie już ważność kluczy sesyjnych (w tym przypadku IFD musi powtórnie uruchomić proces wzajemnego uwierzytelnienia w celu utworzenia nowego klucza sesyjnego).
- Jeżeli w formacie bezpiecznej wymiany komunikatów brakuje pewnych oczekiwanych obiektów (określonych powyżej), zwracany jest stan przetwarzania '6987': ten błąd ma miejsce, jeżeli brakuje oczekiwanego znacznika lub jeżeli treść polecenia nie jest prawidłowo skonstruowana.
- Jeżeli pewne obiekty danych są nieprawidłowe, zwróconym stanem przetwarzania jest '6988': ten błąd ma miejsce, jeżeli obecne są wszystkie wymagane znaczniki, ale niektóre długości różnią się od oczekiwanych.
- Jeżeli weryfikacja kryptograficznej sumy kontrolnej wykaże niezgodność, zwróconym stanem przetwarzania jest '6688'.
3.5.2.2 Polecenie z krótkimi identyfikatorem EF (Elementary File)
Ten wariant polecenia umożliwia IFD wybór EF przy pomocy krótkiego identyfikatora EF oraz odczyt danych z tego EF.
TCS_48 Karta do tachografu obsługuje ten wariant polecenia dla wszystkich plików elementarnych z określonym krótkim identyfikatorem EF. Przedmiotowe krótkie identyfikatory EF zostały określone w rozdziale 4.
TCS_49 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | 'B0h' | Odczyt binarny |
| P1 | 1 | 'XXh' | Bit 8 ustawiany jest na 1. Bity 7 i 6 ustawiane są na 00. Bity 5 - 1 kodują krótki identyfikator EF odpowiedniego EF. |
| P2 | 1 | 'XXh' | Koduje przesunięcie od 0 do 255 bajtów w EF przywołanym przez P1. |
| Le | 1 | 'XXh' | Długość oczekiwanych danych. Liczba bajtów do odczytu. |
Uwaga: Krótkie identyfikatory EF używane na potrzeby aplikacji tachograficznej 2. generacji zostały określone w rozdziale 4.
Jeżeli P1 koduje krótki identyfikator EF, a polecenie zostało pomyślnie wykonane, ustalone EF staje się bieżąco wybranym EF (bieżący EF).
TCS_50 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| #1-#L | L | 'XX..XXh' | Odczyt danych |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli nie znaleziono pliku odpowiadającego krótkiemu identyfikatorowi EF, zwróconym stanem przetwarzania jest '6A82'.
- Jeżeli warunki zabezpieczenia wybranego pliku nie są spełnione, polecenie zostaje przerwane z '6982'.
- Jeżeli przesunięcie nie jest zgodne z wielkością EF (przesunięcie > wielkość EF), zwróconym stanem przetwarzania jest '6B00'.
- Jeżeli wielkość danych do odczytu nie jest zgodna z wielkością EF (przesunięcie + Le > wielkość EF), zwróconym stanem przetwarzania jest '6700' lub '6Cxx', gdzie "xx" wskazuje dokładną długość.
- 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 '6581'.
- Jeżeli błąd integralności zostaje wykryty w zgromadzonych danych, karta zwraca żądane dane, a zwróconym stanem przetwarzania jest '6281'.
3.5.2.3 Polecenie z nieparzystym bajtem instrukcji
Ten wariant polecenia umożliwia IFD odczyt danych z EF, który ma 32 768 bajtów lub więcej.
TCS_51 Karta do tachografu obsługująca EF, który ma 32 768 bajtów lub więcej, musi obsługiwać ten wariant polecenia dla takich EF. Karta do tachografu może, ale nie musi obsługiwać tego wariantu polecenia dla innych EF, z wyjątkiem EF Sensor_Installation_Data (zob. TCS_156 i TCS_160).
TCS_52 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | 'B1h' | Odczyt binarny |
| P1 | 1 | '00h' | bieżący EF |
| P2 | 1 | '00h' | |
| Lc | 1 | 'NNh' | Lc długość przesuniętego obiektu danych. |
| #6-#(5+NN) | NN | 'XX..XXh' | przesunięty obiekt danych: znacznik '54h' długość '01h' lub '02h' wartość przesunięcie |
| Le | 1 | 'XXh' | Liczba bajtów do odczytu. |
IFD koduje długość przesuniętego obiektu danych z możliwie najmniejszą liczbą oktetów, tzn. przy pomocy bajtu długości '01h' IFD koduje przesunięcie od 0 do 255 bajtów, a przy pomocy bajtu długości '02h' koduje przesunięcie od '256' do '65 535' bajtów.
TCS_53 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| #1-#L | L | 'XX..XXh' | Odczytane dane zapakowane do nieokreślonego obiektu danych ze znacznikiem '53h'. |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli nie wybrano EF, zwróconym stanem przetwarzania jest '6986'.
- Jeżeli warunki zabezpieczenia wybranego pliku nie są spełnione, polecenie zostaje przerwane z '6982'.
- Jeżeli przesunięcie nie jest zgodne z wielkością EF (przesunięcie > wielkość EF), zwróconym stanem przetwarzania jest '6B00'.
- Jeżeli wielkość danych do odczytu nie jest zgodna z wielkością EF (przesunięcie + Le > wielkość EF), zwróconym stanem przetwarzania jest '6700' lub '6Cxx', gdzie "xx" wskazuje dokładną długość.
- 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 '6581'.
- Jeżeli błąd integralności zostaje wykryty w zgromadzonych danych, karta zwraca żądane dane, a zwróconym stanem przetwarzania jest '6281'.
3.5.2.3.1 Polecenie z bezpieczną wymianą komunikatów (przykład)
Poniższy przykład ilustruje stosowanie bezpiecznej wymiany komunikatów, jeżeli zastosowanie ma warunek zabezpieczenia SM-MAC-G2.
TCS_54 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '0Ch' | Żądana bezpieczna wymiana komunikatów |
| INS | 1 | 'B1h' | Odczyt binarny |
| P1 | 1 | '00h' | bieżący EF |
| P2 | 1 | '00h' | |
| Lc | 1 | 'XXh' | długość chronionego pola danych |
| #6 | 1 | 'B3h' | znacznik wartości danych odkrytych kodowanych w BER-TLV |
| #7 | 1 | 'NNh' | LPV: długość przesyłanych danych |
| #(8)-#(7+NN) | NN | 'XX..XXh' | dane odkryte kodowane w BER-TLV, tj. przesunięty obiekt danych ze znacznikiem '54' |
| #(8+NN) | 1 | '97h' | TLE: znacznik specyfikacji oczekiwanej długości |
| #(9+NN) | 1 | '01h' | LLE: długość oczekiwanej długości |
| #(10+NN) | 1 | 'XXh' | specyfikacja oczekiwanej długości (początkowy Le): liczba bajtów do odczytu |
| #(11+NN) | 1 | '8Eh' | TCC: znacznik kryptograficznej sumy kontrolnej |
| #(12+NN) | 1 | 'XXh' | LCC: długość znajdującej się dalej kryptograficznej sumy kontrolnej '08h', '0Ch' lub '10h', w zależności od długości klucza AES, dla bezpiecznej wymiany komunikatów 2. generacji (zob. dodatek 11 część B) |
| #(13+NN)-#(12+M+NN) | M | 'XX..XXh' | Kryptograficzna suma kontrolna |
| Le | 1 | '00h' | zgodnie ze specyfikacją w normie ISO/IEC 7816-4 |
TCS_55 komunikat odpowiedzi, jeżeli polecenie zostało pomyślnie wykonane
| Bajt | Długość | Wartość | Opis |
| #1 | 1 | 'B3h' | odkryte dane kodowane w BER-TLV |
| #2 | L | 'NNh' lub '81 NNh' | LPV: długość zwracanych danych (= początkowemu Le). L ma 2 bajty, jeżeli LPV>127 bajtów |
| #(2+L)-#(1+L+NN) | NN | 'XX..XXh' | Wartość odkrytych danych kodowanych w BER-TLV, tj. odczytane dane zapakowane do nieokreślonego obiektu danych ze znacznikiem '53h'. |
| #(2+L+NN) | 1 | '99h' | Stan przetwarzania niechronionej odpowiedzi APDU |
| #(3+L+NN) | 1 | '02h' | Długość stanu przetwarzania |
| #(4+L+NN) - #(5+L+NN) | 2 | 'XX XXh' | Stan przetwarzania niechronionej odpowiedzi APDU |
| #(6+L+NN) | 1 | '8Eh' | TCC: znacznik kryptograficznej sumy kontrolnej |
| #(7+L+NN) | 1 | 'XXh' | LCC: długość znajdującej się dalej kryptograficznej sumy kontrolnej '08h', '0Ch' lub '10h', w zależności od długości klucza AES, dla bezpiecznej wymiany komunikatów 2. generacji (zob. dodatek 11 część B) |
| #(8+L+NN)-#(7+M+L+NN) | M | 'XX..XXh' | Kryptograficzna suma kontrolna |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
3.5.3 UPDATE BINARY
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego zastosowanie jest ograniczone w porównaniu z poleceniem zdefiniowanym w tej normie.
Komunikat polecenia UPDATE BINARY inicjuje aktualizację (kasowanie + zapis) bitów już znajdujących się w binarnym EF, zastępując je bitami podanymi w poleceniu APDU.
3.5.3.1 Polecenie z przesunięciem w P1-P2
Polecenie to umożliwia IFD zapis danych do bieżąco wybranego EF, bez sprawdzenia przez kartę integralności otrzymanych danych.
Uwaga: Tego polecenia bez bezpiecznej wymiany komunikatów można używać tylko do aktualizacji pliku, który wspiera warunek zabezpieczenia ALW dla trybu dostępu do aktualizacji.
TCS_56 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | 'D6h' | Aktualizacja binarna licznika |
| Bajt | Długość | Wartość | Opis |
| P1 | 1 | 'XXh' | Przesunięcie w bajtach od początku pliku: bajt najbardziej znaczący |
| P2 | 1 | 'XXh' | Przesunięcie w bajtach od początku pliku: bajt najmniej znaczący |
| Lc | 1 | 'NNh' | Lc długość aktualizowanych danych. Liczba zapisywanych bajtów. |
| #6-#(5+NN) | NN | 'XX..XXh' | zapisywane dane |
Uwaga: bit 8 w P1 musi być ustawiony na 0.
TCS_57 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli nie wybrano EF, zwróconym stanem przetwarzania jest '6986'.
- Jeżeli warunki zabezpieczenia wybranego pliku nie są spełnione, polecenie zostaje przerwane z '6982'.
- Jeżeli przesunięcie nie jest zgodne z wielkością EF (przesunięcie > wielkość EF), zwróconym stanem przetwarzania jest '6B00'.
- Jeżeli wielkość danych, które mają być zapisane, nie jest zgodna z wielkością EF (przesunięcie + Lc > wielkość EF), zwróconym stanem przetwarzania jest '6700'.
- Jeżeli błąd integralności zostaje wykryty w atrybutach pliku, karta uznaje, że plik jest uszkodzony i nienaprawialny, a zwróconym stanem przetwarzania jest '6400' lub '6500'.
- Jeżeli zapis nie jest wykonany pomyślnie, zwróconym stanem przetwarzania jest '6581'.
3.5.3.1.1 Polecenie z bezpieczną wymianą komunikatów (przykłady)
Polecenie to umożliwia IFD zapis danych do bieżąco wybranego EF, ze sprawdzeniem przez kartę integralności otrzymanych danych. Gdy nie jest wymagana poufność, dane nie są szyfrowane.
TCS_58 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '0Ch' | Żądana bezpieczna wymiana komunikatów |
| INS | 1 | 'D6h' | Aktualizacja binarna licznika |
| P1 | 1 | 'XXh' | Przesunięcie w bajtach od początku pliku: bajt najbardziej znaczący |
| P2 | 1 | 'XXh' | Przesunięcie w bajtach od początku pliku: bajt najmniej znaczący |
| Lc | 1 | 'XXh' | długość chronionego pola danych |
| #6 | 1 | '81h' | TPV: znacznik wartości danych odkrytych |
| #7 | L | 'NNh' lub '81 NNh' | LPV: długość transmitowanych danych. L ma 2 bajty, jeżeli LPV >127 bajtów. |
| #(7 + L)-#(6 + L + NN) | NN | 'XX..XXh' | wartość odkrytych danych (dane, które mają być zapisane) |
| #(7 + L + NN) | 1 | '8Eh' | TCC: znacznik kryptograficznej sumy kontrolnej |
| #(8 + L + NN) | 1 | '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) |
| #(9 + L + NN)-#(8 + M + L + NN) | M | 'XX..XXh' | Kryptograficzna suma kontrolna |
| Le | 1 | '00h' | zgodnie ze specyfikacją w normie ISO/ IEC 7816-4 |
TCS_59 Komunikat odpowiedzi przy prawidłowym formacie wejściowym bezpiecznej wymiany komunikatów
| Bajt | Długość | Wartość | Opis |
| #1 | 1 | '99h' | TSW: znacznik słów stanu (chroniony przez CC) |
| #2 | 1 | '02h' | LSW: długość zwracanego słowa stanu |
| #3-#4 | 2 | 'XXXXh' | Stan przetwarzania niechronionej odpowiedzi APDU |
| #5 | 1 | '8Eh' | TCC: znacznik kryptograficznej sumy kontrolnej |
| #6 | 1 | '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) |
| #7-#(6+L) | L | 'XX..XXh' | Kryptograficzna suma kontrolna |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
Stany "regularnego" przetwarzania, opisane dla polecenia UPDATE BINARY z bezpieczną wymianą komunikatów (zob. pkt 3.5.3.1), mogą być zwracane przy użyciu struktury komunikatu odpowiedzi opisanej powyżej.
Ponadto mogą wystąpić niektóre błędy, swoiście dotyczące bezpiecznej wymiany komunikatów. W takim przypadku zwracany jest po prostu stan przetwarzania bez struktury bezpiecznej wymiany komunikatów:
TCS_60 Komunikat odpowiedzi w przypadku błędu w bezpiecznej wymianie komunikatów
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli klucz bieżącej sesji nie jest dostępny, zwracany jest stan przetwarzania '6A88'.
- Jeżeli w formacie bezpiecznej wymiany komunikatów brakuje pewnych oczekiwanych obiektów (określonych powyżej), zwracany jest stan przetwarzania '6987': ten błąd ma miejsce, jeżeli brakuje oczekiwanego znacznika lub jeżeli treść polecenia nie jest prawidłowo skonstruowana.
- Jeżeli pewne obiekty danych są nieprawidłowe, zwróconym stanem przetwarzania jest '6988': ten błąd ma miejsce, jeżeli obecne są wszystkie wymagane znaczniki, ale niektóre długości różnią się od oczekiwanych.
- Jeżeli weryfikacja kryptograficznej sumy kontrolnej wykaże niezgodność, zwróconym stanem przetwarzania jest '6688'.
3.5.3.2 Polecenie z krótkimi identyfikatorem EF
Ten wariant polecenia umożliwia IFD wybór EF przy pomocy krótkiego identyfikatora EF oraz zapis danych z tego EF.
TCS_61 Karta do tachografu obsługuje ten wariant polecenia dla wszystkich plików elementarnych z określonym krótkim identyfikatorem EF. Przedmiotowe krótkie identyfikatory EF zostały określone w rozdziale 4.
TCS_62 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | 'D6h' | Aktualizacja binarna licznika |
| P1 | 1 | 'XXh' | Bit 8 ustawiany jest na 1. Bity 7 i 6 ustawiane są na 00. Bity 5 - 1 kodują krótki identyfikator EF odpowiedniego EF. |
| P2 | 1 | 'XXh' | Koduje przesunięcie od 0 do 255 bajtów w EF przywołanym przez P1. |
| Lc | 1 | 'NNh' | Lc długość aktualizowanych danych. Liczba zapisywanych bajtów. |
| #6-#(5+NN) | NN | 'XX..XXh' | zapisywane dane |
TCS_63 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
Uwaga: Krótkie identyfikatory EF używane na potrzeby aplikacji tachograficznej 2. generacji zostały określone w rozdziale 4.
Jeżeli P1 koduje krótki identyfikator EF, a polecenie zostało pomyślnie wykonane, ustalone EF staje się bieżąco wybranym EF (bieżący EF).
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli nie znaleziono pliku odpowiadającego krótkiemu identyfikatorowi EF, zwróconym stanem przetwarzania jest '6A82'.
- Jeżeli warunki zabezpieczenia wybranego pliku nie są spełnione, polecenie zostaje przerwane z '6982'.
- Jeżeli przesunięcie nie jest zgodne z wielkością EF (przesunięcie > wielkość EF), zwróconym stanem przetwarzania jest '6B00'.
- Jeżeli wielkość danych, które mają być zapisane, nie jest zgodna z wielkością EF (przesunięcie + Lc > wielkość EF), zwróconym stanem przetwarzania jest '6700'.
- Jeżeli błąd integralności zostaje wykryty w atrybutach pliku, karta uznaje, że plik jest uszkodzony i nienaprawialny, a zwróconym stanem przetwarzania jest '6400' lub '6581'.
- Jeżeli zapis nie jest wykonany pomyślnie, zwróconym stanem przetwarzania jest '6581'.
3.5.3.3 Polecenie z nieparzystym bajtem instrukcji
Ten wariant polecenia umożliwia IFD zapis danych do EF, który ma 32 768 bajtów lub więcej.
TCS_64 Karta do tachografu obsługująca EF, który ma 32 768 bajtów lub więcej, musi obsługiwać ten wariant polecenia dla takich EF. Karta do tachografu może, ale nie musi obsługiwać tego wariantu polecenia dla innych EF.
TCS_65 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | 'D7h' | Aktualizacja binarna licznika |
| P1 | 1 | '00h' | bieżący EF |
| P2 | 1 | '00h' | |
| Lc | 1 | 'NNh' | Lc długość danych w polu danych dotyczących polecenia |
| #6-#(5+NN) | NN | 'XX..XXh' | przesunięty obiekt danych ze znacznikiem '54h' || nieokreślony obiekt danych ze znacznikiem '53h', który pakuje dane do zapisu |
IFD koduje długość przesuniętego obiektu danych oraz długość nieokreślonego obiektu danych z możliwie najmniejszą liczbą oktetów, tzn. przy pomocy bajtu długości '01h' IFD koduje przesunięcie/długość od 0 do 255 bajtów, a przy pomocy bajtu długości '02h' koduje przesunięcie/ długość od '256' do '65 535' bajtów.
TCS_66 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli nie wybrano EF, zwróconym stanem przetwarzania jest '6986'.
- Jeżeli warunki zabezpieczenia wybranego pliku nie są spełnione, polecenie zostaje przerwane z '6982'.
- Jeżeli przesunięcie nie jest zgodne z wielkością EF (przesunięcie > wielkość EF), zwróconym stanem przetwarzania jest '6B00'.
- Jeżeli wielkość danych, które mają być zapisane, nie jest zgodna z wielkością EF (przesunięcie + Lc > wielkość EF), zwróconym stanem przetwarzania jest '6700'.
- Jeżeli błąd integralności zostaje wykryty w atrybutach pliku, karta uznaje, że plik jest uszkodzony i nienaprawialny, a zwróconym stanem przetwarzania jest '6400' lub '6500'.
- Jeżeli zapis nie jest wykonany pomyślnie, zwróconym stanem przetwarzania jest '6581'.
3.5.3.3.1 Polecenie z bezpieczną wymianą komunikatów (przykład)
Poniższy przykład ilustruje stosowanie bezpiecznej wymiany komunikatów, jeżeli zastosowanie ma warunek zabezpieczenia SM-MAC-G2.
TCS_67 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '0Ch' | Żądana bezpieczna wymiana komunikatów |
| INS | 1 | 'D7h' | Aktualizacja binarna licznika |
| P1 | 1 | '00h' | bieżący EF |
| P2 | 1 | '00h' | |
| Lc | 1 | 'XXh' | długość chronionego pola danych |
| #6 | 1 | 'B3h' | znacznik wartości danych odkrytych kodowanych w BER-TLV |
| #7 | L | 'NNh' lub '81 NNh' | LPV: długość transmitowanych danych. L ma 2 bajty, jeżeli LPV >127 bajtów. |
| #(7+L)-#(6+L+NN) | NN | 'XX..XXh' | dane odkryte kodowane w BER-TLV, tj. przesunięty obiekt danych ze znacznikiem '54h' || nieokreślony obiekt danych ze znacznikiem '53h', który pakuje dane do zapisu |
| #(7+L+NN) | 1 | '8Eh' | TCC: znacznik kryptograficznej sumy kontrolnej |
| #(8+L+NN) | 1 | 'XXh' | LCC: długość znajdującej się dalej kryptograficznej sumy kontrolnej '08h', '0Ch' lub '10h', w zależności od długości klucza AES, dla bezpiecznej wymiany komunikatów 2. generacji (zob. dodatek 11 część B) |
| #(9+L+NN)-#(8+M+L+NN) | M | 'XX..XXh' | Kryptograficzna suma kontrolna |
| Le | 1 | '00h' | zgodnie ze specyfikacją w normie ISO/IEC 7816-4 |
TCS_68 komunikat odpowiedzi, jeżeli polecenie zostało pomyślnie wykonane
| Bajt | Długość | Wartość | Opis |
| #1 | 1 | '99h' | TSW: znacznik słów stanu (chroniony przez CC) |
| #2 | 1 | '02h' | LSW: długość zwracanego słowa stanu |
| #3-#4 | 2 | 'XXXXh' | Stan przetwarzania niechronionej odpowiedzi APDU |
| #5 | 1 | '8Eh' | TCC: znacznik kryptograficznej sumy kontrolnej |
| #6 | 1 | 'XXh' | LCC: długość znajdującej się dalej kryptograficznej sumy kontrolnej '08h', '0Ch' lub '10h', w zależności od długości klucza AES, dla bezpiecznej wymiany komunikatów 2. generacji (zob. dodatek 11 część B) |
| #7-#(6 + L) | L | 'XX..XXh' | Kryptograficzna suma kontrolna |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
3.5.4 GET CHALLENGE
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego zastosowanie jest ograniczone w porównaniu z poleceniem zdefiniowanym w tej normie.
Polecenie GET CHALLENGE żąda od karty wydania wyzwania w celu użycia go w procedurze związanej z zabezpieczeniem, w której do karty wysyłany jest kryptogram lub pewne szyfrowane dane.
TCS_69 Wyzwanie wydane przez kartę ważne jest tylko dla następnego polecenia, które używa wyzwania, wysłanego do karty.
TCS_70 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | '84h' | INS |
| P1 | 1 | '00h' | P1 |
| P2 | 1 | '00h' | P2 |
| Le | 1 | '08h' | Le (długość oczekiwanego wyzwania). |
TCS_71 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| #1-#8 | 8 | 'XX..XXh' | wyzwanie |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli Le jest inne niż '08h', zwracany jest stan przetwarzania '6700'.
- Jeżeli parametry P1-P2 są nieprawidłowe, zwracany jest stan przetwarzania '6A86'.
3.5.5 VERIFY
Polecenie to jest zgodne z normą ISO/IEC 7816-4, ale jego zastosowanie jest ograniczone w porównaniu z poleceniem zdefiniowanym w tej normie.
Jedynie karta warsztatowa jest zobowiązana do obsługi tego polecenia.
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować tego polecenia, lecz w przypadku tych kart żadne referencyjne CHV nie jest zindywidualizowane. Karty te nie mogą zatem pomyślnie wykonywać tego polecenia. Jeśli chodzi o rodzaje kart do tachografów inne niż karta warsztatowa, ich zachowanie, tj. zwracany kod błędu, nie jest objęte zakresem zastosowania niniejszej specyfikacji, jeżeli polecenie to jest wysyłane.
Polecenie VERIFY inicjuje porównanie w karcie danych CHV (PIN) wysłanych w poleceniu z referencyjnymi CHV przechowywanymi na karcie.
TCS_72 PIN wprowadzony przez użytkownika musi być kodowany w ASCI 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).
TCS_73 Aplikacje tachograficzne 1. i 2. generacji używają tego samego referencyjnego CHV.
TCS_74 Karta do tachografu sprawdza, czy polecenie jest prawidłowo zakodowane. Jeżeli polecenie nie jest prawidłowo zakodowane, karta nie porównuje wartości CHV, nie zmniejsza licznika dozwolonych prób CHV, ani nie zeruje stanu zabezpieczenia "PIN_Verified", lecz przerywa wykonanie polecenia. Polecenie jest prawidłowo zakodowane, jeżeli bajty CLA, INS, P1, P2 i Lc posiadają określone wartości, brak jest Le, a pole danych dotyczących polecenia posiada odpowiednią długość.
TCS_75 Jeżeli polecenie zostało pomyślnie wykonane, licznik dozwolonych prób CHV zostaje przywrócony do stanu wyjściowego. Wartość początkowa licznika dozwolonych prób CHV to 5. Jeżeli polecenie zostało pomyślnie wykonane, stan zabezpieczenia wewnętrznego karty otrzymuje status "PIN_Verified". Karta zeruje ten stan zabezpieczenia, jeżeli karta jest zresetowana lub jeżeli kod CHV przesłany w poleceniu nie odpowiada przechowywanemu referencyjnemu CHV.
Uwaga: Stosowanie tego samego referencyjnego CHV i globalnego stanu zabezpieczenia zapobiega konieczności ponownego wprowadzenia PIN przez pracownika warsztatu po wybraniu innej aplikacji tachograficznej DF.
TCS_76 Jeżeli porównanie wykaże niezgodność, jest ono rejestrowane na karcie, tzn. licznik dozwolonych prób CHV zmniejsza się o jeden, aby ograniczyć liczbę dalszych prób użycia referencyjnego CHV.
TCS_77 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | '20h' | INS |
| P1 | 1 | '00h' | P1 |
| P2 | 1 | '00h' | P2 (zweryfikowane CHV jest domniemanie znane) |
| Lc | 1 | '08h' | długość przesyłanego kodu CHV |
| #6-#13 | 8 | 'XX..XXh' | CHV |
TCS_78 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli nie znaleziono referencyjnego CHV, zwróconym stanem przetwarzania jest '6A88'.
- Jeżeli CHV jest zablokowane (licznik dozwolonych prób CHV jest wyzerowany), zwróconym stanem przetwarzania jest '6983'. Po znalezieniu się w tym stanie CHV nie może już nigdy być pomyślnie przekazane.
- Jeżeli porównanie wykaże niezgodność, licznik dozwolonych prób CHV jest zmniejszany i zwracany jest stan '63CX' (X > 0, gdzie X pokazuje stan licznika dozwolonych prób CHV).
- Jeżeli referencyjne CHV uznane jest za uszkodzone, zwróconym stanem przetwarzania jest '6400' lub '6581'.
- Jeżeli Lc jest inne niż '08h', zwracany jest stan przetwarzania '6700'.
3.5.6 GET RESPONSE
Polecenie to jest zgodne z normą ISO/IEC 7816-4.
Polecenia tego (niezbędnego i dostępnego tylko dla protokołu T=0) używa się do przesyłania przygotowanych danych z karty do urządzenia interfejsu (przypadek, gdy polecenie zawiera oba parametry Lc i Le).
Polecenie GET RESPONSE musi być wydane bezpośrednio po poleceniu przygotowującym dane, w przeciwnym przypadku dane są tracone. Po wykonaniu polecenia GET RESPONSE (z wyjątkiem sytuacji, gdy wystąpi błąd '61xx' lub '6Cxx', zob. poniżej) wcześniej przygotowane dane nie są już dostępne.
TCS_79 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | 'C0h' | |
| P1 | 1 | '00h' | |
| P2 | 1 | '00h' | |
| Le | 1 | 'XXh' | oczekiwana liczba bajtów |
TCS_80 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| #1-#X | X | 'XX..XXh' | dane |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli karta nie przygotuje żadnych danych, zwróconym stanem przetwarzania jest '6900' lub '6F00'..
- Jeżeli Le przekracza liczbę dostępnych bajtów lub Le to zero, zwróconym stanem przetwarzania jest '6Cxx', gdzie "xx" oznacza dokładną liczbę dostępnych bajtów. W takim przypadku przygotowane dane pozostają dostępne dla kolejnego polecenia GET RESPONSE.
- Jeżeli Le jest różne od zera i jest mniejsze od liczby dostępnych bajtów, karta wysyła normalnie żądane dane, a zwróconym stanem przetwarzania jest '61xx', gdzie "xx" oznacza liczbę dodatkowych bajtów jeszcze dostępnych dla kolejnego polecenia GET RESPONSE.
- Jeżeli polecenie nie jest obsługiwane (protokół T=1), karta zwraca '6D00'.
3.5.7 PSO: VERIFY CERTIFICATE
Polecenie to jest zgodne z normą ISO/IEC 7816-8, ale jego zastosowanie jest ograniczone w porównaniu z poleceniem zdefiniowanym w tej normie.
Karta używa polecenia VERIFY_CERTIFICATE do otrzymania klucza publicznego z zewnątrz i do sprawdzenia ważności tego klucza.
3.5.7.1 Para polecenie - odpowiedź 1. generacji
TCS_81 Ten wariant polecenia jest obsługiwany jedynie przez aplikację tachograficzną 1. generacji.
TCS_82 W przypadku pomyślnej weryfikacji poleceniem VERIFY CERTIFICATE klucz publiczny jest zapamiętany do przyszłego wykorzystania w środowisku zabezpieczeń. Klucz ten jest jawnie przydzielony do używania w poleceniach związanych z zabezpieczeniem (INTERNAL AUTHENTICATE, EXTERNAL AUTHENTICATE lub VERIFY CERTIFICATE) przez polecenie MSE (zob. pkt 3.5.11) przy użyciu jego identyfikatora klucza.
TCS_83 W każdym przypadku polecenie VERIFY CERTIFICATE używa klucza publicznego uprzednio wybranego przez polecenie MSE do otwarcia certyfikatu. Ten klucz publiczny musi być kluczem jednego z Stron lub Europy.
TCS_84 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | '2Ah' | wykonanie operacji zabezpieczającej |
| P1 | 1 | '00h' | P1 |
| P2 | 1 | 'AEh' | P2: dane niekodowane w BER-TLV (konkatenacja elementów danych) |
| Lc | 1 | 'C2h' | Lc: długość certyfikatu, 194 bajty |
| #6-#199 | 194 | 'XX..XXh' | certyfikat: konkatenacja elementów danych (opisana w dodatku 11) |
TCS_85 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli weryfikacja certyfikatu nie uda się, zwróconym stanem przetwarzania jest '6688'. Proces weryfikacji i otwierania certyfikatu opisano w dodatku 11 dla 1. generacji i 2. generacji.
- Jeżeli klucza publicznego nie ma w środowisku zabezpieczeń, zwróconym stanem przetwarzania jest '6A88'.
- Jeżeli wybrany klucz publiczny (użyty do otwierania certyfikatu) uznany jest za uszkodzony, zwróconym stanem przetwarzania jest '6400' lub '6581'.
- Wyłącznie 1. generacja: Jeżeli CHA.LSB (CertificateHolderAuthorisation. equipmentType) wybranego klucza publicznego (użytego do otwierania certyfikatu) różni się od '00' (tzn. nie jest kluczem Strony lub Europy), zwróconym stanem przetwarzania jest '6985'.
3.5.7.2 Para polecenie - odpowiedź 2. generacji
W zależności od wielkości krzywej certyfikaty ECC mogą być tak długie, że nie mogą być przekazywane w jednym APDU. W takim przypadku stosowany musi być łańcuch poleceń zgodny z ISO/IEC 7816-4, a certyfikat musi być przesyłany w dwóch kolejnych poleceniach APDU PSO: Verify Certificate.
Struktura certyfikatu i parametry domeny zostały określone w dodatku 11.
TCS_86 Polecenie może być wykonywane w MF, w DF Tachograph i w DF Tachograph_G2 (zob. również TCS_34).
TCS_87 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | 'X0h' | bajt CLA wskazujący łańcuch poleceń: '00h' - jedyne lub ostatnie polecenie łańcucha '10h' - nieostatnie polecenie łańcucha |
| INS | 1 | '2Ah' | wykonanie operacji zabezpieczającej |
| P1 | 1 | '00h' | |
| P2 | 1 | 'BEh' | weryfikacja samoopisującego certyfikatu |
| Lc | 1 | 'XXh' | długość pola danych dotyczących polecenia (zob. TCS_88 oraz TCS_89). |
| #6-#5+L | L | 'XX..XXh' | dane kodowane w DER-TLV: Obiekt danych jednostki certyfikującej ECC jako pierwszy obiekt danych konkatenowany z obiektem danych podpisu certyfikatu ECC jako drugim obiektem danych lub jako częścią tej konkatenacji. Znacznik '7F21' i odpowiednia długość nie są przekazywane. Kolejność tych obiektów danych jest stała. |
TCS_88 W odniesieniu do APDU o krótkiej długości zastosowanie mają następujące postanowienia: IFD musi wykorzystywać minimalną liczbę APDU wymaganą do przesłania pay- loadu polecenia oraz transmisji maksymalnej liczby bajtów w pierwszym poleceniu APDU. Jednak każda wartość 'Lc' do 255 bajtów musi być obsługiwana przez kartę.
TCS_89 W odniesieniu do APDU o rozszerzonej długości zastosowanie mają następujące postanowienia: jeżeli certyfikat nie jest dopasowany do pojedynczego APDU, karta musi obsługiwać łańcuch poleceń. IFD musi wykorzystywać minimalną liczbę APDU wymaganą do przesłania payloadu polecenia oraz transmisji maksymalnej liczby bajtów w pierwszym poleceniu APDU. Jeżeli konieczne jest utworzenia łańcucha, każda wartość 'Lc' do podanej maksymalnej wielkości rozszerzonej długości musi być obsługiwana przez kartę.
Uwaga: Zgodnie z dodatkiem 11 karta przechowuje certyfikat lub odpowiednie treści certyfikatu oraz uaktualnia jego currentAuthenticatedTime.
Struktura komunikatu odpowiedzi i słowa stanu zostały określone w TCS_85.
TCS_90 Oprócz kodów błędów wymienionych w TCS_85, karta może zwracać następujące kody błędów:
- jeżeli CHA.LSB (CertificateHolderAuthorisation.equipmentType) wybranego klucza publicznego (użytego do otwierania certyfikatu) nie jest odpowiednie dla weryfikacji certyfikatu zgodnie z dodatkiem 11, zwróconym stanem przetwarzania jest '6985'.
- Jeżeli currentAuthenticatedTime karty jest późniejszy niż data upływu ważności certyfikatu, zwróconym stanem przetwarzania jest '6985'.
- Jeżeli oczekiwane jest ostatnie polecenie łańcucha, karta zwraca '6883'.
- Jeżeli nieprawidłowe parametry są wysyłane w polu danych dotyczących polecenia, karta zwraca '6A80' (także w przypadku, gdy obiekty danych nie są wysyłane w określonej kolejności).
3.5.8 INTERNAL AUTHENTICATE
Polecenie to jest zgodne z normą ISO/IEC 7816-4.
TCS_91 Wszystkie karty do tachografów obsługują to polecenie w DF Tachograph_G1. Polecenie może, ale nie musi być dostępne w MF lub DF Tachograph_G2. W takim przypadku polecenie zostaje zakończone odpowiednim kodem błędu, ponieważ klucz prywatny karty (Card.SK) dla protokołu uwierzytelnienia 1. generacji jest dostępny tylko w DF_Tachograph G1.
Używając polecenia INTERNAL AUTHENTICATE, IFD może uwierzytelnić kartę. Proces uwierzytelnienia opisano w dodatku 11. W procesie tym używa się następujących instrukcji:
TCS_92 Polecenie INTERNAL AUTHENTICATE używa klucza prywatnego karty (wybranego niejawnie) do podpisania danych uwierzytelniających obejmujących K1 (pierwszy element do uzgodnienia kluczy sesyjnych) i RND1, a także używa bieżąco wybranego klucza publicznego (w ostatnim poleceniu MSE) do zaszyfrowania podpisu i utworzenia tokenu uwierzytelniania (dokładniej opisano w dodatku 11).
TCS_93 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | CLA |
| INS | 1 | '88h' | INS |
| P1 | 1 | '00h' | P1 |
| P2 | 1 | '00h' | P2 |
| Lc | 1 | '10h' | długość danych wysłanych do karty |
| #6 - #13 | 8 | 'XX..XXh' | wyzwanie użyte do uwierzytelnienia karty |
| #14 -#21 | 8 | 'XX..XXh' | VU.CHR (zob. dodatek 11) |
| Le | 1 | '80h' | długość danych oczekiwanych z karty |
TCS_94 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| #1-#128 | 128 | 'XX..XXh' | token uwierzytelniania karty (zob. dodatek 11) |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli klucza publicznego nie ma w środowisku zabezpieczeń, zwróconym stanem przetwarzania jest '6A88'.
- Jeżeli klucza prywatnego nie ma w środowisku zabezpieczeń, zwróconym stanem przetwarzania jest '6A88'.
- Jeżeli VU.CHR nie zgadza się z bieżącym identyfikatorem klucza publicznego, zwróconym stanem przetwarzania jest '6A88'.
- Jeżeli wybrany klucz prywatny uznany jest za uszkodzony, zwróconym stanem przetwarzania jest '6400' lub '6581'.
TCS_95 Jeżeli uwierzytelnienie poleceniem INTERNAL AUTHENTICATE jest pomyślne, klucz bieżącej sesji (o ile istnieje) zostaje skasowany i nie jest dalej dostępny. W celu uzyskania nowego klucza sesji konieczne jest pomyślne wykonanie uwierzytelnienia poleceniem EXTERNAL AUTHENTICATE dla mechanizmu uwierzytelnienia 1. generacji.
3.5.9 EXTERNAL AUTHENTICATE
Polecenie to jest zgodne z normą ISO/IEC 7816-4.
Poleceniem EXTERNAL AUTHENTICATE karta może uwierzytelnić IFD. Proces uwierzytelnienia opisano w dodatku 11 dla tachografów 1. generacji i 2. generacji (uwierzytelnienie VU).
TCS_96 Wariant polecenia dla mechanizmu wzajemnego uwierzytelnienia 1. generacji jest obsługiwany jedynie przez aplikację tachograficzną 1. generacji.
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).
TCS_98 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | CLA |
| INS | 1 | '82h' | INS |
| P1 | 1 | '00h' | klucze i algorytmy domniemanie znane |
| P2 | 1 | '00h' | |
| Lc | 1 | 'XXh' | Lc (długość danych wysłanych do karty) |
| #6-#(5+L) | L | 'XX..XXh' | uwierzytelnienie 1. generacji: kryptogram (zob. dodatek 11 część A) uwierzytelnienie 2. generacji: podpis wygenerowany przez IFD (zob. dodatek 11 część B) |
TCS_99 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli CHA bieżąco ustawionego klucza publicznego nie jest konkatenacją AID aplikacji tachograficznej i typu urządzenia VU, zwróconym stanem przetwarzania jest '6F00'.
- Jeżeli bezpośrednio przed poleceniem nie znajduje się polecenie GET CHALLENGE, zwróconym stanem przetwarzania jest '6985'.
Aplikacja tachograficzna 1. generacji może zwracać następujące dodatkowe kody błędów:
- Jeżeli klucza publicznego nie ma w środowisku zabezpieczeń, zwróconym stanem przetwarzania jest '6A88'.
- Jeżeli klucza prywatnego nie ma w środowisku zabezpieczeń, zwróconym stanem przetwarzania jest '6A88'.
- Jeżeli weryfikacja kryptogramu daje zły wynik, zwróconym stanem przetwarzania jest '6688'.
- Jeżeli wybrany klucz prywatny uznany jest za uszkodzony, zwróconym stanem przetwarzania jest '6400' lub '6581'.
Wariant polecenia dla uwierzytelnienia 2. generacji może zwracać następujący dodatkowy kod błędu:
- Jeżeli podpis jest zweryfikowany negatywnie, karta zwraca '6300'.
3.5.10 GENERAL AUTHENTICATE
Polecenie to jest używane na potrzeby protokołu uwierzytelnienia mikroprocesora 2. generacji, określonego w dodatku 11 część B, i jest zgodne z normą ISO/IEC 7816-4.
TCS_100 Polecenie może być wykonywane w MF, DF Tachograph i DF Tachograph_G2 (zob. również TCS_34).
TCS_101 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | '86h' | |
| P1 | 1 | '00h' | klucze i protokół domniemanie znane |
| P2 | 1 | '00h' | |
| Lc | 1 | 'NNh' | Lc: długość następnego pola danych |
| Le | 1 | '00h' | zgodnie ze specyfikacją w normie ISO/IEC 7816-4 |
TCS_102 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| #1-#L | L | '7Ch' + L7C + '81h' + '08h' + 'XX..XXh' + '82h' + L82 + 'XX..XXh' | dane dynamicznego uwierzytelniania kodowane w DER-TLV: nonce i token uwierzytelniania (zob. dodatek 11) |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Karta zwraca '6A80', aby wskazać nieprawidłowe parametry w polu danych.
- Karta zwraca '6982', jeżeli uwierzytelnienie poleceniem EXTERNAL AUTHENTICATE nie zostało pomyślnie wykonane.
Obiekt danych dynamicznego uwierzytelnienia odpowiedzi '7Ch'
- musi być obecny, jeżeli operacja została pomyślnie wykonana, tzn. słowa stanu to '9000',
- musi być nieobecny w przypadku błędu wykonania lub błędu kontroli, tzn. jeśli słowa stanu mieszczą się w zakresie '6400' - '6FFF', oraz
- musi być nieobecny w przypadku ostrzeżenia, tzn. jeśli słowa stanu mieszczą się w zakresie '6200' - '63FF'.
3.5.11 MANAGE SECURITY ENVIRONMENT
Poleceniem tym ustawia się klucz publiczny na potrzeby uwierzytelnienia.
3.5.11.1 Para polecenie - odpowiedź 1. generacji
Polecenie to jest zgodne z normą ISO/IEC 7816-4. Zastosowanie tego polecenia jest ograniczone w porównaniu z poleceniem zdefiniowanym w tej normie.
TCS_103 To polecenie jest obsługiwane jedynie przez aplikację tachograficzną 1. generacji.
TCS_104 Klucz powołany w polu danych MSE pozostaje bieżącym kluczem publicznym aż do następnego prawidłowego polecenia MSE, DF zostaje wybrany lub karta zostaje zresetowana.
TCS_105 Jeżeli powołanego klucza nie ma (już) na karcie, środowisko zabezpieczeń pozostaje niezmienione.
TCS_106 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | CLA |
| INS | 1 | '22h' | INS |
| P1 | 1 | 'C1h' | P1: powołany klucz ważny dla wszystkich czynności kryptograficznych |
| P2 | 1 | 'B6h' | P2 (powołane dane dotyczące podpisu cyfrowego) |
| Lc | 1 | '0Ah' | Lc: długość następnego pola danych |
| #6 | 1 | '83h' | znacznik do powołanego klucza publicznego w przypadkach asymetrycznych |
| #7 | 1 | '08h' | długość referencji klucza (identyfikator klucza) |
| #8-#15 | 8 | 'XX..XXh' | identyfikator klucza określony w dodatku 11 |
TCS_107 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli powołany klucz nie znajduje się na karcie, zwróconym stanem przetwarzania jest '6A88'.
- Jeżeli niektórych oczekiwanych obiektów danych brakuje w formacie bezpiecznej wymiany komunikatów, zwracany jest stan przetwarzania '6987'. To może zdarzyć się, gdy brakuje znacznika '83h'.
- Jeżeli pewne obiekty danych są nieprawidłowe, zwróconym stanem przetwarzania jest '6988'. To może zdarzyć się, gdy długość identyfikatora klucza różna jest od '08h'.
- Jeżeli wybrany klucz uznany jest za uszkodzony, zwróconym stanem przetwarzania jest '6400' lub '6581'.
3.5.11.2 Pary polecenie - odpowiedź 2. generacji
Jeśli chodzi o uwierzytelnienie 2. generacji, karta do tachografu obsługuje następujące MSE: Wersje zbioru poleceń, które są zgodne z normą ISO/IEC 7816-4. Te wersje poleceń nie są obsługiwane na potrzeby uwierzytelnienia 1. generacji.
3.5.11.2.1 MSE:SET AT na potrzeby uwierzytelnienia mikroprocesora
Poniższego polecenia MSE:SET AT używa się do wyboru parametrów na potrzeby uwierzytelnienia mikroprocesora, które jest wykonywane kolejnym poleceniem General Authenticate.
TCS_108 Polecenie może być wykonywane w MF, DF Tachograph i DF Tachograph_G2 (zob. również TCS_34).
TCS_109 Komunikat polecenia MSE:SET AT na potrzeby uwierzytelnienia mikroprocesora
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | '22h' | |
| Bajt | Długość | Wartość | Opis |
| P1 | 1 | '41h' | przydzielone do uwierzytelnienia wewnętrznego |
| P2 | 1 | 'A4h' | Uwierzytelnienie |
| Lc | 1 | 'NNh' | Lc: długość następnego pola danych |
| #6-#(5+L) | L | '80h' + '0Ah' + 'XX..XXh' | Odniesienie do mechanizmu kryptograficznego kodowanego w DER-TLV: identyfikator obiektu uwierzytelnienia mikroprocesora (wyłącznie wartość, znacznik '06h' jest pomijany). Zob. dodatek 1 dla wartości identyfikatorów obiektu; Stosuje się zapis bajtowy. Zob. dodatek 11 zawierający wytyczne dotyczące sposobu wyboru jednego z tych identyfikatorów obiektu. |
3.5.11.2.2 MSE:SET AT na potrzeby uwierzytelnienia VU
Poniższego polecenia MSE:SET AT używa się do wyboru parametrów i kluczy na potrzeby uwierzytelnienia VU, które jest wykonywane kolejnym poleceniem External Authenticate.
TCS_110 Polecenie może być wykonywane w MF, DF Tachograph i DF Tachograph_G2 (zob. również TCS_34).
TCS_111 Komunikat polecenia MSE:SET AT na potrzeby uwierzytelnienia VU
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | '22h' | |
| P1 | 1 | '81h' | przydzielone do uwierzytelnienia zewnętrznego |
| P2 | 1 | 'A4h' | Uwierzytelnienie |
| Lc | 1 | 'NNh' | Lc: długość następnego pola danych |
| #6-#(5+L) | L | '80h' + '0Ah' + 'XX..XXh' | Odniesienie do mechanizmu kryptograficznego kodowanego w DER-TLV: identyfikator obiektu uwierzytelnienia VU (wyłącznie wartość, znacznik '06h' jest pomijany). Zob. dodatek 1 dla wartości identyfikatorów obiektu; Stosuje się zapis bajtowy. Zob. dodatek 11 zawierający wytyczne dotyczące sposobu wyboru jednego z tych identyfikatorów obiektu. |
| '83h' + '08h' + 'XX..XXh' | kodowane w DER-TL odniesienie klucza publicznego VU przez Certificate Holder Reference wymienione w jego certyfikacie | ||
| '91h' + L91 + 'XX..XXh' | kodowana w DER-TLV skompresowana reprezentacja efemerycznego klucza publicznego VU do stosowania podczas uwierzytelnienia mikroprocesora (zob. dodatek 11) |
3.5.11.2.3 MSE:SET DST
Poniższego polecenia MSE:SET DST używa się do ustawienia klucza publicznego
- albo do weryfikacji podpisu, który znajduje się w następnym poleceniu PSO: Verify Digital Signature
- albo do weryfikacji podpisem certyfikatu, który znajduje się w następnym poleceniu PSO: Verify Certificate.
TCS_112 Polecenie może być wykonywane w MF, w DF Tachograph i w DF Tachograph_G2 (zob. również TCS_33).
TCS_113 Komunikat polecenia MSE:SET DST
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | |
| INS | 1 | '22h' | |
| P1 | 1 | '81h' | przydzielone do weryfikacji |
| P2 | 1 | 'B6h' | podpis cyfrowy |
| Lc | 1 | 'NNh' | Lc: długość następnego pola danych |
| #6-#(5+L) | L | '83h' + '08h' + 'XX...XXh' | kodowane w DER-TLV odniesienie klucza publicznego, tj. Certificate Holder Reference w certyfikacie klucza publicznego (zob.dodatek 11) |
Dla wszystkich wersji polecenia struktura komunikatu odpowiedzi i słowa stanu podane są przez:
TCS_114 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'. Protokół został wybrany i zainicjowany.
- '6A80' oznacza nieprawidłowe parametry w polu danych dotyczących polecenia.
- '6A88' oznacza, że przywołane dane (tj. powołany klucz) nie są dostępne.
3.5.12 PSO: HASH
Polecenia tego używa się do przesłania na kartę wyniku obliczeń funkcji skrótu dla niektórych danych. Polecenia tego używa się do weryfikowania podpisów cyfrowych. Wartość skrótu jest tymczasowo zachowywana dla kolejnego polecenia PSO: Verify Digital Signature.
Polecenie to jest zgodne z normą ISO/IEC 7816-8. Zastosowanie tego polecenia jest ograniczone w porównaniu z poleceniem zdefiniowanym w tej normie.
Tylko karta kontrolna jest zobowiązana obsługiwać to polecenie w DF Tachograph i DF Tachograph_G2.
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować tego polecenia. Polecenie może, ale nie musi być dostępne w MF.
Aplikacja karty kontrolnej 1. generacji obsługuje tylko SHA-1.
TCS_115 Tymczasowo zachowana wartość skrótu jest usuwana, jeżeli nowa wartość skrótu zostaje obliczona za pomocą polecenia PSO: HASH, jeżeli DF jest wybrany oraz jeżeli karta do tachografu jest zresetowana.
TCS_116 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | CLA |
| INS | 1 | '2Ah' | wykonanie operacji zabezpieczającej |
| P1 | 1 | '90h' | zwróć kod skrótu |
| P2 | 1 | 'A0h' | Znacznik: pole danych zawiera DO stosowne do obliczania skrótu |
| Lc | 1 | 'XXh' | Lc długość następnego pola danych |
| #6 | 1 | '90h' | znacznik dla kodu skrótu |
| #7 | 1 | 'XXh' | długość L kodu skrótu: '14h' dla aplikacji 1. generacji (zob. dodatek 11 część A) '20h', '30h' lub '40h' dla aplikacji 2. generacji (zob. dodatek 11 część B) |
| #8-#(7+L) | L | 'XX..XXh' | kod skrótu |
TCS_117 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli brakuje niektórych oczekiwanych obiektów danych (jak określone powyżej), zwracany jest stan przetwarzania '6987'. To może zdarzyć się, jeżeli brakuje jednego ze znaczników '90h'.
- Jeżeli pewne obiekty danych są nieprawidłowe, zwróconym stanem przetwarzania jest '6988'. Ten błąd zdarza się, gdy wymagany znacznik jest obecny, ale ma długość różną niż '14h' dla SHA-1, '20h' dla SHA-256, '30h' dla SHA-384, '40h' dla SHA-512 (aplikacja 2. generacji).
3.5.13 PERFORM HASH of FILE
Polecenie to nie jest zgodne z normą ISO/IEC 7816-8. Tym samym bajt CLA w tym poleceniu wskazuje na zastrzeżone użycie polecenia PERFORM SECURITY OPERATION/HASH.
Tylko karta kierowcy i karta warsztatowa są zobowiązane obsługiwać to polecenie w DF Tachograph i DF Tachograph_G2.
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować tego polecenia. Jeżeli przedsiębiorstwo lub karta kontrolna realizują to polecenie, odbywa się to zgodnie z opisem w niniejszym rozdziale.
Polecenie może, ale nie musi być dostępne w MF. W takim przypadku polecenie realizowane jest zgodnie z opisem w niniejszym rozdziale, tzn. nie pozwala na obliczenie wartości skrótu, ale zostaje zakończone odpowiednim kodem błędu.
TCS_118 Polecenia PERFORM HASH of FILE używa się do obliczenia skrótu obszaru danych aktualnie wybranego przezroczystego pliku EF.
TCS_119 Karta do tachografu obsługuje to polecenie jedynie dla EF, które są wymienione w rozdziale 4 pod DF_Tachograph i DF_Tachograph_G2 z poniższym wyjątkiem. Karta do tachografu nie obsługuje polecenia dla EF Sensor_Installation_Data w DF_Tachograph_G2.
TCS_120 Wynik operacji obliczania skrótu przechowywany jest tymczasowo na karcie. Następnie może być używany do otrzymania podpisu cyfrowego pliku przy pomocy polecenia PSO: COMPUTE DIGITAL SIGNATURE.
TCS_121 Tymczasowo zachowana wartość skrótu pliku jest usuwana, jeżeli nowa wartość skrótu zostaje obliczona za pomocą polecenia PSO: Hash of File, jeżeli DF jest wybrany oraz jeżeli karta do tachografu jest zresetowana.
TCS_122 Aplikacja tachograficzna 1. generacji obsługuje SHA-1.
TCS_123 Aplikacja tachograficzna 2. generacji obsługuje SHA-1 i SHA-2 (256 bitów, 384 bity i 512 bitów).
TCS_124 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '80h' | CLA |
| INS | 1 | '2Ah' | wykonanie operacji zabezpieczającej |
| P1 | 1 | '90h' | znacznik: Hash |
| P2 | 1 | 'XXh' | P2: Wskazuje algorytm, jaki ma zostać użyty do haszowania danych dla aktualnie wybranego przezroczystego pliku: '00h' dla SHA-1 '01h' dla SHA-256 '02h' dla SHA-384 '03h' dla SHA-512 |
TCS_125 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli bieżący EF nie dopuszcza tego polecenia (EF Sensor_Installation_Data in DF Tachograph_G2), zwróconym stanem przetwarzania jest '6985'.
- Jeżeli wybrany plik EF uznany jest za uszkodzony (błąd atrybutów pliku lub błąd integralności przechowywanych danych), zwróconym stanem przetwarzania jest '6400' lub '6581'.
- Jeżeli wybrany plik nie jest plikiem przezroczystym, zwróconym stanem przetwarzania jest '6986'.
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE
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, lecz nie mogą mieć klucza podpisu. Dlatego też karty te nie mogą wykonać pomyślnie polecenia, ale kończą je odpowiednim kodem błędu.
Polecenie może, ale nie musi być dostępne w MF. W takim przypadku polecenie 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.
TCS_126 Polecenie to nie oblicza podpisu cyfrowego z obliczonego wcześniej kodu skrótu poleceniem PSO: HASH.
TCS_127 Klucza prywatnego karty, który jest niejawnie znany karcie, używa się do obliczania podpisu cyfrowego.
TCS_128 Aplikacja tachograficzna 1. generacji wykonuje podpis cyfrowy metodą wypełniania zgodną z PKCS1 (zob. dokładniejszy opis w dodatku 11).
TCS_129 Aplikacja tachograficzna 2. generacji oblicza podpis cyfrowy oparty na krzywej eliptycznej (zob. dokładniejszy opis w dodatku 11).
TCS_130 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | CLA |
| INS | 1 | '2Ah' | wykonanie operacji zabezpieczającej |
| P1 | 1 | '9Eh' | zwracany podpis cyfrowy |
| P2 | 1 | '9Ah' | znacznik: pole danych zawiera dane do podpisania. Gdy nie zawarto pola danych, przyjmuje się, że dane te są już na karcie (skrót pliku). |
| Le | 1 | 'NNh' | długość oczekiwanego podpisu |
TCS_131 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| #1-#L | L | 'XX..XXh' | podpis uprzednio obliczonego skrótu |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli niejawnie wybrany klucz prywatny uznany jest za uszkodzony, zwróconym stanem przetwarzania jest '6400' lub '6581'.
- Jeżeli skrót, który został obliczony w ramach poprzedniego polecenia Perform Hash of File nie jest dostępny, zwróconym stanem przetwarzania jest '6985'.
3.5.15 PSO: VERIFY DIGITAL SIGNATURE
Polecenia tego używa się do weryfikowania podpisu cyfrowego dostarczanego jako dane wejściowe, którego skrót jest znany karcie. Algorytm podpisu jest niejawnie znany karcie.
Polecenie to jest zgodne z normą ISO/IEC 7816-8. Zastosowanie tego polecenia jest ograniczone w porównaniu z poleceniem zdefiniowanym w tej normie.
Tylko karta kontrolna jest zobowiązana obsługiwać to polecenie w DF Tachograph i DF Tachograph_G2.
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować tego polecenia. Polecenie może, ale nie musi być dostępne w MF.
TCS_132 Polecenie VERIFY DIGITAL SIGNATURE zawsze używa klucza publicznego wybranego poprzednim poleceniem Manage Security Environment MSE: Set DST i poprzednim kodem skrótu wprowadzonym poleceniem PSO: HASH.
TCS_133 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '00h' | CLA |
| INS | 1 | '2Ah' | wykonanie operacji zabezpieczającej |
| P1 | 1 | '00h' | |
| P2 | 1 | 'A8h' | Znacznik: pole danych zawiera obiekty DO stosowne do weryfikacji |
| Lc | 1 | '83h' | Lc długość następnego pola danych |
| 6 | 1 | '9Eh' | znacznik dla podpisu cyfrowego |
| #7-#8 | 2 | '81 XXh' | Długość podpisu cyfrowego: 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) |
| #9-#(8+L) | L | 'XX..XXh' | treść podpisu cyfrowego |
TCS_134 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- Jeżeli podpis jest zweryfikowany negatywnie, zwróconym stanem przetwarzania jest '6688'. Proces weryfikacji opisano w dodatku 11.
- Jeżeli nie wybrano klucza publicznego, zwróconym stanem przetwarzania jest '6A88'.
- Jeżeli brakuje niektórych oczekiwanych obiektów danych (jak określone powyżej), zwracany jest stan przetwarzania '6987'. To może się zdarzyć, gdy brakuje jednego z wymaganych znaczników.
- Jeżeli kod skrótu nie jest dostępny dla przetwarzania polecenia (w wyniku poprzedniego polecenia PSO: Hash), zwróconym stanem przetwarzania jest '6985'.
- Jeżeli pewne obiekty danych są nieprawidłowe, zwróconym stanem przetwarzania jest '6988'. To może się zdarzyć, gdy długość jednego z wymaganych obiektów danych jest nieprawidłowa.
- Jeżeli wybrany klucz publiczny uznany jest za uszkodzony, zwróconym stanem przetwarzania jest '6400' lub '6581'.
3.5.16 PROCESS DSRC MESSAGE
Polecenia tego używa się do weryfikowania integralności i autentyczności komunikatu DSRC oraz odszyfrowania danych przekazywanych z VU do organu kontrolnego lub warsztatu poprzez łącze DSRC. Karta wyprowadza klucz szyfrujący oraz klucz MAC stosowane do zabezpieczenia komunikatu DSRC zgodnie z opisem w dodatku 11 część B rozdział 13.
Tylko karta kontrolna i karta warsztatowa są zobowiązane obsługiwać to polecenie w DF Tachograph_G2.
Inne rodzaje kart do tachografów mogą, ale nie muszą realizować tego polecenia, lecz nie mogą mieć klucza głównego DSRC. Dlatego też karty te nie mogą wykonać pomyślnie polecenia, ale kończą je odpowiednim kodem błędu.
Polecenie może, ale nie musi być dostępne w MF lub DF Tachograph. W takim przypadku polecenie zostaje zakończone odpowiednim kodem błędu.
TCS_135 Klucz główny DSRC jest dostępny tylko w DF Tachograph_G2, tzn. karta kontrolna i karta warsztatowa obsługują pomyślne wykonanie polecenia tylko w DF Tachograph_G2.
TCS_136 Polecenie służy jedynie do odszyfrowania danych i weryfikacji kryptograficznej sumy kontrolnej, ale nie ma interpretować danych wejściowych.
TCS_137 Kolejność obiektów danych w polu danych dotyczących polecenia jest ustalona w niniejszej specyfikacji.
TCS_138 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '80h' | zastrzeżone CLA |
| INS | 1 | '2Ah' | wykonanie operacji zabezpieczającej |
| P1 | 1 | '80h' | dane reakcji: wartość odkryta |
| P2 | 1 | 'B0h' | dane dotyczące polecenia: wartość odkryta kodowana w BER-TLV i z uwzględnieniem obiektów danych SM |
| Lc | 1 | 'NNh' | Lc długość następnego pola danych |
| Le | 1 | '00h' | zgodnie ze specyfikacją w normie ISO/IEC 7816-4 |
TCS_139 Komunikat odpowiedzi
| Bajt | Długość | Wartość | Opis |
| #1-#L | L | 'XX..XXh' | nieobecny (w przypadku błędu) lub dane odszyfrowane (wypełnienie usunięte) |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
- Jeżeli polecenie zostało pomyślnie wykonane, karta zwraca '9000'.
- '6A80' oznacza nieprawidłowe parametry w polu danych dotyczących polecenia (używane także w przypadku, gdy obiekty danych nie są wysyłane w określonej kolejności).
- '6A88' oznacza, że przywołane dane nie są dostępne, tzn. nie jest dostępny powołany klucz główny DSRC.
- '6900' oznacza, że nie udało się wykonać weryfikacji kryptograficznej sumy kontrolnej lub odszyfrowywania danych.
4. STRUKTURA KART DO TACHOGRAFÓW
W niniejszym punkcie opisano struktury plików na kartach do tachografów przeznaczonych do gromadzenia dostępnych danych.
Nie stanowi to opisu wewnętrznych struktur właściwych dla producenta, takich jak nagłówki plików, ani sposobu gromadzenia elementów danych tylko do użytku wewnętrznego (takich
jak EuropeanPublicKey, CardPrivateKey, TdesSessionKey lub WorkshopCardPin) i manipulowania tymi elementami danych.
TCS 140 Karta do tachografu 2. generacji jest hostem dla pliku głównego MF oraz aplikacji tachograficznej 1. generacji i 2. generacji tego samego typu (np. aplikacje karty kierowcy).
TCS 141 Karta do tachografu musi obsługiwać co najmniej minimalną liczbę rekordów określoną dla odpowiednich aplikacji i nie może obsługiwać więcej rekordów niż maksymalna liczba rekordów określona dla odpowiednich aplikacji.
Minimalne i maksymalne liczby rekordów zostały określone w niniejszym rozdziale dla poszczególnych aplikacji. W przypadku wersji 2 generacji 2 kart kierowcy i warsztatowej aplikacja generacji 1 obsługuje maksymalną liczbę rekordów określoną w TCS_150 i TCS_158.
Jeśli chodzi o warunki zabezpieczenia stosowane w zasadach dostępu w niniejszym rozdziale, zob. rozdział 3.3. Ogólnie tryb dostępu "odczyt" oznacza polecenie READ BINARY z parzystym i (jeżeli obsługiwane) z nieparzystym bajtem INS, z wyjątkiem EF Sensor Installation Data na karcie warsztatowej (zob. TCS 156 i TCS 160). Tryb dostępu "aktualizacja" oznacza polecenie Update Binary z parzystym i (jeżeli obsługiwany) z nieparzystym bajtem INS, a tryb dostępu "wybór" -polecenie SELECT.
4.1. Plik główny MF
TCS 142 Po personalizacji plik główny MF ma następującą, trwałą strukturę plików i zasady dostępu do plików:
Uwaga: The short EF identifier SFID podany jest jako liczba dziesiętna, np. wartość 30 odpowiada zapisowi 11110 w systemie binarnym.
W tabeli zastosowano następujący skrót dla warunku zabezpieczenia:
SC1 ALW OR SM-MAC-G2
TCS_143 Wszystkie struktury plików EF są przezroczyste.
TCS_144 Plik główny (MF) ma następującą strukturę danych:
TCS_145 Plik elementarny EF DIR zawiera następujące obiekty danych dotyczące aplikacji: '61 08 4F 06 FF 54 41 43 48 4F 61 08 4F 06 FF 53 4D 52 44 54'
TCS_146 lik elementarny EF ATR/INFO musi być obecny, jeżeli karta do tachografu wskaże w swojej ATR, że obsługuje pola o rozszerzonej długości. W takim przypadku EF ATR/INFO zawiera obiekt danych z informacjami o rozszerzonej długości (DO'7F66') zgodnie z opisem w normie ISO/IEC 7816-4:2013 pkt 12.7.1.
TCS_147 Plik elementarny EF Extended_Length musi być obecny, jeżeli karta do tachografu wskaże w swojej ATR, że obsługuje pola o rozszerzonej długości. W takim przypadku EF zawiera następujący obiekt danych: '02 01 xx', gdzie wartość "xx" wskazuje, czy pola o rozszerzonej długości są obsługiwane dla protokołu T = 1 lub T = 0.
Wartość '01' oznacza obsługiwanie pola o rozszerzonej długości dla protokołu T = 1.
Wartość '10' oznacza obsługiwanie pola o rozszerzonej długości dla protokołu T = 0.
Wartość '11' oznacza obsługiwanie pola o rozszerzonej długości dla protokołu T = 1 i T = 0.
4.2. Aplikacje karty kierowcy
4.2.1 Aplikacja karty kierowcy 1. generacji
TCS_148 Po personalizacji aplikacja karty kierowcy 1. generacji ma trwałą strukturę plików i zasady dostępu do plików, jak określono poniżej:
W tabeli zastosowano następujące skróty dla warunków bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
TCS_149 Wszystkie struktury plików EF są przezroczyste.
TCS_150 Aplikacja karty kierowcy 1. generacji ma następującą strukturę danych:
TCS_151 W tabeli poniżej podano wartości odnoszące się do tabeli powyżej, wyznaczające minimalne i maksymalne liczby rekordów, które musi stosować struktura danych karty kierowcy dla aplikacji 1. generacji:
| Min. | Maks. |
| n1 | NoOfEventsPerType | 6 | 12 |
| n2 | NoOfFaultsPerType | 12 | 24 |
| n3 | NoOfCardVehicleRecords | 84 | 200 |
| n4 | NoOfCardPlaceRecords | 84 | 112 |
| n6 | CardActivityLengthRange | 5 544 bajty (28 dni* 93 zmiany czynności) | 13 776 bajtów (28 dni* 240 zmian czynności) |
4.2.2 Aplikacja karty kierowcy 2. generacji
TCS_152 PPo personalizacji aplikacja karty kierowcy 2. generacji ma trwałą strukturę plików i zasady dostępu do plików, jak określono poniżej:
Uwagi:
- Krótki identyfikator EF (SFID) podany jest jako liczba dziesiętna, np. wartość 30 odpowiada zapisowi 11110 w systemie binarnym.
- Elementy: EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF VU_Configuration oraz EF Load_Type_Entries są obecne tylko w wersji 2 generacji 2 kart kierowcy.
- cardStructureVersion w EF Application_Identification jest równy {01 01} dla wersji 2 generacji 2 kart kierowcy, natomiast jest równy {01 00} dla wersji 1 generacji 2 kart kierowcy.
| Zasady | dostępu | |
| File ID SFID pliku | Odczyt / Wybór | Aktualizacja |
| '-DF Tachograph_G2 | SCI | |
| -EF Application_Identification '0501h 1 | SCI | NEV |
| -EF CardMA_Certificate 'ClOOh 2 | SCI | NEV |
| -EF CardSignCertificate 'ClOlh 3 | SCI | NEV |
| -EF CA_Certificate 'C108h 4 | SCI | NEV |
| -EF Link_Certificate 'C109h 5 | SCI | NEV |
| -EF Identification '0520h 6 | SCI | NEV |
| - EF Card_Download '050Eh 7 | SCI | SCI |
| -EF Driving_Licence_Info '0521h 10 | SCI | NEV |
| - EF Events_Data '0502h 12 | SCI | SM-MAC-G2 |
| - EF Faults_Data '0503h 13 | SCI | SM-MAC-G2 |
| -EF Driver_Activity_Data '0504h 14 | SCI | SM-MAC-G2 |
| -EF Vehicles_Used '0505h 15 | SCI | SM-MAC-G2 |
| -EF Places '0506h 16 | SCI | SM-MAC-G2 |
| - EF Current_Usage '0507h 17 | SCI | SM-MAC-G2 |
| - EF Control_Activity_Data '0508h 18 | SCI | SM-MAC-G2 |
| -EF Specific_Conditions '0522h 19 | SCI | SM-MAC-G2 |
| -EF VehicleUnits_Used '0523h 20 | SCI | SM-MAC-G2 |
| -EF GNSS_Places '0524h 21 | SCI | SM-MAC-G2 |
| -EF Application_Identification_V2 '0525h 22 | SCI | NEV |
| -EF Places_Authentication '0526h 23 | SCI | SM-MAC-G2 |
| -EF GNSS_Places_Authentication '0527h 24 | SCI | SM-MAC-G2 |
| -EF Border_Crossings '0528h 25 | SCI | SM-MAC-G2 |
| -EF Load_Unioad_Operations '0529h 26 | SCI | SM-MAC-G2 |
| - EF Load_Type_Entries '0530h 27 | SCI | SM-MAC-G2 |
| -EF Vu_Configuration '0540h 30 | SC5/SC1 | SM-MAC-G2 |
W tabeli zastosowano następujące skróty dla warunków bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC5 Dla polecenia Read Binary z parzystym bajtem INS: SM-C-
MAC-G2 AND SM-R-ENC-MAC-G2
Dla polecenia Read Binary z nieparzystym bajtem INS (jeżeli obsługiwane): NEV
TCS_153 Wszystkie struktury plików EF są przezroczyste.
TCS_154 Aplikacja karty kierowcy 2. generacji ma następującą strukturę danych:
TCS_155 W tabeli poniżej podano wartości odnoszące się do tabeli powyżej, wyznaczające minimalne i maksymalne liczby rekordów, które musi stosować struktura danych karty kierowcy dla aplikacji 2. generacji:
| Min. | Maks. |
| n1 | NoOfEventsPerType | 12 | 12 |
| n2 | NoOfFaultsPerType | 24 | 24 |
| n3 | NoOfCardVehicleRecords | 200 | 200 |
| n4 | NoOfCardPlaceRecords | 112 | 112 |
| n6 | CardActivityLengthRange | 13776 bajtów (56 dni * 117 zmian czynności) | 13776 bajtów (56 dni * 117 zmian czynności) |
| n7 | NoOfCardVehicleUnitRecords | 200 | 200 |
| n8 | NoOfGNSSADRecords | 336 | 336 |
| n | NoOfSpecificConditionRecords | 112 | 112 |
| n10 | NoOfBorderCrossingRecords | 1120 | 1120 |
| n11 | NoOfLoadUnloadRecords | 1624 | 1624 |
| n12 | NoOfLoadTypeEntryRecords | 336 | 336 |
| n13 | VuConfigurationLengthRange | 3072 bajty | 3072 bajty |
4.3. Aplikacje karty warsztatowej
4.3.1 Aplikacja karty warsztatowej 1. generacji
TCS_156 Po personalizacji aplikacja karty warsztatowej 1. generacji ma trwałą strukturę plików i zasady dostępu do plików, jak określono poniżej.
W tabeli zastosowano następujące skróty dla warunków bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
SC4 Dla polecenia READ BINARY z parzystym bajtem INS:
(PLAIN-C AND SM-R-ENC-G1) OR (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
TCS_157 Wszystkie struktury plików EF są przezroczyste.
TCS_158 Aplikacja karty warsztatowej 1. generacji ma następującą strukturę danych:
TCS_159 W tabeli poniżej podano wartości odnoszące się do tabeli powyżej, wyznaczające minimalne i maksymalne liczby rekordów, które musi stosować struktura danych karty warsztatowej dla aplikacji 1. generacji:
| Min. | Maks. |
| n1 | NoOfEventsPerType | 3 | 3 |
| n2 | NoOfFaultsPerType | 6 | 6 |
| n3 | NoOfCardVehicleRecords | 4 | 8 |
| n4 | NoOfCardPlaceRecords | 6 | 8 |
| n5 | NoOfCalibrationRecords | 88 | 255 |
| n6 | CardActivityLengthRange | 198 bajtów (1 dzień* 9 3 zmiany czynności) | 492 bajty (1 dzień* 240 zmian czynności) |
4.3.2 Aplikacja karty warsztatowej 2. generacji
TCS_160 Po personalizacji aplikacja karty warsztatowej 2. generacji ma trwałą strukturę plików i zasady dostępu do plików, jak określono poniżej.
Uwagi:
- Krótki identyfikator EF (SFID) podany jest jako liczba dziesiętna, np. wartość 30 odpowiada zapisowi 11110 w systemie binarnym.
- Elementy: EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF Load_Type_Entries, EF VU_Configuration oraz EF Calibration_Add_Data są obecne tylko w wersji 2 generacji 2 kart warsztatowych.
- cardStructureVersion w EF Application_Identification jest równy {01 01} dla wersji 2 generacji 2 kart warsztatowych, natomiast jest równy {01 00} dla wersji 1 generacji 2 kart warsztatowych.
| Zasady dostępu |
| File | ID | SFID | Ode z | Wybór | Aktualiz | |
| pliku | yt | acja |
| LDF Tachograph G2 | SCI | SCI |
| -EF | '0501h | 1 | SCI | SCI | NEV | |
| -EF | CardMA Certificate | 'ClOOh | 2 | SCI | SCI | NEV |
| -EF | CardSignCertificate | 'CIOlh | 3 | SCI | SCI | NEV |
| -EF | CA Certificate | 'C108h | 4 | SCI | SCI | NEV |
| -EF | Link Certificate | 'C109h | 5 | SCI | SCI | NEV |
| -EF | Identification | '0520h | 6 | SCI | SCI | NEV |
| -EF | Card Download | '0509h | 7 | SCI | SCI | SCI |
| -EF | Calibration | '050Ah | 10 | SCI | SCI | SM-MAC- |
| -EF | '050Bh | 11 | SC5 | SM-MAC- | NEV | |
| -EF | Events Data | '0502h | 12 | SCI | SC1 | SM-MAC- |
| -EF | Faults Data | '0503h | 13 | SCI | SCI | SM-MAC- |
| -EF | Driver Activity Data | '0504h | 14 | SCI | SCI | SM-MAC- |
| -EF | Vehicles Used | '0505h | 15 | SCI | SCI | SM-MAC- |
| -EF | Places | '0506h | 16 | SCI | SCI | SM-MAC- |
| -EF | Current Usage | '0507h | 17 | SCI | SCI | SM-MAC- |
| -EF | Control Activity Data | '0508h | 18 | SCI | SCI | SM-MAC- |
| -EF | Specific Conditions | '0522h | 19 | SCI | SCI | SM-MAC- |
| -EF | Vehicleunits Used | '0523h | 20 | SCI | SCI | SM-MAC- |
| -EF | GNSS Places | '0524h | 21 | SCI | SCI | SM-MAC- |
| -EF | '0525h | 22 | SCI | SCI | NEV | |
| -EF | Places Authentication | '0526h | 23 | SCI | SCI | SM-MAC- |
| -EF | '0527h | 24 | SCI | SCI | SM-MAC- | |
| -EF | Border Crossings | '0528h | 25 | SCI | SCI | SM-MAC- |
| -EF | Load Unload Operations | '0529h | 26 | SCI | SCI | SM-MAC- |
| -EF | Load Type Entries | '0530h | 27 | SCI | SCI | SM-MAC- |
| -EF | Calibration Add Data | '0531h | 28 | SCI | SCI | SM-MAC- |
| 1-EF | VU Configuration | '0540h | 30 | SC5 | SCI | SM-MAC- |
W tabeli zastosowano następujące skróty dla warunków bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC5 Dla polecenia Read Binary z parzystym bajtem INS: SM-C-MAC-G2
AND SM-R-ENC-MAC-G2
Dla polecenia Read Binary z nieparzystym bajtem INS (jeżeli obsługiwane): NEV
TCS_161 Wszystkie struktury plików EF są przezroczyste.
TCS_162 Aplikacja karty warsztatowej 2. generacji ma następującą strukturę danych:
TCS_163 W tabeli poniżej podano wartości odnoszące się do tabeli powyżej, wyznaczające minimalne i maksymalne liczby rekordów, które musi stosować struktura danych karty warsztatowej dla aplikacji 2. generacji:
| Min. | Maks. |
| n1 | NoOfEventsPerType | 3 | 3 |
| n2 | NoOfFaultsPerType | 6 | 6 |
| n3 | NoOfCardVehicleRecords | 8 | 8 |
| n4 | NoOfCardPlaceRecords | 8 | 8 |
| n5 | NoOfCalibrationRecords | 255 | 255 |
| Min. | Maks. |
| n6 | CardActivityLengthRange | 492 bajty (1 dzień * 240 zmian czynności) | 492 bajty (1 dzień * 240 zmian czynności) |
| n7 | NoOfCardVehicleUnitRecords | 8 | 8 |
| n8 | NoOfGNSSADRecords | 24 | 24 |
| n9 | NoOfSpecificConditionRecords | 4 | 4 |
| n10 | NoOfBorderCrossingRecords | 4 | 4 |
| n11 | NoOfLoadUnloadRecords | 8 | 8 |
| n12 | NoOfLoadTypeEntryRecords | 4 | 4 |
| n13 | VuConfigurationLengthRange | 3072 bajty | 3072 bajty |
4.4. Aplikacje karty kontrolnej
4.4.1 Aplikacja karty kontrolnej 1. generacji
TCS_164 Po personalizacji aplikacja karty kontrolnej 1. generacji ma trwałą strukturę plików i zasady dostępu do plików, jak określono poniżej.
W tabeli zastosowano następujące skróty dla warunków bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
SC6 EXT-AUT-G1 OR SM-MAC-G1 OR SM-MAC-G2
TCS_165 Wszystkie struktury plików EF są przezroczyste.
TCS_166 Aplikacja karty kontrolnej 1. generacji ma następującą strukturę danych:
TCS_167 W tabeli poniżej podano wartości odnoszące się do tabeli powyżej, wyznaczające minimalne i maksymalne liczby rekordów, które musi stosować struktura danych karty kontrolnej dla aplikacji 1. generacji:
| Min. | Mask. |
| n7 | NoOfControlActivityRecords | 230 | 520 |
4.4.2 Aplikacja karty kontrolnej 2. generacji
TCS_168 Po personalizacji aplikacja karty kontrolnej 2. generacji ma trwałą strukturę plików i zasady dostępu do plików, jak określono poniżej.
Uwagi:
- krótki identyfikator EF (SFID) podany jest jako liczba dziesiętna, np. wartość 30 odpowiada zapisowi 11110 w systemie binarnym.
- Elementy: EF Application_Identification_V2 oraz EF VU_Configuration są obecne tylko w wersji 2 generacji 2 kart kontrolnych,
- cardStructureVersion w EF Application_Identification jest równy {01 01} dla wersji 2 generacji 2 kart kontrolnych, natomiast jest równy {01 00} dla wersji 1 generacji 2 kart kontrolnych.
| Zasady dostępu |
| File | ID | SFID | Odczyt / Wybór | Aktualizacja | |
| pliku |
| 1-DF Tachograph_G2 | SCI |
| -EF Application_Identification | '0501h' | 1 | SCI | NEV | |
| -EF CardMA-Certificate | 'ClOOh' | 2 | SCI | NEV | |
| -EF CA_Certificate | 'C108h' | 4 | SCI | NEV | |
| -EF Link_Certificate | 'C109h' | 5 | SCI | NEV | |
| -EF Identification | '0520h' | 6 | SCI | NEV | |
| -EF Controller_Activity_Data | '050Ch' | 14 | SCI | SM-MAC-G2 | |
| -EF Application_Identification_V2 | '0525h' | 22 | SCI | NEV | |
| -EF VU_Configuration | '0540h' | 30 | SC5/SC1 | SM-MAC-G2 |
W tabeli zastosowano następujące skróty dla warunków bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC5 Dla polecenia Read Binary z parzystym bajtem INS: SM-C-
MAC-G2 AND SM-R-ENC-MAC-G2
Dla polecenia Read Binary z nieparzystym bajtem INS (jeżeli obsługiwane): NEV
TCS_169 Wszystkie struktury plików EF są przezroczyste.
TCS_170 Aplikacja karty kontrolnej 2. generacji ma następującą strukturę danych:
TCS_171 W tabeli poniżej podano wartości odnoszące się do tabeli powyżej, wyznaczające minimalne i maksymalne liczby rekordów, które musi stosować struktura danych karty kontrolnej dla aplikacji 2. generacji:
| Min. | Maks. |
| n7 | NoOfControlActivityRecords | 230 | 520 |
| n13 | VuConfigurationLengthRange | 3072 ajty | 3072 bajty |
4.5. Aplikacje karty firmowej
4.5.1 Aplikacja karty firmowej 1. generacji
TCS_172 Po personalizacji aplikacja karty firmowej 1. generacji ma trwałą strukturę plików i zasady dostępu do plików, jak określono poniżej.
W tabeli zastosowano następujące skróty dla warunków bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
SC6 EXT-AUT-G1 OR SM-MAC-G1 OR SM-MAC-G2
TCS_173 Wszystkie struktury plików EF są przezroczyste.
TCS_174 Aplikacja karty firmowej 1. generacji ma następującą strukturę danych:
TCS_175 W tabeli poniżej podano wartości odnoszące się do tabeli powyżej, wyznaczające minimalne i maksymalne liczby rekordów, które musi stosować struktura danych karty firmowej dla aplikacji 1. generacji:
| Min. | Maks. |
| n8 | NoOfCompanyActivityRecords | 230 | 520 |
4.5.2 Aplikacja karty firmowej 2. generacji
TCS_176 Po personalizacji aplikacja karty firmowej 2. generacji ma trwałą strukturę plików i zasady dostępu do plików, jak określono poniżej.
Uwagi:
- krótki identyfikator EF (SFID) podany jest jako liczba dziesiętna, np. wartość 30 odpowiada zapisowi 11110 w systemie binarnym.
- Elementy: EF Application_Identification_V2 oraz EF VU_Configuration są obecne tylko w wersji 2 generacji 2 kart firmowych,
- cardStructureVersion w EF Application_Identification jest równy {01 01} dla wersji 2 generacji 2 kart firmowych, natomiast jest równy {01 00} dla wersji 1 generacji 2 kart firmowych.
| Zasady dostępu |
| File | ID pliku | SFID | Odczyt / Wybór | Aktualizacja |
| 1-DF Tachograph_G2 | SCI |
| - EF | Application_Identification | '0501h' | 1 | SCI | NEV | |
| - EF | CardMA_Certificate | 'ClOOh' | 2 | SCI | NEV | |
| - EF | CA_Certificate | 'C108h' | 4 | SCI | NEV | |
| - EF | Link_Certificate | 'C109h' | 5 | SCI | NEV | |
| - EF | Identification | '0520h' | 6 | SCI | NEV | |
| - EF | Company_Activity_Data | '050Dh' | 14 | SCI | SM-MAC-G2 | |
| - EF | Application_Identification_V2 | '0525h' | 22 | SCI | NEV | |
| - EF | VU Configuration | '0540h' | 30 | SC5/SC1 | SM-MAC-G2 |
W tabeli zastosowano następujące skróty dla warunków bezpieczeństwa:
SC1 ALW OR SM-MAC-G2
SC5 Dla polecenia Read Binary z parzystym bajtem INS: SM-C-MAC-G2
AND SM-R-ENC-MAC-G2
Dla polecenia Read Binary z nieparzystym bajtem INS (jeżeli obsługiwane): NEV
TCS_177 Wszystkie struktury plików EF są przezroczyste.
TCS_178 Aplikacja karty firmowej 2. generacji ma następującą strukturę danych:
TCS_179 W tabeli poniżej podano wartości odnoszące się do tabeli powyżej, wyznaczające minimalne i maksymalne liczby rekordów, które musi stosować struktura danych karty firmowej dla aplikacji 2. generacji:
| Min. | Maks. |
| n8 | NoOfCompanyActivityRecords | 230 | 520 |
| n13 | VuConfigurationLengthRange | 3072 bajty | 3072 bajty |
Dodatek 3 26
PIKTOGRAMY
PIKTOGRAMY
1. PODSTAWOWE PIKTOGRAMY
2. KOMBINACJE PIKTOGRAMÓW
Uwaga: dodatkowe kombinacje piktogramów używane do tworzenia bloków wydruków lub identyfikatorów zapisów określono w dodatku 4.
Dodatek 4 27
WYDRUKI
WYDRUKI
1. ZASADY OGÓLNE ..........................................................................................................
2. SPECYFIKACJA BLOKÓW DANYCH ..........................................................................
3. SPECYFIKACJE WYDRUKU .........................................................................................
3.1. Wydruk dzienny czynności kierowcy z karty ........................................................................
3.2. Wydruk dzienny czynności kierowcy z VU ..........................................................................
3.3. Wydruk zdarzeń i usterek z karty .........................................................................................
3.4. Wydruk zdarzeń i usterek z VU ...........................................................................................
3.5. Wydruk danych technicznych ..............................................................................................
3.6. Wydruk przekroczenia prędkości ........................................................................................
3.7 Historia włożonych kart .......................................................................................................
1. ZASADY OGÓLNE
Wszystkie wydruki tworzy się poprzez zbudowanie łańcucha różnych bloków danych, w miarę możliwości identyfikowanych identyfikatorem bloku.
Blok danych składa się z jednego lub więcej rekordów, o ile możliwe identyfikowanych identyfikatorem rekordu.
PRT_001 Jeżeli identyfikator bloku bezpośrednio poprzedza identyfikator rekordu, identyfikator rekordu nie jest drukowany.
PRT_002 W przypadku gdy pozycja danych nie jest znana lub nie może być drukowana z uwagi na prawa dostępu do danych, zamiast tej pozycji drukowane są spacje.
PRT_003 Jeżeli zawartość pełnego wiersza nie jest znana lub nie wymaga drukowania, cały wiersz jest pomijany.
PRT_004 Numeryczne pola danych są drukowane z wyrównaniem do prawej strony, ze spacją oddzielającą tysiące i miliony i bez zer z lewej strony.
PRT_005 Pola danych tekstowych są drukowane z wyrównaniem do lewej strony i wypełniane spacjami do długości danej pozycji danych lub w razie potrzeby obcinane do długości danej pozycji. Nazwy i adresy mogą być wydrukowane w dwóch wierszach.
PRT_006 W przypadku łamania wiersza w związku z długością tekstu pierwszym znakiem w nowym wierszu powinien być znak specjalny (kropka w połowie wysokości wiersza: "*").
2. SPECYFIKACJA BLOKÓW DANYCH
W tym rozdziale przyjęto następujące konwencje zapisu formatu:
- Znaki drukowane wytłuszczonym drukiem oznaczają zwykły tekst, który ma być drukowany (wydruk normalną czcionką),
- Znaki normalną czcionką oznaczają zmienne (piktogramy lub dane), które na wydruku są zastępowane odpowiednimi wartościami,
- Nazwy zmiennych wypełniono znakami podkreślenia w celu pokazania długości pozycji danych dostępnej dla zmiennej,
- Daty podawane są w układzie "dd/mm/rrrr" (dzień, miesiąc, rok). Dopuszczalny jest także układ "dd.mm.rrrr".
- Wyrażenie "identyfikacja karty" oznacza następujący zestaw danych: typ karty w postaci kombinacji piktogramów, kod Strony, które wydało kartę, ukośnik prawy i numer karty wraz z numerem wymiany i numerem odnowienia rozdzielonymi spacjami:
- w bloku danych tekst po 'pi=' odnosi się do odpowiedniego piktogramu lub kombinacji piktogramów określonych w dodatku 3,
- w przypadku wydruku po długości i szerokości geograficznej zarejestrowanej pozycji lub po znaczniku czasu, gdy pozycja została określona, 
piktogram wskazuje, że pozycję tę obliczono na podstawie uwierzytelnionych komunikatów nawigacyjnych,
- * dane dostępne tylko w tachografach GEN2 (wszystkie wersje),
- ** dane dostępne tylko w GEN2 wersja 2.PRT_007 W wydrukach korzysta się z następujących bloków danych lub rekordów danych w opisanym poniżej znaczeniu i formacie:
Dodatek 5
WYŚWIETLACZ
WYŚWIETLACZ
- znaki wytłuszczonym drukiem oznaczają odkryty tekst widoczny na wyświetlaczu (są wyświetlane jako normalne znaki),
- znaki normalne oznaczają zmienne (piktogramy lub dane), które na wyświetlaczu zastępowane są przez odpowiadające im wartości:
- dd mm yyyy: dzień, miesiąc, rok,
- hh: godziny,
- mm: minuty,
- D: piktogram czasu trwania,
- EF: kombinacja piktogramów zdarzeń lub usterek,
- O: piktogram trybu pracy.
DIS_001 Tachograf wyświetla dane zgodnie z poniższymi formatami:
| Dane | Format |
| Domyślne informacje na wyświetlaczu |
| Czas miejscowy | hh:mm |
| Tryb pracy | O |
| Informacje dotyczące kierowcy | 1 Dhhhmm "hhhram |
| Informacje dotyczące współkierowcy | 2Dhhhmm |
| Otwarty warunek poza zakresem | OUT |
| Wyświetlanie ostrzeżeń |
| Nadmierny nieprzerwany czas prowadzenia pojazdu | 1ʘ hhhmm "hhhmm |
| Zdarzenie lub usterka | EF |
| Inne wyświetlane informacje |
| Data UTC | UTC dd/mm/yyyylub UTC |
| godzina | hh:mm |
| Nieprzerwany czas prowadzenia pojazdu przez kierowcę i skumulowany czas przerwy | 1ʘ hhhmm "hhhmm |
| Nieprzerwany czas prowadzenia pojazdu przez współkierowcę i skumulowany czas przerwy | 2ʘ hhhmm "hhhmm |
| Skumulowany czas prowadzenia pojazdu przez kierowcę za ubiegły i obecny tydzień | 1ʘ ‖ hhhhmm |
| Skumulowany czas prowadzenia pojazdu przez współkierowcę za ubiegły i obecny tydzień | 2ʘ ‖ hhhhmm |
Dodatek 6
PRZEDNIE ZŁĄCZE KALIBRACJI I POBIERANIA DANYCH
PRZEDNIE ZŁĄCZE KALIBRACJI I POBIERANIA DANYCH
1. SPRZĘT .............................................................................................................................
1.1. Złącze .................................................................................................................................
1.2. Rozmieszczenie styków .......................................................................................................
1.3. Schemat blokowy ...............................................................................................................
2. INTERFEJS POBIERANIA DANYCH .............................................................................
3. INTERFEJS KALIBRACYJNY ........................................................................................
1. SPRZĘT
1.1. Złącze
INT_001 Złącze pobierania danych/kalibracji jest złączem sześciopinowym, dostępnym od strony panelu czołowego bez potrzeby odłączania jakiejkolwiek części tachografu. Złącze musi mieć wymiary zgodne z pokazanymi na rysunku poniżej (wszystkie wymiary w milimetrach):
Na rysunku poniżej pokazano typową sześciopinową wtyczkę złączną:
1.2. Rozmieszczenie styków
INT_002 Rozmieszczenie styków opisuje poniższa tabela:
| Pin | Wyszczególnienie | Uwagi |
| 1 | minus akumulatora | przyłączony do minusa akumulatora pojazdu |
| 2 | przesyłanie danych | K-line (ISO 14230-1) |
| 3 | RxD - pobieranie danych | dane wprowadzane do tachografu |
| 4 | sygnał we/wy | kalibracja |
| 5 | stałe wyjście zasilania | Zakres napięcia musi być taki jak dla zasilania pojazdu minus 3V w celu umożliwienia spadku napięcia na obwodzie ochronnym. Wyjście 40 mA |
| 6 | TxD - pobieranie danych | dane pobierane z tachografu |
1.3. Schemat blokowy
INT_003 Schemat blokowy jest następujący:
2. INTERFEJS POBIERANIA DANYCH
INT_004 Interfejs pobierania danych musi być zgodny z wymaganiami RS232.
INT_005 Interfejs pobierania danych jest skonfigurowany w następujący sposób: jeden bit startowy, 8 bitów danych najmniej znaczących na początku, jeden bit parzystości i jeden bit stopu.
Organizacja bajtu danych
bit startowy: jeden bit na poziomie logicznym 0
bity danych: przesyłane z najmniej znaczącym na początku
bit parzystości: kontrola parzystości;
bit stopu: jeden bit na poziomie logicznym 1
W przypadku przesyłania danych liczbowych złożonych z więcej niż jednego bajtu bajt najbardziej znaczący jest przesyłany pierwszy, a bajt najmniej znaczący - ostatni.
INT_006 Szybkość transmisji danych w bodach regulowana jest w zakresie od 9 600 b/s do 115 200 b/s. Transmisja odbywa się z najwyższą możliwą szybkością, przy czym szybkość początkowa przy inicjowaniu sesji ustawiona jest na 9 600 b/s.
3. Interfejs kalibracyjny
INT_007 Przesyłanie danych musi być zgodne z normą ISO 14230-1 Pojazdy drogowe - Systemy diagnostyczne - Protokół słów kluczowych 2000 - część 1: Warstwa fizyczna (wydanie pierwsze: 1999 r.).
INT_008 Sygnał we/wy musi być zgodny z następującymi wymaganiami elektrycznymi:
| Parametr | Min. | Typowy | Maks. | Uwagi |
| U low (we) | 1,0 V | I = 750 µA | ||
| U high (we) | 4 V | I = 200 µA | ||
| Częstotliwość | 4 kHz | |||
| U low (wy) | 1,0 V | I = 1 mA | ||
| U high (wy) | 4 V | I = 1 mA |
INT_009 Sygnał we/wy musi być zgodny z następującymi przebiegami czasowymi:
Dodatek 7 28
PROTOKOŁY POBIERANIA DANYCH
PROTOKOŁY POBIERANIA DANYCH
1. WPROWADZENIE .....................................................................................................
1.1. Zakres ..........................................................................................................................
1.2. Akronimy i skróty ..........................................................................................................
2. POBIERANIE DANYCH Z VU ..................................................................................
2.1. Procedura pobierania danych .........................................................................................
22.2. Protokół pobierania danych ...........................................................................................
2.2.1 Struktura komunikatu ....................................................................................................
2.2.2 Typy komunikatów ........................................................................................................
2.2.2.1 Start Communication Request (SID 81) .........................................................................
2.2.2.2 Positive Response Start Communication (SID C1) .........................................................
2.2.2.3 Start Diagnostic Session Request (SID 10) ....................................................................
2.2.2.4 Positive Response Start Diagnostic (SID 50) ..................................................................
2.2.2.5 Link Control Service (SID 87) .......................................................................................
2.2.2.6 Link Control Positive Response (SID C7) ......................................................................
2.2.2.7 Request Upload (SID 35) ..............................................................................................
2.2.2.8 Positive Response Request Upload (SID 75) .................................................................
2.2.2.9 Transfer Data Request (SID 36) ....................................................................................
2.2.2.10 Positive Response Transfer Data (SID 76) .....................................................................
2.2.2.11 Request Transfer Exit (SID 37) ......................................................................................
2.2.2.12 Positive Response Request Transfer Exit (SID 77) .........................................................
2.2.2.13 Stop Communication Request (SID 82) .........................................................................
2.2.2.14 Positive Response Stop Communication (SID C2) .........................................................
2.2.2.15 Acknowledge Sub Message (SID 83) ............................................................................
2.2.2.16 Negative Response (SID 7F) .........................................................................................
2.2.3 Przepływ komunikatów .................................................................................................
2.2.4 Przebiegi czasowe .........................................................................................................
2.2.5 Obsługa błędów ............................................................................................................
2.2.5.1 Faza rozpoczęcia komunikacji .......................................................................................
2.2.5.2 Faza komunikacji ..........................................................................................................
2.2.6 Treść komunikatu odpowiedzi .......................................................................................
2.2.6.1 Positive Response Transfer Data Download Interface Version (Pozytywna odpowiedź na żądanie przesłania danych dotyczących wersji interfejsu pobierania danych)
2.2.6.2 Positive Response Transfer Data Overview (Pozytywna odpowiedź na żądanie przesłania danych przeglądowych)
2.2.6.3 Positive Response Transfer Data Activities (Pozytywna odpowiedź na żądanie przesłania danych dotyczących czynności)
2.2.6.4 Positive Response Transfer Data Events and Faults (Pozytywna odpowiedź na żądanie przesłania danych dotyczących zdarzeń i usterek)
2.2.6.5 Positive Response Transfer Data Detailed Speed (Pozytywna odpowiedź na żądanie przesłania danych szczegółowych dotyczących prędkości)
2.2.6.6 Positive Response Transfer Data Technical Data (Pozytywna odpowiedź na żądanie przesłania danych technicznych)
2.3. Gromadzenie plików na ESM ........................................................................................
3. PROTOKÓŁ POBIERANIA DANYCH Z KART DO TACHOGRAFÓW ................
3.1. Zakres ..........................................................................................................................
3.2. Definicje ........................................................................................................................
3.3. Pobieranie danych z karty ..............................................................................................
3.3.1 Sekwencja inicjalizująca ................................................................................................
3.3.2 Sekwencja dla niepodpisanych plików danych ...............................................................
3.3.3 Sekwencja dla podpisanych plików danych ....................................................................
3.3.4 Sekwencja zerowania licznika kalibracji .........................................................................
3.4. Format gromadzenia danych ..........................................................................................
3.4.1 Wprowadzenie ..............................................................................................................
3.4.2 Format pliku ..................................................................................................................
4. POBIERANIE DANYCH Z KARTY DO TACHOGRAFU ZA POŚREDNICTWEM PRZYRZĄDU REJESTRUJĄCEGO ............................................................................
1. WPROWADZENIE
Niniejszy dodatek zawiera procedury stosowane przy pobieraniu danych różnych typów na zewnętrzny nośnik danych (ESM), wraz z protokołami, które muszą być wdrożone w celu zagwarantowania prawidłowego przesyłania danych i pełnej zgodności formatu pobranych danych, tak by umożliwić każdemu kontrolerowi sprawdzenie tych danych oraz sprawdzenie autentyczności i integralności przed przystąpieniem do analizy danych.
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.
1.2. Akronimy i skróty
W niniejszym dodatku używa się następujących skrótów:
AID [Application Identifier] identyfikator aplikacji
ATR [Answer To Reset] reakcja na sprowadzenie do stanu wyjściowego
CS [Checksum byte] bajt sumy kontrolnej
DF [Dedicated File] plik dedykowany
DS_ [Diagnostic Session] sesja diagnostyczna
EF [Elementary File] plik elementarny
ESM [External Storage Medium] zewnętrzny nośnik danych
FID [File Identifier] identyfikator pliku (ID pliku)
FMT [Format Byte] bajt formatu (pierwszy bajt nagłówka komunikatu)
ICC [Integrated Circuit Card] karta z układem scalonym
IDE [Intelligent Dedicated Equipment] inteligentne urządzenie dedykowane:
urządzenie służące do pobierania danych na ESM (np. komputer osobisty)
IFD [Interface Device] urządzenie interfejsu
KWP [Keyword Protocol 2000] protokół słowa kluczowego 2000
LEN [Length Byte] bajt długości (ostatni bajt nagłówka komunikatu)
PPS [Protocol Parameter Selection] wybór parametru protokołu
PSO [Perform Security Operation] wykonanie operacji zabezpieczającej
SID [Service Identifier] identyfikator usługi
SRC [Source byte] bajt źródłowy
TGT [Target Byte] bajt docelowy
TLV [Tag Length Value] wartość długości znacznika
TREP [Transfer Response Parameter] parametr odpowiedzi na przesłanie danych
TRTP [Transfer Request Parameter] parametr żądania przesłania danych
VU [Vehicle Unit] przyrząd rejestrujący
2. POBIERANIE DANYCH Z VU
2.1. Procedura pobierania danych
W celu pobrania danych z VU operator musi wykonać następujące czynności:
- włożyć swoją kartę do tachografu do czytnika karty w VU( * ;
- podłączyć IDE do gniazda pobierania w VU;
- nawiązać połączenie między IDE i VU;
- wybrać w IDE dane do pobrania i wysłać żądanie do VU;
- zamknąć sesję pobierania danych.
2.2. Protokół pobierania danych
Protokół skonstruowany jest zgodnie z zasadą nadrzędny-podległy, gdzie IDE jest urządzeniem nadrzędnym a VU podległym.
Struktura komunikatu, typy komunikatów i przepływ są zasadniczo oparte na Protokole słowa kluczowego 2000 (KWP) (według normy ISO 14230-2 Pojazdy drogowe - Systemy diagnostyczne - Protokół słowa kluczowego 2000 - część 2: Warstwa łącza danych).
Warstwa aplikacji zbudowana jest zasadniczo w oparciu o bieżący projekt normy ISO 14229-1 (Pojazdy drogowe - Systemy diagnostyczne - część 1: Usługi diagnostyczne, wersja 6 z dnia 22 lutego 2001 r.)
2.2.1 Struktura komunikatu
DDP_002 Wszystkie komunikaty wymieniane między IDE i VU mają strukturę złożoną z następujących trzech części:
- nagłówek zawierający bajt formatu (FMT), bajt docelowy (TGT), bajt źródłowy (SRC) i ewentualnie bajt długości (LEN);
- pole danych zawierające bajt identyfikator usługi (SID) i zmienną liczbę bajtów z danymi, w których może być bajt opcjonalnej sesji diagnostycznej (DS_) lub bajt opcjonalnego parametru przesyłania (TRTP lub TREP);
- suma kontrolna zawierająca bajt sumy kontrolnej (CS).
| Nagłówek | Pole danych | Suma kontrolna |
| FMT | TGT | SRC | LEN | SID | DATA | ... | ... | ... | CS |
| 4 bajty | Maks. 255 bajtów | 1 bajt |
Bajty TGT i SRC reprezentują fizyczny adres adresata i źródła komunikatu. Przyjmują one wartości F0 Hex dla IDE i EE Hex dla VU.
Bajt LEN jest długością pola danych.
Bajt sumy kontrolnej jest ośmiobitową sumą serii modulo 256 wszystkich bajtów komunikatu, z wyłączeniem bajtu CS.
Bajty FMT, SID, DS_, TRTP i TREP są zdefiniowane w dalszej części niniejszego dokumentu.
DDP_003 W przypadku gdy dane przesyłane komunikatem są dłuższe niż dysponowane pole danych, komunikat wysyła się w kilku podkomunikatach. Każdy podkomunikat ma nagłówek, te same bajty SID i TREP oraz dwubajtowy licznik podkomunikatu pokazujący liczbę podkomunikatów w całym komunikacie. Aby umożliwić kontrolę błędów i przerwanie przesyłania, IDE potwierdza każdy podkomunikat. IDE może przyjmować podkomunikat, żądać powtórzenia transmisji, żądać od VU powtórzenia transmisji od początku lub przerwania transmisji.
DDP_004 Jeżeli ostatni podkomunikat ma dokładnie 255 bajtów w polu danych, musi być dołączony końcowy podkomunikat z pustym polem danych (z wyjątkiem SID TREP i licznika podkomu-nikatów) w celu pokazania końca komunikatu.
Przykład:
| Nagłówek | SID | TREP | Komunikat | CS |
| 4 bajty | dłuższy niż 255 bajtów |
zostanie przesłany w następujący sposób:
| Nagłówek | SID | TREP | 00 | 01 | Podkomunikat 1 | CS |
| 4 bajty | 255 bajtów | |
| Nagłówek | SID | TREP | 00 | 02 | Podkomunikat 2 | CS |
| 4 bajty | 255 bajtów |
...
| Nagłówek | SID | TREP | xx | yy | Podkomunikat n | CS |
| 4 bajty | mniej niż 255 bajtów |
lub w taki sposób:
| Nagłówek | SID | TREP | 00 | 01 | Podkomunikat 1 | CS |
| 4 bajty | 255 bajtów | |
| Nagłówek | SID | TREP | 00 | 02 | Podkomunikat 2 | CS |
| 4 bajty | 255 bajtów |
...
| Nagłówek | SID | TREP | xx | yy | Podkomunikat n | CS |
| 4 bajty | 255 bajtów |
| Nagłówek | SID | TREP | xx | yy + 1 | CS |
| 4 bajty | 4 bajty |
2.2.2 Typy komunikatów
Protokół komunikacyjny pobierania danych między VU i IDE wymaga wymiany komunikatów 8 różnych typów.
W tabeli poniżej opisano te komunikaty.
| Struktura komunikatu IDE -> <- VU | Maks. 4 bajty Nagłówek | Maks. 255 bajtów Dane | 1 bajt Suma kontrolna | |||||
| FMT | TGT | SRC | LEN | SID | DS_ / TRTP | DATA | CS | |
| Żądanie rozpoczęcia transmisji | 81 | EE | F0 | 81 | E0 | |||
| Pozytywna odpowiedź na żądanie rozpoczęcia transmisji | 80 | F0 | EE | 03 | C1 | EA, 8F | 9B | |
| Żądanie rozpoczęcia sesji diagnostycznej | 80 | EE | F0 | 02 | 10 | |||
| Pozytywna odpowiedź na żądanie rozpoczęcia sesji diagnostycznej | 80 | F0 | EE | 02 | 50 | ■ ' | ||
| Obsługa sterowania łączem | ||||||||
| Weryfikacja szybkości transmisji (etap 1) | ||||||||
| 9 600 Bd | 80 | EE | F0 | 04 | 87 | 01 | 01,01 | EC |
| 19 200 Bd | 80 | EE | F0 | 04 | 87 | 01 | 01,02 | ED |
| 38 400 Bd | 80 | EE | F0 | 04 | 87 | 01 | 01,03 | EE |
| 57 600 Bd 115 200 Bd | 80 80 | EE EE | F0 F0 | 04 04 | 87 87 | 01 01 | 01,04 01,05 | EF F0 |
| Pozytywna odpowiedź na weryfikację szybkości transmisji | 80 | F0 | EE | 02 | C7 | 01 | 28 | |
| Zmiana szybkości transmisji (etap 2) | 80 | EE | F0 | 03 | 87 | 02 | 03 | ED |
| Żądanie wczytywania | 80 | EE | F0 | 0A | 35 | 00,00,00,0- 0,00,FF,FF, FF,FF | 99 | |
| Pozytywna odpowiedź na żądanie wczytywania | 80 | F0 | EE | 03 | 75 | 00,FF | D5 | |
| Żądanie przesłania danych | ||||||||
| Wersja interfejsu pobierania danych | 80 | EE | F0 | 02 | 36 | 00 | 96 | |
| Przegląd | 80 | EE | F0 | 02 | 36 | 01, 21 lub 31 | CS | |
| Czynności | 80 | EE | F0 | 06 | 36 | 02, 22 lub 32 | Data | CS |
| Zdarzenia i usterki | 80 | EE | F0 | 02 | 36 | 03, 23 lub 33 | CS | |
| Szczegółowe dane dotyczące prędkości | 80 | EE | F0 | 02 | 36 | 04 lub 24 | CS | |
| Dane techniczne | 80 | EE | F0 | 02 | 36 | 05, 25 lub 35 | CS | |
| Pobieranie danych z karty | 80 | EE | F0 | 02 lub 03 | 36 | 06 | Szczelina czytnika karty | CS |
| Pozytywna odpowiedź na żądanie przesłania danych | 80 | F0 | EE | Len | 76 | TREP | Dane | CS |
| Żądanie wyjścia z przesyłania danych | 80 | EE | F0 | 01 | 37 | 96 | ||
| Pozytywna odpowiedź na żądanie wyjścia z przesyłania danych | 80 | F0 | EE | 01 | 77 | D6 | ||
| Żądanie zatrzymania transmisji | 80 | EE | F0 | 01 | 82 | E1 | ||
| Pozytywna odpowiedź na żądanie zatrzymania transmisji | 80 | F0 | EE | 01 | C2 | 21 | ||
| Potwierdzenie podkomunikatu | 80 | EE | F0 | Len | 83 | Dane | CS | |
| Odpowiedzi negatywne | ||||||||
| Generalne odrzucenie | 80 | F0 | EE | 03 | 7F | Sid Req | 10 | CS |
| Usługa nieobsługiwana | 80 | F0 | EE | 03 | 7F | Sid Req | 11 | CS |
| Podfunkcja nieobsługiwana | 80 | F0 | EE | 03 | 7F | Sid Req | 12 | CS |
| Nieprawidłowa długość komunikatu | 80 | F0 | EE | 03 | 7F | Sid Req | 13 | CS |
| Nieprawidłowe warunki lub błąd kolejności żądań | 80 | F0 | EE | 03 | 7F | Sid Req | 22 | CS |
| Żądanie poza zakresem | 80 | F0 | EE | 03 | 7F | Sid Req | 31 | CS |
| Ładowanie nieprzyjęte | 80 | F0 | EE | 03 | 7F | Sid Req | 50 | CS |
| Oczekiwanie na odpowiedź | 80 | F0 | EE | 03 | 7F | Sid Req | 78 | CS |
| Brak dostępnych danych | 80 | F0 | EE | 03 | 7F | Sid Req | FA | CS |
Uwagi:
- Sid Req = Sid odpowiadającego żądania.
- TREP = TRTP odpowiadającego żądania.
- Ciemne rubryki oznaczają, że nic nie jest przesyłane.
- Pojęcia »ładowanie« (z perspektywy IDE) używa się zgodnie z normą ISO 14229. Oznacza to samo co pobieranie (z perspektywy VU).
- W tabeli nie pokazano potencjalnych dwubajtowych liczników podkomunikatów.
- »Szczelina« dotyczy numeru szczeliny: '1' (karta w szczelinie czytnika karty kierowcy) albo '2' (karta w szczelinie czytnika karty współkierowcy).
- W przypadku gdy szczelina nie jest określona, VU wybiera szczelinę 1, jeżeli karta jest włożona w tę szczelinę, a szczelinę 2 wybiera tylko wówczas, gdy użytkownik specjalnie ją wybierze.
- TRTP 24 używa się w przypadku żądań pobrania danych z przyrządu rejestrującego generacji 2 (wersja 1 i wersja 2).
- TRTP 00, 31, 32, 33 i 35 używa się w przypadku żądań pobrania danych z przyrządu rejestrującego generacji 2 (wersja 2).
- TRTP 21, 22, 23 i 25 używa się w przypadku żądań pobrania danych z przyrządu rejestrującego generacji 2 (wersja 1).
- TRTP 01 do 05 używa się w przypadku żądań pobrania danych z przyrządu rejestrującego generacji 1. Opcjonalnie mogą być one akceptowane przez przyrząd rejestrujący generacji 2, ale tylko w ramach kontroli kierowców przeprowadzanej przez organ kontrolny spoza UE, przy użyciu karty kontrolnej pierwszej generacji.
- TRTP 11 do 1F są zarezerwowane dla żądań pobrania swoistych dla producenta.
2.2.2.1 Start Communication Request (SID 81)
DDP_005 Komunikat ten wysyła IDE w celu zestawienia łącza komunikacyjnego z VU. Początkowe komunikaty są zawsze wysyłane z szybkością 9 600 bodów (aż do ewentualnej zmiany szybkości transmisji przy wykorzystaniu odpowiedniej obsługi sterowania łączem).
2.2.2.2 Positive Response Start Communication (SID C1)
DDP_006 Komunikat ten wysyła VU w celu przesłania pozytywnej odpowiedzi na żądanie rozpoczęcia transmisji. Komunikat zawiera 2 kluczowe bajty ("EA" "8F") wskazujące, że urządzenie obsługuje protokół z nagłówkiem zawierającym informacje o adresie, źródle i długości.
2.2.2.3 Start Diagnostic Session Request (SID 10)
DDP_007 IDE wysyła komunikat "Start Diagnostic Session Request" w celu zażądania nowej sesji diagnostycznej z VU. Podfunkcja "default session" (81 Hex) wskazuje, że IDE żąda otwarcia standardowej sesji diagnostycznej.
2.2.2.4 Positive Response Star t Diagnostic (SID 50)
DDP_008 VU wysyła komunikat "Positive Response Start Diagnostic" w celu przesłania pozytywnej odpowiedzi na żądanie "Diagnostic Session Request".
2.2.2.5 Link Control Service (SID 87)
DDP_052 IDE używa obsługi sterowania łączem do zainicjowania zmiany szybkości transmisji w bodach. Odbywa się to dwustopniowo. Najpierw IDE proponuje zmianę szybkości transmisji podając nową szybkość (pierwszy krok). Po otrzymaniu pozytywnej odpowiedzi od VU IDE wysyła do VU potwierdzenie zmiany szybkości (drugi krok). Następnie IDE przechodzi na nową szybkość transmisji. Po otrzymaniu potwierdzenia VU przechodzi na nową szybkość transmisji.
2.2.2.6 Link Control Positive Response (SID C7)
DDP_053 VU wysyła odpowiedź "Link Control Positive Response" w celu przesłania pozytywnej odpowiedzi na żądanie "Link Control Service" (pierwszy krok). Należy zwrócić uwagę, że na żądanie potwierdzenia (drugi krok) nie ma odpowiedzi.
2.2.2.7 Request Upload (SID 35)
DDP_009 IDE wysyła komunikat "Request Upload" w celu przekazania VU, że żądana jest operacja pobierania. Aby spełnić wymagania normy ISO14229 przesyłane są szczegółowe informacje dotyczące adresu, wielkości i szczegółów żądanych danych. Ponieważ informacje te nie są znane IDE przed pobieraniem, adres pamięci ustawiony jest na 0, format jest nieszyfrowany i bez kompresji, a wielkość pamięci ustawiona na maksimum.
2.2.2.8 Positive Response Request Upload (SID 75)
DDP_010 VU wysyła komunikat "Positive Response Request Upload", aby wskazać IDE, że VU jest gotowe do pobierania danych. Aby spełnić wymagania normy ISO 14229 ten komunikat pozytywnej odpowiedzi zawiera dane wskazujące IDE, że dalsze komunikaty "Positive Response Transfer Data" będą zawierały maksymalnie 00FF hex bajtów.
2.2.2.9 Transfer Data Request (SID 36)
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ę siedem typów przesyłania danych: Na potrzeby pobierania danych z przyrządu rejestrującego dla każdego typu transferu można użyć dwóch różnych wartości TRTP:
| Typ transferu danych | Wartość TRTP w przypadku żądań pobrania danych z przyrządu rejestrującego typu 1. generacji | Wartość TRTP w przypadku żądań pobrania danych z przyrządu rejestrującego typu 2. generacji (wersja 1) | Wartość TRTP w przypadku żądań pobrania danych z przyrządu rejestrującego typu 2. generacji (wersja 2) |
| Wersja interfejsu pobierania danych | Nieużywany | Nieużywany | 00 |
| Przegląd | 01 | 21 | 31 |
| Czynności o określonej dacie | 02 | 22 | 32 |
| Zdarzenia i usterki | 03 | 23 | 33 |
| Szczegółowe dane dotyczące prędkości | 04 | 24 | 24 |
| Dane techniczne | 05 | 25 | 35 |
| Typ transferu danych | Wartość TRTP |
| Pobieranie danych z karty | 06 |
DDP_054 IDE musi obowiązkowo zażądać przesłania danych przeglądowych (TRTP 01, 21 lub 31) w czasie sesji pobierania, ponieważ tylko to zagwarantuje, że certyfikaty VU są zarejestrowane w pobieranym pliku (i umożliwi weryfikację podpisu cyfrowego).
W trzecim przypadku (TRTP 02, 22 lub 32) w komunikacie żądania przesłania danych znajduje się informacja o dniu kalendarzowym (format TimeReal), dla którego dane mają być pobrane.
2.2.2.10 Positive Response Transfer Data (SID 76)
DDP_012 VU wysyła pozytywną odpowiedź "Positive Response Transfer Data" w odpowiedzi na żądanie "Transfer Data Request". Komunikat zawiera żądane dane z parametrem "Transfer Response Parameter" (TREP) odpowiadającym TRTP żądania.
DDP_055 W pierwszym przypadku (TREP 01, 21 lub 31) VU wyśle dane pomagające operatorowi IDE w wyborze danych, które chce dalej pobrać. Komunikat ten zawiera następujące informacje:
- ś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.
2.2.2.11 Request Transfer Exit (SID 37)
DDP_013 IDE wysyła komunikat "Request Transfer Exit" w celu zawiadomienia VU, że sesja pobierania jest zakończona.
2.2.2.12 Positive Response Request Transfer Exit (SID 77)
DDP_014 VU wysyła komunikat "Positive Response Request Transfer Exit" w celu potwierdzenia otrzymania żądania wyjścia z przesyłania danych "Request Transfer Exit".
2.2.2.13 Stop Communication Request (SID 82)
DDP_015 IDE wysyła komunikat "Stop Communication Request" w celu rozłączenia łącza komunikacyjnego z VU.
2.2.2.14 Positive Response Stop Communication (SID C2)
DDP_016 VU wysyła komunikat "Positive Response Stop Communication" w celu potwierdzenia otrzymania żądania "Stop Communication Request".
2.2.2.15 Acknowledge Sub Message (SID 83)
DDP_017 IDE wysyła potwierdzenie podkomunikatu w celu potwierdzenia otrzymania każdej części komunikatu przesyłanego w kilku podkomunikatach. W polu danych znajduje się SID otrzymany z VU i dwubajtowy kod opisany poniżej:
- MsgC +1 potwierdza prawidłowy odbiór podkomunikatu o numerze MsgC. Żądanie od IDE dla VU wysłania następnego podkomunikatu.
- MsgC wskazuje na problem z odbiorem podkomunikatu o numerze MsgC. Żądanie od IDE dla VU wysłania powtórnie następnego podkomunikatu.
- FFFF żąda zakończenia komunikatu.
IDE może użyć tego do zakończenia transmisji komunikatu z VU z dowolnej przyczyny.
Ostatni podkomunikat komunikatu (bajt LEN < 255) może być potwierdzony przy pomocy dowolnego z tych kodów lub być niepotwierdzony.
Odpowiedziami VU, które składają się z kilku podkomunikatów są:
- Positive Response Transfer Data (SID 76)
2.2.2.16 Negative Response (SID 7F)
DDP_018 VU wysyła komunikat "Negative Response" w odpowiedzi na powyższe komunikaty żądań, gdy VU nie może obsłużyć żądania. Pole danych komunikatu zawiera SID odpowiedzi (7F), SID żądania i kod podający przyczynę negatywnej odpowiedzi. Dozwolone są następujące kody:
- 10 generalne odrzucenie
Czynności nie można wykonać z przyczyny innej niż określone poniżej.
- 11 usługa nieobsługiwana
SID żądania nie jest zrozumiany.
- 12 podfunkcja nieobsługiwana
DS_ lub TRTP żądania nie jest zrozumiany lub nie ma dalszych komunikatów do wysłania.
- 13 nieprawidłowa długość komunikatu
Długość odebranego komunikatu jest nieprawidłowa.
- 22 nieprawidłowe warunki lub błąd kolejności żądań
Żądana usługa nie jest aktywna lub sekwencja komunikatów żądań nie jest prawidłowa.
- 31 żądanie poza zakresem
Żądany rekord dotyczący parametru (pole danych) nie jest ważny.
- 50 ładowanie nieprzyjęte
Żądania nie można obsłużyć (VU w nieodpowiednim trybie pracy lub usterka wewnętrzna VU).
- 78 odpowiedź zawieszona
Czynności nie można zakończyć na czas i VU nie jest gotowe do przyjęcia innego żądania.
- 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 ...).
2.2.3 Przepływ komunikatów
Typowy przepływ komunikatów podczas normalnej procedury pobierania danych wygląda następująco:
2.2.4 Przebiegi czasowe
DDP_019 Podczas normalnej pracy przebiegi czasowe wyglądają tak jak na poniższym rysunku:
Rysunek 1
Przepływ komunikatów, przebiegi czasowe
Gdzie:
P1 = czas między bajtami dla odpowiedzi VU.
P2 = czas między końcem żądania IDE a początkiem odpowiedzi VU, lub między końcem potwierdzenia IDE a początkiem następnej odpowiedzi VU.
P3 = czas między końcem odpowiedzi VU a początkiem nowego żądania IDE, bądź między końcem odpowiedzi VU a początkiem potwierdzenia IDE, bądź między końcem żądania IDE a początkiem nowego żądania IDE, jeżeli VU nie odpowiada.
P4 = czas między bajtami dla żądania IDE.
P5 = przedłużona wartość P3 dla pobierania danych z karty.
Dozwolone wartości przebiegów czasowych pokazano w tabeli poniżej (KWP rozszerzony zestaw parametrów przebiegów czasowych używany w przypadku adresowania fizycznego w celu uzyskania szybszej komunikacji).
| Parametr czasowy | Dolna wartość graniczna (ms) | Górna wartość graniczna (ms) |
| P1 | 0 | 20 |
| P2 | 20 | 1 000 (*) |
| P3 | 10 | 5 000 |
| P4 | 5 | 20 |
| P5 | 10 | 20 minut |
| (*) Jeżeli VU daje negatywną odpowiedź "Negative Response" zawierającą kod o znaczeniu "żądanie odebrane prawidłowo, odpowiedź zawieszona", wartość ta zostaje przedłużona do górnej wartości granicznej P3. |
2.2.5 Obsługa błędów
W przypadku wystąpienia błędu w czasie wymiany komunikatów, schemat przepływu komunikatów zostaje zmodyfikowany zależnie od tego, które urządzenia wykryło błąd, i od komunikatu generującego błąd.
Na rysunkach 2 i 3 pokazano odpowiednio procedury obsługi błędów dla VU i IDE.
2.2.5.1 Faza rozpoczęcia komunikacji
DDP_020 Jeżeli w czasie fazy rozpoczęcia komunikacji IDE wykryje błąd synchronizacji lub strumienia bitowego, to odczekuje okres P3min przed powtórnym wysłaniem żądania.
DDP_021 Jeżeli VU wykryje błąd w sekwencji przychodzącej z IDE, to nie wysyła żadnej odpowiedzi i czeka na następny komunikat "Start Communication Request" przez okres P3 max.
2.2.5.2 Faza komunikacji
W tym przypadku można zdefiniować dwa różne obszary obsługi błędów:
1. VU wykrywa błąd transmisji IDE.
DDP_022 Dla każdego odebranego komunikatu VU wykrywa błędy synchronizacji, błędy formatu bajtowego (np. błędy bitów startu i stopu) i błędy ramki (zła liczba odebranych bajtów, zły bajt sumy kontrolnej).
DDP_023 Jeżeli VU wykryje jeden z powyższych błędów, to nie wysyła odpowiedzi i ignoruje odebrany komunikat.
DDP_024 VU może wykrywać inne błędy formatu lub treści otrzymanego komunikatu (np. komunikat nieobsługiwany), nawet jeżeli długości i sumy kontrolne są prawidłowe; w takim przypadku VU wysyła do IDE komunikat negatywnej odpowiedzi "Negative Response" określający charakter błędu.
Rysunek 2
Obsługa błędów w VU
2. IDE WYKRYWA BŁĄD TRANSMISJI VU
DDP_025 Dla każdego odebranego komunikatu IDE wykrywa błędy synchronizacji, błędy formatu bajtowego (np. błędy bitów startu i stopu) i błędy ramki (zła liczba odebranych bajtów, zły bajt sumy kontrolnej).
DDP_026 IDE wykrywa błędy kolejności, np. nieprawidłowe zwiększenie stanu licznika podkomunikatów w kolejnych komunikatach.
DDP_027 Jeżeli IDE wykrywa błąd lub nie ma odpowiedzi z VU w okresie P2max, wysyła ponownie komunikat żądania, z tym że mogą być maksymalnie trzy transmisje. Na potrzeby tego wykrywania błędów VU traktuje potwierdzenie podkomunikatu jako żądanie.
DDP_028 Przed rozpoczęciem każdej transmisji IDE oczekuje przez okres P3min; okres oczekiwania odmierza się od ostatniego bitu stopu po wykryciu błędu.
Rysunek 3
Obsługa błędów w IDE
2.2.6 Treść komunikatu odpowiedzi
W tym punkcie określono treść pól danych w różnych komunikatach pozytywnej odpowiedzi.
Elementy danych zdefiniowano w dodatku 1 "Słownik danych".
Uwaga: W przypadku pobrań 2. generacji każdy element danych najwyższego poziomu jest reprezentowany przez tablicę rekordów, nawet jeśli zawiera tylko jeden rekord. Tablica rekordów zaczyna się od nagłówka; nagłówek ten zawiera typ rekordu, wielkość rekordu i liczbę rekordów. Tablice rekordów oznaczone są za pomocą "...RecordArray" (z nagłówkiem) w poniższych tabelach.
2.2.6.1 Positive Response Transfer Data Download Interface Version (Pozytywna odpowiedź na żądanie przesłania danych dotyczących wersji interfejsu pobierania danych)
DDP_028a Pole danych w komunikacie »Positive Response Transfer Data Download Interface Version« zawiera następujące dane w określonej tu kolejności pod SID 76 Hex, TREP 00 Hex:
Struktura danych generacji 2, wersja 2 (TREP 00 Hex)
| Element danych | Uwagi | |
| DownloadInterfaceVersion | Generacja i wersja VU: 02,02 Hex dla wersji 2 generacji 2. Nieobsługiwany przez VU generacji 1 oraz wersji 1 generacji 2, które muszą reagować negatywnie (podfunkcja nieobsługiwana, zob. DDP_018) |
2.2.6.2 Positive Response Transfer Data Overview (Pozytywna odpowiedź na żądanie przesłania danych przeglądowych)
DDP_029 Pole danych w komunikacie »Positive Response Transfer Data Over
view« zawiera następujące dane w określonej tu kolejności pod SID 76 Hex, TREP 01, 21 lub 31 Hex, z odpowiednim podziałem na podko- munikaty i licznikami:
Struktura danych generacji 1 (TREP 01 Hex)
| Element danych | Uwagi | |
| MemberStateCertificate | świadectwa bezpieczeństwa VU | |
| VUCertificate | ||
| VehicleldentificationNumber | identyfikacja pojazdu | |
| VehicleRegistrationIdentification | ||
| CurrentDateTime | bieżąca data i godzina VU | |
| VuDownloadablePeriod | okres do pobrania | |
| CardSlotsStatus | typy kart włożonych do VU | |
| VuDownloadActivityData | poprzednie pobranie danych z VU | |
| VuCompanyLocksData | Wszystkie przechowywane blokady firmowe. Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfLocks = 0. | |
| VuControlActivityData | Wszystkie rekordy dotyczące kontroli przechowywane w VU. Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfControls = 0. | |
| Signature | Podpis RSA wszystkich danych (z wyjątkiem certyfikatów), począwszy od elementu VehicleldentificationNumber aż do ostatniego bajtu ostatniego elementu VuControlActivityData. |
Struktura danych generacji 2, wersja 1 (TREP 21 Hex)
| Element danych | Uwagi | |
| MemberStateCertificateRecordArray | certyfikat Strony | |
| VUCertificateRecordArray | certyfikat VU | |
| VehicleIdentificationNumberRecordArray | identyfikacja pojazdu | |
| VehicleRegistrationIdentificationRecordArray | numer rejestracyjny pojazdu | |
| CurrentDateTimeRecordArray | bieżąca data i godzina VU | |
| VuDownloadablePeriodRecordArray | okres do pobrania | |
| CardSlotsStatusRecordArray | typy kart włożonych do VU | |
| VuDownloadActivityDataRecordArray VuCompanyLocksRecordArray | poprzednie pobranie danych z VU Wszystkie przechowywane blokady firmowe. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuControlActivityRecordArray | Wszystkie rekordy dotyczące kontroli przechowywane w VU. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| SignatureRecordArray | Podpis ECC wszystkich poprzednich danych, z wyjątkiem certyfikatów. |
Struktura danych generacji 2, wersja 2 (TREP 31 Hex)
| Element danych | Uwagi | |
| MemberStateCertificateRecordArray | certyfikat Strony | |
| VUCertificateRecordArray | certyfikat VU | |
| VehicleIdentificationNumberRecordArray | identyfikacja pojazdu | |
| VehicleRegistrationNumberRecordArray | numer rejestracyjny pojazdu | |
| CurrentDateTimeRecordArray | bieżąca data i godzina VU | |
| VuDownloadablePeriodRecordArray | okres do pobrania | |
| CardSlotsStatusRecordArray | typy kart włożonych do VU | |
| VuDownloadActivityDataRecordArray | poprzednie pobranie danych z VU | |
| VuCompanyLocksRecordArray | Wszystkie przechowywane blokady firmowe. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuControlActivityRecordArray | Wszystkie rekordy dotyczące kontroli przechowywane w VU. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| SignatureRecordArray | Podpis ECC wszystkich poprzednich danych, z wyjątkiem certyfikatów. |
2.2.6.3 Positive Response Transfer Data Activities (Pozytywna odpowiedź na żądanie przesłania danych dotyczących czynności)
DDP_030 Pole danych w komunikacie »Positive Response Transfer Data Activities« zawiera następujące dane w określonej tu kolejności pod SID 76 Hex, TREP 02, 22 lub 32 Hex, z odpowiednim podziałem na podkomunikaty i licznikami:
Struktura danych generacji 1 (TREP 02 Hex)
| Element danych | Uwagi | |
| TimeReal | data pobieranego dnia | |
| OdometerValueMidnight | stan licznika kilometrów na koniec pobieranego dnia | |
| VuCardlWData | Dane dotyczące cykli wkładania wyjmowania kart. - Jeżeli sekcja ta nie zawiera dostępnych danych, wysyłany jest jedynie noOfVuCardlWRecords = 0. - Jeżeli VuCardlWRecord wykracza poza 00:00 (włożenie karty poprzedniego dnia) lub poza 24:00 (wyjęcie karty następnego dnia), musi pojawiać się w pełni w ciągu dwóch odpowiednich dni. | |
| VuActivityDailyData | Stan szczelin o godzinie 00:00 i zmiany czynności zapisane dla pobieranego dnia. | |
| VuPlaceDailyWorkPeriodData | Dane dotyczące miejsc zapisane dla pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfPlaceRecords = 0. | |
| VuSpecificConditionData | Dane dotyczące stanów szczególnych zapisane dla pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfSpecificConditionRecords=0. | |
| Signature | Podpis RSA wszystkich danych, począwszy od elementu TimeReal aż do ostatniego bajtu ostatniego rekordu dotyczącego stanu szczególnego. |
Struktura danych generacji 2, wersja 1 (TREP 22 Hex)
| Element danych | Uwagi | |
| DateOfDayDownloadedRecordArray | data pobieranego dnia | |
| OdometerValueMidnightRecordArray | stan licznika kilometrów na koniec pobieranego dnia | |
| VuCardlWRecordArray | Dane dotyczące cykli wkładania wyjmowania kart. - Jeżeli ta sekcja nie zawiera dostępnych danych, wysyłany jest nagłówek tablicy z noOfRecords = 0. - Jeżeli VuCardIWRecord wykracza poza 00:00 (włożenie karty poprzedniego dnia) lub poza 24:00 (wyjęcie karty następnego dnia), musi pojawiać się w pełni w ciągu dwóch odpowiednich dni. | |
| VuActivityDailyRecordArray | Stan szczelin o godzinie 00:00 i zmiany czynności zapisane dla pobieranego dnia. | |
| VuPlaceDailyWorkPeriodRecordArray | Dane dotyczące miejsc zapisane dla pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuGNSSADRecordArray | Pozycje GNSS dla pojazdu, jeżeli skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech godzin. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuSpecificConditionRecordArray | Dane dotyczące stanów szczególnych zapisane dla pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords =0. | |
| SignatureRecordArray | Podpis ECC wszystkich poprzednich danych. |
Struktura danych generacji 2, wersja 2 (TREP 32 Hex)
| Element danych | Uwagi | |
| DateOfDayDownloadedRecordArray | data pobieranego dnia | |
| OdometerValueMidnightRecordArray | stan licznika kilometrów na koniec pobieranego dnia | |
| VuCardlWRecordArray | Dane dotyczące cykli wkładania wyjmowania kart. - Jeżeli ta sekcja nie zawiera dostępnych danych, wysyłany jest nagłówek tablicy z noOfRecords = 0. - Jeżeli VuCardlWRecord wykracza poza 00:00 (włożenie karty poprzedniego dnia) lub poza 24:00 (wyjęcie karty następnego dnia), musi pojawiać się w pełni w ciągu dwóch odpowiednich dni. | |
| VuActivityDailyRecordArray | Stan szczelin o godzinie 00:00 i zmiany czynności zapisane dla pobieranego dnia. | |
| VuPlaceDailyWorkPeriodRecordArray | Dane dotyczące miejsc zapisane dla pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuGNSSADRecordArray | Pozycje GNSS dla pojazdu, jeżeli skumulowany czas prowadzenia pojazdu osiągnie wielokrotność trzech godzin. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuSpecificConditionRecordArray | Dane dotyczące stanów szczególnych zapisane dla pobieranego dnia. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords =0. | |
| VuBorderCrossingRecordArray | Przekroczenia granicy dla pobranego dnia. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuLoadUnloadRecordArray | Operacje załadunku/rozładunku dla pobranego dnia. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| SignatureRecordArray | Podpis ECC wszystkich poprzednich danych. |
2.2.6.4 Positive Response Transfer Data Events and Faults (Pozytywna odpowiedź na żądanie przesłania danych dotyczących zdarzeń i usterek)
DDP_031 Pole danych w komunikacie »Positive Response Transfer Data Events and Faults« zawiera następujące dane w określonej tu kolejności pod SID 76 Hex, TREP 03, 23 lub 33 Hex, z odpowiednim podziałem na podkomunikaty i licznikami:
| Struktura danych generacji 1 (TREP 03 Hex) Element danych | Uwagi | |
| VuFaultData | Wszystkie usterki przechowywane lub trwające w VU. Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfVuFaults = 0. | |
| VuEventData | Wszystkie zdarzenia (z wyjątkiem przekroczenia prędkości) przechowywane lub trwające w VU. Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfVuEvents = 0. | |
| VuOverSpeedingControlData | Dane dotyczące ostatniej kontroli przekroczenia prędkości (wartość domyślna w przypadku braku danych). | |
| VuOverSpeedingEventData | Wszystkie zdarzenia dotyczące przekroczenia prędkości przechowywane w VU. Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfVuOverSpeedingEvents = 0. | |
| VuTimeAdjustmentData | Wszystkie zdarzenia dotyczące korekty czasu przechowywane w VU (poza ramami pełnej kalibracji). Jeżeli sekcja jest pusta, wysyłany jest jedynie noOfVuTimeAdjRecords = 0. | |
| Signature | Podpis RSA wszystkich danych, począwszy od noOfVuFaults aż do ostatniego bajtu ostatniego rekordu dotyczącego korekty czasu. |
Struktura danych generacji 2, wersja 1 (TREP 23 Hex)
| Element danych | Uwagi | |
| VuFaultRecordArray | Wszystkie usterki przechowywane lub trwające w VU. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuEventRecordArray | Wszystkie zdarzenia (z wyjątkiem przekroczenia prędkości) przechowywane lub trwające w VU. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuOverSpeedingControlDataRecordArray | Dane dotyczące ostatniej kontroli przekroczenia prędkości (wartość domyślna w przypadku braku danych). | |
| VuOverSpeedingEventRecordArray | Wszystkie zdarzenia dotyczące przekroczenia prędkości przechowywane w VU. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuTimeAdjustmentRecordArray | Wszystkie zdarzenia dotyczące korekty czasu przechowywane w VU (poza ramami pełnej kalibracji). | |
| Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | ||
| SignatureRecordArray | Podpis ECC wszystkich poprzednich danych. |
Struktura danych generacji 2, wersja 2 (TREP 33 Hex)
| Element danych | Uwagi | |
| VuFaultRecordArray | Wszystkie usterki przechowywane lub trwające w VU. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuEventRecordArray | Wszystkie zdarzenia (z wyjątkiem przekroczenia prędkości) przechowywane lub trwające w VU. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuOverSpeedingControlDataRecordArray | Dane dotyczące ostatniej kontroli przekroczenia prędkości (wartość domyślna w przypadku braku danych). | |
| VuOverSpeedingEventRecordArray | Wszystkie zdarzenia dotyczące przekroczenia prędkości przechowywane w VU. Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| VuTimeAdjustmentRecordArray | Wszystkie zdarzenia dotyczące korekty czasu przechowywane w VU (poza ramami pełnej kalibracji). Jeżeli sekcja jest pusta, wysyłany jest nagłówek tablicy z noOfRecords = 0. | |
| SignatureRecordArray | Podpis ECC wszystkich poprzednich danych. |
2.2.6.5 Positive Response Transfer Data Detailed Speed (Pozytywna odpowiedź na żądanie przesłania danych szczegółowych dotyczących prędkości)
DDP_032 Pole danych w komunikacie »Positive Response Transfer Data Detailed Speed« zawiera następujące dane w określonej tu kolejności pod SID 76 Hex, TREP 04 lub 24 Hex, z odpowiednim podziałem na podkomunikaty i licznikami:
Struktura danych generacji 1 (TREP 04 Hex)
| Element danych | Uwagi | |
| VuDetailedSpeedData | Wszystkie szczegółowe dane dotyczące prędkości przechowywane w VU (jeden blok prędkości dla minuty, przez którą pojazd był w ruchu). 60 wartości prędkości na minutę (jedna na sekundę). | |
| Signature | Podpis RSA wszystkich danych, począwszy od noOfSpeedBlocks aż do ostatniego bajtu ostatniego bloku prędkości. |
Struktura danych generacji 2 (TREP 24 Hex)
| Element danych | Uwagi | |
| VuDetailedSpeedBlockRecordArray | Wszystkie szczegółowe dane dotyczące prędkości przechowywane w VU (jeden blok prędkości dla minuty, przez którą pojazd był w ruchu). 60 wartości prędkości na minutę (jedna na sekundę). | |
| SignatureRecordArray | Podpis ECC wszystkich poprzednich danych. |
2.2.6.6 Positive Response Transfer Data Technical Data (Pozytywna odpowiedź na żądanie przesłania danych technicznych)
DDP_033 Pole danych w komunikacie »Positive Response Transfer Data Technical Data« zawiera następujące dane w określonej tu kolejności pod SID 76 Hex, TREP 05, 25 lub 35 Hex, z odpowiednim podziałem na podkomunikaty i licznikami:
Struktura danych generacji 1 (TREP 05 Hex)
| Element danych | Uwagi | |
| VuIdentification | ||
| SensorPaired | ||
| VuCalibrationData | Wszystkie rekordy dotyczące kalibracji przechowywane w VU. | |
| Signature | Podpis RSA wszystkich danych, począwszy od vuManufacturerName aż do ostatniego bajtu ostatniego VuCalibrationRecord. |
Struktura danych generacji 2, wersja 1 (TREP 25 Hex)
| Element danych | Uwagi | |
| VuIdentificationRecordArray | ||
| VuSensorPairedRecordArray | Wszystkie sparowania Stron przechowywane w VU. | |
| VuSensorExternalGNSSCoupledRecordArray | Wszystkie powiązania urządzenia zewnętrznego GNSS przechowywane w VU. | |
| VuCalibrationRecordArray | Wszystkie rekordy dotyczące kalibracji przechowywane w VU. | |
| VuCardRecordArray | Wszystkie dane dotyczące włożenia karty przechowywane w VU. | |
| VulTSConsentRecordArray | ||
| VuPowerSupplyInterruptionRecordArray | ||
| SignatureRecordArray | Podpis ECC wszystkich poprzednich danych. |
Struktura danych generacji 2, wersja 2 (TREP 35 Hex)
| Element danych | Uwagi | |
| VuIdentificationRecordArray | ||
| VuSensorPairedRecordArray | Wszystkie sparowania Stron przechowywane w VU. | |
| VuSensorExternalGNSSCoupledRecordArray | Wszystkie powiązania urządzenia zewnętrznego GNSS przechowywane w VU. | |
| VuCalibrationRecordArray | Wszystkie rekordy dotyczące kalibracji przechowywane w VU. | |
| VuCardRecordArray | Wszystkie dane dotyczące włożenia karty przechowywane w VU. | |
| VuITSConsentRecordArray | ||
| VuPowerSupplyInterruptionRecordArray | ||
| SignatureRecordArray | Podpis ECC wszystkich poprzednich danych. |
2.3. Gromadzenie plików na ESM
DDP_034 Jeżeli sesja pobierania obejmuje przesłanie danych z VU, IDE w jednym fizycznym pliku przechowuje wszystkie dane odebrane z VU w czasie tej sesji przesłane z komunikatami "Positive Response Transfer Data". Dane przechowuje się bez nagłówków komunikatów, liczników podkomunikatów, pustych podkomunikatów i sum kontrolnych, ale wraz z SID i TREP (tylko pierwszego podkomunikatu w przypadku kilku podkomunikatów).
3. PROTOKÓŁ POBIERANIA DANYCH Z KART DO TACHOGRAFÓW
3.1. Zakres
W tym punkcie opisano bezpośrednie pobieranie danych z karty do tachografu do IDE. IDE nie jest częścią bezpiecznego środowiska; dlatego też nie wykonuje się uwierzytelnienia między kartą a IDE.
3.2. Definicje
Sesja pobierania: Sesja pobierania ma miejsce za każdym razem, gdy pobiera się dane z karty ICC. Sesja obejmuje całą procedurę od zainicjowania karty ICC przez IFD do dezaktywowania karty ICC (wyjęcie karty lub następne zainicjowanie).
Podpisany plik danych: Plik z karty ICC. Plik przesyła się do IFD w formie odkrytego tekstu. Na karcie ICC skrót pliku jest obliczany i podpisywany, a podpis jest przesyłany do IFD.
3.3. Pobieranie danych z karty
DDP_035 Pobieranie danych z karty do tachografu obejmuje następujące kroki:
- Pobieranie wspólnych informacji zawartych na karcie w plikach EF ICC oraz IC. Dane te są nieobowiązkowe i nie są chronione podpisem cyfrowym.
- W przypadku kart do tachografów pierwszej i drugiej generacji
- Pobieranie w plikach EF w Tachograph DF:
- Wczytanie plików EF Card_Certificate i CA_Certificate. Dane te nie są chronione podpisem cyfrowym.
Pobranie tych plików jest obowiązkowe dla każdej sesji pobierania.
- Wczytanie plików EF zawierających inne dane aplikacyjne (w DF Tachograph) z wyłączeniem EF Card_Download. Informacje takie są zabezpieczone podpisem cyfrowym przy użyciu wspólnych mechanizmów zabezpieczenia określonych w dodatku 11 część A.
- Pobranie przynajmniej plików EF Application_Identification oraz Identification jest obowiązkowe dla każdej sesji pobierania.
- Przy pobieraniu danych z karty kierowcy obowiązkowe jest pobranie także następujących plików EF:
Events_Data,
Faults_Data,
Driver_Activity_Data,
Vehicles_Used,
Places,
Control_Activity_Data,
Specific_Conditions.
- Wyłącznie w przypadku kart do tachografów drugiej generacji:
- Z wyjątkiem sytuacji gdy pobranie danych z karty kierowcy włożonej do przyrządu rejestrującego odbywa się w trakcie kontroli kierowców przeprowadzanej przez organ kontrolny spoza UE przy użyciu karty kontrolnej pierwszej generacji, pobieranie w plikach EF Tachograph_G2 DF:
- Pobieranie w plikach EF CardSignCertificate, CA_Certificate oraz Link_Certificate. Dane te nie są chronione podpisem cyfrowym.
- Pobranie tych plików jest obowiązkowe dla każdej sesji pobierania.
- Wczytanie plików EF zawierających inne dane aplikacyjne (w Tachograph_G2 DF) z wyłączeniem EF Card_Download. Informacje takie są zabezpieczone podpisem cyfrowym przy użyciu wspólnych mechanizmów zabezpieczenia określonych w dodatku 11 część B.
- Pobranie przynajmniej plików EF: Application_Identification, Application_Identi- fication_V2 (jeżeli występuje) oraz Identification jest obowiązkowe dla każdej sesji pobierania.
- Przy pobieraniu danych z karty kierowcy obowiązkowe jest pobranie także następujących plików EF:
Events_Data,
Faults_Data,
Driver_Activity_Data,
Vehicles_Used,
Places,
Control_Activity_Data,
Specific_Conditions,
VehicleUnits_Used,
GNSS_Places,
Places_Authentication, jeżeli występuje,
GNSS_Places_Authentication, jeżeli występuje,
Border_Crossings, jeżeli występuje,
Load_Unload_Operations, jeżeli występuje,
Load_Type_Entries, jeżeli występuje.
- Przy wczytywaniu danych z karty kierowcy aktualizowana jest data LastCardDownload w pliku EF Card_Download, w DF Tachograph i, w stosownych przypadkach, Tachograph_G2.
- Przy pobieraniu danych z karty warsztatowej zerowany jest licznik kalibracji w pliku EF CardDownload w DF Tachograph i, w stosownych przypadkach, Tacho- graph_G2.
- Przy pobieraniu danych z karty warsztatowej pliki EF Sensor_Installation_Data w DF Tachograph i, w stosownych przypadkach, Tachograph_G2 nie mogą być pobierane.
3.3.1 Sekwencja inicjalizująca
DDP_036 IDE inicjuje następującą sekwencję:
Opcjonalnie można używać protokołu PPS do przełączania na większą szybkość transmisji, o ile ICC obsługuje tę funkcję.
3.3.2 Sekwencja dla niepodpisanych plików danych
DDP_037 Sekwencja pobierania plików elementarnych ICC, IC, Card_Certificate (lub CardSignCertificate) i CA_Certificate jest następująca:
Uwaga 1: przed wybraniem Card_Certificate (lub CardSignCertificate) EF musi być wybrana aplikacja tachograficzna (wybór poprzez AID).
Uwaga 2: wybór i odczyt pliku może być również wykonany za jednym razem przy użyciu polecenia Read Binary z krótkim identyfikatorem EF.
3.3.3 Sekwencja dla podpisanych plików danych
DDP_038 Dla każdego pliku, który pobrany jest z podpisem, stosuje się następującą sekwencję operacji:
| Karta | Kierunek | IDE/IFD | Znaczenie / Uwagi |
| ⇦ | Select File | ||
| OK | ⇨ | ||
| ⇦ | Perform Hash of File | - Oblicza wartość skrótu dla danych wybranego pliku przy pomocy wymaganego algorytmu skrótu zgodnie z dodatkiem 11 część A lub B. Polecenie to nie jest poleceniem ISO. | |
| oblicz skrót pliku i czasowo zachowaj wartość skrótu | |||
| OK | ⇨ | ||
| ⇦ | Read Binary | Jeżeli wielkość danych w pliku jest większa od pojemności bufora czytnika lub karty, polecenie musi być powtarzane aż do odczytania całego pliku. | |
| File Data OK | ⇨ | zapisz odebrane dane na ESM | zgodnie z 3.4 Data storage format |
| ⇦ | PSO: Compute Digital Signature | ||
| wykonaj operację zabezpie- czającą "Compute Digital Signature", używając czasowo zachowaną wartość skrótu | |||
| Signature OK | ⇨ | dołącz dane do poprzednio zapisanych danych na ESM | zgodnie z 3.4 Data storage format |
Uwaga: wybór i odczyt pliku może być również wykonany za jednym razem przy użyciu polecenia Read Binary z krótkim identyfikatorem EF. W tym przypadku EF może być wybrany i odczytany przed zastosowaniem polecenia Perform Hash of File.
3.3.4 Sekwencja zerowania licznika kalibracji
DDP_039 Sekwencja zerowania licznika kalibracji NoOfCalibrationsSinceDownload w pliku EF Card_Download na karcie warsztatowej jest następująca:
Uwaga: wybór i odczyt pliku może być również wykonany za jednym razem przy użyciu polecenia Update Binary z krótkim identyfikatorem EF.
3.4. Format gromadzenia danych
3.4.1 Wprowadzenie
DDP_040 Pobrane dane należy przechowywać w sposób zgodny z następującymi wymaganiami:
- Dane przechowuje się transparentnie. Oznacza to, że przy gromadzeniu należy zachować kolejność bajtów, jak i kolejność bitów w bajcie taką jak przy przesyłaniu z karty.
- Wszystkie pliki pobrane z karty w ramach sesji pobierania przechowuje się w jednym pliku na ESM.
3.4.2 Format pliku
DDP_041 Format pliku jest konkatenacją kilku obiektów TLV.
DDP_042 Znacznikiem pliku EF jest jego identyfikator FID z dodatkiem "00".
DDP_043 Znacznikiem podpisu pliku EF jest identyfikator pliku FID z dodatkiem "01".
DDP_044 Długość podana jest w postaci dwubajtowej wartości. Wartość określa liczbę bajtów w polu wartości. Wartość "FF FF" w polu długości jest zastrzeżona do wykorzystania w przyszłości.
DDP_045 Gdy plik nie jest pobrany, nie zachowuje się żadnych danych dotyczących tego pliku (nie ma znacznika i nie ma zerowej długości).
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 Tachograph lub wspólnych informacji zawartych na karcie | 3 bajty |
| FID (2 bajty) || "01" | Znacznik podpisu pliku EF (FID) w DF Tachograph | 3 bajty |
| FID (2 bajty) || "02" | Znacznik podpisu pliku EF (FID) w DF Tachograph_G2 | 3 bajty |
| FID (2 bajty) || "03" | Znacznik podpisu pliku EF (FID) w DF Tachograph_G2 | 3 bajty |
| xx xx | długość pola wartości | 2 bajty |
Przykładowe dane w pliku pobranym na ESM:
| Znacznik | Długość | Wartość |
| 00 02 00 | 00 11 | - Dane pliku EF ICC |
| Cl 00 00 | 00 C2 | - Dane pliku EF Card_Certificate |
| - ... | ||
| 05 05 00 | 0A 2E | Dane pliku EF Vehicles_Used Tachograph) (w DF |
| 05 05 01 | 00 80 | Podpis pliku EF Vehicles_Used Tachograph) (w DF |
| 05 05 02 | 0A 2E | Dane pliku EF Vehicles_Used Tachograph G2 w DF |
| 05 05 03 | XX XX | Podpis pliku EF Vehicles_Used_Used w DF Tachograph_G2 |
4. POBIERANIE DANYCH Z KARTY DO TACHOGRAFU ZA POŚREDNICTWEM PRZYRZĄDU REJESTRUJĄCEGO
DDP_047 VU musi umożliwiać pobieranie danych z włożonej karty kierowcy do przyłączonego IDE.
DDP_048 IDE wysyła do VU komunikat "Transfer Data Request Card Download" w celu zainicjowania tego trybu (zob. pkt 2.2.2.9).
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".
DDP_050 IDE odzyskuje dane z karty z komunikatu "Positive Response Transfer Data" (usuwając wszystkie nagłówki, SID, TREP, liczniki podkomunikatów i sumy kontrolne) i zachowuje te dane w jednym fizycznym pliku jak opisano w pkt 2.3.
DDP_051 Następnie VU, stosownie do przypadku, aktualizuje plik Control_Activity_Data lub Card_Download na karcie kierowcy.
Dodatek 8 29
PROTOKÓŁ KALIBRACJI
PROTOKÓŁ KALIBRACJI
1. WPROWADZENIE ...........................................................................................................
2. POJĘCIA, DEFINICJE I ODNIESIENIA .........................................................................
3. INFORMACJE OGÓLNE O USŁUGACH .......................................................................
3.1. Dostępne usługi ...................................................................................................................
3.2. Kody odpowiedzi ...............................................................................................................
4. USŁUGI KOMUNIKACYJNE .........................................................................................
4.1. Usługa StartCommunication .................................................................................................
4.2. Usługa StopCommunication .................................................................................................
4.2.1 Opis komunikatu .................................................................................................................
4.2.2 Format komunikatu .............................................................................................................
4.2.3 Definicja parametru .............................................................................................................
4.3. Usługa TesterPresent ...........................................................................................................
4.3.1 Opis komunikatu .................................................................................................................
4.3.2 Format komunikatu .............................................................................................................
5. USŁUGI ZARZĄDZANIA ................................................................................................
5.1. Usługa StartDiagnosticSession .............................................................................................
5.1.1 Opis komunikatu .................................................................................................................
5.1.2 Format komunikatu .............................................................................................................
5.1.3 Definicja parametru .............................................................................................................
5.2. Usługa SecurityAccess ........................................................................................................
5.2.1 Opis komunikatu .................................................................................................................
5.2.2 Format komunikatu - SecurityAccess - requestSeed ............................................................
5.2.3 Format komunikatu - SecurityAccess - sendKey .................................................................
6. USŁUGI PRZESYŁANIA DANYCH ................................................................................
6.1. Usługa ReadDataByIdentifier ...............................................................................................
6.1.1 Opis komunikatu .................................................................................................................
6.1.2 Format komunikatu .............................................................................................................
6.1.3 Definicja parametru .............................................................................................................
6.2. UsługaWriteDataByIdentifier ...............................................................................................
6.2.1 Opis komunikatu .................................................................................................................
6.2.2 Format komunikatu .............................................................................................................
6.2.3 Definicja parametru .............................................................................................................
7. STEROWANIE IMPULSAMI TESTUJĄCYMI - JEDNOSTKA FUNKCJONALNA STEROWANIA WE/WY ..................................................................................................
7.1. Usługa InputOutputControlByIdentifier ................................................................................
7.1.1 Opis komunikatu .................................................................................................................
7.1.2 Format komunikatu .............................................................................................................
7.1.3 Definicja parametru .............................................................................................................
8. USŁUGA ROUTINECONTROL (KOREKTA CZASU)
8.1. Opis komunikatu
8.2. Format komunikatu
9. FORMATY DATARECORDS
9.1. Zakresy przesyłanych parametrów
9.2. Formaty dataRecords
1. WPROWADZENIE
Niniejszy dodatek opisuje wymianę danych między przyrządem rejestrującym a testerem poprzez łącze K-line, które stanowi część interfejsu kalibracyjnego opisanego w dodatku 6. Opisano tu także sterowanie linią sygnałową we/wy w złączu kalibracji.
Komunikaty zestawiające łącze K-line opisano w sekcji 4 "Usługi komunikacyjne".
W niniejszym dodatku wykorzystano koncepcję "sesji" diagnostycznych do ustalania zakresu kontroli K-line dla różnych warunków. Sesją domyślną jest "StandardDiagnosticSession", w której wszystkie dane można odczytać z przyrządu rejestrującego, ale żadnych danych nie można zapisać w przyrządzie rejestrującym.
Wybór sesji diagnostycznej opisano w sekcji 5 "Usługi zarządzania".
Niniejszy dodatek musi być uznany za odnoszący się do obu generacji VU i kart warsztatowych, zgodnie z wymaganiami w zakresie interoperacyjności określonymi w niniejszym rozporządzeniu.
CPR_001 Sesja "ECUProgrammingSession" umożliwia wprowadzanie danych do przyrządu rejestrującego. W przypadku wprowadzania danych kalibracyjnych przyrząd rejestrujący musi pracować w trybie KALIBRACYJNYM.
Przesyłanie danych poprzez K-line opisano w sekcji 6 "Usługi przesyłania danych". Formaty przesyłanych danych opisano szczegółowo w sekcji 8 "Formaty dataRecords".
CPR_002 Sesja "ECUAdjustmentSession" umożliwia wybranie trybu we/wy dla linii sygnałowej we/wy kalibracji poprzez interfejs K-line. Sterowanie linią sygnałową we/wy kalibracji opisano w sekcji 7"Sterowanie impulsami testującymi - jednostka funkcjonalna sterowania we/wy".
CPR_003 W niniejszym dokumencie adres testera określony jest jako "tt". Chociaż mogą być zalecane adresy dla testerów, VU odpowiada prawidłowo na dowolny adres testera. Fizycznym adresem VU jest 0xEE.
2. POJĘCIA, DEFINICJE I ODNIESIENIA
Protokoły, komunikaty i kody błędów oparte są zasadniczo na projekcie normy ISO 14229-1 (Pojazdy drogowe - Systemy diagnostyczne - część 1: Usługi diagnostyczne, wersja 6 z dnia 22 lutego 2001 r.).
Kodowania bajtowego i wartości heksadecymalnych używa się w identyfikatorach usług, żądaniach usług i odpowiedziach oraz parametrach standardowych.
Pojęcie "tester" oznacza urządzenie służące do wprowadzania do VU danych programistycznych/kalibracyjnych.
Pojęcia "klient" i "serwer" oznaczają odpowiednio tester i VU.
Pojęcie ECU oznacza "sterownik elektroniczny" i odnosi się do VU.
Odniesienia:
ISO 14230-2: Pojazdy drogowe - Systemy diagnostyczne - Protokół słowa kluczowego 2000 - część 2: Warstwa łącza danych.
Wydanie pierwsze: 1999.
3. INFORMACJE OGÓLNE O USŁUGACH
3.1. Dostępne usługi
Tabela poniżej zawiera informacje ogólne o usługach, które są dostępne w tachografie i są zdefiniowane w niniejszym dokumencie.
CPR_004 Tabela wskazuje usługi dostępne przy włączonej sesji diagnostycznej.
- Pierwsza kolumna zawiera wykaz dostępnych usług.
- Druga kolumna zawiera numer sekcji w niniejszym dodatku, gdzie usługa jest dokładniej zdefiniowana.
- Trzecia kolumna przypisuje wartości identyfikatora usługi dla komunikatów żądań.
- Czwarta kolumna określa usługi "StandardDiagnosticSession" (SD), których wdrożenie jest wymagane w każdym VU.
- Piąta kolumna określa usługi "ECUAdjustmentSession" (ECUAS), które muszą być wdrożone w celu umożliwienia sterowania linią sygnałową we/wy w złączu kalibracji w panelu czołowym VU.
- Szósta kolumna określa usługi "ECUProgrammingSession" (ECUPS), które muszą być wdrożone w celu umożliwienia programowania parametrów w VU.
Tabela 1
Zestawienie wartości identyfikatorów usług
| Sesje diagnostyczne |
| Nazwa usługi diagnostycznej | Sekcja nr | Wartość SId Req. | SD | ECUAS | ECUPS |
| StartCommunication | 4.1 | 81 | ■ | ■ | ■ |
| StopCommunication | 4.2 | 82 | ■ | ||
| TesterPresent | 4.3 | 3E | ■ | ■ | ■ |
| StartDiagnosticSession | 5.1 | 10 | ■ | ■ | ■ |
| SecurityAccess | 5.2 | 27 | ■ | ■ | ■ |
| ReadDataByIdentifier | 6.1 | 22 | ■ | ■ | ■ |
| WriteDataByIdentifier | 6.2 | 2E | ■ | ||
| InputOutputControlByIdentifier | 7.1 | 2F | ■ | ||
| RoutineControl | 8 | 31 | ■ | ■ |
| ■ Symbol ten oznacza, że usługa jest obowiązkowa w tej sesji diagnostycznej. Brak symbolu oznacza, że usługa nie jest dozwolona w tej sesji diagnostycznej. |
3.2. Kody odpowiedzi
Kody odpowiedzi są zdefiniowane dla każdej usługi.
4. USŁUGI KOMUNIKACYJNE
Niektóre usługi są niezbędne do ustanowienia i utrzymania komunikacji. Nie występują one w warstwie aplikacji. Dostępne usługi wyszczególniono w tabeli poniżej:
Tabela 2
Usługi komunikacyjne
| Nazwa usługi | Wyszczególnienie |
| StartCommunication | Klient żąda rozpoczęcia sesji komunikacyjnej z serwerem(-ami). |
| StopCommunication | Klient żąda zaprzestania bieżącej sesji komunikacyjnej. |
| TesterPresent | Klient wskazuje serwerowi, że jest jeszcze obecny. |
CPR_005 Usługa StartCommunication służy do rozpoczęcia komunikacji. W celu wykonania usługi konieczne jest zainicjowanie komunikacji i ustawienie parametrów odpowiednio dla pożądanego trybu.
4.1. Usługa StartCommunication
CPR_006 Po odebraniu prymitywu wskazania StartCommunication VU sprawdza, czy w obecnych warunkach można zainicjować żądane łącze komunikacyjne. Warunki zezwalające na zainicjowanie łącza komunikacyjnego opisano w normie ISO 14230-2.
CPR_007 Następnie VU wykonuje wszystkie działania niezbędne do zainicjowania łącza komunikacyjnego i wysyła prymityw odpowiedzi StartCommunication z wybranymi parametrami Positive Response.
CPR_008 Jeżeli VU, który jest już zainicjowany (ma otwartą dowolną sesję diagnostyczną), otrzymuje nowe żądanie StartCommunication (np. wskutek usuwania błędu w testerze), żądanie zostanie przyjęte, a VU ponownie zainicjowany.
CPR_009 Jeżeli z jakiejkolwiek przyczyny nie można zainicjować łącza komunikacyjnego, VU pracuje tak jak pracował bezpośrednio przed próbą zainicjowania łącza komunikacyjnego.
CPR_010 Komunikat żądania StartCommunication musi mieć fizyczny adres.
CPR_011 Inicjowanie usług w VU odbywa się metodą "szybkiej inicjalizacji":
- Przed każdą czynnością występuje czas jałowy magistrali.
- Następnie tester wysyła kod inicjujący.
- Wszystkie informacje niezbędne do nawiązania komunikacji zawarte są w odpowiedzi VU. CPR_012 Po zakończeniu inicjalizacji:
- Wszystkie parametry komunikacyjne zostają ustawione na wartości zdefiniowane w tabeli 4 zgodnie z bajtami kluczowymi.
- VU czeka na pierwsze żądanie testera.
- VU znajduje się w domyślnym trybie diagnostycznym, tj. StandardDiagnosticSession.
- Linia sygnałowa we/wy kalibracji jest w stanie domyślnym, tj. w stanie "disabled" (wyłączona). CPR_014 Szybkość transmisji K-line jest ustawiona na 10 400 bodów.
CPR_016 Szybką inicjalizację uruchamia tester, wysyłając kod wywoływania (Wup) przez K-line. Kod rozpoczyna się po czasie jałowym na K-line niskim stanem w czasie Tinil. Tester wysyła pierwszy bit usługi StartCommunication po czasie Twup następującym po pierwszej krawędzi opadającej.
CPR_017 Wartości czasów dla szybkiej inicjalizacji i ogólnie komunikatów podano w tabeli poniżej. Dla czasu jałowego są różne możliwości:
- pierwsza transmisja po włączeniu zasilania, Tidle = 300 ms;
- po zakończeniu usługi StopCommunication, Tidle = P3 min;
- po zatrzymaniu komunikacji wskutek upływu czasu oczekiwania P3 max, Tidle = 0.
Tabela 3
Wartości czasów dla szybkiej inicjalizacji
| Parametr | Wartość min. | Wartość maks. |
| Tinil | 25 ± 1 ms | 24 ms | 26 ms |
| Twup | 50 ± 1 ms | 49 ms | 51 ms |
Tabela 4
Wartości czasów dla komunikacji
| Parametr czasowy | Opis parametru | Dolna granica [ms] | Górna granica [ms] |
| min. | maks. | ||
| P1 | Czas między bajtami dla odpowiedzi VU | 0 | 20 |
| P2 | Czas między żądaniem testera a odpowiedzią VU lub dwiema odpowiedziami VU | 25 | 250 |
| P3 | Czas między końcem odpowiedzi VU a początkiem nowego żądania testera | 55 | 5 000 |
| P4 | Czas między bajtami dla żądania testera | 5 | 20 |
CPR_018 Format komunikatu dla szybkiej inicjalizacji opisano szczegółowo w poniższych tabelach.
Tabela 5
Komunikat StartCommunication Request
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 81 | FMT |
| #2 | Bajt adresu docelowego | EE | TGT |
| #3 | Bajt adresu źródłowego | tt | SRC |
| #4 | StartCommunication Request Service Id | 81 | SCR |
| #5 | Suma kontrolna | 00-FF | CS |
Tabela 6
Komunikat StartCommunication Positive Reponse
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 03 | LEN |
| #5 | StartCommunication Positive Response Service Id | C1 | SCRPR |
| #6 | Bajt kluczowy 1 | EA | KB1 |
| #7 | Bajt kluczowy 2 | 8F | KB2 |
| #8 | Suma kontrolna | 00-FF | CS |
CPR_019 Nie ma negatywnej odpowiedzi na komunikat StartCommunication Request, gdy nie zostanie wysłana pozytywna odpowiedź, VU nie zostaje zainicjowany, nic nie jest przesyłane i VU pozostaje w stanie normalnej pracy.
4.2. Usługa StopCommunication
4.2.1 Opis komunikatu
Celem tej usługi warstwy komunikacji jest zakończenie sesji komunikacyjnej.
CPR_020 Po odebraniu prymitywu wskazania StopCommunication VU sprawdza, czy bieżące warunki pozwalają na zakończenie tej komunikacji. W tym przypadku VU wykonuje wszystkie działania niezbędne do zakończenia sesji komunikacyjnej.
CPR_021 Jeżeli zakończenie sesji komunikacyjnej jest możliwe, VU - przed zakończeniem komunikacji - wysyła prymityw odpowiedzi StopCommunication z wybranymi parametrami Positive Response.
CPR_022 Jeżeli zakończenie sesji komunikacyjnej nie jest możliwe z jakiejkolwiek przyczyny, VU wysyła prymityw odpowiedzi StopCommunication z wybranym parametrem Negative Response.
CPR_023 Jeżeli VU wykryje przekroczenie czasu P3 max, komunikacja zostaje zakończona bez wysyłania żadnego prymitywu odpowiedzi.
4.2.2 Format komunikatu
CPR_024 Formaty komunikatu dla prymitywów StopCommunication opisano szczegółowo w poniższych tabelach.
Tabela 7
Komunikat StopCommunication Request
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | EE | TGT |
| #3 | Bajt adresu źródłowego | tt | SRC |
| #4 | Dodatkowy bajt długości | 01 | LEN |
| #5 | StopCommunication Request Service Id | 82 | SPR |
| #6 | Suma kontrolna | 00-FF | CS |
Tabela 8
Komunikat StopCommunication Positive Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 01 | LEN |
| #5 | StopCommunication Positive Response Service Id | C2 | SPRPR |
| #6 | Suma kontrolna | 00-FF | CS |
Tabela 9
Komunikat StopCommunication Negative Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 03 | LEN |
| #5 | negative Response Service Id | 7F | NR |
| #6 | StopCommunication Request Service Identification | 82 | SPR |
| #7 | responseCode = generalReject | 10 | RC_GR |
| #8 | Suma kontrolna | 00-FF | CS |
4.2.3 Definicja parametru
Ta usługa nie wymaga żadnych definicji parametrów.
4.3. Usługa TesterPresent
4.3.1 Opis komunikatu
Tester używa usługi TesterPresent do wskazania serwerowi, że jeszcze jest obecny, w celu zapobieżenia automatycznemu powrotowi serwera do normalnego trybu pracy i zerwania komunikacji. Usługa ta, wysyłana okresowo, utrzymuje sesję diagnostyczną/komunikacyjną w stanie aktywnym, zerując timer P3 za każdym razem po odebraniu żądania tej usługi.
4.3.2 Format komunikatu
CPR_079 Formaty komunikatu dla prymitywów TesterPresent opisano szczegółowo w poniższych tabelach.
Tabela 10
Komunikat TesterPresent Request
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | EE | TGT |
| #3 | Bajt adresu źródłowego | tt | SRC |
| #4 | Dodatkowy bajt długości | 02 | LEN |
| #5 | TesterPresent Request Service Id | 3E | TP |
| #6 | podfunkcja = responseRequired = | [ tak | 01 | RESPREQ_Y |
| nie ] | 02 | RESPREQ_NO |
| #7 | Suma kontrolna | 00-FF | CS |
CPR_080 Jeżeli parametr responseRequired jest ustawiony na "tak", to serwer odpowie niżej przedstawionym komunikatem pozytywnej odpowiedzi. Jeżeli jest ustawiony na "nie", serwer nie wysyła żadnej odpowiedzi.
Tabela 11
Komunikat TesterPresent Positive Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 01 | LEN |
| #5 | TesterPresent Positive Response Service Id | 7E | TPPR |
| #6 | Suma kontrolna | 00-FF | CS |
CPR_081 Usługa używa następujących kodów negatywnej odpowiedzi:
Tabela 12
Komunikat TesterPresent Negative Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 03 | LEN |
| #5 | negative Response Service Id | 7F | NR |
| #6 | TesterPresent Request Service Identification | 3E | TP |
| #7 | responseCode = [ SubFunctionNotSupported-In-validFormat | 12 | RC_SFNS_IF |
| incorrectMessageLength ] | 13 | RC_IML | |
| #8 | Suma kontrolna | 00-FF | CS |
5. USŁUGI ZARZĄDZANIA
Dostępne usługi wyszczególniono w tabeli poniżej:
Tabela 13
Usługi zarządzania
| Nazwa usługi | Wyszczególnienie |
| StartDiagnosticSession | Klient żąda rozpoczęcia sesji diagnostycznej z VU. |
| SecurityAccess | Klient żąda dostępu do funkcji zastrzeżonych dla uprawnionych użytkowników. |
5.1. Usługa StartDiagnosticSession
5.1.1 Opis komunikatu
CPR_025 Usługa StartDiagnosticSession służy do włączania różnych sesji diagnostycznych w serwerze. Sesja diagnostyczna udostępnia swoisty zestaw usług zgodnie z opisem w Tabeli 17. Sesja może udostępnić producentowi pojazdu usługi swoiste nieobjęte tym dokumentem. Zasady wdrożenia muszą spełniać następujące wymagania:
- W VU aktywna jest zawsze dokładnie jedna sesja diagnostyczna.
- Po włączeniu zasilania VU zawsze uruchamia StandardDiagnosticSession. Jeżeli żadna inna sesja diagnostyczna nie zostanie uruchomiona, wówczas StandardDiagnosticSession pozostaje uruchomiona tak długo, jak włączone jest zasilanie VU.
- Jeżeli jest już uruchomiona sesja diagnostyczna zażądana przez tester, VU wysyła komunikat pozytywnej odpowiedzi.
- Za każdym razem kiedy tester żąda nowej sesji diagnostycznej, VU najpierw wysyła komunikat pozytywnej odpowiedzi StartDiagnosticSession, zanim nowa sesja stanie się aktywna w VU. Jeżeli VU nie może uruchomić żądanej nowej sesji diagnostycznej, to odpowiada komunikatem negatywnej odpowiedzi StartDiagnosticSession i bieżąca sesja jest kontynuowana.
CPR_026 Sesja diagnostyczna może zostać uruchomiona tylko wtedy, gdy nawiązana jest komunikacja między klientem a VU.
CPR_027 Parametry czasowe zdefiniowane w tabeli 4 są aktywne po pomyślnym uruchomieniu sesji StartDiag-nosticSession z parametrem diagnosticSession ustawionym na "StandardDiagnosticSession" w komunikacie żądania, jeżeli poprzednio aktywna była inna sesja diagnostyczna.
5.1.2 Format komunikatu
CPR_028 Formaty komunikatu dla prymitywów StartDiagnosticSession opisano szczegółowo w poniższych tabelach.
Tabela 14
Komunikat StartDiagnosticSession Request
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | EE | TGT |
| #3 | Bajt adresu źródłowego | tt | SRC |
| #4 | Dodatkowy bajt długości | 02 | LEN |
| #5 | StartDiagnosticSession Request Service Id | 10 | STDS |
| #6 | diagnosticSession = [jedna wartość z tabeli 17] | xx | DS_... |
| #7 | Suma kontrolna | 00-FF | CS |
Tabela 15
Komunikat StartDiagnosticSession Positive Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 02 | LEN |
| #5 | StartDiagnosticSession Positive Response Service Id | 50 | STDSPR |
| #6 | diagnosticSession = [ta sama wartość jak dla bajtu #6 w tabeli 14] | xx | DS_... |
| #7 | Suma kontrolna | 00-FF | CS |
Tabela 16
Komunikat StartDiagnosticSession Negative Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 03 | LEN |
| #5 | Negative Response Service Id | 7F | NR |
| #6 | StartDiagnosticSession Request Service Id | 10 | STDS |
| #7 | ResponseCode = [subFunctionNotSupported (a) | 12 | RC_SFNS |
| incorrectMessageLength (b) | 13 | RC_IML | |
| conditionsNotCorrect (c) | 22 | RC_CNC | |
| #8 | Suma kontrolna | 00-FF | CS |
| (a) - wartość wstawiona w bajcie #6 komunikatu żądania nie jest obsługiwana, tzn. nie ma jej w tabeli 17; (b) - długość komunikatu jest nieprawidłowa; (c) - kryteria żądania StartDiagnosticSession nie są spełnione. |
5.1.3 Definicja parametru
CPR_029 Parametr diagnosticSession (DS_) używany jest w usłudze StartDiagnosticSession do wybierania szczególnego zachowania serwera(-ów). W niniejszym dokumencie określone są następujące sesje diagnostyczne:
Tabela 17
Definicja wartości diagnosticSession
| Heks | Wyszczególnienie | Mnemonik |
| 81 | StandardDiagnosticSession Ta sesja diagnostyczna udostępnia wszystkie usługi wyszczególnione w tabeli 1 w kolumnie 4 "SD". Usługi te umożliwiają odczyt danych z serwera (VU). Ta sesja diagnostyczna jest aktywna po pomyślnym zakończeniu inicjacji między klientem (tester) a serwerem (VU). Tę sesję diagnostyczną można zastąpić każdą inną sesją diagnostyczną wyszczególnioną w tej sekcji. | SD |
| 85 | ECUProgrammingSession Ta sesja diagnostyczna udostępnia wszystkie usługi wyszczególnione w tabeli 1 w kolumnie 6 "ECUPS". Usługi te wspomagają programowanie pamięci serwera (VU). Tę sesję diagnostyczną można zastąpić każdą inną sesją diagnostyczną wyszczególnioną w tej sekcji. | ECUPS |
| 87 | ECUAdjustmentSession Ta sesja diagnostyczna udostępnia wszystkie usługi wyszczególnione w tabeli 1 w kolumnie 5 "ECUAS". Usługi te wspomagają sterowania we/wy serwera (VU). Tę sesję diagnostyczną można zastąpić każdą inną sesją diagnostyczną wyszczególnioną w tej sekcji. | ECUAS |
5.2. Usługa SecurityAccess
Zapis danych kalibracyjnych nie jest możliwy w trybie KALIBRACYJNYM. Dodatkowo, oprócz włożenia do VU ważnej karty warsztatowej, niezbędne jest wprowadzenie numeru PIN do VU przed uzyskaniem dostępu do trybu KALIBRACYJNEGO.
Jeżeli VU jest w trybie KALIBRACYJNYM lub KONTROLNYM, dostęp do linii we/wy kalibracji jest również możliwy.
Usługa SecurityAccess umożliwia wprowadzenie numeru PIN i przekazanie testerowi, czy VU jest w trybie KALIBRACYJNYM.
Dopuszcza się wprowadzanie numeru PIN alternatywnymi metodami.
5.2.1 Opis komunikatu
Usługa SecurityAccess zawiera komunikat SecurityAccess "requestSeed", po którym może nastąpić komunikat SecurityAccess "sendKey". Usługa SecurityAccess musi być przeprowadzona po usłudze StartDiagnosticSession.
CPR_033 Tester używa komunikatu SecurityAccess "requestSeed" do sprawdzenia, czy przyrząd rejestrujący jest gotowy do przyjęcia numeru PIN.
CPR_034 Jeżeli przyrząd rejestrujący jest już w trybie KALIBRACYJNYM, odpowiada na żądanie wysyłając "seed" równy 0x0000 przy pomocy usługi SecurityAccess Positive Response.
CPR_035 Jeżeli przyrząd rejestrujący jest gotowy do przyjęcia numeru PIN w celu zweryfikowania go przez kartę warsztatową, odpowiada na żądanie wysyłając "seed" większy niż 0x0000 przy pomocy usługi Securi-tyAccess Positive Response.
CPR_036 Jeżeli przyrząd rejestrujący nie jest gotowy do przyjęcia numeru PIN z testera, albo z tego powodu, że włożona karta warsztatowa nie jest ważna lub nie włożono żadnej karty warsztatowej lub przyrząd rejestrujący oczekuje na wprowadzenie numeru PIN inną metodą, odpowiada na żądanie wysyłając negatywną odpowiedź (Negative Reponse) z kodem odpowiedzi ustawionym na conditionsNotCorrec-tOrRequestSequenceError.
CPR_037 Następnie tester używa ostatecznie komunikatu SecurityAccess "sendKey" do przesłania numeru PIN do przyrządu rejestrującego. Aby karta miała wystarczający czas na przeprowadzenie uwierzytelnienia, VU w celu przedłużenia czasu oczekiwania na odpowiedź używa kodu negatywnej odpowiedzi requestCor-rectlyReceived-ResponsePending. Maksymalny czas oczekiwania na odpowiedź nie może jednak przekraczać 5 minut. Gdy tylko żądana usługa zostaje zakończona, VU wysyła komunikat pozytywnej odpowiedzi lub komunikat negatywnej odpowiedzi z kodem odpowiedzi różnym od tego pierwszego kodu. VU może powtarzać kod negatywnej odpowiedzi requestCorrectlyReceived-ResponsePending aż do zakończenia żądanej usługi i wysłania komunikatu ostatecznej odpowiedzi.
CPR_038 Przyrząd rejestrujący odpowiada na to żądanie przy pomocy usługi SecurityAccess Positive Response jedynie wtedy, gdy jest w trybie KALIBRACYJNYM.
CPR_039 W następujących przypadkach przyrząd rejestrujący odpowiada na to żądanie negatywną odpowiedzią (Negative Reponse) z następującą wartością kodu odpowiedzi:
- subFunctionNot supported: niedozwolony format dla parametru podfunkcji (accessType);
- conditionsNotCorrectOrRequestSequenceError: przyrząd rejestrujący nie jest gotowy do przyjęcia numeru PIN;
- invalidKey: nieprawidłowy numer PIN i nieprzekroczona dozwolona liczba prób sprawdzania numeru PIN;
- exceededNumberOfAttempts: nieprawidłowy numer PIN i przekroczona dozwolona liczba prób sprawdzania numeru PIN;
- generalReject: prawidłowy numer PIN, ale nieudane wzajemne uwierzytelnienie z kartą warsztatową.
5.2.2 Format komunikatu - SecurityAccess - requestSeed
CPR_040 Formaty komunikatu dla prymitywów SecurityAccess "requestSeed" opisano szczegółowo w poniższych tabelach.
Tabela 18
Komunikat SecurityAccess Request- requestSeed
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | EE | TGT |
| #3 | Bajt adresu źródłowego | tt | SRC |
| #4 | Dodatkowy bajt długości | 02 | LEN |
| #5 | SecurityAccess Request Service Id | 27 | SA |
| #6 | accessType - requestSeed | 7D | AT_RSD |
| #7 | Suma kontrolna | 00-FF | CS |
Tabela 19
Komunikat SecurityAccess - requestSeed Positive Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 04 | LEN |
| #5 | SecurityAccess Positive Response Service Id | 67 | SAPR |
| #6 | accessType - requestSeed | 7D | AT_RSD |
| #7 | Seed High | 00-FF | SEEDH |
| #8 | Seed Low | 00-FF | SEEDL |
| #9 | Suma kontrolna | 00-FF | CS |
Tabela 20
Komunikat SecurityAccess Negative Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 03 | LEN |
| #5 | negativeResponse Service Id | 7F | NR |
| #6 | SecurityAccess Request Service Id | 27 | SA |
| #7 | responseCode = [conditionsNotCorrectOrRe-questSequenceError | 22 | RC_CNC |
| incorrectMessageLength] | 13 | RC_IML | |
| #8 | Suma kontrolna | 00-FF | CS |
5.2.3 Format komunikatu - SecurityAccess - sendKey
CPR_041 Formaty komunikatu dla prymitywów SecurityAccess "sendKey" opisano szczegółowo w poniższych tabelach.
Tabela 21
Komunikat SecurityAccess Request - sendKey
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | EE | TGT |
| #3 | Bajt adresu źródłowego | tt | SRC |
| #4 | Dodatkowy bajt długości | m+2 | LEN |
| #5 | SecurityAccess Request Service Id | 27 | SA |
| #6 | accessType - sendKey | 7E | AT_SK |
| #7 do #m +6 | Klucz#1 (najwyższy) | xx | KEY |
| ... | ... | ||
| Klucz #m (niższy, m musi być minimum 4 i maksimum 8) | xx | ||
| #m+7 | Suma kontrolna | 00-FF | CS |
Tabela 22
Komunikat SecurityAccess - sendKey Positive Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 02 | LEN |
| #5 | SecurityAccess Positive Response Service Id | 67 | SAPR |
| #6 | accessType - sendKey | 7E | AT_SK |
| #7 | Suma kontrolna | 00-FF | CS |
Tabela 23
Komunikat SecurityAccess Negative Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 03 | LEN |
| #5 | NegativeResponse Service Id | 7F | NR |
| #6 | SecurityAccess Request Service Id | 27 | SA |
| #7 | ResponseCode = [generalReject | 10 | RC_GR |
| subFunctionNotSupported | 12 | RC_SFNS | |
| incorrectMessageLength | 13 | RC_IML | |
| conditionsNotCorrectOrRe-questSequenceError | 22 | RC_CNC | |
| invalidKey | 35 | RC_IK | |
| exceededNumberOfAttempts | 36 | RC_ENA | |
| requestCorrectlyReceived-Res-ponsePending] | 78 | RC_RCR_RP | |
| #8 | Suma kontrolna | 00-FF | CS |
6. USŁUGI PRZESYŁANIA DANYCH
Dostępne usługi wyszczególniono w tabeli poniżej:
Tabela 24
Usługi przesyłania danych
| Nazwa usługi | Wyszczególnienie |
| ReadDataByIdentifier | Klient żąda przesłania bieżącej wartości rekordu z dostępem poprzez recordDa-taIdentifier. |
| WriteDataByIdentifier | Klient żąda zapisu rekordu z dostępem poprzez recordDataIdentifier. |
6.1. Usługa ReadDataByIdentifier
6.1.1 Opis komunikatu
CPR_050 Klient używa usługi ReadDataByIdentifier do żądania wartości rekordów danych z serwera. Dane są identyfikowane przez recordDataIdentifier. Producent VU odpowiada za spełnienie warunków serwera przy wykonywaniu tej usługi.
6.1.2 Format komunikatu
CPR_051 Formaty komunikatu dla prymitywów ReadDataByIdentifier opisano szczegółowo w poniższych tabelach.
Tabela 25
Komunikat ReadDataByIdentifier Request
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | EE | TGT |
| #3 | Bajt adresu źródłowego | tt | SRC |
| #4 | Dodatkowy bajt długości | 03 | LEN |
| #5 | ReadDataByIdentifier Request Service Id | 22 | RDBI |
| #6 do #7 | recordDataIdentifier = [wartość z tabeli 28] | xxxx | RDI_... |
| #8 | Suma kontrolna | 00-FF | CS |
Tabela 26
Komunikat ReadDataByIdentifier Positive Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | m + 3 | LEN |
| #5 | ReadDataByIdentifier Positive Response Service Id | 62 | RDBIPR |
| #6 i #7 | recordDataIdentifier = [ta sama wartość jak dla bajtów #6 i #7 w tabeli 25] | xxxx | RDI_... |
| #8 do #m + 7 | dataRecord[] = [data#1 | xx | DREC_DATA1 |
| : | : | : | |
| data#m] | xx: | DREC_DATAm | |
| #m+8 | Suma kontrolna | 00-FF | CS |
Tabela 27
Komunikat ReadDataByIdentifier Negative Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 03 | LEN |
| #5 | NegativeResponse Service Id | 7F | NR |
| #6 | ReadDataByIdentifier Request Service Id | 22 | RDBI |
| #7 | ResponseCode= [requestOutOfRange | 31 | RC_ROOR |
| incorrectMessageLength | 13 | RC_IML | |
| conditionsNotCorrect] | 22 | RC_CNC | |
| #8 | Suma kontrolna | 00-FF | CS |
6.1.3 Definicja parametru
CPR_052 Parametr recordDataIdentifier (RDI_) w komunikacie żądania ReadDataByIdentifier wskazuje rekord danych.
CPR_053 Wartości recordDataIdentifier zdefiniowane w tym dokumencie pokazano w tabeli poniżej.
Tabela recordDataIdentifier składa się z pięciu kolumn i wielu wierszy.
- Pierwsza kolumna (Heks) zawiera »wartość heksadecymalną« przypisaną identyfikatorowi recordDataIdentifier z trzeciej kolumny.
- Druga kolumna (Element danych) określa element danych z dodatku 1, na którym oparty jest identyfikator recordDataIdentifier (czasami niezbędne jest przekodowanie).
- Trzecia kolumna (Opis) podaje nazwę odpowiadającego identyfikatora recordDataIdentifier.
- Czwarta kolumna (Prawa dostępu) określa prawa dostępu do tego identyfikatora record- DataIdentifier.
- Piąta kolumna (Mnemonik) podaje mnemonik tego identyfikatora recordDataIdentifier.
Tabela 28
Definicja wartości recordDataIdentifier
| Heks | Element danych | Nazwa recordDataldentifier (zob. format w sekcji 8.2) | Prawa dostępu (Read/Write) | Mnemonik |
| F90B | CurrentDateTime | TimeDate | R/W | RDI_TD |
| F912 | HighResOdometer | HighResolutionTotalVehicle- Distance | R/W | RDI_HRTVD |
| F918 | K-ConstantOfRecordingEquipment | Kfactor | R/W | RDI_KF |
| F91C | L-TyreCircumference | LfactorTyreCircumference | R/W | RDI_LF |
| F91D | W-VehicleCharacteristicConstant | WvehicleCharacteristicFactor | R/W | RDI_WVCF |
| F921 | TyreSize | TyreSize | R/W | RDI_TS |
| F922 | nextCalibrationDate | NextCalibrationDate | R/W | RDI_NCD |
| F92C | SpeedAuthorised | SpeedAuthorised | R/W | RDI_SA |
| F97D | vehicleRegistrationNation | RegisteringMemberState | R/W | RDI_RMS |
| F97E | VehicleRegistrationNumber | VehicleRegistrationNumber | R/W | RDI_ VRN |
| F190 | VehicleldentificationNumber | VIN | R/W | RDI_ VIN |
| F9D0 | SensorSerialNumber | MotionSensorSerialNumber | R | RDI_SSN |
| F9D1 | RemoteCommunicationModuleSerialNumber | RemoteCommunicationFacilitySerialNumber | R | RDI_RCSN |
| F9D2 | SensorGNSSSerialNumber | ExternalGNSSFacilitySerial- Number | R | RDI_GSSN |
| F9D3 | SealDataVu | SmartTachographSealsSerial- Number | R/W | RDI_SDV |
| F9D4 | VuSerialNumber | VuSerialNumber | R | RDI_VSN |
| F9D5 | ByDefaultLoadType | ByDefaultLoadType | R/W | RDI_BDLT |
| F9D6 | TachographCardsGenlSuppression | TachographCardsGenlSup- pression | R/W | RDI_TCG1S |
| F9D7 | VehiclePosition | VehiclePosition | R | RDI_VP |
| F9D8 | LastCalibrationCountry | CalibrationCountry | R | RDI_CC |
CPR_054 Parametr dataRecord (DREC_) używany jest w komunikacie pozytywnej odpowiedzi ReadDataByIden-tifier do dostarczania wartości rekordu danych wskazanego klientowi (testerowi) identyfikatorem recordDataIdentifier. Formaty danych określono w sekcji 8. Można wprowadzić dodatkowe opcjonalne dataRecords użytkownika obejmujące szczególne dane wejściowe, wewnętrzne i wyjściowe VU, ale nie są one zdefiniowane w tym dokumencie.
6.2. UsługaWriteDataByIdentifier
6.2.1 Opis komunikatu
CPR_056 Usługa WriteDataByIdentifier używana jest przez klienta do zapisania wartości rekordu danych w serwerze. Dane są identyfikowane przez recordDataIdentifier. Producent VU odpowiada za spełnienie warunków serwera przy wykonywaniu tej usługi. Aby aktualizować parametry wymienione w tabeli 28, VU musi być w trybie KALIBRACYJNYM.
6.2.2 Format komunikatu
CPR_057 Formaty komunikatu dla prymitywów WriteDataByIdentifier opisano szczegółowo w poniższych tabelach.
Tabela 29
Komunikat WriteDataByIdentifier Request
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | EE | TGT |
| #3 | Bajt adresu źródłowego | tt | SRC |
| #4 | Dodatkowy bajt długości | m+3 | LEN |
| #5 | WriteDataByIdentifier Request Service Id | 2E | WDBI |
| #6 do #7 | recordDataIdentifier = [wartość z tabeli 28] | xxxx | RDI_... |
| #8 do m +7 | dataRecord[] = [data#1 | xx | DREC_DATA1 |
| : | : | : | |
| data#m] | xx | DREC_DATAm | |
| #m+8 | Suma kontrolna | 00-FF | CS |
Tabela 30
Komunikat WriteDataByIdentifier Positive Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 03 | LEN |
| #5 | WriteDataByIdentifier Positive Response Service Id | 6E | WDBIPR |
| #6 do #7 | recordDataIdentifier = [ta sama wartość jak dla bajtów #6 i #7 w tabeli 29] | xxxx | RDI_... |
| #8 | Suma kontrolna | 00-FF | CS |
Tabela 31
Komunikat WriteDataByIdentifier Negative Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 03 | LEN |
| #5 | NegativeResponse Service Id | 7F | NR |
| #6 | WriteDataByIdentifier Request Service Id | 2E | WDBI |
| #7 | ResponseCode= [requestOutOfRange | 31 | RRRRRR |
| incorrectMessageLength | 13 | RC_IML | |
| conditionsNotCorrect] | 22 | RC_CNC | |
| #8 | Suma kontrolna | 00-FF | CS |
6.2.3 Definicja parametru
Parametr recordDataIdentifier (RDI_) zdefiniowano w tabeli 28.
Parametr dataRecord (DREC_) używany jest w komunikacie żądania WriteDataByIdentifier do dostarczenia wartości rekordu danych wskazanego serwerowi (VU) przez recordDataIdentifier. Formaty danych określono w sekcji 8.
7. STEROWANIE IMPULSAMI TESTUJĄCYMI - JEDNOSTKA FUNKCJONALNA STEROWANIA WE/WY
Dostępne usługi wyszczególniono w tabeli poniżej:
Tabela 32
Jednostka funkcjonalna sterowania we/wy
| Nazwa usługi | Wyszczególnienie |
| InputOutputControlByIdentifier | Klient żąda sterowania we/wy specyficznego dla serwera. |
7.1. Usługa InputOutputControlByIdentifier
7.1.1 Opis komunikatu
Przez przednie gniazdo zestawione jest połączenie, które umożliwia sterowanie lub monitorowanie impulsów testowych przy pomocy odpowiedniego testera.
CPR_058 Tę linię sygnałową we/wy kalibracji można skonfigurować poleceniem K-line, posługując się usługą InputOutputControlByIdentifier w celu wybrania dla linii wymaganej funkcji wejścia lub wyjścia. Linia może przyjmować następujące stany:
- disabled (wyłączona);
- speedSignalInput, w którym linia sygnałowa we/wy kalibracji używana jest do wprowadzenia sygnału prędkości (sygnał testowy) zastępującego sygnał prędkości z czujnika ruchu; ta funkcja nie jest dostępna w trybie KONTROLNYM;
- realTimeSpeedSignalOutputSensor, w którym linia sygnałowa we/wy kalibracji używana jest do wyprowadzenia sygnału prędkości z czujnika ruchu;
- RTCOutput, w którym linia sygnałowa we/wy kalibracji używana jest do wyprowadzenia sygnału zegarowego UTC; ta funkcja nie jest dostępna w trybie KONTROLNYM.
CPR_059 Przyrząd rejestrujący musi być wprowadzony do sesji regulacji i być w trybie KALIBRACYJNYM lub KONTROLNYM w celu skonfigurowania stanu linii. Jeżeli VU jest w trybie KALIBRACYJNYM, można wybrać cztery stany linii (disabled, speedSignalInput, realTimeSpeedSignalOutputSensor, RTCOutput). Jeżeli VU jest w trybie KONTROLNYM, można wybrać tylko dwa stany linii (disabled, realTimeSpeedOut-putSensor). Na zakończenie sesji regulacji lub trybu KALIBRACYJNEGO lub KONTROLNEGO przyrząd rejestrujący musi zapewnić, aby linia sygnałowa we/wy kalibracji powróciła do stanu "disabled" (wyłączona - stan domyślny).
CPR_060 Jeżeli impulsy prędkości odbierane są w czasie rzeczywistym z linii sygnału wejściowego prędkości w VU, natomiast linia sygnałowa we/wy kalibracji jest ustawiona na wejście, to linia sygnałowa we/wy kalibracji zostanie ustawiona na wyjście lub powróci do stanu "disabled" (wyłączona).
CPR_061 Kolejność czynności jest następująca:
- uruchomienie komunikacji usługą StartCommunication;
- otworzenie sesji regulacji usługą StartDiagnosticSession i wejście do trybu KALIBRACYJNEGO lub KONTROLNEGO (kolejność tych dwóch czynności nie ma znaczenia);
- zmiana stanu wyjścia usługą InputOutputControlByIdentifier. 7.1.2 Format komunikatu
CPR_062 Formaty komunikatu dla prymitywów InputOutputControlByIdentifier opisano szczegółowo w poniższych tabelach.
Tabela 33
Komunikat InputOutputControlByIdentifier Request
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | EE | TGT |
| #3 | Bajt adresu źródłowego | tt | SRC |
| #4 | Dodatkowy bajt długości | xx | LEN |
| #5 | InputOutputControlByIdentifier Request Sid | 2F | IOCBI |
| #6 i #7 | InputOutputIdentifier = [CalibrationInputOutput] | F960 | IOI_CIO |
| #8 lub #8 do #9 | ControlOptionRecord = [ | COR_... | |
| inputOutputControlParameter - jedna wartość z tabeli 36 | xx | IOCP_... | |
| controlState - jedna wartość z tabeli 37 (zob. uwaga poniżej)] | xx | CS_... | |
| #9 lub #10 | Suma kontrolna | 00-FF | CS |
Uwaga: Parametr controlState występuje tylko w określonych przypadkach (zob. 7.1.3).
Tabela 34
Komunikat InputOutputControlByIdentifier Positive Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | xx | LEN |
| #5 | inputOutputControlByIdentifier Positive Response SId | 6F | IOCBIPR |
| #6 i #7 | inputOutputIdentifier = [CalibrationInputOutput] | F960 | IOI_CIO |
| #8 lub #8 do #9 | controlStatusRecord = [ | CSR_ | |
| inputOutputControlParameter (ta sama wartość jak dla bajtu #8 w tabeli 33) | xx | IOCP_... | |
| controlState (ta sama wartość jak dla bajtu #9 w tabeli 33)] (jeżeli dotyczy) | xx | CS_... | |
| #9 lub #10 | Suma kontrolna | 00-FF | CS |
Tabela 35
Komunikat InputOutputControlByIdentifier Negative Response
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 03 | LEN |
| #5 | negativeResponse Service Id | 7F | NR |
| #6 | inputOutputControlByIdentifier Request SId | 2F | IOCBI |
| #7 | responseCode=[ | ||
| incorrectMessageLength | 13 | RC_IML | |
| conditionsNotCorrect | 22 | RC_CNC | |
| requestOutOfRange | 31 | RRRRRR | |
| deviceControlLimitsExceeded] | 7A | RC_DCLE | |
| #8 | Suma kontrolna | 00-FF | CS |
7.1.3 Definicja parametru
CPR_064 Parametr inputOutputControlParameter (IOCP_) zdefiniowano w poniższej tabeli.
Tabela 36
Definicja wartości inputOutputControlParameter
| Heks | Wyszczególnienie | Mnemonik |
| 00 | ReturnControlToECU Wartość ta wskazuje serwerowi (VU), że tester już nie steruje linią sygnałową we/wy kalibracji. | RCTECU |
| 01 | ResetToDefault Wartość ta wskazuje serwerowi (VU), że wymagane jest przełączenie linii sygnałowej we/wy kalibracji do stanu domyślnego. | RTD |
| 03 | ShortTermAdjustment Wartość ta wskazuje serwerowi (VU), że wymagane jest przełączenie linii sygnałowej we/wy kalibracji do żądanej wartości w celu wyregulowania parametru controlState. | STA |
CPR_065 Parametr controlState występuje jedynie wtedy, gdy parametr inputOutputControlParameter jest ustawiony na ShortTermAdjustment i przyjmuje wartości zdefiniowane w poniższej tabeli.
Tabela 37
Definicja wartości controlState
| Tryb | Wartość heksadecymalna | Wyszczególnienie |
| wyłączony | 00 | linia we/wy wyłączona (stan domyślny) |
| włączony | 01 | włącz linię sygnałową we/wy kalibracji jako speedSignalInput |
| włączony | 02 | włącz linię sygnałową we/wy kalibracji jako realTimeSpeedSigna-lOutputSensor |
| włączony | 03 | włącz linię sygnałową we/wy kalibracji jako RTCOutput |
8. USŁUGA ROUTINECONTROL (KOREKTA CZASU)
CPR_065a Usługa RoutineControl (TimeAdjustment) umożliwia uruchomienie operacji dostosowania zegara VU do czasu podawanego przez odbiornik GNSS.
Na potrzeby realizacji usługi RoutineControl (TimeAdjustment) VU musi być w trybie KALI- BRACYJNYM.
Warunek wstępny: zapewnia się zdolność VU do odbierania komunikatów o uwierzytelnionej pozycji z odbiornika GNSS.
Dopóki trwa korekta czasu, VU odpowiada na żądanie RoutineControl, podfunkcja requestRoutineResults, z routineInfo = 0x78.
Uwaga: korekta czasu może być dość czasochłonna. Tester diagnostyczny żąda statusu korekty czasu za pomocą podfunkcji requestRoutineResults.
CPR_065b Formaty komunikatu dla usługi RoutineControl (TimeAdjustment) i jej prymitywów opisano szczegółowo w poniższych tabelach.
Tabela 37a
RoutineControl, komunikat żądania procedury (TimeAdjustment), podfunkcja startRoutine
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | EE | TGT |
| #3 | Bajt adresu źródłowego | tt | SRC |
| #4 | Dodatkowy bajt długości | xx | LEN |
| #5 | RoutineControl Request Sid (Sid żądania RoutineControl) | 31 | RC |
| #6 | routineControlType = [startRoutine] | 01 | RCTP_STR |
| #7 i #8 | routineldentifier = [TimeAdjustment] | 0100 | RI_TA |
| #9 | Suma kontrolna | 00-FF | CS |
Tabela 37b
RoutineControl, procedura (TimeAdjustment), podfunkcja startRoutine, komunikat pozytywnej odpowiedzi
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | xx | LEN |
| #5 | RoutineControl Positive Response Sid (Sid pozytywnej odpowiedzi na RoutineControl) | 71 | RCPR |
| #6 | routineControlType = [startRoutine] | 01 | RCTP_STR |
| #7 i #8 | routineIdentifier= [TimeAdjustment] | 0100 | RI_TA |
| #9 | Suma kontrolna | 00-FF | CS |
Tabela 37c
RoutineControl, komunikat żądania procedury (TimeAdjustment), podfunkcja requestRoutineResults
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | EE | TGT |
| #3 | Bajt adresu źródłowego | tt | SRC |
| #4 | Dodatkowy bajt długości | xx | LEN |
| #5 | RoutineControl Request Sid (Sid żądania RoutineControl) | 31 | RC |
| #6 | routineControlType = [requestRoutineResults] | 03 | RCTP_RRR |
| #7 i #8 | routineIdentifier= [TimeAdjustment] | 0100 | RI_TA |
| #9 | Suma kontrolna | 00-FF | CS |
Tabela 37d
RoutineControl, procedura (TimeAdjustment), podfunkcja requestRoutineResults, komunikat pozytywnej odpowiedzi
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | xx | LEN |
| #5 | RoutineControl Positive Response Sid (Sid pozytywnej odpowiedzi na RoutineControl) | 71 | RCPR |
| #6 | routineControlType = [requestRoutineResults] | 03 | RCTP_RRR |
| #7 i #8 | routineIdentifier= [TimeAdjustment] | 0100 | RI_TA |
| #9 | routineInfo (zob. tabela 37f) | XX | RINF_TA |
| #10 | routineStatusRecord[] = routineStatus#1 (zob. tabela 37g) | XX | RS_TA |
| #11 | Suma kontrolna | 00-FF | CS |
Tabela 37e
RoutineControl, komunikat negatywnej odpowiedzi na procedurę (TimeAdjustment)
| # bajtu | Nazwa parametru | Wartość heksadecymalna | Mnemonik |
| #1 | Bajt formatu - adresowanie fizyczne | 80 | FMT |
| #2 | Bajt adresu docelowego | tt | TGT |
| #3 | Bajt adresu źródłowego | EE | SRC |
| #4 | Dodatkowy bajt długości | 03 | LEN |
| #5 | negativeResponse Service Id (ID usługi negatywnej odpowiedzi) | 7F | NR |
| #6 | inputOutputControlByldentifier Request SId | 31 | RC |
| #7 | responseCode=[ sub-functionNotSupported incorrectMessageLengthOrInvalidFormat conditionsNotCorrect requestOutOfRange ] | 12 13 22 31 | SFNS IMLOIF CNC ROOR |
| #8 | Suma kontrolna | 00-FF | CS |
Tabela 37f
RoutineControl, procedura (TimeAdjustment), routineInfo
| routineInfo | Wartość heksadecymalna | Opis |
| NormalExitWithResultAvailable | 61 | Procedura została wykonana w całości; dostępne są dodatkowe wyniki procedury. |
| RoutineExecutionOngoing | 78 | Żądana procedura jest nadal wykonywana. |
Tabela 37g
RoutineControl, procedura (TimeAdjustment), routineStatus
| Wartość heksadecymalna | Wynik próby | Opis |
| 01 | pozytywny | Korekta czasu zakończyła się pomyślnie. |
| 02..0F | RFU | |
| 10 | negatywny | Brak odbioru sygnału GNSS. |
| 11..7F | RFU | |
| 80..FF | swoisty dla producenta |
W tej sekcji opisano szczegółowo:
CPR_067 VU obsługuje wszystkie wyszczególnione parametry.
CPR_068 Dane wysyłane przez przyrząd rejestrujący do testera w odpowiedzi na komunikat żądania są typu pomiarowego (tj. bieżąca wartość żądanego parametru pomierzona lub stwierdzona przez VU).
CPR_069 W tabeli 38 podano wartości zakresów używane do sprawdzania poprawności przesłanego parametru.
CPR_070 Wartości w zakresie «wskaźnik błędu» umożliwiają przyrządowi rejestrującemu niezwłoczne wskazanie, że poprawne dane parametryczne nie są dostępne w bieżącym czasie wskutek pewnego typu błędu w tachografie.
CPR_071 Wartości w zakresie «niedostępne» umożliwiają przyrządowi rejestrującemu wysłanie komunikatu zawierającego parametr, który nie jest dostępny bądź nie jest obsługiwany w tym module. Wartości w zakresie «nieżądane» umożliwiają urządzeniu wysłanie komunikatu polecenia i wskazanie tych parametrów, w przypadku gdy od urządzenia odbierającego oczekiwany jest brak odpowiedzi.
CPR_072 Jeżeli usterka elementu składowego uniemożliwia wysłanie prawidłowych danych dla parametru, zamiast danych parametru używa się wskaźnika błędu opisanego w tabeli 38. Jednak jeżeli dane pomierzone lub obliczone dają wartość, która jest poprawna, ale wychodzi poza zdefiniowany zakres parametru, nie należy używać wskaźnika błędu. Dane przesyłane są używając odpowiednio wartości minimalnej lub maksymalnej parametru.
Tabela 38
Zakresy dataRecords
| Nazwa zakresu | 1 bajt (wartość heksadecymalna) | 2 bajty (wartość heksadecymalna) | 4 bajty (wartość heksadecymalna) | ASCII |
| Prawidłowy sygnał | 00 do FA | 0000 do FAFF | 00000000 do FAFFFFFF | 1 do 254 |
| Szczególny wskaźnik parametru | FB | FB00 do FBFF | FB000000 do FBFFFFFF | brak |
| Zastrzeżony zakres do wykorzystania w przyszłości | FC do FD | FC00 do FDFF | FC000000 do FDFFFFFF | brak |
| Wskaźnik błędu | FE | FE00 do FEFF | FE000000 do FEFFFFFF | 0 |
| Niedostępne lub nieżądane | FF | FF00 do FFFF | FF000000 do FFFFFFFF | FF |
CPR_073 Dla parametrów kodowanych w ASCII znak ASCII '*' jest zastrzeżony jako ogranicznik.
W tabelach od 39 do 42 poniżej opisano szczegółowo formaty używane przez usługi ReadDataByIdentifier i WriteDataByIdentifier.
CPR_074 W tabeli 39 podano długość, rozdzielczość i zakres roboczy dla każdego parametru identyfikowanego przez recordDataIdentifier:
Tabela 39
Format dataRecords
| Nazwa parametru | Długość danych (w bajtach) | Rozdzielczość | Zakres roboczy |
| TimeDate | 8 | Zob. szczegółowy opis w tabeli 40 |
| HighResolutionTotalVehicleDis- tance | 4 | wzmocnienie 5 m/bit, offset 0 m | 0 do + 21 055 406 km |
| Kfactor | 2 | wzmocnienie 0,001 impulsu/m/bit, offset 0 | 0 do 64,255 impulsu/m |
| LfactorTyreCircumference | 2 | wzmocnienie 0,125 10-3m/bit, offset 0 | 0 do 8,031 m |
| WvehicleCharacteristicFactor | 2 | wzmocnienie 0,001 impulsu/m/bit, offset 0 | 0 do 64,255 impulsu/m |
| TyreSize | 15 | ASCII | ASCII |
| NextCalibrationDate | 3 | Zob. szczegółowy opis w tabeli 41 |
| SpeedAuthorised | 2 | wzmocnienie 1/256km/h/bit, offset 0 | 0 do 250,996 km/h |
| RegisteringMemberState | 3 | ASCII | ASCII |
| VehicleRegistrationNumber | 14 | Zob. szczegółowy opis w tabeli 42 |
| VIN | 17 | ASCII | ASCII |
| SealDataVu | 55 | Zob. szczegółowy opis w tabeli 43 |
| ByDefaultLoadType | 1 | Zob. szczegółowy opis w tabeli 44 |
| VuSerialNumber | 8 | Zob. szczegółowy opis w tabeli 45 |
| SensorSerialNumber | 8 | Zob. szczegółowy opis w tabeli 45 |
| SensorGNSSSerialNumber | 8 | Zob. szczegółowy opis w tabeli 45 |
| RemoteCommunicationModuleSerialNumber | 8 | Zob. szczegółowy opis w tabeli 45 |
| TachographCardsGenlSuppres- sion | 2 | Zob. szczegółowy opis w tabeli 46 |
| VehiclePosition | 14 | Zob. szczegółowy opis w tabeli 47 |
| CalibrationCountry | 3 | ASCII NationAlpha zgodnie z definicją w dodatku 1 |
CPR_075 W tabeli 40 zamieszczono szczegółowy opis formatów poszczególnych bajtów parametru TimeDate:
Tabela 40
Szczegółowy opis formatu TimeDate (wartość recordDataIdentifier # F90B)
| Bajt | Definicja parametru | Rozdzielczość | Zakres roboczy |
| 1 | Sekundy | wzmocnienie 0,25 s/bit, offset 0 s | 0 do 59,75s |
| 2 | Minuty | wzmocnienie 1 minuta/bit, offset 0 minut | 0 do 59 minut |
| 3 | Godziny | wzmocnienie 1 h/bit, offset 0 h | 0 do 23 h |
| 4 | Miesiąc | wzmocnienie 1 miesiąc/bit, offset 0 miesięcy | 1 do 12 miesięcy |
| 5 | Dzień | wzmocnienie 0,25 dnia/bit, offset 0 dni (zob. UWAGA pod tabelą 41) | 0,25 do 31,75 dnia |
| 6 | Rok | wzmocnienie 1 rok/bit, offset rok +1985 (zob. UWAGA pod tabelą 41) | lata od 1985 do 2235 |
| 7 | lokalne przesunięcie dla minut | wzmocnienie 1 minuta/bit, offset -125 minut | -59 do +59 minut |
| 8 | lokalne przesunięcie dla godzin | wzmocnienie 1 h/bit, offset -125 h | -23 do +23 h |
CPR_076 W tabeli 41 zamieszczono szczegółowy opis formatów poszczególnych bajtów parametru NextCalibrationDate:
Tabela 41
Szczegółowy opis formatu NextCalibrationDate (wartość recordDataIdentifier # F922)
| Bajt | Definicja parametru | Rozdzielczość | Zakres roboczy |
| 1 | Miesiąc | wzmocnienie 1 miesiąc/bit, offset 0 miesięcy | 1 do 12 miesięcy |
| 2 | Dzień | wzmocnienie 0,25 dnia/bit, offset 0 dni (zob. UWAGA poniżej) | 0,25 do 31,75 dnia |
| 3 | Rok | wzmocnienie 1 rok/bit, offset rok + 1985 (zob. UWAGA poniżej) | lata od 1985 do 2235 |
UWAGA dotycząca zastosowania parametru »dzień«:
UWAGA dotycząca zastosowania parametru »rok«:
Wartość 0 dla roku oznacza rok 1985, wartość 1 oznacza rok 1986, itd.
CPR_078 W tabeli 42 zamieszczono szczegółowy opis formatów poszczególnych bajtów parametru
VehicleRegistrationNumber:
Tabela 42
Szczegółowy opis formatu VehicleRegistrationNumber (wartość recordDataIdentifier # F97E)
| Bajt | Definicja parametru | Rozdzielczość | Zakres roboczy |
| 1 | Strona kodowa (zdefiniowana w dodatku 1) | nie dotyczy | VehicleRegistrationNumber |
| 2 - 14 | Numer rejestracyjny pojazdu (zdefiniowany w dodatku 1) | nie dotyczy | VehicleRegistrationNumber |
CPR_090 W tabeli 43 zamieszczono szczegółowy opis formatów poszczególnych bajtów parametru SealDataVu:
Tabela 43
Szczegółowy opis formatu SealDataVu (wartość recordDataI- dentifier # F9D3)
| Bajt | Definicja parametru | Rozdzielczość | Zakres roboczy |
| 1 - 11 | sealRecord1. Format SealRecord zdefiniowany w dodatku 1. | nie dotyczy | SealRecord |
| 12 - 22 | sealRecord2. Format SealRecord zdefiniowany w dodatku 1. | nie dotyczy | SealRecord |
| 23 - 33 | sealRecord3. Format SealRecord zdefiniowany w dodatku 1. | nie dotyczy | SealRecord |
| 34 - 44 | sealRecord4. Format SealRecord zdefiniowany w dodatku 1. | nie dotyczy | SealRecord |
| 45 - 55 | sealRecord5. Format SealRecord zdefiniowany w dodatku 1. | nie dotyczy | SealRecord |
UWAGA: W przypadku gdy dostępnych jest mniej niż 5 plomb wartość EquipmentType we wszystkich niewykorzystanych sealRecords należy ustawić na 15, tj. niewykorzystane.
CPR_091 W tabeli 44 zamieszczono szczegółowy opis formatów poszczególnych bajtów parametru ByDefaultLoadType:
Tabela 44
Szczegółowy opis formatu ByDefaultLoadType (wartość recordDataIdentifier # F9D5)
| Bajt | Definicja parametru | Rozdzielczość | Zakres roboczy |
| 1 | loadType '00'H: nieokreślony typ załadunku '01'H: towary '02'H: pasażerowie | nie dotyczy | '00'H do '02'H |
CPR_092 W tabeli 45 zamieszczono szczegółowy opis formatów poszczególnych bajtów parametrów VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber oraz RemoteCommunicationModuleSerialNumber:
Tabela 45
Szczegółowy opis formatu VuSerialNumber, SensorSerialNumber, SensorGNSSSerial- Number oraz RemoteCommunicationModuleSerialNumber (wartości recordDataIdenti- fier # F9D4, F9D0, F9D2, F9D1)
| Bajt | Definicja parametru | Rozdzielczość | Zakres roboczy |
| 1 | VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber and RemoteCommunicationModuleSerialNumber: Format ExtendedSerialNumber zdefiniowany w dodatku 1. | nie dotyczy | ExtendedSerialNumber |
CPR_093 W tabeli 46 zamieszczono szczegółowy opis formatów poszczególnych bajtów parametru TachographCardsGen1Suppression:
Tabela 46
Szczegółowy opis formatu TachographCardsGen1Suppression (wartość recordDataIden- tifier # F9D6)
| Bajt | Definicja parametru | Rozdzielczość | Zakres roboczy |
| 1-2 | TachographCardsGenlSuppression. Format TachographCardsGenlSuppression zdefiniowany w dodatku 1. | nie dotyczy | '0000'H, 'A5E3'H |
| CPR_094 | W tabeli 47 zamieszczono szczegółowy opis formatów poszczególnych bajtów parametru VehiclePosition: |
Tabela 47
Szczegółowy opis formatu VehiclePosition (wartość recordDataIdentifier # F9D7)
| Bajt | Definicja parametru | Rozdzielczość | Zakres roboczy |
| 1 - 4 | Określono znacznik czasu pozycji pojazdu. | nie dotyczy | TimeReal |
| 5 | Dokładność GNSS | nie dotyczy | GNSSAccuracy |
| 6 - 11 | Pozycja pojazdu | nie dotyczy | GeoCoordinates |
| 12 | Status uwierzytelnienia | nie dotyczy | PositionAuthenticationStatus |
| 13 | Bieżący kraj | nie dotyczy | NationNumeric |
| 14 | Bieżący region | nie dotyczy | RegionNumeric |
Uwaga: po aktualizacji pozycji pojazdu aktualizacja bieżącego kraju i regionu może zostać opóźniona.
Dodatek 9 30
HOMOLOGACJA TYPU WYKAZ MINIMUM WYMAGANYCH BADAŃ
HOMOLOGACJA TYPU WYKAZ MINIMUM WYMAGANYCH BADAŃ
1. WPROWADZENIE ..............................................................................................................
2. BADANIA FUNKCJONALNOŚCI PRZYRZĄDU REJESTRUJĄCEGO ..........................
3. BADANIA FUNKCJONALNOŚCI CZUJNIKA RUCHU .................................................
4. BADANIA FUNKCJONALNOŚCI KART DO TACHOGRAFU ......................................
5. BADANIA URZĄDZENIA ZEWNĘTRZNEGO GNSS ......................................................
6. BADANIA ZEWNĘTRZNEGO URZĄDZENIA DO ŁĄCZNOŚCI NA ODLEGŁOŚĆ .....................................
7. BADANIA FUNKCJONALNOŚCI PAPIERU ...................................................................
8. BADANIA INTEROPERACYJNOŚCI ...............................................................................
9. BADANIA OSNMA
1. WPROWADZENIE
1.1. Homologacja typu
Homologacja typu WE urządzenia rejestrującego (lub elementu składowego) lub karty do tachografu opiera się na następujących dokumentach:
- ś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,
- świadectwie funkcjonalności wystawionym przez organ Strony i zaświadczającym, że badany element spełnia wymogi określone w niniejszym załączniku pod względem wykonywanych funkcji, dokładności pomiarów i charakterystyki środowiskowej,
- świadectwie interoperacyjności wystawionym przez właściwy organ i zaświadczającym, że urządzenie rejestrujące (lub karta do tachografu) jest w pełni interoperacyjne z wymaganymi typami kart do tachografu (lub urządzenia rejestrującego) (zob. rozdział 8 niniejszego załącznika).
W niniejszym dodatku określa się, które badania, jako minimum, musi przeprowadzić organ Strony w ramach badań funkcjonalności, i które badania, jako minimum, musi przeprowadzić właściwy organ w ramach badań interoperacyjności. Nie określa się dokładnie procedur przeprowadzania tych badań ani ich rodzajów.
Niniejszy dodatek nie obejmuje aspektów świadectwa bezpieczeństwa. Jeżeli niektóre badania wymagane na potrzeby homologacji typu przeprowadza się przy ocenie bezpieczeństwa i w ramach procesu certyfikacji, to nie trzeba ich przeprowadzać ponownie. W takim przypadku można poddać kontroli tylko wyniki takich badań bezpieczeństwa. Do celów informacyjnych wymogi, które mają zostać poddane badaniom (lub ściśle wiążą się z badaniami, które mają zostać przeprowadzone) w ramach certyfikacji bezpieczeństwa, są w niniejszym dodatku oznaczone symbolem "*".
Ponumerowane wymogi odnoszą się do tekstu głównego załącznika, natomiast pozostałe wymogi odnoszą się do innych dodatków (np. PIC_001 odnosi się do wymogu PIC_001 zawartego w dodatku 3 Piktogramy).
W niniejszym dodatku oddzielnie przedstawiono informacje na temat homologacji typu czujnika ruchu, przyrządu rejestrującego oraz urządzenia zewnętrznego GNSS jako elementów składowych urządzenia rejestrującego. Każdy element składowy uzyska oddzielne świadectwo homologacji typu, w którym wskazane zostaną pozostałe kompatybilne elementy składowe. Badanie funkcjonalności czujnika ruchu (lub urządzenia zewnętrznego GNSS) wykonuje się wraz z badaniem funkcjonalności przyrządu rejestrującego i odwrotnie.
Nie wymaga się zapewnienia interoperacyjności między każdym modelem czujnika ruchu (lub urządzenia zewnętrznego GNSS) i każdym modelem przyrządu rejestrującego. W takim przypadku homologacja typu czujnika ruchu (lub odpowiednio urządzenia zewnętrznego GNSS) może być wydana tylko w połączeniu z homologacją typu właściwego przyrządu rejestrującego i odwrotnie.
Organ Strony odpowiedzialny za badania funkcjonalności przyrządu rejestrującego lub urządzenia zewnętrznego GNSS musi upewnić się, że wbudowany odbiornik GNSS przeszedł pomyślnie badania OSNMA określone w niniejszym dodatku. Badania te uznaje się za część badań funkcjonalności przyrządu rejestrującego lub urządzenia zewnętrznego GNSS.
1.2. Odniesienia
W niniejszym dodatku używa się następujących odniesień:
IEC 60068-2-1: Badania środowiskowe - Część 2-1: Próby - Próba A: Zimno
IEC 60068-2-2: Podstawowe procedury badań środowiskowych - Część 2: Próby - Próba B: Suche gorąco (harmoniczne).
IEC 60068-2-6: Badania środowiskowe - Część 2: Próby - Próba Fc: Wibracje
IEC 60068-2-14: Badania środowiskowe - Część 2-14: Próby - Próba N: Zmiany temperatury
IEC 60068-2-27: Badania środowiskowe - Część 2: Próby - Próba Ea i wytyczne: Udary
IEC 60068-2-30: Badania środowiskowe - Część 2-30: Próby - Próba Db: Wilgotne gorąco, cykliczne (cykl 12 +12 h)
IEC 60068-2-64: Badania środowiskowe - Część 2-64: Próby - Próba Fh: Wibracje szerokopasmowe losowe i wytyczne
IEC 60068-2-78: Badania środowiskowe - Część 2-78: Próby - Próba Cab: Wilgotne gorąco stałe
ISO 16750-3 - Obciążenia mechaniczne (2012-12)
ISO 16750-4 - Obciążenia klimatyczne (2010-04)
ISO 20653: Pojazdy drogowe - Stopień ochrony (kod IP) - Ochrona urządzeń elektrycznych przed ciałami obcymi, wodą i dostępem
ISO 10605:2008 + Sprostowanie techniczne:2010 + AMD1:2014 Pojazdy drogowe - Metody badań zakłóceń elektrycznych powodowanych przez wyładowania elektrostatyczne
ISO 7637-1:2002 + AMD1:2008 Pojazdy drogowe - Zakłócenia elektryczne przenoszone przez przewodzenie i przez sprzężenie - Część 1: Definicje i postanowienia ogólne
ISO 7637-2 Pojazdy drogowe - Zakłócenia elektryczne przenoszone przez przewodzenie i przez sprzężenie - Część 2: Przewodzenie przebiegów przejściowych wyłącznie wzdłuż przewodów zasilających
ISO 7637-3 Pojazdy drogowe - Zakłócenia elektryczne przenoszone przez przewodzenie i przez sprzężenie - Część 3: Przenoszenie elektrycznych przebiegów przejściowych przez sprzężenia pojemnościowe i indukcyjne przez linie inne niż linie zasilające
ISO/IEC 7816-1 Karty identyfikacyjne - Karty elektroniczne - Część 1: Karty stykowe - Charakterystyki fizyczne
ISO/IEC 7816-2 Technologia informacyjna - Karty identyfikacyjne - Karty elektroniczne - Część 2: Karty stykowe - Wymiary i rozmieszczenie styków
ISO/IEC 7816-3 Technologia informacyjna - Karty identyfikacyjne - Karty elektroniczne - Część 3: Karty Stykowe - Sygnały elektryczne i protokoły transmisji
ISO/IEC 10373-1:2006 + AMD1:2012 Karty identyfikacyjne - Metody badań - Część 1: Charakterystyki ogólne
ISO/IEC 10373-3:2010 + Sprostowanie techniczne: 2013 Karty identyfikacyjne - Metody badań - Część 3: Karty elektroniczne i powiązane z nimi urządzenia interfejsowe
ISO 16844-3:2004, Sprostowanie 1: 2006 Pojazdy drogowe - Systemy tachograficzne - Część 3: Interfejs czujnika ruchu (z przyrządami rejestrującymi)
ISO 16844-4 Pojazdy drogowe - Systemy tachograficzne - Część 4: Interfejs CAN
ISO 16844-6 Pojazdy drogowe - Systemy tachograficzne - Część 6: Diagnostyka
ISO 16844-7 Pojazdy drogowe - Systemy tachograficzne - Część 7: Parametry
ISO 534 Papier i tektura - Oznaczanie grubości, gęstości pozornej i objętości właściwej
EKG ONZ R10 Jednolite przepisy dotyczące homologacji pojazdów w odniesieniu do kompatybilności elektromagnetycznej (Europejska Komisja Gospodarcza ONZ)
RGODP Sprawozdanie techniczne JRC - Receiver guidelines for OSNMA data processing
(Wytyczne dla odbiorników w zakresie przetwarzania danych OSNMA)
2. BADANIA FUNKCJONALNOŚCI PRZYRZĄDU REJESTRUJĄCEGO
| "Nr | Badanie | Opis | Powiązane wymogi |
| 1 | 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 |
| 2 | Kontrola wizualna |
| 2.1 | Zgodność z dokumentacją | |
| 2.2 | Identyfikacja/oznakowanie | 224-226 |
| 2.3 | Materiały | 219-223 |
| 2.4 | Plombowanie | 398, 401-405 |
| 2.5 | Interfejsy zewnętrzne |
| 3 | Badania funkcjonalności |
| "3.1 | Obsługiwane funkcje | 02, 03, 04, 05, 07, 382, |
| 3.2 | Tryby pracy | 09 do 11*, 134, 135 |
| 3.3 | Prawa dostępu do funkcji i danych | 12*, 13*, 382, 383, 386 do 389 |
| 3.4 | Monitorowanie wkładania i wyjmowania kart | 15, 16, 17, 18, 19*, 20*, 134 |
| 3.5 | Pomiar prędkości, pozycji i odległości | 21 do 37 |
| 3.6 | Pomiar czasu (badanie przeprowadzone w temperaturze 20 °C) | 38 do 43 |
| 3.7 | Monitorowanie czynności kierowcy | 44 do 53, 134 |
| 3.8 | Monitorowanie stanu prowadzenia pojazdu | 54, 55, 134 |
| 3.9 | Dane wprowadzane przez kierowców | 56 do 62c |
| 3.10 | Zarządzanie blokadami firmowymi | 63 do 68 |
| 3.11 | Monitorowanie czynności kontrolnych | 69, 70 |
| 3.12 | Wykrywanie zdarzeń lub usterek | 71 do 88a, 134 |
| 3.13 | Dane identyfikujące sprzęt | 93*, 94*, 97, 100 |
| 3.14 | Dane rejestrowane przy wkładaniu i wyjmowaniu karty kierowcy lub warsztatowej | 102* do 104* |
| 3.15 | Dane dotyczące czynności kierowcy | 105* do 107* |
| 3.16 | Dane dotyczące miejsc i pozycji | 108* do 112* |
| 3.17 | Dane dotyczące licznika kilometrów | 113*do 115* |
| 3.18 | Dane szczegółowe dotyczące prędkości | 116* |
| 3.19 | Dane dotyczące zdarzeń | 117* |
| 3.20 | Dane dotyczące usterek | 118* |
| 3.21 | Dane dotyczące kalibracji | 119* do 121* |
| 3.22 | Dane dotyczące korekty czasu | 124*, 125* |
| 3.23 | Dane dotyczące czynności kontrolnych | 126*, 127* |
| 3.24 | Dane dotyczące blokad firmowych | 128* |
| 3.25 | Dane dotyczące czynności pobierania | 129* |
| 3.26 | Dane dotyczące stanów szczególnych | 130*, 131* |
| 3.27 | Dane karty do tachografu | 132*, 133* |
| 3.28 | Przekroczenia granicy | 133a* do 133d* |
| 3.29 | Operacja załadunku/rozładunku | 133e* do 133i* |
| 3.30 | Mapa cyfrowa | 133j* do 133t* |
| 3.31 | Rejestrowanie i przechowywanie danych na kartach do tachografów | 136, 137, 138*, 139*, 141*, 142, 143 144, 145, 146*, 147*, 147a*, 147b*, 148*, 149, 150, 150a |
| 3.32 | Wyświetlanie | 90, 134, 151 do 168, PIC_001, DIS_001 |
| 3.33 | Drukowanie | 90, 134, 169 do 181, PIC_001, PRT_001 do PRT_014 |
| 3.34 | Ostrzeganie | 134, 182 do 191, PIC_001 |
| 3.35 | Pobieranie danych na nośnik zewnętrzny | 90, 134, 192 do 196 |
| 3.36 | Łączność na odległość na potrzeby ukierunkowanych kontroli drogowych | 197 do 199 |
| 3.37 | Wymiana danych z dodatkowymi urządzeniami zewnętrznymi | 200, 201 |
| 3.38 | Kalibracja | 202 do 206*, 383, 384, 386 do 391 |
| 3.39 | Drogowe kontrole kalibracji | 207 do 209 |
| 3.40 | Korekta czasu | 210 do 212* |
| 3.41 | Monitorowanie przekroczeń granicy | 226a do 226c |
| 4 | Badania środowiskowe |
| 4.1 | Temperatura | Sprawdzenie funkcjonalności za pomocą: badania zgodnie z normą ISO 16750-4, rozdział 5.1.1.2: Próba eksploatacyjna w niskiej temperaturze (72 h w temperaturze -20 °C). Badanie to odnosi się do normy IEC 60068-2-1: Badania środowiskowe - Część 2-1: Próby - Próba A: Zimno badania zgodnie z normą ISO 16750-4: Rozdział 5.1.2.2: Próba eksploatacyjna w wysokiej temperaturze (72 h w 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 | 1. Drgania harmoniczne: sprawdzenie odporności przyrządu rejestrującego na drgania harmoniczne o następujących właściwościach: stałe przemieszczenie przy częstotliwości 5-11 Hz: 10-milimetrowa amplituda; stałe przyspieszenie przy częstotliwości 11-300 Hz: 5g. Wymóg ten sprawdza się za pomocą próby Fc wg normy IEC 60068-2-6, z minimalnym czasem trwania próby 3 × 12 h (12 h na oś). ISO 16750-3 nie wymaga przeprowadzenia badania drgań harmonicznych w przypadku urządzeń znajdujących się w oddzielnej kabinie pojazdu. | 219 |
| 2. 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. | |||
| 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 |
| 5 | 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 |
3. BADANIA FUNKCJONALNOŚCI CZUJNIKA RUCHU
| Nr | Badanie | Opis | Powiązane wymogi |
| 1. | Badanie administracyjne |
| 1.1 | Dokumentacja | Prawidłowość dokumentacji |
| 2. | Kontrola wizualna |
| 2.1 | Zgodność z dokumentacją | |
| 2.2 | Identyfikacja/oznakowanie | 225, 226, |
| 2.3 | Materiały | 219-223 |
| 2.4 | Plombowanie | 398, 401-405 |
| 3. | Badania funkcjonalności |
| 3.1 | Dane identyfikacyjne czujnika | 95-97* |
| 3.2 | Parowanie czujnik ruchu - przyrząd rejestrujący | 122*, 204 |
| 3.3 | Wykrywanie ruchu Dokładność pomiaru ruchu | 30-35 |
| 3.4 | Interfejs przyrządu rejestrującego | 02 |
| 3.5 | Sprawdzenie, czy działanie stałego pola magnetycznego nie wpływa na czujnik ruchu. Ewentualnie sprawdzenie, czy czujnik ruchu reaguje na działanie stałych pól magnetycznych zaburzających wykrywanie ruchu pojazdu, tak aby podłączony VU mógł wykrywać, rejestrować i zapisywać usterki czujnika. | 217 |
| 4. | Badania środowiskowe |
| 4.1 | Temperatura pracy | Sprawdzenie funkcjonalności (zdefiniowanej w ramach badania nr 3.3) w zakresie temperatur [- 40 - + 135 °C] za pomocą: próby Ad wg normy IEC 60068-2-1, z czasem trwania badania 96 h w najniższej temperaturze Tomin, próby Bd wg normy IEC 60068-2-2, z czasem trwania badania 96 h w najwyższej temperaturze Tomax, badania zgodnie z normą ISO 16750-4: Rozdział 5.1.1.2: Próba eksploatacyjna w niskiej temperaturze (24 h w temperaturze - 40 °C). Badanie to odnosi się do normy IEC 60068-2-1: Badania środowiskowe - Część 2-1: Próby - Próba A: Zimno, wg próby Bd w ramach normy IEC 68-2-2, z czasem trwania 96 h w najniższej temperaturze - 40 °C badania zgodnie z normą ISO 16750-4: Rozdział 5.1.2.2: Próba eksploatacyjna w niskiej temperaturze (96 h w temperaturze 135 °C). Badanie to odnosi się do normy IEC 60068-2-2: Podstawowe procedury badań środowiskowych - Część 2: Próby - Próba B: Suche gorąco; | 213 |
| 4.2 | Cykle temperaturowe | Badanie zgodnie z normą ISO 16750-4: Rozdział 5.3.2: Nagła zmiana temperatury z określonym okresem przejściowym (- 40 °C/135 °C, 20 cykli, czas przebywania: 30 min w każdej temperaturze). IEC 60068-2-14: Badania środowiskowe - Część 2-14: Próby - Próba N: Zmiany temperatury | 213 |
| 4.3 | Cykle wilgotności | Sprawdzenie funkcjonalności (zdefiniowanej w ramach badania nr 3.3) za pomocą próby Db wg normy IEC 60068-2-30, w sześciu 24-godzinnych cyklach, w każdym ze zmieniającą się temperaturą od + 25 °C do + 55 °C i wilgotnością względną 97 % w + 25 °C i 93 % w + 55 °C | 214 |
| 4.4 | Drgania | ISO 16750-3: Rozdział 4.1.2.6: Próba IV: Pojazd użytkowy, silnik, skrzynia biegów Badanie drgań w trybie mieszanym obejmujące: a) badanie drgań harmonicznych, 20...520 Hz, 11,4 ... 120 m/s2, <= 0,5 oct/min b) badanie drgań swobodnych, 10 ... 2 000 Hz, średnia kwadratowa 177 m/s2, 94 h na oś, z cyklem temperaturowym -20...70 °C). Badanie to odnosi się do normy IEC 60068-2-80: Badania środowiskowe - Część 2-80: Próby - Próba Fi: Wibracje - tryb mieszany | 219 |
| 4.5 | Udar mechaniczny | ISO 16750-3: Rozdział 4.2.3: Próba IV: Próba dla urządzeń znajdujących się w skrzyni biegów lub na skrzyni biegów Udar o impulsie półsinusoidalnym, przyspieszenie do uzgodnienia w zakresie 3 000 ... 15 000 m/s2, czas trwania impulsu do uzgodnienia, ale < 1 ms, liczba wstrząsów: do uzgodnienia. Badanie to odnosi się do normy IEC 60068-2-27: Badania środowiskowe - Część 2: Próby - Próba Ea i wytyczne: Udary | 219 |
| 4.6 | Ochrona przed wodą i ciałami obcymi | Badanie zgodnie z normą ISO 20653: Pojazdy drogowe - Stopień ochrony (kod IP) - Ochrona urządzeń elektrycznych przed ciałami obcymi, wodą i dostępem (docelowa wartość IP - 64) | 220, 221 |
| 4.7 | Zabezpieczenie przed odwróceniem polaryzacji | Sprawdzenie odporności czujnika ruchu na odwrócenie biegunów napięcia zasilającego. | 216 |
| 4.8 | Zabezpieczenie zwarciowe | Sprawdzenie, czy sygnały wyjściowe są zabezpieczone przed zwarciem do napięcia zasilającego i do masy. | 216 |
| 5. | Badania kompatybilności elektromagnetycznej |
| 5.1 | Emisje radiacyjne i wrażliwość na radiację | Sprawdzenie zgodności 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 na liniach danych | W przypadku wersji 24 V: zgodność z normą ISO 7637-2 i wersją 3 regulaminu nr 10 EKG ONZ: impuls 1a: Vs = - 450 V, Ri = 50 omów impuls 2a: Vs = + 37 V, Ri = 2 omy impuls 2b: Vs = + 20 V, Ri = 0,05 oma impuls 3a: Vs = - 150 V, Ri = 50 omów impuls 3b: Vs = + 150 V, Ri = 50 omów impuls 4: Vs = - 16 V Va = - 12V, t6 = 100ms impuls 5: Vs = + 120 V, Ri = 2,2 oma, td = 250 ms W przypadku wersji 12 V: zgodność z normą ISO 7637-1 i wersją 3 regulaminu nr 10 EKG ONZ: impuls 1: Vs = - 75 V, Ri = 10 omów impuls 2a: Vs = + 37 V, Ri = 2 omy impuls 2b: Vs = + 10 V, Ri = 0,05 oma impuls 3a: Vs = - 112 V, Ri = 50 omów impuls 3b: Vs = + 75 V, Ri = 50 omów impuls 4: Vs = - 6 V, Va = - 5 V, t6 = 15 ms impuls 5: Vs = + 65 V, Ri = 3 omy, td = 100 ms Impuls 5 należy testować tylko w przypadku przyrządów rejestrujących przeznaczonych do zainstalowania w pojazdach, w których nie zainstalowano zewnętrznego, wspólnego 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 |
4. BADANIA FUNKCJONALNOŚCI KART DO TACHOGRAFU
Badania zgodnie z niniejszą sekcją 4
nr 5 "Testy protokołów",
nr 6 "Struktura karty" i
nr 7 "Badania funkcjonalności"
może przeprowadzić jednostka dokonująca oceny lub jednostka certyfikująca w trakcie procesu wydawania świadectwa bezpieczeństwa dla modułu chipowego zgodnie z normą "Common Criteria" (CC).
Badania nr 2.3 i 4.2 są identyczne. Są to próby mechaniczne kombinacji karty i modułu chipowego. Jeżeli jeden z tych elementów (karta, moduł chipowy) zostanie zmieniony, wówczas przeprowadzenie tych badań jest konieczne.
5. BADANIA URZĄDZENIA ZEWNĘTRZNEGO GNSS
| Nr | Badanie | Opis | Powiązane wymogi |
| 1. | Badanie administracyjne |
| 1.1 | Dokumentacja | Prawidłowość dokumentacji |
| 2. | Kontrola wizualna urządzenia zewnętrznego GNSS |
| 2.1 | Zgodność z dokumentacją | |
| 2.2 | Identyfikacja/oznakowanie | 224-226 |
| 2.3 | Materiały | 219-223 |
| 3. | Badania funkcjonalności |
| 3.1 | Dane identyfikacyjne czujnika | 98, 99 |
| 3.2 | Połączenie między zewnętrznym modułem GNSS a przyrządem rejestrującym | 123, 205 |
| 3.3 | Położenie GNSS | 36, 37 |
| 3.4 | Interfejs przyrządu rejestrującego, gdy odbiornik GNSS znajduje się na zewnątrz przyrządu rejestrującego | 03 |
| 3.5 | Pakiet szyfrów i standardowe parametry domeny | CSM_48, CSM_50 |
| 4. | Badania środowiskowe |
| 4.1 | Temperatura | Sprawdzenie funkcjonalności za pomocą: badania zgodnie z normą ISO 16750-4, Rozdział 5.1.1.2: Próba eksploatacyjna w niskiej temperaturze (72 h w 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; 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 | Wilgotność | Sprawdzenie odporności przyrządu rejestrującego na cykliczne zmiany wilgotności (próba gorąca) za pomocą próby Db wg normy IEC 60068-2-30, w sześciu 24-go-dzinnych cyklach, w każdym ze zmieniającą się temperaturą od + 25 °C do + 55 °C i wilgotnością względną 97 % w + 25 °C i 93 % w + 55 °C | 214 |
| 4.3 | Mechanika | 1. Drgania harmoniczne: sprawdzenie odporności przyrządu rejestrującego na drgania harmoniczne o następujących właściwościach: stałe przemieszczenie przy częstotliwości 5-11 Hz: 10-milimetrowa amplituda; stałe przyspieszenie przy częstotliwości 11-300 Hz: 5g. Wymóg ten sprawdza się za pomocą próby Fc wg normy IEC 60068-2-6, z minimalnym czasem trwania próby 3 × 12 h (12 h na oś). ISO 16750-3 nie wymaga przeprowadzenia testu drgań harmonicznych w przypadku urządzeń znajdujących się w oddzielnej kabinie pojazdu. 2. Drgania swobodne: Próba zgodnie z ISO 16750-3: Rozdział 4.1.2.8: Próba VIII: Pojazd użytkowy, oddzielna kabina pojazdu. Próba drgań swobodnych: 10 ... 2 000 Hz, wertykalna średnia kwadratowa 21,3 m/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) | 220, 221 |
| 4.5 | Zabezpieczenie nadnapięciowe | Sprawdzenie odporności przyrządu rejestrującego na napięcie zasilania: | 216 | |
| wersje 24 V: | 34 V przy + 40 °C przez 1 godzinę | |||
| wersje 12 V: | 17 V przy + 40 °C przez 1 godzinę | |||
| (ISO 16750-2 rozdział 4.3) | ||||
| 4.6 | Zabezpieczenie przed odwróceniem polaryzacji | Sprawdzenie odporności przyrządu rejestrującego na odwrócenie biegunów napięcia zasilającego. (ISO 16750-2 rozdział 4.7) | 216 |
| 4.7 | Zabezpieczenie zwarciowe | Sprawdzenie, czy sygnały wyjściowe są zabezpieczone przed zwarciem do napięcia zasilającego i do masy. (ISO 16750-2 rozdział 4.10) | 216 |
| 5 | Badania EMC |
| 5.1 | Emisje 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: +/- 4 kV w przypadku styku i +/- 8 kV w przypadku rozładowania do powietrza | 218 |
| 5.3 | Wrażliwość na stany nieustalone w zasilaniu | W przypadku wersji 24 V: zgodność z normą ISO 7637-2 i wersją 3 regulaminu nr 10 EKG ONZ: impuls 1a: Vs = - 450 V, Ri = 50 omów impuls 2a: Vs = + 37 V, Ri = 2 omy impuls 2b: Vs = + 20 V, Ri = 0,05 oma impuls 3a: Vs = - 150 V, Ri = 50 omów impuls 3b: Vs = + 150 V, Ri = 50 omów impuls 4: Vs = - 16 V Va = - 12V, t6 = 100 ms impuls 5: Vs = + 120 V, Ri = 2,2 oma, td = 250 ms W przypadku wersji 12 V: zgodność z normą ISO 7637-1 i wersją 3 regulaminu nr 10 EKG ONZ: impuls 1: Vs = - 75 V, Ri = 10 omów impuls 2a: Vs = + 37 V, Ri = 2 omy impuls 2b: Vs = + 10 V, Ri = 0,05 oma impuls 3a: Vs = - 112 V, Ri = 50 omów impuls 3b: Vs = + 75 V, Ri = 50 omów impuls 4: Vs = - 6 V, Va = - 5 V, t6 = 15 ms impuls 5: Vs = + 65 V, Ri = 3 omy, td = 100 ms Impuls 5 należy testować tylko w przypadku przyrządów rejestrujących przeznaczonych do zainstalowania w 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 |
6. BADANIE ZEWNĘTRZNEGO URZĄDZENIA DO ŁĄCZNOŚCI NA ODLEGŁOŚĆ
| Nr | Badanie | Opis | Powiązane wymogi |
| 1. | Badanie administracyjne |
| 1.1 | Dokumentacja | Prawidłowość dokumentacji |
| 2. | Kontrola wizualna |
| 2.1. | Zgodność z dokumentacją | |
| 2.2. | Identyfikacja/oznakowanie | 225, 226 |
| 2.3 | Materiały | 219-223 |
| 3. | Badania funkcjonalności |
| 3.1 | Łączność na odległość na potrzeby ukierunkowanych kontroli drogowych | 4, 197-199 |
| 3.2 | Rejestrowanie i przechowywanie w pamięci danych | 91 |
| 3.3 | Łączność z przyrządem rejestrującym | Dodatek 14 pozycje DSC_66-DSC_70, DSC_71-DSC_76 |
| 4. | Badania środowiskowe |
| 4.1 | Temperatura | Sprawdzenie funkcjonalności za pomocą: badania zgodnie z normą ISO 16750-4, rozdział 5.1.1.2: Próba eksploatacyjna w niskiej temperaturze (72 h w temperaturze -20 °C). Badanie to odnosi się do normy IEC 60068-2-1: Badania środowiskowe - Część 2-1: Próby - Próba A: Zimno Badanie zgodnie z normą ISO 16750-4: Rozdział 5.1.2.2: Próba eksploatacyjna w wysokiej temperaturze (72 h w temperaturze 70 °C). Badanie to odnosi się do normy IEC 60068-2-2: 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 |
| 5 | 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 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 |
7. BADANIA FUNKCJONALNOŚCI PAPIERU
| Nr | Badanie | Opis | Powiązane wymogi |
| 1. | Badanie administracyjne |
| 1.1 | Dokumentacja | Prawidłowość dokumentacji |
| 2 | Badania ogólne |
| 2.1 | Liczba znaków w wierszu | Kontrola wizualna wydruków | 172 |
| 2.2 | Minimalna wielkość czcionki | Kontrola wizualna wydruków i kontrola znaków | 173 |
| 2.3 | Obsługiwane zestawy znaków | Drukarka umożliwia drukowanie znaków określonych w dodatku 1 rozdział 4 "Zestawy znaków". | 174 |
| 2.4 | Definicja wydruków | Sprawdzenie homologacji typu tachografu i przeprowadzenie kontroli wizualnej wydruków | 174 |
| 2.5 | Czytelność i identyfikacja wydruków | Kontrola wydruków Potwierdzona sprawozdaniami z badań i protokołami badań przez producenta. Wszystkie numery homologacyjne tachografów, z którymi można używać danego papieru do drukarek, wydrukowano na papierze. | 175, 177, 178 |
| 2.6 | Dodawanie uwag odręcznych | Kontrola wizualna: dostępne jest miejsce na podpis kierowcy. Dostępne jest miejsce na inne dodatkowe wpisy odręczne. | 180 |
| 2.7 | Dodatkowe informacje szczegółowe na pierwszej stronie kartki papieru | Pierwsza i druga strona kartki papieru mogą zawierać dodatkowe szczegółowe dane i informacje. Tego rodzaju dodatkowe szczegółowe dane i informacje nie mogą ograniczać czytelności wydruków. Kontrola wizualna | 177, 178 |
| 3 | Badania przechowywania |
| 3.1 | Suche gorąco | Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 %. Środowisko testowe: 72 h w temperaturze + 70 °C ± 2 °C. Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 %. | 176, 178 IEC 60068-2-2-Bb |
| 2.2 | Wilgotne gorąco | Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 %. Środowisko testowe: 144 h w temperaturze + 55 °C ± 2 ° C/przy wilgotności względnej 93 % ± 3 %. Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 %. | 176, 178 IEC 60068-2-78-Cab |
| 4 | Badania papieru w użyciu |
| 4.1 | Podstawowa odporność na działanie wilgoci (papier niezadrukowany) | Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 %. Środowisko testowe: 144 h w temperaturze + 55 °C ± 2 ° C/przy wilgotności względnej 93 % ± 3 %. Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 %. | 176, 178 IEC 60068-2-78-Cab |
| 4.2 | Drukowność | Kondycjonowanie wstępne: 24 h w temperaturze + 40 °C ± 2 °C/przy wilgotności względnej 93 % ± 3 %. Środowisko testowe: wydruk sporządzony w temperaturze + 23 °C ± 2 °C Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 %. | 176, 178 |
| 4.3 | Odporność na działanie wysokich temperatur | Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 %. Środowisko testowe: 2 h w temperaturze + 70 °C ± 2 °C, suche gorąco Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 %. | 176, 178 IEC 60068-2-2-Bb |
| 4.4 | Odporność na działanie niskich temperatur | Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 %. Środowisko testowe: 24 h w temperaturze – 20 °C ± 3 °C, suche zimno Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 %. | 176, 178 ISO 60068-2-1-Ab |
| 4.5 | Światłoodporność | Kondycjonowanie wstępne: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 %. Środowisko testowe: 100 h pod oświetleniem o natężeniu 5 000 luksów w temperaturze + 23 °C ± 2 °C przy wilgotności względnej 55 % ± 3 % Odzyskanie: 16 h w temperaturze + 23 °C ± 2 °C/przy wilgotności względnej 55 % ± 3 % | 176, 178 |
Kryteria czytelności w odniesieniu do badań 3.x i 4.x:
Czytelność wydruku jest zapewniona, jeżeli gęstości optyczne są zgodne z następującymi ograniczeniami:
Wielkość drukowanych znaków: min. 1,0
Tło (papier niezadrukowany): maks. 0,2
Gęstości optyczne otrzymanych wydruków mierzy się według DIN EN ISO 534.
Wydruki muszą przedstawiać niezmienione wymiary i być wyraźnie czytelne.
8. BADANIA INTEROPERACYJNOŚCI
| 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. |
W niniejszym rozdziale opisano badania mające na celu wykazanie prawidłowego wdrożenia OSNMA w odbiorniku GNSS. Ponieważ uwierzytelnianie sygnału satelitarnego jest wykonywane wyłącznie przez odbiornik GNSS niezależnie od jakiegokolwiek innego elementu składowego tachografu, badania określone w niniejszym rozdziale mogą być przeprowadzane na odbiorniku GNSS jako samodzielnym elemencie. W takim przypadku producent tachografów przedstawia organom udzielającym homologacji typu sprawozdanie zawierające szczegółowe informacje na temat rozwoju i wyników badań przeprowadzanych na odpowiedzialność producenta odbiorników GNSS.
9.3.1. Definicje
Zimny/ciepły/gorący roz- dotyczy warunku startowego odbiornika GNSS w oparciu o dostępność ruch GNSS:: czasu (T), bieżący almanach (A) i efemerydy (E) oraz pozycję (P):
Zimny/ciepły/gorący roz- dotyczy warunku startowego funkcji OSNMA w oparciu o dostępność ruch OSNMA: klucza publicznego (P) oraz informacji DSM-KROOT (K) (jak określono
w wytycznych dla odbiorników w zakresie OSNMA, o których mowa w dodatku 12):
9.3.2. Akronimy
ADKD Authentication Data & Key Delay [dane uwierzytelniania i opóźnienie klucza]
DSM-KROOT Digital Signature Message KROOT [KROOT komunikatu podpisu cyfrowego] GNSS Global Navigation Satellite System [globalny system nawigacji satelitarnej]
KROOT Root Key of the TESLA key chain [klucz główny łańcucha kluczy TESLA]
MAC Message Authentication Code [kod uwierzytelniania komunikatów]
NMACK Number of MAC & key blocks (per 30 seconds) [liczba MAC i bloków kluczy (na każde 30 sekund)]
OSNMA Galileo Open Service Navigation Message Authentication [uwierzytelnianie komuni
katów nawigacyjnych usługi otwartej Galileo]
SLMAC Slow MAC (powolny MAC)
TESLA Timed Efficient Stream Loss-tolerant Authentication [efektywne czasowo uwierzytelnianie odporne na utratę strumienia] (protokół używany w OSNMA)
Generowanie sygnałów GNSS może odbywać się za pomocą wielokonstelacyjnego symulatora GNSS obsługującego przesyłanie komunikatów OSNMA. Ewentualnie można zastosować odtwarzacz sygnału częstotliwości radiowej umożliwiający odtwarzanie próbek sygnału GNSS z plików. Typowa głębokość bitu i częstotliwość pobierania próbek wynoszą odpowiednio 4 bity I/Q i 10 MHz.
Zakłada się, że odbiornik GNSS posiada interfejsy umożliwiające oczyszczenie pamięci odbiornika (aby niezależnie usunąć klucz publiczny, KROOT, informacje zegarowe, informacje o pozycji, efemerydy i almanach), ustawienie realizacji czasu lokalnego odbiornika na potrzeby weryfikacji czasu OSNMA oraz załadowanie informacji kryptograficznych. Polecenia te mogą ograniczać się do celów testowych i w związku z tym mogą nie być dostępne na potrzeby nominalnego działania odbiornika.
9.5.1. Warunki GNSS
Symulowane lub odtwarzane sygnały GNSS będą miały następującą charakterystykę:
9.5.2. Warunki OSNMA
Komunikat OSNMA przekazywany za pośrednictwem sygnału RF będzie miał następującą charakterystykę:
O ile nie zaznaczono inaczej, realizacja czasu odbiornika wewnętrznego musi być znana z wystarczającą dokładnością i odpowiednio zsynchronizowana z czasem symulowanym. Gwarantuje to spełnienie wymogu synchronizacji czasu początkowego OSNMA dla każdego warunku badania, tj. synchronizacji nominalnej dla wszystkich badań z wyjątkiem SLMAC. Więcej informacji na temat inicjalizacji czasu można znaleźć w wytycznych dla odbiorników w zakresie OSNMA.
Należy zauważyć, że wskazane kryteria zaliczenia/niezaliczenia są zachowawcze i nie odzwierciedlają oczekiwanych wyników OSNMA Galileo.
| Nr | Badanie | Opis | Odpowiednie wymogi |
| 1. | Badanie administracyjne |
| 1.1 | Dokumentacja | Prawidłowość dokumentacji |
| 2 | Badania ogólne |
| 2.1 | Gorący rozruch OSNMA | Cel: sprawdzenie, czy odbiornik GNSS oblicza pozycję przy użyciu OSNMA po gorącym rozruchu. Procedura: Odbiornik GNSS uruchamia się w warunkach gorącego rozruchu GNSS i OSNMA oraz pozyskuje sygnały widocznych satelitów Galileo. Odbiornik uwierzytelnia dane nawigacyjne Galileo za pomocą OSNMA (ADKD = 0) i podaje pozycję z uwierzytelnionymi danymi. Kryteria zaliczenia/niezaliczenia: odbiornik oblicza ustaloną uwierzytelnioną pozycję w ciągu 160 sekund. | Dodatek 12, GNS_3b |
| 2.2 | Ciepły rozruch OSNMA | Cel: sprawdzenie, czy odbiornik GNSS oblicza pozycję przy użyciu OSNMA po ciepłym rozruchu. Procedura: Przed rozpoczęciem badania informacje dotyczące efemerydów i KROOT usuwa się z pamięci odbiornika GNSS w celu wymuszenia ciepłego rozruchu GNSS i OSNmA. Odbiornik GNSS uruchamia się i pozyskuje sygnały widocznych satelitów Galileo. DSM-KROOT jest odbierany i weryfikowany. Odbiornik uwierzytelnia dane nawigacyjne Galileo za pomocą OSNMA (ADKD=0) i podaje pozycję z uwierzytelnionymi danymi. Kryteria zaliczenia/niezaliczenia: odbiornik oblicza ustaloną uwierzytelnioną ważną pozycję w ciągu 430 sekund. | Dodatek 12, GNS_3b |
| 2.3 | Ciepły rozruch OSNMA z SLMAC | Cel: sprawdzenie, czy odbiornik GNSS oblicza pozycję za pomocą OSNMA po ciepłym rozruchu z inicjacją czasu wymagającą trybu SLMAC, jak określono w wytycznych dla odbiorników w zakresie OSNMA. Procedura: Realizacja czasu odbiornika wewnętrznego musi być skonfigurowana w taki sposób, aby początkowa niepewność czasu wynosiła od 2 do 2,5 minuty, tak aby zgodnie z wytycznymi dla odbiorników w zakresie OSNMA aktywować tryb Slow MAC. Przed rozpoczęciem badań informacje dotyczące efemerydów i KROOT usuwa się z pamięci odbiornika GNSS w celu wymuszenia ciepłego rozruchu GNSS i OSNmA. Odbiornik GNSS uruchamia się i pozyskuje sygnały widocznych satelitów Galileo. DSM-KROOT jest odbierany i weryfikowany. Odbiornik uwierzytelnia dane nawigacyjne Galileo wyłącznie za pomocą OSNMA Slow MAC (ADKD=12) i podaje pozycję z uwierzytelnionymi danymi. Kryteria zaliczenia/niezaliczenia: odbiornik oblicza ustaloną uwierzytelnioną ważną pozycję w ciągu 730 sekund. | Dodatek 12, GNS_3b |
| 2.4 | Gorący rozruch OSNMA z odtwarzanym sygnałem | Cel: sprawdzenie, czy odbiornik GNSS wykrywa odtwarzany sygnał. Procedura: Odbiornik GNSS uruchamia się w warunkach gorącego rozruchu GNSS i OSNMA oraz pozyskuje sygnały widocznych satelitów Galileo. Odbiornik uwierzytelnia dane nawigacyjne Galileo za pomocą OSNMA (ADKD=0) i podaje pozycję z uwierzytelnionymi danymi. Gdy odbiornik dostarczy rozwiązanie PVT z uwierzytelnionymi danymi, zostaje wyłączony. Symulowany jest odtwarzany sygnał z opóźnieniem 40 sekund w stosunku do poprzedniego, a odbiornik zostaje włączony. Odbiornik wykrywa, że czas systemu Galileo z czasu sygnału w przestrzeni oraz realizacja czasu lokalnego czasu nie spełniają wymogu synchronizacji i zaprzestaje przetwarzania danych OSNMA, jak określono w wytycznych dla odbiorników w zakresie OSNMA. Kryteria zaliczenia/niezaliczenia: odbiornik wykrywa odtwarzanie i nie oblicza uwierzytelnionej ważnej pozycji od początku odtwarzania do końca badania. | Dodatek 12, GNS_3b |
| 2.5 | Gorący rozruch OSNMA z fałszywymi danymi | Cel: sprawdzenie, czy OSNMA wykrywa fałszywe dane. Procedura: Odbiornik GNSS uruchamia się w warunkach gorącego rozruchu GNSS i OSNMA. Odbiornik GNSS jest w stanie pozyskać sygnał wszystkich widocznych satelitów Galileo i zweryfikować autentyczność ich komunikatów nawigacyjnych za pomocą OSNMA. Co najmniej jeden bit danych efemerycznych dostarczonych przez każdego satelitę Galileo nie odpowiada pierwotnym i uwierzytelnionym danym, ale komunikat Galileo I/NAV musi być spójny, z uwzględnieniem CRC. Kryteria zaliczenia/niezaliczenia: odbiornik wykrywa fałszywe dane w ciągu 160 sekund i nie oblicza uwierzytelnionej ważnej pozycji do zakończenia badania. | Dodatek 12, GNS_3b |
Dodatek 10
WYMOGI BEZPIECZEŃSTWA
WYMOGI BEZPIECZEŃSTWA
SEC_001 Następujące elementy składowe systemu tachografu inteligentnego muszą posiadać certyfikacje bezpieczeństwa zgodnie z systemem wspólnych kryteriów:
- przyrząd rejestrujący;
- karta do tachografu;
- czujnik ruchu;
- urządzenie zewnętrzne GNSS.
SEC_002 Minimalne wymogi bezpieczeństwa informatycznego, jakie ma spełnić każdy element składowy, który musi posiadać certyfikację bezpieczeństwa, określa się w profilu zabezpieczenia dla elementu składowego, zgodnie z systemem wspólnych kryteriów.
SEC_003 Komisja Europejska upewnia się, że cztery profile zabezpieczenia zgodne z niniejszym załącznikiem są finansowane, opracowywane, zatwierdzane przez rządowe jednostki certyfikujące ds. bezpieczeństwa informatycznego, skupione w grupie roboczej ds. wspólnej interpretacji (JIWG), która wspiera wzajemne uznawanie certyfikatów pod egidą SOGIS-MRA (Umowa o wzajemnym uznawaniu świadectw z oceny bezpieczeństwa informatycznego), oraz rejestrowane:
- profil zabezpieczenia dla przyrządu rejestrującego;
- profil zabezpieczenia dla karty do tachografu;
- profil zabezpieczenia dla czujnika ruchu;
- profil zabezpieczenia dla urządzenia zewnętrznego GNSS.
Profil zabezpieczenia dla przyrządu rejestrującego uwzględnia przypadki, gdy przyrząd rejestrujący jest przeznaczony do użytkowania z urządzeniem zewnętrznym GNSS, jak i gdy nie jest do tego przeznaczony. W tym pierwszym przypadku wymogi bezpieczeństwa dotyczące urządzenia zewnętrznego GNSS zostają podane w specjalnym profilu zabezpieczenia.
SEC_004 Aby nadać kształt celowi zabezpieczenia, który stanowi podstawę do uzyskania certyfikacji bezpieczeństwa elementu składowego, producenci elementów składowych przygotowują i kompletują niezbędny profil zabezpieczenia dla odpowiedniego elementu składowego bez poprawiania i usuwania istniejących zagrożeń, celów, środków proceduralnych i specyfikacji funkcji realizujących zabezpieczenia.
SEC_005 Ścisła zgodność takiego konkretnego celu zabezpieczenia z odpowiednim profilem zabezpieczenia musi zostać stwierdzona w procesie oceny.
SEC_006 Poziomem gwarancji dla każdego profilu zabezpieczenia jest poziom EAL4 wzmocniony elementami gwarancji ATE_DPT.2 i AVA_VAN.5.
Dodatek 11 31
WSPÓLNE MECHANIZMY ZABEZPIECZENIA
WSPÓLNE MECHANIZMY ZABEZPIECZENIA
INFORMACJE OGÓLNE ............................................................................................................
CZĘŚĆ A SYSTEM TACHOGRAFU PIERWSZEJ GENERACJI ...............................................
1. WPROWADZENIE ........................................................................................................
1.1. Odniesienia ......................................................................................................................
1.2. Oznaczenia i skróty ..........................................................................................................
2. SYSTEMY I ALGORYTMY KRYPTOGRAFICZNE ...................................................
2.1. Systemy kryptograficzne ...................................................................................................
2.2. Algorytmy kryptograficzne ................................................................................................
2.2.1 Algorytm RSA .................................................................................................................
2.2.2 Algorytm skrótu ...............................................................................................................
2.2.3 Algorytm szyfrowania danych ...........................................................................................
3. KLUCZE I CERTYFIKATY ..........................................................................................
3.1. Generowanie i dystrybucja kluczy .....................................................................................
3.1.1 Generowanie i dystrybucja kluczy RSA ............................................................................
3.1.2 Klucze testowe RSA ........................................................................................................
3.1.3 Klucze czujnika ruchu .......................................................................................................
3.1.4 Generowanie i dystrybucja kluczy sesji T-DES .................................................................
3.2. Klucze .............................................................................................................................
3.3. Certyfikaty .......................................................................................................................
3.3.1 Treść certyfikatów ...........................................................................................................
3.3.2 Wydane certyfikaty ..........................................................................................................
3.3.3 Weryfikacja i rozpakowanie certyfikatu ............................................................................
4. MECHANIZM WZAJEMNEGO UWIERZYTELNIENIA .............................................
5. POUFNOŚĆ, INTEGRALNOŚĆ I MECHANIZMY UWIERZYTELNIANIA PRZESYŁANIA DANYCH MIĘDZY VU A KARTAMI ...............................................
5.1. Bezpieczna wymiana komunikatów ...................................................................................
5.2. Obsługa błędów w bezpiecznej wymianie komunikatów ....................................................
5.3. Algorytm obliczania kryptograficznych sum kontrolnych ....................................................
5.4. Algorytm obliczania kryptogramów dla poufnych obiektów danych ...................................
6. MECHANIZMY CYFROWEGO PODPISU DLA POBIERANIA DANYCH ..............
6.1. Generowanie podpisu .......................................................................................................
6.2. Weryfikacja podpisu ........................................................................................................
CZĘŚĆ B SYSTEM TACHOGRAFU DRUGIEJ GENERACJI .....................................
7. WPROWADZENIE ........................................................................................................
7.1. Odniesienia ......................................................................................................................
7.2. Oznaczenia i skróty ..........................................................................................................
7.3. Definicje ..........................................................................................................................
8. SYSTEMY I ALGORYTMY KRYPTOGRAFICZNE ...................................................
8.1. Systemy kryptograficzne ...................................................................................................
8.2. Algorytmy kryptograficzne ................................................................................................
8.2.1 Algorytmy symetryczne ....................................................................................................
8.2.2 Algorytmy asymetryczne i standardowe parametry domeny ...............................................
8.2.3 Algorytmy skrótu .............................................................................................................
8.2.4 Mechanizm szyfrowania ....................................................................................................
9. KLUCZE I CERTYFIKATY ..........................................................................................
9.1. Pary kluczy asymetrycznych i certyfikaty kluczy publicznych ..............................................
9.1.1 Uwagi ogólne ...................................................................................................................
9.1.2 Poziom europejski ............................................................................................................
9.1.3 Poziom Strony ......................................................................................
9.1.4 Poziom urządzenia: przyrządy rejestrujące .........................................................................
9.1.5 Poziom urządzenia: karty do tachografu ............................................................................
9.1.6 Poziom urządzenia: urządzenia zewnętrzne GNSS .............................................................
9.1.7 Przegląd: zastąpienie certyfikatu ........................................................................................
9.2. Klucze symetryczne ..........................................................................................................
9.2.1 Klucze do zabezpieczania łączności między VU a czujnikiem ruchu ....................................
9.2.2 Klucze do zabezpieczania łączności DSRC .......................................................................
9.3. Certyfikaty .......................................................................................................................
9.3.1 Uwagi ogólne ...................................................................................................................
9.3.2 Treść certyfikatu ..............................................................................................................
9.3.3 Składanie wniosków o certyfikaty .....................................................................................
10. WZAJEMNE UWIERZYTELNIANIE I BEZPIECZNA WYMIANA KOMUNIKATÓW MIĘDZY VU A KARTĄ ................................................................
10.1. Uwagi ogólne ...................................................................................................................
10.2. Wzajemna weryfikacja łańcucha certyfikatów ...................................................................
10.2.1 Weryfikacja łańcucha certyfikatów karty przez VU ...........................................................
10.2.2 Weryfikacja łańcucha certyfikatów VU przez kartę ...........................................................
10.3. Uwierzytelnienie VU .........................................................................................................
10.4. Uwierzytelnianie chipu i uzgadnianie klucza sesji ................................................................
10.5. Bezpieczna wymiana komunikatów ...................................................................................
10.5.1 Uwagi ogólne ...................................................................................................................
10.5.2 Struktura bezpiecznego komunikatu ..................................................................................
10.5.3 Przerwanie sesji bezpiecznej wymiany komunikatów .........................................................
11. POWIĄZANIE, WZAJEMNE UWIERZYTELNIANIE I BEZPIECZNA WYMIANA KOMUNIKATÓW MIĘDZY VU A URZĄDZENIEM ZEWNĘTRZNYM GNSS ........
11.1. Uwagi ogólne ...................................................................................................................
11.2. Ustanowienie powiązania między VU a urządzeniem zewnętrznym GNSS ..........................
11.3. Wzajemna weryfikacja łańcucha certyfikatów ...................................................................
11.3.1 Uwagi ogólne ...................................................................................................................
11.3.2 Podczas ustanawiania powiązania między VU a EGF ........................................................
11.3.3 W czasie normalnej pracy .................................................................................................
11.4. Uwierzytelnienie VU, uwierzytelnienie chipu i uzgodnienie klucza sesji ................................
11.5. Bezpieczna wymiana komunikatów ...................................................................................
12. PAROWANIE VU Z CZUJNIKIEM RUCHU I ŁĄCZNOŚĆ MIĘDZY TYMI URZĄDZENIAMI ..........................................................................................................
12.1. Uwagi ogólne ...................................................................................................................
12.2. Parowanie VU z czujnikiem ruchu przy użyciu różnych generacji kluczy .............................
12.3. Parowanie VU z czujnikiem ruchu i łączność między tymi urządzeniami z wykorzystaniem AES ................................................................................................................................
12.4. Parowanie VU z czujnikiem ruchu w przypadku różnych generacji urządzeń ......................
13. BEZPIECZEŃSTWO ŁĄCZNOŚCI NA ODLEGŁOŚĆ W RAMACH DSRC .............
13.1. Uwagi ogólne ...................................................................................................................
13.2. Szyfrowanie ładunku tachografu i generowanie MAC ........................................................
13.3. Weryfikacja i odszyfrowywanie ładunku tachografu ...........................................................
14. PODPISYWANIE POBIERANYCH DANYCH I SPRAWDZANIE PODPISÓW .......
14.1. Uwagi ogólne ...................................................................................................................
14.2. Generowanie podpisu .......................................................................................................
14.3. Weryfikacja podpisu ........................................................................................................
INFORMACJE OGÓLNE
W niniejszym dodatku określa się mechanizmy zabezpieczenia zapewniające:
- wzajemne uwierzytelnienie między różnymi elementami składowymi systemu tachografu;
- poufność, integralność, autentyczność lub niezaprzeczalność danych przekazywanych między różnymi elementami składowymi systemu tachografu lub pobieranych na zewnętrzne nośniki danych.
Niniejszy dodatek składa się z dwóch części. W części A opisano mechanizmy zabezpieczenia stosowane w systemie tachografu pierwszej generacji (tachograf cyfrowy). W części B opisano mechanizmy zabezpieczenia stosowane w systemie tachografu drugiej generacji (tachograf inteligentny).
Mechanizmy opisane w części A niniejszego dodatku stosuje się, jeżeli przynajmniej jeden element składowy systemu tachografu wykorzystywany w procesie wzajemnego uwierzytelniania lub przesyłania danych jest urządzeniem pierwszej generacji.
Mechanizmy opisane w części B niniejszego dodatku stosuje się, jeżeli obydwa elementy składowe systemu tachografu wykorzystywane w procesie wzajemnego uwierzytelniania lub przesyłania danych są urządzeniami drugiej generacji.
Dodatek 15 zawiera dodatkowe informacje na temat korzystania z elementów składowych pierwszej generacji w połączeniu z elementami składowymi drugiej generacji.
CZĘŚĆ A
SYSTEM TACHOGRAFU PIERWSZEJ GENERACJI
1. WPROWADZENIE
1.1. Odniesienia
W niniejszym dodatku używa się następujących odniesień:
SHA-1 Narodowy Instytut Standaryzacji i Technologii (NIST). FIPS Publikacja 180-1: Bezpieczny standard skrótu. Kwiecień 1995 r.
PKCS1 RSA Laboratories. PCKS # 1: Standard szyfrowania RSA. Wersja 2.0. Październik 1998 r.
TDES Narodowy Instytut Standaryzacji i Technologii (NIST). FIPS Publikacja 46-3: Symetryczny algorytm kryptograficzny. Projekt 1999 r.
TDES-OP ANSI X9.52, Tryby pracy algorytmu trzyetapowego szyfrowania danych. 1998 r.
ISO/IEC 7816-4 Technologia informacyjna - Karty identyfikacyjne - Elektroniczne karty stykowe - Część 4: Międzybranżowe polecenia wymiany informacji. Wydanie pierwsze: 1995 r. + zmiana 1: 1997 r.
ISO/IEC 7816-6 Technologia informacyjna - Karty identyfikacyjne - Elektroniczne karty stykowe - Część 6: Międzybranżowe elementy danych. Wydanie pierwsze: 1996 r. + zmiana 1: 1998 r.
ISO/IEC 7816-8 Technologia informacyjna - Karty identyfikacyjne - Elektroniczne karty stykowe - Część 8: Międzybranżowe polecenia związane z bezpieczeństwem. Wydanie pierwsze: 1999 r.
ISO/IEC 9796-2 Technologia informacyjna - Techniki zabezpieczeń - Schematy podpisu cyfrowego z odtwarzaniem wiadomości - Część 2: Mechanizmy oparte na faktoryzacji liczb całkowitych. Wydanie pierwsze: 1997 r.
ISO/IEC 9798-3 Technologia informacyjna - Techniki zabezpieczeń - Mechanizmy uwierzytelnienia jednostki - Część 3: Uwierzytelnienie jednostki przy użyciu algorytmu klucza publicznego. Wydanie drugie: 1998 r.
ISO 16844-3 Pojazdy drogowe - Systemy tachograficzne - Część 3: Interfejs czujnika ruchu.
1.2. Oznaczenia i skróty
W niniejszym dodatku używa się następujących oznaczeń i skrótów:
(Ka, Kb, Kc) wiązka kluczy używanych w algorytmie trzyetapowego szyfrowania danych,
CA organ certyfikacji
CAR odniesienie do organu certyfikacji
CC kryptograficzna suma kontrolna
CG kryptogram
CH nagłówek polecenia
CHA upoważnienie posiadacza certyfikatu
CHR odniesienie do posiadacza certyfikatu
D() deszyfracja DES
DE element danych
DO obiekt danych
d klucz prywatny RSA, wykładnik prywatny
klucz publiczny RSA, wykładnik publiczny
E() szyfrowanie DES
EQT urządzenie
Hash() skrót, wartość wyjściowa funkcji skrótu
Hash funkcja skrótu
KID identyfikator klucza
Km klucz TDES, klucz główny wg normy ISO 16844-3
KmVU klucz TDES umieszczony w przyrządzie rejestrującym
KmWC klucz TDES umieszczony w kartach warsztatowych
m reprezentacja komunikatu, liczba całkowita z przedziału od 0 do n-1
n klucze RSA, moduły
PB bajty wypełnienia
PI bajt wskaźnik wypełnienia (do zastosowania w kryptogramie dla poufności DO)
PV wartość odkryta
s reprezentacja podpisu, liczba całkowita z przedziału od 0 do n-1
SSC licznik sekwencji wysyłania
SM bezpieczna wymiana komunikatów
TCBC tryb wiązania bloków zaszyfrowanych TDEA
TDEA algorytm trzyetapowego szyfrowania danych
TLV obiekt TLV
VU przyrząd rejestrujący
X.C certyfikat użytkownika X wydany przez organ certyfikacji
X.CA organ certyfikacji użytkownika X
X.CA.PK o X.C Operacja rozpakowania certyfikatu w celu wyodrębnienia klucza publicznego. Jest to operator wrostkowy, którego argumentem lewostronnym jest klucz publiczny organu certyfikacji, a argumentem prawostronnym jest certyfikat wydany przez ten organ certyfikacji. Wynikiem jest klucz publiczny użytkownika X, którego certyfikat jest argumentem prawostronnym.
X.PK klucz publiczny użytkownika X
X.PK[I] szyfrowanie RSA pewnych informacji kluczem publicznym I użytkownika X
X.SK klucz prywatny RSA użytkownika X
X.SK[I] szyfrowanie RSA pewnych informacji kluczem prywatnym I użytkownika X
'xx' wartość heksadecymalna
|| operator konkatenacji
2. SYSTEMY I ALGORYTMY KRYPTOGRAFICZNE
2.1. Systemy kryptograficzne
CSM_001 Przyrządy rejestrujące i karty do tachografu używają klasycznego systemu kryptograficznego RSA z kluczem publicznym do realizowania następujących mechanizmów zabezpieczenia:
- uwierzytelnienie między przyrządami rejestrującymi a kartami,
- transport kluczy sesji Triple-DES między przyrządami rejestrującymi a kartami do tachografu,
- podpis cyfrowy danych pobieranych z przyrządów rejestrujących lub kart do tachografu do zewnętrznych nośników.
CSM_002 Przyrządy rejestrujące i karty do tachografu używają symetrycznego systemu kryptograficznego Triple-DES do zrealizowania mechanizmu zapewniającego integralność danych w czasie wymiany danych użytkownika między przyrządami rejestrującymi a kartami do tachografu i zapewnienia, w stosownych przypadkach, poufności wymiany danych między przyrządami rejestrującymi a kartami do tachografu.
2.2. Algorytmy kryptograficzne
2.2.1 Algorytm RSA
CSM_003 Algorytm RSA w pełni definiują następujące relacje:
| X.SK[m] = s = md mod n X.PK[s] = m = se mod n |
Bardziej wyczerpujący opis funkcji RSA można znaleźć w odniesieniu [PKCS1]. Wykładnik publiczny, e, dla obliczeń RSA jest liczbą całkowitą pomiędzy 3 i n-1 spełniającą gcd(e, lcm(p-1, q-1))=1.
2.2.2 Algorytm skrótu
CSM_004 Mechanizmy podpisu cyfrowego używają algorytmu skrótu SHA-1 zdefiniowanego w odniesieniu [SHA-1].
2.2.3 Algorytm szyfrowania danych
CSM_005 Algorytmy oparte na algorytmie DES są używane w trybie wiązania bloków zaszyfrowanych.
3. KLUCZE I CERTYFIKATY
3.1. Generowanie i dystrybucja kluczy
3.1.1 Generowanie i dystrybucja kluczy RSA
CSM_006 Klucze RSA są generowane na trzech hierarchicznych poziomach funkcjonalnych:
- poziomie europejskim,
- poziomie Strony,
- poziomie urządzenia.
CSM_007 Na poziomie europejskim generuje się jedną parę kluczy europejskich (EUR.SK i EUR.PK). Do poświadczania kluczy publicznych Stron służy europejski klucz prywatny. Należy prowadzić rejestry wszystkich certyfikowanych kluczy. Organem odpowiedzialnym za realizację tych zadań jest europejski organ certyfikacji, działający z upoważnienia i na odpowiedzialność Komisji Europejskiej.
CSM_008 Na poziomie Strony generuje się parę kluczy Strony (MS.SK i MS.PK). Klucze publiczne Strony certyfikuje europejski organ certyfikacji. Klucza prywatnego Strony używa się do certyfikowania kluczy publicznych umieszczanych w urządzeniach (w przyrządzie rejestrującym lub karcie do tachografu). Należy prowadzić rejestry wszystkich certyfikowanych kluczy publicznych wraz z identyfikacją urządzeń, dla których są przewidziane. Organem realizującym te zadania jest organ certyfikacji Strony. Państwo członkowskie może okresowo zmieniać swoją parę kluczy.
CSM_009 Na poziomie urządzenia generuje się jedną parę kluczy (EQT.SK i EQT.PK), którą umieszcza się w każdym urządzeniu. Klucze publiczne urządzenia certyfikuje organ certyfikacji Strony. Zadania te mogą realizować producenci urządzeń, jednostki personalizujące urządzenia lub organy Strony. Wspomnianej pary kluczy używa się do uwierzytelniania, składania podpisu cyfrowego oraz świadczenia usług w zakresie szyfrowania.
CSM_010 W czasie generowania, ewentualnego transportu i przechowywania należy zachować poufność kluczy prywatnych.
Na poniższym rysunku zobrazowano przepływ danych w tym procesie:
3.1.2 Klucze testowe RSA
CSM_011 Do celów testowania urządzeń (włącznie z badaniami interoperacyjności) europejski organ certyfikacji generuje różniące się pary kluczy, jedną europejską parę kluczy testowych i przynajmniej dwie pary kluczy testowych Strony, których klucze publiczne są certyfikowane europejskim prywatnym kluczem testowym. Producenci umieszczają w urządzeniach przechodzących testy homologacji typu klucze testowe certyfikowane jednym z tych kluczy testowych Strony.
3.1.3 Klucze czujnika ruchu
W czasie generowania, ewentualnego transportu i przechowywania w należyty sposób zachowuje się poufność trzech kluczy Triple DES opisanych poniżej.
W celu obsługi elementów składowych tachografu zgodnych z normą ISO 16844 europejski organ certyfikacji i organ certyfikacji Strony dodatkowo zapewniają, co następuje:
CSM_036 europejski organ certyfikacji generuje KmVU i KmWC, dwa niezależne i unikatowe klucze Triple DES, oraz generuje Km jako:
| Km = KmVU XOR KMWC |
Europejski organ certyfikacji przesyła te klucze, z zachowaniem stosownych procedur bezpieczeństwa, organom certyfikacji Stron na ich wniosek.
CSM_037 Organy certyfikacji Stron:
- używają Km do szyfrowania danych czujnika ruchu wymaganych przez producentów czujników ruchu (dane, które mają być zaszyfrowane kluczem Km, są określone w normie ISO 16844-3),
- przesyłają klucz KmVU producentom przyrządów rejestrujących z zachowaniem należytych procedur bezpieczeństwa w celu umieszczenia w przyrządach rejestrujących,
- zapewniają umieszczenie klucza KmWC we wszystkich kartach warsztatowych SensorlnstallationSecData w pliku elementarnym Sensor_Installation_Data w czasie personalizacji kart.
3.1.4 Generowanie i dystrybucja kluczy sesji T-DES
CSM_012 W ramach procesu wzajemnego uwierzytelnienia przyrządy rejestrujące i karty do tachografu generują i wymieniają niezbędne dane w celu uzyskania wspólnego klucza sesji Triple DES. Poufność tej wymiany informacji jest chroniona mechanizmem kryptograficznym RSA.
CSM_013 Klucz ten stosuje się we wszystkich późniejszych czynnościach kryptograficznych, używając bezpiecznej wymiany komunikatów. Ważność tego klucza wygasa z końcem sesji (wyjęcie karty lub wyzerowanie karty) lub po 240 użyciach (jedno użycie klucza = jedno polecenie używające bezpiecznej wymiany komunikatów wysłane do karty i związana z nim odpowiedź).
3.2. Klucze
CSM_014 Długości kluczy RSA (niezależnie od poziomu) są następujące: moduł n 1 024 bity, wykładnik publiczny e maksymalnie 64 bity, wykładnik prywatny d 1 024 bity.
CSM_015 Klucze Triple DES mają postać (Ka, Kb, Ka), gdzie Ka i Kb są niezależnymi 64-bitowymi kluczami. Nie dopuszcza się możliwości ustawiania jakichkolwiek bitów wykrywania błędu parzystości.
3.3. Certyfikaty
CSM_016 Certyfikaty klucza publicznego RSA są certyfikatami "niesamoopisującymi", weryfikowalnymi przez kartę (CVC) (zob. norma ISO/IEC 7816-8).
3.3.1 Treść certyfikatów
CSM_017 Certyfikaty klucza publicznego RSA zawierają następujące dane w określonym poniżej porządku:
| Dane | Format | Bajty | Opis |
| CPI | INTEGER | 1 | Identyfikator profilu certyfikatu ("01" dla tej wersji) |
| CAR | OCTET STRING | 8 | Odniesienie do organu certyfikacji |
| CHA | OCTET STRING | 7 | upoważnienie posiadacza certyfikatu |
| EOV | TimeReal | 4 | Koniec terminu ważności certyfikatu. Opcjonalny, gdy nieużywany, wypełniony "FF". |
| CHR | OCTET STRING | 8 | odniesienie do posiadacza certyfikatu |
| n | OCTET STRING | 128 | Klucz publiczny (moduł) |
| e | OCTET STRING | 8 | Klucz publiczny (wykładnik publiczny) |
| 164 |
Uwagi:
1. "Identyfikator profilu certyfikatu" (CPI) wyznacza dokładną strukturę certyfikatu uwierzytelniania. Można go używać jako wewnętrznego identyfikatora urządzenia w odpowiednim wykazie nagłówków, który opisuje konkatenację elementów danych w certyfikacie.
Wykaz nagłówków związanych z treścią certyfikatu jest następujący:
| '4D' | '16' | '5F 29' | '01' | '42' | '08' | '5F 4B' | '07' | '5F 24' | '04' | '5F 20' | '08' | '7F 49' | '05' | '81' | '81 80' | '82' | '08' |
| Znacznik rozszerzonego wykazu nagłówków | Długość wykazu nagłówków | Znacznik CPI | Długość CPI | Znacznik CAR | Długość CAR | Znacznik CHA | Długość CHA | Znacznik EOV | Długość EOV | Znacznik CHR | Długość CHR | Znacznik klucza publicznego (zbudowany) | Długość następnych DO | Znacznik modułu | Długość modułu | Znacznik wykładnika publicznego | Długość wykładnika publicznego |
2. "Odniesienie do organu certyfikacji" (CAR) ma na celu identyfikację organu certyfikacji wydającego certyfikat, w taki sposób, że ten element danych może być użyty jednocześnie jako identyfikator klucza organu w celu odniesienia do klucza publicznego organu certyfikacji (kodowanie - patrz Identyfikator klucza poniżej).
3. "Upoważnienie posiadacza certyfikatu" (CHA) służy do identyfikowania praw posiadacza certyfikatu. Składa się ono z ID aplikacji tachograficznej i typu urządzenia, dla którego certyfikat jest przeznaczony (zgodnie z elementem danych EquipmentType, "00" dla Strony).
4. "Odniesienie do posiadacza certyfikatu" (CHR) ma na celu jednoznaczną identyfikację posiadacza certyfikatu, w taki sposób, że ten element danych może być użyty jednocześnie jako identyfikator klucza podmiotu w celu odniesienia do posiadacza certyfikatu klucza publicznego.
5. Identyfikatory kluczy jednoznacznie identyfikują posiadacza certyfikatu lub organy certyfikacji. Są one kodowane w następujący sposób:
5.1. Urządzenie (VU lub karta):
| Dane | Numer seryjny urządzenia | Data | Typ | Producent |
| Długość | 4 bajty | 2 bajty | 1 bajt | 1 bajt |
| Wartość | liczba całkowita | kodowanie BCD mm rr | specyficzny dla producenta | kod producenta |
W przypadku VU producent, gdy wnioskuje o certyfikaty, może, ale nie musi, znać identyfikację urządzenia, w którym mają być umieszczone klucze.
W pierwszym przypadku producent wysyła identyfikację urządzenia z kluczem publicznym do organu swojego Strony w celu certyfikacji. W tym przypadku certyfikat będzie zawierał identyfikację urządzenia i producent musi zapewnić umieszczenie kluczy i certyfikatu w przewidzianym urządzeniu. Identyfikator klucza ma przedstawioną powyżej postać.
W drugim przypadku producent musi tylko jednoznacznie zidentyfikować każdy wniosek o certyfikat i wysłać tę identyfikację z kluczem publicznym do organu swojego Strony w celu certyfikacji. W tym przypadku certyfikat będzie zawierał wnioskowaną identyfikację. Po zainstalowaniu klucza w urządzeniu producent musi zawiadomić zwrotnie organ swojego Strony o przyporządkowaniu klucza do urządzenia (tj. podać identyfikację wniosku o certyfikat, identyfikację urządzenia). Identyfikator klucza ma następującą postać:
| Dane | Numer seryjny wniosku o certyfikat | Data | Typ | Producent |
| Długość | 4 bajty | 2 bajty | 1 bajt | 1 bajt |
| Wartość | liczba całkowita | kodowanie BCD mm rr | 'FF' | kod producenta |
5.2. Organ certyfikacji:
| Dane | Identyfikacja organu | Numer seryjny klucza | Dodatkowe informacje | Identyfikator |
| Długość | 4 bajty | 1 bajt | 2 bajty | 1 bajt |
| Wartość | 1-bajtowy kod numeryczny państwa 3-bajtowy kod alfanumeryczny państwa | liczba całkowita | dodatkowe kodowanie (specyficzne dla CA) 'FF FF', gdy nie jest używany | '01' |
Numer seryjny klucza służy do rozróżniania różnych kluczy Strony w przypadku zmiany klucza.
6. Weryfikatory certyfikatów wiedzą niejawnie o tym, iż certyfikowany klucz publiczny jest kluczem RSA właściwym do uwierzytelnienia, weryfikacji podpisu cyfrowego i szyfrowania dla poufnych usług (certyfikat nie zawiera identyfikatora obiektu, który by to określał).
3.3.2 Wydane certyfikaty
CSM_018 Wydany certyfikat jest podpisem cyfrowym z częściowym odzyskiwaniem treści certyfikatu zgodnie z normą ISO/IEC 9796-2 (z wyjątkiem jego załącznika A4) z dołączonym "odniesieniem do organu certyfikacji".
| X.C = X.CA.SK['6A' || Cr || Hash(Cc) || 'BC'] || Cn || X.CAR |
z treścią certyfikatu = Cc = Cr || Cn
106 bajtów 58 bajtów
Uwagi:
1. Ten certyfikat zawiera 194 bajty.
2. CAR, utajniony podpisem, jest również dołączony do podpisu, w związku z czym do weryfikacji certyfikatu można wybrać klucz publiczny organu certyfikacji.
3. Weryfikator certyfikatu zna niejawnie algorytm użyty przez organ certyfikacji do podpisania certyfikatu.
4. Wykaz nagłówków związanych z wydanym certyfikatem jest następujący:
| '7F 21' | '09' | '5F 37' | '81 80' | '5F 38' | '3A' | '42' | '08' |
| Znacznik certyfikatu CV (zbudowany) | Długość następnych DO | Znacznik podpisu | Długość podpisu | Znacznik reszty | Długość reszty | Znacznik CAR | Długość CAR |
3.3.3 Weryfikacja i rozpakowanie certyfikatu
Weryfikacja i rozpakowanie certyfikatu obejmuje sprawdzenie podpisu zgodnie z normą ISO/IEC 9796-2, odzyskanie treści certyfikatu i klucza publicznego: X.PK = X.CA.PK o X.C. oraz sprawdzenie ważności certyfikatu.
CSM_019 Procedura ta składa się z następujących etapów:
weryfikacja podpisu i odzyskanie treści:
- z X.C odzyskaj Sign, Cn' i CAR': X.C = Sign || Cn' || CAR'
128 baj- 58 bajtów8 bajtów
tów
- z CAR' wybierz odpowiednio klucz publiczny organu certyfikacji (jeżeli nie uzyskano go wcześniej innymi środkami)
- odtwórz Sign z klucza publicznego CA: Sr'= X.CA.PK [Sign]
- sprawdź, czy Sr' zaczyna się od '6A' i kończy na 'BC'
- oblicz Cr' i H' z: Sr' = '6A' || Cr' || H' || 'BC'
106 baj- 20 bajtów
tów
- odzyskaj treść certyfikatu C' = Cr' || Cn'
- sprawdź, czy Hash(C') = H'
Jeżeli rezultat kontroli będzie prawidłowy, certyfikat jest prawdziwy, a jego treść to C'.
Sprawdzenie ważności z C':
- w stosownych przypadkach sprawdź koniec daty ważności,
odzyskaj i zachowaj klucz publiczny, identyfikator klucza, upoważnienie posiadacza certyfikatu i koniec ważności certyfikatu z C':
- X.PK = n || e
- X.KID = CHR
- X.CHA = CHA
- X.EOV = EOV
4. MECHANIZM WZAJEMNEGO UWIERZYTELNIENIA
Wzajemne uwierzytelnienie między kartami a VU odbywa się według opisanej poniżej zasady.
Każda strona wykazuje drugiej, że posiada ważną parę kluczy, z której klucz publiczny jest certyfikowany przez organ certyfikacji Strony, który uzyskał certyfikat wydany przez europejski organ certyfikacji.
Wykazanie polega na podpisaniu kluczem prywatnym losowej liczby przysłanej przez drugą stronę, która musi odzyskać tę liczbę przy sprawdzaniu tego podpisu.
Mechanizm zostaje uruchomiony przez VU w chwili włożenia karty. Procedura rozpoczyna się od wymiany certyfikatów i rozpakowania kluczy, a kończy ustaleniem klucza sesji.
CSM_020 W procesie tym stosuje się następujący protokół (strzałki oznaczają polecenia i wymianę danych (zob. dodatek 2)):
5. POUFNOŚĆ, INTEGRALNOŚĆ I MECHANIZMY UWIERZYTELNIANIA PRZESYŁANIA DANYCH MIĘDZY VU A KARTAMI
5.1. Bezpieczna wymiana komunikatów
CSM_021 Bezpieczna wymiana komunikatów chroni integralność przesyłania danych między VU a kartami zgodnie z odniesieniami [ISO/IEC 7816-4] i [ISO/IEC 7816-8].
CSM_022 W przypadku konieczności zapewnienia ochrony przesyłanych danych do obiektów danych wysyłanych w poleceniu lub odpowiedzi dołącza się obiekt danych z kryptograficzną sumą kontrolną. Kryptograficzną sumę kontrolną weryfikuje odbiorca.
CSM_023 Kryptograficzna suma kontrolna danych wysyłanych w poleceniu integruje nagłówek polecenia i wszystkie wysyłane obiekty danych (=>CLA = '0C', a wszystkie obiekty danych są ograniczone znacznikami, w których b1=1).
CSM_024 Bajty stanu odpowiedzi-informacji są chronione kryptograficzną sumą kontrolną, jeżeli odpowiedź nie zawiera żadnego pola danych.
CSM_025 Kryptograficzne sumy kontrolne składają się z 4 bajtów.
W związku z tym struktura poleceń i odpowiedzi w ramach bezpiecznej wymiany komunikatów przedstawia się w następujący sposób:
Wykorzystywane DO stanowią częściowy zbiór DO stosowanych w ramach bezpiecznej wymiany komunikatów, o których mowa w normie ISO/IEC 7816-4:
| Znacznik | Mnemonik | Znaczenie |
| '81' | TPV | Odkryta wartość danych niekodowanych w BER-TLV (chroniona przez kryptograficzną sumę kontrolną) |
| '97' | TLE | Wartość Le w niezabezpieczonym poleceniu (chroniona przez kryptograficzną sumę kontrolną) |
| '99' | TSW | Stan-Info (chronione przez kryptograficzną sumę kontrolną) |
| '8E' | TCC | Kryptograficzna suma kontrolna |
| '87' | TPICG | Bajt wskaźnika wypełnienia || Kryptogram (odkryta wartość niekodowana w BER-TLV) |
Dla danej pary niezabezpieczone polecenie - odpowiedź:
| Nagłówek polecenia | Treść polecenia |
| CLA | INS | P1 | P2 | [Pole Lc] | [Pole danych] | [Pole Le] |
| cztery bajty | Bajty L, oznaczone od B1 do BL |
| Treść odpowiedzi | Stopka odpowiedzi |
| [Pole danych] | SW1 | SW2 |
| Bajty danych Lr | dwa bajty |
Odpowiadająca para zabezpieczone polecenie - odpowiedź jest następująca:
Zabezpieczone polecenie:
| Nagłówek polecenia (CH) | Treść polecenia |
| CLA | INS | P1 | P2 | [Nowe pole Lc] | [Nowe pole danych] | [Nowe pole Le] |
| 'OC' | Długość nowego pola danych | TPV | LPV | PV | TLE | LLE | Le | TCC | LCC | CC | '00' |
| '81' | Lc | pole danych | '97' | '01' | Le | '8E' | '04' | CC |
Dane zintegrowane w sumie kontrolnej = CH || PB || TPV || LPV || PV || TLE || LLE || Le || PB
PB = bajty wypełnienia (80 .. 00) zgodnie z normami ISO-IEC 7816-4 i ISO 9797 metoda 2.
Obiekty DO PV i LE występują tylko wtedy, gdy są pewne odpowiadające im dane w niezabezpieczonym poleceniu.
Zabezpieczona odpowiedź:
1. Przypadek, gdy pole danych odpowiedzi nie jest puste i nie wymaga ochrony poufności:
| Treść odpowiedzi | Stopka odpowiedzi |
| [Nowe pole danych] | nowe SW1 SW2 |
| TPV | LPV | PV | TCC | LCC | CC | |
| '81' | Lr | pole danych | '8E' | '04' | CC |
Dane zintegrowane w sumie kontrolnej = TPV || LPV || PV || PB
2. Przypadek, gdy pole danych odpowiedzi nie jest puste i wymaga ochrony poufności:
| Treść odpowiedzi | Stopka odpowiedzi |
| [Nowe pole danych] | nowe SW1 SW2 |
| TPICG | LPICG | PI CG | TCC | LCC | CC | |
| '87' | PI || CG | '8E' | '04' | CC |
Dane przenoszone przez CG: dane niekodowane w BER-TLV i bajty wypełnienia. Dane zintegrowane w sumie kontrolnej = TPICG || LPICG || PI CG || PB
3. Przypadek, gdy pole danych odpowiedzi jest puste:
| Treść odpowiedzi | Stopka odpowiedzi |
| [Nowe pole danych] | nowe SW1 SW2 |
| TSW | LSW | SW | TCC | LCC | CC | |
| '99' | '02' | nowe SW1 SW2 | '8E' | '04' | CC |
Dane zintegrowane w sumie kontrolnej = TSW || LSW || SW || PB
5.2. Obsługa błędów w bezpiecznej wymianie komunikatów
CSM_026 Gdy karta do tachografu wykryje błąd SM podczas interpretowania polecenia, w odpowiedzi musi zwrócić bajty stanu bez SM. Zgodnie z normą ISO/IEC 7816-4 błędy SM wskazuje się następującymi bajtami stanu:
'66 88': błąd weryfikacji kryptograficznej sumy kontrolnej,
'69 87': brak oczekiwanych obiektów danych SM,
'69 88': nieprawidłowe obiekty danych SM.
CSM_027 W przypadku gdy karta do tachografu zwraca bajty stanu bez obiektów danych SM lub z błędnym obiektem danych SM, VU musi przerwać sesję.
5.3. Algorytm obliczania kryptograficznych sum kontrolnych
CSM_028 Kryptograficzne sumy kontrolne tworzy się za pomocą jednokierunkowej funkcji skrótu MAC zgodnie z normą ANSI X9.19 z DES:
- etap początkowy: początkowy blok kontrolny y0 jest E(Ka, SSC),
- etap sekwencyjny: bloki kontrolne y1,..., yn oblicza się za pomocą Ka,
- etap końcowy: kryptograficzną sumę kontrolną oblicza się z ostatniego bloku yn jako: E(Ka, D (Kb, yn)),
gdzie E() oznacza szyfrowanie z DES, a D() oznacza deszyfrowanie z DES.
Cztery najbardziej znaczące bajty kryptograficznej sumy kontrolnej są przesyłane.
CSM_029 Licznik sekwencji wysyłania (SSC) jest inicjowany podczas procedury uzgadniania klucza:
początkowy SSC: Rnd3 (4 najmniej znaczące bajty) || Rnd1 (4 najmniej znaczące bajty).
CSM_030 Licznik SSC zwiększa się za każdym razem o 1 przed obliczeniem MAC (tj. SSC dla pierwszego polecenia będzie początkowy SSC + 1, SSC dla pierwszej odpowiedzi będzie początkowy SSC + 2).
Na poniższym rysunku pokazano obliczenie skrótu MAC:
5.4. Algorytm obliczania kryptogramów dla poufnych obiektów danych
CSM_031 Kryptogramy oblicza się za pomocą TDEA w trybie pracy TCBC zgodnie z odniesieniami (TDES) i (TDES-OP) i wektorem zerowym jako blokiem wartości początkowych.
Na poniższym rysunku pokazano zastosowanie kluczy w TDES:
6. MECHANIZMY CYFROWEGO PODPISU DLA POBIERANIA DANYCH
CSM_032 Inteligentne urządzenie dedykowane (IDE) przechowuje dane otrzymane z urządzenia (VU lub karty) podczas jednej sesji pobierania w jednym fizycznym pliku danych. Plik ten musi zawierać certyfikaty MSi.C i EQT.C. Plik zawiera podpisy cyfrowe bloków danych zgodnie z opisem znajdującym się w dodatku 7 Protokoły pobierania danych.
CSM_033 Podpisy cyfrowe pobranych danych korzystają ze schematu podpisu cyfrowego z dodatkiem, przy czym, w razie potrzeby, pobrane dane można odczytać bez deszyfrowania.
6.1. Generowanie podpisu
CSM_034 Urządzenie generuje podpis danych zgodnie ze schematem podpisu z dodatkiem zdefiniowanym w odniesieniu [PKCS1] z funkcją skrótu SHA-1:
Podpis = EQT.SK['00' || '01' || PS || '00' || DER(SHA-1(Data))]
PS = Wypełnienie ciągiem oktetów o wartości 'FF' do długości 128.
DER(SHA-1(M)) to kodowanie identyfikatora algorytmu dla funkcji skrótu, a wartość skrótu jest wartością w ASN.1 typu DigestInfo (wyróżnione reguły kodowania):
'30'||'21'||'30'||'09'||'06'||'05'||'2B'||'0E'||'03'||'02'||'1A'||'05'||'00'||'04'||'14'||wartość skrótu.
6.2. Weryfikacja podpisu
CSM_035 Weryfikacja podpisu danych dla pobranych danych odbywa się zgodnie ze schematem podpisu z dodatkiem zdefiniowanym w odniesieniu (PKCS1) z funkcją skrótu SHA-1.
Europejski klucz publiczny EUR.PK musi być niezależnie znany (i zaufany) przez weryfikatora.
Na schemacie poniżej zilustrowano protokół przenoszenia IDE, z którego może korzystać karta kontrolna przy sprawdzaniu integralności danych pobranych i zapisanych na zewnętrznym nośniku danych (ESM). Karta kontrolna służy do deszyfrowania podpisów cyfrowych. W tym przypadku ta funkcja nie musi być zaimplementowana w IDE.
Urządzenie, które pobiera i podpisuje dane przeznaczone do analizowania, oznaczono EQT.
CZĘŚĆ B
SYSTEM TACHOGRAFU DRUGIEJ GENERACJI
7. WPROWADZENIE
7.1. Odniesienia
W tej części dodatku używa się następujących odniesień:
AES Narodowy Instytut Standaryzacji i Technologii (NIST), FIPS Publikacja 197: Symetryczny szyfr blokowy (AES), 26 listopada 2001 r.
DSS Narodowy Instytut Standaryzacji i Technologii (NIST), FIPS Publikacja 186-4: Standard podpisu cyfrowego (DSS), lipiec 2013 r.
ISO 7816-4 ISO/IEC 7816-4, Karty identyfikacyjne - Karty elektroniczne - Część 4: Organizacja, zabezpieczenia i polecenia wymiany. Wydanie trzecie 2013-04-15
ISO 7816-8 ISO/IEC 7816-8, Karty identyfikacyjne - Karty elektroniczne - Część 8: Polecenia operacji zabezpieczających. Wydanie drugie, 2004-06-01
ISO 8825-1 ISO/IEC 8825-1 Technologia informacyjna - Reguły kodowania ASN.1: Specyfikacja podstawowych reguł kodowania (BER), kanonicznych reguł kodowania (CER) i wyróżnionych reguł kodowania (DER). Wydanie czwarte, 2008-12-15.
ISO 9797-1 ISO/IEC 9797-1, Technologia informacyjna - Techniki zabezpieczeń - Kody uwierzytelniania komunikatów (MAC) - Część 1: Mechanizmy stosujące szyfr blokowy. Wydanie drugie, 2011-03-01
ISO 10116 ISO/IEC 10116, Technologia informacyjna - Techniki zabezpieczeń - Tryby pracy algorytmu szyfrowania bloków n-bitowych. Wydanie trzecie, 2006-02-01
ISO 16844-3 ISO 16844-3, Pojazdy drogowe - Systemy tachograficzne - Część 3: Interfejs czujnika ruchu. Wydanie pierwsze z 2004 r., w tym sprostowanie techniczne 1 z 2006 r.
RFC 5480 Kryptografia oparta na krzywej eliptycznej - Informacje na temat klucza publicznego podmiotu, marzec 2009 r.
RFC 5639 Kryptografia oparta na krzywej eliptycznej (ECC) - Standardowe krzywe Brainpool i generowanie krzywych, 2010 r.
RFC 5869 Funkcja wyprowadzania klucza przez wyodrębnianie i rozwijanie oparta na algorytmie HMAC (HKDF), maj 2010 r.
SHS Narodowy Instytut Standaryzacji i Technologii (NIST), FIPS Publikacja 180-4: Bezpieczny standard skrótu, marzec 2012 r.
SP 800-38B Narodowy Instytut Standaryzacji i Technologii (NIST), Specjalna publikacja 800-38B: Zalecenie dotyczące trybów pracy szyfru blokowego: tryb uwierzytelniania CMAC, 2005 r.
TR-03111 Wytyczne techniczne BSI TR-03111, Kryptografia oparta na krzywej eliptycznej, wersja 2.00, 2012-06-28
7.2. Oznaczenia i skróty
W niniejszym dodatku używa się następujących oznaczeń i skrótów:
AES symetryczny szyfr blokowy
CA organ certyfikacji
CAR odniesienie do organu certyfikacji
CBC tryb wiązania bloków zaszyfrowanych (tryb pracy)
CH nagłówek polecenia
CHA upoważnienie posiadacza certyfikatu
CHR odniesienie do posiadacza certyfikatu
CV wektor stały
DER wyróżnione reguły kodowania
DO obiekt danych
DSRC dedykowana łączność krótkiego zasięgu
ECC kryptografia oparta na krzywej eliptycznej
ECDSA algorytm podpisu cyfrowego krzywej eliptycznej
ECDH krzywa eliptyczna Diffiego-Hellmana (algorytm uzgadniania klucza)
EGF urządzenie zewnętrzne GNSS
EQT urządzenia
IDE inteligentne urządzenie dedykowane
KM klucz główny czujnika ruchu umożliwiający sparowanie przyrządu rejestrującego z czujnikiem ruchu
KM-VU klucz umieszczony w przyrządach rejestrujących, umożliwiający VU wyprowadzenie klucza głównego czujnika ruchu, jeżeli karta warsztatowa została włożona do VU
KM-WC klucz umieszczony w kartach warsztatowych, umożliwiający VU wyprowadzenie klucza głównego czujnika ruchu, jeżeli karta warsztatowa została włożona do VU
MAC kod uwierzytelniania komunikatów
MoS czujnik ruchu
MSB najbardziej znaczący bit
PKI infrastruktura klucza publicznego
RCF urządzenie do łączności na odległość
SSC licznik sekwencji wysyłania
SM bezpieczna wymiana komunikatów
TDES potrójny algorytm DES
TLV obiekt TLV (Tag-Length-Value)
VU przyrząd rejestrujący
X.C certyfikat klucza publicznego użytkownika X
X.CA organ certyfikacji, który wydał certyfikat użytkownika X
X.CAR odniesienie do organu certyfikacji, o którym mowa w certyfikacie użytkownika X
X.CHR odniesienie do posiadacza certyfikatu, o którym mowa w certyfikacie użytkownika X
X.PK klucz publiczny użytkownika X
X.SK klucz prywatny użytkownika X
X.PKeph efemeryczny klucz publiczny użytkownika X
X.SKeph efemeryczny klucz prywatny użytkownika X
'xx' wartość heksadecymalna
|| operator konkatenacji
7.3. Definicje
Definicje terminów stosowanych w niniejszym dodatku włączono do sekcji I załącznika 1C.
8. SYSTEMY I ALGORYTMY KRYPTOGRAFICZNE
8.1. Systemy kryptograficzne
CSM_38 Przyrządy rejestrujące i karty do tachografu używają systemu kryptograficznego opartego na krzywej eliptycznej z kluczem publicznym do zapewniania następujących usług zabezpieczających:
- wzajemne uwierzytelnienie między przyrządem rejestrującym a kartą,
- zgodność kluczy sesji AES między przyrządem rejestrującym a kartą,
- zapewnienie autentyczności, integralności i niezaprzeczalności danych pobranych z przyrządów rejestrujących lub kart do tachografu do zewnętrznych nośników.
CSM_39 Przyrządy rejestrujące i zewnętrzne urządzenia GNSS używają systemu kryptograficznego opartego na krzywej eliptycznej z kluczem publicznym do zapewniania następujących usług zabezpieczających:
- powiązanie między przyrządem rejestrującym a urządzeniem zewnętrznym GNSS,
- wzajemne uwierzytelnienie między przyrządem rejestrującym a urządzeniem zewnętrznym GNSS,
- zgodność klucza sesji AES między przyrządem rejestrującym a urządzeniem zewnętrznym GNSS.
CSM_40 Przyrządy rejestrujące i karty do tachografu używają symetrycznego systemu kryptograficznego opartego na AES do zapewniania następujących usług zabezpieczających:
- zapewnienie autentyczności i integralności danych wymienianych między przyrządem rejestrującym a kartą do tachografu,
- w stosownych przypadkach zapewnienie poufności danych wymienianych między przyrządem rejestrującym a kartą do tachografu.
CSM_41 Przyrządy rejestrujące i urządzenia zewnętrzne GNSS używają symetrycznego systemu kryptograficznego opartego na AES do zapewniania następujących usług zabezpieczających:
- zapewnienie autentyczności i integralności danych wymienianych między przyrządem rejestrującym a urządzeniem zewnętrznym GNSS.
CSM_42 Przyrządy rejestrujące i czujniki ruchu używają symetrycznego systemu kryptograficznego opartego na AES do zapewniania następujących usług zabezpieczających:
- sparowanie przyrządu rejestrującego z czujnikiem ruchu,
- wzajemne uwierzytelnienie między przyrządem rejestrującym a czujnikiem ruchu,
- zapewnienie poufności danych wymienianych między przyrządem rejestrującym a czujnikiem ruchu.
CSM_43 Przyrządy rejestrujące i karty kontrolne używają symetrycznego systemu kryptograficznego opartego na AES do zapewniania następujących usług zabezpieczających na interfejsie łączności na odległość:
- zapewnienie poufności, autentyczności i integralności danych przekazywanych z przyrządu rejestrującego do karty kontrolnej.
Uwagi
- Ściśle rzecz ujmując, dane przekazywane z przyrządu rejestrującego do zdalnego interrogatora pod nadzorem funkcjonariusza służb kontrolnych, za pomocą urządzenia do łączności na odległość, które może znajdować się wewnątrz lub na zewnątrz VU, zob. dodatek 14. Zdalny interrogator wysyła jednak otrzymane dane do karty kontrolnej w celu deszyfrowania i potwierdzenia autentyczności. Z punktu widzenia bezpieczeństwa urządzenie do łączności na odległość i zdalny interrogator cechują się pełną przejrzystością.
- Karta warsztatowa zapewnia interfejsowi DSRC takie same usługi zabezpieczające jak karta kontrolna. Dzięki temu warsztat może zatwierdzać prawidłowe funkcjonowanie interfejsu łączności na odległość VU, z uwzględnieniem bezpieczeństwa. Więcej informacji można znaleźć w sekcji 9.2.2.
8.2. Algorytmy kryptograficzne
8.2.1 Algorytmy symetryczne
CSM_44 Przyrządy rejestrujące, karty do tachografu, czujniki ruchu i urządzenia zewnętrzne GNSS obsługują algorytm AES, jak określono w [AES], o długościach klucza wynoszących 128, 192 i 256 bitów.
8.2.2 Algorytmy asymetryczne i standardowe parametry domeny
CSM_45 Przyrządy rejestrujące, karty do tachografu i urządzenia zewnętrzne GNSS obsługują kryptografię opartą na krzywej eliptycznej z kluczami o wielkości 256, 384 i 512/521 bitów.
CSM_46 Przyrządy rejestrujące, karty do tachografu i urządzenia zewnętrzne GNSS obsługują algorytm podpisywania ECDSA, jak określono w [DSS].
CSM_47 Przyrządy rejestrujące, karty do tachografu i urządzenia zewnętrzne GNSS obsługują algorytm uzgadniania klucza ECKA-EG, jak określono w [TR 03111].
CSM_48 Przyrządy rejestrujące, karty do tachografu i urządzenia zewnętrzne GNSS obsługują wszystkie standardowe parametry domeny określone w tabeli 1 poniżej w odniesieniu do kryptografii opartej na krzywej eliptycznej.
Tabela 1
Standardowe parametry domeny
| Nazwa | Wielkość (bity) | Odniesienie | Identyfikator obiektu |
| NIST P-256 | 256 | [DSS], [RFC 5480] | secp256rl |
| BrainpoolP256r1 | 256 | [RFC 5639] | brainpoolP2 5 6rl |
| NIST P-384 | 384 | [DSS], [RFC 5480] | secp384rl |
| BrainpoolP384r1 | 384 | [RFC 5639] | brainpoolP38 4rl |
| BrainpoolP512r1 | 512 | [RFC 5639] | brainpoolP512rl |
| NIST P-521 | 521 | [DSS], [RFC 5480] | secp521rl |
Uwaga: identyfikatory obiektu wspomniane w ostatniej kolumnie tabeli 1 są określone w [RFC 5639] w odniesieniu do krzywych Brainpool oraz w [RFC 5480] w odniesieniu do krzywych NIST.
Przykład 1: identyfikator obiektu krzywej BrainpoolP2 5 6rl to { iso (1)
identified-organization(3) teletrust(36) algorithm(3) signaturealgorithm(3)
ecSign(2) ecStdCurvesAndGeneration (8)
ellipticCurve(1) versionOne(1) 7}.
Lub w zapisie kropkowym: 1.3.36.3.3.2.8.1.1.7.
Przykład 2: identyfikator obiektu krzywej NIST P-384 to
{iso(l) identified-organization(3) certicom(132) curve(0) 34}.
Lub w zapisie kropkowym: 1.3.132.0.34.
8.2.3 Algorytmy skrótu
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].
8.2.4 Mechanizm szyfrowania
CSM_50 W przypadku algorytmu symetrycznego stosuje się łącznie algorytm asymetryczny lub algorytm skrótu w celu utworzenia protokołu zabezpieczeń, zaś długości kluczy i wielkości skrótów obu algorytmów są (w przybliżeniu) tak samo silne. W tabeli 2 przedstawiono dozwolone mechanizmy szyfrowania:
Tabela 2
Dozwolone mechanizmy szyfrowania
| Nr identyfikacyjny mechanizmu szyfrowania | Wielkość klucza ECC (bity) | Długość klucza AES (bity) | Algorytm skrótu | Długość MAC (bajty) |
| CS#1 | 256 | 128 | SHA-256 | 8 |
| CS#2 | 384 | 192 | SHA-384 | 12 |
| CS#3 | 512/521 | 256 | SHA-512 | 16 |
Uwaga: klucze ECC o wielkości 512 i 521 bitów uznaje się za równe pod względem siły do wszystkich celów określonych w niniejszym dodatku.
9. KLUCZE I CERTYFIKATY
9.1. Pary kluczy asymetrycznych i certyfikaty kluczy publicznych
9.1.1 Uwagi ogólne
Uwaga: klucze opisane w tej sekcji wykorzystuje się do wzajemnego uwierzytelniania i bezpiecznej wymiany komunikatów między przyrządami rejestrującymi a kartami do tachografu oraz między przyrządami rejestrującymi a urządzenia zewnętrznymi GNSS. Procesy te opisano szczegółowo w rozdziałach 10 i 11 niniejszego dodatku.
CSM_51 W ramach europejskiego systemu tachografów inteligentnych pary kluczy ECC i odpowiadające im certyfikaty są generowane i zarządzane na trzech funkcjonalnych poziomach hierarchicznych:
- poziomie europejskim,
- poziomie Strony,
- poziomie urządzenia.
CSM_52 W ramach całego europejskiego systemu tachografów inteligentnych klucze publiczne i prywatne oraz certyfikaty są generowane, zarządzane i przekazywane za pomocą standardowych i bezpiecznych metod.
9.1.2 Poziom europejski
CSM_53 Na poziomie europejskim generuje się jedną unikatową parę kluczy ECC oznaczoną jako EUR. Składa się ona z klucza prywatnego (EUR.SK) i klucza publicznego (EUR.PK). Ta para kluczy tworzy parę kluczy głównych całego europejskiego systemu tachografów inteligentnych PKI. Organem realizującym to zadanie jest Główny Europejski Organ Certyfikacji (ERCA), działający z upoważnienia i na odpowiedzialność Komisji Europejskiej.
CSM_54 ERCA używa europejskiego klucza prywatnego do podpisania głównego certyfikatu (z podpisem własnym) europejskiego klucza publicznego i przekazuje ten europejski certyfikat główny wszystkim państwom członkowskim.
CSM_55 ERCA używa europejskiego klucza prywatnego do podpisywania na żądanie certyfikatów kluczy publicznych Stron. ERCA prowadzi rejestry wszystkich podpisanych certyfikatów kluczy publicznych Stron.
CSM_56 Jak przedstawiono na rys. 1 w sekcji 9.1.7, ERCA generuje nową parę europejskich kluczy głównych co 17 lat. Ilekroć ERCA generuje nową parę europejskich kluczy głównych, tworzy nowy certyfikat główny z podpisem własnym dla nowego europejskiego klucza publicznego. Okres ważności europejskiego certyfikatu głównego wynosi 34 lata i 3 miesiące.
Uwaga: wprowadzenie nowej pary kluczy głównych oznacza również, że ERCA wygeneruje nowy klucz główny czujnika ruchu i nowy klucz główny DSRC, zob. sekcje 9.2.1.2 i 9.2.2.2.
CSM_57 Przed wygenerowaniem nowej pary europejskich kluczy głównych ERCA przeprowadza analizę siły kryptograficznej, jaka jest potrzebna w odniesieniu do nowej pary kluczy, biorąc po uwagę fakt, że powinna pozostać bezpieczna przez kolejne 34 lata. W razie konieczności ERCA przechodzi na mechanizm szyfrowania, który jest mocniejszy niż obecny, jak określono wCSM_50.
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.
Uwaga: ze względu na fakt, że certyfikat łączący zawiera klucz publiczny ERCA generacji X i jest podpisany za pomocą klucza prywatnego ERCA generacji X - 1, certyfikat łączący oferuje urządzenie wydane w generacji X - 1, metodę potwierdzenia niezawodności urządzenia wydanego w generacji X.
CSM_59 ERCA nie może używać klucza prywatnego z pary kluczy głównych do jakiegokolwiek celu, po tym jak nowy certyfikat kluczy głównych stanie się ważny.
CSM_60 W każdym momencie ERCA dysponuje następującymi kluczami i certyfikatami kryptograficznymi:
- bieżąca para kluczy europejskich i powiązany certyfikat;
- wszystkie wcześniejsze certyfikaty EUR wykorzystywane do weryfikacji certyfikatów MSCA, które nadal są ważne;
- certyfikaty łączące dla wszystkich generacji certyfikatów EUR, z wyjątkiem pierwszej.
9.1.3 Poziom Strony
CSM_61 Na poziomie Strony wszystkie państwa członkowskie zobowiązane do podpisania certyfikatów kart do tachografu generują co najmniej jedną unikatową parę kluczy ECC oznaczoną jako MSCA_Card. Wszystkie państwa członkowskie zobowiązane do podpisania certyfikatów dla przyrządów rejestrujących lub urządzeń zewnętrznych GNSS dodatkowo generują co najmniej jedną unikatową parę kluczy ECC oznaczoną jako MSCA_VU-EGF.
CSM_62 Organem odpowiedzialnym za generowanie par kluczy Strony jest organ certyfikacji Strony (MSCA). Ilekroć MSCA generuje parę kluczy Strony, przesyła ERCA klucz publiczny, aby uzyskać powiązany z nim certyfikat Strony podpisany przez ERCA.
CSM_63 MSCA dobiera siłę pary kluczy Strony w taki sposób, by odpowiadała ona sile pary europejskich kluczy głównych użytej do podpisania powiązanego certyfikatu Strony.
CSM_64 Para kluczy MSCA_VU-EGF, jeżeli występuje, składa się z klucza prywatnego MSCA_VU-EGF.SK i klucza publicznego MSCA_VU-EGF.PK. MSCA używa klucza prywatnego MSCA_VU-EGF.SK wyłącznie do podpisywania certyfikatów klucza publicznego przyrządów rejestrujących oraz urządzeń zewnętrznych GNSS.
CSM_65 Para kluczy MSCA_Card składa się z klucza prywatnego MSCA_Card.SK i klucza publicznego MSCA_Card.PK. MSCA używa klucza prywatnego MSCA_Card.SK wyłącznie do podpisywania certyfikatów klucza publicznego kart do tachografu.
CSM_66 MSCA prowadzi rejestry wszystkich podpisanych certyfikatów VU, certyfikatów urządzeń zewnętrznych GNSS oraz certyfikatów karty i zamieszcza w nim również informacje pozwalające zidentyfikować urządzenie, dla którego wydano dany certyfikat.
CSM_67 Okres ważności certyfikatu MSCA_VU-EGF wynosi 17 lat i 3 miesiące. Okres ważności certyfikatu MSCA_Card wynosi 7 lat i 1 miesiąc.
CSM_68 Jak przedstawiono na rys. 1 w sekcji 9.1.7, okres użytkowania klucza prywatnego pary kluczy MSCA_VU-EGF i klucza prywatnego pary kluczy MSCA_Card wynosi dwa lata.
CSM_69 MSCA nie może używać klucza prywatnego wchodzącego w skład pary kluczy MSCA_VU-EGF do żadnych celów po zakończeniu okresu jego użytkowania. Podobnie MSCA nie może używać klucza prywatnego wchodzącego w skład pary kluczy MSCA_Card do żadnych celów, po zakończeniu okresu jego użytkowania.
CSM_70 W każdym momencie MSCA dysponuje następującymi kluczami i certyfikatami kryptograficznymi:
- bieżącą parą kluczy MSCA_Card i powiązanym certyfikatem;
- wszystkimi poprzednimi certyfikatami MSCA_Card, które mają służyć do weryfikacji certyfikatów kart do tachografu, które są nadal ważne;
- bieżącym certyfikatem EUR koniecznym do przeprowadzenia weryfikacji bieżącego certyfikatu MSCA;
- wszystkimi poprzednimi certyfikatami EUR koniecznymi do zweryfikowania wszystkich certyfikatów MSCA, które są nadal ważne.
CSM_71 Jeżeli MSCA jest również zobowiązana do podpisywania certyfikatów dla przyrządów rejestrujących lub urządzeń zewnętrznych GNSS, musi dodatkowo dysponować następującymi kluczami i certyfikatami:
- bieżącą parą kluczy MSCA_VU-EGF i powiązanym certyfikatem;
- wszystkimi poprzednimi kluczami publicznymi MSCA_VU-EGF, które mają służyć do weryfikacji certyfikatów VU lub urządzeń zewnętrznych GNSS, które są nadal ważne.
9.1.4 Poziom urządzenia: przyrządy rejestrujące
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.
CSM_73 Data wejścia w życie certyfikatów VU_MA i VU_Sign danego przyrządu rejestrującego musi być taka sama.
CSM_74 Producent VU dobiera siłę pary kluczy VU w taki sposób, by odpowiadała ona sile pary kluczy MSCA użytej do podpisania powiązanego certyfikatu VU.
CSM_75 Przyrząd rejestrujący używa swojej pary kluczy VU_MA, w której skład wchodzi klucz prywatny VU_MA.SK i klucz publiczny VU_MA.PK, wyłącznie do uwierzytelnienia VU w stosunku do kart do tachografu i urządzeń zewnętrznych GNSS, jak określono w sekcjach 10.3 i 11.4 niniejszego dodatku.
CSM_76 Przyrząd rejestrujący musi mieć możliwość generowania par efemerycznych kluczy ECC i musi używać pary kluczy efemerycznych wyłącznie do przeprowadzenia operacji uzgadniania klucza sesji z kartą do tachografu lub urządzeniem zewnętrznym GNSS, jak określono w sekcjach 10.4 i 11.4 niniejszego dodatku.
CSM_77 Przyrząd rejestrujący używa klucza prywatnego VU_Sign.SK wchodzącego w skład pary kluczy VU_Sign wyłącznie do podpisywania pobranych plików danych, jak określono w rozdziale 14 niniejszego dodatku. Powiązanego klucza publicznego VU_Sign.PK używa się wyłącznie do weryfikacji podpisów wygenerowanych przez przyrząd rejestrujący.
CSM_78 Zgodnie z informacjami przedstawionymi na rys. 1 w sekcji 9.1.7 okres ważności certyfikatu VU_MA wynosi 15 lat i 3 miesiące. Okres ważności certyfikatu VU_Sign również wynosi 15 lat i 3 miesiące.
Uwagi
- Wydłużony okres ważności certyfikatu VU_Sign umożliwia przyrządowi rejestrującemu generowanie ważnych podpisów w odniesieniu do pobieranych danych przez pierwsze trzy miesiące po wygaśnięciu certyfikatu zgodnie z art. 7 ust. 5 sekcji 2 części B załącznika 31 do Umowy o handlu i współpracy między Unią Europejską i Europejską Wspólnotą Energii Atomowej, z jednej strony, a Zjednoczonym Królestwem Wielkiej Brytanii i Irlandii Północnej, z drugiej strony.
- Wydłużony okres ważności certyfikatu VU_MA jest potrzebny, aby umożliwić VU uwierzytelnianie karty kontrolnej lub karty firmowej w ciągu pierwszych trzech miesięcy po wygaśnięciu certyfikatu, dzięki czemu istnieje możliwość pobrania danych.
CSM_79 Przyrząd rejestrujący nie może używać klucza prywatnego wchodzącego w skład pary kluczy VU do żadnych celów po wygaśnięciu powiązanego z nim certyfikatu.
CSM_80 Par kluczy VU (z wyjątkiem par kluczy efemerycznych) i powiązanych z nimi certyfikatów danego przyrządu rejestrującego nie można zastępować ani odnawiać w warunkach polowych po rozpoczęciu eksploatacji przyrządu rejestrującego.
Uwagi
- Wymóg ten nie ma zastosowania do par kluczy efemerycznych, ponieważ VU generuje nową parę kluczy efemerycznych w ramach każdego procesu uwierzytelniania mikroprocesora i uzgadniania klucza sesji - zob. sekcja 10.4. Należy zwrócić uwagę na fakt, że pary kluczy efemerycznych nie są powiązane z żadnymi certyfikatami.
- Wymóg ten nie uniemożliwia zastąpienia statycznych par kluczy VU w trakcie modernizacji lub naprawy przeprowadzanej w bezpiecznym środowisku kontrolowanym przez producenta VU.
CSM_81 W chwili ich oddawania do eksploatacji przyrządy rejestrujące muszą zawierać następujące klucze i certyfikaty kryptograficzne:
- klucz prywatny VU_MA i powiązany certyfikat;
- klucz prywatny VU_Sign i powiązany certyfikat;
- certyfikat MSCA_VU-EGF zawierający klucz publiczny MSCA_VU-EGF.PK służący do weryfikacji certyfikatu VU_MA oraz certyfikatu VU_Sign;
- certyfikat EUR zawierający klucz publiczny EUR.PK służący do weryfikacji certyfikatu MSCA_VU-EGF;
- certyfikat EUR, którego okres ważności wygasa bezpośrednio przed okresem ważności certyfikatu EUR służącego do weryfikacji certyfikatu MSCA_VU-EGF, o ile istnieje;
- certyfikat łączący wspomniane dwa certyfikaty EUR, o ile istnieje.
CSM_82 Poza kluczami i certyfikatami kryptograficznymi wymienionymi w CSM_81 przyrządy rejestrujące muszą również zawierać klucze i certyfikaty wskazane w części A niniejszego dodatku, dzięki czemu przyrząd rejestrujący może komunikować się z kartami do tachografu pierwszej generacji.
9.1.5 Poziom urządzenia: karty do tachografu
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.
CSM_84 Data wejścia w życie certyfikatów Card_MA i Card_Sign danej karty kierowcy i karty warsztatowej musi być taka sama.
CSM_85 Producent kart lub instytucja dokonująca personalizacji kart dobiera siłę par kluczy karty w taki sposób, by odpowiadała ona sile pary kluczy MSCA użytej do podpisania powiązanego certyfikatu karty.
CSM_86 Karta do tachografu używa swojej pary kluczy Card_MA, w której skład wchodzi klucz prywatny Card_MA.SK i klucz publiczny Card_MA.PK, wyłącznie do wzajemnego uwierzytelniania i uzgadniania klucza sesji w stosunku do przyrządów rejestrujących, jak określono w sekcjach 10.3 i 10.4 niniejszego dodatku.
CSM_87 Karta kierowcy lub karta warsztatowa używa klucza prywatnego Card_Sign.SK wchodzącego w skład pary kluczy Card_Sign wyłącznie do podpisywania pobranych plików danych, jak określono w rozdziale 14 niniejszego dodatku. Powiązanego klucza publicznego Card_Sign.PK używa się wyłącznie do weryfikacji podpisów wygenerowanych przez kartę.
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.
CSM_89 Okres ważności certyfikatu Card_Sign wynosi:
- w przypadku kart kierowcy: 5 lat i 1 miesiąc;
- w przypadku kart warsztatowych: 1 rok i 1 miesiąc.
Uwaga: wydłużony okres ważności certyfikatu Card_Sign umożliwia karta kierowcy generowanie ważnych podpisów w odniesieniu do pobieranych danych przez pierwszy miesiąc po wygaśnięciu certyfikatu. Jest to konieczne w świetle wymogu ustanowionego w art. 7 ust. 5 sekcji 2 części B załącznika 31 do Umowy o handlu i współpracy między Unią Europejską i Europejską Wspólnotą Energii Atomowej, z jednej strony, a Zjednoczonym Królestwem Wielkiej Brytanii i Irlandii Północnej, z drugiej strony, zgodnie z którym pobranie danych z karty kierowcy musi być możliwe przez okres do 28 dni od daty dokonania ostatniego zapisu danych na tej karcie.
CSM_90 Par kluczy i powiązanych certyfikatów danej karty do tachografu nie można zastępować ani odnawiać po wydaniu karty.
CSM_91 W chwili ich wydawania karty do tachografu muszą zawierać następujące klucze i certyfikaty kryptograficzne:
- klucz prywatny Card_MA i powiązany certyfikat;
- w przypadku kart kierowcy i kart warsztatowych dodatkowo: klucz prywatny Card_Sign i powiązany certyfikat;
- certyfikat MSCA_Card zawierający klucz publiczny MSCA_Card.PK służący do weryfikacji certyfikatu Card_MA oraz certyfikatu Card_Sign;
- certyfikat EUR zawierający klucz publiczny EUR.PK służący do weryfikacji certyfikatu MSCA_Card;
- certyfikat EUR, którego okres ważności wygasa bezpośrednio przed okresem ważności certyfikatu EUR służącego do weryfikacji certyfikatu MSCA_Card, o ile istnieje;
- 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.
- certyfikat łączący wspomniane dwa certyfikaty EUR, o ile istnieje.
CSM_92 Poza kluczami i certyfikatami kryptograficznymi wymienionymi w CSM_91 karty do tachografu muszą również zawierać klucze i certyfikaty wskazane w części A niniejszego dodatku, dzięki czemu mogą komunikować się z VU pierwszej generacji.
9.1.6 Poziom urządzenia: urządzenia zewnętrzne GNSS
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.
CSM_94 Producent EGF dobiera siłę pary kluczy EGF_MA w taki sposób, by odpowiadała ona sile pary kluczy MSCA użytej do podpisania powiązanego certyfikatu EGF_MA.
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.
CSM_96 Okres ważności certyfikatu EGF_MA wynosi 15 lat.
CSM_97 Urządzenie zewnętrzne GNSS nie może używać klucza prywatnego wchodzącego w skład pary kluczy EGF_MA do wiązania się z przyrządem rejestrującym po wygaśnięciu powiązanego z nim certyfikatu.
Uwaga: jak wyjaśniono w sekcji 11.3.3, EGF może potencjalnie używać swojego klucza prywatnego na potrzeby wzajemnego uwierzytelniania w stosunku do VU, jeżeli został już z nim powiązany, nawet po upływie okresu ważności powiązanego certyfikatu.
CSM_98 Pary kluczy EGF_MA i powiązanych certyfikatów danego urządzenia zewnętrznego GNSS nie można zastępować ani odnawiać w warunkach polowych po rozpoczęciu eksploatacji EGF.
Uwaga: wymóg ten nie uniemożliwia zastąpienia par kluczy EGF w trakcie modernizacji lub naprawy przeprowadzanej w bezpiecznym środowisku kontrolowanym przez producenta EGF.
CSM_99 W chwili ich oddawania do eksploatacji urządzenia zewnętrzne GNSS muszą zawierać następujące klucze i certyfikaty kryptograficzne:
- klucz prywatny EGF_MA i powiązany certyfikat;
- certyfikat MSCA_VU-EGF zawierający klucz publiczny MSCA_VU-EGF.PK służący do weryfikacji certyfikatu EGF_MA;
- certyfikat EUR zawierający klucz publiczny EUR.PK służący do weryfikacji certyfikatu MSCA_VU-EGF;
- certyfikat EUR, którego okres ważności wygasa bezpośrednio przed okresem ważności certyfikatu EUR służącego do weryfikacji certyfikatu MSCA_VU-EGF, o ile istnieje;
- certyfikat łączący wspomniane dwa certyfikaty EUR, o ile istnieje.
9.1.7 Przegląd: zastąpienie certyfikatu
Na rys. 1 poniżej przedstawiono, w jaki sposób różne generacje certyfikatów głównych ERCA, certyfikatów łączących ERCA, certyfikatów MSCA oraz certyfikatów urządzeń (VU i kart) są wydawane i wykorzystywane na przestrzeni czasu:
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ń
Uwagi do rys. 1
1. poszczególne generacje certyfikatów głównych oznaczono cyfrą w nawiasie. Na przykład ERCA (1) oznacza pierwszą generację certyfikatu głównego ERCA, ERCA (2) - drugą generację itd.;
2. pozostałe certyfikaty są oznaczone dwiema cyframi w nawiasach: pierwsza z nich wskazuje generację certyfikatu głównego, w której wydano dany certyfikat, natomiast druga określa generację samego certyfikatu. Na przykład MSCA_Card (1-1) oznacza pierwszy certyfikat MSCA_Card wydany na podstawie ERCA (1); MSCA_Card (2-1) oznacza pierwszy certyfikat MSCA_Card wydany na podstawie ERCA (2); MSCA_Card (2-ostatni) oznacza ostatni certyfikat MSCA_Card wydany na podstawie ERCA (2); Card_MA (2-1) oznacza pierwszy certyfikat karty na potrzeby wzajemnego uwierzytelnienia wydany na podstawie ERCA (2) itp.;
3. certyfikaty MSCA_Card (2-1) i MSCA_Card (1-ostatni) wydaje się z bardzo zbliżoną datą. MSCA_Card (2-1) oznacza pierwszy certyfikat MSCA_Card wydany na podstawie ERCA (2), który wydaje się nieco później niż MSCA_Card (1-ostatni), czyli ostatni certyfikat MSCA_Card wydany na podstawie ERCA (1);
4. zgodnie z informacjami przedstawionymi na rysunku pierwsze certyfikaty VU i certyfikaty karty wydane na podstawie ERCA (2) pojawią się niemal dwa lata przed ostatnimi certyfikatami VU i certyfikatami karty wydanymi na podstawie ERCA (1). Wynika to z faktu, że certyfikaty VU i certyfikaty karty wydaje się na podstawie certyfikatu MSCA, nie zaś bezpośrednio na podstawie certyfikatu ERCA. Certyfikat MSCA (2-1) zostanie wydany bezpośrednio po uzyskaniu ważności przez ERCA (2), ale certyfikat MSCA (1-ostatni) zostanie wydany tylko nieznacznie później, tj. w ostatnim dniu, w którym certyfikat ERCA (1) jest nadal ważny. Z tego względu obydwa certyfikaty MSCA będą miały niemal taki sam okres ważności, mimo że należą do różnych generacji;
5. podany okres ważności kart odpowiada okresowi ważności kart kierowcy (5 lat);
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.
9.2. Klucze symetryczne
9.2.1 Klucze do zabezpieczania łączności między VU a czujnikiem ruchu
9.2.1.1 Uwagi ogólne
Uwaga: zakłada się, że czytelnicy tego rozdziału są zaznajomieni z treścią normy [ISO 16844-3], w której opisano interfejs pomiędzy przyrządem rejestrującym a czujnikiem ruchu. Proces parowania VU i czujnika ruchu opisano szczegółowo w rozdziale 12 niniejszego dodatku.
CSM_100 Potrzeba wielu kluczy symetrycznych do sparowania przyrządów rejestrujących i czujników ruchu, wzajemnego uwierzytelnienia między przyrządami rejestrującymi a czujnikami ruchu oraz zaszyfrowania łączności między przyrządami rejestrującymi a czujnikami ruchu, jak pokazano w tabeli 3. Wszystkie te klucze muszą być kluczami AES o długości klucza równej długości klucza głównego czujnika ruchu, która z kolei musi być powiązana z (przewidywaną) długością pary europejskich kluczy głównych, jak opisano w CSM_50.
Tabela 3
Klucze do zabezpieczania łączności między przyrządem rejestrującym a czujnikiem ruchu
| Klucz | Symbol | Generowany przez | Metoda generowania | Przechowywany przez |
| Klucz główny czujnika ruchu - część dotycząca VU | KM-VU | ERCA | Losowo | ERCA, MSCA zaangażowane w wydawanie certyfikatów VU, producenci VU, przyrządy rejestrujące |
| Klucz główny czujnika ruchu - część dotycząca warsztatu | KM-WC | ERCA | Losowo | ERCA, MSCA, producenci kart, karty warsztatowe |
| Klucz główny czujnika ruchu | KM | Nie jest generowany oddzielnie | Obliczany jako KM = KM-VU XOR KM-WC | ERCA, MSCA zaangażowane w wydawanie kluczy czujników ruchu (opcjonalnie) (*) |
| Klucz identyfikacyjny | KID | Nie jest generowany oddzielnie | Obliczany jako KID = KM XOR CV, gdzie CV jest określony w CSM_106 | ERCA, MSCA zaangażowane w wydawanie kluczy czujników ruchu (opcjonalnie) (*) |
| Klucz parowania | KP | Producent czujnika ruchu | Losowo | Jeden czujnik ruchu |
| Klucz sesji | KS | VU (w trakcie parowania VU z czujnikiem ruchu) | Losowo | Jeden VU i jeden czujnik ruchu |
| (*) Przechowywanie KM i KID jest opcjonalne, ponieważ klucze te można wyprowadzić z KM-VU, KM-WC i CV. |
CSM_101 Główny Europejski Organ Certyfikacji generuje KM-WU i KM-WC, dwa losowe, unikatowe klucze AES, na podstawie których można obliczyć klucz główny czujnika ruchu KM jako KM-VU XOR KM-WC. Na wniosek organów certyfikacji Stron ERCA przekazuje im KM, KMVU i KM-WC.
CSM_102 ERCA przypisuje każdemu kluczowi głównemu czujnika ruchu KM unikatowy numer wersji mający zastosowanie również do kluczy ustanawiających KM-VU i KM-WC oraz do powiązanego klucza identyfikacyjnego KID. ERCA powiadamia MSCA o numerze wersji, gdy przekazuje im KM-VU i KM-WC.
Uwaga: numer wersji wykorzystuje się do rozróżnienia poszczególnych generacji wspomnianych kluczy, jak wyjaśniono szczegółowo w sekcji 9.2.1.2.
CSM_103 Organ certyfikacji Strony przekazuje KM-VU wraz z jego numerem wersji producentom przyrządów rejestrujących na ich wniosek. Producenci VU umieszczają KMVU wraz z jego numerem wersji we wszystkich wytwarzanych VU.
CSM_104 Organ certyfikacji Strony zapewnia umieszczenie KMWC wraz z jego numerem wersji w każdej karcie warsztatowej wydanej pod nadzorem MSCA.
Uwagi
- Zobacz opis typu danych SensorlnstallationSecData w dodatku 2.
- Jak wyjaśniono w sekcji 9.2.1.2, w praktyce w niektórych przypadkach może zachodzić konieczność umieszczenia wielu generacji KM-WC w pojedynczej karcie warsztatowej.
CSM_105 Poza kluczem AES, o którym mowa w CSM_104, MSCA zapewnia również umieszczenie klucza TDES KmWC" o którym mowa w wymogu CSM_037 w części A niniejszego dodatku, w każdej karcie warsztatowej wydanej pod nadzorem MSCA.
Uwagi
- Zapewnia to możliwość użycia karty warsztatowej drugiej generacji do powiązania z VU pierwszej generacji.
- Karta warsztatowa drugiej generacji będzie posiadała dwie różne aplikacje, z których jedna będzie zgodna z częścią B niniejszego dodatku, a druga - z częścią A niniejszego dodatku. Ta druga aplikacja będzie zawierała klucz TDES KmWC.
CSM_106 MSCA zaangażowany w wydawanie certyfikatów czujników ruchu wyprowadza klucz identyfikacyjny z klucza głównego czujnika ruchu, za pomocą funkcji XOR z wykorzystaniem wektora stałego CV. Przyjmuje się, że CV ma następującą wartość:
- 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"
- w odniesieniu do 192-bitowych kluczy głównych czujnika ruchu: CV = '72 AD EA FA 00 BB F4 EE F4 99 15 70 5B 7E EE BB 1C 54 ED 46 8B 0E F8 25'
- w odniesieniu do 256-bitowych kluczy głównych czujnika ruchu: CV = '1D 74 DB F0 34 C7 37 2F 65 55 DE D5 DC D1 9A C3 23 D6 A6 25 64 CD BE 2D 42 0D 85 D2 32 63 AD 60'
Uwaga: wektory stałe generuje się w następujący sposób:
Pi_10 = pierwsze 10 bajtów dziesiętnej części stałej matematycznej π = '24 3F 6A 88 85 A3 08 D3 13 19'
CV_128-bits = pierwszych 16 bajtów SHA-256(Pi_10)
CV_192-bits = pierwsze 24 bajty SHA-384(Pi_10)
CV_256-bits = pierwsze 32 bajty SHA-512(Pi_10)
CSM_107 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 Strony (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.
Uwaga: jak wyjaśniono w sekcji 9.2.1.2, w praktyce może zachodzić konieczność wygenerowania przez producenta czujników ruchu wielu unikatowych kluczy parowania dla pojedynczego czujnika ruchu.
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 Strony. 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.
CSM_109 W odniesieniu do wymogów CSM_107 i CSM_108 MSCA korzysta z algorytmu AES w trybie wiązania bloków zaszyfrowanych, jak określono w normie [ISO 10116], z naprzemiennym parametrem m = 1 oraz wektorem inicjującym SV = '00' {16}, tj. szesnaście bajtów o wartości binarnej 0. W razie potrzeby MSCA korzysta z metody wypełniania 2 określonej w normie [ISO 9797-1].
CSM_110 Producent czujników ruchu przechowuje zaszyfrowany klucz parowania i zaszyfrowany numer seryjny w przewidzianym czujniku ruchu wraz z odpowiadającymi wartościami zwykłego tekstu i numerem wersji KM i KID użytymi do szyfrowania.
Uwaga: jak wyjaśniono w sekcji 9.2.1.2, w praktyce może zachodzić konieczność umieszczenia przez producenta czujników ruchu wielu zaszyfrowanych kluczy parowania i wielu zaszyfrowanych numerów seryjnych w pojedynczym czujniku ruchu.
CSM_111 Oprócz materiału kryptograficznego opartego na AES określonego w CSM_110, producent czujników ruchu może również przechowywać w każdym czujniku ruchu materiał kryptograficzny oparty na TDES, jak określono w niniejszym dodatku część A wymóg CSM_037.
Uwaga: dzięki temu możliwe będzie powiązanie czujnika ruchu drugiej generacji z VU pierwszej generacji.
CSM_112 Długość klucza sesji KS wygenerowanego przez VU w trakcie parowania z czujnikiem ruchu jest powiązana z długością jego KM-VU, jak opisano w CSM_50.
9.2.1.2 Zastąpienie klucza głównego czujnika ruchu w urządzeniu drugiej generacji
CSM_113 Każdy klucz główny czujnika ruchu i wszystkie powiązane klucze (zob. tabela 3) są powiązane z określoną generacją pary kluczy głównych ERCA. Klucze te wymienia się zatem co 17 lat. Okres ważności każdej generacji klucza głównego czujnika ruchu rozpoczyna się rok wcześniej, zanim powiązana para kluczy głównych ERCA stanie się ważna, i kończy się po upływie ważności powiązanej pary kluczy głównych ERCA. Przedstawiono to na rys. 2.
Rys. 2
Wydawanie różnych generacji klucza głównego czujnika ruchu i ich używanie w przyrządach rejestrujących, czujnikach ruchu i kartach warsztatowych
CSM_114 Co najmniej rok przed wygenerowaniem nowej pary europejskich kluczy głównych, jak opisano w CSM_56, ERCA generuje nowy klucz główny czujnika ruchu KM poprzez wygenerowanie nowych KM-VU i KM-WC. Długość klucza głównego czujnika ruchu jest powiązana z przewidywaną siłą nowej pary europejskich kluczy głównych zgodnie z CSM_50. Na wniosek MSCA ERCA przekazuje im nowe KM, KM-VU i KM-WC wraz z ich numerem wersji.
CSM_115 MSCA zapewnia, aby wszystkie ważne generacje KM-WC były przechowywane na karcie warsztatowej wydanej z jego upoważnienia wraz z numerami wersji, jak przedstawiono na rys. 2.
Uwaga: oznacza to, że w ostatnim roku okresu ważności certyfikatu ERCA karty warsztatowe będą wydawane z trzema różnymi generacjami KM-WC, jak przedstawiono na rys. 2.
CSM_116 W odniesieniu do procesu opisanego w CSM_107 i CSM_108 powyżej: MSCA szyfruje każdy klucz parowania KP, który otrzymuje od producenta czujników ruchu, oddzielnie za pomocą każdej ważnej generacji klucza głównego czujnika ruchu KM. MSCA szyfruje również każdy numer seryjny, który otrzymuje od producenta czujników ruchu, oddzielnie za pomocą każdej ważnej generacji klucza identyfikacyjnego KID. Producent czujników ruchu przechowuje wszystkie zaszyfrowane klucze parowania i wszystkie zaszyfrowane numery seryjne w przewidzianym czujniku ruchu wraz z odpowiadającymi wartościami zwykłego tekstu i numerami wersji KM i KID użytymi do szyfrowania.
Uwaga: oznacza to, że w ostatnim roku okresu ważności certyfikatu ERCA czujniki ruchu będą wydawane z zaszyfrowanymi danymi opartymi na trzech różnych generacjach KM" jak przedstawiono na rys. 2.
CSM_117 W odniesieniu do procesu opisanego powyżej w CSM_107: ze względu na fakt, że długość klucza parowania KP jest powiązana z długością KM (zob. CSM_100), producent czujnika ruchu może być zmuszony do wygenerowania do trzech różnych kluczy parowania (o różnej długości) dla jednego czujnika ruchu, w przypadku gdy kolejne generacje KM mają różne długości. W takim przypadku producent przesyła MSCA każdy klucz parowania. MSCA zapewnia, aby każdy klucz parowania był zaszyfrowany za pomocą prawidłowej generacji klucza głównego czujnika ruchu tj. klucza mającego taką samą długość.
Uwaga: w przypadku gdy producent czujników ruchu zdecyduje się wygenerować klucz parowania oparty na TDES dla czujnika ruchu drugiej generacji (zob. CSM_111), producent wskazuje MSCA, że klucz główny czujnika ruchu oparty na TDES musi zostać użyty do zaszyfrowania tego klucza parowania. Wynika to z tego, że długość klucza TDES może być równa długości klucza AES, tak więc MSCA nie może dokonać oceny wyłącznie na podstawie długości klucza.
CSM_118 Producenci przyrządów rejestrujących umieszczają tylko jedną generację KM-VU w każdym przyrządzie rejestrującym wraz z jego numerem wersji. Wspomniana generacja KM-VU musi być powiązana z certyfikatem ERCA, na których opierają się certyfikaty VU.
Uwagi
- Przyrząd rejestrujący oparty na certyfikacie ERCA generacji X zawiera jedynie KM-VU generacji X, nawet jeżeli został wydany po rozpoczęciu okresu ważności certyfikatu ERCA generacji X + 1. Przedstawiono to na rys. 2.
- Przyrządu rejestrującego generacji X nie można sparować z czujnikiem ruchu generacji X - 1.
- Ze względu na fakt, że okres ważności kart warsztatowych wynosi jeden rok, w wyniku zastosowania CSM_113 - CSM_118 wszystkie karty warsztatowe będą zawierały nowy KM-WC w momencie wydania pierwszego VU zawierającego nowy KM-VU. W związku z tym taki VU zawsze będzie w stanie obliczyć nowy KM. Ponadto do tego czasu większość nowych czujników ruchu będzie zawierała zaszyfrowane dane również oparte na nowym KM.
9.2.2 Klucze do zabezpieczania łączności DSRC
9.2.2.1 Uwagi ogólne
CSM_119 Autentyczność i poufność danych przekazanych organowi kontrolnemu z przyrządu rejestrującego za pośrednictwem kanału DSRC do łączności na odległość zapewnia się za pomocą zestawu kluczy AES specyficznych dla VU, który wyprowadzono z pojedynczego klucza głównego DSRC, KMDSRC.
CSM_120 Klucz główny DSRC KMDSRC stanowi klucz AES, który jest bezpiecznie generowany, przechowywany i rozpowszechniany przez ERCA. Długość klucza może wynosić 128, 192 lub 256 bitów i jest powiązana z długością pary europejskich kluczy głównych, jak opisano w CSM_50.
CSM_121 Na wniosek organów certyfikacji Stron ERCA przekazuje im klucz główny DSRC w sposób bezpieczny w celu umożliwienia im wyprowadzenia kluczy DSRC specyficznych dla VU i zapewnienia umieszczenia klucza głównego DSRC we wszystkich kartach kontrolnych i kartach warsztatowych wydanych na ich odpowiedzialność.
CSM_122 ERCA przypisuje każdemu kluczowi głównemu DSRC unikatowy numer wersji. ERCA powiadamia MSCA o numerze wersji, gdy przesyła im klucz główny DSRC.
Uwaga: numer wersji wykorzystuje się do rozróżnienia poszczególnych generacji klucza głównego DSRC, jak wyjaśniono szczegółowo w sekcji 9.2.2.2.
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 Strony 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.
CSM_124 Po otrzymaniu wniosku o klucze DSRC specyficzne dla VU MSCA wyprowadza dwa klucze AES dla przyrządu rejestrującego, zwane K_VUDSRC_ENC i K_VUDSRC_MAC. Wspomniane klucze specyficzne dla VU mają taką samą długość jak klucz główny DSRC. MSCA korzysta z funkcji wyprowadzania klucza zdefiniowanej w [RFC 5869]. Funkcja skrótu, która jest niezbędna do utworzenia wystąpienia funkcji HMAC-Hash, jest powiązana z długością klucza głównego DSRC, jak opisano w CSM_50. Z funkcji wyprowadzania klucza w [RFC 5869] korzysta się w następujący sposób:
krok 1: (wyodrębnienie):
- PRK = HMAC-Hash (salt, IKM) gdzie salt oznacza pusty ciąg ", a IKM oznacza KMDSRC;
krok 2: (rozszerzenie):
- OKM = T(1), gdzie
T(1) = HMAC-Hash (PRK, T(0) || info || '01')
- T(0) = pusty ciąg (")
- info = numer seryjny VU lub identyfikator wniosku o certyfikat, jak określono w CSM_123
- K_VUDSRC-ENC = pierwsze oktety L OKM i
K_VUDSRC-MAC = ostatnie oktety L OKM
gdzie L oznacza wymaganą długość K_VUDSRC-ENC i K_VUDSRC-MAC w oktetach.
CSM 125 MSCA przekazuje K VU _ENC i K VU MAC producentowi VU w sposób bezpieczny w celu umieszczenia w przewidzianym przyrządzie rejestrującym.
CSM 126 Po wydaniu przyrząd rejestrujący przechowuje K VU _ENC i K VU MAC w swojej bezpiecznej pamięci, aby móc zapewnić integralność, autentyczność i poufność danych wysyłanych za pośrednictwem kanału do łączności na odległość. Przyrząd rejestrujący przechowuje również numer wersji klucza głównego DSRC użyty do wyprowadzenia tych kluczy specyficznych dla VU.
CSM 127 Po wydaniu karty kontrolne i karty warsztatowe przechowu KM swojej bezpiecznej pamięci, aby móc zweryfikować integralność i autentyczność danych wysyłanych przez VU za pośrednictwem kanału do łączności na odległość oraz aby deszyfrować te dane. Karty kontrolne i karty warsztatowe przechowują również numer wersji klucza głównego DSRC.
Uwaga: jak wyjaśniono w sekcji 9.2.2.2, w praktyce może zachodzić konieczność umieszczenia wielu generacji KM w pojedynczej karcie warsztatowej lub pojedynczej karcie kontrolnej.
CSM_128 MSCA prowadzi rejestry wszystkich wygenerowanych kluczy DSRC specyficznych dla VU, ich numerów wersji i numerów seryjnych VU lub identyfikatorów wniosku o certyfikat wykorzystanych w celu ich wyprowadzenia.
9.2.2.2 Zastąpienie klucza głównego DSRC
CSM_129 Każdy klucz główny DSRC jest powiązany z określoną generacją pary kluczy głównych ERCA. ERCA zastępuje zatem klucz główny DSRC co 17 lat. Okres ważności każdej generacji klucza głównego DSRC rozpoczyna się dwa lata wcześniej, zanim powiązana para kluczy głównych ERCA stanie się ważna, i kończy się po upływie ważności powiązanej pary kluczy głównych ERCA. Przedstawiono to na rys. 3.
Rys. 3
Wydawanie różnych generacji klucza głównego DSRC i ich używanie w przyrządach rejestrujących, kartach warsztatowych i kartach kontrolnych
CSM_130 Co najmniej dwa lata przed wygenerowaniem nowej pary europejskich kluczy głównych, jak opisano w CSM_56, ERCA generuje nowy klucz główny DSRC. Długość klucza DSRC jest powiązana z przewidywaną siłą nowej pary europejskich kluczy głównych zgodnie z CSM_50. Na wniosek MSCA ERCA przekazuje im nowy klucz główny DSRC wraz z jego numerem wersji.
CSM_131 MSCA zapewnia, aby wszystkie ważne generacje KMDSRC były przechowywane na karcie kontrolnej wydanej z jego upoważnienia wraz z numerami wersji, jak przedstawiono na rys. 3.
Uwaga: oznacza to, że w ciągu ostatnich dwóch lat okresu ważności certyfikatu ERCA karty kontrolne będą wydawane z trzema różnymi generacjami KMDSRC, jak przedstawiono na rys. 3.
CSM_132 MSCA zapewnia, aby wszystkie generacje KMDSRC, które były ważne przez co najmniej rok i nadal są ważne, były przechowywane na karcie warsztatowej wydanej z jego upoważnienia wraz z numerami wersji, jak przedstawiono na rys. 3.
Uwaga: oznacza to, że w ostatnim roku okresu ważności certyfikatu ERCA karty warsztatowe będą wydawane z trzema różnymi generacjami KMDSRC, jak przedstawiono na rys. 3.
CSM_133 Producenci przyrządów rejestrujących umieszczają tylko jeden zestaw kluczy DSRC specyficznych dla VU w każdym przyrządzie rejestrującym wraz z jego numerem wersji. Wspomniany zestaw kluczy wyprowadza się z generacji KMDSRC powiązanej z certyfikatem ERCA, na którym opierają się certyfikaty VU.
Uwagi
- Oznacza to, że przyrząd rejestrujący oparty na certyfikacie ERCA generacji X zawiera jedynie K_VUDSRC_ENC i K_VUDSRC_MAC generacji X, nawet jeżeli VU został wydany po rozpoczęciu okresu ważności certyfikatu ERCA generacji X + 1. Przedstawiono to na rys. 3.
- Ze względu na fakt, że okres ważności kart warsztatowych wynosi jeden rok, a kart kontrolnych dwa lata, w wyniku zastosowania CSM_131 - CSM_133 wszystkie karty warsztatowe i karty kontrolne będą zawierały nowy klucz główny DSRC w momencie wydania pierwszego VU zawierającego klucze specyficzne dla VU, oparte na przedmiotowym kluczu głównym.
9.3. Certyfikaty
9.3.1 Uwagi ogólne
CSM_134 Wszystkie certyfikaty w europejskim systemie tachografów inteligentnych są certyfikatami samoopi-sującymi, weryfikowalnymi przez kartę (CV) zgodnie z normami [ISO 7816-4] i [ISO 7816-8].
CSM_135 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.
Uwaga: w wyniku takiego kodowania uzyskuje się następującą strukturę TLV:
znacznik: znacznik jest zakodowany w jednym oktecie lub dwóch oktetach i określa treść;
długość: długość jest zakodowana jako liczba całkowita bez znaku w jednym oktecie, dwóch lub trzech oktetach, co skutkuje uzyskaniem maksymalnej długości 65 535 oktetów. Stosuje się minimalną liczbę oktetów;
wartość: wartość nie jest zakodowana w żadnym oktecie lub jest zakodowana w większej liczbie oktetów.
9.3.2 Treść certyfikatu
CSM_136 Wszystkie certyfikaty mają strukturę przedstawioną w profilu certyfikatu w tabeli 4.
Tabela 4
Wersja 1 profilu certyfikatu
| Pole | Nr ID pola | Znacznik | Długość (bajty) | Typ danych ASN.1 (zob. dodatek 1) |
| Certyfikat ECC | C | '7F 21' | var | |
| Treść certyfikatu ECC | B | '7F 4E' | var | |
| Identyfikator profilu certyfikatu | CPI | '5F 29' | '01' | INTEGER(0..255) |
| odniesienie do organu certyfikacji | CAR | '42' | '08' | Keyldentifier |
| upoważnienie posiadacza certyfikatu | CHA | '5F 4C' | '07' | ČertificateHolder Authorisation |
| Klucz publiczny | PK | '7F 49' | var | |
| Parametry domeny | DP | '06' | var | IDENTYFIKATOR OBIEKTU |
| Punkt publiczny | PP | '86' | var | OCTET STRING |
| odniesienie do posiadacza certyfikatu | CHR | '5F 20' | '08' | Keyldentifier |
| Data wejścia w życie certyfikatu | CEfD | '5F 25' | '04' | TimeReal |
| Data wygaśnięcia certyfikatu | CExD | '5F 24' | '04' | TimeReal |
| Podpis certyfikatu ECC | S | '5F 37' | var | OCTET STRING |
Uwaga: identyfikator pola zostanie wykorzystany w dalszych częściach niniejszego dodatku w celu wskazania poszczególnych pól certyfikatu np. X.CAR oznacza odniesienie do organu certyfikacji, o którym mowa w certyfikacie użytkownika X.
9.3.2.1 Identyfikator profilu certyfikatu
CSM_137 Certyfikaty używają identyfikatora profilu certyfikatu do wskazania użytego profilu certyfikatu. Wersję 1, jak wskazano w tabeli 4, określa się za pomocą wartości '00'.
9.3.2.2 Odniesienie do organu certyfikacji
CSM_138 Odniesienie do organu certyfikacji wykorzystuje się do określenia klucza publicznego, który ma zostać użyty do weryfikacji podpisu certyfikatu. Odniesienie do organu certyfikacji pokrywa się zatem z odniesieniem do posiadacza certyfikatu w certyfikacie odpowiedniego organu certyfikacji.
CSM_139 Certyfikat główny ERCA jest certyfikatem z podpisem własnym, tj. odniesienie do organu certyfikacji pokrywa się z odniesieniem do posiadacza certyfikatu w certyfikacie.
CSM_140 W przypadku certyfikatu łączącego ERCA odniesienie do posiadacza certyfikatu pokrywa się z odniesieniem do posiadacza certyfikatu nowego certyfikatu głównego ERCA. W przypadku certyfikatu łączącego odniesienie do organu certyfikacji pokrywa się z odniesieniem do posiadacza certyfikatu poprzedniego certyfikatu głównego ERCA.
9.3.2.3 Upoważnienie posiadacza certyfikatu
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).
9.3.2.4 Klucz publiczny
Klucz publiczny zawiera dwa elementy danych: standardowe parametry domeny stosowane z kluczem publicznym w certyfikacie i wartość punktu publicznego.
CSM_142 Element danych "parametry domeny" zawiera jeden z identyfikatorów obiektu określony w tabeli 1 w celu odniesienia do zestawu standardowych parametrów domeny.
CSM_143 Element danych "punkt publiczny" zawiera punkt publiczny. Punkty publiczne krzywej eliptycznej przekształca się w ciągi oktetowe, jak określono w [TR-03111]. Stosuje się nieskompresowany format kodowania. Podczas odzyskiwania punktu krzywej eliptycznej z jej zakodowanego formatu zawsze przeprowadza się autoryzacje opisane w [TR-03111].
9.3.2.5 odniesienie do posiadacza certyfikatu
CSM_144 Odniesienie do posiadacza certyfikatu to identyfikator klucza publicznego umieszczony w certyfikacie. Używa się go celem odniesienia do tego klucza publicznego w innych certyfikatach.
CSM_145 W przypadku certyfikatów kart i certyfikatów urządzeń zewnętrznych GNSS odniesienie do posiadacza certyfikatu posiada typ danych ExtendedSerialNumber, określony w dodatku 1.
CSM_146 W przypadku przyrządów rejestrujących producent, składając wniosek o certyfikat, może znać specyficzny dla danego producenta numer seryjny VU, dla którego przeznaczony jest dany certyfikat i powiązany klucz prywatny, ale nie musi go znać. W pierwszym przypadku odniesienie do posiadacza certyfikatu posiada typ danych ExtendedSerialNumber, określony w dodatku 1. W tym drugim przypadku odniesienie do posiadacza certyfikatu posiada typ danych Certif icateRequestID, określony w dodatku 1.
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 sensorGNSSSe-rialNumber 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.
CSM_147 W przypadku certyfikatów ERCA i MSCA odniesienie do posiadacza certyfikatu posiada typ danych Certif icationAuthorityKlD, określony w dodatku 1.
9.3.2.6 Data wejścia w życie certyfikatu
CSM_148 Data wejścia w życie certyfikatu określa datę i godzinę rozpoczęcia okresu ważności certyfikatu.
9.3.2.7 Data wygaśnięcia certyfikatu
CSM_149 Data wygaśnięcia certyfikatu określa datę i godzinę zakończenia okresu ważności certyfikatu.
9.3.2.8 Podpis certyfikatu
CSM_150 Podpis na certyfikacie tworzy się nad zakodowaną treścią certyfikatu, uwzględniając znacznik i długość treści certyfikatu. Algorytmem podpisu jest ECDSA, jak określono w [DSS], używający algorytmu skrótu powiązanego z wielkością klucza jednostki podpisującej, jak określono w CSM_50. Format podpisu jest odkryty, jak określono w [TR-03111].
9.3.3 Składanie wniosków o certyfikaty
CSM_151 Składając wniosek o certyfikat, MSCA przesyła ERCA następujące dane:
- identyfikator profilu certyfikatu, którego dotyczy wniosek;
- odniesienie do organu certyfikacji, w przypadku którego oczekuje się, że zostanie użyte do podpisania certyfikatu;
- klucz publiczny, który ma zostać podpisany.
CSM_152 Oprócz danych określonych w CSM_151 MSCA przesyła ERCA następujące dane we wniosku o certyfikat, co umożliwi ERCA utworzenie odniesienia do posiadacza certyfikatu dla nowego certyfikatu MSCA:
- numeryczny kod krajowy organu certyfikacji (typ danych NationNumeric, określony w dodatku 1);
- alfanumeryczny kod krajowy organu certyfikacji (typ danych NationAlpha, określony w dodatku 1);
- 1-bajtowy numer seryjny umożliwiającym rozróżnienie poszczególnych kluczy organu certyfikacji w przypadku zmiany kluczy;
- 2-bajtowe pole zawierające dodatkowe informacje na temat określonego organu certyfikacji.
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.
CSM_154 W przypadku VU producent, składając wniosek o certyfikat, może znać specyficzny dla danego producenta numer seryjny VU, dla którego przeznaczony jest dany certyfikat i powiązany klucz prywatny, ale nie musi go znać. Producent VU przesyła MSCA numer seryjny, jeżeli jest on znany. Jeżeli nie jest znany, producent jednoznacznie identyfikuje każdy wniosek o certyfikat i przesyła MSCA taki numer seryjny wniosku o certyfikat. Otrzymany certyfikat będzie wówczas zawierał numer seryjny wniosku o certyfikat. Po umieszczeniu certyfikatu w określonym VU producent informuje MSCA o połączeniu między numerem seryjnym wniosku o certyfikat a identyfikacją VU.
10. WZAJEMNE UWIERZYTELNIANIE I BEZPIECZNA WYMIANA KOMUNIKATÓW MIĘDZY VU A KARTĄ
10.1. Uwagi ogólne
CSM_155 Na wysokim szczeblu bezpieczna łączność między przyrządem rejestrującym a kartą do tachografu odbywa się w następujących etapach:
- po pierwsze każda strona wykazuje drugiej, że posiada ważny certyfikat klucza publicznego, podpisany przez organ certyfikacji Strony. Z kolei certyfikat klucza publicznego MSCA musi zostać podpisany przez Główny Europejski Organ Certyfikacji. Etap ten nazywany jest weryfikacją łańcucha certyfikatów i został szczegółowo opisany w sekcji 10.2;
- po drugie przyrząd rejestrujący wykazuje karcie, że posiada klucz prywatny odpowiadający kluczowi publicznemu w przedstawionym certyfikacie. Dokonuje tego poprzez podpisanie losowego numeru wysłanego przez kartę. Karta weryfikuje podpis na losowym numerze. Jeżeli weryfikacja zakończy się powodzeniem, VU zostaje uwierzytelniony. Etap ten nazywany jest uwierzytelnieniem VU i został szczegółowo opisany w sekcji 10.3;
- po trzecie obie strony niezależnie obliczają dwa klucze sesji AES, korzystając z asymetrycznego algorytmu uzgadniania klucza. Korzystając z jednego z tych kluczy sesji karta tworzy kod uwierzytelniania komunikatów (MAC) w odniesieniu do niektórych danych wysłanych przez VU. VU weryfikuje MAC. Jeżeli weryfikacja zakończy się powodzeniem, karta zostaje uwierzytelniona. Etap ten nazywany jest uwierzytelnieniem karty i został szczegółowo opisany w sekcji 10.4;
- po czwarte VU i karta używają zatwierdzonych kluczy sesji w celu zapewnienia poufności, integralności i autentyczności wszystkich wymienianych komunikatów. Etap ten nazywany jest bezpieczną wymianą komunikatów i został szczegółowo opisany w sekcji 10.5.
CSM_156 Mechanizm opisany w CSM_155 jest uruchamiany przez przyrząd rejestrujący za każdym razem, gdy w jeden z czytników kart zostaje włożona karta.
10.2. Wzajemna weryfikacja łańcucha certyfikatów
10.2.1 Weryfikacja łańcucha certyfikatów karty przez VU
CSM_157 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.
Uwagi do rys. 4:
- certyfikaty i klucze publiczne karty wskazane na rysunku są certyfikatami i kluczami, których używa się do wzajemnego uwierzytelnienia. W sekcji 9.1.5 oznaczono je jako Card_MA;
- certyfikaty i klucze publiczne Card.CA wskazane na rysunku są certyfikatami i kluczami używanymi do podpisywania certyfikatów karty i jest to wskazane w CAR certyfikatu Card.CA. W sekcji 9.1.3 oznaczono je jako MSCA_Card;
- certyfikat Card.CA.EUR wspomniany na rysunku jest europejskim certyfikatem głównym wskazanym w CAR certyfikatu Card.CA;
- certyfikat Card.Link wskazany na rysunku jest certyfikatem łączącym karty, o ile istnieje. Jak określono w sekcji 9.1.2, jest to certyfikat łączący dla nowej pary europejskich kluczy głównych wygenerowanej przez ERCA i podpisanej za pomocą poprzedniego europejskiego klucza prywatnego;
- certyfikat Card.Link.EUR jest europejskim certyfikatem głównym wskazanym w CAR certyfikatu Card.Link.
CSM_158 Jak wskazano na rys. 4, weryfikacja łańcucha certyfikatów karty rozpoczyna się po włożeniu karty. Przyrząd rejestrujący odczytuje odniesienie do posiadacza karty (cardExtendedSerialNumber) z pliku elementarnego ICC. VU sprawdza, czy zna kartę tj. czy pomyślnie zweryfikował łańcuch certyfikatów karty w przeszłości i zapisało go na potrzeby przyszłych odniesień. Jeżeli VU zna kartę, certyfikat karty nadal jest ważny, a proces jest kontynuowany i następuje weryfikacja łańcucha certyfikatów VU. W przeciwnym razie VU kolejno odczytuje z karty certyfikat MSCA_Card, który ma służyć do weryfikacji certyfikatu karty Card.CA, certyfikat EUR, który ma służyć do weryfikacji certyfikatu MSCA_Card, oraz ewentualnie certyfikat łączący, do momentu aż znajdzie certyfikat, który rozpozna lub może zweryfikować. Jeżeli znajdzie taki certyfikat, VU używa tego certyfikatu w celu zweryfikowania podstawowych certyfikatów karty, które odczytał z karty. Jeżeli proces przebiegnie pomyślnie, nastąpi weryfikacja łańcucha certyfikatów VU. Jeżeli nie, VU zignoruje kartę.
Uwaga: istnieją trzy sposoby na rozpoznanie certyfikatu Card.CA.EUR przez VU:
- certyfikat Card.CA.EUR jest taki sam jak certyfikat EUR VU;
- certyfikat Card.CA.EUR poprzedza certyfikat EUR VU i VU zawierał już ten certyfikat w chwili wydania (zob. CSM_81);
- certyfikat Card.CA.EUR zastępuje certyfikat EUR VU i VU otrzymał w przeszłości certyfikat łączący z innej karty do tachografu, zweryfikował go i zapisał na potrzeby przyszłych odniesień.
CSM_159 Jak wskazano na rys. 4, po zweryfikowaniu przez VU autentyczności i ważności uprzednio nieznanego certyfikatu VU może zapisać ten certyfikat na potrzeby przyszłych odniesień, tak aby nie musiał po raz kolejny weryfikować autentyczności tego certyfikatu, gdy zostanie mu ponownie przedstawiony. Zamiast zapisywać cały certyfikat, VU może zdecydować się na zapisanie jedynie treści certyfikatu, jak określono w sekcji 9.3.2. Zważywszy że przechowywanie wszystkich pozostałych typów certyfikatu jest fakultatywne, VU musi przechowywać nowy certyfikat łączący przedstawiony przez kartę.
CSM_160 VU weryfikuje czasową ważność każdego certyfikatu odczytanego z karty lub przechowywanego w jej pamięci i odrzuca certyfikaty, które wygasły. W celu zweryfikowania czasowej ważności certyfikatu przedstawionego przez kartę VU używa swojego wewnętrznego zegara.
Rys. 4
Protokół weryfikacji łańcucha certyfikatów karty przez VU
10.2.2 Weryfikacja łańcucha certyfikatów VU przez kartę
CSM_161 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).
Rys. 5
Protokół weryfikacji łańcucha certyfikatów VU przez kartę
Uwagi do rys. 5:
- certyfikaty i klucze publiczne VU wskazane na rysunku są certyfikatami i kluczami, których używa się do wzajemnego uwierzytelnienia. W sekcji 9.1.4 oznaczono je jako VU_MA;
- certyfikaty i klucze publiczne VU.CA wskazane na rysunku są certyfikatami i kluczami używanymi do podpisywania certyfikatów VU i urządzenia zewnętrznego GNSS. W sekcji 9.1.3 oznaczono je jako MSCA_VU-EGF;
- certyfikat VU.CA.EUR przedstawiony na rysunku jest europejskim certyfikatem głównym wskazanym w CAR certyfikatu VU.CA;
- certyfikat VU.Link wskazany na rysunku jest certyfikatem łączącym VU, o ile istnieje. Jak określono w sekcji 9.1.2, jest to certyfikat łączący dla nowej pary europejskich kluczy głównych wygenerowanej przez ERCA i podpisanej za pomocą poprzedniego europejskiego klucza prywatnego;
- certyfikat VU.Link.EUR jest europejskim certyfikatem głównym wskazanym w CAR certyfikatu VU.Link.
CSM_162 Jak wskazano na rys. 5, weryfikacja łańcucha certyfikatów przyrządu rejestrującego rozpoczyna się, gdy przyrząd rejestrujący podejmuje próbę ustawienia swojego własnego klucza publicznego w celu użycia go w karcie do tachografu. Jeżeli proces ten powiedzie się, oznacza to, że karta pomyślnie zweryfikowała łańcuch certyfikatów VU w przeszłości i zapisała certyfikat VU na potrzeby przyszłych odniesień. W tym przypadku certyfikat VU ustawia się jako używany, a proces jest kontynuowany i następuje uwierzytelnienie VU. Jeżeli karta nie zna certyfikatu VU, VU kolejno przedstawia certyfikat VU.CA, który ma służyć do weryfikacji certyfikatu VU, certyfikat VU.CA. EUR, który ma służyć do weryfikacji certyfikatu VU.CA, oraz ewentualnie certyfikat łączący, w celu znalezienia certyfikatu rozpoznanego lub weryfikowalnego przez kartę. W przypadku znalezienia takiego certyfikatu karta używa tego certyfikatu do zweryfikowania podstawowych certyfikatów VU przedstawionych jej przez VU. Jeżeli proces przebiegnie pomyślnie, VU ostatecznie ustawi swój klucz publiczny do używania w karcie do tachografu. Jeżeli nie, VU zignoruje kartę.
Uwaga: istnieją dwa sposoby na rozpoznanie certyfikatu VU.CA.EUR:
- certyfikat VU.CA.EUR jest taki sam jak certyfikat EUR karty;
- certyfikat VU.CA.EUR poprzedza certyfikat EUR karty i karta zawierała już ten certyfikat w chwili wydania (zob. CSM_91);
- certyfikat VU.CA.EUR zastępuje certyfikat EUR karty i karta otrzymała w przeszłości certyfikat łączący z innego przyrządu rejestrującego, zweryfikowała go i zapisała na potrzeby przyszłych odniesień.
CSM_163 VU używa polecenia MSE:Set AT, aby ustawić swój klucz publiczny do używania w karcie do tachografu. Jak określono w dodatku 2, polecenie to zawiera opis mechanizmu kryptograficznego, który będzie używany wraz z ustawionym kluczem. Mechanizm ten określa się mianem uwierzytelnienia VU za pomocą algorytmu ECDSA w połączeniu z algorytmem skrótu powiązanym z wielkością pary kluczy VU VU_MA, jak określono w CSM_50.
CSM_164 Polecenie MSE: Set AT zawiera również opis pary kluczy efemerycznych, których VU będzie używał podczas uzgadniania klucza sesji (zob. sekcja 10.4). W związku z tym przed wysłaniem polecenia MSE: Set AT VU generuje parę kluczy efemerycznych ECC. W celu wygenerowania pary kluczy efemerycznych VU używa standardowych parametrów domeny wskazanych w certyfikacie karty. Parę kluczy efemerycznych oznacza się jako (VU.SKeph, VU.PKeph, Card.DP). VU uznaje współrzędną x efemerycznego punktu publicznego ECDH za identyfikację klucza; określa się to mianem skompresowanej reprezentacji klucza publicznego i oznacza jako Comp(VU.PKeph).
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.
CSM_166 Karta weryfikuje czasową ważność każdego certyfikatu przedstawionego przez VU lub wskazanego przez VU przez odniesienie i zapisanego w pamięci karty i odrzuca certyfikaty, które wygasły.
CSM_167 W celu zweryfikowania czasowej ważności certyfikatu przedstawionego przez VU każda karta do tachografu zapisuje wewnętrznie niektóre dane pokazujące czas bieżący. Dane te nie mogą podlegać bezpośredniej aktualizacji przez VU. W momencie wydania czas bieżący karty ustawia się tak, aby odpowiadał dacie wejścia w życie certyfikatu karty Card_MA. Karta aktualizuje swój czas bieżący, jeżeli data wejścia w życie autentycznego certyfikatu będącego "wiarygodnym źródłem czasu" i przedstawionego przez VU jest późniejsza niż czas bieżący określony na karcie. W takim przypadku karta ustawia swój czas bieżący zgodnie z datą wejścia w życie takiego certyfikatu. Za wiarygodne źródło czasu karta uznaje wyłącznie następujące certyfikaty:
- certyfikaty łączące ERCA drugiej generacji
- certyfikaty MSCA drugiej generacji
- certyfikaty VU drugiej generacji wydane przez to samo państwo, które wydało certyfikaty własne karty.
Uwaga: ostatni wymóg oznacza, że karta jest w stanie rozpoznać CAR certyfikatu VU, tj. certyfikatu MSCA_VU-EGF. Nie będzie się on pokrywał z CAR certyfikatu własnego karty, którym jest certyfikat MSCA_Card.
CSM_168 Jak wskazano na rys. 5, po zweryfikowaniu przez kartę autentyczności i ważności uprzednio nieznanego certyfikatu, karta może zapisać ten certyfikat na potrzeby przyszłych odniesień, tak aby nie musiała po raz kolejny weryfikować autentyczności tego certyfikatu, gdy zostanie jej ponownie przedstawiony. Zamiast zapisywać cały certyfikat, karta może zdecydować się na zapisanie jedynie treści certyfikatu, jak określono w sekcji 9.3.2.
10.3. Uwierzytelnienie VU
CSM_169 Przyrządy rejestrujące i karty używają protokołu uwierzytelniania Vu wskazanego na rys. 6 w celu uwierzytelnienia VU w stosunku do karty. Uwierzytelnienie VU umożliwia karcie do tachografu wyraźne zweryfikowanie, że VU jest autentyczny. W tym celu VU używa swojego klucza prywatnego do podpisania żądania wygenerowanego przez kartę.
CSM_170 Oprócz żądania karty VU umieszcza w podpisie odniesienie do posiadacza certyfikatu uzyskane z certyfikatu karty.
Uwaga: gwarantuje to, że karta, w odniesieniu do której VU się uwierzytelnia, jest tą samą kartą, której łańcuch certyfikatów został wcześniej zweryfikowany przez VU.
CSM_171 VU umieszcza również w podpisie identyfikator efemerycznego klucza publicznego Comp(VU. PKeph), z którego będzie korzystał w celu ustanowienia bezpiecznej wymiany komunikatów podczas procesu uwierzytelniania chipu określonego w sekcji 10.4.
Uwaga: gwarantuje to, że VU, z którym karta komunikuje się podczas sesji bezpiecznej wymiany komunikatów, jest tym samym VU, który został uwierzytelniony przez kartę.
Rys. 6
Protokół uwierzytelniania VU
CSM_172 Jeżeli VU wysyła wielokrotnie polecenie GET CHALLENGE podczas uwierzytelniania VU, karta zwraca za każdym razem nowe 8-bajtowe losowe żądanie, ale zapisuje tylko ostatnie żądanie.
CSM_173 Algorytmem podpisywania używanym przez VU w celu uwierzytelnienia VU jest ECDSA, jak określono w [DSS], używający algorytmu skrótu powiązanego z wielkością klucza pary kluczy VU VU_MA, jak określono w CSM_50. Format podpisu jest odkryty, jak określono w [TR-03111]. VU przesyła uzyskany podpis karcie.
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.
10.4. Uwierzytelnianie chipu i uzgadnianie klucza sesji
CSM_175 Przyrządy rejestrujące i karty korzystają z protokołu uwierzytelniania chipu wskazanego na rys. 7 w celu uwierzytelnienia karty w stosunku do VU. Uwierzytelnienie chipu umożliwia przyrządowi rejestrującemu wyraźne zweryfikowanie, że karta jest autentyczna.
Rys. 7
Uwierzytelnianie chipu i uzgadnianie klucza sesji
CSM_176 VU i karta podejmują następujące kroki:
1. przyrząd rejestrujący inicjuje proces uwierzytelniania chipu poprzez wysłanie polecenia MSE: Set AT określającego uwierzytelnianie chipu za pomocą algorytmu ECDH, w wyniku którego długość klucza sesji AES jest powiązana z wielkością klucza w parze kluczy karty Card_MA, jak określono w CSM_50. VU określa wielkość klucza w parze kluczy karty na podstawie certyfikatu karty;
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;
3. karta oblicza Comp(VU.PKeph) na podstawie VU.PKeph i porównuje go z zapisaną wartością Comp(VU.PKeph);
4. używając algorytmu ECDH w połączeniu ze statycznym kluczem prywatnym karty i efemerycznym kluczem publicznym VU, karta oblicza tajny K;
5. karta wybiera losowy 8-bajtowy identyfikator jednorazowy NPICC i używa go do wyprowadzenia dwóch kluczy sesji AES KMAC i KENC z K. Zob. CSM_179;
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;
7. używając algorytmu ECDH w połączeniu ze statycznym kluczem publicznym karty i efemerycznym kluczem prywatnym VU, przyrząd rejestrujący oblicza ten sam tajny K co karta w ramach kroku 4;
8. VU wyprowadza klucze sesji Kmac i Kenc z K i Npicc; zob. CSM_179;
9. VU weryfikuje token uwierzytelniania Tpicc.
CSM_177 W ramach powyższego kroku 3 karta oblicza Comp(VU.PKeph) jako współrzędną x punktu publicznego w VU.PKeph.
CSM_178 W ramach powyższych kroków 4 i 7 karta i przyrząd rejestrujący używają algorytmu ECKA-EG, jak określono w [TR-03111].
CSM_179 W ramach powyższych kroków 5 i 8 karta i przyrząd rejestrujący używają funkcji wyprowadzania klucza w odniesieniu do kluczy sesji AES zdefiniowanych w [TR-03111] z następującą dokładnością i następującymi zmianami:
- wartość licznika wynosi '00 00 00 01' w odniesieniu do Kenc i '00 00 00 02' w odniesieniu do Kmac;
- używa się opcjonalnego identyfikatora jednorazowego r, który jest równy Npicc;
- w celu wyprowadzenia 128-bitowych kluczy AES używa się algorytmu skrótu SHA-256;
- w celu wyprowadzenia 192-bitowych kluczy AES używa się algorytmu skrótu SHA-384;
- w celu wyprowadzenia 256-bitowych kluczy AES używa się algorytmu skrótu SHA-512.
Długość kluczy sesji (tj. długość, do której skrócono skrót) jest powiązana z wielkością pary kluczy Card_MA, jak określono w CSM_50.
CSM_180 W powyższych krokach 6 i 9 karta i przyrząd rejestrujący używają algorytmu AES w trybie CMAC, jak określono w [SP 800-38B]. Długość Tpicc jest powiązana z długością kluczy sesji AES, jak określono w CSM_50.
10.5. Bezpieczna wymiana komunikatów
10.5.1 Uwagi ogólne
CSM_181 Wszystkie polecenia i odpowiedzi wymieniane między przyrządem rejestrującym a kartą do tachografu po pomyślnym uwierzytelnieniu chipu oraz do zakończenia sesji są chronione za pomocą bezpiecznej wymiany komunikatów.
CSM_182 Z wyjątkiem sytuacji, w której ma miejsce odczyt z pliku z warunkiem dostępu SM-R-ENC-MAC-G2 (zob. dodatek 2 sekcja 4), bezpieczną wymianę komunikatów stosuje się w trybie tylko uwierzytelniania. W tym trybie kryptograficzną sumę kontrolną (zwaną również MAC) dodaje się do wszystkich poleceń i odpowiedzi w celu zapewnienia autentyczności i integralności komunikatów.
CSM_183 Przy odczycie danych z pliku z warunkiem dostępu SM-R-ENC-MAC-G2 bezpieczną wymianę komunikatów stosuje się w trybie uwierzytelniania po wcześniejszym zaszyfrowaniu, co oznacza, że dane odpowiedzi najpierw są szyfrowane w celu zapewnienia poufności komunikatu, a następnie obliczany jest MAC w stosunku do sformatowanych zaszyfrowanych danych w celu zapewnienia autentyczności i integralności.
CSM_184 W ramach bezpiecznej wymiany komunikatów stosuje się AES określony w [AES] z kluczami sesji Kmac i Kenc uzgodnionymi w procesie uwierzytelniania chipu.
CSM_185 Jako licznik sekwencji wysyłania (SSC) stosuje się liczbę całkowitą bez znaku w celu zapobieżenia atakom przez powtórzenie. Rozmiar SSC jest równy rozmiarowi bloku AES, tj. wynosi 128 bitów. SSC ma format, w którym najbardziej znaczący bit znajduje się na początku. Licznik sekwencji wysyłania jest zerowany (tj. ma wartość '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00') w momencie rozpoczęcia bezpiecznej wymiany komunikatów. Wartość SSC jest zwiększana przed każdym wygenerowaniem polecenia lub odpowiedzi APDU, czyli ponieważ wartością początkową SSC w sesji bezpiecznej wymiany komunikatów jest 0, wartość SSC w pierwszym poleceniu będzie wynosiła 1. Wartość SSC dla pierwszej odpowiedzi będzie wynosiła 2.
CSM_186 W przypadku szyfrowania komunikatów stosuje się klucz KENC z AES w trybie wiązania bloków zaszyfrowanych, jak określono w normie [ISO 10116], z naprzemiennym parametrem m = 1 oraz wektorem inicjującym SV = E(KENC, SSC), tj. bieżącą wartością licznika sekwencji wysyłania zaszyfrowanego kluczem KENC.
CSM_187 Do uwierzytelniania komunikatów stosuje się klucz KMAC z AES w trybie CMAC, jak określono w [SP 800-38B]. Długość MAC jest powiązana z długością kluczy sesji AES, jak określono w CSM_50. Licznik sekwencji wysyłania uwzględnia się w MAC poprzez dodanie go przed datagramem, który ma zostać uwierzytelniony.
10.5.2 Struktura bezpiecznego komunikatu
CSM_188 W bezpiecznej wymianie komunikatów używa się wyłącznie obiektów danych bezpiecznej wymiany komunikatów (zob. [ISO 7816-4]) wymienionych w tabeli 5. W każdym komunikacie wspomniane obiekty danych stosuje się w kolejności określonej w poniższej tabeli.
Tabela 5
Obiekty danych bezpiecznej wymiany komunikatów
| Nazwa obiektu danych | Znacznik | Obecność: obowiązkowa (M), warunkowa (C) lub zabroniona (F) w | |
| poleceniach | odpowiedziach | ||
| Odkryta wartość niekodowana w BER-TLV | '81' | C | C |
| Odkryta wartość kodowana w BER-TLV, lecz nie zawiera obiektów danych bezpiecznej wymiany komunikatów | 'B3' | C | C |
| Po wskaźniku treści wypełnienia następuje kryptogram, wartość odkryta nie jest kodowana w BER-TLV | '87' | C | C |
| Chroniona długość | '97' | C | F |
| Status przetwarzania | '99' | F | M |
| Kryptograficzna suma kontrolna | '8E' | M | M |
Uwaga: jak określono w dodatku 2, karty do tachografu mogą obsługiwać polecenia READ BINARY i UPDATE BINARY z nieparzystym bajtem INS ('B1' odp. 'D7'). Wymaga się, aby przedstawione warianty poleceń umożliwiały odczyt i aktualizację plików o rozmiarze 32 768 bajtów lub więcej. W przypadku zastosowania takiego wariantu używa się obiektu danych ze znacznikiem 'B3' zamiast obiektu ze znacznikiem '81'. Aby uzyskać więcej informacji, zob. dodatek 2.
CSM_189 Wszystkie obiekty danych bezpiecznej wymiany komunikatów koduje się w DER TLV, jak określono w [ISO 8825-1]. W wyniku takiego kodowania uzyskuje się następującą strukturę TLV:
znacznik: znacznik jest zakodowany w jednym oktecie lub dwóch oktetach i określa treść;
długość: długość jest zakodowana jako liczba całkowita bez znaku w jednym oktecie, dwóch lub trzech oktetach, co skutkuje uzyskaniem maksymalnej długości 65 535 oktetów. Stosuje się minimalną liczbę oktetów;
wartość: wartość nie jest zakodowana w żadnym oktecie lub jest zakodowana w większej liczbie oktetów.
CSM_190 Polecenia APDU chronione bezpieczną wymianą komunikatów generuje się w następujący sposób:
- nagłówek polecenia uwzględnia się w obliczeniach MAC, w związku z czym wartość '0C' stosuje się w przypadku klasy bajtów CLA;
- jak określono w dodatku 2, wszystkie bajty INS są parzyste, ewentualnie z wyjątkiem nieparzystych bajtów INS w przypadku poleceń READ BINARY i UPDATE BINARY;
- wartość rzeczywista Lc zostanie zmieniona na Lc' po zastosowaniu bezpiecznej wymiany komunikatów;
- pole danych składa się z obiektów danych bezpiecznej wymiany komunikatów;
- w chronionym poleceniu APDU nowy bajt Le otrzymuje wartość '00'. W razie konieczności obiekt danych '97' umieszcza się w polu danych w celu przekazania wartości oryginalnej bajtu Le.
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
10.5.3 Przerwanie sesji bezpiecznej wymiany komunikatów
CSM_192 Przyrząd rejestrujący przerywa trwającą sesję bezpiecznej wymiany komunikatów tylko i wyłącznie wówczas, gdy zaistnieje jeden z poniższych warunków:
- przyrząd otrzyma odkrytą odpowiedź APDU;
- przyrząd wykryje błąd bezpiecznej wymiany komunikatów w odpowiedzi APDU:
- brak oczekiwanego obiektu danych bezpiecznej wymiany komunikatów, nieprawidłową kolejność obiektów danych lub uwzględnienie nieznanego obiektu danych,
- nieprawidłowy obiekt danych bezpiecznej wymiany komunikatów, np. nieprawidłowa wartość MAC, nieprawidłową strukturę TLV lub wskaźnik wypełnienia w znaczniku '87' nie jest równy '01',
- karta wyśle bajt stanu wskazujący na wykrycie błędu bezpiecznej wymiany komunikatów (zob. CSM_194);
- osiągnięty zostanie limit dotyczący liczby poleceń i powiązanych odpowiedzi w ramach bieżącej sesji. Dla danego VU limit ten określa producent, uwzględniając wymogi bezpieczeństwa dotyczące używanego sprzętu, przy czym maksymalna liczba poleceń i powiązanych odpowiedzi w ramach bezpiecznej wymiany komunikatów wynosi 240 w każdej sesji.
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.
CSM_194 W odniesieniu do obsługi błędów w ramach bezpiecznej wymiany komunikatów przez kartę do tachografu:
- jeżeli w poleceniu APDU wystąpi brak niektórych oczekiwanych obiektów danych bezpiecznej wymiany komunikatów, kolejność obiektów danych jest nieprawidłowa lub zawarto nieznane obiekty danych, karta do tachografu wysyła odpowiedź zawierającą bajty stanu '69 87';
- jeżeli w poleceniu APDU obiekt danych bezpiecznej wymiany komunikatów jest nieprawidłowy, karta do tachografu wysyła odpowiedź zawierającą bajty stanu '69 88'.
W takim przypadku bajty stanu są odsyłane bez zastosowania bezpiecznej wymiany komunikatów.
CSM_195 Jeżeli sesja bezpiecznej wymiany komunikatów między VU a kartą do tachografu zostanie przerwana, VU i karta do tachografu:
- w bezpieczny sposób niszczą przechowywane klucze sesji;
- natychmiast ustanawiają nową sesję bezpiecznej wymiany komunikatów, jak opisano w sekcjach 10.2 - 10.5.
CSM_196 Jeżeli z jakiejkolwiek przyczyny VU zdecyduje się ponownie uruchomić proces wzajemnego uwierzytelniania w stosunku do włożonej karty, proces ten ponownie rozpoczyna się od weryfikacji łańcucha certyfikatów karty, jak opisano w sekcji 10.2, i jest kontynuowany, jak opisano w sekcjach 10.2-10.5.
11. POWIĄZANIE, WZAJEMNE UWIERZYTELNIANIE I BEZPIECZNA WYMIANA KOMUNIKATÓW MIĘDZY VU A URZĄDZENIEM ZEWNĘTRZNYM GNSS
11.1. Uwagi ogólne
CSM_197 Urządzenie GNSS wykorzystywane przez VU do ustalania jego położenia może być wewnętrzne (tj. wbudowane w obudowę VU i nieodłączalne) bądź też może stanowić moduł zewnętrzny. W pierwszym przypadku standaryzacja łączności wewnętrznej między urządzeniem GNSS a VU nie jest potrzebna, a wymogi określone w tym rozdziale nie mają zastosowania. W drugim przypadku łączność między VU a urządzeniem zewnętrznym GNSS wymaga standaryzacji i ochrony, jak opisano w tym rozdziale.
CSM_198 Bezpieczna łączność między przyrządem rejestrującym a urządzeniem zewnętrznym GNSS odbywa się na takiej samej zasadzie jak bezpieczna łączność między przyrządem rejestrującym a kartą do tachografu, przy czym urządzenie zewnętrzne GNSS przyjmuje rolę karty. Urządzenie zewnętrzne GNSS musi spełniać wszystkie wymogi, o których mowa w rozdziale 10 w odniesieniu do kart do tachografu, z uwzględnieniem odstępstw, wyjaśnień i uzupełnień przedstawionych w tym rozdziale. W szczególności procesy wzajemnej weryfikacji łańcucha certyfikatów, uwierzytelniania VU i uwierzytelniania chipu przeprowadza się w sposób opisany w sekcjach 11.3 i 11.4.
CSM_199 Łączność między przyrządem rejestrującym a EGF różni się od łączności między przyrządem rejestrującym a kartą pod takim względem, że przyrząd rejestrujący i EGF muszą zostać powiązane w warsztacie, zanim będą mogły dokonywać wymiany danych opartych na GNSS w trakcie normalnej pracy. Proces ustanawiania powiązania opisano w sekcji 11.2.
CSM_200 W przypadku łączności między przyrządem rejestrującym a EGF stosuje się polecenia i odpowiedzi APDU na podstawie [ISO 7816-4] i [ISO 7816-8]. Dokładną składnię tych poleceń i odpowiedzi APDU określono w dodatku 2 do niniejszego załącznika.
11.2. Ustanowienie powiązania między VU a urządzeniem zewnętrznym GNSS
CSM_201 Powiązanie między przyrządem rejestrującym a EGF w pojeździe ustanawia warsztat. W trakcie normalnej pracy tylko powiązany przyrząd rejestrujący i EGF mogą nawiązywać łączność.
CSM_202 Ustanowienie powiązania między przyrządem rejestrującym a EGF jest możliwe, wyłącznie gdy przyrząd rejestrujący znajduje się w trybie kalibracyjnym. Proces ustanawiania powiązania inicjuje przyrząd rejestrujący.
CSM_203 Warsztat może w dowolnym momencie ponownie połączyć przyrząd rejestrujący z innym lub z tym samym EGF. W trakcie ustanawiania ponownego połączenia VU w sposób bezpieczny niszczy istniejący certyfikat EGF_MA w jego pamięci i przechowuje certyfikat EGF_MA EGF, z którym jest powiązany.
CSM_204 Warsztat może w dowolnym momencie ponownie powiązać urządzenie zewnętrzne GNSS z innym lub tym samym VU. W trakcie ustanawiania ponownego powiązania EGF w sposób bezpieczny niszczy istniejący certyfikat VU_MA w jego pamięci i przechowuje certyfikat VU_MA VU, z którym jest wiązany.
11.3. Wzajemna weryfikacja łańcucha certyfikatów
11.3.1 Uwagi ogólne
CSM_205 Wzajemna weryfikacja łańcucha certyfikatów między VU a EGF odbywa się wyłącznie w trakcie procesu ustanawiania przez warsztat powiązania między VU a EGF. W czasie normalnej pracy powiązanego VU i EGF nie przeprowadza się weryfikacji certyfikatów. Zamiast tego VU i EGF ufają certyfikatom, które zapisały podczas ustanawiania powiązania, po sprawdzeniu czasowej ważności tych certyfikatów. VU i EGF nie mogą ufać żadnym innym certyfikatom dotyczącym ochrony łączności między VU a EGF w czasie normalnej pracy.
11.3.2 Podczas ustanawiania powiązania między VU a EGF
CSM_206 Podczas ustanawiania powiązania z EGF przyrząd rejestrujący używa protokołu przedstawionego na rys. 4 (sekcja 10.2.1) w celu weryfikacji łańcucha certyfikatów urządzenia zewnętrznego GNSS.
Uwagi do rys. 4 w tym kontekście:
- kontrola łączności nie jest objęta zakresem niniejszego dodatku. EGF nie jest jednak inteligentną kartą, a zatem VU prawdopodobnie nie wyśle komunikatu "Reset" w celu nawiązania łączności i nie otrzyma odpowiedzi na ponowne inicjowanie (ATR);
- certyfikaty i klucze publiczne karty wskazane na rysunku interpretuje się jako certyfikaty i klucze publiczne EGF na potrzeby wzajemnego uwierzytelniania. W sekcji 9.1.6 oznaczono je jako EGF_MA;
- certyfikaty i klucze publiczne Card.CA wskazane na rysunku interpretuje się jako certyfikaty i klucze publiczne MSCA na potrzeby podpisywania certyfikatów EGF. W sekcji 9.1.3 oznaczono je jako MSCA_VU-EGF;
- certyfikat Card.CA.EUR przedstawiony na rysunku interpretuje się jako europejski certyfikat główny wskazany w CAR certyfikatu MSCA_VU-EGF;
- certyfikat Card.Link wskazany na rysunku interpretuje się jako certyfikat łączący EGF, o ile istnieje. Jak określono w sekcji 9.1.2, jest to certyfikat łączący dla nowej pary europejskich kluczy głównych wygenerowanej przez ERCA i podpisanej za pomocą poprzedniego europejskiego klucza prywatnego;
- certyfikat Card.Link.EUR jest europejskim certyfikatem głównym wskazanym w CAR certyfikatu Card.Link.
- zamiast cardExtendedSerialNumber VU odczyta sensorGNSSserialNumber z pliku elementarnego ICC;
- zamiast AID tachografu VU wybiera AID EGF;
- komunikat "Ignore Card" interpretuje się jako komunikat "Ignore EGF".
CSM_207 Po zweryfikowaniu certyfikatu EGF_MA przyrząd rejestrujący zapisuje ten certyfikat do wykorzystania w czasie normalnej pracy; zob. sekcja 11.3.3.
CSM_208 Podczas ustanawiania powiązania z VU urządzenie zewnętrzne GNSS używa protokołu przedstawionego na rys. 5 (sekcja 10.2.2) w celu weryfikacji łańcucha certyfikatów VU.
Uwagi do rys. 5 w tym kontekście:
- VU generuje nową parę kluczy efemerycznych przy użyciu parametrów domeny określonych w certyfikacie EGF;
- certyfikaty i klucze publiczne VU wskazane na rysunku są certyfikatami i kluczami, których używa się do wzajemnego uwierzytelnienia. W sekcji 9.1.4 oznaczono je jako VU_MA;
- certyfikaty i klucze publiczne VU.CA wskazane na rysunku są certyfikatami i kluczami używanymi do podpisywania certyfikatów VU i urządzenia zewnętrznego GNSS. W sekcji 9.1.3 oznaczono je jako MSCA_VU-EGF;
- certyfikat VU.CA.EUR przedstawiony na rysunku jest europejskim certyfikatem głównym wskazanym w CAR certyfikatu VU.CA;
- certyfikat VU.Link wskazany na rysunku jest certyfikatem łączącym VU, o ile istnieje. Jak określono w sekcji 9.1.2, jest to certyfikat łączący dla nowej pary europejskich kluczy głównych wygenerowanej przez ERCA i podpisanej za pomocą poprzedniego europejskiego klucza prywatnego;
- certyfikat VU.Link.EUR jest europejskim certyfikatem głównym wskazanym w CAR certyfikatu VU.Link.
CSM_209 W odróżnieniu od wymogu CSM_167 EGF wykorzystuje czas GNSS do celów weryfikacji czasowej ważności każdego przedstawionego certyfikatu.
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.
11.3.3 W czasie normalnej pracy
CSM_211 W czasie normalnej pracy przyrząd rejestrujący i EGF używają protokołu wskazanego na rys. 11 w celu weryfikacji czasowej ważności przechowywanych certyfikatu EGF_MA oraz do celów ustalenia klucza publicznego VU_MA na potrzeby późniejszego uwierzytelnienia VU. W czasie normalnej pracy nie odbywa się dalsza wzajemna weryfikacja łańcuchów certyfikatów.
Należy zauważyć, że rys. 11 zasadniczo zawiera pierwsze kroki przedstawione na rys. 4 i rys. 5. Ponownie należy zauważyć, że ponieważ EGF nie jest inteligentną kartą, VU prawdopodobnie nie wyśle komunikatu "Reset" w celu nawiązania łączności i nie otrzyma ATR. W żadnym przypadku kwestia ta nie jest objęta zakresem niniejszego dodatku.
Rys. 11
Wzajemna weryfikacja czasowej ważności certyfikatu w czasie normalnej pracy VU-EGF
CSM_212 Jak przedstawiono na rys. 11, przyrząd rejestrujący rejestruje błąd, jeżeli certyfikat EGF_MA nie jest już aktualny. Wzajemne uwierzytelnienie, uzgodnienie klucza i późniejsza łączność za pośrednictwem bezpiecznej wymiany komunikatów odbywa się jednak normalnie.
11.4. Uwierzytelnienie VU, uwierzytelnienie chipu i uzgodnienie klucza sesji
CSM_213 Uwierzytelnienie VU, uwierzytelnienie chipu i uzgodnienie klucza sesji między VU a EGF odbywa się podczas ustanawiania powiązania oraz za każdym razem, gdy sesja bezpiecznej wymiany komunikatów jest ponownie ustanawiana w czasie normalnej pracy. VU i EGF przeprowadzają procesy opisane w sekcjach 10.3 i 10.4. Zastosowanie mają wszystkie wymogi określone w tych sekcjach.
11.5. Bezpieczna wymiana komunikatów
CSM_214 Wszystkie polecenia i odpowiedzi wymieniane między przyrządem rejestrującym a urządzeniem zewnętrznym GNSS po pomyślnym uwierzytelnieniu chipu i do zakończenia sesji są chronione za pomocą bezpiecznej wymiany komunikatów odbywającej się w trybie tylko uwierzytelniania. Zastosowanie mają wszystkie wymogi określone w sekcji 10.5.
CSM_215 W przypadku przerwania sesji bezpiecznej wymiany komunikatów między VU a EGF przyrząd rejestrujący natychmiast ustanawia nową sesję bezpiecznej wymiany komunikatów, jak opisano w sekcjach 11.3.3 i 11.4.
12. PAROWANIE VU Z CZUJNIKIEM RUCHU I ŁĄCZNOŚĆ MIĘDZY TYMI URZĄDZENIAMI
12.1. Uwagi ogólne
CSM_216 Łączność pomiędzy przyrządem rejestrującym a czujnikiem ruchu odbywa się za pomocą protokołu interfejsu określonego w [ISO 16844-3] w czasie parowania i normalnej pracy, z uwzględnieniem zmian opisanych w tym rozdziale oraz w sekcji 9.2.1.
Uwaga: zakłada się, że czytelnicy tego rozdziału są zaznajomieni z treścią normy [ISO 16844-3].
12.2. Parowanie VU z czujnikiem ruchu przy użyciu różnych generacji kluczy
Jak wyjaśniono w sekcji 9.2.1, klucz główny czujnika ruchu i wszystkie powiązane klucze są regularnie zastępowane. Skutkuje to obecnością do trzech kluczy AES KM-WC związanych z czujnikiem ruchu (kolejnych generacji kluczy) w kartach warsztatowych. Podobnie w czujnikach ruchu może występować do trzech różnych rodzajów szyfrowania danych opartych na AES (na podstawie kolejnych generacji klucza głównego czujnika ruchu KM). Przyrząd rejestrujący zawiera tylko jeden klucz KM-VU związany z czujnikiem ruchu.
CSM_217 Parowanie VU drugiej generacji i czujnika ruchu drugiej generacji odbywa się w sposób przedstawiony poniżej (por. tabela 6 w [ISO 16844-3]).
1. Kartę warsztatową drugiej generacji wkłada się do VU, który jest połączony z czujnikiem ruchu.
2. VU odczytuje wszystkie dostępne klucze KM-WC z karty warsztatowej, sprawdza ich numery wersji kluczy i wybiera klucz pasujący do numeru wersji klucza KM-VU VU. Jeżeli w karcie warsztatowej nie ma pasującego klucza KM-WC, VU przerywa proces parowania i wyświetla posiadaczowi karty warsztatowej odpowiedni komunikat o błędzie.
3. VU oblicza klucz główny czujnika ruchu KM na podstawie KM-VU i KM-WC oraz klucz identyfikacyjny KID na podstawie KM, jak określono w sekcji 9.2.1.
4. VU wysyła instrukcję rozpoczęcia procesu pasowania w stosunku do czujnika ruchu, jak opisano w normie [ISO 16844-3], i szyfruje numer seryjny otrzymany od czujnika ruchu za pomocą klucza identyfikacyjnego KID. VU wysyła zaszyfrowany numer seryjny z powrotem do czujnika ruchu.
5. Czujnik ruchu dopasowuje zaszyfrowany numer seryjny kolejno do każdego przechowywanego wewnętrznie zaszyfrowanego numeru seryjnego. Jeżeli znajdzie odpowiedni numer, VU zostaje uwierzytelniony. Czujnik ruchu rejestruje generację klucza KID użytego przez VU i przekazuje z powrotem pasującą zaszyfrowaną wersję klucza parowania; tj. zaszyfrowany numer stworzony przy zastosowaniu klucza KM tej samej generacji.
6. VU odszyfrowuje klucz parowania za pomocą klucza KM, generuje klucz sesji KS, szyfruje go za pomocą klucza parowania i wysyła uzyskany rezultat do czujnika ruchu. Czujnik ruchu odszyfrowuje klucz KS.
7. VU gromadzi informacje o parowaniu, jak określono w [ISO 16844-3], szyfruje te informacje za pomocą klucza parowania i wysyła uzyskany rezultat do czujnika ruchu. Czujnik ruchu odszyfrowuje informacje o parowaniu.
8. Czujnik ruchu szyfruje otrzymane informacje o parowaniu za pomocą otrzymanego klucza KS i przesyła te informacje z powrotem do VU. VU sprawdza, czy informacje o parowaniu są tymi samymi informacjami, które VU wysłał do czujnika ruchu w poprzednim kroku. Jeżeli tak, oznacza to, że czujnik ruchu użył tego samego klucza KS co VU i zgodnie z krokiem 5 wysłał swój klucz parowania zaszyfrowany za pomocą klucza KM prawidłowej generacji. Czujnik ruchu jest zatem uwierzytelniony.
Należy zauważyć, że kroki 2 i 5 różnią się od standardowego procesu określonego w [ISO 16844-3]; pozostałe kroki są krokami standardowymi.
Przykład: załóżmy, że proces parowania odbywa się w pierwszym roku ważności certyfikatu ERCA (3); zob. rys. 2 w sekcji 9.2.1.2. Ponadto
- załóżmy, że czujnik ruchu wydano w ostatnim roku ważności certyfikatu ERCA (1). Będzie zatem zawierał następujące klucze i dane:
- Ns[1]: swój numer seryjny zaszyfrowany kluczem KID 1. generacji;
- Ns[2]: swój numer seryjny zaszyfrowany kluczem KID 2. generacji;
- Ns[3]: swój numer seryjny zaszyfrowany kluczem KID 3. generacji;
- KP[1]: swój klucz parowania 1. generacji 32 , zaszyfrowany kluczem KM 1. generacji;
- KP[2]: swój klucz parowania 2. generacji, zaszyfrowany kluczem KM 2. generacji;
- KP[3]: swój klucz parowania 3. generacji, zaszyfrowany kluczem KM 3. generacji;
- załóżmy, że kartę warsztatową wydano w pierwszym roku ważności certyfikatu ERCA (3). Będzie zatem zawierała klucz KM-WC 2. i 3. generacji;
- załóżmy, że VU jest VU 2. generacji zawierającym klucz KM-VU 2. generacji. W takim przypadku w krokach 2-5 zajdą następujące procesy:
- krok 2: VU odczytuje klucze KM-WC 2. i 3. generacji z karty warsztatowej i sprawdza ich numery wersji;
- krok 3: VU łączy klucz KM-WC 2. generacji ze swoim kluczem KM-VU w celu obliczenia kluczy KM i KID;
- krok 4: VU szyfruje numer seryjny otrzymany od czujnika ruchu za pomocą klucza KID;
- krok 5: czujnik ruchu porównuje otrzymane dane z numerem Ns[1] i nie znajduje odpowiedniego numeru. Następnie porównuje dane z numerem Ns[2] i znajduje odpowiedni numer. Ustala, że VU jest VU 2. generacji, w związku z czym odsyła klucz KP[2].
12.3. Parowanie VU z czujnikiem ruchu i łączność między tymi urządzeniami z wykorzystaniem AES
CSM_218 Zgodnie z tabelą 3 w sekcji 9.2.1 wszystkie klucze uczestniczące w parowaniu przyrządu rejestrującego i czujnika ruchu (drugiej generacji) oraz w późniejszej łączności są kluczami AES, a nie kluczami TDES podwójnej długości, jak określono w [ISO 16844-3]. Takie klucze AES mogą mieć długość 128, 192 lub 256 bitów. Ponieważ rozmiar bloku AES wynosi 16 bajtów, długość zaszyfrowanego komunikatu musi stanowić wielokrotność 16 bajtów, w porównaniu z 8 bajtami w przypadku TDES. Ponadto niektóre takie komunikaty będą wykorzystywane do transportu kluczy AES, których długość może wynosić 128, 192 lub 256 bitów. W związku z tym liczbę bajtów danych zgodnie z instrukcją w tabeli 5 normy [ISO 16844-3] należy zmienić w sposób określony w tabeli 6:
Tabela 6
Liczba bajtów danych zwykłego tekstu i danych zaszyfrowanych zgodnie z instrukcją określoną w [ISO 16844-3]
| Instrukcja | Żądanie / odpowiedź | Opis danych | Liczba bajtów danych zwykłego tekstu zgodnie z [ISO 16844-3] | Liczba bajtów danych zwykłego tekstu przy użyciu kluczy AES | Liczba bajtów zaszyfrowanych danych przy użyciu kluczy AES o długości w bitach | ||
| 128 | 192 | 256 | |||||
| 10 | żądanie | Dane 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 | 16 / 32 | 16 / 32 | 16 / 32 |
| 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 |
CSM_219 Informacje o parowaniu wysyłane w instrukcjach 43 (żądanie VU) i 50 (odpowiedź czujnika ruchu) są gromadzone zgodnie z wymogami określonymi w sekcji 7.6.10 normy [ISO 16844-3], z tym że zamiast algorytmu TDES należy stosować algorytm AES w systemie szyfrowania danych dotyczących parowania, co skutkuje uzyskaniem dwóch szyfrów AES i przyjęciem wypełnienia zgodnie z CSM_220 w celu dopasowania do rozmiaru bloku AES. Klucz K'p, używany do takiego szyfrowania, generuje się w następujący sposób:
- jeżeli długość klucza parowania KP wynosi 16 bajtów: K'p = KP XOR (Ns||Ns),
- jeżeli długość klucza parowania KP wynosi 24 bajty: K'p = KP XOR (Ns||Ns||Ns),
- jeżeli długość klucza parowania KP wynosi 32 bajty: K'p = KP XOR (Ns||Ns||Ns||Ns), gdzie Ns jest 8-bajtowym numerem seryjnym czujnika ruchu.
CSM_220 Jeżeli długość danych zwykłego tekstu (przy użyciu kluczy AES) nie jest wielokrotnością 16 bajtów, należy stosować metodę wypełniania 2 określoną w normie [ISO 9797-1].
Uwaga: w normie [ISO 16844-3] liczba bajtów danych zwykłego tekstu jest zawsze wielokrotnością 8, tak aby wypełnienie nie było konieczne przy użyciu TDES. Definicja danych i komunikatów w normie [ISO 16844-3] nie jest zmieniona w tej części niniejszego dodatku, co pociąga za sobą konieczność stosowania wypełnienia.
CSM_221 W odniesieniu do instrukcji 11 i w przypadku konieczności zaszyfrowania więcej niż jednego bloku danych stosuje się tryb wiązania bloków zaszyfrowanych zgodnie z wymogami normy [ISO 10116], z naprzemiennym parametrem m = 1. Wektorem inicjującym, jaki należy zastosować, jest:
- w przypadku instrukcji 11: 8-bajtowy blok uwierzytelniania zdefiniowany w sekcji 7.6.3.3 normy [ISO 16844-3], wypełniony za pomocą metody wypełniania 2 określonej w normie [ISO 9797-1]; zob. również sekcja 7.6.5 i 7.6.6 normy [ISO 16844-3];
- w przypadku wszystkich pozostałych instrukcji, w których przekazuje się więcej niż 16 bajtów, zgodnie z tabelą 6: '00' {16}, tj. szesnaście bajtów o wartości binarnej 0.
Uwaga: jak przedstawiono w sekcjach 7.6.5 i 7.6.6 normy [ISO 16844-3], w momencie gdy czujnik ruchu szyfruje pliki danych do celów włączenia ich do instrukcji 11, blok uwierzytelniania jest zarówno:
- używany jako wektor inicjujący do celów szyfrowania plików danych w trybie CBC; jak i
- szyfrowany i włączany jako pierwszy blok w danych, które są wysyłane do VU.
12.4. Parowanie VU z czujnikiem ruchu w przypadku różnych generacji urządzeń
CSM_222 Jak wyjaśniono w sekcji 9.2.1, czujnik ruchu drugiej generacji może zawierać zaszyfrowane w oparciu o TDES dane dotyczące parowania (zgodnie z częścią A niniejszego dodatku), co umożliwia parowanie tego czujnika ruchu z VU pierwszej generacji. W takim przypadku proces parowania VU pierwszej generacji z czujnikiem ruchu drugiej generacji odbywa się zgodnie z opisem przedstawionym w części A niniejszego dodatku oraz w normie [ISO 16844-3]. Na potrzeby procesu parowania można użyć karty warsztatowej pierwszej lub drugiej generacji.
Uwagi
- Nie jest możliwe sparowanie VU drugiej generacji z czujnikiem ruchu pierwszej generacji.
- Nie jest możliwe użycie karty warsztatowej pierwszej generacji do celów powiązania VU drugiej generacji z czujnikiem ruchu.
13. BEZPIECZEŃSTWO ŁĄCZNOŚCI NA ODLEGŁOŚĆ W RAMACH DSRC
13.1. Uwagi ogólne
Jak określono w dodatku 14, VU regularnie generuje dane dotyczące zdalnego monitorowania tachografu (RTM) i wysyła te dane do (wewnętrznego lub zewnętrznego) urządzenia do łączności na odległość (RCF). Urządzenie do łączności na odległość odpowiada za wysłanie tych danych za pośrednictwem interfejsu DSRC opisanego w dodatku 14 do zdalnego interrogatora. W dodatku 1 określono, że dane dotyczące zdalnego monitorowania tachografu stanowią połączenie:
zaszyfrowanego ładunku tachografu zaszyfrowanego zwykłego tekstu ładunku tachografu; danych zabezpieczające DSRC opisanych poniżej.
Format danych ładunku tachografu zawierających zwykły tekst określono w dodatku 1 i szczegółowo opisano w dodatku 14. W tej sekcji opisano strukturę danych zabezpieczających DSRC; formalne specyfikacje przedstawiono w dodatku 1.
CSM_223 Dane zawierające zwykły tekst tachographPayload przekazywane przez VU do urządzenia do łączności na odległość (jeżeli RCF znajduje się na zewnątrz VU) lub przez przyrząd rejestrujący do zdalnego interrogatora za pośrednictwem interfejsu DSRC (jeżeli RCF znajduje się wewnątrz VU) są chronione w trybie uwierzytelnienia po wcześniejszym zaszyfrowaniu, co oznacza, że dane dotyczące ładunku tachografu są najpierw szyfrowane w celu zapewnienia poufności komunikatu, a następnie obliczany jest MAC w celu zapewnienia autentyczności i integralności.
CSM_224 Dane zabezpieczające DSRC składają się z połączenia poniższych elementów danych w następującej kolejności; zob. również rys. 12:
aktualnej daty i godziny tj. aktualnej data i godziny VU (typ danych TimeReal)
licznika tj. 3-bajtowego licznika, zob. CSM_225
numeru seryjnego VU tj. numeru seryjnego VU lub identyfikatora wniosku o certyfikat (typ danych VuSerialNumber lub CertificateRe-questID) - zob. CSM_123
numeru wersji klucza głównego DSRC tj. 1-bajtowego numeru wersji klucza głównego DSRC, z którego wyprowadzono klucze DSRC specyficzne dla VU; zob. sekcja 9.2.2.
MAC tj. MAC obliczanego na podstawie wszystkich wcześniejszych bajtów w danych dotyczących zdalnego monitorowania tachografu.
CSM_225 3-bajtowy licznik w danych zabezpieczających DSRC ma format, w którym najbardziej znaczący bit znajduje się na początku. Za pierwszym razem, gdy VU oblicza zbiór danych dotyczących zdalnego monitorowania tachografu po rozpoczęciu jego produkcji, ustawia wartość licznika na 0. VU zwiększa wartość licznika o 1 za każdym razem, zanim obliczy kolejny zbiór danych dotyczących zdalnego monitorowania tachografu.
13.2. Szyfrowanie ładunku tachografu i generowanie MAC
CSM_226 Po otrzymaniu elementu danych w formie zwykłego tekstu zawierającego typ danych TachographPayload, jak opisano w dodatku 14, VU szyfruje te dane zgodnie z rys. 12: służącego do szyfrowania klucza DSRC przyrządu rejestrującego K_VUDSRC_ENC (zob. sekcja9.2.2) używa się wraz z AES w trybie wiązania bloków zaszyfrowanych (CBC), jak określono w [ISO 10116], z naprzemiennym parametrem m = 1. Wektor inicjujący ma wartość IV = aktualna data i godzina || '00 00 00 00 00 00 00 00 00' || licznik, przy czym wartości aktualnej daty i godzina oraz licznika określono w CSM 224. Dane, które mają zostać zaszyfrowane, wypełnia się za pomocą metody 2 określonej w [ISO 9797-1].
CSM_227 VU oblicza MAC w danych zabezpieczających DSRC zgodnie z rys. 12: MAC oblicza się na podstawie wszystkich wcześniejszych bajtów zawartych w danych dotyczących zdalnego monitorowania tachografu, do wartości numeru wersji klucza głównego DSRC włącznie oraz z uwzględnieniem znaczników i długości obiektów danych. VU używa swojego klucza DSRC do zapewnienia autentyczności K_VUDSRC-MAC (zob. sekca 9.2.2) z alortmem AES w trybie CMAC jak określono w [SP 800-38B]. Długość MAC jest powiązana z długością kluczy DSRC specyficznych dla VU, jak określono w CSM 50.
Rys. 12
Szyfrowanie ładunku tachografu i generowanie MAC
13.3. Weryfikacja i odszyfrowywanie ładunku tachografu
CSM_228 Gdy zdalny interrogator otrzymuje od VU dane dotyczące zdalnego monitorowania tachografu, wysyła wszystkie dane dotyczące zdalnego monitorowania tachografu do karty kontrolnej w polu danych polecenia PROCESS DSRC MESSAGE, jak opisano w dodatku 2. Następnie:
1. karta kontrolna sprawdza numer wersji klucza głównego DSRC w danych zabezpieczających DSRC. Jeżeli karta kontrolna nie rozpozna wskazanego klucza głównego DSRC, zwraca komunikat o błędzie określony w dodatku 2 i przerywa proces;
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;
3. karta kontrolna używa klucza K_VUDSRC_MAC do weryfikacji MAC zawartego w danych zabezpieczających DSRC, jak określono w CSM_227. Jeżeli MAC jest nieprawidłowy, karta kontrolna zwraca komunikat o błędzie określony w dodatku 2 i przerywa proces;
4. karta kontrolna wykorzystuje klucz K_VUDSRC_ENC do celów odszyfrowania zaszyfrowanego ładunku tachografu, jak określono w CSM_226. Karta kontrolna usuwa wypełnienie i odsyła odszyfrowane dane ładunku tachografu do zdalnego interrogatora.
CSM_229 W celu zapobieżenia atakom przez powtórzenie zdalny interrogator weryfikuje aktualność danych dotyczących zdalnego monitorowania tachografu poprzez sprawdzenie, czy aktualna data i godzina zawarta w danych zabezpieczających DSRC nie odbiega zbytnio od czasu bieżącego zdalnego interrogatora.
Uwagi
- W tym celu konieczne jest, aby zdalny interrogator posiadał dokładne i wiarygodne źródło czasu.
- Ponieważ dodatek 14 zawiera wymóg, aby VU obliczał nowy zbiór danych dotyczących zdalnego monitorowania tachografu co 60 sekund, a zegar VU może odbiegać od czasu rzeczywistego o 1 minutę, dolna granica w odniesieniu do aktualności danych dotyczących zdalnego monitorowania tachografu wynosi 2 minuty. Faktyczna aktualność, jaka jest wymagana, zależy również od dokładności zegara zdalnego interrogatora.
CSM_230 Gdy warsztat weryfikuje prawidłowość działania funkcji DSRC VU, wysyła wszystkie otrzymane od VU dane dotyczące zdalnego monitorowania tachografu do karty warsztatowej w polu danych polecenia PROCESS DSRC MESSAGE, jak opisano w dodatku 2. Karta warsztatowa przeprowadza wszystkie kontrole i działania określone w wymogu CSM_228.
14. PODPISYWANIE POBIERANYCH DANYCH I SPRAWDZANIE PODPISÓW
14.1. Uwagi ogólne
CSM_231 Inteligentne urządzenie dedykowane (IDE) przechowuje dane otrzymane z VU lub karty podczas jednej sesji pobierania w jednym fizycznym pliku danych. Dane mogą być przechowywane na zewnętrznym nośniku danych. Plik zawiera podpisy cyfrowe bloków danych zgodnie z opisem znajdującym się w dodatku 7. Plik ten zawiera również następujące certyfikaty (zob. sekcja 9.1):
- w przypadku pobierania przez VU:
- certyfikat VU_Sign;
- certyfikat MSCA_VU-EGF zawierający klucz publiczny służący do weryfikacji certyfikatu VU_Sign;
- w przypadku pobierania przez kartę:
- certyfikat Card_Sign;
- certyfikat MSCA_Card zawierający klucz publiczny służący do weryfikacji certyfikatu Card_Sign.
CSM_232 IDE posiada również:
- w przypadku gdy używa karty kontrolnej do weryfikacji podpisu, jak wskazano na rys. 13: certyfikat łączący najnowszy certyfikat EUR z certyfikatem EUR, którego okres ważności wygasa bezpośrednio przed okresem ważności tego najnowszego certyfikatu EUR, o ile istnieje;
- w przypadku gdy samodzielnie weryfikuje podpis: wszystkie ważne europejskie certyfikaty główne.
Uwaga: metody stosowanej przez IDE do pobierania tych certyfikatów nie określono w niniejszym dodatku.
14.2. Generowanie podpisu
CSM_233 Algorytmem podpisywania służącym do tworzenia podpisów cyfrowych w odniesieniu do pobieranych danych jest ECDSA, jak określono w [DSS], używający algorytmu skrótu powiązanego z wielkością klucza VU lub karty, jak określono w CSM_50. Format podpisu jest odkryty, jak określono w [TR-03111].
14.3. Weryfikacja podpisu
CSM_234 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.
Uwagi do rys. 13:
- urządzenie, które podpisuje dane przeznaczone do analizowania, oznaczono EQT.
- certyfikaty i klucze publiczne ETQ wskazane na rysunku są certyfikatami i kluczami używanymi do podpisywania, tj. VU_Sign lub Card_Sign;
- certyfikaty EQT.CA i klucze publiczne wskazane na rysunku są certyfikatami i kluczami używanymi do podpisywania w stosownych przypadkach certyfikatów VU lub kart;
- certyfikat EQT.CA.EUR wskazany na rysunku jest europejskim certyfikatem głównym wskazanym w CAR certyfikatu EQT.CA;
- certyfikat EQT.Link wskazany na rysunku jest certyfikatem łączącym EQT, o ile istnieje. Jak określono w sekcji 9.1.2, jest to certyfikat łączący dla nowej pary europejskich kluczy głównych wygenerowanej przez ERCA i podpisanej za pomocą poprzedniego europejskiego klucza prywatnego;
- certyfikat EQT.Link.EUR jest europejskim certyfikatem głównym wskazanym w CAR certyfikatu EQT.Link.
CSM_235 Do celów obliczania skrótu M wysyłanego do karty kontrolnej w poleceniu PSO:Hash IDE stosuje algorytm skrótu powiązany z wielkością klucza VU lub karty, z których dane są pobierane, jak określono w CSM_50.
CSM_236 Do celów zweryfikowania podpisu EQT karta kontrolna wykonuje czynności według schematu podpisu określonego w [DSS].
Uwaga: w niniejszym dokumencie nie określono żadnego działania, jakie należy podjąć, jeżeli podpisu złożonego w odniesieniu do pobranego pliku danych nie można zweryfikować lub jeżeli weryfikacja się nie powiedzie.
Rysunek 13
Protokół weryfikacji podpisu złożonego w odniesieniu do pobranego pliku danych
Dodatek 12 33
OKREŚLANIE POŁOŻENIA Z WYKORZYSTANIEM GLOBALNEGO SYSTEMU NAWIGACJI SATELITARNEJ (GNSS)
OKREŚLANIE POŁOŻENIA Z WYKORZYSTANIEM GLOBALNEGO SYSTEMU NAWIGACJI SATELITARNEJ (GNSS)
1. WPROWADZENIE ...........................................................................................................
1.1. Zakres stosowania ..............................................................................................................
1.1.1 Odniesienia
1.2. Akronimy i skróty ...............................................................................................................
2. PODSTAWOWA CHARAKTERYSTYKA ODBIORNIKA GNSS .........................................................................
3. KOMUNIKATY PODAWANE PRZEZ ODBIORNIK GNSS...............................................................................................
4. PRZYRZĄD REJESTRUJĄCY Z URZĄDZENIEM ZEWNĘTRZNYM GNSS ................
4.1. Konfiguracja .......................................................................................................................
4.1.1 Główne elementy składowe i interfejsy .................................................................................
4.1.2 Stan urządzenia zewnętrznego GNSS na koniec procesu produkcji ......................................
4.2. Łączność między urządzeniem zewnętrznym GNSS a przyrządem rejestrującym ...................
4.2.1 Protokół łączności ...............................................................................................................
4.2.2 Bezpieczne przesyłanie danych GNSS .................................................................................
4.2.3 Struktura polecenia Read Record ........................................................................................
4.2.4 Struktura polecenia WriteRecord
4.2.5. Inne polecenia
4.3. Powiązanie, wzajemne uwierzytelnienie i uzgodnienie klucza sesji między urządzeniem zewnętrznym GNSS a przyrządem rejestrującym .................................................................
4.4. Obsługa błędów ..................................................................................................................
4.4.1 Błąd komunikacji z urządzeniem zewnętrznym GNSS ...........................................................
4.4.2 Naruszenie integralności fizycznej urządzenia zewnętrznego GNSS .......................................
4.4.3 Brak informacji o położeniu z odbiornika GNSS ..................................................................
4.4.4 Wygaśnięcie certyfikatu urządzenia zewnętrznego GNSS .....................................................
5. PRZYRZĄD REJESTRUJĄCY BEZ URZĄDZENIA ZEWNĘTRZNEGO GNSS ............
5.1. Konfiguracja .......................................................................................................................
5.2. Transfer informacji z odbiornika GNSS do VU............................................................................................
5.2.1 (uchylony).
5.3. Transfer informacji z VU do odbiornika GNSS
5.4. Obsługa błędów
5.4.1. Brak informacji o pozycji z odbiornika GNSS
6. PRZETWARZANIE I REJESTRACJA DANYCH O POZYCJI PRZEZ VU
7. KONFLIKT CZASOWY GNSS
8. KONFLIKT RUCHU POJAZDU
1. WPROWADZENIE
Niniejszy dodatek zawiera wymogi techniczne dotyczące odbiornika GNSS oraz danych GNSS wykorzystywanych przez przyrząd rejestrujący, z uwzględnieniem protokołów, które należy wdrożyć w celu zapewnienia bezpiecznego i prawidłowego przesyłania danych z informacjami o pozycji.
1.1. Zakres
GNS_1 Przyrząd rejestrujący musi gromadzić dane dotyczące lokalizacji z co najmniej jednej sieci satelitarnej GNSS.
Przyrząd rejestrujący może posiadać urządzenie zewnętrzne GNSS lub nie, jak przedstawiono na rys. 1:
Rys. 1
Różne konfiguracje odbiornika GNSS.
1.1.1 Odniesienia
W tej części dodatku używa się następujących odniesień:
NMEA NMEA (National Marine Electronics Association) [Narodowe Stowarzyszenie Elektroniki Morskiej] 0183 Interface Standard [standard dla interfejsów], V4.11
1.2. Akronimy i skróty
W niniejszym dodatku używa się następujących skrótów:
DOP Rozmycie dokładności
EGF Plik elementarny urządzenia GNSS
GNSS Globalny system nawigacji satelitarnej
EGNOS Europejski system wspomagania satelitarnego
GSA Rozmycie dokładności GPS i aktywne satelity
HDOP Poziome rozmycie dokładności
ICD Dokument kontroli interfejsu
NMEA National Marine Electronics Association
PDOP Trójwymiarowe rozmycie dokładności
RMC Zalecane minimalne dane GNSS
SIS Sygnał w przestrzeni
VDOP Pionowe rozmycie dokładności
VU Przyrząd rejestrujący
OSNMA Galileo Open Service Navigation Message Authentication [uwierzytelnianie komunikatów nawigacyjnych usługi otwartej Galileo]
RTC Real Time Clock [zegar czasu rzeczywistego]
2. PODSTAWOWA CHARAKTERYSTYKA ODBIORNIKA GNSS
Niezależnie od konfiguracji tachografu inteligentnego z urządzeniem zewnętrznym GNSS lub bez niego, dostarczanie dokładnych i wiarygodnych informacji o położeniu jest niezbędne do zapewnienia skutecznego funkcjonowania tachografów inteligentnych. W związku z tym należy wprowadzić wymóg zapewnienia kompatybilności tego systemu z satelitarnymi systemami wspomagającymi (SBAS). System ustanowiony w ramach programu Galileo jest niezależnym światowym systemem nawigacji satelitarnej, zaś system ustanowiony w ramach programu EGNOS jest regionalnym systemem nawigacji satelitarnej poprawiającym jakość sygnału globalnego systemu pozycjonowania.
GNS_2 Producenci zapewniają, aby odbiorniki GNSS instalowane w tachografach inteligentnych były kompatybilne z usługami w zakresie lokalizacji zapewnianymi przez systemy Galileo i EGNOS. Ponadto producenci mogą również wybrać kompatybilność z innymi systemami nawigacji satelitarnej.
GNS_3 Odbiornik GNSS musi być w stanie obsługiwać uwierzytelnianie komunikatów nawigacyjnych w ramach usługi otwartej Galileo (OSNMA).
GNS_3a Odbiornik GNSS przeprowadza szereg kontroli spójności w celu sprawdzenia, czy pomiary obliczane przez odbiornik GNSS na podstawie danych OSNMA doprowadziły do uzyskania prawidłowych informacji na temat pozycji, prędkości i danych pojazdu, a zatem nie były przedmiotem żadnego ataku zewnętrznego, który wywarłby nie na wpływ, takiego jak meaconing. Przedmiotowe kontrole spójności obejmują na przykład: - wykrywanie nietypowych emisji mocy za pomocą połączonego monitorowania automatycznej kontroli wzmocnienia (AGC) i stosunku gęstości nośnej do szumu (C/N0),
- spójności pomiaru pseudozakresów oraz spójności pomiaru Dopplera w czasie, w tym wykrywanie nagłych skoków pomiarowych,
- techniki niezależnego monitorowania spójności odbiornika (RAIM), w tym wykrywanie niespójnych pomiarów z szacowaną pozycją,
- kontrole pozycji i prędkości, w tym nietypowych wskazań pozycji i prędkości, nagłych skoków i zachowań niezgodnych z dynamiką pojazdu,
- spójność czasu i częstotliwości, w tym skoki zegarowe i dryfty, które nie są spójne z charakterystyką zegara odbiornika.
GNS_3b Komisja Europejska opracowuje i zatwierdza następujące dokumenty:
- dokument kontroli interfejsu sygnału w przestrzeni (SIS ICD), określający szczegółowo informacje OSNMA przekazywane w ramach sygnału Galileo;
- wytyczne dla odbiorników w zakresie OSNMA, określające wymogi i procesy dotyczące odbiorników, niezbędne do zagwarantowania bezpiecznego wdrożenia OSNMA, a także zalecenia dotyczące poprawy działania OSNMA.
Odbiorniki GNSS instalowane w tachografach, zarówno wewnętrzne, jak i zewnętrzne, muszą być skonstruowane zgodnie z dokumentem SIS ICD i wytycznymi dla odbiorników w zakresie OSNMA.
GNS_3c Odbiornik GNSS dostarcza komunikaty o pozycji, zwane w niniejszym załączniku i dodat
kach do niego komunikatami o uwierzytelnionej pozycji, opracowane z wykorzystaniem wyłącznie satelitów przekazujących komunikaty nawigacyjne, których autentyczność została z powodzeniem zweryfikowana.
GNS_3d Odbiornik GNSS dostarcza również komunikaty o standardowej pozycji opracowane
z wykorzystaniem widocznych satelitów, niezależnie od tego, czy są one uwierzytelnione, czy nie.
GNS_3e Odbiornik GNSS wykorzystuje zegar czasu rzeczywistego (RTC) VU jako odniesienie dla
synchronizacji czasu na potrzeby OSNMA.
GNS_3f Czas RTC VU jest przekazywany przez VU do odbiornika GNSS.
GNS_3g VU przekazuje do odbiornika GNSS maksymalny dryft czasu określony w wymogu 41
w załączniku IC, wraz z czasem RTC VU.
3. KOMUNIKATY PODAWANE PRZEZ ODBIORNIK GNSS
W niniejszej sekcji opisano komunikaty wykorzystywane w funkcjonowaniu tachografu inteligentnego do przekazywania komunikatów o standardowej i uwierzytelnionej pozycji. Sekcja ta ma zastosowanie w odniesieniu do konfiguracji tachografu inteligentnego z urządzeniem zewnętrznym GNSS lub bez niego.
GNS_4 Dane o standardowej pozycji opierają się na zalecanych minimalnych danych GNSS (RMC)
w komunikacie NMEA, który zawiera informacje o pozycji (długość i szerokość geograficzną), czas w formacie UTC (hhmmss.ss), prędkość nad dnem wyrażoną w węzłach oraz dodatkowe wartości.
Format komunikatu RMC jest następujący (według standardu NMEA V4.11):
Rysunek 2
Struktura komunikatu RMC
$-RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
1) Czas (UTC)
2) Status, A= prawidłowe położenie, V= ostrzeżenie
3) Szerokość geograficzna
4) N lub S
5) Długość geograficzna
6) E lub W
7) Prędkość nad dnem w węzłach
8) Tor prawidłowy, stopnie prawidłowe
9) Data, ddmmrr
10) Deklinacja magnetyczna w stopniach
11) E lub W
12) Wskaźnik trybu FAA
13) Status nawigacji
14) Suma kontrolna
Status nawigacji ma charakter opcjonalny i może być nieobecny w komunikacie RMC.
Parametr »Status« informuje o tym, czy sygnał GNSS jest dostępny. Dopóki wartość statusu nie zostanie ustawiona na 'A', otrzymywanych danych (np. dotyczących czasu lub dłu- gości/szerokości geograficznej) nie można wykorzystywać do rejestrowania pozycji pojazdu w VU.
Dokładność położenia opiera się na formacie komunikatu RMC opisanym powyżej. Pierwszą część pól 3 i 5 wykorzystuje się do określenia stopni. Pozostałe określają minuty kątowe z dokładnością do trzech miejsc po przecinku. Zatem dokładność wynosi 1/1 000 minuty kątowej lub 1/60 000 stopnia (ponieważ jedna minuta to 1/60 stopnia).
GNS_4a Dane o uwierzytelnionej pozycji opierają się na komunikacie podobnym do NMEA, z uwie
rzytelnionymi minimalnymi danymi (AMC), który zawiera informacje o pozycji (długość i szerokość geograficzną), czas w formacie UTC (hhmmss.ss), prędkość nad dnem wyrażoną w węzłach oraz dodatkowe wartości.
Format komunikatu AMC jest następujący (według standardu NMEA V4.11, z wyjątkiem wartości nr 2):
Rysunek 3
Struktura komunikatu AMC
$-AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
1) Czas (UTC)
2) Status, A=uwierzytelniona pozycja (ustalona przy użyciu co najmniej 4 satelitów przekazujących komunikaty nawigacyjne, których autentyczność została z powodzeniem zweryfikowana), J=jamming [celowe zakłócanie] lub O=inny atak na GNSS w razie braku nieprawidłowego uwierzytelnienia komunikatów nawigacyjnych (poprzez wdrożone kontrole spójności zgodnie z GNS_3a), F= nieudane uwierzytelnienie komunikatów nawigacyjnych (wykryte w wyniku weryfikacji OSNMA określonych w dokumentach, o których mowa w GNS_3b), V=puste (uwierzytelniona pozycja nie jest dostępna z innego powodu)
3) Szerokość geograficzna
4) N lub S
5) Długość geograficzna
6) E lub W
7) Prędkość nad dnem w węzłach
8) Tor prawidłowy, stopnie prawidłowe
9) Data, ddmmrr
10) Deklinacja magnetyczna w stopniach
11) E lub W
12) Wskaźnik trybu FAA
13) Status nawigacji
14) Suma kontrolna
Status nawigacji ma charakter opcjonalny i może być nieobecny w komunikacie AMC.
Status wskazuje, czy uwierzytelniona pozycja GNSS dostępna jest dostępna, czy wykryto atak na sygnały GNSS, czy uwierzytelnienie komunikatów nawigacyjnych nie powiodło się, lub czy pozycja GNSS jest pusta. Dopóki wartość statusu nie zostanie ustawiona na 'A', otrzymywanych danych (np. dotyczących czasu lub długości/szerokości geograficznej) nie uznaje się za ważne i nie można ich wykorzystywać do rejestrowania pozycji pojazdu w VU. Jeżeli wartość statusu jest ustawiona na 'J' (jamming), 'O' (inny atak na GNSS) lub 'F' (nieupoważnione uwierzytelnienie komunikatów nawigacyjnych), w VU rejestruje się zdarzenie anomalii GNSS, jak określono w załączniku IC i dodatku 1 (EventFaultCode).
GNS_5 Przyrząd rejestrujący przechowuje w bazie danych VU informacje o położeniu dotyczące
szerokości i długości geograficznej z dokładnością 1/10 minuty kątowej lub 1/600 stopnia, jak określono w dodatku 1 w odniesieniu do współrzędnych geograficznych GeoCoordinates.
VU może wykorzystać polecenie GSA (dotyczące rozmycia dokładności GPS i satelitów czynnych), zgodnie ze standardem NMEA V4.11, w celu ustalenia i zarejestrowania dostępności sygnału i dokładności standardowych pozycji. W szczególności HDOP stosuje się w celu wskazania poziomu dokładności zarejestrowanych danych dotyczących lokalizacji (zob. pkt 4.2.2). VU będzie przechowywał wartość poziomego rozmycia dokładności (HDOP) obliczaną jako minimum wartości HDOP zgromadzonych w dostępnych systemach GNSS.
Identyfikator GNSS wskazuje odpowiedni identyfikator NMEA dla każdej konstelacji GNSS i systemu wspomagającego opartego na wyposażeniu satelitarnym SBAS.
Rysunek 4
Struktura komunikatu GSA (standardowe pozycje)
$-GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh
1) Tryb wyboru
2) Tryb
3) ID pierwszego satelity użytego do ustalenia pozycji
4) ID drugiego satelity użytego do ustalenia pozycji
14) ID dwunastego satelity użytego do ustalenia pozycji
15) PDOP
16) HDOP
17) VDOP
18) ID systemu
19) Suma kontrolna
ID systemu ma charakter opcjonalny i może być nieobecny w komunikacie GSA.
Podobnie VU może wykorzystywać polecenie ASA (dotyczące uwierzytelnionych satelitów czynnych) z komunikatem podobnym do NMEA w celu ustalenia i zarejestrowania gotowości sygnału i dokładności uwierzytelnionych pozycji. Wartości 1-18 są zdefiniowane w standardzie NMEA V4.11.
Rysunek 5
Struktura komunikatu ASA (uwierzytelnione pozycje)
$-ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh
1) Tryb wyboru
2) Tryb
3) ID pierwszego satelity użytego do ustalenia pozycji
4) ID drugiego satelity użytego do ustalenia pozycji
14) ID dwunastego satelity użytego do ustalenia pozycji
15) PDOP
16) HDOP
17) VDOP
18) ID systemu
19) Suma kontrolna
ID systemu ma charakter opcjonalny i może być nieobecny w komunikacie ASA.
GNS_6 W przypadku korzystania z urządzenia zewnętrznego GNSS komunikat GSA przechowuje
się w bezpiecznym nadajniku-odbiorniku GNSS z numerem rekordu '02' do '06', a komunikat ASA przechowuje się z numerem rekordu '12' do '16'.
GNS_7 Maksymalny rozmiar komunikatów (np. RMC, AMC, GSA, ASA lub innych), jaki można
zastosować w celu ustalenia rozmiaru polecenia odczytu rekordu, wynosi 85 bajtów (zob. tabela 1).
4. PRZYRZĄD REJESTRUJĄCY Z URZĄDZENIEM ZEWNĘTRZNYM GNSS
4.1. Konfiguracja
4.1.1 Główne elementy składowe i interfejsy
W tej konfiguracji odbiornik GNSS stanowi część urządzenia zewnętrznego GNSS.
GNS_8 Urządzenie zewnętrzne GNSS musi być obsługiwane przez specjalny interfejs pojazdu.
GNS_9 Urządzenie zewnętrzne GNSS składa się z następujących elementów składowych (zob. rys. 6):
a) komercyjnego odbiornika GNSS zapewniającego dane o pozycji za pośrednictwem interfejsu danych GNSS. Przykładowo interfejs danych GNSS może być w standardzie NMEA V4.11, gdzie odbiornik GNSS pełni funkcję nadajnika i przesyła komunikaty NMEA do bezpiecznego nadajnika-odbiornika GNSS z częstotliwością 1 Hz dla zdefiniowanego wcześniej zbioru komunikatów NMEA i podobnych do NMEA, który musi zawierać co najmniej komunikaty RMC, AMC, GSA i ASAA. Wdrożenie interfejsu danych GNSS zależy od uznania producentów urządzeń zewnętrznych GNSS;
b) zespołu nadajnika-odbiornika (bezpiecznego nadajnika-odbiornika GNSS) zdolnego do zapewnienia zgodności z wymogami normy ISO/IEC 7816-4:2013 (zob. pkt 4.2.1) w celu łączenia się z przyrządem rejestrującym i obsługi interfejsu danych GNSS odbiornika GNSS. Zespół ten jest wyposażony w pamięć do przechowywania danych identyfikacyjnych z odbiornika GNSS i urządzenia zewnętrznego GNSS;
c) systemu obudowy z funkcją wykrywania manipulowania, obejmującego zarówno odbiornik GNSS, jak i bezpieczny nadajnik-odbiornik GNSS. Funkcja wykrywania manipulowania umożliwia wdrażanie środków bezpieczeństwa zgodnie z wymogami określonymi w profilu zabezpieczenia tachografu inteligentnego;
d) anteny GNSS zainstalowanej na pojeździe i połączonej z odbiornikiem GNSS poprzez system obudowy.
GNS_10 Urządzenie zewnętrzne GNSS posiada co najmniej następujące interfejsy zewnętrzne:
a) interfejs anteny GNSS zainstalowanej na pojeździe ciężarowym w przypadku korzystania z anteny zewnętrznej;
b) interfejs przyrządu rejestrującego.
GNS_11 W VU bezpieczny nadajnik-odbiornik VU znajduje się na drugim końcu bezpiecznej łączności z bezpiecznym nadajnikiem-odbiornikiem GNSS i musi zapewniać zgodność z wymogami normy ISO/ IEC 7816-4:2013 w zakresie łączności z urządzeniem zewnętrznym GNSS.
GNS_12 W zakresie warstwy fizycznej łączności z urządzeniem zewnętrznym GNSS przyrząd rejestrujący musi zapewniać zgodność z wymogami normy ISO/IEC 7816-12:2005 lub innej normy zgodnej z normą ISO/IEC 7816-4:2013 (zob. pkt 4.2.1).
4.1.2 Stan urządzenia zewnętrznego GNSS na koniec procesu produkcji
GNS_13 Urządzenie zewnętrzne GNSS przechowuje następujące wartości w pamięci trwałej bezpiecznego nadajnika-odbiornika GNSS w momencie opuszczenia zakładu produkcyjnego:
- parę kluczy EGF_MA i powiązany certyfikat;
- certyfikat MSCA_VU-EGF zawierający klucz publiczny MSCA_VU-EGF.PK służący do weryfikacji certyfikatu EGF_MA;
- certyfikat EUR zawierający klucz publiczny EUR.PK służący do weryfikacji certyfikatu MSCA_VU-EGF;
- certyfikat EUR, którego okres ważności wygasa bezpośrednio przed okres ważności certyfikatu EUR służącego do celów weryfikacji certyfikatu MSCA_VU-EGF, o ile istnieje;
- certyfikat łączący wspomniane dwa certyfikaty EUR, o ile istnieje;
- rozszerzony numer seryjny urządzenia zewnętrznego GNSS;
- identyfikator systemu operacyjnego urządzenia GNSS;
- numer homologacji typu urządzenia zewnętrznego GNSS;
- identyfikator elementu zabezpieczenia modułu zewnętrznego GNSS.
4.2. Łączność między urządzeniem zewnętrznym GNSS a przyrządem rejestrującym
4.2.1 Protokół łączności
GNS_14 Protokół łączności między urządzeniem zewnętrznym GNSS a przyrządem rejestrującym obsługuje następujące funkcje:
1. gromadzenie i rozpowszechnianie danych GNSS (np. pozycja, czas, prędkość);
2. gromadzenie danych dotyczących konfiguracji urządzenia zewnętrznego GNSS;
3. protokół zarządzania na potrzeby obsługi powiązania, wzajemnego uwierzytelnienia i uzgadniania klucza sesji między urządzeniem zewnętrznym GNSS a VU;
4. przekazywanie do urządzenia zewnętrznego GNSS czasu RTC VU oraz maksymalnej różnicy między czasem prawdziwym a czasem RTC VU.
GNS_15 Protokół łączności bazuje na wymogach normy ISO/IEC 7816-4:2013, przy czym bezpieczny nadajnik-odbiornik VU odgrywa rolę nadrzędną, a bezpieczny nadajnik-odbiornik GNSS - rolę podrzędną. Fizyczne połączenie między urządzeniem zewnętrznym GNSS a przyrządem rejestrującym bazuje na normie ISO/IEC 7816-12:2005 lub innej normie zgodnej z normą ISO/IEC 7816-4:2013.
GNS_16 W protokole łączności nie są obsługiwane pola o rozszerzonej długości.
GNS_17 Protokół łączności bazujący na wymogach normy ISO 7816 (zarówno *-4:2013, jak i *-12:2005) między urządzeniem zewnętrznym GNSS a VU ustawia się na wartość T=1.
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.
GNS_18a W odniesieniu do funkcji 4 (przekazywanie do urządzenia zewnętrznego GNSS czasu RTC VU oraz maksymalnej różnicy między czasem prawdziwym a czasem RTC VU) bezpieczny nadajnik-odbiornik GNSS wykorzystuje EF (EF VU) w tym samym DF z identyfikatorem pliku równym '2F30', jak opisano w tabeli 1.
GNS_19 Bezpieczny nadajnik-odbiornik GNSS przechowuje dane z odbiornika GNSS i konfigurację w pliku elementarnym EF.EGF. Jest to liniowy plik rekordu o zmiennej długości z identyfikatorem równym '2F2F' w formacie heksadecymalnym.
GNS_19a Bezpieczny nadajnik-odbiornik GNSS przechowuje dane z VU w EF VU. Jest to liniowy plik rekordu o stałej długości z identyfikatorem równym '2F30' w formacie heksadecymal- nym.
GNS_20 Bezpieczny nadajnik-odbiornik GNSS używa pamięci do przechowywania danych i jest w stanie przeprowadzić tyle cykli odczytu/zapisu, ile jest potrzebnych w okresie eksploatacji wynoszącym co najmniej 15 lat. Poza tym aspektem o konstrukcji wewnętrznej i wdrażaniu bezpiecznego nadajnika-odbiornika GNSS decydują producenci.
GNS_21 Strukturę plików przedstawiono w tabeli 1. Aby uzyskać informacje na temat warunków dostępu (ALW, NEV, SM-MAC), zob. dodatek 2 rozdział 3.5.
Tabela 1
Struktura plików
| Warunki dostępu |
| File | ID pliku | Odczyt | Aktualizacja | Zaszyfrowany |
| MF | 3F00 | |||
| EF.ICC | 0002 | ALW | NEV (ze strony VU) | Nie |
| DF GNSS Facility | 0501 | ALW | NEV | Nie |
| EF EGF_MACertificate | C100 | ALW | NEV | Nie |
| EF CA_Certificate | C108 | ALW | NEV | Nie |
| EF Link_Certificate | C109 | ALW | NEV | Nie |
| EF EGF | 2F2F | SM-MAC | NEV (ze strony VU) | Nie |
| EF VU | 2F30 | SM-MAC | SM-MAC | Nie |
| Plik / element danych | Nr rekordu | Rozmiar (w bajtach) | Wartości domyślne |
| Min. | Maks. | |||
| MF | 552 | 1031 | ||
| EF.ICC | ||||
| sensorGNSSSerialNumber | 8 | 8 | ||
| DF GNSS Facility | 612 | 1023 | ||
| EF EGF_MACertificate | 204 | 341 | ||
| EGFCertificate | 204 | 341 | {00..00} | |
| EF CA_Certificate | 204 | 341 | ||
| MemberStateCertificate | 204 | 341 | {00..00} | |
| EF Link_Certificate | 204 | 341 | ||
| LinkCertificate | 204 | 341 | {00..00} | |
| EF EGF | ||||
| Komunikat RMC NMEA | '01' | 85 | 85 | |
| Pierwszy komunikat GSA NMEA | '02' | 85 | 85 | |
| Drugi komunikat GSA NMEA | '03' | 85 | 85 | |
| Trzeci komunikat GSA NMEA | '04' | 85 | 85 | |
| Czwarty komunikat GSA NMEA | '05' | 85 | 85 | |
| Piąty komunikat GSA NMEA | '06' | 85 | 85 | |
| Rozszerzony numer seryjny urządzenia zewnętrznego GNSS zdefiniowany w dodatku 1 jako SensorGNSSSerialNumber. | '07' | 8 | 8 | |
| Identyfikator systemu operacyjnego bezpiecznego nadajnika-odbiornika GNSS zdefiniowany w dodatku 1 jako SensorOSIdentifier. | '08' | 2 | 2 | |
| Numer homologacji typu urządzenia zewnętrznego GNSS zdefiniowany w dodatku 1 jako SensorExternalGNSSApprovalNum- ber. | '09' | 16 | 16 | |
| Identyfikator elementu zabezpieczenia urządzenia zewnętrznego GNSS zdefiniowany w dodatku 1 jako SensorExternalGNSSSCIdentifier. | '10' | 8 | 8 | |
| Komunikat AMC | '11' | 85 | 85 | |
| Pierwszy komunikat ASA | '12' | 85 | 85 | |
| Drugi komunikat ASA | '13' | 85 | 85 | |
| Trzeci komunikat ASA | '14' | 85 | 85 | |
| Czwarty komunikat ASA | '15' | 85 | 85 | |
| Piąty komunikat ASA | '16' | 85 | 85 | |
| RFU - zarezerwowane dla przyszłego użytku | Od '17' do 'FD' | |||
| EF VU | ||||
| VuRtcTime (zob. dodatek 1) | '01' | 4 | 4 | {00..00} |
| VuGnssMaximalTimeDifference (zob. dodatek 1) | '02' | 2 | 2 | {00..00} |
4.2.2 Bezpieczne przesyłanie danych GNSS
GNS_22 Bezpieczne przesyłanie danych GNSS o pozycji, czasu RTC VU i maksymalnej różnicy czasowej między czasem prawdziwym a czasem RTC VU jest dozwolone wyłącznie w następujących warunkach:
1. proces powiązania został przeprowadzony w sposób opisany w dodatku 11 "Wspólne mechanizmy zabezpieczenia";
2. proces okresowego wzajemnego uwierzytelniania i uzgadniania klucza sesji między VU a urządzeniem zewnętrznym GNSS, również opisany w dodatku 11 "Wspólne mechanizmy zabezpieczenia", przeprowadzono ze wskazaną częstotliwością.
GNS_23 GN- Co T sekund, gdzie T jest wartością nie większą niż 20, chyba że trwa proces powiązania GNS_23 lub wzajemnego uwierzytelnienia i uzgadniania klucza sesji, VU żąda od urządzenia zewnętrznego GNSS przesłania informacji o pozycji w oparciu o poniższy schemat.
1. VU żąda od urządzenia zewnętrznego GNSS przesłania danych dotyczących pozycji wraz z danymi dotyczącymi rozmycia dokładności (z komunikatów GSA i ASA). Bezpieczny nadajnik-odbiornik VU stosuje zgodne z wymogami normy ISO/IEC 7816-4:2013 polecenia SELECT [wybór] i READ RECORD(S) [odczyt rekordu(-ów)] w trybie tylko uwierzytelniania bezpiecznej wymiany komunikatów, jak opisano w dodatku 11 sekcja 11.5, z identyfikatorem pliku '2F2F' i numerem rekordu '01' w przypadku komunikatu RMC NMEA, '02','03','04','05','06' w przypadku komunikatu GSA NMEA, '11' w przypadku komunikatu AMC oraz '12','13','14','15','16' w przypadku komunikatu ASA.
2. Dane dotyczące pozycji otrzymane jako ostatnie są przechowywane w pliku elementarnym z identyfikatorem '2F2F' i rekordami opisanymi w tabeli 1 w bezpiecznym nad- ajniku-odbiorniku GNSS, ponieważ bezpieczny nadajnik-odbiornik GNSS otrzymuje dane NMEA z częstotliwością co najmniej 1 Hz od odbiornika GNSS za pośrednictwem interfejsu danych GNSS.
3. Bezpieczny nadajnik-odbiornik GNSS wysyła odpowiedź do bezpiecznego nadajnika- odbiornika VU za pomocą komunikatu odpowiedzi APDU w trybie tylko uwierzytelniania bezpiecznej wymiany komunikatów, zgodnie z opisem przedstawionym w dodatku 11 sekcja 11.5.
4. Bezpieczny nadajnik-odbiornik VU weryfikuje autentyczność i integralność otrzymanej odpowiedzi. W przypadku pozytywnego wyniku dane dotyczące pozycji są przekazywane do procesora VU za pośrednictwem interfejsu danych GNSS.
5. Procesor VU sprawdza otrzymane dane, wyodrębniając informacje (np. o długości geograficznej, szerokości geograficznej, czasie) z komunikatu NMEA RMC. Komunikat RMC NMEA zawiera informację o tym, czy nieuwierzytelniona pozycja jest prawidłowa. Jeżeli uwierzytelniona pozycja jest prawidłowa, procesor VU wyodrębnia również wartości HDOP z komunikatów NMEA GSA i oblicza minimalną wartość w stosunku do dostępnych systemów satelitarnych (tj. jeżeli ustalenie pozycji jest możliwe).
6. Procesor VU wyodrębnia również informacje (np. o długości geograficznej, szerokości geograficznej, czasie) z komunikatu AMC. Komunikat AMC zawiera informacje, czy uwierzytelniona pozycja jest nieprawidłowa lub czy sygnał GNSS został zaatakowany. Jeżeli pozycja jest prawidłowa, procesor VU wyodrębnia również wartości HDOP z komunikatów ASA i oblicza minimalną wartość w stosunku do dostępnych systemów satelitarnych (tj. jeżeli ustalenie pozycji jest możliwe).
GNS_23a VU zapisuje również czas RTC VU i maksymalną różnicę czasu między czasem prawdziwym a czasem RTC VU, stosownie do potrzeb, stosując polecenia SELECT [wybór] i WRITE RECORD(S) [zapis rekordu(-ów)] zgodnie z normą ISO/IEC 7816-4:2013 w trybie tylko uwierzytelniania bezpiecznej wymiany komunikatów, jak opisano w dodatku 11 sekcja 11.5, z identyfikatorem pliku '2F30' i numerem rekordu równym '01' dla VuRtc- Time oraz '02' for MaximalTimeDifference.
4.2.3 Struktura polecenia Read Record
Poniższa sekcja zawiera szczegółowy opis struktury polecenia Read Record. Zgodnie z opisem przedstawionym w dodatku 11 "Wspólne mechanizmy zabezpieczenia" dodaje się funkcję bezpiecznej wymiany komunikatów (tryb tylko uwierzytelniania).
GNS_24 Polecenie to obsługuje tryb tylko uwierzytelniania bezpiecznej wymiany komunikatów, zob. dodatek 11.
GNS_25 Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '0Ch' | Żądanie bezpiecznej wymiany komunikatów |
| INS | 1 | 'B2h' | Odczyt rekordu |
| P1 | 1 | 'XXh' | Numer rekordu ('00' oznacza bieżący rekord) |
| P2 | 1 | '04h' | Odczytaj rekord o numerze rekordu wskazanym w P1 |
| Le | 1 | 'XXh' | Długość oczekiwanych danych. Liczba bajtów do odczytu |
GNS_26 Rekord wskazany w P1 staje się rekordem bieżącym.
| Bajt | Długość | Wartość | Opis |
| #1-#X | X | 'XX..XXh' | Odczyt danych |
| SW | 2 | 'XXXXh' | Słowo stanu (SW1, SW2) |
- jeżeli wykonanie polecenia zakończyło się pomyślnie, bezpieczny nadajnik-odbiornik GNSS zwraca komunikat '9000',
- jeżeli bieżący plik nie jest ukierunkowany na rekord, bezpieczny nadajnik-odbiornik GNSS zwraca komunikat '6981',
- jeżeli stosuje się polecenie z P1= '00', lecz nie ma żadnego bieżącego pliku elementarnego, bezpieczny nadajnik-odbiornik GNSS zwraca komunikat '6986' (polecenie niedozwolone),
- jeżeli nie znaleziono rekordu, bezpieczny nadajnik-odbiornik GNSS zwraca komunikat '6A83',
- jeżeli urządzenie zewnętrzne GNSS wykryje manipulowanie, zwraca słowa stanu '6690".
GNS_27 (uchylony).
4.2.4 Struktura polecenia WriteRecord
Poniższa sekcja zawiera szczegółowy opis struktury polecenia Write Record [zapis rekordu]. Zgodnie z opisem przedstawionym w dodatku 11 "Wspólne mechanizmy zabezpieczenia" dodaje się funkcję bezpiecznej wymiany komunikatów (tryb tylko uwierzytelniania).
GNS_26a Polecenie to obsługuje tryb tylko uwierzytelniania bezpiecznej wymiany komunikatów, zob. dodatek 11.
GNS_26b Komunikat polecenia
| Bajt | Długość | Wartość | Opis |
| CLA | 1 | '0Ch' | Żądanie bezpiecznej wymiany komunikatów |
| INS | 1 | 'D2h' | Zapis rekordu |
| P1 | 1 | 'XXh' | Numer rekordu ('00' oznacza bieżący rekord) |
| P2 | 1 | '04h' | Zapis rekordu o numerze rekordu wskazanym w P1 |
| Dane | X | 'XXh' | Dane |
GNS_26c Rekord wskazany w P1 staje się rekordem bieżącym.
| Bajt | Długość | Wartość | Opis |
| SW | 2 | 'XXXXh' | Słowa stanu (SW1, SW2) |
4.2.5. Inne polecenia
GNS_27 Bezpieczny nadajnik-odbiornik GNSS obsługuje następujące polecenia tachografów 2. generacji, wyszczególnione w dodatku 2:
| Polecenie | Odniesienie |
| Select [wybór] | Dodatek 2 rozdział 3.5.1 |
| Read Binary [odczyt binarny] | Dodatek 2 rozdział 3.5.2 |
| Get Challenge [wydanie wezwania] | Dodatek 2 rozdział 3.5.4 |
| PSO: Verify Certificate [weryfikacja certyfikatu] | Dodatek 2 rozdział 3.5.7 |
| External authenticate [uwierzytelnianie zewnętrzne] | Dodatek 2 rozdział 3.5.9 |
| General Authenticate [uwierzytelnianie ogólne] | Dodatek 2 rozdział 3.5.10 |
| MSE:SET | Dodatek 2 rozdział 3.5.11 |
4.3. Powiązanie, wzajemne uwierzytelnienie i uzgodnienie klucza sesji między urządzeniem zewnętrznym GNSS a przyrządem rejestrującym
Proces powiązania, wzajemnego uwierzytelniania i uzgadniania klucza sesji między urządzeniem zewnętrznym GNSS a przyrządem rejestrującym opisano w rozdziale 11 dodatku 11 "Wspólne mechanizmy zabezpieczenia".
4.4. Obsługa błędów
W niniejszej sekcji opisano sposób obsługi potencjalnych warunków błędów przez urządzenie zewnętrzne GNSS oraz ich rejestrowania w VU.
4.4.1 Błąd komunikacji z urządzeniem zewnętrznym GNSS
GNS_28 Błąd połączenia z urządzeniem zewnętrznym GNSS zapisuje się w VU, jak określono w wymogu 82 w załączniku IC i dodatku 1 (EventFaultType). W tym kontekście występuje błąd połączenia, gdy bezpieczny nadajnik-odbiornik VU nie otrzyma komunikatu odpowiedzi po wysłaniu komunikatu żądania, jak opisano w pkt 4.2.
4.4.2 Naruszenie integralności fizycznej urządzenia zewnętrznego GNSS
GNS_29 W przypadku naruszenia integralności fizycznej urządzenia zewnętrznego GNSS bezpieczny
nadajnik-odbiornik GNSS gwarantuje niedostępność materiału kryptograficznego. Jak opisano w GNS_25 i GNS_26, VU wykrywa manipulowanie, jeżeli odpowiedź ma status '6690'. Następnie VU generuje i rejestruje zdarzenie związane z próbą naruszenia zabezpieczenia zdefiniowane w wymogu 85 w załączniku IC i dodatku 1 (EventFaultType do celów wykrywania manipulowania w GNSS). Urządzenie zewnętrzne GNSS może ewentualnie odpowiedzieć na żądania VU bez bezpiecznej wymiany komunikatów i ze statusem '6A88'.
4.4.3 Brak informacji o położeniu z odbiornika GNSS
GNS_30 Jeżeli bezpieczny nadajnik-odbiornik GNSS nie otrzymuje danych z odbiornika GNSS, urządzenie to generuje komunikat odpowiedzi na polecenie READ RECORD [odczyt rekordu] z numerem rekordu '01' i polem danych o rozmiarze 12 bajtów, wszystkich ustawionych na 0xFF. Po otrzymaniu komunikatu odpowiedzi zawierającego tę wartość pola danych VU generuje i rejestruje brak informacji o pozycji ze zdarzenia odbiornika GNSS, jak określono w wymogu 81 w załączniku IC i dodatku 1 (EventFaultType).
4.4.4 Wygaśnięcie certyfikatu urządzenia zewnętrznego GNSS
GNS_31 Jeżeli VU wykryje, że certyfikat EGF stosowany do wzajemnego uwierzytelniania nie jest już ważny, VU generuje i rejestruje zdarzenie związane z próbą naruszenia zabezpieczenia zdefiniowane w wymogu 85 w załączniku IC i dodatku 1 (EventFaultType dla wygaśnięcia certyfikatu urządzenia zewnętrznego GNSS). VU nadal wykorzystuje otrzymane dane GNSS o pozycji.
Rysunek 6
Schemat urządzenia zewnętrznego GNSS
5. PRZYRZĄD REJESTRUJĄCY BEZ URZĄDZENIA ZEWNĘTRZNEGO GNSS
5.1. Konfiguracja
W tej konfiguracji odbiornik GNSS znajduje się wewnątrz przyrządu rejestrującego, jak przedstawiono na rys. 1.
GNS_32 Na potrzeby przekazywania pozycji, DOP i danych satelitarnych odbiornik GNSS pełni
funkcję nadajnika i przesyła komunikaty NMEA i podobne do NMEA do procesora VU, który pełni funkcję odbiornika o częstotliwości 1/10 Hz lub większej dla zdefiniowanego wcześniej zbioru komunikatów, który musi obejmować co najmniej komunikaty RMC, GSA, AMC i ASA. Procesor VU i wewnętrzny odbiornik GNSS mogą ewentualnie wykorzystywać inne formaty danych do wymiany danych zawartych w komunikatach NMEA lub podobnych do NMEA określonych w GNS_4, GNS_4a i GNS_5.
GNS_33 Do VU musi być podłączona zewnętrzna antena GNSS zainstalowana na pojeździe lub wewnętrzna antena GNSS.
5.2. Transfer informacji z odbiornika GNSS do VU
GNS_34 Procesor VU sprawdza otrzymane dane, wyodrębniając informacje (np. o długości geograficznej, szerokości geograficznej, czasie) z komunikatu RMC NMEA i komunikatu AMC.
GNS_35 Komunikat RMC NMEA zawiera informację o tym, czy nieuwierzytelniona pozycja jest prawidłowa. Jeżeli nieuwierzytelniona pozycja nie jest prawidłowa, dane dotyczące pozycji nie są dostępne i nie można ich wykorzystać w celu zarejestrowania pozycji pojazdu. Jeżeli nieuwierzytelniona pozycja jest prawidłowa, procesor VU wyodrębnia również wartości HDOP z GSA NMEA.
GNS_36 Procesor VU wyodrębnia również informacje (np. o długości geograficznej, szerokości geograficznej, czasie) z komunikatu AMC. Komunikat AMC zawiera informację o tym, czy nieuwierzytelniona pozycja jest prawidłowa zgodnie z GNS_4a. Jeżeli nieuwierzytel- niona pozycja jest prawidłowa, procesor VU wyodrębnia również wartości HDOP z komunikatów ASA.
5.3. Transfer informacji z VU do odbiornika GNSS
GNS_37 Procesor VU przekazuje do odbiornika GNSS czas RTC VU oraz maksymalną różnicę między czasem prawdziwym a czasem RTC VU, zgodnie z GNS_3f i GNS_3g.
5.4. Obsługa błędów
5.4.1. Brak informacji o pozycji z odbiornika GNSS
GNS_38 VU generuje i rejestruje brak informacji o pozycji ze zdarzenia odbiornika GNSS, jak określono w wymogu 81 w załączniku IC i dodatku 1 (EventFaultType).
6. PRZETWARZANIE I REJESTRACJA DANYCH O POZYCJI PRZEZ VU
Sekcja ta ma zastosowanie w odniesieniu do konfiguracji tachografu inteligentnego z urządzeniem zewnętrznym GNSS lub bez niego.
GNS_39 Dane o pozycji są przechowywane w VU wraz z flagą wskazującą, czy pozycja została uwierzytelniona. Jeżeli konieczne jest zarejestrowanie danych dotyczących pozycji w VU, zastosowanie mają następujące zasady:
a) Jeżeli zarówno uwierzytelniona pozycja, jak i standardowa pozycja są prawidłowe i spójne, standardową pozycję i jej dokładność rejestruje się w VU, a flaga ustawiana jest na »uwierzytelniona«.
b) Jeżeli zarówno uwierzytelniona pozycja, jak i standardowa pozycja są prawidłowe, ale nie są spójne, VU zapisuje uwierzytelnioną pozycję i jej dokładność, a flaga ustawiana jest na »uwierzytelniona«.
c) Jeżeli uwierzytelniona pozycja jest prawidłowa, a standardowa pozycja nie jest prawidłowa, VU rejestruje uwierzytelnioną pozycję i jej dokładność, a flaga ustawiana jest na »uwierzytelniona«.
d) Jeżeli standardowa pozycja jest prawidłowa, a uwierzytelniona pozycja nie jest prawidłowa, VU rejestruje standardową pozycję i jej dokładność, a flaga ustawiana jest na »nie- nieuwierzytelniona«.
Uwierzytelnione i standardowe pozycje uznaje się za spójne, jak pokazano na rys. 7, jeżeli uwierzytelniona pozycja pozioma znajduje się w okręgu o środku w standardowej pozycji poziomej, którego promień wynika z zaokrąglenia w górę do najbliższej liczby całkowitej wartości R_H obliczonej według następującego wzoru:
R_H = 1,74 * Ouere * HDOP
gdzie:
- R_H to odpowiedni promień okręgu wokół szacowanej pozycji poziomej, w metrach. Jest to wskaźnik używany do kontroli spójności między pozycją standardową a pozycją uwierzytelnioną.
- oUERE to odchylenie standardowe ekwiwalentnego błędu pomiaru odległości użytkownika (UERE), gdzie modeluje się wszystkie błędy pomiaru dla docelowego zastosowania, w tym obszarów miejskich. Stosuje się wartość stałą oUERE = 10 metrów.
- σ UERE, HDOP oznacza poziome rozmycie dokładności obliczeń odbiornika GNSS.-oUERE. HDOP to oszacowanie pierwiastka błędu średniokwadratowego w poziomie.
Rysunek 7
Spójne pozycje uwierzytelnione i standardowe (nieuwierzytel- nione)
GNS_40 Jeżeli wartość statusu w otrzymanym komunikacie AMC jest ustawiona na 'J' lub 'O' lub 'F' zgodnie z wymogiem GNS_4a, VU generuje i rejestruje zdarzenie anomalii GNSS, jak określono w wymogu 88a w załączniku IC i dodatku 1 (EventFaultType). Przyrząd rejestrujący może przeprowadzić dodatkowe kontrole przed zapisaniem zdarzenia anomalii GNSS po otrzymaniu ustawienia 'J' lub 'O'.
7. KONFLIKT CZASOWY GNSS
GNS_41 Jeżeli VU wykryje rozbieżność między czasem funkcji pomiaru czasu przyrządu rejestrującego a czasem pochodzącym z sygnałów GNSS, generuje i rejestruje zdarzenie konfliktu czasowego, jak określono w wymogu 86 w załączniku IC i dodatku 1 (EventFaultType).
8. KONFLIKT RUCHU POJAZDU
GNS_42 VU uruchamia i rejestruje zdarzenie konfliktu ruchu pojazdu zgodnie z wymogiem 84 w załączniku IC, w przypadku gdy informacja o ruchu obliczona na podstawie czujnika ruchu jest sprzeczna z informacjami o ruchu obliczonymi na podstawie wewnętrznego odbiornika GNSS, urządzenia zewnętrznego GNSS lub przez inne niezależne źródła ruchu określone w wymogu 26 w załączniku IC.
Zdarzenie konfliktu ruchu pojazdu uruchamia się po wystąpieniu jednego z następujących warunków uruchamiających:
Warunek uruchamiający 1:
W przypadku gdy dostępne są informacje o pozycji z odbiornika GNSS i gdy następuje włączenie zapłonu pojazdu, należy stosować wartość średniej trymowanej różnic prędkości między tymi źródłami, jak określono poniżej:
- maksymalnie co 10 sekund należy obliczać wartość bezwzględną różnicy między różnicą prędkości pojazdu szacowaną na podstawie danych z odbiornika GNSS a różnicą szacowaną na podstawie danych z czujnika ruchu,
- wartość średniej trymowanej oblicza się wykorzystując wszystkie obliczone wartości w oknie czasu obejmującym 5 ostatnich minut ruchu pojazdu,
- wartość średniej trymowanej oblicza się jako średnią 80 % wartości pozostałych po wyeliminowaniu najwyższych wartości bezwzględnych.
zdarzenie konfliktu ruchu pojazdu jest wyzwalane jeżeli wartość średniej trymowanej jest wyższa niż 10 km/h przez pięć nieprzerwanych minut ruchu pojazdu. (Uwaga: średnią trymowaną z ostatnich 5 minut stosuje się, aby zmniejszyć ryzyko związane z wartościami skrajnymi pomiaru i wartościami chwilowymi).
Na potrzeby obliczenia średniej trymowanej pojazd uznaje się za poruszający się, jeżeli co najmniej jedna wartość prędkości pojazdu oszacowana na podstawie czujnika ruchu albo odbiornika GNSS nie jest równa zeru.
Warunek uruchamiający 2:
Zdarzenie konfliktu ruchu pojazdu jest również uruchamiane, jeżeli spełniony jest następujący warunek:
GnssDistance >[ OdometerDifference * OdometerToleranceFactor+Minimum (SlipDistanceUpperli- pperlimit;(OdometerDifference * SlipFactor))+GnssTolerance+FerryTrainDistance ]
gdzie:
- GnssDistance to odległość między bieżącą pozycją pojazdu a poprzednią pozycją, uzyskanymi na podstawie komunikatów o prawidłowej pozycji uwierzytelnionej, bez uwzględniania wysokości;
- OdometerDifference to różnicą między bieżącą wartością licznika kilometrów a wartością licznika kilometrów odpowiadającą poprzedniemu komunikatowi o prawidłowej pozycji uwierzytelnionej;
- OdometerToleranceFactor wynosi 1,1 (współczynnik tolerancji najbardziej niekorzystnego przypadku dla wszystkich tolerancji pomiaru licznika kilometrów pojazdu);
- GnssTolerance wynosi 1 km (najbardziej niekorzystny przypadek tolerancji GNSS);
- Minimum (SlipDistanceUpperLimit; (OdometerDifference * SlipFactor)) to wartość najmniejsza spośród następujących:
- SlipDistanceUpperLimit, która wynosi 10 km (górna granica drogi poślizgu spowodowanej efektami poślizgowymi podczas hamowania)
- oraz OdometerDifference * SlipFactor, gdzie SlipFactor wynosi 0,2 (maksymalny wpływ efektów poślizgowych podczas hamowania),
- FerryTrainDistance oblicza się jako: FerryTrainDistance =200km/h * tFerryTrain, gdzie tFerryTrain jest sumą czasu trwania (w godzinach) przepraw promowych/pociągo- wych w analizowanym przedziale czasowym. Czas trwania przepraw promowych/ pociągowych definiuje się jako różnicę czasu między jego flagą końcową a jego flagą początkową.
Poprzedzające weryfikacje przeprowadza się co 15 minut, jeżeli dostępne są niezbędne dane o pozycji, a w przeciwnym razie, gdy tylko dostępne będą dane o pozycji.
Dla tego warunku uruchamiającego:
- data i godzina rozpoczęcia zdarzenia równa się dacie i godzinie otrzymania poprzedniego komunikatu o pozycji,
- data i godzina zakończenia zdarzenia są równa się dacie i godzinie, kiedy sprawdzany warunek staje się ponownie fałszywy.
Warunek uruchamiający 3:
Przyrząd rejestrujący napotyka rozbieżność polegającą na tym, że czujnik ruchu nie wykrywa żadnego ruchu, a niezależne źródło ruchu wykrywa ruch przez określony czas. Producent przyrządów rejestrujących określa warunki rejestrowania rozbieżności, jak również okres wykrywania rozbieżności, przy czym rozbieżności te muszą być wykrywane nie później niż w ciągu trzech godzin.
Dodatek 13 34
INTERFEJS ITS
INTERFEJS ITS
1. WPROWADZENIE
1.1. Zakres
1.2. Akronimy i definicje
2. PRZYWOŁANE NORMY
3. ZASADY DZIAŁANIA INTERFEJSU ITS
3.1. Technologia łączności
3.2. Dostępne usługi
3.3. Dostęp poprzez interfejs ITS
3.4. Dostępne dane i wymóg uzyskania zgody kierowcy
4. WYKAZ DANYCH DOSTĘPNYCH ZA POŚREDNICTWEM INTERFEJSU ITS ORAZ KLASYFIKACJA DANYCH JAKO OSOBOWE/NIEOSOBOWE
1. WPROWADZENIE
1.1. Zakres
ITS_01 Niniejszy dodatek określa podstawowe elementy łączności za pośrednictwem interfejsu tachografu z inteligentnymi systemami transportowymi (ITS).
ITS_02 Interfejs ITS umożliwia urządzeniom zewnętrznym uzyskiwanie danych z tachografu, korzystanie z usług tachografu oraz dostarczanie danych do tachografu.
Do tego celu mogą być również wykorzystywane inne interfejsy tachografu (np. szyna CAN).
Niniejszy dodatek nie określa:
- w jaki sposób dane dostarczane za pośrednictwem interfejsu ITS są gromadzone i zarządzane w ramach tachografu;
- formy przedstawienia zgromadzonych danych w aplikacji zainstalowanej na urządzeniu zewnętrznym;
- specyfikacji zabezpieczeń ITS uzupełniających zabezpieczenia zapewniane przez Bluetooth®;
- protokołów Bluetooth® wykorzystywanych przez interfejs ITS.
1.2. Akronimy i definicje
Stosuje się następujące akronimy i definicje właściwe dla tego dodatku:
GNSS Global Navigation Satellite System [globalny system nawigacji satelitarnej]
ITS Intelligent Transport System [inteligentny system transportowy]
OSI Open Systems Interconnection [połączenie systemów otwartych]
VU Vehicle Unit [przyrząd rejestrujący]
urządzenie ITS urządzenie zewnętrzne lub aplikacja zewnętrzna wykorzystujące interfejs ITS VU.
2. PRZYWOŁANE NORMY
ITS_03 Niniejszy dodatek dotyczy wszystkich lub części wskazanych poniżej regulacji i norm i jest
od nich zależny. W ramach zapisów niniejszego dodatku wskazano odnośne normy lub odnośne przepisy norm. W razie jakichkolwiek sprzeczności zapisy niniejszego dodatku są nadrzędne.
Normami przywołanymi w niniejszym dodatku, są:
- Bluetooth® - Core Version (wersja podstawowa) 5.0;
- ISO 16844-7: Pojazdy drogowe - Systemy tachograficzne - Część 7: Parametry
- ISO/IEC7498-1:1994 Technologia informatyczna - Współdziałanie systemów otwartych - Podstawowy model odniesienia: Model podstawowy
3. ZASADY DZIAŁANIA INTERFEJSU ITS
ITS_04 Przyrząd rejestrujący odpowiada za aktualizowanie i utrzymywanie danych tachografu przesyłanych za pośrednictwem interfejsu ITS, bez żadnego udziału interfejsu ITS.
3.1. Technologia łączności
ITS_05 Łączność poprzez interfejs ITS musi być zapewniana za pośrednictwem interfejsu Bluetooth® i kompatybilna z Bluetooth® Low Energy [o niskim zużyciu energii] zgodnie z wersją 5.0 lub nowszą Bluetooth.
ITS_06 Łączność między VU a urządzeniem ITS ustanawia się po zakończeniu procesu parowania Bluetooth®.
ITS_07 Ustanawia się bezpieczną i zaszyfrowaną łączność między VU a urządzeniem ITS, zgodnie z mechanizmami specyfikacji Bluetooth®. Niniejszy dodatek nie określa mechanizmów szyfrowania ani innych mechanizmów zabezpieczenia poza tym, co zapewnia Bluetooth®.
ITS_08 Bluetooth® wykorzystuje model serwer/klient do kontroli transmisji danych między urządzeniami, gdzie VU jest serwerem, a urządzenie ITS klientem.
3.2. Dostępne usługi
ITS_09 Dane przekazywane za pośrednictwem interfejsu ITS zgodnie z pkt 4 udostępnia się za pośrednictwem usług określonych w dodatkach 7 i 8. Ponadto VU udostępnia urządzeniu ITS usługi niezbędne do ręcznego wprowadzania danych zgodnie z wymogiem 61 w załączniku IC oraz opcjonalnie w odniesieniu do innych wpisów danych w czasie rzeczywistym.
Rysunek 1
Podział łączności poprzez interfejs ITS zgodnie z warstwami modelu OSI
ITS_10 Jeżeli interfejs pobierania jest używany przez złącze przednie, VU nie świadczy usług pobierania określonych w dodatku 7 za pośrednictwem połączenia ITS Bluetooth®.
ITS_11 Jeżeli interfejs kalibracji jest używany przez złącze przednie, VU nie świadczy usług kalibracji określonych w dodatku 8 za pośrednictwem połączenia ITS Bluetooth®.
3.3. Dostęp poprzez interfejs ITS
ITS_12 Interfejs ITS zapewnia bezprzewodowy dostęp do wszystkich usług określonych w dodatkach 7 i 8, zastępując połączenie kablowe z przednim złączem do celów kalibracji i pobierania określonych w dodatku 6.
ITS_13 VU udostępnia interfejs ITS użytkownikowi zgodnie z kombinacją ważnych kart do tachografów włożonych do VU, jak określono w tabeli 1.
Tabela 1
Dostępność interfejsu ITS w zależności od typu karty włożonej do tachografu
| Dostępność interfejsu ITS | Szczelina czytnika karty kierowcy | ||||
| Brak karty | Karta kierowcy | Karta kontrolna | Karta warsztatowa | Karta firmowa | |
| Szczelina czytnika karty współkierowcy | Brak karty | niedostępny | dostępny | dostępny | dostępny | dostępny |
| Karta kierowcy | dostępny | dostępny | dostępny | dostępny | dostępny | |
| Karta kontrolna | dostępny | dostępny | dostępny | niedostępny | niedostępny | |
| Karta warsztatowa | dostępny | dostępny | niedostępny | dostępny | niedostępny | |
| Karta firmowa | dostępny | dostępny | niedostępny | niedostępny | dostępny |
ITS_14 Po udanym sparowaniu ITS Bluetooth® VU przypisuje połączenie ITS Bluetooth® do konkretnej karty włożonej do tachografu zgodnie z tabelą 2:
Tabela 2
Przypisanie połączenia ITS w zależności od typu karty włożonej do tachografu
| Przypisanie połączenia ITS Bluetooth® | Szczelina czytnika karty kierowcy | ||||
| Brak karty | Karta kierowcy | Karta kontrolna | Karta warsztatowa | Karta firmowa | |
| Szczelina czytnika karty współkierowcy | Brak karty | niedostępny | Karta kierowcy | Karta kontrolna | Karta warsztatowa | Karta firmowa |
| Karta kierowcy | Karta kierowcy | Karta kierowcy (**) | Karta kontrolna | Karta warsztatowa | Karta firmowa | |
| Karta kontrolna | Karta kontrolna | Karta kontrolna | Karta kontrolna (*) | niedostępny | niedostępny | |
| Karta warsztatowa | Karta warsztatowa | Karta warsztatowa | niedostępny | Karta warsztatowa (*) | niedostępny | |
| Karta firmowa | Karta firmowa | Karta firmowa | niedostępny | niedostępny | Karta firmowa (*) |
| (*) Połączenie ITS Bluetooth® przypisuje się karcie do tachografu w szczelinie czytnika karty kierowcy VU. (**) Użytkownik wybiera kartę, do której należy przypisać połączenie ITS Bluetooth® (włożoną do szczeliny czytnika karty kierowcy lub współkierowcy). |
ITS_15 Jeżeli karta do tachografu zostaje wyjęta, VU kończy połączenie ITS Bluetooth®, które jest przypisane do tej karty.
ITS_16 VU obsługuje połączenie ITS z co najmniej jednym urządzeniem ITS i może obsługiwać połączenia z wieloma urządzeniami ITS w tym samym czasie.
ITS_17 Oprócz zgody kierowcy określonej w sekcji 3.4 niniejszego dodatku, prawa dostępu do danych i usług dostępnych za pośrednictwem interfejsu ITS muszą być dodatkowo zgodne z wymogami 12 i 13 w załączniku IC.
3.4. Dostępne dane i wymóg uzyskania zgody kierowcy
| ITS_18 | Wszystkie dane tachografu dostępne za pośrednictwem usług, o których mowa w pkt 3.3, klasyfikuje się jako dane osobowe albo nieosobowe w odniesieniu do kierowcy, współkie- rowcy lub obu tych osób. |
| ITS_19 | Za pośrednictwem interfejsu ITS udostępnia się przynajmniej wykaz danych sklasyfikowanych w sekcji 4 jako dostępne obowiązkowo. |
| ITS_20 | Dane w sekcji 4, które sklasyfikowano jako »osobowe«, są dostępne wyłącznie za zgodą kierowcy, który zaakceptował, że dane osobowe mogą opuścić sieć pojazdu, z wyjątkiem przypadku określonego w wymogu ITS_25, gdzie zgoda kierowcy nie jest wymagana. |
| ITS_21 | Dane dodatkowe w stosunku do danych zgromadzonych w pkt 4 i uznanych za obowiązkowe mogą być udostępniane poprzez interfejs ITS. Dodatkowe dane, które nie są wymienione w pkt 4, są klasyfikowane przez producenta VU jako »osobowe« lub »nieosobowe«, co oznacza, że kierowca musi wyrazić zgodę na te dane, które zostały sklasyfikowane jako dane osobowe, z wyjątkiem przypadku określonego w wymogu ITS_25, gdzie zgoda kierowcy nie jest wymagana. |
| ITS_22 | Po włożeniu karty kierowcy, która nie jest znana przyrządowi rejestrującemu, tachograf wzywa posiadacza karty do wprowadzenia zgody na przesyłanie wyjściowych danych osobowych poprzez interfejs ITS, zgodnie z wymogiem 61 w załączniku IC. |
| ITS_23 | Status zgody (aktywny/nieaktywny) jest zapisywany w pamięci danych przyrządu rejestrującego. |
| ITS_24 | W przypadku wielu kierowców udostępnianiu poprzez interfejs ITS podlegają wyłącznie dane osobowe dotyczące kierowców, którzy wyrazili na to zgodę. Na przykład w przypadku załogi, jeżeli zgodę wyraził tylko kierowca, dane osobowe współkierowcy nie są udostępniane. |
| ITS_25 | Jeżeli VU znajduje się w trybie kontrolnym, firmowym lub kalibracyjnym, prawami dostępu poprzez interfejs ITS zarządza się zgodnie z wymogami 12 i 13 w załączniku IC, w związku z czym zgoda kierowcy nie jest wymagana. |
4. WYKAZ DANYCH DOSTĘPNYCH ZA POŚREDNICTWEM INTERFEJSU ITS ORAZ KLASYFIKACJA DANYCH JAKO OSO- BOWE/NIEOSOBOWE
| Nazwa danych | Format danych | Źródło | Klasyfikacja danych (osobowe/ nieosobowe) | Zgoda na udostępnienie danych | Dostępność | |
| kierowca | współkierowca | |||||
| VehicleIdentificationNumber | Dodatek 8 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| CalibrationDate | ISO 16844-7 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| TachographVehicleSpeed | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | obowiązkowo |
| DriverlWorkingState | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | obowiązkowo |
| Driver2WorkingState | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | obowiązkowo |
| DriveRecognize | ISO 16844-7 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| DriverlTimeRelatedStates | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | obowiązkowo |
| Driver2TimeRelatedStates | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | obowiązkowo |
| DriverCardDriverl | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | obowiązkowo |
| DriverCardDriver2 | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | obowiązkowo |
| OverSpeed | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | obowiązkowo |
| TimeDate | Dodatek 8 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| HighResolutionTotalVehi- cleDistance | ISO 16844-7 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| HighResolutionTripDis- tance | ISO 16844-7 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| ServiceComponentIdentification | ISO 16844-7 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| ServiceDelayCalendarTimeBased | ISO 16844-7 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| DriverlIdentification | ISO 16844-7 | karta kierowcy | osobowe | nie dotyczy | zgoda kierowcy | obowiązkowo |
| Driver2Identification | ISO 16844-7 | karta kierowcy | nie dotyczy | osobowe | zgoda współkierowcy | obowiązkowo |
| NextCalibrationDate | Dodatek 8 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| Driver1ContinuousDrivingTime | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | obowiązkowo |
| Driver2ContinuousDrivingTime | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | obowiązkowo |
| Driver1CumulativeBreakTime | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | obowiązkowo |
| Driver2CumulativeBreakTime | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | obowiązkowo |
| Driver1CurrentDuratio- nOfSelectedActivity | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | obowiązkowo |
| Driver2CurrentDuratio- nOfSelectedActivity | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | obowiązkowo |
| SpeedAuthorised | Dodatek 8 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| TachographCardSlotl | ISO 16844-7 | VU | nieosobowe | nie dotyczy | zgoda niewymagana | obowiązkowo |
| TachographCardSlot2 | ISO 16844-7 | VU | nie dotyczy | nieosobowe | zgoda niewymagana | obowiązkowo |
| DriverlName | ISO 16844-7 | karta kierowcy | osobowe | nie dotyczy | zgoda kierowcy | obowiązkowo |
| Driver2Name | ISO 16844-7 | karta kierowcy | nie dotyczy | osobowe | zgoda współkierowcy | obowiązkowo |
| OutOfScopeCondition | ISO 16844-7 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| ModeOfOperation | ISO 16844-7 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| Driver1CumulatedDri- vingTimePreviousAnd- CurrentWeek | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | obowiązkowo |
| Driver2CumulatedDri- vingTimePreviousAnd- CurrentWeek | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | obowiązkowo |
| EngineSpeed | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| RegisteringMemberState | Dodatek 8 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| VehicleRegistrationNumber | Dodatek 8 | VU | nieosobowe | nieosobowe | zgoda niewymagana | obowiązkowo |
| Driver1EndOfLastDailyR- estPeriod | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2EndOfLastDailyR- estPeriod | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| Driver1EndOfLastWeek- lyRestPeriod | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2EndOfLastWeek- lyRestPeriod | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| Driver1EndOfSecondLast- WeeklyRestPeriod | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2EndOfSecondLast- WeeklyRestPeriod | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| Driver1TimeLastLoadUn- loadOperation | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2TimeLastLoadUn- loadOperation | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| Driver1CurrentDailyDrivingTime | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2CurrentDailyDrivingTime | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| Driver1CurrentWeeklyDrivingTime | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2CurrentWeeklyDrivingTime | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| Driver1TimeLeftUntil- NewDailyRestPeriod | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2TimeLeftUntil- NewDailyRestPeriod | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| Driver1CardExpiryDate | ISO 16844-7 | karta kierowcy | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2CardExpiryDate | ISO 16844-7 | karta kierowcy | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| Driver1CardNextManda- toryDownloadDate | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2CardNextManda- toryDownloadDate | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| TachographNextMandatoryDownloadDate | ISO 16844-7 | VU | nieosobowe | nieosobowe | zgoda niewymagana | opcjonalnie |
| Driver1TimeLeftUntil- NewWeeklyRestPeriod | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2TimeLeftUntil- NewWeeklyRestPeriod | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| Driver1NumberOfTi- mes9hDailyDrivingTime- sExceeded | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2NumberOfTi- mes9hDailyDrivingTime- sExceeded | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| Driver1CumulativeUnin- terruptedRestTime | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2CumulativeUnin- terruptedRestTime | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| DriverlMinimumDailyR- est | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2MinimumDailyR- est | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| DriverlMinimumWeek- lyRest | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2MinimumWeek- lyRest | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| DriverlMaximumDaily- Period | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2MaximumDaily- Period | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| DriverlMaximumDaily- DrivingTime | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2MaximumDailyDrivingTime | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| DriverlNumberOfUse- dReducedDailyRestPer- iods | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2NumberOfUse- dReducedDailyRestPer- iods | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| DriverlRemainingCur- rentDrivingTime | ISO 16844-7 | VU | osobowe | nie dotyczy | zgoda kierowcy | opcjonalnie |
| Driver2RemainingCur- rentDrivingTime | ISO 16844-7 | VU | nie dotyczy | osobowe | zgoda współkierowcy | opcjonalnie |
| VehiclePosition | Dodatek 8 | VU | osobowe | osobowe | zgoda kierowcy i współkierowcy | obowiązkowo |
| ByDefaultLoadType | Dodatek 8 | VU | osobowe | osobowe | zgoda kierowcy i współkierowcy | obowiązkowo |
Załącznik 1 35
1)WYKAZ DANYCH DOSTĘPNYCH ZA POŚREDNICTWEM INTERFEJSU ITS";
1)WYKAZ DANYCH DOSTĘPNYCH ZA POŚREDNICTWEM INTERFEJSU ITS";
| Dane | Źródło | Klasyfikacja danych (osobowe/ nieosobowe) |
| VehicleIdentificationNumber | Przyrząd rejestrujący | nieosobowe |
| CalibrationDate | Przyrząd rejestrujący | nieosobowe |
| TachographVehicleSpeed speed instant t | Przyrząd rejestrujący | osobowe |
| Driver1WorkingState Selector driver | Przyrząd rejestrujący | osobowe |
| Driver2WorkingState | Przyrząd rejestrujący | osobowe |
| DriveRecognize Speed Threshold detected | Przyrząd rejestrujący | nieosobowe |
| Driver1TimeRelatedStates Weekly day time | Karta kierowcy | osobowe |
| Driver2TimeRelatedStates | Karta kierowcy | osobowe |
| DriverCardDriver1 | Przyrząd rejestrujący | nieosobowe |
| DriverCardDriver2 | Przyrząd rejestrujący | nieosobowe |
| OverSpeed | Przyrząd rejestrujący | osobowe |
| TimeDate | Przyrząd rejestrujący | nieosobowe |
| HighResolutionTotalVehicleDistance | Przyrząd rejestrujący | nieosobowe |
| ServiceComponentIdentification | Przyrząd rejestrujący | nieosobowe |
| ServiceDelayCalendarTimeBased | Przyrząd rejestrujący | nieosobowe |
| Driver1Identification | Karta kierowcy | osobowe |
| Driver2Identification | Karta kierowcy | osobowe |
| NextCalibrationDate | Przyrząd rejestrujący | nieosobowe |
| Driver1ContinuousDrivingTime | Karta kierowcy | osobowe |
| Driver2ContinuousDrivingTime | Karta kierowcy | osobowe |
| Driver1CumulativeBreakTime | Karta kierowcy | osobowe |
| Driver2CumulativeBreakTime | Karta kierowcy | osobowe |
| Driver1CurrentDurationOfSelectedActivity | Karta kierowcy | osobowe |
| Driver2CurrentDurationOfSelectedActivity | Karta kierowcy | osobowe |
| SpeedAuthorised | Przyrząd rejestrujący | nieosobowe |
| TachographCardSlot1 | Karta kierowcy | nieosobowe |
| TachographCardSlot2 | Karta kierowcy | nieosobowe |
| Driver1Name | Karta kierowcy | osobowe |
| Driver2Name | Karta kierowcy | osobowe |
| OutOfScopeCondition | Przyrząd rejestrujący | nieosobowe |
| ModeOfOperation | Przyrząd rejestrujący | nieosobowe |
| Driver1CumulatedDrivingTimePreviousAndCurrentWeek | Karta kierowcy | osobowe |
| Driver2CumulatedDrivingTimePreviousAndCurrentWeek | Karta kierowcy | osobowe |
| EngineSpeed | Przyrząd rejestrujący | osobowe |
| RegisteringMemberState | Przyrząd rejestrujący | nieosobowe |
| VehicleRegistrationNumber | Przyrząd rejestrujący | nieosobowe |
| Driver1EndOfLastDailyRestPeriod | Karta kierowcy | osobowe |
| Driver2EndOfLastDailyRestPeriod | Karta kierowcy | osobowe |
| Driver1EndOfLastWeeklyRestPeriod | Karta kierowcy | osobowe |
| Driver2EndOfLastWeeklyRestPeriod | Karta kierowcy | osobowe |
| Driver1EndOfSecondLastWeeklyRestPeriod | Karta kierowcy | osobowe |
| Driver2EndOfSecondLastWeeklyRestPeriod | Karta kierowcy | osobowe |
| Driver1CurrentDailyDrivingTime | Karta kierowcy | osobowe |
| Driver2CurrentDailyDrivingTime | Karta kierowcy | osobowe |
| Driver1CurrentWeeklyDrivingTime | Karta kierowcy | osobowe |
| Driver2CurrentWeeklyDrivingTime | Karta kierowcy | osobowe |
| Driver1TimeLeftUntilNewDailyRestPeriod | Karta kierowcy | osobowe |
| Driver2TimeLeftUntilNewDailyRestPeriod | Karta kierowcy | osobowe |
| Driver1CardExpiryDate | Karta kierowcy | osobowe |
| Driver2CardExpiryDate | Karta kierowcy | osobowe |
| Driver1CardNextMandatoryDownloadDate | Karta kierowcy | osobowe |
| Driver2CardNextMandatoryDownloadDate | Karta kierowcy | osobowe |
| TachographNextMandatoryDownloadDate | Przyrząd rejestrujący | nieosobowe |
| Driver1TimeLeftUntilNewWeeklyRestPeriod | Karta kierowcy | osobowe |
| Driver2TimeLeftUntilNewWeeklyRestPeriod | Karta kierowcy | osobowe |
| Driver1NumberOfTimes9hDailyDrivingTimesExceeded | Karta kierowcy | osobowe |
| Driver2NumberOfTimes9hDailyDrivingTimesExceeced | Karta kierowcy | osobowe |
| Driver1CumulativeUninterruptedRestTime | Karta kierowcy | osobowe |
| Driver2CumulativeUninterruptedRestTime | Karta kierowcy | osobowe |
| Driver1MinimumDailyRest | Karta kierowcy | osobowe |
| Driver2MinimumDailyRest | Karta kierowcy | osobowe |
| Driver1MinimumWeeklyRest | Karta kierowcy | osobowe |
| Driver2MinimumWeeklyRest | Karta kierowcy | osobowe |
| Driver1MaximumDailyPeriod | Karta kierowcy | osobowe |
| Driver2MaximumDailyPeriod | Karta kierowcy | osobowe |
| Driver1MaximumDailyDrivingTime | Karta kierowcy | osobowe |
| Driver2MaximumDailyDrivingTime | Karta kierowcy | osobowe |
| Driver1NumberOfUsedReducedDailyRestPeriods | Karta kierowcy | osobowe |
| Driver2NumberOfUsedReducedDailyRestPeriods | Karta kierowcy | osobowe |
| Driver1RemainingCurrentDrivingTime | Karta kierowcy | osobowe |
| Driver2RemainingCurrentDrivingTime | Karta kierowcy | osobowe |
| GNSS position | Przyrząd rejestrujący | osobowe |
Zobacz dodatek 12 - GNSS.
3) KODY ZDARZEŃ DOSTĘPNE BEZ ZGODY KIEROWCY
| Zdarzenie | Zasady gromadzenia danych | Dane rejestrowane dla zdarzenia |
| Włożenie karty nieważnej | - 10 ostatnich zdarzeń | - data i godzina wystąpienia zdarzenia, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja karty powodującej zdarzenie, - liczba podobnych zdarzeń w tym dniu. |
| Konflikt kart | - 10 ostatnich zdarzeń | - data i godzina rozpoczęcia zdarzenia, - data i godzina zakończenia zdarzenia, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja obu kart powodujących konflikt. |
| Sesja ostatniej karty niezamknięta prawidłowo | - 10 ostatnich zdarzeń | - data i godzina włożenia karty, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja karty, - dane dotyczące ostatniej sesji odczytane z karty: - data i godzina włożenia karty, - numer VRN, państwo członkowskie rejestracji oraz generacja VU. |
| Przerwa w zasilaniu (2) | - najdłuższe zdarzenie w każdym z ostatnich 10 dni ich występowania, - 5 najdłużej trwających zdarzeń w ciągu ostatnich 365 dni. | - data i godzina rozpoczęcia zdarzenia, - data i godzina zakończenia zdarzenia, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja każdej karty włożonej na początku lub po zakończeniu zdarzenia, - liczba podobnych zdarzeń w tym dniu. |
| Błąd łączności z urządzeniem do łączności na odległość | - najdłuższe zdarzenie w każdym z ostatnich 10 dni ich występowania, - 5 najdłużej trwających zdarzeń w ciągu ostatnich 365 dni. | - data i godzina rozpoczęcia zdarzenia, - data i godzina zakończenia zdarzenia, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja każdej karty włożonej na początku lub po zakończeniu zdarzenia, - liczba podobnych zdarzeń w tym dniu. |
| Brak informacji o położeniu z odbiornika GNSS | - najdłuższe zdarzenie w każdym z ostatnich 10 dni ich występowania, - 5 najdłużej trwających zdarzeń w ciągu ostatnich 365 dni. | - data i godzina rozpoczęcia zdarzenia, - data i godzina zakończenia zdarzenia, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja każdej karty włożonej na początku lub po zakończeniu zdarzenia, - liczba podobnych zdarzeń w tym dniu. |
| Błąd danych dotyczących ruchu | - najdłuższe zdarzenie w każdym z ostatnich 10 dni ich występowania, - 5 najdłużej trwających zdarzeń w ciągu ostatnich 365 dni. | - data i godzina rozpoczęcia zdarzenia, - data i godzina zakończenia zdarzenia, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja każdej karty włożonej na początku lub po zakończeniu zdarzenia, - liczba podobnych zdarzeń w tym dniu. |
| Konflikt ruchu pojazdu | - najdłuższe zdarzenie w każdym z ostatnich 10 dni ich występowania, - 5 najdłużej trwających zdarzeń w ciągu ostatnich 365 dni. | - data i godzina rozpoczęcia zdarzenia, - data i godzina zakończenia zdarzenia, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja każdej karty włożonej na początku lub po zakończeniu zdarzenia, - liczba podobnych zdarzeń w tym dniu. |
| Próba naruszenia zabezpieczenia | 10 ostatnich zdarzeń wg typu zdarzenia. | - data i godzina rozpoczęcia zdarzenia, - data i godzina zakończenia zdarzenia (o ile dotyczy), - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja każdej karty włożonej na początku lub po zakończeniu zdarzenia, - typ zdarzenia. |
| Konflikt czasowy | - najdłuższe zdarzenie w każdym z ostatnich 10 dni ich występowania, - 5 najdłużej trwających zdarzeń w ciągu ostatnich 365 dni. | - data i godzina na urządzeniu rejestrującym, - data i godzina na odbiorniku GNSS, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja każdej karty włożonej na początku lub po zakończeniu zdarzenia, - liczba podobnych zdarzeń w tym dniu. |
4) KODY ZDARZENIA DOSTĘPNE BEZ ZGODY KIEROWCY
| Zdarzenie | Zasady gromadzenia danych | Dane rejestrowane dla zdarzenia |
| Prowadzenie bez prawidłowej karty | - najdłuższe zdarzenie w każdym z ostatnich 10 dni ich występowania, - 5 najdłużej trwających zdarzeń w ciągu ostatnich 365 dni. | - data i godzina rozpoczęcia zdarzenia, - data i godzina zakończenia zdarzenia, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja każdej karty włożonej na początku lub po zakończeniu zdarzenia, - liczba podobnych zdarzeń w tym dniu. |
| Włożenie karty podczas prowadzenia pojazdu | - ostatnie zdarzenie dla każdego z 10 ostatnich dni od zaistnienia zdarzenia. | - data i godzina zdarzenia, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja karty, - liczba podobnych zdarzeń w tym dniu. |
| Przekroczenie prędkości (1) | - najpoważniejsze zdarzenie dla każdego z 10 ostatnich dni od zaistnienia zdarzenia (tzn. zdarzenie o najwyższej, przeciętnej prędkości), - 5 najpoważniejszych zdarzeń w okresie ostatnich 365 dni, - pierwsze zdarzenie zaistniałe po ostatniej kalibracji. | - data i godzina rozpoczęcia zdarzenia, - data i godzina zakończenia zdarzenia, - maksymalna prędkość zmierzona w czasie zdarzenia, - średnia arytmetyczna prędkość zmierzona w czasie zdarzenia, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja karty kierowcy (o ile dotyczy), - liczba podobnych zdarzeń w tym dniu. |
5) KODY DANYCH DOTYCZĄCYCH USTEREK DOSTĘPNE BEZ ZGODY KIEROWCY
| Usterka | Zasady gromadzenia danych | Dane rejestrowane dla usterki |
| Usterka karty | - 10 ostatnich usterek karty kierowcy, | - data i godzina rozpoczęcia usterki, - data i godzina zakończenia usterki, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja karty. |
| Usterki urządzenia rejestrującego | - 10 ostatnich usterek dla każdego typu usterki, - pierwsza usterka po ostatniej kalibracji. | - data i godzina rozpoczęcia usterki, - data i godzina zakończenia usterki, - typ usterki, - typ karty, numer karty i państwo członkowskie, które wydało kartę, oraz generacja każdej karty włożonej na początku lub po zakończeniu usterki. |
Usterkę tę uruchamia dowolna z następujących usterek, z wyłączeniem pracy w trybie kalibracyjnym:
- usterka wewnętrzna VU
- usterka drukarki
- usterka wyświetlacza
- usterka pobierania danych
- usterka czujnika
- usterka odbiornika GNSS lub urządzenia zewnętrznego GNSS
- usterka urządzenia do łączności na odległość
6) ZDARZENIA I USTERKI DOTYCZĄCE KONKRETNEGO PRODUCENTA BEZ ZGODY KIEROWCY
| Zdarzenie lub usterka | Zasady gromadzenia danych | Dane rejestrowane dla zdarzenia |
| Określi producent | Określi producent | Określi producent |
Załącznik 2
DIAGRAMY SEKWENCJI WYMIANY KOMUNIKATÓW Z URZĄDZENIEM ITS.
DIAGRAMY SEKWENCJI WYMIANY KOMUNIKATÓW Z URZĄDZENIEM ITS.
Diagram sekwencji próby autoryzacji kodu PIN
Rys. 2
Diagram sekwencji weryfikacji autoryzacji urządzenia ITS
Rys. 3
Diagram sekwencji przetworzenia żądania przedstawienia danych zaklasyfikowanych jako nieosobowe (po poprawnym uzyskaniu dostępu za pomocą kodu PIN)
Rys. 4
Diagram sekwencji przetworzenia żądania przedstawienia danych zaklasyfikowanych jako osobowe (po poprawnym uzyskaniu dostępu za pomocą kodu PIN)
Rys. 5
Diagram sekwencji próby autoryzacji kodu PIN
Dodatek 14 36
FUNKCJA ŁĄCZNOŚCI NA ODLEGŁOŚĆ
FUNKCJA ŁĄCZNOŚCI NA ODLEGŁOŚĆ
1 WPROWADZENIE ...........................................................................................................
2 ZAKRES ............................................................................................................................
3 SKRÓTY, DEFINICJE I OZNACZENIA .........................................................................
4 SCENARIUSZE OPERACYJNE ......................................................................................
4.1 Informacje ogólne ...............................................................................................................
4.1.1 Warunki wstępne dotyczące przesyłania danych za pośrednictwem interfejsu DSRC działającego na częstotliwości 5,8 GHz ................................................................................
4.1.2 Profil 1a: kontrole przeprowadzane przy wykorzystaniu ręcznego czytnika wczesnego wykrywania na odległość lub czytnika wczesnego wykrywania na odległość zainstalowanego tymczasowo na poboczu .....................................................................................................
4.1.3 Profil 1b: Kontrole przeprowadzane przy wykorzystaniu ukierunkowanego czytnika wczesnego wykrywania na odległość (REDCR) zainstalowanego w pojeździe ......................
4.2 Bezpieczeństwo/Integralność ...............................................................................................
5 PROJEKT I PROTOKOŁY ŁĄCZNOŚCI NA ODLEGŁOŚĆ ........................................
5.1 Projekt ...............................................................................................................................
5.2 Przepływ pracy ...................................................................................................................
5.2.1 Operacje ............................................................................................................................
5.2.2 Interpretacja danych otrzymanych za pośrednictwem łączności DSRC ..................................
5.3 Parametry interfejsu fizycznego DSRC w odniesieniu do łączności na odległość ....................
5.3.1 Ograniczenia dotyczące lokalizacji .......................................................................................
5.3.2 Parametry łącza odbiorczego (downlink) i łącza nadawczego (uplink) .................................
5.3.3 Projekt anteny .....................................................................................................................
5.4 Wymogi protokołu DSRC w odniesieniu do zdalnego monitorowania tachografu ..................
5.4.1 Informacje ogólne ...............................................................................................................
5.4.2 Polecenia ............................................................................................................................
5.4.3 Sekwencja polecenia zapytania ............................................................................................
5.4.4 Struktury danych .................................................................................................................
5.4.5 Elementy danych dotyczących zdalnego monitorowania tachografu (RtmData), wykonywane czynności i definicje .............................................................................................................
5.4.6 Mechanizm przesyłania danych ............................................................................................
5.4.7 Szczegółowy opis transakcji DSRC .....................................................................................
5.4.8 Opis transakcji testowej DSRC ...........................................................................................
5.5 Zarezerwowane dla przyszłego użytku
5.5.1 Informacje ogólne ...............................................................................................................
5.5.2 Polecenia ............................................................................................................................
5.5.3 Sekwencja polecenia zapytania ............................................................................................
5.5.4 Struktury danych .................................................................................................................
5.5.5 (uchylony).
5.5.6 Elementy OwsData, wykonywane czynności i definicje .........................................................
5.5.7 Mechanizmy przesyłania danych ..........................................................................................
5.6 Przesyłanie danych pomiędzy DSRC-VU a VU ...................................................................
5.6.1 Połączenie fizyczne i interfejsy ..............................................................................................
5.6.2 Protokół aplikacji ................................................................................................................
5.7 Obsługa błędów ..................................................................................................................
5.7.1 Rejestrowanie i przekazywanie danych w DSRC-VU ..........................................................
5.7.2 Błędy łączności bezprzewodowej ........................................................................................
6 TESTY PRZEPROWADZANE PRZY ODDANIU DO EKSPLOATACJI ORAZ TESTY W RAMACH PRZEGLĄDÓW OKRESOWYCH FUNKCJI ŁĄCZNOŚCI NA ODLEGŁOŚĆ ...................................................................................................................
6.1 Uwagi ogólne ......................................................................................................................
6.2 ECHO ................................................................................................................................
6.3 Testy mające na celu zatwierdzanie treści zabezpieczonych danych .......................................
1 WPROWADZENIE
W niniejszym dodatku określono strukturę oraz procedury, które należy zastosować w celu wykonania funkcji łączności na odległość ("łączność") zgodnie z art. 9 rozporządzenia (UE) nr 165/2014 ("rozporządzenie").
DSC_1 Zgodnie z rozporządzeniem (UE) nr 165/2014 tachograf musi być wyposażony w funkcję łączności na odległość, aby zapewnić przedstawicielom właściwych organów kontrolnych możliwość odczytywania informacji przekazywanych przez tachograf zainstalowany w przejeżdżających pojazdach za pomocą urządzeń zdalnej kontroli ("czytnik wczesnego wykrywania na odległość" (REDCR)), a w szczególności w urządzenia kontroli łączące się bezprzewodowo za pośrednictwem interfejsów dedykowanej łączności krótkiego zasięgu (DSRC) pracujących na częstotliwości CEN 5,8 GHz.
Należy pamiętać, że opisana funkcja jest wykorzystywana wyłącznie w celu wstępnej selekcji pojazdów, które zostaną wybrane do bardziej szczegółowej kontroli; nie zastępuje ona formalnego przeglądu przeprowadzanego zgodnie z przepisami rozporządzenia (UE) nr 165/2014. Zobacz motyw 9 w preambule do tego rozporządzenia, w którym stwierdza się, że łączność na odległość między tachografem a organami kontrolnymi na potrzeby kontroli drogowych usprawnia ukierunkowane kontrole drogowe.
DSC_2 Dane wymienia się za pomocą Łączności, tj. bezprzewodowej wymiany informacji za pośrednictwem systemu łączności bezprzewodowej DSRC operującego na częstotliwości 5,8 GHz prowadzonej zgodnie z niniejszym dodatkiem, która jest sprawdzana pod kątem zgodności z odpowiednimi parametrami przewidzianymi w normie 300 674-1 {Kwestie dotyczące kompatybilności elektromagnetycznej i widma radiowego (ERM); telematyka transportu i ruchu drogowego (RTTT); dedykowana łączność krótkiego zasięgu (DSRC) utrzymywana za pośrednictwem urządzeń transmisyjnych (500 kbit/s / 250 kbit/s) działających na częstotliwości 5,8 GHz w paśmie przeznaczonym do zastosowań przemysłowych, naukowych i medycznych (ISM); Część 1: Charakterystyka ogólna przyrządów instalowanych na poboczu (RSU) oraz przyrządów instalowanych w pojeździe (OBU) i metody kontrolowania tych przyrządów}.
DSC_3 Łączność nawiązuje się za pośrednictwem urządzeń do łączności wyłącznie po otrzymaniu sygnału wyemitowanego przez urządzenia właściwego organu kontrolnego przy wykorzystaniu zgodnych środków łączności radiowej ("czytnik wczesnego wykrywania na odległość" (REDCR)).
DSC_4 Dane zabezpiecza się w celu zapewnienia ich integralności.
DSC_5 Dostęp do przesyłanych Danych jest ograniczony do właściwych organów kontrolnych upoważnionych do kontroli naruszeń rozporządzenia (WE) nr 561/2006 i rozporządzenia (UE) nr 165/2014 oraz do warsztatów w zakresie niezbędnym do sprawdzenia poprawnego funkcjonowania tachografu.
DSC_6 Dane przesyłane w trakcie utrzymywania Łączności ograniczają się do danych niezbędnych na potrzeby ukierunkowanych kontroli drogowych pojazdów wyposażonych w tachografy, które mogły zostać niewłaściwie użyte lub stać się przedmiotem manipulacji.
DSC_7 Integralność i bezpieczeństwo Danych zapewnia się, zabezpieczając Dane przechowywane w przyrządzie rejestrującym (VU) i przekazując wyłącznie zabezpieczone dane ładunku i dane dotyczące zabezpieczeń za pośrednictwem urządzeń bezprzewodowej łączności na odległość DSRC działających na częstotliwości 5,8 GHz (zob. pkt 5.4.4), co oznacza, że tylko upoważnieni pracownicy właściwych organów kontrolnych są w stanie zrozumieć dane przekazywane w trakcie utrzymywania Łączności i są w stanie zweryfikować ich autentyczność. Zob. Dodatek 11 - Wspólne mechanizmy zabezpieczenia.
DSC_8 Dane muszą zawierać znacznik czasu określający datę i godzinę ich ostatniej aktualizacji.
DSC_9 Treść danych zabezpieczających jest znana wyłącznie właściwym organom kontrolnym i tym stronom, którym organy udostępniają te informacje, oraz pozostaje pod ich kontrolą; treść takich danych wykracza poza zakres przepisów dotyczących Łączności będących przedmiotem niniejszego dodatku z wyjątkiem zakresu, w jakim Łączność zabezpiecza przesyłanie pakietu danych zabezpieczających z każdym pakietem danych ładunku.
DSC_10 Należy zapewnić możliwość wykorzystania tej samej architektury i tych samych urządzeń do uzyskania innych koncepcji danych (jak np. ważenie w pojeździe) z zastosowaniem architektury określonej w niniejszym dodatku.
DSC_11 W tym miejscu należy wyjaśnić, że zgodnie z przepisami rozporządzenia (UE) nr 165/2014 (art. 7) dane dotyczące tożsamości kierowcy nie mogą być przekazywane w ramach Łączności.
2 ZAKRES
Celem niniejszego dodatku jest określenie, w jaki sposób przedstawiciele właściwych organów kontrolnych mają korzystać z dedykowanego systemu łączności bezprzewodowej DSRC działającego w paśmie 5,8 GHz, aby zdalnie pozyskiwać z pojazdu docelowego dane ("Dane") wskazujące, że taki pojazd może potencjalnie naruszać przepisy rozporządzenia (UE) nr 165/2014 i że w związku z tym należy rozważyć możliwość jego zatrzymania do bardziej szczegółowej kontroli.
Zgodnie z wymogiem ustanowionym w rozporządzeniu (UE) nr 165/2014 gromadzone Dane muszą ograniczać się do danych lub dotyczyć danych potwierdzających, że mogło dojść do naruszenia praw, zgodnie z definicją przedstawioną w art. 9 rozporządzenia (UE) nr 165/2014.
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 niniejszym dodatku określa się:
- urządzenia do łączności oraz procedury i protokoły, które należy stosować do celów Łączności;
- normy i przepisy, z którymi urządzenia radiowe muszą być zgodne;
- sposób przekazywania Danych za pośrednictwem urządzeń do Łączności;
- procedury zapytywania i pobierania oraz sekwencję operacji;
- Dane, które mają być przekazywane;
- Możliwe interpretacje Danych przesyłanych w ramach Łączności;
- przepisy w zakresie danych zabezpieczających dotyczących Łączności;
- dostępność Danych dla właściwych organów kontrolnych;
- sposób, w jaki Czytnik wczesnego wykrywania na odległość może żądać przekazania różnych koncepcji danych dotyczących ładunku i floty.
W tym miejscu należy wyjaśnić, że w niniejszym dodatku nie określa się:
- operacji gromadzenia Danych i zarządzania tym procesem w ramach VU (co stanowi funkcję projektu produktu, chyba że zostało określone w innym miejscu w rozporządzeniu (UE) nr 165/2014);
- formy, w jakiej należy przedstawić zgromadzone dane przedstawicielowi właściwych organów kontrolnych ani kryteriów, z których właściwe organy kontrolne muszą korzystać przy podejmowaniu decyzji o ewentualnym zatrzymaniu pojazdu (co stanowi funkcję projektu produktu, chyba że zostało określone w innym miejscu w rozporządzeniu (UE) nr 165/2014 lub zależy od decyzji politycznej właściwych organów kontrolnych). W tym miejscu należy wyjaśnić, że za pośrednictwem Łączności udostępnia się Dane właściwym organom kontrolnym, wyłącznie aby zapewnić im możliwość podejmowania świadomych decyzji;
- Przepisów w zakresie bezpieczeństwa danych (takich jak przepisy w zakresie szyfrowania) dotyczących treści Danych (które zostaną określone w dodatku 11 - Wspólne mechanizmy zabezpieczenia);
- szczegółowych informacji dotyczących wszelkich koncepcji danych innych niż RTM, które można pozyskać z zastosowaniem tej samej architektury i tych samych urządzeń;
- szczegółowych informacji dotyczących zachowania i zarządzania pomiędzy VU i DSRC-VU ani dotyczących zachowania w ramach DSRC-VU (poza przekazywaniem Danych na żądanie REDCR).
3 SKRÓTY, DEFINICJE I OZNACZENIA
W niniejszym dodatku używa się następujących skrótów i definicji właściwych dla tego dodatku:
Antena urządzenie elektryczne przekształcające energię elektryczną w fale radiowe i vice versa, wykorzystywane w połączeniu z nadajnikiem radiowym lub odbiornikiem radiowym. W trakcie pracy nadajnik radiowy generuje drgania elektryczne o częstotliwości fal radiowych, które trafiają do gniazd antenowych, a antena emituje energię pozyskiwaną z prądu w formie fal elektromagnetycznych (fal radiowych). Przyjmując fale radiowe, antena przechwytuje część energii z fali elektromagnetycznej i wytwarza niewielkie napięcie w gniazdach antenowych, które jest następnie przesyłane do odbiornika w celu wzmocnienia;
Łączność wymiana informacji/danych między DSRC-REDCR a DSRC-VU zgodnie z przepisami sekcji 5 w trybie nadrzędny-podrzędny prowadzona w celu pozyskania Danych;
Dane zabezpieczone dane o określonym formacie (zob. pkt 5.4.4) żądane przez DSRC-REDCR i przekazane przez DSR-VU za pośrednictwem DSRC działającego na częstotliwości 5,8 GHz określonego w pkt 5 poniżej;
Rozporządzenie (WE) nr 165/2014 Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 165/2014 z dnia 4 lutego 2014 r. w sprawie tachografów stosowanych w transporcie drogowym i uchylające rozporządzenie Rady (EWG) nr 3821/85 w sprawie urządzeń rejestrujących stosowanych w transporcie drogowym oraz zmieniające rozporządzenie (WE) nr 561/2006 Parlamentu Europejskiego i Rady w sprawie harmonizacji niektórych przepisów socjalnych odnoszących się do transportu drogowego;
AID identyfikator aplikacji
BLE Bluetooth Low Energy (łączność Bluetooth przy znikomym poborze prądu)
BST tabela usług sygnału
CIWD włożenie karty podczas prowadzenia pojazdu
CRC cykliczna kontrola nadmiarowa
DSC (n) identyfikator wymogu związanego z określonym dodatkiem dotyczącym DSRC
DSRC dedykowana łączność krótkiego zasięgu
DSRC-REDCR DSRC-czytnik wczesnego wykrywania na odległość
DSRC-VU DSRC-przyrząd rejestrujący. Jest to "urządzenie wczesnego wykrywania na odległość" zdefiniowana w załączniku 1C
DWVC prowadzenie pojazdu bez ważnej karty
EID identyfikator elementu
LLC sterowanie połączeniem logicznym
LPDU jednostka danych protokołu LLC
OWS system ważenia zainstalowany w pojeździe
PDU jednostka danych protokołu
REDCR czytnik wczesnego wykrywania na odległość. Jest to "urządzenie służące jako czytnik wczesnego wykrywania na odległość" zdefiniowane w załączniku 1C
RTM zdalne monitorowanie tachografu
SM-REDCR moduł zabezpieczeń-czytnik wczesnego wykrywania na odległość
TARV aplikacje telematyczne dla pojazdów regulowanych (seria norm ISO 15638)
VU przyrząd rejestrujący
VUPM pamięć ładunku przyrządu rejestrującego
VUSM moduł zabezpieczeń przyrządu rejestrującego
VST tabela usług pojazdu
WIM ważenie w ruchu
WOB ważenie w pojeździe
Specyfikacje określone w niniejszym dodatku odnoszą się do wszystkich lub części wskazanych poniżej rozporządzeń i norm i są od nich zależne. W ramach zapisów niniejszego dodatku wskazano odnośne normy lub odnośne przepisy norm. W razie jakichkolwiek sprzeczności zapisy niniejszego dodatku są nadrzędne. W sytuacji wystąpienia jakichkolwiek sprzeczności, w przypadku których nie istnieją specyfikacje wyraźnie określone w niniejszym dodatku, należy w pierwszej kolejności zastosować procedury przewidziane w ERC 70-03 (i sprawdzić zgodność z odpowiednimi parametrami przewidzianymi w normie EN 300 674-1), a następnie procedury przewidziane kolejno w normach EN 12795, EN 12253, EN 12834 i EN 13372 pkt 6.2, 6.3, 6.4 oraz 7.1.
W niniejszym dodatku przywołano następujące rozporządzenia i normy:
[1] rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 165/2014 z dnia 4 lutego 2014 r. w sprawie tachografów stosowanych w transporcie drogowym i uchylające rozporządzenie Rady (EWG) nr 3821/85 w sprawie urządzeń rejestrujących stosowanych w transporcie drogowym oraz zmieniające rozporządzenie (WE) nr 561/2006 Parlamentu Europejskiego i Rady w sprawie harmonizacji niektórych przepisów socjalnych odnoszących się do transportu drogowego;
[2] rozporządzenie (WE) nr 561/2006 Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. w sprawie harmonizacji niektórych przepisów socjalnych odnoszących się do transportu drogowego oraz zmieniające rozporządzenia Rady (EWG) nr 3821/85 i (WE) nr 2135/98, jak również uchylające rozporządzenie Rady (EWG) nr 3820/85 (tekst mający znaczenie dla EOG);
[3] dokument ERC 70-03 CEPT "Zalecenie ECC 70-03 dotyczące korzystania z urządzeń bliskiego zasięgu (SRD)";
[4] normę ISO 15638 Inteligentne systemy transportowe - Ramy wspólnych aplikacji telematycznych dla regulowanych komercyjnych samochodów ciężarowych (TARV);
[5] normę EN 300 674-1 "Kwestie dotyczące kompatybilności elektromagnetycznej i widma radiowego (ERM); telematyka transportu i ruchu drogowego (RTTT); dedykowana łączność krótkiego zasięgu (DSRC) utrzymywana za pośrednictwem urządzeń transmisyjnych (500 kbit/s / 250 kbit/s) działających na częstotliwości 5,8 GHz w paśmie przeznaczonym do zastosowań przemysłowych, naukowych i medycznych (ISM); Część 1: Charakterystyka ogólna przyrządów instalowanych na poboczu (RSU) oraz przyrządów instalowanych w pojeździe (OBU) i metody kontrolowania tych przyrządów";
[6] normę EN 12253 "Telematyka transportu i ruchu drogowego - Wydzielona komunikacja krótkiego zasięgu - Warstwa fizyczna wykorzystująca częstotliwość 5,8 GHz";
[7] normę EN 12795 "Telematyka transportu i ruchu drogowego - Wydzielona komunikacja krótkiego zasięgu (DSRC) - Warstwa łącza danych DSRC: sterowanie dostępem nośnika i łączem logicznym";
[8] normę EN 12834 "Telematyka transportu i ruchu drogowego - Wydzielona komunikacja krótkiego zasięgu (DSRC) - Warstwa aplikacyjna DSRC";
[9] normę EN 13372 "Telematyka transportu i ruchu drogowego (RTTT) - Wydzielona komunikacja krótkiego zasięgu - Profile zastosowań RTTT";
[10] normę ISO 14906 "Elektroniczny system pobierania opłat - Określenie interfejsu zastosowań dla wydzielonej komunikacji krótkiego zasięgu".
4 SCENARIUSZE OPERACYJNE
4.1 Informacje ogólne
W rozporządzeniu (UE) nr 165/2014 wskazano konkretne i kontrolowane scenariusze określające sposób stosowania Łączności.
Do scenariuszy objętych wsparciem należą:
"Profil łączności 1: Kontrole drogowe przeprowadzane przy wykorzystaniu czytnika wczesnego wykrywania na odległość opartego na technologii łączności bezprzewodowej krótkiego zasięgu dające podstawy do wszczęcia fizycznej kontroli drogowej (relacja nadrzędny-podrzędny)
Profil czytnika 1a: Kontrole przeprowadzane przy wykorzystaniu ręcznego urządzenia wczesnego wykrywania na odległość lub urządzenia wczesnego wykrywania na odległość zainstalowanego tymczasowo na poboczu
Profil czytnika 1b: Kontrole przeprowadzane przy wykorzystaniu ukierunkowanego czytnika wczesnego wykrywania na odległość zainstalowanego w pojeździe".
4.1.1 Warunki wstępne dotyczące przesyłania danych za pośrednictwem interfejsu DSRC działającego na częstotliwości 5,8 GHz
UWAGA: w celu zrozumienia kontekstu warunków wstępnych warto zapoznać się z rys. 14.3 poniżej.
4.1.1.1 Dane przechowywane w VU
DSC_12 Przyrząd rejestrujący odpowiada za aktualizowanie co 60 sekund danych, które mają być przechowywane w VU, bez żadnego udziału funkcji łączności DSRC oraz za utrzymywanie tych danych. Środki umożliwiające osiągnięcie tego celu znajdują się wewnątrz VU i są określone w sekcji 3.19 "Łączność na odległość na potrzeby ukierunkowanych kontroli drogowych" załącznika 1C do rozporządzenia (UE) nr 165/2014, a nie w niniejszym dodatku.
4.1.1.2 Dane przesyłane do funkcji DSRC-VU
DSC_13 Przyrząd rejestrujący odpowiada za aktualizowanie danych gromadzonych przez tachograf DSRC (Dane) za każdym razem, gdy następuje aktualizacja danych przechowywanych w VU w odstępach czasu określonych w pkt 4.1.1.1 (DSC_12), bez żadnego udziału funkcji łączności DSRC.
DSC_14 Dane VU stosuje się jako podstawę do wypełniania i aktualizowania Danych, przy czym środki umożliwiające osiągnięcie tego celu określono w sekcji 3.19 "Łączność na odległość na potrzeby ukierunkowanych kontroli drogowych" załącznika 1C lub w przypadku braku takiego wyszczególnienia stanowią funkcję projektu produktu i nie są określone w niniejszym dodatku. Informacje na temat struktury połączenia między funkcją DSRC-VU a VU można znaleźć w sekcji 5.6.
4.1.1.3 Zawartość Danych
DSC_15 Treść i format Danych powinny pozwalać na to, aby po ich odszyfrowaniu zachowały one odpowiednią strukturę i pozostały dostępne w formie i formacie określonych w pkt 5.4.4 niniejszego dodatku (struktury Danych).
4.1.1.4 Przedstawienie Danych
DSC_16 Dane, który były regularnie aktualizowane zgodnie z procedurami przewidzianymi w pkt 4.1.1.1, zabezpiecza się przed ich przedstawieniem DSRC-VU, a następnie przedstawia jako wartość koncepcji danych zabezpieczonych w celu ich tymczasowego przechowania w DSRC-VU jako aktualną wersję Danych. Dane te przekazuje się z VUSM do funkcji DSRC VUPM. VUSM i VUPM to funkcje, które niekoniecznie muszą mieć postać fizyczną. Forma fizycznej konkretyzacji służącej wykonywaniu tych funkcji jest kwestią projektu produktu, chyba że została określona w innym miejscu w rozporządzeniu (UE) nr 165/2014.
4.1.1.5 Dane zabezpieczające
DSC_17 Dane zabezpieczające (DSRCSecurityData), obejmujące żądane przez REDCR dane niezbędne do zapewnienia mu możliwości odszyfrowania Danych przekazuje się zgodnie z przepisami dodatku 11 "Wspólne mechanizmy zabezpieczenia", w celu ich tymczasowego przechowania w DSRC-VU jako aktualną wersję DSRCSecurityData, w formie określonej w sekcji 5.4.4 niniejszego dodatku.
4.1.1.6 Dane VUPM dostępne do przekazywania za pośrednictwem interfejsu DSRC
DSC_18 Koncepcja danych, która musi być zawsze dostępna w ramach funkcji DSRC VUPM do celów natychmiastowego przekazania na żądanie REDCR, została zdefiniowana w sekcji 5.4.4 w odniesieniu do pełnej specyfikacji modułu ASN.1.
Informacje ogólne na temat profilu łączności 1
Profil ten obejmuje przypadek wykorzystania, w którym przedstawiciel właściwego organu kontrolnego używa czytnika wczesnego wykrywania na odległość (bazującego na interfejsach DSRC działających na częstotliwości 5,8 GHz w ramach ERC 70-03 i sprawdzonego pod kątem zgodności z odpowiednimi parametrami przewidzianymi w normie EN 300 674-1, jak opisano w sekcji 5) (REDCR) w celu zdalnego zidentyfikowania pojazdu, który może potencjalnie naruszać przepisy rozporządzenia (UE) nr 165/2014. Po zidentyfikowaniu pojazdu przedstawiciel właściwego organu kontrolnego przeprowadzający kontrolę podejmuje o ewentualnym zatrzymaniu pojazdu.
4.1.2 Profil 1a: Kontrole przeprowadzane przy wykorzystaniu ręcznego czytnika wczesnego wykrywania na odległość lub czytnika wczesnego wykrywania na odległość zainstalowanego tymczasowo na poboczu
W ramach tego przypadku wykorzystania przedstawiciel właściwego organu kontrolnego znajduje się na poboczu i nakierowuje ręczny REDCR, REDCR ustawiony na statywie trójnożnym lub innego rodzaju przenośny REDCR w kierunku środka szyby przedniej wybranego pojazdu. Kontrolę przeprowadza się przy wykorzystaniu interfejsów DSRC działających na częstotliwości 5,8 GHz w ramach ERC 70-03 i sprawdza pod kątem zgodności z odpowiednimi parametrami przewidzianymi w normie EN 300 674-1, jak opisano w sekcji 5. Zob. rys. 14.1 (przypadek wykorzystania 1).
Rysunek 14.1
Kontrola drogowa przeprowadzana przy wykorzystaniu interfejsów DSRC działających na częstotliwości 5,8 GHz
4.1.3 Profil 1b: Kontrole przeprowadzane przy wykorzystaniu ukierunkowanego czytnika wczesnego wykrywania na odległość (REDCR) zainstalowanego w pojeździe
W przedmiotowym przypadku wykorzystania przedstawiciel właściwego organu kontrolnego znajduje się w pojeździe będącym w ruchu i nakierowuje ręczny, przenośny REDCR znajdujący się wewnątrz pojazdu w kierunku środka szyby przedniej wybranego pojazdu albo REDCR jest zainstalowany w pojeździe lub na nim w taki sposób, by był skierowany w kierunku środka szyby przedniej wybranego pojazdu w momencie, gdy pojazd, w którym znajduje się czytnik wczesnego wykrywania na odległość, znajduje się w określonym położeniu względem wybranego pojazdu (na przykład bezpośrednio przed tym pojazdem w strumieniu ruchu). Kontrolę przeprowadza się przy wykorzystaniu interfejsów DSRC działających na częstotliwości 5,8 GHz w ramach ERC 70-03 i sprawdza pod kątem zgodności z odpowiednimi parametrami przewidzianymi w normie EN 300 674-1, jak opisano w sekcji 5. Zob. rys. 14.2. (przypadek wykorzystania 2).
Rysunek 14.2
Kontrola przeprowadzana z pojazdu korzystającego z interfejsów DSRC działających na częstotliwości 5,8 GHz
4.2 Bezpieczeństwo/integralność
Aby umożliwić weryfikację autentyczności i integralności danych pobranych w ramach łączności na odległość, zabezpieczone Dane są weryfikowane i deszyfrowane zgodnie z dodatkiem 11 Wspólne mechanizmy zabezpieczenia.
5 PROJEKT I PROTOKOŁY ŁĄCZNOŚCI NA ODLEGŁOŚĆ
5.1 Projekt
Projekt funkcji łączności na odległość w tachografie inteligentnym przedstawiono na rys. 14.3.
Rys. 14.3
Projekt funkcji łączności na odległość
DSC_19 W VU zlokalizowane są następujące funkcje:
- moduł zabezpieczeń (VUSM). Ta funkcja występująca w VU jest odpowiedzialna za zabezpieczanie Danych przesyłanych z DSRC-VU do przedstawiciela właściwych organów kontrolnych za pośrednictwem łączności na odległość;
- zabezpieczone dane są przechowywane w pamięci VUSM. W odstępach czasu określonych w pkt 4.1.1.1 (DSC_12) VU szyfruje i uzupełnia koncepcję RTMdata (która obejmuje wartości koncepcji danych ładunku i danych zabezpieczających określone poniżej w tym dodatku) przechowywaną w pamięci DSRC-VU. Działanie modułu zabezpieczeń jest zdefiniowane w dodatku 11 "Wspólne mechanizmy zabezpieczenia" i wykracza poza zakres niniejszego dodatku, z zastrzeżeniem konieczności zapewnienia aktualizacji urządzenia do łączności VU za każdym razem, gdy zmieniają się dane VUSM;
- łączność między VU a DSRC-VU może być łącznością przewodową lub łącznością opartą na technologii Bluetooth Low Energy (BLE), a jeżeli chodzi o fizyczną lokalizację DSRC-VU, może być ono zintegrowane z anteną umieszczoną na szybie przedniej pojazdu, może znajdować się wewnątrz VU lub może być umieszczone gdzieś pomiędzy;
- DSRC-VU posiada niezawodne źródło energii dostępne w każdej chwili. Sposób zasilania energią zależy od projektu;
- pamięć DSRC-VU jest pamięcią trwałą w celu utrzymania danych w DSRC-VU, nawet gdy zapłon pojazdu jest wyłączony;
- jeżeli łączność między VU a DSRC-VU odbywa się za pośrednictwem technologii BLE, a źródłem zasilania jest akumulator, którego nie można ponownie naładować, źródło zasilania DSRC-VU zastępuje się podczas każdego przeglądu okresowego, a producent urządzenia DSRC-VU jest odpowiedzialny za zapewnienie odpowiedniego zasilania energią między jednym przeglądem okresowym a drugim, utrzymując normalny dostęp do danych przez REDCR przez cały okres bez awarii lub przerwania dostaw;
- funkcja VU umożliwiająca zdalne monitorowanie tachografu i wyposażona w "pamięć na temat ładunków" (VUPM). Ta funkcja występująca w VU jest odpowiedzialna za dostarczanie i aktualizację Danych. Treść Danych ("TachographPayload") jest zdefiniowana w pkt 5.4.4/5.4.5 poniżej i jest aktualizowana w odstępach czasu określonych w pkt 4.1.1.1 (DSC_12);
- DSRC-VU. Jest to funkcja w obrębie anteny lub połączona z anteną i nawiązująca łączność z VU za pośrednictwem połączenia przewodowego lub bezprzewodowego (BLE), które posiada aktualne dane (dane VUPM) i zarządza odpowiedziami na kontrolę prowadzoną przez nośnik DSRC działający na częstotliwości 5,8 GHz. Odłączenie urządzenia DSRC lub zakłócenie jego funkcjonowania podczas normalnej eksploatacji pojazdu z działającym urządzeniem DSRC interpretuje się jako naruszenie przepisów rozporządzenia (UE) nr 165/2014;
- moduł zabezpieczeń (REDCR) (SM-REDCR) to funkcja wykorzystywana do deszyfrowania i sprawdzania integralności danych pochodzących z VU. Środki umożliwiające osiągnięcie tego celu określono w dodatku 11 Wspólne mechanizmy zabezpieczenia, a nie w niniejszym dodatku;
- urządzenie DSRC (REDCR) (DSRC-REDCR) obejmuje nadajnik-odbiornik działający na częstotliwości 5,8 GHz i powiązane oprogramowanie wbudowane i oprogramowanie zwykłe, które zarządza Łącznością z DSRC-VU zgodnie z niniejszym dodatkiem;
- DSRC-REDCR wysyła zapytania do DSRC-VU w docelowym pojeździe i pozyskuje Dane (bieżące dane VUPM docelowego pojazdu) za pośrednictwem łącza DSRC oraz przetwarza i przechowuje otrzymane dane w swoim SM-REDCR;
- 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.
- Przed anteną lub w pobliżu anteny nie mogą znajdować się żadne metalowe przedmioty (np. identyfikatory, naklejki, antyodblaskowe (barwione) paski z folii, osłony przeciwsłoneczne, wycieraczki szyby przedniej w stanie spoczynku), które mogą zakłócać łączność.
- Antena musi być zamontowana tak, aby jej obszar pokrycia był mniej więcej równoległy do powierzchni drogi.
DSC_20 Antena i Łączność działają w ramach ERC 70-03, są sprawdzane pod kątem zgodności z odpowiednimi parametrami przewidzianymi w normie EN 300 674-1, jak opisano w sekcji 5. W odniesieniu do anteny i Łączności można wdrożyć techniki ograniczania ryzyka wystąpienia zakłóceń bezprzewodowych, jak opisano w sprawozdaniu ECC nr 228, przy użyciu np. filtrów w łączności CEN DSRC 5.8 GHz.
DSC_21 Antena DSRC jest połączona z funkcją DSRC-VU bezpośrednio w obrębie modułu zamontowanego na szybie przedniej lub blisko szyby przedniej lub poprzez dedykowany przewód zbudowany w taki sposób, aby utrudnić nielegalne odłączenie. Odłączenie lub zakłócenie funkcjonowania anteny stanowi naruszenie przepisów rozporządzenia (UE) nr 165/2014. Zamierzone maskowanie lub inne szkodliwe oddziaływanie na funkcjonowanie anteny interpretuje się jako naruszenie przepisów rozporządzenia (UE) nr 165/2014.
DSC_22 Współczynnik kształtu anteny nie został zdefiniowany i stanowi przedmiot decyzji handlowej, dopóki wbudowany DSRC-VU spełnia wymagania zgodności określone w sekcji 5 poniżej. Antena jest umieszczona w miejscu określonym w DSC_19 i skutecznie wspomaga przypadki wykorzystania opisane w pkt 4.1.2 i 4.1.3.
Rys. 14.4
Przykładowe umieszczenie anteny DSRC działającej na częstotliwości 5,8 GHz na szybie przedniej pojazdów regulowanych
Współczynnik kształtu REDCR i jego anteny może różnić się w zależności od położenia czytnika (zamontowany statyw, urządzenie ręczne, zamontowany w pojeździe itd.) i trybu działania przyjętego przez przedstawiciela właściwych organów kontrolnych.
Funkcję wyświetlania lub powiadamiania wykorzystuje się do przedstawienia przedstawicielowi właściwych organów kontrolnych wyników funkcji łączności na odległość. Wyniki mogą być wyświetlane na ekranie, w formie wydruku, sygnału audio lub połączenia takich powiadomień. Forma takiego wyświetlenia lub powiadomienia jest kwestią wymogów przedstawicieli właściwych organów kontrolnych i projektu urządzenia i nie jest określona w niniejszym dodatku.
DSC_23 Współczynnik projektu i kształtu REDCR stanowi funkcję projektu komercyjnego, funkcjonującego w ramach ERC 70-03, oraz specyfikacji projektu i eksploatacji określonej w niniejszym dodatku (sekcja 5.3.2), tym samym zapewniając maksymalną elastyczność rynku w zakresie zaprojektowania i zapewnienia urządzenia mającego na celu zrealizowanie określonych scenariuszy kontroli dowolnego właściwego organu kontrolnego.
DSC_24 Współczynnik projektu i kształtu DSRC-VU i jego pozycjonowanie wewnątrz lub na zewnątrz VU stanowią funkcję projektu komercyjnego, funkcjonującego w ramach ERC 70-03, oraz specyfikacji projektu i eksploatacji określonej w niniejszym dodatku (sekcja 5.3.2) i w obrębie tej klauzuli (5.1).
DSC_25 W rozsądnym stopniu DSRC-VU musi być jednak w stanie zaakceptować wartości koncepcji danych z innego inteligentnego urządzenia rejestrującego za pomocą otwartego standardowego połączenia branżowego i protokołów (na przykład z urządzenia służącego do ważenia w pojeździe), dopóki takie koncepcje danych są określone unikatowymi i znanymi identyfikatorami aplikacji / nazwami plików, zaś instrukcje obsługi takich protokołów są udostępniane Komisji Europejskiej i są dostępne bezpłatnie dla producentów odpowiednich urządzeń.
5.2 Przepływ pracy
5.2.1 Operacje
Na rys. 14.5 przedstawiono przepływ pracy w odniesieniu do operacji.
Rys. 14.5
Przepływ pracy w odniesieniu do funkcji łączności na odległość
Poszczególne kroki opisano poniżej:
a. ilekroć pojazd jest w ruchu (włączony zapłon), tachograf przekazuje dane funkcji VU. Funkcja VU przygotowuje Dane na potrzeby funkcji łączności na odległość (zaszyfrowane) i aktualizuje VUPM przechowywane w pamięci DSRC-VU (jak określono w pkt 4.1.1.1-4.1.1.2). Zebrane Dane formatuje się w sposób określony w pkt 5.4.4-5.4.5 poniżej;
b. przy każdej aktualizacji Danych aktualizuje się znacznik czasu określony w koncepcji danych zabezpieczających;
c. funkcja VUSM zabezpiecza dane zgodnie z procedurami określonymi w dodatku 11;
d. przy każdej aktualizacji Danych (zob. pkt 4.1.1.1-4.1.1.2) Dane przesyła się do DSRC-VU, gdzie zastępują one wszystkie poprzednie dane, aby w razie kontroli prowadzonej przez REDCR zawsze były dostępne zaktualizowane bieżące dane (Dane). W przypadku dostarczania Danych DSRC-VU przez VU Dane są identyfikowane po nazwie pliku RTMData lub ApplicationID i identyfikatorach atrybutu;
e. jeżeli przedstawiciel właściwych organów kontrolnych chce zgromadzić Dane z wybranego pojazdu docelowego, najpierw umieszcza swoją kartę elektroniczną w REDCR w celu umożliwienia Łączności i pozwolenia SM-REDCR na weryfikację autentyczności karty i deszyfrowanie danych;
f. przedstawiciel właściwego organu kontrolnego wybiera następnie pojazd i żąda przekazania danych za pośrednictwem łączności na odległość. REDCR otwiera sesję interfejsu DSRC działającego na częstotliwości 5,8 GHz z DSRC-VU pojazdu docelowego i żąda przekazania Danych. Dane są przesyłane do REDCR za pośrednictwem systemu łączności bezprzewodowej jako atrybut DSRC korzystający z usługi aplikacyjnej GET, jak określono w 5.4. Atrybut zawiera zaszyfrowane wartości danych ładunku oraz dane zabezpieczające DSCR;
g. dane są analizowane przez urządzenie REDCR i przekazywane przedstawicielowi właściwego organu kontrolnego;
h. przedstawiciel właściwego organu kontrolnego wykorzystuje dane do podjęcia decyzji o ewentualnym zatrzymaniu pojazdu do szczegółowej kontroli lub zwrócenia się do innego przedstawiciela właściwego organu kontrolnego o zatrzymanie pojazdu.
5.2.2 Interpretacja danych otrzymanych za pośrednictwem łączności DSRC
DSC_26 Dane otrzymywane przez interfejs działający na częstotliwości 5,8 GHz niosą tylko i wyłącznie znaczenie i import zdefiniowane w pkt 5.4.4 i 5.4.5 poniżej i są rozumiane zgodnie z celami określonymi w tych punktach. Zgodnie z przepisami rozporządzenia (UE) nr 165/2014 Dane wykorzystuje się jedynie w celu przekazania odpowiednich informacji właściwemu organowi kontrolnemu, aby pomóc mu w ustaleniu, czy należy zatrzymać pojazd do kontroli fizycznej, a następnie Dane te są niszczone zgodnie z art. 9 rozporządzenia (UE) nr 165/2014.
5.3 Parametry interfejsu fizycznego DSRC w odniesieniu do łączności na odległość
5.3.1 Ograniczenia dotyczące lokalizacji
DSC_27 Zdalnej kontroli pojazdów korzystających z interfejsu DSRC działającego na częstotliwości 5,8 GHz nie należy prowadzić w odległości do 200 metrów od uruchomionej suwnicy bramowej DSRC działającej na częstotliwości 5,8 GHz.
5.3.2 Parametry łącza odbiorczego (downlink) i łącza nadawczego (uplink)
DSC_28 Urządzenia wykorzystywane do zdalnego monitorowania tachografu muszą być zgodne z ERC70-03 i parametrami określonymi w tabelach 14.1 i 14.2 poniżej oraz muszą działać w ramach ERC70-03 i tych parametrów.
DSC_29 Ponadto aby zapewnić zgodność z parametrami operacyjnymi innych standardowych systemów DSRC działających na częstotliwości 5,8 GHz, urządzenie wykorzystywane do zdalnego monitorowania tachografu musi być zgodne z parametrami określonymi w normach EN 12253 i EN 13372.
Mianowicie:
Tabela 14.1
Parametry łącza odbiorczego
| Nr pozycji | Parametr | Wartości | Uwagi |
| D1 | Częstotliwości nośne łącza odbiorczego | Istnieją cztery alternatywne częstotliwości, których może używać REDCR: 5,7975 GHz 5,8025 GHz 5,8075 GHz 5,8125 GHz | W ramach ERC 70-03. Częstotliwości nośne mogą zostać wybrane przez podmiot wdrażający system przydrożny i nie muszą być znane w DSRC-VU. (zgodnie z normami EN 12253 i EN 13372) |
| D1a (*) | Tolerancja częstotliwości nośnych | w ramach ± 5 ppm | (zgodnie z normą EN 12253) |
| D2 (*) | Maska zakresu nadajnika RSU (REDCR) | W ramach ERC 70-03. REDCR jest zgodny z klasą B,C, jak określono w normie 12253. Brak innych szczególnych wymogów określonych w tym załączniku | Parametr stosowany do kontrolowania zakłóceń pomiędzy interrogatorami znajdującymi się blisko siebie (jak określono w normach EN 12253 i EN 13372). |
| D3 | OBU(DSRC-VU) Minimalny zakres częstotliwości | 5,795-5,815 GHz | (zgodnie z normą EN 12253) |
| D4 (*) | Maksymalna EIRP | W ramach ERC 70-03 (nielicencjono-wanego) i rozporządzenia krajowego Maksymalna wartość + 33 dBm | (zgodnie z normą EN 12253) |
| D4a | Maska kątowa EIRP | Zgodnie z zadeklarowaną i opublikowaną specyfikacją projektanta interro-gatora | (zgodnie z normą EN 12253) |
| D5 | Polaryzacja | Lewostronna kołowa | (zgodnie z normą EN 12253) |
| D5a | Polaryzacja krzyżowa | XPD: Na obszarze pokrycia: (REDCR) RSU t ≥ 15 dB (DSRC-VU) OBU r ≥ 10 dB Na obszarze -3 dB: (REDCR) RSU t ≥ 10 dB (DSRC-VU) OBU r ≥ 6 dB | (zgodnie z normą EN 12253) |
| D6 (*) | Modulacja | Dwupoziomowa modulacja amplitudy | (zgodnie z normą EN 12253) |
| D6a (*) | Indeks modulacji | 0,5 ... 0,9 | (zgodnie z normą EN 12253) |
| D6b | Wzorzec ruchu gałek ocznych | ≥ 90 % (czas) / ≥ 85 % (amplituda) | |
| D7 (*) | Kodowanie danych | FM0 Bit "1" posiada przejścia jedynie na początku i końcu interwału bitowego. Bit "0" posiada dodatkowe przejście w środku interwału bitowego w porównaniu z bitem "1". | (zgodnie z normą EN 12253) |
| D8 (*) | Szybkość transmisji bitów | 500 kBit/s | (zgodnie z normą EN 12253) |
| D8a | Tolerancja zegara częstotliwości | wyższa niż ± 100 ppm | (zgodnie z normą EN 12253) |
| D9 (*) | Bitowa stopa błędów (BER) w odniesieniu do łączności | ≤ 10 - 6, gdy moc padająca w przyrządzie instalowanym w pojeździe (DSRC-VU) mieści się w zakresie podanym w pkt [D11a-D11b]. | (zgodnie z normą EN 12253) |
| D10 | Czynnik uruchamiający OBU (DSRC-VU) | OBU (DSRC-VU) uruchamia się po otrzymaniu dowolnej ramki zawierającej co najmniej 11 oktetów (w tym preambułę) | Nie jest konieczny żaden specjalny wzór uruchamiania. DSRC-VU może uruchomić się po otrzymaniu ramki zawierającej mniej niż 11 oktetów (zgodnie z normą EN 12253) |
| D10a | Maksymalna godzina rozpoczęcia | ≤ 5 ms | (zgodnie z normą EN 12253) |
| D11 | Strefa łączności | Region przestrzenny, w którym osiąga się BER zgodną z D9a | (zgodnie z normą EN 12253) |
| D11a (*) | Limit zasilania w odniesieniu do łączności (górna) | - 24 dBm | (zgodnie z normą EN 12253) |
| D11b (*) | Limit zasilania w odniesieniu do łączności (dolna) | Moc zdarzenia: - 43 dBm (obszar pokrycia) - 41 dBm (w przedziale - 45° ± 45° odpowiadającym płaszczyźnie równoległej do powierzchni drogi, gdy DSRC-VU jest później instalowany w pojeździe (azymut)) | (zgodnie z normą EN 12253) Rozszerzony wymóg w odniesieniu do kątów poziomych do ±45°, ze względu na przypadki wykorzystania zdefiniowane w niniejszym załączniku. |
| D12 (*) | Poziom odcięcia zasilania (DSRC-VU) | - 60 dBm | (zgodnie z normą EN 12253) |
| D13 | Preambuła | Preambuła jest obowiązkowa. | (zgodnie z normą EN 12253) |
| D13a | Długość i wzór preambuły | 16 bitów ± 1 bit FM0 zakodowany jako bity "1" | (zgodnie z normą EN 12253) |
| D13b | Kształt fali preambuły | Sekwencja naprzemienna o niskim i wysokim poziomie z czasem trwania impulsu równym 2 µs. Tolerancja podana w D8a | (zgodnie z normą EN 12253) |
| D13c | Bity pomocnicze | RSU (REDCR) może przesłać maksymalnie 8 bitów po fladze końcowej. Od OBU (DSRC-VU) nie wymaga się, aby uwzględniał te dodatkowe bity. | (zgodnie z normą EN 12253) |
| (*) - Parametry łącza odbiorczego z zastrzeżeniem sprawdzenia pod kątem zgodności z odpowiednim testem parametrów przewidzianym w normie EN 300 674-1. |
Tabela 14.2
Parametry łącza nadawczego
| Nr pozycji | Parametr | Wartości | Uwagi |
| U1 (*) | Częstotliwości podnośne | OBU (DSRC-VU) obsługuje częstotliwości 1,5 MHz i 2,0 MHz RSU (REDCR) obsługuje częstotliwość 1,5 MHz lub 2,0 MHz lub obie. U1-0: 1,5 MHz U1-1: 2,0 MHz | Wybór częstotliwości podnośnej (1,5 MHz lub 2,0 MHz) zależy od wybranego profilu określonego w normie EN 13372. |
| U1a (*) | Tolerancja częstotliwości podnośnych | w ramach ± 0,1 % | (zgodnie z normą EN 12253) |
| U1b | Wykorzystanie wstęg bocznych | Takie same dane po obu stronach | (zgodnie z normą EN 12253) |
| U2 (*) | Maska zakresu nadajnika OBU (DSRC-VU) | Zgodnie z EN 12253 1) Moc poza pasmem zob. ETSI EN 300674-1 2) Moc na paśmie: [U4a] dBm w 500 kHz 3) Emisja na dowolnym innym kanale łącza nadawczego: U2(3)-1 = -35 dBm w 500 kHz | (zgodnie z normą EN 12253) |
| U4a (*) | Maksymalna modulacja jednowstęgowa EIRP (obszar pokrycia) | Dwie opcje: U4a-0: - 14 dBm U4a-1: - 21 dBm | Zgodnie z zadeklarowaną i opublikowaną specyfikacją projektanta urządzenia |
| U4b (*) | Maksymalna modulacja jednowstęgowa EIRP (35°) | Dwie opcje: - Nie dotyczy - - 17 dBm | Zgodnie z zadeklarowaną i opublikowaną specyfikacją projektanta urządzenia |
| U5 | Polaryzacja | Lewostronna kołowa | (zgodnie z normą EN 12253) |
| U5a | Polaryzacja krzyżowa | XPD: Na obszarze pokrycia: (REDCR) RSU r ≥ 15 dB (DSRC-VU) OBU t ≥ 10 dB Na obszarze - 3 dB: (REDCR) RSU r ≥ 10 dB (DSRC-VU) OBU t ≥ 6 dB | (zgodnie z normą EN 12253) |
| U6 | Modulacja podnośna | 2-PSK Zakodowane dane zsynchronizowane z częstotliwością podnośną: przejścia zakodowanych danych zbieżne z przejściami częstotliwości podnośnej. | (zgodnie z normą EN 12253) |
| U6b | Cykl roboczy | Cykl roboczy: 50 % ± α, α ≤ 5 % | (zgodnie z normą EN 12253) |
| U6c | Modulacja na nośniku | Mnożenie modulowanej częstotliwości podnośnej przez częstotliwość nośną. | (zgodnie z normą EN 12253) |
| U7 (*) | Kodowanie danych | NRZI (Brak przejścia na początku bitu "1", przejście na początku bitu "0", brak przejścia w ramach bitu) | (zgodnie z normą EN 12253) |
| U8 (*) | Szybkość transmisji bitów | 250 kBit/s | (zgodnie z normą EN 12253) |
| U8a | Tolerancja zegara częstotliwości | w ramach ± 1 000 ppm | (zgodnie z normą EN 12253) |
| U9 | Bitowa stopa błędów (B. E.R.) w odniesieniu do łączności | ≤ 10- 6 | (zgodnie z normą EN 12253) |
| U11 | Strefa łączności | Region przestrzenny, w którym zlokalizowany jest DSRC-VU, tak że jego transmisje są odbierane przez REDCR przy BER mniejszej niż ta podana w pkt U9a. | (zgodnie z normą EN 12253) |
| U12a (*) | Zysk z konwersji (dolna granica) | 1 dB dla każdej wstęgi bocznej Zakres kątowy: kołowo-symetryczny pomiędzy obszarem pokrycia a ± 35° oraz | |
| w przedziale - 45° ± 45° odpowiadającym płaszczyźnie równoległej do powierzchni drogi, gdy DSRC-VU jest później instalowany w pojeździe (azymut) | Większy niż określony zakres wartości dla kątów poziomych do ± 45° ze względu na przypadki wykorzystania zdefiniowane w niniejszym załączniku. | ||
| U12b (*) | Zysk z konwersji (górna granica) | 10 dB dla każdej wstęgi bocznej | Niższy niż określony zakres wartości dla każdej wstęgi bocznej w obrębie stożka kołowego wokół obszaru pokrycia ± 45° kąta otwarcia. |
| U13 | Preambuła | Preambuła jest obowiązkowa. | (zgodnie z normą EN 12253) |
| U13a | Długość i wzór preambuły | 32-36 µs modulowane jedynie przy użyciu częstotliwości podnośnej, a następnie 8 bitów "0" zakodowanych jako NRZI. | (zgodnie z normą EN 12253) |
| U13b | Bity pomocnicze | DSRC-VU może przesłać maksymalnie 8 bitów po fladze końcowej. Od RSU (REDCR) nie wymaga się, aby uwzględniał te dodatkowe bity. | (zgodnie z normą EN 12253) |
| (*) - Parametry łącza nadawczego z zastrzeżeniem sprawdzenia zgodności z odpowiednim testem parametrów przewidzianym w normie EN 300 674-1. |
5.3.3 Projekt anteny
5.3.3.1 Antena REDCR
DSC_30 Projekt anteny REDCR stanowi funkcję projektu komercyjnego, funkcjonującego w granicach określonych w pkt 5.3.2, który dostosowano, aby zoptymalizować wydajność odczytu DSRC-REDCR w określonym celu oraz aby odczytać okoliczności, w których w założeniu REDCR ma funkcjonować.
5.3.3.2 Antena VU
DSC_31 Projekt anteny DSRC-VU stanowi funkcję projektu komercyjnego, funkcjonującego w granicach określonych w pkt 5.3.2, które dostosowano, aby zoptymalizować wydajność odczytu DSRC-REDCR w określonym celu oraz aby odczytać okoliczności, w których w założeniu REDCR ma funkcjonować.
DSC_32 Antena VU jest zamontowana na szybie przedniej pojazdu lub blisko szyby przedniej, jak określono w pkt 5.1 powyżej.
DSC_33 W środowisku testowym w warsztacie (zob. sekcja 6.3) antena DSRC-VU, umieszczona zgodnie z pkt 5.1 powyżej, powinna skutecznie połączyć się za pomocą standardowej łączności testowej i skutecznie zapewnić transakcję RTM, jak określono w tym dodatku, na odległość od 2 do 10 m, z wynikiem lepszym niż 99 % przypadków, uśrednionym do 1 000 kontroli odczytów.
5.4 Wymogi protokołu DSRC w odniesieniu do zdalnego monitorowania tachografu
5.4.1 Informacje ogólne
DSC_34 Protokół transakcji służący do pobierania Danych za pomocą połączenia interfejsu DSRC działającego na częstotliwości 5,8 GHz przebiega zgodnie z następującymi krokami. W niniejszej sekcji opisuje się przepływ transakcji w warunkach idealnych, bez retransmisji czy zakłóceń łączności.
UWAGA: celem etapu inicjacji (krok 1) jest ustanowienie łączności między REDCR a DSRC-VU, które znalazły się w strefie transakcji DSRC w częstotliwości 5,8 GHz (tryb nadrzędny-podrzędny), ale jeszcze nie nawiązały łączności z REDCR, a także zgłoszenie procesów aplikacji.
- Krok 1 Inicjacja. REDCR wysyła ramkę zawierającą tabelę usług sygnału (BST), która zawiera identyfikatory aplikacji (AID) w wykazie obsługiwanych usług. W aplikacji RTM będzie to po prostu usługa z wartością AID = 2 (Freight&Fleet). DSRC-VU dokonuje oceny otrzymanej BST i odpowiada (zob. poniżej), przekazując wykaz obsługiwanych aplikacji w ramach domeny Freight&Fleet, lub nie odpowiada, jeżeli żadne aplikacje nie są obsługiwane. Jeżeli REDCR nie oferuje AID=2, DSRC-VU nie odpowiada REDCR.
- Krok 2 DSRC-VU wysyła ramkę zawierającą żądane przydzielenia okna prywatnego.
- Krok 3 REDCR wysyła ramkę z przydziałem okna prywatnego.
- Krok 4 DSRC-VU używa przydzielonego okna prywatnego do wysłania ramki zawierającej jego tabelę usług pojazdu (VST). Tego rodzaju VST zawiera wykaz wszystkich różnych wystąpień aplikacji obsługiwanych przez ten DSRC-VU w ramach AID=2. Poszczególne wystąpienia są identyfikowane za pomocą jednorazowo generowanych identyfikatorów elementu, z których każdy jest powiązany z wartością parametru znacznika kontekstowego aplikacji określającą obsługiwaną aplikację i normę.
- Krok 5 Następnie REDCR analizuje oferowaną tabelę usług pojazdu i albo przerywa łączność (RELEASE), ponieważ nie jest zainteresowany niczym, co dana VST ma do zaoferowania (tj. otrzymuje VST od DSRC-VU, który nie obsługuje transakcji RTM), albo - jeżeli otrzymuje odpowiednią tabelę usług pojazdu - uruchamia wystąpienie aplikacji.
- Krok 6 Aby osiągnąć ten cel, REDCR wysyła ramkę zawierającą polecenie pobrania danych dotyczących zdalnego monitorowania tachografu i identyfikującą wystąpienie aplikacji RTM poprzez wskazanie identyfikatora odpowiadającego wystąpieniu aplikacji RTM (jak określił DSRC-VU w VST) oraz przydziela okno prywatne.
- Krok 7 DSRC-VU używa nowo przydzielonego okna prywatnego do wysłania ramki zawierającej adresowany identyfikator odpowiadający wystąpieniu aplikacji RTM zgodnie z VST, po którym następuje atrybut RtmData (element ładunku + element bezpieczeństwa).
- Krok 8 W przypadku żądania wielu usług wartość "n" zmienia się na kolejny numer referencyjny usługi i procedura zostaje powtórzona.
- Krok 9 REDCR potwierdza otrzymanie danych, wysyłając do DSRC-VU ramkę zawierającą polecenie RELEASE w celu przerwania sesji LUB, jeżeli nie zatwierdził pomyślnego otrzymania LPDU, wraca do kroku 6.
Zob. rys. 14.6 przedstawiający graficzny opis protokołu transakcji.
Rys. 14.6
Zdalne monitorowanie tachografu w ramach przepływu procesów DSRC na częstotliwości 5,8 GHz
5.4.2 Polecenia
DSC_35 Poniższe polecenia stanowią jedyne funkcje stosowane na etapie transakcji RTM:
- INITIALISATION.request: polecenie wysyłane z REDCR w formie emisji z definicją aplikacji obsługiwanych przez ten REDCR;
- INITIALISATION.response: odpowiedź z DSRC-VU potwierdzająca połączenie i zawierająca wykaz obsługiwanych wystąpień aplikacji wraz z charakterystyką oraz informacjami na temat sposobu postępowania z nimi (EID);
- GET.request: polecenie wysyłane z REDCR do DSRC-VU, określające wystąpienie aplikacji, którym należy się zająć, za pomocą zdefiniowanego EID otrzymanego w VST, oraz nakazujące DSRC-VU wysłanie wybranego(-ych) atrybutu(-ów) z Danymi. Celem polecenia GET jest umożliwienie REDCR otrzymania Danych od DSRC-VU;
- GET.response: odpowiedź z DSRC-VU zawierająca żądane Dane;
- ACTION.request ECHO: polecenie nakazujące DSRC-VU odesłanie danych z DSRC-VU do REDCR. Celem polecenia ECHO jest umożliwienie warsztatom lub placówkom przeprowadzających testy na potrzeby homologacji typu zbadania, czy połączenie DSRC działa bez konieczności dostępu do poświadczeń zabezpieczenia;
- ACTION.response ECHO: odpowiedź z DSRC-VU na polecenie ECHO;
- EVENT_REPORT.request RELEASE: polecenie informujące DSRC-VU o zakończeniu transakcji. Celem polecenia RESEALSE jest zakończenie sesji z DSRC-VU. Po otrzymaniu polecenia RELEASE DSRC-VU nie odpowiada na żadne dalsze zapytania w ramach bieżącego połączenia. Należy zauważyć, że zgodnie z wymogami normy EN 12834 DSRC-VU nie połączy się drugi raz z tym samym interrogatorem, chyba że znajdował się poza strefą łączności przez 255 sekund lub identyfikator sygnału interrogatora został zmieniony.
5.4.3 Sekwencja polecenia zapytania
DSC_36 Z perspektywy sekwencji polecenia i odpowiedzi transakcję opisuje się w następujący sposób:
| Sekwencja | Nadajnik | Odbiornik | Opis | Działanie | |
| 1 | REDCR | > | DSRC-VU | Inicjacja łącza komunikacyjnego żądanie | REDCR emituje BST |
| 2 | DSRC-VU | > | REDCR | Inicjacja łącza komunikacyjnego odpowiedź | Jeżeli BST obsługuje AID=2, to DSRC-VU żąda okna prywatnego |
| 3 | REDCR | > | DSRC-VU | Przyznaje okno prywatne | Wysyła ramkę zawierającą przydział okna prywatnego |
| 4 | DSRC-VU | > | REDCR | Wysyła VST | Wysyła ramkę zawierającą VST |
| 5 | REDCR | > | DSRC-VU | Wysyła GET.request w odniesieniu do danych zawartych w Atrybucie dotyczącym konkretnego EID | |
| 6 | DSRC-VU | > | REDCR | Wysyła GET.response z żądanym atrybutem dotyczącym konkretnego EID | Wysyła Atrybut (RTMData, OWS-Data....) zawierający dane dotyczące konkretnego EID |
| 7 | REDCR | > | DSRC-VU | Wysyła GET.request w odniesieniu do danych innego Atrybutu (w razie potrzeby) | |
| 8 | DSRC-VU | > | REDCR | Wysyła GET.response z żądanym atrybutem | Wysyła Atrybut zawierający dane dotyczące konkretnego EID |
| 9 | REDCR | > | DSRC-VU | Potwierdza pomyślne otrzymanie danych | Wysyła polecenie RELEASE zamykające transakcję |
| 10 | DSRC-VU | Zamyka transakcję |
| Przykład sekwencji transakcji i zawartości wymienianych ramek przedstawiono w pkt 5.4.7 i 5.4.8. |
5.4.4 Struktury danych
DSC_37 Struktura semantyczna Danych przekazywanych przez interfejs DSRC działający na częstotliwości 5,8 GHz jest zgodna ze strukturą opisaną w niniejszym dodatku. Strukturę tych danych przedstawiono w tym punkcie.
DSC_38 Ładunek (dane dotyczące zdalnego monitorowania tachografu) składa się z połączenia:
1. danych EncryptedTachographPayload stanowiących zaszyfrowane dane TachographPayload określone w specyfikacji ASN.1 w sekcji 5.4.5. Metodę szyfrowania opisano w dodatku 11;
2. danych DSRCSecurityData określonych w dodatku 11.
DSC_39 Dane dotyczące zdalnego monitorowania tachografu opisuje się jako Atrybut RTM = 1 i przekazuje w kontenerze RTM = 10.
DSC_40 Znacznik kontekstowy RTM określa obsługiwaną część normy w serii norm TARV (RTM odnosi się do części 9).
Zawarta w module ASN.1 definicja danych DSRC w ramach aplikacji RTM jest następująca:
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.
5.4.5 Elementy danych dotyczących zdalnego monitorowania tachografu (RtmData), wykonywane czynności i definicje
DSC_41 Wartości danych, które mają zostać obliczone przez VU i wykorzystane do uaktualnienia zabezpieczonych danych w DSRC-VU, oblicza się zgodnie z zasadami przedstawionymi w tabeli 14.3:
Tabela 14.3
Elementy RtmData, wykonywane czynności i definicje
| 1) Element danych RTM | 2) Czynność wykonywana przez VU | 3) Definicja danych w ASN.1 | |
| RTM1 Tablica rejestracyjna pojazdu | VU ustala wartość tp15638VehicleRegistrationPlate elementu danych RTM1 na podstawie zarejestrowanej wartości typu danych VehicleRegistrationldentification, jak określono w dodatku 1 VehicleRegistrationIdentification | Numer tablicy rejestracyjnej pojazdu wyrażony jako ciąg znaków | tp15638VehicleRegistrationPlate LPN, -tablica rejestracyjna pojazdu ze strukturą danych według ISO 14906, ale z następującym ograniczeniem na potrzeby aplikacji RTM: SEKWENCJA rozpoczyna się od kodu kraju, po którym następuje wskaźnik alfabetu, po którym następuje sam numer tablicy, który ma zawsze 14 oktetów (wypełnionych zerami), tak więc długość typu LPN zawsze wynosi 17 oktetów (determinant długości nie jest potrzebny), z czego 14 to »rzeczywisty« numer tablicy. |
| RTM2 Zdarzenia polegające na przekroczeniu prędkości | VU generuje wartość logiczną w odniesieniu do elementu danych RTM2 tp15638SpeedingEvent. VU oblicza wartość tp15638SpeedingEvent na podstawie zdarzeń przekroczenia prędkości zarejestrowanych w VU w ciągu ostatnich 10 dni, jak określono w załączniku IC . | 1 (PRAWDA): jeżeli ostatnie zdarzenie przekroczenia prędkości zakończyło się w ciągu ostatnich 10 dni lub trwa nadal; 0 (FAŁSZ): w każdym innym przypadku. | tp15638SpeedingEvent BOOLEAN, |
| RTM3 Prowadzenie pojazdu bez ważnej karty | VU generuje wartość logiczną w odniesieniu do elementu danych RTM3 tp15638DrivingWithoutValid- Card. VU przypisuje wartość PRAWDA zmiennej tp15638DrivingWithoutValid- Card, jeżeli w VU zarejestrowano co najmniej jedno zdarzenie prowadzenia pojazdu bez odpowiedniej karty w ciągu ostatnich 10 dni, jak określono w załączniku IC. | 1 (PRAWDA): jeżeli ostatnie zdarzenie prowadzenia pojazdu bez odpowiedniej karty zakończyło się w ciągu ostatnich 10 dni lub trwa nadal; 0 (FAŁSZ): w każdym innym przypadku. | tp15638DrivingWithoutValid- Card BOOLEAN, |
| RTM4 Ważna karta kierowcy | VU generuje wartość logiczną w odniesieniu do elementu danych RTM4 tp15638DriverCard na podstawie ważnej karty kierowcy włożonej w szczelinę czytnika karty kierowcy. | 1 (PRAWDA): jeżeli w szczelinie czytnika karty kierowcy VU nie ma ważnej karty kierowcy; 0 (FAŁSZ): jeżeli w szczelinie czytnika karty kierowcy VU znajduje się ważna karta kierowcy. | tp15638DriverCard BOOLEAN, |
| RTM5 Włożenie karty podczas prowadzenia pojazdu | VU generuje wartość logiczną w odniesieniu do elementu danych RTM5 tp15638CardInsertion. VU przypisuje wartość PRAWDA zmiennej tp15638CardInsertion, jeżeli w VU zarejestrowano co najmniej jedno zdarzenie włożenia karty podczas prowadzenia pojazdu w ciągu ostatnich 10 dni, jak określono w załączniku IC. | 1 (PRAWDA): Jeżeli ostatnie zdarzenie włożenia karty podczas prowadzenia pojazdu miało miejsce w ciągu ostatnich 10 dni; 0 (FAŁSZ): w każdym innym przypadku. | tp15638CardInsertion BOOLEAN, |
| RTM6 Błąd danych dotyczących ruchu | VU generuje wartość logiczną w odniesieniu do elementu danych RTM6. VU przypisuje wartość PRAWDA zmiennej tp15638MotionDataError, jeżeli w VU zarejestrowano co najmniej jedno zdarzenie błędu danych dotyczących ruchu w ciągu ostatnich 10 dni, jak określono w załączniku IC. | 1 (PRAWDA): jeżeli ostatnie zdarzenie błędu danych dotyczących ruchu zakończyło się w ciągu ostatnich 10 dni lub trwa nadal; 0 (FAŁSZ): w każdym innym przypadku. | tp15638MotionDataError BOOLEAN, |
| RTM7 Konflikt ruchu pojazdu | VU generuje wartość logiczną w odniesieniu do elementu danych RTM7. VU przypisuje wartość PRAWDA zmiennej tp15638VehicleMotionCon- flict, jeżeli w VU zarejestrowano co najmniej jedno zdarzenie konfliktu ruchu pojazdu w ciągu ostatnich 10 dni. | 1 (PRAWDA): jeżeli ostatnie zdarzenie konfliktu ruchu pojazdu zakończyło się w ciągu ostatnich 10 dni lub trwa nadal; 0 (FAŁSZ): w każdym innym przypadku. | tp15638VehicleMotionConflict BOOLEAN, |
| RTM8 Druga karta kierowcy | VU generuje wartość logiczną w odniesieniu do elementu danych RTM8 na podstawie załącznika IC (»Dane dotyczące czynności kierowcy« w odniesieniu do ZAŁOGI i WSPÓŁKIEROWCY). W przypadku braku ważnej karty współkierowcy VU ustawia wartość RTM8 na PRAWDA. | 1 (PRAWDA): jeżeli w VU znajduje się ważna karta współkierowcy; 2 (FAŁSZ): jeżeli w VU nie ma ważnej karty współkierowcy. | tp156382ndDriverCard BOOLEAN, |
| RTM9 Bieżąca czynność | VU generuje wartość logiczną w odniesieniu do elementu danych RTM9. Jeżeli VU zarejestruje bieżącą czynność jako jakąkolwiek czynność inną niż PROWADZENIE, jak określono w załączniku IC, ustawia wartość RTM9 na PRAWDA. | 1 (PRAWDA): inna wybrana czynność; 0 (FAŁSZ): wybór czynności »prowadzenie« | tp15638CurrentActivityDriving BOOLEAN |
| RTM10 Zamknięcie ostatniej sesji | VU generuje wartość logiczną w odniesieniu do elementu danych RTM10. Jeżeli ostatnia sesja karty nie została prawidłowo zamknięta zgodnie z procedurą opisaną w załączniku IC, VU ustawia wartość RTM10 na PRAWDA. | 1 (PRAWDA): co najmniej jedna z włożonych kart wywołała błąd niepoprawnego zamknięcia ostatniej sesji karty; 0 (FAŁSZ): żadna z włożonych kart nie wywołała błędu niepoprawnego zamknięcia ostatniej sesji karty. | tp15638LastSessionClosed BOOLEAN |
| RTM11 Przerwa w zasilaniu | VU generuje wartość w postaci liczby całkowitej w odniesieniu do elementu danych RTM11. VU przypisuje zmiennej tp15638PowerSupplyInterrup- tion wartość odpowiadającą liczbie zarejestrowanych zdarzeń przerwy w zasilaniu przechowywanych w VU w ciągu ostatnich 10 dni, jak określono w załączniku IC. Jeżeli VU nie zarejestrował żadnego zdarzenia przerwy w zasilaniu w ciągu ostatnich 10 dni, ustala wartość RTM11 na 0. | Liczba zarejestrowanych przerw w zasilaniu w ciągu ostatnich 10 dni. | tp15638PowerSupplyInterrup- tion INTEGER (0..127), |
| RTM12 Usterka czujnika | VU generuje wartość w postaci liczby całkowitej w odniesieniu do elementu danych RTM12. VU przypisuje zmiennej sensorFault wartość: - 1, jeżeli zdarzenie typu '35'H związane z usterką czujnika zostało zarejestrowane w ciągu ostatnich 10 dni lub trwa nadal. - 2, jeżeli zdarzenie związane z usterką odbiornika GNSS (wewnętrznego albo zewnętrznego, | -usterka czujnika jeden oktet zgodnie ze słownikiem danych | tp15638SensorFault INTEGER (0..255), |
| o wartości enum '36'H lub '37'H) zakończyło się w ciągu ostatnich 10 dni lub trwa nadal. - 3, jeżeli zdarzenie typu '0E'H związane z błędem połączenia z urządzeniem zewnętrznym GNSS zakończyło się w ciągu ostatnich 10 dni lub trwa nadal. - 4, jeżeli zarówno usterka czujnika, jak i usterka odbiornika GNSS zakończyły się w ciągu ostatnich 10 dni lub trwają nadal. - 5, jeżeli zarówno usterka czujnika, jak i błąd połączenia z urządzeniem zewnętrznym GNSS zakończyły się w ciągu ostatnich 10 dni lub trwają nadal. - 6, jeżeli zarówno usterka odbiornika GNSS, jak i błąd połączenia z urządzeniem zewnętrznym GNSS zakończyły się w ciągu ostatnich 10 dni lub trwają nadal. - 7, jeżeli wszystkie trzy usterki czujnika zakończyły się w ciągu ostatnich 10 dni lub trwają nadal. Jeżeli żadne zdarzenie nie zakończyło się w ciągu ostatnich 10 dni ani nie trwa nadal, VU ustala wartość RTM12 na 0. | |||
| RTM13 Korekta czasu | VU generuje wartość w postaci liczby całkowitej (timeReal z dodatku 1) dla elementu danych RTM13 na podstawie obecności danych dotyczących korekty czasu zdefiniowanych w załączniku IC. VU ustawia wartość RTM13 na czas, w którym doszło do wystąpienia ostatniego zdarzenia polegającego na korekcie czasu danych. Jeżeli w danych VU nie stwierdzono wystąpienia żadnego zdarzenia korekty czasu zdefiniowanego w załączniku IC, wartość RTM13 ustala się na 0. | oldTimeValue ostatniej korekty czasu. | tp15638TimeAdjustment INTEGER(0..4294967295), |
| RTM14 Próba naruszenia zabezpieczenia | VU generuje wartość w postaci liczby całkowitej (timeReal z dodatku 1) dla elementu danych RTM14 na podstawie wystąpienia zdarzenia próby naruszenia zabezpieczenia zdefiniowanego w załączniku IC. | Czas rozpoczęcia ostatniego zarejestrowanego zdarzenia związanego z próbą naruszenia zabezpieczenia. | tp15638LatestBreachAttempt INTEGER(0..4294967295), |
| VU ustala wartość czasu, w którym doszło do ostatniego zarejestrowanego przez VU zdarzenia związanego z próbą naruszenia zabezpieczenia. Jeżeli w danych VU nie stwierdzono wystąpienia żadnego zdarzenia próby naruszenia zabezpieczenia zdefiniowanego w załączniku IC, wartość RTM14 ustala się na 0. | |||
| RTM15 Ostatnia kalibracja | VU generuje wartość w postaci liczby całkowitej (timeReal z dodatku 1) dla elementu danych RTM15 na podstawie obecności danych dotyczących ostatniej kalibracji zdefiniowanych w załączniku IC i dodatku 1. VU ustala wartość RTM15 na old TimeValue ostatniego rekordu kalibracji. Jeżeli kalibracja nie miała miejsca, VU ustala wartość RTM15 na 0. | oldTimeValue najnowszego rekordu kalibracji. | tp15638LastCalibrationData INTEGER(0..4294967295), |
| RTM16 Poprzednia kalibracja | VU generuje wartość w postaci liczby całkowitej (timeReal z dodatku 1) dla elementu danych RTM16 z rekordu kalibracyjnego poprzedzającego ostatnią kalibrację. VU ustala wartość RTM16 na old TimeValue rekordu kalibracji poprzedzającego ostatnią kalibrację. Jeżeli nie było poprzedniej kalibracji, VU ustala wartość RTM16 na 0. | oldTimeValue rekordu kalibracji poprzedzającego najnowszy rekord kalibracji. | tp15638PrevCalibrationData INTEGER(0..4294967295), |
| RTM17 Data podłączenia tachografu | VU generuje wartość w postaci liczby całkowitej (timeReal z dodatku 1) w odniesieniu do elementu danych RTM17. VU ustala wartość RTM17 na datę pierwszej kalibracji VU w bieżącym pojeździe. VU wyodrębnia te dane z VuCalibrationData (dodatek 1) znajdujących się w VuCalibrationRecords z CalibrationPurpose równym: '03'H | Data pierwszej kalibracji VU w bieżącym pojeździe. | tp15638DateTachoConnected INTEGER(0..4294967295), |
| Jeżeli nie było poprzedniej kalibracji, VU ustala wartość RTM17 na 0. | |||
| RTM18 Prędkość bieżąca | VU generuje wartość w postaci liczby całkowitej w odniesieniu do elementu danych RTM18. VU ustala wartość RTM18 na wartość ostatniej zarejestrowanej prędkości bieżącej w chwili dokonania ostatniej aktualizacji RtmData. | Ostatnia zarejestrowana prędkość bieżąca | tp15638CurrentSpeed INTEGER (0..255), |
| RTM19 Znacznik czasu | VU generuje wartość w postaci liczby całkowitej w odniesieniu do elementu danych RTM19 (timeReal z dodatku 1). VU ustala wartość RTM19 na czas ostatniej aktualizacji RtmData. | Znacznik czasu bieżącego rekordu TachographPayload | tp15638Timestamp INTEGER(0..4294967295), |
| RTM20 Czas, kiedy była dostępna ostatnia uwierzytelniona pozycja pojazdu | VU generuje wartość w postaci liczby całkowitej (timeReal z dodatku 1) w odniesieniu do elementu danych RTM20. VU ustala wartość RTM20 na czas, kiedy ostatnia uwierzytelniona pozycja pojazdu była dostępna z odbiornika GNSS. Jeżeli żadna uwierzytelniona pozycja pojazdu nie była kiedykolwiek dostępna z odbiornika GNsS, VU ustawia wartość RTM20 na 0. | Znacznik czasu ostatniej uwierzytelnionej pozycji pojazdu | tp15638LatestAuthenticatedPo- sition INTEGER(0..4294967295), |
| RTM21 Nieprzerwany czas prowadzenia pojazdu | VU generuje wartość w postaci liczby całkowitej w odniesieniu do elementu danych RTM21. VU ustala wartość RTM21 na trwający nieprzerwany czas prowadzenia pojazdu przez kierowcę. | Nieprzerwany czas prowadzenia pojazdu przez kierowcę, zakodowany jako liczba całkowita. Długość: 1 bajt Rozdzielczość: 2 minuty/bit Brak offsetu Przedział danych: 0 do 250 Wartość 250 wskazuje, że nieprzerwany czas prowadzenia pojazdu przez kierowcę wynosi co najmniej 500 minut. Wartości 251 do 254 nie używa się. | tp15638ContinuousDrivingTime INTEGER(0..255), |
| Wartość 255 wskazuje, że informacje nie są dostępne. | |||
| RTM22 Najdłuższy dzienny czas prowadzenia pojazdu dla trwającej i poprzedniej zmiany RTM, obliczony zgodnie z addendum do dodatku 14 | VU generuje wartość w postaci liczby całkowitej w odniesieniu do elementu danych RTM22. VU ustawia wartość RTM22 na dłuższy z dwóch dziennych okresów prowadzenia pojazdu przez kierowcę, tj. na trwającą lub poprzednią zmianę RTM. | Dzienny czas prowadzenia pojazdu przez kierowcę, zakodowany jako liczba całkowita. Długość: 1 bajt Rozdzielczość: 4 minuty/bit Brak offsetu Przedział danych: 0 do 250 Wartość 250 wskazuje, że dzienny czas prowadzenia pojazdu przez kierowcę wynosi co najmniej 1 000 minut. Wartości 251 do 254 nie używa się. Wartość 255 wskazuje, że informacje nie są dostępne. | tp15638DailyDrivingTimeShift INTEGER(0..255), |
| RTM23 Najdłuższy dzienny czas prowadzenia pojazdu w trwającym tygodniu, obliczony zgodnie z addendum do dodatku 14 | VU generuje wartość w postaci liczby całkowitej w odniesieniu do elementu danych RTM23. VU ustawia wartość RTM23 na najdłuższy dzienny czas prowadzenia pojazdu przez kierowcę, tj. na trwającą zmianę RTM lub jakąkolwiek ukończoną zmianę RTM, która rozpoczęła się lub zakończyła w trwającym tygodniu. | Dzienny czas prowadzenia pojazdu przez kierowcę, zakodowany jako liczba całkowita. Długość: 1 bajt Rozdzielczość: 4 minuty/bit Brak offsetu Przedział danych: 0 do 250 Wartość 250 wskazuje, że dzienny czas prowadzenia pojazdu przez kierowcę wynosi co najmniej 1 000 minut. Wartości 251 do 254 nie używa się. Wartość 255 wskazuje, że informacje nie są dostępne. | tp15638DailyDrivingTimeWeek INTEGER(0..255), |
| RTM24 Tygodniowy czas prowadzenia pojazdu, obliczony zgodnie z addendum do dodatku 14 | VU generuje wartość w postaci liczby całkowitej w odniesieniu do elementu danych RTM24. VU ustala wartość RTM24 na tygodniowy czas prowadzenia pojazdu przez kierowcę. | Tygodniowy czas prowadzenia pojazdu przez kierowcę, zakodowany jako liczba całkowita. Długość: 1 bajt Rozdzielczość: 20 minuty/bit Brak offsetu Przedział danych: 0 do 250 | tp15638WeeklyDrivingTime INTEGER(0..255), |
| Wartość 250 wskazuje, że tygodniowy czas prowadzenia pojazdu przez kierowcę wynosi co najmniej 5 O00 minut. Wartości 251 do 254 nie używa się. Wartość 255 wskazuje, że informacje nie są dostępne. | |||
| RTM25 Dwutygodniowy czas prowadzenia pojazdu, obliczony zgodnie z addendum do dodatku 14 | VU generuje wartość w postaci liczby całkowitej w odniesieniu do elementu danych RTM25. VU ustala wartość RTM25 na dwutygodniowy czas prowadzenia pojazdu przez kierowcę. | Dwutygodniowy czas prowadzenia pojazdu przez kierowcę, zakodowany jako liczba całkowita. Długość: 1 bajt Rozdzielczość: 30 minuty/bit Brak offsetu Przedział danych: 0 do 250 Wartość 250 wskazuje, że dwutygodniowy czas prowadzenia pojazdu przez kierowcę wynosi co najmniej 7 500 minut. Wartości 251 do 254 nie używa się. Wartość 255 wskazuje, że informacje nie są dostępne. | tp15638FortnightlyDrivmgTime INTEGER(0..255), |
Uwaga: RTM22, RTM23, RTM24 i RTM25 oblicza się zgodnie z addendum do niniejszego dodatku.5.4.6 Mechanizm przesyłania danych
DSC_42 REDCR wysyła żądanie przekazania zdefiniowanych wcześniej danych ładunku po zakończeniu etapu inicjacji; następnie DSRC-VU przekazuje te dane w przydzielonym oknie. REDCR korzysta z polecenia GET w celu pobrania danych.
DSC_43 Wszystkie dane wymieniane w ramach DSRC koduje się przy użyciu reguł PER (Packed Encoding Rules) UNALIGNED, z wyjątkiem TachographPayload oraz OwsPayload;, które koduje się przy użyciu reguł OER (Octet Encoding Rules) zdefiniowanych w normie ISO/IEC 8825-7, Rec. ITU-T X.696.
5.4.7 Szczegółowy opis transakcji DSRC
DSC_44 Inicjację przeprowadza się zgodnie z pkt DSC_44-DSC_48 oraz tabelami 14.4-14.9. Na etapie inicjacji REDCR rozpoczyna przesyłanie ramki zawierającej BST (tabelę usług sygnału) zgodnie z normami EN 12834 i EN 13372 pkt 6.2, 6.3, 6.4 i 7.1 z ustawieniami określonymi w tabeli 14.4 poniżej.
Tabela 14.4
Inicjacja - ustawienia ramki BST
| Pole | Ustawienia |
| Identyfikator łącza | Adres emisji |
| Identyfikator sygnału | Zgodnie z normą EN 12834 |
| Czas | Zgodnie z normą EN 12834 |
| Profil | Brak rozszerzenia, należy zastosować 0 lub 1 |
| Aplikacje obowiązkowe | Brak rozszerzenia, brak EID, brak parametru, AID = 2 Freight&Fleet |
| Aplikacje nieobowiązkowe | Brak |
| Lista profilów | Brak rozszerzenia, liczba profilów na liście = 0 |
| Nagłówek fragmentacji | Brak fragmentacji |
| Ustawienia 2. warstwy | Polecenie PDU, polecenie interfejsu użytkownika |
W tabeli 14.5 poniżej przedstawiono praktyczny przykład zastosowania ustawień określonych w tabeli 14.4 wraz z informacjami o kodowaniu bitowym.
Tabela 14.5
Inicjacja - przykładowa zawartość ramki BST
| Oktet # | Atrybut/Pole | Bity w oktecie | Opis |
| 1 | FLAGA | 0111 1110 | Flaga początkowa |
| 2 | Identyfikator emisji | 1111 1111 | Adres emisji |
| 3 | Pole kontrolne MAC | 1010 0000 | Polecenie PDU |
| 4 | Pole kontrolne LLC | 0000 0011 | Polecenie interfejsu użytkownika |
| 5 | Nagłówek fragmentacji | 1xxx x001 | Brak fragmentacji |
| 6 | BST | 1000 | Żądanie inicjacji |
| SEQUENCE { OPTION indicator BeaconID SEQUENCE { ManufacturerId INTEGER (0..65535) | |||
| 0 | Brak aplikacji nieobowiązkowych | ||
| xxx | Identyfikator producenta | ||
| 7 | xxxx xxxx | ||
| 8 | xxxx x | ||
| IndividualID INTEGER (0..134217727) | xxx | 27-bitowy identyfikator dostępny dla producenta | |
| 9 | xxxx xxxx | ||
| 10 | xxxx xxxx | ||
| 11 | } | xxxx xxxx | |
| 12 | Time INTEGER (0..4294967295) | xxxx xxxx | Czas rzeczywisty w 32-bitowym systemie UNIX |
| 13 | xxxx xxxx | ||
| 14 | xxxx xxxx | ||
| 15 | xxxx xxxx | ||
| 16 | Profile NTEGER (0..127,...) | 0000 0000 | Brak rozszerzenia. Przykładowy profil 0 |
| 17 | MandApplications SEQUENCE (SIZE (0..127,...)) OF { | 0000 0001 | Brak rozszerzenia, liczba aplikacji obowiązkowych = 1 |
| 18 | SEQUENCE { Wskaźnik WARIANTU Wskaźnik WARIANTU AID DSRCApplicationEntityID } } | ||
| 0 | Brak EID | ||
| 0 | Brak parametru | ||
| 00 0010 | Brak rozszerzenia. AID= 2 Freight&-Fleet | ||
| 19 | ProfileList SEQUENCE (0..127,...) OF Profile } | 0000 0000 | Brak rozszerzenia, liczba profilów na liście = 0 |
| 20 | FCS | xxxx xxxx | Sekwencja kontroli ramki |
| 21 | xxxx xxxx | ||
| 22 | Flaga | 0111 1110 | Flaga końcowa |
DSC_45 Po otrzymaniu BST DSRC-VU żąda przydzielenia okna prywatnego zgodnie z postanowieniami norm EN 12795 i EN 13372 pkt 7.1.1, bez określonych ustawień RTM. W tabeli 14.6 przedstawiono przykład kodowania bitowego.
Tabela 14.6
Inicjacja - zawartość ramki dotyczącej żądania przydzielenia okna prywatnego
| Oktet # | Atrybut/Pole | Bity w oktecie | Opis |
| 1 | FLAGA | 0111 1110 | Flaga początkowa |
| 2 | Prywatny LID | xxxx xxxx | Adres łącza określonego DSRC-VU |
| 3 | xxxx xxxx | ||
| 4 | xxxx xxxx | ||
| 5 | xxxx xxxx | ||
| 6 | Pole kontrolne MAC | 0110 0000 | Żądanie przydzielenia okna prywatnego |
| 7 | FCS | xxxx xxxx | Sekwencja kontroli ramki |
| 8 | xxxx xxxx | ||
| 9 | Flaga | 0111 1110 | Flaga końcowa |
DSC_46 Następnie REDCR odpowiada, przydzielając okno prywatne zgodnie z postanowieniami norm EN 12795 i EN 13372 pkt 7.1.1, bez określonych ustawień RTM.
W tabeli 14.7 przedstawiono przykład kodowania bitowego.
Tabela 14.7
Inicjacja - zawartość ramki dotyczącej przydzielenia okna prywatnego
| Oktet # | Atrybut/Pole | Bity w oktecie | Opis |
| 1 | FLAGA | 0111 1110 | Flaga początkowa |
| 2 | Prywatny LID | xxxx xxxx | Adres łącza określonego DSRC-VU |
| 3 | xxxx xxxx | ||
| 4 | xxxx xxxx | ||
| 5 | xxxx xxxx | ||
| 6 | Pole kontrolne MAC | 0010 s000 | Przydzielenie okna prywatnego |
| 7 | FCS | xxxx xxxx | Sekwencja kontroli ramki |
| 8 | xxxx xxxx | ||
| 9 | Flaga | 0111 1110 | Flaga końcowa |
DSC_47 Po otrzymaniu przydziału okna prywatnego DSRC-VU przesyła swoją VST (tabela usług pojazdu), jak określono w normach EN 12834 i EN 13372 pkt 6.2, 6.3, 6.4 i 7.1, z ustawieniami określonymi w tabeli 14.8 za pomocą przydzielonego okna transmisji.
Tabela 14.8
Inicjacja - ustawienia ramki VST
| Pole | Ustawienia |
| Prywatny LID | Zgodnie z normą EN 12834 |
| Parametry VST | Wypełnienie = 0; następnie dla każdej obsługiwanej aplikacji: EID występuje, parametr występuje, AID = 2; EID zgodny z wygenerowanym przez OBU |
| Parametr | Brak rozszerzenia, zawiera znacznik kontekstowy RTM |
| ObeConfiguration | Opcjonalne pole ObeStatus może być obecne, ale nie może być stosowane przez REDCR |
| Nagłówek fragmentacji | Brak fragmentacji |
| Ustawienia 2. warstwy | Polecenie PDU, polecenie interfejsu użytkownika |
DSC_48 DSRC-VU obsługuje aplikację "Ładunek i flota" (Freight and Fleet) opatrzoną identyfikatorem aplikacji '2'. Inne identyfikatory aplikacji mogą być obsługiwane, ale nie mogą występować w tej VST, ponieważ BST wymaga wyłącznie AID=2. Pole "Aplikacje" zawiera wykaz wystąpień aplikacji obsługiwanych w ramach DSRC-VU. Dla każdego obsługiwanego wystąpienia aplikacji podaje się odniesienie do odpowiedniej normy w formie znacznika Rtm Context, który składa się z IDENTYFIKATORA OBIEKTU reprezentującego powiązaną normę, jej część (9 w przypadku RTM) oraz - w stosownych przypadkach - wersję, a także EID generowanego przez DSRC-VU i powiązanego z danym wystąpieniem aplikacji.
W tabeli 14.9 przedstawiono praktyczny przykład ustawień określonych w tabeli 14.8 wraz z informacjami o kodowaniu bitowym.
Tabela 14.9
Inicjacja - przykładowa zawartość ramki VST
| Oktet # | Atrybut/Pole | Bity w oktecie | Opis |
| 1 | FLAG | 0111 1110 | Flaga początkowa |
| 2 | Private LID | xxxx xxxx | Adres łącza określonego DSRC-VU |
| 3 | xxxx xxxx | Polecenie PDU | |
| 4 | xxxx xxxx | ||
| 5 | xxxx xxxx | ||
| 6 | MAC Control field | 1100 0000 | |
| 7 | LLC Control field | 0000 0011 | Polecenie interfejsu użytkownika |
| 8 | Fragmentation header | 1xxx x001 | Brak fragmentacji |
| 9 | VST SEQUENCE { Fill BIT STRING (SIZE(4)) | 1001 | Odpowiedź na inicjację |
| 0000 | Niewykorzystywane i ustawione na 0 | ||
| 10 | Profile INTEGER (0..127,...) Applications SEQUENCE OF { | 0000 0000 | Brak rozszerzenia. Przykładowy profil 0 Brak rozszerzenia, 1 aplikacja |
| 11 | 0000 0001 | ||
| 12 | SEQUENCE { OPTION indicator OPTION indicator AID DSRCApplicationEn- tityID | 1 | EID występuje |
| 1 | Parametr występuje | ||
| 00 0010 | Brak rozszerzenia. AID= 2 Freight&Fleet | ||
| 13 | EID Dsrc-EID | xxxx xxxx | Zdefiniowany przez OBU i identyfikujący wystąpienie aplikacji. |
| 14 | Parameter Container { | 0000 0010 | Brak rozszerzenia, wybór kontenera = 02, ciąg oktetowy |
| 15 | 0000 0110 | Brak rozszerzenia, długość znacznika kontekstowego RTM = 6 | |
| 16 | Rtm-ContextMark::= SEQUENCE { StandardIdentifier | 0000 0101 | Wartość pierwszego oktetu to 05H i stanowi jego długość. Kolejne 5 oktetów koduje identyfikator obiektu obsługiwanej normy, części i wersji. {ISO (1) norma (0) TARV (15638) część 9(9) wersja 2 (2)} |
| 17 | standardIdentifier | 0010 1000 | |
| 18 | 11111010 | ||
| 19 | 0001 0110 | ||
| 20 | 0000 1001 | ||
| 21 | 0000 0010 | ||
| 22 | ObeConfiguration Sequence{ OPTION indicator | 0 | Brak ObeStatus |
| EquipmentClass INTEGER (0..32767) | xxx xxxx | To pole używane jest na potrzeby | |
| 23 | xxxx xxxx | wskazań producenta dotyczących wersji oprogramowania/sprzętu interfejsu DSRC | |
| 24 | ManufacturerId INTEGER (0..65535) | xxxx xxxx | Identyfikator producenta dla DSRC-VU opisany w rejestrze dotyczącym normy ISO 14816 |
| 25 | xxxx xxxx | ||
| 26 | FCS | xxxx xxxx | Sekwencja kontroli ramki |
| 27 | xxxx xxxx | ||
| 28 | Flag | 0111 1110 | Flaga końcowa |
DCS_49 Następnie REDCR odczytuje dane, wydając polecenie GET, które odpowiada poleceniu GET zdefiniowanemu w normie EN 13372 pkt 6.2, 6.3, 6.4 i w normie EN 12834; ustawienia tego polecenia odpowiadają ustawieniom przedstawionym w tabeli 14.10.
Tabela 14.10
Przedstawienie - ustawienia ramki żądania GET
| Pole | Ustawienia |
| Identyfikator źródła (IID) | Brak |
| Identyfikator łącza (LID) | Adres łącza określonego DSRC-VU |
| Tworzenie łańcuchów | Nie |
| Identyfikator elementu (EID) | Jak określono w VST. Brak rozszerzenia |
| Poświadczenia dostępu | Nie |
| AttributeIdList | Brak rozszerzenia, 1 atrybut, AttributeID = 1 (RtmData) |
| Fragmentacja | Nie |
| Ustawienia 2. warstwy | Polecenie PDU, wysondowane polecenie ACn |
W tabeli 14.11 przedstawiono przykład odczytu danych RTM.
Tabela 14.11
Przedstawienie - przykład ramki żądania GET
| Oktet # | Atrybut/Pole | Bity w oktecie | Opis |
| 1 | FLAGA | 0111 1110 | Flaga początkowa |
| 2 | Prywatny LID | xxxx xxxx | Adres łącza określonego DSRC-VU |
| 3 | xxxx xxxx | ||
| 4 | xxxx xxxx | ||
| 5 | xxxx xxxx | ||
| 6 | Pole kontrolne MAC | 1010 s000 | Polecenie PDU |
| 7 | Pole kontrolne LLC | n111 0111 | Wysondowane polecenie ACn, bit n |
| 8 | Nagłówek fragmentacji | 1xxx x001 | Brak fragmentacji |
| 9 | Get.request SEQUENCE { Wskaźnik WARIANTU Wskaźnik WARIANTU Wskaźnik WARIANTU Wypełnienie CIĄG BITÓW (ROZMIAR (1)) | 0110 | Żądanie Get |
| 0 | Brak poświadczeń dostępu | ||
| 0 | Brak IID | ||
| 1 | Występuje AttributeIdList | ||
| 0 | Ustalono na 0. | ||
| 10 | EID INTEGER(0..127,...) | xxxx xxxx | EID wystąpienia aplikacji RTM, jak określono w VST. Brak rozszerzenia |
| 11 | AttributeIdList SEQUENCE OF { AttributeId }} | 0000 0001 | Brak rozszerzenia, liczba atrybutów = 1 |
| 12 | 0000 0001 | AttributeId=1, RtmData. Brak rozszerzenia | |
| 13 | FCS | xxxx xxxx | Sekwencja kontroli ramki |
| 14 | xxxx xxxx | ||
| 15 | Flaga | 0111 1110 | Flaga końcowa |
DSC_50 Po otrzymaniu żądania GET DSRC-VU wysyła odpowiedź GET wraz z żądanymi danymi zgodnymi z odpowiedzią GET określonymi w normie EN 13372 pkt 6.2, 6.3, 6.4 i w normie EN 12834; ustawienia odpowiadają ustawieniom określonym w tabeli 14.12.
Tabela 14.12
Przedstawienie - ustawienia ramki odpowiedzi GET
| Pole | Ustawienia |
| Identyfikator źródła (IID) | Brak |
| Identyfikator łącza (LID) | Zgodnie z normą EN 12834 |
| Tworzenie łańcuchów | Nie |
| Identyfikator elementu (EID) | Jak określono w VST. |
| Poświadczenia dostępu | Nie |
| Fragmentacja | Nie |
| Ustawienia 2. warstwy | Odpowiedź PDU, dostępna odpowiedź i przyjęte polecenie, polecenie ACn |
W tabeli 14.13 przedstawiono przykład odczytu danych RTM.
Tabela 14.13
Przedstawienie - przykładowa zawartość ramki odpowiedzi
| Oktet # | Atrybut/Pole | Bity w oktecie | Opis |
| 1 | FLAGA | 0111 1110 | Flaga początkowa |
| 2 | Prywatny LID | xxxx xxxx | Adres łącza określonego DSRC-VU |
| 3 | xxxx xxxx | ||
| 4 | xxxx xxxx | ||
| 5 | xxxx xxxx | ||
| 6 | Pole kontrolne MAC | 1101 0000 | Odpowiedź PDU |
| 7 | Pole kontrolne LLC | n111 0111 | Dostępna odpowiedź, bit n polecenia ACn |
| 8 | Pole stanu LLC | 0000 0000 | Dostępna odpowiedź i przyjęte polecenie |
| 9 | Nagłówek fragmentacji | 1xxx x001 | Brak fragmentacji |
| 10 | GET.response SEQUENCE { | 0111 | Odpowiedź na żądanie Get |
| Wskaźnik WARIANTU Wskaźnik WARIANTU Wskaźnik WARIANTU Wypełnienie CIĄG BITÓW (ROZMIAR (1)) | 0 | Brak IID | |
| 1 | Lista atrybutów występuje | ||
| 0 | Status zwrotu nie występuje | ||
| 0 | Nieużywany | ||
| 11 | EID INTEGER(0..127,...) | xxxx xxxx | Odpowiedź z wystąpienia aplikacji RTM. Brak rozszerzenia |
| 12 | AttributeList SEQUENCE OF { | 0000 0001 | Brak rozszerzenia, liczba atrybutów = 1 |
| 13 | Attributes SEQUENCE { AttributeId | 0000 0001 | Brak rozszerzenia, AttributeId=1 (RtmData) |
| 14 | AttributeValue CONTAINER { | 0000 1010 | Brak rozszerzenia, wybór kontenera = 1010. |
| 15 | kkkk kkkk | RtmData | |
| 16 | kkkk kkkk | ||
| 17 | kkkk kkkk | ||
| ... | ... | ||
| n | }}}} | kkkk kkkk | |
| n+1 | FCS | xxxx xxxx | Sekwencja kontroli ramki |
| n+2 | xxxx xxxx | ||
| n+3 | Flaga | 0111 1110 | Flaga końcowa |
DSC_51 Następnie REDCR zamyka połączenie, wydając polecenie EVENT_REPORT, RELEASE zgodnie z normą EN 13372 pkt 6.2, 6.3, 6.4 i z normą 12834 pkt 7.3.8, bez określonych ustawień RTM. W tabeli 14.14 przedstawiono przykład kodowania bitowego polecenia RELEASE.
Tabela 14.14
Zakończenie. EVENT_REPORT Uwolnienie zawartości ramki
| Oktet # | Atrybut/Pole | Bity w oktecie | Opis |
| 1 | FLAGA | 0111 1110 | Flaga początkowa |
| 2 | Prywatny LID | xxxx xxxx | Adres łącza określonego DSRC-VU |
| 3 | xxxx xxxx | ||
| 4 | xxxx xxxx | ||
| 5 | xxxx xxxx | ||
| 6 | Pole kontrolne MAC | 1000 s000 | Ramka zawiera polecenie LPDU |
| 7 | Pole kontrolne LLC | 0000 0011 | Polecenie interfejsu użytkownika |
| 8 | Nagłówek fragmentacji | 1xxx x001 | Brak fragmentacji |
| 9 | EVENT_REPORT.request SEQUENCE { | 0010 | EVENT_REPORT (Uwolnienie) |
| Wskaźnik WARIANTU | 0 | Brak poświadczeń dostępu | |
| Wskaźnik WARIANTU | 0 | Parametr zdarzenia nie występuje | |
| Wskaźnik WARIANTU | 0 | Brak IID | |
| Tryb DANYCH LOGICZNYCH | 0 | Odpowiedź nieoczekiwana | |
| 10 | EID INTEGER (0..127,...) | 0000 0000 | Brak rozszerzenia, EID = 0 (System) |
| 11 | EventType INTEGER (0..127,...) } | 0000 0000 | Typ zdarzenia 0 = Uwolnienie |
| 12 | FCS | xxxx xxxx | Sekwencja kontroli ramki |
| 13 | xxxx xxxx | ||
| 14 | Flaga | 0111 1110 | Flaga końcowa |
DSC_52 Nie oczekuje się, że DSRC-VU odpowie na polecenie RELEASE. Następnie łączność zostaje zamknięta.
5.4.8 Opis transakcji testowej DSRC
DSC_53 Pełne testy obejmujące zabezpieczanie danych muszą być przeprowadzane w sposób określony w dodatku 11 "Wspólne mechanizmy zabezpieczenia" przez upoważnione osoby, które mają dostęp do procedur zabezpieczenia, z zastosowaniem standardowych poleceń GET zdefiniowanych powyżej.
DSC_54 Testy przeprowadzane na zlecenie oraz testy w ramach przeglądów okresowych wiążące się z koniecznością odszyfrowania i zrozumienia treści zaszyfrowanych danych przeprowadza się zgodnie z postanowieniami dodatku 11 "Wspólne mechanizmy zabezpieczenia" oraz dodatku 9 "Homologacja typu - wykaz minimalnych wymaganych testów".
Test podstawowej łączności DSRC można jednak przeprowadzić za pomocą polecenia ECHO. Tego rodzaju testy mogą być przeprowadzane na zlecenie, w ramach przeglądów okresowych lub w inny sposób na żądanie właściwego organu kontrolnego lub zgodnie z wymogami określonymi w rozporządzeniu (UE) nr 165/2014 (zob. pkt 6 poniżej).
DSC_55 W celu przeprowadzenia tego podstawowego testu łączności REDCR wydaje polecenie ECHO w trakcie sesji, tj. po pomyślnym zakończeniu etapu inicjacji. Sekwencja czynności jest zatem zbliżona do sekwencji czynności związanych z zapytaniem:
- Etap 1 REDCR wysyła "tabelę usług sygnału" (BST), która zawiera identyfikatory aplikacji (AID) w wykazie obsługiwanych usług. W aplikacji RTM będzie to po prostu usługa z wartością AID = 2.
DSRC-VU oceni otrzymaną BST i jeżeli uzna, że BST żąda danych Freight&Fleet (AID = 2), DSRC-VU udzieli odpowiedzi. Jeżeli REDCR nie oferuje AID=2, DSRC-VU przerywa transakcję z REDCR.
- Krok 2 DSRC-VU wysyła żądanie przydzielenia okna prywatnego.
- Krok 3 REDCR przesyła przydział okna prywatnego.
- Krok 4 DSRC-VU używa przydzielonego okna prywatnego do wysłania swojej tabeli usług pojazdu (VST). Tego rodzaju VST zawiera wykaz wszystkich różnych wystąpień aplikacji obsługiwanych przez ten DSRC-VU w ramach AID=2. Poszczególne wystąpienia są identyfikowane za pomocą jednorazowych identyfikatorów elementu, z których każdy jest powiązany z wartością parametru określającą wystąpienie obsługiwanej aplikacji.
- Krok 5 Następnie REDCR analizuje oferowaną tabelę usług pojazdu i albo przerywa łączność (RELEASE), ponieważ nie jest zainteresowany niczym, co dana VST ma do zaoferowania (tj. otrzymuje VST od DSRC-VU, która nie jest RTM VU), albo - jeżeli otrzymuje odpowiednią tabelę usług pojazdu - uruchamia wystąpienie aplikacji.
- Krok 6 REDCR wydaje polecenie (ECHO) określonemu DSRC-VU i przypisuje okno prywatne.
- Krok 7 DSRC-VU korzysta z nowo przydzielonego okna prywatnego do wysłania ramki odpowiedzi ECHO.
W poniższych tabelach przedstawiono praktyczny przykład sesji wymiany ECHO.
DSC_56 Inicjację przeprowadza się zgodnie z pkt 5.4.7 (DSC_44-DSC_48) oraz tabelami 14.4-14.9.
DSC_57 Następnie REDCR wydaje polecenie ACTION, ECHO zgodnie z normą ISO 14906, zawierającą 100 oktetów danych i bez określonych ustawień RTM. W tabeli 14.15 przedstawiono zawartość ramki wysłanej przez REDCR.
Tabela 14.15
Przykładowa ramka żądania ACTION, ECHO
| Oktet # | Atrybut/Pole | Bity w oktecie | Opis |
| 1 | FLAGA | 0111 1110 | Flaga początkowa |
| 2 | Prywatny LID | xxxx xxxx | Adres łącza określonego DSRC-VU |
| 3 | xxxx xxxx | ||
| 4 | xxxx xxxx | ||
| 5 | xxxx xxxx | ||
| 6 | Pole kontrolne MAC | 1010 s000 | Polecenie PDU |
| 7 | Pole kontrolne LLC | n111 0111 | Wysondowane polecenie ACn, bit n |
| 8 | Nagłówek fragmentacji | 1xxx x001 | Brak fragmentacji |
| 9 | ACTION.request SEQUENCE { | 0000 | Żądanie działania (ECHO) |
| Wskaźnik WARIANTU | 0 | Brak poświadczeń dostępu | |
| Wskaźnik WARIANTU | 1 | Parametr akcji występuje | |
| Wskaźnik WARIANTU | 0 | Brak IID | |
| Tryb BOOLEAN | 1 | Odpowiedź oczekiwana | |
| 10 | EID INTEGER (0..127,...) | 0000 0000 | Brak rozszerzenia, EID = 0 (System) |
| 11 | ActionType INTEGER (0..127,...) | 0000 1111 | Brak rozszerzenia, typ działania: żądanie ECHO |
| 12 | ActionParameter CONTAINER { | 0000 0010 | Brak rozszerzenia, wybór kontenera = 2 |
| 13 | 0110 0100 | Brak rozszerzenia. Długość ciągu = 100 oktetów | |
| 14 | xxxx xxxx | Dane, które mają być powtórzone | |
| ... | ... | ||
| 113 | }} | xxxx xxxx | |
| 11-46-14 | FCS | xxxx xxxx | Sekwencja kontroli ramki |
| 11-57-15 | xxxx xxxx | ||
| 11-68-16 | Flaga | 0111 1110 | Flaga końcowa |
DSC_58 Po otrzymaniu żądania ECHO DSRC-VU wysyła odpowiedź ECHO o długości 100 oktetów danych, odzwierciedlając otrzymane polecenie, zgodnie z normą ISO 14906, bez określonych ustawień RTM. W tabeli 14.16 przedstawiono przykład szyfrowania na poziomie bitów.
Tabela 14.16
Przykładowa ramka żądania ACTION, ECHO
| Oktet # | Atrybut/Pole | Bity w oktecie | Opis |
| 1 | FLAGA | 0111 1110 | Flaga początkowa |
| 2 | Prywatny LID | xxxx xxxx | Adres łącza określonego VU |
| 3 | xxxx xxxx | ||
| 4 | xxxx xxxx | ||
| 5 | xxxx xxxx | ||
| 6 | Pole kontrolne MAC | 1101 0000 | Odpowiedź PDU |
| 7 | Pole kontrolne LLC | n111 0111 | Polecenie ACn, bit n |
| 8 | Pole stanu LLC | 0000 0000 | Odpowiedź dostępna |
| 9 | Nagłówek fragmentacji | 1xxx x001 | Brak fragmentacji |
| 10 | ACTION.response SEQUENCE { | 0001 | Odpowiedź na DZIAŁANIE (ECHO) |
| Wskaźnik WARIANTU | 0 | Brak IID | |
| Wskaźnik WARIANTU | 1 | Parametr odpowiedzi występuje | |
| Wskaźnik WARIANTU | 0 | Status zwrotu nie występuje | |
| Wypełnienie CIĄG BITÓW (ROZMIAR (1)) | 0 | Nieużywany | |
| 11 | EID INTEGER (0..127,...) | 0000 0000 | Brak rozszerzenia, EID = 0 (System) |
| 12 | KONTENER ResponseParameter { | 0000 0010 | Brak rozszerzenia, wybór kontenera = 2 |
| 13 | 0110 0100 | Brak rozszerzenia. Długość ciągu = 100 oktetów | |
| 14 | xxxx xxxx | Powtórzone dane | |
| ... | ... | ||
| 113 | }} | xxxx xxxx | |
| 114 | FCS | xxxx xxxx | Sekwencja kontroli ramki |
| 115 | xxxx xxxx | ||
| 116 | Flaga | 0111 1110 | Flaga końcowa |
5.5 Zarezerwowane dla przyszłego użytku
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.
5.5.2 Polecenia
DSC_60 Polecenia stosowane w odniesieniu do transakcji OWS będą takie same jak polecenia stosowane w odniesieniu do transakcji RTM.
5.5.3 Sekwencja polecenia zapytania
DSC_61 Sekwencja polecenia zapytania w przypadku danych OWS będzie taka sama jak w przypadku danych dotyczących zdalnego monitorowania tachografu.
5.5.4 Struktury danych
DSC_62 Ładunek (dane OWS) składa się z połączenia:
1. danych EncryptedOwsPayload stanowiących zaszyfrowane dane OwsPayload określone w specyfikacji ASN.1 w sekcji 5.5.5. Metoda szyfrowania jest taka sama jak metoda przyjęta w odniesieniu do RtmData, które określono w dodatku 11;
2. DSRCSecurityData obliczone za pomocą tych samych algorytmów przyjętych w odniesieniu do RtmData, które określono w dodatku 11.
5.5.5 Moduł ASN.1 w odniesieniu do transakcji DSRC dotyczącej OWS
DSC_63. Zawarta w module ASN.1 definicja danych DSRC w ramach aplikacji RTM jest następująca:
5.5.6 Elementy OwsData, wykonywane czynności i definicje
Elementy OwsData zdefiniowano, aby zapewnić wsparcie wdrażania dyrektywy 2015/719/WE w sprawie maksymalnych obciążeń i wymiarów pojazdów ciężarowych. Ich znaczenie jest następujące:
- recordedWeight oznacza całkowite zmierzone obciążenie pojazdu ciężarowego z dokładnością do 10 kg, jak określono w normie EN ISO 14906. Na przykład wartość 2 500 odpowiada obciążeniu wynoszącemu 25 ton;
- axlesConfiguration oznacza konfigurację pojazdu ciężarowego jako liczbę osi. Konfigurację określa się za pomocą maski bitów składającej się z 20 bitów (wersja rozszerzona z normy EN ISO 14906).
Maska bitów składająca się z 2 bitów odpowiada konfiguracji osi o następującym formacie:
- wartość 00B oznacza, że wartość jest "niedostępna", ponieważ pojazd nie posiada sprzętu do gromadzenia obciążenia na osi;
- wartość 01B oznacza, że oś nie występuje;
- wartość 10B oznacza, że oś występuje oraz że obciążenie zostało obliczone i zgromadzone oraz jest podane w polu axlesRecordedWeight;
- wartość 11B jest zarezerwowana do wykorzystania w przyszłości.
Ostatnie cztery bity są zarezerwowane do wykorzystania w przyszłości.
| Liczba osi | ||
| Liczba osi na ciągniku | Liczba osi na przyczepie | |
| 00/01/ 10/11 | 00/01/ 10/11 | 00/01/ 10/11 | 00/01/ 10/11 | 00/01/ 10/11 | 00/01/ 10/11 | 00/01/ 10/11 | 00/01/ 10/11 | 00/01/ 10/11 | 00/01/ 10/11 | RFU (4 bity) |
- axlesRecordedWeight oznacza określone obciążenie zarejestrowane dla każdej osi z dokładnością do 10 kg. W odniesieniu do każdej osi stosuje się dwa oktety. Na przykład wartość 150 oznacza obciążenie wynoszące 1 500 kg.
Inne rodzaje danych określono w pkt 5.4.5.
5.5.7 Mechanizmy przesyłania danych
DSC_64 Mechanizm przesyłania danych OWS pomiędzy interrogatorem a urządzeniem DSRC w pojeździe jest taki sam jak w przypadku danych RTM (zob. pkt 5.4.6).
DSC_65 Przesyłanie danych pomiędzy platformą zbierającą dane na temat maksymalnego obciążenia a urządzeniem DSRC w pojeździe opiera się na fizycznym połączeniu oraz interfejsach i protokole określonym w sekcji 5.6.
5.6 Przesyłanie danych pomiędzy DSRC-VU a VU
5.6.1 Połączenie fizyczne i interfejsy
DSC_66 Połączenie między VU a DSRC-VU może odbywać się za pomocą fizycznego okablowania lub łączności bezprzewodowej o krótkim zasięgu opartej na technologii Bluetooth v4.0 BLE.
DSC_67 Niezależnie od wybranego fizycznego połączenia i interfejsu następujące wymogi muszą być spełnione:
DSC_68 a) aby można było zawierać umowy z różnymi dostawcami na dostawę VU i DSRC-VU oraz w praktyce różnych serii DSRC-VU, połączenie między VU a DSRC-VU niebędącym elementem wewnętrznym VU musi być otwartym połączeniem standardowym. VU musi być połączony z DSRC-VU za pomocą:
(i) zamontowanego na stałe kabla o długości co najmniej 2 metrów z wykorzystaniem łącznika Straight DIN 41612 H11 - 11-biegunowego zatwierdzonego wtyku z DSRC-VU w celu dopasowania do podobnego gniazda zatwierdzonego przez DIN/ISO z urządzenia VU albo
(ii) technologii Bluetooth Low Energy (BLE) albo
(iii) standardowego połączenia określonego w ISO 11898 lub SAE J1939,
DSC_69 b) definicja interfejsów i połączenia między VU i DSRC-VU musi obsługiwać polecenia protokołu aplikacji zdefiniowane w pkt 5.6.2 oraz
DSC_70 c) VU i DSRC-VU muszą obsługiwać operację przesyłania danych za pośrednictwem połączenia w odniesieniu do wydajności i zasilania.
5.6.2 Protokół aplikacji
DSC_71 Protokół aplikacji między urządzeniem do łączności na odległość w VU a DSRC-VU jest odpowiedzialny za okresowe przesyłanie danych dotyczących łączności na odległość z VU do DSRC.
DSC_72 Określono następujące polecenia główne:
1. Inicjacja łącza komunikacyjnego - żądanie
2. Inicjacja łącza komunikacyjnego - odpowiedź
3. Wysyłanie danych z identyfikatorem aplikacji RTM i ładunkiem określonym przez dane RTM
4. Potwierdzenie danych
5. Zamknięcie łącza komunikacyjnego - żądanie
6. Zamknięcie łącza komunikacyjnego - odpowiedź
DSC_73 W module ASN1.0 wcześniejsze polecenia można zdefiniować w następujący sposób:
DSC_74 Opis poleceń i parametrów jest następujący:
- RCDT-Communication Link Initialization - Request stosuje się w celu zainicjowania łącza komunikacyjnego. Polecenie jest wysyłane przez VU do DSRC-VU. VU ustanawia LinkIden-tifier i przekazuje DSRC-VU w celu śledzenia określonego łącza komunikacyjnego.
(Uwaga: służy to obsłudze przyszłych łączy i innych aplikacji/modułów takich jak system ważenia w pojeździe);
- RCDT-Communication Link Initialization - Response jest stosowane przez DSRC-VU w celu dostarczenia odpowiedzi na żądanie zainicjowania łącza komunikacyjnego. Polecenie jest wysyłane przez DSRC-VU do VU. Polecenie przekazuje wynik inicjacji w formie odpowiedzi = 1 (Sukces) lub = 0 (Niepowodzenie).
DSC_75 Zainicjowanie łącza komunikacyjnego następuje dopiero po zainstalowaniu, kalibracji i uruchomieniu silnika/VU.
- RCDT-Send Data jest stosowane przez VU do przesyłania podpisanych RCDTData (tj. danych dotyczących łączności na odległość) do DSRC-VU. Dane będą wysyłane co 60 sekund. Parametr DataTransactionId identyfikuje określoną transmisję danych. LinkIdentifier wykorzystuje się także do upewnienia się, że łącze jest prawidłowe;
- RCDT-Data Acknowledgment jest wysyłane przez DSRC-VU w celu dostarczenia VU informacji zwrotnej dotyczącej odbioru danych z polecenia RCDT-Send Data określonego przez parametr DataTransactionId. Parametr odpowiedzi to 1 (Sukces) lub =0 (Niepowodzenie). Jeżeli VU otrzyma więcej niż trzy odpowiedzi równe 0 lub jeżeli VU nie otrzyma komunikatu RCDT Data Acknowledgment w odniesieniu do konkretnego wysłanego wcześniej polecenia z określonym DataTransactionId, VU wygeneruje i zarejestruje zdarzenie;
- RCDT-Communication Link Termination request komunikat jest wysyłane przez VU do DSRC-VU w celu zakończenia łącza w odniesieniu do konkretnego LinkIdentifier.
DSC_76 Po ponownym uruchomieniu DSRC-VU lub VU wszystkie istniejące łącza komunikacyjne należy usunąć, ponieważ w związku z nagłym zamknięciem VU mogą wystąpić "zawieszone" łącza.
- RCDT-Communication Link Termination - Response jest wysyłane przez DSRC-VU do VU w celu potwierdzenia żądania zakończenia łącza przez VU w odniesieniu do konkretnego LinkIdentifier.
5.7 Obsługa błędów
5.7.1 Rejestrowanie i przekazywanie danych w DSRC-VU
DSC_77 Już zabezpieczone Dane są przekazywane DSRC-VU za pomocą funkcji VUSM. VUSM sprawdza, czy dane zarejestrowane w DSRC-VU zostały z powodzeniem przesłane do DSRC-VU. Rejestrowanie i zgłaszanie wszelkich błędów, jakie wystąpiły podczas przesyłania danych z VU do pamięci DSRC-VU, odbywa się przy użyciu zdarzenia typu EventFaultType z wartością enum ustawioną na '0C'H Błąd łączności z urządzeniem do łączności na odległość wraz ze znacznikiem czasu. VUSM sprawdza, czy dane zostały z powodzeniem przesłane do DSRC-VU.
DSC_78 Zarezerwowane dla przyszłego użytku.
DSC_79 Jeżeli VUPM próbuje uzyskać dane VU z modułu zabezpieczeń (w celu przejścia do urządzenia VU-DSRC), ale kończy się to niepowodzeniem, wówczas rejestruje takie niepowodzenie jako zdarzenie typu EventFaultType z wartością enum '62'H Błąd łączności z urządzeniem do łączności na odległość wraz ze znacznikiem czasu. Błąd związany z łącznością zostaje wykryty w przypadku nieotrzymania komunikatu RCDT Data Acknowledgment dotyczącego powiązanego (tj. z tym samym DataTransactionId w komunikatach Send Data i Acknowledgment) komunikatu komunicatu RCDT Send Data więcej niż trzy razy z rzędu.
5.7.2 Błędy łączności bezprzewodowej
DSC_80 Obsługa błędów związanych z łącznością jest zgodna z powiązanymi normami dotyczącymi DSRC, mianowicie EN 300 674-1, EN 12253, EN 12795, EN 12834 i odpowiednimi parametrami normy EN 13372.
5.7.2.1 Błędy szyfrowania i błędy podpisu
DSC_81 Błędy szyfrowania i podpisu obsługuje się zgodnie z dodatkiem 11 "Wspólne mechanizmy zabezpieczenia", przy czym błędy te nie występują w żadnych komunikatach o błędzie związanych z przesyłaniem danych DSRC.
5.7.2.2 Rejestrowanie błędów
Urządzenie DSRC umożliwia dynamiczną łączność bezprzewodową w środowisku z niepewnymi warunkami atmosferycznymi i zakłóceniami, zwłaszcza w przypadku kombinacji "przenośny REDCR" i "pojazd w ruchu" występujących w tej aplikacji. Konieczne jest zatem ustalenie różnicy między "niepowodzeniem odczytu" a "błędem". Podczas transakcji zachodzącej przez interfejs bezprzewodowy niepowodzenie odczytu jest zjawiskiem powszechnym, a jego skutkiem jest zwykle ponowienie próby, tj. reemisja BST i ponowna próba sekwencji, które w większości przypadków doprowadzą do skutecznego nawiązania łączności i przesłania danych, chyba że docelowy pojazd wyjedzie poza zasięg urządzenia w czasie wymaganym do przeprowadzenia ponownej transmisji. (Przypadek "skutecznego odczytu" może obejmować kilka prób i ponowień).
Niepowodzenie odczytu może być spowodowane niewłaściwym sparowaniem anteny (błąd "celowania"); faktem, że jedna z anten jest zasłonięta - może to być celowe, ale może być też spowodowane fizyczną obecnością innego pojazdu; zakłóceniami radiowymi, szczególnie w systemie łączności bezprzewodowej działającym na częstotliwości około 5,8 GHz lub w innych systemach publicznej łączności bezprzewodowej lub może być spowodowane zakłóceniem radarowym lub trudnymi warunkami atmosferycznymi (np. w trakcie burzy); lub po prostu faktem, że pojazd wyjechał poza obszar objęty zasięgiem łączności DSRC. Poszczególnych przypadków niepowodzenia odczytu, ze względu na ich charakter, nie można zarejestrować po prostu dlatego, że nie doszło do nawiązania łączności.
Jeżeli przedstawiciel właściwego organu kontrolnego wybiera pojazd i podejmuje próbę skierowania zapytania do jego DSRC-VU, jednak nie dochodzi do skutecznego przesłania danych, usterka taka mogła nastąpić w wyniku celowego manipulowania, w związku z czym przedstawiciel właściwego organu kontrolnego potrzebuje środka, aby móc wprowadzić usterkę do rejestru i ostrzec współpracowników znajdujących się na dalszym etapie łańcucha o możliwym naruszeniu. Współpracownicy mogą wówczas zatrzymać pojazd i przeprowadzić kontrolę fizyczną. W związku z tym, że nie nawiązano łączności, DSRC-VU nie może jednak dostarczyć danych dotyczących usterki. Przekazywanie tego rodzaju sprawozdań powinno być zatem funkcją projektu urządzenia REDCR.
"Niepowodzenie odczytu" różni się pod względem technicznym od "błędu". W tym kontekście "błąd" oznacza pozyskanie błędnej wartości.
Dane przesłane do DSRC-VU są dostarczane w postaci już zabezpieczonej, dlatego muszą zostać zweryfikowane przez dostawcę danych (zob. pkt 5.4).
Dane przesłane następnie przez interfejs radiowy są sprawdzane w ramach cyklicznej kontroli nadmiarowej na poziomie łączności. Jeżeli dane zostaną zatwierdzone w ramach CRC, oznacza to, że są poprawne. Jeżeli dane nie zostaną zatwierdzone w ramach CRC, oznacza to retransmisję danych. Prawdopodobieństwo, że niepoprawne dane pomyślnie przejdą CRC, jest statystycznie na tyle znikome, że można je pominąć.
Jeżeli dane nie zostaną zatwierdzone w ramach CRC i nie ma czasu na retransmisję i otrzymanie poprawnych danych, wówczas rezultatem nie będzie błąd, lecz wystąpienie określonego typu niepowodzenia odczytu.
Jedyne znaczące dane na temat "usterki", które można zarejestrować, dotyczą liczby udanych inicjacji transakcji, które z kolei nie skutkują skutecznym przesłaniem danych do REDCR.
DSC_82 REDCR rejestruje zatem z sygnaturą czasową liczbę przypadków, gdy faza "inicjowania" zapytania DSRC przebiegła pomyślnie, ale transakcja zakończyła się, zanim REDCR pomyślnie pobrał Dane. Dane te są udostępniane przedstawicielowi właściwego organu kontrolnego i przechowywane w pamięci urządzenia REDCR. Środkiem pozwalającym na osiągnięcie tego celu jest kwestia projektu produktu lub specyfikacja właściwego organu kontrolnego.
Jedyne znaczące dane na temat "błędów", które można zarejestrować, dotyczą liczby przypadków, gdy REDCR nie udało się deszyfrować otrzymanych Danych. Należy jednak zauważyć, że będzie to dotyczyło wyłącznie wydajności oprogramowania REDCR. Dane można technicznie deszyfrować, ale będą pozbawione sensu pod względem semantycznym.
DSC_83 REDCR rejestruje zatem z sygnaturą czasową liczbę podjętych prób deszyfrowania danych otrzymanych przez interfejs DSRC, które zakończyły się niepowodzeniem.
6 TESTY PRZEPROWADZANE PRZY ODDANIU DO EKSPLOATACJI ORAZ TESTY W RAMACH PRZEGLĄDÓW OKRESOWYCH FUNKCJI ŁĄCZNOŚCI NA ODLEGŁOŚĆ
6.1 Uwagi ogólne
DSC_84 Przewiduje się dwa rodzaje testów w odniesieniu do funkcji łączności na odległość:
1) test ECHO w celu zatwierdzania kanału łączności bezprzewodowej DSRC-REDCR >>-:-<DSRC-VU;
2) test bezpieczeństwa typu end-to-end przeprowadzany w celu zapewnienia, aby karta warsztatowa była w stanie uzyskać dostęp do zaszyfrowanych i podpisanych danych utworzonych przez VU i przesyłanych za pośrednictwem kanału komunikacji bezprzewodowej.
6.2 ECHO
Niniejsza klauzula zawiera postanowienia, które mają służyć wyłącznie sprawdzeniu, czy połączenie DSRC-REDCR >>-:-<DSRC-VU jest aktywne.
Celem polecenia ECHO jest umożliwienie warsztatom lub placówkom przeprowadzających testy na potrzeby homologacji typu zbadania, czy połączenie DSRC działa bez konieczności dostępu do poświadczeń zabezpieczenia; Urządzenie testera musi być jedynie w stanie zainicjować łączność DSRC (wysłanie BST z AID=2), a następnie wysłać polecenie ECHO i - zakładając, że DSRC pracuje - otrzymać odpowiedź ECHO. Więcej szczegółowych informacji można znaleźć w pkt 5.4.8. Zakładając, że otrzyma tę odpowiedź prawidłowo, łącze DSRC (DSRC-REDCR >>-:-<DSRC-VU) można zatwierdzić jako funkcjonujące poprawnie.
6.3 Testy mające na celu zatwierdzanie treści zabezpieczonych danych
DSC_85 Tego rodzaju test wykonuje się w celu zatwierdzenia bezpiecznych przepływów danych typu end-to-end. Do przeprowadzenia takiego testu niezbędny jest czytnik testowy DSRC. Czytnik testowy DSRC wykonuje te same funkcje i jest wdrażany z tą samą specyfikacją co czytnik wykorzystywany przez przedstawiciela organów ścigania z taką różnicą, że to karta warsztatowa jest wykorzystywana do uwierzytelniania użytkownika czytnika testowego DSRC, a nie karta kontrolna. Test można przeprowadzić po początkowej aktywacji tachografu inteligentnego lub pod koniec procedury kalibracji. Po aktywacji przyrząd rejestrujący generuje zabezpieczone dane dotyczące wczesnego wykrywania i przekazuje je do DSRC-VU.
DSC_86 Pracownicy warsztatu muszą umieścić czytnik testowy DSRC w odległości od 2 do 10 m od przodu pojazdu.
DSC_87 Następnie pracownicy warsztatu włożą kartę warsztatową do czytnika testowego DSRC w celu przekazania przyrządowi rejestrującemu zapytania o przekazanie danych dotyczących wczesnego wykrywania. Po pomyślnym zapytaniu pracownicy warsztatu uzyskają dostęp do otrzymanych danych w celu upewnienia się, że zostały one pomyślnie zatwierdzone pod względem integralności i deszyfrowane.
Addendum
Zasady obliczania dziennego, tygodniowego i dwutygodniowego czasu prowadzenia pojazdu
1. Podstawowe zasady dokonywania obliczeń
VU oblicza dzienny czas prowadzenia pojazdu, tygodniowy czas prowadzenia pojazdu i dwutygodniowy czas prowadzenia pojazdu z wykorzystaniem odpowiednich danych zapisanych na karcie kierowcy (lub warsztatowej) włożonej do szczeliny czytnika karty kierowcy (szczelina 1, czytnik karty #1) przyrządu rejestrującego oraz wybranych czynności kierowcy w okresie, w którym karta ta pozostaje włożona do VU.
Czasów prowadzenia pojazdu nie wlicza się, gdy żadna karta kierowcy (lub warsztatowa) nie jest włożona.
Wszystkie okresy NIEOKREŚLONE wykryte w obrębie okresu potrzebnego do obliczeń zalicza się do okresu PRZERWA/ODPOCZYNEK.
Nie uwzględnia się NIEOKREŚLONYCH okresów oraz czynności o ujemnym czasie trwania (tzn. gdy początek czynności następuje później niż koniec czynności) wynikających z nakładania się czasów dwóch różnych przyrządów rejestrujących lub z korekty czasu.
Czynności zarejestrowane na karcie kierowcy odpowiadające okresom »POZA ZAKRESEMS«, zgodnie z definicją w lit. gg) w załączniku IC, interpretuje się w następujący sposób:
- Okresy PRZERWA/ODPOCZYNEK liczy się jak »PRZERWĘ« lub »ODPOCZYNEK«.
- Okresy PRACA i PROWADZENIE uznaje się za »PRACĘ«.
- Okres GOTOWOŚĆ uznaje się za »GOTOWOŚĆ«.
W kontekście niniejszego addendum VU zakłada dzienny okres odpoczynku na początku rekordów czynności na karcie.
2. Pojęcia
Poniższe pojęcia mają zastosowanie wyłącznie do niniejszego dodatku i mają na celu określenie sposobu obliczania przez VU czasu prowadzenia pojazdu i jego późniejszej transmisji przez urządzenie łączności na odległość.
a) »zmiana RTM« oznacza okres między końcem danego dziennego okresu odpoczynku a końcem bezpośrednio następującego po nim dziennego okresu odpoczynku.
VU uruchamia nową zmianę RTM po zakończeniu dziennego okresu odpoczynku.
Trwająca zmiana RTM jest okresem od końca ostatniego dziennego okresu odpoczynku;
b) »skumulowany czas prowadzenia pojazdu« oznacza sumę czasu trwania wszystkich czynności PROWADZENIA wykonywanych przez kierowcę w okresie innym niż okres stanu POZA ZAKRESEM;
c) »dzienny czas prowadzenia pojazdu« oznacza skumulowany czas prowadzenia pojazdu w ramach zmiany RTM;
d) »tygodniowy czas prowadzenia pojazdu« oznacza skumulowany czas prowadzenia pojazdu w trwającym tygodniu;
e) »nieprzerwany okres odpoczynku« oznacza nieprzerwany okres PRZERWA/ODPOCZYNEK;
f) »tygodniowy czas prowadzenia pojazdu« oznacza skumulowany czas prowadzenia pojazdu w poprzednim i trwającym tygodniu;
g) »dzienny okres odpoczynku« oznacza okres PRZERWA/ODPOCZYNEK, który może być:
- regularnym dziennym okresem odpoczynku,
- dzielonym dziennym okresem odpoczynku lub
- skróconym dziennym okresem odpoczynku.
W kontekście dodatku 14, gdy VU oblicza tygodniowe okresy odpoczynku, okresy te uznaje się za dzienne okresy odpoczynku;
h) »regularny dzienny okres odpoczynku« oznacza nieprzerwany okres odpoczynku trwający co najmniej 11 godzin.
W drodze wyjątku, jeżeli stan PRZEPRAWA PROMOWA/POCIĄGOWA jest aktywny, to regularny dzienny okres odpoczynku może zostać przerwany maksymalnie dwa razy czynnościami innymi niż odpoczynek, o maksymalnym skumulowanym czasie trwania wynoszącym jedną godzinę, tzn. regularny dzienny okres odpoczynku zawierający okresy przepraw promowych/pociągowych można podzielić na dwie lub trzy części. VU zlicza następnie regularny dzienny okres odpoczynku, gdy skumulowany czas odpoczynku obliczony zgodnie z pkt 3 wynosi co najmniej 11 godzin.
W przypadku przerwania regularnego dziennego okresu odpoczynku przyrząd rejestrujący:
- nie uwzględnia czynności prowadzenia pojazdu zaistniałych podczas tych przerw w obliczeniach dziennego czasu prowadzenia pojazdu oraz
- rozpoczyna nową zmianę RTM z końcem regularnego dziennego okresu odpoczynku, który został przerwany.
Rysunek 1.
Przykład dziennego okresu odpoczynku przerwanego w związku z przeprawą promową/ pociągową
i) »skrócony dzienny okres odpoczynku« oznacza nieprzerwany okres odpoczynku trwający co najmniej 9 godzin, ale mniej niż 11 godzin;
j) »dzielony dzienny okres odpoczynku« oznacza dzienny okres odpoczynku wykorzystywany w dwóch częściach:
- pierwsza część to nieprzerwany okres odpoczynku trwający co najmniej 3 godziny, ale mniej niż 9 godzin;
- druga część to nieprzerwany okres odpoczynku trwający co najmniej 9 godzin.
W drodze wyjątku, jeżeli stan PRZEPRAWA PROMOWA/POCIĄGOWA jest aktywny podczas jednej lub obu części dzielonego dziennego okresu odpoczynku, okres ten może zostać przerwany maksymalnie dwa razy czynnościami innymi niż odpoczynek, o maksymalnym skumulowanym czasie trwania wynoszącym jedną godzinę, tzn.:
- pierwszą część dzielonego dziennego okresu odpoczynku można przerwać jeden raz bądź dwa razy lub
- drugą część dzielonego dziennego okresu odpoczynku można przerwać jeden raz bądź dwa razy lub
- pierwszą część dzielonego dziennego okresu odpoczynku można przerwać jeden raz i drugą część dzielonego dziennego okresu odpoczynku można przerwać jeden raz.
VU zlicza następnie dzielony dzienny okres odpoczynku, gdy skumulowany czas odpoczynku obliczony zgodnie z pkt 3 wynosi:
- co najmniej trzy godziny, ale mniej niż 11 godzin dla pierwszego okresu odpoczynku, oraz co najmniej 9 godzin dla drugiego okresu odpoczynku, jeżeli pierwszy okres odpoczynku został przerwany przez PRZEPRAWĘ PROMOWĄ/POCIĄGOWĄ;
- co najmniej trzy godziny, ale mniej niż 9 godzin dla pierwszego okresu odpoczynku, oraz co najmniej 9 godzin dla drugiego okresu odpoczynku, jeżeli pierwszy okres odpoczynku nie został przerwany przez PRZEPRAWĘ PROMOWĄ/POCIĄGOWĄ.
Rysunek 2.
Przykład dzielonego dziennego okresu odpoczynku przerwanego w związku z przeprawą promową/pociągową
W przypadku dzielonego dziennego okresu odpoczynku przyrząd rejestrujący:
- nie uwzględnia czynności prowadzenia pojazdu zaistniałych podczas tych przerw w obliczeniach dziennego czasu prowadzenia pojazdu oraz
- rozpoczyna nową zmianę RTM z końcem dzielonego dziennego okresu odpoczynku, który został przerwany;
k) »tydzień« oznacza okres w czasie UTC od godz. 00.00 w poniedziałek do godz. 24:00 w niedzielę.
3. Obliczanie dziennego okresu odpoczynku przerwanego w związku z przeprawą promową/pociągową
W celu obliczenia okresu odpoczynku, który został przerwany w związku z przeprawą promową/pociągową, VU liczy skumulowany czas odpoczynku zgodnie z następującymi krokami:
a) Krok 1
VU wykrywa przerwy w czasie odpoczynku, które wystąpiły przed aktywacją flagi PRZEPRAWA PRO- MOWA/POCIĄGOWA (POCZĄTEK), zgodnie z rys. 3 i w stosownych przypadkach rys. 4, oraz ocenia w odniesieniu do każdej wykrytej przerwy, czy spełnione są następujące warunki:
- przerwa powoduje, że całkowity czas trwania wykrytych przerw, w tym w stosownych przypadkach przerw następujących w trakcie pierwszej części dzielonego dziennego okresu odpoczynku w związku z przeprawą promową/pociągową, przekracza łącznie ponad jedną godzinę,
- przerwa powoduje, że całkowita liczba wykrytych przerw, w tym w stosownych przypadkach przerw następujących w trakcie pierwszej części dzielonego dziennego okresu odpoczynku w związku z przeprawą promową/pociągową, jest wyższa niż dwa,
- po zakończeniu przerwy przechowywany jest »Wpis miejsca zakończenia dziennego okresu pracy«.
Jeżeli żaden z powyższych warunków nie jest spełniony, nieprzerwany okres odpoczynku bezpośrednio poprzedzający przerwę dodaje się do skumulowanego czasu odpoczynku.
Jeżeli spełniony jest co najmniej jeden z powyższych warunków, VU musi zatrzymać obliczanie skumulowanego czasu odpoczynku zgodnie z krokiem 2 lub wykryć przerwy w czasie odpoczynku następujące po fladze PRZEPRAWA PROMOWA/POCIĄGOWA (POCZĄTEK) zgodnie z krokiem 3.
b) Krok 2
W odniesieniu do każdej przerwy wykrytej zgodnie z krokiem 1 VU ocenia, czy należy zaprzestać obliczania skumulowanego czasu odpoczynku. VU zatrzymuje proces obliczeniowy, jeżeli do skumulowanego czasu odpoczynku dodano dwa okresy nieprzerwanego odpoczynku, które nastąpiły przed aktywacją flagi PRZEPRAWA PROMOWA/POCIĄGOWA (POCZĄTEK), w tym w stosownych przypadkach okresy odpoczynku dodane do pierwszej części dzielonego dziennego okresu odpoczynku również przerwanego w związku z przeprawą promową/pociągową. W przeciwnym razie VU postępuje zgodnie z krokiem 3.
c) Krok 3
Jeżeli po wykonaniu kroku 2 VU kontynuuje obliczanie skumulowanego czasu odpoczynku, wykrywa przerwy następujące po dezaktywacji stanu PRZEPRAWA PROMOWA/POCIĄGOWA zgodnie z rys. 3 i w stosownych przypadkach rys. 4.
W odniesieniu do każdej wykrytej przerwy VU ocenia, czy przerwa powoduje, że całkowity czas wszystkich wykrytych przerw przekracza łącznie ponad jedną godzinę, w którym to przypadku obliczanie skumulowanego okresu odpoczynku ustaje z końcem nieprzerwanego okresu odpoczynku poprzedzającego przerwę. W przeciwnym razie do obliczeń dziennego okresu odpoczynku dodaje się nieprzerwane okresy odpoczynku następujące po odpowiednich przerwach, aż do spełnienia warunku z kroku 4.
d) Krok 4
Obliczanie skumulowanego czasu odpoczynku zatrzymuje się po dodaniu przez VU, w rezultacie zastosowania kroków 1 i 3, maksymalnie dwóch nieprzerwanych okresów odpoczynku do okresu odpoczynku, w odniesieniu do którego aktywowany jest stan PRZEPRAWA PROMOWA/POCIĄGOWA, w tym w stosownych przypadkach przerw następujących w trakcie pierwszej części dzielonego dziennego okresu odpoczynku w związku z przeprawą promową/pociągową.
Rysunek 3.
Przetwarzanie czasów odpoczynku przez VU w celu ustalenia, czy przerwany okres odpoczynku liczy się jako regularny dzienny okres odpoczynku, czy jako pierwszą część dzielonego dziennego okresu odpoczynku
Rysunek 4.
Przetwarzanie czasów odpoczynku przez VU w celu ustalenia, czy przerwany okres odpoczynku liczy się jako drugą część dzielonego dziennego okresu odpoczynku
Rysunek 5.
Przykład dziennego okresu odpoczynku przerwanego więcej niż dwukrotnie, co powoduje, że okresu odpoczynku H nie uwzględnia się w obliczeniach
Rysunek 6.
Przykład dziennego okresu odpoczynku, w którym okres obliczeniowy prom/pociąg rozpoczyna się z końcem okresu pracy
Rysunek 7.
Przykład dziennego okresu odpoczynku przerwanego więcej niż dwukrotnie, co powoduje, że okresu odpoczynku B nie uwzględnia się w obliczeniach
Rysunek 8.
Przykład dzielonego dziennego okresu odpoczynku przerwanego jeden raz w trakcie pierwszego okresu odpoczynku i jeden raz w trakcie drugiego okresu odpoczynku
4. Obliczanie dziennego, tygodniowego i dwutygodniowego czasu prowadzenia pojazdu
VU oblicza dzienne czasy prowadzenia pojazdu dla trwających i poprzednich zmian RTM. Czasu prowadzenia pojazdu następującego podczas przerw w dziennych okresach odpoczynku nie dodaje się do obliczeń dziennego czasu prowadzenia pojazdu, jeżeli takie przerwy wynikają z przeprawy promowej/pociągowej, a wymogi określone w pkt 2 lit. h) i j) oraz w pkt 3 zostały spełnione. Niemniej jednak, o ile VU nie policzył pełnego regularnego lub dzielonego dziennego okresu odpoczynku zgodnie z pkt 3, czasy prowadzenia pojazdu następujące podczas przerw dodaje się do dziennego czasu prowadzenia pojazdu dla trwającej zmiany RTM.
VU liczy również tygodniowe i dwutygodniowe czasy prowadzenia pojazdu. Czas prowadzenia pojazdu następujący podczas przerw w dziennych okresach odpoczynku wynikających z przeprawy promowej/pociągowej dodaje się do obliczeń tygodniowych i dwutygodniowych czasów prowadzenia pojazdu.
Dodatek 15 37
MIGRACJA: ZARZĄDZANIE WSPÓŁISTNIENIEM GENERACJI URZĄDZEŃ
MIGRACJA: ZARZĄDZANIE WSPÓŁISTNIENIEM GENERACJI URZĄDZEŃ
1. DEFINICJE ............................................................................................................................................
2. PRZEPISY OGÓLNE ........................................................................................................
2.1. Informacje ogólne na temat przejścia ...................................................................................
2.2. Interoperacyjność między VU a kartami..............................................................................
2.3. Interoperacyjność między VU a czujnikami ruchu .................................................................
2.4. Interoperacyjność między przyrządami rejestrującymi, kartami do tachografu i urządzeniami służącymi do pobierania danych ...........................................................................................
2.4.1 Bezpośrednie pobieranie danych z karty przez inteligentne urządzenia dedykowane ...............
2.4.2 Pobieranie danych z karty za pomocą przyrządu rejestrującego ............................................
2.4.3 Pobieranie danych z przyrządów rejestrujących ....................................................................
2.5. Interoperacyjność między VU a urządzeniami do kalibracji ...................................................
3. GŁÓWNE DZIAŁANIA W OKRESIE POPRZEDZAJĄCYM DATĘ WPROWADZENIA ..........................................................................................................
4. PRZEPISY DOTYCZĄCE OKRESU PO DACIE WPROWADZENIA ...........................
5. REJESTROWANIE PRZEKROCZEŃ GRANICY W TACHOGRAFACH PIERWSZEJ GENERACJI I PIERWSZEJ WERSJI DRUGIEJ GENERACJI
1. DEFINICJE
Do celów niniejszego dodatku stosuje się następujące definicje:
system tachografu inteligentnego: zgodnie z definicją zawartą w niniejszym załączniku (rozdział 1: definicja bbb));
system tachografu pierwszej generacji: zgodnie z definicją zawartą w niniejszym rozporządzeniu (art. 2: definicja 1));
system tachografu drugiej generacji: zgodnie z definicją zawartą w niniejszym rozporządzeniu (art. 2: definicja 7));
data wprowadzenia: zgodnie z definicją zawartą w niniejszym załączniku (rozdział 1: definicja ccc));
inteligentne urządzenie dedykowane (IDE): urządzenie służące do przeprowadzania operacji pobierania danych, zgodnie z definicją zawartą w dodatku 7 do niniejszego załącznika.
2. PRZEPISY OGÓLNE
2.1. Informacje ogólne na temat przejścia
Wprowadzenie do niniejszego załącznika zawiera ogólne informacje na temat przejścia między systemami tachografu pierwszej i drugiej generacji oraz wprowadzenia drugiej wersji drugiej generacji urządzeń rejestrujących i kart do tachografów.
Oprócz przepisów zawartych w tym wprowadzeniu należy przypomnieć następujące informacje:
- czujniki ruchu pierwszej generacji nie są interoperacyjne z żadną wersją przyrządów rejestrujących drugiej generacji,
- w pojazdach wyposażonych w dowolną wersję przyrządów rejestrujących drugiej generacji można instalować wyłącznie czujniki ruchu drugiej generacji,
- urządzenia do pobierania i kalibracji danych muszą umożliwiać korzystanie z obu generacji lub wersji urządzeń rejestrujących i kart do tachografów.
2.2. Interoperacyjność między VU a kartami
Przyjmuje się, że karty do tachografu pierwszej generacji są interoperacyjne z przyrządami rejestrującymi pierwszej generacji (zgodnie z załącznikiem IB do rozporządzenia (EWG) nr 3821/85), natomiast karty do tachografu dowolnej wersji drugiej generacji są interoperacyjne z przyrządami rejestrującymi dowolnej wersji drugiej generacji (zgodnie z załącznikiem IC do niniejszego rozporządzenia dostosowanym decyzją 1/2023 Specjalnego Komitetu ds. Transportu Drogowego ustanowionego Umową o handlu i współpracy między Unią Europejską i Europejską Wspólnotą Energii Atomowej, z jednej strony, a Zjednoczonym Królestwem Wielkiej Brytanii i Irlandii Północnej, z drugiej strony). Ponadto zastosowanie mają przedstawione poniżej wymogi.
MIG_001 Z wyjątkiem treści wymogów MIG_004 i MIG_005, karty do tachografu pierwszej generacji mogą być nadal używane w dowolnej wersji przyrządów rejestrujących drugiej generacji do upływu daty ich ważności. Właściciele takich kart mogą jednak wystąpić z wnioskiem o ich wymianę na karty do tachografu drugiej generacji, jak tylko te drugie karty staną się dostępne.
MIG_002 Przyrządy rejestrujące dowolnej wersji drugiej generacji muszą być w stanie obsługiwać każdą włożoną ważną kartę kierowcy, kartę kontrolną oraz kartę firmową pierwszej generacji.
MIG_003 Warsztaty mogą raz na zawsze pozbawić przyrządy rejestrującej tej funkcji, tak aby karty do tachografu pierwszej generacji nie mogły być już dłużej akceptowane. Może to nastąpić dopiero po wszczęciu przez Komisję Europejską stosownej procedury, w ramach której zwróci się ona do warsztatów o podjęcie takich działań, np. w ramach każdego przeglądu okresowego tachografu.
MIG_004 Przyrządy rejestrujące drugiej generacji muszą być w stanie obsługiwać wyłącznie karty warsztatowe drugiej generacji.
MIG_005 Do celów określania trybu pracy przyrządy rejestrujące dowolnej wersji drugiej generacji rozpoznają wyłącznie typy włożonych ważnych kart, bez względu na ich generację lub wersję.
MIG_006 Każda ważna karta do tachografu dowolnej wersji drugiej generacji musi umożliwiać jej zastosowanie w przyrządach rejestrujących pierwszej generacji w dokładnie taki sam sposób jak karty do tachografu pierwszej generacji tego samego typu.
2.3. Interoperacyjność między VU a czujnikami ruchu
Przyjmuje się, że czujniki ruchu pierwszej generacji są interoperacyjne z przyrządami rejestrującymi pierwszej generacji, natomiast czujniki ruchu drugiej generacji są interoperacyjne z przyrządami rejestrującymi dowolnej wersji drugiej generacji. Ponadto zastosowanie mają przedstawione poniżej wymogi.
MIG_007 Przyrządów rejestrujących dowolnej wersji drugiej generacji nie można parować ani używać z czujnikami ruchu pierwszej generacji.
MIG_008 Czujniki ruchu drugiej generacji można parować i używać wyłącznie z przyrządami rejestrującymi drugiej generacji, bez względu na wersję, lub z obiema generacjami przyrządów rejestrujących.
2.4. Interoperacyjność między przyrządami rejestrującymi, kartami do tachografu i urządzeniami służącymi do pobierania danych
MIG_009 Urządzenia do pobierania danych mogą być kompatybilne ze wszystkimi generacjami i wersjami przyrządów rejestrujących i kart do tachografów.
2.4.1. Bezpośrednie pobieranie danych z karty przez inteligentne urządzenia dedykowane
MIG_010 Inteligentne urządzenia dedykowane pobierają dane z kart do tachografu danej generacji włożonych do ich czytników kart z zastosowaniem mechanizmów zabezpieczenia i protokołu pobierania danych tej generacji, a pobierane dane mają format zdefiniowany dla danej generacji i wersji.
MIG_011 Aby organy kontrolne spoza UE mogły kontrolować kierowców, należy umożliwić pobieranie danych z kart kierowców (i kart warsztatowych) drugiej generacji, bez względu na wersję, w dokładnie taki sam sposób, w jaki pobierane są dane z kart kierowców (i kart warsztatowych) pierwszej generacji. Tego rodzaju pobieranie obejmuje:
- niepodpisane pliki elementarne IC i ICC (opcjonalnie),
- niepodpisane pliki elementarne (pierwszej generacji) Card_Certificate i CA_Certificate,
- pliki elementarne zawierające inne dane aplikacyjne (w pliku DF Tachograph) żądane przez protokół pobierania danych z kart pierwszej generacji. Informacje takie muszą być zabezpieczone podpisem cyfrowym zgodnie z mechanizmami zabezpieczenia pierwszej generacji.
Tego rodzaju pobieranie nie może obejmować plików elementarnych zawierających dane aplikacyjne istniejących wyłącznie w kartach kierowców (i kartach warsztatowych) wersji 1 lub wersji 2 drugiej generacji (pliki elementarne zawierające dane aplikacyjne w pliku DF Tachograph_G2).
2.4.2. Pobieranie danych z karty za pomocą przyrządu rejestrującego
MIG_012 Dane z dowolnej wersji karty drugiej generacji włożonej do przyrządu rejestrującego pierwszej generacji są pobierane za pomocą protokołu pobierania danych pierwszej generacji. Karta taka odpowiada na polecenia przyrządu rejestrującego w dokładnie taki sam sposób jak karta pierwszej generacji, a pobierane dane mają taki sam format jak dane pobierane z karty pierwszej generacji.
MIG_013 Dane z karty pierwszej generacji włożonej do przyrządu rejestrującego dowolnej wersji drugiej generacji są pobierane za pomocą protokołu pobierania danych określonego w dodatku 7 do niniejszego załącznika. Przyrząd rejestrujący wysyła polecenia do karty w dokładnie taki sam sposób jak przyrząd rejestrujący pierwszej generacji, a pobierane dane mają format określony w odniesieniu do kart pierwszej generacji.
2.4.3. Pobieranie danych z przyrządów rejestrujących
MIG_014 Poza ramami kontroli kierowców przez organ kontrolny spoza UE dane z przyrządów rejestrujących drugiej generacji są pobierane z zastosowaniem mechanizmów zabezpieczenia drugiej generacji i protokołu pobierania danych określonego w dodatku 7 do niniejszego załącznika w odniesieniu do odpowiedniej wersji.
MIG_015 Aby organy kontrolne spoza UE mogły kontrolować kierowców, opcjonalnie można również umożliwić pobieranie danych z przyrządów rejestrujących dowolnej wersji drugiej generacji z zastosowaniem mechanizmów zabezpieczenia pierwszej generacji. Pobierane dane mają wtedy taki sam format, jak dane pobierane z przyrządu rejestrującego pierwszej generacji. Funkcję tę można wybrać za pomocą poleceń w menu.
2.5. Interoperacyjność między VU a urządzeniami do kalibracji
MIG_016 Urządzenia do kalibracji muszą być w stanie przeprowadzać kalibrację tachografów każdej generacji lub wersji, z zastosowaniem protokołu kalibracyjnego danej generacji lub wersji. Urządzenia do kalibracji mogą być kompatybilne ze wszystkimi generacjami i wersjami przyrządów rejestrujących.
3. GŁÓWNE DZIAŁANIA W OKRESIE POPRZEDZAJĄCYM DATĘ WPROWADZENIA
MIG_017 Klucze testowe i certyfikaty muszą zostać udostępnione producentom najpóźniej z dniem publikacji niniejszego załącznika.
MIG_018 Badania interoperacyjności muszą być gotowe do rozpoczęcia w odniesieniu do wersji 2 przyrządów rejestrujących i wersji 2 kart do tachografów, na wniosek producentów, najpóźniej 15 miesięcy przed datą wprowadzenia.
MIG_019 W przypadku wersji 2 generacji 2 tachografów, kart do tachografów i czujników ruchu stosuje się te same klucze i certyfikaty, co w przypadku urządzeń wersji 1 generacji 2.
MIG_020 Państwa członkowskie muszą być w stanie rozpocząć wydawanie kart warsztatowych wersji 2 drugiej generacji najpóźniej 1 miesiąc przed datą wprowadzenia.
MIG_021 Państwa członkowskie muszą być w stanie rozpocząć wydawanie wszystkich innych typów wersji 2 drugiej generacji kart do tachografu najpóźniej 1 miesiąc przed datą wprowadzenia.
4. PRZEPISY DOTYCZĄCE OKRESU PO DACIE WPROWADZENIA
MIG_022 Po upływie daty wprowadzenia państwa członkowskie wydają wyłącznie karty do tachografu wersji 2 drugiej generacji.
MIG_023 Producenci przyrządów rejestrujących / czujników ruchu mogą produkować przyrządy rejestrujące / czujniki ruchu pierwszej generacji, dopóki są one wykorzystywane w danym obszarze, tak aby była możliwa wymiana nieprawidłowo działających elementów składowych.
MIG_023a Ze skutkiem od daty wprowadzenia, nieprawidłowo działające przyrządy rejestrujące lub urządzenia zewnętrzne GNSS wersji 1 drugiej generacji zastępuje się przyrządami rejestrującymi lub urządzeniami zewnętrznymi GNSS wersji 2 drugiej generacji.
MIG_024 Producenci przyrządów rejestrujących / czujników ruchu mogą ubiegać się o utrzymanie homologacji typu oraz uzyskać zgodę na takie utrzymanie w przypadku pierwszej generacji przyrządów rejestrujących / czujników ruchu lub wersji 1 drugiej generacji przyrządów rejestrujących, posiadających już homologację typu.
5. REJESTROWANIE PRZEKROCZEŃ GRANICY W TACHOGRAFACH PIERWSZEJ GENERACJI I PIERWSZEJ WERSJI DRUGIEJ GENERACJI
MIG_025 Symbol kraju oraz, w stosownych przypadkach, regionu, do którego kierowca wjeżdża po przekroczeniu granicy Strony zgodnie z art. 6 ust. 7 w sekcji 4 części B załącznika 31 do Umowy o handlu i współpracy między Unią Europejską i Europejską Wspólnotą Energii Atomowej, z jednej strony, a Zjednoczonym Królestwem Wielkiej Brytanii i Irlandii Północnej, z drugiej strony, wpisuje się jako miejsce, w którym rozpoczyna się dzienny okres pracy, zgodnie z ręcznym wprowadzaniem miejsc określonym w wymogu 60 w załączniku IC do rozporządzenia (UE) nr 165/2014 oraz wymogu 50 w załączniku IB do rozporządzenia (EWG) nr 3821/85.
Dodatek 16 38
ADAPTER DO POJAZDÓW KATEGORII M1 I N1
ADAPTER DO POJAZDÓW KATEGORII M1 I N1
1. SKRÓTY I DOKUMENTY REFERENCYJNE ................................................................
1.1. Skróty ................................................................................................................................
1.2. Normy referencyjne ............................................................................................................
2. OGÓLNA CHARAKTERYSTYKA I FUNKCJE ADAPTERA ........................................
2.1. Ogólny opis adaptera ..........................................................................................................
2.2. Funkcje ..............................................................................................................................
2.3. Zabezpieczenie ....................................................................................................................
3. WYMAGANIA DOTYCZĄCE URZĄDZEŃ REJESTRUJĄCYCH W PRZYPADKU ZAMONTOWANIA ADAPTERA ....................................................................................
4. WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE W STOSUNKU DO ADAPTERA ......................................................................................................................
4.1. Odbiór i przetwarzanie wejściowych impulsów prędkości ....................................................
4.2. Przekazywanie odbieranych impulsów do wbudowanego czujnika ruchu ...............................
4.3. Wbudowany czujnik ruchu ..................................................................................................
4.4. Wymogi bezpieczeństwa .....................................................................................................
4.5. Parametry pracy ..................................................................................................................
4.6. Materiały ............................................................................................................................
4.7. Oznakowania ......................................................................................................................
5. INSTALACJA URZĄDZENIA REJESTRUJĄCEGO W PRZYPADKU ZASTOSOWANIA ADAPTERA ......................................................................................
5.1. Instalacja ............................................................................................................................
5.2. Plombowanie ......................................................................................................................
6. KONTROLE, PRZEGLĄDY I NAPRAWY ......................................................................
6.1. Przeglądy okresowe ............................................................................................................
7. HOMOLOGACJA TYPU URZĄDZENIA REJESTRUJĄCEGO W PRZYPADKU ZASTOSOWANIA ADAPTERA ......................................................................................
7.1. Uwagi ogólne ......................................................................................................................
7.2. Świadectwo funkcjonalności ................................................................................................
1. SKRÓTY I DOKUMENTY REFERENCYJNE
1.1. Skróty
TBD Do ustalenia
VU Przyrząd rejestrujący
1.2. Normy referencyjne
ISO 16844-3 Pojazdy drogowe - Tachografy - Część 3: Podłączenie czujnika ruchu
2. OGÓLNA CHARAKTERYSTYKA I FUNKCJE ADAPTERA
2.1. Ogólny opis adaptera
ADA_001 Adapter dostarcza podłączonemu do niego VU (przyrządowi rejestrującemu) w sposób pewny i ciągły dane o ruchu pojazdu, odwzorowujące jego prędkość i przebytą drogę.
Adapter przeznaczony jest wyłącznie do pojazdów, które muszą być wyposażone w urządzenie rejestrujące zgodnie z niniejszym rozporządzeniem.
Instaluje się go i używa wyłącznie w pojazdach określonych w definicji yy) "adapter" w załączniku IC, w których z mechanicznego punktu widzenia niemożliwy jest montaż stosowanych czujników ruchu innego rodzaju, pod innym względem zgodnych z wymaganiami przedstawionymi w niniejszym załączniku i w dodatkach 1-16 do niniejszego załącznika.
Adapter nie może być mechanicznie sprzężony z ruchomą częścią pojazdu, lecz podłącza się go do impulsów prędkości/przebytej drogi, które są generowane przez zintegrowane czujniki lub alternatywne interfejsy.
ADA_002 Czujnik ruchu posiadający homologację typu (zgodnie z przepisami niniejszego załącznika IC sekcja 8 - Homologacja typu dla urządzenia rejestrującego i kart do tachografów) umieszczony jest w obudowie adaptera, gdzie znajduje się również przetwornik przekazujący odbierane impulsy do wbudowanego czujnika ruchu. Sam wbudowany czujnik ruchu jest podłączony do VU w taki sposób, aby sprzężenie między VU a adapterem było zgodne z wymaganiami ISO16844-3.
2.2. Funkcje
ADA_003 Adapter realizuje następujące funkcje:
- odbiór i adaptacja wejściowych impulsów pomiaru prędkości;
- przekazywanie odbieranych impulsów do wbudowanego czujnika ruchu;
- wszystkie funkcje wbudowanego czujnika ruchu przekazują w sposób pewny dane o ruchu pojazdu do VU.
2.3. Zabezpieczenie
ADA_004 Adapter nie musi posiadać certyfikacji bezpieczeństwa zgodnie z ogólnym celem zabezpieczenia czujnika ruchu określonym w dodatku 10 do niniejszego załącznika. Zastosowanie mają natomiast wymagania dotyczące zabezpieczenia określone w sekcji 4.4 niniejszego dodatku.
3. WYMAGANIA DOTYCZĄCE URZĄDZEŃ REJESTRUJĄCYCH W PRZYPADKU ZAMONTOWANIA ADAPTERA
Wymagania zawarte w kolejnych rozdziałach wskazują sposób, w jaki należy rozumieć wymagania niniejszego załącznika w przypadku zastosowania adaptera. W nawiasach podano odpowiednie numery poszczególnych wymagań załącznika IC.
ADA_005 Urządzenie rejestrujące każdego pojazdu wyposażonego w adapter musi być zgodne ze wszystkimi przepisami niniejszego załącznika, chyba że w niniejszym dodatku przewidziano inaczej.
ADA_006 W przypadku zainstalowania adaptera, na urządzenie rejestrujące składają się przewody, adapter (wraz z czujnikiem ruchu) oraz VU [01].
ADA_007 Przepisy regulujące wykrywanie zdarzeń lub usterek urządzenia rejestrującego otrzymują brzmienie:
- zdarzenie "przerwa w zasilaniu" jest wyzwalane przez VU, o ile nie jest on w trybie kalibracyjnym, w przypadku każdej przerwy w zasilaniu wbudowanego czujnika ruchu przekraczającej 200 milisekund [79];
- zdarzenie "błąd danych dotyczących ruchu" jest wyzwalane przez UV w przypadku przerwy w normalnym strumieniu danych między wbudowanym czujnikiem ruchu a VU lub w przypadku błędu spójności lub autentyczności danych, który występuje podczas wymiany danych między wbudowanym czujnikiem ruchu a VU [83];
- zdarzenie "próba naruszenia zabezpieczenia" jest wyzwalane przez VU w przypadku każdego zdarzenia mającego wpływ na zabezpieczenie wbudowanego czujnika ruchu, o ile nie jest on w trybie kalibracyjnym [85];
- usterka "urządzenie rejestrujące" jest wyzwalana przez VU, o ile nie jest on w trybie kalibracyjnym, w przypadku każdej usterki wbudowanego czujnika ruchu [88].
ADA_008 Usterki adaptera wykrywalne przez urządzenie rejestrujące to usterki związane z wbudowanym czujnikiem ruchu [88].
ADA_009 Funkcja kalibracji VU pozwala na automatyczne sparowanie wbudowanego czujnika ruchu z VU [202, 204].
4. WYMAGANIA KONSTRUKCYJNE I FUNKCJONALNE W STOSUNKU DO ADAPTERA
4.1. Odbiór i przetwarzanie wejściowych impulsów prędkości
ADA_011 Interfejs wejściowy adaptera odbiera impulsy o częstotliwości odwzorowującej prędkość i przebytą drogę. Własności elektryczne impulsów wejściowych: do ustalenia przez producenta. Prawidłowe sprzężenie wejścia adaptera z pojazdem umożliwiają w stosownych przypadkach regulacje, których może dokonać wyłącznie producent adaptera lub zatwierdzony warsztat montujący adapter.
ADA_012 Interfejs wejściowy adaptera musi w stosownych przypadkach mnożyć lub dzielić częstotliwość impulsów wejściowych prędkości przez stałą wartość, aby dostosować sygnał do zakresu współczynnika k zdefiniowanego w niniejszym załączniku (od 2 400 do 25 000 impulsów/km). Wartość stałej może zaprogramować wyłącznie producent adaptera lub zatwierdzony warsztat instalujący adapter.
4.2. Przekazywanie odbieranych impulsów do wbudowanego czujnika ruchu
ADA_013 Impulsy wejściowe, poddane ewentualnej adaptacji w sposób opisany powyżej, przekazywane są do wbudowanego czujnika ruchu w taki sposób, że każdy wejściowy impuls wykrywany jest przez czujnik ruchu.
4.3. Wbudowany czujnik ruchu
ADA_014 Wbudowany czujnik ruchu stymulowany jest przez przekazywane impulsy, co pozwala mu na wytwarzanie danych o ruchu, dokładnie odwzorowujących ruch pojazdu w taki sposób, jakby był on mechanicznie sprzężony z ruchomą częścią pojazdu.
ADA_015 VU wykorzystuje dane identyfikacyjne wbudowanego czujnika ruchu do identyfikacji adaptera [95].
ADA_016 Dane instalacyjne przechowywane we wbudowanym czujniku ruchu uważa się za dane instalacyjne adaptera [122].
4.4. Wymogi bezpieczeństwa
ADA_017 Obudowa adaptera musi być wykonana w sposób uniemożliwiający jej otwarcie. Musi być zaplombowana, by łatwo można było wykryć próby fizycznej ingerencji (np. w drodze oględzin, zob. ADA_035). Plomby muszą spełniać te same wymogi co plomby czujników ruchu [398-406].
ADA_018 Należy wykluczyć możliwość usunięcia wbudowanego czujnika ruchu z adaptera bez naruszania plomb założonych na obudowę adaptera lub uszkodzenia plomb między czujnikiem a obudową adaptera (zob. ADA_034).
ADA_019 Konstrukcja adaptera musi być taka, by dane o ruchu mogły być przetwarzane i odbierane tylko z wejścia adaptera.
4.5. Parametry pracy
ADA_020 Adapter musi realizować wszystkie funkcje w zakresie temperatur określonym przez producenta.
ADA_021 Adapter musi realizować wszystkie funkcje w zakresie wilgotności od 10 % do 90 % [214].
ADA_022 Adapter musi być zabezpieczony przed zbyt wysokim napięciem, odwróceniem biegunowości zasilania oraz przed zwarciami [216].
ADA_023 Adapter musi:
- reagować na pole magnetyczne, które zakłóca wykrywanie ruchu pojazdu. W takich okolicznościach przyrząd rejestrujący zarejestruje i zapisze w pamięci usterkę czujnika [88]; albo
- posiadać czujnik, który jest chroniony przed polami magnetycznymi lub odporny na nie [217].
ADA_024 Adapter musi spełniać przepisy międzynarodowego regulaminu EKG ONZ nr 10, odnoszące się do kompatybilności elektromagnetycznej, jak również musi być zabezpieczony przed skutkami wyładowań elektrostatycznych oraz stanów nieustalonych [218].
4.6. Materiały
ADA_025 Adapter musi spełniać wymagania odnośnie do stopnia ochrony (do ustalenia przez producenta, zależnie od miejsca instalacji) [220, 221].
ADA_026 Obudowa adaptera musi być żółta.
4.7. Oznakowania
ADA_027 Do adaptera musi być przymocowana tabliczka opisowa z następującymi danymi:
- nazwa i adres producenta adaptera;
- numer części producenta i rok produkcji adaptera;
- znak homologacji typu dla adaptera lub urządzenia rejestrującego zawierającego adapter;
- data instalacji adaptera;
- numer identyfikacyjny pojazdu, w którym zainstalowano dany adapter.
ADA_028 Na tabliczce opisowej umieszcza się również następujące dane, jeżeli nie można ich bezpośrednio odczytać z zewnątrz na wbudowanym czujniku ruchu:
- nazwa producenta wbudowanego czujnika ruchu;
- numer części producenta i rok produkcji wbudowanego czujnika ruchu;
- znak homologacji wbudowanego czujnika ruchu.
5. INSTALACJA URZĄDZENIA REJESTRUJĄCEGO W PRZYPADKU ZASTOSOWANIA ADAPTERA
5.1. Instalacja
ADA_029 Adaptery przeznaczone do zamontowania w pojazdach są montowane wyłącznie przez producentów pojazdów, bądź przez zatwierdzone warsztaty, upoważnione do instalacji, aktywacji oraz kalibracji tachografów cyfrowych i inteligentnych.
ADA_030 Taki zatwierdzony warsztat instalujący adaptery musi dostosować interfejs wejściowy oraz wybrać podzielnik wejściowego sygnału (w stosownych przypadkach).
ADA_031 Taki zatwierdzony warsztat instalujący adapter musi zaplombować jego obudowę.
ADA_032 Adapter montuje się jak najbliżej tej części pojazdu, która jest źródłem impulsów wejściowych.
ADA_033 Przewody zasilające adapter muszą być czerwone (plus zasilania) i czarne (masa).
5.2. Plombowanie
ADA_034 W odniesieniu do plombowania zastosowanie mają następujące wymagania:
- obudowa adaptera musi być zaplombowana (zob. ADA_017);
- obudowa wbudowanego czujnika ruchu musi być połączona plombą z obudową adaptera, chyba że nie można usunąć czujnika ruchu z obudowy adaptera bez naruszania plomby(plomb) obudowy adaptera (zob. ADA_018);
- obudowa adaptera musi być połączona plombą z pojazdem;
- połączenie między adapterem a urządzeniem będącym źródłem impulsów wejściowych musi być zaplombowane na obu końcach (na tyle, na ile jest to możliwe).
6. KONTROLE, PRZEGLĄDY I NAPRAWY
6.1. Przeglądy okresowe
ADA_035 Każdy przegląd okresowy (przegląd okresowy oznacza przegląd zgodny z wymaganiami [409]-[413] zawartymi w załączniku 1C) urządzenia rejestrującego w przypadku zastosowania adaptera obejmuje sprawdzenie:
- czy na adapterze znajdują się odpowiednie znaki homologacji typu;
- czy plomby na adapterze i jego podłączeniach są nienaruszone;
- czy adapter zainstalowano zgodnie z informacjami podanymi na tabliczce instalacyjnej;
- czy adapter zainstalowano zgodnie z instrukcjami producenta adaptera lub pojazdu;
- czy dopuszcza się instalację adaptera w kontrolowanym pojeździe.
ADA_036 Przedmiotowe przeglądy obejmują kalibrację i wymianę wszystkich plomb, niezależnie od ich stanu.
7. HOMOLOGACJA TYPU URZĄDZENIA REJESTRUJĄCEGO W PRZYPADKU ZASTOSOWANIA ADAPTERA
7.1. Uwagi ogólne
ADA_037 Urządzenie rejestrujące dostarcza się do homologacji typu w stanie kompletnym z adapterem [425].
ADA_038 Do homologacji typu można przedstawić sam adapter lub adapter jako element składowy urządzenia rejestrującego.
ADA_039 Homologacja typu obejmuje badania funkcjonalności adaptera. Pozytywne wyniki każdego z tych badań potwierdza się odpowiednim świadectwem [426].
7.2. Świadectwo funkcjonalności
ADA_040 Świadectwo funkcjonalności adaptera lub urządzenia rejestrującego zawierającego adapter wydaje się producentowi adaptera wyłącznie po pozytywnym przejściu co najmniej przez wszystkie wyszczególnione niżej badania funkcjonalności.
| Nr | Badanie | Wyszczególnienie | Odpowiednie wymagania |
| 1. | Badanie administracyjne |
| 1.1 | Dokumentacja | Prawidłowość dokumentacji adaptera |
| 2. | Kontrola wizualna |
| 2.1. | Zgodność adaptera z dokumentacją | |
| 2.2. | Identyfikacja / oznakowania adaptera | ADA_027, ADA_028 |
| 2.3 | Materiały, z których wykonany jest adapter | [219]-[223] ADA_026 |
| 2.4. | Plombowanie | ADA_017, ADA_018, ADA_034 |
| 3. | Badania funkcjonalności |
| 3.1 | Przekazywanie impulsów prędkości do wbudowanego czujnika ruchu | ADA_013 |
| 3.2 | Odbiór i przetwarzanie wejściowych impulsów prędkości | ADA_011, ADA_012 |
| 3.3 | Dokładność pomiaru ruchu | [30]-[35], [217] |
| 4. | Badania środowiskowe |
| 4.1 | Wyniki badań producenta | Wyniki badań środowiskowych przeprowadzonych przez producenta | ADA_020, ADA_021, ADA_022, ADA_024 |
| 5. | EMC (kompatybilność elektromagnetyczna) |
| 5.1 | Emisje radiacyjne i wrażliwość na radiację | Sprawdzenie zgodności z przepisami regulaminu EKG ONZ nr 10 | ADA_024 |
| 5.2 | Wyniki badań producenta | Wyniki badań środowiskowych przeprowadzonych przez producenta | ADA_024 |
Dodatek 17 39
PRZEPISY PRZEJŚCIOWE ZWIĄZANE Z KORZYSTANIEM PRZEZ TACHOGRAFY Z OSNMA
PRZEPISY PRZEJŚCIOWE ZWIĄZANE Z KORZYSTANIEM PRZEZ TACHOGRAFY Z OSNMA
Deklaracja usługi uwierzytelniania komunikatów nawigacyjnych usługi otwartej Galileo (OSNMA) oznacza deklarację Komisji Europejskiej, że OSNMA Galileo wchodzi w fazę operacyjną.
Przejściowy przyrząd rejestrujący: przyrząd rejestrujący zgodny z przepisami niniejszego dodatku.
Przejściowe przyrządy rejestrujące są konstruowane zgodnie z dokumentem kontroli interfejsu sygnału w przestrzeni (SIS ICD) i wytycznymi dla odbiorników w zakresie OSNMA, mającymi zastosowanie w fazie testów publicznych OSNMA. Są wyposażone w odbiornik GNSS, który umożliwia korzystanie z usługi OSNMA dostępnej w fazie testów publicznych.
Przejściowe przyrządy rejestrujące nie są jednak w stanie uwierzytelnić komunikatów nawigacyjnych dostępnych po złożeniu deklaracji usługi OSNMA ze względu na niezbędną aktualizację materiału kryptograficznego w przyrządzie rejestrującym. Należy dokonać odpowiedniej aktualizacji oprogramowania, tak aby mogły one zacząć korzystać z OSNMA i spełnić wszystkie wymogi załącznika IC oraz dodatków 1-16 do tego załącznika. Przed aktualizacją przejściowe przyrządy rejestrujące wdrażają funkcje związane z OSNMA zgodnie z niniejszym dodatkiem. Funkcje niezwiązane z OSNMA pozostają niezmienione.
Po dokonaniu odpowiedniej aktualizacji oprogramowania przejściowe przyrządy rejestrujące wdrażają dokument SIS ICD i wytyczne dla odbiorników w zakresie OSNMA, mające zastosowanie w fazie operacyjnej OSNMA, oraz spełniają wszystkie wymogi załącznika IC i dodatków 1-16 do tego załącznika, przy korzystaniu z usługi OSNMA dostępnej w fazie operacyjnej.
Przejściowy tachograf: tachograf wyposażony w przejściowy przyrząd rejestrujący.
ICD Dokument kontroli interfejsu
OSNMA Galileo Open Service Navigation Message Authentication [uwierzytelnianie komunikatów
nawigacyjnych usługi otwartej Galileo]
SIS Sygnał w przestrzeni
VU Przyrząd rejestrujący
Aby zapewnić możliwość wyposażenia pojazdów rejestrowanych po raz pierwszy w wersję 2 tachografów drugiej generacji, począwszy od wnioskowanej daty wprowadzenia określonej w sekcji 1 lit. ccc) załącznika IC do rozporządzenia wykonawczego (UE) 2016/799, konieczne jest uzyskanie homologacji typu, wyprodukowanie i wprowadzenie do obrotu przyrządów rejestrujących przed złożeniem deklaracji usługi OSNMA. W przypadku tych przyrządów rejestrujących, określanych jako przejściowe przyrządy rejestrujące, należy dostosować wymogi dotyczące OSNMA określone w załączniku IC i w dodatkach 1-16 do tego załącznika, tak aby mogły one uzyskać homologację typu i być wykorzystywane w terenie.
W przepisach zawartych w niniejszym dodatku określono szczególne wymogi mające zastosowanie do przejściowych przyrządów rejestrujących. Mają one zastosowanie wyłącznie do przyrządów rejestrujących wyposażonych w wewnętrzny odbiornik GNSS.
TRA_001 Przejściowe przyrządy rejestrujące są wyposażone w odbiornik GNSS, który umożliwia korzystanie z usługi OSNMA dostępnej w fazie testów publicznych.
TRA_002 Wymogi określone w dodatku 12 mają zastosowanie do odbiornika GNSS znajdującego się w przejściowych przyrządach rejestrujących, przy czym zastosowanie mają następujące wykładnie:
TRA_003 Odbiornik GNSS znajdujący się w przejściowych przyrządach rejestrujących jest tak skonstruowany, aby po aktualizacji jego oprogramowania, dokonanej poprzez aktualizację oprogramowania przyrządu rejestrującego, w pełni spełniał wymogi załącznika 12 przy korzystaniu z usługi OSNMA dostępnej w fazie operacyjnej.
Przejściowe przyrządy rejestrujące mogą przetwarzać sygnał OSNMA dostępny w publicznej fazie testowej, ale nie mają możliwości zgłaszania statusu uwierzytelnienia komunikatów nawigacyjnych z SIS dostępnego w fazie operacyjnej OSNMA do czasu dokonania odpowiedniej aktualizacji oprogramowania. W związku z tym przyjmują one, że standardowe pozycje przekazywane przez odbiornik GNSS są zawsze uwierzytelnione.
Obowiązują wymogi określone w załączniku IC i dodatkach 1-16 do tego załącznika, przy czym stosuje się poniższe wykładnie.
TRA_004 Załącznik IC, pkt 3.9.15 - Zdarzenie "konflikt czasu", wymóg 86, należy rozumieć w następujący sposób:
Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się, jeżeli przyrząd rejestrujący wykryje rozbieżność między czasem określonym przez funkcję pomiaru czasu w przyrządzie rejestrującym a czasem pochodzącym ze standardowych pozycji przekazywanych przez odbiornik GNSS lub urządzenie zewnętrzne GNSS. "Rozbieżność czasu" wykrywa się, jeżeli różnica czasu przekracza ± 3 sekundy, co odpowiada dokładności czasu określonej w wymogu 41a, przy czym ta ostatnia wartość zwiększa się o maksymalny dzienny dryft czasu. Zdarzenie to jest rejestrowane wraz z wartością wyświetlaną na wewnętrznym zegarze urządzenia rejestrującego. Przyrząd rejestrujący dokonuje sprawdzenia w celu uruchomienia zdarzenia "konflikt czasowy" tuż przed automatycznym dostosowaniem wewnętrznego zegara VU, zgodnie z wymogiem 211.
TRA_005 Załącznik IC, pkt 3.9.18 - Zdarzenie "anomalia GNSS", wymóg 88a, należy rozumieć w następujący sposób:
Z wyjątkiem trybu kalibracyjnego, zdarzenie to uruchamia się, gdy odbiornik GNSS wykryje atak, jak określono w dodatku 12. Po uruchomieniu zdarzenia anomalii GNSS przyrząd rejestrujący nie generuje innych zdarzeń anomalii GNSS przez kolejnych 10 minut.
TRA_006 Załącznik IC, pkt 3.12.5 - Rejestracja i przechowywanie w pamięci danych - Miejsca i pozycje, w których zaczynają się i kończą dzienne okresy pracy lub w których osiągnięto 3 godziny skumulowanego czasu prowadzenia pojazdu, wymóg 110, należy rozumieć w następujący sposób:
Wraz z miejscem lub pozycją urządzenie rejestrujące rejestruje i przechowuje w pamięci następujące dane:
TRA_007 Załącznik IC, pkt 3.12.17 - Rejestracja i przechowywanie w pamięci danych - Przekroczenia granicy, wymóg 133b, należy rozumieć w następujący sposób:
Wraz z krajami i pozycją urządzenie rejestrujące rejestruje i przechowuje w pamięci następujące dane:
TRA_008 Załącznik IC, pkt 3.12.18 - Rejestracja i przechowywanie w pamięci danych - Operacje załadunku/ rozładunku, wymóg 133 g, należy rozumieć w następujący sposób:
Wraz z typem operacji i pozycją urządzenie rejestrujące rejestruje i przechowuje w pamięci następujące dane:
TRA_009 Załącznik IC, pkt 3.23 - Korekta czasu, wymóg 211, należy rozumieć w następujący sposób:
Ustawienia czasu wewnętrznego zegara przyrządu rejestrującego są automatycznie korygowane w zmiennych odstępach czasu. Kolejna automatyczna korekta czasu uruchamiana jest między 72 a 168 godz. po poprzedniej korekcie oraz po tym, jak VU będzie mógł uzyskać dostęp do czasu GNSS za pomocą komunikatu o prawidłowej uwierzytelnionej pozycji zgodnie z dodatkiem 12. Niemniej jednak korekta czasu nie może nigdy przekroczyć skumulowanego maksymalnego dryftu czasu na dzień, obliczonego przez producenta VU zgodnie z wymogiem 41b. Jeżeli różnica między czasem wewnętrznego zegara VU a czasem odbiornika GNSS jest większa niż skumulowany maksymalny dryft czasu na dzień, wówczas korekta czasu musi dostosować zegar wewnętrzny VU możliwie jak najbliżej czasu odbiornika GNSS. Ustawienia czasu można dokonać tylko wówczas, gdy czas podawany przez odbiornik GNSS jest uzyskiwany przy użyciu komunikatów o uwierzytelnionej pozycji określonych w dodatku 12. Czasem odniesienia dla automatycznego ustawienia czasu wewnętrznego zegara VU jest czas podany w komunikacie o uwierzytelnionej pozycji.
TRA_010 Załącznik IC, pkt 3.23 - Korekta czasu, wymóg 212, należy rozumieć w następujący sposób:
W trybie kalibracyjnym funkcja korekty czasu umożliwia również wymuszoną korektę bieżącego czasu.
Warsztaty mogą korygować czas:
TRA_011 Dodatek 4, pkt 2 - Specyfikacja bloków danych, akapit pierwszy tiret siódme, należy rozumieć w następujący sposób:
W przypadku wydruku po długości i szerokości geograficznej zarejestrowanej pozycji lub po znaczniku czasu, gdy pozycja została określona, piktogram H wskazuje, że pozycję tę uznano za uwierzytelnioną.
TRA_012 Dodatek 8, pkt 8.1 - Usługa RoutineControl (korekta czasu) - Opis komunikatu, wymóg CPR_065a, należy rozumieć w następujący sposób:
Usługa RoutineControl (TimeAdjustment) umożliwia uruchomienie operacji dostosowania zegara VU do czasu podawanego przez odbiornik GNSS.
Na potrzeby realizacji usługi RoutineControl (TimeAdjustment) VU musi być w trybie KALIBRACYJNYM.
Warunek wstępny: zapewnia się zdolność VU do odbierania komunikatów o standardowej pozycji z odbiornika GNSS.
Dopóki trwa korekta czasu, VU odpowiada na żądanie RoutineControl, podfunkcja requestRoutineResults, z routineInfo = 0x78.
Uwaga: korekta czasu może być dość czasochłonna. Tester diagnostyczny żąda statusu korekty czasu za pomocą podfunkcji requestRoutineResults.
TRA_013 Dodatek 12, pkt 3 - Komunikaty podawane przez odbiornik GNSS, wymóg GNS_4a:
Dane zawarte w komunikatach AMC podanych przez odbiornik GNSS, jeżeli występują, nie mogą być wykorzystywane przez przyrząd rejestrujący, z wyjątkiem następujących wartości statusu:
J = jamming [celowe zakłócanie] lub O = other GNSS attack [inny atak na GNSS] (poprzez wdrożone kontrole spójności zgodnie z GNS_3a),
V = void [puste] (uwierzytelniona pozycja nie jest dostępna z innego powodu).
TRA_014 Dodatek 12, pkt 3 - Komunikaty podawane przez odbiornik GNSS, wymóg GNS_5:
Dane zawarte w komunikatach ASA podanych przez odbiornik GNSS, jeżeli występują, nie mogą być wykorzystywane przez przyrząd rejestrujący.
TRA_015 Dodatek 12, pkt 5.2 - Przyrząd rejestrujący bez urządzenia zewnętrznego GNSS - Transfer informacji z odbiornika GNSS do VU, wymogi GNS_34 i 36:
Procesor VU nie może wykorzystywać informacji pochodzących z komunikatu AMC, z wyjątkiem następujących wartości statusu:
J = jamming [celowe zakłócanie] lub O = other GNSS attack [inny atak na GNSS] (poprzez wdrożone kontrole spójności zgodnie z GNS_3a),
V = void [puste] (uwierzytelniona pozycja nie jest dostępna z innego powodu).
Procesor VU nie może wykorzystywać informacji pochodzących z komunikatu AMC.
TRA_016 Dodatek 12, pkt 6 - Przetwarzanie i rejestracja danych o pozycji przez VU, wymóg GNS_39, należy rozumieć w następujący sposób:
Dane o pozycji są przechowywane w VU wraz z flagą wskazującą, czy pozycja została uznana za uwierzytelnioną. Jeżeli konieczne jest zarejestrowanie danych dotyczących pozycji w VU, zastosowanie ma następująca zasada:
TRA_017 Dodatek 12, pkt 6 - Przetwarzanie i rejestracja danych o pozycji przez VU, wymóg GNS_40, należy rozumieć w następujący sposób:
Jeżeli wartość statusu w otrzymanym komunikacie AMC jest ustawiona na f lub 'O' zgodnie z wymogiem GNS_4a, VU generuje i rejestruje zdarzenie anomalii GNSS, jak określono w wymogu 88a w załączniku IC i dodatku 1 (EventFaultType). Przyrząd rejestrujący może przeprowadzić dodatkowe kontrole przed zapisaniem zdarzenia anomalii GNSS po otrzymaniu ustawienia 'J' lub 'O'.
TRA_018 Dodatek 12, pkt 8 - Konflikt ruchu pojazdu, wymóg GNS_42, Warunek uruchamiający 2, tiret pierwsze i drugie po wzorze należy rozumieć w następujący sposób:
TRA_019 Dodatek 14, pkt 5.4.5 - Wymogi protokołu DSRC - Elementy danych dotyczących zdalnego monitorowania tachografu (RtmData), wykonywane czynności i definicje, wymóg DSC_41, tabela 14.3, druga komórka w wierszu RTM20, należy rozumieć w następujący sposób:
VU generuje wartość w postaci liczby całkowitej (timeReal z dodatku 1) w odniesieniu do elementu danych RTM20.
VU ustala wartość RTM20 na czas, kiedy ostatnia standardowa pozycja pojazdu była dostępna z odbiornika GNSS.
Jeżeli żadna standardowa pozycja pojazdu nie była kiedykolwiek dostępna z odbiornika GNSS, VU ustawia wartość RTM20 na 0.
TRA_020 Producent przejściowego przyrządu rejestrującego, który uzyskał homologację typu, przekazuje Komisji informacje o wersjach jego oprogramowania. Komisja publikuje informacje o tych wersjach oprogramowania na publicznie dostępnej stronie internetowej.
TRA_021 Przejściowe przyrządy rejestrujące muszą uzyskać homologację typu zgodnie z wymogami załącznika IC i dodatków 1-16 do tego załącznika, uzupełnionymi przepisami niniejszego dodatku.
TRA_022 Wnioski o wydanie świadectw homologacji typu dla przejściowych przyrządów rejestrujących i przejściowych tachografów można składać wyłącznie do dnia 31 grudnia 2023 r. lub do daty złożenia deklaracji usługi OSNMA, w zależności od tego, która z tych dat jest późniejsza.
TRA_023 Przejściowe przyrządy rejestrujące mogą być montowane w pojazdach zarejestrowanych po raz pierwszy tylko do dnia 31 maja 2024 r. lub do 5 miesięcy po dacie złożenia deklaracji usługi OSNMA, w zależności od tego, która z tych dat jest późniejsza.
ZAŁĄCZNIK II 40
ZNAK I ŚWIADECTWO HOMOLOGACJI
ZNAK I ŚWIADECTWO HOMOLOGACJI
| Belgia | 6, |
| Bułgaria | 34, |
| Republika Czeska | 8, |
| Dania | 18, |
| Niemcy | 1, |
| Estonia | 29, |
| Irlandia | 24, |
| Grecja | 23, |
| Hiszpania | 9, |
| Francja | 2, |
| Chorwacja | 25, |
| Włochy | 3, |
| Cypr | CY, |
| Łotwa | 32, |
| Litwa | 36, |
| Luksemburg | 13, |
| Węgry | 7, |
| Malta | MT, |
| Niderlandy | 4, |
| Austria | 12, |
| Polska | 20, |
| Portugalia | 21, |
| Rumunia | 19, |
| Słowenia | 26, |
| Słowacja | 27, |
| Finlandia | 17, |
| Szwecja | 5, |
| Zjednoczone Królestwo | 11, |
| oraz |
II. ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW ANALOGOWYCH
Państwo członkowskie, które udzieliło homologacji, wystawia wnioskodawcy świadectwo homologacji, którego wzór przedstawiono poniżej. Informując inne państwa członkowskie o wydanej lub ewentualnie cofniętej homologacji, państwo członkowskie musi posługiwać się kopiami tego świadectwa.
ŚWIADECTWO HOMOLOGACJI
Nazwa właściwej jednostki administracyjnej .........................................................................
Zgłoszenie dotyczące 42 :
Homologacja nr:
.......................................................
(Podpis)
III. ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW CYFROWYCH
Państwo członkowskie, które udzieliło homologacji, wystawia wnioskodawcy świadectwo homologacji, którego wzór przedstawiono poniżej. Informując inne państwa członkowskie o wydanej lub ewentualnie cofniętej homologacji, państwo członkowskie musi posługiwać się kopiami tego świadectwa.
ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW CYFROWYCH
Nazwa właściwej jednostki administracyjnej .........................................................................
Zgłoszenie dotyczące 43 :
Ł homologacji: Ł cofnięcia homologacji:
Ł modelu urządzenia rejestrującego
Ł elementu składowego urządzenia rejestrującego 44
Ł karty kierowcy
Ł karty warsztatowej
Ł karty firmowej
Ł karty kontrolera
Homologacja nr:
....................................................
(Podpis)
IV. ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW INTELIGENTNYCH
Państwo członkowskie, które udzieliło homologacji, wystawia wnioskodawcy świadectwo homologacji, którego wzór przedstawiono poniżej. Informując inne państwa członkowskie o wydanej lub ewentualnie cofniętej homologacji, państwo członkowskie musi posługiwać się kopią tego świadectwa.
ŚWIADECTWO HOMOLOGACJI DLA TACHOGRAFÓW INTELIGENTNYCH
Nazwa właściwej jednostki administracyjnej .........................................................................
Zgłoszenie dotyczące 45 :
Ł homologacji: Ł cofnięcia homologacji:
Ł modelu urządzenia rejestrującego
Ł elementu składowego urządzenia rejestrującego 46
Ł karty kierowcy
Ł karty warsztatowej
Ł karty firmowej
Ł karty kontrolera
Homologacja nr:
.................................................
(Podpis)
- zmieniony przez art. 1 pkt 4 rozporządzenia z dnia 28 lutego 2018 r. (Dz.U.UE.L.2018.85.1) zmieniającego nin. rozporządzenie z dniem 17 kwietnia 2018 r. Zmiany częściowo nie zostały naniesione na tekst.
- zmieniony przez art. 1 rozporządzenia nr 158/2020 z dnia 5 lutego 2020 r. (Dz.U.UE.L.2020.34.20) zmieniającego nin. rozporządzenie z dniem 26 lutego 2020 r.
- zmieniony przez art. 1 rozporządzenia nr 1228/2021 z dnia 16 lipca 2021 r. (Dz.U.UE.L.2021.273.1) zmieniającego nin. rozporządzenie z dniem 23 sierpnia 2023 r.
- zmieniony przez art. 1 decyzji nr 1/2023 (2024/293) z dnia 23 listopada 2023 r. (Dz.U.UE.L.2024.293) zmieniającej nin. rozporządzenie z dniem 21 lutego 2024 r. Zmiany częściowo nie zostały naniesione na tekst.
- zmieniony przez art. 1 rozporządzenia nr 1228/2021 z dnia 16 lipca 2021 r. (Dz.U.UE.L.2021.273.1) zmieniającego nin. rozporządzenie z dniem 23 sierpnia 2023 r.
- zmieniony przez art. 1 decyzji nr 1/2023 (2024/293) z dnia 23 listopada 2023 r. (Dz.U.UE.L.2024.293) zmieniającej nin. rozporządzenie z dniem 21 lutego 2024 r.
- zmieniony przez art. 1 rozporządzenia nr 1228/2021 z dnia 16 lipca 2021 r. (Dz.U.UE.L.2021.273.1) zmieniającego nin. rozporządzenie z dniem 23 sierpnia 2023 r.
- zmieniony przez art. 1 decyzji nr 1/2023 (2024/293) z dnia 23 listopada 2023 r. (Dz.U.UE.L.2024.293) zmieniającej nin. rozporządzenie z dniem 21 lutego 2024 r.
- zmieniony przez art. 1 rozporządzenia nr 1228/2021 z dnia 16 lipca 2021 r. (Dz.U.UE.L.2021.273.1) zmieniającego nin. rozporządzenie z dniem 23 sierpnia 2023 r.
- zmieniony przez art. 1 decyzji nr 1/2023 (2024/293) z dnia 23 listopada 2023 r. (Dz.U.UE.L.2024.293) zmieniającej nin. rozporządzenie z dniem 21 lutego 2024 r.
- zmieniony przez sprostowanie z dnia 1 lutego 2017 r. (Dz.U.UE.L.2017.27.169) zmieniające nin. rozporządzenie z dniem 1 lutego 2017 r.
- zmieniony przez art. 1 rozporządzenia nr 1228/2021 z dnia 16 lipca 2021 r. (Dz.U.UE.L.2021.273.1) zmieniającego nin. rozporządzenie z dniem 23 sierpnia 2023 r.
- zmieniony przez art. 1 decyzji nr 1/2023 (2024/293) z dnia 23 listopada 2023 r. (Dz.U.UE.L.2024.293) zmieniającej nin. rozporządzenie z dniem 21 lutego 2024 r.
- zmieniony przez art. 1 rozporządzenia nr 1228/2021 z dnia 16 lipca 2021 r. (Dz.U.UE.L.2021.273.1) zmieniającego nin. rozporządzenie z dniem 23 sierpnia 2023 r.
- zmieniony przez art. 1 decyzji nr 1/2023 (2024/293) z dnia 23 listopada 2023 r. (Dz.U.UE.L.2024.293) zmieniającej nin. rozporządzenie z dniem 21 lutego 2024 r.
- dodany przez art. 1 rozporządzenia nr 2023/980 z dnia 16 maja 2023 r. (Dz.U.UE.L.2023.134.28) zmieniającego nin. rozporządzenie z dniem 21 sierpnia 2023 r.
- dodany przez sprostowanie z dnia 3 czerwca 2016 r. (Dz.U.UE.L.2016.146.31) zmieniające nin. rozporządzenie z dniem 3 czerwca 2016 r.
- zmieniony przez art. 1 pkt 5 rozporządzenia z dnia 28 lutego 2018 r. (Dz.U.UE.L.2018.85.1) zmieniającego nin. rozporządzenie z dniem 17 kwietnia 2018 r.
© Unia Europejska, http://eur-lex.europa.eu/
Za autentyczne uważa się wyłącznie dokumenty Unii Europejskiej opublikowane w Dzienniku Urzędowym Unii Europejskiej.