Akty, jejichž název není vytištěn tučně, se vztahují ke každodennímu řízení záležitostí v zemědělství a obecně platí po omezenou dobu.
Názvy všech ostatních aktů jsou vytištěny tučně a předchází jim hvězdička.
II Nelegislativní akty
NAŘÍZENÍ
30.7.2021
CS
Úřední věstník Evropské unie
L 273/1
PROVÁDĚCÍ NAŘÍZENÍ KOMISE (EU) 2021/1228
ze dne 16. července 2021,
kterým se mění prováděcí nařízení (EU) 2016/799, pokud jde o požadavky na konstrukci, zkoušení, montáž, provoz a opravy inteligentních tachografů a jejich součástí
(Text s významem pro EHP)
EVROPSKÁ KOMISE,
s ohledem na Smlouvu o fungování Evropské unie,
s ohledem na nařízení Evropského parlamentu a Rady (EU) č. 165/2014 ze dne 4. února 2014 o tachografech v silniční dopravě (1), a zejména na článek 11 uvedeného nařízení,
vzhledem k těmto důvodům:
(1)
Nařízení (EU) č. 165/2014 zavedlo inteligentní tachografy, jejichž součástí je napojení na globální družicový navigační systém (dále též „GNSS“), komunikační zařízení pro včasné dálkové odhalování a rozhraní s inteligentními dopravními systémy.
(2)
Technické požadavky na konstrukci, zkoušení, montáž, provoz a opravy tachografů a jejich součástí jsou stanoveny v prováděcím nařízení Komise (EU) 2016/799 (2).
(3)
Nařízení (EU) č. 165/2014 a nařízení Evropského parlamentu a Rady (ES) č. 561/2006 (3) byla změněna nařízením Evropského parlamentu a Rady (EU) 2020/1054 (4). Nařízení (EU) 2020/1054 požaduje zavedení dalších funkcí do inteligentního tachografu. Proto je třeba změnou prováděcího nařízení (EU) 2016/799 vymezit novou verzi inteligentního tachografu.
(4)
V souladu s čl. 8 odst. 1 nařízení (EU) č. 165/2014 by poloha vozidla měla být zaznamenávána automaticky pokaždé, když vozidlo překročí hranici členského státu, a při každé nakládce či vykládce vozidla.
(5)
Rozhraní s inteligentními dopravními systémy, které je ve verzi inteligentního tachografu zavedené ke dni 15. června 2019 volitelné, by pro novou verzi inteligentního tachografu mělo být povinné.
(6)
Nová verze inteligentního tachografu by měla být připravena k ověření signálu družic Galileo, jakmile bude systém Galileo uveden do provozu.
(7)
Aby se zabránilo fyzické výměně záznamového zařízení, kdykoli je přijata změna technických specifikací tachografu, je nutné zajistit, aby budoucí funkce tachografu mohly být zaváděny a zdokonalovány aktualizacemi softwaru.
(8)
Prováděcí nařízení (EU) 2016/799 umožňuje zabudování adaptéru mezi snímačem pohybu a tachografem pro vozidla, jež ačkoli mají hmotnost nižší než 3,5 tuny, mohou tuto hranici příležitostně přesáhnout, například při tažení přípojného vozidla. V návaznosti na změnu nařízení (ES) č. 561/2006 byla povinnost namontovat tachograf rozšířena na vozidla nad 2,5 tuny. Povinné vybavení inteligentním tachografem u lehkých užitkových vozidel činí nezbytným zvýšení úrovně bezpečnosti poskytované adaptérem montáží vnitřního čidla dovnitř tachografu, jež je nezávislé na signálu snímače pohybu.
(9)
Opatření stanovená tímto nařízením jsou v souladu se stanoviskem výboru zřízeného podle čl. 42 odst. 1 nařízení (EU) č. 165/2014,
PŘIJALA TOTO NAŘÍZENÍ:
Článek 1
Příloha IC prováděcího nařízení (EU) 2016/799 se mění v souladu s přílohou tohoto nařízení.
Článek 2
Vstup v platnost
Toto nařízení vstupuje v platnost dvacátým dnem po vyhlášení v Úředním věstníku Evropské unie.
Použije se ode dne 21. srpna 2023.
Toto nařízení je závazné v celém rozsahu a přímo použitelné ve všech členských státech.
(2) Prováděcí nařízení Komise (EU) 2016/799 ze dne 18. března 2016, kterým se provádí nařízení Evropského parlamentu a Rady (EU) č. 165/2014, kterým se stanoví požadavky na konstrukci, zkoušení, montáž, provoz a opravy tachografů a jejich součástí (Úř. věst. L 139, 26.5.2016, s. 1).
(3) Nařízení Evropského parlamentu a Rady (ES) č. 561/2006 ze dne 15. března 2006 o harmonizaci některých předpisů v sociální oblasti týkajících se silniční dopravy, o změně nařízení Rady (EHS) č. 3821/85 a (ES) č. 2135/98 a o zrušení nařízení Rady (EHS) č. 3820/85 (Úř. věst. L 102, 11.4.2006, s. 1).
(4) Nařízení Evropského parlamentu a Rady (EU) 2020/1054 ze dne 15. července 2020, kterým se mění nařízení (ES) č. 561/2006, pokud jde o minimální požadavky na maximální denní a týdenní dobu řízení, minimální přestávky v řízení a týdenní doby odpočinku, a nařízení (EU) č. 165/2014, pokud jde o určování polohy pomocí tachografů (Úř. věst. L 249, 31.7.2020, s. 1).
PŘÍLOHA
Příloha IC prováděcího nařízení (EU) 2016/799 se mění takto:
1)
obsah se mění takto:
a)
vkládá se nový bod 3.6.4, který zní:
„3.6.4
Záznam operace nakládky/vykládky“;
b)
vkládá se nový bod 3.9.18, který zní:
„3.9.18
„Anomálie GNSS““;
c)
vkládají se nové body 3.12.17, 3.12.18 a 3.12.19, které znějí:
„3.12.17
Překročení hranic
3.12.18
Operace nakládky/vykládky
3.12.19
Digitální mapa“;
d)
bod 3.20 se nahrazuje tímto:
„3.20
Výměny dat s dalšími externími zařízeními“;
e)
doplňují se nové body 3.27 a 3.28, které znějí:
„3.27
Monitorování překročení hranic
3.28
Aktualizace softwaru“;
f)
vkládá se nový bod 4.5.3.2.1.1, který zní:
„4.5.3.2.1.1
Doplňující identifikace aplikace (není přístupné verzi 1 celků ve vozidle druhé generace)“;
g)
vkládají se nové body 4.5.3.2.17 až 4.5.3.2.22, které znějí:
„4.5.3.2.17
Status ověření pravosti pro polohy vztahující se k místům, kde denní pracovní doba začíná a/nebo končí (není přístupné verzi 1 celků ve vozidle druhé generace)
4.5.3.2.18
Status ověření pravosti pro polohy, kde součtová doba řízení dosáhne tří hodin (není přístupné verzi 1 celků ve vozidle druhé generace)
4.5.3.2.19
Překročení hranic (není přístupné verzi 1 celků ve vozidle druhé generace)
4.5.3.2.20
Operace nakládky/vykládky (není přístupné verzi 1 celků ve vozidle druhé generace)
4.5.3.2.21
Záznamy o druhu nákladu (není přístupné verzi 1 celků ve vozidle druhé generace)
4.5.3.2.22
Konfigurace VU (není přístupné verzi 1 celků ve vozidle druhé generace)“;
h)
vkládá se nový bod 4.5.4.2.1.1, který zní:
„4.5.4.2.1.1
Doplňující identifikace aplikace (není přístupné verzi 1 celků ve vozidle druhé generace)“;
i)
vkládají se nové body 4.5.4.2.16 až 4.5.4.2.22, které znějí:
„4.5.4.2.16
Status ověření pravosti pro polohy vztahující se k místům, kde denní pracovní doba začíná a/nebo končí (není přístupné verzi 1 celků ve vozidle druhé generace)
4.5.4.2.17
Status ověření pravosti pro pozice, kde součtová doba řízení dosáhne tří hodin (není přístupné verzi 1 celků ve vozidle druhé generace)
4.5.4.2.18
Překročení hranic (není přístupné verzi 1 celků ve vozidle druhé generace)
4.5.4.2.19
Operace nakládky/vykládky (není přístupné verzi 1 celků ve vozidle druhé generace)
4.5.4.2.20
Záznamy o druhu nákladu (není přístupné verzi 1 celků ve vozidle druhé generace)
4.5.4.2.21
Doplňující údaje o kalibraci (není přístupné verzi 1 celků ve vozidle druhé generace)
4.5.4.2.22
Konfigurace VU (není přístupné verzi 1 celků ve vozidle druhé generace)“;
j)
za bod 4.5.5.2.1 se doplňuje nový bod 4.5.5.2.1.1, který zní:
„4.5.5.2.1.1
Doplňující identifikace aplikace (není přístupné verzi 1 celků ve vozidle druhé generace)“;
k)
vkládá se nový bod 4.5.5.2.6, který zní:
„4.5.5.2.6
Konfigurace VU (není přístupné verzi 1 celků ve vozidle druhé generace)“;
l)
za bod 4.5.6.2.1 se doplňuje nový bod 4.5.6.2.1.1, který zní:
„4.5.6.2.1.1
Doplňující identifikace aplikace (není přístupné verzi 1 celků ve vozidle druhé generace)“;
m)
vkládá se nový bod 4.5.6.2.6, který zní:
„4.5.6.2.6
Konfigurace VU (není přístupné verzi 1 celků ve vozidle druhé generace)“;
2)
úvodní text před Seznamem dodatků se nahrazuje tímto:
„ÚVOD
Tato příloha obsahuje požadavky na záznamové zařízení a karty tachografu druhé generace.
Od 15. června 2019 je ve vozidlech poprvé registrovaných v Unii montováno záznamové zařízení druhé generace a jsou vydávány karty tachografu druhé generace.
Za účelem bezproblémového zavádění systému tachografů druhé generace byly karty tachografu druhé generace navrženy tak, aby byly používány také v celcích ve vozidlech první generace postavených v souladu s přílohou IB nařízení (EHS) č. 3821/85.
Recipročně mohou být karty tachografu první generace použity v celcích ve vozidle druhé generace. Celky ve vozidle druhé generace mohou však být kalibrovány pouze pomocí karet dílny druhé generace.
Požadavky na interoperabilitu mezi systémy tachografů první a druhé generace jsou specifikovány v této příloze. Dodatek 15 obsahuje v této souvislosti další podrobnosti o řízení souběžného fungování obou generací.
Vedle toho, v důsledku zavádění nových funkcí, jako je použití otevřené služby systému Galileo pro ověření pravosti navigačních zpráv, detekce překročení hranic, záznamu operací nakládky a vykládky, a také v důsledku potřeby zvýšit kapacitu karty řidiče na 56 dnů činností řidiče, zavádí toto nařízení technické požadavky pro druhou verzi záznamového zařízení a karet tachografu druhé generace.“;
3)
oddíl 1 se mění takto:
a)
písmeno f) se nahrazuje tímto:
„f)
„kalibrací inteligentních tachografů“:
aktualizace nebo potvrzení parametrů vozidla, které je třeba uchovat v datové paměti. Parametry vozidla zahrnují identifikaci vozidla (identifikační číslo vozidla VIN, registrační značku vozidla VRN a členský stát registrace) a vlastnosti vozidla (charakteristický koeficient vozidla w, konstantu záznamového zařízení k, účinný obvod na kolech l, rozměr pneumatik, nastavení omezovače rychlosti (v příslušných případech), aktuální čas UTC, aktuální stav počitadla ujetých kilometrů, standardní druh nákladu); během kalibrace záznamového zařízení se do datové paměti rovněž uloží typy a identifikátory všech příslušných plomb schválení typu.
Jakékoli obnovení nebo potvrzení pouze času UTC se považuje za nastavení času, a nikoli za kalibraci, pokud není v rozporu s požadavkem 409 stanoveným v bodě 6.4.
Kalibrace záznamového zařízení použití karty dílny;“;
b)
písmeno g) se nahrazuje tímto:
„g)
„číslem karty“:
šestnáctimístné alfanumerické označení, které v členském státě jednoznačně identifikuje kartu tachografu. Číslo karty zahrnuje identifikaci, která spočívá v identifikaci řidiče nebo v identifikaci vlastníka karty společně s pořadovým indexem karty, indexem náhrady karty a indexem obnovy karty;
karta je tedy jednoznačně identifikována kódem vydávajícího členského státu a číslem karty;“;
c)
písmena i) a j) se nahrazují tímto:
„i)
„indexem obnovy karty“:
šestnáctý alfanumerický znak čísla karty, který je zvyšován pokaždé, když je karta tachografu odpovídající dané identifikaci, tj. identifikaci řidiče nebo identifikaci vlastníka spolu s pořadovým indexem, obnovována;
j)
„indexem náhrady karty“:
patnáctý alfanumerický znak čísla karty, který je zvyšován pokaždé, když je karta tachografu odpovídající dané identifikaci, tj. identifikaci řidiče nebo identifikaci vlastníka spolu s pořadovým indexem, nahrazována;“;
d)
písmeno ee) se nahrazuje tímto:
„ee)
„neplatnou kartou“:
karta, která byla zjištěna jako vadná nebo u které chybí prokázání pravosti nebo u které ještě nenastalo datum platnosti nebo u které již doba platnosti uplynula;
karta je považována za neplatnou rovněž celkem ve vozidle:
—
pokud již byla do celku ve vozidle vložena karta se stejným vydávajícím členským státem karty, stejnou identifikací, tj. identifikací řidiče nebo identifikací vlastníka spolu s pořadovým indexem, a vyšším indexem obnovy, nebo
—
pokud již byla do celku ve vozidle vložena karta se stejným vydávajícím členským státem karty, stejnou identifikací, tj. identifikací řidiče nebo identifikací vlastníka spolu s pořadovým indexem a indexem obnovy, ale s vyšším indexem náhrady;“;
e)
písmeno ll) se nahrazuje tímto:
„ll)
„zařízením pro dálkovou komunikaci“, „modulem dálkové komunikace“ nebo „zařízením pro včasné dálkové odhalování“:
vybavení celku ve vozidle, které se užívá k provádění cílených silničních kontrol;“;
f)
písmeno nn) se nahrazuje tímto:
„nn)
„obnovou karty“:
vydání nové karty tachografu v době, kdy existující karta dosáhla data ukončení platnosti, nebo pokud je karta vadná a byla vrácena vydávajícímu orgánu;“;
g)
písmeno pp) se nahrazuje tímto:
„pp)
„náhradou karty“:
vydání nové karty tachografu jako náhrady za existující kartu, která byla prohlášena za ztracenou, odcizenou nebo vadnou a která nebyla vrácena vydávajícímu orgánu;“;
h)
písmeno tt) se nahrazuje tímto:
„tt)
„nastavením času“:
nastavení aktuálního času; toto nastavení lze provádět automaticky podle času z přijímače GNSS představujícího čas referenční nebo v režimu kalibrace;“;
i)
v písmenu yy) se první odrážka nahrazuje tímto:
„—
zabudováno a užíváno pouze ve vozidlech typu M1 a N1 podle definice v článku 4 nařízení Evropského parlamentu a Rady (EU) 2018/858 (1),“;
j)
písmeno aaa) se nahrazuje tímto:
„aaa)
vyhrazeno pro budoucí použití;“;
k)
písmeno ccc) se nahrazuje tímto:
„ccc)
„datem zavedení“:
datum stanovené v nařízení (EU) č. 165/2014, od kterého vozidla registrovaná poprvé musí být vybavena tachografem v souladu s tímto nařízením.“;
4)
bod 2.1 se mění takto:
a)
odstavec 05 se nahrazuje tímto:
„05.
Celek ve vozidle obsahuje rozhraní ITS, které je specifikováno v dodatku 13.
Záznamové zařízení může být připojeno k dalším zařízením přídavnými rozhraními a/nebo rozhraním ITS.“;
b)
v odstavci 07 se poslední pododstavec nahrazuje tímto:
„To se děje v souladu s platnými právními předpisy Unie týkajícími se ochrany údajů a v souladu s článkem 7 nařízení (EU) č. 165/2014.“;
5)
bod 2.2 se mění takto:
a)
šestá odrážka se nahrazuje tímto:
„—
údaje zadávané řidičem ručně:
—
zadávání údajů o místech počátku a/nebo ukončení denní pracovní doby,
—
ruční zadávání údajů o činnostech řidiče a souhlas řidiče pro rozhraní ITS,
—
zadávání údajů o zvláštních podmínkách,
—
zaznamenávání operací nakládky/vykládky“;
b)
doplňují se nové odrážky, které znějí:
„—
monitorování překročení hranic,
—
aktualizace softwaru.“;
6)
bod 2.3 se mění takto
a)
v odstavci 12 se pátá odrážka nahrazuje tímto:
„—
funkce stahování není přístupná v provozním režimu s výjimkou:
a)
ustanovení požadavku 193;
b)
stahování z karty řidiče, není-li do celku ve vozidle vložen žádný jiný typ karty.“;
b)
odstavec 13 se mění takto:
i)
druhá odrážka se nahrazuje tímto:
„—
v podnikovém režimu lze výstup údajů vztahujících se k osobě řidiče (požadavky 102, 105, 108, 133a a 133e) provádět pouze za časová období, která nejsou uzamčena nebo která nemá uzamčena žádný jiný podnik (jak je označeno prvními 13 místy číselného kódu karty podniku),“;
ii)
čtvrtá odrážka se nahrazuje tímto:
„—
výstup osobních údajů zaznamenaných a vytvořených buď tachografem, nebo kartami tachografu se nesmí provádět pomocí rozhraní ITS celku ve vozidle, není-li ověřen souhlas řidiče, k němuž se údaje vztahují.“;
7)
v bodě 2.4 odst. 14 se čtvrtá odrážka nahrazuje tímto:
„—
vnější zařízení GNSS (tento profil je potřebný a použitelný pouze pro variantu vnějšího zařízení GNSS).“;
8)
bod 3.1 se mění takto:
a)
odstavec 16 se nahrazuje tímto:
„16.
Při vložení karty (nebo ověření pravosti karty na dálku) ověřuje záznamové zařízení, zda je karta platná karta tachografu v souladu s definicí v oddílu 1 písm. ee), a v takovém případě identifikuje typ a generaci karty.
Pro kontrolu, zda již byla karta vložena, použije záznamové zařízení údaje karty tachografu uložené v její datové paměti, jak je stanoveno v požadavku 133.“;
b)
odstavec 20 se nahrazuje tímto:
„20.
K vyjmutí karet tachografu může dojít pouze po zastavení vozidla a poté, co byly příslušné údaje uloženy na kartách. Vyjmutí karty vyžaduje aktivní zásah uživatele.“;
9)
bod 3.2 se mění takto:
a)
odstavce 26 a 27 se nahrazují tímto:
„26.
Aby bylo možno zjistit manipulaci údajů o pohybu, je nutno informace ze snímače pohybu podpořit dalšími údaji o pohybu vozidla odvozenými z přijímače GNSS a z jednoho nebo více dalších zdrojů nezávislých na snímači pohybu. Uvnitř celku ve vozidle musí být alespoň jeden jiný nezávislý zdroj pohybu vozidla, aniž by bylo nutné vnější rozhraní.
27)
Tato funkce měří polohu vozidla, aby se umožnil záznam:
—
poloh, kde řidič a/nebo druhý řidič začíná svou denní pracovní dobu,
—
poloh, kde součtová doba řízení dosáhne násobku tří hodin,
—
poloh, kde vozidlo překročilo hranici země,
—
poloh, kde byly provedeny operace nakládky/vykládky,
—
poloh, kde řidič a/nebo druhý řidič končí svou denní pracovní dobu.“;
b)
v bodě 3.2.1 se v odstavci 30 doplňuje nová věta, která zní:
„Tolerance se nepoužijí k záměrné změně měřené vzdálenosti.“;
c)
v bodě 3.2.2 se odstavec 33 nahrazuje tímto:
„33)
Aby byla zajištěna tolerance zobrazované rychlosti maximálně ± 6 km/h a byly vzaty v úvahu:
—
tolerance ± 2 km/h u vstupních změn (proměnlivost pneumatik, …),
—
tolerance ± 1 km/h při měřeních provedených při montáži nebo pravidelných kontrolách,
musí záznamové zařízení pro rychlosti ležící v rozmezí 20 až 180 km/hod a pro charakteristické koeficienty vozidla mezi 2 400 až 25 000 imp/km měřit rychlost s tolerancí ± 1 km/hod (při konstantní rychlosti).
Poznámka: Rozlišovací schopnost ukládání údajů s sebou nese další toleranci ± 0,5 km/h u rychlosti vozidla ukládané záznamovým zařízením.“;
d)
v bodě 3.2.3 se odstavec 37 nahrazuje tímto:
„37)
Absolutní poloha se měří v zeměpisných souřadnicích šířky a délky ve stupních a minutách s rozlišením 1/10 minuty.“;
10)
bod 3.3 se mění takto
a)
odstavec 41 se nahrazuje tímto:
„41)
Nepoužívá-li se žádné nastavení času, nesmí časová odchylka překročit ± 1 sekundu za den za teplotních podmínek v souladu s požadavkem 213.“;
b)
vkládají se nové odstavce 41a, 41b a 41c, které znějí:
„41a)
Přesnost času, když je nastavován dílnami v souladu s požadavkem 212, musí být 3 sekundy nebo lepší.
41b)
Součástí celku ve vozidle musí být počitadlo odchylky, které vypočítá maximální časovou odchylku od posledního nastavení času v souladu s bodem 3.23. Maximální časovou odchylku definuje výrobce celku ve vozidle a nesmí překročit 1 sekundu za den, jak je stanoveno v požadavku 41.
41c)
Počitadlo odchylky se znovu nastaví na 1 sekundu po každém nastavení času záznamového zařízení v souladu s bodem 3.23. To zahrnuje:
—
automatická nastavení času,
—
nastavení času prováděná v kalibračním režimu.“;
11)
bod 3.6 se mění takto:
a)
bod 3.6.1 se mění takto:
i)
odstavce 57 až 59 se nahrazují tímto:
„57)
Místa jsou definována jako stát a případně region.
58)
Po vyjmutí karty řidiče (nebo karty dílny) zobrazí záznamové zařízení aktuální místo vozidla na základě informací z GNSS a uložené digitální mapy v souladu s bodem 3.12.19 a požádá držitele karty, aby potvrdil nebo ručně opravil dané místo.
59)
Místo vložené v souladu s požadavkem 58 se považuje za místo, kde končí denní pracovní doba. Na příslušnou kartu řidiče (nebo dílny) se zaznamená jako dočasný záznam, a proto může být později přepsána.
Za následujících podmínek se dočasný záznam provedený při posledním vyjmutí karty validuje (tj. již se dále nepřepisuje):
—
zaznamenání místa zahájení aktuální denní pracovní doby při ručním zadávání údajů podle požadavku 61,
—
další zaznamenání místa zahájení aktuální denní pracovní doby, pokud držitel karty při ručním zadávání údajů podle požadavku 61 nezadá žádné místo, kde začíná nebo končí pracovní doba.
Za následujících podmínek se dočasný záznam při posledním vyjmutí karty přepíše a nová hodnota se validuje:
—
další zaznamenání místa ukončení aktuální denní pracovní doby, pokud držitel karty při ručním zadávání údajů podle požadavku 61 nezadá žádné místo, kde začíná nebo končí pracovní doba.“;
ii)
v odstavci 60 se doplňuje nový pododstavec, který zní:
„Záznamové zařízení zobrazí aktuální místo vozidla na základě informací z GNSS a uložené digitální mapy (uložených digitálních map) v souladu s bodem 3.12.19 a požádá řidiče, aby místo potvrdil nebo ručně opravil.“;
b)
v bodě 3.6.2 se odstavec 61 nahrazuje tímto:
„61)
Při vložení karty řidiče (nebo karty dílny) a pouze v tomto okamžiku musí záznamové zařízení umožňovat ruční zadávání činností. Ruční zadávání činností se provádí za použití místního času a hodnot data podle daného časového pásma (posun oproti UTC) aktuálně nastaveného pro celek ve vozidle.
Při vložení karty řidiče nebo karty dílny přístroj držiteli karty připomene:
—
datum a čas jeho posledního vyjmutí karty,
—
volitelně: posun místního času oproti UTC momentálně nastavený pro celek ve vozidle.
Při prvním vložení karty řidiče nebo karty dílny, které celek ve vozidle aktuálně nezná, je držitel karty vyzván, aby vyjádřil souhlas s výstupem osobních údajů uložených v tachografu pomocí rozhraní ITS. Pro kontrolu, zda již byla karta vložena, použije záznamové zařízení údaje karty tachografu uložené v její datové paměti, jak je stanoveno v požadavku 133.
Souhlas řidiče (resp. dílny) lze kdykoli aktivovat nebo deaktivovat pomocí příkazů v menu, je-li vložena karta řidiče (resp. dílny).
Musí být možno zadávat činnosti s následujícími omezeními:
—
typy činnosti jsou JÍZDA, POHOTOVOST nebo PŘESTÁVKA/ODPOČINEK,
—
časy zahájení a ukončení každé činnosti musí spadat pouze do intervalu mezi posledním vyjmutím karty a jejím aktuálním vložením,
—
není dovoleno, aby se jednotlivé činnosti navzájem časově překrývaly.
V případě potřeby musí být možno provádět ruční zadávání údajů při prvním vložení dříve nepoužívané karty řidiče (nebo dílny).
Postup ručního zadávání činností musí zahrnovat tolik po sobě jdoucích kroků, kolik je nezbytné k nastavení typu, času zahájení a času ukončení každé činnosti. U libovolné části doby mezi posledním vyjmutím karty a jejím aktuálním vložením musí mít držitel karty možnost neuvést žádnou činnost.
Při ručním zadávání údajů spojeném s vložením karty musí mít držitel karty v příslušných případech možnost zadat:
—
místo ukončení předešlé denní pracovní doby a příslušný čas (čímž dojde k přepsání a validaci položky vytvořené při posledním vyjmutí karty),
—
místo zahájení aktuální denní pracovní doby a příslušný čas (čímž dojde k validaci dočasného záznamu při posledním vyjmutí karty).
Pro místo zahájení aktuální denní pracovní doby při aktuálním vložení karty záznamové zařízení zobrazí aktuální místo vozidla na základě informací z GNSS a uložené digitální mapy (uložených digitálních map) v souladu s bodem 3.12.19 a požádá řidiče, aby místo potvrdil nebo ručně opravil.
Pokud držitel karty při ručním zadávání spojeném s vložením karty nezadá žádné místo, kde zahájil nebo ukončil pracovní dobu, má se za to, že se jeho pracovní doba od posledního vyjmutí karty nezměnila. Další zaznamenání místa ukončení předchozí denní pracovní doby pak přepíše dočasný záznam provedený při posledním vyjmutí karty.
Pokud je zadáno nějaké místo, musí být zaznamenáno na příslušnou kartu tachografu.
Ruční zadávání údajů se přeruší, jestliže:
—
dojde k vyjmutí karty nebo
—
je vozidlo v pohybu a karta je v otvoru pro kartu řidiče.
Jsou povolena i další přerušení, například prodleva přístroje po určité době nečinnosti uživatele. V případě přerušení ručního zadávání záznamové zařízení validuje veškeré již provedené úplné záznamy místa a činnosti (které mají zadáno buď jednoznačné místo a čas, nebo typ činnosti, čas zahájení a čas ukončení).
Pokud dojde k vložení karty druhého řidiče nebo karty dílny během ručního zadávání údajů pro dříve vloženou kartu, musí být možno ruční zadávání údajů pro tuto předchozí kartu dokončit před zahájením ručního zadávání údajů pro druhou kartu.
Držitel karty musí mít možnost ručně zadávat údaje za použití následujícího minimálního postupu:
—
ruční zadání činností v chronologickém pořadí za dobu mezi posledním vyjmutím karty a jejím aktuálním vložením,
—
čas zahájení první činnosti se nastaví na čas vyjmutí karty. U každé následující zadané činnosti se čas zahájení předem nastaví na hodnotu, která bezprostředně následuje po času ukončení předchozí zadané činnosti. U každé činnosti se zvolí typ činnosti a čas ukončení.
Postup je ukončen v okamžiku, kdy se čas ukončení ručně zadané činnosti shoduje s časem vložení karty.
Záznamové zařízení umožní řidičům a dílnám střídavě nahrát ručně zadané údaje, které je třeba vložit během postupu, prostřednictvím rozhraní ITS uvedeného v dodatku 13 a volitelně prostřednictvím jiných rozhraní.
Záznamové zařízení umožní držiteli karty upravovat údaje kterékoli ručně zadané činnosti, a to až do okamžiku, kdy dojde k validaci zvolením zvláštního příkazu. Poté už budou jakékoli takové úpravy zakázány.“;
c)
v bodě 3.6.3 se odstavec 62 nahrazuje tímto:
„62)
Záznamové zařízení umožní řidiči zadat v reálném čase dva údaje o specifických podmínkách:
—
„MIMO PŮSOBNOST“ (začátek, konec),
—
„PŘEVOZ LODÍ / PŘEVOZ VLAKEM“ (začátek, konec).
K záznamu podmínky „PŘEVOZ LODÍ / PŘEVOZ VLAKEM“ nedojde, pokud je otevřen záznam podmínky „MIMO PŮSOBNOST“. Je-li otevřen záznam podmínky „MIMO PŮSOBNOST“, záznamové zařízení nesmí uživatelům umožnit zadat příznak začátku podmínky „PŘEVOZ LODÍ / PŘEVOZ VLAKEM“.
Otevřený záznam podmínky „MIMO PŮSOBNOST“ musí být záznamovým zařízením automaticky uzavřen při vložení nebo vyjmutí karty řidiče.
Otevřený záznam podmínky „MIMO PŮSOBNOST“ musí deaktivovat následující události a varování:
—
jízda bez náležité karty,
—
varování týkající se nepřetržité doby řízení.
Řidič zadá příznak začátku podmínky „PŘEVOZ LODÍ / PŘEVOZ VLAKEM“ ihned po zvolení činnosti „PŘESTÁVKA/ODPOČINEK“.
Otevřený záznam podmínky „PŘEVOZ LODÍ / PŘEVOZ VLAKEM“ musí být záznamovým zařízením ukončen, pokud nastane některá z těchto možností:
—
řidič ručně ukončí „PŘEVOZ LODÍ / PŘEVOZ VLAKEM“, k čemuž musí dojít po příjezdu lodě/vlaku do místa určení před opuštěním lodě/vlaku,
—
je otevřen záznam podmínky „MIMO PŮSOBNOST“,
—
řidič vyjme svou kartu,
—
činnost řidiče se počítá jako JÍZDA za kalendářní minutu v souladu s bodem 3.4.
Pokud se během jedné kalendářní minuty uskuteční záznam více než jedné specifické podmínky stejného typu, uchová se pouze poslední záznam.“;
d)
vkládá se nový bod 3.6.4, který zní:
„3.6.4
Záznam operace nakládky/vykládky
62a)
Záznamové zařízení musí řidiči umožňovat zadávat a potvrzovat v reálném čase informace o tom, že je vozidlo nakládáno, vykládáno nebo že se provádí souběžná operace nakládky/vykládky.
Pokud se během jedné kalendářní minuty uskuteční více než jeden záznam operace nakládky/vykládky stejného typu, uchová se pouze poslední záznam.
62b)
Operace nakládky, vykládky nebo souběžné nakládky/vykládky se zaznamenají jako samostatné události.
62c)
Informace o nakládce/vykládce se zadají dříve, než vozidlo opustí místo, kde se operace nakládky/vykládky provádí.“;
12)
bod 3.9 se mění takto:
a)
v bodě 3.9.12 se odstavec 83 nahrazuje tímto:
„83)
Tato událost nastane, není-li zařízení v kalibračním režimu, v případě přerušení normálního toku dat mezi snímačem pohybu a celkem ve vozidle a/nebo v případě chyby v integritě nebo pravosti údajů přenášených mezi snímačem pohybu a celkem ve vozidle. Tato událost nastane rovněž, není-li zařízení v kalibračním režimu, v případě, že se rychlost vypočtená z impulsů snímače pohybu zvýší z 0 na více než 40 km/h během 1 sekundy a poté se udrží nad 40 km/h po dobu nejméně 3 sekund.“;
b)
v bodě 3.9.13 se odstavec 84 nahrazuje tímto:
„84)
Tato událost nastane, jak je stanoveno v dodatku 12, není-li zařízení v kalibračním režimu, v případě, že informace o pohybu vypočtené ze snímače pohybu jsou v rozporu s informacemi o pohybu vypočtenými z vnitřního přijímače GNSS nebo z vnějšího zařízení GNSS a volitelně z jiných nezávislých zdrojů v souladu s požadavkem 26. Tato událost nesmí nastat během převozu lodí/vlakem.“;
c)
v bodě 3.9.15 se odstavec 86 nahrazuje tímto:
„86)
Tato událost nastane, není-li zařízení v kalibračním režimu, pokud celek ve vozidle zjistí nesoulad mezi časem funkce měření času celku ve vozidle a časem pocházejícím z ověřených poloh přenášených přijímačem GNSS nebo vnějším zařízením GNSS. „Časový nesoulad“ se zjistí, překročí-li časový rozdíl ±3 sekundy odpovídající časové přesnosti stanovené v požadavku 41a, přičemž tato přesnost se zvýší o maximální časovou odchylku za den. Tato událost se zaznamená spolu s hodnotou vnitřních hodin záznamového zařízení. Celek ve vozidle provede kontrolu spuštění události „nesoulad času“ těsně předtím, než celek ve vozidle automaticky znovu nastaví vnitřní hodiny celku ve vozidle v souladu s požadavkem 211.“;
d)
v bodě 3.9.17 se osmá odrážka nahrazuje tímto:
„—
závada rozhraní ITS“;
e)
doplňuje se nový bod, který zní:
„3.9.18
„Anomálie GNSS“
88a)
Tato událost nastane, není-li zařízení v kalibračním režimu, pokud přijímač GNSS zjistí útok nebo když selhalo ověřování navigačních zpráv, jak je uvedeno v dodatku 12. Nastane-li událost anomálie GNSS, celek ve vozidle negeneruje další anomálie GNSS po dobu následujících 10 minut.“;
13)
v bodě 3.10 se poslední řádek tabulky nahrazuje tímto:
„Rozhraní ITS
Správná funkce“;
14)
bod 3.12 se mění takto:
a)
první pododstavec se nahrazuje tímto:
„Pro účely tohoto bodu
—
se „365 dny“ rozumí 365 kalendářních dnů průměrné činnosti řidiče ve vozidle. Průměrná činnost v průběhu dne ve vozidle se definuje jako nejméně 6 řidičů nebo druhých řidičů, 6 cyklů vložení a vyjmutí karty a 256 změn činnosti. „365 dnů“ tedy obsahuje minimálně 2 190 řidičů nebo druhých řidičů, 2 190 cyklů vložení a vyjmutí karty a 93 440 změn činnosti,
—
se průměrný počet zadání místa za den definuje jako nejméně 6 zadání, kde začíná denní pracovní doba, a 6 zadání, kde končí denní pracovní doba, takže „365 dnů“ zahrnuje alespoň 4 380 zadání místa,
—
se průměrný počet poloh za den, kdy součtová doba řízení dosáhne násobku tří hodin, definuje jako nejméně 6 poloh, takže „365 dnů“ zahrnuje alespoň 2 190 takových poloh,
—
se průměrný počet překročení hranic za den definuje jako nejméně 20 překročení hranic, takže „365 dnů“ zahrnuje nejméně 7 300 překročení hranic,
—
se průměrný počet operací nakládky/vykládky za den definuje jako nejméně 25 operací (bez ohledu na typ), takže „365 dnů“ zahrnuje nejméně 9 125 operací nakládky/vykládky,
—
jsou časové údaje zaznamenávány s rozlišením jedné minuty, pokud není stanoveno jinak,
—
se stav počitadla ujetých kilometrů zaznamenává s rozlišením jednoho kilometru,
—
jsou údaje o rychlosti zaznamenávány s rozlišením 1 km/h,
—
jsou polohy (zeměpisné šířky a délky) zaznamenávány ve stupních a minutách s rozlišením 1/10 minuty, s příslušnou přesností GNSS a dobou zjištění a s příznakem informujícím, zda byla poloha ověřena.“;
b)
bod 3.12.1.1 se mění takto:
i)
v odstavci 93 se doplňuje nová odrážka, která zní:
„—
identifikátor verze digitální mapy (požadavek 133l).“;
ii)
odstavec 94 se nahrazuje tímto:
„94)
Identifikační údaje celku ve vozidle jsou výrobcem celku ve vozidle zaznamenány a uloženy jednou provždy, s výjimkou údajů, které mohou být změněny v případě aktualizace softwaru v souladu s tímto nařízením, a schopnosti používat karty tachografu první generace.“;
c)
V bodě 3.12.1.2 odst. 97 se první pododstavec nahrazuje tímto:
„97)
Celek ve vozidle musí být schopen zaznamenat a uložit do své datové paměti následující údaje vztahující se k 20 posledním úspěšným párováním snímačů pohybu (dojde-li k několika párováním během jednoho kalendářního dne, uloží se pouze první a poslední z nich):“;
d)
v bodě 3.12.1.3 odst. 100 se první pododstavec nahrazuje tímto:
„100)
Celek ve vozidle musí být schopen zaznamenat a uložit do své datové paměti následující údaje vztahující se k posledním 20 úspěšným párováním s vnějšími zařízeními GNSS (pokud během jednoho kalendářního dne dojde k několika párováním, uloží se jenom první a poslední z nich).“;
e)
bod 3.12.5 se mění takto:
i)
odstavec 110 se mění takto:
1.
první odrážka se nahrazuje tímto:
„—
číslo karty řidiče a/nebo druhého řidiče a členský stát, který kartu vydal,“;
2.
doplňuje se nová odrážka, která zní:
„—
příznak informující, zda byla poloha ověřena.“;
ii)
vkládá se odstavec 110a, který zní:
„110a)
Pro místa, kde začíná nebo končí denní pracovní doba zaznamenaná během postupu ručního zadávání údajů při vložení karty v souladu s požadavkem 61, se uloží aktuální stav počitadla ujetých kilometrů a poloha vozidla.“;
f)
v bodě 3.12.8 odst. 117 se tabulka mění takto:
i)
pátý řádek se nahrazuje tímto:
„Nesprávné ukončení poslední relace karty
—
deset posledních událostí
—
datum a čas vložení karty
—
typ, číslo, vydávající členský stát a generace karty (karet)
—
poslední data relace přečtená z karty:
—
datum a čas vložení karty“;
ii)
vkládá se nový řádek, který zní:
„Anomálie GNSS
—
nejdelší události v každém z posledních deseti dnů výskytu
—
pět nejdelších událostí za posledních 365 dnů
—
datum a čas začátku události
—
datum a čas konce události
—
typ, číslo, vydávající členský stát a generace všech karet vložených na začátku a/nebo na konci události
—
počet podobných událostí v tentýž den“;
g)
v bodě 3.12.10 odst. 120 se doplňují nové odrážky, které znějí:
„—
výrobní čísla snímače pohybu, případného vnějšího zařízení GNSS a případného vnějšího zařízení pro dálkovou komunikaci,
—
standardní druh nákladu přiřazený k vozidlu (náklad zboží nebo cestujících),
—
země, ve které byla kalibrace provedena, a datum a čas, kdy byla poloha použitá k určení této země poskytnuta přijímačem GNSS.“;
h)
doplňují se nové body, které znějí:
„3.12.17 Překročení hranic
133a)
Záznamové zařízení musí zaznamenávat a uchovávat ve své datové paměti tyto informace o překročení hranic:
—
zemi, kterou vozidlo opouští,
—
zemi, do které vozidlo vstupuje,
—
polohu, kde vozidlo překročilo hranici.
133b)
Společně se zeměmi a polohou musí záznamové zařízení zaznamenávat a uchovávat ve své datové paměti:
—
číslo karty řidiče a/nebo druhého řidiče a členský stát, který kartu vydal,
—
generaci karty,
—
příslušnou přesnost GNSS, datum a čas,
—
příznak informující, zda byla poloha ověřena,
—
stav počitadla ujetých kilometrů vozidla v okamžiku detekce překročení hranice.
133c)
Datová paměť musí být schopna uchovat údaje o překročení hranic nejméně po dobu 365 dnů.
133d)
Jestliže je kapacita paměti vyčerpána, musí nové údaje nahradit nejstarší údaje.
3.12.18 Operace nakládky/vykládky
133e)
Záznamové zařízení musí zaznamenávat a uchovávat ve své datové paměti tyto informace o operacích nakládky a vykládky vozidla:
—
druh operace (nakládka, vykládka nebo souběžná nakládka a vykládka),
—
poloha, kde došlo k operaci nakládky/vykládky.
133f)
Není-li v době operace nakládky/vykládky k dispozici poloha vozidla z přijímače GNSS, záznamové zařízení použije poslední dostupnou polohu a příslušné datum a čas.
133g)
Společně s typem operace a polohou musí záznamové zařízení zaznamenat a uchovat ve své datové paměti:
—
číslo karty řidiče a/nebo druhého řidiče a členský stát, který kartu vydal,
—
generaci karty,
—
datum a čas nakládky/vykládky,
—
příslušnou přesnost GNSS, v příslušných případech datum a čas,
—
příznak informující, zda byla poloha ověřena,
—
stav počitadla ujetých kilometrů.
133h)
Datová paměť musí být schopna uchovat operace nakládky/vykládky nejméně po dobu 365 kalendářních dnů.
133i)
Jestliže je kapacita paměti vyčerpána, musí nové údaje nahradit nejstarší údaje.
3.12.19 Digitální mapa
133j)
Pro účely záznamu polohy vozidla při překročení hranice země musí záznamové zařízení uložit do své datové paměti digitální mapu.
133k)
Evropská komise zpřístupní digitální mapy, které jsou povolené na podporu funkce monitorování překračování hranic záznamového zařízení, ke stažení v různých formátech z vyhrazených zabezpečených internetových stránek.
133l)
Pro každou z uvedených map musí být na internetových stránkách k dispozici identifikátor verze a hodnota hash.
133m)
Mapy se musí vyznačovat:
—
úrovní rozlišení odpovídající úrovni NUTS 0 podle klasifikace územních statistických jednotek,
—
měřítkem 1:1 milionu.
133n)
Výrobci tachografů zvolí mapu z internetových stránek a bezpečně ji stáhnou.
133o)
Výrobci tachografů použijí mapu staženou z internetových stránek teprve poté, co ověřili její integritu pomocí hodnoty hash dotčené mapy.
133p)
Vybranou mapu importuje do záznamového zařízení jeho výrobce ve vhodném formátu, ale sémantika importované mapy musí zůstat nezměněna.
133q)
Výrobce uchová rovněž identifikátor verze mapy použité v záznamovém zařízení.
133r)
Musí být možné aktualizovat nebo nahradit uloženou digitální mapu novou mapou zpřístupněnou Evropskou komisí.
133s)
Aktualizace digitální mapy se provedou za použití mechanismů aktualizace softwaru stanovených výrobcem, přičemž se uplatní požadavky 226d a 226e, aby záznamové zařízení mohlo ověřit pravost a integritu nové importované mapy před jejím uložením a před nahrazením předchozí mapy.
133t)
Výrobci tachografů mohou k základní mapě uvedené v požadavku 133m doplnit další informace pro jiné účely než zaznamenávání překročení hranic, jako jsou hranice regionů EU, za předpokladu, že nedojde ke změně sémantiky základní mapy.“;
15)
bod 3.13 se mění takto:
a)
v odstavci 134 se třetí odrážka nahrazuje tímto:
„—
výpočtu nepřetržité doby řízení řidiče, souhrnné doby přestávek a součtové doby řízení v předchozím a probíhajícím týdnu,“;
b)
doplňuje se nový odstavec 135a, který zní:
„135a)
Struktura aplikace „TACHO_G2“ závisí na verzi. Karty verze 2 musí obsahovat doplňující elementární soubory k souborům karet verze 1, zejména:
—
na kartách řidiče a dílny:
—
EF Places_Authentication obsahuje status ověření pravosti poloh vozidla uložených v EF Places. S každým statusem ověření pravosti se uloží časové razítko, které musí být naprosto shodné s datem a časem uložení záznamu s odpovídající polohou v EF Places.
—
EF GNSS_Places_Authentication musí obsahovat status ověření pravosti poloh vozidla uložených v EF GNSS_Places. S každým statusem ověření pravosti se uloží časové razítko, které musí být naprosto shodné s datem a časem uložení záznamu s odpovídající polohou v EF Places.
—
EF Border_Crossings, EF Load_Unload_Operations a EF Load_Type_Entries musí obsahovat údaje týkající se překročení hranic, operací nakládky/vykládky a druhů nákladu.
—
na kartách dílny:
—
EF Calibration_Add_Data musí obsahovat doplňující údaje o kalibraci k těm, která jsou uložena v EF Calibration. Stará hodnota data a času a identifikační číslo vozidla se musí uložit spolu s každým záznamem doplňujících údajů o kalibraci, přičemž musí být naprosto shodné se starou hodnotou data a času a identifikačním číslem vozidla uloženými s odpovídajícími údaji o kalibraci v EF Calibration.
—
na všech kartách tachografu:
—
EF VU_Configuration musí obsahovat specifická nastavení tachografu držitele karty.
Celek ve vozidle musí ignorovat jakýkoli status ověření pravosti nalezený v EF Places_Authentication nebo EF GNSS_Places_Authentication, není-li v EF Places nebo EF GNSS_Places nalezena žádná poloha vozidla se stejným časovým razítkem.
Celek ve vozidle musí ignorovat elementární soubor EF VU_Configuration na všech kartách, pokud nebyla stanovena žádná zvláštní pravidla v souvislosti s použitím takového elementárního souboru. Uvedená pravidla se stanoví změnou přílohy IC, která musí obsahovat změnu nebo zrušení tohoto odstavce.“;
16)
bod 3.14 se mění takto:
a)
bod 3.14.1 se mění takto:
i)
odstavec 140 se nahrazuje tímto:
„140)
Všechny události a závady, které nejsou definovány pro záznamové zařízení první generace, se na karty řidiče a karty dílny první generace neukládají.“;
ii)
odstavec 143 se nahrazuje tímto:
„143)
Před uvolněním karty řidiče nebo karty dílny a po uložení všech příslušných údajů, které se měly na kartu uložit, nastaví záznamové zařízení znovu „údaje o použití karty“.“;
b)
bod 3.14.2 se mění takto:
i)
v odstavci 144 se vkládá nový pododstavec, který zní:
„Struktura aplikace „TACHO_G2“ závisí na verzi. Karty verze 2 obsahují další elementární soubory k souborům karet verze 1.“;
ii)
vkládají se odstavce 147a a 147b, které znějí:
„147a)
Při vložení karty řidiče nebo karty dílny musí záznamové zařízení na kartu uložit standardní druh nákladu vozidla.
147b)
Při vložení karty řidiče nebo karty dílny a po provedení postupu ručního zadávání údajů musí záznamové zařízení zkontrolovat poslední místo, kde začíná nebo končí denní pracovní doba, uložené na kartě. Toto místo může být dočasné, jak je uvedeno v požadavku 59. Nachází-li se toto místo v jiné zemi než v zemi, v níž se vozidlo momentálně nachází, záznamové zařízení musí uložit na kartu záznam o překročení hranice a:
—
zemi, kterou řidič opustil: není k dispozici,
—
zemi, do které řidič vstupuje: aktuální země, ve které je vozidlo umístěno,
—
datum a čas, kdy řidič překročil hranici: čas vložení karty,
—
polohu řidiče při překročení hranice: není k dispozici,
—
stav počitadla ujetých kilometrů: není k dispozici.“;
iii)
doplňuje se nový odstavec 150a, který zní:
„150a)
Celek ve vozidle musí ignorovat elementární soubor EF VU_Configuration na všech kartách, pokud nebyla stanovena žádná zvláštní pravidla v souvislosti s použitím takového elementárního souboru. Uvedená pravidla se stanoví změnou přílohy IC, která musí obsahovat změnu nebo zrušení tohoto odstavce.“;
17)
v bodě 3.15.4 se odstavec 167 mění takto:
a)
druhá odrážka se nahrazuje tímto:
„—
obsah kteréhokoli výtisku uvedeného v požadavku 169 v témže formátu, jaký mají samotné výtisky,“;
b)
pátá a šestá odrážka se nahrazují tímto:
„—
součtovou dobu řízení řidiče v předchozím a probíhajícím týdnu,
—
součtovou dobu řízení druhého řidiče v předchozím a probíhajícím týdnu,“;
c)
osmá, devátá a desátá odrážka se nahrazují tímto:
„—
součtovou dobu řízení řidiče v probíhajícím týdnu,
—
součtovou dobu řízení druhého řidiče v probíhající denní pracovní době,
—
součtovou dobu řízení řidiče v probíhající denní pracovní době.“;
18)
bod 3.18 se mění takto:
a)
odstavec 193 se nahrazuje tímto:
„193)
Kromě toho a jako volitelnou funkci může záznamové zařízení stahovat údaje v jakémkoli provozním režimu přes jakékoli jiné rozhraní pro podnik ověřený tímto kanálem. V tomto případě se při stahování využijí přístupová práva podniku pro stahování údajů.“;
b)
doplňují se nové odstavce 196a a 196b, které znějí:
„196a)
Dopravce, který používá vozidla vybavená záznamovým zařízením vyhovujícím této příloze a spadající do oblasti působnosti nařízení (ES) č. 561/2006, zajistí, aby byly všechny údaje z celku ve vozidle a karty řidiče staženy.
Maximální časové úseky, během nichž se příslušné údaje stahují, nesmí přesáhnout:
—
90 dnů v případě údajů z celku ve vozidle,
—
28 dnů v případě údajů z karty řidiče.
196b)
Dopravci uchovávají údaje stažené z celku ve vozidle a karty řidiče po dobu nejméně dvanácti měsíců po jejich záznamu.“;
19)
v bodě 3.19 odstavci 199 se doplňují nové odrážky, které znějí:
„—
polohu vozidla,
—
údaj, zda řidič může v současné době porušovat dobu řízení.“;
20)
bod 3.20 se mění takto:
a)
nadpis se nahrazuje tímto:
„3.20
Výměny dat s dalšími externími zařízeními“;
b)
odstavec 200 se nahrazuje tímto:
„200)
Záznamové zařízení musí být v souladu s dodatkem 13 rovněž vybaveno rozhraním ITS, které umožňuje, aby údaje zaznamenané nebo vytvořené tachografem nebo kartami tachografu byly použity externím zařízením.
V provozním režimu je pro přenos osobních údajů prostřednictvím rozhraní ITS nutný souhlas řidiče. Souhlas řidiče se však nevztahuje na data tachografu nebo karty zpřístupněná v kontrolním, podnikovém nebo kalibračním režimu. Údaje a funkční přístupová práva jsou pro tyto režimy specifikovány v požadavcích 12 a 13.
Pro údaje ITS zprostředkované uvedeným rozhraním platí tyto požadavky:
—
osobní údaje jsou k dispozici pouze po získání ověřitelného souhlasu řidiče s tím, že osobní údaje mohou opustit síť vozidla.
Soubor vybraných stávajících údajů, které mohou být k dispozici prostřednictvím rozhraní ITS, a klasifikace údajů jako osobních či nikoli jsou uvedeny v dodatku 13. Kromě souboru údajů uvedeného v dodatku 13 mohou být výstupem rovněž další údaje. Výrobce celku ve vozidle klasifikuje tyto údaje jako „osobní“ nebo „neosobní“, přičemž souhlas řidiče se vztahuje na údaje klasifikované jako „osobní“,
—
pomocí příkazů v menu může být souhlas řidiče kdykoli vydán nebo zamítnut, je-li vložena karta řidiče,
—
přítomnost rozhraní ITS nesmí za žádných okolností narušovat nebo ovlivňovat správnou funkci a bezpečnost celku ve vozidle.
Další rozhraní celku ve vozidle mohou existovat vedle sebe, jsou-li plně v souladu s požadavky dodatku 13, pokud jde o souhlas řidiče. Záznamové zařízení musí být schopno informovat o stavu souhlasu řidiče ostatní platformy v síti vozidla a externí zařízení.
V případě osobních údajů vložených do sítě vozidla, které jsou dále zpracovávány mimo síť vozidla, není výrobce tachografu odpovědný za to, aby tento proces zpracování osobních údajů byl v souladu s platnými právními předpisy Unie o ochraně údajů.
Rozhraní ITS musí rovněž umožňovat vkládání údajů během postupu ručního zadávání údajů v souladu s požadavkem 61 jak pro řidiče, tak pro druhého řidiče.
Rozhraní ITS lze rovněž použít k zadávání dalších informací v reálném čase, jako jsou:
—
výběr činnosti řidiče v souladu s požadavkem 46,
—
místa v souladu s požadavkem 56,
—
zvláštní podmínky v souladu s požadavkem 62,
—
operace nakládky/vykládky v souladu s požadavkem 62a.
Tyto informace mohou být zadány i prostřednictvím jiných rozhraní.“;
c)
odstavec 201 se nahrazuje tímto:
„201)
Sériové rozhraní podle specifikace v příloze IB nařízení (EHS) č. 3821/85 v platném znění může být nadále používáno pro zpětnou slučitelnost tachografů. Sériové spojení je klasifikováno jako součást sítě vozidla v souladu s požadavkem 200.“;
21)
bod 3.21 se mění takto:
a)
odstavec 202 se mění takto:
i)
devátá odrážka se nahrazuje tímto:
„—
aktualizaci nebo potvrzení dalších parametrů známých záznamovému zařízení: identifikaci vozidla, charakteristický koeficient vozidla w, účinný obvod pneumatik l, rozměr pneumatik a v příslušných případech nastavení omezovače rychlosti a standardní druh nákladu,“;
ii)
doplňuje se nová odrážka, která zní:
„—
automatické uložení země, ve které byla kalibrace provedena, a data a času, kdy byla poloha použitá k určení této uvedené poskytnuta přijímačem GNSS.“;
b)
odstavec 205 se nahrazuje tímto:
„205)
Párování vnějšího zařízení GNSS s celkem ve vozidle musí spočívat minimálně v:
—
aktualizaci montážních údajů vnějšího zařízení GNSS ukládaných do vnějšího zařízení GNSS (podle potřeby),
—
kopírování potřebných identifikačních údajů vnějšího zařízení GNSS z vnějšího zařízení GNSS do datové paměti celku ve vozidle, včetně výrobního čísla vnějšího zařízení GNSS.“;
22)
v bodě 3.22 odst. 209 se doplňuje nový pododstavec, který zní:
„Jestliže je v souladu s tímto požadavkem aktivní režim I/O kalibračního signálového vodiče I/O, nesmí celek ve vozidle spustit výstrahu „jízda bez náležité karty“ (požadavek 75).“
23)
bod 3.23 se mění takto:
a)
odstavec 211 se nahrazuje tímto:
„211)
Nastavení času vnitřních hodin celku ve vozidle se provádí automaticky v různých časových intervalech. Následující automatická změna nastavení času se spustí mezi 72 hodinami a 168 hodinami po předchozím nastavení a poté, co má celek ve vozidle přístup k času GNSS prostřednictvím platné zprávy o ověřené poloze v souladu s dodatkem 12. Nastavení času však nesmí být nikdy větší než součtová maximální časová odchylka za den vypočtená výrobcem celku ve vozidle v souladu s požadavkem 41b. Je-li rozdíl mezi interním časem celku ve vozidle a časem přijímače GNSS větší než souhrnná maximální časová odchylka za den, pak se musí přenastavení času vnitřních hodin celku ve vozidle co nejvíce přiblížit času přijímače GNSS. Nastavení času lze provést pouze v případě, že čas poskytnutý přijímačem GNSS je získán pomocí zpráv o ověřené poloze, jak je uvedeno v dodatku 12. Referenční čas pro automatické nastavení času vnitřních hodin celku ve vozidle je čas uvedený v zprávě o ověřené poloze.“;
b)
odstavec 212 se nahrazuje tímto:
„212)
Funkce nastavení času musí v kalibračním režimu rovněž umožnit aktivované nastavení aktuálního času.
Dílny mohou upravit čas:
—
buď zapsáním časové hodnoty v celku ve vozidle pomocí služby WriteDataByIdentifier v souladu s oddílem 6.2 dodatku 8,
—
nebo požadováním sladění hodin celku ve vozidle s časem poskytnutým přijímačem GNSS. To lze provést pouze v případě, že čas poskytnutý přijímačem GNSS je získán pomocí zpráv o ověřené poloze. V takovém případě se služba RoutineControl použije v souladu s oddílem 8 dodatku 8.“;
24)
doplňují se nové body 3.27 a 3.28, které znějí:
„3.27
Monitorování překročení hranic
226 a)
Tato funkce musí detekovat, kdy vozidlo překročilo hranici země, kterou zemi opustilo a do které země vstoupilo.
226b)
Detekce překročení hranice je založena na poloze změřené záznamovým zařízením a uložené v digitální mapě v souladu s bodem 3.12.19.
226c)
Překročení hranic související s přítomností vozidla v zemi po dobu kratší než 120 s se nezaznamenávají.
3.28
Aktualizace softwaru
226d)
V celku ve vozidle musí být zahrnuta funkce pro provádění aktualizací softwaru pro případy, kdy takové aktualizace nezahrnují dostupnost dalších hardwarových zdrojů nad rámec zdrojů stanovených v požadavku 226f a orgány příslušné pro schvalování typu udělí povolení k aktualizacím softwaru na základě stávajícího typově schváleného celku ve vozidle v souladu s čl. 12 odst. 5 nařízení (EU) č. 165/2014.
226e)
Funkce aktualizace softwaru musí být navržena tak, aby kdykoli jsou vyžadovány právními předpisy, podporovala tyto funkční vlastnosti:
—
úprava funkcí uvedených v bodě 2.2, s výjimkou samotné funkce aktualizace softwaru,
—
přidání nových funkcí přímo souvisejících s prosazováním právních předpisů Unie v oblasti silniční dopravy,
—
úprava provozních režimů podle bodu 2.3,
—
změna struktury souboru, jako je přidání nových údajů nebo zvětšení velikosti souboru,
—
zavedení softwarových oprav (software patches) k řešení závad softwaru a bezpečnostních závad nebo nahlášených útoků na funkce záznamového zařízení.
226f)
Celek ve vozidle musí poskytovat volné hardwarové zdroje ve výši nejméně 35 % pro software a data potřebná k provedení požadavku 226e a volné hardwarové zdroje ve výši nejméně 65 % pro aktualizaci digitální mapy na základě hardwarových zdrojů požadovaných pro mapu NUTS 0 verze 2021.“;
25)
v bodě 4.1 za odstavcem 235 se obrázek „model Společenství karet tachografu“, zadní strana kontrolní karty, nahrazuje tímto:
„
“;
26)
bod 4.5 se mění takto:
a)
odstavec 246 se nahrazuje tímto:
„246)
Veškeré další údaje mohou být uloženy na kartách tachografu za předpokladu, že uchovávání těchto údajů je v souladu s platnými právními předpisy o ochraně údajů.“;
b)
v odstavci 247 se za druhou odrážku vkládá nová poznámka, která zní:
„Poznámka: verze 2 karet druhé generace obsahuje doplňující elementární soubory v DF Tachograph_G2.“;
c)
bod 4.5.3.2 se mění takto:
i)
nadpis se nahrazuje tímto:
„4.5.3.2
Aplikace tachografu 2. generace (nepřístupná pro celky ve vozidle první generace, přístupná pro verzi 1 a verzi 2 celku ve vozidle druhé generace)“;
ii)
Za bod 4.5.3.2.1 se doplňuje nový bod 4.5.3.2.1.1, který zní:
„4.5.3.2.1.1
Doplňující identifikace aplikace (není přístupné verzi 1 celků ve vozidle druhé generace)
278a)
Karta řidiče musí být schopna uchovat doplňující identifikační údaje aplikace, které se vztahují pouze na verzi 2.“;
iii)
v bodě 4.5.3.2.7 se odstavec 287 nahrazuje tímto:
„287)
Karta řidiče musí být schopna uchovat údaje vztahující se k posledním 12 událostem každého typu (tzn. 132 událostem).“;
iv)
v bodě 4.5.3.2.8 se odstavec 290 nahrazuje tímto:
„290)
Karta řidiče musí být schopna uchovat údaje vztahující se k posledním 24 závadám každého typu (tzn. 48 závadám).“;
v)
v bodě 4.5.3.2.9 se odstavec 292 nahrazuje tímto:
„292)
Paměť karty řidiče musí být schopna uchovat údaje o činnosti řidiče po dobu 56 dnů (průměrná činnost řidiče je pro tento požadavek definována jako 117 změn činnosti za den).“;
vi)
v bodě 4.5.3.2.10 se odstavec 295 nahrazuje tímto:
„295)
Karta řidiče musí být schopna uchovat 200 takových záznamů.“;
vii)
v bodě 4.5.3.2.11 se odstavec 297 nahrazuje tímto:
„297)
Paměť karty řidiče musí být schopna uchovat 112 takových záznamů.“;
viii)
v bodě 4.5.3.2.14 se odstavec 302 nahrazuje tímto:
„302)
Karta řidiče musí být schopna uchovat 112 takových záznamů.“;
ix)
v bodě 4.5.3.2.15 se odstavec 304 nahrazuje tímto:
„304)
Karta řidiče musí být schopna uchovat 200 takových záznamů.“;
x)
v bodě 4.5.3.2.16 se odstavec 306 nahrazuje tímto:
„306)
Karta řidiče musí být schopna uchovat 336 takových záznamů.“;
xi)
doplňují se nové body 4.5.3.2.17 až 4.5.3.2.22, které znějí:
„4.5.3.2.17
Status ověření pravosti pro polohy vztahující se k místům, kde denní pracovní doba začíná a/nebo končí (není přístupné verzi 1 celků ve vozidle druhé generace)
306a)
Karta řidiče musí být schopna uchovat doplňující údaje vztahující se k místům, kde začíná a/nebo končí denní pracovní doba, vložené řidičem v souladu s bodem 4.5.3.2.11:
—
datum a čas záznamu, které musí být naprosto shodné s datem a časem uloženými v EF Places pod DF Tachograph_G2,
—
příznak informující, zda byla poloha ověřena.
306b)
Paměť karty řidiče musí být schopna uchovat 112 takových záznamů.
4.5.3.2.18
Status ověření pravosti pro polohy, kde součtová doba řízení dosáhne tří hodin (není přístupné verzi 1 celků ve vozidle druhé generace)
306c)
Karta řidiče musí být schopna uchovat doplňující údaje vztahující se k poloze vozidla, kde součtová doba řízení dosáhne násobku tří hodin v souladu s bodem 4.5.3.2.16:
—
datum a čas, kdy součtová doba řízení dosáhne násobku tří hodin, které musí být naprosto shodné s datem a časem uloženými v EF GNSS_Places pod DF Tachograph_G2,
—
příznak informující, zda byla poloha ověřena.
306d)
Karta řidiče musí být schopna uchovat 336 takových záznamů.
4.5.3.2.19
Překročení hranic (není přístupné verzi 1 celků ve vozidle druhé generace)
306e)
Karta řidiče musí být schopna uchovat níže uvedené údaje týkající se překročení hranic buď při vložení karty v souladu s požadavkem 147b, nebo v případě již vložené karty:
—
zemi, kterou vozidlo opouští,
—
zemi, do které vozidlo vstupuje,
—
datum a čas, kdy vozidlo překročilo hranici,
—
polohu vozidla při překročení hranice,
—
přesnost GNSS,
—
příznak informující, zda byla poloha ověřena,
—
stav počitadla ujetých kilometrů.
306f)
Paměť karty řidiče musí být schopna uchovat 1120 takových záznamů.
4.5.3.2.20
Operace nakládky/vykládky (není přístupné verzi 1 celků ve vozidle druhé generace)
306g)
Karta řidiče musí být schopna uchovat tyto údaje týkající se operace nakládky/vykládky:
—
druh operace (nakládka, vykládka nebo souběžná nakládka a vykládka),
—
datum a čas nakládky/vykládky,
—
polohu vozidla,
—
přesnost GNSS, datum a čas, kdy byla poloha zjištěna,
—
příznak informující, zda byla poloha ověřena,
—
stav počitadla ujetých kilometrů.
306h)
Karta řidiče musí být schopna uchovat 1624 operací nakládky/vykládky.
4.5.3.2.21
Záznamy o druhu nákladu (není přístupné verzi 1 celků ve vozidle druhé generace)
306i)
Karta řidiče musí být schopna uchovat tyto údaje týkající se druhu nákladu automaticky zadané celkem ve vozidle při každém vložení karty:
—
zadaný druh nákladu (zboží nebo cestující),
—
datum a čas vložení údajů.
306j)
Karta řidiče musí být schopna uchovat 336 takových záznamů.
4.5.3.2.22
Konfigurace celku ve vozidle (není přístupné verzi 1 celků ve vozidle druhé generace)
306k)
Karta řidiče musí být schopna uchovat specifická nastavení tachografu držitele karty.
306l)
Úložná kapacita karty řidiče pro specifická nastavení tachografu držitele karty je 3072 bajtů.“;
d)
bod 4.5.4.2 se mění takto:
i)
nadpis se nahrazuje tímto:
„4.5.4.2
Aplikace tachografu 2. generace (nepřístupná pro celky ve vozidle první generace, přístupná pro verzi 1 a verzi 2 celku ve vozidle druhé generace)“;
ii)
za bod 4.5.4.2.1 se doplňuje nový bod 4.5.4.2.1.1, který zní:
„4.5.4.2.1.1
Doplňující identifikace aplikace (není přístupné verzi 1 celků ve vozidle druhé generace)
330a)
Karta dílny musí být schopna uchovat doplňující identifikační údaje aplikace, které se vztahují pouze na verzi 2.“;
iii)
v bodě 4.5.4.2.6 se odstavec 338 nahrazuje tímto:
„338)
Karta dílny musí být schopna uchovat 255 takových záznamů.“;
iv)
v bodě 4.5.4.2.8 se odstavec 344 nahrazuje tímto:
„344)
Karta dílny musí být schopna uchovat údaje o činnosti řidiče po dobu jednoho dne obsahující 240 změn činnosti.“;
v)
v bodě 4.5.4.2.9 se odstavec 346 nahrazuje tímto:
„346)
Karta dílny musí být schopna uchovat 8 takových záznamů.“;
vi)
bod 4.5.4.2.10 se nahrazuje tímto:
„4.5.4.2.10
Údaje o místech a polohách, kde začíná a/nebo končí denní pracovní doba
347)
Karta dílny musí být schopna uchovat údaje o začátku a/nebo konci denní pracovní doby stejným způsobem jako karta řidiče.
348)
Karta dílny musí být schopna uchovat čtyři páry takových záznamů.“;
vii)
v bodě 4.5.4.2.13 se odstavec 352 nahrazuje tímto:
„352)
Karta dílny musí být schopna uchovat 8 takových záznamů.“;
viii)
v bodě 4.5.4.2.14 se odstavec 354 nahrazuje tímto:
„354)
Karta dílny musí být schopna uchovat 24 takových záznamů.“;
ix)
v bodě 4.5.4.2.15 se odstavec 356 nahrazuje tímto:
„356)
Karta dílny musí být schopna uchovat 4 takové záznamy.“;
x)
doplňují se nové body 4.5.4.2.16 až 4.5.4.2.22, které znějí:
„4.5.4.2.16
Status ověření pravosti pro polohy vztahující se k místům, kde denní pracovní doba začíná a/nebo končí (není přístupné verzi 1 celků ve vozidle druhé generace)
356a)
Karta dílny musí být schopna uchovat doplňující údaje týkající se míst, kde denní pracovní doba začíná a/nebo končí stejným způsobem jako karta řidiče.
356b)
Paměť karty dílny musí být schopna uchovat nejméně 4 páry takových záznamů.
4.5.4.2.17
Status ověření pravosti pro pozice, kde součtová doba řízení dosáhne tří hodin (není přístupné verzi 1 celků ve vozidle druhé generace)
356c)
Karta dílny musí být schopna uchovat doplňující údaje vztahující se k poloze vozidla, kde součtová doba řízení dosáhne násobku tří hodin stejným způsobem jako karta řidiče.
356d)
Karta dílny musí být schopna uchovat 24 takových záznamů.
4.5.4.2.18
Překročení hranic (není přístupné verzi 1 celků ve vozidle druhé generace)
356e)
Karta dílny musí být schopna uchovat překročení hranic stejným způsobem jako karta řidiče.
356f)
Paměť karty dílny musí být schopna uchovat 4 takové záznamy.
4.5.4.2.19
Operace nakládky/vykládky (není přístupné verzi 1 celků ve vozidle druhé generace)
356g)
Karta dílny musí být schopna uchovat operace nakládky/vykládky stejným způsobem jako karta řidiče.
356h)
Karta dílny musí být schopna uchovat 8 operací nakládky, vykládky nebo souběžné nakládky a vykládky.
4.5.4.2.20
Záznamy o druhu nákladu (není přístupné verzi 1 celků ve vozidle druhé generace)
356i)
Karta dílny musí být schopna uchovat záznamy o druzích nákladu stejným způsobem jako karta řidiče.
356j)
Karta dílny musí být schopna uchovat 4 takové záznamy.
4.5.4.2.21
Doplňující údaje o kalibraci (není přístupné verzi 1 celků ve vozidle druhé generace)
356k)
Karta dílny musí být schopna uchovat doplňující údaje o kalibraci použitelné pouze pro verzi 2:
—
staré datum a čas a identifikační číslo vozidla, které musí být přesně stejné jako hodnoty uložené v EF Calibration pod DF Tachograph_G2,
—
standardní druh nákladu zadaný během této kalibrace,
—
země, ve které byla kalibrace provedena, a datum/čas, kdy byla poloha použitá k určení této země poskytnuta přijímačem GNSS.“;
356l)
Karta dílny musí být schopna uchovat 255 takových záznamů.
4.5.4.2.22
Konfigurace celku ve vozidle (není přístupné verzi 1 celků ve vozidle druhé generace)
356m)
Karta dílny musí být schopna uchovat specifická nastavení tachografu držitele karty.
356n)
Úložná kapacita karty dílny pro specifická nastavení tachografu držitele karty je 3072 bajtů.“;
e)
bod 4.5.5 se mění takto:
i)
V bodě 4.5.5.1.5 se druhá odrážka nahrazuje tímto:
„—
typ kontroly (zobrazení a/nebo vytištění a/nebo stahování dat celku ve vozidle a/nebo stahování dat karty),“;
ii)
Za bod 4.5.5.2.1 se doplňuje nový bod 4.5.5.2.1.1, který zní:
„4.5.5.2.1.1
Doplňující identifikace aplikace (není přístupné verzi 1 celků ve vozidle druhé generace)
363a)
Kontrolní karta musí být schopna uchovat doplňující identifikační údaje aplikace použitelné pouze pro verzi 2.“;
iii)
za bod 4.5.5.2.5 se vkládá nový bod, který zní:
„4.5.5.2.6
Konfigurace celku ve vozidle (není přístupné verzi 1 celků ve vozidle druhé generace)
368a)
Kontrolní karta musí být schopna uchovat specifická nastavení tachografu držitele karty.
368b)
Úložná kapacita kontrolní karty pro specifická nastavení tachografu držitele karty je 3072 bajtů.“;
f)
bod 4.5.6.2 se mění takto:
i)
za bod 4.5.6.2.1 se vkládá nový bod, který zní:
„4.5.6.2.1.1
Doplňující identifikace aplikace (není přístupné verzi 1 celků ve vozidle druhé generace)
375a)
Karta podniku musí být schopna uchovat doplňující identifikační údaje aplikace použitelné pouze pro verzi 2.“;
ii)
doplňuje se nový bod 4.5.6.2.6, který zní:
„4.5.6.2.6
Konfigurace celku ve vozidle (není přístupné verzi 1 celků ve vozidle druhé generace)
380a)
Karta podniku musí být schopna uchovat specifická nastavení tachografu držitele karty.
380b)
Úložná kapacita karty podniku pro specifická nastavení tachografu držitele karty je 3072 bajtů.“;
27)
bod 5 se mění takto:
a)
bod 5.1 se mění takto:
i)
odstavec 383 se nahrazuje tímto:
„383)
Záznamové zařízení nesmí před aktivací zaznamenávat ani ukládat údaje uvedené v požadavcích 102 až 133 včetně. Záznamové zařízení může nicméně před aktivací zaznamenávat a ukládat události pokusů o narušení zabezpečení v souladu s požadavkem 117 a závady záznamového zařízení v souladu s požadavkem 118.“;
ii)
odstavec 392 se nahrazuje tímto:
„392)
Po instalaci musí následovat kalibrace. První kalibrace nemusí nutně zahrnovat zadání identifikace registrace vozidla (VRN a členský stát), pokud ji schválená dílna, která má tuto kalibraci provést, nezná. Za těchto okolností musí mít vlastník vozidla možnost, a to pouze v tomto případě, zadat VRN a členský stát pomocí karty podniku před použitím vozidla v rámci působnosti nařízení (ES) č. 561/2006 (např. pomocí příkazů v příslušné struktuře nabídky rozhraní člověk-stroj celku ve vozidle). Případné pozměnění nebo potvrzení této položky musí být možné jen za použití karty dílny.“;
b)
bod 5.2 se mění takto:
i)
v odstavci 395 se první pododstavec nahrazuje tímto:
„Po provedení kontroly záznamového zařízení, která následuje po montáži, se na záznamové zařízení upevní dobře viditelný a snadno přístupný, rytý nebo trvanlivě tištěný montážní štítek. V případech, kdy toto není možné, musí být štítek upevněn na sloupek „B“ vozidla tak, aby byl dobře viditelný. U vozidel, která sloupek „B“ nemají, musí být montážní štítek upevněn v oblasti dveří vozidla a v každém případě musí být dobře viditelný.“;
ii)
odstavec 396 se mění takto:
1.
desátá odrážka se nahrazuje tímto:
„—
výrobní číslo případného zařízení pro dálkovou komunikaci,“;
2.
doplňuje se šestnáctá odrážka, která zní:
„—
standardní druh nákladu přiřazený k vozidlu.“;
28)
bod 6.4 se mění takto:
a)
odstavec 409 se nahrazuje tímto:
„409)
Pravidelná kontrola zařízení namontovaného do vozidla musí proběhnout po každé opravě zařízení, po jakékoliv změně charakteristického koeficientu vozidla, účinného obvodu pneumatik na kolech, odchylce referenčního času UTC o více než 5 minut, při změně VRN, ale minimálně jednou v průběhu dvou let (24 měsíců) od poslední prohlídky.“;
b)
v odstavci 410 se doplňuje nová devátá odrážka, která zní:
„—
že identifikátor verze uložené digitální mapy je nejnovější.“;
c)
vkládá se odstavec 410a, který zní:
„410a)
V případě zjištění manipulace příslušnými vnitrostátními orgány může být vozidlo odesláno do schválené dílny za účelem nové kalibrace záznamového zařízení.“;
29)
bod 8 se mění takto:
a)
v bodě 8.1 se odstavce 429 a 430 nahrazují tímto:
„429)
Postup aktualizace programového vybavení in situ v záznamovém zařízení musí být schválen orgánem, který vydal schválení typu pro záznamové zařízení. Aktualizace programového vybavení nesmí změnit ani vymazat žádné údaje o činnosti řidiče uložené v záznamovém zařízení. Programové vybavení může být aktualizováno pouze na odpovědnost výrobce zařízení.
430)
Schválení typu úprav programového vybavení zaměřených na aktualizaci záznamového zařízení s dřívějším schválením typu nesmí být zamítnuto, pokud takové úpravy platí pouze pro funkce, které nejsou uvedeny v této příloze. Aktualizace programového vybavení záznamového zařízení může vylučovat zavedení nových sad písma, není-li to technicky proveditelné.“;
b)
bod 8.4 se mění takto:
i)
odstavec 443 se nahrazuje tímto:
„443)
U záznamového zařízení nebo kart tachografu, které neprošly analýzou zranitelnosti v souvislosti s jejich hodnocením bezpečnosti a hodnocením funkčnosti, zkušebna neprovádí žádné zkoušky interoperability, s výjimkou případů výjimečných okolností popsaných v požadavku 432.“;
ii)
odstavec 447 se nahrazuje tímto:
„447)
Osvědčení o interoperabilitě vydá zkušebna výrobci teprve poté, co úspěšně proběhly všechny požadované zkoušky interoperability, a poté, co výrobce prokázal, že bylo pro výrobek vydáno platné osvědčení o funkčnosti i platné osvědčení o bezpečnosti, s výjimkou případů výjimečných okolností popsaných v požadavku 432.“;
30)
dodatek 1 se mění takto:
a)
obsah se mění takto:
i)
vkládají se nové body 2.11a a 2.11b, které znějí:
„2.11a
CardBorderCrossing
2.11b
CardBorderCrossingRecord“;
ii)
vkládají se nové body 2.24a, 2.24b, 2.24c a 2.24d, které znějí:
„2.24a
CardLoadTypeEntries
2.24b
CardLoadTypeEntryRecord
2.24c
CardLoadUnloadOperations
2.24d
CardLoadUnloadRecord“;
iii)
vkládá se nový bod 2.26a, který zní:
„2.26a
CardPlaceAuthDailyWorkPeriod“;
iv)
vkládá se nový bod 2.48a, který zní:
„2.48a
CompanyCardApplicationIdentificationV2“;
v)
vkládá se nový bod 2.50a, který zní:
„2.50a
ControlCardApplicationIdentificationV2“;
vi)
vkládá se nový bod 2.60a, který zní:
„2.60a
DownloadInterfaceVersion“;
vii)
vkládá se nový bod 2.61a, který zní:
„2.61a
DriverCardApplicationIdentificationV2“;
viii)
vkládají se nové body 2.79a, 2.79b a 2.79c, které znějí:
„2.79a
GNSSAuthAccumulatedDriving
2.79b
GNSSAuthStatusADRecord
2.79c
GNSSPlaceAuthRecord“;
ix)
bod 2.84 se nahrazuje tímto:
„2.84
Vyhrazeno pro budoucí použití“;
x)
vkládá se nový bod 2.89a, který zní:
„2.89a
LengthOfFollowingData“;
xi)
vkládá se nový bod 2.90a, který zní:
„2.90a
LoadType“;
xii)
vkládá se nový bod 2.101a, který zní:
„2.101a
NoOfBorderCrossingRecords“;
xiii)
vkládá se nový bod 2.111a, který zní:
„2.111a
NoOfLoadUnloadRecords“;
xiv)
vkládá se nový bod 2.112a, který zní:
„2.112a
NoOfLoadTypeEntryRecords“;
xv)
vkládá se nový bod 2.114a, který zní:
„2.114a
OperationType“;
xvi)
vkládají se nové body 2.116a a 2.116b, které znějí:
„2.116a
PlaceAuthRecord
2.116b
PlaceAuthStatusRecord“;
xvii)
vkládá se nový bod 2.117a, který zní:
„2.117a
PositionAuthenticationStatus“;
xviii)
vkládá se nový bod 2.158a, který zní:
„2.158a
TachographCardsGen1Suppression“;
xix)
vkládá se nový bod 2.166a, který zní:
„2.166a
VehicleRegistrationIdentificationRecordArray“;
xx)
vkládá se nový bod 2.185a, který zní:
„2.185a
VuConfigurationLengthRange“;
xxi)
vkládá se nový bod 2.192a, který zní:
„2.192a
VuDigitalMapVersion“;
xxii)
vkládají se nové body 2.203a a 2.203b, které znějí:
„2.203a
VuBorderCrossingRecord
2.203b
VuBorderCrossingRecordArray“;
xxiii)
vkládá se nový bod 2.204a, který zní:
„2.204a
VuGnssMaximalTimeDifference“;
xxiv)
vkládají se nové body 2.208a a 2.208b, které znějí:
„2.208a
VuLoadUnloadRecord
2.208b
VuLoadUnloadRecordArray“;
xxv)
vkládá se nový bod 2.222a, který zní:
„2.222a
VuRtcTime“;
xxvi)
vkládají se nové body 2.234a, 2.234b a 2.234c, které znějí:
„2.234a
WorkshopCardApplicationIdentificationV2
2.234b
WorkshopCardCalibrationAddData
2.234c
WorkshopCardCalibrationAddDataRecord“;
b)
v bodě 2 se text před bodem 2.1 nahrazuje tímto:
„Není-li stanoveno jinak, u všech následujících datových typů spočívá standardní hodnota pro „neznámý“ nebo „bezpředmětný“ obsah v naplnění daného datového prvku bajty Hex „FF“.
Není-li stanoveno jinak, všechny datové typy se použijí pro aplikace 1. a 2. generace. Jsou uvedeny datové typy používané pouze pro aplikace 2. generace 2. verze.
U typů dat karty používaných pro aplikace 1. a 2. generace je v tomto dodatku uvedena velikost pro aplikaci 2. generace. Má se za to, že velikost pro aplikaci 1. generace již čtečka zná. Čísla požadavků v příloze IC týkajících se těchto datových typů zahrnují aplikace 1. i 2. generace.
Typy dat karet, které nejsou definovány pro karty 1. generace, nejsou uloženy v aplikaci 1. generace karet 2. generace. Zejména:
—
čísla schválení typu uložená v aplikaci 1. generace karty 2. generace jsou v případě potřeby zkrácena na prvních 8 znaků,
—
v aplikaci 1. generace karty 2. generace se ukládá pouze „PŘEVOZ LODÍ / PŘEVOZ VLAKEM začátek“ specifické podmínky „PŘEVOZ LODÍ / PŘEVOZ VLAKEM“.“;
c)
vkládají se nové body 2.11a a 2.11b, které znějí:
„2.11a
CardBorderCrossings
2. generace, verze 2:
Informace uložené na kartě řidiče nebo na kartě dílny týkající se překročení hranic vozidlem, pokud vozidlo překročilo hranici země (požadavky 306f a 356f v příloze IC).
borderCrossingPointerNewestRecord je index posledního aktualizovaného záznamu karty o překročení hranic.
Přiřazení hodnoty je číslo odpovídající čítači záznamu karty o překročení hranic začínající hodnotou „0“ pro první výskyt záznamu karty o překročení hranic ve struktuře.
cardBorderCrossingRecords je sada záznamů karty o překročení hranic.
2.11b
CardBorderCrossingRecord
2. generace, verze 2:
Informace uložené na kartě řidiče nebo kartě dílny týkající se překročení hranic vozidlem, pokud vozidlo překročilo hranici země (požadavky 147b, 306e a 356e v příloze IC).
countryLeft je země, kterou vozidlo opustilo, nebo „nejsou k dispozici žádné informace“ podle požadavku 147b v příloze IC. „Rest of the World“ (Zbytek světa – NationNumeric code „FF“H) se použije, pokud celek ve vozidle není schopen určit zemi, kde se vozidlo nachází (např. aktuální země není součástí uložených digitálních map).
countryEntered je země, do které vozidlo vstoupilo, nebo země, v níž se vozidlo nachází v době vložení karty. „Rest of the World“ (Zbytek světa – NationNumeric code ‘FF’H) se použije v případě, že celek ve vozidle není schopen určit zemi, kde se vozidlo nachází (např. aktuální země není součástí uložených digitálních map).
gnssPlaceAuthRecord obsahuje informace týkající se polohy vozidla, pokud celek ve vozidle zjistil, že vozidlo překročilo hranici země, nebo „nejsou k dispozici žádné informace“ podle požadavku 147b v příloze IC, a statusu ověření pravosti uvedené polohy.
vehicleOdometerValue je stav počitadla ujetých kilometrů, pokud celek ve vozidle zjistil, že vozidlo překročilo hranici země, nebo „nejsou k dispozici žádné informace“ podle požadavku 147b v příloze IC.“;
d)
vkládají se nové body 2.24a, 2.24b, 2.24c a 2.24d, které znějí:
„2.24a
CardLoadTypeEntries
2. generace, verze 2:
Informace uložené na kartě řidiče nebo kartě dílny týkající se záznamů o druhu nákladu při vložení karty do celku ve vozidle (požadavky 306j a 356j v příloze IC).
loadTypeEntryPointerNewestRecord je index posledního aktualizovaného záznamu karty o druhu nákladu.
Přiřazení hodnoty: číslo odpovídající čítači záznamů na kartě o zadání druhu nákladu začínající hodnotou „0“ pro první výskyt záznamu na kartě o zadání druhu nákladu ve struktuře.
cardLoadTypeEntryRecords je sada záznamů obsahující datum a čas zadání a zadaný druh nákladu.
2.24b
CardLoadTypeEntryRecord
2. generace, verze 2:
Informace uložené na kartě řidiče nebo kartě dílny týkající se změn druhu nákladu zadaných při vložení karty do celku ve vozidle (požadavky 306i a 356i v příloze IC).
timeStamp (časové razítko) je datum a čas, kdy byl zadán druh nákladu.
loadTypeEntered je zadaný druh nákladu.
2.24c
CardLoadUnloadOperations
2. generace, verze 2:
Informace uložené na kartě řidiče nebo kartě dílny týkající se operací nakládky/vykládky vozidla (požadavky 306h a 356h v příloze IC).
loadUnloadPointerNewestRecord je index posledního aktualizovaného záznamu karty o nakládce/vykládce.
Přiřazení hodnoty: je číslo odpovídající čítači záznamu karty o nakládce/vykládce začínající hodnotou „0“ pro první výskyt záznamu karty o nakládce/vykládce ve struktuře.
cardLoadUnloadRecords je soubor záznamů obsahující údaj o typu provedené operace (nakládce, vykládce nebo souběžné nakládce a vykládce), datum a čas, kdy byla operace nakládky/vykládky zadána, informace o poloze vozidla a stav počitadla ujetých kilometrů.
2.24d
CardLoadUnloadRecord
2. generace, verze 2:
Informace uložené na kartě řidiče nebo kartě dílny týkající se operací nakládky/vykládky vozidla (požadavky 306g a 356g v příloze IC).
timeStamp (časové razítko) je datum a čas na začátku operace nakládky/vykládky.
operationType je druh zadané operace (nakládka, vykládka nebo souběžná nakládka a vykládka).
gnssPlaceRecord obsahuje informace týkající se polohy vozidla.
VehicleOdometerValue je stav počitadla ujetých kilometrů vztažený k zahájení operace nakládky/vykládky.“;
e)
vkládá se nový bod 2.26a, který zní:
„2.26a
CardPlaceAuthDailyWorkPeriod
2. generace, verze 2:
Informace uložené na kartě řidiče nebo kartě dílny, které poskytují status ověření pravosti míst, kde začíná a/nebo končí denní pracovní doba (požadavky 306b a 356b v příloze IC).
placeAuthPointerNewestRecord je index posledního aktualizovaného záznamu o statusu ověření pravosti místa.
Přiřazení hodnoty: Číslo odpovídající čítači záznamu o statusu ověření pravosti místa začínající hodnotou „0“ pro první výskyt záznamu o statusu ověření pravosti místa ve struktuře.
placeAuthStatusRecords je soubor záznamů se statusem ověření pravosti místa v případě zadaných míst.“;
f)
v bodě 2.36 se text odpovídající přiřazení hodnoty „bbH“ nahrazuje tímto:
„
‘bb’H Index pro změny týkající se používání datových prvků definovaných pro strukturu určenou vyšším bajtem.
‘00’H pro aplikace 1. generace
‘00’H pro verzi 1 aplikací 2. generace
‘01’H pro verzi 2 aplikací 2. generace“;
g)
v bodě 2.40 se odstavec mezi nadpisem a kódem nahrazuje tímto:
„2. generace:
Informace uložené na kartě řidiče nebo kartě dílny týkající se celků ve vozidle, které byly použity držitelem karty (požadavky 304 a 352 v příloze IC).“;
h)
vkládá se nový bod 2,48a, který zní:
„2.48a
CompanyCardApplicationIdentificationV2
2. generace, verze 2:
Informace uložené na kartě podniku týkající se identifikace aplikace karty (požadavek 375a v příloze IC).
lengthOfFollowingData je počet bajtů následujících v záznamu.
vuConfigurationLengthRange je počet bajtů v kartě tachografu, který je k dispozici pro ukládání konfigurací celku ve vozidle.“;
i)
vkládá se nový bod 2.50a, který zní:
„2.50a
ControlCardApplicationIdentificationV2
2. generace, verze 2:
Informace uložené na kontrolní kartě týkající se identifikace aplikace karty (požadavek 363a v příloze IC).
lengthOfFollowingData je počet bajtů následujících v záznamu.
vuConfigurationLengthRange je počet bajtů v kartě tachografu, který je k dispozici pro ukládání konfigurací celku ve vozidle.“;
j)
vkládá se nový bod 2.60a, který zní:
„2.60a
DownloadInterfaceVersion
2. generace, verze 2:
Kód označující verzi rozhraní pro stahování celku ve vozidle.
Přiřazení hodnoty: ‘aabb’H:
‘aa’H ‘00’H: neužívá se,
‘01’H: Celek ve vozidle 2. generace,
‘bb’H ‘00’H: neužívá se,
‘01’H: verze 2 celku ve vozidle 2. generace.“;
k)
vkládá se nový bod 2.61a, který zní:
„2.61a
DriverCardApplicationIdentificationV2
2. generace, verze 2:
Informace uložené na kartě řidiče týkající se identifikace aplikace karty (požadavek 278a v příloze IC).
lengthOfFollowingData je počet bajtů následujících v záznamu.
noOfBorderCrossingRecords je počet záznamů o překročení hranic, které může karta řidiče uložit.
noOfLoadUnloadRecords je počet záznamů o nakládce/vykládce se, které může karta řidiče uložit.
noOfLoadTypeEntryRecords je počet záznamů o zadání druhu nákladu, které může karta řidiče uložit.
vuConfigurationLengthRange je počet bajtů v kartě tachografu, který je k dispozici pro ukládání konfigurací celku ve vozidle.“;
l)
bod 2.63 se nahrazuje tímto:
„2.63
DSRCSecurityData
2. generace:
Definice tohoto datového typu viz dodatek 11.“;
m)
v bodě 2.66 se text odpovídající 2. generaci nahrazuje tímto:
„2. generace
Přiřazení hodnoty: dle ISO/IEC 8824-1.“;
n)
bod 2.70 se mění takto:
i)
nadpis odpovídající 2. generaci se nahrazuje tímto:
„2. generace, verze 1:“;
ii)
doplňuje se nový text, který zní:
„2. generace, verze 2:
‘0x’H
všeobecné události,
‘00’H
žádné další podrobnosti,
‘01’H
vložení neplatné karty,
‘02’H
konflikt karet,
‘03’H
časový přesah,
‘04’H
řízení bez náležité karty,
‘05’H
vložení karty během řízení,
‘06’H
poslední relace karty nebyla korektně uzavřena,
‘07’H
překročení povolené rychlosti,
‘08’H
přerušení napájení,
‘09’H
chyba údajů o pohybu vozidla,
‘0A’H
nesoulad údajů o pohybu vozidla,
‘0B’H
časový nesoulad (GNSS vůči vnitřním hodinám VU),
‘0C’H
chyba komunikace se zařízením pro dálkovou komunikaci,
‘0D’H
chybí informace o poloze z přijímače GNSS,
‘0E’H
chyba komunikace s vnějším zařízením GNSS,
‘0F’H
anomálie GNSS,
‘1x’H
události pokusů o narušení zabezpečení souvisejících s celkem ve vozidle,
‘10’H
žádné další podrobnosti,
‘11’H
chyba ověření pravosti snímače pohybu,
‘12’H
chyba ověření pravosti karty tachografu,
‘13’H
neoprávněná výměna snímače pohybu,
‘14’H
chyba integrity vstupních dat karty,
‘15’H
chyba integrity uložených uživatelských dat,
‘16’H
vnitřní chyba přenosu dat,
‘17’H
neoprávněné otevření krytu,
‘18’H
poškození technického vybavení,
‘19’H
detekce nedovolené manipulace s GNSS,
‘1A’H
chyba ověření pravosti vnějšího zařízení GNSS,
‘1B’H
skončila platnost certifikátu vnějšího zařízení GNSS,
‘1C’H
neshoda mezi údaji o pohybu a uloženými údaji o činnosti řidiče,
‘1D’H až ‘1F’H
vyhrazeno pro budoucí použití,
‘2x’H
události pokusů o narušení zabezpečení souvisejících se snímačem,
manufacturerCode je kód výrobce plomby. Přiřazení hodnoty: viz registrace databáze, kterou spravuje Evropská komise (viz https://dtc.jrc.ec.europa.eu ).
sealIdentifier je identifikátor plomby, který je jednoznačný pro výrobce. Přiřazení hodnoty: alfanumerický kód jedinečný v oblasti výrobce podle [ISO8859-1].“;
p)
v bodě 2.76 se odstavec mezi nadpisem a kódem nahrazuje tímto:
„2. generace:
Zeměpisné souřadnice jsou kódovány jako celá čísla. Tato celá čísla jsou násobky kódování ±DDMM.M pro zeměpisnou šířku a ±DDDMM.M pro zeměpisnou délku. Zde ±DD případně ±DDD označuje stupně a MM.M minuty. Zeměpisná délka a zeměpisná šířka neznámé polohy se vyobrazí jako Hex’7FFFFF’ (v desítkové soustavě 8388607).“;
q)
vkládají se nové body 2.79a, 2.79b a 2.79c, které znějí:
„2.79a
GNSSAuthAccumulatedDriving
2. generace, verze 2:
Informace uložené na kartě řidiče nebo kartě dílny poskytující status ověření pravosti polohy vozidla dle GNSS, pokud součtová doba řízení dosáhne násobku tří hodin (požadavky 306d a 356d v příloze IC).
gnssAuthADPointerNewestRecord je index posledního aktualizovaného záznamu statusu ověření pravosti polohy v systému GNSS.
Přiřazení hodnoty je číslo odpovídající čítači záznamu statusu ověření polohy v systému GNSS začínající hodnotou „0“ pro první výskyt záznamu statusu ověření pravosti polohy v systému GNSS ve struktuře.
gnssAuthStatusADRecords je sada záznamů obsahujících datum a čas, kdy součtová doba řízení dosáhne násobku tří hodin, a status ověření pravosti polohy GNSS.
2.79b
GNSSAuthStatusADRecord
2. generace, verze 2:
Informace uložené na kartě řidiče nebo kartě dílny, které poskytují status ověření pravosti polohy vozidla dle GNSS, pokud součtová doba řízení dosáhne násobku tří hodin (požadavky 306c a 356c v příloze IC). Další informace týkající se samotné polohy dle GNSS jsou uloženy v jiném záznamu (viz bod 2.79 GNSSAccumulatedDrivingRecord).
timeStamp (časové razítko) je datum a čas, kdy součtová doba řízení dosáhne násobku tří hodin (což je stejné datum a čas jako v odpovídajícím GNSSAccumulatedDrivingRecord).
authenticationStatus je status ověření pravosti polohy dle GNSS, když součtová doba řízení dosáhne násobku tří hodin.
2.79c
GNSSPlaceAuthRecord
2. generace, verze 2:
Informace týkající se polohy vozidla dle GNSS (požadavky 108, 109, 110, 296, 306a, 306c, 306e, 306g, 356a, 356c, 356e a 356g v příloze IC).
timeStamp je datum a čas, kdy byla určena poloha vozidla dle GNSS.
gnssAccuracy je přesnost údajů GNSS o poloze.
geoCoordinates je poloha zaznamenaná pomocí GNSS.
authenticationStatus je status ověření pravosti polohy dle GNSS v době, kdy byla určena.“;
r)
bod 2.84 se nahrazuje tímto:
„2.84
Vyhrazeno pro budoucí použití“;
s)
vkládá se nový bod 2.89a, který zní:
„2.89a
LengthOfFollowingData
2. generace, verze 2:
Ukazatel délky pro rozšiřitelné záznamy.
Přiřazení hodnoty: Viz dodatek 2.“;
t)
vkládá se nový bod 2.90a, který zní:
„2.90a
LoadType
2. generace, verze 2:
Kód označující zadaný druh nákladu.
Přiřazení hodnoty:
‘00’H
Nedefinovaný druh nákladu,
‘01’H
Zboží
‘02’H
Cestující
‘03’H .. ‘FF’H
Vyhrazeno pro budoucí použití.“;
u)
vkládá se nový bod 2.101a, který zní:
„2.101a
NoOfBorderCrossingRecords
2. generace, verze 2:
Počet záznamů o překročení hranic, které lze uložit na kartu řidiče nebo kartu dílny.
Přiřazení hodnoty: viz dodatek 2.“;
v)
vkládá se nový bod 2.111a, který zní:
„2.111a.
NoOfLoadUnloadRecords
2. generace, verze 2:
Počet záznamů o nakládce/vykládce, které lze na kartu uložit.
Přiřazení hodnoty: viz dodatek 2.“;
w)
vkládá se nový bod 2.112a, který zní:
„2.112a
NoOfLoadTypeEntryRecords
2. generace, verze 2:
Počet záznamů o zadání druhu nákladu, které lze na kartu řidiče nebo kartu dílny uložit.
Přiřazení hodnoty: viz dodatek 2.“;
x)
vkládá se nový bod 2.114a, který zní:
„2.114a
OperationType
2. generace, verze 2:
Kód označující druh zadané operace.
Přiřazení hodnoty:
‘00’H
vyhrazeno pro budoucí použití,
‘01’H
operace nakládky,
‘02’H
operace vykládky,
‘03’H
souběžná operace nakládky a vykládky,
‘04’H .. ‘FF’H
vyhrazeno pro budoucí použití.“;
y)
vkládají se nové body 2.116a a 2.116b, které znějí:
„2.116a.
PlaceAuthRecord
Informace týkající se místa, kde začíná nebo končí denní pracovní doba (požadavky 108, 271, 296, 324 a 347 v příloze IC).
2. generace, verze 2:
entryTime je datum a čas vztahující se k zadání.
entryTypeDailyWorkPeriod je typ zadání.
dailyWorkPeriodCountry je zadaná země.
dailyWorkPeriodRegion je zadaný region.
vehicleOdometerValue je stav počitadla ujetých kilometrů k okamžiku zadání místa.
entryGNSSPlaceAuthRecord je zaznamenané místo, status a čas ověření pravosti GNSS.
2.116b.
PlaceAuthStatusRecord
2. generace, verze 2:
Informace uložené na kartě řidiče nebo kartě dílny, které poskytují status ověření pravosti místa, kde začíná nebo končí denní pracovní doba (požadavky 306a a 356a v příloze IC). Další informace týkající se samotného místa jsou uloženy v jiném záznamu (viz 2.117 PlaceRecord).
entryTime je datum a čas vztahující se k zadání (což je stejné datum a čas jako v odpovídající položce PlaceRecord).
authenticationStatus je status ověření pravosti zaznamenané polohy dle GNSS.“;
z)
vkládá se nový bod 2.117a, který zní:
„2.117a
PositionAuthenticationStatus
2. generace, verze 2:
Přiřazení hodnoty (viz dodatek 12):
‘00’H
neověřeno (viz dodatek 12, požadavek GNS_39),
‘01’H
ověřeno (viz dodatek 12, požadavek GNS_39),
‘02’H .. ‘FF’H
vyhrazeno pro budoucí použití.“;
aa)
v bodě 2.120 se přiřazení hodnoty ‘22’H až ‘7F’H nahrazuje tímto:
‘‘22’H
VuBorderCrossingRecord,
‘23’H
VuLoadUnloadRecord,
‘24’H
VehicleRegistrationIdentification,
‘25’H až ‘7F’H
vyhrazeno pro budoucí použití.“;
bb)
vkládá se nový bod 2.158a, který zní:
„2.158a
TachographCardsGen1Suppression
2. generace, verze 2:
Schopnost VU druhé generace používat karty řidiče, kontrolní karty a karty podniku první generace (viz dodatek 15, MIG_002).
Přiřazení hodnoty:
‘0000’H
celek ve vozidle je schopen používat karty tachografu 1. generace (standardní hodnota),
‘A5E3’H
celek ve vozidle není schopen používat karty tachografu 1. generace,
všechny jiné hodnoty
nepoužívá se.’;
cc)
vkládá se nový bod 2.166a, který zní:
„2.166a
VehicleRegistrationIdentificationRecordArray
2. generace, verze 2:
identifikace registrace vozidla a metadata použitá v protokolu pro stahování.
recordType označuje typ záznamu (VehicleRegistrationIdentification). Přiřazení hodnoty: viz RecordType.
recordSize je velikost záznamu VehicleRegistrationIdentification v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada identifikace registrace vozidla.“;
dd)
v bodě 2.168 se první řádek za nadpisem nahrazuje tímto:
„2. generace, verze 1:“;
ee)
bod 2.174 se mění takto:
i)
nadpis 2. generace se nahrazuje tímto:
„2. generace, verze 1:“;
ii)
doplňuje se nový text, který zní:
„2. generace, verze 2:
Kromě prvků 1. generace se použije tento datový prvek:
sensorSerialNumber je výrobní číslo snímače pohybu spárovaného s celkem ve vozidle na konci kalibrace,
sensorGNSSSerialNumber je výrobní číslo vnějšího zařízení GNSS provázaného s celkem ve vozidle na konci kalibrace (pokud existuje),
rcmSerialNumber je výrobní číslo zařízení pro dálkovou komunikaci provázaného s celkem ve vozidle na konci kalibrace (pokud existuje),
sealDataVu uvádí informace o plombách, které jsou připojeny k různým částem vozidla.
byDefaultLoadType je standardní druh nákladu vozidla (týká se pouze verze 2).
calibrationCountry je země, ve které byla provedena kalibrace.
calibrationCountryTimestamp je datum a čas, kdy přijímač GNSS poskytl polohu použitou k určení země, ve které byla kalibrace provedena.“;
ff)
vkládá se nový bod 2.185a, který zní:
„2.185a
VuConfigurationLengthRange
2. generace, verze 2:
Počet bajtů v kartě tachografu, který je k dispozici pro uložení konfigurací VU.
Přiřazení hodnoty: viz dodatek 2.“;
gg)
vkládá se nový bod 2.192a, který zní:
„2.192a
VuDigitalMapVersion
2. generace, verze 2:
Verze digitální mapy uložené v celku ve vozidle (požadavek 133j v příloze IC).
Přiřazení hodnoty: jak je uvedeno na speciální zabezpečené internetové stránce zpřístupněné Evropskou komisí (požadavek 133k v příloze IC).“
hh)
bod 2.203 se mění takto:
i)
nadpis odpovídající 2. generaci se nahrazuje tímto:
„2. generace, verze 1:“;
ii)
doplňuje se nový text, který zní:
„2. generace, verze 2:
Informace uložené v celku ve vozidle týkající se polohy vozidla dle GNSS, pokud součtová doba řízení dosáhne násobku tří hodin (požadavky 108 a 110 v příloze IC).
Ve verzi 2 druhé generace se místo prvku gnssPlaceRecord používá prvek gnssPlaceAuthRecord, který navíc obsahuje status ověření pravosti GNSS.“;
ii)
vkládají se nové body 2.203a a 2.203b, které znějí:
„2.203a
VuBorderCrossingRecord
2. generace, verze 2:
Informace uložené v celku ve vozidle týkající se překročení hranic vozidlem, pokud vozidlo překročilo hranici země (požadavky 133a a 133b v příloze IC).
cardNumberAndGenDriverSlot identifikuje kartu vloženou v otvoru pro kartu řidiče, včetně její generace.
cardNumberAndGenCodriverSlot identifikuje kartu vloženou v otvoru pro kartu druhého řidiče, včetně její generace.
countryLeft je země, kterou vozidlo opustilo, na základě poslední dostupné polohy před zjištěním překročení hranice. „Rest of the World“ (Zbytek světa – NationNumeric code ‘FF’H) se použije, pokud celek ve vozidle není schopen určit zemi, kde se vozidlo nachází (např. aktuální země není součástí uložených digitálních map).
countryEntered je země, do které vozidlo vstoupilo. „Rest of the World“ (Zbytek světa – NationNumeric code ‘FF’H) se použije, pokud celek ve vozidle není schopen určit zemi, kde se vozidlo nachází (např. aktuální země není součástí uložených digitálních map).
gnssPlaceAuthRecord obsahuje informace týkající se polohy vozidla při zjištění překročení hranice a jejich status ověření pravosti.
vehicleOdometerValue je stav počitadla ujetých kilometrů, pokud celek ve vozidle zjistil, že vozidlo překročilo hranici země.
2.203b
VuBorderCrossingRecordArray
2. generace, verze 2:
Informace uložené v celku ve vozidle týkající se překročení hranic vozidlem (požadavek 133c v příloze IC).
recordType označuje typ záznamu (VuBorderCrossingRecord). Přiřazení hodnoty: viz RecordType.
recordSize je velikost záznamu VuBorderCrossingRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o překročení hranic.“;
jj)
vkládá se nový bod 2.204a, který zní:
„2.204a
VuGnssMaximalTimeDifference
2. generace, verze 2:
Maximální rozdíl mezi skutečným časem a časem hodin reálného času celku ve vozidle, jenž je založen na maximální časové odchylce určené v požadavku 041 v příloze IC, přenášený celkem ve vozidle na vnější zařízení GNSS, viz požadavek GNS_3g dodatku 12.
“;
kk)
v bodě 2.205 se text odpovídající 2. generaci nahrazuje tímto:
„2. generace:
Kromě prvků 1. generace se používají tyto datové prvky:
vuGeneration identifikuje generaci celku ve vozidle.
vuAbility poskytuje informaci, zda celek ve vozidle podporuje karty tachografu 1. generace, či nikoli.
vuDigitalMapVersion je verze digitální mapy uložená v celku ve vozidle (pouze ve verzi 2).“;
ll)
vkládají se nové body 2.208a a 2.208b, které znějí:
„2.208a
VuLoadUnloadRecord
2. generace, verze 2:
Informace uložené v celku ve vozidle týkající se zadané operace nakládky/vykládky (požadavky 133e, 133f a 133g v příloze IC).
timeStamp (časové razítko) je datum a čas, kdy byla zadána operace nakládky/vykládky.
operationType je druh zadané operace (nakládka, vykládka nebo souběžná nakládka a vykládka).
cardNumberAndGenDriverSlot identifikuje kartu vloženou v otvoru pro kartu řidiče, včetně její generace.
cardNumberAndGenCodriverSlot identifikuje kartu vloženou v otvoru pro kartu druhého řidiče, včetně její generace.
gnssPlaceAuthRecord obsahuje informace týkající se polohy vozidla a jejího statusu ověření pravosti.
VehicleOdometerValue je stav počitadla ujetých kilometrů týkající se operace nakládky/vykládky.
2.208b
VuLoadUnloadRecordArray
2. generace, verze 2:
Informace uložené v celku ve vozidle týkající se zadaného vozidla operace nakládky/vykládky (požadavek 133h v příloze IC).
recordType označuje typ záznamu (VuLoadUnloadRecord).Přiřazení hodnoty:: viz RecordType.
recordSize je velikost záznamu VuLoadUnloadRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o operaci nakládky/vykládky.“;
mm)
bod 2.219 se mění takto:
i)
nadpis 2. generace se nahrazuje tímto:
„2. generace, verze 1:“;
ii)
doplňuje se nový text, který zní:
„2. generace, verze 2:
Informace uložené v celku ve vozidle týkající se místa, kde řidič začíná nebo končí denní pracovní dobu (požadavek 087 přílohy 1B a požadavky 108 a 110 v příloze 1C).
Místo prvku placeRecord používá struktura dat 2. generace verze 2 tento datový prvek:
placeAuthRecord obsahuje informace týkající se zadaného místa, zaznamenané polohy, statusu ověření pravosti GNSS a času určení polohy.“;
nn)
za bod 2.222 se vkládá nový bod, který zní:
„2.222a
VuRtcTime
2. generace, verze 2:
Čas hodin reálného času celku ve vozidle přenášený celkem ve vozidle na vnějšího zařízení GNSS, viz požadavek GNS_3f dodatku 12.
“;
oo)
vkládají se nové body 2.234a, 2.234b a 2.234c, které znějí:
„2.234a
WorkshopCardApplicationIdentificationV2
2. generace, verze 2:
Informace uložené na kartě dílny týkající se identifikace aplikace karty (požadavek 330a v příloze IC).
lengthOfFollowingData je počet bajtů následujících v záznamu.
noOfBorderCrossingRecords je počet záznamů o překročení hranic, které lze na kartu dílny uložit.
noOfLoadUnloadRecords je počet záznamů o nakládce/vykládce, které lze na kartu dílny uložit.
noOfLoadTypeEntryRecords je počet záznamů o zadání druhu nákladu, které lze na kartu dílny uložit.
vuConfigurationLengthRange je počet bajtů v kartě tachografu, který je k dispozici pro ukládání konfigurací celku ve vozidle.
2.234b
WorkshopCardCalibrationAddData
2. generace, verze 2:
Informace uložené na kartě dílny týkající se doplňujících údajů (tj. standardního druhu nákladu) zadaných během kalibrace (požadavek 356l v příloze IC).
calibrationPointerNewestRecord je index naposledy aktualizovaného záznamu doplňujících údajů o kalibraci.
Přiřazení hodnoty je číslo odpovídající čítači záznamů doplňujících údajů o kalibraci začínající hodnotou „0“ pro první výskyt záznamu doplňujících údajů o kalibraci ve struktuře.
workshopCardCalibrationAddDataRecords je sada záznamů obsahující starou hodnotu data a času, hodnotu identifikace vozidla a standardní druh nákladu vozidla.
2.234c
WorkshopCardCalibrationAddDataRecord
2. generace, verze 2:
Informace uložené na kartě dílny týkající se standardního druhu nákladu zadaného během kalibrace (požadavek 356k v příloze IC).
oldTimeValue je stará hodnota data a času obsažená v odpovídajícím prvku WorkshopCardCalibrationRecord,
vehicleIdentificationNumber je identifikační číslo vozidla, které je rovněž obsaženo v odpovídajícím prvku WorkshopCardCalibrationRecord,
byDefaultLoadType je standardní druh nákladu vozidla (existuje pouze ve verzi 2).
calibrationCountry je země, ve které byla provedena kalibrace.
calibrationCountryTimestamp je datum a čas, kdy přijímač GNSS poskytl polohu použitou k určení této země.“;
31)
dodatek 2 se mění takto:
a)
v bodě 2.5 se druhý pododstavec v odstavci TCS_09 nahrazuje tímto:
„provozní stav během vykonávání příkazů nebo propojení s celkem ve vozidle,“;
b)
bod 3 se mění takto:
i)
v bodě 3.2.1 se zrušuje čtvrtá odrážka odstavce TCS_16,
ii)
bod 3.5.7.2 se mění takto:
1.
odstavec TCS_86 se nahrazuje tímto:
„TCS_86
Příkaz lze provést v MF, DF Tachograph a DF Tachograph_G2, viz rovněž TCS_34.“;
2)
odstavce TCS_88 a TCS_89 se nahrazují tímto:
„TCS_88
Pro APDU s krátkou délkou platí tato ustanovení: IFD musí použít minimální počet APDU potřebných pro přenesení přenášených dat příkazu a přenést maximální počet bajtů v APDU prvního příkazu. Každá hodnota „Lc“ až do 255 bajtů však musí být podporována kartou.
TCS_89 Pro APDU s rozšířenou délkou platí tato ustanovení: Nevejde-li se certifikát do jedné APDU, musí karta podporovat řetězení příkazů. IFD musí použít minimální počet APDU potřebných pro přenesení přenášených dat příkazu a přenést maximální počet bajtů v APDU prvního příkazu. Je-li třeba řetězení, musí být každá hodnota „Lc“ až do uvedené maximální prodloužené délky podporována kartou.
Pozn.: V souladu s dodatkem 11 uloží karta certifikát nebo relevantní obsah certifikátu a aktualizuje svou hodnotu currentAuthenticatedTime.
Struktura zprávy s odpovědí a stavové bajty jsou definovány v TCS_85.“;
iii)
v bodě 3.5.10 odstavci TCS_101 se poslední řádek tabulky nahrazuje tímto:
„Le
1
‘00h’
Podle specifikace v ISO/IEC 7816-4
“;
iv)
v bodě 3.5.16 odstavci TCS_138 se poslední řádek tabulky nahrazuje tímto:
„Le
1
‘00h’
Podle specifikace v ISO/IEC 7816-4
“;
c)
bod 4 se mění takto:
i)
v odstavci TCS_141 se druhý pododstavec nahrazuje tímto:
„Maximální a minimální počty záznamů jsou pro různé aplikace specifikovány v této kapitole. Ve verzi 2 2. generace karty řidiče a karty dílny musí aplikace 1. generace podporovat maximální počet záznamů specifikovaný v TCS_150 a TCS_158.“;
ii)
v bodě 4.2.1 se tabulka TCS_150 mění takto:
1.
řádek týkající se prvku cardIssuingAuthorityName je se nahrazuje tímto:
„
“;
2)
řádek týkající se prvku LastCardDownload se nahrazuje tímto:
„
“;
iii)
bod 4.2.2 se mění takto:
1)
odstavec TCS_152 se nahrazuje tímto:
„TCS_152
Po personalizaci má aplikace karty řidiče 2. generace níže uvedenou trvalou strukturu souborů a pravidla přístupu k souborům:
Poznámky:
—
Krátký identifikátor EF SFID je uváděn jako číslo v desítkové soustavě, tj. hodnota 30 odpovídá binární hodnotě 11110.
—
EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF VU_Configuration a EF Load_Type_Entries jsou přítomny pouze ve verzi 2 karty řidiče 2. generace.
—
CardStructureVersion v EF Application_Identification se rovná {01 01} pro verzi 2 karty řidiče 2. generace, zatímco pro verzi 1 karty řidiče 2. generace byl roven {01 00}.
V této tabulce jsou použity níže uvedené zkratky pro bezpečnostní podmínky:
SC1
ALW nebo SM-MAC-G2
SC5
Pro příkaz Read Binary se sudým bajtem INS: SM-C-MAC-G2 a SM-R-ENC-MAC-G2
Pro příkaz Read Binary s lichým bajtem INS (je-li podporován): NEV“;
2)
odstavec TCS_154 se nahrazuje tímto:
„TCS_154
Aplikace karty řidiče 2. generace musí mít tuto strukturu dat:
“;
3)
v odstavci TCS_155 se tabulka nahrazuje tímto:
„
Min
Max
n1
NoOfEventsPerType
12
12
n2
NoOfFaultsPerType
24
24
n3
NoOfCardVehicleRecords
200
200
n4
NoOfCardPlaceRecords
112
112
n6
CardActivityLengthRange
13776 bajtů
(56 dnů * 117 změn činnosti)
13776 bajtů
(56 dnů * 117 změn činnosti)
n7
NoOfCardVehicleUnitRecords
200
200
n8
NoOfGNSSADRecords
336
336
n9
NoOfSpecificConditionRecords
112
112
n10
NoOfBorderCrossingRecords
1120
1120
n11
NoOfLoadUnloadRecords
1624
1624
n12
NoOfLoadTypeEntryRecords
336
336
n13
VuConfigurationLengthRange
3072 bajtů
3072 bajtů
“;
iv)
bod 4.3.2 se mění takto:
1)
odstavec TCS_160 se nahrazuje tímto:
„TCS_160
Po personalizaci musí mít aplikace karty dílny 2. generace následující trvalou strukturu souborů a pravidla přístupu k souborům:
Poznámky:
—
Krátký identifikátor EF SFID je uváděn jako číslo v desítkové soustavě, tj. hodnota 30 odpovídá binární hodnotě 11110.
—
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 a EF Calibration_Add_Data jsou přítomny pouze ve verzi 2 karty dílny 2. generace.
—
CardStructureVersion v EF Application_Identification se rovná {01 01} pro verzi 2 karty dílny 2. generace, zatímco pro verzi 1 karty dílny 2. generace byl roven {01 00}.
V této tabulce jsou pro bezpečnostní podmínky použity tyto zkratky:
SC1
ALW nebo SM-MAC-G2
SC5
Pro příkaz Read Binary se sudým bajtem INS: SM-C-MAC-G2 a SM-R-ENC-MAC-G2
Pro příkaz Read Binary s lichým bajtem INS (je-li podporován): NEV“;
(2)
v odstavci TCS_162 se tabulka nahrazuje tímto:
„
“;
3)
v odstavci TCS_163 se tabulka nahrazuje tímto:
„
Min
Max
n1
NoOfEventsPerType
3
3
n2
NoOfFaultsPerType
6
6
n3
NoOfCardVehicleRecords
8
8
n4
NoOfCardPlaceRecords
8
8
n5
NoOfCalibrationRecords
255
255
n6
CardActivityLengthRange
492 bajtů (1 den * 240 změn činnosti)
492 bajtů (1 den *
240 změn činnosti)
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 bajtů
3072 bajtů
“;
v)
bod 4.4.2 se mění takto:
1)
odstavec TCS_168 se nahrazuje tímto:
„TCS_168
Po personalizaci musí mít aplikace kontrolní karty 2. generace následující trvalou strukturu souborů a pravidla přístupu k souborům:
Poznámky:
—
Krátký identifikátor EF SFID je uváděn jako číslo v desítkové soustavě, tj. hodnota 30 odpovídá binární hodnotě 11110.
—
EF Application_Identification_V2 a EF VU_Configuration jsou přítomny pouze ve verzi 2 kontrolní karty 2. generace.
—
CardStructureVersion v EF Application_Identification se rovná {01 01} pro verzi 2 kontrolní karty 2. generace, zatímco pro verzi 1 kontrolní karty 2. generace byl roven {01 00}.
V této tabulce jsou pro bezpečnostní podmínky použity tyto zkratky:
SC1
ALW nebo SM-MAC-G2
SC5
Pro příkaz Read Binary se sudým bajtem INS: SM-C-MAC-G2 a SM-R-ENC-MAC-G2
Pro příkaz Read Binary s lichým bajtem INS (je-li podporován): NEV“;
2)
v odstavci TCS_170 se tabulka nahrazuje tímto:
„
“;
3)
v odstavci TCS_171 se tabulka nahrazuje tímto:
„
Min
Max
n7
NoOfControlActivityRecords
230
520
n13
VuConfigurationLengthRange
3072 bajtů
3072 bajtů
“;
vi)
bod 4.5.2 se mění takto:
1.
odstavec TCS_176 se nahrazuje tímto:
„TCS_176
Po personalizaci musí mít aplikace karty podniku 2. generace následující trvalou strukturu souborů a pravidla přístupu k souborům:
Poznámky:
—
Krátký identifikátor EF SFID je uváděn jako číslo v desítkové soustavě, tj. hodnota 30 odpovídá binární hodnotě 11110.
—
EF Application_Identification_V2 a EF VU_Configuration jsou přítomny pouze ve verzi 2 karty podniku 2. generace.
—
CardStructureVersion v EF Application_Identification se rovná {01 01} pro verzi 2 karty následující 2. generace, zatímco pro verzi 1 karty následující 2. generace byl roven{01 00}.
V této tabulce jsou pro bezpečnostní podmínky použity tyto zkratky:
SC1
ALW nebo SM-MAC-G2
SC5
Pro příkaz Read Binary se sudým bajtem INS: SM-C-MAC-G2 a SM-R-ENC-MAC-G2
Pro příkaz Read Binary s lichým bajtem INS (je-li podporován): NEV“;
2)
v odstavci TCS_178 se tabulka nahrazuje tímto:
„
“;
3)
v odstavci TCS_179 se tabulka nahrazuje tímto:
„
Min
Max
n8
NoOfCompanyActivityRecords
230
520
n13
VuConfigurationLengthRange
3072 bajtů
3072 bajtů
“;
32)
dodatek 3 se mění takto:
a)
bod 1 se mění takto:
i)
odstavec o zvláštních podmínkách se nahrazuje tímto:
„
Zvláštní podmínky, ruční zadávání
mimo působnost
převoz lodí / převoz vlakem
operace nakládky
operace vykládky
souběžná operace nakládky a vykládky
druh nákladu: cestující
druh nákladu: zboží
druh nákladu: nedefinovaný druh nákladu“;
ii)
piktogramy pro různé položky se mění takto:
1.
piktogram zabezpečení se nahrazuje tímto:
„
zabezpečení / ověřené údaje / plomby“;
2)
doplňuje se tento nový piktogram:
„
digitální mapa / hraniční přechod“;
b)
bod 2 se mění takto:
i)
do piktogramů pro různé položky se doplňují tyto kombinace piktogramů:
„
poloha, kde vozidlo překročilo hranici mezi dvěma zeměmi
poloha, kde došlo k operaci nakládky
poloha, kde došlo k operaci vykládky
poloha, kde došlo k souběžné operaci nakládky a vykládky“;
ii)
do piktogramů pro výtisky se doplňuje tato kombinace piktogramů:
„
výtisk historie vložených karet“;
iii)
do piktogramů pro události se doplňuje tato kombinace piktogramů:
„
anomálie GNSS“;
33)
dodatek 4 se mění takto:
a)
v bodě 1 se odstavec PRT_005 nahrazuje tímto:
„PRT_005
Řetězcová datová pole se tisknou zarovnaná doleva a doplněná mezerami na délku datové položky, nebo v případě potřeby zkrácená na délku datové položky. Jména či názvy a adresy mohou být vytištěny ve dvou řádcích.“;
b)
bod 2 se mění takto:
i)
za tabulku a před odstavec PRT_007 se vkládají nové odrážky, které znějí:
„—
v datovém bloku se text za „pi =“ vztahuje k odpovídajícímu piktogramu nebo kombinaci piktogramů definovaných v dodatku 3,
-
je-li piktogram vytištěný za zeměpisnou délkou a zeměpisnou šířkou zaznamenané polohy nebo za časovým razítkem doby určení polohy, piktogram označuje, že tato poloha byla vypočtena z ověřených navigačních zpráv,
-
* údaje jsou k dispozici pouze v tachografech GEN2 (všechny verze),
-
** údaje jsou k dispozici pouze ve verzi 2 GEN2.“;
ii)
bloky 2 a 3 se nahrazují tímto:
„
V případě, že se jedná o neosobní kartu bez příjmení držitele, se místo uvedeného příjmení vytiskne název podniku, dílny či kontrolního orgánu.“;
iii)
před blokem 4 se zrušuje věta, před níž je uvedena hvězdička;
iv)
za blok 4 se vkládá nový blok, který zní:
„
“;
v)
blok 5 se nahrazuje tímto:
„
“;
vi)
před blokem 6 se zrušuje věta, před níž je uvedena hvězdička;
vii)
za blok 8a se vkládá nový blok, který zní:
„
“;
viii)
blok 8.2 se nahrazuje tímto:
„
“;
ix)
blok 10.2 se nahrazuje tímto:
„
“;
x)
před blokem 11 se zrušuje věta, před níž je uvedena hvězdička;
xi)
bloky 11.4 a 11.5 se nahrazují tímto:
„
“;
xii)
blok 14 se nahrazuje tímto:
„
“;
xiii)
blok 15.1 se nahrazuje tímto:
„
“;
xiv)
bloky 16 a 16.1 se nahrazují tímto:
„
16
Identifikace GNSS*
“;
xv)
blok 17.1 se nahrazuje tímto:
„
Účel kalibrace (p) je číselný kód vysvětlující, proč byly kalibrační parametry zaznamenány, kódovaný v souladu s datovým prvkem CalibrationPurpose“;
xvi)
blok 23 se nahrazuje tímto:
„
“
c)
bod 3 se mění takto:
i)
v bodě 3.1 se odstavec PRT_008 nahrazuje tímto:
„PRT_008
Denní výtisk činností řidiče z karty musí mít následující formát:
“;
ii)
v bodě 3.2 se odstavec PRT_009 nahrazuje tímto:
„PRT_009
Denní výtisk činností řidiče z VU musí mít následující formát:
“;
iii)
v bodě 3.5 se odstavec PRT_012 nahrazuje tímto:
„PRT_012
Výtisk technických dat musí mít tento formát:
“;
iv)
v bodě 3.7 se odstavec PRT_014 nahrazuje tímto:
„PRT_014
Výtisk historie vložených karet musí mít tento formát:
“;
34)
dodatek 7 se mění takto:
a)
obsah se mění takto:
i)
body 2.2.6.1 až 2.2.6.5 se nahrazují tímto:
„2.2.6.1
Positive Response Transfer Data Download Interface Version
2.2.6.2
Positive Response Transfer Data Overview
2.2.6.3
Positive Response Transfer Data Activities
2.2.6.4
Positive Response Transfer Data Events and Faults
2.2.6.5
Positive Response Transfer Data Detailed Speed’;
ii)
doplňuje se nový bod, který zní:
„2.2.6.6
Positive Response Transfer Data Technical Data“;
b)
bod 2 se mění takto:
i)
v bodě 2.2.2 se tabulka struktury zprávy a poznámky za tabulkou nahrazují tímto:
„
Struktura zprávy
Max. 4 bajty
Max. 255 bajtů
1 bajt
Záhlaví
Data
Kontrolní součet
IDE ->
<- VU
FMT
TGT
SRC
LEN
SID
DS_ / TRTP
DATA
CS
Start Communication Request
81
EE
F0
81
E0
Positive Response Start Communication
80
F0
EE
03
C1
EA, 8F
9B
Start Diagnostic Session Request
80
EE
F0
02
10
81
F1
Positive Response Start Diagnostic
80
F0
EE
02
50
81
31
Link Control Service
Verify Baud Rate (stage 1)
9 600 Bd
80
EE
F0
04
87
01
01,01
EC
19 200 Bd
80
EE
F0
04
87
01
01,02
ED
38 400 Bd
80
EE
F0
04
87
01
01,03
EE
57 600 Bd
80
EE
F0
04
87
01
01,04
EF
115 200 Bd
80
EE
F0
04
87
01
01,05
F0
Positive Response Verify Baud Rate
80
F0
EE
02
C7
01
28
Transition Baud Rate (stage 2)
80
EE
F0
03
87
02
03
ED
Request Upload
80
EE
F0
0A
35
00,00,00,00,00,FF,FF, FF,FF
99
Positive Response Request Upload
80
F0
EE
03
75
00,FF
D5
Transfer Data Request
Download interface version
80
EE
F0
02
36
00
96
Overview
80
EE
F0
02
36
01, 21 nebo 31
CS
Activities
80
EE
F0
06
36
02, 22 nebo 32
Date
CS
Events & Faults
80
EE
F0
02
36
03, 23 nebo 33
Date
CS
Detailed Speed
80
EE
F0
02
36
04 nebo 24
Datum
CS
Technical Data
80
EE
F0
02
36
05, 25 nebo 35
Date
CS
Card download
80
EE
F0
02 nebo 03
36
06
Slot
CS
Positive Response Transfer Data
80
F0
EE
Len
76
TREP
Data
CS
Request Transfer Exit
80
EE
F0
01
37
96
Positive Response Request Transfer Exit
80
F0
EE
01
77
D6
Stop Communication Request
80
EE
F0
01
82
E1
Positive Response Stop Communication
80
F0
EE
01
C2
21
Acknowledge sub message
80
EE
F0
Len
83
Data
CS
Negative responses
General reject
80
F0
EE
03
7F
Sid Req
10
CS
Service not supported
80
F0
EE
03
7F
Sid Req
11
CS
Sub function not supported
80
F0
EE
03
7F
Sid Req
12
CS
Incorrect Message Length
80
F0
EE
03
7F
Sid Req
13
CS
Conditions not correct or Request sequence error
80
F0
EE
03
7F
Sid Req
22
CS
Request out of range
80
F0
EE
03
7F
Sid Req
31
CS
Upload not accepted
80
F0
EE
03
7F
Sid Req
50
CS
Response pending
80
F0
EE
03
7F
Sid Req
78
CS
Data not available
80
F0
EE
03
7F
Sid Req
FA
CS
Poznámky:
—
Sid Req = SID odpovídajícího požadavku.
—
TREP = TRTP odpovídajícího požadavku.
—
Tmavé buňky znamenají, že se nic nepřenáší.
—
Termín „odeslání dat“ („upload“, z pohledu IDE) se používá z důvodu slučitelnosti s ISO 14229. Znamená totéž jako stahování dat („download“, z pohledu VU).
—
Případné 2bajtové čítače dílčích zpráv nejsou v tabulce uvedeny.
—
Slot je číslo otvoru pro kartu, buď „1“ (karta v otvoru pro kartu řidiče), nebo „2“ (karta v otvoru pro kartu druhého řidiče).
—
Není-li otvor specifikován, VU vybere otvor č. 1, pokud je v něm vložena karta, a otvor č. 2 vybere jen v případě, že jej explicitně vybere uživatel.
—
TRTP 24 se použije pro požadavky na stahování dat z VU typu 2. generace verze 1 a verze 2.
—
TRTP 00, 31, 32, 33 a 35 se použijí pro požadavky na stahování dat z VU typu 2. generace verze 2.
—
TRTP 21, 22, 23 a 25 se použijí pro požadavky na stahování dat z VU typu 2. generace verze 1.
—
TRTP 01 až 05 se použijí pro požadavky na stahování dat z VU typu 1. generace. Mohou být volitelně akceptovány pro 2. generaci VU, ale pouze v rámci kontroly řidičů prováděné kontrolním orgánem mimo EU za použití kontrolní karty první generace.
—
TRTP 11 až 1F jsou vyhrazeny pro zvláštní požadavky výrobce na stahování.“;
ii)
bod 2.2.2.9 se mění takto:
1.
v odstavci DDP_011 se druhý pododstavec a první tabulka nahrazují tímto:
„Existuje sedm typů přenosu dat. V případě stahování dat z VU lze pro každý přenos dat použít dvě různé hodnoty TRTP:
Typ přenosu dat
Hodnota TRTP pro stahování dat z VU
typu 1. generace
Hodnota TRTP pro stahování dat z VU
typu 2. generace, verze 1
Hodnota TRTP pro stahování dat z VU
typu 2. generace, verze 2
Verze rozhraní pro stahování
Nepoužito
Nepoužito
00
Přehled (Overview)
01
21
31
Činnosti v daný den (Activities of a specified date)
02
22
32
Události a závady (Events and faults)
03
23
33
Podrobnosti o rychlosti (Detailed speed)
04
24
24
Technická data (Technical data)
05
25
35
“;
2)
odstavec DDP_054 se nahrazuje tímto:
„DDP_054
IDE v rámci relace stahování povinně žádá o přenos dat přehledu (TRTP 01, 21 nebo 31), neboť jedině tak lze zajistit, že ve staženém souboru budou zaznamenány certifikáty VU (a bude možné ověřit digitální podpis).
V druhém případě (TRTP 02, 22 nebo 32) zpráva Transfer Data Request obsahuje kalendářní den (ve formátu TimeReal), za který se mají data stáhnout.“;
iii)
v bodě 2.2.2.10 se text před odrážkami v odstavci DDP_055 nahrazuje tímto:
„DDP_055
V prvním případě (TREP 01, 21 nebo 31) VU pošle data, která operátorovi IDE pomohou vybrat data, která chce dále stáhnout. Informace obsažené v této zprávě jsou:“;
iv)
v bodě 2.2.5.2 se obrázek 2 nahrazuje tímto:
Obrázek 2 Zpracování chyb celkem ve vozidle
“;
v)
body 2.2.6.1 až 2.2.6.5 se nahrazují tímto:
„2.2.6.1
Positive Response Transfer Data Download Interface Version
DDP_028a.
Datové pole zprávy „Positive Response Transfer Data Download Version“ musí poskytovat následující data v uvedeném pořadí podle SID 76 Hex, TREP 00 Hex:
Datová struktura 2. generace verze 2 (TREP 00 Hex)“;
Datový prvek
Poznámka
DownloadInterfaceVersion
Generace a verze VU: 02,02 Hex pro 2. generaci verzi 2.
Nepodporuje VU 1. generace a 2. generace verze 1, které musí odeslat zápornou odpověď (podfunkce nepodporována, viz DDP_018)
2.2.6.2
Positive Response Transfer Data Overview
DDP_029
Datové pole zprávy „Positive Response Transfer Data Overview“ musí poskytovat následující data v uvedeném pořadí, přičemž se použije SID 76 Hex, TREP 01, 21 nebo 31 Hex a patřičné rozdělení do dílčích zpráv a jejich počítání:“;
Datová struktura 1. generace (TREP 01 Hex)“;
Datový prvek
Poznámka
MemberStateCertificate
Bezpečnostní certifikáty VU
VUCertificate
VehicleIdentificationNumber
Identifikace vozidla
VehicleRegistrationIdentification
CurrentDateTime
Aktuální datum a čas VU
VuDownloadablePeriod
Období, které lze stáhnout
CardSlotsStatus
Typy karet vložených do VU
VuDownloadActivityData
Předchozí stažení dat z VU
VuCompanyLocksData
Všechny uložené zámky podniku. Pokud je tato sekce prázdná, odešle se pouze noOfLocks = 0.
VuControlActivityData
Všechny záznamy o kontrole uložené ve VU. Pokud je tato sekce prázdná, odešle se pouze noOfControls = 0.
Signature
Podpis RSA všech dat (kromě certifikátů), počínaje VehicleIdentificationNumber a konče posledním bajtem posledního prvku VuControlActivityData.
Datová struktura 2. generace verze 1 (TREP 21 Hex)
Datový prvek
Poznámka
MemberStateCertificateRecordArray
Certifikát členského státu
VUCertificateRecordArray
Certifikát VU
VehicleIdentificationNumberRecordArray
Identifikace vozidla
VehicleRegistrationIdentificationRecordArray
Registrační značka vozidla
CurrentDateTimeRecordArray
Aktuální datum a čas VU
VuDownloadablePeriodRecordArray
Období, které lze stáhnout
CardSlotsStatusRecordArray
Typy karet vložených do VU
VuDownloadActivityDataRecordArray
Předchozí stažení dat z VU
VuCompanyLocksRecordArray
Všechny uložené zámky podniku. Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuControlActivityRecordArray
Všechny záznamy o kontrole uložené ve VU. Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
SignatureRecordArray
Podpis ECC všech předcházejících dat kromě certifikátů.
Datová struktura 2. generace verze 2 (TREP 31 Hex)
Datový prvek
Poznámka
MemberStateCertificateRecordArray
Certifikát členského státu
VUCertificateRecordArray
Certifikát VU
VehicleIdentificationNumberRecordArray
Identifikace vozidla
VehicleRegistrationNumberRecordArray
Registrační značka vozidla
CurrentDateTimeRecordArray
Aktuální datum a čas VU
VuDownloadablePeriodRecordArray
Období, které lze stáhnout
CardSlotsStatusRecordArray
Typy karet vložených do VU
VuDownloadActivityDataRecordArray
Předchozí stažení dat z VU
VuCompanyLocksRecordArray
Všechny uložené zámky podniku. Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuControlActivityRecordArray
Všechny záznamy o kontrole uložené ve VU. Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
SignatureRecordArray
Podpis ECC všech předcházejících dat kromě certifikátů.
2.2.6.3
Positive Response Transfer Data Activities
DDP_030
Datové pole zprávy „Positive Response Transfer Data Activities“ musí obsahovat následující data v uvedeném pořadí, přičemž se použije SID 76 Hex, TREP 02, 22 nebo 32 Hex a patřičné rozdělení do dílčích zpráv a jejich počítání:
Datová struktura 1. generace (TREP 02 Hex)
Datový prvek
Poznámka
TimeReal
Datum stahovaného dne
OdometerValueMidnight
Stav počitadla ujetých kilometrů na konci stahovaného dne
VuCardIWData
Data o cyklech vložení a vyjmutí karet.
—
Pokud tato sekce neobsahuje žádná dostupná data, odešle se pouze noOfVuCardIWRecords = 0.
—
Pokud prvek VuCardIWRecord přesahuje 00:00 (karta byla vložena předešlý den) nebo 24:00 (karta byla vyjmuta následující den), musí být celý obsažen v obou příslušných dnech.
VuActivityDailyData
Status otvorů pro karty v 00:00 a změny činnosti zaznamenané pro stahovaný den.
VuPlaceDailyWorkPeriodData
Data týkající se míst zaznamenaná pro stahovaný den. Pokud je tato sekce prázdná, odešle se pouze noOfPlaceRecords = 0.
VuSpecificConditionData
Data týkající se zvláštních podmínek zaznamenaná pro stahovaný den. Pokud je tato sekce prázdná, odešle se pouze noOfSpecificConditionRecords=0.
Signature
Podpis RSA všech dat, počínaje prvkem TimeReal a konče posledním bajtem posledního záznamu zvláštních podmínek.
Datová struktura 2. generace verze 1 (TREP 22 Hex)
Datový prvek
Poznámka
DateOfDayDownloadedRecordArray
Datum stahovaného dne
OdometerValueMidnightRecordArray
Stav počitadla ujetých kilometrů na konci stahovaného dne
VuCardIWRecordArray
Data o cyklech vložení a vyjmutí karet.
—
Pokud tato sekce neobsahuje žádná dostupná data, odešle se hlavička pole s noOfRecords = 0.
—
Pokud prvek VuCardIWRecord přesahuje 00:00 (karta byla vložena předešlý den) nebo 24:00 (karta byla vyjmuta následující den), musí být celý obsažen v obou příslušných dnech.
VuActivityDailyRecordArray
Status otvorů pro karty v 00:00 a změny činnosti zaznamenané pro stahovaný den.
VuPlaceDailyWorkPeriodRecordArray
Data týkající se míst zaznamenaná pro stahovaný den. Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuGNSSADRecordArray
Polohy vozidla dle GNSS, když součtová doba řízení vozidla dosáhne násobku tří hodin. Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuSpecificConditionRecordArray
Data týkající se zvláštních podmínek zaznamenaná pro stahovaný den. Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
SignatureRecordArray
Podpis ECC všech předcházejících dat.
Datová struktura 2. generace verze 2 (TREP 32 Hex)
Datový prvek
Poznámka
DateOfDayDownloadedRecordArray
Datum stahovaného dne
OdometerValueMidnightRecordArray
Stav počitadla ujetých kilometrů na konci stahovaného dne
VuCardIWRecordArray
Data o cyklech vložení a vyjmutí karet.
—
Pokud tato sekce neobsahuje žádná dostupná data, odešle se hlavička pole s noOfRecords = 0.
—
Pokud prvek VuCardIWRecord přesahuje 00:00 (karta byla vložena předešlý den) nebo 24:00 (karta byla vyjmuta následující den), musí být celý obsažen v obou příslušných dnech.
VuActivityDailyRecordArray
Status otvorů pro karty v 00:00 a změny činnosti zaznamenané pro stahovaný den.
VuPlaceDailyWorkPeriodRecordArray
Data týkající se míst zaznamenaná pro stahovaný den. Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuGNSSADRecordArray
Polohy vozidla dle GNSS, když součtová doba řízení vozidla dosáhne násobku tří hodin. Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuSpecificConditionRecordArray
Data týkající se zvláštních podmínek zaznamenaná pro stahovaný den. Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuBorderCrossingRecordArray
Překročení hranic pro stažený den. Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuLoadUnloadRecordArray
Operace nakládky/vykládky pro stažený den. Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
SignatureRecordArray
Podpis ECC všech předcházejících dat.
2.2.6.4
Positive Response Transfer Data Events and Faults
DDP_031
Datové pole zprávy „Positive Response Transfer Data Events and Faults“ musí poskytovat následující data v uvedeném pořadí, přičemž se použije SID 76 Hex, TREP 03, 23 nebo 33 Hex a patřičné rozdělení do dílčích zpráv a jejich počítání:
Datová struktura 1. generace (TREP 03 Hex)
Datový prvek
Poznámka
VuFaultData
Všechny závady uložené nebo probíhající ve VU.
Pokud je tato sekce prázdná, odešle se pouze noOfVuFaults = 0.
VuEventData
Všechny události (kromě překročení povolené rychlosti) uložené nebo probíhající ve VU.
Pokud je tato sekce prázdná, odešle se pouze noOfVuEvents = 0.
VuOverSpeedingControlData
Data týkající se poslední kontroly překročení povolené rychlosti (výchozí hodnota, nejsou-li žádná data).
VuOverSpeedingEventData
Všechny události překročení povolené rychlosti uložené ve VU.
Pokud je tato sekce prázdná, odešle se pouze noOfVuOverSpeedingEvents = 0.
VuTimeAdjustmentData
Všechny události nastavení času uložené ve VU (mimo rámec úplné kalibrace).
Pokud je tato sekce prázdná, odešle se pouze noOfVuTimeAdjRecords = 0.
Signature
Podpis RSA všech dat, počínaje prvkem noOfVuFaults a konče posledním bajtem posledního záznamu o nastavení času.
Datová struktura 2. generace verze 1 (TREP 23 Hex)
Datový prvek
Poznámka
VuFaultRecordArray
Všechny závady uložené nebo probíhající ve VU.
Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuEventRecordArray
Všechny události (kromě překročení povolené rychlosti) uložené nebo probíhající ve VU.
Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuOverSpeedingControlDataRecordArray
Data týkající se poslední kontroly překročení povolené rychlosti (výchozí hodnota, nejsou-li žádná data).
VuOverSpeedingEventRecordArray
Všechny události překročení povolené rychlosti uložené ve VU.
Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuTimeAdjustmentRecordArray
Všechny události nastavení času uložené ve VU (mimo rámec úplné kalibrace).
Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
SignatureRecordArray
Podpis ECC všech předcházejících dat.
Datová struktura 2. generace verze 2 (TREP 33 Hex)
Datový prvek
Poznámka
VuFaultRecordArray
Všechny závady uložené nebo probíhající ve VU.
Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuEventRecordArray
Všechny události (kromě překročení povolené rychlosti) uložené nebo probíhající ve VU.
Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuOverSpeedingControlDataRecordArray
Data týkající se poslední kontroly překročení povolené rychlosti (výchozí hodnota, nejsou-li žádná data).
VuOverSpeedingEventRecordArray
Všechny události překročení povolené rychlosti uložené ve VU.
Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
VuTimeAdjustmentRecordArray
Všechny události nastavení času uložené ve VU (mimo rámec úplné kalibrace).
Pokud je tato sekce prázdná, odešle se hlavička pole s noOfRecords = 0.
SignatureRecordArray
Podpis ECC všech předcházejících dat.
2.2.6.5
Positive Response Transfer Data Detailed Speed
DDP_032
Datové pole zprávy „Positive Response Transfer Data Detailed Speed“ musí obsahovat následující data v uvedeném pořadí, přičemž se použije SID 76 Hex, TREP 04 nebo 24 Hex a patřičné rozdělení do dílčích zpráv a jejich počítání:
Datová struktura 1. generace (TREP 04 Hex)
Datový prvek
Poznámka
VuDetailedSpeedData
Všechny podrobnosti o rychlosti uložené ve VU (jeden blok rychlostí za minutu, během níž se vozidlo pohybovalo),
60 hodnot rychlosti za minutu (jedna za sekundu).
Signature
Podpis RSA všech dat, počínaje prvkem noOfSpeedBlocks a konče posledním bajtem posledního bloku rychlostí.
Datová struktura 2. generace (TREP 24 Hex)
Datový prvek
Poznámka
VuDetailedSpeedBlockRecordArray
Všechny podrobnosti o rychlosti uložené ve VU (jeden blok rychlostí za minutu, během níž se vozidlo pohybovalo),
60 hodnot rychlosti za minutu (jedna za sekundu).
SignatureRecordArray
Podpis ECC všech předcházejících dat.
“;
vi)
doplňuje se nové písmeno, které zní:
„2.2.6.6
Positive Response Transfer Data Technical Data
DDP_033
Datové pole zprávy „Positive Response Transfer Data Technical Data“ musí obsahovat následující data v uvedeném pořadí, přičemž se použije SID 76 Hex, TREP 05, 25 nebo 35 Hex a patřičné rozdělení do dílčích zpráv a jejich počítání:
Datová struktura 1. generace (TREP 05 Hex)
Datový prvek
Poznámka
VuIdentification
SensorPaired
VuCalibrationData
Všechny záznamy o kalibraci uložené ve VU.
Signature
Podpis RSA všech dat, počínaje prvkem vuManufacturerName a konče posledním bajtem posledního záznamu VuCalibrationRecord.
Datová struktura 2. generace verze 1 (TREP 25 Hex)
Datový prvek
Poznámka
VuIdentificationRecordArray
VuSensorPairedRecordArray
Všechna párování snímačů pohybu uložená ve VU.
VuSensorExternalGNSSCoupledRecordArray
Všechny vazby s vnějšími zařízeními GNSS uložené ve VU.
VuCalibrationRecordArray
Všechny záznamy o kalibraci uložené ve VU.
VuCardRecordArray
Všechna data o vložení karty uložená ve VU.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray
Podpis ECC všech předcházejících dat.
Datová struktura 2. generace verze 2 (TREP 35 Hex)
Datový prvek
Poznámka
VuIdentificationRecordArray
VuSensorPairedRecordArray
Všechna párování snímačů pohybu uložená ve VU.
VuSensorExternalGNSSCoupledRecordArray
Všechny vazby s vnějšími zařízeními GNSS uložené ve VU.
VuCalibrationRecordArray
Všechny záznamy o kalibraci uložené ve VU.
VuCardRecordArray
Všechna data o vložení karty uložená ve VU.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray
Podpis ECC všech předcházejících dat.
“;
c)
v bodě 3.3 se odstavec DDP_035 nahrazuje tímto:
„DDP_035
Stahování z karty tachografu zahrnuje následující kroky:
—
Stažení společných informací karty v elementárních souborech (EF) ICC a IC. Tyto informace jsou nepovinné a nejsou zabezpečeny digitálním podpisem.
—
U karet tachografu první a druhé generace
—
Stažení EF v rámci Tachograph DF:
—
Stažení EF Card_Certificate a CA_Certificate. Tyto informace nejsou zabezpečeny digitálním podpisem.
Tyto soubory musí být povinně staženy v rámci každé relace stahování.
—
Stažení EF s dalšími daty aplikace (v rámci Tachograph DF) kromě EF Card_Download. Tyto informace jsou zabezpečeny digitálním podpisem za použití mechanismů v souladu s dodatkem 11 „Společné bezpečnostní mechanismy“ částí A.
—
V každé relaci stahování musí být povinně staženy alespoň EF Application_Identification a Identification.
—
Při stahování z karty řidiče musí být rovněž povinně staženy tyto EF:
—
Events_Data,
—
Faults_Data,
—
Driver_Activity_Data,
—
Vehicles_Used,
—
Places,
—
Control_Activity_Data,
—
Specific_Conditions.
—
Pouze u karet tachografu druhé generace:
—
Kromě případů, kdy stahování z karty řidiče vložené do VU provádí během kontroly řidičů kontrolní orgán, který nepatří do EU, za použití kontrolní karty první generace, stažení EF v rámci Tachograph_G2 DF:
—
Stažení EF CardSignCertificate, CA_Certificate a Link_Certificate. Tyto informace nejsou zabezpečeny digitálním podpisem.
—
Tyto soubory musí být povinně staženy v rámci každé relace stahování.
—
Stažení EF s dalšími daty aplikace (v rámci Tachograph_G2 DF) kromě EF Card_Download. Tyto informace jsou zabezpečeny digitálním podpisem za použití mechanismů v souladu s dodatkem 11 „Společné bezpečnostní mechanismy“ částí B.
—
V každé relaci stahování musí být povinně staženy alespoň elementární soubory Application_Identification, Application_Identification_V2 (je-li k dispozic) a Identification.
—
Při stahování z karty řidiče musí být rovněž povinně staženy tyto EF:
—
Events_Data,
—
Faults_Data,
—
Driver_Activity_Data,
—
Vehicles_Used,
—
Places,
—
Control_Activity_Data,
—
Specific_Conditions,
—
VehicleUnits_Used,
—
GNSS_Places,
—
Places_Authentication, je-li k dispozici,
—
GNSS_Places_Authentication, je-li k dispozici,
—
Border_Crossings, je-li k dispozici,
—
Load_Unload_Operations, je-li k dispozici,
—
Load_Type_Entries, je-li k dispozici.
—
Při stahování z karty řidiče aktualizujte datum LastCardDownload v EF Card_Download v DF Tachograph a případně Tachograph_G2.
—
Při stahování z karty dílny vynulujte počítadlo kalibrací v EF Card_Download v DF Tachograph a případně Tachograph_G2.
—
Při stahování z karty dílny se nestahuje EF Sensor_Installation_Data v DF Tachograph a případně Tachograph_G2.“;
35)
dodatek 8 se mění takto:
a)
obsah se mění takto:
i)
Body 8, 8.1 a 8.2 se nahrazují tímto:
„8.
SLUŽBA ROUTINECONTROL (NASTAVENÍ ČASU)
8.1.
Popis zprávy
8.2.
Formát zprávy“;
ii)
doplňují se nové body 9, 9.1 a 9.2, které znějí:
„9.
FORMÁTY DATARECORDS
9.1.
Rozsahy přenášených parametrů
9.2.
Formáty dataRecords“;
b)
v bodě 3.1 se v tabulce 1 doplňuje nový řádek, který zní:
„
Diagnostické relace
RoutineControl
8
31
“;
c)
v bodě 6.1.3 se odstavec CPR_053 nahrazuje tímto:
„CPR_053
Hodnoty recordDataIdentifier, definované tímto dokumentem, jsou uvedeny v tabulce níže.
Tabulka recordDataIdentifier je tvořena pěti sloupci a několika řádky.
—
První sloupec (Hex) obsahuje „hexadecimální hodnotu“ přiřazenou k prvku recordDataIdentifier specifikovanému ve třetím sloupci.
—
Druhý sloupec (Datový prvek) stanovuje datový prvek podle dodatku 1, na kterém je založen prvek recordDataIdentifier (někdy je nutné překódování),
—
Třetí sloupec (Popis) stanovuje odpovídající název prvku recordDataIdentifier,
—
Čtvrtý sloupec (Přístupová práva) stanovuje přístupová práva k tomuto prvku recordDataIdentifier.
—
Pátý sloupec (Symbol) stanovuje pro tento prvek recordDtaIdentifier příslušný symbol.
Tabulka 28
Definice hodnot recordDataIdentifier
Hex
Datový prvek
Název prvku recordDataIdentifier
(viz formát v bodě 8.2)
Přístupová práva
(Čtení/Zápis)
Symbol
F90B
CurrentDateTime
TimeDate
R/W
RDI_TD
F912
HighResOdometer
HighResolutionTotalVehicleDistance
R/W
RDI_HRTVD
F918
K-ConstantOfRecordingEquipment
Kfactor
R/W
RDI_KF
F91C
L-TyreCircumference
LfactorTyreCircumference
R/W
RDI_LF
F91D
W-VehicleCharacteristicConstant
WvehicleCharacteristicFactor
R/W
RDI_WVCF
F921
TyreSize
TyreSize
R/W
RDI_TS
F922
nextCalibrationDate
NextCalibrationDate
R/W
RDI_NCD
F92C
SpeedAuthorised
SpeedAuthorised
R/W
RDI_SA
F97D
vehicleRegistrationNation
RegisteringMemberState
R/W
RDI_RMS
F97E
VehicleRegistrationNumber
VehicleRegistrationNumber
R/W
RDI_ VRN
F190
VehicleIdentificationNumber
VIN
R/W
RDI_ VIN
F9D0
SensorSerialNumber
MotionSensorSerialNumber
R
RDI_SSN
F9D1
RemoteCommunicationModuleSerialNumber
RemoteCommunicationFacilitySerialNumber
R
RDI_RCSN
F9D2
SensorGNSSSerialNumber
ExternalGNSSFacilitySerialNumber
R
RDI_GSSN
F9D3
SealDataVu
SmartTachographSealsSerialNumber
R/W
RDI_SDV
F9D4
VuSerialNumber
VuSerialNumber
R
RDI_VSN
F9D5
ByDefaultLoadType
ByDefaultLoadType
R/W
RDI_BDLT
F9D6
TachographCardsGen1Suppression
TachographCardsGen1Suppression
R/W
RDI_TCG1S
F9D7
VehiclePosition
VehiclePosition
R
RDI_VP
F9D8
LastCalibrationCountry
CalibrationCountry
R
RDI_CC
“;
d)
bod 8 se nahrazuje tímto:
„8.
SLUŽBA ROUTINECONTROL (NASTAVENÍ ČASU)
8.1.
Popis zprávy
CPR_065a
Služba RoutineControl (TimeAdjustment) umožňuje spustit nastavení hodin VU na čas poskytnutý přijímačem GNSS.
Pro provádění služby RoutineControl (TimeAdjustment) musí být celek ve vozidle v režimu CALIBRATION.
Předpoklad: je zajištěno, že je VU schopen přijímat zprávy o ověřené poloze z přijímače GNSS.
Po dobu, kdy probíhá nastavení času, musí VU odpovědět na žádost RoutineControl, podfunkci requestRoutineResults, přičemž routineInfo = 0x78.
Poznámka: nastavení času může nějakou dobu trvat. Diagnostické zkušební zařízení požádá o status nastavení času pomocí dílčí funkce requestRoutineResults.
8.2.
Formát zprávy
CPR_065b
Formáty zpráv pro službu RoutineControl (TimeAdjustment) a její prvky jsou podrobně popsány v následujících tabulkách.
Tabulka 37a
RoutineControl, zpráva s požadavkem na provedení rutiny (TimeAdjustment), podfunkce startRoutine
obecná pravidla, která se mají použít na rozsahy parametrů přenášených celkem ve vozidle do zkušebního zařízení,
—
formáty, které mají být použity u dat přenášených pomocí služeb přenosu dat popsaných v části 6.
CPR_067
Veškeré identifikované parametry musí být podporovány celkem ve vozidle.
CPR_068
Data přenášená celkem ve vozidle do zkušebního zařízení jako odpověď na zprávu s požadavkem musí být naměřeného typu (tj. musí se jednat o aktuální hodnotu požadovaného parametru naměřenou nebo zjištěnou celkem ve vozidle).
9.1
Rozsahy přenášených parametrů
CPR_069
Tabulka 38 definuje rozsahy použité ke stanovení platnosti přenášených parametrů.
CPR_070
Hodnoty v rozsahu „error indicator“ (indikátor chyby) jsou pro celek ve vozidle prostředkem, jak okamžitě indikovat, že v důsledku nějakého druhu chyby v tachografu nejsou momentálně dostupná platná parametrická data.
CPR_071
Hodnoty v rozsahu „not available“ (nedostupné) jsou pro celek ve vozidle prostředkem, jak předat zprávu, která obsahuje parametr, který není v daném modulu dostupný nebo není podporován. Hodnoty v rozsahu „not requested“ (nevyžádané) jsou pro zařízení prostředkem, jak předat zprávu s příkazem a identifikovat ty parametry, u kterých se neočekává žádná odpověď z přijímacího zařízení.
CPR_072
Pokud závada některé součásti brání přenosu platných dat parametru, je možné místo dat parametru použít „error indicator“ (indikátor chyby) podle popisu v tabulce 38. Pokud však naměřená nebo vypočtená data poskytují hodnotu, která je platná, ale přesahuje definovaný rozsah parametru, neměl by být „error indicator“ (indikátor chyby) použit. Data by měla být přenesena využitím přiměřené minimální nebo maximální hodnoty parametru.
Tabulka 38
Rozsahy dataRecords
Název rozsahu
1 bajt
(hexadecimální hodnota)
2 bajty
(hexadecimální hodnota)
4 bajty
(hexadecimální hodnota)
ASCII
Platný signál
00 až FA
0000 až FAFF
00000000 až FAFFFFFF
1 až 254
Specifický indikátor parametru
FB
FB00 až FBFF
FB000000 až FBFFFFFF
žádný
Rezervní rozsah pro budoucí indikační bity
FC až FD
FC00 až FDFF
FC000000 až FDFFFFFF
žádný
Indikátor chyby
FE
FE00 až FEFF
FE000000 až FEFFFFFF
0
Nedostupné nebo nevyžádané
FF
FF00 až FFFF
FF000000 až FFFFFFFF
FF
CPR_073
Pro parametry kódované v ASCII je ASCII symbol „*“ vyhrazen jako oddělovací znak.
9.2
Formáty dataRecords
V níže uvedených tabulkách 39 až 42 jsou podrobně uvedeny formáty, které musí být použity prostřednictvím služeb ReadDataByIdentifier a WriteDataByIdentifier.
CPR_074
V tabulce 39 je uvedena délka, rozlišení a pracovní rozsah každého z parametrů identifikovaných pomocí jeho recordDataIdentifier.
Tabulka 39
Formát dataRecords
Název parametru
Délka dat (v bajtech)
Rozlišení
Pracovní rozsah
TimeDate
8
Podrobnosti viz tabulka 40
HighResolutionTotalVehicleDistance
4
přírůstek 5 m/bit, offset 0 m
0 až +21 055 406 km
Kfactor
2
přírůstek 0,001 imp/m/bit, offset 0
0 až 64,255 imp/m
LfactorTyreCircumference
2
přírůstek 0,125 10-3 m /bit, offset 0
0 až 8,031 m
WvehicleCharacteristicFactor
2
přírůstek 0,001 imp/m/bit, offset 0
0 až 64,255 imp/m
TyreSize
15
ASCII
ASCII
NextCalibrationDate
3
Podrobnosti viz tabulka 41
SpeedAuthorised
2
přírůstek 1/256 km/h/bit, offset 0
0 až 250,996 km/h
RegisteringMemberState
3
ASCII
ASCII
VehicleRegistrationNumber
14
Podrobnosti viz tabulka 42
VIN
17
ASCII
ASCII
SealDataVu
55
Podrobnosti viz tabulka 43
ByDefaultLoadType
1
Podrobnosti viz tabulka 44
VuSerialNumber
8
Podrobnosti viz tabulka 45
SensorSerialNumber
8
Podrobnosti viz tabulka 45
SensorGNSSSerialNumber
8
Podrobnosti viz tabulka 45
RemoteCommunicationModuleSerialNumber
8
Podrobnosti viz tabulka 45
TachographCardsGen1Suppression
2
Podrobnosti viz tabulka 46
VehiclePosition
14
Podrobnosti viz tabulka 47
CalibrationCountry
3
ASCII
NationAlpha podle definice v dodatku 1
CPR_075
Tabulka 40 rozepisuje formáty různých bajtů parametru TimeDate:
Tabulka 40
Rozepsaný formát TimeDate (recordDataIdentifier, s hodnotou # F90B)
Bajt
Definice parametru
Rozlišení
Pracovní rozsah
1
Sekundy
přírůstek 0,25 s/bit, offset 0 s
0 až 59,75 s
2
Zápis ze zasedání
přírůstek 1 min/bit, offset 0 min
0 až 59 min
3
Hodiny
přírůstek 1 h/bit, offset 0 h
0 až 23 h
4
Měsíc
přírůstek 1 měsíc/bit, offset 0 měsíců
1 až 12 měsíců
5
Den
přírůstek 0,25 dne/bit, offset 0 dnů (viz POZNÁMKA níže tabulka 41)
0,25 až 31,75 dne
6
Rok
přírůstek 1 rok/bit, offset rok +1985
(viz POZNÁMKA pod tabulkou 41)
roky 1985 až 2235
7
Místní offset v minutách
přírůstek 1 min/bit, offset -125 min
-59 až +59 min
8
Místní offset v hodinách
přírůstek 1 h/bit, offset -125 h
- 23 až +23 h
CPR_076
Tabulka 41 rozepisuje formáty různých bajtů parametru nextCalibrationDate:
Tabulka 41
Rozepsaný formát NextCalibrationDate (recordDataIdentifier s hodnotou # F922)
Bajt
Definice parametru
Rozlišení
Pracovní rozsah
1
Měsíc
přírůstek 1 měsíc/bit, offset 0 měsíců
1 až 12 měsíců
2
Den
přírůstek 0,25 dne/bit, offset 0 dnů (viz POZNÁMKA níže)
0,25 až 31,75 dne
3
Rok
přírůstek 1 rok/bit, offset rok +1985
(viz POZNÁMKA níže )
roky 1985 až 2235
POZNÁMKA týkající se použití parametru „den“:
1.
Hodnota 0 je pro datum prázdnou hodnotou. Hodnoty 1, 2, 3 a 4 se užívají k identifikaci prvního dne v měsíci; 5, 6, 7 a 8 identifikují druhý den v měsíci; atd.
2.
Tento parametr neovlivňuje ani nemění výše uvedený parametr hodin.
POZNÁMKA týkající se použití parametru „Rok“:
Hodnota 0 označuje rok 1985; hodnota 1 označuje rok 1986 atd.
CPR_078.
Tabulka 42 rozepisuje formáty různých bajtů parametru VehicleRegistrationNumber:
Tabulka 42
Rozepsaný formát VehicleRegistrationNumber (recordDataIdentifier s hodnotou # F97E)
Bajt
Definice parametrů
Rozlišení
Pracovní rozsah
1
Kódová stránka (podle definice v dodatku 1)
nepoužije se
VehicleRegistrationNumber
2–14
Registrační značka vozidla (podle definice v dodatku 1)
nepoužije se
VehicleRegistrationNumber
CPR_090
Tabulka 43 rozepisuje formáty různých bajtů parametru SealDataVu:
Tabulka 43
Rozepsaný formát SealDataVu (recordDataIdentifier s hodnotou # F9D3)
Bajt
Definice parametrů
Rozlišení
Pracovní rozsah
1–11
sealRecord1. Formát SealRecord uvedený v dodatku 1.
nepoužije se
SealRecord
12–22
sealRecord2. Formát SealRecord uvedený v dodatku 1.
nepoužije se
SealRecord
23–33
sealRecord3. Formát SealRecord uvedený v dodatku 1.
nepoužije se
SealRecord
34–44
sealRecord4. Formát SealRecord uvedený v dodatku 1.
nepoužije se
SealRecord
45 – 55
sealRecord5. Formát SealRecord uvedený v dodatku 1.
nepoužije se
SealRecord
POZNÁMKA:Je-li dostupných plomb méně než 5, musí být hodnota EquipmentType ve všech nepoužitých záznamech sealRecords nastavena na 15, tj. nepoužité.
CPR_091
Tabulka 44 rozepisuje formáty různých bajtů parametru ByDefaultLoadType:
Tabulka 44
Rozepsaný formát ByDefaultLoadType (recordDataIdentifier s hodnotou # F9D5)
Bajt
Definice parametrů
Rozlišení
Pracovní rozsah
1
loadType
'00'H: Nedefinovaný druh nákladu
'01'H: Zboží
'02'H: Cestující
nepoužije se
'00'H až '02'H
CPR_092
Tabulka 45 rozepisuje formáty různých bajtů parametrů VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber a RemoteCommunicationModuleSerialNumber:
VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber a RemoteCommunicationModuleSerialNumber:
formát ExtendedSerialNumber definovaný v dodatku 1.
nepoužije se
ExtendedSerialNumber
CPR_093
Tabulka 46 rozepisuje formáty různých bajtů parametru TachographCardsGen1Suppression:
Tabulka 46
Rozepsaný formát TachographCardsGen1Suppression (recordDataIdentifier s hodnotou # F9D6)
Bajt
Definice parametrů
Rozlišení
Pracovní rozsah
1-2
TachographCardsGen1Suppression. Formát TachographCardsGen1Suppression definovaný v dodatku 1.
nepoužije se
'0000'H, 'A5E3'H
CPR_094
Tabulka 47 rozepisuje formáty různých bajtů parametru VehiclePosition.
Tabulka 47
Rozepsaný formát VehiclePosition (recordDataIdentifier s hodnotou # F9D7)
Bajt
Definice parametrů
Rozlišení
Pracovní rozsah
1–4
Časové razítko určení polohy vozidla.
nepoužije se
TimeReal
5
přesnost GNSS
nepoužije se
GNSSAccuracy
6–11
Poloha vozidla
nepoužije se
GeoCoordinates
12
Status ověření pravosti
nepoužije se
PositionAuthenticationStatus
13
Aktuální země
nepoužije se
NationNumeric
14
Aktuální region
nepoužije se
RegionNumeric
Poznámka: po aktualizaci polohy vozidla se může aktualizace aktuální země a regionu opozdit.“;
36)
dodatek 9 se mění takto:
a)
v obsahu se doplňuje nový bod 9, který zní:
„9.
ZKOUŠKY OSNMA“;
b)
bod 1 se mění takto:
i)
v bodě 1.1 se doplňuje nový pododstavec, který zní:
„Orgán členských států odpovědný za funkční zkoušky celku ve vozidle nebo vnějšího zařízení GNSS musí zajistit, aby zabudovaný přijímač GNSS úspěšně prošel zkouškami OSNMA uvedenými v tomto dodatku. Tyto zkoušky se považují za součást funkčních zkoušek celku ve vozidle nebo vnějšího zařízení GNSS.“;
ii)
do bodu 1.2 se doplňuje nový odkaz, který zní:
„RGODP
Technická zpráva JRC – Receiver guidelines for OSNMA data processing (Pokyny k přijímačům pro zpracování dat OSNMA)“;
c)
v bodu 2 se řádky 3.1 až 3.41 nahrazují tímto:
„3.1
Poskytované funkce
02, 03, 04, 05, 07, 382
3.2
Provozní režimy
09 až 11*, 134, 135
3.3
Přístupová práva k funkcím a datům
12*, 13*, 382, 383, 386 až 389
3.4
Sledování vkládání a vyjímání karet
15, 16, 17, 18, 19*, 20*, 134
3.5
Měření rychlosti, polohy a vzdálenosti
21 až 37
3.6
Měření času (zkouška při 20 °C)
38 až 43
3.7
Sledování činností řidiče
44 až 53, 134
3.8
Sledování stavu řízení
54, 55, 134
3.9
Řidičem vkládané údaje
56 až 62c
3.10
Správa zámků podniku
63 až 68
3.11
Sledování kontrolních činností
69, 70
3.12
Zjišťování událostí a/nebo závad
71 až 88a, 134
3.13
Identifikační údaje zařízení
93*, 94*, 97, 100
3.14
Údaje související s vložením a vyjmutím karty řidiče nebo dílny
Ověřit, že celek ve vozidle detekuje, zaznamenává a ukládá události a/nebo závady definované jeho výrobcem, když spárovaný snímač pohybu reaguje na magnetická pole, která narušují detekci pohybu vozidla.
217
3.47
Sada šifer a standardizované parametry domény
CSM_48, CSM_50“;
d)
doplňuje se nový bod 9, který zní:
„9.
ZKOUŠKY OSNMA;
9.1
Úvod
Tato kapitola popisuje zkoušky k prokázání správného provedení ověření OSNMA v přijímači GNSS. Vzhledem k tomu, že ověření satelitního signálu provádí výhradně přijímač GNSS nezávisle na jakékoli jiné součásti tachografu, mohou být zkoušky stanovené v této kapitole provedeny na přijímači GNSS jako samostatném prvku. V takovém případě předloží výrobce tachografu schvalovacím orgánům zprávu obsahující podrobnosti o vývoji a výsledcích testů, které jsou prováděny na odpovědnost výrobce přijímače GNSS.
9.2
Platné podmínky
—
Kritéria vyhovění/nevyhovění definovaná ve zkouškách OSNMA se považují za platná pouze pro určené zkušební podmínky.
—
Kritéria se mohou revidovat v okamžiku prohlášení služby Galileo OSNMA a s ohledem na související závazky výkonnosti služby.
9.3.
Definice a zkratky
9.3.1
Definice
Studený/teplý/horký start GNSS
:
Studený/teplý/horký start přijímače GNSS na základě dostupnosti času (T), aktuálního almanachu (A), efemerid (E) a polohy (P):
—
studený start GNSS: žádné
—
teplý start GNSS: T, A, P
—
horký start GNSS: T, A, E, P
Studený/teplý/horký start OSNMA
:
odkazuje na stav spuštění funkce OSNMA na základě dostupnosti informací o veřejném klíči (P) a DSM-KROOT (K) (definovaných v pokynech k přijímačům OSNMA uvedených v dodatku 12):
—
studený start OSNMA: žádné
—
teplý start OSNMA: P
—
horký start OSNMA: P, K
9.3.2
Zkratky
ADKD
Authentication Data & Key Delay (data ověření pravosti a zpoždění klíče)
DSM-KROOT
Digital Signature Message KROOT (zpráva s digitálním podpisem KROOT)
GNSS
Global Navigation Satellite System (globální družicový navigační systém)
KROOT
Root Key of the TESLA key chain (kořenový klíč řetězce klíčů TESLA)
Number of MAC & key blocks (per 30 seconds) (počet bloků MAC a klíčových bloků (za 30 sekund))
OSNMA
Galileo Open Service Navigation Message Authentication (otevřená služba systému Galileo pro ověření pravosti navigačních zpráv)
SLMAC
Slow MAC (pomalý MAC)
TESLA
Timed Efficient Stream Loss-tolerant Authentication (Protocol used in OSNMA) (časovaný účinný tok ověřování odolný vůči ztrátám (protokol používaný v OSNMA)
9.4.
Zařízení pro generování signálů GNSS
Generování signálů GNSS lze provádět pomocí multikonstelačního GNSS simulátoru, který podporuje přenos zpráv OSNMA. Alternativně lze použít přehrávač radiofrekvenčních signálů, který je schopen přehrávat vzorky signálů GNSS ze souborů. Obvyklá bitová hloubka je 4 bity I/Q a vzorkovací frekvence 10 MHz.
Předpokládá se, že přijímač GNSS má rozhraní pro příkaz vymazání paměti přijímače (s cílem nezávisle vymazat veřejný klíč, KROOT, informace hodin, informace o poloze, efemeridy a almanach), pro nastavení určování místního času přijímače pro požadavek ověření OSNMA na ověření načasování a pro nahrávání šifrovacích informací. Tyto příkazy mohou být omezeny na zkušební účely, a proto nemusí být k dispozici pro nominální provoz přijímače.
9.5
Zkušební podmínky
9.5.1
Podmínky GNSS
Simulované nebo přehrávané signály GNSS budou mít tyto vlastnosti:
—
scénář statického uživatelského přijímače,
—
konstelace nejméně GPS a Galileo,
—
frekvence E1/L1,
—
nejméně 4 družice Galileo s výškovým úhlem větším než 5°,
—
doba trvání požadovaná pro každou zkoušku,
—
konstantní navigační efemeridy z družic během zkoušky.
9.5.2
Podmínky OSNMA
Zpráva OSNMA přenášená radiofrekvenčním (RF) signálem bude mít tyto vlastnosti:
—
zpráva HKROOT se statusem OSNMA nastaveným na provozní nebo zkušební status a s pevnou délkou zprávy DSM-KROOT 8 bloků pro platný řetězec;
—
nejméně 4 družice Galileo přenášející ověřování OSNMA;
—
zpráva MACK s jedním blokem MACK (tj. NMACK = 1) a alespoň jedním ADKD = 0 a jedním ADKD = 12 na družici a blok MACK;
—
velikost značky 40 bitů;
—
minimální ekvivalentní délka značky požadovaná v pokynech k přijímačům OSNMA (v současné době 80 bitů).
S výjimkou případů, kdy je to uvedeno, musí být určení interního času přijímače známé s dostatečnou přesností a musí být náležitě synchronizováno se simulovaným časem. To zaručuje, že je pro každou zkušební podmínku splněn požadavek na počáteční časovou synchronizaci OSNMA, tj. nominální synchronizaci pro všechny zkoušky kromě SLMAC. Více podrobností o inicializaci času viz pokyny k přijímačům OSNMA.
Zjištěná kritéria vyhovění/nevyhovění jsou konzervativní a nepředstavují očekávanou výkonnost OSNMA systému Galileo.
9.6
Specifikace zkoušky
Č.
Zkouška
Popis
Související požadavky
1.
Administrativní přezkum
1.1
Dokumentace
Správnost dokumentace
2
Všeobecné zkoušky
2.1
Horký start OSNMA
Cíl: ověřit, zda přijímač GNSS po horkém startu vypočítává polohu pomocí OSNMA.
Postup:
Přijímač GNSS se spouští za podmínek horkého startu GNSS a OSNMA a získává signály viditelných družic Galileo.
Přijímač ověřuje navigační údaje systému Galileo pomocí OSNMA (ADKD = 0) a poskytuje polohu s ověřenými údaji.
Kritéria vyhovění/nevyhovění: přijímač vypočte do 160 sekund ověřenou určenou polohu.
Dodatek 12,
GNS_3b
2.2
Teplý start OSNMA
Cíl: ověřit, zda přijímač GNSS po teplém startu vypočítává polohu pomocí OSNMA.
Postup:
Před zahájením zkoušky se informace o efemeridách a KROOT vymažou z paměti přijímače GNSS, aby se vynutil teplý start GNSS a OSNMA.
Přijímač GNSS se spustí a získává signály z viditelných družic Galileo.
Je přijata a ověřena zpráva DSM-KROOT.
Přijímač ověřuje navigační údaje systému Galileo pomocí OSNMA (ADKD = 0) a poskytuje polohu s ověřenými údaji.
Cíl: ověřit, že přijímač GNSS po teplém startu vypočítává polohu pomocí OSNMA s inicializací času vyžadující režim SLMAC, jak je definováno v pokynech k přijímačům OSNMA.
Postup:
Určení interního času přijímače musí být nakonfigurováno tak, aby existovala počáteční nejistota o čase v hodnotě mezi 2 a 2,5 minutami tak, aby se podle pokynů k přijímačům OSNMA aktivoval režim SLMAC.
Před zahájením zkoušek se informace o efemeridách a KROOT vymažou z paměti přijímače GNSS, aby se vynutil teplý start GNSS a OSNMA.
Přijímač GNSS se spustí a získává signály z viditelných družic Galileo.
Je přijata a ověřena zpráva DSM-KROOT.
Přijímač ověřuje navigační údaje systému Galileo pouze pomocí OSNMA Slow MAC (ADKD = 12) a poskytuje polohu s ověřenými údaji.
Cíl: ověřit, zda přijímač GNSS detekuje přehrávaný signál.
Postup:
Přijímač GNSS se spouští za podmínek horkého startu GNSS a OSNMA a získává signály viditelných družic Galileo.
Přijímač ověřuje navigační údaje systému Galileo pomocí OSNMA (ADKD = 0) a poskytuje polohu s ověřenými údaji.
Jakmile přijímač poskytne PVT s ověřenými údaji, vypne se.
Je simulován přehrávaný signál se zpožděním 40 sekund oproti předchozímu signálu a přijímač se zapne.
Přijímač detekuje, že čas systému Galileo z času signálu v kosmickém prostoru a určení místního načasování nesplňuje požadavek na synchronizaci, a zastavuje zpracování dat OSNMA, jak je definováno v pokynech k přijímačům OSNMA.
Kritéria vyhovění/nevyhovění: přijímač detekuje přehrávání a nevypočítá ověřenou platnou polohu od začátku přehrávání až do konce testu.
Dodatek 12,
GNS_3b
2.5
Horký start OSNMA s chybnými údaji
Cíl: ověřit, zda OSNMA odhalí chybné údaje.
Postup:
Přijímač GNSS se spustí za podmínek horkého startu GNSS i OSNMA.
Přijímač GNSS musí být schopen získat signál ze všech viditelných družic systému Galileo a ověřit pravost jejich navigačních zpráv prostřednictvím OSNMA.
Alespoň jeden bit dat efemerid poskytovaných všemi družicemi systému Galileo neodpovídá původním a ověřeným datům, ale zpráva Galileo I/NAV musí být koherentní, včetně CRC.
Kritéria vyhovění/nevyhovění: přijímač detekuje chybná data do 160 sekund a až do konce zkoušky nevypočítá ověřenou platnou polohu.
Dodatek 12,
GNS_3b
“;
37)
dodatek 12 se mění takto:
a)
obsah se mění takto:
i)
za bod 1.1.1 se vkládá nový bod 1.1, který zní:
„1.1.1
Odkazy“;
ii)
bod 2 se nahrazuje tímto:
„2.
ZÁKLADNÍ CHARAKTERISTIKY PŘIJÍMAČE GNSS“;
iii)
bod 3 se nahrazuje tímto:
„3.
VĚTY POSKYTOVANÉ PŘIJÍMAČEM GNSS“;
iv)
vkládají se nové body 4.2.4 a 4.2.5, které znějí:
„4.2.4
Struktura příkazu WriteRecord
4.2.5
Jiné příkazy“;
v)
bod 5.2 se nahrazuje tímto:
„5.2
Přenos informací z přijímače GNSS do celku ve vozidle (VU)“;
vi)
bod 5.2.1 se zrušuje;
vii)
vkládají se nové body 5.3, 5.4 a 5.4.1 které znějí:
„5.3.
Přenos informací z celku ve vozidle (VU) do přijímače GNSS
5.4.
Zpracování chyb
5.4.1
Chybí informace o poloze z přijímače GNSS“;
viii)
body 6 a 7 se nahrazují tímto:
„6.
ZPRACOVÁNÍ A ZAZNAMENÁVÁNÍ ÚDAJŮ O POLOZE VU
7.
NESOULAD ČASU GNSS“;
ix)
doplňuje se nový bod 8, který zní:
„8.
NESOULAD ÚDAJŮ O POHYBU VOZIDLA“;
b)
bod 1 se mění takto:
i)
Text před obrázkem 1 se nahrazuje tímto:
„1. ÚVOD
Tento dodatek stanoví technické požadavky na přijímač GNSS a data GNSS používaná celkem ve vozidle, včetně protokolů, které je nutné zavést k zajištění zabezpečeného a správného přenosu dat s informacemi o poloze.
1.1. Oblast působnosti
GNS_1
Celek ve vozidle shromažďuje údaje o poloze nejméně z jedné družicové sítě GNSS.
Celek ve vozidle může, ale nemusí být vybaven vnějším zařízením GNSS, jak popisuje obrázek 1:“;
ii)
za bod 1.1 se vkládá nový bod 1.1.1, který zní:
„1.1.1
Odkazy
V této části dodatku jsou užívány následující odkazy:
NMEA
Národní asociace pro námořní elektroniku (National Marine Electronics Association, NMEA) 0183 Interface Standard (norma pro rozhraní), V4.11“;
iii)
v bodě 1.2 se doplňují tyto zkratky:
„ OSNMA
Galileo Open Service Navigation Messages Authentication (otevřená služba systému Galileo pro ověření pravosti navigačních zpráv)
RTC
Real Time Clock (hodiny reálného času)
“;
c)
bod 2 se mění takto:
i)
nadpis se nahrazuje tímto:
„2.
ZÁKLADNÍ CHARAKTERISTIKY PŘIJÍMAČE GNSS“;
ii)
odstavec GNS_3 se nahrazuje tímto:
„GNS_3
Přijímač GNSS musí být schopen podporovat ověřování navigačních zpráv v otevřené službě systému Galileo (OSNMA).“;
iii)
doplňují se nové body GNS_3a až GNS_3g, které znějí:
„GNS_3a
Přijímač GNSS provádí řadu kontrol shody, aby ověřil, že měření jím vypočítaná na základě údajů OSNMA vedla ke správným informacím o poloze, rychlosti a údajích vozidla, a nebyla tudíž ovlivněna žádným vnějším útokem, jako je „meaconing“. Tyto kontroly shody zahrnují například:
—
detekci abnormálních emisí výkonu pomocí kombinovaného monitorování automatického vyrovnávání citlivosti (Automatic Gain Control, AGC) a poměru nosiče a hustoty šumu (Carrier-to-Noise density ratio, C/N0),
—
konzistentnost měření pseudorozsahu a konzistentnost dopplerovského měření, včetně detekce náhlých skoků v měření,
—
techniky autonomního monitorování integrity přijímačem (RAIM), včetně detekce nekonzistentních měření s odhadovanou polohou,
—
kontroly polohy a rychlosti, včetně řešení abnormální polohy a rychlosti, náhlých skoků a chování, které není konzistentní s dynamikou vozidla,
—
konzistentnost času a frekvence, včetně skoků a odchylek hodin, které nejsou konzistentní s charakteristikami hodin přijímače.
GNS_3b
Evropská komise vypracuje a schválí tyto dokumenty:
—
Dokument pro kontrolu rozhraní signálu v kosmu (Signal in Space Interface Control Document, SIS ICD), který uvádí podrobné informace OSNMA přenášené signálem Galileo,
—
pokyny k přijímačům OSNMA, které stanoví požadavky a postupy týkající se přijímačů, aby bylo zaručeno bezpečné zavádění OSNMA, jakož i doporučení ke zvýšení výkonnosti OSNMA.
Přijímače GNSS instalované v tachografech interně nebo externě musí být konstruovány v souladu s dokumentem SIS ICD a pokyny k přijímačům OSNMA.
GNS_3c
Přijímač GNSS poskytuje zprávy o poloze označované v této příloze a jejích dodatcích jako zprávy o ověřené poloze, které se vypracovávají pouze za použití družic, z nichž byla úspěšně ověřena pravost navigačních zpráv.
GNS_3d
Přijímač GNSS musí rovněž poskytovat standardní zprávy o poloze vypracované za použití družic, které jsou viditelné, bez ohledu na to, zda jsou ověřené, či nikoli.
GNS_3e
Přijímač GNSS musí používat hodiny reálného času celku ve vozidle (VU RTC) jako referenční čas pro časovou synchronizaci nezbytnou pro OSNMA.
GNS_3f.
Čas VU RTC musí přijímači GNSS poskytovat celek ve vozidle.
GNS_3g
Maximální časová odchylka stanovená v požadavku 41 přílohy IC musí být přijímači GNSS poskytnuta celkem ve vozidle spolu s časem VU RTC.“;
d)
bod 3 se nahrazuje tímto:
„3.
VĚTY POSKYTOVANÉ PŘIJÍMAČEM GNSS
Tato část popisuje věty používané při provozu inteligentního tachografu pro přenos zpráv o standardních a ověřených polohách. Tato část platí pro konfiguraci inteligentního tachografu s vnějším zařízením GNSS i bez něj.
GNS_4
Údaje o standardní poloze jsou založeny na větě NMEA s doporučenými minimálními specifickými daty GNSS (RMC), která obsahuje informace o poloze (zeměpisná šířka, délka), čas ve formátu UTC (hhmmss.ss) a rychlost vůči zemskému povrchu v uzlech, jakož i další hodnoty.
Věta RMC má tento formát (podle normy NMEA V4.11):
Status navigace je nepovinný a nemusí být ve větě RMC obsažen.
Status udává, zda je signál GNSS dostupný. Dokud nemá status hodnotu „A“, nelze přijímané údaje (např. čas nebo zeměpisnou šířku a délku) používat v celku ve vozidle pro zaznamenávání polohy vozidla.
Rozlišení polohy je založeno na výše popsaném formátu věty RMC. První část polí č. 3 a 5 představuje stupně. Zbytek se používá pro vyjádření minut s třemi desetinnými místy. Rozlišení je tedy 1/1 000 minuty nebo 1/60 000 stupně (protože jedna minuta je 1/60 stupně).
GNS_4a
Údaje o ověřené standardní poloze jsou založeny na větě podobné větě NMEA týkající se ověřených minimálních specifických (AMC) údajů, která obsahuje údaje o poloze (zeměpisná šířka, délka), čas ve formátu UTC (hhmmss.ss) a rychlost vůči zemskému povrchu v uzlech, jakož i další hodnoty.
Věta AMC má následující formát (podle normy NMEA V4.11 s výjimkou hodnoty č. 2):
Status, A = ověřená poloha (zjištěná pomocí nejméně čtyř družic, u nichž byla úspěšně ověřena pravost navigačních zpráv), J = rušení nebo O = jiný útok na GNSS v případě nepřítomnosti selhání ověření pravosti navigačních zpráv (díky kontrolám konzistence podle GNS_3a), F = selhání ověření navigačních zpráv (zjištěné ověřeními OSNMA stanovenými v dokumentech uvedených v GNS_3b), V = neplatné (ověřená poloha není k dispozici z jakéhokoli jiného důvodu).
3)
Zeměpisná šířka
4)
N nebo S
5)
Zeměpisná délka
6)
E nebo W
7)
Rychlost vůči zemskému povrchu v uzlech
8)
Kurz pohybu ve stupních
9)
Datum, ddmmyy
10)
Magnetická deklinace ve stupních
11)
E nebo W
12)
Indikátor režimu FAA
13)
Status navigace
14)
Kontrolní součet
Status navigace je nepovinný a nemusí být ve větě AMC obsažen.
Status udává, zda je k dispozici ověřená poloha GNSS, zda byl zjištěn útok na signály GNSS, zda selhalo ověření pravosti navigačních zpráv nebo zda je poloha GNSS neplatná. Není-li hodnota statusu nastavena na „A“, považují se přijaté údaje (např. čas nebo zeměpisná šířka/délka) za neplatné a nelze je použít k zaznamenání polohy vozidla v celku ve vozidle. Je-li hodnota statusu nastavena na „J“ (rušení), „O“ (jiný útok na GNSS) nebo „F“ (selhání ověření pravosti navigačních zpráv), zaznamená se anomálie GNSS v celku ve vozidle, jak je definováno v příloze IC a dodatku 1 (EventFaultCode).
GNS_5
Celek ve vozidle ukládá v databázi VU informace o poloze, pokud jde o zeměpisnou šířku a délku, s rozlišením 1/10 minuty nebo 1/600 stupně, jak popisuje dodatek 1 pro typ GeoCoordinates.
Ke zjišťování a zaznamenávání dostupnosti signálu a přesnosti standardních poloh může VU používat příkaz GSA (GPS DOP a aktivní družice) podle normy NMEA V4.11. K indikaci úrovně přesnosti zaznamenaných údajů o poloze se používá zejména parametr HDOP (viz část 4.2.2). Celek ve vozidle ukládá hodnotu parametru horizontální přesnosti (HDOP) vypočítanou jako minimum z hodnot HDOP shromážděných z dostupných systémů GNSS.
ID systému GNSS označuje příslušné ID NMEA pro každou konstelaci GNSS a systém s družicovým rozšířením (SBAS).
ID dvanáctého satelitu použitého pro určení polohy
15)
PDOP
16)
HDOP
17)
VDOP
18)
ID systému
19)
Kontrolní součet
ID systému je nepovinné a nemusí být ve větě GSA obsaženo.
Podobně může VU k určování a zaznamenávání dostupnosti signálu a přesnosti ověřených poloh používat větu podobnou větě NMEA, příkaz ověřených aktivních družic (ASA). Hodnoty 1 až 18 jsou definovány v normě NMEA V4.11.
ID dvanáctého satelitu použitého pro určení polohy
15)
PDOP
16)
HDOP
17)
VDOP
18)
ID systému
19)
Kontrolní součet
ID systému je nepovinná a nemusí být ve větě ASA obsažena.
GNS_6
Je-li použito vnější zařízení GNSS, uloží se věta GSA do bezpečnostního přijímače-vysílače GNSS s číslem záznamu „02“ až„06“ a věta ASA se uloží s číslem záznamu „12“ až „16“.
GNS_7
Maximální velikost vět (např. RMC, AMC, GSA, ASA nebo dalších), kterou lze použít pro určení velikosti v příkazu čtení záznamu, je 85 bajtů (viz tabulka 1).“;
e)
bod 4 se mění takto:
i)
v bodě 4.1.1 se odstavec GNS_9 mění takto:
1.
znění před písmenem b) se nahrazuje tímto:
„GNS_9
Vnější zařízení GNSS obsahuje tyto součásti (viz obrázek 6)
a)
komerční přijímač GNSS pro poskytování údajů o poloze prostřednictvím datového rozhraní GNSS. Datovým rozhraním GNSS může být například standard NMEA V4.11, kde přijímač GNSS funguje jako vysílač a předává věty NMEA bezpečnostnímu přijímači-vysílači GNSS s frekvencí 1 Hz, pokud jde o předem definovanou sadu vět NMEA, která musí zahrnovat přinejmenším věty RMC, AMC, GSA a ASA. Provedení datového rozhraní GNSS je volbou výrobce vnějšího zařízení GNSS.“;
2)
písmeno c) se nahrazuje tímto:
„c)
systém krytí s funkcí detekce nedovolené manipulace, který zapouzdřuje jak přijímač GNSS, tak bezpečnostní přijímač-vysílač GNSS. Funkce detekce nedovolené manipulace zavádí bezpečnostní ochranná opatření požadovaná v profilu ochrany inteligentního tachografu.“;
ii)
bod 4.2.1 se mění takto:
1)
odstavec GNS_14 se nahrazuje tímto:
„GNS_14
Komunikační protokol mezi vnějším zařízením GNSS a celkem ve vozidle podporuje tyto funkce:
1.
shromažďování a distribuci údajů GNSS (např. polohy, časování, rychlosti);
2.
shromažďování konfiguračních dat vnějšího zařízení GNSS;
3.
protokol správy na podporu vazby, vzájemného ověření pravosti a dohody na klíči relace mezi vnějším zařízením GNSS a celkem ve vozidle;
4.
převod času RTC VU a maximálního rozdílu mezi skutečným časem a časem RTC VU do vnějšího zařízení GNSS.“;
2)
Za odstavec GNS_18 se vkládá nový odstavec, který zní:
„GNS_18a
Pokud jde o funkci 4) přenos času RTC VU a maximálního rozdílu mezi skutečným časem a časem RTC VU do vnějšího zařízení GNSS, musí bezpečnostní přijímač-vysílač GNSS používat EF (EF VU) ve stejném DF s identifikátorem souboru rovným „2F30“, jak je popsáno v tabulce 1.“;
3)
Za odstavec GNS_19 se vkládá nový odstavec, který zní:
„GNS_19a
Bezpečnostní přijímač-vysílač GNSS ukládá údaje přicházející z celku ve vozidle v EF VU. Jde o lineární soubor se záznamy pevné délky a s identifikátorem rovným „2F30“ v hexadecimálním formátu.“;
4)
v odstavci GNS_20 se první pododstavec nahrazuje tímto:
„GNS_20
Bezpečnostní přijímač-vysílač GNSS používá paměť k ukládání dat a musí být schopen provádět tolik cyklů zápisu/čtení, kolik je potřebné, po dobu životnosti nejméně 15 let. Kromě této podmínky jsou vnitřní konstrukce a provedení bezpečnostního přijímače-vysílače GNSS ponechány na uvážení výrobců.“;
5)
V GNS_21 se tabulka 1 nahrazuje tímto:
„
Tabulka 1
Struktura souborů
Podmínky přístupu
Soubor
ID souboru
Čtení
Aktualizace
Šifrování
MF
3F00
EF.ICC
0002
ALW
NEV
(ze strany VU)
Č.
DF zařízení GNSS
0501
ALW
NEV
Č.
EF EGF_MACertificate
C100
ALW
NEV
Č.
EF CA_Certificate
C108
ALW
NEV
Č.
EF Link_Certificate
C109
ALW
NEV
Č.
EF EGF
2F2F
SM-MAC
NEV
(ze strany VU)
Č.
EF VU
2F30
SM-MAC
SM-MAC
Č.
Soubor / datový prvek
Č. záznamu
Velikost (bajty)
Výchozí hodnoty
Min
Max
MF
552
1031
EF.ICC
sensorGNSSSerialNumber
8
8
DF zařízení GNSS
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
Věta RMC NMEA
'01'
85
85
1. věta GSA NMEA
'02'
85
85
2. věta GSA NMEA
'03'
85
85
3. věta GSA NMEA
'04'
85
85
4. věta GSA NMEA
'05'
85
85
5. věta GSA NMEA
'06'
85
85
Rozšířené sériové číslo vnějšího zařízení GNSS definované v dodatku 1 jako SensorGNSSSerialNumber
'07'
8
8
Identifikátor operačního systému bezpečnostního přijímače-vysílače GNSS definovaný v dodatku 1 jako SensorOSIdentifier
'08'
2
2
Číslo schválení typu vnějšího zařízení GNSS definované v dodatku 1 jako SensorExternalGNSSApprovalNumber
'09'
16
16
Identifikátor bezpečnostní komponenty vnějšího zařízení GNSS definovaný v dodatku 1 jako SensorExternalGNSSSCIdentifier
'10'
8
8
věta AMC
'11'
85
85
1. věta ASA
'12'
85
85
2. věta ASA
'13'
85
85
3. věta ASA
'14'
85
85
4. věta ASA
'15'
85
85
5. věta ASA
'16'
85
85
RFU – vyhrazeno pro budoucí použití
od '17' do 'FD'
EF VU
VuRtcTime (viz dodatek 1)
'01'
4
4
{00..00}
VuGnssMaximalTimeDifference (viz dodatek 1)
'02'
2
2
{00..00}
“;
iii)
bod 4.2.2 se mění takto:
1)
v odstavci GNS_22 se první pododstavec nahrazuje tímto:
„GNS_22
Zabezpečený přenos údajů GNSS o poloze, času RTC VU a maximálním časovém rozdílu mezi skutečným časem a časem RTC VU je povolen pouze za těchto podmínek:“;
2)
odstavec GNS_23 se nahrazuje tímto:
„GNS_23
Každých T sekund, kde T je hodnota menší než nebo rovná 20, pokud neprobíhá vazba nebo vzájemné ověření pravosti a dohoda na klíči relace, si celek ve vozidle vyžádá od vnějšího zařízení GNSS údaje o poloze podle tohoto postupu:
1.
Celek ve vozidle si od vnějšího zařízení GNSS vyžádá údaje o poloze společně s údaji parametru přesnosti (z vět GSA nebo ASA). Bezpečnostní přijímač-vysílač VU používá příkazy ISO/IEC 7816-4:2013 SELECT a READ RECORD(S) v režimu bezpečného předávání zpráv pouze s ověřením pravosti, jak je popsáno v dodatku 11 části 11.5, s identifikátorem souboru „2F2F“ a číslem RECORD rovným „01“, pro větu RMC NMEA’02’,’03’,’04’,’05’,’06’, pro větu GSA NMEA ‚11’ a pro větu ASA ‘12’,’13’,’14’,’15’,’16’.
2.
Poslední přijaté údaje o poloze jsou uloženy v EF s identifikátorem ‘2F2F’ a záznamy, které popisuje tabulka 1, v bezpečnostním přijímači-vysílači GNSS, s tím, jak bezpečnostní přijímač-vysílač GNSS přijímá data NMEA z přijímače GNSS prostřednictvím datového rozhraní GNSS s frekvencí nejméně 1 Hz.
3.
Bezpečnostní přijímač-vysílač GNSS odešle bezpečnostnímu přijímači-vysílači VU odpověď prostřednictvím zprávy s odpovědí APDU v režimu bezpečného předávání zpráv pouze s ověřením pravosti podle popisu dodatku 11 části 11.5.
4.
Bezpečnostní přijímač-vysílač VU ověří pravost a integritu přijaté odpovědi. V případě pozitivního výsledku jsou údaje o poloze předány procesoru VU prostřednictvím datového rozhraní GNSS.
5.
Procesor VU zkontroluje přijaté údaje a extrahuje informace (např. zeměpisnou šířku, délku, čas) z věty RMC NMEA. Věta RMC NMEA obsahuje informaci, zda je neověřená poloha platná. Je-li neověřená poloha platná, procesor VU rovněž extrahuje hodnoty HDOP z vět GSA NMEA a vypočítá minimální hodnotu z dostupných družicových systémů (tj. je-li poloha k dispozici).
6.
Procesor VU extrahuje informace (např. zeměpisnou šířku, délku, čas) rovněž z věty AMC. Věta AMC zahrnuje informace, zda je ověřená poloha neplatná nebo zda byl napaden signál GNSS. Je-li poloha platná, procesor VU rovněž extrahuje hodnoty HDOP z vět ASA a vypočítá minimální hodnotu z dostupných družicových systémů (tj. je-li poloha k dispozici).
GNS_23a
VU musí rovněž podle potřeby zapsat čas RTC VU a maximální časový rozdíl mezi skutečným časem a časem RTC celku ve vozidle za použití příkazů ISO/IEC 7816-4:2013 SELECT a WRITE RECORD(S) v režimu bezpečného předávání zpráv pouze do režimu bezpečného předávání zpráv pouze s ověřením pravosti podle popisu v dodatku 11 části 11.5, s identifikátorem souboru „2F30“ a číslem RECORD rovným „01“ pro VuRtcTime a „02“ pro MaximalTimeDifference“.
iv)
bod 4.2.3 se mění takto:
1)
v odstavci GNS_26 se čtvrtá a pátá odrážka nahrazují tímto:
„—
Není-li záznam nalezen, bezpečnostní přijímač-vysílač GNSS vrátí ‘6A83’.
—
Pokud vnější zařízení GNSS zjistilo nedovolenou manipulaci, vrátí stavová slova ‘6690’.“;
2)
Bod GNS_27 se zrušuje;
v)
vkládají se nové body 4.2.4 a 4.2.5, které znějí:
„4.2.4
Struktura příkazu WriteRecord
Tato část podrobně popisuje strukturu příkazu Write Record. Je doplněno bezpečné předávání zpráv (režim pouze s ověřením pravosti) podle popisu v dodatku 11 – Společné bezpečnostní mechanismy.
GNS_26a
Příkaz podporuje režim bezpečného předávání zpráv pouze s ověřením pravosti, viz dodatek 11.
GNS_26b
Zpráva s příkazem
Bajt
Délka
Hodnota
Popis
CLA
1
‘0Ch’
Požaduje se bezpečné předávání zpráv
INS
1
‘D2h’
Write Record
P1
1
‘XXh’
Číslo záznamu ('00' odkazuje na aktuální záznam)
P2
1
‘04h’
Zapsat záznam s číslem záznamu uvedeným v P1
Data
X
‘XXh’
Data
GNS_26c
Záznam, na který odkazuje P1, se stává aktuálním záznamem.
Bajt
Délka
Hodnota
Popis
SW
2
‘XXXXh’
Stavová slova (SW1, SW2)
—
Je-li příkaz úspěšný, bezpečnostní přijímač-vysílač GNSS vrátí ‘
9000
’.
—
Není-li aktuální soubor uspořádán do záznamů, bezpečnostní přijímač-vysílač GNSS vrátí '6981'.
—
Je-li příkaz použit s parametrem P1 = '00', ale žádný EF není aktuální, bezpečnostní přijímač-vysílač GNSS vrátí '6986' (příkaz není povolen).
—
Není-li záznam nalezen, bezpečnostní přijímač-vysílač GNSS vrátí '6A83'.
—
Pokud vnější zařízení GNSS zjistilo nedovolenou manipulaci, vrátí stavová slova
’6690’
.
4.2.5
Jiné příkazy
GNS_27
Bezpečnostní přijímač-vysílač GNSS podporuje tyto příkazy tachografu druhé generace specifikované v dodatku 2:
Příkaz
Odkaz
Select
Dodatek 2 kapitola 3.5.1
Read Binary
Dodatek 2 kapitola 3.5.2
Get Challenge
Dodatek 2 kapitola 3.5.4
PSO: Verify Certificate
Dodatek 2 kapitola 3.5.7
External Authenticate
Dodatek 2 kapitola 3.5.9
General Authenticate
Dodatek 2 kapitola 3.5.10
MSE:SET
Dodatek 2 kapitola 3.5.11
“;
vi)
v bodě 4.4.1 se odstavec GNS_28 nahrazuje tímto:
„GNS_28
Chyba komunikace s událostí vnějšího zařízení GNSS se zaznamená do celku ve vozidle, jak je definováno v požadavku 82 v příloze IC a dodatku 1 (EventFaultType). V této souvislosti se chyba komunikace vyvolá, když bezpečnostní přijímač-vysílač VU neobdrží zprávu s odpovědí po zprávě s požadavkem, jak je popsáno v bodě 4.2.“;
vii)
v bodě 4.4.2 se odstavec GNS_29 nahrazuje tímto:
„GNS_29
„Je-li vnější zařízení GNSS narušeno, bezpečnostní přijímač-vysílač GNSS zajistí, aby byl kryptografický materiál nedostupný. Jak je popsáno v odstavcích GNS_25 a GNS_26, VU detekuje nedovolenou manipulaci, je-li status odpovědi ‘6690’. VU pak vygeneruje a zaznamená událost pokusu o narušení zabezpečení podle definice v požadavku 85 v příloze IC a dodatku 1 (EventFaultType pro detekci nedovolené manipulace GNSS). Vnější zařízení GNSS může alternativně reagovat na žádosti VU bez bezpečného předávání zpráv a se statusem "6A88".“;
viii)
v bodě 4.4.3 se odstavec GNS_30 nahrazuje tímto:
„GNS_30
Pokud bezpečnostní přijímač-vysílač GNSS neobdrží data z přijímače GNSS, bezpečnostní přijímač-vysílač GNSS generuje zprávu s odpovědí na příkaz READ RECORD s číslem RECORD rovným ‘01’ a s datovým polem obsahujícím 12 bajtů, které mají všechny hodnotu 0xFF. Po přijetí zprávy s odpovědí s touto hodnotou datového pole musí celek ve vozidle generovat a zaznamenávat absenci informací o poloze z přijímače GNSS, jak je definováno v požadavku 81 v příloze IC a dodatku 1 (EventFaultType).“;
ix)
bod 4.4.4 se mění takto:
1)
odstavec GNS_31 se nahrazuje tímto:
„GNS_31
Pokud VU zjistí, že certifikát EGF používaný pro vzájemné ověřování již není platný, musí generovat a zaznamenávat událost pokusu o narušení zabezpečení podle definice v požadavku 85 v příloze IC a dodatku 1 (vypršela platnost certifikátu EventFaultType pro vnější zařízení GNSS). VU nadále používá přijaté údaje GNSS o poloze.“;
2)
nadpis obrázku 4 se nahrazuje tímto:
„
Obrázek 6
Schéma vnějšího zařízení GNSS
“;
f)
bod 5 se mění takto:
i)
v bodě 5.1 se odstavec GNS_32 nahrazuje tímto:
„GNS_32
Při přenášení údajů o poloze, DOP a družicích funguje přijímač GNSS jako vysílač a předává věty NMEA nebo jim podobné procesoru VU, který funguje jako přijímač s frekvencí 1/10 Hz nebo vyšší, pro předem definovanou sadu vět, která musí zahrnovat přinejmenším věty RMC, GSA, AMC a ASA. Alternativně může procesor VU a interní přijímač GNSS používat jiné datové formáty pro výměnu dat obsažených ve větách NMEA nebo jim podobných uvedených v GNS_4, GNS_4a a GNS_5.“;
ii)
bod 5.2 se nahrazuje tímto:
„5.2
Přenos informací z přijímače GNSS do celku ve vozidle
GNS_34
Procesor VU zkontroluje přijaté údaje a extrahuje informace (např. zeměpisnou šířku, délku, čas) z vět RMC NMEA a AMC.
GNS_35
Věta RMC NMEA obsahuje informaci, zda je neověřená poloha platná. Není-li neověřená poloha platná, nejsou údaje o poloze k dispozici a nelze je použít pro zaznamenání polohy vozidla. Pokud je neověřená poloha platná, procesor VU extrahuje rovněž hodnoty HDOP z GSA NMEA.
GNS_36
Procesor VU extrahuje rovněž informace (např. zeměpisnou šířku, délku, čas) z věty AMC. Věta AMC obsahuje informaci, zda je neověřená poloha platná podle GNS_4a. Pokud je neověřená poloha platná, procesor VU extrahuje rovněž hodnoty HDOP z vět ASA.
5.3.
Přenos informací z celku ve vozidle do přijímače GNSS
GNS_37
Procesor VU poskytuje přijímači GNSS čas RTC VU a maximální rozdíl mezi skutečným časem a časem RTC VU v souladu s GNS_3f a GNS_3g.
5.4.
Zpracování chyb
5.4.1
Chybí informace o poloze z přijímače GNSS
GNS_38
VU musí generovat a zaznamenávat nepřítomnost informací o poloze z přijímače GNSS podle definice v požadavku 81 v příloze IC a dodatku 1 (EventFaultType).“;
g)
body 6 a 7 se nahrazují tímto:
„6.
ZPRACOVÁNÍ A ZAZNAMENÁVÁNÍ ÚDAJŮ O POLOZE VU
Tato část platí pro konfiguraci inteligentního tachografu s vnějším zařízením GNSS i bez něj.
GNS_39-
Údaje o poloze musí být uloženy ve VU spolu s příznakem informujícím, zda byla poloha ověřena. Pokud je nutné zaznamenávat údaje o poloze v celku ve vozidle, použijí se tato pravidla:
a)
Jestliže jsou ověřené i standardní polohy platné a konzistentní, zaznamená se standardní poloha a její přesnost v celku ve vozidle a příznak se nastaví na „ověřena“.
b)
Jestliže jsou ověřené i standardní polohy platné, ale nejsou konzistentní, musí VU uchovávat ověřenou polohu a její přesnost a příznak se nastaví na „ověřena“.
c)
Je-li ověřená poloha platná a standardní poloha není platná, zaznamená VU ověřenou polohu a její přesnost a příznak se nastaví na „ověřena“.
d)
Je-li standardní poloha platná a ověřená poloha není platná, zaznamená VU standardní polohu a její přesnost a příznak se nastaví na „neověřena“.
Ověřené a standardní polohy se považují za konzistentní, jak je znázorněno na obrázku 7, pokud lze vodorovnou ověřenou polohu nalézt v kružnici se středem ve vodorovné standardní poloze, přičemž poloměr je zaokrouhlen na nejbližší horní celé číslo, hodnota R_H vypočtená podle tohoto vzorce:
R_H = 1.74 • σUERE • HDOP
kde:
—
ukazatel, který se používá ke kontrole konzistence mezi standardními a ověřenými polohami.R_H je relativní poloměr kruhu kolem odhadované horizontální polohy v metrech. Je to včetně městských prostředí. Konstantní hodnota
—
σUERE je standardní odchylka pro chybu ekvivalentního rozsahu uživatele (user equivalent range error, UERE), která modeluje všechny chyby měření pro cílovou aplikaci, σUERE = použije se 10 metrů.
—
HDOP je parametr horizontální přesnosti (Horizontal Dilution of Precision) vypočítaný přijímačem GNSS.
—
σUERE. HDOP je odhad kvadratického průměru chyby (root mean squared error ) v horizontální doméně.
Obrázek 7 Konzistentní ověřené a standardní (neověřené) polohy
GNS_40
Je-li hodnota statusu v přijaté větě AMC nastavena na hodnotu „J“ nebo „O“ nebo „F“ v souladu s požadavkem GNS_4a, VU generuje a zaznamenává anomálii GNSS, jak je definováno v požadavku 88a v příloze IC a dodatku 1 (EventFaultType). Celek ve vozidle může provést doplňující kontroly před uložením anomálie GNSS po přijetí nastavení „J“ nebo „O“.
7.
NESOULAD ČASU GNSS
GNS_41
Pokud VU zjistí nesoulad mezi časem funkce měření času celku ve vozidle a času pocházejícího ze signálů GNSS, generuje a zaznamenává událost nesouladu času, jak je definováno v požadavku 86 v příloze IC a dodatku 1 (EventFaultType).“;
h)
doplňuje se nový bod 8, který zní:
„8.
NESOULAD ÚDAJŮ O POHYBU VOZIDLA
GNS_42
VU spustí a zaznamená událost „Nesoulad údajů o pohybu vozidla“ v souladu s požadavkem 84 v příloze IC v případě, že informace o pohybu vypočítané ze snímače pohybu jsou v rozporu s informacemi o pohybu vypočítanými z interního přijímače GNSS, z vnějšího zařízení GNSS nebo jiného nezávislého zdroje (zdrojů) pohybu, jak je stanoveno v požadavku 26 přílohy IC.
Událost „Nesoulad údajů o pohybu vozidla“ se spouští při výskytu jedné z těchto spouštěcích podmínek:
Spouštěcí podmínka 1:
Pokud jsou k dispozici informace o poloze z přijímače GNSS a je zapnuto zapalování vozidla, použije se useknutý průměr rozdílů rychlosti mezi těmito zdroji, jak je uvedeno níže:
—
každých maximálně 10 sekund se vypočte absolutní hodnota rozdílu mezi rychlostí vozidla odhadnutou z GNSS a rychlostí odhadnutou ze snímače pohybu,
—
k výpočtu useknutého průměru se použijí všechny vypočtené hodnoty v časovém okně zahrnujícím posledních 5 minut pohybu vozidla,
—
useknutý průměr se vypočte jako průměr z 80 % hodnot, které zůstanou po eliminaci hodnot, jež jsou v absolutních hodnotách nejvyšší.
Událost „Nesoulad údajů o pohybu vozidla“ se vyvolá, pokud je useknutý průměr po dobu pěti nepřerušených minut pohybu vozidla vyšší než 10 km/h. (Poznámka: použití useknutého průměru za posledních 5 minut má za cíl omezit riziko plynoucí z odlehlých a přechodných hodnot.)
Pro výpočet useknutého průměru se vozidlo považuje za vozidlo pohybující se, pokud se alespoň jedna hodnota rychlosti vozidla odhadnutá buď ze snímače pohybu, nebo z přijímače GNSS nerovná nule.
Spouštěcí podmínka 2:
událost „Nesoulad údajů o pohybu vozidla“ se rovněž vyvolá, je-li pravdivá tato podmínka:
GnssDistance je vzdálenost mezi aktuální polohou vozidla a předchozí polohou, obě získané z platných ověřených hlášení polohy bez ohledu na výšku,
—
OdometerDifference je rozdíl mezi aktuálním stavem počitadla ujetých kilometrů a stavem počitadla ujetých kilometrů odpovídajícím předchozímu ověřenému hlášení polohy,
—
OdometerToleranceFactor se rovná 1,1 (nejhorší případ faktoru tolerance pro všechna toleranční rozpětí měření počitadla ujetých kilometrů),
—
GnssTolerance je rovna 1 km (nejhorší případ tolerance GNSS),
—
Minimální (SlipDistanceUpperLimit; (OdometerDifference * SlipFactor)) je minimální hodnota mezi:
—
SlipDistanceUpperLimit (horní mezní hodnota vzdálenosti prokluzu způsobené podklouznutím při brzdění), která se rovná 10 km,
—
a OdometerDifference * SlipFactor, v němž je SlipFactor (maximální vliv podklouznutí při brzdění) roven 0,2,
—
FerryTrainDistance se vypočítá jako: FerryTrainDistance = 200 km/h * tFerryTrain, kde tFerryTrain je součet doby převozu lodí/vlakem v hodinách v daném časovém intervalu. Doba trvání převozu lodí/vlakem je definována jako časový rozdíl mezi jeho příznakem ukončení (end flag) a příznakem začátku (beginning flag).
Předchozí ověření se provádí každých 15 minut, jsou-li k dispozici potřebné údaje o poloze, jinak jakmile jsou údaje o poloze k dispozici.
Pro tuto spouštěcí podmínku:
—
datum a čas začátku události se musí rovnat datu a času, kdy bylo přijato předchozí hlášení o poloze,
—
datum a čas ukončení události se musí rovnat datu a času, kdy se kontrolované podmínky opět stanou chybnými.
Spouštěcí podmínka 3:
Celek ve vozidle se setkává s nesouladem spočívajícím v tom, že snímač pohybu po určitou dobu nedetekoval žádný pohyb, zatímco nezávislý zdroj pohybu ano. Podmínky pro zaznamenání nesouladu, jakož i doby jeho detekce, stanoví výrobce celku ve vozidle, ačkoli nesoulad musí být detekován nejdéle za tři hodiny.“;
38)
dodatek 13 se nahrazuje tímto:
„Dodatek 13
ROZHRANÍ ITS
OBSAH
1.
ÚVOD
1.1.
Oblast působnosti
1.2.
Zkratky a definice
2.
REFERENČNÍ NORMY
3.
PRINCIPY ČINNOSTI ROZHRANÍ ITS
3.1.
Komunikační technologie
3.2.
Dostupné služby
3.3.
Přístup přes rozhraní ITS
3.4.
Dostupné údaje a potřeba souhlasu řidiče
4.
SEZNAM ÚDAJŮ DOSTUPNÝCH PROSTŘEDNICTVÍM ROZHRANÍ ITS A KLASIFIKACE OSOBNÍ/NEOSOBNÍ
1. ÚVOD
1.1. Oblast působnosti
ITS_01
Tento dodatek stanoví základní prvky komunikace prostřednictvím rozhraní tachografu s inteligentními dopravními systémy (ITS), jak se požaduje v článcích 10 a 11 nařízení (EU) č. 165/2014.
ITS_02
Rozhraní ITS musí umožňovat externím zařízením získávat údaje z tachografu, používat služby tachografu a rovněž tachografu poskytovat údaje.
K tomuto účelu lze používat rovněž jiná rozhraní tachografu (např. sběrnici CAN).
Tento dodatek nestanoví:
—
způsob, jakým jsou údaje poskytované prostřednictvím rozhraní ITS shromažďovány a spravovány v tachografu,
—
formu prezentace shromážděných údajů aplikacím v externím zařízení,
—
bezpečnostní specifikaci ITS nad rámec toho, co poskytuje Bluetooth®,
—
protokoly Bluetooth® používané rozhraním ITS.
1.2. Zkratky a definice
Používají se tyto zkratky a definice specifické pro tento dodatek:
GNSS
globální družicový navigační systém
ITS
inteligentní dopravní systém (Intelligent Transport System)
OSI
propojení otevřených systémů (Open Systems Interconnection)
VU
celek ve vozidle (Vehicle Unit)
Jednotka ITS
externí zařízení nebo aplikace využívající rozhraní VU ITS.
2. REFERENČNÍ NORMY
ITS_03
Tento dodatek odkazuje na všechny následující předpisy a normy nebo jejich části a vychází z nich. V rámci ustanovení tohoto dodatku se odkazuje na příslušné normy nebo příslušná ustanovení norem. V případě jakýchkoli rozporů mají přednost ustanovení tohoto dodatku.
Normy, na které se v tomto dodatku odkazuje:
—
Bluetooth® – Core Version 5.0.
—
ISO 16844-7: Road vehicles – Tachograph systems – Part 7: Parameters (Silniční vozidla – Systémy tachografů – Část 7: Parametry)
—
ISO/IEC7498-1:1994 (Informační technologie – Propojení otevřených systémů – Základní referenční vzor, základní vzor)
3. PRINCIPY ČINNOSTI ROZHRANÍ ITS
ITS_04
VU odpovídá za aktualizaci a uchovávání údajů z tachografu přenášených prostřednictvím rozhraní ITS bez jakéhokoli zapojení rozhraní ITS.
3.1. Komunikační technologie
ITS_05
Komunikace prostřednictvím rozhraní ITS se provádí prostřednictvím rozhraní Bluetooth® a je kompatibilní s Bluetooth® Low Energy podle Bluetooth verze 5.0 nebo novější.
ITS_06
Komunikace mezi VU a stanovištěm ITS se zřídí po dokončení procesu párování Bluetooth®.
ITS_07
Musí být zavedena zabezpečená a zakódovaná komunikace mezi VU a stanovištěm ITS v souladu s mechanismy specifikace Bluetooth®. Tento dodatek nespecifikuje kódování ani jiné bezpečnostní mechanismy kromě toho, co poskytuje Bluetooth®.
ITS_08
Bluetooth ® používá k řízení přenosu dat mezi zařízeními model server/klient, přičemž VU musí být serverem a stanoviště ITS musí být klientem.
3.2. Dostupné služby
ITS_09
Data, která mají být přenášena prostřednictvím rozhraní ITS v souladu s bodem 4, musí být zpřístupněna prostřednictvím služeb uvedených v dodatcích 7 a 8. VU kromě toho poskytne stanovišti ITS služby, které jsou nezbytné pro ruční zadávání údajů v souladu s požadavkem 61 v příloze IC, a volitelně i pro jiné vkládání údajů v reálném čase.
ITS_10
Je-li rozhraní pro stahování použito přes přední konektor, nesmí celek ve vozidle poskytovat služby stahování dat uvedené v dodatku 7 prostřednictvím připojení ITS Bluetooth®.
ITS_11
Je-li kalibrační rozhraní používáno přes přední konektor, nesmí celek ve vozidle poskytovat kalibrační služby uvedené v dodatku 8 prostřednictvím připojení ITS Bluetooth®.
3.3. Přístup přes rozhraní ITS
ITS_12
Rozhraní ITS musí poskytovat bezdrátový přístup ke všem službám uvedeným v dodatku 7 a v dodatku 8 jako náhradu kabelového připojení k přednímu konektoru pro kalibraci a stahování podle dodatku 6.
ITS_13
VU musí uživateli zpřístupnit rozhraní ITS v souladu s kombinací platných karet tachografu vložených do celku ve vozidle, jak je uvedeno v tabulce 1.
Tabulka 1
Dostupnost rozhraní ITS v závislosti na typu karty vložené do tachografu
Dostupnost rozhraní ITS
otvor pro kartu řidiče
žádná karta
karta řidiče
kontrolní karta
karta dílny
karta podniku
otvor pro kartu druhého řidiče
žádná karta
není k dispozici
k dispozici
k dispozici
k dispozici
k dispozici
karta řidiče
k dispozici
k dispozici
k dispozici
k dispozici
k dispozici
kontrolní karta
k dispozici
k dispozici
k dispozici
není k dispozici
není k dispozici
karta dílny
k dispozici
k dispozici
není k dispozici
k dispozici
není k dispozici
karta podniku
k dispozici
k dispozici
není k dispozici
není k dispozici
k dispozici
ITS_14
Po úspěšném spárování ITS Bluetooth® musí VU přidělit připojení ITS Bluetooth® konkrétní vložené kartě tachografu podle tabulky 2:
Tabulka 2
Přidělení připojení ITS v závislosti na typu karty vložené do tachografu
Je-li karta tachografu vyjmuta, VU ukončí připojení ITS Bluetooth®, které je přiděleno dané kartě.
ITS_16
VU musí podporovat připojení ITS alespoň k jedné jednotce ITS a zároveň může podporovat připojení k více jednotkám ITS.
ITS_17
Přístupová práva k datům a službám dostupným prostřednictvím rozhraní ITS musí kromě souhlasu řidiče uvedeného v oddíle 3.4 tohoto dodatku splňovat požadavky 12 a 13 v příloze IC.
3.4 Dostupné údaje a potřeba souhlasu řidiče
ITS_18
Všechny údaje tachografu dostupné prostřednictvím služeb uvedených v bodě 3.3 se pro řidiče, druhého řidiče nebo oba klasifikují buď jako osobní, nebo nikoli.
ITS_19
Prostřednictvím rozhraní ITS musí být zpřístupněn alespoň seznam dat klasifikovaných jako povinné v oddíle 4.
ITS_20.
Údaje v oddíle 4, které jsou klasifikovány jako „osobní“, jsou přístupné pouze se souhlasem řidiče, čímž se tudíž souhlasí s tím, že osobní údaje mohou opustit síť vozidla, s výjimkou případu stanoveného v požadavku ITS_25, pro který není souhlas řidiče nutný.
ITS_21
Údaje doplňující údaje shromážděné v bodě 4 a považované za povinné mohou být zpřístupněny prostřednictvím rozhraní ITS. Další údaje, které nejsou uvedeny v bodě 4, klasifikuje výrobce VU jako „osobní“ nebo nikoli „osobní“, což je souhlas řidiče požadovaný pro údaje, které byly klasifikovány jako osobní, s výjimkou případu stanoveného v požadavku ITS_25, pro který není souhlas řidiče nutný.
ITS_22
Po vložení karty řidiče, která není celku ve vozidle známá, musí být držitel karty tachografem vyzván, aby vložil svůj souhlas s přenosem výstupu osobních údajů prostřednictvím rozhraní ITS v souladu s požadavkem 61 v příloze IC.
ITS_23
Stav souhlasu (povoleno/zamítnuto) musí být zaznamenán v datové paměti celku ve vozidle.
ITS_24
V případě více řidičů jsou s rozhraním ITS sdíleny pouze osobní údaje o řidičích, kteří poskytli souhlas. Například v situaci posádky, kdy k tomu dal souhlas pouze řidič, nejsou osobní údaje týkající se druhého řidiče přístupné.
ITS_25
Je-li celek ve vozidle v kontrolním, podnikovém nebo kalibračním režimu, musí být přístupová práva spravována prostřednictvím rozhraní ITS v souladu s požadavky 12 a 13 v příloze IC, a proto není nutný souhlas řidiče.
4. SEZNAM ÚDAJŮ DOSTUPNÝCH PROSTŘEDNICTVÍM ROZHRANÍ ITS A KLASIFIKACE OSOBNÍ/NEOSOBNÍ
Název údaje
Formát údaje
Zdroj
Klasifikace údajů (osobní/neosobní)
Souhlas s dostupností údajů
Dostupnost
řidič
druhý řidič
VehicleIdentificationNumber
Dodatek 8
VU
neosobní
neosobní
souhlas není nutný
povinné
CalibrationDate
ISO 16844-7
VU
neosobní
neosobní
souhlas není nutný
povinné
TachographVehicleSpeed
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
povinné
Driver1WorkingState
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
povinné
Driver2WorkingState
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
povinné
DriveRecognize
ISO 16844-7
VU
neosobní
neosobní
souhlas není nutný
povinné
Driver1TimeRelatedStates
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
povinné
Driver2TimeRelatedStates
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
povinné
DriverCardDriver1
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
povinné
DriverCardDriver2
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
povinné
OverSpeed
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
povinné
TimeDate
Dodatek 8
VU
neosobní
neosobní
souhlas není nutný
povinné
HighResolutionTotalVehicleDistance
ISO 16844-7
VU
neosobní
neosobní
souhlas není nutný
povinné
HighResolutionTripDistance
ISO 16844-7
VU
neosobní
neosobní
souhlas není nutný
povinné
ServiceComponentIdentification
ISO 16844-7
VU
neosobní
neosobní
souhlas není nutný
povinné
ServiceDelayCalendarTimeBased
ISO 16844-7
VU
neosobní
neosobní
souhlas není nutný
povinné
Driver1Identification
ISO 16844-7
Karta řidiče
osobní
neuvádí se
souhlas řidiče
povinné
Driver2Identification
ISO 16844-7
Karta řidiče
neuvádí se
osobní
souhlas druhého řidiče
povinné
NextCalibrationDate
Dodatek 8
VU
neosobní
neosobní
souhlas není nutný
povinné
Driver1ContinuousDrivingTime
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
povinné
Driver2ContinuousDrivingTime
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
povinné
Driver1CumulativeBreakTime
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
povinné
Driver2CumulativeBreakTime
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
povinné
Driver1CurrentDurationOfSelectedActivity
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
povinné
Driver2CurrentDurationOfSelectedActivity
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
povinné
SpeedAuthorised
Dodatek 8
VU
neosobní
neosobní
souhlas není nutný
povinné
TachographCardSlot1
ISO 16844-7
VU
neosobní
neuvádí se
souhlas není nutný
povinné
TachographCardSlot2
ISO 16844-7
VU
neuvádí se
neosobní
souhlas není nutný
povinné
Driver1Name.
ISO 16844-7
Karta řidiče
osobní
neuvádí se
souhlas řidiče
povinné
Driver2Name
ISO 16844-7
Karta řidiče
neuvádí se
osobní
souhlas druhého řidiče
povinné
OutOfScopeCondition
ISO 16844-7
VU
neosobní
neosobní
souhlas není nutný
povinné
ModeOfOperation
ISO 16844-7
VU
neosobní
neosobní
souhlas není nutný
povinné
Driver1CumulatedDrivingTimePreviousAndCurrentWeek
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
povinné
Driver2CumulatedDrivingTimePreviousAndCurrentWeek
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
povinné
EngineSpeed
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
RegisteringMemberState
Dodatek 8
VU
neosobní
neosobní
souhlas není nutný
povinné
VehicleRegistrationNumber
Dodatek 8
VU
neosobní
neosobní
souhlas není nutný
povinné
Driver1EndOfLastDailyRestPeriod
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2EndOfLastDailyRestPeriod
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1EndOfLastWeeklyRestPeriod
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2EndOfLastWeeklyRestPeriod
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1EndOfSecondLastWeeklyRestPeriod
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2EndOfSecondLastWeeklyRestPeriod
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1TimeLastLoadUnloadOperation
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2TimeLastLoadUnloadOperation
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1CurrentDailyDrivingTime
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2CurrentDailyDrivingTime
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1CurrentWeeklyDrivingTime
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2CurrentWeeklyDrivingTime
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1TimeLeftUntilNewDailyRestPeriod
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2TimeLeftUntilNewDailyRestPeriod
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1CardExpiryDate.
ISO 16844-7
Karta řidiče
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2CardExpiryDate
ISO 16844-7
Karta řidiče
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1CardNextMandatoryDownloadDate
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2CardNextMandatoryDownloadDate
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
TachographNextMandatoryDownloadDate
ISO 16844-7
VU
neosobní
neosobní
souhlas není nutný
nepovinné
Driver1TimeLeftUntilNewWeeklyRestPeriod
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2TimeLeftUntilNewWeeklyRestPeriod
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1NumberOfTimes9hDailyDrivingTimesExceeded
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2NumberOfTimes9hDailyDrivingTimesExceeded
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1CumulativeUninterruptedRestTime
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2CumulativeUninterruptedRestTime
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1MinimumDailyRest
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2MinimumDailyRest
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1MinimumWeeklyRest
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2MinimumWeeklyRest
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1MaximumDailyPeriod
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2MaximumDailyPeriod
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1MaximumDailyDrivingTime
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2MaximumDailyDrivingTime
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1NumberOfUsedReducedDailyRestPeriods
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2NumberOfUsedReducedDailyRestPeriods
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
Driver1RemainingCurrentDrivingTime
ISO 16844-7
VU
osobní
neuvádí se
souhlas řidiče
nepovinné
Driver2RemainingCurrentDrivingTime
ISO 16844-7
VU
neuvádí se
osobní
souhlas druhého řidiče
nepovinné
VehiclePosition
Dodatek 8
VU
osobní
osobní
souhlas řidiče a druhého řidiče
povinné
ByDefaultLoadType
Dodatek 8
VU
osobní
osobní
souhlas řidiče a druhého řidiče
povinné
“;
39)
dodatek 14 se mění takto:
a)
v obsahu se za bod 5.4.8 vkládá nový bod, který zní:
„5.5
Vyhrazeno pro budoucí použití“;
b)
v bodě 4.1.1.5 se odstavec DCS_17 nahrazuje tímto:
„DSC_17
Bezpečnostní data (DSRCSecurityData), obsahující údaje požadované REDCR pro účely dekódování dat, jsou poskytována v souladu s dodatkem 11 – Společné bezpečnostní mechanismy – pro dočasné uložení v DSRC-VU jako aktuální verze DSRCSecurityData, ve formě stanovené v tomto dodatku části 5.4.4.“;
c)
bod 5 se mění takto:
i)
v bodě 5.4.4 se sekvence TachographPayload v definici modulu ASN.1 pro data DSRC v aplikaci RTM nahrazuje tímto:
„
“;
ii)
v bodě 5.4.5 se tabulka 14.3 nahrazuje tímto:
„
Tabulka 14.3
Prvky RTMData, provedené akce a definice
(1)
Datový prvek RTM
(2)
Činnost, kterou provádí VU
(3)
Definice údajů podle ASN.1
RTM1.
Registrační značka
vozidla
VU určí hodnotu datového prvku RTM1 tp15638VehicleRegistrationPlate ze zaznamenané hodnoty datového typu
VehicleRegistrationIdentification podle definice v dodatku 1 VehicleRegistrationIdentification
Registrační značka vozidla vyjádřená jako řetězec znaků
tp15638VehicleRegistrationPlate LPN,
–– Registrační značka vozidla s datovou strukturou podle ISO 14906, avšak s následujícím omezením pro aplikaci RTM:
SEKVENCE začíná kódem země následovaným alfabetickým indikátorem, za nímž následuje samotné číslo značky,
které má vždy 14 oktetů (doplněných nulami), takže délka typu LPN je vždy 17 oktetů (není zapotřebí žádný determinant délky), z nichž 14 je „skutečné“ číslo značky.
RTM2
Událost Překročení povolené rychlosti
VU vygeneruje booleovskou
hodnotu pro datový prvek RTM2
tp15638SpeedingEvent.
Hodnotu tp15638SpeedingEvent vypočítá VU z počtu událostí překročení povolené rychlosti zaznamenaných ve VU v posledních 10 dnech výskytu podle definice v příloze IC.
1 (TRUE): jestliže nejnovější událost překročení povolené rychlosti skončila během posledních 10 dnů nebo stále probíhá;
0 (FALSE): ve všech ostatních případech.
tp15638SpeedingEvent BOOLEAN,
RTM3
Řízení bez
platné karty
VU vygeneruje booleovskou
hodnotu pro datový prvek RTM3
tp15638DrivingWithoutValidCard.
VU přiřadí proměnné tp15638DrivingWithoutValidCard hodnotu TRUE, pokud v celku ve vozidle byla během posledních 10 dnů zaznamenána alespoň jedna událost řízení bez příslušné karty podle definice v příloze IC.
1 (TRUE): jestliže poslední událost řízení bez příslušné karty skončila během posledních 10 dnů nebo stále probíhá;
0 (FALSE): ve všech ostatních případech.
tp15638DrivingWithoutValidCard
BOOLEAN,
RTM4
Platná karta řidiče
VU vygeneruje booleovskou hodnotu pro datový prvek RTM4
tp15638DriverCard na základě vložené platné karty řidiče v otvoru pro kartu řidiče.
1 (TRUE): není-li v otvoru pro kartu řidiče celku ve vozidle přítomna platná karta řidiče;
0 (FALSE): je-li v otvoru pro kartu řidiče celku ve vozidle přítomna platná karta řidiče.
tp15638DriverCard BOOLEAN,
RTM5
Vložení karty během
řízení
VU vygeneruje booleovskou hodnotu pro datový prvek RTM5 tp15638CardInsertion.
VU přiřadí proměnné tp15638CardInsertion hodnotu TRUE, pokud bylo ve VU během posledních 10 dnů zaznamenána alespoň jedna událost vložení karty během řízení podle definice v příloze IC.
1 (TRUE): pokud k poslední události vložení karty během řízení došlo během posledních 10 dnů;
0 (FALSE): ve všech ostatních případech.
tp15638CardInsertion BOOLEAN,
RTM6
Chyba údajů o pohybu
VU vygeneruje booleovskou
hodnotu pro datový prvek RTM6.
VU přiřadí proměnné tp15638MotionDataError hodnotu TRUE, pokud byla v celku ve vozidle během posledních 10 dnů zaznamenána alespoň jedna událost chyba údajů o pohybu podle definice v příloze IC.
1 (TRUE): jestliže poslední událost chyba údajů o pohybu skončila během posledních 10 dnů nebo stále probíhá;
0 (FALSE): ve všech ostatních případech.
tp15638MotionDataError BOOLEAN,
RTM7
Nesoulad údajů
o pohybu vozidla
VU vygeneruje booleovskou
hodnotu pro datový prvek RTM7.
VU přiřadí proměnné tp15638VehicleMotionConflict hodnotu TRUE, pokud byla v celku ve vozidle během posledních 10 dnů zaznamenána alespoň jedna událost nesoulad údajů o pohybu vozidla.
1 (TRUE): pokud poslední událost nesoulad údajů o pohybu vozidla skončila během posledních 10 dnů nebo stále probíhá;
0 (FALSE): ve všech ostatních případech.
tp15638VehicleMotionConflict
BOOLEAN,
RTM8
Karta druhého řidiče
VU vygeneruje booleovskou
hodnotu pro datový prvek RTM8 na základě přílohy IC (údaje o činnosti řidiče, POSÁDKA a DRUHÝ ŘIDIČ).
Je-li přítomna platná karta druhého řidiče, VU nastaví hodnotu RTM8 na TRUE.
1 (TRUE): je-li v celku ve vozidle přítomna platná karta druhého řidiče;
2 (FALSE): není-li v celku ve vozidle přítomna žádná platná karta druhého řidiče.
tp156382ndDriverCard BOOLEAN,
RTM9
Aktuální činnost
VU vygeneruje booleovskou
hodnotu pro datový prvek RTM9.
Je-li aktuální činnost zaznamenána v celku ve vozidle jako jakákoli jiná činnost než ŘÍZENÍ podle definice v příloze IC, nastaví VU hodnotu RTM9 na TRUE.
1 (TRUE): zvolena
jiná činnost;
0 (FALSE): zvoleno řízení
tp15638CurrentActivityDriving
BOOLEAN
RTM10
Poslední relace uzavřena
VU vygeneruje booleovskou hodnotu pro datový prvek RTM10.
Jestliže poslední relace karty nebyla správně uzavřena podle definice v příloze IC, VU nastaví hodnotu RTM10 na TRUE.
1 (TRUE): nejméně jedna z vložených karet vyvolala událost poslední relace karty nebyla správně uzavřena;
0 (FALSE): žádná z vložených karet nevyvolala událost poslední relace karty nebyla správně uzavřena.
tp15638LastSessionClosed
BOOLEAN
RTM11
Přerušení elektrického
napájení
VU vygeneruje celočíselnou
hodnotu pro datový prvek RTM11.
VU přiřadí hodnotu proměnné tp15638PowerSupplyInterruption, která je rovna počtu zaznamenaných případů přerušení elektrického napájení uložených ve VU během posledních 10 dnůpodle definice v příloze IC.
Pokud v celku ve vozidle nebyla v posledních deseti dnech zaznamenána žádná událost přerušení elektrického napájení, nastaví hodnotu RTM11 na 0.
Počet událostí přerušení elektrického napájení zaznamenaných během posledních 10 dnů.
tp15638PowerSupplyInterruption
INTEGER (0..127),
RTM12
Porucha snímače
VU vygeneruje celočíselnou hodnotu pro datový prvek RTM12.
VU přiřadí proměnné sensorFault hodnotu:
—
1, jestliže událost typu ‘35’H Porucha
snímače skončila během posledních 10 dnů nebo stále trvá,
—
2, jestliže událost typu Porucha přijímače GNSS (interního nebo externího s hodnotami enum ‘36’H nebo
‘37’H) skončila během posledních 10 dnů nebo stále probíhá,
—
3, jestliže událost typu ‘0E’H Chyba komunikace při události vnějšího zařízení GNSS skončila během posledních 10 dnů nebo stále probíhá,
—
4, pokud porucha snímače a poruchy přijímače GNSS během posledních 10 dnů skončily nebo stále probíhají,
—
5, v případě, že porucha snímače a chyba komunikace s vnějším zařízením GNSS skončila během posledních 10 dnů nebo stále probíhá,
—
6, pokud jak porucha přijímače GNSS, tak chyba komunikace s vnějším zařízením GNSS skončila během posledních 10 dnů nebo stále probíhají,
—
7, pokud všechny tři závady snímače skončily během posledních 10 dnů nebo stále probíhají,
Pokud žádná událost během posledních 10 dnů neskončila nebo ještě neprobíhá, VU nastaví hodnotu RTM12 na 0.
--porucha snímače – jeden oktet podle slovníku údajů
tp15638SensorFault INTEGER (0..255),
RTM13
Nastavení času
VU vygeneruje celočíselnou hodnotu (timeReal z dodatku 1) pro datový prvek RTM13 na základě přítomnosti údajů o nastavení času podle definice v příloze IC.
VU nastaví hodnotu RTM13 na čas, kdy došlo k poslední datové události nastavení času.
Není-li v datech VU zaznamenána žádná událost nastavení času podle definice v příloze IC, nastaví se hodnota RTM13 na 0.
oldTimeValue posledního nastavení času.
tp15638TimeAdjustment
INTEGER(0..4294967295),
RTM14
Pokus o narušení
zabezpečení
VU vygeneruje celočíselnou hodnotu (timeReal z dodatku 1) pro datový prvek RTM14 na základě přítomnosti události pokus o narušení zabezpečení podle definice v příloze IC.
VU nastaví hodnotu času posledního pokusu o narušení zabezpečení, který zaznamenal.
Není-li v datech VU zaznamenána žádná událost pokus o narušení zabezpečení podle definice v příloze IC, nastaví se hodnota RTM14 na 0.
Počáteční čas poslední uložené události pokus o narušení zabezpečení.
tp15638LatestBreachAttempt
INTEGER(0..4294967295),
RTM15
Poslední kalibrace
VU vygeneruje celočíselnou hodnotu (timeReal z dodatku 1) pro datový prvek RTM15 na základě přítomnosti údajů o poslední kalibraci podle definice v příloze IC a v dodatku 1.
VU nastaví hodnotu
RTM15 na oldTimeValue posledního záznamu o kalibraci.
Nedošlo-li k žádné kalibraci, VU nastaví hodnotu RTM15 na 0.
oldTimeValue nejnovějšího záznamu o kalibraci.
tp15638LastCalibrationData
INTEGER(0..4294967295),
RTM16
Předcházející kalibrace
VU vygeneruje celočíselnou hodnotu (timeReal z dodatku 1) pro datový prvek RTM16 na základě záznamu o kalibraci předcházející poslední kalibraci.
VU nastaví hodnotu
pro RTM16 na OldTimeValue záznamu o kalibraci předchozí kalibrace.
Nedošlo-li k žádné předchozí kalibraci, VU nastaví hodnotu RTM16 na 0.
oldTimeValue záznamu o kalibraci předcházejícího poslednímu záznamu o kalibraci.
tp15638PrevCalibrationData
INTEGER(0..4294967295),
RTM17
Datum připojení
tachografu
VU vygeneruje celočíselnou hodnotu (timeReal z dodatku 1) pro datový prvek RTM17.
VU nastaví hodnotu RTM17 na datum první kalibrace VU v aktuálním vozidle.
VU tyto údaje extrahuje z VuCalibrationData (dodatek 1) z vuCalibrationRecords, přičemž CalibrationPurpose se rovná: ’03’H
Nedošlo-li k žádné předchozí kalibraci, VU nastaví hodnotu RTM17 na 0.
Datum první kalibrace VU v aktuálním vozidle.
tp15638DateTachoConnected
INTEGER(0..4294967295),
RTM18
Aktuální rychlost
VU vygeneruje celočíselnou
hodnotu pro datový prvek RTM18.
VU nastaví hodnotu pro RTM18 na poslední aktuální zaznamenanou rychlost ve chvíli poslední aktualizace RtmData.
Poslední aktuální zaznamenaná rychlost
tp15638CurrentSpeed INTEGER (0..255),
RTM19
Časové razítko
VU vygeneruje celočíselnou hodnotu datového prvku RTM19 (timeRealz dodatku 1).
VU nastaví hodnotu pro RTM19 na čas poslední aktualizace RtmData.
Časové razítko aktuálního
záznamu TachographPayload
tp15638Timestamp
INTEGER(0..4294967295),
RTM20
Čas, kdy byla k dispozici poslední ověřená poloha vozidla
VU vygeneruje celočíselnou hodnotu (timeReal z dodatku 1) pro datový prvek RTM20.
VU nastaví hodnotu RTM20 na čas, kdy byla k dispozici poslední ověřená poloha vozidla z přijímače GNSS.
Pokud z přijímače GNSS nebyla k dispozici žádná ověřená poloha vozidla, VU nastaví hodnotu RTM20 na 0.
Časové razítko poslední ověřené polohy vozidla
tp15638LatestAuthenticatedPosition
INTEGER(0..4294967295),
RTM21
Nepřetržitá doba řízení
VU vygeneruje celočíselnou hodnotu pro datový prvek RTM21.
VU nastaví hodnotu RTM21 na probíhající nepřetržitou dobu řízení řidiče.
Nepřetržitá doba řízení řidiče, kódovaná jako celočíselná hodnota.
Délka: 1 bajt
Rozlišení: 2 minuty/bit
Žádný offset
Rozsah údajů: 0 až 250
Hodnota 250 značí, že nepřetržitá doba řízení řidiče je 500 minut nebo více.
Hodnoty 251 až 254 nejsou použity.
Hodnota 255 značí, že informace nejsou k dispozici.
tp15638ContinuousDrivingTime INTEGER(0..255),
RTM22
Nejdelší denní doba řízení probíhající a předchozí směny RTM, vypočtená podle doplňku k dodatku 14
VU vygeneruje celočíselnou hodnotu pro datový prvek RTM22.
VU nastaví hodnotu RTM22 na delší ze dvou denních dob řízení řidiče, což je buď probíhající, nebo předchozí směna RTM.
Denní doba řízení řidiče, kódovaná jako celočíselná hodnota.
Délka: 1 bajt
Rozlišení: 4 minuty/bit
Žádný offset
Rozsah údajů: 0 až 250
Hodnota 250 značí, že denní doba řízení řidiče je rovna 1 000 minutám nebo delší.
Hodnoty 251 až 254 nejsou použity.
Hodnota 255 značí, že informace nejsou k dispozici.
tp15638DailyDrivingTimeShift INTEGER(0..255),
RTM23
Nejdelší denní doba řízení během probíhajícího týdne, vypočtená podle doplňku k dodatku 14
VU vygeneruje celočíselnou hodnotu pro datový prvek RTM23.
VU nastaví hodnotu RTM23 na nejdelší denní dobu řízení řidiče, což je buď probíhající směna RTM, nebo jakákoli dokončená směna RTM, která byla zahájena nebo dokončena v probíhajícím týdnu.
Denní doba řízení řidiče, kódovaná jako celé číslo.
Délka: 1 bajt
Rozlišení: 4 minut/bit
Žádný offset
Rozsah údajů: 0 až 250
Hodnota 250 značí, že denní doba řízení řidiče je rovna 1 000 minutám nebo delší.
Hodnoty 251 až 254 nejsou použity.
Hodnota 255 značí, že informace nejsou k dispozici.
tp15638DailyDrivingTimeWeek INTEGER(0..255),
RTM24
Týdenní doba řízení vypočítaná podle doplňku k dodatku 14
VU vygeneruje celočíselnou hodnotu pro datový prvek RTM24.
VU nastaví hodnotu RTM24 na týdenní dobu řízení řidiče.
Týdenní doba řízení řidiče, kódovaná jako celočíselná hodnota.
Délka: 1 bajt
Rozlišení: 20 minut/bit
Žádný offset
Rozsah údajů: 0 až 250
Hodnota 250 označuje, že týdenní doba řízení řidiče je 5 000 minut nebo více.
Hodnoty 251 až 254 nejsou použity.
Hodnota 255 značí, že informace nejsou k dispozici.
tp15638WeeklyDrivingTime INTEGER(0..255),
RTM25
Čtrnáctidenní doba řízení vypočítaná podle doplňku k dodatku 14
VU vygeneruje celočíselnou hodnotu pro datový prvek RTM25.
VU nastaví hodnotu RTM25 na čtrnáctidenní dobu řízení řidiče.
Čtrnáctidenní doba řízení řidiče, kódovaná jako celočíselná hodnota.
Délka: 1 bajt
Rozlišení: 30 minut/bit
Žádný offset
Rozsah údajů: 0 až 250
Hodnota 250 značí, že čtrnáctidenní doba řízení řidiče je 7 500 minut nebo více.
Hodnoty 251 až 254 nejsou použity.
Hodnota 255 značí, že informace nejsou k dispozici.
tp15638FortnightlyDrivingTime INTEGER(0..255),
Poznámka: RTM22, RTM23, RTM24 a RTM25 se vypočítají podle doplňku k tomuto dodatku.“;
iii)
v bodě 5.4.7 se tabulka 14.9 nahrazuje tímto:
„Tabulka 14.9
Inicializace– příklad obsahu rámce VST
Oktet č.
Atribut/pole
Bity v oktetu
Popis
1
FLAG
0111 1110
Příznak začátku
2
Private LID
xxxx xxxx
Adresa spojení konkrétního DSRC-VU
3
xxxx xxxx
4
xxxx xxxx
5
xxxx xxxx
6
MAC Control field
1100 0000
PDU příkazu
7
LLC Control field
0000 0011
Příkaz UI
8
Fragmentation header
1xxx x001
Bez fragmentace
9
VST
SEQUENCE {
Fill BIT STRING (SIZE(4))
1001
Odpověď v rámci inicializace
0000
Nepoužito a nastaveno na 0.
10
Profile INTEGER (0..127,...)
Applications SEQUENCE OF {
0000 0000
Bez rozšíření. Příklad profilu 0
Bez rozšíření, 1 aplikace
11
0000 0001
12
SEQUENCE {
OPTION indicator
OPTION indicator
AID DSRCApplicationEntityID
1
EID přítomný
1
Parametr přítomný
00 0010
Bez rozšíření. AID = 2 Freight&Fleet
13
EID Dsrc-EID
xxxx xxxx
Definováno v rámci OBU, identifikuje instanci aplikace.
14
Parameter Container {
0000 0010
Bez rozšíření, volba kontejneru = 02,
oktetový řetězec
15
0000 0110
Bez rozšíření, délka kontextové značky Rtm = 6
16
Rtm-ContextMark ::= SEQUENCE {
StandardIdentifier
0000 0101
První oktet je 05H, což je délka.
Následujících5 oktetů kóduje identifikátor objektu podporované normy, části a verze.
{ISO (1) Standard (0) TARV (15638) part9(9) Version2 (2)}
17
standardIdentifier
0010 1000
18
1111 1010
19
0001 0110
20
0000 1001
21
0000 0010
22
ObeConfiguration Sequence {
OPTION indicator
0
ObeStatus nepřítomný
EquipmentClass INTEGER (0..32767)
xxx xxxx
Toto pole se použije pro uvedení
23
xxxx xxxx
údajů výrobce o verzi softwaru/hardwaru rozhraní DSRC
24
ManufacturerId INTEGER (0..65535)
xxxx xxxx
Identifikátor výrobce DSRC-VU, jak je popsán v rejstříku ISO 14816
25
xxxx xxxx
26
FCS
xxxx xxxx
Kontrolní sekvence rámce
27
xxxx xxxx
28
Flag
0111 1110
Příznak ukončení
“;
iv)
vkládá se nový bod 5.5, který zní:
„5.5
Vyhrazeno pro budoucí použití“;
v)
v bodě 5.7 se odstavce DSC_77 a DSC_78 nahrazují tímto:
„DSC_77
Již zabezpečená data se DSRC-VU poskytnou funkcí VUSM. VUSM ověří, zda data zaznamenaná v DSRC-VU byla do DSRC-VU úspěšně přenesena. Zaznamenání a hlášení případných chyb v přenosu dat z VU do paměti DSRC-VU se zaznamenají s typem EventFaultType a hodnotou enum nastavenou na ‘0C’H událost Chyba komunikace se zařízením pro dálkovou komunikaci s časovým razítkem. VUSM ověří, zda data byla do DSRC-VU úspěšně přenesena.
DSC_78
Vyhrazeno pro budoucí použití.“;
d)
doplňuje se nový doplněk, který zní:
„DOPLNĚK
Pravidla pro výpočet denní, týdenní a čtrnáctidenní doby řízení
1.
Základní pravidla výpočtu
VU vypočítá denní dobu řízení, týdenní dobu řízení a čtrnáctidenní dobu řízení s použitím příslušných údajů uložených na kartě řidiče (nebo na kartě dílny) vložené do otvoru pro kartu řidiče (otvor č. 1, čtečka karet #1) celku ve vozidle a vybraných činností řidiče, když je tato karta vložena do celku ve vozidle.
Doby řízení se nepočítají, dokud není vložena karta řidiče (nebo karta dílny).
NEZNÁMÁ doba (NEZNÁMÉ doby, UNKNOWN period(s)) zjištěná (zjištěné) během doby potřebné pro výpočty se začleňuje (začleňují) do položky PŘESTÁVKA/ODPOČINEK (BREAK/REST).
NEZNÁMÁ doba a činnosti se zápornou dobou trvání (tj. zahájení činnosti nastane později než ukončení činnosti) z důvodu časového překrývání mezi dvěma různými VU nebo z důvodu nastavení času se neberou v úvahu.
Činnosti zaznamenané na kartě řidiče odpovídající dobám „MIMO PŮSOBNOST“ (OUT OF SCOPE) v souladu s definicí v písmenu gg) přílohy IC se vykládají takto:
—
PŘESTÁVKA/ODPOČINEK (BREAK/REST) se vypočítá jako „PŘESTÁVKA“ nebo „ODPOČINEK“
—
PRÁCE (WORK) a JÍZDA (DRIVING) se považují za „PRÁCE“
—
POHOTOVOST (AVAILABILITY) se považuje za „POHOTOVOST“
V souvislosti s tímto dodatkem musí VU předpokládat, že má na začátku záznamů činností karty denní dobu odpočinku.
2.
Pojmy
Následující pojmy se vztahují výhradně na tento dodatek a jejich účelem je upřesnit výpočet dob řízení celkem ve vozidle a jeho pozdější přenos zařízením pro dálkovou komunikaci.
a)
„směna RTM" je doba mezi koncem denní doby odpočinku a koncem bezprostředně následující denní doby odpočinku.
VU zahájí novou směnu RTM po uplynutí denní doby odpočinku.
Probíhající směna RTM je doba od konce poslední denní doby odpočinku;
b)
„součtová doba řízení“ je součet všech činností řízení řidiče v době, kdy není MIMO PŮSOBNOST;
c)
„denní doba řízení“ je součtová doba řízení v rámci směny RTM;
d)
„týdenní doba řízení“ je součtová doba řízení v probíhajícím týdnu;
e)
„nepřetržitá doba odpočinku“ je jakákoli nepřerušená doba PŘESTÁVKA/ODPOČINEK;
f)
„čtrnáctidenní doba řízení" je součtová doba řízení za předchozí a probíhající týden;
g)
„denní doba odpočinku“ je doba PŘESTÁVKA/ODPOČINEK, která může být buď
—
pravidelnou denní dobu odpočinku,
—
rozdělenou dobou denního odpočinku, nebo
—
zkrácenou dobou denního odpočinku.
V kontextu dodatku 14, pokud VU vypočítává týdenní doby odpočinku, považují se tyto týdenní doby odpočinku za denní doby odpočinku;
h)
„pravidelná denní doba odpočinku“ je nepřetržitá doba odpočinku v délce nejméně 11 hodin.
Výjimečně, je-li aktivní podmínka PŘEVOZ LODÍ / PŘEVOZ VLAKEM, může být pravidelná denní doba odpočinku přerušena nejvýše dvakrát jinými činnostmi, než je doba odpočinku, s maximální součtovou dobou trvání jedné hodiny, tj. pravidelná denní dobu odpočinku zahrnující dobu (doby) převozu lodí/vlakem může být rozdělena na dvě nebo tři části. VU pak vypočte pravidelnou denní dobu odpočinku, pokud součtová doba odpočinku vypočtená podle bodu 3 činí nejméně 11 hodin.
Pokud byla pravidelná denní doba odpočinku přerušena, VU:
—
nezahrne do výpočtu denní doby řízení řidičskou činnost, která se vyskytla během těchto přerušení, a
—
zahájí novou směnu RTM na konci přerušené pravidelné denní doby odpočinku.
i)
„zkrácená denní doba odpočinku“ je doba nepřetržitého odpočinku v délce nejméně 9 hodin a kratší než 11 hodin;
j)
„rozdělená denní doba odpočinku“ je denní doba odpočinku vybíraná ve dvou částech:
—
první částí je nepřetržitá doba odpočinku v délce nejméně 3 hodiny a kratší než 9 hodin,
—
druhou částí je nepřetržitá doba odpočinku v délce nejméně 9 hodin.
Výjimečně, pokud je podmínka PŘEVOZ LODÍ / PŘEVOZ VLAKEM aktivní během jedné nebo obou částí rozdělené denní doby odpočinku, může být rozdělená denní doba odpočinku přerušena nejvýše dvakrát jinými činnostmi s celkovou dobou trvání maximálně jedné hodiny, tj.:
—
první část rozdělené denní doby odpočinku může být přerušena jednou nebo dvakrát, nebo
—
druhá část rozdělené denní doby odpočinku může být přerušena jednou nebo dvakrát, nebo
—
první část rozdělené denní doby odpočinku může být přerušena jednou a druhá část rozdělené denní doby odpočinku může být přerušena také jednou.
VU pak vypočte rozdělenou denní dobu odpočinku, pokud součtová doba odpočinku vypočtená podle bodu 3 je:
—
nejméně tři hodiny a méně než 11 hodin v první době odpočinku a nejméně 9 hodin v druhé době odpočinku, pokud byla první doba odpočinku přerušena PŘEVOZ LODÍ / PŘEVOZ VLAKEM (převozem lodí či vlakem).
—
nejméně tři hodiny a méně než 9 hodin v případě první doby odpočinku a nejméně 9 hodin v případě druhé doby odpočinku, pokud první doba odpočinku nebyla přerušena PŘEVOZ LODÍ / PŘEVOZ VLAKEM.
Je-li rozdělená denní doba odpočinku přerušena, VU:
—
nezahrne do výpočtu denní doby řízení řidičskou činnost, která se vyskytla během těchto přerušení, a
—
zahájí novou směnu RTM na konci rozdělené denní doby odpočinku, která byla přerušena;
k)
„týden“ je doba v UTC mezi 00:00 hodinou v pondělí a 24:00 hodinou v neděli;
3.
Výpočet doby odpočinku, pokud byla přerušena z důvodu převozu lodí/vlakem
Pro výpočet doby odpočinku, když byla přerušena v důsledku převozu lodí/vlakem, vypočítá VU součtovou dobu odpočinku podle těchto kroků:
a)
Krok č. 1
VU zjistí přerušení doby odpočinku před aktivací příznaku PŘEVOZ LODÍ / PŘEVOZ VLAKEM (ZAČÁTEK) podle obrázku 3 a v případě obrázku 4 a vyhodnotí u každého zjištěného přerušení, jsou-li splněny tyto podmínky:
—
přerušení způsobuje, že celková doba trvání zjištěných přerušení, včetně přerušení, k nimž dojde během první části rozdělené denní doby odpočinku z důvodu převozu lodí/vlakem, překročí celkem více než jednu hodinu,
—
přerušení způsobuje, že celkový počet zjištěných přerušení, včetně přerušení, k nimž dojde během první části rozdělené denní doby odpočinku v důsledku převozu lodí/vlakem, je větší než dvě,
—
po skončení přerušení se uloží „Entry of place where daily work periods end“ (záznam o místě, kde končí denní pracovní doba).
Není-li splněna žádná z výše uvedených podmínek, započítá se k součtové době odpočinku nepřetržitá doba odpočinku bezprostředně předcházející přerušení.
Je-li splněna alespoň jedna z výše uvedených podmínek, VU buď zastaví výpočet součtové doby odpočinku podle kroku 2, nebo zjistí přerušení doby odpočinku po příznaku PŘEVOZ LODÍ / PŘEVOZ VLAKEM (ZAČÁTEK) podle kroku 3.
b)
Krok č. 2
U každého přerušení zjištěného podle kroku 1 VU vyhodnotí, zda by se měl výpočet součtové doby odpočinku zastavit. VU zastaví proces výpočtu, pokud byly k součtové době odpočinku přidány dvě nepřetržité doby odpočinku, k nimž došlo před aktivací příznaku PŘEVOZ LODÍ / PŘEVOZ VLAKEM (ZAČÁTEK), včetně doby odpočinku doplněné v první části rozdělené denní doby odpočinku, která je rovněž přerušena převozem lodí/vlakem. V opačném případě VU postupuje podle kroku 3.
c)
Krok č. 3
Pokud po provedení kroku 2 VU pokračuje ve výpočtu součtové doby odpočinku, musí VU zjistit přerušení, k nimž došlo po deaktivaci podmínky PŘEVOZ LODÍ / PŘEVOZ VLAKEM podle obrázku 3 a v jeho případě na obrázku 4.
U každého zjištěného přerušení VU vyhodnotí, zda přerušení vede k tomu, že celková doba všech zjištěných přerušení přesáhla celkem více než jednu hodinu, přičemž v takovém případě se výpočet součtové doby odpočinku ukončí na konci nepřetržité doby odpočinku předcházející přerušení. V opačném případě se k výpočtu denní doby odpočinku připočtou nepřetržité doby odpočinku, které nastanou po příslušném přerušení, dokud není splněna podmínka v kroku 4.
d)
Krok č. 4
Výpočet součtové doby odpočinku se musí zastavit, jakmile VU v důsledku kroků 1 a 3 přičte k době odpočinku, pro kterou je aktivována podmínka PŘEVOZ LODÍ / PŘEVOZ VLAKEM, maximálně dvě nepřetržité doby odpočinku, v jeho případě včetně přerušení, k nimž dojde během první části rozdělené denní doby odpočinku v důsledku převozu lodí/vlakem.
4.
Výpočet denních, týdenních a čtrnáctidenních dob řízení
VU vypočítá denní dobu (doby) řízení pro probíhající a předchozí směny RTM. Doba řízení, k níž dojde během přerušení denní doby odpočinku, se nepřipočítává k výpočtu denní doby řízení, pokud je toto přerušení způsobeno převozem lodí/vlakem a pokud byly splněny požadavky stanovené v bodech 2 písm. h) a j) a v bodě 3. Pokud však VU nevypočítal úplnou pravidelnou nebo rozdělenou denní dobu odpočinku podle bodu 3, doby řízení, k nimž dojde během přerušení, se připočtou k denní době řízení pro probíhající směnu RTM.
VU rovněž vypočítá týdenní a čtrnáctidenní dobu řízení. Doba řízení, k níž dojde během přerušení denní doby odpočinku z důvodu převozu lodí/vlakem, se připočte k výpočtu týdenní a čtrnáctidenní doby řízení.
“;
40)
dodatek 15 se mění takto:
a)
nadpis se nahrazuje tímto:
„Dodatek 15
MIGRACE: ŘÍZENÍ KOEXISTENCE GENERACÍ A VERZÍ ZAŘÍZENÍ
“;
b)
obsah se mění takto:
i)
bod 2.2 se nahrazuje tímto:
„2.2.
Interoperabilita mezi celky ve vozidle a kartami“;
ii)
doplňuje se nový bod 5, který zní:
„5.
ZÁZNAM PŘEKROČENÍ HRANIC V PRVNÍ GENERACI A PRVNÍ VERZI DRUHÉ GENERACE TACHOGRAFŮ“;
c)
body 2 až 4 se nahrazují tímto:
„2.
OBECNÁ USTANOVENÍ
2.1
Přechod na novou generaci
Úvod této přílohy poskytuje přehled o přechodu z první na druhou generaci systémů tachografů a o zavedení druhé verze záznamového zařízení a karet tachografu druhé generace.
Kromě ustanovení tohoto úvodu lze připomenout tyto informace:
—
snímače pohybu první generace nejsou interoperabilní s žádnou verzí celků ve vozidle druhé generace,
—
ve vozidlech vybavených jakoukoli verzí celků ve vozidle druhé generace lze instalovat pouze snímače pohybu druhé generace,
—
zařízení pro stahování dat a kalibraci musí podporovat používání obou generací nebo verzí záznamového zařízení a karet tachografu.
2.2
Interoperabilita mezi celky ve vozidle a kartami
Rozumí se, že karty tachografu první generace jsou interoperabilní s celky ve vozidle první generace (v souladu s přílohou IB nařízení (EHS) č. 3821/85) a každá verze tachografů druhé generace je interoperabilní s kteroukoli verzí celků ve vozidle druhé generace (v souladu s přílohou IC tohoto nařízení). Kromě toho se uplatní níže uvedené požadavky.
MIG_001
Kromě případů uvedených v požadavcích MIG_004 a MIG_005 mohou být karty tachografu první generace nadále používány v celcích ve vozidlech nové verze druhé generace až do uplynutí jejich data platnosti. Jejich držitelé však mohou požádat o jejich výměnu za karty tachografu druhé generace, jakmile budou k dispozici.
MIG_002
Kterákoli verze celků ve vozidle druhé generace musí být schopna používat jakoukoli platnou vloženou kartu řidiče, kontrolní kartu nebo kartu podniku první generace.
MIG_003
Tato schopnost může být jednou provždy v uvedeném celku ve vozidle dílnami odstraněna, takže karty tachografů první generace nemohou být již dále přijímány. To lze provést pouze poté, co Evropská komise zahájí postup, jehož cílem je dílny požádat, aby tak učinily, např. během každé periodické kontroly tachografu.
MIG_004
Celky ve vozidle druhé generace musí být schopny používat pouze karty dílny druhé generace.
MIG_005
Pro určení provozního režimu musí celky ve vozidlech kterékoli verze druhé generace přihlížet pouze k typům platných vložených karet bez ohledu na jejich generace nebo verze.
MIG_006
Jakoukoli verzi platné karty tachografu druhé generace musí být možné použít v celcích ve vozidle první generace naprosto stejným způsobem jako kartu tachografu první generace stejného typu.
2.3
Interoperabilita mezi celky ve vozidle a snímači pohybu
Rozumí se, že snímače pohybu první generace jsou interoperabilní s první generací celků ve vozidle, zatímco snímače pohybu druhé generace jsou interoperabilní s kteroukoli verzí druhé generace celků ve vozidle. Kromě toho se uplatní níže uvedené požadavky.
MIG_007
Žádná verze celků ve vozidle druhé generace nebude moci být spárována a používána se snímači pohybu první generace.
MIG_008
Snímače pohybu druhé generace mohou být spárovány a používány pouze s celky ve vozidle kterékoli verze druhé generace nebo s oběma generacemi celků ve vozidle.
2.4
Interoperabilita mezi celky ve vozidle, kartami tachografu a zařízením pro stahování dat
MIG_009
Zařízení pro stahování dat může být kompatibilní se všemi generacemi a verzemi celků ve vozidle a karet tachografu.
2.4.1
Přímé stahování z karet prostřednictvím inteligentního vyhrazeného zařízení (IDE)
MIG_010
Data se musí z karet tachografu jedné generace vložených do čtečky karet stahovat pomocí IDE s použitím bezpečnostních mechanismů a protokolu pro stahování dat této generace a stahovaná data musí být ve formátu definovaném pro tuto generaci a verzi.
MIG_011
Aby se umožnila kontrola řidičů kontrolními orgány, které nepatří do EU, musí být rovněž umožněno stahování dat z karty řidiče (a karty dílny) kterékoli verze druhé generace naprosto stejným způsobem jako z karty řidiče (a karty dílny) první generace. Uvedené stahování musí zahrnovat:
—
nepodepsané elementární soubory EF IC a ICC (volitelné),
—
nepodepsané elementární soubory (EF) (první generace) Card_Certificate a CA_Certificate,
—
ostatní elementární soubory EF s aplikačními daty (v rámci souboru DF Tachograph) vyžadované protokolem pro stahování dat z karet první generace. Tyto informace musí být zabezpečeny digitálním podpisem podle bezpečnostních mechanismů první generace.
Uvedené stahování nesmí zahrnovat elementární soubory EF s aplikačními daty, které jsou přítomny pouze na kartách řidiče (a kartách dílny) ve verzi 1 nebo verzi 2 druhé generace (elementární soubory EF s aplikačními daty v rámci souboru DF Tachograph_G2).
2.4.2
Stahování z karet prostřednictvím celku ve vozidle
MIG_012
Data se musí stahovat z karty kterékoli verze druhé generace, vložené do celku ve vozidle první generace pomocí protokolu pro stahování dat první generace. Karta musí na příkazy celku ve vozidle odpovídat naprosto stejným způsobem jako karta první generace a stahovaná data musí mít stejný formát jako data stahovaná z karty první generace.
MIG_013
Data se musí stahovat z karty první generace vložené do celku ve vozidle kterékoli verze druhé generace pomocí protokolu pro stahování dat definovaného v dodatku 7 této přílohy. Celek ve vozidle musí vysílat příkazy do karty naprosto stejným způsobem jako celek ve vozidle první generace a stahovaná data musí respektovat formát definovaný pro karty první generace.
2.4.3
Stahování z celku ve vozidle
MIG_014
Nad rámec kontroly řidičů kontrolními orgány, které nepatří do EU, se data musí stahovat z celků ve vozidle druhé generace pomocí bezpečnostních mechanismů druhé generace a protokolu pro stahování dat specifikovaného v dodatku 7 této přílohy uvedené pro příslušnou verzi.
MIG_015
Aby se umožnila kontrola řidičů kontrolními orgány, které nepatří do EU, lze také případně umožnit stahování dat z celků ve vozidle kterékoli verze druhé generace pomocí bezpečnostních mechanismů první generace. Stahovaná data pak musí mít stejný formát jako data stahovaná z celku ve vozidle první generace. Tuto možnost lze zvolit pomocí příkazů v menu.
2.5
Interoperabilita mezi celkem ve vozidle a kalibračním zařízením
MIG_016
Kalibrační zařízení musí být schopno provádět kalibraci všech generací či verzí tachografu pomocí kalibračního protokolu příslušné generace či verze. Kalibrační zařízení může být kompatibilní se všemi generacemi a verzemi celků ve vozidle.
3.
HLAVNÍ KROKY V OBDOBÍ PŘED DATEM ZAVEDENÍ
MIG_017
Testovací klíče a certifikáty musí být výrobcům k dispozici ke dni zveřejnění této přílohy.
MIG_018
Zkoušky interoperability musí být připraveny k zahájení s verzí 2 celků ve vozidle a verzí 2 karet tachografu, pokud o to výrobci požádají nejpozději 15 měsíců před datem zavedení.
MIG_019
Pro tachografy, karty tachografu a snímače pohybu verze 2 druhé generace se používají stejné klíče a certifikáty jako pro zařízení verze 1 druhé generace.
MIG_020
Členské státy musí být schopny vydávat karty dílny verze 2 druhé generace nejpozději 1 měsíc před datem zavedení.
MIG_021
Členské státy musí být schopny vydávat všechny ostatní typy karet tachografu verze 2 druhé generace nejpozději 1 měsíc před datem zavedení.
4.
USTANOVENÍ PRO OBDOBÍ PO DATU ZAVEDENÍ
MIG_022
Po datu zavedení musí členské státy vydávat pouze karty tachografu verze 2 druhé generace.
MIG_023
Výrobci celků ve vozidle / snímačů pohybu budou smět vyrábět celky ve vozidle / snímače pohybu první generace, dokud budou používány v praxi, aby mohly být vyměňovány vadné součásti.
MIG_023a
Po datu zavedení se vadná verze 1 druhé generace celků ve vozidle nebo vnějších zařízení GNSS nahradí verzí 2 druhé generace celků ve vozidle nebo vnějších zařízení GNSS.
MIG_024
Výrobci celků ve vozidle / snímačů pohybu budou smět požadovat a obdržet zachování schválení typu celků ve vozidle / snímačů pohybu první generace nebo celků ve vozidle verze 1 druhé generace, které již byly typově schváleny.“
d)
doplňuje se nový bod 5, který zní:
„5.
ZÁZNAM PŘEKROČENÍ HRANIC V PRVNÍ GENERACI A PRVNÍ VERZI DRUHÉ GENERACE TACHOGRAFŮ
MIG_025
Symbol země a případně regionu, do nichž řidič vstupuje po překročení hranice členského státu podle čl. 34 odst. 7 nařízení (EU) č. 165/2014, se zaznamená jako místo, kde začíná denní pracovní doba, v souladu s ručním zadáváním míst stanoveným v požadavku 60 v příloze IC nařízení (EU) č. 165/2014 a v požadavku 50 v příloze IB nařízení (EHS) č. 3821/85.“;
41)
v dodatku 16 se odstavec ADA_012 nahrazuje tímto:
„ADA_012
Vstupní rozhraní adaptéru musí být v příslušných případech schopné násobit nebo dělit frekvenci přicházejících impulsů rychlosti pevně stanoveným faktorem pro přizpůsobení signálu rozsahu faktoru k definovanému v této příloze (2 400 až 25 000 impulsů/km). Tento pevně stanovený faktor může být naprogramován pouze výrobcem adaptéru a schválenou dílnou provádějící montáž adaptéru.“.
(1) Nařízení Evropského parlamentu a Rady (EU) 2018/858 ze dne 30. května 2018 o schvalování motorových vozidel a jejich přípojných vozidel, jakož i systémů, konstrukčních částí a samostatných technických celků určených pro tato vozidla a o dozoru nad trhem s nimi, o změně nařízení (ES) č. 715/2007 a č. 595/2009 a o zrušení směrnice 2007/46/ES (Úř. věst. L 151, 14.6.2018, s. 1).
(*1) Spojení ITS Bluetooth® se přidělí kartě tachografu v otvoru VU pro kartu řidiče.
(*2) Uživatel zvolí kartu, k níž má být přiřazeno připojení ITS Bluetooth® (vloženou do otvoru pro kartu řidiče nebo do otvoru pro kartu druhého řidiče).