Consolidated text: Kommissionens gennemførelsesforordning (EU) 2016/799 af 18. marts 2016 om gennemførelse af Europa

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 den
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. februar
2020
L 34 20 6.2.2020
►M3 Kommissionens gennemførelsesforordning (EU) 2021/1228 af 16. juli
2021
L 273 1 30.7.2021
►M4 Kommissionens gennemførelsesforordning (EU) 2023/980 af 16. maj
2023
L 134 28 22.5.2023
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.002 — 1
02016R0799 — DA — 21.08.2023 — 003.002 — 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 typegodkendelsesprocedurerne
for takografer, herunder sikkerhedsmekanismerne.
▼M1
2. Konstruktion, afprøvning, installering, eftersyn, brug og reparation
af intelligente takografer og deres komponenter skal ske i henhold 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 reparation, fortsat
overholde kravene i enten bilag I til forordning (EU) nr. 165/2014 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 vejesystem 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 forordning (EU)
nr. 165/2014.
▼B
( 1 ) Rådets forordning (EØF) nr. 3821/85 af 20. december 1985 om kontrolappa­
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. april 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.002 — 3
Desuden forstås ved:
1) »digital takograf« eller »takograf af første generation«: digital tako­
graf, som ikke er en intelligent takograf
2) »eksternt GNSS-udstyr«: udstyr, der indeholder GNSS-modtageren,
når køretøjsenheden ikke er en enkelt enhed, samt andre kompo­
nenter, der er nødvendige for at beskytte transmission af positions­
data til resten af køretøjsenheden
▼M1
3) »informationsmappe«: hele mappen, i elektronisk form eller papir­
form, der indeholder alle oplysninger, som fabrikanten eller dennes
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 eller
papirform, ledsaget af alle andre dokumenter, som typegodkendel­
sesmyndigheden har tilføjet til informationsmappen i forbindelse
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 relevante
dele af denne pakke identificeres. Formatet af dette dokument skal
skelne mellem de forskellige trin i EC-typegodkendelsesprocessen,
herunder datoer for eventuelle revisioner og ajourføringer af pakken
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 forord­
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, det
eksterne GNSS-udstyr og det eksterne udstyr til tidlig fjernafsløring
▼B
9) »typegodkendelsesmyndighed«: myndighed i en medlemsstat, der
er kompetent til at foretage typegodkendelse af takografen eller af
dennes komponenter, godkendelsesprocessen, udstedelse og i givet
fald tilbagekaldelse af typegodkendelsesattester, at fungere som
kontaktpunkt for typegodkendelsesmyndigheder i andre medlems­
stater og at sikre, at fabrikanterne opfylder deres forpligtelser
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 processor,
et datalager, en tidsmålefunktion, to intelligente kortlæserenheder
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 4
til fører og medfører, en printer, en skærm, stik samt faciliteter 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 indeholder
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 kompatible med
de lokaliseringstjenester, der tilbydes af systemerne Galileo og 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 eller en
gruppe af komponenter til typegodkendelsesmyndighederne, som
udpeges af hver medlemsstat. Den skal bestå af en informationsmappe,
der indeholder oplysninger om hver af de pågældende komponenter,
herunder i givet fald typegodkendelsesattester for andre komponenter,
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 overensstemmelse
med de administrative og tekniske krav i artikel 1, stk. 2 eller 3. I
dette tilfælde udsteder typegodkendelsesmyndigheden en typegodken­
delsesattest til ansøgeren, der er i overensstemmelse med modellen i
bilag II til denne forordning.
3. Typegodkendelsesmyndigheden kan anmode fabrikanten eller
dennes repræsentant om at indsende eventuelle supplerende oplysninger.
▼M1
02016R0799 — DA — 21.08.2023 — 003.002 — 5
4. Fabrikanten eller dennes repræsentant stiller det nødvendige antal
takografer eller takografkomponenter til rådighed for typegodkendelses­
myndighederne og for de organer, der er ansvarlige for at udstede de i
artikel 12, stk. 3, i forordning (EU) nr. 165/2014 omhandlede attester,
med henblik på at muliggøre en tilfredsstillende afvikling af
typegodkendelsesproceduren.
5. Når fabrikanten eller dennes repræsentant søger typegodkendelse
af bestemte komponenter eller grupper af komponenter i en takograf,
skal de stille de øvrige komponenter, som allerede er typegodkendt,
samt andre dele, der er nødvendige for konstruktionen af den komplette
takograf til rådighed for typegodkendelsesmyndighederne, således 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 typegodken­
delse, om eventuelle ændringer i software eller hardware til takografen
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 den
eksisterende typegodkendelse eller udstede en ny typegodkendelse
afhængigt af ændringernes art og kendetegn.
Der foretages en »revision«, hvis typegodkendelsesmyndigheden finder,
at ændringerne i takografens software eller hardware eller arten 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 informations­
pakken i konsolideret form ledsaget af en detaljeret beskrivelse af de
foretagne ændringer er tilstrækkeligt til at opfylde dette krav.
En »forlængelse« foretages, hvis typegodkendelsesmyndigheden finder,
at ændringerne i takografens software eller hardware eller arten 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 underretter
fabrikanten eller dennes repræsentant herom. Hvis disse afprøvninger er
tilfredsstillende, udsteder typegodkendelsesmyndigheden en revideret
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 for den
seneste forlængelse eller revision af typegodkendelsen eller datoen for
den seneste konsolidering af den ajourførte udgave af typegodkendelsen.
4. En typegodkendelse er nødvendig, hvis de ønskede ændringer af
en typegodkendt takograf eller dens komponenter ville medføre, at der
udstedes en ny sikkerheds- eller interoperabilitetsattest.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 6
Artikel 6
Ikrafttræden
Denne forordning træder i kraft på tyvendedagen efter offentliggø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 tillæg 16,
der anvendes fra den 2. marts 2016.
▼B
Denne forordning er bindende i alle enkeltheder og gælder umiddelbart i
hver medlemsstat.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 begynder
og/eller slutter
3.6.2 Manuel indlæsning af føreraktiviteter og førerens samtykke 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 fjernkom­
munikation«
3.9.10 Hændelsen »manglende positionsoplysninger fra GNSS-modtager«
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 satellitnavigationssystemer (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åbegyndes,
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 generation
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 9
3.14.2 Registrering og lagring på takografkort af anden generation
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 vejsidekontroller
▼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 af 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.002 — 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/eller 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ængelig 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 begynder 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 kumuleret køretid nås
▼M3
4.5.3.2.17 Status for ægthedsbekræftelse for positioner, der vedrø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 der 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.002 — 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 version 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ængelig 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.002 — 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 kumuleret 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 vedrø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 der 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 version 1 af køretøjs­
enheder af anden generation)
4.5.4.2.22 Konfiguration af køretøjsenhed (anvendes ikke af version 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ængelig 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 version 1 af
køretøjsenheder af anden generation)
▼B
4.5.6 Virksomhedskort
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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ængelig 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 version 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øjsfabrikanter
▼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 kontrolappa­
rater og takografkort af anden generation
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 14
INDLEDNING
Dette bilag indeholder kravene til anden generation af kontrolapparater 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 generation 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 overensstemmelse 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 kun kalibreres
ved brug af værkstedskort af anden generation.
Kravene til interoperabiliteten mellem første og anden generation af takografsy­
stemer er angivet i dette bilag. Tillæg 15 indeholder nærmere oplysninger 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ænsepassager 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 forordning desuden
tekniske krav til anden version af anden generation af kontrolapparat 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.002 — 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 udstyr
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.002 — 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 udgangs­
signalet fra den køretøjsdel, der forbinder kontrolapparatet med
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, som
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 akkumuleret pausetid benyttes
af kontrolapparatet til beregning af advarselssignal for sammenhæ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øretid 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 kort ikke var isat i et
kontrolapparat, og for hvilke der ikke manuelt er indlæst føreraktiviteter.
( 3 ) Europa-Parlamentets og Rådets forordning (EF) nr. 561/2006 af 15. marts 2006 om
harmonisering af visse sociale bestemmelser inden for vejtransport og om ændring af
Rådets forordning (EØF) nr. 3821/85 og (EF) nr. 2135/98 samt ophæ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.002 — 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 proces
ikke ændrer eller sletter nogen lagrede data.
▼B
( 1 ) Denne beregningsmetode for sammenhængende køretid og akkumuleret pausetid benyttes
af kontrolapparatet til beregning af advarselssignal for sammenhæ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øretid 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 kort ikke var isat i et
kontrolapparat, og for hvilke der ikke manuelt er indlæst føreraktiviteter.
02016R0799 — DA — 21.08.2023 — 003.002 — 18
Fabrikanter af køretøjsenheder til intelligente takografer og
fabrikanter af udstyr, der er konstrueret og beregnet til at over­
føre datafiler, træffer alle rimelige foranstaltninger til at sikre,
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 er
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 2012 om gennemførelse
af Europa-Parlamentets og Rådets forordning (EF) nr. 661/2009 for 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.002 — 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 af
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.002 — 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 para­
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 enten
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.002 — 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 installere
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øjer 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.002 — 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, hvilket
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. at
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ære
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.002 — 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 vist,
printet eller overført.
▼B
2 KONTROLAPPARATETS GENERELLE EGENSKABER OG
FUNKTIONER
2.1 Generelle egenskaber
Kontrolapparatet har til formål at registrere, gemme, vise, udprinte
og udlæse data vedrørende førerens aktiviteter.
Køretøjer, der er udstyret med kontrolapparat, som opfylder forskrif­
terne i dette bilag, skal være forsynet med hastighedsviser og kilo­
metertæller. Disse funktioner skal være indeholdt i kontrolapparatet.
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.002 — 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.002 — 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 kort
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
K
or
tp
la
ds
f
or
m
ed
ch
au
ff
ø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 takografkort, 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.002 — 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 udveksles
mellem køretøjsenhed og eventuelt eksternt GNSS-udstyr, beskytte
fortroligheden, integriteten og ægtheden af data, som udveksles
gennem udstyret til fjernkommunikation med henblik på tidlig afslø­
ring til kontrolformål, samt verificere integriteten og ægtheden af
overførte data.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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åser
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.002 — 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.002 — 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 ved
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.002 — 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, som
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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 37
Kortkonflikt
Førerkortplads
Intet kort Førerkort Kontrolkort Værkstedskort Virksomhedskort
K
or
tp
la
ds
f
or
m
ed
ch
au
ff
ø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
K
or
tp
la
ds
f
or
m
ed
ch
au
ff
ø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.002 — 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.002 — 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.002 — 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 mindst
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. dag
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 den
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.002 — 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.002 — 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 alle
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.002 — 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.002 — 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 mindst
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.002 — 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øjets
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 registreres
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.002 — 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.002 — 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.002 — 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 registreres
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.002 — 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.002 — 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 datalager
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 datalager
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.002 — 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 data
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.002 — 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.002 — 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 kontrolapparatets 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 fabrikanten
i et passende format, men semantikken på det importerede
kort forbliver uændret.
133q) Fabrikanten skal også lagre versionsidentifikatoren for det
kort, der bruges i kontrolapparatet.
133r) Det lagrede digitale kort skal kunne opdateres eller erstattes
af et nyt kort, det stilles til rådighed af Kommissionen.
133s) Opdatering af digitale kort skal ske ved brug af de softwa­
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.002 — 54
133t) Takograffabrikanter kan føje yderligere oplysninger til det
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 gange
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.002 — 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 sted­
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 kontrolapparater
af første generation, skal ikke lagres på fører- og værksteds­
kortene.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 gange
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 alle
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 forskellige
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 kontrol­
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.002 — 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 gange
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.002 — 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.002 — 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, linje
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.002 — 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 tillæ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.002 — 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.002 — 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øres
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ængelige
for fjernkommunikationslæsere via trådløs kommunikation
som beskrevet i tillæg 14.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 oven­
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 passeret 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ærelse
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.002 — 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 NL Nederlandene
D
EST
Tyskland
Estland
A
PL
Østrig
Polen
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 UK Det Forenede Kon­
gerige
I Italien
230) oplysninger, der er specifikke for det udstedte kort, numme­
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 forside
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 72
237) De midlertidige kort omhandlet i artikel 26, stk. 4, i forord­
ning (EU) nr. 165/2014 skal overholde bestemmelserne i
dette bilag.
4.2 Sikkerhed
Sikringen af systemet skal beskytte integritet og ægthed af data, som
udveksles mellem kort og kontrolapparat, beskytte integritet og
ægthed af data, som overføres fra kortene, bevirke, at visse skrive­
procedurer på kortene er forbeholdt kontrolapparatet, dekryptere
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.002 — 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, som
opfylder datalagringsbestemmelserne, er nærmere angivet i tillæg 2.
Medmindre andet anføres, skal datalagring på takografkort tilrette­
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 lagerkapacitet 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 lagring
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.002 — 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 identifikation
af applikationen:
— identifikation af takografapplikation
— identifikation af takografkortets type.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 identifikation
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 identifikation
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 registreres
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.002 — 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 disse
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.002 — 77
4.5.3.1.8 Data vedrørende fejl
Med henblik på bestemmelserne i dette afsnit skal tiden registreres
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 disse
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.002 — 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/eller 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.002 — 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 identifikation
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.002 — 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 identifikation
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 identifikation
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 registreres
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.002 — 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 disse
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.002 — 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 registreres
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 disse
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 af
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.002 — 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 begynder 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.002 — 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.002 — 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 kumuleret 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 vedrø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ørende
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.002 — 86
4.5.3.2.18 Status for ægthedsbekræftelse for positioner, hvor der 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.002 — 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-/losseoperationer.
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 last­
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 version 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 speci­
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 identifi­
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.002 — 88
4.5.4.1.4 Identifikation af kortindehaver
311) Værkstedskortet skal kunne lagre følgende data til identifi­
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.002 — 89
4.5.4.1.8 Føreraktivitetsdata
320) Værkstedskortet skal kunne lagre data om førerens aktivitet
på samme måde som et førerkort.
321) Værkstedskortet skal kunne lagre data om førerens aktivitet
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 identifi­
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.002 — 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 identifi­
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.002 — 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 aktivitet
på samme måde som et førerkort.
▼M3
344) Værkstedskortet skal kunne lagre data om førerens aktivitet
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 daglige 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 poster.
▼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.002 — 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 kumuleret 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 vedrø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.002 — 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 der 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-/losseoperationerne
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 version 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.002 — 94
4.5.4.2.22 Konfiguration af køretøjsenhed (anvendes ikke af version 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 kortindehaverens
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 identifika­
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 identifika­
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.002 — 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 identifika­
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 identifika­
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.002 — 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 version 1 af køre­
tøjsenheder af anden generation)
368a) Kontrolkortet skal kunne lagre kortindehaverens specifikke
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.002 — 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.002 — 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 version 1 af køre­
tøjsenheder af anden generation)
380a) Virksomhedskortet skal kunne lagre kortindehaverens
specifikke takografindstillinger.
380b) Virksomhedskortets kapacitet til lagring af kortindehaverens
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 til
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 registrere
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.002 — 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 ud
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 skal
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.002 — 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 om kontrolapparatet
inden for vejtransport (EUT L 21 af 24.1.2009, s. 3).
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 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 hvilke
omstændigheder plomber må fjernes som omhandlet i artikel 22, stk.
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ærksteder,
som er godkendt til aktivering og/eller kalibrering af kontrolappa­
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 fare
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.002 — 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 skal
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.002 — 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, der
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.002 — 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 eksiste­
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 eksiste­
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, at
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.002 — 106
8 TYPEGODKENDELSE AF KONTROLAPPARATUR OG TAKO­
GRAFKORT
8.1 Almindelige bestemmelser
▼M1
I dette afsnit forstås ved »kontrolapparat« »kontrolapparatet eller
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, som
skal anvendes af kontrolapparatet, anses for at være en komponent 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 om
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, eksternt
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.002 — 107
429) Procedurer til opdatering af software i et allerede monteret
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 til
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.002 — 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 anmod­
ninger om interoperabilitetsprøver i den kronologiske
rækkefølge, de modtages.
442) Anmodningerne vil først blive officielt registreret, når labo­
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 generationer
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.002 — 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.002 — 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 interoperabilitetsmangel,
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 interopera­
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.002 — 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.002 — 112
2.24a. CardLoadTypeEntries
2.24b. CardLoadTypeEntryRecord
2.24c. CardLoadUnloadOperations
2.24d. CardLoadUnloadRecord
▼B
2.25. CardMACertificate
2.26. CardNumber
▼M3
2.26a. CardPlaceAuthDailyWorkPeriod
▼B
2.27. CardPlaceDailyWorkPeriod
2.28. CardPrivateKey
2.29. CardPublicKey
2.30. CardRenewalIndex
2.31. CardReplacementIndex
2.32. CardSignCertificate
2.33. CardSlotNumber
2.34. CardSlotsStatus
2.35. CardSlotsStatusRecordArray
2.36. CardStructureVersion
2.37. CardVehicleRecord
2.38. CardVehiclesUsed
2.39. CardVehicleUnitRecord
2.40. CardVehicleUnitsUsed
2.41. 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.002 — 113
2.48a. CompanyCardApplicationIdentificationV2
▼B
2.49. CompanyCardHolderIdentification
2.50. ControlCardApplicationIdentification
▼M3
2.50a. ControlCardApplicationIdentificationV2
▼B
2.51. ControlCardControlActivityData
2.52. ControlCardHolderIdentification
2.53. ControlType
2.54. CurrentDateTime
2.55. CurrentDateTimeRecordArray
2.56. DailyPresenceCounter
2.57. Datef
2.58. DateOfDayDownloaded
2.59. DateOfDayDownloadedRecordArray
2.60. 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.002 — 114
2.74. FullCardNumberAndGeneration
2.75. Generation
2.76. GeoCoordinates
2.77. GNSSAccuracy
▼M1
2.78. GNSSAccumulatedDriving
2.79. GNSSAccumulatedDrivingRecord
▼M3
2.79a. GNSSAuthAccumulatedDriving
2.79b. GNSSAuthStatusADRecord
2.79c. GNSSPlaceAuthRecord
▼B
2.80. GNSSPlaceRecord
2.81. HighResOdometer
2.82. HighResTripDistance
2.83. HolderName
▼M3
2.84. 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.002 — 115
2.100. NationAlpha
2.101. NationNumeric
▼M3
2.101a. NoOfBorderCrossingRecords
▼B
2.102. NoOfCalibrationRecords
2.103. NoOfCalibrationsSinceDownload
2.104. NoOfCardPlaceRecords
2.105. NoOfCardVehicleRecords
2.106. NoOfCardVehicleUnitRecords
2.107. NoOfCompanyActivityRecords
2.108. NoOfControlActivityRecords
2.109. NoOfEventsPerType
2.110. NoOfFaultsPerType
▼M1
2.111. NoOfGNSSADRecords
▼M3
2.111a. NoOfLoadUnloadRecords
▼B
2.112. NoOfSpecificConditionRecords
▼M3
2.112a. NoOfLoadTypeEntryRecords
▼B
2.113. OdometerShort
2.114. OdometerValueMidnight
▼M3
2.114a. OperationType
▼B
2.115. OdometerValueMidnightRecordArray
2.116. OverspeedNumber
▼M3
2.116a. PlaceAuthRecord
2.116b. PlaceAuthStatusRecord
▼B
2.117. PlaceRecord
▼M3
2.117a. PositionAuthenticationStatus
▼B
2.118. PreviousVehicleInfo
2.119. PublicKey
2.120. RecordType
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 116
2.121. RegionAlpha
2.122. RegionNumeric
2.123. RemoteCommunicationModuleSerialNumber
2.124. RSAKeyModulus
2.125. RSAKeyPrivateExponent
2.126. RSAKeyPublicExponent
2.127. RtmData
2.128. SealDataCard
2.129. SealDataVu
2.130. SealRecord
2.131. SensorApprovalNumber
2.132. SensorExternalGNSSApprovalNumber
2.133. SensorExternalGNSSCoupledRecord
2.134. SensorExternalGNSSIdentification
2.135. SensorExternalGNSSInstallation
2.136. SensorExternalGNSSOSIdentifier
2.137. SensorExternalGNSSSCIdentifier
2.138. SensorGNSSCouplingDate
2.139. SensorGNSSSerialNumber
2.140. SensorIdentification
2.141. SensorInstallation
2.142. SensorInstallationSecData
2.143. SensorOSIdentifier
2.144. SensorPaired
2.145. SensorPairedRecord
2.146. SensorPairingDate
2.147. SensorSCIdentifier
2.148. SensorSerialNumber
2.149. Signature
2.150. SignatureRecordArray
2.151. SimilarEventsNumber
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 117
2.152. SpecificConditionRecord
2.153. SpecificConditions
2.154. SpecificConditionType
2.155. Speed
2.156. SpeedAuthorised
2.157. SpeedAverage
2.158. SpeedMax
▼M3
2.158a. TachographCardsGen1Suppression
▼B
2.159. TachographPayload
▼M1
2.160. 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.002 — 118
2.179. VuCardRecord
2.180. VuCardRecordArray
2.181. VuCertificate
2.182. VuCertificateRecordArray
2.183. VuCompanyLocksData
2.184. VuCompanyLocksRecord
2.185. VuCompanyLocksRecordArray
▼M3
2.185a. VuConfigurationLengthRange
▼B
2.186. VuControlActivityData
2.187. VuControlActivityRecord
2.188. VuControlActivityRecordArray
2.189. VuDataBlockCounter
2.190. VuDetailedSpeedBlock
2.191. VuDetailedSpeedBlockRecordArray
2.192. VuDetailedSpeedData
▼M3
2.192a. VuDigitalMapVersion
▼B
2.193. VuDownloadablePeriod
2.194. VuDownloadablePeriodRecordArray
2.195. VuDownloadActivityData
2.196. VuDownloadActivityDataRecordArray
2.197. VuEventData
2.198. VuEventRecord
2.199. VuEventRecordArray
2.200. VuFaultData
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 119
2.201. VuFaultRecord
2.202. VuFaultRecordArray
▼M1
2.203. VuGNSSADRecord
▼M3
2.203a. VuBorderCrossingRecord
2.203b. VuBorderCrossingRecordArray
▼M1
2.204. VuGNSSADRecordArray
▼M3
2.204a. VuGnssMaximalTimeDifference
▼B
2.205. VuIdentification
2.206. VuIdentificationRecordArray
2.207. VuITSConsentRecord
2.208. VuITSConsentRecordArray
▼M3
2.208a. VuLoadUnloadRecord
2.208b. VuLoadUnloadRecordArray
▼B
2.209. VuManufacturerAddress
2.210. VuManufacturerName
2.211. VuManufacturingDate
2.212. VuOverSpeedingControlData
2.213. VuOverSpeedingControlDataRecordArray
2.214. VuOverSpeedingEventData
2.215. VuOverSpeedingEventRecord
2.216. VuOverSpeedingEventRecordArray
2.217. VuPartNumber
2.218. VuPlaceDailyWorkPeriodData
2.219. VuPlaceDailyWorkPeriodRecord
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 120
2.220. VuPlaceDailyWorkPeriodRecordArray
2.221. VuPrivateKey
2.222. VuPublicKey
▼M3
2.222a. VuRtcTime
▼B
2.223. VuSerialNumber
2.224. VuSoftInstallationDate
2.225. VuSoftwareIdentification
2.226. VuSoftwareVersion
2.227. VuSpecificConditionData
2.228. VuSpecificConditionRecordArray
2.229. VuTimeAdjustmentData
▼M1
2.230. 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.002 — 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 datastrukturer,
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 Abstract Syntax
Notation One (ASN.1). På denne måde kan der defineres enkle og
strukturerede data, uden at dette forudsætter en nærmere bestemt 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 inde­
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 datatypens
navn stadig af én enkelt sekvens af alfabetiske tegn med stort begyn­
delsesbogstav, dog anvendes store bogstaver inde i navnet til at
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 standard 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 visse
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.002 — 122
ISO/IEC 7816-5 Identification cards — Integrated circuit cards — Part
5: Registration of application providers.
Second edition: 2004.
ISO/IEC 7816-6 Identification cards — Integrated circuit cards — Part
6: Interindustry data elements for interchange, 2004
+ Technical Corrigendum 1: 2006
ISO/IEC 8824-1 Information technology — Abstract Syntax Notation
One (ASN.1): Specification of basic notation. 2008 +
Technical Corrigendum 1: 2012 and Technical Corri­
gendum 2: 2014.
ISO/IEC 8825-2 Information technology — ASN.1 encoding rules:
Specification of Packed Encoding Rules (PER). 2008.
ISO/IEC 8859-1 Information technology — 8 bit single-byte coded
graphic character sets — Part 1: Latin alphabet
No.1. First edition: 1998.
ISO/IEC 8859-7 Information technology — 8 bit single-byte coded
graphic character sets — Part 7: Latin/Greek alphabet.
2003.
ISO 16844-3 Road vehicles — Tachograph systems — Motion
Sensor Interface. 2004 + Technical Corrigendum 1:
2006.
TR-03110-3 BSI / ANSSI Technical Guideline TR-03110-3,
Advanced Security Mechanisms for Machine
Readable Travel Documents and eIDAS Token —
Part 3 Common Specifications, version 2.20,
3. 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 generation,
medmindre andet anføres. Datatyper, der kun anvendes til version 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 generation
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 anden
generation.
Kortdatatyper, der ikke er defineret for kort af første generation, lagres
ikke i applikationer af første generation på kort af anden generation.
Navnlig gælder følgende:
— Typegodkendelsesnumre, der er lagret i applikationer af første gene­
ration på kort af anden generation, trunkeres til de første otte 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.002 — 123
2.1. ActivityChangeInfo
Med denne datatype kan der inden for et to bytes stort ord kodes skift af
kortlæserstatus kl. 00:00 og/eller førerstatus kl. 00:00 og/eller skift af
aktivitet og/eller skift af kørestatus og/eller skift af kortstatus 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 00h00
den pågældende dag.
For registreringer på fører- (eller værksteds-)kortet (og førerstatus):
»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.002 — 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 00h00
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 fra
— »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.002 — 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 »Character­
StringType«.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 den første
oktet.
De tilladte cifre er: 0, 1, .. 9.
2.8. CalibrationPurpose
Kode, som forklarer, hvorfor der blev registreret et sæt kalibreringspara­
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ærdier:
»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 og 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 den
OCTET STRING, som indeholder disse poster (se CardActivityLength­
Range, tillæg 2, punkt 4). Når denne post er den ældste døgnpost, skal
activityPreviousRecordLength sættes til 0.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 aktivitets­
skift pr. minut). Dette datasæt indeholder altid ActivityChangeInfo med
kode for førerstatus kl. 00:00.
2.10. CardActivityLengthRange
Antal bytes, som i et fører- eller værkstedskort er til rådighed 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 eventuelle
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ænsepassage­
posten på kortet i strukturen.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 verden«
(NationNumeric-kode »FF«H) anvendes, når køretøjsenheden ikke kan
fastslå det land, hvor køretøjet befinder sig (hvis det nuværende 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øjsenheden
ikke kan fastslå det land, hvor køretøjet befinder sig (hvis det 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 integrerede
kreds (IC) (Bilag 1C, krav 249). icSerialNumber identificerer sammen
med icManufacturingReferences kortets chip entydigt. icSerialNumber
alene identificerer ikke kortets chip entydigt.
icSerialNumber er serienummeret på den integrerede kreds.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 og 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.002 — 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ændige 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 gemme data
vedrørende førerens aktivitet (datastruktur: CardActivityDailyRecord) 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æftet 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 ved at der
indsættes en ny activityDailyRecord) som erstatning for ældre aktivitets­
data, skal activityPointerOldestDayRecord opdateres svarende til den nye
placering af den ældste fuldstændige døgnpost, og activityPreviousRe­
cordLength for denne (nye) ældste fuldstændige døgnpost skal nulstilles.
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.
drivingLicenceNumberer førerbevisets nummer.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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å sikkerhedsbrud).
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å sikkerhedsbrud).
▼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.002 — 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 341).
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 341).
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.002 — 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 (bilag 1C, krav
255, 280, 310, 333, 359, 365, 371 og 377).
cardIssuingMemberState er koden på den medlemsstat, som har
udstedt kortet.
cardNumberer kortets nummer.
cardIssuingAuthorityName er navnet på den myndighed, der har
udstedt kortet.
cardIssueDate er datoen for udstedelse af kortet til den nuværende
indehaver.
cardValidityBeginer kortets første gyldighedsdato.
cardExpiryDateer 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.002 — 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 (bilag
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 356h).
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 strukturen.
cardLoadUnloadRecords er den mængde poster, der indeholder oplys­
ninger om den udførte operationstype (lastning, losning eller samtidig
lastning/losning), dato og klokkeslæt for indlæsning af laste-/losseopera­
tionen, oplysninger om køretøjets position og køretøjets kilometerstand.
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 356g).
timeStamp er dato og klokkeslæt ved begyndelsen af laste-/losseopera­
tionen.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 ægthedsbekræftelse
med en køretøjsenhed. Dette certifikats opbygning er nærmere beskrevet
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ørerkortnummer,
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 arbejdstid
begynder og/eller slutter (bilag I C, krav 306b og 356b).
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 fore­
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)
placePointerNewestRecorder 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.002 — 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.002 — 138
2.35. CardSlotsStatusRecordArray
Anden generation:
CardSlotsStatus plus metadata, der anvendes i protokollen for dataover­
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 implementeret 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.002 — 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.
vuDataBlockCounterer 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, 295, 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 strukturen.
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.002 — 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 periode).
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, krav 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øjsenhedsposterne
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 certificeringsorgan.
Første generation:
Tilordnet værdi: Digital underskrift med delvis genfinding af et Certi­
ficateContent i henhold til tillæg 11 (fælles sikkerhedsmekanismer):
Signature (128 bytes) || Public Key remainder (58 bytes) || Certification
Authority Reference (8 bytes).
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 certificeringsmyn­
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 henhold 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.002 — 142
Anden generation:
tachographApplicationID angiver de seks vigtigste bytes i den tilsva­
rende applikationsidentifikator (AID) for takografkortet af anden gene­
ration. AID for takografkortapplikationen og AID for det eksterne
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 også
benyttes som datanavn for et køretøjs offentlige nøgle, hvis serienum­
meret på den køretøjsenhed, som nøglen er bestemt for, ikke kendes 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 certificeringsmyndighed
(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.002 — 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 aktiviteter, 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 virksomhedsaktivitets­
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 og downloadPeriodEnd angiver den periode,
hvor eventuel overførsel af data fra køretøjsenheden har fundet sted.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 144
2.47. CompanyActivityType
Kode, som angiver en aktivitet udøvet af en virksomhed, som benytter
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 identifika­
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.002 — 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 kortets 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 identifikation 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 kontrolaktiviteter,
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.002 — 146
Tilordnet værdi: Tal svarende til tælleren i kontrolaktivitetsposten,
begyndende med »0« for første forekomst af kontrolaktivitetsposten 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 sted.
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 kortindehaveren
(bilag 1C, krav 360 og 366).
controlBodyName er navnet på kortindehaverens kontrolorgan.
controlBodyAddress er adressen på kortindehaverens kontrolorgan.
cardHolderNameer 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.002 — 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.002 — 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 hvis 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 kortet 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.002 — 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 mellem 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.002 — 150
2.61. DriverCardApplicationIdentification
Oplysninger, gemt på et førerkort, til identifikation af kortets 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.002 — 151
2.61a. DriverCardApplicationIdentificationV2
Anden generation, version 2:
Oplysninger, der er gemt på et førerkort, vedrørende identifikation 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 kortindehaveren
(bilag 1C, krav 256 og 281).
cardHolderNameer efternavn og fornavn(e) på førerkortets indehaver.
cardHolderBirthDateer 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.002 — 152
2.64. EGFCertificate
Anden generation:
Certifikat for det eksterne GNSS-udstyrs offentlige nøgle til gensidig
ægthedsbekræftelse med en køretøjsenhed. Dette certifikats opbygning
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 indlæ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 udstyr til
takografapplikationen.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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ølgende
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, hvis det
er relevant.
Note 2: I feltet CardHolderAuthorisation (CHA) på et certifikat for
anden generation skal værdierne 1), 2), og 6) fortolkes som angivende
et certifikat for gensidig ægthedskontrol for den pågældende udstyrstype.
For at angive det respektive certifikat for at generere en digital 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 blevet
registreret.
Tilordnet værdi:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 forekommet
den alvorligste hændelse for en af de 10 seneste dage, den er forekommet
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å sikkerhedsbrud
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.002 — 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å sikkerhedsbrud
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.002 — 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.002 — 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.002 — 158
2.71. ExtendedSealIdentifier
Anden generation:
Det udvidede datanavn for en plombe identificerer entydigt plomben
(bilag I C, krav 401).
manufacturerCode er en kode for fabrikanten af plomben. Tilordnet
værdi: se databaseregistrering, der skal forvaltes af Kommissionen (se
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 som 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.002 — 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 generation.
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 position
skal angives som Hex »7FFFFF« (Decimal 8388607).
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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ærdien 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 multiplum 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-posten
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 multiplum
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 multiplum 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.002 — 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, hvis 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 multiplum 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 klokkeslæ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.002 — 162
2.79c. GNSSPlaceAuthRecord
Anden generation, version 2:
Oplysninger om køretøjets GNSS-position (bilag I C, krav 108, 109,
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, 109, 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.002 — 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 ekstern 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 henvise 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øgle 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 oplyses på
tidspunktet for udfærdigelse af certifikatet).
Det tredje valg er egnet til henvisning til den offentlige nøgle for en
medlemsstat.
▼B
2.87. KMWCKey
Anden generation:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 tillæ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.002 — 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 svarende 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 081, 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ører og offent­
liggør listen over fabrikantkoder på sit websted (bilag 1C, krav 454).
Der tildeles midlertidigt ManufacturerCode til udviklere af takografudstyr
efter ansøgning til det laboratorium, der forestår interoperabilitetsprø­
verne.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 166
2.95. ManufacturerSpecificEventFaultData
Anden generation:
Fabrikantspecifikke fejlkoder, som sikrer enklere fejlanalyse og 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 protokollen 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.002 — 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 overensstemmelse med
de nationalitetsbetegnelser, der anvendes på køretøjer i international
færdsel (FN-Wienerkonventionen om vejtrafik af 1968).
NationAlpha- og NationNumeric-koderne skal være opført på en liste på
webstedet for det laboratorium, som er udpeget til at udføre interopera­
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 NationNu­
meric -specifikation, der er beskrevet i ovennævnte afsnit, foretages først,
efter at det udpegede laboratorium har indhentet udtalelser fra fabrikanter
af typegodkendte køretøjsenheder til digitale takografer og intelligente
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.002 — 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ærkstedskort.
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ærksteds­
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- eller værk­
stedskort.
Tilordnet værdi: se tillæg 2.
2.107. NoOfCompanyActivityRecords
Antal virksomhedsaktivitetsposter, som kan gemmes på et virksomheds­
kort.
Tilordnet værdi: se tillæg 2.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 kort.
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 kort.
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.002 — 170
2.112a. NoOfLoadTypeEntryRecords
Anden generation, version 2:
Antal lasttypeposter, der kan lagres på et fører- eller værkstedskort.
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.002 — 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 seneste
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 overskridelse
af tilladt hastighed, 1 betyder, at der har været én hændelse med over­
skridelse af tilladt hastighed siden seneste kontrol for overskridelse af
tilladt hastighed, … 255 betyder, at der har været 255 eller flere
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 begynder 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 arbejdstid
begynder eller slutter (bilag I C, krav 306a og 356a). Andre oplysninger
vedrørende selve stedet lagres i en anden post (se 2.117 PlaceRecord).
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 begynder
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 parameter:
entryGNSSPlaceRecord er det registrerede sted og tidspunkt.
▼M3
2.117a. PositionAuthenticationStatus
Anden generation, version 2:
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 anvendte,
da han satte sit kort i en køretøjsenhed (bilag 1B, krav 081, og 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 RecordArrays.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 175
Anden generation:
RegionAlpha-koderne skal være opført på en liste på webstedet for 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.002 — 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 fastgjort
til de forskellige komponenter i et køretøj, er beregnet til lagring 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 fastgjort
til de forskellige komponenter i et køretøj, er beregnet til lagring 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 fastgjort 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.002 — 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 eventuelle
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 eventuelle
bindestreger. Godkendelsesnummeret skal være venstrejusteret.
2.133. SensorExternalGNSSCoupledRecord
Anden generation:
Oplysninger, gemt på en køretøjsenhed, til identifikation af det 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 (bilag 1C,
krav 98).
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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-udstyr.
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.002 — 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 GNSS-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 enheden.
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.002 — 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 sikkerhedsdata, som
er nødvendige til samparring af bevægelsessensorer med køretøjsenheder
(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.002 — 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 den bevæ­
gelsessensor, som er samparret med køretøjsenheden (bilag 1B, krav 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 identifikationen af
en bevægelsessensor der parres med køretøjsenheden (bilag 1C, krav 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øjsenhed.
Tilordnet værdi: Uspecificeret.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 protokollen 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 094, 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ældende
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 registreret 255
eller flere hændelser af den pågældende type den pågældende dag.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 posten
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.002 — 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 anvende
fører-, kontrol- og virksomhedskort af første generation (se tillæ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.002 — 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 klokkeslæt
er angivet som sekunder siden 00h.00m.00s. den 1. januar 1970 UTC.
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 som
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ørsel.
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.002 — 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 (indregistreringsnummer
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 over­
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). Indregistreringsnummeret
tildeles af registreringsmyndigheden.
codePage angiver et tegnsæt, der er defineret i afsnit 4.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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ørsel.
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øjsenhedens
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.002 — 188
Oplysninger, gemt på en køretøjsenhed, vedrørende skift af aktivitet
og/eller skift af kørestatus og/eller skift af kortstatus for en 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 altid 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 aktivitet
og/eller skift af kørestatus og/eller skift af kortstatus for en given kalen­
derdag (bilag 1C, krav 105, 106 og 107), samt kortlæserstatus kl. 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 Activity­
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.002 — 189
Tilordnet værdi: Uspecificeret.
Anden generation:
Tilordnet værdi:
Godkendelsesnummeret skal tilvejebringes som offentliggjort på
Europa-Kommissionens relevante websted, dvs. f.eks. med eventuelle
bindestreger. Godkendelsesnummeret skal være venstrejusteret.
2.173. VuCalibrationData
Første generation:
Oplysninger, gemt på en køretøjsenhed, vedrørende kalibreringerne 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 kalibrering af
kontrolapparatet (bilag 1B, krav 098, og bilag 1C, krav 119 og 120).
Første generation:
calibrationPurpose er formålet med kalibreringen.
workshopName, workshopAddresser værkstedets navn og adresse.
workshopCardNumber identificerer det værkstedskort, der er anvendt
ved kalibreringen.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 kontrolmyndigheden.
▼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.002 — 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 afslutningen
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.002 — 192
2.175. VuCalibrationRecordArray
Anden generation:
Oplysninger, gemt på en køretøjsenhed, vedrørende kalibreringerne 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øjsenheden (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øjsenheden
(bilag 1B, krav 081, og bilag 1C, krav 102).
Første generation:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 kortet.
Anden generation:
I stedet for fullCardNumber anvendes følgende dataelement i datastruk­
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.002 — 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øjsenheden (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 takograf­
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 takografkort, der
er anvendt sammen med køretøjsenheden. Disse oplysninger er beregnet
til analyse af problemer med køretøjsenhed og kort (bilag 1C, krav 132).
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 virksomhedslå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.002 — 196
2.184. VuCompanyLocksRecord
Oplysninger, gemt på en køretøjsenhed, der vedrører én virksomhedslå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 virksomhedslå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.002 — 197
2.185a. VuConfigurationLengthRange
Anden generation, version 2:
Antal byte i et takografkort, der er tilgængeligt til lagring af 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 foretaget
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 foretaget
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.002 — 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 foretaget
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 identificerer 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 (bilag 1B, krav
093, og bilag 1C, krav 116).
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 detalje­
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 detalje­
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.002 — 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 eller 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 eller
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.002 — 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 datastruk­
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 (bilag 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.002 — 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 overskridelser
af tilladt hastighed.
Anden generation:
Ud over dataelementerne for første generation anvendes følgende
dataelementer:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 203
manufacturerSpecificEventFaultData indeholder yderligere fabrikants­
pecifikke oplysninger om hændelsen.
I stedet for cardNumberDriverSlotBegin, cardNumberCodriverSlotBegin,
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 generation.
cardNumberAndGenDriverSlotEnd identificerer det kort, der sad i
førerens kortplads ved hændelsens afslutning, og kortets generation.
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 eventEnd­
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 (bilag 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.002 — 204
2.200. VuFaultData
Første generation:
Oplysninger, gemt på en køretøjsenhed, vedrørende fejl (bilag 1B, 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 (bilag 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.002 — 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, cardNumberCodriverSlotBegin,
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 generation.
cardNumberAndGenDriverSlotEnd identificerer det kort, der sad i
førerens kortplads ved fejlens afslutning, og kortets generation.
cardNumberAndGenCodriverSlotEnd identificerer det kort, der sad i
medchaufførens kortplads ved fejlens afslutning, og kortets generation.
2.202. VuFaultRecordArray
Anden generation:
Oplysninger, gemt på en køretøjsenhed, vedrørende fejl (bilag 1C, 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.002 — 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 multiplum
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 (bilag
I C, krav 133a og 133b).
▼M1
02016R0799 — DA — 21.08.2023 — 003.002 — 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øjsenheden
ikke kan fastslå det land, hvor køretøjet befinder sig (hvis det 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øjsenheden
ikke kan fastslå det land, hvor køretøjet befinder sig (hvis det 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 ægthedsbekræ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.002 — 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 multiplum 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 realtidsur
baseret på den maksimale tidspunktdrift anført i bilag I C, krav 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.002 — 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.002 — 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 samtykke
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 samtykke 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.002 — 211
Oplysninger, der er gemt på en køretøjsenhed, vedrørende en indlæ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 indlæ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.002 — 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 overskridelser af
tilladt hastighed, som har fundet sted siden seneste kontrol med 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 tilladt
hastighed.
numberOfOverspeedSince er antallet af hændelser med overskridelse af
tilladt hastighed siden seneste kontrol med overskridelse af tilladt
hastighed.
2.213. VuOverSpeedingControlDataRecordArray
Anden generation:
VuOverSpeedingControlData plus metadata, der anvendes i protokollen
for dataoverførsel.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 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 start.
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.002 — 215
2.218. VuPlaceDailyWorkPeriodData
Første generation:
Oplysninger, gemt på en køretøjsenhed, vedrørende de steder, hvor
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å kortet.
▼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.002 — 216
I stedet for placeRecord benyttes følgende dataelement i datastrukturen
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, hvor
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øjsenheden til
eksternt GNSS-udstyr, se tillæg 12, krav GNS_3f.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 installerede
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øjsenheden.
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.002 — 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 tidsjusteringer, 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 tidsjustering, 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.002 — 219
oldTimeValue, newTimeValue er gammel og ny værdi af dato og
klokkeslæt.
workshopName, workshopAddresser 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 generation.
2.233. VuTimeAdjustmentRecordArray
Anden generation:
Oplysninger, gemt på en køretøjsenhed, vedrørende tidsjusteringer, 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 kortets appli­
kation (bilag 1C, krav 307 og 330).
Første generation:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 identifikation
af kortets applikation (bilag I C, krav 330a).
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 yderligere 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 forekomst
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 identifi­
kationsnummer og køretøjets standartlasttype.
2.234c. WorkshopCardCalibrationAddDataRecord
Anden generation, version 2:
Oplysninger, der er gemt på et værkstedskort, vedrørende standardlast­
typen, der er indlæst under en kalibrering (bilag I C, krav 356k).
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 aktiviteter, 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 kalibrering, der er
udført med kortet (bilag 1C, krav 314 og 337).
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 kontrolmyndigheden.
vuPartNumber, vuSerialNumber og sensorSerialNumber er de datae­
lementer, som identificerer kontrolapparatet.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 kortindeha­
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.002 — 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 afbrydelse
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 begyndelse.
cardNumberAndGenDriverSlotEnd identificerer det kort, inklusive
generation, der er isat førerens kortplads ved begivenhedens afslutning.
cardNumberAndGenCodriverSlotBegin identificerer det kort, inklu­
sive generation, der er isat medchaufførens kortplads ved begivenhedens
begyndelse.
cardNumberAndGenCodriverSlotEnd identificerer det kort, inklusive
generation, der er isat medchaufførens kortplads ved begivenhedens
afslutning.
similarEventsNumber er antallet af lignende begivenheder den pågæl­
dende dag.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 226
2.241. VuPowerSupplyInterruptionRecordArray
Anden generation:
Oplysninger, gemt i en køretøjsenhed, om begivenheder med afbrydelse
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 proto­
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.002 — 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 definitionerne i
punkt 2.
4. TEGNSÆT
Til IA5Strings anvendes ASCII-tegnsættet som defineret i ISO/IEC
8824-1. Af hensyn til letlæselighed og overskuelighed er de tilordnede
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ølgende
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 13
ISO/IEC 8859-15 Latin-9 15
ISO/IEC 8859-16 Latin-10 Sydøsteuropæisk 16
KOI8-R Latin/Kyrillisk 80
KOI8-U Latin/Kyrillisk 85
5. KODNING
Ved kodning efter ASN.1-kodningsreglerne skal alle de definerede data­
typer være kodet i overensstemmelse med ISO/IEC 8825-2, justeret
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.002 — 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 punktnotation
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ølgende
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 objektidentifikator 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.002 — 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 anden gene­
ration er »FF 53 4D 52 44 54«. Dette er en beskyttet AID i overens­
stemmelse med ISO/IEC 7816-4.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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 size
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.002 — 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 inden 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 ICC,
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.002 — 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 data
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ændingen
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 og
interoperabilitet.
Takografkort opfylder så vidt muligt de foreliggende gældende ISO/
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 kommandoer
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.002 — 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.002 — 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.002 — 237
3.3. Adgangsregler
TCS_22 I en adgangsregel specificeres sikkerhedsbetingelserne for
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. APDU-
kommandoer og -svar sendes som almindelig tekst, dvs. uden sikker 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 sikker
meddelelsesoverførsel.
EXT-AUT-G1 Handlingen kan kun udføres, hvis kommandoen External Authenticate 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 meddelelsesoverfø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 tilbagemeldes 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 11, del A).
SM-MAC-G2 APDU (kommando og svar) skal anvendes ved sikker meddelelsesoverfø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 11, 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.002 — 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.002 — 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.002 — 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 overensstemmelse
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.002 — 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 00 Normal behandling af data.
61 XX Normal behandling af data. XX = antal svarbytes til rådighed
62 81 Advarselsbehandling. En del af svardata kan være beskadiget
63 00 Ægthedsbekræftelse mislykkedes (advarsel)
63 CX Forkert CHV (kortindehaververifikation, PIN). Indholdet i tæller
for resterende forsøg tilbagemeldes med »X«
64 00 Kørselsfejl — Status for ikke-flygtigt lager uændret. Integritets­
fejl.
65 00 Kørselsfejl — Status for ikke-flygtigt lager ændret.
65 81 Kørselsfejl — Status for ikke-flygtigt lager ændret. Hukommel­
sesfejl
66 88 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.002 — 242
SW1 SW2 Betydning
67 00 Forkert længde (forkert Lc eller Le)
68 83 Sidste kommando i den forventede kæde
69 00 Forbudt kommando (intet svar foreligger i T = 0)
69 82 Sikkerhedsstatus ikke tilfredsstillet
69 83 Ægthedsbekræftelse blokeret
69 85 Betingelser for anvendelse ikke opfyldt
69 86 Kommando ikke tilladt (ingen aktuel elementærfil)
69 87 Forventede dataobjekter for sikker meddelelsesoverførsel mangler
69 88 Ukorrekte dataobjekter for sikker meddelelsesoverførsel
6A 80 Ukorrekte parametre i datafelt
6A 82 Filer ikke fundet
6A 86 Forkerte parametre P1-P2
6A 88 De adresserede data kunne ikke findes
6B 00 Forkerte parametre (adressetillæg uden for elementærfil)
6C XX Forkert længde, SW2 angiver eksakt længde. Intet datafelt tilba­
gemeldes
6D 00 Operationskode ikke understøttet eller ugyldig
6E 00 Klasse ikke understøttet
6F 00 — 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 kapitel.
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 altid
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.002 — 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.002 — 244
SELECT-kommandoen anvendes:
— til at vælge en applikationsdedikeret fil (skal vælges med navn)
— til at vælge en elementærfil svarende til det forelagte filnavn.
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 sikker­
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) NN »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.002 — 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ørsel
(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ærfil.
Bemærk: Denne kommando uden sikker meddelelsesoverførsel kan
kun bruges til at læse en fil, som understøtter sikkerhedsbetingelsen
ALW for læseadgangstilstand.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 aktuelt
valgte elementærfil med sikkert meddelelsessystem, med det formål at
efterprøve identiteten af de modtagne data og beskytte fortroligheden
af data, hvis sikkerhedsbetingelsen SM-R-ENC-MAC-G1 (første gene­
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.002 — 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) NN »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.002 — 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) MM »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.002 — 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 en
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.002 — 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 data
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) NN »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.002 — 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 sikkerheds­
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.002 — 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) NN »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.002 — 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 til
den aktuelt valgte elementærfil, uden at kortet kontrollerer ægtheden
af de modtagne data.
Bemærk: Denne kommando uden sikker meddelelsesoverførsel kan
kun bruges til at opdatere en fil, som understøtter sikkerhedsbetin­
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) NN »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 til
den aktuelt valgte elementærfil, idet kortet kontroller ægtheden af de
modtagne data. Da der ikke kræves fortrolighed, er data ikke
krypteret.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 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 en
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) NN »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.002 — 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) NN »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.002 — 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 sikkerheds­
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.002 — 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 kortet.
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« P1
P2 1 »00h« P2
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.002 — 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, men
for disse kort personaliseres ingen reference-CHV. Derfor kan disse
kort ikke udføre denne kommando på tilfredsstillende vis. For så vidt
angår andre slags takografkort end værkstedskort ligger deres adfærd
(den returnerede fejlkode) uden for anvendelsesområdet for denne
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« P1
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 kortet 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ørelse
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.002 — 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« P1
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 anvendes
kommandokædning i overensstemmelse med ISO/IEC 7816-4, og
certifikatet skal sendes i to på hinanden følgende APDU'er af typen
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.002 — 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.002 — 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ørste
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« P1
P2 1 »00h« P2
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.002 — 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 beskrevet
i tillæg 11 for takografer af første og anden generation (ægtheds­
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.002 — 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 af
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.002 — 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 tilknyt­
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 aktuelle
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 til 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.002 — 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 takograf­
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ølgende
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.002 — 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ølgende PSO:
Verify Digital Signature-kommando eller
— underskriftsverifikation af et certifikat, som leveres i en efterfø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.002 — 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 status­
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 verifikation 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 tilknyt­
tede standard.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 en
ophavsretligt beskyttet anvendelse af PERFORM SECURITY
OPERATION/HASH.
Kun førerkortet og værkstedskortet kræves for at understøtte denne
kommando i DF Tachograph og DF Tachograph_G2.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 272
Andre slags takografkort kan eventuelt udføre denne kommando. Hvis
et virksomhedskort eller kontrolkort udfører denne kommando, skal
kommandoen udføres som foreskrevet i dette afsnit.
Kommandoen kan eventuelt være tilgængelig i hovedfilen. I så fald
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.002 — 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 denne
kommando i DF Tachograph og DF Tachograph_G2.
Andre slags takografkort kan eventuelt udføre denne kommando. Ved
takografapplikationer af anden generation er det kun førerkortet og
værkstedskortet, som har en underskriftsnøgle af anden generation,
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 tilknyt­
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 digitale
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.002 — 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 underskrift,
der tilføres som inddata for en meddelelse, for hvilken hash kendes 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 tilknyt­
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.002 — 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 ægtheden af
DSRC-meddelelsen og til at dechifrere de data, som en køretøjsenhed
sender til en kontrolmyndighed eller et værksted via DSRC-forbin­
delsen. Kortet udleder den krypteringsnøgle og den MAC-nøgle, der
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, men
de må ikke have en DSRC-hovednøgle. Disse kort kan derfor ikke
udføre kommandoen med resultat, men skal afsluttes med en passende
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.002 — 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.002 — 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 af tilgænge­
lige data.
Det specificerer ikke producentafhængige interne strukturer i kortet
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.002 — 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 tako­
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.002 — 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.002 — 280
► (1) (2) M3
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 281
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 282
TCS_151 Følgende værdier, der er anvendt som størrelsesangivelser 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.002 — 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.002 — 284
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 285
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 286
TCS_155 Følgende værdier, der er anvendt som størrelsesangivelser 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 12 12
n 2 NoOfFaultsPerType 24 24
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 generation er
personaliseret, skal den have følgende permanente
filstruktur og filadgangsregler:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 have
følgende datastruktur:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 288
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 289
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 290
TCS_159 Følgende værdier, der er anvendt som størrelsesangivelser 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.002 — 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 have
følgende datastruktur:
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 292
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 293
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 294
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 295
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 296
TCS_163 Følgende værdier, der er anvendt som størrelsesangivelser 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 24 24
n 9 NoOfSpecificConditionRecords 4 4
n 10 NoOfBorderCrossingRecords 4 4
n 11 NoOfLoadUnloadRecords 8 8
n 12 NoOfLoadTypeEntryRecords 4 4
n 13 VuConfigurationLengthRange 3072 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.002 — 297
TCS_167 Følgende værdier, der er anvendt som størrelsesangivelser 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 er
personaliseret, skal den have følgende permanente
filstruktur og filadgangsregler:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 299
▼B
TCS_171 Følgende værdier, der er anvendt som størrelsesangivelser 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.002 — 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 generation
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.002 — 301
TCS_175 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 første
generation:
4.5.2 Virksomhedskortapplikation af anden generation
▼M3
TCS_176 Efter at virksomhedskortapplikationen 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, 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.002 — 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.002 — 303
Tillæg 3
PIKTOGRAMMER
PIC_001 Der kan til takografen anvendes følgende piktogrammer og 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.002 — 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.002 — 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.002 — 306
Tidskonflikt eller justering af klokkeslæt (foretaget af værksted)
▼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.002 — 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 datagrupper, om
muligt identificeret med en gruppeidentifikator.
En datagruppe indeholder en eller flere poster, eventuelt identificeret
ved en postidentifikator.
PRT_001 Når en gruppeidentifikator står umiddelbart foran en post­
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 mellemrum
som skilletegn for tusinder og millioner, og uden foranstillede
nuller.
▼M3
PRT_005 Strengdatafelter udskrives venstrejusteret og udfyldt med
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 tekststykke, 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.002 — 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) Formatet
»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 kortets
nummer med udskiftningsindekset og fornyelsesindekset adskilt af et
mellemrum:
P x x x / x x x x x x x x x x x x x x x x
K
om
bi
na
ti
on
a
f
ko
rt

og
p
ik
to
gr
am

U
ds
te
de
nd
e
m
ed
le
m
ss
ta
ts
k
od
e De første 14 tegn i kortnummeret
(eventuelt inkl. et fortløbende indeks)
U
ds
ki
ft
ni
ng
si
nd
ek
s
F
or
ny
el
se
si
nd
ek
s
▼M3
— I en datagruppe henviser teksten efter »pi=« til det tilsvarende pikto­
gram eller den tilsvarende piktogramkombination defineret i tillæg 3.
— Når dette piktogram udskrives efter længdegraden og breddegraden
af en registreret position eller efter det tidspunkt, hvor positionen
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.002 — 309
PRT_007 Udskrifter skal anvende følgende datablokke og/eller dataposter i over­
ensstemmelse med følgende betydninger og formater:
► (1) (2) (3) (4) (5) M3
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 310
► (1) (2) (3) M3
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 311
► (1) (2) M3
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 312
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 313
► (1) (2) (3) (4) M3
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 314
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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, gentaget som
mange gange som nødvendigt.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 316
3.1. Daglig udskrift af føreraktivitet fra kort
▼M3
PRT_008 Daglig udskrift af føreraktivitet fra kort skal overholde
følgende format:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 317
3.2. Daglig udskrift af føreraktivitet fra køretøjsenhed
▼M3
PRT_009 Daglig udskrift af føreraktivitet fra køretøjsenhed skal over­
holde følgende format:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 kontrolkort i
køretøjsenheden + GEN)
3 Identifikation af føreren (fra det kort, som udskriften omhandler)
4 Identifikation af køretøj (det køretøj, hvorfra udskriften tages)
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 over­
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øjsenhed +
GEN)
4 Identifikation af køretøj (det køretøj, hvorfra udskriften tages)
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ærende 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.002 — 319
3.5. Udskrift af tekniske data
▼M3
PRT_012 Udskrift af tekniske data skal overholde følgende format:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 320
3.6. Udskrift af overskridelse af tilladt hastighed
PRT_013 Udskrift af overskridelser af tilladt hastighed skal overholde
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øjsenhed +
GEN)
4 Identifikation af køretøj (det køretøj, hvorfra udskriften tages)
20 Information vedrørende overskridelse af tilladt hastighed
21.1 Identifikator for data vedrørende overskridelser af tilladt hastighed
21.4/21.5 Første overskridelse af tilladt hastighed efter seneste kalibrering
21.2 Identifikator for data vedrørende overskridelser af tilladt hastighed
21.4/21.5
De 5 alvorligste hændelser med overskridelse af tilladt hastighed
inden for de sidste 365 dage
21.3 Identifikator for data vedrørende overskridelser af tilladt hastighed
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 overholde
følgende format:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 formater:
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.002 — 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-benet, 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.002 — 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.002 — 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ølgende:
2. GRÆNSEFLADE FOR DATAOVERFØRSEL
INT_004 Grænsefladen for dataoverførsel skal opfylde specifikationerne
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 sidst.
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 bps.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 325
3. GRÆNSEFLADE FOR KALIBRERING
INT_007 Datakommunikationen skal opfylde ISO 14230-1 Road vehicles
— Diagnostic systems — Keyword protocol 2000 — Part 1:
Physical layer, First edition: 1999.
INT_008 Indgangs- og udgangssignalet skal opfylde følgende elektriske
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 mA
U høj (ud) 4 V I = 1 mA
INT_009 Indgangs- og udgangssignalet skal opfylde følgende tids­
diagrammer:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 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 Version (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 Svar Dataover­
førsel, Aktiviteter)
2.2.6.4 Positive Response Transfer Data Events and Faults (Positivt 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 (Positivt 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 forskellige
typer dataoverførsel til et eksternt lagermedium (ESM), foruden de
protokoller, der skal gennemføres for at sikre korrekt overførsel af
data og fuld kompatibilitet af det overførte dataformat, således 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.002 — 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 dataoverførsel
vedhæftet en underskrift i overensstemmelse med tillæg 11 (fælles
sikkerhedsmekanismer). Kildeenhedens (køretøjsenhed eller kort) iden­
tifikation og sikkerhedsattester (fra medlemsstaten og for udstyret)
bliver ligeledes overført. Den, der kontrollerer data, skal uafhængigt
være indehaver af en betroet europæisk offentlig nøgle.
Data, der overføres fra en køretøjsenhed, underskrives i henhold til
tillæg 11 Fælles sikkerhedsmekanismer, del B (takografsystemer af
anden generation), undtagen når førerkontrollen udføres af en kontrol­
myndighed uden for EU under anvendelse af et kontrolkort af første
generation, idet data så underskrives i henhold til tillæg 11 Fælles
sikkerhedsmekanismer, del A (takografsystemer af første generation),
jf. tillæg 15 Migration, krav MIG_15.
I dette tillæg beskrives derfor to typer data, der kan overføres fra
køretøjsenheden:
— Overførsel af køretøjsenhedsdata af anden generation med data­
struktur af anden generation, som underskrives i henhold til tillæg
11 Fælles sikkerhedsmekanismer, del B
— Overførsel af køretøjsenhedsdata af første generation med data­
struktur af første generation, som underskrives i henhold til tillæ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.002 — 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 foretage
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 fungerer
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 layer).
Applikationslaget bygger hovedsagelig på det aktuelle udkast til ISO
14229-1 (Road vehicles — Diagnostic systems — Part 1: Diagnostic
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 … … … CS
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 adgangsrettigheder til overførselsfunktionen
og til data. Det skal imidlertid være muligt at overføre data fra 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.002 — 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 bytes
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 CS
4 bytes Længere end 255 bytes
Vil blive overført som:
Hoved SID TREP 00 01 Delmeddelelse 1 CS
4 bytes 255 bytes
Hoved SID TREP 00 02
Delmeddelelse
2
CS
4 bytes 255 bytes
…
Hoved SID TREP xx yy Delmeddelelse n CS
4 bytes Mindre end 255 bytes
eller som:
Hoved SID TREP 00 01 Delmeddelelse 1 CS
4 bytes 255 bytes
Hoved SID TREP 00 02 Delmeddelelse 2 CS
4 bytes 255 bytes
…
Hoved SID TREP xx yy Delmeddelelse n CS
4 bytes 255 bytes
Hoved SID TREP xx yy+1 CS
4 bytes 4 bytes
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 331
2.2.2 Meddelelsestyper
Kommunikationsprotokollen for overførsel af data mellem køretøjs­
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 ->
Start Communication Request 81 EE F0 81 E0
Positive Response Start Communica­
tion
80 F0 EE 03 C1 EA, 8F 9 B
Start Diagnostic Session Request 80 EE F0 02 10 81 F1
Positive Response Start Diagnostic 80 F0 EE 02 50 81 31
Link Control Service
Verify Baud Rate (stage 1)
9 600 Bd 80 EE F0 04 87 01 01,01 EC
19 200 Bd 80 EE F0 04 87 01 01,02 ED
38 400 Bd 80 EE F0 04 87 01 01,03 EE
57 600 Bd 80 EE F0 04 87 01 01,04 EF
115 200 Bd 80 EE F0 04 87 01 01,05 F0
Positive Response Verify Baud Rate 80 F0 EE 02 C7 01 28
Transition Baud Rate (stage 2) 80 EE F0 03 87 02 03 ED
Request Upload 80 EE F0 0 A 35 00,00,00,00,
00,FF,FF,
FF,FF
99
Positive Response Request Upload 80 F0 EE 03 75 00,FF D5
Transfer Data Request
Download interface version 80 EE F0 02 36 00 96
Overview 80 EE F0 02 36 01, 21 or 31 CS
Activities 80 EE F0 06 36 02, 22 or 32 Date CS
Events & Faults 80 EE F0 02 36 03, 23 or 33 Date CS
Detailed Speed 80 EE F0 02 36 04 eller 24 Date CS
Technical Data 80 EE F0 02 36 05, 25 or 35 Date CS
Card download 80 EE F0 02 eller 03 36 06 Slot CS
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 332
Message Structure Max 4 Bytes Max 255 Bytes 1 Byte
Header Data CheckSum
IDE ->
Positive Response Transfer Data 80 F0 EE Len 76 TREP Data CS
Request Transfer Exit 80 EE F0 01 37 96
Positive Response Request Transfer
Exit
80 F0 EE 01 77 D6
Stop Communication Request 80 EE F0 01 82 E1
Positive Response Stop Communica­
tion
80 F0 EE 01 C2 21
Acknowledge sub message 80 EE F0 Len 83 Data CS
Negative responses
General reject 80 F0 EE 03 7F Sid Req 10 CS
Service not supported 80 F0 EE 03 7F Sid Req 11 CS
Sub function not supported 80 F0 EE 03 7F Sid Req 12 CS
Incorrect Message Length 80 F0 EE 03 7F Sid Req 13 CS
Conditions not correct or Request
sequence error
80 F0 EE 03 7F Sid Req 22 CS
Request out of range 80 F0 EE 03 7F Sid Req 31 CS
Upload not accepted 80 F0 EE 03 7F Sid Req 50 CS
Response pending 80 F0 EE 03 7F Sid Req 78 CS
Data not available 80 F0 EE 03 7F Sid Req FA CS
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 den
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 skal
vælge kortplads 2, hvis brugeren vælger dette.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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ørsels­
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 svar
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 positivt
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 indlede
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.002 — 334
2.2.2.6 L i n k C o n t r o l P o s i t i v e R e s p o n s e ( S I D C 7 )
DDP_053 Link Control Positive response angives af køretøjsenheden
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 for
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) 00
Overview 01 21 31
Aktiviteter på en nærmere
angivet dato
02 22 32
Hændelser og fejl 03 23 33
Detaljeret hastighed 04 24 24
Tekniske data 05 25 35
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 meddelelsen overfør
data angivet, hvilken kalenderdag (TimeReal format) der skal over­
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øjsenheden
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øjsenheden
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 fortæ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øretøjs­
enheden for at kvittere for Request Transfer Exit.
▼M1
02016R0799 — DA — 21.08.2023 — 003.002 — 336
2.2.2.13 S t o p C o m m u n i c a t i o n R e q u e s t ( S I D 8 2 )
DDP_015 Stop Communication Request afgives af IDE-enheden for at
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øjs­
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
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.002 — 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ørselsprocedure er
følgende:
IDE VU
Start Communication Request ⇨
⇦ Positive Response
Start Diagnostic Service Request ⇨
⇦ Positive Response
Request Upload ⇨
⇦ Positive Response
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 338
IDE VU
Transfer Data Request Overview ⇨
⇦ Positive Response
Transfer Data Request #2 ⇨
⇦ Positive Response #1
Acknowledge Sub Message #1 ⇨
⇦ Positive Response #2
Acknowledge Sub Message #2 ⇨
⇦ Positive Response #m
Acknowledge Sub Message #m ⇨
⇦ Positive Response (Data Field
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 relevante:
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.002 — 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 20
P2 20 1 000 (*)
P3 10 5 000
P4 5 20
P5 10 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 medde­
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øjsenhed 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 sekvens
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.002 — 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 kom
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.002 — 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 generation
gælder det, at hvert dataelement på øverste niveau repræsenteres af et
array med poster (record array), også selv om det kun indeholder én
post. Et record array indledes med et hoved. Dette hoved angiver post­
typen, poststørrelsen og antallet af poster. Record arrays navngives
»…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 Data
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.002 — 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 Data
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.002 — 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 Data
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.002 — 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.002 — 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.002 — 346
2.2.6.4 P o s i t i v e R e s p o n s e T r a n s f e r D a t a E v e n t s a n d F a u l t s
( 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 Data
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.002 — 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 Data
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.002 — 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 Data
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.002 — 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 af 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 takografkort 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 filidentifikatoren
med tilføjelsen »00«.
DDP_043 Etiketten for en elementærfils underskrift skal være filiden­
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 gemmes
(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.002 — 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 indholdet
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.002 — 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.002 — 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 tillæg 6
beskrevne kalibreringsgrænseflade. Det beskriver desuden styringen 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 data kan
aflæses fra køretøjsenheden, men ingen data kan skrives til den.
Valg af diagnosesession er beskrevet i punkt 5 »Administrationsser­
vicer«.
Dette tillæg skal betragtes som relevant for begge generationer af køre­
tøjsenheder og værkstedskort, som overholder de interoperabilitetskrav,
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 »tt«.
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.002 — 358
2. TERMER, DEFINITIONER OG HENVISNINGER
Protokoller, meddelelser og fejlkoder bygger hovedsagelig på udkastet
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 serviceidentifi­
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 testeren 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 vil 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.002 — 359
Tabel 1
Oversigtstabel over serviceidentifikatorer
Diagnosesession
Navn på diagnoseservice Afsnit nr.
Værdi af
Sid-anmodning
SD ECUAS ECUPS
StartCommunication 4.1 81 ■ ■ ■
StopCommunication 4.2 82 ■
TesterPresent 4.3 3E ■ ■ ■
StartDiagnosticSession 5.1 10 ■ ■ ■
SecurityAccess 5.2 27 ■ ■ ■
ReadDataByIdentifier 6.1 22 ■ ■ ■
WriteDataByIdentifier 6.2 2E ■
InputOutputControlByIdentifier 7.1 2F ■
▼M3
RoutineControl 8 31 ■ ■
▼B
■ Dette symbol angiver, at servicen er obligatorisk i denne diagnosesession.
Hvis der ikke er noget symbol, er servicen ikke er tilladt i denne diagnosesession.
3.2. Svarkoder
Svarkoder er defineret for hver service.
4. KOMMUNIKATIONSSERVICER
Visse servicer er nødvendige til at etablere og opretholde kommunika­
tion. De figurerer ikke i applikationslaget. I følgende tabel beskrives 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.002 — 360
CPR_007 Derefter skal køretøjsenheden udføre alle de operationer,
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 initiali­
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 overfø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.002 — 361
CPR_017 Synkroniseringsværdierne for hurtig initialisering og for
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 20
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 20
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 EE TGT
#3 Adressebyte på kilde tt SRC
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 362
Byte # Parameternavn Hex-værdi Huskeværdi
#4 Service-ID på StartCommu­
nication-anmodning
81 SCR
#5 Kontrolsum 00-FF CS
Tabel 6
Positivt svar på StartCommunication
Byte # Parameternavn Hex-værdi Huskeværdi
#1 Formatbyte — fysisk adres­
sering
80 FMT
#2 Adressebyte på destination tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 03 LEN
#5 Service-ID for positivt svar
på StartCommunication
C1 SCRPR
#6 Nøglebyte 1 EA KB1
#7 Nøglebyte 2 8F KB2
#8 Kontrolsum 00-FF CS
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.002 — 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 EE TGT
#3 Adressebyte på kilde tt SRC
#4 Ekstra længdebyte 01 LEN
#5 Service-ID på StopCommuni­
cation-anmodning
82 SPR
#6 Kontrolsum 00-FF CS
Tabel 8
Positivt svar på StopCommunication
Byte # Parameternavn Hex-værdi Huskeværdi
#1 Formatbyte — fysisk adres­
sering
80 FMT
#2 Adressebyte på destination tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 01 LEN
#5 Service-ID for positivt svar
på StopCommunication
C2 SPRPR
#6 Kontrolsum 00-FF CS
Tabel 9
Negativt svar på StopCommunication
Byte # Parameternavn Hex-værdi Huskeværdi
#1 Formatbyte — fysisk adres­
sering
80 FMT
#2 Adressebyte på destination tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 03 LEN
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 10 RC_GR
#8 Kontrolsum 00-FF CS
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 serveren
stadig er til stede for at undgå, at serveren automatisk returnerer til
normal drift og eventuelt standser kommunikationen. Denne service,
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 EE TGT
#3 Adressebyte på kilde tt SRC
#4 Ekstra længdebyte 02 LEN
#5 Identifikation af servicen
TesterPresent-forespørgsel
3E TP
#6 Delfunktion = response-
Required =
[ja 01 RESPREQ_Y
nej] 02 RESPREQ_NO
#7 Kontrolsum 00-FF CS
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.002 — 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 tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 01 LEN
#5 Identifikation af servicen
TesterPresent-forespørgsel
7E TPPR
#6 Kontrolsum 00-FF CS
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 80 FMT
#2 Adressebyte på destination tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 03 LEN
#5 Service-ID på negativt svar 7F NR
#6 Identifikation af servicen
TesterPresent-forespørgsel
3E TP
#7 response­
Code =
[SubFunctionNotSup­
ported-InvalidFormat
12 RC_SFNS_IF
incorrectMessage­
Length]
13 RC_IML
#8 Kontrolsum 00-FF CS
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 diagnostic­
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 givet i
følgende tabeller.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 367
Tabel 14
StartDiagnosticSession-anmodning
Byte # Parameternavn Hex-værdi Huskeværdi
#1 Formatbyte — fysisk adres­
sering
80 FMT
#2 Adressebyte på destination EE TGT
#3 Adressebyte på kilde tt SRC
#4 Ekstra længdebyte 02 LEN
#5 Service-ID på StartDiagno­
sticSession-anmodning
10 STDS
#6 diagnosticSession = [en værdi
fra Tabel 17]
xx DS_…
#7 Kontrolsum 00-FF CS
Tabel 15
Positivt svar på StartDiagnosticSession
Byte # Parameternavn Hex-værdi Huskeværdi
#1 Formatbyte — fysisk adres­
sering
80 FMT
#2 Adressebyte på destination tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 02 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 CS
Tabel 16
Negativt svar på StartDiagnosticSession
Byte # Parameternavn
Hex-
værdi
Huskeværdi
#1 Formatbyte — fysisk adressering 80 FMT
#2 Adressebyte på destination tt TGT
#3 Adressebyte på kilde EE SRC
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 368
Byte # Parameternavn
Hex-
værdi
Huskeværdi
#4 Ekstra længdebyte 03 LEN
#5 Service-ID på negativt svar 7F NR
#6 Service-ID på StartDiagnosticSes­
sion-anmodning
10 STDS
#7 Response­
Code =
[subFunctionNotSup­
ported ( α ) 12 RC_SFNS
incorrectMessage­
Length ( β )
13 RC_IML
conditionsNotCor­
rect ( γ )
22 RC_CNC
#8 Kontrolsum 00-FF CS
( α ) — værdien i byte #6 i anmodningen understøttes ikke, dvs. ikke 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.002 — 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 og
angive over for testeren, om køretøjsenheden er i funktionstilstand
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«-medde­
lelse, senere efterfulgt af en SecurityAccess »sendKey«-meddelelse.
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-kode 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 SecurityAc­
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.002 — 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 EE TGT
#3 Adressebyte på kilde tt SRC
#4 Ekstra længdebyte 02 LEN
#5 Service-ID på SecurityAc­
cess-anmodning
27 SA
#6 accessType — requestSeed 7D AT_RSD
#7 Kontrolsum 00-FF CS
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 04 LEN
#5 Service-ID for positivt svar
på SecurityAccess
67 SAPR
#6 accessType — requestSeed 7D AT_RSD
#7 Basistal højt 00-FF SEEDH
#8 Basistal lavt 00-FF SEEDL
#9 Kontrolsum 00-FF CS
Tabel 20
Negativt svar på SecurityAccess
Byte # Parameternavn
Hex-
værdi
Huskeværdi
#1 Formatbyte — fysisk adressering 80 FMT
#2 Adressebyte på destination tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 03 LEN
#5 Service-ID for negativeResponse 7F NR
#6 Service-ID på SecurityAccess-anmod­
ning
27 SA
#7 response­
Code =
[conditionsNotCorrec­
tOrRequestSequence­
Error
22 RC_CNC
incorrectMessage­
Length]
13 RC_IML
#8 Kontrolsum 00-FF CS
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 EE TGT
#3 Adressebyte på kilde tt SRC
#4 Ekstra længdebyte m+2 LEN
#5 Service-ID på SecurityAc­
cess-anmodning
27 SA
#6 accessType — sendKey 7E AT_SK
#7 til #m+6 Nøgle #1 (høj) xx KEY
… …
Nøgle #m (lav, m skal være
mindst 4 og højst 8)
xx
#m+7 Kontrolsum 00-FF CS
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 tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 02 LEN
#5 Service-ID for positivt svar
på SecurityAccess
67 SAPR
#6 accessType — sendKey 7E AT_SK
#7 Kontrolsum 00-FF CS
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 373
Tabel 23
Negativt svar på SecurityAccess
Byte # Parameternavn
Hex-
værdi
Huskeværdi
#1 Formatbyte — fysisk adressering 80 FMT
#2 Adressebyte på destination tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 03 LEN
#5 Service-ID på NegativeResponse 7F NR
#6 Service-ID på SecurityAccess-
anmodning
27 SA
#7 Response­
Code =
[generalReject 10 RC_GR
subFunctionNotSup­
ported
12 RC_SFNS
incorrectMessage­
Length
13 RC_IML
conditionsNotCorrec­
tOrRequestSequence­
Error
22 RC_CNC
invalidKey 35 RC_IK
exceededNumberO­
fAttempts
36 RC_ENA
requestCorrectlyRe­
ceived-ResponsePen­
ding]
78 RC_RCR_RP
#8 Kontrolsum 00-FF CS
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.002 — 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 EE TGT
#3 Adressebyte på kilde tt SRC
#4 Ekstra længdebyte 03 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 CS
Tabel 26
Positivt svar på ReadDataByIdentifier
Byte # Parameternavn
Hex-
værdi
Huskeværdi
#1 Formatbyte — fysisk adressering 80 FMT
#2 Adressebyte på destination tt TGT
#3 Adressebyte på kilde EE 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.002 — 375
Byte # Parameternavn
Hex-
værdi
Huskeværdi
#8 til #m+7 dataRecord[] = [data#1 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DAT­
Am
#m+8 Kontrolsum 00-FF CS
Tabel 27
Negativt svar på ReadDataByIdentifier
Byte # Parameternavn
Hex-
værdi
Huskeværdi
#1 Formatbyte — fysisk adressering 80 FMT
#2 Adressebyte på destination tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 03 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 CS
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 dette
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.002 — 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.002 — 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 80 FMT
#2 Adressebyte på destination EE TGT
#3 Adressebyte på kilde tt 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 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DAT­
Am
#m+8 Kontrolsum 00-FF CS
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 03 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 CS
Tabel 31
Negativt svar på WriteDataByIdentifier
Byte # Parameternavn
Hex-
værdi
Huskeværdi
#1 Formatbyte — fysisk adressering 80 FMT
#2 Adressebyte på destination tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 03 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 CS
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 identificeret ved
recordDataIdentifier, til serveren (køretøjsenheden). Dataformater 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 passende 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.002 — 380
CPR_060 Hvis der modtages hastighedsimpulser på køretøjsenhedens
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 EE TGT
#3 Adressebyte på kilde tt SRC
#4 Ekstra længdebyte xx 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 CS
Bemærk: Parameteren controlState findes kun i visse
tilfælde (se 7.1.3).
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte xx 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 CS
Tabel 35
Negativt svar på InputOutputControlByIdentifier
Byte # Parameternavn Hex-værdi Huskeværdi
#1 Formatbyte — fysisk adres­
sering
80 FMT
#2 Adressebyte på destination tt TGT
#3 Adressebyte på kilde EE SRC
#4 Ekstra længdebyte 03 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.002 — 382
Byte # Parameternavn Hex-værdi Huskeværdi
#7 responseCode=[
incorrectMessageLength 13 RC_IML
conditionsNotCorrect 22 RC_CNC
requestOutOfRange 31 RC_ROOR
deviceControlLimitsExceeded] 7A RC_DCLE
#8 Kontrolsum 00-FF CS
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 en n e v æ rd i an g iv er o v er fo r s erv eren
(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 00 I/O-linjen er deaktiveret (standardtilstand)
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 383
Funktionstil­
stand
Hex-værdi Beskrivelse
Aktivér 01 Aktivér ind/ud-linje for kalibrering som
speedSignalInput
Aktivér 02 Aktivér ind/ud-linje for kalibrering som real­
TimeSpeedSignalOutputSensor
Aktivér 03 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 muligt
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 80 FMT
#2 Target address byte EE TGT
#3 Source address byte tt SRC
#4 Additional length byte xx LEN
#5 RoutineControl Request Sid (Serviceidentifikation for anmodning
om RoutineControl)
31 RC
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 and #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 Checksum 00-FF CS
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 384
Tabel 37b
Rutinen RoutineControl (TimeAdjustment), delfunktionen startRoutine, positiv svarmeddelelse
Byte # Parameternavn Hex-værdi Huskeværdi
#1 Format byte – physical addressing 80 FMT
#2 Target address byte tt TGT
#3 Source address byte EE SRC
#4 Additional length byte xx LEN
#5 RoutineControl Positive Response Sid (Serviceidentifikation for
positivt svar for RoutineControl)
71 RCPR
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 and #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 Checksum 00-FF CS
Tabel 37c
Rutinen RoutineControl (TimeAdjustment) Request Message, delfunktionen requestRoutineResults
Byte # Parameternavn Hex-værdi Huskeværdi
#1 Format byte - physical addressing 80 FMT
#2 Target address byte EE TGT
#3 Source address byte tt SRC
#4 Additional length byte xx LEN
#5 RoutineControl Request Sid (Serviceidentifikation for anmodning
om RoutineControl)
31 RC
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 and #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 Checksum 00-FF CS
Tabel 37d
Rutinen RoutineControl (TimeAdjustment), delfunktionen requestRoutineResults, positiv svarmeddelelse
Byte # Parameternavn Hex-værdi Huskeværdi
#1 Format byte – physical addressing 80 FMT
#2 Target address byte tt TGT
#3 Source address byte EE SRC
#4 Additional length byte xx LEN
#5 RoutineControl Positive Response Sid (Serviceidentifikation for
positivt svar for RoutineControl)
71 RCPR
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 and #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 routineInfo (see Table 37f) XX RINF_TA
#10 routineStatusRecord[] = routineStatus#1 (see Table 37g) XX RS_TA
#11 Checksum 00-FF CS
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 385
Tabel 37e
Rutinen RoutineControl (TimeAdjustment) negativ svarmeddelelse
Byte # Parameternavn Hex-værdi Huskeværdi
#1 Format byte – physical addressing 80 FMT
#2 Target address byte tt TGT
#3 Source address byte EE SRC
#4 Additional length byte 03 LEN
#5 negativeResponse Service Id (Serviceidentifikation for negativt
svar)
7F NR
#6 inputOutputControlByIdentifier Request SId 31 RC
#7 responseCode=[
sub-functionNotSupported
incorrectMessageLengthOrInvalidFormat
conditionsNotCorrect
requestOutOfRange
]
12
13
22
31
SFNS
IMLOIF
CNC
ROOR
#8 Checksum 00-FF CS
Tabel 37f
Rutinen RoutineControl (TimeAdjustment), routineInfo
routineInfo Hex-værdi Beskrivelse
NormalExitWithResultAvailable 61 Rutinen blev gennemført. Yderligere rutineresultater er
tilgængelige.
RoutineExecutionOngoing 78 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 data­
transmissionsservicer, der er beskrevet i punkt 6.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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øjsenheden
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 FB FB00 til FBFF FB000000 til FBFFFFFF ingen
Område reserveret fremtidige indika­
torbit
FC til FD FC00 til FDFF FC000000 til FDFFFFFF ingen
Fejlindikator FE FE00 til FEFF FE000000 til FEFFFFFF 0
Foreligger ikke eller er ikke anmodet FF FF00 til FFFF FF000000 til FFFFFFFF FF
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 anvendes
via servicerne ReadDataByIdentifier og WriteDataByIdentifier.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 15 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 14 Se nærmere i Tabel 42
VIN 17 ASCII ASCII
SealDataVu 55 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 14 Se nærmere i Tabel 47
CalibrationCountry 3 ASCII NationAlpha som fastlagt i
tillæg 1
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 para­
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.002 — 389
CPR_078 Tabel 42 angiver formaterne for de forskellige byte i para­
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 para­
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 para­
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 para­
metrene VuSerialNumber, SensorSerialNumber,
SensorGNSSSerialNumber og RemoteCommunication­
ModuleSerialNumber:
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 para­
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.002 — 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 dertil) 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 funktioner, måle­
nøjagtighed og miljøegenskaber
— en interoperabilitetsattestering, som udføres af den kompetente
myndighed, og som certificerer, at kontrolapparatet (eller takograf­
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 inter­
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 typegodkendelse,
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 at kontrollere
resultaterne af disse sikkerhedsprøver. De krav, som der forventes prøvet
for (eller nærtbeslægtede prøver foretaget) som led i sikkerhedsatteste­
ringen, er mærket med »*« i tillægget.
De nummererede krav refererer til bilagets korpus, mens de øvrige krav
refererer til de andre tillæg (f.eks. refererer PIC_001 til kravet PIC_001 i
tillæg 3 Piktogrammer).
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 392
I dette tillæg er særskilt omhandlet typegodkendelse af bevægelsesføler,
køretøjsenhed og eksternt GNSS-udstyr som komponenter i kontrolappa­
ratet. Hver komponent får sin egen typegodkendelsesattest, hvori de øvrige
kompatible komponenter angives. Funktionsprøvningen af bevægelses­
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 bevæ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ægelsesføler
(eller eksternt GNSS-udstyr) kun udstedes sammen med typegodkendelsen
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 bestået de
OSNMA-prøver, der er beskrevet i dette tillæg. Disse prøver anses 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 and
guidance: Shock
IEC 60068-2-30: Environmental testing — Part 2-30: Tests — Test Db:
Damp heat, cyclic (12 h + 12 h cycle)
IEC 60068-2-64: Environmental testing — Part 2-64: Tests — Test Fh:
Vibration, broadband random and guidance
IEC 60068-2-78 Environmental testing — Part 2-78: Tests — Test Cab:
Damp heat, steady state
ISO 16750-3 — Mechanical loads (2012-12)
ISO 16750-4 — Climatic loads (2010-04).
ISO 20653: Road vehicles — Degree of protection (IP code) — Protection
of electrical equipment against foreign objects, water and access
ISO 10605:2008 + Technical Corrigendum:2010 + AMD1:2014 Road
vehicles — Test methods for electrical disturbances from electrostatic
discharge
ISO 7637-1:2002 + AMD1: 2008 Road vehicles — Electrical disturbances
from conduction and coupling — Part 1: Definitions and general
considerations.
ISO 7637-2 Road vehicles — Electrical disturbances from conduction and
coupling — Part 2: Electrical transient conduction along supply lines only.
ISO 7637-3 Road vehicles — Electrical disturbances from conduction and
coupling — Part 3: Electrical transient transmission by capacitive and
inductive coupling via lines other than supply lines.
ISO/IEC 7816-1 Identification cards — Integrated circuit(s) cards with
contacts — Part 1: Physical characteristics..
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 393
ISO/IEC 7816-2 Information technology — Identification cards — Inte­
grated circuit(s) cards with contacts — Part 2: Dimensions and location of
the contacts.
ISO/IEC 7816-3 Information technology — Identification cards — Inte­
grated circuit(s) cards with contacts — Part 3: Electronic signals and
transmission protocol.
ISO/IEC 10373-1:2006 + AMD1:2012 Identification cards — Test
methods — Part 1: General characteristics
ISO/IEC 10373-3:2010 + Technical Corrigendum:2013 Identification
cards — Test methods — Part 3: Integrated circuit cards with contacts
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: Diagnostics
ISO 16844-7 Road vehicles — Tachograph systems — Part 7: Parameters
ISO 534 Paper and board — Determination of thickness, density and
specific volume
▼M3
RGODP JRC Technical Report — Receiver guidelines for OSNMA data
processing (Retningslinjer for modtagere med henblik på OSNMA-data­
behandlingen)
▼B
FN/ECE R10 Uniform provisions concerning the approval of vehicles 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.002 — 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ærkstedskort 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.002 — 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 vejsidekontroller 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 og lagrer den/
de hændelse(er) og/eller den/de fejl, som køretøjsenhedsfabrikanten har
defineret, hvis en samparret bevægelsesføler reagerer på magnetiske
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.002 — 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.002 — 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.002 — 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.002 — 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 02
3.5 Det kontrolleres, at bevægelsesføleren er upåvirkelig af konstante 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ølerfejl.
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.002 — 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 ,
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
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.002 — 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 under
sikkerhedsattesteringen af chipmodulet i henhold til de fælleseuropæiske
kriterier.
Prøvning nr. 2.3 og 4.2 er de samme. Disse er de mekaniske prøvninger 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 vejsidekontroller 4, 197 til 199
3.2 Registrering og lagring i datalager 91
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.002 — 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.002 — 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.002 — 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 inden for
følgende grænser:
Udskrevne tegn: min. 1,0
Baggrund (ubeskrevet papir): maks. 0,2
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 418
De frembragte udskrifters optiske tæthed skal måles i overensstemmelse
med DIN EN ISO 534.
Udskrifterne må ikke udvise nogen dimensionsændringer og skal forblive
klart læsbare.
8. INTEROPERABILITETSPRØVER
▼M1
Nr. Prøve Beskrivelse
8.1 Interoperabilitetsprøver mellem køretøjsenheder og takografkort
1 Gensidig ægthedsbekræftelse Kontroller, at den gensidige ægthedsbekræftelse mellem køretøjs­
enheden og takografkortet afvikles normalt
2 Skrive-/læseprøver Gennemfør et typisk aktivitetsscenario på køretøjsenheden. Scena­
riet skal være tilpasset den afprøvede korttype og skal indebære
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 tilsva­
rende registreringer er udført korrekt
Gennem daglige udskrifter kontrolleres det, at alle de tilsvarende
registreringer kan læses korrekt.
8.2 Interoperabilitetsprøver mellem køretøjsenheder og bevægelsesfø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 tilsva­
rende registreringer er udført korrekt
Gennem daglige udskrifter kontrolleres det, at alle de tilsvarende
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øjs­
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 tilsva­
rende registreringer er udført korrekt
Gennem daglige udskrifter kontrolleres det, at alle de tilsvarende
registreringer kan læses korrekt.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 419
9. OSNMA-TEST
9.1. Indledning
I dette kapitel beskrives de prøver, der skal godtgøre, at OSNMA 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 beskrevet
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 og
resultaterne af de prøvninger, der udføres under GNSS-modtagerfabrikan­
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æringen om
OSNMA-tjenesten og under hensyntagen til de tilknyttede præstations­
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.002 — 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 med
flere konstellationer, som understøtter OSNMA-overførsel af meddelelser.
Alternativt kan der anvendes en radiofrekvensindikator, der kan tilbageføre
GNSS-signalprøver fra filer. Typisk bitdybde og prøvetagningshastighed
er henholdsvis 4 bit I/Q og 10MHz.
Det antages, at GNSS-modtageren har grænseflader til at styre clearingen
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 lokaltidsrealisering til
OSNMA's krav om tidsverifikation og til at indlæse de kryptografiske
oplysninger. Disse kommandoer kan være begrænset til testformål og er
derfor muligvis ikke tilgængelige ved modtagerens nominelle drift.
9.5 Prøvningsbetingelser
9.5.1 GNSS-betingelser
De simulerede eller afspillede GNSS-signaler har følgende egenskaber:
— Statisk brugermodtagerscenarie
— Mindst GPS- og Galileo-konstellationer
— E1/L1-frekvens
— Mindst fire Galileo-satellitter med en elevationsvinkel på mere end 5°
— Varighed som krævet for hver prøvning
— Konstante navigation-ephemerides fra satellitterne under prøven.
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.002 — 421
Medmindre andet er anført, skal modtagerens interne tidsrealisering 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 tidssynkro­
nisering er opfyldt for hver prøvningsbetingelse, dvs. nominel synkroni­
sering for alle prøver, undtagen SLMAC-prøven. Se OSNMA Receiver
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.002 — 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.002 — 423
Tillæg 10
SIKKERHEDSKRAV
Dette tillæg beskriver it-sikkerhedsforskrifterne for det intelligente takografsy­
stems komponenter (takograf af anden generation).
SEC_001 Følgende af det intelligente takografsystems komponenter skal sikker­
hedsattesteres i overensstemmelse med de fælleseuropæiske kriterier:
— køretøjsenhed
— takografkort
— bevægelsesføler
— eksternt GNSS-udstyr.
SEC_002 De it-sikkerhedsforskrifter, der som minimum skal opfyldes af hver
enkelt komponent, som skal sikkerhedsattesteres, skal fastlægges i en
komponentsikringsprofil i overensstemmelse med de fælleseuropæiske
kriterier.
SEC_003 Europa-Kommissionen skal sørge for, at følgende fire sikringsprofiler,
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 tilfælde, hvor køre­
tøjsenheden er beregnet til brug sammen med eksternt GNSS-udstyr, og i andre
tilfælde. I førstnævnte tilfælde anføres sikkerhedsforskrifterne 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 udvikle 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æres, at dette
sikkerhedsmål i alle henseender stemmer overens med den tilsvarende
sikringsprofil.
SEC_006 Sikkerhedsniveauet for hver sikringsprofil skal svare til EAL4 og de
udvidede sikkerhedskomponenter ATE_DPT.2 og AVA_VAN.5.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 fortrolighedsdata­
objekter
6. MEKANISMER TIL DIGITAL UNDERSKRIFT AF DATA­
OVERFØRSLER
6.1. Generering af underskrifter
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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æneparametre
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øgler
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øjsenheden
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 426
10.2.2 Kortcertifikatkædeverificering foretaget af kortet
10.3. Ægthedskontrol af køretøjsenhed
10.4. Ægthedskontrol af chip og overenstemmelseskontrol af sessions­
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øgleover­
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ægel­
sessensor ved hjælp af AES
12.4. Parring af køretøjsenhed og bevægelsessensor til forskellige
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.002 — 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 data overført mellem
forskellige komponenter eller overført til eksterne lagringsmedier.
Dette tillæg består af to dele. I del A er sikkerhedsmekanismer for digitale
takografsystemer af første generation (digitale takografer) defineret. I del B er
sikkerhedsmekanismer for digitale takografsystemer af anden generation (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 generation.
De mekanismer, der specificeres i del B i dette tillæg, finder anvendelse, hvis
begge takografsystemets komponenter, der anvendes ved en gensidig ægtheds­
kontrol og/eller dataoverførselsprocessen, er af anden generation.
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.002 — 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 kryptogram 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.002 — 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 kryptogra­
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 fortrolig­
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 relationer:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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ædnings-
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 hierarkiske
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 genere­
ring, eventuel transport og opbevaring.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 fortrolighed.
For at understøtte takografkomponenter, som er i overensstemmelse med
ISO 16844, skal den europæiske certificeringsmyndighed og medlems­
staternes certificeringsmyndigheder endvidere sikre følgende:
CSM_036 Den europæiske certificeringsmyndighed genererer KmVU og
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.002 — 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 gensi­
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 kryptogra­
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-selv­
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.002 — 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øjagtige opbyg­
ning af et ægthedscertifikat. Den kan bruges som intern identifikator
for udstyret i en relevant headerliste, som beskriver sammenkæd­
ningen af dataelementer i certifikatet.
Den headerliste, der er knyttet til indholdet af dette certifikat, 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
æ
rk
at
f
or
u
dv
id
et
h
ea
de
rl
is
te

L
æ
ng
de
a
f
he
ad
er
li
st
e
C
P
I-
m
æ
rk
at

C
P
I-
læ
ng
de

C
A
R
-m
æ
rk
at

C
A
R
-l
æ
ng
de

C
H
A
-m
æ
rk
at

C
H
A
-l
æ
ng
de

E
O
V
-m
æ
rk
at

E
O
V
-l
æ
ng
de

C
H
R
-m
æ
rk
at

C
H
R
-l
æ
ng
de

O
ff
en
tl
ig
n
øg
le
-m
æ
rk
at
(
ko
ns
tr
ue
re
t)

L
æ
ng
de
a
f
ef
te
rf
øl
ge
nd
e
da
ta
ob
je
kt
er

m
od
ul
us
-m
æ
rk
e
m
od
ul
us
-l
æ
ng
de

of
fe
nt
li
g
ek
sp
on
en
t-
m
æ
rk
e
of
fe
nt
li
g
ek
sp
on
en
t-
læ
ng
de

2. »Henvisning til certificeringsmyndighed« (CAR) har til formål at
identificere den certifikatudstedende myndighed på en sådan måde,
at dataelementet samtidig kan anvendes som identifikator for en
myndigheds nøgle og henvise til certificeringsmyndighedens offent­
lige nøgle (vedrørende kodning henvises til nøgleidentifikatoren
nedenfor).
3. »Certifikatindehavers autorisation« (CHA) anvendes til at identificere
certifikatindehaverens rettigheder. Den indeholder fartskriverapplika­
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.002 — 434
4. 4. »Henvisning til certifikatindehaver« (CHR) har til formål at iden­
tificere certifikatindehaveren entydigt, således at dataelementet på en
gang kan anvendes som identifikator for en persons nøgle og henvise
til certifikatindehaverens offentlige nøgle.
5. Nøgleidentifikatorer identificerer entydigt certifikatindehaver 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 af
det udstyr, nøglerne vil blive isat.
I første tilfælde sender fabrikanten identifikationen af udstyret
med den offentlige nøgle til den pågældende medlemsstats
myndigheder til certificering. Certifikatet vil derefter indeholde
identifikationen af udstyret, og fabrikanten skal sikre, at nøgler
og certifikat isættes det udstyr, det er bestemt for. Nøgleidenti­
fikatoren har den ovenfor viste form.
I sidstnævnte tilfælde skal fabrikanten entydigt identificere hver
anmodning om certifikat og sende denne identifikation med den
offentlige nøgle til den pågældende medlemsstats myndigheder til
certificering. Certifikatet vil indeholde identifikationen af anmod­
ningen. Fabrikanten skal melde tilbage til myndighederne i sin
medlemsstat med tilordning af nøgle til udstyr (dvs. identifikation
af anmodning om certifikat, identifikation af udstyr) efter instal­
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.002 — 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 certificerede offentlige
nøgle er en RSA-nøgle, som er relevant for ægthedskontrol, verifice­
ring af digital underskrift og kryptering til fortrolighedstjenester (certi­
fikatet indeholder ingen objektidentifikator til angivelse heraf).
3.3.2 Udstedte certifikater
CSM_018 Det udstedte certifikat er en digital underskrift med delvis
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 skjult af
underskriften, er ligeledes vedhæftet underskriften, således at certifi­
ceringsmyndighedens offentlige nøgle kan vælges til verificering af
certifikatet.
3. Certifikatkontrolløren skal implicit kende den algoritme, der af certi­
ficeringsmyndigheden er anvendt til at underskrive certifikatet.
4. Den headerliste, der er knyttet til dette udstedte certifikat, er som
følger:
»7F 21« »09« »5F 37« »81 80« »5F 38« »3A« »42« »08«
C
V
-c
er
ti
fi
ka
tm
æ
rk
at
(
ko
ns
tr
ue
re
t)

L
æ
ng
de
a
f
ef
te
rf
øl
ge
nd
e
da
ta
ob
je
kt
er

U
nd
er
sk
ri
ft
-m
æ
rk
at

U
nd
er
sk
ri
ft
-l
æ
ng
de

R
es
t-
m
æ
rk
e
R
es
t-
læ
ng
de

C
A
R
-m
æ
rk
at

C
A
R
-l
æ
ng
de

▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 436
3.3.3 Verificering og udpakning af certifikater
Certifikatverificering og -udpakning består i verificering af underskriften
i overensstemmelse med ISO/IEC 9796-2, hentning af certifikatets
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 certifikatet
æ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 medlemssta­
ternes certificeringsmyndigheder, som selv er certificeret af den europæ­
iske certificeringsmyndighed.
Dette sker ved, at der med den private nøgle underskrives et tilfældigt tal,
afsendt af den anden part, som derefter skal genfinde det afsendte tilfæl­
dige tal ved verificering af denne underskrift.
Mekanismen udløses af køretøjsenheden ved isætning af kortet. Den
begynder med udveksling af certifikater og udpakning af offentlige
nøgler og slutter med isætning af en sessionsnøgle.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 438
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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ørsel, 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 en
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.002 — 440
Givet et ikke-sikret kommando/svar-par:
Kommandoheader Kommandoindhold
CLA INS P1 P2 [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 P1 P2 [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« CC
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« CC
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.002 — 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« CC
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« CC
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 dataobjekter 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.002 — 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øgleover­
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 inden
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.002 — 443
6. MEKANISMER TIL DIGITAL UNDERSKRIFT AF DATAOVERFØR­
SLER
CSM_032 Det intelligente dedikerede udstyr (IDE) lagrer data, som 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 anvendes 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ølge
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 skal
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.002 — 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 circuit
cards — Part 4: Organization, security and commands for
interchange. Third edition 2013-04-15
ISO 7816-8 ISO/IEC 7816-8, Identification cards — Integrated circuit
cards — Part 8: Commands for security operations.
Second edition 2004-06-01
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 445
ISO 8825-1 ISO/IEC 8825-1, Information technology — ASN.1 enco­
ding rules: Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER). Fourth edition, 2008-12-15
ISO 9797-1 ISO/IEC 9797-1, Information technology — Security
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.002 — 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 certi­
fikatet for brugeren X
X.CHR henvisning til certifikatindehaveren, der er angivet i certi­
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 elliptisk
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.002 — 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.002 — 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.002 — 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 12
CS#3 512/521 256 SHA-512 16
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 gensidig
ægthedskontrol og sikker meddelelsesoverførsel mellem køretøjsenheder
og takografkort og mellem køretøjsenheder og eksterne GNSS-funk­
tioner. Disse processer beskrives i detaljer i tillæggets kapitel 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.002 — 450
CSM_52 I hele det europæiske intelligent takograf-system genereres,
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.002 — 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 skal
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 private
nøgle for et MSCA_VU-EGF-nøglepar have en nøgle­
brugsperiode på to år.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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 tilpas­
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 den
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.002 — 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 bestemt
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.002 — 456
9.1.6 Apparatniveau: Eksternt GNSS-udstyr
▼M1
CSM_93 Der genereres et entydigt ECC-nøglepar for hvert eksternt
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 et
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 inde­
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.002 — 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 ERCA-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.002 — 458
Bemærkninger til Figur 1:
1. Forskellige generationer af rodcertifikatet angives med et tal i
parentes. ERCA (1) er f.eks. første generation af ERCA-rodcertifi­
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 udstedt,
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 under
ERCA (2), MSCA_Card (2-last) er det sidste MSCA_Card-certifikat
udstedt under ERCA (2), Card_MA(2-1) er det første kortcertifikat til
gensidig ægthedskontrol, der er udstedt under ERCA (2) osv.
3. Certifikaterne MSCA_Card (2-1) og MSCA_Card (1-last) udstedes 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 vil
blive udstedt en smule senere end MSCA_Card (1-last), det sidste
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 kortcertifikater
udstedes under et MSCA-certifikat og ikke direkte under
ERCA-certifikatet. MSCA (2-1)-certifikatet vil blive udstedt umiddel­
bart efter, at ERCA (2) bliver gyldigt, men MSCA (1-last)-certifikatet
udstedes kun ganske kort tid inden dette tidspunkt, nemlig lige inden
ERCA (1)-certifikatet udløber. Derfor vil disse to MSCA-certifikater
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 interfacet
mellem en køretøjsenhed og en bevægelsessensor. Parringsprocessen
mellem en køretøjsenhed og en bevægelsessensor beskrives nærmere 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.002 — 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.002 — 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.002 — 461
CSM_108 Hver fabrikant af bevægelsessensorer genererer et entydigt
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ørende
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.002 — 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 rodnø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 et
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.002 — 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 generation
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.002 — 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øjsenheden
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.002 — 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 og
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øjsenhedsspecifikke
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 generation
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.002 — 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.002 — 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øretø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.002 — 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 PK »7F 49« var
Domæneparametre DP »06« var
Offentligt punkt PP »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-identifikator 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.002 — 469
CSM_140 For et ERCA-forbindelsescertifikat skal henvisningen til
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 identificere
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ører­
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 standardiserede
domæneparametre, der skal bruges sammen med den offentlige nøgle 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 offentlige
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 identifikator 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.002 — 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 kodede
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.002 — 471
CSM_153 En udstyrsfabrikant skal sende følgende data til en MSCA 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 certifikat, 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øre­
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.002 — 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øjs­
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.002 — 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.002 — 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.002 — 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 afsnit
9.1.4 betegnes disse som VU_MA.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 476
— VU.CA-certifikaterne og de offentlige nøgler, der nævnes i figuren,
er dem, der anvendes til underskrift af køretøjsenhedscertifikater 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-certifikatets CAR.
— VU.Link-certifikatet, der nævnes i figuren, er køretøjsenhedens
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 med 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-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 veri­
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.002 — 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 certifi­
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 gyldighed
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.002 — 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 verificeret
æ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å identifika­
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.002 — 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 til
æ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.002 — 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.002 — 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øjsenheden
ECKA-EG-algoritmen som defineret i [TR-03111].
CSM_179 I trin 5 og 8 ovenfor benytter kortet og køretøjsenheden
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.002 — 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 sendefrekvens­
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.002 — 483
10.5.2 Struktur af sikker meddelelse
CSM_188 Sikker meddelelsesoverførsel må udelukkende benytte data­
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.002 — 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 henhold 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 have
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 benyttes 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.002 — 485
Herunder gives tre eksempler på APDU-transformationer for komman­
doer med lige INS-kode. Figur 8 viser en autentificeret Alternativ 4-
kommando-APDU, Figur 9 viser en autentificeret Alternativ 1-/Alternativ
3-svar-APDU, og Figur 10 viser en krypteret og autentificeret Alternativ
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.002 — 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 meddelel­
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.002 — 487
CSM_193 Et takografkort afbryder en igangværende sikker meddelelses­
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 takografkort:
— 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.002 — 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 fastslå 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 eksternt
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 sammenkobles
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øjsenhed
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.002 — 489
11.3. Gensidig certifikatkædeverifikation
11.3.1 Generelt
CSM_205 Gensidig certifikatkædeverifikation mellem en køretøjsenhed
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.002 — 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-certi­
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.002 — 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, hvis
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 finder
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 ved
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.002 — 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 hovednøgle og
alle tilhørende nøgler regelmæssigt. Dette betyder, at op til tre 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ægelses­
sensor-relateret nøgle K M-VU.
CSM_217 En køretøjsenhed af anden generation og en bevægelsessensor
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.002 — 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 generation 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.002 — 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, der
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 16 16 16
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 16 16 16
41 svar Parringsnøgle 16 16 / 24 / 32 16 32 32
42 anmodning Sessionsnøgle 16 16 / 24 / 32 16 32 32
43 anmodning Parringsoplysninger 24 24 32 32 32
50 svar Parringsoplysninger 24 24 32 32 32
70 anmodning Ægthedskontroldata 8 8 16 16 16
80 svar MoS-tællerværdi +
ægthedskontroldata
8 8 16 16 16
▼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.002 — 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 kryp­
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.002 — 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 regelmæssigt
data til fjernovervågning af takograf (Remote Tachograph Monitoring —
RTM) og sender dem til det interne eller eksterne fjernkommunikations­
udstyr (Remote Communication Facility — RCF). Fjernkommunikations­
udstyret har ansvaret for at sende disse data via DSRC-interfacet, som
beskrives i tillæg 14, til fjerninterrogatoren. I tillæg 1 angives 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 strukturen af
DSRC-sikkerhedsdataene; den formelle specifikation findes i tillæ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øre­
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.002 — 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 og 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ægel­
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.002 — 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 fjerninterrogatoren, 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 bevæ­
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, som 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.002 — 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 digitale
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 til
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 kontrol­
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.002 — 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 kontrolkortet 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.002 — 501
Figur 13
Protokol til verifikation af underskriften ud fra en overført datafil
▼M1
02016R0799 — DA — 21.08.2023 — 003.002 — 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 produktionen
4.2. Kommunikation mellem det eksterne GNSS-udstyr og køretøjsenheden
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øgleoverens­
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øjsenheden
__________
5.3. Overførsel af oplysninger fra køretøjsenheden til GNSS-modtageren
5.4. Fejlhåndtering
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 protokoller,
der skal gennemføres for at garantere sikker og korrekt dataoverfø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.002 — 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 uden
eksternt GNSS-udstyr er levering af nøjagtige og pålidelige lokaliserings­
oplysninger et centralt element for en effektiv anvendelse af den intel­
ligente takograf. Derfor er det hensigtsmæssigt at kræve, at den er
forenelig med de serviceydelser, som leveres under programmerne
Galileo og European Geostationary Navigation Overlay Service (Egnos)
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 system, der er
oprettet under Egnosprogrammet, er et regionalt satellitnavigations­
system, der forbedrer kvaliteten af GPS-signalet (det globale positione­
ringssystem).
GNS_2 Fabrikanterne sikrer, at GNSS-modtagerne i de intelligente
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 af 11. december 2013 om
etablering og drift af de europæiske satellitbaserede navigationssystemer og om ophæ­
velse af Rådets forordning (EF) nr. 876/2002 og Europa-Parlamentets og Rådets
forordning (EF) nr. 683/2008 (EUT L 347 af 20.12.2013, s. 1).
02016R0799 — DA — 21.08.2023 — 003.002 — 505
GNS_3 GNSS-modtageren skal kunne understøtte Navigation Messages
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.002 — 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 forbindelse med
intelligente takografer til overførsel af standardpositionsmeddelelser og
ægthedsbekræftede positionsmeddelelser. Dette afsnit gælder både 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.002 — 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*hh
1) Tidspunkt (UTC)
2) Status, A=ægthedsbekræftet position (fastslået ved hjælp af mindst 4 satel­
litter, hvorfra navigationsmeddelelsernes ægthed er blevet verificeret)),
J=jamming eller O=andet GNSS-angreb uden mislykket ægthedsbekræftelse
af navigationsmeddelelser (af gennemførte overensstemmelseskontroller efter
GNS_3a), F=mislykket ægthedsbekræftelse af navigationsmeddelelser (som
registreret af OSNMA-verifikationer omhandlet i dokumenter nævnt 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.002 — 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 position
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 breddegrad
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.002 — 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.002 — 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 eksterne
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.002 — 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.002 — 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 eksterne
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 adgangs­
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.002 — 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« 85 85
1. GSA NMEA-sætning »02« 85 85
2. GSA NMEA-sætning »03« 85 85
3. GSA NMEA-sætning »04« 85 85
4. GSA NMEA-sætning »05« 85 85
5. GSA NMEA-sætning »06« 85 85
Udvidet serienummer for det eksterne
GNSS-udstyr defineret i tillæg 1 som
SensorGNSSSerialNumber.
»07« 8 8
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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« 16 16
Identifikator for sikkerhedskompo­
nenten for det eksterne GNSS-udstyr
defineret i tillæg 1 som SensorExter­
nalGNSSSCIdentifier
»10« 8 8
AMC-sætning »11« 85 85
1. ASA-sætning »12« 85 85
2. ASA-sætning »13« 85 85
3. ASA-sætning »14« 85 85
4. ASA-sætning »15« 85 85
5. ASA-sætning »16« 85 85
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øjsenhedens
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.002 — 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.002 — 516
GNS_23a Køretøjsenheden skal også skrive køretøjsenhedens RTC-tid
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 Record-
kommandoens struktur. Sikre meddelelser (tilstanden »Kun ægtheds­
kontrol«) tilføjes som beskrevet i tillæg 11, Fælles sikkerhedsmeka­
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.002 — 517
4.2.4 WriteRecord-kommandoens struktur
Dette afsnit indeholder en detaljeret beskrivelse af Write Record-komman­
doens struktur. Sikre meddelelser (tilstanden »Kun ægthedskontrol«)
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.002 — 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øglesoverens­
stemmelse for det eksterne GNSS-udstyr med køretøjsenhed beskrives
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 eksterne
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.002 — 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 fungerer
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.002 — 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 takograf
med og uden eksternt GNSS-udstyr.
GNS_39 Positionsdata skal lagres i køretøjsenheden sammen med et
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.002 — 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 til
»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øjs­
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.002 — 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.002 — 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.002 — 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 transportsy­
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 levere
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.002 — 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 forordninger 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 takografdata,
der overføres via ITS-interfacet, uden at ITS-interfacet involveres.
3.1. Kommunikationsteknologi
ITS_05 Kommunikation via ITS-interfacet sker via Bluetooth®-interfacet
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 etab­
leres, når en Bluetooth®-parring er udført.
ITS_07 Der etableres en sikker og krypteret kommunikation mellem 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.002 — 526
3.2. Tilgængelige tjenester
ITS_09 De data, der skal overføres via ITS-interfacet i overensstemmelse
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 stille
de tjenester til rådighed for ITS-enheden, der er nødvendige for
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, leverer 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 stik, 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 tjenester, der er anført
i tillæg 7 og 8, og erstatter den kabelforbindelse til det forreste 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 brugeren
afhængigt af den kombination af gyldige takografkort, der er isat i
køretøjsenheden, som anført i tabel 1.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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
K
or
tp
la
ds
f
or
m
ed
ch
au
ff
ø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 takografkort
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
K
or
tp
la
ds
f
or
m
ed
ch
au
ff
ø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®-forbindelsen skal tildeles (isat i førerkortpladsen eller i medchaufførens kort­
plads).
ITS_15 Hvis et takografkort udtages, afbryder køretøjsenheden den ITS
Bluetooth®-forbindelse, der er tildelt dette kort.
ITS_16 Køretøjsenheden skal understøtte ITS-forbindelsen til mindst én
ITS-enhed og kan understøtte forbindelser til flere ITS-enheder
samtidig.
ITS_17 Adgangsrettighederne til de data og tjenester, der er tilgæ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.002 — 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 derfor,
at disse personlige oplysninger kan forlade køretøjets net, bortset
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 som
obligatoriske, kan stilles til rådighed via ITS-interfacet. Yderligere
data, der ikke er medtaget i punkt 4, klassificeres som »personlige«
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øjsenheden,
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øjsenhedens
hukommelse.
ITS_24 Hvis der er tale om flere førere, vil kun personlige oplysninger 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 kalibrerings­
tilstand, forvaltes adgangsrettighederne via ITS-interfacet i overens­
stemmelse med krav 12 og 13 i bilag I C, og førerens samtykke er
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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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-interface
4.1.2 Profil 1a: via en håndholdt eller midlertidig vejsidemonteret læser i
udstyr til tidlig fjernafsløring
4.1.3 Profil 1b: via en køretøjsmonteret og dirigeret læser i udstyr 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.002 — 535
5.5 Forbeholdt fremtidig brug
▼B
5.6 Dataoverførsel mellem DSRC-køretøjsenheden og køretøjsenheden
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øjsenheden
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, der skal
følges for at gennemføre fjernkommunikationsfunktionen (kommunika­
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 takografen
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æder
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 parametre
i EN 300 674-1, {Electromagnetic compatibility and Radio
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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
indholdsdata 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 kendt 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 stand
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.002 — 537
bestemt køretøj, der angiver, at det pågældende køretøj har overtrå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 data kun
må være data eller vedrøre data, der angiver en mulig overtrædelse
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 kommunikation,
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 andre 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), og sådanne
operationer kan være separate eller sekventielle alt efter de kompetente
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 kommunikationsudstyret
— 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øjsenheden (som
er en funktion af produktdesignet, medmindre det specificeres andet­
steds i forordning (EU) nr. 165/2014)
— Formen af præsentationen af de indsamlede data for repræsentanten
for de kompetente kontrolmyndigheder eller de kriterier, som de
kompetente kontrolmyndigheder skal anvende til at beslutte, hvilke
køretøjer de vil standse (dette skal være en funktion af produktde­
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.002 — 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 af 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.002 — 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.002 — 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 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 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 ERC 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 standarder:
[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 tekst).
[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 spectrum
Matters (ERM); Road Transport and Traffic Telematics (RTTT);
Dedicated Short Range Communication (DSRC) transmission
equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz Indu­
strial, Scientific and Medical (ISM) band; Part 1: General charac­
teristics and test methods for Road Side Units (RSU) and On-Board
Units (OBU).
[6] EN 12253 Road transport and traffic telematics — Dedicated
short-range communication — Physical layer using microwave at
5.8 GHz.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 541
[7] EN 12795 Road transport and traffic telematics — Dedicated
short-range communication — Data link layer: medium access
and logical link control.
[8] EN 12834 Road transport and traffic telematics — Dedicated
short-range communication — Application layer.
[9] EN 13372 Road transport and traffic telematics — Dedicated
short-range communication — Profiles for RTTT applications
[10] ISO 14906 Electronic fee collection — Application interface defi­
nition for dedicated short-range communication
4 DRIFTSSCENARIER
4.1 Oversigt
Forordning (EU) nr. 165/2014 indeholder specifikke og kontrollerede
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-takograf­
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 ajour­
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.002 — 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 og
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-funk­
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 fjernkommunikationsenhed
med kort rækkevidde som læser i udstyr til tidlig fjernafsløring (5,8 GHz
DSRC-interfaces, der fungerer inden for ERC 70-03, og som er afprøvet
i forhold til de relevante parametre i EN 300 674-1 som beskrevet 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 kontrolmyndig­
heder, som kontrollerer anmodningen, hvorvidt køretøjet skal standses.
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 kompetente
kontrolmyndigheder sig ved vejsiden og retter en REDCR, der er hånd­
holdt, monteret på en trefod eller en tilsvarende type, fra vejsiden mod
midten af det udvalgte køretøjs forrude. Anmodningen gennemføres 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 674-1 som
beskrevet i afsnit 5. Se figur 14.1 (Brugssituation 1).
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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 kompetente
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 en bestemt
position i forhold til det udvalgte køretøj (f.eks. direkte foran 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 forhold 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 takograf
beskrives i figur 14.3.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 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 det
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.002 — 546
DSC_21 DSRC-antennen tilsluttes DSRC-køretøjsenheden enten direkte
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 for de
kompetente kontrolmyndigheder.
Et display og/eller en meddelelsesfunktion benyttes til at præsentere
resultaterne af fjernkommunikationsfunktionen for repræsentanten for
de kompetente kontrolmyndigheder. Et display kan have form af en
skærm, en udskrift, et lydsignal eller en kombination af sådanne medde­
lelser. Formen af et sådant display og/eller meddelelser fastlægges i
henhold til kravene fra repræsentanterne for de kompetente kontrolmyn­
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.002 — 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.002 — 548
Trinnene beskrives i det følgende:
a. Så snart køretøjet er i drift (tænding TIL), leverer takografen 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 tidligere 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 ønsker
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 fjernkommunikation.
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.002 — 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 overens­
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 driftsparametrene
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.002 — 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 ms (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.002 — 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øvning 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.002 — 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.002 — 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.002 — 554
DSC_32 Køretøjsenhedens antenne fastgøres til eller tæt ved køretøjets
forrude som specificeret i ovenstående 5.1.
DSC_33 I testmiljøet i et værksted (se afsnit 6.3) skal antennen 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.002 — 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.002 — 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.002 — 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.002 — 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 stan­
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.002 — 559
► (2) (3) M1
► (1) M3
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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.002 — 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 overensstemmelse
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.002 — 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
O
kt
et
n
r.
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.002 — 570
O
kt
et
n
r.
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
O
kt
et
n
r.
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.002 — 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
O
kt
et
n
r.
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.002 — 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
O
kt
et
nr
:
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.002 — 573
O
kt
et
nr
:
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.002 — 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
O
kt
et
n
r.
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.002 — 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
O
kt
et
n
r.
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.002 — 576
O
kt
et
n
r.
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
O
kt
et
n
r.
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.002 — 577
O
kt
et
n
r.
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.002 — 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-udveks­
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.002 — 579
Tabel 14.15
Eksempel på ramme for ACTION, ECHO-anmodning
O
kt
et
n
r.
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.002 — 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
O
kt
et
n
r.
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.002 — 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 og 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 skal
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.002 — 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.002 — 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.002 — 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 til 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 defineret 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 kombinatio­
nerne »transportabel REDCR« og »køretøj i bevægelse«, som denne
applikation omfatter. Derfor er det nødvendigt at vurdere forskellen
mellem en »læsefejl«- og en »fejl«-tilstand. I en transaktion via et tråd­
løst interface er læsefejl almindelige, og konsekvensen er normalt, 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 vellykket
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 tids­
interval, som er nødvendigt for at sende dataene igen (en »vellykket«
»læsning« kan have omfattet flere forsøg og gentagelser).
Læsefejl kan skyldes, at antennerne ikke var parret korrekt (»sigtefejl«),
at en af antennerne er skærmet — dette kan være bevidst, men kan også
skyldes, at et andet køretøj er fysisk til stede, radiointerferens, navnlig
fra omkring 5,8 GHz WIFI eller andre typer af trådløs kommunikation
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-kommunikations­
udstyrets rækkevidde. Individuelle forekomster af læsefejl kan i sagens
natur ikke registreres, fordi kommunikationen ganske enkelt ikke finder
sted.
Men hvis repræsentanten for den kompetente kontrolmyndighed retter
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 manipulation, og
derfor har repræsentanten for den kompetente kontrolmyndighed behov
for et værktøj til at logge fejlen og gøre kollegerne længere henne
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, kan
DSRC-køretøjsenheden ikke levere data vedrørende fejlen. Denne
rapportering skal derfor være en funktion i designet af REDCR-udstyret.
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 585
»Læsefejl« er teknisk set forskellig fra en »fejl«. I denne forbindelse 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, kontrolleres med
cykliske redundanskontroller (CRC) på kommunikationsniveau. Hvis
CRC valideres, er dataene korrekte. Hvis CRC ikke valideres, sendes
dataene igen. Sandsynligheden for, at data kan slippe forkert igennem en
CRC, er statistisk set så lille, at den lades ude af betragtning.
Hvis CRC'en ikke valideres, og der ikke er tid til at gensende og
modtage de korrekte data, bliver resultatet ikke en fejl, men en fore­
komst af en bestemt type læsefejl.
De eneste meningsfulde »fejl«-data, der kan registreres, er antallet af
vellykkede transaktionsindledninger, der forekommer, og som ikke
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 fjernkommunika­
tionsfunktionen:
▼B
02016R0799 — DA — 21.08.2023 — 003.002 — 586
1) En ECHO-afprøvning for at validere den trådløse kommu­
nikationskanal mellem DSRC-REDCR >>-:-
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 >>-:-
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-forbin­
delsen fungerer uden at kræve adgang til sikkerhedsoplysninger. Derfor
skal afprøvningsudstyret kun være i stand til at initialisere en
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 >>-:-
korrekt.
6.3 Afprøvning til validering af sikkert dataindhold
DSC_85 Dette afprøvning gennemføres for at validere ende-til-ende-
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.002 — 587
Addendum
Regler for beregning af daglig køretid, ugentlig køretid og køretid for 14 dage
1. Grundlæggende beregningsregler
Køretøjsenheden beregner den daglige køretid, den ugentlige køretid 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 (kortplads 1, kortlæser
#1) i køretøjsenheden, og udvalgte føreraktiviteter, mens kortet er isat i køre­
tøjsenheden.
Køretiderne beregnes ikke, når der ikke er isat et førerkort (eller værksteds­
kort).
UKENDTE perioder i den periode, der skal bruges til beregningerne, side­
stilles med PAUSE/HVILE.
UKENDTE perioder og aktiviteter af negativ varighed (dvs. aktivitetens start
finder sted senere end aktivitetens afslutning) på grund af tidsoverlapninger
mellem to forskellige køretøjsenheder eller på grund af tidsjustering
medregnes ikke.
Aktiviteter, der registreres på førerkortet svarende til »UDEN FOR GYLDIG­
HEDSOMRÅDE«-perioder i overensstemmelse med definition gg) i bilag 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 hviletid og afslut­
ningen af den umiddelbart efterfølgende daglige hviletid.
Køretøjsenheden påbegynder et nyt RTM-skift, når en daglig hviletid er
afsluttet.
Det igangværende RTM-skift er perioden siden sidste daglige hviletids
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ærende uge
e) »sammenhængende hviletid«: enhver uafbrudt periode med PAUSE/
HVILE
f) »køretid for 14 dage«: den akkumulerede køretid for den foregående og
den indeværende uge
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 for daglige
hviletider, når en køretøjsenhed beregner de ugentlige hviletider
h) »regulær daglig hviletid«: en sammenhængende hviletid på mindst 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 time. Det
betyder, at en regulær daglig hviletid, der opfatter perioder med 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 hviletid ifølge
punkt 3 er på mindst 11 timer.
Når en regulær daglig hviletid er blevet afbrudt, skal køretøjsenheden:
— 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 daglige
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å mindst ni
timer og mindre end 11 timer
j) »opdelt daglig hviletid«: en daglig hviletid fordelt på to dele:
— den første del er en sammenhængende hviletid på mindst tre timer og
mindre end ni timer
— den anden del er en sammenhængende hviletid på mindst ni timer.
Når tilstanden OVERFART MED FÆRGE/TOG er aktiv under en eller
begge dele af en opdelt daglig hviletid, kan den opdelte daglige 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 en 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.002 — 589
— den første del af den opdelte daglige hvileperiode kan afbrydes é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 hviletid og
mindre end ni timer for den anden hviletid, når den første hviletid er
blevet afbrudt af en OVERFART MED FÆRGE/TOG.
— på mindst tre timer og mindre end ni timer for den første hviletid 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øjsenheden:
— 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 daglige
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 af overfart med
færge/tog, beregner køretøjsenheden den akkumulerede hviletid efter følgende
trin:
a) Trin 1
Køretøjsenheden skal registrere afbrydelser af hviletiden før aktiveringen 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ølgende betin­
gelser er opfyldt:
— afbrydelsen bevirker, at den samlede varighed af de 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 mere
end én time i alt
— afbrydelsen bevirker, at det samlede antal registrerede afbrydelser,
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 arbejdstid
slutter« efter afbrydelsens ophør.
Hvis ingen af ovennævnte betingelser er opfyldt, lægges den sammenhæn­
gende hviletid umiddelbart forud for afbrydelsen til den akkumulerede
hviletid.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 590
Hvis mindst én af ovennævnte betingelser er opfyldt, skal køretøjsenheden
stoppe beregningen af den akkumulerede hviletid efter trin 2 eller 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øretøjsenheden,
om beregningen af den akkumulerede hviletid skal standses. Køretø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, herunder 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 beregningen af
den akkumulerede hviletid, skal køretøjsenheden registrere afbrydelser, 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, om afbry­
delsen bevirker, at den akkumulerede tid for alle registrerede afbrydelser
overstiger mere end én time i alt. I så fald afsluttes beregningen af den
akkumulerede hviletid ved afslutningen af den sammenhængende hviletid
før afbrydelsen. Ellers lægges de sammenhængende hviletider, der 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øjsenheden
som resultat af trin 1 og 3 har lagt højst to sammenhængende hviletider
til den hviletid, for hvilken betingelsen OVERFART MED FÆRGE/TOG
er aktiveret, herunder i givet fald afbrydelser i den første del 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.002 — 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.002 — 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 afbrydelserne 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 ikke har beregnet
en fuldstændig regulær eller opdelt daglig hviletid ifølge punkt 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øretiden for 14
dage. Den køretid, der finder sted under afbrydelserne af de daglige hviletider
på grund af overfart med færge/tog, lægges til beregningen af den ugentlige
køretid og køretiden for 14 dage.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 kalibreringsudstyr
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 overgangen mellem
digitale takografsystemer af første og anden generation, og anden version
af kontrolapparater og takografkort af anden generation introduceres.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 594
Ud over bestemmelserne i denne indledning fremhæves følgende
oplysninger:
— bevægelsesfølere af første generation er ikke interoperable med 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 begge 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 interoperable med
køretøjsenheder af første generation i henhold til bilag I B til forordning
(EØF) nr. 3821/85, mens takografkort af anden generation, uanset version,
er interoperable med køretøjsenheder af anden generation, uanset version, i
henhold til bilag I C til denne forordning). Desuden gælder følgende krav.
MIG_001 Bortset fra bestemmelserne i krav MIG_004 og MIG_005 kan
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, skal
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 anvende
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 version,
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 interoperable
med køretøjsenheder af første generation, mens bevægelsesfølere af anden
generation er interoperable med køretøjsenheder af anden generation,
uanset version. Desuden gælder følgende krav.
MIG_007 Køretøjsenheder af anden generation, uanset version, kan ikke
parres og anvendes med bevægelsesfølere af første generation.
▼M3
02016R0799 — DA — 21.08.2023 — 003.002 — 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 generation,
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, uanset
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, der 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.002 — 596
2.4.3 Overførsel fra køretøjsenhed
MIG_014 Uden for rammerne af førerkontrol udført af kontrolmyndig­
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 hver
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 med 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ægelsesfø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ærksteds­
kort af anden generation senest en måned før indførelses­
datoen.
MIG_021 Medlemsstaterne skal kunne udstede version 2 af alle andre
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 kun
udstede version 2 af takografkort af anden generation.
MIG_023 Fabrikanter af køretøjsenheder/bevægelsesfølere har tilladelse
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.002 — 597
MIG_023a Med virkning fra indførelsesdatoen erstattes fejlbehæftede
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 tilladelse
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 region,
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.002 — 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 hastighedsimpulser
4.2. Tilførsel af de indkommende impulser til den indlejrede bevæ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.002 — 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 bestemmelserne
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 ifø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 dette bilag skal
fortolkes, når en adapter anvendes. Numrene på de tilknyttede krav 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 kontrolapparatet kabler,
adapteren (inklusive en bevægelsesføler) og en køretøjsenheden
(01).
ADA_007 Detektionen af hændelser og/eller fejl ved kontrolapparater
æ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.002 — 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 mulighed 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 frekvens­
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 tilpasse
signalet til det k-faktorbånd, som defineres i dette bilag (2 400
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 speci­
ficeret ovenfor, tilføres den indlejrede bevægelsesføler således,
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 tilfø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.002 — 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 åbnes. 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ægelses­
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 udledes på
grundlag af adapterens indgangssignal.
4.5. Funktionsspecifikationer
ADA_020 Adapteren skal være fuldt funktionsdygtig i det temperatur­
interval, som fabrikanten har defineret.
ADA_021 Adapteren skal være fuldt funktionsdygtig i fugtighedsinter­
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 internatio­
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.002 — 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 installeres af
køretøjsfabrikanten eller af godkendte værksteder, der har tilla­
delse til at installere, aktivere og kalibrere digitale takografer
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 eftersyn (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.002 — 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 af 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 kontrolapparatet
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 med
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 eller 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.002 — 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.002 — 605
Tillæg 17
OVERGANGSBESTEMMELSE VEDRØRENDE TAKOGRAFERS BRUG
AF OSNMA
1. DEFINITIONER OG AKRONYMER
1.1. Definitioner
Erklæring om Galileo Open Service Navigation Message Authentica­
tion-tjeneste (OSNMA): erklæringen fra Europa-Kommissionen om, at
Galileo OSNMA går ind i sin operationelle fase.
Overgangskøretøjsenhed: en køretøjsenhed, der er i overensstemmelse
med bestemmelserne i dette tillæg.
Overgangskøretøjsenheder er konstrueret i overensstemmelse med SIS
ICD og OSNMA Receiver Guidelines, som finder anvendelse for
OSNMA i den offentlige prøvningsfase. De indeholder en
GNSS-modtager, som er i stand til at bruge OSNMA, som denne er
tilgængelig i løbet af dens offentlige prøvningsfase.
Overgangskøretøjsenheder er dog ikke i stand til at ægthedsbekræfte navi­
gationsmeddelelser, som er tilgængelige, efter at erklæringen om
OSNMA-tjenesten foreligger, på grund af behovet for at ajourføre køre­
tøjsenhedens kryptografiske materiale. Det er nødvendigt at gennemføre en
passende softwareopdatering, så overgangskøretøjsenhederne kan begynde
at bruge OSNMA og opfylde alle kravene i bilag I C og tillæg 1-16 hertil.
Inden overgangskøretøjsenhederne bliver ajourført, gennemfører de de
OSNMA-relaterede funktionaliteter som angivet i dette tillæg. Funktiona­
liteter, som ikke vedrører OSNMA, forbliver uændrede.
Hvis den passende softwareopdatering gennemføres, gennemfører over­
gangskøretøjsenhederne SIS ICD og OSNMA Receiver Guidelines
gældende for OSNMA's operationelle fase og opfylder alle kravene i
bilag I C og tillæg 1-16 hertil ved hjælp af OSNMA, som denne er
tilgængelig i løbet af den operationelle fase.
Overgangstakograf: takograf inklusive en overgangskøretøjsenhed.
1.2. Akronymer
ICD Interface Control Document (grænsefladekontroldo­
kument)
OSNMA Galileo Open Service Navigation Message Authen­
tication (ægthedsbekræftelse af navigationsmedde­
lelse via åben Galileo-tjeneste)
SIS Signal in Space (signal i rummet)
VU Køretøjsenhed
▼M4
02016R0799 — DA — 21.08.2023 — 003.002 — 606
2. GENERELLE OVERVEJELSER VEDRØRENDE OSNMA
For at gøre det muligt at udstyre køretøjer, der registreres for første gang,
med takografer af version 2 af anden generation fra den dato for indfø­
relse, der anmodes om, jf. bilag I C, afsnit 1, definition ccc), i gennem­
førelsesforordning (EU) 2016/799, er det nødvendigt at typegodkende,
producere og markedsføre køretøjsenhederne, inden erklæringen om
OSNMA-tjenesten foreligger. For disse køretøjsenheder, kaldet overgang­
skøretøjsenheder, er det nødvendigt at tilpasse de OSNMA-relaterede krav
i bilag I C og tillæg 1-16 hertil, så køretøjsenhederne kan typegodkendes
og anvendes.
De bestemmelser, der er fastsat i nærværende tillæg, definerer de speci­
fikke krav, der finder anvendelse på overgangskøretøjsenheder. De finder
kun anvendelse på køretøjsenheder med en intern GNSS-modtager.
3. KRAV, DER FINDER ANVENDELSE PÅ GNSS-MODTAGEREN I
OVERGANGSTAKOGRAFER
TRA_001 Overgangskøretøjsenheder omfatter en GNSS-modtager, som
er i stand til at bruge OSNMA, som denne er tilgængelig i løbet af
dens offentlige prøvningsfase.
TRA_002 Kravene i tillæg 12 finder anvendelse på den GNSS-modtager,
som overgangskøretøjsenheden omfatter, med følgende fortolkninger:
— SIS ICD og OSNMA Receiver Guidelines, som der henvises til, er de
dokumenter, der er tilgængelige for den offentlige prøvningsfase:
— Galileo Open Service Navigation Message Authentication
(OSNMA) User ICD for the Test Phase, Issue 1.0, november 2021,
— Galileo Open Service Navigation Message Authentication
(OSNMA) Receiver Guidelines for the Test Phase, Issue 1.0,
november 2021,
— OSNMA er den tjeneste, der er tilgængelig i den offentlige prøvnings­
fase
— SIS er den Signal in Space-tjeneste, der er tilgængelig i den offentlige
prøvningsfase.
TRA_003 Den GNSS-modtager, som overgangskøretøjsenhederne
omfatter, skal være konstrueret således, at den efter en opdatering af
dens software, som gennemføres via en opdatering af køretøjsenhedens
software, fuldt ud opfylder kravene i bilag 12 og bruger OSNMA, som
denne er tilgængelig i løbet af dens operationelle fase.
4. KRAV, DER FINDER ANVENDELSE PÅ OVERGANGSKØRETØJS­
ENHEDER
Overgangskøretøjsenhederne kan behandle det OSNMA-signal, der er
tilgængeligt i løbet af OSNMA's offentlige prøvningsfase, men er ikke i
stand til at rapportere Navigation Messages Authentication Status fra SIS,
som er tilgængelig i løbet af OSNMA's operationelle fase, før en passende
softwareopdatering er gennemført. De antager derfor, at standardpositio­
nerne fra GNSS-modtageren altid er ægthedsbekræftede.
Kravene i bilag I C og tillæg 1-16 hertil finder anvendelse, med følgende
fortolkninger.
▼M4
02016R0799 — DA — 21.08.2023 — 003.002 — 607
TRA_004 I bilag I C, 3.9.15, Hændelsen »tidskonflikt«, forstås krav 86
således:
Denne hændelse skal udløses uden for kalibreringstilstand, hvis køretøjs­
enheden registrerer en forskel mellem tiden i køretøjsenhedens tids­
målingsfunktion og tidsangivelsen fra de standardpositioner, der er over­
fø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 »tidskonflikt«, umiddelbart inden køre­
tøjsenheden automatisk justerer køretøjsenhedens interne ur, i overens­
stemmelse med krav 211.
TRA_005 I bilag I C, 3.9.18, Hændelsen »GNSS-anomali«, forstås krav
88a således:
Denne hændelse skal udløses uden for kalibreringstilstand, når
GNSS-modtageren registrerer et angreb , 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.
TRA_006 I bilag I C, 3.12.5, Registrering og lagring i datalageret, Steder
og positioner, hvor daglige arbejdsperioder starter, slutter og/eller hvor tre
timers kumuleret køretid nås, forstås krav 110 således:
Sammen med hvert sted eller hver position skal kontrolapparatet regi­
strere og i sit datalager gemme:
— kortnummer for fører og/eller medchauffør samt kortudstedende
medlemsstat
— kortgeneration
— indlæsningsdato og -klokkeslæt
— indlæsningens art (begyndelse, slutning eller tre timers kumuleret
køretid)
— den tilhørende GNSS-nøjagtighed, dato og tid, hvis relevant
— køretøjets kilometerstand
— et flag, der viser, om positionen er blevet antaget som værende
ægthedsbekræftet.
TRA_007 I bilag I C, 3.12.17, Registrering og lagring i datalageret,
Grænsepassager, forstås krav 133b således:
Sammen med lande og positionen skal kontrolapparatet registrere og i sit
datalager gemme:
— kortnummer for fører og/eller medchauffør samt kortudstedende
medlemsstat
— kortgeneration
— den tilhørende GNSS-nøjagtighed, dato og tid
— et flag, der viser, om positionen er blevet antaget som værende
ægthedsbekræftet
— køretøjets kilometerstand på tidspunktet for registrering af grænsepas­
sage.
▼M4
02016R0799 — DA — 21.08.2023 — 003.002 — 608
TRA_008 I bilag I C, 3.12.18, Registrering og lagring i datalageret,
Laste-/losseoperationer, forstås krav 133g således:
Sammen med operationstypen og positionen skal kontrolapparatet regi­
strere og i sit datalager gemme:
— kortnummer for fører og/eller medchauffør samt kortudstedende
medlemsstat
— kortgeneration
— 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 antaget som værende
ægthedsbekræftet
— køretøjets kilometerstand.
TRA_009 I bilag I C, 3.23, Tidsjustering, forstås krav 211 således:
Tidsindstillingen af køretøjsenhedens interne ur skal automatisk justeres
med variable intervaller. Den næste automatiske tidsjustering udløses
mellem 72 timer og 168 timer efter den foregående, og efter at køretøjs­
enheden kan få adgang til GNSS-tiden gennem en gyldig standardposi­
tionsmeddelelse i overensstemmelse med tillæg 12. Tidsjusteringen må
imidlertid aldrig være større end den akkumulerede maksimale tidspunkt­
drift pr. dag som beregnet af køretøjsenhedens fabrikant i overensstem­
melse med krav 41b. Hvis forskellen mellem klokkeslættet på køretøjs­
enhedens interne ur og klokkeslættet på GNSS-modtageren overstiger
den akkumulerede maksimale tidspunktdrift pr. dag, skal tidsjusteringen
bringe køretøjsenhedens 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 standardpositionsmed­
delelser som fastsat i tillæg 12. Referencetidspunktet for den automatiske
indstilling af køretøjsenhedens interne ur skal være klokkeslættet i stan­
dardpositionsmeddelelsen.
TRA_010 I bilag I C, 3.23, Tidsjustering, forstås krav 212 således:
Tidsjusteringsfunktionen skal også muliggøre hændelsesudløst justering af
det aktuelle klokkeslæt i kalibreringstilstand.
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
— 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 standardpositionsmedde­
lelser. I sidstnævnte tilfælde anvendes tjenesten RoutineControl i over­
ensstemmelse med afsnit 8 i tillæg 8.
▼M4
02016R0799 — DA — 21.08.2023 — 003.002 — 609
TRA_011 Tillæg 4, 2. Specifikation af datagrupper, stk. 1, syvende led,
forstås således:
Når dette piktogram udskrives efter længdegraden og breddegraden af
en registreret position eller efter det tidspunkt, hvor positionen blev
bestemt, angiver det, at positionen er blevet antaget som værende
ægthedsbekræftet.
TRA_012 Tillæg 8, 8.1 RoutineControl Service (Tidsjustering), Beskri­
velse af meddelelser, krav CPR_065a, forstås således:
Tjenesten RoutineControl (TimeAdjustment) gør det muligt 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øjs­
enheden være i tilstanden CALIBRATION.
Forudsætning: Det sikres, at køretøjsenheden kan modtage standardposi­
tionsmeddelelser fra GNSS-modtageren.
Så længe tidsjusteringen er i gang, skal køretøjsenheden besvare anmod­
ningen RoutineControl, delfunktionen requestRoutineResults, med routi­
neInfo = 0x78.
Bemærk: Tidsjusteringen kan tage nogen tid. Diagnosetesteren skal
anmode om status for tidsjustering ved hjælp af delfunktionen requestRou­
tineResults.
TRA_013 I tillæg 12, 3 Sætninger fra GNSS-modtageren, krav GNS_4a:
Eventuelle data indeholdt i AMC-sætninger fra GNSS-modtageren skal
ikke anvendes af køretøjsenheden, med undtagelse af følgende værdier
for status:
J = jamming eller O = andet GNSS-angreb (af gennemførte overensstem­
melseskontroller efter GNS_3a)
V = Void (ægthedsbekræftet position er ikke tilgængelig af andre årsager)
TRA_014 I tillæg 12, 3 Sætninger fra GNSS-modtageren, krav GNS_5:
Eventuelle data indeholdt i ASA-sætninger fra GNSS-modtageren skal ikke
anvendes af køretøjsenheden.
TRA_015 I tillæg 12, 5.2 Køretøjsenhed uden eksternt GNSS-udstyr,
Overførsel af oplysninger fra GNSS-modtageren til køretøjsenheden,
krav GNS_34 og 36:
Køretøjsenhedens processor må ikke anvende information, som udledes af
AMC-sætningen, med undtagelse af følgende værdier for status:
J = jamming eller O = andet GNSS-angreb (af gennemførte overensstem­
melseskontroller efter GNS_3a)
V = Void (ægthedsbekræftet position er ikke tilgængelig af andre årsager)
Køretøjsenhedens processor må ikke anvende information, som udledes af
ASA-sætningen.
▼M4
02016R0799 — DA — 21.08.2023 — 003.002 — 610
TRA_016 I tillæg 12, 6 Køretøjsenhedens behandling og registrering af
positionsdata, forstås krav GNS_39 således:
Positionsdata skal lagres i køretøjsenheden sammen med et flag, der viser,
om positionen er blevet antaget som værende ægthedsbekræftet. Når posi­
tionsdata skal registreres i køretøjsenheden, gælder følgende regel:
a) Hvis standardpositionen er gyldig, registreres standardpositionen og
dens nøjagtighed i køretøjsenheden, og flaget indstilles til »ægtheds­
bekræftet«.
TRA_017 I tillæg 12, 6 Køretøjsenhedens behandling og registrering af
positionsdata, forstås krav GNS_40 således:
Når værdien af status i en modtaget AMC-sætning er sat til »J« eller »O«
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.
TRA_018 I tillæg 12, 8 Køretøjsbevægelseskonflikt, krav GNS_42, Udlø­
sende betingelse 2, forstås første og andet led efter formlen således:
— GnssDistance er afstanden mellem køretøjets nuværende position og
den foregående position, som begge er opnået ved gyldige standard­
positionsmeddelelser , uden hensyntagen til højden
— OdometerDifference er forskellen mellem den aktuelle kilometerstand
og kilometertællerens værdi svarende til den tidligere gyldige stan­
dardpositionsmeddelelse
TRA_019 I tillæg 14, 5.4.5 DRSC-protokolkrav for Elementer af
RtmData, udførte handlinger og definitioner, krav DSC_41, tabel 14.3,
forstås anden rubrik i rækken RTM20 således:
Køretøjsenheden generer en heltalsværdi (timeReal fra tillæg 1) for datae­
lementet RTM20.
Køretøjsenheden indstiller værdien for RTM20 til det tidspunkt, hvor den
seneste standardkøretøjsposition var tilgængelig fra GNSS-modtageren.
Hvis en standardkøretøjsposition ikke var tilgængelig fra
GNSS-modtageren, indstiller køretøjsenheden værdien for RTM20 til 0.
TRA_020 Fabrikanten af en typegodkendt køretøjsenhed oplyser
Kommissionen om køretøjsenhedens softwareversioner. Kommissionen
offentliggør disse softwareversioner på et offentligt tilgængeligt websted.
▼M4
02016R0799 — DA — 21.08.2023 — 003.002 — 611
5. SPECIFIKKE BESTEMMELSER FOR TYPEGODKENDELSE OG
ANVENDELSE AF OVERGANGSTAKOGRAFER
TRA_021 Overgangskøretøjsenheder skal typegodkendes i overensstem­
melse med kravene i bilag I C og tillæg 1-16 hertil suppleret af bestem­
melserne i nærværende tillæg.
TRA_022 Det er kun muligt at anmode om typegodkendelsesattester for
overgangskøretøjsenheder og overgangstakografer indtil den 31. december
2023 eller indtil erklæringen om OSNMA-tjenesten foreligger, alt efter
hvilken af disse datoer er den seneste.
TRA_023 Køretøjer, der registreres for første gang, må kun udstyres med
overgangskøretøjsenheder indtil den 31. maj 2024 eller indtil fem måneder
efter erklæringen om OSNMA-tjenesten foreligger, alt efter hvilken af
disse datoer er den seneste.
▼M4
02016R0799 — DA — 21.08.2023 — 003.002 — 612
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 typegodkendelsen 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 typegodken­
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.002 — 613
2. Godkendelsesmærket anbringes på hvert apparats typeplade, på hvert diagra­
mark og på hvert takografkort. Mærket må ikke kunne udslettes og 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 overholdes.
▼C1
( 1 ) Disse tal er kun vejledende.
02016R0799 — DA — 21.08.2023 — 003.002 — 614
II. TYPEGODKENDELSESDOKUMENT FOR ANALOGE TAKOGRAFER
Den medlemsstat, der har meddelt en typegodkendelse, udsteder en typegodken­
delsesattest til ansøgeren efter følgende model. Til underretning af andre
medlemsstater om den meddelte typegodkendelse eller om eventuelle 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 kontrolapparat
— 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 hvilket (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.002 — 615
III. TYPEGODKENDELSESDOKUMENT FOR DIGITALE TAKOGRAFER
Den medlemsstat, der har meddelt en typegodkendelse, udsteder en typegodken­
delsesattest til ansøgeren efter følgende model. Til underretning af andre
medlemsstater om den meddelte typegodkendelse eller om eventuelle 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.002 — 616
IV. GODKENDELSESATTEST FOR INTELLIGENTE TAKOGRAFER
Den medlemsstat, der har meddelt en typegodkendelse, udsteder en typegodken­
delsesattest til ansøgeren efter følgende model. Til underretning af andre
medlemsstater om den meddelte typegodkendelse eller om eventuelle 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.


Full & Egal Universal Law Academy