Tento dokument slouží výhradn ě k informa čním účelům a nemá žádný právní ú činek. Orgány a instituce Evropské unie 
nenesou za jeho obsah žádnou odpov ědnost. Závazná zn ění příslušných právních p ředpisů, včetně jejich právních východisek 
a odůvodnění, jsou zve řejněna v Úředním věstníku Evropské unie a jsou k dispozici v databázi EUR-Lex. Tato ú řední znění 
jsou přímo dostupná p řes odkazy uvedené v tomto dokumentu  
►B PROVÁD ĚCÍ NAŘÍZENÍ KOMISE (EU) 2016/799  
ze dne 18. b řezna 2016,  
kterým se provádí na řízení Evropského parlamentu a Rady (EU) č. 165/2014, kterým se stanoví 
požadavky na konstrukci, zkoušení, montáž, provoz a opravy tachograf ů a jejich sou částí 
(Text s významem pro EHP)  
(Úř. věst. L 139, 26.5.2016, s. 1)  
Ve znění: 
Úřední věstník  
Č. Strana  Datum  
►M1 Provád ěcí nařízení Komise (EU) 2018/502 ze dne 28. února 2018  L 85  1  28.3.2018  
►M2 Provád ěcí nařízení Komise (EU) 2020/158 ze dne 5. února 2020  L 34  20  6.2.2020  
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 — 26.02.2020 — 002.001 — 1
02016R0799 — CS — 26.02.2020 — 002.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é uplat ňo­
vání následujících aspekt ů týkajících se tachograf ů: 
a) zaznamenávání polohy vozidla v ur čitých místech b ěhem denní 
pracovní doby řidiče; 
b) dálkového v časného odhalování p řípadné manipulace s inteligentními 
tachografy nebo jejich zneužití;  
c) rozhraní s inteligentními dopravními systémy;  
d) administrativních a technických požadavk ů na postupy schválení 
typu tachograf ů, včetně bezpečnostních mechanism ů. 
▼M1 
2. Konstrukce, zkoušení, montáž, kontrola, provoz a opravy inteli ­
gentních tachograf ů a jejich sou částí musí spl ňovat technické požadavky 
stanovené v p říloze IC tohoto na řízení.  
3. Tachografy jiné než inteligentní musí nadále, pokud jde o jejich 
konstrukci, zkoušení, montáž, kontrolu, provoz a opravy, spl ňovat podle 
konkrétního p řípadu požadavky stanovené bu ď v příloze I nařízení (EU) 
č. 165/2014, nebo v p říloze IB na řízení Rady (EHS) č. 3821/85 (  1 ). 
▼B 
4. Podle článku 10d sm ěrnice Evropského parlamentu a Rady 
96/53/ES musí za řízení pro v časné dálkové odhalování rovn ěž předávat 
údaje o hmotnosti poskytované interním palubním systémem pro zjiš ­ 
ťování hmotnosti za ú čelem včasného odhalování podvod ů. 
▼M1 
5. Tímto na řízením není dot čena směrnice Evropského parlamentu 
a Rady 2014/53/EU (  2 ). 
▼B 
Článek 2  
Definice  
Pro účely tohoto na řízení se použijí definice stanovené v článku 2 
nařízení (EU) č. 165/2014.  ▼B 
( 1 ) Nařízení Rady (EHS) č. 3821/85 ze dne 20. prosince 1985 o záznamovém 
zařízení v silni ční dopravě (Úř. věst. L 370, 31.12.1985, s. 8). 
( 2 ) Směrnice 2014/53/EU Evropského parlamentu a Rady ze dne 16. dubna 2014 
o harmonizaci právních p ředpisů členských stát ů týkajících se dodávání rádi ­
ových zařízení na trh a zrušení sm ěrnice 1999/5/ES (Ú ř. věst. L 153, 
22.5.2014, s. 62).
 02016R0799 — CS — 26.02.2020 — 002.001 — 3  
Kromě toho se rozumí:  
1) „digitálním tachografem“ nebo „tachografem první generace“ digi ­
tální tachograf, který není inteligentním tachografem;  
2) „vnějším zařízením GNSS“ za řízení, které obsahuje p řijímač GNSS 
v případě, kdy celek ve vozidle není jediným celkem, jakož i další 
součásti nezbytné pro ochranu sd ělování údaj ů o poloze zbytku 
celku ve vozidle;  
▼M1 
3) „dokumentací výrobce“ úplná dokumentace v elektronické nebo 
tištěné podobě, která obsahuje všechny informace poskytované 
výrobcem nebo jeho zmocn ěncem orgánu p říslušnému pro schva ­
lování typu pro ú čely schválení typu tachografu nebo jeho sou části, 
včetně osvědčení uvedených v čl. 12 odst. 3 na řízení (EU) 
č. 165/2014, provád ění zkoušek definovaných v p říloze IC tohoto 
nařízení, jakož i výkresy, fotografie a další p říslušné doklady;  
▼B 
4) „schvalovací dokumentací“ dokumentace výrobce v elektronické 
nebo tištěné podobě společně s dalšími dokumenty p řiloženými 
orgánem p říslušným pro schvalování typu k dokumentaci výrobce 
v průběhu výkonu jeho funkcí, v četně osvědčení ES schválení typu 
tachografu nebo jeho konstruk ční součásti na konci postupu schva ­
lování typu;  
5) „seznamem schvalovací dokumentace“ dokument uvád ějící očíslo­
vaný obsah schvalovací dokumentace identifikující všechny rele ­
vantní části této dokumentace. Formát tohoto dokumentu musí 
rozlišovat po sob ě jdoucí kroky p ři postupu ES schvalování typu, 
včetně dat všech revizí a aktualizací uvedené dokumentace;  
6) „zařízením pro v časné dálkové odhalování“ za řízení celku ve 
vozidle, které je používáno k provád ění cílených silni čních kontrol;  
▼M1 
7) „inteligentním tachografem“ nebo „tachografem druhé generace“ 
digitální tachograf, který spl ňuje požadavky článků 8, 9 a 10 na ří­
zení (EU) č. 165/2014, jakož i p řílohy IC tohoto na řízení;  
8) „součástí tachografu“ kterýkoli z t ěchto prvků: celek ve vozidle, 
snímač pohybu, záznamový list, vn ější zařízení GNSS a vn ější 
zařízení pro v časné dálkové odhalování;  
▼B 
9) „orgánem p říslušným pro schvalování typu“ orgán členského státu 
oprávněný k provád ění schvalování typu tachografu nebo jeho 
součástí, provád ění postupu schvalování, vydávání a v p říslušných 
případech odebírání osv ědčení o schválení typu, který p ůsobí jako 
kontaktní místo pro orgány p říslušné pro schvalování typu ostatních 
členských stát ů a zajišťuje, aby výrobci plnili své povinnosti týka ­
jící se souladu s požadavky tohoto na řízení;  
▼M1 
10) „celkem ve vozidle“ tachograf s výjimkou sníma če pohybu a kabel ů 
připojujících sníma č pohybu.  
Může jím být jediný celek nebo n ěkolik celk ů rozmístěných 
ve vozidle, p řičemž zahrnuje řídicí jednotku, datovou pam ěť, funkci 
měření času, dvě čtecí zařízení čipových karet pro řidiče a druhého  ▼B
 02016R0799 — CS — 26.02.2020 — 002.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 komuni ­
kaci.  
Celek ve vozidle m ůže sestávat z t ěchto součástí, které podléhají 
schválení typu:  
— celku ve vozidle jakožto jediné sou části (včetně přijímače 
GNSS a za řízení pro dálkovou komunikaci),  
— hlavní jednotky celku ve vozidle (v četně zařízení pro dálkovou 
komunikaci) a vn ějšího zařízení GNSS,  
— hlavní jednotky celku ve vozidle (v četně přijímače GNSS) 
a vnějšího zařízení pro dálkovou komunikaci,  
— hlavní jednotky celku ve vozidle, vn ějšího přijímače GNSS 
a vnějšího zařízení pro dálkovou komunikaci.  
Pokud celek ve vozidle sestává z n ěkolika celk ů rozmístěných 
ve vozidle, je hlavní jednotkou celku ve vozidle celek obsahující 
řídicí jednotku, datovou pam ěť a funkci m ěření času. 
Výraz „celek ve vozidle (VU)“ se používá pro ozna čení „celku ve 
vozidle“ nebo „hlavní jednotky celku ve vozidle.“  
▼B 
Článek 3  
Služby vycházející z ur čení polohy  
1. Výrobci zajistí, aby inteligentní tachografy byly kompatibilní se 
službami ur čování polohy, které poskytují systémy Galileo a evropská 
služba pro pokrytí geostacionární navigací (EGNOS).  
2. Výrobci se mohou také rozhodnout, že krom ě systémů uvedených 
v odstavci 1 zajistí kompatibilitu s dalšími družicovými naviga čními 
systémy.  
Článek 4  
Postup schvalování typu tachografu a sou částí tachografu  
1. Výrobce nebo jeho zmocn ěnec předloží žádost o schválení typu 
tachografu nebo jakékoli jeho sou části nebo skupiny sou částí orgánům 
příslušným pro schvalování typu ur čeným každým členským státem. 
Žádost se skládá se z dokumentace výrobce obsahující informace 
o všech dot čených sou částech, v p říslušných p řípadech včetně osvěd­ 
čení o schválení typu ostatních sou částí, jež jsou nezbytné ke zkom ­
pletování tachografu, jakož i všech dalších p říslušných dokument ů. 
2. Členský stát ud ělí schválení typu všem tachograf ům, součástem 
nebo skupinám sou částí, které spl ňují administrativní a technické poža ­
davky uvedené v p říslušných p řípadech v čl. 1 odst. 2 nebo 3. 
V takovém p řípadě vydá orgán p říslušný pro schvalování typu žadateli 
osvědčení o schválení typu, které musí být v souladu se vzorem 
uvedeným v p říloze II tohoto na řízení.  
3. Orgán p říslušný pro schvalování typu m ůže požádat výrobce nebo 
jeho zmocn ěnce o předložení jakýchkoli dalších informací.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.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 dispozici takový 
počet tachograf ů nebo sou částí tachograf ů, který je nezbytný k tomu, 
aby mohl být uspokojivé proveden postup schválení typu.  
5. Jestliže chce výrobce nebo jeho zmocn ěnec získat schválení typu 
určitých součástí nebo skupin sou částí tachografu, musí orgán ům 
příslušným pro schvalování typu poskytnout ostatní sou části, jejichž 
typ byl již schválen, jakož i ostatní sou části nezbytné pro konstrukci 
kompletního tachografu, aby tyto orgány mohly provést pot řebné zkou­ 
šky. 
Článek 5  
Změny schválení typu  
1. Výrobce nebo jeho zmocn ěnec neprodlen ě uvědomí orgány 
příslušné pro schvalování typu, které ud ělily původní schválení typu, 
o všech zm ěnách softwarového nebo hardwarového vybavení tachografu 
nebo povahy materiál ů použitých k jeho výrob ě, které jsou zazname ­
nány ve schvalovací dokumentaci, a p ředloží žádost o zm ěnu schválení 
typu.  
2. Orgány p říslušné pro schvalování typu mohou podle povahy 
a charakteru t ěchto změn revidovat či rozšířit stávající schválení typu 
nebo vydat nové schválení typu.  
„Revize“ se provede, jestliže se orgán p říslušný pro schvalování typu 
domnívá, že zm ěny softwarového nebo hardwarového vybavení tacho ­
grafu nebo povahy materiál ů použitých k jeho výrob ě jsou malé. V tako ­
vých případech orgán p říslušný pro schvalování typu vydá revidované 
dokumenty schvalovací dokumentace a uvede povahu provedených 
změn a datum jejich schválení. Pro spln ění tohoto požadavku posta čuje 
aktualizovaná verze schvalovací dokumentace v konsolidované podob ě 
spolu s podrobným popisem provedených zm ěn. 
„Rozšíření“ se provede, jestliže se orgán p říslušný pro schvalování typu 
domnívá, že zm ěny softwarového nebo hardwarového vybavení tacho ­
grafu nebo povahy materiál ů použitých k jeho výrob ě jsou významné. 
V takových p řípadech m ůže požadovat provedení nových zkoušek a v 
souladu s tím informovat výrobce nebo jeho zmocn ěnce. Pokud jsou 
tyto zkoušky uspokojivé, vydá orgán p říslušný pro schvalování typu 
revidované osv ědčení o schválení typu, s číslem odkazujícím na ud ělené 
rozšíření. V osv ědčení o schválení typu se uvede d ůvod rozšíření 
a datum jeho vystavení.  
3. V seznamu schvalovací dokumentace se uvede datum posledního 
rozšíření, nebo revize schválení typu, nebo datum poslední konsolidace 
aktualizované verze tohoto schválení typu.  
4. Nové schválení typu je nezbytné, pokud by požadované zm ěny 
tachografu, jehož typ byl již schválen, nebo jeho sou částí vedly k vydání 
nového osv ědčení o bezpe čnosti nebo interoperabilit ě. ▼B
 02016R0799 — CS — 26.02.2020 — 002.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 — 26.02.2020 — 002.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í pracovní 
doby  
3.6.2 Ru ční vkládání údaj ů o činnostech řidiče a souhlas řidiče pro 
rozhraní ITS  
3.6.3 Vkládání údaj ů o zvláštních podmínkách  
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 — 26.02.2020 — 002.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í“  
3.10 Integrované zkoušky a autotesty  
3.11 Na čítání z datové pam ěti 
3.12 Zaznamenávání a ukládání do datové pam ěti 
3.12.1 Údaje identifikující za řízení  
3.12.1.1 Identifika ční údaje o celku ve vozidle  
3.12.1.2 Identifika ční údaje sníma če pohybu  
3.12.1.3 Identifika ční údaje globálních naviga čních družicových systém ů 
3.12.2 Klí če a certifikáty  
3.12.3 Data související s vložením a vyjmutím karty řidiče nebo dílny  
3.12.4 Údaje o činnostech řidiče 
▼M1 
3.12.5 Místa a polohy, kde za číná nebo kon čí denní pracovní doba a/nebo 
kde je dosaženo t ří hodin sou čtové doby řízení 
▼B 
3.12.6 Údaje po čitadla ujetých kilometr ů 
3.12.7 Podrobné údaje o rychlosti  
3.12.8 Údaje o událostech  
3.12.9 Údaje o závadách  
3.12.10 Kalibra ční údaje  
3.12.11 Údaje o nastavení času 
3.12.12 Údaje o kontrolních činnostech  
3.12.13 Údaje o zámcích podnik ů 
3.12.14 Údaje o stahování  
3.12.15 Údaje o zvláštních podmínkách  
3.12.16 Údaje o kart ě tachografu  
3.13 Čtení z karet tachografu  
3.14 Zaznamenávání a ukládání údaj ů na kartách tachografu  
3.14.1 Zaznamenávání a ukládání údaj ů na kartách tachografu první gene ­ 
race 
3.14.2 Zaznamenávání a ukládání údaj ů na kartách tachografu druhé gene ­ 
race 
3.15 Zobrazení  
3.15.1 Výchozí zobrazení  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 9  
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  
3.20 Výstupní údaje pro p řídavná externí za řízení  
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í 
4 KONSTRUK ČNÍ A FUNK ČNÍ POŽADAVKY NA KARTY 
TACHOGRAFU  
4.1 Viditelné údaje  
4.2 Zabezpe čení 
4.3 Normy  
4.4 Environmentální a elektrické specifikace  
4.5 Ukládání údaj ů 
4.5.1 Elementární soubory pro identifikaci a správu karty  
4.5.2 Identifikace čipové karty  
4.5.2.1 Identifikace čipu 
4.5.2.2 DIR (pouze v kartách tachografu druhé generace)  
4.5.2.3 Informace ATR (podmíne čné, pouze v kartách tachografu druhé 
generace)  
4.5.2.4 Informace o rozší řené délce (podmíne čná, pouze v kartách tacho ­ 
grafu druhé generace)  
4.5.3 Karta řidiče 
4.5.3.1 Aplikace tachografu (p řístupná pro celky ve vozidle první a druhé 
generace)  
4.5.3.1.1 Identifikace aplikace  
4.5.3.1.2 Klí če a certifikáty  
4.5.3.1.3 Identifikace karty  
4.5.3.1.4 Identifikace držitele karty  
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 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 10  
4.5.3.1.10 Údaje o použitých vozidlech  
4.5.3.1.11 Místa, kde za číná a/nebo kon čí denní pracovní doba  
4.5.3.1.12 Údaje o relaci karty  
4.5.3.1.13 Údaje o kontrolních činnostech  
4.5.3.1.14 Údaje o zvláštních podmínkách  
4.5.3.2 Aplikace tachografu druhé generace (nep řístupná pro celek ve 
vozidle první generace)  
4.5.3.2.1 Identifikace aplikace  
4.5.3.2.2 Klí če a certifikáty  
4.5.3.2.3 Identifikace karty  
4.5.3.2.4 Identifikace držitele karty  
4.5.3.2.5 Stahování z karty  
4.5.3.2.6 Informace o řidičském průkazu  
4.5.3.2.7 Údaje o událostech  
4.5.3.2.8 Údaje o závadách  
4.5.3.2.9 Údaje o činnostech řidiče 
4.5.3.2.10 Údaje o použitých vozidlech  
4.5.3.2.11 Místa a polohy, kde za číná a/nebo kon čí denní pracovní doba  
4.5.3.2.12 Údaje o relaci karty  
4.5.3.2.13 Údaje o kontrolních činnostech  
4.5.3.2.14 Údaje o zvláštních podmínkách  
4.5.3.2.15 Údaje o použitých celcích ve vozidle  
▼M1 
4.5.3.2.16 Údaje o místech sou čtové tříhodinové doby řízení 
▼B 
4.5.4 Karta dílny  
4.5.4.1 Aplikace tachografu (p řístupná pro celky ve vozidle první a druhé 
generace)  
4.5.4.1.1 Identifikace aplikace  
4.5.4.1.2 Klí če a certifikáty  
4.5.4.1.3 Identifikace karty  
4.5.4.1.4 Identifikace držitele karty  
4.5.4.1.5 Stahování z karty  
4.5.4.1.6 Údaje o kalibraci a nastavování času 
4.5.4.1.7 Údaje o událostech a závadách  
4.5.4.1.8 Údaje o činnostech řidiče 
4.5.4.1.9 Údaje o použitých vozidlech  
4.5.4.1.10 Údaje o za čátku a/nebo konci denní pracovní doby  
4.5.4.1.11 Údaje o relaci karty  
4.5.4.1.12 Údaje o kontrolních činnostech  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 11  
4.5.4.1.13 Údaje o zvláštních podmínkách  
4.5.4.2 Aplikace tachografu druhé generace (nep řístupná pro celek ve 
vozidle první generace)  
4.5.4.2.1 Identifikace aplikace  
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  
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  
4.5.5 Kontrolní karta  
4.5.5.1 Aplikace tachografu (p řístupná pro celky ve vozidle první a druhé 
generace)  
4.5.5.1.1 Identifikace aplikace  
4.5.5.1.2 Klí če a certifikáty  
4.5.5.1.3 Identifikace karty  
4.5.5.1.4 Identifikace držitele karty  
4.5.5.1.5 Údaje o kontrolních činnostech  
4.5.5.2 Aplikace tachografu druhé generace (nep řístupná pro celek ve 
vozidle první generace)  
4.5.5.2.1 Identifikace aplikace  
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  
4.5.6 Karta podniku  
4.5.6.1 Aplikace tachografu (p řístupná pro celky ve vozidle první a druhé 
generace)  
4.5.6.1.1 Identifikace aplikace  
4.5.6.1.2 Klí če a certifikáty  
4.5.6.1.3 Identifikace karty  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 12  
4.5.6.1.4 Identifikace držitele karty  
4.5.6.1.5 Údaje o činnosti podniku  
4.5.6.2 Aplikace tachografu druhé generace (nep řístupná pro celek ve 
vozidle první generace)  
4.5.6.2.1 Identifikace aplikace  
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  
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  
ÚVOD  
Systém digitálních tachograf ů první generace byl zaveden 1. kv ětna 2006. 
V oblasti vnitrostátní dopravy se m ůže používat po celou dobu své životnosti. 
Naproti tomu v oblasti mezinárodní dopravy musí být všechna vozidla nejpozd ěji 
15 let po vstupu tohoto na řízení Komise v platnost vybavena vyhovujícím inte ­
ligentním tachografem druhé generace, který zavádí toto na řízení.  
Tato příloha obsahuje požadavky na záznamové za řízení a karty tachografu druhé 
generace.  
Od data zavedení je záznamové za řízení druhé generace montováno ve vozidlech 
registrovaných poprvé a jsou vydávány karty tachografu druhé generace. Pro 
usnadnění plynulého zavád ění systému tachograf ů druhé generace  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 13  
— jsou karty tachografu druhé generace navrženy tak, aby byly použitelné i v 
celcích ve vozidle první generace,  
— není k datu zavedení požadována vým ěna platných karet tachografu první 
generace.  
Řidičům to umožní ponechat si svou jedine čnou kartu řidiče a používat ji v obou 
systémech.  
Záznamové za řízení druhé generace však musí být kalibrováno pouze pomocí 
karet dílny druhé generace.  
Tato příloha obsahuje všechny požadavky týkající se interoperability mezi 
systémy tachograf ů první a druhé generace.  
Dodatek 15 obsahuje dodate čné podrobnosti o správ ě obou soub ěžně existujících 
systémů. 
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ŽI ­ 
COVÉ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  
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;  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 14  
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); 
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čka vozidla VRN a členský stát registrace) a vlastnosti 
vozidla (charakteristický koeficient vozidla  w, konstantu 
záznamového za řízení  k, účinný obvod kol  l, rozměr pneuma­
tik, nastavení omezova če rychlosti (v p říslušných p řípadech), 
aktuální čas UTC, aktuální stav po čitadla ujetých kilometr ů); 
během kalibrace záznamového za řízení jsou v datové pam ěti 
rovněž uloženy typy a identifikátory všech p říslušných plomb 
schválení typu.  
Jakékoli obnovení nebo potvrzení pouze času UTC se pova ­ 
žuje za úpravu času, a nikoli za kalibraci, pokud není v rozporu 
s požadavkem 409.  
Kalibrace záznamového za řízení vyžaduje 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 
(v příslušných p řípadech) po řadový index karty, index náhrady 
karty a index obnovy karty.  
Karta je tedy jednozna čně identifikována kódem vydávajícího 
členského státu a číslem karty;  
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;  
i) „indexem obnovy karty“:  
šestnáctý alfanumerický znak v čísle karty, který je zvyšován 
pokaždé, když je karta obnovována;  
j) „indexem náhrady karty“:  
patnáctý alfanumerický znak v čísle karty, který je zvyšován 
pokaždé, když je karta nahrazována;  
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; ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 15  
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 
kilometru; 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;  
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.  ▼B 
( 1 ) Tento zp ůsob výpočtu nepřetržité doby řízení a kumulativní doby p řestávek slouží 
v záznamovém za řízení pro výpo čet varování o nep řetržité dob ě řízení. To však nena ­
hrazuje právní výklad, který je t řeba použít na tyto doby. Alternativní zp ůsoby výpo čtu 
nepřetržité doby řízení a souhrnné doby p řestávek lze použít k nahrazení t ěchto definic, 
pokud by se staly zastaralými v d ůsledku aktualizací v jiných p říslušných právních 
předpisech. 
( 2 ) NEZNÁMÁ doba odpovídá intervalu, kdy není do záznamového za řízení vložena karta 
řidiče a po které nebyl z řidičovy aktivity vložen ru čně žádný údaj. 
( 3 ) Nařízení Evropského parlamentu a Rady (ES) č. 561/2006 ze dne 15. b řezna 2006 
o harmonizaci n ěkterých předpisů v sociální oblasti týkajících se silni ční dopravy, 
o změně nařízení Rady (EHS) č. 3821/85 a (ES) č. 2135/98 a o zrušení na řízení Rady 
(EHS) č. 3820/85 (Ú ř. věst. L 102, 11.4.2006, s. 1).
 02016R0799 — CS — 26.02.2020 — 002.001 — 16  
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.  
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 
provozní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;  ▼B 
( 1 ) Nařízení Komise (EU) č. 1230/2012 ze dne 12. prosince 2012, kterým se provádí 
nařízení Evropského parlamentu a Rady (ES) č. 661/2009, pokud jde o požadavky pro 
schvalování typu motorových vozidel a jejich p řípojných vozidel týkající se jejich hmot ­
ností a rozm ěrů, a mění směrnice Evropského parlamentu a Rady 2007/46/ES (Ú ř. věst. 
L 353, 21.12.2012, s. 31) v platném zn ění.
 02016R0799 — CS — 26.02.2020 — 002.001 — 17  
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; 
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;  
ee) „neplatnou kartou“:  
karta, která byla zjišt ěna jako vadná nebo u které chybí úvodní 
prokázání pravosti nebo u které ješt ě nebylo dosaženo data 
platnosti nebo u které již uplynulo datum platnosti;  
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í; 
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í;  ▼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 — 26.02.2020 — 002.001 — 18  
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í;  
▼M1 
ll) „zařízením pro dálkovou komunikaci „nebo“ za řízením pro 
včasné dálkové odhalování“:  
vybavení celku ve vozidle, které se užívá k provád ění cílených 
silničních kontrol;  
▼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;  
nn) „obnovením“:  
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í organizaci. Obnovení vždy zahrnuje 
ujištění, že neexistují dv ě současně platné karty;  
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;  
pp) „náhradou karty“:  
vydání 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í organizaci. Náhrada vždy zahrnuje 
riziko, že mohou existovat dv ě současně platné karty;  
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);  
▼M1 
tt) „nastavením času“:  
nastavení aktuálního času; toto nastavení lze provád ět auto­
maticky v pravidelných intervalech 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í; ▼B 
( 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).
 02016R0799 — CS — 26.02.2020 — 002.001 — 19  
vv) „identifikací vozidla“:  
čísla, která vozidlo identifikují: registra ční značka vozidla 
(VRN) s uvedením členského státu registrace a identifika ční 
číslo vozidla (VIN) (  1 ); 
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:  
▼M1 
— zabudováno a užíváno pouze ve vozidlech typu M1 a N1 
(podle definice v p říloze II sm ěrnice Evropského parla ­
mentu a Rady 2007/46/ES (  2 ) v platném zn ění), 
▼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,  
— 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;  ▼B 
( 1 ) Směrnice Rady 76/114/EHS ze dne 18. prosince 1975 o sbližování právních p ředpisů 
členských stát ů týkajících se povinných štítk ů a nápisů pro motorová vozidla a pro jejich 
přípojná vozidla a pro jejich umíst ění a způsob upevn ění (Úř. věst. L 24, 30.1.1976, 
s. 1). 
( 2 ) Směrnice Evropského parlamentu a Rady 2007/46/ES ze dne 5. zá ří 2007, kterou se 
stanoví rámec pro schvalování motorových vozidel a jejich p řípojných vozidel, jakož 
i systémů, konstruk čních částí a samostatných technických celk ů určených pro tato 
vozidla (rámcová sm ěrnice) (Úř. věst. L 263, 9.10.2007, s. 1).
 02016R0799 — CS — 26.02.2020 — 002.001 — 20  
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;  
aaa) „důvěrností údaj ů“: 
všeobecná technická opat ření pro řádné provád ění zásad podle 
směrnice Evropského parlamentu a Rady 95/46/ES (  1 ) a podle 
směrnice Evropského parlamentu a Rady 2002/58/ES (  2 ); 
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.;  
ccc) „datem zavedení“:  
36 měsíců od vstupu podrobných ustanovení podle článku 11 
nařízení Evropského parlamentu a Rady (EU) č. 165/2014 (  3 ) 
v platnost.  
Je to datum, od kterého vozidla registrovaná poprvé:  
— musí být vybavena tachografem p řipojeným ke služb ě 
určování polohy na základ ě družicového naviga čního 
systému,  
— musí být schopna p ředávat údaje pro cílené silni ční 
kontroly p říslušným kontrolním orgán ům během jízdy 
vozidla,  
— a mohou být vybavena standardními rozhraními umož ňu­
jícími, aby údaje zaznamenané nebo vytvo řené tacho ­
grafem byly používány v provozním režimu vn ějším zaříze­
ním; 
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 
( 1 ) Směrnice Evropského parlamentu a Rady 95/46/ES ze dne 24. října 1995 o ochran ě 
fyzických osob v souvislosti se zpracováním osobních údaj ů a o volném pohybu t ěchto 
údajů (Úř. věst. L 281, 23.11.1995, s. 31). 
( 2 ) Směrnice Evropského parlamentu a Rady 2002/58/ES ze dne 12. července 2002 o zpra ­
cování osobních údaj ů a ochraně soukromí v odv ětví elektronických komunikací (Ú ř. 
věst. L 201, 31.7.2002, s. 37). 
( 3 ) Nařízení Evropského parlamentu a Rady (EU) č. 165/2014 ze dne 4. února 2014 o tacho ­
grafech v silni ční dopravě, o zrušení na řízení Rady (EHS) č. 3821/85 o záznamovém 
zařízení v silni ční dopravě a o změně nařízení Evropského parlamentu a Rady (ES) 
č. 561/2006 o harmonizaci n ěkterých předpisů v sociální oblasti týkajících se silni ční 
dopravy (Ú ř. věst. L 60, 28.2.2014, s. 1).
 02016R0799 — CS — 26.02.2020 — 002.001 — 21  
eee) „přesností GNSS“:  
v souvislosti se zaznamenáváním polohy z globálního navi ­
gačního družicového systému (GNSS) pomocí tachograf ů, 
hodnota horizontálního z ředění přesnosti (HDOP) vypo čítaná 
jako minimum z hodnot HDOP zjišt ěných na dostupných 
systémech GNSS;  
▼M1 
fff) „součtovou dobou řízení“:  
hodnota vyjad řující celkový po čet minut jízdy ur čitého 
vozidla.  
Hodnota sou čtové doby řízení je sou čet minut volného chodu, 
který funkce monitorování činností řízení záznamového 
zařízení považuje za JÍZDU, a používá se pouze ke spušt ění 
záznamu polohy vozidla pokaždé, když sou čtová doba řízení 
dosáhne násobku t ří hodin. S čítání je zahájeno zapnutím 
záznamového za řízení. Tuto hodnotu neovliv ňuje žádná jiná 
podmínka jako „mimo p ůsobnost“ nebo „p řevoz lodí / p řevoz 
vlakem“.  
Hodnota sou čtové doby řízení není ur čena k zobrazování, 
tisku ani stahování.  
▼B 
2 OBECNÉ VLASTNOSTI A FUNKCE ZÁZNAMOVÉHO 
ZAŘÍZENÍ  
2.1 Obecné vlastnosti  
Účelem záznamového za řízení je zaznamenávat, ukládat, zobrazovat 
a tisknout údaje týkající se činností řidiče a umožnit jejich výstup.  
Jakékoliv vozidlo vybavené záznamovým za řízením, které vyhovuje 
podmínkám této p řílohy, musí mít displej rychlom ěru a počitadlo 
ujetých kilometr ů. Tyto funkce mohou být sou částí záznamového 
zařízení.  
01) Záznamové za řízení zahrnuje kabely, sníma č pohybu a celek 
ve vozidle.  
02) Rozhraní mezi sníma či pohybu a celky ve vozidle musí 
splňovat požadavky specifikované v dodatku 11.  
03) Celek ve vozidle musí být p řipojen k jednomu nebo více 
globálním naviga čním družicovým systém ům podle specifi ­
kace 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.  
05) Celek ve vozidle m ůže obsahovat rozhraní ITS, které je 
specifikováno v dodatku 13.  
Záznamové za řízení může být připojeno k dalším za řízením 
přídavnými rozhraními a/nebo volitelným rozhraním ITS.  
06) Jakékoliv zapojení nebo propojení záznamového za řízení 
s jakoukoliv funkcí, za řízením nebo za řízeními, ať již schvá­
lenými nebo neschválenými, nesmí ovliv ňovat nebo být 
schopno ovliv ňovat jeho správný a bezpe čný provoz nebo 
plnění podmínek tohoto na řízení.  
Uživatelé záznamového za řízení se identifikují v za řízení 
prostřednictvím karet tachografu.  
07) Záznamové za řízení zajiš ťuje selektivní p řístupová práva 
k údajům a funkcím v závislosti na typu a/nebo identit ě 
uživatele.  
Záznamové za řízení zaznamenává a ukládá údaje do své datové 
paměti, do zařízení pro dálkovou komunikaci a na karty tachografu.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 22  
Toto se děje v souladu se sm ěrnicí 95/46/ES ze dne 24. října 1995 
o ochraně fyzických osob v souvislosti se zpracováním osobních 
údajů a o volném pohybu t ěchto údajů ( 1 ), se směrnicí 2002/58/ES 
ze dne 12. července 2002 o zpracování osobních údaj ů a ochraně 
soukromí v odv ětví elektronických komunikací (  2 ) a v souladu 
s článkem 7 na řízení (EU) č. 165/2014.  
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 
— údaje vkládané řidičem ručně: 
— vkládání údaj ů o místech po čátku a/nebo ukon čení 
denní pracovní doby,  
— ruční vkládání údaj ů o činnostech řidiče, 
— vkládání údaj ů o zvláštních podmínkách  
— 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í,  
— 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. 
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.  ▼B 
( 1 ) Úř. věst. č. L 281, 23.11.1995, s. 31. 
( 2 ) Úř. věst. č. L 201, 31.7.2002, s. 37.
 02016R0799 — CS — 26.02.2020 — 002.001 — 23  
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 tachografu vloženou do otvoru pro vložení karty řidiče. 
11) Záznamové za řízení musí ignorovat vložení neplatné karty, 
kromě zobrazování, tisku a stahování údaj ů uložených na 
kartách s prošlým datem, které musí být možné.  
12) Všechny funkce uvedené v bod ě 2.2 musí být aktivní 
v jakémkoli provozním režimu s t ěmito výjimkami:  
— kalibra ční funkce je p řístupná pouze v kalibra čním 
režimu,  
— funkce silni ční kalibrační kontroly je p řístupná pouze 
v kontrolním režimu,  
— funkce správy zámk ů podniků je přístupná pouze 
v podnikovém režimu,  
— funkce monitorování kontrolních činností je funk ční 
pouze v kontrolním režimu,  
— funkce stahování není p řístupná v provozním režimu (s 
výjimkou ustanovení požadavku 193) a krom ě stahování 
karty řidiče, není-li do celku ve vozidle vložen jiný typ 
karty.  
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í identifi ­
kač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),  
— v podnikovém režimu lze výstup údaj ů vztahujících se 
k osobě řidiče (požadavky 102, 105 a 108) 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),  
— 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ů, 
— výstup osobních údaj ů pocházejících z celku ve vozidle 
se nesmí provád ět pomocí rozhraní ITS celku ve vozidle, 
není-li ověřen souhlas řidiče, k němuž se údaje vztahují,  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 24  
— celky ve vozidle mají normální dobu platnosti používání 
15 let od data vstupu osv ědčení celku ve vozidle v plat ­
nost, ale celky ve vozidle lze používat další t ři měsíce 
pouze pro stahování údaj ů. 
▼B 
2.4 Bezpe čnost 
▼M1 
Bezpečnost systému má za cíl ochranu datové pam ěti takovým 
způsobem, aby se zabránilo neoprávn ěnému přístupu a manipulaci 
s údaji a aby takové pokusy byly odhaleny, ochranu integrity 
a pravosti údaj ů přenášených mezi sníma čem pohybu a celkem ve 
vozidle, ochranu integrity a pravosti údaj ů přenášených mezi zázna ­
movým za řízením a kartami tachografu, ochranu integrity a pravosti 
údajů přenášených mezi celkem ve vozidle a vn ějším zařízením 
GNSS, ochranu d ůvěrnosti, integrity a pravosti údaj ů přenášených 
pomocí komunikace v časného dálkového odhalování pro kontrolní 
účely a ověřování integrity a pravosti stahovaných údaj ů. 
▼B 
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,  
— vnější zařízení GNSS (tento profil je pot řebný a použitelný 
pouze pro variantu vn ějšího GNSS).  
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í.  
16) Při vložení karty ov ěřuje záznamové za řízení, zda vložená 
karta je platná karta tachografu, a v takovém p řípadě identi­
fikuje typ a generaci karty.  
Pokud karta, která má stejné číslo a vyšší index obnovy, již 
byla vložena do záznamového za řízení, je ozna čena za 
neplatnou.  
Pokud karta, která má stejné číslo a index obnovy, ale vyšší 
index náhrady, již byla vložena do záznamového za řízení, je 
označena za neplatnou.  
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áznamo ­
vého zařízení druhé generace, jsou považovány za neplatné.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 25  
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.  
20) K uvoln ění karet tachografu m ůže dojít pouze po zastavení 
vozidla a poté, co byly p říslušné údaje uloženy na kartách. 
Uvolnění karty musí vyžadovat aktivní zásah uživatele.  
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.  
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 ů), namontované 
v jakémkoli vozidle, které je vybaveno záznamovým za říze­
ní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.  
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 voliteln ě z jednoho 
nebo více dalších zdroj ů nezávislých na sníma či pohybu.  
27) Tato funkce m ěří polohu vozidla, čímž umož ňuje auto­
matický záznam:  
— poloh, kde řidič a/nebo druhý řidič začíná svou denní 
pracovní dobu,  
▼M1 
— poloh, kde sou čtová doba řízení dosáhne násobku t ří 
hodin,  
▼B 
— poloh, kde řidič a/nebo druhý řidič končí svou denní 
pracovní dobu.  
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 — 26.02.2020 — 002.001 — 26  
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.  
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.  
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 pneu ­
matik, …),  
— tolerance ± 1 km/h p ři měřeních provedených p ři montáži 
nebo pravidelných kontrolách.  
Záznamové za řízení pro rychlosti ležící v rozmezí 20 až 
180 km/h a pro charakteristické koeficienty vozidla mezi 
4 000 až 25 000 imp/km musí m ěřit rychlost s tolerancí ± 
1 km/h (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.  
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.  
37) Absolutní poloha je m ěřena v zem ěpisných sou řadnicích 
šířky a délky ve stupních a minutách s rozlišením 1/10 
minuty.  
3.3 M ěření času 
38) Funkce m ěření času musí m ěřit nepřetržitě a udávat v digitální 
podobě údaje o koordinovaném sv ětovém datu a času UTC.  
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 povo ­
leny žádné jiné posuny než v záporných nebo kladných 
násobcích p ůl hodiny.  
41) Nepoužívá-li se žádné nastavení času, nesmí zpož ďování 
nebo zrychlování hodin p řekročit ± 2 sekundy za den 
v podmínkách schvalování typu.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 27  
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 elektric ­
kého napájení na dobu kratší nežli 12 m ěsíců v podmínká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.  
▼M1 
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ža ­
davku 051 považována za JÍZDU, je celá minuta považována 
za stejný typ činnosti jako nejdéle nep řetržitě trvají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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 28  
57) Místa jsou definována jako stát a p řípadně region, které se 
zadávají nebo potvrzují ru čně. 
58) V dob ě vyjmutí karty řidiče vyzve záznamové za řízení (dru­
hého) řidiče, aby vložil údaj o míst ě ukončení denní pracovní 
doby.  
▼M1 
59) Řidič pak vloží aktuální polohu vozidla, která je považována 
za dočasný vstup.  
Za následujících podmínek se do časné údaje vytvo řené při 
posledním vyjmutí karty validují (tj. již se dále nep řepisují):  
— vložení údaje o míst ě zahájení aktuální denní pracovní 
doby při ručním zadání podle požadavku 61,  
— pokud držitel karty nezadá žádné místo, kde zahájil nebo 
ukončil pracovní dobu, další vložení údaje o míst ě 
zahájení aktuální denní pracovní doby p ři ručním zadání 
podle požadavku 61.  
Za následujících podmínek se do časné údaje vytvo řené při 
posledním vyjmutí karty p řepíší a nová hodnota se validuje:  
— pokud držitel karty nezadá žádné místo, kde zahájil nebo 
ukončil pracovní dobu, další vložení údaje o míst ě ukon­ 
čení aktuální denní pracovní doby p ři ručním zadání 
podle požadavku 61.  
▼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 zazname ­
náno jen poslední místo zahájení práce a poslední místo 
ukončení práce provedené v dané dob ě. 
3.6.2  Ru ční vkládání údaj ů o činnostech řidiče a souhlas řidiče pro 
rozhraní ITS  
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í volitelného rozhraní ITS.  
Souhlas řidiče (resp. dílny) lze kdykoli aktivovat nebo deak ­
tivovat pomocí p říkazů v menu, je-li vložena karta řidiče 
(resp. dílny).  
Musí být možno zadávat činnosti s následujícími omezeními:  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 29  
— 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 vkládat ru ční záznamy 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:  
▼M1 
— 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ých údaj ů vytvořených 
při posledním vyjmutí karty).  
▼B 
Pokud držitel karty p ři ručním vkládání údaj ů spojeném 
s vložením karty nevloží žá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ší vložení 
údaje o míst ě, kde ukon čil předchozí denní pracovní dobu, 
pak přepíše dočasné údaje vytvo řené při posledním vyjmutí 
karty.  
Pokud je zadáno n ějaké místo, musí být zaznamenáno na 
příslušnou kartu tachografu.  
Ruční zadávání 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í údaj ů 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ání údaj ů pro tuto p ředchozí 
kartu dokon čit před zahájením ru čního zadávání údaj ů pro 
druhou kartu.  
Držitel karty musí mít možnost ru čně zadávat údaje za 
použití následujícího minimálního postupu:  
— ruční zadání činností v chronologickém po řadí za dobu 
mezi posledním vyjmutím karty a jejím aktuálním vlože ­
ním, ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 30  
— č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ě 
vložené činnosti shoduje s časem vložení karty. Záznamové 
zařízení poté m ůže případně povolit 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.  
3.6.3  Vkládání údaj ů o zvláštních podmínkách  
62) Záznamové za řízení musí řidiči umožnit vložit v reálném 
čase údaje o následujících dvou zvláštních podmínkách:  
— „MIMO P ŮSOBNOST“ (za čátek, konec),  
— „PŘEVOZ LODÍ / P ŘEVOZ VLAKEM“ (za čátek, 
konec).  
K záznamu podmínky „P ŘEVOZ LODÍ / P ŘEVOZ 
VLAKEM“ nesmí dojít, pokud je otev řen záznam podmínky 
„MIMO P ŮSOBNOST“.  
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 p říslušné karty,  
— varování týkající se nep řetržité doby řízení.  
Ukazatel za čátku podmínky „P ŘEVOZ LODÍ / P ŘEVOZ 
VLAKEM“ musí být nastaven p řed tím, nežli se na lodi / 
ve vlaku vypne motor.  
Otevřený záznam podmínky „P ŘEVOZ LODÍ / P ŘEVOZ 
VLAKEM“ musí skon čit, nastane-li n ěkterá z následujících 
možností:  
— řidič ručně ukončí „PŘEVOZ LODÍ / P ŘEVOZ 
VLAKEM“,  
— řidič vyjme svou kartu,  
otevřený záznam podmínky „P ŘEVOZ LODÍ / P ŘEVOZ 
VLAKEM“ musí skon čit, pokud již není platný na základ ě 
pravidel uvedených v na řízení (ES) č. 561/2006.  
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 provedeno 
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  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 31  
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áze­
jí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 zobrazovací 
jednotky nebo jsou z datové pam ěti celku ve vozidle staho ­
vá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ž nahrazené 
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:  
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:  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 32  
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ředchá­
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é rych ­
losti.  
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í definuje 
výrobce. Pokles elektrického napájení v d ůsledku startová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 komu ­
nikace mezi vn ějším zařízením GNSS a celkem ve vozidle, 
je-li vozidlo v pohybu.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 33  
3.9.12  „Chybné údaje o pohybu vozidla“  
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 inte ­
gritě nebo pravosti údaj ů přenášených mezi sníma čem 
pohybu a celkem ve vozidle.  
3.9.13  „Nesoulad údaj ů o pohybu vozidla“  
84) Tato událost nastane,  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 ů údajů podle specifi ­
kace v dodatku 12. Tato událost nenastane b ěhem převozu 
lodí / převozu vlakem, za podmínky MIMO P ŮSOBNOST, 
nebo nejsou-li k dispozici informace o poloze z p řijímače 
GNSS.  
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“  
86) Tato událost nastane,  není-li za řízení v kalibra čním režimu , 
pokud celek ve vozidle zjistí mezi časem funkce m ěření času 
celku ve vozidle a časem pocházejícím z p řijímače GNSS 
nesoulad delší než 1 minuta. Tato událost je zaznamenána 
společně s hodnotou vnit řních hodin celku ve vozidle a je 
zahrnuta do automatického nastavení času. Nastane-li událost 
nesouladu času, celek ve vozidle po dobu p říštích 12 hodin 
jiné události nesouladu času nevytvo ří. Tato událost nena ­
stane v případě, že přijímač GNSS po dobu 30 či více dnů 
nezjistil žádný platný signál GNSS.  
▼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  
▼M1 
— závada rozhraní ITS (v p říslušných p řípadech)  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 34  
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 komu ­
nikaci  Správná funkce  Správná funkce  
Zařízení GNSS  Správná funkce  Správná funkce  
▼M1 
Rozhraní ITS (volitelné)  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 
Pro účely tohoto odstavce  
— 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 (druhých) řidičů, 2 190 cykl ů vložení 
a vyjmutí karty a 93 440 zm ěn činnosti,  
▼M1 
— se průměrným počtem poloh za den rozumí nejmén ě 6 poloh, ve 
kterých začíná denní pracovní doba, 6 poloh, kdy sou čtová doba 
řízení dosáhne násobku t ří hodin, a 6 poloh, ve kterých kon čí 
denní pracovní doba, takže „365 dn ů“ obsahuje minimáln ě 6 570 
poloh,  
▼B 
— časové údaje jsou zaznamenávány s rozlišovací schopností jedné 
minuty, pokud není stanoveno jinak,  
— stav po čitadla ujetých kilometr ů se zaznamenává s rozlišovací 
schopností jednoho kilometru,  
— údaje o rychlosti jsou zaznamenávány s rozlišovací schopností 
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, s p říslušnou p řes­
ností GNSS a dobou zjišt ění. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 35  
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 komu ­
nikaci 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 impli ­
citně 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í.  
94) Identifika ční údaje o celku ve vozidle jsou zaznamenány 
a uloženy jednou provždy výrobcem celku ve vozidle, 
s výjimkou údaj ů vztahujících se k programovému vybavení 
a čísla schválení, které se m ůže měnit v případě aktualizace 
programového vybavení, a schopnosti používat karty tacho ­
grafu první generace.  
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. 
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 párování 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
 02016R0799 — CS — 26.02.2020 — 002.001 — 36  
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í.  
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 párování 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).  
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 kryptogra ­
fický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 platnosti 
v podobě uložené na kart ě, 
— generaci karty,  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 37  
— 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.  
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ÁV­
KA/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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 38  
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: 
— číslo karty (druhého) řidiče a členský stát, který vydal 
kartu,  
— 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 ů. 
▼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ídají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 kalendá ř­
ních dnů. 
115) Jestliže je kapacita datové pam ěti vyčerpána, musí nové údaje 
nahradit nejstarší údaje.  
3.12.7  Podrobné údaje o rychlosti  
▼M1 
116) Záznamové za řízení musí zaznamenávat a uchovávat ve své 
datové pam ěti okamžitou rychlost vozidla a odpovídající 
datum a čas v každé sekund ě po dobu nejmén ě posledních 
24 hodin, kdy bylo vozidlo v pohybu.  
▼B 
3.12.8  Údaje o událostech  
Pro účely tohoto bodu musí být čas zaznamenáván s p řesností jedné 
sekundy.  
117) Záznamové za řízení musí zaznamenávat a uchovávat ve své 
datové pam ěti tyto údaje o každé zjišt ěné události podle 
následujících pravidel ukládání:  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 39  
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  
Nesprávné uzav ř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 
— VRN, členský stát registrace a gene ­
race VU  
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 — 26.02.2020 — 002.001 — 40  
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 — 26.02.2020 — 002.001 — 41  
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  
▼B 
(1) Záznamové za řízení musí také zaznamenat a uchovat ve 
své datové pam ěti: 
— datum a čas poslední KONTROLY P ŘEKROČENÍ 
POVOLENÉ RYCHLOSTI,  
— datum a čas prvního p řekročení povolené rychlosti 
následujícího po této KONTROLE P ŘEKROČENÍ 
POVOLENÉ RYCHLOSTI,  
— počet událostí, p ři kterých došlo k p řekročení povo­
lené rychlosti od poslední KONTROLY P ŘEKRO­ 
ČENÍ POVOLENÉ RYCHLOSTI.  
(2) Tyto údaje mohou být zaznamenávány pouze p ři 
opětovném připojení elektrického napájení, časové údaje 
mohou být udávány s p řesností jedné minuty.  
3.12.9  Údaje o závadách  
Pro účely tohoto bodu musí být čas zaznamenáván s p řesností jedné 
sekundy.  
118) Záznamové za řízení se musí pokusit zaznamenat a uložit tato 
data pro každou zjišt ěnou závadu do své datové pam ěti podle 
následujících pravidel o ukládání dat:  
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  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 42  
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 kali­
brací:  
— 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 rychlost 
vozidla, po čitadlo ujetých kilometr ů (stará a nová hodno ­
ta), datum a čas (stará a nová hodnota),  
— typy a identifikátory všech použitých plomb.  
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 vozid ­
le), 
— poslední spárování s celkem ve vozidle (datum, čas, číslo 
schválení celku ve vozidle, výrobní číslo celku ve vozid ­
le). 
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 vozid ­
le), 
— poslední spárování s celkem ve vozidle (datum, čas, číslo 
schválení celku ve vozidle, výrobní číslo celku ve vozid ­
le). 
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 
provedeným v kalibra čním režimu mimo rámec pravidelné 
kalibrace (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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 43  
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 gene ­
raci 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),  
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 kali ­
bračním režimu:  
— datum a čas stahování dat,  
— číslo karty podniku nebo karty dílny, členský stát vydáva ­
jí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 — 26.02.2020 — 002.001 — 44  
— typ karty tachografu,  
— verzi karty tachografu.  
133) Záznamové za řízení musí být schopno uchovávat minimáln ě 
88 takových záznam ů. 
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,  
— výpočtu nepřetržité doby řízení řidiče, souhrnné doby 
přestávek a souhrnné doby řízení v předchozím a probíha ­
jícím týdnu,  
— 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í gene ­
race, 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.  
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 uchová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 plat ­
ných kartách řidiče, kartách dílny, kartách podniku a/nebo 
kontrolních kartách 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 kartách jsou specifikovány v kapitole 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.  
140) Všechny události, které nejsou definovány pro záznamové 
zařízení první generace, se na karty řidiče a karty dílny 
neukládají.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 45  
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 nahrazení nejstarších 
uložených údaj ů posledními údaji.  
142) V p řípadě chybného zápisu se záznamové za řízení maximá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.  
143) Před uvolněním karty řidiče 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 ( card session data )“. 
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 aplikace 
„TACHO_G2“ podle specifikace v kapitole 4 a dodatku 2.  
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 vztahu ­
jícími se k dob ě, kdy byla karta vložena, a k držiteli karty. 
Údaje uložené na t ěchto kartách jsou specifikovány v kapi ­
tole 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.  
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 nahrazení nejstarších 
uložených údaj ů posledními údaji.  
149) V p řípadě chybného zápisu se záznamové za řízení maximá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“.  
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á).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 46  
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í.  
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í piktogram ů. 
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 nepo ­
hybuje.  
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 + časo­
vé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ýka ­
jící se řidiče a musí umožnit uživateli zobrazit informaci 
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 47  
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 infor ­
mace o sou časné činnosti řidiče). 
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, 
— obsah kteréhokoli ze šesti výtisk ů v témže formátu, jaký 
mají samotné výtisky,  
— 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, 
— souhrnnou dobu řízení řidiče v předchozím a probíhajícím 
týdnu,  
— souhrnnou dobu jízdy druhého řidiče v předchozím 
a probíhajícím týdnu,  
volitelně: 
— současné trvání činnosti druhého řidiče (od doby, kdy 
byla navolena),  
— souhrnnou dobu řízení řidiče v probíhajícím týdnu,  
— souhrnnou dobu řízení druhého řidiče v probíhající denní 
pracovní dob ě, 
— souhrnnou dobu řízení řidiče v probíhající denní pracovní 
době. 
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. 
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,  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 48  
— výtisk událostí a závad z celku ve vozidle,  
— výtisk technických údaj ů, 
— výtisk p řekročení povolené rychlosti.  
— historie údaj ů karty tachografu pro daný celek ve vozidle 
(viz kapitola 3.12.16).  
Podrobný popis formátu a obsahu t ěchto výtisk ů je uveden 
v dodatku 4.  
Dodatečné údaje mohou být p řidány na konci t ěchto výtisk ů. 
Ze záznamového za řízení mohou být po řízeny i další výtisky, 
pokud jsou jasn ě odlišitelné od d říve popsaných sedmi 
výtisků. 
170) „Denní výtisk činnosti řidiče z karty“ a „výtisk událostí 
a závad z karty“ musí být k dispozici pouze, pokud je 
v záznamovém za řízení vložena karta řidiče nebo karta dílny. 
Záznamové za řízení musí aktualizovat uložená data na 
příslušné kart ě před započetím tisku.  
171) Aby se vytiskl záznam „denní výtisk činnosti řidiče z karty“ 
nebo „výtisk událostí a závad z karty“, musí záznamové 
zařízení:  
— buď automaticky vybrat kartu řidiče nebo kartu dílny, 
pokud je vložena pouze jedna z nich,  
— nebo nabídnout p říkaz k volb ě zdrojové karty nebo zvolit 
kartu vloženou v otvoru pro vložení karty řidiče, pokud 
jsou v záznamovém za řízení vloženy tyto dv ě karty.  
172) Tiskárna musí být schopna vytisknout 24 znak ů na řádku.  
173) Minimální velikost znak ů musí být 2,1 mm na výšku 
a 1,5 mm na ší řku. 
174) Tiskárna musí podporovat znaky uvedené v dodatku 1 kapi ­
tole 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í. 
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 49  
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áznamové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í.  
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áh­
nout ú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 ě. 
193) Krom ě toho jako p řídavná funkce mohou být údaje staho ­
vány v jakémkoli provozním režimu jiným zp ůsobem pro 
podnik, který se ov ěří tímto kanálem. V tomto p řípadě se 
při stahování využijí p řístupová práva podniku pro stahování 
údajů. 
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 50  
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é komunikace 
podle specifikace v dodatku 14.  
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žených 
kalibračních záznam ů, 
— registra ční značku vozidla,  
— rychlost zaznamenanou tachografem.  
3.20 Výstupní údaje pro p řídavná externí za řízení 
▼M1 
200) Záznamové za řízení může být rovn ěž vybaveno standardními 
rozhraními, která umož ňují, aby údaje zaznamenané nebo 
vytvořené tachografem používalo externí za řízení v provozním 
nebo kalibra čními režimu.  
V dodatku 13 je specifikováno a standardizováno volitelné 
rozhraní ITS. Mohou být používána i další podobná rozhraní 
celku ve vozidle, pokud zcela odpovídají požadavk ům 
dodatku 13 z hlediska minimálního vý čtu údajů, zabezpečení 
a souhlasu řidiče. 
Souhlas řidiče se nevztahuje na data p řenášená ze záznamo ­
vého zařízení do sít ě vozidla. Jsou-li osobní údaje p řenesené 
do sítě vozidla dále zpracovávány mimo sí ť vozidla, výrobce 
vozidla odpovídá za to, že proces zpracování osobních údaj ů 
je v souladu s na řízením (EU) 2016/679 („obecné na řízení 
o ochraně osobních údaj ů“). 
Souhlas řidiče se nevztahuje ani na data tachografu stahovaná 
do vzdáleného podniku (požadavek 193), jelikož tento proces 
je monitorován p řístupovým právem ke kart ě podniku.  
Pro údaje ITS zprost ředkované tímto rozhraním platí tyto 
požadavky:  
— tyto údaje jsou souborem vybraných stávajících údaj ů ze 
slovníku dat tachografu (dodatek 1),  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 51  
— dílčí soubor t ěchto vybraných údaj ů je označen jako 
„osobní údaje“,  
— dílčí soubor „osobní údaje“ je k dispozici pouze v p řípadě, 
že je vydán ov ěřitelný souhlas řidiče s tím, že jeho osobní 
údaje mohou opustit sí ť vozidla,  
— 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, 
— soubor a díl čí soubor údaj ů bude předáván pomocí 
bezdrátového protokolu Bluetooth v prostoru kabiny 
řidiče s obnovovací frekvencí 1 minuty,  
— spárování vn ějšího zařízení s rozhraním ITS bude chrá ­
něno vyhrazeným a náhodným kódem PIN obsahujícím 
minimálně 4 číslice, zaznamenaným a dostupným pomocí 
zobrazovací jednotky každého celku ve vozidle,  
— přítomnost rozhraní ITS nesmí za žádných okolností 
narušovat nebo ovliv ňovat správnou funkci a bezpe čnost 
celku ve vozidle.  
Další údaje mohou být také k dispozici krom ě tohoto souboru 
vybraných stávajících údaj ů považovaných za minimální 
výčet, nelze-li je považovat za osobní údaje.  
Záznamové za řízení musí být schopno informovat o stavu 
souhlasu řidiče ostatní platformy v síti vozidla.  
Je-li zapnuto zapalování vozidla, musí být uvedené údaje 
neustále vysílány.  
▼B 
201) Sériové rozhraní podle specifikace v p říloze 1B 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 ů. V případě přenášení 
osobních údaj ů je však stále nezbytný souhlas řidiče. 
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),  
— 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, ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 52  
— aktualizaci typ ů a identifikátor ů všech použitých plomb,  
— aktualizaci nebo potvrzení dalších parametr ů známých 
záznamovému za řízení: identifikaci vozidla, w, l, rozm ěr 
pneumatik a v p říslušných p řípadech nastavení omezo ­
vače rychlosti.  
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á mini­
málně v: 
— aktualizaci montážních údaj ů snímače pohybu ukládaný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.  
205) Párování vn ějšího zařízení GNSS s celkem ve vozidle 
spočívá 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.  
Po párování následuje ov ěření polohových informací GNSS.  
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. Kali ­
brační funkce musí být schopna vložit nezbytné údaje 
i pomocí jiných prost ředků. 
3.22 Silni ční kalibra ční kontrola  
207) Funkce silni ční kalibrační kontroly musí umožnit čtení výrob­
ního čísla snímače pohybu (p řípadně zabudovaného v adap ­
té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 ECUAdjustmentSession 
podle specifikace v dodatku 8, části 7 Řízení zkušebních 
impulsů – Řídicí funkční celek vstup/výstup.  
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 53  
211) Nastavení času vnitřních hodin celku ve vozidle se provádí 
automaticky každých 12 hodin. Pokud tato zm ěna nastavení 
není možná, protože signál GNSS není k dispozici, provede 
se nastavení času, jakmile má celek ve vozidle podle stavu 
zapalování vozidla p řístup k platnému času poskytovanému 
přijímačem GNSS. Časový odkaz pro automatické nastavení 
času vnitřních hodin celku ve vozidle se odvozuje od p řijí­
mače GNSS.  
▼B 
212) Funkce nastavení času musí rovn ěž umožnit aktivované 
nastavení aktuálního času v kalibra čním režimu.  
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ólo­
vá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í vyhovovat 
mezinárodnímu p ředpisu EHK OSN R10 a musí být chrá ­
něno proti elektrostatickým výboj ům a přechodový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 stabili ­
tou, mechanickou pevností a stabilními elektrickými i magne ­
tický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 specifi ­
kacím vztahujícím se k ergonomii konstrukce.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 54  
223) Zařízení musí být chrán ěno proti náhodnému poškození.  
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 zobrazovalo 
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 zobrazovalo 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. 
▼B 
4 KONSTRUK ČNÍ A FUNK ČNÍ POŽADAVKY NA KARTY 
TACHOGRAFU  
4.1 Viditelné údaje  
Přední strana musí obsahovat:  
227) slova „Karta řidiče“ nebo „Kontrolní karta“ nebo „Karta 
dílny“ nebo „Karta podniku“ vytišt ěná velkými písmeny 
v úředním jazyce nebo jazycích členského státu vydávajícího 
kartu, podle typu karty;  
228) jméno členského státu vydávajícího kartu (volitelné);  
229) rozlišovací zna čku členského státu vydávajícího kartu, která 
je tištěna inverzn ě v modrém obdélníku a je obklopena 12 
žlutými hv ězdami. Rozlišovací zna čky jsou tyto: 
B 
BG 
CZ 
CY Belgie 
Bulharsko 
Česká republika 
Kypr  LV 
L 
LT 
M Lotyšsko 
Lucembursko 
Litva 
Malta  
DK Dánsko  NL  Nizozemsko  
D 
EST Německo 
Estonsko  A 
PL Rakousko 
Polsko  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 55  
GR Řecko  P 
RO 
SK 
SLO  Portugalsko 
Rumunsko 
Slovensko 
Slovinsko  
E Špan ělsko FIN  Finsko  
F 
HR 
H Francie 
Chorvatsko 
Maďarsko  S Švédsko  
IRL Irsko  UK  Spojené království  
I Itálie  
230) zvláštní údaje k vydaným kartám číslované takto:  
Karta řidiče Kontrolní karta  Karta podniku nebo dílny  
1. příjmení řidiče název kontrolního orgánu  název podniku nebo dílny  
2. jméno(a) řidiče p říjmení kontrolora 
(v příslušných p řípadech)  příjmení držitele karty 
(v příslušných p řípadech)  
3. datum narození řidiče jméno(a) kontrolora 
(v příslušných p řípadech)  jméno (jména) držitele karty 
(v příslušných p řípadech)  
4.a datum po čátku platnosti karty  
4.b datum konce platnosti karty  
4.c orgán, který kartu vydal (m ůže být vytišt ěno na druhé stran ě) 
4.d číslo odlišné od čísla uvedeného v záhlaví 5, pro administrativní ú čely (volitelné)  
5. a číslo řidičského průkazu 
(k datu vydání karty řidiče) — —  
5. b číslo karty  
6. fotografie řidiče fotografie kontrolora (voli ­
telné)  fotografie montéra (volitelné)  
7. podpis držitele (volitelné)  
8. obvyklé místo pobytu nebo 
poštovní adresa držitele 
(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 — 26.02.2020 — 002.001 — 56  
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 
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 — 26.02.2020 — 002.001 — 57  
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 characteris ­
tics, (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žitost­
ný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 envi ­
ronmentálními a elektrickými specifikacemi.  
244) V pr ůběhu používání musí karty tachografu vyhovovat poža ­
davkům nařízení EHK R10, vztahujícím se k elektromagne ­
tické kompatibilit ě, a musí být ochrán ěny proti elektrosta ­
tickým výboj ům. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 58  
4.5 Ukládání údaj ů 
Pro účely tohoto odstavce  
— časové údaje jsou zaznamenávány s rozlišením jedné minuty, 
pokud není stanoveno jinak,  
— stav po čitadla ujetých kilometr ů se zaznamenává s rozlišením 
jednoho kilometru,  
— údaje o rychlosti jsou zaznamenávány s rozlišením 1 km/h,  
— polohy (zem ěpisné šířky a délky) jsou zaznamenávány ve stup ­
ních a minutách s rozlišením 1/10 minuty.  
Funkce karty tachografu, p říkazy a logické struktury, spln ění poža­
davků na ukládání údaj ů jsou popsány v dodatku 2.  
Není-li stanoveno jinak, je ukládání údaj ů na kartách tachografu 
organizováno tak, aby nové údaje nahrazovaly nejstarší uložené 
údaje, je-li vy čerpána velikost pam ěti vyhrazené pro p říslušné 
záznamy.  
245) Tento odstavec stanovuje minimální kapacitu pro ukládání 
dat v různých aplika čních souborech. Karty tachografu 
musí být schopny informovat záznamové za řízení o skute čné 
kapacitě těchto datových soubor ů. 
246) Jakékoliv další údaje vztahující se k jiným aplikacím, 
případně přítomným na kart ě, které sm ějí být ukládány na 
karty tachografu, musí být ukládány v souladu se sm ěrnicí 
95/46/ES a se sm ěrnicí 2002/58/ES a v souladu s článkem 7 
nařízení (EU) č. 165/2014.  
247) Každý hlavní soubor (MF) každé karty tachografu musí obsa ­
hovat 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řítomen 
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.  
Ú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,  
— 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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 59  
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 speci ­
fikovaný 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.  
4.5.3.1.2 Klí če a certifikáty  
254) Karta řidiče musí být schopna uchovat řadu kryptografický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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 60  
4.5.3.1.5 Stahování z karty  
257) Karta řidiče musí být schopna uchovat následující údaje týka ­
jí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),  
— 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),  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 61  
— ú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álos ­
tem).  
4.5.3.1.8 Údaje o závadách  
Pro účely tohoto bodu musí být čas zaznamenáván s p řesností jedné 
sekundy.  
263) Karta řidiče musí být schopna uchovat údaje vztahující se 
k následujícím závadám zjišt ěným záznamovým za řízením 
době, kdy byla karta vložena:  
▼M1 
— chyba karty (v p řípadě, že tato karta je p ředmětem 
chyby),  
▼B 
— chyba záznamového za řízení.  
264) Karta řidiče musí být schopna uchovat následující údaje vzta ­
hují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ý kalendá ř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. 
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).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 62  
268) Údaje uvedené v požadavcích 261, 264 a 266 musí být ucho ­
vány způsobem umož ňujícím vyhledání činností v chronolo ­
gickém po řadí i v případě překrývajících se časový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ý kalendá ř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 obsa ­
huje 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:  
— datum a čas otevření relace (tzn. vložení karty) s rozlišo ­
vací 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 vzta ­
hují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)),  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 63  
— 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 vzta ­
hují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 ů. 
4.5.3.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.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.  
4.5.3.2.2 Klí če a certifikáty  
279) Karta řidiče musí být schopna uchovat řadu kryptografický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ýka ­
jí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).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 64  
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),  
— 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 komuni ­
kaci,  
— 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 — 26.02.2020 — 002.001 — 65  
— údaje o vozidlu musí odpovídat vozidlu, ve kterém došlo 
k nesprávnému uzav ření poslední relace.  
287) Karta řidiče musí být schopna uchovat údaje vztahující se 
k posledním šesti událostem každého typu (tzn. 66 událos ­
tem).  
4.5.3.2.8 Údaje o závadách  
Pro účely tohoto bodu musí být čas zaznamenáván s p řesností jedné 
sekundy.  
288) Karta řidiče musí být schopna uchovat údaje vztahující se 
k následujícím závadám zjišt ěným záznamovým za řízením 
době, kdy byla karta vložena:  
▼M1 
— chyba karty (v p řípadě, že tato karta je p ředmětem 
chyby),  
▼B 
— chyba záznamového za řízení.  
289) Karta řidiče musí být schopna uchovat následující údaje vzta ­
hují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.  
290) 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.2.9 Údaje o činnostech řidiče 
291) Karta řidiče musí být schopna uchovat pro každý kalendá ř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),  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 66  
— čas změny. 
292) 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).  
293) Údaje uvedené v požadavcích 286, 289 a 291 musí být ucho ­
vány způsobem umož ňujícím vyhledání v chronologické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ý kalendá ř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 obsa ­
huje 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.  
295) Karta řidiče musí být schopna uchovat 84 takových záznam ů. 
4.5.3.2.11 Místa a polohy, kde za číná a/nebo kon čí denní pracovní doba  
296) Karta řidiče musí být schopna uchovat následující údaje 
vložené řidičem a vztahující se k míst ům, kde začíná a/nebo 
končí denní pracovní doba:  
— datum a čas vložení údaj ů (nebo datum a čas vztahující se 
k vložení údaj ů, pokud jsou zadávány řidičem ručně), 
— 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. 
297) Pam ěť karty řidiče musí být schopna uchovat nejmén ě 84 
párů takových záznam ů. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 67  
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šo ­
vací 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 vzta ­
hují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 staho ­
vá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 vzta ­
hují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.  
302) Karta řidiče musí být schopna uchovat 56 takových záznam ů. 
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 vzta ­
hují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.  
304) Karta řidiče musí být schopna uchovat 84 takových záznam ů. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 68  
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 vzta ­
hují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 ů. 
306) Karta řidiče musí být schopna uchovat nejmén ě 252 takových 
záznamů. 
▼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 kryptografický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.  
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. ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 69  
4.5.4.1.6 Údaje o kalibraci a nastavování času 
313) Karta dílny musí být schopna uchovat záznamy o kalibrací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ásledu ­
jí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 rychlost 
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 posled ­
ních záznam ů o závadách každého typu (tzn. 12 závad).  
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 tako ­
vých záznam ů. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 70  
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.  
4.5.4.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.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.  
4.5.4.2.2 Klí če a certifikáty  
331) Karta dílny musí být schopna uchovat řadu kryptografický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. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 71  
4.5.4.2.6 Údaje o kalibraci a nastavování času 
336) Karta dílny musí být schopna uchovat záznamy o kalibrací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ásledu ­
jí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 rychlost 
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é komu ­
nikace a v p říslušných p řípadech výrobní číslo vnějšího 
zařízení GNSS),  
— 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).  
338) Karta dílny musí být schopna uchovat nejmén ě 88 takových 
záznamů. 
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 posled ­
ní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. 
344) 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.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. 
346) Karta dílny musí být schopna uchovat nejmén ě čtyři takové 
záznamy.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 72  
4.5.4.2.10 Údaje o za čátku a/nebo konci denní pracovní doby  
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 nejmén ě tři páry tako ­
vých záznam ů. 
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. 
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 vzta ­
hují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.  
352) Karta dílny musí být schopna uchovat nejmén ě čtyři takové 
záznamy.  
▼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 vzta ­
hují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 ů. 
354) Karta dílny musí být schopna uchovat nejmén ě 18 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. 
356) Karta dílny musí být schopna uchovat nejmén ě dva takové 
záznamy.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 73  
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í identi ­
fikač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 kryptografický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í identi ­
fikač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í identi ­
fikač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,  
— 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. 
362) Kontrolní karta musí být schopna uchovat nejmén ě 230 tako­
vých záznam ů. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 74  
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í identi ­
fikační údaje aplikace:  
— identifikaci aplikace tachografu,  
— identifikaci typu karty tachografu.  
4.5.5.2.2 Klí če a certifikáty  
364) Kontrolní karta musí být schopna uchovat řadu kryptografic ­
ký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í identi ­
fikač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í identi ­
fikač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,  
— 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 tako­
vých záznam ů. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 75  
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í identi ­
fikač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 kryptografic ­
ký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í identi ­
fikač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í identi ­
fikační údaje držitele karty:  
— název podniku,  
— adresu podniku.  
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 staho ­
vá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 tako­
vých záznam ů. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 76  
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í identi ­
fikační údaje aplikace:  
— identifikaci aplikace tachografu,  
— identifikaci typu karty tachografu.  
4.5.6.2.2 Klí če a certifikáty  
376) Karta dílny musí být schopna uchovat řadu kryptografický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í identi ­
fikač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í identi ­
fikační údaje držitele karty:  
— název podniku,  
— adresu podniku.  
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 staho ­
vá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 tako­
vých záznam ů. 
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 77  
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.  
383) Záznamové za řízení nesmí p řed aktivací zaznamenávat ani 
ukládat údaje uvedené v bodech 3.12.3, 3.12.9 a 3.12.12 až 
3.12.15 včetně. 
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.  
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í. 
392) Po instalaci musí následovat kalibrace. První kalibrace 
nemusí nutn ě zahrnovat zadání registra ční značky vozidla 
VRN, 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 pomocí 
karty dílny 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). (  1 ) Případné 
pozměnění nebo potvrzení této položky musí být možné jen 
za použití karty dílny.  
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.  ▼B 
( 1 ) Úř. věst. č. L 102, 11.4.2006, s. 1.
 02016R0799 — CS — 26.02.2020 — 002.001 — 78  
5.2 Montážní štítek  
395) 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 na rám dve ří vozidla na stran ě řidiče 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.  
▼M1 
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,  
— výrobní číslo případného za řízení pro dálkovou komuni ­
kaci,  
— 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.  
▼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.  ▼B 
( 1 ) Úř. věst. č. L 21, 24.1.2009, s. 3
 02016R0799 — CS — 26.02.2020 — 002.001 — 79  
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 provedení 
neidentifikovatelných zm ěn nebo neidentifikovatelnou 
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 rychlosti 
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 namonto ­
vá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.  
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í.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 80  
404) Schválené dílny a výrobci vozidel musí v rámci na řízení 
(EU) č. 165/2014 používat pouze plomby certifikované 
podle normy EN 16882:2016 od výrobc ů uvedených ve 
výše zmín ěné databázi.  
▼B 
405) Výrobci plomb a jejich prodejci musí zachovat plnou sledo ­
vatelnost záznam ů prodaných plomb pro použití v rámci na ří­
zení (EU) č. 165/2014 a musí být p řipraveni je podle pot řeby 
předložit příslušným vnitrostátním orgán ům. 
406) Jedine čná identifika ční čísla plomb musí být viditelná na 
montážním štítku.  
6 KONTROLY, INSPEKCE A OPRAVY  
Požadavky týkající se okolností, za kterých mohou být odstran ěny 
plomby uvád ěné v čl. 22 odst. 5 na řízení (EU) č. 165/2014, jsou 
definovány v kapitole 5.3 této p řílohy.  
6.1 Schválení montér ů, dílen a výrobc ů vozidel  
Členské státy schvalují a pravideln ě kontrolují subjekty a vydávají 
jim osvědčení k provád ění: 
— montáží,  
— kontrol,  
— prohlídek,  
— oprav.  
Karty dílny se vydávají pouze montér ům a/nebo dílnám oprávn ěným 
k aktivaci a/nebo kalibraci záznamových za řízení v souladu s touto 
přílohou, a krom ě řádně odůvodněných případů: 
— které nejsou oprávn ěny k použití karty podniku  
— a jejichž další profesní činnosti nep ředstavují potenciální st řet 
zájmů z hlediska celkového zabezpe čení systému podle poža ­
davků v dodatku 10.  
▼M1 
6.2 Kontrola nových nebo opravených sou částí 
407) U každého jednotlivého za řízení, ať již nového nebo oprave ­
ného, musí být zkontrolována správná funk čnost a přesnost 
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 
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 ustano ­
vení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á instalace musí být 
zaplombována v souladu s bodem 5.3 a zkalibrována.  
▼B 
6.4 Periodické prohlídky  
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 kol, odchylce referen čního času UTC o více než 
20 minut, p ři změně VRN, ale minimáln ě jednou v pr ůběhu 
dvou let (24 m ěsíců) od poslední prohlídky.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 81  
410) Tyto prohlídky musí obsahovat následující kontroly zajiš ťu­
jí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 komunikace 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 pneuma ­
tik, 
— 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žadavek 401).  
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 řipojené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, odpo ­
vídá informacím obsaženým v datové pam ěti záznamo ­
vé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žený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 manipu ­
lač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:  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 82  
— 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 vnitrostát ­
ní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í.  
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 zaznamena ­
ný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ý exemplá ř 
s výjimkou indexu náhrady, který se zvedne o jednotku (v 
pořadí 0, …, 9, A, …, Z).  
420) Karta tachografu, která se vydává jako náhrada již existující 
karty, musí mít shodné datum ukon čení použitelnosti jako 
nahrazovaný exemplá ř. 
421) Karta tachografu vydávaná p ři obnovení již existující karty 
musí mít stejné číslo karty jako obnovovaný exemplá ř 
s výjimkou indexu náhrady, který je nastaven na hodnotu 
„0“, a indexu obnovy, který je zvýšen o jednotku (v po řadí 
0, …, 9, A, …, Z).  
422) Vým ěna existující karty tachografu p ři úpravách administra ­
tivních údaj ů, musí prob ěhnout podle pravidel platných pro 
obnovu karty, pokud proces probíhá ve stejném členské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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 83  
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.  
8 SCHVÁLENÍ TYPU ZÁZNAMOVÉHO ZA ŘÍZENÍ A KARET 
TACHOGRAFU  
8.1 Všeobecn ě 
▼M1 
Pro účely této kapitoly se „záznamovým za řízením“ rozumí „zázna ­
mové zařízení nebo jeho sou části“. Schválení typu není vyžadováno 
pro kabel(y) spojující sníma č pohybu s celkem ve vozidle, vn ější 
zařízení GNSS s celkem ve vozidle nebo vn ější zařízení pro 
dálkovou komunikaci s celkem ve vozidle. Papír používaný zázna ­
movým za řízením je považován za sou část záznamového za řízení.  
Kterýkoli výrobce m ůže požádat o schválení typu sou části nebo 
součástí záznamového za řízení s jakoukoli jinou sou částí či 
součástmi záznamového za řízení, pokud každá sou část splňuje poža­
davky této p řílohy. Případně mohou výrobci rovn ěž požádat o schvá ­
lení typu záznamového za řízení.  
Jak je popsáno v definici uvedené v čl. 2 bodě 10 tohoto na řízení, 
existují různé varianty montáže sou částí celků ve vozidle. Bez 
ohledu na montáž sou částí celku ve vozidle nejsou externí anténa 
a (případně) anténní rozdvojka p řipojené k p řijímači GNSS nebo 
k zařízení pro dálkovou komunikaci sou částí schválení typu celku 
ve vozidle.  
Výrobci, kte ří obdrželi schválení typu pro záznamové za řízení, však 
musí vést ve řejně dostupný seznam antén a rozdvojek kompatibil ­
ních s každým typov ě schváleným celkem ve vozidle, vn ějším 
zařízením GNSS a vn ějším zařízením pro dálkovou komunikaci.  
▼B 
425) Záznamové za řízení musí být p ředloženo ke schválení typu 
úplné se všemi integrovanými p řídavnými za řízeními.  
426) Postup schvalování typu záznamového za řízení a karet tacho ­
grafu musí zahrnovat zkoušky bezpe čnostních opat ření, 
funkční zkoušky a zkoušky vzájemné interoperability. Pozi ­
tivní 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 nevy ­
dají 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
 02016R0799 — CS — 26.02.2020 — 002.001 — 84  
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 ě. 
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. Aktualizace 
programového vybavení záznamového za řízení může 
vylučovat zavedení nových sad písma, není-li to technicky 
proveditelné.  
8.2 Osv ědčení o bezpe čnosti  
431) Vydání osv ědčení o bezpe čnosti se provede v souladu s usta ­
noveními dodatku 10 této p řílohy. Sou části záznamové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 tacho ­
grafu.  
432) Za výjime čných okolností, kdy orgány provád ějící certifikaci 
zabezpečení odmítnou vystavit osv ědčení pro nové za řízení 
z důvodu zastaralosti zabezpe čovacích mechanism ů, 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í obno ­
vení 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 materiály 
a dokumentaci, kterou tento orgán považuje za nezbytnou.  
435) Výrobci musí poskytovat p říslušné vzorky výrobk ů ucházejí­
cích se o schválení typu a související dokumentaci požado ­
vanou 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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 85  
437) Osv ědčení o funkčnosti vydá orgán p říslušný pro schvalování 
typu. Toto osv ědčení musí obsahovat, krom ě jména příjemce 
osvědčení a identifikace modelu, podrobný seznam provede ­
ných zkoušek a dosažených výsledk ů. 
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 ostatní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 interope ­
rability 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.  
443) U záznamového za řízení nebo karty tachografu, ke kterým 
nebyla poskytnuta osv ědčení o zabezpe čení a funk čnosti, 
zkušebna neprovádí žádné zkoušky interoperability, krom ě 
případů výskytu výjime čných okolností popsaných v poža ­
davku 432.  
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áznamo ­
vý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 gene ­
race záznamového za řízení nebo karet tachografu, které se 
dosud používají.  
447) Osv ědčení o interoperabilit ě musí zkušebna doru čit výrobci 
teprve tehdy, až jsou úsp ěšně absolvovány všechny požado ­
vané zkoušky interoperability.  
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 interoperability.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 86  
Zkušebna identifikuje p říčinu problému týkajícího se intero ­
perability s pomocí p říslušného výrobce a pokusí se mu 
pomoci nalézt technické řešení. V p řípadě, že výrobce již 
upravil sv ůj výrobek, musí zajistit od p říslušných orgán ů 
potvrzení o pokra čující platnosti osv ědčení o bezpe čnosti 
a funkčnosti.  
449) Osv ědčení o interoperabilit ě je platné šest m ěsíců. Na konci 
tohoto období je odebráno, pokud výrobce neobdržel odpo ­
vídající osv ědčení o schválení typu. Osv ědčení doručí 
výrobce orgánu p říslušnému pro schvalování typu členského 
státu, který vydal osv ědčení o funk čnosti.  
450) Jakýkoli prvek, který by mohl zp ůsobit závadu interoperabi ­
lity, 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žado­
vaná 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 ostatní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 tacho ­
grafu:  
— pro které byla zaregistrována žádost o zkoušky interope ­
rability,  
— 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ázna ­
movým za řízením a kartami tachografu (kartami řidiče, dílny, 
kontrolní a podniku) druhé generace z hlediska interoperabi ­
lity je jakékoliv vydané osv ědčení o interoperabilit ě (včetně 
těch prvních) týkající se žádostí registrovaných v tomto 
období považováno za do časné. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 87  
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 interopera ­
bilitou přetrvávat, musí odpov ědná zkušebna ve spolupráci 
s dotčenými výrobci a orgány p říslušnými pro schvalová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 interoperabi ­
lity, která za řízení a karty obdrží definitivní osv ědčení o inte­
roperabilitě, 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 — 26.02.2020 — 002.001 — 88  
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  
2.12 CardCertificate  
2.13 CardChipIdentification  
2.14 CardConsecutiveIndex  
2.15 CardControlActivityDataRecord  
2.16 CardCurrentUse  
2.17 CardDriverActivity  
2.18 CardDrivingLicenceInformation  
2.19 CardEventData  
2.20 CardEventRecord  
2.21 CardFaultData  
2.22 CardFaultRecord  
2.23 CardIccIdentification  
2.24 CardIdentification  
2.25 CardMACertificate  
2.26 CardNumber  
2.27 CardPlaceDailyWorkPeriod  
2.28 CardPrivateKey  
2.29 CardPublicKey  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 89  
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  
2.49 CompanyCardHolderIdentification  
2.50 ControlCardApplicationIdentification  
2.51 ControlCardControlActivityData  
2.52 ControlCardHolderIdentification  
2.53 ControlType  
2.54 CurrentDateTime  
2.55 CurrentDateTimeRecordArray  
2.56 DailyPresenceCounter  
2.57 Datef  
2.58 DateOfDayDownloaded  
2.59 DateOfDayDownloadedRecordArray  
2.60 Distance  
2.61 DriverCardApplicationIdentification  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 90  
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  
2.74 FullCardNumberAndGeneration  
2.75 Generation  
2.76 GeoCoordinates  
2.77 GNSSAccuracy  
▼M1 
2.78 GNSSAccumulatedDriving  
2.79 GNSSAccumulatedDrivingRecord  
▼B 
2.80 GNSSPlaceRecord  
2.81 HighResOdometer  
2.82 HighResTripDistance  
2.83 HolderName  
2.84 InternalGNSSReceiver  
2.85 K-ConstantOfRecordingEquipment  
2.86 KeyIdentifier  
2.87 KMWCKey  
2.88 Language  
2.89 LastCardDownload  
2.90 LinkCertificate  
2.91 L-TyreCircumference  
2.92 MAC  
2.93 ManualInputFlag  
2.94 ManufacturerCode  
2.95 ManufacturerSpecificEventFaultData  
2.96 MemberStateCertificate  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 91  
2.97 MemberStateCertificateRecordArray  
2.98 MemberStatePublicKey  
2.99 Name  
2.100 NationAlpha  
2.101 NationNumeric  
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  
▼B 
2.112 NoOfSpecificConditionRecords  
2.113 OdometerShort  
2.114 OdometerValueMidnight  
2.115 OdometerValueMidnightRecordArray  
2.116 OverspeedNumber  
2.117 PlaceRecord  
2.118 PreviousVehicleInfo  
2.119 PublicKey  
2.120 RecordType  
2.121 RegionAlpha  
2.122 RegionNumeric  
2.123 RemoteCommunicationModuleSerialNumber  
2.124 RSAKeyModulus  
2.125 RSAKeyPrivateExponent  
2.126 RSAKeyPublicExponent  
2.127 RtmData  
2.128 SealDataCard  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 92  
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  
2.152 SpecificConditionRecord  
2.153 SpecificConditions  
2.154 SpecificConditionType  
2.155 Speed  
2.156 SpeedAuthorised  
2.157 SpeedAverage  
2.158 SpeedMax  
2.159 TachographPayload  
▼M1 
2.160 Vyhrazeno pro budoucí použití  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 93  
2.161 TDesSessionKey  
2.162 TimeReal  
2.163 TyreSize  
2.164 VehicleIdentificationNumber  
2.165 VehicleIdentificationNumberRecordArray  
2.166 VehicleRegistrationIdentification  
2.167 VehicleRegistrationNumber  
2.168 VehicleRegistrationNumberRecordArray  
2.169 VuAbility  
2.170 VuActivityDailyData  
2.171 VuActivityDailyRecordArray  
2.172 VuApprovalNumber  
2.173 VuCalibrationData  
2.174 VuCalibrationRecord  
2.175 VuCalibrationRecordArray  
2.176 VuCardIWData  
2.177 VuCardIWRecord  
2.178 VuCardIWRecordArray  
2.179 VuCardRecord  
2.180 VuCardRecordArray  
2.181 VuCertificate  
2.182 VuCertificateRecordArray  
2.183 VuCompanyLocksData  
2.184 VuCompanyLocksRecord  
2.185 VuCompanyLocksRecordArray  
2.186 VuControlActivityData  
2.187 VuControlActivityRecord  
2.188 VuControlActivityRecordArray  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 94  
2.189 VuDataBlockCounter  
2.190 VuDetailedSpeedBlock  
2.191 VuDetailedSpeedBlockRecordArray  
2.192 VuDetailedSpeedData  
2.193 VuDownloadablePeriod  
2.194 VuDownloadablePeriodRecordArray  
2.195 VuDownloadActivityData  
2.196 VuDownloadActivityDataRecordArray  
2.197 VuEventData  
2.198 VuEventRecord  
2.199 VuEventRecordArray  
2.200 VuFaultData  
2.201 VuFaultRecord  
2.202 VuFaultRecordArray  
▼M1 
2.203 VuGNSSADRecord  
2.204 VuGNSSADRecordArray  
▼B 
2.205 VuIdentification  
2.206 VuIdentificationRecordArray  
2.207 VuITSConsentRecord  
2.208 VuITSConsentRecordArray  
2.209 VuManufacturerAddress  
2.210 VuManufacturerName  
2.211 VuManufacturingDate  
2.212 VuOverSpeedingControlData  
2.213 VuOverSpeedingControlDataRecordArray  
2.214 VuOverSpeedingEventData  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 95  
2.215 VuOverSpeedingEventRecord  
2.216 VuOverSpeedingEventRecordArray  
2.217 VuPartNumber  
2.218 VuPlaceDailyWorkPeriodData  
2.219 VuPlaceDailyWorkPeriodRecord  
2.220 VuPlaceDailyWorkPeriodRecordArray  
2.221 VuPrivateKey  
2.222 VuPublicKey  
2.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  
2.235 WorkshopCardCalibrationData  
2.236 WorkshopCardCalibrationRecord  
2.237 WorkshopCardHolderIdentification  
2.238 WorkshopCardPIN  
2.239 W-VehicleCharacteristicConstant  
2.240 VuPowerSupplyInterruptionRecord  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 96  
2.241 VuPowerSupplyInterruptionRecordArray  
2.242 VuSensorExternalGNSSCoupledRecordArray  
2.243 VuSensorPairedRecordArray  
3. DEFINICE HODNOT A ROZSAH Ů VELIKOSTÍ  
4. ZNAKOVÉ SADY  
5. KÓDOVÁNÍ  
6. IDENTIFIKÁTORY OBJEKT Ů A IDENTIFIKÁTORY APLIKACÍ  
6.1 Identifikátory objekt ů 
6.2 Identifikátory aplikací  
1. ÚVOD  
Tento dodatek specifikuje formáty dat, datové prvky a datové struktury 
pro použití v záznamovém za řízení a v kartách tachografu.  
1.1 Přístup k definování datových typ ů 
Tento dodatek používá k definování datových typ ů notaci ASN.1 
(Abstract Syntax Notation One ). Díky tomu lze jednoduchá a strukturo ­
vaná data definovat, aniž by se p ředpokládala n ějaká konkrétní 
přenosová syntaxe (pravidla kódování), která bude závislá na aplikaci 
a systémovém prost ředí. 
Konvence pojmenování typ ů v ASN.1 jsou v souladu s ISO/IEC 8824-1. 
To znamená, že:  
— tam, kde je to možné, je význam datového typu nazna čen zvolenými 
názvy,  
— tam, kde je datový typ složen z jiných datových typ ů, je názvem 
datového typu nadále jednoduchá posloupnost abecedních znak ů 
začínající velkým písmenem, nicmén ě velká písmena jsou použita 
uvnitř názvu ke sd ělení příslušného významu,  
— názvy datových typ ů obvykle souvisejí s názvy datových typ ů, od 
kterých jsou odvozeny, za řízením, ve kterém jsou data uložena, 
a funkcí vztahující se k dat ům. 
Jestliže je typ ASN.1 již definován v rámci jiného standardu a jestliže 
má význam pro použití v záznamovém za řízení, je tento typ ASN.1 
definován v tomto dodatku.  
K umožnění několika typů kódovacích pravidel jsou n ěkteré typy ASN.1 
v tomto dodatku omezeny pomocí identifikátor ů rozsahu hodnot. Iden ­
tifikátory rozsahu hodnot jsou definovány v bod ě 3 a dodatku 2.  
1.2 Odkazy  
V tomto dodatku jsou použity tyto normy:  
ISO 639 Code for the representation of names of languages. 
First Edition: 1988.  
ISO 3166 Codes for the representation of names of countries 
and their subdivisions – Part 1: Country codes, 2013  
ISO 3779  Road vehicles  – Vehicle identification number (VIN)  – 
Content and structure . 2009  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 97  
ISO/IEC 7816-5 Identification cards – Integrated circuit cards – Part 5: 
Registration of application providers.  
Second edition: 2004.  
ISO/IEC 7816-6 Identification cards – Integrated circuit cards – Part 6: 
Interindustry data elements for interchange, 2004 + 
Technical Corrigendum 1: 2006  
ISO/IEC 8824-1 Information technology – Abstract Syntax Notation 
One (ASN.1): Specification of basic notation. 2008 
+ Technical Corrigendum 1: 2012 and Technical 
Corrigendum 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 Ů 
U všech následujících datových typ ů spočívá standardní hodnota pro 
„neznámý“ nebo „bezp ředmětný“ obsah v napln ění daného datového 
prvku bajty „FF“.  
Není-li stanoveno jinak, všechny datové typy se použijí pro aplikace 1. 
a 2. generace.  
▼M1 
U typů dat karty používaných pro aplikace 1. a 2. generace je v tomto 
dodatku uvedena velikost pro aplikaci 2. generace. Má se za to, že 
velikost pro aplikaci 1. generace již čtečka zná. Čísla požadavk ů 
v příloze IC týkajících se t ěchto typů dat zahrnují aplikace 1. i 2. gene ­
race. 
▼B 
2.1 ActivityChangeInfo  
Tento datový typ umož ňuje kódovat uvnit ř dvoubajtového slova status 
otvoru pro kartu v 00:00 a/nebo status řidiče v 00:00 a/nebo zm ěny 
činnosti a/nebo zm ěny statusu řízení a/nebo zm ěny statusu karty, a to 
pro řidiče nebo druhého řidiče. Tento datový typ se vztahuje k poža ­
davkům 105, 266, 291, 320, 321, 343 a 344 p řílohy 1C.
  
Přiřazení hodnoty – oktetové uspo řádání:  ‘scpaattttttttttt’B (16 bit ů) 
Pro záznamy v pam ěti údajů (nebo status otvoru pro kartu):  
‘s’B otvor pro kartu:  
‘0’B: ŘIDIČ, 
‘1’B: DRUHÝ ŘIDIČ, ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 98  
‘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á)  
‘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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 99  
Poznámka pro p řípad „vyjmutí karty“:  
Je-li karta vyjmuta:  
— ‘s’ je relevantní a ozna čuje otvor pro kartu, ze kterého je karta 
vyjmuta,  
— ‘c’ musí být nastaveno na 0,  
— ‘p’ musí být nastaveno na 1,  
— ‘aa’ musí kódovat aktuální činnost, která je v tu dobu navolena.  
Jako výsledek ru čního zadání mohou být bity ‘c’ a ‘aa’ slova (uložené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.  
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 100  
2.5 AES192Key  
2. generace:  
Klíč AES192.
  
length  udává délku klí če AES192 v oktetech.  
aes192Key  je klíč AES s délkou 192 bit ů. 
Přiřazení hodnoty:  
Délka musí mít hodnotu 24.  
2.6 AES256Key  
2. generace:  
Klíč AES256.
  
length  udává délku klí če AES256 v oktetech.  
aes256Key  je klíč AES s délkou 256 bit ů. 
Přiřazení hodnoty:  
Délka musí mít hodnotu 32.  
2.7 BCDString  
BCDString se použije pro vyjád ření dekadických čísel binárním kódem 
(BCD). Tento datový typ se použije k vyjád ření jedné dekadické číslice 
skupinou 4 bit ů (poloviční oktet). BCDString je založen na typu „Cha ­
racterStringType“ dle ISO/IEC 8824-1.
  
BCDString používá notaci „hstring“. Vn ější levá hexadecimální číslice 
představuje nejvýznamn ější 4 bity prvního oktetu. K získání více oktet ů 
se musí podle pot řeby vložit od pozice levé vn ější 4bitové skupiny 
v prvním oktetu nulové 4bitové skupiny.  
Přípustné číslice jsou: 0, 1, .. 9.  
2.8 CalibrationPurpose  
Kód k objasn ění, proč byla zaznamenána sada kalibra čních parametr ů. 
Tento datový typ se vztahuje k požadavk ům 097 a 098 p řílohy 1B a k 
požadavku 119 p řílohy 1C.
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 101  
Přiřazení hodnoty:  
1. generace:  
‘00’H vyhrazená hodnota,  
‘01’H aktivace: záznam známých kalibra čních parametr ů 
v okamžiku aktivace celku ve vozidle,  
‘02’H první montáž: první kalibrace celku ve vozidle po 
jeho aktivaci,  
‘03’H montáž: první kalibrace celku ve vozidle v aktuálním 
vozidle,  
‘04’H pravidelná kontrola.  
2. generace:  
Kromě hodnot 1. generace se používají tyto hodnoty:  
‘05’H zadání registra ční značky vozidla (VRN) podnikem,  
‘06’H nastavení času bez kalibrace,  
‘07’H až ‘7F’H vyhrazeno pro budoucí použití,  
‘80’H až ‘FF’H specifické pro výrobce.  
2.9 CardActivityDailyRecord  
Informace uložené na kart ě a vztahující se k činnostem řidiče po určitý 
kalendářní den. Tento datový typ se vztahuje k požadavk ům 266, 291, 
320 a 343 p řílohy 1C.
  
activityPreviousRecordLength  je celková délka p ředchozího denního 
záznamu v bajtech. Maximální hodnota je dána délkou řetězce OCTET 
STRING obsahujícího tyto záznamy (viz CardActivityLengthRange, 
dodatek 2 bod 4). Jestliže tento záznam je nejstarším denním záznamem, 
musí být hodnota activityPreviousRecordLength nastavena na 0.  
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 102  
activityDailyPresenceCounter  je stav po čitadla dnů přítomnosti karty 
v tento den.  
activityDayDistance  je celková vzdálenost ujetá toho dne.  
activityChangeInfo  je sada dat ActivityChangeInfo toho dne pro řidiče. 
Může obsahovat maximáln ě 1 440 hodnot (jedna zm ěna činnosti za 
minutu). Tato sada vždy obsahuje údaj activityChangeInfo udávající 
status řidiče v 00:00.  
2.10 CardActivityLengthRange  
Počet bajtů na kartě řidiče nebo kart ě dílny, které jsou dostupné k uklá ­
dání záznam ů o činnosti řidiče.
 
Přiřazení hodnoty : viz dodatek 2.  
2.11 CardApprovalNumber  
Číslo schválení typu karty.
  
Přiřazení hodnoty:  
Číslo schválení musí být uvedeno tak, jak bylo zve řejněno na přísluš­
ných webových stránkách Evropské komise, tj. nap ř. včetně případných 
spojovníků. Číslo schválení musí být zarovnáno doleva.  
2.12 CardCertificate  
1. generace:  
Certifikát ve řejného klíče karty.
  
2.13 CardChipIdentification  
Informace uložené na kart ě související s identifikací integrovaného 
obvodu karty (IC) (požadavek 249 p řílohy 1C). Číslo icSerialNumber 
společně s číslem icManufacturingReferences jednozna čně identifikují 
čip karty. Samotné číslo icSerialNumber není jednozna čnou identifikací 
čipu karty.
  
icSerialNumber  je výrobní číslo integrovaného obvodu.  
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’  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 103  
2.15 CardControlActivityDataRecord  
Informace uložené na kart ě řidiče nebo kart ě dílny týkající se poslední 
kontroly, které byl řidič podroben (požadavky 274, 299, 327 a 350 
přílohy 1C).
  
controlType  je typ kontroly.  
controlTime  je datum a čas kontroly.  
controlCardNumber  je FullCardNumber kontrolora, který provedl 
kontrolu.  
controlVehicleRegistration  je registra ční značka (VRN) a členský stát 
registrace vozidla, ve kterém byla kontrola provedena.  
controlDownloadPeriodBegin  a controlDownloadPeriodEnd  je 
stažené období v p řípadě stahování dat.  
2.16 CardCurrentUse  
Informace o aktuálním použití karty (požadavky 273, 298, 326 a 349 
přílohy 1C).
  
sessionOpenTime  je čas, kdy je karta vložena pro aktuální použití. 
Tento prvek se nastavuje na nulu p ři vyjmutí karty.  
sessionOpenVehicle  je identifikace aktuáln ě používaného vozidla, nasta ­
vuje se při vložení karty. Tento prvek se nastavuje na nulu p ři vyjmutí 
karty.  
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. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 104  
activityPointerNewestRecord  je specifikace za čátku paměťového místa 
(počet bajtů od začátku řetězce) nejnov ějšího denního záznamu v řetězci 
activityDailyRecords. Maximální hodnota je dána délkou řetězce. 
activityDailyRecords  je prostor ur čený k ukládání dat o činnosti řidiče 
(datová struktura: CardActivityDailyRecord) pro každý kalendá řní den, 
kdy byla karta použita.  
Přiřazení hodnoty : tento oktetový řetězec je cyklicky pln ěn záznamy 
CardActivityDailyRecord. P ři prvním použití se za číná ukládat od 
prvního bajtu řetězce. Každý nový záznam se p řipojuje za konec p řed­
chozího. Když je řetězec plný, ukládání pokra čuje prvním bajtem řetězce 
nehledě na přerušení, které vznikne uvnit ř datového prvku. P ředtím, než 
jsou do řetězce uložena nová data o činnosti (zv ětšení aktuálního 
záznamu activityDailyRecord nebo uložení nového záznamu activityDa ­
ilyRecord), která nahrazují starší data o činnosti, musí být aktualizován 
ukazatel activityPointerOldestDayRecord, aby odrážel nové umíst ění 
nejstaršího úplného denního záznamu, a délka activityPreviousRecord ­
Length tohoto (nového) nejstaršího úplného denního záznamu musí být 
nastavena na 0.  
2.18 CardDrivingLicenceInformation  
Informace uložené na kart ě řidiče týkající se údaj ů o řidičském průkazu 
držitele karty (požadavky 259 a 284 p řílohy 1C).
  
drivingLicenceIssuingAuthority  je orgán odpov ědný za vydání řidič­
ského průkazu.  
drivingLicenceIssuingNation  je stát orgánu, který vydal řidičský 
průkaz. 
drivingLicenceNumber  je číslo řidičského průkazu.  
▼M1 
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:  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 105  
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.  
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.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 106  
faultBeginTime  je datum a čas začátku závady.  
faultEndTime  je datum a čas konce závady.  
faultVehicleRegistration  je registra ční značka (VRN) a členský stát 
registrace vozidla, ve kterém závada nastala.  
2.23 CardIccIdentification  
Informace uložené na kart ě týkající se identifikace karty s integrovaným 
obvodem (požadavek 248 p řílohy 1C).
  
clockStop  je režim Clockstop dle dodatku 2.  
cardExtendedSerialNumber  je jedinečné výrobní číslo karty s integro ­
vaným obvodem, dále specifikované datovým typem ExtendedSerial ­
Number.  
cardApprovalNumber  je číslo schválení typu karty.  
cardPersonaliserID  je identifikátor personalizace karty kódovaný jako 
ManufacturerCode.  
embedderIcAssemblerId  uvádí informace o subjektu, který vkládá/se ­
stavuje integrovaný obvod.  
icIdentifier  je identifikátor integrovaného obvodu karty a jeho výrobce 
dle ISO/IEC 7816-6.  
2.24 CardIdentification  
Informace uložené na kart ě týkající se identifikace karty (požadavky 
255, 280, 310, 333, 359, 365, 371 a 377 p řílohy 1C).
  
cardIssuingMemberState  je kód členského státu vydávajícího kartu.  
cardNumber  je číslo karty.  
cardIssuingAuthorityName  je název orgánu vydávajícího kartu.  
cardIssueDate  je datum vydání karty sou časnému držiteli.  
cardValidityBegin  je datum prvního dne platnosti karty.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 107  
cardExpiryDate  je datum konce platnosti karty.  
2.25 CardMACertificate  
2. generace:  
Certifikát ve řejného klíče karty pro vzájemné ov ěření pravosti s celkem 
ve vozidle. Struktura tohoto certifikátu je specifikována v dodatku 11.
  
2.26 CardNumber  
Číslo karty dle definice g).
  
driverIdentification  je jednozna čná identifikace řidiče v členském stát ě. 
ownerIdentification  je jednozna čná identifikace podniku, dílny nebo 
kontrolního orgánu v členském stát ě. 
cardConsecutiveIndex  je pořadový index karty.  
cardReplacementIndex  je index náhrady karty.  
cardRenewalIndex  je index obnovy karty.  
První posloupnost ve výb ěru je vhodná ke kódování čísla karty řidiče, 
druhá posloupnost ve výb ěru je vhodná ke kódování čísla karty dílny, 
kontrolní karty a karty podniku.  
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 
zadaných míst.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 108  
2.28 CardPrivateKey  
1. generace:  
Soukromý klí č karty.
  
2.29 CardPublicKey  
Veřejný klíč karty.
  
▼M1 
2.30 CardRenewalIndex  
Index obnovy karty (definice i)).
  
Přiřazení hodnoty : (viz kapitolu 7 této p řílohy).  
„0“ První vydání.  
Posloupnost: „0, …, 9, A, …, Z“  
▼B 
2.31 CardReplacementIndex  
Index náhrady karty (definice j)).
  
Přiřazení hodnoty : (viz kapitolu VII této p řílohy).  
‘0’ Původní karta.  
Posloupnost: ‘0, …, 9, A, …, Z’  
2.32 CardSignCertificate  
2. generace:  
Certifikát ve řejného klíče karty pro podpis. Struktura tohoto certifikátu je 
specifikována v dodatku 11.
  
2.33 CardSlotNumber  
Kód pro rozlišení mezi dv ěma otvory pro kartu v celku ve vozidle.
  
Přiřazení hodnoty : není blíže specifikováno.  
2.34 CardSlotsStatus  
Kód udávající typ karet vložených do dvou otvor ů pro kartu v celku ve 
vozidle.
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 109  
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.  
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  
‘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 tuto verzi aplikací 1. generace  
‘00’H pro tuto verzi aplikací 2. generace  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 110  
2.37 CardVehicleRecord  
Informace uložené na kart ě řidiče nebo kart ě dílny týkající se doby 
používání vozidla b ěhem kalendá řního dne (požadavky 269, 294, 322 
a 345 přílohy 1C).  
1. generace:
  
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 registrace 
vozidla.  
vuDataBlockCounter  je hodnota VuDataBlockCounter p ři poslední 
extrakci doby používání vozidla.  
2. generace:
  
Kromě prvků 1. generace se použije tento datový prvek:  
VehicleIdentificationNumber  je identifika ční číslo vozidla týkající se 
vozidla jako celku.  
2.38 CardVehiclesUsed  
Informace uložené na kart ě řidiče nebo kart ě dílny týkající vozidel použi ­
tých držitelem karty (požadavky 270, 295, 323 a 346 p řílohy 1C).
  
vehiclePointerNewestRecord  je index naposledy aktualizovaného 
záznamu o vozidle.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 111  
Přiřazení hodnoty : Číslo odpovídající čítači záznamů o vozidlech 
začínající hodnotou „0“ pro první výskyt záznamu o vozidle ve struktu ře. 
cardVehicleRecords  je sada záznam ů obsahující informace o použitých 
vozidlech.  
2.39 CardVehicleUnitRecord  
2. generace:  
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  
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 306 a 352 p řílohy 
1C).
 
vehicleUnitPointerNewestRecord  je index naposledy aktualizovaného 
záznamu o celku ve vozidle.  
Přiřazení hodnoty : Číslo odpovídající čítači záznamů o celku ve 
vozidle, za čínající hodnotou „0“ pro první výskyt záznam ů o celku ve 
vozidle ve struktu ře. 
cardVehicleUnitRecords  je sada záznam ů obsahující informace o použi ­
tých celcích ve vozidle.  
2.41 Certificate  
Certifikát ve řejného klíče vydaný certifika ční autoritou.  
1. generace:
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 112  
Přiřazení hodnoty : digitální podpis s částečnou obnovou CertificateCon ­
tent podle dodatku 11 „Spole čné bezpečnostní mechanismy“: podpis (128 
bajtů) || zbytek ve řejného klíče (58 bajtů) || odkaz na certifika ční autoritu 
(8 bajtů). 
2. generace:
  
Přiřazení hodnoty: viz dodatek 11  
2.42 CertificateContent  
1. generace:  
(Nešifrovaný) obsah certifikátu ve řejného klíče podle dodatku 11 „Spo ­
lečné bezpečnostní mechanismy“.
  
certificateProfileIdentifier  je verze odpovídajícího certifikátu.  
Přiřazení hodnoty : ‘01h’ pro tuto verzi.  
certificationAuthorityReference  identifikuje certifika ční autoritu 
vydávající certifikát. Sou časně odkazuje na ve řejný klíč této certifika ční 
autority.  
certificateHolderAuthorisation  identifikuje práva držitele certifikátu.  
certificateEndOfValidity  je datum, kdy kon čí administrativní platnost 
certifikátu.  
certificateHolderReference  identifikuje držitele certifikátu. Zárove ň 
odkazuje na jeho ve řejný klíč. 
publicKey  je veřejný klíč, který je certifikován tímto certifikátem.  
2.43 CertificateHolderAuthorisation  
Identifikace práv držitele certifikátu.
  
1. generace:  
tachographApplicationID  je identifikátor aplikace pro aplikaci tacho ­
grafu.  
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, 
jestliže se jedná o certifikát členského státu.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 113  
2. generace:  
tachographApplicationID  označuje 6 nejvýznamn ějších bajtů identifiká­
toru aplikace (AID) karty tachografu 2. generace. AID pro aplikaci karty 
tachografu je uveden v kapitole 6.2.  
Přiřazení hodnoty:  ‘FF 53 4D 52 44 54’.  
equipmentType  je identifikace typu za řízení, jak je specifikováno pro 2. 
generaci, pro n ěž je certifikát ur čen. 
Přiřazení hodnoty : ve shodě s datovým typem EquipmentType.  
2.44 CertificateRequestID  
Jednoznačná identifikace žádosti o certifikát. M ůže být použita také jako 
identifikátor ve řejného klíče celku ve vozidle, jestliže výrobní číslo celku 
ve vozidle, pro který je klí č určen, není známo v dob ě vystavení certi ­
fiká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ší řené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 — 26.02.2020 — 002.001 — 114  
keySerialNumber  je sériové číslo k odlišení r ůzných klíčů certifikační 
autority v p řípadě, že se klíče změní. 
additionalInfo  je dvoubajtové pole pro dodate čné kódování (specifické 
pro certifika ční autoritu).  
caIdentifier  je identifikátor k odlišení identifikátoru klí če certifika ční 
autority od jiných identifikátor ů klíčů. 
Přiřazení hodnoty : ‘01h’.  
2.46 CompanyActivityData  
Informace uložené na kart ě podniku týkající se činností vykonaných 
s kartou (požadavky 373 a 379 p řílohy 1C).
  
companyPointerNewestRecord  je index naposledy aktualizovaného 
záznamu companyActivityRecord.  
Přiřazení hodnoty : Číslo odpovídající čítači záznamů o činnosti 
podniku, za čínající ‘0’ pro první výskyt záznamu o činnosti podniku 
ve struktuře. 
companyActivityRecords  je sada všech záznam ů o činnosti podniku.  
companyActivityRecord  je posloupnost informací vztahujících se 
k jedné činnosti podniku.  
companyActivityType  je typ činnosti podniku.  
companyActivityTime  je datum a čas činnosti podniku.  
cardNumberInformation  je číslo karty a členský stát vydávající kartu, 
z které jsou stažena data (v p říslušných p řípadech).  
vehicleRegistrationInformation  je registra ční značka (VRN) a členský 
stát registrace vozidla, jehož data jsou stažena, zablokována nebo odblo ­
kována.  
downloadPeriodBegin  a downloadPeriodEnd  je případné období, za 
něž byla z celku ve vozidle stažena data.  
2.47 CompanyActivityType  
Kód udávající činnost vykonávanou podnikem s použitím jeho karty 
podniku.
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 115  
2.48 CompanyCardApplicationIdentification  
Informace uložené na kart ě podniku týkající se identifikace aplikace 
karty (požadavky 369 a 375 p řílohy 1C).
  
typeOfTachographCardId  udává implementovaný typ karty.  
cardStructureVersion  udává verzi struktury implementované v kart ě. 
noOfCompanyActivityRecords  je počet záznam ů o činnosti podniku, 
které lze na kartu uložit.  
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.  
companyAddress  je adresa podniku – držitele.  
cardHolderPreferredLanguage  je upřednostňovaný jazyk držitele karty.  
2.50 ControlCardApplicationIdentification  
Informace uložené na kontrolní kart ě týkající se identifikace aplikace 
karty (požadavky 357 a 363 p řílohy 1C).
  
typeOfTachographCardId  udává implementovaný typ karty.  
cardStructureVersion  udává verzi struktury implementované v kart ě. 
noOfControlActivityRecords  je počet záznam ů o kontrolní činnosti, 
které lze na kartu uložit.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 116  
2.51 ControlCardControlActivityData  
Informace uložené na kontrolní kart ě týkající se kontrolní činnosti 
vykonané s kartou (požadavky 361 a 367 p řílohy 1C).
  
controlPointerNewestRecord  je index naposledy aktualizovaného 
záznamu o kontrolní činnosti.  
Přiřazení hodnoty : Číslo odpovídající čítači záznamů o kontrolní 
činnosti., za čínající ‘0’ pro první výskyt záznamu o kontrolní činnosti 
ve struktuře. 
controlActivityRecords  je sada všech záznam ů o kontrolní činnosti.  
controlActivityRecord  je posloupnost informací vztahujících se k jedné 
kontrole.  
controlType  je typ kontroly.  
controlTime  je datum a čas kontroly.  
controlledCardNumber  je číslo kontrolované karty a členský stát, který 
ji vydal.  
controlledVehicleRegistration  je registra ční značka (VRN) a členský 
stát registrace vozidla, v kterém byla kontrola provedena.  
controlDownloadPeriodBegin  a controlDownloadPeriodEnd  je 
období, za které byla p řípadně stažena data.  
2.52 ControlCardHolderIdentification  
Informace uložené na kontrolní kart ě týkající se identifikace držitele 
karty (požadavky 360 a 366 p řílohy 1C).
  
controlBodyName  je název kontrolního orgánu držitele karty.  
controlBodyAddress  je adresa kontrolního orgánu držitele karty.  
cardHolderName  je příjmení a jméno (jména) držitele kontrolní karty.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 117  
cardHolderPreferredLanguage  je upřednostňovaný jazyk držitele karty.  
2.53 ControlType  
Kód udávající činnosti provedené b ěhem kontroly. Tento datový typ se 
vztahuje k požadavk ům 126, 274, 299, 327 a 350 p řílohy 1C.
  
1. generace:  
Přiřazení hodnoty – oktetové uspo řádání : ‘cvpdxxxx’B (8 bit ů) 
‘c’B stahování dat z karty:  
‘0’B: při této kontrolní činnosti nebyla stažena data 
z karty,  
‘1’B: při této kontrolní činnosti byla stažena data z karty  
‘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  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 118  
‘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í.  
2.54 CurrentDateTime  
Aktuální datum a čas záznamového za řízení.
  
Přiřazení hodnoty : není blíže specifikováno.  
2.55 CurrentDateTimeRecordArray  
2. generace:  
Aktuální datum a čas a metadata použitá v protokolu pro stahování.
  
recordType  označuje typ záznamu (CurrentDateTime).  Přiřazení 
hodnoty : viz RecordType  
recordSize  je velikost záznamu CurrentDateTime v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada záznam ů aktuálního data a času. 
2.56 DailyPresenceCounter  
Čítač uložený v kart ě řidiče nebo kart ě dílny, který se zvýší o jedni čku 
za každý kalendá řní den, kdy byla karta vložena v celku ve vozidle. 
Tento datový typ se vztahuje k požadavk ům 266, 299, 320 a 343 p řílohy 
1C.
 
Přiřazení hodnoty : Pořadové číslo s maximální hodnotou = 9 999, 
začínající od 0. V okamžiku prvního vydání karty se číslo nastavuje na 0.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 119  
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“.  
2.58 DateOfDayDownloaded  
2. generace:  
Datum a čas stahování.
  
Přiřazení hodnoty : není blíže specifikováno.  
2.59 DateOfDayDownloadedRecordArray  
2. generace:  
Datum a čas stahování a metadata použitá v protokolu pro stahování.
  
recordType  označuje typ záznamu (DateOfDayDownloaded).  Přiřazení 
hodnoty : viz RecordType  
recordSize  je velikost záznamu CurrentDateTime v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada záznam ů o datu a čase stahování.  
2.60 Distance  
Ujetá vzdálenost (výsledek rozdílu mezi dv ěma hodnotami po čitadla 
ujetých kilometr ů).
 
Přiřazení hodnoty : Binární číslo bez znaménka. Hodnota v km 
v provozním rozsahu 0 až 9 999 km.  
2.61 DriverCardApplicationIdentification  
Informace uložené na kart ě řidiče týkající se identifikace aplikace karty 
(požadavky 253 a 278 p řílohy 1C).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 120  
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 
2.62 DriverCardHolderIdentification  
Informace uložené na kart ě řidiče týkající se identifikace držitele karty 
(požadavky 256 a 281 p řílohy 1C).
  
cardHolderName  je příjmení a jméno (jména) držitele karty řidiče. 
cardHolderBirthDate  je datum narození držitele karty řidiče. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 121  
cardHolderPreferredLanguage  je upřednostňovaný jazyk držitele karty.  
▼M1 
2.63 Vyhrazeno pro budoucí použití  
▼B 
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 specifiková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.  
2. generace
  
Přiřazení hodnoty : dle ISO/IEC 8824-1.  
2.67 EquipmentType  
Kód k rozlišení r ůzných typů zařízení pro aplikaci tachografu.
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 122  
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. gene ­
race se hodnoty (1), (2) a (6) vykládají jako hodnoty ozna čující certifikát 
pro vzájemné ov ěření pravosti pro p říslušný typ za řízení. K ozna čení 
příslušného certifikátu pro vytvo ření digitálního podpisu se musí použít 
hodnoty (17), (18) nebo (19).  
▼B 
2.68 EuropeanPublicKey  
1. generace:  
Evropský ve řejný klíč.
 
2.69 EventFaultRecordPurpose  
Kód vysvětlující, pro č byla událost nebo závada zaznamenána.
  
Přiřazení hodnoty:  ▼B
02016R0799 — CS — 26.02.2020 — 002.001 — 123 
jedna z 10 nejnov ějších (nebo posledních) událostí nebo závad 
nejdelší událost v jednom z posledních 10 dn ů výskytu 
jedna z 5 nejdelších událostí za posledních 365 dn ů 
poslední událost v jednom z posledních 10 dn ů výskytu 
nejzávažnější událost v jednom z posledních 10 dn ů výskytu 
jedna z 5 nejzávažn ějších událostí za posledních 365 dn ů 
první událost nebo závada od poslední kalibrace 
aktivní/trvající událost nebo závada 
vyhrazeno pro budoucí použití 
specifické pro výrobce  
2.70 EventFaultType 
Kód blíže ur čující událost nebo závadu.
  
Přiřazení hodnoty:  
1. generace:
všeobecné události, 
žádné další podrobnosti, 
vložení neplatné karty, 
konflikt karet, 
časový přesah, 
jízda bez náležité karty, 
vložení karty b ěhem řízení, 
poslední relace karty nebyla korektn ě uzavřena, 
překročení povolené rychlosti, 
přerušení napájení, 
chyba údaj ů o pohybu vozidla, 
nesoulad údaj ů o pohybu vozidla, 
vyhrazeno pro budoucí použití,
  
události pokus ů o narušení zabezpe čení souvisejících s celkem ve vozidle, 
žádné další podrobnosti, 
chyba ověření pravosti snímač e pohybu, 
chyba ověření pravosti karty tachografu, 
neoprávněná výměna snímače pohybu, 
chyba integrity vstupních dat karty, 
chyba integrity uložených uživatelských dat, 
vnitřní chyba p řenosu dat, 
neoprávněné otevření krytu, 
poškození technického vybavení, 
vyhrazeno pro budoucí použití,
  
události pokus ů o narušení zabezpe čení souvisejících se snímač em, 
žádné další podrobnosti, 
chyba ověření pravosti, 
chyba integrity uložených dat, 
vnitřní chyba p řenosu dat, 
neoprávněné otevření krytu, 
poškození technického vybavení, 
vyhrazeno pro budoucí použití,
  
závady záznamového za řízení, 
žádné další podrobnosti, 
interní závada celku ve vozidle, 
závada tiskárny, 
závada displeje, 
závada stahování, 
závada snímač e, 
vyhrazeno pro budoucí použití,  ▼B
02016R0799 — CS — 26.02.2020 — 002.001 — 124 
závady karty, 
žádné další podrobnosti, 
vyhrazeno pro budoucí použití,
  
vyhrazeno pro budoucí použití,
  
specifické pro výrobce.  
▼M1
2. 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, 
časový nesoulad (GNSS v ůči vnitřním hodinám VU), 
chyba komunikace se za řízením pro dálkovou komunikaci, 
chybí informace o poloze z p řijímače GNSS, 
chyba komunikace s vn ějším zařízením GNSS, 
vyhrazeno pro budoucí použití,
  
události pokus ů o narušení zabezpe čení souvisejících s celkem ve vozidle, 
žádné další podrobnosti, 
chyba ověření pravosti snímač e pohybu, 
chyba ověření pravosti karty tachografu, 
neoprávněná výměna snímače pohybu, 
chyba integrity vstupních dat karty, 
chyba integrity uložených uživatelských dat, 
vnitřní chyba p řenosu dat, 
neoprávněné otevření krytu, 
poškození technického vybavení, 
detekce nedovolené manipulace s GNSS, 
chyba ověření pravosti vn ějšího zařízení GNSS, 
skončila platnost certifikátu vn ějšího zařízení GNSS, 
vyhrazeno pro budoucí použití,
  
události pokus ů o narušení zabezpe čení souvisejících se snímač em, 
žádné další podrobnosti, 
chyba ověření pravosti, 
chyba integrity uložených dat, 
vnitřní chyba p řenosu dat, 
neoprávněné otevření krytu, 
poškození technického vybavení, 
vyhrazeno pro budoucí použití,  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 125
  
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.  
2.71 ExtendedSealIdentifier  
2. generace:  
Rozšířený identifikátor plomby jednozna čně identifikuje plombu (p říloha 
IC požadavek 401).
  
manufacturerCode  je kód výrobce plomby.  
sealIdentifier  je identifikátor plomby, který je jednozna čný pro výrobce.  
▼B 
2.72 ExtendedSerialNumber  
Jednoznačná identifikace za řízení. Může také být použito jako identifi ­
kátor veřejného klíče zařízení.  
1. generace:
  
serialNumber  je výrobní číslo zařízení, jednozna čné pro výrobce, typ 
zařízení a dále uvedený m ěsíc a rok.  
monthYear  je identifikace m ěsíce a roku výroby (nebo p řiřazení výrob ­
ního čísla). ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 126  
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.  
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í  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 127  
2.76 GeoCoordinates  
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.
  
latitude  je zeměpisná délka kódovaná jako desetinásobek reprezentace 
±DDMM.M.  
longitude  je zeměpisná šířka kódovaná jako desetinásobek reprezentace 
±DDDMM.M.  
2.77 GNSSAccuracy  
2. generace:  
Přesnost údaj ů o poloze z GNSS (definice eee)). Tato p řesnost je kódo ­
vána jako celé číslo a je desetinásobkem hodnoty X.Y z v ěty GSA 
NMEA.
  
▼M1 
2.78 GNSSAccumulatedDriving  
2. generace:  
Informace uložené na kart ě řidiče nebo kart ě dílny týkající se polohy 
vozidla dle GNSS, pokud sou čtová doba řízení dosáhne násobku t ří 
hodin (příloha IC požadavky 306 a 354).
  
gnssADPointerNewestRecord  je index naposledy aktualizovaného 
záznamu o sou čtové době řízení dle GNSS.  
Přiřazení hodnoty  je číslo odpovídající čítači záznamů o součtové době 
řízení dle GNSS, za čínající hodnotou ‘0’ pro první výskyt záznamu 
o součtové době řízení dle GNSS ve struktu ře. 
gnssAccumulatedDrivingRecords  je sada záznam ů obsahujících datum 
a čas, kdy sou čtová doba řízení dosáhne násobku t ří hodin, a informace 
o poloze vozidla.  
2.79 GNSSAccumulatedDrivingRecord  
2. generace:  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 128  
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.  
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.  
▼B 
2.80 GNSSPlaceRecord  
2. generace:  
Informace týkající se polohy vozidla dle GNSS (požadavky 108, 109, 
110, 296, 305, 347 a 353 p řílohy 1C).
  
timeStamp  je datum a čas, kdy byla ur čena poloha vozidla dle GNSS.  
gnssAccuracy  je přesnost údaj ů GNSS o poloze.  
geoCoordinates  je poloha zaznamenaná pomocí GNSS.  
2.81 HighResOdometer  
Hodnota po čitadla ujetých kilometr ů vozidla: celková vzdálenost ujetá 
vozidlem b ěhem jeho provozu.
  
Přiřazení hodnoty : Binární číslo bez znaménka. Hodnota v 1/200 km 
v provozním rozsahu 0 až 21 055 406 km.  
2.82 HighResTripDistance  
Vzdálenost ujetá b ěhem cesty nebo její části.
 
Přiřazení hodnoty : Binární číslo bez znaménka. Hodnota v 1/200 km 
v provozním rozsahu 0 až 21 055 406 km.  
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 controlBody ­
Name.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 129  
holderFirstNames  jsou jméno (jména) a iniciály držitele.  
2.84 InternalGNSSReceiver  
2. generace:  
Informace, zda je p řijímač GNSS vnit řní nebo vn ější vůči celku ve 
vozidle. Hodnota „true“ znamená, že p řijímač GNSS je interní částí 
VU. Hodnota „false“ znamená, že p řijímač GNSS je vn ější.
 
2.85 K-ConstantOfRecordingEquipment  
Konstanta záznamového za řízení (definice m)).
  
Přiřazení hodnoty : impulsy na kilometr v provozním rozsahu 0 až 
64 255 impuls ů/km. 
▼M1 
2.86 KeyIdentifier  
Jednoznačný identifikátor ve řejného klí če použitý k odkazu na klí č 
a výběru klíče. Rovněž identifikuje držitele klí če.
 
První volba je vhodná k odkazu na ve řejný klíč celku ve vozidle, karty 
tachografu nebo vn ějšího zařízení GNSS.  
Druhá volba je vhodná k odkazu na ve řejný klíč celku ve vozidle (pokud 
výrobní číslo celku ve vozidle není známo v dob ě vystavení certifikátu).  
Třetí volba je vhodná k odkazu na ve řejný klíč členského státu.  
▼B 
2.87 KMWCKey  
2. generace:  
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 130  
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.  
2.90 LinkCertificate  
2. generace:  
Spojovací certifikát mezi páry klí čů evropského ko řenového certifika č­
ního úřadu.
 
2.91 L-TyreCircumference  
Účinný obvod pneumatik na kolech (definice u)).
  
Přiřazení hodnoty : Binární číslo bez znaménka, hodnota v 1/8 mm 
v provozním rozsahu 0 až 8 031 mm.  
▼M1 
2.92 MAC  
2. generace:  
Kryptografický kontrolní sou čet délky 8, 12 nebo 16 bajt ů odpovídající 
sadám šifer uvedeným v dodatku 11.
  
▼B 
2.93 ManualInputFlag  
Kód udávající, zda držitel karty ru čně zadal činnosti řidiče při vložení 
karty, či nikoliv (požadavek 081 p řílohy 1B a požadavek 102 p řílohy 
1C).
 
Přiřazení hodnoty : není blíže specifikováno.  
2.94 ManufacturerCode  
Kód identifikující výrobce typov ě schváleného za řízení.
  
Zkušebna p říslušná pro provád ění zkoušek interoperability vede a zve řej­ 
ňuje seznam kód ů výrobců na svých webových stránkách (požadavek 
454 přílohy 1C).  
Kódy ManufacturerCode se p ředběžně přidělují vývojá řům tachografo ­
vých zařízení, když si podají žádost u zkušebny p říslušné pro provád ění 
zkoušek interoperability.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 131  
2.95 ManufacturerSpecificEventFaultData  
2. generace:  
Kódy chyb specifické pro výrobce zjednodušují analýzu chyb a údržbu 
celků ve vozidle.
  
manufacturerCode  označuje výrobce celku ve vozidle.  
manufacturerSpecificErrorCode  je kód chyby specifický pro výrobce.  
2.96 MemberStateCertificate  
Certifikát ve řejného klí če členského státu vydaný Evropským certifi ­
kačním úřadem.
  
2.97 MemberStateCertificateRecordArray  
2. generace:  
Certifikát členského státu a metadata použitá v protokolu pro stahování.
  
recordType  označuje typ záznamu (MemberStateCertificate).  Přiřazení 
hodnoty : viz RecordType  
recordSize  je velikost záznamu MemberStateCertificate v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. Hodnota je nastavena 
na 1, protože certifikáty mohou mít r ůzné délky.  
records  je sada certifikát ů členských stát ů. 
2.98 MemberStatePublicKey  
1. generace:  
Veřejný klíč členského státu.
  
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 132  
2.100  NationAlpha  
Abecední ozna čení země musí být v souladu s rozlišovacími zna čkami 
používanými na vozidlech v mezinárodním provozu (Víde ňská úmluva 
OSN o silni čním provozu z roku 1968).
  
Abecední a číselné kódy zemí jsou uvedeny v seznamu vedeném na 
webových stránkách zkušebny p říslušné pro provád ění zkoušek interope ­
rability, jak je stanoveno v požadavku 440 p řílohy 1C.  
2.101  NationNumeric  
Číselné ozna čení státu.
  
Přiřazení hodnoty:  viz datový typ 2.100 (NationAlpha).  
Jakákoli úprava nebo aktualizace specifikace abecedních nebo číselných 
kódů popsaných v p ředchozím odstavci se provede pouze poté, co ur čená 
zkušebna obdrží stanovisko výrobc ů typově schválených digitálních 
a inteligentních tachografových celk ů ve vozidle.  
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.  
2. generace:
  
Přiřazení hodnoty : viz dodatek 2.  
2.103  NoOfCalibrationsSinceDownload  
Čítač udávající po čet kalibrací provedených s kartou dílny od posledního 
stahování (požadavky 317 a 340 p řílohy 1C).
  
Přiřazení hodnoty : není specifikováno.  
2.104  NoOfCardPlaceRecords  
Počet záznam ů míst, které lze uložit na kartu řidiče nebo kartu dílny.  
1. generace:
  
Přiřazení hodnoty : viz dodatek 2.  
2. generace:
  
Přiřazení hodnoty : viz dodatek 2.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 133  
2.105  NoOfCardVehicleRecords  
Počet záznam ů o použitých vozidlech, které lze uložit na kartu řidiče 
nebo kartu dílny.
  
Přiřazení hodnoty : viz dodatek 2.  
2.106  NoOfCardVehicleUnitRecords  
2. generace:  
Počet záznamů o použitých celcích ve vozidle, které lze uložit na kartu 
řidiče nebo kartu dílny.
  
Přiřazení hodnoty : viz dodatek 2.  
2.107  NoOfCompanyActivityRecords  
Počet záznam ů o činnosti podniku, které lze uložit na kartu podniku.
  
Přiřazení hodnoty : viz dodatek 2.  
2.108  NoOfControlActivityRecords  
Počet záznamů o kontrolní činnosti, které lze uložit na kontrolní kartu.
  
Přiřazení hodnoty : viz dodatek 2.  
2.109  NoOfEventsPerType  
Počet událostí od každého typu události, které lze na kartu uložit.
  
Přiřazení hodnoty:  viz dodatek 2.  
2.110  NoOfFaultsPerType  
Počet závad od každého typu závady, které lze na kartu uložit.
  
Přiřazení hodnoty:  viz dodatek 2.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 134  
2.111  NoOfGNSSADRecords  
2. generace:  
Počet záznam ů o součtové době řízení dle GNSS, které lze na kartu 
uložit.
  
Přiřazení hodnoty:  viz dodatek 2.  
▼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.  
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 provozním rozsahu 0 až 9 999 999 km.  
2.114  OdometerValueMidnight  
Hodnota po čitadla ujetých kilometr ů vozidla k p ůlnoci daného dne (poža ­
davek 090 p řílohy 1B a požadavek 113 p řílohy 1C).
  
Přiřazení hodnoty : není blíže specifikováno.  
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  
recordSize  je velikost záznamu OdometerValueMidnight v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada záznam ů OdometerValueMidnight.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 135  
2.116  OverspeedNumber  
Počet událostí p řekročení povolené rychlosti od poslední kontroly p řekro­ 
čení povolené rychlosti.
  
Přiřazení hodnoty:  0 znamená, že nedošlo k žádnému p řekročení povo­
lené rychlosti od poslední kontroly p řekročení povolené rychlosti, 1 
znamená, že se vyskytla jedna událost p řekročení povolené rychlosti 
od poslední kontroly p řekročení povolené rychlosti, … 255 znamená, 
že se vyskytlo 255 nebo více událostí p řekročení povolené rychlosti od 
poslední kontroly p řekročení povolené rychlosti.  
2.117  PlaceRecord  
Informace týkající se místa, kde za číná nebo kon čí denní pracovní doba 
(požadavky 108, 271, 296, 324 a 347 p řílohy 1C).  
1. generace:
  
entryTime  je datum a čas zadání.  
entryTypeDailyWorkPeriod  je typ zadání.  
dailyWorkPeriodCountry  je zadaná zem ě. 
dailyWorkPeriodRegion  je zadaný region.  
vehicleOdometerValue  je hodnota po čitadla ujetých kilometr ů 
k okamžiku zadání místa.  
2. generace:
  
Kromě 1. generace se používá tato komponenta:  
entryGNSSPlaceRecord  je zaznamenané místo a čas. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 136  
2.118  PreviousVehicleInfo  
Informace související s p ředchozím vozidlem, které řidič použil, p ři 
vložení karty do celku ve vozidle (požadavek 081 p řílohy 1B a požadavek 
102 přílohy 1C).  
1. generace:
  
vehicleRegistrationIdentification  je registra ční značka vozidla a členský 
stát registrace vozidla.  
cardWithdrawalTime  je datum a čas vyjmutí karty.  
2. generace:
  
Kromě prvků 1. generace se použije tento datový prvek:  
vuGeneration  identifikuje generaci celku ve vozidle.  
2.119  PublicKey  
1. generace:  
Veřejný klíč RSA.
  
rsaKeyModulus  je modul páru klí čů. 
rsaKeyPublicExponent  je veřejný exponent páru klí čů. 
2.120  RecordType  
2. generace:  
Odkaz na typ záznamu. Tento datový typ se používá v záznamu Recor ­
dArrays.
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 137  
Přiřazení hodnoty:
  
► (1) M1 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, 
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 — 26.02.2020 — 002.001 — 138  
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 — 26.02.2020 — 002.001 — 139  
2.126  RSAKeyPublicExponent  
1. generace:  
Veřejný exponent páru klí čů RSA.
  
Přiřazení hodnoty : není specifikováno.  
2.127  RtmData  
2. generace:  
Definice tohoto datového typu viz dodatek 14.  
2.128  SealDataCard  
2. generace:  
Tento datový typ ukládá informace o plombách, které jsou p řipojeny 
k různým částem vozidla, a je ur čen k uložení na kart ě. Tento datový 
typ se vztahuje k požadavku 337 p řílohy 1C.
  
noOfSealRecords  je počet záznamů v sadě sealRecords.  
sealRecords  je sada záznam ů o plombách.  
2.129  SealDataVu  
2. generace:  
Tento datový typ ukládá informace o plombách, které jsou p řipojeny 
k různým částem vozidla, a je ur čen k uložení v celku ve vozidle.
  
sealRecords  je sada záznam ů o plombách. Je-li dostupných plomb mén ě 
než 5, musí být hodnota EquipmentType ve všech nepoužitých zázna ­
mech sealRecords nastavena na 16, tj. nepoužité.  
2.130  SealRecord  
2. generace:  
Tento datový typ ukládá informace o plomb ě, která je p řipojena 
k součásti. Tento datový typ se vztahuje k požadavku 337 p řílohy 1C.
  
equipmentType  označuje typ zařízení, ke kterému je plomba p řipojena.  
extendedSealIdentifier  je identifikátor plomby p řipojené k za řízení.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 140  
2.131  SensorApprovalNumber  
Číslo schválení typu sníma če. 
1. generace:
  
Přiřazení hodnoty : není specifikováno.  
2. generace:
  
Přiřazení hodnoty:  
Číslo schválení musí být uvedeno tak, jak bylo zve řejněno na příslušných 
webových stránkách Evropské komise, tj. nap ř. včetně případných 
spojovníků. Číslo schválení musí být zarovnáno doleva.  
2.132  SensorExternalGNSSApprovalNumber  
2. generace:  
Číslo schválení typu vn ějšího zařízení GNSS.
  
Přiřazení hodnoty:  
Číslo schválení musí být uvedeno tak, jak bylo zve řejněno na příslušných 
webových stránkách Evropské komise, tj. nap ř. včetně případných 
spojovníků. Číslo schválení musí být zarovnáno doleva.  
2.133  SensorExternalGNSSCoupledRecord  
2. generace:  
Informace uložené v celku ve vozidle týkající se identifikace vn ějšího 
zařízení GNSS provázaného s celkem ve vozidle (požadavek 100 p řílohy 
1C).
 
sensorSerialNumber  je výrobní číslo vnějšího zařízení GNSS prováza ­
ného s celkem ve vozidle.  
sensorApprovalNumber  je číslo schválení tohoto vn ějšího zařízení 
GNSS.  
sensorCouplingDate  je datum vazby tohoto vn ějšího zařízení GNSS 
s celkem ve vozidle.  
2.134  SensorExternalGNSSIdentification  
2. generace:  
Informace týkající se identifikace vn ějšího zařízení GNSS (požadavek 98 
přílohy 1C).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 141
  
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áza ­
né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 — 26.02.2020 — 002.001 — 142  
2.136  SensorExternalGNSSOSIdentifier  
2. generace:  
Identifikátor opera čního systému vn ějšího zařízení GNSS.
  
Přiřazení hodnoty : specifické pro výrobce.  
2.137  SensorExternalGNSSSCIdentifier  
2. generace:  
Tento typ se používá nap ř. pro identifikaci kryptografického modulu 
vnějšího zařízení GNSS.  
Identifikátor bezpe čnostní komponenty vn ějšího zařízení GNSS.
  
Přiřazení hodnoty : specifické pro výrobce komponenty.  
2.138  SensorGNSSCouplingDate  
2. generace:  
Datum vazby vn ějšího zařízení GNSS s celkem ve vozidle.
  
Přiřazení hodnoty : není specifikováno.  
2.139  SensorGNSSSerialNumber  
2. generace:  
Tento typ se používá k uložení výrobního čísla přijímače GNSS, a ť už je 
uvnitř nebo vně celku ve vozidle.  
Výrobní číslo přijímače GNSS.
  
2.140  SensorIdentification  
Informace uložená ve sníma či pohybu týkající se identifikace sníma če 
pohybu (požadavek 077 p řílohy 1B a požadavek 95 p řílohy 1C).
  
sensorSerialNumber  je rozšířené výrobní číslo sníma če pohybu (obsa ­
huje katalogové číslo dílu a kód výrobce).  
sensorApprovalNumber  je číslo schválení sníma če pohybu.  
sensorSCIdentifier  je identifikátor bezpe čnostní komponenty sníma če 
pohybu.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 143  
sensorOSIdentifier  je identifikátor opera čního systému sníma če pohybu.  
2.141  SensorInstallation  
Informace uložené ve sníma či pohybu týkající se montáže sníma če 
pohybu (požadavek 099 p řílohy 1B a požadavek 122 p řílohy 1C).
  
sensorPairingDateFirst  je datum prvního párování sníma če pohybu 
s celkem ve vozidle.  
firstVuApprovalNumber  je číslo schválení prvního celku ve vozidle 
spárovaného se sníma čem pohybu.  
firstVuSerialNumber  je výrobní číslo prvního celku ve vozidle spáro ­
vaného se sníma čem pohybu.  
sensorPairingDateCurrent  je datum aktuálního párování sníma če 
pohybu s celkem ve vozidle.  
currentVuApprovalNumber  je číslo schválení celku ve vozidle aktu ­
álně spárovaného se sníma čem pohybu.  
currentVUSerialNumber  je výrobní číslo celku ve vozidle aktuáln ě 
spárovaného se sníma čem pohybu.  
2.142  SensorInstallationSecData  
Informace uložená na kart ě dílny týkající se bezpe čnostních dat pot řeb­
ných pro párování sníma čů pohybu s celky ve vozidlech (požadavky 308 
a 331 přílohy 1C).  
1. generace:
  
Přiřazení hodnoty : dle ISO 16844-3.  
2. generace:  
Jak je uvedeno v dodatku 11, karta dílny musí pojmout až t ři klíče pro 
párování celku ve vozidle se sníma čem pohybu. Tyto klí če mají různé 
verze.
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 144  
2.143  SensorOSIdentifier  
Identifikátor opera čního systému sníma če pohybu.
  
Přiřazení hodnoty : specifické pro výrobce.  
2.144  SensorPaired  
1. generace:  
Informace uložená v celku ve vozidle týkající se identifikace sníma če 
pohybu spárovaného s celkem ve vozidle (požadavek 079 p řílohy 1B).
  
sensorSerialNumber  je výrobní číslo snímače pohybu aktuáln ě spárova­
ného s celkem ve vozidle.  
sensorApprovalNumber  je číslo schválení sníma če pohybu aktuáln ě 
spárovaného s celkem ve vozidle.  
sensorPairingDateFirst  je datum prvního párování sníma če pohybu, 
který je aktuáln ě spárován s celkem ve vozidle, s n ějakým celkem ve 
vozidle.  
2.145  SensorPairedRecord  
2. generace:  
Informace uložená v celku ve vozidle týkající se identifikace sníma če 
pohybu spárovaného s celkem ve vozidle (požadavek 97 p řílohy 1C).
  
sensorSerialNumber  je výrobní číslo sníma če pohybu spárovaného 
s celkem ve vozidle.  
sensorApprovalNumber  je číslo schválení tohoto sníma če pohybu.  
sensorPairingDate  je datum spárování tohoto sníma če pohybu s celkem 
ve vozidle.  
2.146  SensorPairingDate  
Datum spárování sníma če pohybu s celkem ve vozidle.
  
Přiřazení hodnoty : není specifikováno.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 145  
2.147  SensorSCIdentifier  
Identifikátor bezpe čnostní komponenty sníma če pohybu.
  
Přiřazení hodnoty : specifické pro výrobce komponenty.  
2.148  SensorSerialNumber  
Výrobní číslo sníma če pohybu.
  
2.149  Signature  
Digitální podpis.  
1. generace:
  
Přiřazení hodnoty : v souladu s dodatkem 11 „Spole čné bezpečnostní 
mechanismy“.  
2. generace:
  
Přiřazení hodnoty : v souladu s dodatkem 11 „Spole čné bezpečnostní 
mechanismy“.  
2.150  SignatureRecordArray  
2. generace:  
Sada podpis ů a metadata použitá v protokolu pro stahování.
  
recordType  označuje typ záznamu (Signature).  Přiřazení hodnoty : viz 
RecordType  
recordSize  je velikost záznamu Signature v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. Hodnota je nastavena 
na 1, protože digitální podpisy mohou mít r ůzné délky.  
records  je sada digitálních podpis ů. 
2.151  SimilarEventsNumber  
Počet podobných událostí b ěhem daného dne (požadavek 094 p řílohy 1B 
a požadavek 117 p řílohy 1C).
  
Přiřazení hodnoty:  0 se nepoužívá, 1 znamená, že v daný den se 
vyskytla a byla uložena pouze jedna událost toho typu, 2 znamená, že 
v daný den se vyskytly dv ě události toho typu (pouze jedna byla ulože ­
na), … 255 znamená, že v daný den se vyskytlo 255 nebo více událostí 
toho typu.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 146  
2.152  SpecificConditionRecord  
Informace uložené na kart ě řidiče, kartě dílny nebo v celku ve vozidle 
týkající se zvláštní podmínky (požadavky 130, 276, 301, 328 a 355 
přílohy 1C).
  
entryTime  je datum a čas zadání.  
specificConditionType  je kód identifikující zvláštní podmínku.  
2.153  SpecificConditions  
Informace uložené na kart ě řidiče, kartě dílny nebo v celku ve vozidle 
týkající se zvláštní podmínky (požadavky 131, 277, 302, 329 a 356 
přílohy 1C).  
2. generace:
  
conditionPointerNewestRecord  je index naposledy aktualizovaného 
záznamu o zvláštní podmínce.  
Přiřazení hodnoty : Číslo odpovídající čítači záznamů o zvláštní 
podmínce, za čínající hodnotou ‘0’ pro první výskyt záznamu o zvláštní 
podmínce ve struktu ře. 
specificConditionRecords  je sada záznam ů obsahujících informace 
o zaznamenaných zvláštních podmínkách.  
2.154  SpecificConditionType  
Kód identifikující zvláštní podmínku (požadavky 050b, 105a, 212a 
a 230a přílohy 1B a požadavek 62 p řílohy 1C).
  
1. generace:  
Přiřazení hodnoty:  
‘00’H vyhrazeno pro budoucí použití  
‘01’H mimo p ůsobnost – za čátek 
‘02’H mimo p ůsobnost – konec  
‘03’H p řevoz lodí / p řevoz vlakem  
‘04’H .. ‘FF’H vyhrazeno pro budoucí použití  
2. generace:  
Přiřazení hodnoty:  
‘00’H vyhrazeno pro budoucí použití  
‘01’H mimo p ůsobnost – za čátek 
‘02’H mimo p ůsobnost – konec  
‘03’H p řevoz lodí / p řevoz vlakem – za čátek 
‘04’H p řevoz lodí / p řevoz vlakem – konec  
‘05’H .. ‘FF’H vyhrazeno pro budoucí použití  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 147  
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í.
  
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:  
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).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 148  
2.164  VehicleIdentificationNumber  
Identifikační číslo vozidla (VIN) odkazující na vozidlo jako celek, 
obvykle výrobní číslo karosérie nebo rámu.
  
Přiřazení hodnoty : podle ISO 3779.  
2.165  VehicleIdentificationNumberRecordArray  
2. generace:  
Identifikační číslo vozidla a metadata použitá v protokolu pro stahování.
  
recordType  označuje typ záznamu (VehicleIdentificationNumber).  
Přiřazení hodnoty : viz RecordType  
recordSize  je velikost záznamu VehicleIdentificationNumber v bajtech.  
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).  
2.167  VehicleRegistrationNumber  
Registrační značka vozidla (VRN). Registra ční značka je přidělena 
orgánem registrujícím vozidlo.
  
codePage  určuje znakovou sadu definovanou v kapitole 4.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 149  
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  
2. generace:  
Registrační značka vozidla a metadata použitá v protokolu pro stahová ­
ní.
 
recordType  označuje typ záznamu (VehicleRegistrationNumber).  Přiřa­
zení hodnoty : viz RecordType  
recordSize  je velikost záznamu VehicleRegistrationNumber v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada registra čních značek vozidla.  
2.169  VuAbility  
2. generace:  
Informace uložená v celku ve vozidle a týkající se schopnosti celku ve 
vozidle používat karty tachografu 1. generace (požadavek 121 p řílohy 
1C).
 
Přiřazení hodnoty – oktetové uspo řádání:  ‘xxxxxxxa’B (8 bit ů) 
Pro schopnost podporovat 1. generaci:  
‘a’B Schopnost podporovat karty tachografu 1. generace:  
‘0’B 1. generace je podporována,  
‘1’B 1. generace není podporována,  
‘xxxxxxx’B vyhrazeno pro budoucí použití  
2.170  VuActivityDailyData  
1. generace:  
Informace uložené v celku ve vozidle související se zm ěnami činnosti 
a/nebo zm ěnami statusu řízení a/nebo zm ěnami statusu karty pro daný 
kalendářní den (požadavek 084 p řílohy 1B a požadavky 105, 106 a 107 
přílohy 1C) a se stavem otvor ů pro kartu v 00.00 daného dne.
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 150  
noOfActivityChanges  je počet slov ActivityChangeInfo v sad ě activity­
ChangeInfos.  
activityChangeInfos  je sada slov ActivityChangeInfo uložených v celku 
ve vozidle pro daný den. Vždy obsahuje dv ě slova ActivityChangeInfo 
udávající status dvou otvor ů pro kartu v 00.00 daného dne.  
2.171  VuActivityDailyRecordArray  
2. generace:  
Informace uložené v celku ve vozidle související se zm ěnami činnosti 
a/nebo zm ěnami statusu řízení a/nebo zm ěnami statusu karty pro daný 
kalendářní den (požadavky 105, 106 a 107 p řílohy 1C) a se stavem 
otvorů pro kartu v 00.00 daného dne.
  
recordType  označuje typ záznamu (ActivityChangeInfo).  Přiřazení 
hodnoty : viz RecordType  
recordSize  je velikost záznamu ActivityChangeInfo v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada slov ActivityChangeInfo uložených v celku ve vozidle 
pro daný den. Vždy obsahuje dv ě slova ActivityChangeInfo udávající 
status dvou otvor ů pro kartu v 00.00 daného dne.  
2.172  VuApprovalNumber  
Číslo schválení typu celku ve vozidle.  
1. generace:
  
Přiřazení hodnoty : není specifikováno.  
2. generace:
  
Přiřazení hodnoty:  
Číslo schválení musí být uvedeno tak, jak bylo zve řejněno na přísluš­
ných webových stránkách Evropské komise, tj. nap ř. včetně případných 
spojovníků. Číslo schválení musí být zarovnáno doleva.  
2.173  VuCalibrationData  
1. generace:  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 151  
Informace uložené v celku ve vozidle týkající se kalibrací záznamového 
zařízení (požadavek 098 p řílohy 1B).
  
noOfVuCalibrationRecords  je počet záznam ů obsažených v sad ě 
vuCalibrationRecords.  
vuCalibrationRecords  je sada kalibra čních záznam ů. 
2.174  VuCalibrationRecord  
Informace uložené v celku ve vozidle týkající se kalibrace záznamového 
zařízení (požadavek 098 p řílohy 1B a požadavky 119 a 120 p řílohy 1C).  
1. generace:
  
calibrationPurpose  je účel kalibrace.  
workshopName, workshopAddress  jsou název dílny a její adresa.  
workshopCardNumber  identifikuje kartu dílny použitou p ři kalibraci.  
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í.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 152  
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.  
2. generace:
  
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.  
2.175  VuCalibrationRecordArray  
2. generace:  
Informace uložené v celku ve vozidle týkající kalibrací záznamového 
zařízení (požadavky 119 a 120 p řílohy 1C).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 153
  
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:
  
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 ě. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 154  
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:  
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 155  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada záznam ů týkajících se cykl ů vložení a vyjmutí karty.  
▼M1 
2.179  VuCardRecord  
2. generace:  
Informace uložené v celku ve vozidle o použité kart ě tachografu (p říloha 
IC požadavek 132).
  
cardNumberAndGenerationInformation  je celé číslo karty a generace 
použité karty (datový typ 2.74).  
cardExtendedSerialNumber  se načte ze souboru EF_ICC pod hlavním 
souborem (MF) karty.  
cardStructureVersion  se načte ze souboru EF_Application_Identifica ­
tion pod DF_Tachograph_G2.  
cardNumber  se načte ze souboru EF_Identification pod DF_Tacho ­
graph_G2.  
▼B 
2.180  VuCardRecordArray  
2. generace:  
Informace uložené v celku ve vozidle o kartách tachografu použitých 
s tímto celkem ve vozidle. Tyto informace jsou ur čeny pro analýzu 
problémů s celkem ve vozidle a kartou (požadavek 132 p řílohy 1C).
  
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 156  
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.  
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:
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 157  
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.  
2.186  VuControlActivityData  
1. generace:  
Informace uložené v celku ve vozidle týkající se kontrol provedených 
s použitím tohoto celku ve vozidle (požadavek 102 p řílohy 1B).
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 158  
noOfControls  je počet kontrol uvedených v sad ě vuControlActivityRe ­
cords.  
vuControlActivityRecords  je sada záznam ů o kontrolních činnostech.  
2.187  VuControlActivityRecord  
Informace uložené v celku ve vozidle týkající se kontroly provedené 
s použitím tohoto celku ve vozidle (požadavek 102 p řílohy 1B a poža ­
davek 126 p řílohy 1C).  
1. generace:
  
controlType  je typ kontroly.  
controlTime  je datum a čas kontroly.  
controlCardNumber  identifikuje kontrolní kartu použitou p ři kontrole.  
downloadPeriodBeginTime  je začátek staženého období, pokud jsou 
stahována data.  
downloadPeriodEndTime  je konec staženého období, pokud jsou 
stahována data.  
2. generace:
  
Místo prvku controlCardNumber používá struktura dat 2. generace násle ­
dující datový prvek.  
controlCardNumberAndGeneration  identifikuje kontrolní kartu 
použitou pro kontrolu v četně její generace.  
2.188  VuControlActivityRecordArray  
2. generace:  
Informace uložené v celku ve vozidle týkající se kontrol provedených 
s použitím tohoto celku ve vozidle (požadavek 126 p řílohy 1C).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 159
  
recordType  označuje typ záznamu (VuControlActivityRecord).  Přiřa­
zení hodnoty : viz RecordType  
recordSize  je velikost záznamu VuControlActivityRecord v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada záznam ů o kontrolních činnostech provedených s celkem 
ve vozidle.  
2.189  VuDataBlockCounter  
Čítač uložený na kart ě identifikující postupn ě cykly vkládání a vyjímání 
karty z/do celk ů ve vozidle.
  
Přiřazení hodnoty : pořadové číslo s max. hodnotou 9 999, po níž 
začíná opět hodnotou 0.  
2.190  VuDetailedSpeedBlock  
Informace uložené v celku ve vozidle týkající se podrobností o rychlosti 
vozidla během jedné minuty, kdy se vozidlo pohybovalo (požadavek 
093 přílohy 1B a požadavek 116 p řílohy 1C).
  
speedBlockBeginDate  je datum a čas první hodnoty rychlosti v rámci 
bloku.  
speedsPerSecond  je chronologická posloupnost nam ěřených rychlostí 
každou sekundu b ěhem minuty za čínající v okamžiku speedBlockBegin ­
Date (včetně). 
2.191  VuDetailedSpeedBlockRecordArray  
2. generace:  
Informace uložené v celku ve vozidle týkající se podrobností o rychlosti 
vozidla.
  
recordType  označuje typ záznamu (VuDetailedSpeedBlock).  Přiřazení 
hodnoty : viz RecordType  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 160  
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.  
2.193  VuDownloadablePeriod  
Nejstarší a nejnov ější datum, pro které celek ve vozidle uchovává údaje 
týkající se činností řidičů (požadavky 081, 084 nebo 087 p řílohy 1B 
a požadavky 102, 105 a 108 p řílohy 1C).
  
minDownloadableTime  je datum a čas nejstaršího záznamu o vložení 
karty, změně činnosti nebo zadání místa, který je uložen v celku ve 
vozidle.  
maxDownloadableTime  je datum a čas nejnovějšího záznamu o vyjmutí 
karty, změně činnosti nebo zadání místa, který je uložen v celku ve 
vozidle.  
2.194  VuDownloadablePeriodRecordArray  
2. generace:  
VUDownloadablePeriod a metadata použitá v protokolu pro stahování.
  
recordType  označuje typ záznamu (VuDownloadablePeriod).  Přiřazení 
hodnoty : viz RecordType  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 161  
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.  
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ů. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 162  
records  je sada datových záznam ů o provedených staženích.  
2.197  VuEventData  
1. generace:  
Informace uložené v celku ve vozidle týkající se událostí (požadavek 
094 přílohy 1B krom ě událostí p řekročení povolené rychlosti).
  
noOfVuEvents  je počet událostí uvedených v sad ě vuEventRecords.  
vuEventRecords  je sada záznam ů o událostech.  
2.198  VuEventRecord  
Informace uložené v celku ve vozidle týkající se události (požadavek 
094 přílohy 1B a požadavek 117 p řílohy 1C krom ě událostí p řekročení 
povolené rychlosti).  
1. generace:
  
eventType  je typ události.  
eventRecordPurpose  je účel, pro který byla tato událost zaznamenána.  
eventBeginTime  je datum a čas začátku události.  
eventEndTime  je datum a čas konce události.  
cardNumberDriverSlotBegin  identifikuje kartu vloženou v otvoru pro 
kartu řidiče na začátku události.  
cardNumberCodriverSlotBegin  identifikuje kartu vloženou v otvoru 
pro kartu druhého řidiče na začátku události.  
cardNumberDriverSlotEnd  identifikuje kartu vloženou v otvoru pro 
kartu řidiče na konci události.  
cardNumberCodriverSlotEnd  identifikuje kartu vloženou v otvoru pro 
kartu druhého řidiče na konci události.  
similarEventsNumber  je počet podobných událostí v daný den.  
Tato posloupnost m ůže být použita pro všechny události s výjimkou 
událostí překročení povolené rychlosti.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 163  
2. generace:
  
Kromě prvků 1. generace se používají tyto datové prvky:  
manufacturerSpecificEventFaultData  obsahuje dodate čné informace 
o události, které jsou specifické pro výrobce.  
Místo prvk ů cardNumberDriverSlotBegin, cardNumberCodriverSlotBe ­
gin, cardNumberDriverSlotEnd a cardNumberCodriverSlotEnd používá 
struktura dat 2. generace následující datové prvky:  
cardNumberAndGenDriverSlotBegin  identifikuje kartu vloženou 
v otvoru pro kartu řidiče na začátku události, v četně její generace.  
cardNumberAndGenCodriverSlotBegin  identifikuje kartu vloženou 
v otvoru pro kartu druhého řidiče na začátku události, v četně její gene­
race.  
cardNumberAndGenDriverSlotEnd  identifikuje kartu vloženou 
v otvoru pro kartu řidiče na konci události, v četně její generace.  
cardNumberAndGenCodriverSlotEnd  identifikuje kartu vloženou 
v otvoru pro kartu druhého řidiče na konci události, v četně její generace.  
Je-li událost časovým nesouladem, interpretují se eventBeginTime 
a eventEndTime takto:  
eventBeginTime  je datum a čas záznamového za řízení.  
eventEndTime  je datum a čas GNSS.  
2.199  VuEventRecordArray  
2. generace:  
Informace uložené v celku ve vozidle týkající se událostí (požadavek 
117 přílohy 1C krom ě událostí p řekročení povolené rychlosti).
  
recordType  označuje typ záznamu (VuEventRecord).  Přiřazení 
hodnoty : viz RecordType  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 164  
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.  
2.200  VuFaultData  
1. generace:  
Informace uložené v celku ve vozidle týkající se závad (požadavek 096 
přílohy 1B).
  
noOfVuFaults  je počet závad uvedených v sad ě vuFaultRecords.  
vuFaultRecords  je sada záznam ů o závadách.  
2.201  VuFaultRecord  
Informace uložené v celku ve vozidle týkající se závady (požadavek 096 
přílohy 1B a požadavek 118 p řílohy 1C).  
1. generace:
  
faultType  je typ závady záznamového za řízení.  
faultRecordPurpose  je účel, pro který byla tato závada zaznamenána.  
faultBeginTime  je datum a čas začátku závady.  
faultEndTime  je datum a čas konce závady.  
cardNumberDriverSlotBegin  identifikuje kartu vloženou v otvoru pro 
kartu řidiče na začátku závady.  
cardNumberCodriverSlotBegin  identifikuje kartu vloženou v otvoru 
pro kartu druhého řidiče na začátku závady.  
cardNumberDriverSlotEnd  identifikuje kartu vloženou v otvoru pro 
kartu řidiče na konci závady.  
cardNumberCodriverSlotEnd  identifikuje kartu vloženou v otvoru pro 
kartu druhého řidiče na konci závady.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 165  
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, cardNumberCodriverSlotBe ­
gin, cardNumberDriverSlotEnd a cardNumberCodriverSlotEnd používá 
struktura dat 2. generace následující datové prvky:  
cardNumberAndGenDriverSlotBegin  identifikuje kartu vloženou 
v otvoru pro kartu řidiče na začátku závady, v četně její generace.  
cardNumberAndGenCodriverSlotBegin  identifikuje kartu vloženou 
v otvoru pro kartu druhého řidiče na začátku závady, v četně její gene­
race.  
cardNumberAndGenDriverSlotEnd  identifikuje kartu vloženou 
v otvoru pro kartu řidiče na konci závady, v četně její generace.  
cardNumberAndGenCodriverSlotEnd  identifikuje kartu vloženou 
v otvoru pro kartu druhého řidiče na konci závady, v četně její generace.  
2.202  VuFaultRecordArray  
2. generace:  
Informace uložené v celku ve vozidle týkající se závad (požadavek 118 
přílohy 1C).
  
recordType  označuje typ záznamu (VuFaultRecord).  Přiřazení 
hodnoty : viz RecordType  
recordSize  je velikost záznamu VuFaultRecord v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada záznam ů o závadách.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 166  
2.203  VuGNSSADRecord  
2. generace:  
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.  
2.204  VuGNSSADRecordArray  
2. generace:  
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.  
▼B 
2.205  VuIdentification  
Informace uložené v celku ve vozidle týkající se identifikace celku ve 
vozidle (požadavek 075 p řílohy 1B a požadavky 93 a 121 p řílohy 1C).  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 167  
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.  
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.  
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.  
2.206  VuIdentificationRecordArray  
2. generace:  
VuIdentification a metadata použitá v protokolu pro stahování.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 168
  
recordType  označuje typ záznamu (VuIdentification).  Přiřazení 
hodnoty : viz RecordType  
recordSize  je velikost záznamu VuIdentification v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada záznam ů VuIdentification.  
2.207  VuITSConsentRecord  
2. generace:  
Informace uložené v celku ve vozidle týkající se souhlasu řidiče s použí­
váním inteligentních dopravních systém ů.
 
cardNumberAndGen  identifikuje kartu v četně její generace. Musí se 
jednat o kartu řidiče nebo kartu dílny.  
consent  je příznak, který uvádí, zda řidič souhlasil s používáním inteli ­
gentních dopravních systém ů ve spojitosti s tímto vozidlem / celkem ve 
vozidle.  
Přiřazení hodnoty:  
TRUE ozna čuje souhlas řidiče s používáním inteligent ­
ních dopravních systém ů 
FALSE ozna čuje nesouhlas řidiče s používáním inteligent ­
ních dopravních systém ů 
2.208  VuITSConsentRecordArray  
2. generace:  
Informace uložené v celku ve vozidle týkající se souhlasu řidiče s použí­
váním inteligentních dopravních systém ů (požadavek 200 p řílohy 1C).
  
recordType  označuje typ záznamu (VuITSConsentRecord).  Přiřazení 
hodnoty : viz RecordType  
recordSize  je velikost záznamu VuITSConsentRecord v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada záznam ů o souhlasu s používáním ITS.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 169  
2.209  VuManufacturerAddress  
Adresa výrobce celku ve vozidle.
  
Přiřazení hodnoty : není specifikováno.  
2.210  VuManufacturerName  
Název výrobce celku ve vozidle.
  
Přiřazení hodnoty : není specifikováno.  
2.211  VuManufacturingDate  
Datum výroby celku ve vozidle.
  
Přiřazení hodnoty : není specifikováno.  
2.212  VuOverSpeedingControlData  
Informace uložené v celku ve vozidle týkající se událostí p řekročení 
povolené rychlosti od poslední kontroly p řekročení povolené rychlosti 
(požadavek 095 p řílohy 1B a požadavek 117 p řílohy 1C).
  
lastOverspeedControlTime  je datum a čas poslední kontroly p řekročení 
povolené rychlosti.  
firstOverspeedSince  je datum a čas prvního p řekročení povolené rych ­
losti po této kontrole p řekročení povolené rychlosti.  
numberOfOverspeedSince  je počet událostí p řekročení povolené rych ­
losti od poslední kontroly p řekročení povolené rychlosti.  
2.213  VuOverSpeedingControlDataRecordArray  
2. generace:  
VuOverSpeedingControlData a metadata použitá v protokolu pro staho ­
vání.
 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 170  
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é rych ­
losti.  
2.214  VuOverSpeedingEventData  
1. generace:  
Informace uložené v celku ve vozidle týkající se událostí p řekročení 
povolené rychlosti (požadavek 094 p řílohy 1B).
  
noOfVuOverSpeedingEvents  je počet událostí uvedených v sad ě 
vuOverSpeedingEventRecords.  
vuOverSpeedingEventRecords  je sada záznam ů o událostech p řekro­ 
čení povolené rychlosti.  
2.215  VuOverSpeedingEventRecord  
1. generace:  
Informace uložené v celku ve vozidle týkající se událostí p řekročení 
povolené rychlosti (požadavek 094 p řílohy 1B a požadavek 117 p řílohy 
1C).
 
eventType  je typ události.  
eventRecordPurpose  je účel, pro který byla tato událost zaznamenána.  
eventBeginTime  je datum a čas začátku události.  
eventEndTime  je datum a čas konce události.  
maxSpeedValue  je nejvyšší rychlost nam ěřená během události.  
averageSpeedValue  je průměrná rychlost nam ěřená během události.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 171  
cardNumberDriverSlotBegin  identifikuje kartu vloženou v otvoru pro 
kartu řidiče na začátku události.  
similarEventsNumber  je počet podobných událostí v daný den.  
2. generace:  
Informace uložené v celku ve vozidle týkající se událostí p řekročení 
povolené rychlosti (požadavek 094 p řílohy 1B a požadavek 117 p řílohy 
1C).
 
Namísto prvku cardNumberDriverSlotBegin používá struktura dat 2. 
generace následující datový prvek:  
cardNumberAndGenDriverSlotBegin  identifikuje kartu vloženou 
v otvoru pro kartu řidiče na začátku události, v četně její generace.  
2.216  VuOverSpeedingEventRecordArray  
2. generace:  
Informace uložené v celku ve vozidle týkající se událostí p řekročení 
povolené rychlosti (požadavek 117 p řílohy 1C).
  
recordType  označuje typ záznamu (VuOverSpeedingEventRecord).  
Přiřazení hodnoty : viz RecordType  
recordSize  je velikost záznamu VuOverSpeedingEventRecord v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada záznam ů o událostech p řekročení povolené rychlosti.  
2.217  VuPartNumber  
Katalogové číslo dílu celku ve vozidle.
  
Přiřazení hodnoty : specifické pro výrobce celku ve vozidle.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 172  
2.218  VuPlaceDailyWorkPeriodData  
1. generace:  
Informace uložené v celku ve vozidle týkající se míst, kde řidiči začínají 
nebo končí denní pracovní dobu (požadavek 087 p řílohy 1B a požadavky 
108 a 110 p řílohy 1C).
  
noOfPlaceRecords  je počet záznamů uvedených v sad ě vuPlaceDaily ­
WorkPeriodRecords.  
vuPlaceDailyWorkPeriodRecords  je sada záznam ů týkajících se míst.  
2.219  VuPlaceDailyWorkPeriodRecord  
1. generace:  
Informace uložené v celku ve vozidle týkající se místa, kde řidič začíná 
nebo končí denní pracovní dobu (požadavek 087 p řílohy 1B a požadavky 
108 a 110 p řílohy 1C).
  
fullCardNumber  je typ karty řidiče, členský stát, který ji vydal, a číslo 
karty.  
placeRecord  obsahuje informace týkající se zadaného místa.  
2. generace:  
Informace uložené v celku ve vozidle týkající se místa, kde řidič začíná 
nebo končí denní pracovní dobu (požadavek 087 p řílohy 1B a požadavky 
108 a 110 p řílohy 1C).
  
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 173  
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.
  
2.223  VuSerialNumber  
Výrobní číslo celku ve vozidle (požadavek 075 p řílohy 1B a požadavek 
93 přílohy 1C).
  
2.224  VuSoftInstallationDate  
Datum instalace verze softwaru celku ve vozidle.
  
Přiřazení hodnoty : není specifikováno.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 174  
2.225  VuSoftwareIdentification  
Informace uložená v celku ve vozidle týkající se instalovaného softwaru.
  
vuSoftwareVersion  je číslo verze softwaru v celku ve vozidle.  
vuSoftInstallationDate  je datum instalace verze softwaru.  
2.226  VuSoftwareVersion  
Číslo verze softwaru celku ve vozidle.
  
Přiřazení hodnoty : není specifikováno.  
2.227  VuSpecificConditionData  
1. generace:  
Informace uložené v celku ve vozidle týkající se zvláštních podmínek.
  
noOfSpecificConditionRecords  je počet záznam ů uvedených v sad ě 
specificConditionRecords.  
specificConditionRecords  je sada záznam ů týkajících se zvláštních 
podmínek.  
2.228  VuSpecificConditionRecordArray  
2. generace:  
Informace uložené v celku ve vozidle týkající se zvláštních podmínek 
(požadavek 130 p řílohy 1C).
  
recordType  označuje typ záznamu (SpecificConditionRecord).  Přiřa­
zení hodnoty : viz RecordType  
recordSize  je velikost záznamu SpecificConditionRecord v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada záznam ů týkajících se zvláštních podmínek.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 175  
2.229  VuTimeAdjustmentData  
1. generace:  
Informace uložené v celku ve vozidle týkající se nastavení času provede ­
ný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 provede ­
ného mimo pravidelnou kalibraci (požadavek 101 p řílohy 1B a poža ­
davky 124 a 125 p řílohy 1C).  
1. generace:
  
oldTimeValue, newTimeValue  jsou stará a nová hodnota data a času. 
workshopName, workshopAddress  jsou název dílny a její adresa.  
workshopCardNumber  identifikuje kartu dílny použitou k nastavení 
času. 
2. generace:
  
Místo prvku workshopCardNumber používá struktura dat 2. generace 
následující datový prvek.  
workshopCardNumberAndGeneration  identifikuje kartu dílny 
použitou k nastavení času, včetně její generace.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 176  
2.233  VuTimeAdjustmentRecordArray  
2. generace:  
Informace uložené v celku ve vozidle týkající se nastavení času provede ­
ných mimo pravidelnou kalibraci (požadavky 124 a 125 p řílohy 1C).
  
recordType  označuje typ záznamu (VuTimeAdjustmentRecord).  Přiřa­
zení hodnoty : viz RecordType  
recordSize  je velikost záznamu VuTimeAdjustmentRecord v bajtech.  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada záznam ů o nastavení času. 
2.234  WorkshopCardApplicationIdentification  
Informace uložené na kart ě dílny týkající se identifikace aplikace karty 
(požadavky 307 a 330 p řílohy 1C).  
1. generace:
  
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 177  
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.  
▼B 
2.235  WorkshopCardCalibrationData  
Informace uložené na kart ě dílny týkající se činnosti dílny provedené 
s kartou (požadavky 314, 316, 337 a 339 p řílohy 1C).
  
calibrationTotalNumber  je celkový po čet kalibrací provedených 
s kartou.  
calibrationPointerNewestRecord  je index naposledy aktualizovaného 
záznamu o kalibraci.  
Přiřazení hodnoty : číslo odpovídající čítači záznamů o kalibraci za čína­
jící hodnotou „0“ u prvního výskytu záznamu o kalibraci ve struktu ře. 
calibrationRecords  je sada záznam ů obsahujících informace o kalibraci 
a/nebo nastavení času. 
2.236  WorkshopCardCalibrationRecord  
Informace uložené na kart ě dílny týkající se kalibrace provedené s kartou 
(požadavky 314 a 337 p řílohy 1C).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 178  
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 — 26.02.2020 — 002.001 — 179  
2. generace:
  
Kromě prvků 1. generace se používají tyto datové prvky:  
sensorGNSSSerialNumber  identifikuje vn ější zařízení GNSS.  
rcmSerialNumber  identifikuje modul dálkové komunikace.  
sealDataCard  udává informace o plombách, které jsou p řipojeny 
k různým částem vozidla.  
2.237  WorkshopCardHolderIdentification  
Informace uložené na kart ě dílny týkající se identifikace držitele karty 
(požadavky 311 a 334 p řílohy 1C).
  
workshopName  je název dílny držitele karty.  
workshopAddress  je adresa dílny držitele karty.  
cardHolderName  je příjmení a jméno (jména) držitele (nap ř. jméno 
mechanika).  
cardHolderPreferredLanguage  je upřednostňovaný jazyk držitele 
karty.  
2.238  WorkshopCardPIN  
Kód PIN karty dílny (požadavky 309 a 332 p řílohy 1C).
  
Přiřazení hodnoty : Kód PIN známý držiteli karty, zprava dopln ěný 
bajty „FF“ na délku 8 bajt ů. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 180  
2.239  W-VehicleCharacteristicConstant  
Charakteristický koeficient vozidla (definice k)).
  
Přiřazení hodnoty : impulsy na kilometr v provozním rozsahu 0 až 
64 255 impuls ů/km. 
2.240  VuPowerSupplyInterruptionRecord  
2. generace:  
Informace uložené v celku ve vozidle týkající se událostí p řerušení 
napájení (požadavek 117 p řílohy 1C).
  
eventType  je typ události.  
eventRecordPurpose  je účel, pro který byla tato událost zaznamenána.  
eventBeginTime  je datum a čas začátku události.  
eventEndTime  je datum a čas konce události.  
cardNumberAndGenDriverSlotBegin  identifikuje kartu vloženou do 
otvoru pro kartu řidiče na začátku události, v četně její generace.  
cardNumberAndGenDriverSlotEnd  identifikuje kartu vloženou do 
otvoru pro kartu řidiče na konci události, v četně její generace.  
cardNumberAndGenCodriverSlotBegin  identifikuje kartu vloženou do 
otvoru pro kartu druhého řidiče na začátku události, v četně její generace.  
cardNumberAndGenCodriverSlotEnd  identifikuje kartu vloženou do 
otvoru pro kartu druhého řidiče na konci události, v četně její generace.  
similarEventsNumber  je počet podobných událostí v daný den.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 181  
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 — 26.02.2020 — 002.001 — 182  
noOfRecords  je počet záznamů v sadě záznamů. 
records  je sada záznam ů o párování sníma če. 
3. DEFINICE HODNOT A ROZSAH Ů VELIKOSTÍ  
Definice hodnot prom ěnných použitých pro definice v odstavci 2.
  
4. ZNAKOVÉ SADY  
V řetězcích IA5Strings se používají znaky ASCII dle definice v ISO/IEC 
8824-1. Pro čitelnost a snadné odkazování je p řiřazení hodnoty uvedeno 
dále. V případě nesrovnalostí má norma ISO/IEC 8824-1 p řednost před 
touto informativní poznámkou.
  
Další řetězce znaků (Address, Name, VehicleRegistrationNumber) navíc 
používají i znaky z rozsahu dekadických kód ů znaků 161–255 z násle ­
dujících 8-bitových standardních znakových sad ur čených číslem kódové 
stránky: 
Standardní znaková sada  Kódová stránka 
(dekadicky)  
ISO/IEC 8859-1 Latinka 1 – západoevropské jazyky  1  
ISO/IEC 8859-2 Latinka 2 – st ředoevropské jazyky  2  
ISO/IEC 8859-3 Latinka 3 – jihoevropské jazyky  3  
ISO/IEC 8859-5 Latinka / cyrilice  5  
ISO/IEC 8859-7 Latinka / řecká abeceda  7  
ISO/IEC 8859-9 Latinka 5 – ture čtina 9  
ISO/IEC 8859-13 Latinka 7 – pobaltské jazyky  13  
ISO/IEC 8859-15 Latinka 9  15  
ISO/IEC 8859-16 Latinka 10 – jazyky jihovýchodní Evropy  16  
KOI8-R Latinka / cyrilice  80  
KOI8-U Latinka / cyrilice  85  
5. KÓDOVÁNÍ  
Při kódování dle pravidel ASN.1 musí být všechny datové typy kódo ­
vány podle ISO/IEC 88252 v zarovnané variant ě. 
6. IDENTIFIKÁTORY OBJEKT Ů A IDENTIFIKÁTORY APLIKACÍ  
6.1 Identifikátory objekt ů 
Identifikátory objekt ů (OID) uvedené v této kapitole se vztahují pouze 
na 2. generaci. Tyto OID jsou stanoveny v TR-03110-3 a zde jsou  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 183  
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ěr­
nosti 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 — 26.02.2020 — 002.001 — 184  
6.2 Identifikátory aplikací  
2. generace:  
Identifikátor aplikace (AID) pro vn ější zařízení GNSS (2. generace) je 
dán řetězcem ‘FF 44 54 45 47 4D’. Jde o proprietární AID podle 
ISO/IEC 7816-4.  
Poznámka:  Posledních 5 bajt ů kóduje DTEGM pro vn ější zařízení 
GNSS inteligentního tachografu.  
Identifikátor aplikace pro aplikaci karty tachografu 2. generace je dán 
řetězcem ‘FF 53 4D 52 44 54’. Jde o proprietární AID podle ISO/IEC 
7816-4.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 185  
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 — 26.02.2020 — 002.001 — 186  
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 — 26.02.2020 — 002.001 — 187  
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 — 26.02.2020 — 002.001 — 188  
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 inter ­
change.  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 — 26.02.2020 — 002.001 — 189  
Ú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:  
provozním stavu b ěhem vykonávání p říkazů nebo během 
propojení s digitální jednotkou,  
klidovém stavu v ostatním čase; v tomto stavu musejí být 
zachována všechna data na kart ě. 
3. HARDWARE A KOMUNIKACE  
3.1 Úvod  
Tento odstavec popisuje minimální funk čnost požadovanou kartami 
tachografu a celky ve vozidle k zajišt ění správného provozu a intero ­
perability.  
Karty tachografu jsou v maximální možné mí ře v souladu s dostup ­
nými normami ISO/IEC (p ředevším ISO/IEC 7816). P říkazy 
a protokoly jsou nicmén ě plně popsány, aby bylo specifikováno ur čité 
omezené použití nebo n ěkteré rozdíly, pokud existují. Specifikované 
příkazy plně odpovídají normám, na n ěž se odkazuje, pokud není 
uvedeno jinak.  
3.2 Protokol pro p řenos dat  
TCS_10 Protokol pro p řenos dat je v souladu s normou ISO/IEC 
7816-3 pro T = 0 a T = 1. Celek ve vozidle konkrétn ě 
respektuje prodloužení čekací doby odesílaná kartou.  
3.2.1  Protokoly  
TCS_11 Karta podporuje jak protokol  T=0 , tak protokol  T=1 . Karta 
může navíc podporovat další protokoly založené na kontak ­
tech.  
TCS_12  T=0  je výchozí protokol, pro zm ěnu na protokol  T=1  je 
tedy nutný p říkaz PTS . ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 190  
TCS_13 Za řízení podporují v obou protokolech „ přímou konven ­
ci“, 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.  
— Celková délka z řetězení pro datové pole nep řesáhne 
255 bajtů (zajistí IFD).  
— 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 — 26.02.2020 — 002.001 — 191  
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 — 26.02.2020 — 002.001 — 192  
3.3 Pravidla p řístupu  
TCS_22 Pravidlo p řístupu specifikuje pro režim p řístupu, nap ř. 
příkaz, příslušné bezpe čnostní podmínky. P říslušný příkaz 
je zpracován, pokud jsou tyto bezpe čnostní podmínky 
splněny. 
TCS_23 Pro kartu tachografu se používají tyto bezpe čnostní 
podmínky:  
Zkratka  Význam  
ALW  Akce je vždy možná a m ůže být provedena bez omezení. APDU p říkazu 
a odpovědi se posílá jako otev řený text, tj. bez bezpe čného předávání zpráv.  
NEV  Akce není nikdy možná.  
PLAIN-C  APDU p říkazu se posílá otev řeně, tj. bez bezpe čného předávání zpráv.  
PWD  Akce m ůže být provedena pouze v p řípadě, že byl úsp ěšně ověřen kód PIN 
karty dílny, tj. je nastaven vnit řní bezpečnostní status karty „PIN_Verified“. 
Příkaz musí být odeslán bez bezpe čného předávání zpráv.  
EXT-AUT-G1  Akce m ůže být provedena pouze v p řípadě, že byl úsp ěšně proveden p říkaz 
EXTERNAL AUTHENTICATE k ov ěření pravosti 1. generace (viz rovn ěž 
dodatek 11 část A).  
SM-MAC-G1  APDU (p říkaz a odezva) se musí použít s bezpe čným předáváním zpráv 1. 
generace v režimu pouze s ov ěřením pravosti (viz dodatek 11 část A).  
SM-C-MAC-G1  APDU p říkazu se musí použít s bezpe čným předáváním zpráv 1. generace 
v režimu pouze s ov ěřením pravosti (viz dodatek 11 část A).  
SM-R-ENC-G1  APDU odpov ědi se musí použít s bezpe čným předáváním zpráv 1. generace 
v režimu šifrování (viz dodatek 11 část A), tj. nevrací se ov ěřovací kód 
zprávy (MAC).  
SM-R-ENC- 
MAC-G1  APDU odpov ědi se musí použít s bezpe čným předáváním zpráv 1. generace 
v režimu šifrování a následného ov ěření pravosti (viz dodatek 11 část A).  
SM-MAC-G2  APDU (p říkaz a odezva) se musí použít s bezpe čným předáváním zpráv 2. 
generace v režimu pouze s ov ěřením pravosti (viz dodatek 11 část B).  
SM-C-MAC-G2  APDU p říkazu se musí použít s bezpe čným předáváním zpráv 2. generace 
v režimu pouze s ov ěřením pravosti (viz dodatek 11 část B).  
SM-R-ENC- 
MAC-G2  APDU odpov ědi se musí použít s bezpe čným předáváním zpráv 2. generace 
v režimu šifrování a následného ov ěření pravosti (viz dodatek 11 část B).  
▼M1 
TCS_24 Uvedené bezpe čnostní podmínky mohou být spojeny takto:  
AND: všechny bezpe čnostní podmínky musí být spln ěny, 
OR: alespo ň jedna bezpe čnostní podmínka musí být 
splněna. 
Pravidla p řístupu pro systém soubor ů, tj. pro p říkazy 
SELECT, READ BINARY a UPDATE BINARY, jsou 
stanovena v kapitole 4. Pravidla p řístupu pro zbývající 
příkazy jsou stanovena v následujících tabulkách. Výraz 
„nepoužije se“ je uveden v p řípadě, že příkaz nemusí být 
podporován. V takovém p řípadě může být p říkaz 
podporován či nikoli, ale podmínka p řístupu je mimo 
působnost.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 193  
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 — 26.02.2020 — 002.001 — 194  
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 — 26.02.2020 — 002.001 — 195  
Příkaz Karta řidiče Karta dílny  Kontrolní karta  Karta podniku  
Process DSRC Message  Nepoužije se  Nepoužije se  Nepoužije se  Nepoužije se  
PSO: Compute Digital Signature  Nepoužije se  Nepoužije se  Nepoužije se  Nepoužije se  
PSO: Hash  Nepoužije se  Nepoužije se  Nepoužije se  Nepoužije se  
PERFORM HASH of FILE  Nepoužije se  Nepoužije se  Nepoužije se  Nepoužije se  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Nepoužije se  Nepoužije se  Nepoužije se  Nepoužije se  
Verify  Nepoužije se  ALW  Nepoužije se  Nepoužije se  
▼B 
TCS_28 Karta tachografu m ůže, ale nemusí p řijmout příkaz s vyšší 
úrovní zabezpe čení, než jaká je uvedena v bezpe čnostních 
podmínkách. Tj. je-li bezpe čnostní podmínka ALW (nebo 
PLAIN-C), karta m ůže přijmout příkaz s bezpe čným před­
áváním zpráv (v režimu šifrování a/nebo ov ěření pravosti). 
Vyžaduje-li bezpe čnostní podmínka bezpe čné předávání 
zpráv s režimem ov ěření pravosti, karta tachografu m ůže 
přijmout příkaz s bezpe čným předáváním zpráv téže gene ­
race v režimu ov ěření pravosti a šifrování.  
Poznámka:  Více informací o podpo ře příkazů pro různé 
typy karet tachograf ů a různé DF je uvedeno v popisech 
příkazů. 
3.4 P řehled příkazů a kódů chyb  
Příkazy a organizace soubor ů jsou odvozeny od normy ISO/IEC 
7816-4 a jsou s ní v souladu.  
Tato část popisuje následující páry APDU p říkaz-odpov ěď. Varianty 
příkazů, které jsou podporovány aplikací 1. a 2. generace, jsou 
uvedeny v p říslušných popisech p říkazů. 
Příkaz INS  
SELECT  ‘A4h’  
READ BINARY  ‘B0h’, ‘B1h’  
UPDATE BINARY  ‘D6h’, ‘D7h’  
GET CHALLENGE  ‘84h’  
VERIFY  ‘20h’  
GET RESPONSE  ‘C0h’  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 196  
Příkaz INS  
PERFORM SECURITY OPERA ­
TION  ‘2Ah’  
— VERIFY CERTIFICATE  
— COMPUTE DIGITAL SIGNA ­
TURE  
— VERIFY DIGITAL SIGNA ­
TURE  
— HASH  
— PERFORM HASH OF FILE  
— PROCESS DSRC MESSAGE  
INTERNAL AUTHENTICATE  ‘88h’  
EXTERNAL AUTHENTICATE  ‘82h’  
MANAGE SECURITY ENVIRON ­
MENT  ‘22h’  
— SET DIGITAL SIGNATURE 
TEMPLATE  
— SET AUTHENTICATION 
TEMPLATE  
GENERAL AUTHENTICATE  ‘86h’  
▼M1 
TCS_29 V každé zpráv ě s odpovědí jsou vrácena stavová slova 
SW1 SW2, která ozna čují stav zpracování p říkazu.  
SW1  SW2  Význam  
90 00  Normální zpracování  
61 XX  Normální zpracování XX = po čet dostupných bajt ů odpovědi 
62 81  Zpracování s varováním. Část vrácených dat m ůže být poškoze ­
na. 
63 00  Chyba ov ěření pravosti (varování)  
63 CX  Chybné CHV (kód PIN). „X“ poskytuje stav čítače zbývajících 
pokusů. 
64 00  Chyba provád ění – stav pam ěti nezávislé na napájení nezm ěněn. 
Chyba integrity.  
65 00  Chyba provád ění – stav pam ěti nezávislé na napájení zm ěněn. 
65 81  Chyba provád ění – stav pam ěti nezávislé na napájení zm ěněn – 
porucha pam ěti. 
66 88  Chyba zabezpe čení: chybný kryptografický kontrolní sou čet 
(při bezpečném předávání zpráv) nebo 
chybný certifikát (p ři ověřování certifikátu) 
nebo 
chybný kryptogram (p ři externím ov ěřo­
vání pravosti) nebo 
chybný podpis (p ři ověřování podpisu)  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 197  
SW1  SW2  Význam  
67 00  Chybná délka (chybná hodnota Lc nebo Le)  
68 83  Očekáván poslední p říkaz řetězce 
69 00  Zakázaný p říkaz (žádná dostupná odpov ěď v T=0)  
69 82  Bezpe čnostní status nespln ěn 
69 83  Metoda ov ěření pravosti zablokována  
69 85  Podmínky použití nespln ěny 
69 86  Nedovolený p říkaz (žádný aktuální EF)  
69 87  Chybí o čekávané datové objekty bezpe čného předávání zpráv.  
69 88  Chybné datové objekty bezpe čného předávání zpráv  
6A 80  Chybné parametry v datovém poli  
6A 82  Soubor nenalezen  
6A 86  Chybné parametry P1-P2  
6A 88  Odkazovaná data nenalezena  
6B 00  Chybné parametry (offset mimo EF)  
6C XX  Chybná délka, SW2 udává p řesnou délku. Není vráceno žádné 
datové pole.  
6D 00  Kód instrukce není podporován nebo je neplatný.  
6E 00  Třída není podporována.  
6F 00  - Jiné chyby kontroly  
Mohou být vrácena další stavová slova definovaná v norm ě 
ISO/IEC 7816-4, pokud jejich chování není výslovn ě 
uvedeno v tomto dodatku.  
Volitelně mohou být vrácena nap říklad tato stavová slova:  
6881: Logický kanál není podporován.  
6882: Bezpe čné předávání zpráv není podporováno.  
▼B 
TCS_30 Nastane-li v jednom APDU p říkazu více než jedna chybová 
podmínka, m ůže karta vrátit kterékoli p říslušné stavové 
slovo.  
3.5 Popisy p říkazů 
V této kapitole jsou popsány povinné p říkazy pro karty tachografu.  
Další významné podrobnosti vztahující se k obsaženým kryptogra ­
fickým operacím jsou uvedeny v dodatku 11 „Spole čné bezpečnostní 
mechanismy“ pro tachograf 1. a 2. generace.  
Všechny p říkazy jsou popsány nezávisle na použitém protokolu (T=0 
nebo T=1). Bajty CLA, INS, P1, P2, Lc a Le v APDU jsou vždy 
uvedeny. Jestliže Lc a Le nejsou pot řebné pro popisovaný p říkaz, 
zůstanou odpovídající délka, hodnota a popis prázdné.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 198  
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 — 26.02.2020 — 002.001 — 199  
Příkaz SELECT se používá:  
— k výběru DF aplikace (musí být použit výb ěr podle názvu),  
— k výběru elementárního souboru odpovídajícího uvedenému ID 
souboru.  
3.5.1.1 V ý b ě r p o d l e n á z v u ( A I D )  
Tento příkaz umož ňuje výběr DF aplikace na kart ě. 
TCS_35 Tento p říkaz lze provést odkudkoli ve struktu ře souborů 
(po ATR nebo kdykoliv).  
TCS_36 Výb ěrem aplikace se resetuje aktuální bezpe čnostní 
prostředí. Po provedení výb ěru aplikace již není vybrán 
žádný aktuální ve řejný klíč. Přístupová podmínka EXT- 
AUT-G1 je rovn ěž ztracena. Byl-li p říkaz proveden bez 
bezpečného předávání zpráv, p ředchozí klí če relace bezpe č­
ného předávání zpráv již nejsou dostupné.  
TCS_37  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘A4h’  
P1 1  ‘04h’  Výb ěr podle názvu (AID)  
P2 1  ‘0Ch’  Neočekává se žádná odpov ěď 
Lc 1  ‘NNh’  Počet bajtů odeslaných kart ě (délka AID): 
‘06h’ pro aplikaci tachografu  
#6-#(5+NN)  NN  ‘XX..XXh’  AID: ‘FF 54 41 43 48 4F’ pro aplikaci tachografu 1. 
generace 
AID: ‘FF 53 4D 52 44 54’ pro aplikaci tachografu 2. 
generace  
Na příkaz SELECT není nutná žádná odpov ěď (Le chybí 
v T=1 nebo se nepožaduje odpov ěď v T=0).  
TCS_38  Zpráva s odpov ědí (nepožaduje se odpov ěď) 
Bajt Délka  Hodnota  Popis  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Pokud aplikace odpovídající AID není nalezena, je 
vrácen stav zpracování ‘ 6A82 ’. 
— Pokud je v T=1 p řítomen bajt Le, je vrácen stav zpra ­
cování ‘ 6700 ’. 
— Pokud je v T=0 po p říkazu SELECT vyžadována odpo ­
věď, 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 — 26.02.2020 — 002.001 — 200  
3.5.1.2 V ý b ě r e l e m e n t á r n í h o s o u b o r u p o m o c í j e h o i d e n ­
t i f i k á t o r u s o u b o r u  
TCS_39  Zpráva s p říkazem  
TCS_40 Karta tachografu musí pro tuto variantu p říkazu podporovat 
bezpečné předávání zpráv 2. generace, jak je specifikováno 
v dodatku 11 části B.  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘A4h’  
P1 1  ‘02h’  Výb ěr EF v rámci aktuálního DF  
P2 1  ‘0Ch’  Neočekává se žádná odpov ěď 
Lc 1  ‘02h’  Počet bajtů odeslaných kart ě 
#6-#7  2  ‘XXXXh’  Identifikátor souboru  
Na příkaz SELECT není nutná žádná odpov ěď (Le chybí 
v T=1 nebo se nepožaduje odpov ěď v T=0).  
TCS_41  Zpráva s odpov ědí (nepožaduje se odpov ěď) 
Bajt Délka  Hodnota  Popis  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Pokud soubor odpovídající identifikátoru soubor ů není 
nalezen, je vrácen stav zpracování ‘ 6A82 ’. 
— Pokud je v T=1 p řítomen bajt Le, je vrácen stav zpra ­
cování ‘ 6700 ’. 
— Pokud je v T=0 po p říkazu SELECT vyžadována odpo ­
věď, je vrácen stav ‘ 6900 ’. 
▼M1 
— Je-li vybraný soubor považován za poškozený (v atri ­
butech souboru je detekována chyba integrity), je 
vrácen stav zpracování ‘ 6400 ’ nebo ‘ 6500 ’. 
▼B 
3.5.2  READ BINARY  
Tento příkaz je v souladu s normou ISO/IEC 7816-4, jeho použití je 
ale ve srovnání s p říkazem definovaným normou omezené.  
Příkaz READ BINARY se používá ke čtení dat z transparentního 
souboru.  
Odpověď karty sestává z vrácení p řečtených dat, voliteln ě zapouzdře­
ných ve struktu ře bezpečného předávání zpráv.  
3.5.2.1 P ř í k a z s o f f s e t e m v P 1 - P 2  
Tento příkaz umož ňuje IFD číst data z aktuáln ě vybraného EF bez 
bezpečného předávání zpráv.  
Poznámka:  Tento příkaz bez bezpe čného předávání zpráv lze použít 
pouze pro čtení souboru, který podporuje bezpe čnostní podmínku 
ALW pro režim p řístupu pro čtení. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 201  
TCS_42  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘B0h’  Read Binary  
P1 1  ‘XXh’  Offset v bajtech od za čátku souboru: nejvýznamn ější bajt  
P2 1  ‘XXh’  Offset v bajtech od za čátku souboru: nejmén ě významný 
bajt 
Le 1  ‘XXh’  Délka o čekávaných dat. Po čet bajtů ke čtení. 
Poznámka:  bit 8 v P1 musí být nastaven na 0.  
TCS_43  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
#1-#X  X  ‘XX..XXh’  Přečtená data  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Není-li vybrán žádný EF, je vrácen stav zpracování 
‘6986 ’. 
— Nejsou-li spln ěny bezpečnostní podmínky zvoleného 
souboru, p říkaz se přeruší se stavem ‘ 6982 ’. 
— Není-li offset kompatibilní s velikostí EF (offset > veli ­
kost EF), je vrácen stav zpracování ‘ 6B00 ’. 
— Není-li velikost dat ke čtení kompatibilní s velikostí EF 
(offset + Le > velikost EF), je vrácen stav zpracování 
‘6700 ’ nebo ‘ 6Cxx ’, kde ‘xx’ je p řesná délka.  
▼M1 
— Je-li v atributech souboru zjišt ěna chyba integrity, karta 
považuje soubor za poškozený a neopravitelný a je 
vrácen stav zpracování ‘ 6400 ’ nebo ‘ 6500 ’. 
▼B 
— Je-li v uložených datech zjišt ěna chyba integrity, karta 
vrátí požadovaná data a je vrácen stav zpracování 
‘6281 ’. 
3.5.2.1.1 P ř í k a z s b e z p e č n ý m p ř e d á v á n í m z p r á v ( p ř í k l a d y )  
Tento příkaz umož ňuje IFD číst data z aktuáln ě vybraného EF 
s bezpečným předáváním zpráv za ú čelem ověření integrity p řijatých 
dat a ochrany d ůvěrnosti dat v p řípadě, že se použije bezpe čnostní 
podmínka SM-R-ENC-MAC-G1 (1. generace) nebo SM-R-ENC- 
MAC-G2 (2. generace).  
TCS_44  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘0Ch’  Požadavek na bezpe čné předávání zpráv  
INS 1  ‘B0h’  Read Binary  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 202  
Bajt Délka  Hodnota  Popis  
P1 1  ‘XXh’  P1 (offset v bajtech od za čátku souboru): nejvýznamn ější 
bajt 
P2 1  ‘XXh’  P2 (offset v bajtech od za čátku souboru): nejmén ě 
významný bajt  
Lc 1  ‘XXh’  Délka vstupních dat pro bezpe čné předávání zpráv  
#6 1  ‘97h’  T  LE : tag pro specifikaci o čekávané délky  
#7 1  ‘01h’  L  LE : délka očekávané délky  
#8 1  ‘NNh’  Specifikace o čekávané délky (p ůvodní Le): po čet bajtů 
ke čtení 
#9 1  ‘8Eh’  T  CC : tag pro kryptografický kontrolní sou čet 
#10 1  ‘XXh’  L  CC : délka následujícího kryptografického kontrolního 
součtu 
‘04h’ pro bezpe čné předávání zpráv 1. generace (viz 
dodatek 11 část A) 
‘08h’, ‘0Ch’ nebo ‘10h’ v závislosti na délce klí če AES 
pro bezpečné předávání zpráv 2. generace (viz dodatek 
11 část B)  
#11-#(10+L)  L  ‘XX..XXh’  Kryptografický kontrolní sou čet 
Le 1  ‘00h’  Podle specifikace v ISO/IEC 7816-4  
TCS_45  Zpráva s odpov ědí, pokud není požadována podmínka 
SM-R-ENC-MAC-G1 (1. generace) / SM-R-ENC-MAC- 
G2 (2. generace) a pokud je správný vstupní formát 
bezpečného předávání zpráv:  
▼M1 
Bajt Délka  Hodnota  Popis  
#1 1  ‘81h’  T  PV : tag pro otev řená data  
#2 L  ‘NNh’ nebo 
‘81 NNh’  L PV : délka vrácených dat (= p ůvodní Le). 
L jsou 2 bajty, jestliže L  PV > 127 bajt ů. 
#(2+L)-#(1+L+NN)  NN  ‘XX..XXh’  Otevřená data  
#(2+L+NN)  1  ‘99h’  Tag pro stav zpracování (SW1-SW2) – voli ­
telný pro bezpe čné předávání zpráv 1. gene ­
race 
#(3+L+NN)  1  ‘02h’  Délka stavu zpracování – volitelná pro 
bezpečné předávání zpráv 1. generace  
#(4+L+NN) - #(5+L+NN)  2  ‘XX XXh’  Stav zpracování nechrán ěné APDU odpo ­
vědi – volitelný pro bezpe čné předávání 
zpráv 1. generace  
#(6+L+NN)  1  ‘8Eh’  TCC: tag pro kryptografický kontrolní 
součet 
#(7+L+NN)  1  ‘XXh’  LCC: délka následujícího kryptografického 
kontrolního sou čtu 
‘04h’ pro bezpe čné předávání zpráv 1. gene ­
race (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 — 26.02.2020 — 002.001 — 203  
Bajt Délka  Hodnota  Popis  
#(8+L+NN)-#(7+M+L+NN)  M  ‘XX..XXh’  Kryptografický kontrolní sou čet 
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
▼B 
TCS_46  Zpráva s odpov ědí, pokud je požadována podmínka 
SM-R-ENC-MAC-G1 (1. generace) / SM-R-ENC- 
MAC-G2 (2. generace) a pokud je správný vstupní 
formát bezpe čného předávání zpráv:  
▼M1 
Bajt Délka  Hodnota  Popis  
#1 1  ‘87h’  T  PI CG  : tag pro šifrovaná data (kryptogram)  
#2 L  ‘MMh’ nebo 
‘81 MMh’  L PI CG  : délka vrácených šifrovaných dat (v 
důsledku dopln ění odlišná od p ůvodního Le 
příkazu). 
L je 2 bajty, jestliže LPI CG > 127 bajt ů. 
#(2+L)-#(1+L+MM)  MM  ‘01XX..XXh’  Šifrovaná data: indikátor dopln ění a krypto ­
gram  
#(2+L+MM)  1  ‘99h’  Tag pro stav zpracování (SW1-SW2) – voli ­
telný pro bezpe čné předávání zpráv 1. gene ­
race 
#(3+L+MM)  1  ‘02h’  Délka stavu zpracování – volitelná pro 
bezpečné předávání zpráv 1. generace  
#(4+L+MM) - #(5+L+MM)  2  ‘XX XXh’  Stav zpracování nechrán ěné APDU odpo ­
vědi – volitelný pro bezpe čné předávání 
zpráv 1. generace  
#(6+L+MM)  1  ‘8Eh’  TCC: tag pro kryptografický kontrolní 
součet 
#(7+L+MM)  1  ‘XXh’  LCC: délka následujícího kryptografického 
kontrolního sou čtu 
‘04h’ pro bezpe čné předávání zpráv 1. gene ­
race (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 — 26.02.2020 — 002.001 — 204  
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 
jestliže tělo příkazu není správn ě sestaveno.  
— Jsou-li n ěkteré datové objekty chybné, je vrácen stav 
zpracování ‘ 6988 ’: tato chyba se objeví, jestliže jsou 
přítomny všechny požadované tagy, ale n ěkteré délky 
se liší od o čekávaných.  
— Selže-li ov ěření kryptografického kontrolního sou čtu, je 
vrácen stav zpracování ‘ 6688 ’. 
3.5.2.2 P ř í k a z s k r á t k ý m i d e n t i f i k á t o r e m E F ( e l e m e n t á r ­
n í h o s o u b o r u )  
Tato varianta p říkazu umož ňuje IFD vybrat EF pomocí krátkého iden ­
tifikátoru EF a číst data z tohoto EF.  
TCS_48 Karta tachografu musí podporovat tuto variantu p říkazu pro 
všechny elementární soubory se specifikovaným krátkým 
identifikátorem EF. Tyto krátké identifikátory EF jsou 
specifikovány v kapitole 4.  
TCS_49  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘B0h’  Read Binary  
P1 1  ‘XXh’  Bit 8 je nastaven na 1 
Bity 7 a 6 jsou nastaveny na 00 
Bity 5 – 1 kódují krátký identifikátor EF p říslušného EF  
P2 1  ‘XXh’  Kóduje offset od 0 do 255 bajt ů v EF, na který odkazuje 
P1 
Le 1  ‘XXh’  Délka o čekávaných dat. Po čet bajtů ke čtení. 
Poznámka:  Krátké identifikátory EF používané pro aplikaci 
tachografu 2. generace jsou specifikovány v kapitole 4.  
Pokud P1 kóduje krátký identifikátor EF a p říkaz je 
úspěšný, identifikovaný EF se stává aktuáln ě vybraným 
EF (aktuálním EF).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 205  
TCS_50  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
#1-#L  L  ‘XX..XXh’  Přečtená data  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Není-li soubor odpovídající krátkému identifikátoru EF 
nalezen, je vrácen stav zpracování ‘ 6A82 ’. 
— Nejsou-li spln ěny bezpečnostní podmínky zvoleného 
souboru, p říkaz se přeruší se stavem ‘ 6982 ’. 
— Není-li offset kompatibilní s velikostí EF (offset > veli ­
kost EF), je vrácen stav zpracování ‘ 6B00 ’. 
— Není-li velikost dat ke čtení kompatibilní s velikostí EF 
(offset + Le > velikost EF), je vrácen stav zpracování 
‘6700 ’ nebo ‘ 6Cxx ’, kde ‘xx’ je p řesná délka.  
▼M1 
— Je-li v atributech souboru zjišt ěna chyba integrity, karta 
považuje soubor za poškozený a neopravitelný a je 
vrácen stav zpracování ‘ 6400 ’ nebo ‘ 6500 ’. 
▼B 
— Je-li v uložených datech zjišt ěna chyba integrity, karta 
vrátí požadovaná data a je vrácen stav zpracování 
‘6281 ’. 
3.5.2.3 P ř í k a z s l i c h ý m b a j t e m i n s t r u k c e  
Tato varianta p říkazu umož ňuje IFD číst data z EF s 32 768 nebo více 
bajty.  
TCS_51 Karta tachografu, která podporuje EF s 32 768 nebo více 
bajty, podporuje tuto variantu p říkazu pro tyto EF. Karta 
tachografu m ůže, ale nemusí podporovat tuto variantu 
příkazu pro ostatní EF krom ě EF Sensor_Installation_Data, 
viz TCS_156 a TCS_160.  
TCS_52  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘B1h’  Read Binary  
P1 1  ‘00h’  Aktuální EF  
P2 1  ‘00h’  
Lc 1  ‘NNh’  Lc délka datového objektu offsetu  
#6-#(5+NN)  NN  ‘XX..XXh’  Datový objekt offsetu: 
Tag ‘54h’ 
Délka ‘01h’ nebo ‘02h’ 
Hodnota offset  
▼M1 
Le 1  ‘XXh’  Podle specifikace v ISO/IEC 7816-4  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 206  
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 — 26.02.2020 — 002.001 — 207  
Bajt Délka  Hodnota  Popis  
#6 1  ‘B3h’  Tag pro otev řená data v kódování BER-TLV  
#7 1  ‘NNh’  L  PV : délka přenášených dat  
#(8)-#(7+NN)  NN  ‘XX..XXh’  Otevřená data v kódování BER-TLV, tj. datový objekt 
offsetu s tagem ‘54’  
#(8+NN)  1  ‘97h’  T  LE : tag pro specifikaci o čekávané délky  
#(9+NN)  1  ‘01h’  L  LE : délka očekávané délky  
#(10+NN)  1  ‘XXh’  Specifikace o čekávané délky (p ůvodní Le): po čet bajtů 
ke čtení 
#(11+NN)  1  ‘8Eh’  T  CC : tag pro kryptografický kontrolní sou čet 
#(12+NN)  1  ‘XXh’  L  CC : délka následujícího kryptografického kontrolního 
součtu 
‘08h’, ‘0Ch’ nebo ‘10h’ v závislosti na délce klí če AES 
pro bezpečné předávání zpráv 2. generace (viz dodatek 
11 část B)  
#(13+NN)- 
#(12+M+NN)  M ‘XX..XXh’  Kryptografický kontrolní sou čet 
Le 1  ‘00h’  Podle specifikace v ISO/IEC 7816-4  
TCS_55 Zpráva s odpov ědí, je-li příkaz úspěšný 
Bajt Délka  Hodnota  Popis  
#1 1  ‘B3h’  Otev řená data v kódování BER-TLV  
#2 L  ‘NNh’ nebo 
‘81 NNh’  L PV : délka vrácených dat (= p ůvodní Le). 
L jsou 2 bajty, jestliže L  PV > 127 bajt ů. 
#(2+L)- 
#(1+L+NN)  NN ‘XX..XXh’  Otevřená data v kódování BER-TLV, tj. p řečtená data 
zapouzdřená ve volném datovém objektu s tagem ‘53h’  
#(2+L+NN)  1  ‘99h’  Stav zpracování nechrán ěné APDU odpov ědi 
#(3+L+NN)  1  ‘02h’  Délka stavu zpracování  
#(4+L+NN) – 
#(5+L+NN)  2 ‘XX XXh’  Stav zpracování nechrán ěné APDU odpov ědi 
#(6+L+NN)  1  ‘8Eh’  T  CC : tag pro kryptografický kontrolní sou čet 
#(7+L+NN)  1  ‘XXh’  L  CC : délka následujícího kryptografického kontrolního 
součtu 
‘08h’, ‘0Ch’ nebo ‘10h’ v závislosti na délce klí če AES 
pro bezpečné předávání zpráv 2. generace (viz dodatek 
11 část B)  
#(8+L+NN)-# 
(7+M+L+NN)  M ‘XX..XXh’  Kryptografický kontrolní sou čet 
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
3.5.3  UPDATE BINARY  
Tento příkaz je v souladu s normou ISO/IEC 7816-4, jeho použití je 
ale ve srovnání s p říkazem definovaným normou omezené.  
Zpráva s p říkazem UPDATE BINARY spouští p řepis (výmaz + zápis) 
bitů již přítomných v binárním EF bity poskytnutými v APDU 
příkazu.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 208  
3.5.3.1 P ř í k a z s o f f s e t e m v P 1 - P 2  
Tento příkaz umožňuje IFD zapsat data do aktuáln ě vybraného EF bez 
toho, aby karta ov ěřovala integritu p řijatých dat.  
Poznámka:  Tento příkaz bez bezpe čného předávání zpráv lze použít 
pouze pro aktualizaci souboru, který podporuje bezpe čnostní 
podmínku ALW pro režim p řístupu pro aktualizaci.  
TCS_56  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘D6h’  Update Binary  
P1 1  ‘XXh’  Offset v bajtech od za čátku souboru: nejvýznamn ější bajt  
P2 1  ‘XXh’  Offset v bajtech od za čátku souboru: nejmén ě významný 
bajt 
Lc 1  ‘NNh’  Lc: délka dat k aktualizaci. Po čet bajtů k zápisu.  
#6-#(5+NN)  NN  ‘XX..XXh’  Data k zápisu  
Poznámka:  bit 8 v P1 musí být nastaven na 0.  
TCS_57  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Není-li vybrán žádný EF, je vrácen stav zpracování 
‘6986 ’. 
— Nejsou-li spln ěny bezpečnostní podmínky zvoleného 
souboru, p říkaz se přeruší se stavem ‘ 6982 ’. 
— Není-li offset kompatibilní s velikostí EF (offset > veli ­
kost EF), je vrácen stav zpracování ‘ 6B00 ’. 
— Není-li velikost dat k zápisu kompatibilní s velikostí EF 
(Offset + Lc > velikost EF), je vrácen stav zpracování 
‘6700 ’. 
— Je-li v atributech souboru zjišt ěna chyba integrity, karta 
považuje soubor za poškozený a neopravitelný a je 
vrácen stav zpracování ‘ 6400 ’ nebo ‘ 6500 ’. 
— Je-li zápis neúsp ěšný, je vrácen stav zpracování ‘ 6581 ’. 
3.5.3.1.1 P ř í k a z s b e z p e č n ý m p ř e d á v á n í m z p r á v ( p ř í k l a d y )  
Tento příkaz umož ňuje IFD zapsat data do aktuáln ě vybraného EF, 
přičemž karta ov ěřuje integritu p řijatých dat. Protože není požadováno 
zajištění důvěrnosti, data nejsou šifrována.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 209  
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 — 26.02.2020 — 002.001 — 210  
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 
jestliže tělo příkazu není správn ě sestaveno.  
— Jsou-li n ěkteré datové objekty chybné, je vrácen stav 
zpracování ‘ 6988 ’: tato chyba se objeví, jestliže jsou 
přítomny všechny požadované tagy, ale n ěkteré délky 
se liší od o čekávaných.  
— Selže-li ov ěření kryptografického kontrolního sou čtu, je 
vrácen stav zpracování ‘ 6688 ’. 
3.5.3.2 P ř í k a z s k r á t k ý m i d e n t i f i k á t o r e m E F  
Tato varianta p říkazu umož ňuje IFD vybrat EF pomocí krátkého iden ­
tifikátoru EF a zapsat data z tohoto EF.  
TCS_61 Karta tachografu musí podporovat tuto variantu p říkazu pro 
všechny elementární soubory se specifikovaným krátkým 
identifikátorem EF. Tyto krátké identifikátory EF jsou 
specifikovány v kapitole 4.  
TCS_62  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘D6h’  Update Binary  
P1 1  ‘XXh’  Bit 8 je nastaven na 1 
Bity 7 a 6 jsou nastaveny na 00 
Bity 5 – 1 kódují krátký identifikátor EF p říslušného EF  
P2 1  ‘XXh’  Kóduje offset od 0 do 255 bajt ů v EF, na který odkazuje 
P1 
Lc 1  ‘NNh’  Lc: délka dat k aktualizaci. Po čet bajtů k zápisu.  
#6-#(5+NN)  NN  ‘XX..XXh’  Data k zápisu  
TCS_63  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
Poznámka:  Krátké identifikátory EF používané pro aplikaci 
tachografu 2. generace jsou specifikovány v kapitole 4.  
Pokud P1 kóduje krátký identifikátor EF a p říkaz je 
úspěšný, identifikovaný EF se stává aktuáln ě vybraným 
EF (aktuálním EF).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 211  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Není-li soubor odpovídající krátkému identifikátoru EF 
nalezen, je vrácen stav zpracování ‘ 6A82 ’. 
— Nejsou-li spln ěny bezpečnostní podmínky zvoleného 
souboru, p říkaz se přeruší se stavem ‘ 6982 ’. 
— Není-li offset kompatibilní s velikostí EF (offset > veli ­
kost EF), je vrácen stav zpracování ‘ 6B00 ’. 
— Není-li velikost dat k zápisu kompatibilní s velikostí EF 
(Offset + Lc > velikost EF), je vrácen stav zpracování 
‘6700 ’. 
▼M1 
— Je-li v atributech souboru zjišt ěna chyba integrity, karta 
považuje soubor za poškozený a neopravitelný a je 
vrácen stav zpracování ‘ 6400 ’ nebo ‘ 6500 ’. 
▼B 
— Je-li zápis neúsp ěšný, je vrácen stav zpracování ‘ 6581 ’. 
3.5.3.3 P ř í k a z s l i c h ý m b a j t e m i n s t r u k c e  
Tato varianta p říkazu umož ňuje IFD zapisovat data do EF s 32 768 
nebo více bajty.  
TCS_64 Karta tachografu, která podporuje EF s 32 768 nebo více 
bajty, podporuje tuto variantu p říkazu pro tyto EF. Karta 
tachografu m ůže, ale nemusí podporovat tuto variantu 
příkazu pro ostatní EF.  
TCS_65  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘D7h’  Update Binary  
P1 1  ‘00h’  Aktuální EF  
P2 1  ‘00h’  
Lc 1  ‘NNh’  Lc délka dat v datovém poli p říkazu  
#6-#(5+NN)  NN  ‘XX..XXh’  Datový objekt offsetu s tagem ‘54h’ || volný datový 
objekt s tagem ‘53h’, který zapouzd řuje data k zápisu  
IFD kóduje délku datového objektu offsetu a volného dato ­
vého objektu s použitím minimálního možného po čtem 
oktetů, tj. pomocí bajtu délky ‘01h’ musí IFD kódovat 
offset/délku od 0 do 255 a pomocí bajtu délky ‘02h’ offset/ 
délku od 256 do 65 535 bajt ů. 
TCS_66  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 212  
— 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 — 26.02.2020 — 002.001 — 213  
TCS_68 Zpráva s odpov ědí, je-li příkaz úspěšný 
Bajt Délka  Hodnota  Popis  
#1 1  ‘99h’  T  SW : tag pro stavová slova (chrán ěna pomocí CC)  
#2 1  ‘02h’  L  SW : délka vrácených stavových slov  
#3-#4  2  ‘XXXXh’  Stav zpracování nechrán ěné APDU odpov ědi 
#5 1  ‘8Eh’  T  CC : tag pro kryptografický kontrolní sou čet 
#6 1  ‘XXh’  L  CC : délka následujícího kryptografického kontrolního 
součtu 
‘08h’, ‘0Ch’ nebo ‘10h’ v závislosti na délce klí če AES 
pro bezpečné předávání zpráv 2. generace (viz dodatek 
11 část B)  
#7-#(6+L)  L  ‘XX..XXh’  Kryptografický kontrolní sou čet 
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
3.5.4  GET CHALLENGE  
Tento příkaz je v souladu s normou ISO/IEC 7816-4, jeho použití je 
ale ve srovnání s p říkazem definovaným normou omezené.  
Příkaz GET CHALLENGE žádá kartu o vyslání výzvy pro použití 
v postupu souvisejícím se zabezpe čením, v rámci n ějž se kartě pošle 
kryptogram nebo šifrovaná data.  
TCS_69 Kartou vydaná výzva je platná pouze pro následující p říkaz 
poslaný kart ě, který výzvu používá.  
TCS_70  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘84h’  INS  
P1 1  ‘00h’  P1  
P2 1  ‘00h’  P2  
Le 1  ‘08h’  Le (o čekávaná délka výzvy).  
TCS_71  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
#1-#8  8  ‘XX..XXh’  Výzva  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Pokud se Le liší od ‘08h’, stav zpracování je ‘ 6700 ’. 
— Jestliže jsou chybné parametry P1-P2, stav zpracování 
je ‘6A86 ’. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 214  
3.5.5  VERIFY  
Tento příkaz je v souladu s normou ISO/IEC 7816-4, jeho použití je 
ale ve srovnání s p říkazem definovaným normou omezené.  
Tento příkaz musí podporovat pouze karta dílny.  
Ostatní typy karet tachografu mohou, ale nemusí tento p říkaz imple ­
mentovat, ale pro tyto karty není personalizována žádná referen ční 
hodnota CHV. Proto tyto karty nemohou tento p říkaz úspěšně provést. 
Pro typy karet tachografu jiné než kartu dílny je chování, tj. vracený 
chybový kód, mimo oblast p ůsobnosti této specifikace, je-li tento 
příkaz odeslán.  
Příkaz VERIFY spouští na kart ě porovnání dat CHV (kódu PIN) 
zaslaných z p říkazu s referen ční hodnotou CHV uloženou na kart ě. 
▼M1 
TCS_72 Kód PIN zadaný uživatelem musí být v kódování ASCII 
a IFD jej zprava doplní bajty „FFh“ na délku 8 bajt ů, viz 
rovněž datový typ WorkshopCardPIN v dodatku 1.  
▼B 
TCS_73 Aplikace tachografu 1. a 2. generace používají stejnou refe ­
renční hodnotu CHV.  
TCS_74 Karta tachografu zkontroluje, zda je p říkaz správn ě kódo­
ván. Není-li p říkaz kódován správn ě, karta neporovná 
hodnoty CHV, nesníží čítač zbývajících pokus ů o ověření 
CHV a neresetuje bezpe čnostní status „PIN_Verified“, ale 
příkaz přeruší. Příkaz je kódován správn ě, mají-li bajty 
CLA, INS, P1, P2, Lc stanovené hodnoty, Le chybí 
a datové pole p říkazu má správnou délku.  
TCS_75 Je-li p říkaz úspěšný, je čítač zbývajících pokus ů o ověření 
CHV nastaven zp ět na počáteční hodnotu. Po čáteční 
hodnota čítače zbývajících pokus ů o ověření CHV je 5. 
Je-li příkaz úspěšný, musí karta nastavit vnit řní bezpeč­
nostní status „PIN_Verified“. Karta resetuje tento bezpe č­
nostní status, pokud je resetována karta nebo pokud kód 
CHV přenesený v p říkazu neodpovídá uložené referen ční 
hodnotě CHV.  
Poznámka:  používání stejné referen ční hodnoty CHV 
a globálního bezpe čnostního statusu zabra ňují tomu, aby 
pracovník dílny musel po výb ěru jiného DF aplikace tacho ­
grafu znovu zadávat PIN.  
TCS_76 Neúsp ěšné porovnání se na kart ě zaznamená, tj. čítač 
zbývajících pokus ů o ověření CHV se sníží o jedni čku, 
aby se omezil po čet dalších pokus ů o použití referen ční 
hodnoty CHV.  
TCS_77  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘20h’  INS  
P1 1  ‘00h’  P1  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 215  
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škoze ­
nou, 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 — 26.02.2020 — 002.001 — 216  
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 
jestliže je Le nula, je vrácen stav zpracování ‘ 6Cxx ’, 
kde xx udává p řesný počet dostupných bajt ů. V takovém 
případě jsou připravená data nadále k dispozici pro 
následný p říkaz GET RESPONSE.  
— Jestliže Le není nula a je menší než po čet dostupných 
bajtů, karta normáln ě pošle požadovaná data a je vrácen 
stav zpracování ‘ 61xx ’, kde ‘xx’ udává po čet dodateč­
ných bajtů, které jsou nadále k dispozici pro následný 
příkaz GET RESPONSE.  
— Jestliže p říkaz není podporován (protokol T=1), karta 
vrátí ‘ 6D00 ’. 
3.5.7  PSO: VERIFY CERTIFICATE  
Tento příkaz je v souladu s normou ISO/IEC 7816-8, jeho použití je 
ale ve srovnání s p říkazem definovaným normou omezené.  
Příkaz VERIFY CERTIFICATE je používán kartou k získání ve řej­
ného klíče zvenku a ke kontrole jeho platnosti.  
3.5.7.1 P á r p ř í k a z – o d p o v ě ď 1 . g e n e r a c e  
TCS_81 Tuto variantu p říkazu podporuje pouze aplikace tachografu 
1. generace.  
TCS_82 Pokud je p říkaz VERIFY CERTIFICATE úsp ěšný, veřejný 
klíč je uložen k budoucímu použití v bezpe čnostním 
prostředí. Tento klí č je explicitn ě nastaven pro použití 
v příkazech vztahujících se k zabezpe čení (INTERNAL 
AUTHENTICATE, EXTERNAL AUTHENTICATE nebo 
VERIFY CERTIFICATE) pomocí p říkazu MSE (viz část 
3.5.11) s použitím jeho identifikátoru klí če. 
TCS_83 V každém p řípadě příkaz VERIFY CERTIFICATE používá 
veřejný klíč dříve vybraný p říkazem MSE k otev ření certi­
fikátu. Musí se jednat o ve řejný klíč členského státu nebo 
Evropy.  
TCS_84  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘2Ah’  Perform Security Operation  
P1 1  ‘00h’  P1  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 217  
Bajt Délka  Hodnota  Popis  
P2 1  ‘AEh’  P2: data, která nejsou v kódování BER-TLV (z řetězení 
datových prvk ů) 
Lc 1  ‘C2h’  Lc: délka certifikátu, 194 bajt ů 
#6-#199  194  ‘XX..XXh’  Certifikát: z řetězení datových prvk ů (jak je popsáno 
v dodatku 11)  
TCS_85  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Jestliže se ov ěření certifikátu nezda ří, je vrácen stav 
zpracování ‘ 6688 ’. Proces ov ěření a rozbalení certifi ­
kátu je popsán v dodatku 11 pro G1 a G2.  
— Jestliže v bezpe čnostním prost ředí není žádný ve řejný 
klíč, je vráceno ‘ 6A88 ’. 
— Jestliže se vybraný ve řejný klíč (použitý k rozbalení 
certifikátu) považuje za poškozený, je vrácen stav zpra ­
cování ‘ 6400 ’ nebo ‘ 6581 ’. 
— Pouze 1. generace: Jestliže má vybraný ve řejný klíč 
(použitý k rozbalení certifikátu) CHA.LSB 
(
 ) 
rozdílný od ‘00’ (nap ř. nejde o certifikát členského 
státu nebo Evropy), je vrácen stav zpracování ‘ 6985 ’. 
3.5.7.2 P á r p ř í k a z – o d p o v ě ď 2 . g e n e r a c e  
V závislosti na velikosti k řivky mohou být certifikáty ECC tak 
dlouhé, že je nelze p řenést v jedné APDU. V takovém p řípadě je 
třeba použít z řetězení příkazů podle ISO/IEC 7816-4 a p řenést certi ­
fikát ve dvou po sob ě následujících APDU p říkazu PSO: VERIFY 
CERTIFICATE.  
Struktura certifikátu a parametry domény jsou definovány 
v dodatku 11.  
TCS_86 P říkaz lze provést v MF, DF Tachograph a DF Tacho ­
graph_G2, viz rovn ěž TCS_33.  
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 — 26.02.2020 — 002.001 — 218  
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é.  
TCS_88 Pro APDU s krátkou délkou platí tato ustanovení: IFD 
musí použít minimální po čet APDU pot řebných pro 
přenesení přenášených dat p říkazu a p řenést maximální 
počet bajtů v APDU prvního p říkazu podle hodnoty bajtu 
IFSC, viz TCS_14. Chová-li se IFD odlišn ě, je chování 
karty mimo oblast p ůsobnosti.  
TCS_89 Pro APDU s rozší řenou délkou platí tato ustanovení: 
Nevejde-li se certifikát do jedné APDU, musí karta 
podporovat řetězení příkazů. IFD musí použít minimální 
počet APDU pot řebných pro p řenesení přenášených dat 
příkazu a přenést maximální po čet bajtů v APDU prvního 
příkazu. Chová-li se IFD odlišn ě, je chování karty mimo 
oblast působnosti.  
Poznámka:  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.  
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 (CertificateHolderAuthorisati ­
on.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 řa­
dí). ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 219  
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_Ta ­
chograph 1. generace.  
Použitím p říkazu INTERNAL AUTHENTICATE m ůže 
IFD ověřit pravost karty. Proces ov ěření pravosti je popsán 
v dodatku 11. Zahrnuje následující výroky:  
TCS_92 P říkaz INTERNAL AUTHENTICATE pomocí soukromého 
klíče karty (implicitn ě vybraného) podepíše data pro 
ověření pravosti v četně K1 (první element pro dohodu na 
klíči relace) a RND1 a pomocí aktuáln ě vybraného (pomocí 
posledního p říkazu MSE) ve řejného klíče zašifruje podpis 
a vytvoří ověřovací token (další podrobnosti v dodatku 11).  
TCS_93  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  CLA  
INS 1  ‘88h’  INS  
P1 1  ‘00h’  P1  
P2 1  ‘00h’  P2  
Lc 1  ‘10h’  Délka dat poslaných kart ě 
#6 – #13  8  ‘XX..XXh’  Výzva použitá k ov ěření pravosti karty  
#14 -#21  8  ‘XX..XXh’  VU.CHR (viz dodatek 11)  
Le 1  ‘80h’  Délka dat o čekávaných z karty  
TCS_94  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
#1-#128  128  ‘XX..XXh’  Ověřovací token karty (viz dodatek 11)  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Jestliže v bezpe čnostním prost ředí není žádný ve řejný 
klíč, je vrácen stav zpracování ‘ 6A88 ’. 
— Jestliže v bezpe čnostním prost ředí není žádný 
soukromý klí č, je vrácen stav zpracování ‘ 6A88 ’. 
— Jestliže VU.CHR neodpovídá identifikátoru aktuálního 
veřejného klíče, je vrácen stav zpracování ‘ 6A88 ’. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 220  
— 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 — 26.02.2020 — 002.001 — 221  
TCS_99  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Jestliže CHA aktuáln ě nastaveného ve řejného klíče není 
zřetězením AID aplikace tachografu a typu za řízení 
celku ve vozidle, je vrácen stav zpracování ‘ 6F00 ’. 
— Nepředchází-li p říkazu bezprost ředně příkaz GET 
CHALLENGE, je vrácen stav zpracování ‘ 6985 ’. 
Aplikace tachografu 1. generace m ůže vrátit tyto další 
chybové kódy:  
— Jestliže v bezpe čnostním prost ředí není žádný ve řejný 
klíč, je vráceno ‘ 6A88 ’. 
— Jestliže v bezpe čnostním prost ředí není žádný 
soukromý klí č, je vrácen stav zpracování ‘ 6A88 ’. 
— Je-li ov ěření kryptogramu chybné, je vrácen stav zpra ­
cování ‘ 6688 ’. 
— Je-li vybraný soukromý klí č považován za poškozený, 
je vrácen stav zpracování ‘ 6400 ’ nebo ‘ 6581 ’. 
Varianta p říkazu pro ov ěření pravosti 2. generace m ůže 
vrátit tento další chybový kód:  
— Nezdaří-li se ověření podpisu, karta vrátí ‘ 6300 ’. 
3.5.10  GENERAL AUTHENTICATE  
Tento příkaz se používá pro protokol ov ěření pravosti čipu 2. gene ­
race stanovený v dodatku 11 části B a je v souladu s ISO/IEC 7816-4.  
TCS_100 P říkaz lze provést v MF, DF Tachograph a DF Tacho ­
graph_G2, viz rovn ěž TCS_34.  
TCS_101  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘86h’  
P1 1  ‘00h’  Klí če a protokol jsou implicitn ě známé  
P2 1  ‘00h’  
Lc 1  ‘NNh’  Lc: délka následujícího datového pole  
#6-#(5+L)  L  ‘7Ch’ + L  7C + 
‘80h’ + L  80 + 
‘XX..XXh’  Hodnota do časného veřejného klíče v kódování DER- 
TLV (viz dodatek 11) 
Celek ve vozidle odešle datové objekty v tomto 
pořadí 
▼M1 
5 + L + 1  1  ‘00h’  Podle specifikace v ISO/IEC 7816-4  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 222  
TCS_102  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
#1-#L  L  ‘7Ch’ + L  7C + ‘81h’ 
+ ‘08h’ + ‘XX..XXh’ 
+ ‘82h’ + L  82 + 
‘XX..XXh’  Data pro dynamické ov ěření pravosti v kódo ­
vání DER-TLV: hodnota nonce a ov ěřovací 
token (viz dodatek 11)  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Karta vrátí ‘ 6A80 ’ k indikaci chybných parametr ů 
v datovém poli.  
— Karta vrátí ‘ 6982 ’, nebyl-li úsp ěšně proveden p říkaz 
EXTERNAL AUTHENTICATE.  
Datový objekt pro dynamické ov ěření pravosti ‘7Ch’ 
v odpovědi 
— musí být p řítomen, je-li operace úsp ěšná, tj. stavová 
slova jsou ‘ 9000 ’, 
— nesmí být p řítomen v p řípadě chyby provád ění nebo 
chyby kontroly, tj. jsou-li stavová slova v rozsahu 
‘6400 ’–‘6FFF ’, a 
— nemusí být p řítomen v p řípadě varování, tj. jsou-li 
stavová slova v rozsahu ‘ 6200 ’–‘63FF ’. 
3.5.11  MANAGE SECURITY ENVIRONMENT  
Tento příkaz slouží k nastavení ve řejného klí če pro účely ověření 
pravosti.  
3.5.11.1 P á r p ř í k a z – o d p o v ě ď 1 . g e n e r a c e  
Tento příkaz je v souladu s normou ISO/IEC 7816-4. Jeho použití je 
ale ve srovnání se související normou omezené.  
TCS_103 Tento p říkaz je podporován pouze aplikací tachografu 1. 
generace.  
TCS_104 Klí č, na který se odkazuje v datovém poli MSE, z ůstává 
aktuálním ve řejným klí čem až do p říštího správného 
příkazu MSE, výb ěru DF nebo resetu karty.  
TCS_105 Jestliže klí č, na který se odkazuje, není (dosud) na kart ě 
k dispozici, bezpe čnostní prost ředí zůstává nezm ěněno. 
TCS_106  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  CLA  
INS 1  ‘22h’  INS  
P1 1  ‘C1h’  P1: odkazovaný klí č, platí pro všechny kryptografické 
operace  
P2 1  ‘B6h’  P2 (odkazovaná data týkající se digitálního podpisu)  
Lc 1  ‘0Ah’  Lc: délka následujícího datového pole  
#6 1  ‘83h’  Tag pro odkaz na ve řejný klíč v asymetrických p řípa­
dech ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 223  
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říto­
men, je vrácen stav zpracování ‘ 6A88 ’. 
— Pokud ve formátu bezpe čného předávání zpráv chyb ějí 
některé očekávané datové objekty, je vrácen stav zpra ­
cování ‘ 6987 ’. To může nastat, když chybí tag ‘83h’.  
— Jsou-li n ěkteré datové objekty chybné, je vrácen stav 
zpracování ‘ 6988 ’. To může nastat, když délka identi ­
fikátoru klí če není ‘08h’.  
— Je-li vybraný klí č považován za poškozený, je vrácen 
stav zpracování ‘ 6400 ’ nebo ‘ 6581 ’. 
3.5.11.2 P á r y p ř í k a z – o d p o v ě ď 2 . g e n e r a c e  
Pro ověření pravosti 2. generace karta tachografu podporuje následu ­
jící verze p říkazu MSE: Set, které jsou v souladu s normou ISO/IEC 
7816-4. Tyto verze p říkazu nejsou podporovány pro ov ěření pravosti 
1. generace.  
3.5.11.2.1 M S E : S E T A T p r o o v ě ř e n í p r a v o s t i č i p u  
Následující p říkaz MSE:SET AT se používá pro výb ěr parametr ů 
k ověření pravosti čipu, které se provádí následným p říkazem 
GENERAL AUTHENTICATE.  
TCS_108 P říkaz lze provést v MF, DF Tachograph a DF Tacho ­
graph_G2, viz rovn ěž TCS_34.  
TCS_109  Zpráva s p říkazem MSE:SET AT pro ov ěření pravosti 
čipu 
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘41h’  Nastavit pro interní ov ěření pravosti  
P2 1  ‘A4h’  Ověření pravosti  
Lc 1  ‘NNh’  Lc: délka následujícího datového pole  
#6-#(5+L)  L  ‘80h’ + ‘0Ah’ 
+ ‘XX..XXh’  Odkaz na kryptografický mechanismus v kódování DER- 
TLV: identifikátor objektu ov ěření pravosti čipu (pouze 
hodnota, tag ‘06h’ je vynechán). 
Hodnoty identifikátor ů objektů viz dodatek 1; používá se 
bajtová notace. Pokyny, jak vybrat jeden z t ěchto iden­
tifikátorů objektů, viz dodatek 11.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 224  
3.5.11.2.2 M S E : S E T A T p r o o v ě ř e n í p r a v o s t i c e l k u v e 
v o z i d l e  
Následující p říkaz MSE:SET AT se používá pro výb ěr parametr ů 
a klíčů pro ověření pravosti celku ve vozidle, které se provádí pomocí 
následného p říkazu EXTERNAL AUTHENTICATE.  
TCS_110 P říkaz lze provést v MF, DF Tachograph a DF Tacho ­
graph_G2, viz rovn ěž TCS_34.  
TCS_111  Zpráva s p říkazem MSE:SET AT pro ov ěření pravosti 
celku ve vozidle  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘81h’  Nastavit pro externí ov ěření pravosti  
P2 1  ‘A4h’  Ověření pravosti  
Lc 1  ‘NNh’  Lc: délka následujícího datového pole  
#6-#(5+L)  L  ‘80h’ + ‘0Ah’ 
+ ‘XX..XXh’  Odkaz na kryptografický mechanismus v kódování DER- 
TLV: identifikátor objektu ov ěření pravosti celku ve 
vozidle (pouze hodnota, tag ‘06h’ je vynechán). 
Hodnoty identifikátor ů objektů viz dodatek 1; používá se 
bajtová notace. Pokyny, jak vybrat jeden z t ěchto iden­
tifikátorů objektů, viz dodatek 11.  
‘83h’ + ‘08h’ 
+ ‘XX..XXh’  Odkaz na ve řejný klíč VU v kódování DER-TLV 
s využitím reference držitele certifikátu uvedené v jeho 
certifikátu  
‘91h’ + L  91 + 
‘XX..XXh’  Komprimovaná podoba do časného veřejného klíče celku 
ve vozidle v kódování DER-TLV, která se použije p ři 
ověření pravosti čipu (viz dodatek 11)  
3.5.11.2.3 M S E : S E T D S T  
Následující p říkaz MSE:SET DST se používá pro nastavení ve řejného 
klíče, a to buď 
— pro ověření podpisu, který je poskytnut v následném p říkazu PSO: 
VERIFY DIGITAL SIGNATURE, nebo  
— pro ov ěření podpisu certifikátu, který je poskytnut v následném 
příkazu PSO: VERIFY CERTIFICATE.  
TCS_112 P říkaz lze provést v MF, DF Tachograph a DF Tacho ­
graph_G2, viz rovn ěž TCS_33.  
TCS_113  Zpráva s p říkazem MSE:SET DST  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘81h’  Nastavit pro ov ěření 
P2 1  ‘B6h’  Digitální podpis  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 225  
Bajt Délka  Hodnota  Popis  
Lc 1  ‘NNh’  Lc: délka následujícího datového pole  
#6-#(5+L)  L  ‘83h’ + ‘08h’ 
+ ‘XX...XXh’  Odkaz na ve řejný klíč v kódování DER-TLV, tj. refe ­
rence držitele certifikátu v certifikátu ve řejného klíče (viz 
dodatek 11)  
Pro všechny verze p říkazu jsou struktura zprávy s odpov ědí a stavová 
slova dány takto:  
TCS_114  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li p říkaz úspěšný, karta vrátí ‘ 9000 ’. Protokol byl 
vybrán a inicializován.  
— ‘6A80 ’ označuje nesprávné parametry v datovém poli 
příkazu.  
— ‘6A88 ’ označuje, že data, na která se odkazuje (tj. klí č, 
na který se odkazuje), nejsou k dispozici.  
▼M1 
— Je-li currentAuthenticatedTime karty pozd ější než 
datum skon čení platnosti zvoleného ve řejného klíče, je 
vrácen stav zpracování ’ 6A88 ’. 
Poznámka:  Použije-li se pro ov ěření pravosti celku ve 
vozidle příkaz MSE: SET AT, je klí čem, na který se odka ­
zuje, veřejný klíč VU_MA. Karta nastaví k použití ve řejný 
klíč VU_MA, který odpovídá odkazu na držitele certifikátu 
(CHR) uvedenému v datovém poli p říkazu, pokud jej má 
v paměti (karta dokáže ve řejné klíče VU_MA identifikovat 
pomocí pole CHA certifikátu). Karta na tento p říkaz vrátí 
„6A 88“, pokud je k dispozici pouze ve řejný klíč VU_Sign 
nebo pokud není k dispozici žádný ve řejný klíč celku ve 
vozidle. Viz definice pole CHA v dodatku 11 a datového 
typu equipmentType v dodatku 1.  
Podobně v případě příkazu MSE: SET DST s odkazem na 
EQT (tj. celek ve vozidle nebo kartu) poslaného na 
kontrolní kartu je podle CSM_234 klí čem, na který se 
odkazuje, vždy klí č EQT_Sign, který se musí použít 
k ověření digitálního podpisu. Podle obrázku 13 v dodatku 
11 bude na kontrolní kart ě vždy uložen p říslušný veřejný 
klíč EQT_Sign. V n ěkterých p řípadech m ůže být na 
kontrolní kart ě uložen odpovídající ve řejný klíč EQT_MA. 
Kontrolní karta vždy nastaví k použití ve řejný klíč 
EQT_Sign, když obdrží p říkaz MSE: SET DST.  
▼B 
3.5.12  PSO: HASH  
Tento příkaz slouží k p řenosu výsledku výpo čtu hodnoty hash n ěja­
kých dat na kartu. Tento p říkaz se používá k ov ěření digitálních 
podpisů. Hodnota hash se do časně uloží pro následný p říkaz PSO: 
VERIFY DIGITAL SIGNATURE.  
Tento příkaz je v souladu s normou ISO/IEC 7816-8. Jeho použití je 
ale ve srovnání se související normou omezené.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 226  
Tento příkaz musí podporovat pouze kontrolní karta v DF Tachograph 
a DF Tachograph_G2.  
Ostatní typy karet tachografu mohou, ale nemusí tento p říkaz imple ­
mentovat. P říkaz může, ale nemusí být p řístupný v MF.  
Aplikace kontrolní karty 1. generace podporuje pouze SHA-1.  
TCS_115 Do časně uložená hodnota hash se smaže, pokud je pomocí 
příkazu PSO: HASH vypo čítána nová hodnota hash, pokud 
je zvolen DF a pokud je resetována karta tachografu.  
TCS_116  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Perform Security Operation  
P1 1  ‘90h’  Vrátit hodnotu hash  
P2 1  ‘A0h’  Tag: datové pole obsahuje p říslušné DO pro hašování  
Lc 1  ‘XXh’  Délka Lc následujícího datového pole  
#6 1  ‘90h’  Tag pro hodnotu hash  
#7 1  ‘XXh’  Délka L hodnoty hash: 
‘14h’ v aplikaci 1. generace (viz dodatek 11 část A) 
‘20h’, ‘30h’ nebo ‘40h’ v aplikaci 2. generace (viz 
dodatek 11 část B)  
#8-#(7+L)  L  ‘XX..XXh’  Hodnota hash  
TCS_117  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Chybějí-li některé očekávané datové objekty (jak je 
specifikováno výše), je vrácen stav zpracování ‘ 6987 ’. 
To může nastat, když chybí jeden z tag ů ‘90h’.  
— Jsou-li n ěkteré datové objekty chybné, je vrácen stav 
zpracování ‘ 6988 ’. Tato chyba nastane, když je 
přítomen pot řebný tag, ale s jinou délkou než ‘14h’ 
pro SHA-1, ‘20h’ pro SHA-256, ‘30h’ pro SHA-384, 
‘40h’ pro SHA-512 (aplikace 2. generace).  
3.5.13  PERFORM HASH of FILE  
Tento příkaz není v souladu s normou ISO/IEC 7816-8. Proto bajt 
CLA tohoto p říkazu indikuje proprietární použití p říkazu PERFORM 
SECURITY OPERATION / HASH.  
Tento příkaz musí podporovat jen karta řidiče a karta dílny v DF 
Tachograph a DF Tachograph_G2.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 227  
Ostatní typy karet tachografu mohou, ale nemusí tento p říkaz imple ­
mentovat. Pokud tento p říkaz implementuje karta podniku nebo 
kontrolní karta, je p říkaz implementován podle specifikace v této 
kapitole.  
Příkaz může, ale nemusí být p řístupný v MF. Pokud je p řístupný, je 
implementován podle specifikace v této kapitole, tj. neumožní výpo čet 
hodnoty hash, ale skon čí s vhodným chybovým kódem.  
TCS_118 P říkaz PERFORM HASH OF FILE se používá pro výpo čet 
hodnoty hash datové oblasti aktuáln ě vybraného trans ­
parentního EF.  
TCS_119 Karta tachografu podporuje tento p říkaz pouze pro ty EF, 
které jsou uvedeny v kapitole 4 v rámci DF_Tachograph 
a DF_Tachograph_G2 s následující výjimkou. Karta tacho ­
grafu nepodporuje tento p říkaz pro EF Sensor_Installati ­
on_Data v DF Tachograph_G2.  
TCS_120 Výsledek operace hašování se do časně uloží na kart ě. Poté 
může být použit k získání digitálního podpisu souboru 
pomocí příkazu PSO: COMPUTE DIGITAL SIGNATURE.  
▼M1 
TCS_121 Do časně uložená hodnota hash souboru se smaže, pokud je 
pomocí příkazu PERFORM HASH of FILE vypo čítána 
nová hodnota hash souboru, pokud je zvolen DF a pokud 
je resetována karta tachografu.  
▼B 
TCS_122 Aplikace tachografu 1. generace podporuje algoritmus 
SHA-1.  
▼M1 
TCS_123 Aplikace tachografu 2. generace podporuje algoritmus 
SHA-2 (SHA-256, SHA-384 nebo SHA-512), specifiko ­
vaný sadami šifer v dodatku 11 části B pro podpisový 
klíč karty Card_Sign.  
▼B 
TCS_124  Zpráva s p říkazem  
▼M1 
Bajt Délka  Hodnota  Popis  
CLA  1  ‘80h’  CLA  
INS 1  ‘2Ah’  Provedení bezpe čnostní operace  
P1 1  ‘90h’  Tag: Hash  
P2 1  ‘00h’  Algoritmus je implicitn ě znám. 
Pro aplikaci tachografu 1. generace: SHA-1 
Pro aplikaci tachografu 2. generace: algoritmus SHA-2 
(SHA-256, SHA-384 nebo SHA-512) definovaný sadou 
šifer v dodatku 11 části B pro podpisový klí č karty 
Card_Sign  
▼B 
TCS_125  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Pokud aktuální EF nedovoluje tento p říkaz (EF 
Sensor_Installation_Data v DF Tachograph_G2), je 
vrácen stav zpracování ‘ 6985 ’. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 228  
— Je-li vybraný EF považován za poškozený (chyby inte ­
grity atribut ů souboru nebo uložených dat), je vrácen 
stav zpracování ‘ 6400 ’ nebo ‘ 6581 ’. 
— Pokud zvolený soubor není transparentním souborem 
nebo neexistuje aktuální EF, je vrácen stav zpracování 
‘6986 ’. 
3.5.14  PSO: COMPUTE DIGITAL SIGNATURE  
▼M1 
Tento příkaz se používá pro výpo čet digitálního podpisu d říve vypoč­
tené hodnoty hash (viz PERFORM HASH OF FILE, bod 3.5.13).  
Tento příkaz musí podporovat jen karta řidiče a karta dílny v DF 
Tachograph a DF Tachograph_G2.  
Ostatní typy karet tachografu mohou, ale nemusí tento p říkaz imple ­
mentovat. Pokud jde o aplikaci tachografu 2. generace, mají 
podpisový klí č 2. generace pouze karta řidiče a karta dílny, ostatní 
typy karet nemohou tento p říkaz úspěšně provést a ukon čí jej 
s vhodným chybovým kódem.  
Příkaz může, ale nemusí být p řístupný v MF. Pokud p říkaz v MF 
přístupný není, skon čí vhodným chybovým kódem.  
Tento příkaz je v souladu s normou ISO/IEC 7816-8. Jeho použití je 
ale ve srovnání se související normou omezené.  
▼B 
TCS_126 Tento p říkaz nevypo čítá digitální podpis hodnoty hash 
dříve vypočtené příkazem PSO: HASH.  
TCS_127 K výpo čtu digitálního podpisu se použije soukromý klí č 
karty, který je kart ě implicitně znám.  
TCS_128 Aplikace tachografu 1. generace provede digitální podpis 
s použitím metody dopln ění, která je v souladu s PKCS1 
(podrobnosti viz dodatek 11).  
TCS_129 Aplikace tachografu 2. generace vypo čítá digitální podpis 
na bázi eliptických k řivek (podrobnosti viz dodatek 11).  
TCS_130  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Perform Security Operation  
P1 1  ‘9Eh’  Má být vrácen digitální podpis  
P2 1  ‘9Ah’  Tag: datové pole obsahuje data k podpisu. Jelikož žádné 
datové pole není zahrnuto, o čekává se, že data jsou již na 
kartě (hash souboru).  
Le 1  ‘NNh’  Délka o čekávaného podpisu  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 229  
TCS_131  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
#1-#L  L  ‘XX..XXh’  Podpis d říve vypočítané hodnoty hash  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Jestliže se implicitn ě vybraný soukromý klí č považuje 
za poškozený, je vrácen stav zpracování ‘ 6400 ’ nebo 
‘6581 ’. 
— Není-li k dispozici hodnota hash vypo čítaná před­
chozím příkazem PERFORM HASH OF FILE, je 
vrácen stav zpracování ‘ 6985 ’. 
3.5.15  PSO: VERIFY DIGITAL SIGNATURE  
Tento příkaz se používá k ov ěření digitálního podpisu poskytnutého 
jako vstup, jehož hodnota hash je kart ě známa. Algoritmus podpisu je 
kartě implicitně znám.  
Tento příkaz je v souladu s normou ISO/IEC 7816-8. Jeho použití je 
ale ve srovnání se související normou omezené.  
Tento příkaz musí podporovat pouze kontrolní karta v DF Tachograph 
a DF Tachograph_G2.  
Ostatní typy karet tachografu mohou, ale nemusí tento p říkaz imple ­
mentovat. P říkaz může, ale nemusí být p řístupný v MF.  
TCS_132 P říkaz VERIFY DIGITAL SIGNATURE vždy používá 
veřejný klíč vybraný p ředchozím p říkazem MANAGE 
SECURITY ENVIRONMENT MSE: Set DST a p ředchozí 
hodnotu hash vloženou p říkazem PSO: HASH.  
TCS_133  Zpráva s p říkazem  
▼M1 
Bajt Délka  Hodnota  Popis  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Provedení bezpe čnostní operace  
P1 1  ‘00h’  
P2 1  ‘A8h’  Tag: datové pole obsahuje datové objekty relevantní pro 
ověření 
Lc 1  ‘XXh’  Délka Lc následujícího datového pole  
#6 1  ‘9Eh’  Tag pro digitální podpis  
#7 nebo 
#7-#8  L ‘NNh’ nebo 
‘81 NNh’  Délka digitálního podpisu (L je 2 bajty, pokud je digi ­
tální podpis delší než 127 bajt ů): 
128 bajtů kódovaných podle dodatku 11 části A pro 
aplikaci tachografu 1. generace 
v závislosti na zvolené k řivce pro aplikaci tachografu 2. 
generace (viz dodatek 11 část B).  
#(7+L)- 
#(6+L+NN)  NN ‘XX..XXh’  Obsah digitálního podpisu  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 230  
TCS_134  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— Jestliže se ov ěření podpisu nezda ří, je vrácen stav zpra ­
cování ‘ 6688 ’. Postup ov ěření je popsán v dodatku 11.  
— Jestliže není vybrán žádný ve řejný klíč, je vrácen stav 
zpracování ‘ 6A88 ’. 
— Chybějí-li některé očekávané datové objekty (jak je 
specifikováno výše), je vrácen stav zpracování ‘ 6987 ’. 
To může nastat, když chybí jeden z požadovaných tag ů. 
— Jestliže není k dispozici žádná hodnota hash pro zpra ­
cování příkazu (jako výsledek p ředchozího p říkazu 
PSO: HASH), je vrácen stav zpracování ‘ 6985 ’. 
— Jsou-li n ěkteré datové objekty chybné, je vrácen stav 
zpracování ‘ 6988 ’. To může nastat, když je chybná 
délka jednoho z požadovaných datových objekt ů. 
— Je-li vybraný ve řejný klíč považován za poškozený, je 
vrácen stav zpracování ‘ 6400 ’ nebo ‘ 6581 ’. 
▼M1 
— Jestliže vybraný ve řejný klíč (použitý k ov ěření digitál­
ního podpisu) má CHA.LSB (CertificateHolderAuthori ­
sation.equipmentType), který není vhodný pro ov ěření 
digitálního podpisu podle dodatku 11, je vrácen stav 
zpracování ‘ 6985 ’. 
▼B 
3.5.16  PROCESS DSRC MESSAGE  
Tento příkaz se používá k ov ěření integrity a pravosti zprávy DSRC 
a pro dešifrování dat p ředaných z celku ve vozidle kontrolnímu 
orgánu nebo díln ě pomocí spojení DSRC. Karta odvodí šifrovací 
klíč a klíč MAC používané pro zabezpe čení zprávy DSRC podle 
dodatku 11 části B kapitoly 13.  
Tento příkaz musí podporovat pouze kontrolní karta a karta dílny 
v DF Tachograph_G2.  
Ostatní typy karet tachografu mohou, ale nemusí tento p říkaz imple ­
mentovat, ale nemají hlavní klí č DSRC. Proto tyto karty nemohou 
příkaz úspěšně provést, ale ukon čí jej s vhodným chybovým kódem.  
Příkaz může, ale nemusí být p řístupný v MF a/nebo DF Tachograph. 
Pokud je p řístupný, skon čí s vhodným chybovým kódem.  
TCS_135 Hlavní klí č DSRC je p řístupný pouze v DF Tacho ­
graph_G2, tj. kontrolní karta a karta dílny podporují 
úspěšné provedení p říkazu pouze v DF Tachograph_G2.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 231  
TCS_136 P říkaz pouze dešifruje data DSRC a ov ěřuje kryptografický 
kontrolní sou čet, ale neinterpretuje vstupní data.  
TCS_137 Po řadí datových objekt ů v datovém poli p říkazu je ur čeno 
touto specifikací.  
TCS_138  Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘80h’  Proprietární CLA  
INS 1  ‘2Ah’  Perform Security Operation  
P1 1  ‘80h’  Data odpov ědi: otevřená hodnota  
P2 1  ‘B0h’  Data p říkazu: otev řená hodnota v kódování BER-TLV 
a včetně datových objekt ů bezpečného předávání zpráv  
Lc 1  ‘NNh’  Délka Lc následujícího datového pole  
#6-#(5+L)  L  ‘87h’ + L  87 + 
‘XX..XXh’  Bajt indikující obsah dopln ění v kódování DER-TLV 
následovaný šifrovanými p řenášenými daty tachografu. 
Pro bajt indikující obsah dopln ění se používá hodnota 
‘00h’ („žádná další indikace“ podle ISO/IEC 7816- 
4:2013 tabulky 52). Mechanismus šifrování viz dodatek 
11 část B kapitolu 13. 
Povolené hodnoty délky L  87 jsou násobky délky bloku 
AES plus 1 pro bajt indikující obsah dopln ění, tj. od 17 
bajtů do 193 bajt ů včetně. 
Poznámka:  Datový objekt bezpe čného předávání zpráv 
s tagem ‘87h’ viz ISO/IEC 7816-4:2013 tabulka 49.  
‘81h’ + ‘10h’  Šablona řídicích odkaz ů pro důvěrnost v kódování DER- 
TLV, která obsahuje z řetězení následujících datový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.  
▼M1 
5 + L + 1  1  ‘00h’  Podle specifikace v ISO/IEC 7816-4  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 232  
TCS_139  Zpráva s odpov ědí 
Bajt Délka  Hodnota  Popis  
#1-#L  L  ‘XX..XXh’  Chybí (v p řípadě chyby) nebo dešifrovaná data (dopln ění 
odstraněno) 
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li příkaz úspěšný, karta vrátí ‘ 9000 ’. 
— ‘6A80 ’ označuje nesprávné parametry v datovém poli 
příkazu (používá se rovn ěž v případě, že datové objekty 
nejsou odeslány ve stanoveném po řadí). 
— ‘6A88 ’ označuje, že data, na která se odkazuje, tj. 
hlavní klíč DSRC, nejsou k dispozici.  
— ‘6900 ’ označuje, že se nezda řilo ověření kryptografic ­
kého kontrolního sou čtu nebo dešifrování dat.  
▼M1 
— ‘6985 ’ označuje, že časové razítko (4 bajty) uvedené 
v datovém poli p říkazu je dřívější než hodnota cardVa ­
lidityBegin nebo pozd ější než hodnota cardExpiryDate.  
▼B 
4. STRUKTURA KARET TACHOGRAFU  
V tomto odstavci jsou specifikovány struktury soubor ů, které slouží 
pro uložení p řístupných dat na kartách tachografu.  
Nejsou specifikovány vnit řní struktury závislé na výrobci karty, 
jako například hlavi čky soubor ů, ani ukládání a zpracování 
datových prvk ů potřebných pouze pro interní použití, nap říklad
  
,
 ,
  
nebo
  .  
TCS_140 Na kart ě tachografu 2. generace je uložen hlavní soubor 
(MF) a aplikace tachografu stejného typu (nap ř. aplikace 
karty řidiče) 1. generace a 2. generace.  
TCS_141 Karta tachografu musí podporovat alespo ň minimální po čet 
záznamů specifikovaný pro p říslušné aplikace a nesmí 
podporovat více záznam ů než maximální po čet specifiko ­
vaný pro p říslušné aplikace.  
Maximální a minimální po čty záznamů jsou pro r ůzné apli­
kace specifikovány v této kapitole.  
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 — 26.02.2020 — 002.001 — 233  
4.1 Hlavní soubor MF  
TCS_142 Po personalizaci má hlavní soubor MF následující trvalou 
strukturu soubor ů a pravidla p řístupu k soubor ům: 
Poznámka:  Krátký identifikátor EF SFID je uvád ěn jako 
číslo v desítkové soustav ě, tj. hodnota 30 odpovídá binární 
hodnotě 11110.
  
V této tabulce je použita tato zkratka pro bezpe čnostní 
podmínku:  
SC1 ALW OR SM-MAC-G2  
TCS_143 Všechny struktury EF jsou transparentní.  
TCS_144 Hlavní soubor MF má tuto strukturu dat:
  
TCS_145 Elementární soubor EF DIR obsahuje tyto datové objekty 
týkající se aplikace: ‘61 08 4F 06 FF 54 41 43 48 4F 61 08 
4F 06 FF 53 4D 52 44 54’  
TCS_146 Elementární soubor EF ATR/INFO je p řítomen, pokud 
karta tachografu v ATR uvádí, že podporuje rozší řená 
pole délky. V tomto p řípadě EF ATR/INFO obsahuje 
datový objekt s informací o rozší řené délce (DO‘7F66’), 
jak je uvedeno v ISO/IEC 7816-4:2013 bod ě 12.7.1.  
TCS_147 Elementární soubor EF Extended_Length je p řítomen, 
pokud karta tachografu v ATR uvádí, že podporuje rozší ­ 
řená pole délky. V tomto p řípadě tento EF obsahuje tento 
datový objekt: ‘02 01 xx’, kde hodnota ‘xx’ ozna čuje, zda 
jsou rozšířená pole délky podporována pro protokol T = 1 
a/nebo T = 0.  
Hodnota ‘01’ ozna čuje, že rozší řená pole délky jsou 
podporována pro protokol T = 1.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 234  
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 soubo ­
rům:
 
V této tabulce jsou použity tyto zkratky pro bezpe čnostní 
podmínky:  
SC1 ALW OR SM-MAC-G2  
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2  
SC3 SM-MAC-G1 OR SM-MAC-G2  
TCS_149 Všechny struktury EF jsou transparentní.  
TCS_150 Aplikace karty řidiče 1. generace musí mít tuto strukturu 
dat: ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 235
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 236
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 237  
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  
TCS_152 Po personalizaci má aplikace karty řidiče 2. generace násle ­
dující trvalou strukturu soubor ů a pravidla p řístupu k soubo ­
rů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_153 Všechny struktury EF jsou transparentní.  
TCS_154 Aplikace karty řidiče 2. generace musí mít tuto strukturu 
dat: ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 238
  
► (1) M1 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 239
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 240
  
► (1) M1 
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:
  
► (1) M1 
4.3 Aplikace karty dílny  
4.3.1  Aplikace karty dílny 1. generace  
TCS_156 Po personalizaci musí mít aplikace karty dílny 1. generace 
následující trvalou strukturu soubor ů a pravidla p řístupu 
k souborům: ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 241
  
V této tabulce jsou použity tyto zkratky pro bezpe čnostní 
podmínky:  
SC1 ALW OR SM-MAC-G2  
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2  
SC3 SM-MAC-G1 OR SM-MAC-G2  
▼M1 
SC4 Pro příkaz READ BINARY se sudým bajtem INS:  
(SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR  
(SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)  
Pro příkaz READ BINARY s lichým bajtem INS 
(je-li podporován): NEV  
▼B 
TCS_157 Všechny struktury EF jsou transparentní.  
TCS_158 Aplikace karty dílny 1. generace musí mít tuto strukturu 
dat: ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 242
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 243
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 244
  
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  
TCS_160 Po personalizaci musí mít aplikace karty dílny 2. generace 
následující trvalou strukturu soubor ů a pravidla p řístupu 
k souborům: 
Pozná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.
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 245  
V této tabulce jsou použity tyto zkratky pro bezpe čnostní 
podmínky:  
SC1 ALW OR SM-MAC-G2  
SC5 Pro příkaz READ BINARY se sudým bajtem INS: 
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  
TCS_161 Všechny struktury EF jsou transparentní.  
TCS_162 Aplikace karty dílny 2. generace musí mít tuto strukturu 
dat:
 
► (1) (2) M1 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 246
  
► (1) M1 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 247
  
► (1) M1 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 248  
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:
  
► (1) M1 
4.4 Aplikace kontrolní karty  
4.4.1  Aplikace kontrolní karty 1. generace  
TCS_164 Po personalizaci musí mít aplikace kontrolní karty 1. gene ­
race následující trvalou strukturu soubor ů a pravidla 
přístupu k soubor ům:
 
V této tabulce jsou použity tyto zkratky pro bezpe čnostní 
podmínky:  
SC1 ALW OR SM-MAC-G2  
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2  
SC3 SM-MAC-G1 OR SM-MAC-G2  
SC6 EXT-AUT-G1 OR SM-MAC-G1 OR SM-MAC-G2  
TCS_165 Všechny struktury EF jsou transparentní.  
TCS_166 Aplikace kontrolní karty 1. generace musí mít tuto struk ­
turu dat:  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 249
  
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  
TCS_168 Po personalizaci musí mít aplikace kontrolní karty 2. gene ­
race následující trvalou strukturu soubor ů a pravidla 
přístupu k soubor ům: 
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 250
  
V této tabulce je použita tato zkratka pro bezpe čnostní 
podmínku:  
SC1 ALW OR SM-MAC-G2  
TCS_169 Všechny struktury EF jsou transparentní.  
TCS_170 Aplikace kontrolní karty 2. generace musí mít tuto struk ­
turu dat:
  
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:  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 251
  
4.5 Aplikace karty podniku  
4.5.1  Aplikace karty podniku 1. generace  
TCS_172 Po personalizaci musí mít aplikace karty podniku 1. gene ­
race následující trvalou strukturu soubor ů a pravidla 
přístupu k soubor ům:
 
V této tabulce jsou použity tyto zkratky pro bezpe čnostní 
podmínky:  
SC1 ALW OR SM-MAC-G2  
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2  
SC3 SM-MAC-G1 OR SM-MAC-G2  
SC6 EXT-AUT-G1 OR SM-MAC-G1 OR SM-MAC-G2  
TCS_173 Všechny struktury EF jsou transparentní.  
TCS_174 Aplikace karty podniku 1. generace musí mít tuto strukturu 
dat:
 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 252  
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  
TCS_176 Po personalizaci musí mít aplikace karty podniku 2. gene ­
race následující trvalou strukturu soubor ů a pravidla 
přístupu k soubor ům: 
Pozná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_177 Všechny struktury EF jsou transparentní.  
TCS_178 Aplikace karty podniku 2. generace musí mít tuto strukturu 
dat:
 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 253  
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
  ▼B
02016R0799 — CS — 26.02.2020 — 002.001 — 254 
Dodatek 3  
PIKTOGRAMY 
PIC_001 Tachograf může voliteln ě používat tyto piktogramy a jejich kombi ­
nace (nebo piktogramy a jejich kombinace dostate čně podobné, aby je 
bylo možno jednozna čně ztotožnit s t ěmito):  
1. ZÁKLADNÍ PIKTOGRAMY
Osoby Akce Provozní režimy
  
podnik podnikový režim
  
kontrolor kontrola kontrolní režim
  
řidič řízení provozní režim
  
dílna/zkušebna kontrola/kalibrace kalibrační re žim
  
výrobce 
Činnosti Doba trvání
  
pohotovost stávající doba pohotovosti
  
řízení nepřetr žitá doba řízení
  
odpočinek stávající doba odpočinku
 
jiná práce stávající pracovní doba
  
přestávka souhrnná doba přestávek
  
neznámá  
Zařízení Funkce
  
otvor pro kartu řidiče
 
otvor pro kartu druhého řidiče
 
karta
  
hodiny
  
displej zobrazení
  
externí pam ěťové médium  stahování
  
napájení
  
tiskárna/výtisk tisk
 
snímač
 
rozměr pneumatik
  
vozidlo / celek ve vozidle
  
zařízení GNSS
  
zařízení pro dálkové odhalování
  
rozhraní ITS  ▼B
02016R0799 — CS — 26.02.2020 — 002.001 — 255 
Zvláštní podmínky
  
mimo působnost
  
převoz lodí / p řevoz vlakem  
Různé
 
události
 závady
  
začátek denní pracovní doby
 konec denní pracovní doby
  
místo
  
ruční zadání činností řidiče
 
zabezpečení
 
rychlost
  
čas
 
celkem/souhrn  
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 
Karty
  
karta řidiče
 
karta podniku
  
kontrolní karta
  
karta dílny
  
žádná karta  ▼B
02016R0799 — CS — 26.02.2020 — 002.001 — 256 
Ří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  
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í 
▼M1
č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  
▼B
Závady
  
závada karty (otvor pro kartu řidiče)
 
závada karty (otvor pro kartu druhého řidiče)
 
závada displeje  ▼B
02016R0799 — CS — 26.02.2020 — 002.001 — 257 
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 258  
Dodatek 4  
VÝTISKY  
OBSAH  
1. VŠEOBECNÉ  
2. SPECIFIKACE DATOVÝCH BLOK Ů 
3. SPECIFIKACE VÝTISK Ů 
3.1 Denní výtisk činností řidiče z karty  
3.2 Denní výtisk činností řidiče z VU  
3.3 Výtisk událostí a závad z karty  
3.4 Výtisk událostí a závad z VU  
3.5 Výtisk technických dat  
3.6 Výtisk p řekročení povolené rychlosti  
3.7 Historie vložených karet  
1. VŠEOBECNÉ  
Každý výtisk je tvo řen zřetězením různých datových blok ů, které 
mohou být identifikovány identifikátorem bloku.  
Datový blok obsahuje jeden nebo více záznam ů, které mohou být iden ­
tifikovány identifikátorem záznamu.  
PRT_001 Pokud identifikátor bloku bezprost ředně předchází identifiká ­
toru záznamu, identifikátor záznamu se netiskne.  
PRT_002 Není-li n ěkterá datová položka známa nebo nesmí být vytiš ­
těna z důvodu přístupových práv k údaj ům, vytisknou se 
místo ní mezery.  
PRT_003 Není-li znám obsah celé řádky nebo není t řeba jej tisknout, 
vynechá se celá řádka.  
PRT_004 Číselná datová pole se tisknou zarovnaná doprava, s mezerou 
jako oddělovačem tisíců a milionů a bez nul na za čátku.  
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).  
PRT_006 V p řípadě zalomení řádky z důvodu dlouhého textu se jako 
první znak na nové řádce vytiskne zvláštní znak (te čka upro­
střed výšky řádky – „•“).  
2. SPECIFIKACE DATOVÝCH BLOK Ů 
V této kapitole je použita následující konvence, pokud jde o formát:  
— znaky vytišt ěné tučně označují prostý text k vytišt ění (tiskne se 
normálními znaky),  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 259  
— normální znaky ozna čují proměnné (piktogramy nebo data), které se 
při tisku nahradí svými hodnotami,  
— názvy prom ěnných jsou dopln ěny podtržítky, aby se znázornila 
délka datové položky, která je pro prom ěnnou k dispozici,  
— datum se uvádí ve formátu „dd/mm/yyyy“ (den/m ěsíc/rok). Smí se 
použít i formát „dd.mm.yyyy“,  
— termín „identifikace karty“ ozna čuje posloupnost: typu karty znázor ­
něného kombinací piktogram ů karty, kódu členského státu vydáva ­
jícího kartu, znaku lomítka a čísla karty s indexem náhrady 
a indexem obnovy odd ělenými mezerami: 
P
 x  x  x  / x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x
 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 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 260  
PRT_007 Ve výtiscích se používají následující datové bloky a/nebo datové 
záznamy v souladu s následujícími významy a formáty:
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 261
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 262
  
► (1) (2) M1 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 263
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 264
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 265
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 266
  
3. SPECIFIKACE VÝTISK Ů 
V této kapitole je použita následující konvence: 
N Tisk bloku nebo záznamu s číslem N  
N Tisk bloku nebo záznamu s číslem N tolikrát, kolikrát je t řeba 
X/Y Tisk bloků nebo záznam ů X a/nebo Y dle pot řeby a tolikrát, kolikrát 
je třeba 
3.1 Denní výtisk činností řidiče z karty  
PRT_008 Denní výtisk činností řidiče z karty musí mít následující 
formát: 
1 Datum a čas vytištění dokumentu  
2 Typ výtisku  
3 Identifikace kontrolora (pokud je do VU vložena kontrolní karta)  
3 Identifikace řidiče (z karty, pro kterou se výtisk po řizuje, + GEN)  
4 Identifikace vozidla (z n ějž se výtisk po řizuje)  
5 Identifikace VU (VU, z n ějž se výtisk po řizuje, + GEN)  
6 Poslední kalibrace tohoto VU  
7 Poslední kontrola, které byl kontrolovaný řidič podroben  
8 Oddělovač činností řidiče 
8a Na začátku tohoto dne platila podmínka „mimo p ůsobnost“  
8.1a / 8.1b / 8.1c / 8.2 / 
8.3 / 8.3a / 8.4  Činnosti řidiče v pořadí, v jakém k nim došlo  
11 Oddělovač denního souhrnu  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 267  
11.4 Zadaná místa v chronologickém po řadí 
▼M1 
11.5 Polohy po t řech hodinách sou čtové doby řízení v chronologickém 
pořadí 
▼B 
11.6 Celkové doby trvání činností  
12.1 Oddělovač událostí nebo závad z karty  
12.4 Záznamy událostí/závad (posledních 5 událostí nebo závad uložených 
na kartě) 
13.1 Oddělovač událostí nebo závad z VU  
13.4 Záznamy událostí/závad (posledních 5 událostí nebo závad uložených 
nebo probíhajících ve VU)  
22.1 Místo kontroly  
22.2 Podpis kontrolora  
22.5 Podpis řidiče 
3.2 Denní výtisk činností řidiče z VU  
PRT_009 Denní výtisk činností řidiče z VU musí mít následující 
formát:  
▼M1 
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)  
5 Identifikace VU (VU, z n ějž se výtisk po řizuje, + GEN)  
6 Poslední kalibrace tohoto VU  
7 Poslední kontrola tohoto tachografu  
9 Oddělovač činností řidiče 
10 Oddělovač otvoru pro kartu řidiče (otvor č. 1) 
10a Na začátku tohoto dne platila podmínka „mimo p ůsobnost“  
10.1 / 10.2 / 10.3 / 
10.3a / 10.4  Činnosti v chronologickém po řadí (otvor pro kartu řidiče) 
10 Oddělovač otvoru pro kartu druhého řidiče (otvor č. 2) 
10a Na začátku tohoto dne platila podmínka „mimo p ůsobnost“  
10.1 / 10.2 / 
10.3 / 10.3a / 10.4  Činnosti v chronologickém po řadí (otvor pro kartu druhého 
řidiče) 
11 Oddělovač denního souhrnu  
11.1 Souhrn dob bez karty v otvoru pro kartu řidiče ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 268  
11.4 Zadaná místa v chronologickém po řadí 
11.5 Polohy po t řech hodinách sou čtové doby řízení v chronolo ­
gickém po řadí 
11.7 Celkové doby trvání činností  
11.2 Souhrn dob bez karty v otvoru pro kartu druhého řidiče 
11.4 Zadaná místa v chronologickém po řadí 
11.5 Polohy po t řech hodinách sou čtové doby řízení v chronolo ­
gickém po řadí 
11.8 Celkové doby trvání činností  
11.3 Souhrn činností řidiče při zahrnutí obou otvor ů pro kartu  
11.4 Místa zadaná tímto řidičem v chronologickém po řadí 
11.5 Polohy po t řech hodinách sou čtové doby řízení v chronolo ­
gickém po řadí 
11.9 Celkové doby trvání činností tohoto řidiče 
13.1 Oddělovač událostí a závad  
13.4 Záznamy událostí/závad (posledních 5 událostí nebo závad 
uložených nebo probíhajících ve VU)  
22.1 Místo kontroly  
22.2 Podpis kontrolora  
22.3 Čas začátku (místo, kde m ůže řidič bez karty uvést,  
22.4 Čas konce která období se ho týkají)  
22.5 Podpis řidiče 
▼B 
3.3 Výtisk událostí a závad z karty  
PRT_010 Výtisk událostí a závad z karty musí mít následující formát: 
1 Datum a čas vytištění dokumentu  
2 Typ výtisku  
3 Identifikace kontrolora (pokud je do VU vložena kontrolní karta, + 
GEN)  
3 Identifikace řidiče (z karty, které se výtisk týká)  
4 Identifikace vozidla (z n ějž se výtisk po řizuje)  
12.2 Oddělovač událostí  
12.4 Záznamy událostí (všechny události uložené na kart ě) 
12.3 Oddělovač závad  
12.4 Záznamy závad (všechny závady uložené na kart ě) 
22.1 Místo kontroly  
22.2 Podpis kontrolora  
22.5 Podpis řidiče ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 269  
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 
3.5 Výtisk technických dat  
PRT_012 Výpis technických dat 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)  
14 Identifikace VU  
15 Identifikace sníma če 
15.1 Údaje o párování sníma čů (všechny dostupné údaje v chronologickém 
pořadí) 
16 Identifikace GNSS  
16.1 Údaje o vazb ě s vnějším zařízením GNSS (všechny dostupné údaje 
v chronologickém po řadí) 
17 Oddělovač kalibračních údajů 
17.1 Záznamy o kalibraci (všechny dostupné záznamy v chronologickém 
pořadí) 
18 Oddělovač nastavení času 
18.1 Záznamy o nastavení času (všechny dostupné záznamy z nastavení 
času a ze záznam ů kalibračních údajů) 
19 Nejnovější událost a závada zaznamenané ve VU  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 270  
3.6 Výtisk p řekročení povolené rychlosti  
PRT_013 Výtisk p řekročení povolené rychlosti musí mít následující 
formát: 
1 Datum a čas vytištění dokumentu  
2 Typ výtisku  
3 Identifikace držitele karty (pro všechny karty vložené do VU, + GEN)  
4 Identifikace vozidla (z n ějž se výtisk po řizuje)  
20 Informace o kontrole p řekročení povolené rychlosti  
21.1 Identifikátor údaj ů o překročení povolené rychlosti  
21.4 / 21.5  První překročení povolené rychlosti po poslední kalibraci  
21.2 Identifikátor údaj ů o překročení povolené rychlosti  
21.4 / 21.5  5 nejzávažn ějších překročení povolené rychlosti za posledních 365 
dnů 
21.3 Identifikátor údaj ů o překročení povolené rychlosti  
21.4 / 21.5  Nejzávažnější překročení povolené rychlosti v každém z posledních 
10 dnů výskytu  
22.1 Místo kontroly  
22.2 Podpis kontrolora  
22.5 Podpis řidiče 
3.7 Historie vložených karet  
▼M1 
PRT_014 Výtisk historie vložených karet musí mít následující formát: 
1 Datum a čas vytištění dokumentu  
2 Typ výtisku  
3 Identifikace držitel ů karty (pro všechny karty vložené do VU)  
23 Karta naposledy vložená do VU  
23.1 Vložené karty (až 88 záznam ů) 
12.3 Oddělovač závad  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 271  
Dodatek 5  
ZOBRAZENÍ  
V tomto dodatku je použita tato konvence, pokud jde o formát:  
— znaky vytišt ěné tučně znamenají prostý text, který se má zobrazit (zobrazí se 
normálními znaky),  
— normální znaky ozna čují proměnné (piktogramy nebo údaje), které se p ři 
zobrazení nahradí svými hodnotami,  
— dd mm yyyy: den, m ěsíc, rok,  
— hh: hodiny,  
— mm: minuty,  
— D: piktogram doby trvání,  
— EF: kombinace piktogram ů události nebo závady,  
— O: piktogram provozního režimu.  
DIS_001 Tachograf zobrazuje data na displeji v následujících formátech:  
Údaje  Formát  
Výchozí zobrazení  
Místní čas
 
Provozní režim
  
Informace o řidiči
 
Informace o druhém řidiči
 
Otevřená podmínka „mimo p ůsobnost“
  
Varovné zobrazení  
Překročení nepřetržité doby řízení
  
Událost nebo závada
  
Další zobrazení  
Datum v UTC
  
čas 
Nepřetržitá doba řízení a souhrnná doba p řestávek – řidič
 
Nepřetržitá doba řízení a souhrnná doba p řestávek – druhý 
řidič
 
Souhrnná doba řízení za předchozí a aktuální týden – řidič
 
Souhrnná doba řízení za předchozí a aktuální týden – druhý 
řidič
 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 272  
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 — 26.02.2020 — 002.001 — 273  
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 — 26.02.2020 — 002.001 — 274  
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 — 26.02.2020 — 002.001 — 275  
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é specifi ­
kace:  
Parametr  Minimum  Typická hodnota  Maximum  Poznámka  
U low (in) 1,0 V  I = 750 μA 
U high (in) 4 V  I = 200 μA 
Frekvence  4 kHz  
U low (out)  1,0 V  I = 1 mA  
U high (out)  4 V  I = 1 mA  
INT_009 Vstupní/výstupní signál musí spl ňovat tyto časové diagramy:
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 276  
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 — 26.02.2020 — 002.001 — 277  
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í 
2.2.6.1 Positive Response Transfer Data Overview  
2.2.6.2 Positive Response Transfer Data Activities  
2.2.6.3 Positive Response Transfer Data Events and Faults  
2.2.6.4 Positive Response Transfer Data Detailed Speed  
2.2.6.5 Positive Response Transfer Data Technical Data  
2.3 Ukládání soubor ů na externí pam ěťové médium  
3. PROTOKOL PRO STAHOVÁNÍ DAT Z KARET TACHOGRAFU  
3.1 Oblast p ůsobnosti  
3.2 Definice  
3.3 Stahování z karty  
3.3.1 Inicializa ční sekvence  
3.3.2 Sekvence pro nepodepsané datové soubory  
3.3.3 Sekvence pro podepsané datové soubory  
3.3.4 Sekvence pro reset po čítadla kalibrací  
3.4 Formát uložených dat  
3.4.1 Úvod  
3.4.2 Formát souboru  
4. STAHOVÁNÍ Z KARTY TACHOGRAFU P ŘES JEDNOTKU VE 
VOZIDLE  
1. ÚVOD  
Tento dodatek ur čuje postupy pro stahování r ůzných typ ů dat na 
externí pam ěťové médium a protokoly, které je nutno implementovat 
k zajištění správného p řenosu dat a plné slu čitelnosti formátu stažených 
dat, aby kterýkoli kontrolor mohl tato data prov ěřit a před jejich 
analýzou zkontrolovat jejich pravost a integritu.  
▼M1 
1.1 Oblast p ůsobnosti  
Data mohou být stažena na externí pam ěťové médium:  
— z celku ve vozidle inteligentním vyhrazeným za řízením (IDE) 
připojeným k celku ve vozidle,  
— z karty tachografu pomocí IDE vybaveného kartovým rozhraním 
(IFD),  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 278  
— z karty tachografu prost řednictvím celku ve vozidle pomocí IDE 
připojeného k celku ve vozidle.  
Aby bylo možné zkontrolovat pravost a integritu stažených dat ulože ­
ných na externí pam ěťové médium, stahují se data s p řipojeným 
podpisem v souladu s dodatkem 11 „Spole čné bezpečnostní mechanis ­
my“. Rovn ěž se stahuje identifikace zdrojového za řízení (VU nebo 
karty) a jeho bezpe čnostní certifikáty ( členského státu a za řízení). 
Ověřovatel dat musí mít nezávisle získaný d ůvěryhodný evropský 
veřejný klíč. 
Data stažená z celku ve vozidle se opat ří podpisem v souladu 
s dodatkem 11 „Spole čné bezpečnostní mechanismy“ částí B („Systém 
tachografu druhé generace“), vyjma p řípadů, kdy kontrolu řidičů 
provádí kontrolní orgán, který nepat ří do EU, za použití kontrolní 
karty první generace a kdy se data opat ří podpisem v souladu 
dodatkem 11 „Spole čné bezpečnostní mechanismy“ částí A („Systém 
tachografu první generace“), v souladu s dodatkem 15 Migrace poža ­
davkem MIG_015.  
Tento dodatek tudíž stanoví dva typy stahování dat z celku ve vozidle:  
— stahování dat z celku ve vozidle typu 2. generace, poskytující 
datovou strukturu 2. generace a opat řené podpisem v souladu 
s dodatkem 11 „Spole čné bezpečnostní mechanismy“ částí B,  
— stahování dat z celku ve vozidle typu 1. generace, poskytující 
datovou strukturu 1. generace a opat řené podpisem v souladu 
s dodatkem 11 „Spole čné bezpečnostní mechanismy“ částí A.  
Podobně existují dva typy stahování dat z karet řidiče druhé generace 
vložených do celku ve vozidle, jak je uvedeno v bodech 3 a 4 tohoto 
dodatku.  
▼B 
1.2 Zkratky a notace  
V tomto dodatku jsou použity následující zkratky:  
AID identifikátor aplikace ( Application Identifier ) 
ATR  odpověď na reset ( Answer To Reset ) 
CS bajt kontrolního sou čtu (Checksum byte ) 
DF vyhrazený soubor ( Dedicated File ) 
DS_ diagnostická relace ( Diagnostic Session ) 
EF elementární soubor ( Elementary File ) 
ESM  externí pam ěťové médium ( External Storage Medium ) 
FID identifikátor souboru ( File ID ) 
FMT  bajt formátu (první bajt hlavi čky zprávy) ( Format Byte ) 
ICC karta s integrovaným obvodem, čipová karta ( Integrated 
Circuit Card ) 
IDE inteligentní vyhrazené za řízení ( Intelligent Dedicated Equip ­
ment ): zařízení používané pro stahování dat na ESM (nap ř. 
osobní počítač) 
IFD zařízení rozhraní ( Interface Device ) 
KWP  protokol KWP 2000 ( Keyword Protocol 2000 ) 
LEN  bajt délky (poslední bajt hlavi čky zprávy)  
PPS volba parametr ů protokolu ( Protocol Parameter Selection ) 
PSO  provedení bezpe čnostní operace ( Perform Security Operation ) 
SID identifikátor služby ( Service Identifier ) 
SRC  bajt zdroje ( Source byte ) 
TGT  bajt cíle ( Target byte ) ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 279  
TLV  tag, délka, hodnota ( Tag Length Value ) 
TREP  parametr odpov ědi na požadavek na p řenos ( Transfer Response 
Parameter ) 
TRTP  parametr požadavku na p řenos ( Transfer Request Parameter ) 
VU celek ve vozidle ( Vehicle Unit ) 
2. STAHOVÁNÍ DAT Z CELKU VE VOZIDLE  
2.1 Postup stahování  
Ke stažení dat z VU musí operátor provést následující operace:  
— vsunout svou kartu tachografu do otvoru pro kartu v celku ve 
vozidle (*),  
— připojit IDE ke konektoru VU pro stahování,  
— navázat spojení mezi IDE a VU,  
— vybrat v IDE data, která se mají stáhnout, a odeslat požadavek do 
VU, 
— uzavřít relaci stahování.  
2.2 Protokol pro stahování dat  
Protokol používá strukturu „master-slave“ s IDE jako nad řízeným 
zařízením a VU jako pod řízeným zařízením.  
Struktura, typy a tok zpráv jsou v zásad ě založeny na protokolu KWP 
2000 (ISO 14230-2  Road vehicles – Diagnostic systems – Keyword 
protocol 2000 – Part 2: Data link layer ). 
Aplikační vrstva je v zásad ě založena na aktuálním návrhu ISO 14229- 
1 (Road vehicles – Diagnostic systems – Part 1: Diagnostic services, 
version 6 of 22 February 2001 ). 
2.2.1  Struktura zpráv  
DDP_002 Všechny zprávy vym ěňované mezi IDE a VU mají formát 
struktury sestávající ze t ří částí: 
— hlavičky složené z bajtu formátu (FMT), bajtu cíle 
(TGT), bajtu zdroje (SRC) a v p říslušných p řípadech 
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 diagnostické 
relace (DS_) nebo volitelný bajt parametru p řenosu 
(TRTP nebo TREP),  
— kontrolního sou čtu tvořeného bajtem kontrolního sou čtu 
(CS).  
Hlavička Datové pole  Kontrolní sou čet 
FMT  TGT  SRC  LEN  SID  DATA  …  …  …  CS  
4 bajty  Max. 255 bajt ů 1 bajt  
Bajty TGT a SRC p ředstavují fyzickou adresu p říjemce 
a původce zprávy. Hodnoty jsou F0 hex pro IDE a EE 
hex pro VU.  
Bajt LEN je délka datového pole.  ▼B 
(*) Vložená karta aktivuje p říslušná přístupová práva k funkci stahování a k dat ům. Musí 
být nicmén ě možné stáhnout data z karty řidiče vložené do jednoho z otvor ů pro kartu 
ve VU, i když v druhém otvoru pro kartu není vložena žádná karta.
 02016R0799 — CS — 26.02.2020 — 002.001 — 280  
Bajt kontrolního sou čtu je osmibitový sou čet modulo 256 
všech bajtů zprávy vyjma samotného CS.  
Bajty FMT, SID, DS_, TRTP a TREP jsou definovány dále 
v tomto dokumentu.  
DDP_003 V p řípadě, že data, která má zpráva nést, jsou delší než 
dostupný prostor v datovém poli, pošle se zpráva jako 
několik dílčích zpráv. Každá díl čí zpráva nese hlavi čku, 
stejný bajt SID, bajt TREP a dvoubajtový čítač dílčích 
zpráv udávající po řadí dílčí zprávy v celkové zpráv ě. Aby 
byla možná kontrola chyb a p řerušení přenosu, potvrzuje 
IDE každou díl čí zprávu. IDE m ůže přijmout dílčí zprávu, 
požádat, aby byla p řenesena znovu, požádat VU o op ětovný 
start nebo p řenos přerušit.  
DDP_004 Jestliže poslední díl čí zpráva obsahuje v datovém poli 
přesně 255 bajtů, musí se p řipojit závěrečná dílčí zpráva 
s prázdným datovým polem (vyjma bajt ů SID a TREP 
a čítače dílčích zpráv) jako indikátor konce zprávy.  
Příklad:  
Hlavička SID  TREP  Zpráva  CS  
4 bajty  Delší než 255 bajt ů 
Přenese se jako:  
Hlavička SID  TREP  00  01  Dílčí zpráva 1  CS  
4 bajty  255 bajt ů 
Hlavička SID  TREP  00  02  Dílčí zpráva 2  CS  
4 bajty  255 bajt ů 
… 
Hlavička SID  TREP  xx  yy  Dílčí zpráva n  CS  
4 bajty  Mén ě než 255 bajt ů 
nebo jako:  
Hlavička SID  TREP  00  01  Dílčí zpráva 1  CS  
4 bajty  255 bajt ů 
Hlavička SID  TREP  00  02  Dílčí zpráva 2  CS  
4 bajty  255 bajt ů 
… 
Hlavička SID  TREP  xx  yy  Dílčí zpráva n  CS  
4 bajty  255 bajt ů 
Hlavička SID  TREP  xx  yy + 1  CS  
4 bajty  4 bajty  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 281  
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.  
▼M1 
Struktura zprávy  Max. 4 bajty Hlavi čka Max. 255 bajt ů Data  1 bajt 
Kontro­
lní 
součet 
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  CS  
Start Communication Request  81  EE  F0  81  E0  
Positive Response Start 
Communication  80 F0  EE  03  C1  EA, 8F  9B  
Start Diagnostic Session 
Request  80 EE  F0  02  10  81  F1  
Positive Response Start 
Diagnostic  80 F0  EE  02  50  81  31  
Link Control Service  
Verify Baud Rate (stage 1)  
9 600 Bd  80  EE  F0  04  87  01,01,01  EC  
19 200 Bd  80  EE  F0  04  87  01,01,02  ED  
38 400 Bd  80  EE  F0  04  87  01,01,03  EE  
57 600 Bd  80  EE  F0  04  87  01,01,04  EF  
115 200 Bd  80  EE  F0  04  87  01,01,05  F0  
Positive Response Verify Baud 
Rate 80 F0  EE  02  C7  01  28  
Transition Baud Rate 
(stage 2)  80 EE  F0  03  87  02,03  ED  
Request Upload  80  EE  F0  0A  35  00,00,00,00, 
00,FF,FF, 
FF,FF  99 
Positive Response Request 
Upload  80 F0  EE  03  75  00,FF  D5  
Transfer Data Request  
Overview  80  EE  F0  02  36  01 nebo 21  97  
Activities  80  EE  F0  06  36  02 nebo 22  Date  CS  
Events & Faults  80  EE  F0  02  36  03 nebo 23  Date  99  
Detailed Speed  80  EE  F0  02  36  04 nebo 24  Date  9A  
Technical Data  80  EE  F0  02  36  05 nebo 25  Date  9B  
Card download  80  EE  F0  02  36  06  Slot  CS  
Positive Response Transfer Data  80  F0  EE  Len  76  TREP  Data  CS  
Request Transfer Exit  80  EE  F0  01  37  96  
Positive Response Request 
Transfer Exit  80 F0  EE  01  77  D6  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 282  
Struktura zprávy  Max. 4 bajty Hlavi čka Max. 255 bajt ů Data  1 bajt 
Kontro­
lní 
součet 
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  CS  
Stop Communication Request  80  EE  F0  01  82  E1  
Positive Response Stop 
Communication  80 F0  EE  01  C2  21  
Acknowledge sub message  80  EE  F0  Len  83  Data  CS  
Negative responses  
General reject  80  F0  EE  03  7F  Sid Req  10  CS  
Service not supported  80  F0  EE  03  7F  Sid Req  11  CS  
Sub function not supported  80  F0  EE  03  7F  Sid Req  12  CS  
Incorrect Message Length  80  F0  EE  03  7F  Sid Req  13  CS  
Conditions not correct or 
Request sequence error  80 F0  EE  03  7F  Sid Req  22  CS  
Request out of range  80  F0  EE  03  7F  Sid Req  31  CS  
Upload not accepted  80  F0  EE  03  7F  Sid Req  50  CS  
Response pending  80  F0  EE  03  7F  Sid Req  78  CS  
Data not available  80  F0  EE  03  7F  Sid Req  FA  CS  
▼B 
Poznámky:  
▼M1 
— TRTP 21 až 25 se použijí pro požadavky na stahování dat z VU 2. 
generace, TRTP 01 až 05 se použijí pro požadavky na stahování 
dat z VU 1. generace, které m ůže VU akceptovat pouze v rámci 
kontroly řidičů prováděné kontrolním orgánem, který nepat ří do 
EU, za použití kontrolní karty první generace.  
— TRTP 11 až 19 a 31 až 39 jsou vyhrazeny pro specifické poža ­
davky výrobce na stahování.  
▼B 
— Sid Req = SID odpovídajícího požadavku.  
— TREP = TRTP odpovídajícího požadavku.  
— Tmavé bu ňky znamenají, že se nic nep řenáší.  
— Termín „odeslání dat“ („ upload “, z pohledu IDE) se používá 
z důvodu slučitelnosti s ISO 14229. Znamená totéž jako stahování 
dat („ download “, z pohledu VU).  
— Případné 2bajtové čítače dílčích zpráv nejsou v tabulce uvedeny.  
— Slot je číslo otvoru pro kartu, bu ď „1“ (karta v otvoru pro kartu 
řidiče), nebo „2“ (karta v otvoru pro kartu druhého řidiče). 
— Není-li otvor specifikován, VU vybere otvor č. 1, pokud je v n ěm 
vložena karta, a otvor č. 2 vybere jen v p řípadě, že jej explicitn ě 
vybere uživatel.  
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 ). ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 283  
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. 
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ů. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 284  
2.2.2.9 T r a n s f e r D a t a R e q u e s t ( S I D 3 6 )  
▼M1 
DDP_011 Zprávu Transfer Data Request posílá IDE, aby informovalo 
VU, jaký typ dat se má stahovat. Jednobajtový parametr 
TRTP udává typ p řenosu.  
Existuje šest 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  
přehled ( Overvi­
ew) 01 21  
činnosti v daný 
den ( Activities of 
a specified date ) 02 22  
události a chyby 
(Events and faults ) 03 23  
podrobnosti 
o rychlosti 
(Detailed speed ) 04 24  
technická data 
(Technical data ) 05 25  
Typ přenosu dat  Hodnota TRTP  
stahování z karty 
(Card download ) 06 
DDP_054 IDE v rámci relace stahování povinn ě žádá o p řenos dat 
přehledu (TRTP 01 nebo 21), nebo ť jedině tak lze zajistit, 
že ve staženém souboru budou zaznamenány certifikáty VU 
(a bude možné ov ěřit digitální podpis).  
Ve druhém p řípadě (TRTP 02 nebo 22) zpráva  Transfer 
Data Request  obsahuje kalendá řní den (ve formátu
  
), 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.  
▼M1 
DDP_055 V prvním p řípadě (TREP 01 nebo 21) VU pošle data, která 
operátorovi IDE pomohou vybrat data, která chce dále stáh ­
nout. Informace obsažené v této zpráv ě jsou:  
— bezpečnostní certifikáty,  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 285  
— 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 . 
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 nepo ­
tvrzena.  
Odpovědi VU, které se budou skládat z n ěkolika dílčích 
zpráv, jsou:  
— Positive Response Transfer Data  (SID 76)  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 286  
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.  
— 11  Service not supported  (služba nepodporována)  
SID požadavku není srozumitelný.  
— 12  Sub function not supported  (podfunkce nepodporo ­
vá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 
provozní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 dispozici (nap ř. není vložená žádná karta, požadavek 
na stažení dat z VU typu 1. generace je mimo rámec 
kontroly řidiče kontrolním orgánem, který nepat ří do 
EU, …).  
▼B 
2.2.3  Tok zpráv  
Typický tok zpráv b ěhem normálního postupu stahování dat je násle ­
dující:  
IDE VU  
Start Communication Request  ⇨ 
⇦  Positive Response  
Start Diagnostic Service Request  ⇨ 
⇦  Positive Response  
Request Upload  ⇨ 
⇦  Positive Response  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 287  
IDE VU  
Transfer Data Request Overview  ⇨ 
⇦  Positive Response  
Transfer Data Request #2  ⇨ 
⇦  Positive Response #1  
Acknowledge Sub Message #1  ⇨ 
⇦  Positive Response #2  
Acknowledge Sub Message #2  ⇨ 
⇦  Positive Response #m  
Acknowledge Sub Message #m  ⇨ 
⇦  Positive Response (datové pole < 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 — 26.02.2020 — 002.001 — 288  
Přípustné hodnoty parametr ů časování jsou uvedeny v násle ­
dující tabulce (rozší řený soubor parametr ů časování 
protokolu KWP používaný v p řípadě fyzického adresování 
k urychlení komunikace).  
Parametr časování  Spodní mezní hodnota 
(ms) Horní mezní hodnota 
(ms) 
P1 0  20  
P2 20  1 000 (*)  
P3 10  5 000  
P4 5  20  
P5 10  20 minut  
(*) Pokud VU odpoví zprávou  Negative Response  obsahující kód s významem „požadavek správn ě přijat, 
odpověď se připravuje“, prodlužuje se tato hodnota na horní mezní hodnotu parametru P3.  
2.2.5  Zpracování chyb  
Pokud při výměně zpráv dojde k chyb ě, schéma toku zpráv se zm ění 
v závislosti na tom, které za řízení chybu zjistilo a která zpráva chybu 
vyvolala.  
Na obrázku 2 a 3 jsou znázorn ěny postupy zpracování chyb pro VU 
a pro IDE.  
2.2.5.1 F á z e z a h á j e n í k o m u n i k a c e  
DDP_020 Pokud IDE zjistí chybu ve fázi zahájení komunikace, a ť už 
z časování, nebo z bitového toku, p řed zopakováním poža ­
davku vyčká po dobu P3min.  
DDP_021 Pokud VU zjistí chybu v posloupnosti p řicházející z IDE, 
neodešle žádnou odpov ěď a počká na další zprávu  Start 
Communication Request  po dobu P3max.  
2.2.5.2 F á z e k o m u n i k a c e  
Je možné definovat dv ě různé oblasti zpracování chyb:  
1. VU zjistí chybu v p řenosu z IDE  
DDP_022 VU u každé p řijaté zprávy detekuje chyby v časování, 
chyby ve formátu bajt ů (např. porušení start a stop bitu) 
a chyby rámce (chybný po čet přijatých bajt ů, chybný bajt 
kontrolního sou čtu). 
DDP_023 Pokud VU zjistí jednu z výše uvedených chyb, neposílá 
žádnou odpov ěď a obdrženou zprávu ignoruje.  
DDP_024 VU m ůže detekovat další chyby ve formátu nebo obsahu 
obdržené zprávy (nap ř. nepodporovaná zpráva), i když 
zpráva spl ňuje požadavky na délku a kontrolní sou čet; 
v takovém p řípadě VU odešle IDE odpov ěď Negative 
Response  specifikující povahu chyby.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 289  
Obrázek 2  
Zpracování chyb na stran ě VU
 
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. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 290  
DDP_028 IDE p řed zahájením každého p řenosu vyčká nejmén ě po 
dobu P3min. Čekací doba se m ěří od posledního vypo č­
teného výskytu stop bitu po zjišt ění chyby.  
Obrázek 3  
Zpracování chyb na stran ě IDE
  
2.2.6  Obsah zprávy s odpov ědí 
Tento odstavec specifikuje obsah datových polí r ůzných zpráv 
s kladnou odpov ědí. 
Datové prvky jsou definovány v datovém slovníku v dodatku 1.  
Poznámka: P ři stahování dat 2. generace je každý datový prvek 
nejvyšší úrovn ě reprezentován polem záznam ů, i když obsahuje 
pouze jeden záznam. Pole záznam ů začíná hlavičkou; tato hlavi čka 
obsahuje typ záznamu, velikost záznamu a po čet záznam ů. Pole 
záznamů jsou v následujících tabulkách nazvána „…RecordArray“ (s 
hlavičkou).  
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 O v e r v i e w  
DDP_029  ►M1 Datové pole zprávy  Positive Response Transfer Data 
Overview  musí obsahovat následující data v uvedeném 
pořadí, přičemž se použije SID 76 hex, TREP 01 nebo 21 
hex a pat řičné rozdělení do díl čích zpráv a jejich 
počítání: ◄ ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 291  
Datová struktura 1. generace (TREP 01 hex)  
▼B 
Datový prvek  Poznámka
  
Bezpečnostní certifikáty VU
  
Identifikace vozidla
  
Aktuální datum a čas VU
  
Období, které lze stáhnout
  
Typy karet vložených do VU
  
Předchozí stažení dat z VU
  
Všechny uložené zámky podniku. Pokud je tato 
sekce prázdná, odešle se pouze noOfLocks = 0.
  
Všechny záznamy o kontrole uložené ve VU. 
Pokud je tato sekce prázdná, odešle se pouze 
noOfControls = 0.
  
Podpis RSA všech dat (krom ě certifikátů), počí­
naje VehicleIdentificationNumber a kon če 
posledním bajtem posledního prvku VuContro ­
lActivityData.  
▼M1 
Datová struktura 2. generace (TREP 21 hex)  
▼B 
Datový prvek  Poznámka
  
Certifikát členského státu
  
Certifikát VU
  
Identifikace vozidla
  
Registrační značka vozidla
  
Aktuální datum a čas VU
  
Období, které lze stáhnout
  
Typy karet vložených do VU
  
Předchozí stažení dat z VU
  
Všechny uložené zámky podniku. Pokud je tato 
sekce prázdná, odešle se hlavi čka pole s noOfRe ­
cords = 0.
  
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.
  
Podpis ECC všech p ředcházejících dat krom ě 
certifikátů. 
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 A c t i v i t i e s  
DDP_030  ►M1 Datové pole zprávy  Positive Response Transfer Data 
Activities  musí obsahovat následující data v uvedeném 
pořadí, přičemž se použije SID 76 hex, TREP 02 nebo 22 
hex a pat řičné rozdělení do díl čích zpráv a jejich 
počítání: ◄ ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 292  
Datová struktura 1. generace (TREP 02 hex)  
▼B 
Datový prvek  Poznámka
  
Datum stahovaného dne
  
Stav počitadla ujetých kilometr ů na konci stahovaného 
dne
 
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.
  
Stav otvor ů pro karty v 00:00 a zm ěny činností zazna ­
menané pro stahovaný den.
  
Data týkající se míst zaznamenaná pro stahovaný den. 
Pokud je tato sekce prázdná, odešle se pouze noOfPlace ­
Records = 0.
  
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.
  
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.  
▼M1 
Datová struktura 2. generace (TREP 22 hex)  
▼B 
Datový prvek  Poznámka
  
Datum stahovaného dne
  
Stav počitadla ujetých kilometr ů na konci stahovaného 
dne
 
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.
  
Stav otvor ů pro karty v 00:00 a zm ěny činností zazna ­
menané pro stahovaný den.
  
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.  
▼M1
 
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.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 293  
Datový prvek  Poznámka
  
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.
  
Podpis ECC všech p ředcházejících dat.  
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 E v e n t s a n d F a u l t s  
DDP_031  ►M1 Datové pole zprávy  Positive Response Transfer Data 
Events and Faults  musí obsahovat následující data 
v uvedeném po řadí, přičemž se použije SID 76 hex, 
TREP 03 nebo 23 hex a pat řičné rozdělení do díl čích 
zpráv a jejich po čítání: ◄ 
▼M1 
Datová struktura 1. generace (TREP 03 hex)  
▼B 
Datový prvek  Poznámka
  
Všechny závady uložené nebo probíhající ve 
VU. 
Pokud je tato sekce prázdná, odešle se pouze 
noOfVuFaults = 0.
  
Všechny události (krom ě překročení povolené 
rychlosti) uložené nebo probíhající ve VU. 
Pokud je tato sekce prázdná, odešle se pouze 
noOfVuEvents = 0.
  
Data týkající se poslední kontroly p řekročení 
povolené rychlosti (výchozí hodnota, nejsou-li 
žádná data).
  
Všechny události p řekročení povolené rychlosti 
uložené ve VU. 
Pokud je tato sekce prázdná, odešle se pouze 
noOfVuOverSpeedingEvents = 0.
  
Všechny události nastavení času uložené ve VU 
(mimo rámec úplné kalibrace). 
Pokud je tato sekce prázdná, odešle se pouze 
noOfVuTimeAdjRecords = 0.
  
Podpis RSA všech dat, po čínaje prvkem noOf ­
VuFaults a kon če posledním bajtem posledního 
záznamu o nastavení času. 
▼M1 
Datová struktura 2. generace (TREP 23 hex)  
▼B 
Datový prvek  Poznámka
  
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.
  
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.
  
Data týkající se poslední kontroly p řekročení 
povolené rychlosti (výchozí hodnota, nejsou-li 
žádná data).
  
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.  ▼B
02016R0799 — CS — 26.02.2020 — 002.001 — 294 
Datový prvek Poznámka
  
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.  
▼M1__________  
▼B
Podpis ECC všech p ředcházejících dat.  
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 D e t a i l e d S p e e d  
DDP_032 ►M1 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í: ◄ 
▼M1
Datová struktura 1. generace (TREP 04)  
▼B
Datový prvek Poznámka
  
Všechny podrobnosti o rychlosti uložené ve VU 
(jeden blok rychlostí za minutu, b ěhem níž se 
vozidlo pohybovalo), 
60 hodnot rychlosti za minutu (jedna za sekun ­
du).
 
Podpis RSA všech dat, po čínaje prvkem noOf ­
SpeedBlocks a kon če posledním bajtem posled ­
ního bloku rychlostí.  
▼M1
Datová struktura 2. generace (TREP 24)  
▼B
Datový prvek Poznámka
  
Všechny podrobnosti o rychlosti uložené ve VU 
(jeden blok rychlostí za minutu, b ěhem níž se 
vozidlo pohybovalo), 
60 hodnot rychlosti za minutu (jedna za sekun ­
du).
 
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 T e c h n i c a l D a t a  
DDP_033 ►M1 Datové pole zprávy  Positive Response Transfer Data 
Technical Data  musí obsahovat následující data v uvedeném 
pořadí, přičemž se použije SID 76 hex, TREP 05 nebo 25 
hex a patř ičné rozdělení do díl čích zpráv a jejich 
počítání: ◄ ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 295  
Datová struktura 1. generace (TREP 05)  
▼B 
Datový prvek  Poznámka
  
Všechny záznamy o kalibraci uložené ve VU.
  
Podpis RSA všech dat, po čínaje prvkem vuMa ­
nufacturerName a kon če posledním bajtem 
posledního záznamu VuCalibrationRecord.  
▼M1 
Datová struktura 2. generace (TREP 25)  
▼B 
Datový prvek  Poznámka
  
Všechna párování sníma čů pohybu uložená ve 
VU.
 
Všechny vazby s vn ějšími zařízeními GNSS 
uložené ve VU.
  
Všechny záznamy o kalibraci uložené ve VU.
  
Všechna data o vložení karty uložená ve VU.
  
Podpis ECC všech p ředcházejících dat.  
2.3 Ukládání soubor ů na externí pam ěťové médium  
DDP_034 Pokud byl sou částí relace stahování p řenos dat z VU, IDE 
uloží do jednoho fyzického souboru všechna data p řijatá 
z VU během relace stahování ve zprávách  Positive Response 
Transfer Data . Uložená data nezahrnují hlavi čky zpráv, 
čítače dílčích zpráv, prázdné díl čí zprávy a kontrolní sou čty, 
ale zahrnují SID a TREP (jen první díl čí zprávy, pokud je 
dílčích zpráv více).  
3. PROTOKOL PRO STAHOVÁNÍ DAT Z KARET TACHOGRAFU  
3.1 Oblast p ůsobnosti  
Tento odstavec popisuje p římé stahování dat z karty tachografu do 
IDE. IDE není sou částí bezpe čnostního prost ředí, neprobíhá proto 
ověření pravosti mezi kartou a IDE.  
3.2 Definice  
Relace stahování : Každé stahování dat z čipové karty (ICC). 
Relace zahrnuje celý postup od resetování 
ICC zařízením IFD až po deaktivaci ICC 
(vyjmutí karty nebo další reset).  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 296  
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.  
3.3 Stahování z karty  
▼M1 
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)
  a
  . 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
  :  
— Stažení EF
  
a
 . 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
  
) krom ě EF
  
. Tyto informace jsou zabez ­
pečeny digitálním podpisem za použití mechanism ů 
v souladu s dodatkem 11 „Spole čné bezpečnostní 
mechanismy“ částí A.  
— V každé relaci stahování musí být povinn ě staženy 
alespoň EF
  
a
 .  
— Při stahování z karty řidiče musí být rovn ěž povinně 
staženy tyto EF:
  
— (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
  
DF: 
— Stažení EF CardSignCertificate, CA_Certificate 
a Link_Certificate (je-li k dispozici). Tyto infor ­
mace 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
  
DF) krom ě EF
  
. Tyto informace jsou 
zabezpečeny digitálním podpisem za použití 
mechanism ů v souladu s dodatkem 11 „Spole čné 
bezpečnostní mechanismy“ částí B.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 297  
— 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:
  
— Při stahování z karty řidiče aktualizujte datum
  
v EF
  
v DF
  
a případně
 .  
— Při stahování z karty dílny vynulujte po čítadlo 
kalibrací v EF
  v DF
  
a p řípadně
 
. 
— Při stahování z karty dílny se nestahuje EF
  
v DF
  
a p řípadně
 
. 
▼B 
3.3.1  Inicializa ční sekvence  
DDP_036 IDE zahájí sekvenci takto:  
Karta  Sm ěr IDE/IFD  Význam/poznámky  
⇦ Hardwarový reset  
ATR ⇨ 
Nepovinně lze pomocí PPS p řepnout na vyšší rychlost 
přenosu dat, pokud ji ICC podporuje.  
3.3.2  Sekvence pro nepodepsané datové soubory  
DDP_037  ►M1 Sekvence stahování EF ICC, IC, Card_Certificate 
(nebo CardSignCertificate pro DF Tachograph_G2), 
CA_Certificate a Link_Certificate (pouze pro DF Tacho ­
graph_G2) je následující: ◄ 
Karta  Sm ěr IDE/IFD  Význam/poznámky  
⇦ Select File  Výb ěr podle identifikátor ů 
souboru  
OK ⇨ 
⇦ Read Binary  Pokud soubor obsahuje více 
dat, než je velikost vyrovná ­
vací pam ěti čtečky nebo 
karty, je t řeba příkaz opako ­
vat, 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  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 298  
Poznámka 1:  Před vybráním EF Card_Certificate (nebo 
CardSignCertificate) musí být vybrána aplikace tachografu 
(výběr podle AID).  
Poznámka 2:  Výběr a čtení souboru lze rovn ěž provést 
v jednom kroku pomocí p říkazu  Read Binary  s krátkým 
identifikátorem EF.  
3.3.3  Sekvence pro podepsané datové soubory  
DDP_038 Pro každý z následujících soubor ů, které je t řeba stáhnout 
s podpisem, se použije tato sekvence:  
▼M1 
Karta  Sm ěr IDE/IFD  Význam/poznámky
  
Select File  
OK
 
Perform Hash of File  — Vypo čte hodnotu hash 
dat obsažených ve 
vybraném souboru 
pomocí p ředepsaného 
hašovacího algoritmu 
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  
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 Signa ­
ture 
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 . ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 299  
3.3.4  Sekvence pro reset po čítadla kalibrací  
DDP_039 Sekvence pro reset po čítadla
  
v EF
  
na kartě dílny je následující:  
Karta  Sm ěr IDE/IFD  Význam/poznámky  
⇦ Select File  EF Card_Download  Výběr podle identifikátor ů 
souboru  
OK ⇨ 
⇦ Update Binary  
NoOfCalibrationsSinceDownload 
= ‘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.  
3.4 Formát uložených dat  
3.4.1  Úvod  
DDP_040 Stažená data musí být uložena za t ěchto podmínek:  
— Data se ukládají transparentn ě. To znamená, že p ři 
uložení musí být zachováno po řadí bajtů přenesených 
z karty, jakož i po řadí bitů uvnitř bajtů. 
— Všechny soubory karty stažené b ěhem relace stahování 
jsou v ESM uloženy v jednom souboru.  
3.4.2  Formát souboru  
DDP_041 Soubor má formát z řetězení několika objekt ů TLV.  
DDP_042 Tag elementárního souboru je FID plus p řípona „00“.  
DDP_043 Tag podpisu elementárního souboru je FID souboru plus 
přípona „01“.  
DDP_044 Délka je dvoubajtová hodnota. Její hodnota ur čuje počet 
bajtů v poli s hodnotou. Hodnota „FF FF“ v poli délky je 
vyhrazena pro budoucí použití.  
DDP_045 Jestliže se n ějaký soubor nestahuje, neukládá se nic, co 
s tímto souborem souvisí (žádný tag ani nulová délka).  
▼M1 
DDP_046 Podpis se uloží jako následující objekt TLV bezprost ředně 
za objekt TLV, který obsahuje data souboru.  
Definice  Význam  Délka  
FID (2 bajty) || „00“  Tag pro EF (FID) v DF
  
nebo pro 
společné informace karty  3 bajty  
FID (2 bajty) || „01“  Tag pro podpis EF (FID) 
v DF
  3 bajty  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 300  
Definice  Význam  Délka  
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  
Příklad stažených dat v souboru na ESM:  
Tag Délka  Hodnota
  
— Data EF ICC
  
— Data EF Card_Certificate  
— …
  
Data EF
  (v DF
  
)
 
Podpis EF
  (v DF
  
)
 
Data EF
  v DF
  
Podpis EF
  v DF
  
▼B 
4. STAHOVÁNÍ Z KARTY TACHOGRAFU P ŘES JEDNOTKU VE 
VOZIDLE  
DDP_047 VU musí umožnit stažení obsahu vložené karty řidiče do 
připojeného IDE.  
DDP_048 IDE tento režim zahájí zasláním zprávy  Transfer Data 
Request Card Download  do VU (viz bod 2.2.2.9)  
▼M1 
DDP_049 Karty řidiče první generace: data se stahují pomocí 
protokolu 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 — 26.02.2020 — 002.001 — 301  
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 — 26.02.2020 — 002.001 — 302  
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 ů 
8. FORMÁTY DATARECORDS  
8.1. Rozsahy p řenášených parametr ů 
8.2. Formáty dataRecords  
1. ÚVOD  
Tento dodatek popisuje, jak se vym ěňují data mezi celkem ve vozidle 
(VU) a zkušebním za řízením po vodi či K, který tvo ří část kalibračního 
rozhraní popsaného v dodatku 6. Popisuje také řízení signálového 
vodiče vstup/výstup (I/O) na kalibra čním konektoru.  
Navázání komunikace po vodi či K je popsáno v části 4 „Komunika ční 
služby“.  
Tento dodatek používá koncepci diagnostických „relací“ k tomu, aby 
stanovil rozsah řízení vodičem K za různých podmínek. Výchozí relací 
je „StandardDiagnosticSession“ (standardní diagnostická relace), kdy 
mohou být veškerá data z celku ve vozidle čtena, ale žádná data 
nemohou být do celku ve vozidle zapisována.  
Volba diagnostické relace je popsána v části 5 „Řídící služby“.  
Tento dodatek je t řeba, v souladu s požadavky na interoperabilitu 
stanovenými v tomto na řízení, považovat za relevantní pro ob ě gene­
race celků ve vozidle a karet dílny.  
CPR_001 Relace „ECUProgrammingSession“ (programovací relace 
ECU) umož ňuje zadávání dat do celku ve vozidle. V p řípadě 
zadávání kalibra čních dat musí být celek ve vozidle navíc 
v pracovním režimu kalibrace (CALIBRATION).  
Přenos dat po vodi či K je popsán v části 6 „Služby p řenosu 
dat“. Formáty p řenášených dat jsou podrobn ě uvedeny 
v části 8 „Formáty dataRecords“.  
CPR_002 Relace „ECUAdjustmentSession“ (se řizovací relace ECU) 
umožňuje volbu režimu I/O (vstup/výstup) na kalibra čním 
signálovém vodi či I/O přes rozhraní vodi če K. Řízení kali­
bračního signálového vodi če I /O je popsáno v části 7 
„Řízení zkušebních impuls ů – Řízení funkčního celku vstup/ 
výstup“.  
CPR_003 V tomto dokumentu je adresa zkušebního za řízení ozna čo­
vána jako ′tt′. I když mohou existovat preferované adresy 
zkušebních za řízení, celek ve vozidle musí správn ě reagovat 
na kteroukoli adresu zkušebního za řízení. Fyzická adresa 
celku ve vozidle je 0xEE.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 303  
2. POJMY, DEFINICE A ODKAZY  
Protokoly, zprávy a chybové kódy v podstat ě vycházejí z návrhu 
normy ISO 14229-1 Road vehicles – Diagnostic systems – Part 1: 
Diagnostic services, version 6 (Silni ční vozidla — Diagnostické 
systémy — Část 1: Diagnostické služby, verze 6 ze dne 22. února 
2001).  
Pro identifikátory služeb, požadavky na služby, odpov ědi a pro stan ­
dardní parametry se užívá bajtové kódování a hexadecimální hodnoty.  
Pojem „zkušební za řízení“ se vztahuje na za řízení používané pro 
zadávání programovacích nebo kalibra čních dat do celku ve vozidle.  
Pojem „klient“ se vztahuje na zkušební za řízení a pojem „server“ na 
celek ve vozidle.  
Zkratka ECU znamená „elektronický řídící celek“ ( Electronic Control 
Unit) a vztahuje se na celek ve vozidle.  
Odkazy:  
▼M1 
ISO 14230-2: Road Vehicles – Diagnostic Systems – Keyword 
Protocol 2000 – Part 2: Data Link Layer.  
First edition: 1999 (Silni ční vozidla – Diagnostické systémy – Protokol 
klíčových slov 2000 – Část 2: Spojová vrstva. První vydání: 1999).  
▼B 
3. P ŘEHLED SLUŽEB  
3.1. Dostupné služby  
Dále uvedená tabulka podává p řehled služeb, které budou dostupné 
v tachografu a které jsou v tomto dokumentu definovány.  
CPR_004 Tabulka uvádí služby dostupné v povolené diagnostické 
relaci.  
— Prvý sloupec  uvádí seznam dostupných služeb.  
— Druhý sloupec  obsahuje číslo části v tomto dodatku, ve 
kterém je daná služba dále definována.  
— Třetí sloupec  přiděluje zprávám se žádostí hodnoty 
identifikátor ů služeb.  
— Čtvrtý sloupec  specifikuje služby  „StandardDiagnos ­
ticSession“ (SD)  (standardní diagnostická relace), které 
musí být implementovány v každém celku ve vozidle.  
— Pátý sloupec  specifikuje služby  „ECUAdjustmentSes ­
sion“ (ECUAS) , které musí být implementovány pro 
umožnění řízení signálového vodi če I/O z kalibra čního 
konektoru na čelním panelu celku ve vozidle.  
— Šestý sloupec  specifikuje služby  „ECUProgramming ­
Session“ (ECUPS) , které musí být implementovány pro 
umožnění programování parametr ů v celku ve vozidle.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 304  
Tabulka 1  
Souhrnná tabulka hodnot identifikátor ů (Id) služeb  
Diagnostické relace  
Název diagnostické služby  Číslo 
části Požadovaná 
hodnota identi ­
fikátoru služby  SD ECUAS  ECUPS  
StartCommunication  4.1  81  ■ ■ ■ 
StopCommunication  4.2  82  ■ 
TesterPresent  4.3  3E  ■ ■ ■ 
StartDiagnosticSession  5.1  10  ■ ■ ■ 
SecurityAccess  5.2  27  ■ ■ ■ 
ReadDataByIdentifier  6.1  22  ■ ■ ■ 
WriteDataByIdentifier  6.2  2E  ■ 
InputOutputControlByIdentifier  7.1  2F  ■ 
■ Tento symbol zna čí, že služba je v této diagnostické relaci povinná. 
Pokud není symbol uveden, znamená to, že tato služba není v této diagnostické relaci povolena.  
3.2. Kódy odpov ědí 
Kódy odpov ědí jsou definovány pro každou službu.  
4. KOMUNIKA ČNÍ SLUŽBY  
Některé služby jsou pot řebné k navázání a udržování komunikace. 
Neobjevují se na aplika ční vrstvě. Tyto dostupné služby jsou rozepsány 
v následující tabulce:  
Tabulka 2  
Komunika ční služby  
Název služby  Popis  
StartCommunication  Klient požaduje zahájení komunika ční 
relace se serverem (servery).  
StopCommunication  Klient požaduje ukon čení probíhající 
komunikační relace.  
TesterPresent  Klient oznamuje serveru, že je stále 
připojen.  
CPR_005 Služba StartCommunication se užívá pro zahájení komuni ­
kace. Pro navedení jakékoliv služby musí být komunikace 
inicializována a komunika ční parametry musí odpovídat 
požadovanému režimu.  
4.1. Služba StartCommunication (zahájení komunikace)  
CPR_006 Po obdržení indika čního prvku StartCommunication musí 
celek ve vozidle ov ěřit, zda může být požadované komuni ­
kační spojení za sou časných podmínek inicializováno. 
Platné podmínky pro inicializaci komunika čního spojení 
jsou popsány v dokumentu ISO 14230-2.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 305  
CPR_007 Pak musí celek ve vozidle provést veškeré kroky pot řebné 
pro inicializaci komunika čního spojení a musí odeslat prvek 
s odpovědí na StartCommunication spole čně se zvolenými 
parametry kladné odpov ědi. 
CPR_008 Pokud celek ve vozidle, který byl již inicializován (a který 
vstoupil do jakékoli diagnostické relace), obdrží nový poža ­
davek StartCommunication (nap říklad v důsledku zotavení 
z chyb ve zkušebním za řízení), musí být požadavek p řijat 
a celek ve vozidle musí být znovu inicializován.  
CPR_009 Pokud nem ůže být z jakéhokoliv d ůvodu komunika ční 
spojení inicializováno, musí celek ve vozidle pokra čovat 
v činnosti, kterou provozoval bezprost ředně před pokusem 
o inicializaci komunika čního spojení.  
CPR_010 Zpráva s požadavkem StartCommunication musí být fyzicky 
adresována.  
CPR_011 Inicializace celku ve vozidle prob ěhne postupem „rychlé 
inicializace“.  
— Každé činnosti předchází klidová doba sb ěrnice,  
— Zkušební za řízení pak vyšle inicializa ční sekvenci.  
— Veškeré informace, které jsou pot řebné pro zahájení 
komunikace, jsou obsaženy v odpov ědi celku ve 
vozidle.  
CPR_012 Po dokon čení inicializace:  
— se veškeré komunika ční parametry nastaví podle klí čo­
vých bajtů na hodnoty definované v tabulce 4,  
— celek ve vozidle vy čkává na první požadavek zkušeb ­
ního zařízení,  
— celek ve vozidle je ve výchozím diagnostickém režimu, 
tj. StandardDiagnosticSession,  
— kalibra ční signálový vodi č I/O je ve výchozím stavu, tj. 
v neaktivním stavu.  
CPR_014 Rychlost p řenosu dat na vodi či K musí být 10 400 baud ů. 
CPR_016 Rychlá inicializace je zahájena zkušebním za řízením, které 
vysílá startovací sekvenci (Wup) po vodi či K. Sekvence 
začíná po klidové dob ě na vodiči K nízkou úrovní po 
dobu Tinil. Zkušební za řízení vyšle prvý bit ze StartCom ­
municationService následn ě po dob ě Twup po první 
sestupné hran ě.
 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 306  
CPR_017 Hodnoty časování pro rychlou inicializaci a komunikaci jsou 
obecně rozepsány v níže uvedených tabulkách. Existují 
různé možnosti pro dobu klidu ( idle time ): 
— První p řenos po zapnutí napájení, Tidle = 300 ms.  
— Po dokon čení služby StopCommunication Tidle = P3 min.  
— Po ukon čení komunikace v d ůsledku překročení doby 
P3max, Tidle = 0.  
Tabulka 3  
Hodnoty časování pro rychlou inicializaci  
Parametr  Minimální hodnota  Maximální hodnota  
Tinil  25 ± 1 ms  24 ms  26 ms  
Twup  50 ± 1 ms  49 ms  51 ms  
Tabulka 4  
Hodnoty časování pro komunikaci  
Parametr 
časování  Popis parametru  Dolní mezní 
hodnoty (ms)  Horní mezní 
hodnoty (ms)  
min. max.  
P1 Doba mezi bajty pro odpov ěď 
celku ve vozidle  0 20  
P2 Doba mezi požadavkem 
zkušebního za řízení a odpov ědí 
celku ve vozidle nebo mezi 
dvěma odpov ěďmi celku ve 
vozidle  25 250  
P3 Doba mezi koncem odpov ědi 
celku ve vozidle a za čátkem 
nového požadavku zkušebního 
zařízení  55 5 000  
P4 Doba mezi bajty pro poža ­
davek zkušebního za řízení  5 20  
CPR_018 Formáty zprávy pro rychlou inicializaci jsou rozepsány 
v níže uvedených tabulkách: (POZNÁMKA: Hex znamená 
hexadecimální)  
Tabulka 5  
zpráva se žádostí StartCommunication  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Bajt formátu — fyzické adre ­
sování  81 FMT  
#2 Bajt adresy cíle  EE  TGT  
#3 Bajt adresy zdroje  tt  SRC  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 307  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#4 Id služby požadavku Start ­
Communication  81 SCR  
#5 Kontrolní sou čet 00-FF  CS  
Tabulka 6  
zpráva s kladnou odpov ědí na StartCommunication  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Bajt formátu — fyzické adre ­
sování  80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Dodate čný bajt délky  03  LEN  
#5 Id služby kladné odpov ědi na 
StartCommunication  C1 SCRPR  
#6 Klíčový bajt 1  EA  KB1  
#7 Klíčový bajt 2  8F  KB2  
#8 Kontrolní sou čet 00-FF  CS  
CPR_019 Na zprávu StartCommunication není záporná odpov ěď, 
pokud neexistuje zpráva s kladnou odpov ědí, která má být 
přenesena, pak se celek ve vozidle neinicializuje, nic se 
nepřenáší a celek ve vozidle z ůstává v normálním provozu.  
4.2. Služba StopCommunication (ukon čení komunikace)  
4.2.1  Popis zprávy  
Tato služba komunika ční vrstvy slouží k ukon čení komunika ční relace.  
CPR_020 Po obdržení indika čního prvku StopCommunication musí 
celek ve vozidle ov ěřit, zda existující podmínky umož ňují 
tuto komunikaci ukon čit. V tomto p řípadě musí celek ve 
vozidle provést veškeré kroky pot řebné k ukon čení této 
komunikace.  
CPR_021 Pokud je komunikaci možno ukon čit, musí celek ve vozidle, 
dříve než je komunikace ukon čena, vydat prvek odpov ědi 
StopCommunication se zvolenými parametry kladné odpo ­
vědi. 
CPR_022 Pokud nem ůže být komunikace z jakéhokoliv d ůvodu ukon ­ 
čena, vydá celek ve vozidle prvek odpov ědi na StopCom ­
munication se zvoleným parametrem záporné odpov ědi. 
CPR_023 Pokud celek ve vozidle zjistí p řekročení času P3max, komu ­
nikace se ukon čí bez vydání prvku odpov ědi. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 308  
4.2.2  Formát zprávy  
CPR_024 Formáty zpráv pro prvky StopCommunication jsou roze ­
psány v níže uvedených tabulkách.  
Tabulka 7  
zpráva se žádostí StopCommunication  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  EE  TGT  
#3 Bajt adresy zdroje  tt  SRC  
#4 Bajt dodate čné délky  01  LEN  
#5 Id služby požadavku Stop ­
Communication  82 SPR  
#6 Kontrolní sou čet 00-FF  CS  
Tabulka 8  
zpráva s kladnou odpov ědí na StopCommunication  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  01  LEN  
#5 Id služby kladné odpov ědi na 
StopCommunication  C2 SPRPR  
#6 Kontrolní sou čet 00-FF  CS  
Tabulka 9  
zpráva se zápornou odpov ědí na StopCommunication  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  03  LEN  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 309  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#5 Id služby záporné odpov ědi 7F  NR  
#6 Identifikace služby požadavku 
StopCommunication  82 SPR  
#7 responseCode = generalReject  10  RC_GR  
#8 Kontrolní sou čet 00-FF  CS  
4.2.3  Definice parametr ů 
Tato služba nevyžaduje žádné definice parametr ů 
4.3. Služba TesterPresent (zkušební za řízení připojeno)  
4.3.1  Popis zprávy  
Pomocí služby TesterPresent zkušební za řízení indikuje serveru, že je 
stále připojeno, aby tak bylo serveru zabrán ěno v automatickém 
návratu do normálního provozu a p řípadnému ukon čení komunikace. 
Tato služba, která se vysílá pravideln ě, udržuje diagnostickou relaci / 
komunikaci aktivní tím, že vždy po obdržení požadavku na tuto službu 
se resetuje časovač P3. 
4.3.2  Formát zprávy  
CPR_079 Formáty zpráv pro prvky TesterPresent jsou rozepsány 
v níže uvedených tabulkách.  
Tabulka 10  
zpráva se žádostí TesterPresent  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  EE  TGT  
#3 Bajt adresy zdroje  tt  SRC  
#4 Bajt dodate čné délky  02  LEN  
#5 Id služby požadavku Tester ­
Present  3E TP  
#6 Podfunkce = 
responseRequired =  [ano 01 RESPREQ_Y  
ne] 02  RESPREQ_NO  
#7 Kontrolní sou čet 00-FF  CS  
CPR_080 Je-li parametr responseRequired nastaven na „ano“, odpoví 
server následující kladnou zprávou. Je-li nastaven na „ne“, 
neodešle server žádnou odpov ěď. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 310  
Tabulka 11  
zpráva s kladnou odpov ědí na TesterPresent  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  01  LEN  
#5 Id služby kladné odpov ědi na 
TesterPresent  7E TPPR  
#6 Kontrolní sou čet 00-FF  CS  
CPR_081 Služba podporuje následující kódy negativních odpov ědí: 
Tabulka 12  
zpráva se zápornou odpov ědí na TesterPresent  
Bajt č. Název parametru  Hexade­
cimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické adreso ­
vání 80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  03  LEN  
#5 Id služby záporné odpov ědi 7F  NR  
#6 Identifikace služby požadavku 
TesterPresent  3E TP  
#7 responseCode =  [SubFunctionNot ­
Supported-Invalid ­
Format  12 RC_SFNS_IF  
incorrectMessage ­
Length ]  13 RC_IML  
#8 Kontrolní sou čet 00-FF  CS  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 311  
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 
vyhrazený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 vozi ­
del, které nejsou sou částí tohoto dokumentu. Pravidla imple ­
mentace musí odpovídat t ěmto požadavk ům: 
— V celku ve vozidle musí být vždy aktivní jediná diagno ­
stická relace.  
— Vždy, když je celek ve vozidle p řipojen na napájení, 
musí zahájit StandardDiagnosticSession. Pokud není 
zahájena jiná diagnostická relace, pak StandardDiagnos ­
ticSession probíhá tak dlouho, dokud je celek ve vozidle 
napájen.  
— Pokud je zkušebním za řízením požadována diagnostická 
relace, která již probíhá, odešle celek ve vozidle zprávu 
s kladnou odpov ědí. 
— Kdykoli zkušební za řízení požaduje novou diagno ­
stickou relaci, odešle celek ve vozidle nejprve zprávu 
s kladnou odpov ědí na StartDiagnosticSession p ředtím, 
než se v celku ve vozidle aktivuje nová relace. Pokud 
není celek ve vozidle schopen zahájit požadovanou 
novou diagnostickou relaci, musí odpov ědět zprávou se 
zápornou odpov ědí na StartDiagnosticSession a probíha ­
jící relace musí pokra čovat.  
CPR_026 Diagnostická relace se zahájí pouze tehdy, pokud byla mezi 
klientem a celkem ve vozidle zahájena komunikace.  
CPR_027 Pokud byla d říve aktivní jiná diagnostická relace, stanou se 
parametry časování podle definice v tabulce 4 aktivními po 
úspěšné StartDiagnosticSession s parametrem diagnosticSes ­
sion nastaveným ve zpráv ě se žádostí o„StandardDiagnos ­
ticSession“.  
5.1.2  Formát zprávy  
CPR_028 Formáty zpráv pro prvky StartDiagnosticSession jsou roze ­
psány v níže uvedených tabulkách.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 312  
Tabulka 14  
zpráva se žádostí StartDiagnosticSession  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  EE  TGT  
#3 Bajt adresy zdroje  tt  SRC  
#4 Bajt dodate čné délky  02  LEN  
#5 Id služby požadavku StartDi ­
agnosticSession  10 STDS  
#6 diagnosticSession = [jedna 
hodnota z tabulky 17]  xx DS_…  
#7 Kontrolní sou čet 00-FF  CS  
Tabulka 15  
zpráva s kladnou odpov ědí na StartDiagnosticSession  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  02  LEN  
#5 Id služby kladné odpov ědi na 
StartDiagnosticSession  50 STDSPR  
#6 diagnosticSession = [ shodná 
hodnota s bajtem #6 tabulka 
14 ] xx DS_…  
#7 Kontrolní sou čet 00-FF  CS  
Tabulka 16  
zpráva se zápornou odpov ědí na StartDiagnosticSession  
Bajt č. Název parametru  Hexade­
cimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické adreso ­
vání 80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 313  
Bajt č. Název parametru  Hexade­
cimální 
hodnota  Symbol  
#4 Bajt dodate čné délky  03  LEN  
#5 Id služby záporné odpov ědi 7F  NR  
#6 Id služby požadavku StartDiagnostic ­
Session  10 STDS  
#7 Response ­
Code =  [subFunctionNotSup ­
ported (  a ) 12 RC_SFNS  
incorrectMessage ­
Length (  b ) 13 RC_IML  
conditionsNotCor ­
rect (  c ) 22 RC_CNC  
#8 Kontrolní sou čet 00-FF  CS  
( a ) – hodnota vložená do bajtu # 6 zprávy o požadavku není podporována, tj. není 
v tabulce 17, 
( b ) – délka obdržené zprávy je chybná, 
( c ) – kritéria pro požadavek StartDiagnosticSession nejsou spln ěna. 
5.1.3  Definice parametr ů 
CPR_029 Parametr  diagnosticSession (DS_)  využívá služba StartDi ­
agnosticSession k výb ěru zvláštního chování serveru (serve ­
rů). V tomto dokumentu jsou specifikovány tyto diagno ­
stické 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 — 26.02.2020 — 002.001 — 314  
Hex Popis  Symbol  
87 ECUAdjustmentSession  
Tato diagnostická relace umož ňuje všechny 
služby podle  tabulky 1 sloupce 5 „ECUAS“.  
Tyto služby podporují řízení vstupu/výstupu 
serveru (celku ve vozidle). Tato diagnostická 
relace může být přepsána jinými diagnostickými 
relacemi specifikovanými v této části. ECUAS  
5.2. Služba SecurityAccess  
Zapisování kalibra čních dat není možné, pokud celek ve vozidle není 
v režimu KALIBRACE. Krom ě vložení platné karty dílny do celku ve 
vozidle je nezbytné d říve, než je ud ělen přístup k režimu KALI ­
BRACE, vložit do celku ve vozidle p říslušný PIN.  
Přístup ke kalibra čnímu vodi či I/O je také možný, pokud je celek ve 
vozidle v režimu KALIBRACE nebo KONTROLA (CONTROL).  
Služba SecurityAccess poskytuje prost ředky pro vložení PIN a indikuje 
zkušebnímu za řízení, zda celek ve vozidle je, nebo není v režimu 
KALIBRACE.  
PIN může být vložen alternativními postupy.  
5.2.1  Popis zprávy  
Služba SecurityAccess je tvo řena zprávou SecurityAccess„requestSeed“ 
následovanou zprávou SecurityAccess „sendKey“. Služba SecurityAc ­
cess musí být provedena po služb ě StartDiagnosticSession.  
CPR_033 Zkušební za řízení využívá zprávu SecurityAccess „request ­
Seed“, pro ov ěření, zda je celek ve vozidle p řipraven k p řijetí 
PIN. 
CPR_034 Pokud je celek ve vozidle již v režimu KALIBRACE, musí 
odpovědět na požadavek vysláním „seed“ 0x0000 s 
využitím služby kladné odpov ědi na SecurityAccess.  
CPR_035 Pokud je celek ve vozidle p řipraven k p řijetí PIN pro 
ověření kartou dílny, musí odpov ědět na požadavek 
vysláním „seed“ v ětšího než 0x0000 s využitím služby 
kladné odpov ědi na SecurityAccess.  
CPR_036 Pokud není celek ve vozidle p řipraven k p řijetí PIN od 
zkušebního za řízení, buď protože vložená karta dílny není 
platná, nebo protože karta dílny nebyla vložena, nebo 
protože celek ve vozidle o čekává PIN jiným postupem, 
odpoví celek ve vozidle na požadavek zápornou odpov ědí 
s kódem odpov ědi nastaveným na conditionsNotCorrectOr ­
RequestSequenceError.  
CPR_037 Zkušební za řízení pak použije k p ředání PIN do celku ve 
vozidle zprávu SecurityAccess „sendKey“. K tomu, aby byl 
k dispozici čas potřebný k ov ěření pravosti karty, použije 
celek ve vozidle pro prodloužení času pro odpov ěď kód 
záporné odpov ědi requestCorrectlyReceived-ResponsePen ­
ding. Maximální doba pro odpov ěď však nesmí p řekročit ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 315  
pět minut. Jakmile byla požadovaná služba dokon čena, musí 
celek ve vozidle vyslat zprávu s kladnou odpov ědí nebo 
zprávu se zápornou odpov ědí s odlišným kódem odpov ědi. 
Kód záporné odpov ědi requestCorrectlyReceived-Response ­
Pending m ůže být celkem ve vozidle opakován do dokon ­ 
čení požadované služby a do vyslání zprávy s kone čnou 
odpovědí. 
CPR_038 Celek ve vozidle musí na tento požadavek odpov ědět užitím 
služby SecurityAccess PositiveResponse pouze v režimu 
KALIBRACE.  
CPR_039 Celek ve vozidle musí v následujících p řípadech odpov ědět 
na tento požadavek zápornou odpov ědí s kódem odpov ědi 
nastaveným na:  
— subFunctionNot supported: neplatný formát pro parametr 
podfunkce (accessType),  
— conditionsNotCorrectOrRequestSequenceError: celek ve 
vozidle není p řipraven k p řijetí PIN,  
— invalidKey: PIN není platný a po čet pokusů o ověření 
PIN není p řekročen, 
— exceededNumberOfAttempts: PIN není platný a po čet 
pokusů o ověření PIN je p řekročen, 
— generalReject: PIN je správný, ale selhalo vzájemné 
ověření s kartou dílny.  
5.2.2  Formát zprávy – SecurityAccess – requestSeed  
CPR_040 Formáty zpráv pro prvky SecurityAccess „requestSeed“ jsou 
rozepsány v níže uvedených tabulkách.  
Tabulka 18  
požadavek SecurityAccess – zpráva requestSeed  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  EE  TGT  
#3 Bajt adresy zdroje  tt  SRC  
#4 Bajt dodate čné délky  02  LEN  
#5 Id služby požadavku Securi ­
tyAccess  27 SA  
#6 accessType – requestSeed  7D  AT_RSD  
#7 Kontrolní sou čet 00-FF  CS  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 316  
Tabulka 19  
SecurityAccess – zpráva s kladnou odpov ědí requestSeed  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  04  LEN  
#5 Id služby kladné odpov ědi na 
SecurityAccess  67 SAPR  
#6 accessType – requestSeed  7D  AT_RSD  
#7 Seed High  00-FF  SEEDH  
#8 Seed Low  00-FF  SEEDL  
#9 Kontrolní sou čet 00-FF  CS  
Tabulka 20  
zpráva se zápornou odpov ědí na SecurityAccess  
Bajt č. Název parametru  Hexade­
cimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické adreso ­
vání 80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  03  LEN  
#5 Id služby záporné odpov ědi 7F  NR  
#6 Id služby požadavku SecurityAccess  27  SA  
#7 responseCode =  [conditionsNotCor ­
rectOrRequestSe ­
quenceError  22 RC_CNC  
incorrectMessage ­
Length]  13 RC_IML  
#8 Kontrolní sou čet 00-FF  CS  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 317  
5.2.3  Formát zprávy – SecurityAccess – sendKey  
CPR_041 Formáty zpráv pro prvky SecurityAccess „sendKey“ jsou 
rozepsány v níže uvedených tabulkách.  
Tabulka 21  
požadavek SecurityAccess – zpráva sendKey  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  EE  TGT  
#3 Bajt adresy zdroje  tt  SRC  
#4 Bajt dodate čné délky  m+2  LEN  
#5 Id služby požadavku Securi ­
tyAccess  27 SA  
#6 accessType – sendKey  7E  AT_SK  
#7 až #m+6  Klíč #1 (nejvýznamn ější) xx  KEY  
… …  
Klíč #m (nejmén ě významný, 
m musí být nejmén ě 4 
a nejvýše 8)  xx 
#m+7  Kontrolní sou čet 00-FF  CS  
Tabulka 22  
SecurityAccess – zpráva s kladnou odpov ědí na sendKey  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  02  LEN  
#5 Id služby kladné odpov ědi na 
SecurityAccess  67 SAPR  
#6 accessType – sendKey  7E  AT_SK  
#7 Kontrolní sou čet 00-FF  CS  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 318  
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é adresování  80  FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  03  LEN  
#5 Id služby záporné odpov ědi 7F  NR  
#6 Id služby požadavku SecurityAccess  27  SA  
#7 ResponseCode =  [generalReject  10  RC_GR  
subFunctionNotSup ­
ported  12 RC_SFNS  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCorrec ­
tOrRequestSequence ­
Error  22 RC_CNC  
invalidKey  35  RC_IK  
exceededNumberO ­
fAttempts  36 RC_ENA  
requestCorrectlyRe ­
ceived-ResponsePen ­
ding]  78 RC_RCR_RP  
#8 Kontrolní sou čet 00-FF  CS  
6. SLUŽBY P ŘENOSU DAT  
Dostupné služby jsou rozepsány v následující tabulce:  
Tabulka 24  
Služby p řenosu dat  
Název služby  Popis  
ReadDataByIdentifier  Klient požaduje p řenos aktuální hodnoty 
záznamu p řístupem pomocí recordDataIden ­
tifier  
WriteDataByIdentifier  Klient žádá o zápis záznamu p řístupem 
pomocí recordDataIdentifier  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 319  
6.1. Služba ReadDataByIdentifier  
6.1.1  Popis zprávy  
CPR_050 Služba ReadDataByIdentifier je využívána klientem pro 
vyžádání hodnot datového záznamu ze serveru. Data jsou 
identifikována pomocí recordDataIdentifier. Je odpov ědností 
výrobce celku ve vozidle, aby p ři výkonu této služby byly 
splněny podmínky serveru.  
6.1.2  Formát zprávy  
CPR_051 Formáty zpráv pro prvky ReadDataByIdentifier jsou roze ­
psány v níže uvedených tabulkách.  
Tabulka 25  
zpráva se žádostí ReadDataByIdentifier  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  EE  TGT  
#3 Bajt adresy zdroje  tt  SRC  
#4 Bajt dodate čné délky  03  LEN  
#5 Id služby požadavku Read ­
DataByIdentifier  22 RDBI  
#6 až #7  recordDataIdentifier = [hod ­
nota z tabulky 28]  xxxx  RDI_…  
#8 Kontrolní sou čet 00-FF  CS  
Tabulka 26  
zpráva s kladnou odpov ědí na ReadDataByIdentifier  
Bajt č. Název parametru  Hexade­
cimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické adreso ­
vání 80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  m+3  LEN  
#5 Id služby kladné odpov ědi na 
ReadDataByIdentifier  62 RDBIPR  
#6 a #7  recordDataIdentifier = [stejná 
hodnota, jako bajty #6 and #7, 
tabulka 25]  xxxx  RDI_…  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 320  
Bajt č. Název parametru  Hexade­
cimální 
hodnota  Symbol  
#8 až #m 
+7 dataRecord[] =  [data#1  xx  DREC_DATA1  
: :  :  
data#m]  xx  DREC_DATAm  
#m+8  Kontrolní sou čet 00-FF  CS  
Tabulka 27  
zpráva se zápornou odpov ědí na ReadDataByIdentifier  
Bajt č. Název parametru  Hexade­
cimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické adresování  80  FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  03  LEN  
#5 Id služby záporné odpov ědi 7F  NR  
#6 Id služby požadavku ReadDataByI ­
dentifier  22 RDBI  
#7 ResponseCode=  [requestOutO ­
fRange  31 RC_ROOR  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCor ­
rect] 22 RC_CNC  
#8 Kontrolní sou čet 00-FF  CS  
6.1.3  Definice parametr ů 
CPR_052 Parametr  recordDataIdentifier (RDI_)  ve zpráv ě o poža­
davku ReadDataByIdentifier identifikuje datový záznam.  
CPR_053 Hodnoty recordDataIdentifier definované tímto dokumentem 
jsou uvedeny v níže uvedené tabulce.  
Tabulka recordDataIdentifier je tvo řena čtyřmi sloupci 
a několika řádky.  
— První sloupec (Hex)  obsahuje „hexadecimální hodnotu“ 
přiřazenou k recordDataIdentifier specifikovanému ve 
třetím sloupci.  
— Druhý sloupec (Datový prvek)  stanovuje datový prvek 
z dodatku 1, na kterém je založen identifikátor record ­
DataIdentifier (n ěkdy je pot řebné překódování).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 321  
— Třetí sloupec (Popis)  specifikuje odpovídající název 
recordDataIdentifier,  
— Čtvrtý sloupec (Symbol)  specifikuje pro tento record ­
DataIdentifier p říslušný symbol.  
Tabulka 28  
Definice hodnot recordDataIdentifier  
Hex Datový prvek  recordDataIdentifier Name 
(viz formát v bod ě 8.2)  Symbol  
F90B
  TimeDate  RDI_TD  
F912
  HighResolutionTotalVehicle ­
Distance  RDI_HRTVD  
F918
  Kfactor  RDI_KF  
F91C
  LfactorTyreCircumference  RDI_LF  
F91D
  WvehicleCharacteristicFactor  RDI_WVCF  
F921
  TyreSize  RDI_TS  
F922
  NextCalibrationDate  RDI_NCD  
F92C
  SpeedAuthorised  RDI_SA  
F97D
  RegisteringMemberState  RDI_RMS  
F97E
  VehicleRegistrationNumber  RDI_ VRN  
F190
  VIN  RDI_ VIN  
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 322  
Tabulka 29  
zpráva se žádostí WriteDataByIdentifier  
Bajt č. Název parametru  Hexade­
cimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické adreso ­
vání 80 FMT  
#2 Bajt cílové adresy  EE  TGT  
#3 Bajt adresy zdroje  tt  SRC  
#4 Bajt dodate čné délky  m+3  LEN  
#5 Id služby požadavku WriteData ­
ByIdentifier  2E WDBI  
#6 až #7  recordDataIdentifier = [hodnota 
z tabulky 28]  xxxx  RDI_…  
#8 až 
#m+7  dataRecord[] =  [data#1  xx  DREC_DA ­
TA1 
: :  :  
data#m]  xx  DREC_DA ­
TAm  
#m+8  Kontrolní sou čet 00-FF  CS  
Tabulka 30  
zpráva s kladnou odpov ědí na WriteDataByIdentifier  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  03  LEN  
#5 Id služby kladné odpov ědi na 
WriteDataByIdentifier  6E WDBIPR  
#6 až #7  recordDataIdentifier = [stejná 
hodnota, jako bajty #6 and 
#7, tabulka 29]  xxxx  RDI_…  
#8 Kontrolní sou čet 00-FF  CS  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 323  
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é adresování  80  FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  03  LEN  
#5 Id služby záporné odpov ědi 7F  NR  
#6 Id služby požadavku WriteDataByI ­
dentifier  2E WDBI  
#7 ResponseCode=  [requestOutO ­
fRange  31 RC_ROOR  
incorrectMessage ­
Length  13 RC_IML  
conditionsNot ­
Correct]  22 RC_CNC  
#8 Kontrolní sou čet 00-FF  CS  
6.2.3  Definice parametr ů 
Parametr  recordDataIdentifier (RDI_)  je definován v tabulce 28.  
Parametr  dataRecord (DREC_)  se použije ve zpráv ě o požadavku 
WriteDataByIdentifier k tomu, aby klientovi (zkušebnímu za řízení) 
byly dodány hodnoty datových záznam ů identifikovaných pomocí 
recordDataIdentifier. Formáty dat jsou specifikovány v části 8.  
7. ŘÍZENÍ ZKUŠEBNÍCH IMPULS Ů – ŘÍDÍCÍ FUNK ČNÍ CELEK 
VSTUPU/VÝSTUPU  
Dostupné služby jsou rozepsány v následující tabulce:  
Tabulka 32  
Řídící funk ční celek vstupu/výstupu  
Název služby  Popis  
InputOutputControl ­
ByIdentifier  Klient požaduje řízení vstupu/výstupu speci ­
fické pro server.  
7.1. Služba InputOutputControlByIdentifier  
7.1.1  Popis zprávy  
Existuje propojení p řes přední konektor, které umož ňuje, aby zkušební 
impulsy byly řízeny nebo monitorovány pomocí vhodného zkušebního 
zařízení.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 324  
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í).  
CPR_060 Pokud jsou na signálovém vodi či rychlosti v reálném čase 
celku ve vozidle p řijaty rychlostní impulsy v dob ě, kdy je 
kalibrační signálový vodi č I/O nastaven jako vstup, musí se 
kalibrační signálový vodi č I/O nastavit jako výstup nebo 
vrátit do neaktivního stavu.  
CPR_061 Sekvence je tato:  
— zahájit komunikaci prost řednictvím služby StartCommu ­
nication,  
— zahájit se řizovací relaci prost řednictvím služby StartDi ­
agnosticSession a být v provozním režimu KALI ­
BRACE, nebo KONTROLA (po řadí těchto dvou operací 
není důležité),  
— změnit stav výstupu pomocí služby InputOutputControl ­
ByIdentifier.  
7.1.2  Formát zprávy  
CPR_062 Formáty zpráv pro prvky InputOutputControlByIdentifier 
jsou rozepsány v níže uvedených tabulkách.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 325  
Tabulka 33  
zpráva se žádostí InputOutputControlByIdentifier  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  EE  TGT  
#3 Bajt adresy zdroje  tt  SRC  
#4 Bajt dodate čné délky  xx  LEN  
#5 Id služby požadavku Inpu ­
tOutputControlByIdentifier  2F IOCBI  
#6 a #7  InputOutputIdentifier = [Cali ­
brationInputOutput]  F960  IOI_CIO  
#8 nebo 
#8 až #9  ControlOptionRecord = [  COR_…  
inputOutputControlParameter – 
one value from tabulky 36  xx IOCP_…  
controlState — jedna z hodnot 
v tabulce 37 (viz poznámka 
níže)  xx CS_…  
#9 nebo 
#10 Kontrolní sou čet 00-FF  CS  
Poznámka:  parametr controlState je p řítomný jen v n ěkterých 
případech (viz 7.1.3).  
Tabulka 34  
zpráva s kladnou odpov ědí na InputOutputControlByIdentifier  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  xx  LEN  
#5 Id služby kladné odpov ědi na 
inputOutputControlByIdenti ­
fier 6F IOCBIPR  
#6 a #7  inputOutputIdentifier = [Cali ­
brationInputOutput]  F960  IOI_CIO  
#8 nebo 
#8 až #9  controlStatusRecord = [  CSR_  
inputOutputControlParameter 
(stejná hodnota jako bajt #8 
v tabulce 33)  xx IOCP_…  
controlState (stejná hodnota 
jako bajt #9 v tabulce 33)] (v 
příslušných p řípadech)  xx CS_…  
#9 nebo 
#10 Kontrolní sou čet 00-FF  CS  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 326  
Tabulka 35  
zpráva se zápornou odpov ědí na InputOutputControlByIdentifier  
Bajt č. Název parametru  Hexadecimální 
hodnota  Symbol  
#1 Formátový bajt — fyzické 
adresování  80 FMT  
#2 Bajt cílové adresy  tt  TGT  
#3 Bajt adresy zdroje  EE  SRC  
#4 Bajt dodate čné délky  03  LEN  
#5 Id služby záporné odpov ědi 7F  NR  
#6 Id služby požadavku inputOut ­
putControlByIdentifier  2F IOCBI  
#7 responseCode=[  
incorrectMessageLength  13  RC_IML  
conditionsNotCorrect  22  RC_CNC  
requestOutOfRange  31  RC_ROOR  
deviceControlLimitsExceeded]  7A  RC_DCLE  
#8 Kontrolní sou čet 00-FF  CS  
7.1.3  Definice parametr ů 
CPR_064 Parametr  inputOutputControlParameter (IOCP_)  je defi­
nován v následující tabulce.  
Tabulka 36  
Definice hodnot inputOutputControlParameter  
Hex Popis  Symbol  
00 ReturnControlToECU  
Tato hodnota indikuje serveru (celku ve vozidle), 
že zkušební za řízení již ne řídí kalibrační signá- 
lový 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 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 327  
Hex Popis  Symbol  
03 ShortTermAdjustment  
Tato hodnota musí indikovat serveru (celku ve 
vozidle), že se požaduje nastavení kalibra čního 
signálového vodi če I/O na hodnotu obsaženou 
v parametru controlState.  STA  
CPR_065 Parametr  controlState  je přítomen pouze tehdy, když je 
inputOutputControlParameter nastaven na ShortTermAdjust ­
ment, a je definován v následující tabulce:  
Tabulka 37  
Definice hodnot controlState  
Režim  Hexadecimální 
hodnota  Popis  
Neaktivní  00  I/O vodi č je neaktivní (výchozí stav)  
Aktivní  01  Aktivuje kalibra ční spojení I/O jako speed ­
SignalInput  
Aktivní  02  Aktivuje kalibra ční spojení I/O jako realTi ­
meSpeedSignalOutputSensor  
Aktivní  03  Aktivuje kalibra ční spojení I/O jako 
RTCOutput  
8. FORMÁTY DATARECORDS  
Tato část uvádí:  
— obecná pravidla, která se mají použít na rozsahy parametr ů přenáše­
ných celkem ve vozidle do zkušebního za řízení,  
— formáty, které mají být použity u dat p řenášených pomocí služeb 
přenosu dat popsaných v části 6.  
CPR_067 Veškeré identifikované parametry musí být podporovány 
celkem ve vozidle.  
CPR_068 Data p řenášená celkem ve vozidle do zkušebního za řízení 
jako odpov ěď na zprávu s požadavkem musí být nam ěře­
ného typu (tj. musí to být aktuální hodnota požadovaného 
parametru nam ěřená nebo zjišt ěná celkem ve vozidle).  
8.1. Rozsahy p řenášených parametr ů 
CPR_069 Tabulka 38 definuje rozsahy použité ke stanovení platnosti 
přenášených parametr ů. 
CPR_070 Hodnoty v rozsahu „error indicator“ (indikátor chyby) jsou 
pro celek ve vozidle prost ředkem, jak okamžit ě indikovat, že 
v důsledku nějakého druhu chyby v tachografu nejsou 
momentáln ě dostupná platná parametrická data.  
CPR_071 Hodnoty v rozsahu „not available“ (nedostupné) jsou pro 
celek ve vozidle prost ředkem, jak p ředat zprávu, která obsa ­
huje parametr, který není v daném modulu dostupný nebo 
není podporován. Hodnoty v rozsahu „not requested“ (nevy ­ 
žádané) jsou pro za řízení prost ředkem, jak p ředat zprávu 
s příkazem a identifikovat ty parametry, u kterých se neo če­
kává žádná odpov ěď z přijímacího za řízení.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 328  
CPR_072 Pokud závada n ěkteré součásti brání p řenosu platných dat 
parametru, je možné místo dat parametru použít „error indi ­
cator“ (indikátor chyby) podle popisu v tabulce 38. Pokud 
však naměřená nebo vypo čtená data poskytují hodnotu, která 
je platná, ale p řesahuje definovaný rozsah parametru, nem ěl 
by být „error indicator“ (indikátor chyby) použit. Data by 
měla být přenesena s 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í hodno ­
ta) 4 bajty 
(hexadecimální hodnota)  ASCII  
Platný signál  00 až FA  0000 až FAFF  00000000 až FAFFFFFF  1 až 254  
Specifický indikátor parametru  FB  FB00 až FBFF  FB000000 až FBFFFFFF  žádný  
Rezervní rozsah pro budoucí 
indikační bity  FC až FD  FC00 až FDFF  FC000000 až FDFFFFFF  žádný  
Indikátor chyby  FE  FE00 až FEFF  FE000000 až FEFFFFFF  0  
Nedostupné nebo nevyžádané  FF  FF00 až FFFF  FF000000 až FFFFFFFF  FF  
CPR_073 Pro parametry kódované v ASCII je ASCII symbol „*“ 
vyhrazen jako odd ělovací znak.  
8.2. Formáty dataRecords  
V níže uvedených tabulkách 39 až 42 jsou podrobn ě uvedeny formáty, 
které musí být použity prost řednictvím služeb ReadDataByIdentifier 
a WriteDataByIdentifier.  
CPR_074 V tabulce 39 je uvedena délka, rozlišení a pracovní rozsah 
každého z parametr ů identifikovaných pomocí jeho 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  
HighResolutionTotalVehicle ­
Distance  4 5 m/bit, offset 0 m  0 až + 21 055 406 km  
Kfactor  2  0,001 imp/m/bit, offset 0  0 až 64,255 imp/m  
LfactorTyreCircumference  2  0,125 10  – 3 m /bit, offset 0  0 až + 8,031 m  
WvehicleCharacteristicFactor  2  0,001 imp/m /bit, offset 0  0 až 64,255 imp/m  
TyreSize  15  ASCII  ASCII  
NextCalibrationDate  3  Podrobnosti viz tabulka 41  
SpeedAuthorised  2  1/256 km/h/bit, offset 0  0 až 250,996 km/h  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 329  
Název parametru  Délka dat (v 
bajtech)  Rozlišení  Pracovní rozsah  
RegisteringMemberState  3  ASCII  ASCII  
VehicleRegistrationNumber  14  Podrobnosti viz tabulka 42  
VIN 17  ASCII  ASCII  
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 para ­
metrů Rozlišení  Pracovní rozsah  
1 Sekundy  0,25 s/bit, offset 0 s  0 až 59,75s  
2 Minuty  1 min/bit, offset 0 min  0 až 59 min  
3 Hodiny  1 h/bit, offset 0 h  0 až 23 h  
4 M ěsíc 1 m ěsíc/bit, offset 0 m ěsíců 1 až 12 
měsíců 
5 Den  0,25 dne/bit, offset 0 dn ů 
(viz POZNÁMKA níže tabulka 
41) 0,25 až 31,75 
dne 
6 Rok  1 rok/bit, offset +1985 
(viz POZNÁMKA níže tabulka 
41) léta 1985 až 
2235  
7 Místní offset 
v minutách  1 min/bit, offset – 125 min  – 59 až + 59 
min 
8 Místní offset 
v hodinách  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 para ­
metrů Rozlišení  Pracovní rozsah  
1 M ěsíc 1 m ěsíc/bit, offset 0 m ěsíců 1 až 12 
měsíců 
2 Den  0,25 dne/bit, offset 0 dn ů 
(viz POZNÁMKA níže)  0,25 až 31,75 
dne 
3 Rok  1 rok/bit, offset rok +1985 
(viz POZNÁMKA níže )  léta 1985 až 
2235 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 330  
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 užití bajtu parametru „rok“:  
Hodnota 0 ozna čuje rok 1985; hodnota 1 ozna čuje rok 1986 atd.  
CPR_078 Tabulka 42 rozepisuje formáty r ůzných bajt ů parametru 
VehicleRegistrationNumber:  
Tabulka 42  
Rozepsaný formát VehicleRegistrationNumber (recordDataIdentifier 
s hodnotou # F97E)  
Bajt Definice parametr ů Rozlišení  Pracovní rozsah  
1 Kódová stránka (podle definice 
v dodatku 1)  ASCII  01 až 0A  
2 – 14  Registra ční značka vozidla 
(podle definice v dodatku 1)  ASCII  ASCII  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 331  
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  
1. ÚVOD  
1.1 Schválení typu  
ES schválení typu pro záznamové za řízení (nebo jeho sou část) nebo pro 
kartu tachografu se zakládá na:  
▼M1 
— osvědčení bezpe čnosti , které vychází ze specifikací  Common Criteria , 
vůči bezpečnostnímu cíli, který je pln ě v souladu s dodatkem 10 této 
přílohy,  
▼B 
— osvědčení funk čnosti  prováděné příslušným orgánem členského státu, 
který osvědčuje, že zkoušený prvek spl ňuje požadavky této p řílohy 
z hlediska provád ěných funkcí, p řesnosti měření a environmentálních 
vlastností,  
— osvědčení interoperability  prováděné příslušným subjektem, který 
osvědčuje, že záznamové za řízení (nebo karta tachografu) je pln ě inte­
roperabilní s pot řebnými modely karty tachografu (nebo záznamového 
zařízení) (viz kapitolu 8 této p řílohy).  
Tento dodatek stanoví formou minimálních požadavk ů, jaké zkoušky musí 
provést orgán členského státu p ři funkčních zkouškách a jaké zkoušky musí 
provést příslušný subjekt p ři zkouškách interoperability. Postup p ři zkou­ 
škách ani typy zkoušek se podrobn ěji nespecifikují.  
Tento dodatek se nezabývá aspekty osv ědčování bezpe čnosti. Pokud se 
některé ze zkoušek vyžadovaných pro schválení typu provedou v pr ůběhu 
hodnocení a osv ědčování bezpe čnosti, není t řeba takové zkoušky opakovat. 
V takovém p řípadě stačí posoudit výsledky t ěchto zkoušek bezpe čnosti. Pro 
informaci jsou v tomto dodatku hv ězdičkou „*“ ozna čeny požadavky, 
u kterých se o čekává, že budou zkoušeny b ěhem osvědčování bezpe čnosti 
(nebo které úzce souvisí se zkouškami, jejichž provedení se b ěhem osvěd­ 
čování bezpe čnosti očekává).  
Číslované požadavky odkazují na text p řílohy, zatímco další požadavky 
odkazují na ostatní dodatky (nap ř. PIC_001 odkazuje na požadavek 
PIC_001 v dodatku 3 Piktogramy).  
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áznamo ­
vého zařízení. Každá sou část získá vlastní osv ědčení o schválení typu, ve  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 332  
kterém budou uvedeny ostatní kompatibilní sou části. Funk ční zkouška 
snímače pohybu (nebo vn ějšího zařízení GNSS) se provádí spole čně 
s celkem ve vozidle a naopak.  
Není požadována interoperabilita všech model ů snímačů pohybu (resp. vn ěj­ 
ších zařízení GNSS) a všech model ů celků ve vozidle. V takovém p řípadě 
se schválení typu sníma če pohybu (resp. vn ějšího zařízení GNSS) m ůže 
udělit jen ve spojení se schválením typu p říslušného celku ve vozidle 
a naopak.  
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: Vibration  
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 — 26.02.2020 — 002.001 — 333  
ISO/IEC 7816-2  Information technology – Identification cards – Integrated 
circuit(s) cards with contacts – Part 2: Dimensions and location of the 
contacts . 
ISO/IEC 7816-3  Information technology – Identification cards – Integrated 
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 inter ­
face 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 interface  
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  
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  
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 a vzdálenosti  21 až 31  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 334  
Č. Zkouška  Popis  Související požadavky  
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 Ruční vkládání  56 až 62  
3.10 Správa zámk ů podniku  63 až 68  
3.11 Sledování kontrolních činností  69, 70  
3.12 Detekce událostí a/nebo závad  71 až 88, 134  
3.13 Identifika ční údaje za řízení  93*, 94*, 97, 100  
3.14 Údaje o vložení a vyjmutí karty řidiče 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 Kalibra ční údaje  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 Záznam a ukládání dat na kartách tachografu  136, 137, 138*, 139*, 141*, 
142, 143 
144, 145, 146*, 147*, 148*, 
149, 150  
3.28 Zobrazení  90, 134, 
151 až 168, 
PIC_001, DIS_001  
3.29 Tisk  90, 134, 
169 až 181, PIC_001, 
PRT_001 až PRT_014  
3.30 Varování  134, 182 až 191, 
PIC_001  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 335  
Č. Zkouška  Popis  Související požadavky  
3.31 Stahování dat na externí pam ěťová média  90, 134, 192 až 196  
3.32 Dálková komunikace pro cílené silni ční kontroly  197 až 199  
3.33 Výstup dat do dalších vn ějších zařízení  200, 201  
3.34 Kalibrace  202 až 206*, 383, 384, 386 až 
391 
3.35 Silniční kontrola kalibrace  207 až 209  
3.36 Nastavení času 210 až 212*  
3.37 Neovlivn ění přídavnými funkcemi  06, 425  
3.38 Rozhraní sníma če pohybu  02, 122  
3.39 Vnější zařízení GNSS  03, 123  
3.40 Ověřit, že celek ve vozidle detekuje, zaznamenává a ukládá události a/ 
nebo závady definované jeho výrobcem, když spárovaný sníma č pohybu 
reaguje na magnetická pole, která narušují detekci pohybu vozidla.  217 
3.41 Sada šifer a standardizované parametry domény  CSM_48, CSM_50  
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 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 24hodino ­
vý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 ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 336  
Č. Zkouška  Popis  Související požadavky  
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 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 
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: 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í.  219 
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 ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 337  
Č. Zkouška  Popis  Související požadavky  
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)  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 
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 č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 ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 338  
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*  
3.2 Párování sníma če pohybu s celkem ve vozidle  122*, 204  
3.3 Detekce pohybu 
Přesnost měření pohybu  30 až 35  
3.4 Rozhraní s celkem ve vozidle  02  
3.5 Ověřit, zda je sníma č pohybu imunní v ůči konstantnímu magnetickému poli. 
Alternativn ě ověřit, že sníma č pohybu reaguje na konstantní magnetická pole, 
která narušují detekci pohybu vozidla, tak, že p řipojený celek ve vozidle dete ­
kuje, zaznamená a ukládá závady sníma če. 217 
4. Zkoušky vlivu prost ředí 
4.1 Provozní teplota  Ov ěřit funkčnost (jak stanoví zkouška č. 3.3) 
v teplotním rozsahu [– 40 °C; + 135 °C] podle: 
IEC 60068-2-1, zkouška Ad, s dobou trvání 96 
hod při nejnižší teplot ě To  min , 
IEC 60068-2-2, zkouška Bd, s dobou trvání 96 
hod při nejvyšší teplot ě To  max 
Zkouška podle ISO 16750-4, kapitoly 5.1.1.2: 
provozní zkouška p ři nízké teplot ě (24 h při – 
40 °C) 
Tato zkouška odkazuje na IEC 60068-2-1:  Envi­
ronmental testing  – Part 2-1: Tests  – Test A: 
Cold  IEC 68-2-2 zkouška Bd, doba trvání 96 
hod. při nejnižší teplot ě – 40 °C. 
Zkouška podle ISO 16750-4, kapitoly 5.1.2.2: 
provozní zkouška p ři vysoké teplot ě (96 h při 
135 °C) 
Tato zkouška odkazuje na IEC 60068-2-2:  Basic 
environmental testing procedures; part 2: tests; 
tests B: dry heat  213 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 339  
Č. Zkouška  Popis  Související požadavky  
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 24ho ­
dinový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 
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 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 340  
Č. Zkouška  Popis  Související požadavky  
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 
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 č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 
4. FUNK ČNÍ ZKOUŠKY KARET TACHOGRAFU  
Zkoušky podle této části 4,  
bodu 5 „Zkoušky protokolu“,  
bodu 6 „Struktura karty“ a  
bodu 7 „Funk ční zkoušky“  
může osoba provád ějící hodnocení nebo vystavující osv ědčení provád ět 
během postupu osv ědčení bezpečnosti podle  Common Criteria  pro čipový 
modul.  
Zkoušky č. 2.3 a 4.2 jsou stejné. Jde o mechanické zkoušky kombinace t ěla 
karty a čipového modulu. Pokud se n ěkterá z těchto částí (tělo karty, čipový 
modul) zm ění, jsou tyto zkoušky nezbytné.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 341  
Č. 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 — 26.02.2020 — 002.001 — 342  
Č. 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 — 26.02.2020 — 002.001 — 343  
Č. 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 — 26.02.2020 — 002.001 — 344  
Č. 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 — 26.02.2020 — 002.001 — 345  
Č. 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 — 26.02.2020 — 002.001 — 346  
Č. Zkouška  Popis  Související požadavky  
[Mechanická odolnost] 
Karty tachografu musí odpovídat norm ě 
ISO/IEC 7816-1:2011,  Identification cards  – Inte­
grated circuit cards  – Part 1: Cards with contacts  
– Physical characteristics  
[4.3]  Mechanical strength (of a card and contacts)  
[Elektrický p řechodový odpor] 
Karty tachografu musí odpovídat norm ě 
ISO/IEC 7816-1:2011,  Identification cards  – Inte- 
grated circuit cards  – Part 1: Cards with contacts  – 
Physical characteristics  
[4.4]  Electrical resistance (of contacts)  
[Rozměry] 
Karty tachografu musí odpovídat norm ě 
ISO/IEC 7816-2:2007,  Identification cards  – Inte- 
grated circuit cards  – Part 2: Cards with contacts  – 
Dimension and location of the contacts  
[3] Dimension of the contacts  
[Umístění] 
Karty tachografu musí odpovídat norm ě 
ISO/IEC 7816-2:2007,  Identification cards  – Inte- 
grated circuit cards  – Part 2: Cards with contacts  – 
Dimension and location of the contacts  
[4] Number and location of the contacts  
V případě modulů se šesti kontakty nejsou sou částí 
tohoto požadavku na zkoušení kontakty „C4“ a „C8“.  
4 Čip 
4.1 Čip 
[Provozní teplota] 
Čip karty tachografu pracuje v rozsahu teplot okolí 
od – 25 °C do + 85 °C.  241 až 244 
Předpis EHK č. 10 
ISO/IEC 7810 
ISO/IEC 10373  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 347  
Č. 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 — 26.02.2020 — 002.001 — 348  
Č. 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 — 26.02.2020 — 002.001 — 349  
Č. 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 — 26.02.2020 — 002.001 — 350  
Č. 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 čnostní 
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 — 26.02.2020 — 002.001 — 351  
Č. Zkouška  Popis  Související požadavky  
3.3 Poloha dle GNSS  36, 37  
3.4 Rozhraní celku ve vozidle, je-li p řijímač GNSS vn ě celku ve vozidle  03  
3.5 Sada šifer a standardizované parametry domény  CSM_48, CSM_50  
4. Zkoušky vlivu prost ředí 
4.1 Teplota  Ov ěřit funkčnost podle t ěchto zkoušek: 
Zkouška podle ISO 16750-4, kapitoly 5.1.1.2: provozní 
zkouška při nízké teplot ě (72 h při – 20 °C) 
Tato zkouška odkazuje na IEC 60068-2-1:  Environmental 
testing  – Part 2-1: Tests  – Test A: Cold  
Zkouška podle ISO 16750-4: kapitoly 5.1.2.2: provozní 
zkouška při vysoké teplot ě (72 h při 70 °C) 
Tato zkouška odkazuje na IEC 60068-2-2:  Basic environ ­
mental testing procedures; part 2: tests; tests B: dry heat  
Zkouška podle ISO 16750-4:  Chapter 5.3.2: Rapid change 
of temperature with specified transition duration  (– 20°C/ 
70 °C, 20 cykl ů, prodleva 1 h p ři každé teplot ě) 
Při nižší teplot ě, při vyšší teplot ě a během teplotních cykl ů 
lze provád ět omezený soubor zkoušek (z t ěch, které jsou 
definovány v části 3 této tabulky).  213 
4.2 Vlhkost  Ov ěřit, že celek ve vozidle vydrží cyklickou zkoušku 
vlhkostí (zkouška teplem) podle IEC 60068-2-30, zkouška 
Db, šest 24hodinových cykl ů, každý se zm ěnou teploty od + 
25 °C do + 55 °C a relativní vlhkostí 97 % p ři + 25 °C 
a 93 % při + 55 °C  214 
4.3 Mechanické 
vlivy  1. Sinusové vibrace: 
ověřit, že celek ve vozidle vydrží sinusové vibrace 
s těmito parametry: 
konstantní výchylka mezi 5 a 11 Hz: max. 10 mm, 
konstantní zrychlení mezi 11 a 300 Hz: 5 g. 
Tento požadavek se ov ěřuje podle IEC 60068-2-6, 
zkouška Fc o délce nejmén ě 3 × 12 hod (12 hod na 
každou osu). 
ISO 16750-3 nevyžaduje zkoušku sinusovými vibracemi 
u zařízení umíst ěných v odpružené kabin ě vozidla.  219 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 352  
Č. 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:  Environmen- 
tal 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 — 26.02.2020 — 002.001 — 353  
Č. 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í 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 
▼M1 
6. ZKOUŠKA VN ĚJŠÍHO ZA ŘÍZENÍ PRO DÁLKOVOU KOMUNIKACI  
Č. Zkouška  Popis  Související požadavky  
1. Administrativní šet ření 
1.1 Dokumentace  Správnost dokumen ­
tace 
2. Vizuální kontrola  
2.1 Shoda s dokumentací  
2.2 Identifikace/zna čení 225, 226  
2.3 Materiály  219 až 223  
3. Funk ční zkoušky  
3.1 Dálková komunikace pro cílené silni ční kontroly  4, 197 až 199  
3.2 Zaznamenávání a ukládání údaj ů do datové pam ěti 91  
3.3 Komunikace s celkem ve vozidle  Dodatek 14 odstavce 
DSC_66 až DSC_70, 
DSC_71 až DSC_76  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 354  
Č. 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 ř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 Ω 218 ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 355  
Č. 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 — 26.02.2020 — 002.001 — 356  
Č. 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 — 26.02.2020 — 002.001 — 357  
Optické hustoty výsledných výtisk ů se měří podle normy DIN EN ISO 534.  
Výtisky nevykazují žádné rozm ěrové změny a zůstávají jasn ě čitelné.  
8. ZKOUŠKY INTEROPERABILITY  
▼M1 
Č. Zkouška  Popis  
8.1 Zkoušky interoperability celk ů ve vozidle a karet tachografu  
1 Vzájemné ov ěření pravosti  Ov ěřit, že vzájemné ov ěření pravosti mezi celkem ve vozidle a kartou 
tachografu probíhá normáln ě. 
2 Zkoušky zápisu/ čtení Provést typický scéná ř činností s celkem ve vozidle. Scéná ř je 
přizpůsoben typu zkoušené karty a zahrnuje zápis do co nejv ětšího 
počtu elementárních soubor ů na kartě. 
Ověřit stažením z celku ve vozidle, že všechny p říslušné záznamy 
byly řádně provedeny. 
Ověřit stažením z karty, že všechny p říslušné záznamy byly řádně 
provedeny. 
Ověřit pomocí denních výtisk ů, že všechny p říslušné záznamy lze 
řádně přečíst. 
8.2 Zkoušky interoperability celk ů ve vozidle a sníma čů pohybu  
1 Párování  Ov ěřit, že párování mezi celky ve vozidle a sníma či pohybu probíhá 
normálně. 
2 Zkoušky činnosti  Provést typický scéná ř činností se sníma čem pohybu. Scéná ř 
zahrnuje normální činnost a vytvo ření co nejv ětšího počtu událostí 
nebo závad.Ov ěřit stažením z celku ve vozidle, že všechny p říslušné 
záznamy byly řádně provedeny. 
Ověřit stažením z karty, že všechny p říslušné záznamy byly řádně 
provedeny. 
Ověřit pomocí denního výtisku, že všechny p říslušné záznamy lze 
řádně přečíst. 
8.3 
Zkoušky interoperability celk ů ve vozidle a vn ějších zařízení GNSS (v p říslušných p řípadech)  
1 Vzájemné ov ěření pravosti  Ov ěřit, že vzájemné ov ěření pravosti (vazba) mezi celkem ve vozidle 
a vnějším modulem GNSS probíhá normáln ě. 
2 Zkoušky činnosti  Provést typický scéná ř činností s vn ějším zařízením GNSS. Scéná ř 
zahrnuje normální činnost a vytvo ření co nejv ětšího počtu událostí 
nebo závad. 
Ověřit stažením z celku ve vozidle, že všechny p říslušné záznamy 
byly řádně provedeny. 
Ověřit stažením z karty, že všechny p říslušné záznamy byly řádně 
provedeny. 
Ověřit pomocí denního výtisku, že všechny p říslušné záznamy lze 
řádně přečíst. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 358  
Dodatek 10  
BEZPEČNOSTNÍ POŽADAVKY  
Tento dodatek specifikuje bezpe čnostní požadavky v oblasti informa čních tech­
nologií na sou části systém ů inteligentních tachograf ů (tachograf ů druhé genera ­
ce). 
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 technolo ­
gií, které musí každá sou část vyžadující certifikaci z hlediska bezpe č­
nosti splňovat, musí být podle režimu  Common Criteria  vymezeny 
v profilu ochrany sou části. 
SEC_003 Evropská komise zajistí, aby čtyři profily ochrany, jež spl ňují 
podmínky této p řílohy, byly podporovány, vyvíjeny, schváleny vlád ­
ními orgány pro certifikaci bezpe čnosti v oblasti informa čních tech­
nologií vytvo řenými v rámci spole čné interpreta ční pracovní skupiny, 
která podporuje vzájemné uznávání osv ědčení v rámci dohody 
o vzájemném uznávání osv ědčení o posouzení bezpe čnosti informa č­
ních technologií Evropského Poradního výboru pro bezpe čnost infor­
mačních systém ů (SOG-IS MRA), a registrovány:  
— profil ochrany celku ve vozidle,  
— profil ochrany karty tachografu,  
— profil ochrany sníma če pohybu,  
— profil ochrany vn ějšího zařízení GNSS.  
Profil ochrany celku ve vozidle se zabývá p řípady, kdy je celek ve vozidle ur čen 
k tomu, aby byl, nebo nebyl používán s vn ějším zařízením GNSS. V prvním 
případě jsou bezpe čnostní požadavky na vn ější zařízení GNSS uvedeny v samo ­
statném profilu ochrany.  
SEC_004 Výrobci sou částí musí dle pot řeby upřesnit a doplnit profil ochrany 
příslušné sou části, aniž by pozm ěnili nebo odstranili stávající hrozby, 
cíle, postupy a specifikace funkcí zajiš ťujících bezpe čnost, za účelem 
stanovení bezpe čnostního cíle, podle kterého budou požadovat 
bezpečnostní certifikaci sou části. 
SEC_005 V pr ůběhu hodnocení musí být konstatováno p řísné dodržení uvede ­
ného bezpe čnostního cíle s odpovídajícími profilem ochrany.  
SEC_006 Stupe ň záruky pro každý profil ochrany musí být EAL4 rozší řený 
o složky záruky ATE_DPT.2 a AVA_VAN.5.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 359  
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 — 26.02.2020 — 002.001 — 360  
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 — 26.02.2020 — 002.001 — 361  
10.2.2 Ov ěření řetězce certifikát ů VU kartou  
10.3. Ov ěření pravosti VU  
10.4. Ov ěření pravosti čipu a odsouhlasení klí če relace  
10.5. Bezpe čné předávání zpráv  
10.5.1 Obecné informace  
10.5.2 Struktura bezpe čné zprávy  
10.5.3 P řerušení relace bezpe čného předávání zpráv  
11. PÁROVÁNÍ VU – VN ĚJŠÍ ZAŘÍZENÍ GNSS, VZÁJEMNÉ 
OVĚŘOVÁNÍ PRAVOSTI A BEZPE ČNÉ PŘEDÁVÁNÍ ZPRÁV  
11.1. Obecné informace  
11.2. Párování VU a externího za řízení GNSS  
11.3. Vzájemné ov ěření řetězce certifikát ů 
11.3.1 Obecné informace  
11.3.2 B ěhem párování VU – EGF  
11.3.3 B ěhem normálního provozu  
11.4. Ov ěřování pravosti VU, ov ěřování pravosti čipu a odsouhlasení 
klíče relace  
11.5. Bezpe čné předávání zpráv  
12. PÁROVÁNÍ A KOMUNIKACE VU – SNÍMA Č POHYBU  
12.1. Obecné informace  
12.2. Párování VU – sníma č pohybu pomocí r ůzných generací klí čů 
12.3. Párování a komunikace VU – sníma č pohybu pomocí AES  
12.4. Párování VU – sníma č pohybu pro r ůzné generace za řízení  
13. BEZPE ČNOST VZDÁLENÉ KOMUNIKACE PROST ŘEDNIC­ 
TVÍM DSRC  
13.1. Obecné informace  
13.2. Šifrování p řenosu dat tachografu a generování MAC  
13.3. Ov ěření a dešifrování p řenosu dat tachografu  
14. PODEPISOVÁNÍ STAŽENÝCH DAT A OV ĚŘOVÁNÍ 
PODPISŮ 
14.1. Obecné informace  
14.2. Generování podpisu  
14.3. Ov ěření podpisu  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 362  
PREAMBULE  
Tento dodatek stanovuje bezpe čnostní mechanismy, které zajiš ťují 
— vzájemné ov ěřování pravosti mezi r ůznými sou částmi systému tachografu,  
— důvěrnost, integritu, ov ěřování pravosti a/nebo nepopiratelnost dat p řenáše­
ných mezi r ůznými součástmi systému tachografu nebo stahovaných do exter ­
ních paměťových médií.  
Tento dodatek obsahuje dv ě části. Část A stanovuje bezpe čnostní mechanismy 
pro systém tachografu první generace (digitální tachograf). Část B stanovuje 
bezpečnostní mechanismy pro systém digitálního tachografu druhé generace 
(inteligentní tachograf).  
Mechanismy stanovené v části A tohoto dodatku platí, pokud alespo ň jedna 
součást systému tachografu pro proces vzájemného ov ěřování pravosti a/nebo 
přenosu dat je za řízením první generace.  
Mechanismy stanovené v části B tohoto dodatku platí, pokud ob ě součásti 
systému tachografu pro proces vzájemného ov ěřování pravosti a/nebo p řenosu 
dat jsou za řízením druhé generace.  
Dodatek 15 uvádí další informace týkající se používání sou částí první generace 
ve spojení se sou částmi druhé generace.  
ČÁST A  
SYSTÉM TACHOGRAFU PRVNÍ GENERACE  
1. ÚVOD  
1.1. Zdroje  
V tomto dodatku jsou použity tyto zdroje:  
SHA-1 National Institute of Standards and Technology 
(NIST).  FIPS Publication 180-1: Secure Hash Stan ­
dard . Duben 1995.  
PKCS1 RSA Laboratories. PKCS # 1:  RSA Encryption Stan ­
dard . Verze 2.0. Říjen 1998.  
TDES National Institute of Standards and Technology 
(NIST).  FIPS Publication 46-3: Data Encryption 
Standard . Návrh 1999.  
TDES-OP ANSI X9.52, Triple Data Encryption Algorithm 
Modes of Operation. 1998.  
ISO/IEC 7816-4 Information Technology – Identification cards – Inte ­
grated circuit(s) cards with contacts (Informa ční tech­
nologie – Identifika ční karty – Karty s integrovanými 
obvody a s kontakty) Část 4: Interindustry commands 
for interexchange (Mezioborové p říkazy pro vým ěnu). 
První vydání: 1995 + Zm ěna 1: 1997.  
ISO/IEC 7816-6 Information Technology – Identification cards – Inte ­
grated circuit(s) cards with contacts (Informa ční tech­
nologie – Identifika ční karty – Karty s integrovanými 
obvody a s kontakty) Část 6: Interindustry data 
elements (Mezioborové datové prvky). První vydání: 
1996 + Oprava 1: 1998.  
ISO/IEC 7816-8 Information Technology – Identification cards – Inte ­
grated circuit(s) cards with contacts (Informa ční tech­
nologie – Identifika ční karty – Karty s integrovanými 
obvody a s kontakty) Část 8: Security related interin ­
dustry commands (Mezioborové p říkazy pro bezpe č­
nost). První vydání 1999.  
ISO/IEC 9796-2 Information Technology – Security techniques – 
Digital signature schemes giving message recovery 
(Informační technologie – Bezpe čnostní techniky – 
Schémata digitálního podpisu umož ňující obnovu 
zprávy) – Část 2: Mechanisms using a hash function 
(Mechanismy využívající hašovací funkci). První 
vydání: 1997.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 363  
ISO/IEC 9798-3 Information Technology – Security techniques – 
Entity authentication mechanisms (Informa ční techno­
logie – Bezpe čnostní techniky – Mechanismy autenti ­
zace entit) – Část 3: Entity authentication using 
a public key algorithm (Autentizace entit používající 
algoritmus s ve řejným klíčem). Druhé vydání: 1998.  
ISO 16844-3 Road vehicles – Tachograph systems (Silni ční vozidla 
– Systémy tachograf ů) – Část 3: Motion sensor inter ­
face (Rozhraní sníma če pohybu).  
1.2. Značení a zkratky  
V tomto dodatku jsou užity následující zna čení a zkratky:  
(K a , K  b , K  c ) balí ček klíčů pro užití trojitého algoritmu šifrování 
dat, 
CA certifika ční autorita,  
CAR odkaz na certifika ční autoritu,  
CC kryptografický kontrolní sou čet, 
CG kryptogram,  
CH hlavi čka příkazu,  
CHA autorizace držitele certifikátu,  
CHR odkaz na držitele certifikátu,  
D() dešifrování pomocí standardu pro vým ěnu dat DES,  
DE prvek dat,  
DO datový objekt,  
d soukromý klí č RSA, soukromý zmocn ěnec, 
e ve řejný klíč RSA, veřejný zmocn ěnec, 
E() šifrování pomocí DES,  
EQT za řízení,  
Hash()  hašovací hodnota, výstup hodnoty  Hash , 
Hash  hašovací funkce,  
KID identifikátor klí če, 
Km klí č TDES. Hlavní klí č podle definice ISO 16844-3,  
Km  VU klíč TDES vložený do celku ve vozidle,  
Km  WC klíč TDES, vložený do karty dílny,  
m celé číslo mezi 0 a  n-1 reprezentující zprávu,  
n klí če RSA, modul,  
PB dopl ňkové bajty,  
PI indika ční bajt dopln ění (užití v šif ře pro důvěrnost 
DO),  
PV otev řená hodnota,  
s celé číslo mezi 0 a  n-1 reprezentující podpis,  
SSC čítač odeslané posloupnosti,  
SM bezpe čné zpracování zpráv,  
TCBC TDEA blok číslic svazující provozní režimy,  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 364  
TDEA trojitý algoritmus šifrování dat,  
TLV hodnota délky tagu,  
VU celek ve vozidle,  
X.C certifikát uživatele X vydaný certifika ční autoritou,  
X.CA certifika ční autorita uživatele X,  
X.CA.PK  o X.C operace rozbalení certifikátu pro extrakci ve řejného 
klíče. Je to zavád ěcí operátor, jehož levý operand je 
veřejným klíčem certifika ční autority a jehož pravý 
operand je certifikátem vydaným certifika ční auto­
ritou. Výstupem je ve řejný klíč uživatele X, jehož 
certifikát je pravým operandem,  
X.PK RSA ve řejný klíč uživatele X,  
X.PK[I] RSA zašifrování n ěkterých informací I p ři užití veřej­
ného klíče uživatele X,  
X.SK RSA soukromý klí č uživatele X,  
X.SK[I] RSA zašifrování n ěkterých informací I p ři užití 
soukromého klí če uživatele X,  
‘xx’ hexadecimální hodnota,  
|| operátor řetězení.  
2. KRYPTOGRAFICKÉ SYSTÉMY A ALGORITMY  
2.1. Kryptografické systémy  
CSM_001 VU a karty tachografu musí používat klasický kryptografický 
systém RSA ve řejného klí če k tomu, aby vytvo řily tyto 
bezpečnostní mechanismy:  
— ověřování pravosti mezi VU a kartami,  
— převod trojitých DES klí čů relací mezi VU a kartami 
tachografu,  
— digitální podpis dat stažených z VU nebo karet tacho ­
grafu 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 — 26.02.2020 — 002.001 — 365  
X.SK[ m] = s = m d mod n 
X.PK[ s] = m = s e mod n 
Obsažnější popis funkce RSA lze nalézt v odkazu [PKCS1]. 
Veřejný exponent e pro výpo čet RSA je celé číslo mezi 3 
a n-1 splňující podmínku gcd(e, lcm(p-1, q-1))=1.  
2.2.2  Hašovací algoritmus  
CSM_004 Mechanismus digitálního podpisu musí užívat hašovací algo ­
ritmus SHA-1 podle definice v odkazu [SHA-1].  
2.2.3  Algoritmus šifrování dat  
CSM_005 Algoritmus, založený na DES musí být užit v provozním 
režimu „Cipher Block Chaining“.  
3. KLÍ ČE A CERTIFIKÁTY  
3.1. Generování a distribuce klí čů 
3.1.1  Generování a distribuce klí čů RSA  
CSM_006 Klí če RSA musí být generovány prost řednictvím t ří funkč­
ních hierarchických úrovní:  
— evropské úrovn ě, 
— úrovně členských stát ů, 
— úrovně zařízení.  
CSM_007 Na evropské úrovni musí být generován jediný pár evrop ­
ských klíčů (EUR.SK a EUR.PK). K certifikaci ve řejných 
klíčů členských stát ů musí být používán evropský soukromý 
klíč. Musí být udržovány záznamy o všech certifikovaných 
klíčích. Tyto úkoly musí zajiš ťovat Evropský certifika ční 
úřad pod pravomocí a odpov ědností Evropské komise.  
CSM_008 Na úrovni členského státu musí být generován pár klí čů 
členské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 certi ­
fikaci 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 certifikovaný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 pravi­
delně 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, digi ­
tální podpis a šifrovací služby.  
CSM_010 B ěhem generování, dopravy (v p říslušných p řípadech) a skla ­
dování musí být zachována d ůvěrnost soukromých klí čů. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 366  
Toto vyobrazení shrnuje tok dat v tomto procesu:
  
3.1.2  Zkušební klí če RSA  
CSM_011 Pro zkoušení za řízení (včetně zkoušek interoperability) musí 
Evropský certifika ční úřad generovat odlišný jediný evropský 
pár zkušebních klí čů a nejmén ě dva páry zkušebních klí čů 
členských stát ů, jejichž ve řejné klíče musí být certifikovány 
soukromým evropským zkušebním klí čem. Výrobci musí do 
zařízení, které je podrobeno zkouškám schválení typu, vložit 
zkušební klí če certifikované jedním z t ěchto zkušebních klí čů 
členského státu.  
3.1.3  Klíče snímače pohybu  
Důvěrnost níže uvedených t ří klíčů TDES musí být náležit ě zachována 
v průběhu generování, dopravy (v p říslušných p řípadech) a skladování.  
Na podporu vyhov ění součástí tachografu norm ě ISO 16844 musí 
Evropský certifika ční úřad a dále certifika ční úřady členských stát ů 
kromě toho zajistit následující:  
CSM_036 Evropský certifika ční úřad musí generovat KmVU a KmWC, 
dva nezávislé a jedine čné klíče Triple TDES, a generovat 
Km jako:  Km = Km  VU XOR Km  WC . Evropský certifika ční 
úřad musí tyto klí če za příslušných zabezpe čených postup ů 
předat na vyžádání členských stát ů jejich certifika čním auto­
ritám.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 367  
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ájem ­
ného ověřování pravosti generovat a vzájemn ě si vyměňovat 
data potřebná pro vypracování spole čného klíče Triple DES. 
Důvěrnost této vým ěny dat musí být ochrán ěna šifrovacím 
mechanismem RSA.  
CSM_013 Tento klí č musí být použit u všech následujících kryptogra ­
fických operací za použití zabezpe čené komunikace. Jeho 
platnost kon čí ukončením relace (vyjmutím karty nebo rese ­
továním karty) a/nebo po 240 použitích (jedno použití klí če = 
jeden příkaz s využitím zabezpe čené komunikace odeslaný 
na kartu a odpovídající odpov ěď). 
3.2. Klíče 
CSM_014 Klí če RSA musí mít (na kterékoliv úrovni) následující délku: 
modul  n 1 024 bitů, veřejný exponent  e 64 bitů maximáln ě, 
soukromý exponent  d 1 024 bitů. 
CSM_015 Klí če Triple DES musí mít tvar (K  a , K  b , K  a ), kde K  a a K  b 
jsou nezávislé klí če dlouhé 64 bit ů. Nenastavují se žádné bity 
pro detekci závad v parit ě. 
3.3. Certifikáty  
CSM_016 Certifikáty RSA ve řejných klí čů musí být certifikáty „ non 
self-descriptive “ (nepopisné) „ card verifiable “ (ověřující 
kartu) (viz ISO/IEC 7816-8)  
3.3.1  Obsah certifikát ů 
CSM_017 Certifikáty ve řejných klí čů RSA jsou tvo řeny těmito daty 
v následujícím po řadí: 
Data  Formát  Bajt ů Popis  
CPI INTEGER 
(celé číslo) 1 Identifikátor profilu certifi ­
kátu (pro tuto verzi ‘01’)  
CAR  OCTET 
STRING  8 Odkaz na certifika ční auto­
ritu 
CHA  OCTET 
STRING  7 Autorizace držitele certifi ­
kátu ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 368  
Data  Formát  Bajt ů Popis  
EOV  TimeReal  4  Konec platnosti certifikátu. 
Volitelné, dopln ěno 
pomocí ‘FF’ pokud se 
nepoužije.  
CHR  OCTET 
STRING  8 Odkaz na držitele certifi ­
kátu 
n OCTET 
STRING  128 Ve řejný klíč (modul)  
e OCTET 
STRING  8 Ve řejný klí č (veřejný 
exponent)  
164 
Poznámky:  
1. „Identifikátor profilu certifikátu“ (CPI) stanovuje p řesnou strukturu 
certifikátu ov ěření pravosti. M ůže být užit jako interní identifikátor 
zařízení pro odpovídající náv ěští, které popisuje řetězení prvků dat 
v certifikátu.  
Návěští spojené s obsahem tohoto certifikátu je následující: 
‘4D’  ‘16’  ‘5F 
29’ ‘01’ ‘42’  ‘08’  ‘5F 
4B’ ‘07’ ‘5F 
24’ ‘04’ ‘5F 
20’ ‘08’ ‘7F 
49’ ‘05’ ‘81’  ‘81 
80’ ‘82’ ‘08’
 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 identifikovat auto ­
ritu vydávající certifikát (CA) tak, aby prvek dat mohl být použit 
současně jako identifikátor klí če autority pro odkaz na ve řejný klíč 
certifikační autority (pro kódování viz níže identifikátor klí če). 
3. „Autorizace držitele certifikátu“ (CHA) se používá k identifikaci práv 
držitele certifikátu. Je tvo řena identifikací (ID) použití tachografu 
a typem za řízení, ke kterému je certifikát ur čen (podle prvku dat
  
, „00“ pro členský stát).  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 369  
4. „Odkaz na držitele certifikátu“ (CHR) má za ú čel jednozna čně iden­
tifikovat držitele certifikátu tak, aby mohl být užit prvek dat sou časně 
jako identifikátor klí če subjektu a odkazovat na ve řejný klíč držitele 
certifikátu.  
5. Identifikátory klí čů jednoznačně identifikují držitele certifikátu nebo 
certifikační autority. Jsou kódovány takto:  
5.1 Zařízení (VU nebo karta): 
Data  Výrobní 
číslo 
zařízení  Datum  Typ  Výrobce  
Délka  4 bajty  2 bajty  1 bajt  1 bajt  
Hodnota  Integer 
(celé 
číslo) Kódování BCD mm 
rr Specifické podle 
výrobce  Kód výrobce  
Při požadování certifikát ů pro VU výrobce m ůže, nebo nemusí 
znát identifikaci za řízení, do kterého budou klí če vloženy.  
V prvém p řípadě zašle výrobce identifikaci za řízení s veřejným 
klíčem autoritě svého členského státu k certifikaci. Certifikát bude 
v takovém p řípadě zahrnovat identifikaci za řízení a výrobce musí 
zajistit, aby klí če a certifikáty byly vloženy do uvažovaného 
zařízení. Identifikátor klí če má tvar uvedený výše.  
Ve druhém p řípadě musí výrobce jednozna čně identifikovat 
každý požadavek na certifikát a zaslat tuto identifikaci s ve řejným 
klíčem autoritě svého členského státu k certifikaci. Certifikát bude 
obsahovat identifikaci požadavku. Výrobce musí po instalaci klí če 
do zařízení sdělit orgánu svého členského státu p řiřazení klíče 
k zařízení (tj. identifikaci požadavku na certifikát, identifikaci 
zařízení). Identifikátor klí če má následující tvar: 
Data  Po řadové 
číslo 
požadavku 
na certifi­
ká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 — 26.02.2020 — 002.001 — 370  
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 certifikátu = Cc =  C  r || C  n 
106 bajtů 58 bajt ů 
Poznámky:  
1. Tento certifikát je dlouhý 194 bajt ů. 
2. K podpisu je dále p řipojen podpisem p řekrytý odkaz na certifika ční 
autoritu (CAR) tak, že ve řejný klíč certifikačního orgánu m ůže být 
vybrán pro ov ěření certifikátu.  
3. Ověřovatel certifikátu musí bezpodmíne čně znát algoritmus užívaný 
certifikační autoritou k podepisování certifikátu.  
4. Návěští spojené s vydaným certifikátem je následující: 
‘7F 21’  ‘09’  ‘5F 37’  ‘81 80’  ‘5F 38’  ‘3A’  ‘42’  ‘08’
 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 — 26.02.2020 — 002.001 — 371  
3.3.3  Ověření a rozbalení certifikátu  
Ověření a rozbalení certifikát ů zahrnuje ov ěření podpisu podle ISO/IEC 
9796-2, vyhledání obsahu certifikátu a obsaženého ve řejného klíče: X.PK 
= X.CA.PK  o X.C, a ověření platnosti certifikátu.  
CSM_019 Zahrnuje následující kroky:  
Ověřte podpis a vyvolejte obsah: 
— z X.C vyvolejte Sign, C  n ' a CAR':  X.C =  Sign  ||  C  n ' ||  CAR'  
128 bajtů 58 bajt ů 8 bajt ů 
— z CAR' vyberte p říslušný veřejný klíč certifikační autority 
(pokud již nebyl vybrán d říve jinými prost ředky),  
— otevřete Sign pomocí ve řejného klíče CA: Sr'= X.CA.PK 
[Sign],  
— ověření Sr'začíná na ‘6A’a kon čí na ‘BC’, 
— vypočítejte C  r ' a H'ze vztahu: Sr' =  ‘6A’  || C  r ' ||  H'  ||  ‘BC’  
106 bajtů 20 bajt ů 
— obnovte obsah certifikátu C' = C  r ' || C  n ', 
— ověřte Hash (C') = H'  
Pokud jsou ov ěření v pořádku, je certifikát pravý a jeho 
obsahem je C'.  
Ověřte platnost. Z C':  
— v příslušných p řípadech ov ěřte datum ukon čení platnosti.  
Z C' vyvolejte a uložte ve řejný klíč, identifikátor klí če, auto­
rizaci držitele certifikátu a konec platnosti certifikátu:  
— X.PK =  n || e 
— X.KID = CHR  
— X.CHA = CHA  
— X.EOV = EOV  
4. MECHANISMUS VZÁJEMNÉHO OV ĚŘOVÁNÍ PRAVOSTI  
Vzájemné ov ěřování pravosti mezi kartami a VU je založeno na násle ­
dujícím principu:  
Každá strana musí druhé stran ě prokázat, že vlastní platný pár klí čů, 
z něhož veřejný klíč byl certifikován certifika ční autoritou členského 
státu, která sama byla certifikována Evropským certifika čním úřadem.  
Prokazuje se podpisem se soukromým klí čem na náhodn ě vybraném čísle 
zaslaném druhou stranou, která musí zaslané náhodné číslo při ověřování 
tohoto podpisu získat zp ět. 
Mechanismus se aktivuje vložením karty do VU. Mechanismus za číná 
výměnou certifikát ů a rozbalením ve řejných klí čů a končí nastavením 
klíče relace.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 372  
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 — 26.02.2020 — 002.001 — 373
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 374  
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řed­
nictvím bezpe čného předávání zpráv s odkazem na normy 
[ISO/IEC 7816-4] a [ISO/IEC 7816-8].  
CSM_022 Pokud je t řeba data v pr ůběhu přenosu chránit, musí se 
k datovým objekt ům zasílaným v p říkazech nebo odpov ědích 
připojit datový objekt kryptografický kontrolní sou čet (Cryp­
tographic Checksum). Kryptografický kontrolní sou čet je 
kontrolován p říjemcem.  
CSM_023 Kryptografický kontrolní sou čet zaslaný v rámci p říkazu 
musí zahrnovat záhlaví p říkazu a veškeré odeslané datové 
objekty (=>CLA = ‘0C’ a veškeré datové objekty musí být 
uzavřeny tagy, ve kterých b1=1).  
CSM_024 Pokud odpov ěď neobsahuje datové pole, musí být stavové 
informační bajty ochrán ěny kryptografickým kontrolním 
součtem. 
CSM_025 Kryptografický kontrolní sou čet musí být dlouhý čtyři bajty.  
Struktura p říkazů a odpovědí při použití bezpe čného před­
ávání zpráv je proto následující:  
Užité objekty DO jsou částečné soubory bezpe čného před­
ávání zpráv datových objekt ů podle popisu v ISO/IEC 
7816-4:  
Tag Symbol  Význam  
‘81’ T  PV Otevřená hodnota, nikoliv kódovaná data BER-TLV 
(chráněno pomocí CC)  
‘97’ T  LE Hodnota Le v nechrán ěném příkazu (chrán ěno 
pomocí CC)  
‘99’ T  SW Status-Info (chrán ěno pomocí CC)  
‘8E’ T  CC Kryptografický kontrolní sou čet 
‘87’ T  PI CG  Bajtový indikátor napln ění || Kryptogram (otev řená 
hodnota nekódovaná v BER-TLV)  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 375  
Z nechráněného páru odpov ědi na příkaz vychází:  
Záhlaví příkazu  T ělo příkazu  
CLA  INS  P1  P2  [L  c field]  [Data field]  [L  e field]  
čtyři bajty  L bajty, ozna čené jako B  1 až B  L 
Tělo odpovědi Konec odpov ědi 
[Data field]  SW1  SW2  
L r datové bajty  dva bajty  
Odpovídající pár zabezpe čené odpov ědi na příkaz:  
Zabezpečený příkaz:  
Záhlaví příkazu (CH)  T ělo příkazu  
CLA  INS  P1  P2  [New L  c field]  [New Data field]  [New L  e 
field]  
‘OC’  Délka New Data 
field T PV L PV PV T  LE L LE L e T CC L CC CC ‘00’  
‘81’ L  c Datové pole  ‘97’  ‘01’  L  e ‘8E’ ‘04’  CC  
Data, která mají být zahrnuta do kontrolního sou čtu = CH || 
PB || T  PV || L  PV || PV || T  LE || L  LE || L  e || PB  
PB = dopl ňkové bajty (80 .. 00) podle ISO-IEC 7816-4 
a ISO 9797 metoda 2.  
PV a LE z objekt ů DO jsou p řítomny pouze tehdy, pokud 
jsou odpovídající data umíst ěna v nezabezpe čeném příkazu.  
Zabezpečená odpov ěď: 
1. Případ, kdy datové pole odpov ědi není prázdné a nepot ře­
buje být chrán ěno na důvěrnost:  
Tělo odpovědi Konec odpov ědi 
[New Data field]  Nové SW1 SW2  
T PV L PV PV T  CC L CC CC 
‘81’ L  r Datové pole  ‘8E’  ‘04’  CC  
Data, která mají být zahrnuta do kontrolního sou čtu = T  PV 
|| L  PV || PV || PB  
2. Případ, kdy datové pole odpov ědi není prázdné a pot řebuje 
být chráněno na důvěrnost:  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 376  
Tělo odpovědi Konec odpov ědi 
[New Data field]  Nové SW1 SW2  
T PI CG  L PI 
CG PI CG  T  CC L CC CC 
‘87’ PI || CG  ‘8E’  ‘04’  CC  
Data v CG: nekódovaná data BER-TLV a bajty dopln ění. 
Data, která mají být zahrnuta do kontrolního sou čtu = T  PI 
CG || L  PI CG  || PI CG || PB  
3. Případ, kdy je datové pole odpov ědi prázdné:  
Tělo odpovědi Konec odpov ědi 
[New Data field]  nové SW1 SW2  
T SW L SW SW T  CC L CC CC 
‘99’ ‘02’  Nové SW1 SW2  ‘8E’  ‘04’  CC  
Data, která mají být zahrnuta do kontrolního sou čtu = 
T SW || L  SW || SW || PB  
5.2. Zacházení s chybami v bezpe čném předávání zpráv (SM)  
CSM_026 Když karta tachografu p ři interpretaci p říkazu zjistí chybu 
SM, pak se bajty statusu musí vrátit bez SM. Podle ISO/IEC 
7816-4 jsou pro indikaci chyb SM definovány následující 
bajty statusu:  
‘66 88’ selhalo ov ěření kryptografického kontrolního sou čtu, 
‘69 87’ chybí o čekávané datové objekty SM,  
‘69 88’ datové objekty SM nesprávné.  
CSM_027 Pokud karta tachografu vrátí bajty statusu bez SM DO nebo 
s chybným SM DO, musí VU relaci p řerušit.  
5.3. Algoritmus výpo čtu kryptografického kontrolního sou čtu 
CSM_028 Kryptografické kontrolní sou čty jsou tvo řeny užitím obvy ­
klého MAC podle ANSI X.9.19 s DES:  
— Výchozí stav: výchozím zkušebním blokem y0 je E(Ka, 
SSC).  
— Následující krok: Kontrolní bloky y1, .., yn se vypo čtou 
pomocí Ka.  
— Konečný krok: kryptografický kontrolní sou čet se 
vypočte z posledního zkušebního bloku yn takto: E(Ka, 
D(Kb, yn)).  
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. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 377  
CSM_029 V pr ůběhu odsouhlasení klí če se „čítač odeslané posloup ­
nosti“ (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 — 26.02.2020 — 002.001 — 378  
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 
datových blok ů podle specifikace dopl ňku 7 – Protokoly 
stahování dat.  
CSM_033 Digitální podpisy stažených dat musí užívat schéma digitál ­
ního podpisu s dodatkem tak, aby stažená data mohla být 
v případě požadavku čtena bez jakéhokoliv dešifrování.  
6.1. Generování podpisu  
CSM_034 Generování dat podpisu za řízením probíhá podle schématu 
podpisu s dodatkem definovaného v odkazu [PKCS1] s hašo ­
vací funkcí SHA-1:  
Podpis = EQT.SK[‘00’ || ‘01’ ||  PS || ‘00’ || DER(SHA-1(Da ­
ta))] 
PS = doplňkový řetězec oktetů s hodnotou ‘FF’ takový, aby 
délka byla 128.  
DER(SHA-1( M)) je kódováním algoritmu ID pro hašovací 
funkci a hodnotou hash do hodnoty ASN.1 typu DigestInfo 
(zvláštní kódovací pravidla):  
‘30’||‘21’||‘30’||‘09’||‘06’||‘05’ ||‘2B’||‘0E’||‘03’||‘02’||‘1A’|| 
‘05’||‘00’||‘04’||‘14’||hodnota Hash.  
6.2. Ověření podpisu  
CSM_035 Ov ěření dat podpisu stažených dat probíhá podle schématu 
podpisu s dodatkem definovaného v odkazu [PKCS1] s hašo ­
vací funkcí SHA-1.  
Evropský klí č EUR.PK musí být ov ěřujícímu znám z nezá ­
vislé (a důvěryhodné) strany.  
Následující tabulka zobrazuje protokol, podle kterého m ůže 
IDE s kontrolní kartou ov ěřit integritu stažených dat ulože ­
ných na externí pam ěťové médium (ESM). Pro dešifrování 
digitálních podpis ů se užije kontrolní karta. Tato funkce 
nemá být v tomto p řípadě zahrnuta do IDE.  
Zařízení, které data, jež se mají analyzovat, stáhlo a pode ­
psalo, se ozna čí jako EQT.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 379
  
ČÁST B  
SYSTÉM TACHOGRAFU DRUHÉ GENERACE  
7. ÚVOD  
7.1. Zdroje  
V této části dodatku jsou užívány následující odkazy.  
AES National Institute of Standards and Technology (NIST), 
FIPS PUB 197: Advanced Encryption Standard (AES), 
listopad 26, 2001  
DSS National Institute of Standards and Technology (NIST), 
FIPS PUB 186-4: Digital Signature Standard (DSS), 
červenec 2013  
ISO 7816-4 ISO/IEC 7816-4, Identification cards – Integrated circuit 
cards – Part 4: Organization, security and commands for 
interchange. Third edition 2013-04-15  
ISO 7816-8 ISO/IEC 7816-8, Identification cards – Integrated circuit 
cards – Part 8: Commands for security operations. Second 
edition 2004-06-01  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 380  
ISO 8825-1 ISO/IEC 8825-1, Information technology – ASN.1 enco ­
ding rules: Specification of Basic Encoding Rules (BER), 
Canonical Encoding Rules (CER) and Distinguished 
Encoding Rules (DER). Fourth edition, 2008-12-15  
ISO 9797-1 ISO/IEC 9797-1, Information technology – Security tech ­
niques – Message Authentication Codes (MACs) – Part 1: 
Mechanisms using a block cipher. Second edition, 2011- 
03-01  
ISO 10116 ISO/IEC 10116, Information technology – Security tech ­
niques – Modes of operation of an  n-bit block cipher. 
Third edition, 2006-02-01  
ISO 16844-3 ISO/IEC 16844-3, Road vehicles – Tachograph systems – 
Part 3: Motion sensor interface. First edition 2004, inclu ­
ding Technical Corrigendum 1 2006  
RFC 5480 Elliptic Curve Cryptography Subject Public Key Informa ­
tion, March 2009  
RFC 5639 Elliptic Curve Cryptography (ECC) – Brainpool Standard 
Curves and Curve Generation, 2010  
RFC 5869 HMAC-based Extract-and-Expand Key Derivation Func ­
tion (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 — 26.02.2020 — 002.001 — 381  
IDE inteligentní vyhrazené za řízení  
K M hlavní klíč snímače pohybu, umož ňující párování VU se 
snímačem pohybu  
K M-VU  klíč vložený do VU, umož ňující VU odvodit hlavní klí č 
snímače pohybu p ři vložení karty dílny do VU  
K M-WC  klíč vložený do karet dílny, umož ňující VU odvodit hlavní 
klíč snímače pohybu p ři vložení karty dílny do VU  
MAC kód ov ěřování zprávy  
MoS sníma č pohybu  
MSB nejd ůležitější bit  
PKI infrastruktura ve řejného klíče 
RCF za řízení vzdálené komunikace  
SSC čítač odeslané posloupnosti  
SM Bezpe čné předávání zpráv  
TDES trojitý standard šifrování dat  
TLV hodnota délky tagu  
VU celek ve vozidle  
X.C certifikát ve řejného klíče uživatele X  
X.CA certifika ční orgán, který vydal certifikát uživatele X  
X.CAR odkaz na certifika ční orgán uvedený v certifikátu uživatele 
X 
X.CHR odkaz na držitele certifikátu uvedený v certifikátu uživatele 
X 
X.PK ve řejný klíč uživatele X  
X.SK soukromý klí č uživatele X  
X.PK  eph přechodný ve řejný klíč uživatele X  
X.SK  eph přechodný soukromý klí č uživatele X  
‘xx’ hexadecimální hodnota  
|| operátor řetězení 
7.3. Definice  
Definice termín ů používaných v tomto dodatku jsou uvedeny v části 
I přílohy 1C.  
8. KRYPTOGRAFICKÉ SYSTÉMY A ALGORITMY  
8.1. Kryptografické systémy  
CSM_38 VU a karty tachografu musí užívat systém šifrování ve řej­
ného klíče na bázi eliptických k řivek k tomu, aby zajistily 
následující bezpe čnostní služby:  
— vzájemné ov ěřování pravosti mezi VU a kartou,  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 382  
— 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é dotazo ­
vací 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  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 383  
14. Vzdálené dotazovací za řízení však odesílá p řijatá 
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í 
podporovat kryptografii na bázi eliptických k řivek s veli ­
kostí klíče 256, 384 a 512/521 bit ů. 
CSM_46 VU, karty tachografu a vn ější zařízení GNSS musí 
podporovat podpisový algoritmus ECDSA podle ustano ­
vení [DSS].  
CSM_47 VU, karty tachografu a vn ější zařízení GNSS musí 
podporovat algoritmus odsouhlasení klí čů ECKA-EG 
podle ustanovení [TR 03111].  
CSM_48 VU, karty tachografu a vn ější zařízení GNSS musí 
podporovat všechny standardní parametry domén stano ­
vené 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 — 26.02.2020 — 002.001 — 384  
Poznámka:  Identifikátory objektu uvedené v posledním 
sloupci Tabulka 1 jsou stanoveny v [RFC 5639] pro 
křivky Brainpool a v [RFC 5480] pro k řivky NIST.
  
8.2.3  Hašovací algoritmy  
▼M1 
CSM_49 Celky ve vozidle, karty tachografu a vn ější zařízení GNSS 
musí podporovat algoritmy SHA-256, SHA-384 a SHA- 
512 stanovené v [SHS].  
▼B 
8.2.4  Šifrovací soustavy  
CSM_50 V p řípadě symetrického algoritmu se asymetrický algo ­
ritmus a/nebo hašovací algoritmus používají spole čně 
a vytvářejí bezpečnostní protokol, jejich p říslušné délky 
klíče a velikosti hash musí mít (zhruba) stejnou sílu. 
Tabulka 2 zobrazuje schválené sady šifer:  
Tabulka 2  
Povolené sady šifer  
ID sady šifer  Velikost klí če ECC 
(bity)  Délka klíče AES (bity)  Hašovací algorit ­
mus Délka MAC 
(bajty)  
CS#1  256  128  SHA-256  8  
CS#2  384  192  SHA-384  12  
CS#3  512/521  256  SHA-512  16  
Poznámka: Velkosti klí če ECC 512 bit ů a 521 bit ů jsou považovány, že jsou stejné síly pro 
všechny účely v rámci tohoto dodatku.  
9. KLÍ ČE A CERTIFIKÁTY  
9.1. Asymetrické páry klí čů a certifikáty ve řejných klí čů 
9.1.1  Obecné informace  
Poznámka: Klí če popisované v této části jsou používány pro vzájemné 
ověřování pravosti a bezpe čné předávání zpráv mezi VU a kartami tacho ­
grafu a mezi VU a vn ějšími zařízeními GNSS. Tyto procesy jsou 
podrobně popsány v kapitolách 10 a 11 tohoto dodatku.  
CSM_51 V rámci systému evropského inteligentního tachografu 
musí být páry klí čů ECC a p říslušné certifikáty genero ­
vány a spravovány prost řednictvím t ří funkčních hierar ­
chických úrovní:  
— evropské úrovn ě, 
— úrovně členských stát ů, 
— úrovně zařízení.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 385  
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 — 26.02.2020 — 002.001 — 386  
CSM_60 ERCA kdykoli zlikviduje tyto kryptografické klí če a certi­
fikáty:  
— Stávající pár klí čů EUR a příslušný certifikát  
— Všechny p ředchozí certifikáty EUR používané pro 
ověření dosud platných certifikát ů MSCA  
— Spojovací certifikáty pro všechny generace certifikát ů 
EUR s výjimkou prvního  
9.1.3  Úrove ň členských stát ů 
CSM_61 Na úrovni členských stát ů musí všechny členské státy, 
které podepisují certifikáty karet tachografu, generovat 
jeden nebo více jedine čných párů klíčů ECC ozna čených 
jako MSCA_Card. Všechny členské státy, které podepisují 
certifikáty pro VU nebo vn ější zařízení GNSS, musí navíc 
generovat jeden nebo více jedine čných párů klíčů ECC 
označených jako MSCA_VU-EGF.  
CSM_62 Úkol generování pár ů klíčů členského státu musí zajiš ťovat 
certifikační orgán členského státu (MSCA). Kdykoli 
MSCA generuje pár klí čů členského státu, odešle do 
ERCA veřejný klíč, aby obdržel p říslušný certifikát člen­
ského státu podepsaný ERCA.  
CSM_63 MSCA musí zvolit sílu páru klí čů členského státu odpoví ­
dající síle evropského ko řenového páru klí čů užívaného 
k podpisu p říslušného certifikátu členského státu.  
CSM_64 P řípadný pár klí čů MSCA_VU-EGF obsahuje soukromý 
klíč MSCA_VU-EGF.SK a ve řejný klíč MSCA_VU- 
EGF.PK. MSCA musí soukromý klí č MSCA_VU-EGF.SK 
užívat výhradn ě k podpisu certifikát ů veřejného klíče VU 
a vnějších zařízení GNSS.  
CSM_65 Pár klí čů MSCA_Card obsahuje soukromý klí č 
MSCA_Card.SK a ve řejný klíč MSCA_Card.PK. MSCA 
musí soukromý klí č MSCA_Card.SK užívat výhradn ě 
k podpisu certifikát ů veřejného klíče karet tachografu.  
CSM_66 MSCA musí udržovat záznamy všech podepsaných certi ­
fiká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 — 26.02.2020 — 002.001 — 387  
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 certifi­
ká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 — 26.02.2020 — 002.001 — 388  
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 — 26.02.2020 — 002.001 — 389  
— 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 kapitole 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 — 26.02.2020 — 002.001 — 390  
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 — 26.02.2020 — 002.001 — 391  
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 — 26.02.2020 — 002.001 — 392  
— 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 — 26.02.2020 — 002.001 — 393  
Poznámky k Obrázek 1:  
1. Různé generace ko řenového certifikátu jsou ozna čeny číslem v závor ­
kách. Nap ř. ERCA (1) je první generace ko řenového certifikátu 
ERCA; ERCA (2) je druhá generace atd.  
2. Ostatní certifikáty jsou ozna čeny dvěma čísly v závorkách, první 
z nich ozna čuje generaci ko řenového certifikátu, v níž jsou vydány, 
druhé generaci samotného certifikátu. Nap ř. MSCA_Card (1-1) je 
první certifikát MSCA_Card vydaný v rámci ERCA (1); MSCA_Card 
(2-1) je první certifikát MSCA_Card vydaný v rámci ERCA (2); 
MSCA_Card (2-last) je poslední certifikát MSCA_Card vydaný 
v rámci ERCA (2); Card_MA(2-1) je první certifikát Card pro 
vzájemné ov ěřování pravosti vydaný v rámci ERCA (2) atd.  
3. Certifikáty MSCA_Card (2-1) a MSCA_Card (1-last) jsou vydány 
téměř ke stejnému datu, ale nikoli úpln ě přesně. MSCA_Card (2-1) 
je první certifikát MSCA_Card vydaný v rámci ERCA (2) a bude 
vydán pon ěkud později než MSCA_Card (1-last), poslední certifikát 
MSCA_Card v rámci ERCA (1).  
4. Jak je zobrazeno na obrázku, první certifikát VU a certifikáty karty 
vydané v rámci ERCA (2) budou vydány tém ěř dva roky p řed 
vydáním posledního certifikátu VU a certifikátu karty vydaných 
v rámci ERCA (1). D ůvodem je skute čnost, že certifikát VU a certi ­
fikát karty jsou vydány v rámci certifikátu MSCA, nikoli p římo 
v rámci certifikátu ERCA. Certifikát The MSCA (2-1) bude vydán 
přímo po vstupu ERCA (2) v platnost, ale certifikát MSCA (1-last) 
bude vydán pouze nedlouho p řed touto dobou, v posledním 
okamžiku, kdy je certifikát ERCA (1) ješt ě platný. Tyto dva certifi ­
káty MSCA mají proto tém ěř stejnou dobu platnosti, a čkoli jsou 
zástupci různých generací.  
5. Doba platnosti uvedená pro karty je stejná jako pro karty řidiče 
(5 let).  
▼M1 
6. Z důvodu úspory místa je rozdíl doby platnosti mezi certifikáty 
Card_MA a Card_Sign uveden pouze pro první generaci.  
▼B 
9.2. Symetrické klí če 
9.2.1  Klíče pro zabezpe čení VU – komunikace sníma če pohybu  
9.2.1.1  Obecné informace  
Poznámka: Čtenáři této části by měli být seznámeni s obsahem [ISO 
16844-3] popisujícím rozhraní mezi celkem ve vozidle a sníma čem 
pohybu. Proces párování mezi VU a sníma čem pohybu je podrobn ě 
popsán v kapitole 12tohoto dodatku.  
CSM_100 Pro párování celk ů ve vozidle a sníma čů pohybu, pro 
vzájemné ov ěřování pravosti mezi celky ve vozidle a sníma či 
pohybu a pro šifrování komunikace mezi celky ve vozidle 
a snímači pohybu je zapot řebí řada symetrických klí čů podle 
Tabulka 3. Všechny tyto klí če jsou klí če AES s délkou 
odpovídající délce hlavního klí če snímače pohybu, který 
musí být spojen s délkou (p ředpokládaného) evropského 
kořenového páru klí čů podle popisu v CSM_50.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 394  
Tabulka 3  
Klíče pro zabezpe čení celku ve vozidle – komunikace sníma če pohybu  
Klíč Zna čka Generován  Metoda generace  Uložen kým  
Hlavní klí č snímače 
pohybu – část VU  K M-VU  ERCA  Náhodný výb ěr ERCA, MSCA ú častnící se 
vydávání certifikát ů VU, 
výrobci VU, celky ve vozidle  
Hlavní klí č snímače 
pohybu – část dílny  K M-WC  ERCA  Náhodný výb ěr ERCA, MSCA, výrobci karet, 
karty dílny  
Hlavní klí č snímače 
pohybu  K M Negenerovaný 
nezávisle  Vypočtená jako K  M = 
K M-VU  XOR K  M-WC  ERCA, MSCA ú častnící se 
vydávání klí čů snímačů pohybu 
(volitelně) (*) 
Identifikační klíč K  ID Negenerovaný 
nezávisle  Vypočtená jako K  ID =  
K M XOR CV, kde CV 
je specifkováno 
v CSM_106  ERCA, MSCA ú častnící se 
vydávání klí čů snímačů pohybu 
(volitelně) (*) 
Párovací klí č K  P Výrobce sníma če 
pohybu  Náhodný výb ěr Jeden sníma č pohybu  
Klíč relace  K  S VU (během páro­
vání VU a sníma če 
pohybu)  Náhodný výb ěr Jeden VU a jeden sníma č 
pohybu  
(*) Uložení K  M a K  ID je volitelné, protože tyto klí če lze odvodit z K  M-VU  , K  M-WC  a CV.  
CSM_101 Evropský ú řad kořenových certifikát ů (ERCA) musí gene ­
rovat K  M-VU  a K  M-WC  , dva náhodné a jedine čné klíče AES, 
z nichž lze vypo čítat hlavní klí č snímače pohybu K  M jako 
K M-VU  XOR K  M-WC  . ERCA musí na požádání sd ělit K  M, 
K M-VU  a K  M-WC  certifikačním orgán ům členských stát ů. 
CSM_102 ERCA musí každému hlavnímu klí či snímače pohybu K  M 
přidělit jedinečné číslo verze, které je rovn ěž použitelné pro 
ustavující klí če K  M-VU  a K  M-WC  a pro příslušný identifika ční 
klíč K ID . ERCA musí MSCA sd ělit číslo verze p ři zaslání 
K M-VU  a K  M-WC  . 
Poznámka:  Číslo verze se užívá pro rozlišování r ůzných 
generací t ěchto klíčů, jak je podrobn ě uvedeno v části 
9.2.1.2.  
CSM_103 Certifika ční orgán členského státu musí K  M-VU  společně 
s jeho číslem verze p ředat na požádání výrobc ům celků ve 
vozidle. Výrobci VU musí vložit K  M-VU  a jeho číslo verze 
do všech vyrobených VU.  
CSM_104 Certifika ční orgán členského státu musí zajistit, aby byl K  M- 
WC společně s číslem verze vložen do všech karet dílny 
vydaných v rámci jeho odpov ědnosti.  
Poznámky:  
— Viz popis datového typu
  
v dodatku 2.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 395  
— 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é apli­
kace, 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 — 26.02.2020 — 002.001 — 396  
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 
hlavní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 ře­
nového páru klí čů ERCA. To je znázorn ěno na Obrázek 2.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 397  
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 — 26.02.2020 — 002.001 — 398  
Poznámka:  To předpokládá, že v posledním roce doby plat ­
nosti certifikátu ERCA budou vydány sníma če pohybu se 
šifrovanými daty na základ ě tří různých generací K  M podle 
Obrázek 2.  
CSM_117 Ve vztahu k procesu popsanému v CSM_107 výše: Protože 
délka párovacího klí če K  P musí být spojena s délkou K  M 
(viz CSM_100), musí být výrobce sníma čů pohybu schopen 
generovat až t ři různé párovací klí če (různých délek) pro 
jeden sníma č pohybu v p řípadě, že následující generace 
K M mají různé délky. V takovém p řípadě musí výrobce 
zaslat MSCA každý párovací klí č. MSCA musí zajistit, 
aby byl každý párovací klí č zašifrován se správnou generací 
hlavního klí če snímače pohybu, tj. tím, který má stejnou 
délku.  
Poznámka:  V případě, že se výrobce sníma čů pohybu 
rozhodne generovat pro sníma č pohybu druhé generace 
párovací klí č na bázi TDES (viz CSM_111), musí výrobce 
MSCA oznámit, že pro šifrování tohoto párovacího klí če je 
třeba použít hlavní klí č snímače pohybu na bázi TDES. 
Délka klíče TDES m ůže být totiž stejná jako délka klí če 
AES, takže MSCA nem ůže usuzovat podle samotné délky 
klíče. 
CSM_118 Výrobce celk ů ve vozidle musí do každého celku ve vozidle 
vložit pouze jednu generaci K  M-VU  společně s jeho číslem 
verze. Tato generace K  M-VU  musí být spojena s certifikátem 
ERCA, na n ěmž jsou založeny certifikáty VU.  
Poznámky:  
— Celek ve vozidle založený na certifikátu ERCA generace 
X musí obsahovat pouze K  M-VU  generace  X, i když je 
vydán po za čátku doby platnosti certifikátu ERCA gene ­
race X+1 . To je znázorn ěno na Obrázek 2.  
— VU generace  X nemůže být párován se sníma čem 
pohybu generace  X-1. 
— Protože karty dílny mají dobu platnosti jednoho roku, 
důsledkem CSM_113 – CSM_118 je, že všechny karty 
dílny obsahují v okamžiku, kdy je vydán první VU 
obsahující nový K  M-VU  , již nový K  M-WC  . Tento VU je 
proto vždy schopen vypo čítat nový K  M . Do té doby 
bude navíc v ětšina nových sníma čů pohybu také obsa ­
hovat šifrovaná data na bázi nového K  M . 
9.2.2  Klíče pro zabezpe čení komunikace DSRC  
9.2.2.1  Obecné informace  
CSM_119 Pravost a d ůvěrnost dat p ředávaných z celku ve vozidle 
řídicímu orgánu prost řednictvím kanálu vzdálené komuni ­
kace DSRC musí být zajišt ěny pomocí sady klí čů AES 
vyhrazených p říslušným VU odvozených z jediného hlav ­
ního klíče DSRC, totiž KM  DSRC  . ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 399  
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 — 26.02.2020 — 002.001 — 400  
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í.  
▼B 
9.2.2.2  Výměna hlavního klí če DSRC  
CSM_129 Každý hlavní klí č DSRC je p řiřazen určité generaci ko řeno­
vého páru klí čů ERCA. ERCA proto musí vym ěnit hlavní 
klíč DSRC každých 17 let. Doba platnosti každé generace 
hlavního klí če DSRC musí za čínat dva roky p řed vstupem 
přiřazeného ko řenového páru klí čů ERCA v platnost a musí 
končit se skončením platnosti p řiřazeného ko řenového páru 
klíčů ERCA. To je znázorn ěno na Obrázek 3.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 401  
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 402  
Poznámka:  To předpokládá, že v posledním roce doby plat ­
nosti certifikátu ERCA budou vydány karty dílny se t řemi 
různými generacemi KM  DSRC  , jak je znázorn ěno na 
Obrázek 3.  
CSM_133 Výrobci celk ů ve vozidle musí do každého celku ve vozidle 
vložit pouze jednu sadu klí čů DSRC vyhrazených 
příslušným VU spole čně s jejich číslem verze. Tato sada 
klíčů musí být odvozena z generace KM  DSRC  spojené s certi ­
fikátem ERCA, na n ěmž jsou založeny certifikáty VU.  
Poznámky:  
— To předpokládá, že celek ve vozidle založený na certi ­
fikátu ERCA generace  X musí obsahovat pouze 
K_VU  DSRC  _ENC and K_VU  DSRC  _MAC generace  X, 
i když je VU vydán po za čátku doby platnosti certifikátu 
ERCA generace  X+1 . To je znázorn ěno na Obrázek 3.  
— Protože karty dílny mají dobu platnosti jeden rok 
a kontrolní karty dva roky, výsledkem CSM_131 – 
CSM_133 je, že všechny karty dílny a kontrolní karty 
obsahují nový hlavní klí č DSRC v okamžiku, kdy je 
vydán první VU obsahující klí če vyhrazené p říslušným 
VU na základ ě tohoto hlavního klí če. 
9.3. Certifikáty  
9.3.1  Obecné informace  
CSM_134 Všechny certifikáty v systému evropského inteligentního 
tachografu musí být samopopisné, kartou ov ěřitelné (CV) 
certifikáty podle [ISO 7816-4] a [ISO 7816-8].  
CSM_135  ►M1 Pro kódování datových objekt ů v certifikátech musí 
být použita zvláštní kódovací pravidla (DER) podle [ISO 
8825-1]. V tabulce 4 je uvedeno kompletní kódování certi ­
fikátů, včetně všech tag ů a délek v bajtech. ◄ 
Poznámka:  Toto kódování má za následek následující struk ­
turu hodnoty délky tagu (TLV):  
Tag: Tag je kódován v jednom nebo dvou oktetech 
a indikuje obsah.  
Délka: Délka je kódována jako nepodepsané celé číslo 
v jednom, dvou nebo t řech oktetech, což má za 
následek maximální délku 65 535 oktet ů. 
Používá se minimální po čet oktetů. 
Hodnota: Hodnota je kódována v nula nebo více oktetech  
9.3.2  Obsah certifikátu  
CSM_136 Všechny certifikáty musí mít strukturu uvedenou v profilu 
certifikátu v Tabulka 4.  
Tabulka 4  
Profil certifikátu verze 1  
Pole ID pole  Tag  Délka (bajty)  Datový typ ASN.1 
(viz dodatek 1)  
Certifikát ECC  C  ‘7F 21’  var  
Tělo certifikátu ECC  B  ‘7F 4E’  var  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 403  
Pole ID pole  Tag  Délka (bajty)  Datový typ ASN.1 
(viz dodatek 1)  
Identifikátor profilu 
certifikátu  CPI ‘5F 29’  ‘01’
  
Odkaz na certifika ční 
orgán  CAR  ‘42’  ‘08’
  
Autorizace držitele 
certifikátu  CHA  ‘5F 4C’  ‘07’
  
Veřejný klíč PK  ‘7F 49’  var  
Parametry domény  DP  ‘06’  var
  
Veřejný bod  PP  ‘86’  var
  
Odkaz na držitele 
certifikátu  CHR  ‘5F 20’  ‘08’
  
Datum ú činnosti 
certifikátu  CEfD  ‘5F 25’  ‘04’
  
Datum konce plat ­
nosti certifikátu  CExD  ‘5F 24’  ‘04’
  
Podpis certifikátu 
ECC  S ‘5F 37’  var
  
Poznámka:  ID pole se užívá v dalších částech tohoto 
dodatku pro ozna čení jednotlivých polí certifikátu, nap ř. 
X.CAR je odkaz na certifika ční orgán uvedený v certifikátu 
uživatele X.  
9.3.2.1 Identifikátor profilu certifikátu  
CSM_137 Certifikáty musí používat identifikátor profilu certifikátu pro 
označení používaného profilu certifikátu. Verze 1 podle 
Tabulka 4 musí být ozna čena hodnotou ‘00’.  
9.3.2.2 Odkaz na certifika ční orgán  
CSM_138 Odkaz na certifika ční orgán se užívá pro identifikaci ve řej­
ného klíče užívaného pro ov ěření podpisu certifikátu. Odkaz 
na certifika ční orgán proto musí být stejný jako odkaz na 
držitele certifikátu v certifikátu p říslušné certifika ční auto­
rity. 
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é.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 404  
CSM_140 Pro spojovací certifikát ERCA musí být odkaz na držitele 
certifikátu stejný jako CHR nového ko řenového certifikátu 
ERCA. Odkaz na certifika ční orgán pro spojovací certifikát 
musí být stejný jako CHR p ředchozího ko řenového certifi ­
kátu ERCA.  
9.3.2.3 Autorizace držitele certifikátu  
▼M1 
CSM_141 Autorizace držitele certifikátu se používá k identifikaci typu 
certifikátu. Obsahuje šest nejd ůležitějších bajtů ID aplikace 
tachografu kaskádov ě spojených s typem za řízení, čím je 
udán typ za řízení, pro n ěž je certifikát ur čen. V případě 
certifikátu VU, karty řidiče nebo karty dílny se typ za řízení 
používá také k rozlišení mezi certifikátem pro vzájemné 
ověření pravosti a certifikátem pro vytvá ření digitálních 
podpisů (viz bod 9.1 a dodatek 1, datový typ EquipmentTy ­
pe). 
▼B 
9.3.2.4 Ve řejný klíč 
Veřejný klíč obsahuje dva datové prvky: standardní parametry domény 
užívané s ve řejným klíčem v certifikátu a hodnotu ve řejného bodu.  
CSM_142 Datový prvek parametry domény musí obsahovat jeden 
z identifikátor ů objektu uvedených v Tabulka 1 pro ozna ­ 
čení odkazu na sadu standardních parametr ů domény.  
CSM_143 Datový prvek ve řejný bod musí obsahovat ve řejný bod. 
Veřejné body eliptických k řivek musí být konvertovány na 
oktetové řetězce podle [TR-03111]. Musí být použit nekom ­
primovaný kódovací formát. P ři získávání bodu eliptické 
křivky z jeho kódovaného formátu musí být vždy provedeny 
validace podle [TR-03111].  
9.3.2.5 Odkaz na držitele certifikátu  
CSM_144 Odkaz na držitele certifikátu je identifikátor pro ve řejný klíč 
poskytovaný v certifikátu. Užívá se pro ozna čení tohoto 
veřejného klíče v jiných certifikátech.  
CSM_145 Pro certifikáty karet a certifikáty vn ějších zařízení GNSS 
musí mít odkaz na držitele certifikátu datový typ
  
uvedený v dodatku 1.  
CSM_146 Pro celky ve vozidle výrobce p ři podání žádosti o certifikát 
může nebo nemusí znát specifické sériové číslo výrobce VU, 
pro nějž je tento certifikát a p říslušný soukromý klí č určen. 
V prvním p řípadě musí mít odkaz na držitele certifikátu 
datový typ
  podle dodatku 1. 
Ve druhém p řípadě musí mít odkaz na držitele certifikátu 
datový typ
  podle dodatku 1.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 405  
Poznámka:  Pro certifikát karty musí být hodnota CHR rovna 
hodnotě cardExtendedSerialNumber v EF_ICC; viz dodatek 
2. Pro certifikát EGF musí být hodnota CHR rovna hodnot ě 
sensorGNSSSerialNumber v EF_ICC; viz dodatek 14. Pro 
certifikát VU musí být hodnota CHR rovna prvku vuSerial ­
Number identifikace VuIdentification, viz dodatek 1, pokud 
výrobce v okamžiku podání žádosti o certifikát nezná speci ­
fické sériové číslo výrobce.  
▼B 
CSM_147 Pro certifikáty ERCA a MSCA musí mít odkaz na držitele 
certifikátu datový typ
  
podle dodatku 1.  
9.3.2.6 Datum ú činnosti certifikátu  
▼M1 
CSM_148 Datum ú činnosti certifikátu musí ozna čovat počáteční datum 
a délku doby platnosti certifikátu.  
▼B 
9.3.2.7 Datum konce platnosti certifikátu  
CSM_149 Datum konce platnosti certifikátu musí ozna čovat konečné 
datum a délku doby platnosti certifikátu.  
9.3.2.8 Podpis certifikátu  
CSM_150 Podpis certifikátu musí být vytvo řen na kódovaném t ěle 
certifikátu, v četně tagu a délky t ěla certifikátu. Podpisový 
algoritmus musí být ECDSA podle [DSS], který používá 
hašovací algoritmus spojený s velikostí klí če podepisujícího 
orgánu podle CSM_50. Formát podpisu musí být otev řený 
podle [TR-03111].  
9.3.3  Podání žádosti o certifikát  
CSM_151  ►M1 Při podání žádosti o certifikát musí MSCA zaslat 
ERCA tyto údaje: ◄ 
— identifikátor profilu požadovaného certifikátu,  
— odkaz na certifika ční orgán, který se má použít p ři 
podpisu certifikátu,  
— veřejný klíč, který má být podepsán.  
CSM_152 Krom ě údajů v CSM_151 musí MSCA zaslat ERCA 
v žádosti o certifikát tyto údaje, které ERCA umožní 
vytvořit odkaz na držitele certifikátu nového certifikátu 
MSCA:  
— číselný kód státu certifika ční autority (datový typ
  
stanovený v dodatku 1),  
— alfanumerický kód státu certifika ční autority (datový typ
  
stanovený v dodatku 1),  
— jednobajtové sériové číslo pro rozlišení r ůzných klíčů 
certifikační autority v p řípadě výměny klíčů, 
— dvoubajtové pole obsahující dopl ňkové informace 
příslušné certifika ční autority.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 406  
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 — 26.02.2020 — 002.001 — 407  
— 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 — 26.02.2020 — 002.001 — 408  
— Certifikát Card.Link.EUR je evropský ko řenový certifi ­
ká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í zkontrolovat, 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í certi ­
fiká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 certi ­
fiká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ít ­
nout certifikáty se skon čenou platností. Pro ov ěření aktuální 
platnosti certifikátu p ředloženého kartou musí VU užít své 
vnitřní hodiny.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 409  
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 — 26.02.2020 — 002.001 — 410  
— 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 — 26.02.2020 — 002.001 — 411  
— Certifikáty a ve řejné klíče VU.CA uvedené na obrázku se používají 
pro podpis certifikát ů VU a vn ějších zařízení GNSS. V části 9.1.3 
jsou označeny jako MSCA_VU-EGF.  
— Certifikát VU.CA.EUR uvedený na obrázku je evropský ko řenový 
certifikát, který je uveden v CAR certifikátu VU.CA.  
— Certifikát VU.Link uvedený na obrázku je p řípadný spojovací certi ­
fikát VU. Jak je uvedeno v části 9.1.2, jedná se o spojovací certifikát 
pro nový evropský ko řenový pár klí čů vytvořený ERCA a podepsaný 
předchozím evropským soukromým klí čem. 
— Certifikát VU.Link.EUR je evropský ko řenový certifikát, který je 
uveden v CAR certifikátu VU.Link.  
CSM_162 Jak je uvedeno v Obrázek 5, ov ěření řetězce certifikát ů 
celku ve vozidle se zahájí v okamžiku, kdy se celek ve 
vozidle pokouší nastavit vlastní ve řejný klíč pro používání 
v kartě tachografu. Pokud se to poda ří, znamená to, že karta 
v minulosti úsp ěšně ověřila řetězec certifikát ů VU a uložila 
certifikát VU pro budoucí pot řebu. V tomto p řípadě se 
certifikát VU nastaví pro použití a proces pokra čuje 
ověřením pravosti VU. Pokud karta certifikát VU nezná, 
VU postupn ě předloží certifikát VU.CA užívaný pro ov ěření 
certifikátu VU, certifikát VU.CA.EUR užívaný pro ov ěření 
certifikátu VU.CA a p řípadně spojovací certifikát, aby tak 
byl nalezen certifikát, který karta zná. Je-li takový certifikát 
nalezen, karta tento certifikát použije pro ov ěření přísluš­
ných certifikát ů VU, které jí jsou p ředloženy. Je-li tento 
krok úspěšný, VU nakonec nastaví sv ůj veřejný klíč pro 
užití v kart ě tachografu. Není-li úsp ěšný, VU kartu ignoruje.  
Poznámka: Existují t ři způsoby, jak m ůže karta poznat certi ­
fikát VU.CA.EUR:  
— certifikát VU.CA.EUR je stejný certifikát jako vlastní 
certifikát EUR karty,  
— certifikát VU.CA.EUR byl vydán d říve než vlastní certi ­
fikát EUR karty a karta tento certifikát obsahovala již 
při vydání (viz CSM_91),  
— certifikát VU.CA.EUR byl vydán až po vlastním certi ­
fikátu EUR karty a karta v minulosti p řijala spojovací 
certifikát z jiného celku ve vozidle, ov ěřila jej a uložila 
pro budoucí pot řebu. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 412  
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 — 26.02.2020 — 002.001 — 413  
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 — 26.02.2020 — 002.001 — 414  
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 toke ­
nem. ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 415  
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 — 26.02.2020 — 002.001 — 416  
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 — 26.02.2020 — 002.001 — 417  
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 velikost 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 — 26.02.2020 — 002.001 — 418  
10.5.2  Struktura bezpe čné zprávy  
CSM_188 Bezpe čné předávání zpráv musí užívat pouze datové objekty 
bezpečného předávání zpráv (viz [ISO 7816-4]) uvedené 
v Tabulka 5. V každé zpráv ě musí být tyto datové objekty 
použity v po řadí uvedeném v této tabulce.  
Tabulka 5  
Datové objekty bezpe čného předávání zpráv  
Název datového objektu  Tag  Přítomnost (Z)ávazná, 
(P)odmí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 — 26.02.2020 — 002.001 — 419  
— 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ý vyjad řuje 
původní hodnotu Le.  
▼M1 
CSM_191 Všechny datové objekty ur čené k šifrování musí být podle 
[ISO 7816-4] dopln ěny indikátorem dopl ňkového obsahu 
‘01’. Pro výpo čet MAC se datové objekty v APDU doplní 
podle [ISO 7816-4].  
Poznámka:  Doplňování pro bezpe čné předávání zpráv se 
vždy provádí pomocí vrstvy bezpe čného předávání zpráv, 
nikoli pomocí algoritm ů CMAC nebo CBC.  
Shrnutí a p říklady  
Příkaz APDU s použitým bezpe čným předáváním zpráv má v závislosti 
na příslušném nezabezpe čeném příkazu následující strukturu (DO je 
datový objekt):  
Případ 1: CLA INS P1 P2 || Lc' || DO „8E“ || Le  
Případ 2: CLA INS P1 P2 || Lc' || DO „97“ || DO„8E“ 
|| Le 
Případ 3 (sudý bajt INS): CLA INS P1 P2 || Lc' || DO „81“ || DO„8E“ 
|| Le 
Případ 3 (lichý bajt INS): CLA INS P1 P2 || Lc' || DO „B3“ || DO„8E“ 
|| Le 
Případ 4 (sudý bajt INS): CLA INS P1 P2 || Lc' || DO „81“ || DO„97“ 
|| DO„8E“ || Le  
Případ 4 (lichý bajt INS): CLA INS P1 P2 || Lc' || DO „B3“ || DO„97“ 
|| DO„8E“ || Le  
kde Le = ‘00’ nebo ‘00 00’ v závislosti na tom, zda jsou použita krátká 
pole délky nebo rozší řená pole délky; viz [ISO 7816-4].  
Odpověď APDU s použitým bezpe čným předáváním zpráv má 
v závislosti na p říslušné nezabezpe čené odpov ědi následující strukturu:  
Případ 1 nebo 3: DO „99“ || DO „8E“ || 
SW1SW2  
Případ 2 nebo 4 (sudý bajt 
INS) bez šifrování: DO „81“ || DO „99“ || DO 
„8E“ || SW1SW2  
Případ 2 nebo 4 (sudý bajt 
INS) se šifrováním: DO „87“ || DO „99“ || DO 
„8E“ || SW1SW2  
Případ 2 nebo 4 (lichý bajt 
INS) bez šifrování: DO „B3“ || DO „99“ || DO 
„8E“ || SW1SW2  
Poznámka:  Případ 2 nebo 4 (lichý bajt INS) se šifrováním se v komuni ­
kaci mezi VU a kartou nikdy nepoužívá.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 420  
Níže jsou uvedeny t ři příklady transformace APDU pro p říkazy se sudým 
kódem INS. Obrázek 8 znázor ňuje případ 4 příkazu APDU s ov ěřenou 
pravostí, obrázek 9 znázor ňuje případ 1 / p řípad 3 odpov ědi APDU 
s ověřenou pravostí a obrázek 10 znázor ňuje případ 2 / p řípad 4 odpo ­
vědi APDU se šifrováním a ov ěřenou pravostí.  
Obrázek 8  
Transformace p řípadu 4 p říkazu APDU s ov ěřenou pravostí
  
Obrázek 9  
Transformace p řípadu 1 / p řípadu 3 odpov ědi APDU s ov ěřenou pravostí
  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 421  
Obrázek 10  
Transformace p řípadu 2 / p řípadu 4 odpov ědi APDU se šifrováním a ov ěřenou pravostí
  
▼B 
10.5.3  Přerušení relace bezpe čného předávání zpráv  
CSM_192 Celek ve vozidle p řeruší aktuální relaci bezpe čného před­
ávání zpráv pouze v p řípadě, že je spln ěna některá z těchto 
podmínek:  
— přijme otevřenou odpov ěď APDU,  
— detekuje chybu bezpe čného předávání zpráv v odpov ědi 
APDU:  
— chybí o čekávaný datový objekt bezpe čného předávání 
zpráv, pořadí datových objekt ů je nesprávné nebo je 
zařazen neznámý datový objekt,  
— datový objekt bezpe čného předávání zpráv je 
nesprávný, nap ř. hodnota MAC je nesprávná, struk ­
tura 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 — 26.02.2020 — 002.001 — 422  
CSM_193 Karta tachografu p řeruší aktuální relaci bezpe čného před­
ávání zpráv pouze v p řípadě, že je spln ěna některá z těchto 
podmínek:  
— přijme otevřený příkaz APDU,  
— detekuje chybu bezpe čného předávání zpráv v p říkazu 
APDU:  
— chybí o čekávaný datový objekt bezpe čného předávání 
zpráv, pořadí datových objekt ů je nesprávné nebo je 
zařazen neznámý datový objekt,  
— datový objekt bezpe čného předávání zpráv je 
nesprávný, nap ř. hodnota MAC nebo struktura TLV 
je nesprávná,  
— je odpojena od napájení nebo resetována,  
— VU zahájí proces ov ěření pravosti VU,  
— je dosaženo mezního po čtu příkazů a příslušných odpo ­
vědí v rámci aktuální relace. Pro p říslušnou kartu tuto 
mezní hodnotu stanoví její výrobce s ohledem na bezpe č­
nostní požadavky použitého hardwaru s maximální 
hodnotou 240 p říkazů a příslušných odezev SM na 
relaci.  
▼B 
CSM_194 Na chybu SM reaguje karta tachografu takto:  
— Pokud v p říkazu APDU chybí n ěkteré očekávané datové 
objekty bezpe čného předávání zpráv, po řadí datových 
objektů je nesprávné nebo jsou za řazeny neznámé datové 
objekty, odpoví karta tachografu stavovými bajty ‘69 
87’. 
— Pokud je n ěkterý datový objekt bezpe čného předávání 
zpráv v příkazu APDU nesprávný, odpoví karta tacho ­
grafu bajty statusu ‘69 88’.  
V takovém p řípadě musí být bajty statusu znovu odeslány 
bez použití bezpe čného předávání zpráv.  
CSM_195 Pokud je relace bezpe čného předávání zpráv mezi VU 
a kartou tachografu p řerušena, VU a karta tachografu musí  
— bezpečně zlikvidovat uložené klí če relace,  
— okamžit ě navázat novou relaci bezpe čného předávání 
zpráv podle částí 10.2 – 10.5.  
CSM_196 Pokud se z jakéhokoli d ůvodu VU rozhodne znovu zahájit 
vzájemné ov ěřování pravosti v ůči vložené kart ě, musí být 
tento proces zahájen ov ěřením řetězce certifikát ů karty 
podle části 10.2 a pokra čovat v souladu s částmi 10.2 – 10.5.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 423  
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 tachografu p ři zohledn ění odchylek, vysv ětlení 
a doplňků uvedených v této kapitole. Zejména vzájemné 
ověření řetězců certifikátů, ověření pravosti VU a ov ěření 
pravosti čipu se musí provád ět podle pokyn ů v částech 
11.3 and 11.4.  
CSM_199 Komunikace mezi celkem ve vozidle a EGF se liší od komu ­
nikace mezi celkem ve vozidle a kartou v tom, že celek ve 
vozidle a EGF se musí p řed tím, než si budou moci b ěhem 
normálního provozu vym ěňovat data na bázi GNSS, spárovat 
v dílně. Proces párování je popsán v části 11.2.  
CSM_200 Pro komunikaci mezi celkem ve vozidle a EGF musí být 
užívány p říkazy a odezvy APDU podle [ISO 7816-4] 
a [ISO 7816-8]. P řesná struktura t ěchto APDU je stanovena 
v dodatku 2 této p řílohy.  
11.2.  Párování VU a externího za řízení GNSS  
CSM_201 Celek ve vozidle a EGF ve vozidle musí být spárovány 
v dílně. Během normálního provozu mohou komunikovat 
pouze celek ve vozidle a EGF, které byly spárovány.  
CSM_202 Párování celku ve vozidle a EGF je možné pouze v p řípadě, 
že celek ve vozidle je v kalibra čním módu. Párování musí 
být zahájeno celkem ve vozidle.  
CSM_203 Dílna m ůže kdykoli znovu spárovat celek ve vozidle s jiným 
EGF nebo stejným EGF. B ěhem nového párování musí VU 
ve své pam ěti bezpečně zlikvidovat stávající certifikát 
EGF_MA a uložit certifikát EGF_MA vn ějšího zařízení 
GNSS, s nímž má být párováno.  
CSM_204 Dílna m ůže kdykoli znovu spojit vn ější zařízení GNSS 
s jiným VU nebo stejným VU. B ěhem nového párování 
musí EGF ve své pam ěti bezpečně zlikvidovat stávající certi ­
fikát VU_MA a uložit certifikát VU_MA celku ve vozidle, 
s nímž má být párováno.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 424  
11.3.  Vzájemné ov ěření řetězce certifikát ů 
11.3.1  Obecné informace  
CSM_205 Vzájemné ov ěření řetězce certifikát ů mezi VU a EGF se 
provede pouze b ěhem párování VU a EGF v díln ě. Během 
normálního provozu spárovaného VU a EGF nejsou ov ěřo­
vány žádné certifikáty. VU a EGF musí naopak d ůvěřovat 
certifikátům, které uložily b ěhem párování a po ov ěření 
dočasné platnosti t ěchto certifikát ů. VU a EGF nesmí d ůvě­ 
řovat žádným jiným certifikát ům z důvodu ochrany komuni ­
kace VU – EGF b ěhem normálního provozu.  
11.3.2  Během párování VU – EGF  
CSM_206 B ěhem párování s EGF musí celek ve vozidle užívat 
protokol popsaný na Obrázek 4 ( části 10.2.1) pro ov ěření 
řetězce certifiká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 podepsaný p ředchozím evropským soukromým 
klíčem. 
— Certifikát Card.Link.EUR je evropský ko řenový certifi ­
ká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 — 26.02.2020 — 002.001 — 425  
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í 
certifikát VU, 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 podepsaný p řed­
chozím evropským soukromým klí čem. 
— Certifikát VU.Link.EUR je evropský ko řenový certifikát, 
který je uveden v CAR certifikátu VU.Link.  
CSM_209 Odchyln ě od požadavku CSM_167 musí EGF užívat pro 
ověření dočasné platnosti všech p ředložených certifikát ů 
čas GNSS.  
▼M1 
CSM_210 Jakmile vn ější zařízení GNSS ov ěří certifikát VU_MA, musí 
jej uložit pro použití b ěhem normálního provozu; viz bod 
11.3.3.  
▼B 
11.3.3  Během normálního provozu  
CSM_211  ►M1 Během normálního provozu musí celek ve vozidle 
a EGF používat protokol uvedený na obrázku 11 pro ov ěření 
dočasné platnosti uloženého certifikátu EGF_MA a pro 
nastavení 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 — 26.02.2020 — 002.001 — 426  
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á komuni ­
kace prost řednictvím bezpe čného předávání zpráv však 
pokračuje normáln ě. 
11.4.  Ověřování pravosti VU,, ov ěřování pravosti čipu a odsouhlasení klí če 
relace  
CSM_213 Ov ěřování pravosti VU, ov ěřování pravosti čipu a odsouhla ­
sení klíče relace mezi VU a EGF se provádí b ěhem párování 
a při každém obnovení relace bezpe čného předávání zpráv 
během normálního provozu. VU a EGF musí provád ět 
postupy popsané v částech 10.3 a 10.4. Platí všechny poža ­
davky uvedené v t ěchto částech.  
11.5.  Bezpe čné předávání zpráv  
CSM_214 Všechny p říkazy a odezvy vym ěňované mezi celkem ve 
vozidle a vn ějším zařízením GNSS po úsp ěšném ověření 
pravosti čipu a do skon čení relace musí být chrán ěny 
bezpečným předáváním zpráv pouze v módu ov ěřování 
pravosti. Platí všechny požadavky v bod ě 10.5.  
CSM_215 P ři přerušení relace bezpe čného předávání zpráv mezi VU 
a EGF musí VU okamžit ě vytvořit novou relaci bezpe čného 
předávání zpráv, jak je uvedeno v části 11.3.3 a 11.4.  
12. PÁROVÁNÍ A KOMUNIKACE VU – SNÍMA Č POHYBU  
12.1.  Obecné informace  
CSM_216 Celek ve vozidle a sníma č pohybu musí b ěhem párování 
a za normálního provozu komunikovat pomocí protokolu 
rozhraní uvedeného v [ISO 16844-3] se zm ěnami uvedenými 
v této kapitole a v části 9.2.1.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 427  
Poznámka: Čtenáři této kapitoly by m ěli být seznámeni 
s obsahem [ISO 16844-3].  
12.2.  Párování VU – sníma č pohybu pomocí r ůzných generací klí čů 
Jak je uvedeno v části 9.2.1, hlavní klí č snímače pohybu a všechny 
související klí če jsou pravideln ě vyměňovány. To znamená, že v kartách 
dílny jsou sou časně až tři klíče AEC K  M-WC  pro snímač pohybu (násled ­
ných generací klí če). Podobn ě mohou být ve sníma čích pohybu až t ři 
různé druhy šifrování dat na bázi AES (podle následných generací hlav ­
ního klíče snímače pohybu K  M ). Celek ve vozidle obsahuje pouze jeden 
klíč K M-VU  pro snímač pohybu.  
CSM_217 VU druhé generace a sníma č pohybu druhé generace musí 
být párovány takto (viz tabulka 6 v [ISO 16844-3]):  
1. Karta dílny druhé generace je vložena do VU a VU je 
spojen se sníma čem pohybu.  
2. VU čte všechny dostupné klí če K  M-WC  z karty dílny, 
kontroluje jejich čísla verze klí če a zvolí to, které odpo ­
vídá číslu verze klí če VU K  M-VU  . Není-li odpovídající 
klíč K M-WC  na kartě dílny, VU p řeruší párovací proces 
a držiteli karty dílny zobrazí p říslušné chybové hlášení.  
3. VU vypo čítá hlavní klí č snímače pohybu K  M z K  M-VU  
a K  M-WC  a identifika ční klíč K ID zK M , jak je uvedeno 
v části 9.2.1.  
4. VU odešle sníma či pohybu pokyn pro zahájení párova ­
cí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šifruje 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áro ­
vací informace stejná informace, jakou sníma či pohybu 
odeslal v p ředchozím kroku. Pokud ano, znamená to, že  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 428  
snímač 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 generací 2 K  M , 
— K  P [3]: svůj párovací klí č generace 3, šifrovaný 
s generací 3 K  M , 
— předpokládejme, že karta dílny byla vydána v prvním 
roce platnosti certifikátu ERCA (3). Bude proto obsa ­
hovat generaci 2 a generaci 3 klí če K  M-WC  . 
— předpokládejme, že VU je generace 2, obsahující gene ­
raci 2 klíče K  M-VU  . 
V tomto p řípadě proběhnou v krocích 2 – 5 tyto operace:  
— Krok 2: VU p řečte klíče K  M-WC  generace 2 a generace 3 
z karty dílny a zkontroluje jejich čísla verze.  
— Krok 3: VU spojí klí č K M-WC  generace 2 se svým K  M-VU  
a vypočítá K  M a K  ID . 
— Krok 4: VU zašifruje sériové číslo, které p řijme ze 
snímače pohybu, s klí čem K  ID . 
— Krok 5: Sníma č pohybu porovná p řijatá data s N  s [1] 
a nezjistí shodu. Potom porovná data s N  s [2] a zjistí 
shodu. Dojde k záv ěru, že VU je generace 2, a proto 
odešle zpět K  P [2]. ▼B 
( 1 ) Párovací klí če generace 1, generace 2 a generace 3 mohou být ve skute čnosti stejný klí č 
nebo mohou být t řemi různými klíči s různými délkami, jak je uvedeno v CSM_117.
 02016R0799 — CS — 26.02.2020 — 002.001 — 429  
12.3.  Párování a komunikace VU – sníma č pohybu pomocí AES  
CSM_218 Jak je uvedeno v Tabulka 3 v části 9.2.1, všechny klí če 
použité v párování celku ve vozidle (druhé generace) 
a snímače pohybu a v následné komunikaci jsou klí če 
AES, a nikoli klí če TDES dvojité délky podle [ISO 
16844-3]. Tyto klí če AES mohou mít délku 128, 192 nebo 
256 bitů. Protože velikost bloku AES je 16 bajt ů, musí být 
délka šifrované zprávy násobkem 16 bajt ů na rozdíl od 8 
bajtů pro TDES. N ěkteré z těchto zpráv budou navíc použity 
pro přenos klíčů AES, jejichž délka m ůže být 128, 192 nebo 
256 bitů. Proto se po čet datových bajt ů na instrukci v tabulce 
5 [ISO 16844-3] zm ění, jak je uvedeno v Tabulka 6:  
▼M1 
Tabulka 6  
Počet bajtů otevřeného textu a šifrovaných dat na instrukci podle [ISO 16844-3]  
Instrukce  Požadavek/ 
odpověď Popis dat  Počet bajtů otevře­
ných dat podle 
[ISO 16844-3]  Počet bajtů otevře­
ných dat s použitím 
klíčů AES  Počet bajtů otevřených dat 
s použitím klí čů AES 
s bitovou délkou  
128 192  256  
10 požadavek  Data ov ěření pravosti 
+ číslo souboru  8 8  16  16  16  
11 odpov ěď Data ov ěření pravosti 
+ obsah souboru  16 nebo 32, podle 
souboru  16 nebo 32, podle 
souboru  32 / 48  32 / 48  32 / 48  
41 požadavek  Sériové číslo MoS  8  8  16  16  16  
41 odpov ěď Párovací klí č 16  16 / 24 / 32  16  32  32  
42 požadavek  Klíč relace  16  16 / 24 / 32  16  32  32  
43 požadavek  Párovací informace  24  24  32  32  32  
50 odpov ěď Párovací informace  24  24  32  32  32  
70 požadavek  Data ov ěření pravosti  8  8  16  16  16  
80 odpov ěď Hodnota čítače MoS 
+ data ov ěření 
pravosti  8 8  16  16  16  
▼B 
CSM_219 Párovací informace, které jsou zaslány v instrukcích 43 
(žádost VU) a 50 (odpov ěď MoS), musí být sestaveny, jak 
je uvedeno v části 7.6.10 [ISO 16844-3], s tou výjimkou, že 
ve schématu šifrování pro párování se místo algoritmu TDES 
použije algoritmus AES, což vede ke dv ěma šifrováním AES 
a doplňování podle CSM_220 se upraví tak, aby byla 
dodržena délka bloku AES. Klí č K' p použitý pro toto šifro ­
vání musí být generován takto:  
— v případě párovacího klí če K  P s délkou 16 bajt ů: K'  p = 
K P XOR (N  s ||N s ) ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 430  
— v případě párovacího klí če K  P s délkou 24 bajt ů: K'  p = 
K P XOR (N  s ||N s ||N s ) 
— v případě párovacího klí če K  P s délkou 32 bajt ů: K'  p = 
K P XOR (N  s ||N s ||N s ||N s ) 
kde N  s je 8-bajtové sériové číslo snímače pohybu.  
CSM_220 V p řípadě, že délka otev řeného textu (s použitím klí če AES) 
není násobkem 16 bajt ů, použije se metoda dopl ňování 2 
stanovená v [ISO 9797-1].  
Poznámka:  V [ISO 16844-3] je po čet bajtů otevřeného textu 
vždy násobkem 8, proto p ři použití TDES není dopl ňování 
nutné. Tato část tohoto dodatku nem ění definici dat a zpráv 
v [ISO 16844-3], proto je t řeba použít metodu dopl ňování.  
CSM_221 Pro instrukci 11 a v p řípadě, že musí být šifrován více než 
jeden blok, se použije mód řetězení šifrového textu podle 
[ISO 10116] s vloženým parametrem  m = 1. Použitý IV je:  
— pro instrukci 11: 8-bajtový blok ov ěření pravosti 
uvedený v části 7.6.3.3 [ISO 16844-3], dopln ěný pomocí 
metody dopl ňování 2 podle [ISO 9797-1]; viz rovn ěž 
část 7.6.5 a 7.6.6 [ISO 16844-3],  
— pro všechny ostatní instrukce, v nichž je p řesunuto více 
než 16 bajt ů, jak je uvedeno v Tabulka 6: ‘00’ {16}, tj. 
šestnáct bajt ů s binární hodnotou 0.  
Poznámka:  Jak je uvedeno v části 7.6.5 a 7.6.6 [ISO 
16844-3], když MoS šifruje datové soubory pro za řazení 
do instrukce 11, je blok prokázání pravosti:  
— použit jako inicializa ční vektor pro šifrování datových 
souborů v módu CBC,  
— zašifrován a za řazen jako první blok do dat, která jsou 
odeslána do VU.  
12.4.  Párování VU – sníma č pohybu pro r ůzné generace za řízení  
CSM_222 Jak je uvedeno v části 9.2.1, sníma č pohybu druhé generace 
může obsahovat šifrování párovacích dat na bázi TDES 
(podle části A tohoto dodatku), které umož ňuje párování 
snímače pohybu s VU první generace. V tomto p řípadě 
musí být VU první generace a sníma č pohybu druhé gene ­
race 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 — 26.02.2020 — 002.001 — 431  
— Pro párování VU druhé generace a sníma če pohybu nelze 
použít kartu dílny první generace.  
13. BEZPE ČNOST VZDÁLENÉ KOMUNIKACE PROST ŘEDNICTVÍM 
DSRC  
13.1.  Obecné informace  
Jak je uvedeno v dodatku 14, VU pravideln ě generuje data vzdáleného 
sledování tachografu (RTM) a odesílá tato data (internímu nebo exter ­
nímu) zařízení vzdálené komunikace (RCF). Za řízení vzdálené komuni ­
kace je odpov ědné za odesílání t ěchto dat p řes rozhraní DSRC podle 
dodatku 14 do vzdáleného dotazovacího za řízení. Dodatek 1 stanoví, 
že data RTM jsou kaskádovým spojením:  
šifrovaného vytížení tachografu  šifrování otev řeného přenosu dat tacho ­
grafu,  
bezpečnostních dat DSRC  uvedených níže.  
Datový formát otev řeného přenosu dat tachografu je uveden v dodatku 1 
a dále popsán v dodatku 14. Tato část popisuje strukturu bezpe čnostních 
dat DSRC; formální specifikace jsou uvedeny v dodatku 1.  
CSM_223 Otev řený text
  p ředávaný z VU do 
zařízení vzdálené komunikace (je-li RCF v ůči VU externí 
jednotkou) nebo z VU do vzdáleného dotazovacího za řízení 
přes rozhraní DSRC (je-li RCF v ůči VU interní jednotkou) 
musí být chrán ěna v módu šifrování a následného ov ěření 
pravosti, tj. p řenášená data tachografu jsou nejprve šifrována 
pro zajištění důvěrnosti zprávy a následn ě je vypočítán MAC 
pro zajištění pravosti a integrity.  
CSM_224 Bezpe čnostní data DSRC musí obsahovat kaskádové spojení 
následujících datových prvk ů v níže uvedeném po řadí; viz 
také Obr. 12:  
Aktuální datum čas aktuální datum a čas VU (datový typ
  ),  
Čítač 3-bajtový čítač, viz CSM_225  
▼M1 
Sériové číslo VU  sériové číslo VU nebo identifikátor žádosti o certifikát 
(datový typ VuSerialNumber nebo CertificateRequestID) 
– viz CSM_123  
▼B 
Číslo verze hlavního klí če DSRC  1-bajtové číslo verze hlavního klí če DSRC, z n ěhož se 
odvozují klí če DSRC pro p říslušné VU, viz část 9.2.2.  
MAC  MAC vypo čítaný ze všech p ředchozích bajt ů v datech 
RTM.  
CSM_225 3-bajtový čítač v bezpečnostních datech DSRC musí být ve 
formátu MSB-first. Když VU po uvedení do provozu poprvé 
vypočítá sadu dat RTM, nastaví hodnotu čítače na 0. Před 
každým výpo čtem nové sady dat RTM zvýší VU hodnotu 
dat čítače o 1.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 432  
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ředchozí 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 — 26.02.2020 — 002.001 — 433  
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ále ­
nému dotazovacímu za řízení.  
CSM_229 Pro zabrán ění opakovaným útok ům musí vzdálené dotazo ­
vací 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 — 26.02.2020 — 002.001 — 434  
— 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 ů 
stahovaných dat musí být ECDSA podle [DSS] s použitím 
hašovací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 
certifiká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 uvede ­
ného v [DSS]. V obou p řípadech je u každého certifikátu 
přečteného z datového souboru pot řeba ověřit, zda je pole 
autorizace 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 — 26.02.2020 — 002.001 — 435  
— 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 řed­
chozí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 — 26.02.2020 — 002.001 — 436  
Obrázek 13  
Protokol pro ov ěření podpisu staženého datového souboru
  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 437  
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  
1.2 Zkratky a notace  
2. SPECIFIKACE P ŘIJÍMAČE GNSS  
3. VĚTY NMEA  
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  
4.3 Vazba, vzájemné ov ěření pravosti a dohoda na klí či relace mezi vn ějším 
zařízením GNSS a celkem ve vozidle  
4.4 Zpracování chyb  
4.4.1 Chyba komunikace s vn ějším zařízením GNSS  
4.4.2 Narušení fyzické integrity vn ějšího zařízení GNSS  
4.4.3 Chybí informace o poloze z p řijímače GNSS  
4.4.4 Skon čení platnosti certifikátu vn ějšího zařízení GNSS  
5. CELEK VE VOZIDLE BEZ VN ĚJŠÍHO ZA ŘÍZENÍ GNSS  
5.1 Konfigurace  
5.2 Zpracování chyb  
5.2.1 Chybí informace o poloze z p řijímače GNSS  
6. NESOULAD ČASU GNSS  
7. NESOULAD ÚDAJ Ů O POHYBU VOZIDLA  
1. ÚVOD  
Tento dodatek stanoví technické požadavky na údaje GNSS používané 
celkem ve vozidle, v četně protokolů, které je třeba implementovat k zajiš ­
tění zabezpe čeného a správného p řenosu dat s informacemi o poloze.  
Hlavními články nařízení (EU) č. 165/2014 ur čujícími tyto požadavky 
jsou: článek 8 „Zaznamenávání polohy vozidla v ur čitých místech b ěhem 
denní pracovní doby“, článek 10 „Rozhraní s inteligentními dopravními 
systémy“ a článek 11 „Podrobná ustanovení pro inteligentní tachografy“.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 438  
1.1 Oblast p ůsobnosti  
GNS_1 Za ú čelem provád ění článku 8 shromaž ďuje celek ve vozidle 
údaje o poloze nejmén ě z jednoho globálního družicového navi ­
gačního systému.  
Celek ve vozidle m ůže, ale nemusí být vybaven vn ějším zařízením 
GNSS, jak popisuje obrázek 1:  
Obrázek 1  
Různé konfigurace p řijímače GNSS
  
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 Satel ­
lite System ) 
GSA GPS DOP a aktivní družice ( GPS DOP and active satellites ) 
HDOP parametr horizontální p řesnosti ( Horizontal Dilution of 
Precision ) 
ICD kontrolní dokument rozhraní ( Interface Control Document ) 
NMEA Národní asociace pro námo řní elektroniku ( National Marine 
Electronics Association ) ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 439  
PDOP parametr p řesnosti polohy ( Position Dilution of Precision ) 
RMC doporu čená minimální specifická data ( Recommended 
Minimum Specific ) 
SIS signál v kosmu ( Signal in Space ) 
VDOP parametr vertikální p řesnosti ( Vertical Dilution of Precision ) 
VU celek ve vozidle ( Vehicle Unit ) 
2. SPECIFIKACE P ŘIJÍMAČE GNSS  
Bez ohledu na konfiguraci inteligentního tachografu s vn ějším zařízením 
GNSS nebo bez n ěj je poskytování p řesných a spolehlivých informací 
o poloze základním prvkem ú činného fungování inteligentního tacho ­
grafu. Proto je p řiměřené požadovat jeho slu čitelnost se službami posky ­
tovanými v rámci program ů Galileo a EGNOS podle na řízení Evrop ­
ského parlamentu a Rady (EU) č. 1285/2013 (  1 ). Systém zavedený 
v rámci programu Galileo je nezávislým globálním družicovým navi ­
gačním systémem a systém zavedený v rámci programu EGNOS je 
regionálním družicovým naviga čním systémem zvyšujícím kvalitu 
signálu systému GPS ( Global Positioning System ). 
GNS_2 Výrobci zajistí, aby p řijímače GNSS v inteligentních tachogra ­
fech byly slu čitelné se službami ur čování polohy poskytova ­
nými systémy Galileo a EGNOS. Výrobci mohou rovn ěž navíc 
zvolit kompatibilitu s dalšími družicovými naviga čními 
systémy.  
GNS_3 P řijímač GNSS musí být schopen podporovat ov ěření pravosti 
v rámci otev řené služby systému Galileo, až bude systém 
Galileo takovou službu poskytovat a výrobci p řijímačů GNSS 
ji budou podporovat. Nicmén ě u inteligentních tachograf ů 
uvedených na trh d říve, než budou uvedené podmínky spln ěny, 
a nepodporujících ov ěření pravosti v rámci otev řené služby 
systému Galileo nebude vyžadována modernizace.  
3. VĚTY NMEA  
Tato část popisuje v ěty NMEA používané p ři provozu inteligentního 
tachografu. Tato část platí pro konfiguraci inteligentního tachografu 
s vnějším zařízením GNSS i bez n ěj. 
GNS_4 Údaje o poloze jsou založeny na v ětě NMEA s doporu čenými 
minimálními specifickými daty GNSS (RMC), 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 RMC má tento formát (podle standardu NMEA V4.1):  ▼B 
( 1 ) Nařízení Evropského parlamentu a Rady (EU) č. 1285/2013 ze dne 11. prosince 2013 
o zřízení evropských systém ů družicové navigace a jejich využití a o zrušení na řízení 
Rady (ES) č. 876/2002 a na řízení Evropského parlamentu a Rady (ES) č. 683/2008 (Ú ř. 
věst. L 347, 20.12.2013, s. 1).
 02016R0799 — CS — 26.02.2020 — 002.001 — 440  
Obrázek 2  
Struktura v ěty RMC
  
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.  
▼M1 
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 p ředstavuje minuty 
vyjádřené na tři desetinná místa. Rozlišení je tedy 1/1000 minuty nebo 
1/60000 stupn ě (protože jedna minuta je 1/60 stupn ě). 
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 a p řesnosti signálu 
může celek ve vozidle používat p říkaz GSA (GPS DOP 
a aktivní družice). 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 3  
Struktura v ěty GSA
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 441  
GNS_6 V ěta GSA se ukládá s číslem záznamu ‘02’ až ‘06’.  
▼B 
GNS_7 Maximální velikost v ět NMEA (nap ř. RMC, GSA nebo 
dalších), kterou lze použít pro ur čení velikosti v p říkazu čtení 
záznamu, je 85 bajt ů (viz tabulka 1).  
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 vozidlovým 
rozhraním.  
GNS_9 Vn ější zařízení GNSS obsahuje tyto sou části (viz obrázek 4):  
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.10, kde p řijímač GNSS funguje jako vysíla č a předává 
věty NMEA bezpe čnostnímu p řijímači-vysílači GNSS 
s frekvencí 1 Hz, pokud jde o p ředem definovanou sadu 
vět NMEA, která musí zahrnovat p řinejmenším v ěty RMC 
a GSA. Implementace datového rozhraní GNSS je volbou 
výrobce vn ějšího zařízení GNSS;  
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 dato ­
vého rozhraní GNSS s p řijímačem GNSS. Jednotka je 
vybavena pam ětí pro ukládání identifika čních údajů přijí­
mače GNSS a vn ějšího zařízení GNSS;  
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 
implementuje bezpe čnostní ochranná opat ření požadovaná 
v profilu ochrany inteligentního tachografu;  
d) anténu GNSS instalovanou na vozidle a p řipojenou k p řijí­
mači GNSS skrz systém krytí.  
GNS_10 Vn ější zařízení GNSS má p řinejmenším tato vn ější rozhraní:  
a) rozhraní pro anténu GNSS instalovanou na nákladním 
vozidle, je-li použita externí anténa;  
b) rozhraní s celkem ve vozidle.  
GNS_11 V celku ve vozidle je protistranou zabezpe čené komunikace 
s bezpečnostním p řijímačem-vysílačem GNSS bezpe čnostní 
přijímač-vysílač VU, který musí podporovat normu ISO/ 
IEC 7816-4:2013, pokud jde o p řipojení k vn ějšímu zařízení 
GNSS.  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 442  
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,  
— certifikát EUR, jehož doba platnosti p římo předchází dob ě 
platnosti certifikátu EUR používaného pro ov ěření certifi­
ká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  
GNS_14 Komunika ční protokol mezi vn ějším zařízením GNSS a celkem 
ve vozidle podporuje t ři 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.  
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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 443  
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.  
▼M1 
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), vyhrazeným 
souborem (DF) s identifikátorem aplikace stanovený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 certifikáty a jedním 
samostatným elementárním souborem (EF.EGF) s identifiká ­
torem souboru rovným ‘2F2F’, jak popisuje tabulka 1.  
▼B 
GNS_19 Bezpe čnostní přijímač-vysílač GNSS ukládá údaje p řicházejí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 identifikátorem 
rovným ‘2F2F’ v hexadecimálním formátu.  
▼M1 
GNS_20 Bezpe čnostní přijímač-vysílač GNSS používá pro ukládání dat 
paměť a musí být schopen provést nejmén ě 20 milion ů cyklů 
zápisu/čtení. Krom ě této podmínky jsou vnit řní konstrukce 
a implementace bezpe čnostního p řijímače-vysílače GNSS pone ­
chány na uvážení výrobc ů. 
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.  
Tabulka 1  
Struktura soubor ů 
Podmínky p řístupu  
Soubor  ID souboru  Čtení Aktualizace  Šifrování  
MF 3F00  
EF.ICC  0002  ALW  NEV 
(by VU)  Ne 
DF GNSS Facility  0501  ALW  NEV  Ne  
EF EGF_MACertificate  C100  ALW  NEV  Ne  
EF CA_Certificate  C108  ALW  NEV  Ne  
EF Link_Certificate  C109  ALW  NEV  Ne  
EF.EGF  2F2F  SM-MAC  NEV 
(by VU)  Ne ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 444  
Soubor / datový prvek  Č. záznamu  Velikost (bajty)  Výchozí 
hodnoty  
Min Max  
MF 552  1 031  
EF.ICC  
sensorGNSSSerialNumber  8  8  
DF GNSS Facility  612  1 023  
EF EGF_MACertificate  204  341  
EGFCertificate  204  341  {00..00}  
EF CA_Certificate  204  341  
MemberStateCertificate  204  341  {00..00}  
EF Link_Certificate  204  341  
LinkCertificate  204  341  {00..00}  
EF.EGF  
Věta RMC NMEA  ‘01’  85  85  
1. věta GSA NMEA  ‘02’  85  85  
2. věta GSA NMEA  ‘03’  85  85  
3. věta GSA NMEA  ‘04’  85  85  
4. věta GSA NMEA  ‘05’  85  85  
5. věta GSA NMEA  ‘06’  85  85  
Rozšířené sériové číslo vnějšího 
zařízení GNSS definované v dodatku 
1 jako SensorGNSSSerialNumber  ‘07’ 8  8  
Identifikátor opera čního systému 
bezpečnostního p řijímače-vysílače 
GNSS definovaný v dodatku 1 jako 
SensorOSIdentifier  ‘08’ 2  2  
Číslo schválení typu vn ějšího zařízení 
GNSS definované v dodatku 1 jako 
SensorExternalGNSSApprovalNum ­
ber ‘09’ 16  16  
Identifikátor bezpe čnostní kompo ­
nenty vnějšího zařízení GNSS defino ­
vaný v dodatku 1 jako SensorExter ­
nalGNSSSCIdentifier  ‘10’ 8  8  
RFU – rezervováno pro budoucí použití  od ‘11’ do ‘FD’  
4.2.2  Zabezpe čený přenos údaj ů GNSS  
GNS_22 Zabezpe čený přenos údajů GNSS o poloze je povolen pouze za 
těchto podmínek:  
1. byl dokon čen proces vytvo ření vazby popsaný v dodatku 
11. Společné bezpečnostní mechanismy;  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 445  
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í.  
GNS_23 Každých T sekund, kde T je hodnota menší než nebo rovná 10, 
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 parametrem p řesnosti (z v ěty GSA 
NMEA). Bezpe čnostní přijímač-vysílač VU použije p říkaz 
SELECT a READ RECORD(S) podle ISO/IEC 7816- 
4:2013 v 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 ‘2F2F’ a číslem RECORD 
rovným ‘01’ pro v ětu RMC NMEA a ‘02’, ‘03’, ‘04’, 
‘05’, ‘06’ pro v ětu GSA NMEA.  
2. Poslední p řijaté údaje o poloze jsou uloženy v EF s identi ­
fikátorem ‘2F2F’ a záznamy, které popisuje tabulka 1, 
v bezpečnostním p řijímači-vysílači GNSS, s tím, jak 
bezpečnostní přijímač-vysílač GNSS p řijímá data NMEA 
z přijímače GNSS prost řednictvím datového rozhraní 
GNSS s frekvencí nejmén ě 1 Hz.  
3. Bezpečnostní přijímač-vysílač GNSS odešle bezpe čnostnímu 
přijímači-vysílači VU odpov ěď prostřednictvím zprávy 
s odpovědí APDU v režimu bezpe čného předávání zpráv 
pouze s ov ěřením pravosti podle popisu v dodatku 11 
části 11.5.  
4. Bezpečnostní přijímač-vysílač VU ověří pravost a integritu 
přijaté odpov ědi. V případě pozitivního výsledku jsou údaje 
o poloze p ředány procesoru VU prost řednictvím datového 
rozhraní GNSS.  
▼M1 
5. Procesor VU zkontroluje p řijaté údaje a extrahuje informace 
(např. zeměpisnou šířku, délku, čas) z věty RMC NMEA. 
Věta RMC NMEA obsahuje informaci, zda je poloha platná. 
Není-li poloha platná, nejsou údaje o poloze dosud k dispo ­
zici a nelze je použít pro zaznamenání polohy vozidla. Je-li 
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 dispo ­
zici). 
▼B 
6. Procesor VU uloží p řijaté a zpracované informace, nap ř. 
zeměpisnou šířku, délku, čas a rychlost, do celku ve vozidle 
ve formátu stanoveném v dodatku 1 – Datový slovník jako 
údaje GeoCoordinates, spole čně s hodnotou HDOP vypo čí­
tanou jako minimum z hodnot HDOP získaných z dostup ­
ných systém ů GNSS.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 446  
4.2.3  Struktura p říkazu Read Record  
Tato část podrobn ě popisuje strukturu p říkazu  Read Record . Je doplněno 
bezpečné předávání zpráv (režim pouze s ov ěřením pravosti) podle 
popisu v dodatku 11 – Spole čné bezpečnostní mechanismy.  
GNS_24 P říkaz podporuje režim bezpe čného předávání zpráv pouze 
s ověřením pravosti, viz dodatek 11.  
GNS_25 Zpráva s p říkazem  
Bajt Délka  Hodnota  Popis  
CLA  1  ‘0Ch’  Požadavek na bezpe čné předávání zpráv  
INS 1  ‘B2h’  Read Record  
P1 1  ‘XXh’  Číslo záznamu (‘00’ odkazuje na aktuální 
záznam)  
P2 1  ‘04h’  Čtení záznamu s číslem záznamu uvedeným 
v P1  
Le 1  ‘XXh’  Očekávaná délka dat. Po čet bajtů ke čtení. 
GNS_26 Záznam, na který odkazuje P1, se stává aktuálním záznamem.  
Bajt Délka  Hodnota  Popis  
#1-#X  X  ‘XX..XXh’  Přečtená data  
SW 2  ‘XXXXh’  Stavová slova (SW1, SW2)  
— Je-li p říkaz úspěšný, bezpe čnostní přijímač-vysílač GNSS 
vrátí ‘ 9000 ’. 
— Není-li aktuální soubor uspo řádán do záznam ů, bezpeč­
nostní přijímač-vysílač GNSS vrátí ‘ 6981 ’. 
— Je-li příkaz použit s parametrem P1 = ‘00’, ale žádný EF 
není aktuální, bezpe čnostní přijímač-vysílač GNSS vrátí 
‘6986 ’ (příkaz není povolen).  
— Není-li záznam nalezen, bezpe čnostní přijímač-vysílač 
GNSS vrátí ‘ 6A 83 ’. 
— Pokud vn ější zařízení GNSS zjistilo nedovolenou manipu ­
laci, vrátí stavová slova ‘ 66 90 ’. 
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  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 447  
4.3 Vazba, vzájemné ov ěření pravosti a dohoda na klí či relace mezi 
vnějším zařízením GNSS a celkem ve vozidle  
Vazba, vzájemné ov ěření pravosti a dohoda na klí či relace mezi vn ějším 
zařízením GNSS a celkem ve vozidle jsou popsány v dodatku 11 – 
Společné bezpečnostní mechanismy, kapitole 11.  
4.4 Zpracování chyb  
Tato část popisuje, jak jsou v celku ve vozidle zpracovávány a zazname ­
ná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  
▼M1 
GNS_28 Pokud celek ve vozidle není schopen komunikovat s vn ějším 
zařízením GNSS s vytvo řenou vazbou nep řetržitě po dobu delší 
než 20 minut, VU generuje a zaznamená událost typu Event ­
FaultType s hodnotou enum ‘0E’H Communication error with 
the external GNSS facility (chyba komunikace s vn ějším 
zařízením GNSS) a s časovým razítkem s aktuálním časem. 
Událost se generuje, pouze pokud jsou spln ěny tyto dv ě 
podmínky: a) inteligentní tachograf není v kalibra čním režimu 
a b) vozidlo se pohybuje. V této souvislosti se chyba komuni ­
kace vyvolá, když bezpe čnostní přijímač-vysílač VU neobdrží 
zprávu s odpov ědí po zpráv ě s požadavkem, jak je popsáno 
v bodě 4.2. 
▼B 
4.4.2  Narušení fyzické integrity vn ějšího zařízení GNSS  
▼M1 
GNS_29 P ři narušení vn ějšího zařízení GNSS bezpe čnostní přijímač- 
vysílač GNSS vymaže veškerý obsah své pam ěti, včetně kryp­
tografického materiálu. Jak je popsáno v odstavcích GNS_25 
a GNS_26, VU detekuje nedovolenou manipulaci, je-li status 
odpovědi ‘6690’. Celek ve vozidle poté generuje událost typu 
EventFaultType enum ‘19’H Tamper detection of GNSS 
(detekce nedovolené manipulace s GNSS). P řípadně může 
vnější zařízení GNSS p řestat reagovat na externí požadavky.  
▼B 
4.4.3  Chybí informace o poloze z p řijímače GNSS  
▼M1 
GNS_30 Pokud bezpe čnostní přijímač-vysílač GNSS neobdrží data 
z přijímače GNSS nep řetržitě po dobu delší než 3 hodiny, 
bezpečnostní přijímač-vysílač GNSS generuje zprávu s odpo ­
vědí na příkaz READ RECORD s číslem RECORD rovným 
‘01’ a s datovým polem obsahujícím 12 bajt ů, které mají 
všechny hodnotu 0xFF. Po p řijetí zprávy s odpov ědí s touto 
hodnotou datového pole VU generuje a zaznamená událost 
typu EventFaultType enum ‘0D’H Absence of position infor ­
mation from GNSS receiver (chybí informace o poloze z p řijí­
mače GNSS) s časovým razítkem s aktuálním časem, avšak 
pouze v p řípadě, že jsou spln ěny tyto dv ě podmínky: a) inte ­
ligentní tachograf není v kalibra čním režimu a b) vozidlo se 
pohybuje.  
▼B 
4.4.4  Skončení platnosti certifikátu vn ějšího zařízení GNSS  
GNS_31  ►M1 Pokud celek ve vozidle zjistí, že certifikát EGF použí ­
vaný pro vzájemné ov ěření pravosti již není platný, VU gene ­
ruje a zaznamená událost záznamového za řízení typu Event ­
FaultType enum  ‘1B’H External GNSS facility certificate 
expired  (skončila platnost certifikátu vn ějšího zařízení GNSS) 
s časovým razítkem s aktuálním časem. VU nadále používá 
přijaté údaje GNSS o poloze. ◄ ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 448  
Obrázek 4  
Schéma vn ějšího zařízení GNSS
  
5. CELEK VE VOZIDLE BEZ VN ĚJŠÍHO ZA ŘÍZENÍ GNSS  
5.1 Konfigurace  
V této konfiguraci je p řijímač GNSS uvnit ř celku ve vozidle, jak popi ­
suje obrázek 1.  
GNS_32 P řijímač GNSS funguje jako vysíla č a předává věty NMEA 
procesoru VU, který funguje jako p řijímač, s frekvencí 1/10 Hz 
nebo vyšší, pokud jde o p ředem definovanou sadu v ět NMEA, 
která musí zahrnovat p řinejmenším v ěty RMC a GSA.  
GNS_33 K celku ve vozidle je p řipojena externí anténa GNSS instalo ­
vaná na vozidle nebo interní anténa GNSS.  
5.2 Zpracování chyb  
5.2.1  Chybí informace o poloze z p řijímače GNSS  
▼M1 
GNS_34 Pokud celek ve vozidle neobdrží data z p řijímače GNSS nep ře­
tržitě po dobu delší než 3 hodiny, VU generuje a zaznamená 
událost typu EventFaultType enum ‘0D’H Absence of position 
information from GNSS receiver (chybí informace o poloze 
z přijímače GNSS) s časovým razítkem s aktuálním časem, 
avšak pouze v p řípadě, že jsou spln ěny tyto dv ě podmínky: 
a) inteligentní tachograf není v kalibra čním režimu a b) vozidlo 
se pohybuje.  
6. NESOULAD ČASU GNSS  
Pokud celek ve vozidle zjistí rozdíl v ětší než 1 minuta mezi časem podle 
funkce pro m ěření času v celku ve vozidle a časem pocházejícím z p řijí­
mače GNSS, VU zaznamená událost typu EventFaultType enum  ‘0B’H 
Time conflict (GNSS versus VU internal clock)  (nesoulad času – GNSS 
vůči vnitřním hodinám VU). Po vyvolání události nesouladu času VU 
nekontroluje časový nesoulad po dobu následujících 12 hodin. Tato 
událost není vyvolána v p řípadech, kdy p řijímač GNSS během posled ­
ních 30 dn ů nezjistil žádný platný signál GNSS.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 449  
7. NESOULAD ÚDAJ Ů O POHYBU VOZIDLA  
GNS_35 VU generuje a zaznamená událost „Nesoulad údaj ů o pohybu 
vozidla“ (viz požadavek 84 v této p říloze) s časovým razítkem 
s aktuálním časem, pokud jsou informace o pohybu vozidla 
vypočtené ze sníma če pohybu v konfliktu s informacemi 
o pohybu vozidla vypo čtenými z vnit řního přijímače GNSS 
nebo vnějšího zařízení GNSS. Pro ú čely detekce t ěchto 
konfliktů se použije medián rozdíl ů rychlostí mezi t ěmito 
dvěma zdroji, jak je specifikováno níže:  
— každých maximáln ě 10 sekund se vypo čte absolutní 
hodnota rozdílu rychlosti vozidla odhadnuté z GNSS a rych ­
losti odhadnuté ze sníma če pohybu,  
— k výpo čtu mediánu se použijí všechny vypo čtené hodnoty 
v časovém okn ě zahrnujícím posledních p ět minut pohybu,  
— medián se vypo čte jako pr ůměr z 80 % hodnot, které 
zůstanou po eliminaci hodnot, jež jsou v absolutní hodnot ě 
nejvyšší.  
Událost „Nesoulad údaj ů o pohybu vozidla“ se vyvolá, pokud 
je medián po dobu p ěti nepřerušených minut pohybu vozidla 
vyšší než 10 km/h. Voliteln ě lze použít další nezávislé zdroje 
detekce pohybu vozidla, aby byla detekce neoprávn ěných 
manipulací s tachografem spolehliv ější. ( Poznámka:  použití 
mediánu za posledních 5 minut má za cíl omezit riziko 
plynoucí z odlehlých a p řechodných hodnot.) Tato událost se 
nevyvolá za t ěchto podmínek: a) b ěhem převozu lodí / p řevozu 
vlakem, b) pokud nejsou k dispozici údaje o poloze z p řijímače 
GNSS a c) v kalibra čním režimu.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 450  
Dodatek 13  
ROZHRANÍ ITS  
OBSAH  
1. ÚVOD  
2. OBLAST P ŮSOBNOSTI  
2.1 Zkratky, definice a notace  
3. NA ŘÍZENÍ A NORMY, NA KTERÉ SE ODKAZUJE  
4. PRINCIPY ČINNOSTI ROZHRANÍ  
4.1 Předpoklady p řenosu dat prost řednictvím rozhraní ITS  
4.1.1 Údaje poskytované prost řednictvím rozhraní ITS  
4.1.2 Obsah údaj ů 
4.1.3 Aplikace ITS  
4.2 Komunika ční technologie  
4.3 Autorizace pomocí kódu PIN  
4.4 Formát zpráv  
4.5 Souhlas řidiče 
4.6 Čtení standardních údaj ů 
4.7 Čtení osobních údaj ů 
4.8 Čtení údajů událostí a závad  
1. ÚVOD  
Tento dodatek stanoví koncepci a postupy pro implementaci rozhraní 
s inteligentními dopravními systémy (ITS) podle článku 10 na řízení 
(EU) č. 165/2014 (dále jen  nařízení ). 
Nařízení  stanoví, že tachografy vozidel mohou být vybaveny standardizo ­
vaným rozhraním umož ňujícím, aby údaje zaznamenané či vytvořené 
tachografem byly v provozním režimu používány vn ějším zařízením, 
jsou-li spln ěny tyto podmínky:  
a) rozhraní nemá vliv na pravost a integritu údaj ů tachografu;  
b) rozhraní vyhovuje podrobným ustanovením uvedeným v článku 11;  
c) vnější zařízení připojené k rozhraní má p řístup k osobním údaj ům, 
včetně údajů o zeměpisné poloze, pouze po prokazatelném souhlasu 
řidiče, k němuž se tyto údaje vztahují.  
2. OBLAST P ŮSOBNOSTI  
Tento dodatek stanoví, jak aplikace ve vn ějších zařízeních mohou 
prostřednictvím p řipojení Bluetooth® získávat data (dále též  údaje ) 
z tachografu.  
Údaje  dostupné prost řednictvím tohoto rozhraní jsou popsány v p říloze 1 
tohoto dokumentu. Toto rozhraní nebrání implementaci dalších rozhraní 
(např. prostřednictvím sb ěrnice CAN) pro p řenos dat z celku ve vozidle do 
jiných procesorových jednotek vozidla.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 451  
Tento dodatek specifikuje:  
— údaje  dostupné prost řednictvím rozhraní ITS,  
— profil Bluetooth® používaný pro p řenos dat,  
— postupy dotazování a stahování a posloupnost operací,  
— mechanismus párování mezi tachografem a vn ějším zařízením,  
— mechanismus poskytnutí souhlasu, který je k dispozici řidiči. 
▼M1 
Pro upřesnění tento dodatek nespecifikuje:  
— činnost a správu, pokud jde o shromaž ďování  údajů v celku ve vozidle 
(které jsou specifikovány jinde v  nařízení  nebo jsou jinak funkcí 
konstrukce výrobku),  
— formu prezentace shromážd ěných údajů aplikaci ve vn ějším zařízení,  
— ustanovení o zabezpe čení dat nad rámec toho, co poskytuje Blue ­
tooth® (nap ř. šifrování), pokud jde o obsah  údajů (což je specifiko ­
váno jinde v  nařízení  [Dodatek 11 Spole čné bezpečnostní mechanis ­
my]),  
— protokoly Bluetooth® používané rozhraním ITS.  
▼B 
2.1 Zkratky, definice a notace  
Pro účely tohoto dodatku se použijí tyto zkratky a definice:  
komunikace  výměna informací/dat mezi nad řízenou („master“) jedno ­
tkou (tj. tachografy) a vn ější jednotkou prost řednictvím 
rozhraní ITS p řes připojení Bluetooth®  
údaje  sady dat specifikované v p říloze 1  
nařízení  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á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 ěkte­
rých předpisů v sociální oblasti týkajících se silni ční 
dopravy  
BR základní rychlost p řenosu dat ( Basic Rate ) 
EDR  zvýšená rychlost p řenosu dat ( Enhanced Data Rata ) 
GNSS  globální družicový naviga ční systém ( Global Navigation 
Satellite System ) 
IRK  klí č k rozlišení totožnosti ( Identity Resolution Key ) 
ITS inteligentní dopravní systém ( Intelligent Transport System ) 
LE nízká spot řeba energie ( Low Energy ) 
PIN kód PIN ( Personal Identification Number ) 
PUC  osobní odblokovací kód ( Personal Unblocking Code ) 
SID identifikátor služby ( Service Identifier ) 
SPP profil sériového portu ( Serial Port Profile ) ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 452  
SSP bezpe čné jednoduché párování ( Secure Simple Pairing ) 
TRTP  parametr požadavku na p řenos ( Transfer Request Parame ­
ter) 
TREP  parametr odpov ědi na požadavek na p řenos ( Transfer 
Response Parameter ) 
VU celek ve vozidle ( Vehicle Unit ) 
3. NAŘÍZENÍ A NORMY, NA KTERÉ SE ODKAZUJE  
Specifikace definované v tomto dodatku se odvolávají na níže uvedená 
nařízení a normy nebo jejich části a závisí na nich. P říslušné normy nebo 
jejich ustanovení jsou specifikovány v ustanoveních tohoto dodatku. 
V případě rozporu mají p řednost ustanovení tohoto dodatku.  
Nařízení a normy, na které se odkazuje v tomto dodatku, jsou:  
— 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áznamovém za řízení v silni ční dopravě a o 
změně nařízení Evropského parlamentu a Rady (ES) č. 561/2006 
o harmonizaci n ěkterých předpisů v sociální oblasti týkajících se 
silniční dopravy,  
— nařízení Evropského parlamentu a Rady (ES) č. 561/2006 ze dne 
15. března 2006 o harmonizaci n ěkterých předpisů v sociální oblasti 
týkajících se silni ční dopravy, o zm ěně nařízení Rady (EHS) č. 3821/85 
a (ES) č. 2135/98 a o zrušení na řízení Rady (EHS) č. 3820/85,  
— ISO 16844-4:  Road vehicles – Tachograph systems – Part 4: Can 
interface , 
— ISO 16844-7:  Road vehicles – Tachograph systems – Part 7: Para ­
meters , 
— Bluetooth® –  Serial Port Profile – V1.2 , 
— Bluetooth® –  Core Version 4.2 , 
— protokol NMEA 0183 V4.1.  
4. PRINCIPY ČINNOSTI ROZHRANÍ  
4.1 Předpoklady p řenosu dat prost řednictvím rozhraní ITS  
Celek ve vozidle je odpov ědný za aktualizaci a uchovávání údaj ů, které 
mají být uloženy ve VU, bez jakékoli ú časti rozhraní ITS. Zp ůsob, jakým 
je tohoto cíle dosaženo, je vnit řní funkcí VU specifikovanou jinde v na ří­
zení, a není specifikován v tomto dodatku.  
4.1.1  Údaje poskytované prost řednictvím rozhraní ITS  
Celek ve vozidle je odpov ědný za aktualizaci údaj ů, které budou k dispo ­
zici prostřednictvím rozhraní ITS, s četností určenou v rámci postup ů VU 
bez jakékoli ú časti rozhraní ITS. Z údaj ů VU se vychází p ři naplnění 
a aktualizaci  údajů a způsob, jakým je tohoto cíle dosaženo, je specifi ­
kován jinde v  nařízení , nebo pokud taková specifikace neexistuje, je 
funkcí konstrukce výrobku a není specifikován v tomto dodatku.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 453  
4.1.2  Obsah údaj ů 
Obsah  údajů je specifikován v p říloze 1 tohoto dodatku.  
4.1.3  Aplikace ITS  
Aplikace ITS používají údaje zp řístupněné prostřednictvím rozhraní ITS 
např. pro optimalizaci správy činností řidiče při současném dodržení na ří­
zení, pro zjiš ťování možných závad tachografu nebo pro využití údaj ů 
GNSS. Specifikace aplikací nespadá do oblasti p ůsobnosti tohoto dodatku.  
4.2 Komunika ční technologie  
Výměna údajů prostřednictvím rozhraní ITS je realizována pomocí 
rozhraní Bluetooth® kompatibilního s verzí 4.2 nebo nov ější. Bluetooth® 
pracuje v bezlicen čním průmyslovém, v ědeckém a zdravotnickém pásmu 
(ISM) na frekvenci 2,4 až 2,485 GHz. Bluetooth® 4.2 nabízí vylepšené 
mechanismy zajišt ění soukromí a bezpe čnosti a zvyšuje rychlost a spoleh ­
livost přenosu dat. Pro ú čely této specifikace se používá rádiové spojení 
Bluetooth® t řídy 2 s dosahem až 10 metr ů. Více informací o technologii 
Bluetooth® 4.2 je k dispozici na adrese www.bluetooth.com (https:// 
www.bluetooth.org/en-us/specification/adopted-specificati ­
ons?_ga=1.215147412.2083380574. 
1435305676).  
Komunikace  se s komunika čním zařízením naváže poté, co autorizované 
zařízení dokon čí proces párování. Protože Bluetooth® používá k řízení 
toho, kdy a kam mohou za řízení odesílat data, model „master/slave“, 
bude nadřízenou („master“) jednotkou tachograf a pod řízenou („slave“) 
jednotkou vn ější zařízení.  
▼M1 
Dostane-li se vn ější zařízení poprvé do dosahu VU, lze iniciovat proces 
párování Bluetooth® (viz rovn ěž přílohu 2). Za řízení sdílejí své adresy, 
názvy, profily a spole čný tajný klí č, což jim umožní navázat spojení, 
kdykoli se v budoucnu k sob ě přiblíží. Po dokon čení tohoto kroku je 
vnější zařízení považováno za d ůvěryhodné a m ůže iniciovat požadavky 
na stažení dat z tachografu. Nepo čítá se s přidáním šifrovacích mecha ­
nismů nad rámec toho, co poskytuje Bluetooth®. Jsou-li však nezbytné 
dodatečné bezpečnostní mechanismy, lze tak u činit v souladu s dodatkem 
11 Společné bezpečnostní mechanismy.  
▼B 
Obecný princip komunikace je popsán na následujícím obrázku.
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 454  
Pro přenos dat z celku ve vozidle do vn ějšího zařízení se používá profil 
SPP ( Serial Port Profile ). 
4.3 Autorizace pomocí kódu PIN  
▼M1 
Z bezpečnostních d ůvodů VU vyžaduje systém ov ěření pomocí kódu PIN 
odděleně od párování Bluetooth. Pro ú čely ověření pravosti je každý VU 
schopen generovat kódy PIN tvo řené nejmén ě 4 číslicemi. Vn ější zařízení 
musí při každém párování s VU poskytnout správný kód PIN, než bude 
moci přijímat data.  
▼B 
Po úspěšném zadání kódu PIN se za řízení zařadí na seznam povolených 
zařízení. Seznam povolených za řízení pojme nejmén ě 64 zařízení spáro ­
vaných s daným celkem ve vozidle.  
Je-li třikrát za sebou poskytnut špatný kód PIN, je za řízení dočasně 
zařazeno na seznam zakázaných za řízení. Dokud je za řízení na seznamu 
zakázaných za řízení, každý další pokus z tohoto za řízení se odmítne. Je-li 
znovu třikrát za sebou poskytnut špatný kód PIN, prodlužuje se postupn ě 
doba zákazu (viz tabulku 1). Poskytnutím správného kódu PIN se obnoví 
výchozí doba zákazu a po čet pokusů. Na obrázku 1 v p říloze 2 je uvedeno 
schéma logické posloupnosti pokusu o ov ěření kódu PIN.  
Tabulka 1  
Doba zákazu v závislosti na po čtu neúspěšných poskytnutí správného 
kódu PIN za sebou  
Počet po sobě jdoucích neúsp ěchů Doba zákazu  
3 30 sekund  
6 5 minut  
9 1 hodina  
12 24 hodin  
15 trvale  
Není-li správný kód PIN poskytnut patnáctkrát (5 × 3) za sebou, je 
jednotka ITS trvale za řazena na seznam zakázaných za řízení. Tento trvalý 
zákaz je možné zrušit pouze zadáním správného kódu PUC.  
Kód PUC je složen z 8 číslic a poskytuje jej výrobce spole čně s celkem 
ve vozidle. Je-li desetkrát za sebou zadán špatný kód PUC, je jednotka 
ITS zařazena na seznam zakázaných za řízení nezrušiteln ě. 
▼M1 
Výrobce m ůže nabízet možnost zm ěny kódu PIN p římo prostřednictvím 
celku ve vozidle, avšak kód PUC nelze m ěnit. Změna kódu PIN, pokud je 
možná, vyžaduje zadání aktuálního kódu PIN p římo do VU.  
▼B 
Zařízení jsou na seznamu povolených za řízení uchovávána, dokud je 
uživatel ru čně neodstraní (nap ř. přes rozhraní člověk-stroj VU nebo jinými 
prostředky). Ze seznamu povolených za řízení tak lze odstra ňovat ztracené 
nebo odcizené jednotky ITS. Ze seznamu povolených za řízení ve VU se 
rovněž automaticky odstraní jednotky ITS, které jsou mimo dosah spojení 
Bluetooth po dobu delší než 24 hodin. P ři opětovném navázání komuni ­
kace musí tyto jednotky znovu poskytnout správný kód PIN.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 455  
Formát zpráv mezi rozhraním VU a samotným VU není stanoven, ale 
ponechán na rozhodnutí výrobce. Doty čný výrobce však musí zajistit 
dodržování formátu zpráv mezi jednotkou ITS a rozhraním VU (viz speci ­
fikace v notaci ASN.1).  
Všechny požadavky na údaje jsou proto p řed jakýmkoli dalším zpraco ­
váním podrobeny řádné kontrole pov ěření odesílatele. Na obrázku 2 
přílohy 2 je uvedeno schéma logické posloupnosti tohoto postupu. Jaké ­
koli zařízení uvedené na seznamu zakázaných za řízení je automaticky 
odmítnuto, za řízení neuvedené na žádném seznamu obdrží žádost o PIN, 
kterou musí splnit p řed novým odesláním požadavku na údaje.  
4.4 Formát zpráv  
Všechny zprávy vym ěňované mezi jednotkou ITS a rozhraním VU mají 
formát struktury sestávající ze t ří částí: Hlavi čka se skládá z bajtu cíle 
(TGT), bajtu zdroje (SRC) a bajtu délky (LEN).  
Datové pole se skládá z bajtu identifikátoru služby (SID) a prom ěnného 
počtu datových bajt ů (maximáln ě 255).  
Bajt kontrolního sou čtu je jednobajtový sou čet modulo 256 všech bajt ů 
zprávy krom ě samotného CS.  
Zpráva je ve tvaru Big Endian.  
Tabulka 2  
Obecný formát zpráv  
Hlavička Datové pole  Kontrolní 
součet 
TGT  SRC  LEN  SID  TRTP  CC  CM  DATA  CS  
3 bajty  Max. 255 bajt ů 1 bajt  
Hlavička 
TGT a SRC: ID za řízení, které je cílem (TGT) a zdrojem (SRC) zprávy. 
Rozhraní VU má standardní ID „EE“. Toto ID nelze zm ěnit. Jednotka ITS 
používá standardní ID „A0“ pro svou první zprávu v rámci komunika ční 
relace. Rozhraní VU potom jednotce ITS p řiřadí jedinečné ID a informuje 
ji o tomto ID pro budoucí zprávy v rámci relace.  
Bajt LEN zohled ňuje pouze část „DATA“ datového pole (viz tabulku 2), 
první 4 bajty jsou implicitní.  
Rozhraní VU ov ěří pravost odesílatele zprávy k řížovou kontrolou vlast ­
ního seznamu IDList s daty Bluetooth, p ři níž zkontroluje, zda je jednotka 
ITS, která je v seznamu s poskytnutým ID, aktuáln ě v dosahu p řipojení 
Bluetooth.  
Datové pole  
Kromě SID datové pole rovn ěž obsahuje další parametry: parametr poža ­
davku na p řenos (TRTP) a bajty čítačů. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 456  
Jsou-li data, která je t řeba zpracovat, delší než dostupný prostor v jedné 
zprávě, rozdělí se do n ěkolika dílčích zpráv. Každá díl čí zpráva má 
stejnou hlavi čku a SID, ale obsahuje dvoubajtový čítač, Counter Current  
(CC) a  Counter Max  (CM), který uvádí číslo dílčí zprávy. Aby byla 
možná kontrola chyb a p řerušení přenosu, přijímající za řízení potvrzuje 
každou díl čí zprávu. P řijímající za řízení může přijmout díl čí zprávu, 
požádat o to, aby byla znovu p řenesena, nebo požádat vysílající za řízení 
o opětovný start nebo o p řerušení přenosu.  
▼B 
Pokud se CC a CM nepoužívají, mají hodnotu 0xFF.  
Například následující zpráva:  
HLAVIČKA SID  TRTP  CC  CM  DATA  CS  
3 bajty  Delší než 255 bajt ů 1 bajt  
se přenese jako:  
HLAVIČKA SID  TRTP  01  n  DATA  CS  
3 bajty  255 bajty  1 bajt  
HLAVIČKA SID  TRTP  02  n  DATA  CS  
3 bajty  255 bajty  1 bajt  
… 
HLAVIČKA SID  TRTP  N  N  DATA  CS  
3 bajty  Max. 255 bajt ů 1 bajt  
Tabulka 3 obsahuje zprávy, které si mohou VU a jednotka ITS vym ěňo­
vat. Obsah jednotlivých parametr ů je uveden v hexadecimálním formátu. 
V tabulce nejsou z d ůvodu přehlednosti uvedeny CC a CM, viz kompletní 
formát výše.  
Tabulka 3  
Podrobný obsah zpráv  
Zpráva  Hlavička DATA  Kontrolní 
součet 
TGT  SRC  LEN  SID  TRTP  DATA  
RequestPIN  ITSID  EE  00  01  FF  
SendITSID  ITSID  EE  01  02  FF  ITSID  
SendPIN  EE  ITSID  04  03  FF  4*INTEGER (0..9)  
PairingResult  ITSID  EE  01  04  FF  BOOLEAN (T/F)  
SendPUC  EE  ITSID  08  05  FF  8*INTEGER (0..9)  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 457  
Zpráva  Hlavička DATA  Kontrolní 
součet 
TGT  SRC  LEN  SID  TRTP  DATA  
BanLiftingResult  ITSID  EE  01  06  FF  BOOLEAN (T/F)  
RequestRejected  ITSID  EE  08  07  FF  Time  
RequestData  
standardTachData  EE  ITSID  01  08  01  
personalTachData  EE  ITSID  01  08  02  
gnssData  EE  ITSID  01  08  03  
standardEventData  EE  ITSID  01  08  04  
personalEventData  EE  ITSID  01  08  05  
standardFaultData  EE  ITSID  01  08  06  
manufacturerData  EE  ITSID  01  08  07  
ResquestAccepted  ITSID  EE  Len  09  TREP  Data  
DataUnavailable  
No data available  ITSID  EE  02  0A  TREP  10  
Personal data not 
shared  ITSID  EE  02  0A  TREP  11  
NegativeAnswer  
General reject  ITSID  EE  02  0B  SID Req  10  
Service not 
supported  ITSID  EE  02  0B  SID Req  11  
Sub function not 
supported  ITSID  EE  02  0B  SID Req  12  
Incorrect message 
length  ITSID  EE  02  0B  SID Req  13  
Conditions not 
correct or request 
sequence error  ITSID  EE  02  0B  SID Req  22  
Request out of 
range  ITSID  EE  02  0B  SID Req  31  
Response pending  ITSID  EE  02  0B  SID Req  78  
ITSID Mismatch  ITSID  EE  02  0B  SID Req  FC  
ITSID Not Found  ITSID  EE  02  0B  SID Req  FB  
RequestPIN (SID 01)  
Tuto zprávu vyšle rozhraní VU, pokud jednotka ITS, která není za řazena 
do seznamu zakázaných za řízení ani do seznamu povolených za řízení, 
odesílá jakýkoli požadavek na údaje.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 458  
SendITSID (SID 02)  
Tuto zprávu vyšle rozhraní VU, kdykoli nové za řízení odesílá požadavek. 
Toto zařízení použije výchozí ID „A0“, než je mu p řiděleno jedine čné ID 
pro komunika ční relaci.  
SendPIN (SID 03)  
Tuto zprávu vyšle jednotka ITS, aby byla rozhraním VU za řazena do 
seznamu povolených za řízení. Obsahem této zprávy je kód 4 hodnot 
INTEGER od 0 do 9.  
PairingResult (SID 04)  
Tuto zprávu vyšle rozhraní VU, aby informovalo jednotku ITS, zda odes ­
lala správný kód PIN. Obsahem této zprávy je hodnota BOOLEAN 
„True“, pokud byl kód PIN správný, nebo „False“ v opa čném případě. 
SendPUC (SID 05)  
Tuto zprávu vyšle jednotka ITS, aby rozhraní VU zrušilo sankci za řazení 
do seznamu zakázaných za řízení. Obsahem této zprávy je kód 8 hodnot 
INTEGER od 0 do 9.  
BanLiftingResult (SID 06)  
Tuto zprávu vyšle rozhraní VU, aby informovalo jednotku ITS, zda odes ­
lala správný kód PUC. Obsahem této zprávy je hodnota BOOLEAN 
„True“, pokud byl kód PUC správný, nebo „False“ v opa čném případě. 
RequestRejected (SID 07)  
Tuto zprávu vyšle rozhraní VU jako odpov ěď na jakoukoli zprávu od 
jednotky ITS za řazené do seznamu zakázaných za řízení krom ě 
„SendPUC“. Zpráva obsahuje zbývající čas, po který je jednotka ITS 
zařazena do seznamu zakázaných za řízení, ve formátu sekvence „Time“ 
podle přílohy 3.  
RequestData  (SID 08)  
Tuto zprávu pro zp řístupnění údajů vyšle jednotka ITS. Jednobajtový 
parametr TRTP ozna čuje typ požadovaných údaj ů. Existuje n ěkolik typů 
údajů: 
— standardTachData (TRTP 01): údaje dostupné z tachografu a klasifiko ­
vané jako neosobní,  
— personalTachData (TRTP 02): údaje dostupné z tachografu a klasifiko ­
vané jako osobní,  
— gnssData (TRTP 03): údaje GNSS, vždy osobní,  
— standardEventData (TRTP 04): údaje zaznamenaných událostí klasifi ­
kované jako neosobní,  
— personalEventData (TRTP 05): údaje zaznamenaných událostí klasifi ­
kované jako osobní,  
— standardFaultData (TRTP 06): zaznamenané závady klasifikované jako 
neosobní,  
— manufacturerData (TRTP 07): údaje zp řístupněné výrobcem.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 459  
Více informací o obsahu jednotlivých typ ů údajů viz přílohu 3 tohoto 
dodatku.  
Více informací o formátu a obsahu údaj ů GNSS viz dodatek 12.  
Více informací o kódu údaj ů událostí a závadách viz p řílohy IB a IC.  
RequestAccepted  (SID 09)  
Tuto zprávu vyšle rozhraní VU, pokud zpráva „RequestData“ od jednotky 
ITS byla akceptována. Tato zpráva obsahuje jednobajtový parametr TREP, 
což je bajt TRTP p říslušné zprávy RequestData, a všechny údaje požado ­
vaného typu.  
DataUnavailable  (SID 0A)  
Tuto zprávu vyšle rozhraní VU, pokud z n ějakého důvodu nelze odeslat 
požadovaná data jednotce ITS za řazené do seznamu povolených za řízení. 
Zpráva obsahuje jednobajtový parametr TREP, což je TRTP požadova ­
ných údajů, a jednobajtový kód chyby podle tabulky 3. K dispozici jsou 
tyto kódy:  
— No data available  (data nejsou k dispozici) (10): Rozhraní VU nem ůže 
z neurčených důvodů přistupovat k údaj ům VU.  
— Personal data not shared  (osobní údaje nesdíleny) (11): Jednotka ITS 
se pokouší získat osobní údaje, které nejsou sdíleny.  
NegativeAnswer  (SID 0B)  
Tyto zprávy vysílá rozhraní VU, pokud požadavku nelze vyhov ět z jiného 
důvodu, než je nedostupnost údaj ů. Tyto zprávy jsou zpravidla výsledkem 
špatného formátu požadavku (délka, SID, ITSID…), ale mohou mít i jiné 
příčiny. TRTP v datovém poli obsahuje SID požadavku. Datové pole 
obsahuje kód ozna čující důvod negativní odpov ědi. K dispozici jsou násle ­
dující kódy:  
— General Reject  (obecné odmítnutí, kód: 10)  
— Akci nelze provést z d ůvodu, který není uveden níže ani v části 
(doplnit číslo části DataUnavailable ). 
— Service not supported  (služba nepodporována, kód: 11)  
— Nesrozumitelné SID požadavku.  
— Sub function not supported  (podfunkce nepodporována, kód: 12)  
— Nesrozumitelný parametr TRTP požadavku. Nap říklad může hodnota 
chybět nebo být mimo rozsah p řípustných hodnot.  
— Incorrect message length  (chybná délka zprávy, kód: 13)  
— Délka p řijaté zprávy je chybná (neshoda mezi bajtem LEN a skute čnou 
délkou zprávy).  
— Conditions not correct or request sequence error  (chybné podmínky 
nebo chybná sekvence požadavk ů, kód: 22)  
— Požadovaná služba není aktivní nebo je chybná posloupnost zpráv 
s požadavky.  
— Request out of range  (požadavek mimo rozsah, kód: 33)  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 460  
— Záznam s parametry požadavku (datové pole) je neplatný.  
— Response pending  (odpověď se připravuje, kód: 78)  
— Požadovanou akci nelze dokon čit včas a VU není p řipraven přijmout 
další požadavek.  
— ITSID Mismatch  (neshoda  ITSID , kód: FB)  
— SRC  ITSID  neodpovídá p říslušnému za řízení po porovnání s informa ­
cemi Bluetooth.  
— ITSID Not Found  (ITSID  nenalezen, kód: FC)  
— SRC  ITSID  není přidružen k žádnému za řízení.  
Formát zpráv popsaných v tabulce 3 specifikují řádky 1 až 72 ( Format­
MessageModule ) kódu ASN.1 v p říloze 3. Více podrobností o obsahu 
zpráv je uvedeno níže.  
4.5 Souhlas řidiče 
Všechny dostupné údaje jsou klasifikovány jako standardní, nebo osobní. 
Osobní údaje jsou p řístupné pouze v p řípadě, že řidič poskytne souhlas 
s tím, že jeho osobní údaje z tachografu mohou opustit sí ť vozidla a být 
předány aplikacím t řetích stran.  
Souhlas řidiče se poskytuje, když je p ři prvním vložení p říslušné karty 
řidiče nebo karty dílny, kterou celek ve vozidle aktuáln ě nezná, držitel 
karty vyzván, aby vyjád řil souhlas s p ředáváním osobních údaj ů souvise­
jících s tachografem prost řednictvím volitelného rozhraní ITS (viz rovn ěž 
přílohu 1C odstavec 3.6.2).  
Stav souhlasu (povoleno/zamítnuto) je zaznamenán v pam ěti tachografu.  
V případě více řidičů jsou s rozhraním ITS sdíleny pouze osobní údaje 
o řidičích, kteří poskytli souhlas. Jsou-li nap říklad ve vozidle dva řidiči 
a pouze první z nich souhlasil se sdílením svých osobních údaj ů, nesdílí se 
údaje, které se týkají druhého řidiče. 
4.6 Čtení standardních údaj ů 
Na obrázku 3 v p říloze 2 jsou uvedena schémata logické posloupnosti 
platného požadavku na p řístup ke standardním údaj ům odeslaného jedno ­
tkou ITS. Jednotka ITS je řádně uvedena na seznamu povolených za řízení 
a nepožaduje osobní údaje; žádné další ov ěřování není požadováno. Sché ­
mata vycházejí z p ředpokladu, že již byl proveden řádný postup uvedený 
na obrázku 2 p řílohy 2. Mohou být považovány za šedé pole  REQUEST 
TREATMENT  na obrázku 2.  
Z dostupných údaj ů se za standardní považují tyto:  
— standardTachData (TRTP 01),  
— StandardEventData (TRTP 04),  
— standardFaultData (TRTP 06).  
4.7 Čtení osobních údaj ů 
Na obrázku 4 v p říloze 2 jsou uvedena schémata logické posloupnosti 
zpracování požadavku na osobní údaje. Jak bylo uvedeno výše, rozhraní 
VU odešle osobní údaje pouze v p řípadě, že řidič poskytl výslovný 
souhlas (viz rovn ěž bod 4.5). V opa čném případě musí být požadavek 
automaticky odmítnut.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 461  
Z dostupných údaj ů se za osobní považují tyto:  
— personalTachData (TRTP 02),  
— gnssData (TRTP 03),  
— personalEventData (TRTP 05),  
— manufacturerData (TRTP 07).  
4.8 Čtení údaj ů událostí a závad  
Jednotky ITS mohou požadovat údaje o událostech zahrnující seznam 
všech neo čekávaných událostí. Tyto údaje se považují za standardní 
nebo za osobní, viz p řílohu 3. Obsah jednotlivých událostí je v souladu 
s dokumentací uvedenou v p říloze 1 tohoto dodatku.  ▼B
02016R0799 — CS — 26.02.2020 — 002.001 — 462  
PŘÍLOHA 1  
▼M1 
1) SEZNAM ÚDAJ Ů DOSTUPNÝCH PROST ŘEDNICTVÍM ROZHRANÍ ITS  
▼C2 
Údaje  Zdroj Klasifikace 
údajů 
(osobní/neosobní)  
VehicleIdentificationNumber  celek ve vozidle  neosobní 
CalibrationDate  celek ve vozidle  neosobní 
TachographVehicleSpeed speed instant t celek ve vozidle  osobní 
Driver1WorkingState Selector driver  celek ve vozidle  osobní 
Driver2WorkingState  celek ve vozidle  osobní 
DriveRecognize Speed Threshold detected  celek ve vozidle  neosobní 
Driver1TimeRelatedStates Weekly day time  karta řidiče osobní 
Driver2TimeRelatedStates  karta řidiče osobní 
DriverCardDriver1 celek ve vozidle  neosobní 
DriverCardDriver2 celek ve vozidle  neosobní 
OverSpeed celek ve vozidle  osobní 
TimeDate  celek ve vozidle  neosobní 
HighResolutionTotalVehicleDistance  celek ve vozidle  neosobní 
ServiceComponentIdentification  celek ve vozidle  neosobní 
ServiceDelayCalendarTimeBased  celek ve vozidle  neosobní 
Driver1Identification  karta řidiče osobní 
Driver2Identification  karta řidiče osobní 
NextCalibrationDate  celek ve vozidle  neosobní 
Driver1ContinuousDrivingTime  karta řidiče osobní 
Driver2ContinuousDrivingTime  karta řidiče osobní 
Driver1CumulativeBreakTime  karta řidiče osobní 
Driver2CumulativeBreakTime  karta řidiče osobní 
Driver1CurrentDurationOfSelectedActivity  karta řidiče osobní 
Driver2CurrentDurationOfSelectedActivity  karta řidiče osobní 
SpeedAuthorised celek ve vozidle  neosobní 
TachographCardSlot1  karta řidiče neosobní 
TachographCardSlot2  karta řidiče neosobní 
Driver1Name  karta řidiče osobní 
Driver2Name karta řidiče osobní  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 463  
Údaje  Zdroj  Klasifikace 
údajů 
(osobní/neosobní)  
OutOfScopeCondition  celek ve vozidle  neosobní  
ModeOfOperation  celek ve vozidle  neosobní  
Driver1CumulatedDrivingTimePreviousAndCur ­
rentWeek  karta řidiče osobní  
Driver2CumulatedDrivingTimePreviousAndCur ­
rentWeek  karta řidiče osobní  
EngineSpeed  celek ve vozidle  osobní  
RegisteringMemberState  celek ve vozidle  neosobní  
VehicleRegistrationNumber  celek ve vozidle  neosobní  
Driver1EndOfLastDailyRestPeriod  karta řidiče osobní  
Driver2EndOfLastDailyRestPeriod  karta řidiče osobní  
Driver1EndOfLastWeeklyRestPeriod  karta řidiče osobní  
Driver2EndOfLastWeeklyRestPeriod  karta řidiče osobní  
Driver1EndOfSecondLastWeeklyRestPeriod  karta řidiče osobní  
Driver2EndOfSecondLastWeeklyRestPeriod  karta řidiče osobní  
Driver1CurrentDailyDrivingTime  karta řidiče osobní  
Driver2CurrentDailyDrivingTime  karta řidiče osobní  
Driver1CurrentWeeklyDrivingTime  karta řidiče osobní  
Driver2CurrentWeeklyDrivingTime  karta řidiče osobní  
Driver1TimeLeftUntilNewDailyRestPeriod  karta řidiče osobní  
Driver2TimeLeftUntilNewDailyRestPeriod  karta řidiče osobní  
Driver1CardExpiryDate  karta řidiče osobní  
Driver2CardExpiryDate  karta řidiče osobní  
Driver1CardNextMandatoryDownloadDate  karta řidiče osobní  
Driver2CardNextMandatoryDownloadDate  karta řidiče osobní  
TachographNextMandatoryDownloadDate  celek ve vozidle  neosobní  
Driver1TimeLeftUntilNewWeeklyRestPeriod  karta řidiče osobní  
Driver2TimeLeftUntilNewWeeklyRestPeriod  karta řidiče osobní  
Driver1NumberOfTimes9hDailyDrivingTimesEx ­
ceeded  karta řidiče osobní  
Driver2NumberOfTimes9hDailyDrivingTimesEx ­
ceeced  karta řidiče osobní  ▼C2
 02016R0799 — CS — 26.02.2020 — 002.001 — 464  
Údaje  Zdroj  Klasifikace 
údajů 
(osobní/neosobní)  
Driver1CumulativeUninterruptedRestTime  karta řidiče osobní  
Driver2CumulativeUninterruptedRestTime  karta řidiče osobní  
Driver1MinimumDailyRest  karta řidiče osobní  
Driver2MinimumDailyRest  karta řidiče osobní  
Driver1MinimumWeeklyRest  karta řidiče osobní  
Driver2MinimumWeeklyRest  karta řidiče osobní  
Driver1MaximumDailyPeriod  karta řidiče osobní  
Driver2MaximumDailyPeriod  karta řidiče osobní  
Driver1MaximumDailyDrivingTime  karta řidiče osobní  
Driver2MaximumDailyDrivingTime  karta řidiče osobní  
Driver1NumberOfUsedReducedDailyRestPeriods  karta řidiče osobní  
Driver2NumberOfUsedReducedDailyRestPeriods  karta řidiče osobní  
Driver1RemainingCurrentDrivingTime  karta řidiče osobní  
Driver2RemainingCurrentDrivingTime  karta řidiče osobní  
GNSS position  celek ve vozidle  osobní  
▼B 
2) PRŮBĚŽNÉ ÚDAJE GNSS DOSTUPNÉ PO SOUHLASU ŘIDIČE 
Viz dodatek 12 – GNSS.  
3) KÓDY UDÁLOSTÍ DOSTUPNÝCH BEZ SOUHLASU ŘIDIČE 
Událost  Pravidla ukládání  Údaje, které se ukládají pro každou událost  
Vložení neplatné karty  — 10 posledních událostí  — datum a čas události 
— typ, číslo, vydávající členský stát a generace 
karty (karet) vytvá řející(ch) událost 
— počet podobných událostí v tentýž den  
Konflikt karet  — 10 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 generace 
dvou karet vytvá řejících konflikt  
Nesprávné uzav ření poslední 
relace karty  — 10 posledních událostí  — datum a čas vložení karty 
— typ, číslo, vydávající členský stát a generace 
karty (karet) 
— poslední data relace p řečtená z karty: 
— datum a čas vložení karty 
— VRN, členský stát registrace a generace 
VU ▼C2
 02016R0799 — CS — 26.02.2020 — 002.001 — 465  
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 10 
posledních dn ů výskytu 
— 5 nejdelších událostí za posled ­
ních 365 dn ů — datum a čas začátku události 
— datum a čas konce události 
— typ, číslo, vydávající členský stát a generace 
všech karet vložených na za čátku a/nebo 
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 10 
posledních dn ů výskytu 
— 5 nejdelších událostí za posled ­
ních 365 dn ů — datum a čas začátku události 
— datum a čas konce události 
— typ, číslo, vydávající členský stát a generace 
všech karet vložených na za čátku a/nebo 
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 10 
posledních dn ů výskytu 
— 5 nejdelších událostí za posled ­
ních 365 dn ů — datum a čas začátku události 
— datum a čas konce události 
— typ, číslo, vydávající členský stát a generace 
všech karet vložených na za čátku a/nebo 
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 10 dn ů výskytu 
— 5 nejdelších událostí za posled ­
ních 365 dn ů — datum a čas začátku události, 
— datum a čas konce události 
— typ, číslo, vydávající členský stát a generace 
všech karet vložených na za čátku a/nebo na 
konci události 
— počet podobných událostí v tentýž den  
▼B 
Chyba údaj ů o pohybu 
vozidla  — nejdelší událost v každém z 10 
posledních dn ů výskytu 
— 5 nejdelších událostí za posled ­
ních 365 dn ů — datum a čas začátku události 
— datum a čas konce události 
— typ, číslo, vydávající členský stát a generace 
všech karet vložených na za čátku a/nebo 
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 10 
posledních dn ů výskytu 
— 5 nejdelších událostí za posled ­
ních 365 dn ů — datum a čas začátku události 
— datum a čas konce události 
— typ, číslo, vydávající členský stát a generace 
všech karet vložených na za čátku a/nebo 
konci události 
— počet podobných událostí v tentýž den  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 466  
Událost  Pravidla ukládání  Údaje, které se ukládají pro každou událost  
Pokus o narušení zabezpe ­ 
čení 10 posledních 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 generace 
všech karet vložených na za čátku a/nebo 
konci události 
— typ události  
Časový konflikt  — nejdelší událost v každém z 10 
posledních dn ů výskytu 
— 5 nejdelší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 generace 
všech karet vložených na za čátku a/nebo 
konci události 
— počet podobných událostí v tentýž den  
4) KÓDY UDÁLOSTÍ DOSTUPNÝCH SE SOUHLASEM ŘIDIČE 
Událost  Pravidla ukládání  Údaje, které se ukládají pro každou událost  
Řízení bez náležité karty  — nejdelší událost v každém z 10 
posledních dn ů výskytu 
— 5 nejdelších událostí za posled ­
ní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 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 10 
posledních 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  
Překročení povolené rych- 
losti (1)  — nejzávažn ější událost v každém 
z 10 posledních dn ů výskytu 
(tj. případ s nejvyšší pr ůměrnou 
rychlostí) 
— 5 nejzávažn ějších událostí za 
poslední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 řípadech) 
— počet podobných událostí v tentýž den  
5) KÓDY ÚDAJ Ů ZÁVAD DOSTUPNÝCH BEZ SOUHLASU ŘIDIČE 
Závada  Pravidla ukládání  Údaje, které se ukládají p ři závadě 
Závada karty  — 10 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)  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 467  
Závada  Pravidla ukládání  Údaje, které se ukládají p ři závadě 
Závady záznamového 
zařízení  — 10 posledních závad pro každý 
typ závady 
— první závada po poslední kali ­
braci  — 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  
Tato závada se aktivuje, pokud za řízení není v kalibra čním režimu a nastane 
jakákoli z následujících poruch:  
— interní závada celku ve vozidle,  
— závada tiskárny,  
— závada displeje,  
— 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,  
▼M1 
— závada rozhraní ITS (v p říslušných p řípadech).  
▼B 
6) UDÁLOSTI A ZÁVADY SPECIFICKÉ PRO VÝROBCE DOSTUPNÉ BEZ 
SOUHLASU ŘIDIČE 
Událost nebo závada  Pravidla ukládání  Údaje, které se ukládají pro každou událost  
Stanoví výrobce  Stanoví výrobce  Stanoví výrobce  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 468  
PŘÍLOHA 2  
SCHÉMATA LOGICKÉ POSLOUPNOSTI VÝM ĚN ZPRÁV S JEDNOTKOU ITS  
Obrázek 1  
Schéma logické posloupnosti pokusu o ov ěření kódu PIN
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 469  
Obrázek 2  
Schéma logické posloupnosti ov ěření autorizace jednotky ITS
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 470  
Obrázek 3  
Schéma logické posloupnosti zpracování požadavku na údaje klasifikované jako neosobní (po zadání správného 
kódu PIN)
  
Obrázek 4  
Schéma logické posloupnosti zpracování požadavku na údaje klasifikované jako osobní (po zadání správného 
kódu PIN)
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 471  
Obrázek 5  
Schéma logické posloupnosti pokusu o ov ěření PUC
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 472  
PŘÍLOHA 3  
SPECIFIKACE V NOTACI ASN.1
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 473
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 474
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 475
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 476
  
► (1) M1 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 477
  
► (1) (2) (3)  M1 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 478
  
► (1) M1 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 479
  
► (1) (2) M1 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 480
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 481
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 482
  
► (1) M1 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 483
  
▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 484  
Dodatek 14  
FUNKCE DÁLKOVÉ KOMUNIKACE  
OBSAH  
1 ÚVOD  
2 ROZSAH  
3 ZKRATKY, DEFINICE A ZNA ČENÍ 
4 OPERA ČNÍ SCÉNÁ ŘE 
4.1 P řehled  
4.1.1 Podmínky p řenosu dat pomocí rozhraní 5,8 GHz DSRC  
4.1.2 Profil 1a: pomocí čtečky komunika čního zařízení včasného dálkového 
odhalování nasm ěrovaného ru čně nebo do časně namontovaného 
a nasměrovaného u silnice  
4.1.3 Profil 1b: pomocí čtečky komunika čního zařízení včasného dálkového 
odhalování namontovaného a nasm ěrovaného na vozidle  
4.2 Zabezpe čení/integrita  
5 STRUKTURA A PROTOKOLY DÁLKOVÉ KOMUNIKACE  
5.1 Struktura  
5.2 Vývojový diagram  
5.2.1 Činnosti  
5.2.2 Interpretace dat p řijímaných prost řednictvím komunikace DSRC  
5.3 Parametry fyzického rozhraní DSRC pro dálkovou komunikaci  
5.3.1 Omezení umíst ění 
5.3.2 Parametry downlinku a uplinku  
5.3.3 Konstrukce antény  
5.4 Požadavky protokolu DSRC pro RTM  
5.4.1 P řehled  
5.4.2 P říkazy  
5.4.3 Po řadí dotazovacích p říkazů 
5.4.4 Struktury dat  
5.4.5 Prvky RTMData, provedené akce a definice  
5.4.6 Mechanismus p řenosu dat  
5.4.7 Podrobný popis transakce DSRC  
5.4.8 Popis transakce testu DSRC  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 485  
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  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 486  
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 tachogra ­
fem. 
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í aktu ­
alizace.  
DSC_9 Obsah bezpe čnostních dat je zp řístupněn pouze p říslušným 
kontrolním orgán ům a pod jejich kontrolou a stranám, se 
kterými sdílejí tyto informace, a je mimo rámec opat ření 
komunikace , která je p ředmětem tohoto dodatku, krom ě 
případů, kdy tato  komunikace  s každým balí čkem přenášených 
dat zajišťuje přenos balíčku bezpečnostních dat.  
DSC_10 Stejnou architekturu a za řízení podle tohoto dodatku musí být 
možné používat pro získávání dalších datových koncepcí 
(např. vážení na palub ě). 
DSC_11 Je t řeba zdůraznit, že v souladu s ustanoveními na řízení (EU) 
č. 165/2014 ( článek 7) nesm ějí být prost řednictvím  komuni­
kace sdělovány údaje týkající se totožnosti řidiče. 
2 ROZSAH  
Rozsah tohoto dodatku je omezen na stanovení podmínek, za jakých 
zástupci p říslušných kontrolních orgán ů používají specifikovanou 
bezdrátovou komunikaci 5,8 GHz DSRC pro získávání údaj ů (dat) na ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 487  
dálku ze zam ěřeného vozidla, která ukazují, že zam ěřené vozidlo poten ­
ciálně porušuje na řízení (EU) č. 165/2014 a m ěla by být zvážena 
možnost jeho zastavení pro další šet ření. 
Nařízení (EU) č. 165/2014 požaduje, aby se shromaž ďovaná data 
omezovala pouze na údaje nebo se týkala údaj ů, které identifikují poten ­
ciální přestupek, jak je uvedeno v článku 9 na řízení (EU) č. 165/2014.  
▼M1 
V tomto scéná ři je čas vyhrazený pro komunikaci omezený, protože  
komunikace  je cílená a má krátký dosah. Stejné komunika ční prostředky 
pro dálkové sledování tachograf ů (RTM) mohou navíc p říslušné 
kontrolní orgány používat pro další aplikace (nap ř. maximální hmotnosti 
a rozměry těžkých nákladních vozidel podle sm ěrnice (EU) 2015/719) 
a tyto operace mohou být podle rozhodnutí p říslušných kontrolních 
orgánů izolované nebo sekven ční. 
▼B 
Tento dodatek specifikuje:  
— Komunika ční zařízení, postupy a protokoly používané pro  komuni­
kaci 
— Normy a p ředpisy, které musí rádiové za řízení splňovat 
— Předkládání  dat komunika čnímu  zařízení  
— Dotazovací a stahovací postupy a posloupnost operací  
— Data  k přenosu  
— Potenciální výklad  dat přenášených p ři komunikaci  
— Poskytování bezpe čnostních dat v souvislosti s  komunikací  
— Dostupnost  dat příslušným kontrolním orgán ům 
— Jak může čtečka komunika čního zařízení včasného dálkového odha ­
lování  požadovat r ůzné druhy dat týkajících se nákladu a vozového 
parku  
Pro upřesnění, tento dodatek  nestanoví:  
— Postup a řízení sběru dat v celku ve vozidle (které jsou funkcí 
konstrukce výrobku, pokud nejsou stanoveny jinde v na řízení (EU) 
č. 165/2014)  
— Formu poskytování získaných dat zástupci p říslušného kontrolního 
orgánu ani kritéria, která p říslušné kontrolní orgány používají p ři 
rozhodování o tom, jaká vozidla mají zastavit (která jsou funkcí 
konstrukce výrobku, pokud nejsou stanovena jinde v na řízení (EU) 
č. 165/2014 nebo politickým rozhodnutím p říslušných kontrolních 
orgánů). Je třeba zdůraznit, že  komunikace  pouze poskytuje  data  
příslušným kontrolním orgán ům, aby  tyto orgány mohly provád ět 
informovaná rozhodnutí.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 488  
— Bezpečnostní podmínky dat (nap ř. šifrování) týkající se obsahu  dat 
(které jsou stanoveny v dodatku 11 – Spole čné bezpečnostní mecha ­
nismy.  
— Podrobnosti jiných koncepcí dat než RTM, která lze získávat pomocí 
stejné architektury a za řízení.  
— Podrobnosti chování a řízení mezi VU a DSRC-VU ani chování 
v rámci DSRC-VU (jiného než poskytování  dat v případě vyžádání 
ze strany REDCR).  
3 ZKRATKY, DEFINICE A ZNA ČENÍ 
V tomto dodatku se používají tyto specifické zkratky a definice:  
Anténa  Elektrické za řízení, které p řeměňuje 
elektrickou energii na rádiové vlny 
a opačně, používané ve spojení 
s rádiovým vysíla čem nebo rádi ­
ovým přijímačem. Při vysílání 
rádiový vysíla č předává na anténní 
svorky elektrický proud oscilující 
s určitou rádiovou frekvencí a anténa 
vyzařuje energii proudu ve form ě 
elektromagnetického vln ění (rádiové 
vlny). Při přijímání anténa zachycuje 
určitou energii elektromagnetické 
vlny a vytvá ří na svých svorkách 
mírné nap ětí, které je p ředáváno 
přijímači, kde se zesiluje.  
Komunikace  Vým ěna informací/dat mezi DSRC- 
REDCR a DSRC-VU podle části 5 
na základě vztahu hlavní jednotka – 
vedlejší jednotka za ú čelem získání 
dat. 
Data  Zabezpe čená data definovaného 
formátu (viz 5.4.4) požadovaná ze 
strany  DSRC-REDCR  a poskytovaná  
DSRC-REDCR  celkem ve vozidle  
DSRC-VU  prostřednictvím spojení 
5,8 GHz DSRC podle bodu 5 níže.  
Nařízení (EU) č. 165/2014  Na řízení Evropského parlamentu 
a Rady (EU) č. 165/2014 ze dne 
4. února 2014 o tachografech 
v silniční dopravě, o zrušení na ří­
zení Rady (EHS) č. 3821/85 o zázna ­
movém za řízení v silni ční dopravě ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 489  
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 — 26.02.2020 — 002.001 — 490  
VU celek ve vozidle  
VUPM  pam ěť přenášených dat celku ve 
vozidle  
VUSM  bezpe čnostní modul celku ve 
vozidle  
VST  servisní tabulka vozidla  
WIM  vážení za jízdy  
WOB  vážení na palub ě 
Specifikace definovaná v tomto dodatku odkazuje na všechny následující 
předpisy a normy nebo jejich části a je na nich závislá. V rámci usta ­
novení tohoto dodatku jsou specifikovány p říslušné normy nebo 
příslušná ustanovení norem. V p řípadě jakýchkoli rozpor ů mají přednost 
ustanovení tohoto dodatku. V p řípadě jakýchkoli rozpor ů, k nimž se 
tento dodatek jasn ě nevyjadřuje, má přednost postup podle ERC 70-03 
(s kontrolou p říslušných parametr ů EN 300 674-1), v sestupném po řadí 
důležitosti podle EN 12795, EN 12253 EN 12834 a EN 13372, 6.2, 6.3, 
6.4 a 7.1.  
Předpisy a normy, na které odkazuje tento dodatek, jsou:  
[1] Nařízení (EU) č. 165/2014 ze dne 4. února 2014 o tachografech 
v silniční dopravě, o zrušení na řízení Rady (EHS) č. 3821/85 
o záznamovém za řízení v silni ční dopravě a o změně nařízení 
Evropského parlamentu a Rady (ES) č. 561/2006 o harmonizaci 
některých předpisů v sociální oblasti týkajících se silni ční dopravy.  
[2] Nařízení Evropského parlamentu a Rady (ES) č. 561/2006 o harmo ­
nizaci některých předpisů v sociální oblasti týkajících se silni ční 
dopravy, o zm ěně nařízení Rady (EHS) č. 3821/85 a (ES) 
č. 2135/98 a o zrušení na řízení Rady (EHS) č. 3820/85 (Text 
s významem pro EHP).  
[3] ERC 70-03 CEPT: ECC Recommendation 70-03: Relating to the 
Use of Short Range Devices (SRD)  
[4] ISO 15638 Intelligent transport systems — Framework for coope ­
rative telematics applications for regulated commercial freight 
vehicles (TARV).  
[5] EN 300 674-1 Electromagnetic compatibility and Radio spectrum 
Matters (ERM); Road Transport and Traffic Telematics (RTTT); 
Dedicated Short Range Communication (DSRC) transmission 
equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz Indu ­
strial, Scientific and Medical (ISM) band; Part 1: General charac ­
teristics and test methods for Road Side Units (RSU) and On-Board 
Units (OBU).  
[6] EN 12253 Road transport and traffic telematics – Dedicated short- 
range communication – Physical layer using microwave at 5.8 GHz.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 491  
[7] EN 12795 Road transport and traffic telematics – Dedicated short- 
range communication – Data link layer: medium access and logical 
link control.  
[8] EN 12834 Road transport and traffic telematics – Dedicated short- 
range communication – Application layer.  
[9] EN 13372 Road transport and traffic telematics – Dedicated short- 
range communication – Profiles for RTTT applications  
[10] ISO 14906 Electronic fee collection — Application interface defi ­
nition for dedicated short- range communication  
4 OPERA ČNÍ SCÉNÁ ŘE 
4.1 Přehled  
Nařízení (EU) č. 165/2014 stanoví specifické a kontrolované scéná ře, 
v nichž má být  komunikace  používána.  
Podporované scéná ře: 
„Communication Profile 1: Roadside inspection using a short range 
wireless communication Remote Early Detection Communication Reader 
instigating a physical roadside inspection (master-:-slave)  
Reader Profile 1a: pomocí komunika čního zařízení včasného dálkového 
odhalování nasm ěrovaného ru čně nebo do časně namontovaného 
a nasměrovaného u silnice  
Reader Profile 1b: via a vehicle mounted and directed Remote Early 
Detection Communication Reader“.  
4.1.1  Podmínky p řenosu dat pomocí rozhraní 5,8 GHz DSRC  
POZNÁMKA: Pro znázorn ění příslušných souvislostí je komunika ční 
zařízení zobrazeno na obrázku 14.3 níže.  
4.1.1.1 Data uchovávaná ve VU  
DSC_12 VU odpovídá za aktualizaci každých 60 sekund a uchovávání 
v něm uložených dat nezávisle na komunika ční funkci DSRC. 
Způsob, jakým je tohoto cíle dosaženo, je vnit řní funkcí VU 
specifikovanou v na řízení (EU) č. 165/2014, p říloze 1 C, bod ě 
3.19 „ Dálková komunikace pro cílené silni ční kontroly “ a není 
specifikován v tomto dodatku.  
4.1.1.2 Data p ředávaná za řízení DSRC-VU  
DSC_13 VU odpovídá za aktualizaci dat tachografu DSRC ( data), 
kdykoli jsou data uložená ve VU aktualizována, v intervalu 
stanoveném v 4.1.1.1 (DSC_12) nezávisle na komunika ční 
funkci DSRC.  
DSC_14 Základem získávání a aktualizace dat jsou data VU, a zp ůsob, 
jakým je toho dosaženo, je uveden v p říloze 1 C bod ě 3.19 
„Dálková komunikace pro cílené silni ční kontroly “, nebo 
pokud příslušné informace uvedeny nejsou, je funkcí 
konstrukce výrobku a není v tomto dodatku uveden. Zp ůsob 
spojení mezi za řízením DSRC-VU a VU je uveden v části 5.6.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 492  
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  
DSC_17 Bezpe čnostní data ( securityData ), obsahující údaje požadované  
REDCR  pro účely dekódování dat, jsou poskytována v souladu 
s dodatkem 11 – Spole čné bezpečnostní mechanismy – 
a prezentována jako hodnota systému dat pro do časné uložení 
v DSRC-VU  jako aktuální verze  securityData  ve formě stano­
vené v tomto dodatku části 5.4.4.  
4.1.1.6 Data VUPM ur čená k přenosu pomocí rozhraní DSRC  
DSC_18 Systém dat, který musí být ve vždy dostupný ve funkci DSRC 
VUPM pro okamžitý p řenos na požádání ze strany  REDCR , je 
definován v části 5.4.4 pro úplné specifikace modulu ASN.1.  
Obecný přehled komunika čního profilu 1  
Tento profil se vztahuje na p řípad použití, kdy pov ěřená osoba p řísluš­
ného kontrolního orgánu používá komunika ční zařízení včasného dálko ­
vého odhalování s dálkovým spojením krátkého dosahu (rozhraní 
5,8 GHz DSRC pracující v rozsahu ERC 70-03 a testované pro p říslušné 
parametry EN 300 674-1, jak je popsáno v oddílu 5) ( REDCR ) pro 
dálkovou identifikaci vozidel, která potenciáln ě porušují na řízení (EU) 
č. 165/2014. Po této identifikaci pov ěřená osoba p říslušného kontrolního 
orgánu, která kontroluje dotazování, rozhodne, zda má být vozidlo zasta ­
veno.  
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 — 26.02.2020 — 002.001 — 493  
Obrázek 14.1  
Sledování ze silnice pomocí 5,8 GHz DSRC
  
4.1.3  Profil 1b: pomocí čtečky komunika čního zařízení včasného dálkového 
odhalování namontovaného a nasm ěrovaného na vozidle  
V tomto p řípadě použití se pov ěřená osoba p říslušného kontrolního 
orgánu nachází v jedoucím vozidle, a bu ď zaměřuje přenosné  REDCR  
držené v ruce z vozidla do st ředu předního skla cíleného vozidla, nebo je  
REDCR  namontováno uvnit ř vozidla nebo na n ěm tak, aby sm ěřovalo do 
středu předního skla cíleného vozidla, je-li vozidlo s čtečkou komuni ­
kačního zařízení včasného dálkového odhalování v p říslušné poloze v ůči 
cílenému vozidlu (nap ř. přímo před ním ve sm ěru jízdy). Dotazování se 
provádí pomocí rozhraní 5,8 GHz DSRC pracujícího v rozsahu ERC 70- 
03 a testovaného pro p říslušné parametry EN 300 674-1, jak je popsáno 
v oddílu 5. Viz obrázek 14.2. (P řípad použití 2).  
Obrázek 14.2  
Sledování z vozidla pomocí 5,8 GHz DSRC
  
4.2 Zabezpe čení/integrita  
Aby bylo možné ov ěřovat pravost a integritu stahovaných dat pomocí 
dálkové komunikace, jsou zabezpe čená data  ověřována a dešifrována 
v souladu s dodatkem 11 – Spole čné bezpečnostní mechanismy.  
5 STRUKTURA A PROTOKOLY DÁLKOVÉ KOMUNIKACE  
5.1 Struktura  
Struktura funkce dálkové komunikace v inteligentním tachografu je 
znázorněna a popsána na obrázku 14.3.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 494  
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 interva ­
lech 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  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 495  
je odpovědný za to, aby byl tento zdroj energie dostate čný 
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 ostat ­
ní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 — 26.02.2020 — 002.001 — 496  
DSC_21 Anténa DSRC musí být spojena se za řízením DSRC-VU bu ď 
přímo v modulu namontovaném na čelním skle nebo v jeho 
blízkosti, nebo prost řednictvím vyhrazeného kabelu 
s konstrukcí, která zt ěžuje nezákonné p řerušení spojení. 
Přerušení spojení nebo rušení s funkcí antény je považováno 
za porušení na řízení (EU) č. 165/2014. Úmyslné zakrývání 
antény nebo jiná nežádoucí manipulace negativn ě ovlivňující 
její provozní výkon jsou považovány za porušení na řízení 
(EU) č. 165/2014.  
DSC_22  ►M1 Tvarový činitel antény není stanoven a je komer čním 
rozhodnutím, pokud namontované za řízení DSRC-VU spl ňuje 
požadavky na shodu podle části 5 níže. Anténa musí být 
umístěna v souladu s pokyny v DSC_19 a ú činně podporovat 
případy použití popsané v bodech 4.1.2 a 4.1.3. ◄ 
Obrázek 14.4  
Příklad polohy antény 5,8 GHz DSRC na čelním skle regulovaných 
vozidel
  
Tvarový činitel  REDCR  a jeho anténa se mohou m ěnit podle podmínek 
čtečky (montáž na stativu, držení v ruce, montáž ve/na vozidle atd.) 
a pracovního postupu pov ěřené osoby p říslušného kontrolního orgánu.  
Funkce zobrazování a/nebo oznamování pov ěřené osobě příslušného 
kontrolního orgánu znázor ňuje výsledky funkce dálkové komunikace. 
Informace se mohou zobrazovat na obrazovce, jako tišt ěný výstup, 
zvukový signál nebo kombinace t ěchto možností. Zp ůsob tohoto zobra ­
zování a/nebo oznamování závisí na požadavcích pov ěřených osob 
příslušných kontrolních orgán ů a konstrukci za řízení a v tomto dodatku 
není stanoven.  
DSC_23 Konstrukce a tvarový činitel  REDCR  jsou funkcí komer čního 
provedení, které pracuje v rámci ERC 70-03, a konstruk čních 
a výkonnostních specifikací stanovených v tomto dodatku 
(oddíl 5.3.2), čímž je trhu poskytnuta maximální pružnost  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 497  
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 — 26.02.2020 — 002.001 — 498  
Kroky jsou popsány níže:  
a. Kdykoli je vozidlo v provozu (zapnuté zapalování), tachograf 
předává data funkci VU. Funkce VU zpracovává  data  pro funkci 
dálkové komunikace (zašifrovaná) a aktualizuje  VUPM  v paměti 
DSRC-VU  (jak je definováno v bodech 4.1.1.1–4.1.1.2). Získaná  
data jsou formátována, jak je uvedeno v bodech 5.4.4–5.4.5 níže.  
b. Při každé příležitosti, kdy jsou  data  aktualizována, je rovn ěž aktu­
alizováno časové razítko definované v zabezpe čeném systému dat.  
c. Funkce  VUSM  zabezpečuje data v souladu s postupy stanovenými 
v dodatku 11.  
d. Při každé p říležitosti, kdy jsou  data  aktualizována (viz 
4.1.1.1–4.1.1.2), jsou p řenesena do  DSRC-VU , kde nahrazují všechna 
předchozí data, aby tato aktualizovaná  data  byla vždy k dispozici 
v případě komunikace s  REDCR . Při předávání z VU do DSRC-VU 
jsou data  označena názvem souboru  RTMData  nebo identifikátory 
ApplicationID a atributy.  
e. Chce-li pov ěřená osoba p říslušného kontrolního orgánu zam ěřit 
vozidlo a získat z n ěj data , musí tato pov ěřená osoba p říslušného 
kontrolního orgánu nejprve vložit do  REDCR  chytrou kartu, která 
dovoluje  komunikaci  a SM-REDCR  umožňuje ověřit její pravost 
a dešifrovat data.  
f. Pověřená osoba p říslušného kontrolního orgánu potom zam ěří 
vozidlo a pomocí dálkové komunikace si vyžádá data.  REDCR  
otevře relaci rozhraní 5,8 GHz DSRC s  DSRC-VU  cíleného vozidla 
a vyžádá si  data . Data  jsou přenesena do  REDCR  prostřednictvím 
systému bezdrátové komunikace DSCR atribut používajícího službu 
aplikace GET, jak je stanoveno v oddíle 5.4. Atribut obsahuje šifro ­
vané hodnoty p řenášených dat a zabezpe čená data DSRC.  
g. Data jsou za řízením  REDCR  analyzována a p ředána pověřené osobě 
příslušného kontrolního orgánu.  
h. Pověřená osoba p říslušného kontrolního orgánu použije data k tomu, 
aby rozhodla, zda má vozidlo zastavit k podrobné kontrole, či nikoli, 
nebo požádat jinou pov ěřenou osobu p říslušného kontrolního orgánu 
o zastavení vozidla.  
5.2.2  Interpretace dat p řijímaných prost řednictvím komunikace DSRC  
DSC_26 Data p řijatá prostřednictvím rozhraní 5,8 GHz mají význam 
a smysl stanovený v bodech 5.4.4 a 5.4.5 níže a pouze takový 
význam a smysl a jsou chápána ve smyslu zde stanovených 
cílů. V souladu s ustanoveními na řízení (EU) č. 165/2014 
musí být  data  používána pouze pro poskytování náležitých  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 499  
informací p říslušnému kontrolnímu orgánu, aby mohl rozhod ­
nout, zda má vozidlo zastavit pro ú čely fyzické kontroly, 
a následně zlikvidována v souladu s článkem 9 na řízení 
(EU) č. 165/2014.  
5.3 Parametry fyzického rozhraní DSRC pro dálkovou komunikaci  
5.3.1  Omezení umíst ění 
DSC_27 Dálkové sledování vozidel prost řednictvím rozhraní 5,8 GHz 
DSRC by nem ělo být používáno v rozsahu do 200 metr ů od 
provozní brány 5,8 GHz DSRC.  
5.3.2  Parametry downlinku a uplinku  
DSC_28 Za řízení používané pro dálkové sledování tachograf ů musí 
odpovídat doporu čení ERC 70-03 a parametr ům stanoveným 
v tabulkách 14.1 a 14.2 níže a pracovat v jejich rozsahu.  
DSC_29 Pro zajišt ění kompatibility s provozními parametry jiných 
standardních systém ů 5,8 GHz DSRC musí dále za řízení 
používané pro dálkové sledování tachograf ů odpovídat para ­
metrům EN 12253 a EN 13372.  
Konkrétně: 
Tabulka 14.1  
Parametry downlinku  
▼C2 
Číslo položky  Parametr  Hodnota (hodnoty)  Poznámka  
D1 Nosné frekvence downlinku  Snímač REDCR m ůže 
použít čtyři alternativy: 
5,7975 GHz 
5,8025 GHz 
5,8075 GHz 
5,8125 GHz  V rámci ERC 70-03. 
Nosné frekvence nosi če může 
zvolit realizátor silni čního systému 
a nemusí být známy za řízení 
DSRC-VU. 
(V souladu s normami EN 12253, 
EN 13372)  
D1a (*) Tolerance nosných 
frekvencí  do ± 5 ppm  (V souladu s normou EN 12253)  
D2 (*) Spektrální maska vysíla če 
RSU (REDCR)  V rámci ERC 70-03. 
REDCR musí odpovídat 
třídám B a C podle normy 
EN 12253. 
Žádné jiné zvláštní poža ­
davky v rámci této p řílohy.  Parametr používaný ke kontrole 
rušení mezi dotazovacími za říze­
ními ve vzájemné blízkosti (podle 
norem EN 12253 a EN 13372).  
D3 Minimální frekven ční 
rozsah palubní jednotky 
OBU(DSRC-VU)  5,795 – 5,815 GHz  (V souladu s normou EN 12253)  
D4 (*) Maximální výkon EIRP  V rámci ERC 70-03 (bez 
licence) a v souladu s vnit ­
rostátními právními p řed­
pisy 
Maximálně + 33 dBm  (V souladu s normou EN 12253)  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 500  
Čí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 % (ampli ­
tuda)  
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 interva ­
lu. (V souladu s normou EN 12253)  
D8 (*) Bitový tok  500 kBit/s  (V souladu s normou EN 12253)  
D8a Tolerance bitových hodin  Lepší než ± 100 ppm.  (V souladu s normou EN 12253)  
D9 (*) Bitová chybovost (B.E.R.) 
pro komunikaci  ≤ 10  – 6 , jestliže dopadající 
výkon na OBU (DSRC-VU) 
je v rozmezí stanoveném 
v bodech [D11a až D11b].  (V souladu s normou EN 12253)  
D10 Spoušt ěcí signál pro OBU 
(DSRC-VU)  OBU (DSRC-VU) se musí 
spustit po p řijetí jakéhokoli 
rámce s nejmén ě 11 oktety 
(včetně preambule).  Není nutný žádný zvláštní vzor 
spouštění. 
DSRC-VU se m ůže spustit i po 
přijetí rámce s mén ě než 11 oktety. 
(V souladu s normou EN 12253)  
D10a  Maximální doba zahájení  ≤ 5 ms  (V souladu s normou EN 12253)  
D11 Komunika ční zóna  Prostorová oblast, ve které 
se dosahuje hodnoty B.E.R 
podle bodu D9a.  (V souladu s normou EN 12253)  
D11a  (*) Mezní hodnota výkonu pro 
komunikaci (horní).  – 24dBm  (V souladu s normou EN 12253)  ▼C2
 02016R0799 — CS — 26.02.2020 — 002.001 — 501  
Čí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ě rovno­
běžné s povrchem vozovky, 
když se DSRC-VU pozd ěji 
instaluje ve vozidle (azi ­
mut))  (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)  
(*) – Parametry downlinku, které podléhají zkoušce shody v souladu s p říslušnou zkouškou parametr ů uvedenou v norm ě EN 
300 674-1.  
Tabulka 14.2  
Parametry uplinku  
Čí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 — 26.02.2020 — 002.001 — 502  
Čí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 — 26.02.2020 — 002.001 — 503  
Čí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)  
(*) – Parametry uplinku, které podléhají zkoušce shody v souladu s p říslušnou zkouškou parametr ů uvedenou v norm ě EN 300 674-1.  
▼B 
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 — 26.02.2020 — 002.001 — 504  
DSC_32 Anténa VU je p řipevněna k čelnímu sklu vozidla nebo v jeho 
blízkosti, jak je uvedeno v bod ě 5.1 výše.  
DSC_33 Ve zkušebním prost ředí v díln ě (viz část 6.3) by se anténa 
DSCR-VU upevn ěná, jak je popsáno výše v bod ě 5.1, měla 
úspěšně připojit ke standardní zkušební komunikaci a úsp ěšně 
zajistit transakci RTM podle definice v tomto dodatku na 
vzdálenost 2 až 10 metr ů, po více než 99 % času, zprůměro­
váno na 1 000 p řečtených dotaz ů. 
5.4 Požadavky protokolu DSRC pro RTM  
5.4.1  Přehled  
DSC_34 Transak ční protokol pro stahování  dat  pomocí rozhraní 
5,8 GHz DSRC musí být v souladu s následujícími kroky. 
Tento oddíl popisuje postup transakce v ideálních podmín ­
kách, aniž by docházelo k opakovanému vysílání nebo 
přerušení komunikace.  
POZNÁMKA Ú čelem inicia ční fáze (krok 1) je vytvo ření 
komunikace mezi  REDCR  a DSRC celk ů ve vozidle, které 
se dostaly do transak ční zóny 5,8 GHz DSRC ( řídicí jedno ­
tka-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ý 
podporuje. 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 podporo ­
vaných aplikací v domén ě Freight&Fleet nebo neodpoví, 
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 — 26.02.2020 — 002.001 — 505  
— 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ý identifiká ­
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 — 26.02.2020 — 002.001 — 506  
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 — 26.02.2020 — 002.001 — 507  
— GET.request : Příkaz vydaný  REDCR  pro  DSRC-VU , 
který určí příslušnou realizaci aplikace pomocí definova ­
ného EID, jak byl p řijat ve VST, a dává  DSRC-VU  pokyn 
k odeslání vybraných atribut ů s daty . Cílem příkazu GET 
je pro  REDCR  získání  dat od DSRC-VU . 
— GET.response : Odpověď DSRC-VU, která obsahuje 
požadovaná  data . 
— ACTION.request ECHO : Příkaz pro  DSRC-VU , aby 
vrátil data z  DSRC-VU  do REDCR . Cílem p říkazu 
ECHO je umožnit dílnám nebo testovacím za řízením 
pro typové zkoušky testovat funkci spojení DSRC bez 
nutnosti přístupu k bezpe čnostním údaj ům. 
— ACTION .response ECHO: Odpov ěď DSRC VU na 
příkaz ECHO.  
— EVENT_REPORT.request  RELEASE: P říkaz pro  
DSRC-VU , že transakce je ukon čena. Cílem p říkazu 
RELEASE je ukon čení relace s  DSRC-VU . Po přijetí 
příkazu RELEASE  DSRC-VU  neodpovídá na žádné 
další dotazy v rámci aktuálního spojení. Podle EN 
12834 se DSRC-VU nep řipojí dvakrát ke stejnému 
dotazovacímu za řízení, není-li mimo komunika ční zónu 
255 sekund nebo zm ění-li se ID signálu dotazovacího 
zařízení.  
5.4.3  Pořadí dotazovacích p říkazů 
DSC_36 Z hlediska po řadí příkazů a odpovědí lze transakci popsat 
takto:  
▼C2 
Sekvence  Odesílatel  P říjemce  Popis  Činnost  
1 REDCR  >  DSRC-VU  Inicializace komunika čního 
spojení – Požadavek  Snímač REDCR odesílá 
tabulku BST.  
2 DSRC-VU  >  REDCR  Inicializace komunika čního 
spojení – Odpov ěď Jestliže tabulka BST 
podporuje 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 — 26.02.2020 — 002.001 — 508  
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). 
▼C2 
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.  
▼B 
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 — 26.02.2020 — 002.001 — 509
  
► (1) (2) (3) (4)  M1 ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 510
  
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:  
Tabulka 14.3  
Prvky RTMData, provedené akce a definice  
▼C2 
(1) Datový 
prvek RTM  (2) Činnost, kterou provádí VU  (3)  Definice údaj ů podle ASN.1  
RTM1 
Registrační 
značka 
vozidla  VU určí hodnotu datového prvku RTM1  
tp15638VehicleRegistrationPlate  ze zazname ­
nané hodnoty datového typu  VehicleRegistrati ­
onIdentification  podle definice v dodatku 1  
VehicleRegistrationIdentification  Registrační 
značka vozidla 
vyjádřená jako 
řetězec znaků
 
RTM2 
Událost – 
překročení 
povolené 
rychlosti  VU vygeneruje booleovskou hodnotu pro 
datový prvek RTM2 tp15638SpeedingEvent. 
VU vypočte hodnotu tp15638SpeedingEvent 
z počtu událostí p řekročení rychlosti ( Over 
Speeding Events ) zaznamenaných ve VU 
během posledních 10 dní výskytu podle p řílohy 
1C. 1 (TRUE) – 
znamená nesrov ­
nalosti týkající se 
rychlosti 
v průběhu 
posledních 10 dní 
výskytu.
  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 511  
(1) Datový 
prvek RTM  (2) Činnost, kterou provádí VU  (3)  Definice údaj ů podle ASN.1  
Jestliže během posledních 10 dní výskytu došlo 
alespoň k jedné události tp15638SpeedingE ­
vent, hodnota tp15638SpeedingEvent se 
nastaví na TRUE. 
JINAK, jestliže se b ěhem posledních 10 dní 
výskytu nezaznamenaly žádné události, 
hodnota tp15638SpeedingEvent se nastaví na 
FALSE.  
RTM3 
Řízení bez 
platné karty  VU vygeneruje booleovskou hodnotu pro 
datový prvek RTM3 tp15638DrivingWithou ­
tValidCard. 
VU přiřadí proměnné tp15638DrivingWithou ­
tValidCard hodnotu TRUE, jestliže se v údajích 
VU během posledních 10 dní výskytu zazna ­
menala alespo ň jedna událost typu „ řízení 
vozidla bez p říslušné karty“ podle p řílohy 1C. 
JINAK, jestliže se b ěhem posledních 10 dní 
výskytu nezaznamenaly žádné události, 
proměnná tp15638DrivingWithoutValidCard 
se nastaví na FALSE.  1 (TRUE) = 
označuje použití 
neplatné karty.
  
RTM4 
Platná karta 
řidiče VU vygeneruje booleovskou hodnotu pro 
datový prvek RTM4 tp15638DriverCard na 
základě údajů uložených ve VU a vymezených 
v dodatku 1. 
Jestliže není p řítomná žádná platná karta řidiče, 
VU nastaví prom ěnnou na TRUE. 
JINAK, jestliže je p řítomná platná karta řidiče, 
VU nastaví prom ěnnou na FALSE.  0 (FALSE) = 
znamená platnou 
kartu řidiče
 
RTM5 
Vložení karty 
během řízení  VU vygeneruje booleovskou hodnotu pro 
datový prvek RTM5. 
VU přiřadí proměnné tp15638CardInsertion 
hodnotu TRUE, jestliže se v údajích VU 
zaznamenala b ěhem posledních 10 dní výskytu 
alespoň jedna událost typu „Vložení karty 
během řízení“ podle definice v p říloze 1C. 
JINAK, jestliže se b ěhem posledních 10 dní 
výskytu nezaznamenaly žádné takové události, 
proměnná tp15638CardInsertion se nastaví na 
FALSE.  1 (TRUE) = 
označuje vložení 
karty během 
řízení v průběhu 
posledních 10 dní 
výskytu.
  
RTM6 
Chyba údaj ů 
o pohybu  VU vygeneruje booleovskou hodnotu pro 
datový prvek RTM6. 
VU přiřadí proměnné tp15638MotionDataError 
hodnotu TRUE, jestliže se v údajích VU 
zaznamenala b ěhem posledních 10 dní výskytu 
alespoň jedna událost typu „chyba údaj ů 
o pohybu“ podle definice v p říloze 1C. 
JINAK, jestliže se b ěhem posledních 10 dní 
výskytu nezaznamenaly žádné takové události, 
proměnná tp15638MotionDataError se nastaví 
na FALSE.  1 (TRUE) = 
označuje chybu 
údajů o pohybu 
během posled ­
ních 10 dní 
výskytu.
  ▼C2
 02016R0799 — CS — 26.02.2020 — 002.001 — 512  
(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é tp15638vehicleMotion ­
Conflict hodnotu TRUE, jestliže se v údajích 
VU zaznamenala v pr ůběhu posledních 10 dní 
výskytu alespo ň jedna událost typu „nesoulad 
údajů o pohybu vozidla“ (hodnota „0A“H). 
JINAK, jestliže se b ěhem posledních 10 dní 
výskytu nezaznamenaly žádné události, 
proměnná tp15638vehicleMotionConflict se 
nastaví na FALSE.  1 (TRUE) = 
označuje 
nesoulad údaj ů 
o pohybu b ěhem 
posledních 10 dní 
výskytu.
  
RTM8 
Druhá karta 
řidiče VU vygeneruje booleovskou hodnotu pro 
datový prvek RTM8 na základ ě přílohy 1C 
(„údaje o činnosti řidiče“ POSÁDKA 
a DRUHÝ ŘIDIČ). 
Jestliže je p řítomná druhá platná karta řidiče, 
VU nastaví prom ěnnou na TRUE. 
JINAK, jestliže druhá platná karta řidiče není 
přítomná, VU nastaví prom ěnnou na FALSE.  1 (TRUE) = 
označuje 
vloženou druhou 
kartu řidiče.
 
RTM9 
Aktuální 
činnost  VU vygeneruje booleovskou hodnotu pro 
datový prvek RTM9. 
Jestliže se aktuální činnost zaznamená ve VU 
jako jakákoli jiná činnost než ŘÍZENÍ podle 
definice v p říloze 1C, VU nastaví prom ěnnou 
na TRUE. 
JINAK, jestliže se aktuální činnost zaznamená 
ve VU jako „ řízení“ (DRIVING), VU nastaví 
proměnnou na FALSE.  1 (TRUE) = 
zvolená jiná 
činnost, 
0 (FALSE) = 
zvoleno řízení
  
RTM10 
Poslední 
relace 
uzavřená VU vygeneruje booleovskou hodnotu pro 
datový prvek RTM10. 
Jestliže poslední relace karty nebyla správn ě 
uzavřena podle definice v p říloze 1C, VU 
nastaví prom ěnnou na TRUE. 
JINAK, jestliže poslední relace karty byla 
ukončená správn ě, VU nastaví prom ěnnou na 
FALSE.  1 (TRUE) = 
nesprávné 
uzavření 
0 (FALSE) = 
správné uzav ření
 
RTM11 
Přerušení 
dodávky 
energie  VU vygeneruje celo číselnou hodnotu pro 
datový prvek RTM11. 
VU přiřadí proměnné tp15638PowerSupplyIn ­
terruption hodnotu rovnající se nejdelšímu 
přerušení dodávky energie podle článku 9 na ří­
zení (EU) č. 165/2014 typu „p řerušení 
dodávky energie“ podle definice v p říloze 1C.  — Počet 
přerušení 
dodávky 
energie 
během 
posledních 
10 dní 
výskytu
  ▼C2
 02016R0799 — CS — 26.02.2020 — 002.001 — 513  
(1) Datový 
prvek RTM  (2) Činnost, kterou provádí VU  (3)  Definice údaj ů podle ASN.1  
JINAK, jestliže b ěhem posledních 10 dní 
výskytu nedošlo k p řerušení dodávky energie, 
proměnná se nastaví na 0.  
▼M1 
RTM12 
Porucha 
snímače VU vygeneruje celo číselnou hodnotu pro 
datový prvek RTM12. 
VU přiřadí proměnné sensorFault hodnotu: 
— 1, jestliže b ěhem posledních 10 dní zazna ­
menal událost typu ‘35H’ Porucha 
snímače, 
— 2, jestliže b ěhem posledních 10 dní zazna ­
menal událost typu Porucha p řijímače 
GNSS (interního nebo externího s hodno ­
tami enum ‘36’H nebo ‘37’H), 
— 3, jestliže b ěhem posledních 10 dní zazna ­
menal událost typu ‘0E’H Chyba komuni ­
kace s vnějším zařízením GNSS, 
— 4, jestliže b ěhem posledních 10 dní zazna ­
menal poruchu sníma če i poruchu p řijí­
mače GNSS, 
— 5, jestliže b ěhem posledních 10 dní zazna ­
menal poruchu sníma če i událost Chyba 
komunikace s vn ějším zařízením GNSS, 
— 6, jestliže b ěhem posledních 10 dní zazna ­
menal poruchu p řijímače GNSS i událost 
Chyba komunikace s vn ějším zařízením 
GNSS, 
— 7, jestliže b ěhem posledních 10 dní zazna ­
menal všechny t ři poruchy sníma če, 
JINAK přiřadí hodnotu 0, jestliže b ěhem 
posledních 10 dní nebyly zaznamenány 
žádné události.  – Porucha 
snímače – 
jeden oktet 
podle slovníku 
údajů
 
▼C2 
RTM13 
Nastavení 
času VU vygeneruje celé číslo (timeReal z dodatku 
1) pro datový prvek RTM13 na základ ě 
přítomnosti údaj ů o nastavení času podle defi ­
nice v příloze 1C. 
VU přiřadí hodnotu času, kdy došlo k poslední 
události nastavení času. 
JINAK, jestliže v údajích VU neexistuje žádná 
událost nastavení času podle definice 
v příloze 1C, VU nastaví hodnotu 0  Čas posledního 
nastavení času
 
RTM14 
Pokus o naru ­ 
šení zabezpe ­ 
čení VU vygeneruje celé číslo (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 1C.  Čas posledního 
pokusu o naru ­ 
šení 
— standardní 
hodnota = 
0x00FF
  ▼C2
 02016R0799 — CS — 26.02.2020 — 002.001 — 514  
(1) Datový 
prvek RTM  (2) Činnost, kterou provádí VU  (3)  Definice údaj ů podle ASN.1  
VU nastaví hodnotu času posledního pokusu 
o narušení zabezpe čení, který VU zaznamenal. 
JINAK, jestliže v údajích VU není zazna ­
menán žádný pokus o narušení zabezpe čení 
podle definice v p říloze 1C, VU nastaví 
hodnotu 0x00FF.  
RTM15 
Poslední kali ­
brace  VU vygeneruje celé číslo (timeReal z dodatku 
1) pro datový prvek RTM15 na základ ě 
přítomnosti údaj ů o poslední kalibraci podle 
definice v p říloze 1C. 
VU nastaví hodnotu času posledních dvou kali ­
brací (RTM15 a RTM16), které jsou nastaveny 
ve VuCalibrationData podle definice 
v dodatku 1. 
VU nastaví hodnotu pro RTM15 na timeReal 
posledního záznamu o kalibraci.  Údaje o čase 
poslední kali ­
brace
  
RTM16 
Předcházející 
kalibrace  VU vygeneruje celé číslo (timeReal z dodatku 
1) pro datový prvek RTM16 záznamu o kali ­
braci, který p ředchází záznamu o poslední kali ­
braci 
JINAK, jestliže k žádné p ředcházející kalibraci 
nedošlo, VU nastaví hodnotu RTM16 na 0.  Údaje o čase 
předcházející 
kalibrace
  
RTM17 
Datum p řipo­
jení tacho ­
grafu  VU vygeneruje pro datový prvek RTM17 celo ­ 
číselnou hodnotu (timeReal z dodatku 1). 
VU nastaví hodnotu času první instalace VU. 
VU tyto údaje extrahuje z VuCalibrationData 
(dodatek 1) z vuCalibrationRecords, p řičemž 
CalibrationPurpose sa rovná: „03“H  Datum připojení 
tachografu
  
RTM18 
Aktuální 
rychlost  VU vygeneruje celo číselnou hodnotu pro 
datový prvek RTM18. 
VU nastaví hodnotu pro RTM16 na poslední 
aktuální zaznamenanou rychlost v čase 
poslední aktualizace RtmData.  Poslední aktuální 
zaznamenaná 
rychlost
  
RTM19 
Časové 
razítko  VU vygeneruje pro datový prvek RTM19 celo ­ 
číselnou hodnotu (timeReal z dodatku 1). 
VU nastaví hodnotu pro RTM19 na čas 
poslední aktualizace RtmData.  Časové razítko 
aktuálního 
záznamu 
TachographPay ­
load
 
▼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.  ▼C2
 02016R0799 — CS — 26.02.2020 — 002.001 — 515  
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 (Beaco ­
nId) Podle normy EN 12834  
Č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  ▼M1
 02016R0799 — CS — 26.02.2020 — 002.001 — 516
 Oktet č. 
Atribut/pole  Bity v oktetu  Popis  
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 }
  
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  ▼C2
 02016R0799 — CS — 26.02.2020 — 002.001 — 517
 Oktet č. 
Atribut/pole  Bity v oktetu  Popis  
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í 
▼B 
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
 ▼C2
 02016R0799 — CS — 26.02.2020 — 002.001 — 518
 Oktet č. 
Atribut/pole  Bity v oktetu  Popis  
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 
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.  ▼C2
 02016R0799 — CS — 26.02.2020 — 002.001 — 519  
Tabulka 14.9  
Inicializace – p říklad obsahu rámce VST  
▼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
  P říkaz UI  
8 Fragmentation header
  Bez fragmentace  
9 VST 
SEQUENCE {
  Odpověď v rámci iniciali ­
zace 
Fill BIT STRING (SIZE(4))
  Nepoužito a nastaveno na 
0. 
10 Profile INTEGER (0..127,…) 
Applications SEQUENCE OF {
  Bez rozší ření. Příklad 
profilu 0  
11
 Bez rozší ření, 1 aplikace  
12 SEQUENCE {  
OPTION indicator  Identifikátor EID 
přítomný  
OPTION indicator
  Parametr p řítomný  
AID DSRCApplicationEntityID
  Bez rozšíření. AID = 2 
Freight&Fleet  
13 EID Dsrc-EID
  Definováno v rámci 
OBU, identifikuje instanci 
aplikace.  
14 Parameter Container {
  Bez rozší ření, volba 
kontejneru = 02. 
oktetový řetězec 
15
 Bez rozší ření, délka 
kontextové zna čky 
Rtm = 8  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 520
 Oktet č. 
Atribut/pole  Bity v oktetu  Popis  
16 Rtm-ContextMark::= SEQUENCE { 
StandardIdentifier 
standardIdentifier
  ►M1 Identifikátor obje- 
ktu podporované normy, 
části a verze. P říklad: 
ISO (1) norma (0) 
TARV (15638) část9 (9) 
verze 1 (1). 
První oktet je 06H, což je 
identifikátor objektu. 
Druhý oktet je 06H, což 
je délka. Následujících 6 
oktetů kóduje identifikátor 
objektu příkladu. ◄ 17
 
18
 
19
 
20
 
21
 
22
 
23
 
24 ObeConfiguration Sequence {  
OPTION indicator
  ObeStatus nep řítomný  
EquipmentClass INTEGER (0..32767)
  
25
 
26 ManufacturerId INTEGER (0..65535)
  Identifikátor výrobce 
DSRC-VU podle popisu 
v rejstříku v ISO 14816  27
 
28 FCS
  Kontrolní sekvence rámce  
29
 
30 Flag
  P říznak ukon čení 
▼B 
DCS_49 REDCR potom na čte data vydáním p říkazu GET odpovídají ­
címu příkazu GET podle definic v EN 13372, 6.2, 6.3, 6.4 
a EN 12834 s nastaveními uvedenými v tabulce 14.10.  
Tabulka 14.10  
Prezentace – nastavení rámce žádosti GET  
▼C2 
Pole Nastavení  
Invoker Identifier (IID)  Nep řítomný  
Link Identifier (LID)  Adresa spojení konkrétního DSRC- 
VU 
Chaining  Ne  
Element Identifier (EID)  Podle specifikace ve VST. Bez rozší ­ 
ření ▼C2
 02016R0799 — CS — 26.02.2020 — 002.001 — 521  
Pole Nastavení  
Access Credentials  Ne  
AttributeIdList  Bez rozší ření, 1 atribut, AttributeID = 
1 (RtmData)  
Fragmentation  Ne  
Nastavení vrstvy 2  PDU p říkazu, dotazovaný ( polled ) 
příkaz ACn  
▼B 
Tabulka 14.11 uvádí p říklad čtení dat RTM.  
Tabulka 14.11  
Prezentace – p říklad rámce žádosti Get  
▼C2
 
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 — 26.02.2020 — 002.001 — 522  
DSC_50 Po p řijetí žádosti GET odešle  DSRC-VU  odpověď GET 
s požadovanými daty odpovídajícími odpov ědi GET podle 
definic v EN 13372, 6.2, 6.3, 6.4 a EN 12834 s nastaveními 
podle tabulky 14.12.  
Tabulka 14.12  
Prezentace – nastavení rámce odpov ědi GET  
▼C2 
Pole Nastavení  
Invoker Identifier (IID)  Nep řítomný  
Link Identifier (LID)  Podle normy EN 12834  
Chaining  Ne  
Element Identifier (EID)  Podle specifikace ve VST.  
Access Credentials  Ne  
Fragmentation  Ne  
Nastavení vrstvy 2  PDU odpov ědi, odpov ěď 
dostupná a p říkaz akcepto ­
vaný, příkaz ACn  
▼B 
Tabulka 14.13 uvádí p říklad čtení dat RTM.  
Tabulka 14.13  
Prezentace – p říklad obsahu rámce odpov ědi 
▼C2
 
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 — 26.02.2020 — 002.001 — 523
 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_RE ­
PORT, 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 RELE ­
ASE.  
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 — 26.02.2020 — 002.001 — 524
 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 (Rele ­
ase) 
OPTION indicator
  Přístupové oprávn ění 
nepřítomné  
OPTION indicator
  Parametr události nep ří­
tomný  
OPTION indicator
  Identifikátor IID nep ří­
tomný  
Mode BOOLEAN
  Neočekává se odpov ěď 
10 EID INTEGER (0..127,…)
  Bez rozší ření, EID = 0 
(systém)  
11 EventType INTEGER (0..127,…)}
  Typ události 0 = Release  
12 FCS
  Kontrolní sekvence rámce  
13
 
14 Flag
  P říznak ukon čení 
▼B 
DSC_52 Neo čekává se, že  DSRC-VU  odpoví na p říkaz Release. 
Komunikace je poté ukon čena. 
5.4.8  Popis transakce testu DSRC  
DSC_53 Úplné testy, které zahrnují zabezpe čení dat, musí být 
prováděny podle dodatku 11 – Spole čné bezpečnostní mecha ­
nismy oprávn ěnými osobami s p řístupem k bezpe čnostním 
postupům pomocí normálních p říkazů GET stanovených výše.  
DSC_54 Uvedení do provozu a pravidelné kontrolní testy, které 
vyžadují 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 – mini ­
má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 — 26.02.2020 — 002.001 — 525  
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í 
podporovaný p říklad použití.  
— Krok 5  REDCR  potom analyzuje nabízenou VST a bu ď 
ukončí spojení (RELEASE), protože nemá zájem o nic, 
co VST m ůže nabídnout (tj. p řijímá VST od  DSRC-VU , 
který nepodporuje transakci RTM ), nebo p řijme-li 
příslušnou VST, spustí realizaci aplikace.  
— Krok 6  REDCR  odešle p říkaz (ECHO) p říslušnému  
DSRC-VU  a přidělí soukromé okno.  
— Krok 7  DSRC-VU  použije nov ě přidělené soukromé okno 
pro odeslání rámce odpov ědi ECHO.  
V následujících tabulkách je uveden praktický p říklad vým ěnné relace 
ECHO.  
DSC_56 Inicializace je provedena podle 5.4.7 (DSC_44 – DSC_48) 
a tabulek 14.4 – 14.9.  
DSC_57 REDCR potom odešle p říkaz ACTION, ECHO odpovídající 
ISO 14906 a obsahující 100 oktet ů dat bez speciálního nasta ­
vení RTM. V tabulce 14.15 je uveden obsah rámce odesla ­
ného REDCR.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 526  
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 — 26.02.2020 — 002.001 — 527  
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 — 26.02.2020 — 002.001 — 528  
__________  
▼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  
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:  ▼M2
 02016R0799 — CS — 26.02.2020 — 002.001 — 529
  
DSC_74 Popis p říkazů a parametr ů: 
—
 
se používá pro inicializaci komunika čního spojení. P říkaz 
je odeslán z VU do DSRC-VU. VU stanoví LinkIdentifier 
a sdělí jej DSRC-VU pro vytvo ření specifického komuni ­
kačního spojení.  
(Pozn.: slouží k podpo ře budoucích spojení a dalších apli ­
kací/modul ů jako např. vážení na palub ě). 
—
 
používá DSRC-VU pro odeslání odpov ědi na žádost 
o inicializaci komunika čního spojení. P říkaz odešle 
DSRC-VU do VU. P říkaz poskytuje výsledek inicializace 
jako odpov ěď = 1 (úspěch) nebo = 0 (selhání).  
DSC_75 Inicializace komunika čního spojení se provádí po instalaci, 
kalibraci a spušt ění motoru/VU.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 530  
—
 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. Parametr 
DataTransactionId ozna čuje specifický p řenos dat. LinkI ­
dentifier 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 speci ­
fický LinkIdentifier.  
DSC_76 P ři novém spušt ění DSRC-VU nebo VU by všechny stávající 
komunikační odkazy m ěly být odstran ěny, protože se mohou 
vyskytovat „zbytkové“ odkazy v d ůsledku neo čekávaného 
vypnutí VU.  
—
 
odesílá DSRC-VU do VU pro potvrzení žádosti o ukon ­ 
čení spojení ze strany VU pro specifický LinkIdentifier.  
5.7 Řešení chyb  
5.7.1  Záznamy a komunikace dat v DSRC-VU  
▼M1 
DSC_77 Již zabezpe čená data  jsou funkcí  VUSM  poskytnuta  DSRC- 
VU. VUSM  ověří, zda data zaznamenaná v  DSRC-VU  byla 
řádně zaznamenána. Zaznamenání a hlášení p řípadných chyb 
v přenosu dat z  VU do paměti DSRC-VU  je zaznamenáno 
s typem EventFaultType a hodnotou enum nastavenou na 
‘0C’H Chyba komunikace se za řízením pro dálkovou komu ­
nikaci s časovým razítkem.  
▼B 
DSC_78  VU  uchovává soubor ozna čený jedine čným názvem, který 
mohou pracovníci kontroly snadno identifikovat pro ú čely 
zaznamenání„poruchy interní komunikace VU“.  
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 — 26.02.2020 — 002.001 — 531  
na ‘62’H  Chyba komunikace  zařízení vzdálené komunikace  
s časovým razítkem. Selhání komunikace je zjišt ěno, není-li 
zpráva
  pro p říslušný příkaz 
(tj. se stejnými zprávami DataTransactionId
  
)
 
přijata déle než b ěhem tří následných pokus ů. 
5.7.2  Chyby bezdrátové komunikace  
DSC_80 Řešení chyb komunikace odpovídá ustanovením p říslušných 
norem DSRC, konkrétn ě EN 300 674-1, EN 12253, EN 
12795, EN 12834 a p říslušným parametr ům EN 13372.  
5.7.2.1  Chyby šifrování a podpisu  
DSC_81 Chyby šifrování a podpisu se řeší v souladu s dodatkem 11 
Společné bezpe čnostní mechanismy a nejsou p řítomné 
v žádných chybových hlášeních spojených s p řenosem dat 
DSRC.  
5.7.2.2  Záznam chyb  
Médium DSRC je dynamická bezdrátová komunikace v prost ředí nejis­
tých atmosférických a interferen čních podmínek, zejména v kombinacích 
„přenosné REDCR“ a „pohybující se vozidlo“ v rámci této aplikace. Je 
proto třeba uvědomit si rozdíl mezi „chybou čtení“ a „chybovými“ 
podmínkami. P ři přenosu prost řednictvím bezdrátového rozhraní je 
chyba čtení běžná a důsledkem je obvykle nový pokus, tj. nová relace 
BST a nový pokus o sekvenci, které ve v ětšině případů vedou k úsp ěš­
nému komunika čnímu spojení a p řenosu dat, pokud se cílové vozidlo 
během času potřebného pro nový p řenos nedostane z dosahu. 
(„Úspěšný“ případ „čtení“ může zahrnovat n ěkolik pokus ů a nových 
spojení.)  
Chyba čtení může být důsledkem nesprávného spárování antén (chyba 
„zaměření“); zastín ění jedné z antén – m ůže být úmyslné, ale rovn ěž 
důsledkem fyzické p řítomnosti jiného vozidla; rádiové interference, 
zejména za řízení WIFI v pásmu cca 5,8 GHz nebo jiných ve řejně 
přístupných bezdrátových komunikací nebo m ůže být způsobeno rada ­
rovou interferencí nebo nep říznivými atmosférickými podmínkami (nap ř. 
za bouřky); nebo jednoduše vyjetím z dosahu komunikace DSRC. 
Jednotlivé p řípady chyb čtení nelze z jejich povahy zaznamenat, protože 
komunikace nebyla prost ě navázána.  
Pokud však oprávn ěná osoba p říslušných kontrolních orgán ů zaměří 
vozidlo a pokusí se zjistit jeho  DSRC-VU , ale nedojde k úsp ěšnému 
přenosu dat, m ůže k tomuto selhání dojít v d ůsledku úmyslné manipu ­
lace, a proto musí mít oprávn ěná osoba p říslušných kontrolních orgán ů 
k dispozici prost ředek pro zaznamenání selhání a upozorn ění kolegů na 
cestě o možné manipulaci. Kolegové potom mohou zastavit vozidlo 
a provést fyzickou kontrolu. Pokud však není úsp ěšně navázána komu ­
nikace, systém DSRC-VU nem ůže poskytnout data týkající se selhání. 
Podávání t ěchto zpráv je proto funkcí konstrukce za řízení REDCR.  
„Selhání čtení“ je technicky odlišné od „chyby“. V této souvislosti je 
„chyba“ přijetí špatné hodnoty.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 532  
Přenos dat do  DSRC-VU  je realizován již v zabezpe čené podob ě, proto 
musí být ov ěřen poskytovatelem dat (viz 5.4).  
Data následn ě přenášená vzdušným rozhraním se kontrolují cyklickými 
redundantními kontrolami na komunika ční úrovni. Je-li CRC úsp ěšná, 
jsou data správná. Není-li CRC úsp ěšná, jsou data p řenášena znovu. 
Pravděpodobnost, že by nesprávná data mohla úsp ěšně projít CRC, je 
statisticky tak nízká, že m ůže být zanedbána.  
Není-li validace CRC úsp ěšná a není čas pro nový p řenos a přijetí 
správných dat, nebude výsledkem chyba, ale p řípad specifického typu 
selhání čtení. 
Jediné smysluplné „selhání“ dat, které m ůže být zaznamenáno, je chyba 
počtu úspěšných inicializací transakcí, které nevedou k úsp ěšnému 
přenosu dat do REDCR.  
DSC_82 REDCR proto zaznamenává po čet časově označených 
případů, kdy je „inicializa ční“ fáze sledování DSRC úsp ěšná, 
ale transakce je ukon čena před úspěšným přijetím  dat  
v REDCR. Tato data jsou k dispozici oprávn ěné osobě 
příslušných kontrolních orgán ů a jsou uložena v pam ěti 
zařízení REDCR. Zp ůsob, jakým je toho dosaženo, je záleži ­
tostí 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 ů: 
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 . ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 533  
Cílem příkazu ECHO je umožnit dílnám nebo testovacím za řízením pro 
typové zkoušky testovat funkci spojení DSRC bez nutnosti p řístupu 
k bezpečnostním údaj ům. Testovací za řízení proto musí být pouze 
schopno inicializovat komunikaci DSRC (odeslání BST s AID = 2) 
a potom odeslat p říkaz ECHO a v p řípadě, že DSRC pracuje, p řijmout 
odezvu ECHO. Podrobnosti viz 5.4.8. V p řípadě, že tuto odezvu p řijme 
správně, může být spojení DSRC ( DSRC-REDCR  >>-:-< 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ího 
toku dat. Pro tento test je nutná testovací čtečka DSRC. 
Tato čtečka provádí stejné funkce a je realizována se stejnými 
specifikacemi jako čtečka používaná oprávn ěnými osobami 
s tím rozdílem, že karta dílny je používána pro ov ěření totož­
nosti uživatele testovací čtečky DSRC, nikoli kontrolní karty. 
Test lze provád ět po počáteční aktivaci inteligentního tacho ­
grafu nebo na konci kalibra čního postupu. Po aktivaci celek 
ve vozidle generuje zabezpe čená data v časné detekce a sd ělí 
je zařízení dálkové komunikace.  
DSC_86 Pracovníci dílny musí testovací čtečku DSRC umístit ve vzdá ­
lenosti 2 až 10 metr ů před vozidlem.  
DSC_87 Potom pracovníci dílny vloží do testovací čtečky DSRC kartu 
dílny a odešlou požadavek na zjišt ění dat včasné detekce do 
celku ve vozidle. Po úsp ěšném zjištění pracovníci dílny p řijatá 
data zkontrolují, aby se p řesvědčili, že byla úsp ěšně valido­
vána z hlediska integrity a dešifrována.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 534  
Dodatek 15  
MIGRACE: POSTUPY P ŘI SOUČASNÉ EXISTENCI N ĚKOLIKA 
GENERACÍ ZA ŘÍZENÍ  
OBSAH  
1. DEFINICE  
2. OBECNÁ USTANOVENÍ  
2.1. P řechod na novou generaci  
2.2. Interoperabilita mezi celky ve vozidle a kartami  
2.3. Interoperabilita mezi celky ve vozidle a sníma či pohybu  
2.4. Interoperabilita mezi celky ve vozidle, kartami tachografu 
a zařízením pro stahování dat  
2.4.1 P římé stahování z karet prost řednictvím inteligentního 
vyhrazeného za řízení (IDE)  
2.4.2 Stahování z karet prost řednictvím celku ve vozidle  
2.4.3 Stahování z celku ve vozidle  
2.5. Interoperabilita mezi celkem ve vozidle a kalibra čním 
zařízením  
3. HLAVNÍ KROKY V OBDOBÍ P ŘED DATEM 
ZAVEDENÍ  
4. USTANOVENÍ PRO OBDOBÍ PO DATU ZAVEDENÍ  
1. DEFINICE  
Pro účely tohoto dodatku se použijí tyto definice:  
systém inteligentního tachografu : podle definice v této p říloze (kapi ­
tola 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.  
2. OBECNÁ USTANOVENÍ  
2.1. Přechod na novou generaci  
V preambuli této p řílohy je uveden p řehled o p řechodu z první na 
druhou generaci systém ů tachografů. 
Kromě ustanovení této preambule:  
— snímače pohybu první generace nebudou interoperabilní s celky ve 
vozidle druhé generace,  
— instalace sníma čů pohybu druhé generace do vozidel bude zahájena 
současně s instalací celk ů ve vozidle druhé generace,  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 535  
— bude nutný další vývoj za řízení pro stahování dat a kalibra ční 
zařízení, aby bylo podporováno používání obou generací záznamo ­
vého zařízení a karet tachografu.  
2.2. Interoperabilita mezi celky ve vozidle a kartami  
▼M1 
Rozumí se, že karty tachografu první generace jsou interoperabilní 
s celky ve vozidle první generace v souladu s p řílohou IB na řízení 
(EHS) č. 3821/85, zatímco karty tachografu druhé generace jsou intero ­
perabilní s celky ve vozidle druhé generace v souladu s p řílohou IC 
tohoto nařízení. Krom ě toho se uplatní níže uvedené požadavky.  
▼B 
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 vozidle druhé generace až 
do uplynutí jejich data platnosti. Jejich držitelé však mohou 
požádat o jejich vým ěnu za karty tachografu druhé generace, 
jakmile budou k dispozici.  
MIG_002 Celky ve vozidle druhé generace musí být schopny 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 tachografu první 
generace nemohou být již dále p řijímány. To lze provést 
pouze poté, co Evropská komise zahájí postup, jehož cílem 
je dílny požádat, aby tak u činily, např. během každé peri ­
odické kontroly tachografu.  
MIG_004 Celky ve vozidle druhé generace musí být schopny používat 
pouze karty dílny druhé generace.  
MIG_005 Pro ur čení provozního režimu musí celky ve vozidle druhé 
generace p řihlížet pouze k typ ům platných vložených karet 
bez ohledu na jejich generace.  
MIG_006 Jakoukoli platnou kartu 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é gene ­
race jsou interoperabilní s druhou generací celk ů ve vozidle. Krom ě toho 
se uplatní níže uvedené požadavky.  
MIG_007 Celky ve vozidle druhé generace nebudou moci být spáro ­
vány a používány se sníma či pohybu první generace.  
MIG_008 Sníma če pohybu druhé generace mohou být spárovány 
a používány pouze s celky ve vozidle 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 lze používat pouze s jednou gene ­
rací celků ve vozidle a karet tachografu, nebo s ob ěma. ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 536  
2.4.1  Přímé stahování z karet prost řednictvím inteligentního vyhrazeného 
zařízení (IDE)  
MIG_010 Data se musí z karet tachografu jedné generace vložených do 
čtečky karet stahovat pomocí IDE s použitím bezpe čnostních 
mechanism ů a protokolu pro stahování dat této generace 
a stahovaná data musí být ve formátu definovaném pro 
tuto generaci.  
MIG_011 Aby se umožnila kontrola řidičů kontrolními orgány, které 
nepatří do EU, musí být rovn ěž umožněno stahování dat 
z karty řidiče (a karty dílny) druhé generace naprosto 
stejným zp ůsobem jako z karty řidiče (a karty dílny) první 
generace. Uvedené stahování musí zahrnovat:  
▼M1 
— nepodepsané elementární soubory EF ic a icc (volitelné),  
▼B 
— nepodepsané elementární soubory (EF) (první generace)
  
a
 ,  
▼M1 
— 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) druhé generace (elementární soubory 
EF s aplika čními daty v rámci souboru DF Tachograph_G2).  
▼B 
2.4.2  Stahování z karet prost řednictvím celku ve vozidle  
MIG_012 Data se musí stahovat z karty druhé generace vložené do 
celku ve vozidle první generace pomocí protokolu pro staho ­
vá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 druhé generace pomocí protokolu pro staho ­
vání dat definovaného v dodatku 7 této p řílohy. Celek ve 
vozidle musí vysílat p říkazy do karty naprosto stejným 
způsobem jako celek ve vozidle první generace a stahovaná 
data musí respektovat formát definovaný pro karty první 
generace.  
2.4.3  Stahování z celku ve vozidle  
▼M1 
MIG_014 Nad rámec kontroly řidičů kontrolními orgány, které nepat ří 
do EU, se data musí stahovat z celk ů ve vozidle druhé 
generace pomocí bezpe čnostních mechanism ů druhé gene ­
race a protokolu pro stahování dat specifikovaného v dodatku 
7 této přílohy.  
MIG_015 Aby se umožnila kontrola řidičů kontrolními orgány, které 
nepatří do EU, lze také p řípadně umožnit stahování dat 
z celků ve vozidle 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.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 537  
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í tachografu pomocí kalibra čního protokolu 
příslušné generace. Kalibra ční zařízení lze použít pouze 
s jednou generací tachografu, nebo s ob ěma. 
3. HLAVNÍ KROKY V OBDOBÍ P ŘED DATEM ZAVEDENÍ  
MIG_017 Testovací klí če a certifikáty musí být výrobc ům k dispozici 
nejpozději 30 měsíců před datem zavedení.  
MIG_018 Zkoušky interoperability musí být p řipraveny k zahájení, 
jestliže o to výrobci požádají, nejpozd ěji 15 měsíců před 
datem zavedení.  
MIG_019 Oficiální klí če a certifikáty musí být výrobc ům k dispozici 
nejpozději 12 měsíců před datem zavedení.  
MIG_020 Členské státy musí být schopny vydávat karty dílny druhé 
generace nejpozd ěji 3 měsíce před datem zavedení.  
MIG_021 Členské státy musí být schopny vydávat všechny typy karet 
tachografu 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 druhé generace.  
MIG_023 Výrobci celk ů ve vozidle / sníma čů pohybu budou sm ět 
vyrábět celky ve vozidle / sníma če pohybu první generace, 
dokud budou používány v praxi, aby mohly být vym ěňovány 
vadné součásti. 
MIG_024 Výrobci celk ů ve vozidle / sníma čů pohybu budou sm ět 
požadovat a obdržet zachování schválení typu celk ů ve 
vozidle / sníma čů pohybu první generace, které již byly 
typově schváleny.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 538  
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 ADAP ­ 
TÉRU  
2.1. Všeobecný popis adaptéru  
2.2. Funkce  
2.3. Zabezpe čení 
3. POŽADAVKY NA ZÁZNAMOVÉ ZA ŘÍZENÍ U NAMON ­ 
TOVANÉHO ADAPTÉRU  
4. KONSTRUK ČNÍ A FUNK ČNÍ POŽADAVKY NA 
ADAPTÉR  
4.1. Propojení a p řizpůsobení přicházejících impuls ů rychlosti  
4.2. Indukce p řicházejících impuls ů do zabudovaného sníma če 
pohybu  
4.3. Zabudovaný sníma č pohybu  
4.4. Bezpe čnostní požadavky  
4.5. Provozní charakteristiky  
4.6. Materiály  
4.7. Zna čení 
5. MONTÁŽ ZÁZNAMOVÉHO ZA ŘÍZENÍ PŘI POUŽITÍ 
ADAPTÉRU  
5.1. Montáž  
5.2. Plomby  
6. KONTROLY, PROHLÍDKY A OPRAVY  
6.1. Periodické prohlídky  
7. SCHVÁLENÍ TYPU ZÁZNAMOVÉHO ZA ŘÍZENÍ PŘI 
POUŽITÍ ADAPTÉRU  
7.1. Všeobecn ě 
7.2. Osv ědčení o funk čnosti  
1. ZKRATKY A REFEREN ČNÍ DOKUMENTY  
1.1. Zkratky  
TBD bude stanoveno pozd ěji 
VU celek ve vozidle ( Vehicle Unit ) 
1.2. Referen ční normy  
ISO16844-3 Road vehicles – Tachograph systems – Part 3: Motion sensor 
interface (Silni ční vozidla – Systémy tachografu – Část 3: Rozhraní 
snímače pohybu  
2. VŠEOBECNÉ CHARAKTERISTIKY A FUNKCE ADAPTÉRU  
2.1. Všeobecný popis adaptéru  
ADA_001 Adaptér dodává p řipojenému celku ve vozidle (VU) zabezpe ­ 
čené údaje o pohybu vozidla trvale odpovídající rychlosti 
vozidla a vzdálenosti ujeté vozidlem.  
Adaptér je ur čen pouze pro vozidla, která musí být vybavena 
záznamovým za řízením v souladu s tímto na řízením.  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 539  
Musí být namontován a používán pouze u typ ů vozidel 
vymezených v definici yy) „adaptér“ p řílohy IC, u kterých 
není mechanicky možné namontovat jiný typ existujícího 
snímače pohybu, který je jinak v souladu s ustanoveními této 
přílohy a dodatk ů 1 až 16.  
Adaptér nesmí být mechanicky propojen s pohyblivou částí 
vozidla, ale je napojen na impulsy rychlosti/vzdálenosti, které 
jsou generovány integrovanými sníma či nebo alternativními 
rozhraními.  
ADA_002 Sníma č pohybu schváleného typu (podle ustanovení této 
přílohy IC oddílu 8, Schválení typu záznamového za řízení 
a karet tachografu) musí být umíst ěn do skříně adaptéru, 
která musí obsahovat také za řízení na převod impuls ů induku­
jící přicházející impulsy do zabudovaného sníma če pohybu. 
Vlastní zabudovaný sníma č pohybu musí být propojen s celkem 
ve vozidle tak, aby rozhraní mezi celkem ve vozidle a adap ­
térem bylo v souladu s požadavky normy ISO 16844-3.  
2.2. Funkce  
ADA_003 Adaptér musí zajiš ťovat tyto funkce:  
— propojení a p řizpůsobování p říchozích impuls ů rychlosti,  
— indukci p řicházejících impuls ů do zabudovaného sníma če 
rychlosti,  
— všechny funkce zabudovaného sníma če pohybu dodávající 
zabezpečené údaje o pohybu vozidla do celku ve vozidle.  
2.3. Zabezpe čení 
ADA_004 Zabezpe čení systému adaptéru není certifikováno na základ ě 
všeobecného bezpe čnostního cíle pro sníma če pohybu defino ­
vaného v dodatku 10 této p řílohy. Namísto toho se použijí 
požadavky na zabezpe čení specifikované v oddíle 4.4 tohoto 
dodatku.  
3. POŽADAVKY NA ZÁZNAMOVÉ ZA ŘÍZENÍ U NAMONTOVANÉHO 
ADAPTÉRU  
Požadavky uvedené v následujících kapitolách udávají, jak je t řeba 
rozumět požadavk ům v této p říloze, je-li použit adaptér. P říslušná čísla 
požadavků přílohy IC jsou uvedena v závorkách.  
ADA_005 Záznamové za řízení každého vozidla vybaveného adaptérem 
musí být v souladu se všemi ustanoveními této p řílohy 
kromě případů, kdy je v tomto dodatku uvedeno jinak.  
ADA_006 Je-li namontován adaptér, záznamové za řízení zahrnuje kabely, 
adaptér (včetně snímače pohybu) a celek ve vozidle [01].  
ADA_007 Funkce detekce událostí a/nebo závad záznamového za řízení se 
pozměňuje takto:  
— událost „p řerušení elektrického napájení“ aktivuje celek ve 
vozidle, pokud za řízení není v kalibra čním režimu, p ři 
každém p řerušení elektrického napájení zabudovaného 
snímače pohybu delším než 200 milisekund [79],  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 540  
— událost „chybné údaje o pohybu vozidla“ aktivuje celek ve 
vozidle při přerušení normálního toku dat mezi zabudo ­
vaným sníma čem pohybu a celkem ve vozidle a/nebo 
v případě chyby integrity nebo ov ěření pravosti dat 
přenášených mezi zabudovaným sníma čem pohybu 
a celkem ve vozidle [83],  
— událost „pokus o narušení zabezpe čení“ aktivuje celek ve 
vozidle v jakémkoli jiném p řípadě, který ohrožuje zabez ­
pečení zabudovaného sníma če pohybu, pokud za řízení není 
v kalibračním režimu [85],  
— chybu „záznamového za řízení“ aktivuje celek ve vozidle, 
pokud zařízení není v kalibra čním režimu, v p řípadě jaké­
koliv závady na zabudovaném sníma či pohybu [88].  
ADA_008 Závady adaptéru zjistitelné záznamovým za řízením jsou závady 
související se zabudovaným sníma čem pohybu [88].  
ADA_009 Kalibra ční funkce celku ve vozidle musí umožnit automatické 
spárování zabudovaného sníma če pohybu a celku ve vozidle 
[202, 204].  
4. KONSTRUK ČNÍ A FUNK ČNÍ POŽADAVKY NA ADAPTÉR  
4.1. Propojení a p řizpůsobení přicházejících impuls ů rychlosti  
ADA_011 Vstupní rozhraní adaptéru musí p řijímat frekven ční impulsy 
odpovídající rychlosti vozidla a vzdálenosti ujeté vozidlem. 
Elektrické charakteristiky p řicházejících impuls ů jsou:  definuje 
výrobce . Úpravy p řístupné pouze výrobci adaptéru a schválené 
dílně provádějící montáž adaptéru musí v p říslušných p řípa­
dech umožnit správné propojení vstupu adaptéru s vozidlem.  
ADA_012 Vstupní rozhraní adaptéru musí být v p říslušných p řípadech 
schopné násobit nebo d ělit frekvenci p řicházejících impuls ů 
rychlosti pevn ě stanoveným faktorem pro p řizpůsobení signálu 
rozsahu faktoru k definovanému v této p říloze (4 000 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.  
4.2. Indukce p řicházejících impuls ů do zabudovaného sníma če pohybu  
ADA_013 P řicházející impulsy, p řípadně přizpůsobené výše uvedeným 
způsobem, musí být indukovány do zabudovaného sníma če 
pohybu tak, aby každý p řicházející impuls byl sníma čem 
pohybu detekován.  
4.3. Zabudovaný sníma č pohybu  
ADA_014 Zabudovaný sníma č pohybu musí být stimulován indukova ­
nými impulsy, což mu umožní generovat údaje o pohybu 
vozidla přesně odpovídající pohybu vozidla, jako by byl 
mechanicky propojen s pohyblivou částí vozidla.  
ADA_015 K identifikaci adaptéru využívá celek ve vozidle identifika ční 
data zabudovaného sníma če pohybu [95].  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 541  
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í kontro ­
lou, viz ADA_035). Plomby musí spl ňovat stejné požadavky 
jako plomby na sníma čích pohybu [398 až 406].  
ADA_018 Nesmí být možné odstranit zabudovaný sníma č pohybu z adap ­
téru bez porušení plomby (plomb) sk říně adaptéru nebo poru ­ 
šení plomby mezi sníma čem a skříní adaptéru (viz ADA_034).  
ADA_019 Adaptér musí zajistit, aby údaje o pohybu vozidla mohly být 
zpracovávány a odvozovány pouze ze vstupu adaptéru.  
4.5. Provozní charakteristiky  
ADA_020 Adaptér musí být pln ě provozuschopný v rozsahu teplot defi ­
novaném výrobcem.  
ADA_021 Adaptér musí být pln ě provozuschopný v rozsahu vlhkostí od 
10 % do 90 % [214].  
ADA_022 Adaptér musí být chrán ěn proti přepětí, záměně polarity napá ­
jecího nap ětí a zkratu [216].  
ADA_023 Adaptér musí bu ď: 
— reagovat na magnetické pole, které ruší detekci pohybu 
vozidla; za takových okolností celek ve vozidle zaznamená 
a uloží závadu sníma če [88]; nebo  
— musí mít snímací prvek, který je chrán ěn proti magne ­
tickým polím, p řípadně je vůči jejich p ůsobení imunní 
[217].  
ADA_024 Adaptér musí odpovídat mezinárodnímu p ředpisu EHK OSN 
R10, vztahujícímu se k elektromagnetické kompatibilit ě, 
a musí být chrán ěn proti elektrostatickým výboj ům a přecho­
dovým jev ům [218].  
4.6. Materiály  
ADA_025 Adaptér musí spl ňovat stupe ň ochrany ( definují výrobci 
v závislosti na montážní poloze ) [220, 221].  
ADA_026 Barva sk říně adaptéru je žlutá.  
4.7. Značení 
ADA_027 K adaptéru musí být p řipevněn popisný štítek, který obsahuje 
tyto údaje:  
— název a adresu výrobce adaptéru,  
— katalogové číslo adaptéru podle výrobce a rok jeho výroby,  
— značku schválení typu adaptéru nebo záznamového za řízení 
zahrnujícího adaptér,  
— datum montáže adaptéru,  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 542  
— identifika ční číslo vozidla, do n ěhož byl namontován.  
ADA_028 Popisný štítek dále obsahuje tyto údaje (pokud je není možno 
přímo přečíst na vnější straně zabudovaného sníma če pohybu):  
— název výrobce zabudovaného sníma če pohybu,  
— katalogové číslo zabudovaného sníma če pohybu podle 
výrobce a rok jeho výroby,  
— značka schválení typu zabudovaného sníma če pohybu.  
5. MONTÁŽ ZÁZNAMOVÉHO ZA ŘÍZENÍ PŘI POUŽITÍ ADAPTÉRU  
5.1. Montáž  
ADA_029 Adaptéry musí být do vozidel montovány pouze výrobci 
vozidel nebo schválenými dílnami oprávn ěnými k montáži, 
aktivaci a kalibraci digitálních a inteligentních tachograf ů. 
ADA_030 Schválená dílna provád ějící montáž adaptéru musí se řídit 
vstupní rozhraní a zvolit d ělicí poměr vstupního signálu (v 
příslušných p řípadech).  
ADA_031 Schválená dílna provád ějící montáž adaptéru musí sk říň adap­
téru zaplombovat.  
ADA_032 Adaptér musí být namontován co možná nejblíže té části 
vozidla, která zajiš ťuje přicházející impulsy.  
ADA_033 Kabely pro p řívod energie do adaptéru musí být červené 
(kladný pól) a černé (uzemn ění). 
5.2. Plomby  
ADA_034 Platí tyto požadavky na plombování:  
— skříň adaptéru musí být zaplombovaná (viz ADA_017),  
— jestliže je možné odstranit zabudovaný sníma č ze skříně 
adaptéru bez poškození plomby (plomb) sk říně adaptéru, 
musí být sk říň zabudovaného sníma če plombou spojena 
se skříní adaptéru (viz ADA_018),  
— skříň adaptéru musí být plombou spojena s vozidlem,  
— propojení adaptéru a za řízení, které zajiš ťuje přicházející 
impulsy, musí být zaplombováno na obou koncích (pokud 
je to přiměřeně možné).  
6. KONTROLY, PROHLÍDKY A OPRAVY  
6.1. Periodické prohlídky  
ADA_035 P ři použití adaptéru musí každá pravidelná prohlídka (pravi ­
delnou prohlídkou se rozumí prohlídka v souladu s požadavky 
[409] až [413] p řílohy 1C) záznamového za řízení zahrnovat 
kontroly, zda:  
— adaptér nese správnou zna čku schválení typu,  
— plomby na adaptéru a jeho p řipojeních jsou neporušené,  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 543  
— adaptér je namontován tak, jak je uvedeno na montážním 
štítku,  
— adaptér je namontován podle pokyn ů výrobce adaptéru 
a/nebo vozidla,  
— montáž adaptéru je pro kontrolované vozidlo schválená.  
ADA_036 Tyto prohlídky musí zahrnovat kalibraci a vým ěnu všech 
plomb bez ohledu na jejich stav.  
7. SCHVÁLENÍ TYPU ZÁZNAMOVÉHO ZA ŘÍZENÍ PŘI POUŽITÍ 
ADAPTÉRU  
7.1. Všeobecn ě 
ADA_037 Záznamové za řízení musí být p ředloženo ke schválení typu 
úplné, včetně adaptéru [425].  
ADA_038 Každý adaptér m ůže být předložen ke schválení typu samo ­
statně nebo jako sou část záznamového za řízení.  
ADA_039 Uvedené schválení typu musí zahrnovat funk ční zkoušky 
zahrnující adaptér. Kladné výsledky každé z t ěchto zkoušek 
jsou uvedeny v p říslušném osv ědčení [426].  
7.2. Osvědčení o funk čnosti  
ADA_040 Osv ědčení o funk čnosti adaptéru nebo záznamového za řízení 
zahrnujícího adaptér musí být výrobci adaptéru doru čeno až po 
úspěšném absolvování všech funk čních zkoušek v tomto mini ­
málním rozsahu.  
Č. Zkouška  Popis  Související požadavky  
1. Administrativní šet ření 
1.1 Dokumentace  Správnost dokumen ­
tace adaptéru  
2. Vizuální kontrola  
2.1. Shoda adaptéru s dokumentací  
2.2. Identifikace/zna čení adaptéru  ADA_027, 
ADA_028  
2.3 Materiály použité v adaptéru  [219] až [223] 
ADA_026  
2.4. Plomby  ADA_017, 
ADA_018, 
ADA_034  
3. Funk ční zkoušky  
3.1 Indukce impuls ů rychlosti do zabudovaného 
snímače pohybu  ADA_013  ▼B
 02016R0799 — CS — 26.02.2020 — 002.001 — 544  
Č. 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 — 26.02.2020 — 002.001 — 545  
PŘÍLOHA II  
ZNAČKA SCHVÁLENÍ A OSV ĚDČENÍ 
I. ZNAČKA SCHVÁLENÍ  
1. Značka schválení sestává:  
a) z obdélníku, ve kterém je písmeno „e“ a rozlišovací číslo, nebo písmena 
země, která udělila schválení, v souladu s t ěmito dohodnutými zna čkami: 
Belgie  6,  
Bulharsko  34,  
Česká republika  8,  
Dánsko  18,  
Německo  1,  
Estonsko  29,  
Irsko  24,  
Řecko  23,  
Španělsko 9,  
Francie  2,  
Chorvatsko  25,  
Itálie  3,  
Kypr  CY,  
Lotyšsko  32,  
Litva  36,  
Lucembursko  13,  
Maďarsko  7,  
Malta  MT,  
Nizozemsko  4,  
Rakousko  12,  
Polsko  20,  
Portugalsko  21,  
Rumunsko  19,  
Slovinsko  26,  
Slovensko  27,  
Finsko  17,  
Švédsko  5,  
Spojené království  11,  
a 
▼M1 
b) z čísla schválení, které odpovídá číslu osvědčení o schválení vystaveného 
pro prototyp záznamového za řízení nebo záznamového listu nebo karty 
tachografu a které se umístí kdekoli v bezprost řední blízkosti obdélníku.  ▼C1
 02016R0799 — CS — 26.02.2020 — 002.001 — 546  
2. Značka schválení musí být p řipojena na popisný štítek každého souboru 
zařízení, na každý záznamový list a na každou kartu tachografu. Musí být 
nesmazatelná 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 — 26.02.2020 — 002.001 — 547  
II. OSVĚDČENÍ O SCHVÁLENÍ ANALOGOVÝCH TACHOGRAF Ů 
Členský stát, který ud ělil schválení, vystaví žadateli osv ědčení o schválení podle 
níže uvedeného vzoru. Pro informování ostatních členských stát ů o vydaných 
nebo případně odebraných schváleních používají členské státy toto osv ědčení. 
OSVĚDČENÍ O SCHVÁLENÍ  
Název příslušného správního orgánu  
Sdělení týkající se (  1 ): 
— schválení typu záznamového za řízení  
— odebrání schválení typu záznamového za řízení  
— schválení vzoru záznamového listu  
— odebrání schválení vzoru záznamového listu  
Schválení č.: 
...................................  
1. Výrobní nebo obchodní zna čka 
2. Označení typu nebo modelu  
3. Jméno výrobce  
4. Adresa výrobce  
5. Předloženo ke schválení dne  
6. Zkušební laborato ř(e) 
7. Datum a číslo zkoušky/zkoušek  
8. Datum schválení  
9. Datum odebrání schválení  
10. Typ/typy záznamového za řízení, s nímž/s nimiž má být záznamový list 
používán  
11. Místo  
12. Datum  
13. Přiložená dokumentace  
14. Poznámky (v četně umístění případných plomb)  
(Podpis)  ▼C1 
( 1 ) Nehodící se škrtn ěte.
 02016R0799 — CS — 26.02.2020 — 002.001 — 548  
III. OSVĚDČENÍ O SCHVÁLENÍ DIGITÁLNÍCH TACHOGRAF Ů 
Členský stát, který ud ělil schválení, vystaví žadateli osv ědčení o schválení podle 
níže uvedeného vzoru. Pro informování ostatních členských stát ů o vydaných 
nebo případně odebraných schváleních používají členské státy toto osv ědčení. 
OSVĚDČENÍ O SCHVÁLENÍ DIGITÁLNÍCH TACHOGRAF Ů 
Název příslušného správního orgánu  
Sdělení týkající se (  1 ): 
□ schválení:  □ odebrání schválení:  
□ modelu záznamového za řízení 
□ části záznamového za řízení (  2 ) 
□ karty řidiče 
□ karty dílny  
□ karty podniku  
□ karty kontrolora  
Schválení č.: 
1. Výrobní nebo obchodní zna čka 
2. Označení modelu  
3. Jméno výrobce  
4. Adresa výrobce  
▼M1 
5. Předloženo k schválení dne  
▼C1 
6. Zkušební laborato ř(e) 
7. Datum a číslo zkušebního protokolu  
8. Datum schválení  
9. Datum odebrání schválení  
10. Vzor záznamového/záznamových za řízení, s nímž/s nimiž má být část použí­
vána  
11. Místo  
12. Datum  
13. Přiložená dokumentace  
14. Poznámky (v četně umístění případných plomb)  
(Podpis)  ▼C1 
( 1 ) Označte příslušná okénka. 
( 2 ) Uveďte část, jíž se oznámení týká.
 02016R0799 — CS — 26.02.2020 — 002.001 — 549  
IV. OSVĚDČENÍ O SCHVÁLENÍ INTELIGENTNÍCH TACHOGRAF Ů 
Členský stát, který ud ělil schválení, vystaví žadateli osv ědčení o schválení podle 
níže uvedeného vzoru. Pro informování ostatních členských stát ů o vydaných 
nebo případně odebraných schváleních používají členské státy toto osv ědčení. 
OSVĚDČENÍ O SCHVÁLENÍ INTELIGENTNÍCH TACHOGRAF Ů 
Název příslušného správního orgánu  
Sdělení týkající se (  1 ): 
□ schválení:  □ odebrání schválení:  
□ modelu záznamového za řízení 
□ části záznamového za řízení (  2 ) 
□ karty řidiče 
□ karty dílny  
□ karty podniku  
□ karty kontrolora  
Schválení č.: 
1. Výrobní nebo obchodní zna čka 
2. Označení modelu  
3. Jméno výrobce  
4. Adresa výrobce  
▼M1 
5. Předloženo k schválení dne  
▼C1 
6. a) Zkušební laborato ř pro udělování osv ědčení o funk čnosti  
b) Zkušební laborato ř pro udělování osv ědčení o bezpe čnosti  
c) Zkušební laborato ř pro udělování osv ědčení o interoperabilit ě 
7. a) Datum a číslo osvědčení o funk čnosti  
b) Datum a číslo osvědčení o bezpe čnosti  
c) Datum a číslo osvědčení o interoperabilit ě 
8. Datum schválení  
9. Datum odebrání schválení  
10. Vzor záznamového/záznamových za řízení, s nímž/s nimiž má být část použí­
vána  
11. Místo  
12. Datum  
13. Přiložená dokumentace  
14. Poznámky (v četně umístění případných plomb)  
(Podpis)  ▼C1 
( 1 ) Označte příslušná okénka. 
( 2 ) Uveďte část, jíž se oznámení týká.