Denne tekst tjener udelukkende som dokumentationsværktøj og har ingen retsvirkning. EU's institutioner påtager sig intet 
ansvar for dens indhold. De autentiske udgaver af de relevante retsakter, inklusive deres betragtninger, er offentliggjort i de n 
Europæiske Unions Tidende og kan findes i EUR-Lex. Disse officielle tekster er tilgængelige direkte via linkene i dette 
dokument  
►B KOMMISSIONENS GENNEMFØRELSESFORORDNI NG (EU) 2016/799  
af 18. marts 2016  
om gennemførelse af Europa-Parlamentets og Rådets forordning (EU) nr. 165/2014 om fastsættelse 
af forskrifter for konstruktion, afprøvning, installering, brug og reparation af takografer og deres 
komponenter  
(EØS-relevant tekst)  
(EUT L 139 af 26.5.2016, s. 1)  
Ændret ved:  
Tidende  
nr. side  dato  
►M1 Kommissionens gennemførelsesforordning (EU) 2018/502 af 
28. februar 2018  L 85  1  28.3.2018  
►M2 Kommissionens gennemførelsesforordning (EU) 2020/158 af 5. feb ruar 
2020  L 34  2 0  6.2.2020  
►M3 Kommissionens gennemførelsesforordning (EU) 2021/1228 af 16. j uli 
2021  L 273  1  30.7.2021  
Berigtiget ved:  
►C1 Berigtigelse, EUT L 146 af 3.6.2016, s. 31 (2016/799)  
►C2 Berigtigelse, EUT L 27 af 1.2.2017, s. 169 (2016/799)  
►C3 Berigtigelse, EUT L 166 af 29.6.2017, s. 82 (2016/799)  02016R0799 — DA — 21.08.2023 — 003.001 — 1
02016R0799 — DA — 21.08.2023 — 003.001 — 2  
KOMMISSIONENS GENNEMFØRELSESFORORDNING (EU) 
2016/799  
af 18. marts 2016  
om gennemførelse af Europa-Parlamentets og Rådets forordning (EU) 
nr. 165/2014 om fastsættelse af forskrifter for konstruktion, afprøvning, 
installering, brug og reparation af takografer og deres komponenter  
(EØS-relevant tekst)  
Artikel 1  
Genstand og anvendelsesområde  
1. I denne forordning fastsættes de nødvendige bestemmelser for  en 
ensartet anvendelse af følgende aspekter vedrørende takografer:  
a) registrering af køretøjets position på visse punkter i løbet  af førerens 
daglige arbejdsperiode  
b) tidlig fjernafsløring af mulig manipulation eller misbrug af  intel­
ligente takografer  
c) interface med intelligente transportsystemer  
d) de administrative og tekniske krav til typegodkendelsesproce durerne 
for takografer, herunder sikkerhedsmekanismerne.  
▼M1 
2. Konstruktion, afprøvning, installering, eftersyn, brug og re paration 
af intelligente takografer og deres komponenter skal ske i henh old til de 
tekniske krav i bilag I C til denne forordning.  
3. Andre takografer end intelligente takografer skal, for så vidt  angår 
konstruktion, afprøvning, installering, eftersyn, brug og repar ation, fortsat 
overholde kravene i enten bilag I til forordning (EU) nr. 165/2 014 eller 
bilag I B til Rådets forordning (EØF) nr. 3821/85 (  1 ), alt efter hvad der er 
relevant.  
▼B 
4. I henhold til artikel 10d i direktiv 96/53/EF skal udstyret til tidlig 
fjernafsløring ligeledes transmittere vægtdata fra et internt v ejesystem i 
lastbilerne med henblik på tidlig fjernafsløring af svig.  
▼M1 
5. Denne forordning berører ikke Europa-Parlamentets og Rådets 
direktiv 2014/53/EU (  2 ). 
▼B 
Artikel 2  
Definitioner  
I denne forordning anvendes definitionerne i artikel 2 i forord ning (EU) 
nr. 165/2014.  ▼B 
( 1 ) Rådets forordning (EØF) nr. 3821/85 af 20. december 1985 om k ontrolappa­
ratet inden for vejtransport (EFT L 370 af 31.12.1985, s. 8). 
( 2 ) Europa-Parlamentets og Rådets direktiv 2014/53/EU af 16. apri l 2014 om 
harmonisering af medlemsstaternes love om tilgængeliggørelse af  radioudstyr 
på markedet og om ophævelse af direktiv 1999/5/EF (EUT L 153 af  
22.5.2014, s. 62).
 02016R0799 — DA — 21.08.2023 — 003.001 — 3  
Desuden forstås ved:  
1) »digital takograf« eller »takograf af første generation«: di gital tako­
graf, som ikke er en intelligent takograf  
2) »eksternt GNSS-udstyr«: udstyr, der indeholder GNSS-modtager en, 
når køretøjsenheden ikke er en enkelt enhed, samt andre kompo­
nenter, der er nødvendige for at beskytte transmission af posit ions­
data til resten af køretøjsenheden  
▼M1 
3) »informationsmappe«: hele mappen, i elektronisk form eller p apir­
form, der indeholder alle oplysninger, som fabrikanten eller de nnes 
repræsentant har indgivet til typegodkendelsesmyndigheden med 
henblik på typegodkendelse af en takograf eller en komponent 
dertil, inklusive de i artikel 12, stk. 3, i forordning (EU) 
nr. 165/2014 nævnte certifikater, resultaterne af de prøvninger , 
der defineres i bilag I C til denne forordning samt tegninger, foto­
grafier og andre relevante dokumenter  
▼B 
4) »informationspakke«: informationsmappen i elektronisk form e ller 
papirform, ledsaget af alle andre dokumenter, som typegodkendel ­
sesmyndigheden har tilføjet til informationsmappen i forbindels e 
med udøvelsen af sine funktioner, herunder ved afslutningen af 
typegodkendelsesprocessen, EC-typegodkendelsesattesten for tako ­
grafen eller en komponent i denne  
5) »indeks til informationspakken«: dokument med en nummereret 
liste over indholdet i informationspakken, hvori alle de releva nte 
dele af denne pakke identificeres. Formatet af dette dokument s kal 
skelne mellem de forskellige trin i EC-typegodkendelsesprocesse n, 
herunder datoer for eventuelle revisioner og ajourføringer af p akken  
6) »udstyr til tidlig fjernafsløring«: udstyr i køretøjsenheden , der 
anvendes til at udføre målrettede vejkontroller  
▼M1 
7) »intelligent takograf« eller »takograf af anden generation«:  digital 
takograf, der er i overensstemmelse med artikel 8, 9 og 10 i fo rord­
ning (EU) nr. 165/2014 samt med bilag I C til nærværende forord ­
ning 
8) »takografkomponent« eller »komponent«: ethvert af følgende 
elementer: køretøjsenheden, bevægelsessensoren, diagramarket, d et 
eksterne GNSS-udstyr og det eksterne udstyr til tidlig fjernafs løring  
▼B 
9) »typegodkendelsesmyndighed«: myndighed i en medlemsstat, der  
er kompetent til at foretage typegodkendelse af takografen elle r af 
dennes komponenter, godkendelsesprocessen, udstedelse og i give t 
fald tilbagekaldelse af typegodkendelsesattester, at fungere so m 
kontaktpunkt for typegodkendelsesmyndigheder i andre medlems­
stater og at sikre, at fabrikanterne opfylder deres forpligtels er 
vedrørende overholdelsen af kravene i denne forordning  
▼M1 
10) »køretøjsenhed«: takograf bortset fra bevægelsessensoren og  de 
kabler, hvormed bevægelsessensoren tilsluttes.  
Køretøjsenheden kan enten være en enkelt enhed eller flere 
enheder, som er fordelt i køretøjet, og omfatter bl.a. en proce ssor, 
et datalager, en tidsmålefunktion, to intelligente kortlæserenh eder ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 4  
til fører og medfører, en printer, en skærm, stik samt facilite ter til 
indlæsning af brugerens data, en GNSS-modtager og fjernkommu­
nikationsudstyr.  
Køretøjsenheden kan være sammensat af følgende komponenter, 
der er underlagt typegodkendelse:  
— en køretøjsenhed, som består af en enkelt komponent (med 
GNSS-modtager og fjernkommunikationsudstyr)  
— en køretøjsenhedshoveddel (med fjernkommunikationsudstyr) 
og eksternt GNSS-udstyr  
— en køretøjsenhedshoveddel (med GNSS-modtager) og eksternt 
fjernkommunikationsudstyr  
— en køretøjsenhedshoveddel, eksternt GNSS-udstyr og eksternt 
fjernkommunikationsudstyr.  
Hvis køretøjsenheden består af flere enheder, som er fordelt i køre­
tøjet, så er køretøjsenhedens hoveddel den enhed, der indeholde r 
processoren, datalageret og tidsmålefunktionen.  
»køretøjsenhed (VU)« anvendes for »køretøjsenhed« eller »køre­
tøjsenhedshoveddel«  
▼B 
Artikel 3  
Lokaliseringsbaserede tjenester  
1. Fabrikanterne sikrer, at intelligente takografer er kompatib le med 
de lokaliseringstjenester, der tilbydes af systemerne Galileo o g den 
europæiske geostationære navigations-overlay-tjeneste (»EGNOS«) . 
2. Ud over de i stk. 1 omtalte systemer kan fabrikanterne også vælge 
at sikre kompatibilitet med andre satellitnavigationssystemer.  
Artikel 4  
Procedure for typegodkendelse af en takograf og takografkomponenter  
1. En fabrikant eller dennes repræsentant indgiver en ansøgning  om 
typegodkendelse af en takograf eller en af dennes komponenter e ller en 
gruppe af komponenter til typegodkendelsesmyndighederne, som 
udpeges af hver medlemsstat. Den skal bestå af en informationsm appe, 
der indeholder oplysninger om hver af de pågældende komponenter , 
herunder i givet fald typegodkendelsesattester for andre kompon enter, 
der er nødvendige for at færdigbygge takografen samt alle andre  rele­
vante dokumenter.  
2. En medlemsstat meddeler typegodkendelse af enhver takograf, 
komponent eller gruppe af komponenter, der er i overensstemmels e 
med de administrative og tekniske krav i artikel 1, stk. 2 elle r 3. I 
dette tilfælde udsteder typegodkendelsesmyndigheden en typegodk en­
delsesattest til ansøgeren, der er i overensstemmelse med model len i 
bilag II til denne forordning.  
3. Typegodkendelsesmyndigheden kan anmode fabrikanten eller 
dennes repræsentant om at indsende eventuelle supplerende oplys ninger.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 5  
4. Fabrikanten eller dennes repræsentant stiller det nødvendige  antal 
takografer eller takografkomponenter til rådighed for typegodke ndelses­
myndighederne og for de organer, der er ansvarlige for at udste de de i 
artikel 12, stk. 3, i forordning (EU) nr. 165/2014 omhandlede a ttester, 
med henblik på at muliggøre en tilfredsstillende afvikling af 
typegodkendelsesproceduren.  
5. Når fabrikanten eller dennes repræsentant søger typegodkende lse 
af bestemte komponenter eller grupper af komponenter i en takog raf, 
skal de stille de øvrige komponenter, som allerede er typegodke ndt, 
samt andre dele, der er nødvendige for konstruktionen af den ko mplette 
takograf til rådighed for typegodkendelsesmyndighederne, sålede s at 
disse myndigheder kan foretage de nødvendige afprøvninger.  
Artikel 5  
Ændringer af typegodkendelser  
1. Fabrikanten eller dennes repræsentant underretter straks de type­
godkendelsesmyndigheder, der har meddelt den oprindelige typego dken­
delse, om eventuelle ændringer i software eller hardware til ta kografen 
eller i arten af materialer brugt til dens fremstilling, der er  registreret i 
informationspakken, og fremsender en ansøgning om ændring af 
typegodkendelsen.  
2. Typegodkendelsesmyndighederne kan revidere eller forlænge de n 
eksisterende typegodkendelse eller udstede en ny typegodkendels e 
afhængigt af ændringernes art og kendetegn.  
Der foretages en »revision«, hvis typegodkendelsesmyndigheden f inder, 
at ændringerne i takografens software eller hardware eller arte n af de 
materialer, der er anvendt til fremstillingen, er uvæsentlige. I så fald 
udsteder typegodkendelsesmyndigheden de reviderede dokumenter i  
informationspakken med angivelse af de foretagne ændringer og 
datoen for deres godkendelse. En ajourført udgave af informatio ns­
pakken i konsolideret form ledsaget af en detaljeret beskrivels e af de 
foretagne ændringer er tilstrækkeligt til at opfylde dette krav . 
En »forlængelse« foretages, hvis typegodkendelsesmyndigheden fi nder, 
at ændringerne i takografens software eller hardware eller arte n af de 
materialer, der er anvendt til fremstillingen, er væsentlige. I  så fald kan 
den anmode om, at der foretages yderligere afprøvninger, og und erretter 
fabrikanten eller dennes repræsentant herom. Hvis disse afprøvn inger er 
tilfredsstillende, udsteder typegodkendelsesmyndigheden en revi deret 
typegodkendelsesattest, hvorpå angives et nummer, der henviser til 
den meddelte forlængelse. På typegodkendelsesattesten angives 
årsagen til forlængelsen og datoen for dens udstedelse.  
3. I indholdsfortegnelsen i informationspakken anføres datoen f or den 
seneste forlængelse eller revision af typegodkendelsen eller da toen for 
den seneste konsolidering af den ajourførte udgave af typegodke ndelsen.  
4. En typegodkendelse er nødvendig, hvis de ønskede ændringer a f 
en typegodkendt takograf eller dens komponenter ville medføre, at der 
udstedes en ny sikkerheds- eller interoperabilitetsattest.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 6  
Artikel 6  
Ikrafttræden  
Denne forordning træder i kraft på tyvendedagen efter offentlig gørelsen 
i Den Europæiske Unions Tidende . 
Den anvendes fra den 2. marts 2016.  
▼M1 
Bilag I C gælder dog fra den 15. juni 2019 med undtagelse af ti llæg 16, 
der anvendes fra den 2. marts 2016.  
▼B 
Denne forordning er bindende i alle enkeltheder og gælder umidd elbart i 
hver medlemsstat.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 7  
BILAG I C  
Forskrifter for konstruktion, afprøvning, montering og eftersyn  
INDLEDNING  
1 DEFINITIONER  
2 KONTROLAPPARATETS GENERELLE EGENSKABER OG 
FUNKTIONER  
2.1 Generelle egenskaber  
2.2 Funktioner  
2.3 Funktionstilstande  
2.4 Sikkerhed  
3 KONSTRUKTIONS- OG FUNKTIONSKRAV TIL KONTROL­ 
APPARAT  
3.1 Overvågning af isætning og udtagning af kort  
3.2 Måling af hastighed, position og afstand  
3.2.1 Måling af den tilbagelagte vejstrækning  
3.2.2 Måling af hastigheden  
3.2.3 Måling af position  
3.3 Tidsmåling  
3.4 Overvågning af føreraktiviteter  
3.5 Overvågning af kørestatus  
3.6 Indlæsning foretaget af fører  
3.6.1 Indlæsning af de steder, hvor den daglige arbejdstid begy nder 
og/eller slutter  
3.6.2 Manuel indlæsning af føreraktiviteter og førerens samtykk e til brug 
af ITS-grænsefladen  
3.6.3 Indlæsning af særlige omstændigheder  
▼M3 
3.6.4 Indlæsning af laste-/losseoperation  
▼B 
3.7 Forvaltning af virksomhedslåse  
3.8 Overvågning af kontrolaktiviteter  
3.9 Detektion af hændelser og/eller fejl  
3.9.1 Hændelsen »isætning af ugyldigt kort«  
3.9.2 Hændelsen »kortkonflikt«  
3.9.3 Hændelsen »tidsoverlapning«  
3.9.4 Hændelsen »kørsel uden behørigt kort«  
3.9.5 Hændelsen »isætning af kort under kørslen«  
3.9.6 Hændelsen »sidste kortsession ikke korrekt afsluttet«  
3.9.7 Hændelsen »overskridelse af tilladt hastighed«  
3.9.8 Hændelsen »afbrydelse af strømforsyning«  
3.9.9 Hændelsen »fejl ved kommunikation med faciliteten til fje rnkom­ 
munikation«  
3.9.10 Hændelsen »manglende positionsoplysninger fra GNSS-modta ger« ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 8  
3.9.11 Hændelsen »fejl ved kommunikation med det eksterne GNSS-  
udstyr«  
3.9.12 Hændelsen »fejl ved køredata«  
3.9.13 Hændelsen »køretøjsbevægelseskonflikt«  
3.9.14 Hændelsen »forsøg på sikkerhedsbrud«  
3.9.15 Hændelsen »tidskonflikt«  
3.9.16 Fejlen »kort«  
3.9.17 Fejlen »kontrolapparat«  
▼M3 
3.9.18 Hændelsen »GNSS-anomali«  
▼B 
3.10 Indbyggede tester og selvtester  
3.11 Læsning fra datalager  
3.12 Registrering og lagring i datalageret  
3.12.1 Identifikationsdata for apparat  
3.12.1.1 Identifikationsdata for køretøjsenhed  
3.12.1.2 Identifikationsdata for bevægelsessensor  
3.12.1.3 Identifikationsdata for globale satellitnavigationssys temer (GNSS)  
3.12.2 Nøgler og certifikater  
3.12.3 Data vedrørende isætning og udtagning af førerkort eller  værksteds­ 
kort 
3.12.4 Føreraktivitetsdata  
▼M1 
3.12.5 Steder og positioner, hvor daglige arbejdsperioder påbeg yndes, 
afsluttes og/eller hvor tre timers kumuleret køretid nås  
▼B 
3.12.6 Kilometertællerdata  
3.12.7 Detaljerede hastighedsdata  
3.12.8 Data vedrørende hændelser  
3.12.9 Data vedrørende fejl  
3.12.10 Kalibreringsdata  
3.12.11 Tidsjusteringsdata  
3.12.12 Kontrolaktivitetsdata  
3.12.13 Data vedrørende virksomhedslåse  
3.12.14 Data vedrørende dataoverførselsaktivitet  
3.12.15 Data vedrørende særlige omstændigheder  
3.12.16 Data vedrørende takografkort  
▼M3 
3.12.17 Grænsepassager  
3.12.18 Laste-/losseoperationer  
3.12.19 Digitalt kort  
▼B 
3.13 Læsning fra takografkort  
3.14 Registrering og lagring på takografkort  
3.14.1 Registrering og lagring på takografkort af første genera tion ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 9  
3.14.2 Registrering og lagring på takografkort af anden generat ion 
3.15 Visning på skærm  
3.15.1 Standardskærmbillede  
3.15.2 Visning af advarsel  
3.15.3 Adgang via menu  
3.15.4 Andre skærmbilleder  
3.16 Udskrivning  
3.17 Advarsler  
3.18 Dataoverførsel til eksterne medier  
3.19 Fjernkommunikation i forbindelse med målrettede vejsidekon troller  
▼M3 
3.20 Dataudveksling med yderligere eksterne enheder  
▼B 
3.21 Kalibrering  
3.22 Kalibreringskontrol ved vejsiden  
3.23 Tidsjustering  
3.24 Funktionsspecifikationer  
3.25 Materialer  
3.26 Mærkning  
▼M3 
3.27 Overvågning af grænsepassager  
3.28 Softwareopdatering  
▼B 
4 KONSTRUKTIONS- OG FUNKTIONSKRAV TIL TAKOGRAF­ 
KORT  
4.1 Synlige data  
4.2 Sikkerhed  
4.3 Standarder  
4.4 Miljømæssige og elektriske specifikationer  
4.5 Lagring af oplysninger  
4.5.1 Elementærfiler til identifikation og kortstyring  
4.5.2 Identifikation af IC-kort  
4.5.2.1 Identifikation af chip  
4.5.2.2 DIR (findes kun i takografkort af anden generation)  
4.5.2.3 ATR-oplysninger (betingede, findes kun i takografkort a f anden 
generation)  
4.5.2.4 Oplysninger med udvidet længde (betingede, findes kun i  takograf­ 
kort af anden generation)  
4.5.3 Førerkort  
4.5.3.1 Takografapplikation (tilgængelig for køretøjsenheder af  første og 
anden generation)  
4.5.3.1.1 Identifikation af applikation  
4.5.3.1.2 Nøgler og certifikater  
4.5.3.1.3 Identifikation af kort  
4.5.3.1.4 Identifikation af kortindehaver  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 10  
4.5.3.1.5 Dataoverførsel på kort  
4.5.3.1.6 Oplysninger om førerbevis  
4.5.3.1.7 Data vedrørende hændelser  
4.5.3.1.8 Data vedrørende fejl  
4.5.3.1.9 Føreraktivitetsdata  
4.5.3.1.10 Data vedrørende anvendte køretøjer  
4.5.3.1.11 Steder, hvor den daglige arbejdstid begynder og/elle r slutter  
4.5.3.1.12 Kortsessionsdata  
4.5.3.1.13 Kontrolaktivitetsdata  
4.5.3.1.14 Data vedrørende særlige omstændigheder  
4.5.3.2 Takografapplikation af anden generation (ikke tilgængel ig for køre­ 
tøjsenheder af første generation)  
4.5.3.2.1 Identifikation af applikation  
▼M3 
4.5.3.2.1.1 Yderligere identifikation af applikation (anvendes ikke af version 1 
af køretøjsenheder af anden generation)  
▼B 
4.5.3.2.2 Nøgler og certifikater  
4.5.3.2.3 Identifikation af kort  
4.5.3.2.4 Identifikation af kortindehaver  
4.5.3.2.5 Dataoverførsel på kort  
4.5.3.2.6 Oplysninger om førerbevis  
4.5.3.2.7 Data vedrørende hændelser  
4.5.3.2.8 Data vedrørende fejl  
4.5.3.2.9 Føreraktivitetsdata  
4.5.3.2.10 Data vedrørende anvendte køretøjer  
4.5.3.2.11 Steder og positioner, hvor den daglige arbejdstid be gynder og/eller 
slutter  
4.5.3.2.12 Kortsessionsdata  
4.5.3.2.13 Kontrolaktivitetsdata  
4.5.3.2.14 Data vedrørende særlige omstændigheder  
4.5.3.2.15 Data vedrørende anvendte køretøjsenheder  
▼M1 
4.5.3.2.16 Data vedrørende den position, hvor tre timers kumule ret køretid nås  
▼M3 
4.5.3.2.17 Status for ægthedsbekræftelse for positioner, der ve drører steder, 
hvor den daglige arbejdstid begynder og/eller slutter (anvendes  ikke 
af version 1 af køretøjsenheder af anden generation)  
4.5.3.2.18 Status for ægthedsbekræftelse for positioner, hvor d er opnås tre 
timers akkumuleret køretid (anvendes ikke af version 1 af køret øjs­ 
enheder af anden generation)  
4.5.3.2.19 Grænsepassager (anvendes ikke af version 1 af køretø jsenheder af 
anden generation)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 11  
4.5.3.2.20 Laste-/losseoperationer (anvendes ikke af version 1 af køretøjs­ 
enheder af anden generation)  
4.5.3.2.21 Indlæsninger af lasttype (anvendes ikke af version 1  af køretøjs­ 
enheder af anden generation)  
4.5.3.2.22 Konfiguration af køretøjsenhed (anvendes ikke af ver sion 1 af 
køretøjsenheder af anden generation)  
▼B 
4.5.4 Værkstedskort  
4.5.4.1 Takografapplikation (tilgængelig for køretøjsenheder af  første og 
anden generation)  
4.5.4.1.1 Identifikation af applikation  
4.5.4.1.2 Nøgler og certifikater  
4.5.4.1.3 Identifikation af kort  
4.5.4.1.4 Identifikation af kortindehaver  
4.5.4.1.5 Dataoverførsel på kort  
4.5.4.1.6 Kalibrerings- og tidsjusteringsdata  
4.5.4.1.7 Data vedrørende hændelser og fejl  
4.5.4.1.8 Føreraktivitetsdata  
4.5.4.1.9 Data vedrørende anvendte køretøjer  
4.5.4.1.10 Data vedrørende steder, hvor den daglige arbejdstid begynder 
og/eller slutter  
4.5.4.1.11 Kortsessionsdata  
4.5.4.1.12 Kontrolaktivitetsdata  
4.5.4.1.13 Data vedrørende særlige omstændigheder  
4.5.4.2 Takografapplikation af anden generation (ikke tilgængel ig for køre­ 
tøjsenheder af første generation)  
4.5.4.2.1 Identifikation af applikation  
▼M3 
4.5.4.2.1.1 Yderligere identifikation af applikation (anvendes ikke af version 1 
af køretøjsenheder af anden generation)  
▼B 
4.5.4.2.2 Nøgler og certifikater  
4.5.4.2.3 Identifikation af kort  
4.5.4.2.4 Identifikation af kortindehaver  
4.5.4.2.5 Dataoverførsel på kort  
4.5.4.2.6 Kalibrerings- og tidsjusteringsdata  
4.5.4.2.7 Data vedrørende hændelser og fejl  
4.5.4.2.8 Føreraktivitetsdata  
4.5.4.2.9 Data vedrørende anvendte køretøjer  
4.5.4.2.10 Data vedrørende steder, hvor den daglige arbejdstid begynder 
og/eller slutter  
4.5.4.2.11 Kortsessionsdata  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 12  
4.5.4.2.12 Kontrolaktivitetsdata  
4.5.4.2.13 Data vedrørende anvendte køretøjsenheder  
▼M1 
4.5.4.2.14 Data vedrørende den position, hvor tre timers kumule ret køretid nås  
▼B 
4.5.4.2.15 Data vedrørende særlige omstændigheder  
▼M3 
4.5.4.2.16 Status for ægthedsbekræftelse for positioner, der ve drører steder, 
hvor den daglige arbejdstid begynder og/eller slutter (anvendes  ikke 
af version 1 af køretøjsenheder af anden generation)  
4.5.4.2.17 Status for ægthedsbekræftelse for positioner, hvor d er opnås tre 
timers akkumuleret køretid (anvendes ikke af version 1 af køret øjs­ 
enheder af anden generation)  
4.5.4.2.18 Grænsepassager (anvendes ikke af version 1 af køretø jsenheder af 
anden generation)  
4.5.4.2.19 Laste-/losseoperationer (anvendes ikke af version 1 af køretøjs­ 
enheder af anden generation)  
4.5.4.2.20 Indlæsninger af lasttype (anvendes ikke af version 1  af køretøjs­ 
enheder af anden generation)  
4.5.4.2.21 Yderligere kalibreringsdata (anvendes ikke af versio n 1 af køretøjs­ 
enheder af anden generation)  
4.5.4.2.22 Konfiguration af køretøjsenhed (anvendes ikke af ver sion 1 af 
køretøjsenheder af anden generation)  
▼B 
4.5.5 Kontrolkort  
4.5.5.1 Takografapplikation (tilgængelig for køretøjsenheder af  første og 
anden generation)  
4.5.5.1.1 Identifikation af applikation  
4.5.5.1.2 Nøgler og certifikater  
4.5.5.1.3 Identifikation af kort  
4.5.5.1.4 Identifikation af kortindehaver  
4.5.5.1.5 Kontrolaktivitetsdata  
4.5.5.2 Takografapplikation af anden generation (ikke tilgængel ig for køre­ 
tøjsenheder af første generation)  
4.5.5.2.1 Identifikation af applikation  
▼M3 
4.5.5.2.1.1 Yderligere identifikation af applikation (anvendes ikke af version 1 
af køretøjsenheder af anden generation)  
▼B 
4.5.5.2.2 Nøgler og certifikater  
4.5.5.2.3 Identifikation af kort  
4.5.5.2.4 Identifikation af kortindehaver  
4.5.5.2.5 Kontrolaktivitetsdata  
▼M3 
4.5.5.2.6 Konfiguration af køretøjsenhed (anvendes ikke af vers ion 1 af 
køretøjsenheder af anden generation)  
▼B 
4.5.6 Virksomhedskort  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 13  
4.5.6.1 Takografapplikation (tilgængelig for køretøjsenheder af  første og 
anden generation)  
4.5.6.1.1 Identifikation af applikation  
4.5.6.1.2 Nøgler og certifikater  
4.5.6.1.3 Identifikation af kort  
4.5.6.1.4 Identifikation af kortindehaver  
4.5.6.1.5 Virksomhedsaktivitetsdata  
4.5.6.2 Takografapplikation af anden generation (ikke tilgængel ig for køre­ 
tøjsenheder af første generation)  
4.5.6.2.1 Identifikation af applikation  
▼M3 
4.5.6.2.1.1 Yderligere identifikation af applikation (anvendes ikke af version 1 
af køretøjsenheder af anden generation)  
▼B 
4.5.6.2.2 Nøgler og certifikater  
4.5.6.2.3 Identifikation af kort  
4.5.6.2.4 Identifikation af kortindehaver  
4.5.6.2.5 Virksomhedsaktivitetsdata  
▼M3 
4.5.6.2.6 Konfiguration af køretøjsenhed (anvendes ikke af vers ion 1 af 
køretøjsenheder af anden generation)  
▼B 
5 MONTERING AF KONTROLAPPARATET  
5.1 Montering  
5.2 Installationsplade  
5.3 Plombering  
6 KONTROL, EFTERSYN OG REPARATIONER  
6.1 Autorisering af installatører, værksteder og køretøjsfabrik anter 
▼M1 
6.2 Kontrol af nye eller reparerede komponenter  
▼B 
6.3 Monteringsinspektion  
6.4 Periodisk kontrol  
6.5 Måling af fejl  
6.6 Reparationer  
7 UDSTEDELSE AF KORT  
8 TYPEGODKENDELSE AF KONTROLAPPARATUR OG 
TAKOGRAFKORT  
8.1 Almindelige bestemmelser  
8.2 Sikkerhedsattest  
8.3 Funktionsattest  
8.4 Interoperabilitetsattest  
8.5 Typegodkendelsesattest  
8.6 Undtagelsesprocedure: første interoperabilitetsattest til k ontrolappa­ 
rater og takografkort af anden generation  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 14  
INDLEDNING  
Dette bilag indeholder kravene til anden generation af kontrola pparater og 
takografkort.  
Siden den 15. juni 2019 er anden generation af kontrolapparater  blevet installeret 
i køretøjer, der registreres i EU for første gang, og anden gen eration af tako­
grafkort er blevet udstedt.  
For at fremme en gnidningsløs indførelse af anden generation af  takografsystemer 
er anden generation af takografkort blevet udformet, så de også  kan bruges i 
første generation af køretøjsenheder, der er fremstillet i over ensstemmelse med 
bilag I B til forordning (EØF) nr. 3821/85.  
Tilsvarende kan takografkort af første generation anvendes i kø retøjsenheder af 
anden generation. Køretøjsenheder af anden generation kan dog k un kalibreres 
ved brug af værkstedskort af anden generation.  
Kravene til interoperabiliteten mellem første og anden generati on af takografsy­
stemer er angivet i dette bilag. Tillæg 15 indeholder nærmere o plysninger om, 
hvordan de to systemers sameksistens skal administreres.  
Som følge af gennemførelsen af nye funktioner, f.eks. brugen af  Galileo Open 
Signal Navigation Messages Authentication, registrering af græn sepassager og 
indlæsning af laste- og losseoperationer, og behovet for at øge  førerkortets kapa­
citet til 56 dages føreraktiviteter indføres der ved denne foro rdning desuden 
tekniske krav til anden version af anden generation af kontrola pparat og 
takografkort.  
▼B 
Liste over tillæg  
Tillæg 1: DATAORDLISTE  
Tillæg 2: SPECIFIKATION AF TAKOGRAFKORT  
Tillæg 3: PIKTOGRAMMER  
Tillæg 4: UDSKRIFTER  
Tillæg 5: SKÆRM  
Tillæg 6:  STIK TIL KALIBRERING OG DATAOVERFØRSEL PÅ FRONT­ 
PANELET  
Tillæg 7: PROTOKOLLER FOR DATAOVERFØRSEL  
Tillæg 8: KALIBRERINGSPROTOKOL  
Tillæg 9: TYPEGODKENDELSE — LISTE OVER MINDSTEKRAV TIL 
PRØVER  
Tillæg 10: SIKKERHEDSKRAV  
Tillæg 11: FÆLLES SIKKERHEDSMEKANISMER  
Tillæg 12: LOKALISERING BASERET PÅ ET GLOBALT SATELLITNA­ 
VIGATIONSSYSTEM (GNSS)  
Tillæg 13: ITS-INTERFACE  
Tillæg 14: FJERNKOMMUNIKATIONSFUNKTION  
Tillæg 15: MIGRATION: FORVALTNING AF SAMEKSISTENSEN AF 
UDSTYRSGENERATIONER  
Tillæg 16: ADAPTER TIL KØRETØJER I KLASSE M1 OG N1  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 15  
1 DEFINITIONER  
I dette bilag forstås ved:  
a) »aktivering«:  
den fase, hvori takografen bliver helt driftsklar og implemen­
terer alle funktioner, herunder sikkerhedsfunktioner, ved hjælp  
af et værkstedskort  
b) »ægthedsbekræftelse«:  
en funktion, som er bestemt til at fastslå og efterprøve en 
påberåbt identitet  
c) »ægthed«:  
den egenskab ved oplysninger, at de kommer fra en part, hvis 
identitet kan efterprøves  
d) »indbygget test (BIT)«:  
test, som køres på ordre fra operatøren eller fra eksternt udst yr 
e) »kalenderdag«:  
et døgn fra kl. 0:00 til kl. 24:00. Alle kalenderdage går efter  
UTC-tid (koordineret verdenstid)  
▼M3 
f) »kalibrering« af en intelligent takograf:  
opdatering eller bekræftelse af de køretøjsparametre, som skal 
ligge i datalageret. Køretøjsparametre omfatter køretøjsidenti­
fikation (VIN, VRN og den registrerende medlemsstat) samt 
køretøjskarakteristika (w, k, l, dækstørrelse, hastighedsbegræn ­
serens indstilling (hvis relevant), aktuel UTC-tid, aktuel kilo ­
meterstand, standardindstillet lasttype). Ved kalibrering af et  
kontrolapparat skal type og ID for alle monterede plomber, 
der relevante for typegodkendelsen, også registreres i datala­
geret.  
En opdatering eller bekræftelse, som udelukkende omfatter 
UTC-tid, betragtes som en tidsjustering og ikke som en kali­
brering, forudsat at det ikke er i strid med krav 409 anført i 
punkt 6.4.  
Til kalibrering af et kontrolapparat kræves værkstedskort  
g) »kortnummer«:  
et nummer, som består af 16 alfanumeriske tegn og entydigt 
identificerer et takografkort i en medlemsstat. Kortnummeret 
omfatter en identifikation, hvori det indgår en identifikation af 
føreren eller en identifikation af kortets ejer sammen med et 
fortløbende kortindeks, et korterstatningsindeks og et kortfor­
nyelsesindeks.  
Et kort er således entydigt identificeret ved den udstedende 
medlemsstats kode og kortnummeret  
▼B 
h) »fortløbende kortindeks«:  
kortnummerets 14. alfanumeriske tegn, som anvendes til at 
skelne mellem de forskellige kort, som udstedes til en virk­
somhed, et værksted eller en kontrolmyndighed med ret til at 
få udstedt flere forskellige takografkort. Virksomheden, værk­
stedet eller kontrolmyndigheden er entydigt identificeret ved 
de første 13 tegn i kortnummeret  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 16  
i) »kortfornyelsesindeks«:  
et kortnummers 16. alfanumeriske tegn, som øges, hver gang 
et takografkort, der svarer til en given identifikation, dvs. 
identifikation af føreren eller identifikation af kortets ejer 
sammen med fortløbende indeks, fornyes  
j) »korterstatningsindeks«:  
et kortnummers 15. alfanumeriske tegn, som øges, hver gang 
et takografkort, der svarer til en given identifikation, dvs. 
identifikation af føreren eller identifikation af kortets ejer 
sammen med fortløbende indeks, erstattes  
▼B 
k) »køretøjets vejdrejetal«:  
den karakteristiske størrelse, der angiver talværdien af udgang s­
signalet fra den køretøjsdel, der forbinder kontrolapparatet me d 
køretøjet (gearkassens udgangsaksel eller hjulakslen), mens det  
tilbagelægger en afstand på 1 km under normale prøvebetin­
gelser som defineret i krav 414. Vejdrejetallet udtrykkes i 
impulser pr. km (w = … imp/km)  
l) »virksomhedskort«:  
et takografkort, som medlemsstatens myndigheder udsteder til 
en transportvirksomhed, der skal betjene køretøjer monteret 
med en takograf, som identificerer transportvirksomheden og 
giver mulighed for at vise, overføre og udskrive data, der er 
lagret i takografen, og som denne transportvirksomhed har låst  
m) »kontrolapparatets konstant«:  
den karakteristiske størrelse, der angiver talværdien af det 
indgangssignal, som kræves for at vise og registrere en tilba­
gelagt afstand på 1 km. Denne konstant udtrykkes i impulser 
pr. km (k = … imp/km)  
n) »sammenhængende køretid« beregnes i kontrolapparatet 
som (  1 ): 
Aktuel akkumuleret køretid for en given fører siden afslut­
ningen af dennes sidste RÅDIGHED, PAUSE/HVILE eller 
periode, som er UKENDT (  2 ) på 45 minutter eller derover 
(denne periode kan være fordelt i henhold til Europa-Parla­
mentets og Rådets forordning (EF) nr. 561/2006 (  3 )). I bereg­
ningerne tages efter behov hensyn til tidligere aktiviteter, so m 
er gemt på førerkortet. Når føreren ikke har isat sit kort, 
baseres beregningerne på de data, der er registreret vedrørende  
den aktuelle periode, hvor der ikke var isat et kort, og som 
vedrører den pågældende kortplads  ▼M3 
( 1 ) Denne beregningsmetode for sammenhængende køretid og akkumule ret pausetid benyttes 
af kontrolapparatet til beregning af advarselssignal for sammen hængende køretid. Den 
foregriber ikke, hvilken retlig fortolkning disse tider skal gø res til genstand for. Der kan 
anvendes andre metoder til beregning af den sammenhængende køre tid og den akkumu­
lerede pausetid i stedet for disse definitioner, hvis de som fø lge af opdateringer i anden 
relevant lovgivning er forældet. 
( 2 ) Perioder med betegnelsen UKENDT er perioder, hvor førerens ko rt ikke var isat i et 
kontrolapparat, og for hvilke der ikke manuelt er indlæst fører aktiviteter. 
( 3 ) Europa-Parlamentets og Rådets forordning (EF) nr. 561/2006 af  15. marts 2006 om 
harmonisering af visse sociale bestemmelser inden for vejtransp ort og om ændring af 
Rådets forordning (EØF) nr. 3821/85 og (EF) nr. 2135/98 samt op hævelse af Rådets 
forordning (EØF) nr. 3820/85 (EFT L 102 af 11.4.2006, s. 1)
 02016R0799 — DA — 21.08.2023 — 003.001 — 17  
o) »kontrolkort«:  
et takografkort, som en medlemsstats myndigheder udsteder til 
en national kompetent kontrolmyndighed, som identificerer 
kontrolorganet og eventuelt kontrolmedarbejderen, og som 
giver adgang til de data, der er lagret i datalageret eller i 
førerkortene og eventuelt i værkstedskortene med henblik på 
læsning, udskrift og/eller dataoverførsel.  
Kortet skal også give adgang til kalibreringskontrol ved 
vejsiden-funktionen og dataene fra læseren til kommunika­
tionsudstyret til tidlig fjernafsløring  
p) »akkumuleret pausetid« beregnes i kontrolapparatet som (  1 ): 
den akkumulerede kørepausetid beregnes for en given fører 
som de aktuelle akkumulerede perioder med RÅDIGHED, 
PAUSE/HVILE eller UKENDT (  2 ) på hver mindst 15 minutter 
siden slutningen af den seneste periode af RÅDIGHED, 
PAUSE/HVILE eller UKENDT (  2 ) periode på 45 minutter 
eller derover (sidstnævnte periode kan være fordelt i henhold 
til forordning (EF) nr. 561/2006).  
I beregningerne tages efter behov hensyn til tidligere aktivi­
teter, som er gemt på førerkortet. Ukendte perioder, som har 
negativ varighed (dvs. ukendt periodes start > ukendt periodes 
slutning) pga. tidsoverlapning mellem to forskellige kontrol­
apparater, tages ikke i betragtning ved beregningen.  
Når føreren ikke har isat sit kort, baseres beregningerne på de  
data, der er registreret vedrørende den aktuelle periode, hvor 
der ikke var isat et kort, og som vedrører den pågældende 
kortplads.  
q) »datalager«:  
en elektronisk datalagerenhed, som er indbygget i kontrolappa­
ratet 
r) »digital underskrift«:  
data, som er vedhæftet til eller er en kodet transformation af en 
gruppe data, og med hvilke modtageren af datagruppen kan 
fastslå ægthed og integritet af den pågældende gruppe data  
s) »dataoverførsel«:  
kopiering sammen med den digitale signatur af en del af eller 
et komplet sæt datafiler, som er gemt i køretøjsenhedens data­
lager eller i takografkortets datalager, forudsat at denne proc es 
ikke ændrer eller sletter nogen lagrede data.  ▼B 
( 1 ) Denne beregningsmetode for sammenhængende køretid og akkumule ret pausetid benyttes 
af kontrolapparatet til beregning af advarselssignal for sammen hængende køretid. Den 
foregriber ikke, hvilken retlig fortolkning disse tider skal gø res til genstand for. Der kan 
anvendes andre metoder til beregning af den sammenhængende køre tid og den akkumu­
lerede pausetid i stedet for disse definitioner, hvis de som fø lge af opdateringer i anden 
relevant lovgivning er forældet. 
( 2 ) Perioder med betegnelsen UKENDT er perioder, hvor førerens ko rt ikke var isat i et 
kontrolapparat, og for hvilke der ikke manuelt er indlæst fører aktiviteter.
 02016R0799 — DA — 21.08.2023 — 003.001 — 18  
Fabrikanter af køretøjsenheder til intelligente takografer og 
fabrikanter af udstyr, der er konstrueret og beregnet til at ov er­
føre datafiler, træffer alle rimelige foranstaltninger til at s ikre, 
at overførslen af sådanne data kan gennemføres med mindst 
mulig forsinkelse for transportvirksomheder og førere.  
Det er muligvis ikke nødvendigt at overføre den detaljerede 
hastighedsfil for at fastslå, om forordning (EF) nr. 561/2006 e r 
overholdt, men den kan anvendes til andre formål, f.eks. 
undersøgelse af en ulykke  
t) »førerkort«:  
et takografkort, som medlemsstatens myndigheder udsteder til 
en bestemt fører, og som identificerer føreren og giver 
mulighed for at lagre aktivitetsdata for føreren  
u) »effektiv dækperiferi«:  
gennemsnittet af de afstande, hvert enkelt af køretøjets træk­
kende hjul tilbagelægger ved en fuld omdrejning. Måling af 
sådanne afstande skal finde sted under normale prøvebetin­
gelser som defineret i krav 414 og angives i formen »l = … 
mm«. Køretøjsfabrikanten kan erstatte måling af sådanne 
afstande med en teoretisk beregning, som tager hensyn til 
vægtfordelingen på akslerne for det driftsklare, ubelastede 
køretøj (  1 ). Metoderne til en sådan teoretisk beregning skal 
godkendes af de kompetente myndigheder i en medlemsstat, 
og det skal ske, før takografen aktiveres  
v) »hændelse«:  
unormal funktion, som afsløres af den intelligente takograf og 
kan skyldes forsøg på misbrug  
w) »eksternt GNSS-udstyr«:  
udstyr, som indeholder GNSS-modtageren, når køretøjs­
enheden ikke er en enkeltstående enhed, og andre kompo­
nenter, der er nødvendige for at beskytte kommunikationen 
af placeringsdata til resten af køretøjsenheden  
x) »fejl«:  
unormal funktion, som detekteres af den intelligente takograf 
og kan skyldes funktionsfejl ved apparatet eller svigt af dette  
y) »GNSS-modtager«:  
en elektronisk enhed, som modtager signaler fra et eller flere 
GNSS-systemer (Global Navigation Satellite System) og 
behandler dem digitalt for at tilvejebringe oplysninger om 
position, hastighed og tidspunkt  ▼B 
( 1 ) Kommissionens forordning (EU) nr. 1230/2012 af 12. december 2 012 om gennemførelse 
af Europa-Parlamentets og Rådets forordning (EF) nr. 661/2009 f or så vidt angår krav til 
typegodkendelse for masse og dimensioner for motorkøretøjer og påhængskøretøjer dertil 
og om ændring af Europa-Parlamentets og Rådets direktiv 2007/46 /EF (EUT L 353 af 
21.12.2012, s. 31), med de seneste ændringer.
 02016R0799 — DA — 21.08.2023 — 003.001 — 19  
z) »montering«:  
montering af en takograf i et køretøj  
aa) »interoperabilitet«:  
systemers og de bagvedliggende forretningsprocedurers evne 
til at udveksle data og dele information  
bb) »grænseflade«:  
en facilitet, der forbinder systemer og udgør det medium, 
hvorigennem de kan forbindes og fungere sammen  
cc) »position«:  
køretøjets geografiske koordinater på et givet tidspunkt  
dd) »bevægelsessensor«:  
en del af takografen, der afgiver et signal, som repræsenterer 
kørehastighed og/eller tilbagelagt afstand  
▼M3 
ee) »ugyldigt kort«:  
et kort, der enten findes defekt, som ikke har bestået ægtheds­
kontrollen, hvis gyldighedsperiode endnu ikke er begyndt, 
eller hvis udløbsdato er overskredet  
et kort anses også for ugyldigt af køretøjsenheden:  
— hvis et kort med samme kortudstedende medlemsstat, 
samme identifikation, dvs. identifikation af fører eller iden­
tifikation af ejer sammen med fortløbende indeks, og et 
højere fornyelsesindeks allerede blevet indsat i køretøjs­
enheden, eller  
— hvis et kort med samme kortudstedende medlemsstat, 
samme identifikation, dvs. identifikation af fører eller iden­
tifikation af ejer sammen med fortløbende indeks, men 
med et højere erstatningsindeks allerede blevet indsat i 
køretøjsenheden  
▼B 
ff) »åben standard«:  
en standard som fastsat i et standardspecifikationsdokument, 
der kan fås gratis eller for et symbolsk beløb, og som det er 
tilladt at kopiere, distribuere eller bruge gratis eller for et  
symbolsk vederlag  
gg) »uden for gyldighedsområdet«:  
når kontrolapparat ikke kræves anvendt efter bestemmelserne i 
forordning (EF) nr. 561/2006  
hh) »overskridelse af tilladt hastighed«:  
overskridelse af tilladt hastighed for køretøjet, defineret som  
en vilkårlig periode på mere end 60 sekunder, i hvilken køre­
tøjets målte hastighed overskrider den grænse for indstilling a f 
hastighedsbegrænseren, som er fastlagt i Rådets direktiv 
92/6/EØF (  1 ), med senere ændringer  ▼B 
( 1 ) Rådets direktiv 92/6/EØF af 10. februar 1992 om montering og anvendelse af hastig­
hedsbegrænsende anordninger i visse klasser af motorkøretøjer i  Fællesskabet (EFT L 57 
af 2.3.1992, s. 27).
 02016R0799 — DA — 21.08.2023 — 003.001 — 20  
ii) »periodisk eftersyn«:  
et sæt eftersyn, som udføres for at kontrollere, at takografen 
fungerer korrekt, at dens indstillinger svarer til køretøjets p ara­
metre, og at der ikke er nogen manipulerende anordninger 
knyttet til takografen  
jj) »printer«:  
den komponent i kontrolapparatet, som leverer udskrifter af 
lagrede data  
kk) »fjernkommunikation med henblik på tidlig afsløring«:  
kommunikation mellem fjernkommunikationsudstyret til tidlig 
afsløring og læseren til fjernkommunikation med henblik på 
tidlig afsløring under målrettede vejsidekontroller med det 
formål at fjernregistrere mulig manipulation eller misbrug af 
kontroludstyr  
▼M3 
ll) »udstyr til fjernkommunikation«, »modul til fjernkommunika­
tion« eller »udstyr til tidlig fjernafsløring«:  
det udstyr i køretøjsenheden, som anvendes til at udføre 
målrettede vejsidekontroller  
▼B 
mm) »læser til fjernkommunikation med henblik på tidlig afslø­
ring«:  
det system, som kontrolmedarbejdere anvender ved målrettede 
vejsidekontroller  
▼M3 
nn) »kortfornyelse«:  
udstedelse af et nyt takografkort, når et eksisterende kort ent en 
udløber, fejlfungerer eller er blevet returneret til den udste­
dende myndighed  
▼B 
oo) »reparation«:  
enhver reparation af en bevægelsessensor eller af en køretøjs­
enhed eller af et kabel, som kræver afbrydelse af dens strøm­
forsyning, eller dens afbrydelse fra andre af takografens 
komponenter eller oplukning af bevægelsessensoren eller køre­
tøjsenheden  
▼M3 
pp) »korterstatning«:  
udstedelse af et nyt takografkort som erstatning for et eksiste ­
rende kort, som er erklæret tabt, stjålet eller defekt og ikke er 
returneret til den udstedende myndighed  
▼B 
qq) »sikkerhedsattestering«:  
den proces, hvorved det attesteres af et attesteringsorgan, der  
arbejder ud fra fælles kriterier, at kontrolapparatet (eller 
-komponenten) eller det undersøgte takografkort opfylder 
sikkerhedsforskrifterne i de relevante sikringsprofiler  
rr) »selvtest«:  
test, som af kontrolapparatet foretages periodisk og automatisk  
til afsløring af fejl  
ss) »tidsmåling«:  
en permanent digital registrering af den koordinerede 
verdenstid (UTC)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 21  
tt) »tidsjustering«:  
en justering af aktuelt klokkeslæt; det kan være en automatisk 
justering, som anvender GNSS-modtagerens tid som reference, 
eller en justering foretaget ved kalibrering  
▼B 
uu) »dækstørrelse«:  
dækdimensionsbetegnelse (udvendige drivende hjul) i henhold 
til Rådets direktiv 92/23/EØF (  1 ) med senere ændringer  
vv) »køretøjsidentifikation«:  
de numre, som identificerer køretøjet: køretøjets indregistre­
ringsnummer (VRN) med angivelse af den medlemsstat, hvor 
det er indregistreret, og køretøjets identifikationsnummer 
(VIN) (  2 ) 
ww) til beregningsformål i kontrolapparatet forstås ved »uge«:  
tidsrummet fra mandag kl. 00:00 UTC til søndag kl. 24:00 
UTC  
xx) »værkstedskort«:  
et takografkort, som medlemsstatens myndigheder udsteder til 
udpeget personale hos en fabrikant af takografer, en installatø r, 
en køretøjsfabrikant eller i et værksted, som er autoriseret af  
samme medlemsstat, som identificerer kortindehaveren og 
giver mulighed for afprøvning, kalibrering og aktivering af 
og/eller dataoverførsel fra takograferne  
yy) »adapter«:  
en anordning, der afgiver et signal, som vedvarende repræsen­
terer kørehastighed og/eller tilbagelagt distance, som ikke er 
den samme som den anordning, der bruges til uafhængig regi­
strering af bevægelser, og som:  
▼M3 
— installeres og anvendes udelukkende i køretøjer af typerne 
M1 og N1 som defineret i artikel 4 i Europa-Parlamentets 
og Rådets forordning (EU) 2018/858 (  3 ) 
▼B 
— installeres, når det mekanisk set ikke er muligt at installer e 
nogen anden eksisterende type af bevægelsessensor, som er 
i overensstemmelse med de øvrige bestemmelser i dette 
bilag og de tilknyttede tillæg 1-15  ▼M3 
( 1 ) Rådets direktiv 92/23/EØF af 31. marts 1992 om dæk til motork øretøjer og påhæng­
skøretøjer samt om montering heraf (EFT L 129 af 14.5.1992, s. 95). 
( 2 ) Rådets direktiv 76/114/EØF af 18. december 1975 om indbyrdes tilnærmelse af 
medlemsstaternes lovgivning vedrørende skilte og foreskrevne på skrifter og disses 
anbringelsessted og -måde for motordrevne køretøjer og påhængsk øretøjer dertil 
(EFT L 24 af 30.1.1976, s. 1). 
( 3 ) Europa-Parlamentets og Rådets forordning (EU) 2018/858 af 30.  maj 2018 om godken­
delse og markedsovervågning af motorkøretøjer og påhængskøretøj er dertil samt af 
systemer, komponenter og separate tekniske enheder til sådanne køretøjer, om ændring 
af forordning (EF) nr. 715/2007 og (EF) nr. 595/2009 og om ophæ velse af direktiv 
2007/46/EF (EUT L 151 af 14.6.2018, s. 1).
 02016R0799 — DA — 21.08.2023 — 003.001 — 22  
— installeres mellem køretøjsenheden og det sted, hvor de 
hastigheds/afstandsrelaterede impulser genereres af integre­
rede følere eller alternative tilkoblinger  
— set i forhold til køretøjsenheden fungerer adapteren, som 
om en bevægelsessensor, der opfylder bestemmelserne i 
dette bilag og de tilknyttede tillæg 1-16, var tilsluttet køre­
tøjsenheden.  
Anvendelsen af en sådan adapter i de ovenfor beskrevne køre­
tøjer skal muliggøre installation og korrekt anvendelse af en 
køretøjsenhed, der opfylder alle krav i dette bilag.  
For sådanne køretøjer omfatter den intelligente takograf kabler , 
en adapter og en køretøjsenhed.  
zz) »dataintegritet«:  
sikring af, at lagrede data er nøjagtige og konsekvente, hvilke t 
er kendetegnet ved, at der ikke er foretaget ændring af data 
mellem to opdateringer af en datapost. Integritet indebærer, at  
dataene er en nøjagtig kopi af den oprindelige udgave, f.eks. a t 
de ikke er blevet beskadiget under indlæsning i eller udlæsning  
fra et takografkort eller en dedikeret enhed eller under trans­
mission via en kommunikationskanal.  
▼M3 
aaa) forbeholdt fremtidig brug  
▼B 
bbb) »intelligent takografsystem«:  
det kontrolapparat, de takografkort og alt det udstyr, der 
direkte eller indirekte indgår i et samspil under konstruktion,  
montering, brug, afprøvning og kontrol, såsom kort, læsere til 
fjernkommunikation og andet udstyr til dataoverførsel, data­
analyse, kalibrering og frembringelse, styring eller indførelse  
af sikkerhedselementer osv.  
▼M3 
ccc) »dato for indførelse«:  
den dato, der er fastsat i forordning (EU) nr. 165/2014, efter 
hvilken køretøjer, der er registreret for første gang, skal vær e 
udstyret med en takograf i overensstemmelse med denne 
forordning.  
▼B 
ddd) »sikringsprofil«:  
et dokument, der anvendes i forbindelse med certificeringspro­
cessen ud fra fælles kriterier, og som indeholder en implemen­
teringsuafhængig specifikation af sikkerhedskrav  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 23  
eee) »GNSS-nøjagtighed«:  
betyder i forbindelse med registrering af positioner ud fra 
GNSS med takografer den talværdi for HDOP (Horizontal 
Dilution of Precision), som beregnes ud fra den mindste af 
de HDOP-værdier, der indsamles på de tilgængelige 
GNSS-systemer  
▼M1 
fff) »kumuleret køretid«:  
en værdi, som repræsenterer det samlede kumulerede antal 
minutters kørsel med et bestemt køretøj.  
Værdien for kumuleret køretid er en fortløbende tælling af alle  
minutter, der anses for KØRSEL, gennem overvågning af 
kontrolapparatets funktionstilstand for kørsel og anvendes 
kun til at udløse registrering af køretøjets position, hver 
gang et multiplum af tre timers kumuleret køretid er nået. 
Kumuleringen starter, når kontrolapparatet aktiveres. Den 
påvirkes ikke af nogen anden aktivitet som f.eks. uden for 
gyldighedsområde eller færge/tog.  
Værdien for kumuleret køretid er ikke beregnet til at blive vis t, 
printet eller overført.  
▼B 
2 KONTROLAPPARATETS GENERELLE EGENSKABER OG 
FUNKTIONER  
2.1 Generelle egenskaber  
Kontrolapparatet har til formål at registrere, gemme, vise, udp rinte 
og udlæse data vedrørende førerens aktiviteter.  
Køretøjer, der er udstyret med kontrolapparat, som opfylder for skrif­
terne i dette bilag, skal være forsynet med hastighedsviser og kilo­
metertæller. Disse funktioner skal være indeholdt i kontrolappa ratet.  
01) Kontrolapparatet omfatter kabler, en bevægelsessensor og 
en køretøjsenhed.  
02) Grænsefladen mellem bevægelsessensorer og køretøjs­
enheder skal opfylde bestemmelserne i tillæg 11.  
03) Køretøjsenheden skal være tilsluttet et eller flere globale  
satellitnavigationssystemer som anført i tillæg 12.  
04) Køretøjsenheden skal kommunikere med udstyr til fjern­
kommunikation som anført i tillæg 14.  
▼M3 
05) Køretøjsenheden skal omfatte en ITS-grænseflade som 
anført i tillæg 13.  
Kontrolapparatet kan være tilsluttet andre faciliteter gennem 
ekstra grænseflader og/eller gennem ITS-interfacet.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 24  
06) Funktioner og anordninger, som indsættes i eller tilsluttes  
kontrolapparatet må, hvad enten de er godkendt eller ej, 
ikke forstyrre eller kunne forstyrre den korrekte og sikre 
funktion af kontrolapparatet eller overholdelsen af denne 
forordnings bestemmelser.  
Kontrolapparatets brugere identificerer sig over for appa­
ratet gennem takografkort.  
07) Kontrolapparatet giver selektiv adgangsret til data og funk ­
tioner, afhængigt af brugerens type og/eller identitet.  
Kontrolapparatet registrerer og gemmer data i sit datalager, i facili­
teten til fjernkommunikation og på takografkortene.  
▼M3 
Dette foregår i overensstemmelse med gældende EU-lovgivning om 
databeskyttelse og i overensstemmelse med artikel 7 i forord­
ning (EU) nr. 165/2014.  
▼B 
2.2 Funktioner  
08) Kontrolapparatet skal garantere følgende funktioner:  
— overvågning af isætninger og udtagninger af kort  
— måling af hastighed, afstand og position  
— tidsmåling  
— overvågning af førerens aktiviteter  
— overvågning af kørestatus  
▼M3 
— manuel indlæsning foretaget af føreren:  
— indlæsning af de steder, hvor den daglige arbejdstid 
begynder og/eller slutter,  
— manuel indlæsning af føreraktiviteter og førerens 
samtykke til brug af ITS-grænsefladen  
— indlæsning af særlige omstændigheder  
— indlæsning af laste-/losseoperationer  
▼B 
— forvaltning af virksomhedslåse  
— overvågning af kontrolaktiviteter  
— detektion af hændelser og/eller fejl  
— indbyggede tester og selvtester  
— læsning fra datalager  
— registrering og lagring i datalager  
— læsning fra takografkort  
— registrering og lagring på takografkort  
— visning på skærm  
— udprintning  
— advarsler  
— overførsel af data til eksterne medier  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 25  
— fjernkommunikation i forbindelse med målrettede vejs­
idekontroller  
— udlæsning af data til supplerende faciliteter  
— kalibrering  
— kalibreringskontrol ved vejsiden  
— tidsjustering  
▼M3 
— overvågning af grænsepassager  
— softwareopdatering.  
▼B 
2.3 Funktionstilstande  
09) Kontrolapparatet skal have fire funktionstilstande:  
— driftstilstand  
— kontroltilstand  
— kalibreringstilstand  
— virksomhedstilstand.  
10) Kontrolapparatet skal skifte til følgende funktionstilstand , 
afhængigt af de gyldige takografkort, som indsættes i kort­
læserne. Ved bestemmelse af funktionstilstanden er genere­
ringen af takografkortet irrelevant, forudsat at det isatte kor t 
er gyldigt. Et værkstedskort af første generation skal altid 
betragtes som ugyldigt, hvis det sættes i en køretøjsenhed 
af anden generation.  
Funktionstilstand  Førerkortplads  
Intet kort  Førerkort  Kontrolkort  Værkstedskort  Virksomhedskort
 Kortplads for medchauffør Intet kort  Operationelt  Operationelt  Kontrol  Kalibrering  Virksomhed  
Førerkort  Operationelt  Operationelt  Kontrol  Kalibrering  Virksomhed  
Kontrolkort  Kontrol  Kontrol  Kontrol (*)  Operationelt  Operationelt  
Værkstedskort  Kalibrering  Kalibrering  Operationelt  Kalibrering (*)  Operationelt  
Virksomheds­
kort Virksomhed  Virksomhed  Operationelt  Operationelt  Virksomhed (*)  
(*) I disse situationer skal kontrolapparatet kun bruge det tak ografkort, der sættes i førerkortpladsen.  
11) Kontrolapparatet skal ignorere ugyldige kort, som 
indsættes; dog skal det kunne vise, printe og overføre 
data, som ligger på et udgået kort.  
12) Alle de i punkt 2.2 angivne funktioner skal virke i alle 
funktionstilstande, med følgende undtagelser:  
— Kalibreringsfunktionen er kun tilgængelig i kalibre­
ringstilstand  
— Funktionen til kalibreringskontrol ved vejsiden er kun 
tilgængelig i kontroltilstand  
— Funktionen styring af virksomhedslåse er kun tilgæn­
gelig i virksomhedstilstand  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 26  
— Funktionen overvågning af kontrolaktivitet er opera­
tionel i kontroltilstand  
▼M3 
— Dataoverførselsfunktionen er ikke tilgængelig i driftstil­
stand, undtagen:  
a) som fastsat i krav 193  
b) ved overførsel af et førerkort, når der ikke er indsat 
andre korttyper i køretøjsenheden.  
▼B 
13) Kontrolapparatet kan udlæse alle data til skærm, printer og  
eksterne grænsefladeenheder, med følgende undtagelser:  
— I driftstilstand slettes enhver personlig identifikation 
(efternavn og fornavn), som ikke modsvarer det isatte 
takografkort; alle kortnumre, som ikke svarer til det 
isatte kort, bliver delvis slettet (hver andet tegn — fra 
venstre mod højre — bliver slettet).  
▼M3 
— I virksomhedstilstand kan førerrelaterede data (krav 
102, 105, 108, 133a og 133e) kun udlæses for perioder, 
som ikke er låst, eller som ingen anden virksomhed 
(således som denne er identificeret ved de første 13 
cifre i virksomhedskortnummeret) har låst.  
▼B 
— Når der intet kort sidder i kontrolapparatet, kan fører­
relaterede data kun udlæses for den aktuelle dato og de 
otte foregående kalenderdage.  
▼M3 
— Personoplysninger, der registreres eller frembringes af 
takografen eller takografkortene, må ikke udlæses 
gennem køretøjsenhedens ITS-grænseflade, medmindre 
samtykket fra den fører, som dataene vedrører, 
verificeres.  
▼M1 
— Køretøjsenhederne har en gyldighedsperiode for 
normale operationer på 15 år fra og med den faktiske 
dato for køretøjsenhedens certifikater, men køretøjs­
enheder kan anvendes i yderligere tre måneder, dog 
kun til dataoverførsel.  
▼B 
2.4 Sikkerhed  
▼M1 
Med sikringen af systemet tilstræbes det at beskytte datahukom­
melsen på en sådan måde, at uvedkommende ikke kan få adgang 
til og manipulere med data, og således at forsøg herpå opdages,  
beskytte integriteten og ægtheden af data, som udveksles mellem  
bevægelsessensor og køretøjsenhed, beskytte integriteten og 
ægtheden af data, som udveksles mellem kontrolapparat og tako­
grafkort, beskytte integriteten og ægtheden af data, der udveks les 
mellem køretøjsenhed og eventuelt eksternt GNSS-udstyr, beskytt e 
fortroligheden, integriteten og ægtheden af data, som udveksles  
gennem udstyret til fjernkommunikation med henblik på tidlig af slø­
ring til kontrolformål, samt verificere integriteten og ægthede n af 
overførte data.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 27  
14) Af hensyn til systemets sikkerhed skal følgende kompo­
nenter opfylde sikkerhedsforskrifterne i deres sikringspro­
filer som foreskrevet i tillæg 10:  
— køretøjsenhed  
— takografkort  
— bevægelsessensor  
▼M3 
— eksternt GNSS-udstyr (denne profil kræves og gælder 
kun for den eksterne variant af GNSS-udstyr).  
▼B 
3 KONSTRUKTIONS- OG FUNKTIONSKRAV TIL KONTROL­
APPARAT  
3.1 Overvågning af isætning og udtagning af kort  
15) Kontrolapparatet skal overvåge isætning og udtagning af 
kort i kortlæseenhederne.  
▼M3 
16) Når et kort isættes (eller efter fjernægthedsbekræftelse af  
kort), skal kontrolapparatet detektere, om kortet er et 
gyldigt takografkort i overensstemmelse med definition 
ee) i afsnit 1, og, i bekræftende fald, identificere dets 
type og generation.  
For at kontrollere, om et kort allerede er isat, skal kontrol­
apparatet anvende de takografkortdata, der er gemt i dets 
datalager, som fastsat i krav 133.  
▼B 
17) Første generation af takografkort skal betragtes som ugyl­
dige af kontrolapparatet, efter at muligheden for at bruge 
første generation af takografkort er blevet udelukket af et 
værksted i overensstemmelse med tillæg 15 (krav MIG003).  
18) Første generation af værkstedskort, som sættes i kontrol­
apparater af anden generation, skal betragtes som ugyldige.  
19) Kontrolapparatet skal være konstrueret således, at det låse r 
takografkortene i stilling, når de isættes korrekt i kortlæ­
serne.  
▼M3 
20) Udtagning af takografkort må kun være mulig, når køretøjet 
holder stille, og efter at de relevante data er blevet gemt på 
kortene. Udtagning af kortet må kun kunne ske ved et 
aktivt indgreb af brugeren.  
▼B 
3.2 Måling af hastighed, position og afstand  
21) Bevægelsessensoren (som kan være indlejret i adapteren) er 
det vigtigste værktøj til måling af hastighed og afstand.  
22) Denne funktion skal til stadighed måle og kunne angive 
den kilometerstand, der svarer til den totale afstand tilba­
gelagt af køretøjet ved brug af impulserne fra bevægelses­
sensoren.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 28  
23) Desuden skal funktionen til stadighed måle og kunne 
angive køretøjets hastighed ved brug af impulserne fra 
bevægelsessensoren.  
24) Hastighedsmålefunktionen skal endvidere kunne angive, om 
køretøjet er i bevægelse eller holder stille. Køretøjet anses 
for at være i bevægelse, så snart funktionen detekterer flere 
end 1 imp/sek. fra bevægelsessensoren i mindst fem 
sekunder, ellers anses det for at holde stille.  
25) Anordninger, som viser hastighed (speedometer) og total 
tilbagelagt distance (kilometertæller) og er monteret i et 
køretøj med et kontrolapparat, som opfylder denne forord­
nings bestemmelser, skal opfylde forskrifterne for tillade­
lige maksimale tolerancer i dette bilag (se 3.2.1 og 3.2.2).  
▼M3 
26) For at opdage manipulation af køredata skal oplysninger fra  
bevægelsessensoren bekræftes af oplysninger om køretøjets 
bevægelse fra GNSS-modtageren og fra en eller flere andre 
kilder, som er uafhængige af bevægelsessensoren. Der skal 
være mindst én anden uafhængig kilde til oplysninger om 
køretøjets bevægelse i køretøjsenheden, uden at der er 
behov for en ekstern grænseflade.  
27) Denne funktion skal måle køretøjets position for at mulig­
gøre registrering af:  
— positioner, hvor føreren og/eller medchaufføren påbe­
gynder sin daglige arbejdsperiode  
— positioner, hvor den kumulerede køretid når op på et 
multiplum af tre timer  
— positioner, hvor køretøjet har passeret et lands grænse  
— positioner, hvor laste-/losseoperationer har fundet sted  
— positioner, hvor føreren og/eller medchaufføren afslutter 
sin daglige arbejdsperiode.  
▼B 
3.2.1  Måling af den tilbagelagte vejstrækning  
28) Den tilbagelagte afstand kan måles enten:  
— så både fremadkørsel og bagudkørsel medregnes, eller  
— ved fremadkørsel alene.  
29) Kontrolapparatet skal måle afstande fra 0 til 9 999 999,9 
km. ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 29  
30) Ved afstandsmåling skal tolerancen være inden for følgende 
grænser (afstande på mindst 1 000 m):  
— ± 1 % før montering  
— ± 2 % ved montering og periodisk eftersyn  
— ± 4 % under brug.  
▼M3 
Tolerancerne må ikke anvendes til forsætligt at ændre den 
målte afstand.  
▼B 
31) Afstandsmålingen skal have en opløsning på 0,1 km eller 
bedre.  
3.2.2  Måling af hastigheden  
32) Kontrolapparatet skal måle hastigheder fra 0 til 220 km/t.  
▼M3 
33) For at sikre maksimal tolerance på den viste hastighed på 
± 6 km/t under brug, og under hensyntagen til:  
— en tolerance på ± 2 km/t på variationer i inddata 
(dækvariationer, …)  
— en tolerance på ± 1 km/t på målinger udført under 
montering og periodiske eftersyn  
skal kontrolapparatet ved hastigheder mellem 20 
og 180 km/t, og ved vejdrejetal af køretøjet mellem 2 400 
og 25 000 imp/km, måle hastigheden med en tolerance på 
± 1 km/t (ved konstant hastighed).  
Bemærk: Datalagringens opløsning medfører, at der skal 
tillægges en yderligere tolerance på ± 0,5 km/t på den 
hastighed, der er gemt af kontrolapparatet.  
▼B 
34) Inden for 2 sekunder efter afslutning af en hastigheds­
ændring skal hastighedsmåling kunne foretages korrekt 
med de normale tolerancer, når hastighedsændringen er 
sket i et tempo på indtil 2 m/s  2 . 
35) Hastighedsmålingen skal have en opløsning på minimum 
1 km/t.  
3.2.3  Måling af position  
36) Kontrolapparatet skal måle køretøjets absolutte position ve d 
hjælp af GNSS-modtageren.  
▼M3 
37) Den absolutte position måles i geografiske koordinater for 
breddegrad og længdegrad i grader og minutter med en 
opløsning på 1/10 af et minut.  
▼B 
3.3 Tidsmåling  
38) Tidsmålefunktionen skal permanent og digitalt levere 
UTC-dato og -tid.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 30  
39) Der anvendes UTC-dato og -tid til at tidsbestemme data i 
kontrolapparatet (registreringer, dataudveksling) og til alle 
udskrifter, der er anført i tillæg 4 »Udskrifter«.  
40) For at lokal tid kan vises, skal forskydningen af den viste  
tid kunne ændres i trin på en halv time. Ingen andre 
forskydninger end negative eller positive multipla af halve 
timer er tilladt.  
▼M3 
41) Tidspunktdriften skal være ± 1 sekund pr, dag eller 
derunder under temperaturforhold i overensstemmelse med 
krav 213 og uden tidsjustering.  
41a) Tidsnøjagtigheden, når tiden justeres af værksteder i over ­
ensstemmelse med krav 212, skal være 3 sekunder eller 
bedre.  
41b) Køretøjsenheden skal indeholde en tidspunktdrifttæller, so m 
beregner den maksimale tidspunktdrift siden sidste tids­
justering i overensstemmelse med punkt 3.23. Den maksi­
male tidspunktdrift defineres af køretøjsenhedens fabrikant 
og må ikke overstige 1 sekund pr. dag som fastsat i 
krav 41.  
41c) Tidspunktdrifttælleren nulstilles til 1 sekund efter hver tids­
justering af kontrolapparatet i overensstemmelse med punkt 
3.23. Dette omfatter:  
— automatiske tidsjusteringer  
— tidsjusteringer udført i kalibreringstilstand.  
▼B 
42) Tidsmålingens opløsning skal være minimum 1 sekund.  
43) Tidsmålingen må under typegodkendelsesomstændigheder 
ikke kunne påvirkes af en afbrydelse i den eksterne strøm­
forsyning på mindre end 12 måneder.  
3.4 Overvågning af føreraktiviteter  
44) Denne funktion skal permanent og særskilt overvåge akti­
viteterne af én fører og én medchauffør.  
45) Føreraktiviteter skal bestå i KØRSEL, ARBEJDE, 
RÅDIGHED eller PAUSE/HVILE.  
46) Fører og/eller medchauffør skal manuelt kunne vælge 
ARBEJDE, RÅDIGHED eller PAUSE/HVILE.  
47) Når køretøjet bevæger sig, skal der automatisk vælges 
KØRSEL for føreren og RÅDIGHED for medchaufføren.  
48) Når køretøjet standser, skal der automatisk vælges 
ARBEJDE for føreren.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 31  
49) Det første aktivitetsskift til PAUSE/HVILE eller 
RÅDIGHED, som finder sted inden for 120 sekunder 
efter det ved standsning af køretøjet udløste automatiske 
skift til ARBEJDE, antages at have fundet sted på tids­
punktet for køretøjets standsning (således at skiftet til 
ARBEJDE eventuelt ophæves).  
▼B 
50) Denne funktion skal udlæse aktivitetsskift til kontrolfunk­
tionerne med en opløsning på et minut.  
51) Er der for et givet kalenderminut registreret KØRSEL som 
aktivitet i både det umiddelbart foregående og umiddelbart 
efterfølgende minut, anses hele det pågældende minut for 
KØRSEL.  
52) Et givet kalenderminut, der ikke anses for KØRSEL efter 
krav 051, anses for at bestå udelukkende af samme aktivitet 
som den længstvarende uafbrudte aktivitet i det pågældende 
minut (eller, for lige længe varende aktiviteter, den senest 
forekommende af disse).  
53) Denne funktion skal endvidere overvåge førerens kontinuer­
lige køretid og akkumulerede pausetid.  
3.5 Overvågning af kørestatus  
54) Denne funktion overvåger kørestatus permanent og 
automatisk.  
55) Som kørestatus vælges FØRERHOLD, når der er isat to 
gyldige førerkort i apparatet; i alle andre tilfælde vælges 
ÉN FØRER som kørestatus.  
3.6 Indlæsning foretaget af fører  
3.6.1  Indlæsning af de steder, hvor den daglige arbejdstid begynder 
og/eller slutter  
56) Denne funktion skal give mulighed for indlæsning af de 
steder, hvor den daglige arbejdstid begynder og/eller 
slutter for fører og/eller medchauffør ifølge vedkommende 
selv. 
▼M3 
57) Ved steder forstås den pågældende stat samt, hvor det er 
relevant, region.  
58) Ved udtagning af førerkort (eller værkstedskort) skal 
kontrolapparatet vise køretøjets aktuelle placering på 
grundlag af GNSS-oplysningerne og det lagrede digitale 
kort i overensstemmelse med punkt 3.12.19 og anmode 
kortindehaveren om at bekræfte eller manuelt korrigere 
stedet.  
59) Det sted, der er indlæst i overensstemmelse med krav 58, 
anses for at være det sted, hvor den daglige arbejdstid 
slutter. Det registreres på det relevante førerkort (eller 
værkstedskort) som en midlertidig indlæsning og kan 
derfor senere overskrives.  
Under de følgende omstændigheder valideres (dvs. over­
skrives ikke mere) en midlertidig indlæsning ved sidste 
udtag af kortet:  
— der indlæses et sted, hvor den aktuelle daglige arbejds­
periode begynder, under den manuelle indlæsning i 
henhold til krav 61)  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 32  
— den næste indlæsning af et sted, hvor den aktuelle 
daglige arbejdstid begynder, hvis kortindehaveren ikke 
indlæser et sted, hvor arbejdstiden begynder eller slut­
tede, under den manuelle indlæsning i henhold til krav 
61). 
Under de følgende omstændigheder overskrives en midler­
tidig indlæsning ved sidste udtag af kortet, og en ny værdi 
valideres:  
— næste indlæsning af et sted, hvor den aktuelle daglige 
arbejdstid slutter, hvis kortindehaveren ikke indlæser et 
sted, hvor arbejdstiden begynder eller sluttede, under 
den manuelle indlæsning i henhold til krav 61).  
▼B 
60) Det skal være muligt at indlæse steder, hvor den daglige 
arbejdstid begynder og/eller slutter, ved hjælp af komman­
doer i menuerne. Hvis der foretages mere end én sådan 
indlæsning inden for et kalenderminut, bevares kun den 
sidste indlæsning af begyndelsesstedet og den sidste indlæs­
ning af slutstedet, som er foretaget inden for dette tidsrum.  
▼M3 
Kontrolapparatet skal vise køretøjets aktuelle placering på 
grundlag af GNSS-oplysningerne og de(t) lagrede digitale 
kort i overensstemmelse med punkt 3.12.19 og anmode 
kortindehaveren om at bekræfte eller manuelt korrigere 
stedet.  
▼B 
3.6.2  Manuel indlæsning af føreraktiviteter og førerens samtykke til brug 
af ITS-grænsefladen  
▼M3 
61) Kontrolapparatet skal efter isætning af fører- eller værk­
stedskortet, og først på det tidspunkt, tillade manuel indlæs­
ning af aktiviteter. Manuel indlæsning af aktiviteter fore­
tages med lokal tid og dato i den tidszone (UTC-forskyd­
ning), som køretøjsenheden aktuelt er indstillet til.  
Ved isætning af fører- eller værkstedskort skal kortindeha­
veren mindes om:  
— dato og klokkeslæt for den sidste udtagning af det 
pågældende kort  
— valgfrit: den lokale tidsforskydning, som aktuelt er 
indstillet for køretøjsenheden.  
Ved første isætning af et førerkort eller værkstedskort, som 
køretøjsenheden ikke kender, skal kortholderen opfordres til 
at give sit samtykke til udlæsning af takografrelaterede 
personoplysninger gennem ITS-grænsefladen. For at 
kontrollere, om et kort allerede er isat, skal kontrolapparatet  
anvende de takografkortdata, der er gemt i dets datalager, 
som fastsat i krav 133.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 33  
Dette samtykke kan til enhver tid gives eller trækkes tilbage 
ved hjælp af kommandoer i menuen, forudsat at førerkortet 
eller værkstedskortet er isat.  
Det skal være muligt at indlæse aktiviteter inden for 
følgende begrænsninger:  
— Aktivitetstypen skal være ARBEJDE, RÅDIGHED eller 
PAUSE/HVILE  
— Start- og sluttidspunkterne for hver aktivitet skal ligge 
inden for perioden mellem den sidste kortudtagning og 
den aktuelle isætning  
— Aktiviteterne må ikke overlappe hinanden i tid.  
Det skal være muligt at foretage manuelle indlæsninger ved 
den første isætning af et fører- eller værkstedskort, som 
ikke tidligere har været anvendt.  
Proceduren for manuel indlæsning af aktiviteter skal bestå 
af lige så mange på hinanden følgende trin, som er nødven­
dige for at indstille en aktivitetstype og et start- og et slut ­
tidspunkt for hver aktivitet. For enhver del af tidsperioden 
mellem den sidste kortudtagning og den aktuelle kortisæt­
ning skal kortindehaveren have mulighed for ikke at regi­
strere nogen aktivitet.  
Under de manuelle indlæsninger i forbindelse med korti­
sætningen skal kortindehaveren, hvis relevant, have 
mulighed for at indlæse:  
— et sted, hvor en tidligere daglig arbejdsperiode er sluttet, 
og det tilknyttede tidspunkt (hvorved den indlæsning, 
der skete ved den sidste kortudtagning, overskrives og 
valideres)  
— et sted, hvor den aktuelle daglige arbejdsperiode 
begynder, og det tilknyttede tidspunkt (hvorved en 
midlertidig indlæsning, der skete ved den sidste kortud­
tagning, valideres).  
For det sted, hvor den aktuelle daglige arbejdstid begynder, 
der er registreret ved den aktuelle isætning af kortet, skal 
kontrolapparatet vise køretøjets aktuelle placering på 
grundlag af GNSS-oplysningerne og de(t) lagrede digitale 
kort i overensstemmelse med punkt 3.12.19 og anmode 
kortindehaveren om at bekræfte eller manuelt korrigere 
stedet.  
Hvis kortindehaveren ikke indlæser et sted, hvor arbejds­
tiden begynder eller slutter, under de manuelle indlæsninger 
i forbindelse med kortisætningen, anses dette for en angi­
velse af, at vedkommendes arbejdstid ikke har ændret sig 
siden den sidste kortudtagning. Den næste indlæsning af et 
sted, hvor en tidligere daglig arbejdsperiode ender, over­
skriver så den midlertidige indlæsning, der blev foretaget 
ved den sidste kortudtagning.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 34  
Hvis der indlæses et sted, skal det registreres i det relevante  
takografkort.  
Manuelle indlæsninger skal afbrydes, hvis:  
— kortet tages ud, eller  
— køretøjet er i bevægelse og kortet sidder i førerens 
kortplads.  
Yderligere afbrydelser er tilladt, f.eks. en timeout efter en 
vis periode med brugerinaktivitet. Hvis manuelle indlæs­
ninger bliver afbrudt, skal kontrolapparatet godkende alle 
komplette indlæsninger af steder og aktiviteter (med enten 
entydigt sted og tid eller aktivitetstype og start- og sluttids ­
punkt), som allerede er foretaget.  
Hvis der isættes et andet fører- eller værkstedskort, mens 
der er ved at blive foretaget manuelle indlæsninger af akti­
viteter for et tidligere isat kort, skal de manuelle indlæs­
ninger for det tidligere kort afsluttes, før der påbegyndes 
manuelle indlæsninger af det andet kort.  
Kortindehaveren skal have mulighed for at tilføje manuelle 
indlæsninger i henhold til følgende minimumsprocedure:  
— Manuel indlæsning af aktiviteter i kronologisk række­
følge for perioden mellem den sidste kortudtagning og 
den aktuelle isætning.  
— Starttidspunktet for den første aktivitet skal være sat til 
kortudtagningstidspunktet. For hver efterfølgende 
indlæsning skal starttidspunktet være forud sat således, 
at det følger umiddelbart efter den tidligere indlæsning. 
Der skal vælges aktivitetstype og sluttidspunkt for hver 
aktivitet.  
Denne proces skal slutte, når sluttidspunktet for en manuelt 
indlæst aktivitet er lig kortisætningstidspunktet.  
Kontrolapparatet skal gøre det muligt for førere og værk­
steder at overføre manuelle indlæsninger, der skal indlæses 
under proceduren, via den ITS-grænseflade, der er anført i 
tillæg 13, og eventuelt via andre grænseflader.  
Kontrolapparatet skal give kortindehaveren mulighed for at 
ændre en manuelt indlæst aktivitet, indtil den godkendes 
ved valg af en bestemt kommando. Derefter skal det være 
forbudt at foretage enhver sådan ændring.  
▼B 
3.6.3  Indlæsning af særlige omstændigheder  
▼M3 
62) Kontrolapparatet skal give føreren mulighed for tidstro 
indlæsning af følgende to særlige omstændigheder:  
— »UDEN FOR GYLDIGHEDSOMRÅDE« (start, slut).  
— »OVERFART MED FÆRGE/TOG« (start, slut).  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 35  
»OVERFART MED FÆRGE/TOG« må ikke finde sted, 
når betingelsen »UDEN FOR GYLDIGHEDSOMRÅDE« 
er åbnet. Hvis betingelsen »UDEN FOR GYLDIGHEDS­
OMRÅDE« er åbnet, må kontrolapparatet ikke give 
brugerne mulighed for at indlæse en markering af starten 
på tilstanden »OVERFART MED FÆRGE/TOG«.  
Er betingelsen »UDEN FOR GYLDIGHEDSOMRÅDE« 
åbnet, skal den automatisk lukkes af kontrolapparatet ved 
isætning eller udtagning af et førerkort.  
Hvis betingelsen »UDEN FOR GYLDIGHEDSOMRÅDE« 
er åbnet, skal det forhindre følgende hændelser og 
advarsler:  
— Kørsel uden behørigt kort  
— Advarsler forbundet med sammenhængende køretid.  
Føreren skal indlæse markeringen af starten på tilstanden 
»OVERFART MED FÆRGE/TOG« straks efter at have 
valgt PAUSE/HVILE om bord på færgen eller toget.  
En åbnet tilstand OVERFART MED FÆRGE/TOG skal 
afsluttes af kontrolapparatet, når et af følgende forekommer:  
— Føreren afslutter tilstanden OVERFART MED 
FÆRGE/TOG manuelt, hvilket skal ske efter ankomst 
til færgens/togets bestemmelsessted, inden føreren kører 
fra borde  
— betingelsen »UDEN FOR GYLDIGHEDSOMRÅDE« 
er åbnet  
— føreren tager sit kort ud  
— en føreraktivitet beregnes som KØRSEL i et kalender­
minut i overensstemmelse med punkt 3.4.  
Hvis flere specifikke betingelser af den samme type 
indlæses inden for et kalenderminut, registreres kun den 
sidste.  
3.6.4  Indlæsning af laste-/losseoperation  
62a) Kontrolapparatet skal give føreren mulighed for i realtid at 
indlæse og bekræfte oplysninger om, at køretøjet lastes eller 
losses, eller at en samtidig laste-/losseoperation udføres.  
Hvis flere laste-/losseoperationer af den samme type 
indlæses inden for et kalenderminut, registreres kun den 
sidste.  
62b) Lastning, losning eller samtidige laste-/losseoperationer 
registreres som særskilte hændelser.  
62c) Oplysningerne om lastning/losning indlæses, inden køre­
tøjet forlader det sted, hvor laste-/losseoperation udføres.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 36  
3.7 Forvaltning af virksomhedslåse  
63) Denne funktion skal give mulighed for styring af de låse, 
som oprettes af en virksomhed for at dataadgangen er 
forbeholdt virksomheden, når systemet er i virksomhedstil­
stand.  
64) Virksomhedslåse består af startdato/klokkeslæt (lås-ind) og  
slutdato/klokkeslæt (lås-ud), knyttet til virksomhedens iden­
titet som angivet af virksomhedskortets nummer (ved lås- 
ind). 
65) Lås »ind« og lås »ud« kan kun foretages i realtid.  
66) Enten skal kun den virksomhed kunne låse ud, som har låst 
»ind« (som angivet ved de første 13 cifre i virksomheds­
kortets nummer), eller også  
67) skal lås-ud udføres automatisk, hvis en anden virksomhed 
låser ind.  
68) Hvis en virksomhed låser ind, hvor forudgående lås var for 
samme virksomhed, antages det, at forudgående lås ikke er 
låst »ud« og stadig er »ind«.  
3.8 Overvågning af kontrolaktiviteter  
69) Denne funktion skal overvåge aktiviteterne VISNING PÅ 
SKÆRM, UDPRINTNING, UDLÆSNING på køretøjs­
enhed og kort samt KALIBRERINGSKONTROL VED 
VEJSIDEN, som finder sted i kontroltilstand.  
70) Funktionen skal endvidere overvåge aktiviteter vedrørende 
KONTROL MED OVERSKRIDELSE AF TILLADT 
HASTIGHED i kontroltilstand. Kontrol med overskridelse 
af tilladt hastighed anses for at have fundet sted, når en 
udskrift om »overskridelse af tilladt hastighed« er sendt til 
printer eller til skærm, eller når der er overført data vedrø­
rende »hændelser og fejl« fra køretøjsenhedens datalager.  
3.9 Detektion af hændelser og/eller fejl  
71) Denne funktion detekterer følgende hændelser og/eller fejl:  
3.9.1  Hændelsen »isætning af ugyldigt kort«  
72) Denne hændelse skal udløses ved isætning af et vilkårligt 
ugyldigt kort, ved isætning af et førerkort, der allerede er 
udskiftet, og/eller ved udløb af et isat gyldigt kort.  
3.9.2  Hændelsen »kortkonflikt«  
73) Denne hændelse skal udløses når en af de kombinationer af 
gyldige kort, som angivet med X i følgende tabel, 
forekommer:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 37  
Kortkonflikt  Førerkortplads  
Intet kort  Førerkort  Kontrolkort  Værkstedskort  Virksomhedskort
 Kortplads for medchauffør 
Intet kort  
Førerkort  X  
Kontrolkort  X  X  X  
Værkstedskort  X  X  X  X  
Virksomhedskort  X  X  X  
3.9.3  Hændelsen »tidsoverlapning«  
74) Denne hændelse skal udløses, når dato/klokkeslæt for 
seneste udtagning af førerkort, læst på kortet, er senere 
end aktuel dato/aktuelt klokkeslæt på det kontrolapparat, 
hvori kortet indsættes.  
3.9.4  Hændelsen »kørsel uden behørigt kort«  
75) Denne hændelse skal udløses for enhver af de gyldige 
kombinationer af takografkort, som er angivet med X i 
følgende tabel, når føreraktiviteten skifter til KØRSEL, 
eller når der skiftes funktionstilstand, mens føreraktiviteten 
er KØRSEL:  
Kørsel uden behørigt kort  Førerkortplads  
Intet (eller ugyl­
digt) kort  Førerkort  Kontrolkort  Værkstedskort  Virksomhedskort
 Kortplads for medchauffør Intet (eller ugyldigt) 
kort X X  X  
Førerkort  X  X  X  X  
Kontrolkort  X  X  X  X  X  
Værkstedskort  X  X  X  X  
Virksomhedskort  X  X  X  X  X  
3.9.5  Hændelsen »isætning af kort under kørslen«  
76) Denne hændelse skal udløses, når der indsættes et tako­
grafkort i en vilkårlig kortplads, mens føreraktiviteten er 
KØRSEL.  
3.9.6  Hændelsen »sidste kortsession ikke korrekt afsluttet«  
77) Denne hændelse skal udløses, når kontrolapparatet ved 
isætning af kortet konstaterer, at foregående kortsession 
trods bestemmelserne i punkt 3.1 ikke er blevet afsluttet 
korrekt (kortet er taget ud, før alle relevante data er 
blevet gemt på kortet). Denne hændelse er kun relevant 
for fører- og værkstedskort.  
3.9.7  Hændelsen »overskridelse af tilladt hastighed«  
78) Denne hændelse skal udløses for hver overskridelse af 
tilladt hastighed.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 38  
3.9.8  Hændelsen »afbrydelse af strømforsyning«  
79) Denne hændelse skal udløses ved enhver sådan afbrydelse 
af strømforsyningen til bevægelsessensor og/eller køretøjs­
enhed, som sker i en anden måde end kalibrerings- eller 
kontroltilstand og varer over 200 millisekunder. Afbrydel­
sestærsklen fastlægges af fabrikanten. Det fald i spændings­
forsyningen, som fremkommer ved start af køretøjets 
motor, må ikke udløse denne hændelse.  
3.9.9  Hændelsen »fejl ved kommunikation med faciliteten til fjernkommu ­
nikation«  
80) Denne hændelse skal udløses  uden for kalibreringstil ­
stand , hvis faciliteten til fjernkommunikation ikke kvitterer 
for modtagelse af fjernkommunikationsdata sendt fra køre­
tøjsenheden ved mere end tre forsøg.  
3.9.10  Hændelsen »manglende positionsoplysninger fra GNSS-modtager«  
81) Denne hændelse skal udløses  uden for kalibreringstil ­
stand  i tilfælde af manglende positionsoplysninger fra 
GNSS-modtageren (intern eller ekstern) i mere end tre 
timer af akkumuleret køretid.  
3.9.11  Hændelsen »fejl ved kommunikation med det eksterne GNSS-udstyr«  
82) Denne hændelse skal udløses  uden for kalibreringstil ­
stand  i tilfælde af afbrydelse af kommunikationen mellem 
det eksterne GNSS-udstyr og køretøjsenheden i mere end 
20 minutter i træk, mens køretøjet er i bevægelse.  
3.9.12  Hændelsen »fejl ved køredata«  
▼M3 
83) Denne hændelse skal udløses  uden for kalibreringstil ­
stand  ved afbrydelse af den normale dataudveksling 
mellem bevægelsessensor og køretøjsenhed og/eller ved 
fejl i dataintegritet eller -ægthedskontrol under dataudveks­
ling mellem bevægelsessensor og køretøjsenhed. Denne 
hændelse skal også udløses  uden for kalibreringstilstand , 
hvis hastigheden beregnet ud fra bevægelsessensorens 
impulser stiger fra 0 til mere end 40 km/t på 1 sekund 
og derefter forbliver over 40 km/t i mindst 3 sekunder.  
▼B 
3.9.13  Hændelsen »køretøjsbevægelseskonflikt«  
▼M3 
84) Denne hændelse skal udløses som anført i tillæg 12  uden 
for kalibreringstilstand , hvis bevægelsesoplysningerne 
beregnet ud fra bevægelsessensoren er i modstrid med 
bevægelsesoplysninger beregnet ud fra den interne 
GNSS-modtager, fra det eksterne GNSS-udstyr eller fra 
andre uafhængige kilder i overensstemmelse med krav 26. 
Denne hændelse udløses ikke under en overfart med færge/ 
tog. ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 39  
3.9.14  Hændelsen »forsøg på sikkerhedsbrud«  
85) Denne hændelse skal udløses ved enhver anden hændelse, 
der berører sikkerheden ved bevægelsessensor og/eller 
køretøjsenhed og/eller det eksterne GNSS-udstyr som fore­
skrevet i tillæg 10, og som ikke finder sted i kalibrerings­
tilstand.  
▼M1 
3.9.15  Hændelsen »tidskonflikt«  
▼M3 
86) Denne hændelse skal udløses  uden for kalibreringstil ­
stand , hvis køretøjsenheden registrerer en forskel mellem 
tiden i køretøjsenhedens tidsmålingsfunktion og tidsangi­
velsen fra de ægthedsbekræftede positioner, der er overført 
af GNSS-modtageren eller det eksterne GNSS-udstyr. En 
»tidsforskel« registreres, hvis tidsforskellen overstiger ± 3 
sekunder svarende til den tidsnøjagtighed, der er fastsat i 
krav 41a, idet sidstnævnte forhøjes med den maksimale 
tidspunktdrift pr. dag. Denne hændelse registreres sammen 
med kontrolapparatets interne urværdi. Køretøjsenheden 
skal udføre kontrollen for at udløse hændelsen »tidskon­
flikt«, umiddelbart inden køretøjsenheden automatisk 
justerer køretøjsenhedens interne ur, i overensstemmelse 
med krav 211.  
▼B 
3.9.16  Fejlen »kort«  
87) Denne fejl skal udløses, når der optræder fejl ved et tako­
grafkort under driften.  
3.9.17  Fejlen »kontrolapparat«  
88) Denne fejl skal udløses, når et af nedenstående svigt fore­
kommer, uden at apparatet er i kalibreringstilstand:  
— Intern fejl i køretøjsenhed  
— Printerfejl  
— Displayfejl  
— Dataoverførselsfejl  
— Følerfejl  
— Fejl ved GNSS-modtager eller eksternt GNSS-udstyr  
— Fejl ved faciliteten til fjernkommunikation  
▼M3 
— Fejl ved ITS-grænseflade.  
3.9.18  Hændelsen »GNSS-anomali«  
88a) Denne hændelse skal udløses uden for kalibreringstilstand,  
når GNSS-modtageren registrerer et angreb, eller når 
ægthedsbekræftelse af navigationsmeddelelser mislykkes, 
som anført i tillæg 12. Hvis hændelsen »GNSS-anomali« 
er blevet udløst, genererer køretøjsenheden ikke andre 
hændelser af typen GNSS-anomali inden for de næste 10 
minutter.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 40  
3.10 Indbyggede tester og selvtester  
89) ►M1 Kontrolapparatet skal detektere fejl gennem selv­
tester og indbyggede tester i overensstemmelse med 
følgende tabel: ◄  
Den testede underenhed  Selvtest  Indbygget test  
Programmel  Integritet  
Datalager  Adgang  Adgang, dataintegritet  
Kortlæseenheder  Adgang  Adgang  
Tastatur  Manuelt eftersyn  
Printer  (op til fabrikanten)  Udskrift  
Skærm  Visuel kontrol  
Dataoverførsel 
(udføres kun under data­
overførsel)  Korrekt funktion  
Føler  Korrekt funktion  Korrekt funktion  
Faciliteten til fjernkommu­
nikation  Korrekt funktion  Korrekt funktion  
GNSS-udstyr  Korrekt funktion  Korrekt funktion  
▼M3 
ITS-grænseflade  Korrekt funktion  
▼B 
3.11 Læsning fra datalager  
90) Kontrolapparatet skal kunne læse alle data, som er gemt i 
dets lager.  
3.12 Registrering og lagring i datalageret  
▼M3 
I dette punkt  
— defineres »365 dage« som 365 kalenderdage med en aktivitet i 
køretøjet svarende til gennemsnitsførerens. Den gennemsnitlige 
aktivitet pr. dag i et køretøj defineres som mindst seks førere  
eller medchauffører, seks cyklusser med isætning/udtagning af 
kort samt 256 aktivitetsskift. »365 dage« omfatter således mind st 
2 190 (med)chauffører, 2 190 cyklusser med kortisætning og 
-udtagning samt 93 440 aktivitetsskift  
— defineres det gennemsnitlige antal indlæsninger af sted pr. d ag 
som mindst 6 indlæsninger, hvor den daglige arbejdstid starter,  6 
indlæsninger, hvor den daglige arbejdstid slutter, således at » 365 
dage« omfatter mindst 4 380 indlæsninger af sted  
— defineres det gennemsnitlige antal positioner pr. dag, hvor d en 
kumulerede køretid når op på et multiplum af tre timer, som 
mindst 6 positioner, således at »365 dage« omfatter mindst 
2 190 sådanne positioner  
— defineres det gennemsnitlige antal grænsepassager pr. dag som  
mindst 20 passager, således at »365 dage« omfatter mindst 
7 300 grænsepassager  ▼B
02016R0799 — DA — 21.08.2023 — 003.001 — 41  
— defineres det gennemsnitlige antal laste-/losseoperationer pr . dag 
som mindst 25 operationer (uanset typen), således at »365 dage«  
omfatter mindst 9 125 laste-/losseoperationer  
— registreres klokkeslæt med en opløsning på 1 minut, medmindre  
andet er angivet  
— registreres kilometerstand med en opløsning på 1 kilometer  
— hastigheder registreres med en opløsning på 1 km/t  
— registreres positioner (breddegrad og længdegrad) i grader og  
minutter med en opløsning på 1/10 minut og den tilhørende 
GNSS-nøjagtighed og -indlæsningstid og med en markering, 
der viser, om positionen er blevet ægthedsbekræftet.  
▼B 
91) Data gemt i datalageret må under typegodkendelsesomstæn­
digheder ikke kunne påvirkes af en afbrydelse i den 
eksterne strømforsyning af under tolv måneders varighed. 
Derudover må data gemt i den eksterne facilitet til fjern­
kommunikation som defineret i tillæg 14 ikke kunne 
påvirkes af en afbrydelse i strømforsyningen af under 28 
dages varighed.  
92) Kontrolapparatet skal implicit eller eksplicit kunne regi­
strere følgende data og gemme dem i datalageret:  
3.12.1  Identifikationsdata for apparat  
3.12.1.1 I d e n t i f i k a t i o n s d a t a f o r k ø r e t ø j s e n h e d  
93) Kontrolapparatet skal i sit datalager kunne lagre følgende 
identifikationsdata for køretøjsenheden:  
— fabrikantens navn  
— fabrikantens adresse  
— reservedelsnummer  
— serienummer  
— køretøjsenhedens generation  
— mulighed for at bruge takografkort af første generation  
— programmellets versionsnummer  
— installationsdato for den pågældende version af program­
mellet  
— apparatets produktionsår  
— godkendelsesnummer  
▼M3 
— identifikator af version af digitalt kort (krav 133l).  
94) Køretøjsenhedens identifikationsdata registreres og lagres 
én gang for alle af køretøjsenhedens fabrikant, undtagen 
data, som kan ændres i tilfælde af softwareopdatering i 
overensstemmelse med denne forordning, og mulighed for 
at bruge takografkort af første generation.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 42  
3.12.1.2 I d e n t i f i k a t i o n s d a t a f o r b e v æ g e l s e s s e n s o r  
95) Bevægelsessensoren skal kunne gemme følgende identifika­
tionsdata i sit lager:  
— fabrikantens navn  
— serienummer  
— godkendelsesnummer.  
— navn på indlejret sikkerhedskomponent (f.eks. reserve­
delsnummer på intern chip/processor)  
— betegnelse på operativsystem (f.eks. programmellets 
versionsnummer).  
96) Identifikationsdata på bevægelsessensoren registreres og 
lagres én gang for alle i bevægelsessensoren af dennes 
fabrikant.  
▼M3 
97) Køretøjsenheden skal kunne registrere og i sit datalager 
gemme følgende data vedrørende de 20 seneste vellykkede 
parringer af bevægelsessensordata (hvis der er flere 
parringer inden for én kalenderdag, gemmes kun den 
første og den sidste parring på den pågældende dag):  
▼B 
Følgende data skal registreres for hver af disse parringer:  
— identifikationsdata for bevægelsessensor  
— serienummer  
— godkendelsesnummer  
— parringsdata for bevægelsessensor:  
— dato for parring.  
3.12.1.3 I d e n t i f i k a t i o n s d a t a f o r g l o b a l e s a t e l l i t n a v i g a ­
t i o n s s y s t e m e r ( G N S S )  
98) Det eksterne GNSS-udstyr skal kunne gemme følgende 
identifikationsdata i sit lager:  
— fabrikantens navn  
— serienummer  
— godkendelsesnummer.  
— navn på indlejret sikkerhedskomponent (f.eks. reserve­
delsnummer på intern chip/processor)  
— betegnelse på operativsystem (f.eks. programmellets 
versionsnummer).  
99) Identifikationsdataene registreres og lagres én gang for al le 
i det eksterne GNSS-udstyr af dettes fabrikant.  
▼M3 
100) Køretøjsenheden skal kunne registrere og i sit datalager 
gemme følgende data vedrørende de 20 seneste vellykkede 
sammenkoblinger fra eksternt GNSS-udstyr (hvis der er 
flere sammenkoblinger inden for én kalenderdag, gemmes 
kun den første og den sidste sammenkobling på den pågæl­
dende dag).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 43  
Følgende data skal registreres for hver af disse sammen­
koblinger:  
— identifikationsdata for det eksterne GNSS-udstyr:  
— serienummer  
— godkendelsesnummer  
— sammenkoblingsdata om eksternt GNSS-udstyr:  
— dato for sammenkobling.  
3.12.2  Nøgler og certifikater  
101) Kontrolapparatet skal kunne gemme en række kryptogra­
fiske nøgler og certifikater som præciseret i tillæg 11, del 
A og B.  
3.12.3  Data vedrørende isætning og udtagning af førerkort eller værksteds ­
kort 
102) For hver cyklus med isætning og udtagning af fører- eller 
værkstedskort i apparatet skal kontrolapparatet registrere og 
i datalageret gemme:  
— kortindehaverens efternavn og fornavn(e), således som 
de er lagret på kortet  
— kortnummer, udstedende medlemsstat og udløbsdato 
som lagret på kortet  
— kortgeneration  
— isætningsdato og -klokkeslæt  
— køretøjets kilometerstand ved isætning af kortet  
— den kortplads, som kortet sidder i  
— dato og klokkeslæt for udtagning af kortet  
— køretøjets kilometerstand ved udtagning af kortet  
— følgende oplysninger om det foregående køretøj, føreren 
har anvendt, som lagret på kortet:  
— køretøjets indregistreringsnummer og den indregi­
strerende medlemsstat  
— køretøjsenhedens generation (hvis den foreligger)  
— dato og klokkeslæt for udtagning af kortet  
— et flag, som angiver, om kortindehaver ved isætning af 
kortet har indlæst aktiviteter manuelt eller ikke.  
103) Datalageret skal kunne opbevare disse data i mindst 365 
dage.  
104) Når lagerpladsen er opbrugt, skal nye data erstatte de 
ældste data.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 44  
3.12.4  Føreraktivitetsdata  
105) Følgende data skal af kontrolapparatet registreres og 
gemmes i datalageret ved enhver aktivitetsændring for 
fører og/eller medchauffør og/eller ethvert skift i kørestatus 
og/eller enhver isætning eller udtagning af et fører- eller 
værkstedskort:  
— kørestatus (FØRERHOLD, ÉN FØRER)  
— kortplads (FØRER, MEDCHAUFFØR)  
— kortstatus for den pågældende kortplads (ISAT, IKKE 
ISAT)  
— aktivitet (KØRSEL, RÅDIGHED, ARBEJDE, PAUSE/ 
HVILE)  
— dato og klokkeslæt for ændringen.  
ISAT betyder, at et gyldigt fører- eller værkstedskort er sat 
i kortpladsen. IKKE ISAT betyder det modsatte, dvs. der 
sidder ikke et gyldigt fører- eller værkstedskort i kort­
pladsen (f.eks. er der isat et virksomhedskort, eller intet 
kort er isat).  
Aktivitetsdata, som indlæses manuelt af føreren, bliver ikke 
registreret i datalageret.  
106) Datalageret skal kunne opbevare føreraktivitetsdata i mind st 
365 dage.  
107) Når lagerpladsen er opbrugt, skal nye data erstatte de 
ældste data.  
▼M1 
3.12.5  Steder og positioner, hvor daglige arbejdsperioder starter, slutter 
og/eller hvor tre timers kumuleret køretid nås  
108) Kontrolapparatet skal registrere og i sit datalager gemme:  
— steder og positioner, hvor føreren og/eller medchauf­
føren påbegynder sin daglige arbejdsperiode  
— positioner, hvor den kumulerede køretid når op på et 
multiplum af tre timer  
— steder og positioner, hvor føreren og/eller medchauf­
føren slutter sin daglige arbejdsperiode.  
▼B 
109) Hvis køretøjets position ikke oplyses af GNSS-modtageren 
på disse tidspunkter, skal kontrolapparatet bruge den 
seneste tilgængelige position og den tilhørende dato og tid.  
110) Sammen med hvert sted eller hver position skal kontrol­
apparatet registrere og i sit datalager gemme:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 45  
— kortnummer for fører og/eller medchauffør samt kortud­
stedende medlemsstat  
▼B 
— kortgeneration  
— indlæsningsdato og -klokkeslæt  
▼M1 
— indlæsningens art (begyndelse, slutning eller tre timers 
kumuleret køretid)  
▼B 
— den tilhørende GNSS-nøjagtighed, dato og tid, hvis 
relevant  
— køretøjets kilometerstand  
▼M3 
— et flag, der viser, om positionen er blevet ægtheds­
bekræftet.  
110a) For steder, hvor den daglige arbejdstid begynder eller 
slutter, som er indlæst under den manuelle indlæsningspro­
cedure ved isætning af kortet i overensstemmelse med krav 
61, gemmes køretøjets aktuelle kilometerstand og position.  
▼M1 
111) Datalageret skal kunne rumme steder og positioner, hvor 
daglige arbejdsperioder starter og slutter, og/eller hvor tre 
timers kumuleret køretid nås, for mindst 365 dage.  
▼B 
112) Når lagerpladsen er opbrugt, skal nye data erstatte de 
ældste data.  
3.12.6  Kilometertællerdata  
113) Kontrolapparatet skal i sit datalager registrere køretøjet s 
kilometerstand og den tilsvarende dato ved midnat hver 
kalenderdag.  
114) Datalageret skal i mindst 365 kalenderdage kunne opbevare 
værdierne af kilometerstanden ved midnat.  
115) Når lagerpladsen er opbrugt, skal nye data erstatte de 
ældste data.  
3.12.7  Detaljerede hastighedsdata  
▼M1 
116) Kontrolapparatet skal registrere og i sit datalager gemme 
køretøjets øjeblikkelige hastighed med tilhørende dato og 
klokkeslæt i hvert sekund for mindst de seneste 24 timer, 
køretøjet har bevæget sig.  
▼B 
3.12.8  Data vedrørende hændelser  
Med henblik på bestemmelserne i dette afsnit skal tiden registr eres 
med en opløsning på 1 sekund.  
117) For hver hændelse, som detekteres, skal kontrolapparatet 
registrere følgende data og gemme dem i datalageret i over­
ensstemmelse med følgende lagringsbestemmelser:  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 46  
Hændelse  Lagringsbestemmelse  Data, som skal lagres for hver hændelse  
Isætning af ugyldigt kort  — de 10 seneste hændelser  — dato og klokkeslæt for hændelsen 
— korttype, kortnummer, udstedende 
medlemsstat og generation af det kort, 
som er årsag til hændelsen 
— antal tilsvarende hændelser den pågæl­
dende dag  
Kortkonflikt  — de 10 seneste hændelser  — hændelsens startdato og -klokkeslæt 
— hændelsens slutdato og -klokkeslæt 
— korttype, kortnummer, udstedende 
medlemsstat og generation af de to 
kort, som er årsag til konflikten.  
Kørsel uden behørigt kort  — den længstvarige hændelse for hver af 
de 10 seneste dage, den er forekommet 
— de 5 længstvarende hændelser inden for 
de sidste 365 dage  — hændelsens startdato og -klokkeslæt 
— hændelsens slutdato og -klokkeslæt 
— korttype, kortnummer, udstedende 
medlemsstat og generation af kort, der 
er isat ved starten og/eller slutningen af 
hændelsen 
— antal tilsvarende hændelser den pågæl­
dende dag  
Isætning af kort under 
kørslen  — den seneste hændelse for hver af de 10 
seneste dage, den er forekommet  — dato og klokkeslæt for hændelsen 
— korttype, kortnummer, udstedende 
medlemsstat og generation 
— antal tilsvarende hændelser den pågæl­
dende dag  
▼M3 
Seneste kortsession ikke 
korrekt afsluttet  — de 10 seneste hændelser  — dato og klokkeslæt for isætning af kortet 
— korttype, kortnummer, udstedende 
medlemsstat og generation 
— de seneste sessionsdata, aflæst fra kortet: 
— dato og klokkeslæt for isætning af kortet.  
▼B 
Overskridelse af tilladt 
hastighed (1)  — den alvorligste hændelse for hver af de 
seneste 10 dage, hvor den er fore­
kommet (dvs. den, hvor gennemsnits­
hastigheden har været størst) 
— de 5 alvorligste hændelser inden for de 
sidste 365 dage 
— den første hændelse, som har fundet 
sted efter sidste kalibrering  — hændelsens startdato og -klokkeslæt 
— hændelsens slutdato og -klokkeslæt 
— den højeste hastighed målt under 
hændelsen 
— den aritmetiske gennemsnitshastighed 
målt under hændelsen 
— korttype, kortnummer, udstedende 
medlemsstat og generation af førerkortet 
(hvis relevant) 
— antal tilsvarende hændelser den pågæl­
dende dag  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 47  
Hændelse  Lagringsbestemmelse  Data, som skal lagres for hver hændelse  
Strømforsyningssvigt (2)  — den længstvarende hændelse for hver af 
de 10 seneste dage, den er forekommet 
— de 5 længstvarende hændelser inden for 
de sidste 365 dage  — hændelsens startdato og -klokkeslæt 
— hændelsens slutdato og -klokkeslæt 
— korttype, kortnummer, udstedende 
medlemsstat og generation af kort, der 
er isat ved starten og/eller slutningen af 
hændelsen 
— antal tilsvarende hændelser den pågæl­
dende dag  
Fejl ved kommunikation 
med faciliteten til fjern­
kommunikation  — den længstvarende hændelse for hver af 
de 10 seneste dage, den er forekommet 
— de 5 længstvarende hændelser inden for 
de sidste 365 dage  — hændelsens startdato og -klokkeslæt 
— hændelsens slutdato og -klokkeslæt 
— korttype, kortnummer, udstedende 
medlemsstat og generation af kort, der 
er isat ved starten og/eller slutningen af 
hændelsen 
— antal tilsvarende hændelser den pågæl­
dende dag  
Manglende positions­
oplysninger fra GNSS- 
modtager  — den længstvarende hændelse for hver af 
de 10 seneste dage, den er forekommet 
— de 5 længstvarende hændelser inden for 
de sidste 365 dage  — hændelsens startdato og -klokkeslæt 
— hændelsens slutdato og -klokkeslæt 
— korttype, kortnummer, udstedende 
medlemsstat og generation af kort, der 
er isat ved starten og/eller slutningen af 
hændelsen 
— antal tilsvarende hændelser den pågæl­
dende dag  
▼M1 
Fejl ved kommunikation 
med det eksterne GNSS- 
udstyr  — den længstvarende hændelse for hver af 
de 10 seneste dage, den er forekommet 
— de 5 længstvarende hændelser inden for 
de seneste 365 dage  — hændelsens startdato og -klokkeslæt 
— hændelsens slutdato og -klokkeslæt 
— korttype, kortnummer, udstedende 
medlemsstat og generation af kort, der 
er isat ved starten og/eller slutningen af 
hændelsen 
— antal tilsvarende hændelser den pågæl­
dende dag  
▼B 
Fejl ved køredata  — den længstvarende hændelse for hver af 
de 10 seneste dage, den er forekommet 
— de 5 længstvarende hændelser inden for 
de sidste 365 dage  — hændelsens startdato og -klokkeslæt 
— hændelsens slutdato og -klokkeslæt 
— korttype, kortnummer, udstedende 
medlemsstat og generation af kort, der 
er isat ved starten og/eller slutningen af 
hændelsen 
— antal tilsvarende hændelser den pågæl­
dende dag  
Køretøjsbevægelseskon­
flikt — den længstvarende hændelse for hver af 
de 10 seneste dage, den er forekommet 
— de 5 længstvarende hændelser inden for 
de sidste 365 dage  — hændelsens startdato og -klokkeslæt 
— hændelsens slutdato og -klokkeslæt 
— korttype, kortnummer, udstedende 
medlemsstat og generation af kort, der 
er isat ved starten og/eller slutningen af 
hændelsen 
— antal tilsvarende hændelser den pågæl­
dende dag  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 48  
Hændelse  Lagringsbestemmelse  Data, som skal lagres for hver hændelse  
Forsøg på sikkerhedsbrud  — de 10 seneste hændelser for hver type 
hændelse  — hændelsens startdato og -klokkeslæt 
— hændelsens slutdato og -klokkeslæt (hvis 
relevant) 
— korttype, kortnummer, udstedende 
medlemsstat og generation af kort, der 
er isat ved starten og/eller slutningen af 
hændelsen 
— hændelsens type  
▼M1 
Tidskonflikt  — den alvorligste hændelse for hver af de 
10 seneste dage, den er forekommet 
(dvs. med den største forskel mellem 
kontrolapparatdato og -tid og 
GNSS-dato og -tid) 
— de 5 alvorligste hændelser inden for de 
seneste 365 dage  — kontrolapparat, dato og klokkeslæt 
— GNSS, dato og klokkeslæt 
— korttype, kortnummer, udstedende 
medlemsstat og generation af kort, der 
er isat ved starten og/eller slutningen af 
hændelsen 
— antal tilsvarende hændelser den pågæl­
dende dag  
▼M3 
GNSS-anomali  — de længstvarende hændelser for hver af 
de 10 seneste dage, den er forekommet 
— de 5 længstvarende hændelser inden for 
de seneste 365 dage.  — hændelsens startdato og -klokkeslæt 
— hændelsens slutdato og -klokkeslæt 
— korttype, kortnummer, udstedende 
medlemsstat og generation af kort, der 
er isat ved starten og/eller slutningen af 
hændelsen 
— antal tilsvarende hændelser den pågæl­
dende dag.  
▼B 
(1) Kontrolapparatet skal desuden registrere og i sit data­
lager gemme:  
— dato og klokkeslæt for seneste KONTROL FOR 
OVERSKRIDELSE AF TILLADT HASTIGHED  
— dato og klokkeslæt for første overskridelse af tilladt 
hastighed siden denne KONTROL FOR OVER­
SKRIDELSE AF TILLADT HASTIGHED  
— antal hændelser med overskridelse af tilladt 
hastighed siden seneste KONTROL FOR OVER­
SKRIDELSE AF TILLADT HASTIGHED.  
(2) Disse data kan kun registreres ved genetablering af 
strømforsyningen. Klokkeslæt kan kendes med en 
nøjagtighed på 1 minut.  
3.12.9  Data vedrørende fejl  
Med henblik på bestemmelserne i dette afsnit skal tiden registr eres 
med en opløsning på 1 sekund.  
118) For hver funden fejl skal kontrolapparatet registrere 
følgende data og gemme dem i datalageret i overensstem­
melse med følgende lagringsbestemmelser:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 49  
Fejl Lagringsbestemmelse  Data, som skal gemmes for hver hændelse  
Kortfejl  — de 10 seneste kortfejl for førerkortet  — startdato og -klokkeslæt for fejlen 
— slutdato og -klokkeslæt for fejlen 
— korttype, kortnummer, udstedende 
medlemsstat og generation  
Fejl ved kontrolapparatet  — de 10 seneste fejl af hver type fejl 
— den første fejl efter seneste kalibrering  — startdato og -klokkeslæt for fejlen 
— slutdato og -klokkeslæt for fejlen 
— fejltype 
— korttype, kortnummer og udstedende 
medlemsstat samt generation af kort, 
der er isat ved starten og/eller slutningen 
af fejlen.  
3.12.10  Kalibreringsdata  
119) Kontrolapparatet skal registrere og i sit datalager gemme 
data vedrørende:  
— kalibreringsparametre, som er kendte på aktiveringstids­
punktet  
— dets allerførste kalibrering efter aktivering  
— dets første kalibrering i det nuværende køretøj (identi­
ficeret ved sit VIN)  
— de 20 seneste kalibreringer (hvis der udføres flere kali­
breringer samme kalenderdag, skal kun den første og 
sidste heraf gemmes).  
120) Følgende data skal registreres for hver af disse 
kalibreringer:  
— kalibreringens formål (aktivering, første montering, 
montering, periodisk eftersyn)  
— værkstedets navn og adresse  
— værkstedskortets nummer, den kortudstedende 
medlemsstat og kortets udløbsdato  
— køretøjsidentifikation  
— parametre, som er ført ajour eller bekræftet: w, k, l, 
dækstørrelse, hastighedsbegrænserens indstilling, kilo­
meterstand (gammel og ny værdi), dato og klokkeslæt 
(gammel og ny værdi)  
— type og id for alle monterede plomber  
▼M3 
— serienumrene på bevægelsessensoren, eventuelt eksternt 
GNSS-udstyr og eventuelt eksternt fjernkommunika­
tionsudstyr  
— den lasttype, der som standard er knyttet til køretøjet 
(last af gods eller passagerer)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 50  
— det land, hvor kalibreringen er foretaget, og den dato og 
det klokkeslæt, hvor GNSS-modtageren leverede posi­
tionen til bestemmelse af dette land.  
▼B 
121) Derudover skal kontrolapparatet registrere og i sit datala ger 
gemme dets evne til at bruge takografkort af første genera­
tion (stadig aktiverede eller ej).  
122) Bevægelsessensoren skal registrere og i sit datalager 
gemme følgende data vedrørende bevægelsessensorens 
montering:  
— første parring med en køretøjsenhed (dato, klokkeslæt, 
køretøjsenhedens godkendelsesnummer og køretøjs­
enhedens serienummer)  
— sidste parring med en køretøjsenhed (dato, klokkeslæt, 
køretøjsenhedens godkendelsesnummer og køretøjs­
enhedens serienummer).  
123) Det eksterne GNSS-udstyr skal registrere og i sit datalage r 
gemme følgende monteringsdata vedrørende udstyret:  
— første sammenkobling med en køretøjsenhed (dato, 
klokkeslæt, køretøjsenhedens godkendelsesnummer og 
køretøjsenhedens serienummer)  
— sidste sammenkobling med en køretøjsenhed (dato, 
klokkeslæt, køretøjsenhedens godkendelsesnummer og 
køretøjsenhedens serienummer).  
3.12.11  Tidsjusteringsdata  
124) Kontrolapparatet skal registrere og i sit datalager gemme 
data af relevans for tidsjusteringer foretaget i kalibrerings­
tilstand, men ikke i forbindelse med regelmæssig kalibre­
ring (def. f)):  
— seneste justering af tidspunktet  
— de fem største tidsjusteringer  
125) Følgende data skal registreres for hver af disse 
tidsjusteringer:  
— dato og klokkeslæt, gammel værdi  
— dato og klokkeslæt, ny værdi  
— værkstedets navn og adresse  
— værkstedskortets nummer, den kortudstedende 
medlemsstat, kortgenerationen og kortets udløbsdato.  
3.12.12  Kontrolaktivitetsdata  
126) Kontrolapparatet skal registrere og i datalageret gemme 
følgende data vedrørende de 20 seneste kontrolaktiviteter:  
— kontroldato og -klokkeslæt  
— kontrolkortets nummer, den kortudstedende medlemsstat 
og kortgenerationen  
— kontrollens art (visning på skærm og/eller udskrivning 
og/eller dataoverførsel på køretøjsenhed og/eller data­
overførsel på kort og/eller kalibreringskontrol ved vejs­
iden).  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 51  
127) Ved dataoverførsel skal datoen for de ældste og de seneste  
overførte dage ligeledes registreres.  
3.12.13  Data vedrørende virksomhedslåse  
128) Kontrolapparatet skal registrere og i datalageret gemme da ta 
vedrørende de 255 seneste virksomhedslåse:  
— dato og klokkeslæt for lås-ind  
— dato og klokkeslæt for lås-ud  
— virksomhedskortets nummer, den kortudstedende 
medlemsstat og kortgenerationen  
— virksomhedens navn og adresse.  
Data, som tidligere er låst med en lås, der ikke længere 
findes i datalageret på grund af ovennævnte grænse, 
behandles som ikke-låst.  
3.12.14  Data vedrørende dataoverførselsaktivitet  
129) Kontrolapparatet skal registrere og i sit datalager gemme 
følgende data vedrørende den seneste dataoverførsel fra 
datalageret til eksterne medier, som fandt sted i virksom­
hedstilstand eller i kalibreringtilstand:  
— dato og klokkeslæt for dataoverførslen  
— virksomhedskortets eller værkstedskortets nummer, den 
kortudstedende medlemsstat og kortgenerationen  
— virksomhedens eller værkstedets navn.  
3.12.15  Data vedrørende særlige omstændigheder  
130) Kontrolapparatet skal registrere og i datalageret gemme 
følgende data vedrørende særlige omstændigheder:  
— indlæsningsdato og -klokkeslæt  
— den særlige omstændigheds art.  
131) Datalageret skal være i stand til at opbevare data vedrø­
rende særlige omstændigheder i mindst 365 dage (idet det 
forudsættes, at der i gennemsnit åbnes og lukkes en 
omstændighed dagligt). Når lagerpladsen er opbrugt, skal 
nye data erstatte de ældste data.  
3.12.16  Data vedrørende takografkort  
132) Kontrolapparatet skal kunne lagre følgende data vedrørende  
de forskellige takografkort, som er blevet anvendt i køre­
tøjsenheden:  
— takografens kortnummer og serienummer  
— fabrikanten af takografkortet  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 52  
— takografkortets type  
— takografkortets version.  
133) Kontrolapparatet skal kunne lagre mindst 88 sådanne 
poster.  
▼M3 
3.12.17  Grænsepassager  
133a) Kontrolapparatet skal registrere og lagre følgende oplys­
ninger om grænsepassager i sit datalager:  
— det land, som køretøjet forlader  
— det land, som køretøjet kører ind i  
— den position, hvor køretøjet har passeret grænsen.  
133b) Sammen med lande og positionen skal kontrolapparatet 
registrere og i sit datalager gemme:  
— kortnummer for fører og/eller medchauffør samt kortud­
stedende medlemsstat  
— kortgeneration  
— den tilhørende GNSS-nøjagtighed, dato og tid  
— et flag, der viser, om positionen er blevet ægtheds­
bekræftet  
— køretøjets kilometerstand på tidspunktet for registrering 
af grænsepassage.  
133c) Datalageret skal kunne opbevare disse data om grænsepas­
sage i mindst 365 dage.  
133d) Når lagerpladsen er opbrugt, skal nye data erstatte de 
ældste data.  
3.12.18  Laste-/losseoperationer  
133e) Kontrolapparatet skal registrere og lagre følgende oplys­
ninger om køretøjets laste- og losseoperationer i sit 
datalager:  
— operationstypen (lastning, losning eller samtidig last­
ning/losning),  
— den position, hvor laste- og losseoperationen fandt sted.  
133f) Hvis køretøjets position ikke oplyses af GNSS-modtageren 
på tidspunktet for laste-/losseoperationen, skal kontrolappa­
ratet bruge den seneste tilgængelige position og den tilhø­
rende dato og tid.  
133g) Sammen med operationstypen og positionen skal kontrol­
apparatet registrere og i sit datalager gemme:  
— kortnummer for fører og/eller medchauffør samt kortud­
stedende medlemsstat  
— kortgeneration  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 53  
— dato og klokkeslæt for laste-/losseoperationen  
— den tilhørende GNSS-nøjagtighed, dato og tid, hvis 
relevant.  
— et flag, der viser, om positionen er blevet ægtheds­
bekræftet  
— køretøjets kilometerstand.  
133h) Datalageret skal kunne opbevare oplysninger om 
laste-/losseoperationer i mindst 365 kalenderdage.  
133i) Når lagerpladsen er opbrugt, skal nye data erstatte de 
ældste data.  
3.12.19  Digitalt kort  
133j) Med henblik på registrering af køretøjets position ved 
passage af et lands grænse skal kontrolapparatet gemme 
et digitalt kort i sit datalager.  
133k) De tilladte digitale kort til støtte for kontrolapparatet s over­
vågning af grænsepassage stilles til rådighed af 
Europa-Kommissionen til overførsel fra et dedikeret sikret 
websted i forskellige formater.  
133l) For hvert af disse kort skal der være en versionsidentifi ­
kator og en hashværdi på webstedet.  
133m) Kortene skal indeholde:  
— et definitionsniveau svarende til NUTS 0-niveau ifølge 
nomenklaturen for statistiske regionale enheder  
— en skala på 1:1 million.  
133n) Takograffabrikanter skal vælge et kort fra webstedet og 
overføre det på en sikker måde.  
133o) Takograffabrikanter må kun anvende et kort, der er overfø rt 
fra webstedet, efter at de har verificeret dets integritet ved 
hjælp af kortets hashværdi.  
133p) Det valgte kort importeres i kontrolapparatet af fabrikan ten 
i et passende format, men semantikken på det importerede 
kort forbliver uændret.  
133q) Fabrikanten skal også lagre versionsidentifikatoren for d et 
kort, der bruges i kontrolapparatet.  
133r) Det lagrede digitale kort skal kunne opdateres eller erst attes 
af et nyt kort, det stilles til rådighed af Kommissionen.  
133s) Opdatering af digitale kort skal ske ved brug af de softw a­
reopdateringsmekanismer, fabrikanten har konfigureret, i 
overensstemmelse med krav 226d og 226e, således at 
kontrolapparatet kan kontrollere ægtheden og integriteten 
af et nyimporteret kort, inden det lagres og erstatter det 
eksisterende kort.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 54  
133t) Takograffabrikanter kan føje yderligere oplysninger til d et 
basiskort, der er omhandlet i krav 133m), til andre formål 
end registrering af grænsepassager, f.eks. EU-regionernes 
grænser, såfremt basiskortets semantik ikke ændres.  
▼B 
3.13 Læsning fra takografkort  
134) Kontrolapparatet skal i givet fald kunne læse de data fra 
takografkort af første og anden generation, som er nødven­
dige 
— til fastlæggelse af korttype, kortindehaver, tidligere 
anvendt køretøj, dato og klokkeslæt for seneste udtag­
ning af kort og den på det tidspunkt valgte aktivitet  
— til kontrol af, at seneste kortsession blev afsluttet 
korrekt  
▼M3 
— til beregning af førerens sammenhængende køretid, 
akkumulerede pausetid og akkumulerede køretider for 
den foregående og den aktuelle uge  
▼B 
— til at fremstille de nødvendige udskrifter vedrørende de 
data, som er registreret på et førerkort  
— til at overføre data fra et førerkort til eksterne medier.  
Dette krav gælder kun for takografkort af første generation, 
hvis brugen af dem ikke er blevet udelukket af et værksted.  
135) Ved eventuel læsefejl skal kontrolapparatet højst tre gang e 
forsøge at udføre samme læseordre, og derefter, hvis det 
stadig ikke er lykkedes, erklære kortet for defekt og 
ugyldigt.  
▼M3 
135a) Strukturen i applikationen »TACHO_G2« afhænger af 
versionen. Version 2-kort indeholder yderligere elementær­
filer i forhold til version 1-kort, herunder:  
— i fører- og værkstedskort:  
— Elementærfilen Places_Authentication skal inde­
holde status for ægthedsbekræftelse for de køretøjs­
positioner, der er lagret i elementærfilen Places. Der 
skal lagres et tidsstempel med hver status for 
ægthedsbekræftelse, som skal være nøjagtig det 
samme som det tidspunkt, der er gemt med den 
tilsvarende position i elementærfilen Places.  
— Elementærfilen GNSS_Places_Authentication skal 
indeholde status for ægthedsbekræftelse af de køre­
tøjspositioner, der er gemt i elementærfilen 
GNSS_Places. Der skal lagres et tidsstempel med 
hver status for ægthedsbekræftelse, som skal være 
nøjagtig det samme som det tidspunkt, der er gemt 
med den tilsvarende position i elementærfilen 
Places.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 55  
— Elementærfilen Border_Crossings, elementærfilen 
Load_Unload_Operations og elementærfilen 
Load_Type_Entries skal indeholde data vedrørende 
grænseovergange, laste-/losseoperationer og lasttyper.  
— i værkstedskort:  
— Elementærfilen Calibration_Add_Data skal inde­
holde supplerende kalibreringsdata ud over dem, 
der er lagret i elementærfilen Calibration. Den 
gamle dato- og klokkeslætværdi og køretøjets iden­
tifikationsnummer skal lagres med hver yderligere 
kalibreringsdatapost, som skal være præcist den 
samme som den gamle dato- og klokkeslætværdi 
og det køretøjsidentifikationsnummer, der er lagret 
med de tilsvarende kalibreringsdata i elementærfilen 
Calibration.  
— i alle takografkort:  
— Elementærfilen VU_Configuration skal indeholde 
kortindehaverens specifikke takografindstillinger.  
Køretøjsenheden skal ignorere en status for ægthedsbekræf­
telse i elementærfilen Places_Authentication eller elemen­
tærfilen GNSS_Places_Authentication, hvis der ikke findes 
en køretøjsposition med samme tidsstempel i elementær­
filen Places eller elementærfilen GNSS_Places.  
Køretøjsenheden skal ignorere elementærfilen VU_Confi­
guration i alle kort, for så vidt der ikke er fastsat særlige 
regler for anvendelsen af en sådan elementærfil. Disse 
regler skal fastsættes ved en ændring af bilag I C, som 
skal omfatte ændring eller sletning af dette punkt.  
▼B 
3.14 Registrering og lagring på takografkort  
3.14.1  Registrering og lagring på takografkort af første generation  
136) Forudsat at brug af takografkort af første generation ikke  er 
blevet udelukket af et værksted, skal kontrolapparatet regi­
strere og lagre data på nøjagtig samme måde som et 
kontrolapparat af første generation ville gøre.  
137) Kontrolapparatet skal sætte »kortsessionsdata« på fører- 
eller værkstedskort straks efter isætning af kortet.  
138) Kontrolapparatet skal ajourføre de data, som er gemt på 
gyldige fører-, værksteds-, virksomheds- og/eller kontrol­
kort, med alle de nødvendige data vedrørende den periode, 
hvor kortet er isat, og vedrørende kortindehaveren. De data, 
som gemmes på disse kort, er angivet i afsnit 4.  
139) Kontrolapparatet skal ajourføre de føreraktivitets- og ste d­
data (som foreskrevet i 4.5.3.1.9 og 4.5.3.1.11), som er 
gemt på gyldige fører- og/eller værkstedskort, med de 
aktivitets- og steddata, som indlæses manuelt af kortinde­
haveren.  
▼M3 
140) Hændelser og fejl, der ikke er defineret for kontrolappara ter 
af første generation, skal ikke lagres på fører- og værksteds­
kortene.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 56  
141) Ajourføring af takografkort skal ske ved, at seneste data 
erstatter ældste data i det nødvendige omfang og under 
hensyntagen til kortets faktiske lagringskapacitet.  
142) I tilfælde af læsefejl skal kontrolapparatet højst tre gan ge 
forsøge at udføre samme læseordre, og derefter, hvis det 
stadig ikke er lykkedes, erklære kortet for defekt og 
ugyldigt.  
▼M3 
143) Før et fører- eller værkstedskort frigives, og efter at al le 
relevante data er gemt på kortet, skal kontrolapparatet tilba­
gestille »kortsessionsdata«.  
▼B 
3.14.2  Registrering og lagring på takografkort af anden generation  
144) Takografkort af anden generation skal omfatte to forskelli ge 
kortapplikationer, hvoraf den ene skal være nøjagtig den 
samme som TACHO-applikationen for takografkort af 
første generation, og den anden — »TACHO_G2« — 
skal være som fastsat i kapitel 4 og tillæg 2.  
▼M3 
Strukturen i applikationen »TACHO_G2« afhænger af 
versionen. Version 2-kort indeholder yderligere elementær­
filer i forhold til version 1-kort.  
▼B 
145) Kontrolapparatet skal sætte »kortsessionsdata« på fører- 
eller værkstedskort straks efter isætning af kortet.  
146) Kontrolapparatet skal ajourføre de data, som er gemt på de  
to kortapplikationer for gyldige fører-, værksteds-, virksom­
heds- og/eller kontrolkort, med alle de nødvendige data 
vedrørende den periode, hvor kortet er isat, og vedrørende 
kortindehaveren. De data, som gemmes på disse kort, er 
angivet i afsnit 4.  
147) Kontrolapparatet skal ajourføre de data om førerens aktivi ­
tetssteder og -positioner (som foreskrevet i 4.5.3.1.9, 
4.5.3.1.11, 4.5.3.2.9 og 4.5.3.2.11), som er gemt på 
gyldige fører- og/eller værkstedskort, med de data om akti­
viteter og steder, som indlæses manuelt af kortindehaveren.  
▼M3 
147a) Ved isætning af et fører- eller værkstedskort skal kontro l­
apparatet gemme køretøjets standardlasttype på kortet.  
147b) Ved isætning af et fører- eller værkstedskort og efter 
manuel indlæsning skal kontrolapparatet kontrollere det 
sidste sted, hvor den daglige arbejdstid begynder eller 
slutter, som er gemt på kortet. Dette sted kan være midler­
tidigt som anført i krav 59. Hvis dette sted ligger i et andet 
land end det, hvor køretøjet befinder sig, skal kontrolappa­
ratet på kortet gemme en grænsepassage med:  
— det land, som køreren forlod: ikke tilgængelig  
— det land, som føreren kører ind i: det land, som køre­
tøjet aktuelt befinder sig i  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 57  
— dato og klokkeslæt for førerens passage af grænsen: 
tidspunktet for kortisætningen  
— førerens position ved grænsepassagen: ikke tilgængelig  
— køretøjets kilometerstand: ikke tilgængelig.  
▼B 
148) Ajourføring af takografkort skal ske ved, at seneste data 
erstatter ældste data i det nødvendige omfang og under 
hensyntagen til kortets faktiske lagringskapacitet.  
149) I tilfælde af læsefejl skal kontrolapparatet højst tre gan ge 
forsøge at udføre samme læseordre, og derefter, hvis det 
stadig ikke er lykkedes, erklære kortet for defekt og 
ugyldigt.  
150) Før et førerkort frigives, og efter at alle relevante data  er 
gemt på kortets to applikationer, skal kontrolapparatet tilba­
gestille »kortsessionsdata«.  
▼M3 
150a) Køretøjsenheden skal ignorere elementærfilen VU_Confi­
guration i alle kort, for så vidt der ikke er fastsat særlige 
regler for anvendelsen af en sådan elementærfil. Disse 
regler skal fastsættes ved en ændring af bilag I C, som 
skal omfatte ændring eller sletning af dette punkt.  
▼B 
3.15 Visning på skærm  
151) Skærmen skal have mindst 20 tegn.  
152) Der skal anvendes en mindste tegnstørrelse på 5 mm i 
højden og 3,5 mm i bredden.  
153) Skærmen skal understøtte de tegnsæt, der er angivet i till æg 
1, kapitel 4 »Tegnsæt«. Skærmen kan anvende forenklede 
tegn (f.eks. kan tegn med accent vises uden accent, eller 
små bogstaver kan vises som store).  
154) Skærmen skal være forsynet med tilstrækkelig ikkeblæn­
dende belysning.  
155) Anvisningerne skal kunne ses udefra i forhold til 
kontrolapparatet.  
156) Kontrolapparatet skal på skærmen kunne vise:  
— automatisk valgte værdier  
— data vedrørende advarselssignaler  
— data vedrørende adgang via menu  
— andre data, som en bruger ønsker.  
Kontrolapparatet kan på skærmen vise supplerende oplys­
ninger, forudsat at de tydeligt kan skelnes fra de ovenfor 
krævede oplysninger.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 58  
157) Kontrolapparatets skærm skal anvende de i tillæg 3 anførte  
piktogrammer eller piktogramkombinationer. Andre pikto­
grammer eller piktogramkombinationer kan anvendes af 
skærmen, hvis de tydeligt kan skelnes fra ovennævnte 
piktogrammer eller piktogramkombinationer.  
158) Skærmen skal altid være tændt, når køretøjet er i bevæ­
gelse.  
159) Kontrolapparatet kan have en manuel eller automatisk faci­
litet, som slukker for skærmen, når køretøjet ikke er i 
bevægelse.  
Skærmformatet er foreskrevet i tillæg 5.  
3.15.1  Standardskærmbillede  
160) Når ingen andre oplysninger behøver vises på skærmen, 
skal denne automatisk vise følgende:  
— lokaltid (som fremkommet af UTC-tid + forskydning 
som indstillet af fører)  
— funktionstilstand  
— aktuel føreraktivitet og aktuel medchaufføraktivitet  
— oplysninger vedrørende fører:  
— hvis den aktuelle aktivitet er KØRSEL, aktuel sammen­
hængende køretid og aktuel akkumuleret pausetid  
— hvis den aktuelle aktivitet ikke er KØRSEL, aktuel 
varighed af denne aktivitet (siden den valgtes), og 
aktuel akkumuleret pausetid.  
161) Data vedrørende de to chauffører skal på skærmen vises på 
en klar, enkel og utvetydig måde. Kan oplysningerne 
vedrørende fører og medchauffør ikke vises samtidig, skal 
kontrolapparatet automatisk vise oplysningerne vedrørende 
føreren og give brugeren mulighed for at se oplysningerne 
vedrørende medchaufføren.  
162) Giver skærmens bredde ikke mulighed for automatisk 
visning af funktionstilstand, skal kontrolapparatet kortvarigt 
vise den nye funktionstilstand, når den ændres.  
163) Ved isætning af kort skal kontrolapparatet kortvarigt vise  
korthaverens navn.  
164) Når omstændigheden »UDEN FOR GYLDIGHEDS­
OMRÅDE« eller »FÆRGE/TOG« åbnes, skal skærmen 
automatisk ved hjælp af det pågældende piktogram vise, 
at netop denne omstændighed er åbnet. (Det kan godtages, 
at den aktuelle føreraktivitet ikke nødvendigvis vises samti­
digt.)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 59  
3.15.2  Visning af advarsel  
165) Kontrolapparatet skal på skærmen vise oplysninger om 
advarselssignaler, hvilket hovedsagelig sker ved hjælp af 
piktogrammerne i tillæg 3, om nødvendigt suppleret med 
en talkode. Advarslen kan desuden gives som tekst på det 
af føreren foretrukne sprog.  
3.15.3  Adgang via menu  
166) Kontrolapparatet skal stille de nødvendige kommandoer til 
rådighed gennem en hensigtsmæssig menustruktur.  
3.15.4  Andre skærmbilleder  
167) På kommando skal skærmen selektivt kunne vise:  
— UTC-dato og -klokkeslæt og den lokale tidsforskydning  
▼M3 
— indholdet af de udskrifter, der er anført i krav 169, i 
samme format som selve udskrifterne  
▼B 
— førerens sammenhængende køretid og akkumulerede 
pausetid  
— medchaufførens sammenhængende køretid og akkumu­
lerede pausetid  
▼M3 
— førerens akkumulerede køretid for den foregående og 
den aktuelle uge  
— medchaufførens akkumulerede køretid for den foregå­
ende og den aktuelle uge  
▼B 
valgfrit:  
— aktuel varighed af medchaufførens aktivitet (siden den 
valgtes)  
▼M3 
— førerens akkumulerede køretid for den aktuelle uge  
— medchaufførens akkumulerede køretid for den aktuelle 
daglige arbejdstid  
— førerens akkumulerede køretid for den aktuelle daglige 
arbejdstid.  
▼B 
168) Visningen af udskriftens indhold skal være sekventiel, lin je 
for linje. Er skærmen mindre end 24 tegn bred, skal 
brugeren have adgang til de fuldstændige oplysninger 
gennem en passende menu (flere linjer, rulning …).  
Udskriftslinjer, som er afsat til håndskrevne oplysninger, 
kan udelades på skærmen.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 60  
3.16 Udskrivning  
169) Kontrolapparatet skal kunne udskrive oplysninger fra sit 
datalager og/eller fra takografkort i henhold til nedenstå­
ende syv udskriftstyper:  
— daglig udskrift af føreraktivitet fra kort  
— daglig udskrift af føreraktivitet fra køretøjsenhed  
— udskrift af hændelser og fejl fra kort  
— udskrift af hændelser og fejl fra køretøjsenhed  
— udskrift af tekniske data  
— udskrift af overskridelse af tilladt hastighed  
— takografkortdatahistorik for en given køretøjsenhed (se 
afsnit 3.12.16).  
Det nærmere format og indhold af disse udskrifter er 
angivet i tillæg 4.  
Yderligere data kan anføres sidst i udskrifterne.  
Kontrolapparatet kan stille yderligere udskriftstyper til 
rådighed, hvis de tydeligt kan skelnes fra de syv oven­
nævnte udskriftstyper.  
170) Der må ikke være adgang til »Daglig udskrift af førerakti­
viteter fra kort« og »Udskrift af hændelser og fejl fra kort«, 
medmindre der er indsat et fører- eller værkstedskort i 
kontrolapparatet. Før udskrivningen påbegyndes, skal 
kontrolapparatet ajourføre data gemt på det pågældende 
kort. 
171) For at hente »daglig udskrift af føreraktiviteter fra kort « 
eller »udskrift af hændelser og fejl fra kort« skal 
kontrolapparatet:  
— enten automatisk vælge fører- eller værkstedskort, hvis 
kun det ene af disse kort er isat,  
— eller stille en kommando til rådighed for valg af kilde­
kort eller valg af kortet i førerkortpladsen, hvis der er 
isat to af disse kort i kontrolapparatet.  
172) Printeren skal kunne udskrive 24 tegn pr. linje.  
173) Der skal anvendes en mindste tegnstørrelse på 2,1 mm i 
højden og 1,5 mm i bredden.  
174) Printeren skal understøtte de tegnsæt, der er angivet i ti llæg 
1, kapitel 4 »Tegnsæt«.  
175) Printeren skal være således udformet, at disse udskrifter er 
så tydelige, at der ikke er fare for fejllæsning.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 61  
176) De skal bevare deres format og deres registreringer under 
normale luftfugtigheds- (10-90 %) og temperaturforhold.  
177) Det typegodkendte papir, som anvendes i kontrolapparatet, 
skal være forsynet med det pågældende typegodkendelses­
mærke og angivelse af de(n) type(r) kontrolapparat(er), det 
kan anvendes i.  
178) Udskrifterne skal forblive letlæselige og identificerbare 
under normale opbevaringsforhold med hensyn til lysstyrke, 
fugtighed og temperatur i mindst to år.  
179) Udskrifter skal som minimum overholde testspecifikatio­
nerne i tillæg 9.  
180) Disse dokumenter skal kunne påføres håndskrevne påteg­
ninger, f.eks. førerens underskrift.  
181) Kontrolapparatet skal kunne håndtere »papir opbrugt«- 
hændelser under udskrivningen ved, efter isætning af nyt 
papir, at begynde forfra på udskrivningen eller fortsætte 
udskrivningen med en klar henvisning til den allerede 
udskrevne del.  
3.17 Advarsler  
182) Kontrolapparatet skal advare føreren, når det konstaterer en 
hændelse og/eller fejl.  
183) Det kan tillades, at advarsel om afbrydelse af strømfor­
syningen først finder sted, efter at strømforsyningen er 
genoprettet.  
184) Kontrolapparatet skal advare føreren, når den højeste 
tilladte sammenhængende køretid overskrides, samt 15 
minutter inden dette sker.  
185) Advarselssignaler skal være synlige. Akustiske advarsels­
signaler kan anvendes som supplement til synlige 
advarselssignaler.  
186) Synlige advarselssignaler skal være let genkendelige for 
brugeren, skal være placeret i førerens synsfelt og skal 
være letlæselige både ved dag og ved nat.  
187) Synlige advarselssignaler kan være indbygget i kontrol­
apparatet og/eller være placeret fjernt fra kontrolapparatet.  
188) I sidstnævnte tilfælde skal de være forsynet med symbolet 
»T«. 
189) Advarselssignaler skal have en varighed på mindst 30 
sekunder, medmindre brugeren kvitterer ved at trykke på 
en eller flere bestemte knapper i kontrolapparatet. Denne 
første kvittering må ikke slette det i næste afsnit omhand­
lede skærmbillede: Årsag til advarselssignal.  
190) Kontrolapparatets skærm skal vise årsagen til advarselssig ­
nalet og vedblive hermed, indtil brugeren kvitterer med en 
særlig kode eller kommando på kontrolapparatet.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 62  
191) Der kan afgives supplerende advarselssignaler, forudsat de  
ikke af føreren kan forveksles med de tidligere definerede.  
3.18 Dataoverførsel til eksterne medier  
192) Kontrolapparatet skal på kommando kunne overføre data 
fra sit lager eller fra et førerkort til eksterne lagermedier 
gennem kalibrerings- og dataoverførselsstikket. Før 
udskrivningen påbegyndes, skal kontrolapparatet ajourføre 
data gemt på det pågældende kort.  
▼M3 
193) Som en ikke obligatorisk facilitet kan kontrolapparatet 
desuden i enhver funktionstilstand overføre data til en virk­
somhed, hvis identitet er bekræftet gennem denne kanal, via 
en anden grænseflade. I så fald skal der for denne data­
overførsel gælde samme adgangsret til data som i 
virksomhedstilstand.  
▼B 
194) Overførslen må ikke ændre eller slette lagrede data.  
195) Den elektriske grænseflade for kalibrering/dataoverførsel er 
specificeret i tillæg 6.  
196) Dataoverførselsprotokoller er specificeret i tillæg 7.  
▼M3 
196a) En transportvirksomhed, der benytter køretøjer, som er 
udstyret med et kontrolapparat, der opfylder kravene i 
dette bilag og er omfattet af forordning (EF) nr. 561/2006, 
skal sikre, at alle data overføres fra køretøjsenheden og 
førerkortene.  
Den maksimale tidsfrist for overførsel af de relevante data 
må ikke overstige:  
— 90 dage for data fra køretøjsenheden  
— 28 dage for data fra førerkortet.  
196b) Transportvirksomheder skal opbevare de data, der overføre s 
fra køretøjsenheden og førerkortet, i mindst 12 måneder 
efter registreringen.  
▼B 
3.19 Fjernkommunikation i forbindelse med målrettede vejsidekon ­
troller  
197) Når køretøjet er sat i tænding, skal køretøjsenheden hvert  
60. sekund i faciliteten til fjernkommunikation lagre de 
seneste data, der er nødvendige for at foretage målrettede 
vejsidekontroller. Disse data skal krypteres og signeres som 
foreskrevet i tillæg 11 og 14.  
198) De data, der skal fjernkontrolleres, skal være tilgængelig e 
for fjernkommunikationslæsere via trådløs kommunikation 
som beskrevet i tillæg 14.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 63  
199) De data, der er nødvendige for at foretage målrettede vejs ­
idekontroller, skal vedrøre:  
— det seneste forsøg på sikkerhedsbrud  
— den længste afbrydelse af strømforsyning  
— sensorfejl  
— fejl ved køredata  
— køretøjsbevægelseskonflikt  
— kørsel uden gyldigt kort  
— isætning af kort under kørslen  
— tidsjusteringsdata  
— kalibreringsdata, herunder datoerne for de to senest 
lagrede kalibreringsposter  
— køretøjets indregistreringsnummer  
— hastighed registreret af takografen  
▼M3 
— køretøjets position  
— en angivelse, hvis føreren på nuværende tidspunkt 
muligvis overtræder køretiderne.  
3.20 Dataudveksling med yderligere eksterne enheder  
200) Kontrolapparatet skal også være udstyret med en ITS-græn­
seflade i overensstemmelse med tillæg 13, således at de 
data, der registreres eller produceres af takografen eller 
takografkortene, kan bruges af eksternt udstyr.  
I driftstilstand skal føreren give sit samtykke til overførsel 
af personoplysninger gennem ITS-interfacet. Førerens 
samtykke omfatter imidlertid ikke takograf- eller kortdata, 
der anvendes i kontrol-, virksomheds- eller kalibreringstil­
stand. Adgangsrettigheder til data og funktionelle i disse 
tilstande er anført i krav 12 og 13.  
Følgende krav gælder for ITS-data, der tilvejebringes via 
den pågældende grænseflade:  
— personoplysninger er kun tilgængelige, hvis der 
indhentes verificerbart samtykke fra føreren om, at 
vedkommendes personoplysninger må hentes ud af 
køretøjets net.  
Udvalgte eksisterende data, som kan være tilgængelige 
via ITS-interfacet, og klassificeringen af data som 
personlige eller ikke personlige, er omhandlet i tillæg 
13. Yderligere data kan også udlæses ud over de data, 
der er anført i tillæg 13. Fabrikanten af køretøjsenheden 
skal klassificere disse data som »personlige« eller »ikke 
personlige«, hvor førerens samtykke gælder for de data, 
der er klassificeret som »personlige«  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 64  
— dette samtykke kan til enhver tid gives eller trækkes 
tilbage ved hjælp af kommandoer i menuen, forudsat 
at førerkortet er isat.  
— Under ingen omstændigheder må ITS-interfacets tilste­
deværelse forstyrre eller påvirke køretøjsenhedens funk­
tionstilstand og sikkerhed.  
Der kan samtidig anvendes yderligere køretøjsenhedsgræn­
seflader, forudsat at de fuldt ud overholder minimumskra­
vene i tillæg 13 med hensyn til førerens samtykke. Kontrol­
apparatet skal kunne kommunikere førerens samtykkestatus 
til andre platforme i køretøjets net og til eksterne enheder.  
For personoplysninger, der er indlæst i køretøjets net, som 
viderebehandles uden for køretøjets net, er det ikke tako­
graffabrikantens ansvar, at personoplysningerne behandles i 
overensstemmelse med gældende EU-lovgivning om 
databeskyttelse.  
ITS-interfacet skal også give mulighed for dataindlæsning 
under proceduren for manuel indlæsning i overensstem­
melse med krav 61 for både fører og medchauffør.  
ITS-interfacet kan også anvendes til at indlæse yderligere 
oplysninger i realtid, f.eks.:  
— valg af føreraktivitet i overensstemmelse med krav 46  
— steder i overensstemmelse med krav 56  
— specifikke betingelser i overensstemmelse med krav 62  
— laste-/losseoperationer i overensstemmelse med krav 
62a. 
Disse oplysninger kan også indlæses via andre grænse­
flader.  
201) Den grænseflade til den serielle dataforbindelse, der er 
anført i bilag I B til forordning (EØF) nr. 3821/85 (med 
ændringer), kan fortsat anvendes i takografer for at sikre 
bagudkompatibilitet. Den serielle dataforbindelse er klassifi­
ceret som en del af køretøjets net i overensstemmelse med 
krav 200.  
▼B 
3.21 Kalibrering  
202) Kalibreringsfunktionen skal give mulighed for:  
— at samparre bevægelsessensoren automatisk med køre­
tøjsenheden  
— at sammenkoble det eksterne GNSS-udstyr automatisk 
med køretøjsenheden om nødvendigt  
— at tilpasse kontrolapparatets konstant (k) digitalt til 
køretøjets vejdrejetal (w)  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 65  
— at justere det aktuelle tidspunkt inden for gyldigheds­
perioden for det isatte værkstedskort  
— at justere den aktuelle kilometerstand  
— at opdatere datalagerets identifikationsdata for bevægel­
sessensoren  
— om nødvendigt at opdatere identifikationsdata for 
eksternt GNSS-udstyr, der er gemt i datalageret  
— at opdatere type og id for alle monterede plomber  
▼M3 
— at opdatere eller bekræfte andre parametre, som kontrol­
apparatet har kendskab til: køretøjsidentifikation, w, l, 
dækstørrelse, hastighedsbegrænserens indstilling (hvis 
relevant) og standardlasttype  
— automatisk at gemme det land, hvor kalibreringen er 
foretaget, og den dato og det klokkeslæt, hvor 
GNSS-modtageren leverede positionen til bestemmelse 
af dette land.  
▼B 
203) Endvidere skal kalibreringsfunktionen gøre det muligt at 
udelukke brug af takografkort af første generation i kontrol­
apparatet, forudsat at betingelserne i tillæg 15 er opfyldt.  
204) Samparring af bevægelsessensor med køretøjsenhed skal i 
det mindste omfatte følgende:  
— ajourføring af bevægelsessensorens monteringsdata, 
som opbevares af bevægelsessensoren (efter behov)  
— kopiering af de nødvendige data til identifikation af 
bevægelsessensoren fra føleren til køretøjsenhedens 
datalager.  
▼M3 
205) Sammenkobling af det eksterne GNSS-udstyr til køretøjs­
enheden skal som minimum bestå af:  
— opdatering af det eksterne GNSS-udstyrs monterings­
data, som opbevares af udstyret (efter behov)  
— kopiering af de nødvendige identifikationsdata for det 
eksterne GNSS-udstyr, herunder udstyrets serienummer, 
fra udstyret til køretøjsenhedens datalager.  
▼B 
206) Kalibreringsfunktionen skal kunne indlæse data gennem 
kalibrerings-/overførselsstikket i henhold til den i tillæg 8 
fastlagte kalibreringsprotokol. Kalibreringsfunktionen kan 
derudover indlæse de nødvendige data ved brug af andre 
midler.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 66  
3.22 Kalibreringskontrol ved vejsiden  
207) Funktionen til kalibreringskontrol ved vejsiden skal gøre 
det muligt at aflæse serienummeret på den bevægelses­
sensor (muligvis indlejret i adapteren) og (om nødvendigt) 
det eksterne GNSS-udstyr, der er forbundet til køretøjs­
enheden på tidspunktet for anmodningen.  
208) Denne aflæsning skal som minimum kunne foretages på 
køretøjsenhedens skærmbillede via kommandoer i 
menuerne.  
209) Funktionen til kalibreringskontrol ved vejsiden skal 
desuden gøre det muligt at styre valget af I/O-funktions­
tilstand for kalibrerings-I/O-signallinjen, som anført i tillæg  
6, via K-linjegrænsefladen. Dette skal ske gennem funk­
tionen ECUAdjustmentSession som beskrevet i tillæg 8, 
afsnit 7 »Styring af testimpulser — funktionsenhed for 
ind-/uddatastyring«.  
▼M3 
Når I/O-funktionstilstanden for kalibrerings-I/O-signallinjen 
er aktiv ifølge dette krav, udløses advarslen »Kørsel uden 
behørigt kort« (krav 75) ikke af køretøjsenheden.  
▼B 
3.23 Tidsjustering  
210) Tidsjusteringsfunktionen skal give mulighed for automatisk  
justering af det aktuelle klokkeslæt. I kontrolapparatet 
anvendes to kilder til tidsjustering, nemlig 1) køretøjsenhe­
dens interne ur og 2) GNSS-modtageren.  
▼M3 
211 Tidsindstillingen af køretøjsenhedens interne ur skal auto­
matisk justeres med variable intervaller. Den næste auto­
matiske tidsjustering udløses mellem 72 timer og 168 timer 
efter den foregående, og efter at køretøjsenheden kan få 
adgang til GNSS-tiden gennem en gyldig ægthedsbekræftet 
positionsmeddelelse i overensstemmelse med tillæg 12. 
Tidsjusteringen må imidlertid aldrig være større end den 
akkumulerede maksimale tidspunktdrift pr. dag som 
beregnet af køretøjsenhedens fabrikant i overensstemmelse 
med krav 41b. Hvis forskellen mellem klokkeslættet på 
køretøjsenhedens interne ur og klokkeslættet på 
GNSS-modtageren overstiger den akkumulerede maksimale 
tidspunktdrift pr. dag, skal tidsjusteringen bringe køretøjs­
enhedens interne ur så tæt som muligt på 
GNSS-modtagerens klokkeslæt. Tidsindstillingen må kun 
ske, hvis den tid, der leveres af GNSS-modtageren, er 
hentet fra ægthedsbekræftede positionsmeddelelser som 
fastsat i tillæg 12. Referencetidspunktet for den automatiske 
indstilling af køretøjsenhedens interne ur skal være klok­
keslættet i den ægthedsbekræftede positionsmeddelelse.  
212) Tidsjusteringsfunktionen skal også muliggøre hændelsesud­
løst justering af det aktuelle klokkeslæt i kalibreringstil­
stand.  
Værkstederne kan justere tiden:  
— ved at skrive en tidsværdi i køretøjsenheden ved hjælp 
af tjenesten WriteDataByIdentifier i overensstemmelse 
med afsnit 6.2 i tillæg 8  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 67  
— eller ved at anmode om en justering af køretøjsenhedens 
ur til den tid, der leveres af GNSS-modtageren. Dette 
må kun ske, hvis den tid, der leveres af 
GNSS-modtageren, er hentet fra ægthedsbekræftede 
positionsmeddelelser som fastsat i tillæg 12. I sidst­
nævnte tilfælde anvendes tjenesten RoutineControl i 
overensstemmelse med afsnit 8 i tillæg 8.  
▼B 
3.24 Funktionsspecifikationer  
213) Køretøjsenheden skal være helt driftsklar i temperatur­
området – 20 °C til 70 °C. For det eksterne GNSS-udstyr 
er temperaturområdet – 20 °C til 70 °C, og for bevægelses­
sensoren er temperaturområdet – 40 °C til 135 °C. Datala­
gerets indhold skal kunne opbevares ved temperaturer ned 
til – 40 °C.  
214) Takografen skal være fuldt funktionsdygtig i fugtigheds­
intervallet 10 % til 90 %.  
215) Plomberne i den intelligente takograf skal kunne tåle de 
samme forhold som de takografkomponenter, de er fastgjort 
til. 
216) Kontrolapparatet skal være beskyttet mod overspænding, 
omvendt polaritet af strømtilførslen samt kortslutning.  
217) Bevægelsessensorer skal  
— reagere på et magnetisk felt, som forstyrrer detekte­
ringen af køretøjets bevægelse. I dette tilfælde vil køre­
tøjsenheden registrere og gemme en fejl ved føler (krav 
88) 
— eller have et følerelement, som er beskyttet mod eller 
upåvirkelig af magnetiske felter.  
218) Kontrolapparatet og det eksterne GNSS-udstyr skal over­
holde bestemmelserne i det internationale regelsæt UN 
ECE R10 og være beskyttet mod elektrostatiske udlad­
ninger og spændingsvariationer.  
3.25 Materialer  
219) Alle kontrolapparatets komponenter skal være udført i 
materialer af tilstrækkelig stabilitet og mekanisk styrke 
samt med stabile elektriske og magnetiske egenskaber.  
220) Med henblik på normale driftsbetingelser skal alle appa­
ratets indvendige dele være beskyttet mod fugt og støv.  
221) Køretøjsenheden og det eksterne GNSS-udstyr skal opfylde 
beskyttelsesgrad IP 40, og bevægelsessensoren skal opfylde 
beskyttelsesgrad IP 64 i henhold til standard IEC 
60529:1989, herunder A1:1999 og A2:2013.  
222) Kontrolapparatet skal opfylde de pågældende tekniske 
forskrifter for ergonomisk udformning.  
223) Kontrolapparatet skal være beskyttet mod hændelig 
beskadigelse.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 68  
3.26 Mærkning  
224) Hvis kontrolapparatet viser køretøjets kilometerstand og 
hastighed på skærmen, skal følgende angivelser vises på 
skærmen:  
— ved det tal, som viser kilometerstanden, måleenheden 
angivet ved forkortelsen »km«  
— ved det tal, som angiver hastigheden, måleenheden 
»km/t«.  
Kontrolapparatet kan desuden være stillet om til at vise 
hastighed i miles per hour, i hvilket tilfælde hastigheds­
måleenheden skal være angivet ved forkortelsen »mph«. 
Kontrolapparatet kan desuden være stillet om til at vise 
afstand i miles, i hvilket tilfælde afstandsmåleenheden 
skal være angivet ved forkortelsen »mi«.  
▼M1 
225) På hver af kontrolapparatets separate komponenter skal 
være fastgjort et skilt med følgende oplysninger:  
— fabrikantens navn og adresse  
— fabrikantens reservedelsnummer og fremstillingsår  
— komponentens serienummer  
— typegodkendelsesmærke.  
226) Hvis der ikke er tilstrækkelig plads til at angive alle ov en­
nævnte oplysninger, skal skiltet i det mindste angive: fabri­
kantens navn eller mærke, og komponentens reservedels­
nummer.  
▼M3 
3.27 Overvågning af grænsepassager  
226a) Denne funktion registrerer, hvornår køretøjet har passere t et 
lands grænse, hvilket land det har forladt, og hvilket land 
det er kørt ind i.  
226b) Registreringen af grænsepassage baseres på den position, 
der er målt af kontrolapparatet, og det gemte digitale kort 
i overensstemmelse med punkt 3.12.19.  
226c) Grænsepassager i forbindelse med køretøjets tilstedeværel se 
i et land i en kortere periode end 120 sekunder registreres 
ikke.  
3.28 Softwareopdatering  
226d) Køretøjsenheden skal omfatte en funktion til implemente­
ring af softwareopdateringer, når sådanne opdateringer ikke 
kræver adgang til yderligere hardwareressourcer ud over de 
ressourcer, der er anført i krav 226f, og de typegodken­
dende myndigheder giver deres tilladelse til softwareopda­
teringerne baseret på den eksisterende typegodkendte køre­
tøjsenhed, i overensstemmelse med artikel 12, stk. 5, i 
forordning (EU) nr. 165/2014.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 69  
226e) Funktionen til softwareopdatering skal være udformet til at 
understøtte følgende funktionaliteter, når de er pålagt ved 
lov: 
— ændring af de funktioner, der er omhandlet i punkt 2.2, 
bortset fra selve softwareopdateringsfunktionen  
— tilføjelsen af nye funktioner, der er knyttet direkte til 
håndhævelsen af EU-lovgivningen om vejtransport  
— ændring af funktionstilstandene i punkt 2.3  
— ændring af filstrukturen, f.eks. tilføjelse af nye oplys­
ninger eller forøgelse af filstørrelsen  
— installation af softwarepakker for at afhjælpe software- 
og sikkerhedsproblemer eller rapporterede angreb på 
kontrolapparatets funktioner.  
226f) Køretøjsenheden skal sørge for ledige hardwareressourcer 
til mindst 35 % af den software og de data, der er nødven­
dige for at gennemføre krav 226e, og ledige hardwareres­
sourcer til mindst 65 % af opdateringen af det digitale kort 
baseret på de hardwareressourcer, der kræves til version 
2021 af NUTS 0-kortet.  
▼B 
4 KONSTRUKTIONS- OG FUNKTIONSKRAV TIL TAKOGRAF­
KORT  
4.1 Synlige data  
Forsiden skal indeholde:  
227) svarende til kortets art, ordet »Førerkort« eller »Kontrol ­
kort« eller »Værkstedskort« eller »Virksomhedskort«, 
trykt med store bogstaver på de(t) officielle sprog i den 
medlemsstat, som har udstedt kortet  
228) angivelse af navnet på den udstedende medlemsstat er valg­
frit 
229) den udstedende medlemsstats nationalitetsmærke, trykt med 
negativ skrift i et blåt rektangel og omgivet af 12 gule 
stjerner. Nationalitetsmærkerne er følgende: 
B 
BG 
CZ 
CY Belgien 
Bulgarien 
Den Tjekkiske Rep­
ublik 
Cypern  LV 
L 
LT 
M Letland 
Luxembourg 
Litauen 
Malta  
DK Danmark  N L  Nederlandene  
D 
EST Tyskland 
Estland  A 
PL Østrig 
Polen  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 70  
GR Grækenland  P  
RO 
SK 
SLO  Portugal 
Rumænien 
Slovakiet 
Slovenien  
E Spanien  FIN  Finland  
F 
HR 
H Frankrig 
Kroatien 
Ungarn  S Sverige  
IRL Irland  U K  Det Forenede Kon­
gerige  
I Italien  
230) oplysninger, der er specifikke for det udstedte kort, numm e­
reret som følger:  
Førerkort  Kontrolkort  Virksomheds- eller værksteds­
kort 
1. førerens efternavn  kontrolinstansens navn  virksomhedens eller værk­
stedets navn  
2. førerens fornavn(e)  den tilsynsførendes efter­
navn 
(hvis relevant)  kortindehaverens efternavn 
(hvis relevant)  
3. førerens fødselsdato  den tilsynsførendes forn­
avn(e) 
(hvis relevant)  kortindehaverens fornavn(e) 
(hvis relevant)  
4.a første dato i kortets gyldighedsperiode  
4.b kortets udløbsdato  
4.c den udstedende myndigheds navn (kan trykkes på bagsiden)  
4.d (evt.) nummer, der er forskelligt fra nummeret under punkt 5, til administrative formål  
5.a kørekortnummer 
(på udstedelsesdatoen for 
førerkortet)  — —  
5.b kortnummer  
6. fotografi af føreren  (evt.) fotografi af den tilsy­
nsførende  (evt.) fotografi af installa­
tøren  
7. (evt.) indehaverens underskrift  
8. (evt.) førerens sædvanlige 
bopæl eller postadresse  kontrolinstansens postad­
resse  virksomhedens eller værk­
stedets postadresse  
231) datoer skrives i formatet »dd/mm/yyyy« eller »dd.mm.yyyy« 
(dag, måned, år).  
Bagsiden skal indeholde:  
232) en forklaring til de nummererede punkter på kortets forsid e ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 71  
233) med indehaverens udtrykkelige skriftlige godkendelse kan 
der tilføjes data, som ikke har forbindelse med administra­
tionen af kortet; sådanne tilføjelser ændrer ikke på nogen 
måde modellens anvendelse som takografkort.  
234) Takografkort skal være trykt med følgende dominerende 
baggrundsfarve:  
— førerkort: hvid  
— kontrolkort: blå  
— værkstedskort: rød  
— virksomhedskort: gul.  
235) Takografkort skal have mindst følgende egenskaber til 
beskyttelse mod forfalskning og indgreb fra uvedkom­
mende:  
— sikkerhedsbaggrund med fint slangeornament og regn­
buetryk  
— i fotografiets område skal sikkerhedsbaggrund og foto­
grafi overlappe  
— mindst én tofarvet mikroprintlinje.
  
► (1) M1 
► (2) M3 
236) Medlemsstaterne kan efter at have rådført sig med Kommis­
sionen tilføje farve eller mærker som f.eks. nationale 
symboler og sikkerhedsdetaljer, uden at dette berører de 
øvrige bestemmelser i bilaget.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 72  
237) De midlertidige kort omhandlet i artikel 26, stk. 4, i for ord­
ning (EU) nr. 165/2014 skal overholde bestemmelserne i 
dette bilag.  
4.2 Sikkerhed  
Sikringen af systemet skal beskytte integritet og ægthed af dat a, som 
udveksles mellem kort og kontrolapparat, beskytte integritet og  
ægthed af data, som overføres fra kortene, bevirke, at visse sk rive­
procedurer på kortene er forbeholdt kontrolapparatet, dekrypter e 
bestemte data, udelukke forfalskning af data, som opbevares på 
kortene, forhindre indgreb fra uvedkommende og afsløre ethvert 
forsøg derpå.  
238) Af hensyn til systemets sikkerhed skal takografkortene 
opfylde sikkerhedsforskrifterne i tillæg 10 og 11.  
239) Takografkort skal kunne læses med andet udstyr som f.eks. 
pc'er.  
4.3 Standarder  
240) Takografkort skal være i overensstemmelse med følgende 
standarder:  
— ISO/IEC 7810 Identification cards — Physical charac­
teristics  
— ISO/IEC 7816 Identification cards — Integrated circuit 
cards:  
— Part 1: Physical characteristics  
— Part 2: Dimensions and position of the contacts 
(ISO/IEC 7816-2:2007)  
— Part 3: Electrical interface and transmission proto­
cols (ISO/IEC 7816-3:2006)  
— Part 4: Organisation, security and commands for 
interchange (ISO/IEC 7816-4:2013 + Cor 1:2014)  
— Part 6: Interindustry data elements for interchange 
(ISO/IEC 7816-6:2004 + Cor 1:2006)  
— Part 8: Commands for security operations (ISO/IEC 
7816-8:2004).  
— Takografkort skal afprøves i overensstemmelse med 
ISO/IEC 10373-3:2010 Identification cards — Test 
methods — Part 3: Integrated circuit cards with contacts 
and related interface devices.  
4.4 Miljømæssige og elektriske specifikationer  
241) Takografkort skal kunne fungere korrekt under alle de 
klimabetingelser, som normalt optræder på fællesskabets 
område, og det mindste i temperaturområdet – 25 °C til + 
70 °C med lejlighedsvise maksima på indtil + 85 °C, idet 
der ved »lejlighedsvis« forstås højst 4 timer ad gangen og 
højst 100 gange i løbet af kortets levetid.  
242) Takografkort skal fungere korrekt inden for luftfugtigheds ­
intervallet 10-90 %.  
243) Takografkort skal kunne fungere korrekt i fem år, hvis de 
anvendes i overensstemmelse med de miljømæssige og 
elektriske specifikationer.  
244) Under drift skal takografkort opfylde kravene i ECE R10 
om elektromagnetisk kompatibilitet og skal være beskyttet 
mod elektrostatiske udladninger.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 73  
4.5 Lagring af oplysninger  
Med henblik på bestemmelserne i dette afsnit  
— registreres klokkeslæt med en opløsning på 1 minut, medmindre  
andet er angivet  
— registreres kilometerstand med en opløsning på 1 kilometer  
— hastigheder registreres med en opløsning på 1 km/t  
— positioner (breddegrad og længdegrad) registreres i grader og  
minutter med en opløsning på 1/10 minut.  
Takografkortets funktioner, kommandoer og logiske strukturer, s om 
opfylder datalagringsbestemmelserne, er nærmere angivet i tillæ g 2. 
Medmindre andet anføres, skal datalagring på takografkort tilre tte­
lægges på en sådan måde, at nye data erstatter de ældste data, hvis 
den planlagte lagerplads til de pågældende poster er opbrugt.  
245) I dette afsnit fastsættes tilladelig mindste lagerkapacite t til 
applikationens forskellige datafiler. Takografkort skal til 
kontrolapparatet kunne angive den faktiske lagerkapacitet 
til disse datafiler.  
▼M3 
246) Yderligere data kan lagres på takografkort, såfremt lagrin g 
af disse data er i overensstemmelse med den gældende 
lovgivning om databeskyttelse.  
▼B 
247) Hver hovedfil (MF) på ethvert takografkort skal indeholde 
op til fem elementærfiler (EF) til kortstyring, anvendelse og 
identifikation af chip samt to dedikerede filer (DF):  
— DF Tachograph (dedikeret takograffil), som indeholder 
den applikation, der er tilgængelig for første generation 
af køretøjsenheder, og som også findes i takografkort af 
første generation  
— DF Tachograph_G2, som indeholder den applikation, 
der kun er tilgængelig for anden generation af køretøjs­
enheder, og som kun findes i takografkort af anden 
generation.  
▼M3 
Bemærk: version 2 af kort af anden generation indeholder 
yderligere elementære filer i den dedikerede fil Tacho­
graph_G2.  
▼B 
Nærmere oplysninger om takografkortets opbygning findes 
i tillæg 2.  
4.5.1  Elementærfiler til identifikation og kortstyring  
4.5.2  Identifikation af IC-kort  
248) Takografkort skal kunne lagre følgende data til identifika ­
tion af chipkort:  
— »clock stop«  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 74  
— kortets serienummer (herunder produktionshenvis­
ninger)  
— kortets typegodkendelsesnummer  
— identifikation af kortnavn (ID)  
— indlejrer-ID  
— IC-navn.  
4.5.2.1 I d e n t i f i k a t i o n a f c h i p  
249) Takografkort skal kunne lagre følgende data til identifika ­
tion af IC (IC = integreret kreds):  
— IC-serienummer  
— IC-produktionshenvisninger.  
4.5.2.2 D I R ( f i n d e s k u n i t a k o g r a f k o r t a f  a n d e n g e n e r a ­
t i o n )  
250) Takografkort skal kunne lagre de i tillæg 2 anførte data­
objekter til identifikation af applikationen.  
4.5.2.3 A T R - o p l y s n i n g e r ( b e t i n g e d e , f i  n d e s k u n i t a k o ­
g r a f k o r t a f a n d e n g e n e r a t i o n )  
251) Takografkort skal kunne lagre følgende dataobjekt med 
udvidet informationslængde:  
— det dataobjekt med udvidet informationslængde, der er 
anført i tillæg 2, hvis takografkortet understøtter felter 
med udvidet længde.  
4.5.2.4 O p l y s n i n g e r m e d u d v i d e t l æ n g d e (  b e t i n g e d e , 
f i n d e s k u n i t a k o g r a f k o r t a f a n d e n g e n  e r a t i o n )  
252) Takografkort skal kunne lagre følgende dataobjekter med 
udvidet informationslængde:  
— de dataobjekter med udvidet informationslængde, der er 
anført i tillæg 2, hvis takografkortet understøtter felter 
med udvidet længde.  
4.5.3  Førerkort  
4.5.3.1 T a k o g r a f a p p l i k a t i o n ( t i l g æ n g e  l i g f o r k ø r e t ø j s ­
e n h e d e r a f f ø r s t e o g a n d e n g e n e r a t i o n  ) 
4.5.3.1.1 Identifikation af applikation  
253) Førerkortet skal kunne lagre følgende data til identifikat ion 
af applikationen:  
— identifikation af takografapplikation  
— identifikation af takografkortets type.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 75  
4.5.3.1.2 Nøgler og certifikater  
254) Førerkortet skal kunne gemme en række kryptografiske 
nøgler og certifikater som præciseret i tillæg 11, del A.  
4.5.3.1.3 Identifikation af kort  
255) Førerkortet skal kunne lagre følgende data til identifikat ion 
af kortet:  
— kortnummer  
— udstedende medlemsstat, navn på udstedende myndighed, 
udstedelsesdato  
— startdato på kortets gyldighedsperiode, kortets udløbs­
dato.  
4.5.3.1.4 Identifikation af kortindehaver  
256) Førerkortet skal kunne lagre følgende data til identifikat ion 
af kortindehaver:  
— indehaverens efternavn  
— indehaverens fornavn(e)  
— fødselsdato  
— foretrukket sprog.  
4.5.3.1.5 Dataoverførsel på kort  
257) Førerkortet skal kunne lagre følgende data vedrørende data ­
overførsel på kort:  
— dato og klokkeslæt for seneste dataoverførsel på kort (til 
andre formål end kontrol).  
258) Førerkortet skal kunne opbevare én sådan post.  
4.5.3.1.6 Oplysninger om førerbevis  
259) Førerkortet skal kunne lagre følgende data vedrørende 
førerbevis:  
— udstedende medlemsstat, navn på udstedende 
myndighed  
— førerbevisets nummer (på kortets udstedelsesdato).  
4.5.3.1.7 Data vedrørende hændelser  
Med henblik på bestemmelserne i dette afsnit skal tiden registr eres 
med en opløsning på 1 sekund.  
260) Førerkortet skal kunne lagre data vedrørende følgende 
hændelser, som kontrolapparatet har detekteret, mens 
kortet var isat:  
— tidsoverlapning (når kortet er årsag til denne hændelse)  
— isætning af kort under kørslen (når kortet er genstand 
for denne hændelse)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 76  
— seneste kortsession ikke korrekt afsluttet (når kortet er 
genstand for denne hændelse)  
— afbrydelse i strømforsyningen  
— fejl ved køredata  
— forsøg på sikkerhedsbrud.  
261) Førerkortet skal kunne lagre følgende data vedrørende diss e 
hændelser:  
— hændelseskode  
— startdato og -klokkeslæt for hændelsen (eller for isæt­
ning af kortet, hvis dette fandt sted i hændelses­
perioden)  
— slutdato og -klokkeslæt for hændelsen (eller for udtag­
ning af kortet, hvis dette fandt sted i hændelses­
perioden)  
— VRN og den medlemsstat, som har indregistreret det 
køretøj, hvor hændelsen optrådte.  
Bemærk: For hændelsen »tidsoverlapning«  
— skal hændelsens startdato og -klokkeslæt svare til dato 
og klokkeslæt for udtagning af kortet fra det foregående 
køretøj  
— skal hændelsens slutdato og -klokkeslæt svare til dato 
og klokkeslæt for isætning af kortet i det aktuelle 
køretøj  
— skal køretøjsdata svare til det aktuelle køretøj, som 
giver anledning til hændelsen.  
Bemærk: For hændelsen »seneste kortsession ikke korrekt 
afsluttet«  
— skal hændelsens startdato og -klokkeslæt svare til dato 
og klokkeslæt for ukorrekt afslutning af sessionen  
— skal hændelsens slutdato og -klokkeslæt svare til dato 
og klokkeslæt for isætning af kortet ved den session, 
under hvilken hændelsen blev konstateret (den aktuelle 
session)  
— skal køretøjsdata svare til det køretøj, i hvilket 
sessionen ikke blev afsluttet korrekt  
262) skal førerkortet kunne lagre data for de seks senest optrå dte 
hændelser af hver type (dvs. 36 hændelser).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 77  
4.5.3.1.8 Data vedrørende fejl  
Med henblik på bestemmelserne i dette afsnit skal tiden registr eres 
med en opløsning på 1 sekund.  
263) Førerkortet skal kunne lagre data vedrørende følgende 
hændelser, som kontrolapparatet har detekteret, mens 
kortet var isat:  
▼M1 
— kortfejl (når kortet er genstand for fejlen)  
▼B 
— fejl ved kontrolapparat.  
264) Førerkortet skal kunne lagre følgende data vedrørende diss e 
hændelser:  
— fejlkode  
— startdato og -klokkeslæt for hændelsen (eller for isæt­
ning af kortet, hvis dette fandt sted inden for hændel­
sesperioden)  
— slutdato og -klokkeslæt for fejlen (eller for udtagning af 
kortet, hvis dette fandt sted inden for hændelses­
perioden)  
— VRN og den medlemsstat, som har indregistreret det 
køretøj, hvor fejlen optrådte.  
265) Førerkortet skal kunne lagre data for de tolv senest optrå dte 
hændelser af hver type (dvs. 24 hændelser).  
4.5.3.1.9 Føreraktivitetsdata  
266) Førerkortet skal kunne lagre følgende data for hver kalen­
derdag, hvor kortet har været anvendt, eller hvor føreren 
har indtastet aktiviteter manuelt:  
— dato  
— en tæller for daglig tilstedeværelse (øges med én for 
hver af de pågældende kalenderdage)  
— den samlede distance, som føreren har tilbagelagt det 
pågældende døgn  
— førerstatus kl. 00:00  
— samlet distance tilbagelagt af føreren den pågældende 
dag, hver gang føreren har skiftet aktivitet og/eller køre­
status og/eller har isat eller udtaget sit kort:  
— kørestatus (FØRERHOLD, ÉN FØRER)  
— kortplads (FØRER, MEDCHAUFFØR)  
— kortstatus (ISAT, IKKE ISAT)  
— aktivitet (KØRSEL, RÅDIGHED, ARBEJDE, 
PAUSE/HVILE)  
— tidspunkt for ændringen.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 78  
267) Førerkortets lager skal kunne opbevare data vedrørende 
førerens aktivitet i mindst 28 dage (gennemsnitsaktiviteten 
for en fører defineres som 93 aktivitetsskift pr. dag).  
268) De under forskrift 261, 264 og 266 angivne data skal opbe­
vares på en måde, som giver mulighed for at hente aktivi­
teterne i den rækkefølge, de har fundet sted, også når der er 
tidsmæssig overlapning.  
4.5.3.1.10 Data vedrørende anvendte køretøjer  
269) Førerkortet skal kunne lagre følgende data for hver kalen­
derdag, kortet er blevet anvendt, og for hver anvendelses­
periode for et givet køretøj den pågældende dag (en sådan 
periode omfatter alle på hinanden følgende cyklusser med 
isætning/udtagning af kortet i køretøjet, som det »ses« af 
kortet):  
— dato og klokkeslæt for første anvendelse af køretøjet 
(dvs. første kortisætning til denne anvendelsesperiode 
for køretøjet, eller 00:00, hvis det pågældende tidspunkt 
er inden for anvendelsesperioden)  
— køretøjets kilometerstand på det pågældende tidspunkt  
— dato og klokkeslæt for seneste anvendelse af køretøjet 
(dvs. første kortudtagning med henblik på denne anven­
delsesperiode for køretøjet, eller 23:59, hvis det pågæl­
dende tidspunkt er inden for anvendelsesperioden)  
— køretøjets kilometerstand på det pågældende tidspunkt  
— VRN og den indregistrerende medlemsstat.  
270) Førerkortet skal kunne lagre mindst 84 sådanne poster.  
4.5.3.1.11 Steder, hvor den daglige arbejdstid begynder og/elle r slutter  
271) Førerkortet skal kunne opbevare følgende data vedrørende 
de steder, hvor den daglige arbejdstid begynder og/eller 
slutter, og som er indlæst af føreren:  
— dato og klokkeslæt for indlæsningen (eller dato/klok­
keslæt knyttet til indlæsningen, når indlæsning fandt 
sted under den manuelle indlæsningsprocedure)  
— indlæsningens art (begyndelse eller slutning, omstæn­
dighed ved indlæsningen)  
— den indlæste stat og region  
— køretøjets kilometerstand.  
272) Førerkortets lager skal kunne rumme mindst 42 par poster 
af denne art.  
4.5.3.1.12 Kortsessionsdata  
273) Førerkortet skal kunne opbevare følgende data vedrørende 
det køretøj, som åbnede kortets aktuelle session:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 79  
— dato og klokkeslæt for åbning af sessionen (dvs. isæt­
ning af kort) med en opløsning på ét sekund  
— VRN og den indregistrerende medlemsstat.  
4.5.3.1.13 Kontrolaktivitetsdata  
274) Førerkortet skal kunne lagre følgende data vedrørende 
kontrolaktiviteter:  
— kontroldato og -klokkeslæt  
— kontrolkortets nummer og den kortudstedende 
medlemsstat  
— kontrollens art (visning og/eller udskrivning og/eller 
dataoverførsel på køretøjsenhed og/eller dataoverførsel 
på kort (se bemærkning))  
— ved dataoverførsel den overførte periode  
— køretøjets indregistreringsnummer og den medlemsstat, 
som har indregistreret det køretøj, hvor kontrollen fandt 
sted. 
Bemærk: dataoverførsel på kort vil kun blive registreret, 
hvis det sker gennem et kontrolapparat.  
275) Førerkortet skal kunne opbevare én sådan post.  
4.5.3.1.14 Data vedrørende særlige omstændigheder  
276) Førerkortet skal kunne opbevare følgende data vedrørende 
særlige omstændigheder, som er indlæst, mens kortet var 
isat (uanset i hvilken kortplads):  
— indlæsningsdato og -klokkeslæt  
— den særlige omstændigheds art.  
277) Førerkortet skal kunne lagre mindst 56 sådanne poster.  
▼M3 
4.5.3.2 T a k o g r a f a p p l i k a t i o n a f a n d e n g e  n e r a t i o n ( i k k e 
t i l g æ n g e l i g f o r k ø r e t ø j s e n h e d e r a f f  ø r s t e g e n e ­
r a t i o n , t i l g æ n g e l i g f o r v e r s i o n 1 o g v  e r s i o n 2 a f 
k ø r e t ø j s e n h e d e r a f a n d e n g e n e r a t i o n  ) 
▼B 
4.5.3.2.1 Identifikation af applikation  
278) Førerkortet skal kunne lagre følgende data til identifikat ion 
af applikationen:  
— identifikation af takografapplikation  
— identifikation af takografkortets type.  
▼M3 
4.5.3.2.1.1 Yderligere identifikation af applikation (anvendes ikke af version 1 
af køretøjsenheder af anden generation)  
278a) Førerkortet skal kunne lagre supplerende applikationsiden ­
tifikationsdata, der kun gælder for version 2.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 80  
4.5.3.2.2 Nøgler og certifikater  
279) Førerkortet skal kunne gemme en række kryptografiske 
nøgler og certifikater som præciseret i tillæg 11, del B.  
4.5.3.2.3 Identifikation af kort  
280) Førerkortet skal kunne lagre følgende data til identifikat ion 
af kortet:  
— kortnummer  
— udstedende medlemsstat, navn på udstedende 
myndighed, udstedelsesdato  
— startdato på kortets gyldighedsperiode, kortets udløbs­
dato.  
4.5.3.2.4 Identifikation af kortindehaver  
281) Førerkortet skal kunne lagre følgende data til identifikat ion 
af kortindehaver:  
— indehaverens efternavn  
— indehaverens fornavn(e)  
— fødselsdato  
— foretrukket sprog.  
4.5.3.2.5 Dataoverførsel på kort  
282) Førerkortet skal kunne lagre følgende data vedrørende data ­
overførsel på kort:  
— dato og klokkeslæt for seneste dataoverførsel på kort (til 
andre formål end kontrol).  
283) Førerkortet skal kunne opbevare én sådan post.  
4.5.3.2.6 Oplysninger om førerbevis  
284) Førerkortet skal kunne lagre følgende data vedrørende 
førerbevis:  
— udstedende medlemsstat, navn på udstedende 
myndighed  
— førerbevisets nummer (på kortets udstedelsesdato).  
4.5.3.2.7 Data vedrørende hændelser  
Med henblik på bestemmelserne i dette afsnit skal tiden registr eres 
med en opløsning på 1 sekund.  
285) Førerkortet skal kunne lagre data vedrørende følgende 
hændelser, som kontrolapparatet har detekteret, mens 
kortet var isat:  
— tidsoverlapning (når kortet er årsag til denne hændelse)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 81  
— isætning af kort under kørslen (når kortet er genstand 
for denne hændelse)  
— seneste kortsession ikke korrekt afsluttet (når kortet er 
genstand for denne hændelse)  
— afbrydelse i strømforsyningen  
— fejl ved kommunikation med faciliteten til fjernkommu­
nikation  
— manglende positionsoplysninger fra GNSS-modtager  
— fejl ved kommunikation med det eksterne GNSS-udstyr  
— fejl ved køredata  
— køretøjsbevægelseskonflikt  
— forsøg på sikkerhedsbrud  
— tidskonflikt.  
286) Førerkortet skal kunne lagre følgende data vedrørende diss e 
hændelser:  
— hændelseskode  
— startdato og -klokkeslæt for hændelsen (eller for isæt­
ning af kortet, hvis dette fandt sted i hændelses­
perioden)  
— slutdato og -klokkeslæt for hændelsen (eller for udtag­
ning af kortet, hvis dette fandt sted i hændelses­
perioden)  
— VRN og den medlemsstat, som har indregistreret det 
køretøj, hvor hændelsen optrådte.  
Bemærk: For hændelsen »tidsoverlapning«  
— skal hændelsens startdato og -klokkeslæt svare til dato 
og klokkeslæt for udtagning af kortet fra det foregående 
køretøj  
— skal hændelsens slutdato og -klokkeslæt svare til dato 
og klokkeslæt for isætning af kortet i det aktuelle 
køretøj  
— skal køretøjsdata svare til det aktuelle køretøj, som 
giver anledning til hændelsen.  
Bemærk: For hændelsen »seneste kortsession ikke korrekt 
afsluttet«  
— skal hændelsens startdato og -klokkeslæt svare til dato 
og klokkeslæt for ukorrekt afslutning af sessionen  
— skal hændelsens slutdato og -klokkeslæt svare til dato 
og klokkeslæt for isætning af kortet ved den session, 
under hvilken hændelsen blev konstateret (den aktuelle 
session)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 82  
— skal køretøjsdata svare til det køretøj, i hvilket 
sessionen ikke blev afsluttet korrekt  
▼M3 
287) Førerkortet skal kunne lagre data for de 12 seneste 
hændelser af hver type (dvs. 132 hændelser).  
▼B 
4.5.3.2.8 Data vedrørende fejl  
Med henblik på bestemmelserne i dette afsnit skal tiden registr eres 
med en opløsning på 1 sekund.  
288) Førerkortet skal kunne lagre data vedrørende følgende 
hændelser, som kontrolapparatet har detekteret, mens 
kortet var isat:  
▼M1 
— kortfejl (når kortet er genstand for fejlen)  
▼B 
— fejl ved kontrolapparat.  
289) Førerkortet skal kunne lagre følgende data vedrørende diss e 
hændelser:  
— fejlkode  
— startdato og -klokkeslæt for hændelsen (eller for isæt­
ning af kortet, hvis dette fandt sted inden for hændel­
sesperioden)  
— slutdato og -klokkeslæt for fejlen (eller for udtagning af 
kortet, hvis dette fandt sted inden for hændelses­
perioden)  
— VRN og den medlemsstat, som har indregistreret det 
køretøj, hvor fejlen optrådte.  
▼M3 
290) Førerkortet skal kunne lagre data for de 24 seneste fejl a f 
hver type (dvs. 48 fejl).  
▼B 
4.5.3.2.9 Føreraktivitetsdata  
291) Førerkortet skal kunne lagre følgende data for hver kalen­
derdag, hvor kortet har været anvendt, eller hvor føreren 
har indtastet aktiviteter manuelt:  
— dato  
— en tæller for daglig tilstedeværelse (øges med én for 
hver af de pågældende kalenderdage)  
— den samlede distance, som føreren har tilbagelagt det 
pågældende døgn  
— førerstatus kl. 00:00  
— samlet distance tilbagelagt af føreren den pågældende 
dag, hver gang føreren har skiftet aktivitet og/eller køre­
status og/eller har isat eller udtaget sit kort:  
— kørestatus (FØRERHOLD, ÉN FØRER)  
— kortplads (FØRER, MEDCHAUFFØR)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 83  
— kortstatus (ISAT, IKKE ISAT)  
— aktivitet (KØRSEL, RÅDIGHED, ARBEJDE, 
PAUSE/HVILE)  
— tidspunkt for ændringen.  
▼M3 
292) Førerkortets lager skal kunne opbevare data vedrørende 
førerens aktivitet i 56 dage (gennemsnitsaktiviteten for en 
fører defineres som 117 aktivitetsskift pr. dag).  
▼B 
293) De under forskrift 286, 289 og 291 angivne data skal opbe­
vares på en måde, som giver mulighed for at hente aktivi­
teterne i den rækkefølge, de har fundet sted, også når der er 
tidsmæssig overlapning.  
4.5.3.2.10 Data vedrørende anvendte køretøjer  
294) Førerkortet skal kunne lagre følgende data for hver kalen­
derdag, kortet er blevet anvendt, og for hver anvendelses­
periode for et givet køretøj den pågældende dag (en sådan 
periode omfatter alle på hinanden følgende cyklusser med 
isætning/udtagning af kortet i køretøjet, som det »ses« af 
kortet):  
— dato og klokkeslæt for første anvendelse af køretøjet 
(dvs. første kortisætning til denne anvendelsesperiode 
for køretøjet, eller 00:00, hvis det pågældende tidspunkt 
er inden for anvendelsesperioden)  
— køretøjets kilometerstand på det pågældende tidspunkt  
— dato og klokkeslæt for seneste anvendelse af køretøjet 
(dvs. første kortudtagning med henblik på denne anven­
delsesperiode for køretøjet, eller 23:59, hvis det pågæl­
dende tidspunkt er inden for anvendelsesperioden)  
— køretøjets kilometerstand på tidspunktet for seneste 
anvendelse  
— VRN og den indregistrerende medlemsstat  
— køretøjets VIN.  
▼M3 
295) Førerkortet skal kunne lagre 200 sådanne poster.  
▼B 
4.5.3.2.11 Steder og positioner, hvor den daglige arbejdstid be gynder og/eller 
slutter  
296) Førerkortet skal kunne opbevare følgende data vedrørende 
de steder, hvor den daglige arbejdstid begynder og/eller 
slutter, og som er indlæst af føreren:  
— dato og klokkeslæt for indlæsningen (eller dato/klok­
keslæt knyttet til indlæsningen, når indlæsning fandt 
sted under den manuelle indlæsningsprocedure)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 84  
— indlæsningens art (begyndelse eller slutning, omstæn­
dighed ved indlæsningen)  
— den indlæste stat og region  
— køretøjets kilometerstand  
— køretøjets position  
— GNSS-nøjagtigheden, dato og klokkeslæt for registre­
ring af positionen.  
▼M3 
297) Førerkortets hukommelse skal kunne lagre mindst 112 
sådanne poster.  
▼B 
4.5.3.2.12 Kortsessionsdata  
298) Førerkortet skal kunne opbevare følgende data vedrørende 
det køretøj, som åbnede kortets aktuelle session:  
— dato og klokkeslæt for åbning af sessionen (dvs. isæt­
ning af kort) med en opløsning på ét sekund  
— VRN og den indregistrerende medlemsstat.  
4.5.3.2.13 Kontrolaktivitetsdata  
299) Førerkortet skal kunne lagre følgende data vedrørende 
kontrolaktiviteter:  
— kontroldato og -klokkeslæt  
— kontrolkortets nummer og den kortudstedende 
medlemsstat  
— kontrollens art (visning og/eller udskrivning og/eller 
dataoverførsel på køretøjsenhed og/eller dataoverførsel 
på kort (se bemærkning))  
— ved dataoverførsel den overførte periode  
— køretøjets indregistreringsnummer og den medlemsstat, 
som har indregistreret det køretøj, hvor kontrollen fandt 
sted. 
Bemærk: Sikkerhedsforskrifterne indebærer, at dataover­
førsel på kort kun vil blive registreret, hvis det sker 
gennem et kontrolapparat.  
300) Førerkortet skal kunne opbevare én sådan post.  
4.5.3.2.14 Data vedrørende særlige omstændigheder  
301) Førerkortet skal kunne opbevare følgende data vedrørende 
særlige omstændigheder, som er indlæst, mens kortet var 
isat (uanset i hvilken kortplads):  
— indlæsningsdato og -klokkeslæt  
— den særlige omstændigheds art.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 85  
302) Førerkortet skal kunne lagre 112 sådanne poster.  
▼B 
4.5.3.2.15 Data vedrørende anvendte køretøjsenheder  
303) Førerkortet skal kunne lagre følgende data vedrørende de 
forskellige køretøjsenheder, som kortet er blevet brugt i:  
— dato og klokkeslæt for starten af køretøjsenhedens 
anvendelsesperiode (dvs. første isætning af kortet i 
køretøjsenheden i den pågældende periode)  
— fabrikanten af køretøjsenheden  
— køretøjsenhedens type  
— versionsnummeret på det programmel, der anvendes i 
køretøjsenheden.  
▼M3 
304) Førerkortet skal kunne lagre 200 sådanne poster.  
▼M1 
4.5.3.2.16 Data vedrørende den position, hvor tre timers kumule ret køretid nås  
305) Førerkortet skal kunne opbevare følgende data vedrørende 
køretøjets position, hvis den kumulerede køretid når op på 
et multiplum af tre timer:  
— dato og klokkeslæt, hvor den kumulerede køretid når op 
på et multiplum af tre timer  
— køretøjets position  
— GNSS-nøjagtigheden, dato og klokkeslæt for registre­
ring af positionen.  
— køretøjets kilometerstand.  
▼M3 
306) Førerkortet skal kunne lagre 336 sådanne poster.  
▼B 
4.5.3.2.17 Status for ægthedsbekræftelse for positioner, der ve drører steder, 
hvor den daglige arbejdstid begynder og/eller slutter (anvendes  
ikke af version 1 af køretøjsenheder af anden generation)  
306a) Førerkortet skal kunne opbevare yderligere data vedrørend e 
de steder, hvor den daglige arbejdstid begynder og/eller 
slutter, og som er indlæst af føreren i overensstemmelse 
med punkt 4.5.3.2.11:  
— dato og klokkeslæt for indlæsningen, som skal være 
nøjagtig det samme som det tidspunkt, der er gemt i 
elementærfilen Places under den dedikerede fil Tacho­
graph_G2  
— et flag, der viser, om positionen er blevet ægtheds­
bekræftet.  
306b) Førerkortets hukommelse skal kunne lagre 112 sådanne 
poster.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 86  
4.5.3.2.18 Status for ægthedsbekræftelse for positioner, hvor d er opnås tre 
timers akkumuleret køretid (anvendes ikke af version 1 af køret øjs­
enheder af anden generation)  
306c) Førerkortet skal kunne lagre yderligere data vedrørende 
køretøjets position, hvis den akkumulerede køretid når op 
på et multiplum af tre timer i overensstemmelse med punkt 
4.5.3.2.16:  
— dato og klokkeslæt, hvor den akkumulerede køretid når 
op på et multiplum af tre timer, som skal være nøjagtig 
det samme som det tidspunkt, der er gemt i elementær­
filen GNSS_Places under den dedikerede fil Tacho­
graph_G2  
— et flag, der viser, om positionen er blevet ægtheds­
bekræftet.  
306d) Førerkortet skal kunne lagre 336 sådanne poster.  
4.5.3.2.19 Grænsepassager (anvendes ikke af version 1 af køretø jsenheder af 
anden generation)  
306e) Førerkortet skal kunne lagre følgende data vedrørende 
grænsepassager efter kortisætning i overensstemmelse med 
krav 147b eller med kortet allerede isat:  
— det land, som køretøjet forlader  
— det land, som køretøjet kører ind i  
— dato og klokkeslæt for køretøjets passage af grænsen  
— køretøjets position ved grænsepassagen  
— GNSS-nøjagtigheden  
— et flag, der viser, om positionen er blevet ægtheds­
bekræftet  
— køretøjets kilometerstand.  
306f) Førerkortets hukommelse skal kunne lagre 1 120 sådanne 
poster.  
4.5.3.2.20 Laste-/losseoperationer (anvendes ikke af version 1 af køretøjs­
enheder af anden generation)  
306g) Førerkortet skal kunne lagre følgende data vedrørende 
laste-/losseoperationer:  
— operationstypen (lastning, losning eller samtidig last­
ning/losning)  
— dato og klokkeslæt for laste-/losseoperationen  
— køretøjets position  
— GNSS-nøjagtigheden, dato og klokkeslæt for registre­
ring af positionen.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 87  
— et flag, der viser, om positionen er blevet ægtheds­
bekræftet  
— køretøjets kilometerstand.  
306h) Førerkortet skal kunne lagre 1 624 laste-/losseoperatione r. 
4.5.3.2.21 Indlæsninger af lasttype (anvendes ikke af version 1  af køretøjs­
enheder af anden generation)  
306i) Førerkortet skal kunne lagre følgende data vedrørende las t­
type, som automatisk indlæses af køretøjsenheden ved hver 
kortisætning:  
— den indlæste lasttype (gods eller passagerer)  
— indlæsningsdato og -klokkeslæt.  
306j) Førerkortet skal kunne lagre 336 sådanne poster.  
4.5.3.2.22 Konfiguration af køretøjsenhed (anvendes ikke af ver sion 1 af køre­
tøjsenheder af anden generation)  
306k) Førerkortet skal kunne lagre kortindehaverens specifikke 
takografindstillinger.  
306l) Førerkortets kapacitet til lagring af kortindehaverens sp eci­
fikke takografindstillinger skal være på 3 072 byte.  
▼B 
4.5.4  Værkstedskort  
4.5.4.1 T a k o g r a f a p p l i k a t i o n ( t i l g æ n g e  l i g f o r k ø r e t ø j s ­
e n h e d e r a f f ø r s t e o g a n d e n g e n e r a t i o n  ) 
4.5.4.1.1 Identifikation af applikation  
307) Værkstedskortet skal kunne lagre følgende data til identif i­
kation af applikationen:  
— identifikation af takografapplikation  
— identifikation af takografkortets type.  
4.5.4.1.2 Nøgler og certifikater  
308) Værkstedskortet skal kunne gemme en række kryptogra­
fiske nøgler og certifikater som præciseret i tillæg 11, del 
A. 
309) Værkstedskortet skal kunne lagre et personligt identifika­
tionsnummer (en PIN-kode).  
4.5.4.1.3 Identifikation af kort  
310) Værkstedskortet skal kunne lagre følgende data til 
kortidentifikation:  
— kortnummer  
— udstedende medlemsstat, navn på udstedende 
myndighed, udstedelsesdato  
— startdato på kortets gyldighedsperiode, kortets udløbs­
dato. ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 88  
4.5.4.1.4 Identifikation af kortindehaver  
311) Værkstedskortet skal kunne lagre følgende data til identif i­
kation af kortindehaver:  
— værkstedets navn  
— værkstedets adresse  
— indehaverens efternavn  
— indehaverens fornavn(e)  
— foretrukket sprog.  
4.5.4.1.5 Dataoverførsel på kort  
312) Værkstedskortet skal kunne lagre data om dataoverførsel på  
kort på samme måde som et førerkort.  
4.5.4.1.6 Kalibrerings- og tidsjusteringsdata  
313) Værkstedskortet skal kunne opbevare poster vedrørende de 
kalibreringer og/eller tidsjusteringer, som er udført, mens 
kortet er indsat i et kontrolapparat.  
314) Hver kalibreringspost skal kunne indeholde følgende data:  
— kalibreringens formål (aktivering, første montering, 
montering, periodisk eftersyn)  
— identifikation af køretøjer  
— parametre, som er opdateret eller bekræftet (w, k, l, 
dækstørrelse, indstilling af hastighedsbegrænser, kilo­
metertæller (ny og gammel værdi), dato og klokkeslæt 
(ny og gammel værdi))  
— identifikation af kontrolapparatet (køretøjsenhedens 
reservedelsnummer, køretøjsenhedens serienummer).  
315) Værkstedskortet skal kunne lagre mindst 88 sådanne poster.  
316) Værkstedskortet skal have en tæller, som angiver det 
samlede antal kalibreringer, der er udført med kortet.  
317) Værkstedskortet skal have en tæller, som angiver det 
samlede antal kalibreringer, der er udført siden sidste data­
overførsel på kortet.  
4.5.4.1.7 Data vedrørende hændelser og fejl  
318) Værkstedskortet skal kunne lagre dataposter om hændelser 
og fejl på samme måde som et førerkort.  
319) Værkstedskortet skal kunne lagre data for de tre senest 
optrådte hændelser af hver type (dvs. 18 hændelser) og 
de tre senest optrådte fejl af hver type (dvs. 12 fejl).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 89  
4.5.4.1.8 Føreraktivitetsdata  
320) Værkstedskortet skal kunne lagre data om førerens aktivite t 
på samme måde som et førerkort.  
321) Værkstedskortet skal kunne lagre data om førerens aktivite t 
i mindst 1 dag med gennemsnitlig føreraktivitet.  
4.5.4.1.9 Data vedrørende anvendte køretøjer  
322) Værkstedskortet skal kunne lagre dataposter om anvendte 
køretøjer på samme måde som et førerkort.  
323) Værkstedskortet skal kunne lagre mindst 4 sådanne poster.  
4.5.4.1.10 Data vedrørende steder, hvor den daglige arbejdstid begynder 
og/eller slutter  
324) Værkstedskortet skal kunne lagre dataposter om den 
daglige arbejdstids begyndelse og/eller slutning på samme 
måde som et førerkort.  
325) Værkstedskortet skal kunne lagre mindst 3 par poster af 
denne art.  
4.5.4.1.11 Kortsessionsdata  
326) Værkstedskortet skal kunne lagre data om kortsessioner på 
samme måde som et førerkort.  
4.5.4.1.12 Kontrolaktivitetsdata  
327) Værkstedskortet skal kunne lagre data om kontrolaktivitet 
på samme måde som et førerkort.  
4.5.4.1.13 Data vedrørende særlige omstændigheder  
328) Værkstedskortet skal kunne lagre data vedrørende særlige 
omstændigheder på samme måde som et førerkort.  
329) Værkstedskortet skal kunne lagre mindst 2 sådanne poster.  
▼M3 
4.5.4.2 T a k o g r a f a p p l i k a t i o n a f a n d e n g e  n e r a t i o n ( i k k e 
t i l g æ n g e l i g f o r k ø r e t ø j s e n h e d e r a f f  ø r s t e g e n e ­
r a t i o n , t i l g æ n g e l i g f o r v e r s i o n 1 o g v  e r s i o n 2 a f 
k ø r e t ø j s e n h e d e r a f a n d e n g e n e r a t i o n  ) 
▼B 
4.5.4.2.1 Identifikation af applikation  
330) Værkstedskortet skal kunne lagre følgende data til identif i­
kation af applikationen:  
— identifikation af takografapplikation  
— identifikation af takografkortets type.  
▼M3 
4.5.4.2.1.1 Yderligere identifikation af applikation (anvendes ikke af version 1 
af køretøjsenheder af anden generation)  
330a) Værkstedskortet skal kunne lagre supplerende applikations ­
identifikationsdata, der kun gælder for version 2.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 90  
4.5.4.2.2 Nøgler og certifikater  
331) Værkstedskortet skal kunne gemme en række kryptogra­
fiske nøgler og certifikater som præciseret i tillæg 11, del 
B. 
332) Værkstedskortet skal kunne lagre et personligt identifika­
tionsnummer (en PIN-kode).  
4.5.4.2.3 Identifikation af kort  
333) Værkstedskortet skal kunne lagre følgende data til 
kortidentifikation:  
— kortnummer  
— udstedende medlemsstat, navn på udstedende 
myndighed, udstedelsesdato  
— startdato på kortets gyldighedsperiode, kortets udløbs­
dato.  
4.5.4.2.4 Identifikation af kortindehaver  
334) Værkstedskortet skal kunne lagre følgende data til identif i­
kation af kortindehaver:  
— værkstedets navn  
— værkstedets adresse  
— indehaverens efternavn  
— indehaverens fornavn(e)  
— foretrukket sprog.  
4.5.4.2.5 Dataoverførsel på kort  
335) Værkstedskortet skal kunne lagre data om dataoverførsel på  
kort på samme måde som et førerkort.  
4.5.4.2.6 Kalibrerings- og tidsjusteringsdata  
336) Værkstedskortet skal kunne opbevare poster vedrørende de 
kalibreringer og/eller tidsjusteringer, som er udført, mens 
kortet er indsat i et kontrolapparat.  
337) Hver kalibreringspost skal kunne indeholde følgende data:  
— kalibreringens formål (aktivering, første montering, 
montering, periodisk eftersyn)  
— køretøjsidentifikation  
— Parametre, som er opdateret eller bekræftet (w, k, l, 
dækstørrelse, indstilling af hastighedsbegrænser, kilo­
metertæller (ny og gammel værdi), dato og klokkeslæt 
(ny og gammel værdi))  
— identifikation af kontrolapparatet (køretøjsenhedens 
reservedelsnummer, køretøjsenhedens serienummer, 
bevægelsessensorens serienummer, serienummeret på 
faciliteten til fjernkommunikation og det eksterne 
GNSS-udstyrs serienummer, hvis relevant)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 91  
— type og id for alle monterede plomber  
— køretøjsenhedens mulighed for at bruge takografkort af 
første generation (uanset om det er aktiveret).  
▼M3 
338) Værkstedskortet skal kunne lagre 255 sådanne poster.  
▼B 
339) Værkstedskortet skal have en tæller, som angiver det 
samlede antal kalibreringer, der er udført med kortet.  
340) Værkstedskortet skal have en tæller, som angiver det 
samlede antal kalibreringer, der er udført siden sidste data­
overførsel på kortet.  
4.5.4.2.7 Data vedrørende hændelser og fejl  
341) Værkstedskortet skal kunne lagre dataposter om hændelser 
og fejl på samme måde som et førerkort.  
342) Værkstedskortet skal kunne lagre data for de tre senest 
optrådte hændelser af hver type (dvs. 33 hændelser) og 
de tre senest optrådte fejl af hver type (dvs. 12 fejl).  
4.5.4.2.8 Føreraktivitetsdata  
343) Værkstedskortet skal kunne lagre data om førerens aktivite t 
på samme måde som et førerkort.  
▼M3 
344) Værkstedskortet skal kunne lagre data om førerens aktivite t 
i mindst 1 dag med 240 aktivitetsskift.  
▼B 
4.5.4.2.9 Data vedrørende anvendte køretøjer  
345) Værkstedskortet skal kunne lagre dataposter om anvendte 
køretøjer på samme måde som et førerkort.  
▼M3 
346) Værkstedskortet skal kunne lagre 8 sådanne poster.  
4.5.4.2.10 Data vedrørende de steder og positioner, hvor den da glige arbejdstid 
begynder og/eller slutter  
347) Værkstedskortet skal kunne lagre dataposter om de steder 
og positioner, hvor den daglige arbejdstid begynder og/eller 
slutter, på samme måde som et førerkort.  
348) Værkstedskortet skal kunne lagre fire par af sådanne poste r. 
▼B 
4.5.4.2.11 Kortsessionsdata  
349) Værkstedskortet skal kunne lagre data om kortsessioner på 
samme måde som et førerkort.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 92  
4.5.4.2.12 Kontrolaktivitetsdata  
350) Værkstedskortet skal kunne lagre data om kontrolaktivitet 
på samme måde som et førerkort.  
4.5.4.2.13 Data vedrørende anvendte køretøjsenheder  
351) Værkstedskortet skal kunne lagre følgende data vedrørende 
de forskellige køretøjsenheder, som kortet er blevet brugt i:  
— dato og klokkeslæt for starten af køretøjsenhedens 
anvendelsesperiode (dvs. første isætning af kortet i 
køretøjsenheden i den pågældende periode)  
— fabrikanten af køretøjsenheden  
— køretøjsenhedens type  
— versionsnummeret på det programmel, der anvendes i 
køretøjsenheden.  
▼M3 
352) Værkstedskortet skal kunne lagre 8 sådanne poster.  
▼M1 
4.5.4.2.14 Data vedrørende den position, hvor tre timers kumule ret køretid nås  
353) Værkstedskortet skal kunne opbevare følgende data vedrø­
rende køretøjets position, hvis den kumulerede køretid når 
op på et multiplum af tre timer:  
— dato og klokkeslæt, hvor den kumulerede køretid når op 
på et multiplum af tre timer  
— køretøjets position  
— GNSS-nøjagtigheden, dato og klokkeslæt for registre­
ring af positionen.  
— køretøjets kilometerstand.  
▼M3 
354) Værkstedskortet skal kunne lagre 24 sådanne poster.  
▼B 
4.5.4.2.15 Data vedrørende særlige omstændigheder  
355) Værkstedskortet skal kunne lagre data vedrørende særlige 
omstændigheder på samme måde som et førerkort.  
▼M3 
356) Værkstedskortet skal kunne lagre 4 sådanne poster.  
4.5.4.2.16 Status for ægthedsbekræftelse for positioner, der ve drører steder, 
hvor den daglige arbejdstid begynder og/eller slutter (anvendes  
ikke af version 1 af køretøjsenheder af anden generation)  
356a) Værkstedskortet skal kunne lagre yderligere data om de 
steder, hvor den daglige arbejdstid begynder og/eller slutter, 
på samme måde som et førerkort.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 93  
356b) Værkstedskortets hukommelse skal kunne lagre fire par af 
sådanne poster.  
4.5.4.2.17 Status for ægthedsbekræftelse for positioner, hvor d er opnås tre 
timers akkumuleret køretid (anvendes ikke af version 1 af køret øjs­
enheder af anden generation)  
356c) Værkstedskortet skal kunne lagre yderligere data vedrø­
rende køretøjets position, hvis den akkumulerede køretid 
når op på et multiplum af tre timer, på samme måde som 
et førerkort.  
356d) Værkstedskortet skal kunne lagre 24 sådanne poster.  
4.5.4.2.18 Grænsepassager (anvendes ikke af version 1 af køretø jsenheder af 
anden generation)  
356e) Værkstedskortet skal kunne lagre data om grænsepassager 
på samme måde som et førerkort.  
356f) Værkstedskortets hukommelse skal kunne lagre fire 
sådanne poster.  
4.5.4.2.19 Laste-/losseoperationer (anvendes ikke af version 1 af køretøjs­
enheder af anden generation)  
356g) Værkstedskortet skal kunne lagre laste-/losseoperationern e 
på samme måde som et førerkort.  
356h) Værkstedskortet skal kunne lagre otte lasteoperationer, 
losseoperationer eller samtidige laste-/losseoperationer.  
4.5.4.2.20 Indlæsninger af lasttype (anvendes ikke af version 1  af køretøjs­
enheder af anden generation)  
356i) Værkstedskortet skal kunne lagre poster om lasttype på 
samme måde som et førerkort.  
356j) Værkstedskortet skal kunne lagre 4 sådanne poster.  
4.5.4.2.21 Yderligere kalibreringsdata (anvendes ikke af versio n 1 af køretøjs­
enheder af anden generation)  
356k) Værkstedskortet skal kunne lagre supplerende kalibrerings ­
data, der kun gælder for version 2:  
— Den gamle dato- og klokkeslætværdi og køretøjets iden­
tifikationsnummer, som skal være præcist de samme 
værdier som dem, der er lagret i elementærfilen Cali­
bration under den dedikerede fil Tachograph_G2  
— den standardlasttype, der er indlæst under denne kali­
brering  
— det land, hvor kalibreringen er foretaget, og det tids­
punkt, hvor GNSS-modtageren leverede positionen til 
bestemmelse af dette land.  
356l) Værkstedskortet skal kunne lagre 255 sådanne poster.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 94  
4.5.4.2.22 Konfiguration af køretøjsenhed (anvendes ikke af ver sion 1 af køre­
tøjsenheder af anden generation)  
356m) Værkstedskortet skal kunne lagre kortindehaverens speci­
fikke takografindstillinger.  
356n) Værkstedskortets kapacitet til lagring af kortindehaveren s 
specifikke takografindstillinger skal være på 3 072 byte.  
▼B 
4.5.5  Kontrolkort  
4.5.5.1 T a k o g r a f a p p l i k a t i o n ( t i l g æ n g e  l i g f o r k ø r e t ø j s ­
e n h e d e r a f f ø r s t e o g a n d e n g e n e r a t i o n  ) 
4.5.5.1.1 Identifikation af applikation  
357) Kontrolkortet skal kunne lagre følgende data til identifik a­
tion af applikationen:  
— identifikation af takografapplikation  
— identifikation af takografkortets type.  
4.5.5.1.2 Nøgler og certifikater  
358) Kontrolkortet skal kunne gemme en række kryptografiske 
nøgler og certifikater som præciseret i tillæg 11, del A.  
4.5.5.1.3 Identifikation af kort  
359) Kontrolkortet skal kunne lagre følgende data til 
kortidentifikation:  
— kortnummer  
— udstedende medlemsstat, navn på udstedende 
myndighed, udstedelsesdato  
— startdato på kortets gyldighedsperiode, kortets even­
tuelle udløbsdato.  
4.5.5.1.4 Identifikation af kortindehaver  
360) Kontrolkortet skal kunne lagre følgende data til identifik a­
tion af kortindehaveren:  
— kontrolinstansens navn  
— kontrolinstansens adresse  
— indehaverens efternavn  
— indehaverens fornavn(e)  
— foretrukket sprog.  
4.5.5.1.5 Kontrolaktivitetsdata  
361) Kontrolkortet skal kunne lagre følgende data vedrørende 
kontrolaktivitet:  
— kontroldato og -klokkeslæt  
▼M3 
— kontrollens art (visning og/eller udskrivning og/eller 
dataoverførsel på køretøjsenhed og/eller dataoverførsel 
på kort)  
▼B 
— eventuel periode, som er overført  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 95  
— køretøjets indregistreringsnummer og den indregistre­
rende myndighed i det kontrollerede køretøj  
— kontrolkortets nummer og den medlemsstat, som har 
udstedt det kontrollerede førerkort.  
362) Kontrolkortet skal kunne lagre mindst 230 sådanne poster.  
4.5.5.2 T a k o g r a f a p p l i k a t i o n a f a n d e n g e  n e r a t i o n ( i k k e 
t i l g æ n g e l i g f o r k ø r e t ø j s e n h e d e r a f f  ø r s t e g e n e ­
r a t i o n )  
4.5.5.2.1 Identifikation af applikation  
363) Kontrolkortet skal kunne lagre følgende data til identifik a­
tion af applikationen:  
— identifikation af takografapplikation  
— identifikation af takografkortets type.  
▼M3 
4.5.5.2.1.1 Yderligere identifikation af applikation (anvendes ikke af version 1 
af køretøjsenheder af anden generation)  
363a) Kontrolkortet skal kunne lagre supplerende applikations­
identifikationsdata, der kun gælder for version 2.  
▼B 
4.5.5.2.2 Nøgler og certifikater  
364) Kontrolkortet skal kunne gemme en række kryptografiske 
nøgler og certifikater som præciseret i tillæg 11, del B.  
4.5.5.2.3 Identifikation af kort  
365) Kontrolkortet skal kunne lagre følgende data til 
kortidentifikation:  
— kortnummer  
— udstedende medlemsstat, navn på udstedende 
myndighed, udstedelsesdato  
— startdato på kortets gyldighedsperiode, kortets even­
tuelle udløbsdato.  
4.5.5.2.4 Identifikation af kortindehaver  
366) Kontrolkortet skal kunne lagre følgende data til identifik a­
tion af kortindehaveren:  
— kontrolinstansens navn  
— kontrolinstansens adresse  
— indehaverens efternavn  
— indehaverens fornavn(e)  
— foretrukket sprog.  
4.5.5.2.5 Kontrolaktivitetsdata  
367) Kontrolkortet skal kunne lagre følgende data vedrørende 
kontrolaktivitet:  
— kontroldato og -klokkeslæt  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 96  
— kontrollens art (visning på skærm og/eller udskrivning 
og/eller dataoverførsel på køretøjsenhed og/eller data­
overførsel på kort og/eller kalibreringskontrol ved vejs­
iden)  
— eventuel periode, som er overført  
— køretøjets indregistreringsnummer og den indregistre­
rende myndighed i det kontrollerede køretøj  
— kontrolkortets nummer og den medlemsstat, som har 
udstedt det kontrollerede førerkort.  
368) Kontrolkortet skal kunne lagre mindst 230 sådanne poster.  
▼M3 
4.5.5.2.6 Konfiguration af køretøjsenhed (anvendes ikke af vers ion 1 af køre­
tøjsenheder af anden generation)  
368a) Kontrolkortet skal kunne lagre kortindehaverens specifikk e 
takografindstillinger.  
368b) Kontrolkortets kapacitet til lagring af kortindehaverens 
specifikke takografindstillinger skal være på 3 072 byte.  
▼B 
4.5.6  Virksomhedskort  
4.5.6.1 T a k o g r a f a p p l i k a t i o n ( t i l g æ n g e  l i g f o r k ø r e t ø j s ­
e n h e d e r a f f ø r s t e o g a n d e n g e n e r a t i o n  ) 
4.5.6.1.1 Identifikation af applikation  
369) Virksomhedskortet skal kunne lagre følgende data til iden­
tifikation af applikationen:  
— identifikation af takografapplikation  
— identifikation af takografkortets type.  
4.5.6.1.2 Nøgler og certifikater  
370) Virksomhedskortet skal kunne gemme en række kryptogra­
fiske nøgler og certifikater som præciseret i tillæg 11, del 
A. 
4.5.6.1.3 Identifikation af kort  
371) Virksomhedskortet skal kunne lagre følgende data til 
kortidentifikation:  
— kortnummer  
— udstedende medlemsstat, navn på udstedende 
myndighed, udstedelsesdato  
— startdato på kortets gyldighedsperiode, kortets even­
tuelle udløbsdato.  
4.5.6.1.4 Identifikation af kortindehaver  
372) Virksomhedskortet skal kunne lagre følgende data til iden­
tifikation af kortindehaveren:  
— virksomhedens navn  
— virksomhedens adresse.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 97  
4.5.6.1.5 Virksomhedsaktivitetsdata  
373) Virksomhedskortet skal kunne lagre følgende 
virksomhedsaktivitetsdata:  
— dato og klokkeslæt for aktiviteten  
— aktivitetens art (låse ind/ud på køretøjsenhed og/eller 
dataoverførsel på køretøjsenhed og/eller dataoverførsel 
på kort)  
— eventuel periode, som er overført  
— køretøjets indregistreringsnummer og den myndighed, 
som har registreret det  
— kortets nummer og den kortudstedende medlemsstat 
(ved dataoverførsel på kort).  
374) Virksomhedskortet skal kunne opbevare mindst 230 
sådanne poster.  
4.5.6.2 T a k o g r a f a p p l i k a t i o n a f a n d e n g e  n e r a t i o n ( i k k e 
t i l g æ n g e l i g f o r k ø r e t ø j s e n h e d e r a f f  ø r s t e g e n e ­
r a t i o n )  
4.5.6.2.1 Identifikation af applikation  
375) Virksomhedskortet skal kunne lagre følgende data til iden­
tifikation af applikationen:  
— identifikation af takografapplikation  
— identifikation af takografkortets type.  
▼M3 
4.5.6.2.1.1 Yderligere identifikation af applikation (anvendes ikke af version 1 
af køretøjsenheder af anden generation)  
375a) Virksomhedskortet skal kunne lagre supplerende applika­
tionsidentifikationsdata, der kun gælder for version 2.  
▼B 
4.5.6.2.2 Nøgler og certifikater  
376) Virksomhedskortet skal kunne gemme en række kryptogra­
fiske nøgler og certifikater som præciseret i tillæg 11, del 
B. 
4.5.6.2.3 Identifikation af kort  
377) Virksomhedskortet skal kunne lagre følgende data til 
kortidentifikation:  
— kortnummer  
— udstedende medlemsstat, navn på udstedende 
myndighed, udstedelsesdato  
— startdato på kortets gyldighedsperiode, kortets even­
tuelle udløbsdato.  
4.5.6.2.4 Identifikation af kortindehaver  
378) Virksomhedskortet skal kunne lagre følgende data til iden­
tifikation af kortindehaveren:  
— virksomhedens navn  
— virksomhedens adresse.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 98  
4.5.6.2.5 Virksomhedsaktivitetsdata  
379) Virksomhedskortet skal kunne lagre følgende 
virksomhedsaktivitetsdata:  
— dato og klokkeslæt for aktiviteten  
— aktivitetens art (låse ind/ud på køretøjsenhed og/eller 
dataoverførsel på køretøjsenhed og/eller dataoverførsel 
på kort)  
— eventuel periode, som er overført  
— køretøjets indregistreringsnummer og den myndighed, 
som har registreret det  
— kortets nummer og den kortudstedende medlemsstat 
(ved dataoverførsel på kort).  
380) Virksomhedskortet skal kunne opbevare mindst 230 
sådanne poster.  
▼M3 
4.5.6.2.6 Konfiguration af køretøjsenhed (anvendes ikke af vers ion 1 af køre­
tøjsenheder af anden generation)  
380a) Virksomhedskortet skal kunne lagre kortindehaverens 
specifikke takografindstillinger.  
380b) Virksomhedskortets kapacitet til lagring af kortindehaver ens 
specifikke takografindstillinger skal være på 3 072 byte.  
▼B 
5 MONTERING AF KONTROLAPPARATET  
5.1 Montering  
381) Nye kontrolapparater skal leveres i ikke-aktiveret stand t il 
installatører eller køretøjsfabrikanter, med alle de i afsnit 
3.21 opregnede kalibreringsparametre sat til hensigtsmæs­
sige og gyldige standardværdier. Når ingen særlig værdi er 
passende, sættes strengparametre til værdien »?« og talpa­
rametre til »0«. Levering af sikkerhedsrelevante dele til 
kontrolapparatet kan om nødvendigt begrænses under 
sikkerhedscertificeringen.  
382) Inden kontrolapparatet er aktiveret, skal kontrolapparatet  
give adgang til kalibreringsfunktionen, også når det ikke 
er i kalibreringstilstand.  
▼M3 
383) Før kontrolapparatet er aktiveret, må det hverken registre re 
eller lagre de i krav 102-133, inkl., omhandlede data. Før 
kontrolapparatet er aktiveret, må det dog registrere og lagre 
hændelser i forbindelse med forsøg på sikkerhedsbrud i 
overensstemmelse med krav 117 og kontrolapparatets fejl 
i overensstemmelse med krav 118.  
▼B 
384) Under monteringen skal køretøjets fabrikant forudindstille  
alle parametre, som kendes.  
385) Køretøjsfabrikant eller -installatør skal senest aktivere det 
monterede kontrolapparat, før køretøjet anvendes inden for 
anvendelsesområdet for forordning (EF) nr. 561/2006.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 99  
386) Kontrolapparatet skal automatisk aktiveres ved første isæt ­
ning af et gyldigt værkstedskort i en af dets kortlæsere.  
387) Eventuelle nødvendige særlige samparringsprocedurer 
mellem bevægelsessensor og køretøjsenhed skal udføres 
automatisk før eller under aktivering.  
388) Ligeledes skal eventuelle særlige sammenkoblingspro­
cedurer mellem eksternt GNSS-udstyr og køretøjsenhed 
udføres automatisk før eller under aktivering.  
389) Når kontrolapparatet er blevet aktiveret, skal det fuldt u d 
håndhæve funktioner og adgangsret til data.  
390) Efter aktivering af kontrolapparatet skal dette sende de 
sikrede data, der er nødvendige for at foretage målrettede 
vejsidekontroller, til faciliteten til fjernkommunikation.  
391) Kontrolapparatets registrerings- og lagringsfunktioner ska l 
være fuldt funktionsdygtige efter første aktivering af 
apparatet.  
▼M3 
392) Monteringen skal efterfølges af en kalibrering. Den første  
kalibrering skal ikke nødvendigvis omfatte indlæsning af 
køretøjets indregistreringsnummer (VRN og medlemsstat), 
hvis det godkendte værksted, som skal foretage kalibre­
ringen, ikke kender det. I så fald skal ejeren af køretøjet 
have mulighed for at indlæse indregistreringsnummeret og 
medlemsstaten ved hjælp af virksomhedskortet, før køre­
tøjet anvendes inden for anvendelsesområdet for forordning 
(EF) nr. 561/2006 (f.eks. ved at anvende kommandoer ved 
hjælp af en passende menustruktur i køretøjsenhedens 
menneske-maskine-grænseflade), og kun på det tidspunkt. 
Det må kun være muligt at opdatere eller bekræfte denne 
indlæsning ved hjælp af et værkstedskort.  
▼B 
393) Ved montering af eksternt GNSS-udstyr skal dette kobles 
sammen med køretøjsenheden, og efterfølgende skal 
GNSS-positionsoplysningerne kontrolleres.  
394) Kontrolapparatet skal være anbragt på en sådan måde i 
køretøjet, at føreren har adgang til de nødvendige funktio­
ner fra førersædet.  
5.2 Installationsplade  
395) ►M3 Når apparatet er blevet kontrolleret efter monte­
ringen, anbringes en installationsplade med permanent 
indgravering eller tryk klart synligt og lettilgængeligt på 
kontrolapparatet. Hvis dette ikke er muligt, skal pladen fast­
gøres til køretøjets »B«-søjle, så den er klart synlig. I køre­
tøjer, som ikke har en »B«-søjle, skal installationspladen 
fastgøres på køretøjets dørflade og være klart synlig 
under alle omstændigheder. ◄  
Efter ethvert indgreb foretaget af en autoriseret installatør 
eller et autoriseret værksted skal installationspladen 
udskiftes med en ny plade.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 100  
396) Pladen skal være forsynet med mindst følgende oplys­
ninger:  
— den autoriserede installatørs eller det autoriserede værk­
steds navn og adresse eller firmanavn  
— køretøjets vejdrejetal efter formlen »w = … imp/km«  
— kontrolapparatets konstant, angivet ved »k = … 
imp/km«  
— effektiv dækperiferi i formen »l = … mm«  
— dækstørrelse  
— datoen for måling af køretøjets vejdrejetal og dets effek­
tive dækperiferi  
— køretøjets identifikationsnummer  
— om der forefindes eksternt GNSS-udstyr  
— serienummeret på det eksterne GNSS-udstyr, hvis rele­
vant 
▼M3 
— serienummeret på udstyret til fjernkommunikation, hvis 
relevant  
▼M1 
— serienummeret på alle monterede plomber  
— den del af køretøjet, hvor adapteren i givet fald er 
installeret  
— den del af køretøjet, hvor bevægelsessensoren er instal­
leret, hvis den ikke er sluttet til gearkassen, eller der 
ikke anvendes en adapter  
— en angivelse af farven på kablet mellem adapteren og 
den del af køretøjet, der forsyner denne med impulser  
— serienummeret på adapterens indlejrede bevægelses­
sensor.  
▼M3 
— den lasttype, der som standard er knyttet til køretøjet.  
▼B 
397) Der kan udelukkende i forbindelse med M1- og N1-køre­
tøjer, som er forsynet med en adapter i henhold til 
Kommissionens forordning (EF) nr. 68/2009 (  1 ) med 
seneste ændringer, og hvor det ikke er muligt at anføre 
alle de nødvendige oplysninger som beskrevet i krav 396, 
anvendes en anden, supplerende plade. I så fald skal den 
supplerende plade indeholde mindst de sidste fire led i krav 
396. ▼M1 
( 1 ) Kommissionens forordning (EF) Nr. 68/2009 af 23. januar 2009 om niende tilpasning til 
den tekniske udvikling af Rådets forordning (EØF) nr. 3821/85 o m kontrolapparatet 
inden for vejtransport (EUT L 21 af 24.1.2009, s. 3).
 02016R0799 — DA — 21.08.2023 — 003.001 — 101  
Denne anden, supplerende plade anbringes, hvis den 
anvendes, ved siden af den første primære plade, som er 
beskrevet i krav 396, og skal have det samme beskyttelses­
niveau. Endvidere skal der på den sekundære plade også 
være anført navn, adresse eller firmanavn på den autorise­
rede installatør eller det autoriserede værksted, som har 
udført monteringen, samt monteringsdatoen.  
5.3 Plombering  
398) Følgende dele skal være plomberet:  
— enhver tilslutning, hvis afbrydelse medfører uopdagede 
ændringer eller uopdaget tab af data (dette kan f.eks. 
gælde for bevægelsessensorens tilslutning til gear­
kassen, adapteren til M1/N1-køretøjer, den eksterne 
GNSS-tilslutning eller køretøjsenheden)  
— monteringspladen, medmindre den er anbragt således, at 
den ikke kan fjernes, uden at påskriften ødelægges.  
▼M1 
398a) De nævnte plomber skal være certificeret i henhold til 
standard EN 16882:2016.  
▼B 
399) Ovennævnte plomberinger kan brydes:  
— i nødstilfælde  
— med det formål at montere, justere eller reparere en 
hastighedsbegrænser eller anden anordning, som 
bidrager til trafiksikkerheden, forudsat at kontrolappa­
ratet fortsat fungerer pålideligt og korrekt og plomberes 
igen af en autoriseret installatør eller et autoriseret 
værksted (i overensstemmelse med afsnit 6) straks 
efter montering af hastighedsbegrænser eller trafiksik­
kerhedsanordning, i andre tilfælde senest efter syv dage.  
400) Hver gang disse plomber brydes, udfærdiges en skriftlig 
begrundelse herfor, som stilles til rådighed for den kompe­
tente myndighed.  
401) Plomberne skal bære et identifikationsnummer, som tildeles  
af fabrikanten. Dette nummer skal være unikt og adskille 
sig fra ethvert andet plombenummer, der er tildelt af andre 
plombefabrikanter.  
▼M1 
Det unikke identifikationsnummer anføres som en marke­
ring i formatet MMNNNNNNNN, som ikke kan fjernes, 
hvor MM er et unikt fabrikant-ID (databaseregistrering 
forvaltes af Europa-Kommissionen), og NNNNNNNN er 
plombens alfanumeriske nummer, som er unik i fabrikan­
tens regi.  
▼B 
402) På plomberne skal der være plads til, at godkendte instal­
latører, værksteder eller køretøjsfabrikanter kan tilføje et 
særligt mærke i overensstemmelse med artikel 22, stk. 3, 
i forordning (EU) nr. 165/2014.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 102  
Dette mærke må ikke dække plombens identifikations­
nummer.  
▼M1 
403) Plombefabrikanterne skal registreres i en særlig database,  
når de får en plombemodel certificeret i henhold til EN 
16882:2016, og offentliggøre numrene på deres identifika­
tionsplomber ved at følge en procedure, der skal fastlægges 
af Europa-Kommissionen.  
404) Godkendte værksteder og køretøjsfabrikanter må i henhold 
til forordning (EU) nr. 165/2014 kun bruge plomber certi­
ficeret i henhold til EN 16882:2016 fra de plombefabri­
kanter, der står opført i ovennævnte database.  
▼B 
405) Plombefabrikanterne og deres distributører skal sikre 
fyldestgørende sporbarhedsfortegnelser for de plomber, 
der sælges til brug som omhandlet i forordning (EU) 
nr. 165/2014, og de skal fremlægge dem for de kompetente 
nationale myndigheder efter anmodning.  
406) Plombernes unikke identifikationsnumre skal være klart 
synlige på installationspladen.  
6 KONTROL, EFTERSYN OG REPARATIONER  
Punkt 5.3 i dette bilag indeholder bestemmelser for, under hvil ke 
omstændigheder plomber må fjernes som omhandlet i artikel 22, s tk. 
5, i forordning (EØF) nr. 165/2014.  
6.1 Autorisering af installatører, værksteder og køretøjsfabrikanter  
Medlemsstaterne godkender, kontrollerer regelmæssigt og certifi ­
cerer de organer, som skal udføre:  
— montering  
— eftersyn  
— kontrol  
— reparationer.  
Værkstedskort må kun udstedes til installatører og/eller værkst eder, 
som er godkendt til aktivering og/eller kalibrering af kontrola ppa­
rater i overensstemmelse med dette bilag, og som, medmindre det  
behørigt begrundes:  
— ikke er berettiget til et virksomhedskort  
— og hvis øvrige faglige virksomhed ikke frembyder en mulig far e 
for systemets overordnede sikkerhed som foreskrevet i tillæg 10 . 
▼M1 
6.2 Kontrol af nye eller reparerede komponenter  
407) For hver enkelt ny eller repareret anordning kontrolleres 
den korrekte funktion og nøjagtigheden af angivelser og 
optegnelser inden for de i afsnit 3.2.1, 3.2.2, 3.2.3 og 3.3 
fastlagte grænser.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 103  
6.3 Monteringsinspektion  
▼M1 
408) Ved monteringen i et køretøj skal apparatet og hele instal ­
lationen opfylde bestemmelserne i afsnit 3.2.1, 3.2.2, 3.2.3 
og 3.3 vedrørende maksimale tolerancer. Hele monteringen 
plomberes i henhold til afsnit 5.3 og kalibreres.  
▼B 
6.4 Periodisk kontrol  
▼M3 
409) Periodisk eftersyn af det i køretøjet monterede apparat sk al 
foretages efter reparation af apparatet, efter ændring af 
køretøjets vejdrejetal, efter ændring af den effektive dækpe­
riferi, når apparatets UTC-tid har været over 5 minutter 
forkert, når køretøjets indregistreringsnummer er ændret, 
og mindst én gang inden for to år (24 måneder) efter den 
seneste kontrol.  
▼B 
410) Især kontrolleres:  
— at kontrolapparatet fungerer korrekt, herunder også 
lagring af data på takografkortet og kommunikationen 
med læsere til fjernkommunikation  
— at overholdelse af bestemmelserne i afsnit 3.2.1 og 
3.2.2 om maksimale tolerancer ved monteringen er 
sikret  
— at overensstemmelse med bestemmelserne i afsnit 3.2.3 
og 3.3 er sikret  
— at kontrolapparatet er forsynet med typegodkendelses­
mærke  
— at der er anbragt en installationsplade som defineret i 
krav 396 og en typeplade som defineret i krav 225  
— dækstørrelsen og den faktiske dækperiferi  
— at der ikke er manipulerende anordninger fastgjort til 
kontrolapparatet  
— at plomberne sidder korrekt og er i god stand, at deres 
identifikationsnumre er gyldige (godkendt plombefabri­
kant i Europa-Kommissionens database), og at deres 
identifikationsnumre svarer til markeringerne på instal­
lationspladen (se krav 401).  
▼M3 
— at versionsidentifikatoren for det lagrede digitale kort er 
den seneste.  
410a) Hvis de kompetente nationale myndigheder konstaterer et 
tilfælde af manipulation, kan køretøjet sendes til et auto­
riseret værksted med henblik på rekalibrering af kontrol­
apparatet.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 104  
411) Hvis det konstateres, at en af hændelserne i afsnit 3.9 
(Detektion af hændelser og/eller fejl) er indtruffet siden 
det sidste eftersyn, og takograffabrikanter og/eller nationale 
myndigheder anser den for potentielt at kunne bringe 
kontrolapparatets sikkerhed i fare, skal værkstedet:  
a. sammenligne identifikationsdataene for den bevægelses­
sensor, der er tilsluttet gearkassen, med identifikations­
dataene for den bevægelsessensor, der er samparret med 
køretøjsenheden og registreret deri  
b. kontrollere, om de oplysninger, der er anført på instal­
lationspladen, svarer til de oplysninger, der er registreret 
i køretøjsenheden  
c. kontrollere, om bevægelsessensorens serienummer og 
godkendelsesnummer, hvis de er trykt på bevægelses­
sensoren, svarer til de oplysninger, der er lagret i 
kontrolapparatets datalager  
d. sammenligne eventuelle identifikationsdata på det 
eksterne GNSS-udstyrs typeplade med de data, der er 
lagret i køretøjsenhedens datalager.  
412) Værkstedet skal i eftersynsrapporterne nævne resultater, d er 
vedrører brudte plomberinger eller manipulerende anord­
ninger. Værkstedet skal opbevare disse rapporter i mindst 
to år, og de skal til enhver tid stilles til rådighed for den 
kompetente myndighed efter anmodning.  
413) Disse inspektioner skal omfatte kalibrering og forebyg­
gende udskiftning af de plomber, som værkstedet har 
ansvaret for at montere.  
6.5 Måling af fejl  
414) Måling af fejl under installation og drift gennemføres på 
følgende betingelser, der er at anse som normale afprøv­
ningsbetingelser:  
— ubelastet køretøj i køreklar stand  
— dæktryk i overensstemmelse med fabrikantens angi­
velser  
— dækslitage inden for de ved national lov givne grænser  
— køretøjets bevægelse:  
— Køretøjet skal bevæge sig frem ved egen motorkraft i 
lige linje på jævnt terræn ved en hastighed på 50 ± 
5 km/t. Måledistancen skal være mindst 1 000 m.  
— Prøven kan også udføres på anden måde, forudsat 
tilsvarende nøjagtighed opnås, f.eks. med en egnet 
prøvestand.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 105  
6.6 Reparationer  
415) Værksteder skal kunne overføre data fra kontrolapparatet 
for at anvende dem til tilbagemelding til den pågældende 
transportvirksomhed.  
416) Det godkendte værksted skal til transportvirksomheden 
udfærdige en attest om manglende dataoverførsel, når fejl 
ved kontrolapparatet bevirker, at tidligere registrerede data 
ikke kan overføres, heller ikke efter reparation på det 
pågældende værksted. Værkstederne opbevarer en kopi af 
hver attest, som de har udstedt, i mindst to år.  
7 UDSTEDELSE AF KORT  
De af medlemsstaterne oprettede kortudstedelsesprocesser skal v ære 
i overensstemmelse med følgende:  
417) I kortnummeret på et takografkort, som for første gang 
udstedes til en ansøger, indgår et fortløbende indeks (hvis 
relevant), et erstatningsindeks samt et fornyelsesindeks 
stillet på »0«.  
418) På alle ikke personlige takografkort, som udstedes til en 
enkelt kontrolinstans, et enkelt værksted eller en enkelt 
transportvirksomhed, skal kortnumrenes første 13 cifre 
være identiske, og alle kortnumre skal have forskelligt fort­
løbende indeks.  
419) Et takografkort, som udstedes til erstatning for et eksist e­
rende takografkort, skal have samme kortnummer som det 
udskiftede, bortset fra udskiftningsindekset, som skal være 
øget med »1« (i rækkefølgen 0, …, 9, A, …, Z).  
420) Et takografkort, som udstedes til erstatning for et eksist e­
rende takografkort, skal have samme udløbsdato som det 
erstattede.  
421) Et takografkort, som udstedes til fornyelse for et eksiste ­
rende takografkort, skal have samme kortnummer som det 
fornyede, bortset fra udskiftningsindekset, som skal være 
stillet på »0«, og fornyelsesindekset, som skal være øget 
med »1« (i rækkefølgen 0, …, 9, A, …, Z).  
422) Udskiftning af et eksisterende takografkort med det formål  
at ændre administrative data skal følge reglerne for forny­
else, når det finder sted i samme medlemsstat, og reglerne 
for første udstedelse, når det finder sted i en anden 
medlemsstat.  
423) »Kortindehavers efternavn« skal for ikkepersonlige værk­
steds- eller kontrolkort udfyldes med værkstedets eller 
kontrolinstansens navn eller med installatørens eller 
kontrolmedarbejderens navn, hvis den enkelte medlemsstat 
vælger dette.  
424) Medlemsstaterne udveksler data elektronisk for at sikre, a t 
det førerkort, som de udsteder, er unikt, i overensstemmelse 
med artikel 31 i forordning (EU) nr. 165/2014.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 106  
8 TYPEGODKENDELSE AF KONTROLAPPARATUR OG TAKO­
GRAFKORT  
8.1 Almindelige bestemmelser  
▼M1 
I dette afsnit forstås ved »kontrolapparat« »kontrolapparatet e ller 
dets komponenter«. Der kræves ingen typegodkendelse af det/de 
kabler, som forbinder bevægelsessensoren med køretøjsenheden, 
det eksterne GNSS-udstyr med køretøjsenheden eller det eksterne  
udstyr til fjernkommunikation med køretøjsenheden. Det papir, s om 
skal anvendes af kontrolapparatet, anses for at være en kompone nt i 
kontrolapparatet.  
Enhver fabrikant kan anmode om typegodkendelse af kontrolappa­
ratkomponenter sammen med enhver anden kontrolapparatkompo­
nent, forudsat at den enkelte komponent er i overensstemmelse 
med kravene i dette bilag. Alternativt kan fabrikanter anmode o m 
typegodkendelse af kontrolapparater.  
Som beskrevet i definitionen i denne forordnings artikel 2, nr.  10), 
kan køretøjsenheder have varianter i komponentsammensætningen. 
Uanset køretøjsenhedens komponentsammensætning er den eksterne 
antenne og (eventuelt) antennesplitteren, der er forbundet med 
GNSS-modtageren eller udstyret til fjernkommunikation, ikke en 
del af køretøjsenhedens typegodkendelse.  
Dog skal fabrikanter, som har opnået typegodkendelse af kontrol ­
apparatet, føre en offentligt tilgængelig liste over kompatible  
antenner og splittere for hver typegodkendt køretøjsenhed, ekst ernt 
GNSS-udstyr og eksternt udstyr til fjernkommunikation.  
▼B 
425) Ved forelæggelse til godkendelse skal kontrolapparatet 
være komplet med eventuelt indbygget ekstra tilbehør.  
426) Typegodkendelse af kontrolapparater og takografkort skal 
omfatte sikkerhedsrelevante prøver, funktionsprøver og 
interoperabilitetsprøver. Positive resultater for hver af 
disse prøver angives ved en passende attest.  
▼M1 
427) Medlemsstaternes typegodkendelsesmyndigheder udsteder 
ikke en typegodkendelsesattest, før de er i besiddelse af:  
— en sikkerhedsattest (hvis krævet i dette bilag)  
— en funktionsattest  
— en interoperabilitetsattest (hvis krævet i dette bilag)  
for det kontrolapparat eller det takografkort, som typegod­
kendelsesansøgningen omfatter.  
▼B 
428) Enhver ændring af en af apparatets komponenter eller af 
arten af de til dets fremstilling anvendte materialer skal, 
inden apparatet tages i brug, anmeldes til den myndighed, 
som har typegodkendt apparatet. Denne myndighed skal 
over for fabrikanten bekræfte udvidelsen af typegodken­
delsen eller kan kræve opdatering eller bekræftelse af de 
relevante funktions-, sikkerheds- og/eller interoperabilitets­
attester.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 107  
429) Procedurer til opdatering af software i et allerede monter et 
kontrolapparat skal være godkendt af den myndighed, som 
meddelte typegodkendelse af kontrolapparatet. Softwareop­
dateringer må ikke ændre eller slette føreraktivitetsdata, 
som er gemt i kontrolapparatet. Software må kun opdateres 
under ansvar af kontrolapparatets fabrikant.  
430) Typegodkendelse af softwareændringer, som har til formål 
at opdatere et tidligere typegodkendt kontrolapparat, kan 
ikke nægtes, hvis ændringerne kun vedrører funktioner, 
som ikke beskrives i dette bilag. Indførelse af nye 
tegnsæt kan være undtaget fra en softwareopdatering af et 
kontrolapparat, hvis det ikke er teknisk muligt.  
▼B 
8.2 Sikkerhedsattest  
431) Sikkerhedsattesten udstedes i overensstemmelse med 
bestemmelserne i tillæg 10 til dette bilag. De dele af 
kontrolapparatet, der skal certificeres, er køretøjsenheden, 
bevægelsessensoren, det eksterne GNSS-udstyr og 
takografkortet.  
432) Hvis sikkerhedscertificeringsmyndighederne ekstraordinært 
afviser at certificere et nyt apparat med den begrundelse, 
at sikkerhedsmekanismerne er forældede, meddeles der alli­
gevel typegodkendelse udelukkende under denne særlige og 
ekstraordinære omstændighed, hvis der ikke eksisterer en 
alternativ løsning, som er i overensstemmelse med 
forordningen.  
433) Under denne omstændighed underretter den pågældende 
medlemsstat omgående Europa-Kommissionen, som senest 
12 kalendermåneder efter meddelelsen af typegodkendelse, 
iværksætter en procedure, der sikrer, at sikkerhedsniveauet 
bringes tilbage til det oprindelige niveau.  
8.3 Funktionsattest  
434) Ansøgere til typegodkendelse skal forsyne medlemsstatens 
typegodkendelsesmyndigheder med alt det materiale og al 
den dokumentation, som myndigheden anser for nødven­
digt. 
435) Fabrikanterne stiller de relevante prøver af produkterne t il 
typegodkendelse og den tilhørende nødvendige dokumenta­
tion til rådighed for de laboratorier, der er udpeget til at 
udføre funktionsprøver, senest en måned efter at anmod­
ningen er fremsat. Den anmodende enhed afholder even­
tuelle udgifter i forbindelse med denne anmodning. Labo­
ratoriet skal behandle alle kommercielt følsomme oplys­
ninger fortroligt.  
436) Der må ikke udstedes en funktionsattest til fabrikanten, f ør 
mindst alle de i tillæg 9 foreskrevne funktionsprøver er 
udført med tilfredsstillende resultat.  
437) Funktionsattesten udstedes af typegodkendelsesmyndig­
heden. Denne attest skal ud over navnet på modtageren 
og identifikation af modellen indeholde en specificeret 
liste over de udførte prøver og resultaterne heraf.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 108  
438) Funktionsattesten for en komponent til et kontrolapparat 
skal også indeholde typegodkendelsesnumrene for de 
andre typegodkendte kompatible komponenter til kontrol­
apparatet, der afprøves ved certificering af det.  
439) I funktionsattesten for en komponent til et kontrolapparat  
skal det desuden angives, hvilken ISO- eller CEN-standard 
der er anvendt til at certificere den funktionelle grænse­
flade.  
8.4 Interoperabilitetsattest  
440) Interoperabilitetsprøver udføres af ét enkelt laboratorium  
under Europa-Kommissionens myndighed og ansvar.  
441) Laboratoriet registrerer de af fabrikanterne indgivne anmo d­
ninger om interoperabilitetsprøver i den kronologiske 
rækkefølge, de modtages.  
442) Anmodningerne vil først blive officielt registreret, når l abo­
ratoriet er i besiddelse af:  
— det fuldstændige sæt materiale og dokumenter, som er 
nødvendige til sådanne interoperabilitetsprøver  
— den tilsvarende sikkerhedsattest  
— den tilsvarende funktionsattest.  
Fabrikanten underrettes om datoen for registreringen.  
▼M3 
443) Laboratoriet må ikke udføre interoperabilitetsprøver for 
kontrolapparater eller takografkort, som ikke har bestået 
sårbarhedsanalysen under deres sikkerhedsevaluering og 
en funktionel evaluering, undtagen under de særlige 
omstændigheder, der er nævnt i krav 432.  
▼B 
444) Enhver fabrikant, som anmoder om interoperabilitetsprøver,  
forpligter sig til at overlade hele det sæt materiale og doku­
menter, som han har fremskaffet med henblik på udførelse 
af prøverne, til det laboratorium, som forestår prøverne.  
445) Interoperabilitetsprøver skal udføres i overensstemmelse 
med bestemmelserne i tillæg 9 til dette bilag, og i prøverne 
skal indgå henholdsvis alle de typer kontrolapparater og 
takografkort:  
— for hvilke typegodkendelsen stadig er gyldig eller  
— for hvilke typegodkendelsen er under behandling, og for 
hvilke der foreligger en gyldig interoperabilitetsattest.  
446) Interoperabilitetsprøverne skal omfatter alle de generatio ner 
af kontrolapparater og takografkort, der stadig er i brug.  
▼M3 
447) Laboratoriet må først udstede en interoperabilitetsattest til 
fabrikanten, når alle de krævede interoperabilitetsprøver er 
bestået, og fabrikanten har godtgjort, at der er udstedt en 
gyldig funktionsattest og en gyldig sikkerhedsattest, 
undtagen under de særlige omstændigheder, der er nævnt 
i krav 432.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 109  
448) Giver interoperabilitetsprøverne ikke tilfredsstillende 
resultat med en (et) eller flere af kontrolapparaterne eller 
takografkortene, vil interoperabilitetsattesten ikke blive 
udstedt, før den anmodende fabrikant har gennemført de 
nødvendige ændringer og interoperabilitetsprøverne har 
givet tilfredsstillende resultat. Laboratoriet skal udfinde 
årsagen til problemet med assistance fra de fabrikanter, 
der berøres af denne interoperabilitetsmangel og skal søge 
at bistå den anmodende producent med at finde en teknisk 
løsning. I tilfælde, hvor fabrikanten har ændret sit produkt, 
påhviler det fabrikanten at søge de pågældende myndighe­
ders bekræftelse på, at sikkerhedsattest og funktionsattest 
stadig er gyldige.  
449) Interoperabilitetsattesten er gyldig i seks måneder. Efter  
slutningen af denne periode ophæves den, hvis fabrikanten 
ikke har modtaget en tilsvarende typegodkendelsesattest. 
Den fremsendes af fabrikanten til den typegodkendende 
myndighed i den medlemsstat, som har udstedt funktions­
attesten.  
450) Intet element, som kan tænkes at give anledning til en 
interoperabilitetsmangel, må anvendes til at opnå fortjeneste 
eller til at opnå en dominerende stilling.  
8.5 Typegodkendelsesattest  
451) Den typegodkendende myndighed i medlemsstaten kan 
udstede typegodkendelsesattesten, så snart den er i besid­
delse af de nødvendige tre attester.  
452) Typegodkendelsesattesten for en komponent til et kontrol­
apparat skal også indeholde typegodkendelsesnumrene for 
det andet typegodkendte interoperable kontrolapparatur.  
453) Typegodkendelsesattesten kopieres af den typegodkendende 
myndighed til det laboratorium, som forestår interoperabili­
tetsprøverne, på det tidspunkt hvor den udstedes til 
fabrikanten.  
454) Det laboratorium, som forestår interoperabilitetsprøverne,  
skal have et offentligt websted med en opdateret liste 
over de kontrolapparat- eller takografmodeller,  
— for hvilke der er registreret en anmodning om interope­
rabilitetsprøver,  
— for hvilke der er udstedt en interoperabilitetsattest (også 
selv om den er foreløbig),  
— for hvilke der er udstedt en typegodkendelsesattest.  
8.6 Undtagelsesprocedure: første interoperabilitetsattest til kontrol ­
apparater og takografkort af anden generation  
455) I en periode på fire måneder efter at et første sammen­
hørende sæt kontrolapparat af anden generation og tilhø­
rende takografkort af anden generation (fører-, værksteds-, 
kontrol- og virksomhedskort) er attesteret som interopera­
belt, anses en eventuelt udstedt interoperabilitetsattest 
(herunder også den første attest) vedrørende anmodninger 
registreret i denne periode for foreløbig.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 110  
456) Anses alle de omhandlede produkter efter slutningen af 
denne periode for indbyrdes interoperable, bliver alle tilsva­
rende interoperabilitetsattester endelige.  
457) Findes der i løbet af denne periode interoperabilitetsmang el, 
skal det laboratorium, som forestår interoperabilitetsprø­
verne, finde årsagerne til problemerne med assistance fra 
alle de berørte fabrikanter og opfordre dem til at gennem­
føre de nødvendige ændringer.  
458) Tilbagestår der efter slutningen af denne periode interope ra­
bilitetsproblemer, skal det laboratorium, som forestår inter­
operabilitetsprøverne, i samarbejde med de pågældende 
fabrikanter og med de typegodkendelsesmyndigheder, som 
udstedte de tilsvarende funktionsattester, finde årsagen til 
interoperabilitetsmanglerne og fastlægge, hvilke ændringer 
hver af de pågældende fabrikanter bør foretage. Søgningen 
efter tekniske løsninger må vare højst to måneder; findes 
der derved ingen fælles løsning, tager Kommissionen efter 
samråd med det laboratorium, som forestår interoperabili­
tetsprøverne, stilling til, hvilke(t) apparat(er) og kort, der 
skal udstedes en endelig interoperabilitetsattest for, og 
angiver begrundelse herfor.  
459) Eventuelle anmodninger om interoperabilitetsprøver, som af  
laboratoriet registreres i perioden fra fire måneder efter 
udstedelse af den første foreløbige interoperabilitetsattest 
til datoen for den i krav 455 omhandlede Kommissions­
beslutning, stilles i bero, til de første interoperabilitetspro ­
blemer er løst. Disse anmodninger behandles derefter i 
samme kronologiske rækkefølge, som de er registreret.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 111  
Tillæg 1  
DATAORDLISTE  
INDHOLDSFORTEGNELSE  
1. INDLEDNING  
1.1. Fremgangsmåde anvendt ved definition af datatyper  
1.2. Referencer  
2. DEFINITIONER AF DATATYPER  
2.1. ActivityChangeInfo  
2.2. Adresse  
2.3. AESKey  
2.4. AES128Key  
2.5. AES192Key  
2.6. AES256Key  
2.7. BCDString  
2.8. CalibrationPurpose  
2.9. CardActivityDailyRecord  
2.10. CardActivityLengthRange  
2.11. CardApprovalNumber  
▼M3 
2.11a. CardBorderCrossing  
2.11b. CardBorderCrossingRecord  
▼B 
2.12. CardCertificate  
2.13. CardChipIdentification  
2.14. CardConsecutiveIndex  
2.15. CardControlActivityDataRecord  
2.16. CardCurrentUse  
2.17. CardDriverActivity  
2.18. CardDrivingLicenceInformation  
2.19. CardEventData  
2.20. CardEventRecord  
2.21. CardFaultData  
2.22. CardFaultRecord  
2.23. CardIccIdentification  
2.24. CardIdentification  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 112  
2.24a. CardLoadTypeEntries  
2.24b. CardLoadTypeEntryRecord  
2.24c. CardLoadUnloadOperations  
2.24d. CardLoadUnloadRecord  
▼B 
2.25. CardMACertificate  
2.26. CardNumber  
▼M3 
2.26a. CardPlaceAuthDailyWorkPeriod  
▼B 
2.27. CardPlaceDailyWorkPeriod  
2.28. CardPrivateKey  
2.29. CardPublicKey  
2.30. CardRenewalIndex  
2.31. CardReplacementIndex  
2.32. CardSignCertificate  
2.33. CardSlotNumber  
2.34. CardSlotsStatus  
2.35. CardSlotsStatusRecordArray  
2.36. CardStructureVersion  
2.37. CardVehicleRecord  
2.38. CardVehiclesUsed  
2.39. CardVehicleUnitRecord  
2.40. CardVehicleUnitsUsed  
2.41. Attester  
2.42. CertificateContent  
2.43. CertificateHolderAuthorisation  
2.44. CertificateRequestID  
2.45. CertificationAuthorityKID  
2.46. CompanyActivityData  
2.47. CompanyActivityType  
2.48. CompanyCardApplicationIdentification  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 113  
2.48a. CompanyCardApplicationIdentificationV2  
▼B 
2.49. CompanyCardHolderIdentification  
2.50. ControlCardApplicationIdentification  
▼M3 
2.50a. ControlCardApplicationIdentificationV2  
▼B 
2.51. ControlCardControlActivityData  
2.52. ControlCardHolderIdentification  
2.53. ControlType  
2.54. CurrentDateTime  
2.55. CurrentDateTimeRecordArray  
2.56. DailyPresenceCounter  
2.57. Datef  
2.58. DateOfDayDownloaded  
2.59. DateOfDayDownloadedRecordArray  
2.60. Afstand  
▼M3 
2.60a. DownloadInterfaceVersion  
▼B 
2.61. DriverCardApplicationIdentification  
▼M3 
2.61a. DriverCardApplicationIdentificationV2  
▼B 
2.62. DriverCardHolderIdentification  
▼M1 
2.63. Forbeholdt fremtidig brug  
▼B 
2.64. EGFCertificate  
2.65. EmbedderIcAssemblerId  
2.66. EntryTypeDailyWorkPeriod  
2.67. EquipmentType  
2.68. EuropeanPublicKey  
2.69. EventFaultRecordPurpose  
2.70. EventFaultType  
2.71. ExtendedSealIdentifier  
2.72. ExtendedSerialNumber  
2.73. FullCardNumber  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 114  
2.74. FullCardNumberAndGeneration  
2.75. Generation  
2.76. GeoCoordinates  
2.77. GNSSAccuracy  
▼M1 
2.78. GNSSAccumulatedDriving  
2.79. GNSSAccumulatedDrivingRecord  
▼M3 
2.79a. GNSSAuthAccumulatedDriving  
2.79b. GNSSAuthStatusADRecord  
2.79c. GNSSPlaceAuthRecord  
▼B 
2.80. GNSSPlaceRecord  
2.81. HighResOdometer  
2.82. HighResTripDistance  
2.83. HolderName  
▼M3 
2.84. Forbeholdt fremtidig brug  
▼B 
2.85. K-ConstantOfRecordingEquipment  
2.86. KeyIdentifier  
2.87. KMWCKey  
2.88. Language  
2.89. LastCardDownload  
▼M3 
2.89a. LengthOfFollowingData  
▼B 
2.90. LinkCertificate  
▼M3 
2.90a. LoadType  
▼B 
2.91. L-TyreCircumference  
2.92. MAC  
2.93. ManualInputFlag  
2.94. ManufacturerCode  
2.95. ManufacturerSpecificEventFaultData  
2.96. MemberStateCertificate  
2.97. MemberStateCertificateRecordArray  
2.98. MemberStatePublicKey  
2.99. Name  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 115  
2.100. NationAlpha  
2.101. NationNumeric  
▼M3 
2.101a. NoOfBorderCrossingRecords  
▼B 
2.102. NoOfCalibrationRecords  
2.103. NoOfCalibrationsSinceDownload  
2.104. NoOfCardPlaceRecords  
2.105. NoOfCardVehicleRecords  
2.106. NoOfCardVehicleUnitRecords  
2.107. NoOfCompanyActivityRecords  
2.108. NoOfControlActivityRecords  
2.109. NoOfEventsPerType  
2.110. NoOfFaultsPerType  
▼M1 
2.111. NoOfGNSSADRecords  
▼M3 
2.111a. NoOfLoadUnloadRecords  
▼B 
2.112. NoOfSpecificConditionRecords  
▼M3 
2.112a. NoOfLoadTypeEntryRecords  
▼B 
2.113. OdometerShort  
2.114. OdometerValueMidnight  
▼M3 
2.114a. OperationType  
▼B 
2.115. OdometerValueMidnightRecordArray  
2.116. OverspeedNumber  
▼M3 
2.116a. PlaceAuthRecord  
2.116b. PlaceAuthStatusRecord  
▼B 
2.117. PlaceRecord  
▼M3 
2.117a. PositionAuthenticationStatus  
▼B 
2.118. PreviousVehicleInfo  
2.119. PublicKey  
2.120. RecordType  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 116  
2.121. RegionAlpha  
2.122. RegionNumeric  
2.123. RemoteCommunicationModuleSerialNumber  
2.124. RSAKeyModulus  
2.125. RSAKeyPrivateExponent  
2.126. RSAKeyPublicExponent  
2.127. RtmData  
2.128. SealDataCard  
2.129. SealDataVu  
2.130. SealRecord  
2.131. SensorApprovalNumber  
2.132. SensorExternalGNSSApprovalNumber  
2.133. SensorExternalGNSSCoupledRecord  
2.134. SensorExternalGNSSIdentification  
2.135. SensorExternalGNSSInstallation  
2.136. SensorExternalGNSSOSIdentifier  
2.137. SensorExternalGNSSSCIdentifier  
2.138. SensorGNSSCouplingDate  
2.139. SensorGNSSSerialNumber  
2.140. SensorIdentification  
2.141. SensorInstallation  
2.142. SensorInstallationSecData  
2.143. SensorOSIdentifier  
2.144. SensorPaired  
2.145. SensorPairedRecord  
2.146. SensorPairingDate  
2.147. SensorSCIdentifier  
2.148. SensorSerialNumber  
2.149. Signature  
2.150. SignatureRecordArray  
2.151. SimilarEventsNumber  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 117  
2.152. SpecificConditionRecord  
2.153. SpecificConditions  
2.154. SpecificConditionType  
2.155. Speed  
2.156. SpeedAuthorised  
2.157. SpeedAverage  
2.158. SpeedMax  
▼M3 
2.158a. TachographCardsGen1Suppression  
▼B 
2.159. TachographPayload  
▼M1 
2.160. Forbeholdt fremtidig brug  
▼B 
2.161. TDesSessionKey  
2.162. TimeReal  
2.163. TyreSize  
2.164. VehicleIdentificationNumber  
2.165. VehicleIdentificationNumberRecordArray  
2.166. VehicleRegistrationIdentification  
▼M3 
2.166a. VehicleRegistrationIdentificationRecordArray  
▼B 
2.167. VehicleRegistrationNumber  
2.168. VehicleRegistrationNumberRecordArray  
2.169. VuAbility  
2.170. VuActivityDailyData  
2.171. VuActivityDailyRecordArray  
2.172. VuApprovalNumber  
2.173. VuCalibrationData  
2.174. VuCalibrationRecord  
2.175. VuCalibrationRecordArray  
2.176. VuCardIWData  
2.177. VuCardIWRecord  
2.178. VuCardIWRecordArray  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 118  
2.179. VuCardRecord  
2.180. VuCardRecordArray  
2.181. VuCertificate  
2.182. VuCertificateRecordArray  
2.183. VuCompanyLocksData  
2.184. VuCompanyLocksRecord  
2.185. VuCompanyLocksRecordArray  
▼M3 
2.185a. VuConfigurationLengthRange  
▼B 
2.186. VuControlActivityData  
2.187. VuControlActivityRecord  
2.188. VuControlActivityRecordArray  
2.189. VuDataBlockCounter  
2.190. VuDetailedSpeedBlock  
2.191. VuDetailedSpeedBlockRecordArray  
2.192. VuDetailedSpeedData  
▼M3 
2.192a. VuDigitalMapVersion  
▼B 
2.193. VuDownloadablePeriod  
2.194. VuDownloadablePeriodRecordArray  
2.195. VuDownloadActivityData  
2.196. VuDownloadActivityDataRecordArray  
2.197. VuEventData  
2.198. VuEventRecord  
2.199. VuEventRecordArray  
2.200. VuFaultData  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 119  
2.201. VuFaultRecord  
2.202. VuFaultRecordArray  
▼M1 
2.203. VuGNSSADRecord  
▼M3 
2.203a. VuBorderCrossingRecord  
2.203b. VuBorderCrossingRecordArray  
▼M1 
2.204. VuGNSSADRecordArray  
▼M3 
2.204a. VuGnssMaximalTimeDifference  
▼B 
2.205. VuIdentification  
2.206. VuIdentificationRecordArray  
2.207. VuITSConsentRecord  
2.208. VuITSConsentRecordArray  
▼M3 
2.208a. VuLoadUnloadRecord  
2.208b. VuLoadUnloadRecordArray  
▼B 
2.209. VuManufacturerAddress  
2.210. VuManufacturerName  
2.211. VuManufacturingDate  
2.212. VuOverSpeedingControlData  
2.213. VuOverSpeedingControlDataRecordArray  
2.214. VuOverSpeedingEventData  
2.215. VuOverSpeedingEventRecord  
2.216. VuOverSpeedingEventRecordArray  
2.217. VuPartNumber  
2.218. VuPlaceDailyWorkPeriodData  
2.219. VuPlaceDailyWorkPeriodRecord  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 120  
2.220. VuPlaceDailyWorkPeriodRecordArray  
2.221. VuPrivateKey  
2.222. VuPublicKey  
▼M3 
2.222a. VuRtcTime  
▼B 
2.223. VuSerialNumber  
2.224. VuSoftInstallationDate  
2.225. VuSoftwareIdentification  
2.226. VuSoftwareVersion  
2.227. VuSpecificConditionData  
2.228. VuSpecificConditionRecordArray  
2.229. VuTimeAdjustmentData  
▼M1 
2.230. Forbeholdt fremtidig brug  
2.231. Forbeholdt fremtidig brug  
▼B 
2.232. VuTimeAdjustmentRecord  
2.233. VuTimeAdjustmentRecordArray  
2.234. WorkshopCardApplicationIdentification  
▼M3 
2.234a. WorkshopCardApplicationIdentificationV2  
2.234b. WorkshopCardCalibrationAddData  
2.234c. WorkshopCardCalibrationAddDataRecord  
▼B 
2.235. WorkshopCardCalibrationData  
2.236. WorkshopCardCalibrationRecord  
2.237. WorkshopCardHolderIdentification  
2.238. WorkshopCardPIN  
2.239. W-VehicleCharacteristicConstant  
2.240. VuPowerSupplyInterruptionRecord  
2.241. VuPowerSupplyInterruptionRecordArray  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 121  
2.242. VuSensorExternalGNSSCoupledRecordArray  
2.243. VuSensorPairedRecordArray  
3. DEFINITIONER AF VÆRDI- OG STØRRELSESOMRÅDE  
4. TEGNSÆT  
5. KODNING  
6. OBJEKTIDENTIFIKATORER OG APPLIKATIONSIDENTIFIKA­ 
TORER  
6.1. Objektidentifikatorer  
6.2. Applikationsidentifikatorer  
1. INDLEDNING  
Dette tillæg fastlægger de dataformater, dataelementer og datas trukturer, 
som skal anvendes i kontrolapparater og takografkort.  
1.1. Fremgangsmåde anvendt ved definition af datatyper  
Til definition af datatyperne i dette tillæg er anvendt Abstrac t Syntax 
Notation One (ASN.1). På denne måde kan der defineres enkle og 
strukturerede data, uden at dette forudsætter en nærmere bestem t over­
føringssyntaks (kodningsregler), som vil være applikations- og miljø­
afhængig.  
ASN.1-typebenævnelser er tildelt efter ISO/IEC 8824-1. Dette in de­
bærer:  
— at datatypens betydning, hvor det er muligt, er givet gennem de 
valgte navne,  
— at når en datatype er sammensat af andre datatyper, består da tatypens 
navn stadig af én enkelt sekvens af alfabetiske tegn med stort begyn­
delsesbogstav, dog anvendes store bogstaver inde i navnet til a t 
angive den tilsvarende betydning,  
— at datatypernes navne sædvanligvis hænger sammen med navnet p å 
de datatyper, de er opbygget af, det udstyr, data bliver lagret  på, og 
den funktion, der knytter sig til de pågældende data.  
Er en ASN.1-type i forvejen defineret som del af en anden stand ard og 
relevant til brug i kontrolapparatet, vil den pågældende ASN.1- type være 
defineret i dette tillæg.  
For at give mulighed for forskellige typer kodningsregler er vi sse 
ASN.1-typer i dette tillæg begrænset ved identifikatorer for væ rdiom­
rådet. Identifikatorerne for værdiområde er defineret i punkt 3  og 
tillæg 2.  
1.2. Referencer  
I dette tillæg er følgende referencer anvendt:  
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 — DA — 21.08.2023 — 003.001 — 122  
ISO/IEC 7816-5 Identification cards — Integrated circuit cards — Part 
5: Registration of application providers.  
Second edition: 2004.  
ISO/IEC 7816-6 Identification cards — Integrated circuit cards — Part 
6: Interindustry data elements for interchange, 2004 
+ Technical Corrigendum 1: 2006  
ISO/IEC 8824-1 Information technology — Abstract Syntax Notatio n 
One (ASN.1): Specification of basic notation. 2008 + 
Technical Corrigendum 1: 2012 and Technical Corri­
gendum 2: 2014.  
ISO/IEC 8825-2 Information technology — ASN.1 encoding rules: 
Specification of Packed Encoding Rules (PER). 2008.  
ISO/IEC 8859-1 Information technology — 8 bit single-byte coded  
graphic character sets — Part 1: Latin alphabet 
No.1. First edition: 1998.  
ISO/IEC 8859-7 Information technology — 8 bit single-byte coded  
graphic character sets — Part 7: Latin/Greek alphabet. 
2003.  
ISO 16844-3 Road vehicles — Tachograph systems — Motion 
Sensor Interface. 2004 + Technical Corrigendum 1: 
2006.  
TR-03110-3 BSI / ANSSI Technical Guideline TR-03110-3, 
Advanced Security Mechanisms for Machine 
Readable Travel Documents and eIDAS Token — 
Part 3 Common Specifications, version 2.20, 
3. februar 2015  
2. DEFINITIONER AF DATATYPER  
▼M3 
For nedenstående datatyper vil datafeltet som standardværdi for  
»ukendt« eller »ikkerelevant« indhold være udfyldt Hex FF-byte,  
medmindre andet er angivet.  
Alle datatyper anvendes til applikationer af første og anden ge neration, 
medmindre andet anføres. Datatyper, der kun anvendes til versio n 2- 
applikationer af anden generation, angives.  
For kortdatatyper anvendt til applikationer af første og anden generation 
er den størrelse, der er anført i dette tillæg, størrelsen for applikationer af 
anden generation. Størrelsen for applikationer af første genera tion 
formodes at være kendt af aflæsningsenheden. Bilag I C-kravene til 
sådanne datatyper dækker både applikationer af første og af and en 
generation.  
Kortdatatyper, der ikke er defineret for kort af første generat ion, lagres 
ikke i applikationer af første generation på kort af anden gene ration. 
Navnlig gælder følgende:  
— Typegodkendelsesnumre, der er lagret i applikationer af først e gene­
ration på kort af anden generation, trunkeres til de første ott e tegn, 
hvis det er nødvendigt.  
— Kun den specifikke tilstand »OVERFART MED FÆRGE/TOG 
start« af tilstanden »OVERFART MED FÆRGE/TOG« lagres i 
applikationer af første generation på kort af anden generation.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 123  
2.1. ActivityChangeInfo  
Med denne datatype kan der inden for et to bytes stort ord kode s skift af 
kortlæserstatus kl. 00:00 og/eller førerstatus kl. 00:00 og/ell er skift af 
aktivitet og/eller skift af kørestatus og/eller skift af kortst atus for en fører 
eller medchauffør. Denne datatype er knyttet til krav 105, 266,  291, 320, 
321, 343 og 344 i bilag 1C.
  
Tilordnet værdi  — Oktet udsluttet : »scpaattttttttttt«B (16 bit)  
For registreringer i datalageret (eller status for kortplads):  
»s«B Kortplads:  
»0«B: FØRER  
»1«B: MEDCHAUFFØR  
»c«B Kørestatus:  
»0«B: ÉN FØRER  
»1«B: FØRERHOLD  
»p«B Status for fører- (eller værksteds-)kortet i den pågæl­
dende kortplads:  
»0«B: ISAT, der er isat et kort  
»1«B: IKKE ISAT, kort er ikke isat (eller er taget ud)  
»aa«B Aktivitet:  
»00«B: PAUSE/HVILE  
»01«B: RÅDIGHED  
»10«B: ARBEJDE  
»11«B: KØRSEL  
»ttttttttttt«B Tidspunkt for ændringen: Antal minutter siden 00 h00 
den pågældende dag.  
For registreringer på fører- (eller værksteds-)kortet (og fører status):  
»s«B Kortplads (ikke relevant når »p« = 1, se dog bemærk­
ning nedenfor):  
»0«B: FØRER  
»1«B: MEDCHAUFFØR  
»c«B Kørestatus (når »p« = 0) eller  
Efter aktivitetsstatus (når »p« = 1):  
»0«B: ÉN FØRER  
»0«B: UKENDT  
»1«B: FØRERHOLD  
»1«B: KENDT (= indlæst manuelt)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 124  
»p«B Kortstatus:  
»0«B: ISAT, kortet er sat i et kontrolapparat  
»1«B: IKKE ISAT, kortet er ikke isat (eller er taget 
ud) 
»aa«B Aktivitet (ikke relevant, når »p« = 1 og »c« = 0, se 
dog bemærkning nedenfor):  
»00«B: PAUSE/HVILE  
»01«B: RÅDIGHED  
»10«B: ARBEJDE  
»11«B: KØRSEL  
»ttttttttttt«B Tidspunkt for ændringen: Antal minutter siden 00 h00 
den pågældende dag.  
Bemærkning vedrørende tilfældet »udtagning af kort«:  
Når kortet er taget ud:  
— »s« er relevant og angiver den kortplads, kortet er fjernet f ra 
— »c« skal være sat til 0  
— »p« skal være sat til 1  
— »aa« skal kode den aktuelle aktivitet, som er valgt på det på gældende 
tidspunkt  
Bit »c« og »aa« i ordet (gemt på et kort) kan ved senere manuel  indlæs­
ning overskrives svarende til indlæsningen.  
2.2. Adresse  
En adresse.
  
codePage  angiver et tegnsæt, der er defineret i afsnit 4  
address  er en adresse, som er indkodet med det angivne tegnsæt.  
2.3. AESKey  
Anden generation:  
En AES-nøgle med en længde på 128, 192 eller 256 bit.
  
Tilordnet værdi : Ikke yderligere angivet.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 125  
2.4. AES128Key  
Anden generation:  
En AES128-nøgle.
  
length  er længden af AES128-nøglen i oktetter.  
aes128Key  er en AES-nøgle med en længde på 128 bit.  
Tilordnet værdi:  
Længden skal have værdien 16.  
2.5. AES192Key  
Anden generation:  
En AES192-nøgle.
  
length  er længden af AES192-nøglen i oktetter.  
aes192Key  er en AES-nøgle med en længde på 192 bit.  
Tilordnet værdi:  
Længden skal have værdien 24.  
2.6. AES256Key  
Anden generation:  
En AES256-nøgle.
  
length  er længden af AES256-nøglen i oktetter.  
aes256Key  er en AES-nøgle med en længde på 256 bit.  
Tilordnet værdi:  
Længden skal have værdien 32.  
2.7. BCDString  
BCDString anvendes til at fremstille decimaltal ved binær kode (BCD). 
Denne datatype anvendes til at fremstille ét decimalciffer ved én 
semioktet (4 bit). BCDString er baseret på ISO/IEC 8824-1 »Char acter­
StringType«.
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 126  
BCDString anvender »hstring«-notation. Det hexadecimale tegn læ ngst 
til venstre skal være mest betydende semioktet i første oktet. Til frem­
bringelse af flere oktetter indsættes efter behov foranstillede  
nul-semioktetter fra semioktetpositionen længst til venstre i d en første 
oktet.  
De tilladte cifre er: 0, 1, .. 9.  
2.8. CalibrationPurpose  
Kode, som forklarer, hvorfor der blev registreret et sæt kalibr eringspara­
metre. Denne datatype er knyttet til bilag 1B, krav 097 og 098,  og bilag 
1C, krav 119.
  
Tilordnet værdi:  
Første generation:  
»00«H reserveret værdi  
»01«H aktivering: registrering af de kalibreringspara­
metre, som er kendt i det øjeblik, hvor køretøjs­
enheden aktiveres  
»02«H første installation: første kalibrering af køretøjs­
enheden, efter at den er aktiveret  
»03«H installation: første kalibrering af køretøjsenheden i 
det aktuelle køretøj  
»04«H periodisk eftersyn.  
Anden generation:  
Ud over værdierne for første generation anvendes følgende værdi er: 
»05«H virksomhedens indlæsning af VRN  
»06«H tidsjustering uden kalibrering  
»07«H til »7F«H RFU  
»80«H til »FF«H Fabrikantspecifik.  
2.9. CardActivityDailyRecord  
Oplysninger, gemt på kortet, vedrørende føreraktiviteterne for en given 
kalenderdag. Denne datatype er knyttet til krav 266, 291, 320 o g 343 i 
bilag 1C.
  
activityPreviousRecordLength  er den totale længde i bytes af den 
foregående døgnpost. Maksimumværdien er givet ved længden af de n 
OCTET STRING, som indeholder disse poster (se CardActivityLengt h­
Range, tillæg 2, punkt 4). Når denne post er den ældste døgnpos t, skal 
activityPreviousRecordLength sættes til 0.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 127  
activityRecordLength  er den totale længde i bytes af denne post. 
Maksimumværdien er givet ved længden af den OCTET STRING, 
som indeholder disse poster.  
activityRecordDate  er postens dato.  
activityDailyPresenceCounter  er tælleren for daglig tilstedeværelse for 
kortet det pågældende døgn.  
activityDayDistance  er den totale afstand, som er tilbagelagt det pågæl­
dende døgn.  
activityChangeInfo  er ActivityChangeInfo-datasættet for føreren det 
pågældende døgn. Det kan indeholde indtil 1 440 værdier (ét akt ivitets­
skift pr. minut). Dette datasæt indeholder altid ActivityChange Info med 
kode for førerstatus kl. 00:00.  
2.10.  CardActivityLengthRange  
Antal bytes, som i et fører- eller værkstedskort er til rådighe d for lagring 
af poster vedrørende føreraktivitet.
  
Tilordnet værdi : se tillæg 2.  
2.11.  CardApprovalNumber  
Kortets typegodkendelsesnummer.
  
Tilordnet værdi:  
Godkendelsesnummeret skal tilvejebringes som offentliggjort på 
Europa-Kommissionens relevante websted, dvs. f.eks. med eventue lle 
bindestreger. Godkendelsesnummeret skal være venstrejusteret.  
▼M3 
2.11a.  CardBorderCrossings  
Anden generation, version 2:  
Oplysninger, der er gemt på et fører- eller værkstedskort, vedr ørende 
køretøjets grænsepassage, når sidstnævnte har passeret et lands  grænse 
(bilag I C, krav 306f og 356f).
  
borderCrossingPointerNewestRecord  er indekset for den senest opda­
terede grænsepassagepost på kortet.  
Tilordnet værdi  er tallet svarende til tælleren i grænsepassageposten på 
kortet, begyndende med »0« for den første forekomst af grænsepa ssage­
posten på kortet i strukturen.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 128  
cardBorderCrossingRecords  er sættet af grænsepassageposterne på 
kortet.  
2.11b.  CardBorderCrossingRecord  
Anden generation, version 2:  
Oplysninger, der er gemt på et fører- eller værkstedskort, vedr ørende 
køretøjets grænsepassage, når sidstnævnte har passeret et lands  grænse 
(bilag I C, krav 147b, 306e og 356e).
  
countryLeft  er det land, som køretøjet har forladt, eller »ingen tilgænge­
lige oplysninger« ifølge bilag I C, krav 147b. »Resten af verde n« 
(NationNumeric-kode »FF«H) anvendes, når køretøjsenheden ikke k an 
fastslå det land, hvor køretøjet befinder sig (hvis det nuværen de land 
f.eks. ikke findes på de lagrede digitale kort).  
countryEntered  er det land, som køretøjet har indlæst, eller det land, 
hvor køretøjet befinder på tidspunktet for isætningen af kortet . »Resten 
af verden« (NationNumeric-kode »FF«H) anvendes, når køretøjsenh eden 
ikke kan fastslå det land, hvor køretøjet befinder sig (hvis de t nuværende 
land f.eks. ikke findes på de lagrede digitale kort).  
gnssPlaceAuthRecord  indeholder oplysninger om køretøjets position, 
når køretøjsenheden har registreret, at køretøjet har passeret et lands 
grænse, eller »ingen tilgængelige oplysninger« ifølge bilag I C , krav 
147b, og dets status for ægthedsbekræftelse.  
vehicleOdometerValue  er køretøjets kilometerstand, når køretøjs­
enheden har registreret, at køretøjet har passeret et lands græ nse, eller 
»ingen tilgængelige oplysninger« ifølge bilag I C, krav 147b.  
▼B 
2.12.  CardCertificate  
Første generation:  
Certifikat for et korts offentlige nøgle.
  
2.13.  CardChipIdentification  
Oplysninger, gemt på et kort, til identifikation af kortets int egrerede 
kreds (IC) (Bilag 1C, krav 249). icSerialNumber identificerer s ammen 
med icManufacturingReferences kortets chip entydigt. icSerialNu mber 
alene identificerer ikke kortets chip entydigt.
  
icSerialNumber  er serienummeret på den integrerede kreds.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 129  
icManufacturingReferences  er id'et på fabrikanten af den integrerede 
kreds.  
2.14.  CardConsecutiveIndex  
Et fortløbende kortindeks (definition h)).
  
Tilordnet værdi : (Se bilag 1C, afsnit 7)  
Rækkefølge af forøgelse: »0, …, 9, A, …, Z, a, …, z«  
2.15.  CardControlActivityDataRecord  
Oplysninger, gemt på et fører- eller værkstedskort, vedrørende den 
seneste kontrol, som føreren har været genstand for (bilag 1C, krav 
274, 299, 327 og 350).
  
controlType  er kontrollens type.  
controlTime  er dato og klokkeslæt for kontrollen.  
controlCardNumber  er FullCardNumber for den kontrollør, som har 
foretaget kontrollen.  
controlVehicleRegistration  er indregistreringsnummer og registrerende 
medlemsstat for det køretøj, i hvilket kontrollen fandt sted.  
controlDownloadPeriodBegin  o g  controlDownloadPeriodEnd  
angiver, ved dataoverførsel, den periode, for hvilken dataoverf ørsel har 
fundet sted.  
2.16.  CardCurrentUse  
Oplysninger om kortets aktuelle anvendelse (bilag 1C, krav 273,  298, 
326 og 349).
  
sessionOpenTime  er det tidspunkt, hvor kortet er indsat med henblik på 
den aktuelle anvendelse. Dette dataelement sættes til nul, når kortet tages 
ud. 
sessionOpenVehicle  er identifikationen af det aktuelt anvendte køretøj 
og bliver sat ved isætning af kortet. Dette dataelement sættes til nul, når 
kortet tages ud.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 130  
2.17.  CardDriverActivity  
Oplysninger, gemt på et fører- eller værkstedskort, vedrørende førerens 
aktiviteter (bilag 1C, krav 267, 268, 292, 293, 321 og 344).
  
activityPointerOldestDayRecord  angiver begyndelsen på lagerpladsen 
(antal bytes fra strengens begyndelse) for den ældste fuldstænd ige døgn­
post i activityDailyRecords-strengen. Maksimumværdien er givet ved 
længden af strengen.  
activityPointerNewestRecord  angiver begyndelsen på lagerpladsen 
(antal bytes fra strengens begyndelse) for den seneste døgnpost  i  
activityDailyRecords-strengen. Maksimumværdien er givet ved 
længden af strengen.  
activityDailyRecords er den plads, der er til rådighed til at g emme data 
vedrørende førerens aktivitet (datastruktur: CardActivityDailyR ecord) for 
hver kalenderdag, hvor kortet har været anvendt.  
Tilordnet værdi : Denne oktetstreng bliver cyklisk fyldt op med 
CardActivityDailyRecord-poster. Ved første gangs brug begynder 
lagringen ved strengens første byte. Alle nye poster bliver hæf tet til 
slutningen af den foregående. Når strengen er fuld, fortsætter lagringen 
ved strengens første byte uafhængigt af, om der eventuelt er en  afbry­
delse inde i et dataelement. Før nye aktivitetsdata placeres i strengen 
(ved at den aktuelle activityDailyRecord bliver større, eller v ed at der 
indsættes en ny activityDailyRecord) som erstatning for ældre a ktivitets­
data, skal activityPointerOldestDayRecord opdateres svarende ti l den nye 
placering af den ældste fuldstændige døgnpost, og activityPrevi ousRe­
cordLength for denne (nye) ældste fuldstændige døgnpost skal nu lstilles.  
2.18.  CardDrivingLicenceInformation  
Oplysninger, gemt på et førerkort, vedrørende kortindehaverens licens­
data (bilag 1C, krav 259 og 284).
  
drivingLicenceIssuingAuthority  er den myndighed, som er ansvarlig 
for udstedelse af førerbeviset.  
drivingLicenceIssuingNation  er nationaliteten af den myndighed, som 
har udstedt førerbeviset.  
drivingLicenceNumber er førerbevisets nummer.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 131  
2.19.  CardEventData  
Første generation:  
Oplysninger gemt på et fører- eller værkstedskort vedrørende hæ ndelser 
knyttet til kortindehaveren (bilag I C, krav 260 og 318).
  
CardEventData  er en sekvens af cardEventRecords, ordnet efter 
stigende EventFaultType (bortset fra poster vedrørende forsøg p å sikker­
hedsbrud, som er samlet i sidste del af sekvensen).  
cardEventRecords  er et sæt hændelsesposter af en given hændelsestype 
(eller kategori ved hændelser bestående i forsøg på sikkerhedsb rud).  
Anden generation:  
Oplysninger gemt på et fører- eller værkstedskort vedrørende hæ ndelser 
knyttet til kortindehaveren (bilag I C, krav 285 og 341).
  
CardEventData  er en sekvens af cardEventRecords, ordnet efter 
stigende EventFaultType (bortset fra poster vedrørende forsøg p å sikker­
hedsbrud, som er samlet i sidste del af sekvensen).  
cardEventRecords  er et sæt hændelsesposter af en given hændelsestype 
(eller kategori ved hændelser bestående i forsøg på sikkerhedsb rud). 
▼B 
2.20.  CardEventRecord  
Oplysninger, gemt på et fører- eller værkstedskort, vedrørende en 
hændelse knyttet til kortindehaveren (bilag 1C, krav 261, 286, 318 og 
341).
  
eventType  er hændelsens type.  
eventBeginTime  er hændelsens startdato og -klokkeslæt.  
eventEndTime  er hændelsens slutdato og -klokkeslæt.  
eventVehicleRegistration  er indregistreringsnummer og registrerende 
medlemsstat for det køretøj, hvor hændelsen er indtruffet.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 132  
2.21.  CardFaultData  
Oplysninger, gemt på et fører- eller værkstedskort, vedrørende fejl 
knyttet til kortindehaveren (bilag 1C, krav 263, 288, 318 og 34 1).
 
CardFaultData  er en sekvens af poster vedrørende fejl ved kontrolappa­
ratet, efterfulgt af en mængde af poster vedrørende kortfejl.  
cardFaultRecords  er mængden af fejlposter af en given fejlkategori 
(kontrolapparat eller kort).  
2.22.  CardFaultRecord  
Oplysninger, gemt på et fører- eller værkstedskort, vedrørende en fejl 
knyttet til kortindehaveren (bilag 1C, krav 264, 289, 318 og 34 1).
 
faultType  er fejlens type.  
faultBeginTime  er fejlens startdato og -klokkeslæt.  
faultEndTime  er fejlens slutdato og -klokkeslæt.  
faultVehicleRegistration  er indregistreringsnummer og registrerende 
medlemsstat for det køretøj, hvor fejlen er indtruffet.  
2.23.  CardIccIdentification  
Oplysninger, gemt på et kort, til identifikation af kortet med integreret 
kreds (IC) (bilag 1C, krav 248).
  
clockStop  er klokstop-tilstand som defineret i tillæg 2.  
cardExtendedSerialNumber  er IC-kortets unikke serienummer som 
videre angivet ved datatypen ExtendedSerialNumber.  
cardApprovalNumber  er kortets typegodkendelsesnummer.  
cardPersonaliserID  er kortets person-ID kodet som ManufacturerCode.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 133  
embedderIcAssemblerId  rummer oplysninger om embedder/IC 
assembler.  
icIdentifier  er datanavnet for kortets IC og IC-fabrikant som defineret i 
ISO/IEC 7816-6.  
2.24.  CardIdentification  
Oplysninger, gemt på et kort, til identifikation af kortet (bil ag 1C, krav 
255, 280, 310, 333, 359, 365, 371 og 377).
  
cardIssuingMemberState  er koden på den medlemsstat, som har 
udstedt kortet.  
cardNumber er kortets nummer.  
cardIssuingAuthorityName  er navnet på den myndighed, der har 
udstedt kortet.  
cardIssueDate  er datoen for udstedelse af kortet til den nuværende 
indehaver.  
cardValidityBegin er kortets første gyldighedsdato.  
cardExpiryDate er kortets udløbsdato.  
▼M3 
2.24a.  CardLoadTypeEntries  
Anden generation, version 2:  
Oplysninger, der er gemt på et fører- eller værkstedskort, vedr ørende 
poster om lasttype ved isætningen af kortet i køretøjsenheden ( bilag 
I C, krav 306j og 356j).
  
loadTypeEntryPointerNewestRecord  er indekset for den senest opda­
terede post om lasttype på kortet.  
Tilordnet værdi : tallet svarende til tælleren i lasttypeposten på kortet, 
begyndende med »0« for den første forekomst af lasttypeposten p å kortet 
i strukturen.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 134  
cardLoadTypeEntryRecords  er den mængde poster, der indeholder 
dato og klokkeslæt for indlæsningen og den indlæste lasttype.  
2.24b.  CardLoadTypeEntryRecord  
Anden generation, version 2:  
Oplysninger, der er gemt på et fører- eller værkstedskort, vedr ørende 
lasttypeændringer ved isætningen af kortet i køretøjsenheden (b ilag 
I C, krav 306i og 356i).
  
timeStamp  er den dato og det klokkeslæt, hvor lasttypen blev indlæst.  
loadTypeEntered  er den indlæste lasttype.  
2.24c.  CardLoadUnloadOperations  
Anden generation, version 2:  
Oplysninger, der er gemt på et fører- eller værkstedskort, vedr ørende 
køretøjets laste-/losseoperationer (bilag I C, krav 306h og 356 h).
 
loadUnloadPointerNewestRecord  er indekset for den senest opdaterede 
post om laste-/losseoperationer.  
Tilordnet værdi : er tallet svarende til tælleren i posten om 
laste-/losseoperationer på kortet, begyndende med »0« for den f ørste 
forekomst af posten om laste-/losseoperationer på kortet i stru kturen.  
cardLoadUnloadRecords  er den mængde poster, der indeholder oplys­
ninger om den udførte operationstype (lastning, losning eller s amtidig 
lastning/losning), dato og klokkeslæt for indlæsning af laste-/ losseopera­
tionen, oplysninger om køretøjets position og køretøjets kilome terstand.  
2.24d.  CardLoadUnloadRecord  
Anden generation, version 2:  
Oplysninger, der er gemt på et fører- eller værkstedskort, vedr ørende 
køretøjets laste-/losseoperationer (bilag I C, krav 306g og 356 g).
 
timeStamp  er dato og klokkeslæt ved begyndelsen af laste-/losseopera­
tionen.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 135  
operationType  er den indlæste operationstype (lastning, losning eller 
samtidig lastning/losning).  
gnssPlaceAuthRecord  indeholder oplysninger om køretøjets position.  
vehicleOdometerValue  er køretøjets kilometerstand ved begyndelsen af 
laste-/losseoperationen.  
▼B 
2.25.  CardMACertificate  
Anden generation:  
Certifikat for et korts offentlige nøgle til gensidig ægthedsbe kræftelse 
med en køretøjsenhed. Dette certifikats opbygning er nærmere be skrevet 
i tillæg 11.
  
2.26.  CardNumber  
Et kortnummer er defineret ved definition g).
  
driverIdentification  er den entydige identifikation af en fører i en 
medlemsstat.  
ownerIdentification  er den entydige identifikation af en virksomhed, et 
værksted eller et kontrolorgan i en medlemsstat.  
cardConsecutiveIndex  er kortets fortløbende indeks.  
cardReplacementIndex  er kortets udskiftningsindeks.  
cardRenewalIndex  er kortets fornyelsesindeks.  
Den første sekvens af valget er egnet til kodning af et førerko rtnummer, 
den anden sekvens af valget er egnet til kodning af værksteds-,  kontrol- 
og virksomhedskortnummer.  
▼M3 
2.26a  CardPlaceAuthDailyWorkPeriod  
Anden generation, version 2:  
Oplysninger, der er gemt på et fører- eller værkstedskort, vedr ørende 
status for ægthedsbekræftelse for steder, hvor den daglige arbe jdstid 
begynder og/eller slutter (bilag I C, krav 306b og 356b).  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 136
  
placeAuthPointerNewestRecord  er indekset for den senest opdaterede 
post med status for ægthedsbekræftelse af sted.  
Tilordnet værdi : Tal svarende til tælleren i posten med status for 
ægthedsbekræftelse af sted, begyndende med »0« for den første f ore­
komst af disse poster i strukturen.  
placeAuthStatusRecords  er mængden af poster, der indeholder status 
for ægthedsbekræftelse for indlæste steder.  
▼B 
2.27.  CardPlaceDailyWorkPeriod  
Oplysninger, gemt på et fører- eller værkstedskort, vedrørende de steder, 
hvor den daglige arbejdstid begynder og/eller slutter (bilag 1C , krav 272, 
297, 325 og 348)
  
placePointerNewestRecord er indekset for den senest opdaterede 
stedpost.  
Tilordnet værdi : Tal svarende til tælleren i stedposten, begyndende med 
»0« for den første forekomst af stedposterne i strukturen.  
placeRecords  er den mængde poster, der indeholder oplysninger om de 
indlæste steder.  
2.28.  CardPrivateKey  
Første generation:  
Et korts private nøgle.
  
2.29.  CardPublicKey  
Et korts offentlige nøgle.
  
▼M1 
2.30.  CardRenewalIndex  
Et kortfornyelsesindeks (definition i)).
  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 137  
Tilordnet værdi : (se kapitel 7 i dette bilag).  
»0« Første udstedelse.  
Rækkefølge af forøgelse: »0, …, 9, A, …, Z«  
▼B 
2.31.  CardReplacementIndex  
Et korterstatningsindeks (definition j)).
  
Tilordnet værdi : (se kapitel VII i dette bilag).  
»0« Oprindeligt kort.  
Rækkefølge af forøgelse: »0, …, 9, A, …, Z«  
2.32.  CardSignCertificate  
Anden generation:  
Certifikat for et korts offentlige nøgle til underskrift. Dette  certifikats 
opbygning er nærmere beskrevet i tillæg 11.
  
2.33.  CardSlotNumber  
Kode, som anvendes til at skelne mellem de to kortpladser i en køre­
tøjsenhed.
  
Tilordnet værdi : Ikke yderligere angivet.  
2.34.  CardSlotsStatus  
Kode, som angiver den type kort, der sidder i køretøjsenhedens to 
kortpladser.
  
Tilordnet værdi  — Oktet udsluttet : »ccccdddd«B  
»cccc«B Identifikation af den type kort, der sidder i medchauf­
førens kortplads  
»dddd«B Identifikation af den type kort, der sidder i førerens 
kortplads  
med følgende identifikationskoder:  
»0000«B intet kort isat  
»0001«B et førerkort isat  
»0010«B et værkstedskort isat  
»0011«B et kontrolkort isat  
»0100«B et virksomhedskort isat.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 138  
2.35.  CardSlotsStatusRecordArray  
Anden generation:  
CardSlotsStatus plus metadata, der anvendes i protokollen for d ataover­
førsel.
  
recordType  angiver postens type (CardSlotsStatus).  Tilordnet værdi : 
Se RecordType.  
recordSize  er størrelsen af CardSlotsStatus i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af CardSlotsStatus-poster.  
2.36.  CardStructureVersion  
Kode, som angiver versionen af den struktur, der er implementer et i et 
takografkort.
  
Tilordnet værdi : »aabb«H:  
»aa«H Indeks for ændringer af strukturen.  
»00«H for applikationer af første generation  
»01«H for applikationer af anden generation  
▼M3 
»bb«H Indeks for ændringer vedrørende brug af de dataele­
menter, der er defineret for strukturen, er givet ved 
den høje byte.  
»00«H for applikationer af første generation  
»00«H for version 1 af applikationer af anden genera­
tion 
»01«H for version 2 af applikationer af anden genera­
tion 
▼B 
2.37.  CardVehicleRecord  
Oplysninger, gemt på et fører- eller værkstedskort, vedrørende en anven­
delsesperiode for et køretøj på en kalenderdag (bilag 1C, krav 269, 294, 
322 og 345).  
Første generation:
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 139  
vehicleOdometerBegin  er køretøjets kilometerstand ved begyndelsen af 
anvendelsesperioden for køretøjet.  
vehicleOdometerEnd  er køretøjets kilometerstand ved slutningen af 
anvendelsesperioden for køretøjet.  
vehicleFirstUse  er startdato og -klokkeslæt for køretøjets 
anvendelsesperiode.  
vehicleLastUse  er slutdato og -klokkeslæt for køretøjets 
anvendelsesperiode.  
vehicleRegistration  er indregistreringsnummer og registrerende 
medlemsstat for køretøjet.  
vuDataBlockCounter er værdien af VuDataBlockCounter ved sidste 
uddragning af køretøjets anvendelsesperiode.  
Anden generation:
  
Ud over dataelementerne for første generation anvendes følgende  
dataelement:  
VehicleIdentificationNumber  er køretøjets identifikationsnummer, der 
refererer til køretøjet som helhed.  
2.38.  CardVehiclesUsed  
Oplysninger, gemt på et fører- eller værkstedskort, vedrørende de køre­
tøjer, der er anvendt af kortindehaveren (bilag 1C, krav 270, 2 95, 323 og 
346).
  
vehiclePointerNewestRecord  er indekset for den senest opdaterede 
køretøjspost.  
Tilordnet værdi : Tal svarende til tælleren i køretøjsposten, begyndende 
med »0« for den første forekomst af køretøjsposterne i struktur en. 
cardVehicleRecords  er den mængde poster, der indeholder oplysninger 
om de anvendte køretøjer.  
2.39.  CardVehicleUnitRecord  
Anden generation:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 140  
Oplysninger, gemt på et fører- eller værkstedskort, vedrørende en 
anvendt køretøjsenhed (bilag 1C, krav 303 og 351).
  
timeStamp  er starten af køretøjsenhedens anvendelsesperiode (dvs. 
første isætning af kortet i køretøjsenheden i den pågældende pe riode).  
manufacturerCode  identificerer fabrikanten af køretøjsenheden.  
deviceID  identificerer en fabrikants køretøjsenheds type. Værdien er 
fabrikantspecifik.  
vuSoftwareVersion  er versionsnummeret på det programmel, der 
anvendes i køretøjsenheden.  
2.40.  CardVehicleUnitsUsed  
▼M3 
Anden generation:  
Oplysninger, der er gemt på et fører- eller værkstedskort, vedr ørende de 
køretøjsenheder, der anvendes af kortindehaveren (bilag I C, kr av 304 
og 352).  
▼B
 
vehiclePointerNewestRecord  er indekset på den senest opdaterede 
køretøjsenhedspost.  
Tilordnet værdi : Tal svarende til tælleren i køretøjsenhedsposten, 
begyndende med »0« for den første forekomst af køretøjsenhedspo sterne 
i strukturen.  
cardVehicleRecords  er den mængde poster, der indeholder oplysninger 
om de anvendte køretøjsenheder.  
2.41.  Attester  
Certifikatet for en offentlig nøgle, udstedt af et certificerin gsorgan.  
Første generation:
  
Tilordnet værdi : Digital underskrift med delvis genfinding af et Certi­
ficateContent i henhold til tillæg 11 (fælles sikkerhedsmekanis mer): 
Signature (128 bytes) || Public Key remainder (58 bytes) || Cer tification 
Authority Reference (8 bytes).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 141  
Anden generation:
  
Tilordnet værdi: Se tillæg 11.  
2.42.  CertificateContent  
Første generation:  
Det (tydelige) indhold af certifikatet for en offentlig nøgle, som fremgår 
af tillæg 11, fælles sikkerhedsmekanismer.
  
certificateProfileIdentifier  er versionen af det tilsvarende certifikat.  
Tilordnet værdi : »01h« for denne version.  
certificationAuthorityReference  angiver den certificeringsmyndighed, 
som udsteder certifikatet. Den angiver desuden denne certificer ingsmyn­
digheds offentlige nøgle.  
certificateHolderAuthorisation  identificerer certifikatindehaverens 
rettigheder.  
certificateEndOfValidity  er den dato, hvor certifikatet udløber 
administrativt.  
certificateHolderReference  identificerer certifikatindehaveren. Den 
henviser desuden til dennes offentlige nøgle.  
publicKey  er den offentlige nøgle, som er certificeret ved det pågæl­
dende certifikat.  
2.43.  CertificateHolderAuthorisation  
Identifikation af en certifikatindehavers rettigheder.
  
Første generation:  
tachographApplicationID  er datanavnet på takografapplikationen.  
Tilordnet værdi : »FFh« »54h« »41h« »43h« »48h« »4Fh«. Denne AID 
er en beskyttet, ikkeregistreret applikationsidentifikator i he nhold til 
ISO/IEC 7816-5.  
equipmentType  er identifikationen af den type udstyr, som certifikatet 
er bestemt til.  
Tilordnet værdi : i overensstemmelse med datatypen EquipmentType. 0, 
hvis certifikatet er fra en medlemsstat.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 142  
Anden generation:  
tachographApplicationID  angiver de seks vigtigste bytes i den tilsva­
rende applikationsidentifikator (AID) for takografkortet af and en gene­
ration. AID for takografkortapplikationen og AID for det ekster ne 
GNSS-udstyr er nærmere beskrevet i afsnit 6.2.  
Tilordnet værdi : »FF 53 4D 52 44 54«  
equipmentType  er identifikationen af den type udstyr af anden genera­
tion, som certifikatet er bestemt til.  
Tilordnet værdi : i overensstemmelse med datatypen EquipmentType.  
2.44.  CertificateRequestID  
Entydig identifikation af en anmodning om certifikat. Den kan o gså 
benyttes som datanavn for et køretøjs offentlige nøgle, hvis se rienum­
meret på den køretøjsenhed, som nøglen er bestemt for, ikke ken des på 
udfærdigelsestidspunktet for certifikatet.
  
requestSerialNumber  er et serienummer på anmodningen om certifi­
katet. Den er entydig for fabrikanten og for måneden nedenfor.  
requestMonthYear  identificerer måned og år for anmodningen om 
certifikatet.  
Tilordnet værdi : Binært kodet decimaltal for måned (to cifre) og år (to 
sidste cifre).  
crIdentifier  er et datanavn, som har til formål at skelne en anmodning 
om certifikat fra et udvidet serienummer.  
Tilordnet værdi : »FFh«.  
manufacturerCode  er den numeriske kode for den producent, der 
anmoder om certifikatet.  
2.45.  CertificationAuthorityKID  
Datanavn for den offentlige nøgle tilhørende en certificeringsm yndighed 
(en medlemsstat eller den europæiske certificeringsmyndighed).
  
nationNumeric  er den numeriske kode for certificeringsmyndigheden.  
nationAlpha  er den alfanumeriske nationskode for certificeringsmyndig­
heden.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 143  
keySerialNumber  er et serienummer, som er bestemt til at skelne 
mellem certificeringsmyndighedens forskellige nøgler i tilfælde , hvor 
der skiftes nøgle.  
additionalInfo  er et felt på to bytes til supplerende kodning (specifik for 
certificeringsmyndigheden).  
caIdentifier  er et datanavn, som har til formål at skelne datanavnet for 
en certificeringsmyndigheds nøgle fra andre nøgledatanavne.  
Tilordnet værdi : »01h«.  
2.46.  CompanyActivityData  
Oplysninger, gemt på et virksomhedskort, vedrørende de aktivite ter, der 
udføres med kortet (bilag 1C, krav 373 og 379)
  
companyPointerNewestRecord  er indekset på den senest opdaterede 
companyActivityRecord.  
Tilordnet værdi : Tal svarende til tælleren i virksomhedsaktivitetsposten, 
begyndende med »0« for første forekomst af virksomhedsaktivitet s­
posten i strukturen.  
companyActivityRecords  er mængden af alle virksomhedsaktivitets­
poster.  
companyActivityRecord  er sekvensen af oplysninger vedrørende én 
virksomhedsaktivitet.  
companyActivityType  er virksomhedsaktivitetens type.  
companyActivityTime  er klokkeslæt og dato for virksomhedsaktivi­
teten.  
cardNumberInformation  er kortnummer og kortudstedende medlems­
stat for det kort, hvis data er blevet overført (i givet fald).  
vehicleRegistrationInformation  er indregistreringsnummer og registre­
rende medlemsstat for det køretøj, hvis data er blevet overført , eller som 
er blevet låst ind eller ud.  
downloadPeriodBegin  o g downloadPeriodEnd  angiver den periode, 
hvor eventuel overførsel af data fra køretøjsenheden har fundet  sted.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 144  
2.47.  CompanyActivityType  
Kode, som angiver en aktivitet udøvet af en virksomhed, som ben ytter 
sit virksomhedskort.
  
2.48.  CompanyCardApplicationIdentification  
Oplysninger, gemt på et virksomhedskort, til identifikation af kortets 
applikation (bilag 1C, krav 369 og 375).
  
typeOfTachographCardId  angiver den implementerede korttype.  
cardStructureVersion  angiver den version af strukturen, som er imple­
menteret i kortet.  
noOfCompanyActivityRecords  er det antal virksomhedsaktivitets­
poster, som kan lagres på kortet.  
▼M3 
2.48a.  CompanyCardApplicationIdentificationV2  
Anden generation, version 2:  
Oplysninger, der er gemt på et virksomhedskort, vedrørende iden tifika­
tion af kortets applikation (bilag I C, krav 375a).
  
lengthOfFollowingData  er antallet af byte i posten.  
vuConfigurationLengthRange  er antallet af byte i et takografkort, der 
er tilgængeligt til lagring af køretøjsenhedens konfigurationer . 
▼B 
2.49.  CompanyCardHolderIdentification  
Oplysninger, gemt på et virksomhedskort, til identifikation af kortinde­
haveren (bilag 1C, krav 372 og 378)
  
companyName  er navnet på den virksomhed, der er indehaver af kortet.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 145  
companyAddress  er adressen på den virksomhed, der er indehaver af 
kortet.  
cardHolderPreferredLanguage  er det af kortindehaveren foretrukne 
sprog.  
2.50.  ControlCardApplicationIdentification  
Oplysninger, gemt på et kontrolkort, til identifikation af kort ets applika­
tion (bilag 1C, krav 357 og 363)
  
typeOfTachographCardId  angiver den implementerede korttype.  
cardStructureVersion  angiver den version af strukturen, som er imple­
menteret i kortet.  
noOfControlActivityRecords  er det antal kontrolaktivitetsposter, som 
kan lagres på kortet.  
▼M3 
2.50a.  ControlCardApplicationIdentificationV2  
Anden generation, version 2:  
Oplysninger, der er gemt på et kontrolkort, vedrørende identifi kation af 
kortets applikation (bilag I C, krav 363a).
  
lengthOfFollowingData  er antallet af byte i posten.  
vuConfigurationLengthRange  er antallet af byte i et takografkort, der 
er tilgængeligt til lagring af køretøjsenhedens konfigurationer . 
▼B 
2.51.  ControlCardControlActivityData  
Oplysninger, gemt på et kontrolkort, vedrørende de kontrolaktiv iteter, 
der udføres med kortet (bilag 1C, krav 361 og 367).
  
controlPointerNewestRecord  er indekset på den senest opdaterede 
kontrolaktivitetspost.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 146  
Tilordnet værdi : Tal svarende til tælleren i kontrolaktivitetsposten, 
begyndende med »0« for første forekomst af kontrolaktivitetspos ten i 
strukturen.  
controlActivityRecords  er det fuldstændige sæt kontrolaktivitetsposter.  
controlActivityRecord  er sekvensen af oplysninger vedrørende én 
kontrol.  
controlType  er kontrollens type.  
controlTime  er dato og klokkeslæt for kontrollen.  
controlledCardNumber  er kortnummer og kortudstedende medlemsstat 
for det kort, som kontrolleres.  
controlledVehicleRegistration  er indregistreringsnummer og registre­
rende medlemsstat for det køretøj, i hvilket kontrollen fandt s ted. 
controlDownloadPeriodBegin  og controlDownloadPeriodEnd  angiver 
den periode, for hvilken data derefter er blevet overført.  
2.52.  ControlCardHolderIdentification  
Oplysninger, gemt på et kontrolkort, til identifikation af kort indehaveren 
(bilag 1C, krav 360 og 366).
  
controlBodyName  er navnet på kortindehaverens kontrolorgan.  
controlBodyAddress  er adressen på kortindehaverens kontrolorgan.  
cardHolderName er efternavn og fornavn(e) på kontrolkortets indehaver.  
cardHolderPreferredLanguage  er det af kortindehaveren foretrukne 
sprog.  
2.53.  ControlType  
Kode, som angiver de aktiviteter, som udføres under en kontrol.  Denne 
datatype er knyttet til krav 126, 274, 299, 327 og 350 i bilag 1C.
 
Første generation:  
Tilordnet værdi  — Oktet udsluttet : »cvpdxxxx«B (8 bits)  
»c«B dataoverførsel for kort:  
»0«B: Kortets data blev ikke overført under denne 
kontrolaktivitet  
»1«B: Kortets data blev overført under denne kontrol­
aktivitet  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 147  
»v«B dataoverførsel for køretøjsenhed:  
»0«B: Køretøjsenhedens data blev ikke overført under 
denne kontrolaktivitet  
»1«B: Køretøjsenhedens data blev overført under denne 
kontrolaktivitet  
»p«B udprintning:  
»0«B: Der blev ikke udprintet under denne kontrolakti­
vitet 
»1«B: Der blev udprintet under denne kontrolaktivitet  
»d«B visning på skærm:  
»0«B: Der blev ikke anvendt visning på skærm under 
denne kontrolaktivitet  
»1«B: Der blev anvendt visning på skærm under denne 
kontrolaktivitet  
»xxxx«B Ikke anvendt.  
Anden generation:  
Tilordnet værdi  — Oktet udsluttet : »cvpdexxx«B (8 bits)  
»c«B dataoverførsel for kort:  
»0«B: Kortets data blev ikke overført under denne 
kontrolaktivitet  
»1«B: Kortets data blev overført under denne kontrol­
aktivitet  
»v«B dataoverførsel for køretøjsenhed:  
»0«B: Køretøjsenhedens data blev ikke overført under 
denne kontrolaktivitet  
»1«B: Køretøjsenhedens data blev overført under denne 
kontrolaktivitet  
»p«B udprintning:  
»0«B: Der blev ikke udprintet under denne kontrolakti­
vitet 
»1«B: Der blev udprintet under denne kontrolaktivitet  
»d«B visning på skærm:  
»0«B: Der blev ikke anvendt visning på skærm under 
denne kontrolaktivitet  
»1«B: Der blev anvendt visning på skærm under denne 
kontrolaktivitet  
»e«B kalibreringskontrol ved vejsiden:  
»0«B: kalibreringsparametre blev ikke kontrolleret 
under denne kontrolaktivitet  
»1«B: kalibreringsparametre blev kontrolleret under 
denne kontrolaktivitet  
»xxx«B RFU  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 148  
2.54.  CurrentDateTime  
Kontrolapparatets aktuelle klokkeslæt og dato.
  
Tilordnet værdi : Ikke yderligere angivet.  
2.55.  CurrentDateTimeRecordArray  
Anden generation:  
Aktuel dato og aktuelt klokkeslæt plus metadata, der anvendes i  proto­
kollen for dataoverførsel.
  
recordType  angiver postens type (CurrentDateTime).  Tilordnet værdi : 
Se RecordType.  
recordSize  er størrelsen af CurrentDateTime i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af aktuelle dato- og klokkeslætsposter.  
2.56.  DailyPresenceCounter  
En tæller, som er gemt på et fører- eller værkstedskort, og hvi s værdi 
øges med én for hver kalenderdag, kortet har været indsat i en køretøjs­
enhed. Denne datatype er knyttet til krav i bilag 1C, krav 266,  299, 320 
og 343.
  
Tilordnet værdi : Fortløbende nummer med maksimumværdi = 9 999, 
hvorefter der tælles forfra fra 0. Ved første udstedelse af kor tet stilles 
tælleren på nul.  
2.57.  Datef  
Dato, angivet i numerisk, let printbart format.
  
Tilordnet værdi:  
yyyy År  
mm Måned  
dd Dag  
»00000000«H datoangivelse udtrykkeligt udeladt.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 149  
2.58.  DateOfDayDownloaded  
Anden generation:  
Dato og klokkeslæt for overførslen.
  
Tilordnet værdi : Ikke yderligere angivet.  
2.59.  DateOfDayDownloadedRecordArray  
Anden generation:  
Dato og klokkeslæt for overførslen plus metadata, der anvendes i proto­
kollen for dataoverførsel.
  
recordType  angiver postens type (DateOfDayDownloaded).  Tilordnet 
værdi : Se RecordType.  
recordSize  er størrelsen af CurrentDateTime i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er dato og klokkeslæt for overførselsposterne.  
2.60.  Afstand  
En tilbagelagt distance (resultat af beregning af forskellen me llem to 
værdier af køretøjets kilometerstand).
  
Tilordnet værdi : Binær uden fortegn. Værdi i km med området 0 til 
9 999 km.  
▼M3 
2.60a.  DownloadInterfaceVersion  
Anden generation, version 2:  
Kode, der angiver versionen af en køretøjsenheds overførselsgræ nse­
flade.
  
Tilordnet værdi : »aabb«H:  
»aa«H »00«H: anvendes ikke  
»01«H: Køretøjsenhed af anden generation  
»bb«H »00«H: anvendes ikke  
»01«H: version 2 af køretøjsenhed af anden generation.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 150  
2.61.  DriverCardApplicationIdentification  
Oplysninger, gemt på et førerkort, til identifikation af kortet s applikation 
(bilag 1C, krav 253 og 278).  
Første generation:
  
typeOfTachographCardId  angiver den implementerede korttype.  
cardStructureVersion  angiver den version af strukturen, som er imple­
menteret i kortet.  
noOfEventsPerType  er antal hændelser af hver hændelsestype, som kan 
gemmes på kortet.  
noOfFaultsPerType  er antal fejl af hver fejltype, som kan gemmes på 
kortet.  
activityStructureLength  angiver antal bytes til rådighed til lagring af 
aktivitetsposter.  
noOfCardVehicleRecords  er antallet af køretøjsposter, som kan 
gemmes på kortet.  
noOfCardPlaceRecords  er antallet af steder, som kan gemmes på 
kortet.  
Anden generation:  
▼M1
 
Ud over dataelementerne for første generation anvendes følgende  
dataelementer:  
noOfGNSSADRecords  er det antal GNSS-poster for kumuleret køretid, 
som kan gemmes på kortet.  
noOfSpecificConditionRecords  er det antal poster vedrørende særlige 
omstændigheder, som kan gemmes på kortet.  
noOfCardVehicleUnitRecords  er det antal poster om anvendte køre­
tøjsenheder, som kan gemmes på kortet.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 151  
2.61a.  DriverCardApplicationIdentificationV2  
Anden generation, version 2:  
Oplysninger, der er gemt på et førerkort, vedrørende identifika tion af 
kortets applikation (bilag I C, krav 278a).
  
lengthOfFollowingData  er antallet af byte i posten.  
noOfBorderCrossingRecords  er det antal grænsepassageposter, der kan 
lagres på førerkortet.  
noOfLoadUnloadRecords  er det antal laste-/losseposter, der kan lagres 
på førerkortet.  
noOfLoadTypeEntryRecords  er det antal lasttypeposter, der kan lagres 
på førerkortet.  
vuConfigurationLengthRange  er antallet af byte i et takografkort, der 
er tilgængeligt til lagring af køretøjsenhedens konfigurationer . 
▼B 
2.62.  DriverCardHolderIdentification  
Oplysninger, gemt på et førerkort, til identifikation af kortin dehaveren 
(bilag 1C, krav 256 og 281).
  
cardHolderName er efternavn og fornavn(e) på førerkortets indehaver.  
cardHolderBirthDate er fødselsdato for førerkortets indehaver.  
cardHolderPreferredLanguage  er det af kortindehaveren foretrukne 
sprog.  
▼M3 
2.63.  DSRCSecurityData  
Anden generation:  
En definition af denne datatype findes i tillæg 11.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 152  
2.64.  EGFCertificate  
Anden generation:  
Certifikat for det eksterne GNSS-udstyrs offentlige nøgle til g ensidig 
ægthedsbekræftelse med en køretøjsenhed. Dette certifikats opby gning 
er nærmere beskrevet i tillæg 11.
  
2.65.  EmbedderIcAssemblerId  
Rummer oplysninger om IC embedder.
  
countryCode  er landekoden på to bogstaver for den såkaldte »module 
embedder« i overensstemmelse med ISO 3166.  
moduleEmbedder  identificerer den såkaldte »module embedder«.  
manufacturerInformation  er til fabrikantens interne brug.  
2.66.  EntryTypeDailyWorkPeriod  
Kode, der benyttes til at skelne mellem start og slut på det in dlæste sted 
for den daglige arbejdstid og omstændigheden ved indlæsning.  
Første generation:
  
Tilordnet værdi : I henhold til ISO/IEC 8824-1  
▼M3 
Anden generation
  
Tilordnet værdi : i henhold til ISO/IEC8824-1.  
▼B 
2.67.  EquipmentType  
Kode, som benyttes til at skelne mellem forskellige typer udsty r til 
takografapplikationen.
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 153  
Første generation:
  
Tilordnet værdi : I henhold til ISO/IEC 8824-1.  
Værdien 0 er reserveret til at angive en medlemsstat eller EU i  
CHA-feltet i certifikaterne.  
Anden generation:  
▼M1 
De samme værdier som for første generation anvendes med følgend e 
tilføjelser:
  
Note 1:  Værdierne for anden generation for pladen, adapteren og den 
eksterne GNSS-forbindelse samt værdierne for første generation af køre­
tøjsenheden og bevægelsessensoren kan anvendes i SealRecord, hv is det 
er relevant.  
Note 2:  I feltet CardHolderAuthorisation (CHA) på et certifikat for 
anden generation skal værdierne 1), 2), og 6) fortolkes som ang ivende 
et certifikat for gensidig ægthedskontrol for den pågældende ud styrstype. 
For at angive det respektive certifikat for at generere en digi tal under­
skrift skal værdierne 17), 18) eller 19) anvendes.  
▼B 
2.68.  EuropeanPublicKey  
Første generation:  
Den europæiske offentlige nøgle.
  
2.69.  EventFaultRecordPurpose  
Kode, som forklarer, hvorfor en hændelse eller en fejl er bleve t 
registreret.
  
Tilordnet værdi:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 154
  
en af de 10 seneste hændelser eller fejl 
den længstvarende hændelse for en af de 10 seneste dage, den er  forekommet 
en af de 5 længstvarende hændelser inden for de sidste 365 dage  
den seneste hændelse for en af de 10 seneste dage, den er forek ommet 
den alvorligste hændelse for en af de 10 seneste dage, den er f orekommet 
en af de 5 alvorligste hændelser inden for de sidste 365 dage 
den første hændelse eller fejl, som er forekommet efter sidste kalibrering 
en aktiv/igangværende hændelse eller fejl 
RFU 
Fabrikantspecifik  
2.70.  EventFaultType  
Kode, som bestemmer en hændelse eller en fejl.
  
Tilordnet værdi:  
Første generation:
  
Generelle hændelser 
Ingen yderligere detaljer 
Isætning af ugyldigt kort 
Kortkonflikt 
Tidsoverlapning 
Kørsel uden behørigt kort 
Isætning af kort under kørslen 
Seneste kortsession ikke korrekt afsluttet 
Overskridelse af tilladt hastighed 
Afbrydelse i strømforsyningen 
Fejl ved køredata 
Køretøjsbevægelseskonflikt 
RFU
  
Hændelser, som er knyttet til køretøjsenheden og består i forsø g på sikkerhedsbrud 
Ingen yderligere detaljer 
Ægthedsbekræftelse for bevægelsessensor lykkedes ikke 
Ægthedsbekræftelse for takografkort lykkedes ikke 
Ubeføjet ændring af bevægelsessensor 
Integritetsfejl på indlæste kortdata 
Integritetsfejl på lagrede brugerdata 
Fejl ved intern dataoverførsel 
Ubehørig åbning af hus 
Hardware-sabotage 
RFU
  
Hændelser, som knyttet til føleren og består i forsøg på sikker hedsbrud 
Ingen yderligere detaljer 
Ægthedskontrol lykkedes ikke 
Integritetsfejl på lagrede data 
Fejl ved intern dataoverførsel 
Ubehørig åbning af hus 
Hardware-sabotage 
RFU
  
Fejl ved kontrolapparat 
Ingen yderligere detaljer 
Intern fejl i køretøjsenhed 
Printerfejl 
Displayfejl 
Dataoverførselsfejl 
Følerfejl 
RFU ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 155
  
Kortfejl 
Ingen yderligere detaljer 
RFU
  
RFU
  
Fabrikantspecifik.  
▼M3 
Anden generation, version 1:  
▼M1
 Generelle hændelser 
Ingen yderligere detaljer 
Isætning af ugyldigt kort 
Kortkonflikt 
Tidsoverlapning 
Kørsel uden behørigt kort 
Isætning af kort under kørslen 
Seneste kortsession ikke korrekt afsluttet 
Overskridelse af tilladt hastighed 
Afbrydelse i strømforsyningen 
Fejl ved køredata 
Køretøjsbevægelseskonflikt 
Tidskonflikt (GNSS kontra køretøjsenhedens interne ur) 
Fejl ved kommunikation med udstyr til fjernkommunikation 
Manglende positionsoplysninger fra GNSS-modtager 
Fejl ved kommunikation med det eksterne GNSS-udstyr 
RFU
  
Hændelser, som er knyttet til køretøjsenheden og består i forsø g på sikkerhedsbrud 
Ingen yderligere detaljer 
Ægthedsbekræftelse for bevægelsessensor lykkedes ikke 
Ægthedsbekræftelse for takografkort lykkedes ikke 
Ubeføjet ændring af bevægelsessensor 
Integritetsfejl på indlæste kortdata 
Integritetsfejl på lagrede brugerdata 
Fejl ved intern dataoverførsel 
Ubehørig åbning af hus 
Hardware-sabotage 
Registrering af manipulation af GNSS 
Ægthedsbekræftelse for eksternt GNSS-udstyr lykkedes ikke 
Certifikat for eksternt GNSS-udstyr udløbet 
til ‘1F’H RFU
  
Hændelser, som knyttet til føleren og består i forsøg på sikker hedsbrud 
Ingen yderligere detaljer 
Ægthedskontrol lykkedes ikke 
Integritetsfejl på lagrede data 
Fejl ved intern dataoverførsel 
Ubehørig åbning af hus 
Hardware-sabotage 
RFU ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 156
  
Fejl ved kontrolapparat 
Ingen yderligere detaljer 
Intern fejl i køretøjsenhed 
Printerfejl 
Displayfejl 
Dataoverførselsfejl 
Følerfejl 
Intern GNSS-modtager 
Eksternt GNSS-udstyr 
Udstyr til fjernkommunikation 
ITS-grænseflade 
RFU
  
Kortfejl 
Ingen yderligere detaljer 
RFU
  
RFU
  
Fabrikantspecifik.  
▼M3 
Anden generation, version 2:  
»0x«H Generelle hændelser  
»00«H Ingen yderligere detaljer  
»01«H Isætning af ugyldigt kort  
»02«H Kortkonflikt  
»03«H Tidsoverlapning  
»04«H Kørsel uden behørigt kort  
»05«H Isætning af kort under kørslen  
»06«H Seneste kortsession ikke korrekt afsluttet  
»07«H Overskridelse af tilladt hastighed  
»08«H Afbrydelse i strømforsyningen  
»09«H Fejl ved køredata  
»0A«H Køretøjsbevægelseskonflikt  
»0B«H Tidskonflikt (GNSS kontra køretøjsenhedens 
interne ur)  
»0C«H Fejl ved kommunikation med udstyr til fjernkom­
munikation  
»0D«H Manglende positionsoplysninger fra GNSS- 
modtager  
»0E«H Fejl ved kommunikation med det eksterne 
GNSS-udstyr  
»0F«H GNSS-anomali  
»1x«H Hændelser, som er knyttet til køretøjsenheden og 
består i forsøg på sikkerhedsbrud  
»10«H Ingen yderligere detaljer  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 157  
»11«H Ægthedsbekræftelse for bevægelsessensor 
lykkedes ikke  
»12«H Ægthedsbekræftelse for takografkort lykkedes 
ikke 
»13«H Ubeføjet ændring af bevægelsessensor  
»14«H Integritetsfejl på indlæste kortdata.  
»15«H Integritetsfejl på lagrede brugerdata  
»16«H Fejl ved intern dataoverførsel  
»17«H Ubehørig åbning af hus  
»18«H Hardware-sabotage  
»19«H Registrering af manipulation af GNSS  
»1A«H Ægthedsbekræftelse for eksternt GNSS-udstyr 
lykkedes ikke  
»1B«H Certifikat for eksternt GNSS-udstyr udløbet  
»1C«H Uoverensstemmelse mellem køredata og lagrede 
føreraktivitets-data  
»1D«H til »1F«H RFU,  
»2x«H Hændelser, som knyttet til føleren og består i 
forsøg på sikkerhedsbrud  
»20«H Ingen yderligere detaljer  
»21«H Ægthedskontrol lykkedes ikke  
»22«H Integritetsfejl på lagrede data  
»23«H Fejl ved intern dataoverførsel  
»24«H Ubehørig åbning af hus  
»25«H Hardware-sabotage  
»26«H til »2F«H RFU,  
»3x«H Fejl ved kontrolapparat  
»30«H Ingen yderligere detaljer  
»31«H Intern fejl i køretøjsenhed  
»32«H Printerfejl  
»33«H Displayfejl  
»34«H Dataoverførselsfejl  
»35«H Følerfejl  
»36«H Intern GNSS-modtager  
»37«H Eksternt GNSS-udstyr  
»38«H Udstyr til fjernkommunikation  
»39«H ITS-grænseflade  
»3A«H Intern fejl i sensor  
»3B«H til »3F«H RFU,  
»4x«H Kortfejl  
»40«H Ingen yderligere detaljer  
»41«H til »4F«H RFU,  
»50«H til »7F«H RFU,  
»80«H til »FF«H Fabrikantspecifik.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 158  
2.71.  ExtendedSealIdentifier  
Anden generation:  
Det udvidede datanavn for en plombe identificerer entydigt plom ben 
(bilag I C, krav 401).
  
manufacturerCode  er en kode for fabrikanten af plomben.  Tilordnet 
værdi:  se databaseregistrering, der skal forvaltes af Kommissionen (s e 
https://dtc.jrc.ec.europa.eu).  
sealIdentifier  er et datanavn for plomben, som er unikt for fabrikanten.  
Tilordnet værdi:  alfanumerisk nummer, som er unikt i fabrikantens regi 
[ISO8859-1].  
▼B 
2.72.  ExtendedSerialNumber  
Entydig identifikation af et stykke udstyr. Kan desuden bruge s om data­
navn for en offentlig nøgle for udstyr.  
Første generation:
  
serialNumber  er udstyrets serienummer. Det er entydigt for udstyret, 
fabrikanten, udstyrets type og måneden og året nedenfor.  
monthYear  er identifikationen af fabrikationsmåned og -år (eller af 
tildelingen af serienummer).  
Tilordnet værdi : Binært kodet decimaltal for måned (to cifre) og år (to 
sidste cifre).  
type er et datanavn for udstyrets type.  
Tilordnet værdi : Fabrikantspecifik, med »FFh«-reserveret værdi.  
manufacturerCode  er den numeriske kode, som identificerer en fabri­
kant af typegodkendt udstyr.  
Anden generation:
  
serialNumber : Se første generation  
monthYear : Se første generation  
type angiver udstyrets type  
manufacturerCode : Se første generation  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 159  
2.73.  FullCardNumber  
Kode, som fuldstændig identificerer et takografkort.
  
cardType  er takografkortets type.  
cardIssuingMemberState  er koden på den medlemsstat, der har udstedt 
kortet.  
cardNumber  er kortnummeret.  
2.74.  FullCardNumberAndGeneration  
Anden generation:  
Kode, som fuldstændig identificerer et takografkort og dets gen eration.
  
fullcardNumber  identificerer takografkortet.  
generation  angiver det anvendte takografkorts generation.  
2.75.  Generation  
Anden generation:  
Angiver det anvendte takografkorts generation.
  
Tilordnet værdi:  
»00«H RFU  
»01«H Første generation  
»02«H Anden generation  
»03«H .. »FF«H RFU  
2.76.  GeoCoordinates  
▼M3 
Anden generation:  
Geo-koordinaterne kodes som heltal. Disse heltal er multipla af  
kodningen ± DDMM.M for breddegrad og ± DDDMM.M for længde­
grad. Her angiver henholdsvis ± DD og ± DDD graderne, mens MM.M  
angiver minutterne. Længdegrad og breddegrad for en ukendt posi tion 
skal angives som Hex »7FFFFF« (Decimal 8388607).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 160
  
latitude  kodes som et multiplum (faktor 10) af gengivelsen af 
± DDMM.M.  
longitude  kodes som et multiplum (faktor 10) af gengivelsen af 
± DDDMM.M.  
2.77.  GNSSAccuracy  
Anden generation:  
GNSS-placeringsdataenes nøjagtighed (definition eee)). Denne nø jag­
tighed kodes som heltal og er et multiplum (faktor 10) af værdi en X.Y 
i GSA NMEA-sætningen.
  
▼M1 
2.78.  GNSSAccumulatedDriving  
Anden generation:  
Oplysninger gemt på et fører- eller værkstedskort vedrørende kø retøjets 
GNSS-position, hvis den kumulerede køretid når op på et multipl um af 
tre timer (bilag I C, krav 306 og 354).
  
gnssADPointerNewestRecord  er indekset på den senest opdaterede 
GNSS-post for kumuleret køretid.  
Tilordnet værdi:  Tal svarende til tælleren i GNSS-posten for kumuleret 
køretid, begyndende med »0« for den første forekomst af GNSS-po sten 
for kumuleret køretid i strukturen.  
gnssAccumulatedDrivingRecords  er mængden af poster, der indeholder 
dato og klokkeslæt, hvor den kumulerede køretid når op på et mu ltiplum 
af tre timer, og oplysninger om køretøjets position.  
2.79.  GNSSAccumulatedDrivingRecord  
Anden generation:  
Oplysninger gemt på et fører- eller værkstedskort vedrørende kø retøjets 
GNSS-position, hvis den kumulerede køretid når op på et multipl um af 
tre timer (bilag I C, krav 305 og 353).
  
timeStamp  er den dato og det klokkeslæt, hvor den kumulerede køretid 
når op på et multiplum af tre timer.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 161  
gnssPlaceRecord  indeholder oplysninger om køretøjets position.  
vehicleOdometerValue  er kilometerstanden, når den kumulerede køretid 
når op på et multiplum af tre timer.  
▼M3 
2.79a.  GNSSAuthAccumulatedDriving  
Anden generation, version 2:  
Oplysninger, der er gemt på et fører- eller værkstedskort, vedr ørende 
status for ægthedsbekræftelse af køretøjets GNSS-positioner, hv is den 
akkumulerede køretid når op på et multiplum af tre timer (bilag  I C, 
krav 306d og 356d).
  
gnssAuthADPointerNewestRecord  er indekset for den senest opdate­
rede post med status for ægthedsbekræftelse af GNSS-position.  
Tilordnet værdi  er tallet svarende til tælleren i posten med status for 
ægthedsbekræftelse af GNSS-position begyndende med »0« for den 
første forekomst af posten med status for ægthedsbekræftelse af  
GNSS-position i strukturen.  
gnssAuthStatusADRecords  er mængden af poster, der indeholder dato 
og klokkeslæt, hvor den akkumulerede køretid når op på et multi plum af 
tre timer, og status for ægthedsbekræftelse af GNSS-positionen.  
2.79b.  GNSSAuthStatusADRecord  
Anden generation, version 2:  
Oplysninger, der er gemt på et fører- eller værkstedskort, vedr ørende 
status for ægthedsbekræftelse af køretøjets GNSS-position, hvis  den 
akkumulerede køretid når op på et multiplum af tre timer (bilag  I C, 
krav 306c og 356c). Andre oplysninger vedrørende selve 
GNSS-positionen lagres i en anden post (se 2.79 GNSSAccumulated ­
DrivingRecord).
  
timeStamp  er den dato og det klokkeslæt, hvor den akkumulerede 
køretid når op på et multiplum af tre timer (samme dato og klok keslæt 
som i den tilsvarende GNSSAccumulatedDrivingRecord).  
authenticationStatus  er status for ægthedsbekræftelse af GNSS-posi­
tionen, når den akkumulerede køretid når op på et multiplum af tre timer.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 162  
2.79c.  GNSSPlaceAuthRecord  
Anden generation, version 2:  
Oplysninger om køretøjets GNSS-position (bilag I C, krav 108, 1 09, 
110, 296, 306a, 306c, 306e, 306g, 356a, 356c, 356e og 356g).
  
timeStamp  er dato og klokkeslæt for registrering af GNSS-positionen.  
gnssAccuracy  er GNSS-placeringsdataenes nøjagtighed.  
geoCoordinates  er den position, der er registreret ved brug af GNSS.  
authenticationStatus  er status for ægthedsbekræftelse af GNSS-posi­
tionen, da den blev fastlagt.  
▼B 
2.80.  GNSSPlaceRecord  
Anden generation:  
Oplysninger om køretøjets GNSS-position (bilag 1C, krav 108, 10 9, 110, 
296, 305, 347 og 353).
  
timeStamp  er dato og klokkeslæt for registrering af GNSS-positionen.  
gnssAccuracy  er GNSS-placeringsdataenes nøjagtighed.  
geoCoordinates  er den position, der er registreret ved brug af GNSS.  
2.81.  HighResOdometer  
Køretøjets kilometerstand: Samlet distance tilbagelagt af køret øjet i dettes 
driftstid.
  
Tilordnet værdi : Binær uden fortegn. Talværdi i 1/200 km inden for 
området 0 til 21 055 406 km.  
2.82.  HighResTripDistance  
En distance, som er tilbagelagt i løbet af en hel tur eller en del heraf.
  
Tilordnet værdi : Binær uden fortegn. Talværdi i 1/200 km inden for 
området 0 til 21 055 406 km.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 163  
2.83.  HolderName  
En kortindehavers efternavn og fornavn(e).
  
holderSurname  er indehaverens efternavn. Titler indgår ikke i 
efternavnet.  
Tilordnet værdi : Når et kort ikke er personligt, indeholder holderSur­
name samme oplysninger som et companyName eller workshopName 
eller controlBodyName.  
holderFirstNames  er indehaverens fornavn(e) og initialer.  
▼M3 
2.84.  Forbeholdt fremtidig brug  
▼B 
Anden generation:  
Information om, hvorvidt GNSS-modtageren er intern eller ekster n i 
forhold til køretøjsenheden. Sandt betyder, at GNSS-modtageren er 
intern. Falsk betyder, at GNSS-modtageren er ekstern.
  
2.85.  K-ConstantOfRecordingEquipment  
Kontrolapparatets konstant (definition m)).
  
Tilordnet værdi : Impulser pr. kilometer inden for området 0 til 64 255 
impulser/km.  
▼M1 
2.86.  KeyIdentifier  
Et entydigt datanavn for en offentlig nøgle. Benyttes til at he nvise til og 
vælge nøgle. Den identificerer desuden indehaveren af nøglen.
  
Det første valg er egnet til henvisning til den offentlige nøgl e for en 
køretøjsenhed, et takografkort eller et eksternt GNSS-udstyr.  
Det andet valg er egnet til henvisning til den offentlige nøgle  for en 
køretøjsenhed (når køretøjsenhedens serienummer ikke kan oplyse s på 
tidspunktet for udfærdigelse af certifikatet).  
Det tredje valg er egnet til henvisning til den offentlige nøgl e for en 
medlemsstat.  
▼B 
2.87.  KMWCKey  
Anden generation:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 164  
AES-nøglen og den tilhørende version, som anvendes til parring af køre­
tøjsenhed og bevægelsessensor. Nærmere oplysninger findes i til læg 11.
  
kMWCKey  er længden af AES-nøglen sammenkædet med den nøgle, 
der bruges til parring af køretøjsenhed og bevægelsessensor.  
keyVersion  keyVersion er AES-nøglens version.  
2.88.  Language  
Kode, som identificerer et sprog.
  
Tilordnet værdi : En kode bestående af to minuskler i overensstemmelse 
med ISO 639.  
2.89.  LastCardDownload  
Dato og klokkeslæt, gemt på førerkortet, for seneste dataoverfø rsel af 
kort (til andre formål end kontrol) (bilag 1C, krav 257 og 282) . Denne 
dato kan ajourføres af en køretøjsenhed eller enhver kortlæser.
  
Tilordnet værdi : Ikke yderligere angivet.  
▼M3 
2.89a.  LengthOfFollowingData  
Anden generation, version 2:  
Længdeindikator for poster, der kan udvides.
  
Tilordnet værdi : Se tillæg 2.  
▼B 
2.90.  LinkCertificate  
Anden generation:  
Linkcertifikatet mellem nøglepar i europæiske rodnøglecentre.
  
▼M3 
2.90a.  LoadType  
Anden generation, version 2:  
Kode, der identificerer en indlæst lasttype.
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 165  
Tilordnet værdi : 
»00«H Udefineret lasttype  
»01«H Gods  
»02«H Passagerer  
»03«H .. »FF«H RFU.  
▼B 
2.91.  L-TyreCircumference  
Effektiv dækperiferi (definition u)).
  
Tilordnet værdi : Binær uden fortegn, værdi i 1/8 mm inden for området 
0 til 8 031 mm.  
▼M1 
2.92.  MAC  
Anden generation:  
En kryptografisk kontrolsum af 8, 12 eller 16 bytes længde svar ende til 
de krypteringsprogrammer, der er angivet i tillæg 11.
  
▼B 
2.93.  ManualInputFlag  
Kode, som fastslår, om en kortindehaver manuelt har eller ikke har 
indlæst føreraktiviteter ved isætning af kort (bilag 1B, krav 0 81, og 
bilag 1C, krav 102).
  
Tilordnet værdi : Ikke yderligere angivet.  
2.94.  ManufacturerCode  
Kode, som identificerer en fabrikant af typegodkendt udstyr.
  
Det laboratorium, der forestår interoperabilitetsprøverne, føre r og offent­
liggør listen over fabrikantkoder på sit websted (bilag 1C, kra v 454).  
Der tildeles midlertidigt ManufacturerCode til udviklere af tak ografudstyr 
efter ansøgning til det laboratorium, der forestår interoperabi litetsprø­
verne.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 166  
2.95.  ManufacturerSpecificEventFaultData  
Anden generation:  
Fabrikantspecifikke fejlkoder, som sikrer enklere fejlanalyse o g vedli­
geholdelse af køretøjsenheder.
  
manufacturerCode  identificerer fabrikanten af køretøjsenheden.  
manufacturerSpecificErrorCode  er en fejlkode, der gælder specifikt for 
fabrikanten.  
2.96.  MemberStateCertificate  
Certifikat for en medlemsstats offentlige nøgle, udstedt af den  europæ­
iske certificeringsmyndighed.
  
2.97.  MemberStateCertificateRecordArray  
Anden generation:  
Medlemsstatens certifikat plus metadata, der anvendes i protoko llen for 
dataoverførsel.
  
recordType  angiver postens type (MemberStateCertificate).  Tilordnet 
værdi : Se RecordType.  
recordSize  er størrelsen af MemberStateCertificate i bytes.  
noOfRecords  er antallet af poster i mængden af poster. Værdien skal 
sættes til 1, da certifikaterne kan have forskellig længde.  
records  er mængden af medlemsstaters certifikater.  
2.98.  MemberStatePublicKey  
Første generation:  
En medlemsstats offentlige nøgle.
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 167  
2.99.  Name  
Et navn.
  
codePage  angiver et tegnsæt, der er defineret i afsnit 4.  
name  er et navn, som er indkodet med det angivne tegnsæt.  
2.100.  NationAlpha  
Den alfabetiske henvisning til et land skal være i overensstemm else med 
de nationalitetsbetegnelser, der anvendes på køretøjer i intern ational 
færdsel (FN-Wienerkonventionen om vejtrafik af 1968).
  
NationAlpha- og NationNumeric-koderne skal være opført på en li ste på 
webstedet for det laboratorium, som er udpeget til at udføre in teropera­
bilitetsprøverne, jf. bilag 1C, krav 440.  
2.101.  NationNumeric  
Numerisk henvisning til et land.
  
Tilordnet værdi : se datatype 2.100 (NationAlpha).  
Enhver ændring eller opdatering af den NationAlpha- eller Natio nNu­
meric -specifikation, der er beskrevet i ovennævnte afsnit, for etages først, 
efter at det udpegede laboratorium har indhentet udtalelser fra  fabrikanter 
af typegodkendte køretøjsenheder til digitale takografer og int elligente 
takografer.  
▼M3 
2.101a.  NoOfBorderCrossingRecords  
Anden generation, version 2:  
Antal grænsepassageposter, der kan lagres på et fører- eller væ rksteds­
kort.
 
Tilordnet værdi : se tillæg 2.  
▼B 
2.102.  NoOfCalibrationRecords  
Antal kalibreringsposter, som kan gemmes på et værkstedskort.  
Første generation:
  
Tilordnet værdi : se tillæg 2.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 168  
Anden generation:
  
Tilordnet værdi : se tillæg 2.  
2.103.  NoOfCalibrationsSinceDownload  
Tæller, som angiver det samlede antal kalibreringer, der er udf ørt med et 
værkstedskort siden sidste dataoverførsel for kortet (bilag 1C,  krav 317 
og 340).
  
Tilordnet værdi : Ikke yderligere angivet.  
2.104.  NoOfCardPlaceRecords  
Antal stedposter, som kan gemmes på et fører- eller værkstedsko rt. 
Første generation:
  
Tilordnet værdi : se tillæg 2.  
Anden generation:
  
Tilordnet værdi : se tillæg 2.  
2.105.  NoOfCardVehicleRecords  
Antal anvendte køretøjer, som kan gemmes på et fører- eller vær ksteds­
kort.
 
Tilordnet værdi : se tillæg 2.  
2.106.  NoOfCardVehicleUnitRecords  
Anden generation:  
Antal anvendte køretøjsenheder, som kan gemmes på et fører- ell er værk­
stedskort.
  
Tilordnet værdi : se tillæg 2.  
2.107.  NoOfCompanyActivityRecords  
Antal virksomhedsaktivitetsposter, som kan gemmes på et virksom heds­
kort.
 
Tilordnet værdi : se tillæg 2.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 169  
2.108.  NoOfControlActivityRecords  
Antal kontrolaktivitetsposter, som kan gemmes på et kontrolkort .
 
Tilordnet værdi : se tillæg 2.  
2.109.  NoOfEventsPerType  
Antal hændelser af hver hændelsestype, som kan gemmes på et kor t.
 
Tilordnet værdi : se tillæg 2.  
2.110.  NoOfFaultsPerType  
Antal fejl af hver fejltype, som kan gemmes på et kort.
  
Tilordnet værdi : se tillæg 2.  
▼M1 
2.111.  NoOfGNSSADRecords  
Anden generation:  
Antal GNSS-poster for kumuleret køretid, som kan gemmes på et k ort.
 
Tilordnet værdi:  se tillæg 2.  
▼M3 
2.111a.  NoOfLoadUnloadRecords  
Anden generation, version 2:  
Antal laste-/losseposter, der kan lagres på et kort.
  
Tilordnet værdi : se tillæg 2.  
▼B 
2.112.  NoOfSpecificConditionRecords  
Anden generation:  
Antal poster vedrørende særlige omstændigheder, som kan gemmes på et 
kort.
 
Tilordnet værdi : se tillæg 2.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 170  
2.112a.  NoOfLoadTypeEntryRecords  
Anden generation, version 2:  
Antal lasttypeposter, der kan lagres på et fører- eller værkste dskort.
  
Tilordnet værdi : se tillæg 2.  
▼B 
2.113.  OdometerShort  
Køretøjets kilometerstand i kortform.
  
Tilordnet værdi : Binær uden fortegn. Værdi i km inden for området 0 
til 9 999 999 km.  
2.114.  OdometerValueMidnight  
Køretøjets kilometerstand ved midnat i et givet døgn (bilag 1B,  krav 090, 
og bilag 1C, krav 113).
  
Tilordnet værdi : Ikke yderligere angivet.  
▼M3 
2.114a.  OperationType  
Anden generation, version 2:  
Kode, der identificerer en indlæst operationstype.
  
Tilordnet værdi : 
»00«H RFU,  
»01«H Lasteoperation  
»02«H Losseoperation  
»03«H Samtidig laste-/losseoperation  
»04«H .. »FF«H RFU.  
▼B 
2.115.  OdometerValueMidnightRecordArray  
Anden generation:  
OdometerValueMidnight plus metadata, der anvendes i protokollen  for 
dataoverførsel.
  
recordType  angiver postens type (OdometerValueMidnight).  Tilordnet 
værdi : Se RecordType.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 171  
recordSize  er størrelsen af OdometerValueMidnight i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af OdometerValueMidnight-poster.  
2.116.  OverspeedNumber  
Antal hændelser med overskridelse af tilladt hastighed siden se neste 
kontrol for overskridelse af tilladt hastighed.
  
Tilordnet værdi : 0 betyder, at der ikke er forekommet hændelser med 
overskridelse af tilladt hastighed siden seneste kontrol for ov erskridelse 
af tilladt hastighed, 1 betyder, at der har været én hændelse m ed over­
skridelse af tilladt hastighed siden seneste kontrol for oversk ridelse af 
tilladt hastighed, … 255 betyder, at der har været 255 eller fl ere 
hændelser med overskridelse af tilladt hastighed siden seneste kontrol 
for overskridelse af tilladt hastighed.  
▼M3 
2.116a.  PlaceAuthRecord  
Oplysninger vedrørende et sted, hvor en daglig arbejdstid begyn der eller 
slutter (bilag I C, krav 108, 271, 296, 324 og 347).  
Anden generation, version 2:
  
entryTime  er en dato og et klokkeslæt knyttet til indlæsningen.  
entryTypeDailyWorkPeriod  er indlæsningens type.  
dailyWorkPeriodCountry  er det indlæste land.  
dailyWorkPeriodRegion  er den indlæste region.  
vehicleOdometerValue  er kilometerstanden på tidspunktet for indlæs­
ning af stedet.  
entryGNSSPlaceAuthRecord  er den registrerede position, status for 
ægthedsbekræftelse af GNSS og tidspunkt.  
2.116b.  PlaceAuthStatusRecord  
Anden generation, version 2:  
Oplysninger, der er gemt på et fører- eller værkstedskort, som angiver 
status for ægthedsbekræftelse af et sted, hvor den daglige arbe jdstid 
begynder eller slutter (bilag I C, krav 306a og 356a). Andre op lysninger 
vedrørende selve stedet lagres i en anden post (se 2.117 PlaceR ecord).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 172
  
entryTime  er en dato og et klokkeslæt vedrørende indlæsningen. 
(samme dato og klokkeslæt som i den tilsvarende PlaceRecord).  
authenticationStatus  er status for ægthedsbekræftelse af den registrerede 
GNSS-position.  
▼B 
2.117.  PlaceRecord  
Oplysninger vedrørende et sted, hvor en daglig arbejdsperiode b egynder 
eller slutter (bilag 1C, krav 108, 271, 296, 324 og 347).  
Første generation:
  
entryTime  er en dato og et klokkeslæt knyttet til indlæsningen.  
entryTypeDailyWorkPeriod  er indlæsningens type.  
dailyWorkPeriodCountry  er det indlæste land.  
dailyWorkPeriodRegion  er den indlæste region.  
vehicleOdometerValue  er kilometerstanden på tidspunktet for indlæs­
ning af stedet.  
Anden generation:
  
Ud over parametrene for første generation anvendes følgende par ameter:  
entryGNSSPlaceRecord  er det registrerede sted og tidspunkt.  
▼M3 
2.117a.  PositionAuthenticationStatus  
Anden generation, version 2:
  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 173  
Tilordnet værdi  (se tillæg 12):  
»00«H Ikke bekræftet (se tillæg 12, krav GNS_39)  
»01«H Bekræftet (se tillæg 12, krav GNS_39)  
»02«H .. »FF«H RFU.  
▼B 
2.118.  PreviousVehicleInfo  
Oplysninger vedrørende det foregående køretøj, som føreren anve ndte, 
da han satte sit kort i en køretøjsenhed (bilag 1B, krav 081, o g bilag 1C, 
krav 102).  
Første generation:
  
vehicleRegistrationIdentification  er indregistreringsnummer og registre­
rende medlemsstat for køretøjet.  
cardWithdrawalTime  er dato og klokkeslæt for udtagning af kortet.  
Anden generation:
  
Ud over dataelementerne for første generation anvendes følgende  
dataelement:  
vuGeneration  angiver køretøjsenhedens generation.  
2.119.  PublicKey  
Første generation:  
En offentlig RSA-nøgle.
  
rsaKeyModulus  er nøgleparrets modulus.  
rsaKeyPublicExponent  er nøgleparrets offentlige eksponent.  
2.120.  RecordType  
Anden generation:  
Henvisning til en posttype. Denne datatype bruges i RecordArray s.
 ▼M3
02016R0799 — DA — 21.08.2023 — 003.001 — 174  
Tilordnet værdi:
  
► (1) M1 
► (2) M3 ActivityChangeInfo 
CardSlotsStatus 
CurrentDateTime 
MemberStateCertificate 
OdometerValueMidnight 
DateOfDayDownloaded 
SensorPaired 
Signature 
SpecificConditionRecord 
VehicleIdentificationNumber 
VehicleRegistrationNumber 
VuCalibrationRecord 
VuCardIWRecord 
VuCardRecord 
VuCertificate 
VuCompanyLocksRecord 
VuControlActivityRecord 
VuDetailedSpeedBlock 
VuDownloadablePeriod 
VuDownloadActivityData 
VuEventRecord  
►M1 VuGNSSADRecord ◄ 
VuITSConsentRecord 
VuFaultRecord 
VuIdentification 
VuOverSpeedingControlData 
VuOverSpeedingEventRecord 
VuPlaceDailyWorkPeriodRecord 
VuTimeAdjustmentGNSSRecord 
VuTimeAdjustmentRecord 
VuPowerSupplyInterruptionRecord 
SensorPairedRecord 
SensorExternalGNSSCoupledRecord  
►M3 VuBorderCrossingRecord 
VuLoadUnloadRecord 
VehicleRegistrationIdentification 
RFU ◄ 
Fabrikantspecifik.  
2.121.  RegionAlpha  
Alfabetisk henvisning til en region i en given stat.
  
Første generation:  
Tilordnet værdi:
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 175  
Anden generation:  
RegionAlpha-koderne skal være opført på en liste på webstedet f or det 
laboratorium, som er udpeget til at udføre interoperabilitetspr øverne.  
2.122.  RegionNumeric  
Numerisk henvisning til en region i en given stat.
  
Første generation:  
Tilordnet værdi:
  
Anden generation:  
RegionNumeric-koderne skal være opført på en liste på webstedet  for det 
laboratorium, som er udpeget til at udføre interoperabilitetspr øverne.  
2.123.  RemoteCommunicationModuleSerialNumber  
Anden generation:  
Serienummeret på modulet til fjernkommunikation
  
2.124.  RSAKeyModulus  
Første generation:  
Modulus for et RSA-nøglepar.
  
Tilordnet værdi : Uspecificeret.  
2.125.  RSAKeyPrivateExponent  
Første generation:  
Den private eksponent for et RSA-nøglepar.
  
Tilordnet værdi : Uspecificeret.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 176  
2.126.  RSAKeyPublicExponent  
Første generation:  
Den offentlige eksponent for et RSA-nøglepar.
  
Tilordnet værdi : Uspecificeret.  
2.127.  RtmData  
Anden generation:  
En definition af denne datatype findes i tillæg 14.  
2.128.  SealDataCard  
Anden generation:  
Denne datatype, som lagrer oplysninger om de plomber, der er fa stgjort 
til de forskellige komponenter i et køretøj, er beregnet til la gring på et 
kort. Denne datatype er knyttet til bilag 1C, krav 337.
  
noOfSealRecords  er antallet af poster i SealRecords.  
sealRecords  er mængden af plombeposter.  
2.129.  SealDataVu  
Anden generation:  
Denne datatype, som lagrer oplysninger om de plomber, der er fa stgjort 
til de forskellige komponenter i et køretøj, er beregnet til la gring i en 
køretøjsenhed.
  
sealRecords  er mængden af plombeposter. Hvis der er mindre end fem 
plomber til rådighed, skal værdien af EquipmentType i alle ikke - 
anvendte sealRecords sættes til 16, dvs. ikke anvendt.  
2.130.  SealRecord  
Anden generation:  
Denne datatype lagrer oplysninger om en plombe, der er fastgjor t til en 
komponent. Denne datatype er knyttet til bilag 1C, krav 337.
  
equipmentType  angiver den udstyrstype, som plomben er fastgjort til.  
extendedSealIdentifier  er datanavnet på den plombe, der er fastgjort til 
udstyret.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 177  
2.131.  SensorApprovalNumber  
Følerens typegodkendelsesnummer.  
Første generation:
  
Tilordnet værdi : Uspecificeret.  
Anden generation:
  
Tilordnet værdi:  
Godkendelsesnummeret skal tilvejebringes som offentliggjort på 
Europa-Kommissionens relevante websted, dvs. f.eks. med eventue lle 
bindestreger. Godkendelsesnummeret skal være venstrejusteret.  
2.132.  SensorExternalGNSSApprovalNumber  
Anden generation:  
Typegodkendelsesnummeret på det eksterne GNSS-udstyr.
  
Tilordnet værdi:  
Godkendelsesnummeret skal tilvejebringes som offentliggjort på 
Europa-Kommissionens relevante websted, dvs. f.eks. med eventue lle 
bindestreger. Godkendelsesnummeret skal være venstrejusteret.  
2.133.  SensorExternalGNSSCoupledRecord  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, til identifikation af de t eksterne 
GNSS-udstyr, som er koblet sammen med køretøjsenheden (bilag 1C , 
krav 100).
  
sensorSerialNumber  er serienummeret på det eksterne GNSS-udstyr, 
som er koblet sammen med køretøjsenheden.  
sensorApprovalNumber  er godkendelsesnummeret på det pågældende 
eksterne GNSS-udstyr.  
sensorCouplingDate  er datoen for det pågældende eksterne 
GNSS-udstyrs kobling med køretøjsenheden.  
2.134.  SensorExternalGNSSIdentification  
Anden generation:  
Oplysninger til identifikation af det eksterne GNSS-udstyr (bil ag 1C, 
krav 98).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 178
  
sensorSerialNumber  er det udvidede serienummer på det eksterne 
GNSS-udstyr.  
sensorApprovalNumber  er godkendelsesnummeret på det eksterne 
GNSS-udstyr.  
sensorSCIdentifier  er datanavnet på det eksterne GNSS-udstyrs 
sikkerhedskomponent.  
sensorOSIdentifier  er datanavnet på det eksterne GNSS-udstyrs 
operativsystem.  
2.135.  SensorExternalGNSSInstallation  
Anden generation:  
Oplysninger, der er lagret i eksternt GNSS-udstyr, om montering  af det 
eksterne GNSS-udstyrs føler (bilag 1C, krav 123).
  
sensorCouplingDateFirst  er datoen for den første sammenkobling af det 
eksterne GNSS-udstyr med en køretøjsenhed.  
firstVuApprovalNumber  er godkendelsesnummeret på den første køre­
tøjsenhed, som blev koblet sammen med det eksterne GNSS-udstyr.  
firstVuSerialNumber  er serienummeret på den første køretøjsenhed, 
som er samparret med det eksterne GNSS-udstyr.  
sensorCouplingDateCurrent  er datoen for den aktuelle sammenkobling 
af det eksterne GNSS-udstyr med en køretøjsenhed.  
currentVuApprovalNumber  er godkendelsesnummeret på den køretøjs­
enhed, som aktuelt er koblet sammen med det eksterne GNSS-udsty r. 
currentVUSerialNumber  er serienummeret på den køretøjsenhed, som 
aktuelt er koblet sammen med det eksterne GNSS-udstyr.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 179  
2.136.  SensorExternalGNSSOSIdentifier  
Anden generation:  
Datanavnet på det eksterne GNSS-udstyrs operativsystem.
  
Tilordnet værdi : fabrikantspecifik.  
2.137.  SensorExternalGNSSSCIdentifier  
Anden generation:  
Denne type anvendes f.eks. til at identificere det eksterne GNS S-udstyrs 
kryptografiske modul.  
Datanavnet på det eksterne GNSS-udstyrs sikkerhedskomponent.
  
Tilordnet værdi : specifik for komponentfabrikanten.  
2.138.  SensorGNSSCouplingDate  
Anden generation:  
Dato for en sammenkobling af det eksterne GNSS-udstyr med en kø re­
tøjsenhed.
  
Tilordnet værdi : Uspecificeret.  
2.139.  SensorGNSSSerialNumber  
Anden generation:  
Denne type bruges til at lagre GNSS-modtagerens serienummer, bå de når 
den sidder i køretøjsenheden, og når den sidder uden for enhede n. 
GNSS-modtagerens serienummer.
  
2.140.  SensorIdentification  
Oplysninger, gemt på en bevægelsessensor, til identifikation af  bevægel­
sessensoren (bilag 1B, krav 077, og bilag 1C, krav 95).
  
sensorSerialNumber  er det udvidede serienummer på bevægelsessen­
soren (hvori reservedelsnummer og fabrikantkode indgår).  
sensorApprovalNumber  er godkendelsesnummeret på bevægelsessen­
soren.  
sensorSCIdentifier  er datanavnet på bevægelsessensorens sikkerheds­
komponent.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 180  
sensorOSIdentifier  er datanavnet på bevægelsessensorens styresystem.  
2.141.  SensorInstallation  
Oplysninger, gemt på en bevægelsessensor, vedrørende montering af 
bevægelsessensoren (bilag 1B, krav 099, og bilag 1C, krav 122).
  
sensorPairingDateFirst  er datoen for første samparring af bevægelses­
sensoren med en køretøjsenhed.  
firstVuApprovalNumber  er godkendelsesnummeret på den første køre­
tøjsenhed, som er samparret med bevægelsessensoren.  
firstVuSerialNumber  er serienummeret på den første køretøjsenhed, 
som er samparret med bevægelsessensoren.  
sensorPairingDateCurrent  er datoen for den aktuelle samparring af 
bevægelsessensoren med en køretøjsenhed.  
currentVuApprovalNumber  er godkendelsesnummeret på den køretøjs­
enhed, som aktuelt er samparret med bevægelsessensoren.  
currentVUSerialNumber  er serienummeret på den køretøjsenhed, som 
aktuelt er samparret med bevægelsessensoren.  
2.142.  SensorInstallationSecData  
Oplysninger, gemt på et værkstedskort, vedrørende sikkerhedsdat a, som 
er nødvendige til samparring af bevægelsessensorer med køretøjs enheder 
(bilag 1C, krav 308 og 331).  
Første generation:
  
Tilordnet værdi : I henhold til ISO 16844-3.  
Anden generation:  
Som beskrevet i tillæg 11 skal et værkstedskort kunne lagre op til tre 
nøgler til parring af køretøjsenhed og bevægelsessensor. Disse nøgler har 
forskellige versioner.
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 181  
2.143.  SensorOSIdentifier  
Datanavn på bevægelsessensorens styresystem.
  
Tilordnet værdi : fabrikantspecifik.  
2.144.  SensorPaired  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, til identifikation af de n bevæ­
gelsessensor, som er samparret med køretøjsenheden (bilag 1B, k rav 079, 
og bilag 1C, krav 97).
  
sensorSerialNumber  er serienummeret på den bevægelsessensor, som 
aktuelt er samparret med køretøjsenheden.  
sensorApprovalNumber  er godkendelsesnummeret på den bevægelses­
sensor, som aktuelt er samparret med køretøjsenheden.  
sensorPairingDateFirst  er datoen for første samparring mellem en køre­
tøjsenhed og den bevægelsessensor, som aktuelt er samparret med  køre­
tøjsenheden.  
2.145.  SensorPairedRecord  
Anden generation:  
Oplysninger, der er lagret i en køretøjsenhed, vedrørende ident ifikationen af 
en bevægelsessensor der parres med køretøjsenheden (bilag 1C, k rav 97)
  
sensorSerialNumber  er serienummeret på en bevægelsessensor, der er 
samparret med køretøjsenheden.  
sensorApprovalNumber  er typegodkendelsesnummeret for den pågæl­
dende bevægelsessensor.  
sensorPairingDate  er datoen, hvor den pågældende bevægelsessensor er 
samparret med køretøjsenheden.  
2.146.  SensorPairingDate  
Datoen for samparring af bevægelsessensoren med en køretøjsenhe d.
 
Tilordnet værdi : Uspecificeret.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 182  
2.147.  SensorSCIdentifier  
Datanavnet på bevægelsessensorens sikkerhedskomponent.
  
Tilordnet værdi : specifik for komponentfabrikanten.  
2.148.  SensorSerialNumber  
Serienummeret på bevægelsessensoren.
  
2.149.  Signature  
En digital underskrift.  
Første generation:
  
i overensstemmelse med tillæg 11 (fælles sikkerhedsmekanismer).  
Anden generation:
  
Tilordnet værdi : i overensstemmelse med tillæg 11, Fælles sikkerheds­
mekanismer.  
2.150.  SignatureRecordArray  
Anden generation:  
En mængde af underskrifter plus metadata, der bruges i protokol len for 
dataoverførsel.
  
recordType  er postens type (Signature).  Tilordnet værdi : Se Record­
Type.  
recordSize  er størrelsen af Signature i bytes.  
noOfRecords  er antallet af poster i mængden af poster. Værdien skal 
sættes til 1, da underskrifterne kan have forskellig længde.  
records  er mængden af underskrifter.  
2.151.  SimilarEventsNumber  
Antal tilsvarende hændelser for ét givet døgn (bilag 1B, krav 0 94, og 
bilag 1C, krav 117).
  
Tilordnet værdi : 0 anvendes ikke, 1 betyder, at der det pågældende 
døgn kun er indtruffet og registreret én hændelse af den pågæld ende 
type, 2 betyder, at der er registreret to hændelser af den pågæ ldende 
type (kun én er registreret), … 255 betyder, at der er registre ret 255 
eller flere hændelser af den pågældende type den pågældende dag . ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 183  
2.152.  SpecificConditionRecord  
Oplysninger, gemt på et førerkort, et værkstedskort eller en kø retøjs­
enhed der vedrører en særlig omstændighed (bilag 1C, krav 130, 276, 
301, 328 og 355).
  
entryTime  er dato og klokkeslæt for indlæsningen.  
specificConditionType  er den kode, som identificerer den særlige 
omstændighed.  
2.153.  SpecificConditions  
Oplysninger, gemt på et førerkort, et værkstedskort eller en kø retøjs­
enhed, der vedrører en særlig omstændighed (bilag 1C, krav 131,  277, 
302, 329 og 356).  
Anden generation:
  
conditionPointerNewestRecord  er indekset på den senest opdaterede 
post vedrørende særlige omstændigheder.  
Tilordnet værdi : Tal svarende til tælleren i posten vedrørende særlige 
omstændigheder, begyndende med »0« for første forekomst af post en 
vedrørende særlige omstændigheder i strukturen.  
specificConditionRecords  er den mængde poster, der indeholder oplys­
ninger om de registrerede særlige omstændigheder.  
2.154.  SpecificConditionType  
Kode, som identificerer en særlig omstændighed (bilag 1B, krav 050b, 
105a, 212a og 230a, og bilag 1C, krav 62).
  
Første generation:  
Tilordnet værdi:  
»00«H RFU  
»01«H Uden for gyldighedsområde — Start  
»02«H Uden for gyldighedsområde — Slut  
»03«H Overfart med færge/tog  
»04«H .. »FF«H RFU  
Anden generation:  
Tilordnet værdi:  
»00«H RFU  
»01«H Uden for gyldighedsområde — Start  
»02«H Uden for gyldighedsområde — Slut  
»03«H Overfart med færge/tog — Start  
»04«H Overfart med færge/tog — Slut  
»05«H .. »FF«H RFU  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 184  
2.155.  Speed  
Køretøjets hastighed (km/t).
  
Tilordnet værdi : kilometer i timen inden for området 0 til 220 km/t.  
2.156.  SpeedAuthorised  
Maksimal tilladelig hastighed for køretøjet (definition bb)).
  
2.157.  SpeedAverage  
Gennemsnitshastighed i en forud fastlagt periode (km/t).
  
2.158.  SpeedMax  
Maksimumhastighed målt i et forud fastlagt tidsrum.
  
▼M3 
2.158a.  TachographCardsGen1Suppression  
Anden generation, version 2:  
Muligheden for en køretøjsenhed af anden generation for at anve nde 
fører-, kontrol- og virksomhedskort af første generation (se ti llæg 15, 
MIG_002).
  
Tilordnet værdi:  
»0000«H Køretøjsenheden kan anvende takografkort af 
første generation (standardværdi)  
»A5E3«H Køretøjsenheden kan ikke anvende takografkort 
af første generation  
Alle andre værdier Ikke anvendt.  
▼B 
2.159.  TachographPayload  
Anden generation:  
En definition af denne datatype findes i tillæg 14.  
▼M1 
2.160.  Forbeholdt fremtidig brug  
▼B 
2.161.  TDesSessionKey  
Første generation:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 185  
En tredobbelt DES-sessionsnøgle.
  
Tilordnet værdi : Ikke yderligere angivet.  
▼M1 
2.162.  TimeReal  
Kode for et kombineret dato- og klokkeslætfelt, hvor dato og kl okkeslæt 
er angivet som sekunder siden 00h.00m.00s. den 1. januar 1970 U TC.
 
Tilordnet værdi  — Oktet udsluttet : Antal sekunder siden midnat den 
1. januar 1970 UTC.  
Den maksimale værdi af dato/klokkeslæt er året 2106.  
▼B 
2.163.  TyreSize  
Dækdimensionsbetegnelser.
  
Tilordnet værdi : i overensstemmelse med direktiv 92/23 (EØF) af 
31. marts 1992, EFT L129, s. 95.  
2.164.  VehicleIdentificationNumber  
Køretøjets identifikationsnummer med henvisning til køretøjet s om 
helhed, normalt chassisnummeret.
  
Tilordnet værdi : Som defineret i ISO 3779.  
2.165.  VehicleIdentificationNumberRecordArray  
Anden generation:  
VIN plus metadata, der anvendes i protokollen for dataoverførse l.
 
recordType  er postens type (VehicleIdentificationNumber).  Tilordnet 
værdi : Se RecordType.  
recordSize  er størrelsen af VehicleIdentificationNumber i bytes.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 186  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af VIN-numre.  
2.166.  VehicleRegistrationIdentification  
Identifikation af et køretøj, entydig for Europa (indregistreri ngsnummer 
og medlemsstat).
  
vehicleRegistrationNation  er den stat, hvor køretøjet er indregistreret.  
vehicleRegistrationNumber  er køretøjets indregistreringsnummer 
(VRN).  
▼M3 
2.166a.  VehicleRegistrationIdentificationRecordArray  
Anden generation, version 2:  
Køretøjets indregistreringsnummer plus metadata som anvendt i o ver­
førselsprotokollen.
  
recordType  angiver posttypen (VehicleRegistrationIdentification).  
Tilordnet værdi : se RecordType.  
recordSize  er størrelsen af VehicleRegistrationIdentification i byte.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af poster med indregistreringsnummer.  
▼B 
2.167.  VehicleRegistrationNumber  
Køretøjets indregistreringsnummer (VRN). Indregistreringsnummer et 
tildeles af registreringsmyndigheden.
  
codePage  angiver et tegnsæt, der er defineret i afsnit 4.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 187  
vehicleRegNumber  er et indregistreringsnummer, som er indkodet med 
det angivne tegnsæt.  
Tilordnet værdi : Landespecifik.  
2.168.  VehicleRegistrationNumberRecordArray  
▼M3 
Anden generation, version 1:  
▼B 
VRN plus metadata, der anvendes i protokollen for dataoverførse l.
 
recordType  er postens type (VehicleRegistrationNumber).  Tilordnet 
værdi : Se RecordType.  
recordSize  er størrelsen af VehicleRegistrationNumber i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af VRN-numre.  
2.169.  VuAbility  
Anden generation:  
Oplysninger, gemt i en køretøjsenhed, vedrørende køretøjsenhede ns 
mulighed for at bruge takografkort af første generation (bilag 1C, krav 
121).
  
Tilordnet værdi  — Oktet udsluttet : »xxxxxxxa«B (8 bit)  
For muligheden for at understøtte første generation:  
»a«B Mulighed for at understøtte takografkort af første 
generation:  
»0«B Første generation understøttes  
»1«B Generation1 understøttes ikke  
»xxxxxxx«B RFU  
2.170.  VuActivityDailyData  
Første generation:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 188  
Oplysninger, gemt på en køretøjsenhed, vedrørende skift af akti vitet 
og/eller skift af kørestatus og/eller skift af kortstatus for e n given kalen­
derdag (bilag 1B, krav 084, og bilag 1C, krav 105, 106 og 107),  samt 
kortlæserstatus kl. 00:00 den pågældende dag.
  
noOfActivityChanges  er antallet af ActivityChangeInfo-ord i mængden 
activityChangeInfos.  
activityChangeInfos  er den mængde ActivityChangeInfo-ord, som for 
det pågældende døgn er gemt i køretøjsenheden. Den omfatter alt id to 
ActivityChangeInfo-ord, som angiver status for de to kortlæsere  kl. 
00:00 den pågældende dag.  
2.171.  VuActivityDailyRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende skift af akti vitet 
og/eller skift af kørestatus og/eller skift af kortstatus for e n given kalen­
derdag (bilag 1C, krav 105, 106 og 107), samt kortlæserstatus k l. 00:00 
den pågældende dag.
  
recordType  er postens type (ActivityChangeInfo).  Tilordnet værdi : Se 
RecordType.  
recordSize  er størrelsen af ActivityChangeInfo i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er den mængde ActivityChangeInfo-ord, som for det pågæl­
dende døgn er gemt i køretøjsenheden. Den omfatter altid to Act ivity­
ChangeInfo-ord, som angiver status for de to kortlæsere kl. 00: 00 den 
pågældende dag.  
2.172.  VuApprovalNumber  
Køretøjsenhedens typegodkendelsesnummer.  
Første generation:
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 189  
Tilordnet værdi : Uspecificeret.  
Anden generation:
  
Tilordnet værdi:  
Godkendelsesnummeret skal tilvejebringes som offentliggjort på 
Europa-Kommissionens relevante websted, dvs. f.eks. med eventue lle 
bindestreger. Godkendelsesnummeret skal være venstrejusteret.  
2.173.  VuCalibrationData  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende kalibreringer ne af 
kontrolapparatet (bilag 1B, krav 098).
  
noOfVuCalibrationRecords  er antallet af poster indeholdt i 
vuCalibrationRecords-mængden.  
vuCalibrationRecords  er mængden af kalibreringsposter.  
2.174.  VuCalibrationRecord  
Oplysninger, gemt på en køretøjsenhed, vedrørende en kalibrerin g af 
kontrolapparatet (bilag 1B, krav 098, og bilag 1C, krav 119 og 120).  
Første generation:
  
calibrationPurpose  er formålet med kalibreringen.  
workshopName, workshopAddress er værkstedets navn og adresse.  
workshopCardNumber  identificerer det værkstedskort, der er anvendt 
ved kalibreringen.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 190  
workshopCardExpiryDate  er kortets udløbsdato.  
vehicleIdentificationNumber  er køretøjets identifikationsnummer.  
vehicleRegistrationIdentification  indeholder køretøjets indregistrerings­
nummer og den indregistrerende medlemsstat.  
wVehicleCharacteristicConstant  er køretøjets vejdrejetal.  
kConstantOfRecordingEquipment  er kontrolapparatets konstant.  
lTyreCircumference  er den effektive dækperiferi.  
tyreSize  er dimensionsbetegnelsen for de dæk, der er monteret på køre­
tøjet.  
authorisedSpeed  er køretøjets tilladte hastighed.  
oldOdometerValue, newOdometerValue  er gammel og ny 
kilometerstand.  
oldTimeValue, newTimeValue  er gammel og ny værdi af dato og 
klokkeslæt.  
nextCalibrationDate  er datoen for næste kalibrering af den type, som i 
CalibrationPurpose foreskrives at skulle udføres af kontrolmynd igheden.  
▼M3 
Anden generation, version 1:  
▼B
 
Ud over dataelementerne for første generation anvendes følgende  
dataelement:  
sealDataVu  angiver oplysninger om de plomber, der er fastgjort til 
forskellige komponenter på køretøjet.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 191  
Anden generation, version 2:
  
Ud over dataelementerne for første generation anvendes følgende  
dataelement:  
sensorSerialNumber  er serienummeret på den bevægelsessensor, der er 
parret med køretøjsenheden ved afslutningen af kalibreringen,  
sensorGNSSSerialNumber  er serienummeret på det eksterne 
GNSS-udstyr, der eventuelt er tilkoblet køretøjsenheden ved afs lutningen 
af kalibreringen  
rcmSerialNumber  er serienummeret på fjernkommunikationsudstyret, 
der eventuelt er tilkoblet køretøjsenheden ved afslutningen af kalibre­
ringen  
sealDataVu  angiver oplysninger om de plomber, der er fastgjort til 
forskellige komponenter på køretøjet.  
byDefaultLoadType  er køretøjets standartlasttype (findes kun i version 2).  
calibrationCountry  er det land, hvor kalibreringen er foretaget.  
calibrationCountryTimestamp  er den dato og det klokkeslæt, hvor 
GNSS-modtageren leverede den position, der blev anvendt til at 
bestemme det land, hvor kalibreringen blev udført.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 192  
2.175.  VuCalibrationRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende kalibreringer ne af 
kontrolapparatet (bilag 1C, krav 119 og 120).
  
recordType  er postens type (VuCalibrationRecord).  Tilordnet værdi : 
Se RecordType.  
recordSize  er størrelsen af VuCalibrationRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af kalibreringsposter.  
2.176.  VuCardIWData  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende cyklusser med  isæt­
ning/udtagning af førerkort eller værkstedskort i køretøjsenhed en (bilag 
1B, krav 081, og bilag 1C, krav 103).
  
noOfIWRecords  er antallet af poster i mængden af vuCardIWRecords.  
vuCardIWRecords  er mængden af poster, som vedrører cyklusser med 
isætning/udtagning af kort.  
2.177.  VuCardIWRecord  
Oplysninger, gemt på en køretøjsenhed, vedrørende cyklusser med  isæt­
ning/udtagning af et førerkort eller et værkstedskort i køretøj senheden 
(bilag 1B, krav 081, og bilag 1C, krav 102).  
Første generation:
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 193  
cardHolderName  er efternavn og fornavn(e) på indehaveren af fører- 
eller værkstedskortet, som gemt på kortet.  
fullCardNumber  er kortets type, den medlemsstat, som har udstedt 
kortet, samt kortets nummer, som gemt på kortet.  
cardExpiryDate  er kortets udløbsdato, som gemt på kortet.  
cardInsertionTime  er isætningsdato og -klokkeslæt.  
vehicleOdometerValueAtInsertion  er køretøjets kilometerstand ved 
isætning af kortet.  
cardSlotNumber  er den kortplads, som kortet sidder i.  
cardWithdrawalTime  er dato og klokkeslæt for udtagning af kortet.  
vehicleOdometerValueAtWithdrawal  er køretøjets kilometerstand ved 
udtagning af kortet.  
previousVehicleInfo  indeholder oplysninger om det foregående køretøj, 
føreren har anvendt, som gemt på kortet.  
manualInputFlag  er et flag, som angiver, om kortindehaveren manuelt 
har eller ikke har indlæst føreraktiviteter ved isætning af kor tet. 
Anden generation:
  
I stedet for fullCardNumber anvendes følgende dataelement i dat astruk­
turen af anden generation.  
fullCardNumberAndGeneration  er kortets type, den medlemsstat, som 
har udstedt kortet, samt kortets nummer og generation, som gemt  på 
kortet.  
2.178.  VuCardIWRecordArray  
Anden generation:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 194  
Oplysninger, gemt på en køretøjsenhed, vedrørende cyklusser med  isæt­
ning/udtagning af førerkort eller værkstedskort i køretøjsenhed en (bilag 
1C, krav 103).
  
recordType  er postens type (VuCardIWRecord).  Tilordnet værdi : Se 
RecordType.  
recordSize  er størrelsen af VuCardIWRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af poster, som vedrører cyklusser med isætning/ 
udtagning af kort.  
▼M1 
2.179.  VuCardRecord  
Anden generation:  
Oplysninger gemt på en køretøjsenhed vedrørende et anvendt tako graf­
kort (bilag I C, krav 132).
  
cardNumberAndGenerationInformation  er det fuldstændige kort­
nummer og det anvendte korts generation (datatype 2.74).  
cardExtendedSerialNumber , aflæst fra filen EF_ICC under kortets 
hovedfil.  
cardStructureVersion , aflæst fra filen EF_Application_Identification 
under DF_Tachograph_G2.  
cardNumber , aflæst fra filen EF_Identification under DF_Tacho­
graph_G2.  
▼B 
2.180.  VuCardRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende de takografko rt, der 
er anvendt sammen med køretøjsenheden. Disse oplysninger er ber egnet 
til analyse af problemer med køretøjsenhed og kort (bilag 1C, k rav 132).
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 195  
recordType  er postens type (VuCardRecord).  Tilordnet værdi : Se 
RecordType.  
recordSize  er størrelsen af VuCardRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af poster, som vedrører de takografkort, der er 
anvendt sammen med køretøjsenheden.  
2.181.  VuCertificate  
Certifikat for en køretøjsenheds offentlige nøgle.
  
2.182.  VuCertificateRecordArray  
Anden generation:  
Certifikatet for køretøjsenheden plus metadata, der anvendes i proto­
kollen for dataoverførsel.
  
recordType  er postens type (VuCertificate).  Tilordnet værdi : Se 
RecordType.  
recordSize  er størrelsen af VuCertificate i bytes.  
noOfRecords  er antallet af poster i mængden af poster. Værdien skal 
sættes til 1, da certifikaterne kan have forskellig længde.  
records  er mængden af certifikater for køretøjsenheder.  
2.183.  VuCompanyLocksData  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, der vedrører virksomheds låse 
(bilag 1B, krav 104).
  
noOfLocks  er antallet af låse, som er opført i vuCompanyLocksRecords.  
vuCompanyLocksRecords  er mængden af poster vedrørende virksom­
hedslåse.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 196  
2.184.  VuCompanyLocksRecord  
Oplysninger, gemt på en køretøjsenhed, der vedrører én virksomh edslås 
(bilag 1B, krav 104, og bilag 1C, krav 128).  
Første generation:
  
lockInTime, lockOutTime  er dato og klokkeslæt for lås-ind og lås-ud.  
companyName, companyAddress  er navn og adresse på den virk­
somhed, der er knyttet til den pågældende lås-ind.  
companyCardNumber  identificerer det kort, der er anvendt ved lås-ind.  
Anden generation:
  
I stedet for companyCardNumber anvendes følgende dataelement i data­
strukturen af anden generation.  
companyCardNumberAndGeneration  identificerer det kort, der er 
anvendt ved lås-ind, og kortets generation.  
2.185.  VuCompanyLocksRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, der vedrører virksomheds låse 
(bilag 1C, krav 128).
  
recordType  er postens type (VuCompanyLocksRecord).  Tilordnet 
værdi : Se RecordType.  
recordSize  er størrelsen af VuCompanyLocksRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster. Værdi 0..255.  
records  er mængden af poster vedrørende virksomhedslåse.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 197  
2.185a.  VuConfigurationLengthRange  
Anden generation, version 2:  
Antal byte i et takografkort, der er tilgængeligt til lagring a f køretøjs­
enhedens konfigurationer.
  
Tilordnet værdi : se tillæg 2.  
▼B 
2.186.  VuControlActivityData  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende kontroller fo retaget 
ved hjælp af denne køretøjsenhed (bilag 1B, krav 102).
  
noOfControls  er antallet af kontroller, som er opført i vuControlActi­
vityRecords.  
vuControlActivityRecords  er mængden af kontrolaktivitetsposter.  
2.187.  VuControlActivityRecord  
Oplysninger, gemt på en køretøjsenhed, vedrørende en kontrol fo retaget 
ved hjælp af denne køretøjsenhed (bilag 1B, krav 102, og bilag 1C, krav 
126).  
Første generation:
  
controlType  er kontrollens type.  
controlTime  er dato og klokkeslæt for kontrollen.  
controlCardNumber  identificerer det kontrolkort, som er anvendt til 
kontrollen.  
downloadPeriodBeginTime  er begyndelsestidspunktet for dataover­
førsel, når en sådan har fundet sted.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 198  
downloadPeriodEndTime  er sluttidspunktet for dataoverførsel, når en 
sådan har fundet sted.  
Anden generation:
  
I stedet for controlCardNumber anvendes følgende dataelement i data­
strukturen af anden generation.  
controlCardNumberAndGeneration  identificerer det kontrolkort, som 
er anvendt til kontrollen, og kortets generation.  
2.188.  VuControlActivityRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende kontroller fo retaget 
ved hjælp af denne køretøjsenhed (bilag 1C, krav 126).
  
recordType  er postens type (VuControlActivityRecord).  Tilordnet 
værdi : Se RecordType.  
recordSize  er størrelsen af VuControlActivityRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af kontrolaktivitetsposter for køretøjsenheden.  
2.189.  VuDataBlockCounter  
Tæller, som er gemt på et kort, og som sekventielt identificere r cyklus­
serne med isætning/udtagning af kortet i køretøjsenheder.
  
Tilordnet værdi : Fortløbende nummer, som, efter at have nået maksi­
mumværdien 9 999, begynder forfra fra 0.  
2.190.  VuDetailedSpeedBlock  
Oplysninger, gemt på en køretøjsenhed, der detaljeret angiver k øretøjets 
hastighed i et minut, i hvilket køretøjet har bevæget sig (bila g 1B, krav 
093, og bilag 1C, krav 116).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 199
  
speedBlockBeginDate  er dato og klokkeslæt for den første hastigheds­
værdi inden for blokken.  
speedsPerSecond  er den kronologiske sekvens af målte hastigheder 
hvert sekund for det minut, der begynder på speedBlockBeginDate  
(inklusive).  
2.191.  VuDetailedSpeedBlockRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende køretøjets de talje­
rede hastighed.
  
recordType  er postens type (VuDetailedSpeedBlock).  Tilordnet værdi : 
Se RecordType.  
recordSize  er størrelsen af VuDetailedSpeedBlock i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af detaljerede hastighedsblokke.  
2.192.  VuDetailedSpeedData  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende køretøjets de talje­
rede hastighed.
  
noOfSpeedBlocks  er antallet af hastighedsblokke i mængden vuDetai­
ledSpeedBlocks.  
vuDetailedSpeedBlocks  er mængden af detaljerede hastighedsblokke.  
▼M3 
2.192a.  VuDigitalMapVersion  
Anden generation, version 2:  
Version af det digitale kort, der er lagret i køretøjsenheden ( bilag I C, 
krav 133j).
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 200  
Tilordnet værdi : som anført på det dedikerede sikre websted, der stilles 
til rådighed af Kommissionen (bilag I C, krav 133k).  
▼B 
2.193.  VuDownloadablePeriod  
Ældste og nyeste dato, for hvilke en køretøjsenhed lagrer data vedrø­
rende førerens aktiviteter (bilag 1B, krav 081, 084 eller 087, og bilag 
1C, krav 102, 105 og 108).
  
minDownloadableTime  er ældste dato og klokkeslæt, som i køretøjs­
enheden er gemt vedrørende isætning af kort, aktivitetsskift el ler indlæs­
ning af sted.  
maxDownloadableTime  er nyeste dato og klokkeslæt, som i køretøjs­
enheden er gemt vedrørende udtagning af kort, aktivitetsskift e ller 
indlæsning af sted.  
2.194.  VuDownloadablePeriodRecordArray  
Anden generation:  
VUDownloadablePeriod plus metadata, der anvendes i protokollen for 
dataoverførsel.
  
recordType  er postens type (VuDownloadablePeriod).  Tilordnet værdi : 
Se RecordType.  
recordSize  er størrelsen af VuDownloadablePeriod i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af VuDownloadablePeriod-poster.  
2.195.  VuDownloadActivityData  
Oplysninger, gemt på en køretøjsenhed, der vedrører dens sidste  over­
førsel (bilag 1B, krav 105, og bilag 1C, krav 129).  
Første generation:
  
downloadingTime  er dato og klokkeslæt for dataoverførslen.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 201  
fullCardNumber  identificerer det kort, der er anvendt til at muliggøre 
dataoverførslen.  
companyOrWorkshopName  er virksomhedens eller værkstedets navn.  
Anden generation:
  
I stedet for fullCardNumber anvendes følgende dataelement i dat astruk­
turen af anden generation.  
fullCardNumberAndGeneration  identificerer det kort, der er anvendt 
til at muliggøre dataoverførslen, og kortets generation.  
2.196.  VuDownloadActivityDataRecordArray  
Anden generation:  
Oplysninger om den sidste overførsel for køretøjsenheden (bilag  1C, 
krav 129).
  
recordType  er postens type (VuDownloadActivityData).  Tilordnet 
værdi : Se RecordType.  
recordSize  er størrelsen af VuDownloadActivityData i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af dataposter vedrørende dataoverførsel.  
2.197.  VuEventData  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende hændelser (bi lag 1B, 
krav 094, bortset fra overskridelser af tilladt hastighed).
  
noOfVuEvents  er antallet af hændelser på listen over hændelser i 
mængden vuEventRecords.  
vuEventRecords  er mængden af hændelsesposter.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 202  
2.198.  VuEventRecord  
Oplysninger, gemt på en køretøjsenhed, vedrørende en hændelse ( bilag 
1B, krav 094, og bilag 1C, krav 117, bortset fra overskridelse af tilladt 
hastighed).  
Første generation:
  
eventType  er hændelsens type.  
eventRecordPurpose  er det formål, hændelsen er registreret til.  
eventBeginTime  er hændelsens startdato og -klokkeslæt.  
eventEndTime  er hændelsens slutdato og -klokkeslæt.  
cardNumberDriverSlotBegin  identificerer det kort, der er sat i førerens 
kortplads ved hændelsens start.  
cardNumberCodriverSlotBegin  identificerer det kort, der sad i 
medchaufførens kortplads ved hændelsens start.  
cardNumberDriverSlotEnd  identificerer det kort, der sad i førerens 
kortplads ved hændelsens slutning.  
cardNumberCodriverSlotEnd  identificerer det kort, der sad i 
medchaufførens kortplads ved hændelsens slutning.  
similarEventsNumber  er antallet af tilsvarende hændelser samme døgn.  
Denne sekvens kan anvendes til alle hændelser, bortset fra over skridelser 
af tilladt hastighed.  
Anden generation:
  
Ud over dataelementerne for første generation anvendes følgende  
dataelementer:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 203  
manufacturerSpecificEventFaultData  indeholder yderligere fabrikants­
pecifikke oplysninger om hændelsen.  
I stedet for cardNumberDriverSlotBegin, cardNumberCodriverSlotB egin, 
cardNumberDriverSlotEnd og cardNumberCodriverSlotEnd anvendes 
følgende dataelementer i datastrukturen af anden generation:  
cardNumberAndGenDriverSlotBegin  identificerer det kort, der sad i 
førerens kortplads ved hændelsens start, og kortets generation.  
cardNumberAndGenCodriverSlotBegin  identificerer det kort, der sad i 
medchaufførens kortplads ved hændelsens start, og kortets gener ation.  
cardNumberAndGenDriverSlotEnd  identificerer det kort, der sad i 
førerens kortplads ved hændelsens afslutning, og kortets genera tion. 
cardNumberAndGenCodriverSlotEnd  identificerer det kort, der sad i 
medchaufførens kortplads ved hændelsens afslutning, og kortets 
generation.  
Hvis hændelsen er en tidskonflikt, skal eventBeginTime og event End­
Time fortolkes som følger:  
eventBeginTime  er kontrolapparatets dato og klokkeslæt.  
cardWithdrawalTime  er GNSS-udstyrets dato og klokkeslæt.  
2.199.  VuEventRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende hændelser (bi lag 1C, 
krav 117, bortset fra overskridelser af tilladt hastighed).
  
recordType  er postens type (VuEventRecord).  Tilordnet værdi : Se 
RecordType.  
recordSize  er størrelsen af VuEventRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af hændelsesposter.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 204  
2.200.  VuFaultData  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende fejl (bilag 1 B, krav 
096).
  
noOfVuFaults  er antallet af fejl opført i vuFaultRecords-mængden.  
vuFaultRecords  er mængden af fejlposter.  
2.201.  VuFaultRecord  
Oplysninger, gemt på en køretøjsenhed, der vedrører en fejl (bi lag 1B, 
krav 096, og bilag 1C, krav 118).  
Første generation:
  
faultType  er typen af den pågældende fejl ved kontrolapparatet.  
faultRecordPurpose  er det formål, til hvilket fejlen er blevet registreret.  
faultBeginTime  er fejlens startdato og -klokkeslæt.  
faultEndTime  er fejlens slutdato og -klokkeslæt.  
cardNumberDriverSlotBegin  identificerer det kort, der sad i førerens 
kortplads ved fejlens begyndelse.  
cardNumberCodriverSlotBegin  identificerer det kort, der sad i 
medchaufførens kortplads ved fejlens begyndelse.  
cardNumberDriverSlotEnd  identificerer det kort, der sad i førerens 
kortplads ved fejlens slutning.  
cardNumberCodriverSlotEnd  identificerer det kort, der sad i 
medchaufførens kortplads ved fejlens slutning.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 205  
Anden generation:
  
Ud over dataelementerne for første generation anvendes følgende  
dataelement:  
manufacturerSpecificEventFaultData  indeholder yderligere fabrikants­
pecifikke oplysninger om fejlen.  
I stedet for cardNumberDriverSlotBegin, cardNumberCodriverSlotB egin, 
cardNumberDriverSlotEnd og cardNumberCodriverSlotEnd anvendes 
følgende dataelementer i datastrukturen af anden generation:  
cardNumberAndGenDriverSlotBegin  identificerer det kort, der sad i 
førerens kortplads ved fejlens start, og kortets generation.  
cardNumberAndGenCodriverSlotBegin  identificerer det kort, der sad i 
medchaufførens kortplads ved fejlens start, og kortets generati on. 
cardNumberAndGenDriverSlotEnd  identificerer det kort, der sad i 
førerens kortplads ved fejlens afslutning, og kortets generatio n. 
cardNumberAndGenCodriverSlotEnd  identificerer det kort, der sad i 
medchaufførens kortplads ved fejlens afslutning, og kortets gen eration.  
2.202.  VuFaultRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende fejl (bilag 1 C, krav 
118).
  
recordType  er postens type (VuFaultRecord).  Tilordnet værdi : Se 
RecordType.  
recordSize  er størrelsen af VuFaultRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af fejlposter.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 206  
2.203.  VuGNSSADRecord  
▼M3 
Anden generation, version 1:  
▼M1 
Oplysninger gemt på en køretøjsenhed vedrørende køretøjets 
GNSS-position, hvis den kumulerede køretid når op på et multipl um 
af tre timer (bilag I C, krav 108) og 110).
  
timeStamp  er den dato og det klokkeslæt, hvor den kumulerede køretid 
når op på et multiplum af tre timer.  
cardNumberAndGenDriverSlot  identificerer det kort, der sidder i føre­
rens kortplads, og kortets generation.  
cardNumberAndGenCodriverSlot  identificerer det kort, der sidder i 
medchaufførens kortplads, og kortets generation.  
gnssPlaceRecord  indeholder oplysninger om køretøjets position.  
vehicleOdometerValue  er kilometerstanden, når den kumulerede køretid 
når op på et multiplum af tre timer.  
▼M3 
Anden generation, version 2:  
Oplysninger gemt på en køretøjsenhed vedrørende køretøjets GNSS - 
position, hvis den kumulerede køretid når op på et multiplum af  tre 
timer (bilag I C, krav 108) og 110).
  
I anden generation, version 2 , er gnssPlaceRecord blevet erstattet af 
gnssPlaceAuthRecord, som også indeholder status for ægthedsbekr æf­
telse af GNSS.  
2.203a.  VuBorderCrossingRecord  
Anden generation, version 2:  
Oplysninger, der er gemt på en køretøjsenhed, vedrørende køretø jets 
grænsepassager, når sidstnævnte har passeret et lands grænse (b ilag 
I C, krav 133a og 133b).  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 207
  
cardNumberAndGenDriverSlot  identificerer det kort, der sidder i føre­
rens kortplads, og kortets generation.  
cardNumberAndGenCodriverSlot  identificerer det kort, der sidder i 
medchaufførens kortplads, og kortets generation.  
countryLeft  er det land, som køretøjet har forladt ifølge den senest 
tilgængelige position, inden grænsepassagen blev registreret. » Resten 
af verden« (NationNumeric-kode »FF«H) anvendes, når køretøjsenh eden 
ikke kan fastslå det land, hvor køretøjet befinder sig (hvis de t nuværende 
land f.eks. ikke findes på de lagrede digitale kort).  
countryEntered  er det land, som køretøjet er kørt ind i. »Resten af 
verden« (NationNumeric-kode »FF«H) anvendes, når køretøjsenhede n 
ikke kan fastslå det land, hvor køretøjet befinder sig (hvis de t nuværende 
land f.eks. ikke findes på de lagrede digitale kort).  
gnssPlaceAuthRecord  indeholder oplysninger om køretøjets position, 
da grænsepassagen blev registreret, og dets status for ægthedsb ekræf­
telse.  
vehicleOdometerValue  er køretøjets kilometerstand, når køretøjs­
enheden har registreret, at køretøjet har passeret et lands græ nse. 
2.203b.  VuBorderCrossingRecordArray  
Anden generation, version 2:  
Oplysninger, der er gemt på en køretøjsenhed, vedrørende køretø jets 
grænsepassager (bilag I C, krav 133c).
  
recordType  angiver posttypen (VuBorderCrossingRecord).  Tilordnet 
værdi : se RecordType.  
recordSize  er størrelsen på VuBorderCrossingRecord i byte.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af grænsepassageposter.  
▼M1 
2.204.  VuGNSSADRecordArray  
Anden generation:  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 208  
Oplysninger gemt på en køretøjsenhed vedrørende køretøjets 
GNSS-position, når den kumulerede køretid når op på et multiplu m af 
tre timer (bilag I C, krav 108 og 110).
  
recordType  er postens type (VuGNSSADRecord).  
Tilordnet værdi : Se postens type.  
recordSize  er størrelsen af VuGNSSADRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af GNSS-poster for kumuleret køretid.  
▼M3 
2.204a.  VuGnssMaximalTimeDifference  
Anden generation, version 2:  
Den maksimale forskel mellem sand tid og køretøjsenhedens realt idsur 
baseret på den maksimale tidspunktdrift anført i bilag I C, kra v 041, 
overført af køretøjsenheden til eksternt GNSS-udstyr, se tillæg  12, krav 
GNS_3g.
  
▼B 
2.205.  VuIdentification  
Oplysninger, gemt på en køretøjsenhed, til identifikation af kø retøjs­
enheden (bilag 1B, krav 075, og bilag 1C, krav 93 og 121).  
Første generation:
  
vuManufacturerName  er navnet på fabrikanten af køretøjsenheden.  
vuManufacturerAddress  er adressen på fabrikanten af køretøjsenheden.  
vuPartNumber  er reservedelsnummeret på køretøjsenheden.  
vuSerialNumber  er serienummeret på køretøjsenheden.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 209  
vuSoftwareIdentification  identificerer det programmel, der anvendes i 
køretøjsenheden.  
vuManufacturingDate  er køretøjsenhedens fabrikationsdato.  
vuApprovalNumber  er køretøjsenhedens typegodkendelsesnummer.  
▼M3 
Anden generation:
  
Ud over dataelementerne for første generation anvendes følgende  
dataelementer:  
vuGeneration  angiver køretøjsenhedens generation.  
vuAbility  rummer oplysninger om, hvorvidt køretøjsenheden under­
støtter takografkort af første generation eller ej.  
vuDigitalMapVersion  er den version af det digitale kort, der er lagret i 
køretøjsenheden (findes kun i version 2).  
▼B 
2.206.  VuIdentificationRecordArray  
Anden generation:  
VuIdentification plus metadata, der anvendes i protokollen for dataover­
førsel.
  
recordType  er postens type (VuIdentification).  Tilordnet værdi : Se 
RecordType.  
recordSize  er størrelsen af VuIdentification i bytes.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 210  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af VuIdentification-poster.  
2.207.  VuITSConsentRecord  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende en førers sam tykke 
om at anvende intelligente transportsystemer.
  
cardNumberAndGen  identificerer kortet, herunder dets generation. 
Dette skal være et førerkort eller et værkstedskort.  
consent  er et flag, som angiver, om føreren har givet sit samtykke til  at 
bruge intelligente transportsystemer sammen med køretøjet/køret øjs­
enheden.  
Tilordnet værdi:  
TRUE angiver, at føreren har givet sit samtykke til at 
bruge intelligente transportsystemer.  
FALSE angiver, at føreren ikke har givet sit samtykke til at 
bruge intelligente transportsystemer.  
2.208.  VuITSConsentRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende føreres samty kke til 
brug af intelligente transportsystemer (bilag 1C, krav 200).
  
recordType  er postens type (VuITSConsentRecord).  Tilordnet værdi : 
Se RecordType.  
recordSize  er størrelsen af VuITSConsentRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af poster om samtykke til brug af ITS.  
▼M3 
2.208a.  VuLoadUnloadRecord  
Anden generation, version 2:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 211  
Oplysninger, der er gemt på en køretøjsenhed, vedrørende en ind læst 
laste-/losseoperation (bilag I C, krav 133e, 133f og 133g).
  
timeStamp  er dato og klokkeslæt for indlæsning af laste-/losseopera­
tionen.  
operationType  er den indlæste operationstype (lastning, losning eller 
samtidig lastning/losning)  
cardNumberAndGenDriverSlot  identificerer det kort, der sidder i føre­
rens kortplads, og kortets generation.  
cardNumberAndGenCodriverSlot  identificerer det kort, der sidder i 
medchaufførens kortplads, og kortets generation.  
gnssPlaceAuthRecord  indeholder oplysninger om køretøjets position og 
dets status for ægthedsbekræftelse.  
vehicleOdometerValue  er køretøjets kilometerstand i forbindelse med 
laste-/losseoperationen.  
2.208b.  VuLoadUnloadRecordArray  
Anden generation, version 2:  
Oplysninger, der er gemt på en køretøjsenhed, vedrørende en ind læst 
laste-/losseoperation (bilag I C, krav 133h).
  
recordType  angiver posttypen (VuLoadUnloadRecord). Tilordnet 
værdi : Se RecordType.  
recordSize  er størrelsen på VuLoadUnloadRecord i byte.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af poster vedrørende laste-/losseoperationer.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 212  
2.209.  VuManufacturerAddress  
Adressen på fabrikanten af køretøjsenheden.
  
Tilordnet værdi : Uspecificeret.  
2.210.  VuManufacturerName  
Navnet på fabrikanten af køretøjsenheden.
  
Tilordnet værdi : Uspecificeret.  
2.211.  VuManufacturingDate  
Fabrikationsdatoen for køretøjsenheden.
  
Tilordnet værdi : Uspecificeret.  
2.212.  VuOverSpeedingControlData  
Oplysninger, gemt på en køretøjsenhed, vedrørende de overskride lser af 
tilladt hastighed, som har fundet sted siden seneste kontrol me d over­
skridelse af tilladt hastighed (bilag 1B, krav 095, og bilag 1C , krav 117).
  
lastOverspeedControlTime  er dato og klokkeslæt for seneste kontrol 
med overskridelse af tilladt hastighed.  
firstOverspeedSince  er dato og klokkeslæt for første overskridelse af 
tilladt hastighed siden denne kontrol med overskridelse af till adt 
hastighed.  
numberOfOverspeedSince  er antallet af hændelser med overskridelse af 
tilladt hastighed siden seneste kontrol med overskridelse af ti lladt 
hastighed.  
2.213.  VuOverSpeedingControlDataRecordArray  
Anden generation:  
VuOverSpeedingControlData plus metadata, der anvendes i protoko llen 
for dataoverførsel.
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 213  
recordType  er postens type (VuOverSpeedingControlData).  Tilordnet 
værdi : Se RecordType.  
recordSize  er størrelsen af VuOverSpeedingControlData i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af dataposter om kontrol med overskridelse af 
tilladt hastighed.  
2.214.  VuOverSpeedingEventData  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende hændelser med  over­
skridelse af tilladt hastighed (bilag 1B, krav 094).
  
noOfVuOverSpeedingEvents  er antal hændelser opført i listen over 
hændelser i mængden vuOverSpeedingEventRecords.  
vuOverSpeedingEventRecords  er mængden af poster vedrørende 
hændelser med overskridelse af tilladt hastighed.  
2.215.  VuOverSpeedingEventRecord  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende overskridelse  af 
tilladt hastighed (bilag 1B, krav 094, og bilag 1C, krav 117).
  
eventType  er hændelsens type.  
eventRecordPurpose  er det formål, hændelsen er registreret til.  
eventBeginTime  er hændelsens startdato og -klokkeslæt.  
eventEndTime  er hændelsens slutdato og -klokkeslæt.  
maxSpeedValue  er den højeste hastighed målt under hændelsen.  
averageSpeedValue  er den aritmetiske gennemsnitshastighed målt under 
hændelsen.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 214  
cardNumberDriverSlotBegin  identificerer det kort, der er sat i førerens 
kortplads ved hændelsens start.  
similarEventsNumber  er antallet af tilsvarende hændelser samme døgn.  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende overskridelse  af 
tilladt hastighed (bilag 1B, krav 094, og bilag 1C, krav 117).
  
I stedet for cardNumberDriverSlotBegin benytter datastrukturen for 
anden generation følgende dataelement:  
cardNumberAndGenDriverSlotBegin  identificerer det kort, inklusive 
generation, der er sat i førerens kortplads ved hændelsens star t. 
2.216.  VuOverSpeedingEventRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende hændelser med  over­
skridelse af tilladt hastighed (bilag 1C, krav 117).
  
recordType  er postens type (VuOverSpeedingEventRecord).  Tilordnet 
værdi : Se RecordType.  
recordSize  er størrelsen af VuOverSpeedingEventRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af poster vedrørende hændelser med overskridelse 
af tilladt hastighed.  
2.217.  VuPartNumber  
Serienummeret på køretøjsenheden.
  
Tilordnet værdi : Specifik for fabrikanten af køretøjsenheden.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 215  
2.218.  VuPlaceDailyWorkPeriodData  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende de steder, hv or 
føreren begynder eller afslutter den daglige arbejdstid (bilag 1B, krav 
087, og bilag 1C, krav 108 og 110).
  
noOfPlaceRecords  er antallet af poster i mængden vuPlaceDailyWork­
PeriodRecords.  
vuPlaceDailyWorkPeriodRecords  er mængden af poster vedrørende 
steder.  
2.219.  VuPlaceDailyWorkPeriodRecord  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende et sted, hvor  føreren 
begynder eller afslutter den daglige arbejdstid (bilag 1B, krav  087, og 
bilag 1C, krav 108 og 110).
  
fullCardNumber  er førerens korttype, den kortudstedende medlemsstat 
og kortets nummer.  
placeRecord  indeholder oplysningerne om det indlæste sted.  
▼M3 
Anden generation, version 1:  
▼B 
Oplysninger, gemt på en køretøjsenhed, vedrørende et sted, hvor  føreren 
begynder eller afslutter den daglige arbejdstid (bilag 1B, krav  087, og 
bilag 1C, krav 108 og 110).
  
I stedet for fullCcardNumber benytter datastrukturen for anden genera­
tion følgende dataelement:  
fullCardNumberAndGeneration  angiver korttypen, den udstedende 
medlemsstat, kortnummeret og kortets generation, som gemt på ko rtet. 
▼M3 
Anden generation, version 2:  
Oplysninger, gemt på en køretøjsenhed, vedrørende et sted, hvor  føreren 
begynder eller afslutter den daglige arbejdstid (bilag 1B, krav  087, og 
bilag 1C, krav 108 og 110).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 216
  
I stedet for placeRecord benyttes følgende dataelement i datast rukturen 
for anden generation, version 2:  
placeAuthRecord  indeholder oplysninger om det indlæste sted, den 
registrerede position, status for ægthedsbekræftelse af GNSS og  tids­
punkt for bestemmelse af position.  
▼B 
2.220.  VuPlaceDailyWorkPeriodRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende de steder, hv or 
føreren begynder eller afslutter den daglige arbejdstid (bilag 1C, krav 
108 og 110).
  
recordType  er postens type (VuPlaceDailyWorkPeriodRecord).  
Tilordnet værdi : Se RecordType.  
recordSize  er størrelsen af VuPlaceDailyWorkPeriodRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af poster vedrørende steder.  
2.221.  VuPrivateKey  
Første generation:  
Køretøjsenhedens private nøgle.
  
2.222.  VuPublicKey  
Første generation:  
Køretøjsenhedens offentlige nøgle.
  
▼M3 
2.222a.  VuRtcTime  
Anden generation, version 2:  
Klokkeslættet i køretøjsenhedens RTC-ur overført af køretøjsenh eden til 
eksternt GNSS-udstyr, se tillæg 12, krav GNS_3f.
  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 217  
2.223.  VuSerialNumber  
Køretøjsenhedens serienummer (bilag 1B, krav 075, og bilag 1C, krav 93).
  
2.224.  VuSoftInstallationDate  
Dato for installation af den programmelversion, som anvendes i køre­
tøjsenheden.
  
Tilordnet værdi : Uspecificeret.  
2.225.  VuSoftwareIdentification  
Oplysninger, gemt på en køretøjsenhed, vedrørende det installer ede 
programmel.
  
vuSoftwareVersion  er versionsnummeret på det programmel, der 
anvendes i køretøjsenheden.  
vuSoftInstallationDate  er datoen for installation af den pågældende 
version af programmellet.  
2.226.  VuSoftwareVersion  
Versionsnummeret på det programmel, der anvendes i køretøjsenhe den.
 
Tilordnet værdi : Uspecificeret.  
2.227.  VuSpecificConditionData  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende særlige omstæ ndig­
heder.
  
noOfSpecificConditionRecords  er det antal poster, som er indeholdt i 
specificConditionRecords-mængden.  
specificConditionRecords  er mængden af poster vedrørende særlige 
omstændigheder.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 218  
2.228.  VuSpecificConditionRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende særlige omstæ ndig­
heder (bilag 1C, krav 130).
  
recordType  er postens type (SpecificConditionRecord).  Tilordnet 
værdi : Se RecordType.  
recordSize  er størrelsen af SpecificConditionRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af poster vedrørende særlige omstændigheder.  
2.229.  VuTimeAdjustmentData  
Første generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende tidsjustering er, som 
har fundet sted uden for rammerne af en planmæssig kalibrering (bilag 
1B, krav 101).
  
noOfVuTimeAdjRecords  er antallet af poster i vuTimeAdjustmentRe­
cords-mængden.  
vuTimeAdjustmentRecords  er mængden af tidsjusteringsposter.  
▼M1 
2.230.  Forbeholdt fremtidig brug  
2.231.  Forbeholdt fremtidig brug  
▼B 
2.232.  VuTimeAdjustmentRecord  
Oplysninger, gemt på en køretøjsenhed, vedrørende en tidsjuster ing, som 
har fundet sted uden for rammerne af en planmæssig kalibrering (bilag 
1B, krav 101, og bilag 1C, krav 124 og 125).  
Første generation:
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 219  
oldTimeValue, newTimeValue  er gammel og ny værdi af dato og 
klokkeslæt.  
workshopName, workshopAddress er værkstedets navn og adresse.  
workshopCardNumber  identificerer det værkstedskort, der er brugt til 
at foretage tidsjustering.  
Anden generation:
  
I stedet for workshopCardNumber anvendes følgende dataelement i  data­
strukturen af anden generation:  
workshopCardNumberAndGeneration  identificerer det værkstedskort, 
der er brugt til at foretage tidsjustering, og kortets generati on. 
2.233.  VuTimeAdjustmentRecordArray  
Anden generation:  
Oplysninger, gemt på en køretøjsenhed, vedrørende tidsjustering er, som 
har fundet sted uden for rammerne af en planmæssig kalibrering (bilag 
1C, krav 124 og 125).
  
recordType  er postens type (VuTimeAdjustmentRecord).  Tilordnet 
værdi : Se RecordType.  
recordSize  er størrelsen af VuTimeAdjustmentRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af poster vedrørende tidsjustering.  
2.234.  WorkshopCardApplicationIdentification  
Oplysninger, gemt på et værkstedskort, til identifikation af ko rtets appli­
kation (bilag 1C, krav 307 og 330).  
Første generation:
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 220  
typeOfTachographCardId  angiver den implementerede korttype.  
cardStructureVersion  angiver den version af strukturen, som er imple­
menteret i kortet.  
noOfEventsPerType  er antallet af hændelser af hver hændelsestype, 
som kan gemmes på kortet.  
noOfFaultsPerType  er antal fejl af hver fejltype, som kan gemmes på 
kortet.  
activityStructureLength  angiver antal bytes til rådighed til lagring af 
aktivitetsposter.  
noOfCardVehicleRecords  er antallet af køretøjsposter, som kan 
gemmes på kortet.  
noOfCardPlaceRecords  er antallet af steder, som kan gemmes på 
kortet.  
noOfCalibrationRecords  er antallet af kalibreringsposter, som kan 
gemmes på kortet.  
Anden generation:  
▼M1
 
Ud over dataelementerne for første generation anvendes følgende  
dataelementer:  
noOfGNSSADRecords  er det antal GNSS-poster for kumuleret køretid, 
som kan gemmes på kortet.  
noOfSpecificConditionRecords  er det antal poster vedrørende særlige 
omstændigheder, som kan gemmes på kortet.  
noOfCardVehicleUnitRecords  er det antal poster om anvendte køre­
tøjsenheder, som kan gemmes på kortet.  
▼M3 
2.234a.  WorkshopCardApplicationIdentificationV2  
Anden generation, version 2:  
Oplysninger, der er gemt på et værkstedskort, vedrørende identi fikation 
af kortets applikation (bilag I C, krav 330a).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 221
  
lengthOfFollowingData  er antallet af byte i posten.  
noOfBorderCrossingRecords  er det antal grænsepassageposter, der kan 
lagres på værkstedskortet.  
noOfLoadUnloadRecords  er det antal laste-/losseposter, der kan lagres 
på værkstedskortet.  
noOfLoadTypeEntryRecords  er det antal lasttypeposter, der kan lagres 
på værkstedskortet.  
vuConfigurationLengthRange  er antallet af byte i et takografkort, der 
er tilgængeligt til lagring af køretøjsenhedens konfigurationer . 
2.234b.  WorkshopCardCalibrationAddData  
Anden generation, version 2:  
Oplysninger, der er gemt på et værkstedskort, vedrørende yderli gere data 
(dvs. standardlasttypen), der er indlæst under en kalibrering ( bilag I C, 
krav 356l).
  
calibrationPointerNewestRecord  er indekset for den senest opdaterede 
post vedrørende kalibrering af yderligere data.  
Tilordnet værdi  er tallet svarende til tælleren i posten vedrørende kali­
brering af yderligere data, begyndende med »0« for den første f orekomst 
af sådanne poster i strukturen.  
workshopCardCalibrationAddDataRecords  er mængden af poster, der 
indeholder den gamle værdi for dato og klokkeslæt, køretøjets i dentifi­
kationsnummer og køretøjets standartlasttype.  
2.234c.  WorkshopCardCalibrationAddDataRecord  
Anden generation, version 2:  
Oplysninger, der er gemt på et værkstedskort, vedrørende standa rdlast­
typen, der er indlæst under en kalibrering (bilag I C, krav 356 k). ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 222
  
oldTimeValue  er den gamle værdi for dato og klokkeslæt i den tilsva­
rende WorkshopCardCalibrationRecord  
vehicleIdentificationNumber  er køretøjets identifikationsnummer, som 
også findes i den tilsvarende WorkshopCardCalibrationRecord  
byDefaultLoadType  er køretøjets standartlasttype (findes kun i version 2).  
calibrationCountry  er det land, hvor kalibreringen er foretaget  
calibrationCountryTimestamp  er den dato og det klokkeslæt, hvor 
GNSS-modtageren leverede den position, der blev anvendt til at 
bestemme dette land.  
▼B 
2.235.  WorkshopCardCalibrationData  
Oplysninger, gemt på et værkstedskort, vedrørende de aktivitete r, der er 
udført med kortet (bilag 1C, krav 314, 316, 337 og 339).
  
calibrationTotalNumber  er det samlede antal kalibreringer, som er 
udført med kortet.  
calibrationPointerNewestRecord  er indekset for den senest opdaterede 
kalibreringspost.  
Tilordnet værdi : Tal svarende til tælleren i kalibreringsposten, begyn­
dende med »0« for den første forekomst af kalibreringsposterne i 
strukturen.  
calibrationRecords  er den mængde poster, der indeholder oplysninger 
om kalibrering og/eller tidsjustering.  
2.236.  WorkshopCardCalibrationRecord  
Oplysninger, gemt på et værkstedskort, vedrørende en kalibrerin g, der er 
udført med kortet (bilag 1C, krav 314 og 337).  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 223  
Første generation:
  
calibrationPurpose  er formålet med kalibreringen.  
vehicleIdentificationNumber  er køretøjets identifikationsnummer.  
vehicleRegistration  indeholder køretøjets indregistreringsnummer og 
den indregistrerende medlemsstat.  
wVehicleCharacteristicConstant  er køretøjets vejdrejetal.  
kConstantOfRecordingEquipment  er kontrolapparatets konstant.  
lTyreCircumference  er den effektive dækperiferi.  
tyreSize  er dimensionsbetegnelsen for de dæk, der er monteret på køre­
tøjet.  
authorisedSpeed  er køretøjets tilladte hastighed.  
oldOdometerValue, newOdometerValue  er gammel og ny 
kilometerstand.  
oldTimeValue, newTimeValue  er gammel og ny værdi af dato og 
klokkeslæt.  
nextCalibrationDate  er datoen for næste kalibrering af den type, som i 
CalibrationPurpose foreskrives at skulle udføres af kontrolmynd igheden.  
vuPartNumber , vuSerialNumber  og sensorSerialNumber  er de datae­
lementer, som identificerer kontrolapparatet.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 224  
Anden generation:
  
Ud over dataelementerne for første generation anvendes følgende  
dataelementer:  
sensorGNSSSerialNumber , som identificerer eksternt GNSS-udstyr.  
rcmSerialNumber , som identificerer et modul til fjernkommunikation.  
sealDataCard  angiver oplysninger om de plomber, der er fastgjort til 
forskellige komponenter på køretøjet.  
2.237.  WorkshopCardHolderIdentification  
Oplysninger, gemt på et værkstedskort, til identifikation af ko rtindeha­
veren (bilag 1C, krav 311 og 334).
  
workshopName  er navnet på kortindehaverens værksted.  
workshopAddress  er adressen på kortindehaverens værksted.  
cardHolderName  er efternavn og fornavn(e) på indehaveren (f.eks. 
navnet på mekanikeren).  
cardHolderPreferredLanguage  er det af kortindehaveren foretrukne 
sprog.  
2.238.  WorkshopCardPIN  
Det personlige identifikationsnummer på værkstedskortet (bilag 1C, krav 
309 og 332).
  
Tilordnet værdi : Den PIN-kode, som kendes af kortindehaveren, 
udfyldt mod højre med sideskiftbytes indtil 8 bytes.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 225  
2.239.  W-VehicleCharacteristicConstant  
Køretøjets vejdrejetal (definition k)).
  
Tilordnet værdi : Impulser pr. kilometer inden for området 0 til 64 255 
impulser/km.  
2.240.  VuPowerSupplyInterruptionRecord  
Anden generation:  
Oplysninger, gemt i en køretøjsenhed, om begivenheder med afbry delse 
af strømforsyningen (bilag 1C, krav 117).
  
eventType  er begivenhedstypen.  
eventRecordPurpose  er det formål, til hvilket begivenheden registreres.  
eventBeginTime  er dato og tidspunkt for begivenhedens begyndelse.  
eventEndTime  er dato og tidspunkt for begivenhedens afslutning.  
cardNumberAndGenDriverSlotBegin  identificerer det kort, inklusive 
generation, der er isat førerens kortplads ved begivenhedens be gyndelse.  
cardNumberAndGenDriverSlotEnd  identificerer det kort, inklusive 
generation, der er isat førerens kortplads ved begivenhedens af slutning.  
cardNumberAndGenCodriverSlotBegin  identificerer det kort, inklu­
sive generation, der er isat medchaufførens kortplads ved begiv enhedens 
begyndelse.  
cardNumberAndGenCodriverSlotEnd  identificerer det kort, inklusive 
generation, der er isat medchaufførens kortplads ved begivenhed ens 
afslutning.  
similarEventsNumber  er antallet af lignende begivenheder den pågæl­
dende dag.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 226  
2.241.  VuPowerSupplyInterruptionRecordArray  
Anden generation:  
Oplysninger, gemt i en køretøjsenhed, om begivenheder med afbry delse 
af strømforsyningen (bilag 1C, krav 117).
  
recordType  er postens type (VuPowerSupplyInterruptionRecord).  
Tilordnet værdi : Se RecordType.  
recordSize  er størrelsen af VuPowerSupplyInterruptionRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af poster vedrørende afbrydelse af strømfor­
syningen.  
2.242.  VuSensorExternalGNSSCoupledRecordArray  
Generation 2:  
En mængde af SensorExternalGNSSCoupledRecord plus metadata, der  
anvendes i protokollen for dataoverførsel.
  
recordType  er postens type (SensorExternalGNSSCoupledRecord).  
Tilordnet værdi : Se RecordType.  
recordSize  er størrelsen af SensorExternalGNSSCoupledRecord i bytes.  
noOfRecords  er antallet af poster i mængden af poster.  
records  er mængden af poster vedrørende sensoren sammenkoblet med 
det eksterne GNSS-udstyr  
2.243.  VuSensorPairedRecordArray  
Anden generation:  
En mængde af SensorPairedRecord plus metadata, der anvendes i p roto­
kollen for dataoverførsel.
  
recordType  er postens type (SensorPairedRecord).  Tilordnet værdi : Se 
RecordType  
recordSize  er størrelsen af SensorPairedRecord i byte.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 227  
noOfRecords  er antallet af poster i mængden af poster.  
records  er en mængde poster om sensorens samparring.  
3. DEFINITIONER AF VÆRDI- OG STØRRELSESOMRÅDE  
Definition af de variabelværdier, der er anvendt til definition erne i 
punkt 2.
  
4. TEGNSÆT  
Til IA5Strings anvendes ASCII-tegnsættet som defineret i ISO/IE C 
8824-1. Af hensyn til letlæselighed og overskuelighed er de til ordnede 
værdier gengivet nedenfor. Ved eventuel uoverensstemmelse har 
ISO/IEC 8824-1 forrang for denne bemærkning.
  
I andre tegnstrenge (Address, Name, VehicleRegistrationNumber) 
anvendes herudover tegn fra decimalkodeområdet 161-255 i de føl gende 
8-bit standardtegnsæt, angivet ved Code Page-nummeret: 
Standardtegnsæt  Code Page 
(Decimal)  
ISO/IEC 8859-1 Latin-1 Vesteuropæisk  1  
ISO/IEC 8859-2 Latin-2 Centraleuropæisk  2  
ISO/IEC 8859-3 Latin-3 Sydeuropæisk  3  
ISO/IEC 8859-5 Latin/Kyrillisk  5  
ISO/IEC 8859-7 Latin/Græsk  7  
ISO/IEC 8859-9 Latin-5 Tyrkisk  9  
ISO/IEC 8859-13 Latin-7 Det baltiske område  1 3  
ISO/IEC 8859-15 Latin-9  1 5  
ISO/IEC 8859-16 Latin-10 Sydøsteuropæisk  1 6  
KOI8-R Latin/Kyrillisk  8 0  
KOI8-U Latin/Kyrillisk  8 5  
5. KODNING  
Ved kodning efter ASN.1-kodningsreglerne skal alle de definered e data­
typer være kodet i overensstemmelse med ISO/IEC 8825-2, justere t 
variant.  
6. OBJEKTIDENTIFIKATORER OG APPLIKATIONSIDENTIFIKA­
TORER  
6.1. Objektidentifikatorer  
Objektidentifikatorerne i dette afsnit er kun relevante 
for anden generation. De beskrives nærmere i TR-03110-3  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 228  
og gentages her for fuldstændighedens skyld. De er indeholdt i under­
træet af bsi-de:
  
Datanavne på protokoller til ægthedsbekræftelse af køretøjsenheder
  
Eksempel:  Hvis ægthedsbekræftelse af en køretøjsenhed skal 
foretages med SHA-384, skal objektidentifikatoren
  
anvendes (i 
ASN.1-notation). Værdien af denne objektidentifikator i punktno tation 
er
 .  
Punktnotation  Byte-notation
  
»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«  
Datanavne på protokoller til ægthedsbekræftelse af chips
  
Eksempel:  Ægthedsbekræftelse af chips skal foretages med ECDH- 
algoritmen, så der fremkommer en AES-sessionsnøgle med 
en længde på 128 bit. Denne sessionsnøgle anvendes efterfølgend e 
i CBC-funktionstilstand til at sikre datafortrolighed, og 
CMAC-algoritmen anvendes for at sikre dataægthed. Derfor skal 
objektidentifikatoren
  
anvendes (i ASN.1-notation). Værdien af denne objektidentifikat or 
i punktnotation er
  .  
Punktnotation  Byte-notation
  
»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 — DA — 21.08.2023 — 003.001 — 229  
6.2. Applikationsidentifikatorer  
Anden generation:  
Applikationsidentifikatoren (AID) for det eksterne GNSS-udstyr (anden 
generation) er »FF 44 54 45 47 4D«. Dette er en beskyttet AID i  
overensstemmelse med ISO/IEC 7816-4.  
Bemærk:  De sidste fem bytes koder DTEGM for intelligente takografers 
eksterne GNSS-udstyr.  
Applikationsidentifikatoren for takografkortapplikationer af an den gene­
ration er »FF 53 4D 52 44 54«. Dette er en beskyttet AID i over ens­
stemmelse med ISO/IEC 7816-4.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 230  
Tillæg 2  
SPECIFIKATION AF TAKOGRAFKORT  
INDHOLDSFORTEGNELSE  
1. INDLEDNING  
1.1. Forkortelser  
1.2. Referencer  
2. ELEKTRISKE OG FYSISKE EGENSKABER  
2.1. Forsyningsspænding og strømforbrug  
2.2. Programmeringsspænding V  pp 
2.3. Klokgenerering og -frekvens  
2.4. I/O-kontakt  
2.5. Kortets tilstande  
3. HARDWARE OG KOMMUNIKATION  
3.1. Indledning  
3.2. Transmissionsprotokol  
3.2.1 Protokoller  
3.2.2 ATR  
3.2.3 PTS  
3.3. Adgangsregler  
3.4. Oversigt over kommandoer og fejlkoder  
3.5. Kommandobeskrivelser  
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 — DA — 21.08.2023 — 003.001 — 231  
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE  
3.5.15 PSO: VERIFY DIGITAL SIGNATURE  
3.5.16 PROCESS DSRC MESSAGE  
4. TAKOGRAFKORTENES STRUKTUR  
4.1. Hovedfil (Master file — MF)  
4.2. Førerkortapplikationer  
4.2.1 Førerkortapplikation af første generation  
4.2.2 Førerkortapplikation af anden generation  
4.3. Værkstedskortapplikationer  
4.3.1 Værkstedskortsapplikation af første generation  
4.3.2 Værkstedskortsapplikation af anden generation  
4.4. Kontrolkortapplikationer  
4.4.1 Kontrolkortapplikation af første generation  
4.4.2 Kontrolkortapplikation af anden generation  
4.5. Virksomhedskortapplikationer  
4.5.1 Virksomhedskortapplikation af første generation  
4.5.2 Virksomhedskortapplikation af anden generation  
1. INDLEDNING  
1.1. Forkortelser  
I dette tillæg anvendes følgende forkortelser:  
AC Betingelser for adgang til faciliteten  
AES Avanceret krypteringsstandard (Advanced Encryption 
Standard)  
AID Applikationsidentifikator (Application Identifier)  
ALW Altid (Always)  
APDU Dataenhed i applikationsprotokol (struktur i kommando) 
(Application Protocol Data Unit)  
ATR Svar på reset (Answer to Reset)  
AUT Identitetsbekræftet (Authenticated)  
C6, C7  Kortets kontakt nr. 6 og 7 som beskrevet i ISO/IEC 7816-2  
cc Klokcyklusser (clock cycles)  
▼M1 
CHA Certifikatindehavers autorisation (Certificate Holder 
Authorisation)  
▼B 
CHV Information til verifikation af kortindehaver (Card holder 
verification information)  
CLA Klassebyte i APDU-kommando (Class byte of an APDU 
command)  
▼M1 
DO Dataobjekt  
▼B 
DSRC Dedikeret kortdistancekommunikation (Dedicated Short 
Range Communication)  
DF Dedikeret fil En DF kan indeholde andre filer (EF eller DF)  
ECC Elliptisk kurvekryptografi (Elliptic Curve Cryptography)  
EF Elementærfil (Elementary File)  
etu Elementær tidsenhed (elementary time unit)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 232  
G1 Første generation  
G2 Anden generation  
IC Integreret kredsløb  
ICC Chipkort (Integrated Circuit Card)  
ID Identifikator  
IFD Kortlæser (interface device)  
IFS Længde af informationsfelt (information field size)  
IFSC Længde af informationsfelt til kort (information field siz e 
for the card)  
IFSD Informationsfeltlængde for kortlæser (information field 
size device)  
INS Ordrebyte i APDU-kommando (instruction byte)  
Lc Længde af inddata til APDU-kommando  
Le Længde af forventede data (uddata til en kommando)  
MF Hovedfil (dedikeret rodfil) (Master file)  
NAD Knudepunktadresse i en T = 1 protokol (Node address)  
NEV Aldrig  
P1-P2 Parameterbytes  
PIN Personligt identifikationsnummer  
PRO SM Beskyttet med sikker meddelelsesoverførsel (protected 
with secure messaging)  
PTS Valgt transmissionsprotokol (protocol transmission selec­
tion)  
RFU Forbeholdt fremtidig brug  
RST Nulstilling (af et kort) (Reset)  
SFID Kort id for elementærfil  
SM Sikker meddelelsesoverførsel  
SW1-SW2 Statusbytes  
TS Initialt tegn i ATR (svar på nulstilling)  
VPP Programmeringsspænding  
VU Køretøjsenhed  
XXh Størrelsen XX i hexadecimal notation  
»XXh« Størrelsen XX i hexadecimal notation  
|| Sammenkædningssymbol (03||04 = 0304)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 233  
1.2. Referencer  
I dette tillæg henvises til følgende referencer:  
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 proto­
cols. ISO/IEC 7816-3:2006.  
ISO/IEC 7816-4 Identification cards — Integrated circuit cards — 
Part 4: Organization, security and commands for 
interchange. ISO/IEC 7816-4:2013 + Cor 1: 2014.  
ISO/IEC 7816-6 Identification cards — Integrated circuit cards — 
Part 6: Interindustry data elements for interchange. 
ISO/IEC 7816-6:2004 + Cor 1: 2006.  
ISO/IEC 7816-8 Identification cards — Integrated circuit cards — 
Part 8: Commands for security operations. ISO/IEC 
7816-8:2004.  
ISO/IEC 9797-2 Information technology — Security techniques — 
Message Authentication Codes (MACs) — Part 2: 
Mechanisms using a dedicated hash-function. 
ISO/IEC 9797-2:2011  
2. ELEKTRISKE OG FYSISKE EGENSKABER  
TCS_01 Alle elektroniske signaler skal overholde ISO/IEC 7816-3 , 
medmindre andet er angivet.  
TCS_02 Placering og dimensioner af kortets kontakter skal være i 
overensstemmelse med ISO/IEC 7816-2.  
2.1. Forsyningsspænding og strømforbrug  
TCS_03 Kortet skal fungere i henhold til specifikationerne inde n for 
de forbrugsgrænser, der foreskrives i ISO/IEC 7816-3.  
TCS_04 Kortet skal fungere ved Vcc = 3 V (± 0,3 V) eller Vcc = 
5 V (± 0,5 V).  
Valg af spænding skal ske i overensstemmelse med 
ISO/IEC 7816-3.  
2.2. Programmeringsspænding V  pp 
TCS_05 Kortet behøver ingen programmeringsspænding på pin C6. 
Det forventes, at klemme C6 ikke tilsluttes en kortlæser. 
Kontakt C6 kan være tilsluttet Vcc i kortet, men må ikke 
stelforbindes. Denne spænding må ikke i noget tilfælde 
tolkes.  
2.3. Klokgenerering og -frekvens  
TCS_06 Kortet skal arbejde i et frekvensområde fra 1 til 5 MHz og 
kan understøtte højere frekvenser. Inden for én kortsession 
kan klokfrekvensen variere ± 2 %. Klokfrekvensen gene­
reres af køretøjsenheden, ikke af kortet selv. Arbejds­
cyklussen kan variere mellem 40 og 60 %.  
TCS_07 Under de betingelser, der er indeholdt i kortfilen EF IC C, 
kan den eksterne klokke standses. Den første byte i 
kroppen af filen EF ICC koder for betingelserne i 
Clockstop-funktionstilstand:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 234  
Lavt Højt  
Bit 3  Bit 2  Bit 1  
0 0  1  Clockstop tilladt, intet foretrukket niveau  
0 1  1  Clockstop tilladt, højt niveau foretrukket  
1 0  1  Clockstop tilladt, lavt niveau foretrukket  
0 0  0  Clockstop ikke tilladt  
0 1  0  Clockstop kun tilladt på højt niveau  
1 0  0  Clockstop kun tilladt på lavt niveau  
Bit 4 til 8 ubenyttet.  
2.4. I/O-kontakt  
TCS_08 I/O-kontakten C7 anvendes til at modtage og overføre dat a 
fra og til kortlæseren. Under funktion må kun enten kortet 
eller kortlæseren være i dataoverførselstilstand. Hvis begge 
enheder er i overførselstilstand, må det ikke kunne medføre 
skade på kortet. Medmindre kortet overfører data, skal det 
skifte til modtagetilstand.  
2.5. Kortets tilstande  
TCS_09 Kortet arbejder i to tilstande, mens forsyningsspændinge n 
tilføres:  
▼M3 
i driftstilstand, mens det udfører kommandoer eller er 
koblet til køretøjsenheden  
▼B 
i hviletilstand på alle andre tidspunkter; i denne tilstand 
skal alle data ligge på kortet.  
3. HARDWARE OG KOMMUNIKATION  
3.1. Indledning  
Dette afsnit beskriver de funktioner, der som minimum kræves af  
takografkort og køretøjsenheder for at sikre korrekt funktion o g 
interoperabilitet.  
Takografkort opfylder så vidt muligt de foreliggende gældende I SO/ 
IEC-normer (specielt ISO/IEC 7816). Dog beskrives kommandoer og  
protokoller fuldt ud for at specificere visse indskrænkninger i  brugen 
eller visse forskelle, når sådanne findes. De foreskrevne komma ndoer 
er fuldt forenelige med de anførte normer, medmindre andet er 
angivet.  
3.2. Transmissionsprotokol  
TCS_10 Transmissionsprotokollen skal være i overensstemmelse 
med ISO/IEC 7816-3 for T = 0 og T = 1. Specielt skal 
køretøjsenheden anerkende udvidelser af ventetid, som 
sendes af kortet.  
3.2.1  Protokoller  
TCS_11 Kortet skal give mulighed både for protokol  T = 0  og 
protokol  T = 1 . Derudover kan kortet understøtte andre 
kontaktrelaterede protokoller.  
TCS_12 T = 0 er standardprotokol, hvorfor der kræves en  PTS - 
kommando for at ændre protokol til T = 1.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 235  
TCS_13 Enheder skal understøtte  direkte konvention  i begge 
protokoller:  
TCS_14 Ved ATR præsenteres  Information Field Size Card -byten 
i TA3. Denne værdi skal være mindst »F0h« (= 240 bytes).  
For protokollerne gælder følgende begrænsninger:  
TCS_15  T = 0  
— Kortlæseren skal understøtte et svar på I/O efter begyn­
delsen af signalet på nulstilling fra 400 cc.  
— Kortlæseren skal kunne læse tegn, som er adskilt af 12 
etu. 
— Kortlæseren skal læse en forkert karakter og dens 
gentagelse, hvis de er adskilt af 13 etu. Hvis der regi­
streres en forkert karakter, kan fejlsignalet på I/O 
optræde mellem 1 etu og 2 etu. Kortlæseren skal under­
støtte en forsinkelse på 1 etu.  
— Kortlæseren skal acceptere et svar på nulstilling (ATR) 
på 33 bytes (TS + 32).  
— Hvis det pågældende ATR indeholder et TC1, skal den 
ekstra beskyttelsestid gælde for tegn sendt af kortlæ­
seren, dog kan tegn sendt af kortet stadig være adskilt 
af 12 etu. Dette gælder også for ACK-tegnet sendt af 
kortet efter, at der er afgivet et P3-tegn af kortlæseren.  
— Kortlæseren skal tage hensyn til et NUL-tegn afsendt 
fra kortet.  
— Kortlæseren skal acceptere den supplerende funktions­
tilstand for ACK.  
— Kommandoen GET RESPONSE kan ikke bruges i 
kædningsfunktion til at hente data, hvis længde even­
tuelt er over 255 bytes.  
TCS_16  T = 1  
— NAD-byte: ikke anvendt (NAD skal sættes til »00«).  
— S-block ABORT: Ikke anvendt.  
— S-block VPP state fejl: Ikke anvendt.  
▼M3 __________  
▼B 
— Informationsfeltstørrelse for kortlæser (IFSD) skal 
angives af kortlæseren umiddelbart efter svar på nulstil­
ling: Kortlæseren skal overføre S-blokkens 
IFS-forespørgsel efter svar på nulstilling (ATR), og 
kortet skal tilbagemelde S-blokkens IFS. Den anbefa­
lede værdi for IFSD er 254 bytes.  
— Kortet anmoder ikke om efterjustering af IFS.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 236  
3.2.2  ATR  
TCS_17 Kortlæseren kontrollerer ATR-bytes (svar på nulstilling)  i  
henhold til ISO/IEC 7816-3. Der skal ikke foretages 
kontrol af historiske ATR-tegn.  
Eksempel på grundlæggende biprotokollær ATR i henhold 
til ISO/IEC 7816-3  
Karakter  Værdi  Bemærkninger  
TS »3Bh«  Angiver direkte konvention  
T0 »85h«  TD1 foreligger; 5 historiske bytes til stede  
TD1 »80h«  TD1 foreligger; T = 0 skal anvendes  
TD2 »11h«  TA3 foreligger; T = 1 skal anvendes  
TA3 »XXh« (mindst 
»F0h«)  Størrelse af informationsfelt på kort (IFSC)  
TH1 til TH5  »XXh«  Historiske tegn  
TCK  »XXh«  Kontroltegn (eksklusive OR)  
TCS_18 Efter Answer To Reset (ATR) er hovedfilen (MF) valgt 
automatisk og bliver den aktuelle mappe.  
3.2.3  PTS  
TCS_19 Standardprotokollen er T = 0. For at vælge protokol T = 1 
skal der sendes en PTS (også benævnt PPS) til kortet fra 
kortlæseren.  
TCS_20 Da protokollerne T = 0 og T = 1 begge er påbudte for 
kortet, er det grundlæggende valg af transmissionsprotokol 
(PTS) for protokolskift påbudt for kortet.  
Som angivet i ISO/IEC 7816-3 kan PTS benyttes til at 
skifte til en højere transmissionshastighed end den stan­
dardhastighed, som vælges af kortet i svar på nulstilling 
(ATR), hvis der er nogen (TA(1)) bytes til stede.  
Højere transmissionshastigheder er valgfri for kortet.  
TCS_21 Hvis ingen anden transmissionshastighed end standardha­
stigheden understøttes (eller den valgte transmissions­
hastighed ikke understøttes), skal kortet svare korrekt på 
protokoltransmissionsvalget (PTS) i henhold til ISO/IEC 
7816-3 ved at udelade PPS1-byten.  
Følgende er eksempler på grundlæggende PTS til 
protokolvalg:  
Karakter  Værdi  Bemærkninger  
PPSS  »FFh«  Starttegn  
PPS0  »00h« eller »01h«  PPS1 til PPS3 findes ikke; »00h« for at vælge T0, »01h« 
for at vælge T1.  
PK »XXh«  Kontroltegn: »Xh« = »FFh«, hvis PPS0 = »00h« 
»XXh« = »FEh«, hvis PPS0 = »01h«  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 237  
3.3. Adgangsregler  
TCS_22 I en adgangsregel specificeres sikkerhedsbetingelserne f or 
en adgangstilstand, dvs. en kommando. Hvis disse sikker­
hedsbetingelser er opfyldt, behandles den tilsvarende 
kommando.  
TCS_23 Følgende sikkerhedsbetingelser bruges for takografkortet : 
Forkortelse  Betydning  
ALW  Operationen er altid mulig og kan udføres uden begrænsning. AP DU- 
kommandoer og -svar sendes som almindelig tekst, dvs. uden sikk er medde­
lelsesoverførsel.  
NEV  Operationen er aldrig mulig.  
PLAIN-C  Kommandoen APDU sendes som almindelig tekst, dvs. uden sikker medde­
lelsesoverførsel.  
PWD  Handlingen kan kun udføres, hvis værkstedskortets PIN-kode er blevet 
kontrolleret med tilfredsstillende resultat, dvs. hvis kortets interne sikkerheds­
status »PIN_Verified« er angivet. Kommandoen skal sendes uden s ikker 
meddelelsesoverførsel.  
EXT-AUT-G1  Handlingen kan kun udføres, hvis kommandoen External Authentic ate for 
ægthedsbekræftelse (første generation) (se også tillæg 11, del A) er gennem­
ført med tilfredsstillende resultat.  
SM-MAC-G1  APDU (kommando og svar) skal anvendes ved sikker meddelelsesov erførsel 
(første generation) i »authentication-only«-tilstand (se tillæg  11, del A).  
SM-C-MAC-G1  Kommandoen APDU skal anvendes ved sikker meddelelsesoverførsel  (første 
generation) i »authentication-only«-tilstand (se tillæg 11, del  A). 
SM-R-ENC-G1  Svaret APDU skal anvendes ved sikker meddelelsesoverførsel (fø rste genera­
tion) i krypteringstilstand (se tillæg 11, del A), dvs. der til bagemeldes ingen 
meddelelsesgodkendelseskode.  
SM-R-ENC- 
MAC-G1  Kommandoen APDU skal anvendes ved sikker meddelelsesoverførsel (første 
generation) i »encrypt-then-authenticate«-tilstand (se tillæg 1 1, del A).  
SM-MAC-G2  APDU (kommando og svar) skal anvendes ved sikker meddelelsesov erførsel 
(anden generation) i »authentication-only«-tilstand (se tillæg 11, del B).  
SM-C-MAC-G2  Kommandoen APDU skal anvendes ved sikker meddelelsesoverførsel  (anden 
generation) i »authentication-only«-tilstand (se tillæg 11, del  B). 
SM-R-ENC- 
MAC-G2  Kommandoen APDU skal anvendes ved sikker meddelelsesoverførsel (anden 
generation) i »encrypt-then-authenticate«-tilstand (se tillæg 1 1, del A).  
▼M1 
TCS_24 Disse sikkerhedsbetingelser kan kædes sammen på 
følgende måder:  
AND: Alle sikkerhedsbetingelser skal være opfyldt  
OR: Mindst én sikkerhedsbetingelse skal være opfyldt  
Adgangsreglerne for filsystemet, dvs. kommandoerne 
SELECT, READ BINARY og UPDATE BINARY, er 
nærmere beskrevet i afsnit 4. Adgangsreglerne for de reste­
rende kommandoer er nærmere beskrevet i følgende 
tabeller. Udtrykket »ikke relevant« anvendes, hvis der 
ikke findes noget krav til støtte for kommandoen. I så 
tilfælde kan kommandoen være støttet, men adgangsreg­
lerne er uden for gyldighedsområdet.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 238  
TCS_25 I applikationen DF Tachograph G1 anvendes følgende 
adgangsregler:  
▼M1 
Kommando  Førerkort  Værkstedskort  Kontrolkort  Virksomheds­
kort 
External Authenticate  
— For ægthedsbekræftelse 
(første generation)  ALW  ALW  ALW  ALW  
— For ægthedsbekræftelse 
(anden generation)  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  Ikke relevant  Ikke relevant  Ikke relevant  Ikke relevant  
PSO: Compute Digital Signature  ALW OR 
SM-MAC- 
G2 ALW OR 
SM-MAC- 
G2 Ikke relevant  Ikke relevant  
PSO: Hash  Ikke relevant  Ikke relevant  ALW  Ikke relevant  
PERFORM HASH OF FILE  ALW OR 
SM-MAC- 
G2 ALW OR 
SM-MAC- 
G2 Ikke relevant  Ikke relevant  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Ikke relevant  Ikke relevant  ALW  Ikke relevant  
Verify  Ikke relevant  ALW  Ikke relevant  Ikke relevant  
▼B 
TCS_26 I applikationen DF Tachograph_G2 anvendes følgende 
adgangsregler:  
▼M1 
Kommando  Førerkort  Værkstedskort  Kontrolkort  Virksomheds­
kort 
External Authenticate  
— For ægthedsbekræftelse 
(første generation)  Ikke relevant  Ikke relevant  Ikke relevant  Ikke relevant  
— For ægthedsbekræftelse 
(anden generation)  ALW  PWD  ALW  ALW  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 239  
Kommando  Førerkort  Værkstedskort  Kontrolkort  Virksomheds­
kort 
Internal Authenticate  Ikke relevant  Ikke relevant  Ikke relevant  Ikke relevant  
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  Ikke relevant  ALW  ALW  Ikke relevant  
PSO: Compute Digital Signature  ALW OR 
SM-MAC- 
G2 ALW OR 
SM-MAC- 
G2 Ikke relevant  Ikke relevant  
PSO: Hash  Ikke relevant  Ikke relevant  ALW  Ikke relevant  
PERFORM HASH OF FILE  ALW OR 
SM-MAC- 
G2 ALW OR 
SM-MAC- 
G2 Ikke relevant  Ikke relevant  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Ikke relevant  Ikke relevant  ALW  Ikke relevant  
Verify  Ikke relevant  ALW  Ikke relevant  Ikke relevant  
▼B 
TCS_27 I hovedfilen anvendes følgende adgangsregler:  
▼M1 
Kommando  Førerkort  Værkstedskort  Kontrolkort  Virksomheds­
kort 
External Authenticate  
— For første generation 
ægthedskontrol  Ikke relevant  Ikke relevant  Ikke relevant  Ikke relevant  
— For anden generation 
ægthedskontrol  ALW  PWD  ALW  ALW  
Internal Authenticate  Ikke relevant  Ikke relevant  Ikke relevant  Ikke relevant  
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 — DA — 21.08.2023 — 003.001 — 240  
Kommando  Førerkort  Værkstedskort  Kontrolkort  Virksomheds­
kort 
Process DSRC Message  Ikke relevant  Ikke relevant  Ikke relevant  Ikke relevant  
PSO: Compute Digital Signature  Ikke relevant  Ikke relevant  Ikke relevant  Ikke relevant  
PSO: Hash  Ikke relevant  Ikke relevant  Ikke relevant  Ikke relevant  
PERFORM HASH OF FILE  Ikke relevant  Ikke relevant  Ikke relevant  Ikke relevant  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Ikke relevant  Ikke relevant  Ikke relevant  Ikke relevant  
Verify  Ikke relevant  ALW  Ikke relevant  Ikke relevant  
▼B 
TCS_28 Et takografkort kan enten acceptere en kommando med et 
højere sikkerhedsniveau end niveauet i sikkerhedsbetingel­
serne eller ikke gøre det. Hvis sikkerhedsbetingelsen er 
ALW (eller PLAIN-C), kan kortet således acceptere en 
kommando med sikker meddelelsesoverførsel (kryptering 
og/eller ægthedsbekræftelsestilstand). Hvis sikkerhedsbetin­
gelsen kræver sikker meddelelsesoverførsel i ægtheds­
bekræftelsestilstand, kan takografkortet acceptere en 
kommando med sikker meddelelsesoverførsel af samme 
generation i ægthedsbekræftelses- og krypteringstilstand.  
Bemærk:  I kommandobeskrivelserne findes der flere oplys­
ninger om, ihvilket omfang kommandoerne understøtter de 
forskellige takografkorttyper og dedikerede filer.  
3.4. Oversigt over kommandoer og fejlkoder  
Kommandoer og filorganisation er afledt af og i overensstemmels e 
med ISO/IEC 78164.  
I dette afsnit beskrives følgende APDU-kommando-svar-par. De 
kommandovarianter, der understøttes af en applikation af første  eller 
anden generation, er nærmere beskrevet i de tilsvarende 
kommandobeskrivelser.  
Kommando  INS  
SELECT  »A4h«  
READ BINARY  »B0h«, »B1h«  
UPDATE BINARY  »D6h«, »D7h«  
GET CHALLENGE  »84h«  
VERIFY  »20h«  
GET RESPONSE  »C0h«  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 241  
Kommando  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 Statusordene SW1 SW2 tilbagemeldes sammen med enhver 
svarmeddelelse og angiver behandlingsstatus for 
kommandoen.  
SW1  SW2  Betydning  
90 0 0  Normal behandling af data.  
61 X X  Normal behandling af data. XX = antal svarbytes til rådighed  
62 8 1  Advarselsbehandling. En del af svardata kan være beskadiget  
63 0 0  Ægthedsbekræftelse mislykkedes (advarsel)  
63 C X  Forkert CHV (kortindehaververifikation, PIN). Indholdet i tæll er 
for resterende forsøg tilbagemeldes med »X«  
64 0 0  Kørselsfejl — Status for ikke-flygtigt lager uændret. Integrit ets­
fejl. 
65 0 0  Kørselsfejl — Status for ikke-flygtigt lager ændret.  
65 8 1  Kørselsfejl — Status for ikke-flygtigt lager ændret. Hukommel­
sesfejl  
66 8 8  Sikkerhedsfejl: forkert kryptografisk kontrolsum (ved sikker 
meddelelsesoverførsel) eller 
forkert certifikat (ved verifikation af certifikat) 
eller 
forkert kryptogram (ved ekstern ægthedsbekræf­
telse) eller 
forkert underskrift (ved verifikation af under­
skrift)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 242  
SW1  SW2  Betydning  
67 0 0  Forkert længde (forkert Lc eller Le)  
68 8 3  Sidste kommando i den forventede kæde  
69 0 0  Forbudt kommando (intet svar foreligger i T = 0)  
69 8 2  Sikkerhedsstatus ikke tilfredsstillet  
69 8 3  Ægthedsbekræftelse blokeret  
69 8 5  Betingelser for anvendelse ikke opfyldt  
69 8 6  Kommando ikke tilladt (ingen aktuel elementærfil)  
69 8 7  Forventede dataobjekter for sikker meddelelsesoverførsel mangl er 
69 8 8  Ukorrekte dataobjekter for sikker meddelelsesoverførsel  
6A 8 0  Ukorrekte parametre i datafelt  
6A 8 2  Filer ikke fundet  
6A 8 6  Forkerte parametre P1-P2  
6A 8 8  De adresserede data kunne ikke findes  
6B 0 0  Forkerte parametre (adressetillæg uden for elementærfil)  
6C X X  Forkert længde, SW2 angiver eksakt længde. Intet datafelt tilb a­
gemeldes  
6D 0 0  Operationskode ikke understøttet eller ugyldig  
6E 0 0  Klasse ikke understøttet  
6F 0 0  — Andre kontrolfejl  
Der kan tilbagemeldes yderligere statusord som defineret i 
ISO/IEC 7816-4, hvis deres funktion ikke er udtrykkeligt 
nævnt i dette tillæg.  
F.eks. kan følgende statusord eventuelt tilbagemeldes:  
6881: Logisk kanal ikke understøttet  
6882: Sikker meddelelsesoverførsel ikke understøttet  
▼B 
TCS_30 Hvis mere end én fejlbetingelse er opfyldt i en 
kommando-APDU kan kortet tilbagemelde ethvert af de 
passende statusord.  
3.5. Kommandobeskrivelser  
Påbudte kommandoer for takografkort er beskrevet i dette kapite l. 
Supplerende relevante enkeltheder om de anvendte kryptografiske  
operationer er givet i tillæg 11 (fælles sikkerhedsmekanismer) for 
takografer af første og anden generation.  
Alle kommandoer beskrives uafhængigt af den anvendte protokol ( T = 
0 eller T = 1). APDU-bytene CLA, INS, P1, P2, Lc og Le bliver a ltid 
angivet. Hvis Lc eller Le ikke er nødvendig for den beskrevne 
kommando, er den tilhørende længde, værdi og beskrivelse tomme.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 243  
TCS_31 Anmodes der om begge længdebytes (Lc og Le), skal den 
beskrevne kommando deles i to dele, hvis kortlæseren 
bruger protokol T = 0: Kortlæseren sender kommandoen 
som beskrevet ved hjælp af P3 = Lc + data og sender 
derefter en GET RESPONSE (se punkt 3.5.6) kommando 
med P3 = Le.  
TCS_32 Anmodes der om begge længdebytes, og Le = 0 (sikker 
meddelelsesoverførsel):  
— når der bruges protokol T = 1, skal kortet svare på Le = 
0 ved at sende alle tilgængelige uddata  
— når protokol T = 0 anvendes, skal kortlæseren sende 
den første kommando med P3 = Lc + data, kortet skal 
(på det implicitte Le = 0) svare med statusbytes 
»61La «, hvor La er antal svarbytes til rådighed. Kort­
læseren skal derefter generere en GET RESPONSE- 
kommando med P3 = La for at læse data.  
TCS_33 Takografkort kan understøtte felter med udvidet længde i  
overensstemmelse med ISO/IEC 7816-4 som en valgfri 
funktion. Et takografkort, som understøtter felter med 
udvidet længde, skal  
— angive, at felter med udvidet længde understøttes, i 
ATR  
— angive de understøttede bufferstørrelser ved hjælp af 
oplysningerne med udvidet længde i elementærfilen 
ATR/INFO, se TCS_146  
— angive, om det understøtter felter med udvidet længde 
for T = 1 og/eller T = 0, i elementærfilen Extended 
Length, se TCS_147  
— understøtte felter med udvidet længde for takografap­
plikationer af første og anden generation.  
Bemærkninger:  
Alle kommandoer beskrives nærmere for felter med kort 
længde. Brug af APDU'er med udvidet længde beskrives 
i ISO/IEC 7816-4.  
Generelt anføres kommandoerne for ordinær funktionstil­
stand, dvs. uden sikker meddelelsesoverførsel, da laget til 
sikker meddelelsesoverførsel er nærmere beskrevet i tillæg 
11. Det fremgår klart af adgangsreglerne for en kommando, 
om kommandoen skal understøtte sikker meddelelsesover­
førsel eller ej, og om den skal understøtte sikker meddelel­
sesoverførsel for første og/eller anden generation. En række 
kommandovarianter beskrives med hensyn til sikker 
meddelelsesoverførsel for at illustrere brugen af sikker 
meddelelsesoverførsel.  
TCS_34 Køretøjsenheden skal gennemføre hele den fælles ægtheds­
bekræftelsesprotokol for køretøjsenheder og kort af anden 
generation for en session, herunder (om nødvendigt) certi­
fikatverificeringen — enten i DF Tachograph, DF Tacho­
graph_G2 eller hovedfilen.  
3.5.1  SELECT  
Denne kommando overholder ISO/IEC 7816-4, men har begrænset 
anvendelse i forhold til den i normen definerede kommando.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 244  
SELECT-kommandoen anvendes:  
— til at vælge en applikationsdedikeret fil (skal vælges med na vn) 
— til at vælge en elementærfil svarende til det forelagte filna vn. 
3.5.1.1 V a l g v e d n a v n ( A I D )  
Med denne kommando kan der vælges en applikationsdedikeret fil på 
kortet.  
TCS_35 Denne kommando kan udføres fra et vilkårligt sted i 
filstrukturen (efter svar på nulstilling (ATR) eller på et 
vilkårligt tidspunkt).  
TCS_36 Når der vælges en applikation, bliver det aktuelle sikke r­
hedsmiljø nulstillet. Efter valget af applikationen er der 
ikke længere valgt nogen aktuel offentlig nøgle. Adgangs­
betingelsen EXT-AUT-G1 mistes ligeledes. Hvis komman­
doen blev udført uden sikker meddelelsesoverførsel, er de 
tidligere sessionsnøgler til sikker meddelelsesoverførsel 
ikke længere til rådighed.  
TCS_37  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »A4h«  
P1 1  »04h«  Valg ved navn (AID)  
P2 1  »0Ch«  Intet svar forventet  
Lc 1  »NNh«  Antal byte sendt til kortet (længde af AID): 
»06h« for takografapplikationen  
#6-#(5+NN)  N N  »XX..XXh«  AID: »FF 54 41 43 48 4F« for takografapplikationen af 
første generation 
AID: »FF 53 4D 52 44 54« for takografapplikationen af 
anden generation  
Der kræves intet svar på kommandoen SELECT (Le findes 
ikke i T = 1, eller der anmodes ikke om svar i T = 0).  
TCS_38  Svarmeddelelse (der er ikke anmodet om svar)  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Hvis den applikation, som svarer til applikationsnavnet, 
ikke findes, tilbagemeldes status » 6A82 «. 
— Hvis byten Le er til stede i T = 1, tilbagemeldes status 
»6700 «. 
— Hvis der i T = 0 anmodes om et svar efter 
SELECT-kommandoen, tilbagemeldes status » 6900 «. 
▼M1 
— Hvis den valgte applikation anses for beskadiget (der er 
fundet integritetsfejl i filattributterne), tilbagemeldes 
behandlingsstatus » 6400 « eller » 6500 «. ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 245  
3.5.1.2 V a l g a f e n e l e m e n t æ r f i l v e d h j æ l p  a f f i l n a v n e t  
TCS_39  Kommandomeddelelse  
TCS_40 Takografkort skal understøtte sikker meddelelsesoverførs el 
(anden generation) som foreskrevet i tillæg 11, del B for 
denne kommandovariant.  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »A4h«  
P1 1  »02h«  Valg af en elementærfil under den aktuelle dedikerede fil  
P2 1  »0Ch«  Intet svar forventet  
Lc 1  »02h«  Antal bytes sendt til kortet  
#6-#7  2  »XXXXh«  Filnavn  
Der kræves intet svar på kommandoen SELECT (Le findes 
ikke i T = 1, eller der anmodes ikke om svar i T = 0).  
TCS_41  Svarmeddelelse (der er ikke anmodet om svar)  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Hvis filen svarende til det pågældende filnavn ikke 
findes, tilbagemeldes status » 6A82 «. 
— Hvis byten Le er til stede i T = 1, tilbagemeldes status 
»6700 «. 
— Hvis der i T = 0 anmodes om et svar efter 
SELECT-kommandoen, tilbagemeldes status » 6900 «. 
▼M1 
— Hvis den valgte fil anses for beskadiget (der er fundet 
integritetsfejl i filattributterne), tilbagemeldes behand­
lingsstatus » 6400 « eller » 6500 «. 
▼B 
3.5.2  READ BINARY  
Denne kommando overholder ISO/IEC 7816-4, men har begrænset 
anvendelse i forhold til den i normen definerede kommando.  
Kommandoen READ BINARY anvendes til at læse data fra en trans­
parent fil.  
Kortets svar består i at tilbagemelde de læste data, om ønsket indkap­
slet i en sikker meddelelsesstruktur.  
3.5.2.1 K o m m a n d o m e d f o r s k y d n i n g i P 1 - P 2  
Denne kommando giver kortlæseren mulighed for uden sikker medde ­
lelsesoverførsel at læse data fra den aktuelt valgte elementærf il. 
Bemærk:  Denne kommando uden sikker meddelelsesoverførsel kan 
kun bruges til at læse en fil, som understøtter sikkerhedsbetin gelsen 
ALW for læseadgangstilstand.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 246  
TCS_42  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »B0h«  Read Binary  
P1 1  »XXh«  Forskydning i bytes fra filens begyndelse: Mest bety­
dende byte  
P2 1  »XXh«  Forskydning i bytes fra filens begyndelse: Mindst bety­
dende byte  
Le 1  »XXh«  Forventet datalængde. Antal bytes, som skal læses.  
Bemærk:  bit 8 af P1 skal være sat til 0.  
TCS_43  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
#1-#X  X  »XX..XXh«  Data læst  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Vælges ingen elementærfil, tilbagemeldes behandlings­
status » 6986 «. 
— Er sikkerhedsbetingelserne for den valgte fil ikke 
opfyldt, afbrydes kommandoen med » 6982 «. 
— Er forskydningen ikke forenelig med elementærfilens 
størrelse (forskydning > størrelse af EF), tilbagemeldes 
status » 6B00 «. 
— Er størrelsen af de data, der skal læses, ikke forenelig 
med elementærfilens størrelse (forskydning + Le > stør­
relsen af EF), tilbagemeldes status » 6700 « eller 
»6Cxx «, hvor »xx« er den eksakte længde.  
▼M1 
— Konstateres der en integritetsfejl i filattributterne, skal 
kortet anse filen for uoprettelig beskadiget, og der tilba­
gemeldes behandlingsstatus » 6400 « eller » 6500 «. 
▼B 
— Konstateres der en integritetsfejl i de lagrede data, skal 
kortet tilbagemelde de ønskede data, og der tilbage­
meldes status » 6281 «. 
3.5.2.1.1 K o m m a n d o m e d s i k k e r m e d d e l e l s e  s o v e r f ø r s e l 
( e k s e m p l e r )  
Denne kommando giver IDF mulighed for at læse data fra den aktu elt 
valgte elementærfil med sikkert meddelelsessystem, med det form ål at 
efterprøve identiteten af de modtagne data og beskytte fortroli gheden 
af data, hvis sikkerhedsbetingelsen SM-R-ENC-MAC-G1 (første gen e­
ration) eller SM-R-ENC-MAC-G2 (anden generation) gælder.  
TCS_44  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »0Ch«  Der er anmodet om sikker meddelelsesoverførsel  
INS 1  »B0h«  Read Binary  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 247  
Byte  Længde  Værdi  Beskrivelse  
P1 1  »XXh«  P1 (forskydning i bytes fra filens begyndelse): Mest 
betydende byte  
P2 1  »XXh«  P2 (forskydning i bytes fra filens begyndelse): Mindst 
betydende byte  
Lc 1  »XXh«  Længde af inddata til sikker meddelelse  
#6 1  »97h«  T  LE : Etiket for angivelse af forventet længde  
#7 1  »01h«  L  LE : Forventet længde  
#8 1  »NNh«  Angivelse af forventet længde (oprindelig Le): Antal 
bytes, som skal læses  
#9 1  »8Eh«  T  CC : Etiket for kryptografisk kontrolsum  
#10 1  »XXh«  L  CC : Længde af efterfølgende kryptografiske kontrolsum 
»04h« for sikker meddelelsesoverførsel (første genera­
tion) (se tillæg 11, del A) 
»08h«, »0Ch« eller »10h« afhængigt af AES-nøgle­
længden for sikker meddelelsesoverførsel (anden genera­
tion) (se tillæg 11, del B)  
#11-#(10+L)  L  »XX..XXh«  Kryptografisk kontrolsum  
Le 1  »00h«  Som foreskrevet i ISO/IEC 7816-4  
TCS_45  Svarmeddelelse, hvis SM-R-ENC-MAC-G1 (første gene ­
ration) / SM-R-ENC-MAC-G2 (anden generation) ikke 
kræves, og hvis inddataformatet for sikker overførsel er 
korrekt:  
▼M1 
Byte  Læng­
de Værdi  Beskrivelse  
#1 1  »81h«  T  PV : Etiket for data med ordinær værdi  
#2 L  »NNh« eller 
»81 NNh«  L PV : længde af tilbagemeldte data (= original 
Le). 
L er 2 bytes, hvis L  PV >127 bytes.  
#(2+L) - #(1+L+NN)  N N  »XX..XXh«  Ordinær dataværdi  
#(2+L+NN)  1  »99h«  Etiket til behandlingsstatus (SW1-SW2) — 
valgfri for sikker meddelelsesoverførsel 
(første generation)  
#(3+L+NN)  1  »02h«  Længde af behandlingsstatus — valgfri for 
sikker meddelelsesoverførsel (første genera­
tion)  
#(4+L+NN) - #(5+L+NN)  2  »XX XXh«  Behandlingsstatus for det ubeskyttede 
APDU-svar — valgfri for sikker meddelel­
sesoverførsel (første generation)  
#(6+L+NN)  1  »8Eh«  TCC: Etiket for kryptografisk kontrolsum  
#(7+L+NN)  1  »XXh«  LCC: Længde af efterfølgende kryptogra­
fiske kontrolsum 
»04h« for sikker meddelelsesoverførsel 
(første generation) (se tillæg 11, del A) 
»08h«, »0Ch« eller »10h« afhængigt af 
AES-nøglelængden for sikker meddelelses­
overførsel (anden generation) (se tillæg 11, 
del B)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 248  
Byte  Læng­
de Værdi  Beskrivelse  
#(8+L+NN)-#(7+M+L+NN)  M  »XX..XXh«  Kryptografisk kontrolsum  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
▼B 
TCS_46  Svarmeddelelse, hvis SM-R-ENC-MAC-G1 (første gene ­
ration) / SM-R-ENC-MAC-G2 (anden generation) 
kræves, og hvis inddataformatet for sikker overførsel 
er korrekt:  
▼M1 
Byte  Læng­
de Værdi  Beskrivelse  
#1 1  »87h«  T  PI CG  : Etiket for krypterede data (krypto­
gram)  
#2 L  »MMh« eller 
»81 MMh«  L PI CG  : Længde af tilbagemeldte krypterede 
data (afviger pga. udfyldning fra komman­
doens oprindelige længde Le). 
L er 2 bytes, hvis LPI CG >127 bytes.  
#(2+L)-#(1+L+MM)  M M  »01XX..XXh«  Krypterede data: Udfyldningsindikator og 
kryptogram  
#(2+L+MM)  1  »99h«  Etiket til behandlingsstatus (SW1-SW2) — 
valgfri for sikker meddelelsesoverførsel 
(første generation)  
#(3+L+MM)  1  »02h«  Længde af behandlingsstatus — valgfri for 
sikker meddelelsesoverførsel (første genera­
tion)  
#(4+L+MM) - #(5+L+MM)  2  »XX XXh«  Behandlingsstatus for det ubeskyttede 
APDU-svar — valgfri for sikker meddelel­
sesoverførsel (første generation)  
#(6+L+MM)  1  »8Eh«  TCC: Etiket for kryptografisk kontrolsum  
#(7+L+MM)  1  »XXh«  LCC: Længde af efterfølgende kryptogra­
fiske kontrolsum 
»04h« for sikker meddelelsesoverførsel 
(første generation) (se tillæg 11, del A) 
»08h«, »0Ch« eller »10h« afhængigt af 
AES-nøglelængden for sikker meddelelses­
overførsel (anden generation) (se tillæg 11, 
del B)  
#(8+L+MM)- 
#(7+N+L+MM)  N »XX..XXh«  Kryptografisk kontrolsum  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
▼B 
Kommandoen READ BINARY kan tilbagemelde de ordi­
nære behandlingsstatusser, der er anført i TCS_43 under 
etiket »99h« som beskrevet i TCS_59 ved brug af svar­
strukturen for sikker meddelelsesoverførsel.  
Derudover kan der optræde visse fejl, som særligt vedrører 
sikker meddelelsesoverførsel. I så fald tilbagemeldes 
behandlingsstatus simpelthen, uden at nogen struktur for 
sikker meddelelsesoverførsel er inddraget:  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 249  
TCS_47  Svarmeddelelse, hvis det indlæste format for sikker 
meddelelsesoverførsel er ukorrekt  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Foreligger der ingen nøgle for den aktuelle session, 
tilbagemeldes behandlingsstatus » 6A88 «. Dette sker, 
hvis sessionsnøglen enten ikke er genereret i forvejen 
eller er blevet ugyldig (i så fald skal kortlæseren på ny 
udføre den gensidige ægthedsbekræftelse, så der fast­
sættes en ny sessionsnøgle).  
— Hvis der mangler nogle forventede dataobjekter (som 
ovenfor specificeret) i formatet for sikker meddelelses­
overførsel, tilbagemeldes behandlingsstatus » 6987 «: 
Denne fejl opstår, hvis der mangler en forventet 
etiket, eller hvis kommandoen ikke er korrekt opbygget.  
— Hvis nogle dataobjekter er ukorrekte, tilbagemeldes 
status » 6988 «: Denne fejl optræder, når alle de nødven­
dige etiketter er til stede, men visse af længderne ikke 
svarer til de forventede.  
— Lykkes verifikationen af den kryptografiske kontrolsum 
ikke, tilbagemeldes behandlingsstatus » 6688 «. 
3.5.2.2 K o m m a n d o m e d k o r t i d f o r e l e m e n t æ  r f i l  
Denne kommandovariant giver kortlæseren mulighed for at vælge e n 
elementærfil ved hjælp af et kort id for elementærfilen og læse  data 
fra filen.  
TCS_48 Et takografkort skal understøtte denne kommandovariant 
for alle elementærfiler med et fastsat kort id for elementær­
filen. Disse korte id'er for elementærfiler er nærmere 
beskrevet i afsnit 4.  
TCS_49  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »B0h«  Read Binary  
P1 1  »XXh«  Bit 8 er sat til 1 
Bit 7 og 6 er sat til 00 
Bit 5-1 koder det korte id for den tilsvarende elemen­
tærfil  
P2 1  »XXh«  Koder en forskydning fra 0 til 255 bytes i den elemen­
tærfil, som P1 henviser til  
Le 1  »XXh«  Forventet datalængde. Antal bytes, som skal læses.  
Bemærk:  De korte id'er for elementærfiler, der anvendes til 
takografapplikationen af anden generation, er nærmere 
beskrevet i afsnit 4.  
Hvis P1 koder et kort id for en elementærfil, og komman­
doen giver resultat, bliver den identificerede elementærfil til  
den aktuelt valgte elementærfil (den aktuelle elementærfil).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 250  
TCS_50  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
#1-#L  L  »XX..XXh«  Data læst  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Hvis filen svarende til det korte id for elementærfilen 
ikke findes, tilbagemeldes status » 6A82 «. 
— Er sikkerhedsbetingelserne for den valgte fil ikke 
opfyldt, afbrydes kommandoen med » 6982 «. 
— Er forskydningen ikke forenelig med elementærfilens 
størrelse (forskydning > størrelse af EF), tilbagemeldes 
status » 6B00 «. 
— Er størrelsen af de data, der skal læses, ikke forenelig 
med elementærfilens størrelse (forskydning + Le > stør­
relsen af EF), tilbagemeldes status » 6700 « eller 
»6Cxx «, hvor »xx« er den eksakte længde.  
▼M1 
— Konstateres der en integritetsfejl i filattributterne, skal 
kortet anse filen for uoprettelig beskadiget, og der tilba­
gemeldes behandlingsstatus » 6400 « eller » 6500 «. 
▼B 
— Konstateres der en integritetsfejl i de lagrede data, skal 
kortet tilbagemelde de ønskede data, og der tilbage­
meldes status » 6281 «. 
3.5.2.3 K o m m a n d o m e d u l i g e o r d r e b y t e  
Denne kommandovariant giver kortlæseren mulighed for at læse da ta 
fra en elementærfil med 32 768 bytes eller derover.  
TCS_51 Takografkort, som understøtter elementærfiler med 32 768  
bytes eller derover, skal understøtte denne kommandova­
riant for disse elementærfiler. Et takografkort kan eventuelt 
understøtte denne kommandovariant for andre elementær­
filer med undtagelse af elementærfilen Sensor_Installa­
tion_Data. Se TCS_156 og TCS_160.  
TCS_52  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »B1h«  Read Binary  
P1 1  »00h«  Aktuel elementærfil  
P2 1  »00h«  
Lc 1  »NNh«  Lc Længde af forskydningsdataobjekt.  
#6-#(5+NN)  N N  »XX..XXh«  Forskydningsdataobjekt: 
Etiket »54h« 
Længde »01h« eller »02h« 
Værdi forskudt  
▼M1 
Le 1  »XXh«  Som foreskrevet i ISO/IEC 7816-4  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 251  
Kortlæseren skal kode længden på forskydningsdata­
objektet med det mindst mulige antal oktetter. For 
eksempel skal kortlæseren ved brug af længdebyten 
»01h« kode en forskydning fra 0 til 255, og ved brug af 
længdebyten »02h« skal den kode en forskydning fra 
»256« op til »65 535« bytes.  
▼M1 
Hvis T = 0, antager kortet værdien Le = »00h«, hvis der 
ikke anvendes sikker meddelelsesoverførsel.  
Hvis T = 1, tilbagemeldes behandlingsstatus »6700«, hvis 
Le=»01h«.  
▼B 
TCS_53  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
#1-#L  L  »XX..XXh«  Læste data, der er indkapslet i et objekt med yderligere 
data med etiketten »53h«.  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Vælges ingen elementærfil, tilbagemeldes behandlings­
status » 6986 «. 
— Er sikkerhedsbetingelserne for den valgte fil ikke 
opfyldt, afbrydes kommandoen med » 6982 «. 
— Er forskydningen ikke forenelig med elementærfilens 
størrelse (forskydning > størrelse af EF), tilbagemeldes 
status » 6B00 «. 
— Er størrelsen af de data, der skal læses, ikke forenelig 
med elementærfilens størrelse (forskydning + Le > stør­
relsen af EF), tilbagemeldes status » 6700 « eller 
»6Cxx «, hvor »xx« er den eksakte længde.  
▼M1 
— Konstateres der en integritetsfejl i filattributterne, skal 
kortet anse filen for uoprettelig beskadiget, og der tilba­
gemeldes behandlingsstatus » 6400 « eller » 6500 «. 
▼B 
— Konstateres der en integritetsfejl i de lagrede data, skal 
kortet tilbagemelde de ønskede data, og der tilbage­
meldes status » 6281 «. 
3.5.2.3.1 K o m m a n d o m e d s i k k e r m e d d e l e l s e  s o v e r f ø r s e l 
( e k s e m p l e r )  
Kommando med sikker meddelelsesoverførsel (eksempler)Følgende 
eksempel viser brug af sikker meddelelsesoverførsel, hvis sikke rheds­
betingelsen SM-MAC-G2 gælder.  
TCS_54 Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »0Ch«  Der er anmodet om sikker meddelelsesoverførsel  
INS 1  »B1h«  Read Binary  
P1 1  »00h«  Aktuel elementærfil  
P2 1  »00h«  
Lc 1  »XXh«  Længde af det sikrede datafelt  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 252  
Byte  Længde  Værdi  Beskrivelse  
#6 1  »B3h«  Etiket for data med ordinær værdi, der er kodet i 
BER-TLV  
#7 1  »NNh«  L  PV : længde af overførte data  
#(8)-#(7+NN)  N N  »XX..XXh«  Ordinære data, der er kodet i BER-TLV, dvs. forskyd­
ningsdataobjektet med etiket »54«  
#(8+NN)  1  »97h«  T  LE : Etiket for angivelse af forventet længde  
#(9+NN)  1  »01h«  L  LE : Forventet længde  
#(10+NN)  1  »XXh«  Angivelse af forventet længde (oprindelig Le): Antal 
bytes, som skal læses  
#(11+NN)  1  »8Eh«  T  CC : Etiket for kryptografisk kontrolsum  
#(12+NN)  1  »XXh«  L  CC : Længde af efterfølgende kryptografiske kontrolsum 
»08h«, »0Ch« eller »10h« afhængigt af AES-nøgle­
længden for sikker meddelelsesoverførsel (anden genera­
tion) (se tillæg 11, del B)  
#(13+NN)- 
#(12+M+NN)  M »XX..XXh«  Kryptografisk kontrolsum  
Le 1  »00h«  Som foreskrevet i ISO/IEC 7816-4  
TCS_55 Svarmeddelelse, hvis kommandoen giver resultat  
Byte  Længde  Værdi  Beskrivelse  
#1 1  »B3h«  Ordinære data kodet i BER-TLV  
#2 L  »NNh« eller 
»81 NNh«  L PV : længde af tilbagemeldte data (= original Le). 
L er 2 bytes, hvis L  PV > 127 bytes.  
#(2+L)- 
#(1+L+NN)  NN »XX..XXh«  Ordinære data, der er kodet i BER-TLV, dvs. indlæste 
data, som er indkapslet i et objekt med yderligere data 
med etiket »53h«.  
#(2+L+NN)  1  »99h«  Behandlingsstatus for det ubeskyttede APDU-svar  
#(3+L+NN)  1  »02h«  Behandlingsstatussens længde  
#(4+L+NN)- 
#(5+L+NN)  2 »XX XXh«  Behandlingsstatus for det ubeskyttede APDU-svar  
#(6+L+NN)  1  »8Eh«  T  CC : Etiket for kryptografisk kontrolsum  
#(7+L+NN)  1  »XXh«  L  CC : Længde af efterfølgende kryptografiske kontrolsum 
»08h«, »0Ch« eller »10h« afhængigt af AES-nøgle­
længden for sikker meddelelsesoverførsel (anden genera­
tion) (se tillæg 11, del B)  
#(8+L+NN)- 
#(7+M+L+ 
NN) M »XX..XXh«  Kryptografisk kontrolsum  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
3.5.3  UPDATE BINARY  
Denne kommando overholder ISO/IEC 7816-4, men har begrænset 
anvendelse i forhold til den i normen definerede kommando.  
Med kommandomeddelelsen UPDATE BINARY igangsættes opdate­
ring (sletning + skrivning) af de bit, der i forvejen ligger i en binær 
elementærfil, med de bit, der er indeholdt i kommandoen APDU.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 253  
3.5.3.1 K o m m a n d o m e d f o r s k y d n i n g i P 1 - P 2  
Denne kommando giver kortlæseren mulighed for at skrive data ti l 
den aktuelt valgte elementærfil, uden at kortet kontrollerer æg theden 
af de modtagne data.  
Bemærk:  Denne kommando uden sikker meddelelsesoverførsel kan 
kun bruges til at opdatere en fil, som understøtter sikkerhedsb etin­
gelsen ALW for opdateringsadgangstilstand.  
TCS_56  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »D6h«  Update Binary  
P1 1  »XXh«  Forskydning i bytes fra filens begyndelse: Mest bety­
dende byte  
P2 1  »XXh«  Forskydning i bytes fra filens begyndelse: Mindst bety­
dende byte  
Lc 1  »NNh«  Længde af data, som skal opdateres. Antal bytes, som 
skal skrives  
#6-#(5+NN)  N N  »XX..XXh«  Data, som skal skrives  
Bemærk:  bit 8 af P1 skal være sat til 0.  
TCS_57  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Vælges ingen elementærfil, tilbagemeldes behandlings­
status » 6986 «. 
— Er sikkerhedsbetingelserne for den valgte fil ikke 
opfyldt, afbrydes kommandoen med » 6982 «. 
— Er forskydningen ikke forenelig med elementærfilens 
størrelse (forskydning > størrelse af EF), tilbagemeldes 
status » 6B00 «. 
— Er størrelsen af de data, der skal skrives, ikke forenelig 
med elementærfilens størrelse (forskydning + Lc > stør­
relsen af EF), tilbagemeldes status » 6700 «. 
— Konstateres der en integritetsfejl i filattributterne, skal 
kortet anse filen for uoprettelig beskadiget, og den 
tilbagemeldte behandlingsstatur er » 6400 « eller » 6500 «. 
— Hvis der ikke kan skrives, tilbagemeldes behandlings­
status » 6581 «. 
3.5.3.1.1 K o m m a n d o m e d s i k k e r m e d d e l e l s e  s o v e r f ø r s e l 
( e k s e m p l e r )  
Denne kommando giver kortlæseren mulighed for at skrive data ti l 
den aktuelt valgte elementærfil, idet kortet kontroller ægthede n af de 
modtagne data. Da der ikke kræves fortrolighed, er data ikke 
krypteret.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 254  
TCS_58  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »0Ch«  Der er anmodet om sikker meddelelsesoverførsel  
INS 1  »D6h«  Update Binary  
P1 1  »XXh«  Forskydning i bytes fra filens begyndelse: 
Mest betydende byte  
P2 1  »XXh«  Forskydning i bytes fra filens begyndelse: 
Mindst betydende byte  
Lc 1  »XXh«  Længde af det sikrede datafelt  
#6 1  »81h«  T  PV : Etiket for data med ordinær værdi  
#7 L  »NNh« eller 
»81 NNh«  L PV : længde af overførte data 
L er 2 bytes, hvis L  PV > 127 bytes.  
#(7+L)- 
#(6+L+NN)  NN »XX..XXh«  Værdi af ordinære data (data, som skal skrives)  
#(7+L+NN)  1  »8Eh«  T  CC : Etiket for kryptografisk kontrolsum  
#(8+L+NN)  1  »XXh«  L  CC : Længde af efterfølgende kryptografiske kontrolsum 
»04h« for sikker meddelelsesoverførsel (første genera­
tion) (se tillæg 11, del A) 
»08h«, »0Ch« eller »10h« afhængigt af AES-nøgle­
længden for sikker meddelelsesoverførsel (anden genera­
tion) (se tillæg 11, del B)  
#(9+L+NN)- 
#(8+M+L+ 
NN) M »XX..XXh«  Kryptografisk kontrolsum  
Le 1  »00h«  Som foreskrevet i ISO/IEC 7816-4  
TCS_59  Svarmeddelelse, hvis inddata har det korrekte format til 
sikker meddelelsesoverførsel  
Byte  Længde  Værdi  Beskrivelse  
#1 1  »99h«  T  SW : Etiket for statusord (skal beskyttes af CC)  
#2 1  »02h«  L  SW : længde af tilbagemeldte statusord  
#3-#4  2  »XXXXh«  Behandlingsstatus for det ubeskyttede APDU-svar  
#5 1  »8Eh«  T  CC : Etiket for kryptografisk kontrolsum  
#6 1  »XXh«  L  CC : Længde af efterfølgende kryptografiske kontrolsum 
»04h« for sikker meddelelsesoverførsel (første genera­
tion) (se tillæg 11, del A) 
»08h«, »0Ch« eller »10h« afhængigt af AES-nøgle­
længden for sikker meddelelsesoverførsel (anden genera­
tion) (se tillæg 11, del B)  
#7-#(6+L)  L  »XX..XXh«  Kryptografisk kontrolsum  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
De »ordinære« behandlingsstatusser, som beskrives for 
kommandoen UPDATE BINARY uden sikker meddelelses­
overførsel (se punkt 3.5.3.1), kan tilbagemeldes med den 
svarmeddelelsesstruktur, som er beskrevet ovenfor.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 255  
Derudover kan der optræde visse fejl, som særligt vedrører 
sikker meddelelsesoverførsel. I så fald tilbagemeldes 
behandlingsstatus simpelthen, uden at nogen struktur for 
sikker meddelelsesoverførsel er inddraget:  
TCS_60  Svarmeddelelse ved fejl i sikker meddelelsesoverførsel  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Foreligger der ingen nøgle for den aktuelle session, 
tilbagemeldes behandlingsstatus » 6A88 «. 
— Hvis der mangler nogle forventede dataobjekter (som 
ovenfor specificeret) i formatet for sikker meddelelses­
overførsel, tilbagemeldes behandlingsstatus » 6987 «: 
Denne fejl opstår, hvis der mangler en forventet 
etiket, eller hvis kommandoen ikke er korrekt opbygget.  
— Hvis nogle dataobjekter er ukorrekte, tilbagemeldes 
status » 6988 «: Denne fejl optræder, når alle de nødven­
dige etiketter er til stede, men visse af længderne ikke 
svarer til de forventede.  
— Lykkes verifikationen af den kryptografiske kontrolsum 
ikke, tilbagemeldes behandlingsstatus » 6688 «. 
3.5.3.2 K o m m a n d o m e d k o r t i d f o r e l e m e n t æ  r f i l  
Denne kommandovariant giver kortlæseren mulighed for at vælge e n 
elementærfil ved hjælp af et kort id for elementærfilen og læse  data 
fra filen.  
TCS_61 Et takografkort skal understøtte denne kommandovariant 
for alle elementærfiler med et fastsat kort id for elementær­
filen. Disse korte id'er for elementærfiler er nærmere 
beskrevet i afsnit 4.  
TCS_62  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »D6h«  Update Binary  
P1 1  »XXh«  Bit 8 er sat til 1 
Bit 7 og 6 er sat til 00 
Bit 5-1 koder det korte id for den tilsvarende elemen­
tærfil  
P2 1  »XXh«  Koder en forskydning fra 0 til 255 bytes i den elemen­
tærfil, som P1 henviser til  
Lc 1  »NNh«  Længde af data, som skal opdateres. Antal bytes, som 
skal skrives  
#6-#(5+NN)  N N  »XX..XXh«  Data, som skal skrives  
TCS_63  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
Bemærk:  De korte id'er for elementærfiler, der anvendes til 
takografapplikationen af anden generation, beskrives 
nærmere i afsnit 4.  
Hvis P1 koder et kort id for en elementærfil, og komman­
doen giver resultat, bliver den identificerede elementærfil til  
den aktuelt valgte elementærfil (den aktuelle elementærfil).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 256  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Hvis filen svarende til det korte id for elementærfilen 
ikke findes, tilbagemeldes status » 6A82 «. 
— Er sikkerhedsbetingelserne for den valgte fil ikke 
opfyldt, afbrydes kommandoen med » 6982 «. 
— Er forskydningen ikke forenelig med elementærfilens 
størrelse (forskydning > størrelse af EF), tilbagemeldes 
status » 6B00 «. 
— Er størrelsen af de data, der skal skrives, ikke forenelig 
med elementærfilens størrelse (forskydning + Lc > stør­
relsen af EF), tilbagemeldes status » 6700 «. 
▼M1 
— Konstateres der en integritetsfejl i filattributterne, skal 
kortet anse filen for uoprettelig beskadiget, og der tilba­
gemeldes behandlingsstatus » 6400 « eller » 6500 «. 
▼B 
— Hvis der ikke kan skrives, tilbagemeldes behandlings­
status » 6581 «. 
3.5.3.3 K o m m a n d o m e d u l i g e o r d r e b y t e  
Denne kommandovariant giver kortlæseren mulighed for at skrive 
data til en elementærfil med 32 768 bytes eller derover.  
TCS_64 Takografkort, som understøtter elementærfiler med 32 768  
bytes eller derover, skal understøtte denne kommandova­
riant for disse elementærfiler. Et takografkort kan eventuelt 
understøtte denne kommandovariant for andre elementær­
filer.  
TCS_65  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »D7h«  Update Binary  
P1 1  »00h«  Aktuel elementærfil  
P2 1  »00h«  
Lc 1  »NNh«  Lc Længde af data i kommandodatafeltet  
#6-#(5+NN)  N N  »XX..XXh«  Forskydningsdataobjekt med etiket »54h« || Objekt med 
yderligere data med etiket »53h«, der indkapsler de data, 
som skal skrives  
Kortlæseren skal kode længden af forskydningsdataobjektet 
og længden af objektet med yderligere data med det mindst 
mulige antal oktetter. For eksempel skal kortlæseren ved 
brug af længdebyten »01h« kode en forskydning/længde 
fra 0 til 255, og ved brug af længdebyten »02h« skal den 
kode en forskydning/længde fra »256« op til »65 535« 
bytes.  
TCS_66  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 257  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Vælges ingen elementærfil, tilbagemeldes behandlings­
status » 6986 «. 
— Er sikkerhedsbetingelserne for den valgte fil ikke 
opfyldt, afbrydes kommandoen med » 6982 «. 
— Er forskydningen ikke forenelig med elementærfilens 
størrelse (forskydning > størrelse af EF), tilbagemeldes 
status » 6B00 «. 
— Er størrelsen af de data, der skal skrives, ikke forenelig 
med elementærfilens størrelse (forskydning + Lc > stør­
relsen af EF), tilbagemeldes status » 6700 «. 
— Konstateres der en integritetsfejl i filattributterne, skal 
kortet anse filen for uoprettelig beskadiget, og den 
tilbagemeldte behandlingsstatur er » 6400 « eller » 6500 «. 
— Hvis der ikke kan skrives, tilbagemeldes behandlings­
status » 6581 «. 
3.5.3.3.1 K o m m a n d o m e d s i k k e r m e d d e l e l s e  s o v e r f ø r s e l 
( e k s e m p l e r )  
Kommando med sikker meddelelsesoverførsel (eksempler)Følgende 
eksempel viser brug af sikker meddelelsesoverførsel, hvis sikke rheds­
betingelsen SM-MAC-G2 gælder.  
TCS_67 Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »0Ch«  Der er anmodet om sikker meddelelsesoverførsel  
INS 1  »D7h«  Update Binary  
P1 1  »00h«  Aktuel elementærfil  
P2 1  »00h«  
Lc 1  »XXh«  Længde af det sikrede datafelt  
#6 1  »B3h«  Etiket for data med ordinær værdi, der er kodet i 
BER-TLV  
#7 L  »NNh« eller 
»81 NNh«  L PV : længde af overførte data 
L er 2 bytes, hvis L  PV >127 bytes.  
#(7+L)- 
#(6+L+NN)  NN »XX..XXh«  Ordinære data kodet i BER-TLV, dvs. forskydningsdata­
objekt med etiket »54h« || Objekt med yderligere data 
med etiket »53h«, der indkapsler de data, som skal 
skrives  
#(7+L+NN)  1  »8Eh«  T  CC : Etiket for kryptografisk kontrolsum  
#(8+L+NN)  1  »XXh«  L  CC : Længde af efterfølgende kryptografiske kontrolsum 
»08h«, »0Ch« eller »10h« afhængigt af AES-nøgle­
længden for sikker meddelelsesoverførsel (anden genera­
tion) (se tillæg 11, del B)  
#(9+L+NN)- 
#(8+M+L+ 
NN) M »XX..XXh«  Kryptografisk kontrolsum  
Le 1  »00h«  Som foreskrevet i ISO/IEC 7816-4  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 258  
TCS_68 Svarmeddelelse, hvis kommandoen giver resultat  
Byte  Længde  Værdi  Beskrivelse  
#1 1  »99h«  T  SW : Etiket for statusord (skal beskyttes af CC)  
#2 1  »02h«  L  SW : længde af tilbagemeldte statusord  
#3-#4  2  »XXXXh«  Behandlingsstatus for det ubeskyttede APDU-svar  
#5 1  »8Eh«  T  CC : Etiket for kryptografisk kontrolsum  
#6 1  »XXh«  L  CC : Længde af efterfølgende kryptografiske kontrolsum 
»08h«, »0Ch« eller »10h« afhængigt af AES-nøgle­
længden for sikker meddelelsesoverførsel (anden genera­
tion) (se tillæg 11, del B)  
#7-#(6+L)  L  »XX..XXh«  Kryptografisk kontrolsum  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
3.5.4  GET CHALLENGE  
Denne kommando overholder ISO/IEC 7816-4, men har begrænset 
anvendelse i forhold til den i normen definerede kommando.  
Med GET CHALLENGE-kommandoen beder man kortet afgive en 
challenge for at bruge den i en sikkerhedsrelateret procedure, hvori 
der sendes et kryptogram eller nogle kryptograferede data til k ortet.  
TCS_69 Den challenge, som afgives af kortet, er kun gyldig for den 
næste kommando, som anvender en challenge, som sendes 
til kortet.  
TCS_70  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »84h«  INS  
P1 1  »00h«  P 1  
P2 1  »00h«  P 2  
Le 1  »08h«  Le (forventet længde af challenge).  
TCS_71  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
#1-#8  8  »XX..XXh«  Udfordring  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Hvis længden Le er forskellig fra »08h«, er behand­
lingsstatus » 6700 «. 
— Hvis parametrene P1-P2 er ukorrekte, er behandlings­
status » 6A86 «. ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 259  
3.5.5  VERIFY  
Denne kommando overholder ISO/IEC 7816-4, men har begrænset 
anvendelse i forhold til den i normen definerede kommando.  
Kun værkstedskortet kræves for at understøtte denne kommando.  
Andre slags takografkort kan muligvis udføre denne kommando, me n 
for disse kort personaliseres ingen reference-CHV. Derfor kan d isse 
kort ikke udføre denne kommando på tilfredsstillende vis. For s å vidt 
angår andre slags takografkort end værkstedskort ligger deres a dfærd 
(den returnerede fejlkode) uden for anvendelsesområdet for denn e 
specifikation, hvis denne kommando sendes.  
VERIFY-kommandoen får kortet til at sammenholde de 
CHV(PIN)data, som sendes med kommandoen, med kortindehaverens 
reference-CHV, som er gemt på kortet.  
▼M1 
TCS_72 Den PIN, der er indlæst af brugeren, skal af kortlæseren  
være ASCII-kodet og udfyldt mod højre med »FFh«-bytes 
til en længde af 8 bytes. Se også datatypen Workshop­
CardPIN i tillæg 1.  
▼B 
TCS_73 Takografapplikationer af første og anden generation skal  
bruge den samme reference-CHV.  
TCS_74 Takografkortet skal kontrollere, om kommandoen er kodet 
korrekt. Hvis kommandoen ikke er kodet korrekt, skal 
kortet ikke sammenligne CHV-værdierne, ikke nedbringe 
tælleren for resterende CHV-forsøg og ikke nulstille sikker­
hedsstatussen »PIN_Verified«, men derimod afbryde 
kommandoen. En kommando er kodet korrekt, hvis 
bytene CLA, INS, P1, P2 og Lc har de fastsatte værdier, 
Le ikke findes, og kommandoens datafelt har den korrekte 
længde.  
TCS_75 Hvis kommandoen giver resultat, tilbagestilles tælleren for 
resterende CHV-forsøg. Tælleren for resterende CHV- 
forsøg starter på værdien 5. Hvis kommandoen giver 
resultat, skal kortet sætte den interne sikkerhedsstatus til 
»PIN_Verified«. Kortet skal nulstille denne sikkerheds­
status, hvis kortet selv nulstilles, eller hvis den 
CHV-kode, der overføres i kommandoen, ikke matcher 
den lagrede reference-CHV.  
Bemærk:  Ved at bruge den samme reference-CHV og en 
overordnet sikkerhedsstatus slipper værkstedsmedarbej­
derne for at skulle genindlæse PIN-koden efter at have 
valgt en anden dedikeret fil for takografapplikationen.  
TCS_76 Manglende overensstemmelse mellem oplysninger regi­
streres på kortet, dvs. tælleren for resterende CHV-forsøg 
nedbringes med én, for at begrænse antal yderligere forsøg 
på benyttelse af reference-CHV.  
TCS_77  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »20h«  INS  
P1 1  »00h«  P 1  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 260  
Byte  Længde  Værdi  Beskrivelse  
P2 1  »00h«  P2 (det verificerede CHV kendes implicit)  
Lc 1  »08h«  Længden af den overførte CHV-kode  
#6-#13  8  »XX..XXh«  CHV  
TCS_78  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Hvis reference-CHV'et ikke findes, tilbagemeldes status 
»6A88 «. 
— Hvis CHV'er er blokeret (tælleren for resterende forsøg 
for det pågældende CHV har værdien nul), tilbage­
meldes behandlingsstatus » 6983 «. Når først CHV'et er 
i denne status, kan det pågældende CHV ikke længere 
fremvises med held.  
— Stemmer oplysningerne ikke overens, bliver tælleren for 
resterende forsøg formindsket, og status » 63CX « tilba­
gemeldes (X > 0 og X er lig værdien af tælleren for 
resterende CHV-forsøg).  
— Hvis reference-CHV anses for beskadiget, tilbage­
meldes status » 6400 « eller » 6581 «. 
— Hvis længden Lc er forskellig fra »08h«, er behand­
lingsstatus » 6700 «. 
3.5.6  GET RESPONSE  
Denne kommando er i overensstemmelse med ISO/IEC 7816-4.  
Denne kommando (som kun er nødvendig og tilgængelig for proto­
kollen T = 0) benyttes til at overføre behandlede data fra kort et til 
kortlæseren (i tilfælde, hvor både Lc og Le er indgået i en 
kommando).  
Kommandoen GET RESPONSE skal udstedes straks efter den 
kommando, som behandler data, ellers mistes data. Efter udførel se 
af kommandoen GET RESPONSE er de tidligere behandlede data 
ikke længere tilgængelige (medmindre fejlen »61xx« eller »6Cxx«  
optræder, se nedenfor).  
TCS_79  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »C0h«  
P1 1  »00h«  
P2 1  »00h«  
Le 1  »XXh«  Antal bytes forventet  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 261  
TCS_80  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
#1-#X  X  »XX..XXh«  Data  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Hvis ingen data er behandlet af kortet, tilbagemeldes 
status » 6900 « eller » 6F00 «. 
— Hvis længden (Le) overstiger antal bytes til rådighed, 
eller hvis Le er nul, tilbagemeldes status » 6Cxx «, hvor 
»xx« er det nøjagtige antal bytes til rådighed. I dette 
tilfælde er de behandlede data stadig til rådighed for en 
efterfølgende GET RESPONSE-kommando.  
— Hvis Le ikke er nul og er mindre end antal bytes til 
rådighed, bliver de ønskede data sendt på normal måde 
af kortet, og der tilbagemeldes status » 61xx «, hvor 
»xx« er antal bytes, som stadig er til rådighed ved en 
efterfølgende GET RESPONSE-kommando.  
— Hvis kommandoen ikke understøttes (protokol T = 1), 
tilbagemelder kortet » 6D00 «. 
3.5.7  PSO: VERIFY CERTIFICATE  
Denne kommando overholder ISO/IEC 7816-8, men har begrænset 
anvendelse i forhold til den i normen definerede kommando.  
VERIFY CERTIFICATE-kommandoen anvendes af kortet til at hente 
en offentlig nøgle udefra og kontrollere dens gyldighed.  
3.5.7.1 K o m m a n d o - s v a r - p a r ( f ø r s t e g e n e  r a t i o n )  
TCS_81 Denne kommandovariant understøttes kun af en takografap­
plikation af første generation.  
TCS_82 Når en VERIFY CERTIFICATE-kommando giver resultat, 
bliver den offentlige nøgle gemt til fremtidig anvendelse i 
sikkerhedsmiljøet. Denne nøgle skal udtrykkelig være 
angivet til brug i sikkerhedsrelaterede kommandoer 
(INTERNAL AUTHENTICATE, EXTERNAL AUTHEN­
TICATE eller VERIFY CERTIFICATE) af MSE-komman­
doen (se punkt 3.5.11) med anvendelse af nøgleidentifika­
toren.  
TCS_83 I alle tilfælde anvender kommandoen VERIFY CERTIFI­
CATE den offentlige nøgle, som tidligere er valgt af 
MSE-kommandoen til at åbne certifikatet. Denne offentlige 
nøgle skal tilhøre en medlemsstat eller EU.  
TCS_84  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »2Ah«  Udfør sikkerhedsoperation  
P1 1  »00h«  P 1  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 262  
Byte  Længde  Værdi  Beskrivelse  
P2 1  »AEh«  P2: Ikke BER-TLV-kodede data (sammenkædning af 
dataelementer)  
Lc 1  »C2h«  Lc: Certifikatets længde, 194 bytes  
#6-#199  194  »XX..XXh«  Certifikat: Sammenkædning af dataelementer (som 
beskrevet i tillæg 11)  
TCS_85  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Lykkes certifikatverificeringen ikke, tilbagemeldes 
behandlingsstatus » 6688 «. Verifikation og udpakning 
af certifikatet er beskrevet i tillæg 11 for både første 
og anden generation.  
— Findes der ingen offentlig nøgle i sikkerhedsmiljøet, 
tilbagemeldes » 6A88 «. 
— Hvis den valgte offentlige nøgle (som benyttes til 
udpakning af certifikatet) anses for beskadiget, tilbage­
meldes status » 6400 « eller » 6581 «. 
— Kun første generation: Hvis den valgte offentlige nøgle (som 
anvendes til at udpakke certifikatet) har en anden CHA.LSB 
(
 )  
end »00« (dvs. ikke tilhører en EU-medlemsstat), tilbage­
meldes status » 6985 «. 
3.5.7.2 K o m m a n d o - s v a r - p a r ( a n d e n g e n e r  a t i o n )  
Afhængigt af kurvestørrelsen kan ECC-certifikater være så lange , at 
de ikke kan sendes i en enkelt APDU. I så fald skal der anvende s 
kommandokædning i overensstemmelse med ISO/IEC 7816-4, og 
certifikatet skal sendes i to på hinanden følgende APDU'er af t ypen 
PSO: Verify Certificate.  
Certifikaters opbygning og domæneparametre er fastlagt i tillæg  11. 
▼M3 
TCS_86 Kommandoen kan udføres i hovedfilen, den dedikerede fil 
Tachograph og den dedikerede fil Tachograph_G2. Se også 
TCS_34.  
▼B 
TCS_87  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »X0h«  CLA-byte, der indikerer kommandokædning: 
»00h« — den eneste eller sidste kommando i kæden 
»10h« — ikke den sidste kommando i kæden  
INS 1  »2Ah«  Udfør sikkerhedsoperation  
P1 1  »00h«  
P2 1  »BEh«  Verificer selvdeskriptivt certifikat  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 263  
Byte  Længde  Værdi  Beskrivelse  
Lc 1  »XXh«  Længde af kommandoens datafelt, se TCS_88 og 
TCS_89.  
#6-#5+L  L  »XX..XXh«  DER-TLV-kodede data: dataobjekt af typen »ECC Certi­
ficate Body« som første dataobjekt sammenkædet med 
dataobjektet »ECC Certificate Signature« som andet 
dataobjekt eller en del af denne sammenkædning. 
Etiketten »7F21« og den tilsvarende længde skal ikke 
overføres. 
Disse dataobjekters rækkefølge ligger fast.  
▼M3 
TCS_88 For APDU'er med kort længde gælder følgende bestem­
melser: kortlæseren skal bruge det mindste antal APDU'er, 
der er nødvendige for at overføre kommandoens indhold, 
og overføre det størst mulige antal bytes i den første 
kommando-APDU. En »Lc«-værdi på op til 255 byte 
skal dog understøttes af kortet.  
TCS_89 For APDU'er med udvidet længde gælder følgende bestem­
melser: Hvis certifikatet ikke kan være i en enkelt APDU, 
skal kortet understøtte kommandokædning. Kortlæseren 
skal bruge det mindste antal APDU'er, der er nødvendige 
for at overføre kommandoens indhold, og overføre det 
størst mulige antal bytes i den første kommando-APDU. 
Hvis kædning er nødvendig, skal en »Lc«-værdi på op til 
den angivne maksimale længde understøttes af kortet.  
Bemærk: Som anført i tillæg 11 lagrer kortet certifikatet 
eller det relevante indhold i det, hvorefter det opdaterer 
parameteren currentAuthenticatedTime.  
Svarmeddelelsesstrukturen og statusordene er fastlagt i 
TCS_85.  
▼B 
TCS_90 Ud over de fejlkoder, der er opført i TCS_85, kan kortet  
tilbagemelde følgende fejlkoder:  
— Hvis den valgte offentlige nøgle (som anvendes til at 
udpakke certifikatet) har en CHA.LSB (CertificateHol­
derAuthorisation.equipmentType), som ikke egner sig 
til certifikatverificering i overensstemmelse med tillæg 
11, tilbagemeldes status » 6985 «. 
— Hvis kortets currentAuthenticatedTime ligger senere 
end Certificate Expiration Date, tilbagemeldes behand­
lingsstatus » 6985 «. 
— Hvis den sidste kommando i kæden er som forventet, 
tilbagemelder kortet » 6883 «. 
— Hvis der sendes ukorrekte parametre i kommandoens 
datafelt, tilbagemelder kortet » 6A80 « (bruges også, 
hvis dataobjekterne ikke sendes i den foreskrevne 
rækkefølge).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 264  
3.5.8  INTERNAL AUTHENTICATE  
Denne kommando er i overensstemmelse med ISO/IEC 7816-4.  
TCS_91 Alle takografkort skal understøtte denne kommando i førs te 
generation af DF Tachograph. Kommandoen kan eventuelt 
være tilgængelig i hovedfilen og/eller DF Tachograph_G2. 
I så fald skal kommandoen afsluttes med en passende fejl­
kode, da kortets (Card.SK) private nøgle til ægthedsbekræf­
telsesprotokollen (første generation) kun er tilgængelig i 
første generation af DF Tachograph.  
Med kommandoen INTERNAL AUTHENTICATE kan 
kortlæseren bekræfte kortets ægthed. Identitetsbekræftelsen 
er beskrevet i tillæg 11. Den indeholder følgende 
sætninger:  
TCS_92 Kommandoen INTERNAL AUTHENTICATE anvender 
kortets private nøgle (som er valgt implicit) til signering 
af ægthedsdata, som indeholder K1 (første element i 
session nøgleoverensstemmelse) og RND1, og anvender 
den offentlige nøgle, der aktuelt er valgt (ved den seneste 
MSE-kommando), til at kryptere underskriften og udforme 
ægthedsbekræftelsestoken (nærmere detaljer i tillæg 11).  
TCS_93  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  CLA  
INS 1  »88h«  INS  
P1 1  »00h«  P 1  
P2 1  »00h«  P 2  
Lc 1  »10h«  Længde af data sendt til kortet  
#6-#13  8  »XX..XXh«  Challenge anvendt til bekræftelse af kortets identitet  
#14-#21  8  »XX..XXh«  VU.CHR (se tillæg 11)  
Le 1  »80h«  Forventet længde af data fra kortet  
TCS_94  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
#1-#128  128  »XX..XXh«  Token for identifikation af kort (se tillæg 11)  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Findes ingen offentlig nøgle i sikkerhedsmiljøet, tilba­
gemeldes status » 6A88 «. 
— Findes ingen privat nøgle i sikkerhedsmiljøet, tilbage­
meldes status » 6A88 «. 
— Hvis VU.CHR ikke svarer til navnet for den aktuelle 
offentlige nøgle, tilbagemeldes status » 6A88 «. ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 265  
— Hvis den valgte private nøgle anses for beskadiget, 
tilbagemeldes status » 6400 « eller » 6581 «. 
▼M1 
TCS_95 Hvis INTERNAL AUTHENTICATE-kommandoen giver 
resultat, slettes den eventuelle aktuelle nøgle af første gene­
ration for sessionen, og er ikke længere til rådighed. For at 
man kan få adgang til en ny sessionsnøgle for første gene­
ration, skal kommandoen EXTERNAL AUTHENTICATE 
for mekanismen til ægthedsbekræftelse for første generation 
gennemføres med resultat.  
Bemærk:  For sessionsnøgler af anden generation henvises 
til tillæg 11, krav CSM_193 og CSM_195. Hvis der 
oprettes sessionsnøgler for anden generation, og takograf­
kortet modtager den ordinære INTERNAL AUTHEN­
TICATE-kommando APDU, afbryder det den sikre medde­
lelsesoverførsel for anden generation og destruerer sessions­
nøglerne for anden generation.  
▼B 
3.5.9  EXTERNAL AUTHENTICATE  
Denne kommando er i overensstemmelse med ISO/IEC 7816-4.  
Med kommandoen EXTERNAL AUTHENTICATE kan kortet 
bekræfte identiteten af kortlæseren. Ægthedsbekræftelsen er bes krevet 
i tillæg 11 for takografer af første og anden generation (ægthe ds­
bekræftelse for køretøjsenhed).  
TCS_96 Kommandovarianten for mekanismen til gensidig ægtheds­
bekræftelse af første generation understøttes kun af tako­
grafapplikationer af første generation.  
▼M1 
TCS_97 Kommandovarianten for gensidig ægthedsbekræftelse for 
anden generation på køretøjsenhedens kort kan udføres i 
hovedfilen, DF Tachograph og DF Tachograph_G2. Se 
også TCS_34. Hvis INTERNAL AUTHENTICATE- 
kommandoen for anden generation giver resultat, slettes 
den eventuelle aktuelle nøgle af første generation for 
sessionen, og er ikke længere til rådighed.  
Bemærk:  For sessionsnøgler af anden generation henvises 
til tillæg 11, krav CSM_193 og CSM_195. Hvis der 
oprettes sessionsnøgler for anden generation, og takograf­
kortet modtager den ordinære EXTERNAL AUTHEN­
TICATE-kommando APDU, afbryder det den sikre medde­
lelsesoverførsel for anden generation og destruerer sessions­
nøglerne for anden generation.  
▼B 
TCS_98  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  CLA  
INS 1  »82h«  INS  
P1 1  »00h«  Nøgler og algoritmer kendes implicit  
P2 1  »00h«  
Lc 1  »XXh«  Lc (længde af data sendt til kortet)  
#6-#(5+L)  L  »XX..XXh«  Ægthedsbekræftelse for første generation: Kryptogram 
(se tillæg 11, del A) 
Ægthedsbekræftelse for anden generation: Underskrift 
genereret af kortlæseren (se tillæg 11, del B)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 266  
TCS_99  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Hvis CHA for den aktuelt fastsatte offentlige nøgle ikke 
er en sammenføjning af takografapplikationens navn 
(AID) og en type køretøjsenhed, tilbagemeldes status 
»6F00 «. 
— Hvis denne kommando ikke følger umiddelbart efter en 
GET CHALLENGE-kommando, tilbagemeldes status 
»6985 «. 
Takografapplikationen af første generation kan derudover 
tilbagemelde følgende fejlkoder:  
— Findes der ingen offentlig nøgle i sikkerhedsmiljøet, 
tilbagemeldes » 6A88 «. 
— Findes ingen privat nøgle i sikkerhedsmiljøet, tilbage­
meldes status » 6A88 «. 
— Lykkes verifikationen af den kryptografiske kontrolsum 
ikke, tilbagemeldes behandlingsstatus » 6688 «. 
— Hvis den valgte private nøgle anses for beskadiget, 
tilbagemeldes status » 6400 « eller » 6581 «. 
Kommandovarianten for ægthedsbekræftelse for anden 
generation kan desuden tilbagemelde følgende fejlkode:  
— Lykkes verifikationen af underskriften ikke, tilbage­
melder kortet » 6300 «. 
3.5.10  GENERAL AUTHENTICATE  
Denne kommando bruges til den protokol til ægthedsbekræftelse a f 
chip af anden generation, der er angivet i tillæg 11, del B, og  som er i 
overensstemmelse med ISO/IEC 7816-4.  
TCS_100 Kommandoen kan udføres i hovedfilen, DF Tachograph og 
DF Tachograph_G2. Se også TCS_34.  
TCS_101  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »86h«  
P1 1  »00h«  Nøgler og protokol kendes implicit  
P2 1  »00h«  
Lc 1  »NNh«  Lc: længde af efterfølgende datafelt  
#6-#(5+L)  L  »7Ch« + L  7C + 
»80h« + L  80 + 
»XX..XXh«  DER-TLV-kodet kortvarig værdi for offentlig nøgle 
(se tillæg 11) 
Køretøjsenheden skal sende dataobjekterne i denne 
rækkefølge.  
▼M3 
Le 1  »00h«  Som foreskrevet i ISO/IEC 7816-4  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 267  
TCS_102  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
#1-#L  L  »7Ch« + L  7C + 
»81h« + »08h« + 
»XX..XXh« + »82h« 
+ L  82 + »XX..XXh«  DER-TLV-kodede dynamiske ægthedsbekræf­
telsesdata: nonce og ægthedsbekræftelsestoken 
(se tillæg 11)  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Kortet tilbagemelder » 6A80 « for at indikere ukorrekte 
parametre i datafelt.  
— Kortet tilbagemelder » 6982 «, hvis kommandoen 
External Authenticate ikke er udført med resultat  
Svarobjektet for dynamisk ægthedsbekræftelse »7Ch«  
— skal findes, hvis operationen giver resultat, dvs. statu­
sordet er » 9000 « 
— må ikke findes i tilfælde af en kørselsfejl eller kontrol­
fejl, dvs. hvis statusordene er inden for området  
»6400«-»6FFF«  
— findes muligvis ikke i tilfælde af en advarsel, dvs. hvis 
statusordene er inden for området  »6200«-»63FF« . 
3.5.11  MANAGE SECURITY ENVIRONMENT  
Med denne kommando fastsættes en offentlig nøgle til brug for 
ægthedsbekræftelse.  
3.5.11.1 K o m m a n d o - s v a r - p a r ( f ø r s t e g e n e r a t i o n )  
Denne kommando er i overensstemmelse med ISO/IEC 7816-4. 
Brugen af denne kommando er begrænset med hensyn til den tilkny t­
tede standard.  
TCS_103 Denne kommando understøttes kun af en takografapplika­
tion af første generation.  
TCS_104 Den nøgle, der henvises til i MSE-datafeltet, er den ak tuelle 
offentlige nøgle indtil næste korrekte MSE-kommando, 
indtil en dedikeret fil vælges, eller indtil kortet nulstilles.  
TCS_105 Hvis den nøgle, der henvises til, ikke (allerede) er ti l stede 
på kortet, sker der ingen ændring i sikkerhedsmiljøet.  
TCS_106  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  CLA  
INS 1  »22h«  INS  
P1 1  »C1h«  P1: Den nøgle, der henvises til, er gyldig for alle krypto­
grafiske operationer  
P2 1  »B6h«  P2 (data, som der er henvist til vedrørende digital under­
skrift)  
Lc 1  »0Ah«  Lc: længde af efterfølgende datafelt  
#6 1  »83h«  Etiket bestemt til henvisning til en offentlig nøgle i 
asymmetriske tilfælde  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 268  
Byte  Længde  Værdi  Beskrivelse  
#7 1  »08h«  Længde af nøglehenvisning (nøgleidentifikator)  
#8-#15  8  »XX..XXh«  Nøgleidentifikator som foreskrevet i tillæg 11  
TCS_107  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Hvis den nøgle, der henvises til, ikke er til stede på 
kortet, tilbagemeldes behandlingsstatus » 6A88 «. 
— Hvis visse forventede dataobjekter ikke findes i sikkert 
meddelelsesformat, tilbagemeldes status » 6987 «. Dette 
kan være tilfældet, hvis etiketten »83h« mangler.  
— Hvis nogle dataobjekter er ukorrekte, tilbagemeldes 
status » 6988 «. Dette kan ske, hvis længden af nøglei­
dentifikatoren ikke er »08h.«  
— Hvis den valgte nøgle anses for beskadiget, tilbage­
meldes status » 6400 « eller » 6581 «. 
3.5.11.2 K o m m a n d o - s v a r - p a r ( a n d e n g e n e r a t i o n )  
Ved ægthedsbekræftelse af anden generation understøtter takogra f­
kortet følgende kommandoversioner af typen MSE: Set, som er i 
overensstemmelse med ISO/IEC 7816-4. Disse kommandoversioner 
understøttes ikke for ægthedsbekræftelse af første generation.  
3.5.11.2.1 M S E : S E T A T t i l æ g t h e d s b e k r æ f t e l s e a f c h i p  
Følgende MSE:SET AT-kommando bruges til at vælge parametrene 
for den ægthedsbekræftelse af chip, som udføres af en efterfølg ende 
General Authenticate-kommando.  
TCS_108 Kommandoen kan udføres i hovedfilen, DF Tachograph og 
DF Tachograph_G2. Se også TCS_34.  
TCS_109  MSE:SET AT-kommandomeddelelse til ægthedsbekræf ­
telse af chip  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »22h«  
P1 1  »41h«  Angives for intern ægthedsbekræftelse  
P2 1  »A4h«  Ægthedsbekræftelse  
Lc 1  »NNh«  Lc: længde af efterfølgende datafelt  
#6-#(5+L)  L  »80h« + 
»0Ah« + 
»XX..XXh«  DER-TLV-kodet henvisning til kryptografisk meka­
nisme: Objektidentifikator for ægthedsbekræftelse af 
chip (kun værdi, Etiket »06h« udelades). 
Objektidentifikatorernes værdier fremgår af tillæg 1. 
Byte-notation skal anvendes. I tillæg 11 findes en vejled­
ning i udvælgelse af en af disse objektidentifikatorer.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 269  
3.5.11.2.2 M S E : S E T A T t i l æ g t h e d s b e k r æ f t e l s e a f k ø r e t ø j s ­
e n h e d  
Følgende MSE:SET AT-kommando bruges til at vælge parametrene 
og nøglerne for den ægthedsbekræftelse af køretøjsenheden, som 
udføres af en efterfølgende External Authenticate-kommando.  
TCS_110 Kommandoen kan udføres i hovedfilen, DF Tachograph og 
DF Tachograph_G2. Se også TCS_34.  
TCS_111  MSE:SET AT-kommandomeddelelse til ægthedsbekræf ­
telse af køretøjsenhed  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »22h«  
P1 1  »81h«  Angives for ekstern ægthedsbekræftelse  
P2 1  »A4h«  Ægthedsbekræftelse  
Lc 1  »NNh«  Lc: længde af efterfølgende datafelt  
#6-#(5+L)  L  »80h« + 
»0Ah« + 
»XX..XXh«  DER-TLV-kodet henvisning til kryptografisk meka­
nisme: Objektidentifikator for ægthedsbekræftelse af 
køretøjsenhed (kun værdi, Etiket »06h« udelades). 
Objektidentifikatorernes værdier fremgår af tillæg 1. 
Byte-notation skal anvendes. I tillæg 11 findes en vejled­
ning i udvælgelse af en af disse objektidentifikatorer.  
»83h« + »08h« 
+ »XX..XXh«  DER-TLV-kodet henvisning af køretøjsenhedens offent­
lige nøgle foretaget af den henvisning til certifikatinde­
haveren, der er nævnt i nøglens certifikat.  
»91h« + L  91 + 
»XX..XXh«  DER-TLV-kodet komprimeret gengivelse af den kortva­
rige offentlige nøgle for køretøjsenheden, som vil blive 
anvendt under ægthedsbekræftelse af chip (se tillæg 11)  
3.5.11.2.3 M S E : S E T D S T  
Følgende MSE:SET DST-kommando bruges til at fastsætte en 
offentlig nøgle for enten  
— verifikation af en underskrift, som leveres i en efterfølgend e PSO: 
Verify Digital Signature-kommando eller  
— underskriftsverifikation af et certifikat, som leveres i en e fterføl­
gende PSO: Verify Certificate-kommando  
TCS_112 Kommandoen kan udføres i hovedfilen, DF Tachograph og 
DF Tachograph_G2. Se også TCS_33.  
TCS_113  MSE SET DST-kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  
INS 1  »22h«  
P1 1  »81h«  Angives for verifikation  
P2 1  »B6h«  Digital underskrift  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 270  
Byte  Længde  Værdi  Beskrivelse  
Lc 1  »NNh«  Lc: længde af efterfølgende datafelt  
#6-#(5+L)  L  »83h« + »08h« 
+ »XX..XXh«  DER-TLV-kodet henvisning af en offentlig nøgle, dvs. 
henvisningen til certifikatindehaveren i den offentlige 
nøgles certifikat (se tillæg 11)  
For alle kommandoversioner er svarmeddelelsesstrukturen og stat us­
ordene givet ved:  
TCS_114  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. Protokollen er valgt og initialiseret.  
— » 6A80 « indikerer ukorrekte parametre i kommandoens 
datafelt.  
— » 6A88 « indikerer, at adresserede data (dvs. en nøgle, 
der henvises til) ikke er tilgængelig.  
▼M1 
— Hvis kortets currentAuthenticatedTime ligger senere 
end udløbsdatoen for den valgte offentlige nøgle, tilba­
gemeldes behandlingsstatus  »6A88« . 
Bemærk:  For kommandoen MSE: SET AT til ægtheds­
bekræftelse af køretøjsenheden er den nøgle, der henvises 
til, en offentlig VU_MA-nøgle. Kortet indstiller den offent­
lige VU_MA-nøgle, der skal anvendes, hvis den findes i 
hukommelsen, og som modsvarer den henvisning til certi­
fikatindehaveren (Certificate Holder Reference - CHR), der 
er givet i kommandoens datafelt (kortet kan identificere 
offentlige VU_MA-nøgler ved hjælp af certifikatets 
CHA-felt). Kortet skal tilbagemelde »6A 88« på denne 
kommando, hvis kun den offentlige VU_Sign-nøgle eller 
ingen offentlig nøgle for køretøjsenheden er til rådighed. 
Se definitionen af CHA-feltet i tillæg 11 og af datatypen 
Equipment Type i tillæg 1.  
Ligeledes hvis en MSE: SET DST-kommando, som 
henviser til et EQT (dvs. en køretøjsenhed eller et kort), 
sendes til et kontrolkort, jf. krav CSM_234, er den nøgle, 
der henvises til, altid en EQT_Sign-nøgle, som skal 
anvendes til verifikation af en digital underskrift. Ifølge 
Figur 13 i tillæg 11 vil kontrolkortet altid have lagret den 
relevante offentlige EQT_Sign-nøgle. I visse tilfælde kan 
kontrolkortet have lagret den modsvarende offentlige 
EQT_MA-nøgle. Kontrolkortet skal altid indstille den 
offentlige EQT_Sign-nøgle til anvendelse, når det modtager 
en MSE: SET DST-kommando.  
▼B 
3.5.12  PSO: HASH  
Denne kommando anvendes til at overføre værdien af en hashbereg ­
ning på visse data til kortet. Kommandoen bruges til verifikati on af 
digitale underskrifter. Hashværdien lagres midlertidigt til den  efter­
følgende kommando PSO: Verify Digital Signature  
Denne kommando er i overensstemmelse med ISO/IEC 7816-8. 
Brugen af denne kommando er begrænset med hensyn til den tilkny t­
tede standard.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 271  
Kun kontrolkortet kræves for at understøtte denne kommando i DF  
Tachograph og DF Tachograph_G2.  
Andre slags takografkort kan eventuelt udføre denne kommando. 
Kommandoen kan eventuelt være tilgængelig i hovedfilen.  
Kontrolkortapplikationen af første generation understøtter kun SHA-1.  
TCS_115 Den midlertidigt gemte hashværdi skal slettes, hvis en ny 
hashværdi beregnes ved hjælp af kommandoen PSO: 
HASH, hvis en dedikeret fil vælges, og hvis takografkortet 
nulstilles.  
TCS_116  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  CLA  
INS 1  »2Ah«  Udfør sikkerhedsoperation  
P1 1  »90h«  Tilbagemeld hashkode  
P2 1  »A0h«  Etiket: Datafeltet indeholder dataobjekter, som er rele­
vante for hashing  
Lc 1  »XXh«  Længde Lc af det efterfølgende datafelt  
#6 1  »90h«  Etiket til hashkode  
#7 1  »XXh«  Længde L af hashkoden: 
»14h« i applikation af første generation (se tillæg 11, del 
A) 
»20h«, »30h« eller »40h« i applikation af anden genera­
tion (se tillæg 11, del B)  
#8-#(7+L)  L  »XX..XXh«  Hashkode  
TCS_117  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Hvis nogle af de forventede dataobjekter (som angivet 
ovenfor) mangler, tilbagemeldes status » 6987 «. Dette 
kan ske, hvis en af etiketterne »90h« mangler.  
— Hvis nogle dataobjekter er ukorrekte, tilbagemeldes 
status » 6988 «. Denne fejl opstår, hvis den ønskede 
etiket er til stede, men har en anden længde end 
»14h« for SHA-1, »20h« for SHA-256, »30h« for 
SHA-384 eller »40h« for SHA-512 (applikation af 
anden generation).  
3.5.13  PERFORM HASH of FILE  
Denne kommando er ikke i overensstemmelse med ISO/IEC 7816-8. 
Klassebyten (CLA) i denne kommando angiver således, at der er e n 
ophavsretligt beskyttet anvendelse af PERFORM SECURITY 
OPERATION/HASH.  
Kun førerkortet og værkstedskortet kræves for at understøtte de nne 
kommando i DF Tachograph og DF Tachograph_G2.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 272  
Andre slags takografkort kan eventuelt udføre denne kommando. H vis 
et virksomhedskort eller kontrolkort udfører denne kommando, sk al 
kommandoen udføres som foreskrevet i dette afsnit.  
Kommandoen kan eventuelt være tilgængelig i hovedfilen. I så fa ld 
skal kommandoen udføres som foreskrevet i dette afsnit. Den må ikke 
muliggøre beregning af en hashværdi, men skal afsluttes med en 
passende fejlkode.  
TCS_118 Kommandoen PERFORM HASH OF FILE anvendes til 
hashing af dataområdet i den aktuelt valgte transparente 
elementærfil.  
TCS_119 Takografkort skal kun understøtte denne kommando for de  
elementærfiler, der er anført i afsnit 4 under DF_Tacho­
graph og DF_Tachograph_G2 med følgende undtagelse. 
Takografkort må ikke understøtte kommandoen for elemen­
tærfilen Sensor_Installation_Data i DF Tachograph_G2.  
TCS_120 Resultatet af hashoperationen gemmes midlertidigt på 
kortet. Derefter kan det benyttes til at sætte en digital 
underskrift på filen ved hjælp af kommandoen PSO: 
COMPUTE DIGITAL SIGNATURE.  
▼M1 
TCS_121 Den midlertidigt gemte Hash of File-værdi skal slettes,  hvis 
en ny Hash of File-værdi beregnes ved hjælp af komman­
doen PERFORM HASH of FILE, hvis en dedikeret fil 
vælges, og hvis takografkortet nulstilles.  
▼B 
TCS_122 Takografapplikationer af første generation skal underst øtte 
SHA-1.  
▼M1 
TCS_123 Takografapplikationer af anden generation skal understø tte 
SHA-2-algoritmen (dvs. SHA-256, SHA-384 eller 
SHA-512) angivet ved krypteringsprogrammerne i tillæg 
11, del B for kortets underskriftsnøgle Card_Sign.  
▼B 
TCS_124  Kommandomeddelelse  
▼M1 
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »80h«  CLA  
INS 1  »2Ah«  Udfør sikkerhedsoperation  
P1 1  »90h«  Etiket: Hash  
P2 1  »00h«  Algoritmen kendes implicit 
For takografapplikationer af første generation: SHA-1 
For takografapplikationer af anden generation: SHA-2- 
algoritmen (SHA-256, SHA-384 eller SHA-512), 
angivet ved krypteringsprogrammerne i tillæg 11, del B 
for kortets underskriftsnøgle Card_Sign.  
▼B 
TCS_125  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Hvis den aktuelt valgte elementærfil ikke tillader denne 
kommando (elementærfilen Sensor_Installation_Data i 
DF Tachograph_G2), tilbagemeldes status » 6985 «. ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 273  
— Anses den valgte elementærfil for beskadiget, tilbage­
meldes status » 6400 « eller » 6581 «. 
— Er den valgte fil ikke en transparent fil, eller findes der 
ingen aktuelt valgt elementærfil, tilbagemeldes status 
»6986 «. 
3.5.14  PSO: COMPUTE DIGITAL SIGNATURE  
▼M1 
Denne kommando anvendes til at beregne den digitale underskrift  af 
en tidligere beregnet hashkode (se PERFORM HASH OF FILE, afsnit  
3.5.13).  
Kun førerkortet og værkstedskortet kræves for at understøtte de nne 
kommando i DF Tachograph og DF Tachograph_G2.  
Andre slags takografkort kan eventuelt udføre denne kommando. V ed 
takografapplikationer af anden generation er det kun førerkorte t og 
værkstedskortet, som har en underskriftsnøgle af anden generati on, 
andre kort kan ikke udføre kommandoen med resultat, men skal 
afsluttes med en passende fejlkode.  
Kommandoen kan eventuelt være tilgængelig i hovedfilen. Hvis 
kommandoen ikke er tilgængelig i hovedfilen, skal den afsluttes  
med en passende fejlkode.  
Denne kommando er i overensstemmelse med ISO/IEC 7816-8. 
Brugen af denne kommando er begrænset med hensyn til den tilkny t­
tede standard.  
▼B 
TCS_126 Denne kommando må ikke beregne en digital underskrift 
for en tidligere beregnet hashkode med kommandoen PSO: 
HASH.  
TCS_127 Kortets private nøgle anvendes til at beregne den digit ale 
underskrift og kendes implicit af kortet.  
TCS_128 Takografapplikationen af første generation udfører en 
digital underskrift med en udfyldningsmetode, som er i 
overensstemmelse med PKCS1 (se tillæg 11 for nærmere 
detaljer).  
TCS_129 Takografapplikationen af anden generation beregner en 
digital underskrift, der baseret på en elliptisk kurve (se 
tillæg 11 for detaljer).  
TCS_130  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  CLA  
INS 1  »2Ah«  Udfør sikkerhedsoperation  
P1 1  »9Eh«  Digital underskrift, som skal tilbagemeldes  
P2 1  »9Ah«  Etiket: Datafeltet indeholder data, som skal underskrives. 
Da der ikke indgår noget datafelt, formodes data allerede 
at være til stede i kortet (hash af filen)  
Le 1  »NNh«  Længde af den forventede underskrift  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 274  
TCS_131  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
#1-#L  L  »XX..XXh«  Underskrift af den tidligere beregnede hash  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Hvis den implicit valgte private nøgle anses for beska­
diget, tilbagemeldes status » 6400 « eller » 6581 «. 
— Hvis den hashværdi, der blev beregnet ved en tidligere 
PERFORM HASH of FILE-kommando, ikke er tilgæn­
gelig, tilbagemeldes status » 6985 «. 
3.5.15  PSO: VERIFY DIGITAL SIGNATURE  
Denne kommando anvendes til at verificere den digitale underskr ift, 
der tilføres som inddata for en meddelelse, for hvilken hash ke ndes af 
kortet. Underskriftsalgoritmen kendes implicit af kortet.  
Denne kommando er i overensstemmelse med ISO/IEC 7816-8. 
Brugen af denne kommando er begrænset med hensyn til den tilkny t­
tede standard.  
Kun kontrolkortet kræves for at understøtte denne kommando i DF  
Tachograph og DF Tachograph_G2.  
Andre slags takografkort kan eventuelt udføre denne kommando. 
Kommandoen kan eventuelt være tilgængelig i hovedfilen.  
TCS_132 Kommandoen VERIFY DIGITAL SIGNATURE bruger 
altid den offentlige nøgle, der er valgt af den foregående 
kommando af typen Manage Security Environment MSE: 
Set DST, og den foregående hashkode, der er indlæst af en 
PSO: HASH-kommando.  
TCS_133  Kommandomeddelelse  
▼M1 
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »00h«  CLA  
INS 1  »2Ah«  Udfør sikkerhedsoperation  
P1 1  »00h«  
P2 1  »A8h«  Etiket: Datafeltet indeholder dataobjekter, der er rele­
vante for verifikation  
Lc 1  »XXh«  Længde Lc af det efterfølgende datafelt  
#6 1  »9Eh«  Etiket for digital underskrift  
#7 eller 
#7-#8  L »NNh« eller 
»81 NNh«  Længde af digital underskrift (L er 2 bytes, hvis den 
digitale underskrift er længere end 127 bytes): 
128 bytes kodet i overensstemmelse med tillæg 11, del 
A, for takografapplikationer af første generation 
Afhængigt af den valgte kurve for takografapplikationer 
af anden generation (se tillæg 11, del B).  
#(7+L)- 
#(6+L+NN)  NN »XX..XXh«  Indhold af digital underskrift  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 275  
TCS_134  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— Lykkes verifikationen af underskriften ikke, tilbage­
meldes behandlingsstatus » 6688 «. Verifikationspro­
cessen er beskrevet i tillæg 11.  
— Hvis der ikke er valgt nogen offentlig nøgle, tilbage­
meldes status » 6A88 «. 
— Hvis nogle af de forventede dataobjekter (som angivet 
ovenfor) mangler, tilbagemeldes status » 6987 «. Dette 
kan forekomme, hvis en af de ønskede etiketter 
mangler.  
— Hvis der til behandling af kommandoen ikke er nogen 
hashkode til rådighed (som resultat af en forudgående 
PSO: HASH-kommando), tilbagemeldes status » 6985 «. 
— Hvis nogle dataobjekter er ukorrekte, tilbagemeldes 
status » 6988 «. Dette kan forekomme, hvis længden af 
et af de ønskede dataobjekter er forkert.  
— Hvis den valgte offentlige nøgle anses for beskadiget, 
tilbagemeldes status » 6400 « eller » 6581 «. 
▼M1 
— Hvis den valgte offentlige nøgle (som anvendes til at 
verificere den digitale underskrift) har en CHA.LSB 
(CertificateHolderAuthorisation.equipmentType), som 
ikke egner sig til verificering af digital underskrift i 
overensstemmelse med tillæg 11, tilbagemeldes status  
»6985« . 
▼B 
3.5.16  PROCESS DSRC MESSAGE  
Denne kommando bruges til at verificere integriteten og ægthede n af 
DSRC-meddelelsen og til at dechifrere de data, som en køretøjse nhed 
sender til en kontrolmyndighed eller et værksted via DSRC-forbi n­
delsen. Kortet udleder den krypteringsnøgle og den MAC-nøgle, d er 
bruges til at sikre DSRC-meddelelsen som beskrevet i tillæg 11,  del 
B, afsnit 13.  
Kun kontrolkortet og værkstedskortet kræves for at understøtte denne 
kommando i DF Tachograph_G2.  
Andre slags takografkort kan muligvis udføre denne kommando, me n 
de må ikke have en DSRC-hovednøgle. Disse kort kan derfor ikke 
udføre kommandoen med resultat, men skal afsluttes med en passe nde 
fejlkode.  
Kommandoen kan eventuelt være tilgængelig i hovedfilen og/eller  DF 
Tachograph. I så fald skal kommandoen afsluttes med en passende  
fejlkode.  
TCS_135 DSRC-hovednøglen er kun tilgængelig i DF Tacho­
graph_G2. Kontrol- og værkstedskortet skal således kun 
understøtte udførelse af kommandoen i DF Tacho­
graph_G2.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 276  
TCS_136 Kommandoen skal kun dekryptere DSRC-dataene og veri­
ficere den kryptografiske kontrolsum, men ikke fortolke de 
indlæste data.  
TCS_137 Dataobjekternes rækkefølge i kommandoens datafelt er 
fastlagt i denne specifikation.  
TCS_138  Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »80h«  Beskyttet CLA  
INS 1  »2Ah«  Udfør sikkerhedsoperation  
P1 1  »80h«  Svardata: ordinær værdi  
P2 1  »B0h«  Kommandodata: ordinær værdi, der er kodet i BER-TLV 
og omfatter SM-dataobjekter  
Lc 1  »NNh«  Længde Lc af det efterfølgende datafelt  
#6-#(5+L)  L  »87h« + 
L 87 + 
»XX..XXh«  DER-TLV-kodet indikatorbyte for udfyldningsindhold 
efterfulgt af krypteret takografindhold. For indikator­
byten for udfyldningsindhold skal værdien »00h« 
anvendes (»no further indication« (ingen yderligere angi­
velse) i henhold til ISO/IEC 7816-4:2013, tabel 52). For 
så vidt angår krypteringsmekanismen henvises til tillæg 
11, del B, afsnit 13. 
De tilladte værdier for længden L  87 er multiplerne af 
AES-bloklængden plus 1 for indikatorbyten for udfyld­
ningsindhold, dvs. fra 17 bytes til og med 193 bytes.  
Bemærk:  Se ISO/IEC 7816-4:2013, tabel 49, med hensyn 
til SM-dataobjektet med etiket »87h«.  
»81h« + 
»10h«  DER-TLV-kodet kontrolreferenceskabelon for fortro­
lighed, der indlejrer sammenkædningen af følgende 
dataelementer (se tillæg 1 (DSRCSecurityData) og 
tillæg 11, del B, afsnit 13): 
— tidsstempel på 4 bytes 
— tæller på 3 bytes 
— køretøjsenhedens serienummer på 8 bytes 
— DSRC-hovednøgleversion på 1 byte  
Bemærk:  Se ISO/IEC 7816-4:2013, tabel 49, med hensyn 
til SM-dataobjektet med etiket »81h«.  
»8Eh« + 
L 8E + 
»XX..XXh«  DER-TLV-kodet MAC over DSRC-meddelelsen. For så 
vidt angår MAC-algoritmen og beregning henvises til 
tillæg 11, del B, afsnit 13.  
Bemærk:  Se ISO/IEC 7816-4:2013, tabel 49, med hensyn 
til SM-dataobjektet med etiket »8Eh«.  
▼M3 
Le 1  »00h«  Som foreskrevet i ISO/IEC 7816-4  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 277  
TCS_139  Svarmeddelelse  
Byte  Længde  Værdi  Beskrivelse  
#1-#L  L  »XX..XXh«  Manglende data (i tilfælde af en fejl) eller dechifrerede 
data (udfyldning fjernet)  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder kortet 
»9000 «. 
— » 6A80 « indikerer ukorrekte parametre i kommandoens 
datafelt (bruges også, hvis dataobjekterne ikke sendes i 
den foreskrevne rækkefølge).  
— » 6A88 « indikerer, at adresserede data ikke er tilgænge­
lige (den adresserede DSRC-hovednøgle er ikke tilgæn­
gelig).  
— » 6900 « indikerer, at verifikationen af den kryptogra­
fiske kontrolsum eller dekrypteringen af dataene 
mislykkedes.  
▼M1 
— » 6985 « indikerer, at tidsstemplet på 4 byte, som 
fremgår af kommandodatafeltet er tidligeree end card­
ValidityBegin eller senere end cardExpiryDate.  
▼B 
4. TAKOGRAFKORTENES STRUKTUR  
Dette afsnit angiver takografkortenes filstruktur til lagring a f tilgænge­
lige data.  
Det specificerer ikke producentafhængige interne strukturer i k ortet 
som f.eks. startetiketter på filer eller lagring og behandling af datae­
lementer, som udelukkende behøves til intern brug, som f.eks.
  
,
 ,
  
eller
 .  
TCS_140 Takografkort af anden generation skal rumme hovedfilen 
og en takografapplikation af første og anden generation af 
samme type (f.eks. førerkortapplikationer).  
TCS_141 Takografkort skal som minimum understøtte det antal 
poster, som er fastsat for de tilsvarende applikationer, og 
må ikke understøtte flere poster end det maksimale antal 
poster, der er fastsat for de tilsvarende applikationer.  
▼M3 
Det højeste og laveste antal poster er nærmere beskrevet i 
dette afsnit for de forskellige applikationer. I version 2 af 
fører- og værkstedskort af anden generation skal applika­
tioner af første generation understøtte det maksimale antal 
poster, der er anført i TCS_150 og TCS_158.  
▼B 
For så vidt angår de sikkerhedsbetingelser, der anvendes i 
adgangsreglerne i hele dette afsnit, henvises til afsnit 3.3. 
Generelt angiver adgangstilstanden »læs« kommandoen 
READ BINARY med lige — og hvis de understøttes — 
ulige INS-byte med undtagelse af elementærfilen 
Sensor_Installation_Data på værkstedskortet. Se TCS_156 
og TCS_160. Adgangstilstanden »opdater« angiver 
kommandoen Update Binary med lige — og hvis de under­
støttes — ulige INS-byte, mens adgangstilstanden »vælg« 
angiver kommandoen SELECT.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 278  
4.1. Hovedfil (Master file — MF)  
TCS_142 Efter at hovedfilen er personaliseret, skal den have fø lgende 
permanente filstruktur og filadgangsregler:  
Bemærk:  Det korte id for elementærfilen (SFID) gives som 
decimaltal. F.eks. svarer værdien 30 til 11110 som binært 
tal.
 
Følgende forkortelse for sikkerhedsbetingelsen anvendes i 
denne tabel:  
SC1 ALW OR SM-MAC-G2  
TCS_143 Alle elementærfilers strukturer skal være transparente.  
TCS_144 Hovedfilen skal have følgende datastruktur:
  
TCS_145 Elementærfilen EF DIR skal indeholde følgende applika­
tionsrelaterede dataobjekter: »61 08 4F 06 FF 54 41 43 
48 4F 61 08 4F 06 FF 53 4D 52 44 54«  
TCS_146 Elementærfilen EF ATR/INFO skal findes, hvis takograf­
kortet i sit ATR angiver, at det understøtter felter med 
udvidet længde. I så fald skal elementærfilen EF ATR/ 
INFO indeholde dataobjektet med udvidet informations­
længde (DO »7F66«) som foreskrevet i ISO/IEC 7816- 
4:2013, afsnit 12.7.1.  
TCS_147 Elementærfilen EF Extended_Length skal findes, hvis tak o­
grafkortet i sit ATR angiver, at det understøtter felter med 
udvidet længde. I så fald skal elementærfilen indeholde 
følgende dataobjekt: »02 01 xx«, hvor værdien »xx« 
angiver, om felter med udvidet længde understøttes for 
protokollen T = 1 og/eller T = 0.  
Værdien »01« angiver, at felter med udvidet længde under­
støttes for protokollen T = 1.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 279  
Værdien »10« angiver, at felter med udvidet længde under­
støttes for protokollen T = 0.  
Værdien »11« angiver, at felter med udvidet længde under­
støttes for protokollerne T = 1 og T = 0.  
4.2. Førerkortapplikationer  
4.2.1  Førerkortapplikation af første generation  
TCS_148 Efter at førerkortapplikationen af første generation er  perso­
naliseret, skal den have følgende permanente filstruktur og 
filadgangsregler:
  
Følgende forkortelser for sikkerhedsbetingelserne anvendes 
i denne tabel:  
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 Alle elementærfilers strukturer skal være transparente.  
TCS_150 Førerkortapplikationen af første generation skal have 
følgende datastruktur:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 280
  
► (1) (2) M3 ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 281
  
▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 282  
TCS_151 Følgende værdier, der er anvendt som størrelsesangivels er i 
ovenstående tabel, er mindste og største antal poster i fører­
kortets datastruktur for en applikation af første generation:
  
4.2.2  Førerkortapplikation af anden generation  
▼M3 
TCS_152 Efter at førerkortapplikationen af anden generation er 
personaliseret, skal den have følgende permanente 
filstruktur og filadgangsregler:  
Bemærk:  
— Det korte id for elementærfilen (SFID) gives som deci­
maltal. F.eks. svarer værdien 30 til 11110 som binært 
tal. 
— Elementærfilen Application_Identification_V2, elemen­
tærfilen Places_Authentication, elementærfilen GNSS_ 
Places_Authentication, elementærfilen Border_Cros­
sings, elementærfilen Load_Unload_Operations, 
elementærfilen VU_Configuration og elementærfilen 
Load_Type_Entries findes kun i version 2 af førerkortet 
af anden generation.  
— cardStructureVersion i elementærfilen Applica­
tion_Identification svarer til {01 01} for version 2 af 
førerkortet af anden generation, mens den var lig med 
{01 00} for version 1 af førerkortet af anden 
generation.
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 283  
Følgende forkortelser for sikkerhedsbetingelsen anvendes i 
denne tabel:  
SC1 ALW OR SM-MAC-G2  
SC5 For kommandoen Read Binary med lige INS-byte: 
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2  
For kommandoen Read Binary med ulige INS-byte 
(hvis den understøttes): NEV  
▼B 
TCS_153 Alle elementærfilers strukturer skal være transparente.  
▼M3 
TCS_154 Førerkortapplikationen af anden generation skal have 
følgende datastruktur:
  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 284
  
▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 285
  
▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 286  
TCS_155 Følgende værdier, der er anvendt som størrelsesangivels er i 
ovenstående tabel, er mindste og største antal poster i fører­
kortets datastruktur for en applikation af anden generation:  
▼M3 
Min Max  
n 1 NoOfEventsPerType  1 2  1 2  
n 2 NoOfFaultsPerType  2 4  2 4  
n 3 NoOfCardVehicleRecords  200  200  
n 4 NoOfCardPlaceRecords  112  112  
n 6 CardActivityLengthRange  13776 bytes 
(56 døgn med 
117 aktivitetsskift)  13776 bytes 
(56 døgn med 
117 aktivitetsskift)  
n 7 NoOfCardVehicleUnitRecords  200  200  
n 8 NoOfGNSSADRecords  336  336  
n 9 NoOfSpecificConditionRecords  112  112  
n 10 NoOfBorderCrossingRecords  1120  1120  
n 11 NoOfLoadUnloadRecords  1624  1624  
n 12 NoOfLoadTypeEntryRecords  336  336  
n 13 VuConfigurationLengthRange  3072 bytes  3072 bytes  
▼B 
4.3. Værkstedskortapplikationer  
4.3.1  Værkstedskortsapplikation af første generation  
TCS_156 Efter at værkstedskortapplikationen af første generatio n er 
personaliseret, skal den have følgende permanente 
filstruktur og filadgangsregler:
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 287  
Følgende forkortelser for sikkerhedsbetingelserne anvendes 
i denne tabel:  
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 For kommandoen READ BINARY med lige 
INS-byte:  
(SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR  
(SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)  
For kommandoen READ BINARY med ulige 
INS-byte (hvis den understøttes): NEV  
▼B 
TCS_157 Alle elementærfilers strukturer skal være transparente.  
TCS_158 Værkstedskortsapplikationen af første generation skal h ave 
følgende datastruktur:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 288
  
▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 289
  
▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 290
  
TCS_159 Følgende værdier, der er anvendt som størrelsesangivels er i 
ovenstående tabel, er mindste og største antal poster i værk­
stedskortets datastruktur for en applikation af første 
generation:
  
4.3.2  Værkstedskortsapplikation af anden generation  
▼M3 
TCS_160 Efter at værkstedskortapplikationen af anden generation  er 
personaliseret, skal den have følgende permanente 
filstruktur og filadgangsregler.  
Bemærk:  
— Det korte id for elementærfilen (SFID) gives som deci­
maltal. F.eks. svarer værdien 30 til 11110 som binært 
tal. 
— Elementærfilen Application_Identification_V2, elemen­
tærfilen Places_Authentication, elementærfilen GNSS_ 
Places_Authentication, elementærfilen Border_Cros­
sings, elementærfilen Load_Unload_Operations, ele­
mentærfilen Load_Type_Entries, elementærfilen 
VU_Configuration og elementærfilen Calibra­
tion_Add_Datafindes kun i version 2 af værkstedskortet 
af anden generation.  
— cardStructureVersion i elementærfilen Applica­
tion_Identification er lig med {01 01} for version 2 
af anden generation af værkstedskortet, mens det var 
lig med {01 00} for version 1 af anden generation af 
værkstedskortet.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 291
  
Følgende forkortelser for sikkerhedsbetingelserne anvendes 
i denne tabel:  
SC1 ALW OR SM-MAC-G2  
SC5 For kommandoen Read Binary med lige INS-byte: 
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2  
For kommandoen Read Binary med ulige INS-byte 
(hvis den understøttes): NEV  
▼B 
TCS_161 Alle elementærfilers strukturer skal være transparente.  
TCS_162 Værkstedskortsapplikationen af anden generation skal ha ve 
følgende datastruktur:  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 292
  
▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 293
  
▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 294
  
▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 295
  
▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 296  
TCS_163 Følgende værdier, der er anvendt som størrelsesangivels er i 
ovenstående tabel, er mindste og største antal poster i værk­
stedskortets datastruktur for en applikation af anden 
generation:  
▼M3 
Min Max  
n 1 NoOfEventsPerType  3  3  
n 2 NoOfFaultsPerType  6  6  
n 3 NoOfCardVehicleRecords  8  8  
n 4 NoOfCardPlaceRecords  8  8  
n 5 NoOfCalibrationRecords  255  255  
n 6 CardActivityLengthRange  492 byte (1 dag * 240 
aktivitetsskift)  492 byte (1 dag 
med 240 aktivitetsskift)  
n 7 NoOfCardVehicleUnitRecords  8  8  
n 8 NoOfGNSSADRecords  2 4  2 4  
n 9 NoOfSpecificConditionRecords  4  4  
n 10 NoOfBorderCrossingRecords  4  4  
n 11 NoOfLoadUnloadRecords  8  8  
n 12 NoOfLoadTypeEntryRecords  4  4  
n 13 VuConfigurationLengthRange  3072 byte  3072 byte  
▼B 
4.4. Kontrolkortapplikationer  
4.4.1  Kontrolkortapplikation af første generation  
TCS_164 Efter at kontrolkortapplikationen af første generation er 
personaliseret, skal den have følgende permanente 
filstruktur og filadgangsregler:
  
Følgende forkortelser for sikkerhedsbetingelserne anvendes 
i denne tabel:  
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 Alle elementærfilers strukturer skal være transparente.  
TCS_166 Kontrolkortapplikationen af første generation skal have  
følgende datastruktur:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 297
  
TCS_167 Følgende værdier, der er anvendt som størrelsesangivels er i 
ovenstående tabel, er mindste og største antal poster i 
kontrolkortets datastruktur for en applikation af første 
generation:
  
4.4.2  Kontrolkortapplikation af anden generation  
▼M3 
TCS_168 Efter at kontrolkortapplikationen af anden generation e r 
personaliseret, skal den have følgende permanente 
filstruktur og filadgangsregler:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 298  
Bemærk:  
— Det korte id for elementærfilen (SFID) gives som deci­
maltal. F.eks. svarer værdien 30 til 11110 som binært 
tal. 
— Elementærfilen Application_Identification_V2, og 
elementærfilen VU_Configuration findes kun i version 
2 af anden generation af kontrolkortet  
— cardStructureVersion i elementærfilen Applica­
tion_Identification er lig med {01 01} for version 2 
af anden generation af kontrolkortet, mens det var lig 
med {01 00} for version 1 af anden generation af 
kontrolkortet.
  
Følgende forkortelser for sikkerhedsbetingelsen anvendes i 
denne tabel:  
SC1 ALW OR SM-MAC-G2  
SC5 For kommandoen Read Binary med lige 
INS-byte: SM-C-MAC-G2 AND SM-R-ENC- 
MAC-G2  
For kommandoen Read Binary med ulige 
INS-byte (hvis den understøttes): NEV  
▼B 
TCS_169 Alle elementærfilers strukturer skal være transparente.  
TCS_170 Kontrolkortapplikationen af anden generation skal have 
følgende datastruktur:  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 299
  
▼B 
TCS_171 Følgende værdier, der er anvendt som størrelsesangivels er i 
ovenstående tabel, er mindste og største antal poster i 
kontrolkortets datastruktur for en applikation af anden 
generation:  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 300  
Min Max  
n 7 NoOfControlActivityRecords  230  520  
n 13 VuConfigurationLengthRange  3072 byte  3072 byte  
▼B 
4.5. Virksomhedskortapplikationer  
4.5.1  Virksomhedskortapplikation af første generation  
TCS_172 Efter at virksomhedskortapplikationen af første generat ion 
er personaliseret, skal den have følgende permanente 
filstruktur og filadgangsregler:
  
Følgende forkortelser for sikkerhedsbetingel­
serne anvendes i denne tabel:  
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 Alle elementærfilers strukturer skal være transparente.  
TCS_174 Virksomhedskortapplikationen af første generation skal 
have følgende datastruktur:
  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 301  
TCS_175 Følgende værdier, der er anvendt som størrelsesangivels er i 
ovenstående tabel, er mindste og største antal poster i virk­
somhedskortets datastruktur for en applikation af første 
generation:
  
4.5.2  Virksomhedskortapplikation af anden generation  
▼M3 
TCS_176 Efter at virksomhedskortapplikationen af anden generati on 
er personaliseret, skal den have følgende permanente 
filstruktur og filadgangsregler.  
Bemærk:  
— Det korte id for elementærfilen (SFID) gives som deci­
maltal. F.eks. svarer værdien 30 til 11110 som binært 
tal. 
— Elementærfilen Application_Identification_V2, og 
elementærfilen VU_Configuration findes kun i version 
2 af anden generation af virksomhedskortet  
— cardStructureVersion i elementærfilen Applica­
tion_Identification er lig med {01 01} for version 2 
af anden generation af virksomhedskortet, mens det 
var lig med {01 00} for version 1 af anden generation 
af virksomhedskortet.
  
Følgende forkortelser for sikkerhedsbetingelsen anvendes i 
denne tabel:  
SC1 ALW OR SM-MAC-G2  
SC5 For kommandoen Read Binary med lige 
INS-byte: SM-C-MAC-G2 AND SM-R-ENC- 
MAC-G2  
For kommandoen Read Binary med ulige 
INS-byte (hvis den understøttes): NEV  
▼B 
TCS_177 Alle elementærfilers strukturer skal være transparente.  
TCS_178  Virksomhedskortapplikationen af anden generation skal have 
følgende datastruktur:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 302
  
▼B 
TCS_179  Følgende værdier, der er anvendt som størrelsesangivelser i 
ovenstående tabel, er mindste og største antal poster i virk­
somhedskortets datastruktur for en applikation af anden 
generation:  
▼M3 
Min Max  
n 8 NoOfCompanyActivityRecords  230  520  
n 13 VuConfigurationLengthRange  3072 byte  3072 byte  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 303  
Tillæg 3  
PIKTOGRAMMER  
PIC_001 Der kan til takografen anvendes følgende piktogrammer o g piktogram­
kombinationer (eller piktogrammer og kombinationer, som svarer 
tilstrækkeligt til dem til at være entydigt identificerbare som  dem):  
1. BASISPIKTOGRAMMER  
Mennesker  Handlinger  Funktionstilstande
  
Virksomhed  Virksomhedstilstand
  
Tilsynsførende  Kontrol  Kontroltilstand
  
Fører  Kørsel  Driftstilstand
  
Værksted/prøvestation  Eftersyn/kalibrering  Kalibreringstilstand
  
Fabrikant  
Aktiviteter  Varighed
  
Til rådighed  Aktuel rådighedsperiode
  
Kørsel  Kontinuerlig køretid
  
Hvile  Aktuel hvileperiode
  
Andet arbejde  Aktuel arbejdsperiode
  
Pause  Akkumuleret pausetid
  
Ukendt  
Udstyr  Funktioner
  
Førerkortplads
  
Kortplads for medchauffør
  
Kort
 
Ur
 
Skærm  Visning på skærm
  
Overførsel til eksternt lager  Dataoverførsel
  
Strømforsyning
  
Printer/udskrift  Trykning
  
Føler
  
Dækstørrelse
  
Køretøj/køretøjsenhed
  
GNSS-udstyr
  
Udstyr til fjernkommunikation
  
ITS-grænseflade  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 304  
Særlige omstændigheder, manuel indlæsning
  
Uden for gyldighedsområde
  
Overfart med færge/tog
  
Lasteoperation
  
Losseoperation
  
Samtidig laste-/losseoperation
  
Lasttype: passagerer
  
Lasttype: gods
  
Lasttype: udefineret lasttype  
▼B 
Diverse
  
Hændelser
  Fejl
  
Den daglige arbejdstids begyndelse
  Den daglige arbejdstids afslutning
  
Sted
 
Manuel indlæsning af føreraktiviteter  
▼M3
 
Sikkerhed/bekræftede data/plomber  
▼B
 
Hastighed
  
Tid
 
Total/sum  
▼M3
 
Digitalt kort/grænsepassage  
▼B 
Angivelse  
24t Dagligt
  
Ugentligt
  
Hver anden uge
  
Fra eller til  
2. KOMBINATIONER AF PIKTOGRAMMER  
Diverse
  
Kontrolsted
  
Sted, hvor den daglige arbejdstid 
begynder
  Sted, hvor den daglige 
arbejdstid slutter  
▼M1
 
Position efter tre timers kumuleret 
køretid  
▼B
 
Fra tidspunkt
  Til tidspunkt
  
Fra køretøj
  
Uden for gyldighedsområde (start)
  Uden for gyldighedsområde (slut)  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 305
  
Position, hvor køretøjet har passeret 
grænsen mellem to lande
  
Position, hvor en lasteoperation har 
fundet sted
  
Position, hvor en losseoperation har 
fundet sted
  
Position, hvor en samtidig laste-/ 
losseoperation har fundet sted  
▼B 
Kort
  
Førerkort
  
Virksomhedskort
  
Kontrolkort
  
Værkstedskort
  
Intet kort  
Kørsel
  
Førerholdkørsel
  
Køretid for én uge
  
Køretid for to uger  
Udskrifter
  
Daglig udskrift af føreraktivitet fra kort
  
Daglig udskrift af føreraktivitet fra VU
  
Udskrift af hændelser og fejl fra kort
  
Udskrift af hændelser og fejl fra VU
  
Udskrift af tekniske data
  
Udskrift af overskridelse af tilladt hastighed  
▼M3
 
Udskrift af historik for isatte kort  
▼B 
Begivenheder
  
Isætning af ugyldigt kort
  
Kortkonflikt
  
Tidsoverlapning
  
Kørsel uden behørigt kort
  
Isætning af kort under kørslen
  
Seneste kortsession ikke korrekt afsluttet
  
Overskridelse af tilladt hastighed
  
Strømforsyningssvigt
  
Fejl ved køredata
  
Køretøjsbevægelseskonflikt
  
Sikkerhedsbrud  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 306
  
Tidskonflikt eller justering af klokkeslæt (foretaget af værkst ed) 
▼B
 
Kontrol af overskridelse af tilladt hastighed  
▼M1
 
Manglende positionsoplysninger fra GNSS-modtager eller Fejl ved  
kommunikation med det eksterne GNSS-udstyr
  
Fejl ved kommunikation med udstyr til fjernkommunikation  
▼M3
 
GNSS-anomali  
▼B 
Fejl
 
Kortfejl (førerkortplads)
  
Kortfejl (medchaufførs kortplads)
  
Displayfejl
  
Dataoverførselsfejl
  
Printerfejl
  
Følerfejl
  
Intern fejl i VU
  
GNSS-fejl
  
Fejl ved fjernkommunikation  
Manuel indlæsning
  
Stadig samme daglige arbejdsperiode?
  
Slut på foregående arbejdsperiode?
  
Bekræft eller indlæs sted, hvor daglig arbejdsperiode slutter
  
Indlæs starttidspunkt
  
Indlæs sted, hvor daglig arbejdsperiode begynder.  
Bemærk:  Andre kombinationer af piktogrammer, som danner udskriv­
ningsgrupper eller datanavne for poster, er givet i tillæg 4.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 307  
Tillæg 4  
UDSKRIFTER  
INDHOLDSFORTEGNELSE  
1. GENERELT  
2. SPECIFIKATION AF DATAGRUPPER  
3. SPECIFIKATION AF UDSKRIFTER  
3.1. Daglig udskrift af føreraktivitet fra kort  
3.2. Daglig udskrift af føreraktivitet fra køretøjsenhed  
3.3. Udskrift af hændelser og fejl fra kort  
3.4. Udskrift af hændelser og fejl fra køretøjsenhed  
3.5. Udskrift af tekniske data  
3.6. Udskrift af overskridelse af tilladt hastighed  
3.7 Historik over isatte kort  
1. GENERELT  
Hver udskrift er opbygget ved kædning af forskellige datagruppe r, om 
muligt identificeret med en gruppeidentifikator.  
En datagruppe indeholder en eller flere poster, eventuelt ident ificeret 
ved en postidentifikator.  
PRT_001 Når en gruppeidentifikator står umiddelbart foran en po st­
identifikator, bliver postidentifikatoren ikke udskrevet.  
PRT_002 Når et dataelement er ukendt eller ikke må udskrives af  
grunde vedrørende dataadgang, udskrives mellemrum i stedet.  
PRT_003 Hvis indholdet af en hel linje er ukendt eller ikke beh øver 
udskrives, udelades hele linjen.  
PRT_004 Numeriske datafelter udskrives højrejusteret, med melle mrum 
som skilletegn for tusinder og millioner, og uden foranstillede  
nuller.  
▼M3 
PRT_005 Strengdatafelter udskrives venstrejusteret og udfyldt m ed 
mellemrum til dataelementets længde eller om nødvendigt 
afkortet til dataelementets længde. Navne og adresser kan 
udskrives på to linjer.  
▼B 
PRT_006 I tilfælde af et linjeskift på grund af et langt teksts tykke, skal 
et specialtegn (en prik midt på linjen (i højden) »•«) 
udskrives som det første tegn på den næste linje.  
2. SPECIFIKATION AF DATAGRUPPER  
I dette kapitel er anvendt følgende notationsregler for format:  
— Tegn med  fede  typer angiver almindelig tekst, som skal udskrives 
(udskrives med normale tegn)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 308  
— Normale typer angiver variable (piktogrammer eller data) som ved 
udskrivning skal erstattes med deres værdi  
— Variabelnavne er omgivet af understregningstegn for at angive  den 
længde, som dataelementer for den pågældende variabel kan have  
— Datoer angives i formatet »dd/mm/yyyy« (dag, måned, år) Forma tet 
»dd.mm.yyyy« kan også anvendes  
— Betegnelsen »kortidentifikation« angiver sammensætningen af 
kortets type gennem en kombination af kortpiktogrammer, den 
kortudstedende medlemsstats kode, en normal skråstreg og kortet s 
nummer med udskiftningsindekset og fornyelsesindekset adskilt a f et 
mellemrum: 
P
 x  x  x  / x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x
 Kombination af kort 
og piktogram  
Udstedende 
medlemsstats kode De første 14 tegn i kortnummeret 
(eventuelt inkl. et fortløbende indeks)
 
Udskiftningsindeks  
Fornyelsesindeks 
▼M3 
— I en datagruppe henviser teksten efter »pi=« til det tilsvare nde pikto­
gram eller den tilsvarende piktogramkombination defineret i til læg 3.  
— Når dette piktogram udskrives efter længdegraden og breddegra den 
af en registreret position eller efter det tidspunkt, hvor posi tionen 
blev bestemt,
  angiver det, at positionen er blevet beregnet ud fra 
ægthedsbekræftede navigationsmeddelelser.  
— * data kun tilgængelige i GEN2-takografer (alle versioner)  
— ** data kun tilgængelige i version 2 af GEN2-takografer.  ▼B
02016R0799 — DA — 21.08.2023 — 003.001 — 309  
PRT_007 Udskrifter skal anvende følgende datablokke og/eller da taposter i over­
ensstemmelse med følgende betydninger og formater:
  
► (1) (2) (3) (4) (5)  M3 ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 310
  
► (1) (2) (3)  M3 ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 311
  
► (1) (2) M3 ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 312
  
▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 313
  
► (1) (2) (3) (4)  M3 ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 314
  
▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 315
  
► (1) M3 
3. SPECIFIKATION AF UDSKRIFTER  
I dette kapitel er anvendt følgende notationsregler for format:  
N Udskriv datagruppe- eller postantal N  
N Udskriv datagruppe- eller postantal N, gentaget så mange gange som 
nødvendigt  
X/Y Udskriv datagruppe eller post X og/eller Y efter behov, gentage t som 
mange gange som nødvendigt.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 316  
3.1. Daglig udskrift af føreraktivitet fra kort  
▼M3 
PRT_008 Daglig udskrift af føreraktivitet fra kort skal overhol de 
følgende format:
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 317  
3.2. Daglig udskrift af føreraktivitet fra køretøjsenhed  
▼M3 
PRT_009 Daglig udskrift af føreraktivitet fra køretøjsenhed ska l over­
holde følgende format:
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 318  
3.3. Udskrift af hændelser og fejl fra kort  
PRT_010 Udskrift af hændelser og fejl fra kort skal overholde f ølgende 
format: 
1 Dato og tidspunkt for udskrivning af dokumentet  
2 Udskriftens art  
3 Identifikation af den tilsynsførende (hvis der er isat et kontr olkort i 
køretøjsenheden + GEN)  
3 Identifikation af føreren (fra det kort, som udskriften omhandl er) 
4 Identifikation af køretøj (det køretøj, hvorfra udskriften tage s) 
12.2 Skilletegn for hændelser  
12.4 Hændelsesposter (alle hændelser gemt på kortet)  
12.3 Skilletegn for fejl  
12.4 Poster vedrørende fejl (alle fejl gemt på kortet)  
22.1 Kontrolsted  
22.2 Den tilsynsførendes underskrift  
22.5 Førerens underskrift  
3.4. Udskrift af hændelser og fejl fra køretøjsenhed  
PRT_011 Udskrift af hændelser og fejl fra køretøjsenhed skal ov er­
holde følgende format: 
1 Dato og tidspunkt for udskrivning af dokumentet  
2 Udskriftens art  
3 Identifikation af kortindehaver (for alle kort isat i køretøjse nhed + 
GEN)  
4 Identifikation af køretøj (det køretøj, hvorfra udskriften tage s) 
13.2 Skilletegn for hændelser  
13.4 Hændelsesposter (alle hændelser, som er gemt eller igangværende  på 
køretøjsenheden)  
13.3 Skilletegn for fejl  
13.4 Poster vedrørende fejl (alle fejl, som er gemt eller igangværen de på 
køretøjsenheden)  
22.1 Kontrolsted  
22.2 Den tilsynsførendes underskrift  
22.5 Førerens underskrift  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 319  
3.5. Udskrift af tekniske data  
▼M3 
PRT_012 Udskrift af tekniske data skal overholde følgende forma t:
 ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 320  
3.6. Udskrift af overskridelse af tilladt hastighed  
PRT_013 Udskrift af overskridelser af tilladt hastighed skal ov erholde 
følgende format: 
1 Dato og tidspunkt for udskrivning af dokumentet  
2 Udskriftens art  
3 Identifikation af kortindehaver (for alle kort isat i køretøjse nhed + 
GEN)  
4 Identifikation af køretøj (det køretøj, hvorfra udskriften tage s) 
20 Information vedrørende overskridelse af tilladt hastighed  
21.1 Identifikator for data vedrørende overskridelser af tilladt has tighed  
21.4/21.5  Første overskridelse af tilladt hastighed efter seneste kalibre ring 
21.2 Identifikator for data vedrørende overskridelser af tilladt has tighed  
21.4/21.5  De 5 alvorligste hændelser med overskridelse af tilladt hastigh ed 
inden for de sidste 365 dage  
21.3 Identifikator for data vedrørende overskridelser af tilladt has tighed  
21.4/21.5  Den alvorligste hændelse vedrørende overskridelse af tilladt 
hastighed for hver af de 10 seneste dage, den er forekommet  
22.1 Kontrolsted  
22.2 Den tilsynsførendes underskrift  
22.5 Førerens underskrift  
3.7. Historik over isatte kort  
▼M3 
PRT_014 Udskriften af historikken over isatte kort skal overhol de 
følgende format:
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 321  
Tillæg 5  
SKÆRM  
I dette tillæg er anvendt følgende notationsregler for format:  
— tegn med  fede  typer angiver almindelig tekst, som vises (vises på skærmen 
med normale typer)  
— normale typer angiver variabler (piktogrammer eller data) som  på skærmen 
skal erstattes med deres værdi:  
— dd mm yyyy: dag, måned, år  
— hh: timer  
— mm: minutter  
— D: varighedspiktogram  
— EF: kombination af piktogrammer for begivenheder eller fejl  
— O: piktogram for funktionsmåde.  
DIS_001 Takografen skal på skærmen vise data i følgende formate r: 
Data  Format  
Standardskærmbillede  
Lokal tid
  
Funktionsmåde
  
Oplysninger vedrørende fører
  
Oplysninger vedrørende medchauffør
  
Omstændigheden »uden for område« åbnet
  
Visning af advarsel  
Overskridelse af sammenhængende køretid
  
Hændelse eller fejl
  
Andre skærmbilleder  
UTC-dato
  
tid 
Førers sammenhængende køretid og akkumulerede pausetid
  
Medchaufførs sammenhængende køretid og akkumulerede 
pausetid
  
Førers akkumulerede køretid for den foregående og den 
aktuelle uge
  
Medchaufførs akkumulerede køretid for den foregående og 
den aktuelle uge
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 322  
Tillæg 6  
STIK TIL KALIBRERING OG DATAOVERFØRSEL PÅ FRONTPA ­
NELET  
INDHOLDSFORTEGNELSE  
1. HARDWARE  
1.1. Stik  
1.2. Kontakternes tildeling  
1.3. Blokdiagram  
2. GRÆNSEFLADE FOR DATAOVERFØRSEL  
3. GRÆNSEFLADE FOR KALIBRERING  
1. HARDWARE  
1.1. Stik  
INT_001 Stikket til dataoverførsel/kalibrering skal være 6-bene t, skal være 
tilgængeligt fra frontpanelet, uden at nogen del af takografen 
behøver adskilles, og skal være i overensstemmelse med 
følgende tegning (alle mål i mm):
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 323  
Følgende diagram viser et typisk 6-benet stik:
  
1.2. Kontakternes tildeling  
INT_002 Kontakterne skal være tildelt i overensstemmelse med fø lgende 
tabel:  
Klemme  Beskrivelse  Bemærkning  
1 Batteri minus  Tilsluttet køretøjets negative batteripol  
2 Datakommunikation  K-linje (ISO 14230-1)  
3 RxD — dataoverførsel  Dataindgang til takograf  
4 Indgangs-/udgangssignal  Kalibrering  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 324  
Klemme  Beskrivelse  Bemærkning  
5 Permanent effektudgang  Det foreskrevne spændingsområde er som køretøjets strøm­
forsyning minus 3 V for at tage hensyn til spændingstabet 
over beskyttelseskredsen 
Udgangseffekt 40 mA  
6 TxD — dataoverførsel  Dataoverførsel fra takograf  
1.3. Blokdiagram  
INT_003 Blokdiagrammet skal være i overensstemmelse med følgend e:
 
2. GRÆNSEFLADE FOR DATAOVERFØRSEL  
INT_004 Grænsefladen for dataoverførsel skal opfylde specifikat ionerne 
RS232.  
INT_005 Grænsefladen for dataoverførsel skal have én startbit, 8 mindst 
betydende databit først, én lige paritetsbit og 1 stopbit.
  
Organisation af databytes  
Startbit: én bit med logisk niveau 0  
Databit: overføres med mindst betydende bit først  
Paritetsbit: lige paritet  
Stopbit: én bit med logisk niveau 1  
Ved overførsel af numeriske data bestående af flere end én byte  overføres 
den mest betydende byte først, og den mindst betydende byte sid st. 
INT_006 Transmissionshastigheden skal kunne indstilles mellem 9  600 
bps og 115 200 bps. Transmission skal kunne ske med den 
højst mulige transmissionshastighed, idet den indledende 
hastighed efter start af kommunikationen er stillet på 9 600 bp s. ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 325  
3. GRÆNSEFLADE FOR KALIBRERING  
INT_007 Datakommunikationen skal opfylde ISO 14230-1 Road vehic les 
— Diagnostic systems — Keyword protocol 2000 — Part 1: 
Physical layer, First edition: 1999.  
INT_008 Indgangs- og udgangssignalet skal opfylde følgende elek triske 
forskrift:  
Parameter  Minimum  Typisk  Maksimum  Bemærkning  
U lav (ind)  1,0 V  I = 750 μA  
U høj (ind)  4  V  I = 200 μA  
Frekvens  4 kHz  
U lav (ud) 1,0 V  I  =  1  m A  
U høj (ud) 4  V  I  =  1  m A  
INT_009 Indgangs- og udgangssignalet skal opfylde følgende tids ­
diagrammer:
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 326  
Tillæg 7  
PROTOKOLLER FOR DATAOVERFØRSEL  
INDHOLDSFORTEGNELSE  
1. INDLEDNING  
1.1. Anvendelsesområde  
1.2. Akronymer og notation  
2. OVERFØRSEL AF DATA FRA KØRETØJSENHEDEN  
2.1. Fremgangsmåde ved dataoverførsel  
2.2. Protokol for dataoverførsel  
2.2.1 Meddelelsesstruktur  
2.2.2 Meddelelsestyper  
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 Meddelelsesstrøm  
2.2.4 Synkronisering  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 327  
2.2.5 Fejlhåndtering  
2.2.5.1 Fasen Begynd kommunikation  
2.2.5.2 Kommunikationsfasen  
2.2.6 Svarmeddelelsens indhold  
▼M3 
2.2.6.1 Positive Response Transfer Data Download Interface Vers ion (Positivt 
Svar Dataoverførsel, Version af Download-Interface)  
2.2.6.2 Positive Response Transfer Data Overview (Positivt Svar  Dataover­ 
førsel, Oversigt)  
2.2.6.3 Positive Response Transfer Data Activities (Positivt Sv ar Dataover­ 
førsel, Aktiviteter)  
2.2.6.4 Positive Response Transfer Data Events and Faults (Posi tivt Svar Data­ 
overførsel, Hændelser og Fejl)  
2.2.6.5 Positive Response Transfer Data Detailed Speed(Positivt  Svar Dataover­ 
førsel, Præcis Hastighedsangivelse)  
2.2.6.6 Positive Response Transfer Data Technical Data (Positiv t Svar Data­ 
overførsel, Tekniske Data)  
▼B 
2.3. Lagring af fil på eksternt lagermedium  
3. PROTOKOL FOR OVERFØRSEL AF TAKOGRAFKORT  
3.1. Anvendelsesområde  
3.2. Definitioner  
3.3. Dataoverførsel af kort  
3.3.1 Initialiseringssekvens  
3.3.2 Sekvens for ikke-underskrevne datafiler  
3.3.3 Sekvens for underskrevne datafiler  
3.3.4 Sekvens for nulstilling af kalibreringstæller  
3.4. Format for lagring af data  
3.4.1 Indledning  
3.4.2 Filformat  
4. OVERFØRSEL AF TAKOGRAFKORT VIA KØRETØJSENHEDEN  
1. INDLEDNING  
Dette tillæg beskriver de procedurer, der skal følges ved forsk ellige 
typer dataoverførsel til et eksternt lagermedium (ESM), foruden  de 
protokoller, der skal gennemføres for at sikre korrekt overførs el af 
data og fuld kompatibilitet af det overførte dataformat, sålede s at 
enhver tilsynsførende har adgang til disse data og mulighed for  at 
kontrollere deres ægthed og integritet, før de analyseres.  
▼M1 
1.1. Anvendelsesområde  
Der kan overføres data til et eksternt lagermedium:  
— fra en køretøjsenhed med en intelligent dedikeret enhed (IDE)  
tilsluttet køretøjsenheden  
— fra et takografkort med en IDE-enhed med kortlæser (IFD)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 328  
— fra et takografkort via en køretøjsenhed ved hjælp af en IDE- enhed 
tilsluttet køretøjsenheden.  
For at man skal kunne fastslå ægthed og integritet af overførte  data, 
som er gemt på et eksternt lagermedium, bliver der ved dataover førsel 
vedhæftet en underskrift i overensstemmelse med tillæg 11 (fæll es 
sikkerhedsmekanismer). Kildeenhedens (køretøjsenhed eller kort)  iden­
tifikation og sikkerhedsattester (fra medlemsstaten og for udst yret) 
bliver ligeledes overført. Den, der kontrollerer data, skal uaf hængigt 
være indehaver af en betroet europæisk offentlig nøgle.  
Data, der overføres fra en køretøjsenhed, underskrives i henhol d til 
tillæg 11 Fælles sikkerhedsmekanismer, del B (takografsystemer af 
anden generation), undtagen når førerkontrollen udføres af en k ontrol­
myndighed uden for EU under anvendelse af et kontrolkort af før ste 
generation, idet data så underskrives i henhold til tillæg 11 F ælles 
sikkerhedsmekanismer, del A (takografsystemer af første generat ion), 
jf. tillæg 15 Migration, krav MIG_15.  
I dette tillæg beskrives derfor to typer data, der kan overføre s fra 
køretøjsenheden:  
— Overførsel af køretøjsenhedsdata af anden generation med data ­
struktur af anden generation, som underskrives i henhold til ti llæg 
11 Fælles sikkerhedsmekanismer, del B  
— Overførsel af køretøjsenhedsdata af første generation med dat a­
struktur af første generation, som underskrives i henhold til t illæg 
11 Fælles sikkerhedsmekanismer, del A.  
Ligeledes er der to typer dataoverførsel fra førerkort af anden  genera­
tion, der er isat en køretøjsenhed, jf. dette tillægs afsnit 3 og 4.  
▼B 
1.2. Akronymer og notation  
I dette tillæg anvendes følgende akronymer:  
AID Applikationsidentifikator (Application Identifier)  
ATR  Svar på reset (Answer to Reset)  
CS Kontrolsumbyte  
DF Dedikeret fil  
DS_ Diagnosesession  
EF Elementærfil (Elementary File)  
ESM  Eksternt lagermedium  
FID Filidentifikator (filnavn)  
FMT  Formatbyte (første byte i meddelelsens hoved)  
ICC Chipkort (Integrated Circuit Card)  
IDE Intelligent dedikeret udstyr: Det udstyr, som anvendes til at 
overføre data til det eksterne lagermedium (f.eks. pc)  
IFD Kortlæser (interface device)  
KWP  Nøgleordsprotokol 2000  
LEN  Længdebyte (sidste byte i meddelelsens hoved)  
PPS Protokolparametervalg (Protocol Parameter Selection)  
PSO  Udfør sikkerhedsoperation  
SID Tjenesteidentifikator  
SRC  Kildebyte  
TGT  Adressebyte  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 329  
TLV  Etiketlængde (Tag length value)  
TREP  Parameter for svar på overførsel  
TRTP  Parameter for anmodning om overførsel  
VU Køretøjsenhed  
2. OVERFØRSEL AF DATA FRA KØRETØJSENHEDEN  
2.1. Fremgangsmåde ved dataoverførsel  
For at overføre data fra køretøjsenheden skal operatøren foreta ge 
følgende:  
— indsætte sit takografkort i en kortplads i køretøjsenheden (* ) 
— tilslutte IDE-enheden til køretøjsenhedens datastik  
— etablere forbindelse mellem IDE-enhed og køretøjsenhed  
— på IDE-enheden vælge data, som skal overføres, og sende anmod ­
ningen til køretøjsenheden  
— afslutte dataoverførselssessionen.  
2.2. Protokol for dataoverførsel  
Protokollen har master/slave-struktur, således at IDE-enheden f ungerer 
som master og køretøjsenheden som slave.  
Meddelelsesstruktur, -typer og -strøm er hovedsagelig baseret p å 
Keyword protocol 2000 (KWP) (ISO 14230-2 Road vehicles — Diag­
nostic systems — Keyword protocol 2000 — Part 2: Data link laye r). 
Applikationslaget bygger hovedsagelig på det aktuelle udkast ti l ISO 
14229-1 (Road vehicles — Diagnostic systems — Part 1: Diagnosti c 
services, version 6 af 22. februar 2001).  
2.2.1  Meddelelsesstruktur  
DDP_002 Alle meddelelser, som udveksles mellem IDE-enhed og 
køretøjsenhed, er formateret med tredelt struktur:  
— et hoved bestående af en formatbyte (FMT), en 
destinationsbyte (TGT), en kildebyte (SRC) og eventuelt 
en længdebyte (LEN)  
— et datafelt bestående af en tjenesteidentifikatorbyte (SID) 
og et varierende antal databytes, som kan omfatte en 
ikke-obligatorisk diagnosesessionsbyte (DS) eller en 
frivillig overførselsparameterbyte (TRTP eller TREP)  
— en kontrolsum bestående af en kontrolsumbyte (CS).  
Hoved  Datafelt  Kontrolsum  
FMT  TGT  SRC  LEN  SID  DATA  …  …  …  C S  
4 bytes  Maks. 255 bytes  1 byte  
TGT- og SRC-byten repræsenterer den fysiske adresse på 
modtageren og afsenderen af meddelelsen. De har værdierne 
F0 Hex for IDE-enheden og EE Hex for køretøjsenheden.  
LEN-byten er længden af datafeltdelen.  ▼B 
(*) Det indsatte kort vil udløse de nødvendige adgangsrettighed er til overførselsfunktionen 
og til data. Det skal imidlertid være muligt at overføre data f ra et førerkort, der er indsat 
i en af køretøjsenhedens kortpladser, hvis der ikke er isat en anden korttype i den anden 
kortplads.
 02016R0799 — DA — 21.08.2023 — 003.001 — 330  
Kontrolsumbyten er 8 bit-sumserie modulo 256 for alle 
meddelelsens bytes bortset fra selve kontrolsummen.  
FMT-, SID-, DS-, TRTP- og TREP-bytes er defineret senere 
i dette dokument.  
DDP_003 Hvis de data, som meddelelsen skal medføre, er længere end 
pladsen i datafeltdelen, bliver meddelelsen reelt sendt som 
flere delmeddelelser. Hver sådan delmeddelelse har et 
hoved, samme SID og TREP og en 2-byte-delmeddelelses­
tæller, som angiver delmeddelelsens nummer i den samlede 
meddelelse. For at der skal kunne foretages fejlkontrol og 
afbrydelse, kvitterer IDE-enheden for hver delmeddelelse. 
IDE-enheden kan acceptere delmeddelelsen, anmode om, 
at den genoverføres, anmode køretøjsenheden om at 
begynde igen eller afbryde dataoverførslen.  
DDP_004 Hvis den sidste delmeddelelse indeholder nøjagtig 255 b ytes 
i datafeltet, skal der vedhæftes en afsluttende delmeddelelse, 
hvor datafeltet er tomt (bortset fra SID, TREP og delmed­
delelsestælleren), som angivelse af meddelelsens slutning.  
Eksempel:  
Hoved  SID  TREP  Meddelelse  C S  
4 bytes  Længere end 255 bytes  
Vil blive overført som:  
Hoved  SID  TREP  0 0  0 1  Delmeddelelse 1  C S  
4 bytes  255 bytes  
Hoved  SID  TREP  0 0  0 2  Delmeddelelse 
2 CS 
4 bytes  255 bytes  
… 
Hoved  SID  TREP  x x  y y  Delmeddelelse n  C S  
4 bytes  Mindre end 255 bytes  
eller som:  
Hoved  SID  TREP  0 0  0 1  Delmeddelelse 1  C S  
4 bytes  255 bytes  
Hoved  SID  TREP  0 0  0 2  Delmeddelelse 2  C S  
4 bytes  255 bytes  
… 
Hoved  SID  TREP  x x  y y  Delmeddelelse n  C S  
4 bytes  255 bytes  
Hoved  SID  TREP  x x  yy+1  C S  
4 bytes  4 bytes  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 331  
2.2.2  Meddelelsestyper  
Kommunikationsprotokollen for overførsel af data mellem køretøj s­
enheden og IDE-enheden kræver udveksling af 8 forskellige typer  
meddelelser.  
Disse meddelelser er sammenfattet i følgende tabel.  
▼M3 
Message Structure  Max 4 Bytes  Max 255 Bytes  1 Byte  
Header  Data  CheckSum  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  C S  
Start Communication Request  8 1  E E  F 0  8 1  E 0  
Positive Response Start Communica­
tion 80 F 0  E E  0 3  C 1  EA, 8F  9  B  
Start Diagnostic Session Request  8 0  E E  F 0  0 2  1 0  8 1  F 1  
Positive Response Start Diagnostic  8 0  F 0  E E  0 2  5 0  8 1  3 1  
Link Control Service  
Verify Baud Rate (stage 1)  
9 600 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,01  E C  
19 200 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,02  E D  
38 400 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,03  E E  
57 600 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,04  E F  
115 200 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,05  F 0  
Positive Response Verify Baud Rate  8 0  F 0  E E  0 2  C 7  0 1  2 8  
Transition Baud Rate (stage 2)  8 0  E E  F 0  0 3  8 7  0 2  0 3  E D  
Request Upload  8 0  E E  F 0  0  A  3 5  00,00,00,00, 
00,FF,FF, 
FF,FF  99 
Positive Response Request Upload  8 0  F 0  E E  0 3  7 5  00,FF  D 5  
Transfer Data Request  
Download interface version  8 0  E E  F 0  0 2  3 6  0 0  9 6  
Overview  80 E E  F 0  0 2  3 6  01, 21 or 31  C S  
Activities  80 E E  F 0  0 6  3 6  02, 22 or 32  Date  C S  
Events & Faults  80 E E  F 0  0 2  3 6  03, 23 or 33  Date  C S  
Detailed Speed  80 E E  F 0  0 2  3 6  04 eller 24  Date  C S  
Technical Data  80 E E  F 0  0 2  3 6  05, 25 or 35  Date  C S  
Card download  80 E E  F 0  02 eller 03  3 6  0 6  Slot  C S  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 332  
Message Structure  Max 4 Bytes  Max 255 Bytes  1 Byte  
Header  Data  CheckSum  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  C S  
Positive Response Transfer Data  8 0  F 0  E E  Len  7 6  TREP  Data  C S  
Request Transfer Exit  8 0  E E  F 0  0 1  3 7  9 6  
Positive Response Request Transfer 
Exit 80 F 0  E E  0 1  7 7  D 6  
Stop Communication Request  8 0  E E  F 0  0 1  8 2  E 1  
Positive Response Stop Communica­
tion 80 F 0  E E  0 1  C 2  2 1  
Acknowledge sub message  8 0  E E  F 0  Len  8 3  Data  C S  
Negative responses  
General reject  8 0  F 0  E E  0 3  7 F  Sid Req  1 0  C S  
Service not supported  8 0  F 0  E E  0 3  7 F  Sid Req  1 1  C S  
Sub function not supported  8 0  F 0  E E  0 3  7 F  Sid Req  1 2  C S  
Incorrect Message Length  8 0  F 0  E E  0 3  7 F  Sid Req  1 3  C S  
Conditions not correct or Request 
sequence error  80 F 0  E E  0 3  7 F  Sid Req  2 2  C S  
Request out of range  8 0  F 0  E E  0 3  7 F  Sid Req  3 1  C S  
Upload not accepted  8 0  F 0  E E  0 3  7 F  Sid Req  5 0  C S  
Response pending  8 0  F 0  E E  0 3  7 F  Sid Req  7 8  C S  
Data not available  8 0  F 0  E E  0 3  7 F  Sid Req  F A  C S  
Bemærk:  
— Sid Req = Sid for den tilsvarende anmodning.  
— TREP = TRTP for den tilsvarende anmodning.  
— Mørke celler angiver, at intet overføres.  
— Betegnelsen upload (set fra IDE-enheden) anvendes for kompati ­
bilitet med nøgleordsprotokollen (ISO 14229). Betydningen er de n 
samme som af dataoverførsel (set fra køretøjsenheden).  
— Eventuelle 2-byte-delmeddelelsestællere er ikke vist i denne tabel.  
— »Slot« er kortpladsnummeret — enten »1« (kort i førerens kort ­
plads) eller »2« (kort i medchaufførens kortplads).  
— Er kortpladsnummeret ikke angivet, skal køretøjsenheden vælge  
kortplads 1, hvis et kort er sat i denne plads, mens den kun sk al 
vælge kortplads 2, hvis brugeren vælger dette.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 333  
— TRTP 24 anvendes til anmodninger om overførsel af køretøjs­
enhedsdata af anden generation, version 1 og version 2.  
— TRTP 00, 31, 32, 33 og 35 anvendes til anmodninger om over­
førsel af køretøjsenhedsdata af anden generation, version 2.  
— TRTP 21, 22, 23 og 25 anvendes til anmodninger om overførsel af 
køretøjsenhedsdata af anden generation, version 1.  
— TRTP 01 til 05 anvendes til anmodninger om overførsel af køre ­
tøjsenhedsdata af første generation. De accepteres eventuelt af  køre­
tøjsenheder af anden generation, men kun når førerkontrollen 
udføres af en kontrolmyndighed uden for EU under anvendelse af 
et kontrolkort af første generation.  
— TRTP 11 til 1F er reserveret til fabrikantspecifikke overførs els­
anmodninger.  
▼B 
2.2.2.1 S t a r t C o m m u n i c a t i o n R e q u e s t ( S I  D 8 1 )  
DDP_005 Denne meddelelse afgives af IDE-enheden for at etablere  en 
kommunikationsforbindelse med køretøjsenheden. Den 
indledende kommunikation udføres altid ved 9 600 baud 
(indtil transmissionshastigheden til sidst ændres ved hjælp 
af de pågældende link-kontroltjenester).  
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 Denne meddelelse afgives af IDE-enheden som positivt sv ar 
på anmodning om at begynde kommunikation. Den inde­
holder de to nøglebytes »EA« »8F«, som angiver, at 
enheden understøtter protokollen, og hovedet indeholder 
oplysninger om destination, kilde og længde.  
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 IDE-enheden sender denne meddelelse for at anmode om en  
ny diagnosesession med køretøjsenheden. Delfunktionen 
»default session« (81 Hex) angiver, at der skal åbnes en 
standarddiagnosesession.  
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 Denne meddelelse afgives af køretøjsenheden som positiv t 
svar på anmodning om diagnosesession.  
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 Link Control Service anvendes af IDE-enheden til at ind lede 
en ændring i transmissionshastigheden. Dette sker i to trin. I 
første trin foreslår IDE-enheden en ændring i transmissions­
hastigheden. Ved modtagelse af et positivt svar fra køretøjs­
enheden afgiver IDE-enheden en bekræftelse på den 
ændrede transmissionshastighed til køretøjsenheden (andet 
trin). IDE-enheden skifter derefter til den nye transmissions­
hastighed. Efter modtagelse af bekræftelsen skifter køretøjs­
enheden til den nye transmissionshastighed.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 334  
2.2.2.6 L i n k C o n t r o l P o s i t i v e R e s p o n s e (  S I D C 7 )  
DDP_053 Link Control Positive response angives af køretøjsenhed en 
som svar på en anmodning til linkkontroltjenesten (første 
trin). Bemærk, at der ikke svares på bekræftelsen af anmod­
ningen (trin to).  
2.2.2.7 R e q u e s t U p l o a d ( S I D 3 5 )  
DDP_009 Request Upload afgives af IDE-enheden for over for køre ­
tøjsenheden at anmode om en dataoverførsel. For at opfylde 
kravene i ISO 14229 indgår der data om adresse, størrelse 
og format af de ønskede data. Da disse ikke kendes af 
IDE-enheden før overførslen, sættes lageradressen til 0, 
formatet til ukrypteret og lagerstørrelsen til maksimum.  
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 Positive Response Request Upload sendes af køretøjs­
enheden for at fortælle IDE-enheden, at køretøjsenheden 
er klar til at overføre data. For at opfylde kravene i 
ISO14229 indeholder den positive svarmeddelelse data, 
som fortæller IDE-enheden, at yderligere meddelelser med 
positivt svar på dataoverførsel vil indeholde maksimalt 00FF 
hex byte.  
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 Transfer Data Request sendes af IDE-enheden for over fo r 
køretøjsenheden at specificere den type data, som skal over­
føres. Overførslens type angives af en parameter for anmod­
ning om dataoverførsel (TRTP) på én byte.  
▼M3 
Der er syv typer af dataoverførsel. For overførsel af køre­
tøjsenhedsdata kan der anvendes to forskellige TRTP- 
værdier for hver overførselstype:  
Dataoverførselstype  TRTP-værdi for overførsel 
af køretøjsenhedsdata af første 
generation  TRTP-værdi for overførsel 
af køretøjsenhedsdata af anden 
generation, version 1  TRTP-værdi for overførsel 
af køretøjsenhedsdata af anden 
generation, version 2  
Download interface version  (ikke anvendt)  (ikke anvendt)  0 0  
Overview  0 1  2 1  3 1  
Aktiviteter på en nærmere 
angivet dato  02 2 2  3 2  
Hændelser og fejl  0 3  2 3  3 3  
Detaljeret hastighed  0 4  2 4  2 4  
Tekniske data  0 5  2 5  3 5  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 335  
Dataoverførsels­
type TRTP-værdi  
Overførsel af 
data fra kort  06 
▼M3 
DDP_054 IDE-enheden skal obligatorisk anmode om oversigt over 
dataoverførsel (TRTP 01, 21 eller 31) under en dataover­
førselssession, da det kun på denne måde kan sikres, at 
køretøjsenhedens certifikater registreres i den overførte fil 
(så der er mulighed for verifikation af en digital underskrift) . 
I det tredje tilfælde (TRTP 02, 22 eller 32) er det i meddelels en overfør 
data angivet, hvilken kalenderdag (TimeReal format) der skal ov er­
føres.  
▼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 Positive Response Transfer Data afgives af køretøjsenhe den 
som svar på Transfer Data Request. Meddelelsen indeholder 
de anmodede data med en parameter for svar på overførsel 
(Transfer Response Parameter — TREP) svarende til 
anmodningens TRTP.  
▼M3 
DDP_055 I første tilfælde (TREP 01, 21 eller 31) vil køretøjsen heden 
sende data, som hjælper IDE-operatøren til at vælge de data, 
som han yderligere vil overføre. Denne meddelelse inde­
holder følgende oplysninger:  
▼M1 
— sikkerhedscertifikater  
— identifikation af køretøjer  
— køretøjsenhedens aktuelle dato og klokkeslæt  
— mindste og største dato, som kan overføres (data fra 
køretøjsenhed)  
— angivelse af kort, som er isat i køretøjsenheden  
— tidligere dataoverførsler til en virksomhed  
— virksomhedslåse  
— tidligere kontroller.  
▼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 Request Transfer Exit afgives af IDE-enheden for at for tælle 
køretøjsenheden, at dataoverførselssessionen er slut.  
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 Positive Response Request Transfer Exit afgives af køre tøjs­
enheden for at kvittere for Request Transfer Exit.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 336  
2.2.2.13 S t o p C o m m u n i c a t i o n R e q u e s t ( S I D 8 2 )  
DDP_015 Stop Communication Request afgives af IDE-enheden for a t 
afbryde kommunikationsforbindelsen til køretøjsenheden.  
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 Positive Response Stop Communication afgives af køretøj s­
enheden for at kvittere for 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 Acknowledge Sub Message afgives af IDE-enheden for at 
bekræfte de enkelte dele af en meddelelse, der overføres 
som flere delmeddelelser. Datafeltet indeholder den SID, 
som er modtaget fra køretøjsenheden, og en 2-byte-kode 
som følger:  
— MsgC + 1 kvitterer for korrekt modtagelse af delmedde­
lelse nummer MsgC.  
Anmodning fra IDE-enheden til køretøjsenheden om at 
sende næste delmeddelelse.  
— MsgC angiver, at der er en fejl ved modtagelse af 
delmeddelelse nummer MsgC.  
Anmodning fra IDE-enheden til køretøjsenheden om at 
sende delmeddelelsen igen.  
— FFFF anmoder om afslutning af meddelelsen.  
Dette kan af IDE-enheden anvendes til at afslutte over­
førslen af meddelelsen fra køretøjsenheden uanset grund.  
For den afsluttende delmeddelelse i en meddelelse (LEN 
byte < 255) kan der kvitteres med enhver af disse koder, 
eller kvittering kan undlades.  
Svar fra køretøjsenheden består af flere delmeddelelser og 
kan være:  
— Positive Response Transfer Data (SID 76)  
2.2.2.16 N e g a t i v e R e s p o n s e ( S I D 7 F )  
DDP_018 Som svar på ovennævnte anmodninger sender køretøjs­
enheden Negative Response, når køretøjsenheden ikke kan 
imødekomme anmodningen. Meddelelsens datafelter inde­
holder svarets SID (7F), anmodningens SID og en kode, 
som angiver begrundelsen for det negative svar. Følgende 
koder er til rådighed:  
— 10 generel afvisning  
Operationen kan ikke gennemføres af grunde, som ikke 
er omfattet af nedenstående.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 337  
— 11 tjeneste ikke understøttet  
Anmodningens SID er ikke blevet forstået.  
— 12 delfunktion understøttes ikke  
Anmodningens DS_ eller TRTP forstås ikke, eller der er 
ikke flere delmeddelelser at overføre.  
— 13 ukorrekt meddelelseslængde  
Længden af den modtagne meddelelse er forkert.  
— 22 ukorrekte betingelser eller fejl i anmodningssekvens  
Den anmodede tjeneste er ikke aktiv eller sekvensen af 
anmodningsmeddelelsen ukorrekt.  
— 31 Anmodning uden for gyldighedsområde  
Posten med anmodningens parametre (datafelt) er 
ugyldig.  
— 50 upload ikke accepteret  
Anmodningen kan ikke efterkommes (køretøjsenhed 
ikke i korrekt driftstilstand, eller intern fejl i køretøjs­
enhed).  
— 78 svar uafgjort  
Den anmodede operation kan ikke gennemføres i tide, 
og køretøjsenheden er ikke klar til at modtage endnu en 
anmodning.  
▼M1 
— FA-data foreligger ikke  
Dataobjektet for en anmodning om dataoverførsel findes 
ikke i køretøjsenheden (f.eks. hvis der ikke er isat noget 
kort, eller der er anmodet om overførsel af køretøjs­
enhedsdata af første generation, uden for rammerne af 
en førerkontrol udført af en kontrolmyndighed uden for 
EU). 
▼B 
2.2.3  Meddelelsesstrøm  
En typisk meddelelsesstrøm ved en normal dataoverførselsprocedu re er 
følgende:  
IDE V U  
Start Communication Request  ⇨ 
⇦  Positive Response  
Start Diagnostic Service Request  ⇨ 
⇦  Positive Response  
Request Upload  ⇨ 
⇦  Positive Response  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 338  
IDE V U  
Transfer Data Request Overview  ⇨ 
⇦  Positive Response  
Transfer Data Request #2  ⇨ 
⇦  Positive Response #1  
Acknowledge Sub Message #1  ⇨ 
⇦  Positive Response #2  
Acknowledge Sub Message #2  ⇨ 
⇦  Positive Response #m  
Acknowledge Sub Message #m  ⇨ 
⇦  Positive Response (Data Field<255 Bytes)  
Acknowledge Sub Message (optional)  ⇨  
… 
Transfer Data Request #n  ⇨ 
⇦  Positive Response  
Request Transfer Exit  ⇨ 
⇦  Positive Response  
Stop Communication Request  ⇨ 
⇦  Positive Response  
2.2.4  Synkronisering  
DDP_019  Under normal drift er tidsparametrene i følgende figur relevan te: 
Figur 1  
Meddelelsesstrøm, synkronisering
  
Hvor:  
P1 = Tidsrum, som adskiller bytes for svar fra køretøjs­
enhed.  
P2 = Tid fra slutning af IDE-enhedens anmodning til start 
på køretøjsenhedens svar, eller fra slutning af IDE- 
enhedens kvittering til start på køretøjsenhedens 
næste svar.  
P3 = Tid fra slutning af køretøjsenhedens svar til start på 
ny anmodning fra IDE-enheden, eller fra slutningen af 
køretøjsenhedens svar til start på IDE-enhedens kvit­
tering, eller fra slutningen af IDE-enhedens anmod­
ning til start på ny anmodning fra IDE-enheden, hvis 
køretøjsenheden ikke svarer.  
P4 = Tidsrum, der adskiller bytes i anmodning fra IDE- 
enheden.  
P5 = Forlænget P3 ved overførsel fra kort.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 339  
Tilladte værdier af tidsparametrene er angivet i følgende 
tabel (det udvidede KWP-tidsparametersæt, som anvendes 
ved fysisk adressering for at gøre kommunikationen hurti­
gere).  
Synkroniseringsparameter  Nedre grænseværdi 
(ms) Øvre grænseværdi 
(ms) 
P1 0  2 0  
P2 2 0  1 000 (*)  
P3 1 0  5 000  
P4 5  2 0  
P5 1 0  20 minutter  
(*) Hvis køretøjsenheden reagerer med et Negative Response, der  indeholder en kode med betydningen »anmod­ 
ning modtaget som foreskrevet, svar afventes«, gælder den samme  øvre grænseværdi for denne værdi som 
for P3.  
2.2.5  Fejlhåndtering  
Indtræffer der en fejl under meddelelsesudvekslingen, ændres me dde­
lelsesstrømmene alt efter, hvilket udstyr der har fundet fejlen , og den 
meddelelse, som har udløst fejlen.  
I figur 2 og 3 vises fejlhåndteringsprocedurer for hhv. køretøj senhed og 
IDE-enhed.  
2.2.5.1 F a s e n B e g y n d k o m m u n i k a t i o n  
DDP_020 Hvis IDE-enheden finder en fejl i start kommunikation- 
fasen, enten i synkroniseringen eller i bitstrømmen, venter 
den i et tidsrum af P3min, før den igen afgiver anmod­
ningen.  
DDP_021 Hvis køretøjsenheden finder en fejl i den afgivne sekve ns 
fra IDE-enheden, skal den intet svar sende og vente på 
endnu en anmodning om start på kommunikation inden 
for et tidsrum af P3max.  
2.2.5.2 K o m m u n i k a t i o n s f a s e n  
Der kan defineres to forskellige fejlhåndteringsområder:  
1. Køretøjsenheden konstaterer en fejl i dataoverførslen for 
IDE-enheden  
DDP_022 For hver modtaget meddelelse skal køretøjsenheden finde  
eventuelle synkroniseringsfejl, fejl ved byteformat (f.eks. 
fejl ved start- og stopbit) og rammefejl (forkert antal 
bytes modtaget, forkert kontrolsumbyte).  
DDP_023 Hvis køretøjsenheden finder en af ovennævnte fejl, 
afgiver den intet svar og ignorerer den modtagne 
meddelelse.  
DDP_024 Køretøjsenheden kan finde andre fejl i den modtagne 
meddelelses format eller indhold (f.eks. at meddelelsen 
ikke understøttes), uanset om meddelelsen opfylder 
forskrifterne for længde og kontrolsum. I så fald skal 
køretøjsenheden svare IDE-enheden med et Negative 
Response med angivelse af fejlens art.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 340  
Figur 2  
Håndtering af fejl ved køretøjsenhed
  
▼B 
2. IDE-enheden registrerer en dataoverførselsfejl ved køretøjs ­
enheden  
DDP_025 For hver modtaget meddelelse skal IDE-enheden finde 
eventuelle synkroniseringsfejl, fejl ved byteformat, 
(f.eks. fejl ved start- og stopbit) og rammefejl (forkert 
antal bytes modtaget, forkert kontrolsumbyte).  
DDP_026 IDE-enheden skal finde sekvensfejl, f.eks. ukorrekt 
forøgelse af tællerne for delmeddelelser i successivt 
modtagne meddelelser.  
DDP_027 Hvis IDE-enheden konstaterer en fejl, eller der ikke ko m 
svar fra køretøjsenheden inden for et tidsrum af P2max, 
vil anmodningen blive sendt igen, til den er sendt i alt 
højst tre gange. Hvad angår denne fejlfinding, vil en 
kvittering for delmeddelelse blive betragtet som en 
anmodning til køretøjsenheden.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 341  
DDP_028 IDE-enheden skal vente mindst P3min, før den begynder 
hver dataoverførsel. Venteperioden måles fra seneste 
beregnede forekomst af en stopbit, efter at fejlen blev 
konstateret.  
Figur 3  
Håndtering af fejl ved IDE-enhed
  
2.2.6  Svarmeddelelsens indhold  
Dette afsnit angiver indholdet af datafelterne i de forskellige  positive 
svarmeddelelser.  
Dataelementerne er defineret i tillæg 1 (Dataordliste).  
Bemærk: For dataoverførsel ved brug af udstyr af anden generati on 
gælder det, at hvert dataelement på øverste niveau repræsentere s af et 
array med poster (record array), også selv om det kun indeholde r én 
post. Et record array indledes med et hoved. Dette hoved angive r post­
typen, poststørrelsen og antallet af poster. Record arrays navn gives 
»…RecordArray« (med hoved) som i følgende tabeller.  
▼M3 
2.2.6.1 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  D o w n l o a d I n t e r ­
f a c e V e r s i o n ( P o s i t i v t S v a r D a t a o v e r  f ø r s e l , 
V e r s i o n a f D o w n l o a d - I n t e r f a c e )  
DDP_028a Datafeltet i meddelelsen »Positive Response Transfer D ata 
Download Interface Version« skal indeholde følgende data 
i følgende rækkefølge under SID 76 Hex, TREP 00 Hex:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 342  
Datastruktur, anden generation, version 2 (TREP 00 Hex)  
Dataelement  Bemærkning  
DownloadInterfaceVersion  Generering og version af køretøjsenheden: 02,02 
Hex for anden generation, version 2. 
Understøttes ikke af køretøjsenheder af første 
generation og anden generation, version 1, som 
give et negativt svar (Delfunktion understøttes 
ikke, se DDP_018)  
2.2.6.2 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  O v e r v i e w ( P o s i ­
t i v t S v a r D a t a o v e r f ø r s e l , O v e r s i g t )  
DDP_029 Datafeltet i meddelelsen »Positive Response Transfer Da ta 
Overview« skal bære følgende data i følgende rækkefølge 
under SID 76 Hex, TREP 01, 21 eller 31 Hex og med 
passende opdeling i delmeddelelser og behørig tælling:  
Datastruktur, første generation (TREP 01 Hex)  
Dataelement  Bemærkning  
MemberStateCertificate  Køretøjsenheders sikkerhedsattester  
VUCertificate  
VehicleIdentificationNumber  Identifikation af køretøj  
VehicleRegistrationIdentification  
CurrentDateTime  Køretøjsenhedens aktuelle dato og klokkeslæt  
VuDownloadablePeriod  Periode, som kan overføres  
CardSlotsStatus  Type af kort, som er isat køretøjsenheden  
VuDownloadActivityData  Foregående overførsel fra køretøjsenheden  
VuCompanyLocksData  Alle gemte virksomhedslåse. Hvis feltet står tomt, 
sendes kun noOfLocks = 0.  
VuControlActivityData  Alle kontrolposter, der er gemt i køretøjsenheden. 
Hvis feltet står tomt, sendes kun noOfControls = 0.  
Signature  RSA-underskrift for alle data (undtagen attester) 
fra VehicleIdentificationNumber ned til sidste 
byte i sidste VuControlActivityData.  
Datastruktur, anden generation, version 1 (TREP 21 Hex)  
Dataelement  Bemærkning  
MemberStateCertificateRecordArray  Attest fra medlemsstaten  
VUCertificateRecordArray  Attest for køretøjsenheden  
VehicleIdentificationNumberRecordArray  Identifikation af køretøj  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 343  
Dataelement  Bemærkning  
VehicleRegistrationIdentificationRecordArray  Køretøjets registreringsnummer  
CurrentDateTimeRecordArray  Køretøjsenhedens aktuelle dato og klokkeslæt  
VuDownloadablePeriodRecordArray  Periode, som kan overføres  
CardSlotsStatusRecordArray  Type af kort, som er isat køretøjsenheden  
VuDownloadActivityDataRecordArray  Foregående overførsel fra køretøjsenheden  
VuCompanyLocksRecordArray  Alle gemte virksomhedslåse. Hvis feltet står tomt, 
sendes et array-hoved med noOfRecords = 0  
VuControlActivityRecordArray  Alle kontrolposter, der er gemt i køretøjsenheden. 
Hvis feltet står tomt, sendes et array-hoved med 
noOfRecords = 0  
SignatureRecordArray  ECC-underskrift for alle foregående data 
undtagen attesterne.  
Datastruktur, anden generation, version 2 (TREP 31 Hex)  
Dataelement  Bemærkning  
MemberStateCertificateRecordArray  Attest fra medlemsstaten  
VUCertificateRecordArray  Attest for køretøjsenheden  
VehicleIdentificationNumberRecordArray  Identifikation af køretøj  
VehicleRegistrationNumberRecordArray  Køretøjets registreringsnummer  
CurrentDateTimeRecordArray  Køretøjsenhedens aktuelle dato og klokkeslæt  
VuDownloadablePeriodRecordArray  Periode, som kan overføres  
CardSlotsStatusRecordArray  Type af kort, som er isat køretøjsenheden  
VuDownloadActivityDataRecordArray  Foregående overførsel fra køretøjsenheden  
VuCompanyLocksRecordArray  Alle gemte virksomhedslåse. Hvis feltet står tomt, 
sendes et array-hoved med noOfRecords = 0  
VuControlActivityRecordArray  Alle kontrolposter, der er gemt i køretøjsenheden. 
Hvis feltet står tomt, sendes et array-hoved med 
noOfRecords = 0  
SignatureRecordArray  ECC-underskrift for alle foregående data 
undtagen attesterne.  
2.2.6.3 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  A c t i v i t i e s ( P o s i ­
t i v t S v a r D a t a o v e r f ø r s e l , A k t i v i t e t  e r ) 
DDP_030 Datafeltet i meddelelsen »Positive Response Transfer Da ta 
Activities« skal bære følgende data i følgende rækkefølge 
under SID 76 Hex, TREP 02, 22 eller 32 Hex og med 
passende opdeling i delmeddelelser og behørig tælling:  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 344  
Datastruktur, første generation (TREP 02 Hex)  
Dataelement  Bemærkning  
TimeReal  Dato for overført dag  
OdometerValueMidnight  Kilometertæller ved afslutning af overført dag  
VuCardIWData  Data om cyklusser med isætning/udtagning af kort. 
— Hvis dette felt ikke indeholder nogen tilgængelige 
data, sendes kun noOfVuCardIWRecords = 0. 
— Hvis en VuCardIWRecord-post overskrider 00:00 
(kort isat den foregående dag) eller 24:00 (kort 
udtaget den følgende dag), skal den vises fuldt ud 
inden for de to pågældende dage.  
VuActivityDailyData  Kortpladsers status kl. 00:00 og aktivitetsskift, der er 
registreret for den overførte dag.  
VuPlaceDailyWorkPeriodData  Data vedrørende steder, der er registreret for den over­
førte dag. Hvis feltet står tomt, sendes kun noOfPlace­
Records = 0.  
VuSpecificConditionData  Data vedrørende særlige omstændigheder, der er regi­
streret for den overførte dag. Hvis feltet står tomt, 
sendes kun noOfSpecificConditionRecords = 0.  
Signature  RSA-underskrift for alle data fra TimeReal ned til sidste 
byte i sidste post vedrørende særlige omstændigheder.  
Datastruktur, anden generation, version 1 (TREP 22 Hex)  
Dataelement  Bemærkning  
DateOfDayDownloadedRecordArray  Dato for overført dag  
OdometerValueMidnightRecordArray  Kilometertæller ved afslutning af overført dag  
VuCardIWRecordArray  Data om cyklusser med isætning/udtagning af kort. 
— Hvis dette felt ikke indeholder nogen tilgængelige 
data, sendes et array-hoved med noOfRecords = 0. 
— Hvis en VuCardIWRecord-post overskrider 00:00 
(kort isat den foregående dag) eller 24:00 (kort 
udtaget den følgende dag), skal den vises fuldt ud 
inden for de to pågældende dage.  
VuActivityDailyRecordArray  Kortpladsers status kl. 00:00 og aktivitetsskift, der er 
registreret for den overførte dag.  
VuPlaceDailyWorkPeriodRecordArray  Data vedrørende steder, der er registreret for den over­
førte dag. Hvis feltet står tomt, sendes et array-hoved 
med noOfRecords = 0.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 345  
Dataelement  Bemærkning  
VuGNSSADRecordArray  Køretøjets GNSS-positioner, når den kumulerede 
køretid når op på et multiplum af tre timer. Hvis feltet 
står tomt, sendes et array-hoved med noOfRecords = 0.  
VuSpecificConditionRecordArray  Data vedrørende særlige omstændigheder, der er regi­
streret for den overførte dag. Hvis feltet står tomt, 
sendes et array-hoved med noOfRecords = 0.  
SignatureRecordArray  ECC-underskrift for alle foregående data.  
Datastruktur, anden generation, version 2 (TREP 32 Hex)  
Dataelement  Bemærkning  
DateOfDayDownloadedRecordArray  Dato for overført dag  
OdometerValueMidnightRecordArray  Kilometertæller ved afslutning af overført dag  
VuCardIWRecordArray  Data om cyklusser med isætning/udtagning af kort. 
— Hvis dette felt ikke indeholder nogen tilgængelige 
data, sendes et array-hoved med noOfRecords = 0. 
— Hvis en VuCardIWRecord-post overskrider 00:00 
(kort isat den foregående dag) eller 24:00 (kort 
udtaget den følgende dag), skal den vises fuldt ud 
inden for de to pågældende dage.  
VuActivityDailyRecordArray  Kortpladsers status kl. 00:00 og aktivitetsskift, der er 
registreret for den overførte dag.  
VuPlaceDailyWorkPeriodRecordArray  Data vedrørende steder, der er registreret for den over­
førte dag. Hvis feltet står tomt, sendes et array-hoved 
med noOfRecords = 0.  
VuGNSSADRecordArray  Køretøjets GNSS-positioner, når den kumulerede 
køretid når op på et multiplum af tre timer. Hvis feltet 
står tomt, sendes et array-hoved med noOfRecords = 0.  
VuSpecificConditionRecordArray  Data vedrørende særlige omstændigheder, der er regi­
streret for den overførte dag. Hvis feltet står tomt, 
sendes et array-hoved med noOfRecords = 0.  
VuBorderCrossingRecordArray  Grænsepassager for den overførte dag. Hvis feltet står 
tomt, sendes et array-hoved med noOfRecords = 0.  
VuLoadUnloadRecordArray  Laste-/losseoperationer for den overførte dag. Hvis feltet 
står tomt, sendes et array-hoved med noOfRecords = 0.  
SignatureRecordArray  ECC-underskrift for alle foregående data.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 346  
2.2.6.4 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  E v e n t s a n d F a u l t s 
( P o s i t i v t S v a r D a t a o v e r f ø r s e l , H æ n d  e l s e r o g F e j l )  
DDP_031 Datafeltet i meddelelsen »Positive Response Transfer Da ta 
Events and Faults« skal indeholde følgende data i følgende 
rækkefølge under SID 76 Hex og TREP 03, 23 eller 33 
Hex, med passende opdeling i delmeddelelser og behørig 
tælling:  
Datastruktur, første generation (TREP 03 Hex)  
Dataelement  Bemærkning  
VuFaultData  Alle fejl, som er gemt eller igangværende på køretøjs­
enheden. 
Hvis feltet står tomt, sendes kun noOfVuFaults = 0.  
VuEventData  All hændelser (undtagen overskridelse af tilladt 
hastighed), som er gemt eller igangværende på køretøjs­
enheden. 
Hvis feltet står tomt, sendes kun noOfVuEvents = 0.  
VuOverSpeedingControlData  Data vedrørende sidste kontrol med overskridelse af 
tilladt hastighed (standardværdi i mangel af data).  
VuOverSpeedingEventData  Alle hændelser med overskridelse af tilladt hastighed, 
der er gemt i køretøjsenheden. 
Hvis feltet står tomt, sendes kun noOfVuOverSpeed­
ingEvents = 0.  
VuTimeAdjustmentData  Alle tidsjusteringshændelser, der er gemt i køretøjs­
enheden (uden for rammerne af en komplet kalibrering). 
Hvis feltet står tomt, sendes kun noOfVuTimeAdjRe­
cords = 0.  
Signature  RSA-underskrift for alle data fra noOfVuFaults ned til 
sidste byte i sidste tidsjusteringspost.  
Datastruktur, anden generation, version 1 (TREP 23 Hex)  
Dataelement  Bemærkning  
VuFaultRecordArray  Alle fejl, som er gemt eller igangværende på køretøjs­
enheden. 
Hvis feltet står tomt, sendes et array-hoved med 
noOfRecords = 0.  
VuEventRecordArray  All hændelser (undtagen overskridelse af tilladt 
hastighed), som er gemt eller igangværende på køretøjs­
enheden. 
Hvis feltet står tomt, sendes et array-hoved med 
noOfRecords = 0.  
VuOverSpeedingControlDataRecordArray  Data vedrørende sidste kontrol med overskridelse af 
tilladt hastighed (standardværdi i mangel af data).  
VuOverSpeedingEventRecordArray  Alle hændelser med overskridelse af tilladt hastighed, 
der er gemt i køretøjsenheden. 
Hvis feltet står tomt, sendes et array-hoved med 
noOfRecords = 0.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 347  
Dataelement  Bemærkning  
VuTimeAdjustmentRecordArray  Alle tidsjusteringshændelser, der er gemt i køretøjs­
enheden (uden for rammerne af en komplet kalibrering). 
Hvis feltet står tomt, sendes et array-hoved med 
noOfRecords = 0.  
SignatureRecordArray  ECC-underskrift for alle foregående data.  
Datastruktur, anden generation, version 2 (TREP 33 Hex)  
Dataelement  Bemærkning  
VuFaultRecordArray  Alle fejl, som er gemt eller igangværende på køretøjs­
enheden. 
Hvis feltet står tomt, sendes et array-hoved med 
noOfRecords = 0.  
VuEventRecordArray  All hændelser (undtagen overskridelse af tilladt 
hastighed), som er gemt eller igangværende på køretøjs­
enheden. 
Hvis feltet står tomt, sendes et array-hoved med 
noOfRecords = 0.  
VuOverSpeedingControlDataRecordArray  Data vedrørende sidste kontrol med overskridelse af 
tilladt hastighed (standardværdi i mangel af data).  
VuOverSpeedingEventRecordArray  Alle hændelser med overskridelse af tilladt hastighed, 
der er gemt i køretøjsenheden. 
Hvis feltet står tomt, sendes et array-hoved med 
noOfRecords = 0.  
VuTimeAdjustmentRecordArray  Alle tidsjusteringshændelser, der er gemt i køretøjs­
enheden (uden for rammerne af en komplet kalibrering). 
Hvis feltet står tomt, sendes et array-hoved med 
noOfRecords = 0.  
SignatureRecordArray  ECC-underskrift for alle foregående data.  
2.2.6.5 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  D e t a i l e d S p e e d  
DDP_032 Datafeltet i meddelelsen »Positive Response Transfer Da ta 
Detailed Speed« skal indeholde følgende data i følgende 
rækkefølge under SID 76 Hex og TREP 04 eller 24 Hex, 
med passende opdeling i delmeddelelser og behørig tælling:  
Datastruktur, første generation (TREP 04 Hex)  
Dataelement  Bemærkning  
VuDetailedSpeedData  Alle detaljerede hastighedsdata, der er gemt i køretøjs­
enheden (én hastighedsblok pr. minut, i hvilket køretøjet 
har bevæget sig). 
60 hastighedsværdier pr. minut (én pr. sekund).  
Signature  RSA-underskrift for alle data fra noOfSpeedBlocks ned 
til sidste byte i sidste hastighedsblok.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 348  
Datastruktur, anden generation (TREP 24 Hex)  
Dataelement  Bemærkning  
VuDetailedSpeedBlockRecordArray  Alle detaljerede hastighedsdata, der er gemt i køretøjs­
enheden (én hastighedsblok pr. minut, i hvilket køretøjet 
har bevæget sig). 
60 hastighedsværdier pr. minut (én pr. sekund).  
SignatureRecordArray  ECC-underskrift for alle foregående data.  
2.2.6.6 P o s i t i v e R e s p o n s e T r a n s f e r D a t a  T e c h n i c a l D a t a  
DDP_033 Datafeltet i meddelelsen »Positive Response Transfer Da ta 
Technical Data« skal indeholde følgende data i følgende 
rækkefølge under SID 76 Hex og TREP 05, 25 eller 35 
Hex med passende opdeling i delmeddelelser og behørig 
tælling:  
Datastruktur, første generation (TREP 05 Hex)  
Dataelement  Bemærkning  
VuIdentification  
SensorPaired  
VuCalibrationData  Alle kalibreringsposter, der er gemt i køretøjsenheden.  
Signature  RSA-underskrift for alle data fra vuManufacturerName 
ned til sidste byte i sidste VuCalibrationRecord.  
Datastruktur, anden generation, version 1 (TREP 25 Hex)  
Dataelement  Bemærkning  
VuIdentificationRecordArray  
VuSensorPairedRecordArray  Alle bevægelsessensorparringer, der er gemt i køretøjs­
enheden  
VuSensorExternalGNSSCoupledRecor­
dArray  Alle koblinger med det eksterne GNSS-udstyr, der er 
gemt i køretøjsenheden  
VuCalibrationRecordArray  Alle kalibreringsposter, der er gemt i køretøjsenheden.  
VuCardRecordArray  Alle data om isætning af kort, der er gemt i køretøjs­
enheden.  
VuITSConsentRecordArray  
VuPowerSupplyInterruptionRecordArray  
SignatureRecordArray  ECC-underskrift for alle foregående data.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 349  
Datastruktur, anden generation, version 2 (TREP 35 Hex)  
Dataelement  Bemærkning  
VuIdentificationRecordArray  
VuSensorPairedRecordArray  Alle bevægelsessensorparringer, der er gemt i køretøjs­
enheden  
VuSensorExternalGNSSCoupledRecor­
dArray  Alle koblinger med det eksterne GNSS-udstyr, der er 
gemt i køretøjsenheden  
VuCalibrationRecordArray  Alle kalibreringsposter, der er gemt i køretøjsenheden.  
VuCardRecordArray  Alle data om isætning af kort, der er gemt i køretøjs­
enheden.  
VuITSConsentRecordArray  
VuPowerSupplyInterruptionRecordArray  
SignatureRecordArray  ECC-underskrift for alle foregående data.  
▼B 
2.3. Lagring af fil på eksternt lagermedium  
DDP_034 Når en dataoverførselssession har omfattet overførsel a f data 
fra en køretøjsenhed, skal IDE-enheden i én fysisk fil 
gemme alle data, som er modtaget fra køretøjsenheden 
under overførselssessionen i meddelelser om Positive 
Response Transfer Data. Data, som gemmes, omfatter 
ikke meddelelsers hoved, delmeddelelsestællere, tomme 
delmeddelelser og kontrolsummer, men indbefatter SID og 
TREP (af første delmeddelelse kun, hvis der er flere 
delmeddelelser).  
3. PROTOKOL FOR OVERFØRSEL AF TAKOGRAFKORT  
3.1. Anvendelsesområde  
Dette afsnit beskriver direkte overførsel af data fra et takogr afkort til en 
IDE-enhed. IDE-elementet indgår ikke i det sikre miljø. Derfor udføres 
der ikke ægthedskontrol mellem kortet og IDE-enheden.  
3.2. Definitioner  
Overførselssession : Hver gang der finder en overførsel af chipkort­
data sted. Sessionen omfatter hele forløbet fra 
en kortlæser nulstiller chipkortet til deaktive­
ring af chipkortet (udtagning af kort eller 
næste isætning).  
Underskrevet datafil : En fil fra chipkortet. Filen overføres til kort­
læseren som almindelig tekst. På chipkortet 
bliver filen hashet og underskrevet, og under­
skriften overføres til kortlæseren.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 350  
3.3. Dataoverførsel af kort  
▼M3 
DDP_035 Overførsel af et takografkort omfatter følgende trin:  
— Overførsel af kortets fælles oplysninger i elementærfi­
lerne ICC og IC. Disse oplysninger er ikke obligatoriske 
og sikres ikke med digital underskrift.  
— For takografkort af første og anden generation  
— Overførsel af elementærfiler i den dedikerede fil 
Tachograph:  
— Overførsel af elementærfilerne Card_Certificate 
og CA_Certificate. Disse oplysninger sikres 
ikke med digital underskrift.  
Det er obligatorisk at overføre disse filer ved 
hver overførselssession.  
— Overførsel af applikationens øvrige elementær­
filer (i den dedikerede fil Tachograph) undtagen 
elementærfilen Card_Download. Disse oplys­
ninger sikres med en digital underskrift i 
henhold til tillæg 11 Fælles sikkerhedsmeka­
nismer, del A.  
— Ved hver overførselssession er det obligatorisk 
som minimum at overføre elementærfilerne 
Application_Identification og Identification.  
— Ved overførsel af et førerkort er det desuden 
obligatorisk at overføre følgende elementærfiler:  
Events_Data,  
Faults_Data,  
Driver_Activity_Data,  
Vehicles_Used,  
Places,  
Control_Activity_Data,  
Specific_Conditions.  
— Kun for takografkort af anden generation:  
— Undtagen når overførsel af et førerkort isat en køre­
tøjsenhed udføres under førerkontrol udført af en 
kontrolmyndighed uden for EU under anvendelse 
af et kontrolkort af første generation, overføres 
elementærfilerne i den dedikerede fil Tacho­
graph_G2:  
— Overførsel af elementærfilerne CardSignCertifi­
cate, CA_Certificate og Link_Certificate. Disse 
oplysninger sikres ikke med digital underskrift.  
— Det er obligatorisk at overføre disse filer ved 
hver overførselssession.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 351  
— Overførsel af applikationens øvrige elementær­
filer (i den dedikerede fil Tachograph_G2) 
undtagen elementærfilen Card_Download. Disse 
oplysninger sikres med en digital underskrift i 
henhold til tillæg 11 Fælles sikkerhedsmeka­
nismer, del B.  
— Ved hver overførselssession er det obligatorisk 
som minimum at overføre elementærfilerne 
Application_Identification, Application_Identifi­
cation_V2 (hvis den findes) og Identification.  
— Ved overførsel af et førerkort er det desuden 
obligatorisk at overføre følgende elementærfiler:  
Events_Data  
Faults_Data  
Driver_Activity_Data  
Vehicles_Used  
Places  
Control_Activity_Data  
Specific_Conditions  
VehicleUnits_Used  
GNSS_Places  
Places_Authentication, hvis den findes  
GNSS_Places_Authentication, hvis den findes  
Border_Crossings, hvis den findes  
Load_Unload_Operations, hvis den findes  
Load_Type_Entries, hvis den findes.  
— Ved overførsel af et førerkort opdateres datoen 
for LastCardDownload i elementærfilen 
Card_Download i den dedikerede fil Tachograph 
og den dedikerede fil Tachograph_G2, hvis det 
er relevant.  
— Ved overførsel af et værkstedskort nulstilles kali­
breringstælleren i elementærfilen Card_Download i 
den dedikerede fil Tachograph og den dedikerede 
fil Tachograph_G2, hvis det er relevant.  
— Ved overførsel af et værkstedskort skal elemen­
tærfilen Sensor_Installation_Data i den dedike­
rede fil Tachograph og den dedikerede fil Tacho­
graph_G2, hvis det er relevant, ikke overføres.  
▼B 
3.3.1  Initialiseringssekvens  
DDP_036 IDE-enheden skal indlede sekvensen som følger:  
Kort Retning  IDE-enhed/kortlæser  Betydning/bemærkninger  
⇦ Nulstilling af hardware  
ATR ⇨ 
Om ønsket kan man ved hjælp af PPS skifte til en højere 
transmissionshastighed, når blot denne understøttes af 
chipkortet.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 352  
3.3.2  Sekvens for ikke-underskrevne datafiler  
DDP_037  ►M1 Følgende sekvens anvendes til overførsel af elementærfi­
lerne ICC, IC, Card_Certificate (eller CardSignCertificate for den 
dedikerede fil Tachograph_G2), CA_Certificate og Link_Certifi­
cate (kun for den dedikerede fil Tachograph_G2): ◄  
Kort Retning  IDE-enhed/kortlæser  Betydning/bemærkninger  
⇦ Select File  Vælg ved filnavn  
OK ⇨ 
⇦ Read Binary  Indeholder filen flere data 
end svarende til bufferstør­
relsen af kortlæser eller kort, 
må kommandoen gentages, 
indtil hele filen er læst.  
Fildata 
OK ⇨ Gem data på eksternt lagerme­
dium  i overensstemmelse med  3.4 
Format for lagring af data  
Note 1:  Før valg af elementærfilen Card_Certificate (eller 
CardSignCertificate) skal takografapplikationen være valgt 
(vælges ved applikationsnavn).  
Note 2:  Valg og læsning af en fil kan også foretages i ét trin 
ved brug af en Read Binary-kommando med et kort id for 
elementærfilen.  
3.3.3  Sekvens for underskrevne datafiler  
DDP_038 Følgende sekvens anvendes til hver af de efterfølgende filer, 
som skal overføres med tilhørende underskrift:  
▼M1 
Kort Retn.  IDE-enhed/kortlæser  Betydning/bemærkninger
  
Select File  
OK
 
Perform Hash of File  — Beregner hash-værdien 
af den valgte fils dataind­
hold ved hjælp af den 
foreskrevne 
hash-algoritme i overens­
stemmelse med tillæg 11, 
del A eller B. Denne 
kommando er ikke en 
ISO-kommando.  
Beregn hashværdi af fil, 
og gem hashværdi 
midlertidigt  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 353  
Kort Retn.  IDE-enhed/kortlæser  Betydning/bemærkninger  
OK
 
Read Binary  Indeholder filen flere data 
end svarende til bufferstør­
relsen af kortlæser eller kort, 
må kommandoen gentages, 
indtil hele filen er læst.  
File Data 
OK
 Gem de modtagne data på 
eksternt lagermedium  i henhold til  3.4 Data storage 
format
  
PSO: Compute Digital 
Signature  
Udfør sikkerhedsope­
rationen »Compute 
Digital Signature« med 
anvendelse af den 
midlertidigt gemte 
hashværdi  
Signature 
OK
 Tilføj data til de data, som i 
forvejen er gemt på det 
eksterne lagermedium  i henhold til  3.4 Data storage 
format  
▼B 
Bemærk:  Valg og læsning af en fil kan også foretages i ét 
trin ved brug af en Read Binary-kommando med et kort id 
for elementærfilen. I dette tilfælde kan elementærfilen 
vælges og læses, før kommandoen Perform Hash of File 
udføres.  
3.3.4  Sekvens for nulstilling af kalibreringstæller  
DDP_039  Til nulstilling af
  
-tælleren i elementærfilen
  på et værk­
stedskort anvendes følgende sekvens:  
Kort Retn.  IDE-enhed/kortlæser  Betydning/bemærkninger  
⇦ Select File , elementærfilen 
Card_Download  Vælg ved filnavn  
OK ⇨ 
⇦ Update Binary  
NoOfCalibrationsSince­
Download = »00 00«  
nulstiller antal overfør­
sler fra kort  
OK ⇨ 
Bemærk:  Valg og opdatering af en fil kan også foretages i ét 
trin ved brug af en Update Binary-kommando med et kort id 
for elementærfilen.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 354  
3.4. Format for lagring af data  
3.4.1  Indledning  
DDP_040 De overførte data skal gemmes i overensstemmelse med 
følgende betingelser:  
— Data skal opbevares transparent. Dette indebærer, at 
byte-rækkefølgen såvel som bitrækkefølgen i den over­
førte byte skal forblive uændret ved overførslen.  
— Alle filer, der overføres fra kortet i løbet af en overfør­
selssession, gemmes i én fil på det eksterne lagerme­
dium.  
3.4.2  Filformat  
DDP_041 Filformatet er en sammenkædning af flere TLV-objekter.  
DDP_042 Etiketten for en elementærfil skal være filidentifikato ren 
med tilføjelsen »00«.  
DDP_043 Etiketten for en elementærfils underskrift skal være fi liden­
tifikatoren plus tilføjelsen »01«.  
DDP_044 Længden er en to byte-værdi. Værdien fastlægger antal 
bytes i feltet Værdi. Værdien »FF FF« i længdefeltet er 
forbeholdt fremtidig brug.  
DDP_045 Når en fil ikke overføres, må intet vedrørende filen ge mmes 
(ingen etiket og ingen nullængde).  
▼M1 
DDP_046 En underskrift skal gemmes som næste TLV-objekt direkte  
efter det TLV-objekt, som indeholder filens data.  
Definition  Betydning  Længde  
FID (2 bytes) »00«  Etiket for elementærfil 
(FID) i den dedikerede fil
  
eller for 
kortets fælles oplysninger  3 bytes  
FID (2 bytes) »01«  Etiket for underskrift af 
elementærfilen (FID) i den 
dedikerede fil
  3 bytes  
FID (2 bytes) »02«  Etiket for elementærfil 
(FID) i den dedikerede fil
  3 bytes  
FID (2 bytes) »03«  Etiket for underskrift af elem­
entærfilen (FID) i den dedike­
rede fil
  3 bytes  
xx xx  Længde af feltet Værdi  2 bytes  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 355  
Eksempel på data i en fil overført til eksternt lagermedium:  
Etiket  Længde  Værdi
  
— Data i elementærfilen ICC
  
— Data i elementærfilen Card_Certifi­
cate 
— ...
  
Data i elementærfilen
  
(i den dedikerede 
fil
 )
  
Underskrift af elementærfilen
  
(i den dedikerede 
fil
 )
  
Data i elementærfilen
  
(i den dedikerede 
fil
 )
  
Underskrift af elementærfilen
  
(i den dedikerede 
fil
 )  
▼B 
4. OVERFØRSEL AF TAKOGRAFKORT VIA KØRETØJSENHEDEN  
DDP_047 Køretøjsenheden skal gøre det muligt at overføre indhol det 
af et førerkort, som indsættes i en tilsluttet IDE-enhed.  
DDP_048 IDE-enheden sender meddelelsen Transfer Data Request 
Card Download til køretøjsenheden for at indlede denne 
arbejdstilstand (se 2.2.2.9).  
▼M1 
DDP_049 Førerkort af første generation: Data skal overføres ved  hjælp 
af dataoverførselsprotokollen for første generation, og over­
førte data skal have samme format som data, der overføres 
fra en køretøjsenhed af første generation.  
Førerkort af anden generation: Køretøjsenheden skal derefter 
overføre hele kortet fil for fil i overensstemmelse med proto­
kollen for overførsel af kort som fastlagt i punkt 3 og skal 
fremsende alle data, som er modtaget fra kortet, til 
IDE-enheden i det korrekte TLV-filformat (se 3.4.2) og 
indkapslet i en »Positive Response Transfer Data«-medde­
lelse. 
▼B 
DDP_050 IDE-enheden skal hente data fra meddelelsen »Positive 
Response Transfer Data« (efter fjernelse af alle hoveder, 
SID, TREP, delmeddelelsestællere og kontrolsummer) og 
gemme dem i én fysisk fil som beskrevet i punkt 2.3.  
DDP_051 Køretøjsenheden skal derefter i givet fald ajourføre fø rerkor­
tets
 -fil eller
  -fil.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 356  
Tillæg 8  
KALIBRERINGSPROTOKOL  
INDHOLDSFORTEGNELSE  
1. INDLEDNING  
2. TERMER, DEFINITIONER OG HENVISNINGER  
3. OVERSIGT OVER SERVICER  
3.1. Tilgængelige servicer  
3.2. Svarkoder  
4. KOMMUNIKATIONSSERVICER  
4.1. Servicen StartCommunication  
4.2. StopCommunication-service  
4.2.1 Beskrivelse af meddelelser  
4.2.2 Meddelelsesformat  
4.2.3 Parameterdefinition  
4.3. TesterPresent-service  
4.3.1 Beskrivelse af meddelelser  
4.3.2 Meddelelsesformat  
5. ADMINISTRATIONSSERVICER  
5.1. StartDiagnosticSession-service  
5.1.1 Beskrivelse af meddelelser  
5.1.2 Meddelelsesformat  
5.1.3 Parameterdefinition  
5.2. SecurityAccess-service  
5.2.1 Beskrivelse af meddelelser  
5.2.2 Meddelelsesformat — SecurityAccess — requestSeed  
5.2.3 Meddelelsesformat — SecurityAccess — sendKey  
6. DATAOVERFØRSELSSERVICER  
6.1. ReadDataByIdentifier-service  
6.1.1 Beskrivelse af meddelelser  
6.1.2 Meddelelsesformat  
6.1.3 Parameterdefinition  
6.2. WriteDataByIdentifier-service  
6.2.1 Beskrivelse af meddelelser  
6.2.2 Meddelelsesformat  
6.2.3 Parameterdefinition  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 357  
7. KONTROL AF TESTIMPULSER — FUNKTIONSENHED FOR 
IND-/UDDATASTYRING  
7.1. InputOutputControlByIdentifier-service  
7.1.1 Beskrivelse af meddelelser  
7.1.2 Meddelelsesformat  
7.1.3 Parameterdefinition  
▼M3 
8. ROUTINECONTROL SERVICE (TIDSJUSTERING)  
8.1. Beskrivelse af meddelelser  
8.2. Meddelelsesformat  
9. FORMATER TIL DATARECORDS  
9.1. Værdiområder for overførte parametre  
9.2. Formater til dataRecords  
▼B 
1. INDLEDNING  
I dette tillæg beskrives, hvordan der udveksles data mellem en køre­
tøjsenhed og en tester via K-linjen, som er en del af den i til læg 6 
beskrevne kalibreringsgrænseflade. Det beskriver desuden styrin gen af 
ind-/uddatalinjen på kalibreringsstikket.  
Etablering af K-linje-kommunikationer er beskrevet i punkt 4 
»Kommunikationsservicer«.  
I dette tillæg anvendes begrebet »diagnosesessioner« til fastlæ ggelse af 
omfanget af styring over K-linjen under forskellige betingelser . Den 
forudindstillede tilstand er »standardsessionen«, hvor alle dat a kan 
aflæses fra køretøjsenheden, men ingen data kan skrives til den . 
Valg af diagnosesession er beskrevet i punkt 5 »Administrations ser­
vicer«.  
Dette tillæg skal betragtes som relevant for begge generationer  af køre­
tøjsenheder og værkstedskort, som overholder de interoperabilit etskrav, 
der er fastlagt i denne forordning.  
CPR_001 I »ECUProgrammingSession« kan der indlæses data til 
køretøjsenheden. Ved indlæsning af kalibreringsdata skal 
køretøjsenheden desuden være i funktionstilstand CALI­
BRATION.  
Dataoverførsel via K-linje er beskrevet i afsnit 6 »Dataover­
førselsservicer«. Formatet af de overførte data er beskrevet i 
afsnit 8 »Formater til dataRecords«.  
CPR_002 I »ECUAdjustmentSession« kan kalibrerings-I/O-signallin ­
jens I/O-funktionstilstand vælges via K-linjegrænsefladen. 
Kontrol af kalibrerings-I/O-signallinjen er beskrevet i 
afsnit 7 »Kontrol af testimpulser — funktionsenhed for 
ind-/uddatastyring«.  
CPR_003 I hele dette dokument betegnes testerens adresse som »t t«. 
Skønt visse adresser for testere kan være foretrukne, skal 
køretøjsenheden svare korrekt på enhver testeradresse. Køre­
tøjsenhedens fysiske adresse er 0xEE.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 358  
2. TERMER, DEFINITIONER OG HENVISNINGER  
Protokoller, meddelelser og fejlkoder bygger hovedsagelig på ud kastet 
til ISO 14229-1 (Road vehicles — Diagnostic systems — Part 1: 
Diagnostic services, version 6 af 22. februar 2001).  
Der anvendes bytekodning og hexadecimale værdier til serviceide ntifi­
katorer, serviceanmodninger og -svar samt standardparametre.  
Begrebet »tester« anvendes for det udstyr, som benyttes til at indlæse 
programmerings- og kalibreringsdata i køretøjsenheden.  
Begreberne »klient« og »server« henviser henholdsvis til tester en og 
køretøjsenheden.  
Begrebet ECU står for »Electronic control unit« og henviser til  køre­
tøjsenheden.  
Henvisninger:  
▼M1 
ISO 14230-2: Road Vehicles — Diagnostic Systems — Keyword 
Protocol 2000 — Part 2: Data Link Layer.  
First edition: 1999.  
▼B 
3. OVERSIGT OVER SERVICER  
3.1. Tilgængelige servicer  
I nedenstående tabel gives en oversigt over de servicer, som vi l være til 
rådighed i takografen og er fastlagt i dette dokument.  
CPR_004 Tabellerne angiver servicer, som er til rådighed i en p åbe­
gyndt diagnosesession.  
— Søjle 1  angiver de servicer, som er til rådighed.  
— Søjle 2  henviser til nummeret på det punkt i dette tillæg, 
hvor denne service er nærmere defineret.  
— Søjle 3  tildeler værdier til serviceidentifikatorer for 
anmodningsmeddelelser.  
— Søjle 4  angiver de servicer i en »StandardDiagnosticSes­
sion« (SS), som skal være implementeret i hver køre­
tøjsenhed.  
— Søjle 5  angiver de servicer i en »ECUAdjustmentS­
ession« (ECUAS), som skal være implementeret, så 
der er mulighed for styring af I/O-signallinjen i kalibre­
ringsstikket på køretøjsenhedens frontpanel.  
— Søjle 6  angiver de servicer i en »ECUProgrammingS­
ession« (ECUPS), som skal være implementeret, så der 
kan programmeres parametre i køretøjsenheden.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 359  
Tabel 1  
Oversigtstabel over serviceidentifikatorer  
Diagnosesession  
Navn på diagnoseservice  Afsnit nr.  Værdi af 
Sid-anmodning  SD ECUAS  ECUPS  
StartCommunication  4.1  8 1  ■  ■  ■  
StopCommunication  4.2  8 2  ■  
TesterPresent  4.3  3 E  ■  ■  ■  
StartDiagnosticSession  5.1  1 0  ■  ■  ■  
SecurityAccess  5.2  2 7  ■  ■  ■  
ReadDataByIdentifier  6.1  2 2  ■  ■  ■  
WriteDataByIdentifier  6.2  2 E  ■  
InputOutputControlByIdentifier  7.1  2 F  ■  
▼M3 
RoutineControl  8  3 1  ■  ■  
▼B 
■ Dette symbol angiver, at servicen er obligatorisk i denne diag nosesession. 
Hvis der ikke er noget symbol, er servicen ikke er tilladt i de nne diagnosesession.  
3.2. Svarkoder  
Svarkoder er defineret for hver service.  
4. KOMMUNIKATIONSSERVICER  
Visse servicer er nødvendige til at etablere og opretholde komm unika­
tion. De figurerer ikke i applikationslaget. I følgende tabel b eskrives de 
servicer, som er til rådighed:  
Tabel 2  
Kommunikationsservicer  
Servicens navn  Beskrivelse  
StartCommunication  Klienten anmoder om påbegyndelse af 
en kommunikationssession med en 
server  
StopCommunication  Klienten anmoder om at standse den 
aktuelle kommunikationssession  
TesterPresent  Klienten angiver over for serveren, at 
den stadig er til stede  
CPR_005 Servicen StartCommunication anvendes til at begynde en 
kommunikation. For enhver service gælder, at kommunika­
tionen skal være initialiseret, og kommunikationsparame­
trene skal være passende til den pågældende funktionstil­
stand.  
4.1. Servicen StartCommunication  
CPR_006 Ved modtagelse af en StartCommunication-indikation skal  
køretøjsenheden kontrollere, om den ønskede dataforbin­
delse kan initialiseres under de aktuelle betingelser. De 
gældende betingelser for initialisering af en dataforbindelse 
er beskrevet i dokument ISO 14230-2.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 360  
CPR_007 Derefter skal køretøjsenheden udføre alle de operatione r, 
som er nødvendige for at initialisere dataforbindelsen og 
sende et StartCommunication-svar, hvor parametre for posi­
tivt svar er valgt.  
CPR_008 Hvis en køretøjsenhed, som i forvejen er initialiseret (og har 
påbegyndt en diagnosesession, uanset hvilken), modtager en 
ny StartCommunication-anmodning (f.eks. pga. fejlafhjælp­
ning i testeren), skal anmodningen accepteres, og køretøjs­
enheden skal reinitialiseres.  
CPR_009 Hvis dataforbindelsen af en eller grund ikke kan initia li­
seres, skal køretøjsenheden fortsætte med at fungere, som 
den gjorde umiddelbart før forsøget på at initialisere 
dataforbindelsen.  
CPR_010 Meddelelsen med anmodningen StartCommunication skal 
være fysisk adresseret.  
CPR_011 Initialisering af køretøjsenheden til servicer sker ved  hurtig 
initialisering  
— forud for enhver aktivitet er en periode, hvor bussen er 
ledig  
— testeren sender derefter et initialiseringsmønster  
— alle oplysninger, som er nødvendige til oprettelse af 
dataforbindelsen, er indeholdt i svaret fra køretøjs­
enheden.  
CPR_012 Når initialisering har fundet sted,  
— er alle kommunikationsparametre sat til de i Tabel 4 
fastlagte standardværdier i henhold til nøglebytes.  
— afventer køretøjsenheden første anmodning fra testeren.  
— er køretøjsenheden i sin standardfunktionstilstand for 
diagnose, dvs. StandardDiagnosticSession.  
— er I/O-signallinjen for kalibrering i standardtilstand, dvs. 
deaktiveret.  
CPR_014 Datahastigheden på K-linjen skal være 10 400 baud.  
CPR_016 Hurtig initialisering igangsættes ved, at testeren over fører et 
opvågningsmønster (Wup) på K-linjen. Efter den ledige 
periode på K-linjen begynder mønsteret med et kortvarigt 
Tinil. Testeren overfører første bit af StartCommunication- 
servicen efter en periode med Twup, som efterfølger den 
første slutkant.
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 361  
CPR_017 Synkroniseringsværdierne for hurtig initialisering og f or 
meddelelser i almindelighed er givet i nedenstående tabel. 
Der er forskellige muligheder for den ledige tid:  
— Første overførsel, efter at der er tændt, Tidle = 300 ms.  
— Efter afslutning af en StopCommunication Service, Tidle 
= P3 min.  
— Efter afbrydelse af kommunikation ved tidsudkobling P3 
maks., Tidle = 0.  
Tabel 3  
Synkroniseringsværdier for hurtig initialisering  
Parameter  Min. værdi  Maks. værdi  
Tinil  25 ± 1 ms  24 ms  26 ms  
Twup  50 ± 1 ms  49 ms  51 ms  
Tabel 4  
Synkroniseringsværdier for kommunikation  
Tidspunkt 
Parameter  Parameterbeskrivelse  Nedre grænse 
(ms) Øvre grænse 
(ms) 
Min.  maks.  
P1 Tid mellem bytes for svar fra 
køretøjsenhed  0 2 0  
P2 Tid mellem anmodning fra 
tester og svar fra køretøjs­
enhed, eller mellem to svar 
fra køretøjsenhed  25 250  
P3 Tid mellem slutning af svar fra 
køretøjsenhed og begyndelse 
på ny anmodning fra tester  55 5 000  
P4 Tid mellem bytes for anmod­
ning fra tester  5 2 0  
CPR_018 Meddelelsesformatet for hurtig initialisering er givet i 
nedenstående tabeller.  
Tabel 5  
StartCommunication-anmodning  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  81 FMT  
#2 Adressebyte på destination  E E  TGT  
#3 Adressebyte på kilde  t t  SRC  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 362  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#4 Service-ID på StartCommu ­
nication-anmodning  81 SCR  
#5 Kontrolsum  00-FF  C S  
Tabel 6  
Positivt svar på StartCommunication  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 3  LEN  
#5 Service-ID for positivt svar 
på StartCommunication  C1 SCRPR  
#6 Nøglebyte 1  E A  KB1  
#7 Nøglebyte 2  8 F  KB2  
#8 Kontrolsum  00-FF  C S  
CPR_019 Der findes intet negativt svar på en StartCommunication - 
anmodning; er der ingen positiv svarmeddelelse at overføre, 
bliver køretøjsenheden ikke initialiseret, der overføres intet,  
og enheden fortsætter i normal funktionstilstand.  
4.2. StopCommunication-service  
4.2.1  Beskrivelse af meddelelser  
Denne service er placeret i kommunikationslaget og anvendes til  at 
afslutte en kommunikationssession.  
CPR_020 Ved modtagelse af en StopCommunication-indikation skal 
køretøjsenheden kontrollere, om kommunikationen kan 
afsluttes under de aktuelle betingelser. I bekræftende fald 
skal køretøjsenheden udføre alle de nødvendige operationer 
til at afslutte kommunikationen.  
CPR_021 Hvis det kan lade sig gøre at afslutte kommunikationen,  skal 
køretøjsenheden afgive et StopCommunication-svar med 
parametre svarende til positivt svar, før kommunikationen 
afsluttes.  
CPR_022 Hvis kommunikationen af en eller anden grund ikke kan 
afsluttes, skal køretøjsenheden afgive et StopCommunica­
tion-svar med parameteren negativt svar.  
CPR_023 Hvis køretøjsenheden registrerer tidsudkobling af P3max , 
skal kommunikationen afsluttes, uden at der afgives et svar.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 363  
4.2.2  Meddelelsesformat  
CPR_024 Meddelelsesformater for StopCommunication er givet i 
følgende tabeller:  
Tabel 7  
StopCommunication-anmodning  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  E E  TGT  
#3 Adressebyte på kilde  t t  SRC  
#4 Ekstra længdebyte  0 1  LEN  
#5 Service-ID på StopCommuni ­
cation-anmodning  82 SPR  
#6 Kontrolsum  00-FF  C S  
Tabel 8  
Positivt svar på StopCommunication  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 1  LEN  
#5 Service-ID for positivt svar 
på StopCommunication  C2 SPRPR  
#6 Kontrolsum  00-FF  C S  
Tabel 9  
Negativt svar på StopCommunication  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 3  LEN  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 364  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#5 Service-ID på negativt svar  7F  NR  
#6 Service-ID på StopCommuni­
cation  82 SPR  
#7 responseCode = generalReject  1 0  RC_GR  
#8 Kontrolsum  00-FF  C S  
4.2.3  Parameterdefinition  
Denne service kræver ingen parameterdefinition.  
4.3. TesterPresent-service  
4.3.1  Beskrivelse af meddelelser  
Servicen TesterPresent anvendes af testeren til at angive, at s erveren 
stadig er til stede for at undgå, at serveren automatisk return erer til 
normal drift og eventuelt standser kommunikationen. Denne servi ce, 
der udføres med regelmæssige mellemrum, holder diagnosesession/  
kommunikation aktive ved at tilbagestille P3-timeren, hver gang  der 
modtages en anmodning om denne service.  
4.3.2  Meddelelsesformat  
CPR_079 Meddelelsesformater for TesterPresent-instruktioner er 
angivet i følgende tabeller.  
Tabel 10  
TesterPresent-anmodning  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  E E  TGT  
#3 Adressebyte på kilde  t t  SRC  
#4 Ekstra længdebyte  0 2  LEN  
#5 Identifikation af servicen 
TesterPresent-forespørgsel  3E TP  
#6 Delfunktion = response- 
Required =  [ja 0 1  RESPREQ_Y  
nej] 0 2  RESPREQ_NO  
#7 Kontrolsum  00-FF  C S  
CPR_080 Hvis parameteren responseRequired sættes til »ja«, skal  
serveren svare med følgende positive svarmeddelelse. Hvis 
den sættes til »nej«, kommer der intet svar fra serveren.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 365  
Tabel 11  
Positivt svar på TesterPresent  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 1  LEN  
#5 Identifikation af servicen 
TesterPresent-forespørgsel  7E TPPR  
#6 Kontrolsum  00-FF  C S  
CPR_081 Servicen skal understøtte følgende negative svarkoder:  
Tabel 12  
Negativt svar på TesterPresent  
Byte #  Parameternavn  Hex- 
værdi  Huskeværdi  
#1 Formatbyte — fysisk adressering  8 0  FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 3  LEN  
#5 Service-ID på negativt svar  7F  NR  
#6 Identifikation af servicen 
TesterPresent-forespørgsel  3E T P  
#7 response­
Code =  [SubFunctionNotSup­
ported-InvalidFormat  12 RC_SFNS_IF  
incorrectMessage­
Length]  13 RC_IML  
#8 Kontrolsum  00-FF  C S  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 366  
5. ADMINISTRATIONSSERVICER  
I følgende tabel beskrives de servicer, som er til rådighed:  
Tabel 13  
Administrationsservicer  
Servicens navn  Beskrivelse  
StartDiagnosticSession  Klienten anmoder om at påbegynde en diag­
nosesession med en VU.  
SecurityAccess  Klienten anmoder om adgang til funktioner, 
som er forbeholdt autoriserede brugere.  
5.1. StartDiagnosticSession-service  
5.1.1  Beskrivelse af meddelelser  
CPR_025 Servicen StartDiagnosticSession anvendes til at tillade  
forskellige diagnosesessioner i serveren. En diagnosesession 
tillader et nærmere bestemt sæt servicer i henhold til Tabel 
17. En session kan for køretøjsfabrikanten åbne særlige 
servicer, som ikke indgår i dette dokument. Implemente­
ringsreglerne skal være i overensstemmelse med følgende 
krav:  
— Der skal altid være netop én aktiv diagnosesession i 
køretøjsenheden.  
— Køretøjsenheden skal altid åbne StandardDiagnosticSes­
sion, når den startes op. Hvis der ikke påbegyndes 
nogen anden diagnosesession, skal StandardDiagnostic­
Session køre, så længe køretøjsenheden er tændt.  
— Har testeren anmodet om en diagnosesession, som i 
forvejen kører, skal køretøjsenheden afgive en positiv 
svarmeddelelse.  
— Når testeren anmoder om en ny diagnosesession, skal 
køretøjsenheden først sende en positiv svarmeddelelse 
på StartDiagnosticSession, før den nye session bliver 
aktiv i køretøjsenheden. Er køretøjsenheden ikke i 
stand til at starte den anmodede nye diagnosesession, 
skal den svare med en negativ svarmeddelelse på Start­
DiagnosticSession, og den aktuelle session skal fort­
sætte.  
CPR_026 En diagnosesession må kun påbegyndes, hvis der er etab­
leret kommunikation mellem klienten og køretøjsenheden.  
CPR_027 Efter en vellykket StartDiagnosticSession med diagnosti c­
Session-parameteren sat til »StandardDiagnsticSession« i 
anmodningsmeddelelsen skal de i Tabel 4 angivne synkro­
niseringsparametre være aktive, hvis en anden diagnoseses­
sion i forvejen var aktiv.  
5.1.2  Meddelelsesformat  
CPR_028 Meddelelsesformaterne for StartDiagnosticSession er giv et i 
følgende tabeller.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 367  
Tabel 14  
StartDiagnosticSession-anmodning  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  E E  TGT  
#3 Adressebyte på kilde  t t  SRC  
#4 Ekstra længdebyte  0 2  LEN  
#5 Service-ID på StartDiagno ­
sticSession-anmodning  10 STDS  
#6 diagnosticSession = [en værdi 
fra Tabel 17]  xx DS_…  
#7 Kontrolsum  00-FF  C S  
Tabel 15  
Positivt svar på StartDiagnosticSession  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 2  LEN  
#5 Service-ID for positivt svar 
på StartDiagnosticSession  50 STDSPR  
#6 diagnosticSession = [samme 
værdi som byte #6 i Tabel 14]  xx DS_…  
#7 Kontrolsum  00-FF  C S  
Tabel 16  
Negativt svar på StartDiagnosticSession  
Byte #  Parameternavn  Hex- 
værdi  Huskeværdi  
#1 Formatbyte — fysisk adressering  8 0  FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 368  
Byte #  Parameternavn  Hex- 
værdi  Huskeværdi  
#4 Ekstra længdebyte  0 3  LEN  
#5 Service-ID på negativt svar  7F  NR  
#6 Service-ID på StartDiagnosticSes­
sion-anmodning  10 STDS  
#7 Response­
Code =  [subFunctionNotSup­
ported (  α ) 1 2  RC_SFNS  
incorrectMessage­
Length (  β ) 13 RC_IML  
conditionsNotCor­
rect (  γ ) 22 RC_CNC  
#8 Kontrolsum  00-FF  C S  
( α ) — værdien i byte #6 i anmodningen understøttes ikke, dvs. ikk e i tabel 17 
( β ) — anmodningens længde er forkert 
( γ ) — kriterierne for anmodningen StartDiagnosticSession er ikke opfyldt.  
5.1.3  Parameterdefinition  
CPR_029 Parameteren  diagnosticSession (DS_)  anvendes af StartDi­
agnosticSession-servicen til at vælge en nærmere bestemt 
adfærd for serveren (serverne). Følgende diagnosesessioner 
er beskrevet i dette dokument:  
Tabel 17  
Fastlæggelse af værdier for diagnosticSession  
Hex Beskrivelse  Huskeværdi  
81 StandardDiagnosticSession  
Denne diagnosesession tillader alle servicer i  
tabel 1, søjle 4 »SD« . Disse servicer giver 
mulighed for læsning af data fra en server 
(køretøjsenhed). Denne diagnosesession er aktiv 
efter vellykket initialisering mellem klient (tes- 
ter) og server (køretøjsenhed). Denne diagnose- 
s e s s i o n k a n o v e r s k r i v e s a f a n d r e 
diagnosesessioner, som foreskrives i dette afsnit.  SD 
85 ECUProgrammingSession  
Denne diagnosesession tillader alle servicer i  
tabel 1, søjle 6 »ECUPS« . Disse servicer 
understøtter programmering af hukommelsen på 
en server (køretøjsenhed). Denne diagnoseses- 
sion kan overskrives af andre diagnosesessioner, 
som er beskrevet i dette afsnit.  ECUPS  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 369  
Hex Beskrivelse  Huskeværdi  
87 ECUAdjustmentSession  
Denne diagnosesession tillader alle servicer i  
tabel 1, søjle 5 »ECUAS«.  Disse servicer 
understøtter ind-/uddatastyring for en server 
(køretøjsenhed). Denne diagnosesession kan 
overskrives af andre diagnosesessioner, som 
foreskrives i dette afsnit.  ECUAS  
5.2. SecurityAccess-service  
Skrivning af kalibreringsdata er kun mulig, når køretøjsenheden  er i 
CALIBRATION-funktionstilstand. For at få adgang til CALIBRA­
TION-funktionstilstand skal man isætte et gyldigt værkstedskort  i køre­
tøjsenheden og indlæse korrekt PIN-kode i køretøjsenheden.  
Når køretøjsenheden er i funktionstilstandene CALIBRATION eller  
CONTROL er der også adgang til kalibreringens ind-/uddatalinje.  
SecurityAccess-servicen kan anvendes til at indlæse PIN-koden o g 
angive over for testeren, om køretøjsenheden er i funktionstils tand 
CALIBRATION eller ej.  
Det kan godtages, at indlæsning af PIN-koden kan ske på anden m åde. 
5.2.1  Beskrivelse af meddelelser  
Sikkerhedsservicen består af en SecurityAccess »requestSeed«-me dde­
lelse, senere efterfulgt af en SecurityAccess »sendKey«-meddele lse. 
SecurityAccess skal udføres efter StartDiagnosticSession.  
CPR_033 Testeren skal anvende SecurityAccess »sendKey«-medde­
lelsen til kontrol af, om køretøjsenheden er klar til at 
modtage en PIN-kode.  
CPR_034 Er køretøjsenheden i forvejen i CALIBRATION-funktions­
tilstand, skal den besvare forespørgslen ved at sende et 
»basistal« på 0x0000 ved hjælp af servicen positivt svar 
på SecurityAccess.  
CPR_035 Er køretøjsenheden klar til at modtage en PIN-kode med 
henblik på kontrol ved hjælp af et værkstedskort, skal den 
besvare forespørgslen ved at sende et »basistal« større end 
0x0000 ved hjælp af servicen positivt svar på SecurityAc­
cess.  
CPR_036 Er køretøjsenheden ikke klar til at acceptere en PIN-ko de fra 
testeren, enten fordi det isatte værkstedskort ikke er gyldigt,  
fordi der ikke er indsat et værkstedskort, eller fordi køre­
tøjsenheden forventer PIN-koden indlæst på anden måde, 
skal den besvare forespørgslen med et negativt svar, hvor 
svarkoden er sat til conditionsNotCorrectOrRequestSequen­
ceError.  
CPR_037 Testeren skal derefter til sidst anvende servicen Secur ityAc­
cess »SendKey«-meddelelse til at fremsende en PIN-kode til 
køretøjsenheden. For at give tid til ægthedskontrol skal 
køretøjsenheden anvende den negative svarkode requestCor­
rectlyReceived-ResponsePending for at forlænge tiden til at  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 370  
svare. Dog må den maksimale svartid ikke være over 5 
minutter. Så snart den ønskede service er udført, skal køre­
tøjsenheden sende en positiv svarmeddelelse eller negativ 
svarmeddelelse med en svarkode forskellig fra denne. Den 
negative svarkode requestCorrectlyReceived-ResponsePen­
ding kan af køretøjsenheden gentages, indtil den ønskede 
service er udført og den endelige svarmeddelelse sendt.  
CPR_038 Køretøjsenheden skal kun besvare denne anmodning med 
servicen positivt svar på SecurityAccess, når den er i 
CALIBRATION-funktionstilstand.  
CPR_039 I følgende tilfælde skal køretøjsenheden besvare denne fore­
spørgsel med et negativt svar med en svarkode sat til:  
— subFunctionNot supported: Ugyldigt format af delfunk­
tionens parameter (accessType)  
— conditionsNotCorrectOrRequestSequenceError: Køretøjs­
enheden ikke klar til at acceptere en indtastet PIN-kode  
— invalidKey: PIN-kode ikke gyldig, og antal PIN-kode­
forsøg ikke overskredet,  
— exceededNumberOfAttempts: PIN-kode ikke gyldig, og 
antal PIN-kodeforsøg overskredet,  
— generalReject: korrekt PIN-kode, men gensidig ægtheds­
kontrol med værkstedskort mislykkedes.  
5.2.2  Meddelelsesformat — SecurityAccess — requestSeed  
CPR_040 Meddelelsesformaterne for SecurityAccess »requestSeed«-  
instruktionerne er angivet i nedenstående tabeller:  
Tabel 18  
SecurityAccess-anmodning — requestSeed-meddelelse  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  E E  TGT  
#3 Adressebyte på kilde  t t  SRC  
#4 Ekstra længdebyte  0 2  LEN  
#5 Service-ID på SecurityAc ­
cess-anmodning  27 SA  
#6 accessType — requestSeed  7 D  AT_RSD  
#7 Kontrolsum  00-FF  C S  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 371  
Tabel 19  
Positiv svarmeddelelse på SecurityAccess — requestSeed  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 4  LEN  
#5 Service-ID for positivt svar 
på SecurityAccess  67 SAPR  
#6 accessType — requestSeed  7 D  AT_RSD  
#7 Basistal højt  00-FF  SEEDH  
#8 Basistal lavt  00-FF  SEEDL  
#9 Kontrolsum  00-FF  C S  
Tabel 20  
Negativt svar på SecurityAccess  
Byte #  Parameternavn  Hex- 
værdi  Huskeværdi  
#1 Formatbyte — fysisk adressering  8 0  FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 3  LEN  
#5 Service-ID for negativeResponse  7F  NR  
#6 Service-ID på SecurityAccess-anmod­
ning 27 S A  
#7 response­
Code =  [conditionsNotCorrec­
tOrRequestSequence­
Error  22 RC_CNC  
incorrectMessage­
Length]  13 RC_IML  
#8 Kontrolsum  00-FF  C S  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 372  
5.2.3  Meddelelsesformat — SecurityAccess — sendKey  
CPR_041 Meddelelsesformaterne for SecurityAccess »sendKey«- 
instruktioner er givet i nedenstående tabeller:  
Tabel 21  
SecurityAccess-anmodning — sendKey-meddelelse  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  E E  TGT  
#3 Adressebyte på kilde  t t  SRC  
#4 Ekstra længdebyte  m+2  LEN  
#5 Service-ID på SecurityAc ­
cess-anmodning  27 SA  
#6 accessType — sendKey  7 E  AT_SK  
#7 til #m+6  Nøgle #1 (høj)  x x  KEY  
… …  
Nøgle #m (lav, m skal være 
mindst 4 og højst 8)  xx 
#m+7  Kontrolsum  00-FF  C S  
Tabel 22  
Positiv svarmeddelelse på SecurityAccess — sendKey  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 2  LEN  
#5 Service-ID for positivt svar 
på SecurityAccess  67 SAPR  
#6 accessType — sendKey  7 E  AT_SK  
#7 Kontrolsum  00-FF  C S  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 373  
Tabel 23  
Negativt svar på SecurityAccess  
Byte #  Parameternavn  Hex- 
værdi  Huskeværdi  
#1 Formatbyte — fysisk adressering  8 0  FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 3  LEN  
#5 Service-ID på NegativeResponse  7F  NR  
#6 Service-ID på SecurityAccess- 
anmodning  27 S A  
#7 Response­
Code =  [generalReject  1 0  RC_GR  
subFunctionNotSup­
ported  12 RC_SFNS  
incorrectMessage­
Length  13 RC_IML  
conditionsNotCorrec­
tOrRequestSequence­
Error  22 RC_CNC  
invalidKey  3 5  RC_IK  
exceededNumberO­
fAttempts  36 RC_ENA  
requestCorrectlyRe­
ceived-ResponsePen­
ding]  78 RC_RCR_RP  
#8 Kontrolsum  00-FF  C S  
6. DATAOVERFØRSELSSERVICER  
I følgende tabel beskrives de servicer, som er til rådighed:  
Tabel 24  
Dataoverførselsservicer  
Servicens navn  Beskrivelse  
ReadDataByIdentifier  Klienten anmoder om overførsel af den aktu­
elle værdi af en post med adgang gennem 
recordDataIdentifier.  
WriteDataByIdentifier  Klienten anmoder om at skrive en post, 
hvortil der er adgang gennem recordDataI­
dentifier  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 374  
6.1. ReadDataByIdentifier-service  
6.1.1  Beskrivelse af meddelelser  
CPR_050 Servicen ReadDataByIdentifier anvendes af klienten til at 
skrive recordValues (dataværdier) fra en server. Data iden­
tificeres af en recordDataIdentifier. Fabrikanten af køretøjs­
enheden har ansvaret for, at de for serveren gældende betin­
gelser er opfyldt ved udførelse af denne service.  
6.1.2  Meddelelsesformat  
CPR_051 Meddelelsesformaterne for ReadDataByIdentifier instruk­
tioner er givet i følgende tabeller.  
Tabel 25  
ReadDataByIdentifier-anmodning  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  E E  TGT  
#3 Adressebyte på kilde  t t  SRC  
#4 Ekstra længdebyte  0 3  LEN  
#5 Service-ID på ReadDataByI ­
dentifier-anmodning  22 RDBI  
#6 til #7  recordDataIdentifier = [en 
værdi fra Tabel 28]  xxxx  RDI_…  
#8 Kontrolsum  00-FF  C S  
Tabel 26  
Positivt svar på ReadDataByIdentifier  
Byte #  Parameternavn  Hex- 
værdi  Huskeværdi  
#1 Formatbyte — fysisk adressering  8 0  FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  m+3  LEN  
#5 Service-ID for positivt svar på 
ReadDataByIdentifier  62 RDBIPR  
#6 og #7  recordDataIdentifier = [samme værdi 
som byte #6 og #7 Tabel 25]  xxxx  RDI_…  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 375  
Byte #  Parameternavn  Hex- 
værdi  Huskeværdi  
#8 til #m+7  dataRecord[] =  [data#1  x x  DREC_DAT­
A1 
: :  :  
data#m]  x x  DREC_DAT­
Am 
#m+8  Kontrolsum  00-FF  C S  
Tabel 27  
Negativt svar på ReadDataByIdentifier  
Byte #  Parameternavn  Hex- 
værdi  Huskeværdi  
#1 Formatbyte — fysisk adressering  8 0  FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 3  LEN  
#5 Service-ID på NegativeResponse  7F  NR  
#6 Service-ID på ReadDataByIdentifier- 
anmodning  22 RDBI  
#7 Response­
Code=  [requestOutO­
fRange  31 RC_ROOR  
incorrectMessage­
Length  13 RC_IML  
conditionsNotCor­
rect] 22 RC_CNC  
#8 Kontrolsum  00-FF  C S  
6.1.3  Parameterdefinition  
CPR_052 Parameteren  recordDataIdentifier (RDI_)  i anmodningen 
ReadDataByIdentifier identificerer en datapost.  
▼M3 
CPR_053 De værdier af recordDataIdentifier, som defineres af de tte 
dokument, er vist i tabellen nedenfor.  
Tabellen recordDataIdentifier består af fem kolonner og 
mange linjer.  
— Første kolonne  indeholder den »Hex-værdi«, der er 
tilordnet den recordDataIdentifier, der er anført i tredje 
kolonne.  
— Anden kolonne (Dataelement)  indeholder det dataele­
ment i tillæg 1, som recordDataIdentifier er baseret på 
(omkodning kan være nødvendig).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 376  
— Tredje kolonne (Beskrivelse)  indeholder navnet på den 
tilsvarende recordDataIdentifier.  
— Fjerde kolonne (Adgangsrettigheder)  angiver adgangs­
rettighederne til denne recordDataIdentifier.  
— Femte kolonne (Huskeværdi)  angiver huskeværdien for 
denne recordDataIdentifier.  
Tabel 28  
Definition af recordDataIdentifier-værdier  
Hex Dataelement  recordDataIdentifier-navn 
(se format i afsnit 8.2)  Adgangsret­
tigheder 
(Read/ 
Write)  Huskeværdi  
F90B  CurrentDateTime  TimeDate  R/W  RDI_TD  
F912  HighResOdometer  HighResolutionTotalVehicleDi­
stance  R/W  RDI_HRTVD  
F918  K-ConstantOfRecordingEquipment  Kfactor  R/W  RDI_KF  
F91C  L-TyreCircumference  LfactorTyreCircumference  R/W  RDI_LF  
F91D  W-VehicleCharacteristicConstant  WvehicleCharacteristicFactor  R/W  RDI_WVCF  
F921  TyreSize  TyreSize  R/W  RDI_TS  
F922  nextCalibrationDate  NextCalibrationDate  R/W  RDI_NCD  
F92C  SpeedAuthorised  SpeedAuthorised  R/W  RDI_SA  
F97D  vehicleRegistrationNation  RegisteringMemberState  R/W  RDI_RMS  
F97E  VehicleRegistrationNumber  VehicleRegistrationNumber  R/W  RDI_ VRN  
F190  VehicleIdentificationNumber  VIN  R/W  RDI_ VIN  
F9D0  SensorSerialNumber  MotionSensorSerialNumber  R  RDI_SSN  
F9D1  RemoteCommunicationModuleSerial­
Number  RemoteCommunicationFacility­
SerialNumber  R RDI_RCSN  
F9D2  SensorGNSSSerialNumber  ExternalGNSSFacilitySerial­
Number  R RDI_GSSN  
F9D3  SealDataVu  SmartTachographSealsSerial­
Number  R/W  RDI_SDV  
F9D4  VuSerialNumber  VuSerialNumber  R  RDI_VSN  
F9D5  ByDefaultLoadType  ByDefaultLoadType  R/W  RDI_BDLT  
F9D6  TachographCardsGen1Suppression  TachographCardsGen1Suppres­
sion R/W  RDI_TCG1S  
F9D7  VehiclePosition  VehiclePosition  R  RDI_VP  
F9D8  LastCalibrationCountry  CalibrationCountry  R  RDI_CC  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 377  
CPR_054 Parameteren  dataRecord (DREC_)  anvendes af den positive 
svarmeddelelse på ReadDataByIdentifier til at hente den 
datapost, der er identificeret ved recordDataIdentifier, til 
klienten (testeren). Dataformater er fastlagt i punkt 8. Der 
kan fastlægges andre dataposter, som brugeren frivilligt kan 
benytte, herunder køretøjsenhedsspecifikke inddata, interne 
data og uddata, men disse er ikke defineret i dette 
dokument.  
6.2. WriteDataByIdentifier-service  
6.2.1  Beskrivelse af meddelelser  
CPR_056 Servicen WriteDataByIdentifier anvendes af klienten til  at 
skrive dataværdier til en server. Data identificeres af en 
recordDataIdentifier. Fabrikanten af køretøjsenheden har 
ansvaret for, at de for serveren gældende betingelser er 
opfyldt ved udførelse af denne service. For at opdatere para­
metrene i Tabel 28 skal køretøjsenheden være i CALIBRA­
TION-funktionstilstand.  
6.2.2  Meddelelsesformat  
CPR_057 Meddelelsesformaterne for WriteDataByIdentifier-instruk ­
tioner er givet i nedenstående tabeller.  
Tabel 29  
WriteDataByIdentifier-anmodning  
Byte #  Parameternavn  Hex- 
værdi  Huskeværdi  
#1 Formatbyte — fysisk adressering  8 0  FMT  
#2 Adressebyte på destination  E E  TGT  
#3 Adressebyte på kilde  t t  SRC  
#4 Ekstra længdebyte  m+3  LEN  
#5 Service-ID på WriteDataByIdenti ­
fier-anmodning  2E WDBI  
#6 til #7  recordDataIdentifier = [en værdi fra 
Tabel 28]  xxxx  RDI_…  
#8 til m+7  dataRecord[] =  [data#1  x x  DREC_DAT­
A1 
: :  :  
data#m]  x x  DREC_DAT­
Am 
#m+8  Kontrolsum  00-FF  C S  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 378  
Tabel 30  
Positivt svar på WriteDataByIdentifier  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 3  LEN  
#5 Service-ID for positivt svar 
på WriteDataByIdentifier  6E WDBIPR  
#6 til #7  recordDataIdentifier = [samme 
værdi som byte #6 og #7 Tabel 
29] xxxx  RDI_…  
#8 Kontrolsum  00-FF  C S  
Tabel 31  
Negativt svar på WriteDataByIdentifier  
Byte #  Parameternavn  Hex- 
værdi  Huskeværdi  
#1 Formatbyte — fysisk adressering  8 0  FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 3  LEN  
#5 Service-ID på NegativeResponse  7F  NR  
#6 Service-ID på WriteDataByIdentifier- 
anmodning  2E WDBI  
#7 Response­
Code=  [requestOutO­
fRange  31 RC_ROOR  
incorrectMessage­
Length  13 RC_IML  
conditionsNotCor­
rect] 22 RC_CNC  
#8 Kontrolsum  00-FF  C S  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 379  
6.2.3  Parameterdefinition  
Parameteren  recordDataIdentifier (RDI_)  er defineret i Tabel 28.  
Parameteren  dataRecord (DREC_)  anvendes i anmodningen ReadDa­
taByIdentifier til at hente de dataværdier, der er identificere t ved 
recordDataIdentifier, til serveren (køretøjsenheden). Dataforma ter er 
fastlagt i punkt 8.  
7. KONTROL AF TESTIMPULSER — FUNKTIONSENHED FOR 
IND-/UDDATASTYRING  
I følgende tabel beskrives de servicer, som er til rådighed:  
Tabel 32  
Funktionsenhed for ind-/uddatastyring  
Servicens navn  Beskrivelse  
InputOutputControl­
ByIdentifier  Klienten anmoder om at måtte styre et sæt 
serverspecifikke ind-/uddata.  
7.1. InputOutputControlByIdentifier-service  
7.1.1  Beskrivelse af meddelelser  
Testimpulser kan styres eller overvåges ved hjælp af en passend e tester, 
som tilsluttes via det forreste stik.  
CPR_058 Denne I/O-signallinje for kalibrering kan konfigureres med 
ordrer over K-linjen ved hjælp af servicen InputOutputCon­
trolByIdentifier, med hvilken man vælger den ønskede ind- 
eller udlæsningsfunktion for linjen. Linjen kan have 
følgende status:  
— frakoblet  
— speedSignalInput, hvor der gennem I/O-signallinjen for 
kalibrering tilføres et hastighedssignal (testsignal), som 
erstatter hastighedssignalet fra bevægelsesføleren; denne 
funktion er ikke tilgængelig i funktionstilstanden 
CONTROL  
— realTimeSpeedSignalOutputSensor, hvor der gennem 
I/O-signallinjen for kalibrering afgives et hastigheds­
signal fra bevægelsesføleren; denne funktion er ikke 
tilgængelig i funktionstilstanden CONTROL  
— RTCOutput, hvor der gennem I/O-signallinjen for kali­
brering afgives et UTC-kloksignal.  
CPR_059 Køretøjsenheden skal have indledt en justeringssession og 
skal være i CALIBRATION- eller CONTROL-funktionstil­
stand, for at linjens tilstand kan konfigureres. Når køretøjs­
enheden er i funktionstilstanden CALIBRATION, kan der 
vælges fire status for linjen (disabled, speedSignalInput, 
realTimeSpeedSignalOutputSensor, RTCOutput). Når køre­
tøjsenheden er i funktionstilstanden CONTROL, kan der 
kun vælges to status for linjen (disabled, realTimeSpeedOut­
putSensor). Når køretøjsenheden forlader justeringssession 
eller CALIBRATION- eller CONTROL-funktionstilstanden, 
skal den stille I/O-signallinjen for kalibrering tilbage i 
»deaktiveret« tilstand (standardtilstanden).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 380  
CPR_060 Hvis der modtages hastighedsimpulser på køretøjsenheden s 
indgangslinje for tidstro hastighedssignal, mens I/O-signal­
linjen for kalibrering er stillet på indgang, vil I/O-signal­
linjen blive stillet på udgang eller ført tilbage i deaktiveret  
tilstand.  
CPR_061 Sekvensen skal være:  
— Der oprettes kommunikation med StartCommunication- 
servicen  
— Der åbnes en justeringssession med StartDiagnosticSes­
sion-servicen og benyttes CALIBRATION-tilstand 
(rækkefølgen af disse to operationer har ikke betydning)  
— Tilstanden af uddata ændres med InputOutputControl­
ByIdentifier-servicen.  
7.1.2  Meddelelsesformat  
CPR_062 Meddelelsesformaterne af InputOutputControlByIdentifier - 
instruktionerne er givet i følgende tabeller.  
Tabel 33  
InputOutputControlByIdentifier-anmodning  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  E E  TGT  
#3 Adressebyte på kilde  t t  SRC  
#4 Ekstra længdebyte  x x  LEN  
#5 Sid for InputOutputControl ­
ByIdentifier-anmodning  2F IOCBI  
#6 og #7  InputOutputIdentifier = [Cali­
brationInputOutput]  F960  IOI_CIO  
#8 eller 
#8 til #9  ControlOptionRecord = [  COR_…  
inputOutputControlParameter 
— en værdi fra Tabel 36  xx IOCP_…  
controlState — en værdi fra 
Tabel 37 (se bemærkning 
nedenfor)]  xx CS_…  
#9 eller #10  Kontrolsum  00-FF  C S  
Bemærk:  Parameteren controlState findes kun i visse 
tilfælde (se 7.1.3).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 381  
Tabel 34  
Positivt svar på InputOutputControlByIdentifier  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  x x  LEN  
#5 S-id for positivt svar på 
inputOutputControlByIdenti ­
fier 6F IOCBIPR  
#6 og #7  inputOutputIdentifier = [Cali­
brationInputOutput]  F960  IOI_CIO  
#8 eller 
#8 til #9  controlStatusRecord = [  CSR_  
inputOutputControlParameter 
(samme værdi som byte #8 i 
Tabel 33)  xx IOCP_…  
controlState (samme værdi 
som byte #9 Tabel 33)] (i 
givet fald)  xx CS_…  
#9 eller #10  Kontrolsum  00-FF  C S  
Tabel 35  
Negativt svar på InputOutputControlByIdentifier  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Formatbyte — fysisk adres­
sering  80 FMT  
#2 Adressebyte på destination  t t  TGT  
#3 Adressebyte på kilde  E E  SRC  
#4 Ekstra længdebyte  0 3  LEN  
#5 Service-ID for negativeRes ­
ponse  7F NR  
#6 Sid for anmodning om inpu­
tOutputControlByIdentifier  2F IOCBI  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 382  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#7 responseCode=[  
incorrectMessageLength  1 3  RC_IML  
conditionsNotCorrect  2 2  RC_CNC  
requestOutOfRange  3 1  RC_ROOR  
deviceControlLimitsExceeded]  7 A  RC_DCLE  
#8 Kontrolsum  00-FF  C S  
7.1.3  Parameterdefinition  
CPR_064 Parameteren  inputOutputControlParameter (IOCP_)  er 
defineret i følgende tabel:  
Tabel 36  
Definition af inputOutputControlParameter-værdier  
Hex Beskrivelse  Huskeværdi  
00 ReturnControlToECU  
D  e n  n  e  v  æ  r d  i  a n  g  i v  e r  o  v  e r  f o  r  s  e r v  e r e n  
(køretøjsenheden), at testeren ikke længere kon- 
trollerer ind/ud-signallinjen for kalibrering.  RCTECU  
01 ResetToDefault  
D e n n e v æ r d i s k a l a n m o d e s e r v e r e n 
(køretøjsenheden) om at tilbagestille ind/ud- 
s i g n a l l i n j e n f o r k a l i b r e r i n g t i l d e n  s  
standardtilstand.  RTD  
03 ShortTermAdjustment  
D e n n e v æ r d i s k a l f o r t æ l l e s e r v e r e n 
(køretøjsenheden), at den anmodes om at justere 
ind/ud-signallinjen for kalibrering til den værdi, 
som er indeholdt i controlState-parameteren.  STA  
CPR_065 Parameteren  controlState , som kun er til stede, når inpu­
tOutputControlParameter er sat til ShortTermAdjustment, 
er fastlagt i følgende tabel:  
Tabel 37  
Definition af controlState-værdier  
Funktionstil­
stand  Hex-værdi  Beskrivelse  
Deaktiver  0 0  I/O-linjen er deaktiveret (standardtilstand)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 383  
Funktionstil­
stand  Hex-værdi  Beskrivelse  
Aktivér  0 1  Aktivér ind/ud-linje for kalibrering som 
speedSignalInput  
Aktivér  0 2  Aktivér ind/ud-linje for kalibrering som real­
TimeSpeedSignalOutputSensor  
Aktivér  0 3  Aktivér ind/ud-linje for kalibrering som 
RTCOutput  
▼M3 
8. ROUTINECONTROL SERVICE (TIDSJUSTERING)  
8.1. Beskrivelse af meddelelser  
CPR_065a Tjenesten RoutineControl (TimeAdjustment) gør det muli gt 
at udløse en justering af køretøjsenhedens ur til den tid, der 
leveres af GNSS-modtageren.  
For at udføre tjenesten RoutineControl (TimeAdjustment) 
skal køretøjsenheden være i tilstanden CALIBRATION.  
Forudsætning : Det sikres, at køretøjsenheden kan 
modtage ægthedsbekræftede positionsmeddelelser fra 
GNSS-modtageren.  
Så længe tidsjusteringen er i gang, skal køretøjsenheden 
besvare anmodningen RoutineControl, delfunktionen 
requestRoutineResults, med routineInfo = 0x78.  
Bemærk: Tidsjusteringen kan tage nogen tid. Diagnosete­
steren skal anmode om status for tidsjustering ved hjælp af 
delfunktionen requestRoutineResults.  
8.2. Meddelelsesformat  
CPR_065b Meddelelsesformaterne for tjenesten RoutineControl 
(TimeAdjustment) og dens instruktioner er omhandlet i 
de følgende tabeller.  
Tabel 37a  
Rutinen RoutineControl (TimeAdjustment) Request Message, delfunktionen startRoutine  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Format byte - physical addressing  8 0  FMT  
#2 Target address byte  E E  TGT  
#3 Source address byte  t t  SRC  
#4 Additional length byte  x x  LEN  
#5 RoutineControl Request Sid (Serviceidentifikation for anmodning 
om RoutineControl)  31 RC  
#6 routineControlType = [startRoutine]  0 1  RCTP_STR  
#7 and #8  routineIdentifier = [TimeAdjustment]  0100  RI_TA  
#9 Checksum  00-FF  C S  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 384  
Tabel 37b  
Rutinen RoutineControl (TimeAdjustment), delfunktionen startRoutine, positiv svarmeddelelse  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Format byte – physical addressing  8 0  FMT  
#2 Target address byte  t t  TGT  
#3 Source address byte  E E  SRC  
#4 Additional length byte  x x  LEN  
#5 RoutineControl Positive Response Sid (Serviceidentifikation for 
positivt svar for RoutineControl)  71 RCPR  
#6 routineControlType = [startRoutine]  0 1  RCTP_STR  
#7 and #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 Checksum  00-FF  C S  
Tabel 37c  
Rutinen RoutineControl (TimeAdjustment) Request Message, delfunktionen requestRoutineResults  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Format byte - physical addressing  8 0  FMT  
#2 Target address byte  E E  TGT  
#3 Source address byte  t t  SRC  
#4 Additional length byte  x x  LEN  
#5 RoutineControl Request Sid (Serviceidentifikation for anmodning 
om RoutineControl)  31 RC  
#6 routineControlType = [requestRoutineResults]  0 3  RCTP_RRR  
#7 and #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 Checksum  00-FF  C S  
Tabel 37d  
Rutinen RoutineControl (TimeAdjustment), delfunktionen requestRoutineResults, positiv svarmeddelelse  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Format byte – physical addressing  8 0  FMT  
#2 Target address byte  t t  TGT  
#3 Source address byte  E E  SRC  
#4 Additional length byte  x x  LEN  
#5 RoutineControl Positive Response Sid (Serviceidentifikation for 
positivt svar for RoutineControl)  71 RCPR  
#6 routineControlType = [requestRoutineResults]  0 3  RCTP_RRR  
#7 and #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 routineInfo (see Table 37f)  X X  RINF_TA  
#10 routineStatusRecord[] = routineStatus#1 (see Table 37g)  X X  RS_TA  
#11 Checksum  00-FF  C S  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 385  
Tabel 37e  
Rutinen RoutineControl (TimeAdjustment) negativ svarmeddelelse  
Byte #  Parameternavn  Hex-værdi  Huskeværdi  
#1 Format byte – physical addressing  8 0  FMT  
#2 Target address byte  t t  TGT  
#3 Source address byte  E E  SRC  
#4 Additional length byte  0 3  LEN  
#5 negativeResponse Service Id (Serviceidentifikation for negativt 
svar)  7F NR  
#6 inputOutputControlByIdentifier Request SId  3 1  RC  
#7 responseCode=[ 
sub-functionNotSupported 
incorrectMessageLengthOrInvalidFormat 
conditionsNotCorrect 
requestOutOfRange 
] 12 
13 
22 
31 SFNS 
IMLOIF 
CNC 
ROOR  
#8 Checksum  00-FF  C S  
Tabel 37f  
Rutinen RoutineControl (TimeAdjustment), routineInfo  
routineInfo  Hex-værdi  Beskrivelse  
NormalExitWithResultAvailable  6 1  Rutinen blev gennemført. Yderligere rutineresultater er 
tilgængelige.  
RoutineExecutionOngoing  7 8  Den rutine, der anmodes om, udføres stadig.  
Tabel 37g  
Rutinen RoutineControl (TimeAdjustment), routineStatus  
Hex-værdi  Testresultat  Beskrivelse  
01 positive  Tidsjusteringen blev afsluttet.  
02..0F  RFU  
10 negative  Ingen modtagelse af GNSS-signal.  
11..7F  RFU  
80..FF  Fabrikantspecifik  
9. FORMATER TIL DATARECORDS  
Dette punkt angiver:  
— generelle regler, som gælder for områderne for de parametre, som 
overføres af køretøjsenheden til testeren  
— formater, som skal anvendes til data, som overføres med de da ta­
transmissionsservicer, der er beskrevet i punkt 6.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 386  
CPR_067 Alle angivne parametre skal være understøttet af køretø js­
enheden.  
CPR_068 De data, som overføres af køretøjsenheden til testeren som 
svar på en forespørgselsmeddelelse, skal være af den målte 
type (dvs. den aktuelle værdi af den anmodede parameter, 
således som den måles eller observeres af køretøjsenheden).  
9.1. Værdiområder for overførte parametre  
CPR_069 Tabel 38 fastlægger de områder, som anvendes til at 
bestemme gyldigheden af en overført parameter.  
CPR_070 Værdierne i området »fejlindikator« giver køretøjsenhed en 
mulighed for øjeblikkelig at angive, at der som følge af en 
fejl i takografen ikke aktuelt forefindes gyldige parameter­
værdier.  
CPR_071 Værdierne i området »forefindes ikke« giver køretøjs­
enheden mulighed for at overføre en meddelelse, som inde­
holder en parameter, som ikke er til rådighed eller ikke 
understøttes i den pågældende programenhed. Værdierne i 
området »ikke anmodet« giver en enhed mulighed for at 
overføre en kommandomeddelelse og fastlægge de para­
metre, for hvilke der ikke forventes noget svar fra den 
modtagende enhed.  
CPR_072 Hvis der som følge af komponentsvigt ikke kan overføres  
gyldige data for en parameter, skal fejlindikatoren som 
beskrevet i tabel 38 anvendes i stedet for den pågældende 
parameters data. Men hvis de målte og beregnede data har 
resulteret i en værdi, som er gyldig, men falder uden for det 
fastlagte parameterområde, bør fejlindikatoren ikke 
benyttes. Data bør overføres med den pågældende 
minimum- eller maksimumværdi af parameteren.  
Tabel 38  
Områder for dataRecords  
Områdenavn  1 byte 
(Hex-værdi)  2 byte 
(Hex-værdi)  4 byte 
(Hex-værdi)  ASCII  
Gyldigt signal  00 til FA  0000 til FAFF  00000000 til FAFFFFFF  1 til 254  
Parameterspecifik indikator  F B  FB00 til FBFF  FB000000 til FBFFFFFF  ingen  
Område reserveret fremtidige indika­
torbit  FC til FD  FC00 til FDFF  FC000000 til FDFFFFFF  ingen  
Fejlindikator  F E  FE00 til FEFF  FE000000 til FEFFFFFF  0  
Foreligger ikke eller er ikke anmodet  F F  FF00 til FFFF  FF000000 til FFFFFFFF  F F  
CPR_073 For parametre kodet i ASCII skal ASCII-tegnet »*« reser ­
veres som skilletegn.  
9.2. Formater til dataRecords  
Tabel 39 til Tabel 42 nedenfor angiver de formater, som skal an vendes 
via servicerne ReadDataByIdentifier og WriteDataByIdentifier.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 387  
CPR_074 Tabel 39 angiver længde, opløsning og arbejdsområde for  
hver parameter, som er identificeret ved sin recordDataIden­
tifier:  
Tabel 39  
Format af dataRecords  
Parameternavn  Datalængde 
(byte)  Opløsning  Arbejdsområde  
TimeDate  8  Se nærmere i Tabel 40  
HighResolutionTotalVehicleDi­
stance  4 forstærkning 5 m/bit, 
forskydning 0 m  0 til +21 055 406 km  
Kfactor  2  forstærkning 0,001 impulser/m 
/bit, forskydning 0  0 til 64,255 impulser/m  
LfactorTyreCircumference  2  forstærkning 0,125 10  -3 m/bit, 
forskydning 0  0 til 8,031 m  
WvehicleCharacteristicFactor  2  forstærkning 0,001 impulser/m 
/bit, forskydning 0  0 til 64,255 impulser/m  
TyreSize  1 5  ASCII  ASCII  
NextCalibrationDate  3  Se nærmere i Tabel 41  
SpeedAuthorised  2  forstærkning 1/256 km/t/bit, 
forskydning 0  0 til 250,996 km/t  
RegisteringMemberState  3  ASCII  ASCII  
VehicleRegistrationNumber  1 4  Se nærmere i Tabel 42  
VIN 1 7  ASCII  ASCII  
SealDataVu  5 5  Se nærmere i Tabel 43  
ByDefaultLoadType  1  Se nærmere i Tabel 44  
VuSerialNumber  8  Se nærmere i Tabel 45  
SensorSerialNumber  8  Se nærmere i Tabel 45  
SensorGNSSSerialNumber  8  Se nærmere i Tabel 45  
RemoteCommunicationModuleSeri­
alNumber  8 Se nærmere i Tabel 45  
TachographCardsGen1Suppression  2  Se nærmere i Tabel 46  
VehiclePosition  1 4  Se nærmere i Tabel 47  
CalibrationCountry  3  ASCII  NationAlpha som fastlagt i 
tillæg 1  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 388  
CPR_075 Tabel 40 angiver formaterne for de forskellige byte i 
TimeDate-parameteren:  
Tabel 40  
Detaljeret format af TimeDate (recordDataIdentifier-værdi # F90B)  
Længde  Parameterdefinition  Opløsning  Arbejdsområde  
1 Sekunder  Forstærkning 0,25 s/bit, forskydning 0 s  0 til 59.75s  
2 Minutter  Forstærkning 1 min/bit, forskydning 0 min  0 til 59 min  
3 Timer  Forstærkning 1 t/bit, forskydning 0 t  0 til 23 t  
4 Måned  Forstærkning 1 måned/bit, forskydning 0 
måned  1 til 12 måneder  
5 Dag  Forstærkning 0,25 dag/bit, forskydning 0 dage 
(se bemærkning under tabel 41)  0,25 til 31,75 dage  
6 å r  Forstærkning 1 år/bit, forskydning +1985 år 
(se bemærkning under Tabel 41)  år 1985 til 2235  
7 Lokal forskydning, minutter  Forstærkning 1 min/bit, forskydning -125 min  -59 til +59 min  
8 Forskydning af lokalt 
timetal  Forstærkning 1 t/bit, forskydning -125 t  -23 til + 23 t  
CPR_076 Tabel 41 angiver formaterne for de forskellige byte i p ara­
meteren NextCalibrationDate:  
Tabel 41  
Detaljeret format af NextCalibrationDate (recordDataIdentifier-værdi # F922)  
Længde  Parameterdefinition  Opløsning  Arbejdsområde  
1 Måned  Forstærkning 1 måned/bit, forskydning 0 
måned  1 til 12 måneder  
2 Dag  Forstærkning 0,25 dag/bit, forskydning 0 dage 
(se bemærkning nedenfor)  0,25 til 31,75 dage  
3 å r  Forstærkning 1 år/bit, forskydning +1985 år 
(se bemærkning nedenfor)  år 1985 til 2235  
Bemærkning vedrørende brug af parameteren »Dag«:  
1) En værdi på 0 for datoen er ugyldig. Værdierne 1, 2, 3 
og 4 anvendes til at angive første dag i måneden. Værdi­
erne 5, 6, 7 og 8 angiver anden dag i måneden osv.  
2) Denne parameter kan ikke påvirke eller ændre ovenstå­
ende timeparameter.  
Bemærkning vedrørende brug af parameteren »År«:  
En værdi på 0 for året angiver år 1985, mens en værdi på 1 
angiver år 1986 osv.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 389  
CPR_078 Tabel 42 angiver formaterne for de forskellige byte i p ara­
meteren VehicleRegistrationNumber:  
Tabel 42  
Detaljeret format af VehicleRegistrationNumber (recordDataIdentifier-værdi # F97E)  
Længde  Parameterdefinition  Opløsning  Arbejdsområde  
1 Tegntabel (som fastlagt i tillæg 1)  ikke relevant  VehicleRegistrationNumber  
2 — 14  Køretøjets indregistreringsnummer (som 
defineret i tillæg 1)  ikke relevant  VehicleRegistrationNumber  
CPR_090 Tabel 43 angiver formaterne for de forskellige byte i p ara­
meteren SealDataVu:  
Tabel 43  
Detaljeret format af SealDataVu (recordDataIdentifier-værdi # F9D3)  
Længde  Parameterdefinition  Opløsning  Arbejdsområde  
1 — 11  sealRecord1. Format SealRecord som fastlagt 
i tillæg 1.  ikke relevant  SealRecord  
12 — 22  sealRecord2. Format SealRecord som fastlagt 
i tillæg 1.  ikke relevant  SealRecord  
23 — 33  sealRecord3. Format SealRecord som fastlagt 
i tillæg 1.  ikke relevant  SealRecord  
34 — 44  sealRecord4. Format SealRecord som fastlagt 
i tillæg 1.  ikke relevant  SealRecord  
45 — 55  sealRecord5. Format SealRecord som fastlagt 
i tillæg 1.  ikke relevant  SealRecord  
BEMÆRK:  Hvis der er mindre end fem plomber til 
rådighed, skal værdien af EquipmentType i alle ikke- 
anvendte sealRecords sættes til 15, dvs. ikke anvendt.  
CPR_091 Tabel 44 angiver formaterne for de forskellige byte i p ara­
meteren ByDefaultLoadType:  
Tabel 44  
Detaljeret format af ByDefaultLoadType (recordDataIdentifier-værdi # F9D5)  
Længde  Parameterdefinition  Opløsning  Arbejdsområde  
1 loadType 
»00«H: Udefineret lasttype 
»01«H: Gods 
»02«H: Passagerer  ikke relevant  »00«H — »02«H  
CPR_092 Tabel 45 angiver formaterne for de forskellige byte i p ara­
metrene VuSerialNumber, SensorSerialNumber, 
SensorGNSSSerialNumber og RemoteCommunication­
ModuleSerialNumber:  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 390  
Tabel 45  
Detaljeret format af VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber og 
RemoteCommunicationModuleSerialNumber (recordDataIdentifier-værdi # F9D4, F9D0, F9D2, F9D1)  
Længde  Parameterdefinition  Opløsning  Arbejdsområde  
1 VuSerialNumber, SensorSerialNumber, 
SensorGNSSSerialNumber og RemoteCom­
municationModuleSerialNumber: 
Format ExtendedSerialNumber som fastlagt i 
tillæg 1.  ikke relevant  ExtendedSerialNumber  
CPR_093  Tabel 46 angiver formaterne for de forskellige byte i parame­
teren TachographCardsGen1Suppression:  
Tabel 46  
Detaljeret format af TachographCardsGen1Suppression (recordDataIdentifier-værdi # F9D6)  
Længde  Parameterdefinition  Opløsning  Arbejdsområde  
1 — 2  TachographCardsGen1Suppression. Format 
TachographCardsGen1Suppression som fast­
lagt i tillæg 1.  ikke relevant  »0000«H, »A5E3«H  
CPR_094 Tabel 47 angiver formaterne for de forskellige byte i p ara­
meteren VehiclePosition.  
Tabel 47  
Detaljeret format af VehiclePosition (recordDataIdentifier-værdi # F9D7)  
Længde  Parameterdefinition  Opløsning  Arbejdsområde  
1 — 4  Tidsstemplet for køretøjets position blev 
bestemt.  Ikke relevant  TimeReal  
5 GNSS-nøjagtighed  Ikke relevant  GNSSAccuracy  
6 — 11  Køretøjsposition  Ikke relevant  GeoCoordinates  
12 Status for ægthedsbekræftelse  Ikke relevant  PositionAuthenticationStatus  
13 Nuværende land  Ikke relevant  NationNumeric  
14 Nuværende region  Ikke relevant  RegionNumeric  
Bemærk : Efter opdatering af køretøjspositionen kan opda­
teringen af nuværende land og region blive forsinket.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 391  
Tillæg 9.  
TYPEGODKENDELSE — LISTE OVER MINDSTEKRAV TIL PRØVER  
INDHOLDSFORTEGNELSE  
1. INDLEDNING  
2. FUNKTIONSPRØVER FOR KØRETØJSENHED  
3. FUNKTIONSPRØVER FOR BEVÆGELSESFØLER  
4. FUNKTIONSPRØVER FOR TAKOGRAFKORT  
5. PRØVNING AF EKSTERNT GNSS-UDSTYR  
▼M1 
6. PRØVNING AF EKSTERNT UDSTYR TIL FJERNKOMMUNIKATION  
▼B 
7. FUNKTIONSPRØVNING AF PAPIR  
8. INTEROPERABILITETSPRØVER  
▼M3 
9. OSNMA-PRØVER  
▼B 
1. INDLEDNING  
1.1. Typegodkendelse  
EF-typegodkendelse for kontrolapparater (eller komponenter dert il) eller 
takografkort bygger på  
▼M1 
— en  sikkerhedsattestering  baseret på fælles kriterier efter et sikker­
hedsmål, som er i fuld overensstemmelse med tillæg 10 til dette  bilag  
▼B 
— en  funktionel attestering , som udføres af en medlemsstats myndig­
heder, og ved hvilken det attesteres, at den afprøvede genstand  
opfylder forskrifterne i dette bilag hvad angår udførte funktio ner, måle­
nøjagtighed og miljøegenskaber  
— en  interoperabilitetsattestering , som udføres af den kompetente 
myndighed, og som certificerer, at kontrolapparatet (eller tako graf­
kortet) er gensidigt fuldt kompatibelt med den nødvendige type tako­
grafkort (eller kontrolapparat) (se afsnit 8 i dette bilag).  
I tillægget foreskrives det, hvilke prøver der som minimum skal  udføres af 
medlemsstatens myndigheder ved funktionsprøverne, og hvilke prø ver der 
som minimum skal udføres af de kompetente myndigheder under int er­
operabilitetsprøverne. Der er ingen yderligere forskrifter for de procedurer, 
som skal følges ved udførelse af prøverne eller den pågældende type 
prøver.  
Spørgsmål vedrørende sikkerhedsattestering er ikke omfattet af dette 
tillæg. Såfremt nogle af de prøver, som kræves til typegodkende lse, 
udføres som led i sikkerhedsvurdering og -attestering, behøver disse 
prøver ikke udføres igen. I så fald er det tilstrækkeligt kun a t kontrollere 
resultaterne af disse sikkerhedsprøver. De krav, som der forven tes prøvet 
for (eller nærtbeslægtede prøver foretaget) som led i sikkerhed satteste­
ringen, er mærket med »*« i tillægget.  
De nummererede krav refererer til bilagets korpus, mens de øvri ge krav 
refererer til de andre tillæg (f.eks. refererer PIC_001 til kra vet PIC_001 i 
tillæg 3 Piktogrammer).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 392  
I dette tillæg er særskilt omhandlet typegodkendelse af bevægel sesføler, 
køretøjsenhed og eksternt GNSS-udstyr som komponenter i kontrol appa­
ratet. Hver komponent får sin egen typegodkendelsesattest, hvor i de øvrige 
kompatible komponenter angives. Funktionsprøvningen af bevægels es­
føleren (eller det eksterne GNSS-udstyr) foretages sammen med k øretøjs­
enheden og omvendt.  
Der kræves ikke interoperabilitet mellem hver enkelt model af b evægelses­
føleren/det eksterne GNSS-udstyr og hver enkelt model af køretø js­
enheden. I relevante tilfælde kan typegodkendelsen for en bevæg elsesføler 
(eller eksternt GNSS-udstyr) kun udstedes sammen med typegodken delsen 
for den pågældende køretøjsenhed og omvendt.  
▼M3 
Medlemsstatens myndighed med ansvar for funktionsprøverne for k øre­
tøjsenheder skal sikre, at den integrerede GNSS-modtager har be stået de 
OSNMA-prøver, der er beskrevet i dette tillæg. Disse prøver ans es for at 
være en del af funktionsprøvningen af køretøjsenheden eller det  eksterne 
GNSS-udstyr.  
▼B 
1.2. Referencer  
I dette tillæg henvises til følgende referencer:  
IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A : Cold  
IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests 
B: dry heat (sinusoidal).  
IEC 60068-2-6: Environmental testing — Part 2: Tests — Test Fc:  Vibra­
tion 
IEC 60068-2-14: Environmental testing; Part 2-14: Tests; Test N : Change 
of temperature  
IEC 60068-2-27: Environmental testing. Part 2: Tests. Test Ea a nd 
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) — Pro tection 
of electrical equipment against foreign objects, water and acce ss 
ISO 10605:2008 + Technical Corrigendum:2010 + AMD1:2014 Road 
vehicles — Test methods for electrical disturbances from electr ostatic 
discharge  
ISO 7637-1:2002 + AMD1: 2008 Road vehicles — Electrical disturb ances 
from conduction and coupling — Part 1: Definitions and general 
considerations.  
ISO 7637-2 Road vehicles — Electrical disturbances from conduct ion and 
coupling — Part 2: Electrical transient conduction along supply  lines only.  
ISO 7637-3 Road vehicles — Electrical disturbances from conduct ion and 
coupling — Part 3: Electrical transient transmission by capacit ive and 
inductive coupling via lines other than supply lines.  
ISO/IEC 7816-1 Identification cards — Integrated circuit(s) car ds with 
contacts — Part 1: Physical characteristics..  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 393  
ISO/IEC 7816-2 Information technology — Identification cards — Inte­
grated circuit(s) cards with contacts — Part 2: Dimensions and location of 
the contacts.  
ISO/IEC 7816-3 Information technology — Identification cards — Inte­
grated circuit(s) cards with contacts — Part 3: Electronic sign als and 
transmission protocol.  
ISO/IEC 10373-1:2006 + AMD1:2012 Identification cards — Test 
methods — Part 1: General characteristics  
ISO/IEC 10373-3:2010 + Technical Corrigendum:2013 Identificatio n 
cards — Test methods — Part 3: Integrated circuit cards with co ntacts 
and related interface devices  
ISO 16844-3:2004, Cor 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: Diagno stics 
ISO 16844-7 Road vehicles — Tachograph systems — Part 7: Parame ters 
ISO 534 Paper and board — Determination of thickness, density a nd 
specific volume  
▼M3 
RGODP JRC Technical Report — Receiver guidelines for OSNMA data  
processing (Retningslinjer for modtagere med henblik på OSNMA-d ata­
behandlingen)  
▼B 
FN/ECE R10 Uniform provisions concerning the approval of vehicl es with 
regard to electromagnetic compatibility (United Nation Economic  
Commission for Europe)  
2. FUNKTIONSPRØVER FOR KØRETØJSENHED  
▼M1 
Nr. Prøve  Beskrivelse  Tilknyttede krav  
1. Administrativ undersøgelse  
1.1 Dokumentation  Dokumentationens korrekthed  
1.2 Fabrikantens prøv­
ningsresultater  Resultater af fabrikantens prøvning, udført 
med kombination. 
Eftervisning på papir  88, 89,91  
2. Eftersyn  
2.1 Overensstemmelse med dokumentationen  
2.2 Identifikation/mærkning  224 til 226  
2.3 Materialer  219 til 223  
2.4 Plombering  398, 401 til 405  
2.5 Eksterne grænseflader  
3. Funktionsprøver  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 394  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
▼M3 
3.1 Ydede funktioner  02, 03, 04, 05, 07, 382  
3.2 Funktionsmåder  09 til 11*, 134, 135  
3.3 Funktioner og ret til dataadgang  12* 13*, 382, 383, 386 til 389  
3.4 Overvågning af isætning og udtagning af kort  15, 16, 17, 18, 19*, 20*, 134  
3.5 Måling af hastighed, position og afstand  21 til 37  
3.6 Tidsmåling (prøvning udført ved 20 °C)  38 til 43  
3.7 Overvågning af føreraktiviteter  44 til 53, 134  
3.8 Overvågning af kørestatus  54, 55 og 134  
3.9 Indlæsning foretaget af fører  56 til 62c  
3.10 Forvaltning af virksomhedslåse  63 til 68  
3.11 Overvågning af kontrolaktiviteter  69, 70  
3.12 Detektion af hændelser og/eller fejl  71 til 88a, 134  
3.13 Identifikationsdata for apparat  93*, 94*, 97, 100  
3.14 Data vedrørende isætning og udtagning af førerkort eller værks tedskort  102* til 104*  
3.15 Føreraktivitetsdata  105* til 107*  
3.16 Data om steder og positioner  108* til 112*  
3.17 Kilometertællerdata  113* til 115*  
3.18 Detaljerede hastighedsdata  116*  
3.19 Data vedrørende hændelser  117*  
3.20 Data vedrørende fejl  118*  
3.21 Kalibreringsdata  119* til 121*  
3.22 Tidsjusteringsdata  124*, 125*  
3.23 Kontrolaktivitetsdata  126*, 127*  
3.24 Data vedrørende virksomhedslåse  128*  
3.25 Data vedrørende dataoverførselsaktivitet  129*  
3.26 Data vedrørende særlige omstændigheder  130*, 131*  
3.27 Data vedrørende takografkort  132*, 133*  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 395  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
3.28 Grænsepassager  133a* til 133d*  
3.29 Laste-/losseoperation  133e* til 133i*  
3.30 Digitalt kort  133j* til 133t*  
3.31 Registrering og lagring på takografkort  136, 137, 138*, 139*, 141*, 
142, 143 
144, 145, 146*, 147*, 147a*, 
147b*, 148*, 149, 150, 150a  
3.32 Visning på skærm  90, 134 
151 til 168, 
PIC_001, DIS_001  
3.33 Trykning  90, 134 
169 til 181, PIC_001, 
PRT_001 til PRT_014  
3.34 Advarsel  134, 182 til 191, 
PIC_001  
3.35 Dataoverførsel til eksterne medier  90, 134, 192 til 196  
3.36 Fjernkommunikation i forbindelse med målrettede vejsidekontrol ler 197 til 199  
3.37 Dataudveksling med yderligere eksterne enheder  200, 201  
3.38 Kalibrering  202 til 206*, 383, 384, 386 til 
391 
3.39 Kalibreringskontrol ved vejsiden  207 til 209  
3.40 Tidsjustering  210 til 212*  
3.41 Overvågning af grænsepassager  226a til 226c  
3.42 Softwareopdatering  226d til 226f  
3.43 Fravær af forstyrrelse af ekstra funktioner  06, 425  
3.44 Grænseflade til bevægelsesføler  02, 122  
3.45 Eksternt GNSS-udstyr  03, 123  
3.46 Det kontrolleres, at køretøjsenheden detekterer, registrerer o g lagrer den/ 
de hændelse(er) og/eller den/de fejl, som køretøjsenhedsfabrika nten har 
defineret, hvis en samparret bevægelsesføler reagerer på magnet iske 
felter, som forstyrrer køretøjets bevægelsesregistrering.  217 
3.47 Krypteringsprogram og standardiserede domæneparametre  CSM_48, CSM_50  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 396  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
4. Miljøprøver  
4.1 Temperatur  Funktionaliteten eftervises gennem: 
Prøvning i overensstemmelse med ISO 
16750-4, kapitel 5.1.1.2: Funktionsprøve 
ved lav temperatur (72 timer ved – 20 °C) 
For denne prøve henvises til IEC 60068-2-1: 
Environmental testing — Part 2-1: Tests — 
Test A: Cold 
Test i overensstemmelse med ISO 16750-4: 
kapitel 5.1.2.2: High temperature operation 
test (72 timer ved 70 °C) 
For denne prøve henvises til IEC 60068-2-2: 
Basic environmental testing procedures; part 
2: tests; tests B: dry heat 
Test i overensstemmelse med ISO 16750-4: 
kapitel 5.3.2: Rapid change of temperature 
with specified transition duration (– 20°C/ 
70 °C, 20 cycles, dwell time 2h at each 
temperature) 
Et reduceret sæt prøvninger (af dem, som 
foreskrives i denne tabels punkt 3) kan 
udføres ved den lave temperatur, den høje 
temperatur og med gennemgang af tempera­
turcyklusserne  213 
4.2 Fugtighed  Det eftervises, at køretøjsenheden kan 
modstå en cyklisk fugtighedsprøve (varme­
prøve) ved gennemgang af IEC 60068-2-30, 
prøve Db, seks 24 timers cyklusser, hvor 
hver temperatur varierer fra + 25 °C til 
+ 55 °C, og hvor den relative fugtighed er 
97 % ved + 25 °C og 93 % ved + 55 °C  214 
4.3 Mekanisk masse  1. Sinusvibrationer. 
Det kontrolleres, at køretøjsenheden kan 
modstå sinusvibrationer med følgende 
egenskaber: 
Konstant skift mellem 5 og 11 Hz: 
Topværdi 10 mm 
konstant acceleration mellem 11 og 
300 Hz: 5 g 
Prøvning for dette krav sker med IEC 
60068-2-6, prøve Fc, med en mindste 
prøvningsvarighed på 3 × 12 timer (12 
timer for hver akse) 
ISO 16750-3 kræver ikke en sinusvibra­
tionsprøvning for enheder, der sidder i 
afkoblede førerhuse. 
2. Tilfældige vibrationer: 
Test i overensstemmelse med ISO 16750- 
3: kapitel 4.1.2.8: Test VIII: Commercial 
vehicle, decoupled vehicle cab  219 ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 397  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
Prøvning for tilfældige vibrationer, 10...2 
000 Hz, kvadratisk middel, lodret: 21,3 m/ 
s 2 , kvadratisk middel, langsgående: 11,8 m/ 
s 2 , kvadratisk middel, tværgående: 13,1 m/ 
s 2 , 3 akser, 32 timer pr. akse, herunder 
temperaturcyklus: – 20...70 °C. 
For denne prøve henvises til IEC 60068-2- 
64: Environmental testing - Part 2-64: Tests 
- Test Fh: Vibration, broadband random and 
guidance - 
3. Stød: 
mekanisk stød med 3 g halv-sinus i over­
ensstemmelse med ISO 16750. 
De ovenfor beskrevne prøvninger udføres på 
forskellige prøveeksemplarer af den afprø­
vede apparattype.  
4.4 Beskyttelse mod vand 
og fremmedlegemer  Prøvning i overensstemmelse med ISO 
20653: Road vehicles — Degree of protec­
tion (IP code) — Protection of electrical 
equipment against foreign objects, water 
and access (No change in parameters); 
Minimum value IP 40  220, 221  
4.5 Overspændingsbeskyt­
telse Det kontrolleres, at køretøjsenheden kan 
modstå en strømforsyning på: 
24 V-udførelse: 34 V ved + 40 °C 1 time 
12 V-udførelse: 17 V ved + 40 °C 1 time 
(ISO 16750-2)  216 
4.6 Beskyttelse mod 
omvendt polaritet  Det kontrolleres, at køretøjsenheden kan 
modstå polvending af strømforsyningen 
(ISO 16750-2)  216 
4.7 Kortslutningsbeskyt­
telse Det kontrolleres, at ind- og udgangssignaler 
er beskyttet mod kortslutning til strømfor­
syningen og til stel 
(ISO 16750-2)  216 
5. Prøver for elektromagnetisk kompatibilitet  
5.1 Strålingsemission og 
følsomhed  Overensstemmelse med ECE-regulativ R10  218  
5.2 Elektrostatisk udlad­
ning Overensstemmelse med ISO 10605:2008 + 
Technical Corrigendum:2010 + 
AMD1: 2014: +/– 4 kV for kontakt og +/– 
8 kV for udladning i luften  218 ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 398  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
5.3 Transient nedre lednin­
gsoverførsel for strøm­
forsyning  For 24 V-udførelse: overensstemmelse med 
ISO 7637-2 og ECE-regulativ nr. 10, rev. 3: 
impuls 1a: Vs = – 450 V, Ri = 50 ohm 
impuls 2 a: Vs = + 37 V, Ri = 2 ohm 
impuls 2b: Vs = + 20 V, Ri = 0,05 ohm 
impuls 3 a: Vs = – 150 V, Ri = 50 ohm 
impuls 3b: Vs = + 150 V, Ri = 50 ohm 
impuls 4: Vs = – 16 V Va = – 12 V 
t6 = 100 ms 
impuls 5: Vs = + 120 V Ri = 2,2 ohm td = 
250 ms 
For 12 V-udførelse: overensstemmelse med 
ISO 7637-1 og ECE-regulativ nr. 10, rev. 3: 
impuls 1: Vs = – 75 V, Ri = 10 ohm 
impuls 2a: Vs = + 37 V, Ri = 2 ohm 
impuls 2b: Vs = + 10 V, Ri = 0,05 ohm 
impuls 3a: Vs = – 112 V, Ri = 50 ohm 
impuls 3b: Vs = + 75 V, Ri = 50 ohm 
impuls 4: Vs = – 6 V Va = – 5 V 
t6 = 15 ms 
impuls 5: Vs = + 65 V, Ri = 3 ohm td = 
100 ms 
Impuls 5 skal kun afprøves for køretøjs­
enheder bestemt til montering i køretøjer 
uden ekstern fælles overbelastningsbeskyt­
telse 
For så vidt angår overbelastningsbeskyttelse 
henvises til ISO 16750-2, 4. udgave, kapitel 
4.6.4.  218 
▼B 
3. FUNKTIONSPRØVER FOR BEVÆGELSESFØLER  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
1. Administrativ undersøgelse  
1.1 Dokumentation  Dokumentationens korrekthed  
2. Besigtigelse  
2.1. Overensstemmelse med dokumentationen  
2.2. Identifikation/mærkning  225, 226  
2.3 Materialer  219 til 223  
2.4. Plombering  398, 401 til 405  
3. Funktionsprøver  
3.1 Identifikationsdata for føler  95 til 97*  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 399  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
3.2 Bevægelsesføler — samparring med køretøjsenhed  122*, 204  
3.3 Bevægelsesregistrering 
Nøjagtighed af målingen af bevægelsen  30 til 35  
3.4 Grænseflade for køretøjsenhed  0 2  
3.5 Det kontrolleres, at bevægelsesføleren er upåvirkelig af konst ante magnetiske 
felter. Ellers kontrolleres det, at bevægelsesføleren reagerer på konstante magne­
tiske felter, som forstyrrer køretøjets bevægelsesregistrering,  således at en 
tilsluttet køretøjsenhed kan detektere, registrere og lagre føl erfejl.  217 
4. Miljøprøver  
4.1 Arbejdstemperatur  Funktionaliteten (som defineret i prøve nr. 3.3) 
efterprøves i temperaturintervallet [– 40 °C; + 
135 °C] gennem: 
IEC 60068-2-1 prøve Ad, med en prøvnings­
varighed på 96 timer ved den laveste temperatur 
To min 
IEC 60068-2-2 prøve Bd, med en prøvnings­
varighed på 96 timer ved den højeste temperatur 
To max 
Prøvning i overensstemmelse med ISO 16750-4: 
Chapter 5.1.1.2: Funktionsprøve ved lav tempe­
ratur (24 timer ved – 40 °C) 
For denne prøve henvises til IEC 60068-2-1: 
Environmental testing — Part 2-1: Tests — 
Test A: Cold, IEC 68-2-2 prøve Bd, med en 
prøvningsvarighed på 96 timer ved temperaturer 
på ned til – 40 °C. 
Prøvning i overensstemmelse med ISO 16750-4: 
Chapter 5.1.2.2: Funktionsprøve ved høj tempe­
ratur (96 timer ved 135 °C) 
For denne prøve henvises til IEC 60068-2-2: 
Basic environmental testing procedures; part 2: 
tests; tests B: dry heat  213 
4.2 Temperaturcyklusser  Prøvning i overensstemmelse med ISO 16750-4: 
Chapter 5.3.2: Rapid change of temperature 
with specified transition duration (– 40 °C/ 
135 °C, 20 cyklusser, holdetid 30 min. ved 
hver temperatur) 
IEC 60068-2-14: Environmental testing; Part 2- 
14: Tests; Test N: Change of temperature  213 
4.3 Fugtighedscyklusser  Funktionaliteten (som defineret i prøvning 
nr. 3.3) eftervises ved gennemgang af IEC 
60068-2-30, prøve Db, seks 24-timers 
cyklusser, hvor hver temperatur varierer fra + 
25 °C til + 55 °C.  214 ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 400  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
4.4 Vibration  ISO 16750-3: Chapter 4.1.2.6: Test VI: 
Commercial vehicle, engine, gearbox 
Blandet vibrationsprøvning, inkl. 
a) sinusvibrationsprøvning, 20...520 Hz, 11,4 
… 120 m/s  2 , <= 0,5 okt./min 
b) Prøvning for tilfældige vibrationer, 
10…2 000 Hz, kvadratisk middel 177 m/s  2 
94 timer pr. akse, inkl. temperaturcyklus – 
20…70 °C 
For denne prøve henvises til IEC 60068-2-80: 
Environmental testing — Part 2-80: Tests — 
Test Fi: Vibration — Mixed mode  219 
4.5 Mekanisk stød  ISO 16750-3: Chapter 4.2.3: Test VI: Test for 
devices in or on the gearbox 
stød med halv-sinus, acceleration efter aftale 
inden for området 3 000…15 000 m/s  2 , impuls­
varighed efter aftale, dog < 1 ms, antal stød: 
efter aftale 
For denne prøve henvises til IEC 60068-2-27: 
Environmental testing. Part 2: Tests. Test Ea 
and guidance: Shock  219 
4.6 Beskyttelse mod vand og 
fremmedlegemer  Prøvning i overensstemmelse med ISO 20653: 
Road vehicles — Degree of protection (IP code) 
— Protection of electrical equipment against 
foreign objects, water and access 
(Målværdi: IP 64)  220, 221  
4.7 Beskyttelse mod omvendt 
polaritet  Det kontrolleres, at bevægelsesføleren kan 
modstå polvending af strømforsyningen  216 
4.8 Kortslutningsbeskyttelse  Det kontrolleres, at ind- og udgangssignaler er 
beskyttet mod kortslutning til strømforsyningen 
og til stel  216 
5. Elektromagnetisk kompatibilitet  
5.1 Strålingsemission og 
følsomhed  Overensstemmelse med ECE-regulativ R10 
påvises  218 
5.2 Elektrostatisk udladning  Overensstemmelse med ISO 10605:2008 + 
Technical Corrigendum:2010 + AMD1:2014: 
+/– 4 kV for kontakt og +/– 8 kV for udladning 
i luften  218 ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 401  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
5.3 Transient nedre lednings­
overførsel for datalinjerne  For 24V-udførelse: overensstemmelse med ISO 
7637-2 og ECE-regulativ nr. 10, rev. 3: 
impuls 1a: Vs = – 450V, Ri = 50 ohm 
impuls 2a: Vs = + 37 V, Ri = 2 ohm 
impuls 2b: Vs = + 20V, Ri = 0,05 ohm 
impuls 3a: Vs = – 150V, Ri = 50 ohm 
impuls 3b: Vs = + 150V, Ri = 50 ohm 
impuls 4: Vs = – 16 V Va = – 12 V 
t6 = 100 ms 
impuls 5: Vs = + 120 V Ri = 2,2 ohm 
td = 250 ms 
For 12 V-udførelse: overensstemmelse med ISO 
7637-1 og ECE-regulativ nr. 10, rev. 3: 
impuls 1: Vs = – 75V, Ri = 10 ohm 
impuls 2a: Vs = + 37 V, Ri = 2 ohm 
impuls 2b: Vs = + 10V, Ri = 0,05 ohm 
impuls 3a: Vs = – 112V, Ri = 50 ohm 
impuls 3b: Vs = + 75V, Ri = 50 ohm 
impuls 4: Vs = – 6 V Va = – 5 V t6 = 15 ms 
impuls 5: Vs = + 65 V Ri = 3 ohm td = 100 ms 
Impuls 5 skal kun afprøves for køretøjsenheder 
bestemt til montering i køretøjer uden ekstern 
fælles overbelastningsbeskyttelse 
For så vidt angår overbelastningsbeskyttelse 
henvises til ISO 16750-2, 4. udgave, afsnit 
4.6.4.  218 
4. FUNKTIONSPRØVER FOR TAKOGRAFKORT  
Prøvning i overensstemmelse med dette afsnit 4,  
nr. 5 »Protokolprøver«  
nr. 6 »Kortstruktur« og  
nr. 7 »Funktionsprøver«,  
kan foretages af bedømmeren eller certificeringsmyndigheden und er 
sikkerhedsattesteringen af chipmodulet i henhold til de fællese uropæiske 
kriterier.  
Prøvning nr. 2.3 og 4.2 er de samme. Disse er de mekaniske prøv ninger af 
kombinationen kort og chipmodul. Hvis en af disse komponenter ( kort 
eller chipmodul) ændres, er disse prøvninger nødvendige.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 402  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
1. Administrativ undersøgelse  
1.1 Dokumentation  Dokumentationens korrekthed  
2 Kort  
2.1 Tryk  Det kontrolleres, at alle faciliteter til beskyttelse samt 
synlige data er korrekt udskrevet på kortet og over­
ensstemmende. 
[Designation] 
Bilag 1C, afsnit 4.1 »Synlige data«, 227) 
Forsiden skal indeholde: 
svarende til kortets art, ordet »Førerkort« eller 
»Kontrolkort« eller »Værkstedskort« eller »Virksom­
hedskort«, trykt med store bogstaver på de(t) offici­
elle sprog i den medlemsstat, som har udstedt kortet. 
[Medlemsstatens navn] 
Bilag 1C, afsnit 4.1 »Synlige data«, 228) 
Forsiden skal indeholde: 
angivelse af navnet på den udstedende medlemsstat 
(valgfrit). 
[Mærke] 
Bilag 1C, afsnit 4.1 »Synlige data«, 229) 
Forsiden skal indeholde: 
den udstedende medlemsstats nationalitetsmærke, 
trykt med negativ skrift i et blåt rektangel og omgivet 
af 12 gule stjerner. 
[Fortegnelse] 
Bilag 1C, afsnit 4.1 »Synlige data«, 232) 
Bagsiden skal indeholde: 
en forklaring til de nummererede punkter på kortets 
forside 
[Farve] 
Bilag 1C, afsnit 4.1 »Synlige data«, 234) 
Takografkort skal være trykt med følgende dominer- 
ende baggrundsfarve: 
— førerkort: hvid 
— værkstedskort: rød 
— kontrolkort: blå 
— virksomhedskort: gul.  227 til 229, 232, 234 
til 236  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 403  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
[Sikkerhed] 
Bilag 1C, afsnit 4.1 »Synlige data«, 235) 
Takografkort skal have mindst følgende egenskaber til 
beskyttelse mod forfalskning og indgreb fra uved- 
kommende: 
— sikkerhedsbaggrund med fint slangeornament og 
regnbuetryk 
— mindst én tofarvet mikroprintlinje. 
[Mærker] 
Bilag 1C, afsnit 4.1 »Synlige data«, 236) 
Medlemsstaterne kan tilføje farver eller mærker, f.eks. 
nationale symboler og sikkerhedsfeatures. 
[Godkendelsesmærke] 
Takografkort skal indeholde et godkendelsesmærke. 
Godkendelsesmærket består af 
— et rektangel, i hvilket er anbragt bogstavet »e« 
efterfulgt af kodetallet eller kendingsbogstavet for 
det land, som har meddelt typegodkendelsen 
— et typegodkendelsesnummer, som svarer til num- 
meret i typegodkendelsesdokumentet for et tako- 
grafkort, og som anbringes et sted i nærheden af 
rektanglet.  
2.2 Mekanisk prøvning  
[Kortstørrelse] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[5] Dimensionering af kort 
[5.1] Kortstørrelse 
[5.1.1] Kortdimensioner og tolerancer 
korttype ID-1 Ubrugt kort 
[Kortkanter] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[5] Dimensionering af kort 
[5.1] Kortstørrelse 
[5.1.2] Kortkanter  240, 243 
ISO/IEC 7810  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 404  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
[Kortopbygning] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[6] Kortopbygning 
[Kortmaterialer] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[7] Kortmaterialer 
[Bøjestivhed] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Kortegenskaber 
[8.1] Bøjestivhed 
[Toksicitet] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Kortegenskaber 
[8.3] Toksicitet 
[Modstandsdygtighed over for kemiske stoffer] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Kortegenskaber 
[8.4] Modstandsdygtighed over for kemiske stoffer 
[Kortstabilitet] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Kortegenskaber 
[8.5] Kortets formbestandighed/krumning afhængigt 
af temperatur og fugtighed  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 405  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
[Lys] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Kortegenskaber 
[8.6] Lys 
[Holdbarhed] 
Bilag 1C, afsnit 4.4 »Miljømæssige og elektriske 
specifikationer«, 241) 
Takografkort skal kunne fungere korrekt i fem år, hvis 
d e a n v e n d e s i o v e r e n s s t e m m e l s e m e d d e  
miljømæssige og elektriske specifikationer. 
[Afrivningsstyrke] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Kortegenskaber 
[8.8] Afrivningsstyrke 
[Adhæsion eller blokering] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Kortegenskaber 
[8.9] Adhæsion eller blokering 
[Krumning] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Kortegenskaber 
[8.11] Samlet kortkrumning 
[Varmebestandighed] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Kortegenskaber 
[8.12] Varmebestandighed  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 406  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
[Overfladeforvrængninger] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Kortegenskaber 
[8.13] Overfladeforvrængninger 
[Kontaminering] 
Takografkort skal overholde 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Kortegenskaber 
[ 8 . 1 4 ] K o n t a m i n e r i n g o g s a m s p i l b l a n  d  t  
kortkomponenter  
2.3 Mekanisk prøvning 
med chipmodul 
indlejret  [Bøjning] 
Takografkort skal overholde 
ISO/IEC 7810:2003/Amd. 1:2009, Identification 
cards — Physical characteristics, Amendment 1: 
Criteria for cards containing integrated circuits 
[9.2] Dynamisk bøjespænding 
Samlet antal bøjningscyklusser: 4 000. 
[Vridning] 
Takografkort skal overholde 
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards 
— Physical characteristics, Amendment 1: Criteria for 
cards containing integrated circuits 
[9.3] Dynamisk vridningsspænding 
Samlet antal vridningscyklusser: 4 000.  ISO/IEC 7810  
3 Modul  
3.1 Modul  Modulet består af chipindkapslingen og kontakt­
pladen. 
[Overfladeprofil] 
Takografkort skal overholde 
ISO/IEC 7816-1:2011, Identification cards — Inte­
grated circuit cards — Part 1: Cards with contacts 
— Physical characteristics 
[4.2] Kontakters overfladeprofil  ISO/IEC 7816  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 407  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
[Mekanisk styrke] 
Takografkort skal overholde 
ISO/IEC 7816-1:2011, Identification cards — Inte­
grated circuit cards — Part 1: Cards with contacts 
— Physical characteristics 
[4.3] Mekanisk styrke (ved kort og kontakter) 
[Elektrisk modstand] 
Takografkort skal overholde 
ISO/IEC 7816-1:2011, Identification cards — Inte- 
grated circuit cards — Part 1: Cards with contacts — 
Physical characteristics 
[4.4] Elektrisk modstand (ved kontakter) 
[Dimensionering] 
Takografkort skal overholde 
ISO/IEC 7816-2:2007, Identification cards — Inte- 
grated circuit cards — Part 2: Cards with contacts — 
Dimension and location of the contacts 
[3] Dimensionering af kontakterne 
[Placering] 
Takografkort skal overholde 
ISO/IEC 7816-2:2007, Identification cards — Inte- 
grated circuit cards — Part 2: Cards with contacts — 
Dimension and location of the contacts 
[4] Antal kontakter og deres placering 
I tilfælde af moduler med seks kontakter, indgår 
kontakt »C4« og »C8« ikke i denne prøvning.  
4 Chip  
4.1 Chip  
[Arbejdstemperatur] 
Chippen i et takografkort skal fungere ved en omgi­
vende temperatur i området mellem – 25 °C og + 
85 °C.  241 til 244 
ECE R10 
ISO/IEC 7810 
ISO/IEC 10373  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 408  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
[Temperatur og fugtighed] 
Bilag 1C, afsnit 4.4 »Miljømæssige og elektriske 
specifikationer«, 241) 
Takografkort skal kunne fungere korrekt under alle 
de klimabetingelser, som normalt optræder på fælles­
skabets område, og som det mindste i temperatur­
området – 25 °C til + 70 °C med lejlighedsvise 
maksima på indtil + 85 °C, idet der ved »lejlig­
hedsvis« forstås højst 4 timer ad gangen og højst 
100 gange i løbet af kortets levetid. 
Takografkortene udsættes trinvist for følgende 
temperatur- og fugtighedsforhold i det givne tidsrum. 
Efter hvert trin afprøves takografkortenes elektriske 
funktionalitet. 
1. Temperatur på – 20 °C i 2 timer. 
2. Temperatur på +/–0 °C i 2 timer. 
3. Temperatur på + 20 °C, 50 % RF, i 2 timer. 
4. Temperatur på 50 °C, 50 % RF, i 2 timer. 
5. Temperatur på 70 °C, 50 % RF, i 2 timer. 
Temperaturen øges periodisk til + 85 °C, 50 % 
RF, i 60 min. 
6. Temperatur på 70 °C, 85 % RF, i 2 timer. 
Temperaturen øges periodisk til +85 °C, 85 % 
RF, i 30 min. 
[Fugtighed] 
Bilag 1C, afsnit 4.4 »Miljømæssige og elektriske 
specifikationer«, 242) 
Takografkort skal fungere korrekt inden for fugtigh- 
edsintervallet 10 % — 90 %. 
[Elektromagnetisk kompatibilitet — EMC] 
Bilag 1C, afsnit 4.4 »Miljømæssige og elektriske 
specifikationer«, 244 
Under drift skal takografkort opfylde kravene i ECE 
R10 om elektromagnetisk kompatibilitet.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 409  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
[Statisk elektricitet] 
Bilag 1C, afsnit 4.4 »Miljømæssige og elektriske 
specifikationer«, 244 
Under drift skal takografkort være beskyttet mod 
elektrostatiske udladninger. 
Takografkort skal overholde 
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards 
— Physical characteristics, Amendment 1: Criteria for 
cards containing integrated circuits 
[9.4] Statisk elektricitet 
[9.4.1] Kort med kontakt og integreret kredsløb 
Prøvespænding: 4 000 V 
[Røntgen] 
Takografkort skal overholde 
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards 
— Physical characteristics, Amendment 1: Criteria for 
cards containing integrated circuits 
[9.1] Røntgen 
[Ultraviolet lys] 
ISO/IEC 10373-1:2006, Identification cards — Test 
methods — Part 1: General characteristics 
[5.11] Ultraviolet lys 
[3-hjulsprøvning] 
Takografkort skal overholde 
ISO/IEC 10373-1:2006/Amd. 1:2012, Identification 
cards — Test methods — Part 1: General character- 
istics, Amendment 1 
[5.22] Kort med integreret kreds — mekanisk styrke: 
3-hjulsprøvning af kort med integreret kreds og 
kontakter 
[Coating] 
Takografkort skal overholde 
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 — DA — 21.08.2023 — 003.001 — 410  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
4.2 Mekanisk prøvning af 
chipmodul indlejret i 
kort-> samme som 2.3  [Bøjning] 
Takografkort skal overholde 
ISO/IEC 7810:2003/Amd. 1:2009, Identification 
cards — Physical characteristics, Amendment 1: 
Criteria for cards containing integrated circuits 
[9.2] Dynamisk bøjespænding 
Samlet antal bøjningscyklusser: 4 000. 
[Vridning] 
Takografkort skal overholde 
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards 
— Physical characteristics, Amendment 1: Criteria for 
cards containing integrated circuits 
[9.3] Dynamisk vridningsspænding 
Samlet antal vridningscyklusser: 4 000.  ISO/IEC 7810  
5 Protokolprøver  
5.1 ATR  Kontroller, at ATR er overensstemmende  ISO/IEC 7816-3 
TCS_14, TCS_17, 
TCS_18  
5.2 T=0  Kontroller, at T = 0-protokollen er overensstemmende  ISO/IEC 7816-3 
TCS_11, TCS_12, 
TCS_13, TCS_15  
5.3 PTS  Kontroller, at PTS-kommandoen er overensstem­
mende, ved at sætte T = 1 fra T = 0.  ISO/IEC 7816-3 
TCS_12, TCS_19, 
TCS_20, TCS_21  
5.4 T=1  Kontroller, at T = 1-protokollen er overensstemmende  ISO/IEC 7816-3 
TCS_11, TCS_13, 
TCS_16  
6 Kortets struktur  
6.1 Kontroller, at kortets filstruktur er overensstemmende, 
ved at kontrollere for tilstedeværelse af påbudte filer i 
kortet og adgangsbetingelserne til dem  TCS_22 til TCS_28 
TCS_140 til 
TCS_179  
7 Funktionsprøver  
7.1 Normal behandling af 
data Hver tilladt brug af hver kommando afprøves mindst 
én gang (f.eks. afprøves kommandoen UPDATE 
BINARY med CLA = »00«, CLA = »0C« og med 
andre P1-, P2- og Lc-parametre). 
Kontroller, at operationerne faktisk er udført på kortet 
(f.eks. ved at læse den fil, kommandoen er udført på)  TCS_29 til TCS_139  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 411  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
7.2 Fejlmeddelelser  Hver fejlmeddelelse afprøves mindst én gang (som 
foreskrevet i tillæg 2) for hver kommando. 
Hver fælles fejl afprøves mindst én gang (bortset fra  
»6400«  integritetsfejl, der kontrolleres som led i 
sikkerhedsattesteringen)  
7.3 Krypteringsprogram og standardiserede domæneparametre  CSM_48, CSM_50  
8 Tilpasning  
8.1 Optisk tilpasning  Bilag 1C, afsnit 4.1 »Synlige data«, 230) 
Forsiden skal indeholde: 
oplysninger, der er specifikke for det udstedte kort. 
Bilag 1C, afsnit 4.1 »Synlige data«, 231) 
Forsiden skal indeholde: 
datoer i formatet »dd/mm/yyyy« eller »dd.mm.yyyy« 
(dag, måned, år). 
Bilag 1C, afsnit 4.1 »Synlige data«, 235) 
Takografkort skal have mindst følgende egenskaber til 
beskyttelse mod forfalskning og indgreb fra uved- 
kommende: 
— i fotografiets område skal sikkerhedsbaggrund- 
og fotografi overlappe.  230, 231, 235  
5. PRØVNING AF EKSTERNT GNSS-UDSTYR  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
1. Administrativ undersøgelse  
1.1 Dokumentation  Dokumentationens korrekthed  
2. Visuel inspektion af eksternt GNSS-udstyr  
2.1. Overensstemmelse med dokumentationen  
2.2. Identifikation/mærkning  224 til 226  
2.3 Materialer  219 til 223  
3. Funktionsprøver  
3.1 Identifikationsdata for føler  98,99  
3.2 Sammenkobling af eksternt GNSS-modul med køretøjsenhed  123, 205  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 412  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
3.3 GNSS-position  36, 37  
3.4 Grænseflade for køretøjsenhed, hvis GNSS-modtageren er ekstern  i forhold til 
køretøjsenheden  03 
3.5 Krypteringsprogram og standardiserede domæneparametre  CSM_48, CSM_50  
4. Miljøprøver  
4.1 Temperatur  Funktionaliteten eftervises gennem: 
Prøvning i overensstemmelse med ISO 16750-4, Chapter 
5.1.1.2: Funktionsprøve ved lav temperatur (72 timer ved – 
20 °C) 
For denne prøve henvises til IEC 60068-2-1: Environmental 
testing — Part 2-1: Tests — Test A: Cold 
Test i overensstemmelse med ISO 16750-4: Chapter 5.1.2.2: 
High temperature operation test (72 timer ved 70 °C) 
For denne prøve henvises til IEC 60068-2-2: Basic environ­
mental testing procedures; part 2: tests; tests B: dry heat 
Prøvning i overensstemmelse med ISO 16750-4: Chapter 
5.3.2: Rapid change of temperature with specified transition 
duration (– 20 °C/70 °C, 20 cyklusser, holdetid 1 time ved 
hver temperatur) 
Et reduceret sæt prøvninger (af dem, som foreskrives i afsnit 
3 af denne tabel) kan udføres ved den lave temperatur, den 
høje temperatur og med gennemgang af temperaturcyklus­
serne  213 
4.2 Fugtighed  Det eftervises, at køretøjsenheden kan modstå en cyklisk 
fugtighedsprøve (varmeprøve) ved gennemgang af IEC 
60068-2-30, prøve Db, seks 24 timers cyklusser, hvor hver 
temperatur varierer fra + 25 °C til + 5 °C, og hvor den rela­
tive fugtighed er 97 % ved + 25 °C og 93 % ved + 55 °C  214 
4.3 Mekanisk 
masse  1. Sinusvibrationer. 
Det kontrolleres, at køretøjsenheden kan modstå sinus­
vibrationer med følgende egenskaber: 
Konstant skift mellem 5 og 11 Hz: Topværdi 10mm 
konstant acceleration mellem 11 og 300 Hz: 5g 
Prøvning for dette krav sker med IEC 60068-2-6, prøve 
Fc, med en mindste prøvningsvarighed på 3 × 12 timer 
(12 timer for hver akseretning) 
ISO 16750-3 kræver ikke en sinusvibrationsprøvning for 
enheder, der sidder i afkoblede førerhuse.  219 ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 413  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
2. Tilfældige vibrationer: 
Prøvning i overensstemmelse med ISO 16750-3: Chapter 
4.1.2.8: Test VIII: Commercial vehicle, decoupled vehicle 
cab 
Prøvning for tilfældige vibrationer, 10…2 000 Hz, kvadra- 
tisk middel, lodret: 21,3 m/s  2 , kvadratisk middel, langs- 
gående: 11,8 m/s  2 , kvadratisk middel, tværgående: 
13,1 m/s  2 , 3 akser, 32 timer pr. akse, herunder temper- 
aturcyklus: – 20…70 °C. 
For denne prøve henvises til IEC 60068-2-64: Environ- 
mental testing — Part 2-64: Tests — Test Fh: Vibration, 
broadband random and guidance 
3. Stød: 
mekanisk stød med 3g halv-sinus i overensstemmelse med 
ISO 16750. 
De ovenfor beskrevne prøvninger udføres på forskellige 
prøveeksemplarer af den afprøvede apparattype.  
4.4 Beskyttelse 
mod vand og 
fremmedle­
gemer  Prøvning i overensstemmelse med ISO 20653: Road vehicles 
— Degree of protection (IP code) — Protection of electrical 
equipment against foreign objects, water and access (no 
change in parameters)  220, 221  
4.5 Overspæn­
dings-beskyt­
telse Det kontrolleres, at køretøjsenheden kan modstå en strømfor­
syning på:  216 
24 V-udførelse:  34V ved + 40 °C 1 
time 
12 V-udførelse:  17 V ved + 40 °C 1 
time 
(ISO 16750-2, punkt 4.3)  
4.6 Beskyttelse 
mod omvendt 
polaritet  Det kontrolleres, at køretøjsenheden kan modstå polvending 
af strømforsyningen 
(ISO 16750-2, punkt 4.7)  216 
4.7 Kortslutnings- 
beskyttelse  Det kontrolleres, at ind- og udgangssignaler er beskyttet mod 
kortslutning til strømforsyningen og til stel 
(ISO 16750-2, punkt 4.10)  216 
5 Prøver for elektromagnetisk kompatibilitet  
5.1 Strålingsemission 
og følsomhed  Overensstemmelse med ECE-regulativ R10  218  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 414  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
5.2 Elektrostatisk 
udladning  Overensstemmelse med ISO 10605:2008 + Technical Corri­
gendum:2010 + AMD1:2014: +/– 4 kV for kontakt og +/– 
8 kV for udladning i luften  218 
5.3 Transient nedre 
ledningsover­
førsel for 
strømforsyning  For 24V-udførelse: overensstemmelse med ISO 7637-2 og 
ECE-regulativ nr. 10, rev. 3: 
impuls 1a: Vs = – 450V, Ri = 50 ohm 
impuls 2a: Vs = + 37 V, Ri = 2 ohm 
impuls 2b: Vs = + 20V, Ri = 0,05 ohm 
impuls 3a: Vs = – 150V, Ri = 50 ohm 
impuls 3b: Vs = + 150V, Ri = 50 ohm 
impuls 4: Vs = – 16 V Va = – 12 V t6 = 100 ms 
impuls 5: Vs = + 120 V Ri = 2,2 ohm td = 250 ms 
For 12 V-udførelse: overensstemmelse med ISO 7637-1 og 
ECE-regulativ nr. 10, rev. 3: 
impuls 1: Vs = – 75V, Ri = 10 ohm 
impuls 2a: Vs = + 37 V, Ri = 2 ohm 
impuls 2b: Vs = + 10V, Ri = 0,05 ohm 
impuls 3a: Vs = – 112V, Ri = 50 ohm 
impuls 3b: Vs = + 75V, Ri = 50 ohm 
impuls 4: Vs = – 6 V Va = – 5 V t6 = 15 ms 
impuls 5: Vs = + 65 V Ri = 3 ohm td = 100 ms 
Impuls 5 skal kun afprøves for køretøjsenheder bestemt til 
montering i køretøjer uden ekstern fælles overbelastnings­
beskyttelse 
For så vidt angår overbelastningsbeskyttelse henvises til ISO 
16750-2, 4. udgave, afsnit 4.6.4.  218 
▼M1 
6. PRØVNING AF EKSTERNT UDSTYR TIL FJERNKOMMUNIKATION  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
1. Administrativ undersøgelse  
1.1 Dokumentation  Dokumentationens 
korrekthed  
2. Eftersyn  
2.1. Overensstemmelse med dokumentationen  
2.2. Identifikation/mærkning  225, 226  
2.3 Materialer  219 til 223  
3. Funktionsprøver  
3.1 Fjernkommunikation i forbindelse med målrettede vejsidekontrol ler 4, 197 til 199  
3.2 Registrering og lagring i datalager  9 1  
3.3 Kommunikation med køretøjsenhed  Tillæg 14, krav 
DSC_66 til DSC_70, 
DSC_71 til DSC_76  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 415  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
4. Miljøprøver  
4.1 Temperatur  Funktionaliteten eftervises gennem: 
Prøvning i overensstemmelse med ISO 16750-4, kapitel 
5.1.1.2: Funktionsprøve ved lav temperatur (72 timer ved 
– 20 °C) 
For denne prøve henvises til IEC 60068-2-1: Environ­
mental testing — Part 2-1: Tests — Test A: Cold 
Test i overensstemmelse med ISO 16750-4: kapitel 
5.1.2.2: High temperature operation test (72 timer ved 
70 °C) 
For denne prøve henvises til IEC 60068-2-2: Basic envi­
ronmental testing procedures; part 2: tests; tests B: dry 
heat 
Test i overensstemmelse med ISO 16750-4: kapitel 5.3.2: 
Rapid change of temperature with specified transition 
duration (– 20 °C/70 °C, 20 cyklusser, holdetid 1 time 
ved hver temperatur) 
Et reduceret sæt prøvninger (af dem, som foreskrives i 
denne tabels punkt 3) kan udføres ved den lave tempe­
ratur, den høje temperatur og med gennemgang af 
temperaturcyklusserne  213 
4.2 Beskyttelse mod 
vand og fremmedle­
gemer  Prøvning i overensstemmelse med ISO 20653: Road 
vehicles — Degree of protection (IP code) — Protection 
of electrical equipment against foreign objects, water and 
access (targeted value IP40)  220, 221  
5 Prøver for elektromagnetisk kompatibilitet  
5.1 Strålingsemission 
og følsomhed  Overensstemmelse med ECE-regulativ R10  218  
5.2 Elektrostatisk 
udladning  Overensstemmelse med ISO 10605:2008 + Technical 
Corrigendum:2010 + AMD1: 2014: +/– 4 kV for 
kontakt og +/– 8 kV for udladning i luften  218 
5.3 Transient nedre 
ledningsoverførsel 
for strømforsyning  For 24 V-udførelse: overensstemmelse med ISO 7637-2 
og ECE-regulativ nr. 10, rev. 3: 
impuls 1a: Vs = – 450 V, Ri = 50 ohm 
impuls 2 a: Vs = + 37 V, Ri = 2 ohm 
impuls 2b: Vs = + 20 V, Ri = 0,05 ohm 
impuls 3 a: Vs = – 150 V, Ri = 50 ohm 
impuls 3b: Vs = + 150 V, Ri = 50 ohm 
impuls 4: Vs = – 16 V Va = – 12 V t6 = 100 ms 
impuls 5: Vs = + 120 V Ri = 2,2 ohm td = 250 ms 
For 12 V-udførelse: overensstemmelse med ISO 7637-1 
og ECE-regulativ nr. 10, rev. 3: 
impuls 1: Vs = – 75 V, Ri = 10 ohm 
impuls 2 a: Vs = + 37 V, Ri = 2 ohm 
impuls 2b: Vs = + 10 V, Ri = 0,05 ohm 
impuls 3 a: Vs = – 112 V, Ri = 50 ohm  218 ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 416  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
impuls 3b: Vs = + 75 V, Ri = 50 ohm 
impuls 4: Vs = – 6 V Va = – 5 V t6 = 15 ms 
impuls 5: Vs = + 65 V, Ri = 3 ohm td = 100 ms 
Impuls 5 skal kun afprøves for køretøjsenheder bestemt 
til montering i køretøjer uden ekstern fælles overbelast­
ningsbeskyttelse 
For så vidt angår overbelastningsbeskyttelse henvises til 
ISO 16750-2, 4. udgave, kapitel 4.6.4.  
▼B 
7. FUNKTIONSPRØVNING AF PAPIR  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
1. Administrativ undersøgelse  
1.1 Dokumentation  Dokumentationens korrekthed  
2 Generelle prøvninger  
2.1 Antal tegn pr. linje  Visuel inspektion af udskrifter.  172  
2.2 Mindste tegnstørrelse  Visuel inspektion af udskrift og tegn.  173  
2.3 Understøttede 
tegnsæt  Printeren skal understøtte de tegnsæt, der er angivet i 
tillæg 1, kapitel 4 »Tegnsæt«.  174 
2.4 Udskrifters tyde­
lighed  Kontrol af takografens typegodkendelse og visuel 
inspektion af udskrifter  174 
2.5 Læsbarhed og identi­
fikation af udskrifter  Inspektion af udskrifter 
Påvist gennem prøvningsrapporter og -protokoller fra 
fabrikanten. 
Alle typegodkendelsesnumre på takografer, som printer­
papiret kan bruges sammen med, er påtrykt papiret.  175, 177, 178  
2.6 Tilføjelse af hånd­
skrevne noter  Visuel inspektion: Der findes et felt til førerens under­
skrift. 
Der findes felter til andre håndskrevne noter.  180 
2.7 Yderligere oplys­
ninger på papir­
udskrifter.  For- og bagsiden af papiret kan indeholde yderligere 
oplysninger. 
Disse yderligere oplysninger må ikke påvirke udskrif­
ternes læsbarhed. 
Visuel inspektion.  177, 178  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 417  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
3 Prøvning af holdbarhed ved opbevaring  
3.1 Tør varme  Forkonditionering: 16 timer ved + 23 °C ± 2 °C/55 % 
± 3 % relativ fugtighed 
Prøvningsmiljø: 72 timer ved + 70 °C ± 2 °C 
Genvinding: 16 timer ved + 23 °C ± 2 °C/55 % ±3 % 
relativ 
fugtighed  176, 178 
IEC 60068-2-2-Bb  
3.2 Fugtig varme  Forkonditionering: 16 timer ved + 23 °C ± 2 °C/55 % 
± 3 % relativ fugtighed 
Prøvningsmiljø: 144 timer ved + 55 °C ± 2 °C og 93 % 
±3 % 
relativ fugtighed 
Genvinding: 16 timer ved + 23 °C ± 2 °C/55 % ± 3 % 
relativ 
fugtighed  176, 178 
IEC 60068-2-78-Cab  
4 Driftsprøvning af papir  
4.1 Fugtighedsresistens, 
baggrund (blankt 
papir)  Forkonditionering: 16 timer ved + 23 °C ± 2 °C/55 % 
± 3 % relativ fugtighed 
Prøvningsmiljø: 144 timer ved + 55 °C ± 2 °C og 93 % 
± 3 % relativ fugtighed 
Genvinding: 16 timer ved + 23 °C ± 2 °C/55 % ± 3 % 
relativ fugtighed  176, 178 
IEC 60068-2-78-Cab  
4.2 Trykbarhed  Forkonditionering: 24 timer ved + 40 °C ± 2 °C/93 % 
± 3 % relativ fugtighed 
Prøvningsmiljø: udskrift foretaget ved + 23 °C ± 2 °C 
Genvinding: 16 timer ved + 23 °C ± 2 °C/55 % ±3 % 
relativ fugtighed  176, 178  
4.3 Varmebestandig-hed  Forkonditionering: 16 timer ved + 23 °C ± 2 °C/55 % 
± 3 % relativ fugtighed 
Prøvningsmiljø: 2 timer ved +70 °C ± 2 °C, tør varme 
Genvinding: 16 timer ved + 23 °C ± 2 °C/55 % ± 3 % 
relativ fugtighed  176, 178 
IEC 60068-2-2-Bb  
4.4 Kuldebestandighed  Forkonditionering: 16 timer ved + 23 °C ± 2 °C/55 % 
±3 % relativ fugtighed 
Prøvningsmiljø: 24 timer ved – 20 °C ± 3 °C, tør kulde 
Genvinding: 16 timer ved + 23 °C ± 2 °C/55 % ±3 % 
relativ fugtighed  176, 178 
ISO 60068-2-1-Ab  
4.5 Lysægthed  Forkonditionering: 16 timer ved + 23 °C ± 2 °C/55 % 
± 3 % relativ fugtighed. 
Prøvningsmiljø: 100 timers belysning ved 5 000 lux og 
+ 23 °C ± 2 °C/55 % ± 3 % relativ fugtighed 
16 timer ved + 23 °C ± 2 °C/55 % ± 3 % relativ 
fugtighed  176, 178  
Læsbarhedskriterier for prøvning 3.x og 4.x:  
Udskriftens læsbarhed sikres, hvis den optiske tæthed ligger in den for 
følgende grænser:  
Udskrevne tegn: min. 1,0  
Baggrund (ubeskrevet papir): maks. 0,2  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 418  
De frembragte udskrifters optiske tæthed skal måles i overensst emmelse 
med DIN EN ISO 534.  
Udskrifterne må ikke udvise nogen dimensionsændringer og skal f orblive 
klart læsbare.  
8. INTEROPERABILITETSPRØVER  
▼M1 
Nr. Prøve  Beskrivelse  
8.1 Interoperabilitetsprøver mellem køretøjsenheder og takograf kort 
1 Gensidig ægthedsbekræftelse  Kontroller, at den gensidige ægthedsbekræftelse mellem køretøj s­
enheden og takografkortet afvikles normalt  
2 Skrive-/læseprøver  Gennemfør et typisk aktivitetsscenario på køretøjsenheden. Sce na­
riet skal være tilpasset den afprøvede korttype og skal indebær e 
skrivning på så mange af kortets elementærfiler som muligt 
Gennem dataoverførsel til køretøjsenheden kontrolleres det, at alle 
de tilsvarende registreringer er udført korrekt 
Gennem dataoverførsel fra kortet kontrolleres det, at alle de t ilsva­
rende registreringer er udført korrekt 
Gennem daglige udskrifter kontrolleres det, at alle de tilsvare nde 
registreringer kan læses korrekt.  
8.2 Interoperabilitetsprøver mellem køretøjsenheder og bevægels esfølere  
1 Parring  Kontrollér, at parringen mellem køretøjsenheden og bevægelses­
føleren afvikles normalt.  
2 Aktivitetsprøvninger  Gennemfør et typisk aktivitetsscenario på bevægelsesføleren. 
Scenariet skal omfatte en normal aktivitet og frembringe så 
mange hændelser eller fejl som muligt. 
Gennem dataoverførsel til køretøjsenheden kontrolleres det, at alle 
de tilsvarende registreringer er udført korrekt 
Gennem dataoverførsel fra kortet kontrolleres det, at alle de t ilsva­
rende registreringer er udført korrekt 
Gennem daglige udskrifter kontrolleres det, at alle de tilsvare nde 
registreringer kan læses korrekt.  
8.3 Interoperabilitetsprøver mellem køretøjsenheder og eksternt  GNSS-udstyr (hvor det er relevant)  
1 Gensidig ægthedsbekræftelse  Kontrollér, at den gensidige ægthedsbekræftelse mellem køretøj s­
enheden og det eksterne GNSS-modul afvikles normalt.  
2 Aktivitetsprøvninger  Gennemfør et typisk aktivitetsscenario på det eksterne 
GNSS-udstyr. Scenariet skal omfatte en normal aktivitet og frem ­
bringe så mange hændelser eller fejl som muligt. 
Gennem dataoverførsel til køretøjsenheden kontrolleres det, at alle 
de tilsvarende registreringer er udført korrekt 
Gennem dataoverførsel fra kortet kontrolleres det, at alle de t ilsva­
rende registreringer er udført korrekt 
Gennem daglige udskrifter kontrolleres det, at alle de tilsvare nde 
registreringer kan læses korrekt.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 419  
9. OSNMA-TEST  
9.1. Indledning  
I dette kapitel beskrives de prøver, der skal godtgøre, at OSNM A er 
korrekt implementeret i GNSS-modtageren. Da ægthedsbekræftelse af 
satellitsignaler udelukkende foretages af GNSS-modtageren uafhæ ngigt 
af alle andre komponenter i takografen, kan de prøver, der er b eskrevet 
i dette kapitel, udføres på GNSS-modtageren som et selvstændigt  element. 
I dette tilfælde skal takograffabrikanten forelægge en rapport for typegod­
kendelsesmyndighederne med nærmere oplysninger om udviklingen o g 
resultaterne af de prøvninger, der udføres under GNSS-modtagerf abrikan­
tens ansvar.  
9.2 Betingelser  
— De kriterier for godkendelse/ikkegodkendelse, der er fastsat i 
OSNMA-prøverne, er kun gyldige i forbindelse med de angivne prø ve­
betingelser.  
— Kriterierne kan revideres i forbindelse med Galileo-erklæring en om 
OSNMA-tjenesten og under hensyntagen til de tilknyttede præstat ions­
forpligtelser.  
9.3. Definitioner og akronymer  
9.3.1 Definitioner  
GNSS Cold/Warm/Hot Start:  starttilstanden for en GNSS-modtager 
baseret på tilgængeligheden af tid (T), 
nuværende almanak (A) og ephemeris 
(E), position (P):  
— GNSS Cold Start: ingen  
— GNSS Warm Start: T, A, P  
— GNSS Hot Start: T, A, E, P  
OSNMA Cold/Warm/Hot Start:  starttilstanden for GNSS-funktionen baseret 
på tilgængeligheden af oplysningerne om 
Public Key (P) og DSM-KROOT (K) 
(som fastlagt i OSNMA Receiver Guide­
lines omhandlet i tillæg 12):  
— OSNMA Cold Start: ingen  
— OSNMA Warm Start: P  
— OSNMA Hot Start: P, K  
9.3.2 Akronymer  
ADKD Authentication Data & Key Delay (Ægthedskontroldata 
og Nøgleforsinkelse)  
DSM-KROOT Digital Signature Message KROOT (Digitalsignaturmed­
delelse KROOT)  
GNSS Global Navigation Satellite System (Globalt satellitnavi­
gationssystem)  
KROOT Root Key of the TESLA key chain (Basal nøgle i 
TESLA-nøglekæde)  
MAC Message Authentication Code (Meddelelsesægthedskode)  
NMACK Number of MAC & key blocks (per 30 seconds) (Antal 
MAC & nøgleblokke (pr. 30 sekunder))  
OSNMA Galileo Open Service Navigation Message Authentication 
(Ægthedsbekræftelse af navigationsmeddelelse via åben 
Galileo-tjeneste)  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 420  
SLMAC Slow MAC (Langsom MAC)  
TESLA Timed Efficient Stream Loss-tolerant Authentication 
(tidsstyret effektiv strømtabstolerant ægthedsbekræftelse) 
(protokol anvendt i OSNMA)  
9.4. Udstyr til generering af GNSS-signaler  
GNSS-signalerne kan genereres ved hjælp af en GNSS-simulator me d 
flere konstellationer, som understøtter OSNMA-overførsel af med delelser. 
Alternativt kan der anvendes en radiofrekvensindikator, der kan  tilbageføre 
GNSS-signalprøver fra filer. Typisk bitdybde og prøvetagningsha stighed 
er henholdsvis 4 bit I/Q og 10MHz.  
Det antages, at GNSS-modtageren har grænseflader til at styre c learingen 
af modtagerens hukommelse (med henblik på uafhængigt at slette den 
offentlige nøgle, KROOT, tidsoplysninger, positionsoplysninger,  ephe­
meris og almanak), til at indstille modtagerens lokaltidsrealis ering til 
OSNMA's krav om tidsverifikation og til at indlæse de kryptogra fiske 
oplysninger. Disse kommandoer kan være begrænset til testformål  og er 
derfor muligvis ikke tilgængelige ved modtagerens nominelle dri ft. 
9.5 Prøvningsbetingelser  
9.5.1 GNSS-betingelser  
De simulerede eller afspillede GNSS-signaler har følgende egens kaber:  
— Statisk brugermodtagerscenarie  
— Mindst GPS- og Galileo-konstellationer  
— E1/L1-frekvens  
— Mindst fire Galileo-satellitter med en elevationsvinkel på me re end 5°  
— Varighed som krævet for hver prøvning  
— Konstante navigation-ephemerides fra satellitterne under prøv en. 
9.5.2 OSNMA-betingelser  
Den OSNMA-meddelelse, der overføres i RF-signalet, har følgende  
egenskaber:  
— En HKROOT-meddelelse med OSNMA Status indstillet til Opera­
tional eller Test og en fast DSM-KROOT på otte blokke for den 
gældende kæde  
— Mindst fire Galileo-satellitter, der overfører OSNMA  
— En MACK-meddelelse med en MACK-blok (dvs. NMACK=1) og 
mindst én ADKD=0 og én ADKD=12 pr. satellit og MACK-blok  
— En tagstørrelse på 40 bit  
— Den ækvivalente minimumslængde på tags som kræver i OSNMA 
Receiver Guidelines (aktuelt 80 bit).  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 421  
Medmindre andet er anført, skal modtagerens interne tidsrealise ring være 
kendt med tilstrækkelig nøjagtighed og være i overensstemmelse med den 
simulerede tid. Dette sikrer, at OSNMA's krav til indledende ti dssynkro­
nisering er opfyldt for hver prøvningsbetingelse, dvs. nominel synkroni­
sering for alle prøver, undtagen SLMAC-prøven. Se OSNMA Receive r 
Guidelines for flere oplysninger om tidsinitialisering.  
Bemærk, at de anførte kriterier for godkendelse/ikkegodkendelse  er 
konservative og ikke repræsenterer den forventede Galileo OSNMA - 
performance.  
9.6. Prøvningsspecifikationer  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
1. Administrativ undersøgelse  
1.1 Dokumentation  Dokumentationens korrekthed  
2 Generelle prøvninger  
2.1 OSNMA Hot Start  Formål: Bekræft, at GNSS-modtageren beregner en 
position med OSNMA efter en hot start. 
Procedure: 
GNSS-modtageren starter under betingelserne for hot 
start af GNSS og OSNMA og henter signaler fra 
synlige Galileo satellitter. 
Modtageren ægthedskontrollerer Galileo-navigations­
data i forhold til OSNMA (ADKD = 0) og viser en 
position med ægthedsbekræftede data. 
Kriterier for godkendelse/ikkegodkendelse: Modtageren 
beregner en ægthedsbekræftet position inden for 160 
sekunder.  Tillæg 12 
GNS_3b  
2.2 OSNMA Warm Start  Formål: Bekræft, at GNSS-modtageren beregner en 
position med OSNMA efter en warm start. 
Procedure: 
Før prøvningen påbegyndes, slettes ephemeris- og 
KROOT-oplysningerne fra GNSS-modtagerens hukom­
melse for at fremtvinge en warm start af GNSS og 
OSNMA. 
GNSS-modtageren starter og henter signaler fra synlige 
Galileo satellitter. 
DSM-KROOT modtages og verificeres. 
Modtageren ægthedskontrollerer Galileo-navigations­
data i forhold til OSNMA (ADKD = 0) og viser en 
position med bekræftede data. 
Kriterier for godkendelse/ikkegodkendelse: Modtageren 
beregner en ægthedsbekræftet gyldig position inden for 
430 sekunder.  Tillæg 12 
GNS_3b  
2.3 OSNMA warm start 
med SLMAC  Formål: Bekræfte, at GNSS-modtageren beregner en 
position med OSNMA efter en warm start med en tids­
initialisering, der kræver SLMAC-tilstand, som fastlagt 
i OSNMA Receiver Guidelines. 
Procedure: 
Modtagerens interne tidsrealisering skal konfigureres 
for at få en indledende tidsmæssig usikkerhed på 2- 
2,5 minutter, således at Slow MAC-tilstand aktiveres 
ifølge OSNMA Receiver Guidelines.  Tillæg 12 
GNS_3b  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 422  
Nr. Prøve  Beskrivelse  Tilknyttede krav  
Før prøvningen påbegyndes, slettes ephemeris- og 
KROOT-oplysningerne fra GNSS-modtagerens hukom­
melse for at fremtvinge en warm start af GNSS og 
OSNMA. 
GNSS-modtageren starter og henter signaler fra synlige 
Galileo satellitter. 
DSM-KROOT modtages og verificeres. 
Modtageren ægthedskontrollerer Galileo-navigations­
data i forhold til OSNMA Slow MAC (ADKD=12) 
og viser en position med bekræftede data. 
Kriterier for godkendelse/ikkegodkendelse: Modtageren 
beregner en ægthedsbekræftet gyldig position inden for 
730 sekunder.  
2.4 OSNMA hot start med 
afspillet signal  Formål: Bekræft, at GNSS-modtageren registrerer et 
afspillet signal. 
Procedure: 
GNSS-modtageren starter under betingelserne for hot 
start af GNSS og OSNMA og henter signaler fra 
synlige Galileo satellitter. 
Modtageren ægthedskontrollerer Galileo-navigations­
data i forhold til OSNMA (ADKD = 0) og viser en 
position med bekræftede data. 
Når modtageren leverer PVT-opløsning med bekræftede 
data, slukkes den. 
Der simuleres et afspillet signal med en forsinkelse på 
40 sekunder i forhold til det foregående, og modtageren 
tændes. 
Modtageren registrerer, at Galileo System Time fra 
signal-in-space-tiden og lokaltidsrealiseringen ikke 
opfylder synkroniseringskravet, og standser behand­
lingen af OSNMA-data som defineret i OSNMA 
Receiver Guidelines. 
Kriterier for godkendelse/ikkegodkendelse: Modtageren 
registrerer afspilningen og beregner ikke en bekræftet 
gyldig position fra starten af afspilningen og indtil 
prøvens slutning.  Tillæg 12 
GNS_3b  
2.5 OSNMA hot start med 
falske data  Formål: Bekræft, at OSNMA registrerer falske data. 
Procedure: 
GNSS-modtageren starter under betingelserne for hot 
start af GNSS og OSNMA. 
GNSS-modtageren skal kunne hente signalet fra alle 
synlige Galileo-satellitter og bekræfte ægtheden af 
deres navigationsmeddelelser ved hjælp af OSNMA. 
Mindst én bit af ephemeris-data fra hver Galileo-satellit 
svarer ikke til de oprindelige og ægthedsbekræftede 
data, men Galileo I/NAV-meddelelsen skal være 
sammenhængende, herunder CRC. 
Kriterier for godkendelse/ikkegodkendelse: Modtageren 
registrerer de falske data inden for 160 sekunder og 
beregner ikke en ægthedsbekræftet gyldig position før 
prøvens afslutning.  Tillæg 12 
GNS_3b  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 423  
Tillæg 10  
SIKKERHEDSKRAV  
Dette tillæg beskriver it-sikkerhedsforskrifterne for det intel ligente takografsy­
stems komponenter (takograf af anden generation).  
SEC_001 Følgende af det intelligente takografsystems komponente r skal sikker­
hedsattesteres i overensstemmelse med de fælleseuropæiske krite rier: 
— køretøjsenhed  
— takografkort  
— bevægelsesføler  
— eksternt GNSS-udstyr.  
SEC_002 De it-sikkerhedsforskrifter, der som minimum skal opfyl des af hver 
enkelt komponent, som skal sikkerhedsattesteres, skal fastlægge s i en 
komponentsikringsprofil i overensstemmelse med de fælleseuropæi ske 
kriterier.  
SEC_003 Europa-Kommissionen skal sørge for, at følgende fire si kringsprofiler, 
som er i overensstemmelse med dette bilag, støttes, udvikles og  
godkendes af de statslige it-sikkerhedsattesteringsorganer, der  er orga­
niseret i den arbejdsgruppe om fælles fortolkning, som understø tter 
gensidig anerkendelse af attester inden for rammerne af 
SOGIS-MRA (den europæiske aftale om gensidig anerkendelse af 
it-sikkerhedsvurderingsattester), og at de registreres:  
— sikringsprofil for køretøjsenhed  
— sikringsprofil for takografkort  
— sikringsprofil for bevægelsesføler  
— sikringsprofil for eksternt GNSS-udstyr.  
Sikringsprofilen for køretøjsenheden skal både anvendes i de ti lfælde, hvor køre­
tøjsenheden er beregnet til brug sammen med eksternt GNSS-udsty r, og i andre 
tilfælde. I førstnævnte tilfælde anføres sikkerhedsforskriftern e for det eksterne 
GNSS-udstyr i den dedikerede sikringsprofil.  
SEC_004 For at opstille et sikkerhedsmål, som komponenterne kan  sikkerheds­
attesteres efter, skal komponentfabrikanterne efter behov udvik le og 
komplettere hensigtsmæssige komponentsikringsprofiler uden at æ ndre 
eller slette eksisterende risici, mål, proceduremæssige metoder  eller 
forskrifter for sikkerhedsfunktioner.  
SEC_005 I forbindelse med evalueringsprocessen skal det erklære s, at dette 
sikkerhedsmål i alle henseender stemmer overens med den tilsvar ende 
sikringsprofil.  
SEC_006 Sikkerhedsniveauet for hver sikringsprofil skal svare t il EAL4 og de 
udvidede sikkerhedskomponenter ATE_DPT.2 og AVA_VAN.5.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 424  
Tillæg 11  
FÆLLES SIKKERHEDSMEKANISMER  
INDHOLDSFORTEGNELSE  
PRÆAMBEL  
DEL A TAKOGRAFSYSTEM AF FØRSTE GENERATION  
1. INDLEDNING  
1.1. Henvisninger  
1.2. Notation og forkortelser  
2. KRYPTOGRAFISKE SYSTEMER OG ALGORITMER  
2.1. Kryptografiske systemer  
2.2. Kryptografiske algoritmer  
2.2.1 RSA-algoritme  
2.2.2 Hash-algoritme  
2.2.3 Algoritme til datakryptering  
3. NØGLER OG CERTIFIKATER  
3.1. Generering og distribution af nøgler  
3.1.1 Generering og distribution af RSA-nøgler  
3.1.2 RSA-prøvenøgler  
3.1.3 Nøgler til bevægelsessensor  
3.1.4 Generering og distribution af T-DES-sessionsnøgler  
3.2. Nøgler  
3.3. Certifikater  
3.3.1 Certifikaters indhold  
3.3.2 Udstedte certifikater  
3.3.3 Verificering og udpakning af certifikater  
4. MEKANISME TIL GENSIDIG ÆGTHEDSKONTROL  
5. MEKANISMER TIL FORTROLIGHED, INTEGRITET OG 
ÆGTHEDSKONTROL VED DATAOVERFØRSEL PÅ KØRE­ 
TØJSENHEDENS KORT  
5.1. Sikker meddelelsesoverførsel  
5.2. Håndtering af fejl ved sikker meddelelsesoverførsel  
5.3. Algoritme til beregning af kryptografiske kontrolsummer  
5.4. Algoritme til beregning af kryptogrammer til fortroligheds data­ 
objekter  
6. MEKANISMER TIL DIGITAL UNDERSKRIFT AF DATA­ 
OVERFØRSLER  
6.1. Generering af underskrifter  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 425  
6.2. Verificering af underskrift  
DEL B TAKOGRAFSYSTEM AF ANDEN GENERATION  
7. INDLEDNING  
7.1. Henvisninger  
7.2. Notation og forkortelser  
7.3. Definitioner  
8. KRYPTOGRAFISKE SYSTEMER OG ALGORITMER  
8.1. Kryptografiske systemer  
8.2. Kryptografiske algoritmer  
8.2.1 Symmetriske algoritmer  
8.2.2 Asymmetriske algoritmer og standardiserede domæneparametr e 
8.2.3 Hash-algoritmer  
8.2.4 Talrækker  
9. NØGLER OG CERTIFIKATER  
9.1. Asymmetriske nøglepar og certifikater for offentlige nøgle r 
9.1.1 Generelt  
9.1.2 Europæisk niveau  
9.1.3 Medlemsstatsniveau  
9.1.4 Apparatniveau: Køretøjsenheder  
9.1.5 Apparatniveau: Takografkort  
9.1.6 Apparatniveau: Eksternt GNSS-udstyr  
9.1.7 Oversigt: Udskiftning af certifikat  
9.2. Symmetriske nøgler  
9.2.1 Nøgler til sikring af kommunikation mellem køretøjsenhed og 
bevægelsessensor  
9.2.2 Nøgler til sikring af DSRC-kommunikation  
9.3. Certifikater  
9.3.1 Generelt  
9.3.2 Certifikaters indhold  
9.3.3 Anmodning om certifikater  
10. GENSIDIG ÆGTHEDSKONTROL OG SIKKER MEDDELEL­ 
SESOVERFØRSEL MELLEM KØRETØJSENHED OG KORT  
10.1. Generelt  
10.2. Gensidig certifikatkædeverificering  
10.2.1 Kortcertifikatkædeverificering foretaget af køretøjsenhe den ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 426  
10.2.2 Kortcertifikatkædeverificering foretaget af kortet  
10.3. Ægthedskontrol af køretøjsenhed  
10.4. Ægthedskontrol af chip og overenstemmelseskontrol af sess ions­ 
nøgle  
10.5. Sikker meddelelsesoverførsel  
10.5.1 Generelt  
10.5.2 Struktur af sikker meddelelse  
10.5.3 Afbrydelse af en sikker meddelelsesoverførselssession  
11. SAMMENKOBLING AF KØRETØJSENHED OG EKSTERNT 
GNSS-UDSTYR, GENSIDIG ÆGTHEDSKONTROL OG 
SIKKER MEDDELELSESOVERFØRSEL  
11.1. Generelt  
11.2. Sammenkobling af køretøjsenhed og eksternt GNSS-udstyr  
11.3. Gensidig certifikatkædeverifikation  
11.3.1 Generelt  
11.3.2 Under sammenkobling af køretøjsenhed og EGF  
11.3.3 Under normal drift  
11.4. Ægthedskontrol af køretøjsenhed og chip samt sessionsnøgl eover­ 
ensstemmelse  
11.5. Sikker meddelelsesoverførsel  
12. PARRING AF OG KOMMUNIKATION MELLEM KØRETØJS­ 
ENHED OG BEVÆGELSESSENSOR  
12.1. Generelt  
12.2. Parring af køretøjsenhed og bevægelsessensor ved hjælp af  forskel­ 
lige nøglegenerationer  
12.3. Parring af og kommunikation mellem køretøjsenhed og bevæg el­ 
sessensor ved hjælp af AES  
12.4. Parring af køretøjsenhed og bevægelsessensor til forskell ige 
udstyrsgenerationer  
13. SIKKERHED VED FJERNKOMMUNIKATION OVER DSRC  
13.1. Generelt  
13.2. Kryptering af takografindhold og MAC-generering  
13.3. Verifikation og dekryptering af takografindhold  
14. UNDERSKRIVELSE AF DATAOVERFØRSLER OG VERIFICE­ 
RING AF UNDERSKRIFTER  
14.1. Generelt  
14.2. Generering af underskrifter  
14.3. Verifikation af underskrift  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 427  
PRÆAMBEL  
Dette tillæg foreskriver de sikkerhedsmekanismer, som sikrer:  
— gensidig ægthedskontrol mellem forskellige komponenter i det digitale tako­
grafsystem  
— fortrolighed, integritet, ægthed og/eller uafviselighed af da ta overført mellem 
forskellige komponenter eller overført til eksterne lagringsmed ier. 
Dette tillæg består af to dele. I del A er sikkerhedsmekanismer  for digitale 
takografsystemer af første generation (digitale takografer) def ineret. I del B er 
sikkerhedsmekanismer for digitale takografsystemer af anden gen eration (intel­
ligente takografer) defineret.  
De mekanismer, der specificeres i del A i dette tillæg, finder anvendelse, hvis 
mindst en af takografsystemets komponenter, der anvendes ved en  gensidig 
ægthedskontrol og/eller dataoverførselsproces, er af første gen eration.  
De mekanismer, der specificeres i del B i dette tillæg, finder anvendelse, hvis 
begge takografsystemets komponenter, der anvendes ved en gensid ig ægtheds­
kontrol og/eller dataoverførselsprocessen, er af anden generati on. 
Tillæg 15 indeholder flere oplysninger om brugen af komponenter  af første 
generation sammen med komponenter af anden generation.  
DEL A  
TAKOGRAFSYSTEM AF FØRSTE GENERATION  
1. INDLEDNING  
1.1. Henvisninger  
I dette tillæg er følgende henvisninger anvendt:  
SHA-1 National Institute of Standards and Technology 
(NIST).  FIPS Publication 180-1: Secure Hash Stan ­
dard . April 1995.  
PKCS1 RSA Laboratories. PKCS # 1:  RSA Encryption Stan ­
dard . Version 2.0. October 1998.  
TDES National Institute of Standards og Technology (NIST).  
FIPS Publication 46-3: Data Encryption Standard . 
Draft 1999.  
TDES-OP ANSI X9.52, Triple Data Encryption Algorithm 
Modes of Operation. 1998.  
ISO/IEC 7816-4 Information Technology — Identification cards — 
Integrated circuit(s) cards with contacts — Part 4: 
Interindustry commands for interexchange. First 
edition: 1995 + Amendment 1: 1997.  
ISO/IEC 7816-6 Information Technology — Identification cards — 
Integrated circuit(s) cards with contacts — Part 6: 
Interindustry data elements. First edition: 1996 + Cor 
1: 1998.  
ISO/IEC 7816-8 Information Technology — Identification cards — 
Integrated circuit(s) cards with contacts — Part 8: 
Security related interindustry commands. First edition 
1999.  
ISO/IEC 9796-2 Information Technology — Security techniques — 
Digital signature schemes giving message recovery 
— Part 2: Mechanisms using a hash function. First 
edition: 1997.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 428  
ISO/IEC 9798-3 Information Technology — Security techniques — 
Entity authentication mechanisms — Part 3: Entity 
authentication using a public key algorithm. Second 
edition 1998.  
ISO 16844-3 Road vehicles — Tachograph systems — Part 3: 
Motion sensor interface.  
1.2. Notation og forkortelser  
I dette tillæg bruges følgende notation og forkortelser:  
(K a , K  b , K  c ) Et nøglebundt til brug for den tredobbelte datakryp­
teringsalgoritme  
CA Certificeringsmyndighed  
CAR Henvisning til certificeringsmyndighed  
CC Kryptografisk kontrolsum  
CG Kryptogram  
CH Kommandoheader  
CHA Certifikatindehavers autorisation  
CHR Henvisning til certifikatindehaver  
D() Dekryptering med DES  
DE Dataelement  
DO Dataobjekt  
d Privat RSA-nøgle, privat eksponent  
e Offentlig RSA-nøgle, offentlig eksponent  
E() Kryptering med DES  
EQT Udstyr  
Hash()  hash-værdi, et  Hash -resultat  
Hash  Hash-funktion  
KID Nøgle-identifikator  
Km TDES-nøgle. Hovednøgle defineret i ISO 16844-3  
Km  VU TDES-nøgle isat køretøjsenheder  
Km  WC TDES-nøgle isat værkstedskort  
m Repræsenterer en meddelelse, heltal mellem 0 og  n-1 
n RSA-nøgler, modulus  
PB Udfyldningsbyte  
Produktangivelse Udfyldningsindikatorbyte (til brug i kryptogra m til 
fortrolighedsdataobjekt)  
PV Ordinær dataværdi  
s Repræsenterer en underskrift, heltal mellem 0 og  n-1 
SSC Sendesekvenstæller  
SM Sikker meddelelsesoverførsel  
TCBC TDEA-kryptografering med blokkædningsfunktion  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 429  
TDEA Algoritme til tredobbelt datakryptering  
TLV Mærkatlængde  
VU Køretøjsenhed  
X.C Certifikat for bruger X, udstedt af en certificerings­
myndighed  
X.CA Certificeringsmyndighed for bruger X  
X.CA.PK  o X.C Operation, som består i at udpakke et certifikat for at 
udtrække en offentlig nøgle. Der er tale om en 
operator af infix-typen, der som venstre operand har 
certificeringsmyndighedens offentlige nøgle og som 
højre operand certifikatet udstedt af den pågældende 
certificeringsmyndighed. Resultatet er den offentlige 
nøgle for brugeren X, hvis certifikat er den højre 
operand  
X.PK Offentlig RSA-nøgle for bruger X  
X.PK[I] RSA-krypteringen af en vilkårlig oplysning I ved 
hjælp af den offentlige nøgle fra bruger X  
X.SK Privat RSA-nøgle for bruger X  
X.SK[I] RSA-kryptering af en vilkårlig oplysning I ved hjælp 
af den private nøgle fra bruger X  
»xx« Hexadecimal værdi  
|| Sammenkædningsoperator  
2. KRYPTOGRAFISKE SYSTEMER OG ALGORITMER  
2.1. Kryptografiske systemer  
CSM_001 Køretøjsenheder og takografkort skal anvende et kryptog ra­
fisk system med en klassisk offentlig RSA-nøgle til at tilve­
jebringe følgende sikkerhedsmekanismer:  
— ægthedskontrol mellem køretøjsenheder og kort  
— transport af tredobbelte DES-sessionsnøgler mellem køre­
tøjsenheder og takografkort  
— digital underskrift af data, som er overført fra køretøjs­
enhederne eller fra takografkort til eksterne medier.  
CSM_002 I køretøjsenheder og takografkort skal der anvendes et tredob­
belt symmetrisk DES-kryptograferingssystem til sikring af 
dataintegritet under udveksling af brugerdata mellem køretøjs­
enheder og takografkort og til, i givet fald, at sikre fortroli g­
heden af dataoverførsel mellem køretøjsenheder og 
takografkort.  
2.2. Kryptografiske algoritmer  
2.2.1  RSA-algoritme  
CSM_003 RSA-algoritmen er fuldt defineret ved følgende relation er: ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 430  
X.SK[ m] = s = m d mod n 
X.PK[ s] = m = s e mod n 
En mere fuldstændig beskrivelse af RSA-funktionen findes i 
henvisning [PKCS1]. Den offentlige eksponent, e, til 
RSA-beregninger er et heltal mellem 3 og n-1, som opfylder 
betingelsen gcd(e, lcm(p-1, q-1))=1.  
2.2.2  Hash-algoritme  
CSM_004 Mekanismerne til digital underskrift skal anvende SHA-1 - 
hashalgoritmen som defineret i henvisning [SHA-1].  
2.2.3  Algoritme til datakryptering  
CSM_005 Der skal anvendes DES-baserede algoritmer i blokkædning s- 
funktionstilstand.  
3. NØGLER OG CERTIFIKATER  
3.1. Generering og distribution af nøgler  
3.1.1  Generering og distribution af RSA-nøgler  
CSM_006 RSA-nøgler skal genereres i tre funktionelle hierarkisk e 
niveauer:  
— europæisk niveau,  
— medlemsstatsniveau  
— apparatniveau.  
CSM_007 På europæisk niveau skal der genereres et enkelt europæ isk 
nøglepar (EUR.SK og EUR.PK). Den europæiske private 
nøgle skal anvendes til at certificere medlemsstaternes offent­
lige nøgler. Der skal føres registre over alle certificerede 
nøgler. Disse opgaver udføres af en europæisk certificerings­
myndighed under Europa-Kommissionens myndighed og 
ansvar.  
CSM_008 På medlemsstatsniveau skal der genereres et medlemsstat - 
nøglepar (MS.SK og MS.PK). Medlemsstaternes offentlige 
nøgler skal være certificeret af den europæiske certificerings­
myndighed. Den private medlemsstatsnøgle anvendes til at 
certificere de offentlige nøgler, som skal isættes udstyret 
(køretøjsenhed eller takografkort). Der skal føres register 
over alle certificerede offentlige nøgler med identifikation af  
det udstyr, de er bestemt til. Disse opgaver varetages af en 
medlemsstats certificeringsmyndighed. En medlemsstat kan 
jævnligt ændre sit nøglepar.  
CSM_009 På apparatniveau skal der genereres et enkelt nøglepar 
(EQT.SK og EQT.PK), som isættes hvert apparat. Apparatets 
offentlige nøgler skal certificeres af en medlemsstats certifi­
ceringsmyndighed. Disse opgaver kan varetages af udstyrs­
fabrikanter, leverandører af individuelle tilpasninger af 
udstyr eller medlemsstaternes myndigheder. Dette nøglepar 
anvendes til ægthedskontrol, digital underskrift og krypte­
ringstjenester.  
CSM_010 De private nøglers fortrolighed skal bibeholdes under g enere­
ring, eventuel transport og opbevaring.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 431  
Følgende billede sammenfatter datastrømmen under denne 
proces:
  
3.1.2  RSA-prøvenøgler  
CSM_011 Til afprøvning af udstyr (herunder interoperabilitetspr øvning) 
skal den europæiske certificeringsmyndighed generere et uens 
par europæiske prøvenøgler og mindst to par medlemsstats­
prøvenøgler, af hvilke de offentlige nøgler skal certificeres 
med den europæiske private prøvenøgle. I det udstyr, som 
skal typegodkendes, skal fabrikanterne isætte prøvenøgler, 
som er certificeret med en af medlemsstaternes prøvenøgler.  
3.1.3  Nøgler til bevægelsessensor  
Generering, eventuel transport og opbevaring af de tre nedenfor  be­
skrevne TDES-nøgler skal ske under iagttagelse af fuld fortroli ghed.  
For at understøtte takografkomponenter, som er i overensstemmel se med 
ISO 16844, skal den europæiske certificeringsmyndighed og medle ms­
staternes certificeringsmyndigheder endvidere sikre følgende:  
CSM_036 Den europæiske certificeringsmyndighed genererer KmVU o g 
KmWC, to uafhængige og unikke tredobbelte DES-nøgler, og 
genererer Km som: Km = Km  VU XOR Km  WC . Den europæ­
iske certificeringsmyndighed fremsender disse nøgler under 
brug af tilbørligt sikrede procedurer til medlemsstaternes 
certificeringsmyndigheder på disses anmodning.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 432  
CSM_037 Medlemsstaternes certificeringsmyndigheder skal:  
— Anvende Km til kryptering af bevægelsessensordata, som 
fabrikanter af bevægelsessensorer anmoder om (de data, 
som skal krypteres med Km, er fastlagt i ISO 16844-3)  
— Fremsende Km  VU til fabrikanterne af køretøjsenheder 
under brug af behørigt sikrede procedurer til isætning i 
køretøjsenheder  
— sørge for, at Km  WC isættes alle værkstedskort 
(
 i elementærfilen
  
) under personalisering 
af kortet.  
3.1.4  Generering og distribution af T-DES-sessionsnøgler  
CSM_012 Køretøjsenheder og takografkort skal som del af den gen si­
dige ægthedskontrol generere og udveksle de nødvendige data 
til udarbejdelse af en tredobbelt fælles DES-sessionsnøgle. 
Denne dataudveksling skal være fortrolighedsbeskyttet ved 
RSA-kryptering.  
CSM_013 Denne nøgle skal anvendes til alle efterfølgende krypto gra­
fiske operationer, hvor der anvendes sikker meddelelsesover­
førsel. Dens gyldighed udløber ved sessionens afslutning 
(udtagning eller genindsætning af kort) og/eller efter 240 
anvendelser (en anvendelse af nøglen = en kommando med 
sikker meddelelsesoverførsel sendt til kortet, samt det tilhø­
rende svar).  
3.2. Nøgler  
CSM_014 RSA-nøgler (uanset niveau) skal have følgende længder: 
modulus  n 1 024 bit, offentlig eksponent  e højst 64 bit, 
privat eksponent  d 1 024 bit.  
CSM_015 Tredobbelte DES-nøgler har formen (K  a , K b , K  a ), hvor K  a og 
K b er uafhængige nøgler med en længde på 64 bit. Der skal 
ikke sættes paritetsbit.  
3.3. Certifikater  
CSM_016 Certifikater med offentlig RSA-nøgle skal være »ikke-se lv­
deskriptive« og »verificerbare med kort« (ref.: ISO/IEC 
7816-8) ISO/IEC 7816-8)  
3.3.1  Certifikaters indhold  
CSM_017 Certifikater med offentlig RSA-nøgle er opbygget med 
følgende data i følgende rækkefølge:  
Data  Format  Byte  Bemærkning  
CPI INTEGER  1  Certifikatprofil-identifi­
kator (»01« for denne 
version)  
CAR  OCTET 
STRING  8 Henvisning til certifice­
ringsmyndighed  
CHA  OCTET 
STRING  7 Certifikatindehavers auto­
risation  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 433  
Data  Format  Byte  Bemærkning  
EOV  TimeReal  4  Certifikatets udløbsdato. 
Ikke obligatorisk, udfyldt 
med »FF«, hvis det ikke 
benyttes.  
CHR  OCTET 
STRING  8 Henvisning til certifikatin­
dehaver  
n OCTET 
STRING  128 Offentlig nøgle (modulus)  
e OCTET 
STRING  8 Offentlig nøgle (offentlig 
eksponent)  
164 
Bemærk:  
1. »Certifikatprofil-identifikatoren« (CPI) beskriver den nøjag tige opbyg­
ning af et ægthedscertifikat. Den kan bruges som intern identif ikator 
for udstyret i en relevant headerliste, som beskriver sammenkæd ­
ningen af dataelementer i certifikatet.  
Den headerliste, der er knyttet til indholdet af dette certifik at, er som 
følger: 
»4D«  »16«  »5F 
29« »01«  »42«  »08«  »5F 
4B« »07«  »5F 
24« »04«  »5F 
20« »08«  »7F 
49« »05«  »81«  »81 
80« »82«  »08«
 Mærkat for udvidet headerliste  
Længde af headerliste  
CPI-mærkat  
CPI-længde  
CAR-mærkat  
CAR-længde  
CHA-mærkat  
CHA-længde  
EOV -mærkat  
EOV -længde  
CHR-mærkat  
CHR-længde  
Offentlig nøgle-mærkat (konstrueret)  
Længde af efterfølgende dataobjekter  
modulus-mærke  
modulus-længde  
offentlig eksponent-mærke  
offentlig eksponent-længde 
2. »Henvisning til certificeringsmyndighed« (CAR) har til formå l at 
identificere den certifikatudstedende myndighed på en sådan måd e, 
at dataelementet samtidig kan anvendes som identifikator for en  
myndigheds nøgle og henvise til certificeringsmyndighedens offe nt­
lige nøgle (vedrørende kodning henvises til nøgleidentifikatore n 
nedenfor).  
3. »Certifikatindehavers autorisation« (CHA) anvendes til at id entificere 
certifikatindehaverens rettigheder. Den indeholder fartskrivera pplika­
tionens ID og en angivelse af den type udstyr, som certifikatet  er 
bestemt til (i henhold til dataelementet
  »00« for 
en medlemsstat).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 434  
4. 4. »Henvisning til certifikatindehaver« (CHR) har til formål  at iden­
tificere certifikatindehaveren entydigt, således at dataelement et på en 
gang kan anvendes som identifikator for en persons nøgle og hen vise 
til certifikatindehaverens offentlige nøgle.  
5. Nøgleidentifikatorer identificerer entydigt certifikatindeha ver eller 
certificeringsmyndighed. De kodes som følger:  
5.1. Udstyr (køretøjsenhed eller kort): 
Data  Udstyrets 
serie­
nummer  Dato  Type  Fabrikant  
Længde  4 byte  2 byte  1 byte  1 byte  
Værdi  Heltal  mm yy binær deci­
malkode  Fabrikants­
pecifik  Fabrikantkode  
For en køretøjsenhed kan producenten, når han anmoder om 
certifikater, være vidende eller uvidende om identifikationen a f 
det udstyr, nøglerne vil blive isat.  
I første tilfælde sender fabrikanten identifikationen af udstyr et 
med den offentlige nøgle til den pågældende medlemsstats 
myndigheder til certificering. Certifikatet vil derefter indeho lde 
identifikationen af udstyret, og fabrikanten skal sikre, at nøg ler 
og certifikat isættes det udstyr, det er bestemt for. Nøgleiden ti­
fikatoren har den ovenfor viste form.  
I sidstnævnte tilfælde skal fabrikanten entydigt identificere h ver 
anmodning om certifikat og sende denne identifikation med den 
offentlige nøgle til den pågældende medlemsstats myndigheder ti l 
certificering. Certifikatet vil indeholde identifikationen af a nmod­
ningen. Fabrikanten skal melde tilbage til myndighederne i sin 
medlemsstat med tilordning af nøgle til udstyr (dvs. identifika tion 
af anmodning om certifikat, identifikation af udstyr) efter ins tal­
lering af nøglen i udstyret. Nøgleidentifikatoren har følgende 
form: 
Data  Serie­
nummer 
på 
anmod­
ning om 
certifikat  Dato  Type  Fabrikant  
Længde  4 byte  2 byte  1 byte  1 byte  
Værdi  Heltal  mm yy binær deci­
malkode  »FF«  Fabrikantkode  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 435  
5.2. Certificeringsmyndighed: 
Data  Identifikation af 
myndighed  Serienummer 
på nøgle  Yderligere 
oplysninger  Identifikator  
Længde  4 byte  1 byte  2 byte  1 byte  
Værdi  1 byte numerisk 
nation-kode 
3 byte alfanume­
risk nation-kode  Heltal  Tillægskode 
(CA-specifik) 
»FF FF«, hvis 
det ikke 
anvendes  »01«  
Nøglens serienummer anvendes til at skelne mellem en medlems­
stats forskellige nøgler, i tilfælde af at nøglen ændres.  
6. Certifikatkontrollører skal implicit vide, at den certificer ede offentlige 
nøgle er en RSA-nøgle, som er relevant for ægthedskontrol, veri fice­
ring af digital underskrift og kryptering til fortrolighedstjen ester (certi­
fikatet indeholder ingen objektidentifikator til angivelse hera f). 
3.3.2  Udstedte certifikater  
CSM_018 Det udstedte certifikat er en digital underskrift med d elvis 
genetablering af certifikatets indhold i overensstemmelse 
med ISO/IEC 9796-2, undtagen bilag A.4 dertil, med 
»henvisning til certificeringsmyndighed« vedhæftet.  
X.C = X.CA.SK[»6A« || C  r || Hash  (Cc) || »BC«] || C  n || X.CAR 
Med certifikatind­
hold = Cc =  C r || C  n 
106 byte  58 byte  
Bemærk:  
1. Dette certifikat er 194 byte langt.  
2. Henvisning til certificeringsmyndigheden (CAR), som er skjul t af 
underskriften, er ligeledes vedhæftet underskriften, således at  certifi­
ceringsmyndighedens offentlige nøgle kan vælges til verificerin g af 
certifikatet.  
3. Certifikatkontrolløren skal implicit kende den algoritme, de r af certi­
ficeringsmyndigheden er anvendt til at underskrive certifikatet . 
4. Den headerliste, der er knyttet til dette udstedte certifika t, er som 
følger: 
»7F 21«  »09«  »5F 37«  »81 80«  »5F 38«  »3A«  »42«  »08«
 CV -certifikatmærkat (konstrueret)  
Længde af efterfølgende dataobjekter  
Underskrift-mærkat  
Underskrift-længde  
Rest-mærke  
Rest-længde  
CAR-mærkat  
CAR-længde ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 436  
3.3.3  Verificering og udpakning af certifikater  
Certifikatverificering og -udpakning består i verificering af u nderskriften 
i overensstemmelse med ISO/IEC 9796-2, hentning af certifikatet s 
indhold og den deri indeholdte offentlige nøgle: X.PK = X.CA.PK  o 
X.C, og kontrol af certifikatets gyldighed.  
CSM_019 Der indgår heri følgende trin:  
Verificer underskrift og hent indhold: 
— fra X.C hent Sign, C  n »og CAR«:  X.C =  Sign  | |  C  n ' | |  CAR'  
128 byte  58 byte  8 byte  
— fra CAR' vælg korrekt offentlig nøgle for certificerings­
myndighed (hvis dette ikke er sket før på anden måde)  
— åben Sign med certificeringsmyndighedens offentlige 
nøgle: Sr'= X.CA.PK [Sign],  
— kontroller, at Sr' begynder med »6A« og ender på »BC« 
— beregn C  r ' og H' af: Sr' =  »6A«  | | C  r ' | |  H '  | |  »BC«  
106 byte  20 byte  
— Hent indhold af certifikat C' = C  r ' || C  n ', 
— kontroller, at  Hash  (C') = H'  
Giver kontrollerne et tilfredsstillende resultat, er certifikat et 
ægte, dets indhold er C'.  
Verificer gyldighed. Fra C':  
— Kontroller i givet fald udløbsdatoen.  
Hent og gem offentlig nøgle, nøgleidentifikator, certifikatin­
dehavers autorisation og certifikatets udløbsdato fra C':  
— X.PK =  n | | e 
— X.KID = CHR  
— X.CHA = CHA  
— X.EOV = EOV  
4. MEKANISME TIL GENSIDIG ÆGTHEDSKONTROL  
Gensidig ægthedskontrol mellem kort og køretøjsenheder bygger p å 
følgende princip:  
Hver part skal over for den anden godtgøre, at den er indehaver  af en 
gyldig nøgle, hvis offentlige nøgle er certificeret af en af me dlemssta­
ternes certificeringsmyndigheder, som selv er certificeret af d en europæ­
iske certificeringsmyndighed.  
Dette sker ved, at der med den private nøgle underskrives et ti lfældigt tal, 
afsendt af den anden part, som derefter skal genfinde det afsen dte tilfæl­
dige tal ved verificering af denne underskrift.  
Mekanismen udløses af køretøjsenheden ved isætning af kortet. D en 
begynder med udveksling af certifikater og udpakning af offentl ige 
nøgler og slutter med isætning af en sessionsnøgle.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 437  
CSM_020 Der skal anvendes følgende protokol (pilene angiver 
kommandoer og udvekslede data (se tillæg 2):
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 438
  
▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 439  
5. MEKANISMER TIL FORTROLIGHED, INTEGRITET OG 
ÆGTHEDSKONTROL VED DATAOVERFØRSEL PÅ KØRETØJS­
ENHEDENS KORT  
5.1. Sikker meddelelsesoverførsel  
CSM_021 Ved overførsler af data på kort i køretøjsenheder skal datain­
tegriteten beskyttes gennem sikker meddelelsesoverførsel i 
overensstemmelse med henvisning [ISO/IEC 7816-4] og 
[ISO/IEC 7816-8].  
CSM_022 Når der er behov for beskyttelse af data under overførs el, skal 
et dataobjekt med kryptografisk kontrolsum vedhæftes de 
dataobjekter, der udsendes inden for kommandoen eller 
svaret. Den kryptografiske kontrolsum skal verificeres af 
modtageren.  
CSM_023 Den kryptografiske kontrolsum af data sendt inden for e n 
kommando skal indeholde kommandoens header og alle de 
afsendte dataobjekter (= > CLA = »0C«, og alle dataobjekter 
skal være indkapslet med mærkater, i hvilke b1 = 1).  
CSM_024 Informationsbyte for svarstatus skal være beskyttet af en 
kryptografisk kontrolsum, når svaret ikke indeholder noget 
datafelt.  
CSM_025 Kryptografiske kontrolsummer skal være 4 byte lange.  
Kommandoer og svar har derfor følgende struktur ved brug af 
sikker meddelelsesoverførsel:  
De anvendte dataobjekter er et delsæt af de dataobjekter for 
sikker meddelelsesoverførsel, som er beskrevet i ISO/IEC 
7816-4:  
Mærkat  Huskeværdi  Betydning  
»81«  T  PV Ordinær værdi af ikke BER-TLV-kodede data (skal 
beskyttes med kryptografisk kontrolsum)  
»97«  T  LE Værdien af Le i den ikke-sikrede kommando (skal 
beskyttes med kryptografisk kontrolsum)  
»99«  T  SW Status (skal beskyttes med kryptografisk kontrolsum)  
»8E«  T  CC Kryptografisk kontrolsum  
»87«  T  PI CG  Byte med udfyldningsindikator || Kryptogram 
(ordinær værdi ikke kodet i BER-TLV)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 440  
Givet et ikke-sikret kommando/svar-par:  
Kommandoheader  Kommandoindhold  
CLA  INS  P 1  P 2  [ L  c -felt]  [Datafelt]  [ L  e -felt]  
Fire byte  L-byte, betegnet B  1 til B  L 
Svarindhold  Svarefterskrift  
[Datafelt]  SW1  SW2  
L r -databyte  To byte  
Det tilsvarende sikrede kommando/svar-par er:  
Sikret kommando:  
Kommandoheader (CH)  Kommandoindhold  
CLA  INS  P 1  P 2  [Nyt L  c -felt]  [Nyt datafelt]  [Nyt 
L e -felt]  
»OC«  Længde af Nyt 
datafelt  T PV L PV PV T  LE L LE L e T CC L CC CC »00«  
»81«  L  c Datafelt  »97«  »01«  L  e »8E«  »04«  C C  
Data, som skal integreres i kontrolsum = CH || PB || T  PV || 
L PV || PV || T  LE || L  LE || L  e || PB  
PB = Udfyldningsbyte (80 .. 00) i overensstemmelse med 
ISO-IEC 7816-4 og ISO 9797, metode 2.  
Dataobjekterne PV og LE er kun til stede, når der er nogle 
tilsvarende data i den ikke-sikrede kommando.  
Sikret svar:  
1. Tilfælde, hvor svardatafeltet ikke er tomt og ikke behøver 
være fortrolighedsbeskyttet:  
Svarindhold  Svarefterskrift  
[Nyt datafelt]  ny SW1 SW2  
T PV L PV PV T  CC L CC CC 
»81«  L  r Datafelt  »8E«  »04«  C C  
Data, der skal integreres i kontrolsum = T  PV || L  PV || PV || 
PB 
2. Tilfælde, hvor svardatafeltet ikke er tomt og behøver være 
fortrolighedsbeskyttet:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 441  
Svarindhold  Svarefterskrift  
[Nyt datafelt]  ny SW1 SW2  
T PI CG  L PI 
CG PI CG  T  CC L CC CC 
»87«  PI || CG  »8E«  »04«  C C  
Data, som skal bæres af CG: ikke-BER-TLV-kodede data 
og udfyldningsbyte.  
Data, der skal integreres i kontrolsummen = T  PI CG  || L  PI 
CG || PI CG || PB  
3. Tilfælde, hvor svardatafeltet er tomt:  
Svarindhold  Svarefterskrift  
[Nyt datafelt]  ny SW1 SW2  
T SW L SW SW T  CC L CC CC 
»99«  »02«  Ny SW1 SW2  »8E«  »04«  C C  
Data, der skal integreres i kontrolsummen = T  SW || L  SW || 
SW || PB  
5.2. Håndtering af fejl ved sikker meddelelsesoverførsel  
CSM_026 Når takografkortet konstaterer en fejl i fortolkningen af en 
kommando under sikker meddelelsesoverførsel, skal status­
bytene returneres uden sikker meddelelsesoverførsel. I 
henhold til ISO/IEC 7816-4 er følgende statusbyte defineret 
til angivelse af fejl under sikker meddelelsesoverførsel:  
»66 88«: Verificering af kryptografisk kontrolsum mislyk­
kedes  
»69 87«: Forventede dataobjekter i sikker meddelelsesover­
førsel mangler  
»69 88«: Dataobjekter i sikker meddelelelsesoverførsel fejl­
behæftede  
CSM_027 Når takografkortet returnerer statusbyte uden dataobjek ter for 
sikker meddelelsesoverførsel (SM) eller med et fejlbehæftet 
SM-dataobjekt, skal sessionen afbrydes af køretøjsenheden.  
5.3. Algoritme til beregning af kryptografiske kontrolsummer  
CSM_028 Kryptografiske kontrolsummer opbygget ved hjælp af en 
sædvanlig MAC i overensstemmelse med ANSI X9.19 med 
DES:  
— Indledende trin: Den indledende kontrolblok y0 er E(Ka, 
SSC),  
— Sekventielt trin: Kontrolblokkene y1, .., yn beregnes ved 
hjælp af Ka.  
— Sluttrin: Den kryptografiske kontrolsum beregnes ved 
hjælp af den sidste kontrolblok yn på følgende måde: 
E(Ka, D(Kb, yn)).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 442  
hvor E() betyder kryptering med DES, og D() betyder dekryp­
tering med DES.  
De fire mest betydende byte i den kryptografiske kontrolsum 
overføres  
CSM_029 Sendesekvenstælleren (SSC) skal under kontrol af nøgleo ver­
ensstemmelse initialiseres med:  
Startværdi af SSC: Rnd3 (fire mindst betydende byte) || Rnd1 
(fire mindst betydende byte).  
CSM_030 Sendesekvenstælleren skal hver gang forhøjes med 1 inde n 
beregning af en MAC (dvs. SSC for den første kommando er 
startværdien af SSC + 1, SSC for det første svar er startvær­
dien af SSC + 2).  
Følgende figur viser beregningen af MAC:
  
5.4. Algoritme til beregning af kryptogrammer til fortrolighedsdata ­
objekter  
CSM_031 Kryptogrammer beregnes ved hjælp af TDEA i TCBC-funk­
tionstilstand i overensstemmelse med henvisning [TDES] og 
[TDES-OP] og med nulvektoren som startværdiblok.  
Følgende figur viser anvendelsen af nøgler i TDES:
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 443  
6. MEKANISMER TIL DIGITAL UNDERSKRIFT AF DATAOVERFØR­
SLER  
CSM_032 Det intelligente dedikerede udstyr (IDE) lagrer data, s om er 
modtaget fra en enhed (køretøjsenhed eller kort) under en 
overførselssession, inden for en fysisk datafil. Denne fil 
skal indeholde certifikaterne MS  i .C og EQT.C. Filen inde­
holder digitale underskrifter af datablokke som foreskrevet i 
tillæg 7, Protokoller til dataoverførsel.  
CSM_033 I digitale underskrifter af overførte data skal anvende s et 
digitalt underskriftssystem med appendiks, således at over­
førte data om ønsket kan læses uden dechifrering.  
6.1. Generering af underskrifter  
CSM_034 Ved generering af en dataunderskrift skal udstyret følg e 
underskriftssystemet med appendiks som fastlagt i henvisning 
PKCS1 med SHA-1-hash-funktionen:  
Underskrift = EQT.SK[»00« || »01« ||  PS  || »00« || 
DER(SHA-1 
(Data))]  
PS = Udfyldningsstreng af oktetter, der har værdien »FF«, så 
længden er 128.  
DER(SHA-1( M)) er kodningen af algoritme-ID'ens 
hash-værdi til en ASN.1-værdi af typen DigestInfo (distin­
guished encoding rules):  
»30«||»21«||»30«||»09«||»06«||»05«||»2B«||»0E«||»03«||»02«||»1A «|| 
»05«||»00«||»04«||»14«||Hash-værdi.  
6.2. Verificering af underskrift  
CSM_035 Ved verificering af dataunderskrift på overførte data s kal 
udstyret følge underskriftssystemet med appendiks som defi­
neret i henvisning [PKCS1] med SHA-1-hash-funktionen.  
Den europæiske offentlige nøgle EUR.PK må uafhængigt (og 
betroet) kendes af kontrolløren.  
Følgende tabel illustrerer den protokol, som en intelligent 
dedikeret enhed (IDE) med kontrolkort kan følge ved verifi­
cering af integriteten af data, som er overført og lagret på 
eksterne lagermedier. Kontrolkortet anvendes til at udføre 
dechifreringen af digitale underskrifter. Denne funktion 
behøver i dette tilfælde ikke være implementeret i det pågæl­
dende IDE.  
Det udstyr, som har overført og underskrevet de data, der skal 
analyseres, benævnes EQT.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 444
  
DEL B  
TAKOGRAFSYSTEM AF ANDEN GENERATION  
7. INDLEDNING  
7.1. Henvisninger  
Følgende henvisninger benyttes i denne del af dette tillæg.  
AES National Institute of Standards og Technology (NIST), 
FIPS PUB 197: Advanced Encryption Standard (AES), 
26. november 2001  
DSS National Institute of Standards and Technology (NIST), 
FIPS PUB 186-4: Digital Signature Standard (DSS), juli 
2013  
ISO 7816-4 ISO/IEC 7816-4, Identification cards — Integrated ci rcuit 
cards — Part 4: Organization, security and commands for 
interchange. Third edition 2013-04-15  
ISO 7816-8 ISO/IEC 7816-8, Identification cards — Integrated ci rcuit 
cards — Part 8: Commands for security operations. 
Second edition 2004-06-01  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 445  
ISO 8825-1 ISO/IEC 8825-1, Information technology — ASN.1 enco­
ding rules: Specification of Basic Encoding Rules (BER), 
Canonical Encoding Rules (CER) and Distinguished 
Encoding Rules (DER). Fourth edition, 2008-12-15  
ISO 9797-1 ISO/IEC 9797-1, Information technology — Security 
techniques — 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, 
including Technical Corrigendum 1 2006  
RFC 5480 Elliptic Curve Cryptography Subject Public Key Infor­
mation, marts 2009  
RFC 5639 Elliptic Curve Cryptography (ECC) — Brainpool Stan­
dard Curves and Curve Generation, 2010  
RFC 5869 HMAC-based Extract-and-Expand Key Derivation 
Function (HKDF), maj 2010  
SHS National Institute of Standards and Technology (NIST), 
FIPS PUB 180-4: Secure Hash Standard, marts 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. Notation og forkortelser  
I dette tillæg bruges følgende notation og forkortelser:  
AES Advanced Encryption Standard  
CA Certificeringsmyndighed  
CAR Henvisning til certificeringsmyndighed  
CBC Blokkædningsfunktion (funktionstilstand)  
CH Kommandoheader  
CHA Certifikatindehavers autorisation  
CHR Henvisning til certifikatindehaver  
CV Konstant vektor  
DER Distinguished Encoding Rules  
DO Dataobjekt  
DSRC Dedicated Short Range Communication  
ECC Elliptisk kurvekryptografi  
ECDSA Digital underskriftsalgoritme for elliptisk kurve  
ECDH Elliptisk kurve Diffie-Hellman (algoritme for nøgleover­
ensstemmelseskontrol)  
EGF Eksternt GNSS-udstyr  
EQT Udstyr  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 446  
IDE Intelligent dedikeret udstyr:  
K M Hovednøgle for bevægelsessensor, der gør det muligt at 
parre en køretøjsenhed med en bevægelsessensor  
K M-VU  Nøgle isat køretøjsenheder, der giver en køretøjsenhed 
mulighed for at udlede hovednøglen til bevægelsessen­
soren, hvis der sættes et værkstedskort i køretøjsenheden  
K M-WC  Nøgle isat værkstedskort, der giver en køretøjsenhed 
mulighed for at udlede hovednøglen til bevægelsessen­
soren, hvis der sættes et værkstedskort i køretøjsenheden  
MAC Message Authentication Code  
MoS Bevægelsessensor  
MSB Mest betydende bit  
PKI Public key-infrastruktur  
RCF Fjernkommunikationsudstyr  
SSC Sendesekvenstæller  
SM Sikker meddelelsesoverførsel  
TDES Tredobbelt datakrypteringsstandard  
TLV Mærkatlængde  
VU Køretøjsenhed  
X.C offentligt nøglecertifikat for brugeren X  
X.CA certifikatmyndigheden, der har udstedt certifikatet for 
brugeren X  
X.CAR henvisning til certifikatmyndigheden, der er angivet i ce rti­
fikatet for brugeren X  
X.CHR henvisning til certifikatindehaveren, der er angivet i ce rti­
fikatet for brugeren X  
X.PK offentlig nøgle for brugeren X  
X.SK privat nøgle for brugeren X  
X.PK  eph midlertidig offentlig nøgle for brugeren X  
X.SK  eph midlertidig privat nøgle for brugeren X  
»xx« hexadecimal værdi  
|| sammenkædningsoperator  
7.3. Definitioner  
Definitionerne af de begreber, der benyttes i dette tillæg, er medtaget i 
bilag 1C, afsnit I.  
8. KRYPTOGRAFISKE SYSTEMER OG ALGORITMER  
8.1. Kryptografiske systemer  
CSM_38 Køretøjsenheder og takografkort skal anvende et elliptis k 
kurvebaseret kryptografisk system med en offentlig nøgle 
til at tilvejebringe følgende sikkerhedsmekanismer:  
— gensidig ægthedskontrol mellem en køretøjsenhed og 
et kort  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 447  
— kontrol af AES-sessionsnøglers overensstemmelse 
mellem en køretøjsenhed og et kort  
— sikring af ægthed, integritet og uafviselighed af data, 
der er overført fra køretøjsenheder eller takografkort til 
eksterne medier.  
CSM_39 Køretøjsenheder og eksternt GNSS-udstyr skal anvende et 
elliptisk kurvebaseret kryptografisk system med en 
offentlig nøgle til at tilvejebringe følgende sikkerheds­
mekanismer:  
— sammenkobling af en køretøjsenhed og eksternt 
GNSS-udstyr  
— gensidig ægthedskontrol mellem en køretøjsenhed og 
eksternt GNSS-udstyr  
— aftale om en AES-sessionsnøgle mellem en køretøjs­
enhed og eksternt GNSS-udstyr.  
CSM_40 Køretøjsenheder og takografkort skal anvende et 
AES-baseret symmetrisk kryptografisk system med en 
offentlig nøgle til at tilvejebringe følgende sikkerheds­
mekanismer:  
— sikring af ægthed og integritet af data, der udveksles 
mellem en køretøjsenhed og et takografkort  
— hvor det er relevant, sikring af fortrolighed af data 
udvekslet mellem en køretøjsenhed og et takografkort.  
CSM_41 Køretøjsenheder og eksternt GNSS-udstyr skal anvende et 
AES-baseret symmetrisk kryptografisk system med en 
offentlig nøgle til at tilvejebringe følgende sikkerheds­
mekanismer:  
— sikring af ægthed og integritet af data udvekslet 
mellem en køretøjsenhed og eksternt GNSS-udstyr.  
CSM_42 Køretøjsenheder og bevægelsessensorer skal anvende et 
AES-baseret symmetrisk kryptografisk system med en 
offentlig nøgle til at tilvejebringe følgende sikkerheds­
mekanismer:  
— parring af en køretøjsenhed og en bevægelsessensor  
— gensidig ægthedskontrol mellem en køretøjsenhed og 
en bevægelsessensor  
— sikring af fortrolighed af data udvekslet mellem en 
køretøjsenhed og en bevægelsessensor.  
CSM_43 Køretøjsenheder og kontrolkort skal anvende et AES- 
baseret symmetrisk kryptografisk system med følgende 
sikkerhedsmekanismer på fjernkommunikationsinterfacet:  
— sikring af fortrolighed, ægthed og integritet af data, der 
sendes fra en køretøjsenhed til et takografkort.  
Bemærk:  
— Data overføres egentlig fra en køretøjsenhed til en 
fjerninterrogator under kontrol af en kontrolførende 
ved hjælp af fjernkommunikationsudstyr, der kan 
være i eller uden for køretøjsenheden, se tillæg 14. 
Fjerninterrogatoren sender dog de modtagne data til  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 448  
et kontrolkort til dekryptering og ægthedskontrol. Rent 
sikkerhedsmæssigt er fjernkommunikationsudstyret og 
fjerninterrogatoren helt gennemsigtige.  
— Et værkstedskort giver samme sikkerhedsmekanismer 
til DSRC-interfacet som et kontrolkort. Derfor kan et 
værkstedskort kontrollere, at fjernkommunikationsinter­
facet i en køretøjsenhed, herunder sikkerheden, 
fungerer korrekt. Der henvises til afsnit 9.2.2 for yder­
ligere oplysninger.  
8.2. Kryptografiske algoritmer  
8.2.1  Symmetriske algoritmer  
CSM_44 Køretøjsenheder, takografkort, bevægelsessensorer og 
eksterne GNSS-funktioner understøtter AES-algoritmen 
som defineret i [AES]; nøglelængder: 128, 192 og 256 bit.  
8.2.2  Asymmetriske algoritmer og standardiserede domæneparametre  
CSM_45 Køretøjsenheder, takografkort og eksterne GNSS-funk­
tioner understøtter elliptisk kurvekryptografi, nøglestør­
relse: 256, 384 og 512/521 bit.  
CSM_46 Køretøjsenheder, takografkort og eksterne GNSS-funk­
tioner understøtter ECDSA-underskriftsalgoritmen som 
specificeret i [DSS].  
CSM_47 Køretøjsenheder, takografkort og eksterne GNSS-funk­
tioner understøtter ECKA-EG-nøgleaftalealgoritmen som 
specificeret i [TR 03111].  
CSM_48 Køretøjsenheder, takografkort og eksterne GNSS-funk­
tioner understøtter alle standardiserede parametre som 
specificeret i nedenstående Tabel 1 for elliptisk 
kurvekryptografi.  
Tabel 1  
Standardiserede domæneparametre  
Navn  Størrelse (bit)  Henvisning  Objektidentifikator  
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 — DA — 21.08.2023 — 003.001 — 449  
Bemærk:  Objektidentifikatorerne i sidste kolonne i Tabel 1 
er specificeret i [RFC 5639] for Brainpool-kurver og i 
[RFC 5480] for NIST-kurver
  
8.2.3  Hash-algoritmer  
▼M1 
CSM_49 Køretøjsenheder, takografkort og eksternt GNSS-udstyr 
skal understøtte SHA-256-, SHA-384- og SHA-512-algo­
ritmerne som specificeret i [SHS].  
▼B 
8.2.4  Talrækker  
CSM_50 For en symmetrisk algoritme anvendes en asymmetrisk 
algoritme og/eller en hash-algoritme sammen som sikker­
hedsprotokol, idet deres respektive nøglelængder og 
hash-størrelser er af (omtrent) samme styrke. Tabel 2 
viser de tilladte talrækker:  
Tabel 2  
Tilladte talrækker  
Talrække-ID  ECC-nøglestørrelse 
(bit) AES-nøglelængde (bit)  Hash-altoritme  MAC-længde 
(byte)  
CS#1  256  128  SHA-256  8  
CS#2  384  192  SHA-384  1 2  
CS#3  512/521  256  SHA-512  1 6  
Bemærk:  ECC-nøglestørrelser på 512 bit og 521 bit anses 
som værende af samme styrke i dette tillæg.  
9. NØGLER OG CERTIFIKATER  
9.1. Asymmetriske nøglepar og certifikater for offentlige nøgler  
9.1.1  Generelt  
Bemærk: De nøgler, der beskrives i dette afsnit, anvendes til g ensidig 
ægthedskontrol og sikker meddelelsesoverførsel mellem køretøjse nheder 
og takografkort og mellem køretøjsenheder og eksterne GNSS-funk ­
tioner. Disse processer beskrives i detaljer i tillæggets kapit el 10 og 11.  
CSM_51 I det europæiske digitale takografsystem genereres og 
forvaltes ECC-nøglepar og tilsvarende certifikater 
gennem tre hierarkiske funktionsniveauer:  
— europæisk niveau  
— medlemsstatsniveau  
— apparatniveau.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 450  
CSM_52 I hele det europæiske intelligent takograf-system genere res, 
forvaltes og meddeles offentlige og private nøgler og certi­
fikater under anvendelse af standardiserede, sikrede 
metoder.  
9.1.2  Europæisk niveau  
CSM_53 På europæisk niveau skal der genereres et enkelt euro­
pæisk nøglepar, der betegnes EUR. Det består af en 
privat nøgle (EUR.SK) og en offentlig nøgle (EUR.PK). 
Dette par udgør det basale nøglepar i hele PKI for den 
europæiske intelligente takograf. Opgaven udføres af en 
europæisk certificeringsmyndighed (ERCA) under Europa- 
Kommissionens myndighed og ansvar.  
CSM_54 ERCA'en benytter den europæiske private nøgle til at 
underskrive et (selvunderskrevet) rodcertifikat for den 
europæiske offentlige nøgle og formidler dette europæiske 
rodcertifikat til alle medlemsstater.  
CSM_55 ERCA'en benytter den europæiske private nøgle til at 
underskrive certifikaterne for medlemsstaternes offentlige 
nøgler, når den anmodes herom. ERCA'en fører registre 
over alle underskrevne nøglecertifikater tilhørende 
medlemsstaterne.  
CSM_56 Som det fremgår af Figur 1 i afsnit 9.1.7 genererer 
ERCA'en et nyt europæisk rodnøglepar hvert 17. år. 
Hver gang ERCA'en genererer et nyt europæisk rodnøg­
lepar, opretter den et nyt selvunderskrevet rodcertifikat for 
den nye europæiske offentlige nøgle. Gyldighedsperioden 
for et europæisk rodcertifikat er 34 år plus 3 måneder.  
Bemærk:  Indførelsen af et nyt rodnøglepar indebærer også, 
at ERCA vil generere en ny hovednøgle til bevægelses­
sensoren og en DSRC-hovednøgle, se afsnit 9.2.1.2 og 
9.2.2.2.  
CSM_57 Inden ERCA'en genererer et nyt europæisk rodnøglepar, 
foretager den en analyse af den kryptografiske styrke, 
der kræves for det nye nøglepar, eftersom det skal være 
sikkert i de næste 34 år. Om nødvendigt skal ERCA'en 
skifte til en talrække, der er stærkere end den nuværende, 
som specificeret i CSM_50.  
▼M1 
CSM_58 Hver gang ERCA'en genererer et nyt europæisk rodnøg­
lepar, opretter den et forbindelsescertifikat til den nye 
europæiske offentlige nøgle og underskriver det med den 
hidtidige europæiske private nøgle. Gyldighedsperioden af 
et forbindelsescertifikat er 17 år plus 3 måneder. Dette 
fremgår ligeledes af Figur 1 i afsnit 9.1.7.  
▼B 
Bemærk: Eftersom et forbindelsescertifikat indeholder 
ERCA'ens offentlige nøgle af generation  X og er under­
skrevet med ERCA'ens private nøgle af generation  X-1 , 
giver forbindelsescertifikatet mulighed for, at man 
gennem udstyr fremstillet under generation  X-1  også kan 
have tillid til udstyr fremstillet under generation  X. 
CSM_59 ERCA'en må ikke bruge den private nøgle for et rodnøg­
lepar til noget formål efter det tidspunkt, hvor et nyt 
rodnøglecertifikat bliver gyldigt.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 451  
CSM_60 ERCA'en skal til enhver tid råde over følgende kryptogra ­
fiske nøgler og certifikater:  
— Det aktuelle EUR-nøglepar og det tilhørende certifikat  
— Alle tidligere EUR-certifikater, der skal anvendes til 
verifikation af MSCA-certifikater, der stadig er gyldige  
— Forbindelsescertifikater for alle generationer af 
EUR-certifikater undtagen den første.  
9.1.3  Medlemsstatsniveau  
CSM_61 På medlemsstatsniveau generer alle medlemsstater, der sk al 
underskrive takografkortcertifikater, et eller flere entydige 
ECC-nøglepar, der betegnes et MSCA_Card. Alle 
medlemsstater, der skal underskrive certifikater til køretøjs­
enheder eller eksternt GNSS-udstyr, genererer desuden et 
eller flere andre entydige ECC-nøglepar, der betegnes 
MSCA_VU-EGF.  
CSM_62 Opgaven med at generere medlemsstatens nøglepar vare­
tages af en certificeringsmyndighed i medlemsstaten 
(MSCA). Når en MSCA genererer en medlemsstats 
nøglepar, sender den den offentlige nøgle til ERCA'en 
for at få et tilsvarende medlemsstatscertifikat underskrevet 
af ERCA'en.  
CSM_63 En MSCA vælger styrken af en medlemsstats nøglepar, så 
den svarer til styrken af det europæiske rodnøglepar, der 
bruges til at underskrive den tilhørende medlemsstats 
certifikat.  
CSM_64 Hvis der foreligger et MSCA_VU-EGF-nøglepar, består 
det af en privat nøgle, MSCA_VU-EGF.SK, og en 
offentlig nøgle, MSCA_VU-EGF.PK. En MSCA bruger 
udelukkende den private nøgle MSCA_VU-EGF.SK til at 
underskrive de offentlige nøglecertifikater for køretøjs­
enheder og eksternt GNSS-udstyr.  
CSM_65 Et MSCA_Card-nøglepar består af den private nøgle 
MSCA_Card.SK og den offentlige nøgle MSCA_Card.PK. 
En MSCA benytter udelukkende den private nøgle 
MSCA_Card.SK til at underskrive de offentlige nøglecer­
tifikater for takografkort.  
CSM_66 En MSCA fører registre over alle underskrevne køretøjs­
enhedscertifikater, certifikater for ekstern GNSS-udstyr og 
kortcertifikater sammen med identifikation af det udstyr, 
som hvert certifikat er beregnet til.  
CSM_67 Gyldighedsperioden for et MSCA_VU-EGF-certifikat er 
17 år plus 3 måneder. Gyldighedsperioden for et 
MSCA_Card-certifikat er 7 år plus 1 måned.  
CSM_68 Som det fremgår af Figur 1 i afsnit 9.1.7 skal den priva te 
nøgle for et MSCA_VU-EGF-nøglepar have en nøgle­
brugsperiode på to år.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 452  
CSM_69 En MSCA må ikke bruge den private nøgle for et 
MSCA_VU-EGF-nøglepar til noget formål, efter at dens 
brugstid er udløbet. En MSCA må heller ikke bruge den 
private nøgle i et MSCA_Card-nøglepar til andre formål, 
efter at dets brugstid er udløbet.  
CSM_70 En MSCA skal til enhver tid råde over følgende krypto­
grafiske nøgler og certifikater:  
— Det aktuelle MSCA_Card-nøglepar og det tilhørende 
certifikat  
— Alle tidligere MSCA_Card-certifikater, der skal 
anvendes til verifikation af certifikaterne for takograf­
kort, der stadig er gyldige  
— Det aktuelle EUR-certifikat, der skal anvendes til veri­
fikation af det aktuelle MSCA-certifikat  
— Alle tidligere EUR-certifikater, der skal anvendes til 
verifikation af alle MSCA-certifikater, der stadig er 
gyldige.  
CSM_71 Hvis en MSCA skal underskrive certifikater for køretøjs­
enheder eller eksternt GNSS-udstyr, skal den endvidere 
råde over følgende nøgler og certifikater:  
— Det aktuelle MSCA_VU-EGF-nøglepar og det tilhø­
rende certifikat  
— Alle tidligere MSCA_VU_EGF-certifikater, der skal 
anvendes til verifikation af certifikaterne for køretøjs­
enheder eller eksternt GNSS-udstyr, der stadig er 
gyldige.  
9.1.4  Apparatniveau: Køretøjsenheder  
▼M1 
CSM_72 Der skal genereres to entydige ECC-nøglepar for hver 
køretøjsenhed, som betegnes VU_MA og VU_Sign. 
Denne opgave varetages af køretøjsenhedsfabrikanterne. 
Når der genereres et køretøjsenhedsnøglepar, sender den 
part, der genererer nøglen den offentlige nøgle til sin 
MSCA for at få et tilhørende køretøjsenhedscertifikat 
underskrevet af MSCA'en. Den private nøgle må kun 
benyttes af køretøjsenheden.  
▼B 
CSM_73 VU_MA- og VU_Sign-certifikaterne for en givet køretøjs­
enhed skal have samme gyldighedsdato.  
CSM_74 En fabrikant af en køretøjsenhed vælger styrken af et kø re­
tøjsenhedsnøglepar, så den svarer til styrken af det 
MSCA-nøglepar, der bruges til at underskrive det tilhø­
rende køretøjsenhedscertifikat.  
CSM_75 En køretøjsenhed må udelukkende benytte sit VU_MA- 
nøglepar, som består af en privat VU_MA.SK-nøgle og 
en offentlig VU_MA.PK-nøgle til at foretage ægthedskon­
trol af køretøjsenheden i forhold til takografkort og 
eksternt GNSS-udstyr, som specificeret i afsnit 10.3 og 
11.4 i dette tillæg.  
CSM_76 En køretøjsenhed skal kunne generere midlertidige 
ECC-nøglepar og må udelukkende bruge et midlertidigt 
nøglepar til at foretage kontrol af en sessionsnøgles over­
ensstemmelse med et takografkort eller eksternt 
GNSS-udstyr, som specificeret i afsnit 10.4 og 11.4 i 
dette tillæg.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 453  
CSM_77 En køretøjsenhed må udelukkende anvende den private 
VU_Sign.SK-nøgle i sit VU_Sign-nøglepar til at under­
skrive overførte datafiler som specificeret i kapitel 14 i 
dette tillæg. Den tilhørende offentlige VU_Sign.PK-nøgle 
må udelukkende anvendes til at verificere underskrifter 
oprettet af køretøjsenheden.  
CSM_78 Som vist i Figur 1 i afsnit 9.1.7 er gyldighedsperioden for 
et VU_MA-certifikat 15 år og 3 måneder. Gyldigheds­
perioden for et VU_Sign-certifikat er ligeledes 15 år og 
3 måneder.  
Bemærk:  
— Den udvidede gyldighedsperiode for et VU_Sign-certi­
fikat giver en køretøjsenhed mulighed for at oprette 
gyldige underskrifter over overførte data i de første 
tre måneder, efter at det er udløbet, jf. forordning 
(EU) nr. 581/2010.  
— Den udvidede gyldighedsperiode for et VU_MA-certi­
fikat er nødvendig for at give køretøjsenheden 
mulighed for at bekræfte ægtheden af et kontrolkort 
eller et virksomhedskort i løbet de første tre måneder, 
efter at det er udløbet, således at det er muligt at fore­
tage dataoverførsel.  
CSM_79 En køretøjsenhed må ikke bruge den private nøgle i et 
køretøjsenhedsnøglepar til noget formål, efter at det tilhø­
rende certifikat er udløbet.  
CSM_80 Køretøjsenhedsnøgleparrene (undtagen midlertidige 
nøglepar) og de tilhørende certifikater for en given køre­
tøjsenhed må ikke erstattes eller fornys i marken, når først 
køretøjsenheden er taget i drift.  
Bemærk:  
— Midlertidige nøglepar er ikke medtaget i dette krav, 
eftersom en køretøjsenhed genererer et nyt midlertidigt 
nøglepar, hver gang der foretages ægthedskontrol af en 
chip og overensstemmelseskontrol af en sessionsnøgle, 
se afsnit 10.4. Bemærk, at midlertidige nøglepar ikke 
har tilhørende certifikater.  
— Dette krav indeholder ikke forbud mod at erstatte 
statiske køretøjsenhedsnøglepar i forbindelse med en 
renovering eller reparation i et sikkert miljø under 
kontrol af fabrikanten af køretøjsenheden.  
CSM_81 Når køretøjsenheder tages i drift, skal de indeholde 
følgende kryptografiske nøgler og certifikater:  
— Den private VU_MA-nøgle med tilhørende certifikat  
— Den private VU_Sign-nøgle med tilhørende certifikat  
— MSCA_VU-EGF-certifikatet, der indeholder den offent­
lige MSCA_VU-EGF.PK-nøgle, der skal benyttes til veri­
fikation af VU_MA-certifikatet og VU_Sign-certifikatet  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 454  
— EUR-certifikatet, der indeholder den offentlige EUR.PK- 
nøgle, der skal benyttes til verifikation af MSCA_VU- 
EGF-certifikatet  
— EUR-certifikatet, hvis gyldighedsperiode ligger umid­
delbart forud for EUR-certifikatets gyldighedsperiode, 
som skal anvendes til at verificere MSCA_VU-EGF- 
certifikatet, hvis dette findes  
— Forbindelsescertifikatet, der knytter disse to EUR-certi­
fikater sammen, hvis dette findes.  
CSM_82 Ud over de kryptografiske nøgler og certifikater, der st år 
opført i CSM_81, skal køretøjsenhederne også indeholde 
de nøgler og certifikater, der specificeres i del A i dette 
tillæg, således at en køretøjsenhed kan interagere med 
takografkort af første generation.  
9.1.5  Apparatniveau: Takografkort  
▼M1 
CSM_83 Der genereres et entydigt ECC- nøglepar, som betegnes 
Card_MA, for hvert takografkort. Der genereres desuden 
endnu et entydigt ECC-nøglepar, som betegnes Card_Sign, 
for hvert førerkort og hvert værkstedskort. Denne opgave 
kan udføres af kortfabrikanter eller leverandører af indivi­
duelle tilpasninger af kort. Når der genereres et kortnøg­
lepar, sender den part, der genererer nøglen den offentlige 
nøgle til sin MSCA for at få et tilhørende kortcertifikat 
underskrevet af MSCA'en. Den private nøgle må kun 
benyttes af takografkortet.  
▼B 
CSM_84  Card_MA- og Card_Sign-certifikaterne for et bestemt fører­
kort eller værkstedskort skal have samme gyldighedsdato.  
CSM_85 En kortfabrikant eller en leverandør af individuelle til pas­
ninger af kort skal vælge styrken for et kortnøglepar, så 
den svarer til styrken af det MSCA-nøglepar, som 
anvendes til at underskrive det tilhørende kortcertifikat.  
CSM_86 Et takografkort må udelukkende bruge sit Card_MA- 
nøglepar, som består af den private Card_MA.SK-nøgle 
og den offentlige Card_MA.PK-nøgle, til at foretage 
gensidig ægthedskontrol og kontrol af en sessionsnøgles 
overensstemmelse med køretøjsenheder som specificeret i 
afsnit 10.3 og 10.4 i dette tillæg.  
CSM_87 Et førerkort eller værkstedskort må udelukkende bruge de n 
private Card_Sign.SK-nøgle i sit Card_Sign-nøglepar til at 
underskrive overførte datafiler som specificeret i kapitel 14 
i dette tillæg. Den tilhørende offentlige Card_Sign.PK- 
nøgle må udelukkende bruges til at verificere de under­
skrifter, som kortet opretter.  
▼M1 
CSM_88 Et Card_MA-certifikat har følgende gyldighedsperiode:  
— for førerkort: 5 år  
— for virksomhedskort: 5 år  
— for kontrolkort: 2 år  
— for værkstedskort: 1 år.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 455  
CSM_89 Et Card_Sign-certifikat har følgende gyldighedsperiode: 
— For førerkort:  5 år og 1 måned  
— For værkstedskort:  1 år og 1 måned  
Bemærk:  Den udvidede gyldighedsperiode for et 
Card_Sign-certifikat giver et førerkort mulighed for at 
oprette gyldige underskrifter over overførte data i den 
første måned, efter at det er udløbet. Dette er nødvendigt 
i henhold til forordning (EU) nr. 581/2010, hvori det 
kræves, at en dataoverførsel fra et førerkort skal være 
mulig i op til 28 dage, efter at de seneste data er 
registreret.  
CSM_90 Nøgleparrene og de tilhørende certifikater for et bestem t 
takografkort erstattes eller fornys ikke, når kortet er 
udstedt.  
CSM_91 Når takografkort er udstedt, skal de indeholde følgende 
kryptografiske nøgler og certifikater:  
— Den private Card_MA-nøgle med tilhørende certifikat  
— For førerkort og værkstedskort desuden: den private 
Card_Sign-nøgle med tilhørende certifikat  
— MSCA_Card-certifikatet, der indeholder den offentlige 
nøgle MSCA_Card.PK, der skal benyttes til verifika­
tion af Card_MA-certifikatet og Card_Sign-certifikatet  
— EUR-certifikatet, der indeholder den offentlige EUR.PK- 
nøgle, der skal benyttes til verifikation af MSCA_Card- 
certifikatet  
— EUR-certifikatet, hvis gyldighedsperiode ligger umid­
delbart forud for EUR-certifikatets gyldighedsperiode, 
som skal anvendes til at verificere MSCA_Card-certi­
fikatet, hvis dette findes  
— Forbindelsescertifikatet, der knytter disse to EUR-certi­
fikater sammen, hvis dette findes  
▼M1 
— Udelukkende for kontrolkort, virksomhedskort og 
værkstedskort gælder desuden, at hvis sådanne kort 
udstedes i løbet af de første tre måneder af gyldigheds­
perioden for et nyt EUR-certifikat: det EUR-certifikat, 
som er to generationer ældre, hvis dette findes.  
Bemærkning til sidste led : F.eks. i de første tre 
måneder af ERCA(3)-certifikatet (jf. Figur 1), skal de 
nævnte kort indeholde ERCA(1)-certifikatet. Det er 
nødvendigt, så disse kort kan anvendes til at udføre 
dataoverførsel fra ERCA(1)-køretøjsenheder, hvis 
normale dataoverførselslevetid på 15 år plus 3 
måneder udløber i disse måneder; se det sidste led i 
krav 13) i bilag I C.  
▼B 
CSM_92 Ud over de kryptografiske nøgler og certifikater, der st år 
opført i CSM_91, skal takografkortene også indeholde de 
nøgler og certifikater, der specificeres i del A i dette tillæg , 
således at disse kort kan interagere med køretøjsenheder af 
første generation.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 456  
9.1.6  Apparatniveau: Eksternt GNSS-udstyr  
▼M1 
CSM_93 Der genereres et entydigt ECC-nøglepar for hvert ekstern t 
GNSS-udstyr, som betegnes EGF_MA. Denne opgave 
varetages af fabrikanter af eksternt GNSS-udstyr. Når der 
genereres et EGF_MA-nøglepar, sender den part, der gene­
rerer nøglen den offentlige nøgle til sin MSCA for at få et 
tilhørende EGF_MA-certifikat underskrevet af MSCA'en. 
Den private nøgle må kun benyttes af det eksterne 
GNSS-udstyr.  
▼B 
CSM_94 En EGF-fabrikant vælger styrken af et EGF_MA-nøglepar, 
så den svarer til styrken af det MSCA-nøglepar, der bruges 
til at underskrive det tilhørende EGF_MA-certifikat.  
▼M1 
CSM_95 Eksternt GNSS-udstyr må udelukkende bruge sit 
EGF_MA-nøglepar, som består af den private nøgle 
EGF_MA.SK og den offentlige nøgle EGF_MA.PK til at 
foretage gensidig ægthedskontrol og kontrol af en 
sessionsnøgles overensstemmelse med køretøjsenheder 
som specificeret i afsnit 11.4 i dette tillæg.  
▼B 
CSM_96 EGF_MA-certifikatets gyldighedsperiode er 15 år.  
CSM_97 Eksternt GNSS-udstyr må ikke bruge den private nøgle i e t 
EGF_MA-nøglepar til opkobling til en køretøjsenhed, efter 
at det tilhørende certifikat er udløbet.  
Bemærk:  Som forklaret i afsnit 11.3.3 kan en EGF even­
tuelt bruge sin private nøgle til gensidig ægthedskontrol 
over for den køretøjsenhed, som den allerede er koblet 
op til, selv efter at det tilhørende certifikat er udløbet.  
CSM_98 EGF_MA-nøgleparret og det tilhørende certifikat for 
givent eksternt GNSS-udstyr må ikke erstattes eller 
fornys i marken, når først EGF'en er taget i drift.  
Bemærk: Dette krav indeholder ikke forbud mod at erstatte 
EGF-nøglepar i forbindelse med en renovering eller repa­
ration i et sikkert miljø under kontrol af EGF-fabrikanten.  
CSM_99 Når det eksterne GNSS-udstyr tages i drift, skal den ind e­
holde følgende kryptografiske nøgler og certifikater:  
— Den private EGF_MA-nøgle og tilhørende certifikat  
— MSCA_VU-EGF-certifikatet, der indeholder den 
offentlige nøgle MSCA_VU-EUR.PK, der skal 
benyttes til verifikation af EGF_MA-certifikatet  
— EUR-certifikatet, der indeholder den offentlige EUR.PK- 
nøgle, der skal benyttes til verifikation af MSCA_VU- 
EGF-certifikatet  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 457  
— EUR-certifikatet, hvis gyldighedsperiode ligger umid­
delbart forud for EUR-certifikatets gyldighedsperiode, 
som skal anvendes til at verificere MSCA_VU-EGF- 
certifikatet, hvis dette findes  
— Forbindelsescertifikatet, der knytter disse to EUR-certi­
fikater sammen, hvis dette findes.  
9.1.7  Oversigt: Udskiftning af certifikat  
Figur 1 herunder viser, hvordan forskellige generationer af ERC A-rodcer­
tifikater, ERCA-forbindelsescertifikater, MSCA-certifikater og udstyrscer­
tifikater (køretøjsenhed og kort) udstedes og anvendes:  
▼M1 
Figur 1  
Udstedelse og brug af forskellige generationer af ERCA-rodcertifikater, ERCA-forbindelsescertifikater, 
MSCA-certifikater og udstyrscertifikater
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 458  
Bemærkninger til Figur 1:  
1. Forskellige generationer af rodcertifikatet angives med et t al i 
parentes. ERCA (1) er f.eks. første generation af ERCA-rodcerti fi­
katet, ERCA (2) er anden generation osv.  
2. Andre certifikater angives med to tal i parentes, hvoraf det  første 
angiver generationen af rodcertifikat, under hvilken de er udst edt, 
det andet generationen for selve certifikatet. MSCA_Card (1-1) er 
f.eks. det første MSCA_Card-certifikat udstedt under ERCA (1), 
MSCA_Card (2-1) er det første MSCA_Card-certifikat udstedt unde r 
ERCA (2), MSCA_Card (2-last) er det sidste MSCA_Card-certifikat  
udstedt under ERCA (2), Card_MA(2-1) er det første kortcertifik at til 
gensidig ægthedskontrol, der er udstedt under ERCA (2) osv.  
3. Certifikaterne MSCA_Card (2-1) og MSCA_Card (1-last) udstede s på 
næsten samme dato, men ikke præcis den samme. MSCA_Card (2-1) 
er det første MSCA_Card-certifikat udstedt under ERCA (2) og vi l 
blive udstedt en smule senere end MSCA_Card (1-last), det sidst e 
MSCA_Card-certifikat under ERCA (1).  
4. Som det fremgår af figuren, kommer de første køretøjsenheds-  og 
kortcertifikater udstedt under ERCA (2) næsten to år inden, de 
sidste køretøjsenheds- og kortcertifikater udstedt under ERCA ( 1) 
kommer frem. Dette skyldes, at køretøjsenheds- og kortcertifika ter 
udstedes under et MSCA-certifikat og ikke direkte under 
ERCA-certifikatet. MSCA (2-1)-certifikatet vil blive udstedt um iddel­
bart efter, at ERCA (2) bliver gyldigt, men MSCA (1-last)-certi fikatet 
udstedes kun ganske kort tid inden dette tidspunkt, nemlig lige  inden 
ERCA (1)-certifikatet udløber. Derfor vil disse to MSCA-certifi kater 
have næsten samme gyldighedsperiode, selv om de kommer fra 
forskellige generationer.  
5. Den viste gyldighedsperiode for kort gælder for førerkort (5  år). 
▼M1 
6. Af pladshensyn vises forskellen i gyldighedsperiode mellem 
Card_MA- og Card_Sign-certifikaterne kun for første generation.  
▼B 
9.2. Symmetriske nøgler  
9.2.1  Nøgler til sikring af kommunikation mellem køretøjsenhed og bevægel ­
sessensor  
9.2.1.1  Generelt  
Bemærk: Læserne af dette afsnit formodes at være fortrolige med  
indholdet af [ISO 16844-3], som indeholder en beskrivelse af in terfacet 
mellem en køretøjsenhed og en bevægelsessensor. Parringsprocess en 
mellem en køretøjsenhed og en bevægelsessensor beskrives nærmer e i 
kapitel 12 i dette tillæg.  
CSM_100 Der skal bruges et antal symmetriske nøgler til parring  af 
køretøjsenheder og bevægelsessensorer, til gensidig 
ægthedskontrol mellem køretøjsenheder og bevægelsessen­
sorer og til kryptering af kommunikation mellem køretøjs­
enheder og bevægelsessensorer som vist i Tabel 3. Alle 
disse nøgler skal være AES-nøgler med en nøglelængde, 
der er lig med længden af bevægelsessensorens hovednøgle, 
som er knyttet til længden af det (planlagte) europæiske 
rodnøglepar som beskrevet i CSM_50.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 459  
Tabel 3  
Nøgler til sikring af kommunikation mellem køretøjsenhed og bevægelsessensor  
Forklaring  Symbol  Genereret af  Genereringsmetode  Gemt af  
Hovednøgle til bevægel­
sessensoren — køretøjs­
enhedens del  K M-VU  ERCA  Tilfældig  ERCA, MSCA'er, der udsteder 
certifikater for køretøjsenheder, 
fabrikanter af køretøjsenheder, 
køretøjsenheder  
Hovednøglen til bevæ­
gelsessensoren — værk­
stedsdel  K M-WC  ERCA  Tilfældig  ERCA, MSCA'er, kortfabri­
kanter, værkstedskort  
Hovednøgle til bevægel­
sessensoren  K M Genereres ikke 
uafhængigt  Beregnet som K  M = K  M- 
VU XOR K  M-WC  ERCA, MSCA'er, der er invol­
veret i udstedelse af bevægel­
sessensornøglepar (valgfrit) (*)  
Identifikationsnøgle  K  ID Genereres ikke 
uafhængigt  Beregnet som K  ID = K M 
XOR CV, hvor CV 
specificeres i CSM_106  ERCA, MSCA'er, der er invol­
veret i udstedelse af bevægel­
sessensornøglepar (valgfrit) (*)  
Parringsnøgle  K  P Fabrikant af bevæ­
gelsessensor  Tilfældig  En bevægelsessensor  
Sessionsnøgle  K  S Køretøjsenhed 
(under parring af 
køretøjsenhed og 
bevægelsessensor)  Tilfældig  En køretøjsenhed og en bevæ­
gelsessensor  
(*) Det er valgfrit, om man vil gemme K  M og K  ID , eftersom disse nøgler kan udledes fra K  M-VU  , K  M-WC  og CV.  
CSM_101 Den europæiske certificeringsmyndighed genererer K  M-VU  
og K  M-WC  , to tilfældige og entydige AES-nøgler, ud fra 
hvilke bevægelsessensorens hovednøgle K  M kan beregnes 
som K  M-VU  XOR K  M-WC  . ERCA'en sender K  M, K M-VU  og 
K M-WC  til medlemsstatens certificeringsmyndighed efter 
anmodning fra disse.  
CSM_102 ERCA'en tildeler hver af bevægelsessensorernes hoved­
nøgler K  M et entydigt versionsnummer, som ligeledes 
gælder for de indgående nøgler K  M-VU  og K  M-WC  og den 
tilhørende identifikationsnøgle K  ID. ERCA'en underretter 
MSCA'erne om versionsnummeret, når den sender K  M-VU  
og K  M-WC  til dem.  
Bemærk:  Versionsnummeret benyttes til at skelne mellem 
forskellige generationer af disse nøgler som forklaret 
nærmere i afsnit 9.2.1.2.  
CSM_103 En medlemsstats certificeringsmyndighed fremsender K  M-VU  
sammen med dens versionsnummer til fabrikanter af køre­
tøjsenheder efter anmodning fra disse. Fabrikanterne af køre­
tøjsenhederne indsætter K  M-VU  og dens versionsnummer i 
alle fremstillede køretøjsenheder.  
CSM_104 En medlemsstats certificeringsmyndighed sikrer, at K  M-WC  
sammen med dens versionsnummer indsættes i alle værk­
stedskort, som den har ansvaret for at udstede.  
Bemærk:  
— Se beskrivelsen af datatypen
  
i tillæg 2.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 460  
— Som forklaret i afsnit 9.2.1.2 kan det være nødvendigt at 
indsætte flere generationer af K  M-WC  på et og samme 
værkstedskort.  
CSM_105 Ud over AES-nøglen, som specificeres i CSM_104, skal en  
MSCA sikre, at TDES-nøglen Km  WC, der specificeres i krav 
CSM_037 i del A i dette tillæg, indsættes i alle værksteds­
kort, som den har ansvaret for at udstede.  
Bemærk:  
— Dette gør det muligt at sammenkoble et værkstedskort af 
anden generation med en køretøjsenhed af første 
generation.  
— Et værkstedskort af anden generation vil indeholde to 
forskellige applikationer — en, der er i overensstem­
melse med del B i dette tillæg, og en, der er i over­
ensstemmelse med del A. Sidstnævnte indeholder 
TDES-nøglen Km  WC . 
CSM_106 En MSCA, der beskæftiger sig med at udstede bevægelses­
sensorer, skal hente identifikationsnøglen fra bevægelsessen­
sorens hovednøgle ved at udføre en XOR-operation på den 
med en konstant vektor (CV). Værdien af CV er som følger:  
▼M1 
— For 128-bit hovednøgler til bevægelsessensorer: CV = 
»B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 
83« 
▼B 
— For 192-bit hovednøgler til bevægelsessensorer: 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«  
— For 256-bit hovednøgler til bevægelsessensorer: 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«  
Bemærk:  De konstante vektorer er genereret som følger:  
Pi_10 = de første 10 byte af decimaldelen af den matema­
tiske konstant π = »24 3F 6A 88 85 A3 08 D3 13 19«  
CV_128-bit = første 16 byte af SHA-256(Pi_10)  
CV_192-bit = første 24 byte af SHA-384(Pi_10)  
CV_256-bit = første 32 byte af SHA-512(Pi_10)  
CSM_107  ►M1 Hver fabrikant af bevægelsessensorer genererer en 
tilfældig og entydig parringsnøgle K  P til hver bevægelses­
sensor og sender hver enkelt parringsnøgle til sin medlems­
stats certificeringsmyndighed. MSCA'en krypterer hver 
parringsnøgle separat med bevægelsessensorens hovednøgle 
K M og returnerer den krypterede nøgle til fabrikanten af 
bevægelsessensoren. For hver krypteret nøgle meddeler 
MSCA'en fabrikanten af bevægelsessensoren versionsnum­
meret for den tilhørende K  M . ◄ 
Bemærk:  Som forklaret i afsnit 9.2.1.2 skal en fabrikant af 
en bevægelsessensor muligvis generere flere entydige 
parringsnøgler til den samme bevægelsessensor.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 461  
CSM_108 Hver fabrikant af bevægelsessensorer genererer et entyd igt 
serienummer til hver bevægelsessensor og sender alle serie­
numre til sin medlemsstats certificeringsmyndighed. 
MSCA'en krypterer hvert serienummer separat med identifi­
kationsnøglen K  ID og returnerer det krypterede serienummer 
til fabrikanten af bevægelsessensoren. For hvert krypteret 
serienummer meddeler MSCA'en fabrikanten af bevægelses­
sensoren versionsnummeret for den tilhørende K  ID . 
▼B 
CSM_109 For krav CSM_107 og CSM_108 skal MSCA'en benytte 
AES-algoritmen i blokkædningsfunktionen som defineret i 
[ISO 10116] med en indskudt parameter  m = 1 og en initi­
aliseringsvektor SV = »00« {16}, dvs. 16 byte med en binær 
værdi på 0. Om nødvendigt skal MSCA'en benytte udfyld­
ningsmetode 2, som defineres i [ISO 9797-1].  
CSM_110 Fabrikanten af bevægelsessensoren gemmer den krypterede  
parringsnøgle og det krypterede serienummer i den planlagte 
bevægelsessensor sammen med de tilhørende klartekstvær­
dier og versionsnummeret for K  M og K  ID, som benyttes til 
kryptering.  
Bemærk:  Som forklaret i afsnit 9.2.1.2 skal en fabrikant af 
en bevægelsessensor muligvis indsætte flere krypterede 
parringsnøgler og flere krypterede serienumre i en og 
samme bevægelsessensor.  
CSM_111 Ud over det AES-baserede kryptografiske materiale, der 
specificeres i CSM_110, kan en fabrikant af en bevægelses­
sensor ligeledes gemme det TDES-baserede kryptografiske 
materiale, der specificeres i krav CSM_037 i del A i dette 
tillæg, i hver bevægelsessensor.  
Bemærk:  Dette betyder, at en bevægelsessensor af anden 
generation kan kobles sammen med en køretøjsenhed af 
første generation.  
CSM_112 Længden af sessionsnøglen K  S , som en bevægelsessensor 
genererer under parringen med en bevægelsessensor, skal 
kædes sammen med længden af dens K  M-VU  som beskrevet 
i CSM_50.  
9.2.1.2  Udskiftning af hovednøglen til bevægelsessensoren i udstyr af anden 
generation  
CSM_113 Hver hovednøgle til bevægelsessensoren og alle tilhøren de 
nøgler (se Tabel 3) er knyttet til en bestemt generation af 
ERCA-rodnøglepar. Derfor skal disse nøgler udskiftes hvert 
17. år. Gyldighedsperioden for hver hovednøglegeneration 
for bevægelsessensoren indledes et år inden, det tilhørende 
ERCA-rodnøglepar bliver gyldigt, og afsluttes, når det tilhø­
rende ERCA-rodnøglepar udløber. Dette fremgår af Figur 2.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 462  
Figur 2  
Udstedelse og brug af forskellige generationer af hovednøgler til bevægelsessensorer i køretøjsenheder, 
bevægelsessensorer og værkstedskortkort
  
CSM_114 Mindst et år inden genereringen af et nyt europæisk rod nøg­
lepar som beskrevet i CSM_56 genererer ERCA'en en ny 
hovednøgle til bevægelsessensoren K  M ved at generere en 
ny K  M-VU  og K  M-WC  . Længden af bevægelsessensorens 
hovednøgle kædes sammen med den planlagte styrke af 
det nye europæiske rodnøglepar i henhold til CSM_50. 
ERCA'en sender de nye K  M , K  M-VU  og K  M-WC  til 
MSCA'en efter anmodning fra disse sammen med deres 
versionsnummer.  
CSM_115 En MSCA skal sikre, at alle gyldige generationer af K  M-WC  
gemmes i alle værkstedskort, der udstedes under dens 
myndighed, sammen med deres versionsnumre som vist i 
Figur 2.  
Bemærk: Dette betyder, at værkstedskortene i det sidste år af e t 
ERCA-certifikats gyldighedsperiode vil blive udstedt med tre 
forskellige generationer af K  M-WC  som vist i Figur 2.  
CSM_116 Med hensyn til den proces, der beskrives i CSM_107 og 
CSM_108 ovenfor: En MSCA skal kryptere hver parrings­
nøgle K  P , som den modtager fra en fabrikant af en bevæ­
gelsessensor separat med hver gyldig generation af hoved­
nøgler til bevægelsessensoren K  M . En MSCA skal ligeledes 
kryptere hvert serienummer, som den modtager fra en fabri­
kant af en bevægelsessensor, separat med hver gyldig gene­
ration af identifikationsnøglen K  ID . En fabrikant af en bevæ­
gelsessensor gemmer alle krypteringer af parringsnøglen og 
alle krypteringer af serienummeret i den planlagte bevægel­
sessensor sammen med de tilhørende klartekstværdier og 
versionsnummer/-numre for K  M og K  ID, som benyttes til 
kryptering.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 463  
Bemærk:  Dette betyder, at i det sidste år af et 
ERCA-certifikats gyldighedsperiode, vil bevægelsessenso­
rerne blive udstedt med krypterede data baseret på tre 
forskellige generationer af K  M som vist i Figur 2.  
CSM_117 Med hensyn til den proces, som beskrives i CSM_107 
ovenfor: Eftersom længden af parringsnøglen K  P skal være 
kædet sammen med længden af K  M (se CSM_100), skal en 
fabrikant af en bevægelsessensor muligvis generere op til tre 
forskellige parringsnøgler (af forskellig længde) til samme 
bevægelsessensor, hvis efterfølgende generationer af K  M har 
forskellige længder. I dette tilfælde skal fabrikanten sende 
hver parringsnøgle til MSCA'en. MSCA'en skal sikre, at 
hver parringsnøgle er krypteret med den korrekte generation 
af bevægelsessensorens hovednøgle, dvs. den med samme 
længde.  
Bemærk:  Hvis fabrikanten af bevægelsessensoren vælger at 
generere en TDES-baseret parringsnøgle til en bevægelses­
sensor af anden generation (se CSM_111), skal fabrikanten 
over for MSCA'en angive, at den TDES-baserede hoved­
nøgle til bevægelsessensoren skal benyttes til kryptering af 
denne parringsnøgle. Dette skyldes, at længden af en 
TDES-nøgle kan være lig med længden af en AES-nøgle, 
så MSCA'en kan ikke vurdere dette alene ud fra nøgle­
længden.  
CSM_118 Fabrikanter af køretøjsenheder må kun isætte en generat ion 
af K  M-VU  i hver køretøjsenhed sammen med dens versions­
nummer. Denne K  M-VU  -generation kædes sammen med det 
ERCA-certifikat, som køretøjsenhedens certifikater er 
baseret på.  
Bemærk:  
— En køretøjsenhed baseret på et ERCA-certifikat af gene­
ration  X skal kun indeholde K  M-VU  af generation  X, selv 
om det er udstedt efter indledningen af gyldigheds­
perioden for ERCA-certifikatet af generation  X+1 . 
Dette illustreres i Figur 2.  
— En køretøjsenhed af generation  X kan ikke parres med 
en bevægelsessensor af generation  X-1. 
— Eftersom værkstedskort har en gyldighedsperiode på et 
år, er resultatet af CSM_113-CSM_118, at alle værk­
stedskort vil indeholde den nye K  M-WC  på det tidspunkt, 
hvor den første køretøjsenhed, der indeholder den nye 
K M-VU  , udstedes. Derfor vil en sådan køretøjsenhed altid 
kunne beregne den nye K  M. Desuden vil de fleste nye 
bevægelsessensorer på det tidspunkt også indeholde 
krypterede data baseret på den nye K  M . 
9.2.2  Nøgler til sikring af DSRC-kommunikation  
9.2.2.1  Generelt  
CSM_119 Ægtheden og fortroligheden af data, der sendes fra en k øre­
tøjsenhed til en kontrolmyndighed via en DSRC-fjernkom­
munikationskanal, skal sikres ved hjælp af et sæt køretøjs­
enhedsspecifikke AES-nøgler, der er udledt af en enkelt 
DSRC-hovednøgle, KM  DSRC  . ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 464  
CSM_120 DSRC-hovednøglen KM  DSRC  skal være en AES-nøgle, som 
ERCA'en genererer, gemmer og distribuerer sikkert. Nøglens 
længde kan være 128, 192 eller 256 bit og skal være kædet 
sammen med længden af det europæiske rodnøglepar som 
beskrevet i CSM_50.  
CSM_121 ERCA'en sender DSRC-hovednøglen til medlemsstatens 
certificeringsmyndigheder på en sikker måde efter anmod­
ning fra disse for at give dem mulighed for at udlede køre­
tøjsenhedsspecifikke DSRC-nøgler og for at sikre, at 
DSRC-hovednøglen isættes alle kontrolkort og værksteds­
kort, der udstedes under deres ansvar.  
CSM_122 ERCA'en tildeler hver DSRC-hovednøgle et entydigt 
versionsnummer. ERCA'en underretter MSCA'erne om 
versionsnummeret, når de fremsender DSRC-hovednøglen 
til dem.  
Bemærk:  Versionsnummeret benyttes til at skelne mellem 
forskellige generationer af DSRC-hovednøgler som forklaret 
nærmere i afsnit 9.2.2.2.  
▼M1 
CSM_123 For hver køretøjsenhed skal fabrikanten af køretøjsenhe den 
oprette et entydigt serienummer for køretøjsenheden og 
sende dette nummer til sin medlemsstats certificeringsmyn­
dighed med en anmodning om at få et sæt bestående af to 
køretøjsenhedsspecifikke DSRC-nøgler. Køretøjsenhedens 
serienummer skal have datatypen
  .  
Bemærk:  
— Køretøjsenhedens serienummer skal være identisk med 
vuSerialNumber-elementet af VuIdentification, se tillæg 
1, og henvisningen til certifikatindehaveren i køretøjs­
enhedens certifikater.  
— Køretøjsenhedens serienummer er måske ikke kendt på 
det tidspunkt, hvor en fabrikant af køretøjsenheder 
anmoder om de køretøjsenhedsspecifikke DSRC-nøgler. 
I dette tilfælde skal fabrikanten af køretøjsenheden i 
stedet sende den unikke ID for certifikatanmodningen, 
som fabrikanten anvendte i forbindelse med anmod­
ningen om køretøjsenhedens certifikater; se CSM_153. 
Denne ID for certifikatanmodningen skal derfor svare til 
henvisningen til certifikatindehaveren i køretøjsenhedens 
certifikater.  
▼B 
CSM_124 Efter at have modtaget en anmodning om køretøjsenheds­
specifikke DSRC-nøgler udleder MSCA'en to AES-nøgler til 
køretøjsenheden, som kaldes K_VU  DSRC  _ENC og 
K_VU  DSRC  _MAC. Disse køretøjsenhedsspecifikke nøgler 
skal have samme længde som DSRC-hovednøglen. 
MSCA'en skal benytte den nøgleudledningsfunktion, der 
defineres i [RFC 5869]. Hash-funktionen, der skal benyttes 
til at instantiere HMAC-hash-funktionen, skal være knyttet 
til længden af DSRC-hovednøglen som beskrevet i 
CSM_50. Nøgleudledningsfunktionen i [RFC 5869] skal 
anvendes som følger:  
Trin 1 (Udtræk):  
— PRK  = HMAC-Hash ( salt, IKM ), hvor  salt  er en tom 
streng »«, og  IKM  er KM  DSRC  . ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 465  
Trin 2 (Udvid):  
— OKM  = T(1) , hvor  
T(1) = HMAC-Hash ( PRK , T(0)  | | info  || »01«) med  
— T(0)  = en tom streng (»«)  
— ►M1 info  = køretøjsenhedens serienummer eller 
certifikatanmodningens ID som specificeret i krav 
CSM_123 ◄  
— K_VU  DSRC  _ENC = første  L oktetter af  OKM  o g 
K_VU  DSRC  _MAC = sidste  L oktetter af  OKM , 
hvor L er den krævede længde af K_VU  DSRC  _ENC og 
K_VU  DSRC  _MAC i oktetter.  
CSM_125  MSCA'en distribuerer K_VU  DSRC  _ENC og K_VU  DSRC  _MAC 
til fabrikanten af køretøjsenheden på en sikker måde med 
henblik på indsættelse i den planlagte køretøjsenhed.  
CSM_126 Når en køretøjsenhed udstedes, skal den have 
K_VU  DSRC  _ENC og K_VU  DSRC  _MAC lagret i sin sikre 
hukommelse for at kunne sikre integriteten, ægtheden og 
fortroligheden af de data, der sendes via fjernkommunika­
tionskanalen. En køretøjsenhed skal ligeledes gemme 
versionsnummeret på DSRC-hovednøglen, der benyttes til 
at udlede disse køretøjsenhedsspecifikke nøgler.  
CSM_127 Når kontrolkort og værkstedskort udstedes, skal de have  
KM  DSRC  lagret i deres sikre hukommelse for at kunne veri­
ficere integriteten og ægtheden af data, som sendes af en 
køretøjsenhed via fjernkommunikationskanalen, og dekryp­
tere disse data. Kontrolkort og værkstedskort skal ligeledes 
have versionsnummeret for DSRC-hovednøglen lagret.  
Bemærk:  Som forklaret i afsnit 9.2.2.2 skal flere genera­
tioner af KM  DSRC  muligvis indsættes på et og samme værk­
stedskort eller kontrolkort.  
▼M1 
CSM_128 MSCA'en fører registre over alle køretøjsenhedsspecifik ke 
DSRC-nøgler, som den har genereret, deres versionsnummer 
og serienummer eller certifikatanmodningens ID for den 
køretøjsenhed, der anvendes til at generere dem.  
9.2.2.2  Udskiftning af DSRC-hovednøgle  
CSM_129 Hver DSRC-hovednøgle er knyttet til en bestemt generati on 
af ERCA-rodnøglepar. Derfor skal ERCA'en udskifte 
DSRC-hovednøglen hvert 17. år. Gyldighedsperioden af 
hver DSRC-hovednøglegeneration indledes to år inden, det 
tilhørende ERCA-rodnøglepar bliver gyldigt, og afsluttes, 
når det tilhørende ERCA-rodnøglepar udløber. Dette 
fremgår af Figur 3.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 466  
Figur 3  
Udstedelse og brug af forskellige generationer af DSRC-hovednøglen i køretøjsenheder, værkstedskort og 
kontrolkort
  
CSM_130 Mindst to år før ERCA'en genererer et nyt europæisk 
rodnøglepar som beskrevet i CSM_56, skal den generere 
en ny DSRC-hovednøgle. Længden af DSRC-nøglen 
kædes sammen med den planlagte styrke af det nye euro­
pæiske rodnøglepar i henhold til CSM_50. ERCA'en sender 
den nye DSRC-hovednøgle til MSCA'erne på anmodning fra 
disse sammen med dens versionsnummer.  
CSM_131 En MSCA skal sikre, at alle gyldige generationer af K  DSRC  
gemmes i alle kontrolkort, der udstedes under dens 
myndighed, sammen med deres versionsnumre som vist i 
Figur 3.  
Bemærk:  Dette betyder, at kontrolkortet i det sidste år af et 
ERCA-certifikats gyldighedsperiode vil blive udstedt med 
tre forskellige generationer af K  DSRC  som vist i Figur 3.  
CSM_132 En MSCA skal sikre, at alle generationer af K  DSRC  , der har 
været gyldige i mindst et år, gemmes i alle værkstedskort, 
der udstedes under dens myndighed, sammen med deres 
versionsnumre som vist i Figur 3.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 467  
Bemærk:  Dette betyder, at værkstedskort i det sidste år af et 
ERCA-certifikats gyldighedsperiode vil blive udstedt med 
tre forskellige generationer af K  DSRC  som vist i Figur 2.  
CSM_133 Fabrikanter af køretøjsenheder må kun sætte et sæt køre tøjs­
enhedsspecifikke DSRC-nøgler i hver køretøjsenhed 
sammen med dens versionsnummer. Dette sæt nøgler 
udledes fra den KM  DSRC  -generation, der er knyttet til det 
ERCA-certifikat, som køretøjsenhedens certifikater er 
baseret på.  
Bemærk:  
— Dette indebærer, at en køretøjsenhed baseret på et 
ERCA-certifikat af generation  X kun må indeholde 
K_VU  DSRC  og K_VU  DSRC  _MAC af generation  X, selv 
om køretøjsenheden udstedes efter indledningen af 
gyldighedsperioden for ERCA-certifikatet af generation  
X+1. Dette illustreres i Figur 3.  
— Eftersom værkstedskort har en gyldighedsperiode på et 
år og kontrolkort på to år, er resultatet af CSM_131- 
CSM_133, at værkstedskort og kontrolkort vil indeholde 
den nye DSRC-hovednøgle på det tidspunkt, hvor den 
første køretøjsenhed, der indeholder køretøjsenhedsspe­
cifikke nøgler baseret på den pågældende hovednøgle, 
udstedes.  
9.3. Certifikater  
9.3.1  Generelt  
CSM_134 Alle certifikater i det europæiske intelligent takograf -system 
er selvbeskrivende, kort-verificerbare (CV) certifikater i 
henhold til [ISO 7816-4] og [ISO 7816-8].  
CSM_135  ►M1 Distinguished Encoding Rules (DER) i henhold til 
[ISO 8825-1] skal anvendes til kodning af dataobjekter i 
certifikater. Tabel 4 viser den fuldstændige certifikatkod­
ning, herunder alle etiket- og længdebytes. ◄  
Bemærk:  Denne kodning medfører følgende mærkat-længde- 
værdi- (TLV) struktur:  
Mærkat: Mærkaten kodet i en eller to oktetter med angi­
velse af indholdet.  
Længde: Længden kodet som et ikke-underskrevet heltal i 
en, to eller tre oktetter, hvilket giver en maksimal 
længde på 65 535 oktetter. Det mindste antal 
oktetter skal benyttes.  
Værdi: Værdien kodet i nul eller flere oktetter  
9.3.2  Certifikaters indhold  
CSM_136 Alle certifikater skal følge den struktur, der vises i certifikat­
profilen i Tabel 4.  
Tabel 4  
Certifikatprofil version 1  
Felt Felt-ID  Mærkat  Længde (byte)  ASN.1-datatype 
(se tillæg 1)  
ECC-certifikat  C  »7F 21«  var  
ECC-certifikattekst  B  »7F 4E«  var  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 468  
Felt Felt-ID  Mærkat  Længde (byte)  ASN.1-datatype 
(se tillæg 1)  
Certifikatprofil-identi­
fikator  CPI »5F 29«  »01«
  
Henvisning til certifi­
ceringsmyndighed  CAR  »42«  »08«
  
Certifikatindehavers 
autorisation  CHA  »5F 4C«  »07«
  
Offentlig nøgle  P K  »7F 49«  var  
Domæneparametre  D P  »06«  var
  
Offentligt punkt  P P  »86«  var
  
Henvisning til certifi­
katindehaver  CHR  »5F 20«  »08«
  
Certifikatets gyldig­
hedsdato  CEfD  »5F 25«  »04«
  
Certifikatets udløbs­
dato CExD  »5F 24«  »04«
  
ECC-certifikatunder­
skrift  S »5F 37«  var
  
Bemærk: Felt-ID vil blive brugt i senere afsnit i dette tillæg 
til at angive de individuelle felter i et certifikat, f.eks. er  
X.CAR henvisningen til certifikatmyndigheden, som 
nævnes i certifikatet for brugeren X.  
9.3.2.1 Certifikatprofil-identifikator  
CSM_137 Certifikater skal anvende en certifikatprofil-identifik ator til 
at angive den benyttede certifikatprofil. Version 1, som 
specificeret i Tabel 4, identificeres med en værdi på »00«.  
9.3.2.2 Henvisning til certificeringsmyndighed  
CSM_138 Henvisningen til certificeringsmyndigheden benyttes til  at 
identificere den offentlige nøgle, der skal bruges til at veri­
ficere certifikatets underskrift. Henvisningen til certifice­
ringsmyndigheden skal derfor være lig med henvisningen 
til certifikatindehaveren i certifikatet for den tilhørende 
certifikatmyndighed.  
CSM_139 Et ERCA-rodcertifikat skal være selvunderskrevet, dvs. at 
henvisningen til certificeringsmyndigheden og henvisningen 
til certifikatindehaveren i certifikatet skal være den samme.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 469  
CSM_140 For et ERCA-forbindelsescertifikat skal henvisningen ti l 
certificeringsmyndigheden være lig med CHR for det nye 
ERCA-rodcertifikat. Henvisningen til certificeringsmyndig­
heden for et forbindelsescertifikat skal være lig med CHR 
for det tidligere ERCA-rodcertifikat.  
9.3.2.3 Certifikatindehavers autorisation  
▼M1 
CSM_141 Certifikatindehavers autorisation anvendes til at ident ificere 
typen af certifikat. Den består af de seks mest betydende 
byte i takografens applikations-ID sammenføjet med den 
type udstyr, som angiver den type udstyr, certifikatet er 
beregnet til. I tilfælde af et køretøjsenhedscertifikat, et før er­
kortcertifikat eller et værkstedskortscertifikat anvendes 
udstyrstypen også til at skelne mellem et certifikat for 
gensidig ægthedskontrol og et certifikat til at generere digi­
tale underskrifter (se afsnit 9.1 og tillæg 1, datatypen Equip­
ment Type).  
▼B 
9.3.2.4 Offentlig nøgle  
Den offentlige nøgle indeholder to dataelementer: de standardis erede 
domæneparametre, der skal bruges sammen med den offentlige nøgl e i 
certifikatet, og værdien af det offentlige punkt.  
CSM_142 Dataelementet Domæneparametre skal indeholde en af de 
objektidentifikatorer, der specificeres i Tabel 1, for at 
henvise til et sæt standardiserede domæneparametre.  
CSM_143 Dataelementet Offentligt punkt indeholder det offentlig e 
punkt. Offentlige punkter i form af elliptiske kurver skal 
konverteres til oktetstrenge som specificeret i [TR-03111]. 
Det ukomprimerede kodningsformat skal benyttes. Når man 
genopretter et elliptisk kurvepunkt fra dets kodede format, 
skal de valideringer, der beskrives i [TR-03111], altid 
foretages.  
9.3.2.5 Henvisning til certifikatindehaver  
CSM_144 Henvisningen til certifikatindehaveren er en identifika tor for 
den offentlige nøgle, som certifikatet indeholder. Den skal 
bruges som henvisning til denne offentlige nøgle i andre 
certifikater.  
CSM_145 For kortcertifikater og certifikater for eksternt GNSS- udstyr 
skal henvisningen til certifikatindehaveren have datatypen
  
, som specificeres i tillæg 1.  
CSM_146 For køretøjsenheder kender fabrikanten ved anmodning om  
et certifikat eventuelt det fabrikantspecifikke serienummer på 
køretøjsenheden, som det pågældende certifikat og den tilhø­
rende private nøgle er beregnet til. I førstnævnte tilfælde 
skal henvisningen til certifikatindehaveren have datatypen
  
, der specificeres i tillæg 1. I 
sidstnævnte tilfælde skal henvisningen til certifikatindeha­
veren have datatypen
  , der 
specificeres i tillæg 1.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 470  
Bemærk : For et kortcertifikat skal værdien af CHR svare til 
værdien af cardExtendedSerialNumber i EF_ICC; se tillæg 
2. For et EGF-certifikat skal værdien af CHR svare til 
værdien af sensorGNSSSerialNumber i EF_ICC; se tillæg 
14. For et køretøjsenhedscertifikat skal værdien af CHR 
svare til vuSerialNumber-elementet af VuIdentification, se 
tillæg 1, medmindre fabrikanten ikke kender det fabrikants­
pecifikke serienummer på det tidspunkt, hvor der anmodes 
om certifikatet.  
▼B 
CSM_147 For ERCA- og MSCA-certifikater skal henvisningen 
til certifikatindehaveren have datatypen
  
, der specificeres i 
tillæg 1.  
9.3.2.6 Certifikatets gyldighedsdato  
▼M1 
CSM_148 Certifikatets faktiske gyldighedsdato angiver startdato  og 
-tidspunkt for certifikatets gyldighedsperiode.  
▼B 
9.3.2.7 Certifikatets udløbsdato  
CSM_149 Certifikatets udløbsdato angiver slutdato og -tidspunkt  for 
certifikatets gyldighedsperiode.  
9.3.2.8 Certifikatunderskrift  
CSM_150 Underskriften på certifikatet skal oprettes over den ko dede 
certifikattekst, inklusive certifikattekstens mærkat og 
længde. Underskriftslogaritmen er ECDSA som specificeret 
i [DSS] ved hjælp af hash-algoritmen, der er knyttet til den 
underskrivende myndigheds nøglestørrelse som specificeret i 
CSM_50. Underskriftsformatet skal være klartekst som 
specificeret i [TR-03111].  
9.3.3  Anmodning om certifikater  
CSM_151  ►M1 Når der anmodes om et certifikat, sender MSCA'en 
følgende data til ERCA'en: ◄  
— Certifikatprofilidentifikatoren for det ønskede certifikat  
— Henvisningen til den certificeringsmyndighed, som 
forventes anvendt til at underskrive certifikatet.  
— Den offentlige nøgle, der skal underskrives.  
CSM_152 Ud over dataene i CSM_151 skal en MSCA sende følgende 
data til ERCA'en i anmodningen om et certifikat, således at 
ERCA'en får mulighed for at oprette henvisningen til certi­
fikatindehaveren for det nye MSCA-certifikat:  
— Den numeriske landekode for certificeringsmyndigheden 
(datatype
  defineret i tillæg 1)  
— Den alfanumeriske landekode for certificeringsmyndig­
heden (datatyp
  defineret i tillæg 1)  
— Serienummeret på 1 byte, som bruges til at skelne 
mellem certificeringsmyndighedens forskellige nøgler, 
hvis nøglerne skal skiftes  
— Feltet på 2 byte, der indeholder specifikke supplerende 
oplysninger om certificeringsmyndigheden.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 471  
CSM_153 En udstyrsfabrikant skal sende følgende data til en MSC A i 
anmodningen om et certifikat, således at MSCA'en får 
mulighed for at oprette henvisningen til certifikatindeha­
veren for det nye udstyrscertifikat:  
— Hvis dette kendes (se CSM_154), et serienummer for 
udstyret, som er entydigt for fabrikanten, udstyrstypen 
og produktionsmåneden. Ellers en entydig identifikator 
for certifikatanmodningen  
— Måned og år for produktionen af udstyret eller for 
anmodningen om certifikatet.  
Fabrikanten skal sikre, at disse data er korrekte, og at det ce rtifikat, der 
sendes tilbage af MSCA'en, sættes i det planlagte udstyr.  
▼B 
CSM_154 For køretøjsenheder kender fabrikanten ved anmodning om  
et certifikat eventuelt det fabrikantspecifikke serienummer 
for køretøjsenheden, som det pågældende certifikat og den 
tilhørende private nøgle er beregnet til. Hvis serienummeret 
er kendt, skal fabrikanten af køretøjsenheden sende dette til 
MSCA'en. Hvis det ikke er kendt, skal fabrikanten entydigt 
identificere hver enkelt certifikatanmodning og sende serie­
nummeret på denne certifikatanmodning til MSCA'en. Det 
resulterende certifikat vil herefter indeholde serienummeret 
på certifikatanmodningen. Efter at have isat certifikatet i en 
specifik køretøjsenhed skal fabrikanten give MSCA'en 
meddelelse om forbindelsen mellem serienummeret på certi­
fikatanmodningen og køretøjsenhedens identifikations­
nummer.  
10. GENSIDIG ÆGTHEDSKONTROL OG SIKKER MEDDELELSES­
OVERFØRSEL MELLEM KØRETØJSENHED OG KORT  
10.1.  Generelt  
CSM_155 På et højt niveau er sikker kommunikation mellem en kør e­
tøjsenhed og et takografkort baseret på følgende trin:  
— Først skal hver part demonstrere over for den anden part, 
at den ejer et gyldigt offentligt nøglecertifikat under­
skrevet af en medlemsstats certificeringsmyndighed. 
Herefter skal MSCA'ens offentlige nøglecertifikat under­
skrives af den europæiske certificeringsmyndighed. Dette 
trin kaldes certifikatkædeverificering og specificeres 
nærmere i afsnit 10.2  
— For det andet skal køretøjsenheden over for kortet 
påvise, at den er i besiddelse af den private nøgle, der 
svarer til den offentlige nøgle i det fremlagte certifikat. 
Dette sker ved at underskrive et tilfældigt nummer, som 
fremsendes af kortet. Kortet verificerer underskriften 
over det tilfældige tal. Hvis denne verifikation lykkes, 
er køretøjsenhedens ægthed bekræftet. Dette trin kaldes 
ægthedskontrol af køretøjsenhed og specificeres nærmere 
i afsnit 10.3  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 472  
— For det tredje beregner begge parter uafhængigt af 
hinanden to AES-sessionsnøgler ved hjælp af en asym­
metrisk nøgleoverensstemmelsesalgoritme. Ved hjælp af 
disse sessionsnøgler opretter kortet en kode, der 
bekræfter meddelelsens ægthed (MAC), over nogle 
data, der sendes af køretøjsenheden. Køretøjsenheden 
verificerer MAC'en. Hvis denne verifikation lykkes, er 
kortets ægthed bekræftet. Dette trin kaldes ægthedskon­
trol af kort og specificeres nærmere i afsnit 10.4  
— For det fjerde skal køretøjsenheden og kortet bruge de 
sessionsnøgler, for hvilke der er udført overensstemmel­
seskontrol, for at sikre fortroligheden, integriteten og 
ægtheden af alle udvekslede meddelelser. Dette kaldes 
sikker meddelelsesoverførsel og specificeres nærmere i 
afsnit 10.5.  
CSM_156 Mekanismen, der beskrives i CSM_155, udløses af køretøj s­
enheden, når der sættes et kort i en af kortlæserne.  
10.2.  Gensidig certifikatkædeverificering  
10.2.1  Kortcertifikatkædeverificering foretaget af køretøjsenheden  
CSM_157  ►M1 Køretøjsenheder skal anvende den protokol, der 
beskrives i Figur 4, til at verificere takografkorts certifikat ­
kæde. For hvert certifikat, som den læser fra kortet, skal 
køretøjsenheden kontrollere, at CHA-feltet (Certificate 
Holder Authorisation) er korrekt:  
— Kortcertifikatets CHA-felt skal angive et kortcertifikat til 
brug for gensidig ægthedskontrol (se tillæg 1, datatypen 
Equipment Type).  
— CHA'en på Card.CA-certifikatet skal angive en MSCA.  
— CHA'en på Card.Link-certifikatet skal angive ERCA'en. ◄  
Bemærkninger til Figur 4:  
— Kortcertifikaterne og de offentlige nøgler, der nævnes i 
figuren, er dem, der anvendes til gensidig ægthedskon­
trol. I afsnit 9.1.5 betegnes disse som Card_MA.  
— Card.CA-certifikaterne og de offentlige nøgler, der 
nævnes i figuren, er dem, der anvendes til underskrift 
af kortcertifikater, og det angives i kortcertifikatets CAR. 
I afsnit 9.1.3 betegnes disse som MSCA_Card.  
— Card.CA.EUR-certifikatet, der nævnes i figuren, er det 
europæiske rodcertifikat, der angives i Card.CA-certifi­
katets CAR.  
— Card.Link-certifikatet, der nævnes i figuren, er kortets 
linkcertifikat, hvis dette findes. Som beskrevet i afsnit 
9.1.2 er dette et forbindelsescertifikat til et europæisk 
rodnøglepar, som er oprettet af ERCA'en og under­
skrevet med den tidligere europæiske private nøgle.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 473  
— Card.Link.EUR-certifikatet, der nævnes i figuren, er det 
europæiske rodcertifikat, der angives i Card.Link-certifi­
katets CAR.  
CSM_158 Som afbilledet i Figur 4 skal verifikationen af kortets  
certifikatkæde indledes, når kortet isættes. Køretøjsenheden 
skal læse henvisningen til kortindehaveren 
(
 ) fra elementærfilen 
ICC. Køretøjsenheden kontrollerer, om den kender kortet, 
dvs. om den tidligere har verificeret kortets certifikatkæde 
og gemt den til senere brug. Hvis dette er tilfældet, og 
kortets certifikat stadig er gyldigt, fortsættes processen 
med verifikation af certifikatkæden for køretøjsenheden. 
Ellers skal køretøjsenheden gradvist læse fra kortets 
MSCA_Card-certifikat, som skal benyttes til at verificere 
kortets certifikat, Card.CA.EUR-certifikatet, som skal 
bruges til at verificere MSCA_Card-certifikatet, og eventuelt 
forbindelsescertifikatet, indtil den finder et certifikat, den 
kender eller kan verificere. Hvis den finder et sådant certi­
fikat, skal køretøjsenheden bruge dette certifikat til at veri­
ficere de underliggende kortcertifikater, som den har læst fra 
kortet. Hvis dette lykkes, fortsætter processen med verifika­
tionen af certifikatkæden for køretøjsenheden. Hvis det ikke 
lykkes, ignorerer køretøjsenheden kortet.  
Bemærk:  Der er tre muligheder for, at køretøjsenheden 
kender Card.CA.EUR-certifikatet:  
— Card.CA.EUR-certifikatet er det samme certifikat som 
køretøjsenhedens eget EUR-certifikat  
— Card.CA.EUR-certifikatet er tidligere end køretøjsenhe­
dens eget EUR-certifikat, og køretøjsenheden havde alle­
rede dette certifikat på tidspunktet for udstedelsen (se 
CSM_81)  
— Card.CA.EUR-certifikatet er senere end køretøjsenhe­
dens eget EUR-certifikat, og køretøjsenheden har tidli­
gere modtaget et forbindelsescertifikat fra et andet tako­
grafkort, verificeret det og gemt det til senere brug.  
CSM_159 Som anført i Figur 4 kan køretøjsenheden, så snart den har 
verificeret ægtheden og gyldigheden af et hidtil ukendt certi­
fikat, gemme dette certifikat til senere brug, så det ikke er 
nødvendigt at verificere det pågældende certifikats ægthed, 
hvis køretøjsenheden præsenteres for det igen. I stedet for at 
gemme hele certifikatet kan en køretøjsenhed vælge kun at 
gemme indholdet af certifikatteksten som angivet i afsnit 
9.3.2.  ►M1 Det er fakultativt at opbevare alle andre 
typer certifikater, men det er obligatorisk for en køretøjs­
enhed at opbevare et nyt forbindelsescertifikat, som præsen­
teres af et kort. ◄  
CSM_160 Køretøjsenheden verificerer den tidsmæssige gyldighed 
af alle certifikater, der læses fra kortet eller er gemt i 
hukommelsen, og afviser udløbne certifikater. Køretøjs­
enheden anvender sit interne ur til at verificere den tidsmæs­
sige gyldighed af et certifikat, som sendes af kortet.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 474  
Figur 4  
Protokol til køretøjsenhedens verifikation af kortets certifikatkæde
  
10.2.2  Kortcertifikatkædeverificering foretaget af kortet  
CSM_161  ►M1 Takografkort skal benytte den protokol, der illustreres 
i Figur 5 til verifikation af en køretøjsenheds certifikatkæde.  
For hvert certifikat, som sendes af køretøjsenheden, skal 
kortet kontrollere, at CHA-feltet (Card Holder Authorisation) 
er korrekt:  
— CHA'en på VU.Link-certifikatet skal angive ERCA'en.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 475  
— CHA'en på VU.CA-certifikatet skal angive en MSCA.  
— Køretøjsenhedscertifikatets CHA-felt skal angive et køre­
tøjsenhedscertifikat til brug for gensidig ægthedskontrol 
(se tillæg 1, datatypen Equipment Type). ◄  
Figur 5  
Protokol til kortets verifikation af køretøjsenhedens certifikatkæde
  
Bemærkninger til Figur 5:  
— Køretøjsenhedens certifikater og de offentlige nøgler, der næ vnes i 
figuren, er dem, der anvendes til gensidig ægthedskontrol. I af snit 
9.1.4 betegnes disse som VU_MA.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 476  
— VU.CA-certifikaterne og de offentlige nøgler, der nævnes i fi guren, 
er dem, der anvendes til underskrift af køretøjsenhedscertifika ter og 
certifikater for eksternt GNSS-udstyr. I afsnit 9.1.3 betegnes disse 
som MSCA_VU_EGF.  
— VU.CA.EUR-certifikatet, der nævnes i figuren, er det europæis ke 
rodcertifikat, der angives i VU.CA-certifikatets CAR.  
— VU.Link-certifikatet, der nævnes i figuren, er køretøjsenhede ns 
forbindelsescertifikat, hvis dette findes. Som beskrevet i afsn it 9.1.2 
er dette et forbindelsescertifikat til et europæisk rodnøglepar , som er 
oprettet af ERCA'en og underskrevet med den tidligere europæisk e 
private nøgle.  
— VU.Link.EUR-certifikatet, der nævnes i figuren, er det europæ iske 
rodcertifikat, der angives i VU.Link-certifikatets CAR.  
CSM_162 Som beskrevet i Figur 5 begynder verifikationen af køre ­
tøjsenhedens certifikatkæde med, at køretøjsenheden 
forsøger at anvende sin egen offentlige nøgle i takograf­
kortet. Hvis dette lykkes, betyder det, at kortet tidligere 
har verificeret køretøjsenheden og har gemt køretøjsenheds­
certifikatet til fremtidig brug. I dette tilfælde benyttes køre ­
tøjsenhedscertifikatet, og processen fortsætter med ægtheds­
kontrol af køretøjsenheden. Hvis kortet ikke kender køre­
tøjsenhedens certifikat, skal køretøjsenheden først fremsende 
det VU.CA-certifikat, som skal benyttes til at verificere 
dens køretøjsenhedscertifikat, VU.CA.EUR-certifikatet, 
som skal bruges til at verificere VU.CA-certifikatet og even­
tuelt forbindelsescertifikatet for at finde et certifikat, som 
kortet kender eller kan verificere. Hvis den finder et 
sådant certifikat, skal kortet bruge dette certifikat til at ve ri­
ficere de underliggende køretøjsenhedscertifikater, som det 
præsenteres for. Hvis det lykkes, vælger køretøjsenheden 
endeligt sin offentlige nøgle til brug i takografkortet. Hvis 
det ikke lykkes, ignorerer køretøjsenheden kortet.  
Bemærk: Der er tre muligheder for, at koret kender 
VU.CA.EUR-certifikatet:  
— VU.CA.EUR-certifikatet er det samme certifikat som 
kortets eget EUR-certifikat  
— VU.CA.EUR-certifikatet er tidligere end kortets eget 
EUR-certifikat, og kortet havde allerede dette certifikat 
på tidspunktet for udstedelsen (se CSM_91)  
— VU.CA.EUR-certifikatet er senere end kortets eget 
EUR-certifikat, og kortet har tidligere modtaget et 
forbindelsescertifikat fra en anden køretøjsenhed, verifi­
ceret det og gemt det til senere brug.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 477  
CSM_163 Køretøjsenheden bruger kommandoen MSE: Set AT til at 
angive sin offentlige nøgle til brug i takografkortet. Som 
angivet i tillæg 2 indeholder denne kommando en indikation 
af den kryptografiske mekanisme, der skal bruges sammen 
med den nøgle, der er fastlagt. Denne mekanisme er 
»ægthedskontrol af køretøjsenhed ved brug af 
ECDSA-algoritmen kombineret med hash-algoritmen 
kombineret med nøglestørrelsen af køretøjsenhedens 
VU_MA-nøglepar som specificeret i CSM_50«.  
CSM_164 Kommandoen MSE: Set AT indeholder ligeledes en indika­
tion af det midlertidige nøglepar, som køretøjsenheden skal 
bruge ved overensstemmelseskontrol af sessionsnøglen (se 
afsnit 10.4). Inden køretøjsenheden sender kommandoen 
MSE: Set AT, genererer den således et midlertidigt 
ECC-nøglepar. Ved generering af det midlertidige nøglepar 
bruger køretøjsenheden de standardiserede domænepara­
metre, der er angivet i kortets certifikat. Det midlertidige 
nøglepar betegnes (VU.SK  eph , VU.PK  eph , Card.DP). Køre­
tøjsenheden anvender x-koordinaten i det midlertidige 
offentlige punkt for ECDH som nøgleidentifikation; dette 
kaldes den komprimerede gengivelse af den offentlige 
nøgle og betegnes Comp(VU.PK  eph ). 
▼M1 
CSM_165 Hvis kommandoen MSE: Set AT giver et positivt resultat,  
angiver kortet den angivne VU.PK til efterfølgende brug 
under ægthedskontrol af køretøjet og gemmer 
Comp(VU.PKeph) midlertidigt. Hvis der sendes to eller 
flere vellykkede MSE: Set AT-kommandoer, inden overens­
stemmelseskontrollen af sessionsnøglen gennemføres, 
gemmer kortet kun den seneste modtagne 
Comp(VU.PKeph). Kortet skal nulstille Comp(VU.PKeph) 
efter et positivt resultat af kommandoen GENERAL 
AUTHENTICATE.  
▼B 
CSM_166 Kortet verificerer den tidsmæssige gyldighed af alle ce rtifi­
kater, som køretøjsenheden sender eller henviser til, mens 
de er gemt i kortets hukommelse, og afviser udløbne 
certifikater.  
CSM_167 Med henblik på verificering af den tidsmæssige gyldighe d 
af et certifikat, som fremsendes af køretøjsenheden, gemmer 
hvert takografkort internt nogle data, der repræsenterer det 
aktuelle tidspunkt. Disse data kan ikke ajourføres direkte af 
en køretøjsenhed. Ved udstedelsen sættes det aktuelle tids­
punkt for et kort til at være lig med den aktuelle dato for 
kortets Card_MA-certifikat. Et kort ajourfører sit aktuelle 
tidspunkt, hvis en køretøjsenhed fremsender den faktiske 
dato for et autentisk »gyldig tidsangiver«-certifikat, som er 
nyere end kortets aktuelle tidspunkt. I dette tilfælde 
indstiller kortet sit aktuelle tidspunkt til den faktiske dato 
på det pågældende certifikat. Kortet accepterer kun følgende 
certifikater som gyldig tidsangiver:  
— ERCA-forbindelsescertifikater af anden generation  
— MSCA-certifikater af anden generation  
— køretøjsenhedscertifikater af anden generation, som er 
udstedt af samme land som kortets eget/egne kortcerti­
fikat(er).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 478  
Bemærk:  Det seneste krav indebærer, at et kort skal kunne 
genkende køretøjsenhedscertifikatets CAR, dvs. 
MSCA_VU-EGF-certifikatet. Dette vil ikke være det 
samme som CAR for kortets eget certifikat, som er 
MSCA_Card-certifikatet.  
CSM_168 Som anført i Figur 5 kan kortet, så snart det har verif iceret 
ægtheden og gyldigheden af et hidtil ukendt certifikat, 
gemme dette certifikat til senere brug, så det ikke er 
nødvendigt at verificere det pågældende certifikats ægthed, 
hvis kortet præsenteres for det igen. I stedet for at gemme 
hele certifikatet kan et kort vælge kun at gemme indholdet 
af certifikatteksten som angivet i afsnit 9.3.2.  
10.3.  Ægthedskontrol af køretøjsenhed  
CSM_169 Køretøjsenheder og kort skal benytte den protokol til 
ægthedskontrol af køretøjsenhed, som beskrives i Figur 6, 
til at bekræfte køretøjsenhedens ægthed over for kortet. 
Ægthedskontrollen af køretøjsenheden giver takografkortet 
mulighed for udtrykkeligt at verificere, at køretøjsenheden 
er ægte. For at gøre dette benytter køretøjsenheden sin 
private nøgle til at underskrive en anmodning, som gene­
reres af kortet.  
CSM_170  ►M1 Ud over kortets anmodning skal køretøjsenheden i 
underskriften medtage henvisningen til certifikatindehaveren 
hentet fra kortets certifikat. ◄  
Bemærk:  Dette sikrer, at det kort, som køretøjsenheden 
bekræfter sig over for, er det samme kort, hvis certifikat­
kæde køretøjsenheden tidligere har verificeret.  
CSM_171 I underskriften medtager køretøjsenheden også identifik a­
toren for den midlertidige offentlige nøgle 
Comp(VU.PK  eph ), som køretøjsenheden bruger til sikker 
meddelelsesoverførsel under ægthedskontrol af en chip, 
der beskrives i afsnit 10.4.  
Bemærk:  Dette sikrer, at den køretøjsenhed, som et kort 
kommunikerer med under en sikker meddelelsessession, er 
den samme køretøjsenhed, som kortet har foretaget 
ægthedskontrol af.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 479  
Figur 6  
Protokol til ægthedskontrol af køretøjsenhed
  
▼B 
CSM_172 Hvis køretøjsenheden sender flere GET 
CHALLENGE-kommandoer under ægthedskontrollen af 
køretøjsenheden, returnerer kortet hver gang en ny tilfældig 
anmodning på 8 byte, men gemmer kun den seneste 
anmodning.  
CSM_173 Underskriftsalgoritmen, som køretøjsenheden anvender ti l 
ægthedskontrol af køretøjsenheden, er ECDSA som specifi­
ceret i [DSS] ved hjælp af hash-algoritmen, der er knyttet til 
nøglestørrelsen af køretøjsenhedens VU_MA-nøglepar som 
specificeret i CSM_50. Underskriftsformatet skal være klar­
tekst som specificeret i [TR-03111]. Køretøjsenheden sender 
den resulterende underskrift til kortet.  
▼M1 
CSM_174 Efter modtagelsen af køretøjsenhedens underskrift i en 
EXTERNAL AUTHENTICATE-kommando gør kortet 
følgende:  
— Beregner token for ægthedskontrol ved at sammenføre 
Card.CHR, kortets anmodning rcard og identifikatoren 
for køretøjsenhedens midlertidige offentlige nøgle 
Comp(VU.PKeph)  
— Verificerer køretøjsenhedens underskrift ved at benytte 
ECDSA-algoritmen ved hjælp af hash-algoritmen, der er 
sammenkædet med nøglestørrelsen af køretøjsenhedens 
VU_MA-nøglepar som specificeret i CSM_50, i kombi­
nation med VU.PK og den beregnede token for 
ægthedskontrol.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 480  
10.4.  Ægthedskontrol af chip og overenstemmelseskontrol af sessionsnøgle  
CSM_175 Køretøjsenheder og kort skal benytte den protokol til 
ægthedskontrol af chip, som beskrives i  Figur 7 , til 
bekræfte ægtheden af kortet over for køretøjsenheden. 
Ægthedskontrol af chippen giver køretøjsenheden mulighed 
for udtrykkeligt at verificere, at kortet er ægte.  
Figur 7  
Ægthedskontrol af chip og kontrol af sessionsnøgleoverensstemmelse
  
CSM_176 Køretøjsenheden og kortet gennemfører følgende trin:  
1. Køretøjsenheden indleder ægthedskontrollen af chippen 
ved at sende kommandoen MSE: Set AT med angivelsen 
»Ægthedskontrol af chip med ECDH-algoritmen, der 
giver en AES-sessionsnøgle, som er sammenkædet med 
nøglestørrelsen på kortets Card_MA-nøglepar som speci­
ficeret i CSM_50«. Køretøjsenheden fastlægger stør­
relsen af kortets nøglepar ud fra kortets certifikat.  
▼M1 
2. Køretøjsenheden sender det offentlige punkt VU.PK  eph 
for sit midlertidige nøglepar til kortet. Det offentlige 
punkt konverteres til en oktetstreng som specificeret i 
[TR-03111]. Det ukomprimerede kodningsformat skal 
benyttes. Som forklaret i CSM_164 genererede køretøjs­
enheden dette midlertidige nøglepar inden verifikationen 
af køretøjsenhedens certifikatkæde. Køretøjsenheden 
sendte identifikatoren for den midlertidige offentlige 
nøgle Comp(VU.PK  eph ) til kortet, og kortet gemte den.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 481  
3. Kortet beregner Comp(VU.PK  eph ) ud fra VU.PK  eph og 
sammenligner med den gemte værdi for Comp(VU.PK  eph ). 
4. Ved hjælp af ECDH- algoritmen kombineret med kortets 
statiske private nøgle og køretøjsenhedens midlertidige 
offentlige nøgle, beregner kortet en hemmelig K.  
5. Kortet vælger en tilfældig 8 byte stor engangsstreng 
N PICC og bruger den til at udlede to AES-sessionsnøgler 
K MAC og K  ENC af K. Se CSM_179.  
▼M1 
6. Ved hjælp af K  MAC beregner kortet et token til ægtheds­
kontrol ud fra køretøjsenhedens midlertidige offentlige 
nøgle: T  PICC = CMAC(K  MAC , VU.PK  eph ). Det offentlige 
punkt skal være i det format, der anvendes af køretøjs­
enheden (se underafsnit 2). Kortet sender N  PICC og T  PICC 
til køretøjsenheden.  
▼B 
7. Ved hjælp af ECDH-algoritmen kombineret med kortets 
statiske private nøgle og køretøjsenhedens midlertidige 
private nøgle beregner køretøjsenheden den samme 
hemmelige K, som kortet beregnede i trin 4.  
8. VU'en udleder sessionsnøglerne K  MAC og K  ENC af K og 
N PICC ; se CSM_179.  
9. VU'en verificerer token for ægthedskontrollen T  PICC . 
CSM_177 I trin 3 ovenfor beregner kortet Comp(VU.PKeph) som 
x-koordinaten for det offentlige punkt i VU.PKeph.  
CSM_178 I trin 4 og 7 ovenfor benytter kortet og køretøjsenhede n 
ECKA-EG-algoritmen som defineret i [TR-03111].  
CSM_179 I trin 5 og 8 ovenfor benytter kortet og køretøjsenhede n 
nøgleudledningsfunktionen for AES-sessionsnøgler, som 
defineres i [TR-03111], med følgende præciseringer og 
ændringer:  
— Tællerens værdi er »00 00 00 01« for K  ENC og »00 00 
00 02« for K  MAC.  
— Den valgfrie engangsstreng  r skal anvendes og skal 
være lig med N  PICC. 
— Til udledning af 128-bit AES-nøgler benyttes 
hash-algoritmen SHA-256.  
— Til udledning af 192-bit AES-nøgler benyttes 
hash-algoritmen SHA-384.  
— Til udledning af 256-bit AES-nøgler benyttes 
hash-algoritmen SHA-512.  
Sessionsnøglernes længde (dvs. længden, hvor hash-værdien 
trunkeres) sammenkædes med størrelsen af Card_MA- 
nøgleparret som specificeret i CSM_50.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 482  
CSM_180  I trin 6 og 9 ovenfor benytter kortet og køretøjsenheden 
AES-algoritmen i CMAC-tilstand som specificeret i [SP 800- 
38B]. Længden af T  PICC kædes sammen med længden af 
AES-sessionsnøglerne som specificeret i CSM_50.  
10.5.  Sikker meddelelsesoverførsel  
10.5.1  Generelt  
CSM_181 Alle kommandoer og svar, der udveksles mellem en køre­
tøjsenhed og et takografkort efter vellykket ægthedskontrol 
af chippen og frem til afslutningen af sessionen, skal 
beskyttes ved hjælp af sikker meddelelsesoverførsel.  
CSM_182 Undtagen ved læsning af en fil med adgangsbetingelsen 
SM-R-ENC-MAC-G2 (se tillæg 2, afsnit 4) skal sikker 
meddelelsesoverførsel anvendes i tilstanden »Kun ægtheds­
kontrol«. I denne tilstand tilføjes en kryptografisk 
kontrolsum (også betegnet MAC) til alle kommandoer og 
svar for at sikre meddelelsens ægthed og integritet.  
CSM_183 Ved læsning fra en fil med adgangsbetingelsen SM-R-ENC-  
MAC-G2 skal sikker meddelelsesoverførsel anvendes i 
tilstanden »Krypter-derefter-autentificer«, dvs. svardataene 
krypteres først for at sikre meddelelsens fortrolighed, og 
herefter beregnes der en MAC ud fra de formaterede kryp­
terede data for at garantere ægtheden og integriteten.  
CSM_184 Sikker meddelelsesoverførsel anvender AES som defineret  i 
[AES] sammen med sessionsnøglerne K  MAC og K  ENC , for 
hvilke der blev foretaget overensstemmelseskontrol under 
ægthedskontrol af chippen.  
CSM_185 Et ikke underskrevet heltal skal bruges som sendefrekve ns­
tæller (SSC) for at forhindre replay-angreb. Sendefrekvens­
tællerens størrelse er lig med AES-blokstørrelsen, dvs. 128 
bit. Sendefrekvenstælleren skal være i MSB-first-format. 
Sendefrekvenstælleren initialiseres til nul (dvs »00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00«), når den 
sikre meddelelsesoverførsel indledes. Sendefrekvenstælleren 
forøges trinvist hver gang, inden der genereres en 
kommando- eller et svar-APDU, hvilket vil sige, at eftersom 
startværdien for sendefrekvenstælleren i en SM-session er 0, 
vil værdien af sendefrekvenstælleren i den første kommando 
være 1. Værdien i sendefrekvenstælleren for det første svar 
vil være 2.  
CSM_186 Til kryptering af meddelelser skal K  ENC anvendes sammen 
med AES i blokkædningsfunktionstilstand (CBC) som defi­
neret i [ISO 10116] med en indskudt parameter  m = 1 og en 
initialiseringsvektor SV = E(K  ENC , SSC), dvs. den aktuelle 
værdi af sendesekvenstælleren krypteret med K  ENC . 
CSM_187 Ved ægthedskontrol af meddelelser anvendes K  MAC 
sammen med AES i CMAC-tilstand som specificeret i [SP 
800-38B]. Længden af MAC'en sammenkædes med 
længden af AES-sessionsnøglerne som specificeret i 
CSM_50. Sendesekvenstælleren skal medtages i MAC'en 
ved at indsætte den på forhånd, inden ægtheden af datag­
rammet bekræftes.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 483  
10.5.2  Struktur af sikker meddelelse  
CSM_188 Sikker meddelelsesoverførsel må udelukkende benytte dat a­
objekter til sikker meddelelsesoverførsel (se [ISO 7816-4]), 
som står opført i Tabel 5. I alle meddelelser skal disse 
dataobjekter anvendes i den rækkefølge, der angives i 
denne tabel.  
Tabel 5  
Dataobjekter til sikker meddelelsesoverførsel  
Navn på dataobjekt  Mærkat  Tilstedeværelse (O)bligato­
risk, (B)etinget 
eller (F)orbudt i  
Komman­
doer Svar 
Ordinær værdi ikke kodet i BER-TLV  »81«  B  B  
Ordinær værdi kodet i BER-TLV, men 
ikke inklusive SM-dataobjekter  »B3«  B  B  
Indikator med udfyldningsindhold efter­
fulgt af kryptogram, ordinær værdi ikke 
kodet i BER-TLV  »87«  B  B  
Beskyttet Le  »97«  B  F  
Behandlingsstatus  »99«  F  O  
Kryptografisk kontrolsum  »8E«  O  O  
Bemærk:  Som angivet i tillæg 2 kan takografkort under­
støtte kommandoerne READ BINARY og UPDATE 
BINARY med en ulige INS-byte (»B1« hhv. »D7«). 
Disse kommandovarianter skal bruges til at læse og ajour­
føre filer på 32 768 byte eller mere. Hvis man benytter en 
sådan variant, skal man anvende et dataobjekt med 
mærkatet »B3« i stedet for et objekt med mærkatet »81«. 
Se tillæg 2 for flere oplysninger.  
CSM_189 Alle SM-dataobjekter skal kodes i DER TLV som specifi­
ceret i [ISO 8825-1]. Denne kodning medfører følgende 
mærkat-længde-værdi-struktur (TLV-struktur):  
Mærkat: Mærkaten kodet i en eller to oktetter med angi­
velse af indholdet.  
Længde: Længden kodet som et ikke underskrevet heltal i 
en, to eller tre oktetter, hvilket giver en maksimal 
længde på 65 535 oktetter. Det mindste antal 
oktetter skal benyttes.  
Værdi: Værdien kodet i nul eller flere oktetter  
CSM_190 APDU'er, der er beskyttet med sikker meddelelsesover­
førsel, oprettes som følger:  
— Kommandoheaderen skal medtages i MAC-beregningen, 
og derfor anvendes værdien »0C« til klassebyten CLA.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 484  
— Som specificeret i tillæg 2 skal alle INS-byte være lige, 
med ulige INS-byte til kommandoerne READ BINARY 
og UPDATE BINARY som en mulig undtagelse.  
— Den faktiske værdi af Lc vil blive ændret til Lc' efter 
brugen af sikker meddelelsesoverførsel.  
— Datafeltet består af SM-dataobjekter.  
— I den beskyttede kommando-APDU sættes den nye 
Le-byte til »00«. Om nødvendigt medtages et dataobjekt 
»97« i datafeltet for at formidle den oprindelige værdi af 
Le. 
▼M1 
CSM_191 Alle dataobjekter, der skal krypteres, udfyldes i henho ld til 
[ISO 7816-4] med udfyldningsindikatoren »01«. Ved bereg­
ningen af MAC'en skal dataobjekter i APDU'en udfyldes i 
henhold til [ISO 7816-4].  
Bemærk:  Udfyldning til sikker meddelelsesoverførsel 
udføres altid af det sikre meddelelseslag, ikke af CMAC- 
eller CBC-algoritmerne.  
Sammenfatning og eksempler  
En kommando-APDU med anvendt sikker meddelelsesoverførsel vil h ave 
følgende struktur afhængigt af alternativet for den respektive ikke-sikrede 
kommando (DO står for dataobjekt):  
Alternativ 1: CLA INS P1 P2 Lc' DO »8E« Le  
Alternativ 2: CLA INS P1 P2 Lc' DO »97« DO»8E« 
Le 
Alternativ 3 (lige INS-byte): CLA INS P1 P2 Lc' DO »81« DO»8E« 
Le 
Alternativ 3 (ulige INS-byte): CLA INS P1 P2 Lc' DO »B3« DO»8E«  
Le 
Alternativ 4 (lige INS-byte): CLA INS P1 P2 Lc' DO »81« DO»97« 
DO»8E« Le  
Alternativ 4 (ulige INS-byte): CLA INS P1 P2 Lc' DO »B3« DO»97«  
DO»8E« Le  
Hvor Le = »00« eller »00 00« afhængigt af, hvorvidt der benytte s felter 
med kort længde eller felter med udvidet længde; se [ISO 7816-4 ]. 
En svar-APDU med anvendt sikker meddelelsesoverførsel vil have 
følgende struktur afhængigt af alternativet for det respektive 
ikke-sikrede svar:  
Alternativ 1 eller 3: DO »99« DO »8E« 
SW1SW2  
Alternativ 2 eller 4 (lige INS-byte) 
uden kryptering 
: DO »81« DO »99« DO 
»8E« SW1SW2  
Alternativ 2 eller 4 (lige INS-byte) 
med kryptering 
: DO »87« DO »99« DO 
»8E« SW1SW2  
Alternativ 2 eller 4 (ulige INS-byte) 
uden kryptering: DO »B3« DO »99« DO 
»8E« SW1SW2  
Bemærk:  Alternativ 2 eller 4 (ulige INS-byte) med kryptering anvendes 
aldrig i kommunikationen mellem en køretøjsenhed og et kort.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 485  
Herunder gives tre eksempler på APDU-transformationer for komma n­
doer med lige INS-kode. Figur 8 viser en autentificeret Alterna tiv 4- 
kommando-APDU, Figur 9 viser en autentificeret Alternativ 1-/Al ternativ 
3-svar-APDU, og Figur 10 viser en krypteret og autentificeret A lternativ 
2-/Alternativ 4-svar-APDU.  
Figur 8  
Transformation af en autentificeret Alternativ 4-kommando-APDU
  
Figur 9  
Transformation af en autentificeret Alternativ 1-/Alternativ 3-svar-APDU
  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 486  
Figur 10  
Transformation af et krypteret og autentificeret Alternativ 2-/Alternativ 4-svar-APDU
  
▼B 
10.5.3  Afbrydelse af en sikker meddelelsesoverførselssession  
CSM_192 En køretøjsenhed afbryder en igangværende sikker meddel el­
sesoverførselssession, hvis, og kun hvis et af følgende forhold  
gør sig gældende:  
— Den modtager en APDU med et svar i klartekst.  
— Den konstaterer en fejl i den sikre meddelelsesoverførsel i 
en svar-APDU:  
— Et forventet dataobjekt i en sikker meddelelsesover­
førsel mangler, rækkefølgen af dataobjekter er forkert, 
eller der er medtaget et ukendt dataobjekt.  
— Dataobjektet i en sikker meddelelsesoverførsel er 
forkert, f.eks. er MAC-værdien forkert, TLV-struk­
turen er forkert, eller udfyldingsindikatoren i mærkat 
»87« er ikke lig med »01«.  
— Kortet sender en statusbyte, der viser, at det har konsta­
teret en SM-fejl (se CSM_194).  
— Grænsen for antallet af kommandoer og tilhørende svar 
inden for den aktuelle session er nået. For en bestemt 
køretøjsenhed defineres denne grænse af fabrikanten 
under hensyntagen til sikkerhedskravene for den anvendte 
hardware med et maksimum på 240 SM-kommandoer og 
tilhørende svar pr. session.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 487  
CSM_193 Et takografkort afbryder en igangværende sikker meddele lses­
overførselssession, hvis, og kun hvis et af følgende forhold 
gør sig gældende:  
— Det modtager en APDU-kommando i klartekst.  
— Det konstaterer en fejl i den sikre meddelelsesoverførsel i 
en kommando-APDU:  
— Et forventet dataobjekt i en sikker meddelelsesover­
førsel mangler, rækkefølgen af dataobjekter er forkert, 
eller der er medtaget et ukendt dataobjekt.  
— Et dataobjekt i en sikker meddelelsesoverførsel er 
forkert, f.eks. er MAC-værdien forkert, eller TLV- 
strukturen er forkert.  
— Strømmen afbrydes, eller enheden nulstilles.  
— Køretøjsenheden indleder processen med ægthedskontrol 
af køretøjsenheden.  
— Grænsen for antallet af kommandoer og tilhørende svar 
inden for den aktuelle session er nået. For et bestemt kort 
defineres denne grænse af fabrikanten under hensyntagen 
til sikkerhedskravene for den anvendte hardware med et 
maksimum på 240 SM-kommandoer og tilhørende svar 
pr. session.  
▼B 
CSM_194 Vedrørende SM-fejlhåndtering foretaget af et takografko rt: 
— Hvis der mangler visse dataobjekter til sikker meddelel­
sesoverførsel i en kommando-APDU, rækkefølgen af 
dataobjekter er forkert, eller der er medtaget ukendte data­
objekter, svarer et takografkort med statusbyte »69 87«.  
— Hvis et dataobjekt i en kommando-APDU ved sikker 
meddelelsesoverførsel er forkert, svarer et takografkort 
med statusbyte »69 88«.  
I dette tilfælde returneres de pågældende statusbyte uden brug 
af SM.  
CSM_195 Hvis en sikker meddelelsesoverførselssession mellem en køre­
tøjsenhed og et takografkort afbrydes, ødelægger køretøjs­
enheden og takografen  
— de gemte sessionsnøgler på en sikker måde  
— og opretter øjeblikkelig en ny sikker meddelelsesoverfør­
selssession som beskrevet i afsnit 10.2-10.5.  
CSM_196 Hvis køretøjsenheden af en eller anden grund beslutter at 
genstarte den gensidige ægthedskontrol over for et isat kort, 
genstartes processen med verifikation af kortets certifikatkæde  
som beskrevet i afsnit 10.2 og fortsætter som beskrevet i 
afsnit 10.2-10.5.  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 488  
11. SAMMENKOBLING AF KØRETØJSENHED OG EKSTERNT 
GNSS-UDSTYR, GENSIDIG ÆGTHEDSKONTROL OG SIKKER 
MEDDELELSESOVERFØRSEL  
11.1.  Generelt  
CSM_197 GNSS-udstyret, som en køretøjsenhed bruger til at fasts lå sin 
position, kan være intern (dvs. indbygget i køretøjsenhedens 
hus og kan ikke afmonteres), eller den kan være et eksternt 
modul. I førstnævnte tilfælde er der ikke behov for at stan­
dardisere den interne kommunikation mellem GNSS-udstyret 
og køretøjsenheden, og kravene i dette kapitel finder ikke 
anvendelse. I sidstnævnte tilfælde skal kommunikationen 
mellem køretøjsenheden og det eksterne GNSS-udstyr stan­
dardiseres og beskyttes som beskrevet i dette kapitel.  
CSM_198 Sikker kommunikation mellem en køretøjsenhed og ekstern t 
GNSS-udstyr finder sted på samme måde som sikker kommu­
nikation mellem en køretøjsenhed og et takografkort, hvor det 
eksterne GNSS-udstyr (EGF) overtager kortets rolle. Alle 
krav, der nævnes i kapitel 10 for takografkort, skal opfyldes 
af en EGF under hensyntagen til de afvigelser, præciseringer 
og tilføjelser, der nævnes i dette kapitel. Det gælder navnlig,  
at gensidig verifikation af certifikatkæden, ægthedskontrol af 
køretøjsenhed og chip udføres som beskrevet i afsnit 11.3 og 
11.4.  
CSM_199 Kommunikation mellem en køretøjsenhed og en EGF 
adskiller sig fra kommunikation mellem en køretøjsenhed 
og et kort ved, at en køretøjsenhed og en EGF skal sammen­
kobles en gang på et værksted, inden køretøjsenheden og 
EGF'en kan udveksle GNSS-baserede data under normal 
drift. Sammenkoblingsprocessen beskrives i afsnit 11.2.  
CSM_200 Ved kommunikation mellem en køretøjsenhed og en EGF 
skal APDU-kommandoer og -svar baseret på [ISO 7816-4] 
og [ISO 7816-8] benyttes. Den præcise struktur for disse 
APDU'er defineres i tillæg 2 til dette bilag.  
11.2.  Sammenkobling af køretøjsenhed og eksternt GNSS-udstyr  
CSM_201 En køretøjsenhed og en EGF i et køretøj skal sammenkobl es 
af et værksted. Kun en sammenkoblet køretøjsenhed og EGF 
skal kunne kommunikere ved normal drift.  
CSM_202 Sammenkoblingen af køretøjsenhed og en EGF må kun være 
mulig, når køretøjsenheden er i kalibreringstilstand. 
Koblingen skal indledes af køretøjsenheden.  
CSM_203 Et værksted kan til enhver tid sammenkoble en køretøjse nhed 
med en anden EGF eller med den samme EGF. Under 
gensammenkoblingen skal køretøjsenheden ødelægge det ek­
sisterende EGF_MA-certifikat i sin hukommelse på en sikker 
måde og gemme EGF_MA-certifikatet for den EGF, som den 
skal kobles sammen med.  
CSM_204 Et værksted kan til enhver tid sammenkoble eksternt 
GNSS-udstyr med en anden køretøjsenhed eller med den 
samme køretøjsenhed. Under gensammenkoblingen skal 
EGF'en ødelægge det eksisterende VU_MA-certifikat i sin 
hukommelse på en sikker måde og gemme VU_MA-certifi­
katet for den køretøjsenhed, som den skal kobles sammen 
med. ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 489  
11.3.  Gensidig certifikatkædeverifikation  
11.3.1  Generelt  
CSM_205 Gensidig certifikatkædeverifikation mellem en køretøjse nhed 
og en EGF må kun finde sted under sammenkoblingen af 
køretøjsenheden og EGF'en på et værksted. Under normal 
drift for en sammenkoblet køretøjsenhed og EGF verificeres 
der ingen certifikater. I stedet har køretøjsenheden og EGF'en 
tillid til de certifikater, som de har gemt under sammenkob­
lingen efter at have kontrolleret den midlertidige gyldighed af  
disse certifikater. Køretøjsenheden og EGF'en accepterer ikke 
andre certifikater til beskyttelse af kommunikationen mellem 
køretøjsenheden og EGF'en under normal drift.  
11.3.2  Under sammenkobling af køretøjsenhed og EGF  
CSM_206 Under sammenkoblingen med en EGF benytter en køretøjs­
enhed den protokol, der fremgår af Figur 4 (afsnit 10.2.1), til  
verifikation af det eksterne GNSS-udstyrs certifikatkæde.  
Bemærkninger til Figur 4 i denne sammenhæng:  
— Kommunikationskontrol ligger uden for dette tillægs 
område. En EGF er imidlertid ikke et intelligent kort, 
og derfor vil køretøjsenheden formentlig ikke sende en 
Reset-kommando for at indlede kommunikationen og vil 
ikke modtage en ATR.  
— Kortcertifikaterne og de offentlige nøgler, der nævnes i 
figuren, fortolkes som EGF'ens certifikater og offentlige 
nøgler til gensidig ægthedskontrol. I afsnit 9.1.6 betegnes 
disse som EGF_MA.  
— Card.CA-certifikaterne og de offentlige nøgler, som 
nævnes i figuren, fortolkes som MSCA'ens certifikater 
og offentlige nøgler til underskrift af EGF-certifikater. I 
afsnit 9.1.3 betegnes disse som MSCA_VU_EGF.  
— Card.CA.EUR-certifikatet, der nævnes i figuren, skal 
fortolkes som det europæiske rodcertifikat, der angives i 
MSCA_VU-EFT-certifikatets CAR.  
— Card.Link-certifikatet, der nævnes i figuren, skal fortolkes 
som EGF'ens forbindelsescertifikat, hvis dette findes. Som 
beskrevet i afsnit 9.1.2 er dette et forbindelsescertifikat til  
et europæisk rodnøglepar, som er oprettet af ERCA'en og 
underskrevet af den tidligere europæiske private nøgle.  
— Card.Link.EUR-certifikatet, der nævnes i figuren, er det 
europæiske rodcertifikat, der angives i Card.Link-certifi­
katets CAR.  
— I stedet for
  , læser køre­
tøjsenheden
  fra elementær­
filen ICC.  
— I stedet for at vælge takograf-AID'en vælger køretøjs­
enheden EGF-AID'en.  
— »Ignore Card« fortolkes som »Ignore EGF«.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 490  
CSM_207 Når køretøjsenheden har verificeret EGF_MA-certifikatet , 
gemmer den dette certifikat til brug under normal drift; se 
afsnit 11.3.3.  
CSM_208  ►M1 Under sammenkoblingen med en køretøjsenhed 
benytter eksternt GNSS-udstyr den protokol, der beskrives i 
Figur 5 (afsnit 10.2.2) til verifikation af køretøjsenhedens 
certifikatkæde. ◄  
Bemærkninger til Figur 5 i denne sammenhæng:  
— Køretøjsenheden genererer en nyt midlertidigt nøglepar 
ved hjælp af domæneparametrene i EGF-certifikatet.  
— Køretøjsenhedens certifikater og de offentlige nøgler, der 
nævnes i figuren, er dem, der anvendes til gensidig 
ægthedskontrol. I afsnit 9.1.4 betegnes disse som 
VU_MA.  
— VU.CA-certifikaterne og de offentlige nøgler, der nævnes i 
figuren, er dem, der anvendes til underskrift af køretøjs­
enhedscertifikater og certifikater for eksternt GNSS-udstyr. 
I afsnit 9.1.3 betegnes disse som MSCA_VU_EGF.  
— VU.CA.EUR-certifikatet, der nævnes i figuren, er det 
europæiske rodcertifikat, der angives i VU.CA-certifika­
tets CAR.  
— VU.Link-certifikatet, der nævnes i figuren, er køretøjs­
enhedens linkcertifikat, hvis dette findes. Som beskrevet 
i afsnit 9.1.2 er dette et forbindelsescertifikat til et euro­
pæisk rodnøglepar, som er oprettet af ERCA'en og under­
skrevet af den tidligere europæiske private nøgle.  
— VU.Link.EUR-certifikatet, der nævnes i figuren, er det 
europæiske rodcertifikat, der angives i VU.Link-certifika­
tets CAR.  
CSM_209 Som en afvigelse fra krav CSM_167 skal en EGF anvende 
GNSS'ens klokkeslæt til at verificere den tidsmæssige 
gyldighed af ethvert fremlagt certifikat.  
▼M1 
CSM_210 Når det eksterne GNSS-udstyr har verificeret VU_MA-cert i­
fikatet, gemmer den dette certifikat til brug under normal 
drift; se afsnit 11.3.3.  
▼B 
11.3.3  Under normal drift  
CSM_211  ►M1 Under normal drift benytter en køretøjsenhed og en 
EGF den protokol, der beskrives i Figur 11 til verifikation af 
den tidsmæssige gyldighed af det gemte EGF_MA-certifikat 
og til at indstille den offentlige VU_MA-nøgle til efterføl­
gende ægthedskontrol af køretøjsenheden. Der foretages 
ingen yderligere gensidig verificering af certifikatkæderne 
under normal drift. ◄  
Bemærk, at Figur 11 i alt væsentligt består af de første trin, 
der beskrives i Figur 4 og Figur 5. Igen skal man bemærke, at 
eftersom en EGF ikke er et intelligent kort, vil køretøjs­
enheden formentlig ikke sende en Reset-kommando for at 
indlede kommunikationen og vil ikke modtage en ATR. 
Under alle omstændigheder ligger dette uden for dette 
tillægs område.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 491  
Figur 11  
Gensidig verificering af et certifikats tidsmæssige gyldighed ved normal drift af køretøjsenhed og EGF
  
CSM_212 Som vist i Figur 11 logger køretøjsenheden en fejl, hvi s 
EGF_MA-certifikatet ikke længere er gyldigt. Den gensidige 
ægthedskontrol, nøgleoverensstemmelse og den efterfølgende 
kommunikation via sikker meddelelsesoverførsel foregår som 
normalt.  
11.4.  Ægthedskontrol af køretøjsenhed og chip samt sessionsnøgleoverens ­
stemmelse  
CSM_213 Ægthedskontrol af køretøjsenhed og chip og kontrol af 
sessionsnøgleoverensstemmelse mellem en køretøjsenhed og 
en EGF foregår under sammenkobling, og når en sikker 
meddelelsesoverførselssession genetableres under normal 
drift. Køretøjsenheden og EGF'en udfører de processer, der 
beskrives i afsnit 10.3 og 10.4. Alle krav i disse afsnit finde r 
anvendelse.  
11.5.  Sikker meddelelsesoverførsel  
CSM_214 Alle kommandoer og svar, der udveksles mellem en køretø js­
enhed og eksternt GNSS-udstyr efter vellykket ægthedskon­
trol af chippen og frem til afslutningen af sessionen, skal 
beskyttes ved hjælp af sikker meddelelsesoverførsel i 
tilstanden »Kun ægthedskontrol«. Alle krav i afsnit 10.5 
finder anvendelse.  
CSM_215 Hvis en sikker meddelelsesoverførselssession mellem en køre­
tøjsenhed og en EGF afbrydes, etablerer køretøjsenheden 
øjeblikkelig en ny sikker meddelelsesoverførselssession som 
beskrevet i afsnit 11.3.3 og 11.4.  
12. PARRING AF OG KOMMUNIKATION MELLEM KØRETØJS­
ENHED OG BEVÆGELSESSENSOR  
12.1.  Generelt  
CSM_216 En køretøjsenhed og en bevægelsessensor kommunikerer ve d 
hjælp af den interfaceprotokol, der specificeres i [ISO 16844- 
3], under parring og ved normal drift med de ændringer, der 
beskrives i dette kapitel og i afsnit 9.2.1.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 492  
Bemærk: Læsere af dette kapitel formodes at være fortrolige 
med indholdet af [ISO 16844-3].  
12.2.  Parring af køretøjsenhed og bevægelsessensor ved hjælp af forskel ­
lige nøglegenerationer  
Som forklaret i afsnit 9.2.1 udskiftes bevægelsessensorens hove dnøgle og 
alle tilhørende nøgler regelmæssigt. Dette betyder, at op til t re bevægel­
sessensor-relaterede AES-nøgler K  M-WC  (af på hinanden følgende nøgle­
generationer) er til stede på værkstedskortene. Tilsvarende kan  op til tre 
forskellige AES-baserede datakrypteringer (baseret på hinanden følgende 
generationer af bevægelsessensorens hovednøgle K  M ) være til stede i 
bevægelsessensorer. En køretøjsenhed indeholder kun en bevægels es­
sensor-relateret nøgle K  M-VU.  
CSM_217 En køretøjsenhed af anden generation og en bevægelsesse nsor 
af anden generation parres på følgende måde (sammenlign 
med tabel 6 i [ISO 16844-3]):  
1. Et værkstedskort af anden generation sættes i køretøjs­
enheden, og køretøjsenheden tilsluttes bevægelsessensoren.  
2. Køretøjsenheden læser alle tilgængelige K  M-WC  -nøgler fra 
værkstedskortet, undersøger deres nøgleversionsnumre og 
vælger den, der passer til versionsnummeret for køretøjs­
enhedens K  M-VU  -nøgle. Hvis der ikke er nogen passende 
K M-WC  -nøgle til stede på værkstedskortet, afbryder køre­
tøjsenheden parringsprocessen og viser en relevant fejl­
meddelelse til indehaveren af værkstedskortet.  
3. Køretøjsenheden beregner bevægelsessensorens hoved­
nøgle K  M ud fra K  M-VU  og K  M-WC  og identifikations­
nøglen K  ID ud fra K  M som specificeret i afsnit 9.2.1.  
4. Køretøjsenheden sender instruktionen om at indlede 
parringsprocessen til bevægelsessensoren, som beskrevet 
i [ISO 16844-3], og krypterer det serienummer, den 
modtager fra bevægelsessensoren med identifikations­
nøglen K  ID. Køretøjsenheden sender det krypterede serie­
nummer tilbage til bevægelsessensoren.  
5. Bevægelsessensoren sammenligner det krypterede serie­
nummer med hver af krypteringerne af serienummeret, 
som den har lagret internt. Hvis den finder et, der 
passer, bekræftes køretøjsenhedens ægthed. Bevægelses­
sensoren noterer den generation af K  ID , som køretøjs­
enheden anvender, og returnerer den passende krypterede 
version af sin parringsnøgle, dvs. den kryptering, der blev 
oprettet med den samme generation af K  M . 
6. Køretøjsenheden dekrypterer parringsnøglen med K  M , 
genererer en sessionsnøgle K  S, krypterer den med parrings­
nøglen og sender resultatet til bevægelsessensoren. Bevæ­
gelsessensoren dekrypterer K  S . 
7. Køretøjsenheden samler parringsoplysningerne som defi­
neret i [ISO 16844-3], krypterer oplysningerne med 
parringsnøglen og sender resultatet til bevægelsessensoren. 
Bevægelsessensoren dekrypterer parringsoplysningerne.  
8. Bevægelsessensoren krypterer de modtagne parringsoplys­
ninger med den modtagne K  S og returnerer dem til køre­
tøjsenheden. Køretøjsenheden verificerer, at parringsoplys­
ningerne er det samme oplysninger, som køretøjsenheden 
sendte til bevægelsessensoren i det foregående trin. Hvis  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 493  
dette er tilfældet, beviser det, at bevægelsessensoren brugte 
den samme K  S som køretøjsenheden og dermed i trin 5 
sendte sin parringsnøgle krypteret med den korrekte gene­
ration af K  M . Dermed er bevægelsessensorens ægthed 
bekræftet.  
Bemærk, at trin 2 og 5 er forskellige fra standardprocessen i 
[ISO 16844-3], mens de øvrige trin er standard.  
Eksempel:  Det forudsættes, at en parring finder sted i ERCA- 
(3) certifikatets første gyldighedsår; se Figur 2 i afsnit 9.2. 1.2. 
Det 
— forudsættes desuden, at bevægelsessensoren blev udstedt i 
ERCA- (1) certifikatets sidste gyldighedsår. Den inde­
holder derfor følgende nøgler og data:  
— N  s [1]: dens serienummer krypteret med generation 1 
af K  ID 
— N  s [2]: dens serienummer krypteret med generation 2 
af K  ID 
— N  s [3]: dens serienummer krypteret med generation 3 
af K  ID 
— K  P [1]: dens generation 1-parringsnøgle (  1 ) krypteret 
med generation 1 af K  M 
— K  P [2]: dens generation 2-parringsnøgle krypteret med 
generation 2 af K  M 
— K  P [3]: dens generation 3-parringsnøgle krypteret med 
generation 3 af K  M . 
— Det forudsættes, at værkstedskortet blev udstedt i ERCA- 
(3) certifikatets første gyldighedsår. Det vil derfor inde­
holde generation 2 og generation 3 af K  M-WC  -nøglen.  
— Det forudsættes, at køretøjsenheden er en generation 2- 
køretøjsenhed, der indeholder generation 2 af K  M-VU.  
I dette tilfælde vil følgende ske i trin 2-5:  
— Trin 2: Køretøjsenheden læser generation 2 og generation 
3 af K  M-WC  fra værkstedskortet og undersøger deres 
versionsnumre.  
— Trin 3: Køretøjsenheden kombinerer generation 2-K  M-WC  
med dens K  M-VU  for at beregne K  M og K ID. 
— Trin 4: Køretøjsenheden krypterer det serienummer, den 
modtager fra bevægelsessensoren med K  ID. 
— Trin 5: Bevægelsessensoren sammenligner de modtagne 
data med N  s [1] og finder ikke nogen, der passer. Herefter 
sammenligner den dataene med N  s [2] og finder en værdi, 
der passer. Den konkluderer, at køretøjsenheden er en 
generation 2-køretøjsenhed og returnerer derfor K  P [2]. ▼B 
( 1 ) Bemærk, at parringsnøgler af generation 1, generation 2 og ge neration 3 rent faktisk kan 
være den samme nøgle eller kan være tre forskellige nøgler med forskellig længde som 
forklaret i CSM_117.
 02016R0799 — DA — 21.08.2023 — 003.001 — 494  
12.3.  Parring af og kommunikation mellem køretøjsenhed og bevægelses ­
sensor ved hjælp af AES  
CSM_218 Som anført i Tabel 3 i afsnit 9.2.1 skal alle nøgler, d er 
anvendes til parring af en (andengenerations) køretøjsenhed 
og en bevægelsessensor og i den efterfølgende kommunika­
tion være AES-nøgler frem for TDES-nøgler med dobbelt 
længde som specificeret i [ISO 16844-3]. Disse AES-nøgler 
kan have en længde på 128, 192 eller 256 bit. Eftersom blok­
størrelsen i en AES er 16 byte, skal længden af en krypteret 
meddelelse være et multiplum af 16 byte sammenlignet med 8 
byte for TDES. Desuden vil nogle af disse meddelelser blive 
brugt til at transportere AES-nøgler, hvis længde kan være 
128, 192 eller 256 bit. Derfor skal antallet af databyte pr. 
instruktion i tabel 5 i [ISO 16844-3] ændres som vist i 
Tabel 6:  
▼M1 
Tabel 6  
Antal databyte i klartekst og krypteret form pr. instruktion defineret i [ISO 16844-3]  
Instruktion  Anmodning/ 
svar Beskrivelse af data  Antal databyte i 
klartekst i henhold til 
[ISO 16844-3]  Antal databyte i 
klartekst ved brug af 
AES-nøgler  Antal krypterede databyte ved 
brug af AES-nøgler med en 
bitlængde på  
128 192  256  
10 anmodning  Ægthedskontroldata + 
filnummer  8 8  1 6  1 6  1 6  
11 svar  Ægthedskontroldata + 
filindhold  16 eller 32, 
afhænger af filen  16 eller 32, 
afhænger af filen  32 / 48  32 / 48  32 / 48  
41 anmodning  MoS-serienummer  8  8  1 6  1 6  1 6  
41 svar  Parringsnøgle  1 6  16 / 24 / 32  1 6  3 2  3 2  
42 anmodning  Sessionsnøgle  1 6  16 / 24 / 32  1 6  3 2  3 2  
43 anmodning  Parringsoplysninger  2 4  2 4  3 2  3 2  3 2  
50 svar  Parringsoplysninger  2 4  2 4  3 2  3 2  3 2  
70 anmodning  Ægthedskontroldata  8  8  1 6  1 6  1 6  
80 svar  MoS-tællerværdi + 
ægthedskontroldata  8 8  1 6  1 6  1 6  
▼B 
CSM_219 De parringsoplysninger, der fremsendes i instruktion 43  (VU- 
anmodning) og 50 (MoS-svar), samles som specificeret i 
afsnit 7.6.10 i [ISO 16844-3], bortset fra at AES-algoritmen 
skal benyttes i stedet for TDES-algoritmen i krypteringsord­
ningen til parringsdataene, hvilket betyder to AES-krypte­
ringer, og idet man anvender den udfyldning, der specificeres 
i CSM_220, så den passer med AES-blokstørrelsen. Nøglen 
K' p , der benyttes til denne kryptering, genereres på følgende 
måde:  
— Hvis parringsnøglen K  P er 16 byte lang: K'  p = K  P XOR 
(N s ||N s ) ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 495  
— Hvis parringsnøglen K  P er 24 byte lang: K'  p = K  P XOR 
(N s ||N s ||N s ) 
— Hvis parringsnøglen K  P er 32 byte lang: K'  p = K  P XOR 
(N s ||N s ||N s ||N s ) 
hvor N  s er bevægelsessensorens serienummer på 8 byte.  
CSM_220 Hvis datalængden af klarteksten (ved brug af AES-nøgler ) 
ikke er et multiplum af 16 byte, skal udfyldningsmetode 2, 
som defineres i [ISO 9797-1], benyttes.  
Bemærk:  I [ISO 16844-3] er antallet af klartekstdatabyte altid 
et multiplum af 8, og der er således ikke behov for udfyld­
ning, når man bruger TDES. Definitionen af data og medde­
lelser i [ISO 16844-3] ændres ikke af denne del i dette tillæg,  
så der bliver behov for at bruge udfyldning.  
CSM_221 Til instruktion 11, og hvis mere end en datablok skal k ryp­
teres, skal blokkædningsmetoden benyttes som defineret i 
[ISO 10116] med en indskudt parameter  m = 1. Den anvendte 
IV skal være  
— Til instruktion 11: ægthedskontrolblokken på 8 byte, som 
specificeres i afsnit 7.6.3.3 i [ISO 16844-3], udfyldt ved 
hjælp af udfyldningsmetode 2, som defineres i [ISO 9797- 
1]; se også afsnit 7.6.5 og 7.6.6 i [ISO 16844-3].  
— Til alle andre instruktioner, hvor der overføres mere end 
16 byte, som specificeret i Tabel 6: »00« {16}, dvs. 16 
byte med den binære værdi 0.  
Bemærk:  Som vist i afsnit 7.6.5 og 7.6.6 i [ISO 16844-3] 
gælder det, at når MoS'en krypterer datafiler med henblik 
på medtagelse i instruktion 11, skal ægthedskontrolblokken 
både  
— bruges som initialiseringsvektor for kryptering af dataf­
ilerne i CBC-tilstand  
— krypteres og medtages som den første blok i dataene, der 
sendes til køretøjsenheden.  
12.4.  Parring af køretøjsenhed og bevægelsessensor til forskellige udstyrs ­
generationer  
CSM_222 Som forklaret i afsnit 9.2.1 kan en bevægelsessensor af  anden 
generation indeholde TDES-baseret kryptering af parrings­
dataene (som defineret i del A i dette tillæg), hvilket betyder , 
at bevægelsessensoren kan parres med en køretøjsenhed af 
første generation. Hvis det forholder sig således, skal en køre ­
tøjsenhed af første generation og en bevægelsessensor af 
anden generation parres som beskrevet i del A i dette tillæg 
og i [ISO 16844-3]. Ved parringsprocessen kan man enten 
benytte et værkstedskort af første eller anden generation.  
Bemærk:  
— Det er ikke muligt at parre en køretøjsenhed af anden 
generation og en bevægelsessensor af første generation.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 496  
— Det er ikke muligt at anvende et værkstedskort af første 
generation til at sammenkoble en bevægelsessensor af 
anden generation med en bevægelsessensor.  
13. SIKKERHED VED FJERNKOMMUNIKATION OVER DSRC  
13.1.  Generelt  
Som det anføres i tillæg 14, genererer en bevægelsessensor rege lmæssigt 
data til fjernovervågning af takograf (Remote Tachograph Monito ring — 
RTM) og sender dem til det interne eller eksterne fjernkommunik ations­
udstyr (Remote Communication Facility — RCF). Fjernkommunikatio ns­
udstyret har ansvaret for at sende disse data via DSRC-interfac et, som 
beskrives i tillæg 14, til fjerninterrogatoren. I tillæg 1 angi ves det, at 
RTM-dataene er en sammenføring af:  
Krypteret takografindhold  krypteringen af takografindholdet i klartekst  
DSRC-sikkerhedsdata  beskrives nedenfor  
Formatet for takografindholdet i klartekst specificeres i tillæ g 1 og 
beskrives nærmere i tillæg 14. I dette afsnit beskrives struktu ren af 
DSRC-sikkerhedsdataene; den formelle specifikation findes i til læg 1.  
CSM_223
  -dataene i klartekst, som en bevæ­
gelsessensor sender til fjernkommunikationsudstyr (hvis 
RCF'et er eksternt i forhold til køretøjsenheden) eller fra kør e­
tøjsenheden til fjerninterrogatoren via DSRC-interfacet (hvis 
RCF'et er indbygget i køretøjsenheden), skal beskyttes i 
»Krypter-derefter-autentificer«-tilstand, dvs. at takografind­
holdet krypteres først for at sikre meddelelsens fortrolighed, 
og derefter beregnes der en MAC for at sikre dataenes ægthed 
og integritet.  
CSM_224 DSRC-sikkerhedsdataene består af sammenlægningen af 
følgende dataelementer i følgende rækkefølge; se også 
Figur 12:  
Aktuel dato og klokkeslæt  køretøjsenhedens aktuelle dato og klokkeslæt (datatype
  
) 
Tæller  en tæller på 3 byte, se CSM_225  
▼M1 
Køretøjsenhedens serienummer  køretøjsenhedens serienummer eller certifikatanmodnin­
gens ID (datatype VuSerialNumber eller CertificateReq­
uestID) – se krav CSM_123  
▼B 
Versionsnummer for DSRC-hovednøgle  versionsnummeret for DSRC-hovednøglen på 1 bit, ud 
fra hvilken de køretøjsenhedsspecifikke DSRC-nøgler 
er afledt, se afsnit 9.2.2.  
MAC  MAC'en beregnet ud fra alle de tidligere byte i 
RTM-dataene.  
CSM_225 Tælleren på 3 byte i DSRC-sikkerhedsdataene skal være i  
MSB-first-format. Første gang en bevægelsessensor beregner 
et sæt RTM-data, efter at den er sat i produktion, sætter den 
tællerens værdi til 0. Køretøjsenheden øger værdien af tæller­
dataene med 1, hver gang den beregner det næste sæt 
RTM-data.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 497  
13.2.  Kryptering af takografindhold og MAC-generering  
CSM_226  Med et dataelement i klartekst med datatypen
  
som beskrevet i tillæg 14 skal en 
bevægelsessensor kryptere disse data som vist i Figur 12: køre­
tøjsenhedens DSRC-nøgle til kryptering af K_VU  DSRC  _ENC 
(se afsnit 9.2.2) skal anvendes med AES med blokkædnings­
metoden (CBC) som defineret i [ISO 10116] med en indskudt 
parameter  m = 1. Initialiseringsvektoren er lig med  IV = aktuel 
dato og klokkeslæt  || »00 00 00 00 00 00 00 00 00 « || tæller , 
hvor aktuel dato og klokkeslæt  o g tæller  specificeres i 
CSM_224. De data, der skal krypteres, udfyldes ved hjælp af 
metode 2, som defineres i [ISO 9797-1].  
CSM_227 En køretøjsenhed beregner MAC'en i DSRC-sikkerheds­
dataene som vist i Figur 12: MAC'en beregnes ud fra alle 
de foregående byte i RTM-dataene til og med versionsnum­
meret for DSRC-hovednøglen og inklusive dataobjekternes 
mærkater og længder. Køretøjsenheden bruger sin 
DSRC-nøgle til ægthed K_VU  DSRC  _MAC (se afsnit 9.2.2) 
med AES-algoritmen i CMAC-tilstand som specificeret i 
[SP 800-38B]. Længden af MAC'en sammenkædes med 
længden af de køretøjsenhedsspecifikke DSRC-nøgler som 
specificeret i CSM_50.  
Figur 12  
Kryptering af takografens dataindhold og MAC-generering
  
13.3.  Verifikation og dekryptering af takografindhold  
CSM_228 Når en fjerninterrogator modtager RTM-data fra en bevæg el­
sessensor, sender den alle RTM-dataene til et kontrolkort i 
datafeltet for en PROCESS DSRC MESSAGE-kommando 
som beskrevet i tillæg 2. Herefter:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 498  
1. undersøger kontrolkortet versionsnummeret på DSRC- 
hovednøglen i DSRC-sikkerhedsdataene. Hvis kontrol­
kortet ikke kender den angivne DSRC-hovednøgle, retur­
nerer den en fejl som specificeret i tillæg 2 og afbryder 
processen.  
▼M1 
2. Kontrolkortet bruger den angivne DSRC-hovednøgle i 
kombination med køretøjsenhedens serienummer eller 
certifikatanmodningens ID i DSRC-sikkerhedsdataene til 
at udlede de køretøjsenhedsspecifikke DSRC-nøgler 
K_VU  DSRC  _ENC og K_VU  DSRC  _MAC som specificeret 
i krav CSM_124.  
▼B 
3. Kontrolkortet bruger K_VU  DSRC  _MAC til at verificere 
MAC'en i DSRC-sikkerhedsdataene som specificeret i 
CSM_227. Hvis MAC'en er forkert, returnerer kontrol­
kortet en fejl som specificeret i tillæg 2 og afbryder 
processen.  
4. Kontrolkortet bruger K_VU  DSRC  _ENC til at dekryptere det 
krypterede takografindhold som specificeret i CSM_226. 
Kontrolkortet fjerner udfyldningen og returnerer de 
dekrypterede data for takografindholdet til fjerninterroga­
toren.  
CSM_229 For at undgå replay-angreb verificerer fjerninterrogato ren, at 
der er tale om nye RTM-data, ved at verificere, at  aktuel dato 
og klokkeslæt  i DSRC-sikkerhedsdataene ikke afviger for 
meget fra det aktuelle klokkeslæt i fjerninterrogatoren.  
Bemærk:  
— Dette kræver, at fjerninterrogatoren har en nøjagtig og 
pålidelig kilde til klokkeslæt.  
— Eftersom det i tillæg 14 kræves, at en bevægelsessensor 
skal beregne et nyt sæt RTM-data hver 60. sekund, og uret 
i køretøjsenheden må afvige med 1 minut fra det reelle 
tidspunkt, er den nedre grænse for RTM-dataene på 2 
minutter. Den faktiske opdateringsfrekvens, der kræves, 
afhænger også af nøjagtigheden af fjerninterrogatorens ur.  
CSM_230 Når et værksted verificerer, at DSRC-funktionen i en be væ­
gelsessensor fungerer korrekt, sender den alle de RTM-data, 
som den har modtaget fra køretøjsenheden, til et værksteds­
kort i datafeltet for en PROCESS DSRC MESSAGE- 
kommando som beskrevet i tillæg 2. Værkstedskortet 
udfører alle kontroller og handlinger, som specificeres i 
CSM_228.  
14. UNDERSKRIVELSE AF DATAOVERFØRSLER OG VERIFICERING 
AF UNDERSKRIFTER  
14.1.  Generelt  
CSM_231 Det intelligente dedikerede udstyr (IDE) lagrer data, s om er 
modtaget fra en bevægelsessensor eller et kort, i løbet af en 
overførselssession, i en fysisk datafil. Data kan lagres på et 
eksternt lagermedie. Denne fil indeholder digitale under­
skrifter over datablokke som specificeret i tillæg 7. Filen 
indeholder ligeledes følgende certifikater (se afsnit 9.1):  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 499  
— Ved overførsel fra en køretøjsenhed:  
— VU_Sign-certifikatet  
— MSCA_VU-EGF-certifikatet, der indeholder den 
offentlige nøgle, som skal benyttes til verifikation af 
VU_Sign-certifikatet  
— Ved overførsel fra et kort:  
— Card_Sign-certifikatet  
— MSCA_Card-certifikatet, der indeholder den offentlige 
nøgle, der skal benyttes til verifikation af Card_Sign- 
certifikatet  
CSM_232 IDE-udstyret skal også have adgang til følgende:  
— Hvis det anvender et kontrolkort til at verificere under­
skriften som vist i Figur 13: forbindelsescertifikatet, der 
knytter det seneste EUR-certifikat sammen med EUR- 
certifikatet, hvis gyldighedsperiode ligger umiddelbart 
forud for det, hvis dette findes.  
— Hvis det selv verificerer underskriften: alle gyldige euro­
pæiske rodcertifikater.  
Bemærk:  Den metode, som IDE-udstyret bruger til at hente 
disse certifikater, specificeres ikke i dette tillæg.  
14.2.  Generering af underskrifter  
CSM_233 Underskriftsalgoritmen, som anvendes til at oprette dig itale 
underskrifter ud fra overførte data, er ECDSA som specifi­
ceret i [DSS] ved hjælp af hash-algoritmen, der er knyttet til 
køretøjsenhedens eller kortets nøglestørrelse som specificeret i 
CSM_50. Underskriftsformatet skal være klartekst som speci­
ficeret i [TR-03111].  
14.3.  Verifikation af underskrift  
CSM_234  ►M1 En IDE kan foretage verifikation af en underskrift ud 
fra selve de overførte data eller kan benytte et kontrolkort ti l 
dette. Hvis det anvender et kontrolkort, skal verifikationen 
foregå som vist i Figur 13. Kontrolkortet anvender sit 
interne ur til at verificere den tidsmæssige gyldighed af et 
certifikat, som sendes af IDE-udstyret, som specificeret i 
krav CSM_167. Kontrolkortet ajourfører sit aktuelle tids­
punkt, hvis den faktiske dato for et autentisk »gyldig tids­
angiver«-certifikat er nyere end kortets aktuelle tidspunkt. 
Kortet accepterer kun følgende certifikater som gyldig 
tidsangiver:  
— ERCA-forbindelsescertifikater af anden generation  
— MSCA-certifikater af anden generation  
— VU_Sign- eller Card_Sign-certifikater af anden genera­
tion, som er udstedt af samme land som kontrolkortets 
eget kortcertifikat.  
Hvis det selv foretager verifikationen af underskriften, skal 
IDE-udstyret verificere ægtheden og gyldigheden af alle certi­
fikater i certifikatkæden i datafilen, og det skal verificere 
underskriften ud fra dataene i henhold til den underskrifts­
metode, der defineres i [DSS]. I begge tilfælde er det for 
hvert certifikat, der læses fra datafilen, nødvendigt at kontro l­
lere, at CHA-feltet (Card Holder Authorisation) er korrekt:  
— EQT-certifikatets CHA-felt skal angive et køretøjsenheds- 
eller kortcertifikat (alt efter hvad der er relevant) til brug 
ved underskrift (se tillæg 1, datatypen Equipment Type).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 500  
— CHA'en på EQT.CA-certifikatet skal angive en MSCA.  
— CHA'en på EQT.Link-certifikatet skal angive ERCA'en. ◄  
Bemærkninger til Figur 13:  
— Det udstyr, som har overført og underskrevet de data, der 
skal analyseres, benævnes EQT (udstyr).  
— EQT-certifikaterne og de offentlige nøgler, der nævnes i 
figuren, er dem, der anvendes til underskrift, dvs. 
VU_Sign eller Card_Sign.  
— EQT.CA-certifikaterne og de offentlige nøgler, der 
nævnes i figuren, er dem, der anvendes til underskrift af 
enten bevægelsessensor- eller kortcertifikater.  
— EQT.CA.EUR-certifikatet, der nævnes i figuren, er det 
europæiske rodcertifikat, der angives i EQT.CA-certifika­
tets CAR.  
— EQT.Link-certifikatet, der nævnes i figuren, er EQT'ens 
forbindelsescertifikat, hvis dette findes. Som beskrevet i 
afsnit 9.1.2 er dette et forbindelsescertifikat til et euro­
pæisk rodnøglepar, som er oprettet af ERCA'en og under­
skrevet af den tidligere europæiske private nøgle.  
— EQT.Link.EUR-certifikatet er det europæiske rodcerti­
fikat, der angives i EQT.Link-certifikatets CAR.  
CSM_235 Ved beregning af hash-værdien M, som sendes til kontrol ­
kortet i PSO:Hash-kommandoen, benytter IDT-udstyret den 
hash-algoritme, der er knyttet til nøglestørrelsen af køretøjs­
enheden eller kortet, hvorfra dataene er overført, som speci­
ficeret i CSM_50.  
CSM_236 Til verifikation af EQT'ets underskrift skal kontrolkor tet følge 
den underskriftsmetode, der defineres i [DSS].  
Bemærk:  I dette dokument angives det ikke, hvilke foranstalt­
ninger der skal træffes, hvis en underskrift ud fra en overført  
datafil ikke kan verificeres, eller hvis verifikationen ikke 
lykkes.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 501  
Figur 13  
Protokol til verifikation af underskriften ud fra en overført datafil
  ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 502  
Tillæg 12  
LOKALISERING BASERET PÅ ET GLOBALT 
SATELLITNAVIGATIONSSYSTEM (GNSS)  
INDHOLDSFORTEGNELSE  
1. INDLEDNING  
1.1. Anvendelsesområde  
▼M3 
1.1.1 Referencer  
▼B 
1.2. Akronymer og notation  
▼M3 
2. GNSS-MODTAGERENS GRUNDLÆGGENDE EGENSKABER  
3. SÆTNINGER FRA GNSS-MODTAGEREN  
▼B 
4. KØRETØJSENHED MED EKSTERNT GNSS-UDSTYR  
4.1. Konfiguration  
4.1.1 Vigtigste komponenter og interfaces  
4.1.2 Det eksterne GNSS-udstyrs tilstand ved afslutningen af pr oduktionen  
4.2. Kommunikation mellem det eksterne GNSS-udstyr og køretøjse nheden  
4.2.1 Kommunikationsprotokol  
4.2.2 Sikker overførsel af GNSS-data  
4.2.3 Read Record-kommandoens struktur  
▼M3 
4.2.4 WriteRecord-kommandoens struktur  
4.2.5 Andre kommandoer  
▼B 
4.3. Kobling, gensidig ægthedskontrol og kontrol af sessionsnøg leoverens­ 
stemmelse for det eksterne GNSS-udstyr med køretøjsenhed  
4.4. Fejlhåndtering  
4.4.1 Kommunikationsfejl med det eksterne GNSS-udstyr  
4.4.2 Brud på det eksterne GNSS-udstyrs fysiske integritet  
4.4.3 Manglende positionsoplysninger fra GNSS-modtager  
4.4.4 Certifikatet for det eksterne GNSS-udstyr er udløbet  
5. KØRETØJSENHED UDEN EKSTERNT GNSS-UDSTYR  
5.1. Konfiguration  
▼M3 
5.2. Overførsel af oplysninger fra GNSS-modtageren til køretøjs enheden  
__________  
5.3. Overførsel af oplysninger fra køretøjsenheden til GNSS-mod tageren  
5.4. Fejlhåndtering  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 503  
5.4.1 Manglende positionsoplysninger fra GNSS-modtager  
6. KØRETØJSENHEDENS BEHANDLING OG REGISTRERING AF 
POSITIONSDATA  
7. GNSS-TIDSKONFLIKT  
8. KØRETØJSBEVÆGELSESKONFLIKT  
1. INDLEDNING  
Dette tillæg indeholder de tekniske krav til den GNSS-modtager og de 
GNSS-data, som benyttes af køretøjsenheden, inklusive de protok oller, 
der skal gennemføres for at garantere sikker og korrekt dataove rførsel af 
lokaliseringsoplysningerne.  
1.1. Anvendelsesområde  
GNS_1 Køretøjsenheden indsamler positionsdata fra mindst ét 
GNSS-satellitnet.  
Køretøjsenheden kan være forsynet med eksternt GNSS-udstyr, 
jf. Figur 1:  
1.1.1  Henvisninger  
Følgende henvisninger benyttes i denne del af dette tillæg.  
NMEA NMEA (National Marine Electronics Association) 0183 Inter­
face Standard, V4.11  
▼B 
Figur 1  
Forskellige konfigurationer af GNSS-modtageren.
  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 504  
1.2. Akronymer og notation  
I dette tillæg anvendes følgende akronymer:  
DOP Præcisionsopløsning  
EGF GNSS-udstyrets elementærfil  
EGNOS European Geostationary Navigation Overlay Service  
GNSS Globalt satellitnavigationssystem  
GSA GPS DOP og aktive satellitter  
HDOP Horisontal præcisionsopløsning  
ICD Interfacekontroldokument  
NMEA National Marine Electronics Association  
▼M3 
OSNMA Galileo Open Service Navigation Messages Authentication 
(Ægthedsbekræftelse af navigationsmeddelelser via åben 
Galileo-tjeneste)  
▼B 
PDOP Positions præcisionsopløsning  
RMC Anbefalet minimum specifik  
▼M3 
RTC Real Time Clock (Realtidsur)  
▼B 
SIS Signal i rummet  
VDOP Vertikal præcisionsopløsning  
VU Køretøjsenhed  
▼M3 
2. GNSS-MODTAGERENS GRUNDLÆGGENDE EGENSKABER  
▼B 
Uanset konfigurationen af den intelligente takograf med eller u den 
eksternt GNSS-udstyr er levering af nøjagtige og pålidelige lok aliserings­
oplysninger et centralt element for en effektiv anvendelse af d en intel­
ligente takograf. Derfor er det hensigtsmæssigt at kræve, at de n er 
forenelig med de serviceydelser, som leveres under programmerne  
Galileo og European Geostationary Navigation Overlay Service (E gnos) 
som fastsat i Europa-Parlamentets og Rådets forordning (EU) 
nr. 1285/2013 (  1 ). Det system, der er oprettet under Galileoprogrammet, 
er et uafhængigt globalt satellitnavigationssystem, og det syst em, der er 
oprettet under Egnosprogrammet, er et regionalt satellitnavigat ions­
system, der forbedrer kvaliteten af GPS-signalet (det globale p ositione­
ringssystem).  
GNS_2 Fabrikanterne sikrer, at GNSS-modtagerne i de intelligent e 
takografer er kompatible med positioneringstjenesterne fra 
Galileo- og Egnossystemerne. Fabrikanterne kan derudover 
også vælge kompatibilitet med andre satellitnavigations­
systemer.  ▼B 
( 1 ) Europa-Parlamentets og Rådets forordning (EU) nr. 1285/2013 a f 11. december 2013 om 
etablering og drift af de europæiske satellitbaserede navigatio nssystemer og om ophæ­
velse af Rådets forordning (EF) nr. 876/2002 og Europa-Parlamen tets og Rådets 
forordning (EF) nr. 683/2008 (EUT L 347 af 20.12.2013, s. 1).
 02016R0799 — DA — 21.08.2023 — 003.001 — 505  
GNS_3 GNSS-modtageren skal kunne understøtte Navigation Message s 
Authentication on the Open Service of Galileo (OSNMA).  
GNS_3a GNSS-modtageren foretager en række overensstemmelseskon­
troller for at verificere, at de målinger, som GNSS-modtageren 
har beregnet på grundlag af OSNMA-dataene, har resulteret i 
korrekte oplysninger om køretøjets position, hastighed og data 
og derfor ikke er blevet påvirket af et eksternt angreb som 
f.eks. meaconing. Disse overensstemmelseskontroller kan 
f.eks. omfatte:  
— registrering af unormale emissioner ved hjælp af kombi­
neret overvågning af Automatic Gain Control (AGC) og 
Carrier-to-Noise Density Ratio (C/N0)  
— overensstemmelse af pseudomålinger og Doppler-målinger 
over tid, herunder registrering af abrupte spring i målin­
gerne  
— RAIM-teknikker (receiver autonomous integrity monito­
ring), herunder registrering af uoverensstemmende målinger 
i forhold til den estimerede position  
— kontrol af position og hastighed, herunder unormale 
positions- og hastighedsopløsninger, pludselige spring og 
adfærd, der ikke er i overensstemmelse med køretøjets 
dynamik  
— overensstemmelse mellem tid og frekvens, herunder tids­
spring og tidspunktdrift, som ikke er i overensstemmelse 
med modtagerens urkarakteristika.  
GNS_3b Kommissionen udvikler og godkender følgende dokumenter:  
— et dokument om SIS ICD (Signal in Space Interface 
Control Document), som beskriver de OSNMA-oplys­
ninger, der skal overføres i Galileo-signalet  
— OSNMA Receiver Guidelines med de krav og processer, 
der skal indgå i modtagerne for at garantere en sikker 
gennemførelse af OSNMA, samt anbefalinger til forbedring 
af OSNMA's performance.  
GNSS-modtagere, der er monteret i takografer, enten interne 
eller eksterne, skal konstrueres i overensstemmelse med disse 
SIS-ICD og OSNMA Receiver Guidelines.  
GNS_3c GNSS-modtageren skal levere positionsmeddelelser, der 
betegnes ægthedsbekræftede positionsmeddelelser i dette bilag 
og dets tillæg, som udelukkende er udarbejdet ved hjælp af 
satellitter, hvorfra navigationsmeddelelsernes ægthed er blevet  
verificeret.  
GNS_3d GNSS-modtageren skal også levere standardpositionsmedde­
lelser, der er udarbejdet ved brug af de synlige satellitter, 
uanset om de er ægthedsbekræftede eller ej.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 506  
GNS_3e GNSS-modtageren skal anvende køretøjsenhedens Real Time 
Clock (RTC) som tidsreference for den tidssynkronisering, 
der kræves i forbindelse med OSNMA.  
GNS_3f Køretøjsenhedens RTC-tid leveres til GNSS-modtageren af 
køretøjsenheden.  
GNS_3g Den maksimale tidspunktdrift anført i krav 41 i bilag I C 
leveres til GNSS-modtageren af køretøjsenheden sammen 
med køretøjsenhedens RTC-tid.  
3. SÆTNINGER FRA GNSS-MODTAGEREN  
I dette afsnit beskrives de sætninger, der anvendes i forbindel se med 
intelligente takografer til overførsel af standardpositionsmedd elelser og 
ægthedsbekræftede positionsmeddelelser. Dette afsnit gælder båd e konfi­
gurationen af den intelligente takograf med og uden eksternt 
GNSS-udstyr.  
GNS_4 Standardpositionsdataene er baseret på NMEA-sætningen 
Recommended Minimum Specific (RMC) GNSS-data, der 
indeholder positionsoplysninger (breddegrad, længdegrad), 
klokkeslæt i UTC-format (ttmmss.ss) og hastigheden over 
jorden i knob (Speed Over Ground in Knots) plus supplerende 
værdier.  
RMC-sætningen har følgende format (fra NMEA V4.11-stan­
darden):  
Figur 2  
RMC-sætningens struktur
  
$–RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x .x,xxxx,x.x,a,a,a* hh 
1) Tidspunkt (UTC)  
2) Status, A= Gyldig position, V= Advarsel  
3) Breddegrad  
4) N eller S  
5) Længdegrad  
6) E eller W  
7) Hastighed over jorden i knob  
8) Track made good, grader retvisende  
9) Dato, ddmmåå  
10) Magnetisk variation, grader  
11) E eller W  
12) FAA-tilstandsindikator  
13) Navigationsstatus  
14) Checksum  
Navigationsstatus er valgfri og indgår muligvis ikke i 
RMC-sætningen.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 507  
Status viser, om der modtages et GNSS-signal. Indtil værdien 
for Status ikke er sat til »A«, kan de modtagne data (f.eks. om  
klokkeslæt eller breddegrad/længdegrad) ikke bruges til at 
registrere køretøjets position i køretøjsenheden.  
Opløsningen af positionen er baseret på RMC-sætningens 
format som beskrevet ovenfor. Første del af felt 3) og 5) 
bruges til at angive graderne. Resten bruges til at angive 
minutterne med tre decimaler. Så opløsningen er 1/1 000 
minut eller 1/60 000 grad (fordi et minut er 1/60 grad).  
GNS_4a De ægthedsbekræftede positionsdata er baseret på en 
NMEA-lignende sætning, Authenticated Minimum Specific 
(AMC) Data, som indeholder positionsoplysningerne (bredde­
grad og længdegrad), klokkeslæt i UTC-format (ttmmss.ss) og 
hastigheden over jorden i knob (Speed Over Ground in Knots) 
plus supplerende værdier.  
AMC-sætningen har følgende format (fra NMEA V4.11-stan­
darden, bortset fra værdi nr. 2):  
Figur 3  
AMC-sætningens struktur
  
$–AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*h h 
1) Tidspunkt (UTC)  
2) Status, A=ægthedsbekræftet position (fastslået ved hjælp af mindst 4 satel­
litter, hvorfra navigationsmeddelelsernes ægthed er blevet veri ficeret)), 
J=jamming eller O=andet GNSS-angreb uden mislykket ægthedsbekræ ftelse 
af navigationsmeddelelser (af gennemførte overensstemmelseskont roller efter 
GNS_3a), F=mislykket ægthedsbekræftelse af navigationsmeddelels er (som 
registreret af OSNMA-verifikationer omhandlet i dokumenter nævn t i 
GNS_3b), V=Void (ægthedsbekræftet position er ikke tilgængelig af andre 
årsager)  
3) Breddegrad  
4) N eller S  
5) Længdegrad  
6) E eller W  
7) Hastighed over jorden i knob  
8) Track made good, grader retvisende  
9) Dato, ddmmåå  
10) Magnetisk variation, grader  
11) E eller W  
12) FAA-tilstandsindikator  
13) Navigationsstatus  
14) Checksum  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 508  
Navigationsstatus er valgfri og indgår muligvis ikke i AMC- 
sætningen.  
Status viser, om der findes en ægthedsbekræftet GNSS-posi­
tion, om der er registreret et angreb på GNSS-signalerne, om 
ægthedsbekræftelsen af navigationsmeddelelser er mislykket, 
eller om GNSS-positionen er ugyldig. Når værdien for 
Status ikke er sat til »A«, anses de modtagne data (f.eks. 
om klokkeslæt eller breddegrad/længdegrad) for ikke at være 
gyldige og kan ikke bruges til at registrere køretøjets positio n 
i køretøjsenheden. Når værdien af Status er sat til »J« 
(jamming), »O« (andet GNSS-angreb) eller »F« (mislykket 
ægthedsbekræftelse af navigationsmeddelelser), registreres en 
GNSS-anomali i køretøjsenheden som defineret i bilag I C og 
tillæg 1 (EventFaultCode).  
GNS_5 Køretøjsenheden gemmer positionsoplysninger for breddegra d 
og længdegrad i sin database med en opløsning på 1/10 minut 
eller 1/600 grad som beskrevet i tillæg 1 for typen GeoCo­
ordinates.  
Køretøjsenheden kan bruge kommandoen GPS DOP og aktive 
satellitter (GSA) (fra standarden NMEA V4.11) til at afgøre 
og registrere signalets tilgængelighed og nøjagtigheden af 
standardpositioner. HDOP anvendes navnlig til at give en 
indikation af nøjagtigheden af de registrerede positionsdata 
(se afsnit 4.2.2). Køretøjsenheden gemmer værdien af den 
horisontale præcisionsopløsning (HDOP), der beregnes som 
den mindste af HDOP-værdierne, der er indsamlet på de 
tilgængelige GNSS-systemer.  
GNSS Id. angiver den tilsvarende NMEA Id. for hver GNSS- 
konstellation og Satellite-Based Augmentation System 
(SBAS).  
Figur 4  
GSA-sætningens struktur (standardpositioner)
  
$–GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h  
1) Udvælgelsestilstand  
2) Tilstand  
3) ID for den første satellit, der anvendes til bestemmelse  
4) ID for den anden satellit, der anvendes til bestemmelse  
… 
14) ID for den 12. satellit, der anvendesn til bestemmelse  
15) PDOP  
16) HDOP  
17) VDOP  
18) System id  
19) Checksum  
System id er valgfrit og indgår muligvis ikke i GSA- 
sætningen.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 509  
Køretøjsenheden kan ligeledes bruge ASA-kommandoen, der 
er ægthedsbekræftet med den NMEA-lignende sætning, til at 
afgøre og registrere signalets tilgængelighed og nøjagtigheden 
af ægthedsbekræftede positioner. Værdierne 1 til 18 er defi­
neret i NMEA V4.11-standarden.  
Figur 5  
ASA-sætningens struktur (ægthedsbekræftede positioner)
  
$–ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h  
1) Udvælgelsestilstand  
2) Tilstand  
3) ID for den første satellit, der anvendes til bestemmelse  
4) ID for den anden satellit, der anvendes til bestemmelse  
… 
14) ID for den 12. satellit, der anvendes til bestemmelse  
15) PDOP  
16) HDOP  
17) VDOP  
18) System id  
19) Checksum  
System id er valgfrit og indgår muligvis ikke i ASA- 
sætningen.  
GNS_6 Når der anvendes eksternt GNSS-udstyr, lagres  GSA - 
sætningen i den sikre GNSS-sender/modtager med post­
nummer »02« til »06«, og ASA-sætningen lagres med post­
nummer »12« til »16«.  
GNS_7 Den maksimale størrelse af sætningerne (f.eks. RMC, AMC, 
GSA, ASA eller andre), som kan anvendes til at angive stør­
relsen af kommandoen Read record, er 85 byte (se tabel 1).  
▼M1 
4. KØRETØJSENHED MED EKSTERNT GNSS-UDSTYR  
4.1. Konfiguration  
4.1.1  Vigtigste komponenter og interfaces  
I denne konfiguration er GNSS-modtageren en del af det eksterne  
GNSS-udstyr.  
GNS_8 Det eksterne GNSS-udstyr skal have strøm fra en specifik 
køretøjsinterface.  
▼M3 
GNS_9 Det eksterne GNSS-udstyr består af følgende komponenter 
(se figur 6):  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 510  
a) En kommerciel GNSS-modtager, der leverer positions­
data via GNSS-datainterfacet. GNSS-datainterfacet kan 
f.eks. følge NMEA-standard V4.11, hvor GNSS-modta­
geren fungerer som talker og sender NMEA-sætninger 
til den sikre GNSS-sender/modtager med en frekvens på 
1 Hz for det foruddefinerede sæt af NMEA og 
NMEA-lignende sætninger, der som minimum skal 
omfatte RMC-, AMC-, GSA- og ASA-sætningerne. 
Indførelsen af GNSS-datainterfacet vælges af fabrikanten 
af det eksterne GNSS-udstyr.  
▼B 
b) En sende-/modtageenhed (sikker GNSS-sender/ 
modtager), der kan understøtte standard ISO/IEC 7816- 
4:2013 (se 4.2.1) til at kommunikere med køretøjs­
enheden og understøtte GNSS-datainterfacet til GNSS- 
modtageren. Enheden er udstyret med en hukommelse til 
lagring af GNSS-modtagerens og det eksterne GNSS- 
udstyrs identifikationsdata.  
▼M3 
c) Et indkapslingssystem med en funktion til detektering af 
manipulation, som indkapsler både GNSS-modtageren 
og den sikre GNSS-sender/modtager. Funktionen til 
detektering af manipulation omfatter de sikkerheds- og 
beskyttelsesforanstaltninger, der kræves i beskyttelses­
profilen for den intelligente takograf.  
▼B 
d) En GNSS-antenne monteret på køretøjet og tilsluttet 
GNSS-modtageren gennem indkapslingssystemet.  
GNS_10 Det eksterne GNSS-udstyr har som minimum følgende 
eksterne interfaces:  
a) interfacet til GNSS-antennen, som er monteret på køre­
tøjets trækker, hvis der benyttes en ekstern antenne  
b) interfacet til køretøjsenheden.  
GNS_11 I køretøjsenheden er køretøjsenhedens sikre sender- 
modtager den anden ende af den sikre kommunikation 
med den sikre GNSS-sender/modtager, og den skal under­
støtte ISO/IEC 7816-4:2013 for forbindelsen til det eksterne 
GNSS-udstyr.  
GNS_12 Hvad angår det fysiske lag af forbindelsen til det ekste rne 
GNSS-udstyr, skal køretøjsenheden understøtte ISO/IEC 
7816-12:2005 eller en anden standard, som understøtter 
ISO/IEC 7816-4:2013 (se 4.2.1).  
4.1.2  Det eksterne GNSS-udstyrs tilstand ved afslutningen af produktionen  
GNS_13 Det eksterne GNSS-udstyr gemmer følgende værdier i det 
ikkeflygtige lager i den sikre GNSS-sender/modtager, når 
den forlader fabrikken:  
— EGF_MA-nøgleparret og det tilhørende certifikat  
— MSCA_VU-EGF-certifikatet, der indeholder den offent­
lige MSCA_VU-EGF.PK-nøgle, der skal anvendes til 
verifikation af EGF_MA-certifikatet  
— EUR-certifikatet, der indeholder den offentlige 
EUR.PK-nøgle, der skal benyttes til verifikation af 
MSCA_VU-EGF-certifikatet  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 511  
— EUR-certifikatet, hvis gyldighedsperiode ligger umid­
delbart forud for EUR-certifikatets gyldighedsperiode, 
som skal anvendes til at verificere MSCA_VU-EGF- 
certifikatet, hvis dette findes  
— forbindelsescertifikatet, der knytter disse to EUR-certifi­
kater sammen, hvis dette findes  
— det udvidede serienummer for det eksterne GNSS-udstyr  
— identifikatoren for styresystemet i GNSS-udstyret  
— typegodkendelsesnummeret på det eksterne GNSS- 
udstyr  
— identifikatoren for sikkerhedskomponenten for det 
eksterne GNSS-modul.  
4.2. Kommunikation mellem det eksterne GNSS-udstyr og køretøjs ­
enheden  
4.2.1  Kommunikationsprotokol  
▼M3 
GNS_14 Kommunikationsprotokollen mellem det eksterne GNSS- 
udstyr og køretøjsenheden skal understøtte følgende funk­
tioner:  
1. indsamling og distribution af GNSS-data (f.eks., posi­
tion, tidspunkt, hastighed)  
2. indsamling af konfigurationsdata for det eksterne 
GNSS-udstyr  
3. administrationsprotokollen, der understøtter sammenkob­
lingen, gensidig ægthedskontrol og kontrol af sessions­
nøgleoverensstemmelse mellem det eksterne GNSS- 
udstyr og køretøjsenheden  
4. overførslen til det eksterne GNSS-udstyr af køretøjs­
enhedens RTC-tid og af den maksimale forskel mellem 
sand tid og køretøjsenhedens RTC-tid.  
▼B 
GNS_15 Kommunikationsprotokollen er baseret på standard ISO/IEC  
7816-4:2013, hvor køretøjsenhedens sikre sender/modtager 
er »master«, og den sikre GNSS-sender/modtager er 
»slave«. Den fysiske forbindelse mellem det eksterne 
GNSS-udstyr og køretøjsenheden er baseret på ISO/IEC 
7816-12:2005 eller en anden standard, som understøtter 
ISO/IEC 7816-4:2013.  
▼M1 
GNS_16 Kommunikationsprotokollen understøtter ikke felter med 
udvidet længde.  
▼B 
GNS_17 Kommunikationsprotokollen fra ISO 7816 (både *-4:2013 
og *-12:2005) mellem det eksterne GNSS-udstyr og køre­
tøjsenheden angives til T=1.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 512  
GNS_18 Hvad angår funktionerne 1) indsamling og distribution af  
GNSS-data, 2) indsamling af konfigurationsdata for det 
eksterne GNSS-udstyr og 3) administrationsprotokollen, 
skal den sikre GNSS-sender/modtager simulere et intelligent 
kort med en filsystemarkitektur bestående af en masterfil 
(MF), en dedikeret fil (DF) med en applikations-ID som 
specificeret i tillæg 1, afsnit 6.2 (»FF 44 54 45 47 4D«) 
og med 3 elementærfiler, der indeholder certifikater og en 
enkelt elementærfil (EF.EGF) med en filidentifikator lig 
med »2F2F« som beskrevet i tabel 1.  
GNS_18a Med hensyn til funktion 4) (overførslen til det ekstern e 
GNSS-udstyr af køretøjsenhedens RTC-tid og af den maksi­
male forskel mellem sand tid og køretøjsenhedens RTC-tid) 
skal den sikre GNSS-sender/modtager anvende en elemen­
tærfil (elementærfilen VU) i den samme dedikerede fil med 
en filidentifikator svarende til »2F30« som beskrevet i 
tabel 1.  
▼B 
GNS_19 Den sikre GNSS-sender/modtager gemmer data, der 
kommer fra GNSS-modtageren og konfigurationen i 
EF.EGF. Dette er en lineær registerfil af variabel længde 
med en identifikator lig med »2F2F« i hexadecimalformat.  
▼M3 
GNS_19a Den sikre GNSS-sender/modtager gemmer data fra køretøjs ­
enheden i elementærfilen VU. Dette er en lineær registerfil 
af fast længde med en identifikator lig med »2F30« i 
hexadecimalformat.  
GNS_20 Den sikre GNSS-sender/modtager skal anvende en hukom­
melse til at lagre dataene og kunne udføre så mange læse- 
og skrivecyklusser som nødvendigt i løbet af en levetid på 
mindst 15 år. Bortset fra dette aspekt overlades det interne 
design og implementeringen af den sikre GNSS-sender/ 
modtager til fabrikanterne.  
▼M1 
Kortlægningen af registernumre og data findes i tabel 1. 
Bemærk, at der findes fem GSA-sætninger for GNSS- 
konstellationerne og Satellite-Based Augmentation System 
(SBAS).  
▼B 
GNS_21 Filstrukturen findes i Tabel 1. For så vidt angår adgang s­
betingelser (ALW, NEV, SM-MAC) henvises til tillæg 2, 
kapitel 3.5.  
▼M3 
Tabel 1  
Filstruktur  
Adgangsbetingelser  
Fil Fil-ID  Læs  Update  Krypteret  
MF 3F00  
EF.ICC  0002  ALW  NEV 
(efter køretøjs­
enhed)  Nr. ▼M1
 02016R0799 — DA — 21.08.2023 — 003.001 — 513  
Adgangsbetingelser  
Fil Fil-ID  Læs  Update  Krypteret  
DF GNSS-udstyr  0501  ALW  NEV  Nr.  
EF EGF_MA_Certificate  C100  ALW  NEV  Nr.  
EF CA_Certificate  C108  ALW  NEV  Nr.  
EF Link_Certificate  C109  ALW  NEV  Nr.  
EF EGF  2F2F  SM-MAC  NEV 
(efter køretøjs­
enhed)  Nr. 
EF VU  2F30  SM-MAC  SM-MAC  Nr.  
Fil/dataelement  Post nr.  Størrelse (bytes)  Standardvær­
dier 
Min Max  
MF 552  1031  
EF.ICC  
sensorGNSSSerialNumber  8  8  
DF GNSS-udstyr  612  1023  
EF EGF_MA_Certificate  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  
RMC NMEA-sætning  »01«  8 5  8 5  
1. GSA NMEA-sætning  »02«  8 5  8 5  
2. GSA NMEA-sætning  »03«  8 5  8 5  
3. GSA NMEA-sætning  »04«  8 5  8 5  
4. GSA NMEA-sætning  »05«  8 5  8 5  
5. GSA NMEA-sætning  »06«  8 5  8 5  
Udvidet serienummer for det eksterne 
GNSS-udstyr defineret i tillæg 1 som 
SensorGNSSSerialNumber.  »07«  8  8  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 514  
Fil/dataelement  Post nr.  Størrelse (bytes)  Standardvær­
dier 
Identifikator for styresystemet for den 
sikre GNSS-sender/modtager defineret 
i tillæg 1 som SensorOSIdentifier.  »08«  2  2  
Typegodkendelsesnummer for det 
eksterne GNSS-udstyr defineret i 
tillæg 1 som SensorExternalGNSSAp­
provalNumber.  »09«  1 6  1 6  
Identifikator for sikkerhedskompo­
nenten for det eksterne GNSS-udstyr 
defineret i tillæg 1 som SensorExter­
nalGNSSSCIdentifier  »10«  8  8  
AMC-sætning  »11«  8 5  8 5  
1. ASA-sætning  »12«  8 5  8 5  
2. ASA-sætning  »13«  8 5  8 5  
3. ASA-sætning  »14«  8 5  8 5  
4. ASA-sætning  »15«  8 5  8 5  
5. ASA-sætning  »16«  8 5  8 5  
RFU — Forbeholdt fremtidig brug — 
(Reserved for future use)  Fra »17« 
til »FD«  
EF VU  
VuRtcTime (se tillæg 1)  »01«  4  4  {00..00}  
VuGnssMaximalTimeDifference (se 
tillæg 1)  »02«  2  2  {00..00}  
▼B 
4.2.2  Sikker overførsel af GNSS-data  
▼M3 
GNS_22 Sikker overførsel af GNSS-positionsdata, køretøjsenheden s 
RTC-tid og den maksimale tidsforskel mellem det faktiske 
tidspunkt og køretøjsenhedens RTC-tid må kun tillades 
under følgende betingelser:  
▼B 
1. Koblingsprocessen er gennemført som beskrevet i tillæg 
11. Fælles sikkerhedsmekanismer.  
2. Den periodiske gensidige ægthedskontrol og kontrol af 
sessionsnøgleoverensstemmelse mellem køretøjsenheden 
og det eksterne GNSS-udstyr beskrives ligeledes i tillæg 
11. Fælles sikkerhedsmekanismer er blevet gennemført 
med den angivne frekvens.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 515  
GNS_23 Hver T sekunder, hvor T er lavere end eller lig med 20, 
medmindre kobling eller gensidig ægthedskontrol og 
kontrol af sessionsnøgleoverensstemmelse finder sted, 
anmoder køretøjsenheden det eksterne GNSS-udstyr om 
positionsoplysninger på grundlag af følgende flow:  
1. Køretøjsenheden anmoder om positionsdata fra det 
eksterne GNSS-udstyr sammen med data om præcisions­
opløsning (fra GSA- og ASA-sætningen). Køretøjsenhe­
dens sikre sender/modtager anvender kommandoerne 
SELECT og READ RECORD(S) ifølge ISO/IEC 7816- 
4:2013 i tilstanden »Kun ægthedskontrol« for den sikre 
meddelelsesfunktion som beskrevet i tillæg 11, afsnit 
11.5, med filidentifikatoren »2F2F« og RECORD-tallet 
lig med »01« for RMC NMEA-sætningen, 
»02«,»03«,»04«,»05«,»06« for GSA NMEA-sætningen, 
»11« for AMC-sætningen og »12«,»13«,»14«,»15«,»16« 
for ASA-sætningen.  
2. De senest modtagne positionsdata gemmes i elementær­
filen med identifikatoren »2F2F« og posterne, der 
beskrives i Tabel 1 i den sikre GNSS-sender/modtager, 
mens den sikre GNSS-sender/modtager modtager 
NMEA-data med en frekvens på mindst 1 Hz fra 
GNSS-modtageren via GNSS-datainterfacet.  
3. Den sikre GNSS-sender/modtager sender svaret til køre­
tøjsenhedens sikre sender/modtager ved hjælp af 
APDU-svarmeddelelsen i tilstanden »Kun ægthedskon­
trol« i den sikre meddelelsesoverførsel som beskrevet i 
tillæg 11, afsnit 11.5.  
4. Køretøjsenhedens sikre sender/modtager kontrollerer 
ægtheden og integriteten af det modtagne svar. Ved et 
positivt resultat overføres positionsdataene til køretøjs­
enhedens processor via GNSS-datainterfacet.  
5. Køretøjsenhedens processor kontrollerer de modtagne 
data ved at udtrække oplysningerne (f.eks. breddegrad, 
længdegrad, tidspunkt) af RMC NMEA-sætningen. 
RMC NMEA-sætningen medtager oplysningerne, hvis 
den ikke-ægthedsbekræftede position er gyldig. Hvis 
den ikke-ægthedsbekræftede position er gyldig, 
udtrækker køretøjsenhedens processor ligeledes HDOP- 
værdierne fra GSA NMEA-sætningerne og beregner 
mindsteværdien af de tilgængelige satellitsystemer (dvs. 
når den modtager et signal).  
6. Køretøjsenhedens processor udtrækker også oplysnin­
gerne (f.eks. breddegrad, længdegrad, tidspunkt) af 
AMC-sætningen. AMC-sætningen medtager oplysnin­
gerne, hvis den ægthedsbekræftede position ikke er 
gyldig, eller GNSS-signalet er blevet angrebet. Hvis 
positionen er gyldig, udtrækker køretøjsenhedens 
processor ligeledes HDOP-værdierne fra ASA-sætnin­
gerne og beregner mindsteværdien af de tilgængelige 
satellitsystemer (dvs. når den modtager et signal).  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 516  
GNS_23a Køretøjsenheden skal også skrive køretøjsenhedens RTC-t id 
og den maksimale tidsforskel mellem det faktiske tidspunkt 
og køretøjsenhedens RTC-tid, hvis det er nødvendigt, ved 
hjælp af kommandoerne SELECT og WRITE RECORD(S) 
ifølge ISO/IEC 7816-4:2013 i tilstanden »Kun ægthedskon­
trol« for den sikre meddelelsesfunktion som beskrevet i 
tillæg 11, afsnit 11.5, med filidentifikatoren »2F2F« og 
RECORD-tallet lig med »01« for VuRtcTime og »02« for 
MaximalTimeDifference.  
▼B 
4.2.3  Read Record-kommandoens struktur  
Dette afsnit indeholder en detaljeret beskrivelse af Read Recor d- 
kommandoens struktur. Sikre meddelelser (tilstanden »Kun ægthed s­
kontrol«) tilføjes som beskrevet i tillæg 11, Fælles sikkerheds meka­
nismer.  
GNS_24 Kommandoen understøtter sikker meddelelsesoverførsel i 
tilstanden »Kun ægthedskontrol«, se tillæg 11.  
GNS_25 Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »0Ch«  Der er anmodet om sikker meddelelses­
overførsel  
INS 1  »B2h«  Read Record  
P1 1  »XXh«  Post nr. (»00« henviser til den aktuelle 
post)  
P2 1  »04h«  Læst posten med det postnummer, der 
angives i P1  
Le 1  »XXh«  Forventet datalængde. Antal byte, som 
skal læses  
GNS_26 Posten, der henvises til i P1, bliver den aktuelle post.  
Byte  Længde  Værdi  Beskrivelse  
#1-#X  X  »XX..XXh«  Data læst  
SW 2  »XXXXh«  Statusord (SW1,SW2)  
— Giver kommandoen resultat, tilbagemelder den sikre 
GNSS-sender/modtager » 9000 «. 
— Hvis den aktuelle fil ikke er postorienteret, tilbage­
melder den sikre GNSS-sender/modtager  »6981« . 
— Hvis kommandoen bruges med P1 = »00«, men der 
ikke findes nogen aktuel elementærfil, tilbagemelder 
den sikre GNSS-sender/modtager  »6986«  (kommando 
ikke tilladt).  
▼M3 
— Hvis posten ikke findes, tilbagemelder den sikre 
GNSS-sender/modtager »6A83«.  
— Hvis det eksterne GNSS-udstyr har konstateret manipu­
lation, tilbagemelder det statusordene »6690«.  
__________  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 517  
4.2.4 WriteRecord-kommandoens struktur  
Dette afsnit indeholder en detaljeret beskrivelse af Write Reco rd-komman­
doens struktur. Sikre meddelelser (tilstanden »Kun ægthedskontr ol«) 
tilføjes som beskrevet i tillæg 11, Fælles sikkerhedsmekanismer . 
GNS_26a Kommandoen understøtter sikker meddelelsesoverførsel i 
tilstanden »Kun ægthedskontrol«, se tillæg 11.  
GNS_26b Kommandomeddelelse  
Byte  Længde  Værdi  Beskrivelse  
CLA  1  »0Ch«  Der er anmodet om sikker meddelelses­
overførsel  
INS 1  »D2h«  Write Record  
P1 1  »XXh«  Post nr. (»00« henviser til den aktuelle 
post)  
P2 1  »04h«  Skriv posten med det postnummer, der 
angives i P1  
Data  X  »XXh«  Data  
GNS_26c Posten, der henvises til i P1, bliver den aktuelle post . 
Længde  Længde  Værdi  Beskrivelse  
SW 2  »XXXXh«  Statusord (SW1, SW2)  
— Giver kommandoen resultat, tilbagemelder den sikre 
GNSS-sender/modtager »9000«.  
— Hvis den aktuelle fil ikke er postorienteret, tilbage­
melder den sikre GNSS-sender/modtager  »6981 «. 
— Hvis kommandoen bruges med P1 = »00«, men der 
ikke findes nogen aktuel elementærfil, tilbagemelder 
den sikre GNSS-sender/modtager » 6986 « (kommando 
ikke tilladt).  
— Hvis posten ikke findes, tilbagemelder den sikre 
GNSS-sender/modtager » 6A83 «. 
— Hvis det eksterne GNSS-udstyr har konstateret manipu­
lation, tilbagemelder det statusordene » 6690 «." 
4.2.5  Andre kommandoer  
GNS_27 Den sikre GNSS-sender/modtager understøtter følgende 
kommandoer fra takografer af anden generation, som speci­
ficeres i tillæg 2:  
Kommando  Henvisning  
Select (Vælg)  Tillæg 2, kapitel 3.5.1  
Read Binary (Læs binær værdi)  Tillæg 2, kapitel 3.5.2  
Get Challenge (Hent en challenge)  Tillæg 2, kapitel 3.5.4  
PSO: Verify Certificate (Verificer certi­
fikat)  Tillæg 2, kapitel 3.5.7  
External Authenticate (Ekstern ægtheds­
kontrol)  Tillæg 2, kapitel 3.5.9  
General Authenticate (Almen ægtheds­
kontrol)  Tillæg 2, kapitel 3.5.10  
MSE:SET  Tillæg 2, kapitel 3.5.11.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 518  
4.3. Kobling, gensidig ægthedskontrol og kontrol af sessionsnøgleover ­
ensstemmelse for det eksterne GNSS-udstyr med køretøjsenhed  
Kobling, gensidig ægthedskontrol og kontrol af sessionsnøglesov erens­
stemmelse for det eksterne GNSS-udstyr med køretøjsenhed beskri ves 
i tillæg 11. Fælles sikkerhedsmekanismer, kapitel 11.  
4.4. Fejlhåndtering  
I dette afsnit beskrives det, hvordan potentielle fejltilstande  hos det 
eksterne GNSS-udstyr behandles og registreres i køretøjsenheden . 
4.4.1  Kommunikationsfejl med det eksterne GNSS-udstyr  
▼M3 
GNS_28 Der registreres en fejl i kommunikationen med det ekster ne 
GNSS-udstyr i køretøjsenheden som defineret i krav 82 i 
bilag I C og tillæg 1 (EventFaultType). I den forbindelse 
opstår der en kommunikationsfejl, når køretøjsenhedens 
sikre sender/modtager ikke modtager en svarmeddelelse 
efter en anmodningsmeddelelse som beskrevet i afsnit 4.2.  
▼B 
4.4.2  Brud på det eksterne GNSS-udstyrs fysiske integritet  
▼M3 
GNS_29 Hvis det eksterne GNSS-udstyr er blevet brudt, skal den 
sikre GNSS-sender/modtager sikre, at det kryptografiske 
materiale ikke er tilgængeligt. Som beskrevet i GNS_25 
og GNS_26 detekterer køretøjsenheden manipulation, hvis 
Svar har status »6690«. Køretøjsenheden genererer og regi­
strerer derefter en hændelse i forbindelse med forsøg på 
sikkerhedsbrud som defineret i krav 85 i bilag I C og 
tillæg 1 (EventFaultType til detektering af manipulation 
af GNSS). Det eksterne GNSS-udstyr kan alternativt 
besvare køretøjsenhedens anmodninger uden sikker medde­
lelsesoverførsel og med status »6A88«.  
▼B 
4.4.3  Manglende positionsoplysninger fra GNSS-modtager  
▼M3 
GNS_30 Hvis den sikre GNSS-sender/modtager ikke modtager data 
fra GNSS-modtageren, genererer den sikre GNSS-sender/ 
modtager en svarmeddelelse på READ RECORD-komman­
doen med et RECORD-nummer lig med »01« med et 
datafelt på 12 byte, som alle er sat til 0xFF. Efter modta­
gelsen af svarmeddelelsen med denne værdi i datafeltet, 
genererer og registrerer køretøjsenheden hændelsen »Mang­
lende positionsoplysninger fra GNSS-modtager« som defi­
neret i krav 81 i bilag I C og tillæg 1 (EventFaultType).  
▼B 
4.4.4  Certifikatet for det eksterne GNSS-udstyr er udløbet  
▼M3 
GNS_31 Hvis køretøjsenheden detekterer, at EGF'ens certifikat, som 
anvendes til gensidig ægthedsbekræftelse, ikke længere er 
gyldigt, genererer og registrerer køretøjsenheden en 
hændelse af typen forsøg på sikkerhedsbrud som defineret 
i krav 85 i bilag I C og tillæg 1 (EventFaultType for 
certifikat for eksternt GNSS-udstyr udløbet). Køretøjs­
enheden anvender stadig de modtagne GNSS-positionsdata.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 519  
Figur 6  
Skema over det eksterne GNSS-udstyr  
▼B
 
5. KØRETØJSENHED UDEN EKSTERNT GNSS-UDSTYR  
5.1. Konfiguration  
I denne konfiguration befinder GNSS-modtageren sig inde i køret øjs­
enheden som beskrevet i Figur 1.  
▼M3 
GNS_32 Ved overførsel af positions, DOP- og satellitdata funger er 
GNSS-modtageren som talker og overfører NMEA- eller 
NMEA-lignende sætninger til køretøjsenhedens processor, 
der fungerer som modtager med en frekvens på 1/10 Hz 
eller hurtigere for et forud defineret sæt sætninger, der som 
minimum skal omfatte RMC-, GSA-, AMC- og ASA- 
sætninger. Alternativt kan køretøjsenhedens processor og 
den interne GNSS-modtager anvende andre dataformater 
til at udveksle de data, der er indeholdt i NMEA eller 
NMEA-lignende sætninger som specificeret i GNS_4, 
GNS_4a og GNS_5.  
▼B 
GNS_33 En ekstern GNSS-antenne monteret på køretøjet eller en 
intern GNSS-antenne skal være tilsluttet køretøjsenheden.  
▼M3 
5.2. Overførsel af oplysninger fra GNSS-modtageren til køretøjs ­
enheden  
GNS_34 Køretøjsenhedens processor kontrollerer de modtagne data  
ved at udtrække oplysningerne (f.eks. breddegrad, længde­
grad, tidspunkt) af RMC NMEA-sætningen og AMC- 
sætningen.  
GNS_35 RMC NMEA-sætningen medtager oplysningerne, hvis den 
ikke-ægthedsbekræftede position er gyldig. Hvis den 
ikke-ægthedsbekræftede position is ikke er gyldig, er posi­
tionsdataene endnu ikke tilgængelige, og de kan ikke 
anvendes til at registrere køretøjets position. Hvis den 
ikke-ægthedsbekræftede position er gyldig, udtrækker køre­
tøjsenhedens processor også HDOP-værdierne fra GSA 
NMEA.  
GNS_36 Køretøjsenhedens processor udtrækker også oplysningerne 
(f.eks. breddegrad, længdegrad, tidspunkt) af AMC- 
sætningen. AMC-sætningen medtager oplysningerne, hvis 
den ikke-ægthedsbekræftede position er gyldig i overens­
stemmelse med GNS_4a. Hvis den ikke-ægthedsbekræftede 
position er gyldig, udtrækker køretøjsenhedens processor 
også HDOP-værdierne fra ASA-sætningerne.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 520  
5.3. Overførsel af oplysninger fra køretøjsenheden til GNSS-modta ­
geren  
GNS_37 Køretøjsenhedens processor leverer køretøjsenhedens 
RTC-tid og af den maksimale forskel mellem sand tid og 
køretøjsenhedens RTC-tid i overensstemmelse med 
GNS_3f og GNS_3g til GNSS-modtageren.  
5.4. Fejlhåndtering  
5.4.1 Manglende positionsoplysninger fra GNSS-modtager  
GNS_38 Køretøjsenheden genererer og registrerer hændelsen 
»Manglende positionsoplysninger fra GNSS-modtager« 
som defineret i krav 81 i bilag I C og tillæg 1 (EventFault­
Type).  
6. KØRETØJSENHEDENS BEHANDLING OG REGISTRERING AF 
POSITIONSDATA  
Dette afsnit gælder både konfigurationen af den intelligente ta kograf 
med og uden eksternt GNSS-udstyr.  
GNS_39 Positionsdata skal lagres i køretøjsenheden sammen med e t 
flag, der viser, om positionen er blevet ægthedsbekræftet. 
Når positionsdata skal registreres i køretøjsenheden, gælder 
følgende regler:  
a) Hvis både den ægthedsbekræftede position og standard­
positionen er gyldige og overensstemmende, registreres 
standardpositionen og dens nøjagtighed i køretøjs­
enheden, og flaget indstilles til »ægthedsbekræftet«.  
b) Hvis både den ægthedsbekræftede position og standard­
positionen er gyldige, men ikke overensstemmende, 
lagrer køretøjsenheden den ægthedsbekræftede position 
og dens nøjagtighed, og flaget indstilles til »ægtheds­
bekræftet«.  
c) Hvis den ægthedsbekræftede position er gyldig, og stan­
dardpositionen ikke er gyldig, registrerer køretøjs­
enheden den ægthedsbekræftede position og dens nøjag­
tighed, og flaget indstilles til »ægthedsbekræftet«.  
d) Hvis standardpositionen er gyldig, og den ægtheds­
bekræftede position ikke er gyldig, registrerer køretøjs­
enheden standardpositionen og dens nøjagtighed, og 
flaget indstilles til »ikke ægthedsbekræftet«.  
Ægthedsbekræftede positioner og standardpositioner anses 
for at være overensstemmende (som vist i figur 7), når den 
horisontale ægthedsbekræftede position kan findes i en 
cirkel, der er centreret ved den horisontale standardposition, 
og hvis radius fås ved at afrunding opad til nærmeste hele 
tal af R_H beregnet efter følgende formel: 
R_H = 1,74 • σ  UERE  • HDOP  
hvor:  
— R_H er den relative radius af en cirkel omkring den 
estimerede horisontale position i meter. Det er en indi­
kator, der bruges til at kontrollere overensstemmelsen 
mellem standardpositioner og ægthedsbekræftede 
positioner.  
— σ  UERE  er standardafvigelsen for User Equivalent Range 
Error (UERE), der modellerer alle målefejl for målap­
plikationen, herunder bymiljøer. Der anvendes en 
konstant værdi på σ  UERE  = 10 meter.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 521  
— HDOP er den horisontale præcisionsopløsning beregnet 
af GNSS-modtageren.  
— σ  UERE  . HDOP er estimatet af Root Mean Squared Error 
i det horisontale domæne.  
Figur 7  
Overensstemmende ægthedsbekræftede positioner og 
ikke-ægthedsbekræftede standardpositioner
  
GNS_40 Når værdien af status i en modtaget AMC-sætning er sat t il 
»J« eller »O« eller »F« i overensstemmelse med krav 
GNS_4a, skal køretøjsenheden generere og registrere en 
GNSS-anomali som defineret i krav 88a i bilag I C og 
tillæg 1 (EventFaultType). Køretøjsenheden kan foretage 
yderligere kontrol, inden den lagrer en GNSS-anomali 
efter modtagelse af en »J«- eller »O«-værdi.  
7. GNSS-TIDSKONFLIKT  
GNS_41 Hvis køretøjsenheden registrerer en forskel mellem tiden  i  
køretøjsenhedens tidsmålingsfunktion og tidsangivelsen fra 
GNSS-signalerne, genererer og registrerer den en tidskon­
flikt som defineret i krav 86 i bilag I C og tillæg 1 (Event­
FaultType).  
8. KØRETØJSBEVÆGELSESKONFLIKT  
GNS_42 Køretøjsenheden udløser og registrerer hændelsen køretøj s­
bevægelseskonflikt i overensstemmelse med krav 84 i bilag 
I C, hvis de bevægelsesoplysninger, der beregnes ud fra 
bevægelsesføleren, modsiges af bevægelsesoplysninger 
beregnet ud af den interne GNSS-modtager, det eksterne 
GNSS-udstyr eller andre uafhængige bevægelseskilder som 
fastsat i krav 26 i bilag I C.  
Hændelsen køretøjsbevægelseskonflikt udløses, når en af 
følgende udløsende betingelser indtræder:  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 522  
Udløsende betingelse 1:  
Den trimmede gennemsnitsværdi af hastighedsforskellene 
mellem disse kilder anvendes, når positionsoplysningerne 
fra GNSS-modtageren er tilgængelige, og når køretøjets 
tænding slås til, som angivet nedenfor:  
— mindst hver 10 sekunder beregnes den absolutte værdi 
af forskellen mellem køretøjets hastighed skønnet ud 
fra GNSS og hastigheden skønnet ud fra bevægelses­
føleren.  
— alle beregnede værdier inden for en tidsramme, som 
omfatter mindst fem minutters køretøjsbevægelse, 
anvendes til at beregne middelværdien  
— den trimmede gennemsnitsværdi beregnes som gennem­
snittet af 80 % af de resterende værdier, når de højeste 
værdier i absolutte tal er elimineret.  
Hændelsen køretøjsbevægelseskonflikt udløses, hvis den 
trimmede gennemsnitsværdi er over 10 km/t i fem 
uafbrudte minutter, hvor køretøjet er i bevægelse. 
(Bemærk: Den trimmede gennemsnitsværdi for de seneste 
fem minutter anvendes for at mindske risikoen for afvi­
gende måleværdier og øjebliksværdier).  
Ved beregningen af den trimmede gennemsnitsværdi anses 
køretøjet for at være i bevægelse, hvis mindst én af køre­
tøjets hastighedsværdier estimeret ud fra bevægelsessen­
soren eller GNSS-modtager ikke er lig med nul.  
Udløsende betingelse 2:  
Hændelsen køretøjsbevægelseskonflikt udløses også, hvis 
følgende betingelse er sand:  
GnssDistance  >  [OdometerDifference  × OdometerToleran ­
ceFactor  + Minimum  (SlipDistanceUpperlimit ;(Odometer ­
Difference  × SlipFactor )) + GnssTolerance  + FerryTrain ­
Distance ] 
hvor:  
— GnssDistance  er afstanden mellem køretøjets nuvæ­
rende position og den foregående position, som begge 
er opnået ved gyldige ægthedsbekræftede positionsmed­
delelser, uden hensyntagen til højden  
— OdometerDifference er forskellen mellem den aktuelle 
kilometerstand og kilometertællerens værdi svarende til 
den tidligere gyldige ægthedsbekræftede positionsmed­
delelse  
— OdometerToleranceFactor er lig med 1.1 (worst 
case-tolerancefaktor for alle måletolerancer for køretø­
jets kilometerstand)  
— GnssTolerance er lig med 1 km (worst case GNSS-tole­
rance)  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 523  
— Minimum (SlipDistanceUpperLimit; (OdometerDiffe­
rence * SlipFactor)) er minimumsværdien mellem:  
— SlipDistanceUpperLimit, som er lig med 10 km den 
øvre grænse for slipafstand forårsaget af udslips­
effekter under bremsning)  
— og OdometerDifference * SlipFactor, hvor Slip­
Factor er lig med 0.2 (maksimal virkning af 
udslipseffekter under bremsning)  
— FerryTrainDistance beregnes som: FerryTrainDistance 
=200 km/t * tFerryTrain, hvor tFerryTrain er summen 
af varigheden i timer af færge-/togoverfarter inden for 
det pågældende tidsinterval. Varigheden af en færge- 
/togoverfart defineres som tidsforskellen mellem dens 
slutflag og dens startflag.  
De forudgående kontroller foretages mindst hvert 15. 
minut, hvis de nødvendige positionsdata foreligger, ellers 
så snart positionsdataene foreligger.  
For denne udløsende betingelse gælder følgende:  
— dato og klokkeslæt for hændelsens begyndelse er lig 
med den dato og det klokkeslæt, hvor den foregående 
positionsmeddelelse blev modtaget  
— dato og klokkeslæt for hændelsens afslutning er lig 
med den dato og det klokkeslæt, hvor den kontrollerede 
betingelse bliver falsk igen.  
Udløsende betingelse 3:  
Køretøjsenheden konstaterer en afvigelse, hvor bevægelses­
føleren ikke detekterer nogen bevægelse, og den uafhæn­
gige bevægelseskilde detekterer bevægelse i en bestemt 
periode. Betingelserne for registrering af en afvigelse 
samt perioden for detektering af afvigelsen fastsættes af 
fabrikanten af køretøjsenheden, selv om afvigelsen skal 
detekteres inden for højst tre timer.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 524  
Tillæg 13  
ITS-INTERFACE  
INDHOLDSFORTEGNELSE  
1. INDLEDNING  
1.1. Anvendelsesområde  
1.2. Akronymer og definitioner  
2. REFERENCESTANDARDER  
3. FUNKTIONSPRINCIPPER FOR ITS-INTERFACE  
3.1. Kommunikationsteknologi  
3.2. Tilgængelige tjenester  
3.3. Adgang via ITS-interfacet  
3.4. Tilgængelige data og behov for førerens samtykke  
4. LISTE OVER DATA, DER ER TILGÆNGELIGE VIA ITS-INTER­ 
FACET, OG KLASSIFICERING SOM PERSONLIG/IKKE PERSONLIG  
1. INDLEDNING  
1.1. Anvendelsesområde  
ITS_01 I dette tillæg specificeres de grundlæggende elementer i  kommu­
nikationen gennem takografinterfacet med intelligente transport sy­
stemer (ITS) i overensstemmelse med kravene i artikel 10 og 11 i 
forordning (EU) nr. 165/2014.  
ITS_02 ITS-interfacet skal gøre det muligt for eksterne enheder  at indhente 
data fra takografen, at anvende takograftjenester og også at le vere 
data til takografen.  
Andre takografinterfaces (f.eks. CAN-bus) kan også anvendes til  
dette formål.  
Dette tillæg omhandler ikke:  
— hvordan data, der leveres via ITS-grænsefladen, indsamles og 
håndteres i takografen  
— formatet for præsentationen af de indsamlede data til applika ­
tionerne på den eksterne anordning  
— ITS-sikkerhedsspecifikationen ud over Bluetooth®  
— Bluetooth®-protokollerne, som ITS-interfacet benytter.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 525  
1.2. Akronymer og definitioner  
Følgende akronymer og definitioner anvendes i dette tillæg:  
GNSS  Global Navigation Satellite System (Globalt satellitnaviga­
tionssystem)  
ITS Intelligent Transport System (Intelligent transportsystem)  
OSI Open Systems Interconnection (Åbne systemers sammen­
kobling)  
VU Vehicle Unit (Køretøjsenhed)  
ITS-enhed  En ekstern enhed eller applikation, der anvender køretøjs­
enhedens ITS-interface.  
2. REFERENCESTANDARDER  
ITS_03 Dette tillæg henviser til og er baseret på følgende foro rdninger og 
standarder, enten helt eller delvist. I bestemmelserne i dette tillæg 
angives de relevante standarder eller de relevante bestemmelser  i  
standarderne. Hvis der er modstrid mellem kravene, har bestem­
melserne i dette tillæg forrang.  
De standarder, der henvises til i dette tillæg, er:  
— Bluetooth® — Core Version 5.0.  
— ISO 16844-7: Road vehicles — Tachograph systems — Part 7: 
Parameters  
— ISO/IEC 7498-1:1994 Information technology — Open 
Systems Interconnection — Basic Reference Model, the Basic 
Model  
3. FUNKTIONSPRINCIPPER FOR ITS-INTERFACE  
ITS_04 Køretøjsenheden er ansvarlig for at have ajourførte tako grafdata, 
der overføres via ITS-interfacet, uden at ITS-interfacet involv eres. 
3.1. Kommunikationsteknologi  
ITS_05 Kommunikation via ITS-interfacet sker via Bluetooth®-int erfacet 
og skal være kompatibel med Bluetooth® Low Energy (lavenergi) 
ifølge Bluetooth version 5.0 eller nyere.  
ITS_06 Kommunikationen mellem køretøjsenheden og ITS-enheden et ab­
leres, når en Bluetooth®-parring er udført.  
ITS_07 Der etableres en sikker og krypteret kommunikation melle m køre­
tøjsenheden og ITS-enheden i overensstemmelse med Bluetooth®- 
specifikationsmekanismerne. Dette tillæg omhandler ikke krypte­
ring eller andre sikkerhedsmekanismer ud over det, som Blue­
tooth® tilvejebringer.  
ITS_08 Bluetooth® anvender en server/client-model til at styre overførslen 
af data mellem enheder, hvor køretøjsenheden er server og 
ITS-enheden er client.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 526  
3.2. Tilgængelige tjenester  
ITS_09 De data, der skal overføres via ITS-interfacet i overens stemmelse 
med punkt 4, skal stilles til rådighed gennem de tjenester, der  er 
angivet i tillæg 7 og tillæg 8. Køretøjsenheden skal desuden st ille 
de tjenester til rådighed for ITS-enheden, der er nødvendige fo r 
manuel dataindlæsning i overensstemmelse med krav 61 i bilag 
I C, og eventuelt for andre dataindlæsninger i realtid.  
Figur 1  
Fordeling af kommunikationen via ITS-interfacet efter OSI-modellag
  
ITS_10 Når downloadinterfacet anvendes via det forreste stik, l everer køre­
tøjsenheden ikke de downloadtjenester, der er anført i tillæg 7 , via 
ITS Bluetooth®-forbindelsen.  
ITS_11 Når kalibreringsinterfacet anvendes via det forreste sti k, leverer 
køretøjsenheden ikke de downloadtjenester, der er anført i till æg 
8, via ITS Bluetooth®-forbindelsen.  
3.3. Adgang via ITS-interfacet  
ITS_12 ITS-interfacet giver trådløs adgang til alle de tjeneste r, der er anført 
i tillæg 7 og 8, og erstatter den kabelforbindelse til det forr este stik, 
som kan anvendes til kalibrering og download som anført i tillæ g 
6. 
ITS_13  Køretøjsenheden stiller ITS-interfacet til rådighed for bruger en 
afhængigt af den kombination af gyldige takografkort, der er is at i 
køretøjsenheden, som anført i tabel 1.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 527  
Tabel 1  
ITS-interfacet tilgængelighed afhængigt af den type kort, der er isat i takografen  
Tilgængelighed af 
ITS-interfacet  Førerkortplads  
Intet kort  Førerkort  Kontrolkort  Værkstedskort  Virksomhedskort
 Kortplads for medchauffør Intet kort  Ikke til 
rådighed  Til rådighed  Til rådighed  Til rådighed  Til rådighed  
Førerkort  Til rådighed  Til rådighed  Til rådighed  Til rådighed  Til rådighed  
Kontrolkort  Til rådighed  Til rådighed  Til rådighed  Ikke til 
rådighed  Ikke til rådighed  
Værkstedskort  Til rådighed  Til rådighed  Ikke til 
rådighed  Til rådighed  Ikke til rådighed  
Virksomhedskort  Til rådighed  Til rådighed  Ikke til 
rådighed  Ikke til 
rådighed  Til rådighed  
ITS_14 Efter en vellykket ITS Bluetooth®-parring tildeler køret øjsenheden 
ITS Bluetooth®-forbindelsen til det specifikke isatte takografk ort 
som anført i tabel 2:  
Tabel 2  
Tildeling af ITS-forbindelse afhængigt af den type kort, der er isat i takografen  
Tildeling af ITS Bluetooth®- 
forbindelse  Førerkortplads  
Intet kort  Førerkort  Kontrolkort  Værkstedskort  Virksomhedskort
 Kortplads for medchauffør Intet kort  Ikke til 
rådighed  Førerkort  Kontrolkort  Værkstedskort  Virksomhedskort  
Førerkort  Førerkort  Førerkort (**)  Kontrolkort  Værkstedskort  Virksomhedskort  
Kontrolkort  Kontrolkort  Kontrolkort  Kontrolkort (*)  Ikke til 
rådighed  Ikke til rådighed  
Værkstedskort  Værkstedskort  Værkstedskort  Ikke til 
rådighed  Værksteds­
kort (*)  Ikke til rådighed  
Virksomhedskort  Virksomheds­
kort Virksomheds­
kort Ikke til 
rådighed  Ikke til 
rådighed  Virksomheds­
kort (*)  
(*) ITS Bluetooth®-forbindelsen tildeles takografkortet i køret øjsenhedens førerkortplads. 
(**) Brugeren skal vælge det kort, som ITS Bluetooth®-forbindel sen skal tildeles (isat i førerkortpladsen eller i medchaufføre ns kort­ 
plads).  
ITS_15 Hvis et takografkort udtages, afbryder køretøjsenheden d en ITS 
Bluetooth®-forbindelse, der er tildelt dette kort.  
ITS_16 Køretøjsenheden skal understøtte ITS-forbindelsen til mi ndst én 
ITS-enhed og kan understøtte forbindelser til flere ITS-enheder  
samtidig.  
ITS_17 Adgangsrettighederne til de data og tjenester, der er ti lgængelige 
via ITS-grænsefladen, skal opfylde krav 12 og 13 i bilag I C ud  
over førerens samtykke omhandlet i afsnit 3.4 i dette tillæg.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 528  
3.4. Tilgængelige data og behov for førerens samtykke  
ITS_18 Alle takografdata, der er tilgængelige via de tjenester,  der er 
omhandlet i punkt 3.3, klassificeres enten som personlige eller  
ikke personlige for føreren, medchaufføren eller begge.  
ITS_19 Som minimum skal listen over data, der er klassificeret som obli­
gatoriske i afsnit 4, stilles til rådighed via ITS-interfacet.  
ITS_20 De data i afsnit 4, der er klassificeret som »personlige «, må kun 
være tilgængelige efter førerens samtykke, og det accepteres de rfor, 
at disse personlige oplysninger kan forlade køretøjets net, bor tset 
fra det tilfælde, der er omhandlet i krav ITS_25, hvor førerens  
samtykke ikke er påkrævet.  
ITS_21 Data ud over dem, der indsamles i punkt 4 og betragtes s om 
obligatoriske, kan stilles til rådighed via ITS-interfacet. Yde rligere 
data, der ikke er medtaget i punkt 4, klassificeres som »person lige« 
eller »ikke personlige« af køretøjsenhedens fabrikant, idet der  
anmodes om førerens samtykke i forbindelse med data, der er 
klassificeret som personlige, bortset fra det tilfælde, der er 
omhandlet i krav ITS_25, hvor førerens samtykke ikke er 
påkrævet.  
ITS_22 Hvis der isættes et førerkort, som er ukendt for køretøj senheden, 
anmodes kortindehaveren om at give samtykke til overførsel af 
personlige data gennem ITS-interfacet af takografen, i overens­
stemmelse med krav 61 i bilag I C.  
ITS_23 Samtykkestatus (givet/ikke givet) registreres i køretøjs enhedens 
hukommelse.  
ITS_24 Hvis der er tale om flere førere, vil kun personlige opl ysninger om 
førere, der har givet deres samtykke, være tilgængelige via 
ITS-interfacet. I en besætningssituation er personoplysninger 
vedrørende medchaufføren f.eks. ikke tilgængelige, hvis kun 
føreren har givet sit samtykke.  
ITS_25 Hvis køretøjsenheden er i kontrol-, virksomheds- eller k alibrerings­
tilstand, forvaltes adgangsrettighederne via ITS-interfacet i o verens­
stemmelse med krav 12 og 13 i bilag I C, og førerens samtykke e r 
derfor ikke påkrævet.  
4. LISTE OVER DATA, DER ER TILGÆNGELIGE VIA ITS-INTER­
FACET, OG KLASSIFICERING SOM PERSONLIG/IKKE PERSONLIG  
Databetegnelse  Dataformat  Kilde  Dataklassificering (personlig/ ikke 
personlig)  Samtykke til oplys­
ningernes tilgænge­
lighed  Tilgænge­
lighed  
fører  medchauffør  
VehicleIdentification­
Number  Tillæg 8  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
CalibrationDate  ISO 16844-7  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
TachographVehicleS­
peed  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  obligatorisk  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 529  
Databetegnelse  Dataformat  Kilde  Dataklassificering (personlig/ ikke 
personlig)  Samtykke til oplys­
ningernes tilgænge­
lighed  Tilgænge­
lighed  
fører  medchauffør  
Driver1WorkingState  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  obligatorisk  
Driver2WorkingState  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  obligatorisk  
DriveRecognize  ISO 16844-7  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
Driver1TimeRelated­
States  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  obligatorisk  
Driver2TimeRelated­
States  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  obligatorisk  
DriverCardDriver1  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  obligatorisk  
DriverCardDriver2  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  obligatorisk  
OverSpeed  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  obligatorisk  
TimeDate  Tillæg 8  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
HighResolutionTotal­
VehicleDistance  ISO 16844-7  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
HighResolutionTrip­
Distance  ISO 16844-7  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
ServiceComponent 
Identification  ISO 16844-7  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
ServiceDelayCalen­
darTimeBased  ISO 16844-7  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
Driver1Identification  ISO 16844-7  Fører­
kort personlig  Ikke relevant  førerens 
samtykke  obligatorisk  
Driver2Identification  ISO 16844-7  Fører­
kort Ikke relevant  personlig  medchaufførens 
samtykke  obligatorisk  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 530  
Databetegnelse  Dataformat  Kilde  Dataklassificering (personlig/ ikke 
personlig)  Samtykke til oplys­
ningernes tilgænge­
lighed  Tilgænge­
lighed  
fører  medchauffør  
NextCalibrationDate  Tillæg 8  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
Driver1Continuous­
DrivingTime  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  obligatorisk  
Driver2Continuous­
DrivingTime  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  obligatorisk  
Driver1Cumulative­
BreakTime  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  obligatorisk  
Driver2Cumulative­
BreakTime  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  obligatorisk  
Driver1CurrentDura­
tionOfSelectedActi­
vity ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  obligatorisk  
Driver2CurrentDura­
tionOfSelectedActi­
vity ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  obligatorisk  
SpeedAuthorised  Tillæg 8  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
TachographCardSlot1  ISO 16844-7  Køre­
tøjs­
enhed  ikke personlig  Ikke relevant  intet behov for 
samtykke  obligatorisk  
TachographCardSlot2  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  ikke personlig  intet behov for 
samtykke  obligatorisk  
Driver1Name  ISO 16844-7  Fører­
kort personlig  Ikke relevant  førerens 
samtykke  obligatorisk  
Driver2Name  ISO 16844-7  Fører­
kort Ikke relevant  personlig  medchaufførens 
samtykke  obligatorisk  
OutOfScopeCondi­
tion ISO 16844-7  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
ModeOfOperation  ISO 16844-7  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
Driver1Cumulated­
DrivingTimePrevious 
AndCurrentWeek  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  obligatorisk  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 531  
Databetegnelse  Dataformat  Kilde  Dataklassificering (personlig/ ikke 
personlig)  Samtykke til oplys­
ningernes tilgænge­
lighed  Tilgænge­
lighed  
fører  medchauffør  
Driver2Cumulated­
DrivingTimePreviou­
sAndCurrentWeek  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  obligatorisk  
EngineSpeed  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
RegisteringMember­
State  Tillæg 8  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
VehicleRegistration­
Number  Tillæg 8  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  obligatorisk  
Driver1EndOfLast­
DailyRestPeriod  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2EndOfLast­
DailyRestPeriod  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1EndOfLast­
WeeklyRestPeriod  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2EndOfLast­
WeeklyRestPeriod  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1EndOfSe­
condLastWeeklyRest­
Period  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2EndOfSe­
condLastWeeklyRest­
Period  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  Personlige  medchaufførens 
samtykke  valgfrit  
Driver1TimeLastLoa­
dUnloadOperation  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2TimeLastLoa­
dUnloadOperation  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1CurrentDai­
lyDrivingTime  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2CurrentDai­
lyDrivingTime  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1CurrentWeek­
lyDrivingTime  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2CurrentWeek­
lyDrivingTime  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 532  
Databetegnelse  Dataformat  Kilde  Dataklassificering (personlig/ ikke 
personlig)  Samtykke til oplys­
ningernes tilgænge­
lighed  Tilgænge­
lighed  
fører  medchauffør  
Driver1TimeLeftUn­
tilNewDailyRest­
Period  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2TimeLeftUn­
tilNewDailyRest­
Period  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1CardExpiry­
Date  ISO 16844-7  Fører­
kort personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2CardExpiry­
Date  ISO 16844-7  Fører­
kort Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1Card­
NextMandatory­
DownloadDate  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2Card­
NextMandatory­
DownloadDate  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
TachographNextMan­
datoryDownloadDate  ISO 16844-7  Køre­
tøjs­
enhed  ikke personlig  ikke personlig  intet behov for 
samtykke  valgfrit  
Driver1TimeLeftUn­
tilNewWeeklyRest­
Period  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2TimeLeftUn­
tilNewWeeklyRest­
Period  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1NumberOf­
Times9hDailyDri­
vingTimesExceeded  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2NumberOf­
Times9hDailyDri­
vingTimesExceeded  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1Cumulati­
veUninterruptedRest­
Time  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2Cumulati­
veUninterruptedRest­
Time  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1MinimumDai­
lyRest  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2MinimumDai­
lyRest  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 533  
Databetegnelse  Dataformat  Kilde  Dataklassificering (personlig/ ikke 
personlig)  Samtykke til oplys­
ningernes tilgænge­
lighed  Tilgænge­
lighed  
fører  medchauffør  
Driver1MinimumWe­
eklyRest  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2MinimumWe­
eklyRest  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1Maximum­
DailyPeriod  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2Maximum­
DailyPeriod  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1Maximum­
DailyDrivingTime  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2Maximum­
DailyDrivingTime  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1NumberOf 
UsedReducedDaily­
RestPeriods  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2NumberOf 
UsedReducedDaily­
RestPeriods  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
Driver1Remaining­
CurrentDrivingTime  ISO 16844-7  Køre­
tøjs­
enhed  personlig  Ikke relevant  førerens 
samtykke  valgfrit  
Driver2Remaining­
CurrentDrivingTime  ISO 16844-7  Køre­
tøjs­
enhed  Ikke relevant  personlig  medchaufførens 
samtykke  valgfrit  
VehiclePosition  Tillæg 8  Køre­
tøjs­
enhed  personlig  personlig  førerens og 
medchaufførens 
samtykke  obligatorisk  
ByDefaultLoadType  Tillæg 8  Køre­
tøjs­
enhed  personlig  personlig  førerens og 
medchaufførens 
samtykke  obligatorisk  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 534  
Tillæg 14.  
FJERNKOMMUNIKATIONSFUNKTION  
INDHOLDSFORTEGNELSE  
1 INDLEDNING  
2 ANVENDELSESOMRÅDE  
3 AKRONYMER, DEFINITIONER OG NOTATION  
4 DRIFTSSCENARIER  
4.1 Oversigt  
4.1.1 Forudsætninger for dataoverførsel via 5,8 GHz DSRC-interf ace 
4.1.2 Profil 1a: via en håndholdt eller midlertidig vejsidemont eret læser i 
udstyr til tidlig fjernafsløring  
4.1.3 Profil 1b: via en køretøjsmonteret og dirigeret læser i u dstyr til tidlig 
fjernafsløring.  
4.2 Sikkerhed/integritet  
5 DESIGN OG PROTOKOLLER TIL FJERNKOMMUNIKATION  
5.1 Design  
5.2 Arbejdsgang  
5.2.1 Drift  
5.2.2 Fortolkning af data modtaget via DSRC-kommunikationen  
5.3 Fysiske DSRC-interfaceparametre til fjernkommunikation  
5.3.1 Lokaliseringsbegrænsninger  
5.3.2 Downlink- og uplink-parametre  
5.3.3 Antennedesign  
5.4 DSRC-protokolkrav til RTM  
5.4.1 Oversigt  
5.4.2 Kommandoer  
5.4.3 Kommandosekvens ved anmodning  
5.4.4 Datastrukturer  
5.4.5 Elementer af RtmData, udførte handlinger og definitioner  
5.4.6 Dataoverførselsmekanisme  
5.4.7 Detaljeret DSRC-transaktionsbeskrivelse  
5.4.8 Beskrivelse af DSRC-afprøvningstransaktion  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 535  
5.5 Forbeholdt fremtidig brug  
▼B 
5.6 Dataoverførsel mellem DSRC-køretøjsenheden og køretøjsenhed en 
5.6.1 Fysisk forbindelse og interfaces  
5.6.2 Applikationsprotokol  
5.7 Fejlhåndtering  
5.7.1 Registrering og kommunikation af data i DSRC-køretøjsenhe den 
5.7.2 Fejl i trådløs kommunikation  
6 IDRIFTSÆTTELSE OG PERIODISKE INSPEKTIONSAFPRØV­ 
NINGER FOR FJERNKOMMUNIKATIONSFUNKTIONEN  
6.1 Generelt  
6.2 ECHO  
6.3 Afprøvning til validering af sikkert dataindhold  
1 INDLEDNING  
I dette tillæg specificeres den udformning og de procedurer, de r skal 
følges for at gennemføre fjernkommunikationsfunktionen (kommuni ka­
tionen) i henhold til kravet i artikel 9 i forordning (EU) nr. 165/2014 
(forordningen).  
DSC_1 I forordning (EU) nr. 165/2014 bestemmes det, at takograf en 
skal være udstyret med en fjernkommunikationsfunktion, der 
giver repræsentanter for de kompetente kontrolmyndigheder 
mulighed for at aflæse takografoplysninger fra forbipasserende 
køretøjer ved hjælp fjernaflæsningsudstyr (læser i udstyr til 
tidlig fjernafsløring [REDCR]), navnlig anmodningsudstyr, 
der tilsluttes trådløst med CEN 5,8 GHz Dedicated Short 
Range Communication-interfaces (DSRC-interfaces).  
Det er vigtigt at forstå, at formålet med denne funktion udeluk ­
kende er, at den skal fungere som et foreløbigt filter til udvæ l­
gelse af køretøjer til nærmere inspektion, og at den ikke træde r 
i stedet for den formelle inspektionsproces som fastlagt i 
bestemmelserne i forordning (EU) 165/2014. Se betragtning 
9 i præamblen til denne forordning, hvori det hedder, at fjern­
kommunikation mellem takografen og kontrolmyndighederne 
med henblik på vejkontrol letter målrettede vejkontroller.  
DSC_2  Dataene  udveksles ved hjælp af  kommunikationen , som skal 
være en trådløs forbindelse, der benytter 5,8 GHz DSRC 
trådløs kommunikation, der er i overensstemmelse med 
dette tillæg og er afprøvet i forhold til de relevante parametr e 
i EN 300 674-1, {Electromagnetic compatibility and Radio  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 536  
spectrum Matters (ERM); Road Transport and Traffic Telema­
tics (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  Kommunikationen  etableres kun med kommunikationsudstyret, 
når der kommer en anmodning fra den kompetente kontrol­
myndigheds udstyr ved hjælp af godkendte radiokommunika­
tionsmetoder ( læseren i udstyr til tidlig fjernafsløring 
(REDCR) ). 
DSC_4  Dataene  skal sikres for at garantere deres integritet.  
DSC_5 Adgang til de kommunikerede  data  begrænses til kontrolmyn­
digheder, der er bemyndiget til at kontrollere overtrædelser af  
forordning (EF) nr. 561/2006 og af forordning (EU) 
nr. 165/2014 og til værksteder, for så vidt det er nødvendigt 
at kontrollere takografens korrekte funktion.  
DSC_6  Data , som udveksles i forbindelse med  kommunikationen , 
begrænses til de data, der er nødvendige af hensyn til de 
målrettede vejkontroller af køretøjer med en potentielt mani­
puleret eller misbrugt takograf.  
DSC_7 Dataintegritet og -sikkerhed opnås ved at sikre  dataene  inde i 
køretøjsenheden (VU) og ved kun at overføre de sikrede 
indholds data og sikkerhedsrelaterede data (se 5.4.4) over det 
trådløse 5,8 GHz DSRC-fjernkommunikationsmedium, hvilket 
betyder, at kun godkendte personer fra de kompetente kontrol­
myndigheder har mulighed for at forstå de data, der overføres 
via kommunikationen , og for at verificere deres ægthed. Se 
tillæg 11, Fælles sikkerhedsmekanismer.  
DSC_8  Dataene  indeholder et tidsstempel med tidspunktet for deres 
seneste ajourføring.  
DSC_9 Indholdet af sikkerhedsdataene skal udelukkende være kend t af 
de kompetente kontrolmyndigheder og være inden for deres 
kontrol samt de parter, som de deler disse oplysninger med, og 
ligger uden for bestemmelserne for  kommunikationen , der er 
genstand for dette tillæg, bortset fra, at  kommunikationen  giver 
mulighed for at overføre en pakke med sikkerhedsdata med 
hver pakke indholdsdata.  
DSC_10 Den samme arkitektur og det samme udstyr skal være i sta nd 
til at hente andre datakoncepter (såsom weigh-on-board) ved 
hjælp af den heri angivne arkitektur.  
DSC_11 Det skal præciseres, at i overensstemmelse med bestemmel ­
serne of forordning (EU) nr. 165/2014 (artikel 7) må data 
vedrørende førerens identitet ikke transmitteres over  kommuni ­
kationen . 
2 ANVENDELSESOMRÅDE  
Formålet med dette tillæg er at angive, hvordan repræsentanter for de 
kompetente kontrolmyndigheder anvender en bestemt 5,8 GHz DSRC 
trådløs kommunikation til at opnå fjernadgang til data ( dataene ) fra et  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 537  
bestemt køretøj, der angiver, at det pågældende køretøj har ove rtrådt 
forordning (EU) 165/2014 og bør tages i betragtning med henblik  på 
standsning for en nærmere undersøgelse.  
I forordning (EU) nr. 165/2014 kræves det, at de indsamlede dat a kun 
må være data eller vedrøre data, der angiver en mulig overtræde lse 
begået af en af de registrerede, der er omfattet af forordning (EU) 
nr. 165/2014.  
▼M1 
I dette scenario er der kun begrænset tid til rådighed til komm unikation, 
fordi  kommunikationen  er målrettet og har kort rækkevidde. Desuden 
kan de kompetente kontrolmyndigheder anvende de samme kommuni­
kationsmidler til fjernovervågning af takografer (RTM) til andr e formål 
(såsom de største tilladte dimensioner og den største tilladte vægt for 
tunge varekøretøjer, som defineret i direktiv (EU) 2015/719), o g sådanne 
operationer kan være separate eller sekventielle alt efter de k ompetente 
kontrolmyndigheders valg.  
▼B 
I dette tillæg specificeres:  
— Kommunikationsudstyr, -procedurer og -protokoller, der skal 
benyttes til  kommunikationen  
— Standarder og forordninger, som radioudstyret skal overholde  
— Præsentationen af  dataene  for kommunikations udstyret  
— Anmodnings- og dataoverførselsprocedurer og operationernes ræ kke­
følge  
— Dataene , der skal overføres  
— Potentiel fortolkning af  dataene , der overføres via  kommunikationen  
— Bestemmelserne for sikkerhedsdata vedrørende  kommunikationen  
— De kompetente kontrolmyndigheders adgang til  dataene  
— Hvordan  læseren i udstyr til tidlig fjernafsløring  kan anmode om 
forskellige koncepter for last- og flådedata  
Det skal præciseres, at følgende  ikke specificeres i dette tillæg:  
— Indsamling af dataene og håndtering af disse i køretøjsenhede n (som 
er en funktion af produktdesignet, medmindre det specificeres a ndet­
steds i forordning (EU) nr. 165/2014)  
— Formen af præsentationen af de indsamlede data for repræsenta nten 
for de kompetente kontrolmyndigheder eller de kriterier, som de  
kompetente kontrolmyndigheder skal anvende til at beslutte, hvi lke 
køretøjer de vil standse (dette skal være en funktion af produk tde­
signet, medmindre det angives andetsteds i forordning (EU) 
165/2014, eller en politisk beslutning truffet af de kompetente  
kontrolmyndigheder). Det præciseres, at:  Kommunikationen  kun 
gør dataene  tilgængelige for de kompetente kontrolmyndigheder, 
således at  de kan træffe beslutninger på et velinformeret grundlag  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 538  
— Datasikkerhedsbestemmelser (såsom kryptering) for så vidt ang år 
indholdet af  dataene  (som angives i tillæg 11, Fælles sikkerheds­
mekanismer).  
— Nærmere oplysninger og andre datakoncepter end RTM, som kan 
opnås ved hjælp af den samme arkitektur og det samme udstyr  
— Nærmere oplysninger om adfærden og administrationen mellem 
køretøjsenheder og DSRC-køretøjsenheden og ej heller adfærden 
inden for DSRC-køretøjsenheden (ud over at stille  dataene  til 
rådighed, når en REDCR anmoder om dette).  
3 AKRONYMER, DEFINITIONER OG NOTATION  
Følgende akronymer og definitioner, der er specifikke for dette  tillæg, 
anvendes i tillægget:  
Antennen  elektrisk enhed, der omdanner elek­
trisk strøm til radiobølger og 
omvendt, når den bruges sammen 
med en radiosender eller radiomod­
tager. Under drift leverer en radio­
sender elektrisk strøm, der svinger i 
radiofrekvens, til antennens termi­
naler, og antennen udstråler energi 
fra strømmen i form af elektromag­
netiske bølger (radiobølger). Ved 
modtagelsen fanger antennen noget 
af effekten i en elektromagnetisk 
bølge og frembringer en svag spæn­
ding ved sine terminaler, som sendes 
videre til en modtager for at blive 
forstærket  
Kommunikationen  udveksling af information/data 
mellem en  DSRC-REDCR  og en 
DSRC-køretøjsenhed i henhold til 
afsnit 5 i et master-slave-forhold for 
at modtage  dataene . 
Dataene  sikre data i et defineret format (se 
5.4.4), som  DSRC-REDCR'en  
anmoder om, og som leveres til  
DSRC-REDCR'en  a f DSRC-køretøjs ­
enheden  via en 5,8 GHz DSRC- 
forbindelse som defineret i 5 
nedenfor  
Forordning (EF) nr. 165/2014  Europa-Parlamentets og Rådets forord­
ning (EU) nr.165/2014 af 4. februar 
2014 om takografer inden for vejtrans­
port, som ophævede Rådets forord­
ning (EØF) nr. 3821/85 om kontrol­
apparatet inden for vejtransport og  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 539  
ændrede Europa-Parlamentets og 
Rådets forordning (EF) nr. 561/2006 
om harmonisering af visse bestem­
melser på det sociale område inden 
for vejtransport  
AID Applikationsnavn  
BLE  Bluetooth Low Energy  
BST  Beacon Service Table  
CIWD  Isætning af kort under kørsel  
CRC  Cyklisk redundanskontrol  
DSC (n)  Identifikator for et krav om et speci­
fikt DSRC-tillæg  
DSRC  Dedicated Short Range Communica­
tion 
DSRC-REDCR  DSRC-læser i udstyr til tidlig fjern­
afsløring.  
DSRC-VU  DSRC-køretøjsenhed. Dette er 
»udstyret til tidlig fjernafsløring«, 
som defineres i bilag 1C.  
DWVC  Kørsel uden gyldigt kort  
EID Elementidentifikator  
LLC  Logical Link Control  
LPDU  LLC-dataenhedsprotokol  
OWS  Vejesystem om bord  
PDU  Protokoldataenhed  
REDCR  Læser i udstyr til tidlig fjernafsløring, 
som defineret i bilag 1C.  
RTM  Fjernovervågning af takograf  
SM-REDCR  Sikkerhedsmodul i læser i udstyr til 
tidlig fjernafsløring  
TARV  Telematics Applications for Regu­
lated Vehicles (ISO 15638-standard­
serien)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 540  
VU Køretøjsenhed  
VUPM  Indholdshukommelse i køretøjsenhed  
VUSM  Sikkerhedsmodul i køretøjsenhed  
VST  Servicetabel for køretøj  
WIM  Weigh in motion  
WOB  Weigh on board  
Den specifikation, som fastlægges i dette tillæg, henviser til og er 
baseret på følgende forordninger og standarder, enten helt elle r delvist. 
I bestemmelserne i dette tillæg angives de relevante standarder  eller de 
relevante bestemmelser i standarderne. Hvis der er modstrid mel lem 
kravene, har bestemmelserne i dette tillæg forrang. Hvis der er  tale 
om modstridende bestemmelser, når der ikke entydigt er fastlagt  
nogen specifikation i dette tillæg, skal drift i henhold til ER C 70-03 
(efter afprøvning i forhold til de relevante parametre i EN 300  674-1) 
have forrang efterfulgt af EN 12795, EN 12253 EN 12834 og EN 
13372, 6.2, 6.3, 6.4 og 7.1 i faldende betydningsrækkefølge.  
I dette tillæg henvises der til følgende forordninger og standa rder:  
[1] I forordning (EU) nr. Rådets forordning (EU) nr.165/2014 af  
4. februar 2014 om takografer inden for vejtransport, som ophæ­
vede Rådets forordning (EØF) nr. 3821/85 om kontrolapparatet 
inden for vejtransport og ændrede Europa-Parlamentets og Rådets  
forordning (EF) nr. 561/2006 om harmonisering af visse bestem­
melser på det sociale område inden for vejtransport  
[2] Europa-Parlamentets og Rådets forordning (EF) nr. 561/2006 af 
15. marts 2006 om harmonisering af visse bestemmelser på det 
sociale område inden for vejtransport og om ændring af Rådets 
forordning (EØF) nr. 3821/85 og (EF) nr. 2135/98 og om ophæ­
velse af Rådets forordning (EØF) nr. 3820/85 (EØS-relevant teks t). 
[3] ERC 70-03 CEPT: ECC Recommendation 70-03: Relating to the 
Use of Short Range Devices (SRD)  
[4] ISO 15638-9 Intelligent transport systems — Framework for 
cooperative telematics applications for regulated commercial 
freight vehicles (TARV).  
[5] EN 300 674-1 Electromagnetic compatibility and Radio spectr um 
Matters (ERM); Road Transport and Traffic Telematics (RTTT); 
Dedicated Short Range Communication (DSRC) transmission 
equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz In du­
strial, Scientific and Medical (ISM) band; Part 1: General char ac­
teristics and test methods for Road Side Units (RSU) and On-Boa rd 
Units (OBU).  
[6] EN 12253 Road transport and traffic telematics — Dedicated 
short-range communication — Physical layer using microwave at 
5.8 GHz.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 541  
[7] EN 12795 Road transport and traffic telematics — Dedicated 
short-range communication — Data link layer: medium access 
and logical link control.  
[8] EN 12834 Road transport and traffic telematics — Dedicated 
short-range communication — Application layer.  
[9] EN 13372 Road transport and traffic telematics — Dedicated 
short-range communication — Profiles for RTTT applications  
[10] ISO 14906 Electronic fee collection — Application interfac e defi­
nition for dedicated short-range communication  
4 DRIFTSSCENARIER  
4.1 Oversigt  
Forordning (EU) nr. 165/2014 indeholder specifikke og kontrolle rede 
scenarier, inden for hvilke  kommunikationen  skal anvendes.  
Følgende scenarier er understøttet:  
»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: via a hand aimed or temporary roadside mounted 
and aimed Remote Early Detection Communication  
Reader Profile 1b: via a vehicle mounted and directed Remote Early 
Detection Communication Reader«.  
4.1.1  Forudsætninger for dataoverførsel via 5,8 GHz DSRC-interface  
BEMÆRK: For at forstå indholdet af forudsætningerne henvises læ seren 
til figur 14.3 herunder.  
4.1.1.1 Data lagret i køretøjsenheden  
DSC_12 Køretøjsenheden er ansvarlig for at ajourføre data, der skal 
gemmes i køretøjsenheden, hvert 60. sekund og vedligeholde 
dem, uden at DSRC-kommunikationsfunktionen involveres. 
Metoderne, som skal anvendes til dette, er indbygget i køre­
tøjsenheden som specificeret i forordning (EU) nr. 165/2014, 
bilag 1 C, afsnit 3.19 » Fjernkommunikation til målrettede 
vejkontroller « og specificeres ikke i dette tillæg.  
4.1.1.2 Data leveret til DSRC-køretøjsenheden  
DSC_13 Køretøjsenheden er ansvarlig for at ajourføre DSRC-takog raf­
dataene ( dataene ), når de data, der er lagret i køretøjsenheden, 
ajourføres med det i 4.1.1.1 (DSC_12) fastsatte interval uden 
at inddrage DSRC-kommunikationsfunktionen.  
DSC_14 Dataene fra køretøjsenheden bruges som input og til at a jour­
føre dataene , og metoderne til dette angives i bilag 1C, afsnit 
3.19 » Fjernkommunikation til målrettede vejkontroller «. Alter­
nativt, hvis der ikke findes en sådan angivelse, er det en del af 
produktdesignet og angives ikke i dette tillæg. For så vidt 
angår udformningen af forbindelsen mellem DSRC-køretøjs­
enheden og køretøjsenheden henvises til afsnit 5.6.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 542  
4.1.1.3 Dataenes indhold  
DSC_15  Dataenes  indhold og format betyder, at de, når de er dekryp­
terede, skal være strukturerede og tilgængelige i den form og 
det format, der specificeres i 5.4.4 i dette tillæg (Datastruk­
turer).  
4.1.1.4 Præsentation af data  
DSC_16  Dataene  er blevet ajourført hyppigt i overensstemmelse med 
procedurerne i 4.1.1.1 og skal sikres forud for præsentationen 
for DSRC-køretøjsenheden og skal præsenteres som en sikret 
datakonceptværdi til midlertidig lagring i DSRC-køretøjs­
enheden som den aktuelle version af  dataene . Disse data over­
føres fra  VUSM  til DSRC-funktionen  VUPM . VUSM  o g 
VUPM  er funktioner og ikke nødvendigvis fysiske enheder. 
Den fysiske enhed, der anvendes til at udføre disse funktioner,  
fastlægges i henhold til produktdesign, medmindre den speci­
ficeres andetsteds i forordning (EU) nr. 165/2014.  
4.1.1.5 Sikkerhedsdata  
▼M3 
DSC_17 Sikkerhedsdata ( DSRCSecurityData) , der omfatter de data, 
som REDCR  behøver for at kunne dekryptere  dataene , 
leveres som defineret i tillæg 11, Fælles sikkerhedsmeka­
nismer, til midlertidig opbevaring i  DSRC-køretøjsenheden  
som den nuværende version af  DSRCSecurityData  i den 
form, der er fastlagt i afsnit 5.4.4 i dette tillæg.  
▼B 
4.1.1.6 VUPM-data, der er tilgængelige for overførsel via DSRC- interfacet  
DSC_18 Datakonceptet, som altid skal være tilgængeligt i DSRC-f unk­
tionen VUPM til umiddelbar overførsel efter anmodning fra 
REDCR'en, er som defineret i afsnit 5.4.4 med de fuldstæn­
dige specifikationer for ASN.1-modulet.  
Generel oversigt over kommunikationsprofil 1  
Denne profil omfatter brugssituationen, hvor repræsentanten for  de 
kompetente kontrolmyndigheder benytter en fjernkommunikationsen hed 
med kort rækkevidde som læser i udstyr til tidlig fjernafslørin g (5,8 GHz 
DSRC-interfaces, der fungerer inden for ERC 70-03, og som er af prøvet 
i forhold til de relevante parametre i EN 300 674-1 som beskrev et i 
afsnit 5) ( REDCR'en ) med henblik på fjernidentifikation af et køretøj, 
der muligvis overtræder forordning (EU) nr. 165/2014. Når køret øjet er 
identificeret, beslutter repræsentanten for de kompetente kontr olmyndig­
heder, som kontrollerer anmodningen, hvorvidt køretøjet skal st andses.  
4.1.2  Profil 1a: via en håndholdt eller midlertidig vejsidemonteret læser i 
udstyr til tidlig fjernafsløring  
I denne brugssituation befinder repræsentanten for de kompetent e 
kontrolmyndigheder sig ved vejsiden og retter en  REDCR , der er hånd­
holdt, monteret på en trefod eller en tilsvarende type, fra vej siden mod 
midten af det udvalgte køretøjs forrude. Anmodningen gennemføre s ved 
hjælp af 5,8 GHz DSRC-interfaces, der opererer inden for ERC 70 -03, 
og som er afprøvet i forhold til de relevante parametre i 300 6 74-1 som 
beskrevet i afsnit 5. Se figur 14.1 (Brugssituation 1).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 543  
Figur 14.1  
Vejsideanmodning ved hjælp af 5,8 GHz DSRC
  
4.1.3  Profil 1b: via en køretøjsmonteret og dirigeret læser i udstyr til tidlig 
fjernafsløring.  
I denne brugssituation befinder repræsentanten for de kompetent e 
kontrolmyndigheder sig i et køretøj i bevægelse og retter enten  en hånd­
holdt, bærbar  REDCR  fra køretøjet imod midten af det udvalgte køretøjs 
forrude, eller også er  REDCR'en  monteret i eller på køretøjet, så den 
peger mod midten af forruden på det kontrollerede køretøj, når køretøjet 
med læseren i udstyr til tidlig fjernafsløring befinder sig i e n bestemt 
position i forhold til det udvalgte køretøj (f.eks. direkte for an i en trafik­
strøm). Anmodningen gennemføres ved hjælp af 5,8 GHz DSRC-inter ­
faces, der opererer inden for ERC 70-03, og som er afprøvet i f orhold til 
de relevante parametre i 300 674-1 som beskrevet i afsnit 5. Se  figur 
14.2. (Brugssituation 2).  
Figur 14.2  
Køretøjsbaseret anmodning ved hjælp af 5,8 GHz DSRC
  
4.2 Sikkerhed/integritet  
For at man skal kunne fastslå ægtheden og integriteten af data,  der er 
overført via fjernkommunikation, verificeres og dekrypteres de sikrede  
data i overensstemmelse med tillæg 11, Fælles sikkerhedsmekanismer.  
5 DESIGN OG PROTOKOLLER TIL FJERNKOMMUNIKATION  
5.1 Design  
Designet af fjernkommunikationsfunktionen i den intelligente ta kograf 
beskrives i figur 14.3.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 544  
Figur 14.3  
Design af fjernkommunikationsfunktionen
  
DSC_19 Følgende funktioner er placeret i køretøjsenheden:  
— Sikkerhedsmodulet ( VUSM ). Denne funktion i køretøjs­
enheden er ansvarlig for at sikre  de data , som skal over­
føres fra DSRC-køretøjsenheden til repræsentanten for de 
kompetente kontrolmyndigheder via fjernkommunikation.  
— De sikrede data gemmes i VUSM-hukommelsen. Med de 
intervaller, der fastlægges i 4.1.1.1 (DSC_12), krypterer 
køretøjsenheden dataene og leverer input til RTM-datakon­
ceptet (som omfatter datakonceptværdier for indholdsdata 
og sikkerhedsdata som fastlagt nedenfor i dette tillæg), 
som ligger i DSRC-køretøjsenhedens hukommelse. Sikker­
hedsmodulets funktion fastlægges i tillæg 11, Fælles 
sikkerhedsmekanismer, og ligger uden for dette tillægs 
dækningsområde, bortset fra at det skal levere ajour­
føringer til køretøjsenhedens kommunikationsenhed, hver 
gang VUSM-dataene ændrer sig.  
— Kommunikationen mellem køretøjsenheden og DSRC- 
køretøjsenheden kan foregå via et kabel eller Bluetooth 
Low Energy-kommunikation (BLE-kommunikation), og 
DSRC-køretøjsenhedens fysiske placering kan være 
bygget sammen med antennen ved køretøjets forrude, 
være indbygget i køretøjsenheden eller være placeret et 
sted imellem disse.  
— DSRC-køretøjsenheden skal til enhver tid have en pålidelig 
strømforsyning. Strømforsyningsmetoden fastlægges i 
designfasen.  
— DSRC-køretøjsenhedens hukommelse skal være ikke- 
flygtig for at kunne gemme dataene i DSRC-køretøjs­
enheden, selv når køretøjets tænding er slået fra.  
— Hvis kommunikationen mellem køretøjsenheden og 
DSRC-køretøjsenheden foregår via BLE, og strømfor­
syningen er et ikkegenopladeligt batteri, skal DSRC-køre­
tøjsenhedens strømforsyning udskiftes ved hver periodisk  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 545  
inspektion, og fabrikanten af udstyret til DSRC-køretøjs­
enheden er ansvarlig for at sikre, at strømforsyningen er 
tilstrækkelig til at holde fra den ene periodiske inspektion 
til den næste, idet en REDCR skal have normal adgang til 
dataene igennem hele perioden uden fejl eller afbrydelser.  
— Køretøjsenhedens RTM-funktion »indholdshukommelse« 
(VUPM ). Denne funktion i køretøjsenheden er ansvarlig 
for at levere og ajourføre  dataene . Indholdet af  dataene . 
(»TachographPayload«) defineres i 5.4.4/5.4.5 nedenfor og 
ajourføres med det interval, der fastlægges i 4.1.1.1 
(DSC_12).  
— DSRC-køretøjsenhed. Dette er den funktion, der er 
indbygget i eller tilsluttet antennen og er i kommunikation 
med køretøjsenheden via en kablet eller trådløs (BLE) 
forbindelse, og som indeholder de aktuelle data ( VUPM- 
data) og forvalter svaret på en anmodning via 5,8 GHz 
DSRC-mediet. Afbrydelse af DSRC-enheden eller inter­
ferens med DSRC-enhedens funktion under køretøjets 
normale drift betragtes som en overtrædelse af forordning 
(EU) 165/2014.  
— Sikkerhedsmodulet (REDCR) ( SM-REDCR ) er den funk­
tion, der anvendes til at dekryptere og kontrollere integri­
teten af dataene, der kommer fra køretøjsenheden. Meto­
derne til at opnå dette fastlægges i tillæg 11, Fælles sikker­
hedsmekanismer, og defineres ikke i dette tillæg.  
— DSRC-enhedens (REDCR) ( DSRC-REDCR ) funktion 
omfatter en 5,8 GHz sender/modtager og tilhørende firm­
ware og software, der administrerer  kommunikationen 
DSRC-køretøjsenheden  i overensstemmelse med dette 
tillæg.  
— DSRC-REDCR  forespørger DSRC-køretøjsenheden i det 
udvalgte køretøj og modtager  dataene  (det udvalgte køre­
tøjs aktuelle  VUPM-data ) via DSRC-forbindelsen og 
behandler og gemmer de modtagne data i sin  SM-REDCR . 
▼M1 
— DSRC-køretøjsenhedens antenne skal være anbragt i en 
position, hvor den optimerer DSRC-kommuniktionen 
mellem køretøjet og antennen i vejsiden, når denne er 
anbragt 15 m foran køretøjet og i 2 meters højde, rettet 
mod det horisontale og vertikale midtpunkt af køretøjets 
forrude. For lette køretøjer er montering svarende til den 
øverste del af frontruden hensigtsmæssig. For alle andre 
installeres DSRC-antennen enten nær den nedre eller den 
øvre del af forruden.  
▼B 
DSC_20 Antennen og kommunikationen opererer inden for ERC 70-03  
og er afprøvet i forhold til de relevante parametre i 300 674-1  
som beskrevet i afsnit 5. Antennen og kommunikationen kan 
anvende teknikker til at afhjælpe risikoen for interferens af d et 
trådløse signal som beskrevet i ECC-rapport 228, f.eks. ved 
brug af filtre i CEN DSRC 5,8 GHz-kommunikationen.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 546  
DSC_21 DSRC-antennen tilsluttes DSRC-køretøjsenheden enten dire kte 
inde i modulet, der er monteret på eller i nærheden af 
forruden, eller via et dedikeret kabel, der er konstrueret på 
en sådan måde, at en ulovlig afbrydelse er vanskelig. Afbry­
delse af eller interferens med antennens funktion betragtes som  
en overtrædelse af forordning (EU) nr. 165/2014. Bevidst 
maskering af eller andre former for forstyrrelse af antennens 
drift betragtes som en overtrædelse af forordning (EU) 
nr. 165/2014.  
DSC_22  ►M1 Antennens formfaktor defineres ikke og er genstand for 
en kommerciel beslutning, når blot den monterede 
DSRC-køretøjsenhed opfylder overensstemmelseskravene som 
defineret i afsnit 5 nedenfor. Antennen skal monteres som 
fastsat i krav DSC_19 og effektivt understøtte de anvendelses­
situationer, der beskrives i afsnit 4.1.2 og 4.1.3. ◄  
Figur 14.4  
Eksempel på placering af 5,8 GHz DSRC-antennen i forruden af 
regulerede køretøjer
  
REDCR'ens  og dens antennes formfaktor kan variere i henhold til 
omstændighederne for læseren (monteret på trefod, håndholdt, kø retøjs­
monteret osv.) og den metode, som anvendes af repræsentanten fo r de 
kompetente kontrolmyndigheder.  
Et display og/eller en meddelelsesfunktion benyttes til at præs entere 
resultaterne af fjernkommunikationsfunktionen for repræsentante n for 
de kompetente kontrolmyndigheder. Et display kan have form af e n 
skærm, en udskrift, et lydsignal eller en kombination af sådann e medde­
lelser. Formen af et sådant display og/eller meddelelser fastlæ gges i 
henhold til kravene fra repræsentanterne for de kompetente kont rolmyn­
digheder og udstyrsdesignet og angives ikke i dette tillæg.  
DSC_23 REDCR'ens design og formfaktor fastlægges af det kommer­
cielle design, driftskravene i ERC 70-03 samt design- og 
præstationsspecifikationerne i dette tillæg (afsnit 5.3.2), 
således at markedet gives maksimal fleksibilitet til at designe  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 547  
og levere udstyr, der kan opfylde de specifikke behov 
for anmodninger hos en given kompetent kontrolmyndighed.  
DSC_24  DSRC-køretøjsenheden  og dens placering inde i eller uden for 
køretøjsenheden afhænger af det kommercielle design, drifts­
kravene i ERC 70-03 samt de design- og præstationsspecifika­
tioner, der defineres i dette tillæg (afsnit 5.3.2) og i denne 
bestemmelse (5.1).  
DSC_25  DSRC-køretøjsenheden  skal imidlertid inden for rimelige 
grænser være i stand til at modtage datakonceptværdier fra 
andet intelligent køretøjsudstyr ved hjælp af en open 
industry-standardforbindelse og protokoller (f.eks. fra weigh 
on board-udstyr), så længe disse datakoncepter identificeres 
med entydige og kendte applikationsidentifikatorer/filnavne, 
og instruktionen om at anvende sådanne protokoller skal 
stilles til rådighed for Kommissionen og uden beregning for 
fabrikanter af relevant udstyr.  
5.2 Arbejdsgang  
5.2.1  Drift  
Arbejdsgangen for driften fremgår af figur 14.5.  
Figur 14.5  
Arbejdsgang for fjernkommunikationsfunktionen
  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 548  
Trinnene beskrives i det følgende:  
a. Så snart køretøjet er i drift (tænding TIL), leverer takogra fen data til 
køretøjsenhedsfunktionen. Køretøjsenhedsfunktionen forbereder  
dataene  til fjernkommunikationsfunktionen (krypteret) og ajourfører  
VUPM , der ligger i DSRC-køretøjsenhedens hukommelse (som defi­
neret i 4.1.1.1-4.1.1.2). De indsamlede  Data  formateres som angivet i 
5.4.4-5.4.5 nedenfor.  
b. Hver gang  dataene  ajourføres, skal tidsstemplet, som defineres i 
sikkerhedsdatakonceptet, ajourføres.  
c. VUSM -funktionen sikrer dataene i overensstemmelse med procedu­
rerne i tillæg 11.  
d. Hver gang  dataene  ajourføres (se 4.1.1.1-4.1.1.2), overføres  dataene  
til DSRC-køretøjsenheden, hvor de erstatter eventuelle tidliger e data, 
således at de ajourførte aktuelle data ( dataene ) altid vil være tilgæn­
gelige, hvis der indkommer en anmodning fra en  REDCR . Når køre­
tøjsenheden leverer  dataene  til DSRC-køretøjsenheden, skal de 
kunne identificeres med filnavnet  RTMData  eller med identifikato­
rerne ApplicationID og Attribute.  
e. Hvis en repræsentant for de kompetente kontrolmyndigheder øn sker 
at kontrollere et køretøj og indsamle  dataene  fra det udvalgte køretøj, 
skal repræsentanten for de kompetente kontrolmyndigheder først 
isætte sit smartcard i  REDCR'en  for at give mulighed for  kommuni ­
kationen  og give  SM-REDCR'en  mulighed for at verificere dets 
ægthed og kryptere dataene.  
f. Repræsentanten for den kompetente kontrolmyndighed udvælger 
herefter et køretøj og anmoder om dataene via fjernkommunikatio n. 
REDCR'en  indleder en 5,8 GHz DSRC-interfacesession med  DSRC- 
køretøjsenheden  for det udvalgte køretøj og anmoder om  dataene . 
Dataene  overføres til  REDCR'en  via det trådløse kommunikations­
system som en DSRC-attribut ved hjælp af applikationstjenesten 
GET som defineret i 5.4. Attributten indeholder de krypterede 
indholdsdataværdier og DSRC-sikkerhedsdataene.  
g. Dataene analyseres af  REDCR -udstyret og leveres til repræsentanten 
for den kompetente kontrolmyndighed.  
h. Repræsentanten for den kompetente kontrolmyndighed anvender 
dataene som en del af beslutningen om, hvorvidt køretøjet skal 
standses med henblik på en detaljeret inspektion, eller om en 
anden repræsentant for den kompetente kontrolmyndighed skal 
anmodes om at standse køretøjet.  
5.2.2  Fortolkning af data modtaget via DSRC-kommunikationen  
DSC_26 Data, der modtages over 5.8 GHz-interfacet har alene den  
betydning og vægt, der defineres i 5.4.4 og 5.4.5 nedenfor 
og skal forstås inden for de deri definerede formål. I over­
ensstemmelse med bestemmelserne of forordning (EU) 
nr. 165/2014 må  dataene  udelukkende bruges til at stille  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 549  
relevante oplysninger til rådighed for en kompetent kontrol­
myndighed med henblik på at hjælpe disse med at afgøre, 
hvilke køretøjer der skal standses med henblik på fysisk 
inspektion, og skal efterfølgende destrueres i overensstem­
melse med artikel 9 i forordning (EU) nr. 165/2014.  
5.3 Fysiske DSRC-interfaceparametre til fjernkommunikation  
5.3.1  Lokaliseringsbegrænsninger  
DSC_27 Fjernanmodninger til køretøjer ved hjælp af et 5,8 GHz 
DSRC-interface bør ikke anvendes nærmere end 200 meter 
fra en operationel 5,8 GHz DSRC-bro.  
5.3.2  Downlink- og uplink-parametre  
DSC_28 Udstyret til fjernaflæsning af takografer skal være i ov erens­
stemmelse med og fungere inden for ERC70-03 samt de para­
metre, der defineres i tabel 14.1 og 14.2 nedenfor.  
DSC_29 Med henblik på at sikre kompatibilitet med driftsparamet rene 
for andre standardiserede 5,8 GHz DSRC-systemer gælder det 
endvidere, at det udstyr, der benyttes til fjernaflæsning af 
takografer, skal være i overensstemmelse med parametrene i 
EN 12253 og EN 13372.  
Det gælder navnlig:  
Tabel 14.1  
Downlinkparametre  
Punkt nr.  Parameter  Værdi(er)  Bemærkning  
D1 Downlink-bærefrekvenser  Der findes fire alternativer, 
som en REDCR kan 
benytte: 
5,7975 GHz 
5,8025 GHz 
5,8075 GHz 
5,8125 GHz  Inden for ERC 70-03. 
Bærefrekvenser vælges af 
montøren af systemet ved vejsiden 
og behøver ikke være kendt af 
DSRC-køretøjsenheden 
(Overholder EN 12253, EN 13372)  
D1a (*) Bærefrekvensernes 
tolerance:  inden for ± 5 ppm  (Overholder EN 12253)  
D2 (*) RSU (REDCR) Spektral­
maske for transmitter  Inden for ERC 70-03. 
REDCR'en skal være i 
overensstemmelse med 
Class B,C som defineret i 
EN 12253. 
Ingen andre specifikke krav 
i dette bilag  Parameter, der benyttes til at 
kontrollere interferens mellem 
interrogatorer i nærheden (som 
defineret i EN 12253 og EN 
13372).  
D3 OBU(DSRC-VU) Minimum 
frekvensinterval  5,795-5,815 GHz  (Overholder EN 12253)  
D4 (*) Maksimum E.I.R.P.  Inden for ERC 70-03 (uden 
tilladelse) og inden for de 
nationale bestemmelser 
Maksimum +33 dBm  (Overholder EN 12253)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 550  
Punkt nr.  Parameter  Værdi(er)  Bemærkning  
D4a Vinklet E.I.R.P.-maske  I henhold til den indberet­
tede og offentliggjorte 
specifikation fra designeren 
af interrogatoren  (Overholder EN 12253)  
D5 Polarisering  Venstre, cirkulær  (I overensstemmelse med EN 
12253)  
D5a Krydspolarisering  XPD: 
I boresigte: (REDCR) RSU 
t ≥15 dB 
(DSRC-VU) OBU r≥ 10 dB 
I -3 dB-området: (REDCR) 
RSU t ≥ 10 dB 
(DSRC-VU) OBU r ≥ 6 dB  (Overholder EN 12253)  
D6 (*) Modulation  Amplitudemodulation i to 
niveauer.  (Overholder EN 12253)  
D6a (*) Modulationsindeks  0,5 … 0,9  (Overholder EN 12253)  
D6b Øjenmønster  ≥ 90 % (tid) / ≥ 85 % 
(amplitude)  
D7 (*) Datakodning  FM0 
»1«-bit'en har kun tran­
sitioner ved begyndelsen 
og slutningen af bitinter­
vallet. »0«-bit'en har en 
yderligere transition i 
midten af bitintervallet 
sammenlignet med »1«- 
bit'en.  (Overholder EN 12253)  
D8 (*) Bithastighed  500 kBit/s  (Overholder EN 12253)  
D8a Bit-klokkens tolerance  bedre end ± 100 ppm  (Overholder EN 12253)  
D9 (*) Bitfejlrate (B.E.R.) for 
kommunikation  ≤10  – 6 , når den indfaldende 
effekt ved OBU (DSRC- 
VU) ligger i det interval, 
der er givet ved [D11a til 
D11b].  (Overholder EN 12253)  
D10 Start-trigger til OBU 
(DSRC-køretøjsenhed)  OBU (DSRC-køretøjs­
enheden) skal starte op ved 
modtagelse af en hvilken 
som helst ramme med 11 
oktetter eller derover (inklu­
sive præambel)  Der kræves intet særligt startmøn­
ster. 
DSRC-køretøjsenheden kan starte 
op ved modtagelse af en ramme 
med mindre end 11 oktetter 
(Overholder EN 12253)  
D10a  Maksimal opstartstid  ≤  5  m s  (Overholder EN 12253)  
D11 Kommunikationszone  Region, inden for hvilken 
der opnås en B.E.R. i 
henhold til D9a  (Overholder EN 12253)  
D11a  (*) Effektgrænse for kommuni­
kation (øvre).  -24dBm  (Overholder EN 12253)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 551  
Punkt nr.  Parameter  Værdi(er)  Bemærkning  
D11b  (*) Effektgrænse for kommuni­
kation (nedre).  Indfaldende effekt: 
– 43 dBm (boresigte) 
– 41 dBm (inden for – 45 ° 
— + 45 ° svarende til det 
plan, der er parallelt med 
vejoverfladen, når 
DSRC-køretøjsenheden 
senere installeres i køretøjet 
(azimut))  (Overholder EN 12253) 
Udvidede krav til horisontale 
vinkler op til ± 45 ° som følge af 
de anvendelsessituationer, der defi­
neres i dette bilag.  
D12 (*) Afbrydelsesniveau for 
(DSRC-køretøjsenhed)  – 60 dBm  (Overholder EN 12253)  
D13 Præambel  Præambel er obligatorisk.  (Overholder EN 12253)  
D13a  Længde og mønster for 
præambel  16 bit ± 1 bit FM0-kodede 
»1« bits  (Overholder EN 12253)  
D13b  Bølgeform for præambel  En skiftende sekvens af lavt 
og højt niveau med en 
impulsvarighed på 2 μs. 
Tolerancen angives i D8a  (Overholder EN 12253)  
D13c  Efterstillede bit  RSU'en (REDCR) må højst 
transmittere 8 bit efter 
afslutningsmarkøren. Der er 
ikke behov for en OBU 
(DSRC-køretøjsenhed) for 
at tage hensyn til disse 
supplerende bit.  (Overholder EN 12253)  
(*) — Downlink-parametre er underlagt overensstemmelsesafprøvni ng i overensstemmelse med den relevante parameterafprøvning fra  
EN 300 674-1  
Tabel 14.2  
Uplink-parametre  
Punkt nr.  Parameter  Værdi(er)  Bemærkning  
U1 (*) Frekvenser for 
sub-bærebølge  En OBU (DSRC-køretøjs­
enhed) skal understøtte 
1,5 MHz og 2,0 MHz 
En RSU (REDCR) skal 
understøtte 1,5 MHz eller 
2,0 MHz eller begge. U1- 
0: 1,5 MHz U1-1: 2,0 MHz  Frekvensvalg for sub-bærebølge 
(1,5 MHz eller 2,0 MHz) afhæn­
gigt af den valgte EN 13372-profil.  
U1a (*) Tolerance for 
sub-bærebølgefrekvenser  inden for ± 0,1 %  (Overholder EN 12253)  
U1b Brug af sidebånd  Samme data på begge sider  (Overholder EN 12253)  
U2 (*) OBU (DSRC-køretøjs­
enhed) Spektralmaske for 
transmitter  Overholder EN12253 
1) Effekt, udadgående 
bånd: 
se ETSI EN 300674-1  (Overholder EN 12253)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 552  
Punkt nr.  Parameter  Værdi(er)  Bemærkning  
2) Effekt, indadgående 
bånd: 
[U4a] dBm i 500 kHz 
3) Emission på en hvilken 
som helst anden 
uplink-kanal: 
U2(3)-1 = -35 dBm i 
500 kHz  
U4a (*) Maksimalt enkelt sidebånd 
E.I.R.P. (boresigte)  To muligheder: 
U4a-0: -14 dBm 
U4a-1: -21 dBm  I henhold til den indberettede og 
offentliggjorte specifikation fra 
designeren af udstyret  
U4b (*) Maksimalt enkelt sidebånd 
E.I.R.P. (35 °)  To muligheder: 
— Ikke relevant 
— – 17dBm  I henhold til den indberettede og 
offentliggjorte specifikation fra 
designeren af udstyret  
U5 Polarisering  Venstre, cirkulær  (I overensstemmelse med EN 
12253)  
U5a Krydspolarisering  XPD: 
I boresigte: (REDCR) RSU 
r ≥ 15 dB  
(DSRC-VU) OBU t ≥ 10 dB 
Ved -3 dB: (REDCR) RSU r 
≥ 10 dB 
(DSRC-VU) OBU t ≥ 6 dB  (Overholder EN 12253)  
U6 Modulation af 
sub-bærebølge  2-PSK 
Kodede data synkroniseret 
med sub-bærebølge: Tran­
sitionerne for kodede data 
er sammenfaldende med 
transitionerne for sub-bære­
bølgen.  (Overholder EN 12253)  
U6b Driftsperiode  Driftsperiode: 
50 % ± α, α ≤ 5 %  (Overholder EN 12253)  
U6c Modulation på bærebølge  Multiplikation af moduleret 
sub-bærebølge med bære­
bølge.  (Overholder EN 12253)  
U7 (*) Datakodning  NRZI (Ingen transition ved 
begyndelsen af »1«-bit'en, 
transition ved begyndelsen 
af »0«-bit'en, ingen tran­
sition inden for bit'en)  (Overholder EN 12253)  
U8 (*) Bithastighed  250 kbit/s  (Overholder EN 12253)  
U8a Tolerance for bit-takt  Inden for ± 1 000 ppm  (Overholder EN 12253)  
U9 Bitfejlrate (B.E.R.) ved 
kommunikation  ≤ 10  – 6 (Overholder EN 12253)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 553  
Punkt nr.  Parameter  Værdi(er)  Bemærkning  
U11 Kommunikationszone  Den fysiske region, inden 
for hvilken DSRC-køretøjs­
enheden befinder sig, 
således at dens transmis­
sioner modtages af 
REDCR'en med en B.E.R. 
på mindre end det, der 
angives i U9a.  (Overholder EN 12253)  
U12a  (*) Konverteringsforstærkning 
(nedre grænse)  1 dB for hvert sidebånd 
Vinkelinterval: Cirkulært 
symmetrisk mellem bore­
sigte og ± 35 ° 
og 
inden for – 45 ° — + 45 ° 
svarende til det plan, der er 
parallelt med vejoverfladen, 
når DSRC-køretøjsenheden 
senere installeres i køretøjet 
(azimut)  Større end det angivne interval for 
horisontale vinkler op til ± 45° som 
følge af de anvendelsessituationer, 
der defineres i dette bilag.  
U12b  (*) Konverteringsforstærkning 
(øvre grænse)  10 dB for hvert sidebånd  Mindre end det angivne værdiin­
terval for hvert sidebånd inden for 
en cirkelformet kegle omkring 
boresigtet med en ± 45 ° åbnings­
vinkel.  
U13 Præambel  Præambel er obligatorisk.  (Overholder EN 12253)  
U13a  Præambel 
Længde og mønster  32 til 36 μs udelukkende 
moduleret med sub-bære­
bølge, herefter 8 bit 
NRZI-kodede »0«-bit.  (Overholder EN 12253)  
U13b  Efterstillede bit  DSRC-køretøjsenheden må 
højst transmittere 8 bit 
efter afslutningsmarkøren. 
En RSU (REDCR) skal 
ikke tage hensyn til disse 
supplerende bit.  (Overholder EN 12253)  
(*) Uplink-parametre er underlagt overensstemmelsesafprøvning i  overensstemmelse med den relevante parameterafprøvning fra EN 300 
674-1  
5.3.3  Antennedesign  
5.3.3.1 REDCR-antenne  
DSC_30 Udformningen af  REDCR -antennen bestemmes af det 
kommercielle design, og den skal operere inden for de 
grænser, der er fastsat i 5.3.2, som har til formål at optimere  
DSRC-REDCR 'ens læseevne med det specifikke formål og på 
de læsevilkår, som  REDCR'en  er udformet til at operere 
under.  
5.3.3.2 Køretøjsenhedens antenne  
DSC_31 Udformningen af antennen på  DSRC-køretøjsenheden  
bestemmes af det kommercielle design, og den skal operere 
inden for de grænser, der er fastsat i 5.3.2, som har til formå l 
at optimere  DSRC-REDCR'ens  læseevne med det specifikke 
formål og på de læsevilkår, som  REDCR'en  er udformet til at 
operere under.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 554  
DSC_32 Køretøjsenhedens antenne fastgøres til eller tæt ved kør etøjets 
forrude som specificeret i ovenstående 5.1.  
DSC_33 I testmiljøet i et værksted (se afsnit 6.3) skal antenne n på en 
DSRC-køretøjsenhed, der er monteret i henhold til 5.1 
ovenfor, oprette forbindelse til standardtestkommunikations­
udstyr og gennemføre en RTM-transaktion som defineret i 
dette tillæg i en afstand på 2 og 10 m mere end 99 % af 
tiden med et gennemsnit på over 1 000 læste anmodninger.  
5.4 DSRC-protokolkrav til RTM  
5.4.1  Oversigt  
DSC_34 Transaktionsprotokollen til download af  dataene  via 5,8 GHz 
DSRC-interfaceforbindelsen skal være i overensstemmelse 
med følgende beskrivelse. I dette afsnit beskrives en trans­
aktionsstrøm under ideelle betingelser uden genfremsendelser 
eller kommunikationsafbrydelser.  
Bemærk: Formålet med initialiseringsfasen (trin 1) er at etab­
lere kommunikationen mellem  REDCR'en  og DSRC-køretøjs­
enheder, der er kommet ind i 5,8 GHz DSRC- (master-slave) 
transaktionsområdet, men endnu ikke har etableret kommuni­
kation med  REDCR'en , og at anmelde applikationsprocesser.  
— Trin 1  Initialisering.  REDCR'en  sender en ramme med en 
»Beacon Service Table« (BST), der indeholder applika­
tionsidentifikatorerne (AIDs) i den serviceliste, den under­
støtter. I RTM-applikationen bliver dette ganske enkelt 
tjenesten med AID-værdien = 2 (Freight&Fleet).  DSRC- 
køretøjsenheden  evaluerer den modtagne BST og reagerer 
(se nedenfor) med listen over de understøttede applika­
tioner i Freight&Fleet-området eller reagerer ikke, hvis 
ingen applikationer understøttes. Hvis  REDCR'en  ikke 
tilbyder AID = 2, afslutter svarer DSRC-køretøjsenheden 
ikke REDCR'en.  
— Trin 2  DSRC-køretøjsenheden  sender en ramme med en 
anmodning om tildeling af et privat vindue.  
— Trin 3  REDCR'en  sender en ramme med tildeling af et 
privat vindue.  
— Trin 4  DSRC-køretøjsenheden  bruger det tildelte private 
vindue til at sende en ramme med dets servicetabel for 
køretøjet (VST). Denne VST indeholder en liste med alle 
de forskellige applikationsforekomster, som denne  DSRC- 
køretøjsenhed  understøtter i AID = 2-rammen. De forskel­
lige forekomster identificeres ved hjælp af entydigt gene­
rerede EID'er, hver tilhørende en parameterværdi for 
applikationsindholdsmarkør, der angiver applikationen 
og den understøttede standard.  
— Trin 5  Derefter analyserer  REDCR'en  den tilbudte VST 
og afslutter enten forbindelsen (RELEASE), da den ikke 
er interesseret i noget af det, VST'en kan tilbyde (dvs. at 
den modtager en VST fra en  DSRC-køretøjsenhed , der 
ikke understøtter RTM-transaktionen), eller den starter 
en app-forekomst.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 555  
— Trin 6  For at igangsætte dette sender REDCR'en en 
ramme med en kommando om at hente RTM-data, som 
identificerer forekomsten af RTM-applikationen ved at 
specificere den identifikator, der svarer til forekomsten 
af RTM-applikationen (som specificeret af DSRC-køre­
tøjsenheden i VST'en), og tildeler et privat vindue.  
— Trin 7  DSRC-køretøjsenheden  bruger det nyligt tildelte 
private vindue til at sende en ramme med den behandlede 
identifikator svarende til RTM-applikationsforekomsten 
som tilvejebragt i VST'en, efterfulgt af egenskaben  
RtmData  (dataindholdselement + sikkerhedselement).  
— Trin 8  Hvis der er anmodet om flere services, ændres 
værdien »n« til det næste servicereferencenummer, og 
processen gentages.  
— Trin 9  REDCR'en  bekræfter modtagelsen af data ved at 
sende en ramme med en RELEASE-kommando til  DSRC- 
køretøjsenheden  for at afslutte sessionen ELLER går 
tilbage til trin 6, hvis den ikke har valideret en vellykket 
modtagelse af LDPU'en.  
Se figur 14.6 for en grafisk beskrivelse af transaktionspro­
tokollen.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 556  
Figur 14.6  
RTM 5,8 GHz DSRC-procesflow
  
5.4.2  Kommandoer  
DSC_35 Følgende kommandoer bruges kun i en RTM-transaktionsfase  
— INITIALISATION.request : En kommando, der afgives 
af REDCR'en i form af en transmission med definition af 
applikationer, som REDCR'en understøtter.  
— INITIALISATION.response : Et svar fra DSRC-køre­
tøjsenheden, der bekræfter forbindelsen og indeholder 
en liste over understøttede applikationsforekomster med 
kendetegn og information om, hvordan de skal håndteres 
(EID).  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 557  
— GET.request : En kommando afgivet af  REDCR'en  til 
DSRC-køretøjsenheden , der angiver den applikationsfore­
komst, der skal håndteres ved hjælp af en defineret EID, 
som denne modtages i VST'en, som instruerer  DSRC- 
køretøjsenheden  i at sende de(n) valgte attribut(ter) 
sammen med  dataene . Formålet med GET-kommandoen 
er, at  REDCR'en  skal hente  dataene  fra DSRC-køretøjs ­
enheden . 
— GET.response : Et svar fra DSRC-køretøjsenheden, der 
indeholder  dataene  fra forespørgslen.  
— ACTION.request ECHO : En kommando, der instruerer  
DSRC-køretøjsenheden  i at sende data tilbage fra  DSRC- 
køretøjsenheden  til REDCR'en . Formålet med ECHO- 
kommandoen er at give værksteder eller prøveanlæg til 
typegodkendelse mulighed for at efterprøve, at 
DSRC-forbindelsen fungerer uden at kræve adgang til 
sikkerhedsoplysninger.  
— ACTION .response (ECHO): Svar fra DSRC-køretøjs­
enheden på ECHO-kommandoen.  
— EVENT_REPORT.request  RELEASE: En kommando 
til DSRC-køretøjsenheden  om, at transaktionen er 
afsluttet. Formålet med RELEASE-kommandoen er at 
afslutte sessionen med  DSRC-køretøjsenheden . Ved 
modtagelsen af RELEASE reagerer  DSRC-køretøjs ­
enheden  ikke på yderligere anmodninger under den nuvæ­
rende forbindelse. Bemærk, at en DSRC-køretøjsenhed i 
henhold til EN 12834 ikke forbindes to gange til samme 
interrogator, medmindre den har været ude af kommuni­
kationsområdet i 255 sekunder, eller hvis interrogatorens 
Beacon-ID er blevet ændret.  
5.4.3  Kommandosekvens ved anmodning  
DSC_36 Set ud fra kommando- og responssekvensen beskrives trans ­
aktionen som følger:  
Rækkefølge  Sender  Modtager  Beskrivelse  Handling  
1 REDCR  >  DSRC-VU  Initialisering af kommuni­
kationen forbindelse — 
Anmodning  REDCR udsender BST  
2 DSRC-køre ­
tøjsenhed  > REDCR  Initialisering af kommuni ­
kationen forbindelse — 
Svar Hvis BST understøtter 
AID=2, anmoder DSRC-køre ­
tøjs-enheden om et privat 
vindue  
3 REDCR  >  DSRC-køre­
tøjsenhed  Tildeler et privat vindue  Sender ramme med tildeling 
af privat vindue  
4 DSRC-køre ­
tøjsenhed  > REDCR  Sender VST  Sender ramme indeholdende 
VST 
5 REDCR  >  DSRC-køre­
tøjsenhed  Sender GET.request om 
data i Attribut for specifik 
EID 
6 DSRC-VU  >  REDCR  Sender GET.response med 
ønsket Attribut til specifik 
EID Sender attribut (RTMData, 
OWSData….) med data til 
specifik EID  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 558  
Rækkefølge  Sender  Modtager  Beskrivelse  Handling  
▼M1 
7 REDCR  >  DSRC-køre­
tøjsenhed  Sender GET.request om 
data anden Attribut (hvis 
relevant)  
▼B 
8 DSRC-køre ­
tøjsenhed  > REDCR  Sender GET.response med 
ønsket Attribut  Sender Attribut med data til 
specifik EID  
9 REDCR  >  DSRC-køre­
tøjsenhed  Bekræfter vellykket modta­
gelse af data  Sender RELEASE- 
kommando, der afslutter 
transaktionen  
10 DSRC-køre ­
tøjsenhed  Afslutter transaktionen  
Et eksempel på transaktionssekvensen og indholdet af de 
udvekslede rammer defineres i punkt 5.4.7 og 5.4.8.  
5.4.4  Datastrukturer  
DSC_37 Når  dataene  sendes via 5,8 GHz DSRC-interfacet, skal deres 
semantiske struktur være i overensstemmelse med beskri­
velsen i dette tillæg. Den måde, disse data er struktureret 
på, specificeres i denne artikel.  
DSC_38 Indholdsdataene (RTM-data) består af en sammenkædning af  
1. EncryptedtachographPayload-data, som er krypteringen af 
TachographPayload som defineret i ASN.1 i afsnit 5.4.5. 
Krypteringsmetoden er beskrevet i tillæg 11  
2. DSRCSecurityData, specificeres i tillæg 11.  
DSC_39 RTM-data behandles som RTM-attribut = 1 og overføres i 
RTM-container = 10.  
DSC_40 RTM-indholdsmarkøren identificerer den understøttede sta n­
darddel i TARV-serien af standarder (RTM svarer til del 9)  
ASN.1-moduldefinition for DSRC-dataene inden for RTM- 
applikationen defineres som følger:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 559
  
► (2) (3) M1 
► (1) M3 ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 560
  
5.4.5  Elementer af RtmData, udførte handlinger og definitioner  
DSC_41 Dataværdierne, som skal beregnes af køretøjsenheden og 
bruges til at ajourføre de sikrede data i DSRC-køretøjs­
enheden, skal beregnes i henhold til reglerne i tabel 14.3:  
▼M3 
Tabel 14.3  
Elementer af RtmData, udførte handlinger og definitioner  
1) 
RTM-dataelement  2) 
Handling udført af køretøjsenhed  3) 
ASN.1 Definition af data  
RTM1 
Køretøjsregistrering 
Nummerplade  Køretøjsenheden angiver 
værdien for dataelementet  
tp15638VehicleRegistration ­
Plate  RTM1 ud fra den 
værdi, der er registreret for 
datatypen  
VehicleRegistrationIdentifica ­
tion som fastlagt i tillæg 1  
VehicleRegistrationIdentifica ­
tion Køretøjets nummerplade 
udtrykt som en streng af 
tegn tp15638VehicleRegistration­
Plate LPN, 
–Køretøjets nummerplade ud 
fra datastrukturen i ISO 14906, 
men med følgende begræns­
ning for RTM-applikationen: 
SEQUENCE indledes med 
landekode efterfulgt af en 
alfabetindikator efterfulgt af 
selve pladenummeret, 
som altid er 14 oktetter 
(udfyldt med nuller), så 
LPN-typelængden altid er 17 
oktetter (der er ikke behov for 
en længdedeterminant), hvoraf 
14 er det »egentlige« 
pladenummer.  
RTM2 
Hastighedshændelse  Køretøjsenheden genererer en 
boolsk 
værdi for dataelementet 
RTM2 
tp15638SpeedingEvent. 
Køretøjsenheden beregner 
værdien af tp15638Speed­
ingEvent på grundlag af det 
antal hændelser med over­
skridelse af tilladt hastighed, 
der er registreret i køretøjs­
enheden i de sidste ti dage 
som defineret i bilag I C.  1 (TRUE): hvis den 
seneste hændelse med 
overskridelse af tilladt 
hastighed sluttede inden 
for de sidste ti dage eller 
stadig er i gang 
0 (FALSE): i alle andre 
tilfælde.  tp15638SpeedingEvent 
BOOLEAN,  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 561  
1) 
RTM-dataelement  2) 
Handling udført af køretøjsenhed  3) 
ASN.1 Definition af data  
RTM3 
Kørsel uden 
gyldigt kort  Køretøjsenheden genererer en 
boolsk 
værdi for dataelementet 
RTM3 
tp15638DrivingWithoutVa­
lidCard. 
Køretøjsenheden tildeler 
værdien TRUE til variablen 
tp15638DrivingWithoutVa­
lidCard, hvis mindst én 
hændelse med kørsel uden 
behørigt kort er blevet regi­
streret i køretøjsenheden 
inden for de sidste ti dage 
som defineret i bilag I C.  1 (TRUE): hvis den 
seneste hændelse med 
kørsel uden behørigt kort 
sluttede inden for de 
sidste ti dage eller stadig 
er i gang 
0 (FALSE): i alle andre 
tilfælde.  tp15638DrivingWithoutValid­
Card 
BOOLEAN,  
RTM4 
Gyldigt førerkort  Køretøjsenheden genererer en 
boolsk værdi af dataelement 
RTM4 
tp15638DriverCard på 
grundlag af det isatte gyldige 
førerkort i førerkortpladsen.  1 (TRUE): hvis der ikke 
er et gyldigt førerkort i 
førerkortpladsen i køre­
tøjsenheden 
0 (FALSE): hvis der er 
et gyldigt førerkort i 
førerkortpladsen i køre­
tøjsenheden.  tp15638DriverCard 
BOOLEAN,  
RTM5 
Isætning af kort under 
Kørsel  genererer en boolsk værdi for 
dataelementet RTM5 
tp15638CardInsertion. 
Køretøjsenheden tildeler 
værdien TRUE til variablen 
tp15638CardInsertion, hvis 
mindst én hændelse med 
isætning af kort under 
kørslen er blevet registreret i 
køretøjsenheden inden for de 
sidste ti dage som defineret i 
bilag I C.  1 (TRUE): hvis den 
seneste isætning af kort 
under kørslen er sket 
inden for de sidste ti 
dage 
0 (FALSE): i alle andre 
tilfælde.  tp15638CardInsertion 
BOOLEAN,  
RTM6 
Fejl i bevægelsesdata  Køretøjsenheden genererer en 
boolsk 
værdi for dataelementet 
RTM6. 
Køretøjsenheden tildeler 
værdien TRUE til variablen 
tp15638MotionDataError, 
hvis mindst én hændelse med 
fejl ved bevægelsesdata er 
blevet registreret i køretøjs­
enheden inden for de sidste ti 
dage som defineret i bilag 
I C. 1 (TRUE): hvis den 
seneste hændelse med 
fejl ved bevægelsesdata 
sluttede inden for de 
sidste ti dage eller stadig 
er i gang 
0 (FALSE): i alle andre 
tilfælde.  tp15638MotionDataError 
BOOLEAN,  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 562  
1) 
RTM-dataelement  2) 
Handling udført af køretøjsenhed  3) 
ASN.1 Definition af data  
RTM7 
Køretøjsbevægelses- 
konflikt  Køretøjsenheden genererer en 
boolsk 
værdi for dataelementet 
RTM7. 
Køretøjsenheden tildeler 
værdien TRUE til variablen 
tp15638VehicleMotionCon­
flict, hvis mindst én hændelse 
med køretøjsbevægelseskon­
flikt er blevet registreret i 
køretøjsenheden inden for de 
sidste ti dage som defineret i 
bilag I C.  1 (TRUE): hvis den 
seneste hændelse med 
køretøjsbevægelseskon­
flikt sluttede inden for de 
sidste ti dage eller stadig 
er i gang 
0 (FALSE): i alle andre 
tilfælde.  tp15638VehicleMotionConflict 
BOOLEAN,  
RTM8 
2. førerkort  Køretøjsenheden genererer en 
boolsk 
værdi for dataelementet 
RTM8 på grundlag af bilag 
I C (Føreraktivitetsdata 
CREW og CO-DRIVER). 
Hvis der er et gyldigt 
medchaufførkort, indstiller 
køretøjsenheden værdien af 
RTM8 til TRUE.  1 (TRUE): hvis der er et 
gyldigt medchaufførkort 
i køretøjsenheden 
2 (FALSE): hvis der 
ikke er et gyldigt 
medchaufførkort i køre­
tøjsenheden.  tp156382ndDriverCard 
BOOLEAN,  
RTM9 
Aktuel aktivitet  Køretøjsenheden genererer en 
boolsk 
værdi for dataelementet 
RTM9. 
Hvis den aktuelle aktivitet er 
registreret i køretøjsenheden 
som en hvilken som helst 
anden aktivitet end 
»KØRSEL« som defineret i 
bilag I C, sætter køretøjs­
enheden værdien af RTM9 til 
TRUE.  1 (TRUE): anden akti­
vitet 
valgt 
0 (FALSE): kørsel valgt  tp15638CurrentActivityDri­
ving 
BOOLEAN  
RTM10 
Seneste session afsluttet  Køretøjsenheden genererer en 
boolsk værdi for dataele­
mentet RTM10. 
Hvis den seneste kortsession 
ikke blev lukket korrekt som 
defineret i bilag I C, sætter 
køretøjsenheden værdien af 
RTM10 til TRUE.  1 (TRUE): hvis mindst 
ét af de isatte kort har 
udløst en hændelse med 
sidste kortsession ikke 
korrekt afsluttet 
0 (FALSE): ingen af de 
isatte kort har udløst en 
hændelse med sidste 
kortsession ikke korrekt 
afsluttet.  tp15638LastSessionClosed 
BOOLEAN  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 563  
1) 
RTM-dataelement  2) 
Handling udført af køretøjsenhed  3) 
ASN.1 Definition af data  
RTM11 
Afbrydelse af 
strømforsyning  Køretøjsenheden generer en 
heltalsværdi 
værdi for dataelementet 
RTM11. 
Køretøjsenheden tildeler en 
værdi for variablen 
tp15638PowerSupplyInter­
ruption svarende til det antal 
registrerede hændelser med 
afbrydelse af strømforsyning, 
der er lagret i køretøjs­
enheden inden for de sidste ti 
dage som defineret i bilag 
I C. 
Hvis der ikke er registreret en 
hændelse med afbrydelse af 
strømforsyning i køretøjs­
enheden inden for de sidste ti 
dage, indstilles værdien for 
RTM11 til 0.  Antal registrerede 
hændelser med afbry­
delse af strømforsyning 
inden for de sidste ti 
dage.  tp15638PowerSupplyInterrup­
tion 
INTEGER(0..127),  
RTM12 
Følerfejl  Køretøjsenheden genererer en 
heltalsværdi for dataelementet 
RTM12. 
Køretøjsenheden tildeler 
variablen sensorFault en 
værdi på: 
— 1, hvis en hændelse af 
typen »35«H sensorfejl 
blev afsluttet inden for 
de sidste 10 dage eller er 
stadig i gang. 
— 2, hvis en hændelse af 
typen 
GNSS-modtagerfejl 
(enten intern eller ekstern 
med enum-værdien 
»36«H eller 
»37«H) blev afsluttet 
inden for de sidste 10 
dage eller er stadig i 
gang. 
— 3, hvis en hændelse af 
typen »0E«H Ekstern 
GNSS-kommunikations­
fejl blev afsluttet inden 
for de sidste 10 dage 
eller er stadig i gang. 
— 4, hvis både sensorfejl og 
GNSS-modtagerfejl blev 
afsluttet inden for de 
sidste 10 dage eller er 
stadig i gang. 
— 5, hvis både sensorfejl og 
ekstern GNSS-kommuni­
kationsfejl blev afsluttet 
inden for de sidste 10 
dage eller er stadig i 
gang.  –følerfejl en oktet i 
henhold til dataordlisten  tp15638SensorFault INTEGER 
(0..255),  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 564  
1) 
RTM-dataelement  2) 
Handling udført af køretøjsenhed  3) 
ASN.1 Definition af data  
— 6, hvis både GNSS- 
modtagerfejl og ekstern 
GNSS-kommunikations­
fejl blev afsluttet inden 
for de sidste 10 dage 
eller er stadig i gang. 
— 7, hvis alle tre sensorfejl 
blev afsluttet inden for 
de sidste 10 dage eller er 
stadig i gang. 
Hvis ingen hændelse er 
afsluttet inden for de sidste 
10 dage eller stadig er i gang, 
indstiller køretøjsenheden 
værdien for RTM12 til 0.  
RTM13 
Tidsjustering  Køretøjsenheden genererer en 
heltalsværdi (timeReal fra 
tillæg 1) for dataelementet 
RTM13 på grundlag af 
tilstedeværelsen af data for 
tidsjustering som defineret i 
bilag I C. 
Køretøjsenheden indstiller 
værdien af RTM13 til tids­
værdi, hvor den seneste 
hændelse med tidsjusterings­
data er forekommet. 
Hvis der ikke findes nogen 
hændelse med tidsjustering 
som defineret i bilag I C i 
dataene for køretøjsenheden, 
sættes værdien for RTM13 
til 0.  oldTimeValue er den 
seneste tidsjustering.  tp15638TimeAdjustment 
INTEGER(0..4294967295),  
RTM14 
Forsøg på 
sikkerhedsbrud  Køretøjsenheden genererer en 
heltalsværdi (timeReal fra 
tillæg 1) til dataelementet 
RTM14 på grundlag af en 
hændelse med forsøg på 
sikkerhedsbrud som defineret 
i bilag I C. 
Køretøjsenheden sætter 
værdien til tidspunktet for 
den seneste hændelse med 
forsøg på sikkerhedsbrud, 
som køretøjsenheden har 
registreret. 
Hvis der ikke findes nogen 
hændelse med forsøg på 
sikkerhedsbrud som defineret 
i bilag I C i dataene for 
køretøjsenheden, sættes 
værdien for RTM14 til 0.  Starttidspunkt for den 
seneste hændelse med 
forsøg på 
sikkerhedsbrud.  tp15638LatestBreachAttempt 
INTEGER(0..4294967295),  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 565  
1) 
RTM-dataelement  2) 
Handling udført af køretøjsenhed  3) 
ASN.1 Definition af data  
RTM15 
Seneste kalibrering  Køretøjsenheden genererer en 
heltalsværdi (timeReal fra 
tillæg 1) for dataelementet 
RTM15 på grundlag af 
tilstedeværelsen af seneste 
kalibreringsdata som defi­
neret i bilag I C og tillæg 1. 
Køretøjsenheden indstiller 
værdien for 
RTM15 til oldTimeValue i 
den seneste kalibreringspost. 
Hvis der ikke findes nogen 
tidligere kalibrering, indstiller 
køretøjsenheden værdien for 
RTM15 til 0.  oldTimeValue er den 
seneste kalibreringspost.  tp15638LastCalibrationData 
INTEGER(0..4294967295),  
RTM16 
Foregående kalibrering  Køretøjsenheden genererer en 
heltalsværdi (timeReal fra 
tillæg 1) for dataelementet 
RTM16 på grundlag af kali­
breringsposten forud for den 
seneste kalibrering. 
Køretøjsenheden indstiller 
værdien for 
RTM16 til oldTimeValue for 
kalibreringsposten forud for 
den seneste kalibrering. 
Hvis der ikke findes nogen 
forudgående kalibrering, 
indstiller køretøjsenheden 
værdien for RTM16 til 0.  oldTimeValue for kali­
breringspostens forud for 
den seneste 
kalibreringspost.  tp15638PrevCalibrationData 
INTEGER(0..4294967295),  
RTM17 
Dato for 
tilslutning af takograf  Køretøjsenheden generer en 
heltalsværdi (timeReal fra 
tillæg 1) for dataelementet 
RTM17. 
Køretøjsenheden indstiller 
værdien for RTM17 til 
datoen for den første kali­
brering af køretøjsenheden i 
det aktuelle køretøj. 
Køretøjsenheden henter disse 
data fra VuCalibrationData 
(tillæg 1) fra vuCalibration­
Records med CalibrationPur­
pose lig med: »03«H 
Hvis der ikke findes nogen 
forudgående kalibrering, 
indstiller køretøjsenheden 
værdien for RTM17 til 0.  Dato for første kalibre­
ring af køretøjsenheden i 
det aktuelle køretøj.  tp15638DateTachoConnected 
INTEGER(0..4294967295),  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 566  
1) 
RTM-dataelement  2) 
Handling udført af køretøjsenhed  3) 
ASN.1 Definition af data  
RTM18 
Aktuel hastighed  Køretøjsenheden generer en 
heltalsværdi 
værdi for dataelementet 
RTM18. 
Køretøjsenheden indstiller 
værdien for RTM18 til den 
senest registrerede aktuelle 
hastighed på tidspunktet for 
den seneste ajourføring af 
RtmData.  Senest registrerede aktu­
elle hastighed  tp15638CurrentSpeed 
INTEGER (0..255),  
RTM19 
Tidsstempel  Køretøjsenheden generer en 
heltalsværdi for dataelementet 
RTM19 (timeReal fra tillæg 1). 
Køretøjsenheden indstiller 
værdien for RTM19 til tids­
punktet for den seneste ajour­
føring af RtmData.  Tidsstempel for aktuel 
TachographPayload-post  tp15638Timestamp 
INTEGER(0..4294967295),  
RTM20 
Tidspunkt, hvor den 
senest ægthedsbekræf ­
tede køretøjsposition var 
tilgængelig  Køretøjsenheden generer en 
heltalsværdi (timeReal fra 
tillæg 1) for dataelementet 
RTM20. 
Køretøjsenheden indstiller 
værdien for RTM20 til det 
tidspunkt, hvor den senest 
ægthedsbekræftede køretøjs­
position var tilgængelig fra 
GNSS-modtageren. 
Hvis en ægthedsbekræftet 
køretøjsposition ikke var 
tilgængelig fra 
GNSS-modtageren, indstiller 
køretøjsenheden værdien for 
RTM20 til 0.  Tidsstempel for den 
seneste ægthedsbekræf­
tede køretøjsposition  tp15638LatestAuthenticatedPo­
sition 
INTEGER(0..4294967295),  
RTM21 
Kontinuerlig køretid  Køretøjsenheden genererer en 
heltalsværdi for dataelementet 
RTM21. 
Køretøjsenheden indstiller 
værdien for RTM21 til føre­
rens sammenhængende 
køretid.  Førerens sammenhæn­
gende køretid kodet som 
en heltalsværdi. 
Længde: 1 byte 
Opløsning: 2 minutter/bit 
Ingen forskydning 
Datainterval: 0 til 250 
En værdi på 250 
angiver, at førerens 
sammenhængende 
køretid er lig med eller 
større end 500 minutter. 
Værdierne 251-254 
anvendes ikke. 
Værdien 255 angiver, at 
oplysningerne ikke er 
tilgængelige.  tp15638ContinuousDriving­
Time INTEGER(0..255),  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 567  
1) 
RTM-dataelement  2) 
Handling udført af køretøjsenhed  3) 
ASN.1 Definition af data  
RTM22 
Længste daglige køretid 
for igangværende og 
tidligere RTM-skift 
beregnet i overensstem ­
melse med adden ­
dummet til tillæg 14  Køretøjsenheden genererer en 
heltalsværdi for dataelementet 
RTM22. 
Køretøjsenheden indstiller 
værdien for RTM22 til den 
længste af førerens to daglige 
køretider, som er det igang­
værende eller det tidligere 
RTM-skift.  Førerens daglige køretid 
kodet som en heltals­
værdi. 
Længde: 1 byte 
Opløsning: 4 minutter/bit 
Ingen forskydning 
Datainterval: 0 til 250 
En værdi på 250 
angiver, at førerens 
daglige køretid er lig 
med eller større end 
1 000 minutter. 
Værdierne 251-254 
anvendes ikke. 
Værdien 255 angiver, at 
oplysningerne ikke er 
tilgængelige.  tp15638DailyDrivingTimeShift 
INTEGER(0..255),  
RTM23 
Længste daglige køretid 
i indeværende uge 
beregnet i overensstem ­
melse med adden ­
dummet til tillæg 14  Køretøjsenheden genererer en 
heltalsværdi for dataelementet 
RTM23. 
Køretøjsenheden indstiller 
værdien for RTM23 til føre­
rens længste daglige køretid, 
som enten er det igangvæ­
rende RTM-skift eller et 
afsluttet RTM-skift, som er 
påbegyndt eller afsluttet i den 
indeværende uge.  Førerens daglige køretid 
kodet som en heltals­
værdi. 
Længde: 1 byte 
Opløsning: 4 minutter/bit 
Ingen forskydning 
Datainterval: 0 til 250 
En værdi på 250 
angiver, at førerens 
daglige køretid er lig 
med eller større end 
1 000 minutter. 
Værdierne 251-254 
anvendes ikke. 
Værdien 255 angiver, at 
oplysningerne ikke er 
tilgængelige.  tp15638DailyDrivingTime­
Week INTEGER(0..255),  
RTM24 
Ugentlig køretid 
beregnet i overensstem ­
melse med adden ­
dummet til tillæg 14  Køretøjsenheden genererer en 
heltalsværdi for dataelementet 
RTM24. 
Køretøjsenheden indstiller 
værdien for RTM24 til føre­
rens ugentlige køretid.  Førerens ugentlige 
køretid kodet som en 
heltalsværdi. 
Længde: 1 byte 
Opløsning: 20 minutter/ 
bit 
Ingen forskydning 
Datainterval: 0 til 250 
En værdi på 250 
angiver, at førerens 
ugentlige køretid er lig 
med eller større end 
5 000 minutter. 
Værdierne 251-254 
anvendes ikke. 
Værdien 255 angiver, at 
oplysningerne ikke er 
tilgængelige.  tp15638WeeklyDrivingTime 
INTEGER(0..255),  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 568  
1) 
RTM-dataelement  2) 
Handling udført af køretøjsenhed  3) 
ASN.1 Definition af data  
RTM25 
Køretid over to uger 
beregnet i overensstem ­
melse med adden ­
dummet til tillæg 14  Køretøjsenheden genererer en 
heltalsværdi for dataelementet 
RTM25. 
Køretøjsenheden indstiller 
værdien for RTM25 til føre­
rens køretid for 14 dage.  Førerens køretid for 14 
dage kodet som en 
heltalsværdi. 
Længde: 1 byte 
Opløsning: 30 minutter/ 
bit 
Ingen forskydning 
Datainterval: 0 til 250 
En værdi på 250 
angiver, at førerens 
køretid for 14 dage er lig 
med eller større end 
7 500 minutter. 
Værdierne 251-254 
anvendes ikke. 
Værdien 255 angiver, at 
oplysningerne ikke er 
tilgængelige.  tp15638FortnightlyDriving­
Time INTEGER(0..255),  
Bemærk: RTM22, RTM23, RTM24 og RTM25 beregnes i overensstemmels e 
med addendummet til dette tillæg  
▼B 
5.4.6  Dataoverførselsmekanisme  
DSC_42 REDCR anmoder om tidligere defineret dataindhold efter 
initialiseringsfasen, der herefter overføres af  DSRC-køretøjs ­
enheden  i det tildelte vindue. REDCR benytter kommandoen 
GET til at hente data.  
▼M1 
DSC_43 Ved alle DSRC-udvekslinger skal dataene kodes med PER 
(Packed Encoding Rules) UNALIGNED, bortset fra
  
og
 , som skal 
kodes med OER (Octet Encoding Rules) som fastsat i 
ISO/IEC 8825-7, Rec. ITU-T X.696.  
▼B 
5.4.7  Detaljeret DSRC-transaktionsbeskrivelse  
DSC_44 Initialiseringen udføres i henhold til DSC_44-DSC_48 og 
tabel 14.4-14.9. Under initialiseringsfasen begynder REDCR 
at sende en ramme, der indeholder en BST (Beacon Service 
Table) i henhold til EN 12834 og EN 13372, 6.2, 6.3, 6.4 og 
7.1 med indstillinger som angivet i nedenstående tabel 14.4.  
Tabel 14.4  
Initialisering — BST-rammeindstillinger  
Felt Indstillinger  
Link-identifikator  Sendeadresse  
BeaconId  I henhold til EN 12834  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 569  
Klokkeslæt  I henhold til EN 12834  
Profil  Ingen udvidelse, 0 eller 1 
benyttes  
MandApplications  Ingen udvidelse, EID ikke til 
stede, Parameter ikke til 
stede, AID = 2 Freight&Fleet  
NonMandApplications  Ikke til stede  
ProfileList  Ingen udvidelse, antal 
profiler på listen = 0  
Fragmenterings-header  Ingen fragmentering  
Indstillinger for lag 2  Kommando-PDU, 
UI-kommando  
Følgende tabel 14.5 indeholder et praktisk eksempel på 
indstillingerne i tabel 14.4 med angivelse af bitkodninger.  
Tabel 14.5  
Initialisering — eksempel på BST-rammeindhold
 Oktet nr. 
Attribut/Felt  Bit in oktet  Beskrivelse  
1 MARKØR
  Startmarkør  
2 Sende-ID
  Sendeadresse  
3 MAC-kontrolfelt
  Kommando-PDU  
4 LLC-kontrolfelt
  UI-kommando  
5 Fragmenterings-header
  Ingen fragmentering  
6 BST
  Initialiseringsanmodning  
SEQUENCE {  
OPTION indicator 
BeaconID SEQUENCE { 
ManufacturerId INTEGER (0..65535)
  NonMand-applikationer 
ikke til stede
  
Fabrikantidentifikator  
7
 
8
 
IndividualID INTEGER (0..134217727) 
}
 27 bit ID tilgængelig for 
fabrikant  
9
 
10
 
11
 ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 570
 Oktet nr. 
Attribut/Felt  Bit in oktet  Beskrivelse  
12 Klokkeslæt INTEGER (0..4294967295)
  32 bit UNIX realtid  
13
 
14
 
15
 
16 Profil INTEGER (0..127,…)
  Ingen udvidelse. Eksem­
pelprofil 0  
17 MandApplications SEQUENCE 
(SIZE(0..127,…)) 
OF {!
  Ingen undtagelse, Antal 
mandApplications = 1  
18 SEQUENCE {  
OPTION indicator
  EID ikke til stede  
OPTION indicator
  Parameter ikke til stede  
AID DSRCApplicationEntityID } }
  Ingen udvidelse. AID = 2 
Freight&Fleet  
19 ProfileList SEQUENCE (0..127,…) OF 
Profile }
  Ingen udvidelse, antal 
profiler på listen = 0  
20 FCS
  Sekvens for rammekontrol  
21
 
22 Markør
  Slutmarkør  
DSC_45 Når en  DSRC-køretøjsenhed  modtager en BST, kræver den 
tildeling af et privat vindue som specificeret i EN 12795 og 
EN 13372, 7.1.1, uden specifikke RTM-indstillinger. Tabel 
14.6 indeholder et eksempel på bitkodning.  
Tabel 14.6  
Initialisering — Indhold af ramme til anmodning om tildeling af privat vindue
 Oktet nr. 
Attribut/Felt  Bit i oktet  Beskrivelse  
1 MARKØR
  Startmarkør  
2 Privat LID
  Linkadresse for specifik 
DSRC-køretøjsenhed  
3
 
4
 
5
 
6 MAC-kontrolfelt
  Anmodning om privat 
vindue  
7 FCS
  Sekvens for rammekontrol  
8
 
9 Markør
  Slutmarkør  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 571  
DSC_46 Herefter svarer REDCR'en ved at tildele et privat vindue  som 
specificeret i EN 12795 og EN 13372, 7.1.1, uden specifikke 
RTM-indstillinger.  
Tabel 14.7 indeholder et eksempel på bitkodning.  
Tabel 14.7  
Initialisering — Indhold af ramme til anmodning om tideling af privat vindue
 Oktet nr. 
Attribut/Felt  Bit i oktet  Beskrivelse  
1 MARKØR
  Startmarkør  
2 Privat LID
  Linkadresse på den speci­
fikke 
DSRC-køretøjsenhed  3
 
4
 
5
 
6 MAC-kontrolfelt
  Tildeling af privat vindue  
7 FCS
  Sekvens for rammekontrol  
8
 
9 Markør
  Slutmarkør  
DSC_47 Når  DSRC-køretøjsenheden  modtager tildelingen af det 
private vindue, sender den sin VST (Vehicle Service Table) 
som defineret i EN 12834 og EN 13372, 6.2, 6,3, 6.4 og 7.1 
med indstillinger som specificeret i tabel 14.8 ved hjælp af 
det tildelte transmissionsvindue.  
Tabel 14.8  
Initialisering — VST-rammeindstillinger  
Felt Indstillinger  
Privat LID  I henhold til EN 12834  
VST-parametre  Fill = 0, herefter for hver understøttet 
applikation: EID til stede, parameter 
til stede, AID = 2, EID som genereret 
af OBU  
Parameter  Ingen udvidelse, Indeholder RTM- 
kontekstmarkør  
ObeConfiguration  Det valgfrie felt ObeStatus kan være 
til stede, men skal ikke benyttes af 
REDCR'en  
Fragmenterings-header  Ingen fragmentering  
Indstillinger for lag 2  Kommando-PDU, UI-kommando  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 572  
DSC_48  DSRC-køretøjsenheden  skal understøtte applikationen 
»Freight&Fleet«, som identificeres med applikationsidentifi­
katoren »2«. Andre applikationsidentifikatorer kan også 
understøttes, men behøver ikke være til stede i denne VST, 
eftersom BST kun kræver AID = 2. Feltet »Applikationer« 
indeholder en liste over de understøttede applikationsforekom­
ster i  DSRC-køretøjsenheden . For hver understøttet applika­
tionsforekomst indsættes der en henvisning til den relevante 
standard bestående af et RTM Context-mærke, der består af 
en OBJECT IDENTIFIER, som repræsenterer den tilhørende 
standard, dens del (9 for RTM) og eventuelt dens version, 
plus en EID, som genereres af DSRC-køretøjsenheden, og 
som er tilknyttet den pågældende applikationshændelse.  
Tabel 14.9 indeholder et praktisk eksempel på de indstillinger,  
der angives i tabel 14.8, med angivelse af bitkodninger.  
▼M3 
Tabel 14.9  
Initialisering — Eksempel på VST-rammeindhold
 Oktetnr : 
Attribut/Felt  Bit i oktet  Beskrivelse  
1 MARKØR  0111 1110  Startmarkør  
2 Privat LID  xxxx xxxx  Linkadresse på den speci­
fikke DSRC-køretøjsenhed  
3 xxxx xxxx  
4 xxxx xxxx  
5 xxxx xxxx  
6 MAC-kontrolfelt  1100 0000  Kommando-PDU  
7 LLC-kontrolfelt  0000 0011  UI-kommando  
8 Fragmenterings-header  1xxx x001  Ingen fragmentering  
9 VST 
SEQUENCE { 
Fill BIT STRING (SIZE(4))  1001  Initialiseringssvar  
0000  Ikke i brug og sat til 0  
10 Profile INTEGER (0..127,...) 
Applications SEQUENCE OF {  0000 0000  Ingen udvidelse. Eksem­
pelprofil 0 
Ingen udvidelse, 1 appli­
kation  11 0000 0001  
12 SEQUENCE { 
OPTION-indikator 
OPTION-indikator 
AID DSRCApplicationEntityID  1 EID til stede  
1 Parameter til stede  
00 0010  Ingen udvidelse. AID = 2 
Freight&Fleet  
13 EID Dsrc-EID  xxxx xxxx  Defineret inde i OBU'en 
og identificerer applika­
tionsforekomsten.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 573
 Oktetnr : 
Attribut/Felt  Bit i oktet  Beskrivelse  
14 Parameter Container {  0000 0010  Ingen udvidelse, Contai­
nervalg = 02, 
Oktetstreng  
15 0000 0110  Ingen udvidelse, længde 
af RTM-kontekstmarke­
ring = 6  
16 Rtm-ContextMark ::= SEQUENCE { 
StandardIdentifier  0000 0101  Første oktet er 05H, som 
er længden. 
Efterfølgende 5 oktetter 
koder objektidentifikator 
for den understøttede 
standard, del og version. 
{ISO (1) Standard (0) 
TARV (15638) part9(9) 
Version2 (2)}  17 standardIdentifier  0010 1000  
18 1111 1010  
19 0001 0110  
20 0000 1001  
21 0000 0010  
22 ObeConfiguration Sequence { 
OPTION-indikator  0 ObeStatus ikke til stede  
EquipmentClass INTEGER (0..32767)  xxx xxxx  Dette felt skal indeholde  
23 xxxx xxxx  fabrikantens angivelser af 
software-/hardwarever­
sionen for DSRC-inter­
facet  
24 ManufacturerId INTEGER (0..65535)  xxxx xxxx  Fabrikantidentifikator for 
DSRC-køretøjsenheden 
som beskrevet i ISO 
14816-registret  25 xxxx xxxx  
26 FCS  xxxx xxxx  Sekvens for rammekontrol  
27 xxxx xxxx  
28 Markør  0111 1110  Slutmarkør  
▼B 
DCS_49 Herefter læser REDCR'en dataene ved at udsende en 
GET-kommando, der er i overensstemmelse med GET- 
kommandoen, som defineres i EN 13372, 6.2, 6.3, 6.4 og 
EN 12834 med indstillinger som specificeret i tabel 14.10.  
Tabel 14.10  
Præsentation — Rammeindstillinger for GET-anmodning  
Felt Indstillinger  
Identifikator for aktiverende applika­
tionsenhed (IID)  Ikke til stede  
Linkidentifikator (LID)  Linkadresse på den specifikke DSRC- 
køretøjsenhed  
Sammenkædning  Nej  
Elementidentifikator (EID)  Som specificeret i VST. Ingen udvi­
delse ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 574  
Felt Indstillinger  
Adgangsoplysninger  Nej  
AttributeIdList  Ingen udvidelse, 1 attribut, Attribu­
teID = 1 (RtmData)  
Fragmentering  Nej  
Lag2-indstillinger  Kommando-PDU, Udsendt ACn- 
kommando  
Tabel 14.11 viser et eksempel på læsning af RTM-dataene.  
Tabel 14.11  
Præsentation — Eksempel på ramme for Get-anmodning
 Oktet nr. 
Attribut/Felt  Bit i oktet  Beskrivelse  
1 MARKØR
  Startmarkør  
2 Privat LID
  Linkadresse på den speci­
fikke 
DSRC-køretøjsenhed  3
 
4
 
5
 
6 MAC-kontrolfelt
  Kommando-PDU  
7 LLC-kontrolfelt
  Udsendt ACn-kommando, 
n bit  
8 Fragmenterings-header
  Ingen fragmentering  
9 Get.request 
SEQUENCE {
  Hent anmodning  
OPTION-indikator
  Adgangsoplysninger ikke 
til stede  
OPTION-indikator
  IID ikke til stede  
OPTION-indikator
  AttributeIdList til stede  
Fyld BIT STRING(SIZE(1))
  Sæt til 0.  
10 EID INTEGER(0..127,…)
  EID-for RTM-applika­
tionshændelsen som 
specificeret i VST. Ingen 
udvidelse  
11 AttributeIdList SEQUENCE OF { 
AttributeId }}
  Ingen udvidelse, antal 
attributter = 1  
12
 AttributeId=1, RtmData. 
Ingen udvidelse  
13 FCS
  Sekvens for rammekontrol  
14
 
15 Markør
  Slutmarkør  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 575  
DSC_50 Når  DSRC-køretøjsenheden  modtager GET-anmodningen, 
sender den et GET-svar med de ønskede data i henhold til 
GET-svaret som defineret i EN 13372, 6.2, 6.3, 6.4 and EN 
12834 med indstillinger som specificeret i tabel 14.12.  
Tabel 14.12  
Præsentation — Rammeindstillinger for GET-svar  
Felt Indstillinger  
Identifikator for aktiverende 
applikationsenhed (IID)  Ikke til stede  
Linkidentifikator (LID)  I henhold til EN 12834  
Sammenkædning  Nej  
Elementidentifikator (EID)  Som specificeret i VST.  
Adgangsoplysninger  Nej  
Fragmentering  Nej  
Lag2-indstillinger  Svar-PDU, Svar tilgængeligt 
og kommando accepteret, 
ACn-kommando  
Tabel 14.13 viser et eksempel på læsning af RTM-dataene.  
Tabel 14.13  
Præsentation — Eksempel på indhold af svarramme
 Oktet nr. 
Attribut/Felt  Bit i oktet  Beskrivelse  
1 MARKØR
  Startmarkør  
2 Privat LID
  Linkadresse på den speci­
fikke 
DSRC-køretøjsenhed  3
 
4
 
5
 
6 MAC-kontrolfelt
  Svar-PDU  
7 LLC-kontrolfelt
  Svar tilgængeligt, ACn- 
kommando n bit  
8 LLC-statusfelt
  Svar tilgængeligt og 
kommando accepteret  
9 Fragmenterings-header
  Ingen fragmentering  
10 Get.response 
SEQUENCE {
  Get response  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 576
 Oktet nr. 
Attribut/Felt  Bit i oktet  Beskrivelse  
OPTION-indikator
  IID ikke til stede  
OPTION-indikator
  Attributliste til stede  
OPTION-indikator
  Returstatus ikke til stede  
Fyld BIT STRING(SIZE(1))
  (ikke anvendt)  
11 EID INTEGER(0..127,…)
  Svar fra RTM-applika­
tionen  
Hændelse. Ingen udvidelse,  
12 AttributeList SEQUENCE OF {
  Ingen udvidelse, antal 
attributter = 1  
13 Attributter SEQUENCE { 
AttributeId
  Ingen udvidelse, Attribu­
teId=1 (RtmData)  
14 AttributeValue CONTAINER {
  Ingen udvidelse, Contai­
nervalg = 10  10 . 
15
 RtmData  
16
 
17
 
… …  
n }}}}
  
n + 1  FCS
  Sekvens for rammekontrol  
n + 2
  
n + 3  Markør
  Slutmarkør  
DSC_51 Herefter lukker REDCR'en forbindelsen ved at udsende en 
EVENT_REPORT_RELEASE-kommando i henhold til EN 
13372, 6.2, 6.3, 6.4 og EN 12834, 7.3.8 uden specifikke 
RTM-indstillinger. Tabel 14.14 viser et bitkodningseksempel 
på RELEASE-kommandoen.  
Tabel 14.14  
Afslutning. EVENT_REPORT Frigiv rammeindhold
 Oktet nr. 
Attribut/Felt  Bit i oktet  Beskrivelse  
1 MARKØR
  Startmarkør  
2 Privat LID
  Linkadresse på den speci­
fikke DSRC-køretøjs­
enhed  3
 
4
 ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 577
 Oktet nr. 
Attribut/Felt  Bit i oktet  Beskrivelse  
5
 
6 MAC-kontrolfelt
  Rammen indeholder en 
kommando-LPDU  
7 LLC-kontrolfelt
  UI-kommando  
8 Fragmenterings-header
  Ingen fragmentering  
9 EVENT_REPORT.request 
SEQUENCE {
  EVENT_REPORT 
(Release)  
OPTION-indikator
  Adgangsoplysninger ikke 
til stede  
OPTION-indikator
  Begivenhedsparameter 
ikke til stede  
OPTION-indikator
  IID ikke til stede  
Tilstand BOOLEAN
  Intet svar forventet  
10 EID INTEGER (0..127,…)
  Ingen udvidelse, EID = 0 
(System)  
11 EventType INTEGER (0..127,…) }
  Begivenhedstype 0 = 
Frigiv  
12 FCS
  Sekvens for rammekontrol  
13
 
14 Markør
  Slutmarkør  
DSC_52  DSRC-køretøjsenheden  forventes ikke at svare på RELEASE- 
kommandoen. Herefter afsluttes kommunikationen.  
5.4.8  Beskrivelse af DSRC-afprøvningstransaktion  
DSC_53 Fuldstændig afprøvning, der omfatter sikring af dataene,  skal 
gennemføres som defineret i tillæg 11, Fælles sikkerheds­
mekanismer, af godkendte personer med adgang til sikker­
hedsprocedurer ved hjælp af de normale GET-kommandoer, 
som defineres ovenfor.  
DSC_54 Idriftsættelse og periodiske inspektionsprøvninger, der kræver 
dekryptering og forståelse af det dekrypterede dataindhold, 
skal foretages som specificeret i tillæg 11, Fælles sikkerheds­
mekanismer, og tillæg 9, Typegodkendelsesliste over mini­
mumskrav vedrørende afprøvning.  
Den grundlæggende DSRC-kommunikation kan imidlertid 
afprøves med kommandoen ECHO. Sådanne afprøvninger 
kan være påkrævet ved idriftsættelse, ved periodiske inspek­
tioner eller på andre tidspunkter efter krav fra den kompetente  
kontrolmyndighed eller forordning (EU) nr. 165/2014 (Se 6 
nedenfor)  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 578  
DSC_55 For at udføre denne basale kommunikationsafprøvning 
udsteder REDCR ECHO-kommandoen under en session, 
dvs. når en initialiseringsfase er afsluttet planmæssigt. 
Sekvensen af interaktioner svarer derfor til en anmodning:  
— Trin 1  REDCR'en  sender en »Beacon Service Table« 
(BST), der indeholder applikationsidentifikatorerne 
(AID'er) på den tjenesteliste, som den understøtter. I 
RTM-applikationerne bliver dette ganske enkelt tjenesten 
med AID-værdien = 2.  
DSRC-køretøjsenheden  evaluerer den modtagne BST, og 
når den konstaterer, at BST'en forespørger Freight&Fleet 
(AID = 2), svarer DSRC-køretøjsenheden. Hvis  
REDCR'en  ikke sender AID = 2, afslutter  DSRC-køretøjs ­
enheden  sin transaktion med  REDCR'en . 
— Trin 2  DSRC-køretøjsenheden  sender en anmodning om 
tildeling af et privat vindue.  
— Trin 3 REDCR'en sender en tildeling af et privat vindue.  
— Trin 4  DSRC-køretøjsenheden  anvender det tildelte 
private vindue til at sende sin køretøjsservicetabel 
(Vehicle Service Table — VST). Denne VST indeholder 
en liste med alle de forskellige applikationsforekomster, 
som denne  DSRC-køretøjsenhed  understøtter i AID = 2- 
rammen. De forskellige forekomster identificeres ved 
hjælp af entydige EID'er, hver tilhørende en parameter­
værdi, der viser forekomsten af den understøttede 
applikation.  
— Trin 5 Derefter analyserer  REDCR'en  den tilbudte VST 
og afslutter enten forbindelsen (RELEASE), da den ikke 
er interesseret i noget af det, VST'en kan tilbyde (dvs. at 
den modtager en VST fra en  DSRC-køretøjsenhed , der er 
en RTM-køretøjsenhed, eller hvis den modtager en 
passende VST, starter den en app-forekomst.  
— Trin 6  REDCR'en  udsteder en kommando (ECHO) til den 
specifikke  DSRC-køretøjsenhed  og tildeler et privat 
vindue.  
— Trin 7  DSRC-køretøjsenheden  bruger det nye tildelte 
private vindue til at sende en ECHO-svarramme.  
Følgende tabeller indeholder et praktisk eksempel på en ECHO-ud veks­
lingssession.  
DSC_56 Initialiseringen udføres i henhold til 5.4.7 (DSC_44-DSC _48) 
og tabel 14.4-14.9.  
DSC_57 Herefter udsteder REDCR'en en ECHO-kommando i henhold 
til ISO 14906, der indeholder 100 dataoktetter, og uden speci­
fikke indstillinger for RTM. Tabel 14.15 viser indholdet af 
den ramme, som REDCR'en sender.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 579  
Tabel 14.15  
Eksempel på ramme for ACTION, ECHO-anmodning
 Oktet nr. 
Attribut/Felt  Bit i oktet  Beskrivelse  
1 MARKØR
  Startmarkør  
2 Privat LID
  Linkadresse på den speci­
fikke DSRC-køretøjsenhed  
3
 
4
 
5
 
6 MAC-kontrolfelt
  Kommando-PDU  
7 LLC-kontrolfelt
  Udsendt ACn-kommando, 
n bit  
8 Fragmenterings-header
  Ingen fragmentering  
9 ACTION.request 
SEQUENCE {
  Anmodning om handling 
(ECHO)  
OPTION-indikator
  Adgangsoplysninger ikke 
til stede  
OPTION-indikator
  Handlingsparameter til 
stede  
OPTION-indikator
  IID ikke til stede  
Tilstand BOOLEAN
  Svar forventet  
10 EID INTEGER (0..127,…)
  Ingen udvidelse, EID = 0 
(System)  
11 ActionType INTEGER (0..127,…)
  Ingen udvidelse, anmod­
ning om handlingstypen 
ECHO  
12 ActionParameter CONTAINER {
  Ingen udvidelse, Contai­
nervalg = 2  
13
 Ingen udvidelse. Streng­
længde = 100 oktetter  
14
 Data, der skal besvares  
… …  
113 } }
  
114 FCS
  Sekvens for rammekontrol  
115
 
116 Markør
  Slutmarkør  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 580  
DSC_58 Når  DSRC-køretøjsenheden  modtager ECHO-anmodningen, 
sender den et ECHO-svar på 100 dataoktetter ved at 
gentage den modtagne kommando i henhold til ISO 14906 
uden specifikke indstillinger for RTM. Tabel 14.16 viser et 
eksempel på bitniveaukodning.  
Tabel 14.16  
Eksempel på ramme for ACTION, ECHO-svar
 Oktet nr. 
Attribut/Felt  Bit i oktet  Beskrivelse  
1 MARKØR
  Startmarkør  
2 Privat LID
  Linkadresse på den speci­
fikke køretøjsenhed  
3
 
4
 
5
 
6 MAC-kontrolfelt
  Svar-PDU  
7 LLC-kontrolfelt
  ACn-kommando n bit  
8 LLC-statusfelt
  Svar tilgængeligt  
9 Fragmenterings-header
  Ingen fragmentering  
10 ACTION.response 
SEQUENCE {
  ACTION-svar (ECHO)  
OPTION-indikator
  IID ikke til stede  
OPTION-indikator
  Svarparameter til stede  
OPTION-indikator
  Returstatus ikke til stede  
Fyld BIT STRING (SIZE (1))
  (ikke anvendt)  
11 EID INTEGER (0..127,…)
  Ingen udvidelse, EID = 0 
(System)  
12 ResponseParameter CONTAINER {
  Ingen udvidelse, Contai­
nervalg = 2  
13
 Ingen udvidelse. Streng­
længde = 100 oktetter  
14
 Besvarede data  
… …  
113 } }
  
114 FCS
  Sekvens for rammekontrol  
115
 
116 Markør
  Slutmarkør  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 581  
5.5 Forbeholdt fremtidig brug  
▼M2 __________  
▼B 
5.6 Dataoverførsel mellem DSRC-køretøjsenheden og køretøjsenheden  
5.6.1  Fysisk forbindelse og interfaces  
DSC_66 Forbindelsen mellem  køretøjsenheden  o g DSRC-køretøjs ­
enheden  kan enten etableres med et fysisk kabel eller med 
trådløs kommunikation med kort rækkevidde baseret på Blue­
tooth v4.0 BLE.  
DSC_67 Uanset valget af den fysiske forbindelse og interfacet s kal 
følgende krav være opfyldt:  
DSC_68  ►M1 a) For at give mulighed for at bestille køretøjs­
enheden og DSRC-køretøjsenheden og forskellige 
partier af DSRC-køretøjsenheder fra forskellige 
leverandører skal forbindelsen mellem køretøjs­
enheden og DSRC-køretøjsenheden, som ikke er 
integreret i køretøjsenheden, være en åben stan­
dardforbindelse. Køretøjsenheden forbindes enten 
med DSRC-køretøjsenheden ◄  
i) via et fast kabel på mindst 2 m, hvorpå der er 
monteret et lige DIN 41612 H11-stik — 
godkendt hanstik med 11 stikben fra 
DSRC-køretøjsenheden, så den passer til et 
tilsvarende DIN/ISO-godkendt hunstik fra 
køretøjsenheden  
ii) ved hjælp af Bluetooth Low Energy (BLE)  
iii) ved hjælp af en standard ISO 11898- eller SAE 
J1939-forbindelse.  
DSC_69 b) Definitionen af interfacene og forbindelsen mellem kø re­
tøjsenheden og DSRC-køretøjsenheden skal understøtte 
kommandoerne til applikationsprotokollen, som defineres 
i 5.6.2.  
DSC_70 c) Køretøjsenheden og DSRC-køretøjsenheden skal under­
støtte dataoverførsel via forbindelsen for så vidt angår 
ydelse og strømforsyning.  
5.6.2  Applikationsprotokol  
DSC_71 Applikationsprotokollen mellem køretøjsenhedens fjernkom ­
munikationsudstyr og DSRC-køretøjsenheden skal periodisk 
overføre data fra fjernkommunikationsudstyret til DSRC'en.  
DSC_72 Følgende centrale kommandoer er identificeret:  
1. Initialisering af kommunikationsforbindelsen — Anmod­
ning 
2. Initialisering af kommunikationsforbindelsen — Svar  
3. Send Data med RTM-applikationens identifikator og 
dataindhold defineret ved RTM-data  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 582  
4. Bekræftelse af dataene  
5. Afslutning af kommunikationsforbindelsen — Anmodning  
6. Afslutning af kommunikationsforbindelsen — Svar.  
DSC_73 I ASN1.0 kan de forudgående kommandoer være defineret 
som:
  
DSC_74 Kommandoerne og parametrene beskrives som følger:  
—
 
bruges til at initialisere kommunikationsforbindelsen. 
Køretøjsenheden sender kommandoen til DSRC-køretøjs­
enheden. LinkIdentifier fastsættes af køretøjsenheden og 
kommunikeres til DSRC-køretøjsenheden for at spore en 
bestemt kommunikationsforbindelse.  
(Bemærk: Dette sker for at understøtte fremtidige forbin­
delser og andre applikationer/moduler som Weighing on 
board).  
—
 
bruges af DSRC-køretøjsenheden til at sende svaret på 
anmodningen om at initialisere kommunikationsforbin­
delsen. DSRC-køretøjsenheden sender kommandoen til 
køretøjsenheden. Kommandoen giver resultatet af initiali­
seringen som svar 1 (lykkedes) eller 0 (mislykkedes).  
DSC_75 Initialiseringen af kommunikationsforbindelsen foretages  først 
efter installering, kalibrering og start af motor/køretøjsenhed . ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 583  
—
 bruges af køretøjsenheden til at 
sende de underskrevne RCDT-data (dvs.  fjernkommunika ­
tionsdataene ) til DSRC-køretøjsenheden. Dataene sendes 
hvert 60. sekund. Parameteren DataTransactionId identifi­
cerer den specifikke transmission af data. LinkIdentifier 
bruges også til at sikre, at den pågældende forbindelse 
er korrekt.  
—
 sendes af DSRC- 
køretøjsenheden for at give feedback til køretøjsenheden 
om modtagelse af data fra en
  ­
-kommando, som identificeres af DataTransactionId-para­
meteren. Svarparameteren er 1 (lykkedes) eller 0 (mislyk­
kedes). Hvis en bevægelsessensor modtager mere end tre 
svar på 0, eller hvis køretøjsenheden ikke modtager en 
RCDT-databekræftelse for en bestemt tidligere fremsendt 
RCDT-Send Data med en specifik DataTransactionId, 
genererer og registrerer køretøjsenheden en hændelse.  
—
 sendes af 
køretøjsenheden til DSRC-køretøjsenheden for at afslutte 
en forbindelse for en bestemt LinkIdentifier.  
DSC_76 Ved genstart af DSRC-køretøjsenheden eller en bevægelses ­
sensor skal alle eksisterende kommunikationsforbindelser 
afbrydes, da der kan være forbindelser, der »hænger« som 
følge af en pludselig nedlukning af en bevægelsessensor.  
—
 !sendes af 
DSRC-køretøjsenheden til køretøjsenheden for at bekræfte 
køretøjsenhedens anmodning om afbrydelse af forbin­
delsen for den specifikke LinkIdentifier.  
5.7 Fejlhåndtering  
5.7.1  Registrering og kommunikation af data i DSRC-køretøjsenheden  
▼M3 
DSC_77  Dataene  skal leveres af  VUSM -funktionen til DSRC-køretøjs­
enheden og skal allerede være sikrede.  VUSM'en  kontrollerer, 
at dataene, der er registreret i  DSRC-køretøjsenheden , er 
blevet overført til DSRC-køretøjsenheden. Registrering og 
indberetning af eventuelle fejl i dataoverførslen fra  køretøjs­
enheden  til DSRC-køretøjsenhedens  hukommelse skal regi­
streres med typen EventFaultType og en enum-værdi på 
»0C«H kommunikationsfejl ved fjernkommunikation 
sammen med tidsstemplet.  VUSM 'en kontrollerer, at dataene 
er blevet overført til DSRC-køretøjsenheden.  
DSC_78 Forbeholdt fremtidig brug.  
▼B 
DSC_79 Hvis VUPM'en forsøger at hente køretøjsenhedsdata fra 
sikkerhedsmodulet (for at sende dem videre til DSRC-køre­
tøjsenheden), men dette ikke lykkes, registrerer den denne fejl  
med typen EventFaultType og en enum-værdi på  »62«H 
kommunikationsfejl ved fjernkommunikation  sammen med  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 584  
tidsstemplet. Kommunikationsfejlen detekteres, når der ikke 
modtages en
  -meddelelse for 
den tilhørende (dvs. med det samme DataTransactionId 
i meddelelserne
  )
  
mere end tre på hinanden følgende 
gange.  
5.7.2  Fejl i trådløs kommunikation  
DSC_80 Håndteringen af kommunikationsfejl skal ske i henhold ti l de 
tilhørende DSRC-standarder, dvs. EN 300 674-1, EN 12253, 
EN 12795, EN 12834 og de tilhørende parametre i EN 13372.  
5.7.2.1  Krypterings- og underskriftfejl  
DSC_81 Krypterings- og signaturfejl skal håndteres som definere t i 
tillæg 11, Fælles sikkerhedsmekanismer, og findes ikke i 
nogen fejlmeddelelser i forbindelse med DSRC-dataoverfør­
slen. 
5.7.2.2  Fejlregistrering  
DSRC-mediet er en dynamisk trådløs kommunikation i et miljø med  
usikre atmosfæriske forhold og interferensforhold, navnlig i ko mbinatio­
nerne »transportabel REDCR« og »køretøj i bevægelse«, som denne  
applikation omfatter. Derfor er det nødvendigt at vurdere forsk ellen 
mellem en »læsefejl«- og en »fejl«-tilstand. I en transaktion v ia et tråd­
løst interface er læsefejl almindelige, og konsekvensen er norm alt, at 
man prøver igen, dvs. at BST'en sendes igen, og man forsøger 
sekvensen igen, og i de fleste tilfælde vil det føre til en vel lykket 
kommunikationsforbindelse og dataoverførsel, medmindre det pågæ l­
dende køretøj bevæger sig uden for rækkevidde i løbet af det ti ds­
interval, som er nødvendigt for at sende dataene igen (en »vell ykket« 
»læsning« kan have omfattet flere forsøg og gentagelser).  
Læsefejl kan skyldes, at antennerne ikke var parret korrekt (»s igtefejl«), 
at en af antennerne er skærmet — dette kan være bevidst, men ka n også 
skyldes, at et andet køretøj er fysisk til stede, radiointerfer ens, navnlig 
fra omkring 5,8 GHz WIFI eller andre typer af trådløs kommunika tion 
med offentlig adgang, eller at der forekommer radarinterferens eller 
problematiske atmosfæriske forhold (f.eks. under et tordenvejr)  eller 
ganske enkelt, fordi man bevæger sig uden for DSRC-kommunikatio ns­
udstyrets rækkevidde. Individuelle forekomster af læsefejl kan i sagens 
natur ikke registreres, fordi kommunikationen ganske enkelt ikk e finder 
sted. 
Men hvis repræsentanten for den kompetente kontrolmyndighed ret ter 
opmærksomheden mod et køretøj og forsøger at sende en anmodning  til 
dets DSRC-køretøjsenhed , men der sker ikke nogen vellykket dataover­
førsel, kan fejlen være opstået som følge af bevidst manipulati on, og 
derfor har repræsentanten for den kompetente kontrolmyndighed b ehov 
for et værktøj til at logge fejlen og gøre kollegerne længere h enne 
opmærksom på, at der kan være tale om en overtrædelse. Herefter  kan 
kollegerne standse køretøjet og foretage en fysisk inspektion. Men 
eftersom der ikke er foregået nogen vellykket kommunikation, ka n 
DSRC-køretøjsenheden ikke levere data vedrørende fejlen. Denne 
rapportering skal derfor være en funktion i designet af REDCR-u dstyret.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 585  
»Læsefejl« er teknisk set forskellig fra en »fejl«. I denne for bindelse er 
en »fejl« indhentning af en forkert værdi.  
Data, der overføres til  DSRC-køretøjsenheden , leveres i en allerede sikret 
form, og skal derfor verificeres af dataleverandøren (se 5.4).  
Data, der efterfølgende overføres via luft-interfacet, kontroll eres med 
cykliske redundanskontroller (CRC) på kommunikationsniveau. Hvi s 
CRC valideres, er dataene korrekte. Hvis CRC ikke valideres, se ndes 
dataene igen. Sandsynligheden for, at data kan slippe forkert i gennem en 
CRC, er statistisk set så lille, at den lades ude af betragtnin g. 
Hvis CRC'en ikke valideres, og der ikke er tid til at gensende og 
modtage de korrekte data, bliver resultatet ikke en fejl, men e n fore­
komst af en bestemt type læsefejl.  
De eneste meningsfulde »fejl«-data, der kan registreres, er ant allet af 
vellykkede transaktionsindledninger, der forekommer, og som ikk e 
fører til en vellykket overførsel af data til REDCR.  
DSC_82  REDCR'en  registrerer og tidsstempler derfor antallet af 
tilfælde, hvor »initialiseringsfasen« for en DSRC-anmodning 
lykkes, men hvor transaktionen afsluttes, inden REDCR'en 
har modtaget  dataene . Disse data skal være tilgængelige for 
repræsentanten for den kompetente kontrolmyndighed og skal 
gemmes i REDCR-udstyrets hukommelse. Dette opnås ved 
hjælp af produktets udformning eller i henhold til specifika­
tionen fra en kompetent kontrolmyndighed.  
De eneste meningsfyldte »fejl«-data, der kan registreres, er 
antallet af tilfælde, hvor REDCR'en ikke kan dekryptere de 
modtagne  data . Det skal imidlertid bemærkes, at dette udeluk­
kende vil vedrøre effektiviteten af REDCR'ens software. Data 
kan dekrypteres teknisk, men uden at give mening rent 
semantisk.  
DSC_83  REDCR'en  skal derfor registrere og tidsstemple antallet af 
tilfælde, hvor den har forsøgt af dechifrere data modtaget 
via DSRC-interfacet, men hvor dette er mislykkedes.  
6 IDRIFTSÆTTELSE OG PERIODISKE INSPEKTIONSAFPRØV­
NINGER FOR FJERNKOMMUNIKATIONSFUNKTIONEN  
6.1 Generelt  
DSC_84 Der er mulighed for to typer afprøvning af fjernkommunik a­
tionsfunktionen:  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 586  
1) En ECHO-afprøvning for at validere den trådløse kommu­
nikationskanal mellem  DSRC-REDCR  >>-:-< DSRC-køre ­
tøjsenheden . 
2) En ende-til-ende-sikkerhedsafprøvning for at sikre, at der 
forefindes et værkstedskort, der giver mulighed for at få 
adgang til det krypterede og underskrevne dataindhold, 
som køretøjsenheden har genereret og transmitteret via 
den trådløse kommunikationskanal.  
6.2 ECHO  
Dette punkt indeholder bestemmelser, der er udformet specifikt til kun at 
afprøve, om  DSRC-REDCR  >>-:-< DSRC-køretøjsenheden  er funktionelt 
aktiv.  
Formålet med ECHO-kommandoen er at give værksteder eller prøve­
anlæg til typegodkendelse mulighed for at efterprøve, at DSRC-f orbin­
delsen fungerer uden at kræve adgang til sikkerhedsoplysninger.  Derfor 
skal afprøvningsudstyret kun være i stand til at initialisere e n 
DSRC-kommunikation (at sende en BST med AID = 2) og derefter 
sende ECHO-kommandoen, og, hvis man antager, at DSRC'en virker,  
modtage ECHO-svaret. Se 5.4.8 for nærmere oplysninger. Idet man  går 
ud fra, at dette svar modtages korrekt, kan DSRC-forbindelsen ( DSRC- 
REDCR  >>-:-< DSRC-køretøjsenheden ) valideres som fungerende 
korrekt.  
6.3 Afprøvning til validering af sikkert dataindhold  
DSC_85 Dette afprøvning gennemføres for at validere ende-til-en de- 
sikkerheden for datastrømmen. Der er behov for en 
DSRC-testlæser til en sådan afprøvning. DSRC-testlæseren 
udfører den samme funktion, og anvendes med de samme 
specifikationer som den læser, de retshåndhævende myndig­
heder benytter, med den forskel, at der skal benyttes et værk­
stedskort til at godkende brugeren af DSRC-testlæseren i 
stedet for et kontrolkort. Afprøvningen kan udføres efter 
den indledende aktivering af en intelligent takograf eller ved 
afslutningen af kalibreringsproceduren. Efter aktiveringen 
genererer køretøjsenheden de sikrede data til tidlig fjernafslø ­
ring og sender disse til DSRC-køretøjsenheden.  
DSC_86 Værkstedspersonalet skal anbringe DSRC-testlæseren i en 
afstand af mellem 2 og 10 meter foran køretøjet.  
DSC_87 Herefter isætter værkstedspersonalet et værkstedskort i 
DSRC-testlæseren for at anmode køretøjsenheden om data 
vedrørende tidlig fjernafsløring. Efter en vellykket anmodning 
går værkstedspersonalet ind i dataene for at sikre, at de er 
dekrypterede og valideret korrekt for så vidt angår 
integriteten.  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 587  
Addendum  
Regler for beregning af daglig køretid, ugentlig køretid og kør etid for 14 dage  
1. Grundlæggende beregningsregler  
Køretøjsenheden beregner den daglige køretid, den ugentlige kør etid og køre­
tiden for 14 dage ved hjælp af relevante data, der er lagret på  et førerkort 
(eller værkstedskort), der er isat i førerens kortplads (kortpl ads 1, kortlæser 
#1) i køretøjsenheden, og udvalgte føreraktiviteter, mens korte t er isat i køre­
tøjsenheden.  
Køretiderne beregnes ikke, når der ikke er isat et førerkort (e ller værksteds­
kort).  
UKENDTE perioder i den periode, der skal bruges til beregninger ne, side­
stilles med PAUSE/HVILE.  
UKENDTE perioder og aktiviteter af negativ varighed (dvs. aktiv itetens start 
finder sted senere end aktivitetens afslutning) på grund af tid soverlapninger 
mellem to forskellige køretøjsenheder eller på grund af tidsjus tering 
medregnes ikke.  
Aktiviteter, der registreres på førerkortet svarende til »UDEN FOR GYLDIG­
HEDSOMRÅDE«-perioder i overensstemmelse med definition gg) i bi lag I C, 
fortolkes på følgende måde:  
— PAUSE/HVILE beregnes som »PAUSE« eller »HVILE«  
— ARBEJDE og KØRSEL anses for »ARBEJDE«  
— RÅDIGHED anses for »RÅDIGHED«  
I forbindelse med dette addendum antages det i køretøjsenheden,  at der er en 
daglig hviletid ved begyndelsen af kortaktiviteterne.  
2. Begreber  
Følgende begreber finder udelukkende anvendelse på dette tillæg  og har til 
formål at specificere køretøjsenhedens beregning af køretiderne  og dens senere 
overførsel via fjernkommunikationsudstyret:  
a) »RTM-skift«: perioden mellem afslutningen af en daglig hvile tid og afslut­
ningen af den umiddelbart efterfølgende daglige hviletid.  
Køretøjsenheden påbegynder et nyt RTM-skift, når en daglig hvil etid er 
afsluttet.  
Det igangværende RTM-skift er perioden siden sidste daglige hvi letids 
afslutning  
b) »akkumuleret køretid«: summen af varigheden af alle førerens  KØRSELs­
aktiviteter i en periode, som ikke er UDEN FOR GYLDIGHEDS­
OMRÅDE  
c) »daglig køretid«: den akkumulerede køretid inden for et RTM- skift 
d) »ugentlig køretid«: den akkumulerede køretid i den indeværen de uge  
e) »sammenhængende hviletid«: enhver uafbrudt periode med PAUSE / 
HVILE  
f) »køretid for 14 dage«: den akkumulerede køretid for den fore gående og 
den indeværende uge  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 588  
g) »daglig hviletid«: en periode med PAUSE/HVILE, som kan være enten  
— en regulær daglig hviletid  
— en opdelt daglig hviletid eller  
— en reduceret daglig hviletid.  
I forbindelse med tillæg 14 anses disse ugentlige hviletider fo r daglige 
hviletider, når en køretøjsenhed beregner de ugentlige hviletid er 
h) »regulær daglig hviletid«: en sammenhængende hviletid på min dst 11 
timer.  
Når tilstanden OVERFART MED FÆRGE/TOG er aktiv, kan den regu­
lære daglige hviletid undtagelsesvis afbrydes højst to gange af  andre akti­
viteter end hvile med en maksimal akkumuleret varighed på en ti me. Det 
betyder, at en regulær daglig hviletid, der opfatter perioder m ed overfart 
med færge/tog, kan opdeles i to eller tre dele. Køretøjsenheden  beregner 
derefter en regulær daglig hviletid, når den akkumulerede hvile tid ifølge 
punkt 3 er på mindst 11 timer.  
Når en regulær daglig hviletid er blevet afbrudt, skal køretøjs enheden:  
— ikke medregne den kørselsaktivitet, der er udført under disse  afbry­
delser, ved beregningen af den daglige køretid  
— påbegynde et nyt RTM-skift ved afslutningen af den regulære d aglige 
hviletid, som er blevet afbrudt.  
Figur 1  
Eksempel på daglig hviletid afbrudt på grund af overfart med færge/tog
  
i) »reduceret daglig hviletid«: en sammenhængende hviletid på m indst ni 
timer og mindre end 11 timer  
j) »opdelt daglig hviletid«: en daglig hviletid fordelt på to d ele: 
— den første del er en sammenhængende hviletid på mindst tre ti mer og 
mindre end ni timer  
— den anden del er en sammenhængende hviletid på mindst ni time r. 
Når tilstanden OVERFART MED FÆRGE/TOG er aktiv under en eller 
begge dele af en opdelt daglig hviletid, kan den opdelte daglig e hviletid 
undtagelsesvis afbrydes højst to gange af andre aktiviteter med  en akku­
muleret varighed på højst én time, dvs.:  
— den første del af den opdelte daglige hviletid kan afbrydes e n eller to 
gange, eller  
— den anden del af den opdelte daglige hviletid kan afbrydes en  eller to 
gange, eller  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 589  
— den første del af den opdelte daglige hvileperiode kan afbryd es én 
gang, og den anden del af den opdelte daglige hvileperiode kan 
afbrydes én gang.  
Køretøjsenheden beregner derefter en opdelt daglig hviletid, nå r den akku­
mulerede hviletid ifølge punkt 3 er:  
— på mindst tre timer og mindre end 11 timer for den første hvi letid og 
mindre end ni timer for den anden hviletid, når den første hvil etid er 
blevet afbrudt af en OVERFART MED FÆRGE/TOG.  
— på mindst tre timer og mindre end ni timer for den første hvi letid og 
mindst ni timer for den anden hviletid, når den første hviletid  ikke er 
blevet afbrudt af en OVERFART MED FÆRGE/TOG.  
Figur 2  
Eksempel på opdelt daglig hviletid afbrudt på grund af overfart med færge/tog
  
Når en opdelt daglig hviletid er blevet afbrudt, skal køretøjse nheden:  
— ikke medregne den kørselsaktivitet, der er udført under disse  afbry­
delser, ved beregningen af den daglige køretid  
— påbegynde et nyt RTM-skift ved afslutningen af den opdelte da glige 
hviletid, som er blevet afbrudt  
k) »uge«: tidsrummet fra mandag kl. 00:00 UTC til søndag kl. 24 :00 UTC.  
3. Beregning af hviletiden, når den er blevet afbrudt på grund af overfart med 
færge/tog  
For at beregne hviletiden, når den er blevet afbrudt på grund a f overfart med 
færge/tog, beregner køretøjsenheden den akkumulerede hviletid e fter følgende 
trin: 
a) Trin 1  
Køretøjsenheden skal registrere afbrydelser af hviletiden før a ktiveringen af 
flaget OVERFART MED FÆRGE/TOG (START) ifølge figur 3 og i givet  
fald figur 4 og for hver registreret afbrydelse vurdere, om føl gende betin­
gelser er opfyldt:  
— afbrydelsen bevirker, at den samlede varighed af de registrer ede afbry­
delser, herunder i givet fald afbrydelser i den første del af e n opdelt 
daglig hviletid som følge af en overfart med færge/tog, oversti ger mere 
end én time i alt  
— afbrydelsen bevirker, at det samlede antal registrerede afbry delser, 
herunder i givet fald afbrydelser i den første del af en opdelt  daglig 
hviletid som følge af en overfart med færge/tog, overstiger to  
— der er lagret en »Indlæsning af de steder, hvor den daglige a rbejdstid 
slutter« efter afbrydelsens ophør.  
Hvis ingen af ovennævnte betingelser er opfyldt, lægges den sam menhæn­
gende hviletid umiddelbart forud for afbrydelsen til den akkumu lerede 
hviletid.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 590  
Hvis mindst én af ovennævnte betingelser er opfyldt, skal køret øjsenheden 
stoppe beregningen af den akkumulerede hviletid efter trin 2 el ler registrere 
afbrydelser af hviletiden, der sker efter aktivering af flaget med OVER­
FART MED FÆRGE/TOG (START) under trin 3.  
b) Trin 2  
For hver afbrydelse, der registreres under trin 1, vurderer kør etøjsenheden, 
om beregningen af den akkumulerede hviletid skal standses. Køre tøjs­
enheden standser beregningen, når to sammenhængende hviletider,  der 
finder sted før aktiveringen af flaget OVERFART MED FÆRGE/TOG 
(START), er blevet føjet til den akkumulerede hviletid, herunde r i givet 
fald hviletider, der er tilføjet i den første del af en opdelt daglig hviletid, 
der også er afbrudt af en overfart med færge/tog. Ellers fortsæ tter køre­
tøjsenheden til trin 3.  
c) Trin 3  
Hvis køretøjsenheden efter udførelsen af trin 2 fortsætter bere gningen af 
den akkumulerede hviletid, skal køretøjsenheden registrere afbr ydelser, der 
sker efter deaktivering af betingelsen OVERFART MED FÆRGE/TOG 
ifølge figur 3 og i givet fald figur 4.  
For hver registreret afbrydelse skal køretøjsenheden vurdere, o m afbry­
delsen bevirker, at den akkumulerede tid for alle registrerede afbrydelser 
overstiger mere end én time i alt. I så fald afsluttes beregnin gen af den 
akkumulerede hviletid ved afslutningen af den sammenhængende hv iletid 
før afbrydelsen. Ellers lægges de sammenhængende hviletider, de r finder 
sted efter de respektive afbrydelser, lægges til beregningen af  den daglige 
hviletid, indtil betingelsen i trin 4 er opfyldt.  
d) Trin 4  
Beregningen af den akkumulerede hviletid stoppes, når køretøjse nheden 
som resultat af trin 1 og 3 har lagt højst to sammenhængende hv iletider 
til den hviletid, for hvilken betingelsen OVERFART MED FÆRGE/TO G 
er aktiveret, herunder i givet fald afbrydelser i den første de l af en opdelt 
hviletid på grund af en overfart med færge/tog.  
Figur 3  
Køretøjsenhedens behandling af hviletider med henblik på at afgøre, om en afbrudt hviletid skal 
medregnes som en regulær daglig hviletid eller som den første del af en opdelt daglig hviletid
  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 591  
Figur 4  
Køretøjsenhedens behandling af hviletider med henblik på at afgøre, om en afbrudt hviletid skal 
medregnes som anden del af en opdelt daglig hviletid
  
Figur 5  
Eksempel på en daglig hviletid, der er afbrudt mere end to gange, således at hviletiden H ikke medregnes
  
Figur 6  
Eksempel på en daglig hviletid, hvor beregningen af en overfart med færge/tog blev påbegyndt ved 
arbejdstidens afslutning
  
Figur 7  
Eksempel på en daglig hviletid, der er afbrudt mere end to gange, således at hviletiden B ikke medregnes
  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 592  
Figur 8  
Eksempel på en opdelt daglig hviletid, der er afbrudt én gang i løbet af den første hviletid og én gang i 
løbet af den anden hviletid
  
4. Beregning af daglig køretid, ugentlig køretid og køretid for  14 dage  
Køretøjsenheden beregner den eller de daglige køretider for det  igangværende 
og tidligere RTM-skift. Den køretid, der finder sted under afbr ydelserne af de 
daglige hviletider, lægges ikke til beregningen af den daglige køretid, når 
sådanne afbrydelser skyldes overfart med færge/tog, og kravene i punkt 2, 
litra h) og j), og punkt 3 er opfyldt. Hvis køretøjsenheden ikk e har beregnet 
en fuldstændig regulær eller opdelt daglig hviletid ifølge punk t 3, lægges de 
køretider, der finder sted under afbrydelserne, til den daglige  køretid for det 
igangværende RTM-skift.  
Køretøjsenheden beregner også den ugentlige køretid og køretide n for 14 
dage. Den køretid, der finder sted under afbrydelserne af de da glige hviletider 
på grund af overfart med færge/tog, lægges til beregningen af d en ugentlige 
køretid og køretiden for 14 dage.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 593  
Tillæg 15  
MIGRATION: FORVALTNING AF SAMEKSISTENSEN AF 
UDSTYRSGENERATIONER OG -VERSIONER  
▼B 
INDHOLDSFORTEGNELSE  
1. DEFINITIONER  
2. ALMINDELIGE BESTEMMELSER  
2.1. Oversigt over overgangen  
▼M3 
2.2. Interoperabilitet mellem køretøjsenhed og kort  
▼B 
2.3. Interoperabilitet mellem køretøjsenhed og bevægelsesføler  
2.4. Interoperabilitet mellem køretøjsenheder, takografkort og udstyr til data­
overførsel  
2.4.1 IDE'ens direkte overførsel af kort  
2.4.2 Overførsel af kort via en køretøjsenhed  
2.4.3 Overførsel fra køretøjsenhed  
2.5. Interoperabilitet mellem køretøjsenhed og kalibreringsudst yr 
3. VIGTIGSTE SKRIDT I PERIODEN OP TIL INDFØRELSESDATOEN  
4. BESTEMMELSER I PERIODEN EFTER INDFØRELSESDATOEN  
▼M3 
5. REGISTRERING AF GRÆNSEPASSAGER I TAKOGRAFER AF 
FØRSTE GENERATION OG TAKOGRAFER AF FØRSTE VERSION 
AF ANDEN GENERATION  
▼B 
1. DEFINITIONER  
I dette tillæg anvendes følgende definitioner.  
digitalt takografsystem:  som defineret i dette bilag (kapitel 1: definition 
bbb) 
digitalt takografsystem af første generation:  som defineret i denne 
forordning (kapitel 2: definition b)  
digitalt takografsystem af anden generation:  som defineret i denne 
forordning (kapitel 2: definition j)  
indførelsesdato:  som beskrevet i dette bilag (kapitel 1: definition ccc)  
intelligent dedikeret udstyr (IDE):  udstyr, der anvendes til at foretage 
dataoverførsel som defineret i tillæg 7 i dette bilag.  
▼M3 
2. ALMINDELIGE BESTEMMELSER  
2.1. Oversigt over overgangen  
I indledningen til dette bilag gives der oversigt over overgang en mellem 
digitale takografsystemer af første og anden generation, og and en version 
af kontrolapparater og takografkort af anden generation introdu ceres.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 594  
Ud over bestemmelserne i denne indledning fremhæves følgende 
oplysninger:  
— bevægelsesfølere af første generation er ikke interoperable m ed køre­
tøjsenheder af anden generation, uanset version  
— kun bevægelsesfølere af anden generation kan installeres i kø retøjer, 
der er udstyret med køretøjsenheder af anden generation, uanset  
version  
— udstyr til dataoverførsel og kalibrering skal understøtte beg ge genera­
tioner eller versioner af kontrolapparat og takografkort.  
2.2. Interoperabilitet mellem køretøjsenhed og kort  
Det forudsættes, at første generation af takografkort er intero perable med 
køretøjsenheder af første generation i henhold til bilag I B ti l forordning 
(EØF) nr. 3821/85, mens takografkort af anden generation, uanse t version, 
er interoperable med køretøjsenheder af anden generation, uanse t version, i 
henhold til bilag I C til denne forordning). Desuden gælder føl gende krav.  
MIG_001 Bortset fra bestemmelserne i krav MIG_004 og MIG_005 ka n 
takografkort af første generation fortsat benyttes i køretøjs­
enheder af anden generation, uanset version, indtil deres 
gyldighedsperiode udløber. Indehaverne kan imidlertid 
anmode om at få dem udskiftet med takografkort af anden 
generation, så snart disse er til rådighed.  
MIG_002 Køretøjsenheder af anden generation, uanset version, sk al 
kunne anvende et hvilket som helst gyldigt fører-, kontrol- 
og virksomhedskort, der isættes.  
MIG_003 Værksteder kan ophæve denne mulighed i sådanne køretøjs ­
enheder, så takografkort af første generation ikke længere kan 
benyttes. Dette kan først ske, når Kommissionen har iværksat 
en procedure, der giver mulighed for at anmode værkstederne 
om at gøre dette, f.eks. under den periodiske inspektion af 
kontrolapparatet.  
MIG_004 Køretøjsenheder af anden generation må kun kunne anvend e 
værkstedskort af anden generation.  
MIG_005 Med henblik på at fastlægge funktionstilstanden skal kø retøjs­
enheder af anden generation, uanset version, udelukkende tage 
hensyn til typerne af de isatte gyldige kort, uanset generation  
eller version.  
MIG_006 Et gyldigt takografkort af anden generation, uanset ver sion, 
skal kunne benyttes i køretøjsenheder af første generation på 
præcis samme måde som et takografkort af første generation 
af samme type.  
2.3. Interoperabilitet mellem køretøjsenhed og bevægelsesføler  
Det forudsættes, at bevægelsesfølere af første generation er in teroperable 
med køretøjsenheder af første generation, mens bevægelsesfølere  af anden 
generation er interoperable med køretøjsenheder af anden genera tion, 
uanset version. Desuden gælder følgende krav.  
MIG_007 Køretøjsenheder af anden generation, uanset version, ka n ikke 
parres og anvendes med bevægelsesfølere af første generation.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 595  
MIG_008 Bevægelsesfølere af anden generation kan kun parres og 
anvendes med køretøjsenheder af anden generation, uanset 
version, eller med begge generationer af køretøjsenheder.  
2.4. Interoperabilitet mellem køretøjsenheder, takografkort og udstyr til 
dataoverførsel  
MIG_009 Udstyr til dataoverførsel kan være kompatibelt med alle  gene­
rationer og versioner af køretøjsenheder og takografkort.  
2.4.1  IDE'ens direkte overførsel af kort  
MIG_010 IDE'en skal overføre data fra takografkort af en genera tion, 
som isættes deres kortlæsere, ved hjælp af sikkerhedsmekanis­
merne og dataoverførselsprotokollen for den pågældende 
generation, og de overførte data skal have det format, der er 
defineret for denne generation og version.  
MIG_011 For at give kontrolmyndigheder uden for EU mulighed for  at 
kontrollere førerne skal det ligeledes være muligt at overføre 
førerkort (og værkstedskort) af anden generation, uanset 
version, på præcis samme måde som førerkort (og værksteds­
kort) af første generation. En sådan overførsel omfatter:  
— ikke-undertegnet elementærfilers ic og icc (valgfrit)  
— ikke-undertegnede elementærfilers (første generation) 
Card_Certificate og CA_Certificate  
— andre applikationsdatas elementærfiler (inden for den dedi­
kerede fil Tachograph), som overførselsprotokollen for 
kort af første generation forespørger. Disse oplysninger 
skal sikres med en digital underskrift i henhold til sikker­
hedsmekanismerne af første generation.  
En sådan overførsel skal ikke omfatte applikationsdatas 
elementærfiler, som kun findes på første og anden 
version af førerkort (og værkstedskort) af anden genera­
tion (applikationsdatas elementærfiler inden for den dedi­
kerede fil Tachograph_G2).  
2.4.2  Overførsel af kort via en køretøjsenhed  
MIG_012 Data skal overføres fra et kort af anden generation, ua nset 
version, der er isat en køretøjsenhed af første generation, 
ved hjælp af dataoverførselsprotokollen for første generation. 
Kortet skal besvare køretøjsenhedens kommandoer på præcis 
samme måde som et kort af første generation, og de overførte 
data skal have samme format som data, der er overført fra et 
kort af første generation.  
MIG_013 Data skal overføres fra et kort af første generation, d er er isat 
en køretøjsenhed af anden generation, uanset version, ved 
hjælp af den dataoverførselsprotokol, der defineres i tillæg 7 
til dette bilag. Køretøjsenheden sender kommandoer til kortet 
på præcis samme måde som en køretøjsenhed af første gene­
ration, og de overførte data skal overholde formatet, der er 
defineret for kort af første generation.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 596  
2.4.3  Overførsel fra køretøjsenhed  
MIG_014 Uden for rammerne af førerkontrol udført af kontrolmynd ig­
heder uden for EU skal data overføres fra køretøjsenheder af 
anden generation ved hjælp af sikkerhedsmekanismer af anden 
generation og dataoverførselsprotokollen, som er specificeret i  
tillæg 7 til dette bilag for den relevante version.  
MIG_015 For at give kontrolmyndigheder uden for EU mulighed for  at 
foretage førerkontrol kan der valgfrit gives mulighed for at 
overføre data fra køretøjsenheder af anden generation, uanset 
version, ved hjælp af sikkerhedsmekanismer af første genera­
tion. De overførte data skal have samme format som data, der 
overføres fra en køretøjsenhed af første generation. Denne 
mulighed kan vælges via menukommandoerne.  
2.5. Interoperabilitet mellem køretøjsenhed og kalibreringsudstyr  
MIG_016 Kalibreringsudstyr skal kunne foretage kalibrering af h ver 
generation eller version af takografen ved hjælp af den pågæl­
dende generations eller versions kalibreringsprotokol. Kalibre­
ringsudstyr kan være kompatibelt med alle generationer og 
versioner af køretøjsenheder.  
3. VIGTIGSTE SKRIDT I PERIODEN OP TIL INDFØRELSESDATOEN  
MIG_017 Prøvenøgler og certifikater skal være til rådighed for fabri­
kanter på datoen for offentliggørelse af dette bilag.  
MIG_018 Interoperabilitetsprøver skal være klar til at starte m ed version 
2 af køretøjsenheder og version 2 af takografkort, hvis fabri­
kanterne anmoder herom, senest  15 måneder  før indførelses­
datoen.  
MIG_019 For version 2 af takografer, takografkort og bevægelses følere 
af anden generation anvendes de samme nøgler og certifikater 
som for version 1 af udstyr af anden generation.  
MIG_020 Medlemsstaterne skal kunne udstede version 2 af værkste ds­
kort af anden generation senest  en måned  før indførelses­
datoen.  
MIG_021 Medlemsstaterne skal kunne udstede version 2 af alle an dre 
typer takografkort af anden generation senest  en måned  før 
indførelsesdatoen.  
4. BESTEMMELSER I PERIODEN EFTER INDFØRELSESDATOEN  
MIG_022 Med virkning fra indførelsesdatoen må medlemsstaterne k un 
udstede version 2 af takografkort af anden generation.  
MIG_023 Fabrikanter af køretøjsenheder/bevægelsesfølere har til ladelse 
til at fremstille køretøjsenheder/bevægelsesfølere af første 
generation, så længe de bruges i praksis, således at det er 
muligt at udskifte fejlbehæftede komponenter.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 597  
MIG_023a Med virkning fra indførelsesdatoen erstattes fejlbehæf tede 
køretøjsenheder eller eksternt GNSS-udstyr i version 1 af 
anden generation med version 2 af køretøjsenheder eller 
eksternt GNSS-udstyr af anden generation.  
MIG_024 Fabrikanter af køretøjsenheder/bevægelsesfølere har til ladelse 
til at anmode om og få typegodkendt vedligeholdelse af typer 
af køretøjsenheder/bevægelsesfølere af første generation eller 
version 1 af anden generation, der allerede er typegodkendt.  
5. REGISTRERING AF GRÆNSEPASSAGER I TAKOGRAFER AF 
FØRSTE GENERATION OG TAKOGRAFER AF FØRSTE VERSION 
AF ANDEN GENERATION  
MIG_025 Symbolet for det land og, hvis det er relevant, den reg ion, 
som føreren kører ind i efter at have passeret en medlemsstats 
grænse i henhold artikel 34, stk. 7, i forordning (EU) 
nr. 165/2014, indlæses som et sted, hvor den daglige 
arbejdstid begynder i overensstemmelse med den manuelle 
indlæsning af steder fastsat i krav 60 i bilag I C til forord­
ning (EU) nr. 165/2014 og krav 50 i bilag I B til forordning 
(EØF) nr. 3821/85.  ▼M3
 02016R0799 — DA — 21.08.2023 — 003.001 — 598  
Tillæg 16.  
ADAPTER TIL KØRETØJER I KLASSE M1 OG N1  
INDHOLDSFORTEGNELSE  
1. FORKORTELSER OG REFERENCEDOKUMENTER  
1.1. Forkortelser  
1.2. Referencestandarder  
2. ADAPTERENS GENERELLE EGENSKABER OG FUNKTIONER  
2.1. Generel beskrivelse af adapteren  
2.2. Funktioner  
2.3. Sikkerhed  
3. KRAV TIL KONTROLAPPARATET, NÅR EN ADAPTER ER 
INSTALLERET  
4. KONSTRUKTIONS- OG FUNKTIONSKRAV TIL ADAPTEREN  
4.1. Tilkobling og tilpasning af de indkommende hastighedsimpul ser 
4.2. Tilførsel af de indkommende impulser til den indlejrede be vægelsesføler  
4.3. Indlejret bevægelsesføler  
4.4. Sikkerhedskrav  
4.5. Funktionsspecifikationer  
4.6. Materialer  
4.7. Påskrifter  
5. INSTALLERING AF KONTROLAPPARATET, NÅR EN ADAPTER 
BENYTTES  
5.1. Installering  
5.2. Plombering  
6. KONTROL, EFTERSYN OG REPARATIONER  
6.1. Periodiske eftersyn  
7. TYPEGODKENDELSE AF KONTROLAPPARATET, NÅR EN 
ADAPTER BENYTTES  
7.1. Almindelige bestemmelser  
7.2. Funktionsattest  
1. FORKORTELSER OG REFERENCEDOKUMENTER  
1.1. Forkortelser  
TBD Endnu ikke fastlagt  
VU Køretøjsenhed  
1.2. Referencestandarder  
ISO 16844-3 Road vehicles — Tachograph systems — Part 3: Motion  
sensor interface  
2. ADAPTERENS GENERELLE EGENSKABER OG FUNKTIONER  
2.1. Generel beskrivelse af adapteren  
ADA_001 Adapteren skal forsyne en tilsluttet køretøjsenhed med sikrede 
køredata, der vedvarende repræsenterer kørehastighed og/eller 
tilbagelagt distance.  
Adapteren er alene beregnet til køretøjer, som skal udstyres 
med et kontrolapparat i overensstemmelse med denne forord­
ning. ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 599  
Den skal kun installeres og anvendes i de under yy) »adapter« 
definerede køretøjstyper i bilag IC, når det mekanisk set ikke 
er muligt at installere nogen anden eksisterende type af bevæ­
gelsesføler, som er i overensstemmelse med de øvrige bestem­
melser i dette bilag og de tilhørende tillæg 1 til 16.  
Adapteren må ikke være mekanisk forbundet med en bevæ­
gelig del af køretøjet, men alene forbindes med det sted, hvor 
de hastigheds-/afstandsrelaterede impulser frembringes af inte­
grerede følere eller alternative tilkoblinger.  
ADA_002 En typegodkendt bevægelsesføler (i henhold til bestemme lserne 
i bilag IC, afsnit 8, Typegodkendelse af kontrolapparatur og 
takografkort) monteres i adapterhuset, som også skal indeholde 
en impulskonverteringsanordning, der tilfører de indkommende 
impulser til den indlejrede bevægelsesføler. Den indlejrede 
bevægelsesføler tilsluttes køretøjsenheden således, at tilkob­
lingen mellem køretøjsenheden og adapteren opfylder kravene 
i ISO16844-3.  
2.2. Funktioner  
ADA_003 Adapteren skal kunne udføre følgende funktioner:  
— tilkobling og tilpasning af de indkommende hastigheds­
impulser  
— tilførsel af de indkommende impulser til den indlejrede 
bevægelsesføler  
— alle den indlejrede bevægelsesfølers funktioner, herunder 
sikrede køredata til køretøjsenheden.  
2.3. Sikkerhed  
ADA_004 Adapteren behøver ikke at være sikkerhedscertificeret i følge 
det fælles sikkerhedsmål for bevægelsesfølere, som defineres 
i dette bilags tillæg 10. I stedet anvendes de sikkerhedsrelate ­
rede krav, som specificeres i dette tillægs punkt 4.4.  
3. KRAV TIL KONTROLAPPARATET, NÅR EN ADAPTER ER INSTAL­
LERET  
Kravene i de følgende kapitler angiver, hvorledes kravene i det te bilag skal 
fortolkes, når en adapter anvendes. Numrene på de tilknyttede k rav i bilag 
IC anføres i parenteser.  
ADA_005 Kontrolapparatet i ethvert køretøj, der udstyres med en  adapter, 
skal opfylde alle bestemmelser i dette bilag, medmindre andet 
specificeres i dette tillæg.  
ADA_006 Når en adapter er installeret, omfatter kontrolapparate t kabler, 
adapteren (inklusive en bevægelsesføler) og en køretøjsenheden 
(01).  
ADA_007 Detektionen af hændelser og/eller fejl ved kontrolappar ater 
ændres på følgende måde:  
— Hændelsen »afbrydelse af strømforsyning« skal udløses af 
køretøjsenheden, uden at apparatet er i kalibreringstilstand, 
såfremt afbrydelsen af den indlejrede bevægelsesfølers 
strømforsyning varer mere end 200 millisekunder [79].  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 600  
— Hændelsen »fejl i køredata« skal udløses af køretøjs­
enheden ved afbrydelse af den normale dataudveksling 
mellem den indlejrede bevægelsesføler og køretøjsenheden 
og/eller ved fejl i dataintegritet eller -ægthedskontrol under 
dataudveksling mellem den indlejrede bevægelsesføler og 
køretøjsenheden [83].  
— Hændelsen »forsøg på sikkerhedsbrud« skal udløses af 
køretøjsenheden ved enhver anden hændelse, som berører 
sikkerheden af den indlejrede bevægelsesføler, og som ikke 
finder sted i kalibreringstilstand [85].  
— »Fejl ved kontrolapparatet« skal udløses af køretøjs­
enheden, når et svigt i den indlejrede bevægelsesføler fore­
kommer, uden at apparatet er i kalibreringstilstand [88].  
ADA_008 Fejl ved adapteren, der detekteres af kontrolapparatet,  skal 
være fejl i relation til den indlejrede bevægelsesføler [88].  
ADA_009 Køretøjsenhedens kalibreringsfunktion skal give mulighe d for, 
at den indlejrede bevægelsesføler automatisk samparres med 
køretøjsenheden [202, 204].  
4. KONSTRUKTIONS- OG FUNKTIONSKRAV TIL ADAPTEREN  
4.1. Tilkobling og tilpasning af de indkommende hastighedsimpulser  
ADA_011 Adapterens indgangssignaltilkobling skal modtage frekve ns­
impulser, der er repræsentative for køretøjshastigheden og 
den tilbagelagte distance. De elektriske egenskaber af de 
indkommende impulser er:  Fastlægges af fabrikanten . Med 
tilpasninger, som kun er tilgængelige for adapterfabrikanten 
og det godkendte værksted, der installerer adapteren, skal det 
om nødvendigt være muligt at foretage en korrekt tilkobling af 
adapterens indgangssignal til køretøjet.  
▼M3 
ADA_012 Adapterens indgangssignaltilkobling skal om nødvendigt kunne 
multiplicere eller dividere frekvensimpulserne fra de indkom­
mende hastighedsimpulser med en fastlagt faktor, for at tilpass e 
signalet til det k-faktorbånd, som defineres i dette bilag (2 4 00 
til 25 000 impulser pr. km). Denne fastsatte faktor må kun 
programmeres af adapterfabrikanten og det godkendte værk­
sted, som installerer adapteren.  
▼B 
4.2. Tilførsel af de indkommende impulser til den indlejrede bevægelses ­
føler  
ADA_013 De indkommende impulser, der eventuelt tilpasses som sp eci­
ficeret ovenfor, tilføres den indlejrede bevægelsesføler sålede s, 
at hver indkommende impuls detekteres af bevægelsesføleren.  
4.3. Indlejret bevægelsesføler  
ADA_014 Den indlejrede bevægelsesføler skal aktiveres af de til førte 
impulser, så den kan generere køredata, som nøjagtigt repræ­
senterer køretøjets bevægelse, som om den var mekanisk 
forbundet med en bevægelig del af køretøjet.  
ADA_015 Køretøjsenheden skal benytte den indlejrede bevægelsesf ølers 
identifikationsdata til at identificere adapteren [95].  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 601  
ADA_016 Monteringsdata, der lagres i den indlejrede bevægelsesf øler, 
skal anses for at udgøre adapterens monteringsdata [122].  
4.4. Sikkerhedskrav  
ADA_017 Adapterhuset skal udformes således, at det ikke kan åbn es. Det 
skal plomberes, så forsøg på fysisk manipulation let kan 
afsløres (f.eks. ved besigtigelse, se ADA_035). Plomberingen 
skal overholde samme krav som plomberingen af bevægelses­
følerne [398 til 406].  
ADA_018 Det må ikke være muligt at fjerne den indbyggede bevæge lses­
føler fra adapteren uden at bryde plomberingen af adapterhuset 
eller bryde plomberingen mellem føleren og adapterhuset (se 
ADA_034).  
ADA_019 Adapteren skal sikre, at køredata alene beregnes og udl edes på 
grundlag af adapterens indgangssignal.  
4.5. Funktionsspecifikationer  
ADA_020 Adapteren skal være fuldt funktionsdygtig i det tempera tur­
interval, som fabrikanten har defineret.  
ADA_021 Adapteren skal være fuldt funktionsdygtig i fugtighedsi nter­
vallet 10 % til 90 % [214].  
ADA_022 Adapteren skal være beskyttet mod overspænding, omvendt  
polaritet af strømtilførslen samt kortslutning [216].  
ADA_023 Adapteren skal enten:  
— reagere på et magnetisk felt, som forstyrrer detekteringen af  
køretøjets bevægelse. I dette tilfælde vil køretøjsenheden 
registrere og gemme en fejl ved føleren [88], eller  
— have et følerelement, som er beskyttet mod eller er upåvir­
kelig af magnetfelter [217].  
ADA_024 Adapteren skal være i overensstemmelse med den internat io­
nale bestemmelse UN ECE R10 om elektromagnetisk kompati­
bilitet og skal være beskyttet mod elektrostatiske udladninger 
og spændingsvariationer [218].  
4.6. Materialer  
ADA_025 Adapteren skal opfylde beskyttelsesgraden ( fastsættes af fabri ­
kanten, afhængig af hvor den installeres ) [220, 221].  
ADA_026 Adapterhusets farve skal være gul.  
4.7. Påskrifter  
ADA_027 En typeplade med følgende oplysninger anbringes på 
adapteren:  
— adapterfabrikantens navn og adresse  
— fabrikantens reservedelsnummer og adapterens fremstil­
lingsår  
— godkendelsesmærke for adaptertypen eller for kontrolappa­
rattypen, som omfatter adapteren  
— datoen, hvor adapteren er installeret  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 602  
— identifikationsnummer på det køretøj, hvori den er 
installeret.  
ADA_028 Typepladen skal desuden indeholde følgende oplysninger (hvis 
disse ikke kan aflæses direkte på ydersiden af den indlejrede 
bevægelsesføler):  
— navn på fabrikanten af den indlejrede bevægelsesføler  
— fabrikantens reservedelsnummer og den indlejrede bevægel­
sesfølers fremstillingsår  
— godkendelsesmærke for den indlejrede bevægelsesføler.  
5. INSTALLERING AF KONTROLAPPARATET, NÅR EN ADAPTER 
BENYTTES  
5.1. Installering  
ADA_029 Adaptere, der skal installeres i køretøjer, må kun inst alleres af 
køretøjsfabrikanten eller af godkendte værksteder, der har till a­
delse til at installere, aktivere og kalibrere digitale takogra fer 
og intelligente takografer.  
ADA_030 Et sådant godkendt værksted, der installerer adapteren,  justerer 
indgangssignaltilkoblingen og vælger omsætningsforhold til 
indgangssignalet (hvis dette er relevant).  
ADA_031 Et sådant godkendt værksted, der installerer adapteren,  plom­
berer adapterhuset.  
ADA_032 Adapteren installeres så tæt som muligt på den del af k øretøjet, 
der frembringer indkommende impulser til denne.  
ADA_033 Kablerne, som forsyner adapteren med strøm, skal være 
henholdsvis rød (positiv forsyning) og sort (stel).  
5.2. Plombering  
ADA_034 Følgende plomberingskrav finder anvendelse:  
— Adapterhuset plomberes (se ADA_017).  
— Den indlejrede bevægelsesfølers hus plomberes fast til 
adapterhuset, medmindre det ikke er muligt at fjerne 
føleren fra adapterhuset uden at bryde adapterhusets 
plombe(r) (se ADA_018).  
— Adapterhuset plomberes fast på køretøjet.  
— Forbindelsen mellem adapteren og det udstyr, der frem­
bringer impulserne til denne, plomberes i begge ender (i 
det omfang, dette med rimelighed kan lade sig gøre).  
6. KONTROL, EFTERSYN OG REPARATIONER  
6.1. Periodiske eftersyn  
ADA_035 Når der benyttes adapter, skal hvert periodiske eftersy n (perio­
diske eftersyn skal forstås i overensstemmelse med krav [409] 
til krav [413] i bilag 1C) af kontrolapparatet omfatte kontrol af 
følgende:  
— at adapteren er forsynet med den relevante typegodkendel­
sesmærkning  
— at plomberne på adapteren og dennes forbindelser er 
ubeskadigede  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 603  
— at adapteren er installeret som angivet på installations­
pladen  
— at adapteren er installeret som specificeret af adapter- 
og/eller køretøjsfabrikanten  
— at det er tilladt at montere en adapter på det inspicerede 
køretøj.  
ADA_036 Disse eftersyn omfatter en kalibrering og udskiftning a f alle 
plomberinger uanset deres stand.  
7. TYPEGODKENDELSE AF KONTROLAPPARATET, NÅR EN 
ADAPTER BENYTTES  
7.1. Almindelige bestemmelser  
ADA_037 Ved forelæggelse til typegodkendelse skal kontrolappara tet 
være komplet med adapter [425].  
ADA_038 Enhver adapter kan forelægges med henblik på en selvstæ ndig 
typegodkendelse eller til typegodkendelse som en komponent i 
et kontrolapparat.  
ADA_039 En sådan typegodkendelse skal omfatte funktionsprøver m ed 
adapteren. Positive resultater for hver af disse prøver angives  
ved en passende attest [426].  
7.2. Funktionsattest  
ADA_040 Der udstedes først en funktionsattest for en adapter el ler et 
kontrolapparat med en adapter til adapterfabrikanten, efter at 
alle de følgende minimumsfunktionsprøver er afsluttet med et 
tilfredsstillende resultat.  
Nr. Test  Beskrivelse  Tilknyttede krav  
1. Administrativ undersøgelse  
1.1 Dokumentation  Adapterdokumenta­
tionens korrekthed  
2. Besigtigelse  
2.1. Overensstemmelse med dokumentationen  
2.2. Identifikation/mærkning af adapteren  ADA_027, 
ADA_028  
2.3 Adapterens materialer  [219] til [223] 
ADA_026  
2.4. Plombering  ADA_017, 
ADA_018, 
ADA_034  
3. Funktionsprøver  
3.1 Tilførsel af hastighedsimpulser til den indlejrede 
bevægelsesføler  ADA_013  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 604  
Nr. Test  Beskrivelse  Tilknyttede krav  
3.2 Tilkobling og tilpasning af de indkommende 
hastighedsimpulser  ADA_011, 
ADA_012  
3.3 Nøjagtighed af målingen af bevægelsen  [30] til [35], [217]  
4. Miljøprøver  
4.1 Fabrikantens prøvnings­
resultater  Resultater af fabri­
kantens prøvninger  ADA_020, 
ADA_021, 
ADA_022, 
ADA_024  
5. Elektromagnetisk kompatibilitet  
5.1 Strålingsemission og 
følsomhed  Overensstemmelse 
med direktiv 2006/ 
28/EF verificeres  ADA_024  
5.2 Fabrikantens prøvnings­
resultater  Resultater af fabri­
kantens prøvninger  ADA_024  ▼B
 02016R0799 — DA — 21.08.2023 — 003.001 — 605  
BILAG II  
GODKENDELSESMÆRKE OG TYPEGODKENDELSESDOKUMENT  
I. GODKENDELSESMÆRKE  
1. Godkendelsesmærket består af:  
a) et rektangel, i hvilket er anbragt bogstavet »e« efterfulgt af kodetallet eller 
kendingsbogstavet for det land, som har meddelt typegodkendelse n i over­
ensstemmelse med følgende oversigt: 
Belgien  6 ,  
Bulgarien  34,  
Den Tjekkiske Republik  8 ,  
Danmark  18,  
Tyskland  1 ,  
Estland  29,  
Irland  24,  
Grækenland  23,  
Spanien  9 ,  
Frankrig  2 ,  
Kroatien  25,  
Italien  3 ,  
Cypern  CY,  
Letland  32,  
Litauen  36,  
Luxembourg  13,  
Ungarn  7 ,  
Malta  MT,  
Nederlandene  4 ,  
Østrig  12,  
Polen  20,  
Portugal  21,  
Rumænien  19,  
Slovenien  26,  
Slovakiet  27,  
Finland  17,  
Sverige  5 ,  
Det Forenede Kongerige  11,  
og 
▼M1 
b) et typegodkendelsesnummer, som svarer til nummeret i det typ egodken­
delsesdokument, der er udstedt for modellen af kontrolapparatet  eller 
diagramarket eller takografkortet, og som anbringes et sted i n ærheden 
af rektanglet.  ▼C1
 02016R0799 — DA — 21.08.2023 — 003.001 — 606  
2. Godkendelsesmærket anbringes på hvert apparats typeplade, på  hvert diagra­
mark og på hvert takografkort. Mærket må ikke kunne udslettes o g skal til 
enhver tid være letlæseligt.  
3. De nedenfor angivne mål (  1 ) for godkendelsesmærket er udtrykt i millimeter 
og udgør mindstemålene. Forholdene mellem disse mål skal overho ldes.
 ▼C1 
( 1 ) Disse tal er kun vejledende.
 02016R0799 — DA — 21.08.2023 — 003.001 — 607  
II. TYPEGODKENDELSESDOKUMENT FOR ANALOGE TAKOGRAFER  
Den medlemsstat, der har meddelt en typegodkendelse, udsteder e n typegodken­
delsesattest til ansøgeren efter følgende model. Til underretni ng af andre 
medlemsstater om den meddelte typegodkendelse eller om eventuel le tilbagekal­
delser skal medlemsstaterne anvende kopier af denne attest.  
TYPEGODKENDELSESATTEST  
Navnet på den kompetente myndighed  
Meddelelse vedrørende (  1 ): 
— typegodkendelse for modellen af et kontrolapparat  
— tilbagekaldelse af typegodkendelse for modellen af et kontrol apparat  
— godkendelse af modeller af diagramark  
— tilbagekaldelse af godkendelse af modeller af diagramark  
Godkendelsesnr.:  
...................................  
1. Varemærke eller -navn  
2. Modellens eller typens betegnelse  
3. Fabrikantens navn  
4. Fabrikantens adresse  
5. Forelagt til godkendelse den  
6. Afprøvningssted  
7. Afprøvningsdato og nr.  
8. Godkendelsesdato  
9. Dato for tilbagekaldelse af godkendelse  
10. Modellen af det kontrolapparat (eller de apparater), til hv ilket (hvilke) diagra­
market benyttes  
11. Sted  
12. Dato  
13. Bilag (beskrivelser mv.)  
14. Bemærkninger (herunder eventuelle plombers placering)  
(Underskrift)  ▼C1 
( 1 ) Det ikke gældende overstreges.
 02016R0799 — DA — 21.08.2023 — 003.001 — 608  
III. TYPEGODKENDELSESDOKUMENT FOR DIGITALE TAKOGRAFER  
Den medlemsstat, der har meddelt en typegodkendelse, udsteder e n typegodken­
delsesattest til ansøgeren efter følgende model. Til underretni ng af andre 
medlemsstater om den meddelte typegodkendelse eller om eventuel le tilbagekal­
delser skal medlemsstaterne anvende kopier af denne attest.  
GODKENDELSESATTEST FOR DIGITALE TAKOGRAFER  
Navnet på den kompetente myndighed  
Meddelelse vedrørende (  1 ): 
□ godkendelse af:  □  tilbagekaldelse af godkendelse af:  
□ kontrolapparatmodel  
□ komponent til kontrolapparat (  2 ) 
□ et førerkort  
□ et værkstedskort  
□ et virksomhedskort  
□ et kontrolkort  
Godkendelsens nr.:  
1. Fabrikat eller varemærke  
2. Modellens betegnelse  
3. Fabrikantens navn  
4. Fabrikantens adresse  
▼M1 
5. Forelagt til godkendelse den  
▼C1 
6. Laboratorium(er)  
7. Afprøvningsrapportens dato og nr.  
8. Godkendelsesdato  
9. Dato for tilbagekaldelse af godkendelse  
10. Model af kontrolapparat(er), som komponenten er bestemt til  anvendelse 
sammen med  
11. Sted  
12. Dato  
13. Bilag (beskrivelser mv.)  
14. Bemærkninger (herunder eventuelle plombers placering)  
(Underskrift)  ▼C1 
( 1 ) Afkryds de relevante felter. 
( 2 ) Angiv, hvilken komponent meddelelsen vedrører.
 02016R0799 — DA — 21.08.2023 — 003.001 — 609  
IV. GODKENDELSESATTEST FOR INTELLIGENTE TAKOGRAFER  
Den medlemsstat, der har meddelt en typegodkendelse, udsteder e n typegodken­
delsesattest til ansøgeren efter følgende model. Til underretni ng af andre 
medlemsstater om den meddelte typegodkendelse eller om eventuel le tilbagekal­
delser skal medlemsstaterne anvende kopier af denne attest.  
GODKENDELSESATTEST FOR INTELLIGENTE TAKOGRAFER  
Navnet på den kompetente myndighed  
Meddelelse vedrørende (  1 ): 
□ godkendelse af:  □  tilbagekaldelse af godkendelse af:  
□ kontrolapparatmodel  
□ komponent til kontrolapparat (  2 ) 
□ et førerkort  
□ et værkstedskort  
□ et virksomhedskort  
□ et kontrolkort  
Godkendelsens nr.:  
1. Fabrikat eller varemærke  
2. Modellens betegnelse  
3. Fabrikantens navn  
4. Fabrikantens adresse  
▼M1 
5. Forelagt til godkendelse den  
▼C1 
6. a) Prøvelaboratorium for funktionsgodkendelse  
b) Prøvelaboratorium for sikkerhedsgodkendelse  
c) Prøvelaboratorium for interoperabilitetsgodkendelse  
7. a) Dato og nummer på funktionsattest  
b) Dato og nummer på sikkerhedsattest  
c) Dato og nummer på interoperabilitetsattest  
8. Godkendelsesdato  
9. Dato for tilbagekaldelse af godkendelse  
10. Model af kontrolapparat(er), som komponenten er bestemt til  anvendelse 
sammen med  
11. Sted  
12. Dato  
13. Bilag (beskrivelser mv.)  
14. Bemærkninger (herunder eventuelle plombers placering)  
(Underskrift)  ▼C1 
( 1 ) Afkryds de relevante felter. 
( 2 ) Angiv, hvilken komponent meddelelsen vedrører.