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  8 5  1  28.3.2018  
►M2 Prováděcí nařízení Komise (EU) 2020/158 ze dne 5. února 2020  L  3 4  2 0  6.2.2020  
►M3 Prováděcí nařízení Komise (EU) 2021/1228 ze dne 16. července 2 021 L 273  1  30.7.2021  
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.001 — 1
02016R0799 — CS — 21.08.2023 — 003.001 — 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é upla tň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 intelige ntní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ále ní 
typu tachografů, včetně bezpečnostních mechanismů.  
▼M1 
2. Konstrukce, zkoušení, montáž, kontrola, provoz a opravy inte li­
gentních tachografů a jejich součástí musí splňovat technické p ožadavky 
stanovené v příloze IC tohoto nařízení.  
3. Tachografy jiné než inteligentní musí nadále, pokud jde o je jich 
konstrukci, zkoušení, montáž, kontrolu, provoz a opravy, splňov at 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ře dávat 
údaje o hmotnosti poskytované interním palubním systémem pro zj iš­ 
ť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ánk u 2 
nařízení (EU) č. 165/2014.  ▼B 
( 1 ) Nařízení Rady (EHS) č. 3821/85 ze dne 20. prosince 1985 o záz namové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. d ubna 2014 
o harmonizaci právních předpisů členských států týkajících se d odá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.001 — 3  
Kromě toho se rozumí:  
1) „digitálním tachografem“ nebo „tachografem první generace“ d igi­
tální tachograf, který není inteligentním tachografem;  
2) „vnějším zařízením GNSS“ zařízení, které obsahuje přijímač G NSS 
v případě, kdy celek ve vozidle není jediným celkem, jakož i da lší 
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í typ u 
tachografu nebo jeho konstrukční součásti na konci postupu schv a­
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 kon trol; 
▼M1 
7) „inteligentním tachografem“ nebo „tachografem druhé generace “ 
digitální tachograf, který splňuje požadavky článků 8, 9 a 10 n aří­
zení (EU) č. 165/2014, jakož i přílohy IC tohoto nařízení;  
8) „součástí tachografu“ kterýkoli z těchto prvků: celek ve voz idle, 
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í ja ko 
kontaktní místo pro orgány příslušné pro schvalování typu ostat ní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 k abelů 
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ěť, fu nkci 
měření času, dvě čtecí zařízení čipových karet pro řidiče a dru hého  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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éha jí 
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álkovo u 
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 kompatibil ní se 
službami určování polohy, které poskytují systémy Galileo a evr opská 
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í or gá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ě os vě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 dokumen tů. 
2. Členský stát udělí schválení typu všem tachografům, součáste m 
nebo skupinám součástí, které splňují administrativní a technic ké 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 žad ateli 
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 ne bo 
jeho zmocněnce o předložení jakýchkoli dalších informací.  ▼M1
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 dispozic i 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í t ypu 
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, je jichž 
typ byl již schválen, jakož i ostatní součásti nezbytné pro kon strukci 
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í tachogr afu 
nebo povahy materiálů použitých k jeho výrobě, které jsou zazna me­
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ál ení 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á revido vané 
dokumenty schvalovací dokumentace a uvede povahu provedených 
změn a datum jejich schválení. Pro splnění tohoto požadavku pos tačuje 
aktualizovaná verze schvalovací dokumentace v konsolidované pod obě 
spolu s podrobným popisem provedených změn.  
„Rozšíření“ se provede, jestliže se orgán příslušný pro schvalo vá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ýznam né. 
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 jso u 
tyto zkoušky uspokojivé, vydá orgán příslušný pro schvalování t ypu 
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í kons olidace 
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í vedl y k vydání 
nového osvědčení o bezpečnosti nebo interoperabilitě.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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í praco vní 
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.001 — 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í dob a 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 prv ní gene­ 
race ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 9  
3.14.2  Zaznamenávání a ukládání údajů na kartách tachografu druhé gen erace  
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 d ruhé 
generace)  
4.5.2.4 Informace o rozšířené délce (podmínečná, pouze v kartác h tacho­ 
grafu druhé generace)  
4.5.3 Karta řidiče  
4.5.3.1 Aplikace tachografu (přístupná pro celky ve vozidle prv ní 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.001 — 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 cel ek 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é ve rzi 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í pracov ní 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á dob a ří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 v ozidle druhé 
generace)  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 11  
4.5.3.2.20 Operace nakládky/vykládky (není přístupné verzi 1 ce lků 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 vozi dle druhé 
generace)  
▼B 
4.5.4 Karta dílny  
4.5.4.1 Aplikace tachografu (přístupná pro celky ve vozidle prv ní 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 cel ek 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é ve rzi 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.001 — 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á dob a ří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 v ozidle druhé 
generace)  
4.5.4.2.19 Operace nakládky/vykládky (není přístupné verzi 1 ce lků 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 vozi dle druhé 
generace)  
▼B 
4.5.5 Kontrolní karta  
4.5.5.1 Aplikace tachografu (přístupná pro celky ve vozidle prv ní 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 cel ek 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é ve rzi 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 vozid le druhé 
generace)  
▼B 
4.5.6 Karta podniku  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 13  
4.5.6.1 Aplikace tachografu (přístupná pro celky ve vozidle prv ní 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 cel ek 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é ve rzi 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 vozid le 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.001 — 14  
ÚVOD  
Tato příloha obsahuje požadavky na záznamové zařízení a karty t achografu 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 tachogr afu druhé 
generace.  
Za účelem bezproblémového zavádění systému tachografů druhé gen erace byly 
karty tachografu druhé generace navrženy tak, aby byly používán y 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 d ruhé generace 
jsou specifikovány v této příloze. Dodatek 15 obsahuje v této s ouvislosti 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 tachogr afu 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.001 — 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 identi fi­
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.001 — 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í do by 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. Alte rnativní 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 zr ušení nařízení 
Rady (EHS) č. 3820/85 (Úř. věst. L 102, 11.4.2006, s. 1).
 02016R0799 — CS — 21.08.2023 — 003.001 — 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í do by 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. Alte rnativní 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.001 — 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, k terým se provádí 
nařízení Evropského parlamentu a Rady (ES) č. 661/2009, pokud j de 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 2 007/46/ES (Úř. věst. 
L 353, 21.12.2012, s. 31) v platném znění.
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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 mot orová 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 vozidl a 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.001 — 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.001 — 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, zobrazova t 
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.001 — 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 tachogra fu. 
▼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.001 — 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
 Otvor pro vložení karty druhého řidič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 t achografu 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.001 — 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 pravo sti 
ú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ýc h 
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 37  
Rozpor karet  Otvor pro vložení karty řidiče  
Bez karty  Karta řidiče  Kontrolní karta  Karta dílny  Karta podniku
 Otvor pro vložení karty druhého řidič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
 Otvor pro vložení karty druhého řidič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.001 — 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.001 — 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žim u, 
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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í jed né 
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.001 — 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.001 — 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.001 — 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í jed né 
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 kart y“ 
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 hranic i 
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 zem i 
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.001 — 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, kte rá 
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  N L  Nizozemsko  
D 
EST Německo 
Estonsko  A 
PL Rakousko 
Polsko  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  U K  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 administrati vní úč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.001 — 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.001 — 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.001 — 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í p ož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 tachograf u 
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.001 — 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.001 — 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.001 — 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.001 — 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í jed né 
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.001 — 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.001 — 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é ve rzi 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.001 — 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.001 — 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.001 — 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í jed né 
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.001 — 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í pracov ní 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.001 — 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.001 — 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.001 — 86  
4.5.3.2.18 Status ověření pravosti pro polohy, kde součtová dob a ří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 v ozidle 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 ce lků 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.001 — 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í tac ho­
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.001 — 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.001 — 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é ve rzi 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.001 — 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.001 — 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.001 — 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.001 — 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á dob a ří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 v ozidle 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 ce lků 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.001 — 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í tach o­
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.001 — 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é ve rzi 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.001 — 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.001 — 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é ve rzi 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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ěn y 
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 to uto 
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í s tř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.001 — 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.001 — 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.001 — 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í kart y 
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.001 — 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 sch vá­
lení typu záznamového zařízení.  
Jak je popsáno v definici uvedené v čl. 2 bodě 10 tohoto naříze ní, 
existují různé varianty montáže součástí celků ve vozidle. Bez 
ohledu na montáž součástí celku ve vozidle nejsou externí antén a 
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 celk u 
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.001 — 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.001 — 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.001 — 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 kon ci 
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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é st ruktury 
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 aplikac i 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ázv em 
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. I den­
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.001 — 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 Notatio n 
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ů sp očívá 
standardní hodnota pro „neznámý“ nebo „bezpředmětný“ obsah v na pl­
nění daného datového prvku bajty Hex „FF“.  
Není-li stanoveno jinak, všechny datové typy se použijí pro apl ikace 
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žadav ků 
v příloze IC týkajících se těchto datových typů zahrnují aplika ce 
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ŘE VOZ 
LODÍ / PŘEVOZ VLAKEM začátek“ specifické podmínky 
„PŘEVOZ LODÍ / PŘEVOZ VLAKEM“.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 123  
2.1 ActivityChangeInfo  
Tento datový typ umožňuje kódovat uvnitř dvoubajtového slova st atus 
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.001 — 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 k arta 
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 navole na. 
Jako výsledek ručního zadání mohou být bity „c“ a „aa“ slova (u lož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.001 — 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é deka dické 
čí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.001 — 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íc e oktetů 
se musí podle potřeby vložit od pozice levé vnější 4bitové skup iny 
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 parame trů. 
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 p o 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 OCT ET 
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.001 — 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 dostup né 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řípa dný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 ka rty 
o překročení hranic ve struktuře.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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žadav ky 
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 th e 
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“ (Z bytek 
světa – NationNumeric code „FF“H) se použije v případě, že cele k 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 z emě, 
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 „n ejsou 
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í integrova ného 
obvodu karty (IC) (požadavek 249 přílohy 1C). Číslo icSerialNum ber 
společně s číslem icManufacturingReferences jednoznačně identif ikují 
čip karty. Samotné číslo icSerialNumber není jednoznačnou ident ifikací 
čipu karty.
  
icSerialNumber  je výrobní číslo integrovaného obvodu.  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 3 50 
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.001 — 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 o d 
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řed tí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 activit yDa­
ilyRecord), která nahrazují starší data o činnosti, musí být ak tualizován 
ukazatel activityPointerOldestDayRecord, aby odrážel nové umíst ění 
nejstaršího úplného denního záznamu, a délka activityPreviousRe cord­
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.001 — 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.001 — 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 int egrovaný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.001 — 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ža davky 
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žadavk y 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.001 — 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 (p ož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 za dá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.001 — 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 dod atku 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é posky tují status 
ověření pravosti míst, kde začíná a/nebo končí denní pracovní d oba 
(požadavky 306b a 356b v příloze IC).  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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 c ertifikátu 
je specifikována v dodatku 11.
  
2.33 CardSlotNumber  
Kód pro rozlišení mezi dvěma otvory pro kartu v celku ve vozidl e.
 
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 ce lku 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.001 — 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, 3 22 
a 345 přílohy 1C).  
1. generace:
  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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í voz idel 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 struk tuř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.001 — 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 35 2 
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 cel ku 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“: po dpis 
(128 bajtů) || zbytek veřejného klíče (58 bajtů) || odkaz na ce rtifikační 
autoritu (8 bajtů).  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 1 1 
„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 certi fikač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.001 — 142  
2. generace:  
tachographApplicationID  označuje 6 nejvýznamnějších bajtů identifi­
kátoru aplikace (AID) karty tachografu 2. generace. AID pro apl ikaci 
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ě vy stavení 
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.001 — 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 pod niku 
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 n ebo 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.001 — 144  
2.47 CompanyActivityType  
Kód udávající činnost vykonávanou podnikem s použitím jeho kart y 
podniku.
  
2.48 CompanyCardApplicationIdentification  
Informace uložené na kartě podniku týkající se identifikace apl ikace 
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 apl ikace 
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.001 — 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 a plikace 
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 a plikace 
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í činn osti 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.001 — 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 d rž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ý t yp 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.001 — 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.001 — 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 vozi dle. 
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 nasta vuje 
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.001 — 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čitad la 
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.001 — 150  
2.61 DriverCardApplicationIdentification  
Informace uložené na kartě řidiče týkající se identifikace apli kace 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.001 — 151  
2.61a  DriverCardApplicationIdentificationV2  
2. generace, verze 2:  
Informace uložené na kartě řidiče týkající se identifikace apli kace 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ži tele 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.001 — 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 s pecifiko­
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.001 — 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 po dpisu 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.001 — 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 v e 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če m, 
žá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.001 — 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 v e 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če m, 
žá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.001 — 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.001 — 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.001 — 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 i dentifi­
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.001 — 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.001 — 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 j e 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ázna mu 
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 in formace 
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.001 — 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 struk tuř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é posky tují 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 ji né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 odp oví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.001 — 162  
2.79c  GNSSPlaceAuthRecord  
2. generace, verze 2:  
Informace týkající se polohy vozidla dle GNSS (požadavky 108, 1 09, 
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, 1 09, 
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.001 — 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 k líč 
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í cert ifiká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.001 — 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 cert ifikač­
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.001 — 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 tachogra fo­
vých zařízení, když si podají žádost u zkušebny příslušné pro p rovádění 
zkoušek interoperability.  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 166  
2.95 ManufacturerSpecificEventFaultData  
2. generace:  
Kódy chyb specifické pro výrobce zjednodušují analýzu chyb a úd rž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 cer tifi­
kačním úřadem.
  
2.97 MemberStateCertificateRecordArray  
2. generace:  
Certifikát členského státu a metadata použitá v protokolu pro s tahová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.001 — 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čk ami 
používanými na vozidlech v mezinárodním provozu (Vídeňská úmluv a 
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 int erope­
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 ři dič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.001 — 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 p oslední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 pod niku.
  
Přiřazení hodnoty : viz dodatek 2.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 169  
2.108  NoOfControlActivityRecords  
Počet záznamů o kontrolní činnosti, které lze uložit na kontrol ní 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 kar tu 
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.001 — 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 dn e 
(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.001 — 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í kontro ly 
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é rychlos ti, 1 
znamená, že se vyskytla jedna událost překročení povolené rychl osti 
od poslední kontroly překročení povolené rychlosti, … 255 zname ná, 
že se vyskytlo 255 nebo více událostí překročení povolené rychl osti 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í pracov ní 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é posky tují status 
ověření pravosti místa, kde začíná nebo končí denní pracovní do ba 
(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.001 — 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í pracov ní 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.001 — 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 p ož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 Rec or­
dArrays.
  ▼M3
02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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řipoj eny 
k různým částem vozidla, a je určen k uložení na kartě. Tento d atový 
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řipoj eny 
k různým částem vozidla, a je určen k uložení v celku ve vozidl e.
 
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ázn a­
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říloh y 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.001 — 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řípa dný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řípa dný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 v ně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ža davek 98 
přílohy 1C).  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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 mo dulu 
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.001 — 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žadavk y 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.001 — 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 s nímače 
pohybu spárovaného s celkem ve vozidle (požadavek 079 přílohy 1 B).
 
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 celke m ve 
vozidle.  
2.145  SensorPairedRecord  
2. generace:  
Informace uložená v celku ve vozidle týkající se identifikace s ní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.001 — 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říloh y 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íc e 
událostí toho typu.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 3 55 
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 3 56 
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 zv láš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, 212 a 
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.001 — 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í ka rty 
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.001 — 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 ce lek, 
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.001 — 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ěle na 
orgánem registrujícím vozidlo.
  
codePage  určuje znakovou sadu definovanou v kapitole 4.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 s taho­
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 c elku 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.001 — 188  
Informace uložené v celku ve vozidle související se změnami čin nosti 
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 ActivityChange Info 
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 čin nosti 
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 stave m 
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.001 — 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řípa dný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ázn amové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ázn amového 
zařízení (požadavek 098 přílohy 1B a požadavky 119 a 120 příloh y 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.001 — 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.001 — 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 exist uje), 
rcmSerialNumber  je výrobní číslo zařízení pro dálkovou komunikaci 
provázaného s celkem ve vozidle na konci kalibrace (pokud exist uje), 
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.001 — 192  
2.175  VuCalibrationRecordArray  
2. generace:  
Informace uložené v celku ve vozidle týkající kalibrací záznamo vé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.001 — 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.001 — 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ži tý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.001 — 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.001 — 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.001 — 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 proved ený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 prove dené 
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.001 — 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 proved ený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žadave k 
093 přílohy 1B a požadavek 116 přílohy 1C).  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 speedBlockBeg in­
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.001 — 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říloh y 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 celk u 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 celk u 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.001 — 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ža davek 
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.001 — 202  
2.198  VuEventRecord  
Informace uložené v celku ve vozidle týkající se události (poža davek 
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ýjimk ou 
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.001 — 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í gene race.  
cardNumberAndGenCodriverSlotBegin  identifikuje kartu vloženou 
v otvoru pro kartu druhého řidiče na začátku události, včetně j ejí 
generace.  
cardNumberAndGenDriverSlotEnd  identifikuje kartu vloženou 
v otvoru pro kartu řidiče na konci události, včetně její genera ce. 
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 eventBeginTim e 
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ža davek 
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.001 — 204  
2.200  VuFaultData  
1. generace:  
Informace uložené v celku ve vozidle týkající se závad (požadav ek 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žada vek 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.001 — 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í genera ce. 
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žadav ek 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.001 — 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í hra nic 
vozidlem, pokud vozidlo překročilo hranici země (požadavky 133a  
a 133b v příloze IC).  ▼M1
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 cel ek 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í hra nic 
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.001 — 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 ča su 
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 c elku 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.001 — 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.001 — 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 inte li­
gentních dopravních systémů ve spojitosti s tímto vozidlem / ce lkem 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.001 — 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 vozid la 
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.001 — 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řekr očení 
povolené rychlosti od poslední kontroly překročení povolené ryc hlosti 
(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 st aho­
vání.
 ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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řekr oč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řekr očení povo­
lené rychlosti (požadavek 094 přílohy 1B a požadavek 117 příloh y 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.001 — 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řekr očení povo­
lené rychlosti (požadavek 094 přílohy 1B a požadavek 117 příloh y 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í gene race.  
2.216  VuOverSpeedingEventRecordArray  
2. generace:  
Informace uložené v celku ve vozidle týkající se událostí překr oč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.001 — 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ža davky 
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 řid ič začíná 
nebo končí denní pracovní dobu (požadavek 087 přílohy 1B a poža davky 
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 řid ič začíná 
nebo končí denní pracovní dobu (požadavek 087 přílohy 1B a poža davky 
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 řid ič začíná 
nebo končí denní pracovní dobu (požadavek 087 přílohy 1B a poža davky 
108 a 110 v příloze 1C).  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 vo zidle 
na vnějšího zařízení GNSS, viz požadavek GNS_3f dodatku 12.
  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 217  
2.223  VuSerialNumber  
Výrobní číslo celku ve vozidle (požadavek 075 přílohy 1B a poža davek 
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 pod mí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.001 — 218  
2.228  VuSpecificConditionRecordArray  
2. generace:  
Informace uložené v celku ve vozidle týkající se zvláštních pod mí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 p oža­
davky 124 a 125 přílohy 1C).  
1. generace:
  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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. generac e 
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 aplik ace karty 
(požadavky 307 a 330 přílohy 1C).  
1. generace:
  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 aplik ace karty 
(požadavek 330a v příloze IC).  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 356 l 
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ázn amu 
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.001 — 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 pro vedené 
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 st ruktuř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.001 — 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.001 — 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žit ele 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.001 — 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í genera ce. 
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.001 — 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.001 — 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  1 3  
ISO/IEC 8859-15 Latinka 9  1 5  
ISO/IEC 8859-16 Latinka 10 – jazyky jihovýchodní Evropy  1 6  
KOI8-R Latinka / cyrilice  8 0  
KOI8-U Latinka / cyrilice  8 5  
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 zd e ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 229  
6.2 Identifikátory aplikací  
2. generace:  
Identifikátor aplikace (AID) pro vnější zařízení GNSS (2. gener ace) 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. generac e 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 i ntero­
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í. Specifiko vané 
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.001 — 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.001 — 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.001 — 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řík azu 
a odpovědi se posílá jako otevřený text, tj. bez bezpečného pře dá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ě proved en 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 z práv 1. 
generace v režimu pouze s ověřením pravosti (viz dodatek 11 čás t A).  
SM-C-MAC-G1  APDU příkazu se musí použít s bezpečným předáváním zpráv 1. ge nerace 
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. g enerace 
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. ge nerace 
v režimu šifrování a následného ověření pravosti (viz dodatek 1 1 část A).  
SM-MAC-G2  APDU (příkaz a odezva) se musí použít s bezpečným předáváním z práv 2. 
generace v režimu pouze s ověřením pravosti (viz dodatek 11 čás t B).  
SM-C-MAC-G2  APDU příkazu se musí použít s bezpečným předáváním zpráv 2. ge nerace 
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. ge nerace 
v režimu šifrování a následného ověření pravosti (viz dodatek 1 1 čá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.001 — 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.001 — 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.001 — 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ěď. Varian ty 
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.001 — 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 0 0  Normální zpracování  
61 X X  Normální zpracování XX = počet dostupných bajtů odpovědi  
62 8 1  Zpracování s varováním. Část vrácených dat může být poško­
zena.  
63 0 0  Chyba ověření pravosti (varování)  
63 C X  Chybné CHV (kód PIN). „X“ poskytuje stav čítače zbývajících 
pokusů.  
64 0 0  Chyba provádění – stav paměti nezávislé na napájení nezměněn. 
Chyba integrity.  
65 0 0  Chyba provádění – stav paměti nezávislé na napájení změněn.  
65 8 1  Chyba provádění – stav paměti nezávislé na napájení změněn – 
porucha paměti.  
66 8 8  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.001 — 242  
SW1  SW2  Význam  
67 0 0  Chybná délka (chybná hodnota Lc nebo Le)  
68 8 3  Očekáván poslední příkaz řetězce  
69 0 0  Zakázaný příkaz (žádná dostupná odpověď v T=0)  
69 8 2  Bezpečnostní status nesplněn  
69 8 3  Metoda ověření pravosti zablokována  
69 8 5  Podmínky použití nesplněny  
69 8 6  Nedovolený příkaz (žádný aktuální EF)  
69 8 7  Chybí očekávané datové objekty bezpečného předávání zpráv.  
69 8 8  Chybné datové objekty bezpečného předávání zpráv  
6A 8 0  Chybné parametry v datovém poli  
6A 8 2  Soubor nenalezen  
6A 8 6  Chybné parametry P1-P2  
6A 8 8  Odkazovaná data nenalezena  
6B 0 0  Chybné parametry (offset mimo EF)  
6C X X  Chybná délka, SW2 udává přesnou délku. Není vráceno žádné 
datové pole.  
6D 0 0  Kód instrukce není podporován nebo je neplatný.  
6E 0 0  Třída není podporována.  
6F 0 0  - 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 tachogra fu. 
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.001 — 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.001 — 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)  N N  „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.001 — 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 podporov at 
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ě zapou zdř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.001 — 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čnos tní 
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.001 — 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)  N N  „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.001 — 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)  M M  „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.001 — 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 id en­
tifikátoru EF a číst data z tohoto EF.  
TCS_48 Karta tachografu musí podporovat tuto variantu příkazu p ro 
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.001 — 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)  N N  „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.001 — 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.001 — 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)  N N  „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.001 — 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)  N N  „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.001 — 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.001 — 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 id en­
tifikátoru EF a zapsat data z tohoto EF.  
TCS_61 Karta tachografu musí podporovat tuto variantu příkazu p ro 
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)  N N  „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.001 — 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 76 8 
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)  N N  „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.001 — 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.001 — 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ě p ošle 
kryptogram nebo šifrovaná data.  
TCS_69 Kartou vydaná výzva je platná pouze pro následující přík az 
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“  P 1  
P2 1  „00h“  P 2  
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.001 — 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 im ple­
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 ten to 
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 r efe­
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“  P 1  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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 tachograf u 
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“  P 1  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 c erti­
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.001 — 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.001 — 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“  P 1  
P2 1  „00h“  P 2  
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.001 — 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.001 — 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. g ene­
race stanovený v dodatku 11 části B a je v souladu s ISO/IEC 78 16-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.001 — 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ěře ní 
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 ka rtě 
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.001 — 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ás ledu­
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í pravo sti 
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.001 — 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 P SO: 
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.001 — 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 st avová 
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ěj a­
kých dat na kartu. Tento příkaz se používá k ověření digitálníc h 
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.001 — 271  
Tento příkaz musí podporovat pouze kontrolní karta v DF Tachogr aph 
a DF Tachograph_G2.  
Ostatní typy karet tachografu mohou, ale nemusí tento příkaz im ple­
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 PERFOR M 
SECURITY OPERATION / HASH.  
Tento příkaz musí podporovat jen karta řidiče a karta dílny v D F 
Tachograph a DF Tachograph_G2.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 272  
Ostatní typy karet tachografu mohou, ale nemusí tento příkaz im ple­
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ě. Po té 
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.001 — 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 v ypoč­
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 D F 
Tachograph a DF Tachograph_G2.  
Ostatní typy karet tachografu mohou, ale nemusí tento příkaz im ple­
mentovat. Pokud jde o aplikaci tachografu 2. generace, mají pod pi­
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í podpi s 
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í podp is 
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.001 — 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 podpi su 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 Tachogr aph 
a DF Tachograph_G2.  
Ostatní typy karet tachografu mohou, ale nemusí tento příkaz im ple­
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.001 — 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 D SRC 
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íln y 
v DF Tachograph_G2.  
Ostatní typy karet tachografu mohou, ale nemusí tento příkaz im ple­
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.001 — 276  
TCS_136 Příkaz pouze dešifruje data DSRC a ověřuje kryptografic ký 
kontrolní součet, ale neinterpretuje vstupní data.  
TCS_137 Pořadí datových objektů v datovém poli příkazu je určen o 
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.001 — 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é sl ouží 
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če t 
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.001 — 278  
4.1 Hlavní soubor MF  
TCS_142 Po personalizaci má hlavní soubor MF následující trvalo u 
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.001 — 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 struktu ru 
dat: ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 280
  
► (1) (2) M3 ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 281
  
▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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 struktu ru 
dat:
 ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 284
  
▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 285
  
▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  1 2  1 2  
n 2 NoOfFaultsPerType  2 4  2 4  
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. gener ace 
následující trvalou strukturu souborů a pravidla přístupu 
k souborům:
  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 struktur u 
dat: ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 288
  
▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 289
  
▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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. gener ace 
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.001 — 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 struktur u 
dat: ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 292
  
▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 293
  
▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 294
  
▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 295
  
▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  2 4  2 4  
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. g ene­
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 stru k­
turu dat:  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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. g ene­
race následující trvalou strukturu souborů a pravidla 
přístupu k souborům:  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 stru k­
turu dat:  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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. gen e­
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.001 — 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. gen e­
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 strukt uru 
dat: ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 303  
Dodatek 3  
PIKTOGRAMY  
PIC_001 Tachograf může volitelně používat tyto piktogramy a jej ich kombi­
nace (nebo piktogramy a jejich kombinace dostatečně podobné, ab y 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.001 — 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.001 — 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.001 — 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.001 — 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 i den­
tifikovány identifikátorem záznamu.  
PRT_001 Pokud identifikátor bloku bezprostředně předchází ident ifiká­
toru záznamu, identifikátor záznamu se netiskne.  
PRT_002 Není-li některá datová položka známa nebo nesmí být vyt iš­
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 tiskn out, 
vynechá se celá řádka.  
PRT_004 Číselná datová pole se tisknou zarovnaná doprava, s mez erou 
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 jak o 
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 fo rmá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.001 — 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í s e 
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
 Kombinace 
piktogramů 
karty  
Kód vydávajícího 
členského státu Prvních 14 znaků čísla karty 
(případně s pořadovým indexem)
 
Index náhrady  
Index obnovy 
▼M3 
— v datovém bloku se text za „pi =“ vztahuje k odpovídajícímu p ikto­
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.001 — 309  
PRT_007 Ve výtiscích se používají následující datové bloky a/ne bo 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.001 — 310
  
► (1) (2) (3)  M3 ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 311
  
► (1) (2) M3 ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 312
  
▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 313
  
► (1) (2) (3) (4)  M3 ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 314
  
▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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, koli krát 
je třeba  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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í fo rmá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.001 — 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.001 — 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 3 65 
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.001 — 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), kte ré 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 fo rmá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.001 — 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.001 — 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.001 — 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.001 — 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  m A  
U high (out)  4  V  I  =  1  m A  
INT_009 Vstupní/výstupní signál musí splňovat tyto časové diagr amy:
 ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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 Vers ion 
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 implementov at 
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 jej ich 
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.001 — 328  
— z karty tachografu prostřednictvím celku ve vozidle pomocí ID E 
připojeného k celku ve vozidle.  
Aby bylo možné zkontrolovat pravost a integritu stažených dat u lož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říz ení). 
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í kontro lní 
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 v ozidle:  
— 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é ge nerace 
vložených do celku ve vozidle, jak je uvedeno v bodech 3 a 4 to hoto 
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.001 — 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žadave k 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 1 4229- 
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  …  …  …  C S  
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 jedno ho z otvorů pro kartu 
ve VU, i když v druhém otvoru pro kartu není vložena žádná kart a.
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  C S  
4 bajty  Delší než 255 bajtů  
Přenese se jako:  
Hlavička  SID  TREP  0 0  0 1  Dílčí zpráva 1  C S  
4 bajty  255 bajtů  
Hlavička  SID  TREP  0 0  0 2  Dílčí zpráva 2  C S  
4 bajty  255 bajtů  
… 
Hlavička  SID  TREP  x x  y y  Dílčí zpráva n  C S  
4 bajty  Méně než 255 bajtů  
nebo jako:  
Hlavička  SID  TREP  0 0  0 1  Dílčí zpráva 1  C S  
4 bajty  255 bajtů  
Hlavička  SID  TREP  0 0  0 2  Dílčí zpráva 2  C S  
4 bajty  255 bajtů  
… 
Hlavička  SID  TREP  x x  y y  Dílčí zpráva n  C S  
4 bajty  255 bajtů  
Hlavička  SID  TREP  x x  yy + 1  C S  
4 bajty  4 bajty  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  C S  
Start Communication Request  8 1  E E  F 0  8 1  E 0  
Positive Response Start Communica­
tion 80 F 0  E E  0 3  C 1  EA, 8F  9 B  
Start Diagnostic Session Request  8 0  E E  F 0  0 2  1 0  8 1  F 1  
Positive Response Start Diagnostic  8 0  F 0  E E  0 2  5 0  8 1  3 1  
Link Control Service  
Verify Baud Rate (stage 1)  
9 600 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,01  E C  
19 200 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,02  E D  
38 400 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,03  E E  
57 600 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,04  E F  
115 200 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,05  F 0  
Positive Response Verify Baud Rate  8 0  F 0  E E  0 2  C 7  0 1  2 8  
Transition Baud Rate (stage 2)  8 0  E E  F 0  0 3  8 7  0 2  0 3  E D  
Request Upload  8 0  E E  F 0  0 A  3 5  00,00,00,00, 
00,FF,FF, 
FF,FF  99 
Positive Response Request Upload  8 0  F 0  E E  0 3  7 5  00,FF  D 5  
Transfer Data Request  
Download interface version  8 0  E E  F 0  0 2  3 6  0 0  9 6  
Overview  80 E E  F 0  0 2  3 6  01, 21 nebo 
31 CS 
Activities  80 E E  F 0  0 6  3 6  02, 22 nebo 
32 Date  C S  
Events & Faults  80 E E  F 0  0 2  3 6  03, 23 nebo 
33 Date  C S  
Detailed Speed  80 E E  F 0  0 2  3 6  04 nebo 24  Datum  C S  
Technical Data  80 E E  F 0  0 2  3 6  05, 25 nebo 
35 Date  C S  
Card download  80 E E  F 0  02 nebo 03  3 6  0 6  Slot  C S  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 332  
Struktura zprávy  Max. 4 bajty  Max. 255 bajtů  1 bajt  
Záhlaví  Data  Kontrolní 
součet  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  C S  
Positive Response Transfer Data  8 0  F 0  E E  Len  7 6  TREP  Data  C S  
Request Transfer Exit  8 0  E E  F 0  0 1  3 7  9 6  
Positive Response Request Transfer 
Exit 80 F 0  E E  0 1  7 7  D 6  
Stop Communication Request  8 0  E E  F 0  0 1  8 2  E 1  
Positive Response Stop Communica­
tion 80 F 0  E E  0 1  C 2  2 1  
Acknowledge sub message  8 0  E E  F 0  Len  8 3  Data  C S  
Negative responses  
General reject  8 0  F 0  E E  0 3  7 F  Sid Req  1 0  C S  
Service not supported  8 0  F 0  E E  0 3  7 F  Sid Req  1 1  C S  
Sub function not supported  8 0  F 0  E E  0 3  7 F  Sid Req  1 2  C S  
Incorrect Message Length  8 0  F 0  E E  0 3  7 F  Sid Req  1 3  C S  
Conditions not correct or Request 
sequence error  80 F 0  E E  0 3  7 F  Sid Req  2 2  C S  
Request out of range  8 0  F 0  E E  0 3  7 F  Sid Req  3 1  C S  
Upload not accepted  8 0  F 0  E E  0 3  7 F  Sid Req  5 0  C S  
Response pending  8 0  F 0  E E  0 3  7 F  Sid Req  7 8  C S  
Data not available  8 0  F 0  E E  0 3  7 F  Sid Req  F A  C S  
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 uvede ny. 
— Slot je číslo otvoru pro kartu, buď „1“ (karta v otvoru pro k artu 
ř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 explic itně 
vybere uživatel.  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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í da t 
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. genera ci 
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 n a 
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.001 — 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 informoval o 
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  0 0  
Přehled (Overview)  0 1  2 1  3 1  
Činnosti v daný den (Activi­
ties of a specified date)  02 2 2  3 2  
Události a závady (Events 
and faults)  03 2 3  3 3  
Podrobnosti o rychlosti 
(Detailed speed)  04 2 4  2 4  
Technická data (Technical 
data)  05 2 5  3 5  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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 < 255) 
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.001 — 337  
— 11  Service not supported  (služba nepodporována)  
SID požadavku není srozumitelný.  
— 1 2 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ás le­
dující:  
IDE V U  
Start Communication Request  ⇨ 
⇦  Positive Response  
Start Diagnostic Service Request  ⇨ 
⇦  Positive Response  
Request Upload  ⇨ 
⇦  Positive Response  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 338  
IDE V U  
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 < 255 bajtů)  
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.001 — 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  2 0  
P2 2 0  1 000 (*)  
P3 1 0  5 000  
P4 5  2 0  
P5 1 0  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í mez ní 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.001 — 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.001 — 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čk a 
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.001 — 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.001 — 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 Act i­
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 Tec h­
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.001 — 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, ID E 
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á prot o 
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.001 — 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.001 — 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  S m ě 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.001 — 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  S m ě 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áhn out 
s podpisem, se použije tato sekvence:  
▼M1 
Karta  S m ě 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.001 — 353  
Karta  S m ě 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  S m ě 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.001 — 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, c o 
s tímto souborem souvisí (žádný tag ani nulová délka).  
▼M1 
DDP_046 Podpis se uloží jako následující objekt TLV bezprostřed ně 
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.001 — 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  D F
  
Podpis EF
  v  D F
  
▼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í pro to­
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.001 — 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.001 — 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ří čás t 
kalibračního rozhraní popsaného v dodatku 6. Popisuje také říze ní 
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í r elací 
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 interoperabili tu 
stanovenými v tomto nařízení, považovat za relevantní pro obě g ene­
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.001 — 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í hodn oty. 
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í: 199 9). 
▼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.001 — 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  8 1  ■  ■  ■  
StopCommunication  4.2  8 2  ■  
TesterPresent  4.3  3 E  ■  ■  ■  
StartDiagnosticSession  5.1  1 0  ■  ■  ■  
SecurityAccess  5.2  2 7  ■  ■  ■  
ReadDataByIdentifier  6.1  2 2  ■  ■  ■  
WriteDataByIdentifier  6.2  2 E  ■  
InputOutputControlByIdentifier  7.1  2 F  ■  
▼M3 
RoutineControl  8  3 1
  
▼B 
■ Tento symbol značí, že služba je v této diagnostické relaci po vinná. 
Pokud není symbol uveden, znamená to, že tato služba není v tét o 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 ro zepsá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.001 — 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, kt eré 
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.001 — 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 2 0  
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 2 0  
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  E E  TGT  
#3 Bajt adresy zdroje  t t  SRC  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  C S  
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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Dodatečný bajt délky  0 3  LEN  
#5 Id služby kladné odpov ědi na 
StartCommunication  C1 SCRPR  
#6 Klíčový bajt 1  E A  KB1  
#7 Klíčový bajt 2  8 F  KB2  
#8 Kontrolní součet  00-FF  C S  
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í re lace. 
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 vozidl e, 
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, ko mu­
nikace se ukončí bez vydání prvku odpovědi.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  E E  TGT  
#3 Bajt adresy zdroje  t t  SRC  
#4 Bajt dodatečné délky  0 1  LEN  
#5 Id služby požadavku Stop ­
Communication  82 SPR  
#6 Kontrolní součet  00-FF  C S  
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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 1  LEN  
#5 Id služby kladné odpov ědi na 
StopCommunication  C2 SPRPR  
#6 Kontrolní součet  00-FF  C S  
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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 3  LEN  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  1 0  RC_GR  
#8 Kontrolní součet  00-FF  C S  
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 s luž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  E E  TGT  
#3 Bajt adresy zdroje  t t  SRC  
#4 Bajt dodatečné délky  0 2  LEN  
#5 Id služby požadavku Tester ­
Present  3E TP  
#6 Podfunkce = respon­
seRequired =  [ano 0 1  RESPREQ_Y  
ne] 0 2  RESPREQ_NO  
#7 Kontrolní součet  00-FF  C S  
CPR_080 Je-li parametr responseRequired nastaven na „ano“, odpo ví 
server následující kladnou zprávou. Je-li nastaven na „ne“, 
neodešle server žádnou odpověď.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 1  LEN  
#5 Id služby kladné odpov ědi na 
TesterPresent  7E TPPR  
#6 Kontrolní součet  00-FF  C S  
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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 3  LEN  
#5 Id služby záporné odpov ědi 7F  NR  
#6 Identifikace služby požadavku 
TesterPresent  3E T P  
#7 response­
Code =  [SubFunctionNotSup­
ported-InvalidFormat  12 RC_SFNS_IF  
incorrectMessage­
Length ]  13 RC_IML  
#8 Kontrolní součet  00-FF  C S  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 m ezi 
klientem a celkem ve vozidle zahájena komunikace.  
CPR_027 Pokud byla dříve aktivní jiná diagnostická relace, stan ou 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 roz e­
psány v níže uvedených tabulkách.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  E E  TGT  
#3 Bajt adresy zdroje  t t  SRC  
#4 Bajt dodatečné délky  0 2  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  C S  
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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 2  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  C S  
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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 368  
Bajt č.  Název parametru  Hexade­
cimální 
hodnota  Symbol  
#4 Bajt dodatečné délky  0 3  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  C S  
( α ) – hodnota vložená do bajtu # 6 zprávy o požadavku není podpor ována, tj. není 
v tabulce 17, 
( β ) – délka obdržené zprávy je chybná, 
( γ ) – kritéria pro požadavek StartDiagnosticSession nejsou splněn a. 
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.001 — 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 v e 
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 cele k ve 
vozidle v režimu KALIBRACE nebo KONTROLA (CONTROL).  
Služba SecurityAccess poskytuje prostředky pro vložení PIN a in dikuje 
zkušebnímu zařízení, zda celek ve vozidle je, nebo není v režim u 
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„request Seed“ 
následovanou zprávou SecurityAccess „sendKey“. Služba SecurityA c­
cess musí být provedena po službě StartDiagnosticSession.  
CPR_033 Zkušební zařízení využívá zprávu SecurityAccess „reques t­
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.001 — 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“ js ou 
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  E E  TGT  
#3 Bajt adresy zdroje  t t  SRC  
#4 Bajt dodatečné délky  0 2  LEN  
#5 Id služby požadavku Securi ­
tyAccess  27 SA  
#6 accessType – requestSeed  7 D  AT_RSD  
#7 Kontrolní součet  00-FF  C S  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 4  LEN  
#5 Id služby kladné odpov ědi na 
SecurityAccess  67 SAPR  
#6 accessType – requestSeed  7 D  AT_RSD  
#7 Seed High  00-FF  SEEDH  
#8 Seed Low  00-FF  SEEDL  
#9 Kontrolní součet  00-FF  C S  
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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 3  LEN  
#5 Id služby záporné odpov ědi 7F  NR  
#6 Id služby požadavku SecurityAccess  2 7  S A  
#7 response­
Code =  [conditionsNotCorrec­
tOrRequestSequence­
Error  22 RC_CNC  
incorrectMessage­
Length]  13 RC_IML  
#8 Kontrolní součet  00-FF  C S  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  E E  TGT  
#3 Bajt adresy zdroje  t t  SRC  
#4 Bajt dodatečné délky  m+2  LEN  
#5 Id služby požadavku Securi ­
tyAccess  27 SA  
#6 accessType – sendKey  7 E  AT_SK  
#7 až #m+6  Klíč #1 (nejvýznamnější)  x x  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  C S  
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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 2  LEN  
#5 Id služby kladné odpov ědi na 
SecurityAccess  67 SAPR  
#6 accessType – sendKey  7 E  AT_SK  
#7 Kontrolní součet  00-FF  C S  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 3  LEN  
#5 Id služby záporné odpov ědi 7F  NR  
#6 Id služby požadavku SecurityAccess  2 7  S A  
#7 Response­
Code =  [generalReject  1 0  RC_GR  
subFunctionNotSup­
ported  12 RC_SFNS  
incorrectMessage­
Length  13 RC_IML  
conditionsNotCorrec­
tOrRequestSequence­
Error  22 RC_CNC  
invalidKey  3 5  RC_IK  
exceededNumberO­
fAttempts  36 RC_ENA  
requestCorrectlyRe­
ceived-ResponsePen­
ding]  78 RC_RCR_RP  
#8 Kontrolní součet  00-FF  C S  
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.001 — 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  E E  TGT  
#3 Bajt adresy zdroje  t t  SRC  
#4 Bajt dodatečné délky  0 3  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  C S  
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  t t  TGT  
#3 Bajt adresy zdroje  E E  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.001 — 375  
Bajt č.  Název parametru  Hexade­
cimální 
hodnota  Symbol  
#8 až #m 
+7 dataRecord[] =  [data#1  x x  DREC_DAT­
A1 
: :  :  
data#m]  x x  DREC_DAT­
Am 
#m+8  Kontrolní součet  00-FF  C S  
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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 3  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  C S  
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.001 — 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.001 — 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  E E  TGT  
#3 Bajt adresy zdroje  t t  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  x x  DREC_DAT­
A1 
: :  :  
data#m]  x x  DREC_DAT­
Am 
#m+8  Kontrolní součet  00-FF  C S  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 3  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  C S  
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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 3  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  C S  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 zk ušební 
impulsy byly řízeny nebo monitorovány pomocí vhodného zkušebníh o 
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.001 — 380  
CPR_060 Pokud jsou na signálovém vodiči rychlosti v reálném čas e 
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  E E  TGT  
#3 Bajt adresy zdroje  t t  SRC  
#4 Bajt dodatečné délky  x x  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  C S  
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.001 — 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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  x x  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  C S  
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  t t  TGT  
#3 Bajt adresy zdroje  E E  SRC  
#4 Bajt dodatečné délky  0 3  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.001 — 382  
Bajt č.  Název parametru  Hexadecimální 
hodnota  Symbol  
#7 responseCode=[  
incorrectMessageLength  1 3  RC_IML  
conditionsNotCorrect  2 2  RC_CNC  
requestOutOfRange  3 1  RC_ROOR  
deviceControlLimitsExceeded]  7 A  RC_DCLE  
#8 Kontrolní součet  00-FF  C S  
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í  0 0  I/O vodič je neaktivní (výchozí stav)  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 383  
Režim  Hexadecimální 
hodnota  Popis  
Aktivní  0 1  Aktivuje kalibrační spojení I/O jako speed­
SignalInput  
Aktivní  0 2  Aktivuje kalibrační spojení I/O jako realTi­
meSpeedSignalOutputSensor  
Aktivní  0 3  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 spusti t 
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í  8 0  FMT  
#2 Bajt cílové adresy  E E  TGT  
#3 Bajt zdrojové adresy  t t  SRC  
#4 Bajt dodatečné délky  x x  LEN  
#5 RoutineControl Request Sid (SID požadavku RoutineControl)  31  RC  
#6 routineControlType = [startRoutine]  0 1  RCTP_STR  
#7 a #8  routineIdentifier = [TimeAdjustment]  0100  RI_TA  
#9 Kontrolní součet  00-FF  C S  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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í  8 0  FMT  
#2 Bajt cílové adresy  t t  TGT  
#3 Bajt zdrojové adresy  E E  SRC  
#4 Bajt dodatečné délky  x x  LEN  
#5 RoutineControl Positive Response Sid (SID kladné odpov ědi na 
požadavek RoutineControl)  71 RCPR  
#6 routineControlType = [startRoutine]  0 1  RCTP_STR  
#7 a #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 Kontrolní součet  00-FF  C S  
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í  8 0  FMT  
#2 Bajt cílové adresy  E E  TGT  
#3 Bajt zdrojové adresy  t t  SRC  
#4 Bajt dodatečné délky  x x  LEN  
#5 RoutineControl Request Sid (SID požadavku RoutineControl)  31  RC  
#6 routineControlType = [requestRoutineResults]  0 3  RCTP_RRR  
#7 a #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 Kontrolní součet  00-FF  C S  
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í  8 0  FMT  
#2 Bajt cílové adresy  t t  TGT  
#3 Bajt zdrojové adresy  E E  SRC  
#4 Bajt dodatečné délky  x x  LEN  
#5 RoutineControl Positive Response Sid (SID kladné odpov ědi na 
požadavek RoutineControl)  71 RCPR  
#6 routineControlType = [requestRoutineResults]  0 3  RCTP_RRR  
#7 a #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 routineInfo (viz tabulka 37f)  X X  RINF_TA  
#10 routineStatusRecord[] = routineStatus#1 (viz tabulka 37g)  X X  RS_TA  
#11 Kontrolní součet  00-FF  C S  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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í  8 0  FMT  
#2 Bajt cílové adresy  t t  TGT  
#3 Bajt zdrojové adresy  E E  SRC  
#4 Bajt dodatečné délky  0 3  LEN  
#5 negativeResponse Service Id (Identifikátor služby negativeRe ­
sponse)  7F NR  
#6 inputOutputControlByIdentifier Request SId  3 1  RC  
#7 responseCode=[ 
sub-functionNotSupported 
incorrectMessageLengthOrInvalidFormat 
conditionsNotCorrect 
requestOutOfRange 
] 12 
13 
22 
31 SFNS 
IMLOIF 
CNC 
ROOR  
#8 Kontrolní součet  00-FF  C S  
Tabulka 37f  
RoutineControl, rutina (TimeAdjustment), routineInfo  
routineInfo  Hexadecimální 
hodnota  Popis  
NormalExitWithResultAvailable  6 1  Rutina byla plně provedena; k dispozici jsou další 
výsledky rutiny.  
RoutineExecutionOngoing  7 8  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.001 — 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í platno sti 
přenášených parametrů.  
CPR_070 Hodnoty v rozsahu „error indicator“ (indikátor chyby) j sou 
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 da t 
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  F B  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  F E  FE00 až FEFF  FE000000 až FEFFFFFF  0  
Nedostupné nebo nevyžádané  F F  FF00 až FFFF  FF000000 až FFFFFFFF  F F  
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 ReadDataByIdentif ier 
a WriteDataByIdentifier.  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 387  
CPR_074 V tabulce 39 je uvedena délka, rozlišení a pracovní roz sah 
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  1 5  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  1 4  Podrobnosti viz tabulka 42  
VIN 1 7  ASCII  ASCII  
SealDataVu  5 5  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  1 4  Podrobnosti viz tabulka 47  
CalibrationCountry  3  ASCII  NationAlpha podle definice 
v dodatku 1  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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.001 — 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) ne bo 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řílo hy 
z hlediska prováděných funkcí, přesnosti měření a environmentál ní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šk y musí 
provést orgán členského státu při funkčních zkouškách a jaké zk ouš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. Poku d se 
některé ze zkoušek vyžadovaných pro schválení typu provedou v p rů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ž prov edení 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žadave k 
PIC_001 v dodatku 3 Piktogramy).  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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ál ení 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 (r esp. 
vnějších zařízení GNSS) a všech modelů celků ve vozidle. V tako vém 
případě se schválení typu snímače pohybu (resp. vnějšího zaříze ní 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 voz idle 
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.001 — 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.001 — 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íln y 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.001 — 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č poh ybu 
reaguje na magnetická pole, která narušují detekci pohybu vozid la. 217 
3.47 Sada šifer a standardizované parametry domény  CSM_48, CSM_50  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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.001 — 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  0 2  
3.5 Ověřit, zda je snímač pohybu imunní vůči konstantnímu magnetic kému poli. 
Alternativně ověřit, že snímač pohybu reaguje na konstantní mag netická 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.001 — 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 , <= 0,5 oktávy/min; 
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 < 1 ms, počet rázů: dohodne se 
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.001 — 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í pro vá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 komb inace 
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 Č i p  
[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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 vo zidle  0 3  
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.001 — 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.001 — 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  9 1  
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.001 — 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.001 — 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.001 — 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.001 — 418  
Optické hustoty výsledných výtisků se měří podle normy DIN EN I SO 
534. 
Výtisky nevykazují žádné rozměrové změny a zůstávají jasně čite lné. 
8. ZKOUŠKY INTEROPERABILITY  
▼M1 
Č. Zkouška  Popis  
8.1 Zkoušky interoperability celků ve vozidle a karet tachograf u 
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áznam y 
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álo stí 
nebo závad. 
Ověřit stažením z celku ve vozidle, že všechny příslušné záznam y 
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říze ní 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álo stí 
nebo závad. 
Ověřit stažením z celku ve vozidle, že všechny příslušné záznam y 
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.001 — 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 ji né 
součásti tachografu, mohou být zkoušky stanovené v této kapitol e 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 n a 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 Gali leo 
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.001 — 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ě lz e 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 nast avení 
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 dispo zici 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 vlastnos ti: 
— 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.001 — 421  
S výjimkou případů, kdy je to uvedeno, musí být určení interníh o času 
přijímače známé s dostatečnou přesností a musí být náležitě syn chronizo­
váno se simulovaným časem. To zaručuje, že je pro každou zkušeb ní 
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ím ačů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.001 — 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.001 — 423  
Dodatek 10  
BEZPEČNOSTNÍ POŽADAVKY  
Tento dodatek specifikuje bezpečnostní požadavky v oblasti info rmačních tech­
nologií na součásti systémů inteligentních tachografů (tachogra fů 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 bezp eč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í skupi ny, 
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 inf or­
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 uve deny v samo­
statném profilu ochrany.  
SEC_004 Výrobci součástí musí dle potřeby upřesnit a doplnit pr ofil 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 be zpeč­
nostní certifikaci součásti.  
SEC_005 V průběhu hodnocení musí být konstatováno přísné dodrže ní 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 ro zšířený 
o složky záruky ATE_DPT.2 a AVA_VAN.5.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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 odsouhla sení 
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.001 — 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 ta chografu,  
— důvěrnost, integritu, ověřování pravosti a/nebo nepopiratelno st 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). Čás t 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 ales poň jedna 
součást systému tachografu pro proces vzájemného ověřování prav osti 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/n ebo 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.001 — 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í vozidl a 
– 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.001 — 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ý kryptograf ický 
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.001 — 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í al go­
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 s kla­
dování musí být zachována důvěrnost soukromých klíčů.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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ě zacho vána 
v průběhu generování, dopravy (v příslušných případech) a sklad ová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.001 — 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 krypto gra­
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 dat y 
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.001 — 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í identi fiká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“
 Tag rozšířeného návěští  
Délka návěští  
Tag CPI  
Délka CPI  
Tag CAR  
Délka CAR  
Tag CHA  
Délka CHA  
Tag EOV  
Délka EOV  
Tag CHR  
Délka CHR  
Tag veřejného klíče (sestaveného)  
Délka následujících DO  
Tag modulu  
Délka modulu  
Tag veřejného exponentu  
Délka veřejného exponentu 
2. „Odkaz na certifikační autoritu“ (CAR) má za účel identifiko vat 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 identif ikaci práv 
držitele certifikátu. Je tvořena identifikací (ID) použití tach ografu 
a typem zařízení, ke kterému je certifikát určen (podle prvku d at
 
, „00“ pro členský stát).  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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íč d ržitele 
certifikátu.  
5. Identifikátory klíčů jednoznačně identifikují držitele certi fiká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 z aří­
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ře jný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, identifik aci 
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.001 — 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 certif ikač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“
 Tag certifikátu CV 
(sestaveného)  
Délka následujících DO  
Tag podpisu  
Délka podpisu  
Tag zbytku  
Délka zbytku  
Tag CAR  
Délka CAR ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 čl enské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 o věř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čí nastav ením 
klíče relace.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 438
  
▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 b ajty. 
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.001 — 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  P 1  P 2  [ 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  P 1  P 2  [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“  C C  
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“  C C  
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.001 — 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“  C C  
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“  C C  
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í c hybu 
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 ne bo 
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 obv y­
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.001 — 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.001 — 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 digi tá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“||„0 5“||„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émat u 
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.001 — 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 ci rcuit 
cards – Part 4: Organization, security and commands for 
interchange. Third edition 2013-04-15  
ISO 7816-8 ISO/IEC 7816-8, Identification cards – Integrated ci rcuit 
cards – Part 8: Commands for security operations. Second 
edition 2004-06-01  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 te ch­
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.001 — 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živate le 
X 
X.CHR odkaz na držitele certifikátu uvedený v certifikátu uživa tele 
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 čás ti 
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.001 — 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.001 — 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.001 — 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í GNS S 
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  1 2  
CS#3  512/521  256  SHA-512  1 6  
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áj emné 
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.001 — 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.001 — 451  
CSM_60 ERCA kdykoli zlikviduje tyto kryptografické klíče a cert i­
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šťov at 
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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, p rvní 
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 cer ti­
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-las t) 
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 certifi káty 
MSCA mají proto téměř stejnou dobu platnosti, ačkoli jsou zástu pci 
různých generací.  
5. Doba platnosti uvedená pro karty je stejná jako pro karty ři dič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 [I SO 
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.001 — 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 b yl 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.001 — 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.001 — 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.001 — 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.001 — 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 vozid le 
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.001 — 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.001 — 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ře no­
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.001 — 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.001 — 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 vozid le 
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 profi lu 
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.001 — 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íč  P K  „7F 49“  var  
Parametry domény  D P  „06“  var
  
Veřejný bod  P P  „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 certifi ká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 v eř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.001 — 469  
CSM_140 Pro spojovací certifikát ERCA musí být odkaz na držitel e 
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 identifika ci 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 do mény 
užívané s veřejným klíčem v certifikátu a hodnotu veřejného bod u. 
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ře jný 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í G NSS 
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 certi fiká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.001 — 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í da tum 
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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í c erti­
fikát VU. Jak je uvedeno v části 9.1.2, jedná se o spojovací ce rtifiká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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 483  
10.5.2  Struktura bezpe čné zprávy  
CSM_188 Bezpečné předávání zpráv musí užívat pouze datové objek ty 
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.001 — 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 podl e 
[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ávislos ti 
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“ || D O„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“ || D O„97“ 
|| DO„8E“ || Le  
kde Le = ‘00’ nebo ‘00 00’ v závislosti na tom, zda jsou použit a 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í struktur u: 
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.001 — 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ěřeno u 
pravostí, obrázek 9 znázorňuje případ 1 / případ 3 odpovědi APD U 
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.001 — 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ře dá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.001 — 487  
CSM_193 Karta tachografu přeruší aktuální relaci bezpečného pře dá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 ka rtou 
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.001 — 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 ji ný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.001 — 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 proto kol 
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.001 — 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, mu sí 
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.001 — 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 odsouh la­
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.001 — 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šec hny 
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.001 — 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 uv edeno v CSM_117.
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  1 6  1 6  1 6  
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  1 6  1 6  1 6  
41 odpověď  Párovací klíč  1 6  16 / 24 / 32  1 6  3 2  3 2  
42 požadavek  Klíč relace  1 6  16 / 24 / 32  1 6  3 2  3 2  
43 požadavek  Párovací informace  2 4  2 4  3 2  3 2  3 2  
50 odpověď  Párovací informace  2 4  2 4  3 2  3 2  3 2  
70 požadavek  Data ověření pravosti  8  8  1 6  1 6  1 6  
80 odpověď  Hodnota čítače MoS 
+ data ověření 
pravosti  8 8  1 6  1 6  1 6  
▼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.001 — 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  n e ž  
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é gener ace 
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.001 — 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ále né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é kom uni­
kace je odpovědné za odesílání těchto dat přes rozhraní DSRC po dle 
dodatku 14 do vzdáleného dotazovacího zařízení. Dodatek 1 stano ví, 
ž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 dod atku 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 (dato vý 
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 v e 
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.001 — 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.001 — 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.001 — 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 cert i­
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.001 — 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.001 — 501  
Obrázek 13  
Protokol pro ov ěření podpisu staženého datového souboru
  ▼M1
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 m ezi 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.001 — 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 da ta 
GNSS používaná celkem ve vozidle, včetně protokolů, které je nu tné 
zavést k zajištění zabezpečeného a správného přenosu dat s info rmacemi 
o poloze.  
1.1. Oblast p ůsobnosti  
GNS_1 Celek ve vozidle shromažďuje údaje o poloze nejméně z jed né 
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.001 — 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 z ařízením 
GNSS nebo bez něj je poskytování přesných a spolehlivých inform ací 
o poloze základním prvkem účinného fungování inteligentního tac ho­
grafu. Proto je přiměřené požadovat jeho slučitelnost se služba mi 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 nav i­
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 tach ogra­
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 dn e 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.001 — 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ét o 
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.001 — 506  
GNS_3e Přijímač GNSS musí používat hodiny reálného času celku v e 
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řílo hy 
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 ta chografu 
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 G NSS 
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.001 — 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*h h 
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í neb o O = jiný 
útok na GNSS v případě nepřítomnosti selhání ověření pravosti n avigač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 dokum entech 
uvedených v GNS_3b), V = neplatné (ověřená poloha není k dispoz ici 
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.001 — 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.001 — 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.001 — 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é komunikac e 
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.001 — 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.001 — 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áz e­
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.001 — 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'  8 5  8 5  
1. věta GSA NMEA  '02'  8 5  8 5  
2. věta GSA NMEA  '03'  8 5  8 5  
3. věta GSA NMEA  '04'  8 5  8 5  
4. věta GSA NMEA  '05'  8 5  8 5  
5. věta GSA NMEA  '06'  8 5  8 5  
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.001 — 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' 1 6  1 6  
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'  8 5  8 5  
1. věta ASA  '12'  8 5  8 5  
2. věta ASA  '13'  8 5  8 5  
3. věta ASA  '14'  8 5  8 5  
4. věta ASA  '15'  8 5  8 5  
5. věta ASA  '16'  8 5  8 5  
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.001 — 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.001 — 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 pravo sti) 
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.001 — 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 pravo sti) 
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.001 — 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 dodat ku 
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.001 — 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, ja k 
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 inst a­
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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řed nictví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 (na př. 
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.001 — 525  
1.2. Zkratky a definice  
Používají se tyto zkratky a definice specifické pro tento dodat ek: 
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 tachogra fu 
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če ní 
procesu párování Bluetooth®.  
ITS_07 Musí být zavedena zabezpečená a zakódovaná komunikace me zi 
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 mu sí 
být klientem.  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 soul adu 
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í konekto r, 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 k ombinací 
platných karet tachografu vložených do celku ve vozidle, jak je  
uvedeno v tabulce 1.  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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
 otvor pro kartu druhého řidiče žádná karta  není k dispozici  k dispozici  k dispozici  k dispozici  k dispozici  
karta řidiče  k dispozici  k dispozici  k dispozici  k dispozici  k dispozici  
kontrolní karta  k dispozici  k dispozici  k dispozici  není k dispozici  není k dispozici  
karta dílny  k dispozici  k dispozici  není k dispozici  k dispozici  není k dispozici  
karta podniku  k dispozici  k dispozici  není k dispozici  není k dispozici  k dispozici  
ITS_14 Po úspěšném spárování ITS Bluetooth® musí VU přidělit př ipojení 
ITS Bluetooth® konkrétní vložené kartě tachografu podle 
tabulky 2:  
Tabulka 2  
Přidělení připojení ITS v závislosti na typu karty vložené do tachografu  
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
 otvor pro kartu druhého řidič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é jednotc e 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řednic tví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.001 — 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 klasifik ují 
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 kal ibrač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  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
CalibrationDate  ISO 16844-7  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
TachographVehicle­
Speed  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  povinné  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 529  
Název údaje  Formát údaje  Zdroj  Klasifikace údajů (osobní/neosobní)  Souhlas s dostupností 
údajů  Dostupnost  
řidič druhý řidič  
Driver1WorkingState  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  povinné  
Driver2WorkingState  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  povinné  
DriveRecognize  ISO 16844-7  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
Driver1TimeRelated­
States  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  povinné  
Driver2TimeRelated­
States  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  povinné  
DriverCardDriver1  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  povinné  
DriverCardDriver2  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  povinné  
OverSpeed  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  povinné  
TimeDate  Dodatek 8  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
HighResolutionTotal­
VehicleDistance  ISO 16844-7  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
HighResolutionTrip­
Distance  ISO 16844-7  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
ServiceComponentI­
dentification  ISO 16844-7  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
ServiceDelayCalendar­
TimeBased  ISO 16844-7  V U  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.001 — 530  
Název údaje  Formát údaje  Zdroj  Klasifikace údajů (osobní/neosobní)  Souhlas s dostupností 
údajů  Dostupnost  
řidič druhý řidič  
NextCalibrationDate  Dodatek 8  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
Driver1ContinuousDri­
vingTime  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  povinné  
Driver2ContinuousDri­
vingTime  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  povinné  
Driver1CumulativeBre­
akTime  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  povinné  
Driver2CumulativeBre­
akTime  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  povinné  
Driver1CurrentDurati­
onOfSelectedActivity  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  povinné  
Driver2CurrentDurati­
onOfSelectedActivity  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  povinné  
SpeedAuthorised  Dodatek 8  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
TachographCardSlot1  ISO 16844-7  V U  neosobní  neuvádí se  souhlas není 
nutný  povinné  
TachographCardSlot2  ISO 16844-7  V U  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  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
ModeOfOperation  ISO 16844-7  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
Driver1CumulatedDri­
vingTimePreviousAnd­
CurrentWeek  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  povinné  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  V U  neuvádí se  osobní  souhlas druhého 
řidiče  povinné  
EngineSpeed  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
RegisteringMember­
State  Dodatek 8  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
VehicleRegistration­
Number  Dodatek 8  V U  neosobní  neosobní  souhlas není 
nutný  povinné  
Driver1EndOfLastDa­
ilyRestPeriod  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2EndOfLastDa­
ilyRestPeriod  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
Driver1EndOfLast­
WeeklyRestPeriod  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2EndOfLast­
WeeklyRestPeriod  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
Driver1EndOfSecond­
LastWeeklyRestPeriod  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2EndOfSecond­
LastWeeklyRestPeriod  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
Driver1TimeLastLo­
adUnloadOperation  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2TimeLastLo­
adUnloadOperation  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
Driver1CurrentDaily­
DrivingTime  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2CurrentDaily­
DrivingTime  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
Driver1CurrentWeekly­
DrivingTime  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2CurrentWeekly­
DrivingTime  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2TimeLeftUntil­
NewDailyRestPeriod  ISO 16844-7  V U  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  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2CardNextMan­
datoryDownloadDate  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
TachographNextMan­
datoryDownloadDate  ISO 16844-7  V U  neosobní  neosobní  souhlas není 
nutný  nepovinné  
Driver1TimeLeftUntil­
NewWeeklyRestPeriod  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2TimeLeftUntil­
NewWeeklyRestPeriod  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
Driver1NumberOf­
Times9hDailyDriving­
TimesExceeded  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2NumberOf­
Times9hDailyDriving­
TimesExceeded  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
Driver1Cumulative 
UninterruptedRestTime  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2Cumulative 
UninterruptedRestTime  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
Driver1MinimumDa­
ilyRest  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2MinimumDa­
ilyRest  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2MinimumWee­
klyRest  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
Driver1MaximumDa­
ilyPeriod  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2MaximumDa­
ilyPeriod  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
Driver1MaximumDa­
ilyDrivingTime  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2MaximumDa­
ilyDrivingTime  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
Driver1NumberOfUse­
dReducedDailyRestPe­
riods  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2NumberOfUse­
dReducedDailyRestPe­
riods  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
Driver1RemainingCur­
rentDrivingTime  ISO 16844-7  V U  osobní  neuvádí se  souhlas řidiče  nepovinné  
Driver2RemainingCur­
rentDrivingTime  ISO 16844-7  V U  neuvádí se  osobní  souhlas druhého 
řidiče  nepovinné  
VehiclePosition  Dodatek 8  V U  osobní  osobní  souhlas řidiče 
a druhého řidiče  povinné  
ByDefaultLoadType  Dodatek 8  V U  osobní  osobní  souhlas řidiče 
a druhého řidiče  povinné  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 D SRC  
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.001 — 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.001 — 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ýc h 
zástupci příslušných kontrolních orgánů používají specifikovano u 
bezdrátovou komunikaci 5,8 GHz DSRC pro získávání údajů ( dat) na ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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é identifiku jí poten­
ciální přestupek, jak je uvedeno v článku 9 nařízení (EU) č. 16 5/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í h motnosti 
a rozměry těžkých nákladních vozidel podle směrnice (EU) 2015/7 19) 
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.001 — 538  
— Bezpečnostní podmínky dat (např. šifrování) týkající se obsah u dat 
(které jsou stanoveny v dodatku 11 – Společné bezpečnostní 
mechanismy.  
— Podrobnosti jiných koncepcí dat než RTM, která lze získávat p omocí 
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.001 — 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.001 — 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ásl edující 
předpisy a normy nebo jejich části a je na nich závislá. V rámc i 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 7 0-03 
(s kontrolou příslušných parametrů EN 300 674-1), v sestupném p oř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 tachografe ch 
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í do pravy.  
[2] Nařízení Evropského parlamentu a Rady (ES) č. 561/2006 o ha rmo­
nizaci některých předpisů v sociální oblasti týkajících se siln ič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 coo pe­
rative telematics applications for regulated commercial freight  
vehicles (TARV).  
[5] EN 300 674-1 Electromagnetic compatibility and Radio spectr um 
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 In du­
strial, Scientific and Medical (ISM) band; Part 1: General char ac­
teristics and test methods for Road Side Units (RSU) and On-Boa rd 
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.001 — 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 interfac e 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.001 — 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 DS RC 
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říz ení (EU) 
č. 165/2014. Po této identifikaci pověřená osoba příslušného ko ntrolního 
orgánu, která kontroluje dotazování, rozhodne, zda má být vozid lo 
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.001 — 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 vozidl a, 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é polo ze 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 p opsá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 pom ocí 
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.001 — 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.001 — 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.001 — 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é komunikac e. 
Informace se mohou zobrazovat na obrazovce, jako tištěný výstup , 
zvukový signál nebo kombinace těchto možností. Způsob tohoto zo bra­
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.001 — 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.001 — 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ěři t 
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 n ikoli, 
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ýzna m 
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.001 — 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 G Hz 
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ýc h 
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.001 — 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  m s  (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.001 — 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 soul adu 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.001 — 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.001 — 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 soulad u 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.001 — 554  
DSC_32 Anténa VU je připevněna k čelnímu sklu vozidla nebo v je ho 
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.001 — 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.001 — 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.001 — 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 o d 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  d o 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 popsa t 
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.001 — 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.001 — 559
  
► (2) (3) M1 
► (1) M3 ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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
 
Oktet č. 
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.001 — 570
 Oktet č. 
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
 
Oktet č. 
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.001 — 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
 
Oktet č. 
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.001 — 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
 Oktetč : 
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.001 — 573
 Oktetč : 
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  N e  
Element Identifier (EID)  Podle specifikace ve VST. Bez rozší­ 
ření ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 574  
Pole Nastavení  
Access Credentials  N e  
AttributeIdList  Bez rozšíření, 1 atribut, AttributeID = 
1 (RtmData)  
Fragmentation  N e  
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
 
Oktet č. 
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.001 — 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  N e  
Element Identifier (EID)  Podle specifikace ve VST.  
Access Credentials  N e  
Fragmentation  N e  
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
 
Oktet č. 
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.001 — 576
 Oktet č. 
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
 
Oktet č. 
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.001 — 577
 Oktet č. 
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 pr ová­
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é v yž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.001 — 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é r elace 
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.001 — 579  
Tabulka 14.15  
Příklad rámce žádosti ACTION, ECHO  
▼C2
 
Oktet č. 
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.001 — 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
 
Oktet č. 
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.001 — 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.001 — 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 instala ci, 
kalibraci a spuštění motoru/VU.  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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ý LinkI­
dentifier.  
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  s e 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.001 — 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 1 1 
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í neji s­
tých atmosférických a interferenčních podmínek, zejména v kombi nacích 
„přenosné REDCR“ a „pohybující se vozidlo“ v rámci této aplikac e. 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í j e 
chyba čtení běžná a důsledkem je obvykle nový pokus, tj. nová r elace 
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é vozid lo 
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ýc h 
spojení.)  
Chyba čtení může být důsledkem nesprávného spárování antén (chy ba 
„zaměření“); zastínění jedné z antén – může být úmyslné, ale ro vněž 
důsledkem fyzické přítomnosti jiného vozidla; rádiové interfere nce, 
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 rad a­
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é man ipu­
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í kol egů 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 k omu­
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.001 — 585  
„Selhání čtení“ je technicky odlišné od „chyby“. V této souvisl osti 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í cyklic ký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 zno vu. 
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řije tí 
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.001 — 586  
1) Test ECHO pro posouzení bezdrátového komunikačního 
kanálu  DSRC-REDCR  >>-:-< DSRC-VU . 
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  >>-:-< DSRC-VU . 
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řístu pu 
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řijm out 
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  >>-:-< DSRC-VU ) 
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íh o 
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 v zdá­
lenosti 2 až 10 metrů před vozidlem.  
DSC_87 Potom pracovníci dílny vloží do testovací čtečky DSRC ka rtu 
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.001 — 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áctide nní 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 k aret #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 (neb o 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 úvah u. 
Č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 z ačátku 
záznamů činností karty denní dobu odpočinku.  
2. Pojmy  
Následující pojmy se vztahují výhradně na tento dodatek a jejic h úč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 konce m 
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 RT M; 
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ředc hozí a probíha­
jící týden;  ▼M3
 02016R0799 — CS — 21.08.2023 — 003.001 — 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čin ku, 
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či nku 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 dvak rá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 zahrnu jí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á do ba 
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í do by 
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či nku 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 h odiny 
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či nku, 
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.001 — 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 od po­ 
činku a nejméně 9 hodin v případě druhé doby odpočinku, pokud p rvní 
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čink u, 
která byla přerušena;  
k) „týden“ je doba v UTC mezi 00:00 hodinou v pondělí a 24:00 h odinou 
v neděli;  
3. Výpočet doby odpočinku, pokud byla přerušena z důvodu převoz u lodí/ 
vlakem  
Pro výpočet doby odpočinku, když byla přerušena v důsledku přev ozu 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ŘEVO Z 
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 s plně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 wo rk 
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.001 — 590  
Je-li splněna alespoň jedna z výše uvedených podmínek, VU buď z astaví 
výpočet součtové doby odpočinku podle kroku 2, nebo zjistí přer uš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ře trž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 krok u 3. 
c) Krok č. 3  
Pokud po provedení kroku 2 VU pokračuje ve výpočtu součtové dob y 
odpočinku, musí VU zjistit přerušení, k nimž došlo po deaktivac i 
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 n epř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 p odmí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í/vl akem.  
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.001 — 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.001 — 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či nku, 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 prav idelnou 
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 pro bí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.001 — 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 vy hrazené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 druho u 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.001 — 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 interoperabi lní s celky 
ve vozidle první generace (v souladu s přílohou IB nařízení (EH S) 
č. 3821/85) a každá verze tachografů druhé generace je interope rabilní 
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 moho u 
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žív at 
pouze karty dílny druhé generace.  
MIG_005 Pro určení provozního režimu musí celky ve vozidlech kt eré­
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é generac e jsou 
interoperabilní s kteroukoli verzí druhé generace celků ve vozi dle. 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.001 — 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še mi 
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ýc h 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, kte ré 
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é gen erace, 
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.001 — 596  
2.4.3  Stahování z celku ve vozidle  
MIG_014 Nad rámec kontroly řidičů kontrolními orgány, které nep atří 
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, kte ré 
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 dispo zici 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 verz e 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.001 — 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.001 — 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 poh ybu 
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: Rozh raní 
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) zabezp e­ 
č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.001 — 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ákl adě 
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 k abely, 
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říze ní 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.001 — 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 automat ické 
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í impu lsy 
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řípad ech 
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 identi fikační 
data zabudovaného snímače pohybu [95].  ▼B
 02016R0799 — CS — 21.08.2023 — 003.001 — 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 ad ap­
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 d efi­
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ý obs ahuje 
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.001 — 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řídi t 
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 (p ravi­
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.001 — 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í typ u 
ú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říze ní 
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.001 — 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.001 — 605  
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, n ebo písmena 
země, která udělila schválení, v souladu s těmito dohodnutými z nač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 k arty 
tachografu a které se umístí kdekoli v bezprostřední blízkosti obdélníku.  ▼C1
 02016R0799 — CS — 21.08.2023 — 003.001 — 606  
2. Značka schválení musí být připojena na popisný štítek každéh o 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.001 — 607  
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 to to 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áznam ový 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.001 — 608  
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 to to 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.001 — 609  
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 to to 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á.