EUR-Lex Document 02016R0799-20230821

Tento dokument slouží výhradně k informačním účelům a nemá žádný právní účinek. Orgány a instituce Evropské unie
nenesou za jeho obsah žádnou odpovědnost. Závazná znění příslušných právních předpisů, včetně jejich právních východisek
a odůvodnění, jsou zveřejněna v Úředním věstníku Evropské unie a jsou k dispozici v databázi EUR-Lex. Tato úřední znění
jsou přímo dostupná přes odkazy uvedené v tomto dokumentu
►B 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í
(Text s významem pro EHP)
(Úř. věst. L 139, 26.5.2016, s. 1)
Ve znění:
Úřední věstník
Č. Strana Datum
►M1 Prováděcí nařízení Komise (EU) 2018/502 ze dne 28. února 2018 L 85 1 28.3.2018
►M2 Prováděcí nařízení Komise (EU) 2020/158 ze dne 5. února 2020 L 34 20 6.2.2020
►M3 Prováděcí nařízení Komise (EU) 2021/1228 ze dne 16. července 2021 L 273 1 30.7.2021
►M4 Prováděcí nařízení Komise (EU) 2023/980 ze dne 16. května 2023 L 134 28 22.5.2023
Opraveno:
►C1 Oprava, Úř. věst. L 146, 3.6.2016, s. 31 (2016/799)
►C2 Oprava, Úř. věst. L 27, 1.2.2017, s. 169 (2016/799)
02016R0799 — CS — 21.08.2023 — 003.002 — 1
02016R0799 — CS — 21.08.2023 — 003.002 — 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í
(Text s významem pro EHP)
Článek 1
Předmět a oblast působnosti
1. Toto nařízení obsahuje ustanovení nezbytná pro jednotné uplatňo­
vání následujících aspektů týkajících se tachografů:
a) zaznamenávání polohy vozidla v určitých místech během denní
pracovní doby řidiče;
b) dálkového včasného odhalování případné manipulace s inteligentními
tachografy nebo jejich zneužití;
c) rozhraní s inteligentními dopravními systémy;
d) administrativních a technických požadavků na postupy schválení
typu tachografů, včetně bezpečnostních mechanismů.
▼M1
2. Konstrukce, zkoušení, montáž, kontrola, provoz a opravy inteli­
gentních tachografů a jejich součástí musí splňovat technické požadavky
stanovené v příloze IC tohoto nařízení.
3. Tachografy jiné než inteligentní musí nadále, pokud jde o jejich
konstrukci, zkoušení, montáž, kontrolu, provoz a opravy, splňovat podle
konkrétního případu požadavky stanovené buď v příloze I nařízení (EU)
č. 165/2014, nebo v příloze IB nařízení Rady (EHS) č. 3821/85 ( 1 ).
▼B
4. Podle článku 10d směrnice Evropského parlamentu a Rady
96/53/ES musí zařízení pro včasné dálkové odhalování rovněž předávat
údaje o hmotnosti poskytované interním palubním systémem pro zjiš­
ťování hmotnosti za účelem včasného odhalování podvodů.
▼M1
5. Tímto nařízením není dotčena směrnice Evropského parlamentu
a Rady 2014/53/EU ( 2 ).
▼B
Článek 2
Definice
Pro účely tohoto nařízení se použijí definice stanovené v článku 2
nařízení (EU) č. 165/2014.
▼B
( 1 ) Nařízení Rady (EHS) č. 3821/85 ze dne 20. prosince 1985 o záznamovém
zařízení v silniční dopravě (Úř. věst. L 370, 31.12.1985, s. 8).
( 2 ) Směrnice 2014/53/EU Evropského parlamentu a Rady ze dne 16. dubna 2014
o harmonizaci právních předpisů členských států týkajících se dodávání rádi­
ových zařízení na trh a zrušení směrnice 1999/5/ES (Úř. věst. L 153,
22.5.2014, s. 62).
02016R0799 — CS — 21.08.2023 — 003.002 — 3
Kromě toho se rozumí:
1) „digitálním tachografem“ nebo „tachografem první generace“ digi­
tální tachograf, který není inteligentním tachografem;
2) „vnějším zařízením GNSS“ zařízení, které obsahuje přijímač GNSS
v případě, kdy celek ve vozidle není jediným celkem, jakož i další
součásti nezbytné pro ochranu sdělování údajů o poloze zbytku
celku ve vozidle;
▼M1
3) „dokumentací výrobce“ úplná dokumentace v elektronické nebo
tištěné podobě, která obsahuje všechny informace poskytované
výrobcem nebo jeho zmocněncem orgánu příslušnému pro schva­
lování typu pro účely schválení typu tachografu nebo jeho součásti,
včetně osvědčení uvedených v čl. 12 odst. 3 nařízení (EU)
č. 165/2014, provádění zkoušek definovaných v příloze IC tohoto
nařízení, jakož i výkresy, fotografie a další příslušné doklady;
▼B
4) „schvalovací dokumentací“ dokumentace výrobce v elektronické
nebo tištěné podobě společně s dalšími dokumenty přiloženými
orgánem příslušným pro schvalování typu k dokumentaci výrobce
v průběhu výkonu jeho funkcí, včetně osvědčení ES schválení typu
tachografu nebo jeho konstrukční součásti na konci postupu schva­
lování typu;
5) „seznamem schvalovací dokumentace“ dokument uvádějící očíslo­
vaný obsah schvalovací dokumentace identifikující všechny rele­
vantní části této dokumentace. Formát tohoto dokumentu musí
rozlišovat po sobě jdoucí kroky při postupu ES schvalování typu,
včetně dat všech revizí a aktualizací uvedené dokumentace;
6) „zařízením pro včasné dálkové odhalování“ zařízení celku ve
vozidle, které je používáno k provádění cílených silničních kontrol;
▼M1
7) „inteligentním tachografem“ nebo „tachografem druhé generace“
digitální tachograf, který splňuje požadavky článků 8, 9 a 10 naří­
zení (EU) č. 165/2014, jakož i přílohy IC tohoto nařízení;
8) „součástí tachografu“ kterýkoli z těchto prvků: celek ve vozidle,
snímač pohybu, záznamový list, vnější zařízení GNSS a vnější
zařízení pro včasné dálkové odhalování;
▼B
9) „orgánem příslušným pro schvalování typu“ orgán členského státu
oprávněný k provádění schvalování typu tachografu nebo jeho
součástí, provádění postupu schvalování, vydávání a v příslušných
případech odebírání osvědčení o schválení typu, který působí jako
kontaktní místo pro orgány příslušné pro schvalování typu ostatních
členských států a zajišťuje, aby výrobci plnili své povinnosti týka­
jící se souladu s požadavky tohoto nařízení ;
▼M1
10) „celkem ve vozidle“ tachograf s výjimkou snímače pohybu a kabelů
připojujících snímač pohybu.
Může jím být jediný celek nebo několik celků rozmístěných
ve vozidle, přičemž zahrnuje řídicí jednotku, datovou paměť, funkci
měření času, dvě čtecí zařízení čipových karet pro řidiče a druhého
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 4
řidiče, tiskárnu, zobrazení, konektory a zařízení pro vkládání uživa­
telských údajů, přijímač GNSS a zařízení pro dálkovou
komunikaci.
Celek ve vozidle může sestávat z těchto součástí, které podléhají
schválení typu:
— celku ve vozidle jakožto jediné součásti (včetně přijímače
GNSS a zařízení pro dálkovou komunikaci),
— hlavní jednotky celku ve vozidle (včetně zařízení pro dálkovou
komunikaci) a vnějšího zařízení GNSS,
— hlavní jednotky celku ve vozidle (včetně přijímače GNSS)
a vnějšího zařízení pro dálkovou komunikaci,
— hlavní jednotky celku ve vozidle, vnějšího přijímače GNSS
a vnějšího zařízení pro dálkovou komunikaci.
Pokud celek ve vozidle sestává z několika celků rozmístěných
ve vozidle, je hlavní jednotkou celku ve vozidle celek obsahující
řídicí jednotku, datovou paměť a funkci měření času.
Výraz „celek ve vozidle (VU)“ se používá pro označení „celku ve
vozidle“ nebo „hlavní jednotky celku ve vozidle.“
▼B
Článek 3
Služby vycházející z určení polohy
1. Výrobci zajistí, aby inteligentní tachografy byly kompatibilní se
službami určování polohy, které poskytují systémy Galileo a evropská
služba pro pokrytí geostacionární navigací (EGNOS).
2. Výrobci se mohou také rozhodnout, že kromě systémů uvedených
v odstavci 1 zajistí kompatibilitu s dalšími družicovými navigačními
systémy.
Článek 4
Postup schvalování typu tachografu a součástí tachografu
1. Výrobce nebo jeho zmocněnec předloží žádost o schválení typu
tachografu nebo jakékoli jeho součásti nebo skupiny součástí orgánům
příslušným pro schvalování typu určeným každým členským státem.
Žádost se skládá se z dokumentace výrobce obsahující informace
o všech dotčených součástech, v příslušných případech včetně osvěd­
čení o schválení typu ostatních součástí, jež jsou nezbytné ke zkom­
pletování tachografu, jakož i všech dalších příslušných dokumentů.
2. Členský stát udělí schválení typu všem tachografům, součástem
nebo skupinám součástí, které splňují administrativní a technické poža­
davky uvedené v příslušných případech v čl. 1 odst. 2 nebo 3.
V takovém případě vydá orgán příslušný pro schvalování typu žadateli
osvědčení o schválení typu, které musí být v souladu se vzorem
uvedeným v příloze II tohoto nařízení.
3. Orgán příslušný pro schvalování typu může požádat výrobce nebo
jeho zmocněnce o předložení jakýchkoli dalších informací.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 5
4. Výrobce nebo jeho zmocněnec dá orgánům příslušným pro schva­
lování typu, jakož i subjektům odpovědným za vydávání osvědčení
uvedených v čl. 12 odst. 3 nařízení (EU) č. 165/2014 k dispozici takový
počet tachografů nebo součástí tachografů, který je nezbytný k tomu,
aby mohl být uspokojivé proveden postup schválení typu.
5. Jestliže chce výrobce nebo jeho zmocněnec získat schválení typu
určitých součástí nebo skupin součástí tachografu, musí orgánům
příslušným pro schvalování typu poskytnout ostatní součásti, jejichž
typ byl již schválen, jakož i ostatní součásti nezbytné pro konstrukci
kompletního tachografu, aby tyto orgány mohly provést potřebné
zkoušky.
Článek 5
Změny schválení typu
1. Výrobce nebo jeho zmocněnec neprodleně uvědomí orgány
příslušné pro schvalování typu, které udělily původní schválení typu,
o všech změnách softwarového nebo hardwarového vybavení tachografu
nebo povahy materiálů použitých k jeho výrobě, které jsou zazname­
nány ve schvalovací dokumentaci, a předloží žádost o změnu schválení
typu.
2. Orgány příslušné pro schvalování typu mohou podle povahy
a charakteru těchto změn revidovat či rozšířit stávající schválení typu
nebo vydat nové schválení typu.
„Revize“ se provede, jestliže se orgán příslušný pro schvalování typu
domnívá, že změny softwarového nebo hardwarového vybavení tacho­
grafu nebo povahy materiálů použitých k jeho výrobě jsou malé. V tako­
vých případech orgán příslušný pro schvalování typu vydá revidované
dokumenty schvalovací dokumentace a uvede povahu provedených
změn a datum jejich schválení. Pro splnění tohoto požadavku postačuje
aktualizovaná verze schvalovací dokumentace v konsolidované podobě
spolu s podrobným popisem provedených změn.
„Rozšíření“ se provede, jestliže se orgán příslušný pro schvalování typu
domnívá, že změny softwarového nebo hardwarového vybavení tacho­
grafu nebo povahy materiálů použitých k jeho výrobě jsou významné.
V takových případech může požadovat provedení nových zkoušek a v
souladu s tím informovat výrobce nebo jeho zmocněnce. Pokud jsou
tyto zkoušky uspokojivé, vydá orgán příslušný pro schvalování typu
revidované osvědčení o schválení typu, s číslem odkazujícím na udělené
rozšíření. V osvědčení o schválení typu se uvede důvod rozšíření
a datum jeho vystavení.
3. V seznamu schvalovací dokumentace se uvede datum posledního
rozšíření, nebo revize schválení typu, nebo datum poslední konsolidace
aktualizované verze tohoto schválení typu.
4. Nové schválení typu je nezbytné, pokud by požadované změny
tachografu, jehož typ byl již schválen, nebo jeho součástí vedly k vydání
nového osvědčení o bezpečnosti nebo interoperabilitě.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 6
Článek 6
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 2. března 2016.
▼M1
Příloha IC se však použije ode dne 15. června 2019, s výjimkou
dodatku 16, který se použije ode dne 2. března 2016.
▼B
Toto nařízení je závazné v celém rozsahu a přímo použitelné ve všech
členských státech.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 7
PŘÍLOHA I C
Požadavky na konstrukci, zkoušení, montáž a kontrolu
ÚVOD
1 DEFINICE
2 OBECNÉ VLASTNOSTI A FUNKCE ZÁZNAMOVÉHO ZAŘÍ­
ZENÍ
2.1 Obecné vlastnosti
2.2 Funkce
2.3 Provozní režimy
2.4 Bezpečnost
3 KONSTRUKČNÍ A FUNKČNÍ POŽADAVKY NA ZÁZNA­
MOVÉ ZAŘÍZENÍ
3.1 Monitorování vkládání a vyjímání karet
3.2 Měření rychlosti, polohy a vzdálenosti
3.2.1 Měření ujeté vzdálenosti
3.2.2 Měření rychlosti
3.2.3 Měření polohy
3.3 Měření času
3.4 Monitorování činností řidiče
3.5 Monitorování provozního stavu řidiče
3.6 Řidičem vkládané údaje
3.6.1 Vložení údajů o místě počátku a/nebo ukončení denní pracovní
doby
3.6.2 Ruční vkládání údajů o činnostech řidiče a souhlas řidiče pro
rozhraní ITS
3.6.3 Vkládání údajů o zvláštních podmínkách
▼M3
3.6.4 Záznam operace nakládky/vykládky
▼B
3.7 Správa zámků podniků
3.8 Monitorování kontrolních činností
3.9 Zjišťování událostí a/nebo závad
3.9.1 „Vložení neplatné karty“
3.9.2 „Rozporkaret“
3.9.3 „Překrytí časových údajů“
3.9.4 „Jízda bez náležité karty“
3.9.5 „Vložení karty v průběhu jízdy“
3.9.6 „Nesprávné uzavření poslední relace karty“
3.9.7 „Překročení povolené rychlosti“
3.9.8 „Přerušení elektrického napájení“
3.9.9 „Chyba komunikace se zařízením pro dálkovou komunikaci“
3.9.10 „Chybějící informace o poloze z přijímače GNSS“
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 8
3.9.11 „Chyba komunikace s vnějším zařízením GNSS“
3.9.12 „Chybné údaje o pohybu vozidla“
3.9.13 „Nesoulad údajů o pohybu vozidla“
3.9.14 „Pokus o narušení bezpečnosti systému“
3.9.15 „Nesoulad času“
3.9.16 „Chyba karty“
3.9.17 „Chyba záznamového zařízení“
▼M3
3.9.18 „Anomálie GNSS“
▼B
3.10 Integrované zkoušky a autotesty
3.11 Načítání z datové paměti
3.12 Zaznamenávání a ukládání do datové paměti
3.12.1 Údaje identifikující zařízení
3.12.1.1 Identifikační údaje o celku ve vozidle
3.12.1.2 Identifikační údaje snímače pohybu
3.12.1.3 Identifikační údaje globálních navigačních družicových systémů
3.12.2 Klíče a certifikáty
3.12.3 Data související s vložením a vyjmutím karty řidiče nebo dílny
3.12.4 Údaje o činnostech řidiče
▼M1
3.12.5 Místa a polohy, kde začíná nebo končí denní pracovní doba a/nebo
kde je dosaženo tří hodin součtové doby řízení
▼B
3.12.6 Údaje počitadla ujetých kilometrů
3.12.7 Podrobné údaje o rychlosti
3.12.8 Údaje o událostech
3.12.9 Údaje o závadách
3.12.10 Kalibrační údaje
3.12.11 Údaje o nastavení času
3.12.12 Údaje o kontrolních činnostech
3.12.13 Údaje o zámcích podniků
3.12.14 Údaje o stahování
3.12.15 Údaje o zvláštních podmínkách
3.12.16 Údaje o kartě tachografu
▼M3
3.12.17 Překročení hranic
3.12.18 Operace nakládky/vykládky
3.12.19 Digitální mapa
▼B
3.13 Čtení z karet tachografu
3.14 Zaznamenávání a ukládání údajů na kartách tachografu
3.14.1 Zaznamenávání a ukládání údajů na kartách tachografu první gene­
race
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 9
3.14.2 Zaznamenávání a ukládání údajů na kartách tachografu druhé generace
3.15 Zobrazení
3.15.1 Výchozí zobrazení
3.15.2 Varovné zobrazení
3.15.3 Přístupové menu
3.15.4 Další zobrazení
3.16 Tisk
3.17 Výstražná sdělení
3.18 Stahování údajů do externích médií
3.19 Dálková komunikace pro cílené silniční kontroly
▼M3
3.20 Výměny dat s dalšími externími zařízeními
▼B
3.21 Kalibrace
3.22 Silniční kalibrační kontrola
3.23 Nastavení času
3.24 Provozní charakteristiky
3.25 Materiály
3.26 Značení
▼M3
3.27 Monitorování překročení hranic
3.28 Aktualizace softwaru
▼B
4 KONSTRUKČNÍ A FUNKČNÍ POŽADAVKY NA KARTY
TACHOGRAFU
4.1 Viditelné údaje
4.2 Zabezpečení
4.3 Normy
4.4 Environmentální a elektrické specifikace
4.5 Ukládání údajů
4.5.1 Elementární soubory pro identifikaci a správu karty
4.5.2 Identifikace čipové karty
4.5.2.1 Identifikace čipu
4.5.2.2 DIR (pouze v kartách tachografu druhé generace)
4.5.2.3 Informace ATR (podmínečné, pouze v kartách tachografu druhé
generace)
4.5.2.4 Informace o rozšířené délce (podmínečná, pouze v kartách tacho­
grafu druhé generace)
4.5.3 Karta řidiče
4.5.3.1 Aplikace tachografu (přístupná pro celky ve vozidle první a druhé
generace)
4.5.3.1.1 Identifikace aplikace
4.5.3.1.2 Klíče a certifikáty
4.5.3.1.3 Identifikace karty
4.5.3.1.4 Identifikace držitele karty
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 10
4.5.3.1.5 Stahování z karty
4.5.3.1.6 Informace o řidičském průkazu
4.5.3.1.7 Údaje o událostech
4.5.3.1.8 Údaje o závadách
4.5.3.1.9 Údaje o činnostech řidiče
4.5.3.1.10 Údaje o použitých vozidlech
4.5.3.1.11 Místa, kde začíná a/nebo končí denní pracovní doba
4.5.3.1.12 Údaje o relaci karty
4.5.3.1.13 Údaje o kontrolních činnostech
4.5.3.1.14 Údaje o zvláštních podmínkách
4.5.3.2 Aplikace tachografu druhé generace (nepřístupná pro celek ve
vozidle první generace)
4.5.3.2.1 Identifikace aplikace
▼M3
4.5.3.2.1.1 Doplňující identifikace aplikace (není přístupné verzi 1 celků ve
vozidle druhé generace)
▼B
4.5.3.2.2 Klíče a certifikáty
4.5.3.2.3 Identifikace karty
4.5.3.2.4 Identifikace držitele karty
4.5.3.2.5 Stahování z karty
4.5.3.2.6 Informace o řidičském průkazu
4.5.3.2.7 Údaje o událostech
4.5.3.2.8 Údaje o závadách
4.5.3.2.9 Údaje o činnostech řidiče
4.5.3.2.10 Údaje o použitých vozidlech
4.5.3.2.11 Místa a polohy, kde začíná a/nebo končí denní pracovní doba
4.5.3.2.12 Údaje o relaci karty
4.5.3.2.13 Údaje o kontrolních činnostech
4.5.3.2.14 Údaje o zvláštních podmínkách
4.5.3.2.15 Údaje o použitých celcích ve vozidle
▼M1
4.5.3.2.16 Údaje o místech součtové tříhodinové doby řízení
▼M3
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)
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 11
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)
▼B
4.5.4 Karta dílny
4.5.4.1 Aplikace tachografu (přístupná pro celky ve vozidle první a druhé
generace)
4.5.4.1.1 Identifikace aplikace
4.5.4.1.2 Klíče a certifikáty
4.5.4.1.3 Identifikace karty
4.5.4.1.4 Identifikace držitele karty
4.5.4.1.5 Stahování z karty
4.5.4.1.6 Údaje o kalibraci a nastavování času
4.5.4.1.7 Údaje o událostech a závadách
4.5.4.1.8 Údaje o činnostech řidiče
4.5.4.1.9 Údaje o použitých vozidlech
4.5.4.1.10 Údaje o začátku a/nebo konci denní pracovní doby
4.5.4.1.11 Údaje o relaci karty
4.5.4.1.12 Údaje o kontrolních činnostech
4.5.4.1.13 Údaje o zvláštních podmínkách
4.5.4.2 Aplikace tachografu druhé generace (nepřístupná pro celek ve
vozidle první generace)
4.5.4.2.1 Identifikace aplikace
▼M3
4.5.4.2.1.1 Doplňující identifikace aplikace (není přístupné verzi 1 celků ve
vozidle druhé generace)
▼B
4.5.4.2.2 Klíče a certifikáty
4.5.4.2.3 Identifikace karty
4.5.4.2.4 Identifikace držitele karty
4.5.4.2.5 Stahování z karty
4.5.4.2.6 Údaje o kalibraci a nastavování času
4.5.4.2.7 Údaje o událostech a závadách
4.5.4.2.8 Údaje o činnostech řidiče
4.5.4.2.9 Údaje o použitých vozidlech
4.5.4.2.10 Údaje o začátku a/nebo konci denní pracovní doby
4.5.4.2.11 Údaje o relaci karty
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 12
4.5.4.2.12 Údaje o kontrolních činnostech
4.5.4.2.13 Údaje o použitých celcích ve vozidle
▼M1
4.5.4.2.14 Údaje o místech součtové tříhodinové doby řízení
▼B
4.5.4.2.15 Údaje o zvláštních podmínkách
▼M3
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)
▼B
4.5.5 Kontrolní karta
4.5.5.1 Aplikace tachografu (přístupná pro celky ve vozidle první a druhé
generace)
4.5.5.1.1 Identifikace aplikace
4.5.5.1.2 Klíče a certifikáty
4.5.5.1.3 Identifikace karty
4.5.5.1.4 Identifikace držitele karty
4.5.5.1.5 Údaje o kontrolních činnostech
4.5.5.2 Aplikace tachografu druhé generace (nepřístupná pro celek ve
vozidle první generace)
4.5.5.2.1 Identifikace aplikace
▼M3
4.5.5.2.1.1 Doplňující identifikace aplikace (není přístupné verzi 1 celků ve
vozidle druhé generace)
▼B
4.5.5.2.2 Klíče a certifikáty
4.5.5.2.3 Identifikace karty
4.5.5.2.4 Identifikace držitele karty
4.5.5.2.5 Údaje o kontrolních činnostech
▼M3
4.5.5.2.6 Konfigurace VU (není přístupné verzi 1 celků ve vozidle druhé
generace)
▼B
4.5.6 Karta podniku
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 13
4.5.6.1 Aplikace tachografu (přístupná pro celky ve vozidle první a druhé
generace)
4.5.6.1.1 Identifikace aplikace
4.5.6.1.2 Klíče a certifikáty
4.5.6.1.3 Identifikace karty
4.5.6.1.4 Identifikace držitele karty
4.5.6.1.5 Údaje o činnosti podniku
4.5.6.2 Aplikace tachografu druhé generace (nepřístupná pro celek ve
vozidle první generace)
4.5.6.2.1 Identifikace aplikace
▼M3
4.5.6.2.1.1 Doplňující identifikace aplikace (není přístupné verzi 1 celků ve
vozidle druhé generace)
▼B
4.5.6.2.2 Klíče a certifikáty
4.5.6.2.3 Identifikace karty
4.5.6.2.4 Identifikace držitele karty
4.5.6.2.5 Údaje o činnosti podniku
▼M3
4.5.6.2.6 Konfigurace VU (není přístupné verzi 1 celků ve vozidle druhé
generace)
▼B
5 MONTÁŽ ZÁZNAMOVÉHO ZAŘÍZENÍ
5.1 Montáž
5.2 Montážní štítek
5.3 Plomby
6 KONTROLY, INSPEKCE A OPRAVY
6.1 Schválení montérů, dílen a výrobců vozidel
▼M1
6.2 Kontrola nových nebo opravených součástí
▼B
6.3 Montážní kontrola
6.4 Periodické prohlídky
6.5 Měření odchylek
6.6 Opravy
7 VYDÁVÁNÍ KARET
8 SCHVÁLENÍ TYPU ZÁZNAMOVÉHO ZAŘÍZENÍ A KARET
TACHOGRAFU
8.1 Všeobecně
8.2 Osvědčení o bezpečnosti
8.3 Osvědčení o funkčnosti
8.4 Osvědčení o interoperabilitě
8.5 Osvědčení o schválení typu
8.6 Výjimečný postup: první osvědčení o interoperabilitě pro zázna­
mové zařízení a karty tachografu druhé generace
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 14
Ú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 kalib­
rová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.
▼B
Seznam dodatků
Dodatek 1: DATOVÝ SLOVNÍK
Dodatek 2: SPECIFIKACE KARET TACHOGRAFU
Dodatek 3: PIKTOGRAMY
Dodatek 4: VÝTISKY
Dodatek 5: DISPLEJ
Dodatek 6: PŘEDNÍ KONEKTOR PRO KALIBRACI A STAHOVÁNÍ
Dodatek 7: PROTOKOLY PRO STAHOVÁNÍ DAT
Dodatek 8: KALIBRAČNÍ PROTOKOL
Dodatek 9: SCHVÁLENÍ TYPU A MINIMÁLNÍ ROZSAH POŽADOVA­
NÝCH ZKOUŠEK
Dodatek 10: BEZPEČNOSTNÍ POŽADAVKY
Dodatek 11: SPOLEČNÉ BEZPEČNOSTNÍ MECHANISMY
Dodatek 12: URČOVÁNÍ POLOHY NA ZÁKLADĚ GLOBÁLNÍHO
DRUŽICOVÉHO NAVIGAČNÍHO SYSTÉMU (GNSS)
Dodatek 13: ROZHRANÍ ITS
Dodatek 14: FUNKCE DÁLKOVÉ KOMUNIKACE
Dodatek 15: MIGRACE: POSTUPY PŘI SOUČASNÉ EXISTENCI NĚKO­
LIKA GENERACÍ ZAŘÍZENÍ
Dodatek 16: ADAPTÉR PRO VOZIDLA KATEGORIE M1 A N1
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 15
1 DEFINICE
Pro účely této přílohy se rozumí:
a) „aktivací“:
fáze, ve které se tachograf použitím karty dílny stává plně
funkčním a ve které provádí veškeré funkce, včetně funkcí
bezpečnostních;
b) „prokázáním pravosti“:
funkce určená ke stanovení a ověření uváděné identity;
c) „pravostí“:
vlastnost, že informace přicházejí ze strany, jejíž identitu je
možno ověřit;
d) „integrovanou zkouškou“:
zkouška, která proběhne na vyžádání, spouštěná obsluhou
nebo vnějším zařízením;
e) „kalendářním dnem“:
den v době od 00.00 hod. do 24.00 hod. Veškeré kalendářní
dny se vztahují k času UTC (koordinovaný světový čas);
▼M3
f) „kalibrací inteligentních tachografů“:
aktualizace nebo potvrzení parametrů vozidla, které je třeba
uchovat v datové paměti. Parametry vozidla zahrnují identifi­
kaci 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ázna­
mového zařízení se do datové paměti rovněž uloží typy a iden­
tifiká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;
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 identifi­
kaci 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;
▼B
h) „pořadovým indexem karty“:
čtrnáctý alfanumerický znak v čísle karty, který je užit pro
rozlišení různých karet vydaných určitému podniku, dílně
nebo kontrolnímu orgánu, které mají právo na vydání více
karet tachografu. Podnik, dílna nebo kontrolní orgán jsou
jednoznačně identifikovány prvními třinácti znaky čísla karty;
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 16
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é identifi­
kaci, 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é identifi­
kaci, tj. identifikaci řidiče nebo identifikaci vlastníka spolu
s pořadovým indexem, nahrazována;
▼B
k) „charakteristickým koeficientem vozidla“:
číselné označení, které udává hodnotu výstupního signálu vysí­
laného částí vozidla, která je propojuje se záznamovým zaří­
zením (výstupní hřídel převodovky nebo náprava), když
vozidlo ujede za standardních zkušebních podmínek vzdále­
nost 1 km, jak stanoví požadavek 414. Charakteristický
koeficient se vyjadřuje v počtu impulsů na kilometr (w = …
imp/km);
l) „kartou podniku“:
karta tachografu vydaná orgány členského státu dopravci,
který potřebuje provozovat vozidla vybavená tachografem.
Karta identifikuje dopravce a umožňuje zobrazování, stahování
a tištění údajů uložených v tachografu, která byla tímto
dopravcem uzamčena;
m) „konstantou záznamového zařízení“:
číselné označení udávající hodnotu vstupního signálu, požado­
vaného pro zobrazení a záznam ujeté vzdálenosti jednoho kilo­
metru; tato konstanta se vyjadřuje v počtu impulsů na kilometr
(k = … imp/km);
n) „nepřetržitá doba řízení“ se vypočítává v záznamovém zařízení
jako ( 1 ):
nepřetržitá doba řízení, která se vypočítává jako běžná
součtová doba řízení určitého řidiče od konce jeho poslední
POHOTOVOSTI nebo PŘESTÁVKY/ODPOČINKU nebo
NEZNÁMÉ DOBY ( 2 ) v délce 45 minut nebo doby delší
(tato doba může být rozdělena v souladu s nařízením Evrop­
ského parlamentu a Rady (ES) č. 561/2006 ( 3 )). Příslušné
výpočty berou podle potřeby v úvahu minulé činnosti uložené
na kartě řidiče. Pokud řidič nevložil svou kartu, jsou příslušné
výpočty podloženy údaji z paměťových záznamů, které se
vztahují k běžné době, kdy nebyla vložena žádná karta,
a které se vztahují k odpovídajícímu otvoru pro kartu;
▼M3
( 1 ) Tento způsob výpočtu nepřetržité doby řízení a kumulativní doby přestávek slouží
v záznamovém zařízení pro výpočet varování o nepřetržité době řízení. To však nena­
hrazuje právní výklad, který je třeba použít na tyto doby. Alternativní způsoby výpočtu
nepřetržité doby řízení a souhrnné doby přestávek lze použít k nahrazení těchto definic,
pokud by se staly zastaralými v důsledku aktualizací v jiných příslušných právních
předpisech.
( 2 ) NEZNÁMÁ doba odpovídá intervalu, kdy není do záznamového zařízení vložena karta
řidiče a po které nebyl z řidičovy aktivity vložen ručně žádný údaj.
( 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).
02016R0799 — CS — 21.08.2023 — 003.002 — 17
o) „kontrolní kartou“:
karta tachografu vydaná orgány členského státu příslušnému
národnímu kontrolnímu orgánu, která identifikuje kontrolní
organizaci a případně i kontrolora a umožňuje přístup k údajům
uloženým v datové paměti nebo na kartách řidiče a případně
na kartách dílny pro čtení, tisk a/nebo stahování.
Umožňuje rovněž přístup k funkci silniční kalibrační kontroly
a k údajům na snímači komunikace včasného dálkového odha­
lování;
p) „souhrnnou dobou přestávek“ vypočítávanou v rámci zázna­
mového zařízení jako ( 1 ):
souhrnná doba přestávek v jízdě vypočtená z běžných kumu­
lovaných dob POHOTOVOSTI nebo PŘESTÁVKY/ODPO­
ČINKU nebo NEZNÁMÉ DOBY ( 2 ) daného řidiče, které
jsou dlouhé 15 minut nebo delší, od konce jeho poslední
doby POHOTOVOSTI nebo PŘESTÁVKY/ODPOČINKU
nebo NEZNÁMÉ DOBY ( 2 ), které jsou dlouhé 45 minut
nebo delší (tato doba může být rozdělena v souladu s naří­
zením (ES) č. 561/2006).
Příslušné výpočty berou podle potřeby v úvahu minulé
činnosti uložené na kartě řidiče. Neznámé doby záporné
doby trvání (počátek neznámé doby > konec neznámé doby)
vzniklé překrytím mezi dvěma různými záznamovými zaříze­
ními, se při výpočtu neberou v úvahu.
Pokud řidič nevložil svou kartu, jsou příslušné výpočty podlo­
ženy údaji z paměťových záznamů, které se vztahují k běžné
době, kdy nebyla vložena žádná karta, a které se vztahují
k odpovídajícímu otvoru pro kartu;
q) „datovou pamětí“:
elektronické zařízení na ukládání údajů, které je vestavěné
v záznamovém zařízení;
r) „digitálním podpisem“:
údaje, které jsou připojeny k bloku údajů nebo kryptografická
transformace bloku údajů, které příjemci bloku údajů umožňují
prokázání pravosti a integrity bloku údajů;
s) „stahováním“:
kopírování, spolu s digitálním podpisem, části nebo úplné sady
datových souborů zaznamenaných v datové paměti celku ve
vozidle nebo v paměti karty tachografu, pokud tento postup
nezmění nebo nesmaže žádné uložené údaje.
▼B
( 1 ) Tento způsob výpočtu nepřetržité doby řízení a kumulativní doby přestávek slouží
v záznamovém zařízení pro výpočet varování o nepřetržité době řízení. To však nena­
hrazuje právní výklad, který je třeba použít na tyto doby. Alternativní způsoby výpočtu
nepřetržité doby řízení a souhrnné doby přestávek lze použít k nahrazení těchto definic,
pokud by se staly zastaralými v důsledku aktualizací v jiných příslušných právních
předpisech.
( 2 ) NEZNÁMÁ doba odpovídá intervalu, kdy není do záznamového zařízení vložena karta
řidiče a po které nebyl z řidičovy aktivity vložen ručně žádný údaj.
02016R0799 — CS — 21.08.2023 — 003.002 — 18
Výrobci inteligentních tachografových celků ve vozidle
a výrobci zařízení konstruovaných a určených ke stahování
datových souborů musí podniknout veškeré přiměřené kroky
k zajištění toho, aby stahování takových údajů dopravce nebo
řidiče co nejméně zdržovalo.
Stahování podrobných údajů o rychlosti nemusí být nutné
k prokázání shody s nařízením (ES) č. 561/2006, ale může
být použito pro jiné účely, např. pro vyšetřování nehod.
t) „kartou řidiče“:
karta tachografu vystavená orgány členského státu určitému
řidiči, která identifikuje řidiče a umožňuje ukládání údajů
o jeho činnostech;
u) „účinným obvodem kol“:
průměrná vzdálenost ujetá každým z kol pohánějících vozidlo
(hnací kola) v průběhu jedné ukončené otáčky. Tyto vzdále­
nosti jsou měřeny za normálních zkušebních podmínek, jak
stanoví požadavek 414, a vyjadřují se ve tvaru: „l = …
mm“. Výrobci vozidla mohou měření těchto vzdáleností
nahradit teoretickým výpočtem, který bere v úvahu rozložení
hmotností na nápravy pro nenaložené vozidlo v běžném provo­
zním stavu ( 1 ). Postupy pro tyto teoretické výpočty podléhají
schválení příslušného orgánu členského státu a mohou být
provedeny výhradně před aktivací tachografu;
v) „událostí“:
mimořádná činnost zjištěná inteligentním tachografem, která
může pocházet z pokusu o podvod;
w) „vnějším zařízením GNSS“:
zařízení obsahující přijímač GNSS, není-li celek ve vozidle
samostatnou jednotkou, a další součásti potřebné k ochraně
komunikace údajů o poloze se zbytkem celku ve vozidle;
x) „závadou“:
mimořádná činnost zjištěná inteligentním tachografem, která
může pocházet z chybné funkce nebo z poruchy zařízení;
y) „přijímačem GNSS“:
elektronické zařízení, které přijímá a digitálně zpracovává
signály z jednoho nebo více globálních navigačních družico­
vých systémů (GNSS v angličtině) pro poskytování informací
o poloze, rychlosti a čase;
▼B
( 1 ) Nařízení Komise (EU) č. 1230/2012 ze dne 12. prosince 2012, kterým se provádí
nařízení Evropského parlamentu a Rady (ES) č. 661/2009, pokud jde o požadavky pro
schvalování typu motorových vozidel a jejich přípojných vozidel týkající se jejich hmot­
ností a rozměrů, a mění směrnice Evropského parlamentu a Rady 2007/46/ES (Úř. věst.
L 353, 21.12.2012, s. 31) v platném znění.
02016R0799 — CS — 21.08.2023 — 003.002 — 19
z) „montáží“:
montáž tachografu do vozidla;
aa) „interoperabilitou“:
schopnost systémů a příslušných podnikových procesů vymě­
ňovat si údaje a sdílet informace;
bb) „rozhraním“:
zařízení mezi systémy, které poskytuje prostředí pro jejich
spojení a součinnost;
cc) „polohou“:
zeměpisné souřadnice vozidla v daném čase;
dd) „snímačem pohybu“:
část tachografu, která zajišťuje signál odpovídající rychlosti
vozidla a/nebo vzdálenosti ujeté vozidlem;
▼M3
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 iden­
tifikací, 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 iden­
tifikací, tj. identifikací řidiče nebo identifikací vlastníka
spolu s pořadovým indexem a indexem obnovy, ale
s vyšším indexem náhrady;
▼B
ff) „otevřeným standardem“:
standard stanovený v dokumentu standardních specifikací
dostupném volně nebo za nominální poplatek, který může
být kopírován, rozšiřován nebo používán bezplatně nebo za
nominální poplatek;
gg) „mimo působnost“:
případ, kdy není podle nařízení (ES) č. 561/2006 užívání
záznamového zařízení požadováno;
hh) „překročením rychlosti“:
překročení povolené rychlosti vozidla, které je definováno jako
jakékoliv období delší než 60 s, v němž měřená rychlost
vozidla překračuje mezní hodnotu pro nastavení omezovače
rychlosti, která byla stanovena směrnicí Rady 92/6/EHS ( 1 )
v platném znění;
▼B
( 1 ) Směrnice Rady 92/6/EHS ze dne 10. února 1992 o montáži a použití omezovačů rych­
losti u určitých kategorií motorových vozidel ve Společenství (Úř. věst. L 57, 2.3.1992,
s. 27).
02016R0799 — CS — 21.08.2023 — 003.002 — 20
ii) „pravidelnou kontrolou“:
řada operací ke kontrole, že tachograf správně pracuje, že jeho
seřízení odpovídá parametrům vozidla a že k tachografu nejsou
připojena žádná manipulační zařízení;
jj) „tiskárnou“:
součást záznamového zařízení, které zajišťuje vytištění ulože­
ných údajů;
kk) „komunikací včasného dálkového odhalování“:
komunikace mezi zařízením komunikace včasného dálkového
odhalování a snímačem komunikace včasného dálkového
odhalování během cílených silničních kontrol s cílem dálko­
vého odhalování možné manipulace nebo zneužití záznamo­
vého zařízení;
▼M3
ll) „zařízením pro dálkovou komunikaci“, „modulem dálkové
komunikace“ nebo „zařízením pro včasné dálkové odhalo­
vání“:
vybavení celku ve vozidle, které se užívá k provádění cílených
silničních kontrol;
▼B
mm) „snímačem komunikace včasného dálkového odhalování“:
systém používaný kontrolory pro cílené silniční kontroly;
▼M3
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;
▼B
oo) „opravou“:
oprava snímače pohybu nebo celku ve vozidle nebo kabelu,
která vyžaduje jejich odpojení od napájení nebo odpojení od
jiných součástí tachografu nebo otevření snímače pohybu nebo
celku ve vozidle;
▼M3
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;
▼B
qq) „osvědčením bezpečnosti“:
postup, kterým orgán pro certifikaci všeobecných kritérií
osvědčuje, že zkoumané záznamové zařízení (nebo jeho
součást) nebo karta tachografu splňuje bezpečnostní poža­
davky stanovené v příslušných ochranných profilech;
rr) „autotestem“:
zkouška, která probíhá v záznamovém zařízení cyklicky a auto­
maticky za účelem zjištění závad;
ss) „měřením času“:
nepřetržitý digitální záznam koordinovaného světového data
a času (UTC);
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 21
tt) „nastavením času“:
nastavení aktuálního času; toto nastavení lze provádět auto­
maticky podle času z přijímače GNSS představujícího čas
referenční nebo v režimu kalibrace;
▼B
uu) „rozměrem pneumatiky“:
stanovení rozměrů pneumatik (vnějších hnacích kol) podle
směrnice Rady 92/23/EHS ( 1 ) v platném znění;
vv) „identifikací vozidla“:
čísla, která vozidlo identifikují: registrační značka
vozidla (VRN) s uvedením členského státu registrace a identi­
fikační číslo vozidla (VIN) ( 2 );
ww) „týdnem“ pro účely výpočtu v záznamovém zařízení:
období od 00.00 hodin času UTC v pondělí do 24.00 hodin
času UTC v neděli;
xx) „kartou dílny“:
karta tachografu vydaná orgány členského státu určeným
pracovníkům výrobce tachografu, montážního podniku,
výrobce vozidla nebo dílně schváleným uvedeným členským
státem, která identifikuje držitele karty a umožňuje zkoušení,
kalibraci a aktivaci tachografů a/nebo stahování údajů z nich;
yy) „adaptérem“:
zařízení, které zajišťuje signál trvale odpovídající rychlosti
vozidla a/nebo vzdálenosti ujeté vozidlem, jiné než zařízení
používané pro nezávislé sledování pohybu, a které je:
▼M3
— 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 ( 3 );
▼B
— zabudováno tam, kde není mechanicky možné zabudovat
jiný typ existujícího snímače pohybu, který je jinak
v souladu s ustanoveními této přílohy a dodatků 1 až 15,
▼M3
( 1 ) Směrnice Rady 92/23/EHS ze dne 31. března 1992 o pneumatikách pro motorová
vozidla a jejich přípojná vozidla a o jejich montáži (Úř. věst. L 129, 14.5.1992, s. 95).
( 2 ) Směrnice Rady 76/114/EHS ze dne 18. prosince 1975 o sbližování právních předpisů
členských států týkajících se povinných štítků a nápisů pro motorová vozidla a pro jejich
přípojná vozidla a pro jejich umístění a způsob upevnění (Úř. věst. L 24, 30.1.1976,
s. 1).
( 3 ) Nařízení Evropského parlamentu a Rady (EU) 2018/858 ze dne 30. května 2018 o schva­
lová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).
02016R0799 — CS — 21.08.2023 — 003.002 — 22
— zabudováno mezi celkem ve vozidle a místem, odkud inte­
grované snímače nebo alternativní rozhraní vysílají
impulsy rychlosti/vzdálenosti,
— co se týče celku ve vozidle, je chování adaptéru stejné,
jako by byl k celku ve vozidle připojen snímač pohybu,
který je v souladu s ustanoveními této přílohy a dodatků 1
až 16.
Použití takového adaptéru ve výše popsaných vozidlech
umožní montáž a správné užívání celku ve vozidle vyhovují­
cího všem požadavkům v této příloze.
U těchto vozidel inteligentní tachograf zahrnuje kabely,
adaptér a celek ve vozidle;
zz) „integritou údajů“:
přesnost a konzistentnost uložených údajů, jejichž dokladem je
absence jakékoli změny údajů mezi dvěma aktualizacemi
záznamů. Integrita znamená, že údaje jsou přesnou kopií
původní verze, např. že nebyly porušeny při zápisu na kartu
tachografu nebo vyhrazené zařízení a načítání z nich nebo
během přenosu jakýmkoli komunikačním kanálem;
▼M3
aaa) vyhrazeno pro budoucí použití;
▼B
bbb) „systémem inteligentního tachografu“:
záznamové zařízení, karty tachografu a veškerá zařízení přímo
nebo nepřímo spolupracující během konstrukce, montáže,
používání, zkoušení a kontroly, např. karty, snímač dálkové
komunikace a další zařízení pro stahování údajů, analýzu
údajů, kalibraci, vytváření, správu nebo zavádění bezpečnost­
ních prvků atd.;
▼M3
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;
▼B
ddd) „ochranným profilem“:
dokument používaný jako součást certifikačního postupu
v souladu se všeobecnými kritérii, který obsahuje specifikaci
bezpečnostních požadavků na zabezpečení informací, nezá­
vislou na způsobu provedení;
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 23
eee) „přesností GNSS“:
v souvislosti se zaznamenáváním polohy z globálního navigač­
ního družicového systému (GNSS) pomocí tachografů,
hodnota horizontálního zředění přesnosti (HDOP) vypočítaná
jako minimum z hodnot HDOP zjištěných na dostupných
systémech GNSS ;
▼M1
fff) „součtovou dobou řízení“:
hodnota vyjadřující celkový počet minut jízdy určitého
vozidla.
Hodnota součtové doby řízení je součet minut volného chodu,
který funkce monitorování činností řízení záznamového zaří­
zení považuje za JÍZDU, a používá se pouze ke spuštění
záznamu polohy vozidla pokaždé, když součtová doba řízení
dosáhne násobku tří hodin. Sčítání je zahájeno zapnutím
záznamového zařízení. Tuto hodnotu neovlivňuje žádná jiná
podmínka jako „mimo působnost“ nebo „převoz lodí / převoz
vlakem“.
Hodnota součtové doby řízení není určena k zobrazování, tisku
ani stahování.
▼B
2 OBECNÉ VLASTNOSTI A FUNKCE ZÁZNAMOVÉHO ZAŘÍ­
ZENÍ
2.1 Obecné vlastnosti
Účelem záznamového zařízení je zaznamenávat, ukládat, zobrazovat
a tisknout údaje týkající se činností řidiče a umožnit jejich výstup.
Jakékoliv vozidlo vybavené záznamovým zařízením, které vyhovuje
podmínkám této přílohy, musí mít displej rychloměru a počitadlo
ujetých kilometrů. Tyto funkce mohou být součástí záznamového
zařízení.
01) Záznamové zařízení zahrnuje kabely, snímač pohybu
a celek ve vozidle.
02) Rozhraní mezi snímači pohybu a celky ve vozidle musí
splňovat požadavky specifikované v dodatku 11.
03) Celek ve vozidle musí být připojen k jednomu nebo více
globálním navigačním družicovým systémům podle speci­
fikace v dodatku 12.
04) Celek ve vozidle musí komunikovat se snímači komunikace
včasného dálkového odhalování podle specifikace
v dodatku 14.
▼M3
05) Celek ve vozidle obsahuje rozhraní ITS, které je specifiko­
vá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
02016R0799 — CS — 21.08.2023 — 003.002 — 24
06) Jakékoliv zapojení nebo propojení záznamového zařízení
s jakoukoliv funkcí, zařízením nebo zařízeními, ať již
schválenými nebo neschválenými, nesmí ovlivňovat nebo
být schopno ovlivňovat jeho správný a bezpečný provoz
nebo plnění podmínek tohoto nařízení.
Uživatelé záznamového zařízení se identifikují v zařízení
prostřednictvím karet tachografu.
07) Záznamové zařízení zajišťuje selektivní přístupová práva
k údajům a funkcím v závislosti na typu a/nebo identitě
uživatele.
Záznamové zařízení zaznamenává a ukládá údaje do své datové
paměti, do zařízení pro dálkovou komunikaci a na karty tachografu.
▼M3
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.
▼B
2.2 Funkce
08) Záznamové zařízení musí zajistit tyto funkce:
— monitorování vkládání a vyjímání karet,
— měření rychlosti, vzdálenosti a polohy,
— měření času,
— monitorování činnosti řidiče,
— monitorování provozního stavu řidiče,
▼M3
— ú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
— správa zámků podniků,
— monitorování kontrolních činností,
— zjišťování událostí a/nebo závad,
— integrované zkoušky a autotesty,
— načítání z datové paměti,
— zaznamenávání a ukládání údajů do datové paměti,
— čtení údajů z karet tachografu,
— zaznamenávání a ukládání údajů na karty tachografu,
— zobrazování,
— tisk,
— výstraha,
— stahování údajů do vnějších médií,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 25
— dálková komunikace pro cílené silniční kontroly,
— výstup údajů na přídavná zařízení,
— kalibrace,
— silniční kalibrační kontrola,
— nastavení času ,
▼M3
— monitorování překročení hranic,
— aktualizace softwaru.
▼B
2.3 Provozní režimy
09) Záznamové zařízení musí být schopno pracovat ve čtyřech
režimech:
— v provozním režimu,
— v kontrolním režimu,
— v kalibračním režimu,
— v podnikovém režimu.
10) Záznamové zařízení se přepíná do následujících provozních
režimů podle platné karty tachografu vložené do čtecích
zařízení karet. Pro určení provozního režimu nemá generace
karty tachografu význam, je-li vložená karta platná. Karta
dílny první generace je vždy považována za neplatnou, je-li
vložena do celku ve vozidle druhé generace.
Provozní režim
Otvor pro vložení karty řidiče
Bez karty Karta řidiče Kontrolní karta Karta dílny Karta podniku
O
tv
or
p
ro
v
lo
že
ní
k
ar
ty
d
ru
hé
ho
ř
id
ič
e Bez karty Provozní Provozní Kontrolní Kalibrační Podnikový
Karta řidiče Provozní Provozní Kontrolní Kalibrační Podnikový
Kontrolní karta Kontrolní Kontrolní Kontrolní (*) Provozní Provozní
Karta dílny Kalibrační Kalibrační Provozní Kalibrační (*) Provozní
Karta podniku Podnikový Podnikový Provozní Provozní Podnikový (*)
(*) V těchto situacích používá záznamové zařízení pouze kartu tachografu vloženou do otvoru pro vložení karty řidiče.
11) Záznamové zařízení musí ignorovat vložení neplatné karty,
kromě zobrazování, tisku a stahování údajů uložených na
kartách s prošlým datem, které musí být možné.
12) Všechny funkce uvedené v bodě 2.2 musí být aktivní
v jakémkoli provozním režimu s těmito výjimkami:
— kalibrační funkce je přístupná pouze v kalibračním
režimu,
— funkce silniční kalibrační kontroly je přístupná pouze
v kontrolním režimu,
— funkce správy zámků podniků je přístupná pouze
v podnikovém režimu,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 26
— funkce monitorování kontrolních činností je funkční
pouze v kontrolním režimu,
▼M3
— 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
13) Záznamové zařízení může předat data na displej, do
tiskárny nebo na vnější rozhraní s těmito výjimkami:
— v provozním režimu musí být jakékoliv osobní identi­
fikační údaje (příjmení nebo jméno(a)), které neodpoví­
dají vložené kartě tachografu, ignorovány a jakékoliv
číslo karty neodpovídající vložené kartě tachografu
musí být částečně ignorováno (každý lichý znak –
odleva doprava – musí obsahovat prázdnou hodnotu),
▼M3
— 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),
▼B
— pokud není v záznamovém zařízené vložena žádná
karta, výstup údajů vztahujících se k osobě řidiče lze
provádět pouze pro aktuální den a osm předcházejících
kalendářních dnů,
▼M3
— 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í,
▼M1
— celky ve vozidle mají normální dobu platnosti použí­
vání 15 let od data vstupu osvědčení celku ve vozidle
v platnost, ale celky ve vozidle lze používat další tři
měsíce pouze pro stahování údajů.
▼B
2.4 Bezpečnost
▼M1
Bezpečnost systému má za cíl ochranu datové paměti takovým
způsobem, aby se zabránilo neoprávněnému přístupu a manipulaci
s údaji a aby takové pokusy byly odhaleny, ochranu integrity
a pravosti údajů přenášených mezi snímačem pohybu a celkem ve
vozidle, ochranu integrity a pravosti údajů přenášených mezi zázna­
movým zařízením a kartami tachografu, ochranu integrity a pravosti
údajů přenášených mezi celkem ve vozidle a vnějším zařízením
GNSS, ochranu důvěrnosti, integrity a pravosti údajů přenášených
pomocí komunikace včasného dálkového odhalování pro kontrolní
účely a ověřování integrity a pravosti stahovaných údajů.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 27
14) Aby se dosáhlo bezpečnosti systému, musí následující
součásti splnit bezpečnostní požadavky uvedené v jejich
ochranných profilech, jak stanoví dodatek 10:
— celek ve vozidle,
— karta tachografu,
— snímač pohybu,
▼M3
— vnější zařízení GNSS (tento profil je potřebný a použ­
itelný pouze pro variantu vnějšího zařízení GNSS).
▼B
3 KONSTRUKČNÍ A FUNKČNÍ POŽADAVKY NA ZÁZNAMOVÉ
ZAŘÍZENÍ
3.1 Monitorování vkládání a vyjímání karet
15) Záznamové zařízení monitoruje vkládání karty do čtecích
zařízení karet a její vyjímání.
▼M3
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 tacho­
grafu 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
17) Karty tachografu první generace považuje záznamové zaří­
zení za neplatné, pokud dílna zablokuje možnost použití
karet tachografu první generace v souladu s dodatkem 15
(pož. MIG003).
18) Karty dílny první generace, které jsou vloženy do zázna­
mového zařízení druhé generace, jsou považovány za
neplatné.
19) Záznamové zařízení se navrhuje tak, že karty tachografu
jsou po správném vložení do čtecích zařízení karet zamčeny
v této poloze.
▼M3
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.
▼B
3.2 Měření rychlosti, polohy a vzdálenosti
21) Hlavním zdrojem měření rychlosti a vzdálenosti je snímač
pohybu (případně zabudovaný v adaptéru).
22) Tato funkce musí měřit nepřetržitě a musí být schopna
dodávat stav počitadla ujetých kilometrů odpovídající
celkové vzdálenosti ujeté vozidlem na základě impulsů
vydávaných snímačem pohybu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 28
23) Tato funkce musí měřit nepřetržitě a musí být schopna
udávat rychlost vozidla na základě impulsů vydávaných
snímačem pohybu.
24) Funkce měření rychlosti musí být také schopna dodávat
informace, zda je vozidlo v pohybu, nebo se zastavilo.
Vozidlo je považováno za pohybující se, jakmile funkce
registruje od snímače pohybu více než 1 imp/s po dobu
nejméně pěti sekund. Jinak se vozidlo považuje za stojící.
25) Zařízení zobrazující rychlost (rychloměr) a měřidlo celkové
ujeté vzdálenosti (počítadlo ujetých kilometrů), namonto­
vané v jakémkoli vozidle, které je vybaveno záznamovým
zařízením, vyhovujícím ustanovením tohoto nařízení, musí
vyhovovat požadavkům týkajícím se maximálních tolerancí
(viz body 3.2.1 a 3.2.2), které jsou uvedeny v této příloze.
▼M3
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
3.2.1 Měření ujeté vzdálenosti
28) Ujetá vzdálenost může být měřena buď:
— tak, že se načítá dopředný i zpětný pohyb, nebo
— tak, že je brán v úvahu pouze dopředný pohyb.
29) Záznamové zařízení měří vzdálenost od 0 do 9 999 999,9
km.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 29
30) Měření vzdálenosti musí být v následujících tolerancích
(vzdálenosti nejméně 1 000 m):
— ± 1 % před montáží,
— ± 2 % při montáži a pravidelné kontrole,
— ± 4 % v provozu.
▼M3
Tolerance se nepoužijí k záměrné změně měřené vzdále­
nosti.
▼B
31) Vzdálenost se měří s rozlišením 0,1 km nebo jemnějším.
3.2.2 Měření rychlosti
32) Záznamové zařízení musí měřit v rozsahu 0 až 220 km/h.
▼M3
33) Aby byla zajištěna tolerance zobrazované rychlosti maxi­
má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.
▼B
34) Rychlost se měří přesně s normální tolerancí během 2
sekund po ukončení změny rychlosti, jestliže změna
proběhla při hodnotě 2 m/s 2 .
35) Měření rychlosti se provádí s rozlišením 1 km/h nebo
jemnějším.
3.2.3 Měření polohy
36) Záznamové zařízení měří absolutní polohu vozidla pomocí
přijímače GNSS.
▼M3
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.
▼B
3.3 Měření času
38) Funkce měření času musí měřit nepřetržitě a udávat v digi­
tální podobě údaje o koordinovaném světovém datu a času
UTC.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 30
39) K datování údajů v záznamovém zařízení (záznamy,
výměna údajů) a pro všechny výtisky uvedené v dodatku
4 „Výtisky“ se musí používat datum a čas UTC.
40) Aby bylo možno zobrazit místní čas, musí se dát měnit
posun zobrazovaného času s půlhodinovým krokem.
Nejsou povoleny žádné jiné posuny než v záporných
nebo kladných násobcích půl hodiny.
▼M3
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.
41a) Přesnost času, když je nastavován dílnami v souladu s poža­
davkem 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ža­
davku 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.
▼B
42) Měření času musí mít rozlišovací schopnost vyšší nebo
rovnou 1 sekundě.
43) Měření času nesmí být ovlivněno vypnutím vnějšího elek­
trického napájení na dobu kratší nežli 12 měsíců v podmín­
kách schvalování typu.
3.4 Monitorování činností řidiče
44) Tato funkce musí nepřetržitě a odděleně monitorovat
činnosti jednoho řidiče a jednoho druhého řidiče.
45) Řidičovy činnosti jsou JÍZDA, PRÁCE, POHOTOVOST
a PŘESTÁVKA/ODPOČINEK.
46) Mělo by být umožněno řidiči a/nebo druhému řidiči ručně
navolit režimy PRÁCE, POHOTOVOST a PŘESTÁVKA/
ODPOČINEK.
47) Jestliže se vozidlo pohybuje, musí se nastavit automaticky
JÍZDA pro řidiče a u druhého řidiče se musí automaticky
nastavit POHOTOVOST.
48) Jestliže se vozidlo zastaví, musí se u řidiče automaticky
nastavit režim PRÁCE.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 31
49) První změna činnosti řidiče na režim PŘESTÁVKA/ODPO­
ČINEK nebo POHOTOVOST, která nastane během 120
sekund po automatickém přepnutí do režimu PRÁCE
v důsledku zastavení vozidla, musí být považována za
změnu nastalou v průběhu zastávky vozidla (proto je
možné zrušení změny na režim PRÁCE).
▼B
50) Tato funkce předává informaci o změně činnosti s rozli­
šením jedné minuty.
51) Pokud se u dané kalendářní minuty objeví jakákoliv činnost
v režimu JÍZDA, jak v přímo předcházející, tak v přímo
následující minutě, je celá tato minuta považována za
JÍZDU.
52) Pokud jde o danou kalendářní minutu, která není podle
požadavku 051 považována za JÍZDU, je celá minuta pova­
žována za stejný typ činnosti jako nejdéle nepřetržitě trva­
jící činnost v této minutě (nebo poslední ze stejně dlouho
trvajících činností).
53) Tato funkce musí také nepřetržitě monitorovat nepřetržitou
dobu řízení a načítaný čas doby přestávek řidiče.
3.5 Monitorování provozního stavu řidiče
54) Tato funkce musí nepřetržitě a automaticky monitorovat
provozní stav řidiče.
55) Provozní stav řidiče POSÁDKA se musí navolit, jestliže
jsou v záznamovém zařízení vloženy dvě platné karty
řidiče. V každém jiném případě se navolí stav řízení
vozidla SAMOTNÝ ŘIDIČ.
3.6 Řidičem vkládané údaje
3.6.1 Vložení údajů o místě počátku a/nebo ukončení denní pracovní doby
56) Tato funkce musí umožnit vložení údajů o místě, kde podle
řidiče a/nebo druhého řidiče začíná a/nebo končí denní
pracovní doba.
▼M3
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ázna­
mové 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ře­
pisuje):
— zaznamenání místa zahájení aktuální denní pracovní
doby při ručním zadávání údajů podle požadavku 61,
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 32
— 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.
▼B
60) Pomocí příkazů v nabídkách musí být možno zadávat
místa, kde dochází k zahájení a/nebo ukončení denní
pracovní doby řidiče. Pokud v průběhu jedné kalendářní
minuty dojde k zadání více než jednoho takového údaje,
zůstane zaznamenáno jen poslední místo zahájení práce
a poslední místo ukončení práce provedené v dané době.
▼M3
Záznamové zařízení zobrazí aktuální místo vozidla na
základě informací z GNSS a uložené digitální mapy (ulože­
ný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
3.6.2 Ruční vkládání údajů o činnostech řidiče a souhlas řidiče pro
rozhraní ITS
▼M3
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 stano­
veno v požadavku 133.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 33
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 omeze­
ní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é digi­
tá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ší zazna­
mená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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 34
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řed­
chozí 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.
▼B
3.6.3 Vkládání údajů o zvláštních podmínkách
▼M3
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).
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 35
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živa­
telů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.
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í.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 36
3.7 Správa zámků podniků
63) Tato funkce umožňuje správu zámků použitých podnikem
k omezení přístupu k údajům v podnikovém režimu pouze
na tento podnik.
64) Zámky podniků spočívají ve vložení počátečního data
a času (uzamčení) a koncového data a času (odemknutí)
spojeného s identifikací podniku číslem karty podniku
(při uzamčení).
65) Uzamčení a odemknutí zámků podniků může být prove­
deno pouze v reálném čase.
66) Zámek může odemknout pouze podnik, jehož zámek je
uzamčen (identifikováno prvními 13 znaky v čísle karty
podniku), nebo
67) odemknutí se provede automaticky při uzamčení jiným
podnikem.
68) V případě, že podnik provede uzamčení a předcházející
uzamčení provedl týž podnik, předpokládá se, že předchá­
zející uzamčení nebylo ukončeno a stále pokračuje.
3.8 Monitorování kontrolních činností
69) Tato funkce musí monitorovat činnosti ZOBRAZOVÁNÍ,
TISKU, STAHOVÁNÍ ÚDAJŮ z celku ve vozidle nebo
z karty a SILNIČNÍ KALIBRAČNÍ kontroly, které jsou
prováděny v kontrolním režimu.
70) Tato funkce také monitoruje KONTROLU PŘEKROČENÍ
POVOLENÉ RYCHLOSTI v kontrolním režimu. Činnost
je považována za kontrolu překročení povolené rychlosti
v případě, že v kontrolním režimu dojde k odeslání výtisku
„překročení povolené rychlosti“ do tiskárny nebo zobrazo­
vací jednotky nebo jsou z datové paměti celku ve vozidle
stahovány údaje „události a závady“.
3.9 Zjišťování událostí a/nebo závad
71) Tato funkce identifikuje následující události a/nebo závady:
3.9.1 „Vložení neplatné karty“
72) Tato událost se vyvolá vložením neplatné karty, již nahra­
zené karty řidiče a/nebo karty s prošlým datem.
3.9.2 „Rozpor karet“
73) Tato událost nastane, jestliže se vložením platných karet
dosáhne kombinace označená v tabulce jako X:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 37
Rozpor karet
Otvor pro vložení karty řidiče
Bez karty Karta řidiče Kontrolní karta Karta dílny Karta podniku
O
tv
or
p
ro
v
lo
že
ní
k
ar
ty
d
ru
hé
ho
ř
id
ič
e Bez karty
Karta řidiče X
Kontrolní karta X X X
Karta dílny X X X X
Karta podniku X X X
3.9.3 „Překrytí časových údajů“
74) Tato událost nastane, jestliže datum a čas posledního
vyjmutí karty řidiče, které je přečteno na kartě, je pozdější
nežli aktuální datum/čas záznamového zařízení, do kterého
je karta vložena.
3.9.4 „Jízda bez náležité karty“
75) Tato událost nastane při jakékoliv z kombinací údajů plat­
ných karet tachografu označených v následující tabulce
jako X, když se řidičova činnost mění na režim JÍZDA
nebo nastane změna režimu provozu v době nastaveného
režimu řidičovy činnosti JÍZDA:
Jízda bez příslušné karty,
Otvor pro vložení karty řidiče
Žádná (nebo
neplatná) karta
Karta řidiče Kontrolní karta Karta dílny Karta podniku
O
tv
or
p
ro
v
lo
že
ní
k
ar
ty
d
ru
hé
ho
ř
id
ič
e Žádná (nebo
neplatná) karta
X X X
Karta řidiče X X X X
Kontrolní karta X X X X X
Karta dílny X X X X
Karta podniku X X X X X
3.9.5 „Vložení karty v průběhu jízdy“
76) Tato událost nastane, jestliže je vložena karta tachografu do
libovolného otvoru pro vkládání karet v době řidičovy
činnosti JÍZDA.
3.9.6 „Nesprávné uzavření poslední relace karty“
77) Tato událost nastane, jestliže při vložení karty záznamové
zařízení zjistí, že přes opatření popsaná v bodě 3.1 před­
cházející vložení karty nebylo správným způsobem ukon­
čeno (karta byla vyjmuta dříve, nežli na ni byly uloženy
příslušné údaje). Tato událost nastane pouze při vložení
karty řidiče nebo karty dílny.
3.9.7 „Překročení povolené rychlosti“
78) Tato událost nastane při každém překročení povolené
rychlosti.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 38
3.9.8 „Přerušení elektrického napájení“
79) Tato událost nastane při každém přerušení elektrického
napájení snímače pohybu a/nebo celku ve vozidle delším
nežli 200 milisekund, pokud zařízení není v kalibračním
nebo kontrolním režimu. Prahovou hodnotu přerušení defi­
nuje výrobce. Pokles elektrického napájení v důsledku star­
tování motoru vozidla nesmí vyvolat tuto událost.
3.9.9 „Chyba komunikace se zařízením pro dálkovou komunikaci“
80) Tato událost nastane, není-li zařízení v kalibračním
režimu a nepotvrdí-li zařízení pro dálkovou komunikaci
úspěšné přijetí údajů dálkové komunikace odeslaných
z celku ve vozidle po více než třech pokusech.
3.9.10 „Chybějící informace o poloze z přijímače GNSS“
81) Tato událost nastane, není-li zařízení v kalibračním
režimu a chybějí-li po dobu delší než 3 hodiny z celkové
doby řízení informace o poloze pocházející z přijímače
GNSS (vnitřního nebo vnějšího).
3.9.11 „Chyba komunikace s vnějším zařízením GNSS“
82) Tato událost nastane, není-li zařízení v kalibračním
režimu a je-li po souvislou dobu delší než 20 minut přeru­
šena komunikace mezi vnějším zařízením GNSS a celkem
ve vozidle, je-li vozidlo v pohybu.
3.9.12 „Chybné údaje o pohybu vozidla“
▼M3
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
3.9.13 „Nesoulad údajů o pohybu vozidla“
▼M3
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.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 39
3.9.14 „Pokus o narušení bezpečnosti systému“
85) Tato událost nastane v jakémkoliv jiném případě, který
ohrožuje bezpečnost systému snímače pohybu a/nebo
celku ve vozidle a/nebo vnějšího zařízení GNSS podle
požadavků v dodatku 10, pokud není zařízení v kalibračním
režimu.
▼M1
3.9.15 „Nesoulad času“
▼M3
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.
▼B
3.9.16 „Chyba karty“
87) Tato závada nastane, když je v průběhu provozu zjištěna
vada karty tachografu.
3.9.17 „Chyba záznamového zařízení“
88) Tato závada nastane, pokud zařízení není v kalibračním
režimu, v případě jakékoliv následující závady:
— vnitřní závada celku ve vozidle
— závada tiskárny
— závada zobrazovací jednotky
— závada stahování
— závada snímače
— závada přijímače GNSS nebo vnějšího zařízení GNSS
— závada zařízení pro dálkovou komunikaci
▼M3
— závada rozhraní ITS
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ěřo­
vání navigačních zpráv, jak je uvedeno v dodatku 12.
Nastane-li událost anomálie GNSS, celek ve vozidle nege­
neruje další anomálie GNSS po dobu následujících 10
minut.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 40
3.10 Integrované zkoušky a autotesty
89) ►M1 Záznamové zařízení musí zjistit závady v průběhu
integrovaných zkoušek a autotestů v souladu s touto
tabulkou: ◄
Testovaný subsystém Autotest Integrovaná zkouška
Programové vybavení Integrita
Datová paměť Přístup Přístup, integrita údajů
Čtecí zařízení karet Přístup Přístup
Klávesnice Ruční kontrola
Tiskárna (podle výrobce) Výtisk
Zobrazování Vizuální kontrola
Stahování údajů
(prováděno pouze v průběhu
stahování)
Správná funkce
Snímač Správná funkce Správná funkce
Zařízení pro dálkovou
komunikaci
Správná funkce Správná funkce
Zařízení GNSS Správná funkce Správná funkce
▼M3
Rozhraní ITS Správná funkce
▼B
3.11 Načítání z datové paměti
90) Záznamové zařízení musí být schopno načíst jakékoliv
údaje uložené v jeho datové paměti.
3.12 Zaznamenávání a ukládání do datové paměti
▼M3
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,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 41
— 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 stup­
ní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
91) Údaje uložené do datové paměti nesmějí být ovlivněny
přerušením elektrického napájení z vnějšího zdroje
v rozsahu kratším nežli dvanáct měsíců v podmínkách
schvalování typu. Údaje uložené ve vnějším zařízení pro
dálkovou komunikaci podle dodatku 14 navíc nesmějí být
ovlivněny přerušením elektrického napájení v rozsahu
kratším nežli 28 dnů.
92) Záznamové zařízení musí být schopno zaznamenávat
a implicitně nebo explicitně ukládat do své datové paměti
následující údaje:
3.12.1 Údaje identifikující zařízení
3.12.1.1 I d e n t i f i k a č n í ú d a j e o c e l k u v e v o z i d l e
93) Záznamové zařízení musí být schopno ukládat do své
datové paměti tyto identifikační údaje o celku ve vozidle:
— jméno výrobce,
— adresa výrobce,
— číslo součásti,
— výrobní číslo,
— generace celku ve vozidle,
— schopnost používat karty tachografu první generace,
— číslo verze programového vybavení,
— datum instalace aktuální verze programového vybavení,
— rok výroby zařízení,
— číslo schválení,
▼M3
— identifikátor verze digitální mapy (požadavek 133l).
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 schop­
nosti používat karty tachografu první generace.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 42
3.12.1.2 I d e n t i f i k a č n í ú d a j e s n í m a č e p o h y b u
95) Snímač pohybu musí být schopen uložit do své datové
paměti tyto identifikační údaje:
— jméno výrobce,
— výrobní číslo,
— číslo schválení,
— identifikátor vloženého bezpečnostního komponentu
(např. číslo součásti vnitřního čipu / číslo procesoru),
— identifikátor operačního systému (např. číslo verze
programového vybavení).
96) Identifikační údaje snímače pohybu jsou zaznamenány
a uloženy výrobcem tohoto snímače jednou provždy do
snímače.
▼M3
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):
▼B
Pro každé z těchto párování se uloží tyto údaje:
— identifikační údaje snímače pohybu,
— výrobní číslo,
— číslo schválení,
— párovací údaje snímače pohybu:
— datum párování.
3.12.1.3 I d e n t i f i k a č n í ú d a j e g l o b á l n í c h n a v i g a č n í c h
d r u ž i c o v ý c h s y s t é m ů
98) Vnější zařízení GNSS musí být schopno uložit do své
datové paměti tyto identifikační údaje:
— jméno výrobce,
— výrobní číslo,
— číslo schválení,
— identifikátor vloženého bezpečnostního komponentu
(např. číslo součásti vnitřního čipu / číslo procesoru),
— identifikátor operačního systému (např. číslo verze
programového vybavení).
99) Identifikační údaje jsou zaznamenány a uloženy výrobcem
vnějšího zařízení GNSS jednou provždy do tohoto zařízení.
▼M3
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).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 43
Pro každé z těchto párování se uloží tyto údaje:
— identifikační údaje vnějšího zařízení GNSS:
— výrobní číslo,
— číslo schválení,
— párovací údaje vnějšího zařízení GNSS:
— datum spárování.
3.12.2 Klíče a certifikáty
101) Záznamové zařízení musí být schopno uložit řadu krypto­
grafických klíčů a certifikátů podle specifikace v dodatku
11 části A a části B.
3.12.3 Data související s vložením a vyjmutím karty řidiče nebo dílny
102) Při každém cyklu vložení a vyjmutí karty řidiče nebo karty
dílny musí záznamové zařízení zaznamenat a uložit do své
datové paměti tyto informace:
— jméno(a) a příjmení držitele karty v podobě uložené na
kartě,
— číslo karty, členský stát vydávající kartu a datum plat­
nosti v podobě uložené na kartě,
— generaci karty,
— datum a čas vložení karty,
— stav počitadla ujetých kilometrů při vložení karty,
— otvor pro vkládání karet, do kterého byla tato karta
vložena,
— datum a čas vyjmutí karty,
— stav počitadla ujetých kilometrů při vyjmutí karty,
— následující informace o posledním řidičem použitém
vozidle tak, jak jsou uloženy na kartě:
— registrační značku vozidla a členský stát registrace,
— generaci celku ve vozidle (je-li k dispozici),
— datum a čas vyjmutí karty,
— značku informující, zda držitel karty při vložení karty
vložil ručně údaje o činnosti, nebo ne.
103) Datová paměť musí být schopna uchovat tato data nejméně
po dobu 365 dnů.
104) Jestliže je kapacita datové paměti vyčerpána, musí nové
údaje nahradit nejstarší údaje.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 44
3.12.4 Údaje o činnostech řidiče
105) Záznamové zařízení musí provést záznam a uložení do své
datové paměti, kdykoliv dojde ke změně činnosti u řidiče
a/nebo druhého řidiče a/nebo dojde ke změně provozního
stavu řidiče a/nebo je vsunuta nebo vyjmuta karta řidiče
nebo karta dílny:
— provozní stav řidiče (POSÁDKA, SAMOTNÝ ŘIDIČ),
— otvor pro vložení karty (ŘIDIČ, DRUHÝ ŘIDIČ),
— stav karty v příslušném otvoru pro vkládání karet
(VLOŽENA, NEVLOŽENA),
— činnost (JÍZDA, POHOTOVOST, PRÁCE,
PŘESTÁVKA/ODPOČINEK),
— datum a čas změny.
VLOŽENA znamená, že platná karta řidiče nebo karta
dílny je vložena v otvoru pro vkládání karet. NEVLO­
ŽENA znamená opak, tzn. žádná platná karta řidiče nebo
karta dílny není vložena v otvoru pro vkládání karet (např.
je vložena karta podniku nebo není vložena žádná karta).
Údaje o činnosti vložené ručně řidičem nejsou zaznamená­
vány do datové paměti.
106) Datová paměť musí být schopna uchovat údaje o činnostech
řidiče nejméně po dobu 365 dnů.
107) Jestliže je kapacita datové paměti vyčerpána, musí nové
údaje nahradit nejstarší údaje.
▼M1
3.12.5 Místa a polohy, kde začíná nebo končí denní pracovní doba a/nebo
kde je dosaženo tří hodin součtové doby řízení
108) Záznamové zařízení musí zaznamenávat a ukládat do své
datové paměti:
— místa a polohy, kde řidič a/nebo druhý řidič začíná svou
denní pracovní dobu,
— polohy, kde součtová doba řízení dosáhne násobku tří
hodin,
— místa a polohy, kde řidič a/nebo druhý řidič končí svou
denní pracovní dobu.
▼B
109) Není-li v těchto časech z přijímače GNSS k dispozici
poloha vozidla, záznamové zařízení použije poslední
dostupnou polohu a příslušné datum a čas.
110) Společně s příslušným místem nebo polohou musí zázna­
mové zařízení zaznamenat a uložit do své datové paměti:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 45
— číslo karty řidiče a/nebo druhého řidiče a členský stát,
který kartu vydal,
▼B
— generaci karty,
— datum a čas vložení údajů,
▼M1
— typ vložených údajů (začátek a konec nebo tři hodiny
součtové doby řízení),
▼B
— příslušnou přesnost GNSS, v příslušných případech
datum a čas,
— stav počitadla ujetých kilometrů,
▼M3
— příznak informující, zda byla poloha ověřena.
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.
▼M1
111) Datová paměť musí být schopna uchovat místa a polohy,
ve kterých denní pracovní doba začíná a končí a/nebo ve
kterých je dosaženo tří hodin součtové doby řízení, mini­
málně po dobu 365 dnů.
▼B
112) Jestliže je kapacita datové paměti vyčerpána, musí nové
údaje nahradit nejstarší údaje.
3.12.6 Údaje počitadla ujetých kilometrů
113) Záznamové zařízení musí zaznamenávat do své datové
paměti stav počitadla ujetých kilometrů vozidla a odpovída­
jící datum o půlnoci každého kalendářního dne.
114) Datová paměť musí být schopna ukládat stav počitadla
ujetých kilometrů o půlnoci nejméně po dobu 365 kalen­
dářních dnů.
115) Jestliže je kapacita datové paměti vyčerpána, musí nové
údaje nahradit nejstarší údaje.
3.12.7 Podrobné údaje o rychlosti
▼M1
116) Záznamové zařízení musí zaznamenávat a uchovávat ve své
datové paměti okamžitou rychlost vozidla a odpovídající
datum a čas v každé sekundě po dobu nejméně posledních
24 hodin, kdy bylo vozidlo v pohybu.
▼B
3.12.8 Údaje o událostech
Pro účely tohoto bodu musí být čas zaznamenáván s přesností jedné
sekundy.
117) Záznamové zařízení musí zaznamenávat a uchovávat ve své
datové paměti tyto údaje o každé zjištěné události podle
následujících pravidel ukládání:
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 46
Událost Pravidla ukládání Údaje, které se ukládají pro každou událost
Vložení neplatné karty — deset posledních událostí — datum a čas události
— typ, číslo, vydávající členský stát a gene­
race karty (karet) vytvářející(ch) událost
— počet podobných událostí v tentýž den
Rozpor karet — deset posledních událostí — datum a čas začátku události
— datum a čas konce události
— typ, číslo, vydávající členský stát a gene­
race dvou karet vytvářejících konflikt
Jízda bez příslušné karty, — nejdelší událost 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 gene­
race všech karet vložených na začátku a/
nebo na konci události
— počet podobných událostí v tentýž den
Vložení karty během
řízení
— poslední událost v každém z posledních
deseti dnů výskytu
— datum a čas události
— typ, číslo, vydávající členský stát a gene­
race karty (karet)
— počet podobných událostí v tentýž den
▼M3
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 gene­
race karty (karet)
— poslední data relace přečtená z karty:
— datum a čas vložení karty
▼B
Překročení povolené rych­
losti (1)
— nejzávažnější událost v každém z deseti
posledních dnů výskytu (tj. případ
s nejvyšší průměrnou rychlostí)
— pět nejzávažnějších událostí za posled­
ních 365 dnů
— první událost, která nastala po poslední
kalibraci
— datum a čas začátku události
— datum a čas konce události
— maximální rychlost změřená v průběhu
události
— aritmetický průměr rychlostí změřených
v průběhu události
— typ, číslo, vydávající členský stát a gene­
race karty řidiče (v příslušných přípa­
dech)
— počet podobných událostí v tentýž den
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 47
Událost Pravidla ukládání Údaje, které se ukládají pro každou událost
Přerušení napájení (2) — nejdelší událost 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 gene­
race všech karet vložených na začátku a/
nebo na konci události
— počet podobných událostí v tentýž den
Chyba komunikace se
zařízením pro dálkovou
komunikaci
— nejdelší událost 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 gene­
race všech karet vložených na začátku a/
nebo na konci události
— počet podobných událostí v tentýž den
Chybí informace o poloze
z přijímače GNSS
— nejdelší událost 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 gene­
race všech karet vložených na začátku a/
nebo na konci události
— počet podobných událostí v tentýž den
▼M1
Chyba komunikace
s vnějším zařízením
GNSS
— nejdelší událost 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 gene­
race všech karet vložených na začátku a/
nebo na konci události
— počet podobných událostí v tentýž den
▼B
Chyba údajů o pohybu
vozidla
— nejdelší událost 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 gene­
race všech karet vložených na začátku a/
nebo na konci události
— počet podobných událostí v tentýž den
Nesoulad údajů o pohybu
vozidla
— nejdelší událost 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 gene­
race všech karet vložených na začátku a/
nebo na konci události
— počet podobných událostí v tentýž den
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 48
Událost Pravidla ukládání Údaje, které se ukládají pro každou událost
Pokus o narušení zabez­
pečení
— posledních deset událostí pro každý typ
události
— datum a čas začátku události
— datum a čas konce události (je-li rele­
vantní)
— typ, číslo, vydávající členský stát a gene­
race všech karet vložených na začátku a/
nebo na konci události
— typ události
▼M1
Časový konflikt — nejzávažnější událost v každém
z posledních deseti dnů výskytu (tj.
případy s největším rozdílem mezi
datem a časem záznamového zařízení
a datem a časem GNSS)
— pět nejzávažnějších událostí za posled­
ních 365 dnů
— datum a čas záznamového zařízení
— datum a čas GNSS
— typ, číslo, vydávající členský stát a gene­
race všech karet vložených na začátku a/
nebo na konci události
— počet podobných událostí v tentýž den
▼M3
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 gene­
race všech karet vložených na začátku a/
nebo na konci události
— počet podobných událostí v tentýž den
▼B
(1) Záznamové zařízení musí také zaznamenat a uchovat ve
své datové paměti:
— datum a čas poslední KONTROLY PŘEKROČENÍ
POVOLENÉ RYCHLOSTI,
— datum a čas prvního překročení povolené rychlosti
následujícího po této KONTROLE PŘEKROČENÍ
POVOLENÉ RYCHLOSTI,
— počet událostí, při kterých došlo k překročení povo­
lené rychlosti od poslední KONTROLY PŘEKRO­
ČENÍ POVOLENÉ RYCHLOSTI.
(2) Tyto údaje mohou být zaznamenávány pouze při
opětovném připojení elektrického napájení, časové
údaje mohou být udávány s přesností jedné minuty.
3.12.9 Údaje o závadách
Pro účely tohoto bodu musí být čas zaznamenáván s přesností jedné
sekundy.
118) Záznamové zařízení se musí pokusit zaznamenat a uložit
tato data pro každou zjištěnou závadu do své datové paměti
podle následujících pravidel o ukládání dat:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 49
Závada Pravidla ukládání Údaje, které se ukládají při závadě
Chyba karty — deset posledních závad karty řidiče — datum a čas začátku závady
— datum a čas konce závady
— typ, číslo, vydávající členský stát a gene­
race karty (karet)
Závady záznamového
zařízení
— deset posledních závad pro každý typ
závady
— první závada po poslední kalibraci
— datum a čas začátku závady
— datum a čas konce závady
— typ závady
— typ, číslo, vydávající členský stát a gene­
race všech karet vložených na začátku a/
nebo konci závady
3.12.10 Kalibrační údaje
119) Záznamové zařízení musí zaznamenávat a ukládat do své
datové paměti údaje týkající se:
— známých kalibračních parametrů v okamžiku aktivace,
— jeho první kalibrace po aktivaci,
— jeho první kalibrace v současném vozidle (identifiko­
vaném jeho identifikačním číslem vozidla),
— posledních dvaceti kalibrací (jestliže proběhne několik
kalibrací v průběhu jednoho kalendářního dne, je zazna­
menána pouze první a poslední kalibrace).
120) Následující údaje se zaznamenávají pro každou z těchto
kalibrací:
— důvod kalibrace (aktivace, první instalace, instalace,
pravidelná prohlídka),
— název a adresa dílny,
— číslo karty dílny, členský stát vydávající kartu a datum
ukončení použitelnosti karty,
— identifikace vozidla,
— aktualizované nebo potvrzené parametry: w, k, l,
rozměr pneumatik, nastavení zařízení omezujícího rych­
lost vozidla, počitadlo ujetých kilometrů (stará a nová
hodnota), datum a čas (stará a nová hodnota),
— typy a identifikátory všech použitých plomb ,
▼M3
— 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),
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 50
— 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.
▼B
121) Záznamové zařízení musí navíc zaznamenávat a uchovávat
ve své datové paměti schopnost používat karty tachografu
první generace (dosud aktivované, či nikoli).
122) Snímač pohybu musí zaznamenávat a uchovávat ve své
datové paměti tyto montážní údaje snímače pohybu:
— první spárování s celkem ve vozidle (datum, čas, číslo
schválení celku ve vozidle, výrobní číslo celku ve
vozidle),
— poslední spárování s celkem ve vozidle (datum, čas,
číslo schválení celku ve vozidle, výrobní číslo celku
ve vozidle).
123) Vnější zařízení GNSS musí zaznamenávat a uchovávat ve
své datové paměti tyto montážní údaje vnějšího zařízení
GNSS:
— první spárování s celkem ve vozidle (datum, čas, číslo
schválení celku ve vozidle, výrobní číslo celku ve
vozidle),
— poslední spárování s celkem ve vozidle (datum, čas,
číslo schválení celku ve vozidle, výrobní číslo celku
ve vozidle).
3.12.11 Údaje o nastavení času
124) Záznamové zařízení musí zaznamenávat a uchovávat ve své
datové paměti údaje vztahující se k nastavením času prove­
deným v kalibračním režimu mimo rámec pravidelné kali­
brace (def. f)):
— času posledního nastavení času,
— pěti největším nastavením času.
125) Tyto údaje musí být zaznamenávány pro každé z těchto
nastavení času:
— datum a čas, stará hodnota,
— datu a čas, nová hodnota,
— název a adresa dílny,
— číslo karty dílny, členský stát vydávající kartu, generace
karty a datum ukončení použitelnosti karty.
3.12.12 Údaje o kontrolních činnostech
126) Záznamové zařízení musí zaznamenávat a uchovávat ve své
datové paměti tyto údaje týkající se posledních dvaceti
případů kontrolní činnosti:
— datum a čas kontroly,
— číslo kontrolní karty, členský stát vydávající kartu
a generaci karty,
— druh kontroly (zobrazení a/nebo tisk a/nebo stahování
z celku ve vozidle a/nebo stahování z karty a/nebo
silniční kalibrační kontrola),
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 51
127) V případě stahování údajů jsou také zaznamenávány údaje
o nejstarším a o posledním dni stahování údajů.
3.12.13 Údaje o zámcích podniků
128) Záznamové zařízení musí zaznamenávat a uchovávat ve své
datové paměti tyto údaje týkající se 255 posledních případů
použití zámků podniků:
— datum a čas uzamčení,
— datum a čas odemknutí,
— číslo karty podniku, členský stát, který kartu vydal,
a generaci karty,
— název a adresu podniku.
Údaje, které byly dříve uzamčeny zámkem odstraněným
z paměti v důsledku výše uvedeného limitu, se považují
za neuzamčené.
3.12.14 Údaje o stahování
129) Záznamové zařízení musí zaznamenávat a uchovávat ve své
datové paměti tyto údaje týkající se posledního stahování
dat z datové paměti do vnějšího média v podnikovém nebo
kalibračním režimu:
— datum a čas stahování dat,
— číslo karty podniku nebo karty dílny, členský stát vydá­
vající kartu a generaci karty,
— název podniku nebo dílny.
3.12.15 Údaje o zvláštních podmínkách
130) Záznamové zařízení musí zaznamenávat ve své datové
paměti tyto údaje týkající se zvláštních podmínek:
— datum a čas záznamu,
— druh zvláštní podmínky.
131) Datová paměť musí být schopna uchovat zvláštní podmínky
po dobu nejméně 365 dnů (za předpokladu, že průměrně
jedna podmínka je otevřena a uzavřena během jednoho
dne). Jestliže je kapacita paměti vyčerpána, musí nové
údaje nahradit nejstarší údaje.
3.12.16 Údaje o kartě tachografu
132) Záznamové zařízení musí být schopno uchovávat tyto údaje
týkající se různých karet tachografu, které byly použity
v celku ve vozidle:
— číslo karty tachografu a její výrobní číslo,
— výrobce karty tachografu,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 52
— typ karty tachografu,
— verzi karty tachografu.
133) Záznamové zařízení musí být schopno uchovávat mini­
málně 88 takových záznamů.
▼M3
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,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 53
— 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 digi­
tální mapu novou mapou zpřístupněnou Evropskou komisí.
133s) Aktualizace digitální mapy se provedou za použití mecha­
nismů 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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 54
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éman­
tiky základní mapy.
▼B
3.13 Čtení z karet tachografu
134) Záznamové zařízení musí být schopno, pokud je třeba,
přečíst z karet tachografu první a druhé generace údaje
nezbytné k(e):
— identifikaci typu karty, držitele karty, předcházejícího
použitého vozidla, data a času posledního vyjmutí
karty a v té době navolené činnosti,
— kontrole správného uzavření poslední relace karty,
▼M3
— 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
— vytištění požadovaných dat zaznamenaných na kartě
řidiče,
— stažení dat z karty řidiče na externí média.
Tento požadavek platí pouze pro karty tachografu první
generace, pokud dílna nezablokuje jejich používání.
135) V případě chyby načítání dat se záznamové zařízení maxi­
málně třikrát pokusí vyplnit daný příkaz k načtení dat,
a pak v případě neúspěchu vyznačí chybu karty a její
neplatnost.
▼M3
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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 55
— 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ňu­
jí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 stano­
vena žádná zvláštní pravidla v souvislosti s použitím tako­
vého elementárního souboru. Uvedená pravidla se stanoví
změnou přílohy IC, která musí obsahovat změnu nebo
zrušení tohoto odstavce.
▼B
3.14 Zaznamenávání a ukládání údajů na kartách tachografu
3.14.1 Zaznamenávání a ukládání údajů na kartách tachografu první gene­
race
136) Pokud dílna nezablokovala použití karet tachografu první
generace, musí záznamové zařízení zaznamenávat a ucho­
vávat údaje naprosto stejným způsobem jako záznamové
zařízení první generace.
137) Záznamové zařízení musí v kartě řidiče nebo kartě dílny
nastavit režim „údaje o použití karty“ okamžitě po vložení
karty.
138) Záznamové zařízení musí aktualizovat údaje uložené na
platných kartách řidiče, kartách dílny, kartách podniku
a/nebo kontrolních kartách se všemi nezbytnými údaji vzta­
hujícími se k době, kdy byla karta vložena, a k držiteli
karty. Údaje uložené na kartách jsou specifikovány v kapi­
tole 4.
139) Záznamové zařízení musí aktualizovat údaje o činnostech
řidiče a místech (podle specifikace v bodech 4.5.3.1.9
a 4.5.3.1.11), které jsou uloženy na platných kartách řidiče
a/nebo kartách dílny, s údaji týkajícími se činností řidiče
a míst, které byly vloženy ručně držitelem karty.
▼M3
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í.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 56
141) Údaje uložené na kartách tachografu jsou aktualizovány
takovým způsobem a v takovou dobu, jak je třeba
s ohledem na momentální kapacitu datové paměti a nahra­
zení nejstarších uložených údajů posledními údaji.
142) V případě chybného zápisu se záznamové zařízení maxi­
málně třikrát pokusí vyplnit daný příkaz k zápisu a potom
v případě neúspěchu vyznačí chybu karty a její neplatnost.
▼M3
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
3.14.2 Zaznamenávání a ukládání údajů na kartách tachografu druhé
generace
144) Karty tachografu druhé generace musí obsahovat dvě různé
aplikace karet, z nichž první je přesně stejná jako aplikace
TACHO karet tachografu první generace a druhá je apli­
kace „TACHO_G2“ podle specifikace v kapitole 4
a dodatku 2.
▼M3
Struktura aplikace „TACHO_G2“ závisí na verzi. Karty
verze 2 obsahují další elementární soubory k souborům
karet verze 1.
▼B
145) Záznamové zařízení musí v kartě řidiče nebo kartě dílny
nastavit režim „údaje o použití karty“ okamžitě po vložení
karty.
146) Záznamové zařízení musí aktualizovat údaje uložené na
dvou aplikacích platných karet řidiče, karet dílny, karet
podniku a/nebo kontrolních karet se všemi nezbytnými
údaji vztahujícími se k době, kdy byla karta vložena, a k
držiteli karty. Údaje uložené na těchto kartách jsou speci­
fikovány v kapitole 4.
147) Záznamové zařízení musí aktualizovat údaje o činnostech
řidiče, místech a polohách (podle specifikace v bodech
4.5.3.1.9, 4.5.3.1.11, 4.5.3.2.9 a 4.5.3.2.11), které jsou
uloženy na platných kartách řidiče a/nebo kartách dílny,
s údaji týkajícími se činností řidiče a míst, které byly
ručně vloženy držitelem karty.
▼M3
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 momen­
tá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,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 57
— 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.
▼B
148) Údaje uložené na kartách tachografu jsou aktualizovány
takovým způsobem a v takovou dobu, jak je třeba
s ohledem na momentální kapacitu datové paměti a nahra­
zení nejstarších uložených údajů posledními údaji.
149) V případě chybného zápisu se záznamové zařízení maxi­
málně třikrát pokusí vyplnit daný příkaz k zápisu a potom
v případě neúspěchu vyznačí chybu karty a její neplatnost.
150) Před uvolněním karty řidiče a po uložení všech příslušných
údajů na dvou aplikacích karty nastaví záznamové zařízení
znovu „údaje o použití karty“.
▼M3
150a) Celek ve vozidle musí ignorovat elementární soubor EF
VU_Configuration na všech kartách, pokud nebyla stano­
vena žádná zvláštní pravidla v souvislosti s použitím tako­
vého elementárního souboru. Uvedená pravidla se stanoví
změnou přílohy IC, která musí obsahovat změnu nebo
zrušení tohoto odstavce.
▼B
3.15 Zobrazení
151) Displej musí mít minimálně 20 znaků.
152) Minimální velikost znaků musí být 5 mm na výšku a 3,5
mm na šířku.
153) Zobrazovací jednotka musí podporovat znaky uvedené
v dodatku 1 kapitole 4 „Znakové sady“. Zobrazovací
jednotka může používat zjednodušené znaky (např. znaky
s diakritikou mohou být zobrazeny bez diakritiky nebo
malá písmena mohou být zobrazena jako velká).
154) Zobrazovací jednotka musí vydávat přiměřené, neoslňující
světlo.
155) Údaje záznamového zařízení musí být dobře viditelné.
156) Záznamové zařízení musí být schopno zobrazit:
— implicitní údaje,
— údaje vztahující se k výstražným sdělením,
— údaje vztahující se k přístupovému menu,
— ostatní údaje požadované uživatelem.
Další informace mohou být zobrazeny záznamovým zaří­
zením za předpokladu, že jsou jasně odlišitelné od výše
uvedených informací.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 58
157) Displej záznamového zařízení musí používat piktogramy
nebo kombinace piktogramů uvedené v dodatku 3. Další
piktogramy nebo kombinace piktogramů mohou být na
displeji zobrazeny za předpokladu, že jsou jasně odlišitelné
od dříve uvedených piktogramů nebo kombinací pikto­
gramů.
158) Displej musí být vždy zapnut, pokud je vozidlo v pohybu.
159) Záznamové zařízení může obsahovat ruční nebo auto­
matickou možnost vypnutí displeje, pokud se vozidlo
nepohybuje.
Formát zobrazení je uveden v dodatku 5.
3.15.1 Výchozí zobrazení
160) Pokud není třeba zobrazit žádnou jinou informaci, musí
záznamové zařízení standardně zobrazovat tyto údaje:
— místní čas (jako výsledek referenčního času UTC +
časového posunu nastaveného řidičem),
— provozní režim,
— aktuální činnost řidiče a aktuální činnost druhého řidiče,
— informace vztahující se k řidiči:
— jeho současná nepřetržitá doba řízení a jeho současná
souhrnná doba přestávek, pokud je jeho aktuální
činností JÍZDA,
— aktuální trvání současné činnosti (od doby, kdy byla
navolena) a jeho současná souhrnná doba přestávek,
pokud jeho aktuální činností není JÍZDA.
161) Zobrazení údajů vztahujících se ke každému řidiči musí být
jasné, jednoduché a jednoznačné. V případě, že informace
o řidiči i druhém řidiči nemohou být zobrazeny současně,
musí záznamové zařízení implicitně ukazovat informaci
týkající se řidiče a musí umožnit uživateli zobrazit infor­
maci týkající se druhého řidiče.
162) V případě, že šířka zobrazovací jednotky nedovoluje
zobrazit implicitně provozní režim, musí záznamové zaří­
zení krátce zobrazit nový provozní režim v okamžiku, kdy
se mění.
163) Záznamové zařízení musí při vložení karty krátce zobrazit
jméno držitele karty.
164) Jestliže je otevřena podmínka „MIMO PŮSOBNOST“ nebo
„PŘEVOZ LODÍ/PŘEVOZ VLAKEM“, potom musí
displej ukázat odpovídající piktogram, že příslušná
podmínka je otevřena (je povoleno, aby zároveň nebyla
zobrazena informace o současné činnosti řidiče).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 59
3.15.2 Varovné zobrazení
165) Záznamové zařízení musí zobrazit výstražné sdělení
primárně použitím piktogramů podle dodatku 3, doplněné
v případě potřeby dodatečnými numericky kódovanými
informacemi. Přesné popisy výstražných sdělení mohou
být také zobrazeny v preferovaném jazyce řidiče.
3.15.3 Přístupové menu
166) Záznamové zařízení musí nabídnout nezbytné příkazy
prostřednictvím odpovídající struktury menu.
3.15.4 Další zobrazení
167) Musí být možné na vyžádání selektivně zobrazit:
— datum a čas UTC a posun místního času,
▼M3
— obsah kteréhokoli výtisku uvedeného v požadavku 169
v témže formátu, jaký mají samotné výtisky,
▼B
— nepřetržitou dobu řízení a souhrnnou dobu přestávek
řidiče,
— nepřetržitou dobu řízení a souhrnnou dobu přestávek
druhého řidiče,
▼M3
— součtovou dobu řízení řidiče v předchozím a probíha­
jícím týdnu,
— součtovou dobu řízení druhého řidiče v předchozím
a probíhajícím týdnu,
▼B
volitelně:
— současné trvání činnosti druhého řidiče (od doby, kdy
byla navolena),
▼M3
— 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ě.
▼B
168) Zobrazování obsahu výtisku musí probíhat sekvenčně,
řádek po řádce. Jestliže je šířka displeje menší nežli 24
znaků, musí být uživateli nabídnuta úplná informace
vhodným způsobem (několik řádek, rolování…).
Řádky výtisku věnované ručně napsaným informacím
mohou být ze zobrazení vypuštěny.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 60
3.16 Tisk
169) Záznamové zařízení musí být schopno vytisknout údaje
z vlastní datové paměti a/nebo karet tachografu v podobě
následujících sedmi výtisků:
— denní výtisk činnosti řidiče z karty,
— denní výtisk činnosti řidiče z celku ve vozidle,
— výtisk událostí a závad z karty,
— výtisk událostí a závad z celku ve vozidle,
— výtisk technických údajů,
— výtisk překročení povolené rychlosti.
— historie údajů karty tachografu pro daný celek ve
vozidle (viz kapitola 3.12.16).
Podrobný popis formátu a obsahu těchto výtisků je uveden
v dodatku 4.
Dodatečné údaje mohou být přidány na konci těchto
výtisků.
Ze záznamového zařízení mohou být pořízeny i další
výtisky, pokud jsou jasně odlišitelné od dříve popsaných
sedmi výtisků.
170) „Denní výtisk činnosti řidiče z karty“ a „výtisk událostí
a závad z karty“ musí být k dispozici pouze, pokud je
v záznamovém zařízení vložena karta řidiče nebo karta
dílny. Záznamové zařízení musí aktualizovat uložená data
na příslušné kartě před započetím tisku.
171) Aby se vytiskl záznam „denní výtisk činnosti řidiče z karty“
nebo „výtisk událostí a závad z karty“, musí záznamové
zařízení:
— buď automaticky vybrat kartu řidiče nebo kartu dílny,
pokud je vložena pouze jedna z nich,
— nebo nabídnout příkaz k volbě zdrojové karty nebo
zvolit kartu vloženou v otvoru pro vložení karty řidiče,
pokud jsou v záznamovém zařízení vloženy tyto dvě
karty.
172) Tiskárna musí být schopna vytisknout 24 znaků na řádku.
173) Minimální velikost znaků musí být 2,1 mm na výšku a 1,5
mm na šířku.
174) Tiskárna musí podporovat znaky uvedené v dodatku 1
kapitole 4 „Znakové sady“.
175) Tiskárny musí být navrženy tak, aby se při tisku výtisků
s dostatečnou pravděpodobností vyhnuly jakékoliv nejedno­
značnosti při čtení.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 61
176) Výtisky si musí podržet své rozměry a záznamy za normál­
ních podmínek vlhkosti (10 až 90 %) a teploty.
177) Typově schválený papír používaný v záznamovém zařízení
musí nést příslušnou značku schválení typu a označení
typu(ů) záznamových zařízení, ve kterých jej lze používat.
178) Za normálních podmínek skladování, co se týče intenzity
osvětlení, vlhkosti a teploty, musí výtisky zůstat dobře
čitelné nejméně po dobu dvou let.
179) Výtisky musí splňovat alespoň požadavky na zkoušky defi­
nované v dodatku 9.
180) Na tyto dokumenty by mělo být možné učinit ručně psané
poznámky, např. řidičův podpis.
181) Záznamové zařízení by mělo vyřešit v průběhu tisku
událost „došel papír“ tak, že po opětovném vložení papíru
je tisk restartován od úplného počátku výtisku nebo tisk
pokračuje s jednoznačným odkazem na dříve vytištěnou
část.
3.17 Výstražná sdělení
182) Záznamové zařízení musí upozornit řidiče při zjištění jaké­
koliv události a/nebo závady.
183) Výstražné sdělení při přerušení elektrického napájení může
být odloženo až do opětovného připojení elektrického napá­
jení.
184) Záznamové zařízení musí řidiče upozornit 15 minut před
uplynutím maximální povolené nepřetržité doby řízení a při
jejím překročení.
185) Výstražná sdělení musí být vizuální. Zvukové výstrahy
mohou být také použity jako doplněk vizuálních výstra­
žných sdělení.
186) Vizuální výstrahy musí být jasně rozeznatelné uživatelem,
musí být umístěny v zorném poli řidiče a musí být jasně
čitelné ve dne i v noci.
187) Vizuální výstrahy mohou být zabudovány v záznamovém
zařízení a/nebo umístěny mimo záznamové zařízení.
188) Ve druhém případě musí nést symbol „T“.
189) Výstražná sdělení musí trvat nejméně 30 sekund, pokud
není uživatelem potvrzeno, že je bere na vědomí stiskem
jednoho nebo více speciálních ovládacích prvků záznamo­
vého zařízení. První potvrzení nesmí smazat zobrazení
příčiny výstražného sdělení v souladu s následujícím
odstavcem.
190) Příčina výstrahy musí být zobrazena na záznamovém zaří­
zení a zůstat viditelná, dokud není uživatelem potvrzeno, že
ji bere na vědomí, použitím specifického ovladače nebo
vložením příkazu záznamového zařízení.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 62
191) Další výstražná sdělení mohou být také použita, pokud
nebudou mást řidiče ve vztahu ke sdělením výše popsaným.
3.18 Stahování údajů do externích médií
192) Záznamové zřízení musí být schopno v případě potřeby
stáhnout údaje z datové paměti nebo z karty řidiče na
externí médium pro uložení údajů prostřednictvím kalibrač­
ního nebo stahovacího konektoru. Záznamové zařízení před
počátkem stahování údajů aktualizuje údaje uložené na
příslušné kartě.
▼M3
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
194) Stahování údajů nesmí změnit nebo odstranit žádné uložené
údaje.
195) Elektrické rozhraní spojovacího konektoru pro kalibraci
nebo stahování údajů je popsáno v dodatku 6.
196) Protokoly pro stahování údajů jsou uvedeny v dodatku 7.
▼M3
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.
▼B
3.19 Dálková komunikace pro cílené silniční kontroly
197) Při zapnutém zapalování musí celek ve vozidle ukládat
každých 60 sekund do zařízení pro dálkovou komunikaci
nejnovější údaje potřebné pro účely cílených silničních
kontrol. Tyto údaje musí být šifrovány a podepsány podle
specifikace v dodatcích 11 a 14.
198) Dálkově kontrolované údaje musí být dostupné snímačům
dálkové komunikace prostřednictvím bezdrátové komuni­
kace podle specifikace v dodatku 14.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 63
199) Údaje potřebné pro účely cílených silničních kontrol
zahrnují:
— poslední pokus o narušení zabezpečení,
— nejdelší přerušení dodávky energie,
— poruchu snímače,
— chybu v údajích o pohybu vozidla,
— nesoulad údajů o pohybu vozidla,
— jízdu bez platné karty,
— vložení karty během řízení,
— údaje o úpravě času,
— kalibrační údaje, včetně údajů dvou posledních ulože­
ných kalibračních záznamů,
— registrační značku vozidla,
— rychlost zaznamenanou tachografem,
▼M3
— polohu vozidla,
— údaj, zda řidič může v současné době porušovat dobu
řízení.
3.20 Výměny dat s dalšími externími zařízeními
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řed­
nictví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 specifiko­
vá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ěři­
telné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í“,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 64
— 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í plat­
formy 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ža­
davkem 61 jak pro řidiče, tak pro druhého řidiče.
Rozhraní ITS lze rovněž použít k zadávání dalších infor­
mací 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í.
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.
▼B
3.21 Kalibrace
202) Kalibrační funkce musí umožnit:
— automatické spárování snímače pohybu a celku ve
vozidle,
— v příslušných případech automatickou vazbu vnějšího
zařízení GNSS a celku ve vozidle,
— digitální přizpůsobení konstanty záznamového zařízení
(k) charakteristickému koeficientu vozidla (w),
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 65
— nastavení aktuálního času v době platnosti vložené
karty dílny,
— nastavit současnou hodnotu počitadla ujetých kilometrů,
— aktualizovat identifikační data snímače pohybu uložená
v datové paměti,
— v příslušných případech aktualizaci identifikačních
údajů vnějšího zařízení GNSS uložených v datové
paměti,
— aktualizaci typů a identifikátorů všech použitých plomb,
▼M3
— aktualizaci nebo potvrzení dalších parametrů známých
záznamovému zařízení: identifikaci vozidla, charakteris­
tický 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,
— 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
203) Kalibrační funkce musí navíc umožňovat zablokovat použí­
vání karet tachografu první generace v záznamovém zaří­
zení, jsou-li splněny podmínky uvedené v dodatku 15.
204) Párování snímače pohybu s celkem ve vozidle spočívá
minimálně v:
— aktualizaci montážních údajů snímače pohybu ukláda­
ných do snímače pohybu (podle potřeby),
— kopírování potřebných identifikačních údajů snímače
pohybu ze snímače do datové paměti celku ve vozidle.
▼M3
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.
▼B
206) Kalibrační funkce musí být schopna vložit nezbytné údaje
prostřednictvím kalibračního/stahovacího konektoru
v souladu s kalibračním protokolem definovaným v dodatku
8. Kalibrační funkce musí být schopna vložit nezbytné
údaje i pomocí jiných prostředků.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 66
3.22 Silniční kalibrační kontrola
207) Funkce silniční kalibrační kontroly musí umožnit čtení
výrobního čísla snímače pohybu (případně zabudovaného
v adaptéru) a výrobního čísla vnějšího zařízení GNSS (v
příslušných případech), připojeného k celku ve vozidle
v čase vyslání žádosti.
208) Toto čtení musí být možné minimálně na displeji celku ve
vozidle prostřednictvím příkazů v menu.
209) Funkce silniční kalibrační kontroly musí rovněž umožnit
kontrolu volby režimu I/O kalibračního signálního spojení
I/O podle dodatku 6 pomocí rozhraní vodiče K. Tento
postup je realizován pomocí parametru ECUAdjustment­
Session podle specifikace v dodatku 8, části 7 Řízení
zkušebních impulsů – Řídicí funkční celek vstup/výstup.
▼M3
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ža­
davek 75).
▼B
3.23 Nastavení času
210) Funkce nastavení času musí umožnit automatické nastavení
aktuálního času. V záznamovém zařízení se pro nastavení
času používají dva zdroje času: 1) vnitřní hodiny celku ve
vozidle, 2) přijímač GNSS.
▼M3
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 hodi­
nami 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. Nasta­
vení č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.
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,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 67
— 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.
▼B
3.24 Provozní charakteristiky
213) Celek ve vozidle musí být plně provozuschopný v rozsahu
teplot od – 20 °C do 70 °C, vnější zařízení GNSS v rozsahu
teplot od – 20 °C do 70 °C a snímač pohybu v rozmezí od
– 40 °C do 135 °C. Obsah datové paměti musí být
zachován při teplotách do – 40 °C.
214) Tachograf musí být plně funkční v rozsahu vlhkosti 10 %
až 90 %.
215) Plomby používané v inteligentním tachografu musí
odolávat stejným podmínkám, které platí pro součásti
tachografu, k nimž jsou připojeny.
216) Záznamové zařízení musí být chráněno proti přepětí, přepó­
lování elektrického napájení a zkratu.
217) Snímače pohybu musí buď:
— reagovat na magnetické pole, které ruší detekci pohybu
vozidla; za takových okolností celek ve vozidle zazna­
mená a uloží chybu snímače (požadavek 88); nebo
— mít snímací prvek, který je chráněn proti magnetickým
polím, nebo je vůči jejich působení imunní.
218) Záznamové zařízení a vnější zařízení GNSS musí vyho­
vovat mezinárodnímu předpisu EHK OSN R10 a musí
být chráněno proti elektrostatickým výbojům a přecho­
dovým jevům.
3.25 Materiály
219) Všechny komponenty, ze kterých se záznamové zařízení
skládá, musí být vyrobeny z materiálů s dostatečnou stabi­
litou, mechanickou pevností a stabilními elektrickými
i magnetickými charakteristikami.
220) Při normálním použití musí být všechny vnitřní části zaří­
zení chráněny proti vlhkosti a prachu.
221) Celek ve vozidle a vnější zařízení GNSS musí vyhovovat
stupni ochrany IP 40 a snímač pohybu stupni ochrany IP 64
podle normy IEC 60529:1989, včetně A1:1999 a A2:2013.
222) Zařízení musí vyhovovat odpovídajícím technickým speci­
fikacím vztahujícím se k ergonomii konstrukce.
223) Zařízení musí být chráněno proti náhodnému poškození.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 68
3.26 Značení
224) Pokud záznamové zařízení zobrazuje údaje počitadla
ujetých kilometrů a rychlost, musí se na zobrazovací
jednotce objevit i následující údaje:
— v blízkosti údaje ujeté vzdálenosti jsou uvedeny
jednotky vzdálenosti vyznačené zkratkou „km“,
— v blízkosti údaje zobrazujícího rychlost je jednotka
„km/h“.
Záznamové zařízení může být také přepnuto, aby zobrazo­
valo rychlost v mílích za hodinu, a v tom případě je
jednotka měřené rychlosti vyznačena zkratkou „mph“.
Záznamové zařízení může být také přepnuto, aby zobrazo­
valo vzdálenost v mílích, a v tom případě je jednotka
měřené vzdálenosti vyznačena zkratkou „mi“.
▼M1
225) Na každou samostatnou součást záznamového zařízení musí
být připevněn popisný štítek, na němž jsou uvedeny tyto
údaje:
— název a adresa výrobce,
— katalogové číslo součásti podle výrobce a rok výroby,
— výrobní číslo,
— značka schválení typu.
226) Pokud není k dispozici dostatečný prostor pro zobrazení
všech výše uvedených údajů, musí být na popisném štítku
uvedeny alespoň: název nebo logo výrobce a katalogové
číslo součásti.
▼M3
3.27 Monitorování překročení hranic
226a) 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.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 69
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 prosazo­
vá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áše­
ný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 prove­
dení 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.
▼B
4 KONSTRUKČNÍ A FUNKČNÍ POŽADAVKY NA KARTY
TACHOGRAFU
4.1 Viditelné údaje
Přední strana musí obsahovat:
227) slova „Karta řidiče“ nebo „Kontrolní karta“ nebo „Karta
dílny“ nebo „Karta podniku“ vytištěná velkými písmeny
v úředním jazyce nebo jazycích členského státu vydávají­
cího kartu, podle typu karty;
228) jméno členského státu vydávajícího kartu (volitelné);
229) rozlišovací značku členského státu vydávajícího kartu, která
je tištěna inverzně v modrém obdélníku a je obklopena 12
žlutými hvězdami. Rozlišovací značky jsou tyto:
B
BG
CZ
CY
Belgie
Bulharsko
Česká republika
Kypr
LV
L
LT
M
Lotyšsko
Lucembursko
Litva
Malta
DK Dánsko NL Nizozemsko
D
EST
Německo
Estonsko
A
PL
Rakousko
Polsko
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 70
GR Řecko P
RO
SK
SLO
Portugalsko
Rumunsko
Slovensko
Slovinsko
E Španělsko FIN Finsko
F
HR
H
Francie
Chorvatsko
Maďarsko
S Švédsko
IRL Irsko UK Spojené království
I Itálie
230) zvláštní údaje k vydaným kartám číslované takto:
Karta řidiče Kontrolní karta Karta podniku nebo dílny
1. příjmení řidiče název kontrolního orgánu název podniku nebo dílny
2. jméno(a) řidiče příjmení kontrolora
(v příslušných případech)
příjmení držitele karty
(v příslušných případech)
3. datum narození řidiče jméno(a) kontrolora
(v příslušných případech)
jméno (jména) držitele
karty
(v příslušných případech)
4.a datum počátku platnosti karty
4.b datum konce platnosti karty
4.c orgán, který kartu vydal (může být vytištěno na druhé straně)
4.d číslo odlišné od čísla uvedeného v záhlaví 5, pro administrativní účely (volitelné)
5. a číslo řidičského průkazu
(k datu vydání karty
řidiče)
— —
5. b číslo karty
6. fotografie řidiče fotografie kontrolora (voli­
telné)
fotografie montéra (voli­
telné)
7. podpis držitele (volitelné)
8. obvyklé místo pobytu
nebo poštovní adresa drži­
tele (volitelné).
poštovní adresa kontrolního
orgánu
poštovní adresa podniku
nebo dílny
231) datum musí být uváděno ve formátu „dd/mm/rrrr“ nebo
„dd.mm.rrrr“ (den, měsíc, rok).
Rubová strana musí obsahovat:
232) vysvětlení očíslovaných položek, které se objevily na
přední straně karty;
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 71
233) na základě zvláštní psané dohody s držitelem mohou být
uvedeny další informace, které se nevztahují ke správě
karty, pokud nikterak nemění způsob použití daného
modelu karty tachografu.
234) Karty tachografu musí být vydávány s těmito převládají­
cími barvami pozadí:
— karta řidiče: bílá barva,
— kontrolní karta: modrá barva,
— karta dílny: červená barva,
— karta podniku: žlutá barva.
235) Karty tachografu musí nést minimálně následující ochranné
prvky, chránící karty proti padělání a pozměňování:
— bezpečnostní provedení pozadí ve formě proplétané
textury a duhového tisku,
— v oblasti fotografie se musí překrývat bezpečnostní
provedení pozadí a fotografie,
— nejméně jednu dvoubarevnou mikrotiskovou linku.
► (1) M1
► (2) M3
236) Po konzultaci s Komisí mohou členské státy přidat barvy
nebo označení, jako vnitrostátní symboly a bezpečnostní
prvky, aniž by byla dotčena ostatní opatření této přílohy.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 72
237) Dočasné karty podle článku 26.4 nařízení (EU) č. 165/2014
musí odpovídat ustanovením této přílohy.
4.2 Zabezpečení
Zabezpečení systému se zaměřuje na ochranu integrity a pravosti
údajů přenášených mezi kartou a záznamovým zařízením, ochranu
integrity a pravosti údajů stahovaných z karet, umožňuje zapsání
jistých údajů na kartu pouze záznamovým zařízením, zaměřuje se
na dešifrování některých údajů, vyloučení možnosti falzifikace údajů
uložených na kartách, zabránění neoprávněné manipulaci a zjištění
pokusu o podobné jednání.
238) Aby se dosáhlo systémové bezpečnosti, musí karty tacho­
grafu splňovat bezpečnostní požadavky definované v dodat­
cích 10 a 11.
239) Karty tachografu musí být čitelné dalšími zařízeními, např.
osobními počítači.
4.3 Normy
240) Karty tachografu musí vyhovovat následujícím normám:
— ISO/IEC 7810 Identification cards – Physical characte­
ristics, (Identifikační karty – Fyzikální charakteristiky),
— ISO/IEC 7816 Identification cards – Integrated circuit
cards (Identifikační karty – Karty s integrovanými
obvody s kontakty):
— Část 1: Fyzikální charakteristiky,
— Část 2: Rozměry a umístění kontaktů (ISO/IEC
7816-2:2007),
— Část 3: Elektronické rozhraní a protokoly přenosu
(ISO/IEC 7816-3:2006),
— Část 4: Organizace, bezpečnost a příkazy pro
výměnu (ISO/IEC 7816-4:2013 + opr. 1:2014),
— Část 6: Mezioborové datové prvky pro výměnu
(ISO/IEC 7816-6:2004 + opr. 1:2006),
— Část 8: Příkazy pro bezpečnostní operace (ISO/IEC
7816-8:2004).
— Karty tachografu musí být testovány v souladu s normou
ISO/IEC 10373-3:2010 Identification cards – Test
methods (Identifikační karty – Zkušební metody) –
Část 3: Karty s integrovanými obvody s kontakty
a příslušná čtecí zařízení karet.
4.4 Environmentální a elektrické specifikace
241) Karty tachografu musí být schopny správné funkce za
všech klimatických podmínek běžně se vyskytujících na
území Společenství a nejméně v rozsahu teplot od –
25 °C do + 70 °C s příležitostnými špičkami do + 85 °C;
„příležitostnými“ se myslí doba nepřesahující 4 hodiny a ne
více než sto opakování v průběhu životnosti karty.
242) Karty tachografu musí být schopny správné funkce při
vlhkosti v rozsahu 10 % až 90 %.
243) Karty tachografu musí být schopny správné funkce po dobu
pěti let, pokud jsou používány ve shodě s předepsanými
environmentálními a elektrickými specifikacemi.
244) V průběhu používání musí karty tachografu vyhovovat
požadavkům nařízení EHK R10, vztahujícím se k elektro­
magnetické kompatibilitě, a musí být ochráněny proti elekt­
rostatickým výbojům.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 73
4.5 Ukládání údajů
Pro účely tohoto odstavce
— časové údaje jsou zaznamenávány s rozlišením jedné minuty,
pokud není stanoveno jinak,
— stav počitadla ujetých kilometrů se zaznamenává s rozlišením
jednoho kilometru,
— údaje o rychlosti jsou zaznamenávány s rozlišením 1 km/h,
— polohy (zeměpisné šířky a délky) jsou zaznamenávány ve stup­
ních a minutách s rozlišením 1/10 minuty.
Funkce karty tachografu, příkazy a logické struktury, splnění poža­
davků na ukládání údajů jsou popsány v dodatku 2.
Není-li stanoveno jinak, je ukládání údajů na kartách tachografu
organizováno tak, aby nové údaje nahrazovaly nejstarší uložené
údaje, je-li vyčerpána velikost paměti vyhrazené pro příslušné
záznamy.
245) Tento odstavec stanovuje minimální kapacitu pro ukládání
dat v různých aplikačních souborech. Karty tachografu
musí být schopny informovat záznamové zařízení
o skutečné kapacitě těchto datových souborů.
▼M3
246) Veškeré další údaje mohou být uloženy na kartách tacho­
grafu 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
247) Každý hlavní soubor (MF) každé karty tachografu musí
obsahovat až pět elementárních souborů (EF) pro správu
karty, identifikaci aplikace a čipu a dva vyhrazené
soubory (DF):
— DF Tachograph, který obsahuje aplikaci přístupnou pro
celky ve vozidle první generace, který je rovněž přít­
omen na kartách tachografu první generace,
— DF Tachograph_G2, který obsahuje aplikaci přístupnou
pouze pro celky ve vozidle druhé generace, který je
přítomen pouze na kartách tachografu druhé generace.
▼M3
Poznámka: verze 2 karet druhé generace obsahuje doplňu­
jící elementární soubory v DF Tachograph_G2.
▼B
Úplné informace o struktuře karet tachografu jsou uvedeny
v dodatku 2.
4.5.1 Elementární soubory pro identifikaci a správu karty
4.5.2 Identifikace čipové karty
248) Karty tachografu musí být schopny uchovávat následující
identifikační údaje čipové karty:
— zastavení hodin,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 74
— výrobní číslo karty (včetně výrobních referencí),
— číslo schválení typu karty,
— personifikovanou identifikaci (ID) karty,
— identifikátor integrátoru,
— identifikátor integrovaného obvodu.
4.5.2.1 I d e n t i f i k a c e č i p u
249) Karty tachografu musí být schopny uchovávat následující
identifikační údaje integrovaného obvodu:
— výrobní číslo integrovaného obvodu,
— výrobní reference integrovaného obvodu.
4.5.2.2 D I R ( p o u z e v k a r t á c h t a c h o g r a f u d r u h é g e n e ­
r a c e )
250) Karty tachografu musí být schopny uchovávat datové
objekty s identifikací aplikace specifikované v dodatku 2.
4.5.2.3 I n f o r m a c e A T R ( p o d m í n e č n é , p o u z e v k a r t á c h
t a c h o g r a f u d r u h é g e n e r a c e )
251) Karty tachografu musí být schopny uchovávat následující
datový objekt s s informací o rozšířené délce:
— pokud karta tachografu podporuje pole s rozšířenou
délkou, datový objekt s informací o rozšířené délce
specifikovaný v dodatku 2.
4.5.2.4 I n f o r m a c e o r o z š í ř e n é d é l c e ( p o d m í n e č n á , p o u z e
v k a r t á c h t a c h o g r a f u d r u h é g e n e r a c e )
252) Karty tachografu musí být schopny uchovávat následující
datové objekty s informací o rozšířené délce:
— pokud karta tachografu podporuje pole s rozšířenou
délkou, datové objekty s informací o rozšířené délce
specifikované v dodatku 2.
4.5.3 Karta řidiče
4.5.3.1 A p l i k a c e t a c h o g r a f u ( p ř í s t u p n á p r o c e l k y v e
v o z i d l e p r v n í a d r u h é g e n e r a c e )
4.5.3.1.1 Identifikace aplikace
253) Karta řidiče musí být schopna uchovat následující identifi­
kační údaje aplikace:
— identifikaci aplikace tachografu,
— identifikaci typu karty tachografu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 75
4.5.3.1.2 Klíče a certifikáty
254) Karta řidiče musí být schopna uchovat řadu kryptografic­
kých klíčů a certifikátů podle specifikace v dodatku 11
části A.
4.5.3.1.3 Identifikace karty
255) Karta řidiče musí být schopna uchovat následující identifi­
kační údaje karty:
— číslo karty,
— vydávající členský stát, název vydávajícího orgánu,
datum vydání,
— datum počátku platnosti karty, datum konce platnosti.
4.5.3.1.4 Identifikace držitele karty
256) Karta řidiče musí být schopna uchovat následující identifi­
kační údaje držitele karty:
— příjmení držitele,
— jméno(a) držitele,
— datum narození,
— preferovaný jazyk.
4.5.3.1.5 Stahování z karty
257) Karta řidiče musí být schopna uchovat následující údaje
týkající se stahování z karty:
— datum a čas posledního stahování z karty (pro jiné než
kontrolní účely).
258) Karta řidiče musí být schopna uchovat jeden takový
záznam.
4.5.3.1.6 Informace o řidičském průkazu
259) Karta řidiče musí být schopna uchovat následující údaje
o řidičském průkazu:
— vydávající členský stát, název vydávajícího orgánu,
— číslo řidičského průkazu (ke dni vydání karty).
4.5.3.1.7 Údaje o událostech
Pro účely tohoto pododstavce je čas ukládán s rozlišením jedné
sekundy.
260) Karta řidiče musí být schopna uchovat údaje týkající se
následujících událostí zjištěných záznamovým zařízením
v době, kdy byla karta vložena:
— časové překrytí (v případě, že je tato karta příčinou
události),
— vložení karty v průběhu jízdy, (v případě, že je tato
karta předmětem události),
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 76
— nesprávné uzavření poslední relace karty (v případě, že
je tato karta předmětem události),
— přerušení elektrického napájení,
— chyba údajů o pohybu vozidla
— pokusy o narušení zabezpečení.
261) Karta řidiče musí být schopna uchovat následující údaje
o těchto událostech:
— kód události,
— datum a čas počátku události (nebo vložení karty,
pokud událost v této době probíhala),
— datum a čas ukončení události (nebo vyjmutí karty,
pokud událost v této době probíhala),
— registrační značku vozidla a členský stát registrace, ve
kterém k události došlo.
Poznámka: V případě události časového překrytí:
— datum a čas počátku události musí odpovídat datu
a času vyjmutí karty z předcházejícího vozidla,
— datum a čas ukončení události musí odpovídat datu
a času vložení karty v současně používaném vozidle,
— údaje o vozidle musí odpovídat současně používanému
vozidlu, které vyvolalo událost.
Poznámka: V případě „nesprávného uzavření poslední
relace karty“:
— datum a čas počátku události by měly odpovídat datu
a času vložení karty, u níž došlo k nesprávnému
uzavření poslední relace,
— datum a čas konce události by měl odpovídat datu
a času vložení karty při relaci, v jejímž průběhu došlo
k detekci události (aktuální relace),
— údaje o vozidlu musí odpovídat vozidlu, ve kterém
došlo k nesprávnému uzavření poslední relace.
262) Karta řidiče musí být schopna uchovat údaje vztahující se
k posledním šesti událostem každého typu (tzn. 36
událostem).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 77
4.5.3.1.8 Údaje o závadách
Pro účely tohoto bodu musí být čas zaznamenáván s přesností jedné
sekundy.
263) Karta řidiče musí být schopna uchovat údaje vztahující se
k následujícím závadám zjištěným záznamovým zařízením
době, kdy byla karta vložena:
▼M1
— chyba karty (v případě, že tato karta je předmětem
chyby),
▼B
— chyba záznamového zařízení.
264) Karta řidiče musí být schopna uchovat následující údaje
vztahující se k těmto závadám:
— chybový kód,
— datum a čas počátku závady (nebo vložení karty, pokud
závada v té době probíhala),
— datum a čas ukončení závady (nebo vyjmutí karty,
pokud závada v té době probíhala),
— registrační značka vozidla a členský stát registrace
vozidla, ve kterém závada nastala.
265) Karta řidiče musí být schopna uchovat údaje vztahující se
k posledním dvanácti závadám každého typu (tzn. 24
závadám).
4.5.3.1.9 Údaje o činnostech řidiče
266) Karta řidiče musí být schopna uchovat pro každý kalen­
dářní den, kdy byla karta použita nebo pro který řidič vložil
činnosti ručně, následující údaje:
— datum,
— stav počitadla denní přítomnosti (vzroste o jednotku
každý kalendářní den),
— celkovou vzdálenost ujetou řidičem v průběhu tohoto
dne,
— provozní stav řidiče v 00.00,
— kdykoliv se změní činnost řidiče a/nebo se změnil jeho
provozní stav a/nebo byla vložena nebo vyjmuta jeho
karta:
— provozní stav řidiče (POSÁDKA, SAMOTNÝ
ŘIDIČ),
— otvor pro vložení karty (ŘIDIČ, DRUHÝ ŘIDIČ),
— stav karty (VLOŽENA, NEVLOŽENA),
— činnost (JÍZDA, POHOTOVOST, PRÁCE,
PŘESTÁVKA/ODPOČINEK),
— čas změny.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 78
267) Paměť karty řidiče musí být schopna uchovat údaje
o činnosti řidiče nejméně po dobu 28 dnů (průměrná
činnost řidiče je definována jako 93 změn činnosti za den).
268) Údaje uvedené v požadavcích 261, 264 a 266 musí být
uchovány způsobem umožňujícím vyhledání činností
v chronologickém pořadí i v případě překrývajících se časo­
vých údajů.
4.5.3.1.10 Údaje o použitých vozidlech
269) Karta řidiče musí být schopna uchovat pro každý kalen­
dářní den, kdy byla použita, a pro každý časový úsek,
kdy byla v uvedený den použita v daném vozidle (časový
úsek obsahuje všechny po sobě jdoucí cykly mezi vložením
a vyjmutím karty v tomto vozidle z pohledu této karty),
následující údaje:
— datum a čas prvního použití vozidla (tzn. první vložení
karty v tomto časovém úseku použití vozidla, nebo
00h00, jestliže použití vozidla pokračuje v této době),
— údaj počitadla ujetých kilometrů v této době,
— datum a čas posledního použití vozidla (tzn. poslední
vyjmutí karty v tomto časovém úseku použití vozidla,
nebo 23h59, jestliže použití vozidla pokračuje v této
době),
— údaj počitadla ujetých kilometrů v této době,
— registrační značku vozidla a členský stát registrace.
270) Karta řidiče musí být schopna uchovat 84 takových
záznamů.
4.5.3.1.11 Místa, kde začíná a/nebo končí denní pracovní doba
271) Karta řidiče musí být schopna uchovat následující údaje
vložené řidičem a vztahující se k místům, kde začíná
a/nebo končí denní pracovní doba:
— datum a čas vložení údajů (nebo datum a čas vztahující
se k vložení údajů, pokud jsou zadávány řidičem
ručně),
— typ vložených údajů (začátek nebo konec, podmínky
vložení údajů),
— zadanou zemi a region,
— stav počitadla ujetých kilometrů.
272) Paměť karty řidiče musí být schopna uchovat nejméně 42
párů takových záznamů.
4.5.3.1.12 Údaje o relaci karty
273) Karta řidiče musí být schopna uchovat údaje vztahující se
k vozidlu, které otevřelo aktuální relaci:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 79
— datum a čas otevření relace (tzn. vložení karty) s rozli­
šovací schopností jedné vteřiny,
— registrační značku vozidla a členský stát registrace.
4.5.3.1.13 Údaje o kontrolních činnostech
274) Karta řidiče musí být schopna uchovat následující údaje
vztahující se ke kontrolním činnostem:
— datum a čas kontroly,
— číslo kontrolní karty a členský stát vydávající kartu,
— typ kontrolní činnosti (zobrazení a/nebo vytištění a/nebo
stahování z celku ve vozidle a/nebo stahování z karty
(viz poznámka)),
— dobu stahování dat, pokud k němu došlo,
— registrační značku vozidla a členský stát registrace
vozidla, u kterého kontrolní činnost proběhla.
Poznámka: Stahování z karty je zaznamenáno pouze
v případě, že proběhne přes záznamové zařízení.
275) Karta řidiče musí být schopna uchovat jeden takový
záznam.
4.5.3.1.14 Údaje o zvláštních podmínkách
276) Karta řidiče musí být schopna uchovat následující údaje
vztahující se ke zvláštním podmínkám, které byly zadány
v době, kdy byla karta vložena (v jakémkoliv otvoru pro
vkládání karet):
— datum a čas záznamu,
— druh zvláštní podmínky.
277) Karta řidiče musí být schopna uchovat 56 takových
záznamů.
▼M3
4.5.3.2 A p l i k a c e t a c h o g r a f u 2 . g e n e r a c e ( n e p ř í s t u p n á
p r o c e l k y v e v o z i d l e p r v n í g e n e r a c e , p ř í s t u p n á
p r o v e r z i 1 a v e r z i 2 c e l k u v e v o z i d l e d r u h é
g e n e r a c e )
▼B
4.5.3.2.1 Identifikace aplikace
278) Karta řidiče musí být schopna uchovat následující identifi­
kační údaje aplikace:
— identifikaci aplikace tachografu,
— identifikaci typu karty tachografu.
▼M3
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í identifi­
kační údaje aplikace, které se vztahují pouze na verzi 2.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 80
4.5.3.2.2 Klíče a certifikáty
279) Karta řidiče musí být schopna uchovat řadu kryptografic­
kých klíčů a certifikátů podle specifikace v dodatku 11
části B.
4.5.3.2.3 Identifikace karty
280) Karta řidiče musí být schopna uchovat následující identifi­
kační údaje karty:
— číslo karty,
— vydávající členský stát, název vydávajícího orgánu,
datum vydání,
— datum počátku platnosti karty, datum konce platnosti.
4.5.3.2.4 Identifikace držitele karty
281) Karta řidiče musí být schopna uchovat následující identifi­
kační údaje držitele karty:
— příjmení držitele,
— jméno(a) držitele,
— datum narození,
— preferovaný jazyk.
4.5.3.2.5 Stahování z karty
282) Karta řidiče musí být schopna uchovat následující údaje
týkající se stahování z karty:
— datum a čas posledního stahování z karty (pro jiné než
kontrolní účely).
283) Karta řidiče musí být schopna uchovat jeden takový
záznam.
4.5.3.2.6 Informace o řidičském průkazu
284) Karta řidiče musí být schopna uchovat následující údaje
o řidičském průkazu:
— vydávající členský stát, název vydávajícího orgánu,
— číslo řidičského průkazu (ke dni vydání karty).
4.5.3.2.7 Údaje o událostech
Pro účely tohoto pododstavce je čas ukládán s rozlišením jedné
sekundy.
285) Karta řidiče musí být schopna uchovat údaje týkající se
následujících událostí zjištěných záznamovým zařízením
v době, kdy byla karta vložena:
— časové překrytí (v případě, že je tato karta příčinou
události),
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 81
— vložení karty v průběhu jízdy, (v případě, že je tato
karta předmětem události),
— nesprávné uzavření poslední relace karty (v případě, že
je tato karta předmětem události),
— přerušení elektrického napájení,
— chyba komunikace se zařízením pro dálkovou
komunikaci,
— chybějící informace o poloze z přijímače GNSS,
— komunikační chyba s vnějším zařízením GNSS,
— chyba údajů o pohybu vozidla,
— nesoulad údajů o pohybu vozidla,
— pokusy o narušení zabezpečení,
— časový konflikt.
286) Karta řidiče musí být schopna uchovat následující údaje
o těchto událostech:
— kód události,
— datum a čas počátku události (nebo vložení karty,
pokud událost v té době probíhala),
— datum a čas ukončení události (nebo vyjmutí karty,
pokud událost v té době probíhala),
— registrační značka vozidla a členský stát registrace, ve
kterém k události došlo.
Poznámka: V případě události časového překrytí:
— datum a čas počátku události musí odpovídat datu
a času vyjmutí karty z předcházejícího vozidla,
— datum a čas ukončení události musí odpovídat datu
a času vložení karty v současně používaném vozidle,
— údaje o vozidle musí odpovídat současně používanému
vozidlu, které vyvolalo událost.
Poznámka: V případě „nesprávného uzavření poslední
relace karty“:
— datum a čas počátku události by měly odpovídat datu
a času vložení karty, u níž došlo k nesprávnému
uzavření poslední relace,
— datum a čas konce události by měly odpovídat datu
a času vložení karty při relaci, v jejímž průběhu došlo
k detekci události (aktuální relace),
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 82
— údaje o vozidlu musí odpovídat vozidlu, ve kterém
došlo k nesprávnému uzavření poslední relace.
▼M3
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).
▼B
4.5.3.2.8 Údaje o závadách
Pro účely tohoto bodu musí být čas zaznamenáván s přesností jedné
sekundy.
288) Karta řidiče musí být schopna uchovat údaje vztahující se
k následujícím závadám zjištěným záznamovým zařízením
době, kdy byla karta vložena:
▼M1
— chyba karty (v případě, že tato karta je předmětem
chyby),
▼B
— chyba záznamového zařízení.
289) Karta řidiče musí být schopna uchovat následující údaje
vztahující se k těmto závadám:
— chybový kód,
— datum a čas počátku závady (nebo vložení karty, pokud
závada v té době probíhala),
— datum a čas ukončení závady (nebo vyjmutí karty,
pokud závada v té době probíhala),
— registrační značka vozidla a členský stát registrace
vozidla, ve kterém závada nastala.
▼M3
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).
▼B
4.5.3.2.9 Údaje o činnostech řidiče
291) Karta řidiče musí být schopna uchovat pro každý kalen­
dářní den, kdy byla karta použita nebo pro který řidič vložil
činnosti ručně, následující údaje:
— datum,
— stav počitadla denní přítomnosti (vzroste o jednotku
každý kalendářní den),
— celkovou vzdálenost ujetou řidičem v průběhu tohoto
dne,
— provozní stav řidiče v 00.00,
— kdykoliv se změní činnost řidiče a/nebo se změnil jeho
provozní stav a/nebo byla vložena nebo vyjmuta jeho
karta:
— provozní stav řidiče (POSÁDKA, SAMOTNÝ
ŘIDIČ),
— otvor pro vložení karty (ŘIDIČ, DRUHÝ ŘIDIČ),
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 83
— stav karty (VLOŽENA, NEVLOŽENA),
— činnost (JÍZDA, POHOTOVOST, PRÁCE,
PŘESTÁVKA/ODPOČINEK),
— čas změny.
▼M3
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).
▼B
293) Údaje uvedené v požadavcích 286, 289 a 291 musí být
uchovány způsobem umožňujícím vyhledání v chronolo­
gickém pořadí i v případě překrývajících se časových
údajů.
4.5.3.2.10 Údaje o použitých vozidlech
294) Karta řidiče musí být schopna uchovat pro každý kalen­
dářní den, kdy byla použita, a pro každý časový úsek,
kdy byla v uvedený den použita v daném vozidle (časový
úsek obsahuje všechny po sobě jdoucí cykly mezi vložením
a vyjmutím karty v tomto vozidle z pohledu této karty),
následující údaje:
— datum a čas prvního použití vozidla (tzn. první vložení
karty v tomto časovém úseku použití vozidla, nebo
00h00, jestliže použití vozidla pokračuje v této době),
— údaj počitadla ujetých kilometrů v této době prvního
použití,
— datum a čas posledního použití vozidla (tzn. poslední
vyjmutí karty v tomto časovém úseku použití vozidla,
nebo 23h59, jestliže použití vozidla pokračuje v této
době),
— údaj počitadla ujetých kilometrů v této době posledního
použití,
— registrační značku vozidla a členský stát registrace.
— číslo VIN.
▼M3
295) Karta řidiče musí být schopna uchovat 200 takových
záznamů.
▼B
4.5.3.2.11 Místa a polohy, kde začíná a/nebo končí denní pracovní doba
296) Karta řidiče musí být schopna uchovat následující údaje
vložené řidičem a vztahující se k místům, kde začíná
a/nebo končí denní pracovní doba:
— datum a čas vložení údajů (nebo datum a čas vztahující
se k vložení údajů, pokud jsou zadávány řidičem
ručně),
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 84
— typ vložených údajů (začátek nebo konec, podmínky
vložení údajů),
— zadanou zemi a region,
— stav počitadla ujetých kilometrů,
— polohu vozidla,
— přesnost GNSS, datum a čas, kdy byla poloha zjištěna.
▼M3
297) Paměť karty řidiče musí být schopna uchovat 112 takových
záznamů.
▼B
4.5.3.2.12 Údaje o relaci karty
298) Karta řidiče musí být schopna uchovat údaje vztahující se
k vozidlu, které otevřelo aktuální relaci:
— datum a čas otevření relace (tzn. vložení karty) s rozli­
šovací schopností jedné vteřiny,
— registrační značku vozidla a členský stát registrace.
4.5.3.2.13 Údaje o kontrolních činnostech
299) Karta řidiče musí být schopna uchovat následující údaje
vztahující se ke kontrolním činnostem:
— datum a čas kontroly,
— číslo kontrolní karty a členský stát vydávající kartu,
— typ kontrolní činnosti (zobrazení a/nebo vytištění a/nebo
stahování z celku ve vozidle a/nebo stahování z karty
(viz poznámka)),
— dobu stahování dat, pokud k němu došlo,
— registrační značku vozidla a členský stát registrace
vozidla, u kterého kontrolní činnost proběhla.
Poznámka: Bezpečnostní požadavky předpokládají, že
stahování z karty je zaznamenáno pouze v případě, že
proběhne přes záznamové zařízení.
300) Karta řidiče musí být schopna uchovat jeden takový
záznam.
4.5.3.2.14 Údaje o zvláštních podmínkách
301) Karta řidiče musí být schopna uchovat následující údaje
vztahující se ke zvláštním podmínkám, které byly zadány
v době, kdy byla karta vložena (v jakémkoliv otvoru pro
vkládání karet):
— datum a čas záznamu,
— druh zvláštní podmínky.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 85
302) Karta řidiče musí být schopna uchovat 112 takových
záznamů.
▼B
4.5.3.2.15 Údaje o použitých celcích ve vozidle
303) Karta řidiče musí být schopna uchovat následující údaje
vztahující se k různým celkům ve vozidle, ve kterých
byla karta použita:
— datum a čas zahájení doby používání celku ve vozidle
(tj. první vložení karty do celku ve vozidle pro
příslušnou dobu),
— výrobce celku ve vozidle,
— typ celku ve vozidle,
— číslo verze softwaru celku ve vozidle.
▼M3
304) Karta řidiče musí být schopna uchovat 200 takových
záznamů.
▼M1
4.5.3.2.16 Údaje o místech součtové tříhodinové doby řízení
305) Karta řidiče musí být schopna uchovat následující údaje
vztahující se k poloze vozidla, kde součtová doba řízení
dosáhne násobku tří hodin:
— datum a čas, kdy součtová doba řízení dosáhne násobku
tří hodin,
— polohu vozidla,
— přesnost GNSS, datum a čas, kdy byla poloha zjištěna,
— stav počitadla ujetých kilometrů.
▼M3
306) Karta řidiče musí být schopna uchovat 336 takových
záznamů.
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 Tacho­
graph_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ů.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 86
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 Tacho­
graph_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 tako­
vý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,
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 87
— 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í tacho­
grafu držitele karty je 3072 bajtů.
▼B
4.5.4 Karta dílny
4.5.4.1 A p l i k a c e t a c h o g r a f u ( p ř í s t u p n á p r o c e l k y v e
v o z i d l e p r v n í a d r u h é g e n e r a c e )
4.5.4.1.1 Identifikace aplikace
307) Karta dílny musí být schopna uchovat následující identifi­
kační údaje aplikace:
— identifikaci aplikace tachografu,
— identifikaci typu karty tachografu.
4.5.4.1.2 Klíče a certifikáty
308) Karta dílny musí být schopna uchovat řadu kryptografic­
kých klíčů a certifikátů podle specifikace v dodatku 11
části A.
309) Karta dílny musí být schopna uchovat osobní identifikační
číslo (kód PIN).
4.5.4.1.3 Identifikace karty
310) Karta dílny musí být schopna uchovat následující identifi­
kační údaje karty:
— číslo karty,
— vydávající členský stát, název vydávajícího orgánu,
datum vydání,
— datum počátku platnosti karty, datum konce platnosti.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 88
4.5.4.1.4 Identifikace držitele karty
311) Karta dílny musí být schopna uchovat následující identifi­
kační údaje držitele karty:
— název dílny,
— adresu dílny,
— příjmení držitele,
— jméno(a) držitele,
— preferovaný jazyk.
4.5.4.1.5 Stahování z karty
312) Karta dílny musí být schopna uchovat údaje o stahování
z karty stejným způsobem jako karta řidiče.
4.5.4.1.6 Údaje o kalibraci a nastavování času
313) Karta dílny musí být schopna uchovat záznamy o kalibra­
cích a/nebo nastavování času provedených v době, kdy byla
karta vložena v záznamovém zařízení.
314) Každý kalibrační záznam musí být schopen uchovat násle­
dující údaje:
— důvod kalibrace (aktivace, první instalace, instalace,
pravidelná prohlídka),
— identifikaci vozidel
— aktualizované nebo potvrzené parametry (w, k, l,
rozměr pneumatik, nastavení zařízení omezujícího rych­
lost vozidla, údaje počitadla ujetých kilometrů (nová
a stará hodnota), datum a čas (nová a stará hodnota)),
— identifikaci záznamového zařízení (katalogové číslo
celku ve vozidle, výrobní číslo celku ve vozidle,
výrobní číslo snímače rychlosti).
315) Karta dílny musí být schopna uchovat nejméně 88 takových
záznamů.
316) Karta dílny musí mít počitadlo celkového počtu kalibrací
provedených s kartou.
317) Karta dílny musí mít počitadlo počtu kalibrací provedených
od posledního stahování dat.
4.5.4.1.7 Údaje o událostech a závadách
318) Karta dílny musí být schopna uchovat údaje o událostech
a závadách stejným způsobem jako karta řidiče.
319) Karta dílny musí být schopna uchovat údaje o třech posled­
ních událostech každého typu (tzn. 18 událostí) a šest
posledních záznamů o závadách každého typu (tzn. 12
závad).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 89
4.5.4.1.8 Údaje o činnostech řidiče
320) Karta dílny musí být schopna uchovat údaje o činnostech
řidiče stejným způsobem jako karta řidiče.
321) Karta dílny musí být schopna uchovat údaje o činnostech
řidiče pro nejméně jeden den průměrné činnosti řidiče.
4.5.4.1.9 Údaje o použitých vozidlech
322) Karta dílny musí být schopna uchovat údaje o použitých
vozidlech stejným způsobem jako karta řidiče.
323) Karta dílny musí být schopna uchovat nejméně čtyři takové
záznamy.
4.5.4.1.10 Údaje o začátku a/nebo konci denní pracovní doby
324) 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.
325) Karta dílny musí být schopna uchovat nejméně tři páry
takových záznamů.
4.5.4.1.11 Údaje o relaci karty
326) Karta dílny musí být schopna uchovat údaje o relaci karty
stejným způsobem jako karta řidiče.
4.5.4.1.12 Údaje o kontrolních činnostech
327) Karta dílny musí být schopna uchovat údaje o kontrolní
činnosti stejným způsobem jako karta řidiče.
4.5.4.1.13 Údaje o zvláštních podmínkách
328) Karta dílny musí být schopna uchovat údaje o zvláštních
podmínkách stejným způsobem jako karta řidiče.
329) Karta dílny musí být schopna uchovat nejméně dva takové
záznamy.
▼M3
4.5.4.2 A p l i k a c e t a c h o g r a f u 2 . g e n e r a c e ( n e p ř í s t u p n á
p r o c e l k y v e v o z i d l e p r v n í g e n e r a c e , p ř í s t u p n á
p r o v e r z i 1 a v e r z i 2 c e l k u v e v o z i d l e d r u h é
g e n e r a c e )
▼B
4.5.4.2.1 Identifikace aplikace
330) Karta dílny musí být schopna uchovat následující identifi­
kační údaje aplikace:
— identifikaci aplikace tachografu,
— identifikaci typu karty tachografu.
▼M3
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í identifi­
kační údaje aplikace, které se vztahují pouze na verzi 2.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 90
4.5.4.2.2 Klíče a certifikáty
331) Karta dílny musí být schopna uchovat řadu kryptografic­
kých klíčů a certifikátů podle specifikace v dodatku 11
části B.
332) Karta dílny musí být schopna uchovat osobní identifikační
číslo (kód PIN).
4.5.4.2.3 Identifikace karty
333) Karta dílny musí být schopna uchovat následující identifi­
kační údaje karty:
— číslo karty,
— vydávající členský stát, název vydávajícího orgánu,
datum vydání,
— datum počátku platnosti karty, datum konce platnosti.
4.5.4.2.4 Identifikace držitele karty
334) Karta dílny musí být schopna uchovat následující identifi­
kační údaje držitele karty:
— název dílny,
— adresu dílny,
— příjmení držitele,
— jméno(a) držitele,
— preferovaný jazyk.
4.5.4.2.5 Stahování z karty
335) Karta dílny musí být schopna uchovat údaje o stahování
z karty stejným způsobem jako karta řidiče.
4.5.4.2.6 Údaje o kalibraci a nastavování času
336) Karta dílny musí být schopna uchovat záznamy o kalibra­
cích a/nebo nastavování času provedených v době, kdy byla
karta vložena v záznamovém zařízení.
337) Každý kalibrační záznam musí být schopen uchovat násle­
dující údaje:
— důvod kalibrace (aktivace, první instalace, instalace,
pravidelná prohlídka),
— identifikaci vozidla,
— aktualizované nebo potvrzené parametry (w, k, l,
rozměr pneumatik, nastavení zařízení omezujícího rych­
lost vozidla, údaje počitadla ujetých kilometrů (nová
a stará hodnota), datum a čas (nová a stará hodnota),
— identifikaci záznamového zařízení (katalogové číslo
celku ve vozidle, výrobní číslo celku ve vozidle,
výrobní číslo snímače rychlosti, výrobní číslo zařízení
dálkové komunikace a v příslušných případech výrobní
číslo vnějšího zařízení GNSS),
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 91
— typ plomby a identifikátor všech použitých plomb,
— schopnost celku ve vozidle používat karty tachografu
první generace (aktivována nebo nikoli).
▼M3
338) Karta dílny musí být schopna uchovat 255 takových
záznamů.
▼B
339) Karta dílny musí mít počitadlo celkového počtu kalibrací
provedených s kartou.
340) Karta dílny musí mít počitadlo počtu kalibrací provedených
od posledního stahování dat.
4.5.4.2.7 Údaje o událostech a závadách
341) Karta dílny musí být schopna uchovat údaje o událostech
a závadách stejným způsobem jako karta řidiče.
342) Karta dílny musí být schopna uchovat údaje o třech posled­
ních událostech každého typu (tzn. 33 událostí) a šest
posledních záznamů o závadách každého typu (tzn. 12
závad).
4.5.4.2.8 Údaje o činnostech řidiče
343) Karta dílny musí být schopna uchovat údaje o činnostech
řidiče stejným způsobem jako karta řidiče.
▼M3
344) Karta dílny musí být schopna uchovat údaje o činnosti
řidiče po dobu jednoho dne obsahující 240 změn činnosti.
▼B
4.5.4.2.9 Údaje o použitých vozidlech
345) Karta dílny musí být schopna uchovat údaje o použitých
vozidlech stejným způsobem jako karta řidiče.
▼M3
346) Karta dílny musí být schopna uchovat 8 takových záznamů.
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ů.
▼B
4.5.4.2.11 Údaje o relaci karty
349) Karta dílny musí být schopna uchovat údaje o relaci karty
stejným způsobem jako karta řidiče.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 92
4.5.4.2.12 Údaje o kontrolních činnostech
350) Karta dílny musí být schopna uchovat údaje o kontrolní
činnosti stejným způsobem jako karta řidiče.
4.5.4.2.13 Údaje o použitých celcích ve vozidle
351) Karta dílny musí být schopna uchovat následující údaje
vztahující se k různým celkům ve vozidle, ve kterých
byla karta použita:
— datum a čas zahájení doby používání celku ve vozidle
(tj. první vložení karty do celku ve vozidle pro
příslušnou dobu),
— výrobce celku ve vozidle,
— typ celku ve vozidle,
— číslo verze softwaru celku ve vozidle.
▼M3
352) Karta dílny musí být schopna uchovat 8 takových záznamů.
▼M1
4.5.4.2.14 Údaje o místech součtové tříhodinové doby řízení
353) Karta dílny musí být schopna uchovat následující údaje
vztahující se k poloze vozidla, kde součtová doba řízení
dosáhne násobku tří hodin:
— datum a čas, kdy součtová doba řízení dosáhne násobku
tří hodin,
— polohu vozidla,
— přesnost GNSS, datum a čas, kdy byla poloha zjištěna,
— stav počitadla ujetých kilometrů.
▼M3
354) Karta dílny musí být schopna uchovat 24 takových
záznamů.
▼B
4.5.4.2.15 Údaje o zvláštních podmínkách
355) Karta dílny musí být schopna uchovat údaje o zvláštních
podmínkách stejným způsobem jako karta řidiče.
▼M3
356) Karta dílny musí být schopna uchovat 4 takové záznamy.
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.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 93
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 Cali­
bration 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ů.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 94
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í tacho­
grafu držitele karty je 3072 bajtů.
▼B
4.5.5 Kontrolní karta
4.5.5.1 A p l i k a c e t a c h o g r a f u ( p ř í s t u p n á p r o c e l k y v e
v o z i d l e p r v n í a d r u h é g e n e r a c e )
4.5.5.1.1 Identifikace aplikace
357) Kontrolní karta musí být schopna uchovat následující iden­
tifikační údaje aplikace:
— identifikaci aplikace tachografu,
— identifikaci typu karty tachografu.
4.5.5.1.2 Klíče a certifikáty
358) Karta dílny musí být schopna uchovat řadu kryptografic­
kých klíčů a certifikátů podle specifikace v dodatku 11
části A.
4.5.5.1.3 Identifikace karty
359) Kontrolní karta musí být schopna uchovat následující iden­
tifikační údaje karty:
— číslo karty,
— vydávající členský stát, název vydávajícího orgánu,
datum vydání,
— datum počátku platnosti karty, datum konce platnosti
(pokud přichází v úvahu).
4.5.5.1.4 Identifikace držitele karty
360) Kontrolní karta musí být schopna uchovat následující iden­
tifikační údaje držitele karty:
— název kontrolního orgánu,
— adresu kontrolního orgánu,
— příjmení držitele,
— jméno(a) držitele,
— preferovaný jazyk.
4.5.5.1.5 Údaje o kontrolních činnostech
361) Kontrolní karta musí být schopna uchovat následující údaje
o kontrolní činnosti:
— datum a čas kontroly,
▼M3
— typ kontroly (zobrazení a/nebo vytištění a/nebo staho­
vání dat celku ve vozidle a/nebo stahování dat karty),
▼B
— dobu stahování dat (pokud proběhlo),
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 95
— registrační značku vozidla a registrační orgán členského
státu kontrolovaného vozidla,
— číslo karty a členský stát vydávající kontrolovanou
kartu řidiče.
362) Kontrolní karta musí být schopna uchovat nejméně 230
takových záznamů.
4.5.5.2 A p l i k a c e t a c h o g r a f u d r u h é g e n e r a c e ( n e p ř í ­
s t u p n á p r o c e l e k v e v o z i d l e p r v n í g e n e r a c e )
4.5.5.2.1 Identifikace aplikace
363) Kontrolní karta musí být schopna uchovat následující iden­
tifikační údaje aplikace:
— identifikaci aplikace tachografu,
— identifikaci typu karty tachografu.
▼M3
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í iden­
tifikační údaje aplikace použitelné pouze pro verzi 2.
▼B
4.5.5.2.2 Klíče a certifikáty
364) Kontrolní karta musí být schopna uchovat řadu kryptogra­
fických klíčů a certifikátů podle specifikace v dodatku 11
části B.
4.5.5.2.3 Identifikace karty
365) Kontrolní karta musí být schopna uchovat následující iden­
tifikační údaje karty:
— číslo karty,
— vydávající členský stát, název vydávajícího orgánu,
datum vydání,
— datum počátku platnosti karty, datum konce platnosti
(pokud přichází v úvahu).
4.5.5.2.4 Identifikace držitele karty
366) Kontrolní karta musí být schopna uchovat následující iden­
tifikační údaje držitele karty:
— název kontrolního orgánu,
— adresu kontrolního orgánu,
— příjmení držitele,
— jméno(a) držitele,
— preferovaný jazyk.
4.5.5.2.5 Údaje o kontrolních činnostech
367) Kontrolní karta musí být schopna uchovat následující údaje
o kontrolní činnosti:
— datum a čas kontroly,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 96
— druh kontroly (zobrazení a/nebo tisk a/nebo stahování
z celku ve vozidle a/nebo stahování z karty a/nebo
silniční kalibrační kontrola),
— dobu stahování dat (pokud proběhlo),
— registrační značku vozidla a registrační orgán členského
státu kontrolovaného vozidla,
— číslo karty a členský stát vydávající kontrolovanou
kartu řidiče.
368) Kontrolní karta musí být schopna uchovat nejméně 230
takových záznamů.
▼M3
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á nasta­
vení tachografu držitele karty.
368b) Úložná kapacita kontrolní karty pro specifická nastavení
tachografu držitele karty je 3072 bajtů.
▼B
4.5.6 Karta podniku
4.5.6.1 A p l i k a c e t a c h o g r a f u ( p ř í s t u p n á p r o c e l k y v e
v o z i d l e p r v n í a d r u h é g e n e r a c e )
4.5.6.1.1 Identifikace aplikace
369) Karta podniku musí být schopna uchovat následující iden­
tifikační údaje aplikace:
— identifikaci aplikace tachografu,
— identifikaci typu karty tachografu.
4.5.6.1.2 Klíče a certifikáty
370) Karta podniku musí být schopna uchovat řadu kryptogra­
fických klíčů a certifikátů podle specifikace v dodatku 11
části A.
4.5.6.1.3 Identifikace karty
371) Karta podniku musí být schopna uchovat následující iden­
tifikační údaje karty:
— číslo karty,
— vydávající členský stát, název vydávajícího orgánu,
datum vydání,
— datum počátku platnosti karty, datum konce platnosti
(pokud přichází v úvahu).
4.5.6.1.4 Identifikace držitele karty
372) Karta podniku musí být schopna uchovat následující iden­
tifikační údaje držitele karty:
— název podniku,
— adresu podniku.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 97
4.5.6.1.5 Údaje o činnosti podniku
373) Karta podniku musí být schopna uchovat následující údaje
o činnosti podniku:
— datum a čas činnosti,
— druh činnosti (odemčení a/nebo uzamčení celku ve
vozidle a/nebo stahování z celku ve vozidle a/nebo
stahování z karty)
— dobu stahování dat (pokud proběhlo),
— registrační značku vozidla a registrační orgán vozidla
členského státu,
— číslo karty a kartu vydávající členský stát (v případě
stahování dat z karty).
374) Karta podniku musí být schopna uchovat nejméně 230
takových záznamů.
4.5.6.2 A p l i k a c e t a c h o g r a f u d r u h é g e n e r a c e ( n e p ř í ­
s t u p n á p r o c e l e k v e v o z i d l e p r v n í g e n e r a c e )
4.5.6.2.1 Identifikace aplikace
375) Karta podniku musí být schopna uchovat následující iden­
tifikační údaje aplikace:
— identifikaci aplikace tachografu,
— identifikaci typu karty tachografu.
▼M3
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í identi­
fikační údaje aplikace použitelné pouze pro verzi 2.
▼B
4.5.6.2.2 Klíče a certifikáty
376) Karta dílny musí být schopna uchovat řadu kryptografic­
kých klíčů a certifikátů dle specifikace v dodatku 11 části
B.
4.5.6.2.3 Identifikace karty
377) Karta podniku musí být schopna uchovat následující iden­
tifikační údaje karty:
— číslo karty,
— vydávající členský stát, název vydávajícího orgánu,
datum vydání,
— datum počátku platnosti karty, datum konce platnosti
(pokud přichází v úvahu).
4.5.6.2.4 Identifikace držitele karty
378) Karta podniku musí být schopna uchovat následující iden­
tifikační údaje držitele karty:
— název podniku,
— adresu podniku.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 98
4.5.6.2.5 Údaje o činnosti podniku
379) Karta podniku musí být schopna uchovat následující údaje
o činnosti podniku:
— datum a čas činnosti,
— druh činnosti (odemčení a/nebo uzamčení celku ve
vozidle a/nebo stahování z celku ve vozidle a/nebo
stahování z karty)
— dobu stahování dat (pokud proběhlo),
— registrační značku vozidla a registrační orgán vozidla
členského státu,
— číslo karty a kartu vydávající členský stát (v případě
stahování dat z karty).
380) Karta podniku musí být schopna uchovat nejméně 230
takových záznamů.
▼M3
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á nasta­
vení tachografu držitele karty.
380b) Úložná kapacita karty podniku pro specifická nastavení
tachografu držitele karty je 3072 bajtů.
▼B
5 MONTÁŽ ZÁZNAMOVÉHO ZAŘÍZENÍ
5.1 Montáž
381) Nové záznamové zařízení musí být dodáno servisní dílně
nebo výrobci vozidla neaktivované, se všemi kalibračními
parametry, jak je uvedeno v kapitole 3.21, a s nastavenými
příslušnými platnými implicitními hodnotami. V případě, že
žádná konkrétní hodnota není považována za „příslušnou“,
musí se písmenné parametry nastavit na řetězce „?“ a nume­
rické parametry na „0“. Dodávky součástí záznamového
zařízení důležitých pro zabezpečení mohou být omezeny,
pokud o to bude během certifikace zabezpečení požádáno.
382) Záznamové zařízení musí před aktivací umožnit přístup ke
kalibrační funkci dokonce, i když není v kalibračním
režimu.
▼M3
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í zazname­
ná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.
▼B
384) V průběhu montáže musí výrobci vozidel přednastavit
všechny známé parametry.
385) Výrobci vozidel nebo montážní pracovníci musí namonto­
vané záznamové zařízení aktivovat nejpozději do té doby,
než je vozidlo použito v rámci působnosti nařízení (ES)
č. 561/2006.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 99
386) Aktivace záznamového zařízení se musí spustit automaticky
prvním vložením platné karty dílny do jednoho ze zařízení
rozhraní karty.
387) Specifické úkony párování potřebné mezi snímačem
pohybu a celkem ve vozidle, pokud je namontován, musí
proběhnout automaticky před nebo v průběhu aktivace.
388) Podobně musí případné specifické úkony vytvoření vazby
mezi vnějším zařízením GNSS a celkem ve vozidle proběh­
nout automaticky před aktivací nebo v jejím průběhu.
389) Po aktivaci záznamového zařízení musí být plně aktivní
funkce zařízení a přístupová práva.
390) Po aktivaci musí záznamové zařízení předávat zařízení pro
dálkovou komunikaci zabezpečené údaje potřebné za
účelem cílených silničních kontrol.
391) Záznamové a ukládací funkce záznamového zařízení musí
být po aktivaci plně funkční.
▼M3
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
393) Montáž vnějšího zařízení GNSS vyžaduje spárování
s celkem ve vozidle a následné ověření informací o poloze
z GNSS.
394) Záznamové zařízení se musí ve vozidle umístit takovým
způsobem, aby umožňovalo řidiči přístup k potřebným
funkcím z jeho sedadla.
5.2 Montážní štítek
395) ►M3 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ý. ◄
Po každé prohlídce provedené schváleným montérem nebo
dílnou musí být původní štítek nahrazen novým.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 100
396) Štítek musí obsahovat alespoň tyto údaje:
— jméno, adresu nebo firemní značku schváleného
montéra nebo dílny,
— charakteristický koeficient vozidla ve tvaru „w = …
imp/km“,
— konstantu záznamového zařízení ve tvaru „k = … imp/
km“,
— účinný obvod pneumatik na kolech ve tvaru „l = …
mm“,
— rozměr pneumatiky,
— datum změření charakteristického koeficientu vozidla
a účinného obvodu pneumatik na kolech,
— identifikační číslo vozidla,
— přítomnost (či nepřítomnost) vnějšího zařízení GNSS,
— v příslušných případech výrobní číslo vnějšího zařízení
GNSS,
▼M3
— výrobní číslo případného zařízení pro dálkovou
komunikaci,
▼M1
— výrobní číslo všech příslušných plomb,
— část vozidla, v níž je případně zabudován adaptér,
— část vozidla, v níž je zabudován snímač pohybu, pokud
není připojen k převodové skříni nebo není používán
adaptér,
— popis barvy kabelu mezi adaptérem a částí vozidla
zajišťující přicházející impulsy,
— výrobní číslo vloženého snímače pohybu adaptéru.
▼M3
— standardní druh nákladu přiřazený k vozidlu.
▼B
397) Pouze u vozidel kategorií M1 a N1, která jsou vybavena
adaptérem v souladu s nařízením Komise (ES) č. 68/2009 ( 1 )
v platném znění a u kterých není možné zahrnout všechny
potřebné informace podle požadavku 396, může být použit
druhý doplňkový štítek. V takových případech musí tento
doplňkový štítek obsahovat alespoň informace uvedené
v posledních čtyřech odrážkách požadavku 396.
▼M1
( 1 ) Úř. věst. č. L 21, 24.1.2009, s. 3
02016R0799 — CS — 21.08.2023 — 003.002 — 101
Pokud je tento druhý, doplňkový štítek použit, musí být
upevněn vedle prvního, hlavního štítku popsaného v poža­
davku 396 a musí mít stejnou úroveň ochrany. Kromě toho
musí být na doplňkovém štítku uvedeno jméno a adresa
nebo obchodní název schváleného montéra nebo dílny,
která montáž provedla, a datum montáže.
5.3 Plomby
398) Následující díly musí být zaplombovány:
— jakékoliv spojení, jehož rozpojení by umožnilo prove­
dení neidentifikovatelných změn nebo neidentifikova­
telnou ztrátu dat (toto opatření může např. platit pro
upevnění snímače pohybu na převodovce, adaptér pro
vozidla M1/N1, vnější připojení GNSS nebo celek ve
vozidle);
— montážní štítek, pokud není připevněn tak, aby jej
nebylo možno sejmout bez zničení jeho údajů.
▼M1
398a) Výše uvedené plomby musí být certifikovány v souladu
s normou EN 16882:2016.
▼B
399) Výše uvedené plomby mohou být odstraněny:
— v nouzových situacích,
— při montáži, seřizování nebo opravě omezovače rych­
losti vozidla nebo jiného zařízení přispívajícího
k bezpečnosti silničního provozu za předpokladu, že
záznamové zařízení nadále spolehlivě a správně funguje
a bude opětovně zaplombováno schváleným montérem
nebo dílnou (v souladu s kapitolou 6) okamžitě po
namontování omezovače rychlosti nebo jiného zařízení
přispívajícího k bezpečnosti silničního provozu nebo
v průběhu sedmi dnů v ostatních případech.
400) V každém případě, kdy jsou porušeny tyto plomby, musí
být vyhotoven písemný zápis se zdůvodněním celé události
a musí být předán příslušnému orgánu.
401) Plomby jsou opatřeny identifikačním číslem přiděleným
jejich výrobcem. Toto číslo musí být jedinečné a odlišné
od všech ostatních čísel plomb přidělených jakýmkoli
jiným výrobcem plomb.
▼M1
Toto jedinečné identifikační číslo je definováno jako:
MMNNNNNNNN provedené neodstranitelným značením,
přičemž MM je jedinečná identifikace výrobce (registrační
databázi spravuje EK) a NNNNNNNN alfanumerické číslo
plomby, které je jedinečné v doméně výrobců.
▼B
402) Plomby musí mít volné místo, kam mohou schválení
montéři, dílny nebo výrobci vozidel přidat zvláštní značku
podle čl. 22 odst. 3 nařízení (EU) č. 165/2014.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 102
Tato značka nesmí zakrývat identifikační číslo plomby.
▼M1
403) Výrobci plomb musí být registrováni v příslušné databázi,
jakmile si nechají model plomby certifikovat podle normy
EN 16882:2016, a musí zveřejnit identifikační čísla svých
plomb postupem stanoveným Evropskou komisí.
404) Schválené dílny a výrobci vozidel musí v rámci naří­
zení (EU) č. 165/2014 používat pouze plomby certifikované
podle normy EN 16882:2016 od výrobců uvedených ve
výše zmíněné databázi.
▼B
405) Výrobci plomb a jejich prodejci musí zachovat plnou sledo­
vatelnost záznamů prodaných plomb pro použití v rámci
nařízení (EU) č. 165/2014 a musí být připraveni je podle
potřeby předložit příslušným vnitrostátním orgánům.
406) Jedinečná identifikační čísla plomb musí být viditelná na
montážním štítku.
6 KONTROLY, INSPEKCE A OPRAVY
Požadavky týkající se okolností, za kterých mohou být odstraněny
plomby uváděné v čl. 22 odst. 5 nařízení (EU) č. 165/2014, jsou
definovány v kapitole 5.3 této přílohy.
6.1 Schválení montérů, dílen a výrobců vozidel
Členské státy schvalují a pravidelně kontrolují subjekty a vydávají
jim osvědčení k provádění:
— montáží,
— kontrol,
— prohlídek,
— oprav.
Karty dílny se vydávají pouze montérům a/nebo dílnám oprávněným
k aktivaci a/nebo kalibraci záznamových zařízení v souladu s touto
přílohou, a kromě řádně odůvodněných případů:
— které nejsou oprávněny k použití karty podniku
— a jejichž další profesní činnosti nepředstavují potenciální střet
zájmů z hlediska celkového zabezpečení systému podle poža­
davků v dodatku 10.
▼M1
6.2 Kontrola nových nebo opravených součástí
407) U každého jednotlivého zařízení, ať již nového nebo opra­
veného, musí být zkontrolována správná funkčnost a přes­
nost odečtů a záznamů, a to v rámci limitů stanovených
v bodech 3.2.1, 3.2.2, 3.2.3 a 3.3.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 103
6.3 Montážní kontrola
▼M1
408) Po namontování záznamového zařízení do vozidla musí
celá instalace (včetně záznamového zařízení) vyhovovat
ustanovením vztahujícím se k maximálním tolerancím
stanoveným v bodech 3.2.1, 3.2.2, 3.2.3 a 3.3. Celá insta­
lace musí být zaplombována v souladu s bodem 5.3
a zkalibrována.
▼B
6.4 Periodické prohlídky
▼M3
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
410) Tyto prohlídky musí obsahovat následující kontroly zajiš­
ťující, že:
— je zajištěna správná funkce záznamového zařízení
včetně ukládání údajů na kartách tachografu a komuni­
kace se snímači dálkové komunikace,
— je zajištěn soulad s ustanoveními bodů 3.2.1 a 3.2.2,
které se týkají povolených tolerancí při montáži,
— je zajištěn soulad s ustanoveními bodů 3.2.3 a 3.3,
— záznamové zařízení nese značku schválení typu,
— je upevněn montážní štítek definovaný v požadavku
396 a popisný štítek definovaný v požadavku 225,
— odpovídá velikost pneumatik a skutečný obvod
pneumatik,
— k zařízení nejsou připojeny žádné manipulační
pomůcky,
— plomby jsou správně umístěné, v dobrém stavu, že jsou
jejich identifikační čísla platná (příslušný výrobce
plomb v databázi EK) a že jejich identifikační čísla
odpovídají značkám na montážním štítku (viz poža­
davek 401).
▼M3
— že identifikátor verze uložené digitální mapy je nejno­
vější.
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í.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 104
411) Pokud se zjistí, že od poslední kontroly došlo k výskytu
některé z událostí uvedených v kapitole 3.9 (Zjišťování
událostí a/nebo závad), pokud je taková událost výrobci
tachografů a/nebo vnitrostátními orgány považována za
možné ohrožení zabezpečení zařízení, potom je dílna
povinna:
a. porovnat identifikační údaje snímače pohybu připoje­
ného k převodovce s identifikačními údaji párového
snímače pohybu zaregistrovaného v celku ve vozidle;
b. zkontrolovat, zda informace uvedené na montážním
štítku odpovídají informacím obsaženým v záznamu
celku ve vozidle;
c. zkontrolovat, zda výrobní číslo a číslo schválení snímače
pohybu, pokud je vytištěno na těle snímače pohybu,
odpovídá informacím obsaženým v datové paměti zázna­
mového zařízení;
d. porovnat případné identifikační údaje uvedené na
popisném štítku vnějšího zařízení GNSS s údaji ulože­
nými v datové paměti celku ve vozidle.
412) Dílny jsou povinny ve svých kontrolních zprávách evidovat
veškerá zjištění týkající se porušených plomb nebo mani­
pulačních pomůcek. Tyto zprávy musí dílny uchovávat po
dobu nejméně dvou let a zpřístupnit je příslušnému orgánu,
kdykoli jsou o to požádány.
413) Tyto prohlídky musí obsahovat kalibraci a preventivní
výměnu plomb, za jejichž upevnění jsou odpovědné dílny.
6.5 Měření odchylek
414) Měření odchylek při montáži a při užívání se provádí za
následujících podmínek, jež jsou považovány za obvyklé
zkušební podmínky:
— prázdné vozidlo v obvyklých provozních podmínkách,
— tlak v pneumatikách podle údajů výrobce,
— opotřebení pneumatik je v mezích povolených vnitros­
tátními právními předpisy,
— pohyb vozidla:
— vozidlo se pohybuje vlastní silou po přímé a vodorovné
trati rychlostí 50 ± 5 km/h. Měřená vzdálenost musí být
minimálně 1 000 m.
— za předpokladu, že je zajištěna srovnatelná přesnost,
může být pro provedení zkoušky použito alternativních
metod, jako je vhodné zkušební zařízení.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 105
6.6 Opravy
415) Dílny musí být schopny stahovat data ze záznamového
zařízení, aby údaje mohly být předloženy zpět dotyčnému
dopravnímu podniku.
416) Schválení montéři a servisní dílny musí dopravnímu
podniku vydat potvrzení o nemožnosti stáhnout data,
pokud špatná funkce záznamového zařízení brání stažení
dříve zaznamenaných dat i v případě, že oprava byla prová­
děna v téže dílně. Dílny musí archivovat kopie vydaných
potvrzení nejméně po dobu dvou let.
7 VYDÁVÁNÍ KARET
Postupy vydávání karet stanovené jednotlivými členskými státy
musí vyhovovat následujícím podmínkám:
417) Číslo karty při prvním vydání karty tachografu žadateli
musí obsahovat pořadový index (v příslušných případech),
index náhrady a index obnovy, které jsou nastaveny na
hodnotu „0“.
418) Čísla karet všech neosobních karet tachografu, které byly
vydány témuž kontrolnímu orgánu, téže dílně nebo témuž
dopravnímu podniku, musí mít shodných prvních 13 číslic,
ale všechna musí mít odlišné pořadové indexy.
419) Karta tachografu, která se vydává jako náhrada již existující
karty, musí mít stejné číslo karty jako nahrazovaný exem­
plář s výjimkou indexu náhrady, který se zvedne o jednotku
(v pořadí 0, …, 9, A, …, Z).
420) Karta tachografu, která se vydává jako náhrada již existující
karty, musí mít shodné datum ukončení použitelnosti jako
nahrazovaný exemplář.
421) Karta tachografu vydávaná při obnovení již existující karty
musí mít stejné číslo karty jako obnovovaný exemplář
s výjimkou indexu náhrady, který je nastaven na hodnotu
„0“, a indexu obnovy, který je zvýšen o jednotku (v pořadí
0, …, 9, A, …, Z).
422) Výměna existující karty tachografu při úpravách admini­
strativních údajů, musí proběhnout podle pravidel platných
pro obnovu karty, pokud proces probíhá ve stejném člen­
ském státě, nebo podle pravidel pro první vydání karty,
pokud probíhá v jiném členském státě.
423) „Příjmení držitele karty“ u neosobních karet dílny nebo
kontrolních karet musí být vyplněno názvem dílny nebo
kontrolního orgánu nebo jménem montéra nebo kontrolora,
pokud se tak členské státy rozhodnou.
424) Členské státy si musí elektronicky vyměňovat údaje, aby
byla zajištěna jedinečnost karet řidiče, které vydávají
v souladu s článkem 31 nařízení (EU) č. 165/2014.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 106
8 SCHVÁLENÍ TYPU ZÁZNAMOVÉHO ZAŘÍZENÍ A KARET
TACHOGRAFU
8.1 Všeobecně
▼M1
Pro účely této kapitoly se „záznamovým zařízením“ rozumí „zázna­
mové zařízení nebo jeho součásti“. Schválení typu není vyžadováno
pro kabel(y) spojující snímač pohybu s celkem ve vozidle, vnější
zařízení GNSS s celkem ve vozidle nebo vnější zařízení pro
dálkovou komunikaci s celkem ve vozidle. Papír používaný zázna­
movým zařízením je považován za součást záznamového zařízení.
Kterýkoli výrobce může požádat o schválení typu součásti nebo
součástí záznamového zařízení s jakoukoli jinou součástí či
součástmi záznamového zařízení, pokud každá součást splňuje poža­
davky této přílohy. Případně mohou výrobci rovněž požádat o schvá­
lení typu záznamového zařízení.
Jak je popsáno v definici uvedené v čl. 2 bodě 10 tohoto nařízení,
existují různé varianty montáže součástí celků ve vozidle. Bez
ohledu na montáž součástí celku ve vozidle nejsou externí anténa
a (případně) anténní rozdvojka připojené k přijímači GNSS nebo
k zařízení pro dálkovou komunikaci součástí schválení typu celku
ve vozidle.
Výrobci, kteří obdrželi schválení typu pro záznamové zařízení, však
musí vést veřejně dostupný seznam antén a rozdvojek kompatibil­
ních s každým typově schváleným celkem ve vozidle, vnějším zaří­
zením GNSS a vnějším zařízením pro dálkovou komunikaci.
▼B
425) Záznamové zařízení musí být předloženo ke schválení typu
úplné se všemi integrovanými přídavnými zařízeními.
426) Postup schvalování typu záznamového zařízení a karet
tachografu musí zahrnovat zkoušky bezpečnostních
opatření, funkční zkoušky a zkoušky vzájemné interopera­
bility. Pozitivní výsledky každé z těchto zkoušek se potvrdí
příslušnými osvědčeními.
▼M1
427) Orgány členských států příslušné pro schvalování typu
nevydají osvědčení o schválení typu, pokud neobdrží:
— osvědčení o bezpečnosti (vyžaduje-li ho tato příloha),
— osvědčení o funkčnosti
— a osvědčení o interoperabilitě (vyžaduje-li ho tato
příloha)
k záznamovému zařízení nebo kartě, která je předmětem
žádosti o schválení typu.
▼B
428) Jakákoli úprava programového nebo technického vybavení
zařízení nebo povahy materiálu použitého pro jeho výrobu
musí být před zavedením oznámena orgánu, který vydal
schválení typu zařízení. Tento orgán potvrdí výrobci rozší­
ření schválení typu, nebo může požadovat aktualizaci nebo
potvrzení příslušného osvědčení o funkčnosti, o bezpečnosti
a/nebo o interoperabilitě.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 107
429) Postup aktualizace programového vybavení in situ v zázna­
movém zařízení musí být schválen orgánem, který vydal
schválení typu pro záznamové zařízení. Aktualizace progra­
mového vybavení nesmí změnit ani vymazat žádné údaje
o činnosti řidiče uložené v záznamovém zařízení. Progra­
mové vybavení může být aktualizováno pouze na odpověd­
nost 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. Aktuali­
zace programového vybavení záznamového zařízení může
vylučovat zavedení nových sad písma, není-li to technicky
proveditelné.
▼B
8.2 Osvědčení o bezpečnosti
431) Vydání osvědčení o bezpečnosti se provede v souladu
s ustanoveními dodatku 10 této přílohy. Součásti záznamo­
vého zařízení, pro které se vydává osvědčení, jsou celek ve
vozidle, snímač pohybu, vnější zařízení GNSS a karty
tachografu.
432) Za výjimečných okolností, kdy orgány provádějící certifi­
kaci zabezpečení odmítnou vystavit osvědčení pro nové
zařízení z důvodu zastaralosti zabezpečovacích mecha­
nismů, musí být schválení typu nadále vydáváno pouze
za těchto konkrétních a výjimečných okolností a když
neexistuje žádné alternativní řešení, které by bylo v souladu
s nařízením.
433) Za těchto okolností je dotyčný členský stát povinen neprod­
leně informovat Evropskou komisi, která do dvanácti
měsíců od udělení schválení typu zahájí postup, který
zajistí obnovení původní úrovně zabezpečení.
8.3 Osvědčení o funkčnosti
434) Každý žadatel o vydání schválení typu dodá orgánu přísluš­
nému pro schvalování typu členského státu všechny mate­
riály a dokumentaci, kterou tento orgán považuje za
nezbytnou.
435) Výrobci musí poskytovat příslušné vzorky výrobků ucháze­
jících se o schválení typu a související dokumentaci poža­
dovanou zkušebnami pověřenými prováděním funkčních
zkoušek, a to do jednoho měsíce od data vyžádání. Veškeré
náklady související s touto žádostí nese žádající subjekt.
Zkušebny jsou povinny uchovávat veškeré obchodně citlivé
informace v tajnosti.
436) Osvědčení o funkčnosti musí být výrobci vydáno teprve po
úspěšném absolvování všech funkčních zkoušek minimálně
v rozsahu uvedeném v dodatku 9.
437) Osvědčení o funkčnosti vydá orgán příslušný pro schvalo­
vání typu. Toto osvědčení musí obsahovat, kromě jména
příjemce osvědčení a identifikace modelu, podrobný
seznam provedených zkoušek a dosažených výsledků.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 108
438) V osvědčení o funkčnosti kterékoli součásti záznamového
zařízení musí být také uvedena čísla schválení typu ostat­
ních kompatibilních součástí záznamového zařízení se
schválením typu, testovaných pro vydání osvědčení.
439) V osvědčení o funkčnosti kterékoli součásti záznamového
zařízení musí být také uvedena norma ISO nebo CEN, na
jejímž základě bylo vydáno osvědčení pro funkční rozhraní.
8.4 Osvědčení o interoperabilitě
440) Zkoušky interoperability se provádějí v jediné zkušebně
schválené a podléhající Evropské komisi.
441) Zkušebna registruje požadavky výrobců na zkoušky intero­
perability v pořadí, v jakém byly doručeny.
442) Požadavky budou úředně registrovány pouze tehdy, jestliže
zkušebně již byly dodány:
— úplná sada materiálů a dokumentů nezbytných pro
takové zkoušky interoperability,
— související osvědčení o bezpečnosti,
— související osvědčení o funkčnosti.
Datum registrace žádosti musí být oznámeno výrobci.
▼M3
443) U záznamového zařízení nebo kart tachografu, které
neprošly analýzou zranitelnosti v souvislosti s jejich hodno­
cení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.
▼B
444) Každý výrobce požadující zkoušky interoperability se
zaváže ponechat zkušebně, která odpovídá za provedení
zkoušek, úplnou sadu materiálů a dokumentace, které
byly ke zkouškám dodány.
445) Zkoušky interoperability musí být provedeny v souladu
s dodatkem 9 této přílohy postupně se všemi typy zázna­
mových zařízení a karet tachografu:
— jejichž schválení typu je dosud platné, nebo
— jejichž schválení typu není dosud vyřízeno, ale mají
platné osvědčení o interoperabilitě.
446) Zkoušky interoperability se musí vztahovat na všechny
generace záznamového zařízení nebo karet tachografu,
které se dosud používají.
▼M3
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.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 109
448) Jestliže zkoušky interoperability nejsou úspěšné s jedním
nebo několika záznamovými zařízeními nebo kartou/
kartami tachografu, osvědčení o interoperabilitě nesmí být
vydáno, dokud výrobce žádající o schválení neprovede
nezbytné úpravy a neabsolvuje úspěšně zkoušky interope­
rability. Zkušebna identifikuje příčinu problému týkajícího
se interoperability s pomocí příslušného výrobce a pokusí
se mu pomoci nalézt technické řešení. V případě, že
výrobce již upravil svůj výrobek, musí zajistit od přísluš­
ných orgánů potvrzení o pokračující platnosti osvědčení
o bezpečnosti a funkčnosti.
449) Osvědčení o interoperabilitě je platné šest měsíců. Na konci
tohoto období je odebráno, pokud výrobce neobdržel odpo­
vídající osvědčení o schválení typu. Osvědčení doručí
výrobce orgánu příslušnému pro schvalování typu člen­
ského státu, který vydal osvědčení o funkčnosti.
450) Jakýkoli prvek, který by mohl způsobit závadu interopera­
bility, nesmí být použit pro vytvoření zisku a nesmí vést
k získání dominantního postavení.
8.5 Osvědčení o schválení typu
451) Orgán členského státu příslušný pro schvalování typu může
vydat osvědčení o schválení typu, jakmile obdrží tři poža­
dovaná osvědčení.
452) Osvědčení o schválení typu jakékoli součásti záznamového
zařízení musí rovněž obsahovat čísla schválení typu ostat­
ních interoperabilních záznamových zařízení se schválením
typu.
453) Orgán příslušný pro schvalování typu předá kopii osvěd­
čení o schválení typu zkušebně pověřené prováděním
zkoušek interoperability v době vydání osvědčení výrobci.
454) Zkušebna pověřená prováděním zkoušek interoperability
musí udržovat internetové stránky, na kterých je aktualizo­
vaný seznam modelů záznamových zařízení a karet
tachografu:
— pro které byla zaregistrována žádost o zkoušky
interoperability,
— které obdržely osvědčení o interoperabilitě (i dočasné),
— které získaly osvědčení o schválení typu.
8.6 Výjimečný postup: první osvědčení o interoperabilitě pro zázna­
mové zařízení a karty tachografu druhé generace
455) V průběhu čtyř měsíců po osvědčení první vazby mezi
záznamovým zařízením a kartami tachografu (kartami
řidiče, dílny, kontrolní a podniku) druhé generace z hlediska
interoperability je jakékoliv vydané osvědčení o interopera­
bilitě (včetně těch prvních) týkající se žádostí registrova­
ných v tomto období považováno za dočasné.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 110
456) Jestliže na konci tohoto období budou všechny dotčené
výrobky vzájemně interoperabilní, stanou se všechna
příslušná osvědčení o interoperabilitě definitivními.
457) Jestliže budou v tomto období zjištěny závady z hlediska
interoperability, musí zkušebna pověřená prováděním
zkoušek interoperability za pomoci všech zúčastněných
výrobců identifikovat zdroje obtíží a vyzvat výrobce
k provedení nezbytných úprav.
458) Jestliže na konci tohoto období budou problémy s interope­
rabilitou přetrvávat, musí odpovědná zkušebna ve spolu­
práci s dotčenými výrobci a orgány příslušnými pro schva­
lování typu, které vydaly související osvědčení o funkčnosti,
zjistit důvody závad v interoperabilitě a stanovit, které
úpravy by měl každý dotčený výrobce provést. Hledání
technických řešení smí trvat maximálně dva měsíce, po
kterých v případě nenalezení společného řešení rozhodne
Komise po konzultaci se zkušebnou pověřenou prováděním
zkoušek interoperability, která zařízení a karty obdrží defi­
nitivní osvědčení o interoperabilitě, a zdůvodní proč.
459) Všechny žádosti o zkoušky interoperability registrované
mezi koncem čtyřměsíčního období po vydání prvního
dočasného osvědčení o interoperabilitě a datem rozhodnutí
Komise podle požadavku 455 musí být odloženy, dokud
nebudou počáteční obtíže s interoperabilitou vyřešeny.
Tyto žádosti budou potom vyřízeny v pořadí, v jakém
byly registrovány.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 111
Dodatek 1
DATOVÝ SLOVNÍK
OBSAH
1. ÚVOD
1.1 Přístup k definování datových typů
1.2 Odkazy
2. DEFINICE DATOVÝCH TYPŮ
2.1 ActivityChangeInfo
2.2 Address
2.3 AESKey
2.4 AES128Key
2.5 AES192Key
2.6 AES256Key
2.7 BCDString
2.8 CalibrationPurpose
2.9 CardActivityDailyRecord
2.10 CardActivityLengthRange
2.11 CardApprovalNumber
▼M3
2.11a CardBorderCrossing
2.11b CardBorderCrossingRecord
▼B
2.12 CardCertificate
2.13 CardChipIdentification
2.14 CardConsecutiveIndex
2.15 CardControlActivityDataRecord
2.16 CardCurrentUse
2.17 CardDriverActivity
2.18 CardDrivingLicenceInformation
2.19 CardEventData
2.20 CardEventRecord
2.21 CardFaultData
2.22 CardFaultRecord
2.23 CardIccIdentification
2.24 CardIdentification
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 112
2.24a CardLoadTypeEntries
2.24b CardLoadTypeEntryRecord
2.24c CardLoadUnloadOperations
2.24d CardLoadUnloadRecord
▼B
2.25 CardMACertificate
2.26 CardNumber
▼M3
2.26a CardPlaceAuthDailyWorkPeriod
▼B
2.27 CardPlaceDailyWorkPeriod
2.28 CardPrivateKey
2.29 CardPublicKey
2.30 CardRenewalIndex
2.31 CardReplacementIndex
2.32 CardSignCertificate
2.33 CardSlotNumber
2.34 CardSlotsStatus
2.35 CardSlotsStatusRecordArray
2.36 CardStructureVersion
2.37 CardVehicleRecord
2.38 CardVehiclesUsed
2.39 CardVehicleUnitRecord
2.40 CardVehicleUnitsUsed
2.41 Certificate
2.42 CertificateContent
2.43 CertificateHolderAuthorisation
2.44 CertificateRequestID
2.45 CertificationAuthorityKID
2.46 CompanyActivityData
2.47 CompanyActivityType
2.48 CompanyCardApplicationIdentification
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 113
2.48a CompanyCardApplicationIdentificationV2
▼B
2.49 CompanyCardHolderIdentification
2.50 ControlCardApplicationIdentification
▼M3
2.50a ControlCardApplicationIdentificationV2
▼B
2.51 ControlCardControlActivityData
2.52 ControlCardHolderIdentification
2.53 ControlType
2.54 CurrentDateTime
2.55 CurrentDateTimeRecordArray
2.56 DailyPresenceCounter
2.57 Datef
2.58 DateOfDayDownloaded
2.59 DateOfDayDownloadedRecordArray
2.60 Distance
▼M3
2.60a DownloadInterfaceVersion
▼B
2.61 DriverCardApplicationIdentification
▼M3
2.61a DriverCardApplicationIdentificationV2
▼B
2.62 DriverCardHolderIdentification
▼M1
2.63 Vyhrazeno pro budoucí použití
▼B
2.64 EGFCertificate
2.65 EmbedderIcAssemblerId
2.66 EntryTypeDailyWorkPeriod
2.67 EquipmentType
2.68 EuropeanPublicKey
2.69 EventFaultRecordPurpose
2.70 EventFaultType
2.71 ExtendedSealIdentifier
2.72 ExtendedSerialNumber
2.73 FullCardNumber
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 114
2.74 FullCardNumberAndGeneration
2.75 Generation
2.76 GeoCoordinates
2.77 GNSSAccuracy
▼M1
2.78 GNSSAccumulatedDriving
2.79 GNSSAccumulatedDrivingRecord
▼M3
2.79a GNSSAuthAccumulatedDriving
2.79b GNSSAuthStatusADRecord
2.79c GNSSPlaceAuthRecord
▼B
2.80 GNSSPlaceRecord
2.81 HighResOdometer
2.82 HighResTripDistance
2.83 HolderName
▼M3
2.84 Vyhrazeno pro budoucí použití
▼B
2.85 K-ConstantOfRecordingEquipment
2.86 KeyIdentifier
2.87 KMWCKey
2.88 Language
2.89 LastCardDownload
▼M3
2.89a LengthOfFollowingData
▼B
2.90 LinkCertificate
▼M3
2.90a LoadType
▼B
2.91 L-TyreCircumference
2.92 MAC
2.93 ManualInputFlag
2.94 ManufacturerCode
2.95 ManufacturerSpecificEventFaultData
2.96 MemberStateCertificate
2.97 MemberStateCertificateRecordArray
2.98 MemberStatePublicKey
2.99 Name
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 115
2.100 NationAlpha
2.101 NationNumeric
▼M3
2.101a NoOfBorderCrossingRecords
▼B
2.102 NoOfCalibrationRecords
2.103 NoOfCalibrationsSinceDownload
2.104 NoOfCardPlaceRecords
2.105 NoOfCardVehicleRecords
2.106 NoOfCardVehicleUnitRecords
2.107 NoOfCompanyActivityRecords
2.108 NoOfControlActivityRecords
2.109 NoOfEventsPerType
2.110 NoOfFaultsPerType
▼M1
2.111 NoOfGNSSADRecords
▼M3
2.111a NoOfLoadUnloadRecords
▼B
2.112 NoOfSpecificConditionRecords
▼M3
2.112a NoOfLoadTypeEntryRecords
▼B
2.113 OdometerShort
2.114 OdometerValueMidnight
▼M3
2.114a OperationType
▼B
2.115 OdometerValueMidnightRecordArray
2.116 OverspeedNumber
▼M3
2.116a PlaceAuthRecord
2.116b PlaceAuthStatusRecord
▼B
2.117 PlaceRecord
▼M3
2.117a PositionAuthenticationStatus
▼B
2.118 PreviousVehicleInfo
2.119 PublicKey
2.120 RecordType
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 116
2.121 RegionAlpha
2.122 RegionNumeric
2.123 RemoteCommunicationModuleSerialNumber
2.124 RSAKeyModulus
2.125 RSAKeyPrivateExponent
2.126 RSAKeyPublicExponent
2.127 RtmData
2.128 SealDataCard
2.129 SealDataVu
2.130 SealRecord
2.131 SensorApprovalNumber
2.132 SensorExternalGNSSApprovalNumber
2.133 SensorExternalGNSSCoupledRecord
2.134 SensorExternalGNSSIdentification
2.135 SensorExternalGNSSInstallation
2.136 SensorExternalGNSSOSIdentifier
2.137 SensorExternalGNSSSCIdentifier
2.138 SensorGNSSCouplingDate
2.139 SensorGNSSSerialNumber
2.140 SensorIdentification
2.141 SensorInstallation
2.142 SensorInstallationSecData
2.143 SensorOSIdentifier
2.144 SensorPaired
2.145 SensorPairedRecord
2.146 SensorPairingDate
2.147 SensorSCIdentifier
2.148 SensorSerialNumber
2.149 Signature
2.150 SignatureRecordArray
2.151 SimilarEventsNumber
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 117
2.152 SpecificConditionRecord
2.153 SpecificConditions
2.154 SpecificConditionType
2.155 Speed
2.156 SpeedAuthorised
2.157 SpeedAverage
2.158 SpeedMax
▼M3
2.158a TachographCardsGen1Suppression
▼B
2.159 TachographPayload
▼M1
2.160 Vyhrazeno pro budoucí použití
▼B
2.161 TDesSessionKey
2.162 TimeReal
2.163 TyreSize
2.164 VehicleIdentificationNumber
2.165 VehicleIdentificationNumberRecordArray
2.166 VehicleRegistrationIdentification
▼M3
2.166a VehicleRegistrationIdentificationRecordArray
▼B
2.167 VehicleRegistrationNumber
2.168 VehicleRegistrationNumberRecordArray
2.169 VuAbility
2.170 VuActivityDailyData
2.171 VuActivityDailyRecordArray
2.172 VuApprovalNumber
2.173 VuCalibrationData
2.174 VuCalibrationRecord
2.175 VuCalibrationRecordArray
2.176 VuCardIWData
2.177 VuCardIWRecord
2.178 VuCardIWRecordArray
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 118
2.179 VuCardRecord
2.180 VuCardRecordArray
2.181 VuCertificate
2.182 VuCertificateRecordArray
2.183 VuCompanyLocksData
2.184 VuCompanyLocksRecord
2.185 VuCompanyLocksRecordArray
▼M3
2.185a VuConfigurationLengthRange
▼B
2.186 VuControlActivityData
2.187 VuControlActivityRecord
2.188 VuControlActivityRecordArray
2.189 VuDataBlockCounter
2.190 VuDetailedSpeedBlock
2.191 VuDetailedSpeedBlockRecordArray
2.192 VuDetailedSpeedData
▼M3
2.192a VuDigitalMapVersion
▼B
2.193 VuDownloadablePeriod
2.194 VuDownloadablePeriodRecordArray
2.195 VuDownloadActivityData
2.196 VuDownloadActivityDataRecordArray
2.197 VuEventData
2.198 VuEventRecord
2.199 VuEventRecordArray
2.200 VuFaultData
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 119
2.201 VuFaultRecord
2.202 VuFaultRecordArray
▼M1
2.203 VuGNSSADRecord
▼M3
2.203a VuBorderCrossingRecord
2.203b VuBorderCrossingRecordArray
▼M1
2.204 VuGNSSADRecordArray
▼M3
2.204a VuGnssMaximalTimeDifference
▼B
2.205 VuIdentification
2.206 VuIdentificationRecordArray
2.207 VuITSConsentRecord
2.208 VuITSConsentRecordArray
▼M3
2.208a VuLoadUnloadRecord
2.208b VuLoadUnloadRecordArray
▼B
2.209 VuManufacturerAddress
2.210 VuManufacturerName
2.211 VuManufacturingDate
2.212 VuOverSpeedingControlData
2.213 VuOverSpeedingControlDataRecordArray
2.214 VuOverSpeedingEventData
2.215 VuOverSpeedingEventRecord
2.216 VuOverSpeedingEventRecordArray
2.217 VuPartNumber
2.218 VuPlaceDailyWorkPeriodData
2.219 VuPlaceDailyWorkPeriodRecord
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 120
2.220 VuPlaceDailyWorkPeriodRecordArray
2.221 VuPrivateKey
2.222 VuPublicKey
▼M3
2.222a VuRtcTime
▼B
2.223 VuSerialNumber
2.224 VuSoftInstallationDate
2.225 VuSoftwareIdentification
2.226 VuSoftwareVersion
2.227 VuSpecificConditionData
2.228 VuSpecificConditionRecordArray
2.229 VuTimeAdjustmentData
▼M1
2.230 Vyhrazeno pro budoucí použití
2.231 Vyhrazeno pro budoucí použití
▼B
2.232 VuTimeAdjustmentRecord
2.233 VuTimeAdjustmentRecordArray
2.234 WorkshopCardApplicationIdentification
▼M3
2.234a WorkshopCardApplicationIdentificationV2
2.234b WorkshopCardCalibrationAddData
2.234c WorkshopCardCalibrationAddDataRecord
▼B
2.235 WorkshopCardCalibrationData
2.236 WorkshopCardCalibrationRecord
2.237 WorkshopCardHolderIdentification
2.238 WorkshopCardPIN
2.239 W-VehicleCharacteristicConstant
2.240 VuPowerSupplyInterruptionRecord
2.241 VuPowerSupplyInterruptionRecordArray
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 121
2.242 VuSensorExternalGNSSCoupledRecordArray
2.243 VuSensorPairedRecordArray
3. DEFINICE HODNOT A ROZSAHŮ VELIKOSTÍ
4. ZNAKOVÉ SADY
5. KÓDOVÁNÍ
6. IDENTIFIKÁTORY OBJEKTŮ A IDENTIFIKÁTORY APLIKACÍ
6.1 Identifikátory objektů
6.2 Identifikátory aplikací
1. ÚVOD
Tento dodatek specifikuje formáty dat, datové prvky a datové struktury
pro použití v záznamovém zařízení a v kartách tachografu.
1.1 Přístup k definování datových typů
Tento dodatek používá k definování datových typů notaci ASN.1
(Abstract Syntax Notation One). Díky tomu lze jednoduchá a strukturo­
vaná data definovat, aniž by se předpokládala nějaká konkrétní přeno­
sová syntaxe (pravidla kódování), která bude závislá na aplikaci a systé­
movém prostředí.
Konvence pojmenování typů v ASN.1 jsou v souladu s ISO/IEC 8824-1.
To znamená, že:
— tam, kde je to možné, je význam datového typu naznačen zvolenými
názvy,
— tam, kde je datový typ složen z jiných datových typů, je názvem
datového typu nadále jednoduchá posloupnost abecedních znaků
začínající velkým písmenem, nicméně velká písmena jsou použita
uvnitř názvu ke sdělení příslušného významu,
— názvy datových typů obvykle souvisejí s názvy datových typů, od
kterých jsou odvozeny, zařízením, ve kterém jsou data uložena,
a funkcí vztahující se k datům.
Jestliže je typ ASN.1 již definován v rámci jiného standardu a jestliže
má význam pro použití v záznamovém zařízení, je tento typ ASN.1
definován v tomto dodatku.
K umožnění několika typů kódovacích pravidel jsou některé typy ASN.1
v tomto dodatku omezeny pomocí identifikátorů rozsahu hodnot. Iden­
tifikátory rozsahu hodnot jsou definovány v bodě 3 a dodatku 2.
1.2 Odkazy
V tomto dodatku jsou použity tyto normy:
ISO 639 Code for the representation of names of languages.
First Edition: 1988.
ISO 3166 Codes for the representation of names of countries
and their subdivisions – Part 1: Country codes, 2013
ISO 3779 Road vehicles – Vehicle identification number (VIN) –
Content and structure. 2009
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 122
ISO/IEC 7816-5 Identification cards – Integrated circuit cards – Part 5:
Registration of application providers.
Second edition: 2004.
ISO/IEC 7816-6 Identification cards – Integrated circuit cards – Part 6:
Interindustry data elements for interchange, 2004 +
Technical Corrigendum 1: 2006
ISO/IEC 8824-1 Information technology – Abstract Syntax Notation
One (ASN.1): Specification of basic notation. 2008 +
Technical Corrigendum 1: 2012 and Technical Corri­
gendum 2: 2014.
ISO/IEC 8825-2 Information technology – ASN.1 encoding rules:
Specification of Packed Encoding Rules (PER). 2008.
ISO/IEC 8859-1 Information technology – 8 bit single-byte coded
graphic character sets – Part 1: Latin alphabet No.1.
First edition: 1998.
ISO/IEC 8859-7 Information technology – 8 bit single-byte coded
graphic character sets – Part 7: Latin/Greek alphabet.
2003.
ISO 16844-3 Road vehicles – Tachograph systems – Motion
Sensor Interface. 2004 + Technical Corrigendum 1:
2006.
TR-03110-3 BSI / ANSSI Technical Guideline TR-03110-3,
Advanced Security Mechanisms for Machine
Readable Travel Documents and eIDAS Token –
Part 3 Common Specifications, version 2.20, 3.
February 2015
2. DEFINICE DATOVÝCH TYPŮ
▼M3
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 napl­
ně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 apli­
kace 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“.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 123
2.1 ActivityChangeInfo
Tento datový typ umožňuje kódovat uvnitř dvoubajtového slova status
otvoru pro kartu v 00:00 a/nebo status řidiče v 00:00 a/nebo změny
činnosti a/nebo změny statusu řízení a/nebo změny statusu karty, a to
pro řidiče nebo druhého řidiče. Tento datový typ se vztahuje k poža­
davkům 105, 266, 291, 320, 321, 343 a 344 přílohy 1C.
Přiřazení hodnoty – oktetové uspořádání: „scpaattttttttttt“B (16 bitů)
Pro záznamy v paměti údajů (nebo status otvoru pro kartu):
„s“B otvor pro kartu:
„0“B: ŘIDIČ,
„1“B: DRUHÝ ŘIDIČ,
„c“B status řízení vozidla:
„0“B: SAMOTNÝ ŘIDIČ,
„1“B: POSÁDKA,
„p“B status karty řidiče (nebo karty dílny) v příslušném otvoru
pro kartu:
„0“B: VLOŽENA, karta je vložena,
„1“B: NEVLOŽENA, není vložena žádná karta (nebo je
karta vyjmuta),
„aa“B činnost:
„00“B: PŘESTÁVKA/ODPOČINEK,
„01“B: POHOTOVOST,
„10“B: PRÁCE,
„11“B: ŘÍZENÍ,
„ttttttttttt“B čas změny: počet minut od 00h00 daného dne.
Pro záznamy na kartě řidiče (nebo kartě dílny) (a status řidiče):
„s“B otvor pro kartu (není relevantní, jestliže „p“=1, kromě
dále uvedené poznámky):
„0“B: ŘIDIČ,
„1“B: DRUHÝ ŘIDIČ,
„c“B status řízení (při „p“=0) nebo
následující status činnosti (při „p“=1):
„0“B: SAMOTNÝ ŘIDIČ,
„0“B: NEZNÁMÁ
„1“B: POSÁDKA,
„1“B: ZNÁMÁ (= ručně zadaná)
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 124
„p“B status karty:
„0“B: VLOŽENA, karta je vložena do záznamového zaří­
zení,
„1“B: NEVLOŽENA, karta není vložena (nebo je karta
vyjmuta),
„aa“B činnost (nepoužije se, jestliže „p“=1 a „c“=0, kromě
poznámky níže):
„00“B: PŘESTÁVKA/ODPOČINEK,
„01“B: POHOTOVOST,
„10“B: PRÁCE,
„11“B: ŘÍZENÍ,
„ttttttttttt“B čas změny: počet minut od 00h00 daného dne.
Poznámka pro případ „vyjmutí karty“:
Je-li karta vyjmuta:
— „s“ je relevantní a označuje otvor pro kartu, ze kterého je karta
vyjmuta,
— „c“ musí být nastaveno na 0,
— „p“ musí být nastaveno na 1,
— „aa“ musí kódovat aktuální činnost, která je v tu dobu navolena.
Jako výsledek ručního zadání mohou být bity „c“ a „aa“ slova (ulože­
ného na kartě) později přepsány s ohledem na toto zadání.
2.2 Address
Adresa.
codePage určuje znakovou sadu definovanou v kapitole 4.
address je adresa kódovaná za použití určené znakové sady.
2.3 AESKey
2. generace:
Klíč AES s délkou 128, 192 nebo 256 bitů.
Přiřazení hodnoty: není blíže specifikováno.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 125
2.4 AES128Key
2. generace:
Klíč AES128.
length udává délku klíče AES128 v oktetech.
aes128Key je klíč AES s délkou 128 bitů.
Přiřazení hodnoty:
Délka musí mít hodnotu 16.
2.5 AES192Key
2. generace:
Klíč AES192.
length udává délku klíče AES192 v oktetech.
aes192Key je klíč AES s délkou 192 bitů.
Přiřazení hodnoty:
Délka musí mít hodnotu 24.
2.6 AES256Key
2. generace:
Klíč AES256.
length udává délku klíče AES256 v oktetech.
aes256Key je klíč AES s délkou 256 bitů.
Přiřazení hodnoty:
Délka musí mít hodnotu 32.
2.7 BCDString
BCDString se použije pro vyjádření dekadických čísel binárním
kódem (BCD). Tento datový typ se použije k vyjádření jedné dekadické
číslice skupinou 4 bitů (poloviční oktet). BCDString je založen na typu
„CharacterStringType“ dle ISO/IEC 8824-1.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 126
BCDString používá notaci „hstring“. Vnější levá hexadecimální číslice
představuje nejvýznamnější 4 bity prvního oktetu. K získání více oktetů
se musí podle potřeby vložit od pozice levé vnější 4bitové skupiny
v prvním oktetu nulové 4bitové skupiny.
Přípustné číslice jsou: 0, 1, .. 9.
2.8 CalibrationPurpose
Kód k objasnění, proč byla zaznamenána sada kalibračních parametrů.
Tento datový typ se vztahuje k požadavkům 097 a 098 přílohy 1B a k
požadavku 119 přílohy 1C.
Přiřazení hodnoty:
1. generace:
„00“H vyhrazená hodnota,
„01“H aktivace: záznam známých kalibračních parametrů
v okamžiku aktivace celku ve vozidle,
„02“H první montáž: první kalibrace celku ve vozidle po
jeho aktivaci,
„03“H montáž: první kalibrace celku ve vozidle v aktu­
álním vozidle,
„04“H pravidelná kontrola.
2. generace:
Kromě hodnot 1. generace se používají tyto hodnoty:
„05“H zadání registrační značky vozidla (VRN) podnikem,
„06“H nastavení času bez kalibrace,
„07“H až „7F“H vyhrazeno pro budoucí použití,
„80“H až „FF“H specifické pro výrobce.
2.9 CardActivityDailyRecord
Informace uložené na kartě a vztahující se k činnostem řidiče po určitý
kalendářní den. Tento datový typ se vztahuje k požadavkům 266, 291,
320 a 343 přílohy 1C.
activityPreviousRecordLength je celková délka předchozího denního
záznamu v bajtech. Maximální hodnota je dána délkou řetězce OCTET
STRING obsahujícího tyto záznamy (viz CardActivityLengthRange,
dodatek 2 bod 4). Jestliže tento záznam je nejstarším denním záznamem,
musí být hodnota activityPreviousRecordLength nastavena na 0.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 127
activityRecordLength je celková délka tohoto záznamu v bajtech.
Maximální hodnota je dána délkou řetězce OCTET STRING obsahují­
cího tyto záznamy.
activityRecordDate je datum záznamu.
activityDailyPresenceCounter je stav počitadla dnů přítomnosti karty
v tento den.
activityDayDistance je celková vzdálenost ujetá toho dne.
activityChangeInfo je sada dat ActivityChangeInfo toho dne pro řidiče.
Může obsahovat maximálně 1 440 hodnot (jedna změna činnosti za
minutu). Tato sada vždy obsahuje údaj activityChangeInfo udávající
status řidiče v 00:00.
2.10 CardActivityLengthRange
Počet bajtů na kartě řidiče nebo kartě dílny, které jsou dostupné k uklá­
dání záznamů o činnosti řidiče.
Přiřazení hodnoty: viz dodatek 2.
2.11 CardApprovalNumber
Číslo schválení typu karty.
Přiřazení hodnoty:
Číslo schválení musí být uvedeno tak, jak bylo zveřejněno na přísluš­
ných webových stránkách Evropské komise, tj. např. včetně případných
spojovníků. Číslo schválení musí být zarovnáno doleva.
▼M3
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 aktualizova­
né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.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 128
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.
▼B
2.12 CardCertificate
1. generace:
Certifikát veřejného klíče karty.
2.13 CardChipIdentification
Informace uložené na kartě související s identifikací integrovaného
obvodu karty (IC) (požadavek 249 přílohy 1C). Číslo icSerialNumber
společně s číslem icManufacturingReferences jednoznačně identifikují
čip karty. Samotné číslo icSerialNumber není jednoznačnou identifikací
čipu karty.
icSerialNumber je výrobní číslo integrovaného obvodu.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 129
icManufacturingReferences je identifikátor specifický pro výrobce inte­
grovaného obvodu.
2.14 CardConsecutiveIndex
Pořadový index karty (definice h)).
Přiřazení hodnoty: (viz příloha 1C kapitola 7)
Posloupnost: „0, …, 9, A, …, Z, a, …, z“
2.15 CardControlActivityDataRecord
Informace uložené na kartě řidiče nebo kartě dílny týkající se poslední
kontroly, které byl řidič podroben (požadavky 274, 299, 327 a 350
přílohy 1C).
controlType je typ kontroly.
controlTime je datum a čas kontroly.
controlCardNumber je FullCardNumber kontrolora, který provedl
kontrolu.
controlVehicleRegistration je registrační značka (VRN) a členský stát
registrace vozidla, ve kterém byla kontrola provedena.
controlDownloadPeriodBegin a controlDownloadPeriodEnd je
stažené období v případě stahování dat.
2.16 CardCurrentUse
Informace o aktuálním použití karty (požadavky 273, 298, 326 a 349
přílohy 1C).
sessionOpenTime je čas, kdy je karta vložena pro aktuální použití.
Tento prvek se nastavuje na nulu při vyjmutí karty.
sessionOpenVehicle je identifikace aktuálně používaného vozidla, nasta­
vuje se při vložení karty. Tento prvek se nastavuje na nulu při vyjmutí
karty.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 130
2.17 CardDriverActivity
Informace uložené na kartě řidiče nebo kartě dílny týkající se činností
řidiče (požadavky 267, 268, 292, 293, 321 a 344 přílohy 1C).
activityPointerOldestDayRecord je specifikace začátku paměťového
místa (počet bajtů od začátku řetězce) nejstaršího úplného denního
záznamu v řetězci activityDailyRecords. Maximální hodnota je dána
délkou řetězce.
activityPointerNewestRecord je specifikace začátku paměťového místa
(počet bajtů od začátku řetězce) nejnovějšího denního záznamu v řetězci
activityDailyRecords. Maximální hodnota je dána délkou řetězce.
activityDailyRecords je prostor určený k ukládání dat o činnosti řidiče
(datová struktura: CardActivityDailyRecord) pro každý kalendářní den,
kdy byla karta použita.
Přiřazení hodnoty: tento oktetový řetězec je cyklicky plněn záznamy
CardActivityDailyRecord. Při prvním použití se začíná ukládat od
prvního bajtu řetězce. Každý nový záznam se připojuje za konec před­
chozího. Když je řetězec plný, ukládání pokračuje prvním bajtem řetězce
nehledě na přerušení, které vznikne uvnitř datového prvku. Předtím, než
jsou do řetězce uložena nová data o činnosti (zvětšení aktuálního
záznamu activityDailyRecord nebo uložení nového záznamu activityDa­
ilyRecord), která nahrazují starší data o činnosti, musí být aktualizován
ukazatel activityPointerOldestDayRecord, aby odrážel nové umístění
nejstaršího úplného denního záznamu, a délka activityPreviousRecord­
Length tohoto (nového) nejstaršího úplného denního záznamu musí být
nastavena na 0.
2.18 CardDrivingLicenceInformation
Informace uložené na kartě řidiče týkající se údajů o řidičském průkazu
držitele karty (požadavky 259 a 284 přílohy 1C).
drivingLicenceIssuingAuthority je orgán odpovědný za vydání řidič­
ského průkazu.
drivingLicenceIssuingNation je stát orgánu, který vydal řidičský
průkaz.
drivingLicenceNumber je číslo řidičského průkazu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 131
2.19 CardEventData
1. generace:
Informace uložené na kartě řidiče nebo kartě dílny týkající se událostí
souvisejících s držitelem karty (příloha IC požadavky 260 a 318).
CardEventData je posloupnost záznamů cardEventRecords seřazená
vzestupně podle hodnot EventFaultType (kromě záznamů souvisejících
s pokusy o narušení zabezpečení, které jsou seskupeny v poslední sadě
v posloupnosti).
cardEventRecords je sada záznamů o událostech daného typu (nebo
kategorie v případě pokusů o narušení zabezpečení).
2. generace:
Informace uložené na kartě řidiče nebo kartě dílny týkající se událostí
souvisejících s držitelem karty (příloha IC požadavky 285 a 341).
CardEventData je posloupnost záznamů cardEventRecords seřazená
vzestupně podle hodnot EventFaultType (kromě záznamů souvisejících
s pokusy o narušení zabezpečení, které jsou seskupeny v poslední sadě
v posloupnosti).
cardEventRecords je sada záznamů o událostech daného typu (nebo
kategorie v případě pokusů o narušení zabezpečení)
▼B
2.20 CardEventRecord
Informace uložené na kartě řidiče nebo kartě dílny týkající se události
související s držitelem karty (požadavky 261, 286, 318 a 341 přílohy
1C).
eventType je typ události.
eventBeginTime je datum a čas začátku události.
eventEndTime je datum a čas konce události.
eventVehicleRegistration je registrační značka (VRN) a členský stát
registrace vozidla, ve kterém událost nastala.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 132
2.21 CardFaultData
Informace uložené na kartě řidiče nebo kartě dílny týkající se závad
souvisejících s držitelem karty (požadavky 263, 288, 318 a 341 přílohy
1C).
CardFaultData je posloupnost sad záznamů o závadách záznamového
zařízení následovaná sadou záznamů o závadách karty.
cardFaultRecords je sada záznamů o závadách patřících do určité kate­
gorie závad (záznamové zařízení nebo karta).
2.22 CardFaultRecord
Informace uložené na kartě řidiče nebo kartě dílny týkající se závady
související s držitelem karty (požadavky 264, 289, 318 a 341 přílohy
1C).
faultType je typ závady.
faultBeginTime je datum a čas začátku závady.
faultEndTime je datum a čas konce závady.
faultVehicleRegistration je registrační značka (VRN) a členský stát
registrace vozidla, ve kterém závada nastala.
2.23 CardIccIdentification
Informace uložené na kartě týkající se identifikace karty s integrovaným
obvodem (požadavek 248 přílohy 1C).
clockStop je režim Clockstop dle dodatku 2.
cardExtendedSerialNumber je jedinečné výrobní číslo karty s integro­
vaným obvodem, dále specifikované datovým typem ExtendedSerial­
Number.
cardApprovalNumber je číslo schválení typu karty.
cardPersonaliserID je identifikátor personalizace karty kódovaný jako
ManufacturerCode.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 133
embedderIcAssemblerId uvádí informace o subjektu, který vkládá/
sestavuje integrovaný obvod.
icIdentifier je identifikátor integrovaného obvodu karty a jeho výrobce
dle ISO/IEC 7816-6.
2.24 CardIdentification
Informace uložené na kartě týkající se identifikace karty (požadavky
255, 280, 310, 333, 359, 365, 371 a 377 přílohy 1C).
cardIssuingMemberState je kód členského státu vydávajícího kartu.
cardNumber je číslo karty.
cardIssuingAuthorityName je název orgánu vydávajícího kartu.
cardIssueDate je datum vydání karty současnému držiteli.
cardValidityBegin je datum prvního dne platnosti karty.
cardExpiryDate je datum konce platnosti karty.
▼M3
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 aktualizova­
né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.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 134
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ža­
davky 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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 135
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.
▼B
2.25 CardMACertificate
2. generace:
Certifikát veřejného klíče karty pro vzájemné ověření pravosti s celkem
ve vozidle. Struktura tohoto certifikátu je specifikována v dodatku 11.
2.26 CardNumber
Číslo karty dle definice g).
driverIdentification je jednoznačná identifikace řidiče v členském státě.
ownerIdentification je jednoznačná identifikace podniku, dílny nebo
kontrolního orgánu v členském státě.
cardConsecutiveIndex je pořadový index karty.
cardReplacementIndex je index náhrady karty.
cardRenewalIndex je index obnovy karty.
První posloupnost ve výběru je vhodná ke kódování čísla karty řidiče,
druhá posloupnost ve výběru je vhodná ke kódování čísla karty dílny,
kontrolní karty a karty podniku.
▼M3
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).
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 136
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.
▼B
2.27 CardPlaceDailyWorkPeriod
Informace uložené na kartě řidiče nebo kartě dílny týkající se míst, kde
začíná nebo končí denní pracovní doba (požadavky 272, 297, 325 a 348
přílohy 1C).
placePointerNewestRecord je index naposledy aktualizovaného
záznamu o místě.
Přiřazení hodnoty: Číslo odpovídající čítači záznamů míst, začínající
„0“ pro první výskyt záznamu místa ve struktuře.
placeRecords je sada záznamů obsahující informace týkající se zada­
ných míst.
2.28 CardPrivateKey
1. generace:
Soukromý klíč karty.
2.29 CardPublicKey
Veřejný klíč karty.
▼M1
2.30 CardRenewalIndex
Index obnovy karty (definice i)).
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 137
Přiřazení hodnoty: (viz kapitolu 7 této přílohy).
„0“ První vydání.
Posloupnost: „0, …, 9, A, …, Z“
▼B
2.31 CardReplacementIndex
Index náhrady karty (definice j)).
Přiřazení hodnoty: (viz kapitolu VII této přílohy).
„0“ Původní karta.
Posloupnost: „0, …, 9, A, …, Z“
2.32 CardSignCertificate
2. generace:
Certifikát veřejného klíče karty pro podpis. Struktura tohoto certifikátu
je specifikována v dodatku 11.
2.33 CardSlotNumber
Kód pro rozlišení mezi dvěma otvory pro kartu v celku ve vozidle.
Přiřazení hodnoty: není blíže specifikováno.
2.34 CardSlotsStatus
Kód udávající typ karet vložených do dvou otvorů pro kartu v celku ve
vozidle.
Přiřazení hodnoty – oktetové uspořádání: „ccccdddd“B
„cccc“B identifikace typu karty vložené do otvoru pro kartu
druhého řidiče,
„dddd“B identifikace typu karty vložené do otvoru pro kartu
řidiče,
s těmito identifikačními kódy:
„0000“B není vložena žádná karta,
„0001“B je vložena karta řidiče,
„0010“B je vložena karta dílny,
„0011“B je vložena kontrolní karta,
„0100“B je vložena karta podniku.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 138
2.35 CardSlotsStatusRecordArray
2. generace:
CardSlotsStatus a metadata použitá v protokolu pro stahování.
recordType označuje typ záznamu (CardSlotsStatus). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu CardSlotsStatus v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů CardSlotsStatus.
2.36 CardStructureVersion
Kód udávající verzi implementované struktury v kartě tachografu.
Přiřazení hodnoty: „aabb“H:
„aa“H Index pro změny struktury.
„00“H pro aplikace 1. generace
„01“H pro aplikace 2. generace
▼M3
„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
▼B
2.37 CardVehicleRecord
Informace uložené na kartě řidiče nebo kartě dílny týkající se doby
používání vozidla během kalendářního dne (požadavky 269, 294, 322
a 345 přílohy 1C).
1. generace:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 139
vehicleOdometerBegin je hodnota počitadla ujetých kilometrů na
začátku doby používání vozidla.
vehicleOdometerEnd je hodnota počitadla ujetých kilometrů na konci
doby používání vozidla.
vehicleFirstUse je datum a čas začátku doby používání vozidla.
vehicleLastUse je datum a čas konce doby používání vozidla.
vehicleRegistration je registrační značka (VRN) a členský stát regis­
trace vozidla.
vuDataBlockCounter je hodnota VuDataBlockCounter při poslední
extrakci doby používání vozidla.
2. generace:
Kromě prvků 1. generace se použije tento datový prvek:
VehicleIdentificationNumber je identifikační číslo vozidla týkající se
vozidla jako celku.
2.38 CardVehiclesUsed
Informace uložené na kartě řidiče nebo kartě dílny týkající vozidel použ­
itých držitelem karty (požadavky 270, 295, 323 a 346 přílohy 1C).
vehiclePointerNewestRecord je index naposledy aktualizovaného
záznamu o vozidle.
Přiřazení hodnoty: Číslo odpovídající čítači záznamů o vozidlech začí­
nající hodnotou „0“ pro první výskyt záznamu o vozidle ve struktuře.
cardVehicleRecords je sada záznamů obsahující informace o použitých
vozidlech.
2.39 CardVehicleUnitRecord
2. generace:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 140
Informace uložené na kartě řidiče nebo kartě dílny týkající se celku ve
vozidle, který byl použit (požadavky 303 a 351 přílohy 1C).
timeStamp je začátek doby používání celku ve vozidle (tj. první vložení
karty do celku ve vozidle pro dané období).
manufacturerCode označuje výrobce celku ve vozidle.
deviceID označuje typ celku ve vozidle od daného výrobce. Jedná se
o hodnotu specifickou pro výrobce.
vuSoftwareVersion je číslo verze softwaru v celku ve vozidle.
2.40 CardVehicleUnitsUsed
▼M3
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).
▼B
vehicleUnitPointerNewestRecord je index naposledy aktualizovaného
záznamu o celku ve vozidle.
Přiřazení hodnoty: Číslo odpovídající čítači záznamů o celku ve
vozidle, začínající hodnotou „0“ pro první výskyt záznamů o celku ve
vozidle ve struktuře.
cardVehicleUnitRecords je sada záznamů obsahující informace o použ­
itých celcích ve vozidle.
2.41 Certificate
Certifikát veřejného klíče vydaný certifikační autoritou.
1. generace:
Přiřazení hodnoty: digitální podpis s částečnou obnovou Certificate­
Content podle dodatku 11 „Společné bezpečnostní mechanismy“: podpis
(128 bajtů) || zbytek veřejného klíče (58 bajtů) || odkaz na certifikační
autoritu (8 bajtů).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 141
2. generace:
Přiřazení hodnoty: viz dodatek 11
2.42 CertificateContent
1. generace:
(Nešifrovaný) obsah certifikátu veřejného klíče podle dodatku 11
„Společné bezpečnostní mechanismy“.
certificateProfileIdentifier je verze odpovídajícího certifikátu.
Přiřazení hodnoty: „01h“ pro tuto verzi.
certificationAuthorityReference identifikuje certifikační autoritu vydá­
vající certifikát. Současně odkazuje na veřejný klíč této certifikační
autority.
certificateHolderAuthorisation identifikuje práva držitele certifikátu.
certificateEndOfValidity je datum, kdy končí administrativní platnost
certifikátu.
certificateHolderReference identifikuje držitele certifikátu. Zároveň
odkazuje na jeho veřejný klíč.
publicKey je veřejný klíč, který je certifikován tímto certifikátem.
2.43 CertificateHolderAuthorisation
Identifikace práv držitele certifikátu.
1. generace:
tachographApplicationID je identifikátor aplikace pro aplikaci
tachografu.
Přiřazení hodnoty: „FFh“ „54h“ „41h“ „43h“ „48h“ „4Fh“. Tento AID
je proprietární neregistrovaný identifikátor aplikace v souladu s ISO/IEC
7816-5.
equipmentType je identifikace typu zařízení, pro které je certifikát
určen.
Přiřazení hodnoty: ve shodě s datovým typem EquipmentType. 0, jest­
liže se jedná o certifikát členského státu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 142
2. generace:
tachographApplicationID označuje 6 nejvýznamnějších bajtů identifi­
kátoru aplikace (AID) karty tachografu 2. generace. AID pro aplikaci
karty tachografu je uveden v kapitole 6.2.
Přiřazení hodnoty: „FF 53 4D 52 44 54“.
equipmentType je identifikace typu zařízení, jak je specifikováno pro 2.
generaci, pro něž je certifikát určen.
Přiřazení hodnoty: ve shodě s datovým typem EquipmentType.
2.44 CertificateRequestID
Jednoznačná identifikace žádosti o certifikát. Může být použita také jako
identifikátor veřejného klíče celku ve vozidle, jestliže výrobní číslo
celku ve vozidle, pro který je klíč určen, není známo v době vystavení
certifikátu.
requestSerialNumber je sériové číslo žádosti o certifikát, jednoznačné
pro výrobce a níže uvedený měsíc.
requestMonthYear je identifikace měsíce a roku žádosti o certifikát.
Přiřazení hodnoty: BCD kód měsíce (dvě číslice) a roku (poslední dvě
číslice).
crIdentifier: je identifikátor k odlišení žádosti o certifikát od rozšíře­
ného výrobního čísla.
Přiřazení hodnoty: „FFh“.
manufacturerCode: je číselný kód výrobce žádajícího o certifikát.
2.45 CertificationAuthorityKID
Identifikátor veřejného klíče certifikační autority (členského státu nebo
Evropského certifikačního úřadu).
nationNumeric je číselný kód státu certifikační autority.
nationAlpha je alfanumerický kód státu certifikační autority.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 143
keySerialNumber je sériové číslo k odlišení různých klíčů certifikační
autority v případě, že se klíče změní.
additionalInfo je dvoubajtové pole pro dodatečné kódování (specifické
pro certifikační autoritu).
caIdentifier je identifikátor k odlišení identifikátoru klíče certifikační
autority od jiných identifikátorů klíčů.
Přiřazení hodnoty: „01h“.
2.46 CompanyActivityData
Informace uložené na kartě podniku týkající se činností vykonaných
s kartou (požadavky 373 a 379 přílohy 1C).
companyPointerNewestRecord je index naposledy aktualizovaného
záznamu companyActivityRecord.
Přiřazení hodnoty: Číslo odpovídající čítači záznamů o činnosti
podniku, začínající „0“ pro první výskyt záznamu o činnosti podniku
ve struktuře.
companyActivityRecords je sada všech záznamů o činnosti podniku.
companyActivityRecord je posloupnost informací vztahujících se
k jedné činnosti podniku.
companyActivityType je typ činnosti podniku.
companyActivityTime je datum a čas činnosti podniku.
cardNumberInformation je číslo karty a členský stát vydávající kartu,
z které jsou stažena data (v příslušných případech).
vehicleRegistrationInformation je registrační značka (VRN) a členský
stát registrace vozidla, jehož data jsou stažena, zablokována nebo odblo­
kována.
downloadPeriodBegin a downloadPeriodEnd je případné období, za
něž byla z celku ve vozidle stažena data.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 144
2.47 CompanyActivityType
Kód udávající činnost vykonávanou podnikem s použitím jeho karty
podniku.
2.48 CompanyCardApplicationIdentification
Informace uložené na kartě podniku týkající se identifikace aplikace
karty (požadavky 369 a 375 přílohy 1C).
typeOfTachographCardId udává implementovaný typ karty.
cardStructureVersion udává verzi struktury implementované v kartě.
noOfCompanyActivityRecords je počet záznamů o činnosti podniku,
které lze na kartu uložit.
▼M3
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.
▼B
2.49 CompanyCardHolderIdentification
Informace uložené na kartě podniku týkající se identifikace držitele karty
(požadavky 372 a 378 přílohy 1C).
companyName je jméno podniku – držitele.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 145
companyAddress je adresa podniku – držitele.
cardHolderPreferredLanguage je upřednostňovaný jazyk držitele
karty.
2.50 ControlCardApplicationIdentification
Informace uložené na kontrolní kartě týkající se identifikace aplikace
karty (požadavky 357 a 363 přílohy 1C).
typeOfTachographCardId udává implementovaný typ karty.
cardStructureVersion udává verzi struktury implementované v kartě.
noOfControlActivityRecords je počet záznamů o kontrolní činnosti,
které lze na kartu uložit.
▼M3
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.
▼B
2.51 ControlCardControlActivityData
Informace uložené na kontrolní kartě týkající se kontrolní činnosti vyko­
nané s kartou (požadavky 361 a 367 přílohy 1C).
controlPointerNewestRecord je index naposledy aktualizovaného
záznamu o kontrolní činnosti.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 146
Přiřazení hodnoty: Číslo odpovídající čítači záznamů o kontrolní
činnosti., začínající „0“ pro první výskyt záznamu o kontrolní činnosti
ve struktuře.
controlActivityRecords je sada všech záznamů o kontrolní činnosti.
controlActivityRecord je posloupnost informací vztahujících se k jedné
kontrole.
controlType je typ kontroly.
controlTime je datum a čas kontroly.
controlledCardNumber je číslo kontrolované karty a členský stát, který
ji vydal.
controlledVehicleRegistration je registrační značka (VRN) a členský
stát registrace vozidla, v kterém byla kontrola provedena.
controlDownloadPeriodBegin a controlDownloadPeriodEnd je
období, za které byla případně stažena data.
2.52 ControlCardHolderIdentification
Informace uložené na kontrolní kartě týkající se identifikace držitele
karty (požadavky 360 a 366 přílohy 1C).
controlBodyName je název kontrolního orgánu držitele karty.
controlBodyAddress je adresa kontrolního orgánu držitele karty.
cardHolderName je příjmení a jméno (jména) držitele kontrolní karty.
cardHolderPreferredLanguage je upřednostňovaný jazyk držitele
karty.
2.53 ControlType
Kód udávající činnosti provedené během kontroly. Tento datový typ se
vztahuje k požadavkům 126, 274, 299, 327 a 350 přílohy 1C.
1. generace:
Přiřazení hodnoty – oktetové uspořádání: „cvpdxxxx“B (8 bitů)
„c“B stahování dat z karty:
„0“B: při této kontrolní činnosti nebyla stažena data
z karty,
„1“B: při této kontrolní činnosti byla stažena data z karty
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 147
„v“B stahování dat z celku ve vozidle:
„0“B: při této kontrolní činnosti nebyla stažena data
z celku ve vozidle,
„1“B: při této kontrolní činnosti byla stažena data
z celku ve vozidle
„p“B tisk:
„0“B: při této kontrolní činnosti se netisklo,
„1“B: při této kontrolní činnosti se tisklo
„d“B zobrazení:
„0“B: při této kontrolní činnosti nebylo použito zobra­
zení,
„1“B: při této kontrolní činnosti bylo použito zobrazení
„xxxx“B nepoužito.
2. generace:
Přiřazení hodnoty – oktetové uspořádání: „cvpdexxx“B (8 bitů)
„c“B stahování dat z karty:
„0“B: při této kontrolní činnosti nebyla stažena data
z karty,
„1“B: při této kontrolní činnosti byla stažena data
z karty
„v“B stahování dat z celku ve vozidle:
„0“B: při této kontrolní činnosti nebyla stažena data
z celku ve vozidle,
„1“B: při této kontrolní činnosti byla stažena data
z celku ve vozidle
„p“B tisk:
„0“B: při této kontrolní činnosti se netisklo,
„1“B: při této kontrolní činnosti se tisklo
„d“B zobrazení:
„0“B: při této kontrolní činnosti nebylo použito zobra­
zení,
„1“B: při této kontrolní činnosti bylo použito zobrazení
„e“B silniční kontrola kalibrace:
„0“B: pří této kontrolní činnosti nebyly kontrolovány
kalibrační parametry,
„1“B: pří této kontrolní činnosti byly kontrolovány kali­
brační parametry
„xxx“B vyhrazeno pro budoucí použití.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 148
2.54 CurrentDateTime
Aktuální datum a čas záznamového zařízení.
Přiřazení hodnoty: není blíže specifikováno.
2.55 CurrentDateTimeRecordArray
2. generace:
Aktuální datum a čas a metadata použitá v protokolu pro stahování.
recordType označuje typ záznamu (CurrentDateTime). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu CurrentDateTime v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů aktuálního data a času.
2.56 DailyPresenceCounter
Čítač uložený v kartě řidiče nebo kartě dílny, který se zvýší o jedničku
za každý kalendářní den, kdy byla karta vložena v celku ve vozidle.
Tento datový typ se vztahuje k požadavkům 266, 299, 320 a 343 přílohy
1C.
Přiřazení hodnoty: Pořadové číslo s maximální hodnotou = 9 999,
začínající od 0. V okamžiku prvního vydání karty se číslo nastavuje
na 0.
2.57 Datef
Datum vyjádřené v číselném tvaru, který lze snadno tisknout.
Přiřazení hodnoty:
yyyy rok
mm měsíc
dd den
„00000000“H explicitně označuje „žádné datum“.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 149
2.58 DateOfDayDownloaded
2. generace:
Datum a čas stahování.
Přiřazení hodnoty: není blíže specifikováno.
2.59 DateOfDayDownloadedRecordArray
2. generace:
Datum a čas stahování a metadata použitá v protokolu pro stahování.
recordType označuje typ záznamu (DateOfDayDownloaded). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu CurrentDateTime v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o datu a čase stahování.
2.60 Distance
Ujetá vzdálenost (výsledek rozdílu mezi dvěma hodnotami počitadla
ujetých kilometrů).
Přiřazení hodnoty: Binární číslo bez znaménka. Hodnota v km v provo­
zním rozsahu 0 až 9 999 km.
▼M3
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.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 150
2.61 DriverCardApplicationIdentification
Informace uložené na kartě řidiče týkající se identifikace aplikace karty
(požadavky 253 a 278 přílohy 1C).
1. generace:
typeOfTachographCardId udává implementovaný typ karty.
cardStructureVersion udává verzi struktury implementované v kartě.
noOfEventsPerType je počet událostí od každého typu události, které
lze na kartu zaznamenat.
noOfFaultsPerType je počet závad od každého druhu závady, které lze
na kartu zaznamenat.
activityStructureLength udává počet bajtů, které jsou k dispozici pro
ukládání záznamů o činnosti.
noOfCardVehicleRecords je počet záznamů o vozidle, které může karta
obsahovat.
noOfCardPlaceRecords je počet míst, která lze na kartu zaznamenat.
2. generace:
▼M1
Kromě prvků 1. generace se používají tyto datové prvky:
noOfGNSSADRecords je počet záznamů o součtové době řízení dle
GNSS, které lze na kartu uložit.
noOfSpecificConditionRecords je počet záznamů o zvláštní podmínce,
které lze na kartu uložit.
noOfCardVehicleUnitRecords je počet záznamů o použitých celcích ve
vozidle, které lze na kartu uložit.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 151
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.
▼B
2.62 DriverCardHolderIdentification
Informace uložené na kartě řidiče týkající se identifikace držitele karty
(požadavky 256 a 281 přílohy 1C).
cardHolderName je příjmení a jméno (jména) držitele karty řidiče.
cardHolderBirthDate je datum narození držitele karty řidiče.
cardHolderPreferredLanguage je upřednostňovaný jazyk držitele
karty.
▼M3
2.63 DSRCSecurityData
2. generace:
Definice tohoto datového typu viz dodatek 11.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 152
2.64 EGFCertificate
2. generace:
Certifikát veřejného klíče vnějšího zařízení GNSS pro vzájemné ověření
pravosti s celkem ve vozidle. Struktura tohoto certifikátu je specifiko­
vána v dodatku 11.
2.65 EmbedderIcAssemblerId
Poskytuje informace o subjektu, který vkládá integrovaný obvod.
countryCode je dvoupísmenný kód země subjektu, který vkládá modul,
podle ISO 3166.
moduleEmbedder označuje subjekt, který vkládá modul.
manufacturerInformation slouží pro interní použití výrobcem.
2.66 EntryTypeDailyWorkPeriod
Kód k rozlišení mezi začátkem a koncem při zadání denní pracovní
doby a podmínek zadání.
1. generace
Přiřazení hodnoty: dle ISO/IEC 8824-1.
▼M3
2. generace
Přiřazení hodnoty: dle ISO/IEC 8824-1.
▼B
2.67 EquipmentType
Kód k rozlišení různých typů zařízení pro aplikaci tachografu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 153
1. generace:
Přiřazení hodnoty: dle ISO/IEC 8824-1.
Hodnota 0 je vyhrazena pro účely označení členského státu nebo Evropy
v poli CHA certifikátů.
2. generace:
▼M1
Používají se stejné hodnoty jako v 1. generaci s těmito doplňky:
Poznámka 1: Hodnoty 2. generace pro štítek, adaptér a vnější připojení
GNSS, jakož i hodnoty 1. generace pro celek ve vozidle a snímač
pohybu lze v příslušných případech použít v záznamu SealRecord.
Poznámka 2: V poli CardHolderAuthorisation (CHA) certifikátu 2.
generace se hodnoty (1), (2) a (6) vykládají jako hodnoty označující
certifikát pro vzájemné ověření pravosti pro příslušný typ zařízení.
K označení příslušného certifikátu pro vytvoření digitálního podpisu se
musí použít hodnoty (17), (18) nebo (19).
▼B
2.68 EuropeanPublicKey
1. generace:
Evropský veřejný klíč.
2.69 EventFaultRecordPurpose
Kód vysvětlující, proč byla událost nebo závada zaznamenána.
Přiřazení hodnoty:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 154
jedna z 10 nejnovějších (nebo posledních) událostí nebo závad
nejdelší událost v jednom z posledních 10 dnů výskytu
jedna z 5 nejdelších událostí za posledních 365 dnů
poslední událost v jednom z posledních 10 dnů výskytu
nejzávažnější událost v jednom z posledních 10 dnů výskytu
jedna z 5 nejzávažnějších událostí za posledních 365 dnů
první událost nebo závada od poslední kalibrace
aktivní/trvající událost nebo závada
vyhrazeno pro budoucí použití
specifické pro výrobce
2.70 EventFaultType
Kód blíže určující událost nebo závadu.
Přiřazení hodnoty:
1. generace:
všeobecné události,
žádné další podrobnosti,
vložení neplatné karty,
konflikt karet,
časový přesah,
jízda bez náležité karty,
vložení karty během řízení,
poslední relace karty nebyla korektně uzavřena,
překročení povolené rychlosti,
přerušení napájení,
chyba údajů o pohybu vozidla,
nesoulad údajů o pohybu vozidla,
vyhrazeno pro budoucí použití,
události pokusů o narušení zabezpečení souvisejících s celkem ve vozidle,
žádné další podrobnosti,
chyba ověření pravosti snímače pohybu,
chyba ověření pravosti karty tachografu,
neoprávněná výměna snímače pohybu,
chyba integrity vstupních dat karty,
chyba integrity uložených uživatelských dat,
vnitřní chyba přenosu dat,
neoprávněné otevření krytu,
poškození technického vybavení,
vyhrazeno pro budoucí použití,
události pokusů o narušení zabezpečení souvisejících se snímačem,
žádné další podrobnosti,
chyba ověření pravosti,
chyba integrity uložených dat,
vnitřní chyba přenosu dat,
neoprávněné otevření krytu,
poškození technického vybavení,
vyhrazeno pro budoucí použití,
závady záznamového zařízení,
žádné další podrobnosti,
interní závada celku ve vozidle,
závada tiskárny,
závada displeje,
závada stahování,
závada snímače,
vyhrazeno pro budoucí použití,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 155
závady karty,
žádné další podrobnosti,
vyhrazeno pro budoucí použití,
vyhrazeno pro budoucí použití,
specifické pro výrobce.
▼M3
2. generace, verze 1:
▼M1 všeobecné události,
žádné další podrobnosti,
vložení neplatné karty,
konflikt karet,
časový přesah,
jízda bez náležité karty,
vložení karty během řízení,
poslední relace karty nebyla korektně uzavřena,
překročení povolené rychlosti,
přerušení napájení,
chyba údajů o pohybu vozidla,
nesoulad údajů o pohybu vozidla,
časový nesoulad (GNSS vůči vnitřním hodinám VU),
chyba komunikace se zařízením pro dálkovou komunikaci,
chybí informace o poloze z přijímače GNSS,
chyba komunikace s vnějším zařízením GNSS,
vyhrazeno pro budoucí použití,
události pokusů o narušení zabezpečení souvisejících s celkem ve vozidle,
žádné další podrobnosti,
chyba ověření pravosti snímače pohybu,
chyba ověření pravosti karty tachografu,
neoprávněná výměna snímače pohybu,
chyba integrity vstupních dat karty,
chyba integrity uložených uživatelských dat,
vnitřní chyba přenosu dat,
neoprávněné otevření krytu,
poškození technického vybavení,
detekce nedovolené manipulace s GNSS,
chyba ověření pravosti vnějšího zařízení GNSS,
skončila platnost certifikátu vnějšího zařízení GNSS,
vyhrazeno pro budoucí použití,
události pokusů o narušení zabezpečení souvisejících se snímačem,
žádné další podrobnosti,
chyba ověření pravosti,
chyba integrity uložených dat,
vnitřní chyba přenosu dat,
neoprávněné otevření krytu,
poškození technického vybavení,
vyhrazeno pro budoucí použití,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 156
závady záznamového zařízení,
žádné další podrobnosti,
interní závada celku ve vozidle,
závada tiskárny,
závada displeje,
závada stahování,
závada snímače,
vnitřní přijímač GNSS,
vnější zařízení GNSS,
zařízení pro dálkovou komunikaci,
rozhraní ITS,
vyhrazeno pro budoucí použití,
závady karty,
žádné další podrobnosti,
vyhrazeno pro budoucí použití,
vyhrazeno pro budoucí použití,
specifické pro výrobce.
▼M3 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,
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 157
„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,
„20“H žádné další podrobnosti,
„21“H chyba ověření pravosti,
„22“H chyba integrity uložených dat,
„23“H vnitřní chyba přenosu dat,
„24“H neoprávněné otevření krytu,
„25“H poškození technického vybavení,
„26“H až „2F“H vyhrazeno pro budoucí použití,
„3x“H závady záznamového zařízení,
„30“H žádné další podrobnosti,
„31“H interní závada celku ve vozidle,
„32“H závada tiskárny,
„33“H závada displeje,
„34“H závada stahování,
„35“H závada snímače,
„36“H vnitřní přijímač GNSS,
„37“H vnější zařízení GNSS,
„38“H zařízení pro dálkovou komunikaci,
„39“H rozhraní ITS,
„3A“H závada snímače,
„3B“H až „3F“H vyhrazeno pro budoucí použití,
„4x“H závady karty,
„40“H žádné další podrobnosti,
„41“H až „4F“H vyhrazeno pro budoucí použití,
„50“H až „7F“H vyhrazeno pro budoucí použití,
„80“H až „FF“H specifické pro výrobce.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 158
2.71 ExtendedSealIdentifier
2. generace:
Rozšířený identifikátor plomby jednoznačně identifikuje plombu (poža­
davek 401 v příloze IC).
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].
▼B
2.72 ExtendedSerialNumber
Jednoznačná identifikace zařízení. Může také být použito jako identifi­
kátor veřejného klíče zařízení.
1. generace:
serialNumber je výrobní číslo zařízení, jednoznačné pro výrobce, typ
zařízení a dále uvedený měsíc a rok.
monthYear je identifikace měsíce a roku výroby (nebo přiřazení výrob­
ního čísla).
Přiřazení hodnoty: BCD kód měsíce (dvě číslice) a roku (poslední dvě
číslice).
type je identifikátor typu zařízení.
Přiřazení hodnoty: specifické pro výrobce, s vyhrazenou hodnotou
„FF“h.
manufacturerCode: je číselný kód výrobce typově schváleného zařízení.
2. generace:
serialNumber viz 1. generace
monthYear viz 1. generace
type je identifikátor typu zařízení
manufacturerCode: viz 1. generace.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 159
2.73 FullCardNumber
Kód plně identifikující kartu tachografu.
cardType je typ karty tachografu.
cardIssuingMemberState je kód členského státu, který kartu vydal.
cardNumber je číslo karty.
2.74 FullCardNumberAndGeneration
2. generace:
Kód plně identifikující kartu tachografu a její generaci.
fullcardNumber identifikuje kartu tachografu.
generation označuje generaci použité karty tachografu.
2.75 Generation
2. generace:
Označuje generaci použitého tachografu.
Přiřazení hodnoty:
„00“H vyhrazeno pro budoucí použití
„01“H 1. generace
„02“H 2. generace
„03“H .. „FF“H vyhrazeno pro budoucí použití
2.76 GeoCoordinates
▼M3
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).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 160
latitude je zeměpisná délka kódovaná jako desetinásobek reprezentace
±DDMM.M.
longitude je zeměpisná šířka kódovaná jako desetinásobek reprezentace
±DDDMM.M.
2.77 GNSSAccuracy
2. generace:
Přesnost údajů o poloze z GNSS (definice eee)). Tato přesnost je kódo­
vána jako celé číslo a je desetinásobkem hodnoty X.Y z věty GSA
NMEA.
▼M1
2.78 GNSSAccumulatedDriving
2. generace:
Informace uložené na kartě řidiče nebo kartě dílny týkající se polohy
vozidla dle GNSS, pokud součtová doba řízení dosáhne násobku tří
hodin (příloha IC požadavky 306 a 354).
gnssADPointerNewestRecord je index naposledy aktualizovaného
záznamu o součtové době řízení dle GNSS.
Přiřazení hodnoty je číslo odpovídající čítači záznamů o součtové době
řízení dle GNSS, začínající hodnotou ‘0’ pro první výskyt záznamu
o součtové době řízení dle GNSS ve struktuře.
gnssAccumulatedDrivingRecords je sada záznamů obsahujících datum
a čas, kdy součtová doba řízení dosáhne násobku tří hodin, a informace
o poloze vozidla.
2.79 GNSSAccumulatedDrivingRecord
2. generace:
Informace uložené na kartě řidiče nebo kartě dílny týkající se polohy
vozidla dle GNSS, pokud součtová doba řízení dosáhne násobku tří
hodin (příloha IC požadavky 305 a 353).
timeStamp je datum a čas, kdy součtová doba řízení dosáhne násobku
tří hodin.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 161
gnssPlaceRecord obsahuje informace týkající se polohy vozidla.
vehicleOdometerValue je stav počitadla ujetých kilometrů, kdy
součtová doba řízení dosáhne násobku tří hodin.
▼M3
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ída­
jícím GNSSAccumulatedDrivingRecord).
authenticationStatus je status ověření pravosti polohy dle GNSS, když
součtová doba řízení dosáhne násobku tří hodin.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 162
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.
▼B
2.80 GNSSPlaceRecord
2. generace:
Informace týkající se polohy vozidla dle GNSS (požadavky 108, 109,
110, 296, 305, 347 a 353 přílohy 1C).
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.
2.81 HighResOdometer
Hodnota počitadla ujetých kilometrů vozidla: celková vzdálenost ujetá
vozidlem během jeho provozu.
Přiřazení hodnoty: Binární číslo bez znaménka. Hodnota v 1/200 km
v provozním rozsahu 0 až 21 055 406 km.
2.82 HighResTripDistance
Vzdálenost ujetá během cesty nebo její části.
Přiřazení hodnoty: Binární číslo bez znaménka. Hodnota v 1/200 km
v provozním rozsahu 0 až 21 055 406 km.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 163
2.83 HolderName
Příjmení a jméno (jména) držitele karty.
holderSurname je příjmení držitele. Toto příjmení neobsahuje tituly.
Přiřazení hodnoty: Jestliže karta není osobní, obsahuje holderSurname
stejné informace jako companyName, workshopName nebo controlBo­
dyName.
holderFirstNames jsou jméno (jména) a iniciály držitele.
▼M3
2.84 Vyhrazeno pro budoucí použití
▼B
2. generace:
Informace, zda je přijímač GNSS vnitřní nebo vnější vůči celku ve
vozidle. Hodnota „true“ znamená, že přijímač GNSS je interní částí
VU. Hodnota „false“ znamená, že přijímač GNSS je vnější.
2.85 K-ConstantOfRecordingEquipment
Konstanta záznamového zařízení (definice m)).
Přiřazení hodnoty: impulsy na kilometr v provozním rozsahu 0 až
64 255 impulsů/km.
▼M1
2.86 KeyIdentifier
Jednoznačný identifikátor veřejného klíče použitý k odkazu na klíč
a výběru klíče. Rovněž identifikuje držitele klíče.
První volba je vhodná k odkazu na veřejný klíč celku ve vozidle, karty
tachografu nebo vnějšího zařízení GNSS.
Druhá volba je vhodná k odkazu na veřejný klíč celku ve vozidle (pokud
výrobní číslo celku ve vozidle není známo v době vystavení certifikátu).
Třetí volba je vhodná k odkazu na veřejný klíč členského státu.
▼B
2.87 KMWCKey
2. generace:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 164
Klíč AES a jeho příslušná verze používané pro párování celku ve vozidle
se snímačem pohybu. Podrobnosti viz dodatek 11.
kMWCKey je délka klíče AES zřetězená s klíčem, který se používá pro
párování celku ve vozidle se snímačem pohybu.
keyVersion označuje verzi klíče AES.
2.88 Language
Kód identifikující jazyk.
Přiřazení hodnoty: Dvě malá písmena kódovaná dle ISO 639.
2.89 LastCardDownload
Datum a čas, uložené na kartě řidiče, posledního stažení dat z karty (pro
jiné účely než pro kontrolu) – požadavky 257 a 282 přílohy 1C. Toto
datum může být aktualizováno celkem ve vozidle nebo libovolnou
čtečkou karet.
Přiřazení hodnoty: není blíže specifikováno.
▼M3
2.89a LengthOfFollowingData
2. generace, verze 2:
Ukazatel délky pro rozšiřitelné záznamy.
Přiřazení hodnoty: Viz dodatek 2.
▼B
2.90 LinkCertificate
2. generace:
Spojovací certifikát mezi páry klíčů evropského kořenového certifikač­
ního úřadu.
▼M3
2.90a LoadType
2. generace, verze 2:
Kód označující zadaný druh nákladu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 165
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í.
▼B
2.91 L-TyreCircumference
Účinný obvod pneumatik na kolech (definice u)).
Přiřazení hodnoty: Binární číslo bez znaménka, hodnota v 1/8 mm
v provozním rozsahu 0 až 8 031 mm.
▼M1
2.92 MAC
2. generace:
Kryptografický kontrolní součet délky 8, 12 nebo 16 bajtů odpovídající
sadám šifer uvedeným v dodatku 11.
▼B
2.93 ManualInputFlag
Kód udávající, zda držitel karty ručně zadal činnosti řidiče při vložení
karty, či nikoliv (požadavek 081 přílohy 1B a požadavek 102 přílohy
1C).
Přiřazení hodnoty: není blíže specifikováno.
2.94 ManufacturerCode
Kód identifikující výrobce typově schváleného zařízení.
Zkušebna příslušná pro provádění zkoušek interoperability vede a zveřej­
ňuje seznam kódů výrobců na svých webových stránkách (požadavek
454 přílohy 1C).
Kódy ManufacturerCode se předběžně přidělují vývojářům tachografo­
vých zařízení, když si podají žádost u zkušebny příslušné pro provádění
zkoušek interoperability.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 166
2.95 ManufacturerSpecificEventFaultData
2. generace:
Kódy chyb specifické pro výrobce zjednodušují analýzu chyb a údržbu
celků ve vozidle.
manufacturerCode označuje výrobce celku ve vozidle.
manufacturerSpecificErrorCode je kód chyby specifický pro výrobce.
2.96 MemberStateCertificate
Certifikát veřejného klíče členského státu vydaný Evropským certifi­
kačním úřadem.
2.97 MemberStateCertificateRecordArray
2. generace:
Certifikát členského státu a metadata použitá v protokolu pro stahování.
recordType označuje typ záznamu (MemberStateCertificate). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu MemberStateCertificate v bajtech.
noOfRecords je počet záznamů v sadě záznamů. Hodnota je nastavena
na 1, protože certifikáty mohou mít různé délky.
records je sada certifikátů členských států.
2.98 MemberStatePublicKey
1. generace:
Veřejný klíč členského státu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 167
2.99 Name
Název nebo jméno.
codePage určuje znakovou sadu definovanou v kapitole 4.
name je název nebo jméno kódované za použití určené znakové sady.
2.100 NationAlpha
Abecední označení země musí být v souladu s rozlišovacími značkami
používanými na vozidlech v mezinárodním provozu (Vídeňská úmluva
OSN o silničním provozu z roku 1968).
Abecední a číselné kódy zemí jsou uvedeny v seznamu vedeném na
webových stránkách zkušebny příslušné pro provádění zkoušek interope­
rability, jak je stanoveno v požadavku 440 přílohy 1C.
2.101 NationNumeric
Číselné označení státu.
Přiřazení hodnoty: viz datový typ 2.100 (NationAlpha).
Jakákoli úprava nebo aktualizace specifikace abecedních nebo číselných
kódů popsaných v předchozím odstavci se provede pouze poté, co určená
zkušebna obdrží stanovisko výrobců typově schválených digitálních
a inteligentních tachografových celků ve vozidle.
▼M3
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.
▼B
2.102 NoOfCalibrationRecords
Počet kalibračních záznamů, které lze uložit na kartu dílny.
1. generace:
Přiřazení hodnoty: viz dodatek 2.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 168
2. generace:
Přiřazení hodnoty: viz dodatek 2.
2.103 NoOfCalibrationsSinceDownload
Čítač udávající počet kalibrací provedených s kartou dílny od posledního
stahování (požadavky 317 a 340 přílohy 1C).
Přiřazení hodnoty: není specifikováno.
2.104 NoOfCardPlaceRecords
Počet záznamů míst, které lze uložit na kartu řidiče nebo kartu dílny.
1. generace:
Přiřazení hodnoty: viz dodatek 2.
2. generace:
Přiřazení hodnoty: viz dodatek 2.
2.105 NoOfCardVehicleRecords
Počet záznamů o použitých vozidlech, které lze uložit na kartu řidiče
nebo kartu dílny.
Přiřazení hodnoty: viz dodatek 2.
2.106 NoOfCardVehicleUnitRecords
2. generace:
Počet záznamů o použitých celcích ve vozidle, které lze uložit na kartu
řidiče nebo kartu dílny.
Přiřazení hodnoty: viz dodatek 2.
2.107 NoOfCompanyActivityRecords
Počet záznamů o činnosti podniku, které lze uložit na kartu podniku.
Přiřazení hodnoty: viz dodatek 2.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 169
2.108 NoOfControlActivityRecords
Počet záznamů o kontrolní činnosti, které lze uložit na kontrolní kartu.
Přiřazení hodnoty: viz dodatek 2.
2.109 NoOfEventsPerType
Počet událostí od každého typu události, které lze na kartu uložit.
Přiřazení hodnoty: viz dodatek 2.
2.110 NoOfFaultsPerType
Počet závad od každého typu závady, které lze na kartu uložit.
Přiřazení hodnoty: viz dodatek 2.
▼M1
2.111 NoOfGNSSADRecords
2. generace:
Počet záznamů o součtové době řízení dle GNSS, které lze na kartu
uložit.
Přiřazení hodnoty: viz dodatek 2.
▼M3
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.
▼B
2.112 NoOfSpecificConditionRecords
2. generace:
Počet záznamů o zvláštní podmínce, které lze na kartu uložit.
Přiřazení hodnoty: viz dodatek 2.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 170
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.
▼B
2.113 OdometerShort
Hodnota počitadla ujetých kilometrů vozidla ve zkrácené formě.
Přiřazení hodnoty: Binární číslo bez znaménka. Hodnota v km v provo­
zním rozsahu 0 až 9 999 999 km.
2.114 OdometerValueMidnight
Hodnota počitadla ujetých kilometrů vozidla k půlnoci daného dne
(požadavek 090 přílohy 1B a požadavek 113 přílohy 1C).
Přiřazení hodnoty: není blíže specifikováno.
▼M3
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í.
▼B
2.115 OdometerValueMidnightRecordArray
2. generace:
OdometerValueMidnight a metadata použitá v protokolu pro stahování.
recordType označuje typ záznamu (OdometerValueMidnight). Přiřazení
hodnoty: viz RecordType
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 171
recordSize je velikost záznamu OdometerValueMidnight v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů OdometerValueMidnight.
2.116 OverspeedNumber
Počet událostí překročení povolené rychlosti od poslední kontroly
překročení povolené rychlosti.
Přiřazení hodnoty: 0 znamená, že nedošlo k žádnému překročení povo­
lené rychlosti od poslední kontroly překročení povolené rychlosti, 1
znamená, že se vyskytla jedna událost překročení povolené rychlosti
od poslední kontroly překročení povolené rychlosti, … 255 znamená,
že se vyskytlo 255 nebo více událostí překročení povolené rychlosti od
poslední kontroly překročení povolené rychlosti.
▼M3
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 samot­
ného místa jsou uloženy v jiném záznamu (viz 2.117 PlaceRecord).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 172
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.
▼B
2.117 PlaceRecord
Informace týkající se místa, kde začíná nebo končí denní pracovní doba
(požadavky 108, 271, 296, 324 a 347 přílohy 1C).
1. generace:
entryTime je datum a čas zadání.
entryTypeDailyWorkPeriod je typ zadání.
dailyWorkPeriodCountry je zadaná země.
dailyWorkPeriodRegion je zadaný region.
vehicleOdometerValue je hodnota počitadla ujetých kilometrů k okam­
žiku zadání místa.
2. generace:
Kromě 1. generace se používá tato komponenta:
entryGNSSPlaceRecord je zaznamenané místo a čas.
▼M3
2.117a PositionAuthenticationStatus
2. generace, verze 2:
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 173
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í.
▼B
2.118 PreviousVehicleInfo
Informace související s předchozím vozidlem, které řidič použil, při
vložení karty do celku ve vozidle (požadavek 081 přílohy 1B a poža­
davek 102 přílohy 1C).
1. generace:
vehicleRegistrationIdentification je registrační značka vozidla a členský
stát registrace vozidla.
cardWithdrawalTime je datum a čas vyjmutí karty.
2. generace:
Kromě prvků 1. generace se použije tento datový prvek:
vuGeneration identifikuje generaci celku ve vozidle.
2.119 PublicKey
1. generace:
Veřejný klíč RSA.
rsaKeyModulus je modul páru klíčů.
rsaKeyPublicExponent je veřejný exponent páru klíčů.
2.120 RecordType
2. generace:
Odkaz na typ záznamu. Tento datový typ se používá v záznamu Recor­
dArrays.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 174
Přiřazení hodnoty:
► (1) M1
► (2) M3
ActivityChangeInfo,
CardSlotsStatus,
CurrentDateTime,
MemberStateCertificate,
OdometerValueMidnight,
DateOfDayDownloaded,
SensorPaired,
Signature,
SpecificConditionRecord,
VehicleIdentificationNumber,
VehicleRegistrationNumber,
VuCalibrationRecord,
VuCardIWRecord,
VuCardRecord,
VuCertificate,
VuCompanyLocksRecord,
VuControlActivityRecord,
VuDetailedSpeedBlock,
VuDownloadablePeriod,
VuDownloadActivityData,
VuEventRecord,
►M1 VuGNSSADRecord, ◄
VuITSConsentRecord,
VuFaultRecord,
VuIdentification,
VuOverSpeedingControlData,
VuOverSpeedingEventRecord,
VuPlaceDailyWorkPeriodRecord,
VuTimeAdjustmentGNSSRecord,
VuTimeAdjustmentRecord,
VuPowerSupplyInterruptionRecord,
SensorPairedRecord,
SensorExternalGNSSCoupledRecord,
►M3 VuBorderCrossingRecord,
VuLoadUnloadRecord,
VehicleRegistrationIdentification,
vyhrazeno pro budoucí použití, ◄
specifické pro výrobce.
2.121 RegionAlpha
Abecední odkaz na region uvnitř určitého státu.
1. generace:
Přiřazení hodnoty:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 175
2. generace:
Kódy RegionAlpha jsou uvedeny v seznamu vedeném na webových
stránkách zkušebny pověřené prováděním zkoušek interoperability.
2.122 RegionNumeric
Číselný odkaz na region uvnitř určitého státu.
1. generace:
Přiřazení hodnoty:
2. generace:
Kódy RegionNumeric jsou uvedeny v seznamu vedeném na webových
stránkách zkušebny pověřené prováděním zkoušek interoperability.
2.123 RemoteCommunicationModuleSerialNumber
2. generace:
Výrobní číslo modulu dálkové komunikace.
2.124 RSAKeyModulus
1. generace:
Modul páru klíčů RSA.
Přiřazení hodnoty: není specifikováno.
2.125 RSAKeyPrivateExponent
1. generace:
Soukromý exponent páru klíčů RSA.
Přiřazení hodnoty: není specifikováno.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 176
2.126 RSAKeyPublicExponent
1. generace:
Veřejný exponent páru klíčů RSA.
Přiřazení hodnoty: není specifikováno.
2.127 RtmData
2. generace:
Definice tohoto datového typu viz dodatek 14.
2.128 SealDataCard
2. generace:
Tento datový typ ukládá informace o plombách, které jsou připojeny
k různým částem vozidla, a je určen k uložení na kartě. Tento datový
typ se vztahuje k požadavku 337 přílohy 1C.
noOfSealRecords je počet záznamů v sadě sealRecords.
sealRecords je sada záznamů o plombách.
2.129 SealDataVu
2. generace:
Tento datový typ ukládá informace o plombách, které jsou připojeny
k různým částem vozidla, a je určen k uložení v celku ve vozidle.
sealRecords je sada záznamů o plombách. Je-li dostupných plomb méně
než 5, musí být hodnota EquipmentType ve všech nepoužitých zázna­
mech sealRecords nastavena na 16, tj. nepoužité.
2.130 SealRecord
2. generace:
Tento datový typ ukládá informace o plombě, která je připojena
k součásti. Tento datový typ se vztahuje k požadavku 337 přílohy 1C.
equipmentType označuje typ zařízení, ke kterému je plomba připojena.
extendedSealIdentifier je identifikátor plomby připojené k zařízení.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 177
2.131 SensorApprovalNumber
Číslo schválení typu snímače.
1. generace:
Přiřazení hodnoty: není specifikováno.
2. generace:
Přiřazení hodnoty:
Číslo schválení musí být uvedeno tak, jak bylo zveřejněno na přísluš­
ných webových stránkách Evropské komise, tj. např. včetně případných
spojovníků. Číslo schválení musí být zarovnáno doleva.
2.132 SensorExternalGNSSApprovalNumber
2. generace:
Číslo schválení typu vnějšího zařízení GNSS.
Přiřazení hodnoty:
Číslo schválení musí být uvedeno tak, jak bylo zveřejněno na přísluš­
ných webových stránkách Evropské komise, tj. např. včetně případných
spojovníků. Číslo schválení musí být zarovnáno doleva.
2.133 SensorExternalGNSSCoupledRecord
2. generace:
Informace uložené v celku ve vozidle týkající se identifikace vnějšího
zařízení GNSS provázaného s celkem ve vozidle (požadavek 100 přílohy
1C).
sensorSerialNumber je výrobní číslo vnějšího zařízení GNSS prováza­
ného s celkem ve vozidle.
sensorApprovalNumber je číslo schválení tohoto vnějšího zařízení
GNSS.
sensorCouplingDate je datum vazby tohoto vnějšího zařízení GNSS
s celkem ve vozidle.
2.134 SensorExternalGNSSIdentification
2. generace:
Informace týkající se identifikace vnějšího zařízení GNSS (požadavek 98
přílohy 1C).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 178
sensorSerialNumber je rozšířené výrobní číslo vnějšího zařízení GNSS.
sensorApprovalNumber je číslo schválení vnějšího zařízení GNSS.
sensorSCIdentifier je identifikátor bezpečnostní komponenty vnějšího
zařízení GNSS.
sensorOSIdentifier je identifikátor operačního systému vnějšího zařízení
GNSS.
2.135 SensorExternalGNSSInstallation
2. generace:
Informace uložené ve vnějším zařízení GNSS týkající se montáže vněj­
šího snímače GNSS (požadavek 123 přílohy 1C).
sensorCouplingDateFirst je datum první vazby vnějšího zařízení GNSS
s celkem ve vozidle.
firstVuApprovalNumber je číslo schválení prvního celku ve vozidle
provázaného s vnějším zařízením GNSS.
firstVuSerialNumber je výrobní číslo prvního celku ve vozidle prová­
zaného s vnějším zařízením GNSS.
sensorCouplingDateCurrent je datum aktuální vazby vnějšího zařízení
GNSS s celkem ve vozidle.
currentVuApprovalNumber je číslo schválení celku ve vozidle aktu­
álně provázaného s vnějším zařízením GNSS.
currentVUSerialNumber je výrobní číslo celku ve vozidle aktuálně
provázaného s vnějším zařízením GNSS.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 179
2.136 SensorExternalGNSSOSIdentifier
2. generace:
Identifikátor operačního systému vnějšího zařízení GNSS.
Přiřazení hodnoty: specifické pro výrobce.
2.137 SensorExternalGNSSSCIdentifier
2. generace:
Tento typ se používá např. pro identifikaci kryptografického modulu
vnějšího zařízení GNSS.
Identifikátor bezpečnostní komponenty vnějšího zařízení GNSS.
Přiřazení hodnoty: specifické pro výrobce komponenty.
2.138 SensorGNSSCouplingDate
2. generace:
Datum vazby vnějšího zařízení GNSS s celkem ve vozidle.
Přiřazení hodnoty: není specifikováno.
2.139 SensorGNSSSerialNumber
2. generace:
Tento typ se používá k uložení výrobního čísla přijímače GNSS, ať už je
uvnitř nebo vně celku ve vozidle.
Výrobní číslo přijímače GNSS.
2.140 SensorIdentification
Informace uložená ve snímači pohybu týkající se identifikace snímače
pohybu (požadavek 077 přílohy 1B a požadavek 95 přílohy 1C).
sensorSerialNumber je rozšířené výrobní číslo snímače pohybu (obsa­
huje katalogové číslo dílu a kód výrobce).
sensorApprovalNumber je číslo schválení snímače pohybu.
sensorSCIdentifier je identifikátor bezpečnostní komponenty snímače
pohybu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 180
sensorOSIdentifier je identifikátor operačního systému snímače pohybu.
2.141 SensorInstallation
Informace uložené ve snímači pohybu týkající se montáže snímače
pohybu (požadavek 099 přílohy 1B a požadavek 122 přílohy 1C).
sensorPairingDateFirst je datum prvního párování snímače pohybu
s celkem ve vozidle.
firstVuApprovalNumber je číslo schválení prvního celku ve vozidle
spárovaného se snímačem pohybu.
firstVuSerialNumber je výrobní číslo prvního celku ve vozidle spáro­
vaného se snímačem pohybu.
sensorPairingDateCurrent je datum aktuálního párování snímače
pohybu s celkem ve vozidle.
currentVuApprovalNumber je číslo schválení celku ve vozidle aktu­
álně spárovaného se snímačem pohybu.
currentVUSerialNumber je výrobní číslo celku ve vozidle aktuálně
spárovaného se snímačem pohybu.
2.142 SensorInstallationSecData
Informace uložená na kartě dílny týkající se bezpečnostních dat potřeb­
ných pro párování snímačů pohybu s celky ve vozidlech (požadavky 308
a 331 přílohy 1C).
1. generace:
Přiřazení hodnoty: dle ISO 16844-3.
2. generace:
Jak je uvedeno v dodatku 11, karta dílny musí pojmout až tři klíče pro
párování celku ve vozidle se snímačem pohybu. Tyto klíče mají různé
verze.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 181
2.143 SensorOSIdentifier
Identifikátor operačního systému snímače pohybu.
Přiřazení hodnoty: specifické pro výrobce.
2.144 SensorPaired
1. generace:
Informace uložená v celku ve vozidle týkající se identifikace snímače
pohybu spárovaného s celkem ve vozidle (požadavek 079 přílohy 1B).
sensorSerialNumber je výrobní číslo snímače pohybu aktuálně spáro­
vaného s celkem ve vozidle.
sensorApprovalNumber je číslo schválení snímače pohybu aktuálně
spárovaného s celkem ve vozidle.
sensorPairingDateFirst je datum prvního párování snímače pohybu,
který je aktuálně spárován s celkem ve vozidle, s nějakým celkem ve
vozidle.
2.145 SensorPairedRecord
2. generace:
Informace uložená v celku ve vozidle týkající se identifikace snímače
pohybu spárovaného s celkem ve vozidle (požadavek 97 přílohy 1C).
sensorSerialNumber je výrobní číslo snímače pohybu spárovaného
s celkem ve vozidle.
sensorApprovalNumber je číslo schválení tohoto snímače pohybu.
sensorPairingDate je datum spárování tohoto snímače pohybu s celkem
ve vozidle.
2.146 SensorPairingDate
Datum spárování snímače pohybu s celkem ve vozidle.
Přiřazení hodnoty: není specifikováno.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 182
2.147 SensorSCIdentifier
Identifikátor bezpečnostní komponenty snímače pohybu.
Přiřazení hodnoty: specifické pro výrobce komponenty.
2.148 SensorSerialNumber
Výrobní číslo snímače pohybu.
2.149 Signature
Digitální podpis.
1. generace:
Přiřazení hodnoty: v souladu s dodatkem 11 „Společné bezpečnostní
mechanismy“.
2. generace:
Přiřazení hodnoty: v souladu s dodatkem 11 „Společné bezpečnostní
mechanismy“.
2.150 SignatureRecordArray
2. generace:
Sada podpisů a metadata použitá v protokolu pro stahování.
recordType označuje typ záznamu (Signature). Přiřazení hodnoty: viz
RecordType
recordSize je velikost záznamu Signature v bajtech.
noOfRecords je počet záznamů v sadě záznamů. Hodnota je nastavena
na 1, protože digitální podpisy mohou mít různé délky.
records je sada digitálních podpisů.
2.151 SimilarEventsNumber
Počet podobných událostí během daného dne (požadavek 094 přílohy 1B
a požadavek 117 přílohy 1C).
Přiřazení hodnoty: 0 se nepoužívá, 1 znamená, že v daný den se
vyskytla a byla uložena pouze jedna událost toho typu, 2 znamená, že
v daný den se vyskytly dvě události toho typu (pouze jedna byla
uložena), … 255 znamená, že v daný den se vyskytlo 255 nebo více
událostí toho typu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 183
2.152 SpecificConditionRecord
Informace uložené na kartě řidiče, kartě dílny nebo v celku ve vozidle
týkající se zvláštní podmínky (požadavky 130, 276, 301, 328 a 355
přílohy 1C).
entryTime je datum a čas zadání.
specificConditionType je kód identifikující zvláštní podmínku.
2.153 SpecificConditions
Informace uložené na kartě řidiče, kartě dílny nebo v celku ve vozidle
týkající se zvláštní podmínky (požadavky 131, 277, 302, 329 a 356
přílohy 1C).
2. generace:
conditionPointerNewestRecord je index naposledy aktualizovaného
záznamu o zvláštní podmínce.
Přiřazení hodnoty: Číslo odpovídající čítači záznamů o zvláštní
podmínce, začínající hodnotou „0“ pro první výskyt záznamu o zvláštní
podmínce ve struktuře.
specificConditionRecords je sada záznamů obsahujících informace
o zaznamenaných zvláštních podmínkách.
2.154 SpecificConditionType
Kód identifikující zvláštní podmínku (požadavky 050b, 105a, 212a
a 230a přílohy 1B a požadavek 62 přílohy 1C).
1. generace:
Přiřazení hodnoty:
„00“H vyhrazeno pro budoucí použití
„01“H mimo působnost – začátek
„02“H mimo působnost – konec
„03“H převoz lodí / převoz vlakem
„04“H .. „FF“H vyhrazeno pro budoucí použití
2. generace:
Přiřazení hodnoty:
„00“H vyhrazeno pro budoucí použití
„01“H mimo působnost – začátek
„02“H mimo působnost – konec
„03“H převoz lodí / převoz vlakem – začátek
„04“H převoz lodí / převoz vlakem – konec
„05“H .. „FF“H vyhrazeno pro budoucí použití
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 184
2.155 Speed
Rychlost vozidla (km/h).
Přiřazení hodnoty: kilometry za hodinu v provozním rozsahu 0 až
220 km/h.
2.156 SpeedAuthorised
Maximální dovolená rychlost vozidla (definice hh)).
2.157 SpeedAverage
Průměrná rychlost v dříve určené době trvání (km/h).
2.158 SpeedMax
Nejvyšší naměřená rychlost v dříve určené době trvání.
▼M3
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 tacho­
grafu 1. generace (standardní hodnota),
„A5E3“H celek ve vozidle není schopen používat karty
tachografu 1. generace,
všechny jiné hodnoty nepoužívá se.
▼B
2.159 TachographPayload
2. generace:
Definice tohoto datového typu viz dodatek 14.
▼M1
2.160 Vyhrazeno pro budoucí použití
▼B
2.161 TDesSessionKey
1. generace:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 185
Klíč Triple-DES relace.
Přiřazení hodnoty: není blíže specifikováno.
▼M1
2.162 TimeReal
Kód pro kombinované pole data a času, kde datum a čas jsou vyjádřeny
jako počet sekund uplynutých od 00h:00m:00s dne 1. ledna 1970
v časovém pásmu UTC.
Přiřazení hodnoty – oktetové uspořádání: počet sekund od půlnoci
1. ledna 1970 v časovém pásmu UTC.
Nejvyšší možný údaj data/času je v roce 2106.
▼B
2.163 TyreSize
Označení rozměrů pneumatik.
Přiřazení hodnoty: podle směrnice 92/23/EHS (Úř. věst. L 129,
31.3.1992, s. 95).
2.164 VehicleIdentificationNumber
Identifikační číslo vozidla (VIN) odkazující na vozidlo jako celek,
obvykle výrobní číslo karosérie nebo rámu.
Přiřazení hodnoty: podle ISO 3779.
2.165 VehicleIdentificationNumberRecordArray
2. generace:
Identifikační číslo vozidla a metadata použitá v protokolu pro stahování.
recordType označuje typ záznamu (VehicleIdentificationNumber).
Přiřazení hodnoty: viz RecordType
recordSize je velikost záznamu VehicleIdentificationNumber v bajtech.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 186
noOfRecords je počet záznamů v sadě záznamů.
records je sada identifikačních čísel vozidla.
2.166 VehicleRegistrationIdentification
Jednoznačná identifikace vozidla v Evropě (VRN a členský stát).
vehicleRegistrationNation je stát, ve kterém je vozidlo registrováno.
vehicleRegistrationNumber je registrační značka vozidla (VRN).
▼M3
2.166a VehicleRegistrationIdentificationRecordArray
2. generace, verze 2:
identifikace registrace vozidla a metadata použitá v protokolu pro staho­
vá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.
▼B
2.167 VehicleRegistrationNumber
Registrační značka vozidla (VRN). Registrační značka je přidělena
orgánem registrujícím vozidlo.
codePage určuje znakovou sadu definovanou v kapitole 4.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 187
vehicleRegNumber je registrační značka vozidla (VRN) kódovaná
s použitím určené znakové sady.
Přiřazení hodnoty: specifické pro stát.
2.168 VehicleRegistrationNumberRecordArray
▼M3
2. generace, verze 1:
▼B
Registrační značka vozidla a metadata použitá v protokolu pro staho­
vání.
recordType označuje typ záznamu (VehicleRegistrationNumber). Přiřa­
zení hodnoty: viz RecordType
recordSize je velikost záznamu VehicleRegistrationNumber v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada registračních značek vozidla.
2.169 VuAbility
2. generace:
Informace uložená v celku ve vozidle a týkající se schopnosti celku ve
vozidle používat karty tachografu 1. generace (požadavek 121 přílohy 1C).
Přiřazení hodnoty – oktetové uspořádání: „xxxxxxxa“B (8 bitů)
Pro schopnost podporovat 1. generaci:
„a“B Schopnost podporovat karty tachografu 1. generace:
„0“B 1. generace je podporována,
„1“B 1. generace není podporována,
„xxxxxxx“B vyhrazeno pro budoucí použití
2.170 VuActivityDailyData
1. generace:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 188
Informace uložené v celku ve vozidle související se změnami činnosti
a/nebo změnami statusu řízení a/nebo změnami statusu karty pro daný
kalendářní den (požadavek 084 přílohy 1B a požadavky 105, 106 a 107
přílohy 1C) a se stavem otvorů pro kartu v 00.00 daného dne.
noOfActivityChanges je počet slov ActivityChangeInfo v sadě activity­
ChangeInfos.
activityChangeInfos je sada slov ActivityChangeInfo uložených v celku
ve vozidle pro daný den. Vždy obsahuje dvě slova ActivityChangeInfo
udávající status dvou otvorů pro kartu v 00.00 daného dne.
2.171 VuActivityDailyRecordArray
2. generace:
Informace uložené v celku ve vozidle související se změnami činnosti
a/nebo změnami statusu řízení a/nebo změnami statusu karty pro daný
kalendářní den (požadavky 105, 106 a 107 přílohy 1C) a se stavem
otvorů pro kartu v 00.00 daného dne.
recordType označuje typ záznamu (ActivityChangeInfo). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu ActivityChangeInfo v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada slov ActivityChangeInfo uložených v celku ve vozidle
pro daný den. Vždy obsahuje dvě slova ActivityChangeInfo udávající
status dvou otvorů pro kartu v 00.00 daného dne.
2.172 VuApprovalNumber
Číslo schválení typu celku ve vozidle.
1. generace:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 189
Přiřazení hodnoty: není specifikováno.
2. generace:
Přiřazení hodnoty:
Číslo schválení musí být uvedeno tak, jak bylo zveřejněno na přísluš­
ných webových stránkách Evropské komise, tj. např. včetně případných
spojovníků. Číslo schválení musí být zarovnáno doleva.
2.173 VuCalibrationData
1. generace:
Informace uložené v celku ve vozidle týkající se kalibrací záznamového
zařízení (požadavek 098 přílohy 1B).
noOfVuCalibrationRecords je počet záznamů obsažených v sadě
vuCalibrationRecords.
vuCalibrationRecords je sada kalibračních záznamů.
2.174 VuCalibrationRecord
Informace uložené v celku ve vozidle týkající se kalibrace záznamového
zařízení (požadavek 098 přílohy 1B a požadavky 119 a 120 přílohy 1C).
1. generace:
calibrationPurpose je účel kalibrace.
workshopName, workshopAddress jsou název dílny a její adresa.
workshopCardNumber identifikuje kartu dílny použitou při kalibraci.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 190
workshopCardExpiryDate je datum konce platnosti karty.
vehicleIdentificationNumber je identifikační číslo vozidla (VIN).
vehicleRegistrationIdentification obsahuje registrační značku (VRN)
a členský stát registrace vozidla.
wVehicleCharacteristicConstant je charakteristický koeficient vozidla.
kConstantOfRecordingEquipment je konstanta záznamového zařízení.
lTyreCircumference je účinný obvod pneumatik na kolech.
tyreSize je označení rozměrů pneumatik namontovaných na vozidle.
authorisedSpeed je dovolená rychlost vozidla.
oldOdometerValue, newOdometerValue jsou stará a nová hodnota
počitadla ujetých kilometrů.
oldTimeValue, newTimeValue jsou stará a nová hodnota data a času.
nextCalibrationDate je datum příští kalibrace typu určeného v Calibra­
tionPurpose, kterou provede schválený kontrolní orgán.
▼M3
2. generace, verze 1:
▼B
Kromě prvků 1. generace se použije tento datový prvek:
sealDataVu uvádí informace o plombách, které jsou připojeny k různým
částem vozidla.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 191
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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 192
2.175 VuCalibrationRecordArray
2. generace:
Informace uložené v celku ve vozidle týkající kalibrací záznamového
zařízení (požadavky 119 a 120 přílohy 1C).
recordType označuje typ záznamu (VuCalibrationRecord). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu VuCalibrationRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada kalibračních záznamů.
2.176 VuCardIWData
1. generace:
Informace uložené v celku ve vozidle týkající se cyklů vložení a vyjmutí
karty řidiče nebo karty dílny do/z celku ve vozidle (požadavek 081
přílohy 1B a požadavek 103 přílohy 1C).
noOfIWRecords je počet záznamů v sadě vuCardIWRecords.
vuCardIWRecords je sada záznamů týkajících se cyklů vkládání a vyjí­
mání karty.
2.177 VuCardIWRecord
Informace uložené v celku ve vozidle týkající se cyklů vložení a vyjmutí
karty řidiče nebo karty dílny do/z celku ve vozidle (požadavek 081
přílohy 1B a požadavek 102 přílohy 1C).
1. generace:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 193
cardHolderName je příjmení a jméno (jména) držitele karty řidiče nebo
karty dílny ve tvaru, jak jsou uložena na kartě.
fullCardNumber je typ karty, členský stát, který ji vystavil, a její číslo
ve tvaru, jak jsou uložené na kartě.
cardExpiryDate je datum konce platnosti karty ve tvaru, jak je uloženo
na kartě.
cardInsertionTime je datum a čas vložení karty.
vehicleOdometerValueAtInsertion je hodnota počitadla ujetých kilo­
metrů při vložení karty.
cardSlotNumber je otvor pro kartu, ve kterém je karta vložena.
cardWithdrawalTime je datum a čas vyjmutí karty.
vehicleOdometerValueAtWithdrawal je hodnota počitadla ujetých
kilometrů při vyjmutí karty.
previousVehicleInfo obsahuje informaci o předchozím vozidle, které
řidič použil, ve tvaru, jak je uložena na kartě.
manualInputFlag je příznak udávající, zda držitel karty při jejím
vložení ručně zadal činnosti řidiče.
2. generace:
Místo prvku fullCardNumber používá struktura dat 2. generace následu­
jící datový prvek.
fullCardNumberAndGeneration je typ karty, členský stát, který ji
vydal, její číslo a generace, jak jsou na kartě uloženy.
2.178 VuCardIWRecordArray
2. generace:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 194
Informace uložené v celku ve vozidle týkající se cyklů vložení a vyjmutí
karet řidiče nebo karet dílny z/do celku ve vozidle (požadavek 103
přílohy 1C).
recordType označuje typ záznamu (VuCardIWRecord). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu VuCardIWRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů týkajících se cyklů vložení a vyjmutí karty.
▼M1
2.179 VuCardRecord
2. generace:
Informace uložené v celku ve vozidle o použité kartě tachografu (příloha
IC požadavek 132).
cardNumberAndGenerationInformation je celé číslo karty a generace
použité karty (datový typ 2.74).
cardExtendedSerialNumber se načte ze souboru EF_ICC pod hlavním
souborem (MF) karty.
cardStructureVersion se načte ze souboru EF_Application_Identifica­
tion pod DF_Tachograph_G2.
cardNumber se načte ze souboru EF_Identification pod DF_Tacho­
graph_G2.
▼B
2.180 VuCardRecordArray
2. generace:
Informace uložené v celku ve vozidle o kartách tachografu použitých
s tímto celkem ve vozidle. Tyto informace jsou určeny pro analýzu
problémů s celkem ve vozidle a kartou (požadavek 132 přílohy 1C).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 195
recordType označuje typ záznamu (VuCardRecord). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu VuCardRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů týkajících se karet tachografu použitých
s celkem ve vozidle.
2.181 VuCertificate
Certifikát veřejného klíče celku ve vozidle.
2.182 VuCertificateRecordArray
2. generace:
Certifikát celku ve vozidle a metadata použitá v protokolu pro stahování.
recordType označuje typ záznamu (VuCertificate). Přiřazení hodnoty:
viz RecordType
recordSize je velikost záznamu VuCertificate v bajtech.
noOfRecords je počet záznamů v sadě záznamů. Hodnota je nastavena
na 1, protože certifikáty mohou mít různé délky.
records je sada certifikátů celků ve vozidle.
2.183 VuCompanyLocksData
1. generace:
Informace uložené v celku ve vozidle týkající se zámků podniku (poža­
davek 104 přílohy 1B).
noOfLocks je počet zámků uvedených v sadě vuCompanyLocks­
Records.
vuCompanyLocksRecords je sada záznamů zámků podniku.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 196
2.184 VuCompanyLocksRecord
Informace uložená v celku ve vozidle týkající se jednoho zámku
podniku (požadavek 104 přílohy 1B a požadavek 128 přílohy 1C).
1. generace:
lockInTime, lockOutTime jsou datum a čas zamčení a odemčení
zámku.
companyName, companyAddress jsou název a adresa podniku vztahu­
jící se k zamčenému zámku.
companyCardNumber identifikuje kartu použitou při zamčení zámku.
2. generace:
Místo prvku companyCardNumber používá struktura dat 2. generace
následující datový prvek.
companyCardNumberAndGeneration identifikuje kartu použitou při
zamčení zámku včetně její generace.
2.185 VuCompanyLocksRecordArray
2. generace:
Informace uložené v celku ve vozidle týkající se zámků podniku (poža­
davek 128 přílohy 1C).
recordType označuje typ záznamu (VuCompanyLocksRecord). Přiřa­
zení hodnoty: viz RecordType
recordSize je velikost záznamu VuCompanyLocksRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů. Hodnota 0..255.
records je sada záznamů zámků podniku.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 197
2.185a VuConfigurationLengthRange
2. generace, verze 2:
Počet bajtů v kartě tachografu, který je k dispozici pro uložení konfi­
gurací VU.
Přiřazení hodnoty: viz dodatek 2.
▼B
2.186 VuControlActivityData
1. generace:
Informace uložené v celku ve vozidle týkající se kontrol provedených
s použitím tohoto celku ve vozidle (požadavek 102 přílohy 1B).
noOfControls je počet kontrol uvedených v sadě vuControlActivityRe­
cords.
vuControlActivityRecords je sada záznamů o kontrolních činnostech.
2.187 VuControlActivityRecord
Informace uložené v celku ve vozidle týkající se kontroly provedené
s použitím tohoto celku ve vozidle (požadavek 102 přílohy 1B a poža­
davek 126 přílohy 1C).
1. generace:
controlType je typ kontroly.
controlTime je datum a čas kontroly.
controlCardNumber identifikuje kontrolní kartu použitou při kontrole.
downloadPeriodBeginTime je začátek staženého období, pokud jsou
stahována data.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 198
downloadPeriodEndTime je konec staženého období, pokud jsou
stahována data.
2. generace:
Místo prvku controlCardNumber používá struktura dat 2. generace násle­
dující datový prvek.
controlCardNumberAndGeneration identifikuje kontrolní kartu použ­
itou pro kontrolu včetně její generace.
2.188 VuControlActivityRecordArray
2. generace:
Informace uložené v celku ve vozidle týkající se kontrol provedených
s použitím tohoto celku ve vozidle (požadavek 126 přílohy 1C).
recordType označuje typ záznamu (VuControlActivityRecord). Přiřa­
zení hodnoty: viz RecordType
recordSize je velikost záznamu VuControlActivityRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o kontrolních činnostech provedených s celkem
ve vozidle.
2.189 VuDataBlockCounter
Čítač uložený na kartě identifikující postupně cykly vkládání a vyjímání
karty z/do celků ve vozidle.
Přiřazení hodnoty: pořadové číslo s max. hodnotou 9 999, po níž
začíná opět hodnotou 0.
2.190 VuDetailedSpeedBlock
Informace uložené v celku ve vozidle týkající se podrobností o rychlosti
vozidla během jedné minuty, kdy se vozidlo pohybovalo (požadavek
093 přílohy 1B a požadavek 116 přílohy 1C).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 199
speedBlockBeginDate je datum a čas první hodnoty rychlosti v rámci
bloku.
speedsPerSecond je chronologická posloupnost naměřených rychlostí
každou sekundu během minuty začínající v okamžiku speedBlockBegin­
Date (včetně).
2.191 VuDetailedSpeedBlockRecordArray
2. generace:
Informace uložené v celku ve vozidle týkající se podrobností o rychlosti
vozidla.
recordType označuje typ záznamu (VuDetailedSpeedBlock). Přiřazení
hodnoty
: viz RecordType
recordSize je velikost záznamu VuDetailedSpeedBlock v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada bloků podrobností o rychlosti.
2.192 VuDetailedSpeedData
1. generace:
Informace uložené v celku ve vozidle týkající se podrobností o rychlosti
vozidla.
noOfSpeedBlocks je počet bloků o rychlosti v sadě vuDetailedSpeed­
Blocks.
vuDetailedSpeedBlocks je sada bloků s podrobnostmi o rychlosti.
▼M3
2.192a VuDigitalMapVersion
2. generace, verze 2:
Verze digitální mapy uložené v celku ve vozidle (požadavek 133j
v příloze IC).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 200
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).
▼B
2.193 VuDownloadablePeriod
Nejstarší a nejnovější datum, pro které celek ve vozidle uchovává údaje
týkající se činností řidičů (požadavky 081, 084 nebo 087 přílohy 1B
a požadavky 102, 105 a 108 přílohy 1C).
minDownloadableTime je datum a čas nejstaršího záznamu o vložení
karty, změně činnosti nebo zadání místa, který je uložen v celku ve
vozidle.
maxDownloadableTime je datum a čas nejnovějšího záznamu o vyjmutí
karty, změně činnosti nebo zadání místa, který je uložen v celku ve
vozidle.
2.194 VuDownloadablePeriodRecordArray
2. generace:
VUDownloadablePeriod a metadata použitá v protokolu pro stahování.
recordType označuje typ záznamu (VuDownloadablePeriod). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu VuDownloadablePeriod v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů VuDownloadablePeriod.
2.195 VuDownloadActivityData
Informace uložené v celku ve vozidle týkající se posledního stažení dat
z něj (požadavek 105 přílohy 1B a požadavek 129 přílohy 1C).
1. generace:
downloadingTime je datum a čas stažení dat.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 201
fullCardNumber identifikuje kartu použitou k autorizaci stahování.
companyOrWorkshopName je název podniku nebo dílny.
2. generace:
Místo prvku fullCardNumber používá struktura dat 2. generace následu­
jící datový prvek.
fullCardNumberAndGeneration identifikuje kartu použitou k autorizaci
stahování, včetně její generace.
2.196 VuDownloadActivityDataRecordArray
2. generace:
Informace týkající se posledního stažení dat z celku ve vozidle (poža­
davek 129 přílohy 1C).
recordType označuje typ záznamu (VuDownloadActivityData). Přiřa­
zení hodnoty: viz RecordType
recordSize je velikost záznamu VuDownloadActivityData v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada datových záznamů o provedených staženích.
2.197 VuEventData
1. generace:
Informace uložené v celku ve vozidle týkající se událostí (požadavek
094 přílohy 1B kromě událostí překročení povolené rychlosti).
noOfVuEvents je počet událostí uvedených v sadě vuEventRecords.
vuEventRecords je sada záznamů o událostech.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 202
2.198 VuEventRecord
Informace uložené v celku ve vozidle týkající se události (požadavek
094 přílohy 1B a požadavek 117 přílohy 1C kromě událostí překročení
povolené rychlosti).
1. generace:
eventType je typ události.
eventRecordPurpose je účel, pro který byla tato událost zaznamenána.
eventBeginTime je datum a čas začátku události.
eventEndTime je datum a čas konce události.
cardNumberDriverSlotBegin identifikuje kartu vloženou v otvoru pro
kartu řidiče na začátku události.
cardNumberCodriverSlotBegin identifikuje kartu vloženou v otvoru
pro kartu druhého řidiče na začátku události.
cardNumberDriverSlotEnd identifikuje kartu vloženou v otvoru pro
kartu řidiče na konci události.
cardNumberCodriverSlotEnd identifikuje kartu vloženou v otvoru pro
kartu druhého řidiče na konci události.
similarEventsNumber je počet podobných událostí v daný den.
Tato posloupnost může být použita pro všechny události s výjimkou
událostí překročení povolené rychlosti.
2. generace:
Kromě prvků 1. generace se používají tyto datové prvky:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 203
manufacturerSpecificEventFaultData obsahuje dodatečné informace
o události, které jsou specifické pro výrobce.
Místo prvků cardNumberDriverSlotBegin, cardNumberCodriverSlot­
Begin, cardNumberDriverSlotEnd a cardNumberCodriverSlotEnd
používá struktura dat 2. generace následující datové prvky:
cardNumberAndGenDriverSlotBegin identifikuje kartu vloženou
v otvoru pro kartu řidiče na začátku události, včetně její generace.
cardNumberAndGenCodriverSlotBegin identifikuje kartu vloženou
v otvoru pro kartu druhého řidiče na začátku události, včetně její
generace.
cardNumberAndGenDriverSlotEnd identifikuje kartu vloženou
v otvoru pro kartu řidiče na konci události, včetně její generace.
cardNumberAndGenCodriverSlotEnd identifikuje kartu vloženou
v otvoru pro kartu druhého řidiče na konci události, včetně její generace.
Je-li událost časovým nesouladem, interpretují se eventBeginTime
a eventEndTime takto:
eventBeginTime je datum a čas záznamového zařízení.
eventEndTime je datum a čas GNSS.
2.199 VuEventRecordArray
2. generace:
Informace uložené v celku ve vozidle týkající se událostí (požadavek
117 přílohy 1C kromě událostí překročení povolené rychlosti).
recordType označuje typ záznamu (VuEventRecord). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu VuEventRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o událostech.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 204
2.200 VuFaultData
1. generace:
Informace uložené v celku ve vozidle týkající se závad (požadavek 096
přílohy 1B).
noOfVuFaults je počet závad uvedených v sadě vuFaultRecords.
vuFaultRecords je sada záznamů o závadách.
2.201 VuFaultRecord
Informace uložené v celku ve vozidle týkající se závady (požadavek 096
přílohy 1B a požadavek 118 přílohy 1C).
1. generace:
faultType je typ závady záznamového zařízení.
faultRecordPurpose je účel, pro který byla tato závada zaznamenána.
faultBeginTime je datum a čas začátku závady.
faultEndTime je datum a čas konce závady.
cardNumberDriverSlotBegin identifikuje kartu vloženou v otvoru pro
kartu řidiče na začátku závady.
cardNumberCodriverSlotBegin identifikuje kartu vloženou v otvoru
pro kartu druhého řidiče na začátku závady.
cardNumberDriverSlotEnd identifikuje kartu vloženou v otvoru pro
kartu řidiče na konci závady.
cardNumberCodriverSlotEnd identifikuje kartu vloženou v otvoru pro
kartu druhého řidiče na konci závady.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 205
2. generace:
Kromě prvků 1. generace se použije tento datový prvek:
manufacturerSpecificEventFaultData obsahuje dodatečné informace
o závadě, které jsou specifické pro výrobce.
Místo prvků cardNumberDriverSlotBegin, cardNumberCodriverSlot­
Begin, cardNumberDriverSlotEnd a cardNumberCodriverSlotEnd
používá struktura dat 2. generace následující datové prvky:
cardNumberAndGenDriverSlotBegin identifikuje kartu vloženou
v otvoru pro kartu řidiče na začátku závady, včetně její generace.
cardNumberAndGenCodriverSlotBegin identifikuje kartu vloženou
v otvoru pro kartu druhého řidiče na začátku závady, včetně její
generace.
cardNumberAndGenDriverSlotEnd identifikuje kartu vloženou
v otvoru pro kartu řidiče na konci závady, včetně její generace.
cardNumberAndGenCodriverSlotEnd identifikuje kartu vloženou
v otvoru pro kartu druhého řidiče na konci závady, včetně její generace.
2.202 VuFaultRecordArray
2. generace:
Informace uložené v celku ve vozidle týkající se závad (požadavek 118
přílohy 1C).
recordType označuje typ záznamu (VuFaultRecord). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu VuFaultRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o závadách.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 206
2.203 VuGNSSADRecord
▼M3
2. generace, verze 1:
▼M1
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 (příloha
IC požadavky 108 a 110).
timeStamp je datum a čas, kdy součtová doba řízení dosáhne násobku
tří hodin.
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.
gnssPlaceRecord obsahuje informace týkající se polohy vozidla.
vehicleOdometerValue je stav počitadla ujetých kilometrů, kdy
součtová doba řízení dosáhne násobku tří hodin.
▼M3
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ža­
davky 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.
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).
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 207
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řa­
zení 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.
▼M1
2.204 VuGNSSADRecordArray
2. generace:
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 208
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 (příloha
IC požadavky 108 a 110).
recordType označuje typ záznamu (VuGNSSADRecord).
Přiřazení hodnoty: viz RecordType.
recordSize je velikost záznamu VuGNSSADRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o součtové době řízení dle GNSS.
▼M3
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.
▼B
2.205 VuIdentification
Informace uložené v celku ve vozidle týkající se identifikace celku ve
vozidle (požadavek 075 přílohy 1B a požadavky 93 a 121 přílohy 1C).
1. generace:
vuManufacturerName je název výrobce celku ve vozidle.
vuManufacturerAddress je adresa výrobce celku ve vozidle.
vuPartNumber je katalogové číslo dílu celku ve vozidle.
vuSerialNumber je výrobní číslo celku ve vozidle.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 209
vuSoftwareIdentification identifikuje software implementovaný v celku
ve vozidle.
vuManufacturingDate je datum výroby celku ve vozidle.
vuApprovalNumber je číslo schválení typu celku ve vozidle.
▼M3
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).
▼B
2.206 VuIdentificationRecordArray
2. generace:
VuIdentification a metadata použitá v protokolu pro stahování.
recordType označuje typ záznamu (VuIdentification). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu VuIdentification v bajtech.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 210
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů VuIdentification.
2.207 VuITSConsentRecord
2. generace:
Informace uložené v celku ve vozidle týkající se souhlasu řidiče s použí­
váním inteligentních dopravních systémů.
cardNumberAndGen identifikuje kartu včetně její generace. Musí se
jednat o kartu řidiče nebo kartu dílny.
consent je příznak, který uvádí, zda řidič souhlasil s používáním inteli­
gentních dopravních systémů ve spojitosti s tímto vozidlem / celkem ve
vozidle.
Přiřazení hodnoty:
TRUE označuje souhlas řidiče s používáním inteligent­
ních dopravních systémů
FALSE označuje nesouhlas řidiče s používáním inteligent­
ních dopravních systémů
2.208 VuITSConsentRecordArray
2. generace:
Informace uložené v celku ve vozidle týkající se souhlasu řidiče s použí­
váním inteligentních dopravních systémů (požadavek 200 přílohy 1C).
recordType označuje typ záznamu (VuITSConsentRecord). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu VuITSConsentRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o souhlasu s používáním ITS.
▼M3
2.208a VuLoadUnloadRecord
2. generace, verze 2:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 211
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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 212
2.209 VuManufacturerAddress
Adresa výrobce celku ve vozidle.
Přiřazení hodnoty: není specifikováno.
2.210 VuManufacturerName
Název výrobce celku ve vozidle.
Přiřazení hodnoty: není specifikováno.
2.211 VuManufacturingDate
Datum výroby celku ve vozidle.
Přiřazení hodnoty: není specifikováno.
2.212 VuOverSpeedingControlData
Informace uložené v celku ve vozidle týkající se událostí překročení
povolené rychlosti od poslední kontroly překročení povolené rychlosti
(požadavek 095 přílohy 1B a požadavek 117 přílohy 1C).
lastOverspeedControlTime je datum a čas poslední kontroly překročení
povolené rychlosti.
firstOverspeedSince je datum a čas prvního překročení povolené rych­
losti po této kontrole překročení povolené rychlosti.
numberOfOverspeedSince je počet událostí překročení povolené rych­
losti od poslední kontroly překročení povolené rychlosti.
2.213 VuOverSpeedingControlDataRecordArray
2. generace:
VuOverSpeedingControlData a metadata použitá v protokolu pro staho­
vání.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 213
recordType označuje typ záznamu (VuOverSpeedingControlData).
Přiřazení hodnoty: viz RecordType
recordSize je velikost záznamu VuOverSpeedingControlData v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada datových záznamů o kontrole překročení povolené
rychlosti.
2.214 VuOverSpeedingEventData
1. generace:
Informace uložené v celku ve vozidle týkající se událostí překročení
povolené rychlosti (požadavek 094 přílohy 1B).
noOfVuOverSpeedingEvents je počet událostí uvedených v sadě
vuOverSpeedingEventRecords.
vuOverSpeedingEventRecords je sada záznamů o událostech překro­
čení povolené rychlosti.
2.215 VuOverSpeedingEventRecord
1. generace:
Informace uložené v celku ve vozidle týkající se událostí překročení povo­
lené rychlosti (požadavek 094 přílohy 1B a požadavek 117 přílohy 1C).
eventType je typ události.
eventRecordPurpose je účel, pro který byla tato událost zaznamenána.
eventBeginTime je datum a čas začátku události.
eventEndTime je datum a čas konce události.
maxSpeedValue je nejvyšší rychlost naměřená během události.
averageSpeedValue je průměrná rychlost naměřená během události.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 214
cardNumberDriverSlotBegin identifikuje kartu vloženou v otvoru pro
kartu řidiče na začátku události.
similarEventsNumber je počet podobných událostí v daný den.
2. generace:
Informace uložené v celku ve vozidle týkající se událostí překročení povo­
lené rychlosti (požadavek 094 přílohy 1B a požadavek 117 přílohy 1C).
Namísto prvku cardNumberDriverSlotBegin používá struktura dat 2.
generace následující datový prvek:
cardNumberAndGenDriverSlotBegin identifikuje kartu vloženou
v otvoru pro kartu řidiče na začátku události, včetně její generace.
2.216 VuOverSpeedingEventRecordArray
2. generace:
Informace uložené v celku ve vozidle týkající se událostí překročení
povolené rychlosti (požadavek 117 přílohy 1C).
recordType označuje typ záznamu (VuOverSpeedingEventRecord).
Přiřazení hodnoty: viz RecordType
recordSize je velikost záznamu VuOverSpeedingEventRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o událostech překročení povolené rychlosti.
2.217 VuPartNumber
Katalogové číslo dílu celku ve vozidle.
Přiřazení hodnoty: specifické pro výrobce celku ve vozidle.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 215
2.218 VuPlaceDailyWorkPeriodData
1. generace:
Informace uložené v celku ve vozidle týkající se míst, kde řidiči začínají
nebo končí denní pracovní dobu (požadavek 087 přílohy 1B a požadavky
108 a 110 přílohy 1C).
noOfPlaceRecords je počet záznamů uvedených v sadě vuPlaceDaily­
WorkPeriodRecords.
vuPlaceDailyWorkPeriodRecords je sada záznamů týkajících se míst.
2.219 VuPlaceDailyWorkPeriodRecord
1. generace:
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 přílohy 1C).
fullCardNumber je typ karty řidiče, členský stát, který ji vydal, a číslo
karty.
placeRecord obsahuje informace týkající se zadaného místa.
▼M3
2. generace, verze 1:
▼B
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 přílohy 1C).
Místo prvku fullCardNumber používá struktura dat 2. generace následu­
jící datový prvek:
fullCardNumberAndGeneration je typ karty, členský stát, který ji
vydal, její číslo a generace, jak jsou na kartě uloženy.
▼M3
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).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 216
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.
▼B
2.220 VuPlaceDailyWorkPeriodRecordArray
2. generace:
Informace uložené v celku ve vozidle týkající se míst, kde řidič začíná
nebo končí denní pracovní dobu (požadavky 108 a 110 přílohy 1C).
recordType označuje typ záznamu (VuPlaceDailyWorkPeriodRecord).
Přiřazení hodnoty: viz RecordType
recordSize je velikost záznamu VuPlaceDailyWorkPeriodRecord
v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů týkajících se míst.
2.221 VuPrivateKey
1. generace:
Soukromý klíč celku ve vozidle.
2.222 VuPublicKey
1. generace:
Veřejný klíč celku ve vozidle.
▼M3
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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 217
2.223 VuSerialNumber
Výrobní číslo celku ve vozidle (požadavek 075 přílohy 1B a požadavek
93 přílohy 1C).
2.224 VuSoftInstallationDate
Datum instalace verze softwaru celku ve vozidle.
Přiřazení hodnoty: není specifikováno.
2.225 VuSoftwareIdentification
Informace uložená v celku ve vozidle týkající se instalovaného softwaru.
vuSoftwareVersion je číslo verze softwaru v celku ve vozidle.
vuSoftInstallationDate je datum instalace verze softwaru.
2.226 VuSoftwareVersion
Číslo verze softwaru celku ve vozidle.
Přiřazení hodnoty: není specifikováno.
2.227 VuSpecificConditionData
1. generace:
Informace uložené v celku ve vozidle týkající se zvláštních podmínek.
noOfSpecificConditionRecords je počet záznamů uvedených v sadě
specificConditionRecords.
specificConditionRecords je sada záznamů týkajících se zvláštních
podmínek.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 218
2.228 VuSpecificConditionRecordArray
2. generace:
Informace uložené v celku ve vozidle týkající se zvláštních podmínek
(požadavek 130 přílohy 1C).
recordType označuje typ záznamu (SpecificConditionRecord). Přiřa­
zení hodnoty: viz RecordType
recordSize je velikost záznamu SpecificConditionRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů týkajících se zvláštních podmínek.
2.229 VuTimeAdjustmentData
1. generace:
Informace uložené v celku ve vozidle týkající se nastavení času prove­
dených mimo pravidelnou kalibraci (požadavek 101 přílohy 1B).
noOfVuTimeAdjRecords je počet záznamů v sadě vuTimeAdjustmen­
tRecords.
vuTimeAdjustmentRecords je sada záznamů o nastavení času.
▼M1
2.230 Vyhrazeno pro budoucí použití
2.231 Vyhrazeno pro budoucí použití
▼B
2.232 VuTimeAdjustmentRecord
Informace uložené v celku ve vozidle týkající se nastavení času prove­
deného mimo pravidelnou kalibraci (požadavek 101 přílohy 1B a poža­
davky 124 a 125 přílohy 1C).
1. generace:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 219
oldTimeValue, newTimeValue jsou stará a nová hodnota data a času.
workshopName, workshopAddress jsou název dílny a její adresa.
workshopCardNumber identifikuje kartu dílny použitou k nastavení
času.
2. generace:
Místo prvku workshopCardNumber používá struktura dat 2. generace
následující datový prvek.
workshopCardNumberAndGeneration identifikuje kartu dílny použ­
itou k nastavení času, včetně její generace.
2.233 VuTimeAdjustmentRecordArray
2. generace:
Informace uložené v celku ve vozidle týkající se nastavení času prove­
dených mimo pravidelnou kalibraci (požadavky 124 a 125 přílohy 1C).
recordType označuje typ záznamu (VuTimeAdjustmentRecord). Přiřa­
zení hodnoty: viz RecordType
recordSize je velikost záznamu VuTimeAdjustmentRecord v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o nastavení času.
2.234 WorkshopCardApplicationIdentification
Informace uložené na kartě dílny týkající se identifikace aplikace karty
(požadavky 307 a 330 přílohy 1C).
1. generace:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 220
typeOfTachographCardId udává implementovaný typ karty.
cardStructureVersion udává verzi struktury implementované v kartě.
noOfEventsPerType je počet událostí od každého typu události, které
lze na kartu zaznamenat.
noOfFaultsPerType je počet závad od každého druhu závady, které lze
na kartu zaznamenat.
activityStructureLength udává počet bajtů, které jsou k dispozici pro
ukládání záznamů o činnosti.
noOfCardVehicleRecords je počet záznamů o vozidle, které může karta
obsahovat.
noOfCardPlaceRecords je počet míst, která lze na kartu zaznamenat.
noOfCalibrationRecords je počet záznamů o kalibraci, který lze na
kartu uložit.
2. generace:
▼M1
Kromě prvků 1. generace se používají tyto datové prvky:
noOfGNSSADRecords je počet záznamů o součtové době řízení dle
GNSS, které lze na kartu uložit.
noOfSpecificConditionRecords je počet záznamů o zvláštní podmínce,
které lze na kartu uložit.
noOfCardVehicleUnitRecords je počet záznamů o použitých celcích ve
vozidle, které lze na kartu uložit.
▼M3
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).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 221
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. stan­
dardní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ů obsahu­
jí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).
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 222
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 WorkshopCardCalibrationRe­
cord,
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ě.
▼B
2.235 WorkshopCardCalibrationData
Informace uložené na kartě dílny týkající se činnosti dílny provedené
s kartou (požadavky 314, 316, 337 a 339 přílohy 1C).
calibrationTotalNumber je celkový počet kalibrací provedených
s kartou.
calibrationPointerNewestRecord je index naposledy aktualizovaného
záznamu o kalibraci.
Přiřazení hodnoty: číslo odpovídající čítači záznamů o kalibraci začí­
nající hodnotou „0“ u prvního výskytu záznamu o kalibraci ve struktuře.
calibrationRecords je sada záznamů obsahujících informace o kalibraci
a/nebo nastavení času.
2.236 WorkshopCardCalibrationRecord
Informace uložené na kartě dílny týkající se kalibrace provedené s kartou
(požadavky 314 a 337 přílohy 1C).
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 223
1. generace:
calibrationPurpose je účel kalibrace.
vehicleIdentificationNumber je identifikační číslo vozidla (VIN).
vehicleRegistration obsahuje registrační značku (VRN) a členský stát
registrace vozidla.
wVehicleCharacteristicConstant je charakteristický koeficient vozidla.
kConstantOfRecordingEquipment je konstanta záznamového zařízení.
lTyreCircumference je účinný obvod pneumatik na kolech.
tyreSize je označení rozměrů pneumatik namontovaných na vozidle.
authorisedSpeed je maximální dovolená rychlost vozidla.
oldOdometerValue, newOdometerValue jsou stará a nová hodnota
počitadla ujetých kilometrů.
oldTimeValue, newTimeValue jsou stará a nová hodnota data a času.
nextCalibrationDate je datum příští kalibrace typu určeného v Calibra­
tionPurpose, kterou provede schválený kontrolní orgán.
vuPartNumber, vuSerialNumber a sensorSerialNumber jsou datové
prvky pro identifikaci záznamového zařízení.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 224
2. generace:
Kromě prvků 1. generace se používají tyto datové prvky:
sensorGNSSSerialNumber identifikuje vnější zařízení GNSS.
rcmSerialNumber identifikuje modul dálkové komunikace.
sealDataCard udává informace o plombách, které jsou připojeny
k různým částem vozidla.
2.237 WorkshopCardHolderIdentification
Informace uložené na kartě dílny týkající se identifikace držitele karty
(požadavky 311 a 334 přílohy 1C).
workshopName je název dílny držitele karty.
workshopAddress je adresa dílny držitele karty.
cardHolderName je příjmení a jméno (jména) držitele (např. jméno
mechanika).
cardHolderPreferredLanguage je upřednostňovaný jazyk držitele
karty.
2.238 WorkshopCardPIN
Kód PIN karty dílny (požadavky 309 a 332 přílohy 1C).
Přiřazení hodnoty: Kód PIN známý držiteli karty, zprava doplněný
bajty „FF“ na délku 8 bajtů.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 225
2.239 W-VehicleCharacteristicConstant
Charakteristický koeficient vozidla (definice k)).
Přiřazení hodnoty: impulsy na kilometr v provozním rozsahu 0 až
64 255 impulsů/km.
2.240 VuPowerSupplyInterruptionRecord
2. generace:
Informace uložené v celku ve vozidle týkající se událostí přerušení
napájení (požadavek 117 přílohy 1C).
eventType je typ události.
eventRecordPurpose je účel, pro který byla tato událost zaznamenána.
eventBeginTime je datum a čas začátku události.
eventEndTime je datum a čas konce události.
cardNumberAndGenDriverSlotBegin identifikuje kartu vloženou do
otvoru pro kartu řidiče na začátku události, včetně její generace.
cardNumberAndGenDriverSlotEnd identifikuje kartu vloženou do
otvoru pro kartu řidiče na konci události, včetně její generace.
cardNumberAndGenCodriverSlotBegin identifikuje kartu vloženou do
otvoru pro kartu druhého řidiče na začátku události, včetně její generace.
cardNumberAndGenCodriverSlotEnd identifikuje kartu vloženou do
otvoru pro kartu druhého řidiče na konci události, včetně její generace.
similarEventsNumber je počet podobných událostí v daný den.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 226
2.241 VuPowerSupplyInterruptionRecordArray
2. generace:
Informace uložené v celku ve vozidle týkající se událostí přerušení
napájení (požadavek 117 přílohy 1C).
recordType označuje typ záznamu (VuPowerSupplyInterruptionRe­
cord). Přiřazení hodnoty: viz RecordType
recordSize je velikost záznamu VuPowerSupplyInterruptionRecord
v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o událostech přerušení napájení.
2.242 VuSensorExternalGNSSCoupledRecordArray
2. generace:
Sada záznamů SensorExternalGNSSCoupledRecord a metadata použitá
v protokolu pro stahování.
recordType označuje typ záznamu (SensorExternalGNSSCoupledRe­
cord). Přiřazení hodnoty: viz RecordType
recordSize je velikost záznamu SensorExternalGNSSCoupledRecord
v bajtech.
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o vazbě externího snímače GNSS.
2.243 VuSensorPairedRecordArray
2. generace:
Sada záznamů SensorPairedRecord a metadata použitá v protokolu pro
stahování.
recordType označuje typ záznamu (SensorPairedRecord). Přiřazení
hodnoty: viz RecordType
recordSize je velikost záznamu SensorPairedRecord v bajtech.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 227
noOfRecords je počet záznamů v sadě záznamů.
records je sada záznamů o párování snímače.
3. DEFINICE HODNOT A ROZSAHŮ VELIKOSTÍ
Definice hodnot proměnných použitých pro definice v odstavci 2.
4. ZNAKOVÉ SADY
V řetězcích IA5Strings se používají znaky ASCII dle definice v ISO/IEC
8824-1. Pro čitelnost a snadné odkazování je přiřazení hodnoty uvedeno
dále. V případě nesrovnalostí má norma ISO/IEC 8824-1 přednost před
touto informativní poznámkou.
Další řetězce znaků (Address, Name, VehicleRegistrationNumber) navíc
používají i znaky z rozsahu dekadických kódů znaků 161–255 z násle­
dujících 8-bitových standardních znakových sad určených číslem
kódové stránky:
Standardní znaková sada
Kódová stránka
(dekadicky)
ISO/IEC 8859-1 Latinka 1 – západoevropské jazyky 1
ISO/IEC 8859-2 Latinka 2 – středoevropské jazyky 2
ISO/IEC 8859-3 Latinka 3 – jihoevropské jazyky 3
ISO/IEC 8859-5 Latinka / cyrilice 5
ISO/IEC 8859-7 Latinka / řecká abeceda 7
ISO/IEC 8859-9 Latinka 5 – turečtina 9
ISO/IEC 8859-13 Latinka 7 – pobaltské jazyky 13
ISO/IEC 8859-15 Latinka 9 15
ISO/IEC 8859-16 Latinka 10 – jazyky jihovýchodní Evropy 16
KOI8-R Latinka / cyrilice 80
KOI8-U Latinka / cyrilice 85
5. KÓDOVÁNÍ
Při kódování dle pravidel ASN.1 musí být všechny datové typy kódo­
vány podle ISO/IEC 88252 v zarovnané variantě.
6. IDENTIFIKÁTORY OBJEKTŮ A IDENTIFIKÁTORY APLIKACÍ
6.1 Identifikátory objektů
Identifikátory objektů (OID) uvedené v této kapitole se vztahují
pouze na 2. generaci. Tyto OID jsou stanoveny v TR-03110-3 a zde
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 228
jsou zopakovány z důvodu úplnosti. Tyto OID jsou obsaženy
v podstromu bsi-de:
Identifikátory protokolu ověření pravosti celku ve vozidle
Příklad: Má-li být ověření pravosti celku ve vozidle prováděno pomocí
SHA-384, musí být použit identifikátor objektu (v notaci ASN.1)
. Hodnota
tohoto identifikátoru objektu v tečkové notaci je
.
Tečková notace Bajtová notace
„04 00 7F 00 07 02 02 02 02 03“
„04 00 7F 00 07 02 02 02 02 04“
„04 00 7F 00 07 02 02 02 02 05“
Identifikátory protokolu ověření pravosti čipu
Příklad: Ověření pravosti čipu má být provedeno pomocí algoritmu
ECDH a jeho výsledkem klíč relace AES o délce 128 bitů.
Tento klíč relace bude následně použit v režimu CBC k zajištění
důvěrnosti dat a v algoritmu CMAC k zaručení pravosti
dat. Použije se tedy identifikátor objektu (v notaci ASN.1)
. Hodnota
tohoto identifikátoru objektu v tečkové notaci je
.
Tečková notace Bajtová notace
„04 00 7F 00 07 02 02 03 02 02“
„04 00 7F 00 07 02 02 03 02 03“
„04 00 7F 00 07 02 02 03 02 04“
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 229
6.2 Identifikátory aplikací
2. generace:
Identifikátor aplikace (AID) pro vnější zařízení GNSS (2. generace) je
dán řetězcem „FF 44 54 45 47 4D“. Jde o proprietární AID podle
ISO/IEC 7816-4.
Poznámka: Posledních 5 bajtů kóduje DTEGM pro vnější zařízení
GNSS inteligentního tachografu.
Identifikátor aplikace pro aplikaci karty tachografu 2. generace je dán
řetězcem „FF 53 4D 52 44 54“. Jde o proprietární AID podle ISO/IEC
7816-4.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 230
Dodatek 2
SPECIFIKACE KARET TACHOGRAFU
OBSAH
1. ÚVOD
1.1 Zkratky
1.2 Odkazy
2. ELEKTRICKÉ A FYZICKÉ VLASTNOSTI
2.1 Napájecí napětí a spotřeba proudu
2.2 Programovací napětí V pp
2.3 Generátor hodinových impulsů a frekvence
2.4 Kontakt I/O
2.5 Stavy karty
3. HARDWARE A KOMUNIKACE
3.1 Úvod
3.2 Protokol pro přenos dat
3.2.1 Protokoly
3.2.2 ATR
3.2.3 PTS
3.3 Pravidla přístupu
3.4 Přehled příkazů a kódů chyb
3.5 Popisy příkazů
3.5.1 SELECT
3.5.2 READ BINARY
3.5.3 UPDATE BINARY
3.5.4 GET CHALLENGE
3.5.5 VERIFY
3.5.6 GET RESPONSE
3.5.7 PSO: VERIFY CERTIFICATE
3.5.8 INTERNAL AUTHENTICATE
3.5.9 EXTERNAL AUTHENTICATE
3.5.10 GENERAL AUTHENTICATE
3.5.11 MANAGE SECURITY ENVIRONMENT
3.5.12 PSO: HASH
3.5.13 PERFORM HASH of FILE
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 231
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE
3.5.15 PSO: VERIFY DIGITAL SIGNATURE
3.5.16 PROCESS DSRC MESSAGE
4. STRUKTURA KARET TACHOGRAFU
4.1 Hlavní soubor MF
4.2 Aplikace karty řidiče
4.2.1 Aplikace karty řidiče 1. generace
4.2.2 Aplikace karty řidiče 2. generace
4.3 Aplikace karty dílny
4.3.1 Aplikace karty dílny 1. generace
4.3.2 Aplikace karty dílny 2. generace
4.4 Aplikace kontrolní karty
4.4.1 Aplikace kontrolní karty 1. generace
4.4.2 Aplikace kontrolní karty 2. generace
4.5 Aplikace karty podniku
4.5.1 Aplikace karty podniku 1. generace
4.5.2 Aplikace karty podniku 2. generace
1. ÚVOD
1.1 Zkratky
Pro účely tohoto dodatku se použijí tyto zkratky:
AC podmínky přístupu (Access conditions)
AES pokročilý standard pro šifrování (Advanced Encryption
Standard)
AID identifikátor aplikace (Application Identifier)
ALW vždy (Always)
APDU datová jednotka aplikačního protokolu (Application
Protocol Data Unit, struktura příkazu)
ATR odpověď na reset (Answer To Reset)
AUT ověřena pravost (Authenticated)
C6, C7 kontakty č. 6 a 7 karty, jak popisuje norma ISO/IEC
7816-2
cc hodinové takty (clock cycles)
▼M1
CHA autorizace držitele certifikátu
▼B
CHV informace k ověření držitele karty (Card holder Verifica­
tion Information)
CLA bajt třídy (Class) příkazu APDU
▼M1
DO datový objekt
▼B
DSRC vyhrazené komunikace krátkého dosahu (Dedicated Short
Range Communication)
DF vyhrazený soubor (Dedicated File). DF může obsahovat
jiné soubory (EF nebo DF)
ECC kryptografie na bázi eliptických křivek (Elliptic Curve
Cryptography)
EF elementární soubor (Elementary File)
etu základní časová jednotka (elementary time unit)
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 232
G1 1. generace
G2 2. generace
IC integrovaný obvod (Integrated Circuit)
ICC karta s integrovaným obvodem, čipová karta (Integrated
Circuit Card)
ID identifikátor
IFD zařízení rozhraní (Interface Device)
IFS velikost informačního pole (Information Field Size)
IFSC velikost informačního pole pro kartu (Information Field
Size for the card)
IFSD velikost informačního pole zařízení (Information Field
Size Device, pro terminál)
INS bajt instrukce (Instruction) příkazu APDU
Lc délka vstupních dat pro příkaz APDU
Le délka očekávaných dat (výstupních dat pro příkaz)
MF hlavní soubor (Master File, kořenový DF)
NAD adresa uzlu (Node Address) používaná v protokolu T=1
NEV nikdy (Never)
P1-P2 bajty parametrů
PIN kód PIN (Personal Identification Number)
PRO SM chráněno bezpečným předáváním zpráv (Protected with
secure messaging)
PTS výběr přenosového protokolu (Protocol Transmission
Selection)
RFU vyhrazeno pro budoucí použití (Reserved for Future Use)
RST reset (karty)
SFID krátký identifikátor EF (Short EF Identifier)
SM bezpečné předávání zpráv (Secure Messaging)
SW1-SW2 stavové bajty
TS počáteční znak ATR
VPP programovací napětí
VU celek ve vozidle (Vehicle Unit)
XXh hodnota XX v hexadecimální notaci
„XXh“ hodnota XX v hexadecimální notaci
|| symbol zřetězení: 03||04=0304
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 233
1.2 Odkazy
V tomto dodatku se používají tyto odkazy:
ISO/IEC 7816-2 Identification cards – Integrated circuit cards –
Part 2: Dimensions and location of the contacts.
ISO/IEC 7816-2:2007.
ISO/IEC 7816-3 Identification cards – Integrated circuit cards –
Part 3: Electrical interface and transmission
protocols. ISO/IEC 7816-3:2006.
ISO/IEC 7816-4 Identification cards – Integrated circuit cards –
Part 4: Organization, security and commands for
interchange. ISO/IEC 7816-4:2013 + Cor 1: 2014.
ISO/IEC 7816-6 Identification cards – Integrated circuit cards –
Part 6: Interindustry data elements for
interchange. ISO/IEC 7816-6:2004 + Cor 1: 2006.
ISO/IEC 7816-8 Identification cards – Integrated circuit cards –
Part 8: Commands for security operations.
ISO/IEC 7816-8:2004.
ISO/IEC 9797-2 Information technology – Security techniques –
Message Authentication Codes (MACs) – Part 2:
Mechanisms using a dedicated hash-function.
ISO/IEC 9797-2:2011
2. ELEKTRICKÉ A FYZICKÉ VLASTNOSTI
TCS_01 Všechny elektronické signály musí být v souladu s normou
ISO/IEC 7816-3, pokud není uvedeno jinak.
TCS_02 Umístění kontaktů karty a jejich rozměry musí být
v souladu s normou ISO/IEC 7816-2.
2.1 Napájecí napětí a spotřeba proudu
TCS_03 Karta pracuje podle specifikace uvnitř hranic spotřeby
podle ISO/IEC 7816-3.
TCS_04 Karta pracuje při Vcc = 3 V (± 0,3 V) nebo při Vcc = 5 V
(± 0,5 V).
Volba napětí se provádí v souladu s ISO/IEC 7816-3.
2.2 Programovací napětí V pp
TCS_05 Karta nevyžaduje na kontaktu C6 programovací napětí.
Předpokládá se, že kontakt C6 není v zařízení
rozhraní (IFD) zapojen. Kontakt C6 může být na kartě
spojen s napětím V cc , nesmí být ale uzemněn. Toto napětí
nesmí být v žádném případě interpretováno.
2.3 Generátor hodinových impulsů a frekvence
TCS_06 Karta pracuje v rozsahu frekvencí 1 až 5 MHz a může
podporovat vyšší frekvence. V rámci jedné relace karty
se hodinová frekvence může měnit ± 2 %. Hodinová
frekvence je generována celkem ve vozidle, ne kartou.
Střída se může pohybovat od 40 do 60 %.
TCS_07 Za podmínek obsažených v souboru EF ICC karty mohou
být vnější hodiny zastaveny. První bajt těla souboru EF
ICC kóduje podmínky režimu Clockstop:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 234
Úroveň L Úroveň H
Bit 3 Bit 2 Bit 1
0 0 1
Režim Clockstop dovolen, žádná preferovaná
úroveň
0 1 1 Režim Clockstop dovolen, preferována úroveň H
1 0 1 Režim Clockstop dovolen, preferována úroveň L
0 0 0 Režim Clockstop není dovolen
0 1 0 Režim Clockstop dovolen pouze při úrovni H
1 0 0 Režim Clockstop dovolen pouze při úrovni L
Bity 4 až 8 nejsou použity.
2.4 Kontakt I/O
TCS_08 Kontakt I/O (C7) slouží pro příjem dat ze zařízení
rozhraní (IFD) a pro vysílání dat do IFD. Během provozu
se nachází v režimu vysílání buď jen karta, nebo IFD.
Jsou-li v režimu vysílání obě jednotky, nesmí tím být
karta poškozena. Pokud karta nevysílá, musí být v režimu
příjmu.
2.5 Stavy karty
TCS_09 Při připojeném napájecím napětí pracuje karta ve dvou
stavech:
▼M3
provozní stav během vykonávání příkazů nebo propojení
s celkem ve vozidle,
▼B
klidovém stavu v ostatním čase; v tomto stavu musejí být
zachována všechna data na kartě.
3. HARDWARE A KOMUNIKACE
3.1 Úvod
Tento odstavec popisuje minimální funkčnost požadovanou kartami
tachografu a celky ve vozidle k zajištění správného provozu a intero­
perability.
Karty tachografu jsou v maximální možné míře v souladu s dostup­
nými normami ISO/IEC (především ISO/IEC 7816). Příkazy a proto­
koly jsou nicméně plně popsány, aby bylo specifikováno určité
omezené použití nebo některé rozdíly, pokud existují. Specifikované
příkazy plně odpovídají normám, na něž se odkazuje, pokud není
uvedeno jinak.
3.2 Protokol pro přenos dat
TCS_10 Protokol pro přenos dat je v souladu s normou ISO/IEC
7816-3 pro T = 0 a T = 1. Celek ve vozidle konkrétně
respektuje prodloužení čekací doby odesílaná kartou.
3.2.1 Protokoly
TCS_11 Karta podporuje jak protokol T=0, tak protokol T=1. Karta
může navíc podporovat další protokoly založené na
kontaktech.
TCS_12 T=0 je výchozí protokol, pro změnu na protokol T=1 je
tedy nutný příkaz PTS.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 235
TCS_13 Zařízení podporují v obou protokolech „přímou
konvenci“, která je proto pro kartu povinná.
TCS_14 Bajt IFSC (velikost informačního pole karty) je uveden
v ATR ve znaku TA3. Tato hodnota činí nejméně „F0h“
(= 240 bajtů).
Pro protokoly platí následující omezení:
TCS_15 T=0
— Zařízení rozhraní podporuje odpověď na I/O po
náběžné hraně signálu RST od 400 cc.
— Zařízení rozhraní musí být schopno číst znaky oddělené
12 etu.
— Zařízení rozhraní čte chybný znak a jeho opakování,
jestliže jsou odděleny 13 etu. Jestliže je detekován
chybný znak, signál chyby se na I/O může objevit
mezi 1 etu a 2 etu. Zařízení podporuje prodlevu 1 etu.
— Zařízení rozhraní akceptuje 33 bajtů ATR (TS+32).
— Jestliže se v ATR nachází TC1, použije se u znaků
odesílaných zařízením rozhraní prodloužená ochranná
doba Extra Guard Time, ačkoliv znaky odesílané kartou
mohou být nadále odděleny 12 etu. To také platí pro
znak ACK odeslaný kartou po vyslání znaku P3 zaří­
zením rozhraní.
— Zařízení rozhraní bere v úvahu znak NUL odeslaný
kartou.
— Zařízení rozhraní akceptuje komplementární režim pro
ACK.
— Příkaz get-response nelze použít v režimu zřetězení
k získání dat, jejichž délka by mohla přesáhnout 255
bajtů.
TCS_16 T=1
— Bajt NAD: nepoužívá se (NAD se nastaví na „00“).
— S-blok ABORT: nepoužívá se.
— S-blok VPP state error: nepoužívá se.
▼M3
__________
▼B
— IFD bezprostředně po ATR uvede velikost informač­
ního pole zařízení (IFSD): IFD vyšle S-blok IFS request
po ATR a karta pošle zpět S-blok IFS. Doporučená
hodnota IFSD je 254 bajtů.
— Karta nežádá o nové nastavení IFS.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 236
3.2.2 ATR
TCS_17 Zařízení kontroluje bajty ATR podle normy ISO/IEC 7816-
3. Historické znaky ATR se nekontrolují.
Příklad základní ATR pro dva protokoly podle normy
ISO/IEC 7816-3
Znak Hodnota Poznámky
TS „3Bh“ Indikuje přímou konvenci
T0 „85h“ TD1 přítomen; přítomno 5 historických bajtů
TD1 „80h“ TD2 přítomen; použije se T=0
TD2 „11h“ TA3 přítomen; použije se T=1
TA3 „XXh“ (minimálně
„F0h“)
Information Field Size Card (IFSC)
TH1 až TH5 „XXh“ Historické znaky
TCK „XXh“ Kontrolní znak (XOR)
TCS_18 Po odpovědi na reset (ATR) je implicitně vybrán hlavní
soubor (MF) a stává se aktuálním adresářem.
3.2.3 PTS
TCS_19 Výchozí protokol je T=0. Pro nastavení protokolu T=1
musí zařízení kartě poslat příkaz PTS (také známý jako
PPS).
TCS_20 Poněvadž protokoly T=0 i T=1 jsou pro kartu povinné,
základní PTS pro přepínání protokolů je pro kartu povinný.
Jak je uvedeno v normě ISO/IEC 7816-3, lze PTS použít
pro přepnutí na vyšší rychlost přenosu dat než rychlost
výchozí, kterou karta případně navrhla v ATR (bajt TA(1)).
Vyšší rychlosti přenosu dat jsou pro kartu volitelné.
TCS_21 Jestliže žádné jiné rychlosti přenosu dat kromě výchozí
rychlosti nejsou podporovány (nebo není podporována
zvolená rychlost přenosu dat), odpoví karta na PTS
korektně podle normy ISO/IEC 7816-3 vynecháním bajtu
PPS1.
Příklady základního PTS pro výběr protokolu:
Znak Hodnota Poznámky
PPSS „FFh“ Zahajovací znak.
PPS0 „00h“ nebo
„01h“
PPS1 až PPS3 nejsou přítomny; „00h“ pro výběr T0,
„01h“ pro výběr T1.
PK „XXh“ Kontrolní znak: „XXh“ = „FFh“ pokud PPS0 = „00h“,
„XXh“ = „FEh“ pokud PPS0 = „01h“.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 237
3.3 Pravidla přístupu
TCS_22 Pravidlo přístupu specifikuje pro režim přístupu, např.
příkaz, příslušné bezpečnostní podmínky. Příslušný příkaz
je zpracován, pokud jsou tyto bezpečnostní podmínky
splněny.
TCS_23 Pro kartu tachografu se používají tyto bezpečnostní
podmínky:
Zkratka Význam
ALW Akce je vždy možná a může být provedena bez omezení. APDU příkazu
a odpovědi se posílá jako otevřený text, tj. bez bezpečného předávání zpráv.
NEV Akce není nikdy možná.
PLAIN-C APDU příkazu se posílá otevřeně, tj. bez bezpečného předávání zpráv.
PWD Akce může být provedena pouze v případě, že byl úspěšně ověřen kód PIN
karty dílny, tj. je nastaven vnitřní bezpečnostní status karty „PIN_Verified“.
Příkaz musí být odeslán bez bezpečného předávání zpráv.
EXT-AUT-G1 Akce může být provedena pouze v případě, že byl úspěšně proveden příkaz
EXTERNAL AUTHENTICATE k ověření pravosti 1. generace (viz rovněž
dodatek 11 část A).
SM-MAC-G1 APDU (příkaz a odezva) se musí použít s bezpečným předáváním zpráv 1.
generace v režimu pouze s ověřením pravosti (viz dodatek 11 část A).
SM-C-MAC-G1 APDU příkazu se musí použít s bezpečným předáváním zpráv 1. generace
v režimu pouze s ověřením pravosti (viz dodatek 11 část A).
SM-R-ENC-G1 APDU odpovědi se musí použít s bezpečným předáváním zpráv 1. generace
v režimu šifrování (viz dodatek 11 část A), tj. nevrací se ověřovací kód
zprávy (MAC).
SM-R-ENC-
MAC-G1
APDU odpovědi se musí použít s bezpečným předáváním zpráv 1. generace
v režimu šifrování a následného ověření pravosti (viz dodatek 11 část A).
SM-MAC-G2 APDU (příkaz a odezva) se musí použít s bezpečným předáváním zpráv 2.
generace v režimu pouze s ověřením pravosti (viz dodatek 11 část B).
SM-C-MAC-G2 APDU příkazu se musí použít s bezpečným předáváním zpráv 2. generace
v režimu pouze s ověřením pravosti (viz dodatek 11 část B).
SM-R-ENC-
MAC-G2
APDU odpovědi se musí použít s bezpečným předáváním zpráv 2. generace
v režimu šifrování a následného ověření pravosti (viz dodatek 11 část B).
▼M1
TCS_24 Uvedené bezpečnostní podmínky mohou být spojeny takto:
AND: všechny bezpečnostní podmínky musí být splněny,
OR: alespoň jedna bezpečnostní podmínka musí být
splněna.
Pravidla přístupu pro systém souborů, tj. pro příkazy
SELECT, READ BINARY a UPDATE BINARY, jsou
stanovena v kapitole 4. Pravidla přístupu pro zbývající
příkazy jsou stanovena v následujících tabulkách. Výraz
„nepoužije se“ je uveden v případě, že příkaz nemusí být
podporován. V takovém případě může být příkaz podpo­
rován či nikoli, ale podmínka přístupu je mimo působnost.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 238
TCS_25 V aplikaci DF Tachograph G1 se používají tato pravidla
přístupu:
▼M1
Příkaz Karta řidiče Karta dílny Kontrolní karta Karta podniku
External Authenticate
— pro ověření pravosti 1.
generace
ALW ALW ALW ALW
— pro ověření pravosti 2.
generace
ALW PWD ALW ALW
Internal Authenticate ALW PWD ALW ALW
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message Nepoužije se Nepoužije se Nepoužije se Nepoužije se
PSO: Compute Digital Signature ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
Nepoužije se Nepoužije se
PSO: Hash Nepoužije se Nepoužije se ALW Nepoužije se
PERFORM HASH of FILE ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
Nepoužije se Nepoužije se
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature Nepoužije se Nepoužije se ALW Nepoužije se
Verify Nepoužije se ALW Nepoužije se Nepoužije se
▼B
TCS_26 V aplikaci DF Tachograph_G2 se používají tato pravidla
přístupu:
▼M1
Příkaz Karta řidiče Karta dílny Kontrolní karta Karta podniku
External Authenticate
— pro ověření pravosti 1.
generace
Nepoužije se Nepoužije se Nepoužije se Nepoužije se
— pro ověření pravosti 2.
generace
ALW PWD ALW ALW
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 239
Příkaz Karta řidiče Karta dílny Kontrolní karta Karta podniku
Internal Authenticate Nepoužije se Nepoužije se Nepoužije se Nepoužije se
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message Nepoužije se ALW ALW Nepoužije se
PSO: Compute Digital Signature ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
Nepoužije se Nepoužije se
PSO: Hash Nepoužije se Nepoužije se ALW Nepoužije se
PERFORM HASH of FILE ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
Nepoužije se Nepoužije se
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature Nepoužije se Nepoužije se ALW Nepoužije se
Verify Nepoužije se ALW Nepoužije se Nepoužije se
▼B
TCS_27 V MF se používají tato pravidla přístupu:
▼M1
Příkaz Karta řidiče Karta dílny Kontrolní karta Karta podniku
External Authenticate
— pro ověření pravosti 1.
generace
Nepoužije se Nepoužije se Nepoužije se Nepoužije se
— pro ověření pravosti 2.
generace
ALW PWD ALW ALW
Internal Authenticate Nepoužije se Nepoužije se Nepoužije se Nepoužije se
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 240
Příkaz Karta řidiče Karta dílny Kontrolní karta Karta podniku
Process DSRC Message Nepoužije se Nepoužije se Nepoužije se Nepoužije se
PSO: Compute Digital Signature Nepoužije se Nepoužije se Nepoužije se Nepoužije se
PSO: Hash Nepoužije se Nepoužije se Nepoužije se Nepoužije se
PERFORM HASH of FILE Nepoužije se Nepoužije se Nepoužije se Nepoužije se
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature Nepoužije se Nepoužije se Nepoužije se Nepoužije se
Verify Nepoužije se ALW Nepoužije se Nepoužije se
▼B
TCS_28 Karta tachografu může, ale nemusí přijmout příkaz s vyšší
úrovní zabezpečení, než jaká je uvedena v bezpečnostních
podmínkách. Tj. je-li bezpečnostní podmínka ALW (nebo
PLAIN-C), karta může přijmout příkaz s bezpečným před­
áváním zpráv (v režimu šifrování a/nebo ověření pravosti).
Vyžaduje-li bezpečnostní podmínka bezpečné předávání
zpráv s režimem ověření pravosti, karta tachografu může
přijmout příkaz s bezpečným předáváním zpráv téže gene­
race v režimu ověření pravosti a šifrování.
Poznámka: Více informací o podpoře příkazů pro různé
typy karet tachografů a různé DF je uvedeno v popisech
příkazů.
3.4 Přehled příkazů a kódů chyb
Příkazy a organizace souborů jsou odvozeny od normy ISO/IEC
7816-4 a jsou s ní v souladu.
Tato část popisuje následující páry APDU příkaz-odpověď. Varianty
příkazů, které jsou podporovány aplikací 1. a 2. generace, jsou
uvedeny v příslušných popisech příkazů.
Příkaz INS
SELECT „A4h“
READ BINARY „B0h“, „B1h“
UPDATE BINARY „D6h“, „D7h“
GET CHALLENGE „84h“
VERIFY „20h“
GET RESPONSE „C0h“
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 241
Příkaz INS
PERFORM SECURITY OPERA­
TION
„2Ah“
— VERIFY CERTIFICATE
— COMPUTE DIGITAL SIGNA­
TURE
— VERIFY DIGITAL SIGNA­
TURE
— HASH
— PERFORM HASH OF FILE
— PROCESS DSRC MESSAGE
INTERNAL AUTHENTICATE „88h“
EXTERNAL AUTHENTICATE „82h“
MANAGE SECURITY ENVIRON­
MENT
„22h“
— SET DIGITAL SIGNATURE
TEMPLATE
— SET AUTHENTICATION
TEMPLATE
GENERAL AUTHENTICATE „86h“
▼M1
TCS_29 V každé zprávě s odpovědí jsou vrácena stavová slova
SW1 SW2, která označují stav zpracování příkazu.
SW1 SW2 Význam
90 00 Normální zpracování
61 XX Normální zpracování XX = počet dostupných bajtů odpovědi
62 81 Zpracování s varováním. Část vrácených dat může být poško­
zena.
63 00 Chyba ověření pravosti (varování)
63 CX Chybné CHV (kód PIN). „X“ poskytuje stav čítače zbývajících
pokusů.
64 00 Chyba provádění – stav paměti nezávislé na napájení nezměněn.
Chyba integrity.
65 00 Chyba provádění – stav paměti nezávislé na napájení změněn.
65 81 Chyba provádění – stav paměti nezávislé na napájení změněn –
porucha paměti.
66 88 Chyba zabezpečení: chybný kryptografický kontrolní součet
(při bezpečném předávání zpráv) nebo
chybný certifikát (při ověřování certifikátu)
nebo
chybný kryptogram (při externím ověřo­
vání pravosti) nebo
chybný podpis (při ověřování podpisu)
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 242
SW1 SW2 Význam
67 00 Chybná délka (chybná hodnota Lc nebo Le)
68 83 Očekáván poslední příkaz řetězce
69 00 Zakázaný příkaz (žádná dostupná odpověď v T=0)
69 82 Bezpečnostní status nesplněn
69 83 Metoda ověření pravosti zablokována
69 85 Podmínky použití nesplněny
69 86 Nedovolený příkaz (žádný aktuální EF)
69 87 Chybí očekávané datové objekty bezpečného předávání zpráv.
69 88 Chybné datové objekty bezpečného předávání zpráv
6A 80 Chybné parametry v datovém poli
6A 82 Soubor nenalezen
6A 86 Chybné parametry P1-P2
6A 88 Odkazovaná data nenalezena
6B 00 Chybné parametry (offset mimo EF)
6C XX Chybná délka, SW2 udává přesnou délku. Není vráceno žádné
datové pole.
6D 00 Kód instrukce není podporován nebo je neplatný.
6E 00 Třída není podporována.
6F 00 - Jiné chyby kontroly
Mohou být vrácena další stavová slova definovaná v normě
ISO/IEC 7816-4, pokud jejich chování není výslovně
uvedeno v tomto dodatku.
Volitelně mohou být vrácena například tato stavová slova:
6881: Logický kanál není podporován.
6882: Bezpečné předávání zpráv není podporováno.
▼B
TCS_30 Nastane-li v jednom APDU příkazu více než jedna chybová
podmínka, může karta vrátit kterékoli příslušné stavové
slovo.
3.5 Popisy příkazů
V této kapitole jsou popsány povinné příkazy pro karty tachografu.
Další významné podrobnosti vztahující se k obsaženým kryptogra­
fickým operacím jsou uvedeny v dodatku 11 „Společné bezpečnostní
mechanismy“ pro tachograf 1. a 2. generace.
Všechny příkazy jsou popsány nezávisle na použitém protokolu (T=0
nebo T=1). Bajty CLA, INS, P1, P2, Lc a Le v APDU jsou vždy
uvedeny. Jestliže Lc a Le nejsou potřebné pro popisovaný příkaz,
zůstanou odpovídající délka, hodnota a popis prázdné.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 243
TCS_31 Jsou-li požadovány oba bajty délky (Lc a Le), je třeba
v případě, že IFD používá protokol T=0, popisovaný příkaz
rozdělit na dvě části: IFD odešle příkaz podle popisu
s P3=Lc + data a pak odešle příkaz GET RESPONSE
(viz část 3.5.6) s P3=Le.
TCS_32 Jsou-li požadovány oba bajty délky a Le=0 (bezpečné před­
ávání zpráv):
— při použití protokolu T=1 karta na Le=0 odpoví odes­
láním všech výstupních dat, která jsou k dispozici,
— při použití protokolu T=0 vyšle IFD první příkaz
s P3=Lc + data a karta odpoví (na toto implicitní
Le=0) stavovými bajty „61La“, kde La je počet dostup­
ných bajtů odpovědi. IFD potom generuje příkaz GET
RESPONSE s P3=La pro čtení dat.
TCS_33 Karta tachografu může jako volitelnou funkci podporovat
rozšířená pole délky podle ISO/IEC 7816-4. Karta tacho­
grafu, která podporuje rozšířená pole délky, musí:
— uvádět podporu rozšířených polí délky v ATR,
— uvádět podporované velikosti vyrovnávacích pamětí
v rámci informací o rozšířené délce v EF ATR/INFO,
viz TCS_146,
— uvádět, zda podporuje rozšířená pole délky pro T = 1
a/nebo T = 0, v EF Extended Length, viz TCS_147,
— podporovat rozšířená pole délky pro aplikaci tachografu
1. a 2. generace.
Poznámky:
Všechny příkazy jsou specifikovány pro krátká pole délky.
Použití APDU s rozšířenou délkou je zřejmé z normy
ISO/IEC 7816-4.
Příkazy jsou obecně specifikovány pro otevřený režim, tj.
bez bezpečného předávání zpráv, přičemž vrstva bezpeč­
ného předávání zpráv je specifikována v dodatku 11.
Z pravidel přístupu pro daný příkaz je zřejmé, zda příkaz
podporuje bezpečné předávání zpráv či nikoli a zda příkaz
musí podporovat bezpečné předávání zpráv 1. generace
a/nebo 2. generace. Některé varianty příkazů jsou popsány
s bezpečným předáváním zpráv, aby bylo znázorněno
použití bezpečného předávání zpráv.
TCS_34 Celek ve vozidle musí pro danou relaci provést celý
protokol 2. generace pro vzájemné ověření pravosti celku
ve vozidle a karty, včetně ověření certifikátu (je-li požado­
váno), buď v DF Tachograph, v DF Tachograph_G2, nebo
v MF.
3.5.1 SELECT
Tento příkaz je v souladu s normou ISO/IEC 7816-4, jeho použití je
ale ve srovnání s příkazem definovaným normou omezené.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 244
Příkaz SELECT se používá:
— k výběru DF aplikace (musí být použit výběr podle názvu),
— k výběru elementárního souboru odpovídajícího uvedenému ID
souboru.
3.5.1.1 V ý b ě r p o d l e n á z v u ( A I D )
Tento příkaz umožňuje výběr DF aplikace na kartě.
TCS_35 Tento příkaz lze provést odkudkoli ve struktuře souborů
(po ATR nebo kdykoliv).
TCS_36 Výběrem aplikace se resetuje aktuální bezpečnostní
prostředí. Po provedení výběru aplikace již není vybrán
žádný aktuální veřejný klíč. Přístupová podmínka
EXT-AUT-G1 je rovněž ztracena. Byl-li příkaz proveden
bez bezpečného předávání zpráv, předchozí klíče relace
bezpečného předávání zpráv již nejsou dostupné.
TCS_37 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „A4h“
P1 1 „04h“ Výběr podle názvu (AID)
P2 1 „0Ch“ Neočekává se žádná odpověď
Lc 1 „NNh“ Počet bajtů odeslaných kartě (délka AID):
„06h“ pro aplikaci tachografu
#6-#(5+NN) NN „XX..XXh“ AID: „FF 54 41 43 48 4F“ pro aplikaci tachografu 1.
generace
AID: „FF 53 4D 52 44 54“ pro aplikaci tachografu 2.
generace
Na příkaz SELECT není nutná žádná odpověď (Le chybí
v T=1 nebo se nepožaduje odpověď v T=0).
TCS_38 Zpráva s odpovědí (nepožaduje se odpověď)
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Pokud aplikace odpovídající AID není nalezena, je
vrácen stav zpracování „6A82“.
— Pokud je v T=1 přítomen bajt Le, je vrácen stav zpra­
cování „6700“.
— Pokud je v T=0 po příkazu SELECT vyžadována
odpověď, je vrácen stav „6900“.
▼M1
— Je-li vybraná aplikace považována za poškozenou (v
atributech souboru je detekována chyba integrity), je
vrácen stav zpracování „6400“ nebo „6500“.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 245
3.5.1.2 V ý b ě r e l e m e n t á r n í h o s o u b o r u p o m o c í j e h o i d e n ­
t i f i k á t o r u s o u b o r u
TCS_39 Zpráva s příkazem
TCS_40 Karta tachografu musí pro tuto variantu příkazu podporovat
bezpečné předávání zpráv 2. generace, jak je specifikováno
v dodatku 11 části B.
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „A4h“
P1 1 „02h“ Výběr EF v rámci aktuálního DF
P2 1 „0Ch“ Neočekává se žádná odpověď
Lc 1 „02h“ Počet bajtů odeslaných kartě
#6-#7 2 „XXXXh“ Identifikátor souboru
Na příkaz SELECT není nutná žádná odpověď (Le chybí
v T=1 nebo se nepožaduje odpověď v T=0).
TCS_41 Zpráva s odpovědí (nepožaduje se odpověď)
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Pokud soubor odpovídající identifikátoru souborů není
nalezen, je vrácen stav zpracování „6A82“.
— Pokud je v T=1 přítomen bajt Le, je vrácen stav zpra­
cování „6700“.
— Pokud je v T=0 po příkazu SELECT vyžadována
odpověď, je vrácen stav „6900“.
▼M1
— Je-li vybraný soubor považován za poškozený (v atri­
butech souboru je detekována chyba integrity), je
vrácen stav zpracování „6400“ nebo „6500“.
▼B
3.5.2 READ BINARY
Tento příkaz je v souladu s normou ISO/IEC 7816-4, jeho použití je
ale ve srovnání s příkazem definovaným normou omezené.
Příkaz READ BINARY se používá ke čtení dat z transparentního
souboru.
Odpověď karty sestává z vrácení přečtených dat, volitelně zapouzdře­
ných ve struktuře bezpečného předávání zpráv.
3.5.2.1 P ř í k a z s o f f s e t e m v P 1 - P 2
Tento příkaz umožňuje IFD číst data z aktuálně vybraného EF bez
bezpečného předávání zpráv.
Poznámka: Tento příkaz bez bezpečného předávání zpráv lze použít
pouze pro čtení souboru, který podporuje bezpečnostní podmínku
ALW pro režim přístupu pro čtení.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 246
TCS_42 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „B0h“ Read Binary
P1 1 „XXh“ Offset v bajtech od začátku souboru: nejvýznamnější bajt
P2 1 „XXh“ Offset v bajtech od začátku souboru: nejméně významný
bajt
Le 1 „XXh“ Délka očekávaných dat. Počet bajtů ke čtení.
Poznámka: bit 8 v P1 musí být nastaven na 0.
TCS_43 Zpráva s odpovědí
Bajt Délka Hodnota Popis
#1-#X X „XX..XXh“ Přečtená data
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Není-li vybrán žádný EF, je vrácen stav zpracování
„6986“.
— Nejsou-li splněny bezpečnostní podmínky zvoleného
souboru, příkaz se přeruší se stavem „6982“.
— Není-li offset kompatibilní s velikostí EF (offset > veli­
kost EF), je vrácen stav zpracování „6B00“.
— Není-li velikost dat ke čtení kompatibilní s velikostí EF
(offset + Le > velikost EF), je vrácen stav zpracování
„6700“ nebo „6Cxx“, kde „xx“ je přesná délka.
▼M1
— Je-li v atributech souboru zjištěna chyba integrity, karta
považuje soubor za poškozený a neopravitelný a je
vrácen stav zpracování „6400“ nebo „6500“.
▼B
— Je-li v uložených datech zjištěna chyba integrity, karta
vrátí požadovaná data a je vrácen stav zpracování
„6281“.
3.5.2.1.1 P ř í k a z s b e z p e č n ý m p ř e d á v á n í m z p r á v ( p ř í k l a d y )
Tento příkaz umožňuje IFD číst data z aktuálně vybraného EF
s bezpečným předáváním zpráv za účelem ověření integrity přijatých
dat a ochrany důvěrnosti dat v případě, že se použije bezpečnostní
podmínka SM-R-ENC-MAC-G1 (1. generace) nebo SM-R-ENC-
MAC-G2 (2. generace).
TCS_44 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „0Ch“ Požadavek na bezpečné předávání zpráv
INS 1 „B0h“ Read Binary
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 247
Bajt Délka Hodnota Popis
P1 1 „XXh“ P1 (offset v bajtech od začátku souboru): nejvýznamnější
bajt
P2 1 „XXh“ P2 (offset v bajtech od začátku souboru): nejméně
významný bajt
Lc 1 „XXh“ Délka vstupních dat pro bezpečné předávání zpráv
#6 1 „97h“ T LE : tag pro specifikaci očekávané délky
#7 1 „01h“ L LE : délka očekávané délky
#8 1 „NNh“ Specifikace očekávané délky (původní Le): počet bajtů
ke čtení
#9 1 „8Eh“ T CC : tag pro kryptografický kontrolní součet
#10 1 „XXh“ L CC : délka následujícího kryptografického kontrolního
součtu
„04h“ pro bezpečné předávání zpráv 1. generace (viz
dodatek 11 část A)
„08h“, „0Ch“ nebo „10h“ v závislosti na délce klíče
AES pro bezpečné předávání zpráv 2. generace (viz
dodatek 11 část B)
#11-#(10+L) L „XX..XXh“ Kryptografický kontrolní součet
Le 1 „00h“ Podle specifikace v ISO/IEC 7816-4
TCS_45 Zpráva s odpovědí, pokud není požadována podmínka
SM-R-ENC-MAC-G1 (1. generace) / SM-R-ENC-MAC-
G2 (2. generace) a pokud je správný vstupní formát
bezpečného předávání zpráv:
▼M1
Bajt Délka Hodnota Popis
#1 1 „81h“ T PV : tag pro otevřená data
#2 L „NNh“ nebo
„81 NNh“
L PV : délka vrácených dat (= původní Le).
L jsou 2 bajty, jestliže L PV > 127 bajtů.
#(2+L)-#(1+L+NN) NN „XX..XXh“ Otevřená data
#(2+L+NN) 1 „99h“ Tag pro stav zpracování (SW1-SW2) – voli­
telný pro bezpečné předávání zpráv 1. gene­
race
#(3+L+NN) 1 „02h“ Délka stavu zpracování – volitelná pro
bezpečné předávání zpráv 1. generace
#(4+L+NN) - #(5+L+NN) 2 „XX XXh“ Stav zpracování nechráněné APDU odpo­
vědi – volitelný pro bezpečné předávání
zpráv 1. generace
#(6+L+NN) 1 „8Eh“ TCC: tag pro kryptografický kontrolní
součet
#(7+L+NN) 1 „XXh“ LCC: délka následujícího kryptografického
kontrolního součtu
„04h“ pro bezpečné předávání zpráv 1.
generace (viz dodatek 11 část A)
„08h“, „0Ch“ nebo „10h“ v závislosti na
délce klíče AES pro bezpečné předávání
zpráv 2. generace (viz dodatek 11 část B)
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 248
Bajt Délka Hodnota Popis
#(8+L+NN)-#(7+M+L+NN) M „XX..XXh“ Kryptografický kontrolní součet
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
▼B
TCS_46 Zpráva s odpovědí, pokud je požadována podmínka
SM-R-ENC-MAC-G1 (1. generace) / SM-R-ENC-
MAC-G2 (2. generace) a pokud je správný vstupní
formát bezpečného předávání zpráv:
▼M1
Bajt Délka Hodnota Popis
#1 1 „87h“ T PI CG : tag pro šifrovaná data (kryptogram)
#2 L „MMh“ nebo
„81 MMh“
L PI CG : délka vrácených šifrovaných dat (v
důsledku doplnění odlišná od původního Le
příkazu).
L je 2 bajty, jestliže LPI CG > 127 bajtů.
#(2+L)-#(1+L+MM) MM „01XX..XXh“ Šifrovaná data: indikátor doplnění a krypto­
gram
#(2+L+MM) 1 „99h“ Tag pro stav zpracování (SW1-SW2) – voli­
telný pro bezpečné předávání zpráv 1. gene­
race
#(3+L+MM) 1 „02h“ Délka stavu zpracování – volitelná pro
bezpečné předávání zpráv 1. generace
#(4+L+MM) - #(5+L+MM) 2 „XX XXh“ Stav zpracování nechráněné APDU odpo­
vědi – volitelný pro bezpečné předávání
zpráv 1. generace
#(6+L+MM) 1 „8Eh“ TCC: tag pro kryptografický kontrolní
součet
#(7+L+MM) 1 „XXh“ LCC: délka následujícího kryptografického
kontrolního součtu
„04h“ pro bezpečné předávání zpráv 1.
generace (viz dodatek 11 část A)
„08h“, „0Ch“ nebo „10h“ v závislosti na
délce klíče AES pro bezpečné předávání
zpráv 2. generace (viz dodatek 11 část B)
#(8+L+MM)-
#(7+N+L+MM)
N „XX..XXh“ Kryptografický kontrolní součet
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
▼B
Příkaz READ BINARY může vracet běžné stavy zpraco­
vání uvedené v TCS_43 pod tagem „99h“, jak popisuje
TCS_59, pomocí struktury odpovědi v rámci bezpečného
předávání zpráv.
Navíc se mohou vyskytnout některé chyby, které se týkají
konkrétně bezpečného předávání zpráv. V takovém případě
je jednoduše vrácen stav zpracování bez použití struktury
bezpečného předávání zpráv:
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 249
TCS_47 Zpráva s odpovědí, jestliže je chybný vstupní formát
bezpečného předávání zpráv
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Není-li k dispozici žádný aktuální klíč relace, je vrácen
stav zpracování „6A88“. To se stane tehdy, jestliže klíč
relace dosud není vygenerován, nebo jestliže skončila
platnost klíče relace (v tomto případě musí IFD zopa­
kovat vzájemný proces ověření totožnosti za účelem
stanovení nového klíče relace).
— Jestliže některé očekávané datové objekty (jak je
uvedeno výše) ve formátu bezpečného předávání
zpráv chybějí, je vrácen stav zpracování „6987“: tato
chyba se objeví, jestliže chybí očekávaný tag nebo jest­
liže tělo příkazu není správně sestaveno.
— Jsou-li některé datové objekty chybné, je vrácen stav
zpracování „6988“: tato chyba se objeví, jestliže jsou
přítomny všechny požadované tagy, ale některé délky
se liší od očekávaných.
— Selže-li ověření kryptografického kontrolního součtu, je
vrácen stav zpracování „6688“.
3.5.2.2 P ř í k a z s k r á t k ý m i d e n t i f i k á t o r e m E F ( e l e m e n t á r ­
n í h o s o u b o r u )
Tato varianta příkazu umožňuje IFD vybrat EF pomocí krátkého iden­
tifikátoru EF a číst data z tohoto EF.
TCS_48 Karta tachografu musí podporovat tuto variantu příkazu pro
všechny elementární soubory se specifikovaným krátkým
identifikátorem EF. Tyto krátké identifikátory EF jsou
specifikovány v kapitole 4.
TCS_49 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „B0h“ Read Binary
P1 1 „XXh“ Bit 8 je nastaven na 1
Bity 7 a 6 jsou nastaveny na 00
Bity 5 – 1 kódují krátký identifikátor EF příslušného EF
P2 1 „XXh“ Kóduje offset od 0 do 255 bajtů v EF, na který odkazuje
P1
Le 1 „XXh“ Délka očekávaných dat. Počet bajtů ke čtení.
Poznámka: Krátké identifikátory EF používané pro aplikaci
tachografu 2. generace jsou specifikovány v kapitole 4.
Pokud P1 kóduje krátký identifikátor EF a příkaz je
úspěšný, identifikovaný EF se stává aktuálně vybraným
EF (aktuálním EF).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 250
TCS_50 Zpráva s odpovědí
Bajt Délka Hodnota Popis
#1-#L L „XX..XXh“ Přečtená data
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Není-li soubor odpovídající krátkému identifikátoru EF
nalezen, je vrácen stav zpracování „6A82“.
— Nejsou-li splněny bezpečnostní podmínky zvoleného
souboru, příkaz se přeruší se stavem „6982“.
— Není-li offset kompatibilní s velikostí EF (offset > veli­
kost EF), je vrácen stav zpracování „6B00“.
— Není-li velikost dat ke čtení kompatibilní s velikostí EF
(offset + Le > velikost EF), je vrácen stav zpracování
„6700“ nebo „6Cxx“, kde „xx“ je přesná délka.
▼M1
— Je-li v atributech souboru zjištěna chyba integrity, karta
považuje soubor za poškozený a neopravitelný a je
vrácen stav zpracování „6400“ nebo „6500“.
▼B
— Je-li v uložených datech zjištěna chyba integrity, karta
vrátí požadovaná data a je vrácen stav zpracování
„6281“.
3.5.2.3 P ř í k a z s l i c h ý m b a j t e m i n s t r u k c e
Tato varianta příkazu umožňuje IFD číst data z EF s 32 768 nebo více
bajty.
TCS_51 Karta tachografu, která podporuje EF s 32 768 nebo více
bajty, podporuje tuto variantu příkazu pro tyto EF. Karta
tachografu může, ale nemusí podporovat tuto variantu
příkazu pro ostatní EF kromě EF Sensor_Installation_Data,
viz TCS_156 a TCS_160.
TCS_52 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „B1h“ Read Binary
P1 1 „00h“ Aktuální EF
P2 1 „00h“
Lc 1 „NNh“ Lc délka datového objektu offsetu
#6-#(5+NN) NN „XX..XXh“ Datový objekt offsetu:
Tag „54h“
Délka „01h“ nebo „02h“
Hodnota offset
▼M1
Le 1 „XXh“ Podle specifikace v ISO/IEC 7816-4
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 251
IFD kóduje délku datového objektu offsetu s použitím
minimálního možného počtu oktetů, tj. s použitím bajtu
délky „01h“ musí IFD kódovat offset od 0 do 255 a s
použitím bajtu délky „02h“ offset od 256 do 65 535 bajtů.
▼M1
Je-li T=0, karta předpokládá hodnotu Le = „00h“, jestliže
není použito bezpečné předávání zpráv.
Je-li T=1, je vrácen stav zpracování „6700“, jestliže Le =
„01h“.
▼B
TCS_53 Zpráva s odpovědí
Bajt Délka Hodnota Popis
#1-#L L „XX..XXh“ Čtená data zapouzdřená ve volném datovém objektu
s tagem „53h“
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Není-li vybrán žádný EF, je vrácen stav zpracování
„6986“.
— Nejsou-li splněny bezpečnostní podmínky zvoleného
souboru, příkaz se přeruší se stavem „6982“.
— Není-li offset kompatibilní s velikostí EF (offset > veli­
kost EF), je vrácen stav zpracování „6B00“.
— Není-li velikost dat ke čtení kompatibilní s velikostí EF
(offset + Le > velikost EF), je vrácen stav zpracování
„6700“ nebo „6Cxx“, kde „xx“ je přesná délka.
▼M1
— Je-li v atributech souboru zjištěna chyba integrity, karta
považuje soubor za poškozený a neopravitelný a je
vrácen stav zpracování „6400“ nebo „6500“.
▼B
— Je-li v uložených datech zjištěna chyba integrity, karta
vrátí požadovaná data a je vrácen stav zpracování
„6281“.
3.5.2.3.1 P ř í k a z s b e z p e č n ý m p ř e d á v á n í m z p r á v ( p ř í k l a d )
Následující příklad znázorňuje použití bezpečného předávání zpráv,
použije-li se bezpečnostní podmínka SM-MAC-G2.
TCS_54 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „0Ch“ Požadavek na bezpečné předávání zpráv
INS 1 „B1h“ Read Binary
P1 1 „00h“ Aktuální EF
P2 1 „00h“
Lc 1 „XXh“ Délka zabezpečeného datového pole
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 252
Bajt Délka Hodnota Popis
#6 1 „B3h“ Tag pro otevřená data v kódování BER-TLV
#7 1 „NNh“ L PV : délka přenášených dat
#(8)-#(7+NN) NN „XX..XXh“ Otevřená data v kódování BER-TLV, tj. datový objekt
offsetu s tagem „54“
#(8+NN) 1 „97h“ T LE : tag pro specifikaci očekávané délky
#(9+NN) 1 „01h“ L LE : délka očekávané délky
#(10+NN) 1 „XXh“ Specifikace očekávané délky (původní Le): počet bajtů
ke čtení
#(11+NN) 1 „8Eh“ T CC : tag pro kryptografický kontrolní součet
#(12+NN) 1 „XXh“ L CC : délka následujícího kryptografického kontrolního
součtu
„08h“, „0Ch“ nebo „10h“ v závislosti na délce klíče
AES pro bezpečné předávání zpráv 2. generace (viz
dodatek 11 část B)
#(13+NN)-
#(12+M+NN)
M „XX..XXh“ Kryptografický kontrolní součet
Le 1 „00h“ Podle specifikace v ISO/IEC 7816-4
TCS_55 Zpráva s odpovědí, je-li příkaz úspěšný
Bajt Délka Hodnota Popis
#1 1 „B3h“ Otevřená data v kódování BER-TLV
#2 L „NNh“ nebo
„81 NNh“
L PV : délka vrácených dat (= původní Le).
L jsou 2 bajty, jestliže L PV > 127 bajtů.
#(2+L)-
#(1+L+NN)
NN „XX..XXh“ Otevřená data v kódování BER-TLV, tj. přečtená data
zapouzdřená ve volném datovém objektu s tagem „53h“
#(2+L+NN) 1 „99h“ Stav zpracování nechráněné APDU odpovědi
#(3+L+NN) 1 „02h“ Délka stavu zpracování
#(4+L+NN) –
#(5+L+NN)
2 „XX XXh“ Stav zpracování nechráněné APDU odpovědi
#(6+L+NN) 1 „8Eh“ T CC : tag pro kryptografický kontrolní součet
#(7+L+NN) 1 „XXh“ L CC : délka následujícího kryptografického kontrolního
součtu
„08h“, „0Ch“ nebo „10h“ v závislosti na délce klíče
AES pro bezpečné předávání zpráv 2. generace (viz
dodatek 11 část B)
#(8+L+NN)-
#(7+M+L+
NN)
M „XX..XXh“ Kryptografický kontrolní součet
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
3.5.3 UPDATE BINARY
Tento příkaz je v souladu s normou ISO/IEC 7816-4, jeho použití je
ale ve srovnání s příkazem definovaným normou omezené.
Zpráva s příkazem UPDATE BINARY spouští přepis (výmaz + zápis)
bitů již přítomných v binárním EF bity poskytnutými v APDU
příkazu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 253
3.5.3.1 P ř í k a z s o f f s e t e m v P 1 - P 2
Tento příkaz umožňuje IFD zapsat data do aktuálně vybraného EF bez
toho, aby karta ověřovala integritu přijatých dat.
Poznámka: Tento příkaz bez bezpečného předávání zpráv lze použít
pouze pro aktualizaci souboru, který podporuje bezpečnostní
podmínku ALW pro režim přístupu pro aktualizaci.
TCS_56 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „D6h“ Update Binary
P1 1 „XXh“ Offset v bajtech od začátku souboru: nejvýznamnější bajt
P2 1 „XXh“ Offset v bajtech od začátku souboru: nejméně významný
bajt
Lc 1 „NNh“ Lc: délka dat k aktualizaci. Počet bajtů k zápisu.
#6-#(5+NN) NN „XX..XXh“ Data k zápisu
Poznámka: bit 8 v P1 musí být nastaven na 0.
TCS_57 Zpráva s odpovědí
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Není-li vybrán žádný EF, je vrácen stav zpracování
„6986“.
— Nejsou-li splněny bezpečnostní podmínky zvoleného
souboru, příkaz se přeruší se stavem „6982“.
— Není-li offset kompatibilní s velikostí EF (offset > veli­
kost EF), je vrácen stav zpracování „6B00“.
— Není-li velikost dat k zápisu kompatibilní s velikostí EF
(Offset + Lc > velikost EF), je vrácen stav zpracování
„6700“.
— Je-li v atributech souboru zjištěna chyba integrity, karta
považuje soubor za poškozený a neopravitelný a je
vrácen stav zpracování „6400“ nebo „6500“.
— Je-li zápis neúspěšný, je vrácen stav zpracování „6581“.
3.5.3.1.1 P ř í k a z s b e z p e č n ý m p ř e d á v á n í m z p r á v ( p ř í k l a d y )
Tento příkaz umožňuje IFD zapsat data do aktuálně vybraného EF,
přičemž karta ověřuje integritu přijatých dat. Protože není požadováno
zajištění důvěrnosti, data nejsou šifrována.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 254
TCS_58 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „0Ch“ Požadavek na bezpečné předávání zpráv
INS 1 „D6h“ Update Binary
P1 1 „XXh“ Offset v bajtech od začátku souboru:
nejvýznamnější bajt
P2 1 „XXh“ Offset v bajtech od začátku souboru:
nejméně významný bajt
Lc 1 „XXh“ Délka zabezpečeného datového pole
#6 1 „81h“ T PV : tag pro otevřená data
#7 L „NNh“ nebo
„81 NNh“
L PV : délka přenášených dat.
L jsou 2 bajty, jestliže L PV > 127 bajtů.
#(7+L)-
#(6+L+NN)
NN „XX..XXh“ Otevřená data (data k zápisu)
#(7+L+NN) 1 „8Eh“ T CC : tag pro kryptografický kontrolní součet
#(8+L+NN) 1 „XXh“ L CC : délka následujícího kryptografického kontrolního
součtu: „04h“ pro bezpečné předávání zpráv 1. generace
(viz dodatek 11 část A)
„08h“, „0Ch“ nebo „10h“ v závislosti na délce klíče
AES pro bezpečné předávání zpráv 2. generace (viz
dodatek 11 část B)
#(9+L+NN)-
#(8+M+L+
NN)
M „XX..XXh“ Kryptografický kontrolní součet
Le 1 „00h“ Podle specifikace v ISO/IEC 7816-4
TCS_59 Zpráva s odpovědí, jestliže je vstupní formát bezpeč­
ného předávání zpráv správný
Bajt Délka Hodnota Popis
#1 1 „99h“ T SW : tag pro stavová slova (chráněna pomocí CC)
#2 1 „02h“ L SW : délka vrácených stavových slov
#3-#4 2 „XXXXh“ Stav zpracování nechráněné APDU odpovědi
#5 1 „8Eh“ T CC : tag pro kryptografický kontrolní součet
#6 1 „XXh“ L CC : délka následujícího kryptografického kontrolního
součtu
„04h“ pro bezpečné předávání zpráv 1. generace (viz
dodatek 11 část A)
„08h“, „0Ch“ nebo „10h“ v závislosti na délce klíče
AES pro bezpečné předávání zpráv 2. generace (viz
dodatek 11 část B)
#7-#(6+L) L „XX..XXh“ Kryptografický kontrolní součet
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
Běžné stavy zpracování, popsané pro příkaz UPDATE
BINARY bez bezpečného předávání zpráv (viz část
3.5.3.1), mohou být vráceny pomocí výše uvedené struk­
tury zprávy s odpovědí.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 255
Navíc se mohou vyskytnout některé chyby, které se týkají
konkrétně bezpečného předávání zpráv. V takovém případě
je jednoduše vrácen stav zpracování bez použití struktury
bezpečného předávání zpráv:
TCS_60 Zpráva s odpovědí v případě chyby v bezpečném před­
ávání zpráv
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Není-li k dispozici aktuální klíč relace, je vrácen stav
zpracování „6A88“.
— Jestliže některé očekávané datové objekty (jak je
uvedeno výše) ve formátu bezpečného předávání
zpráv chybějí, je vrácen stav zpracování „6987“: tato
chyba se objeví, jestliže chybí očekávaný tag nebo jest­
liže tělo příkazu není správně sestaveno.
— Jsou-li některé datové objekty chybné, je vrácen stav
zpracování „6988“: tato chyba se objeví, jestliže jsou
přítomny všechny požadované tagy, ale některé délky
se liší od očekávaných.
— Selže-li ověření kryptografického kontrolního součtu, je
vrácen stav zpracování „6688“.
3.5.3.2 P ř í k a z s k r á t k ý m i d e n t i f i k á t o r e m E F
Tato varianta příkazu umožňuje IFD vybrat EF pomocí krátkého iden­
tifikátoru EF a zapsat data z tohoto EF.
TCS_61 Karta tachografu musí podporovat tuto variantu příkazu pro
všechny elementární soubory se specifikovaným krátkým
identifikátorem EF. Tyto krátké identifikátory EF jsou
specifikovány v kapitole 4.
TCS_62 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „D6h“ Update Binary
P1 1 „XXh“ Bit 8 je nastaven na 1
Bity 7 a 6 jsou nastaveny na 00
Bity 5 – 1 kódují krátký identifikátor EF příslušného EF
P2 1 „XXh“ Kóduje offset od 0 do 255 bajtů v EF, na který odkazuje
P1
Lc 1 „NNh“ Lc: délka dat k aktualizaci. Počet bajtů k zápisu.
#6-#(5+NN) NN „XX..XXh“ Data k zápisu
TCS_63 Zpráva s odpovědí
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
Poznámka: Krátké identifikátory EF používané pro aplikaci
tachografu 2. generace jsou specifikovány v kapitole 4.
Pokud P1 kóduje krátký identifikátor EF a příkaz je
úspěšný, identifikovaný EF se stává aktuálně vybraným
EF (aktuálním EF).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 256
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Není-li soubor odpovídající krátkému identifikátoru EF
nalezen, je vrácen stav zpracování „6A82“.
— Nejsou-li splněny bezpečnostní podmínky zvoleného
souboru, příkaz se přeruší se stavem „6982“.
— Není-li offset kompatibilní s velikostí EF (offset > veli­
kost EF), je vrácen stav zpracování „6B00“.
— Není-li velikost dat k zápisu kompatibilní s velikostí EF
(Offset + Lc > velikost EF), je vrácen stav zpracování
„6700“.
▼M1
— Je-li v atributech souboru zjištěna chyba integrity, karta
považuje soubor za poškozený a neopravitelný a je
vrácen stav zpracování „6400“ nebo „6500“.
▼B
— Je-li zápis neúspěšný, je vrácen stav zpracování „6581“.
3.5.3.3 P ř í k a z s l i c h ý m b a j t e m i n s t r u k c e
Tato varianta příkazu umožňuje IFD zapisovat data do EF s 32 768
nebo více bajty.
TCS_64 Karta tachografu, která podporuje EF s 32 768 nebo více
bajty, podporuje tuto variantu příkazu pro tyto EF. Karta
tachografu může, ale nemusí podporovat tuto variantu
příkazu pro ostatní EF.
TCS_65 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „D7h“ Update Binary
P1 1 „00h“ Aktuální EF
P2 1 „00h“
Lc 1 „NNh“ Lc délka dat v datovém poli příkazu
#6-#(5+NN) NN „XX..XXh“ Datový objekt offsetu s tagem „54h“ || volný datový
objekt s tagem „53h“, který zapouzdřuje data k zápisu
IFD kóduje délku datového objektu offsetu a volného dato­
vého objektu s použitím minimálního možného počtem
oktetů, tj. pomocí bajtu délky „01h“ musí IFD kódovat
offset/délku od 0 do 255 a pomocí bajtu délky „02h“
offset/délku od 256 do 65 535 bajtů.
TCS_66 Zpráva s odpovědí
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 257
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Není-li vybrán žádný EF, je vrácen stav zpracování
„6986“.
— Nejsou-li splněny bezpečnostní podmínky zvoleného
souboru, příkaz se přeruší se stavem „6982“.
— Není-li offset kompatibilní s velikostí EF (offset > veli­
kost EF), je vrácen stav zpracování „6B00“.
— Není-li velikost dat k zápisu kompatibilní s velikostí EF
(Offset + Lc > velikost EF), je vrácen stav zpracování
„6700“.
— Je-li v atributech souboru zjištěna chyba integrity, karta
považuje soubor za poškozený a neopravitelný a je
vrácen stav zpracování „6400“ nebo „6500“.
— Je-li zápis neúspěšný, je vrácen stav zpracování „6581“.
3.5.3.3.1 P ř í k a z s b e z p e č n ý m p ř e d á v á n í m z p r á v ( p ř í k l a d )
Následující příklad znázorňuje použití bezpečného předávání zpráv,
použije-li se bezpečnostní podmínka SM-MAC-G2.
TCS_67 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „0Ch“ Požadavek na bezpečné předávání zpráv
INS 1 „D7h“ Update Binary
P1 1 „00h“ Aktuální EF
P2 1 „00h“
Lc 1 „XXh“ Délka zabezpečeného datového pole
#6 1 „B3h“ Tag pro otevřená data v kódování BER-TLV
#7 L „NNh“ nebo
„81 NNh“
L PV : délka přenášených dat.
L jsou 2 bajty, jestliže L PV > 127 bajtů.
#(7+L)-
#(6+L+NN)
NN „XX..XXh“ Otevřená data v kódování BER-TLV, tj. datový objekt
offsetu s tagem „54h“ || volný datový objekt s tagem
„53h“, který zapouzdřuje data k zápisu
#(7+L+NN) 1 „8Eh“ T CC : tag pro kryptografický kontrolní součet
#(8+L+NN) 1 „XXh“ L CC : délka následujícího kryptografického kontrolního
součtu
„08h“, „0Ch“ nebo „10h“ v závislosti na délce klíče
AES pro bezpečné předávání zpráv 2. generace (viz
dodatek 11 část B)
#(9+L+NN)-
#(8+M+L+
NN)
M „XX..XXh“ Kryptografický kontrolní součet
Le 1 „00h“ Podle specifikace v ISO/IEC 7816-4
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 258
TCS_68 Zpráva s odpovědí, je-li příkaz úspěšný
Bajt Délka Hodnota Popis
#1 1 „99h“ T SW : tag pro stavová slova (chráněna pomocí CC)
#2 1 „02h“ L SW : délka vrácených stavových slov
#3-#4 2 „XXXXh“ Stav zpracování nechráněné APDU odpovědi
#5 1 „8Eh“ T CC : tag pro kryptografický kontrolní součet
#6 1 „XXh“ L CC : délka následujícího kryptografického kontrolního
součtu
„08h“, „0Ch“ nebo „10h“ v závislosti na délce klíče
AES pro bezpečné předávání zpráv 2. generace (viz
dodatek 11 část B)
#7-#(6+L) L „XX..XXh“ Kryptografický kontrolní součet
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
3.5.4 GET CHALLENGE
Tento příkaz je v souladu s normou ISO/IEC 7816-4, jeho použití je
ale ve srovnání s příkazem definovaným normou omezené.
Příkaz GET CHALLENGE žádá kartu o vyslání výzvy pro použití
v postupu souvisejícím se zabezpečením, v rámci nějž se kartě pošle
kryptogram nebo šifrovaná data.
TCS_69 Kartou vydaná výzva je platná pouze pro následující příkaz
poslaný kartě, který výzvu používá.
TCS_70 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „84h“ INS
P1 1 „00h“ P1
P2 1 „00h“ P2
Le 1 „08h“ Le (očekávaná délka výzvy).
TCS_71 Zpráva s odpovědí
Bajt Délka Hodnota Popis
#1-#8 8 „XX..XXh“ Výzva
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Pokud se Le liší od „08h“, stav zpracování je „6700“.
— Jestliže jsou chybné parametry P1-P2, stav zpracování
je „6A86“.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 259
3.5.5 VERIFY
Tento příkaz je v souladu s normou ISO/IEC 7816-4, jeho použití je
ale ve srovnání s příkazem definovaným normou omezené.
Tento příkaz musí podporovat pouze karta dílny.
Ostatní typy karet tachografu mohou, ale nemusí tento příkaz imple­
mentovat, ale pro tyto karty není personalizována žádná referenční
hodnota CHV. Proto tyto karty nemohou tento příkaz úspěšně provést.
Pro typy karet tachografu jiné než kartu dílny je chování, tj. vracený
chybový kód, mimo oblast působnosti této specifikace, je-li tento
příkaz odeslán.
Příkaz VERIFY spouští na kartě porovnání dat CHV (kódu PIN)
zaslaných z příkazu s referenční hodnotou CHV uloženou na kartě.
▼M1
TCS_72 Kód PIN zadaný uživatelem musí být v kódování ASCII
a IFD jej zprava doplní bajty „FFh“ na délku 8 bajtů, viz
rovněž datový typ WorkshopCardPIN v dodatku 1.
▼B
TCS_73 Aplikace tachografu 1. a 2. generace používají stejnou refe­
renční hodnotu CHV.
TCS_74 Karta tachografu zkontroluje, zda je příkaz správně
kódován. Není-li příkaz kódován správně, karta neporovná
hodnoty CHV, nesníží čítač zbývajících pokusů o ověření
CHV a neresetuje bezpečnostní status „PIN_Verified“, ale
příkaz přeruší. Příkaz je kódován správně, mají-li bajty
CLA, INS, P1, P2, Lc stanovené hodnoty, Le chybí
a datové pole příkazu má správnou délku.
TCS_75 Je-li příkaz úspěšný, je čítač zbývajících pokusů o ověření
CHV nastaven zpět na počáteční hodnotu. Počáteční
hodnota čítače zbývajících pokusů o ověření CHV je 5.
Je-li příkaz úspěšný, musí karta nastavit vnitřní bezpeč­
nostní status „PIN_Verified“. Karta resetuje tento bezpeč­
nostní status, pokud je resetována karta nebo pokud kód
CHV přenesený v příkazu neodpovídá uložené referenční
hodnotě CHV.
Poznámka: používání stejné referenční hodnoty CHV
a globálního bezpečnostního statusu zabraňují tomu, aby
pracovník dílny musel po výběru jiného DF aplikace tacho­
grafu znovu zadávat PIN.
TCS_76 Neúspěšné porovnání se na kartě zaznamená, tj. čítač
zbývajících pokusů o ověření CHV se sníží o jedničku,
aby se omezil počet dalších pokusů o použití referenční
hodnoty CHV.
TCS_77 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „20h“ INS
P1 1 „00h“ P1
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 260
Bajt Délka Hodnota Popis
P2 1 „00h“ P2 (ověřovaná hodnota CHV je implicitně známa)
Lc 1 „08h“ Délka přenášeného kódu CHV
#6-#13 8 „XX..XXh“ CHV
TCS_78 Zpráva s odpovědí
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Není-li referenční hodnota CHV nalezena, je vrácen
stav zpracování „6A88“.
— Je-li CHV zablokována (čítač zbývajících pokusů
o ověření CHV je na nule), je vrácen stav zpracování
„6983“. Po dosažení tohoto stavu už nelze nikdy
úspěšně předložit CHV.
— Jestliže je porovnání neúspěšné, čítač zbývajících
pokusů se sníží a je vrácen stav „63CX“ (X>0 a X
se rovná čítači zbývajících pokusů o ověření CHV).
— Je-li referenční hodnota CHV považována za poško­
zenou, je vrácen stav zpracování „6400“ nebo „6581“.
— Pokud se Lc liší od „08h“, stav zpracování je „6700“.
3.5.6 GET RESPONSE
Tento příkaz je v souladu s normou ISO/IEC 7816-4.
Tento příkaz (potřebný a dostupný pouze pro protokol T=0) slouží
k přenosu připravených dat z karty do zařízení rozhraní (případ, kdy
příkaz obsahoval jak Lc, tak Le).
Příkaz GET RESPONSE musí být vydán ihned po příkazu, který
připravuje data, jinak jsou data ztracena. Po provedení příkazu GET
RESPONSE (nevyskytne-li se chyba „61xx“ nebo „6Cxx“, viz dále)
dříve připravená data již nejsou k dispozici.
TCS_79 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „C0h“
P1 1 „00h“
P2 1 „00h“
Le 1 „XXh“ Počet očekávaných bajtů
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 261
TCS_80 Zpráva s odpovědí
Bajt Délka Hodnota Popis
#1-#X X „XX..XXh“ Data
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Pokud karta nepřipravila žádná data, je vrácen stav
zpracování „6900“ nebo „6F00“.
— Jestliže Le překročí počet dostupných bajtů nebo jest­
liže je Le nula, je vrácen stav zpracování „6Cxx“, kde
xx udává přesný počet dostupných bajtů. V takovém
případě jsou připravená data nadále k dispozici pro
následný příkaz GET RESPONSE.
— Jestliže Le není nula a je menší než počet dostupných
bajtů, karta normálně pošle požadovaná data a je vrácen
stav zpracování „61xx“, kde „xx“ udává počet dodateč­
ných bajtů, které jsou nadále k dispozici pro následný
příkaz GET RESPONSE.
— Jestliže příkaz není podporován (protokol T=1), karta
vrátí „6D00“.
3.5.7 PSO: VERIFY CERTIFICATE
Tento příkaz je v souladu s normou ISO/IEC 7816-8, jeho použití je
ale ve srovnání s příkazem definovaným normou omezené.
Příkaz VERIFY CERTIFICATE je používán kartou k získání veřej­
ného klíče zvenku a ke kontrole jeho platnosti.
3.5.7.1 P á r p ř í k a z – o d p o v ě ď 1 . g e n e r a c e
TCS_81 Tuto variantu příkazu podporuje pouze aplikace tachografu
1. generace.
TCS_82 Pokud je příkaz VERIFY CERTIFICATE úspěšný, veřejný
klíč je uložen k budoucímu použití v bezpečnostním
prostředí. Tento klíč je explicitně nastaven pro použití
v příkazech vztahujících se k zabezpečení (INTERNAL
AUTHENTICATE, EXTERNAL AUTHENTICATE nebo
VERIFY CERTIFICATE) pomocí příkazu MSE (viz část
3.5.11) s použitím jeho identifikátoru klíče.
TCS_83 V každém případě příkaz VERIFY CERTIFICATE používá
veřejný klíč dříve vybraný příkazem MSE k otevření certi­
fikátu. Musí se jednat o veřejný klíč členského státu nebo
Evropy.
TCS_84 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „2Ah“ Perform Security Operation
P1 1 „00h“ P1
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 262
Bajt Délka Hodnota Popis
P2 1 „AEh“ P2: data, která nejsou v kódování BER-TLV (zřetězení
datových prvků)
Lc 1 „C2h“ Lc: délka certifikátu, 194 bajtů
#6-#199 194 „XX..XXh“ Certifikát: zřetězení datových prvků (jak je popsáno
v dodatku 11)
TCS_85 Zpráva s odpovědí
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Jestliže se ověření certifikátu nezdaří, je vrácen stav
zpracování „6688“. Proces ověření a rozbalení certifi­
kátu je popsán v dodatku 11 pro G1 a G2.
— Jestliže v bezpečnostním prostředí není žádný veřejný
klíč, je vráceno „6A88“.
— Jestliže se vybraný veřejný klíč (použitý k rozbalení
certifikátu) považuje za poškozený, je vrácen stav zpra­
cování „6400“ nebo „6581“.
— Pouze 1. generace: Jestliže má vybraný veřejný klíč
(použitý k rozbalení certifikátu) CHA.LSB
( )
rozdílný od „00“ (např. nejde o certifikát členského
státu nebo Evropy), je vrácen stav zpracování „6985“.
3.5.7.2 P á r p ř í k a z – o d p o v ě ď 2 . g e n e r a c e
V závislosti na velikosti křivky mohou být certifikáty ECC tak
dlouhé, že je nelze přenést v jedné APDU. V takovém případě je
třeba použít zřetězení příkazů podle ISO/IEC 7816-4 a přenést certi­
fikát ve dvou po sobě následujících APDU příkazu PSO: VERIFY
CERTIFICATE.
Struktura certifikátu a parametry domény jsou definovány
v dodatku 11.
▼M3
TCS_86 Příkaz lze provést v MF, DF Tachograph a DF Tacho­
graph_G2, viz rovněž TCS_34.
▼B
TCS_87 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „X0h“ Bajt CLA označující zřetězení příkazů:
„00h“ – jediný nebo poslední příkaz řetězce
„10h“ – nikoli poslední příkaz řetězce
INS 1 „2Ah“ Perform Security Operation
P1 1 „00h“
P2 1 „BEh“ Verify self-descriptive certificate
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 263
Bajt Délka Hodnota Popis
Lc 1 „XXh“ Délka datového pole příkazu, viz TCS_88 a TCS_89
#6-#5+L L „XX..XXh“ Data v kódování DER-TLV: datový objekt těla certifi­
kátu ECC jako první datový objekt zřetězený s datovým
objektem podpisu certifikátu ECC jako druhým datovým
objektem, nebo část tohoto zřetězení. Tag „7F21“
a příslušná délka se nepřenášejí.
Pořadí těchto datových objektů je pevné.
▼M3
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řene­
sení 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 podpo­
rovat ř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 defino­
vány v TCS_85.
▼B
TCS_90 Kromě chybových kódů uvedených v TCS_85 může karta
vrátit tyto chybové kódy:
— Jestliže vybraný veřejný klíč (použitý k rozbalení certi­
fikátu) má CHA.LSB (CertificateHolderAuthorisa­
tion.equipmentType), který není vhodný pro ověření
certifikátu podle dodatku 11, je vrácen stav zpracování
„6985“.
— Je-li currentAuthenticatedTime karty pozdější než
datum skončení platnosti certifikátu, je vrácen stav
zpracování „6985“.
— Je-li očekáván poslední příkaz řetězce, karta vrátí
„6883“.
— Jsou-li v datovém poli příkazu odeslány chybné para­
metry, karta vrátí „6A80“ (použije se rovněž v případě,
že datové objekty nejsou odeslány ve stanoveném
pořadí).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 264
3.5.8 INTERNAL AUTHENTICATE
Tento příkaz je v souladu s normou ISO/IEC 7816-4.
TCS_91 Všechny karty tachografu podporují tento příkaz v DF
Tachograph 1. generace. Příkaz může, ale nemusí být
přístupný v MF a/nebo DF Tachograph_G2. Pokud je
příkaz dostupný, skončí vhodným chybovým kódem,
protože soukromý klíč karty (Card.SK) pro protokol
ověření pravosti 1. generace je přístupný pouze
v DF_Tachograph 1. generace.
Použitím příkazu INTERNAL AUTHENTICATE může
IFD ověřit pravost karty. Proces ověření pravosti je popsán
v dodatku 11. Zahrnuje následující výroky:
TCS_92 Příkaz INTERNAL AUTHENTICATE pomocí soukromého
klíče karty (implicitně vybraného) podepíše data pro
ověření pravosti včetně K1 (první element pro dohodu na
klíči relace) a RND1 a pomocí aktuálně vybraného (pomocí
posledního příkazu MSE) veřejného klíče zašifruje podpis
a vytvoří ověřovací token (další podrobnosti v dodatku 11).
TCS_93 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“ CLA
INS 1 „88h“ INS
P1 1 „00h“ P1
P2 1 „00h“ P2
Lc 1 „10h“ Délka dat poslaných kartě
#6 – #13 8 „XX..XXh“ Výzva použitá k ověření pravosti karty
#14 -#21 8 „XX..XXh“ VU.CHR (viz dodatek 11)
Le 1 „80h“ Délka dat očekávaných z karty
TCS_94 Zpráva s odpovědí
Bajt Délka Hodnota Popis
#1-#128 128 „XX..XXh“ Ověřovací token karty (viz dodatek 11)
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Jestliže v bezpečnostním prostředí není žádný veřejný
klíč, je vrácen stav zpracování „6A88“.
— Jestliže v bezpečnostním prostředí není žádný
soukromý klíč, je vrácen stav zpracování „6A88“.
— Jestliže VU.CHR neodpovídá identifikátoru aktuálního
veřejného klíče, je vrácen stav zpracování „6A88“.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 265
— Je-li vybraný soukromý klíč považován za poškozený,
je vrácen stav zpracování „6400“ nebo „6581“.
▼M1
TCS_95 Jestliže je příkaz INTERNAL AUTHENTICATE úspěšný,
aktuální klíč relace 1. generace, pokud existuje, se vymaže
a není nadále k dispozici. Aby byl k dispozici nový klíč
relace 1. generace, musí být úspěšně proveden příkaz
EXTERNAL AUTHENTICATE pro mechanismus ověření
pravosti 1. generace.
Poznámka: klíče relace 2. generace viz dodatek 11
odstavce CSM_193 a CSM_195. Jsou-li vytvořeny klíče
relace 2. generace a karta tachografu přijme otevřený příkaz
INTERNAL AUTHENTICATE APDU, přeruší relaci
bezpečného předávání zpráv 2. generace a zlikviduje klíče
relace 2. generace.
▼B
3.5.9 EXTERNAL AUTHENTICATE
Tento příkaz je v souladu s normou ISO/IEC 7816-4.
Použitím příkazu EXTERNAL AUTHENTICATE může karta ověřit
pravost IFD. Proces ověření pravosti je popsán v dodatku 11 pro
Tachograph G1 a G2 (ověření pravosti celku ve vozidle).
TCS_96 Varianta příkazu pro mechanismus vzájemného ověření
pravosti 1. generace je podporována pouze aplikací tacho­
grafu 1. generace.
▼M1
TCS_97 Variantu příkazu pro vzájemné ověření pravosti druhé
generace celku ve vozidle a karty lze provést v MF, DF
Tachograph a DF Tachograph_G2, viz rovněž TCS_34.
Jestliže je tento příkaz EXTERNAL AUTHENTICATE 2.
generace úspěšný, aktuální klíč relace 1. generace, pokud
existuje, se vymaže a není nadále k dispozici.
Poznámka: klíče relace 2. generace viz dodatek 11
odstavce CSM_193 a CSM_195. Jsou-li vytvořeny klíče
relace 2. generace a karta tachografu přijme otevřený příkaz
EXTERNAL AUTHENTICATE APDU, přeruší relaci
bezpečného předávání zpráv 2. generace a zlikviduje klíče
relace 2. generace.
▼B
TCS_98 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“ CLA
INS 1 „82h“ INS
P1 1 „00h“ Klíče a algoritmy jsou implicitně známé
P2 1 „00h“
Lc 1 „XXh“ Lc (délka dat poslaných kartě)
#6-#(5+L) L „XX..XXh“ Ověření pravosti 1. generace: kryptogram (viz dodatek
11 část A)
Ověření pravosti 2. generace: podpis vytvořený IFD (viz
dodatek 11 část B)
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 266
TCS_99 Zpráva s odpovědí
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Jestliže CHA aktuálně nastaveného veřejného klíče není
zřetězením AID aplikace tachografu a typu zařízení
celku ve vozidle, je vrácen stav zpracování „6F00“.
— Nepředchází-li příkazu bezprostředně příkaz GET
CHALLENGE, je vrácen stav zpracování „6985“.
Aplikace tachografu 1. generace může vrátit tyto další
chybové kódy:
— Jestliže v bezpečnostním prostředí není žádný veřejný
klíč, je vráceno „6A88“.
— Jestliže v bezpečnostním prostředí není žádný
soukromý klíč, je vrácen stav zpracování „6A88“.
— Je-li ověření kryptogramu chybné, je vrácen stav zpra­
cování „6688“.
— Je-li vybraný soukromý klíč považován za poškozený,
je vrácen stav zpracování „6400“ nebo „6581“.
Varianta příkazu pro ověření pravosti 2. generace může
vrátit tento další chybový kód:
— Nezdaří-li se ověření podpisu, karta vrátí „6300“.
3.5.10 GENERAL AUTHENTICATE
Tento příkaz se používá pro protokol ověření pravosti čipu 2. gene­
race stanovený v dodatku 11 části B a je v souladu s ISO/IEC 7816-4.
TCS_100 Příkaz lze provést v MF, DF Tachograph a DF Tacho­
graph_G2, viz rovněž TCS_34.
TCS_101 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „86h“
P1 1 „00h“ Klíče a protokol jsou implicitně známé
P2 1 „00h“
Lc 1 „NNh“ Lc: délka následujícího datového pole
#6-#(5+L) L „7Ch“ + L 7C +
„80h“ + L 80 +
„XX..XXh“
Hodnota dočasného veřejného klíče v kódování
DER-TLV (viz dodatek 11)
Celek ve vozidle odešle datové objekty v tomto
pořadí
▼M3
Le 1 „00h“ Podle specifikace v ISO/IEC 7816-4
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 267
TCS_102 Zpráva s odpovědí
Bajt Délka Hodnota Popis
#1-#L L „7Ch“ + L 7C + „81h“
+ „08h“ +
„XX..XXh“ + „82h“
+ L 82 + „XX..XXh“
Data pro dynamické ověření pravosti v kódo­
vání DER-TLV: hodnota nonce a ověřovací
token (viz dodatek 11)
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Karta vrátí „6A80“ k indikaci chybných parametrů
v datovém poli.
— Karta vrátí „6982“, nebyl-li úspěšně proveden příkaz
EXTERNAL AUTHENTICATE.
Datový objekt pro dynamické ověření pravosti „7Ch“
v odpovědi
— musí být přítomen, je-li operace úspěšná, tj. stavová
slova jsou „9000“,
— nesmí být přítomen v případě chyby provádění nebo
chyby kontroly, tj. jsou-li stavová slova v rozsahu
„6400“–„6FFF“, a
— nemusí být přítomen v případě varování, tj. jsou-li
stavová slova v rozsahu „6200“–„63FF“.
3.5.11 MANAGE SECURITY ENVIRONMENT
Tento příkaz slouží k nastavení veřejného klíče pro účely ověření
pravosti.
3.5.11.1 P á r p ř í k a z – o d p o v ě ď 1 . g e n e r a c e
Tento příkaz je v souladu s normou ISO/IEC 7816-4. Jeho použití je
ale ve srovnání se související normou omezené.
TCS_103 Tento příkaz je podporován pouze aplikací tachografu 1.
generace.
TCS_104 Klíč, na který se odkazuje v datovém poli MSE, zůstává
aktuálním veřejným klíčem až do příštího správného
příkazu MSE, výběru DF nebo resetu karty.
TCS_105 Jestliže klíč, na který se odkazuje, není (dosud) na kartě
k dispozici, bezpečnostní prostředí zůstává nezměněno.
TCS_106 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“ CLA
INS 1 „22h“ INS
P1 1 „C1h“ P1: odkazovaný klíč, platí pro všechny kryptografické
operace
P2 1 „B6h“ P2 (odkazovaná data týkající se digitálního podpisu)
Lc 1 „0Ah“ Lc: délka následujícího datového pole
#6 1 „83h“ Tag pro odkaz na veřejný klíč v asymetrických přípa­
dech
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 268
Bajt Délka Hodnota Popis
#7 1 „08h“ Délka odkazu na klíč (identifikátoru klíče)
#8-#15 8 „XX..XXh“ Identifikátor klíče podle specifikace v dodatku 11
TCS_107 Zpráva s odpovědí
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Pokud klíč, na který se odkazuje, není na kartě přít­
omen, je vrácen stav zpracování „6A88“.
— Pokud ve formátu bezpečného předávání zpráv chybějí
některé očekávané datové objekty, je vrácen stav zpra­
cování „6987“. To může nastat, když chybí tag „83h“.
— Jsou-li některé datové objekty chybné, je vrácen stav
zpracování „6988“. To může nastat, když délka identi­
fikátoru klíče není „08h“.
— Je-li vybraný klíč považován za poškozený, je vrácen
stav zpracování „6400“ nebo „6581“.
3.5.11.2 P á r y p ř í k a z – o d p o v ě ď 2 . g e n e r a c e
Pro ověření pravosti 2. generace karta tachografu podporuje následu­
jící verze příkazu MSE: Set, které jsou v souladu s normou ISO/IEC
7816-4. Tyto verze příkazu nejsou podporovány pro ověření pravosti
1. generace.
3.5.11.2.1 M S E : S E T A T p r o o v ě ř e n í p r a v o s t i č i p u
Následující příkaz MSE:SET AT se používá pro výběr parametrů
k ověření pravosti čipu, které se provádí následným příkazem
GENERAL AUTHENTICATE.
TCS_108 Příkaz lze provést v MF, DF Tachograph a DF Tacho­
graph_G2, viz rovněž TCS_34.
TCS_109 Zpráva s příkazem MSE:SET AT pro ověření pravosti
čipu
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „22h“
P1 1 „41h“ Nastavit pro interní ověření pravosti
P2 1 „A4h“ Ověření pravosti
Lc 1 „NNh“ Lc: délka následujícího datového pole
#6-#(5+L) L „80h“ +
„0Ah“ +
„XX..XXh“
Odkaz na kryptografický mechanismus v kódování
DER-TLV: identifikátor objektu ověření pravosti čipu
(pouze hodnota, tag „06h“ je vynechán).
Hodnoty identifikátorů objektů viz dodatek 1; používá se
bajtová notace. Pokyny, jak vybrat jeden z těchto iden­
tifikátorů objektů, viz dodatek 11.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 269
3.5.11.2.2 M S E : S E T A T p r o o v ě ř e n í p r a v o s t i c e l k u v e
v o z i d l e
Následující příkaz MSE:SET AT se používá pro výběr parametrů
a klíčů pro ověření pravosti celku ve vozidle, které se provádí pomocí
následného příkazu EXTERNAL AUTHENTICATE.
TCS_110 Příkaz lze provést v MF, DF Tachograph a DF Tacho­
graph_G2, viz rovněž TCS_34.
TCS_111 Zpráva s příkazem MSE:SET AT pro ověření pravosti
celku ve vozidle
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „22h“
P1 1 „81h“ Nastavit pro externí ověření pravosti
P2 1 „A4h“ Ověření pravosti
Lc 1 „NNh“ Lc: délka následujícího datového pole
#6-#(5+L) L „80h“ + „0Ah“
+ „XX..XXh“
Odkaz na kryptografický mechanismus v kódování
DER-TLV: identifikátor objektu ověření pravosti celku
ve vozidle (pouze hodnota, tag „06h“ je vynechán).
Hodnoty identifikátorů objektů viz dodatek 1; používá se
bajtová notace. Pokyny, jak vybrat jeden z těchto iden­
tifikátorů objektů, viz dodatek 11.
„83h“ + „08h“
+ „XX..XXh“
Odkaz na veřejný klíč VU v kódování DER-TLV
s využitím reference držitele certifikátu uvedené v jeho
certifikátu
„91h“ + L 91 +
„XX..XXh“
Komprimovaná podoba dočasného veřejného klíče celku
ve vozidle v kódování DER-TLV, která se použije při
ověření pravosti čipu (viz dodatek 11)
3.5.11.2.3 M S E : S E T D S T
Následující příkaz MSE:SET DST se používá pro nastavení veřejného
klíče, a to buď
— pro ověření podpisu, který je poskytnut v následném příkazu PSO:
VERIFY DIGITAL SIGNATURE, nebo
— pro ověření podpisu certifikátu, který je poskytnut v následném
příkazu PSO: VERIFY CERTIFICATE.
TCS_112 Příkaz lze provést v MF, DF Tachograph a DF Tacho­
graph_G2, viz rovněž TCS_33.
TCS_113 Zpráva s příkazem MSE:SET DST
Bajt Délka Hodnota Popis
CLA 1 „00h“
INS 1 „22h“
P1 1 „81h“ Nastavit pro ověření
P2 1 „B6h“ Digitální podpis
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 270
Bajt Délka Hodnota Popis
Lc 1 „NNh“ Lc: délka následujícího datového pole
#6-#(5+L) L „83h“ + „08h“
+ „XX...XXh“
Odkaz na veřejný klíč v kódování DER-TLV, tj. refe­
rence držitele certifikátu v certifikátu veřejného klíče (viz
dodatek 11)
Pro všechny verze příkazu jsou struktura zprávy s odpovědí a stavová
slova dány takto:
TCS_114 Zpráva s odpovědí
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“. Protokol byl
vybrán a inicializován.
— „6A80“ označuje nesprávné parametry v datovém poli
příkazu.
— „6A88“ označuje, že data, na která se odkazuje (tj. klíč,
na který se odkazuje), nejsou k dispozici.
▼M1
— Je-li currentAuthenticatedTime karty pozdější než
datum skončení platnosti zvoleného veřejného klíče, je
vrácen stav zpracování „6A88“.
Poznámka: Použije-li se pro ověření pravosti celku ve
vozidle příkaz MSE: SET AT, je klíčem, na který se odka­
zuje, veřejný klíč VU_MA. Karta nastaví k použití veřejný
klíč VU_MA, který odpovídá odkazu na držitele
certifikátu (CHR) uvedenému v datovém poli příkazu,
pokud jej má v paměti (karta dokáže veřejné klíče
VU_MA identifikovat pomocí pole CHA certifikátu).
Karta na tento příkaz vrátí „6A 88“, pokud je k dispozici
pouze veřejný klíč VU_Sign nebo pokud není k dispozici
žádný veřejný klíč celku ve vozidle. Viz definice pole CHA
v dodatku 11 a datového typu equipmentType v dodatku 1.
Podobně v případě příkazu MSE: SET DST s odkazem na
EQT (tj. celek ve vozidle nebo kartu) poslaného na
kontrolní kartu je podle CSM_234 klíčem, na který se
odkazuje, vždy klíč EQT_Sign, který se musí použít
k ověření digitálního podpisu. Podle obrázku 13 v dodatku
11 bude na kontrolní kartě vždy uložen příslušný veřejný
klíč EQT_Sign. V některých případech může být na
kontrolní kartě uložen odpovídající veřejný klíč EQT_MA.
Kontrolní karta vždy nastaví k použití veřejný klíč
EQT_Sign, když obdrží příkaz MSE: SET DST.
▼B
3.5.12 PSO: HASH
Tento příkaz slouží k přenosu výsledku výpočtu hodnoty hash něja­
kých dat na kartu. Tento příkaz se používá k ověření digitálních
podpisů. Hodnota hash se dočasně uloží pro následný příkaz PSO:
VERIFY DIGITAL SIGNATURE.
Tento příkaz je v souladu s normou ISO/IEC 7816-8. Jeho použití je
ale ve srovnání se související normou omezené.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 271
Tento příkaz musí podporovat pouze kontrolní karta v DF Tachograph
a DF Tachograph_G2.
Ostatní typy karet tachografu mohou, ale nemusí tento příkaz imple­
mentovat. Příkaz může, ale nemusí být přístupný v MF.
Aplikace kontrolní karty 1. generace podporuje pouze SHA-1.
TCS_115 Dočasně uložená hodnota hash se smaže, pokud je pomocí
příkazu PSO: HASH vypočítána nová hodnota hash, pokud
je zvolen DF a pokud je resetována karta tachografu.
TCS_116 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“ CLA
INS 1 „2Ah“ Perform Security Operation
P1 1 „90h“ Vrátit hodnotu hash
P2 1 „A0h“ Tag: datové pole obsahuje příslušné DO pro hašování
Lc 1 „XXh“ Délka Lc následujícího datového pole
#6 1 „90h“ Tag pro hodnotu hash
#7 1 „XXh“ Délka L hodnoty hash:
„14h“ v aplikaci 1. generace (viz dodatek 11 část A)
„20h“, „30h“ nebo „40h“ v aplikaci 2. generace (viz
dodatek 11 část B)
#8-#(7+L) L „XX..XXh“ Hodnota hash
TCS_117 Zpráva s odpovědí
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Chybějí-li některé očekávané datové objekty (jak je
specifikováno výše), je vrácen stav zpracování „6987“.
To může nastat, když chybí jeden z tagů „90h“.
— Jsou-li některé datové objekty chybné, je vrácen stav
zpracování „6988“. Tato chyba nastane, když je přít­
omen potřebný tag, ale s jinou délkou než „14h“ pro
SHA-1, „20h“ pro SHA-256, „30h“ pro SHA-384,
„40h“ pro SHA-512 (aplikace 2. generace).
3.5.13 PERFORM HASH of FILE
Tento příkaz není v souladu s normou ISO/IEC 7816-8. Proto bajt
CLA tohoto příkazu indikuje proprietární použití příkazu PERFORM
SECURITY OPERATION / HASH.
Tento příkaz musí podporovat jen karta řidiče a karta dílny v DF
Tachograph a DF Tachograph_G2.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 272
Ostatní typy karet tachografu mohou, ale nemusí tento příkaz imple­
mentovat. Pokud tento příkaz implementuje karta podniku nebo
kontrolní karta, je příkaz implementován podle specifikace v této
kapitole.
Příkaz může, ale nemusí být přístupný v MF. Pokud je přístupný, je
implementován podle specifikace v této kapitole, tj. neumožní výpočet
hodnoty hash, ale skončí s vhodným chybovým kódem.
TCS_118 Příkaz PERFORM HASH OF FILE se používá pro výpočet
hodnoty hash datové oblasti aktuálně vybraného trans­
parentního EF.
TCS_119 Karta tachografu podporuje tento příkaz pouze pro ty EF,
které jsou uvedeny v kapitole 4 v rámci DF_Tachograph
a DF_Tachograph_G2 s následující výjimkou. Karta tacho­
grafu nepodporuje tento příkaz pro EF Sensor_Installa­
tion_Data v DF Tachograph_G2.
TCS_120 Výsledek operace hašování se dočasně uloží na kartě. Poté
může být použit k získání digitálního podpisu souboru
pomocí příkazu PSO: COMPUTE DIGITAL SIGNATURE.
▼M1
TCS_121 Dočasně uložená hodnota hash souboru se smaže, pokud je
pomocí příkazu PERFORM HASH of FILE vypočítána
nová hodnota hash souboru, pokud je zvolen DF a pokud
je resetována karta tachografu.
▼B
TCS_122 Aplikace tachografu 1. generace podporuje algoritmus
SHA-1.
▼M1
TCS_123 Aplikace tachografu 2. generace podporuje algoritmus
SHA-2 (SHA-256, SHA-384 nebo SHA-512), specifiko­
vaný sadami šifer v dodatku 11 části B pro podpisový
klíč karty Card_Sign.
▼B
TCS_124 Zpráva s příkazem
▼M1
Bajt Délka Hodnota Popis
CLA 1 „80h“ CLA
INS 1 „2Ah“ Provedení bezpečnostní operace
P1 1 „90h“ Tag: Hash
P2 1 „00h“ Algoritmus je implicitně znám.
Pro aplikaci tachografu 1. generace: SHA-1
Pro aplikaci tachografu 2. generace: algoritmus SHA-2
(SHA-256, SHA-384 nebo SHA-512) definovaný sadou
šifer v dodatku 11 části B pro podpisový klíč karty
Card_Sign
▼B
TCS_125 Zpráva s odpovědí
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Pokud aktuální EF nedovoluje tento příkaz (EF
Sensor_Installation_Data v DF Tachograph_G2), je
vrácen stav zpracování „6985“.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 273
— Je-li vybraný EF považován za poškozený (chyby inte­
grity atributů souboru nebo uložených dat), je vrácen
stav zpracování „6400“ nebo „6581“.
— Pokud zvolený soubor není transparentním souborem
nebo neexistuje aktuální EF, je vrácen stav zpracování
„6986“.
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE
▼M1
Tento příkaz se používá pro výpočet digitálního podpisu dříve vypoč­
tené hodnoty hash (viz PERFORM HASH OF FILE, bod 3.5.13).
Tento příkaz musí podporovat jen karta řidiče a karta dílny v DF
Tachograph a DF Tachograph_G2.
Ostatní typy karet tachografu mohou, ale nemusí tento příkaz imple­
mentovat. Pokud jde o aplikaci tachografu 2. generace, mají podpi­
sový klíč 2. generace pouze karta řidiče a karta dílny, ostatní typy
karet nemohou tento příkaz úspěšně provést a ukončí jej s vhodným
chybovým kódem.
Příkaz může, ale nemusí být přístupný v MF. Pokud příkaz v MF
přístupný není, skončí vhodným chybovým kódem.
Tento příkaz je v souladu s normou ISO/IEC 7816-8. Jeho použití je
ale ve srovnání se související normou omezené.
▼B
TCS_126 Tento příkaz nevypočítá digitální podpis hodnoty hash
dříve vypočtené příkazem PSO: HASH.
TCS_127 K výpočtu digitálního podpisu se použije soukromý klíč
karty, který je kartě implicitně znám.
TCS_128 Aplikace tachografu 1. generace provede digitální podpis
s použitím metody doplnění, která je v souladu s PKCS1
(podrobnosti viz dodatek 11).
TCS_129 Aplikace tachografu 2. generace vypočítá digitální podpis
na bázi eliptických křivek (podrobnosti viz dodatek 11).
TCS_130 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „00h“ CLA
INS 1 „2Ah“ Perform Security Operation
P1 1 „9Eh“ Má být vrácen digitální podpis
P2 1 „9Ah“ Tag: datové pole obsahuje data k podpisu. Jelikož žádné
datové pole není zahrnuto, očekává se, že data jsou již na
kartě (hash souboru).
Le 1 „NNh“ Délka očekávaného podpisu
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 274
TCS_131 Zpráva s odpovědí
Bajt Délka Hodnota Popis
#1-#L L „XX..XXh“ Podpis dříve vypočítané hodnoty hash
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Jestliže se implicitně vybraný soukromý klíč považuje
za poškozený, je vrácen stav zpracování „6400“ nebo
„6581“.
— Není-li k dispozici hodnota hash vypočítaná před­
chozím příkazem PERFORM HASH OF FILE, je
vrácen stav zpracování „6985“.
3.5.15 PSO: VERIFY DIGITAL SIGNATURE
Tento příkaz se používá k ověření digitálního podpisu poskytnutého
jako vstup, jehož hodnota hash je kartě známa. Algoritmus podpisu je
kartě implicitně znám.
Tento příkaz je v souladu s normou ISO/IEC 7816-8. Jeho použití je
ale ve srovnání se související normou omezené.
Tento příkaz musí podporovat pouze kontrolní karta v DF Tachograph
a DF Tachograph_G2.
Ostatní typy karet tachografu mohou, ale nemusí tento příkaz imple­
mentovat. Příkaz může, ale nemusí být přístupný v MF.
TCS_132 Příkaz VERIFY DIGITAL SIGNATURE vždy používá
veřejný klíč vybraný předchozím příkazem MANAGE
SECURITY ENVIRONMENT MSE: Set DST a předchozí
hodnotu hash vloženou příkazem PSO: HASH.
TCS_133 Zpráva s příkazem
▼M1
Bajt Délka Hodnota Popis
CLA 1 „00h“ CLA
INS 1 „2Ah“ Provedení bezpečnostní operace
P1 1 „00h“
P2 1 „A8h“ Tag: datové pole obsahuje datové objekty relevantní pro
ověření
Lc 1 „XXh“ Délka Lc následujícího datového pole
#6 1 „9Eh“ Tag pro digitální podpis
#7 nebo
#7-#8
L „NNh“ nebo
„81 NNh“
Délka digitálního podpisu (L je 2 bajty, pokud je digi­
tální podpis delší než 127 bajtů):
128 bajtů kódovaných podle dodatku 11 části A pro
aplikaci tachografu 1. generace
v závislosti na zvolené křivce pro aplikaci tachografu 2.
generace (viz dodatek 11 část B).
#(7+L)-
#(6+L+NN)
NN „XX..XXh“ Obsah digitálního podpisu
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 275
TCS_134 Zpráva s odpovědí
Bajt Délka Hodnota Popis
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— Jestliže se ověření podpisu nezdaří, je vrácen stav zpra­
cování „6688“. Postup ověření je popsán v dodatku 11.
— Jestliže není vybrán žádný veřejný klíč, je vrácen stav
zpracování „6A88“.
— Chybějí-li některé očekávané datové objekty (jak je
specifikováno výše), je vrácen stav zpracování „6987“.
To může nastat, když chybí jeden z požadovaných tagů.
— Jestliže není k dispozici žádná hodnota hash pro zpra­
cování příkazu (jako výsledek předchozího příkazu
PSO: HASH), je vrácen stav zpracování „6985“.
— Jsou-li některé datové objekty chybné, je vrácen stav
zpracování „6988“. To může nastat, když je chybná
délka jednoho z požadovaných datových objektů.
— Je-li vybraný veřejný klíč považován za poškozený, je
vrácen stav zpracování „6400“ nebo „6581“.
▼M1
— Jestliže vybraný veřejný klíč (použitý k ověření digitál­
ního podpisu) má CHA.LSB (CertificateHolderAuthori­
sation.equipmentType), který není vhodný pro ověření
digitálního podpisu podle dodatku 11, je vrácen stav
zpracování „6985“.
▼B
3.5.16 PROCESS DSRC MESSAGE
Tento příkaz se používá k ověření integrity a pravosti zprávy DSRC
a pro dešifrování dat předaných z celku ve vozidle kontrolnímu
orgánu nebo dílně pomocí spojení DSRC. Karta odvodí šifrovací
klíč a klíč MAC používané pro zabezpečení zprávy DSRC podle
dodatku 11 části B kapitoly 13.
Tento příkaz musí podporovat pouze kontrolní karta a karta dílny
v DF Tachograph_G2.
Ostatní typy karet tachografu mohou, ale nemusí tento příkaz imple­
mentovat, ale nemají hlavní klíč DSRC. Proto tyto karty nemohou
příkaz úspěšně provést, ale ukončí jej s vhodným chybovým kódem.
Příkaz může, ale nemusí být přístupný v MF a/nebo DF Tachograph.
Pokud je přístupný, skončí s vhodným chybovým kódem.
TCS_135 Hlavní klíč DSRC je přístupný pouze v DF Tacho­
graph_G2, tj. kontrolní karta a karta dílny podporují
úspěšné provedení příkazu pouze v DF Tachograph_G2.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 276
TCS_136 Příkaz pouze dešifruje data DSRC a ověřuje kryptografický
kontrolní součet, ale neinterpretuje vstupní data.
TCS_137 Pořadí datových objektů v datovém poli příkazu je určeno
touto specifikací.
TCS_138 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „80h“ Proprietární CLA
INS 1 „2Ah“ Perform Security Operation
P1 1 „80h“ Data odpovědi: otevřená hodnota
P2 1 „B0h“ Data příkazu: otevřená hodnota v kódování BER-TLV
a včetně datových objektů bezpečného předávání zpráv
Lc 1 „NNh“ Délka Lc následujícího datového pole
#6-#(5+L) L „87h“ + L 87 +
„XX..XXh“
Bajt indikující obsah doplnění v kódování DER-TLV
následovaný šifrovanými přenášenými daty tachografu.
Pro bajt indikující obsah doplnění se používá hodnota
„00h“ („žádná další indikace“ podle ISO/IEC 7816-
4:2013 tabulky 52). Mechanismus šifrování viz dodatek
11 část B kapitolu 13.
Povolené hodnoty délky L 87 jsou násobky délky bloku
AES plus 1 pro bajt indikující obsah doplnění, tj. od 17
bajtů do 193 bajtů včetně.
Poznámka: Datový objekt bezpečného předávání zpráv
s tagem „87h“ viz ISO/IEC 7816-4:2013 tabulka 49.
„81h“ + „10h“ Šablona řídicích odkazů pro důvěrnost v kódování
DER-TLV, která obsahuje zřetězení následujících dato­
vých prvků (viz dodatek 1 DSRCSecurityData a dodatek
11 část B kapitolu 13):
— 4 bajty – časové razítko
— 3 bajty – čítač
— 8 bajtů – výrobní číslo celku ve vozidle
— 1 bajt – verze hlavního klíče DSRC
Poznámka: Datový objekt bezpečného předávání zpráv
s tagem „81h“ viz ISO/IEC 7816-4:2013 tabulka 49.
„8Eh“ + L 8E +
„XX..XXh“
MAC zprávy DSRC v kódování DER-TLV. Algoritmus
a výpočet MAC viz dodatek 11 část B kapitolu 13.
Poznámka: Datový objekt bezpečného předávání zpráv
s tagem „8Eh“ viz ISO/IEC 7816-4:2013 tabulka 49.
▼M3
Le 1 „00h“ Podle specifikace v ISO/IEC 7816-4
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 277
TCS_139 Zpráva s odpovědí
Bajt Délka Hodnota Popis
#1-#L L „XX..XXh“ Chybí (v případě chyby) nebo dešifrovaná data (doplnění
odstraněno)
SW 2 „XXXXh“ Stavová slova (SW1, SW2)
— Je-li příkaz úspěšný, karta vrátí „9000“.
— „6A80“ označuje nesprávné parametry v datovém poli
příkazu (používá se rovněž v případě, že datové objekty
nejsou odeslány ve stanoveném pořadí).
— „6A88“ označuje, že data, na která se odkazuje, tj.
hlavní klíč DSRC, nejsou k dispozici.
— „6900“ označuje, že se nezdařilo ověření kryptografic­
kého kontrolního součtu nebo dešifrování dat.
▼M1
— „6985“ označuje, že časové razítko (4 bajty) uvedené
v datovém poli příkazu je dřívější než hodnota cardVa­
lidityBegin nebo pozdější než hodnota cardExpiryDate.
▼B
4. STRUKTURA KARET TACHOGRAFU
V tomto odstavci jsou specifikovány struktury souborů, které slouží
pro uložení přístupných dat na kartách tachografu.
Nejsou specifikovány vnitřní struktury závislé na výrobci karty,
jako například hlavičky souborů, ani ukládání a zpracování
datových prvků potřebných pouze pro interní použití, například
, ,
nebo .
TCS_140 Na kartě tachografu 2. generace je uložen hlavní
soubor (MF) a aplikace tachografu stejného typu (např.
aplikace karty řidiče) 1. generace a 2. generace.
TCS_141 Karta tachografu musí podporovat alespoň minimální počet
záznamů specifikovaný pro příslušné aplikace a nesmí
podporovat více záznamů než maximální počet specifiko­
vaný pro příslušné aplikace.
▼M3
Maximální a minimální počty záznamů jsou pro různé apli­
kace specifikovány v této kapitole. Ve verzi 2 2. generace
karty řidiče a karty dílny musí aplikace 1. generace podpo­
rovat maximální počet záznamů specifikovaný v TCS_150
a TCS_158.
▼B
Bezpečnostní podmínky používané v pravidlech přístupu
v této kapitole jsou uvedeny v kapitole 3.3. Režim přístupu
„čtení“ obecně označuje příkaz READ BINARY se sudým
a – je-li podporován – lichým bajtem INS, s výjimkou EF
Sensor_Installation_Data na kartě dílny, viz TCS_156
a TCS_160. Režim přístupu „aktualizace“ označuje příkaz
UPDATE BINARY se sudým a – je-li podporován –
lichým bajtem INS a režim přístupu „výběr“ označuje
příkaz SELECT.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 278
4.1 Hlavní soubor MF
TCS_142 Po personalizaci má hlavní soubor MF následující trvalou
strukturu souborů a pravidla přístupu k souborům:
Poznámka: 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.
V této tabulce je použita tato zkratka pro bezpečnostní
podmínku:
SC1 ALW OR SM-MAC-G2
TCS_143 Všechny struktury EF jsou transparentní.
TCS_144 Hlavní soubor MF má tuto strukturu dat:
TCS_145 Elementární soubor EF DIR obsahuje tyto datové objekty
týkající se aplikace: „61 08 4F 06 FF 54 41 43 48 4F 61 08
4F 06 FF 53 4D 52 44 54“
TCS_146 Elementární soubor EF ATR/INFO je přítomen, pokud
karta tachografu v ATR uvádí, že podporuje rozšířená
pole délky. V tomto případě EF ATR/INFO obsahuje
datový objekt s informací o rozšířené délce (DO„7F66“),
jak je uvedeno v ISO/IEC 7816-4:2013 bodě 12.7.1.
TCS_147 Elementární soubor EF Extended_Length je přítomen,
pokud karta tachografu v ATR uvádí, že podporuje rozší­
řená pole délky. V tomto případě tento EF obsahuje tento
datový objekt: „02 01 xx“, kde hodnota „xx“ označuje, zda
jsou rozšířená pole délky podporována pro protokol T = 1
a/nebo T = 0.
Hodnota „01“ označuje, že rozšířená pole délky jsou
podporována pro protokol T = 1.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 279
Hodnota „10“ označuje, že rozšířená pole délky jsou
podporována pro protokol T = 0.
Hodnota „11“ označuje, že rozšířená pole délky jsou
podporována pro protokol T = 1 a T = 0.
4.2 Aplikace karty řidiče
4.2.1 Aplikace karty řidiče 1. generace
TCS_148 Po personalizaci má aplikace karty řidiče 1. generace násle­
dující trvalou strukturu souborů a pravidla přístupu
k souborům:
V této tabulce jsou použity tyto zkratky pro bezpečnostní
podmínky:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
TCS_149 Všechny struktury EF jsou transparentní.
TCS_150 Aplikace karty řidiče 1. generace musí mít tuto strukturu
dat:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 280
► (1) (2) M3
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 281
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 282
TCS_151 Následující hodnoty používané pro označení velikostí ve
výše uvedené tabulce jsou hodnoty minimálního a maximál­
ního počtu záznamů, které musí struktura dat karty řidiče
používat pro aplikaci 1. generace:
4.2.2 Aplikace karty řidiče 2. generace
▼M3
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_Authenti­
cation, 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}.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 283
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
▼B
TCS_153 Všechny struktury EF jsou transparentní.
▼M3
TCS_154 Aplikace karty řidiče 2. generace musí mít tuto strukturu
dat:
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 284
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 285
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 286
TCS_155 Následující hodnoty používané pro označení velikostí ve
výše uvedené tabulce jsou hodnoty minimálního a maximál­
ního počtu záznamů, které musí struktura dat karty řidiče
používat pro aplikaci 2. generace:
▼M3
Min Max
n 1 NoOfEventsPerType 12 12
n 2 NoOfFaultsPerType 24 24
n 3 NoOfCardVehicleRecords 200 200
n 4 NoOfCardPlaceRecords 112 112
n 6 CardActivityLengthRange 13776 bajtů
(56 dnů * 117 změn
činnosti)
13776 bajtů
(56 dnů * 117 změn
činnosti)
n 7 NoOfCardVehicleUnitRecords 200 200
n 8 NoOfGNSSADRecords 336 336
n 9 NoOfSpecificConditionRecords 112 112
n 10 NoOfBorderCrossingRecords 1120 1120
n 11 NoOfLoadUnloadRecords 1624 1624
n 12 NoOfLoadTypeEntryRecords 336 336
n 13 VuConfigurationLengthRange 3072 bajtů 3072 bajtů
▼B
4.3 Aplikace karty dílny
4.3.1 Aplikace karty dílny 1. generace
TCS_156 Po personalizaci musí mít aplikace karty dílny 1. generace
následující trvalou strukturu souborů a pravidla přístupu
k souborům:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 287
V této tabulce jsou použity tyto zkratky pro bezpečnostní
podmínky:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
▼M1
SC4 Pro příkaz READ BINARY se sudým bajtem INS:
(SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR
(SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)
Pro příkaz READ BINARY s lichým bajtem INS
(je-li podporován): NEV
▼B
TCS_157 Všechny struktury EF jsou transparentní.
TCS_158 Aplikace karty dílny 1. generace musí mít tuto strukturu
dat:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 288
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 289
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 290
TCS_159 Následující hodnoty používané pro označení velikostí ve
výše uvedené tabulce jsou hodnoty minimálního a maximál­
ního počtu záznamů, které musí struktura dat karty dílny
používat pro aplikaci 1. generace:
4.3.2 Aplikace karty dílny 2. generace
▼M3
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_Authenti­
cation, EF GNSS_Places_Authentication, EF
Border_Crossings, EF Load_Unload_Operations, EF
Load_Type_Entries, EF VU_Configuration a EF Cali­
bration_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}.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 291
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
▼B
TCS_161 Všechny struktury EF jsou transparentní.
TCS_162 Aplikace karty dílny 2. generace musí mít tuto strukturu
dat:
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 292
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 293
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 294
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 295
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 296
TCS_163 Následující hodnoty používané pro označení velikostí ve
výše uvedené tabulce jsou hodnoty minimálního a maximál­
ního počtu záznamů, které musí struktura dat karty dílny
používat pro aplikaci 2. generace:
▼M3
Min Max
n 1 NoOfEventsPerType 3 3
n 2 NoOfFaultsPerType 6 6
n 3 NoOfCardVehicleRecords 8 8
n 4 NoOfCardPlaceRecords 8 8
n 5 NoOfCalibrationRecords 255 255
n 6 CardActivityLengthRange 492 bajtů (1 den * 240
změn činnosti)
492 bajtů (1 den *
240 změn činnosti)
n 7 NoOfCardVehicleUnitRecords 8 8
n 8 NoOfGNSSADRecords 24 24
n 9 NoOfSpecificConditionRecords 4 4
n 10 NoOfBorderCrossingRecords 4 4
n 11 NoOfLoadUnloadRecords 8 8
n 12 NoOfLoadTypeEntryRecords 4 4
n 13 VuConfigurationLengthRange 3072 bajtů 3072 bajtů
▼B
4.4 Aplikace kontrolní karty
4.4.1 Aplikace kontrolní karty 1. generace
TCS_164 Po personalizaci musí mít aplikace kontrolní karty 1. gene­
race následující trvalou strukturu souborů a pravidla
přístupu k souborům:
V této tabulce jsou použity tyto zkratky pro bezpečnostní
podmínky:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
SC6 EXT-AUT-G1 OR SM-MAC-G1 OR SM-MAC-G2
TCS_165 Všechny struktury EF jsou transparentní.
TCS_166 Aplikace kontrolní karty 1. generace musí mít tuto struk­
turu dat:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 297
TCS_167 Následující hodnoty používané pro označení velikostí ve
výše uvedené tabulce jsou hodnoty minimálního a maximál­
ního počtu záznamů, které musí struktura dat kontrolní
karty používat pro aplikaci 1. generace:
4.4.2 Aplikace kontrolní karty 2. generace
▼M3
TCS_168 Po personalizaci musí mít aplikace kontrolní karty 2. gene­
race následující trvalou strukturu souborů a pravidla
přístupu k souborům:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 298
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_Configura­
tion 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. gene­
race, 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
▼B
TCS_169 Všechny struktury EF jsou transparentní.
TCS_170 Aplikace kontrolní karty 2. generace musí mít tuto struk­
turu dat:
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 299
▼B
TCS_171 Následující hodnoty používané pro označení velikostí ve
výše uvedené tabulce jsou hodnoty minimálního a maximál­
ního počtu záznamů, které musí struktura dat kontrolní
karty používat pro aplikaci 2. generace:
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 300
Min Max
n 7 NoOfControlActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 bajtů 3072 bajtů
▼B
4.5 Aplikace karty podniku
4.5.1 Aplikace karty podniku 1. generace
TCS_172 Po personalizaci musí mít aplikace karty podniku 1. gene­
race následující trvalou strukturu souborů a pravidla
přístupu k souborům:
V této tabulce jsou použity tyto zkratky pro
bezpečnostní podmínky:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
SC6 EXT-AUT-G1 OR SM-MAC-G1 OR
SM-MAC-G2
TCS_173 Všechny struktury EF jsou transparentní.
TCS_174 Aplikace karty podniku 1. generace musí mít tuto strukturu dat:
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 301
TCS_175 Následující hodnoty používané pro označení velikostí ve
výše uvedené tabulce jsou hodnoty minimálního a maximál­
ního počtu záznamů, které musí struktura dat karty podniku
používat pro aplikaci 1. generace
4.5.2 Aplikace karty podniku 2. generace
▼M3
TCS_176 Po personalizaci musí mít aplikace karty podniku 2. gene­
race 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_Configura­
tion 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. gene­
race, 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
▼B
TCS_177 Všechny struktury EF jsou transparentní.
TCS_178 Aplikace karty podniku 2. generace musí mít tuto strukturu
dat:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 302
▼B
TCS_179 Následující hodnoty používané pro označení velikostí ve
výše uvedené tabulce jsou hodnoty minimálního a maximál­
ního počtu záznamů, které musí struktura dat karty podniku
používat pro aplikaci 2. generace
▼M3
Min Max
n 8 NoOfCompanyActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 bajtů 3072 bajtů
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 303
Dodatek 3
PIKTOGRAMY
PIC_001 Tachograf může volitelně používat tyto piktogramy a jejich kombi­
nace (nebo piktogramy a jejich kombinace dostatečně podobné, aby je
bylo možno jednoznačně ztotožnit s těmito):
1. ZÁKLADNÍ PIKTOGRAMY
Osoby Akce Provozní režimy
podnik podnikový režim
kontrolor kontrola kontrolní režim
řidič řízení provozní režim
dílna/zkušebna kontrola/kalibrace kalibrační režim
výrobce
Činnosti Doba trvání
pohotovost stávající doba pohotovosti
řízení nepřetržitá doba řízení
odpočinek stávající doba odpočinku
jiná práce stávající pracovní doba
přestávka souhrnná doba přestávek
neznámá
Zařízení Funkce
otvor pro kartu řidiče
otvor pro kartu druhého řidiče
karta
hodiny
displej zobrazení
externí paměťové médium stahování
napájení
tiskárna/výtisk tisk
snímač
rozměr pneumatik
vozidlo / celek ve vozidle
zařízení GNSS
zařízení pro dálkové odhalování
rozhraní ITS
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 304
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
▼B
Různé
události závady
začátek denní pracovní doby konec denní pracovní doby
místo
ruční zadání činností řidiče
▼M3
zabezpečení / ověřené údaje / plomby
▼B
rychlost
čas
celkem/souhrn
▼M3
digitální mapa / hraniční přechod
▼B
Kvalifikátory
24h denní
týdenní
dvoutýdenní
od nebo do
2. KOMBINACE PIKTOGRAMŮ
Různé
místo kontroly
místo začátku denní pracovní doby místo konce denní pracovní
doby
▼M1
poloha po třech hodinách součtové
doby řízení
▼B
čas začátku čas konce
z vozidla
mimo působnost – začátek mimo působnost – konec
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 305
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
▼B
Karty
karta řidiče
karta podniku
kontrolní karta
karta dílny
žádná karta
Řízení
řízení posádkou
doba řízení během jednoho týdne
doba řízení během dvou týdnů
Výtisky
denní výtisk činností řidiče z karty
denní výtisk činností řidiče z celku ve vozidle
výtisk událostí a závad z karty
výtisk událostí a závad z celku ve vozidle
výtisk technických dat
výtisk překročení povolené rychlosti
▼M3
výtisk historie vložených karet
▼B
Události
vložení neplatné karty
konflikt karet
časový přesah
řízení bez příslušné karty
vložení karty během řízení
nesprávné ukončení poslední relace karty
překročení povolené rychlosti
přerušení napájení
chyba údajů o pohybu vozidla
nesoulad údajů o pohybu vozidla
narušení zabezpečení
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 306
časový konflikt nebo nastavení času (dílnou)
▼B
kontrola překročení povolené rychlosti
▼M1
chybí informace o poloze z přijímače GNSS nebo chyba komunikace
s vnějším zařízením GNSS
chyba komunikace se zařízením pro dálkovou komunikaci
▼M3
anomálie GNSS
▼B
Závady
závada karty (otvor pro kartu řidiče)
závada karty (otvor pro kartu druhého řidiče)
závada displeje
závada stahování
závada tiskárny
závada snímače
interní závada celku ve vozidle
závada GNSS
závada dálkového odhalování
Proces ručního zadávání
nadále tatáž denní pracovní doba?
konec předešlé pracovní doby?
potvrzení nebo zadání místa konce pracovní doby
zadání času začátku
zadání místa začátku pracovní doby
Poznámka: Další kombinace piktogramů k vytvoření bloků ve výtis­
cích nebo identifikátorů záznamů jsou definovány v dodatku 4.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 307
Dodatek 4
VÝTISKY
OBSAH
1. VŠEOBECNÉ
2. SPECIFIKACE DATOVÝCH BLOKŮ
3. SPECIFIKACE VÝTISKŮ
3.1 Denní výtisk činností řidiče z karty
3.2 Denní výtisk činností řidiče z VU
3.3 Výtisk událostí a závad z karty
3.4 Výtisk událostí a závad z VU
3.5 Výtisk technických dat
3.6 Výtisk překročení povolené rychlosti
3.7 Historie vložených karet
1. VŠEOBECNÉ
Každý výtisk je tvořen zřetězením různých datových bloků, které
mohou být identifikovány identifikátorem bloku.
Datový blok obsahuje jeden nebo více záznamů, které mohou být iden­
tifikovány identifikátorem záznamu.
PRT_001 Pokud identifikátor bloku bezprostředně předchází identifiká­
toru záznamu, identifikátor záznamu se netiskne.
PRT_002 Není-li některá datová položka známa nebo nesmí být vytiš­
těna z důvodu přístupových práv k údajům, vytisknou se
místo ní mezery.
PRT_003 Není-li znám obsah celé řádky nebo není třeba jej tisknout,
vynechá se celá řádka.
PRT_004 Číselná datová pole se tisknou zarovnaná doprava, s mezerou
jako oddělovačem tisíců a milionů a bez nul na začátku.
▼M3
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
PRT_006 V případě zalomení řádky z důvodu dlouhého textu se jako
první znak na nové řádce vytiskne zvláštní znak (tečka upro­
střed výšky řádky – „•“).
2. SPECIFIKACE DATOVÝCH BLOKŮ
V této kapitole je použita následující konvence, pokud jde o formát:
— znaky vytištěné tučně označují prostý text k vytištění (tiskne se
normálními znaky),
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 308
— normální znaky označují proměnné (piktogramy nebo data), které se
při tisku nahradí svými hodnotami,
— názvy proměnných jsou doplněny podtržítky, aby se znázornila
délka datové položky, která je pro proměnnou k dispozici,
— datum se uvádí ve formátu „dd/mm/yyyy“ (den/měsíc/rok). Smí se
použít i formát „dd.mm.yyyy“,
— termín „identifikace karty“ označuje posloupnost: typu karty znázor­
něného kombinací piktogramů karty, kódu členského státu vydáva­
jícího kartu, znaku lomítka a čísla karty s indexem náhrady
a indexem obnovy oddělenými mezerami:
P x x x / x x x x x x x x x x x x x x x x
K
om
bi
na
ce

pi
kt
og
ra
m
ů
ka
rt
y
K
ód
v
yd
áv
aj
íc
íh
o
čl
en
sk
éh
o
st
át
u
Prvních 14 znaků čísla karty
(případně s pořadovým indexem)
In
de
x
ná
hr
ad
y
In
de
x
ob
no
vy

▼M3
— v datovém bloku se text za „pi =“ vztahuje k odpovídajícímu pikto­
gramu 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.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 309
PRT_007 Ve výtiscích se používají následující datové bloky a/nebo datové
záznamy v souladu s následujícími významy a formáty:
► (1) (2) (3) (4) (5) M3
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 310
► (1) (2) (3) M3
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 311
► (1) (2) M3
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 312
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 313
► (1) (2) (3) (4) M3
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 314
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 315
► (1) M3
3. SPECIFIKACE VÝTISKŮ
V této kapitole je použita následující konvence:
N Tisk bloku nebo záznamu s číslem N
N
Tisk bloku nebo záznamu s číslem N tolikrát, kolikrát je třeba
X/Y
Tisk bloků nebo záznamů X a/nebo Y dle potřeby a tolikrát, kolikrát
je třeba
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 316
3.1 Denní výtisk činností řidiče z karty
▼M3
PRT_008 Denní výtisk činností řidiče z karty musí mít následující
formát:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 317
3.2 Denní výtisk činností řidiče z VU
▼M3
PRT_009 Denní výtisk činností řidiče z VU musí mít následující
formát:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 318
3.3 Výtisk událostí a závad z karty
PRT_010 Výtisk událostí a závad z karty musí mít následující formát:
1 Datum a čas vytištění dokumentu
2 Typ výtisku
3 Identifikace kontrolora (pokud je do VU vložena kontrolní karta, +
GEN)
3 Identifikace řidiče (z karty, které se výtisk týká)
4 Identifikace vozidla (z nějž se výtisk pořizuje)
12.2 Oddělovač událostí
12.4 Záznamy událostí (všechny události uložené na kartě)
12.3 Oddělovač závad
12.4
Záznamy závad (všechny závady uložené na kartě)
22.1 Místo kontroly
22.2 Podpis kontrolora
22.5 Podpis řidiče
3.4 Výtisk událostí a závad z VU
PRT_011 Výtisk událostí a závad z VU musí mít následující formát:
1 Datum a čas vytištění dokumentu
2 Typ výtisku
3
Identifikace držitele karty (pro všechny karty vložené do VU, +
GEN)
4 Identifikace vozidla (z nějž se výtisk pořizuje)
13.2 Oddělovač událostí
13.4
Záznamy událostí (všechny události uložené nebo probíhající ve VU)
13.3 Oddělovač závad
13.4
Záznamy závad (všechny závady uložené nebo probíhající ve VU)
22.1 Místo kontroly
22.2 Podpis kontrolora
22.5 Podpis řidiče
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 319
3.5 Výtisk technických dat
▼M3
PRT_012 Výtisk technických dat musí mít tento formát:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 320
3.6 Výtisk překročení povolené rychlosti
PRT_013 Výtisk překročení povolené rychlosti musí mít následující
formát:
1 Datum a čas vytištění dokumentu
2 Typ výtisku
3
Identifikace držitele karty (pro všechny karty vložené do VU, +
GEN)
4 Identifikace vozidla (z nějž se výtisk pořizuje)
20 Informace o kontrole překročení povolené rychlosti
21.1 Identifikátor údajů o překročení povolené rychlosti
21.4 / 21.5 První překročení povolené rychlosti po poslední kalibraci
21.2 Identifikátor údajů o překročení povolené rychlosti
21.4 / 21.5
5 nejzávažnějších překročení povolené rychlosti za posledních 365
dnů
21.3 Identifikátor údajů o překročení povolené rychlosti
21.4 / 21.5 Nejzávažnější překročení povolené rychlosti v každém z posledních
10 dnů výskytu
22.1 Místo kontroly
22.2 Podpis kontrolora
22.5 Podpis řidiče
3.7 Historie vložených karet
▼M3
PRT_014 Výtisk historie vložených karet musí mít tento formát:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 321
Dodatek 5
ZOBRAZENÍ
V tomto dodatku je použita tato konvence, pokud jde o formát:
— znaky vytištěné tučně znamenají prostý text, který se má zobrazit (zobrazí se
normálními znaky),
— normální znaky označují proměnné (piktogramy nebo údaje), které se při
zobrazení nahradí svými hodnotami,
— dd mm yyyy: den, měsíc, rok,
— hh: hodiny,
— mm: minuty,
— D: piktogram doby trvání,
— EF: kombinace piktogramů události nebo závady,
— O: piktogram provozního režimu.
DIS_001 Tachograf zobrazuje data na displeji v následujících formátech:
Údaje Formát
Výchozí zobrazení
Místní čas
Provozní režim
Informace o řidiči
Informace o druhém řidiči
Otevřená podmínka „mimo působnost“
Varovné zobrazení
Překročení nepřetržité doby řízení
Událost nebo závada
Další zobrazení
Datum v UTC
čas
Nepřetržitá doba řízení a souhrnná doba přestávek – řidič
Nepřetržitá doba řízení a souhrnná doba přestávek – druhý
řidič
Souhrnná doba řízení za předchozí a aktuální týden – řidič
Souhrnná doba řízení za předchozí a aktuální týden – druhý
řidič
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 322
Dodatek 6
PŘEDNÍ KONEKTOR PRO KALIBRACI A STAHOVÁNÍ
OBSAH
1. TECHNICKÉ VYBAVENÍ
1.1 Konektor
1.2 Zapojení kontaktů
1.3 Blokové schéma
2. ROZHRANÍ PRO STAHOVÁNÍ
3. ROZHRANÍ PRO KALIBRACI
1. TECHNICKÉ VYBAVENÍ
1.1 Konektor
INT_001 Konektor pro stahování/kalibraci je šestikolíkový, je přístupný na
předním panelu bez nutnosti odpojení jakékoli části tachografu
a odpovídá následujícímu výkresu (všechny rozměry jsou v mili­
metrech):
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 323
Následující výkres znázorňuje typický šestikolíkový protikus:
1.2 Zapojení kontaktů
INT_002 Kontakty jsou zapojeny podle následující tabulky:
Kolík Popis Poznámka
1 Záporný pól baterie Připojen k zápornému pólu baterie vozidla
2 Datová komunikace Vodič K (ISO 14230-1)
3 RxD pro stahování Vstup dat do tachografu
4 Vstupní/výstupní signál Kalibrace
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 324
Kolík Popis Poznámka
5 Trvalý výkonový výstup Napěťový rozsah je specifikován jako napěťový rozsah elek­
troinstalace vozidla minus 3 V pro zohlednění poklesu
napětí na ochranných obvodech
Výstup 40 mA
6 TxD pro stahování Výstup dat z tachografu
1.3 Blokové schéma
INT_003 Blokové schéma musí odpovídat tomuto:
2. ROZHRANÍ PRO STAHOVÁNÍ
INT_004 Rozhraní pro stahování musí splňovat specifikace RS232.
INT_005 Rozhraní pro stahování používá jeden start bit, 8 datových bitů,
z nichž první je nejméně významný (LSB), jeden bit sudé parity
a 1 stop bit.
Uspořádání datového bajtu
Start bit: jeden bit s logickou úrovní 0
Datové bity: přenášené s nejméně významným bitem jako prvním
Paritní bit: sudá parita
Stop bit: jeden bit s logickou úrovní 1
Při přenosu číselných dat tvořených více bajty se nejvýznamnější bajt se
přenese jako první a nejméně významný bajt jako poslední.
INT_006 Rychlost přenosu dat musí být nastavitelná od 9 600 bit/s do
115 200 bit/s. Přenos se uskutečňuje při nejvyšší možné rych­
losti, počáteční rychlost přenosu dat po zahájení komunikace se
nastaví na 9 600 bit/s.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 325
3. ROZHRANÍ PRO KALIBRACI
INT_007 Datová komunikace musí splňovat normu ISO 14230-1 Road
vehicles – Diagnostic systems – Keyword protocol 2000 –
Part 1: Physical layer, First edition: 1999.
INT_008 Vstupní/výstupní signál musí splňovat tyto elektrické
specifikace:
Parametr Minimum Typická hodnota Maximum Poznámka
U low (in) 1,0 V I = 750 μA
U high (in) 4 V I = 200 μA
Frekvence 4 kHz
U low (out) 1,0 V I = 1 mA
U high (out) 4 V I = 1 mA
INT_009 Vstupní/výstupní signál musí splňovat tyto časové diagramy:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 326
Dodatek 7
PROTOKOLY PRO STAHOVÁNÍ DAT
OBSAH
1. ÚVOD
1.1 Oblast působnosti
1.2 Zkratky a notace
2. STAHOVÁNÍ DAT Z CELKU VE VOZIDLE
2.1 Postup stahování
2.2 Protokol pro stahování dat
2.2.1 Struktura zpráv
2.2.2 Typy zpráv
2.2.2.1 Start Communication Request (SID 81)
2.2.2.2 Positive Response Start Communication (SID C1)
2.2.2.3 Start Diagnostic Session Request (SID 10)
2.2.2.4 Positive Response Start Diagnostic (SID 50)
2.2.2.5 Link Control Service (SID 87)
2.2.2.6 Link Control Positive Response (SID C7)
2.2.2.7 Request Upload (SID 35)
2.2.2.8 Positive Response Request Upload (SID 75)
2.2.2.9 Transfer Data Request (SID 36)
2.2.2.10 Positive Response Transfer Data (SID 76)
2.2.2.11 Request Transfer Exit (SID 37)
2.2.2.12 Positive Response Request Transfer Exit (SID 77)
2.2.2.13 Stop Communication Request (SID 82)
2.2.2.14 Positive Response Stop Communication (SID C2)
2.2.2.15 Acknowledge Sub Message (SID 83)
2.2.2.16 Negative Response (SID 7F)
2.2.3 Tok zpráv
2.2.4 Časování
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 327
2.2.5 Zpracování chyb
2.2.5.1 Fáze zahájení komunikace
2.2.5.2 Fáze komunikace
2.2.6 Obsah zprávy s odpovědí
▼M3
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
2.2.6.6 Positive Response Transfer Data Technical Data
▼B
2.3 Ukládání souborů na externí paměťové médium
3. PROTOKOL PRO STAHOVÁNÍ DAT Z KARET TACHOGRAFU
3.1 Oblast působnosti
3.2 Definice
3.3 Stahování z karty
3.3.1 Inicializační sekvence
3.3.2 Sekvence pro nepodepsané datové soubory
3.3.3 Sekvence pro podepsané datové soubory
3.3.4 Sekvence pro reset počítadla kalibrací
3.4 Formát uložených dat
3.4.1 Úvod
3.4.2 Formát souboru
4. STAHOVÁNÍ Z KARTY TACHOGRAFU PŘES JEDNOTKU VE
VOZIDLE
1. ÚVOD
Tento dodatek určuje postupy pro stahování různých typů dat na
externí paměťové médium a protokoly, které je nutno implementovat
k zajištění správného přenosu dat a plné slučitelnosti formátu stažených
dat, aby kterýkoli kontrolor mohl tato data prověřit a před jejich
analýzou zkontrolovat jejich pravost a integritu.
▼M1
1.1 Oblast působnosti
Data mohou být stažena na externí paměťové médium:
— z celku ve vozidle inteligentním vyhrazeným zařízením (IDE)
připojeným k celku ve vozidle,
— z karty tachografu pomocí IDE vybaveného kartovým rozhraním
(IFD),
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 328
— z karty tachografu prostřednictvím celku ve vozidle pomocí IDE
připojeného k celku ve vozidle.
Aby bylo možné zkontrolovat pravost a integritu stažených dat ulože­
ných na externí paměťové médium, stahují se data s připojeným
podpisem v souladu s dodatkem 11 „Společné bezpečnostní mecha­
nismy“. Rovněž se stahuje identifikace zdrojového zařízení (VU nebo
karty) a jeho bezpečnostní certifikáty (členského státu a zařízení).
Ověřovatel dat musí mít nezávisle získaný důvěryhodný evropský
veřejný klíč.
Data stažená z celku ve vozidle se opatří podpisem v souladu
s dodatkem 11 „Společné bezpečnostní mechanismy“ částí B („Systém
tachografu druhé generace“), vyjma případů, kdy kontrolu řidičů
provádí kontrolní orgán, který nepatří do EU, za použití kontrolní
karty první generace a kdy se data opatří podpisem v souladu
dodatkem 11 „Společné bezpečnostní mechanismy“ částí A („Systém
tachografu první generace“), v souladu s dodatkem 15 Migrace poža­
davkem MIG_015.
Tento dodatek tudíž stanoví dva typy stahování dat z celku ve vozidle:
— stahování dat z celku ve vozidle typu 2. generace, poskytující
datovou strukturu 2. generace a opatřené podpisem v souladu
s dodatkem 11 „Společné bezpečnostní mechanismy“ částí B,
— stahování dat z celku ve vozidle typu 1. generace, poskytující
datovou strukturu 1. generace a opatřené podpisem v souladu
s dodatkem 11 „Společné bezpečnostní mechanismy“ částí A.
Podobně existují dva typy stahování dat z karet řidiče druhé generace
vložených do celku ve vozidle, jak je uvedeno v bodech 3 a 4 tohoto
dodatku.
▼B
1.2 Zkratky a notace
V tomto dodatku jsou použity následující zkratky:
AID identifikátor aplikace (Application Identifier)
ATR odpověď na reset (Answer To Reset)
CS bajt kontrolního součtu (Checksum byte)
DF vyhrazený soubor (Dedicated File)
DS_ diagnostická relace (Diagnostic Session)
EF elementární soubor (Elementary File)
ESM externí paměťové médium (External Storage Medium)
FID identifikátor souboru (File ID)
FMT bajt formátu (první bajt hlavičky zprávy) (Format Byte)
ICC karta s integrovaným obvodem, čipová karta (Integrated
Circuit Card)
IDE inteligentní vyhrazené zařízení (Intelligent Dedicated Equip­
ment): zařízení používané pro stahování dat na ESM (např.
osobní počítač)
IFD zařízení rozhraní (Interface Device)
KWP protokol KWP 2000 (Keyword Protocol 2000)
LEN bajt délky (poslední bajt hlavičky zprávy)
PPS volba parametrů protokolu (Protocol Parameter Selection)
PSO provedení bezpečnostní operace (Perform Security Operation)
SID identifikátor služby (Service Identifier)
SRC bajt zdroje (Source byte)
TGT bajt cíle (Target byte)
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 329
TLV tag, délka, hodnota (Tag Length Value)
TREP parametr odpovědi na požadavek na přenos (Transfer Response
Parameter)
TRTP parametr požadavku na přenos (Transfer Request Parameter)
VU celek ve vozidle (Vehicle Unit)
2. STAHOVÁNÍ DAT Z CELKU VE VOZIDLE
2.1 Postup stahování
Ke stažení dat z VU musí operátor provést následující operace:
— vsunout svou kartu tachografu do otvoru pro kartu v celku ve
vozidle (*),
— připojit IDE ke konektoru VU pro stahování,
— navázat spojení mezi IDE a VU,
— vybrat v IDE data, která se mají stáhnout, a odeslat požadavek do
VU,
— uzavřít relaci stahování.
2.2 Protokol pro stahování dat
Protokol používá strukturu „master-slave“ s IDE jako nadřízeným zaří­
zením a VU jako podřízeným zařízením.
Struktura, typy a tok zpráv jsou v zásadě založeny na protokolu KWP
2000 (ISO 14230-2 Road vehicles – Diagnostic systems – Keyword
protocol 2000 – Part 2: Data link layer).
Aplikační vrstva je v zásadě založena na aktuálním návrhu ISO 14229-
1 (Road vehicles – Diagnostic systems – Part 1: Diagnostic services,
version 6 of 22 February 2001).
2.2.1 Struktura zpráv
DDP_002 Všechny zprávy vyměňované mezi IDE a VU mají formát
struktury sestávající ze tří částí:
— hlavičky složené z bajtu formátu (FMT), bajtu
cíle (TGT), bajtu zdroje (SRC) a v příslušných přípa­
dech bajtu délky (LEN),
— datového pole složeného z bajtu identifikátoru
služby (SID) a proměnného počtu datových bajtů,
které mohou případně zahrnovat volitelný bajt diagno­
stické relace (DS_) nebo volitelný bajt parametru
přenosu (TRTP nebo TREP),
— kontrolního součtu tvořeného bajtem kontrolního
součtu (CS).
Hlavička Datové pole Kontrolní součet
FMT TGT SRC LEN SID DATA … … … CS
4 bajty Max. 255 bajtů 1 bajt
Bajty TGT a SRC představují fyzickou adresu příjemce
a původce zprávy. Hodnoty jsou F0 hex pro IDE a EE
hex pro VU.
Bajt LEN je délka datového pole.
▼B
(*) Vložená karta aktivuje příslušná přístupová práva k funkci stahování a k datům. Musí
být nicméně možné stáhnout data z karty řidiče vložené do jednoho z otvorů pro kartu
ve VU, i když v druhém otvoru pro kartu není vložena žádná karta.
02016R0799 — CS — 21.08.2023 — 003.002 — 330
Bajt kontrolního součtu je osmibitový součet modulo 256
všech bajtů zprávy vyjma samotného CS.
Bajty FMT, SID, DS_, TRTP a TREP jsou definovány dále
v tomto dokumentu.
DDP_003 V případě, že data, která má zpráva nést, jsou delší než
dostupný prostor v datovém poli, pošle se zpráva jako
několik dílčích zpráv. Každá dílčí zpráva nese hlavičku,
stejný bajt SID, bajt TREP a dvoubajtový čítač dílčích
zpráv udávající pořadí dílčí zprávy v celkové zprávě. Aby
byla možná kontrola chyb a přerušení přenosu, potvrzuje
IDE každou dílčí zprávu. IDE může přijmout dílčí zprávu,
požádat, aby byla přenesena znovu, požádat VU o opětovný
start nebo přenos přerušit.
DDP_004 Jestliže poslední dílčí zpráva obsahuje v datovém poli
přesně 255 bajtů, musí se připojit závěrečná dílčí zpráva
s prázdným datovým polem (vyjma bajtů SID a TREP
a čítače dílčích zpráv) jako indikátor konce zprávy.
Příklad:
Hlavička SID TREP Zpráva CS
4 bajty Delší než 255 bajtů
Přenese se jako:
Hlavička SID TREP 00 01 Dílčí zpráva 1 CS
4 bajty 255 bajtů
Hlavička SID TREP 00 02 Dílčí zpráva 2 CS
4 bajty 255 bajtů
…
Hlavička SID TREP xx yy Dílčí zpráva n CS
4 bajty Méně než 255 bajtů
nebo jako:
Hlavička SID TREP 00 01 Dílčí zpráva 1 CS
4 bajty 255 bajtů
Hlavička SID TREP 00 02 Dílčí zpráva 2 CS
4 bajty 255 bajtů
…
Hlavička SID TREP xx yy Dílčí zpráva n CS
4 bajty 255 bajtů
Hlavička SID TREP xx yy + 1 CS
4 bajty 4 bajty
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 331
2.2.2 Typy zpráv
Komunikační protokol mezi VU a IDE pro stahování dat vyžaduje
výměnu osmi různých typů zpráv.
Následující tabulka uvádí přehled těchto zpráv.
▼M3
Struktura zprávy Max. 4 bajty Max. 255 bajtů 1 bajt
Záhlaví Data
Kontrolní
součet
IDE ->
Start Communication Request 81 EE F0 81 E0
Positive Response Start Communica­
tion
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
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 332
Struktura zprávy Max. 4 bajty Max. 255 bajtů 1 bajt
Záhlaví Data
Kontrolní
součet
IDE ->
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 Communica­
tion
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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 333
— 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í.
▼B
2.2.2.1 S t a r t C o m m u n i c a t i o n R e q u e s t ( S I D 8 1 )
DDP_005 Tuto zprávu vyšle zařízení IDE, aby navázalo spojení s VU.
Počáteční komunikace vždy probíhá rychlostí 9 600 baudů
(až do případné změny rychlosti přenosu dat příslušnými
zprávami Link Control Service).
2.2.2.2 P o s i t i v e R e s p o n s e S t a r t C o m m u n i c a t i o n ( S I D C 1 )
DDP_006 Tuto zprávu vyšle VU jako kladnou odpověď na požadavek
Start Communication Request. Zpráva obsahuje 2 klíčové
bajty „EA“ „8F“ udávající, že VU podporuje protokol
s hlavičkou zahrnující informace o zdroji, cíli a délce.
2.2.2.3 S t a r t D i a g n o s t i c S e s s i o n R e q u e s t ( S I D 1 0 )
DDP_007 Zprávu Start Diagnostic Session Request vyšle IDE jako
žádost o novou diagnostickou relaci s VU. Podfunkce
„default session“ (81 hex) udává, že se má otevřít standardní
diagnostická relace.
2.2.2.4 P o s i t i v e R e s p o n s e S t a r t D i a g n o s t i c ( S I D 5 0 )
DDP_008 Zprávu Positive Response Start Diagnostic posílá VU jako
kladnou odpověď na požadavek Start Diagnostic Session
Request.
2.2.2.5 L i n k C o n t r o l S e r v i c e ( S I D 8 7 )
DDP_052 Zprávu Link Control Service používá IDE k vyvolání změny
rychlosti přenosu dat. Změna probíhá ve dvou krocích.
V prvním kroku IDE navrhne změnu rychlosti přenosu
dat, včetně nové rychlosti. Po přijetí kladné zprávy od VU
pak IDE odešle VU potvrzení o změně rychlosti přenosu dat
(druhý krok). IDE pak přejde na novou rychlost přenosu dat.
Po obdržení potvrzení přejde VU na novou rychlost přenosu
dat.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 334
2.2.2.6 L i n k C o n t r o l P o s i t i v e R e s p o n s e ( S I D C 7 )
DDP_053 Zprávu Link Control Positive Response vyšle VU jako
kladnou odpověď na požadavek Link Control Service (první
krok). Je třeba poznamenat, že na potvrzující požadavek
(druhý krok) se nezasílá žádná odpověď.
2.2.2.7 R e q u e s t U p l o a d ( S I D 3 5 )
DDP_009 Vysláním zprávy Request Upload IDE informuje VU, že je
požadováno stahování. Pro splnění požadavků ISO 14229
jsou obsaženy údaje o adrese, velikosti a podrobnostech
o formátu požadovaných dat. Vzhledem k tomu, že IDE
tyto údaje před stahováním nezná, nastaví se adresa v paměti
na 0, formát je nešifrovaný a nekomprimovaný a velikost
paměti se nastaví na maximum.
2.2.2.8 P o s i t i v e R e s p o n s e R e q u e s t U p l o a d ( S I D 7 5 )
DDP_010 Zprávu Positive Response Request Upload odesílá VU, aby
sdělil IDE, že VU je připraven na stahování dat. Pro splnění
požadavků ISO 14229 jsou ve zprávě s pozitivní odpovědí
obsaženy údaje, které IDE sdělují, že další zprávy Positive
Response Transfer Data budou obsahovat maximálně 00FF
hex bajtů.
2.2.2.9 T r a n s f e r D a t a R e q u e s t ( S I D 3 6 )
▼M1
DDP_011 Zprávu Transfer Data Request posílá IDE, aby informovalo
VU, jaký typ dat se má stahovat. Jednobajtový parametr
TRTP udává typ přenosu.
▼M3
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 (Activi­
ties 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
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 335
Typ přenosu dat Hodnota TRTP
stahování z karty
(Card download)
06
▼M3
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 certi­
fiká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.
▼B
2.2.2.10 P o s i t i v e R e s p o n s e T r a n s f e r D a t a ( S I D 7 6 )
DDP_012 Zprávu Positive Response Transfer Data posílá VU jako
odpověď na zprávu Transfer Data Request. Zpráva obsahuje
požadovaná data s parametrem TREP odpovídajícím para­
metru TRTP požadavku.
▼M3
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:
▼M1
— bezpečnostní certifikáty,
— identifikace vozidla,
— aktuální datum a čas VU,
— minimální a maximální datum, za které lze data stáh­
nout(data VU),
— indikace přítomnosti karet ve VU,
— předešlé stažení dat podnikem,
— zámky podniku,
— předešlé kontroly.
▼B
2.2.2.11 R e q u e s t T r a n s f e r E x i t ( S I D 3 7 )
DDP_013 Zprávu Request Transfer Exit posílá IDE, aby informovalo
VU, že relace stahování je ukončena.
2.2.2.12 P o s i t i v e R e s p o n s e R e q u e s t T r a n s f e r E x i t ( S I D 7 7 )
DDP_014 Zprávu Positive Response Request Transfer Exit posílá VU,
aby potvrdil přijetí požadavku Request Transfer Exit.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 336
2.2.2.13 S t o p C o m m u n i c a t i o n R e q u e s t ( S I D 8 2 )
DDP_015 Zprávu Stop Communication Request zasílá IDE, aby přeru­
šilo komunikační spojení s VU.
2.2.2.14 P o s i t i v e R e s p o n s e S t o p C o m m u n i c a t i o n ( S I D C 2 )
DDP_016 Zprávu Positive Response Stop Communication zasílá VU,
aby potvrdil přijetí požadavku Stop Communication
Request.
2.2.2.15 A c k n o w l e d g e S u b M e s s a g e ( S I D 8 3 )
DDP_017 Zprávu Acknowledge Sub Message zasílá IDE jako
potvrzení o přijetí jednotlivých částí zprávy, která se přenáší
jako několik dílčích zpráv. Datové pole obsahuje SID
obdržený od VU a následující dvoubajtový kód:
— MsgC + 1 potvrzuje správné přijetí dílčí zprávy s číslem
MsgC.
IDE požaduje od VU odeslání další dílčí zprávy.
— MsgC označuje problém při příjmu dílčí zprávy s číslem
MsgC.
IDE požaduje od VU opakované odeslání dílčí zprávy.
— FFFF požaduje ukončení zprávy.
Tento kód může IDE použít k ukončení přenosu zprávy
od VU z jakéhokoli důvodu.
Poslední dílčí zpráva celkové zprávy (bajt LEN
může být potvrzena kterýmkoli z těchto kódů, nebo
nepotvrzena.
Odpovědi VU, které se budou skládat z několika dílčích
zpráv, jsou:
— Positive Response Transfer Data (SID 76)
2.2.2.16 N e g a t i v e R e s p o n s e ( S I D 7 F )
DDP_018 Zprávu Negative Response zasílá VU jako odpověď na výše
uvedené zprávy požadavků, pokud VU nemůže požadavek
splnit. Datové pole zprávy obsahuje SID odpovědi (7F), SID
požadavku a kód, který upřesňuje důvod negativní odpo­
vědi. K dispozici jsou následující kódy:
— 10 General reject (obecné odmítnutí)
Akci nelze provést z důvodů níže neuvedených.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 337
— 11 Service not supported (služba nepodporována)
SID požadavku není srozumitelný.
— 12 Sub function not supported (podfunkce nepodporována)
Bajt DS_ nebo TRTP požadavku není srozumitelný,
nebo není třeba přenést žádné další dílčí zprávy.
— 13 Incorrect message length (chybná délka zprávy)
Délka přijaté zprávy je chybná.
— 22 Conditions not correct or Request sequence error
(nesprávné podmínky nebo chybná posloupnost poža­
davků)
Požadovaná služba není aktivní nebo je chybná posloup­
nost zpráv s požadavky.
— 31 Request out of range (požadavek mimo rozsah)
Záznam s parametry požadavku (datové pole) je
neplatný.
— 50 Upload not accepted (odeslání neakceptováno)
Požadavek nelze provést (VU není v příslušném provo­
zním režimu nebo došlo k interní závadě VU).
— 78 Response pending (odpověď se připravuje)
Požadovanou akci nelze včas dokončit a VU není
připraven přijmout další požadavek.
▼M1
— FA Data not available (data nejsou k dispozici)
Datový objekt požadavku na přenos dat není ve VU k dispo­
zici (např. není vložená žádná karta, požadavek na stažení
dat z VU typu 1. generace je mimo rámec kontroly řidiče
kontrolním orgánem, který nepatří do EU, …).
▼B
2.2.3 Tok zpráv
Typický tok zpráv během normálního postupu stahování dat je násle­
dující:
IDE VU
Start Communication Request ⇨
⇦ Positive Response
Start Diagnostic Service Request ⇨
⇦ Positive Response
Request Upload ⇨
⇦ Positive Response
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 338
IDE VU
Transfer Data Request Overview ⇨
⇦ Positive Response
Transfer Data Request #2 ⇨
⇦ Positive Response #1
Acknowledge Sub Message #1 ⇨
⇦ Positive Response #2
Acknowledge Sub Message #2 ⇨
⇦ Positive Response #m
Acknowledge Sub Message #m ⇨
⇦ Positive Response (datové pole
Acknowledge Sub Message (nepovinná) ⇨
…
Transfer Data Request #n ⇨
⇦ Positive Response
Request Transfer Exit ⇨
⇦ Positive Response
Stop Communication Request ⇨
⇦ Positive Response
2.2.4 Časování
DDP_019 Při normální činnosti platí parametry časování uvedené na
následujícím obrázku:
Obrázek 1
Časování toku zpráv
kde:
P1 = prodleva mezi bajty v odpovědi VU
P2 = prodleva mezi koncem požadavku IDE a začátkem
odpovědi VU nebo mezi koncem potvrzení ze strany
IDE a začátkem následující odpovědi VU
P3 = prodleva mezi koncem odpovědi VU a začátkem
nového požadavku IDE nebo mezi koncem odpovědi
VU a začátkem potvrzení ze strany IDE nebo mezi
koncem požadavku IDE a začátkem nového poža­
davku IDE, pokud VU neodpoví
P4 = prodleva mezi bajty v požadavku IDE
P5 = prodloužená hodnota P3 pro stahování z karty
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 339
Přípustné hodnoty parametrů časování jsou uvedeny v násle­
dující tabulce (rozšířený soubor parametrů časování proto­
kolu KWP používaný v případě fyzického adresování
k urychlení komunikace).
Parametr časování
Spodní mezní hodnota
(ms)
Horní mezní hodnota
(ms)
P1 0 20
P2 20 1 000 (*)
P3 10 5 000
P4 5 20
P5 10 20 minut
(*) Pokud VU odpoví zprávou Negative Response obsahující kód s významem „požadavek správně přijat,
odpověď se připravuje“, prodlužuje se tato hodnota na horní mezní hodnotu parametru P3.
2.2.5 Zpracování chyb
Pokud při výměně zpráv dojde k chybě, schéma toku zpráv se změní
v závislosti na tom, které zařízení chybu zjistilo a která zpráva chybu
vyvolala.
Na obrázku 2 a 3 jsou znázorněny postupy zpracování chyb pro VU
a pro IDE.
2.2.5.1 F á z e z a h á j e n í k o m u n i k a c e
DDP_020 Pokud IDE zjistí chybu ve fázi zahájení komunikace, ať už
z časování, nebo z bitového toku, před zopakováním poža­
davku vyčká po dobu P3min.
DDP_021 Pokud VU zjistí chybu v posloupnosti přicházející z IDE,
neodešle žádnou odpověď a počká na další zprávu Start
Communication Request po dobu P3max.
2.2.5.2 F á z e k o m u n i k a c e
Je možné definovat dvě různé oblasti zpracování chyb:
1. VU zjistí chybu v přenosu z IDE
DDP_022 VU u každé přijaté zprávy detekuje chyby v časování,
chyby ve formátu bajtů (např. porušení start a stop bitu)
a chyby rámce (chybný počet přijatých bajtů, chybný bajt
kontrolního součtu).
DDP_023 Pokud VU zjistí jednu z výše uvedených chyb, neposílá
žádnou odpověď a obdrženou zprávu ignoruje.
DDP_024 VU může detekovat další chyby ve formátu nebo obsahu
obdržené zprávy (např. nepodporovaná zpráva), i když
zpráva splňuje požadavky na délku a kontrolní součet;
v takovém případě VU odešle IDE odpověď Negative
Response specifikující povahu chyby.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 340
Obrázek 2
Zpracování chyb celkem ve vozidle
▼B
2. IDE zjistí chybu v přenosu z VU
DDP_025 IDE u každé přijaté zprávy detekuje chyby časování,
chyby ve formátu bajtů (např. porušení start a stop
bitu) a chyby rámce (chybný počet přijatých bajtů,
chybný bajt kontrolního součtu).
DDP_026 IDE detekuje chyby v posloupnosti, např. chybné zvyšo­
vání čítače dílčích zpráv ve zprávách přijatých za sebou.
DDP_027 Pokud IDE zjistí chybu nebo neobdrží odpověď od VU
v době do P2max, pošle zprávu s požadavkem znovu.
Celkem ji přenese nejvýše třikrát. Pro účely této detekce
chyb se potvrzení dílčí zprávy považuje za požadavek na
VU.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 341
DDP_028 IDE před zahájením každého přenosu vyčká nejméně po
dobu P3min. Čekací doba se měří od posledního vypoč­
teného výskytu stop bitu po zjištění chyby.
Obrázek 3
Zpracování chyb na straně IDE
2.2.6 Obsah zprávy s odpovědí
Tento odstavec specifikuje obsah datových polí různých zpráv
s kladnou odpovědí.
Datové prvky jsou definovány v datovém slovníku v dodatku 1.
Poznámka: Při stahování dat 2. generace je každý datový prvek
nejvyšší úrovně reprezentován polem záznamů, i když obsahuje
pouze jeden záznam. Pole záznamů začíná hlavičkou; tato hlavička
obsahuje typ záznamu, velikost záznamu a počet záznamů. Pole
záznamů jsou v následujících tabulkách nazvána „…RecordArray“ (s
hlavičkou).
▼M3
2.2.6.1 P o s i t i v e R e s p o n s e T r a n s f e r D a t a D o w n l o a d I n t e r ­
f a c e V e r s i o n
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:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 342
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 P o s i t i v e R e s p o n s e T r a n s f e r D a t a O v e r v i e w
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 VuContro­
lActivityData.
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
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 343
Datový prvek Poznámka
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 noOfRe­
cords = 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 noOfRe­
cords = 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 P o s i t i v e R e s p o n s e T r a n s f e r D a t a A c t i v i t i e s
DDP_030 Datové pole zprávy „Positive Response Transfer Data Acti­
vities“ 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í:
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 344
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 zazna­
menané 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 noOfPla­
ceRecords = 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ášt­
ní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 zazna­
menané 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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 345
Datový prvek Poznámka
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 zazna­
menané 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 noOfRe­
cords = 0.
SignatureRecordArray Podpis ECC všech předcházejících dat.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 346
2.2.6.4 P o s i t i v e R e s p o n s e T r a n s f e r D a t a E v e n t s a n d F a u l t s
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 noOfVu­
Faults = 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 noOfVuE­
vents = 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 noOfVu­
OverSpeedingEvents = 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 noOfVu­
TimeAdjRecords = 0.
Signature Podpis RSA všech dat, počínaje prvkem noOfVuFaults
a konče posledním bajtem posledního záznamu o nasta­
vení č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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 347
Datový prvek Poznámka
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 P o s i t i v e R e s p o n s e T r a n s f e r D a t a D e t a i l e d S p e e d
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 pohy­
bovalo),
60 hodnot rychlosti za minutu (jedna za sekundu).
Signature Podpis RSA všech dat, počínaje prvkem noOfSpeed­
Blocks a konče posledním bajtem posledního bloku
rychlostí.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 348
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 pohy­
bovalo),
60 hodnot rychlosti za minutu (jedna za sekundu).
SignatureRecordArray Podpis ECC všech předcházejících dat.
2.2.6.6 P o s i t i v e R e s p o n s e T r a n s f e r D a t a T e c h n i c a l D a t a
DDP_033 Datové pole zprávy „Positive Response Transfer Data Tech­
nical 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 vuManufactu­
rerName 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.
VuSensorExternalGNSSCoupledRecor­
dArray
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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 349
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.
VuSensorExternalGNSSCoupledRecor­
dArray
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.
▼B
2.3 Ukládání souborů na externí paměťové médium
DDP_034 Pokud byl součástí relace stahování přenos dat z VU, IDE
uloží do jednoho fyzického souboru všechna data přijatá
z VU během relace stahování ve zprávách Positive
Response Transfer Data. Uložená data nezahrnují hlavičky
zpráv, čítače dílčích zpráv, prázdné dílčí zprávy a kontrolní
součty, ale zahrnují SID a TREP (jen první dílčí zprávy,
pokud je dílčích zpráv více).
3. PROTOKOL PRO STAHOVÁNÍ DAT Z KARET TACHOGRAFU
3.1 Oblast působnosti
Tento odstavec popisuje přímé stahování dat z karty tachografu do
IDE. IDE není součástí bezpečnostního prostředí, neprobíhá proto
ověření pravosti mezi kartou a IDE.
3.2 Definice
Relace stahování: Každé stahování dat z čipové
karty (ICC). Relace zahrnuje
celý postup od resetování ICC
zařízením IFD až po deaktivaci
ICC (vyjmutí karty nebo další
reset).
Podepsaný datový soubor: Soubor z ICC. Soubor se
přenáší do IFD jako otevřený
text. V ICC se vypočte hash
souboru, soubor se podepíše
a podpis se přenese do IFD.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 350
3.3 Stahování z karty
▼M3
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 nepo­
vinné 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í mecha­
nismy“ čá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 Tacho­
graph_G2 DF:
— Stažení EF CardSignCertificate, CA_Certificate
a Link_Certificate. Tyto informace nejsou zabez­
pečeny digitálním podpisem.
— Tyto soubory musí být povinně staženy v rámci
každé relace stahování.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 351
— 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í mecha­
nismy“ částí B.
— V každé relaci stahování musí být povinně
staženy alespoň elementární soubory Applica­
tion_Identification, Application_Identifica­
tion_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 Tacho­
graph 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.
▼B
3.3.1 Inicializační sekvence
DDP_036 IDE zahájí sekvenci takto:
Karta Směr IDE/IFD Význam/poznámky
⇦ Hardwarový reset
ATR ⇨
Nepovinně lze pomocí PPS přepnout na vyšší rychlost
přenosu dat, pokud ji ICC podporuje.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 352
3.3.2 Sekvence pro nepodepsané datové soubory
DDP_037 ►M1 Sekvence stahování EF ICC, IC, Card_Certificate
(nebo CardSignCertificate pro DF Tachograph_G2),
CA_Certificate a Link_Certificate (pouze pro DF Tacho­
graph_G2) je následující: ◄
Karta Směr IDE/IFD Význam/poznámky
⇦ Select File Výběr podle identifikátorů
souboru
OK ⇨
⇦ Read Binary Pokud soubor obsahuje více
dat, než je velikost vyrovná­
vací paměti čtečky nebo
karty, je třeba příkaz
opakovat, dokud není přečten
celý soubor.
Data souboru
OK
⇨ Uložení dat na ESM Podle bodu 3.4 Formát ulože­
ných dat
Poznámka 1: Před vybráním EF Card_Certificate (nebo
CardSignCertificate) musí být vybrána aplikace tachografu
(výběr podle AID).
Poznámka 2: Výběr a čtení souboru lze rovněž provést
v jednom kroku pomocí příkazu Read Binary s krátkým
identifikátorem EF.
3.3.3 Sekvence pro podepsané datové soubory
DDP_038 Pro každý z následujících souborů, které je třeba stáhnout
s podpisem, se použije tato sekvence:
▼M1
Karta Směr IDE/IFD Význam/poznámky
Select File
OK
Perform Hash of File — Vypočte hodnotu hash dat
obsažených ve vybraném
souboru pomocí předepsa­
ného hašovacího algo­
ritmu podle dodatku 11
části A nebo B. Tento
příkaz není příkazem ISO.
Výpočet hodnoty hash
souboru a dočasné
uložení hodnoty hash
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 353
Karta Směr IDE/IFD Význam/poznámky
OK
Read Binary Pokud soubor obsahuje více
dat, než pojme vyrovnávací
paměť čtečky nebo karty, je
třeba příkaz opakovat, dokud
není přečten celý soubor.
Data souboru
OK
Uložení přijatých dat na
ESM
Podle bodu 3.4 Data storage
format
PSO: Compute Digital
Signature
Provedení bezpeč­
nostní operace
Compute Digital
Signature (výpočet
digitálního podpisu)
pomocí dočasně
uložené hodnoty hash
Podpis
OK
Připojení dat k datům dříve
uloženým na ESM
Podle bodu 3.4 Data storage
format
▼B
Poznámka: Výběr a čtení souboru lze rovněž provést
v jednom kroku pomocí příkazu Read Binary s krátkým
identifikátorem EF. V takovém případě lze EF vybrat
a přečíst před použitím příkazu Perform Hash of File.
3.3.4 Sekvence pro reset počítadla kalibrací
DDP_039 Sekvence pro reset počítadla
v EF
na kartě dílny je následující:
Karta Směr IDE/IFD Význam/poznámky
⇦ Select File EF
Card_Download
Výběr podle identifikátorů
souboru
OK ⇨
⇦ Update Binary
NoOfCalibrationsSinceDown­
load = „00 00“
reset počtu stažení
z karty
OK ⇨
Poznámka: Výběr a aktualizaci souboru lze rovněž provést
v jednom kroku pomocí příkazu Update Binary s krátkým
identifikátorem EF.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 354
3.4 Formát uložených dat
3.4.1 Úvod
DDP_040 Stažená data musí být uložena za těchto podmínek:
— Data se ukládají transparentně. To znamená, že při
uložení musí být zachováno pořadí bajtů přenesených
z karty, jakož i pořadí bitů uvnitř bajtů.
— Všechny soubory karty stažené během relace stahování
jsou v ESM uloženy v jednom souboru.
3.4.2 Formát souboru
DDP_041 Soubor má formát zřetězení několika objektů TLV.
DDP_042 Tag elementárního souboru je FID plus přípona „00“.
DDP_043 Tag podpisu elementárního souboru je FID souboru plus
přípona „01“.
DDP_044 Délka je dvoubajtová hodnota. Její hodnota určuje počet
bajtů v poli s hodnotou. Hodnota „FF FF“ v poli délky je
vyhrazena pro budoucí použití.
DDP_045 Jestliže se nějaký soubor nestahuje, neukládá se nic, co
s tímto souborem souvisí (žádný tag ani nulová délka).
▼M1
DDP_046 Podpis se uloží jako následující objekt TLV bezprostředně
za objekt TLV, který obsahuje data souboru.
Definice Význam Délka
FID (2 bajty) || „00“ Tag pro EF (FID) v DF
nebo pro
společné informace karty
3 bajty
FID (2 bajty) || „01“ Tag pro podpis EF (FID)
v DF
3 bajty
FID (2 bajty) || „02“ Tag pro EF (FID) v DF 3 bajty
FID (2 bajty) || „03“ Tag pro podpis EF (FID)
v DF
3 bajty
xx xx Délka pole s hodnotou 2 bajty
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 355
Příklad stažených dat v souboru na ESM:
Tag Délka Hodnota
— Data EF ICC
— Data EF Card_Certificate
— …
Data EF (v DF
)
Podpis EF (v DF
)
Data EF v DF
Podpis EF v DF
▼B
4. STAHOVÁNÍ Z KARTY TACHOGRAFU PŘES JEDNOTKU VE
VOZIDLE
DDP_047 VU musí umožnit stažení obsahu vložené karty řidiče do
připojeného IDE.
DDP_048 IDE tento režim zahájí zasláním zprávy Transfer Data
Request Card Download do VU (viz bod 2.2.2.9)
▼M1
DDP_049 Karty řidiče první generace: data se stahují pomocí proto­
kolu pro stahování dat první generace a stažená data mají
stejný formát jako data stažená z celku ve vozidle první
generace.
Karty řidiče druhé generace: VU poté stáhne data z celé
karty, soubor po souboru, v souladu s protokolem pro staho­
vání z karty definovaným v odstavci 3 a přepošle všechna
data přijatá z karty do IDE v patřičném formátu souboru
TLV (viz bod 3.4.2) a zapouzdřená ve zprávě Positive
Response Transfer Data.
▼B
DDP_050 IDE načte data z karty ze zprávy Positive Response Transfer
Data (přičemž odstraní všechny hlavičky, bajty SID
a TREP, čítače dílčích zpráv a kontrolní součty) a uloží je
do jednoho fyzického souboru, jak popisuje odstavec 2.3.
DDP_051 VU poté v příslušných případech aktualizuje soubor
nebo soubor na
kartě řidiče.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 356
Dodatek 8.
KALIBRAČNÍ PROTOKOL
OBSAH
1. ÚVOD
2. POJMY, DEFINICE A ODKAZY
3. PŘEHLED SLUŽEB
3.1. Dostupné služby
3.2. Kódy odpovědí
4. KOMUNIKAČNÍ SLUŽBY
4.1. Služba StartCommunication (zahájení komunikace)
4.2. Služba StopCommunication (ukončení komunikace)
4.2.1 Popis zprávy
4.2.2 Formát zprávy
4.2.3 Definice parametrů
4.3. Služba TesterPresent (zkušební zařízení připojeno)
4.3.1 Popis zprávy
4.3.2 Formát zprávy
5. ŘÍDÍCÍ SLUŽBY
5.1. Služba StartDiagnosticSession
5.1.1 Popis zprávy
5.1.2 Formát zprávy
5.1.3 Definice parametrů
5.2. Služba SecurityAccess
5.2.1 Popis zprávy
5.2.2 Formát zprávy – SecurityAccess – requestSeed
5.2.3 Formát zprávy – SecurityAccess – sendKey
6. SLUŽBY PŘENOSU DAT
6.1. Služba ReadDataByIdentifier
6.1.1 Popis zprávy
6.1.2 Formát zprávy
6.1.3 Definice parametrů
6.2. Služba WriteDataByIdentifier
6.2.1 Popis zprávy
6.2.2 Formát zprávy
6.2.3 Definice parametrů
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 357
7. ŘÍZENÍ ZKUŠEBNÍCH IMPULSŮ – ŘÍDÍCÍ FUNKČNÍ CELEK
VSTUPU/VÝSTUPU
7.1. Služba InputOutputControlByIdentifier
7.1.1 Popis zprávy
7.1.2 Formát zprávy
7.1.3 Definice parametrů
▼M3
8. SLUŽBA ROUTINECONTROL (NASTAVENÍ ČASU)
8.1. Popis zprávy
8.2. Formát zprávy
9. FORMÁTY DATARECORDS
9.1. Rozsahy přenášených parametrů
9.2. Formáty dataRecords
▼B
1. ÚVOD
Tento dodatek popisuje, jak se vyměňují data mezi celkem ve
vozidle (VU) a zkušebním zařízením po vodiči K, který tvoří část
kalibračního rozhraní popsaného v dodatku 6. Popisuje také řízení
signálového vodiče vstup/výstup (I/O) na kalibračním konektoru.
Navázání komunikace po vodiči K je popsáno v části 4 „Komunikační
služby“.
Tento dodatek používá koncepci diagnostických „relací“ k tomu, aby
stanovil rozsah řízení vodičem K za různých podmínek. Výchozí relací
je „StandardDiagnosticSession“ (standardní diagnostická relace), kdy
mohou být veškerá data z celku ve vozidle čtena, ale žádná data
nemohou být do celku ve vozidle zapisována.
Volba diagnostické relace je popsána v části 5 „Řídící služby“.
Tento dodatek je třeba, v souladu s požadavky na interoperabilitu
stanovenými v tomto nařízení, považovat za relevantní pro obě gene­
race celků ve vozidle a karet dílny.
CPR_001 Relace „ECUProgrammingSession“ (programovací relace
ECU) umožňuje zadávání dat do celku ve vozidle. V případě
zadávání kalibračních dat musí být celek ve vozidle navíc
v pracovním režimu kalibrace (CALIBRATION).
Přenos dat po vodiči K je popsán v části 6 „Služby přenosu
dat“. Formáty přenášených dat jsou podrobně uvedeny
v části 8 „Formáty dataRecords“.
CPR_002 Relace „ECUAdjustmentSession“ (seřizovací relace ECU)
umožňuje volbu režimu I/O (vstup/výstup) na kalibračním
signálovém vodiči I/O přes rozhraní vodiče K. Řízení kali­
bračního signálového vodiče I /O je popsáno v části 7
„Řízení zkušebních impulsů – Řízení funkčního celku vstup/
výstup“.
CPR_003 V tomto dokumentu je adresa zkušebního zařízení označo­
vána jako ′tt′. I když mohou existovat preferované adresy
zkušebních zařízení, celek ve vozidle musí správně reagovat
na kteroukoli adresu zkušebního zařízení. Fyzická adresa
celku ve vozidle je 0xEE.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 358
2. POJMY, DEFINICE A ODKAZY
Protokoly, zprávy a chybové kódy v podstatě vycházejí z návrhu
normy ISO 14229-1 Road vehicles – Diagnostic systems – Part 1:
Diagnostic services, version 6 (Silniční vozidla — Diagnostické
systémy — Část 1: Diagnostické služby, verze 6 ze dne 22. února
2001).
Pro identifikátory služeb, požadavky na služby, odpovědi a pro stan­
dardní parametry se užívá bajtové kódování a hexadecimální hodnoty.
Pojem „zkušební zařízení“ se vztahuje na zařízení používané pro zadá­
vání programovacích nebo kalibračních dat do celku ve vozidle.
Pojem „klient“ se vztahuje na zkušební zařízení a pojem „server“ na
celek ve vozidle.
Zkratka ECU znamená „elektronický řídící celek“ (Electronic Control
Unit) a vztahuje se na celek ve vozidle.
Odkazy:
▼M1
ISO 14230-2: Road Vehicles – Diagnostic Systems – Keyword
Protocol 2000 – Part 2: Data Link Layer.
First edition: 1999 (Silniční vozidla – Diagnostické systémy – Protokol
klíčových slov 2000 – Část 2: Spojová vrstva. První vydání: 1999).
▼B
3. PŘEHLED SLUŽEB
3.1. Dostupné služby
Dále uvedená tabulka podává přehled služeb, které budou dostupné
v tachografu a které jsou v tomto dokumentu definovány.
CPR_004 Tabulka uvádí služby dostupné v povolené diagnostické
relaci.
— Prvý sloupec uvádí seznam dostupných služeb.
— Druhý sloupec obsahuje číslo části v tomto dodatku, ve
kterém je daná služba dále definována.
— Třetí sloupec přiděluje zprávám se žádostí hodnoty
identifikátorů služeb.
— Čtvrtý sloupec specifikuje služby „StandardDiagnos­
ticSession“ (SD) (standardní diagnostická relace), které
musí být implementovány v každém celku ve vozidle.
— Pátý sloupec specifikuje služby „ECUAdjustmentSes­
sion“ (ECUAS), které musí být implementovány pro
umožnění řízení signálového vodiče I/O z kalibračního
konektoru na čelním panelu celku ve vozidle.
— Šestý sloupec specifikuje služby „ECUProgramming­
Session“ (ECUPS), které musí být implementovány pro
umožnění programování parametrů v celku ve vozidle.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 359
Tabulka 1
Souhrnná tabulka hodnot identifikátorů (Id) služeb
Diagnostické relace
Název diagnostické služby
Číslo
části
Požadovaná
hodnota identi­
fikátoru služby
SD ECUAS ECUPS
StartCommunication 4.1 81 ■ ■ ■
StopCommunication 4.2 82 ■
TesterPresent 4.3 3E ■ ■ ■
StartDiagnosticSession 5.1 10 ■ ■ ■
SecurityAccess 5.2 27 ■ ■ ■
ReadDataByIdentifier 6.1 22 ■ ■ ■
WriteDataByIdentifier 6.2 2E ■
InputOutputControlByIdentifier 7.1 2F ■
▼M3
RoutineControl 8 31
▼B
■ Tento symbol značí, že služba je v této diagnostické relaci povinná.
Pokud není symbol uveden, znamená to, že tato služba není v této diagnostické
relaci povolena.
3.2. Kódy odpovědí
Kódy odpovědí jsou definovány pro každou službu.
4. KOMUNIKAČNÍ SLUŽBY
Některé služby jsou potřebné k navázání a udržování komunikace.
Neobjevují se na aplikační vrstvě. Tyto dostupné služby jsou rozepsány
v následující tabulce:
Tabulka 2
Komunikační služby
Název služby Popis
StartCommunication Klient požaduje zahájení komunikační
relace se serverem (servery).
StopCommunication Klient požaduje ukončení probíhající
komunikační relace.
TesterPresent Klient oznamuje serveru, že je stále
připojen.
CPR_005 Služba StartCommunication se užívá pro zahájení komuni­
kace. Pro navedení jakékoliv služby musí být komunikace
inicializována a komunikační parametry musí odpovídat
požadovanému režimu.
4.1. Služba StartCommunication (zahájení komunikace)
CPR_006 Po obdržení indikačního prvku StartCommunication musí
celek ve vozidle ověřit, zda může být požadované komuni­
kační spojení za současných podmínek inicializováno.
Platné podmínky pro inicializaci komunikačního spojení
jsou popsány v dokumentu ISO 14230-2.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 360
CPR_007 Pak musí celek ve vozidle provést veškeré kroky potřebné
pro inicializaci komunikačního spojení a musí odeslat prvek
s odpovědí na StartCommunication společně se zvolenými
parametry kladné odpovědi.
CPR_008 Pokud celek ve vozidle, který byl již inicializován (a který
vstoupil do jakékoli diagnostické relace), obdrží nový poža­
davek StartCommunication (například v důsledku zotavení
z chyb ve zkušebním zařízení), musí být požadavek přijat
a celek ve vozidle musí být znovu inicializován.
CPR_009 Pokud nemůže být z jakéhokoliv důvodu komunikační
spojení inicializováno, musí celek ve vozidle pokračovat
v činnosti, kterou provozoval bezprostředně před pokusem
o inicializaci komunikačního spojení.
CPR_010 Zpráva s požadavkem StartCommunication musí být fyzicky
adresována.
CPR_011 Inicializace celku ve vozidle proběhne postupem „rychlé
inicializace“.
— Každé činnosti předchází klidová doba sběrnice,
— Zkušební zařízení pak vyšle inicializační sekvenci.
— Veškeré informace, které jsou potřebné pro zahájení
komunikace, jsou obsaženy v odpovědi celku ve
vozidle.
CPR_012 Po dokončení inicializace:
— se veškeré komunikační parametry nastaví podle klíčo­
vých bajtů na hodnoty definované v tabulce 4,
— celek ve vozidle vyčkává na první požadavek zkušeb­
ního zařízení,
— celek ve vozidle je ve výchozím diagnostickém režimu,
tj. StandardDiagnosticSession,
— kalibrační signálový vodič I/O je ve výchozím stavu, tj.
v neaktivním stavu.
CPR_014 Rychlost přenosu dat na vodiči K musí být 10 400 baudů.
CPR_016 Rychlá inicializace je zahájena zkušebním zařízením, které
vysílá startovací sekvenci (Wup) po vodiči K. Sekvence
začíná po klidové době na vodiči K nízkou úrovní po
dobu Tinil. Zkušební zařízení vyšle prvý bit ze StartCom­
municationService následně po době Twup po první
sestupné hraně.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 361
CPR_017 Hodnoty časování pro rychlou inicializaci a komunikaci jsou
obecně rozepsány v níže uvedených tabulkách. Existují
různé možnosti pro dobu klidu (idle time):
— První přenos po zapnutí napájení, Tidle = 300 ms.
— Po dokončení služby StopCommunication Tidle = P3
min.
— Po ukončení komunikace v důsledku překročení doby
P3max, Tidle = 0.
Tabulka 3
Hodnoty časování pro rychlou inicializaci
Parametr Minimální hodnota Maximální hodnota
Tinil 25 ± 1 ms 24 ms 26 ms
Twup 50 ± 1 ms 49 ms 51 ms
Tabulka 4
Hodnoty časování pro komunikaci
Parametr
časování
Popis parametru
Dolní mezní
hodnoty (ms)
Horní mezní
hodnoty (ms)
min. max.
P1 Doba mezi bajty pro odpověď
celku ve vozidle
0 20
P2 Doba mezi požadavkem
zkušebního zařízení a odpovědí
celku ve vozidle nebo mezi
dvěma odpověďmi celku ve
vozidle
25 250
P3 Doba mezi koncem odpovědi
celku ve vozidle a začátkem
nového požadavku zkušebního
zařízení
55 5 000
P4 Doba mezi bajty pro poža­
davek zkušebního zařízení
5 20
CPR_018 Formáty zprávy pro rychlou inicializaci jsou rozepsány
v níže uvedených tabulkách: (POZNÁMKA: Hex znamená
hexadecimální)
Tabulka 5
zpráva se žádostí StartCommunication
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Bajt formátu — fyzické adre­
sování
81 FMT
#2 Bajt adresy cíle EE TGT
#3 Bajt adresy zdroje tt SRC
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 362
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#4 Id služby požadavku Start­
Communication
81 SCR
#5 Kontrolní součet 00-FF CS
Tabulka 6
zpráva s kladnou odpovědí na StartCommunication
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Bajt formátu — fyzické adre­
sování
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Dodatečný bajt délky 03 LEN
#5 Id služby kladné odpovědi na
StartCommunication
C1 SCRPR
#6 Klíčový bajt 1 EA KB1
#7 Klíčový bajt 2 8F KB2
#8 Kontrolní součet 00-FF CS
CPR_019 Na zprávu StartCommunication není záporná odpověď,
pokud neexistuje zpráva s kladnou odpovědí, která má být
přenesena, pak se celek ve vozidle neinicializuje, nic se
nepřenáší a celek ve vozidle zůstává v normálním provozu.
4.2. Služba StopCommunication (ukončení komunikace)
4.2.1 Popis zprávy
Tato služba komunikační vrstvy slouží k ukončení komunikační relace.
CPR_020 Po obdržení indikačního prvku StopCommunication musí
celek ve vozidle ověřit, zda existující podmínky umožňují
tuto komunikaci ukončit. V tomto případě musí celek ve
vozidle provést veškeré kroky potřebné k ukončení této
komunikace.
CPR_021 Pokud je komunikaci možno ukončit, musí celek ve vozidle,
dříve než je komunikace ukončena, vydat prvek odpovědi
StopCommunication se zvolenými parametry kladné odpo­
vědi.
CPR_022 Pokud nemůže být komunikace z jakéhokoliv důvodu ukon­
čena, vydá celek ve vozidle prvek odpovědi na StopCom­
munication se zvoleným parametrem záporné odpovědi.
CPR_023 Pokud celek ve vozidle zjistí překročení času P3max, komu­
nikace se ukončí bez vydání prvku odpovědi.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 363
4.2.2 Formát zprávy
CPR_024 Formáty zpráv pro prvky StopCommunication jsou roze­
psány v níže uvedených tabulkách.
Tabulka 7
zpráva se žádostí StopCommunication
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy EE TGT
#3 Bajt adresy zdroje tt SRC
#4 Bajt dodatečné délky 01 LEN
#5 Id služby požadavku Stop­
Communication
82 SPR
#6 Kontrolní součet 00-FF CS
Tabulka 8
zpráva s kladnou odpovědí na StopCommunication
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 01 LEN
#5 Id služby kladné odpovědi na
StopCommunication
C2 SPRPR
#6 Kontrolní součet 00-FF CS
Tabulka 9
zpráva se zápornou odpovědí na StopCommunication
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 03 LEN
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 364
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#5 Id služby záporné odpovědi 7F NR
#6 Identifikace služby požadavku
StopCommunication
82 SPR
#7 responseCode = generalReject 10 RC_GR
#8 Kontrolní součet 00-FF CS
4.2.3 Definice parametrů
Tato služba nevyžaduje žádné definice parametrů
4.3. Služba TesterPresent (zkušební zařízení připojeno)
4.3.1 Popis zprávy
Pomocí služby TesterPresent zkušební zařízení indikuje serveru, že je
stále připojeno, aby tak bylo serveru zabráněno v automatickém
návratu do normálního provozu a případnému ukončení komunikace.
Tato služba, která se vysílá pravidelně, udržuje diagnostickou relaci /
komunikaci aktivní tím, že vždy po obdržení požadavku na tuto službu
se resetuje časovač P3.
4.3.2 Formát zprávy
CPR_079 Formáty zpráv pro prvky TesterPresent jsou rozepsány
v níže uvedených tabulkách.
Tabulka 10
zpráva se žádostí TesterPresent
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy EE TGT
#3 Bajt adresy zdroje tt SRC
#4 Bajt dodatečné délky 02 LEN
#5 Id služby požadavku Tester­
Present
3E TP
#6 Podfunkce = respon­
seRequired =
[ano 01 RESPREQ_Y
ne] 02 RESPREQ_NO
#7 Kontrolní součet 00-FF CS
CPR_080 Je-li parametr responseRequired nastaven na „ano“, odpoví
server následující kladnou zprávou. Je-li nastaven na „ne“,
neodešle server žádnou odpověď.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 365
Tabulka 11
zpráva s kladnou odpovědí na TesterPresent
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 01 LEN
#5 Id služby kladné odpovědi na
TesterPresent
7E TPPR
#6 Kontrolní součet 00-FF CS
CPR_081 Služba podporuje následující kódy negativních odpovědí:
Tabulka 12
zpráva se zápornou odpovědí na TesterPresent
Bajt č. Název parametru
Hexade­
cimální
hodnota
Symbol
#1 Formátový bajt — fyzické adreso­
vání
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 03 LEN
#5 Id služby záporné odpovědi 7F NR
#6 Identifikace služby požadavku
TesterPresent
3E TP
#7 response­
Code =
[SubFunctionNotSup­
ported-InvalidFormat
12 RC_SFNS_IF
incorrectMessage­
Length ]
13 RC_IML
#8 Kontrolní součet 00-FF CS
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 366
5. ŘÍDÍCÍ SLUŽBY
Dostupné služby jsou rozepsány v následující tabulce:
Tabulka 13
Řídící služby
Název služby Popis
StartDiagnosticSession Klient požaduje zahájení diagnostické relace
s celkem ve vozidle.
SecurityAccess Klient požaduje přístup k funkcím vyhra­
zeným pro autorizované uživatele.
5.1. Služba StartDiagnosticSession
5.1.1 Popis zprávy
CPR_025 Služba StartDiagnosticSession se užívá pro povolení
různých diagnostických relací na serveru. Diagnostická
relace umožňuje specifický soubor služeb podle tabulky
17. Relace může povolit služby specifické pro výrobce
vozidel, které nejsou součástí tohoto dokumentu. Pravidla
implementace musí odpovídat těmto požadavkům:
— V celku ve vozidle musí být vždy aktivní jediná diagno­
stická relace.
— Vždy, když je celek ve vozidle připojen na napájení,
musí zahájit StandardDiagnosticSession. Pokud není
zahájena jiná diagnostická relace, pak StandardDiagnos­
ticSession probíhá tak dlouho, dokud je celek ve vozidle
napájen.
— Pokud je zkušebním zařízením požadována diagnostická
relace, která již probíhá, odešle celek ve vozidle zprávu
s kladnou odpovědí.
— Kdykoli zkušební zařízení požaduje novou diagno­
stickou relaci, odešle celek ve vozidle nejprve zprávu
s kladnou odpovědí na StartDiagnosticSession předtím,
než se v celku ve vozidle aktivuje nová relace. Pokud
není celek ve vozidle schopen zahájit požadovanou
novou diagnostickou relaci, musí odpovědět zprávou se
zápornou odpovědí na StartDiagnosticSession a probíha­
jící relace musí pokračovat.
CPR_026 Diagnostická relace se zahájí pouze tehdy, pokud byla mezi
klientem a celkem ve vozidle zahájena komunikace.
CPR_027 Pokud byla dříve aktivní jiná diagnostická relace, stanou se
parametry časování podle definice v tabulce 4 aktivními po
úspěšné StartDiagnosticSession s parametrem diagnosticSes­
sion nastaveným ve zprávě se žádostí o„StandardDiagnos­
ticSession“.
5.1.2 Formát zprávy
CPR_028 Formáty zpráv pro prvky StartDiagnosticSession jsou roze­
psány v níže uvedených tabulkách.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 367
Tabulka 14
zpráva se žádostí StartDiagnosticSession
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy EE TGT
#3 Bajt adresy zdroje tt SRC
#4 Bajt dodatečné délky 02 LEN
#5 Id služby požadavku StartDi­
agnosticSession
10 STDS
#6 diagnosticSession = [jedna
hodnota z tabulky 17]
xx DS_…
#7 Kontrolní součet 00-FF CS
Tabulka 15
zpráva s kladnou odpovědí na StartDiagnosticSession
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 02 LEN
#5 Id služby kladné odpovědi na
StartDiagnosticSession
50 STDSPR
#6 diagnosticSession = [ shodná
hodnota s bajtem #6 tabulka
14 ]
xx DS_…
#7 Kontrolní součet 00-FF CS
Tabulka 16
zpráva se zápornou odpovědí na StartDiagnosticSession
Bajt č. Název parametru
Hexade­
cimální
hodnota
Symbol
#1 Formátový bajt — fyzické adreso­
vání
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 368
Bajt č. Název parametru
Hexade­
cimální
hodnota
Symbol
#4 Bajt dodatečné délky 03 LEN
#5 Id služby záporné odpovědi 7F NR
#6 Id služby požadavku StartDiagnostic­
Session
10 STDS
#7 Response­
Code =
[subFunctionNotSup­
ported ( α )
12 RC_SFNS
incorrectMessage­
Length ( β )
13 RC_IML
conditionsNotCor­
rect ( γ )
22 RC_CNC
#8 Kontrolní součet 00-FF CS
( α ) – hodnota vložená do bajtu # 6 zprávy o požadavku není podporována, tj. není
v tabulce 17,
( β ) – délka obdržené zprávy je chybná,
( γ ) – kritéria pro požadavek StartDiagnosticSession nejsou splněna.
5.1.3 Definice parametrů
CPR_029 Parametr diagnosticSession (DS_) využívá služba StartDi­
agnosticSession k výběru zvláštního chování serveru
(serverů). V tomto dokumentu jsou specifikovány tyto
diagnostické relace:
Tabulka 17
Definice hodnot diagnosticSession
Hex Popis Symbol
81 StandardDiagnosticSession
Tato diagnostická relace umožňuje všechny
služby podle tabulky 1 sloupce 4 „SD“. Tyto
služby umožňují čtení dat ze serveru (celku ve
vozidle). Tato diagnostická relace je aktivní po
úspěšném dokončení inicializace mezi klientem
(zkušebním zařízením) a serverem (celkem ve
vozidle). Tato diagnostická relace může být
přepsána jinými diagnostickými relacemi speci-
fikovanými v této části.
SD
85 ECUProgrammingSession
Tato diagnostická relace umožňuje všechny
služby podle tabulky 1 sloupce 6 „ECUPS“.
Tyto služby podporují programování paměti
serveru (celku ve vozidle). Tato diagnostická
relace může být přepsána jinými diagnostickými
relacemi specifikovanými v této části.
ECUPS
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 369
Hex Popis Symbol
87 ECUAdjustmentSession
Tato diagnostická relace umožňuje všechny
služby podle tabulky 1 sloupce 5 „ECUAS“.
Tyto služby podporují řízení vstupu/výstupu
serveru (celku ve vozidle). Tato diagnostická
relace může být přepsána jinými diagnostickými
relacemi specifikovanými v této části.
ECUAS
5.2. Služba SecurityAccess
Zapisování kalibračních dat není možné, pokud celek ve vozidle není
v režimu KALIBRACE. Kromě vložení platné karty dílny do celku ve
vozidle je nezbytné dříve, než je udělen přístup k režimu KALI­
BRACE, vložit do celku ve vozidle příslušný PIN.
Přístup ke kalibračnímu vodiči I/O je také možný, pokud je celek ve
vozidle v režimu KALIBRACE nebo KONTROLA (CONTROL).
Služba SecurityAccess poskytuje prostředky pro vložení PIN a indikuje
zkušebnímu zařízení, zda celek ve vozidle je, nebo není v režimu
KALIBRACE.
PIN může být vložen alternativními postupy.
5.2.1 Popis zprávy
Služba SecurityAccess je tvořena zprávou SecurityAccess„requestSeed“
následovanou zprávou SecurityAccess „sendKey“. Služba SecurityAc­
cess musí být provedena po službě StartDiagnosticSession.
CPR_033 Zkušební zařízení využívá zprávu SecurityAccess „request­
Seed“, pro ověření, zda je celek ve vozidle připraven k přijetí
PIN.
CPR_034 Pokud je celek ve vozidle již v režimu KALIBRACE, musí
odpovědět na požadavek vysláním „seed“ 0x0000 s
využitím služby kladné odpovědi na SecurityAccess.
CPR_035 Pokud je celek ve vozidle připraven k přijetí PIN pro
ověření kartou dílny, musí odpovědět na požadavek
vysláním „seed“ většího než 0x0000 s využitím služby
kladné odpovědi na SecurityAccess.
CPR_036 Pokud není celek ve vozidle připraven k přijetí PIN od
zkušebního zařízení, buď protože vložená karta dílny není
platná, nebo protože karta dílny nebyla vložena, nebo
protože celek ve vozidle očekává PIN jiným postupem,
odpoví celek ve vozidle na požadavek zápornou odpovědí
s kódem odpovědi nastaveným na conditionsNotCorrectOr­
RequestSequenceError.
CPR_037 Zkušební zařízení pak použije k předání PIN do celku ve
vozidle zprávu SecurityAccess „sendKey“. K tomu, aby byl
k dispozici čas potřebný k ověření pravosti karty, použije
celek ve vozidle pro prodloužení času pro odpověď kód
záporné odpovědi requestCorrectlyReceived-ResponsePen­
ding. Maximální doba pro odpověď však nesmí překročit
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 370
pět minut. Jakmile byla požadovaná služba dokončena, musí
celek ve vozidle vyslat zprávu s kladnou odpovědí nebo
zprávu se zápornou odpovědí s odlišným kódem odpovědi.
Kód záporné odpovědi requestCorrectlyReceived-Response­
Pending může být celkem ve vozidle opakován do dokon­
čení požadované služby a do vyslání zprávy s konečnou
odpovědí.
CPR_038 Celek ve vozidle musí na tento požadavek odpovědět užitím
služby SecurityAccess PositiveResponse pouze v režimu
KALIBRACE.
CPR_039 Celek ve vozidle musí v následujících případech odpovědět
na tento požadavek zápornou odpovědí s kódem odpovědi
nastaveným na:
— subFunctionNot supported: neplatný formát pro parametr
podfunkce (accessType),
— conditionsNotCorrectOrRequestSequenceError: celek ve
vozidle není připraven k přijetí PIN,
— invalidKey: PIN není platný a počet pokusů o ověření
PIN není překročen,
— exceededNumberOfAttempts: PIN není platný a počet
pokusů o ověření PIN je překročen,
— generalReject: PIN je správný, ale selhalo vzájemné
ověření s kartou dílny.
5.2.2 Formát zprávy – SecurityAccess – requestSeed
CPR_040 Formáty zpráv pro prvky SecurityAccess „requestSeed“ jsou
rozepsány v níže uvedených tabulkách.
Tabulka 18
požadavek SecurityAccess – zpráva requestSeed
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy EE TGT
#3 Bajt adresy zdroje tt SRC
#4 Bajt dodatečné délky 02 LEN
#5 Id služby požadavku Securi­
tyAccess
27 SA
#6 accessType – requestSeed 7D AT_RSD
#7 Kontrolní součet 00-FF CS
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 371
Tabulka 19
SecurityAccess – zpráva s kladnou odpovědí requestSeed
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 04 LEN
#5 Id služby kladné odpovědi na
SecurityAccess
67 SAPR
#6 accessType – requestSeed 7D AT_RSD
#7 Seed High 00-FF SEEDH
#8 Seed Low 00-FF SEEDL
#9 Kontrolní součet 00-FF CS
Tabulka 20
zpráva se zápornou odpovědí na SecurityAccess
Bajt č. Název parametru
Hexade­
cimální
hodnota
Symbol
#1 Formátový bajt — fyzické adreso­
vání
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 03 LEN
#5 Id služby záporné odpovědi 7F NR
#6 Id služby požadavku SecurityAccess 27 SA
#7 response­
Code =
[conditionsNotCorrec­
tOrRequestSequence­
Error
22 RC_CNC
incorrectMessage­
Length]
13 RC_IML
#8 Kontrolní součet 00-FF CS
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 372
5.2.3 Formát zprávy – SecurityAccess – sendKey
CPR_041 Formáty zpráv pro prvky SecurityAccess „sendKey“ jsou
rozepsány v níže uvedených tabulkách.
Tabulka 21
požadavek SecurityAccess – zpráva sendKey
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy EE TGT
#3 Bajt adresy zdroje tt SRC
#4 Bajt dodatečné délky m+2 LEN
#5 Id služby požadavku Securi­
tyAccess
27 SA
#6 accessType – sendKey 7E AT_SK
#7 až #m+6 Klíč #1 (nejvýznamnější) xx KEY
… …
Klíč #m (nejméně významný,
m musí být nejméně 4
a nejvýše 8)
xx
#m+7 Kontrolní součet 00-FF CS
Tabulka 22
SecurityAccess – zpráva s kladnou odpovědí na sendKey
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 02 LEN
#5 Id služby kladné odpovědi na
SecurityAccess
67 SAPR
#6 accessType – sendKey 7E AT_SK
#7 Kontrolní součet 00-FF CS
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 373
Tabulka 23
zpráva se zápornou odpovědí na SecurityAccess
Bajt č. Název parametru
Hexade­
cimální
hodnota
Symbol
#1 Formátový bajt — fyzické adreso­
vání
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 03 LEN
#5 Id služby záporné odpovědi 7F NR
#6 Id služby požadavku SecurityAccess 27 SA
#7 Response­
Code =
[generalReject 10 RC_GR
subFunctionNotSup­
ported
12 RC_SFNS
incorrectMessage­
Length
13 RC_IML
conditionsNotCorrec­
tOrRequestSequence­
Error
22 RC_CNC
invalidKey 35 RC_IK
exceededNumberO­
fAttempts
36 RC_ENA
requestCorrectlyRe­
ceived-ResponsePen­
ding]
78 RC_RCR_RP
#8 Kontrolní součet 00-FF CS
6. SLUŽBY PŘENOSU DAT
Dostupné služby jsou rozepsány v následující tabulce:
Tabulka 24
Služby přenosu dat
Název služby Popis
ReadDataByIdentifier Klient požaduje přenos aktuální hodnoty
záznamu přístupem pomocí recordDataIden­
tifier
WriteDataByIdentifier Klient žádá o zápis záznamu přístupem
pomocí recordDataIdentifier
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 374
6.1. Služba ReadDataByIdentifier
6.1.1 Popis zprávy
CPR_050 Služba ReadDataByIdentifier je využívána klientem pro
vyžádání hodnot datového záznamu ze serveru. Data jsou
identifikována pomocí recordDataIdentifier. Je odpovědností
výrobce celku ve vozidle, aby při výkonu této služby byly
splněny podmínky serveru.
6.1.2 Formát zprávy
CPR_051 Formáty zpráv pro prvky ReadDataByIdentifier jsou roze­
psány v níže uvedených tabulkách.
Tabulka 25
zpráva se žádostí ReadDataByIdentifier
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy EE TGT
#3 Bajt adresy zdroje tt SRC
#4 Bajt dodatečné délky 03 LEN
#5 Id služby požadavku Read­
DataByIdentifier
22 RDBI
#6 až #7 recordDataIdentifier =
[hodnota z tabulky 28]
xxxx RDI_…
#8 Kontrolní součet 00-FF CS
Tabulka 26
zpráva s kladnou odpovědí na ReadDataByIdentifier
Bajt č. Název parametru
Hexade­
cimální
hodnota
Symbol
#1 Formátový bajt — fyzické adreso­
vání
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky m+3 LEN
#5 Id služby kladné odpovědi na
ReadDataByIdentifier
62 RDBIPR
#6 a #7 recordDataIdentifier = [stejná
hodnota, jako bajty #6 and #7,
tabulka 25]
xxxx RDI_…
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 375
Bajt č. Název parametru
Hexade­
cimální
hodnota
Symbol
#8 až #m
+7
dataRecord[] = [data#1 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DAT­
Am
#m+8 Kontrolní součet 00-FF CS
Tabulka 27
zpráva se zápornou odpovědí na ReadDataByIdentifier
Bajt č. Název parametru
Hexade­
cimální
hodnota
Symbol
#1 Formátový bajt — fyzické adreso­
vání
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 03 LEN
#5 Id služby záporné odpovědi 7F NR
#6 Id služby požadavku ReadDataByI­
dentifier
22 RDBI
#7 Response­
Code=
[requestOutO­
fRange
31 RC_ROOR
incorrectMessage­
Length
13 RC_IML
conditionsNotCor­
rect]
22 RC_CNC
#8 Kontrolní součet 00-FF CS
6.1.3 Definice parametrů
CPR_052 Parametr recordDataIdentifier (RDI_) ve zprávě o poža­
davku ReadDataByIdentifier identifikuje datový záznam.
▼M3
CPR_053 Hodnoty recordDataIdentifier, definované tímto doku­
mentem, jsou uvedeny v tabulce níže.
Tabulka recordDataIdentifier je tvořena pěti sloupci a něko­
lika řádky.
— První sloupec (Hex) obsahuje „hexadecimální hodnotu“
přiřazenou k prvku recordDataIdentifier specifikova­
nému ve třetím sloupci.
— Druhý sloupec (Datový prvek) stanovuje datový prvek
podle dodatku 1, na kterém je založen prvek recordDa­
taIdentifier (někdy je nutné překódování),
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 376
— Třetí sloupec (Popis) stanovuje odpovídající název
prvku recordDataIdentifier,
— Čtvrtý sloupec (Přístupová práva) stanovuje přístu­
pová 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 HighResolutionTotal
VehicleDistance
R/W RDI_HRTVD
F918 K-ConstantOfRecordingEquipment Kfactor R/W RDI_KF
F91C L-TyreCircumference LfactorTyreCircumference R/W RDI_LF
F91D W-VehicleCharacteristicConstant WvehicleCharacteristicFactor R/W RDI_WVCF
F921 TyreSize TyreSize R/W RDI_TS
F922 nextCalibrationDate NextCalibrationDate R/W RDI_NCD
F92C SpeedAuthorised SpeedAuthorised R/W RDI_SA
F97D vehicleRegistrationNation RegisteringMemberState R/W RDI_RMS
F97E VehicleRegistrationNumber VehicleRegistrationNumber R/W RDI_ VRN
F190 VehicleIdentificationNumber VIN R/W RDI_ VIN
F9D0 SensorSerialNumber MotionSensorSerialNumber R RDI_SSN
F9D1 RemoteCommunicationModuleSerial­
Number
RemoteCommunicationFacility­
SerialNumber
R RDI_RCSN
F9D2 SensorGNSSSerialNumber ExternalGNSSFacilitySerial­
Number
R RDI_GSSN
F9D3 SealDataVu SmartTachographSealsSerial­
Number
R/W RDI_SDV
F9D4 VuSerialNumber VuSerialNumber R RDI_VSN
F9D5 ByDefaultLoadType ByDefaultLoadType R/W RDI_BDLT
F9D6 TachographCardsGen1Suppression TachographCardsGen1Suppres­
sion
R/W RDI_TCG1S
F9D7 VehiclePosition VehiclePosition R RDI_VP
F9D8 LastCalibrationCountry CalibrationCountry R RDI_CC
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 377
CPR_054 Parametr dataRecord (DREC_) se použije ve zprávě
s kladnou odpovědí na ReadDataByIdentifier k tomu, aby
klientovi (zkušebnímu zařízení) byla dodána hodnota dato­
vého záznamu identifikovaného pomocí recordDataIdenti­
fier. Formáty dat jsou specifikovány v části 8. Mohou být
volitelně implementovány další uživatelské dataRecords
včetně vstupu specifického pro VU, vnitřních a výstupních
dat, ty však nejsou definovány v tomto dokumentu.
6.2. Služba WriteDataByIdentifier
6.2.1 Popis zprávy
CPR_056 Službu WriteDataByIdentifier používá klient k zápisu
hodnot datového záznamu na server. Data jsou identifiko­
vána pomocí recordDataIdentifier. Je odpovědností výrobce
celku ve vozidle, aby při výkonu této služby byly splněny
podmínky serveru. Pro aktualizaci parametrů uvedených
v tabulce 28 musí být celek ve vozidle v režimu KALI­
BRACE.
6.2.2 Formát zprávy
CPR_057 Formáty zpráv pro prvky WriteDataByIdentifier jsou roze­
psány v níže uvedených tabulkách.
Tabulka 29
zpráva se žádostí WriteDataByIdentifier
Bajt č. Název parametru
Hexade­
cimální
hodnota
Symbol
#1 Formátový bajt — fyzické adreso­
vání
80 FMT
#2 Bajt cílové adresy EE TGT
#3 Bajt adresy zdroje tt SRC
#4 Bajt dodatečné délky m+3 LEN
#5 Id služby požadavku WriteData­
ByIdentifier
2E WDBI
#6 až #7 recordDataIdentifier = [hodnota
z tabulky 28]
xxxx RDI_…
#8 až
#m+7
dataRecord[] = [data#1 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DAT­
Am
#m+8 Kontrolní součet 00-FF CS
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 378
Tabulka 30
zpráva s kladnou odpovědí na WriteDataByIdentifier
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 03 LEN
#5 Id služby kladné odpovědi na
WriteDataByIdentifier
6E WDBIPR
#6 až #7 recordDataIdentifier = [stejná
hodnota, jako bajty #6 and
#7, tabulka 29]
xxxx RDI_…
#8 Kontrolní součet 00-FF CS
Tabulka 31
zpráva se zápornou odpovědí na WriteDataByIdentifier
Bajt č. Název parametru
Hexade­
cimální
hodnota
Symbol
#1 Formátový bajt — fyzické adreso­
vání
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 03 LEN
#5 Id služby záporné odpovědi 7F NR
#6 Id služby požadavku WriteDataByI­
dentifier
2E WDBI
#7 Response­
Code=
[requestOutO­
fRange
31 RC_ROOR
incorrectMessage­
Length
13 RC_IML
conditionsNotCor­
rect]
22 RC_CNC
#8 Kontrolní součet 00-FF CS
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 379
6.2.3 Definice parametrů
Parametr recordDataIdentifier (RDI_) je definován v tabulce 28.
Parametr dataRecord (DREC_) se použije ve zprávě o požadavku
WriteDataByIdentifier k tomu, aby klientovi (zkušebnímu zařízení)
byly dodány hodnoty datových záznamů identifikovaných pomocí
recordDataIdentifier. Formáty dat jsou specifikovány v části 8.
7. ŘÍZENÍ ZKUŠEBNÍCH IMPULSŮ – ŘÍDÍCÍ FUNKČNÍ CELEK
VSTUPU/VÝSTUPU
Dostupné služby jsou rozepsány v následující tabulce:
Tabulka 32
Řídící funkční celek vstupu/výstupu
Název služby Popis
InputOutputControl­
ByIdentifier
Klient požaduje řízení vstupu/výstupu speci­
fické pro server.
7.1. Služba InputOutputControlByIdentifier
7.1.1 Popis zprávy
Existuje propojení přes přední konektor, které umožňuje, aby zkušební
impulsy byly řízeny nebo monitorovány pomocí vhodného zkušebního
zařízení.
CPR_058 Tento kalibrační signálový vodič I/O (vstup/výstup) může
být konfigurován příkazem přes vodič K využitím služby
InputControlByIdentifier k volbě požadované vstupní nebo
výstupní funkce vodiče. Dostupné stavy vodiče jsou:
— neaktivní,
— speedSignalInput, kdy je kalibrační signálový vodič I/O
použit pro vstup rychlostního signálu (zkušební signál),
který nahrazuje rychlostní signál snímače pohybu; tato
funkce není dostupná v režimu KONTROLA,
— realTimeSpeedSignalOutputSensor, kdy je kalibrační
signálový vodič I/O použit pro výstup rychlostního
signálu ze snímače pohybu,
— RTCOutput, kdy je kalibrační signálový vodič I/O
použit pro výstup hodinového signálu UTC; tato funkce
není dostupná v režimu KONTROLA.
CPR_059 Celek ve vozidle musí zahájit seřizovací relaci a musí být
v režimu KALIBRACE, nebo KONTROLA, aby bylo
možné konfigurovat stav vodiče. Pokud je celek ve vozidle
v režimu KALIBRACE, mohou být vybrány čtyři stavy
spojení (neaktivní, speedSignalInput, realTimeSpeedSigna­
lOutputSensor, RTCOutput). Pokud je celek ve vozidle
v režimu KONTROLA, mohou být vybrány pouze dva
stavy spojení (neaktivní, realTimeSpeedOutputSensor). Při
ukončení seřizovací relace, nebo režimu KALIBRACE,
nebo KONTROLA musí celek ve vozidle zajistit, aby se
kalibrační signálový vodič I/O vrátil do stavu „disabled“
(neaktivní) (výchozí).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 380
CPR_060 Pokud jsou na signálovém vodiči rychlosti v reálném čase
celku ve vozidle přijaty rychlostní impulsy v době, kdy je
kalibrační signálový vodič I/O nastaven jako vstup, musí se
kalibrační signálový vodič I/O nastavit jako výstup nebo
vrátit do neaktivního stavu.
CPR_061 Sekvence je tato:
— zahájit komunikaci prostřednictvím služby StartCommu­
nication,
— zahájit seřizovací relaci prostřednictvím služby StartDi­
agnosticSession a být v provozním režimu KALI­
BRACE, nebo KONTROLA (pořadí těchto dvou operací
není důležité),
— změnit stav výstupu pomocí služby InputOutputControl­
ByIdentifier.
7.1.2 Formát zprávy
CPR_062 Formáty zpráv pro prvky InputOutputControlByIdentifier
jsou rozepsány v níže uvedených tabulkách.
Tabulka 33
zpráva se žádostí InputOutputControlByIdentifier
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy EE TGT
#3 Bajt adresy zdroje tt SRC
#4 Bajt dodatečné délky xx LEN
#5 Id služby požadavku Inpu­
tOutputControlByIdentifier
2F IOCBI
#6 a #7 InputOutputIdentifier = [Cali­
brationInputOutput]
F960 IOI_CIO
#8 nebo
#8 až #9
ControlOptionRecord = [ COR_…
inputOutputControlParameter –
one value from tabulky 36
xx IOCP_…
controlState — jedna z hodnot
v tabulce 37 (viz poznámka
níže)
xx CS_…
#9 nebo
#10
Kontrolní součet 00-FF CS
Poznámka: parametr controlState je přítomný jen v některých
případech (viz 7.1.3).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 381
Tabulka 34
zpráva s kladnou odpovědí na InputOutputControlByIdentifier
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky xx LEN
#5 Id služby kladné odpovědi na
inputOutputControlByIdenti­
fier
6F IOCBIPR
#6 a #7 inputOutputIdentifier = [Cali­
brationInputOutput]
F960 IOI_CIO
#8 nebo
#8 až #9
controlStatusRecord = [ CSR_
inputOutputControlParameter
(stejná hodnota jako bajt #8
v tabulce 33)
xx IOCP_…
controlState (stejná hodnota
jako bajt #9 v tabulce 33)] (v
příslušných případech)
xx CS_…
#9 nebo
#10
Kontrolní součet 00-FF CS
Tabulka 35
zpráva se zápornou odpovědí na InputOutputControlByIdentifier
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt — fyzické
adresování
80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt adresy zdroje EE SRC
#4 Bajt dodatečné délky 03 LEN
#5 Id služby záporné odpovědi 7F NR
#6 Id služby požadavku inputOut­
putControlByIdentifier
2F IOCBI
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 382
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#7 responseCode=[
incorrectMessageLength 13 RC_IML
conditionsNotCorrect 22 RC_CNC
requestOutOfRange 31 RC_ROOR
deviceControlLimitsExceeded] 7A RC_DCLE
#8 Kontrolní součet 00-FF CS
7.1.3 Definice parametrů
CPR_064 Parametr inputOutputControlParameter (IOCP_) je defi­
nován v následující tabulce.
Tabulka 36
Definice hodnot inputOutputControlParameter
Hex Popis Symbol
00 ReturnControlToECU
Tato hodnota indikuje serveru (celku ve vozidle),
že zkušební zařízení již neřídí kalibrační signálo-
vý vodič I/O.
RCTECU
01 ResetToDefault
Tato hodnota indikuje serveru (celku ve vozidle),
že se od něj požaduje nastavení kalibračního
signálového vodiče I/O do výchozího stavu.
RTD
03 ShortTermAdjustment
Tato hodnota musí indikovat serveru (celku ve
vozidle), že se požaduje nastavení kalibračního
signálového vodiče I/O na hodnotu obsaženou
v parametru controlState.
STA
CPR_065 Parametr controlState je přítomen pouze tehdy, když je
inputOutputControlParameter nastaven na ShortTermAdjust­
ment, a je definován v následující tabulce:
Tabulka 37
Definice hodnot controlState
Režim
Hexadecimální
hodnota
Popis
Neaktivní 00 I/O vodič je neaktivní (výchozí stav)
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 383
Režim
Hexadecimální
hodnota
Popis
Aktivní 01 Aktivuje kalibrační spojení I/O jako speed­
SignalInput
Aktivní 02 Aktivuje kalibrační spojení I/O jako realTi­
meSpeedSignalOutputSensor
Aktivní 03 Aktivuje kalibrační spojení I/O jako
RTCOutput
▼M3
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 requestRoutineRe­
sults, 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 (TimeAdjust­
ment) 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
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt – fyzické adresování 80 FMT
#2 Bajt cílové adresy EE TGT
#3 Bajt zdrojové adresy tt SRC
#4 Bajt dodatečné délky xx LEN
#5 RoutineControl Request Sid (SID požadavku RoutineControl) 31 RC
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 a #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 Kontrolní součet 00-FF CS
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 384
Tabulka 37b
RoutineControl, rutina (TimeAdjustment), podfunkce startRoutine, zpráva s kladnou odpovědí
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt – fyzické adresování 80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt zdrojové adresy EE SRC
#4 Bajt dodatečné délky xx LEN
#5 RoutineControl Positive Response Sid (SID kladné odpovědi na
požadavek RoutineControl)
71 RCPR
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 a #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 Kontrolní součet 00-FF CS
Tabulka 37c
RoutineControl, zpráva s požadavkem týkajícím se rutiny (TimeAdjustment), podfunkce requestRoutineResults
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt – fyzické adresování 80 FMT
#2 Bajt cílové adresy EE TGT
#3 Bajt zdrojové adresy tt SRC
#4 Bajt dodatečné délky xx LEN
#5 RoutineControl Request Sid (SID požadavku RoutineControl) 31 RC
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 a #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 Kontrolní součet 00-FF CS
Tabulka 37d
RoutineControl, rutina (TimeAdjustment), podfunkce requestRoutineResults, zpráva s kladnou odpovědí
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt – fyzické adresování 80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt zdrojové adresy EE SRC
#4 Bajt dodatečné délky xx LEN
#5 RoutineControl Positive Response Sid (SID kladné odpovědi na
požadavek RoutineControl)
71 RCPR
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 a #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 routineInfo (viz tabulka 37f) XX RINF_TA
#10 routineStatusRecord[] = routineStatus#1 (viz tabulka 37g) XX RS_TA
#11 Kontrolní součet 00-FF CS
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 385
Tabulka 37e
RoutineControl, rutina (TimeAdjustment), zpráva se zápornou odpovědí
Bajt č. Název parametru
Hexadecimální
hodnota
Symbol
#1 Formátový bajt – fyzické adresování 80 FMT
#2 Bajt cílové adresy tt TGT
#3 Bajt zdrojové adresy EE SRC
#4 Bajt dodatečné délky 03 LEN
#5 negativeResponse Service Id (Identifikátor služby negativeRe­
sponse)
7F NR
#6 inputOutputControlByIdentifier Request SId 31 RC
#7 responseCode=[
sub-functionNotSupported
incorrectMessageLengthOrInvalidFormat
conditionsNotCorrect
requestOutOfRange
]
12
13
22
31
SFNS
IMLOIF
CNC
ROOR
#8 Kontrolní součet 00-FF CS
Tabulka 37f
RoutineControl, rutina (TimeAdjustment), routineInfo
routineInfo
Hexadecimální
hodnota
Popis
NormalExitWithResultAvailable 61 Rutina byla plně provedena; k dispozici jsou další
výsledky rutiny.
RoutineExecutionOngoing 78 Požadovaná rutina je stále prováděna.
Tabulka 37g
RoutineControl, rutina (TimeAdjustment), routineStatus
Hexadecimální
hodnota
Výsledek zkoušky Popis
01 pozitivní Nastavení času bylo úspěšně dokončeno.
02..0F Vyhrazeno pro budoucí použití (RFU)
10 negativní Žádný příjem signálu GNSS.
11..7F Vyhrazeno pro budoucí použití (RFU)
80..FF Specifické podle výrobce
9. FORMÁTY DATARECORDS
Tato část uvádí:
— 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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 386
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ěře­
ného typu (tj. musí se jednat o aktuální hodnotu požadova­
né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á obsa­
huje 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 indi­
cator“ (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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 387
CPR_074 V tabulce 39 je uvedena délka, rozlišení a pracovní rozsah
každého z parametrů identifikovaných pomocí jeho record­
DataIdentifier.
Tabulka 39
Formát dataRecords
Název parametru
Délka dat
(v bajtech)
Rozlišení Pracovní rozsah
TimeDate 8 Podrobnosti viz tabulka 40
HighResolutionTotalVehicleDis­
tance
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
RemoteCommunicationModuleSeri­
alNumber
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
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 388
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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 389
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, SensorGNSSSerial­
Number a RemoteCommunicationModuleSerialNumber:
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 390
Tabulka 45
Rozepsaný formát kódů VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber
a RemoteCommunicationModuleSerialNumber (hodnoty recordDataIdentifier # F9D4, F9D0, F9D2, F9D1)
Bajt Definice parametrů Rozlišení Pracovní rozsah
1 VuSerialNumber, SensorSerialNumber,
SensorGNSSSerialNumber a RemoteCommu­
nicationModuleSerialNumber:
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 defino­
vaný 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 aktuali­
zace aktuální země a regionu opozdit.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 391
Dodatek 9.
SCHVÁLENÍ TYPU MINIMÁLNÍ ROZSAH POŽADOVANÝCH
ZKOUŠEK
OBSAH
1. ÚVOD
2. FUNKČNÍ ZKOUŠKY CELKU VE VOZIDLE
3. FUNKČNÍ ZKOUŠKY SNÍMAČŮ POHYBU
4. FUNKČNÍ ZKOUŠKY KARET TACHOGRAFU
5. ZKOUŠKY VNĚJŠÍHO ZAŘÍZENÍ GNSS
▼M1
6. ZKOUŠKY VNĚJŠÍHO ZAŘÍZENÍ PRO DÁLKOVOU KOMUNIKACI
▼B
7. FUNKČNÍ ZKOUŠKY PAPÍRU
8. ZKOUŠKY INTEROPERABILITY
▼M3
9. ZKOUŠKY OSNMA
▼B
1. ÚVOD
1.1 Schválení typu
ES schválení typu pro záznamové zařízení (nebo jeho součást) nebo pro
kartu tachografu se zakládá na:
▼M1
— osvědčení bezpečnosti, které vychází ze specifikací Common Criteria,
vůči bezpečnostnímu cíli, který je plně v souladu s dodatkem 10 této
přílohy,
▼B
— osvědčení funkčnosti prováděné příslušným orgánem členského státu,
který osvědčuje, že zkoušený prvek splňuje požadavky této přílohy
z hlediska prováděných funkcí, přesnosti měření a environmentálních
vlastností,
— osvědčení interoperability prováděné příslušným subjektem, který
osvědčuje, že záznamové zařízení (nebo karta tachografu) je plně inte­
roperabilní s potřebnými modely karty tachografu (nebo záznamového
zařízení) (viz kapitolu 8 této přílohy).
Tento dodatek stanoví formou minimálních požadavků, jaké zkoušky musí
provést orgán členského státu při funkčních zkouškách a jaké zkoušky
musí provést příslušný subjekt při zkouškách interoperability. Postup při
zkouškách ani typy zkoušek se podrobněji nespecifikují.
Tento dodatek se nezabývá aspekty osvědčování bezpečnosti. Pokud se
některé ze zkoušek vyžadovaných pro schválení typu provedou v průběhu
hodnocení a osvědčování bezpečnosti, není třeba takové zkoušky
opakovat. V takovém případě stačí posoudit výsledky těchto zkoušek
bezpečnosti. Pro informaci jsou v tomto dodatku hvězdičkou „*“ označeny
požadavky, u kterých se očekává, že budou zkoušeny během osvědčování
bezpečnosti (nebo které úzce souvisí se zkouškami, jejichž provedení se
během osvědčování bezpečnosti očekává).
Číslované požadavky odkazují na text přílohy, zatímco další požadavky
odkazují na ostatní dodatky (např. PIC_001 odkazuje na požadavek
PIC_001 v dodatku 3 Piktogramy).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 392
V tomto dodatku se samostatně pojednává o schválení typu snímače
pohybu, celku ve vozidle a vnějšího zařízení GNSS jako součástí zázna­
mového zařízení. Každá součást získá vlastní osvědčení o schválení typu,
ve kterém budou uvedeny ostatní kompatibilní součásti. Funkční zkouška
snímače pohybu (nebo vnějšího zařízení GNSS) se provádí společně
s celkem ve vozidle a naopak.
Není požadována interoperabilita všech modelů snímačů pohybu (resp.
vnějších zařízení GNSS) a všech modelů celků ve vozidle. V takovém
případě se schválení typu snímače pohybu (resp. vnějšího zařízení GNSS)
může udělit jen ve spojení se schválením typu příslušného celku ve
vozidle a naopak.
▼M3
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.
▼B
1.2 Odkazy
V tomto dodatku se používají tyto odkazy:
IEC 60068-2-1: Environmental testing – Part 2-1: Tests – Test A: Cold
IEC 60068-2-2: Basic environmental testing procedures; part 2: tests;
tests B: dry heat (sinusoidal).
IEC 60068-2-6: Environmental testing – Part 2: Tests – Test Fc: Vibra­
tion
IEC 60068-2-14: Environmental testing; Part 2-14: Tests; Test N: Change
of temperature
IEC 60068-2-27: Environmental testing. Part 2: Tests. Test Ea and
guidance: Shock
IEC 60068-2-30: Environmental testing – Part 2-30: Tests – Test Db:
Damp heat, cyclic (12 h + 12 h cycle)
IEC 60068-2-64: Environmental testing – Part 2-64: Tests – Test Fh:
Vibration, broadband random and guidance
IEC 60068-2-78 Environmental testing – Part 2-78: Tests – Test Cab:
Damp heat, steady state
ISO 16750-3 – Mechanical loads (2012-12)
ISO 16750-4 – Climatic loads(2010-04).
ISO 20653: Road vehicles – Degree of protection (IP code) – Protection
of electrical equipment against foreign objects, water and access
ISO 10605:2008 + technická oprava: 2010 + AMD1: 2014 Road vehicles
– Test methods for electrical disturbances from electrostatic discharge
ISO 7637-1:2002 + AMD1: 2008 Road vehicles – Electrical disturbances
from conduction and coupling – Part 1: Definitions and general conside­
rations.
ISO 7637-2 Road vehicles – Electrical disturbances from conduction and
coupling – Part 2: Electrical transient conduction along supply lines only.
ISO 7637-3 Road vehicles – Electrical disturbances from conduction and
coupling – Part 3: Electrical transient transmission by capacitive and
inductive coupling via lines other than supply lines.
ISO/IEC 7816-1 Identification cards – Integrated circuit(s) cards with
contacts – Part 1: Physical characteristics.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 393
ISO/IEC 7816-2 Information technology – Identification cards – Inte­
grated circuit(s) cards with contacts – Part 2: Dimensions and location
of the contacts.
ISO/IEC 7816-3 Information technology – Identification cards – Inte­
grated circuit(s) cards with contacts – Part 3: Electronic signals and
transmission protocol.
ISO/IEC 10373-1:2006 + AMD1:2012 Identification cards – Test methods
– Part 1: General characteristics
ISO/IEC 10373-3:2010 + technická oprava: 2013 Identification cards –
Test methods – Part 3: Integrated circuit cards with contacts and related
interface devices
ISO 16844-3:2004, oprava 1:2006 Road vehicles – Tachograph systems –
Part 3: Motion sensor interface (with vehicle units).
ISO 16844-4 Road vehicles – Tachograph systems – Part 4: CAN inter­
face
ISO 16844-6 Road vehicles – Tachograph systems – Part 6: Diagnostics
ISO 16844-7 Road vehicles – Tachograph systems – Part 7: Parameters
ISO 534 Paper and board – Determination of thickness, density and
specific volume
▼M3
RGODP Technická zpráva JRC – Receiver guidelines for OSNMA data
processing (Pokyny k přijímačům pro zpracování dat OSNMA)
▼B
Předpis EHK OSN č. 10: Uniform provisions concerning the approval of
vehicles with regard to electromagnetic compatibility (United Nation
Economic Commission for Europe)
2. FUNKČNÍ ZKOUŠKY CELKU VE VOZIDLE
▼M1
Č. Zkouška Popis Související požadavky
1. Administrativní šetření
1.1 Dokumentace Správnost dokumentace
1.2 Výsledky zkoušek
výrobce
Výsledky zkoušek výrobce provedených při
integraci.
Předložení písemných dokladů.
88, 89, 91
2. Vizuální kontrola
2.1 Shoda s dokumentací
2.2 Identifikace/značení 224 až 226
2.3 Materiály 219 až 223
2.4 Plomby 398, 401 až 405
2.5 Vnější rozhraní
3. Funkční zkoušky
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 394
Č. Zkouška Popis Související požadavky
▼M3
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 102* až 104*
3.15 Údaje o činnostech řidiče 105* až 107*
3.16 Údaje o místech a polohách 108* až 112*
3.17 Údaje počitadla ujetých kilometrů 113* až 115*
3.18 Podrobné údaje o rychlosti 116*
3.19 Údaje o událostech 117*
3.20 Údaje o závadách 118*
3.21 Údaje o kalibraci 119* až 121*
3.22 Údaje o nastavení času 124*, 125*
3.23 Údaje o kontrolních činnostech 126*, 127*
3.24 Údaje o zámcích podniku 128*
3.25 Údaje o stahování dat 129*
3.26 Údaje o zvláštních podmínkách 130*, 131*
3.27 Údaje o kartách tachografů 132*, 133*
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 395
Č. Zkouška Popis Související požadavky
3.28 Překročení hranic 133a* až 133d*
3.29 Operace nakládky/vykládky 133e* až 133i*
3.30 Digitální mapa 133j* až 133t*
3.31 Záznam a ukládání dat na kartách tachografů 136, 137, 138*, 139*, 141*,
142, 143
144, 145, 146*, 147*, 147a*,
147b*, 148*, 149, 150, 150a
3.32 Zobrazení 90, 134,
151 až 168,
PIC_001, DIS_001
3.33 Tisk 90, 134,
169 až 181, PIC_001,
PRT_001 až PRT_014
3.34 Varování 134, 182 až 191,
PIC_001
3.35 Stahování údajů na externí paměťová média 90, 134, 192 až 196
3.36 Dálková komunikace pro cílené silniční kontroly 197 až 199
3.37 Výměny dat s dalšími externími zařízeními 200, 201,
3.38 Kalibrace 202 až 206*, 383, 384, 386 až
391
3.39 Silniční kontrola kalibrace 207 až 209
3.40 Nastavení času 210 až 212*
3.41 Monitorování překročení hranic 226a až 226c
3.42 Aktualizace softwaru 226d až 226f
3.43 Neovlivnění přídavnými funkcemi 06, 425
3.44 Rozhraní snímače pohybu 02, 122
3.45 Vnější zařízení GNSS 03, 123
3.46 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
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 396
Č. Zkouška Popis Související požadavky
4. Zkoušky vlivů prostředí
4.1 Teplota Ověřit funkčnost podle těchto zkoušek:
Zkouška podle ISO 16750-4,
kapitoly 5.1.1.2: provozní zkouška při
nízké teplotě (72 h při – 20 °C)
Tato zkouška odkazuje na IEC 60068-2-1:
Zkoušení vlivů prostředí– Část 2-1:
Zkoušky– Zkouška A: Chlad
Zkouška podle ISO 16750-4,
kapitoly 5.1.2.2: provozní zkouška při
vysoké teplotě (72 h při 70 °C)
Tato zkouška odkazuje na IEC 60068-2-2:
Zkoušení vlivů prostředí – Část 2-2:
Zkoušky – Zkouška B: Suché teplo
Zkouška podle ISO 16750-4, kapitoly 5.3.2:
Rychlá změna teploty se stanovenou dobou
přechodu (– 20 °C/70 °C, 20 cyklů,
prodleva 2 h při každé teplotě)
Při nižší teplotě, při vyšší teplotě a během
teplotních cyklů lze provádět omezený
soubor zkoušek (z těch, které jsou defino­
vány v části 3 této tabulky).
213
4.2 Vlhkost Ověřit, že celek ve vozidle vydrží cyklickou
zkoušku vlhkostí (zkouška teplem) podle
IEC 60068-2-30 – Zkouška Db, šest 24hodi­
nových cyklů, každý se změnou teploty od
+ 25 °C do + 55 °C a relativní vlhkostí
97 % při + 25 °C a 93 % při + 55 °C
214
4.3 Mechanické vlivy 1. Sinusové vibrace:
Ověřit, že celek ve vozidle vydrží sinu­
sové vibrace s těmito parametry:
konstantní výchylka mezi 5 a 11 Hz:
max. 10 mm,
konstantní zrychlení mezi 11 a 300 Hz:
5 g.
Tento požadavek se ověřuje podle IEC
60068-2-6 – Zkouška Fc o délce nejméně
3 × 12 hod (12 hod na každou osu).
ISO 16750-3 nevyžaduje zkoušku sinuso­
vými vibracemi u zařízení umístěných
v odpružené kabině vozidla.
2. Náhodné vibrace:
Zkouška podle ISO 16750-3,
kapitoly 4.1.2.8: Zkouška VIII: Užitkové
vozidlo, odpružená kabina vozidla
219
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 397
Č. Zkouška Popis Související požadavky
Zkouška náhodnými vibracemi, 10...2 000
Hz, efektivní vertikální zrychlení 21,3 m/s 2 ,
efektivní podélné zrychlení 11,8 m/s 2 , efek­
tivní příčné zrychlení 13,1 m/s 2 , 3 osy, 32 h
na osu, včetně teplotního cyklu -20...70 °C.
Tato zkouška odkazuje na IEC 60068-2-64:
Zkoušení vlivů prostředí– Část 2-64:
Zkoušky – Zkouška Fh: Širokopásmové
náhodné vibrace a návod
3. Rázy:
mechanický půlsinusový ráz o velikosti
3 g podle ISO 16750.
Výše uvedené zkoušky se provádějí na
různých vzorcích typu testovaného zařízení.
4.4 Ochrana proti vodě
a cizím tělesům
Zkouška podle ISO 20653: Road vehicles –
Degree of protection (IP code) – Protection
of electrical equipment against foreign
objects, water and access (beze změny para­
metrů); minimální hodnota IP 40
220, 221
4.5 Ochrana proti přepětí Ověřit, že celek ve vozidle vydrží tato napá­
jecí napětí:
verze pro napětí 24 V: 34 V při + 40 °C,
1 hod.
verze pro napětí 12 V: 17 V při + 40 °C,
1 hod.
(ISO 16750-2)
216
4.6 Ochrana proti záměně
polarity
Ověřit, že celek ve vozidle vydrží přepólo­
vání napájecího napětí
(ISO 16750-2)
216
4.7 Ochrana proti zkratu Ověřit, že vstupní a výstupní signály jsou
chráněny proti zkratu vůči napájení a uzem­
nění
(ISO 16750-2)
216
5. Zkoušky elektromagnetické kompatibility
5.1 Vyzařované emise
a citlivost
Soulad s předpisem EHK č. 10 218
5.2 Elektrostatický výboj Soulad s ISO 10605:2008 +
technická oprava: 2010 +
AMD1:2014: +/- 4 kV pro kontakt a
+/- 8 kV pro výboj vzduchem
218
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 398
Č. Zkouška Popis Související požadavky
5.3 Odolnost proti rušení
vedenému napájecími
vodiči
Verze pro napětí 24 V: soulad s ISO 7637-
2 + předpisem EHK č. 10 rev. 3:
impuls 1a: Vs = – 450 V, Ri = 50 Ω
impuls 2a: Vs = + 37 V, Ri = 2 Ω
impuls 2b: Vs = + 20 V, Ri = 0,05 Ω
impuls 3a: Vs = – 150 V, Ri = 50 Ω
impuls 3b: Vs = + 150 V, Ri = 50 Ω
impuls 4: Vs = – 16 V, Va = -12 V, t6 =
100 ms
impuls 5: Vs = + 120 V, Ri = 2,2 Ω, td =
250 ms
Verze pro napětí 12 V: soulad s ISO 7637-
1 + předpisem EHK č. 10 rev. 3:
impuls 1: Vs = – 75 V, Ri = 10 Ω
impuls 2a: Vs = + 37 V, Ri = 2 Ω
impuls 2b: Vs = + 10 V, Ri = 0,05 Ω
impuls 3a: Vs = – 112 V, Ri = 50 Ω
impuls 3b: Vs = + 75 V, Ri = 50 Ω
impuls 4: Vs = – 6 V, Va = – 5 V, t6 = 15
ms
impuls 5: Vs = + 65 V, Ri = 3 Ω, td = 100
ms
Impuls 5 se zkouší jen u celků ve vozidle
určených k montáži ve vozidlech, která
nejsou vybavena žádnou vnější společnou
ochranou proti odpojení zátěže.
Návrh týkající se odpojení zátěže viz ISO
16750-2, 4. vydání, kapitola 4.6.4.
218
▼B
3. FUNKČNÍ ZKOUŠKY SNÍMAČŮ POHYBU
Č. Zkouška Popis Související požadavky
1. Administrativní šetření
1.1 Dokumentace Správnost dokumentace
2. Vizuální kontrola
2.1. Shoda s dokumentací
2.2. Identifikace/značení 225, 226,
2.3 Materiály 219 až 223
2.4. Plomby 398, 401 až 405
3. Funkční zkoušky
3.1 Identifikační údaje snímače 95 až 97*
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 399
Č. Zkouška Popis Související požadavky
3.2 Párování snímače pohybu s celkem ve vozidle 122*, 204
3.3 Detekce pohybu
Přesnost měření pohybu
30 až 35
3.4 Rozhraní s celkem ve vozidle 02
3.5 Ověřit, zda je snímač pohybu imunní vůči konstantnímu magnetickému poli.
Alternativně ověřit, že snímač pohybu reaguje na konstantní magnetická pole,
která narušují detekci pohybu vozidla, tak, že připojený celek ve vozidle dete­
kuje, zaznamená a ukládá závady snímače.
217
4. Zkoušky vlivu prostředí
4.1 Provozní teplota Ověřit funkčnost (jak stanoví zkouška č. 3.3)
v teplotním rozsahu [– 40 °C; + 135 °C] podle:
IEC 60068-2-1, zkouška Ad, s dobou trvání 96
hod při nejnižší teplotě To min ,
IEC 60068-2-2, zkouška Bd, s dobou trvání 96
hod při nejvyšší teplotě To max
Zkouška podle ISO 16750-4, kapitoly 5.1.1.2:
provozní zkouška při nízké teplotě (24 h při –
40 °C)
Tato zkouška odkazuje na IEC 60068-2-1: Envi­
ronmental testing – Part 2-1: Tests – Test A:
Cold IEC 68-2-2 zkouška Bd, doba trvání 96
hod. při nejnižší teplotě – 40 °C.
Zkouška podle ISO 16750-4, kapitoly 5.1.2.2:
provozní zkouška při vysoké teplotě (96 h při
135 °C)
Tato zkouška odkazuje na IEC 60068-2-2:
Basic environmental testing procedures; part
2: tests; tests B: dry heat
213
4.2 Teplotní cykly Zkouška podle ISO 16750-4: Chapter 5.3.2:
Rapid change of temperature with specified
transition duration (– 40°C/135 °C, 20 cyklů,
prodleva 30 min při každé teplotě)
IEC 60068-2-14: Environmental testing; Part 2-
14: Tests; Test N: Change of temperature
213
4.3 Vlhkostní cykly Ověřit funkčnost (jak stanoveno ve zkoušce 3.3)
podle IEC 60068-2-30, zkouška Db, šest
24hodinových cyklů, každý se změnou teploty
od + 25 °C do + 55 °C a relativní vlhkostí od
97 % při + 25 °C resp. 93 % při + 55 °C
214
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 400
Č. Zkouška Popis Související požadavky
4.4 Vibrace ISO 16750-3: Chapter 4.1.2.6: Test VI:
Commercial vehicle, engine, gearbox
Zkouška vibracemi ve smíšeném módu zahrnu­
jící:
a) zkoušku sinusovými vibracemi, 20…520 Hz,
11,4 … 120 m/s 2 ,
b) zkoušku náhodnými vibracemi, 10…2 000 Hz,
efektivní zrychlení 177 m/s 2 ;
94 h na osu, včetně teplotního cyklu -20…70 °C
Tato zkouška odkazuje na IEC 60068-2-80: Envi­
ronmental testing – Part 2-80: Tests – Test Fi:
Vibration – Mixed mode
219
4.5 Mechanický ráz ISO 16750-3: Chapter 4.2.3: Test VI: Test for
devices in or on the gearbox
půlsinusový ráz, zrychlení se dohodne v rozsahu
3 000…15 000 m/s 2 , délka impulsu se dohodne,
avšak
Tato zkouška odkazuje na IEC 60068-2-27:
Environmental testing. Part 2: Tests. Test Ea
and guidance: Shock
219
4.6 Ochrana proti vodě a cizím
tělesům
Zkouška podle ISO 20653: Road vehicles –
Degree of protection (IP code) – Protection of
electrical equipment against foreign objects,
water and access
(cílová hodnota IP 64)
220, 221
4.7 Ochrana proti záměně pola­
rity
Ověřit, že snímač pohybu vydrží přepólování
napájecího napětí
216
4.8 Ochrana proti zkratu Ověřit, že vstupní a výstupní signály jsou chrá­
něny proti zkratu vůči napájení a uzemnění
216
5. Elektromagnetická kompatibilita
5.1 Vyzařované emise a citlivost Ověřit soulad s předpisem EHK č. 10 218
5.2 Elektrostatický výboj Soulad s ISO 10605:2008 + technická oprava:
2010 + AMD1: 2014: +/– 4 kV pro kontakt
a +/– 8 kV pro výboj vzduchem
218
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 401
Č. Zkouška Popis Související požadavky
5.3 Odolnost proti rušení vede­
nému datovými vodiči
Verze pro napětí 24 V: soulad s ISO 7637-2 +
předpisem EHK č. 10 rev. 3:
impuls 1a: Vs = – 450 V, Ri = 50 Ω
impuls 2a: Vs = + 37 V, Ri = 2 Ω
impuls 2b: Vs = + 20 V, Ri = 0,05 Ω
impuls 3a: Vs = – 150 V, Ri = 50 Ω
impuls 3b: Vs = + 150 V, Ri = 50 Ω
impuls 4: Vs = – 16 V, Va = – 12 V, t6 = 100
ms
impuls 5: Vs = + 120 V, Ri = 2,2 Ω, td = 250
ms
Verze pro napětí 12 V: soulad s ISO 7637-1 +
předpisem EHK č. 10 rev. 3:
impuls 1: Vs = – 75 V, Ri = 10 Ω
impuls 2a: Vs = + 37 V, Ri = 2 Ω
impuls 2b: Vs = + 10 V, Ri = 0,05 Ω
impuls 3a: Vs = – 112 V, Ri = 50 Ω
impuls 3b: Vs = + 75 V, Ri = 50 Ω
impuls 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms
impuls 5: Vs = + 65 V, Ri = 3 Ω, td = 100 ms
Impuls 5 se zkouší jen u celků ve vozidle urče­
ných k montáži ve vozidlech, která nejsou
vybavena žádnou vnější společnou ochranou
proti odpojení zátěže
Návrh týkající se odpojení zátěže viz ISO
16750-2, 4. vydání, kapitola 4.6.4.
218
4. FUNKČNÍ ZKOUŠKY KARET TACHOGRAFU
Zkoušky podle této části 4,
bodu 5 „Zkoušky protokolu“,
bodu 6 „Struktura karty“ a
bodu 7 „Funkční zkoušky“
může osoba provádějící hodnocení nebo vystavující osvědčení provádět
během postupu osvědčení bezpečnosti podle Common Criteria pro čipový
modul.
Zkoušky č. 2.3 a 4.2 jsou stejné. Jde o mechanické zkoušky kombinace
těla karty a čipového modulu. Pokud se některá z těchto částí (tělo karty,
čipový modul) změní, jsou tyto zkoušky nezbytné.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 402
Č. Zkouška Popis Související požadavky
1. Administrativní šetření
1.1 Dokumentace Správnost dokumentace
2 Tělo karty
2.1 Potisk
Ověřit, že všechny ochranné prvky a viditelné údaje
jsou na kartě správné natištěny a jsou v souladu
s požadavky.
[Označení]
Příloha 1C, kapitola 4.1 „Viditelné údaje“, 227)
Přední strana musí obsahovat:
slova „Karta řidiče“ nebo „Kontrolní karta“ nebo
„Karta dílny“ nebo „Karta podniku“ vytištěná
velkými písmeny v úředním jazyce nebo jazycích
členského státu vydávajícího kartu, podle typu karty.
[Název členského státu]
Příloha 1C, kapitola 4.1 „Viditelné údaje“, 228)
Přední strana musí obsahovat:
název členského státu vydávajícího kartu (volitelně).
[Značka]
Příloha 1C, kapitola 4.1 „Viditelné údaje“, 229)
Přední strana musí obsahovat:
rozlišovací značku členského státu vydávajícího kartu,
která je tištěna inverzně v modrém obdélníku a je
obklopena 12 žlutými hvězdami.
[Číslování]
Příloha 1C, kapitola 4.1 „Viditelné údaje“, 232)
Rubová strana musí obsahovat:
vysvětlení očíslovaných položek uvedených na přední
straně karty.
[Barva]
Příloha 1C, kapitola 4.1 „Viditelné údaje“, 234)
Karty tachografu musí být tištěny s těmito převláda-
jícími barvami pozadí:
— karta řidiče: bílá barva,
— karta dílny: červená barva,
— kontrolní karta: modrá barva,
— karta podniku: žlutá barva.
227 až 229, 232, 234
až 236
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 403
Č. Zkouška Popis Související požadavky
[Zabezpečení]
Příloha 1C, kapitola 4.1 „Viditelné údaje“, 235)
Karty tachografu musí nést minimálně tyto ochranné
prvky, které chrání tělo karty proti padělání a pozmě-
ňování:
— bezpečnostní provedení pozadí ve formě proplé-
tané textury a duhový tisk,
— nejméně jednu dvoubarevnou mikrotiskovou lin-
ku.
[Značení]
Příloha 1C, kapitola 4.1 „Viditelné údaje“, 236)
Členské státy mohou přidat barvy nebo označení, jako
jsou vnitrostátní symboly a bezpečnostní prvky.
[Značka schválení]
Karty tachografu obsahují značku schválení.
Značka schválení sestává:
— z obdélníku, ve kterém je písmeno „e“ následo-
vané rozlišovacím číslem nebo písmeny země,
která udělila schválení,
— z čísla schválení, které odpovídá číslu osvědčení
o schválení karty tachografu a které se umístí
kdekoliv v bezprostřední blízkosti obdélníku.
2.2 Mechanické zkoušky
[Velikost karet]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[5] Dimension of card,
[5.1] Card size,
[5.1.1] Card dimensions and tolererances,
typ karty ID-1 Nepoužitá karta
[Hrany karty]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[5] Dimension of card,
[5.1] Card size,
[5.1.2] Card edges
240, 243
ISO/IEC 7810
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 404
Č. Zkouška Popis Související požadavky
[Konstrukce karet]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[6] Card construction
[Materiály karet]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[7] Card materials
[Ohybová tuhost]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[8] Card characteristics,
[8.1] Bending stiffness
[Toxicita]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[8] Card characteristics,
[8.3] Toxicity
[Odolnost proti chemikáliím]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[8] Card characteristics,
[8.4] Resistance to chemicals
[Stabilita karet]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[8] Card characteristics,
[8.5] Card dimensional stability and warpage with
temperature and humidity
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 405
Č. Zkouška Popis Související požadavky
[Odolnost proti světlu]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[8] Card characteristics,
[8.6] Light
[Trvanlivost]
Příloha 1C, kapitola 4.4 „Environmentální a elektrické
specifikace“, 241)
Karty tachografu musí být schopny správné funkce po
dobu pěti let, pokud jsou používány ve shodě
s předepsanými environmentálními a elektrickými
specifikacemi.
[Odolnost proti loupání]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[8] Card characteristics,
[8.8] Peel strength
[Adheze nebo vytváření bloků]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[8] Card characteristics,
[8.9] Adhesion or blocking
[Průhyb]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[8] Card characteristics,
[8.11] Overall card warpage
[Odolnost proti teplu]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[8] Card characteristics,
[8.12] Resistance to heat
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 406
Č. Zkouška Popis Související požadavky
[Deformace povrchu]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[8] Card characteristics,
[8.13] Surface distortions
[Kontaminace]
Karty tachografu musí odpovídat normě
ISO/IEC 7810, Identification cards – Physical
characteristics,
[8] Card characteristics,
[8.14] Contamination and interaction of card
components
2.3 Mechanické zkoušky
s vloženým čipovým
modulem
[Ohyb]
Karty tachografu musí odpovídat normě
ISO/IEC 7810:2003/Amd. 1:2009, Identification
cards – Physical characteristics, Amendment 1:
Criteria for cards containing integrated circuits
[9.2] Dynamic bending stress
Celkový počet cyklů ohybu: 4 000.
[Torze]
Karty tachografu musí odpovídat normě
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards
– Physical characteristics, Amendment 1: Criteria for
cards containing integrated circuits
[9.3] Dynamic torsional stress
Celkový počet cyklů torze: 4 000.
ISO/IEC 7810
3 Modul
3.1 Modul Modulem je pouzdro čipu a kontaktní destička.
[Profil povrchu]
Karty tachografu musí odpovídat normě
ISO/IEC 7816-1:2011, Identification cards – Inte­
grated circuit cards – Part 1: Cards with contacts
– Physical characteristics
[4.2] Surface profile of contacts
ISO/IEC 7816
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 407
Č. Zkouška Popis Související požadavky
[Mechanická odolnost]
Karty tachografu musí odpovídat normě
ISO/IEC 7816-1:2011, Identification cards – Inte­
grated circuit cards – Part 1: Cards with contacts
– Physical characteristics
[4.3] Mechanical strength (of a card and contacts)
[Elektrický přechodový odpor]
Karty tachografu musí odpovídat normě
ISO/IEC 7816-1:2011, Identification cards – Inte-
grated circuit cards – Part 1: Cards with contacts –
Physical characteristics
[4.4] Electrical resistance (of contacts)
[Rozměry]
Karty tachografu musí odpovídat normě
ISO/IEC 7816-2:2007, Identification cards – Inte-
grated circuit cards – Part 2: Cards with contacts –
Dimension and location of the contacts
[3] Dimension of the contacts
[Umístění]
Karty tachografu musí odpovídat normě
ISO/IEC 7816-2:2007, Identification cards – Inte-
grated circuit cards – Part 2: Cards with contacts –
Dimension and location of the contacts
[4] Number and location of the contacts
V případě modulů se šesti kontakty nejsou součástí
tohoto požadavku na zkoušení kontakty „C4“ a „C8“.
4 Čip
4.1 Čip
[Provozní teplota]
Čip karty tachografu pracuje v rozsahu teplot okolí
od – 25 °C do + 85 °C.
241 až 244
Předpis EHK č. 10
ISO/IEC 7810
ISO/IEC 10373
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 408
Č. Zkouška Popis Související požadavky
[Teplota a vlhkost]
Příloha 1C, kapitola 4.4 „Environmentální a elek­
trické specifikace“, 241)
Karty tachografu musí být schopny správné funkce
za všech klimatických podmínek běžně se vyskytují­
cích na území Společenství a nejméně v rozsahu
teplot od – 25 °C do + 70 °C s příležitostnými špič­
kami do + 85 °C; „příležitostnými“ se rozumí doba
nepřesahující 4 hodiny a ne více než sto opakování
v průběhu životnosti karty.
Karty tachografu jsou postupně po danou dobu
vystaveny následujícím teplotám a vlhkostem. Po
každém kroku se zkouší elektrická funkčnost karet
tachografu.
1. Teplota – 20 °C po dobu 2 h.
2. Teplota +/– 0 °C po dobu 2 h.
3. Teplota + 20 °C a relativní vlhkost 50 % po dobu
2 h.
4. Teplota + 50 °C a relativní vlhkost 50 % po dobu
2 h.
5. Teplota + 70 °C a relativní vlhkost 50 % po dobu
2 h.
Teplota je chvilkově zvyšována na + 85 °C při
relativní vlhkosti 50 % RH po dobu 60 min.
6. Teplota + 70 °C a relativní vlhkost 85 % po dobu
2 h.
Teplota je chvilkově zvyšována na + 85 °C při
relativní vlhkosti 85 % RH po dobu 30 min.
[Vlhkost]
Příloha 1C, kapitola 4.4 „Environmentální a elektrické
specifikace“, 242)
Karty tachografu musí být schopny správné funkce při
vlhkosti v rozsahu 10 % až 90 %.
[Elektromagnetická kompatibilita – EMC]
Příloha 1C, kapitola 4.4 „Environmentální a elektrické
specifikace“, 244)
Během provozu musí karty tachografu vyhovovat
požadavkům předpisu EHK č. 10 ohledně elektro-
magnetické kompatibility.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 409
Č. Zkouška Popis Související požadavky
[Statická elektřina]
Příloha 1C, kapitola 4.4 „Environmentální a elektrické
specifikace“, 244)
Během provozu jsou karty tachografu chráněny proti
elektrostatickým výbojům.
Karty tachografu musí odpovídat normě
ISO/IEC 7810:2003/Amd. 1:2009, Identification
cards – Physical characteristics, Amendment 1:
Criteria for cards containing integrated circuits
[9.4] Static electricity
[9.4.1] Contact IC cards
Zkušební napětí: 4 000 V.
[Rentgenové záření]
Karty tachografu musí odpovídat normě
ISO/IEC 7810:2003/Amd. 1:2009, Identification
cards – Physical characteristics, Amendment 1:
Criteria for cards containing integrated circuits
[9.1] X-rays
[Ultrafialové světlo]
ISO/IEC 10373-1:2006, Identification cards – Test
methods – Part 1: General characteristics
[5.11] Ultraviolet light
[Zkouška třemi koly]
Karty tachografu musí odpovídat normě
ISO/IEC 10373-1:2006/Amd. 1:2012, Identification
cards – Test methods – Part 1: General character-
istics, Amendment 1
[5.22] ICC – Mechanical strength: 3 wheel test for
ICCs with contacts
[Navíjení]
Karty tachografu musí odpovídat normě
MasterCard CQM V2.03:2013
[11.1.3] R-L3-14-8: Wrapping Test Robustness
[13.2.1.32] TM-422: Mechanical Reliability: Wrap-
ping Test
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 410
Č. Zkouška Popis Související požadavky
4.2 Mechanické zkoušky
čipového modulu
vloženého do těla
karty -> stejné jako 2.3
[Ohyb]
Karty tachografu musí odpovídat normě
ISO/IEC 7810:2003/Amd. 1:2009, Identification
cards – Physical characteristics, Amendment 1:
Criteria for cards containing integrated circuits
[9.2] Dynamic bending stress
Celkový počet cyklů ohybu: 4 000.
[Torze]
Karty tachografu musí odpovídat normě
ISO/IEC 7810:2003/Amd. 1:2009, Identification
cards – Physical characteristics, Amendment 1:
Criteria for cards containing integrated circuits
[9.3] Dynamic torsional stress
Celkový počet cyklů torze: 4 000.
ISO/IEC 7810
5 Zkoušky protokolu
5.1 ATR Ověřit, že ATR splňuje požadavky ISO/IEC 7816-3
TCS_14, TCS_17,
TCS_18
5.2 T=0 Ověřit, že protokol T=0 splňuje požadavky ISO/IEC 7816-3
TCS_11, TCS_12,
TCS_13, TCS_15
5.3 PTS Ověřit, že příkaz PTS splňuje požadavky, změnou na
T=1 z T=0
ISO/IEC 7816-3
TCS_12, TCS_19,
TCS_20, TCS_21
5.4 T=1 Ověřit, že protokol T=1 splňuje požadavky ISO/IEC 7816-3
TCS_11, TCS_13,
TCS_16
6 Struktura karty
6.1 Ověřit, že struktura souborů karty splňuje požadavky,
kontrolou přítomnosti povinných souborů na kartě
a podmínek přístupu k nim
TCS_22 až TCS_28
TCS_140 až
TCS_179
7 Funkční zkoušky
7.1 Normální zpracování Nejméně jednou přezkoušet každé povolené použití
každého příkazu (např.: přezkoušet příkaz UPDATE
BINARY s CLA = „00“, s CLA = „0C“ a s různými
parametry P1, P2 a Lc).
Zkontrolovat, zda operace byly na kartě skutečně
provedeny (např. čtením souboru, na němž byl příkaz
proveden).
TCS_29 až TCS_139
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 411
Č. Zkouška Popis Související požadavky
7.2 Chybové zprávy Pro každý příkaz nejméně jednou přezkoušet každou
chybovou zprávu (podle specifikace v dodatku 2).
Nejméně jednou přezkoušet každou obecnou chybu
(kromě chyb integrity „6400“ kontrolovaných během
osvědčování bezpečnosti)
7.3 Sada šifer a standardizované parametry domény CSM_48, CSM_50
8 Personalizace
8.1 Optická personalizace
Příloha 1C, kapitola 4.1 „Viditelné údaje“, 230)
Přední strana musí obsahovat:
informace specifické pro vydávanou kartu.
Příloha 1C, kapitola 4.1 „Viditelné údaje“, 231)
Přední strana musí obsahovat:
data ve formátu „dd/mm/rrrr“ nebo „dd.mm.rrrr“ (den,
měsíc, rok).
Příloha 1C, kapitola 4.1 „Viditelné údaje“, 235)
Karty tachografu musí nést minimálně tyto ochranné
prvky, které chrání tělo karty proti padělání a pozmě-
ňování:
— v oblasti fotografie se musí překrývat bezpečnost-
ní-
provedení pozadí a fotografie.
230, 231, 235
5. ZKOUŠKY VNĚJŠÍHO ZAŘÍZENÍ GNSS
Č. Zkouška Popis Související požadavky
1. Administrativní šetření
1.1 Dokumentace Správnost dokumentace
2. Vizuální kontrola vnějšího zařízení GNSS
2.1. Shoda s dokumentací
2.2. Identifikace/značení 224 až 226
2.3 Materiály 219 až 223
3. Funkční zkoušky
3.1 Identifikační údaje snímače 98,99
3.2 Vazba vnějšího modulu GNSS s celkem ve vozidle 123, 205
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 412
Č. Zkouška Popis Související požadavky
3.3 Poloha dle GNSS 36, 37
3.4 Rozhraní celku ve vozidle, je-li přijímač GNSS vně celku ve vozidle 03
3.5 Sada šifer a standardizované parametry domény CSM_48, CSM_50
4. Zkoušky vlivu prostředí
4.1 Teplota Ověřit funkčnost podle těchto zkoušek:
Zkouška podle ISO 16750-4, kapitoly 5.1.1.2: provozní
zkouška při nízké teplotě (72 h při – 20 °C)
Tato zkouška odkazuje na IEC 60068-2-1: Environmental
testing – Part 2-1: Tests – Test A: Cold
Zkouška podle ISO 16750-4: kapitoly 5.1.2.2: provozní
zkouška při vysoké teplotě (72 h při 70 °C)
Tato zkouška odkazuje na IEC 60068-2-2: Basic environ­
mental testing procedures; part 2: tests; tests B: dry heat
Zkouška podle ISO 16750-4: Chapter 5.3.2: Rapid change of
temperature with specified transition duration (– 20°C/
70 °C, 20 cyklů, prodleva 1 h při každé teplotě)
Při nižší teplotě, při vyšší teplotě a během teplotních cyklů
lze provádět omezený soubor zkoušek (z těch, které jsou
definovány v části 3 této tabulky).
213
4.2 Vlhkost Ověřit, že celek ve vozidle vydrží cyklickou zkoušku vlhkostí
(zkouška teplem) podle IEC 60068-2-30, zkouška Db, šest
24hodinových cyklů, každý se změnou teploty od + 25 °C
do + 55 °C a relativní vlhkostí 97 % při + 25 °C a 93 %
při + 55 °C
214
4.3 Mechanické
vlivy
1. Sinusové vibrace:
ověřit, že celek ve vozidle vydrží sinusové vibrace s těmito
parametry:
konstantní výchylka mezi 5 a 11 Hz: max. 10 mm,
konstantní zrychlení mezi 11 a 300 Hz: 5 g.
Tento požadavek se ověřuje podle IEC 60068-2-6,
zkouška Fc o délce nejméně 3 × 12 hod (12 hod na
každou osu).
ISO 16750-3 nevyžaduje zkoušku sinusovými vibracemi
u zařízení umístěných v odpružené kabině vozidla.
219
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 413
Č. Zkouška Popis Související požadavky
2. Náhodné vibrace:
Zkouška podle ISO 16750-3: Chapter 4.1.2.8: Test VIII:
Commercial vehicle, decoupled vehicle cab
Zkouška náhodnými vibracemi, 10…2 000 Hz, efektivní
vertikální zrychlení 21,3 m/s 2 , efektivní podélné zrychlení
11,8 m/s 2 , efektivní příčné zrychlení 13,1 m/s 2 , 3 osy,
32 h na osu, včetně teplotního cyklu – 20…70 °C.
Tato zkouška odkazuje na IEC 60068-2-64: Environmental
testing – Part 2-64: Tests – Test Fh: Vibration, broadband
random and guidance
3. Rázy:
mechanický půlsinusový ráz o velikosti 3 g podle ISO
16750.
Výše uvedené zkoušky se provádějí na různých vzorcích typu
testovaného zařízení.
4.4 Ochrana proti
vodě a cizím
tělesům
Zkouška podle ISO 20653: Road vehicles – Degree of
protection (IP code) – Protection of electrical equipment
against foreign objects, water and access (beze změn para­
metrů)
220, 221
4.5 Ochrana proti
přepětí
Ověřit, že celek ve vozidle vydrží tato napájecí napětí: 216
verze pro napětí 24 V: 34 V při + 40 °C, 1
hod.
verze pro napětí 12 V: 17 V při + 40 °C, 1
hod.
(ISO 16750-2, kapitola 4.3)
4.6 Ochrana proti
záměně polarity
Ověřit, že celek ve vozidle vydrží přepólování napájecího
napětí
(ISO 16750-2, kapitola 4.7)
216
4.7 Ochrana proti
zkratu
Ověřit, že vstupní a výstupní signály jsou chráněny proti
zkratu vůči napájení a uzemnění
(ISO 16750-2, kapitola 4.10)
216
5 Zkoušky elektromagnetické kompatibility
5.1 Vyzařované
emise a citlivost
Soulad s předpisem EHK č. 10 218
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 414
Č. Zkouška Popis Související požadavky
5.2 Elektrostatický
výboj
Soulad s ISO 10605:2008 + technická oprava: 2010 +
AMD1: 2014: +/– 4 kV pro kontakt a +/– 8 kV pro výboj
vzduchem
218
5.3 Odolnost proti
rušení vede­
nému napáje­
cími vodiči
Verze pro napětí 24 V: soulad s ISO 7637-2 + předpisem
EHK č. 10 rev. 3:
impuls 1a: Vs = – 450 V, Ri = 50 Ω
impuls 2a: Vs = + 37 V, Ri = 2 Ω
impuls 2b: Vs = + 20 V, Ri = 0,05 Ω
impuls 3a: Vs = – 150 V, Ri = 50 Ω
impuls 3b: Vs = + 150 V, Ri = 50 Ω
impuls 4: Vs = – 16 V, Va = – 12 V, t6 = 100 ms
impuls 5: Vs = + 120 V, Ri = 2,2 Ω, td = 250 ms
Verze pro napětí 12 V: soulad s ISO 7637-1 + předpisem
EHK č. 10 rev. 3:
impuls 1: Vs = – 75 V, Ri = 10 Ω
impuls 2a: Vs = + 37 V, Ri = 2 Ω
impuls 2b: Vs = + 10 V, Ri = 0,05 Ω
impuls 3a: Vs = – 112 V, Ri = 50 Ω
impuls 3b: Vs = + 75 V, Ri = 50 Ω
impuls 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms
impuls 5: Vs = + 65 V, Ri = 3 Ω, td = 100 ms
Impuls 5 se zkouší jen u celků ve vozidle určených k montáži
ve vozidlech, která nejsou vybavena žádnou vnější společnou
ochranou proti odpojení zátěže
Návrh týkající se odpojení zátěže viz ISO 16750-2, 4.
vydání, kapitola 4.6.4.
218
▼M1
6. ZKOUŠKA VNĚJŠÍHO ZAŘÍZENÍ PRO DÁLKOVOU KOMUNIKACI
Č. Zkouška Popis Související požadavky
1. Administrativní šetření
1.1 Dokumentace Správnost dokumen­
tace
2. Vizuální kontrola
2.1 Shoda s dokumentací
2.2 Identifikace/značení 225, 226
2.3 Materiály 219 až 223
3. Funkční zkoušky
3.1 Dálková komunikace pro cílené silniční kontroly 4, 197 až 199
3.2 Zaznamenávání a ukládání údajů do datové paměti 91
3.3 Komunikace s celkem ve vozidle Dodatek 14 odstavce
DSC_66 až DSC_70,
DSC_71 až DSC_76
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 415
Č. Zkouška Popis Související požadavky
4. Zkoušky vlivů prostředí
4.1 Teplota Ověřit funkčnost podle těchto zkoušek:
Zkouška podle ISO 16750-4, kapitoly 5.1.1.2: provozní
zkouška při nízké teplotě (72 h při – 20 °C)
Tato zkouška odkazuje na IEC 60068-2-1: Zkoušení
vlivů prostředí– Část 2-1: Zkoušky– Zkouška A: Chlad
Zkouška podle ISO 16750-4, kapitoly 5.1.2.2: provozní
zkouška při vysoké teplotě (72 h při 70 °C)
Tato zkouška odkazuje na IEC 60068-2-2: Zkoušení
vlivů prostředí – Část 2-2: Zkoušky – Zkouška B:
Suché teplo
Zkouška podle ISO 16750-4, kapitoly 5.3.2: Rychlá
změna teploty se stanovenou dobou přechodu (– 20
°C/70 °C, 20 cyklů, prodleva 1 h při každé teplotě)
Při nižší teplotě, při vyšší teplotě a během teplotních
cyklů lze provádět omezený soubor zkoušek (z těch,
které jsou definovány v bodě 3 této tabulky).
213
4.2 Ochrana proti vodě
a cizím tělesům
Zkouška podle ISO 20653: Road vehicles – Degree of
protection (IP code) – Protection of electrical equipment
against foreign objects, water and access (cílová
hodnota IP40)
220, 221
5 Zkoušky elektromagnetické kompatibility
5.1 Vyzařované emise
a citlivost
Soulad s předpisem EHK č. 10 218
5.2 Elektrostatický
výboj
Soulad s ISO 10605:2008 + technická oprava: 2010 +
AMD1:2014: +/- 4 kV pro kontakt a +/- 8 kV pro
výboj vzduchem
218
5.3 Odolnost proti
rušení vedenému
napájecími vodiči
Verze pro napětí 24 V: soulad s ISO 7637-2 + před­
pisem EHK č. 10 rev. 3:
impuls 1a: Vs = – 450 V, Ri = 50 Ω
impuls 2a: Vs = + 37 V, Ri = 2 Ω
impuls 2b: Vs = + 20 V, Ri = 0,05 Ω
impuls 3a: Vs = – 150 V, Ri = 50 Ω
impuls 3b: Vs = + 150 V, Ri = 50 Ω
impuls 4: Vs = – 16 V, Va = – 12 V, t6 = 100 ms
impuls 5: Vs = + 120 V, Ri = 2,2 Ω, td = 250 ms
Verze pro napětí 12 V: soulad s ISO 7637-1 + před­
pisem EHK č. 10 rev. 3:
impuls 1: Vs = – 75 V, Ri = 10 Ω
impuls 2a: Vs = + 37 V, Ri = 2 Ω
impuls 2b: Vs = + 10 V, Ri = 0,05 Ω
impuls 3a: Vs = – 112 V, Ri = 50 Ω
218
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 416
Č. Zkouška Popis Související požadavky
impuls 3b: Vs = + 75 V, Ri = 50 Ω
impuls 4: Vs = – 6 V, Va = -5 V, t6 = 15 ms
impuls 5: Vs = + 65 V, Ri = 3 Ω, td = 100 ms
Impuls 5 se zkouší jen u celků ve vozidle určených
k montáži ve vozidlech, která nejsou vybavena žádnou
vnější společnou ochranou proti odpojení zátěže.
Návrh týkající se odpojení zátěže viz ISO 16750-2, 4.
vydání, kapitola 4.6.4.
▼B
7. FUNKČNÍ ZKOUŠKY PAPÍRU
Č. Zkouška Popis Související požadavky
1. Administrativní šetření
1.1 Dokumentace Správnost dokumentace
2 Všeobecné zkoušky
2.1 Počet znaků na řádek Vizuální kontrola výtisků. 172
2.2 Minimální velikost
písma
Vizuální kontrola výtisku a kontrola znaků. 173
2.3 Podporované
znakové sady
Tiskárna podporuje znaky specifikované v dodatku 1
kapitole 4 „Znakové sady“.
174
2.4 Definice výtisků Kontrola schválení typu tachografu a vizuální kontrola
výtisků
174
2.5 Čitelnost a identifi­
kace výtisků
Kontrola výtisků
Prokazuje se zkušebními zprávami a protokoly výrobce.
Všechna čísla schválení tachografů, s kterými může být
papír do tiskárny používán, jsou natištěna na papíru.
175, 177, 178
2.6 Doplnění rukopis­
ných poznámek
Vizuální kontrola: je k dispozici pole pro podpis řidiče.
Jsou k dispozici pole pro další rukopisné záznamy.
180
2.7 Další podrobnosti na
přední straně papíru
Přední a rubová strana papíru mohou nést další podrob­
nosti a informace.
Tyto další podrobnosti a informace nesmí narušovat
čitelnost výtisků.
Vizuální kontrola.
177, 178
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 417
Č. Zkouška Popis Související požadavky
3 Zkoušky skladování
3.1 Suché teplo Aklimatizace před zkouškou: 16 hodin při + 23 °C
± 2 °C/relativní vlhkosti 55 % ± 3 %
Zkušební prostředí: 72 hodin při + 70 °C ± 2 °C
Aklimatizace po zkoušce: 16 hodin při + 23 °C ± 2 °C/
relativní
vlhkosti 55 % ± 3 %
176, 178
IEC 60068-2-2-Bb
2.2 Vlhké teplo Aklimatizace před zkouškou: 16 hodin při + 23 °C
± 2 °C/relativní vlhkosti 55 % ± 3 %
Zkušební prostředí: 144 hodin při + 55 °C ± 2 °C a rel.
vlhkosti
93 % ± 3 %
Aklimatizace po zkoušce: 16 hodin při + 23 °C ± 2 °C/
relativní
vlhkosti 55 % ± 3 %
176, 178
IEC 60068-2-78-Cab
4 Provozní zkoušky papíru
4.1 Odolnost podkladu
proti vlhkosti (nepo­
tištěný papír)
Aklimatizace před zkouškou: 16 hodin při + 23 °C
± 2 °C/relativní vlhkosti 55 % ± 3 %
Zkušební prostředí: 144 hodin při + 55 °C ± 2 °C a rel.
vlhkosti 93 % ± 3 %
Aklimatizace po zkoušce: 16 hodin při + 23 °C ± 2 °C/
relativní vlhkosti 55 % ± 3 %
176, 178
IEC 60068-2-78-Cab
4.2 Potiskovatelnost Aklimatizace před zkouškou: 24 hodin při + 40 °C
± 2 °C/relativní vlhkosti 93 % ± 3 %
Zkušební prostředí: výtisk pořízen při + 23°C ± 2°C
Aklimatizace po zkoušce: 16 hodin při + 23 °C ± 2 °C/
relativní vlhkosti 55 % ± 3 %
176, 178
4.3 Odolnost proti teplu Aklimatizace před zkouškou: 16 hodin při + 23 °C
± 2 °C/relativní vlhkosti 55 % ± 3 %
Zkušební prostředí: 2 hodiny při + 70 °C ± 2 °C, suché
teplo
Aklimatizace po zkoušce: 16 hodin při + 23 °C ± 2 °C/
relativní vlhkosti 55 % ± 3 %
176, 178
IEC 60068-2-2-Bb
4.4 Odolnost proti nízké
teplotě
Aklimatizace před zkouškou: 16 hodin při + 23 °C
± 2 °C/relativní vlhkosti 55 % ± 3 %
Zkušební prostředí: 24 hodin, – 20 °C ± 3°C, suchý
chlad
Aklimatizace po zkoušce: 16 hodin při + 23 °C ± 2 °C/
relativní vlhkosti 55 % ± 3 %
176, 178
ISO 60068-2-1-Ab
4.5 Odolnost proti světlu Aklimatizace před zkouškou: 16 hodin při + 23 °C
± 2 °C/relativní vlhkosti 55 % ± 3 %
Zkušební prostředí: 100 hodin při osvětlení 5 000 Lux
při + 23 °C ± 2 °C/relativní vlhkosti 55 % ± 3 %
Aklimatizace po zkoušce: 16 hodin při + 23 °C ± 2 °C/
relativní vlhkosti 55 % ± 3 %
176, 178
Kritéria čitelnosti pro zkoušky 3.x a 4.x:
Čitelnost tisku je zaručena, pokud optické hustoty odpovídají těmto
mezním hodnotám:
tištěné znaky: min. 1,0,
podklad (nepotištěný papír): max. 0,2.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 418
Optické hustoty výsledných výtisků se měří podle normy DIN EN ISO
534.
Výtisky nevykazují žádné rozměrové změny a zůstávají jasně čitelné.
8. ZKOUŠKY INTEROPERABILITY
▼M1
Č. Zkouška Popis
8.1 Zkoušky interoperability celků ve vozidle a karet tachografu
1 Vzájemné ověření pravosti Ověřit, že vzájemné ověření pravosti mezi celkem ve vozidle
a kartou tachografu probíhá normálně.
2 Zkoušky zápisu/čtení Provést typický scénář činností s celkem ve vozidle. Scénář je
přizpůsoben typu zkoušené karty a zahrnuje zápis do co největšího
počtu elementárních souborů na kartě.
Ověřit stažením z celku ve vozidle, že všechny příslušné záznamy
byly řádně provedeny.
Ověřit stažením z karty, že všechny příslušné záznamy byly řádně
provedeny.
Ověřit pomocí denních výtisků, že všechny příslušné záznamy lze
řádně přečíst.
8.2 Zkoušky interoperability celků ve vozidle a snímačů pohybu
1 Párování Ověřit, že párování mezi celky ve vozidle a snímači pohybu
probíhá normálně.
2 Zkoušky činnosti Provést typický scénář činností se snímačem pohybu. Scénář
zahrnuje normální činnost a vytvoření co největšího počtu událostí
nebo závad.
Ověřit stažením z celku ve vozidle, že všechny příslušné záznamy
byly řádně provedeny.
Ověřit stažením z karty, že všechny příslušné záznamy byly řádně
provedeny.
Ověřit pomocí denního výtisku, že všechny příslušné záznamy lze
řádně přečíst.
8.3 Zkoušky interoperability celků ve vozidle a vnějších zařízení GNSS (v příslušných případech)
1 Vzájemné ověření pravosti Ověřit, že vzájemné ověření pravosti (vazba) mezi celkem ve
vozidle a vnějším modulem GNSS probíhá normálně.
2 Zkoušky činnosti Provést typický scénář činností s vnějším zařízením GNSS. Scénář
zahrnuje normální činnost a vytvoření co největšího počtu událostí
nebo závad.
Ověřit stažením z celku ve vozidle, že všechny příslušné záznamy
byly řádně provedeny.
Ověřit stažením z karty, že všechny příslušné záznamy byly řádně
provedeny.
Ověřit pomocí denního výtisku, že všechny příslušné záznamy lze
řádně přečíst.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 419
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 prove­
deny 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 odpo­
vě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 uvede­
ný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)
MAC Message Authentication Code (kód ověřování zprávy)
NMACK 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)
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 420
SLMAC Slow MAC (pomalý MAC)
TESLA Timed Efficient Stream Loss-tolerant Authentication
(Protocol used in OSNMA) (časovaný účinný tok ověřo­
vá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 vzor­
kovací 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, infor­
mace 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ů).
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 421
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ě synchronizo­
vá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.
Kritéria vyhovění/nevyhovění: přijímač vypočte do 430
sekund ověřenou platnou určenou polohu.
Dodatek 12,
GNS_3b
2.3 Teplý start OSNMA
se SLMAC
Cíl: ověřit, že přijímač GNSS po teplém startu vypočí­
tává polohu pomocí OSNMA s inicializací času vyža­
dují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 nakonfiguro­
vá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.
Dodatek 12,
GNS_3b
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 422
Č. Zkouška Popis Související požadavky
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.
Kritéria vyhovění/nevyhovění: přijímač vypočte do 730
sekund ověřenou platnou určenou polohu.
2.4 Horký start OSNMA
s přehrávaným
signálem
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ča­
sování nesplňuje požadavek na synchronizaci, a zasta­
vuje zpracování dat OSNMA, jak je definováno v poky­
nech 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
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 423
Dodatek 10
BEZPEČNOSTNÍ POŽADAVKY
Tento dodatek specifikuje bezpečnostní požadavky v oblasti informačních tech­
nologií na součásti systémů inteligentních tachografů (tachografů druhé gene­
race).
SEC_001 Z hlediska bezpečnosti musí být podle režimu Common Criteria certi­
fikovány tyto součásti systémů inteligentních tachografů:
— celek ve vozidle,
— karta tachografu,
— snímač pohybu,
— vnější zařízení GNSS.
SEC_002 Minimální bezpečnostní požadavky v oblasti informačních technologií,
které musí každá součást vyžadující certifikaci z hlediska bezpečnosti
splňovat, musí být podle režimu Common Criteria vymezeny v profilu
ochrany součásti.
SEC_003 Evropská komise zajistí, aby čtyři profily ochrany, jež splňují
podmínky této přílohy, byly podporovány, vyvíjeny, schváleny vlád­
ními orgány pro certifikaci bezpečnosti v oblasti informačních techno­
logií vytvořenými v rámci společné interpretační pracovní skupiny,
která podporuje vzájemné uznávání osvědčení v rámci dohody
o vzájemném uznávání osvědčení o posouzení bezpečnosti informač­
ních technologií Evropského Poradního výboru pro bezpečnost infor­
mačních systémů (SOG-IS MRA), a registrovány:
— profil ochrany celku ve vozidle,
— profil ochrany karty tachografu,
— profil ochrany snímače pohybu,
— profil ochrany vnějšího zařízení GNSS.
Profil ochrany celku ve vozidle se zabývá případy, kdy je celek ve vozidle určen
k tomu, aby byl, nebo nebyl používán s vnějším zařízením GNSS. V prvním
případě jsou bezpečnostní požadavky na vnější zařízení GNSS uvedeny v samo­
statném profilu ochrany.
SEC_004 Výrobci součástí musí dle potřeby upřesnit a doplnit profil ochrany
příslušné součásti, aniž by pozměnili nebo odstranili stávající hrozby,
cíle, postupy a specifikace funkcí zajišťujících bezpečnost, za účelem
stanovení bezpečnostního cíle, podle kterého budou požadovat bezpeč­
nostní certifikaci součásti.
SEC_005 V průběhu hodnocení musí být konstatováno přísné dodržení uvede­
ného bezpečnostního cíle s odpovídajícími profilem ochrany.
SEC_006 Stupeň záruky pro každý profil ochrany musí být EAL4 rozšířený
o složky záruky ATE_DPT.2 a AVA_VAN.5.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 424
Dodatek 11
SPOLEČNÉ BEZPEČNOSTNÍ MECHANISMY
OBSAH
PREAMBULE
ČÁST A SYSTÉM TACHOGRAFU PRVNÍ GENERACE
1. ÚVOD
1.1. Zdroje
1.2. Značení a zkratky
2. KRYPTOGRAFICKÉ SYSTÉMY A ALGORITMY
2.1. Kryptografické systémy
2.2. Kryptografické algoritmy
2.2.1 Algoritmus RSA
2.2.2 Hašovací algoritmus
2.2.3 Algoritmus šifrování dat
3. KLÍČE A CERTIFIKÁTY
3.1. Generování a distribuce klíčů
3.1.1 Generování a distribuce klíčů RSA
3.1.2 Zkušební klíče RSA
3.1.3 Klíče snímače pohybu
3.1.4 Generování a distribuce klíčů T-DES
3.2. Klíče
3.3. Certifikáty
3.3.1 Obsah certifikátů
3.3.2 Vydané certifikáty
3.3.3 Ověření a rozbalení certifikátu
4. MECHANISMUS VZÁJEMNÉHO OVĚŘOVÁNÍ PRAVOSTI
5. DŮVĚRNOST PŘENOSU DAT KARET VU, INTEGRITA
A MECHANISMUS OVĚŘOVÁNÍ PRAVOSTI
5.1. Bezpečné předávání zpráv
5.2. Zacházení s chybami v bezpečném předávání zpráv (SM)
5.3. Algoritmus výpočtu kryptografického kontrolního součtu
5.4. Algoritmus výpočtu šifer pro důvěrnost objektů DO
6. MECHANISMY DIGITÁLNÍCH PODPISŮ PŘI STAHOVÁNÍ
DAT
6.1. Generování podpisu
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 425
6.2. Ověření podpisu
ČÁST B SYSTÉM TACHOGRAFU DRUHÉ GENERACE
7. ÚVOD
7.1. Zdroje
7.2. Značení a zkratky
7.3. Definice
8. KRYPTOGRAFICKÉ SYSTÉMY A ALGORITMY
8.1. Kryptografické systémy
8.2. Kryptografické algoritmy
8.2.1 Symetrické algoritmy
8.2.2 Asymetrické algoritmy a standardní parametry domény
8.2.3 Hašovací algoritmy
8.2.4 Šifrovací soustavy
9. KLÍČE A CERTIFIKÁTY
9.1. Asymetrické páry klíčů a certifikáty veřejných klíčů
9.1.1 Obecné informace
9.1.2 Evropská úroveň
9.1.3 Úroveň členských států
9.1.4 Úroveň zařízení: celky ve vozidle
9.1.5 Úroveň zařízení: karty tachografu
9.1.6 Úroveň zařízení: vnější zařízení GNSS
9.1.7 Přehled: výměna certifikátu
9.2. Symetrické klíče
9.2.1 Klíče pro zabezpečení VU – komunikace snímače pohybu
9.2.2 Klíče pro zabezpečení komunikace DSRC
9.3. Certifikáty
9.3.1 Obecné informace
9.3.2 Obsah certifikátu
9.3.3 Podání žádosti o certifikát
10. VZÁJEMNÉ OVĚŘOVÁNÍ PRAVOSTI A BEZPEČNÉ PŘED­
ÁVÁNÍ ZPRÁV VU A KARTY
10.1. Obecné informace
10.2. Vzájemné ověření řetězce certifikátů
10.2.1 Ověření řetězce certifikátů karty celkem ve vozidle
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 426
10.2.2 Ověření řetězce certifikátů VU kartou
10.3. Ověření pravosti VU
10.4. Ověření pravosti čipu a odsouhlasení klíče relace
10.5. Bezpečné předávání zpráv
10.5.1 Obecné informace
10.5.2 Struktura bezpečné zprávy
10.5.3 Přerušení relace bezpečného předávání zpráv
11. PÁROVÁNÍ VU – VNĚJŠÍ ZAŘÍZENÍ GNSS, VZÁJEMNÉ
OVĚŘOVÁNÍ PRAVOSTI A BEZPEČNÉ PŘEDÁVÁNÍ ZPRÁV
11.1. Obecné informace
11.2. Párování VU a externího zařízení GNSS
11.3. Vzájemné ověření řetězce certifikátů
11.3.1 Obecné informace
11.3.2 Během párování VU – EGF
11.3.3 Během normálního provozu
11.4. Ověřování pravosti VU, ověřování pravosti čipu a odsouhlasení
klíče relace
11.5. Bezpečné předávání zpráv
12. PÁROVÁNÍ A KOMUNIKACE VU – SNÍMAČ POHYBU
12.1. Obecné informace
12.2. Párování VU – snímač pohybu pomocí různých generací klíčů
12.3. Párování a komunikace VU – snímač pohybu pomocí AES
12.4. Párování VU – snímač pohybu pro různé generace zařízení
13. BEZPEČNOST VZDÁLENÉ KOMUNIKACE PROSTŘEDNIC­
TVÍM DSRC
13.1. Obecné informace
13.2. Šifrování přenosu dat tachografu a generování MAC
13.3. Ověření a dešifrování přenosu dat tachografu
14. PODEPISOVÁNÍ STAŽENÝCH DAT A OVĚŘOVÁNÍ
PODPISŮ
14.1. Obecné informace
14.2. Generování podpisu
14.3. Ověření podpisu
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 427
PREAMBULE
Tento dodatek stanovuje bezpečnostní mechanismy, které zajišťují
— vzájemné ověřování pravosti mezi různými součástmi systému tachografu,
— důvěrnost, integritu, ověřování pravosti a/nebo nepopiratelnost dat přenáše­
ných mezi různými součástmi systému tachografu nebo stahovaných do exter­
ních paměťových médií.
Tento dodatek obsahuje dvě části. Část A stanovuje bezpečnostní mechanismy
pro systém tachografu první generace (digitální tachograf). Část B stanovuje
bezpečnostní mechanismy pro systém digitálního tachografu druhé generace
(inteligentní tachograf).
Mechanismy stanovené v části A tohoto dodatku platí, pokud alespoň jedna
součást systému tachografu pro proces vzájemného ověřování pravosti a/nebo
přenosu dat je zařízením první generace.
Mechanismy stanovené v části B tohoto dodatku platí, pokud obě součásti
systému tachografu pro proces vzájemného ověřování pravosti a/nebo přenosu
dat jsou zařízením druhé generace.
Dodatek 15 uvádí další informace týkající se používání součástí první generace
ve spojení se součástmi druhé generace.
ČÁST A
SYSTÉM TACHOGRAFU PRVNÍ GENERACE
1. ÚVOD
1.1. Zdroje
V tomto dodatku jsou použity tyto zdroje:
SHA-1 National Institute of Standards and Technology
(NIST). FIPS Publication 180-1: Secure Hash Stan­
dard. Duben 1995.
PKCS1 RSA Laboratories. PKCS # 1: RSA Encryption Stan­
dard. Verze 2.0. Říjen 1998.
TDES National Institute of Standards and Technology
(NIST). FIPS Publication 46-3: Data Encryption
Standard. Návrh 1999.
TDES-OP ANSI X9.52, Triple Data Encryption Algorithm
Modes of Operation. 1998.
ISO/IEC 7816-4 Information Technology – Identification cards – Inte­
grated circuit(s) cards with contacts (Informační tech­
nologie – Identifikační karty – Karty s integrovanými
obvody a s kontakty) Část 4: Interindustry commands
for interexchange (Mezioborové příkazy pro výměnu).
První vydání: 1995 + Změna 1: 1997.
ISO/IEC 7816-6 Information Technology – Identification cards – Inte­
grated circuit(s) cards with contacts (Informační tech­
nologie – Identifikační karty – Karty s integrovanými
obvody a s kontakty) Část 6: Interindustry data
elements (Mezioborové datové prvky). První vydání:
1996 + Oprava 1: 1998.
ISO/IEC 7816-8 Information Technology – Identification cards – Inte­
grated circuit(s) cards with contacts (Informační tech­
nologie – Identifikační karty – Karty s integrovanými
obvody a s kontakty) Část 8: Security related interin­
dustry commands (Mezioborové příkazy pro bezpeč­
nost). První vydání 1999.
ISO/IEC 9796-2 Information Technology – Security techniques –
Digital signature schemes giving message recovery
(Informační technologie – Bezpečnostní techniky –
Schémata digitálního podpisu umožňující obnovu
zprávy) – Část 2: Mechanisms using a hash function
(Mechanismy využívající hašovací funkci). První
vydání: 1997.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 428
ISO/IEC 9798-3 Information Technology – Security techniques –
Entity authentication mechanisms (Informační techno­
logie – Bezpečnostní techniky – Mechanismy autenti­
zace entit) – Část 3: Entity authentication using
a public key algorithm (Autentizace entit používající
algoritmus s veřejným klíčem). Druhé vydání: 1998.
ISO 16844-3 Road vehicles – Tachograph systems (Silniční vozidla
– Systémy tachografů) – Část 3: Motion sensor inter­
face (Rozhraní snímače pohybu).
1.2. Značení a zkratky
V tomto dodatku jsou užity následující značení a zkratky:
(K a , K b , K c ) balíček klíčů pro užití trojitého algoritmu šifrování
dat,
CA certifikační autorita,
CAR odkaz na certifikační autoritu,
CC kryptografický kontrolní součet,
CG kryptogram,
CH hlavička příkazu,
CHA autorizace držitele certifikátu,
CHR odkaz na držitele certifikátu,
D() dešifrování pomocí standardu pro výměnu dat DES,
DE prvek dat,
DO datový objekt,
d soukromý klíč RSA, soukromý zmocněnec,
e veřejný klíč RSA, veřejný zmocněnec,
E() šifrování pomocí DES,
EQT zařízení,
Hash() hašovací hodnota, výstup hodnoty Hash,
Hash hašovací funkce,
KID identifikátor klíče,
Km klíč TDES. Hlavní klíč podle definice ISO 16844-3,
Km VU klíč TDES vložený do celku ve vozidle,
Km WC klíč TDES, vložený do karty dílny,
m celé číslo mezi 0 a n-1 reprezentující zprávu,
n klíče RSA, modul,
PB doplňkové bajty,
PI indikační bajt doplnění (užití v šifře pro důvěrnost
DO),
PV otevřená hodnota,
s celé číslo mezi 0 a n-1 reprezentující podpis,
SSC čítač odeslané posloupnosti,
SM bezpečné zpracování zpráv,
TCBC TDEA blok číslic svazující provozní režimy,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 429
TDEA trojitý algoritmus šifrování dat,
TLV hodnota délky tagu,
VU celek ve vozidle,
X.C certifikát uživatele X vydaný certifikační autoritou,
X.CA certifikační autorita uživatele X,
X.CA.PK o X.C operace rozbalení certifikátu pro extrakci veřejného
klíče. Je to zaváděcí operátor, jehož levý operand je
veřejným klíčem certifikační autority a jehož pravý
operand je certifikátem vydaným certifikační auto­
ritou. Výstupem je veřejný klíč uživatele X, jehož
certifikát je pravým operandem,
X.PK RSA veřejný klíč uživatele X,
X.PK[I] RSA zašifrování některých informací I při užití veřej­
ného klíče uživatele X,
X.SK RSA soukromý klíč uživatele X,
X.SK[I] RSA zašifrování některých informací I při užití
soukromého klíče uživatele X,
„xx“ hexadecimální hodnota,
|| operátor řetězení.
2. KRYPTOGRAFICKÉ SYSTÉMY A ALGORITMY
2.1. Kryptografické systémy
CSM_001 VU a karty tachografu musí používat klasický kryptografický
systém RSA veřejného klíče k tomu, aby vytvořily tyto
bezpečnostní mechanismy:
— ověřování pravosti mezi VU a kartami,
— převod trojitých DES klíčů relací mezi VU a kartami
tachografu,
— digitální podpis dat stažených z VU nebo karet tachografu
do externích médií.
CSM_002 VU a karty tachografu musí užívat trojitý DES symetrický
kryptografický systém k tomu, aby v průběhu výměny dat
uživatele mezi VU a kartami tachografu vytvořily mecha­
nismus pro udržení integrity dat a aby v příslušných přípa­
dech zajistily důvěrnost výměny dat mezi VU a kartami
tachografu.
2.2. Kryptografické algoritmy
2.2.1 Algoritmus RSA
CSM_003 Algoritmus RSA je plně definován těmito rovnicemi:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 430
X.SK[m] = s = m d mod n
X.PK[s] = m = s e mod n
Obsažnější popis funkce RSA lze nalézt v odkazu [PKCS1].
Veřejný exponent e pro výpočet RSA je celé číslo mezi 3 a n-
1 splňující podmínku gcd(e, lcm(p-1, q-1))=1.
2.2.2 Hašovací algoritmus
CSM_004 Mechanismus digitálního podpisu musí užívat hašovací algo­
ritmus SHA-1 podle definice v odkazu [SHA-1].
2.2.3 Algoritmus šifrování dat
CSM_005 Algoritmus, založený na DES musí být užit v provozním
režimu „Cipher Block Chaining“.
3. KLÍČE A CERTIFIKÁTY
3.1. Generování a distribuce klíčů
3.1.1 Generování a distribuce klíčů RSA
CSM_006 Klíče RSA musí být generovány prostřednictvím tří funkčních
hierarchických úrovní:
— evropské úrovně,
— úrovně členských států,
— úrovně zařízení.
CSM_007 Na evropské úrovni musí být generován jediný pár evrop­
ských klíčů (EUR.SK a EUR.PK). K certifikaci veřejných
klíčů členských států musí být používán evropský soukromý
klíč. Musí být udržovány záznamy o všech certifikovaných
klíčích. Tyto úkoly musí zajišťovat Evropský certifikační úřad
pod pravomocí a odpovědností Evropské komise.
CSM_008 Na úrovni členského státu musí být generován pár klíčů člen­
ského státu (MS.SK a MS.PK). Veřejné klíče členských států
musí být certifikovány Evropským certifikačním úřadem.
Soukromý klíč členského státu se musí užívat k certifikaci
veřejných klíčů, které se mají vkládat do zařízení (VU nebo
karty tachografu). Musí být udržovány záznamy o všech certi­
fikovaných veřejných klíčích spolu s identifikací zařízení, pro
která jsou určeny. Tyto úkoly musí zajišťovat certifikační
autorita členského státu. Členský stát může pravidelně svůj
pár klíčů měnit.
CSM_009 Na úrovni zařízení musí být generován pár klíčů (EQT.SK
a EQT.PK) a musí být vložen do každého zařízení. Veřejné
klíče zařízení musí být certifikovány certifikační autoritou
členského státu. Tyto úkoly mohou být zajišťovány výrobci
zařízení, personalizátory zařízení nebo orgány členského státu.
Tento pár klíčů se užívá pro ověřování pravosti, digitální
podpis a šifrovací služby.
CSM_010 Během generování, dopravy (v příslušných případech) a skla­
dování musí být zachována důvěrnost soukromých klíčů.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 431
Toto vyobrazení shrnuje tok dat v tomto procesu:
3.1.2 Zkušební klíče RSA
CSM_011 Pro zkoušení zařízení (včetně zkoušek interoperability) musí
Evropský certifikační úřad generovat odlišný jediný evropský
pár zkušebních klíčů a nejméně dva páry zkušebních klíčů
členských států, jejichž veřejné klíče musí být certifikovány
soukromým evropským zkušebním klíčem. Výrobci musí do
zařízení, které je podrobeno zkouškám schválení typu, vložit
zkušební klíče certifikované jedním z těchto zkušebních klíčů
členského státu.
3.1.3 Klíče snímače pohybu
Důvěrnost níže uvedených tří klíčů TDES musí být náležitě zachována
v průběhu generování, dopravy (v příslušných případech) a skladování.
Na podporu vyhovění součástí tachografu normě ISO 16844 musí
Evropský certifikační úřad a dále certifikační úřady členských států
kromě toho zajistit následující:
CSM_036 Evropský certifikační úřad musí generovat KmVU a KmWC,
dva nezávislé a jedinečné klíče Triple TDES, a generovat Km
jako: Km = Km VU XOR Km WC . Evropský certifikační úřad
musí tyto klíče za příslušných zabezpečených postupů předat
na vyžádání členských států jejich certifikačním autoritám.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 432
CSM_037 Certifikační autority členských států musí:
— užít Km k šifrování dat snímače pohybu podle požadavku
výrobce snímače pohybu (data, která mají být šifrována
pomocí Km, definuje ISO 16844-3),
— předat Km VU výrobcům VU pro vložení do VU za nále­
žitě zabezpečených postupů,
— zajistit, aby Km WC bylo v průběhu personalizace
karty vloženo do všech karet dílny
( do elementárního
souboru ).
3.1.4 Generování a distribuce klíčů T-DES
CSM_012 VU a karty tachografu musí jako součást postupu vzájemného
ověřování pravosti generovat a vzájemně si vyměňovat data
potřebná pro vypracování společného klíče Triple DES.
Důvěrnost této výměny dat musí být ochráněna šifrovacím
mechanismem RSA.
CSM_013 Tento klíč musí být použit u všech následujících kryptogra­
fických operací za použití zabezpečené komunikace. Jeho
platnost končí ukončením relace (vyjmutím karty nebo rese­
továním karty) a/nebo po 240 použitích (jedno použití klíče =
jeden příkaz s využitím zabezpečené komunikace odeslaný na
kartu a odpovídající odpověď).
3.2. Klíče
CSM_014 Klíče RSA musí mít (na kterékoliv úrovni) následující délku:
modul n 1 024 bitů, veřejný exponent e 64 bitů maximálně,
soukromý exponent d 1 024 bitů.
CSM_015 Klíče Triple DES musí mít tvar (K a , K b , K a ), kde K a a K b
jsou nezávislé klíče dlouhé 64 bitů. Nenastavují se žádné bity
pro detekci závad v paritě.
3.3. Certifikáty
CSM_016 Certifikáty RSA veřejných klíčů musí být certifikáty „non
self-descriptive“ (nepopisné) „card verifiable“ (ověřující
kartu) (viz ISO/IEC 7816-8)
3.3.1 Obsah certifikátů
CSM_017 Certifikáty veřejných klíčů RSA jsou tvořeny těmito daty
v následujícím pořadí:
Data Formát Bajtů Popis
CPI INTEGER
(celé číslo)
1 Identifikátor profilu certifi­
kátu (pro tuto verzi „01“)
CAR OCTET
STRING
8 Odkaz na certifikační auto­
ritu
CHA OCTET
STRING
7 Autorizace držitele certifi­
kátu
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 433
Data Formát Bajtů Popis
EOV TimeReal 4 Konec platnosti certifikátu.
Volitelné, doplněno
pomocí „FF“ pokud se
nepoužije.
CHR OCTET
STRING
8 Odkaz na držitele certifi­
kátu
n OCTET
STRING
128 Veřejný klíč (modul)
e OCTET
STRING
8 Veřejný klíč (veřejný
exponent)
164
Poznámky:
1. „Identifikátor profilu certifikátu“ (CPI) stanovuje přesnou strukturu
certifikátu ověření pravosti. Může být užit jako interní identifikátor
zařízení pro odpovídající návěští, které popisuje řetězení prvků dat
v certifikátu.
Návěští spojené s obsahem tohoto certifikátu je následující:
„4D“ „16“ „5F
29“
„01“ „42“ „08“ „5F
4B“
„07“ „5F
24“
„04“ „5F
20“
„08“ „7F
49“
„05“ „81“ „81
80“
„82“ „08“
Ta
g
ro
zš
íř
en
éh
o
ná
vě
št
í
D
él
ka
n
áv
ěš
tí
Ta
g
C
P
I
D
él
ka
C
P
I
Ta
g
C
A
R

D
él
ka
C
A
R

Ta
g
C
H
A

D
él
ka
C
H
A

Ta
g
E
O
V

D
él
ka
E
O
V

Ta
g
C
H
R

D
él
ka
C
H
R

Ta
g
ve
ře
jn
éh
o
kl
íč
e
(s
es
ta
ve
né
ho
)
D
él
ka
n
ás
le
du
jí
cí
ch
D
O

Ta
g
m
od
ul
u
D
él
ka
m
od
ul
u
Ta
g
ve
ře
jn
éh
o
ex
po
ne
nt
u
D
él
ka
v
eř
ej
né
ho
e
xp
on
en
tu

2. „Odkaz na certifikační autoritu“ (CAR) má za účel identifikovat auto­
ritu vydávající certifikát (CA) tak, aby prvek dat mohl být použit
současně jako identifikátor klíče autority pro odkaz na veřejný klíč
certifikační autority (pro kódování viz níže identifikátor klíče).
3. „Autorizace držitele certifikátu“ (CHA) se používá k identifikaci práv
držitele certifikátu. Je tvořena identifikací (ID) použití tachografu
a typem zařízení, ke kterému je certifikát určen (podle prvku dat
, „00“ pro členský stát).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 434
4. „Odkaz na držitele certifikátu“ (CHR) má za účel jednoznačně iden­
tifikovat držitele certifikátu tak, aby mohl být užit prvek dat současně
jako identifikátor klíče subjektu a odkazovat na veřejný klíč držitele
certifikátu.
5. Identifikátory klíčů jednoznačně identifikují držitele certifikátu nebo
certifikační autority. Jsou kódovány takto:
5.1 Zařízení (VU nebo karta):
Data Výrobní
číslo zaří­
zení
Datum Typ Výrobce
Délka 4 bajty 2 bajty 1 bajt 1 bajt
Hodnota Integer
(celé
číslo)
Kódování BCD mm
rr
Specifické podle
výrobce
Kód výrobce
Při požadování certifikátů pro VU výrobce může, nebo nemusí
znát identifikaci zařízení, do kterého budou klíče vloženy.
V prvém případě zašle výrobce identifikaci zařízení s veřejným
klíčem autoritě svého členského státu k certifikaci. Certifikát bude
v takovém případě zahrnovat identifikaci zařízení a výrobce musí
zajistit, aby klíče a certifikáty byly vloženy do uvažovaného zaří­
zení. Identifikátor klíče má tvar uvedený výše.
Ve druhém případě musí výrobce jednoznačně identifikovat
každý požadavek na certifikát a zaslat tuto identifikaci s veřejným
klíčem autoritě svého členského státu k certifikaci. Certifikát bude
obsahovat identifikaci požadavku. Výrobce musí po instalaci klíče
do zařízení sdělit orgánu svého členského státu přiřazení klíče
k zařízení (tj. identifikaci požadavku na certifikát, identifikaci
zařízení). Identifikátor klíče má následující tvar:
Data Pořadové
číslo
požadavku
na certi­
fikát
Datum Typ Výrobce
Délka 4 bajty 2 bajty 1 bajt 1 bajt
Hodnota Integer
(celé
číslo)
Kódování BCD mm
rr
„FF“ Kód výrobce
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 435
5.2 Certifikační autorita:
Data Identifikace
orgánu
Pořadové
číslo klíče
Přídavné
informace
Identifikátor
Délka 4 bajty 1 bajt 2 bajty 1 bajt
Hodnota 1 bajt číselný kód
státu
3 bajty alfanume­
rický kód státu
Integer (celé
číslo)
Doplňující
kódování
(specifické
pro CA)
„FF FF“,
pokud se
nevyužije
„01“
Pořadové číslo klíče se užívá pro rozlišení různých klíčů člen­
ského státu v případě, kdy je klíč měněn.
6. Ověřovatel certifikátu musí bezpodmínečně vědět, že veřejný certifi­
kovaný klíč je RSA klíč platný pro ověřování pravosti, ověřování
digitálního podpisu a šifrování pro důvěrnost služeb (certifikát neza­
hrnuje žádný identifikátor objektu, který jej specifikuje).
3.3.2 Vydané certifikáty
CSM_018 Vydaný certifikát je digitálním podpisem s částečnou
obnovou obsahu certifikátu podle ISO/IEC 9796-2 (s
výjimkou přílohy A4), s připojeným „Certification Authority
Reference“ (Odkaz na certifikační autoritu).
X.C = X.CA.SK[„6A“ || C r || Hash (Cc) || „BC“] || C n || X.CAR
Kde je obsah certifi­
kátu = Cc =
C r || C n
106 bajtů 58 bajtů
Poznámky:
1. Tento certifikát je dlouhý 194 bajtů.
2. K podpisu je dále připojen podpisem překrytý odkaz na certifikační
autoritu (CAR) tak, že veřejný klíč certifikačního orgánu může být
vybrán pro ověření certifikátu.
3. Ověřovatel certifikátu musí bezpodmínečně znát algoritmus užívaný
certifikační autoritou k podepisování certifikátu.
4. Návěští spojené s vydaným certifikátem je následující:
„7F 21“ „09“ „5F 37“ „81 80“ „5F 38“ „3A“ „42“ „08“
Ta
g
ce
rt
if
ik
át
u
C
V

(s
es
ta
ve
né
ho
)
D
él
ka
n
ás
le
du
jí
cí
ch
D
O

Ta
g
po
dp
is
u
D
él
ka
p
od
pi
su

Ta
g
zb
yt
ku

D
él
ka
z
by
tk
u
Ta
g
C
A
R

D
él
ka
C
A
R

▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 436
3.3.3 Ověření a rozbalení certifikátu
Ověření a rozbalení certifikátů zahrnuje ověření podpisu podle ISO/IEC
9796-2, vyhledání obsahu certifikátu a obsaženého veřejného klíče: X.PK
= X.CA.PK o X.C, a ověření platnosti certifikátu.
CSM_019 Zahrnuje následující kroky:
Ověřte podpis a vyvolejte obsah:
— z X.C vyvolejte Sign, C n ' a CAR': X.C = Sign || C n ' || CAR'
128 bajtů 58 bajtů 8 bajtů
— z CAR' vyberte příslušný veřejný klíč certifikační autority
(pokud již nebyl vybrán dříve jinými prostředky),
— otevřete Sign pomocí veřejného klíče CA: Sr'= X.CA.PK
[Sign],
— ověření Sr'začíná na „6A“a končí na „BC“,
— vypočítejte C r ' a H'ze vztahu: Sr' = „6A“ || C r ' || H' || „BC“
106 bajtů 20 bajtů
— obnovte obsah certifikátu C' = C r ' || C n ',
— ověřte Hash (C') = H'
Pokud jsou ověření v pořádku, je certifikát pravý a jeho
obsahem je C'.
Ověřte platnost. Z C':
— v příslušných případech ověřte datum ukončení platnosti.
Z C' vyvolejte a uložte veřejný klíč, identifikátor klíče, auto­
rizaci držitele certifikátu a konec platnosti certifikátu:
— X.PK = n || e
— X.KID = CHR
— X.CHA = CHA
— X.EOV = EOV
4. MECHANISMUS VZÁJEMNÉHO OVĚŘOVÁNÍ PRAVOSTI
Vzájemné ověřování pravosti mezi kartami a VU je založeno na násle­
dujícím principu:
Každá strana musí druhé straně prokázat, že vlastní platný pár klíčů,
z něhož veřejný klíč byl certifikován certifikační autoritou členského
státu, která sama byla certifikována Evropským certifikačním úřadem.
Prokazuje se podpisem se soukromým klíčem na náhodně vybraném čísle
zaslaném druhou stranou, která musí zaslané náhodné číslo při ověřování
tohoto podpisu získat zpět.
Mechanismus se aktivuje vložením karty do VU. Mechanismus začíná
výměnou certifikátů a rozbalením veřejných klíčů a končí nastavením
klíče relace.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 437
CSM_020 Musí být použit tento protokol (šipky označují příkazy
a výměnu dat (viz dodatek 2)):
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 438
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 439
5. DŮVĚRNOST PŘENOSU DAT KARET VU, INTEGRITA A MECHA­
NISMUS OVĚŘOVÁNÍ PRAVOSTI
5.1. Bezpečné předávání zpráv
CSM_021 Integrita přenosu dat VU karet musí být chráněna prostřednic­
tvím bezpečného předávání zpráv s odkazem na normy
[ISO/IEC 7816-4] a [ISO/IEC 7816-8].
CSM_022 Pokud je třeba data v průběhu přenosu chránit, musí se
k datovým objektům zasílaným v příkazech nebo odpovědích
připojit datový objekt kryptografický kontrolní součet (Cryp­
tographic Checksum). Kryptografický kontrolní součet je
kontrolován příjemcem.
CSM_023 Kryptografický kontrolní součet zaslaný v rámci příkazu musí
zahrnovat záhlaví příkazu a veškeré odeslané datové objekty
(=>CLA = „0C“ a veškeré datové objekty musí být uzavřeny
tagy, ve kterých b1=1).
CSM_024 Pokud odpověď neobsahuje datové pole, musí být stavové
informační bajty ochráněny kryptografickým kontrolním
součtem.
CSM_025 Kryptografický kontrolní součet musí být dlouhý čtyři bajty.
Struktura příkazů a odpovědí při použití bezpečného před­
ávání zpráv je proto následující:
Užité objekty DO jsou částečné soubory bezpečného před­
ávání zpráv datových objektů podle popisu v ISO/IEC
7816-4:
Tag Symbol Význam
„81“ T PV Otevřená hodnota, nikoliv kódovaná data BER-TLV
(chráněno pomocí CC)
„97“ T LE Hodnota Le v nechráněném příkazu (chráněno
pomocí CC)
„99“ T SW Status-Info (chráněno pomocí CC)
„8E“ T CC Kryptografický kontrolní součet
„87“ T PI CG Bajtový indikátor naplnění || Kryptogram (otevřená
hodnota nekódovaná v BER-TLV)
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 440
Z nechráněného páru odpovědi na příkaz vychází:
Záhlaví příkazu Tělo příkazu
CLA INS P1 P2 [L c field] [Data field] [L e field]
čtyři bajty L bajty, označené jako B 1 až B L
Tělo odpovědi Konec odpovědi
[Data field] SW1 SW2
L r datové bajty dva bajty
Odpovídající pár zabezpečené odpovědi na příkaz:
Zabezpečený příkaz:
Záhlaví příkazu (CH) Tělo příkazu
CLA INS P1 P2 [New L c field] [New Data field] [New L e
field]
„OC“ Délka New Data
field
T PV L PV PV T LE L LE L e T CC L CC CC „00“
„81“ L c Datové pole „97“ „01“ L e „8E“ „04“ CC
Data, která mají být zahrnuta do kontrolního součtu = CH ||
PB || T PV || L PV || PV || T LE || L LE || L e || PB
PB = doplňkové bajty (80 .. 00) podle ISO-IEC 7816-4 a ISO
9797 metoda 2.
PV a LE z objektů DO jsou přítomny pouze tehdy, pokud
jsou odpovídající data umístěna v nezabezpečeném příkazu.
Zabezpečená odpověď:
1. Případ, kdy datové pole odpovědi není prázdné a nepotře­
buje být chráněno na důvěrnost:
Tělo odpovědi Konec odpovědi
[New Data field] Nové SW1 SW2
T PV L PV PV T CC L CC CC
„81“ L r Datové pole „8E“ „04“ CC
Data, která mají být zahrnuta do kontrolního součtu = T PV
|| L PV || PV || PB
2. Případ, kdy datové pole odpovědi není prázdné a potřebuje
být chráněno na důvěrnost:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 441
Tělo odpovědi Konec odpovědi
[New Data field] Nové SW1 SW2
T PI CG L PI
CG
PI CG T CC L CC CC
„87“ PI || CG „8E“ „04“ CC
Data v CG: nekódovaná data BER-TLV a bajty doplnění.
Data, která mají být zahrnuta do kontrolního součtu = T PI
CG || L PI CG || PI CG || PB
3. Případ, kdy je datové pole odpovědi prázdné:
Tělo odpovědi Konec odpovědi
[New Data field] nové SW1 SW2
T SW L SW SW T CC L CC CC
„99“ „02“ Nové SW1 SW2 „8E“ „04“ CC
Data, která mají být zahrnuta do kontrolního součtu = T SW
|| L SW || SW || PB
5.2. Zacházení s chybami v bezpečném předávání zpráv (SM)
CSM_026 Když karta tachografu při interpretaci příkazu zjistí chybu
SM, pak se bajty statusu musí vrátit bez SM. Podle ISO/IEC
7816-4 jsou pro indikaci chyb SM definovány následující
bajty statusu:
„66 88“ selhalo ověření kryptografického kontrolního
součtu,
„69 87“ chybí očekávané datové objekty SM,
„69 88“ datové objekty SM nesprávné.
CSM_027 Pokud karta tachografu vrátí bajty statusu bez SM DO nebo
s chybným SM DO, musí VU relaci přerušit.
5.3. Algoritmus výpočtu kryptografického kontrolního součtu
CSM_028 Kryptografické kontrolní součty jsou tvořeny užitím obvy­
klého MAC podle ANSI X.9.19 s DES:
— Výchozí stav: výchozím zkušebním blokem y0 je E(Ka,
SSC).
— Následující krok: Kontrolní bloky y1, .., yn se vypočtou
pomocí Ka.
— Konečný krok: kryptografický kontrolní součet se vypočte
z posledního zkušebního bloku yn takto: E(Ka, D(Kb,
yn)).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 442
kde E() znamená šifrování s DES a D() znamená rozšifrování
s DES.
Přenášejí se čtyři nejvýznamnější bajty kryptografického
kontrolního součtu.
CSM_029 V průběhu odsouhlasení klíče se „čítač odeslané
posloupnosti“ (SSC) inicializuje takto:
Výchozí SSC: Rnd3 (4 nejméně významné bajty) || Rnd1 (4
nejméně významné bajty).
CSM_030 Na čítači odeslané posloupnosti se hodnota zvýší o 1 před
každým výpočtem MAC (tj. SSC pro první příkaz je výchozí
SSC + 1, SSC pro prvou odpověď je výchozí SSC + 2).
Následující vyobrazení uvádí výpočet retail MAC:
5.4. Algoritmus výpočtu šifer pro důvěrnost objektů DO
CSM_031 Kryptogramy se vypočtou pomocí TDEA v režimu TCBC
podle odkazů [TDES] a [TDES-OP] spolu s nulovým
vektorem jako výchozí blok hodnot.
Toto vyobrazení uvádí využití klíčů v TDES:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 443
6. MECHANISMY DIGITÁLNÍCH PODPISŮ PŘI STAHOVÁNÍ DAT
CSM_032 Inteligentní vyhrazené zařízení (IDE) ukládá data ze zařízení
(VU nebo karty) v průběhu relace stahování do jednoho
fyzického souboru dat. Tento soubor musí zahrnovat certifi­
káty MS i .C a EQT.C. Soubor obsahuje digitální podpisy dato­
vých bloků podle specifikace doplňku 7 – Protokoly staho­
vání dat.
CSM_033 Digitální podpisy stažených dat musí užívat schéma digitál­
ního podpisu s dodatkem tak, aby stažená data mohla být
v případě požadavku čtena bez jakéhokoliv dešifrování.
6.1. Generování podpisu
CSM_034 Generování dat podpisu zařízením probíhá podle schématu
podpisu s dodatkem definovaného v odkazu [PKCS1] s hašo­
vací funkcí SHA-1:
Podpis = EQT.SK[„00“ || „01“ || PS || „00“ || DER(SHA-
1(Data))]
PS = doplňkový řetězec oktetů s hodnotou „FF“ takový, aby
délka byla 128.
DER(SHA-1(M)) je kódováním algoritmu ID pro hašovací
funkci a hodnotou hash do hodnoty ASN.1 typu DigestInfo
(zvláštní kódovací pravidla):
„30“||„21“||„30“||„09“||„06“||„05“||„2B“||„0E“||„03“||„02“||„1A“||
„05“||„00“||„04“||„14“||hodnota Hash.
6.2. Ověření podpisu
CSM_035 Ověření dat podpisu stažených dat probíhá podle schématu
podpisu s dodatkem definovaného v odkazu [PKCS1] s hašo­
vací funkcí SHA-1.
Evropský klíč EUR.PK musí být ověřujícímu znám z nezá­
vislé (a důvěryhodné) strany.
Následující tabulka zobrazuje protokol, podle kterého může
IDE s kontrolní kartou ověřit integritu stažených dat ulože­
ných na externí paměťové médium (ESM). Pro dešifrování
digitálních podpisů se užije kontrolní karta. Tato funkce
nemá být v tomto případě zahrnuta do IDE.
Zařízení, které data, jež se mají analyzovat, stáhlo a pode­
psalo, se označí jako EQT.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 444
ČÁST B
SYSTÉM TACHOGRAFU DRUHÉ GENERACE
7. ÚVOD
7.1. Zdroje
V této části dodatku jsou užívány následující odkazy.
AES National Institute of Standards and Technology (NIST),
FIPS PUB 197: Advanced Encryption Standard (AES),
listopad 26, 2001
DSS National Institute of Standards and Technology (NIST),
FIPS PUB 186-4: Digital Signature Standard (DSS),
červenec 2013
ISO 7816-4 ISO/IEC 7816-4, Identification cards – Integrated circuit
cards – Part 4: Organization, security and commands for
interchange. Third edition 2013-04-15
ISO 7816-8 ISO/IEC 7816-8, Identification cards – Integrated circuit
cards – Part 8: Commands for security operations. Second
edition 2004-06-01
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 445
ISO 8825-1 ISO/IEC 8825-1, Information technology – ASN.1 enco­
ding rules: Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER). Fourth edition, 2008-12-15
ISO 9797-1 ISO/IEC 9797-1, Information technology – Security tech­
niques – Message Authentication Codes (MACs) – Part 1:
Mechanisms using a block cipher. Second edition, 2011-
03-01
ISO 10116 ISO/IEC 10116, Information technology – Security tech­
niques – Modes of operation of an n-bit block cipher.
Third edition, 2006-02-01
ISO 16844-3 ISO/IEC 16844-3, Road vehicles – Tachograph systems –
Part 3: Motion sensor interface. First edition 2004, inclu­
ding Technical Corrigendum 1 2006
RFC 5480 Elliptic Curve Cryptography Subject Public Key Informa­
tion, March 2009
RFC 5639 Elliptic Curve Cryptography (ECC) – Brainpool Standard
Curves and Curve Generation, 2010
RFC 5869 HMAC-based Extract-and-Expand Key Derivation
Function (HKDF), May 2010
SHS National Institute of Standards and Technology (NIST),
FIPS PUB 180-4: Secure Hash Standard, March 2012
SP 800-38B National Institute of Standards and Technology (NIST),
Special Publication 800-38B: Recommendation for Block
Cipher Modes of Operation: The CMAC Mode for
Authentication, 2005
TR-03111 BSI Technical Guideline TR-03111, Elliptic Curve Cryp­
tography, version 2.00, 2012-06-28
7.2. Značení a zkratky
V tomto dodatku jsou užity následující značení a zkratky:
AES pokročilý standard pro šifrování
CA certifikační orgán
CAR Odkaz na certifikační orgán
CBC řetězení šifrového textu (operační mód)
CH hlavička příkazu
CHA Autorizace držitele certifikátu
CHR Odkaz na držitele certifikátu
CV konstantní vektor
DER zvláštní kódovací pravidla
DO datový objekt
DSRC vyhrazená komunikace krátkého dosahu
ECC kryptografie na bázi eliptických křivek
ECDSA algoritmus digitálního podpisu na bázi eliptických křivek
ECDH Diffie-Hellmanova eliptická křivka (algoritmus odsouhla­
sení klíče)
EGF vnější zařízení GNSS
EQT Zařízení
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 446
IDE inteligentní vyhrazené zařízení
K M hlavní klíč snímače pohybu, umožňující párování VU se
snímačem pohybu
K M-VU klíč vložený do VU, umožňující VU odvodit hlavní klíč
snímače pohybu při vložení karty dílny do VU
K M-WC klíč vložený do karet dílny, umožňující VU odvodit hlavní
klíč snímače pohybu při vložení karty dílny do VU
MAC kód ověřování zprávy
MoS snímač pohybu
MSB nejdůležitější bit
PKI infrastruktura veřejného klíče
RCF zařízení vzdálené komunikace
SSC čítač odeslané posloupnosti
SM Bezpečné předávání zpráv
TDES trojitý standard šifrování dat
TLV hodnota délky tagu
VU celek ve vozidle
X.C certifikát veřejného klíče uživatele X
X.CA certifikační orgán, který vydal certifikát uživatele X
X.CAR odkaz na certifikační orgán uvedený v certifikátu uživatele
X
X.CHR odkaz na držitele certifikátu uvedený v certifikátu uživatele
X
X.PK veřejný klíč uživatele X
X.SK soukromý klíč uživatele X
X.PK eph přechodný veřejný klíč uživatele X
X.SK eph přechodný soukromý klíč uživatele X
„xx“ hexadecimální hodnota
|| operátor řetězení
7.3. Definice
Definice termínů používaných v tomto dodatku jsou uvedeny v části
I přílohy 1C.
8. KRYPTOGRAFICKÉ SYSTÉMY A ALGORITMY
8.1. Kryptografické systémy
CSM_38 VU a karty tachografu musí užívat systém šifrování veřej­
ného klíče na bázi eliptických křivek k tomu, aby zajistily
následující bezpečnostní služby:
— vzájemné ověřování pravosti mezi VU a kartou,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 447
— odsouhlasení klíčů relace AES mezi VU a kartou,
— zajištění pravosti, integrity a nepopiratelnosti dat staho­
vaných z VU nebo karet tachografu na externí média.
CSM_39 VU a vnější zařízení GNSS musí užívat kryptografický
systém veřejného klíče na bázi eliptických křivek
k tomu, aby zajistily následující bezpečnostní služby:
— vazbu VU a vnějšího zařízení GNSS,
— vzájemné ověřování pravosti mezi VU a vnějším zaří­
zením GNSS,
— odsouhlasení klíčů relace AES mezi VU a vnějším
zařízením GNSS.
CSM_40 VU a karty tachografu musí užívat symetrický kryptogra­
fický systém na bázi AES k tomu, aby zajistily následující
bezpečnostní služby:
— zajištění pravosti a integrity dat vyměňovaných mezi
VU a kartou tachografu,
— v příslušných případech zajištění důvěrnosti dat vymě­
ňovaných mezi VU a kartou tachografu.
CSM_41 VU a vnější zařízení GNSS musí užívat symetrický kryp­
tografický systém na bázi AES k tomu, aby zajistily násle­
dující bezpečnostní služby:
— zajištění pravosti a integrity dat vyměňovaných mezi
VU a vnějším zařízením GNSS.
CSM_42 VU a snímače pohybu musí užívat symetrický kryptogra­
fický systém na bázi AES k tomu, aby zajistily následující
bezpečnostní služby:
— párování VU a snímače pohybu,
— vzájemné ověřování pravosti mezi VU a snímačem
pohybu,
— zajištění důvěrnosti dat vyměňovaných mezi VU
a snímačem pohybu.
CSM_43 VU a kontrolní karty musí užívat symetrický kryptogra­
fický systém na bázi AES k tomu, aby zajistily následující
bezpečnostní služby na rozhraní vzdálené komunikace:
— zajištění důvěrnosti, pravosti a integrity dat předáva­
ných z VU do kontrolní karty.
Poznámky:
— Data jsou v praxi předávána z VU na vzdálené dota­
zovací zařízení pod dohledem kontrolního úředníka
pomocí zařízení vzdálené komunikace, které může
být vnitřní nebo vnější jednotkou vůči VU, viz dodatek
14. Vzdálené dotazovací zařízení však odesílá přijatá
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 448
data na kontrolní kartu pro dekódování a validaci
pravosti. Z bezpečnostního hlediska jsou zařízení vzdá­
lené komunikace a vzdálené dotazovací zařízení zcela
transparentní.
— Karta dílny poskytuje stejné bezpečnostní služby pro
rozhraní DSRC jako kontrolní karta. To dílně
umožňuje validovat správnou funkci rozhraní vzdálené
komunikace VU, včetně zabezpečení. Další informace
jsou uvedeny v části 9.2.2.
8.2. Kryptografické algoritmy
8.2.1 Symetrické algoritmy
CSM_44 VU, karty tachografu, snímače pohybu a vnější zařízení
GNSS musí podporovat algoritmy AES podle definice
v [AES], s délkami klíčů 128, 192 a 256 bitů.
8.2.2 Asymetrické algoritmy a standardní parametry domény
CSM_45 VU, karty tachografu a vnější zařízení GNSS musí podpo­
rovat kryptografii na bázi eliptických křivek s velikostí
klíče 256, 384 a 512/521 bitů.
CSM_46 VU, karty tachografu a vnější zařízení GNSS musí podpo­
rovat podpisový algoritmus ECDSA podle ustanovení
[DSS].
CSM_47 VU, karty tachografu a vnější zařízení GNSS musí podpo­
rovat algoritmus odsouhlasení klíčů ECKA-EG podle usta­
novení [TR 03111].
CSM_48 VU, karty tachografu a vnější zařízení GNSS musí podpo­
rovat všechny standardní parametry domén stanovené
v Tabulka 1 níže pro kryptografii na bázi eliptických
křivek.
Tabulka 1
Standardní parametry domén
Název Velikost (bity) Odkaz Identifikátor objektu
NIST P-256 256 [DSS], [RFC 5480]
BrainpoolP256r1 256 [RFC 5639]
NIST P-384 384 [DSS], [RFC 5480]
BrainpoolP384r1 384 [RFC 5639]
BrainpoolP512r1 512 [RFC 5639]
NIST P-521 521 [DSS], [RFC 5480]
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 449
Poznámka: Identifikátory objektu uvedené v posledním
sloupci Tabulka 1 jsou stanoveny v [RFC 5639] pro
křivky Brainpool a v [RFC 5480] pro křivky NIST.
8.2.3 Hašovací algoritmy
▼M1
CSM_49 Celky ve vozidle, karty tachografu a vnější zařízení GNSS
musí podporovat algoritmy SHA-256, SHA-384 a SHA-
512 stanovené v [SHS].
▼B
8.2.4 Šifrovací soustavy
CSM_50 V případě symetrického algoritmu se asymetrický algo­
ritmus a/nebo hašovací algoritmus používají společně
a vytvářejí bezpečnostní protokol, jejich příslušné délky
klíče a velikosti hash musí mít (zhruba) stejnou sílu.
Tabulka 2 zobrazuje schválené sady šifer:
Tabulka 2
Povolené sady šifer
ID sady šifer
Velikost klíče ECC
(bity)
Délka klíče AES (bity)
Hašovací algo­
ritmus
Délka MAC
(bajty)
CS#1 256 128 SHA-256 8
CS#2 384 192 SHA-384 12
CS#3 512/521 256 SHA-512 16
Poznámka: Velkosti klíče ECC 512 bitů a 521 bitů jsou
považovány, že jsou stejné síly pro všechny účely v rámci
tohoto dodatku.
9. KLÍČE A CERTIFIKÁTY
9.1. Asymetrické páry klíčů a certifikáty veřejných klíčů
9.1.1 Obecné informace
Poznámka: Klíče popisované v této části jsou používány pro vzájemné
ověřování pravosti a bezpečné předávání zpráv mezi VU a kartami tacho­
grafu a mezi VU a vnějšími zařízeními GNSS. Tyto procesy jsou
podrobně popsány v kapitolách 10 a 11 tohoto dodatku.
CSM_51 V rámci systému evropského inteligentního tachografu
musí být páry klíčů ECC a příslušné certifikáty genero­
vány a spravovány prostřednictvím tří funkčních hierar­
chických úrovní:
— evropské úrovně,
— úrovně členských států,
— úrovně zařízení.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 450
CSM_52 V rámci systému evropského inteligentního tachografu
musí být veřejné i soukromé klíče a certifikáty genero­
vány, spravovány a předávány pomocí standardních
a bezpečných metod.
9.1.2 Evropská úroveň
CSM_53 Na evropské úrovni musí být generován jediný pár evrop­
ských klíčů ECC označený jako EUR. Musí sestávat ze
soukromého klíče (EUR.SK) a veřejného klíče (EUR.PK).
Tento pár klíčů představuje kořenový pár klíčů celé PKI
evropského inteligentního tachografu. Tento úkol musí
zajišťovat Evropský úřad kořenových certifikátů (ERCA)
pod pravomocí a odpovědností Evropské komise.
CSM_54 ERCA musí užívat evropský soukromý klíč k podpisu
(automatickému) kořenového certifikátu evropského veřej­
ného klíče a tento evropský kořenový certifikát sdělovat
všem členským státům.
CSM_55 ERCA musí na požádání užívat evropský soukromý klíč
k podpisu certifikátů veřejných klíčů členských států.
ERCA musí udržovat záznamy o všech podepsaných certi­
fikátech veřejných klíčů členských států.
CSM_56 Podle popisu na Obrázek 1 v části 9.1.7 musí ERCA
generovat nový evropský kořenový pár klíčů každých 17
let. Kdykoli ERCA generuje nový evropský kořenový pár
klíčů, vytvoří nový automaticky podepsaný kořenový certi­
fikát pro nový evropský veřejný klíč. Doba platnosti
evropského kořenového certifikátu je 34 let a 3 měsíce.
Poznámka: Zavedení nového kořenového páru klíčů
rovněž předpokládá, že ERCA generuje nový hlavní klíč
pro snímač pohybu a nový hlavní klíč DSRC, viz části
9.2.1.2 and 9.2.2.2.
CSM_57 Před vygenerováním nového evropského kořenového páru
klíčů musí ERCA provést analýzu kryptografické síly,
která je potřebná pro nový pár klíčů, aby mohl být
bezpečný pro dalších 34 let. V případě potřeby ERCA
přejde na sadu šifer, která je silnější než sada stávající,
podle popisu v CSM_50.
▼M1
CSM_58 Kdykoli ERCA generuje nový evropský kořenový pár
klíčů, vytvoří spojovací certifikát pro nový evropský
veřejný klíč a podepíše jej předchozím evropským
soukromým klíčem. Doba platnosti spojovacího certifikátu
je 17 let plus 3 měsíce. To je také znázorněno na obrázku
1 v bodě 9.1.7.
▼B
Poznámka: Protože spojovací certifikát obsahuje veřejný
klíč ERCA generace X a je podepsán soukromým klíčem
ERCA generace X-1, poskytuje tento spojovací certifikát
zařízení vytvořenému za generace X-1 základ pro důvěru
zařízení vytvořenému za generace X.
CSM_59 ERCA nesmí užívat soukromý klíč kořenového páru klíčů
k jakémukoli účelu od okamžiku vstupu nového kořeno­
vého certifikátu klíče v platnost.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 451
CSM_60 ERCA kdykoli zlikviduje tyto kryptografické klíče a certi­
fikáty:
— Stávající pár klíčů EUR a příslušný certifikát
— Všechny předchozí certifikáty EUR používané pro
ověření dosud platných certifikátů MSCA
— Spojovací certifikáty pro všechny generace certifikátů
EUR s výjimkou prvního
9.1.3 Úroveň členských států
CSM_61 Na úrovni členských států musí všechny členské státy,
které podepisují certifikáty karet tachografu, generovat
jeden nebo více jedinečných párů klíčů ECC označených
jako MSCA_Card. Všechny členské státy, které podepisují
certifikáty pro VU nebo vnější zařízení GNSS, musí navíc
generovat jeden nebo více jedinečných párů klíčů ECC
označených jako MSCA_VU-EGF.
CSM_62 Úkol generování párů klíčů členského státu musí zajišťovat
certifikační orgán členského státu (MSCA). Kdykoli
MSCA generuje pár klíčů členského státu, odešle do
ERCA veřejný klíč, aby obdržel příslušný certifikát člen­
ského státu podepsaný ERCA.
CSM_63 MSCA musí zvolit sílu páru klíčů členského státu odpoví­
dající síle evropského kořenového páru klíčů užívaného
k podpisu příslušného certifikátu členského státu.
CSM_64 Případný pár klíčů MSCA_VU-EGF obsahuje soukromý
klíč MSCA_VU-EGF.SK a veřejný klíč MSCA_VU-
EGF.PK. MSCA musí soukromý klíč MSCA_VU-EGF.SK
užívat výhradně k podpisu certifikátů veřejného klíče VU
a vnějších zařízení GNSS.
CSM_65 Pár klíčů MSCA_Card obsahuje soukromý klíč
MSCA_Card.SK a veřejný klíč MSCA_Card.PK. MSCA
musí soukromý klíč MSCA_Card.SK užívat výhradně
k podpisu certifikátů veřejného klíče karet tachografu.
CSM_66 MSCA musí udržovat záznamy všech podepsaných certifi­
kátů VU, certifikátů vnějších zařízení GNSS a certifikátů
karet společně s identifikací zařízení, pro které je každý
certifikát určen.
CSM_67 Doba platnosti certifikátu MSCA_VU-EGF je 17 let plus 3
měsíce. Doba platnosti certifikátu MSCA_Card je 7 let
plus 1 měsíc.
CSM_68 Jak je patrné z Obrázek 1 v části 9.1.7, soukromý klíč
z páru klíčů MSCA_VU-EGF a soukromý klíč z páru
klíčů MSCA_Card musí být používány po dobu dvou let.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 452
CSM_69 MSCA nesmí soukromý klíč páru klíčů MSCA_VU-EGF
od chvíle, kdy skončí doba jeho použitelnosti, užívat
k žádnému účelu. MSCA nesmí od chvíle, kdy skončí
jeho doba použitelnosti, užívat k žádnému účelu ani
soukromý klíč páru klíčů MSCA_Card.
CSM_70 MSCA musí kdykoli zlikvidovat tyto kryptografické klíče
a certifikáty:
— Stávající pár klíčů MSCA_Card a příslušný certifikát
— Všechny předchozí certifikáty MSCA_Card užívané
pro ověřování dosud platných certifikátů karet tacho­
grafu
— Současný certifikát EUR potřebný pro ověřování stáva­
jícího certifikátu MSCA
— Všechny předchozí certifikáty EUR potřebné pro
ověřování všech dosud platných certifikátů MSCA
CSM_71 Má-li MSCA podepsat certifikáty pro VU nebo vnější zaří­
zení GNSS, musí navíc zlikvidovat tyto klíče a certifikáty:
— Stávající pár klíčů MSCA_VU-EGF a příslušný certi­
fikát
— Všechny předchozí veřejné klíče MSCA_VU-EGF
užívané pro ověřování dosud platných certifikátů VU
nebo vnějších zařízení GNSS
9.1.4 Úroveň zařízení: celky ve vozidle
▼M1
CSM_72 Pro každý VU musí být generovány dva jedinečné páry
klíčů ECC označené jako VU_MA a VU_Sign. Tento
úkol zajišťují výrobci VU. Při každém generování páru
klíčů VU zašle strana generující klíč svému MSCA veřejný
klíč, aby mohla obdržet příslušný certifikát VU podepsaný
MSCA. Soukromý klíč užívá pouze celek ve vozidle.
▼B
CSM_73 Certifikáty VU_MA a VU_Sign příslušného celku ve
vozidle musí mít stejné datum účinnosti.
CSM_74 Výrobce VU musí zvolit sílu páru klíčů VU odpovídající
síle páru klíčů MSCA užívaného k podpisu příslušného
certifikátu VU.
CSM_75 Celek ve vozidle musí užívat svůj pár klíčů VU_MA obsa­
hující soukromý klíč VU_MA.SK a veřejný klíč
VU_MA.PK výhradně pro ověřování pravosti VU vůči
kartám tachografu a vnějším zařízením GNSS podle
pokynů v částech 10.3 a 11.4 tohoto dodatku.
CSM_76 Celek ve vozidle musí být schopen generovat přechodné
páry klíčů ECC a musí užívat přechodný pár klíčů
výhradně pro odsouhlasení klíče relace s kartou tachografu
nebo vnějším zařízením GNSS podle pokynů v částech
10.4 a 11.4 tohoto dodatku.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 453
CSM_77 Celek ve vozidle musí užívat soukromý klíč VU_Sign.SK
svého páru klíčů VU_Sign výhradně k podpisu stahova­
ných souborů dat podle pokynů v kapitole 14 tohoto
dodatku. Příslušný veřejný klíč VU_Sign.PK musí být
užíván výhradně pro ověřování podpisů vytvořených
celkem ve vozidle.
CSM_78 Podle pokynů Obrázek 1 v části 9.1.7 musí být doba plat­
nosti certifikátu VU_MA 15 let a 3 měsíce. Doba platnosti
certifikátu VU_Sign musí být rovněž 15 let a 3 měsíce.
Poznámky:
— Prodloužená doba platnosti certifikátu VU_Sign
umožňuje VU vytvářet platné podpisy stahovaných
dat během prvních tří měsíců po skončení platnosti
podle ustanovení nařízení (EU) č. 581/2010.
— Prodloužená doba platnosti certifikátu VU_MA je
potřebná k tomu, aby VU mohl prokázat pravost
kontrolní karty nebo karty společnosti během prvních
tří měsíců po skončení platnosti, aby bylo možné
stahovat data.
CSM_79 Celek ve vozidle nesmí používat soukromý klíč páru klíčů
VU po skončení platnosti příslušného certifikátu užívat
k žádnému účelu.
CSM_80 Páry klíčů VU (s výjimkou přechodných párů klíčů)
a příslušné certifikáty daného celku ve vozidle nesmí být
vyměňovány nebo obnovovány v terénu poté, co byl celek
ve vozidle uveden do provozu.
Poznámky:
— Přechodné páry klíčů nejsou do tohoto požadavku
zahrnuty, protože nový přechodný pár klíčů je gene­
rován VU při každém ověřování pravosti čipu a odsou­
hlasení klíče relace, viz část 10.4. Přechodné páry klíčů
ostatně nemají příslušné certifikáty.
— Tento požadavek nebrání možnosti výměny statických
párů klíčů VU během renovace nebo opravy
v bezpečném prostředí kontrolovaném výrobcem VU.
CSM_81 Při uvedení do provozu musí celky ve vozidle obsahovat
tyto kryptografické klíče a certifikáty:
— soukromý klíč VU_MA a příslušný certifikát,
— soukromý klíč VU_Sign a příslušný certifikát,
— certifikát MSCA_VU-EGF obsahující veřejný klíč
MSCA_VU-EGF.PK užívaný k ověřování certifikátu
VU_MA a certifikátu VU_Sign,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 454
— certifikát EUR obsahující veřejný klíč EUR.PK použí­
vaný pro ověření certifikátu MSCA_VU-EGF,
— certifikát EUR, jehož doba platnosti přímo předchází
době platnosti certifikátu EUR používaného pro
ověření certifikátu MSCA_VU-EGF, pokud existuje,
— spojovací certifikát spojující tyto dva certifikáty EUR,
pokud existuje.
CSM_82 Kromě kryptografických klíčů a certifikátů uvedených
v CSM_81 musí celky ve vozidle rovněž obsahovat klíče
a certifikáty uvedené v části A tohoto dodatku, které celku
ve vozidle umožňují spolupracovat s kartami tachografu
první generace.
9.1.5 Úroveň zařízení: karty tachografu
▼M1
CSM_83 Pro každou kartu tachografu musí být generován jedinečný
pár klíčů ECC, označený jako Card_MA. Pro každou kartu
řidiče a každou kartu dílny musí být navíc generován
druhý jedinečný pár klíčů ECC, označený jako Card_Sign.
Tento úkol mohou zajišťovat výrobci karet nebo persona­
lizátoři karet. Při každém generování páru klíčů karty zašle
strana generující klíč svému MSCA veřejný klíč, aby
mohla obdržet příslušný certifikát karty podepsaný
MSCA. Soukromý klíč užívá pouze karta tachografu.
▼B
CSM_84 Certifikáty Card_MA a Card_Sign příslušné karty řidiče
nebo karty dílny musí mít stejné datum vstupu v platnost.
CSM_85 Výrobce karet nebo personalizátor karet musí zvolit sílu
páru klíčů karty odpovídající síle páru klíčů MSCA užíva­
ného k podpisu příslušného certifikátu karty.
CSM_86 Karta tachografu musí svůj pár klíčů Card_MA obsahující
soukromý klíč Card_MA.SK a veřejný klíč Card_MA.PK
užívat výhradně pro vzájemné ověřování pravosti a odsou­
hlasení klíče relace vůči celkům ve vozidle podle pokynů
v částech 10.3 a 10.4 tohoto dodatku.
CSM_87 Karta řidiče nebo karta dílny musí soukromý klíč
Card_Sign.SK svého páru klíčů Card_Sign užívat výhradně
k podpisu stahovaných souborů dat podle pokynů v kapi­
tole 14 tohoto dodatku. Příslušný veřejný klíč
Card_Sign.PK se užívá výhradně k ověřování podpisů
vytvářených kartou.
▼M1
CSM_88 Doba platnosti certifikátu Card_MA je následující:
— pro karty řidiče: 5 let
— pro karty podniku: 5 let
— pro kontrolní karty: 2 roky
— pro karty dílny: 1 rok
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 455
CSM_89 Doba platnosti certifikátu Card_Sign je následující:
— pro karty řidiče: 5 let a 1 měsíc,
— pro karty dílny: 1 rok a 1 měsíc.
Poznámka: Prodloužená doba platnosti certifikátu
Card_Sign umožňuje kartě řidiče vytvářet platné podpisy
stahovaných dat během prvního měsíce po skončení plat­
nosti. To je nutné s ohledem na nařízení (EU) č. 581/2010,
které vyžaduje, aby bylo stahování dat z karty řidiče
možné do 28 dnů po zaznamenání posledních dat.
CSM_90 Páry klíčů a příslušné certifikáty dané karty tachografu
nesmí být po vydání karty vyměňovány nebo obnovovány.
CSM_91 Při vydání obsahují karty tachografu tyto kryptografické
klíče a certifikáty:
— soukromý klíč Card_MA a příslušný certifikát,
— pro karty řidiče a karty dílny navíc: soukromý klíč
Card_Sign a příslušný certifikát,
— certifikát MSCA_Card obsahující veřejný klíč
MSCA_Card.PK užívaný k ověřování certifikátu
Card_MA a certifikátu Card_Sign,
— certifikát EUR obsahující veřejný klíč EUR.PK užívaný
k ověřování certifikátu MSCA_Card,
— certifikát EUR, jehož doba platnosti přímo předchází
době platnosti certifikátu EUR užívaného k ověřování
certifikátu MSCA_Card, pokud existuje,
— spojovací certifikát spojující tyto dva certifikáty EUR,
pokud existuje.
▼M1
— dále pouze pro kontrolní karty, karty podniku a karty
dílny a pouze v případě, že takové karty byly vydány
v prvních třech měsících doby platnosti nového certi­
fikátu EUR: certifikát EUR, který je o dvě generace
starší, pokud existuje.
Poznámka k poslední odrážce: Například v prvních
třech měsících platnosti certifikátu ERCA(3) (viz
obrázek 1) musí uvedené karty obsahovat certifikát
ERCA(1). To je nutné k zajištění toho, aby tyto karty
mohly být používány ke stahování dat z celků ve
vozidle ERCA(1), jejichž běžná patnáctiletá životnost
plus tříměsíční období pro stahování dat vyprší během
těchto tří měsíců; viz příloha IC požadavek 13 poslední
odrážka.
▼B
CSM_92 Kromě kryptografických klíčů a certifikátů uvedených
v CSM_91 musí karty tachografu rovněž obsahovat klíče
a certifikáty uvedené v části A tohoto dodatku, které těmto
kartám umožňují spolupracovat s VU první generace.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 456
9.1.6 Úroveň zařízení: vnější zařízení GNSS
▼M1
CSM_93 Pro každé vnější zařízení GNSS musí být generován jedi­
nečný pár klíčů ECC, označený jako EGF_MA. Tento úkol
musí zajišťovat výrobci vnějšího zařízení GNSS. Při
každém generování páru klíčů EGF_MA zašle strana gene­
rující klíč svému MSCA veřejný klíč, aby mohla obdržet
příslušný certifikát EGF_MA podepsaný MSCA.
Soukromý klíč užívá pouze vnější zařízení GNSS.
▼B
CSM_94 Výrobce EGF musí zvolit sílu páru klíčů EGF_MA odpo­
vídající síle páru klíčů MSCA užívaného k podpisu přísluš­
ného certifikátu EGF_MA.
▼M1
CSM_95 Vnější zařízení GNSS musí užívat svůj pár klíčů EGF_MA
obsahující soukromý klíč EGF_MA.SK a veřejný klíč
EGF_MA.PK výhradně pro vzájemné ověřování pravosti
a odsouhlasení klíče relace vůči celkům ve vozidle podle
pokynů v bodě 11.4 tohoto dodatku.
▼B
CSM_96 Doba platnosti certifikátu EGF_MA je 15 let.
CSM_97 Vnější zařízení GNSS nesmí užívat soukromý klíč svého
páru klíčů EGF_MA pro vazbu s celkem ve vozidle po
skončení platnosti příslušného certifikátu.
Poznámka: Podle pokynů v části 11.3.3 může EGF poten­
ciálně užívat svůj soukromý klíč pro vzájemné ověřování
pravosti vůči VU, s nímž je již spárováno, i po skončení
platnosti příslušného certifikátu.
CSM_98 Pár klíčů EGF_MA a příslušný certifikát daného vnějšího
zařízení GNSS nesmí být vyměňovány nebo obnovovány
v terénu poté, co bylo EGF uvedeno do provozu.
Poznámka: Tento požadavek nebrání možnosti výměny
párů klíčů EGF během renovace nebo opravy v bezpečném
prostředí kontrolovaném výrobcem EGF.
CSM_99 Při uvedení do provozu musí vnější zařízení GNSS obsa­
hovat tyto kryptografické klíče a certifikáty:
— soukromý klíč EGF_MA a příslušný certifikát,
— certifikát MSCA_VU-EGF obsahující veřejný klíč
MSCA_VU-EGF.PK používaný pro ověření certifikátu
EGF_MA,
— certifikát EUR obsahující veřejný klíč EUR.PK použí­
vaný pro ověření certifikátu MSCA_VU-EGF,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 457
— certifikát EUR, jehož doba platnosti přímo předchází
době platnosti certifikátu EUR používaného pro
ověření certifikátu MSCA_VU-EGF, pokud existuje,
— spojovací certifikát spojující tyto dva certifikáty EUR,
pokud existuje.
9.1.7 Přehled: výměna certifikátu
Obrázek 1 níže zobrazuje vydávání a užívání různých generací kořeno­
vých certifikátů ERCA, spojovacích certifikátů ERCA, certifikátů MSCA
a certifikátů zařízení (VU a karta):
▼M1
Obrázek 1
Vydávání a používání různých generací kořenových certifikátů ERCA, spojovacích certifikátů ERCA, certifikátů
MSCA a certifikátů zařízení
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 458
Poznámky k Obrázek 1:
1. Různé generace kořenového certifikátu jsou označeny číslem v závor­
kách. Např. ERCA (1) je první generace kořenového certifikátu
ERCA; ERCA (2) je druhá generace atd.
2. Ostatní certifikáty jsou označeny dvěma čísly v závorkách, první
z nich označuje generaci kořenového certifikátu, v níž jsou vydány,
druhé generaci samotného certifikátu. Např. MSCA_Card (1-1) je
první certifikát MSCA_Card vydaný v rámci ERCA (1); MSCA_Card
(2-1) je první certifikát MSCA_Card vydaný v rámci ERCA (2);
MSCA_Card (2-last) je poslední certifikát MSCA_Card vydaný
v rámci ERCA (2); Card_MA(2-1) je první certifikát Card pro
vzájemné ověřování pravosti vydaný v rámci ERCA (2) atd.
3. Certifikáty MSCA_Card (2-1) a MSCA_Card (1-last) jsou vydány
téměř ke stejnému datu, ale nikoli úplně přesně. MSCA_Card (2-1)
je první certifikát MSCA_Card vydaný v rámci ERCA (2) a bude
vydán poněkud později než MSCA_Card (1-last), poslední certifikát
MSCA_Card v rámci ERCA (1).
4. Jak je zobrazeno na obrázku, první certifikát VU a certifikáty karty
vydané v rámci ERCA (2) budou vydány téměř dva roky před
vydáním posledního certifikátu VU a certifikátu karty vydaných
v rámci ERCA (1). Důvodem je skutečnost, že certifikát VU a certi­
fikát karty jsou vydány v rámci certifikátu MSCA, nikoli přímo
v rámci certifikátu ERCA. Certifikát The MSCA (2-1) bude vydán
přímo po vstupu ERCA (2) v platnost, ale certifikát MSCA (1-last)
bude vydán pouze nedlouho před touto dobou, v posledním okam­
žiku, kdy je certifikát ERCA (1) ještě platný. Tyto dva certifikáty
MSCA mají proto téměř stejnou dobu platnosti, ačkoli jsou zástupci
různých generací.
5. Doba platnosti uvedená pro karty je stejná jako pro karty řidiče
(5 let).
▼M1
6. Z důvodu úspory místa je rozdíl doby platnosti mezi certifikáty
Card_MA a Card_Sign uveden pouze pro první generaci.
▼B
9.2. Symetrické klíče
9.2.1 Klíče pro zabezpečení VU – komunikace snímače pohybu
9.2.1.1 Obecné informace
Poznámka: Čtenáři této části by měli být seznámeni s obsahem [ISO
16844-3] popisujícím rozhraní mezi celkem ve vozidle a snímačem
pohybu. Proces párování mezi VU a snímačem pohybu je podrobně
popsán v kapitole 12tohoto dodatku.
CSM_100 Pro párování celků ve vozidle a snímačů pohybu, pro
vzájemné ověřování pravosti mezi celky ve vozidle a snímači
pohybu a pro šifrování komunikace mezi celky ve vozidle
a snímači pohybu je zapotřebí řada symetrických klíčů podle
Tabulka 3. Všechny tyto klíče jsou klíče AES s délkou
odpovídající délce hlavního klíče snímače pohybu, který
musí být spojen s délkou (předpokládaného) evropského
kořenového páru klíčů podle popisu v CSM_50.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 459
Tabulka 3
Klíče pro zabezpečení celku ve vozidle – komunikace snímače pohybu
Klíč Značka Generován Metoda generace Uložen kým
Hlavní klíč snímače
pohybu – část VU
K M-VU ERCA Náhodný výběr ERCA, MSCA účastnící se
vydávání certifikátů VU,
výrobci VU, celky ve vozidle
Hlavní klíč snímače
pohybu – část dílny
K M-WC ERCA Náhodný výběr ERCA, MSCA, výrobci karet,
karty dílny
Hlavní klíč snímače
pohybu
K M Negenerovaný
nezávisle
Vypočtená jako K M =
K M-VU XOR K M-WC
ERCA, MSCA účastnící se
vydávání klíčů snímačů pohybu
(volitelně) (*)
Identifikační klíč K ID Negenerovaný
nezávisle
Vypočtená jako K ID =
K M XOR CV, kde CV
je specifkováno
v CSM_106
ERCA, MSCA účastnící se
vydávání klíčů snímačů pohybu
(volitelně) (*)
Párovací klíč K P Výrobce snímače
pohybu
Náhodný výběr Jeden snímač pohybu
Klíč relace K S VU (během páro­
vání VU a snímače
pohybu)
Náhodný výběr Jeden VU a jeden snímač
pohybu
(*) Uložení K M a K ID je volitelné, protože tyto klíče lze odvodit z K M-VU , K M-WC a CV.
CSM_101 Evropský úřad kořenových certifikátů (ERCA) musí gene­
rovat K M-VU a K M-WC , dva náhodné a jedinečné klíče AES,
z nichž lze vypočítat hlavní klíč snímače pohybu K M jako
K M-VU XOR K M-WC . ERCA musí na požádání sdělit K M,
K M-VU a K M-WC certifikačním orgánům členských států.
CSM_102 ERCA musí každému hlavnímu klíči snímače pohybu K M
přidělit jedinečné číslo verze, které je rovněž použitelné pro
ustavující klíče K M-VU a K M-WC a pro příslušný identifikační
klíč K ID . ERCA musí MSCA sdělit číslo verze při zaslání
K M-VU a K M-WC .
Poznámka: Číslo verze se užívá pro rozlišování různých
generací těchto klíčů, jak je podrobně uvedeno v části
9.2.1.2.
CSM_103 Certifikační orgán členského státu musí K M-VU společně
s jeho číslem verze předat na požádání výrobcům celků ve
vozidle. Výrobci VU musí vložit K M-VU a jeho číslo verze
do všech vyrobených VU.
CSM_104 Certifikační orgán členského státu musí zajistit, aby byl K M-
WC společně s číslem verze vložen do všech karet dílny
vydaných v rámci jeho odpovědnosti.
Poznámky:
— Viz popis datového typu
v dodatku 2.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 460
— Podle vysvětlení v části 9.2.1.2 musí být do jedné karty
dílny prakticky možné vkládat více generací K M-WC .
CSM_105 Kromě klíče AES uvedeného v CSM_104 musí MSCA
zajistit, aby klíč TDES Km WC , stanovený v požadavku
CSM_037 v části A tohoto dodatku byl vložen do každé
karty dílny vydané v rámci jeho odpovědnosti.
Poznámky:
— Tím se umožní užívání karty dílny druhé generace pro
párování s VU první generace.
— Karta dílny druhé generace obsahuje dvě různé aplikace,
z nichž jedna odpovídá části B tohoto dodatku a druhá
odpovídá části A. Ta obsahuje klíč TDES Km WC .
CSM_106 MSCA účastnící se vydávání snímačů pohybu musí odvodit
identifikační klíč z hlavního klíče snímače pohybu pomocí
operace XOR s konstantním vektorem CV. CV má tuto
hodnotu:
▼M1
— Pro 128-bitové hlavní klíče snímače pohybu: CV = ‘B6
44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83’
▼B
— Pro 192-bitové hlavní klíče snímače pohybu: CV = „72
AD EA FA 00 BB F4 EE F4 99 15 70 5B 7E EE BB
1C 54 ED 46 8B 0E F8 25“
— Pro 256-bitové hlavní klíče snímače pohybu: CV = „1D
74 DB F0 34 C7 37 2F 65 55 DE D5 DC D1 9A C3 23
D6 A6 25 64 CD BE 2D 42 0D 85 D2 32 63 AD 60“
Poznámka: Konstantní vektory byly generovány takto:
Pi_10 = prvních 10 bajtů decimální části matematické
konstanty π = „24 3F 6A 88 85 A3 08 D3 13 19“
CV_128-bitů = prvních 16 bajtů SHA-256(Pi_10)
CV_192-bitů = prvních 24 bajtů SHA-384(Pi_10)
CV_256-bitů = prvních 32 bajtů SHA-512(Pi_10)
CSM_107 ►M1 Každý výrobce snímačů pohybu musí generovat
náhodný a jedinečný párovací klíč K P pro každý snímač
pohybu a odeslat každý párovací klíč certifikačnímu orgánu
svého členského státu. MSCA musí každý párovací klíč
samostatně zašifrovat pomocí hlavního klíče snímače
pohybu K M a vrátit zašifrovaný klíč výrobci snímačů
pohybu. Pro každý zašifrovaný klíč musí MSCA oznámit
výrobci snímačů pohybu číslo verze příslušného K M . ◄
Poznámka: Podle pokynů v části 9.2.1.2 musí být výrobce
snímačů pohybu prakticky schopen generovat vícenásobné
jedinečné párovací klíče pro jeden snímač pohybu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 461
CSM_108 Každý výrobce snímačů pohybu musí generovat jedinečné
sériové číslo pro každý snímač pohybu a odeslat všechna
sériová čísla certifikačnímu orgánu svého členského státu.
MSCA musí každé sériové číslo samostatně zašifrovat
pomocí identifikačního klíče K ID a vrátit zašifrované sériové
číslo výrobci snímačů pohybu. Pro každé zašifrované
sériové číslo musí MSCA oznámit výrobci snímačů pohybu
číslo verze příslušného K ID .
▼B
CSM_109 Pro požadavky CSM_107 a CSM_108 musí MSCA užívat
algoritmy AES v operačním režimu řetězení šifrového textu
podle definice v [ISO 10116] s vloženým parametrem m = 1
a inicializačním vektorem SV = „00“ {16}, tj. šestnáct bajtů
s binární hodnotou 0. V případě potřeby musí MSCA užívat
metodu doplnění 2 definovanou v [ISO 9797-1].
CSM_110 Výrobce snímačů pohybu musí uložit zašifrovaný párovací
klíč a zašifrované sériové číslo do určeného snímače pohybu
společně s příslušnými otevřenými textovými hodnotami
a číslem verze K M a K ID užívanými pro šifrování.
Poznámka: Podle pokynů v části 9.2.1.2 musí být výrobce
snímačů pohybu prakticky schopen vkládat vícenásobné
zašifrované párovací klíče a vícenásobná zašifrovaná sériová
čísla do jednoho snímače pohybu.
CSM_111 Kromě kryptografického materiálu na bázi AES uvedeného
v CSM_110 může výrobce snímačů pohybu rovněž do
každého snímače pohybu ukládat kryptografický materiál
na bázi TDES uvedený v požadavku CSM_037 v části
A tohoto dodatku.
Poznámka: Snímači pohybu druhé generace je tak umož­
něno párování s VU první generace.
CSM_112 Délka klíče relace K S generovaného VU během párování se
snímačem pohybu musí být spojena s délkou jeho K M-VU
podle popisu v CSM_50.
9.2.1.2 Výměna hlavního klíče snímače pohybu v zařízení druhé generace
CSM_113 Každý hlavní klíč snímače pohybu a všechny související
klíče (viz Tabulka 3) jsou přiřazeny k určité generaci koře­
nového páru klíčů ERCA. Tyto klíče proto musí být vymě­
něny každých 17 let. Doba platnosti každé generace hlav­
ního klíče snímače pohybu musí začínat jeden rok před
vstupem příslušného kořenového páru klíčů ERCA v platnost
a končit se skončením platnosti příslušného kořenového páru
klíčů ERCA. To je znázorněno na Obrázek 2.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 462
Obrázek 2
Vydávání a užívání různých generací hlavního klíče snímače pohybu v celcích ve vozidle, snímačích pohybu
a kartách dílny
CSM_114 Nejméně jeden rok před generováním nového evropského
kořenového páru klíčů podle popisu v CSM_56 musí
ERCA generovat nový hlavní klíč snímače pohybu K M ge­
nerováním nových klíčů K M-VU a K M-WC . Délka hlavního
klíče snímače pohybu je spojena s předpokládanou délkou
nového evropského kořenového páru klíčů podle CSM_50.
ERCA musí na požádání oznámit MSCA nové klíče K M ,
K M-VU and K M-WC společně s jejich číslem verze.
CSM_115 MSCA musí zajistit uložení všech platných generací K M-WC
do každé karty dílny vydané v rámci jeho pravomoci
společně s jejich čísly verze podle Obrázek 2.
Poznámka: To předpokládá, že v posledním roce doby plat­
nosti certifikátu ERCA budou vydány karty dílny se třemi
různými generacemi K M-WC podle Obrázek 2.
CSM_116 Ve vztahu k procesu popsanému výše v CSM_107
a CSM_108: MSCA musí šifrovat každý párovací klíč K P ,
který obdrží od výrobce snímačů pohybu samostatně
s každou platnou generací hlavního klíče snímače pohybu
K M . MSCA musí rovněž šifrovat každé sériové číslo, které
obdrží od výrobce snímačů pohybu samostatně s každou
platnou generací identifikačního klíče K ID . Výrobce snímačů
pohybu musí uložit veškerá šifrování párovacího klíče
a veškerá šifrování sériového čísla do určeného snímače
pohybu společně s příslušnými otevřenými textovými
hodnotami a číslem (čísly) verze K M a K ID užívanými pro
šifrování.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 463
Poznámka: To předpokládá, že v posledním roce doby plat­
nosti certifikátu ERCA budou vydány snímače pohybu se
šifrovanými daty na základě tří různých generací K M podle
Obrázek 2.
CSM_117 Ve vztahu k procesu popsanému v CSM_107 výše: Protože
délka párovacího klíče K P musí být spojena s délkou K M
(viz CSM_100), musí být výrobce snímačů pohybu schopen
generovat až tři různé párovací klíče (různých délek) pro
jeden snímač pohybu v případě, že následující generace
K M mají různé délky. V takovém případě musí výrobce
zaslat MSCA každý párovací klíč. MSCA musí zajistit,
aby byl každý párovací klíč zašifrován se správnou generací
hlavního klíče snímače pohybu, tj. tím, který má stejnou
délku.
Poznámka: V případě, že se výrobce snímačů pohybu
rozhodne generovat pro snímač pohybu druhé generace
párovací klíč na bázi TDES (viz CSM_111), musí výrobce
MSCA oznámit, že pro šifrování tohoto párovacího klíče je
třeba použít hlavní klíč snímače pohybu na bázi TDES.
Délka klíče TDES může být totiž stejná jako délka klíče
AES, takže MSCA nemůže usuzovat podle samotné délky
klíče.
CSM_118 Výrobce celků ve vozidle musí do každého celku ve vozidle
vložit pouze jednu generaci K M-VU společně s jeho číslem
verze. Tato generace K M-VU musí být spojena s certifikátem
ERCA, na němž jsou založeny certifikáty VU.
Poznámky:
— Celek ve vozidle založený na certifikátu ERCA generace
X musí obsahovat pouze K M-VU generace X, i když je
vydán po začátku doby platnosti certifikátu ERCA gene­
race X+1. To je znázorněno na Obrázek 2.
— VU generace X nemůže být párován se snímačem
pohybu generace X-1.
— Protože karty dílny mají dobu platnosti jednoho roku,
důsledkem CSM_113 – CSM_118 je, že všechny karty
dílny obsahují v okamžiku, kdy je vydán první VU
obsahující nový K M-VU , již nový K M-WC . Tento VU je
proto vždy schopen vypočítat nový K M . Do té doby
bude navíc většina nových snímačů pohybu také obsa­
hovat šifrovaná data na bázi nového K M .
9.2.2 Klíče pro zabezpečení komunikace DSRC
9.2.2.1 Obecné informace
CSM_119 Pravost a důvěrnost dat předávaných z celku ve vozidle
řídicímu orgánu prostřednictvím kanálu vzdálené komuni­
kace DSRC musí být zajištěny pomocí sady klíčů AES
vyhrazených příslušným VU odvozených z jediného hlav­
ního klíče DSRC, totiž KM DSRC .
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 464
CSM_120 Hlavní klíč DSRC KM DSRC musí být klíč AES, který je
bezpečně generován, uložen a distribuován ERCA. Délka
klíče může být 128, 192 nebo 256 bitů a musí být spojena
s délkou evropského kořenového páru klíčů podle popisu
v CSM_50.
CSM_121 ERCA musí certifikačním orgánům členských států na požá­
dání bezpečným způsobem předat hlavní klíč DSRC, aby
mohly odvozovat klíče DSRC vyhrazené příslušným VU
a aby bylo zajištěno, že je hlavní klíč DSRC vložen do
všech kontrolních karet a karet dílny vydaných v rámci
jeho odpovědnosti.
CSM_122 ERCA musí každému hlavnímu klíči DSRC přidělit jedi­
nečné číslo verze. ERCA musí MSCA sdělit číslo verze
při zaslání hlavního klíče DSRC.
Poznámka: Číslo verze je užíváno pro rozlišování různých
generací hlavního klíče DSRC, jak je podrobně vysvětleno
v části 9.2.2.2.
▼M1
CSM_123 Pro každý celek ve vozidle musí výrobce celku ve
vozidle vytvořit jedinečné sériové číslo VU a na
požádání je zaslat certifikačnímu orgánu svého členského
státu, aby mohl získat sadu dvou klíčů DSRC vyhrazených
příslušným VU. Sériové číslo VU musí mít datový typ
.
Poznámka:
— Toto sériové číslo VU se musí shodovat s prvkem vuSe­
rialNumber identifikace VuIdentification, viz dodatek 1,
a s odkazem na držitele certifikátu v certifikátech VU.
— Sériové číslo VU nemusí být v okamžiku, kdy výrobce
celku ve vozidle požádá o klíče DSRC vyhrazené
příslušnému VU, známo. V takovém případě výrobce
VU místo toho zašle jedinečný identifikátor žádosti
o certifikát, který použil v žádosti o certifikáty VU;
viz CSM_153. Tento identifikátor žádosti o certifikát
je tudíž rovnocenný odkazu na držitele certifikátu v certi­
fikátech VU.
▼B
CSM_124 Po přijetí žádosti o vydání klíčů DSRC vyhrazených
příslušným VU musí MSCA odvodit dva klíče AES pro
celek ve vozidle, označené K_VU DSRC _ENC and
K_VU DSRC _MAC. Tyto klíče vyhrazené příslušným VU
musí mít stejnou délku jako hlavní klíč DSRC. MSCA
musí použít funkci odvození klíče definovanou v [RFC
5869]. Hašovací funkce, která je potřebná pro vytvoření
instance funkce HMAC-Hash, musí být spojena s délkou
hlavního klíče DSRC podle popisu v CSM_50. Funkce
odvození klíče v [RFC 5869] se užívá takto:
Krok 1 (extrakce):
— PRK = HMAC-Hash (salt, IKM) kde salt je prázdný
řetězec (empty string) „“ a IKM je KM DSRC .
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 465
Krok 2 (expanze):
— OKM = T(1), kde
T(1) = HMAC-Hash (PRK, T(0) || info || „01“) s
— T(0) = an empty string („“)
— ►M1 info = sériové číslo VU nebo identifikátor
žádosti o certifikát, jež jsou uvedeny v odstavci
CSM_123
— K_VU DSRC _ENC = první L oktety OKM a
K_VU DSRC _MAC = poslední L oktety OKM
kde L je požadovaná délka K_VU DSRC _ENC
a K_VU DSRC _MAC v oktetech.
CSM_125 MSCA musí bezpečným způsobem předat K_VU DSRC _ENC
and K_VU DSRC _MAC výrobci VU k vložení do určeného
celku ve vozidle.
CSM_126 Při vydání musí mít celek ve vozidle ve své zabezpečené
paměti uloženy K_VU DSRC _ENC a K_VU DSRC _MAC, aby
mohl zaručit integritu, pravost a důvěrnost dat zasílaných
prostřednictvím kanálu vzdálené komunikace. Celek ve
vozidle musí mít rovněž uloženo číslo verze hlavního klíče
DSRC používaného pro odvozování těchto klíčů vyhraze­
ných příslušným VU.
CSM_127 Při vydání musí mít kontrolní karty a karty dílny ve své
zabezpečené paměti uloženy KM DSRC , aby mohly zaručit
integritu a pravost dat zasílaných VU prostřednictvím kanálu
vzdálené komunikace a dekódovat tato data. Kontrolní karty
a karty dílny musí mít rovněž uložené číslo verze hlavního
klíče DSRC.
Poznámka: Podle pokynů v části 9.2.2.2 musí být do jediné
karty dílny nebo kontrolní karty prakticky možné vkládat
více generací KM DSRC .
▼M1
CSM_128 MSCA musí vést záznamy o všech klíčích DSRC vyhraze­
ných příslušným VU, které generoval, jejich číslech verze
a sériových číslech VU nebo identifikátorech žádosti o certi­
fikát, které byly použity při jejich odvozování.
9.2.2.2 Výměna hlavního klíče DSRC
CSM_129 Každý hlavní klíč DSRC je přiřazen určité generaci kořeno­
vého páru klíčů ERCA. ERCA proto musí vyměnit hlavní
klíč DSRC každých 17 let. Doba platnosti každé generace
hlavního klíče DSRC musí začínat dva roky před vstupem
přiřazeného kořenového páru klíčů ERCA v platnost a musí
končit se skončením platnosti přiřazeného kořenového páru
klíčů ERCA. To je znázorněno na Obrázek 3.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 466
Obrázek 3
Vydávání a používání různých generací hlavního klíče DSRC v celcích ve vozidle, kartách dílny a kontrolních
kartách
CSM_130 Nejméně dva roky před generováním nového evropského
kořenového páru klíčů podle popisu v CSM_56 musí
ERCA generovat nový hlavní klíč DSRC. Délka klíče
DSRC musí být spojena s předpokládanou sílou nového
evropského kořenového páru klíčů podle CSM_50. ERCA
musí na požádání MSCA sdělit nový hlavní klíč DSRC
společně s jeho číslem verze.
CSM_131 MSCA musí zajistit uložení všech platných generací K M-WC
do každé kontrolní karty vydané v rámci jeho pravomoci
společně s jejich čísly verze podle Obrázek 3.
Poznámka: To předpokládá, že v posledních dvou letech
doby platnosti certifikátu ERCA budou kontrolní karty
vydávány se třemi různými generacemi KM DSRC , jak je
znázorněno na Obrázek 3.
CSM_132 MSCA musí zajistit, aby všechny generace KM DSRC , které
byly platné nejméně rok a jsou stále platné, byly uloženy
v každé kartě dílny vydané v rámci jeho pravomoci společně
s jejich čísly verze jak je znázorněno na Obrázek 3.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 467
Poznámka: To předpokládá, že v posledním roce doby plat­
nosti certifikátu ERCA budou vydány karty dílny se třemi
různými generacemi KM DSRC , jak je znázorněno na
Obrázek 3.
CSM_133 Výrobci celků ve vozidle musí do každého celku ve vozidle
vložit pouze jednu sadu klíčů DSRC vyhrazených
příslušným VU společně s jejich číslem verze. Tato sada
klíčů musí být odvozena z generace KM DSRC spojené s certi­
fikátem ERCA, na němž jsou založeny certifikáty VU.
Poznámky:
— To předpokládá, že celek ve vozidle založený na certi­
fikátu ERCA generace X musí obsahovat pouze
K_VU DSRC _ENC and K_VU DSRC _MAC generace X,
i když je VU vydán po začátku doby platnosti certifikátu
ERCA generace X+1. To je znázorněno na Obrázek 3.
— Protože karty dílny mají dobu platnosti jeden rok
a kontrolní karty dva roky, výsledkem CSM_131 –
CSM_133 je, že všechny karty dílny a kontrolní karty
obsahují nový hlavní klíč DSRC v okamžiku, kdy je
vydán první VU obsahující klíče vyhrazené příslušným
VU na základě tohoto hlavního klíče.
9.3. Certifikáty
9.3.1 Obecné informace
CSM_134 Všechny certifikáty v systému evropského inteligentního
tachografu musí být samopopisné, kartou ověřitelné (CV)
certifikáty podle [ISO 7816-4] a [ISO 7816-8].
CSM_135 ►M1 Pro kódování datových objektů v certifikátech musí
být použita zvláštní kódovací pravidla (DER) podle [ISO
8825-1]. V tabulce 4 je uvedeno kompletní kódování certi­
fikátů, včetně všech tagů a délek v bajtech. ◄
Poznámka: Toto kódování má za následek následující struk­
turu hodnoty délky tagu (TLV):
Tag: Tag je kódován v jednom nebo dvou oktetech
a indikuje obsah.
Délka: Délka je kódována jako nepodepsané celé číslo
v jednom, dvou nebo třech oktetech, což má za
následek maximální délku 65 535 oktetů. Používá
se minimální počet oktetů.
Hodnota: Hodnota je kódována v nula nebo více oktetech
9.3.2 Obsah certifikátu
CSM_136 Všechny certifikáty musí mít strukturu uvedenou v profilu
certifikátu v Tabulka 4.
Tabulka 4
Profil certifikátu verze 1
Pole ID pole Tag Délka (bajty)
Datový typ ASN.1
(viz dodatek 1)
Certifikát ECC C „7F 21“ var
Tělo certifikátu ECC B „7F 4E“ var
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 468
Pole ID pole Tag Délka (bajty)
Datový typ ASN.1
(viz dodatek 1)
Identifikátor profilu
certifikátu
CPI „5F 29“ „01“
Odkaz na certifikační
orgán
CAR „42“ „08“
Autorizace držitele
certifikátu
CHA „5F 4C“ „07“
Veřejný klíč PK „7F 49“ var
Parametry domény DP „06“ var
Veřejný bod PP „86“ var
Odkaz na držitele
certifikátu
CHR „5F 20“ „08“
Datum účinnosti
certifikátu
CEfD „5F 25“ „04“
Datum konce plat­
nosti certifikátu
CExD „5F 24“ „04“
Podpis certifikátu
ECC
S „5F 37“ var
Poznámka: ID pole se užívá v dalších částech tohoto
dodatku pro označení jednotlivých polí certifikátu, např.
X.CAR je odkaz na certifikační orgán uvedený v certifikátu
uživatele X.
9.3.2.1 Identifikátor profilu certifikátu
CSM_137 Certifikáty musí používat identifikátor profilu certifikátu pro
označení používaného profilu certifikátu. Verze 1 podle
Tabulka 4 musí být označena hodnotou „00“.
9.3.2.2 Odkaz na certifikační orgán
CSM_138 Odkaz na certifikační orgán se užívá pro identifikaci veřej­
ného klíče užívaného pro ověření podpisu certifikátu. Odkaz
na certifikační orgán proto musí být stejný jako odkaz na
držitele certifikátu v certifikátu příslušné certifikační
autority.
CSM_139 Kořenový certifikát ERCA musí být samočinně podepsaný,
tj. odkaz na certifikační orgán a odkaz na držitele certifikátu
musí být v certifikátu stejné.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 469
CSM_140 Pro spojovací certifikát ERCA musí být odkaz na držitele
certifikátu stejný jako CHR nového kořenového certifikátu
ERCA. Odkaz na certifikační orgán pro spojovací certifikát
musí být stejný jako CHR předchozího kořenového certifi­
kátu ERCA.
9.3.2.3 Autorizace držitele certifikátu
CSM_141 Autorizace držitele certifikátu se používá k identifikaci typu
certifikátu. Obsahuje šest nejdůležitějších bajtů ID aplikace
tachografu kaskádově spojených s typem zařízení, čím je
udán typ zařízení, pro něž je certifikát určen. V případě
certifikátu VU, karty řidiče nebo karty dílny se typ zařízení
používá také k rozlišení mezi certifikátem pro vzájemné
ověření pravosti a certifikátem pro vytváření digitálních
podpisů (viz bod 9.1 a dodatek 1, datový typ Equipment­
Type).
▼B
9.3.2.4 Veřejný klíč
Veřejný klíč obsahuje dva datové prvky: standardní parametry domény
užívané s veřejným klíčem v certifikátu a hodnotu veřejného bodu.
CSM_142 Datový prvek parametry domény musí obsahovat jeden
z identifikátorů objektu uvedených v Tabulka 1 pro ozna­
čení odkazu na sadu standardních parametrů domény.
CSM_143 Datový prvek veřejný bod musí obsahovat veřejný bod.
Veřejné body eliptických křivek musí být konvertovány na
oktetové řetězce podle [TR-03111]. Musí být použit nekom­
primovaný kódovací formát. Při získávání bodu eliptické
křivky z jeho kódovaného formátu musí být vždy provedeny
validace podle [TR-03111].
9.3.2.5 Odkaz na držitele certifikátu
CSM_144 Odkaz na držitele certifikátu je identifikátor pro veřejný klíč
poskytovaný v certifikátu. Užívá se pro označení tohoto
veřejného klíče v jiných certifikátech.
CSM_145 Pro certifikáty karet a certifikáty vnějších zařízení GNSS
musí mít odkaz na držitele certifikátu datový typ
uvedený v dodatku 1.
CSM_146 Pro celky ve vozidle výrobce při podání žádosti o certifikát
může nebo nemusí znát specifické sériové číslo výrobce VU,
pro nějž je tento certifikát a příslušný soukromý klíč určen.
V prvním případě musí mít odkaz na držitele certifikátu
datový typ podle dodatku 1.
Ve druhém případě musí mít odkaz na držitele certifikátu
datový typ podle dodatku 1.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 470
Poznámka: Pro certifikát karty musí být hodnota CHR rovna
hodnotě cardExtendedSerialNumber v EF_ICC; viz dodatek
2. Pro certifikát EGF musí být hodnota CHR rovna hodnotě
sensorGNSSSerialNumber v EF_ICC; viz dodatek 14. Pro
certifikát VU musí být hodnota CHR rovna prvku vuSerial­
Number identifikace VuIdentification, viz dodatek 1, pokud
výrobce v okamžiku podání žádosti o certifikát nezná speci­
fické sériové číslo výrobce.
▼B
CSM_147 Pro certifikáty ERCA a MSCA musí mít odkaz na držitele
certifikátu datový typ
podle dodatku 1.
9.3.2.6 Datum účinnosti certifikátu
▼M1
CSM_148 Datum účinnosti certifikátu musí označovat počáteční datum
a délku doby platnosti certifikátu.
▼B
9.3.2.7 Datum konce platnosti certifikátu
CSM_149 Datum konce platnosti certifikátu musí označovat konečné
datum a délku doby platnosti certifikátu.
9.3.2.8 Podpis certifikátu
CSM_150 Podpis certifikátu musí být vytvořen na kódovaném těle
certifikátu, včetně tagu a délky těla certifikátu. Podpisový
algoritmus musí být ECDSA podle [DSS], který používá
hašovací algoritmus spojený s velikostí klíče podepisujícího
orgánu podle CSM_50. Formát podpisu musí být otevřený
podle [TR-03111].
9.3.3 Podání žádosti o certifikát
CSM_151 ►M1 Při podání žádosti o certifikát musí MSCA zaslat
ERCA tyto údaje: ◄
— identifikátor profilu požadovaného certifikátu,
— odkaz na certifikační orgán, který se má použít při
podpisu certifikátu,
— veřejný klíč, který má být podepsán.
CSM_152 Kromě údajů v CSM_151 musí MSCA zaslat ERCA
v žádosti o certifikát tyto údaje, které ERCA umožní
vytvořit odkaz na držitele certifikátu nového certifikátu
MSCA:
— číselný kód státu certifikační autority (datový typ
stanovený v dodatku 1),
— alfanumerický kód státu certifikační autority (datový typ
stanovený v dodatku 1),
— jednobajtové sériové číslo pro rozlišení různých klíčů
certifikační autority v případě výměny klíčů,
— dvoubajtové pole obsahující doplňkové informace
příslušné certifikační autority.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 471
CSM_153 Výrobce zařízení musí zaslat MSCA v žádosti o certifikát
tyto údaje, které MSCA umožní vytvořit odkaz na držitele
nového certifikátu zařízení:
— případně (viz CSM_154) sériové číslo pro zařízení, které
je pro výrobce jedinečné, typ zařízení a měsíc výroby.
V ostatních případech jedinečný identifikátor žádosti
o certifikát,
— měsíc a rok výroby zařízení nebo žádosti o certifikát.
Výrobce musí zajistit správnost těchto údajů a vložení certifikátu, který
mu MSCA vrátí, do určeného zařízení.
▼B
CSM_154 Pokud jde o VU, výrobce při podání žádosti o certifikát
může a nemusí znát specifické sériové číslo výrobce VU,
pro nějž je tento certifikát a příslušný soukromý klíč určen.
Je-li toto číslo známo, musí výrobce VU zaslat sériové číslo
MSCA. Není-li známo, musí výrobce jedinečně označit
každou žádost o certifikát a toto sériové číslo žádosti o certi­
fikát zaslat MSCA. Výsledný certifikát potom obsahuje
sériové číslo žádosti o certifikát. Po vložení certifikátu do
specifického VU musí výrobce sdělit MSCA spojení mezi
sériovým číslem žádosti o certifikát a označením VU.
10. VZÁJEMNÉ OVĚŘOVÁNÍ PRAVOSTI A BEZPEČNÉ PŘEDÁVÁNÍ
ZPRÁV VU A KARTY
10.1. Obecné informace
CSM_155 Bezpečná komunikace na vysoké úrovni mezi celkem ve
vozidle a kartou tachografu je založena na těchto krocích:
— Za prvé, každá strana musí druhé straně prokázat, že
vlastní platný certifikát veřejného klíče podepsaný certi­
fikačním orgánem členského státu. Certifikát veřejného
klíče MSCA musí být navíc podepsán Evropským
úřadem kořenových certifikátů. Tento krok se nazývá
ověřením řetězce certifikátů a je podrobně popsán
v části 10.2.
— Za druhé, celek ve vozidle musí kartě prokázat, že
vlastní soukromý klíč odpovídající veřejnému klíči
příslušného certifikátu. Učiní tak podpisem náhodného
čísla zaslaného kartou. Karta ověří podpis náhodného
čísla. Je-li toto ověření úspěšné, je ověřena pravost
VU. Tento krok se nazývá ověření pravosti VU a je
podrobně popsán v části 10.3.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 472
— Za třetí, obě strany nezávisle vypočítají dva klíče relace
AES pomocí algoritmu odsouhlasení asymetrického
klíče. Pomocí jednoho z těchto klíčů relace karta vytvoří
kód ověřování zprávy (MAC) pro určitá data zaslaná
z VU. VU ověří MAC. Je-li toto ověření úspěšné, je
ověřena pravost karty. Tento krok se nazývá ověření
pravosti karty a je podrobně popsán v části 10.4.
— Za čtvrté, VU a karta musí užívat odsouhlasené klíče
relace pro zajištění důvěrnosti, integrity a pravosti
všech vyměňovaných zpráv. Tento proces se nazývá
bezpečné předávání práv a je podrobně popsán v části
10.5.
CSM_156 Mechanismus popsaný v CSM_155 musí být aktivován
celkem ve vozidle při každém vložení karty do některého
z jeho slotů.
10.2. Vzájemné ověření řetězce certifikátů
10.2.1 Ověření řetězce certifikátů karty celkem ve vozidle
CSM_157 ►M1 Celky ve vozidle musí pro ověření řetězce certifikátů
karty tachografu užívat protokol popsaný na obrázku 4.
U každého certifikátu přečteného z karty VU ověří, zda
jsou údaje v poli autorizace držitele certifikátu (CHA)
správné:
— V poli CHA certifikátu karty musí být uveden certifikát
karty pro vzájemné ověření pravosti (viz dodatek 1,
datový typ EquipmentType).
— V poli CHA certifikátu Card.CA musí být uveden
MSCA.
— V poli CHA certifikátu Card.Link musí být uveden
ERCA. ◄
Poznámky k Obrázek 4:
— Certifikáty a veřejné klíče karty uvedené na obrázku se
používají pro vzájemné ověřování pravosti. V části 9.1.5
jsou označeny jako Card_MA.
— Certifikáty a veřejné klíče Card.CA uvedené na obrázku
se používají pro podpis certifikátů karet a jsou uvedeny
v CAR certifikátu karty. V bodě 9.1.3 jsou označeny
jako MSCA_Card.
— Certifikát Card.CA.EUR uvedený na obrázku je
evropský kořenový certifikát, který je uveden v CAR
certifikátu Card.CA.
— Certifikát Card.Link uvedený na obrázku je případný
spojovací certifikát karty. Jak je uvedeno v části 9.1.2,
jedná se o spojovací certifikát pro nový evropský koře­
nový pár klíčů vytvořený ERCA a podepsaný před­
chozím evropským soukromým klíčem.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 473
— Certifikát Card.Link.EUR je evropský kořenový certi­
fikát, který je uveden v CAR certifikátu Card.Link.
CSM_158 Jak je uvedeno v Obrázek 4, ověření řetězce certifikátů
karty se zahájí po vložení karty. Celek ve vozidle
přečte z EF ICC odkaz na držitele karty
( ). VU musí zkontro­
lovat, zda kartu zná, tj. zda řetězec certifikátů karty úspěšně
ověřil v minulosti a uložil jej pro budoucí potřebu. Pokud
ano a certifikát karty je dosud platný, pokračuje proces
ověřením řetězce certifikátů VU. V opačném případě VU
postupně z karty přečte certifikát MSCA_Card užívaný pro
ověření certifikátu karty, certifikát Card.CA. EUR užívaný
pro ověření certifikátu MSCA_Card a případně spojovací
certifikát, dokud nenalezne certifikát, který zná nebo který
může ověřit. Pokud takový certifikát nalezne, VU tento
certifikát použije pro ověření příslušných certifikátů karty,
které z karty přečetl. Je-li tento krok úspěšný, pokračuje
proces ověřením řetězce certifikátů VU. Není-li úspěšný,
VU kartu ignoruje.
Poznámka: Existují tři způsoby, jak může VU znát certifikát
Card.CA.EUR:
— certifikát Card.CA.EUR je stejný certifikát jako vlastní
certifikát EUR ve VU,
— Card.CA.EUR certifikát byl vydán dříve než vlastní
certifikát EUR ve VU a VU tento certifikát obsahoval
již při vydání (viz CSM_81),
— Card:CA.EUR certifikát byl vydán až po vlastním certi­
fikátu EUR ve VU a VU v minulosti přijal spojovací
certifikát z jiné karty tachografu, ověřil jej a uložil pro
budoucí potřebu.
CSM_159 Jak je uvedeno v Obrázek 4, jakmile VU prokáže pravost
a platnost dříve neznámého certifikátu, může tento certifikát
uložit pro budoucí potřebu, aby nemusel pravost tohoto
certifikátu ověřovat znovu, až bude VU opět předložen.
Místo uložení celého certifikátu může VU uložit
pouze obsah těla certifikátu, jak je uvedeno v části 9.3.2.
►M1 Zatímco uložení všech ostatních typů certifikátů není
povinné, nový spojovací certifikát předložený kartou VU
uložit musí. ◄
CSM_160 VU musí ověřit aktuální platnost každého certifikátu přečte­
ného
z karty nebo uloženého do své paměti a musí zamítnout
certifikáty se skončenou platností. Pro ověření aktuální plat­
nosti certifikátu předloženého kartou musí VU užít své
vnitřní hodiny.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 474
Obrázek 4
Protokol pro ověření řetězce certifikátů karty celkem ve vozidle
10.2.2 Ověření řetězce certifikátů VU kartou
CSM_161 ►M1 Karty tachografu musí pro ověření řetězce certifikátů
VU používat protokol popsaný na obrázku 5. U každého
certifikátu, který VU předloží, karta ověří, zda jsou údaje
v poli autorizace držitele certifikátu (CHA) správné:
— V poli CHA certifikátu VU.Link musí být uveden
ERCA.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 475
— V poli CHA certifikátu VU.CA musí být uveden MSCA.
— V poli CHA certifikátu VU musí být uveden certifikát
VU pro vzájemné ověření pravosti (viz dodatek 1,
datový typ EquipmentType). ◄
Obrázek 5
Protokol pro ověření řetězce certifikátů karty celkem ve vozidle
Poznámky k Obrázek 5:
— Certifikáty a veřejné klíče VU uvedené na obrázku se používají pro
vzájemné ověřování pravosti. V části 9.1.4 jsou označeny jako
VU_MA.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 476
— Certifikáty a veřejné klíče VU.CA uvedené na obrázku se používají
pro podpis certifikátů VU a vnějších zařízení GNSS. V části 9.1.3
jsou označeny jako MSCA_VU-EGF.
— Certifikát VU.CA.EUR uvedený na obrázku je evropský kořenový
certifikát, který je uveden v CAR certifikátu VU.CA.
— Certifikát VU.Link uvedený na obrázku je případný spojovací certi­
fikát VU. Jak je uvedeno v části 9.1.2, jedná se o spojovací certifikát
pro nový evropský kořenový pár klíčů vytvořený ERCA a podepsaný
předchozím evropským soukromým klíčem.
— Certifikát VU.Link.EUR je evropský kořenový certifikát, který je
uveden v CAR certifikátu VU.Link.
CSM_162 Jak je uvedeno v Obrázek 5, ověření řetězce certifikátů
celku ve vozidle se zahájí v okamžiku, kdy se celek ve
vozidle pokouší nastavit vlastní veřejný klíč pro používání
v kartě tachografu. Pokud se to podaří, znamená to, že karta
v minulosti úspěšně ověřila řetězec certifikátů VU a uložila
certifikát VU pro budoucí potřebu. V tomto případě se
certifikát VU nastaví pro použití a proces pokračuje
ověřením pravosti VU. Pokud karta certifikát VU nezná,
VU postupně předloží certifikát VU.CA užívaný pro ověření
certifikátu VU, certifikát VU.CA.EUR užívaný pro ověření
certifikátu VU.CA a případně spojovací certifikát, aby tak
byl nalezen certifikát, který karta zná. Je-li takový certifikát
nalezen, karta tento certifikát použije pro ověření přísluš­
ných certifikátů VU, které jí jsou předloženy. Je-li tento
krok úspěšný, VU nakonec nastaví svůj veřejný klíč pro
užití v kartě tachografu. Není-li úspěšný, VU kartu ignoruje.
Poznámka: Existují tři způsoby, jak může karta poznat certi­
fikát VU.CA.EUR:
— certifikát VU.CA.EUR je stejný certifikát jako vlastní
certifikát EUR karty,
— certifikát VU.CA.EUR byl vydán dříve než vlastní certi­
fikát EUR karty a karta tento certifikát obsahovala již
při vydání (viz CSM_91),
— certifikát VU.CA.EUR byl vydán až po vlastním certi­
fikátu EUR karty a karta v minulosti přijala spojovací
certifikát z jiného celku ve vozidle, ověřila jej a uložila
pro budoucí potřebu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 477
CSM_163 VU použije příkaz MSE: Set AT pro nastavení svého veřej­
ného klíče pro užití v kartě tachografu. Jak je uvedeno
v dodatku 2, tento příkaz obsahuje označení kryptografic­
kého mechanismu, který bude použit se stanoveným klíčem.
Tímto mechanismem je „Ověřování pravosti VU pomocí
algoritmu ECDSA ve spojení s hašovacím algoritmem
spojeným s velikostí klíče páru klíčů VU_MA celku ve
vozidle, jak je uvedeno v CSM_50“.
CSM_164 Příkaz MSE: Set AT rovněž obsahuje označení přechodného
páru klíčů, který VU použije při odsouhlasení klíče relace
(viz část 10.4). Před zasláním příkazu MSE: Set AT proto
VU vygeneruje přechodný pár klíčů ECC. Pro generování
přechodného páru klíčů VU použije standardní parametry
domény uvedené v certifikátu karty. Přechodný pár klíčů
je označen jako (VU.SK eph , VU.PK eph , Card.DP). VU
použije souřadnici x přechodného veřejného bodu ECDH
jako označení klíče; toto se nazývá komprimované zastou­
pení veřejného klíče a označuje se jako Comp(VU.PK eph ).
▼M1
CSM_165 Je-li příkaz MSE: Set AT úspěšný, karta nastaví uvedený
VU.PK pro následující použití během ověřování pravosti
vozidla a přechodně uloží Comp(VU.PKeph). Jsou-li před
odsouhlasením klíče relace zaslány dva nebo více úspěš­
ných příkazů MSE: Set AT, karta uloží pouze poslední
přijatý Comp(VU.PKeph). Karta resetuje Comp(VU.PKeph)
po úspěšném provedení příkazu GENERAL AUTHENTI­
CATE.
▼B
CSM_166 Karta musí ověřit dočasnou platnost všech certifikátů, které
VU předloží nebo na které odkazuje při uložení do paměti
karty, a musí zamítnout certifikáty se skončenou platností.
CSM_167 Pro ověření dočasné platnosti certifikátu předloženého
celkem ve vozidle musí každá karta tachografu interně
ukládat určitá data představující aktuální čas. Tato data
nesmí být celkem ve vozidle přímo aktualizovatelná. Při
vydání musí být aktuální čas karty nastaven na datum účin­
nosti certifikátu Card_MA karty. Karta svůj aktuální čas
aktualizuje, je-li datum účinnosti certifikátu s původním
platným zdrojem času předloženého celkem ve vozidle
pozdější než aktuální čas karty. V tomto případě karta
nastaví svůj aktuální čas na datum účinnosti tohoto certifi­
kátu. Karta jako platný zdroj času přijme pouze tyto certi­
fikáty:
— spojovací certifikáty ERCA druhé generace,
— certifikáty MSCA druhé generace,
— certifikáty VU druhé generace vydané stejnou zemí jako
vlastní certifikát(y) karty.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 478
Poznámka: Poslední požadavek předpokládá, že karta musí
být schopna rozeznat CAR certifikátu VU, tj. certifikát
MSCA_VU-EGF. Ten nebude stejný jako CAR jejího vlast­
ního certifikátu, kterým je certifikát MSCA_Card.
CSM_168 Jak je uvedeno v Obrázek 5, jakmile karta ověří pravost
a platnost dříve neznámého certifikátu, může tento certifikát
uložit pro budoucí potřebu, aby nemusela pravost tohoto
certifikátu ověřovat znovu, až bude kartě opět předložen.
Místo uložení celého certifikátu může karta uložit pouze
obsah těla certifikátu, jak je uvedeno v části 9.3.2.
10.3. Ověření pravosti VU
CSM_169 Celky ve vozidle a karty musí používat protokol ověřování
pravosti VU uvedený na Obr. 6 pro prokázání pravosti VU
vůči kartě. Ověřování pravosti VU umožňuje kartě tacho­
grafu jednoznačně ověřit důvěryhodnost VU. K tomuto
účelu VU použije svůj soukromý klíč k podpisu výzvy
generované kartou.
CSM_170 ►M1 Kromě samotného podpisu výzvy karty musí VU do
podpisu vložit odkaz na držitele certifikátu zjištěný z certifi­
kátu karty. ◄
Poznámka: Tento postup zajišťuje, že karta, které VU
prokazuje svou pravost, je stejná karta, jejíž řetězec certifi­
kátů VU dříve ověřil.
CSM_171 VU musí rovněž do podpisu vložit identifikátor přechod­
ného veřejného klíče Comp(VU.PK eph ), který bude VU
používat pro zajištění bezpečného předávání zpráv během
procesu ověřování pravosti čipu stanoveného v části 10.4.
Poznámka: Tento postup zajišťuje, že VU, se kterým karta
komunikuje během relace bezpečného předávání zpráv, je
ten VU, jehož pravost byla ověřena kartou.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 479
Obrázek 6
Protokol ověřování pravosti VU
▼B
CSM_172 Pokud během ověřování pravosti VU celek ve vozidle
odešle vícenásobné příkazy GET CHALLENGE, karta
vždy vrátí novou osmibajtovou náhodnou výzvu, ale uloží
pouze poslední výzvu.
CSM_173 Podpisový algoritmus užívaný celkem ve vozidle pro ověřo­
vání pravosti VU musí být ECDSA podle pokynů v [DSS],
který používá hašovací algoritmus spojený s velikostí klíče
páru klíčů VU_MA celku ve vozidle podle CSM_50.
Formát podpisu musí být otevřený podle [TR-03111]. VU
zašle výsledný podpis kartě.
▼M1
CSM_174 Po přijetí podpisu VU v příkazu EXTERNAL AUTHENTI­
CATE musí karta
— vypočítat ověřovací token kaskádovým spojením
Card.CHR, výzvu karty rcard a identifikátor přechod­
ného veřejného klíče Comp(VU.PKeph) celku ve
vozidle,
— ověřit podpis VU pomocí algoritmu ECDSA, pomocí
hašovacího algoritmu spojeného s velikostí klíče páru
klíčů VU_MA key celku ve vozidle podle CSM_50,
ve spojení s VU.PK a vypočítaným ověřovacím
tokenem.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 480
10.4. Ověření pravosti čipu a odsouhlasení klíče relace
CSM_175 Celky ve vozidle a karty musí užívat protokol ověřování
pravosti čipu uvedený na Obr. 7 pro ověření pravosti
karty vůči VU. Ověření pravosti čipu umožňuje celku ve
vozidle jednoznačně ověřit důvěryhodnost karty.
Obr. 7
Ověření pravosti čipu a odsouhlasení klíče relace
CSM_176 VU a karta musí provést tyto kroky:
1. Celek ve vozidle zahájí proces ověření pravosti čipu
zasláním příkazu MSE: Set AT, který znamená „Ověření
pravosti čipu pomocí algoritmu ECDH pro vytvoření
délky klíče relace AES spojené s velikostí klíče páru
klíčů Card_MA karty, jak je uvedeno v CSM_50“. VU
určí velikost klíče páru klíčů karty z certifikátu karty.
▼M1
2. VU zašle kartě veřejný bod VU.PK eph svého přechod­
ného páru klíčů. Tento veřejný bod musí být konver­
tován na oktetový řetězec podle [TR-03111]. Musí být
použit nekomprimovaný kódovací formát. Jak je
uvedeno v CSM_164, VU generoval tento přechodný
pár klíčů před ověřením řetězce certifikátů VU. VU
zaslal identifikátor přechodného veřejného klíče
Comp(VU.PK eph ) kartě, která jej uložila.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 481
3. Karta vypočítá Comp(VU.PK eph ) z VU.PK eph a porovná
jej s uloženou hodnotou Comp(VU.PK eph ).
4. Pomocí algoritmu ECDH ve spojení se statickým
soukromým klíčem karty a přechodným veřejným klíčem
VU karta vypočítá tajnou hodnotu K.
5. Karta zvolí náhodnou 8bajtovou hodnotu nonce N PICC
a použije ji pro odvození dvou klíčů relace AES K MAC
a K ENC z hodnoty K. Viz CSM_179.
▼M1
6. Pomocí K MAC karta vypočítá ověřovací token pro
přechodný veřejný bod VU: T PICC = CMAC(K MAC ,
VU.PK eph ). Veřejný bod musí být ve formátu použitém
v celku ve vozidle (viz druhý pododstavec výše). Karta
zašle N PICC a T PICC celku ve vozidle.
▼B
7. Pomocí algoritmu ECDH ve spojení se statickým
veřejným klíčem karty a přechodným soukromým klíčem
VU celek ve vozidle vypočítá stejnou tajnou hodnotu
K jako karta v kroku 4.
8. VU odvodí klíče relace K MAC a K ENC z K a N PICC ; viz
CSM_179.
9. VU ověří značku prokázání pravosti T PICC .
CSM_177 V kroku 3 výše musí karta vypočítat Comp(VU.PKeph)
jako souřadnici x veřejného bodu ve VU.PKeph.
CSM_178 V krocích 4 a 7 výše musí karta a celek ve vozidle použít
algoritmus ECKA-EG stanovený v [TR-03111].
CSM_179 V krocích 5 a 8 výše musí karta a celek ve vozidle použít
funkci odvození klíče pro klíče relace AES stanovené
v [TR-03111] s touto přesností a změnami:
— Hodnota čítače musí být „00 00 00 01“ pro K ENC a „00
00 00 02“ pro K MAC .
— Musí být použita volitelná hodnota nonce r odpovídající
hodnotě N PICC .
— Pro odvození 128-bitových klíčů AES musí být použit
hašovací algoritmus SHA-256.
— Pro odvození 192-bitových klíčů AES musí být použit
hašovací algoritmus SHA-384.
— Pro odvození 256-bitových klíčů AES musí být použit
hašovací algoritmus SHA-512.
Délka klíčů relace (tj. délka, při níž je hash přerušen) musí
být spojena s velikostí páru klíčů Card_MA podle CSM_50.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 482
CSM_180 V krocích 6 a 9 výše musí karta a celek ve vozidle použít
algoritmus AES v režimu CMAC podle [SP 800-38B].
Délka T PICC musí být spojena s délkou klíčů relace AES
podle CSM_50.
10.5. Bezpečné předávání zpráv
10.5.1 Obecné informace
CSM_181 Všechny příkazy a odpovědi vyměňované mezi celkem ve
vozidle a kartou tachografu po úspěšném ověření pravosti
čipu a do skončení relace musí být chráněny bezpečným
předáváním zpráv.
CSM_182 S výjimkou čtení ze souboru s podmínkou přístupu SM-R-
ENC-MAC-G2 (viz dodatek 2, část 4) musí být bezpečné
předávání zpráv užíváno pouze v režimu ověřování pravosti.
V tomto režimu je kryptografický kontrolní součet (MAC)
přidáván ke všem příkazům a odpovědím pro zajištění
pravosti a integrity zpráv.
CSM_183 Při čtení dat ze souboru s podmínkou přístupu SM-R-ENC-
MAC-G2 musí být bezpečné předávání zpráv používáno
v režimu šifrování a následného prokazování pravosti, tj.
data odezvy jsou nejprve šifrována pro zajištění důvěrnosti
zprávy a následně je vypočítán MAC pro formátovaná šifro­
vaná data pro zajištění pravosti a integrity.
CSM_184 Bezpečné předávání zpráv musí užívat AES podle [AES]
s klíči relace K MAC a K ENC , které byly odsouhlaseny
během ověřování pravosti čipu.
CSM_185 Pro zabránění opakovaným útokům musí být používáno
nepodepsané celé číslo jako čítač odeslané
posloupnosti (SSC). Velikost SSC musí být stejná jako veli­
kost bloku AES, tj. 128 bitů. SSC musí být ve formátu
MSB-first. Čítač odeslané posloupnosti musí být při zahá­
jení bezpečného předávání zpráv nastaven na nulu (tj. „00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00“). SSC
musí být zvýšen před každým generováním příkazu nebo
odezvy APDU, tj. jestliže je počáteční hodnota SSC v relaci
SM 0, bude v prvním příkazu hodnota SSC 1. Hodnota SSC
pro první odpověď bude 2.
CSM_186 Pro šifrování zpráv musí být užíván klíč K ENC s AES
v operačním módu řetězení šifrového textu (CBC) podle
[ISO 10116] s vloženým parametrem m = 1 a inicializačním
vektorem SV = E(K ENC , SSC), tj. aktuální hodnota čítače
odeslané posloupnosti šifrovaná pomocí K ENC .
CSM_187 Pro ověření pravosti zpráv musí být užíván klíč K MAC
s AES v módu CMAC podle [SP 800-38B]. Délka MAC
musí být spojena s délkou klíčů relace AES podle CSM_50.
Čítač odeslané posloupnosti se do MAC vloží před data­
gram, který má být ověřen.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 483
10.5.2 Struktura bezpečné zprávy
CSM_188 Bezpečné předávání zpráv musí užívat pouze datové objekty
bezpečného předávání zpráv (viz [ISO 7816-4]) uvedené
v Tabulka 5. V každé zprávě musí být tyto datové objekty
použity v pořadí uvedeném v této tabulce.
Tabulka 5
Datové objekty bezpečného předávání zpráv
Název datového objektu Tag
Přítomnost (Z)ávazná, (P)o­
dmíněná
nebo (N)epřípustná v
Příkazy Odezvy
Otevřená hodnota nekódovaná v BER-
TLV
„81“ C C
Otevřená hodnota kódovaná v BER-
TLV, ale neobsahující SM DO
„B3“ C C
Indikátor doplňkového obsahu následo­
vaný šifrovaným záznamem, otevřenou
hodnotou nekódovanou v BER-TLV
„87“ C C
Chráněné Le „97“ C F
Stav zpracování „99“ F M
Kryptografický kontrolní součet „8E“ M M
Poznámka: Jak je uvedeno v dodatku 2, mohou karty tacho­
grafu podporovat příkaz READ BINARY a UPDATE
BINARY s lichým bajtem INS („B1“ resp. „D7“). Tyto
varianty příkazů jsou požadovány pro čtení a aktualizaci
souborů s více než 32 768 bajty. V případě užití takové
varianty se datový objekt s tagem „B3“ použije místo
objektu s tagem „81“. Více informací v dodatku 2.
CSM_189 Všechny datové objekty SM musí být kódovány v DER
TLV podle [ISO 8825-1]. Toto kódování má za následek
následující strukturu hodnoty délky tagu (TLV):
Tag: Tag je kódován v jednom nebo dvou oktetech
a indikuje obsah.
Délka: Délka je kódována jako nepodepsané celé číslo
v jednom, dvou nebo třech oktetech, což má za
následek maximální délku 65 535 oktetů. Používá
se minimální počet oktetů.
Hodnota: Hodnota je kódována v nula nebo více oktetech
CSM_190 APDU chráněné bezpečným předáváním zpráv musí být
vytvořeny takto:
— Záhlaví příkazu se zahrne do výpočtu MAC, proto se
pro druh bajtu CLA užije hodnota „0C“.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 484
— Jak je uvedeno v dodatku 2, musí být všechny bajty INS
sudé s možnou výjimkou lichých bajtů INS pro příkazy
READ BINARY a UPDATE BINARY.
— Aktuální hodnota Lc se po použití bezpečného zpraco­
vání zpráv změní na Lc'.
— Datové pole musí obsahovat datové objekty SM.
— V chráněném příkazu APDU musí být nový bajt Le
nastaven na hodnotu „00“. V případě potřeby se do
datového pole zařadí datový objekt „97“, který vyja­
dřuje původní hodnotu Le.
▼M1
CSM_191 Všechny datové objekty určené k šifrování musí být podle
[ISO 7816-4] doplněny indikátorem doplňkového obsahu
‘01’. Pro výpočet MAC se datové objekty v APDU doplní
podle [ISO 7816-4].
Poznámka: Doplňování pro bezpečné předávání zpráv se
vždy provádí pomocí vrstvy bezpečného předávání zpráv,
nikoli pomocí algoritmů CMAC nebo CBC.
Shrnutí a příklady
Příkaz APDU s použitým bezpečným předáváním zpráv má v závislosti
na příslušném nezabezpečeném příkazu následující strukturu (DO je
datový objekt):
Případ 1: CLA INS P1 P2 || Lc' || DO „8E“ || Le
Případ 2: CLA INS P1 P2 || Lc' || DO „97“ || DO„8E“
|| Le
Případ 3 (sudý bajt INS): CLA INS P1 P2 || Lc' || DO „81“ || DO„8E“
|| Le
Případ 3 (lichý bajt INS): CLA INS P1 P2 || Lc' || DO „B3“ || DO„8E“
|| Le
Případ 4 (sudý bajt INS): CLA INS P1 P2 || Lc' || DO „81“ || DO„97“
|| DO„8E“ || Le
Případ 4 (lichý bajt INS): CLA INS P1 P2 || Lc' || DO „B3“ || DO„97“
|| DO„8E“ || Le
kde Le = ‘00’ nebo ‘00 00’ v závislosti na tom, zda jsou použita krátká
pole délky nebo rozšířená pole délky; viz [ISO 7816-4].
Odpověď APDU s použitým bezpečným předáváním zpráv má v závi­
slosti na příslušné nezabezpečené odpovědi následující strukturu:
Případ 1 nebo 3: DO „99“ || DO „8E“ ||
SW1SW2
Případ 2 nebo 4 (sudý bajt
INS) bez šifrování
:
DO „81“ || DO „99“ || DO
„8E“ || SW1SW2
Případ 2 nebo 4 (sudý bajt
INS) se šifrováním
:
DO „87“ || DO „99“ || DO
„8E“ || SW1SW2
Případ 2 nebo 4 (lichý bajt
INS)
bez šifrování:
DO „B3“ || DO „99“ || DO
„8E“ || SW1SW2
Poznámka: Případ 2 nebo 4 (lichý bajt INS) se šifrováním se v komuni­
kaci mezi VU a kartou nikdy nepoužívá.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 485
Níže jsou uvedeny tři příklady transformace APDU pro příkazy se sudým
kódem INS. Obrázek 8 znázorňuje případ 4 příkazu APDU s ověřenou
pravostí, obrázek 9 znázorňuje případ 1 / případ 3 odpovědi APDU
s ověřenou pravostí a obrázek 10 znázorňuje případ 2 / případ 4 odpo­
vědi APDU se šifrováním a ověřenou pravostí.
Obrázek 8
Transformace případu 4 příkazu APDU s ověřenou pravostí
Obrázek 9
Transformace případu 1 / případu 3 odpovědi APDU s ověřenou pravostí
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 486
Obrázek 10
Transformace případu 2 / případu 4 odpovědi APDU se šifrováním a ověřenou pravostí
▼B
10.5.3 Přerušení relace bezpečného předávání zpráv
CSM_192 Celek ve vozidle přeruší aktuální relaci bezpečného předávání
zpráv pouze v případě, že je splněna některá z těchto
podmínek:
— přijme otevřenou odpověď APDU,
— detekuje chybu bezpečného předávání zpráv v odpovědi
APDU:
— chybí očekávaný datový objekt bezpečného předávání
zpráv, pořadí datových objektů je nesprávné nebo je
zařazen neznámý datový objekt,
— datový objekt bezpečného předávání zpráv je
nesprávný, např. hodnota MAC je nesprávná, struktura
TLV je nesprávná nebo indikátor doplnění v tagu „87“
se nerovná „01“.
— karta odešle bajt statusu, který označuje detekování chyby
SM (viz CSM_194),
— je dosaženo mezního počtu příkazů a příslušných odpo­
vědí v rámci aktuální relace. Pro příslušný VU tuto mezní
hodnotu stanoví jeho výrobce s ohledem na bezpečnostní
požadavky použitého hardwaru s maximální hodnotou
240 příkazů a příslušných odpovědí SM na relaci.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 487
CSM_193 Karta tachografu přeruší aktuální relaci bezpečného předávání
zpráv pouze v případě, že je splněna některá z těchto
podmínek:
— přijme otevřený příkaz APDU,
— detekuje chybu bezpečného předávání zpráv v příkazu
APDU:
— chybí očekávaný datový objekt bezpečného předávání
zpráv, pořadí datových objektů je nesprávné nebo je
zařazen neznámý datový objekt,
— datový objekt bezpečného předávání zpráv je
nesprávný, např. hodnota MAC nebo struktura TLV
je nesprávná,
— je odpojena od napájení nebo resetována,
— VU zahájí proces ověření pravosti VU,
— je dosaženo mezního počtu příkazů a příslušných odpo­
vědí v rámci aktuální relace. Pro příslušnou kartu tuto
mezní hodnotu stanoví její výrobce s ohledem na bezpeč­
nostní požadavky použitého hardwaru s maximální
hodnotou 240 příkazů a příslušných odezev SM na relaci.
▼B
CSM_194 Na chybu SM reaguje karta tachografu takto:
— Pokud v příkazu APDU chybí některé očekávané datové
objekty bezpečného předávání zpráv, pořadí datových
objektů je nesprávné nebo jsou zařazeny neznámé datové
objekty, odpoví karta tachografu stavovými bajty „69 87“.
— Pokud je některý datový objekt bezpečného předávání
zpráv v příkazu APDU nesprávný, odpoví karta tacho­
grafu bajty statusu „69 88“.
V takovém případě musí být bajty statusu znovu odeslány bez
použití bezpečného předávání zpráv.
CSM_195 Pokud je relace bezpečného předávání zpráv mezi VU a kartou
tachografu přerušena, VU a karta tachografu musí
— bezpečně zlikvidovat uložené klíče relace,
— okamžitě navázat novou relaci bezpečného předávání
zpráv podle částí 10.2 – 10.5.
CSM_196 Pokud se z jakéhokoli důvodu VU rozhodne znovu zahájit
vzájemné ověřování pravosti vůči vložené kartě, musí být
tento proces zahájen ověřením řetězce certifikátů karty
podle části 10.2 a pokračovat v souladu s částmi 10.2 – 10.5.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 488
11. PÁROVÁNÍ VU – VNĚJŠÍ ZAŘÍZENÍ GNSS, VZÁJEMNÉ OVĚŘO­
VÁNÍ PRAVOSTI A BEZPEČNÉ PŘEDÁVÁNÍ ZPRÁV
11.1. Obecné informace
CSM_197 Zařízení GNSS používané VU pro určování jeho polohy může
být interní (tj. vestavěné do krytu VU a neoddělitelné), nebo
se může jednat o externí modul. V prvním případě není třeba
standardizovat vnitřní komunikaci mezi zařízením GNSS
a VU a požadavky podle této kapitoly se nepoužijí. Ve
druhém případě musí být komunikace mezi VU a vnějším
zařízením GNSS standardizována a chráněna podle ustano­
vení této kapitoly.
CSM_198 Bezpečná komunikace mezi celkem ve vozidle a vnějším zaří­
zením GNSS probíhá stejně jako bezpečná komunikace mezi
celkem ve vozidle a kartou tachografu, přičemž úlohu karty
přebírá vnější zařízení GNSS (EGF). EGF musí splňovat
všechny požadavky uvedené v kapitole 10 pro karty tacho­
grafu při zohlednění odchylek, vysvětlení a doplňků uvede­
ných v této kapitole. Zejména vzájemné ověření řetězců certi­
fikátů, ověření pravosti VU a ověření pravosti čipu se musí
provádět podle pokynů v částech 11.3 and 11.4.
CSM_199 Komunikace mezi celkem ve vozidle a EGF se liší od komu­
nikace mezi celkem ve vozidle a kartou v tom, že celek ve
vozidle a EGF se musí před tím, než si budou moci během
normálního provozu vyměňovat data na bázi GNSS, spárovat
v dílně. Proces párování je popsán v části 11.2.
CSM_200 Pro komunikaci mezi celkem ve vozidle a EGF musí být
užívány příkazy a odezvy APDU podle [ISO 7816-4]
a [ISO 7816-8]. Přesná struktura těchto APDU je stanovena
v dodatku 2 této přílohy.
11.2. Párování VU a externího zařízení GNSS
CSM_201 Celek ve vozidle a EGF ve vozidle musí být spárovány
v dílně. Během normálního provozu mohou komunikovat
pouze celek ve vozidle a EGF, které byly spárovány.
CSM_202 Párování celku ve vozidle a EGF je možné pouze v případě,
že celek ve vozidle je v kalibračním módu. Párování musí být
zahájeno celkem ve vozidle.
CSM_203 Dílna může kdykoli znovu spárovat celek ve vozidle s jiným
EGF nebo stejným EGF. Během nového párování musí VU
ve své paměti bezpečně zlikvidovat stávající certifikát
EGF_MA a uložit certifikát EGF_MA vnějšího zařízení
GNSS, s nímž má být párováno.
CSM_204 Dílna může kdykoli znovu spojit vnější zařízení GNSS
s jiným VU nebo stejným VU. Během nového párování
musí EGF ve své paměti bezpečně zlikvidovat stávající certi­
fikát VU_MA a uložit certifikát VU_MA celku ve vozidle,
s nímž má být párováno.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 489
11.3. Vzájemné ověření řetězce certifikátů
11.3.1 Obecné informace
CSM_205 Vzájemné ověření řetězce certifikátů mezi VU a EGF se
provede pouze během párování VU a EGF v dílně. Během
normálního provozu spárovaného VU a EGF nejsou ověřo­
vány žádné certifikáty. VU a EGF musí naopak důvěřovat
certifikátům, které uložily během párování a po ověření
dočasné platnosti těchto certifikátů. VU a EGF nesmí důvě­
řovat žádným jiným certifikátům z důvodu ochrany komuni­
kace VU – EGF během normálního provozu.
11.3.2 Během párování VU – EGF
CSM_206 Během párování s EGF musí celek ve vozidle užívat protokol
popsaný na Obrázek 4 (části 10.2.1) pro ověření řetězce certi­
fikátů vnějšího zařízení GNSS.
Poznámky k Obrázek 4 v této souvislosti:
— Řízení komunikace je mimo rozsah tohoto dodatku. EGF
však není inteligentní karta, a proto VU pravděpodobně
nebude odesílat příkaz resetu pro obnovení komunikace
a nebude přijímat ATR.
— Certifikáty a veřejné klíče karet uvedené na obrázku lze
považovat za certifikáty a veřejné klíče EGF pro
vzájemné ověřování pravosti. V části 9.1.6 jsou označeny
jako EGF_MA.
— Certifikáty a veřejné klíče Card.CA uvedené na obrázku
lze považovat za certifikáty a veřejné klíče MSCA pro
podpis certifikátů EGF. V části 9.1.3 jsou označeny
jako MSCA_VU-EGF.
— Certifikát Card.CA.EUR uvedený na obrázku lze pova­
žovat za evropský kořenový certifikát, který je uveden
v CAR certifikátu MSCA_VU-EGF.
— Certifikát Card.Link uvedený na obrázku lze považovat za
spojovací certifikát EGF, je-li přítomen. Jak je uvedeno
v části 9.1.2, jedná se o spojovací certifikát pro nový
evropský kořenový pár klíčů vytvořený ERCA a pode­
psaný předchozím evropským soukromým klíčem.
— Certifikát Card.Link.EUR je evropský kořenový certifikát,
který je uveden v CAR certifikátu Card.Link.
— Místo musí VU z EF
ICC načíst .
— Místo výběru AID tachografu musí VU zvolit AID EGF.
— Příkaz „Ignore Card“ se považuje za příkaz „Ignore EGF“.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 490
CSM_207 Jakmile celek ve vozidle ověří certifikát EGF_MA, uloží jej
pro užití během normálního provozu; viz bod 11.3.3.
CSM_208 ►M1 Během párování s VU musí vnější zařízení GNSS
používat protokol uvedený na obrázku 5 (bod 10.2.2) pro
ověření řetězců certifikátů VU. ◄
Poznámky k Obrázek 5 v této souvislosti:
— VU musí vygenerovat nový přechodný pár klíčů pomocí
parametrů domény v certifikátu EGF.
— Certifikáty a veřejné klíče VU uvedené na obrázku se
používají pro vzájemné ověřování pravosti. V části 9.1.4
jsou označeny jako VU_MA.
— Certifikáty a veřejné klíče VU.CA uvedené na obrázku se
používají pro podpis certifikátů VU a vnějších zařízení
GNSS. V části 9.1.3 jsou označeny jako MSCA_VU-
EGF.
— Certifikát VU.CA.EUR uvedený na obrázku je evropský
kořenový certifikát, který je uveden v CAR certifikátu
VU.CA.
— Certifikát VU.Link uvedený na obrázku je spojovací certi­
fikát VU, je-li přítomen. Jak je uvedeno v části 9.1.2,
jedná se o spojovací certifikát pro nový evropský koře­
nový pár klíčů vytvořený ERCA a podepsaný předchozím
evropským soukromým klíčem.
— Certifikát VU.Link.EUR je evropský kořenový certifikát,
který je uveden v CAR certifikátu VU.Link.
CSM_209 Odchylně od požadavku CSM_167 musí EGF užívat pro
ověření dočasné platnosti všech předložených certifikátů čas
GNSS.
▼M1
CSM_210 Jakmile vnější zařízení GNSS ověří certifikát VU_MA, musí
jej uložit pro použití během normálního provozu; viz bod
11.3.3.
▼B
11.3.3 Během normálního provozu
CSM_211 ►M1 Během normálního provozu musí celek ve vozidle
a EGF používat protokol uvedený na obrázku 11 pro ověření
dočasné platnosti uloženého certifikátu EGF_MA a pro nasta­
vení veřejného klíče VU_MA pro následné ověření pravosti
VU. Během normálního provozu se žádné další vzájemné
ověření řetězců certifikátů neprovádí. ◄
Všimněte si, že Obrázek 11 v zásadě obsahuje první kroky
uvedené na Obrázek 4 a Obrázek 5. Protože EGF není inte­
ligentní karta, opět platí, že VU pravděpodobně nebude
odesílat příkaz resetu pro zahájení komunikace a nebude
přijímat ATR. Tento postup je v každém případě mimo
rozsah tohoto dodatku.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 491
Obrázek 11
Vzájemné ověření dočasné platnosti certifikátu během normálního provozu VU – EGF
CSM_212 Jak je uvedeno na Obrázek 11, celek ve vozidle zaznamená
chybu, pokud certifikát EGF_MA již není platný. Vzájemné
ověřování pravosti, odsouhlasení klíče a následná komunikace
prostřednictvím bezpečného předávání zpráv však pokračuje
normálně.
11.4. Ověřování pravosti VU,, ověřování pravosti čipu a odsouhlasení klíče
relace
CSM_213 Ověřování pravosti VU, ověřování pravosti čipu a odsouhla­
sení klíče relace mezi VU a EGF se provádí během párování
a při každém obnovení relace bezpečného předávání zpráv
během normálního provozu. VU a EGF musí provádět
postupy popsané v částech 10.3 a 10.4. Platí všechny poža­
davky uvedené v těchto částech.
11.5. Bezpečné předávání zpráv
CSM_214 Všechny příkazy a odezvy vyměňované mezi celkem ve
vozidle a vnějším zařízením GNSS po úspěšném ověření
pravosti čipu a do skončení relace musí být chráněny
bezpečným předáváním zpráv pouze v módu ověřování
pravosti. Platí všechny požadavky v bodě 10.5.
CSM_215 Při přerušení relace bezpečného předávání zpráv mezi VU
a EGF musí VU okamžitě vytvořit novou relaci bezpečného
předávání zpráv, jak je uvedeno v části 11.3.3 a 11.4.
12. PÁROVÁNÍ A KOMUNIKACE VU – SNÍMAČ POHYBU
12.1. Obecné informace
CSM_216 Celek ve vozidle a snímač pohybu musí během párování a za
normálního provozu komunikovat pomocí protokolu rozhraní
uvedeného v [ISO 16844-3] se změnami uvedenými v této
kapitole a v části 9.2.1.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 492
Poznámka: Čtenáři této kapitoly by měli být seznámeni s
obsahem [ISO 16844-3].
12.2. Párování VU – snímač pohybu pomocí různých generací klíčů
Jak je uvedeno v části 9.2.1, hlavní klíč snímače pohybu a všechny
související klíče jsou pravidelně vyměňovány. To znamená, že v kartách
dílny jsou současně až tři klíče AEC K M-WC pro snímač pohybu (násled­
ných generací klíče). Podobně mohou být ve snímačích pohybu až tři
různé druhy šifrování dat na bázi AES (podle následných generací hlav­
ního klíče snímače pohybu K M ). Celek ve vozidle obsahuje pouze jeden
klíč K M-VU pro snímač pohybu.
CSM_217 VU druhé generace a snímač pohybu druhé generace musí být
párovány takto (viz tabulka 6 v [ISO 16844-3]):
1. Karta dílny druhé generace je vložena do VU a VU je
spojen se snímačem pohybu.
2. VU čte všechny dostupné klíče K M-WC z karty dílny,
kontroluje jejich čísla verze klíče a zvolí to, které odpo­
vídá číslu verze klíče VU K M-VU . Není-li odpovídající klíč
K M-WC na kartě dílny, VU přeruší párovací proces a držiteli
karty dílny zobrazí příslušné chybové hlášení.
3. VU vypočítá hlavní klíč snímače pohybu K M z K M-VU
a K M-WC a identifikační klíč K ID zK M , jak je uvedeno
v části 9.2.1.
4. VU odešle snímači pohybu pokyn pro zahájení párovacího
procesu, jak je uvedeno v [ISO 16844-3], a zašifruje
sériové číslo, které získá ze snímače pohybu s identifi­
kačním klíčem K ID . VU vrátí snímači pohybu zašifrované
sériové číslo.
5. Snímač pohybu porovná zašifrované sériové číslo postupně
se všemi zašifrovanými sériovými čísly, která jsou v něm
uložena. Nalezne-li shodu, je pravost VU ověřena. Snímač
pohybu zaznamená generaci K ID používaného VU a vrátí
vyhovující zašifrovanou verzi svého párovacího klíče; tj.
šifrování, které bylo vytvořeno pomocí stejné generace
KM.
6. VU dešifruje párovací klíč pomocí K M , generuje klíč
relace K S , zašifruje jej s párovacím klíčem a výsledek
odešle do snímače pohybu. Snímač pohybu K S dekóduje.
7. VU sestaví párovací informaci podle [ISO 16844-3], zaši­
fruje informaci s párovacím klíčem a výsledek odešle do
snímače pohybu. Snímač pohybu párovací informaci dekó­
duje.
8. Snímač pohybu zašifruje přijatou párovací informaci
s přijatým K S a vrátí ji VU. Ten ověří, zda je tato párovací
informace stejná informace, jakou snímači pohybu odeslal
v předchozím kroku. Pokud ano, znamená to, že snímač
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 493
pohybu použil stejný K S jako VU, a proto v kroku 5
odeslal svůj párovací klíč zašifrovaný se správnou generací
K M . Tím je pravost snímače pohybu ověřena.
Kroky 2 a 5 se liší od standardního procesu v [ISO 16844-3];
ostatní kroky jsou standardní.
Příklad: Předpokládejme, že k párování dojde v prvním roce
platnosti certifikátu ERCA (3); viz Obrázek 2 v bodě 9.2.1.2.
Kromě toho:
— předpokládejme, že snímač pohybu byl vydán v posledním
roce platnosti certifikátu ERCA (1). Bude proto obsahovat
tyto klíče a data:
— N s [1]: své sériové číslo šifrované s generací 1 K ID ,
— N s [2]: své sériové číslo šifrované s generací 2 K ID ,
— N s [3]: své sériové číslo šifrované s generací 3 K ID ,
— K P [1]: svůj párovací klíč generace 1 ( 1 ), šifrovaný
s generací 1 K M ,
— K P [2]: svůj párovací klíč generace 2, šifrovaný s gene­
rací 2 K M ,
— K P [3]: svůj párovací klíč generace 3, šifrovaný s gene­
rací 3 K M ,
— předpokládejme, že karta dílny byla vydána v prvním roce
platnosti certifikátu ERCA (3). Bude proto obsahovat
generaci 2 a generaci 3 klíče K M-WC .
— předpokládejme, že VU je generace 2, obsahující generaci
2 klíče K M-VU .
V tomto případě proběhnou v krocích 2 – 5 tyto operace:
— Krok 2: VU přečte klíče K M-WC generace 2 a generace 3
z karty dílny a zkontroluje jejich čísla verze.
— Krok 3: VU spojí klíč K M-WC generace 2 se svým K M-VU
a vypočítá K M a K ID .
— Krok 4: VU zašifruje sériové číslo, které přijme ze
snímače pohybu, s klíčem K ID .
— Krok 5: Snímač pohybu porovná přijatá data s N s [1]
a nezjistí shodu. Potom porovná data s N s [2] a zjistí
shodu. Dojde k závěru, že VU je generace 2, a proto
odešle zpět K P [2].
▼B
( 1 ) Párovací klíče generace 1, generace 2 a generace 3 mohou být ve skutečnosti stejný klíč
nebo mohou být třemi různými klíči s různými délkami, jak je uvedeno v CSM_117.
02016R0799 — CS — 21.08.2023 — 003.002 — 494
12.3. Párování a komunikace VU – snímač pohybu pomocí AES
CSM_218 Jak je uvedeno v Tabulka 3 v části 9.2.1, všechny klíče
použité v párování celku ve vozidle (druhé generace)
a snímače pohybu a v následné komunikaci jsou klíče AES,
a nikoli klíče TDES dvojité délky podle [ISO 16844-3]. Tyto
klíče AES mohou mít délku 128, 192 nebo 256 bitů. Protože
velikost bloku AES je 16 bajtů, musí být délka šifrované
zprávy násobkem 16 bajtů na rozdíl od 8 bajtů pro TDES.
Některé z těchto zpráv budou navíc použity pro přenos klíčů
AES, jejichž délka může být 128, 192 nebo 256 bitů. Proto se
počet datových bajtů na instrukci v tabulce 5 [ISO 16844-3]
změní, jak je uvedeno v Tabulka 6:
▼M1
Tabulka 6
Počet bajtů otevřeného textu a šifrovaných dat na instrukci podle [ISO 16844-3]
Instrukce
Požadavek/
odpověď
Popis dat
Počet bajtů otevře­
ných dat podle
[ISO 16844-3]
Počet bajtů otevře­
ných dat s použitím
klíčů AES
Počet bajtů otevřených dat
s použitím klíčů AES
s bitovou délkou
128 192 256
10 požadavek Data ověření pravosti
+ číslo souboru
8 8 16 16 16
11 odpověď Data ověření pravosti
+ obsah souboru
16 nebo 32, podle
souboru
16 nebo 32, podle
souboru
32 / 48 32 / 48 32 / 48
41 požadavek Sériové číslo MoS 8 8 16 16 16
41 odpověď Párovací klíč 16 16 / 24 / 32 16 32 32
42 požadavek Klíč relace 16 16 / 24 / 32 16 32 32
43 požadavek Párovací informace 24 24 32 32 32
50 odpověď Párovací informace 24 24 32 32 32
70 požadavek Data ověření pravosti 8 8 16 16 16
80 odpověď Hodnota čítače MoS
+ data ověření
pravosti
8 8 16 16 16
▼B
CSM_219 Párovací informace, které jsou zaslány v instrukcích 43
(žádost VU) a 50 (odpověď MoS), musí být sestaveny, jak
je uvedeno v části 7.6.10 [ISO 16844-3], s tou výjimkou, že
ve schématu šifrování pro párování se místo algoritmu TDES
použije algoritmus AES, což vede ke dvěma šifrováním AES
a doplňování podle CSM_220 se upraví tak, aby byla
dodržena délka bloku AES. Klíč K' p použitý pro toto šifro­
vání musí být generován takto:
— v případě párovacího klíče K P s délkou 16 bajtů: K' p = K P
XOR (N s ||N s )
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 495
— v případě párovacího klíče K P s délkou 24 bajtů: K' p = K P
XOR (N s ||N s ||N s )
— v případě párovacího klíče K P s délkou 32 bajtů: K' p = K P
XOR (N s ||N s ||N s ||N s )
kde N s je 8-bajtové sériové číslo snímače pohybu.
CSM_220 V případě, že délka otevřeného textu (s použitím klíče AES)
není násobkem 16 bajtů, použije se metoda doplňování 2
stanovená v [ISO 9797-1].
Poznámka: V [ISO 16844-3] je počet bajtů otevřeného textu
vždy násobkem 8, proto při použití TDES není doplňování
nutné. Tato část tohoto dodatku nemění definici dat a zpráv
v [ISO 16844-3], proto je třeba použít metodu doplňování.
CSM_221 Pro instrukci 11 a v případě, že musí být šifrován více než
jeden blok, se použije mód řetězení šifrového textu podle
[ISO 10116] s vloženým parametrem m = 1. Použitý IV je:
— pro instrukci 11: 8-bajtový blok ověření pravosti uvedený
v části 7.6.3.3 [ISO 16844-3], doplněný pomocí metody
doplňování 2 podle [ISO 9797-1]; viz rovněž část 7.6.5
a 7.6.6 [ISO 16844-3],
— pro všechny ostatní instrukce, v nichž je přesunuto více
než 16 bajtů, jak je uvedeno v Tabulka 6: „00“ {16}, tj.
šestnáct bajtů s binární hodnotou 0.
Poznámka: Jak je uvedeno v části 7.6.5 a 7.6.6 [ISO
16844-3], když MoS šifruje datové soubory pro zařazení do
instrukce 11, je blok prokázání pravosti:
— použit jako inicializační vektor pro šifrování datových
souborů v módu CBC,
— zašifrován a zařazen jako první blok do dat, která jsou
odeslána do VU.
12.4. Párování VU – snímač pohybu pro různé generace zařízení
CSM_222 Jak je uvedeno v části 9.2.1, snímač pohybu druhé generace
může obsahovat šifrování párovacích dat na bázi TDES
(podle části A tohoto dodatku), které umožňuje párování
snímače pohybu s VU první generace. V tomto případě
musí být VU první generace a snímač pohybu druhé generace
párovány podle části A tohoto dodatku a podle [ISO 16844-
3]. Pro párovací proces lze použít kartu dílny první nebo
druhé generace.
Poznámky:
— Nelze párovat VU druhé generace a snímač pohybu první
generace.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 496
— Pro párování VU druhé generace a snímače pohybu nelze
použít kartu dílny první generace.
13. BEZPEČNOST VZDÁLENÉ KOMUNIKACE PROSTŘEDNICTVÍM
DSRC
13.1. Obecné informace
Jak je uvedeno v dodatku 14, VU pravidelně generuje data vzdáleného
sledování tachografu (RTM) a odesílá tato data (internímu nebo exter­
nímu) zařízení vzdálené komunikace (RCF). Zařízení vzdálené komuni­
kace je odpovědné za odesílání těchto dat přes rozhraní DSRC podle
dodatku 14 do vzdáleného dotazovacího zařízení. Dodatek 1 stanoví,
že data RTM jsou kaskádovým spojením:
šifrovaného vytížení tachografu šifrování otevřeného přenosu dat
tachografu,
bezpečnostních dat DSRC uvedených níže.
Datový formát otevřeného přenosu dat tachografu je uveden v dodatku 1
a dále popsán v dodatku 14. Tato část popisuje strukturu bezpečnostních
dat DSRC; formální specifikace jsou uvedeny v dodatku 1.
CSM_223 Otevřený text předávaný z VU do
zařízení vzdálené komunikace (je-li RCF vůči VU externí
jednotkou) nebo z VU do vzdáleného dotazovacího zařízení
přes rozhraní DSRC (je-li RCF vůči VU interní jednotkou)
musí být chráněna v módu šifrování a následného ověření
pravosti, tj. přenášená data tachografu jsou nejprve šifrována
pro zajištění důvěrnosti zprávy a následně je vypočítán MAC
pro zajištění pravosti a integrity.
CSM_224 Bezpečnostní data DSRC musí obsahovat kaskádové spojení
následujících datových prvků v níže uvedeném pořadí; viz
také Obr. 12:
Aktuální datum čas aktuální datum a čas VU (datový typ ),
Čítač 3-bajtový čítač, viz CSM_225
▼M1
Sériové číslo VU sériové číslo VU nebo identifikátor žádosti o certifikát (datový
typ VuSerialNumber nebo CertificateRequestID) – viz
CSM_123
▼B
Číslo verze hlavního klíče DSRC 1-bajtové číslo verze hlavního klíče DSRC, z něhož se odvo­
zují klíče DSRC pro příslušné VU, viz část 9.2.2.
MAC MAC vypočítaný ze všech předchozích bajtů v datech RTM.
CSM_225 3-bajtový čítač v bezpečnostních datech DSRC musí být ve
formátu MSB-first. Když VU po uvedení do provozu poprvé
vypočítá sadu dat RTM, nastaví hodnotu čítače na 0. Před
každým výpočtem nové sady dat RTM zvýší VU hodnotu dat
čítače o 1.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 497
13.2. Šifrování přenosu dat tachografu a generování MAC
CSM_226 V případě otevřeného datového prvku s datovým typem
podle dodatku 14 musí VU tato
data šifrovat, jak je uvedeno v Obr. 12: Klíč DSRC celku
ve vozidle pro šifrování K_VU DSRC _ENC (viz bod 9.2.2)
musí být použit s AES v operačním módu řetězení šifrového
textu (CBC) podle [ISO 10116] s vloženým parametrem m =
1. Inicializační vektor musí odpovídat hodnotě IV = aktuální
datum čas || „00 00 00 00 00 00 00 00 00“ || čítač, kde
aktuální datum čas a čítač jsou uvedeny v CSM_224. Šifro­
vaná data musí být doplněna pomocí metody 2 podle [ISO
9797-1].
CSM_227 VU musí vypočítat MAC v bezpečnostních datech DSRC, jak
je uvedeno v Obr. 12: MAC se vypočte pro všechny před­
chozí bajty v datech RTM až do čísla verze hlavního klíče
DSRC včetně i včetně tagů a délek datových objektů. VU
použije svůj klíč DSRC pro ověření pravosti
K_VU DSRC _MAC (viz část 9.2.2) s algoritmem AES
v módu CMAC podle [SP 800-38B]. Délka MAC musí být
spojena s délkou klíčů DSRC příslušných VU, jak je uvedeno
v CSM_50.
Obr. 12
Šifrování přenosu dat tachografu a generování MAC
13.3. Ověření a dešifrování přenosu dat tachografu
CSM_228 Když vzdálené dotazovací zařízení přijme data RTM z VU,
musí veškerá data RTM odeslat do kontrolní karty v datovém
poli příkazu PROCESS DSRC MESSAGE, jak je uvedeno
v dodatku 2. Pak:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 498
1. Kontrolní karta zkontroluje číslo verze hlavního klíče
DSRC v bezpečnostních datech DSRC. Pokud kontrolní
karta nezná uvedený hlavní klíč DSRC, oznámí chybu
uvedenou v dodatku 2 a přeruší proces.
▼M1
2. Kontrolní karta použije uvedený hlavní klíč DSRC ve
spojení se sériovým číslem VU nebo identifikátorem
žádosti o certifikát v bezpečnostních datech DSRC pro
odvození klíčů DSRC příslušného celku ve vozidle
K_VU DSRC _ENC a K_VU DSRC _MAC, jak je uvedeno
v CSM_124.
▼B
3. Kontrolní karta použije K_VU DSRC _MAC pro ověření
MAC v bezpečnostních datech DSRC, jak je uvedeno
v CSM_227. Je-li MAC nesprávný, kontrolní karta oznámí
chybu uvedenou v dodatku 2 a přeruší proces.
4. Kontrolní karta použije K_VU DSRC _ENC pro dešifrování
šifrovaného přenosu dat tachografu, jak je uvedeno
v CSM_226. Kontrolní karta musí odstranit doplnění
a vrátit dešifrovaná přenášená data tachografu vzdálenému
dotazovacímu zařízení.
CSM_229 Pro zabránění opakovaným útokům musí vzdálené dotazovací
zařízení zkontrolovat aktuálnost dat RTM ověřením, zda se
aktuální datum čas v bezpečnostních datech DSRC příliš
neodchyluje od aktuálního času vzdáleného dotazovacího
zařízení.
Poznámky:
— To vyžaduje, aby mělo vzdálené dotazovací zařízení
přesný a spolehlivý zdroj času.
— Protože dodatek 14 požaduje, aby VU každých 60 sekund
vypočítal novou sadu dat RTM a hodiny VU se smějí
odlišovat o 1 minutu od skutečného času, je spodní hranice
aktuálnosti dat RTM 2 minuty. Požadovaná aktuálnost
rovněž závisí na přesnosti hodin vzdáleného dotazovacího
zařízení.
CSM_230 Když dílna ověří správnou funkci DSRC celku ve vozidle,
musí veškerá přijatá data RTM odeslat z VU do karty dílny
v datovém poli příkazu PROCESS DSRC MESSAGE, jak je
uvedeno v dodatku 2. Dílna karty musí provést kontroly
a postupy uvedené v CSM_228.
14. PODEPISOVÁNÍ STAžENÝCH DAT A OVĚŘOVÁNÍ PODPISŮ
14.1. Obecné informace
CSM_231 Inteligentní vyhrazené zařízení (IDE) musí uložit data přijatá
z VU nebo karty během jedné relace stahování v jednom
fyzickém datovém souboru. Data mohou být uložena na
ESM (externí paměťové médium). Tento soubor obsahuje
digitální podpisy bloků dat, jak je uvedeno v dodatku 7.
Tento soubor musí rovněž obsahovat tyto certifikáty (viz
část 9.1):
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 499
— v případě stahování VU:
— certifikát VU_Sign,
— certifikát MSCA_VU-EGF obsahující veřejný klíč pro
ověření certifikátu VU_Sign,
— v případě stahování karty:
— certifikát Card_Sign,
— certifikát MSCA_Card obsahující veřejný klíč pro
ověření certifikátu Card_Sign.
CSM_232 IDE musí rovněž zlikvidovat
— v případě, že používá kontrolní kartu pro ověření podpisu
podle Obrázek 13: spojovací certifikát spojující poslední
certifikát EUR s certifikátem EUR, jehož doba platnosti
jej přímo předchází, pokud existuje,
— v případě, že ověřuje samotný podpis: všechny platné
evropské kořenové certifikáty.
Poznámka: Metoda, kterou IDE používá pro získání těchto
certifikátů, není v tomto dodatku stanovena.
14.2. Generování podpisu
CSM_233 Podpisový algoritmus pro vytváření digitálních podpisů staho­
vaných dat musí být ECDSA podle [DSS] s použitím hašo­
vacího algoritmu spojeného s velikostí klíče VU nebo karty,
jak je uvedeno v CSM_50. Formát podpisu musí být otevřený
podle [TR-03111].
14.3. Ověření podpisu
CSM_234 ►M1 IIDE může ověřovat podpis stahovaných dat samo­
statně nebo může k tomuto účelu použít kontrolní kartu.
V případě, že použije kontrolní kartu, provede se ověření
podpisu podle Figure 13. Pro ověření dočasné platnosti certi­
fikátu předloženého IDE kontrolní karta použije svůj interní
aktuální čas, jak je uvedeno v odstavci CSM_167. Kontrolní
karta svůj aktuální čas aktualizuje, je-li datum účinnosti certi­
fikátu s původním platným zdrojem času pozdější než aktu­
ální čas karty. Karta jako platný zdroj času přijme pouze tyto
certifikáty:
— spojovací certifikáty ERCA druhé generace,
— certifikáty MSCA druhé generace,
— certifikáty VU_Sign nebo Card_Sign druhé generace
vydané stejnou zemí jako vlastní certifikát kontrolní karty.
V případě, že ověří podpis samostatně, prokázání pravosti
a platnost všech certifikátů v řetězci certifikátů datového
souboru a podpis dat podle podpisového schématu uvedeného
v [DSS]. V obou případech je u každého certifikátu přečte­
ného z datového souboru potřeba ověřit, zda je pole auto­
rizace držitele certifikátu (CHA) správné:
— V poli CHA certifikátu EQT musí být uveden certifikát
VU, případně karty pro připojení podpisu (viz dodatek 1,
datový typ EquipmentType).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 500
— V poli CHA certifikátu EQT.CA musí být uveden MSCA.
— V poli CHA certifikátu EQT.Link musí být uveden
ERCA. ◄
Poznámky k Obrázek 13:
— zařízení, které podepisovalo analyzovaná data, je ozna­
čeno EQT,
— certifikáty a veřejné klíče EQT uvedené na obrázku se
používají pro podpis, tj. VU_Sign nebo Card_Sign,
— certifikáty a veřejné klíče EQT.CA uvedené na obrázku se
používají pro podpis certifikátů VU nebo karty,
— certifikát EQT.CA.EUR uvedený na obrázku je evropský
kořenový certifikát, který je uveden v CAR certifikátu
EQT.CA,
— certifikát EQT.Link uvedený na obrázku je případný
spojovací certifikát EQT. Jak je uvedeno v části 9.1.2,
jedná se o spojovací certifikát pro nový evropský koře­
nový pár klíčů vytvořený ERCA a podepsaný předchozím
evropským soukromým klíčem,
— certifikát EQT.Link.EUR je evropský kořenový certifikát,
který je uveden v CAR certifikátu EQT.Link.
CSM_235 Pro výpočet hash M odeslané do kontrolní karty v PSO:
příkaz hash, IDE musí používat hašovací algoritmus spojený
s velikostí klíče VU nebo karty, ze kterých jsou stahována
data, jak je uvedeno v CSM_50.
CSM_236 Pro ověření podpisu EQT musí kontrolní karta postupovat
podle podpisového schématu uvedeného v [DSS].
Poznámka: Tento dokument nestanoví žádné opatření pro
případ, kdy nelze ověřit podpis staženého datového souboru
nebo je ověření neúspěšné.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 501
Obrázek 13
Protokol pro ověření podpisu staženého datového souboru
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 502
Dodatek 12
URČOVÁNÍ POLOHY NA ZÁKLADĚ GLOBÁLNÍHO DRUŽICOVÉHO
NAVIGAČNÍHO SYSTÉMU (GNSS)
OBSAH
1. ÚVOD
1.1 Oblast působnosti
▼M3
1.1.1 Odkaz
▼B
1.2 Zkratky a notace
▼M3
2. ZÁKLADNÍ CHARAKTERISTIKY PŘIJÍMAČE GNSS
3. VĚTY POSKYTOVANÉ PŘIJÍMAČEM GNSS
▼B
4. CELEK VE VOZIDLE S VNĚJŠÍM ZAŘÍZENÍM GNSS
4.1 Konfigurace
4.1.1 Hlavní součásti a rozhraní
4.1.2 Stav vnějšího zařízení GNSS po dokončení výroby
4.2 Komunikace mezi vnějším zařízením GNSS a celkem ve vozidle
4.2.1 Komunikační protokol
4.2.2 Zabezpečený přenos údajů GNSS
4.2.3 Struktura příkazu Read Record
▼M3
4.2.4 Struktura příkazu WriteRecord
4.2.5 Jiné příkazy
▼B
4.3 Vazba, vzájemné ověření pravosti a dohoda na klíči relace mezi vnějším
zařízením GNSS a celkem ve vozidle
4.4 Zpracování chyb
4.4.1 Chyba komunikace s vnějším zařízením GNSS
4.4.2 Narušení fyzické integrity vnějšího zařízení GNSS
4.4.3 Chybí informace o poloze z přijímače GNSS
4.4.4 Skončení platnosti certifikátu vnějšího zařízení GNSS
5. CELEK VE VOZIDLE BEZ VNĚJŠÍHO ZAŘÍZENÍ GNSS
5.1 Konfigurace
▼M3
5.2 Přenos informací z přijímače GNSS do celku ve vozidle (VU)
__________
5.3. Přenos informací z celku ve vozidle (VU) do přijímače GNSS
5.4. Zpracování chyb
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 503
5.4.1 Chybí informace o poloze z přijímače GNSS
6. ZPRACOVÁNÍ A ZAZNAMENÁVÁNÍ ÚDAJŮ O POLOZE VU
7. NESOULAD ČASU GNSS
8. NESOULAD ÚDAJŮ O POHYBU VOZIDLA
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:
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
▼B
Obrázek 1
Různé konfigurace přijímače GNSS
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 504
1.2 Zkratky a notace
V tomto dodatku jsou použity tyto zkratky:
DOP parametr přesnosti (Dilution of Precision)
EGF elementární soubor zařízení GNSS (Elementary file GNSS
Facility)
EGNOS Evropská služba pro pokrytí geostacionární navigací (Euro­
pean Geostationary Navigation Overlay Service)
GNSS globální družicový navigační systém (Global Navigation
Satellite System)
GSA GPS DOP a aktivní družice (GPS DOP and active satellites)
HDOP parametr horizontální přesnosti (Horizontal Dilution of Preci­
sion)
ICD kontrolní dokument rozhraní (Interface Control Document)
NMEA Národní asociace pro námořní elektroniku (National Marine
Electronics Association)
▼M3
OSNMA Galileo Open Service Navigation Messages Authentication
(otevřená služba systému Galileo pro ověření pravosti navi­
gačních zpráv)
▼B
PDOP parametr přesnosti polohy (Position Dilution of Precision)
RMC doporučená minimální specifická data (Recommended
Minimum Specific)
▼M3
RTC Real Time Clock (hodiny reálného času)
▼B
SIS signál v kosmu (Signal in Space)
VDOP parametr vertikální přesnosti (Vertical Dilution of Precision)
VU celek ve vozidle (Vehicle Unit)
▼M3
2. ZÁKLADNÍ CHARAKTERISTIKY PŘIJÍMAČE GNSS
▼B
Bez ohledu na konfiguraci inteligentního tachografu s vnějším zařízením
GNSS nebo bez něj je poskytování přesných a spolehlivých informací
o poloze základním prvkem účinného fungování inteligentního tacho­
grafu. Proto je přiměřené požadovat jeho slučitelnost se službami posky­
tovanými v rámci programů Galileo a EGNOS podle nařízení Evrop­
ského parlamentu a Rady (EU) č. 1285/2013 ( 1 ). Systém zavedený
v rámci programu Galileo je nezávislým globálním družicovým navi­
gačním systémem a systém zavedený v rámci programu EGNOS je
regionálním družicovým navigačním systémem zvyšujícím kvalitu
signálu systému GPS (Global Positioning System).
GNS_2 Výrobci zajistí, aby přijímače GNSS v inteligentních tachogra­
fech byly slučitelné se službami určování polohy poskytova­
nými systémy Galileo a EGNOS. Výrobci mohou rovněž navíc
zvolit kompatibilitu s dalšími družicovými navigačními
systémy.
▼B
( 1 ) Nařízení Evropského parlamentu a Rady (EU) č. 1285/2013 ze dne 11. prosince 2013
o zřízení evropských systémů družicové navigace a jejich využití a o zrušení nařízení
Rady (ES) č. 876/2002 a nařízení Evropského parlamentu a Rady (ES) č. 683/2008 (Úř.
věst. L 347, 20.12.2013, s. 1).
02016R0799 — CS — 21.08.2023 — 003.002 — 505
GNS_3 Přijímač GNSS musí být schopen podporovat ověřování navi­
gačních zpráv v otevřené službě systému Galileo (OSNMA).
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í kombinova­
né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 odhado­
vanou 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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 506
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 synchroni­
zaci 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.
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):
Obrázek 2
Struktura věty RMC
$–RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x .x,xxxx,x.x,a,a,a*hh
1) Čas (UTC)
2) Status, A= platná poloha, V= varování
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ě RMC
obsažen.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 507
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):
Obrázek 3
Struktura věty AMC
$–AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
1) Čas (UTC)
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
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 508
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).
Obrázek 4
Struktura věty GSA (standardní polohy)
$–GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h
1) Režim výběru
2) Režim
3) ID prvního satelitu použitého pro určení polohy
4) ID druhého satelitu použitého pro určení polohy
…
14) 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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 509
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.
Obrázek 5
Struktura věty ASA (ověřené polohy)
$–ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h
1) Režim výběru
2) Režim
3) ID prvního satelitu použitého pro určení polohy
4) ID druhého satelitu použitého pro určení polohy
…
14) 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).
▼B
4. CELEK VE VOZIDLE S VNĚJŠÍM ZAŘÍZENÍM GNSS
4.1 Konfigurace
4.1.1 Hlavní součásti a rozhraní
V této konfiguraci je přijímač GNSS součástí vnějšího zařízení GNSS.
GNS_8 Vnější zařízení GNSS musí být napájeno zvláštním vozi­
dlovým rozhraním.
▼M3
GNS_9 Vnější zařízení GNSS obsahuje tyto součásti (viz obrázek 6)
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 510
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 defi­
novanou sadu vět NMEA, která musí zahrnovat přinej­
menším věty RMC, AMC, GSA a ASA. Provedení dato­
vého rozhraní GNSS je volbou výrobce vnějšího zařízení
GNSS.
▼B
b) jednotku přijímače-vysílače (bezpečnostní přijímač-
vysílač GNSS) podporující normu ISO/IEC 7816-4:2013
(viz část 4.2.1) pro komunikaci s celkem ve vozidle
a podporu datového rozhraní GNSS s přijímačem
GNSS. Jednotka je vybavena pamětí pro ukládání iden­
tifikačních údajů přijímače GNSS a vnějšího zařízení
GNSS;
▼M3
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ža­
dovaná v profilu ochrany inteligentního tachografu.
▼B
d) anténu GNSS instalovanou na vozidle a připojenou
k přijímači GNSS skrz systém krytí.
GNS_10 Vnější zařízení GNSS má přinejmenším tato vnější
rozhraní:
a) rozhraní pro anténu GNSS instalovanou na nákladním
vozidle, je-li použita externí anténa;
b) rozhraní s celkem ve vozidle.
GNS_11 V celku ve vozidle je protistranou zabezpečené komunikace
s bezpečnostním přijímačem-vysílačem GNSS bezpečnostní
přijímač-vysílač VU, který musí podporovat normu ISO/
IEC 7816-4:2013, pokud jde o připojení k vnějšímu zaří­
zení GNSS.
GNS_12 Pokud jde o fyzickou vrstvu komunikace s vnějším zaří­
zením GNSS, musí celek ve vozidle podporovat normu
ISO/IEC 7816-12:2005 nebo jiný standard, který podporuje
normu ISO/IEC 7816-4:2013 (viz část 4.2.1).
4.1.2 Stav vnějšího zařízení GNSS po dokončení výroby
GNS_13 Vnější zařízení GNSS při opuštění továrny uchovává
v paměti bezpečnostního přijímače-vysílače GNSS nezá­
vislé na napájení tyto hodnoty:
— pár klíčů EGF_MA a příslušný certifikát,
— certifikát MSCA_VU-EGF obsahující veřejný klíč
MSCA_VU-EGF.PK používaný pro ověření certifikátu
EGF_MA,
— certifikát EUR obsahující veřejný klíč EUR.PK použí­
vaný pro ověření certifikátu MSCA_VU-EGF,
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 511
— certifikát EUR, jehož doba platnosti přímo předchází
době platnosti certifikátu EUR používaného pro ověření
certifikátu MSCA_VU-EGF, pokud existuje,
— spojovací certifikát spojující tyto dva certifikáty EUR,
pokud existuje,
— rozšířené sériové číslo vnějšího zařízení GNSS,
— identifikátor operačního systému zařízení GNSS,
— číslo schválení typu vnějšího zařízení GNSS,
— identifikátor bezpečnostní komponenty vnějšího modulu
GNSS.
4.2 Komunikace mezi vnějším zařízením GNSS a celkem ve vozidle
4.2.1 Komunikační protokol
▼M3
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.
▼B
GNS_15 Komunikační protokol je založen na normě ISO/IEC 7816-
4:2013, přičemž bezpečnostní přijímač-vysílač VU má
nadřazenou roli („master“) a bezpečnostní přijímač-vysílač
GNSS má podřízenou roli („slave“). Fyzické spojení mezi
vnějším zařízením GNSS a celkem ve vozidle je založeno
na normě ISO/IEC 7816-12:2005 nebo na jiném standardu,
který podporuje normu ISO/IEC 7816-4:2013.
▼M1
GNS_16 V komunikačním protokolu nejsou podporována rozšířená
pole délky.
▼B
GNS_17 Komunikační protokol dle ISO 7816 (jak -4:2013, tak
-12:2005) mezi vnějším zařízením GNSS a VU je nastaven
na T=1.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 512
GNS_18 Pokud jde o funkce 1) shromažďování a distribuce údajů
GNSS, 2) shromažďování konfiguračních dat vnějšího zaří­
zení GNSS a 3) protokol správy, bezpečnostní přijímač-
vysílač GNSS simuluje inteligentní kartu s architekturou
systému souborů tvořenou hlavním souborem (MF), vyhra­
zeným souborem (DF) s identifikátorem aplikace stano­
veným v dodatku 1 kapitole 6.2 (‘FF 44 54 45 47 4D’)
a s třemi elementárními soubory (EF) obsahujícími certifi­
káty a jedním samostatným elementárním souborem
(EF.EGF) s identifikátorem souboru rovným ‘2F2F’, jak
popisuje tabulka 1.
▼M3
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.
▼B
GNS_19 Bezpečnostní přijímač-vysílač GNSS ukládá údaje přicháze­
jící z přijímače GNSS a konfiguraci v souboru EF.EGF. Jde
o lineární soubor se záznamy proměnné délky a s identifi­
kátorem rovným „2F2F“ v hexadecimálním formátu.
▼M3
GNS_19a Bezpečnostní přijímač-vysílač GNSS ukládá údaje přicháze­
jí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.
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ů.
▼M1
Mapování čísel záznamů a dat je uvedeno v tabulce 1. Je
třeba mít na paměti, že existuje pět vět GSA pro konstelace
GNSS a systém s družicovým rozšířením (SBAS).
▼B
GNS_21 Strukturu souborů uvádí tabulka 1. Podmínky přístupu
(ALW, NEV, SM-MAC) viz dodatek 2 kapitolu 3.5.
▼M3
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)
Č.
▼M1
02016R0799 — CS — 21.08.2023 — 003.002 — 513
Podmínky přístupu
Soubor ID souboru Čtení Aktualizace Šifrování
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
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 514
Soubor / datový prvek Č. záznamu Velikost (bajty)
Výchozí
hodnoty
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 SensorExter­
nalGNSSSCIdentifier
'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}
▼B
4.2.2 Zabezpečený přenos údajů GNSS
▼M3
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:
▼B
1. byl dokončen proces vytvoření vazby popsaný v dodatku
11. Společné bezpečnostní mechanismy;
2. bylo provedeno periodické vzájemné ověření pravosti
a dohoda na klíči relace mezi celkem ve vozidlem
a vnějším zařízením GNSS, rovněž popsané v dodatku
11. Společné bezpečnostní mechanismy, s uvedenou
frekvencí.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 515
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 iden­
tifiká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čnost­
ní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 inte­
gritu přijaté odpovědi. V případě pozitivního výsledku
jsou údaje o poloze předány procesoru VU prostřednic­
tvím datového rozhraní GNSS.
5. Procesor VU zkontroluje přijaté údaje a extrahuje infor­
mace (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ži­
cových systémů (tj. je-li poloha k dispozici).
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 516
GNS_23a VU musí rovněž podle potřeby zapsat čas RTC VU a maxi­
má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 Maxi­
malTimeDifference
▼B
4.2.3 Struktura příkazu Read Record
Tato část podrobně popisuje strukturu příkazu Read 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_24 Příkaz podporuje režim bezpečného předávání zpráv pouze
s ověřením pravosti, viz dodatek 11.
GNS_25 Zpráva s příkazem
Bajt Délka Hodnota Popis
CLA 1 „0Ch“ Požadavek na bezpečné předávání zpráv
INS 1 „B2h“ Read Record
P1 1 „XXh“ Číslo záznamu („00“ odkazuje na aktu­
ální záznam)
P2 1 „04h“ Čtení záznamu s číslem záznamu
uvedeným v P1
Le 1 „XXh“ Očekávaná délka dat. Počet bajtů ke
čtení.
GNS_26 Záznam, na který odkazuje P1, se stává aktuálním
záznamem.
Bajt Délka Hodnota Popis
#1-#X X „XX..XXh“ Přečtená data
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).
▼M3
— Není-li záznam nalezen, bezpečnostní přijímač-vysílač
GNSS vrátí „6A83“.
— Pokud vnější zařízení GNSS zjistilo nedovolenou mani­
pulaci, vrátí stavová slova „6690“.
__________
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 517
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 mani­
pulaci, 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
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 518
4.3 Vazba, vzájemné ověření pravosti a dohoda na klíči relace mezi
vnějším zařízením GNSS a celkem ve vozidle
Vazba, vzájemné ověření pravosti a dohoda na klíči relace mezi
vnějším zařízením GNSS a celkem ve vozidle jsou popsány v dodatku
11 – Společné bezpečnostní mechanismy, kapitole 11.
4.4 Zpracování chyb
Tato část popisuje, jak jsou v celku ve vozidle zpracovávány a zazna­
menávány potenciální chybové stavy vnějšího zařízení GNSS.
4.4.1 Chyba komunikace s vnějším zařízením GNSS
▼M3
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ža­
davku 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 odpo­
vědí po zprávě s požadavkem, jak je popsáno v bodě 4.2.
▼B
4.4.2 Narušení fyzické integrity vnějšího zařízení GNSS
▼M3
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“.
▼B
4.4.3 Chybí informace o poloze z přijímače GNSS
▼M3
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 obsa­
hují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 (EventFault­
Type).
▼B
4.4.4 Skončení platnosti certifikátu vnějšího zařízení GNSS
▼M3
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.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 519
Obrázek 6
Schéma vnějšího zařízení GNSS
▼B
5. CELEK VE VOZIDLE BEZ VNĚJŠÍHO ZAŘÍZENÍ GNSS
5.1 Konfigurace
V této konfiguraci je přijímač GNSS uvnitř celku ve vozidle, jak
popisuje obrázek 1.
▼M3
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 podob­
ných uvedených v GNS_4, GNS_4a a GNS_5.
▼B
GNS_33 K celku ve vozidle je připojena externí anténa GNSS insta­
lovaná na vozidle nebo interní anténa GNSS.
▼M3
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 infor­
mace (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 zazname­
ná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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 520
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 infor­
mací o poloze z přijímače GNSS podle definice v poža­
davku 81 v příloze IC a dodatku 1 (EventFaultType).
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 vodo­
rovné 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 rela­
tivní 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 apli­
kaci, σ UERE = použije se 10 metrů.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 521
— 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ňu­
jí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).
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 inter­
ní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:
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 522
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:
[OdometerDifference×OdometerToleranceFactor+Minimum
(SlipDistanceUpperlimit;(OdometerDifference×Slip­
Factor))+GnssTolerance+FerryTrainDistance]
kde:
— 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),
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 523
— Minimální (SlipDistanceUpperLimit; (OdometerDiffe­
rence * 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 Slip­
Factor (maximální vliv podklouznutí při brzdění)
roven 0,2,
— FerryTrainDistance se vypočítá jako: FerryTrainDis­
tance = 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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 524
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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 525
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 Interconnec­
tion)
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řednic­
tví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 Blue­
tooth®. 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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 526
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.
Obrázek 1
Rozdělování komunikace prostřednictvím rozhraní ITS podle vrstev modelu OSI
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 kabe­
lové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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 527
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
ot
vo
r
pr
o
ka
rt
u
dr
uh
éh
o
ři
di
č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
Přidělení připojení ITS Blue­
tooth®
otvor pro kartu řidiče
žádná karta karta řidiče kontrolní karta karta dílny karta podniku
ot
vo
r
pr
o
ka
rt
u
dr
uh
éh
o
ři
di
če

žádná karta není k dispozici karta řidiče kontrolní karta karta dílny karta podniku
karta řidiče karta řidiče karta řidiče (**) kontrolní karta karta dílny karta podniku
kontrolní karta kontrolní karta kontrolní karta kontrolní
karta (*)
není k dispozici není k dispozici
karta dílny karta dílny karta dílny není k dispozici karta dílny (*) není k dispozici
karta podniku karta podniku karta podniku není k dispozici není k dispozici karta podniku (*)
(*) Spojení ITS Bluetooth® se přidělí kartě tachografu v otvoru VU pro kartu řidiče.
(**) 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).
ITS_15 Je-li karta tachografu vyjmuta, VU ukončí připojení ITS Blue­
tooth®, 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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 528
3.4 Dostupné údaje a potřeba souhlasu řidiče
ITS_18 Všechny údaje tachografu dostupné prostřednictvím služeb uvede­
ný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č
VehicleIdentification­
Number
Dodatek 8 VU neosobní neosobní souhlas není
nutný
povinné
CalibrationDate ISO 16844-7 VU neosobní neosobní souhlas není
nutný
povinné
TachographVehicle­
Speed
ISO 16844-7 VU osobní neuvádí se souhlas řidiče povinné
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 529
Název údaje Formát údaje Zdroj
Klasifikace údajů (osobní/neosobní)
Souhlas s dostupností
údajů
Dostupnost
řidič druhý řidič
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é
Driver1TimeRelated­
States
ISO 16844-7 VU osobní neuvádí se souhlas řidiče povinné
Driver2TimeRelated­
States
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é
HighResolutionTotal­
VehicleDistance
ISO 16844-7 VU neosobní neosobní souhlas není
nutný
povinné
HighResolutionTrip­
Distance
ISO 16844-7 VU neosobní neosobní souhlas není
nutný
povinné
ServiceComponentI­
dentification
ISO 16844-7 VU neosobní neosobní souhlas není
nutný
povinné
ServiceDelayCalendar­
TimeBased
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é
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 530
Název údaje Formát údaje Zdroj
Klasifikace údajů (osobní/neosobní)
Souhlas s dostupností
údajů
Dostupnost
řidič druhý řidič
NextCalibrationDate Dodatek 8 VU neosobní neosobní souhlas není
nutný
povinné
Driver1ContinuousDri­
vingTime
ISO 16844-7 VU osobní neuvádí se souhlas řidiče povinné
Driver2ContinuousDri­
vingTime
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
povinné
Driver1CumulativeBre­
akTime
ISO 16844-7 VU osobní neuvádí se souhlas řidiče povinné
Driver2CumulativeBre­
akTime
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
povinné
Driver1CurrentDurati­
onOfSelectedActivity
ISO 16844-7 VU osobní neuvádí se souhlas řidiče povinné
Driver2CurrentDurati­
onOfSelectedActivity
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é
Driver1CumulatedDri­
vingTimePreviousAnd­
CurrentWeek
ISO 16844-7 VU osobní neuvádí se souhlas řidiče povinné
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 531
Název údaje Formát údaje Zdroj
Klasifikace údajů (osobní/neosobní)
Souhlas s dostupností
údajů
Dostupnost
řidič druhý řidič
Driver2CumulatedDri­
vingTimePreviousAnd­
CurrentWeek
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é
RegisteringMember­
State
Dodatek 8 VU neosobní neosobní souhlas není
nutný
povinné
VehicleRegistration­
Number
Dodatek 8 VU neosobní neosobní souhlas není
nutný
povinné
Driver1EndOfLastDa­
ilyRestPeriod
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2EndOfLastDa­
ilyRestPeriod
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1EndOfLast­
WeeklyRestPeriod
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2EndOfLast­
WeeklyRestPeriod
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1EndOfSecond­
LastWeeklyRestPeriod
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2EndOfSecond­
LastWeeklyRestPeriod
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1TimeLastLo­
adUnloadOperation
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2TimeLastLo­
adUnloadOperation
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1CurrentDaily­
DrivingTime
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2CurrentDaily­
DrivingTime
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1CurrentWeekly­
DrivingTime
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2CurrentWeekly­
DrivingTime
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 532
Název údaje Formát údaje Zdroj
Klasifikace údajů (osobní/neosobní)
Souhlas s dostupností
údajů
Dostupnost
řidič druhý řidič
Driver1TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1CardExpiry­
Date.
ISO 16844-7 Karta
řidiče
osobní neuvádí se souhlas řidiče nepovinné
Driver2CardExpiry­
Date
ISO 16844-7 Karta
řidiče
neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1CardNextMan­
datoryDownloadDate
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2CardNextMan­
datoryDownloadDate
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
TachographNextMan­
datoryDownloadDate
ISO 16844-7 VU neosobní neosobní souhlas není
nutný
nepovinné
Driver1TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1NumberOf­
Times9hDailyDriving­
TimesExceeded
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2NumberOf­
Times9hDailyDriving­
TimesExceeded
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1Cumulative
UninterruptedRestTime
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2Cumulative
UninterruptedRestTime
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1MinimumDa­
ilyRest
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2MinimumDa­
ilyRest
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 533
Název údaje Formát údaje Zdroj
Klasifikace údajů (osobní/neosobní)
Souhlas s dostupností
údajů
Dostupnost
řidič druhý řidič
Driver1MinimumWee­
klyRest
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2MinimumWee­
klyRest
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1MaximumDa­
ilyPeriod
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2MaximumDa­
ilyPeriod
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1MaximumDa­
ilyDrivingTime
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2MaximumDa­
ilyDrivingTime
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1NumberOfUse­
dReducedDailyRestPe­
riods
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2NumberOfUse­
dReducedDailyRestPe­
riods
ISO 16844-7 VU neuvádí se osobní souhlas druhého
řidiče
nepovinné
Driver1RemainingCur­
rentDrivingTime
ISO 16844-7 VU osobní neuvádí se souhlas řidiče nepovinné
Driver2RemainingCur­
rentDrivingTime
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é
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 534
Dodatek 14
FUNKCE DÁLKOVÉ KOMUNIKACE
OBSAH
1 ÚVOD
2 ROZSAH
3 ZKRATKY, DEFINICE A ZNAČENÍ
4 OPERAČNÍ SCÉNÁŘE
4.1 Přehled
4.1.1 Podmínky přenosu dat pomocí rozhraní 5,8 GHz DSRC
4.1.2 Profil 1a: pomocí čtečky komunikačního zařízení včasného dálkového
odhalování nasměrovaného ručně nebo dočasně namontovaného
a nasměrovaného u silnice
4.1.3 Profil 1b: pomocí čtečky komunikačního zařízení včasného dálkového
odhalování namontovaného a nasměrovaného na vozidle
4.2 Zabezpečení/integrita
5 STRUKTURA A PROTOKOLY DÁLKOVÉ KOMUNIKACE
5.1 Struktura
5.2 Vývojový diagram
5.2.1 Činnosti
5.2.2 Interpretace dat přijímaných prostřednictvím komunikace DSRC
5.3 Parametry fyzického rozhraní DSRC pro dálkovou komunikaci
5.3.1 Omezení umístění
5.3.2 Parametry downlinku a uplinku
5.3.3 Konstrukce antény
5.4 Požadavky protokolu DSRC pro RTM
5.4.1 Přehled
5.4.2 Příkazy
5.4.3 Pořadí dotazovacích příkazů
5.4.4 Struktury dat
5.4.5 Prvky RTMData, provedené akce a definice
5.4.6 Mechanismus přenosu dat
5.4.7 Podrobný popis transakce DSRC
5.4.8 Popis transakce testu DSRC
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 535
5.5 Vyhrazeno pro budoucí použití
▼B
5.6 Přenos dat mezi DSRC-VU a VU
5.6.1 Fyzické spojení a rozhraní
5.6.2 Protokol aplikace
5.7 Řešení chyb
5.7.1 Záznamy a komunikace dat v DSRC-VU
5.7.2 Chyby bezdrátové komunikace
6 UVEDENÍ DO PROVOZU A PRAVIDELNÉ KONTROLNÍ TESTY
PRO FUNKCE DÁLKOVÉ KOMUNIKACE OBECNÉ INFORMACE
6.1 Obecné informace
6.2 ECHO
6.3 Testy validace obsahu zabezpečených dat
1 ÚVOD
Tento dodatek specifikuje koncepci a postupy provádění funkce dálkové
komunikace (dále jen komunikace) podle článku 9 nařízení (EU)
č. 165/2014 (dále jen nařízení).
DSC_1 Nařízení (EU) č. 165/2014 stanoví, že tachograf musí být
vybaven funkcí dálkové komunikace, která musí zástupcům
příslušných kontrolních orgánů umožnit číst informace tacho­
grafu z projíždějících vozidel pomocí dálkového dotazovacího
zařízení (čtecí komunikační zařízení včasného dálkového odha­
lování [REDCR]), konkrétně dotazovacího zařízení s bezdrá­
tovým připojením pomocí rozhraní CEN 5,8 GHz vyhrazených
komunikací krátkého dosahu (DSRC).
Je třeba zdůraznit, že tato funkce je určena pouze pro před­
běžné třídění, které identifikuje vozidla pro podrobnější
kontrolu, a nenahrazuje formální kontrolní postup podle usta­
novení nařízení (EU) č. 165/2014. Viz 9. bod odůvodnění
v preambuli tohoto nařízení, kde se uvádí, že dálková komu­
nikace mezi tachografem a kontrolními orgány pro účely
silniční kontroly usnadňuje cílené silniční kontroly.
DSC_2 Data se vyměňují prostřednictvím komunikace s použitím
bezdrátového přenosu DSRC 5,8 GHz odpovídajícího tomuto
dodatku a testovaného na příslušné parametry normy EN 300
674-1, {Electromagnetic compatibility and Radio spectrum
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 536
Matters (ERM); Road Transport and Traffic Telematics
(RTTT); Dedicated Short Range Communication (DSRC)
transmission equipment (500 kbit/s / 250 kbit/s) operating in
the 5,8 GHz Industrial, Scientific and Medical (ISM) band;
Part 1: General characteristics and test methods for Road
Side Units (RSU) and On -Board Units (OBU)}.
DSC_3 Komunikace je prostřednictvím komunikačního zařízení navá­
zána pouze v případě, že je zařízením příslušného kontrolního
orgánu vyžádána pomocí radiokomunikačních prostředků
splňujících požadavky (čtečkou komunikačního zařízení včas­
ného dálkového odhalování (REDCR)).
DSC_4 Pro zajištění integrity musí být data zabezpečená.
DSC_5 Přístup ke sdělovaným datům mají pouze příslušné kontrolní
orgány pověřené kontrolou porušování nařízení (ES)
č. 561/2006 a nařízení (EU) č. 165/2014 a dílny, pokud je
to nutné k ověření správného fungování tachografu.
DSC_6 Data vyměňovaná v průběhu komunikace se musí omezit na
data nezbytně nutná pro účely cílených silničních kontrol
vozidel s potenciálně zmanipulovaným či zneužitým
tachografem.
DSC_7 Integrita a bezpečnost dat je zaručena zabezpečením dat
v celku ve vozidle (VU) a předáváním pouze zabezpečených
přenášených dat a bezpečnostních dat (viz 5.4.4) prostřednic­
tvím bezdrátového zařízení dálkové komunikace 5,8 GHz
DSRC, což znamená, že prostředky k porozumění datům před­
ávaným komunikací a k ověření jejich pravosti mají pouze
pověřené osoby příslušných kontrolních orgánů. Viz dodatek
11 Společné bezpečnostní mechanismy.
DSC_8 Data musí obsahovat časové razítko okamžiku poslední
aktualizace.
DSC_9 Obsah bezpečnostních dat je zpřístupněn pouze příslušným
kontrolním orgánům a pod jejich kontrolou a stranám, se
kterými sdílejí tyto informace, a je mimo rámec opatření
komunikace, která je předmětem tohoto dodatku, kromě
případů, kdy tato komunikace s každým balíčkem přenášených
dat zajišťuje přenos balíčku bezpečnostních dat.
DSC_10 Stejnou architekturu a zařízení podle tohoto dodatku musí být
možné používat pro získávání dalších datových koncepcí
(např. vážení na palubě).
DSC_11 Je třeba zdůraznit, že v souladu s ustanoveními nařízení (EU)
č. 165/2014 (článek 7) nesmějí být prostřednictvím komuni­
kace sdělovány údaje týkající se totožnosti řidiče.
2 ROZSAH
Rozsah tohoto dodatku je omezen na stanovení podmínek, za jakých
zástupci příslušných kontrolních orgánů používají specifikovanou
bezdrátovou komunikaci 5,8 GHz DSRC pro získávání údajů (dat) na
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 537
dálku ze zaměřeného vozidla, která ukazují, že zaměřené vozidlo poten­
ciálně porušuje nařízení (EU) č. 165/2014 a měla by být zvážena
možnost jeho zastavení pro další šetření.
Nařízení (EU) č. 165/2014 požaduje, aby se shromažďovaná data
omezovala pouze na údaje nebo se týkala údajů, které identifikují poten­
ciální přestupek, jak je uvedeno v článku 9 nařízení (EU) č. 165/2014.
▼M1
V tomto scénáři je čas vyhrazený pro komunikaci omezený, protože
komunikace je cílená a má krátký dosah. Stejné komunikační prostředky
pro dálkové sledování tachografů (RTM) mohou navíc příslušné
kontrolní orgány používat pro další aplikace (např. maximální hmotnosti
a rozměry těžkých nákladních vozidel podle směrnice (EU) 2015/719)
a tyto operace mohou být podle rozhodnutí příslušných kontrolních
orgánů izolované nebo sekvenční.
▼B
Tento dodatek specifikuje:
— Komunikační zařízení, postupy a protokoly používané pro komuni­
kaci
— Normy a předpisy, které musí rádiové zařízení splňovat
— Předkládání dat komunikačnímu zařízení
— Dotazovací a stahovací postupy a posloupnost operací
— Data k přenosu
— Potenciální výklad dat přenášených při komunikaci
— Poskytování bezpečnostních dat v souvislosti s komunikací
— Dostupnost dat příslušným kontrolním orgánům
— Jak může čtečka komunikačního zařízení včasného dálkového odha­
lování požadovat různé druhy dat týkajících se nákladu a vozového
parku
Pro upřesnění, tento dodatek nestanoví:
— Postup a řízení sběru dat v celku ve vozidle (které jsou funkcí
konstrukce výrobku, pokud nejsou stanoveny jinde v nařízení (EU)
č. 165/2014)
— Formu poskytování získaných dat zástupci příslušného kontrolního
orgánu ani kritéria, která příslušné kontrolní orgány používají při
rozhodování o tom, jaká vozidla mají zastavit (která jsou funkcí
konstrukce výrobku, pokud nejsou stanovena jinde v nařízení (EU)
č. 165/2014 nebo politickým rozhodnutím příslušných kontrolních
orgánů). Je třeba zdůraznit, že komunikace pouze poskytuje data
příslušným kontrolním orgánům, aby tyto orgány mohly provádět
informovaná rozhodnutí.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 538
— Bezpečnostní podmínky dat (např. šifrování) týkající se obsahu dat
(které jsou stanoveny v dodatku 11 – Společné bezpečnostní
mechanismy.
— Podrobnosti jiných koncepcí dat než RTM, která lze získávat pomocí
stejné architektury a zařízení.
— Podrobnosti chování a řízení mezi VU a DSRC-VU ani chování
v rámci DSRC-VU (jiného než poskytování dat v případě vyžádání
ze strany REDCR).
3 ZKRATKY, DEFINICE A ZNAČENÍ
V tomto dodatku se používají tyto specifické zkratky a definice:
Anténa Elektrické zařízení, které přeměňuje
elektrickou energii na rádiové vlny
a opačně, používané ve spojení
s rádiovým vysílačem nebo rádi­
ovým přijímačem. Při vysílání
rádiový vysílač předává na anténní
svorky elektrický proud oscilující
s určitou rádiovou frekvencí a anténa
vyzařuje energii proudu ve formě
elektromagnetického vlnění (rádiové
vlny). Při přijímání anténa zachycuje
určitou energii elektromagnetické
vlny a vytváří na svých svorkách
mírné napětí, které je předáváno
přijímači, kde se zesiluje.
Komunikace Výměna informací/dat mezi
DSRC-REDCR a DSRC-VU podle
části 5 na základě vztahu hlavní
jednotka – vedlejší jednotka za
účelem získání dat.
Data Zabezpečená data definovaného
formátu (viz 5.4.4) požadovaná ze
strany DSRC-REDCR a poskytovaná
DSRC-REDCR celkem ve vozidle
DSRC-VU prostřednictvím spojení
5,8 GHz DSRC podle bodu 5 níže.
Nařízení (EU) č. 165/2014 Nařízení Evropského parlamentu
a Rady (EU) č. 165/2014 ze dne
4. února 2014 o tachografech
v silniční dopravě, o zrušení naří­
zení Rady (EHS) č. 3821/85 o zázna­
movém zařízení v silniční dopravě
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 539
a o změně nařízení Evropského
parlamentu a Rady (ES) č. 561/2006
o harmonizaci některých předpisů
v sociální oblasti týkajících se
silniční dopravy
AID identifikátor aplikace
BLE bluetooth s nízkou energií
BST servisní tabulka signálů
CIWD vložení karty během řízení
CRC kontrola cyklickým kódem
DSC (n) identifikátor požadavku na speci­
fický dodatek DSRC
DSRC vyhrazené spojení krátkého dosahu
DSRC-REDCR čtečka komunikačního zařízení včas­
ného dálkového odhalování DSRC
DSRC-VU celek ve vozidle DSRC. Toto je
„zařízení včasného dálkového odha­
lování“ definované v příloze 1C.
DWVC jízda bez platné karty
EID identifikátor prvku
LLC kontrola logického spojení
LPDU datová jednotka protokolu LLC
OWS palubní vážicí systém
PDU datová jednotka protokolu
REDCR čtečka komunikačního zařízení včas­
ného dálkového odhalování Toto je
„čtečka komunikačního zařízení
včasného dálkového odhalování“
definované v příloze 1C.
RTM dálkové sledování tachografů
SM-REDCR bezpečnostní modul – čtečka komu­
nikačního zařízení včasného dálko­
vého odhalování
TARV telematické aplikace pro regulovaná
vozidla (řada norem ISO 15638)
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 540
VU celek ve vozidle
VUPM paměť přenášených dat celku ve
vozidle
VUSM bezpečnostní modul celku ve
vozidle
VST servisní tabulka vozidla
WIM vážení za jízdy
WOB vážení na palubě
Specifikace definovaná v tomto dodatku odkazuje na všechny následující
předpisy a normy nebo jejich části a je na nich závislá. V rámci usta­
novení tohoto dodatku jsou specifikovány příslušné normy nebo
příslušná ustanovení norem. V případě jakýchkoli rozporů mají přednost
ustanovení tohoto dodatku. V případě jakýchkoli rozporů, k nimž se
tento dodatek jasně nevyjadřuje, má přednost postup podle ERC 70-03
(s kontrolou příslušných parametrů EN 300 674-1), v sestupném pořadí
důležitosti podle EN 12795, EN 12253 EN 12834 a EN 13372, 6.2, 6.3,
6.4 a 7.1.
Předpisy a normy, na které odkazuje tento dodatek, jsou:
[1] Nařízení (EU) č. 165/2014 ze dne 4. února 2014 o tachografech
v silniční dopravě, o zrušení nařízení Rady (EHS) č. 3821/85
o záznamovém zařízení v silniční dopravě a o změně nařízení
Evropského parlamentu a Rady (ES) č. 561/2006 o harmonizaci
některých předpisů v sociální oblasti týkajících se silniční dopravy.
[2] Nařízení Evropského parlamentu a Rady (ES) č. 561/2006 o harmo­
nizaci 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 (Text
s významem pro EHP).
[3] ERC 70-03 CEPT: ECC Recommendation 70-03: Relating to the
Use of Short Range Devices (SRD)
[4] ISO 15638 Intelligent transport systems — Framework for coope­
rative telematics applications for regulated commercial freight
vehicles (TARV).
[5] EN 300 674-1 Electromagnetic compatibility and Radio spectrum
Matters (ERM); Road Transport and Traffic Telematics (RTTT);
Dedicated Short Range Communication (DSRC) transmission
equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz Indu­
strial, Scientific and Medical (ISM) band; Part 1: General charac­
teristics and test methods for Road Side Units (RSU) and On-Board
Units (OBU).
[6] EN 12253 Road transport and traffic telematics – Dedicated
short-range communication – Physical layer using microwave at
5.8 GHz.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 541
[7] EN 12795 Road transport and traffic telematics – Dedicated
short-range communication – Data link layer: medium access and
logical link control.
[8] EN 12834 Road transport and traffic telematics – Dedicated
short-range communication – Application layer.
[9] EN 13372 Road transport and traffic telematics – Dedicated
short-range communication – Profiles for RTTT applications
[10] ISO 14906 Electronic fee collection — Application interface defi­
nition for dedicated short- range communication
4 OPERAČNÍ SCÉNÁŘE
4.1 Přehled
Nařízení (EU) č. 165/2014 stanoví specifické a kontrolované scénáře,
v nichž má být komunikace používána.
Podporované scénáře:
„Communication Profile 1: Roadside inspection using a short range
wireless communication Remote Early Detection Communication Reader
instigating a physical roadside inspection (master-:-slave)
Reader Profile 1a: pomocí komunikačního zařízení včasného dálkového
odhalování nasměrovaného ručně nebo dočasně namontovaného
a nasměrovaného u silnice
Reader Profile 1b: via a vehicle mounted and directed Remote Early
Detection Communication Reader“.
4.1.1 Podmínky přenosu dat pomocí rozhraní 5,8 GHz DSRC
POZNÁMKA: Pro znázornění příslušných souvislostí je komunikační
zařízení zobrazeno na obrázku 14.3 níže.
4.1.1.1 Data uchovávaná ve VU
DSC_12 VU odpovídá za aktualizaci každých 60 sekund a uchovávání
v něm uložených dat nezávisle na komunikační funkci DSRC.
Způsob, jakým je tohoto cíle dosaženo, je vnitřní funkcí VU
specifikovanou v nařízení (EU) č. 165/2014, příloze 1 C, bodě
3.19 „Dálková komunikace pro cílené silniční kontroly“ a není
specifikován v tomto dodatku.
4.1.1.2 Data předávaná zařízení DSRC-VU
DSC_13 VU odpovídá za aktualizaci dat tachografu DSRC (data),
kdykoli jsou data uložená ve VU aktualizována, v intervalu
stanoveném v 4.1.1.1 (DSC_12) nezávisle na komunikační
funkci DSRC.
DSC_14 Základem získávání a aktualizace dat jsou data VU, a způsob,
jakým je toho dosaženo, je uveden v příloze 1 C bodě 3.19
„Dálková komunikace pro cílené silniční kontroly“, nebo
pokud příslušné informace uvedeny nejsou, je funkcí
konstrukce výrobku a není v tomto dodatku uveden. Způsob
spojení mezi zařízením DSRC-VU a VU je uveden v části 5.6.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 542
4.1.1.3 Obsah údajů
DSC_15 Obsah a formát dat musí být po dekódování strukturované
a dostupné ve formě a formátu uvedeném v bodě 5.4.4 tohoto
dodatku (Struktury dat).
4.1.1.4 Předkládání údajů
DSC_16 Data, která jsou často aktualizována v souladu s postupy podle
bodu 4.1.1.1, musí být zajištěna před prezentací systému
DSRC-VU a předložena jako hodnota zabezpečeného systému
dat pro dočasné uložení v DSRC-VU jako aktuální verze dat.
Tato data jsou přenesena z VUSM do DSRC funkce VUPM.
VUSM a VUPM jsou funkce, a nikoli nutně fyzikální veličiny.
Forma fyzické realizace pro provádění těchto funkcí je záleži­
tostí návrhu výrobku, pokud nejsou uvedeny jinde v naří­
zení (EU) č. 165/2014.
4.1.1.5 Bezpečnostní data
▼M3
DSC_17 Bezpečnostní data (DSRCSecurityData), obsahující údaje poža­
dované REDCR pro účely dekódování dat, jsou poskytována
v souladu s dodatkem 11 – Společné bezpečnostní mecha­
nismy – pro dočasné uložení v DSRC-VU jako aktuální
verze DSRCSecurityData, ve formě stanovené v tomto dodatku
části 5.4.4.
▼B
4.1.1.6 Data VUPM určená k přenosu pomocí rozhraní DSRC
DSC_18 Systém dat, který musí být ve vždy dostupný ve funkci DSRC
VUPM pro okamžitý přenos na požádání ze strany REDCR, je
definován v části 5.4.4 pro úplné specifikace modulu ASN.1.
Obecný přehled komunikačního profilu 1
Tento profil se vztahuje na případ použití, kdy pověřená osoba přísluš­
ného kontrolního orgánu používá komunikační zařízení včasného dálko­
vého odhalování s dálkovým spojením krátkého dosahu (rozhraní 5,8
GHz DSRC pracující v rozsahu ERC 70-03 a testované pro příslušné
parametry EN 300 674-1, jak je popsáno v oddílu 5) (REDCR) pro
dálkovou identifikaci vozidel, která potenciálně porušují nařízení (EU)
č. 165/2014. Po této identifikaci pověřená osoba příslušného kontrolního
orgánu, která kontroluje dotazování, rozhodne, zda má být vozidlo
zastaveno.
4.1.2 Profil 1a: pomocí čtečky komunikačního zařízení včasného dálkového
odhalování nasměrovaného ručně nebo dočasně namontovaného
a nasměrovaného u silnice
V tomto případě použití se pověřená osoba příslušného kontrolního
orgánu nachází na silnici a zaměřuje REDCR držené v ruce, namonto­
vané na stativu nebo jinak přenosné ze silnice do středu předního okna
cíleného vozidla. Dotazování se provádí pomocí rozhraní 5,8 GHz
DSRC pracujícího v rozsahu ERC 70-03 a testovaného pro příslušné
parametry EN 300 674-1, jak je popsáno v oddílu 5. Viz obrázek
14.1 (případ použití 1).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 543
Obrázek 14.1
Sledování ze silnice pomocí 5,8 GHz DSRC
4.1.3 Profil 1b: pomocí čtečky komunikačního zařízení včasného dálkového
odhalování namontovaného a nasměrovaného na vozidle
V tomto případě použití se pověřená osoba příslušného kontrolního
orgánu nachází v jedoucím vozidle, a buď zaměřuje přenosné REDCR
držené v ruce z vozidla do středu předního skla cíleného vozidla, nebo je
REDCR namontováno uvnitř vozidla nebo na něm tak, aby směřovalo do
středu předního skla cíleného vozidla, je-li vozidlo s čtečkou komuni­
kačního zařízení včasného dálkového odhalování v příslušné poloze vůči
cílenému vozidlu (např. přímo před ním ve směru jízdy). Dotazování se
provádí pomocí rozhraní 5,8 GHz DSRC pracujícího v rozsahu ERC 70-
03 a testovaného pro příslušné parametry EN 300 674-1, jak je popsáno
v oddílu 5. Viz obrázek 14.2. (Případ použití 2).
Obrázek 14.2
Sledování z vozidla pomocí 5,8 GHz DSRC
4.2 Zabezpečení/integrita
Aby bylo možné ověřovat pravost a integritu stahovaných dat pomocí
dálkové komunikace, jsou zabezpečená data ověřována a dešifrována
v souladu s dodatkem 11 – Společné bezpečnostní mechanismy.
5 STRUKTURA A PROTOKOLY DÁLKOVÉ KOMUNIKACE
5.1 Struktura
Struktura funkce dálkové komunikace v inteligentním tachografu je
znázorněna a popsána na obrázku 14.3.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 544
Obrázek 14.3
Struktura funkce dálkové komunikace
DSC_19 Ve VU jsou umístěny tyto funkce:
— Bezpečnostní modul (VUSM). Tato funkce ve VU je odpo­
vědná za zabezpečení dat, která mají být přenesena
z DSRC-VU k pověřené osobě příslušného kontrolního
orgánu prostřednictvím dálkové komunikace.
— Zabezpečená data jsou uložena v paměti VUSM. V inter­
valech stanovených v 4.1.1.1 (DSC_12) VU šifruje
a doplňuje systém RTMdata (který obsahuje přenášená
data a hodnoty zabezpečeného systému dat stanovené
níže v tomto dodatku) uchovávaný v paměti DSRC-VU.
Provoz bezpečnostního modulu je definován v dodatku
11– Společné bezpečnostní mechanismy – a mimo rozsah
tohoto dodatku s výjimkou případů, kdy bude třeba
poskytnout aktualizace komunikačnímu zařízení VU při
každé změně dat VUSM.
— Komunikace mezi VU a DSRC-VU může být drátová
komunikace nebo komunikace bluetooth s nízkým
napětím (BLE) a fyzické umístění DSRC-VU může být
totožné s anténou na čelním skle vozidla, může být vnitřní
částí VU nebo jakékoli přechodné umístění.
— DSRC-VU musí mít trvalý spolehlivý zdroj napájení.
Prostředky, kterými je toho dosaženo, jsou konstrukčním
rozhodnutím.
— Paměť DSRC-VU musí být stálá, aby se data na
DSRC-VU uchovala, i když je zapalování vozidla vypnuto.
— Je-li komunikace mezi VU a DSRC-VU realizována
pomocí BLE a zdrojem energie je jednorázově použitelná
baterie, musí být zdroj energie DSRC-VU vyměněn při
každé pravidelné kontrole a výrobce zařízení DSRC-VU
je odpovědný za to, aby byl tento zdroj energie dostatečný
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 545
na dobu od jedné pravidelné kontroly k další a byl zajištěn
normální přístup k datům prostřednictvím REDCR po
celou tuto dobu bez výpadků nebo přerušení.
— Zařízení „paměti přenášených dat“ VU RTM (VUPM).
Tato funkce ve VU je odpovědná za poskytování a aktuali­
zaci dat. Obsah dat. Obsah dat („TachographPayload“) je
definován v 5.4.4/5.4.5 níže a je aktualizován v intervalu
stanoveném v bodě 4.1.1.1 (DSC_12).
— DSRC-VU. Tato funkce, která je umístěna v anténě nebo
je s ní spojena a komunikuje s VU prostřednictvím dráto­
vého nebo bezdrátového (BLE) spojení, obsahuje aktuální
data (data VUPM) a řídí odpovědi na dotazy v systému
5,8 GHz DSRC. Přerušení spojení nebo rušení s funkcí
zařízení DSRC během normálního provozu vozidla je
považováno za porušení nařízení (EU) č. 165/2014.
— Bezpečnostní modul (REDCR) (SM-REDCR) je funkce
používaná pro dešifrování a kontrolu integrity dat z VU.
Prostředky, kterými je toho dosaženo, jsou určeny
v dodatku 11 – Společné bezpečnostní mechanismy
a nejsou definovány v tomto dodatku.
— Funkce zařízení DSRC (REDCR) (DSRC-REDCR)
zahrnuje přijímač-vysílač 5,8 GHz a příslušný firmware
a software, který řídí komunikaci s DSRC-VU v souladu
s tímto dodatkem.
— DSRC-REDCR sleduje DSRC-VU cíleného vozidla, získává
data (aktuální data VUPM cíleného vozidla) prostřednic­
tvím spojení DSRC a přijatá data zpracovává a ukládá ve
svém SM-REDCR.
▼M1
— Anténa DSRC-VU musí být umístěna v místě, ve kterém
umožňuje optimální komunikaci DSRC mezi vozidlem
a přijímací silniční anténou, když je přijímač umístěn 15
metrů před vozidlem a ve výšce 2 metry a zaměřen na
vodorovný a svislý střed čelního skla. U lehkých vozidel
se umístí v horní části čelního skla. U všech ostatních
vozidel se anténa DSRC umístí buď poblíž spodní nebo
poblíž horní části čelního skla.
▼B
DSC_20 Anténa a komunikace musí pracovat v rámci ERC 70-03, musí
být testovány pro příslušné parametry EN 300 674-1 jak je
popsáno v oddíle 5. Anténa a komunikace mohou používat
techniky zmírňování rizika rušení bezdrátové sítě, jak je
popsáno ve zprávě ECC 228, například použitím filtrů při
komunikaci CEN DSRC 5.8 GHz.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 546
DSC_21 Anténa DSRC musí být spojena se zařízením DSRC-VU buď
přímo v modulu namontovaném na čelním skle nebo v jeho
blízkosti, nebo prostřednictvím vyhrazeného kabelu
s konstrukcí, která ztěžuje nezákonné přerušení spojení. Přeru­
šení spojení nebo rušení s funkcí antény je považováno za
porušení nařízení (EU) č. 165/2014. Úmyslné zakrývání antény
nebo jiná nežádoucí manipulace negativně ovlivňující její
provozní výkon jsou považovány za porušení nařízení (EU)
č. 165/2014.
DSC_22 ►M1 Tvarový činitel antény není stanoven a je komerčním
rozhodnutím, pokud namontované zařízení DSRC-VU splňuje
požadavky na shodu podle části 5 níže. Anténa musí být
umístěna v souladu s pokyny v DSC_19 a účinně podporovat
případy použití popsané v bodech 4.1.2 a 4.1.3. ◄
Obrázek 14.4
Příklad polohy antény 5,8 GHz DSRC na čelním skle regulovaných
vozidel
Tvarový činitel REDCR a jeho anténa se mohou měnit podle podmínek
čtečky (montáž na stativu, držení v ruce, montáž ve/na vozidle atd.)
a pracovního postupu pověřené osoby příslušného kontrolního orgánu.
Funkce zobrazování a/nebo oznamování pověřené osobě příslušného
kontrolního orgánu znázorňuje výsledky funkce dálkové komunikace.
Informace se mohou zobrazovat na obrazovce, jako tištěný výstup,
zvukový signál nebo kombinace těchto možností. Způsob tohoto zobra­
zování a/nebo oznamování závisí na požadavcích pověřených osob
příslušných kontrolních orgánů a konstrukci zařízení a v tomto dodatku
není stanoven.
DSC_23 Konstrukce a tvarový činitel REDCR jsou funkcí komerčního
provedení, které pracuje v rámci ERC 70-03, a konstrukčních
a výkonnostních specifikací stanovených v tomto dodatku
(oddíl 5.3.2), čímž je trhu poskytnuta maximální pružnost
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 547
v navrhování a dodávání zařízení, které odpovídá konkrétním
scénářům dotazování příslušného kontrolního orgánu při
provádění konkrétních sledovacích scénářů.
DSC_24 Konstrukce a tvarový činitel DSRC-VU a jeho umístění uvnitř
nebo vně VU jsou funkcí komerčního provedení, které pracuje
v rámci ERC 70-03, a konstrukčních a výkonnostních specifi­
kací stanovených v tomto dodatku (oddíl 5.3.2) a v tomto
bodě (5.1).
DSC_25 DSRC-VU však musí být přiměřeně schopno přijímat hodnoty
systémů dat z jiných inteligentních zařízení ve vozidle
prostřednictvím otevřeného průmyslového standardního
spojení a protokolů (např. ze zařízení vážení na palubě),
pokud jsou tyto systémy dat identifikovány jedinečnými
a známými identifikátory aplikací/názvy souborů a instrukce
k provozování těchto protokolů jsou dostupné Evropské
komisi a bezplatně také výrobcům příslušného zařízení.
5.2 Vývojový diagram
5.2.1 Činnosti
Vývojový diagram činností je znázorněn na obrázku 14.5.
Obrázek 14.5
Vývojový diagram funkce dálkové komunikace
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 548
Kroky jsou popsány níže:
a. Kdykoli je vozidlo v provozu (zapnuté zapalování), tachograf
předává data funkci VU. Funkce VU zpracovává data pro funkci
dálkové komunikace (zašifrovaná) a aktualizuje VUPM v paměti
DSRC-VU (jak je definováno v bodech 4.1.1.1–4.1.1.2). Získaná
data jsou formátována, jak je uvedeno v bodech 5.4.4–5.4.5 níže.
b. Při každé příležitosti, kdy jsou data aktualizována, je rovněž aktu­
alizováno časové razítko definované v zabezpečeném systému dat.
c. Funkce VUSM zabezpečuje data v souladu s postupy stanovenými
v dodatku 11.
d. Při každé příležitosti, kdy jsou data aktualizována (viz
4.1.1.1–4.1.1.2), jsou přenesena do DSRC-VU, kde nahrazují všechna
předchozí data, aby tato aktualizovaná data byla vždy k dispozici
v případě komunikace s REDCR. Při předávání z VU do DSRC-VU
jsou data označena názvem souboru RTMData nebo identifikátory
ApplicationID a atributy.
e. Chce-li pověřená osoba příslušného kontrolního orgánu zaměřit
vozidlo a získat z něj data, musí tato pověřená osoba příslušného
kontrolního orgánu nejprve vložit do REDCR chytrou kartu, která
dovoluje komunikaci a SM-REDCR umožňuje ověřit její pravost
a dešifrovat data.
f. Pověřená osoba příslušného kontrolního orgánu potom zaměří
vozidlo a pomocí dálkové komunikace si vyžádá data. REDCR
otevře relaci rozhraní 5,8 GHz DSRC s DSRC-VU cíleného vozidla
a vyžádá si data. Data jsou přenesena do REDCR prostřednictvím
systému bezdrátové komunikace DSCR atribut používajícího službu
aplikace GET, jak je stanoveno v oddíle 5.4. Atribut obsahuje šifro­
vané hodnoty přenášených dat a zabezpečená data DSRC.
g. Data jsou zařízením REDCR analyzována a předána pověřené osobě
příslušného kontrolního orgánu.
h. Pověřená osoba příslušného kontrolního orgánu použije data k tomu,
aby rozhodla, zda má vozidlo zastavit k podrobné kontrole, či nikoli,
nebo požádat jinou pověřenou osobu příslušného kontrolního orgánu
o zastavení vozidla.
5.2.2 Interpretace dat přijímaných prostřednictvím komunikace DSRC
DSC_26 Data přijatá prostřednictvím rozhraní 5,8 GHz mají význam
a smysl stanovený v bodech 5.4.4 a 5.4.5 níže a pouze takový
význam a smysl a jsou chápána ve smyslu zde stanovených
cílů. V souladu s ustanoveními nařízení (EU) č. 165/2014
musí být data používána pouze pro poskytování náležitých
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 549
informací příslušnému kontrolnímu orgánu, aby mohl rozhod­
nout, zda má vozidlo zastavit pro účely fyzické kontroly,
a následně zlikvidována v souladu s článkem 9 nařízení (EU)
č. 165/2014.
5.3 Parametry fyzického rozhraní DSRC pro dálkovou komunikaci
5.3.1 Omezení umístění
DSC_27 Dálkové sledování vozidel prostřednictvím rozhraní 5,8 GHz
DSRC by nemělo být používáno v rozsahu do 200 metrů od
provozní brány 5,8 GHz DSRC.
5.3.2 Parametry downlinku a uplinku
DSC_28 Zařízení používané pro dálkové sledování tachografů musí
odpovídat doporučení ERC 70-03 a parametrům stanoveným
v tabulkách 14.1 a 14.2 níže a pracovat v jejich rozsahu.
DSC_29 Pro zajištění kompatibility s provozními parametry jiných
standardních systémů 5,8 GHz DSRC musí dále zařízení
používané pro dálkové sledování tachografů odpovídat para­
metrům EN 12253 a EN 13372.
Konkrétně:
Tabulka 14.1
Parametry downlinku
▼C2
Číslo položky Parametr Hodnota (hodnoty) Poznámka
D1 Nosné frekvence downlinku Snímač REDCR může
použít čtyři alternativy:
5,7975 GHz
5,8025 GHz
5,8075 GHz
5,8125 GHz
V rámci ERC 70-03.
Nosné frekvence nosiče může
zvolit realizátor silničního systému
a nemusí být známy zařízení
DSRC-VU.
(V souladu s normami EN 12253,
EN 13372)
D1a (*) Tolerance nosných
frekvencí
do ± 5 ppm (V souladu s normou EN 12253)
D2 (*) Spektrální maska vysílače
RSU (REDCR)
V rámci ERC 70-03.
REDCR musí odpovídat
třídám B a C podle normy
EN 12253.
Žádné jiné zvláštní poža­
davky v rámci této přílohy.
Parametr používaný ke kontrole
rušení mezi dotazovacími zaříze­
ními ve vzájemné blízkosti (podle
norem EN 12253 a EN 13372).
D3 Minimální frekvenční
rozsah palubní jednotky
OBU(DSRC-VU)
5,795 – 5,815 GHz (V souladu s normou EN 12253)
D4 (*) Maximální výkon EIRP V rámci ERC 70-03 (bez
licence) a v souladu s vnit­
rostátními právními před­
pisy
Maximálně + 33 dBm
(V souladu s normou EN 12253)
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 550
Číslo položky Parametr Hodnota (hodnoty) Poznámka
D4a Úhlová maska výkonu
EIRP
Podle deklarované a uveřej­
něné specifikace konstru­
ktéra dotazovacího zařízení
(V souladu s normou EN 12253)
D5 Polarizace Kruhová levotočivá (V souladu s normou EN 12253)
D5a Křížová polarizace XPD:
V ose: (REDCR) RSU
t ≥ 15 dB
(DSRC-VU) OBU
r ≥ 10 dB
V oblasti – 3 dB: (REDCR)
RSU t ≥ 10 dB
(DSRC-VU) OBU r ≥ 6 dB
(V souladu s normou EN 12253)
D6 (*) Modulace Dvouúrovňová amplitudová
modulace
(V souladu s normou EN 12253)
D6a (*) Modulační index 0,5 … 0,9 (V souladu s normou EN 12253)
D6b Diagram oka ≥ 90 % (čas)/≥ 85 %
(amplituda)
D7 (*) Kódování údajů FM0
Bit „1“ má přechod pouze
na začátku a na konci bito­
vého intervalu. Bit „0“ má
v porovnání s bitem „1“
další doplňkový přechod
ve středu bitového
intervalu.
(V souladu s normou EN 12253)
D8 (*) Bitový tok 500 kBit/s (V souladu s normou EN 12253)
D8a Tolerance bitových hodin Lepší než ± 100 ppm. (V souladu s normou EN 12253)
D9 (*) Bitová chybovost (B.E.R.)
pro komunikaci
≤ 10 – 6 , jestliže dopadající
výkon na OBU (DSRC-VU)
je v rozmezí stanoveném
v bodech [D11a až D11b].
(V souladu s normou EN 12253)
D10 Spouštěcí signál pro OBU
(DSRC-VU)
OBU (DSRC-VU) se musí
spustit po přijetí jakéhokoli
rámce s nejméně 11 oktety
(včetně preambule).
Není nutný žádný zvláštní vzor
spouštění.
DSRC-VU se může spustit i po
přijetí rámce s méně než 11 oktety.
(V souladu s normou EN 12253)
D10a Maximální doba zahájení ≤ 5 ms (V souladu s normou EN 12253)
D11 Komunikační zóna Prostorová oblast, ve které
se dosahuje hodnoty B.E.R
podle bodu D9a.
(V souladu s normou EN 12253)
D11a (*) Mezní hodnota výkonu pro
komunikaci (horní).
– 24dBm (V souladu s normou EN 12253)
▼C2
02016R0799 — CS — 21.08.2023 — 003.002 — 551
Číslo položky Parametr Hodnota (hodnoty) Poznámka
D11b (*) Mezní hodnota výkonu pro
komunikaci (dolní).
Dopadající výkon:
– 43 dBm (v ose)
– 41 dBm (pod úhlem –
45° až + 45° vůči rovině
rovnoběžné s povrchem
vozovky, když se
DSRC-VU později instaluje
ve vozidle (azimut))
(V souladu s normou EN 12253)
Rozšířený požadavek na horizon­
tální úhly do ± 45° vzhledem
k případům použití definovaným
v této příloze.
D12 (*) Vypínací hladina výkonu
pro (DSRC-VU)
– 60 dBm (V souladu s normou EN 12253)
D13 Preambule Preambule je povinná. (V souladu s normou EN 12253)
D13a Délka a vzor preambule 16 bitů ± 1 bitů s hodnotou
„1“ v kódóvání FM0
(V souladu s normou EN 12253)
D13b Tvar signálu preambule Sekvence, v níž se střídá
nízká a vysoká úroveň
s délkou trvání impulsu 2
μs.
Tolerance je uvedená
v bodě D8a.
(V souladu s normou EN 12253)
D13c Koncové bity RSU (REDCR) smí vyslat
nejvýše 8 bitů po příznaku
ukončení (end flag). OBU
(DSRC-VU) nemusí tyto
dodatečné bity zohlednit.
(V souladu s normou EN 12253)
▼B
(*) – Parametry downlinku, které podléhají zkoušce shody v souladu s příslušnou zkouškou parametrů uvedenou v normě EN
300 674-1.
Tabulka 14.2
Parametry uplinku
▼C2
Číslo položky Parametr Hodnota (hodnoty) Poznámka
U1 (*) Pomocná nosná frekvence OBU (DSRC-VU) musí
podporovat 1,5 MHz a 2,0
MHz
RSU (REDCR) musí
podporovat 1,5 MHz nebo
2,0 MHz nebo obě
frekvence. U1-0: 1,5 MHz
U1-1: 2,0 MHz
Volba pomocné nosné frekvence
(1,5 MHz nebo 2,0 MHz) závisí od
zvoleného profilu podle normy EN
13372.
U1a (*) Tolerance pomocných
nosných frekvencí
do ± 0,1 % (V souladu s normou EN 12253)
U1b Použití postranních pásem Stejné údaje na obou stra­
nách.
(V souladu s normou EN 12253)
U2 (*) Spektrální maska vysílače
OBU (DSRC-VU)
Podle normy EN 12253.
1) Výkon mimo pásmo:
viz norma ETSI EN
300674-1
(V souladu s normou EN 12253)
▼C2
02016R0799 — CS — 21.08.2023 — 003.002 — 552
Číslo položky Parametr Hodnota (hodnoty) Poznámka
2) Výkon v pásmu:
[U4a] dBm při 500 kHz
3) Emise v jakémkoli
jiném kanále uplinku:
U2(3)-1 = – 35 dBm při
500 kHz
U4a (*) Maximální výkon EIRP
v jednom postranním
pásmu (v ose)
Dvě možnosti:
U4a-0: – 14 dBm
U4a-1: – 21 dBm
Podle deklarované a uveřejněné
specifikace konstruktéra zařízení.
U4b (*) Maximální výkon EIRP
v jednom postranním
pásmu (35°)
Dvě možnosti:
— neuplatňuje se
— – 17 dBm
Podle deklarované a uveřejněné
specifikace konstruktéra zařízení.
U5 Polarizace Kruhová levotočivá (V souladu s normou EN 12253)
U5a Křížová polarizace XPD:
V ose: (REDCR) RSU r
≥ 15 dB
(DSRC-VU) OBU
t ≥ 10 dB
Při – 3 dB: (REDCR) RSU
r ≥ 10 dB
(DSRC-VU) OBU t ≥ 6 dB
(V souladu s normou EN 12253)
U6 Modulace pomocné nosné 2-PSK
Kódované údaje synchroni­
zované s pomocnou
nosnou: Přechody kódova­
ných údajů se shodují
s přechody pomocné nosné.
(V souladu s normou EN 12253)
U6b Pracovní cyklus Pracovní cyklus:
50 % ± α, α ≤ 5 %
(V souladu s normou EN 12253)
U6c Modulace nosné Multiplikace modulované
pomocné nosné s nosnou.
(V souladu s normou EN 12253)
U7 (*) Kódování údajů NRZI (Žádný přechod na
začátku bitu „1“, přechod
na začátku bitu „0“, žádný
přechod v rámci bitu)
(V souladu s normou EN 12253)
U8 (*) Bitový tok 250 kbit/s (V souladu s normou EN 12253)
U8a Tolerance bitových hodin do ± 1 000 ppm (V souladu s normou EN 12253)
U9 Bitová chybovost (B.E.R.)
při komunikaci
≤ 10 – 6 (V souladu s normou EN 12253)
▼C2
02016R0799 — CS — 21.08.2023 — 003.002 — 553
Číslo položky Parametr Hodnota (hodnoty) Poznámka
U11 Komunikační zóna Prostorová oblast, ve které
je zařízení DSRC-VU umís­
těno tak, že jeho vysílání
přijímá snímač REDCR
s hodnotou B.E.R. nižší,
než je uvedeno v bodě U9a.
(V souladu s normou EN 12253)
U12a (*) Konverzní zisk (dolní mez) 1 dB pro každé postranní
pásmo
Rozsah úhlů: Kruhově
symetrický mezi osou
a ± 35°
a
v rozsahu – 45° až + 45°
vůči rovině rovnoběžné
s povrchem vozovky, když
se DSRC-VU později insta­
luje ve vozidle (azimut)
Vyšší než stanovený rozsah hodnot
pro horizontální úhly do ± 45°
vzhledem k případům použití
stanoveným v této příloze.
U12b (*) Konverzní zisk (horní mez) 10 dB pro každé postranní
pásmo
Nižší, než je specifikovaný rozsah
hodnot pro každé postranní pásmo
v rámci kruhového kužele kolem
osy s vrcholovým úhlem ± 45°
U13 Preambule Preambule je povinná. (V souladu s normou EN 12253)
U13a Délka a vzor
preambule
32 až 36 μs modulovaných
pouze pomocnou nosnou,
poté 8 bitů „0“ v kódování
NRZI.
(V souladu s normou EN 12253)
U13b Koncové bity DSRC-VU smí vyslat
nejvýše 8 bitů po příznaku
ukončení. RSU (REDCR)
nemusí tyto dodatečné bity
zohlednit.
(V souladu s normou EN 12253)
▼B
(*) – Parametry uplinku, které podléhají zkoušce shody v souladu s příslušnou zkouškou parametrů uvedenou v normě EN 300 674-1.
5.3.3 Konstrukce antény
5.3.3.1 Anténa REDCR
DSC_30 Konstrukce antény REDCR je funkcí komerčního návrhu
a funguje v mezích stanovených v bodě 5.3.2, přičemž je
přizpůsoben tak, aby byl optimalizován výkon čtení DSRC-
REDCR pro specifický účel a podmínky čtení, pro které bylo
REDCR navrženo.
5.3.3.2 Anténa VU
DSC_31 Konstrukce antény REDCR je funkcí komerčního návrhu
a funguje v mezích stanovených v bodě 5.3.2, přičemž je
přizpůsoben tak, aby byl optimalizován výkon čtení DSRC-
REDCR pro specifický účel a podmínky čtení, pro které bylo
REDCR navrženo.
▼C2
02016R0799 — CS — 21.08.2023 — 003.002 — 554
DSC_32 Anténa VU je připevněna k čelnímu sklu vozidla nebo v jeho
blízkosti, jak je uvedeno v bodě 5.1 výše.
DSC_33 Ve zkušebním prostředí v dílně (viz část 6.3) by se anténa
DSCR-VU upevněná, jak je popsáno výše v bodě 5.1, měla
úspěšně připojit ke standardní zkušební komunikaci a úspěšně
zajistit transakci RTM podle definice v tomto dodatku na
vzdálenost 2 až 10 metrů, po více než 99 % času, zprůměro­
váno na 1 000 přečtených dotazů.
5.4 Požadavky protokolu DSRC pro RTM
5.4.1 Přehled
DSC_34 Transakční protokol pro stahování dat pomocí rozhraní 5,8
GHz DSRC musí být v souladu s následujícími kroky.
Tento oddíl popisuje postup transakce v ideálních podmín­
kách, aniž by docházelo k opakovanému vysílání nebo přeru­
šení komunikace.
POZNÁMKA Účelem iniciační fáze (krok 1) je vytvoření
komunikace mezi REDCR a DSRC celků ve vozidle, které
se dostaly do transakční zóny 5,8 GHz DSRC (řídicí
jednotka-vedlejší jednotka), ale dosud nenavázaly komunikaci
s REDCR, a informování procesů aplikace.
— Krok 1 Inicializace. REDCR vyšle rámec obsahující
„servisní tabulku signálů“ (BST), která obsahuje identifi­
kátory aplikace (AID) v servisním seznamu, který podpo­
ruje. V aplikaci RTM se jednoduše jedná o službu
s hodnotou AID = 2 (Freight&Fleet). DSRC-VU vyhod­
notí přijatou BST a odpoví (viz níže) seznamem podpo­
rovaných aplikací v doméně Freight&Fleet nebo neod­
poví, nejsou-li podporovány žádné aplikace. Jestliže
REDCR neuvádí AID = 2, DSRC-VU neodpoví na
REDCR.
— Krok 2 DSRC-VU vyšle rámec obsahující žádost o přidě­
lení soukromého okna.
— Krok 3 REDCR vyšle rámec obsahující přidělení soukro­
mého okna.
— Krok 4 DSRC-VU použije přidělené soukromé okno pro
odeslání rámce obsahujícího servisní tabulku svého
vozidla (VST). Tato VST obsahuje seznam všech různých
instancí aplikací, které tento DSRC-VU podporuje v rámci
AID = 2. Různé instance jsou identifikovány pomocí
jedinečně generovaných EID, které jsou vždy spojeny
s hodnotou parametru Application Context Mark (kontex­
tová značka aplikace) indikující aplikaci a podporovanou
normu.
— Krok 5 REDCR potom analyzuje nabízenou VST, a buď
ukončí spojení (RELEASE), protože nemá zájem o nic,
co VST může nabídnout (tj. přijímá VST od DSRC-VU,
který nepodporuje transakci RTM), nebo přijme-li
příslušnou VST, spustí instanci aplikace.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 555
— Krok 6 Za tímto účelem REDCR odešle rámec obsahující
příkaz k načtení dat RTM, označující instanci aplikace
RTM uvedením identifikátoru, který určí příslušnou
instanci aplikace RTM (jak stanoví DSRC-VU ve VST)
a přidělí soukromé okno.
— Krok 7 DSRC-VU použije nově přidělené soukromé okno
pro odeslání rámce, který obsahuje adresovaný identifi­
kátor, který odpovídá instanci aplikace RTM, jak je
uvedeno ve VST, společně s atributem RtmData (prvek
přenášených dat + bezpečnostní prvek).
— Krok 8 Je-li požadováno více služeb, hodnota „n“ se
změní na další servisní referenční číslo a proces se
opakuje.
— Krok 9 REDCR potvrdí přijetí dat odesláním rámce obsa­
hujícího příkaz RELEASE do DSRC-VU, aby byla relace
ukončena, NEBO v případě, že se mu nepodaří vyhod­
notit úspěšné přijetí LDPU, vrátí se do kroku 6.
Viz obrázek 14.6 a názorný popis transakčního protokolu.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 556
Obrázek 14.6
Vývojový diagram RTM přes 5.8 GHz DSRC
5.4.2 Příkazy
DSC_35 Následující příkazy jsou jediné funkce používané ve fázi
transakce RTM
— INITIALISATION.request: Příkaz vydaný REDCR ve
formě rádiové zprávy s definicí aplikací, které REDCR
podporuje.
— INITIALISATION.response: Odpověď DSRC-VU
potvrzující spojení a obsahující seznam podporovaných
případů aplikací s charakteristikami a informacemi, jak
k nim přistupovat (EID).
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 557
— GET.request: Příkaz vydaný REDCR pro DSRC-VU,
který určí příslušnou realizaci aplikace pomocí definova­
ného EID, jak byl přijat ve VST, a dává DSRC-VU pokyn
k odeslání vybraných atributů s daty. Cílem příkazu GET
je pro REDCR získání dat od DSRC-VU.
— GET.response: Odpověď DSRC-VU, která obsahuje
požadovaná data.
— ACTION.request ECHO: Příkaz pro DSRC-VU, aby
vrátil data z DSRC-VU do REDCR. Cílem příkazu
ECHO je umožnit dílnám nebo testovacím zařízením
pro typové zkoušky testovat funkci spojení DSRC bez
nutnosti přístupu k bezpečnostním údajům.
— ACTION.response ECHO: Odpověď DSRC VU na
příkaz ECHO.
— EVENT_REPORT.request RELEASE: Příkaz pro
DSRC-VU, že transakce je ukončena. Cílem příkazu
RELEASE je ukončení relace s DSRC-VU. Po přijetí
příkazu RELEASE DSRC-VU neodpovídá na žádné
další dotazy v rámci aktuálního spojení. Podle EN
12834 se DSRC-VU nepřipojí dvakrát ke stejnému dota­
zovacímu zařízení, není-li mimo komunikační zónu 255
sekund nebo změní-li se ID signálu dotazovacího zařízení.
5.4.3 Pořadí dotazovacích příkazů
DSC_36 Z hlediska pořadí příkazů a odpovědí lze transakci popsat
takto:
▼C2
Sekvence Odesílatel Příjemce Popis Činnost
1 REDCR > DSRC-VU Inicializace komunikačního
spojení – Požadavek
Snímač REDCR odesílá
tabulku BST.
2 DSRC-VU > REDCR Inicializace komunikačního
spojení – Odpověď
Jestliže tabulka BST podpo­
ruje AID = 2, DSRC-VU si
vyžádá soukromé okno
3 REDCR > DSRC-VU Poskytne soukromé okno. Posílá rámec s přidělením
soukromého okna.
4 DSRC-VU > REDCR Posílá tabulku VST. Posílá rámec obsahující VST.
5 REDCR > DSRC-VU Posílá příkaz GET.request
na údaje v atributu pro
konkrétní EID.
6 DSRC-VU > REDCR Posílá příkaz GET.response
s požadovaným atributem
pro konkrétní EID.
Posílá atribut (RTMData,
OWSData…) s údaji pro
konkrétní EID.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 558
Sekvence Odesílatel Příjemce Popis Činnost
▼M1
7 REDCR > DSRC-VU Posílá příkaz GET.request
na údaje v jiném atributu
(v případě potřeby).
▼B
8 DSRC-VU > REDCR Posílá příkaz GET.response
s požadovaným atributem.
Posílá atribut s údaji pro
konkrétní EID.
9 REDCR > DSRC-VU Potvrzuje úspěšné přijetí
údajů.
Posílá příkaz RELEASE,
kterým se ukončí transakce.
10 DSRC-VU Ukončuje transakci.
Příklad pořadí a obsahu transakce s vyměňovanými rámci, jak
je stanoveno v článcích 5.4.7 a 5.4.8.
5.4.4 Struktury dat
DSC_37 Sémantická struktura dat předávaných rozhraním 5,8 GHz
DSRC odpovídá popisu uvedenému v této příloze. Struktura
těchto dat je stanovena v tomto článku.
DSC_38 Přenášená data (data RTM) obsahují řetězec
1. dat EncryptedTachographPayload, která jsou šifrováním
údaje TachographPayload stanoveného v ASN.1 v části
5.4.5. Způsob šifrování je popsán v dodatku 11;
2. dat DSRCSecurityData, stanovených v dodatku 11.
DSC_39 Data RTM jsou označena jako atribut RTM = 1 a přenášena
v kontejneru RTM =10.
DSC_40 Kontextová značka RTM identifikuje podporované standardní
části v řadě TARV norem (RTM odpovídá části 9)
Definice modulu ASN.1 pro data DSRC v aplikaci RTM je
určena takto:
▼C2
02016R0799 — CS — 21.08.2023 — 003.002 — 559
► (2) (3) M1
► (1) M3
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 560
5.4.5 Prvky RTMData, provedené akce a definice
DSC_41 Hodnoty dat vypočítávané VU a používané pro aktualizaci
zabezpečených dat v DSRC-VU se vypočítávají podle
pravidel stanovených v tabulce 14.3:
▼M3
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 tp15638Vehic­
leRegistrationPlate ze zazna­
menané hodnoty datového
typu
VehicleRegistrationIdentifica­
tion podle definice
v dodatku 1 VehicleRegi­
strationIdentification
Registrační značka
vozidla vyjádřená jako
řetězec znaků
tp15638VehicleRegistrationP­
late LPN,
–– Registrační značka vozidla
s datovou strukturou podle
ISO 14906, avšak s následu­
jícím omezením pro aplikaci
RTM:
SEKVENCE začíná kódem
země následovaným alfabe­
tický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 tp15638SpeedingE­
vent 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,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 561
(1)
Datový prvek RTM
(2)
Činnost, kterou provádí VU
(3)
Definice údajů podle ASN.1
RTM3
Řízení bez
platné karty
VU vygeneruje booleovskou
hodnotu pro datový prvek
RTM3
tp15638DrivingWithoutVa­
lidCard.
VU přiřadí proměnné
tp15638DrivingWithoutVa­
lidCard 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 posled­
ních 10 dnů nebo stále
probíhá;
0 (FALSE): ve všech
ostatních případech.
tp15638DrivingWithoutValid­
Card
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ů zazname­
ná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,
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 562
(1)
Datový prvek RTM
(2)
Činnost, kterou provádí VU
(3)
Definice údajů podle ASN.1
RTM7
Nesoulad údajů
o pohybu vozidla
VU vygeneruje booleovskou
hodnotu pro datový prvek
RTM7.
VU přiřadí proměnné
tp15638VehicleMotionCon­
flict 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 zazna­
mená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í
tp15638CurrentActivityDri­
ving
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 nevy­
volala událost poslední
relace karty nebyla
správně uzavřena.
tp15638LastSessionClosed
BOOLEAN
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 563
(1)
Datový prvek RTM
(2)
Činnost, kterou provádí VU
(3)
Definice údajů podle ASN.1
RTM11
Přerušení elektrického
napájení
VU vygeneruje celočíselnou
hodnotu pro datový prvek
RTM11.
VU přiřadí hodnotu
proměnné tp15638PowerSup­
plyInterruption, která je rovna
počtu zaznamenaných
případů přerušení elektric­
ké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ů.
tp15638PowerSupplyInterrup­
tion
INTEGER (0..127),
RTM12
Porucha snímače
VU vygeneruje celočíselnou
hodnotu pro datový prvek
RTM12.
VU přiřadí proměnné sensor­
Fault 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 komuni­
kace 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 komu­
nikace s vnějším zaří­
zením GNSS skončila
během posledních 10 dnů
nebo stále probíhá,
–porucha snímače –
jeden oktet podle slov­
níku údajů
tp15638SensorFault INTEGER
(0..255),
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 564
(1)
Datový prvek RTM
(2)
Činnost, kterou provádí VU
(3)
Definice údajů podle ASN.1
— 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.
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 zazna­
menána žádná událost nasta­
vení času podle definice
v příloze IC, nastaví se
hodnota RTM13 na 0.
oldTimeValue posled­
ní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ý zazna­
menal.
Není-li v datech VU zazna­
mená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),
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 565
(1)
Datový prvek RTM
(2)
Činnost, kterou provádí VU
(3)
Definice údajů podle ASN.1
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 kali­
braci.
Nedošlo-li k žádné kalibraci,
VU nastaví hodnotu RTM15
na 0.
oldTimeValue nejnověj­
šího záznamu o kali­
braci.
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řed­
cházející poslední kalibraci.
VU nastaví hodnotu
pro RTM16 na OldTime­
Value 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 vuCalibration­
Records, přičemž Calibrati­
onPurpose 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),
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 566
(1)
Datový prvek RTM
(2)
Činnost, kterou provádí VU
(3)
Definice údajů podle ASN.1
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í zazna­
menaná rychlost
tp15638CurrentSpeed
INTEGER (0..255),
RTM19
Časové razítko
VU vygeneruje celočíselnou
hodnotu datového prvku
RTM19 (time­
Realz dodatku 1).
VU nastaví hodnotu pro
RTM19 na čas poslední
aktualizace RtmData.
Časové razítko aktuál­
ního
záznamu Tachograph­
Payload
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
tp15638LatestAuthenticatedPo­
sition
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.
tp15638ContinuousDriving­
Time INTEGER(0..255),
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 567
(1)
Datový prvek RTM
(2)
Činnost, kterou provádí VU
(3)
Definice údajů podle ASN.1
RTM22
Nejdelší denní doba
řízení probíhající a před­
chozí 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.
tp15638DailyDrivingTime­
Week 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),
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 568
(1)
Datový prvek RTM
(2)
Činnost, kterou provádí VU
(3)
Definice údajů podle ASN.1
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.
tp15638FortnightlyDriving­
Time INTEGER(0..255),
Poznámka: RTM22, RTM23, RTM24 a RTM25 se vypočítají podle doplňku
k tomuto dodatku.
▼B
5.4.6 Mechanismus přenosu dat
DSC_42 Výše definovaná přenášená data jsou vyžádána REDCR po
inicializační fázi a následně předána DSRC-VU v přiděleném
okně. Příkaz GET používá REDCR pro stažení dat.
▼M1
DSC_43 Pro všechny výměny DSRC jsou data šifrována pomocí PER
(Packed Encoding Rules) UNALIGNED, kromě
a , které se šifrují
pomocí OER (Octet Encoding Rules), definovaných v normě
ISO/IEC 8825-7, Rec. ITU-T X.696.
▼B
5.4.7 Podrobný popis transakce DSRC
DSC_44 Inicializace se provádí podle DSC_44–DSC_48) a tabulek
14.4–14.9. V inicializační fázi REDCR začne odesílat rámec
obsahující BST (servisní tabulka signálů) podle EN 12834
a EN 13372, 6.2, 6.3, 6.4 a 7.1 s nastaveními podle následu­
jící tabulky 14.4.
Tabulka 14.4
Inicializace – nastavení rámce BST
▼C2
Pole Nastavení
Identifikátor spojení Adresa pro všesměrové vysí­
lání
Identifikátor majáku
(BeaconId)
Podle normy EN 12834
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 569
Čas Podle normy EN 12834
Profil Bez rozšíření, použije se 0
nebo 1
MandApplications Bez rozšíření, identifikátor
EID nepřítomný, parametr
nepřítomný, AID = 2
Freight&Fleet
NonMandApplications Nepřítomné
ProfileList Bez rozšíření, počet profilů
na seznamu = 0
Fragmentation header Bez fragmentace
Nastavení vrstvy 2 PDU příkazu, příkaz UI
▼B
Praktický příklad nastavení uvedených v tabulce 14.4 s ozna­
čením šifrování bitů je uveden v následující tabulce 14.5.
Tabulka 14.5
Inicializace – příklad obsahu rámce BST
▼C2
O
kt
et
č
.
Atribut/pole Bity v oktetu Popis
1 FLAG Příznak začátku
2 Broadcast ID Adresa pro všesměrové
vysílání
3 MAC Control Field PDU příkazu
4 LLC Control field Příkaz UI
5 Fragmentation header Bez fragmentace
6 BST Požadavek na inicializaci
SEQUENCE {
OPTION indicator
BeaconID SEQUENCE {
ManufacturerId INTEGER (0..65535)
aplikace NonMand nepří­
tomné
Identifikátor výrobce
7
8
IndividualID INTEGER (0..134217727) 27bitový identifikátor
dostupný výrobci
9
10
11
}
▼C2
02016R0799 — CS — 21.08.2023 — 003.002 — 570
O
kt
et
č
.
Atribut/pole Bity v oktetu Popis
12 Time INTEGER (0..4294967295) 32bitový UNIX v reálném
čase
13
14
15
16 Profile INTEGER (0..127,…) Bez rozšíření. Příklad
profilu 0
17 MandApplications SEQUENCE
(SIZE(0..127,…))
OF {
Bez rozšíření. Počet
mandApplications = 1
18 SEQUENCE {
OPTION indicator Identifikátor EID nepří­
tomný
OPTION indicator
Parametr nepřítomný
AID DSRCApplicationEntityID}} Bez rozšíření. AID = 2
Freight&Fleet
19 ProfileList SEQUENCE (0..127,…) OF
Profile}
Bez rozšíření, počet profilů
na seznamu = 0
20 FCS Kontrolní sekvence rámce
21
22 Flag Příznak ukončení
▼B
DSC_45 Po přijetí BST požádá DSRC-VU o přidělení soukromého
okna, jak je uvedeno v EN 12795 a EN 13372, 7.1.1, bez
jakýchkoli specifických nastavení RTM. Tabulka 14.6 uvádí
příklad šifrování bitů.
Tabulka 14.6
Inicializace – obsah rámce žádosti o přidělení soukromého okna
▼C2
O
kt
et
č
.
Atribut/pole Bity v oktetu Popis
1 FLAG Příznak začátku
2 Private LID Adresa spojení konkrét­
ního DSRC – VU
3
4
5
6 MAC Control field Požadavek na soukromé
okno
7 FCS Kontrolní sekvence rámce
8
9 Flag Příznak ukončení
▼C2
02016R0799 — CS — 21.08.2023 — 003.002 — 571
DSC_46 REDCR potom odpoví přidělením soukromého okna, podle
specifikace v EN 12795 a EN 13372, 7.1.1, bez jakýchkoli
specifických nastavení RTM.
Tabulka 14.7 uvádí příklad šifrování bitů.
Tabulka 14.7
Inicializace – obsah rámce přidělení soukromého okna
▼C2
O
kt
et
č
.
Atribut/pole Bity v oktetu Popis
1 FLAG Příznak začátku
2 Private LID Adresa spojení konkrét­
ního DSRC-VU
3
4
5
6 MAC Control field Přidělení soukromého
okna
7 FCS Kontrolní sekvence rámce
8
9 Flag Příznak ukončení
▼B
DSC_47 Po přijetí přiděleného soukromého okna DSRC-VU odešle
svou VST (servisní tabulka vozidla) podle definice v EN
12834 a EN 13372, 6.2, 6.3, 6.4 a 7.1 s nastaveními podle
tabulky 14.8 pomocí přiděleného přenosového okna.
Tabulka 14.8
Inicializace – nastavení rámce VST
▼C2
Pole Nastavení
Private LID Podle normy EN 12834
Parametry tabulky VST Fill = 0, potom pro každou podporo­
vanou aplikaci: Identifikátor EID
přítomný, parametr přítomný, AID =
2, identifikátor EID, jak ho vygene­
ruje palubní jednotka (OBU)
Parametr Bez rozšíření, obsahuje kontextovou
značku RTM
ObeConfiguration Nepovinné pole ObeStatus může být
přítomné, ale REDCR ho nepoužije
Fragmentation header Bez fragmentace
Nastavení vrstvy 2 PDU příkazu, příkaz UI
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 572
DSC_48 DSRC-VU podporuje aplikaci „Freight and Fleet“ označenou
identifikátorem aplikace „2“. Mohou být podporovány i další
identifikátory aplikací, ale nejsou přítomny v této VST,
protože BST pouze požaduje AID=2. Pole „Aplikace“ obsa­
huje seznam případů podporovaných aplikací v DSRC-VU.
Pro každou realizaci podporované aplikace je uveden odkaz
na příslušnou normu tvořený kontextovou značkou Rtm, která
je složena z IDENTIFIKÁTORU OBJEKTU představujícího
příslušnou normu, její část (9 pro RTM) a případně její verzi
a navíc EID vytvořený DSRC-VU a spojený s daným
případem aplikace.
Praktický příklad nastavení stanovených v tabulce 14.8 s
označením šifrování bitů je uveden v tabulce 14.9.
▼M3
Tabulka 14.9
Inicializace– příklad obsahu rámce VST
O
kt
et
č:

Atribut/pole Bity v oktetu Popis
1 FLAG 0111 1110 Příznak začátku
2 Private LID xxxx xxxx Adresa spojení konkrét­
ní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 iniciali­
zace
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.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 573
O
kt
et
č:

Atribut/pole Bity v oktetu Popis
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í
▼B
DCS_49 REDCR potom načte data vydáním příkazu GET odpovídají­
címu příkazu GET podle definic v EN 13372, 6.2, 6.3, 6.4
a EN 12834 s nastaveními uvedenými v tabulce 14.10.
Tabulka 14.10
Prezentace – nastavení rámce žádosti GET
▼C2
Pole Nastavení
Invoker Identifier (IID) Nepřítomný
Link Identifier (LID) Adresa spojení konkrétního
DSRC-VU
Chaining Ne
Element Identifier (EID) Podle specifikace ve VST. Bez rozší­
ření
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 574
Pole Nastavení
Access Credentials Ne
AttributeIdList Bez rozšíření, 1 atribut, AttributeID =
1 (RtmData)
Fragmentation Ne
Nastavení vrstvy 2 PDU příkazu, dotazovaný (polled)
příkaz ACn
▼B
Tabulka 14.11 uvádí příklad čtení dat RTM.
Tabulka 14.11
Prezentace – příklad rámce žádosti Get
▼C2
O
kt
et
č
.
Atribut/pole Bity v oktetu Popis
1 FLAG Příznak začátku
2 Private LID Adresa spojení konkrét­
ního DSRC-VU
3
4
5
6 MAC Control field PDU příkazu
7 LLC Control field Dotazovaný příkaz ACn,
n-bitový
8 Fragmentation header Bez fragmentace
9 Get.request
SEQUENCE {
Požadavek Get
OPTION indicator Přístupové oprávnění
nepřítomné
OPTION indicator Identifikátor IID nepří­
tomný
OPTION indicator AttributeIdList přítomný
Fill BIT STRING(SIZE(1)) Nastaveno na 0.
10 EID INTEGER(0..127,…) EID instance aplikace
RTM podle specifikace
ve VST. Bez rozšíření
11 AttributeIdList SEQUENCE OF {
AttributeId}}
Bez rozšíření, počet atri­
butů = 1
12 AttributeId = 1, RtmData.
Bez rozšíření
13 FCS Kontrolní sekvence rámce
14
15 Flag Příznak ukončení
▼C2
02016R0799 — CS — 21.08.2023 — 003.002 — 575
DSC_50 Po přijetí žádosti GET odešle DSRC-VU odpověď GET
s požadovanými daty odpovídajícími odpovědi GET podle
definic v EN 13372, 6.2, 6.3, 6.4 a EN 12834 s nastaveními
podle tabulky 14.12.
Tabulka 14.12
Prezentace – nastavení rámce odpovědi GET
▼C2
Pole Nastavení
Invoker Identifier (IID) Nepřítomný
Link Identifier (LID) Podle normy EN 12834
Chaining Ne
Element Identifier (EID) Podle specifikace ve VST.
Access Credentials Ne
Fragmentation Ne
Nastavení vrstvy 2 PDU odpovědi, odpověď
dostupná a příkaz akcepto­
vaný, příkaz ACn
▼B
Tabulka 14.13 uvádí příklad čtení dat RTM.
Tabulka 14.13
Prezentace – příklad obsahu rámce odpovědi
▼C2
O
kt
et
č
.
Atribut/pole Bity v oktetu Popis
1 FLAG Příznak začátku
2 Private LID Adresa spojení konkrét­
ního DSRC-VU
3
4
5
6 MAC Control field PDU odpovědi
7 LLC Control field Odpověď dostupná,
příkaz ACn n-bitový
8 LLC Status field Odpověď dostupná
a příkaz akceptovaný
9 Fragmentation header Bez fragmentace
10 Get.response
SEQUENCE {
Odpověď Get
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 576
O
kt
et
č
.
Atribut/pole Bity v oktetu Popis
OPTION indicator
OPTION indicator
OPTION indicator
Fill BIT STRING(SIZE(1))
Identifikátor IID nepří­
tomný
Seznam atributů přítomný
Návratový status nepří­
tomný
Nepoužije se
11 EID INTEGER(0..127,…) Odpověď instance apli­
kace RTM. Bez rozšíření
12 AttributeList SEQUENCE OF { Bez rozšíření, počet atri­
butů = 1
13 Attributes SEQUENCE {
AttributeId
Bez rozšíření, Attribu­
teId = 1 (RtmData)
14 AttributeValue CONTAINER { Bez rozšíření, volba
kontejneru = 1010.
15 RtmData
16
17
… …
n }}}}
n+1 FCS Kontrolní sekvence rámce
n+2
n+3 Flag Příznak ukončení
▼B
DSC_51 REDCR potom ukončí spojení vydáním příkazu
EVENT_REPORT, RELEASE podle EN 13372, 6.2, 6.3,
6.4 a EN 12834, 7.3.8 bez jakýchkoli specifických nastavení
RTM. Tabulka 14.14 uvádí příklad šifrování bitů příkazu
RELEASE.
Tabulka 14.14
Ukončení. EVENT_REPORT uvolnění obsahu rámce
▼C2
O
kt
et
č
.
Atribut/pole Bity v oktetu Popis
1 FLAG Příznak začátku
2 Private LID Adresa spojení konkrét­
ního DSRC-VU
3
4
▼C2
02016R0799 — CS — 21.08.2023 — 003.002 — 577
O
kt
et
č
.
Atribut/pole Bity v oktetu Popis
5
6 MAC Control field Rámec obsahuje LPDU
príkazu
7 LLC Control field Příkaz UI
8 Fragmentation header Bez fragmentace
9 EVENT_REPORT.request
SEQUENCE {
EVENT_REPORT
(Release)
OPTION indicator Přístupové oprávnění
nepřítomné
OPTION indicator Parametr události nepří­
tomný
OPTION indicator Identifikátor IID nepří­
tomný
Mode BOOLEAN Neočekává se odpověď
10 EID INTEGER (0..127,…) Bez rozšíření, EID = 0
(systém)
11 EventType INTEGER (0..127,…)} Typ události 0 = Release
12 FCS Kontrolní sekvence rámce
13
14 Flag Příznak ukončení
▼B
DSC_52 Neočekává se, že DSRC-VU odpoví na příkaz Release.
Komunikace je poté ukončena.
5.4.8 Popis transakce testu DSRC
DSC_53 Úplné testy, které zahrnují zabezpečení dat, musí být prová­
děny podle dodatku 11 – Společné bezpečnostní mechanismy
oprávněnými osobami s přístupem k bezpečnostním postupům
pomocí normálních příkazů GET stanovených výše.
DSC_54 Uvedení do provozu a pravidelné kontrolní testy, které vyža­
dují dešifrování a pochopení obsahu dešifrovaných údajů, se
provádějí v souladu s dodatkem 11 – Společné bezpečnostní
mechanismy a dodatkem 9 – Schválení typu – minimální
rozsah požadovaných zkoušek.
Základní komunikaci DSRC však lze testovat příkazem
ECHO. Tyto testy mohou být požadovány po uvedení do
provozu, při pravidelné kontrole nebo jindy podle požadavků
příslušného kontrolního orgánu nebo nařízení (EU)
č. 165/2014 (viz 6 níže).
▼C2
02016R0799 — CS — 21.08.2023 — 003.002 — 578
DSC_55 Pro provedení tohoto základního testu komunikace REDCR
vydá příkaz ECHO během relace, tj. po úspěšném dokončení
inicializační fáze. Sekvence interakcí je tak podobná sekvenci
sledování:
— Krok 1 REDCR vyšle „servisní tabulku signálů“ (BST),
která obsahuje identifikátory aplikace (AID) v servisním
seznamu, který podporuje. V aplikacích RTM se jedno­
duše jedná o službu s hodnotou AID = 2.
DSRC-VU vyhodnotí přijatou BST, a pokud zjistí, že
BST požaduje Freight&Fleet (AID = 2), DSRC-VU
odpoví. Pokud REDCR nenabízí AID = 2, DSRC-VU
ukončí transakci s REDCR.
— Krok 2 DSRC-VU vyšle žádost o přidělení soukromého
okna.
— Krok 3 REDCR vyšle přidělení soukromého okna.
— Krok 4 DSRC-VU použije přidělené soukromé okno pro
odeslání servisní tabulky svého vozidla (VST). Tato VST
obsahuje seznam všech různých realizací aplikace, které
tento DSRC-VU podporuje v rámci AID = 2. Různé reali­
zace jsou identifikovány pomocí jedinečných EID, které
jsou vždy spojeny s hodnotou parametru uvádějící podpo­
rovaný příklad použití.
— Krok 5 REDCR potom analyzuje nabízenou VST a buď
ukončí spojení (RELEASE), protože nemá zájem o nic,
co VST může nabídnout (tj. přijímá VST od DSRC-VU,
který nepodporuje transakci RTM ), nebo přijme-li
příslušnou VST, spustí realizaci aplikace.
— Krok 6 REDCR odešle příkaz (ECHO) příslušnému
DSRC-VU a přidělí soukromé okno.
— Krok 7 DSRC-VU použije nově přidělené soukromé okno
pro odeslání rámce odpovědi ECHO.
V následujících tabulkách je uveden praktický příklad výměnné relace
ECHO.
DSC_56 Inicializace je provedena podle 5.4.7 (DSC_44 – DSC_48)
a tabulek 14.4 – 14.9.
DSC_57 REDCR potom odešle příkaz ACTION, ECHO odpovídající
ISO 14906 a obsahující 100 oktetů dat bez speciálního nasta­
vení RTM. V tabulce 14.15 je uveden obsah rámce odesla­
ného REDCR.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 579
Tabulka 14.15
Příklad rámce žádosti ACTION, ECHO
▼C2
O
kt
et
č
.
Atribut/pole Bity v oktetu Popis
1 FLAG Příznak začátku
2 Private LID Adresa spojení konkrét­
ního DSRC-VU
3
4
5
6 MAC Control field PDU příkazu
7 LLC Control field Dotazovaný příkaz ACn,
n-bitový
8 Fragmentation header Bez fragmentace
9 ACTION.request
SEQUENCE {
Činnost – požadavek
(ECHO)
OPTION indicator Přístupové oprávnění
nepřítomné
OPTION indicator Parametr činnosti přítomný
OPTION indicator Identifikátor IID nepří­
tomný
Mode BOOLEAN Očekává se odpověď.
10 EID INTEGER (0..127,…) Bez rozšíření, EID = 0
(systém)
11 ActionType INTEGER (0..127,…) Bez rozšíření, požadavek
na typ činnosti ECHO
12 ActionParameter CONTAINER { Bez rozšíření, volba
kontejneru = 2
13 Bez rozšíření. Délka
řetězce = 100 oktetů
14 Údaje, které se mají
odeslat zpět
… …
113 }}
114 FCS Kontrolní sekvence rámce
115
116 Flag Příznak ukončení
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 580
DSC_58 Při přijímání žádosti ECHO odešle DSRC-VU odpověď
ECHO o 100 oktetech dat a reaguje na přijatý příkaz
v souladu s ISO 14906 bez speciálního nastavení pro RTM.
Tabulka 14.16 uvádí příklad šifrování na úrovni bitů.
Tabulka 14.16
Příklad rámce odpovědi ACTION, ECHO
▼C2
O
kt
et
č
.
Atribut/pole Bity v oktetu Popis
1 FLAG Příznak začátku
2 Private LID Adresa spojení konkrét­
ního VU
3
4
5
6 MAC Control field PDU odpovědi
7 LLC Control field Příkaz ACn, n-bitový
8 LLC status field Odpověď dostupná
9 Fragmentation header Bez fragmentace
10 ACTION.response
SEQUENCE {
Činnost – odpověď
(ECHO)
OPTION indicator Identifikátor IID nepří­
tomný
OPTION indicator Parametr odpovědi
přítomný
OPTION indicator Návratový status nepří­
tomný
Fill BIT STRING (SIZE (1)) Nepoužije se
11 EID INTEGER (0..127,…) Bez rozšíření, EID = 0
(systém)
12 ResponseParameter CONTAINER { Bez rozšíření, volba
kontejneru = 2
13 Bez rozšíření. Délka
řetězce = 100 oktetů
14 Údaje odeslané zpět
… …
113 }}
114 FCS Kontrolní sekvence rámce
115
116 Flag Příznak ukončení
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 581
5.5 Vyhrazeno pro budoucí použití
▼M2
__________
▼B
5.6 Přenos dat mezi DSRC-VU a VU
5.6.1 Fyzické spojení a rozhraní
DSC_66 Spojení mezi VU a DSRC-VU může být provedeno buď
fyzickým kabelem, nebo bezdrátovou komunikací krátkého
dosahu na bázi Bluetooth v4.0 BLE.
DSC_67 Bez ohledu na volbu fyzického spojení a rozhraní jsou
splněny tyto požadavky:
DSC_68 ►M1 a) Aby bylo možné uzavírat smlouvy na dodávky VU
a DSRC-VU a rovněž různých sérií DSRC-VU
s různými dodavateli, je spojení mezi VU
a DSRC-VU, který není součástí VU, otevřeným
standardním spojením. VU se s DSRC-VU spojuje
buď ◄
i) pomocí pevného kabelu délky nejméně 2 metry
s přímým konektorem DIN 41612 H11 –
schválenou zástrčkou na straně DSRC-VU
s 11 kolíky a odpovídající zásuvkou se schvá­
lením DIN/ISO na straně VU,
ii) pomocí zařízení Bluetooth Low Energy (BLE)
iii) pomocí standardního spojení ISO 11898 nebo
SAE J1939
DSC_69 b) Definice rozhraní a spojení mezi VU a DSRC-VU musí
podporovat příkazy protokolu aplikace stanovené v 5.6.2.
a
DSC_70 c) VU a DSRC-VU musí podporovat přenos dat prostřednic­
tvím spojení s ohledem na výkon a napájení.
5.6.2 Protokol aplikace
DSC_71 Protokol aplikace mezi zařízením vzdálené komunikace VU
a DSRC-VU je odpovědný za pravidelný přenos dat vzdálené
komunikace z VU do DSRC.
DSC_72 Jsou určeny tyto hlavní příkazy:
1. 1. Inicializace komunikačního spojení – žádost
2. Inicializace komunikačního spojení – odpověď
3. Odeslání dat s identifikátorem aplikace RTM a přenášená
data podle dat RTM
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 582
4. Potvrzení dat
5. Ukončení komunikačního spojení – žádost
6. Ukončení komunikačního spojení – odpověď
DSC_73 V ASN1.0 mohou být předchozí příkazy definovány takto:
DSC_74 Popis příkazů a parametrů:
— se
používá pro inicializaci komunikačního spojení. Příkaz
je odeslán z VU do DSRC-VU. VU stanoví LinkIdentifier
a sdělí jej DSRC-VU pro vytvoření specifického komuni­
kačního spojení.
(Pozn.: slouží k podpoře budoucích spojení a dalších apli­
kací/modulů jako např. vážení na palubě).
—
používá DSRC-VU pro odeslání odpovědi na žádost
o inicializaci komunikačního spojení. Příkaz odešle
DSRC-VU do VU. Příkaz poskytuje výsledek inicializace
jako odpověď = 1 (úspěch) nebo = 0 (selhání).
DSC_75 Inicializace komunikačního spojení se provádí po instalaci,
kalibraci a spuštění motoru/VU.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 583
— používá VU pro odeslání podepsa­
ných RCDTData (tj. dat vzdálené komunikace) do
DSRC-VU. Data jsou odesílána každých 60 sekund. Para­
metr DataTransactionId označuje specifický přenos dat.
LinkIdentifier rovněž zajišťuje správnost příslušného
odkazu.
— odesílá DSRC-VU
jako zpětnou vazbu do VU po přijetí dat z příkazu ­
označeného parametrem DataTran­
sactionId. Parametr odpovědi je 1 (úspěch) nebo = 0
(selhání). Pokud VU přijme víc než tři odpovědi odpoví­
dající 0 nebo pokud VU nepřijme pro specifický dříve
odeslaný příkaz se specifickým DataTransactionId, VU
generuje a zaznamená událost.
— odesílá
VU do DSRC-VU pro ukončení spojení pro specifický
LinkIdentifier.
DSC_76 Při novém spuštění DSRC-VU nebo VU by všechny stávající
komunikační odkazy měly být odstraněny, protože se mohou
vyskytovat „zbytkové“ odkazy v důsledku neočekávaného
vypnutí VU.
— odesílá
DSRC-VU do VU pro potvrzení žádosti o ukončení
spojení ze strany VU pro specifický LinkIdentifier.
5.7 Řešení chyb
5.7.1 Záznamy a komunikace dat v DSRC-VU
▼M3
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řípad­
ných chyb v přenosu dat z VU do paměti DSRC-VU se zazna­
menají 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í.
▼B
DSC_79 Pokud se VUPM neúspěšně pokusí získat data VU z bezpeč­
nostního modulu (pro předání do VU-DSRC), zaznamená toto
selhání s typem EventFaultType a hodnotou enum nastavenou
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 584
na „62“H Chyba komunikace zařízení vzdálené komunikace
s časovým razítkem. Selhání komunikace je zjištěno, není-li
zpráva pro příslušný příkaz
(tj. se stejnými zprávami DataTransactionId
) přijata déle než
během tří následných pokusů.
5.7.2 Chyby bezdrátové komunikace
DSC_80 Řešení chyb komunikace odpovídá ustanovením příslušných
norem DSRC, konkrétně EN 300 674-1, EN 12253, EN
12795, EN 12834 a příslušným parametrům EN 13372.
5.7.2.1 Chyby šifrování a podpisu
DSC_81 Chyby šifrování a podpisu se řeší v souladu s dodatkem 11
Společné bezpečnostní mechanismy a nejsou přítomné
v žádných chybových hlášeních spojených s přenosem dat
DSRC.
5.7.2.2 Záznam chyb
Médium DSRC je dynamická bezdrátová komunikace v prostředí nejis­
tých atmosférických a interferenčních podmínek, zejména v kombinacích
„přenosné REDCR“ a „pohybující se vozidlo“ v rámci této aplikace. Je
proto třeba uvědomit si rozdíl mezi „chybou čtení“ a „chybovými“
podmínkami. Při přenosu prostřednictvím bezdrátového rozhraní je
chyba čtení běžná a důsledkem je obvykle nový pokus, tj. nová relace
BST a nový pokus o sekvenci, které ve většině případů vedou k úspěš­
nému komunikačnímu spojení a přenosu dat, pokud se cílové vozidlo
během času potřebného pro nový přenos nedostane z dosahu.
(„Úspěšný“ případ „čtení“ může zahrnovat několik pokusů a nových
spojení.)
Chyba čtení může být důsledkem nesprávného spárování antén (chyba
„zaměření“); zastínění jedné z antén – může být úmyslné, ale rovněž
důsledkem fyzické přítomnosti jiného vozidla; rádiové interference,
zejména zařízení WIFI v pásmu cca 5,8 GHz nebo jiných veřejně
přístupných bezdrátových komunikací nebo může být způsobeno rada­
rovou interferencí nebo nepříznivými atmosférickými podmínkami (např.
za bouřky); nebo jednoduše vyjetím z dosahu komunikace DSRC.
Jednotlivé případy chyb čtení nelze z jejich povahy zaznamenat, protože
komunikace nebyla prostě navázána.
Pokud však oprávněná osoba příslušných kontrolních orgánů zaměří
vozidlo a pokusí se zjistit jeho DSRC-VU, ale nedojde k úspěšnému
přenosu dat, může k tomuto selhání dojít v důsledku úmyslné manipu­
lace, a proto musí mít oprávněná osoba příslušných kontrolních orgánů
k dispozici prostředek pro zaznamenání selhání a upozornění kolegů na
cestě o možné manipulaci. Kolegové potom mohou zastavit vozidlo
a provést fyzickou kontrolu. Pokud však není úspěšně navázána komu­
nikace, systém DSRC-VU nemůže poskytnout data týkající se selhání.
Podávání těchto zpráv je proto funkcí konstrukce zařízení REDCR.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 585
„Selhání čtení“ je technicky odlišné od „chyby“. V této souvislosti je
„chyba“ přijetí špatné hodnoty.
Přenos dat do DSRC-VU je realizován již v zabezpečené podobě, proto
musí být ověřen poskytovatelem dat (viz 5.4).
Data následně přenášená vzdušným rozhraním se kontrolují cyklickými
redundantními kontrolami na komunikační úrovni. Je-li CRC úspěšná,
jsou data správná. Není-li CRC úspěšná, jsou data přenášena znovu.
Pravděpodobnost, že by nesprávná data mohla úspěšně projít CRC, je
statisticky tak nízká, že může být zanedbána.
Není-li validace CRC úspěšná a není čas pro nový přenos a přijetí
správných dat, nebude výsledkem chyba, ale případ specifického typu
selhání čtení.
Jediné smysluplné „selhání“ dat, které může být zaznamenáno, je chyba
počtu úspěšných inicializací transakcí, které nevedou k úspěšnému
přenosu dat do REDCR.
DSC_82 REDCR proto zaznamenává počet časově označených
případů, kdy je „inicializační“ fáze sledování DSRC úspěšná,
ale transakce je ukončena před úspěšným přijetím dat
v REDCR. Tato data jsou k dispozici oprávněné osobě
příslušných kontrolních orgánů a jsou uložena v paměti zaří­
zení REDCR. Způsob, jakým je toho dosaženo, je záležitostí
konstrukce výrobku nebo specifikace příslušného kontrolního
orgánu.
Jedinými smysluplnými „chybnými“ daty, která mohou být
zaznamenána, je počet případů, kdy REDCR nedokáže deši­
frovat přijatá data. Je však třeba zmínit, že tyto případy
souvisejí pouze s účinností softwaru REDCR. Data mohou
být technicky dešifrována, ale nedávají sémantický smysl.
DSC_83 REDCR proto zaznamenává počet časově označených
případů, kdy se neúspěšně pokusilo dešifrovat data přijatá
přes rozhraní DSRC.
6 UVEDENÍ DO PROVOZU A PRAVIDELNÉ KONTROLNÍ TESTY
PRO FUNKCE DÁLKOVÉ KOMUNIKACE OBECNÉ INFORMACE
6.1 Obecné informace
DSC_84 Pro funkci dálkové komunikace jsou určeny dva typy testů:
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 586
1) Test ECHO pro posouzení bezdrátového komunikačního
kanálu DSRC-REDCR >>-:-
2) Koncový bezpečnostní test, který ověřuje, že je karta dílny
schopna přístupu k šifrovanému a podepsanému datovému
obsahu vytvořenému VU a přenášenému bezdrátovým
komunikačním kanálem.
6.2 ECHO
Tento článek obsahuje ustanovení speciálně vytvořená pro testování
funkční aktivity DSRC-REDCR >>-:-
Cílem příkazu ECHO je umožnit dílnám nebo testovacím zařízením pro
typové zkoušky testovat funkci spojení DSRC bez nutnosti přístupu
k bezpečnostním údajům. Testovací zařízení proto musí být pouze
schopno inicializovat komunikaci DSRC (odeslání BST s AID = 2)
a potom odeslat příkaz ECHO a v případě, že DSRC pracuje, přijmout
odezvu ECHO. Podrobnosti viz 5.4.8. V případě, že tuto odezvu přijme
správně, může být spojení DSRC (DSRC-REDCR >>-:-
validováno jako správně fungující.
6.3 Testy validace obsahu zabezpečených dat
DSC_85 Tento test je určen pro validaci koncového bezpečnostního
toku dat. Pro tento test je nutná testovací čtečka DSRC.
Tato čtečka provádí stejné funkce a je realizována se stejnými
specifikacemi jako čtečka používaná oprávněnými osobami
s tím rozdílem, že karta dílny je používána pro ověření totož­
nosti uživatele testovací čtečky DSRC, nikoli kontrolní karty.
Test lze provádět po počáteční aktivaci inteligentního tacho­
grafu nebo na konci kalibračního postupu. Po aktivaci celek
ve vozidle generuje zabezpečená data včasné detekce a sdělí
je zařízení dálkové komunikace.
DSC_86 Pracovníci dílny musí testovací čtečku DSRC umístit ve vzdá­
lenosti 2 až 10 metrů před vozidlem.
DSC_87 Potom pracovníci dílny vloží do testovací čtečky DSRC kartu
dílny a odešlou požadavek na zjištění dat včasné detekce do
celku ve vozidle. Po úspěšném zjištění pracovníci dílny přijatá
data zkontrolují, aby se přesvědčili, že byla úspěšně valido­
vána z hlediska integrity a dešifrována.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 587
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ŮSOB­
NOST“ (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íha­
jící týden;
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 588
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.
Obrázek 1.
Příklad denní doby odpočinku přerušené z důvodu převozu lodí/vlakem
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
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 589
— 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.
Obrázek 2.
Příklad rozdělené denní doby odpočinku přerušené z důvodu převozu lodí/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í.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 590
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ře­
trž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.
Obrázek 3.
Zpracování dob odpočinku celkem ve vozidle s cílem určit, zda musí být přerušená doba odpočinku
vypočtena jako pravidelná denní doba odpočinku nebo jako první část rozdělené denní doby odpočinku
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 591
Obrázek 4.
Zpracování dob odpočinku celkem ve vozidle s cílem určit, zda musí být přerušená doba odpočinku
vypočtena jako druhá část rozdělené denní doby odpočinku
Obrázek 5.
Příklad denní doby odpočinku přerušené více než dvakrát, což vede k tomu, že se doba odpočinku
H nezahrnuje do výpočtu
Obrázek 6.
Příklad denní doby odpočinku, kdy je výpočet doby na trajektu/ ve vlaku (Ferry/Train Calculation)
zahájen na konci pracovní doby
Obrázek 7.
Příklad denní doby odpočinku přerušené více než dvakrát, což vede k tomu, že doba odpočinku B neza­
hrnuje do výpočtu
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 592
Obrázek 8.
Příklad rozdělené denní doby odpočinku přerušené jednou během první doby odpočinku a jednou během
druhé doby odpočinku
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í.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 593
Dodatek 15
MIGRACE: ŘÍZENÍ KOEXISTENCE GENERACÍ A VERZÍ ZAŘÍZENÍ
▼B
OBSAH
1. DEFINICE
2. OBECNÁ USTANOVENÍ
2.1. Přechod na novou generaci
▼M3
2.2. Interoperabilita mezi celky ve vozidle a kartami
▼B
2.3. Interoperabilita mezi celky ve vozidle a snímači pohybu
2.4. Interoperabilita mezi celky ve vozidle, kartami tachografu a zařízením pro
stahování dat
2.4.1 Přímé stahování z karet prostřednictvím inteligentního vyhrazeného zaří­
zení (IDE)
2.4.2 Stahování z karet prostřednictvím celku ve vozidle
2.4.3 Stahování z celku ve vozidle
2.5. Interoperabilita mezi celkem ve vozidle a kalibračním zařízením
3. HLAVNÍ KROKY V OBDOBÍ PŘED DATEM ZAVEDENÍ
4. USTANOVENÍ PRO OBDOBÍ PO DATU ZAVEDENÍ
▼M3
5. ZÁZNAM PŘEKROČENÍ HRANIC V PRVNÍ GENERACI A PRVNÍ
VERZI DRUHÉ GENERACE TACHOGRAFŮ
▼B
1. DEFINICE
Pro účely tohoto dodatku se použijí tyto definice:
systém inteligentního tachografu: podle definice v této příloze (kapitola
1: definice bbb);
systém tachografu první generace: podle definice v tomto nařízení
(článek 2: definice 1);
systém tachografu druhé generace: podle definice v tomto nařízení
(článek 2: definice 7);
datum zavedení: podle definice v této příloze (kapitola 1: definice ccc);
inteligentní vyhrazené zařízení (IDE): zařízení používané ke stahování
dat podle definice v dodatku 7 této přílohy.
▼M3
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 gene­
raci systémů tachografů a o zavedení druhé verze záznamového zařízení
a karet tachografu druhé generace.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 594
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é gene­
race 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é peri­
odické 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 stej­
né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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 595
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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 596
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é gene­
race 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 zave­
dení.
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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 597
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ža­
dovat 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.
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.
▼M3
02016R0799 — CS — 21.08.2023 — 003.002 — 598
Dodatek 16
ADAPTÉR PRO VOZIDLA KATEGORIE M1 A N1
OBSAH
1. ZKRATKY A REFERENČNÍ DOKUMENTY
1.1. Zkratky
1.2. Referenční normy
2. VŠEOBECNÉ CHARAKTERISTIKY A FUNKCE ADAPTÉRU
2.1. Všeobecný popis adaptéru
2.2. Funkce
2.3. Zabezpečení
3. POŽADAVKY NA ZÁZNAMOVÉ ZAŘÍZENÍ U NAMONTOVANÉHO
ADAPTÉRU
4. KONSTRUKČNÍ A FUNKČNÍ POŽADAVKY NA ADAPTÉR
4.1. Propojení a přizpůsobení přicházejících impulsů rychlosti
4.2. Indukce přicházejících impulsů do zabudovaného snímače pohybu
4.3. Zabudovaný snímač pohybu
4.4. Bezpečnostní požadavky
4.5. Provozní charakteristiky
4.6. Materiály
4.7. Značení
5. MONTÁŽ ZÁZNAMOVÉHO ZAŘÍZENÍ PŘI POUŽITÍ ADAPTÉRU
5.1. Montáž
5.2. Plomby
6. KONTROLY, PROHLÍDKY A OPRAVY
6.1. Periodické prohlídky
7. SCHVÁLENÍ TYPU ZÁZNAMOVÉHO ZAŘÍZENÍ PŘI POUŽITÍ
ADAPTÉRU
7.1. Všeobecně
7.2. Osvědčení o funkčnosti
1. ZKRATKY A REFERENČNÍ DOKUMENTY
1.1. Zkratky
TBD bude stanoveno později
VU celek ve vozidle (Vehicle Unit)
1.2. Referenční normy
ISO16844-3 Road vehicles – Tachograph systems – Part 3: Motion sensor
interface (Silniční vozidla – Systémy tachografu – Část 3: Rozhraní
snímače pohybu
2. VŠEOBECNÉ CHARAKTERISTIKY A FUNKCE ADAPTÉRU
2.1. Všeobecný popis adaptéru
ADA_001 Adaptér dodává připojenému celku ve vozidle (VU) zabezpe­
čené údaje o pohybu vozidla trvale odpovídající rychlosti
vozidla a vzdálenosti ujeté vozidlem.
Adaptér je určen pouze pro vozidla, která musí být vybavena
záznamovým zařízením v souladu s tímto nařízením.
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 599
Musí být namontován a používán pouze u typů vozidel vyme­
zených v definici yy) „adaptér“ přílohy IC, u kterých není
mechanicky možné namontovat jiný typ existujícího snímače
pohybu, který je jinak v souladu s ustanoveními této přílohy
a dodatků 1 až 16.
Adaptér nesmí být mechanicky propojen s pohyblivou částí
vozidla, ale je napojen na impulsy rychlosti/vzdálenosti, které
jsou generovány integrovanými snímači nebo alternativními
rozhraními.
ADA_002 Snímač pohybu schváleného typu (podle ustanovení této
přílohy IC oddílu 8, Schválení typu záznamového zařízení
a karet tachografu) musí být umístěn do skříně adaptéru,
která musí obsahovat také zařízení na převod impulsů induku­
jící přicházející impulsy do zabudovaného snímače pohybu.
Vlastní zabudovaný snímač pohybu musí být propojen s celkem
ve vozidle tak, aby rozhraní mezi celkem ve vozidle a adap­
térem bylo v souladu s požadavky normy ISO 16844-3.
2.2. Funkce
ADA_003 Adaptér musí zajišťovat tyto funkce:
— propojení a přizpůsobování příchozích impulsů rychlosti,
— indukci přicházejících impulsů do zabudovaného snímače
rychlosti,
— všechny funkce zabudovaného snímače pohybu dodávající
zabezpečené údaje o pohybu vozidla do celku ve vozidle.
2.3. Zabezpečení
ADA_004 Zabezpečení systému adaptéru není certifikováno na základě
všeobecného bezpečnostního cíle pro snímače pohybu defino­
vaného v dodatku 10 této přílohy. Namísto toho se použijí
požadavky na zabezpečení specifikované v oddíle 4.4 tohoto
dodatku.
3. POŽADAVKY NA ZÁZNAMOVÉ ZAŘÍZENÍ U NAMONTOVANÉHO
ADAPTÉRU
Požadavky uvedené v následujících kapitolách udávají, jak je třeba
rozumět požadavkům v této příloze, je-li použit adaptér. Příslušná čísla
požadavků přílohy IC jsou uvedena v závorkách.
ADA_005 Záznamové zařízení každého vozidla vybaveného adaptérem
musí být v souladu se všemi ustanoveními této přílohy
kromě případů, kdy je v tomto dodatku uvedeno jinak.
ADA_006 Je-li namontován adaptér, záznamové zařízení zahrnuje kabely,
adaptér (včetně snímače pohybu) a celek ve vozidle [01].
ADA_007 Funkce detekce událostí a/nebo závad záznamového zařízení se
pozměňuje takto:
— událost „přerušení elektrického napájení“ aktivuje celek ve
vozidle, pokud zařízení není v kalibračním režimu, při
každém přerušení elektrického napájení zabudovaného
snímače pohybu delším než 200 milisekund [79],
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 600
— událost „chybné údaje o pohybu vozidla“ aktivuje celek ve
vozidle při přerušení normálního toku dat mezi zabudo­
vaným snímačem pohybu a celkem ve vozidle a/nebo
v případě chyby integrity nebo ověření pravosti dat přená­
šených mezi zabudovaným snímačem pohybu a celkem ve
vozidle [83],
— událost „pokus o narušení zabezpečení“ aktivuje celek ve
vozidle v jakémkoli jiném případě, který ohrožuje zabez­
pečení zabudovaného snímače pohybu, pokud zařízení není
v kalibračním režimu [85],
— chybu „záznamového zařízení“ aktivuje celek ve vozidle,
pokud zařízení není v kalibračním režimu, v případě jaké­
koliv závady na zabudovaném snímači pohybu [88].
ADA_008 Závady adaptéru zjistitelné záznamovým zařízením jsou závady
související se zabudovaným snímačem pohybu [88].
ADA_009 Kalibrační funkce celku ve vozidle musí umožnit automatické
spárování zabudovaného snímače pohybu a celku ve vozidle
[202, 204].
4. KONSTRUKČNÍ A FUNKČNÍ POŽADAVKY NA ADAPTÉR
4.1. Propojení a přizpůsobení přicházejících impulsů rychlosti
ADA_011 Vstupní rozhraní adaptéru musí přijímat frekvenční impulsy
odpovídající rychlosti vozidla a vzdálenosti ujeté vozidlem.
Elektrické charakteristiky přicházejících impulsů jsou: definuje
výrobce. Úpravy přístupné pouze výrobci adaptéru a schválené
dílně provádějící montáž adaptéru musí v příslušných přípa­
dech umožnit správné propojení vstupu adaptéru s vozidlem.
▼M3
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.
▼B
4.2. Indukce přicházejících impulsů do zabudovaného snímače pohybu
ADA_013 Přicházející impulsy, případně přizpůsobené výše uvedeným
způsobem, musí být indukovány do zabudovaného snímače
pohybu tak, aby každý přicházející impuls byl snímačem
pohybu detekován.
4.3. Zabudovaný snímač pohybu
ADA_014 Zabudovaný snímač pohybu musí být stimulován indukova­
nými impulsy, což mu umožní generovat údaje o pohybu
vozidla přesně odpovídající pohybu vozidla, jako by byl
mechanicky propojen s pohyblivou částí vozidla.
ADA_015 K identifikaci adaptéru využívá celek ve vozidle identifikační
data zabudovaného snímače pohybu [95].
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 601
ADA_016 Montážní data uložená v zabudovaném snímači pohybu jsou
považována za data představující montážní data adaptéru [122].
4.4. Bezpečnostní požadavky
ADA_017 Skříň adaptéru musí být konstruována tak, aby ji nebylo možno
otevřít. Musí být opatřena plombou, aby bylo možné snadno
zjistit pokusy o nepovolenou manipulaci (např. vizuální
kontrolou, viz ADA_035). Plomby musí splňovat stejné poža­
davky jako plomby na snímačích pohybu [398 až 406].
ADA_018 Nesmí být možné odstranit zabudovaný snímač pohybu z adap­
téru bez porušení plomby (plomb) skříně adaptéru nebo poru­
šení plomby mezi snímačem a skříní adaptéru (viz ADA_034).
ADA_019 Adaptér musí zajistit, aby údaje o pohybu vozidla mohly být
zpracovávány a odvozovány pouze ze vstupu adaptéru.
4.5. Provozní charakteristiky
ADA_020 Adaptér musí být plně provozuschopný v rozsahu teplot defi­
novaném výrobcem.
ADA_021 Adaptér musí být plně provozuschopný v rozsahu vlhkostí od
10 % do 90 % [214].
ADA_022 Adaptér musí být chráněn proti přepětí, záměně polarity napá­
jecího napětí a zkratu [216].
ADA_023 Adaptér musí buď:
— reagovat na magnetické pole, které ruší detekci pohybu
vozidla; za takových okolností celek ve vozidle zaznamená
a uloží závadu snímače [88]; nebo
— musí mít snímací prvek, který je chráněn proti magne­
tickým polím, případně je vůči jejich působení imunní
[217].
ADA_024 Adaptér musí odpovídat mezinárodnímu předpisu EHK OSN
R10, vztahujícímu se k elektromagnetické kompatibilitě,
a musí být chráněn proti elektrostatickým výbojům a přecho­
dovým jevům [218].
4.6. Materiály
ADA_025 Adaptér musí splňovat stupeň ochrany (definují výrobci v závi­
slosti na montážní poloze) [220, 221].
ADA_026 Barva skříně adaptéru je žlutá.
4.7. Značení
ADA_027 K adaptéru musí být připevněn popisný štítek, který obsahuje
tyto údaje:
— název a adresu výrobce adaptéru,
— katalogové číslo adaptéru podle výrobce a rok jeho výroby,
— značku schválení typu adaptéru nebo záznamového zařízení
zahrnujícího adaptér,
— datum montáže adaptéru,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 602
— identifikační číslo vozidla, do něhož byl namontován.
ADA_028 Popisný štítek dále obsahuje tyto údaje (pokud je není možno
přímo přečíst na vnější straně zabudovaného snímače pohybu):
— název výrobce zabudovaného snímače pohybu,
— katalogové číslo zabudovaného snímače pohybu podle
výrobce a rok jeho výroby,
— značka schválení typu zabudovaného snímače pohybu.
5. MONTÁŽ ZÁZNAMOVÉHO ZAŘÍZENÍ PŘI POUŽITÍ ADAPTÉRU
5.1. Montáž
ADA_029 Adaptéry musí být do vozidel montovány pouze výrobci
vozidel nebo schválenými dílnami oprávněnými k montáži,
aktivaci a kalibraci digitálních a inteligentních tachografů.
ADA_030 Schválená dílna provádějící montáž adaptéru musí seřídit
vstupní rozhraní a zvolit dělicí poměr vstupního signálu (v
příslušných případech).
ADA_031 Schválená dílna provádějící montáž adaptéru musí skříň adap­
téru zaplombovat.
ADA_032 Adaptér musí být namontován co možná nejblíže té části
vozidla, která zajišťuje přicházející impulsy.
ADA_033 Kabely pro přívod energie do adaptéru musí být červené
(kladný pól) a černé (uzemnění).
5.2. Plomby
ADA_034 Platí tyto požadavky na plombování:
— skříň adaptéru musí být zaplombovaná (viz ADA_017),
— jestliže je možné odstranit zabudovaný snímač ze skříně
adaptéru bez poškození plomby (plomb) skříně adaptéru,
musí být skříň zabudovaného snímače plombou spojena
se skříní adaptéru (viz ADA_018),
— skříň adaptéru musí být plombou spojena s vozidlem,
— propojení adaptéru a zařízení, které zajišťuje přicházející
impulsy, musí být zaplombováno na obou koncích (pokud
je to přiměřeně možné).
6. KONTROLY, PROHLÍDKY A OPRAVY
6.1. Periodické prohlídky
ADA_035 Při použití adaptéru musí každá pravidelná prohlídka (pravi­
delnou prohlídkou se rozumí prohlídka v souladu s požadavky
[409] až [413] přílohy 1C) záznamového zařízení zahrnovat
kontroly, zda:
— adaptér nese správnou značku schválení typu,
— plomby na adaptéru a jeho připojeních jsou neporušené,
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 603
— adaptér je namontován tak, jak je uvedeno na montážním
štítku,
— adaptér je namontován podle pokynů výrobce adaptéru
a/nebo vozidla,
— montáž adaptéru je pro kontrolované vozidlo schválená.
ADA_036 Tyto prohlídky musí zahrnovat kalibraci a výměnu všech
plomb bez ohledu na jejich stav.
7. SCHVÁLENÍ TYPU ZÁZNAMOVÉHO ZAŘÍZENÍ PŘI POUŽITÍ
ADAPTÉRU
7.1. Všeobecně
ADA_037 Záznamové zařízení musí být předloženo ke schválení typu
úplné, včetně adaptéru [425].
ADA_038 Každý adaptér může být předložen ke schválení typu samo­
statně nebo jako součást záznamového zařízení.
ADA_039 Uvedené schválení typu musí zahrnovat funkční zkoušky
zahrnující adaptér. Kladné výsledky každé z těchto zkoušek
jsou uvedeny v příslušném osvědčení [426].
7.2. Osvědčení o funkčnosti
ADA_040 Osvědčení o funkčnosti adaptéru nebo záznamového zařízení
zahrnujícího adaptér musí být výrobci adaptéru doručeno až po
úspěšném absolvování všech funkčních zkoušek v tomto mini­
málním rozsahu.
Č. Zkouška Popis Související požadavky
1. Administrativní šetření
1.1 Dokumentace Správnost dokumen­
tace adaptéru
2. Vizuální kontrola
2.1. Shoda adaptéru s dokumentací
2.2. Identifikace/značení adaptéru ADA_027,
ADA_028
2.3 Materiály použité v adaptéru [219] až [223]
ADA_026
2.4. Plomby ADA_017,
ADA_018,
ADA_034
3. Funkční zkoušky
3.1 Indukce impulsů rychlosti do zabudovaného
snímače pohybu
ADA_013
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 604
Č. Zkouška Popis Související požadavky
3.2 Propojení a přizpůsobení přicházejících impulsů
rychlosti
ADA_011,
ADA_012
3.3 Přesnost měření pohybu vozidla [30] až [35], [217]
4. Environmentální zkoušky
4.1 Výsledky zkoušek výrobce Výsledky environ­
mentálních zkoušek
výrobce
ADA_020,
ADA_021,
ADA_022,
ADA_024
5. Elektromagnetická kompatibilita (EMC)
5.1 Vyzařované emise a citli­
vost
Ověření shody se
směrnicí 2006/28/
ES
ADA_024
5.2 Výsledky zkoušek výrobce Výsledky environ­
mentálních zkoušek
výrobce
ADA_024
▼B
02016R0799 — CS — 21.08.2023 — 003.002 — 605
Dodatek 17
PŘECHODNÁ USTANOVENÍ TÝKAJÍCÍ SE VYUŽÍVÁNÍ SLUŽBY
OSNMA U TACHOGRAFŮ
1. DEFINICE A ZKRATKY
1.1. Definice
Prohlášením otevřené služby systému Galileo pro ověření pravosti
navigačních zpráv (OSNMA) se rozumí prohlášení Evropské komise
o uvedení služby Galileo OSNMA do fáze provozu.
Přechodný celek ve vozidle: Celek ve vozidle, který splňuje požadavky
tohoto dodatku.
Přechodné celky ve vozidle jsou konstruovány v souladu s dokumentem
SIS ICD a pokyny k přijímačům OSNMA platnými pro fázi veřejného
testování OSNMA. Obsahují přijímač GNSS, který je schopen využívat
službu OSNMA dostupnou během fáze jejího veřejného testování.
Přechodné celky ve vozidle však kvůli nezbytné aktualizaci kryptografic­
kého materiálu v celku ve vozidle nemohou ověřovat dostupné navigační
zprávy po datu prohlášení služby OSNMA. K tomu, aby mohly začít
využívat OSNMA a splňovat všechny požadavky přílohy IC a jejích
dodatků 1 až 16, je třeba provést náležitou aktualizaci softwaru. Před
aktualizací implementují přechodné celky ve vozidle funkce týkající se
OSNMA podle specifikací v tomto dodatku. Funkce, které se netýkají
OSNMA, zůstávají beze změny.
Náležitou aktualizací softwaru implementují přechodné celky ve vozidle
dokument SIS ICD a pokyny k přijímačům OSNMA platné pro fázi
provozu OSNMA a splňují všechny požadavky přílohy IC a jejích
dodatků 1 až 16, přičemž využívají službu OSNMA dostupnou během
fáze provozu.
Přechodný tachograf: tachograf včetně přechodného celku ve vozidle.
1.2. Zkratky
ICD kontrolní dokument rozhraní (Interface Control
Document)
OSNMA otevřená služba systému Galileo pro ověření
pravosti navigačních zpráv (Galileo Open Service
Navigation Message Authentication)
SIS signál v prostoru (Signal in Space)
VU celek ve vozidle (Vehicle Unit)
▼M4
02016R0799 — CS — 21.08.2023 — 003.002 — 606
2. OBECNÉ ÚVAHY TÝKAJÍCÍ SE OSNMA
Aby mohla být vozidla registrovaná poprvé vybavena druhou verzí tacho­
grafů druhé generace, počínaje požadovaným datem zavedení podle defi­
nice v příloze IC oddíle 1 písm. ccc) prováděcího nařízení (EU) 2016/799,
je třeba typově schválit, vyrábět a uvádět na trh celky ve vozidle před
vydáním prohlášení služby OSNMA. Pro tyto celky ve vozidle označo­
vané jako přechodné celky ve vozidle je třeba upravit požadavky týkající
se OSNMA uvedené v příloze IC a jejích dodatcích 1 až 16, aby mohly
být typově schváleny a používány v praxi.
Ustanovení tohoto dodatku definují zvláštní požadavky použitelné na
přechodné celky ve vozidle. Vztahují se pouze na celky ve vozidle
s vnitřním přijímačem GNSS.
3. POŽADAVKY NA PŘIJÍMAČ GNSS U PŘECHODNÝCH TACHO­
GRAFŮ
TRA_001 Přechodné celky ve vozidle obsahují přijímač GNSS, který je
schopen využívat službu OSNMA dostupnou během fáze jejího veřejného
testování.
TRA_002 Požadavky dodatku 12 se vztahují na přijímač GNSS, který je
součástí přechodných celků ve vozidle, s těmito výklady:
— Dokumentem SIS ICD a pokyny k přijímačům OSNMA se rozumí
tyto dokumenty dostupné pro fázi veřejného testování:
— Galileo Open Service Navigation Message Authentication
(OSNMA) User ICD for the Test Phase, vydání 1.0, listopad 2021,
— Galileo Open Service Navigation Message Authentication
(OSNMA) Receiver Guidelines for the Test Phase, vydání 1.0,
listopad 2021,
— OSNMA je služba dostupná během fáze veřejného testování,
— SIS je signál v prostoru (Signal in Space) dostupný během fáze veřej­
ného testování.
TRA_003 Přijímač GNSS, který je součástí přechodných celků ve
vozidle, musí být navržen tak, aby po aktualizaci svého softwaru prove­
dené aktualizací softwaru celku ve vozidle plně splňoval požadavky
dodatku 12 při využívání služby OSNMA dostupné během její fáze
provozu.
4. POŽADAVKY NA PŘECHODNÉ CELKY VE VOZIDLE
Přechodné celky ve vozidle mohou zpracovávat signál OSNMA dostupný
během fáze jejího veřejného testování, ale nejsou schopny hlásit status
ověření pravosti navigačních zpráv ze SIS, který je dostupný během
fáze provozu OSNMA, dokud se neprovede náležitá aktualizace softwaru.
Z toho důvodu přechodné celky ve vozidle pracují s předpokladem, že
standardní polohy poskytované přijímačem GNSS jsou vždy ověřené.
Použijí se požadavky přílohy IC a jejích dodatků 1 až 16 s těmito
výklady.
▼M4
02016R0799 — CS — 21.08.2023 — 003.002 — 607
TRA_004 V příloze IC bodě 3.9.15 „Nesoulad času“ se požadavkem 86
rozumí:
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 ze standardní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 stano­
vené 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.
TRA_005 V příloze IC bodě 3.9.18 „Anomálie GNSS“ se požadavkem
88a rozumí:
Tato událost nastane, není-li zařízení v kalibračním režimu, pokud
přijímač GNSS zjistí útok , 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.
TRA_006 V příloze IC bodě 3.12.5 Zaznamenávání a ukládání do datové
paměti, Místa a polohy, kde začíná nebo končí denní pracovní doba a/nebo
kde je dosaženo tří hodin součtové doby řízení se požadavkem 110
rozumí:
Společně s příslušným místem nebo polohou musí záznamové zařízení
zaznamenat a uložit do 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 vložení údajů,
— typ vložených údajů (začátek a konec nebo tři hodiny součtové doby
řízení),
— příslušnou přesnost GNSS, v příslušných případech datum a čas,
— stav počitadla ujetých kilometrů,
— příznak informující, že poloha se považuje za ověřenou.
TRA_007 V příloze IC bodě 3.12.17 Zaznamenávání a ukládání do
datové paměti, Překročení hranic, se požadavkem 133b rozumí:
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í, že poloha se považuje za ověřenou,
— stav počitadla ujetých kilometrů vozidla v okamžiku detekce překročení
hranice.
▼M4
02016R0799 — CS — 21.08.2023 — 003.002 — 608
TRA_008 V příloze IC bodě 3.12.18 Zaznamenávání a ukládání do
datové paměti, Operace nakládky/vykládky, se požadavkem 133 g rozumí:
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í, že poloha se považuje za ověřenou,
— stav počitadla ujetých kilometrů.
TRA_009 V příloze IC bodě 3.23 Nastavení času se požadavkem 211
rozumí:
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
zprávy o platné standardní 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 časem vnitřních hodin celku ve vozidle a časem přijímače
GNSS větší než součtová maximální časová odchylka za den, musí se čas
vnitřních hodin celku ve vozidle po přenastavení času 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 standardní poloze,
jak je uvedeno v dodatku 12. Referenční čas pro automatické nastavení
času vnitřních hodin celku ve vozidle je čas uvedený ve zprávě o standardní
poloze.
TRA_010 V příloze IC bodě 3.23 Nastavení času se požadavkem 212
rozumí:
Funkce nastavení času musí rovněž umožňovat spustit nastavení aktuál­
ního času v kalibračním režimu.
Dílny mohou upravit čas:
— buď zapsáním časové hodnoty v celku ve vozidle pomocí služby Write­
DataByIdentifier 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 standardní poloze.
V takovém případě se služba RoutineControl použije v souladu
s oddílem 8 dodatku 8.
▼M4
02016R0799 — CS — 21.08.2023 — 003.002 — 609
TRA_011 V dodatku 4 bodě 2 Specifikace datových bloků se sedmou
odrážkou prvního pododstavce rozumí:
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, pikto­
gram označuje, že tato poloha se považuje za ověřenou.
TRA_012 V dodatku 8 bodě 8.1 Služba RoutineControl (nastavení času),
Popis zprávy se požadavkem CPR_065a rozumí:
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 standardní
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.: nastavení času může nějakou dobu trvat. Diagnostické zkušební
zařízení požádá o status nastavení času pomocí dílčí funkce requestRou­
tineResults.
TRA_013 V dodatku 12 bodě 3 Věty poskytované přijímačem GNSS se
požadavkem GNS_4a rozumí:
Údaje obsažené ve větách AMC poskytovaných přijímačem GNSS, pokud
existují, nesmí být použity celkem ve vozidle, s výjimkou těchto hodnot
statusu:
J = rušení nebo O = jiný útok na GNSS (díky kontrolám konzistence podle
GNS_3a),
V = neplatné (ověřená poloha není k dispozici z jakéhokoli jiného
důvodu).
TRA_014 V dodatku 12 bodě 3 Věty poskytované přijímačem GNSS se
požadavkem GNS_5 rozumí:
Údaje obsažené ve větách ASA poskytovaných přijímačem GNSS, pokud
existují, nesmí být použity celkem ve vozidle.
TRA_015 V dodatku 12 bodě 5.2 Celek ve vozidle bez vnějšího zařízení
GNSS, Přenos informací z přijímače GNSS do celku ve vozidle se poža­
davky GNS_34 a 36 rozumí:
Procesor VU nesmí používat informace extrahované z věty AMC,
s výjimkou těchto hodnot statusu:
J = rušení nebo O = jiný útok na GNSS (díky kontrolám konzistence podle
GNS_3a),
V = neplatné (ověřená poloha není k dispozici z jakéhokoli jiného
důvodu).
Procesor VU nesmí používat informace extrahované z věty ASA.
▼M4
02016R0799 — CS — 21.08.2023 — 003.002 — 610
TRA_016 V dodatku 12 bodě 6 Zpracování a zaznamenávání údajů
o poloze VU se požadavkem GNS_39 rozumí:
Údaje o poloze musí být uloženy v celku ve vozidle spolu s příznakem
informujícím, zda se poloha považuje za ověřenou. Pokud je nutné zazna­
menávat údaje o poloze v celku ve vozidle, použije se toto pravidlo:
a) Jestliže je standardní poloha platná, zaznamená se standardní poloha
a její přesnost v celku ve vozidle a příznak se nastaví na „ověřena“.
TRA_017 V dodatku 12 bodě 6 Zpracování a zaznamenávání údajů
o poloze VU se požadavkem GNS_40 rozumí:
Je-li hodnota statusu v přijaté větě AMC nastavena na hodnotu „J“ nebo
„O“ 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“.
TRA_018 V dodatku 12 bodě 8 Nesoulad údajů o pohybu vozidla se
první a druhou odrážkou Spouštěcí podmínky 2 požadavku GNS_42
rozumí:
— GnssDistance je vzdálenost mezi aktuální polohou vozidla a předchozí
polohou, obě získané ze zpráv o platné standardní poloze 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řed­
chozí zprávě o platné standardní poloze,
TRA_019 V dodatku 14 bodě 5.4.5 Požadavky protokolu DSRC pro
RTM, Prvky RTMData, provedené akce a definice se druhou buňkou
v řádku RTM20 v tabulce 14.3 pod požadavkem DSC_41 rozumí:
VU vygeneruje celočíselnou hodnotu (timeReal z dodatku 1) pro datový
prvek RTM20.
VU nastaví hodnotu RTM20 na čas, kdy byla k dispozici poslední stan­
dardní poloha vozidla z přijímače GNSS.
Pokud z přijímače GNSS nebyla k dispozici žádná standardní poloha
vozidla, VU nastaví hodnotu RTM20 na 0.
TRA_020 Výrobce typově schváleného přechodného celku ve vozidle
informuje Komisi o svých verzích softwaru. Komise tyto verze softwaru
zveřejní na veřejně dostupných internetových stránkách.
▼M4
02016R0799 — CS — 21.08.2023 — 003.002 — 611
5. ZVLÁŠTNÍ USTANOVENÍ PRO SCHVALOVÁNÍ TYPU A POUŽÍ­
VÁNÍ PŘECHODNÝCH TACHOGRAFŮ
TRA_021 Přechodné celky ve vozidle musí být typově schváleny podle
požadavků přílohy IC a jejích dodatků 1 až 16 doplněných ustanoveními
tohoto dodatku.
TRA_022 Osvědčení o schválení typu přechodných celků ve vozidle
a přechodných tachografů lze požadovat pouze do 31. prosince 2023
nebo do data prohlášení služby OSNMA, podle toho, co nastane později.
TRA_023 Přechodné celky ve vozidle mohou být do vozidel registrova­
ných poprvé montovány pouze do 31. května 2024 nebo pět měsíců po
datu prohlášení služby OSNMA, podle toho, co nastane později.
▼M4
02016R0799 — CS — 21.08.2023 — 003.002 — 612
PŘÍLOHA II
ZNAČKA SCHVÁLENÍ A OSVĚDČENÍ
I. ZNAČKA SCHVÁLENÍ
1. Značka schválení sestává:
a) z obdélníku, ve kterém je písmeno „e“ a rozlišovací číslo, nebo písmena
země, která udělila schválení, v souladu s těmito dohodnutými značkami:
Belgie 6,
Bulharsko 34,
Česká republika 8,
Dánsko 18,
Německo 1,
Estonsko 29,
Irsko 24,
Řecko 23,
Španělsko 9,
Francie 2,
Chorvatsko 25,
Itálie 3,
Kypr CY,
Lotyšsko 32,
Litva 36,
Lucembursko 13,
Maďarsko 7,
Malta MT,
Nizozemsko 4,
Rakousko 12,
Polsko 20,
Portugalsko 21,
Rumunsko 19,
Slovinsko 26,
Slovensko 27,
Finsko 17,
Švédsko 5,
Spojené království 11,
a
▼M1
b) z čísla schválení, které odpovídá číslu osvědčení o schválení vystaveného
pro prototyp záznamového zařízení nebo záznamového listu nebo karty
tachografu a které se umístí kdekoli v bezprostřední blízkosti obdélníku.
▼C1
02016R0799 — CS — 21.08.2023 — 003.002 — 613
2. Značka schválení musí být připojena na popisný štítek každého souboru zaří­
zení, na každý záznamový list a na každou kartu tachografu. Musí být nesma­
zatelná a trvale dobře čitelná.
3. Minimální rozměry značky schválení uvedené níže ( 1 ) jsou vyjádřeny v mili­
metrech. Poměr mezi jednotlivými rozměry musí být zachován.
▼C1
( 1 ) Tato čísla jsou uvedena jen jako příklad.
02016R0799 — CS — 21.08.2023 — 003.002 — 614
II. OSVĚDČENÍ O SCHVÁLENÍ ANALOGOVÝCH TACHOGRAFŮ
Členský stát, který udělil schválení, vystaví žadateli osvědčení o schválení podle
níže uvedeného vzoru. Pro informování ostatních členských států o vydaných
nebo případně odebraných schváleních používají členské státy toto osvědčení.
OSVĚDČENÍ O SCHVÁLENÍ
Název příslušného správního orgánu
Sdělení týkající se ( 1 ):
— schválení typu záznamového zařízení
— odebrání schválení typu záznamového zařízení
— schválení vzoru záznamového listu
— odebrání schválení vzoru záznamového listu
Schválení č.:
...................................
1. Výrobní nebo obchodní značka
2. Označení typu nebo modelu
3. Jméno výrobce
4. Adresa výrobce
5. Předloženo ke schválení dne
6. Zkušební laboratoř(e)
7. Datum a číslo zkoušky/zkoušek
8. Datum schválení
9. Datum odebrání schválení
10. Typ/typy záznamového zařízení, s nímž/s nimiž má být záznamový list
používán
11. Místo
12. Datum
13. Přiložená dokumentace
14. Poznámky (včetně umístění případných plomb)
(Podpis)
▼C1
( 1 ) Nehodící se škrtněte.
02016R0799 — CS — 21.08.2023 — 003.002 — 615
III. OSVĚDČENÍ O SCHVÁLENÍ DIGITÁLNÍCH TACHOGRAFŮ
Členský stát, který udělil schválení, vystaví žadateli osvědčení o schválení podle
níže uvedeného vzoru. Pro informování ostatních členských států o vydaných
nebo případně odebraných schváleních používají členské státy toto osvědčení.
OSVĚDČENÍ O SCHVÁLENÍ DIGITÁLNÍCH TACHOGRAFŮ
Název příslušného správního orgánu
Sdělení týkající se ( 1 ):
□ schválení: □ odebrání schválení:
□ modelu záznamového zařízení
□ části záznamového zařízení ( 2 )
□ karty řidiče
□ karty dílny
□ karty podniku
□ karty kontrolora
Schválení č.:
1. Výrobní nebo obchodní značka
2. Označení modelu
3. Jméno výrobce
4. Adresa výrobce
▼M1
5. Předloženo k schválení dne
▼C1
6. Zkušební laboratoř(e)
7. Datum a číslo zkušebního protokolu
8. Datum schválení
9. Datum odebrání schválení
10. Vzor záznamového/záznamových zařízení, s nímž/s nimiž má být část použí­
vána
11. Místo
12. Datum
13. Přiložená dokumentace
14. Poznámky (včetně umístění případných plomb)
(Podpis)
▼C1
( 1 ) Označte příslušná okénka.
( 2 ) Uveďte část, jíž se oznámení týká.
02016R0799 — CS — 21.08.2023 — 003.002 — 616
IV. OSVĚDČENÍ O SCHVÁLENÍ INTELIGENTNÍCH TACHOGRAFŮ
Členský stát, který udělil schválení, vystaví žadateli osvědčení o schválení podle
níže uvedeného vzoru. Pro informování ostatních členských států o vydaných
nebo případně odebraných schváleních používají členské státy toto osvědčení.
OSVĚDČENÍ O SCHVÁLENÍ INTELIGENTNÍCH TACHOGRAFŮ
Název příslušného správního orgánu
Sdělení týkající se ( 1 ):
□ schválení: □ odebrání schválení:
□ modelu záznamového zařízení
□ části záznamového zařízení ( 2 )
□ karty řidiče
□ karty dílny
□ karty podniku
□ karty kontrolora
Schválení č.:
1. Výrobní nebo obchodní značka
2. Označení modelu
3. Jméno výrobce
4. Adresa výrobce
▼M1
5. Předloženo k schválení dne
▼C1
6. a) Zkušební laboratoř pro udělování osvědčení o funkčnosti
b) Zkušební laboratoř pro udělování osvědčení o bezpečnosti
c) Zkušební laboratoř pro udělování osvědčení o interoperabilitě
7. a) Datum a číslo osvědčení o funkčnosti
b) Datum a číslo osvědčení o bezpečnosti
c) Datum a číslo osvědčení o interoperabilitě
8. Datum schválení
9. Datum odebrání schválení
10. Vzor záznamového/záznamových zařízení, s nímž/s nimiž má být část použí­
vána
11. Místo
12. Datum
13. Přiložená dokumentace
14. Poznámky (včetně umístění případných plomb)
(Podpis)
▼C1
( 1 ) Označte příslušná okénka.
( 2 ) Uveďte část, jíž se oznámení týká.


Full & Egal Universal Law Academy